Vorgehensweise bei XDEV 2 Projekten

Letzte Änderung 03.02.2010

Die Entwicklung von Software-Anwendungen ist mit XDEV 2 zwar deutlich einfacher und schneller als mit klassischen Code-Editoren, die Vorgehensweise bei der Anwendungs-Entwicklung ändert sich dadurch jedoch nicht. Es gibt bestimmte Regeln, die Sie grundsätzlich bei der Entwicklung beachten sollten.

Am Anfang eines Software-Projektes sollte immer zuerst eine ausführliche Bedarfs-Analyse stattfinden. Veranstalten Sie ein Meeting zu dem Sie den oder die Projektleiter, möglichst alle Entwickler und Ihren Kunden mit möglichst allen Entscheidern einladen. Überzeugen Sie Ihren Kunden, dass es enorm wichtig ist, dass auch spätere, wichtige Anwender unbedingt an diesem Meeting teilnehmen sollten. Denn die Meinung der Anwender wird später über den Erfolg oder Misserfolg Ihres Projektes entscheiden. Nehmen Sie sich für dieses Meeting sehr viel Zeit und erörtern Sie gemeinsam möglichst detailliert, was die benötigte Software im Idealfall alles können sollte. Spielen Sie durch, wie das Handling der Benutzeroberfläche sein soll, ob sich viel im Hauptfenster abspielen, oder ob die Funktionen auf mehrere Fenster verteilt werden sollen. Das allerwichtigste ist jedoch das Datenmodell, auf dessen Planung Sie aller größten Wert legen sollten. Erörtern so ausführlich wie möglich, welche Daten von der Anwendung verwaltet werden müssen. Gehen Sie dabei bis ins kleinste Detail und versuchen Sie alle Fälle zu erfassen.

Beispiel: Bei einer Kunden-Verwaltung müssen Firmen verwaltet werden. Eine Firma kann mehrere Niederlassungen haben. Eine Niederlassung hat eine Postanschrift, kann jedoch zusätzlich eine andere Rechnungsanschrift benutzen. In jeder Anschrift kann ein Postfach vorkommen, wobei ein Postfach sogar eine eigene Postleitzahl haben kann.

Bei dieser Diskussion wird sich bereits klären, wie weit Ihr Kunde oder die Anwender ins Detail gehen möchten. Das ganze Meeting muss so ausführlich und genau wie möglich protokolliert werden, da oftmals kleine Anmerkungen von entscheidender Bedeutung sein können. Nehmen Sie ruhig auch aus Ihrer Sicht uthopische Wünsche und Vorschläge mit auf. Vielleicht relativiert sich der Aufwand später und Sie können mit der einen oder anderen Überraschung punkten. Bei entsprechendem Projektumfang können auch mehrere Meetings dieser Art notwendig sein. Nach dem Meeting erfolgt die Gliederung der nun sehr ausführlichen Stoffsammlung.

Unterziehen Sie nun alle wichtigen und aus Ihrer Sicht kritischen Features einer Machbarkeitsanalyse. Für Funktionen, bei denen Sie sich nicht sicher sind, sollten Sie kleine eigenständige Anwendungen als Prototypen entwickeln. Sie werden sehr schnell feststellen, dass sich XDEV 2 auch hervorragend eignet, sehr schnell und vor allem realitätsnahe Prototypen zu entwickeln. Sollten Sie beim Prototyping auf Probleme stoßen, können Sie jetzt noch flexibel darauf reagieren und ggf. sogar Ihr Konzept noch umstellen. Später ist dies oftmals nur noch mit großem Aufwand und erheblichem Zeitverlust möglich. Verwenden Sie bereits für das Prototyping möglichst realistische Testdaten und testen Sie soweit möglich unter Realbedingungen, z.B. auf entsprechender Hardware, Betriebssystem, Datenbank und mit einer vergleichbaren Datenanbindung. Bereits bei diesem Arbeitsschritt erhalten Sie einen groben Überblick über den bevorstehenden Gesamtaufwand, welche Features sich problemlos realisieren lassen und welche Features auf Grund eines zu hohen Aufwandes erst einmal zurück gestellt werden sollten. Die wertvollen Erkenntnisse nach dem Prototyping sollten nun nochmals bei einem gemeinsamen Meeting besprochen werden, sodass Sie nun alle Programm-Features nach ihrer Priorität gliedern und sich gemeinsam auf den tatsächlichen Feature-Umfang festlegen können. Das entsprechende Protokoll dazu wäre ein grobes Lastenheft, welches entweder von Ihrem Kunden zu einem finalen Lastenheft, oder von Ihnen zu einem Pflichtenheft ausgearbeitet wird. In der Praxis wird aus Zeit- und Kostengründen sehr häufig auf die Ausarbeitung eines detaillierten Lasten- und Pflichtenheftes verzichtet. Dies wird häufig damit begründet, dass sich die Anforderungen während der Entwicklung ggf. noch erheblich ändern können und dann auch das Pflichtenheft wieder geändert werden muss. Meistens stellt sich jedoch heraus, dass dies eine "Milchmännchen-Rechnung" ist. Denn wenn sich die Anforderungen ändern, muss meistens auch das Datenmodell, im besten Fall ergänzt, im schlimmsten Fall geändert werden, was einen deutlich höheren Aufwand bedeutet, als die Dokumentation zu ändern. Erfolgt die Änderung in einem bereits fortgeschrittenem Stadium, ist eine grundsätzliche Änderung des Datenmodells oft nicht mehr möglich, sodass man zu (zeitlich = Geld) schmerzhaften Spagaten gezwungen wird. Besteht dennoch der Wunsch oder die Notwendigkeit auf ein Pflichtenheft zu verzichten, ist Ihr ausführliches Protokoll zu Ihren Meetings umso wertvoller.

Nachdem alle Spezifikationen feststehen, folgt nun gleich eine der bedeutendsten Phasen Ihres ganzen Projekts - die Entwicklung des Datenmodells. Setzen Sie sich für diese Aufgabe kein zeitliches Limit, sondern nehmen Sie sich so viel Zeit wie Sie brauchen. Das Datenmodell ist das Fundament jeder Datenbank-Anwendung und somit ein ganz bedeutender Arbeitsschritt. Analysieren Sie nochmals mit größter Sorgfalt, welche Daten von der Anwendung verwaltet werden müssen und erstellen Sie möglichst realistische Test-Datensätze. Falls die Möglichkeit besteht, bereits existierende reale Datensätze einzusehen, dann sollten Sie diese unbedingt nutzen. Anschließend könnten Sie mit der sog. Normalisierung beginnen. Dabei werden die Datensätze zerlegt und die Daten auf mehrere Tabellen verteilt, die mittels eines Schlüssels miteinander in Beziehung (Relation) stehen, um ein relationales Datenbankschema zu erhalten, was für jede Datenbank-Anwendung notwendig ist. Die Normalisierung hat zum Ziel, Redundanzen (vielfach vorkommende Werte in einer Tabelle) zu vermeiden, die unnötigen Speicherplatz einnehmen, Datenbank-Abfragen z.T. erheblich verlängern und bei Änderung von Daten schlimmstenfalls zu Inkonsistenzen (fehlerhafte Daten) führen. Hier kann es sich ggf. lohnen, einen erfahrenden Datenbank-Entwickler als Berater hinzuzuziehen. Denn jede spätere Änderungen am Datenmodell wird zwangsweise eine Überarbeitung der Programmlogik zur Folge haben, was Sie eine Menge Entwicklungszeit kosten kann und zudem eine enorme Fehlerquelle darstellt. Allein durch eine sorgfältige Planung des Datenmodells können Sie eine Menge Probleme vermeiden und legen gleichzeitig den Grundstein für eine fehlerfreie und performante Anwendung. Der Umgang mit relationalen Datenbanken ist im Grunde nicht allzu schwer, erfordert jedoch theoretisches Grundwissen und stellt daher im Grunde die einzige Einstiegshürde in XDEV 2 dar. Daher wird das Thema Relationale Datenbanken in diesem Handbuch ausführlich behandelt, sodass Sie auch als Einsteiger die Zusammenhänge schnell verstehen und sich innerhalb kürzester Zeit in die Thematik einarbeiten können.

Nach Fertigstellung des Datenmodells müssen Sie alle benötigten Tabellen mit dem Administrations-Werkzeug Ihrer Datenbank anlegen. Wenn Sie noch wenig Erfahrung mit der Datenbank haben, die zum Einsatz kommen soll, dann können Sie Ihre Tabellen auch mit Hilfe des Daten-Editors, den Sie im Menü Daten finden, direkt in XDEV 2 als Virtuelle Tabellen anlegen und anschließend bequem in Ihre Datenbank exportieren. Es ist jedoch sehr empfehlenswert, sich mit dem Administrations-Frontend seiner Datenbank zu beschäftigen, da die Adiminstrations-Möglichkeiten die Ihnen XDEV 2 bietet, nur eine Schnittmenge aller unterstützter Datenbanken darstellt, während jede Datenbank spezielle Funktionen bietet und ihre Eigenheiten hat, z.B. die Unterscheidung von Groß- und Kleinschreibung bei Tabellen- und Feldnamen, Lieferung von Fehlermeldungen usw. Zudem ist es während der Entwicklung hilfreich, sich nach Datenbank-Abfragen die Daten direkt in der Datenbank anzusehen, um Fehler in Abfragen schneller auf die Spur zu kommen. I.d.R. finden Sie auf der Homepage Ihres Datenbank-Herstellers eine Dokumentation zum Datenbank-Administrations-Frontend. Wenn Sie Ihre Tabellen mit Ihrem Datenbank-Tool angelegt haben, müssen Sie nun umgekehrt alle Tabellen mit dem Daten-Editor als Virtuelle Tabellen nach XDEV 2 importieren. Jede Virtuelle Tabelle stellt eine Art Spiegelbild der Datenbank-Tabelle dar.

Nun erfolgt ein weiterer, bedeutender Arbeitsschritt - die Konstruktion eines ER-Diagramms (Entity Relationship). Das ER-Diagramm dient eigentlich zur besseren Übersicht über das Datenmodell, sodass man die Zusammenhänge schneller verstehen kann. sich , das als Basis für alle Ihre Datenbank-Abfragen dienen wird. Im ER-Diagramm werden alle Tabellen abgebildet und über ihre Schlüssel-Felder miteinander verknüpft. Bei der Konstruktion von Abfragen mit Hilfe des SQL-Assistenten greift dieser selbständig auf das ER-Diagramm zu und liefert Ihnen auf Basis der hinterlegten Verknüpfungen die für jede Datenbank-Abfrage notwendige SQL-Anweisung sogar inkl. Join-Bedingung. Achten Sie darauf, dass Sie alle Verknüpfungen korrekt anlegen, da Sie ansonsten mit dem SQL-Assistenten automatisch falsche Datenbank-Abfragen konstruieren werden.

Nach Abschluss der Arbeiten am Datenmodell können Sie mit der Entwicklung der Grafischen Benutzeroberfläche beginnen. Das Hauptfenster, sowie zahlreiche Eingabemasken, Fenster und Dialoge können oftmals schon fertiggestellt werden, ohne dass Sie mit der Entwicklung der Programmlogik beginnen müssen. In der Praxis wird jedoch die Entwicklung der Oberfläche und der Programmlogik fließend ineinander übergehen. Es ist sehr empfehlenswert, den Programmcode bereits während der Entwicklung ausführlich zu dokumentieren, sodass Sie Ihre Anwendung zu einem späteren Zeitpunkt möglichst einfach warten und weiter entwickeln können. Bereits während der Entwicklung sollten Sie Ihre Anwendung regelmäßig und ausführlich testen, um vor allem Fehler im Datenmodell möglichst früh erkennen und korrigieren zu können. Auch der Workflow einer Anwendung sollte regelmäßig getestet werden. Falls möglich sollten Sie dabei eng mit Ihrem Kunden und den späteren Anwendern zusammen arbeiten, um auch hier auf Änderungswünsche möglichst früh reagieren zu können.

7.	Abschließend erfolgt ein ausführlicher Betatest, der möglichst schon auf dem Ziel-System durchgeführt werden sollte.