zurueckweiter


Einige wichtige Aspekte der Software Entwicklung

Die traditionelle Methode IS Anwendungen zu entwickeln ist eine Entwicklung in Stufen. Diese Methode wird als "Wasserfall Methode" bezeichnet, weil ein Entwicklungsprojekt in eine Reihe aufeinanderfolgender Entwicklungsphasen unterteilt wird. Die üblichen Phasen sind dabei "Produkt-Specifikation", "Grobdesign", "Feindesign", "Kodierung", "Test" und "Einführung". Eine neue Phase zu beginnen ist im Wasserfall Modell nur erlaubt, wenn der abschließende Checkpoint der vorausgehenden Phase erfolgreich bestanden worden ist.

Mit dem Erscheinen neuer, objektorientierter Programmiersprachen wie z.B. "Smalltalk" und "Java" wurde das Wasserfallmodell von vielen Anwendungsentwicklern zugunsten eines iterativen Programmentwicklungsverfahrens aufgegeben. Diese iterativen Modelle werden häufig als "Spiralmodell" und "Fontänenmodell" bezeichnet. Bei diesen Verfahren wird mit einem ersten Entwurf für ein Programmsystem begonnen. Dieser Entwurf (oft als "Prototyp" bezeichnet) wird dann diskutiert und in mehreren Iterationsschritten verfeinert, und zwar solange, bis er allgemein akzeptiert wird.

Die Befürworter dieses iterativen Verfahrens behaupten, dass die auf diese Art und Weise erstellten Anwendungssysteme von potentiellen Endbenutzern besser angenommen werden. Der Grund dafür ist, dass diese potentiellen Endbenutzer schon relativ früh einen Eindruck vom Aussehen und Verhalten der Anwendung bekommen weil sie ja die einzelnen Prototypen testen können und dadurch in der Lage sind, das endgültige Produkt noch zu beeinflussen.

Dies scheint ein sinnvolles Argument zu sein, aber die Erfahrung zeigt, dass Projekte, die nicht unter der strengen Kontrolle des "Wasserfall Modelles" durchgeführt werden, dazu tendieren, gesetzte Entwicklungspläne signifikant zu überschreiten. Es scheint einen schweren Konflikt zwischen wünschenswertem Zeitpunkt der Markteinführung und Produktakzeptanz zu geben.

Die Wahrheit scheint aber (wie fast immer) in der Mitte zu liegen. Zumindest für größere Entwicklungsprojekte gelten folgende Feststellungen:

Ein empfohlener Entwicklungsansatz

Wenn ein Produkt entwickelt werden soll, das geschäftsmäßig einen ganzen Industriezweig (oder zumindest einen wesentlichen Teil davon) abdecken soll, dann schlage ich das schon erwähnte "Sinnvolle Wasserfallmodell" als Entwicklungsmethode vor. Das bedeutet konkret, ich schlage vor, zuerst eine (weitgehend) vollständige Analyse der Problemdomäne vorzunehmen um daraus dann ein "Soll-Modell" des Geschäftsbereiches zu erstellen. Basierend auf diesem Modell sollte dann als zweiter Schritt ein grober technischer Entwurf des anvisierten IS Anwendungssystemes erstellt werden, ein Entwurf, den man bei traditioneller Anwendungsentwicklung als "High Level Design" bezeichnet. Dieser technische Grobentwurf kann dann zur Segmentierung der Problemdomäne in verschiedene Implementierungsdomänen verwendet werden. Entsprechend der zur Verfügung stehenden Ressourcen (Personal, Zeit und Geld) können dann die identifizierten Implementierungsdomänen parallel oder sequentiell in Angriff genommen werden. Durch die geleistete Vorarbeit ist bei diesem Ansatz die Homogenität des Gesamtsystemes weitgehend gewährleistet und ein Projekt kann schnellstmöglich zu vermarktungsfähigen Ergebnissen führen.

Entwicklungsansatz
Ein sinnvoller Entwicklungsansatz.

Der Hauptvorteil dieses Ansatzes ist es, dass die Implementierungen der verschiedenen Produktkomponenten auf solider Basis vorgenommen werden können. Diese Basis ist das weitgehend vollständige und sehr konsistente Geschäftsbereichsmodell. Dieses Modell garantiert, dass die Produktkomponenten nahtlos zusammenpassen, das bedeutet, es gibt keine funktionellen Überlappungen und damit keinen unnötigen Mehrfachaufwand.

Aber es gibt noch weitere Vorteile:

Gesichtspunkte der Software Spezifikation

Gemäß des oben gezeigten Diagrammes ist die Produktspezifikation (bzw. Problemspezifikation) die erste Phase im Entwicklungszyklus einer kommerziellen IS Anwendungssuite.

Während dieser Phase sollte das anvisierte Produkt aus Geschäftssicht so vollständig wie möglich beschrieben werden. Als geeignetste Form für eine derartige Beschreibung empfehle ich ein "Geschäftsbereichsmodell" denn reine Geschäftsfunktionen (nicht durchmischt mit organisatorischen und technischen Aspekten) ändern sich im Laufe der Zeit nur geringfügig und darum ist eine solche Beschreibung sehr stabil und langlebig.

Es gibt im Prinzip drei Arten von Anwendungssoftware:

  1. generische Middle-Ware und Werkzeuge, wie z.B. Workflow Manager, Transaktionsmanager, Datensicherungssysteme, Text-Editioren, Graphik-Editioren oder Arbeitsblätter (spreadsheets).
  2. Computerspiele, die auf Einzelrechnern oder auch in einem Netzwerk gespielt werden.
  3. Kommerzielle Software zur Steuerung und Unterstützung von Geschäftstransaktionen eines Unternehmens um im wirtschaftlichen Sinne konkurenzfähig zu bleiben.

Zwischen diesen Softwarearten gibt es durchaus grundlegende Unterschiede. Der wichtigste Unterschied ist dabei sicherlich die Behandlung von Daten.

Für Werkzeuge und Spiele besteht normalerweise eine geringe Notwendigkeit Datenelemente zu verwenden, die von mehreren aktiven Programminstanzen gleichzeitig benutzt werden müssen. Inkonsistenzen zwischen gleichartigen Informationselementen verschiedener aktiven Software Instanzen sind meist tolerabel. Eine Ausnahme mögen sogenannte Netzwerkspiele sein, die z.B. im Internet gespielt werden.

Der Sinn kommerzieller IS Anwnedungen ist aber hauptsächlich die Informationsverwaltung. Das bedeutet, dass Informationseinheiten, die von verschiedenen Anwendungsinstanzen benutzt werden, müssen konsistent sein. Die Integrität einer Unternehmensdatenbank ist normalerweise lebenswichtig für eine Firma und darum ist die wichtigsten Aufgaben der verwendeten Anwendungssysteme, diese Integrität unter allen Umständen zu garantieren. Das erzeugt spezielle Anforderungen an die kommerzielle Anwendungsentwicklung.

Dieses Dokument widmet sich besonders der Entwicklung kommerzieller Anwendungen. Es ist daher wichtig, die spezifischen Anforderungen an diese Art von Software zu verstehen, sowie die Unterschiede in Bezug auf andere Software herauszustellen.

Wenn wir mit der Entwicklung von kommerziellen Anwendungssystemen beginnen, stellen wir unmittelbar fest (normalerweise schon während der Erstellung des sogenannten Pflichtenheftes - also der funktionellen Beschreibung), dass wir es mit einer ziemlich komplexen Problemdomäne zu tun haben. Innerhalb dieser Problemdomäne tauchen Informationseinheiten, aber auch essentielle Komponenten von Ablaufprozeduren an verschiedenen Stellen immer wieder auf.

Es gibt einen prinzipiellen Unterschied zwischen der Behandlung eines Informationselementes, das die Größe einer Schrift in einem Dokument bestimmt, das mittels eines Texteditiors erstellt wird und der Behandlung eines Informationselementes das zu einem Auftrag gehört, der durch die einzelnen Abteilungen eines Handelsunternehmens läuft.

Werkzeuge haben normalerweise eine bestimmte Anzahl von mehr oder weniger unabhängigen Parametern, die eine limitierten Anzahl von Werten annehmen dürfen. Sie haben ebenfalls meist eine große Zahl kleiner, wohldefinierter aber in der Regel nicht zu komplexer Operationen, die relativ unabhängig voneinander sind und die durch die oben erwähnten Parameterwerte gesteuert werden, die für eine Sitzung eingestellt wurden. Die interaktive Benutzung dieser elementaren Operationen durch den Endbenutzer ist typisch für solche Programmwerkzeuge.

Bei industriespezifischen Anwendungen ist die Zahl der Parameter, die den Ablauf der Geschäftsfunktionen selbst steuern (also nicht die, die die Präsentation von Information in einem Bildschirmfenster bestimmen), nicht übermäßig groß, dafür ist aber die Integration der Aktivitäten viel intensiver. Oft gibt es für bestimmte Geschäftvorfälle festgelegte Aktivitätsfolgen, die eine bestimmte Bereitstellung von Informationen und ganz bestimmte Zugriffe auf Datenbanken erfordern, um das erwünschte Geschäftsergebnis zu erzeugen.

Werkzeuge erfordern in der Regel keine Datenbank als Ablage für sogenannte "schlafende Objekte" oder "Instanzen von Informationsgruppen" die einem bestimmten Typ von Informationsstruktur angehören.

Kommerzielle Anwendungssystem benutzen das gleiche Datenelement (die gleiche Instanz) innerhalb der verschiedensten Prozesse. Die Geschäftsprozesse können unabhängig voneinander sein, sie können aber auch voneinander abhängig und miteinander verzahnt sein. Da Informationen simultan in verschiedenen Geschäftsprozessen verwendet werden und weil diese Informationseinheiten in aller Regel Einfluß auf das Ergebnis einer Geschäftstransaktion haben, ist es besonders wichtig, diese Informationseinheiten gut zu strukturieren, und es muss sichergestellt werden, dass jedem Geschäftsprozess die gleichen und die aktuellsten Informationen zur Verfügung gestellt werden. Andernfalls ist es unmöglich, die Integrität der Unternehmensdatenbank zu gewährleisten.

Ein weiterer zu fordernder Anspruch an kommerzielle Anwendungsentwicklung ist es, die elementaren Geschäftstransaktionen immer durch dieselben elementaren Softwareprozeduren zu unterstützen. Es ist für Endbenutzer eines kommerziellen Anwendungssystemes sehr verwirrend, wenn für gleichartige Geschäftsabläufe unterschiedliche Unterstützung angeboten wird. So etwas ist grundsätzlich zu vermeiden.

Die zwei Forderungen (die Integrität der kommerziellen Datenbank zu garantieren und immer dieselben essentiellen Geschäftsprozeduren zu verwenden) machen klar, dass es für die Entwicklung kommerzieller Anwendungssysteme viel wichtiger ist als für die Entwicklung von Programmwerkzeugen, dass die Problemdomäne sorgfältig analysiert wird, und dass das Analyseresultat genauso sorgfältig und so vollständig wie möglich dokumentiert wird. Das zu erreichende Ziel in dieser Entwicklungsphase ist also die Erstellung einer soliden Geschäftsfeldbeschreibung die weitgehendst frei von organistorischen und technischen Gesichtspunkten sein muss. Solch eine Beschreibung kann dann die Basis für den Entwurf eines kommerziellen Anwendungssystemes sein, das die Geschäftsvorgänge der entsprechenden Domäne in optimaler Form unterstützt. Sie kann zudem die Basis für Managemententscheidungen darstellen, wie ein Geschäftsfeld für die Zukunft weiterentwickelt werden sollte. Obwohl Änderungen einer derartigen Geschäftsfeldbeschreibung relativ selten anfallen, ist es trotzdem sinnvoll, die Form eines "Geschäftsbereichsmodelles" zu wählen, einer Form die sehr leicht auf dem neuesten Stand gehalten werden kann.

zum Seitenanfang
zum Inhaltsverzeichnis

zurueckweiter