KAPITEL 3 Softwareprozesse LERNZIELE Das Ziel dieses Kapitels ist es, Sie mit dem Konzept des Softwareprozesses einer zusammenhängenden Menge von Abläufen der Softwareherstellung bekannt zu machen. Wenn Sie dieses Kapitel gelesen haben, werden Sie das Konzept eines Softwareprozesses und eines Vorgehensmodells für Software verstehen, eine Anzahl verschiedener Vorgehensmodelle kennen und wissen, wann sie anzuwenden sind, im Groben Vorgehensmodelle für die Analyse von Softwareanforderungen, die Softwareentwicklung, das Testen und die Weiterentwicklung von Software kennen, sich mit CASE-Technologie zur Unterstützung von Softwareprozessen befasst haben. Wie ich schon in Kapitel 1 erwähnt habe, ist ein Softwareprozess eine Menge von Aktivitäten und damit zusammenhängenden Ergebnissen, die zur Herstellung eines Softwareprodukts führen. Dazu kann die Entwicklung von Software von Grund auf zählen, obwohl immer häufiger der Fall eintritt, dass neue Software entwickelt wird, indem bestehende Systeme erweitert und verändert werden. Softwareprozesse sind sehr komplex und, wie alle intellektuellen Vorgänge, abhängig vom menschlichen Urteilsvermögen. Gerade wegen des Bedarfs an Urteilsvermögen und Kreativität hat der Versuch, Softwareprozesse zu automatisieren, nur begrenzt Erfolg gehabt. CASE- Werkzeuge (die in Abschnitt 3.7 besprochen werden) können einige der Abläufe unterstützen, aber es wird zumindest in den nächsten Jahren keine Möglichkeit der umfassenden Automatisierung geben, bei der Software den am Softwareprozess beteiligten Entwicklern das kreative Entwerfen abnimmt. Ein Grund dafür, dass es nur begrenzten Spielraum für Automatisierung gibt, liegt in der großen Vielfalt der Softwareprozesse. Es gibt keinen idealen Prozess und die verschiedenen Organisationen haben völlig unterschiedliche Ansätze für die Softwareentwicklung. Die Prozesse haben sich so verändert, dass sie die Fähigkeiten der Menschen in einer Organisation und die Eigenschaften der Systeme, die entwickelt werden, optimal ausnutzen. Daher kann es sogar innerhalb einer Firma verschiedene Prozesse für die Softwareentwicklung geben. Obwohl es viele verschiedene Softwareprozesse gibt, gibt es einige grundlegende Abläufe, die alle Softwareprozesse gemeinsam haben: 1. Softwarespezifikation: Die Funktionen der Software und die Beschränkungen ihrer Benutzung müssen definiert werden. 2. Softwareentwurf und -implementierung: Die Software, die diese Anforderungen erfüllen soll, muss erstellt werden.
56 Kapitel 3 Softwareprozesse 3. Softwarevalidierung: Die Software muss validiert werden, um sicherzustellen, dass sie tut, was der Kunde will. 4. Weiterentwicklung von Software: Die Software muss sich weiterentwickeln, um mit den sich verändernden Bedürfnissen des Kunden Schritt zu halten. Ich werde Ihnen in diesem Kapitel nur einen Überblick über diese Aktivitäten geben und sie an anderer Stelle detailliert erläutern. Obwohl es keinen idealen Softwareprozess gibt, können viele Organisationen ihre Softwareprozesse noch deutlich verbessern. Die Prozesse beruhen mitunter auf veralteten Techniken oder ignorieren die Vorteile anerkannter Praktiken beim industriellen Software Engineering. Tatsächlich verlassen sich viele Organisationen auf Ad-hoc-Prozesse und benutzen bei der Entwicklung ihrer Software keinerlei Methoden aus dem Bereich des Software Engineering. Die Verbesserung von Softwareprozessen kann auf verschiedene Arten eingeführt werden. Sie kann aus der Standardisierung der Prozesse folgen, bei der die Vielfalt von Softwareprozessen innerhalb der Organisation reduziert wird. Dies führt zu besserer Kommunikation, reduzierter Schulungszeit und macht eine automatisierte Unterstützung der Prozesse bezahlbar. Eine Standardisierung ist auch ein wesentlicher Schritt bei der Einführung neuer Methoden und Techniken des Software Engineering. Ich werde in Kapitel 25 auf die Verbesserung von Softwareprozessen zurückkommen. 3.1 Vorgehensmodelle Wie in Kapitel 1 beschrieben, handelt es sich bei einem Vorgehensmodell um eine abstrakte Darstellung eines Softwareprozesses. Jedes Vorgehensmodell stellt einen Prozess von einem bestimmten Standpunkt dar und zeigt somit nur einen Teil der Informationen über diesen Prozess. In diesem Abschnitt werde ich eine Anzahl sehr allgemeiner Vorgehensmodelle (auch Prozessparadigmen genannt) einführen und sie vom Standpunkt der Architektur vorstellen. Das heißt, wir sehen den Rahmen des Prozesses, aber keine Details über die speziellen Abläufe. Diese allgemeinen Modelle sind keine endgültigen Beschreibungen der Softwareprozesse, sondern vielmehr nützliche Abstraktionen, die benutzt werden können, um verschiedene Ansätze der Softwareentwicklung zu erläutern. Für große Systeme gibt es natürlich keinen einzelnen Softwareprozess, der immer verwendet wird, sondern es kommen bei der Entwicklung verschiedener Teile des Systems unterschiedliche Prozesse zum Einsatz. Die Vorgehensmodelle, die ich in diesem Kapitel erläutern werde, sind: 1. Das Wasserfall-Modell: Dieses Modell stellt die grundlegenden Prozessabläufe wie Spezifikation, Entwicklung, Validierung und Weiterentwicklung als eigenständige Phasen des Prozesses dar, wie zum Beispiel als Spezifikation der Anforderungen, als Softwareentwurf, Implementierung, Tests usw. 2. Evolutionäre Entwicklung: Dieser Ansatz verknüpft die Aktivitäten der Spezifikation, der Entwicklung und der Validierung, indem möglichst schnell aus abstrakten Spezifikationen ein erstes System entwickelt wird. Mit Hilfe des Kunden wird dieses System verfeinert, bis es die Bedürfnisse des Kunden erfüllt. 3. Formale Systementwicklung: Dieser Ansatz basiert darauf, formale mathematische Systemspezifikationen herzustellen und diese mit Hilfe mathematischer Funktionen in ein Programm umzuwandeln. Die Verifikation von Systemkomponenten findet statt, indem mathematisch bewiesen wird, dass sie mit ihrer Spezifikation übereinstimmen.
3.1 Vorgehensmodelle 57 4. Entwicklung unter Wiederverwendung: Dieses Modell basiert auf der Existenz einer beträchtlichen Anzahl von wiederverwendbaren Komponenten. Der Systementwicklungsprozess beschäftigt sich mehr damit, diese Komponenten in ein System zu integrieren, als damit, neue Komponenten von Grund auf zu entwickeln. Prozesse, die auf dem Wasserfallmodell oder auf der evolutionären Entwicklung aufbauen, sind in der praktischen Systementwicklung weit verbreitet. Die Formale Systementwicklung ist in einer Reihe von Projekten erfolgreich angewendet worden (Mills et al., 1987; Linger, 1994), aber Prozesse, die auf diesem Modell basieren, werden nur in wenigen Organisationen angewendet. Informelle Wiederverwendung kommt in vielen Prozessen vor, aber die wenigsten Organisationen orientieren ihre Softwareentwicklungsprozesse explizit an der Wiederverwendbarkeit. Dieser Ansatz wird im 21. Jahrhundert wahrscheinlich an Einfluss gewinnen, da die Wiederverwendung von Komponenten für die schnelle Softwareentwicklung absolut notwendig ist. Ich werde die Wiederverwendung von Software in Kapitel 14 besprechen. 3.1.1 Das Wasserfall -Modell Das erste veröffentlichte Modell für die Softwareentwicklung wurde von anderen Entwicklungsprozessen abgeleitet (Royce, 1970). Es wird in Abbildung 3.1 dargestellt. Wegen der Kaskade von einer Phase zur nächsten wird dieses Modell das Wasserfall-Modell oder der Softwarelebenszyklus genannt. Die wichtigen Phasen dieses Modells lassen sich auf grundlegende Entwicklungsaktivitäten abbilden: 1. Analyse und Definition der Anforderungen: Die Dienstleistungen, Einschränkungen und Ziele des Systems werden in Zusammenarbeit mit den Systembenutzern aufgestellt. Dann werden sie detaillierter definiert und dienen so als Systemspezifikationen. 2. System- und Softwareentwurf: Der Systementwurfsprozess teilt die Anforderungen in Hardund Softwaresysteme auf und legt eine allgemeine Systemarchitektur fest. Beim Softwareentwurf geht es um das Erkennen und Beschreiben der grundlegenden abstrakten Softwaresysteme und ihrer Beziehungen zueinander. 3. Implementierung und Komponententest: In dieser Phase wird der Softwareentwurf in eine Reihe von Programmen oder Programmeinheiten umgesetzt. Das Testen der Einheiten stellt sicher, dass jede Einheit ihre Spezifikationen erfüllt. 4. Integration und Systemtest: Die einzelnen Programme oder Programmeinheiten werden zusammengeführt bzw. integriert und als Ganzes getestet, um sicherzustellen, dass die Softwareanforderungen erfüllt werden. Nach den Tests wird das Softwaresystem an den Kunden ausgeliefert. 5. Betrieb und Wartung: Normalerweise (aber nicht unbedingt) ist dies die längste Phase innerhalb des Lebenszyklus. Das System wird installiert und zum Gebrauch freigegeben. Zur Wartung gehörten das Korrigieren von Fehlern, die in den früheren Phasen nicht entdeckt wurden, die Verbesserung der Implementierung von Systemeinheiten und die Verbesserung des Systems, falls neue Anforderungen entdeckt werden. In der Theorie gehen aus jeder Phase ein oder mehrere Dokumente hervor, die abgenommen, reviewed", werden. Die nächste Phase sollte nicht beginnen, bevor nicht die vorherige abgeschlossen wurde. In der Praxis überlappen sich die Phasen und tauschen Informationen untereinander aus. Während des Entwurfs werden Probleme mit den Anforderungen entdeckt, während des Programmierens fallen Fehler im Entwurf auf usw. Der Softwareprozess ist nicht einfach ein linearer Prozess, sondern besteht aus einer Reihe sich wiederholender Entwicklungsaktivitäten.
58 Kapitel 3 Softwareprozesse Abbildung 3.1 Der Softwarelebenszyklus Anforderungsdefinition System- und Softwareentwurf Implementierung und Komponententest Integration und Systemtests Betrieb und Wartung Wegen der hohen Kosten bei der Herstellung und Abnahme von Dokumenten sind die Iterationen von Entwicklungsaktivitäten teuer und verlangen erhebliche Überarbeitungen. Daher wird normalerweise nach einer kleinen Anzahl von Wiederholungen ein Teil der Entwicklung, zum Beispiel die Spezifikation, eingefroren und ein anderer angefangen. Probleme werden zurückgestellt, ignoriert oder im Programm umgangen. Dieses verfrühte Einfrieren von Anforderungen kann bedeuten, dass das System nicht das tun wird, was der Benutzer will. Es kann auch zu einem schlecht strukturierten System führen, weil Probleme im Entwurf durch Tricks in der Implementierung umgangen werden. Während der letzten Phase des Lebenszyklus (Betrieb und Wartung) wird die Software in Betrieb genommen. Dabei werden Fehler und Lücken in den ursprünglichen Anforderungen entdeckt. Es tauchen Programm- und Entwurfsfehler auf und der Bedarf an neuen Funktionen wird festgestellt. Das System muss sich also weiterentwickeln, um nützlich zu bleiben. Das Durchführen dieser Veränderungen (die Softwarewartung) kann zur Folge haben, dass einige oder alle der vorherigen Prozessphasen wiederholt werden müssen. Das Problem beim Wasserfall-Modell ist seine starre Aufteilung des Projektes in die verschiedenen Phasen. Zu einem frühen Zeitpunkt müssen Verpflichtungen eingegangen werden und das bedeutet, dass es schwer ist, sich auf neue Anforderungen des Kunden einzustellen. Daher sollte das Wasserfall-Modell nur Verwendung finden, wenn die Anforderungen gut durchdacht sind. Das Wasserfall-Modell spiegelt jedoch auch die momentane Entwicklungspraxis wider. Daraus folgt, dass auf diesem Modell basierende Softwareprozesse immer noch bei der Softwareentwicklung benutzt werden besonders, wenn es sich dabei um einen Teil eines größeren Systementwicklungsprojekts handelt. 3.1.2 Evolutionäre Entwicklung Die evolutionäre Entwicklung basiert darauf, eine Anfangsimplementierung zu entwickeln, die Benutzer zu Kommentaren zu dieser Implementierung aufzufordern und sie über viele Versionen hinweg zu verfeinern, bis ein angemessenes System entstanden ist (Abbildung 3.2).
3.1 Vorgehensmodelle 59 Anstatt die Spezifikation, die Entwicklung und die Validierung als separate Abläufe zu betrachten, werden sie gleichzeitig ausgeführt, wobei sie untereinander Rückmeldungen austauschen. Es gibt zwei Arten von evolutionärer Entwicklung: 1. Die erforschende (explorative) Entwicklung, bei der das Ziel des Prozesses darin besteht, durch die Zusammenarbeit mit dem Kunden die Anforderungen zu bestimmen und ein fertiges System auszuliefern. Die Entwicklung beginnt bei den Teilen des Systems, die eindeutig sind. Das System entwickelt sich, indem neue Funktionen hinzugefügt werden, die der Kunde vorschlägt. 2. Die Erstellung von Wegwerf-Prototypen, bei denen das Ziel des evolutionären Entwicklungsprozesses ist, die Bedürfnisse des Kunden zu verstehen und dadurch eine bessere Definition der Anforderungen zu entwickeln. Der Prototyp beschränkt sich auf die Teile der Bedürfnisse des Kunden, die unklar geblieben sind. Abbildung 3.2 Evolutionäre Entwicklung Gleichzeitig stattfindende Aktivitäten Spezifikation Anfangsversion Grobe Beschreibung Entwicklung Zwischenversionen Validierung Endversion Ich werde evolutionäre Entwicklungsprozesse und -prozessunterstützung in Kapitel 8 behandeln, das auch die verschiedenen Arten von Prototypen beschreibt. Ein evolutionärer Ansatz der Softwareentwicklung ist häufig effektiver als das Wasserfall- Modell, wenn es darum geht, Systeme herzustellen, die die unmittelbaren Bedürfnisse des Kunden erfüllen. Der Vorteil eines Softwareprozesses, der auf dem evolutionären Ansatz basiert, ist, dass die Spezifikation nach und nach erstellt wird. Noch während die Benutzer ihr Problem besser kennen lernen, können geeignete Veränderungen am Softwaresystem vorgenommen werden. Die evolutionäre Entwicklung hat jedoch vom Standpunkt der Entwicklung und des Managements aus gesehen drei Schwachpunkte: 1. Der Prozess ist nicht sichtbar: Manager brauchen in regelmäßigen Abständen Zwischenversionen, an denen sie den Fortschritt messen können. Wenn Systeme schnell entwickelt werden, ist es nicht kosteneffektiv, jede Version zu dokumentieren. 2. Die Systeme sind oft schlecht strukturiert: Stetige Veränderungen neigen dazu, die Struktur der Software zu beeinträchtigen. Die Integration von Softwareänderungen wird zunehmend schwerer und teurer.
60 Kapitel 3 Softwareprozesse 3. Es könnten spezielle Werkzeuge und Techniken erforderlich werden: Diese können zwar eine schnelle Entwicklung unterstützen, sind aber vielleicht inkompatibel mit anderen Werkzeugen oder Techniken, und womöglich wissen nur relativ wenige Leute, wie man mit ihnen umgeht. Für kleine (weniger als 100 000 Codezeilen) oder mittlere Systeme (bis zu 500 000 Codezeilen) mit relativ kurzer Lebensdauer stellt meines Erachtens eine evolutionäre Entwicklung den besten Ansatz dar. Bei großen Systemen mit einer langen Lebensdauer werden die Probleme der evolutionären Entwicklung schnell akut. Für diese Systeme schlage ich einen gemischten Ansatz vor, der die besten Eigenschaften des Wasserfall-Modells und des evolutionären Entwicklungsmodells vereinigt. Ein solcher Prozess könnte bedeuten, dass mit Hilfe der evolutionären Entwicklung ein Wegwerf-Prototyp hergestellt wird, um Unklarheiten in den Systemspezifikationen zu beseitigen. Dann könnte das System unter Verwendung einer strukturierten Methode neu implementiert werden. Die Teile des Systems, die eindeutig sind, können mit Hilfe des Wasserfall- Modells spezifiziert und entwickelt werden, während für andere, schwerer im Voraus zu spezifizierende Teile des Systems wie der Benutzeroberfläche ein erforschender Programmieransatz zum Einsatz kommen sollte. 3.1.3 Formale Systementwicklung Die Formale Systementwicklung ist ein Ansatz zur Softwareentwicklung, der einiges mit dem Wasserfall-Modell gemeinsam hat, bei dem aber der Entwicklungsprozess auf formalen mathematischen Umwandlungen aufbaut, durch die aus der Systemspezifikation ein ausführbares Programm wird. Dieser Prozess wird in Abbildung 3.3 dargestellt. Der Einfachheit halber habe ich die Iteration in diesem Vorgehensmodell weggelassen. Die wesentlichen Unterschiede zwischen diesem Ansatz und dem Wasserfall-Modell sind: 1. Die Spezifikation der Anforderungen wird zu einer detaillierten, formalen Spezifikation verfeinert, die in einer mathematischen Notation ausgedrückt wird. 2. Der Entwicklungsprozess aus Entwurf, Implementierung und Komponententest wird durch einen Umwandlungsprozess ersetzt, bei dem die formale Spezifikation durch eine Reihe von Umwandlungen in ein äquivalentes Programm umgewandelt wird. Dieser Prozess wird in Abbildung 3.4 gezeigt. Während des Umwandlungsprozesses wird die formale mathematische Darstellung systematisch in eine detailliertere, aber immer noch mathematisch korrekte Darstellung des Systems umgeformt. Jeder Schritt fügt Details hinzu, bis aus der formalen Spezifikation ein äquivalentes Programm geworden ist. Die Umwandlungsergebnisse sind einander so ähnlich, dass kein großer Aufwand betrieben werden muss, um jede einzelne Umwandlung zu verifizieren. Daher kann garantiert werden, dass das Programm eine echte Implementierung der Spezifikation ist, solange keine Fehler bei der Verifikation gemacht wurden. Abbildung 3.3 Formale Systementwicklung Anforderungsdefinition Formale Spezifikation Formale Umwandlung Integration und Systemtest
3.1 Vorgehensmodelle 61 Abbildung 3.4 Formale Umwandlung Formale Umwandlungen T1 T2 T3 T4 Formale Spezifikation R1 R2 R3 Ausführbares Programm P1 P2 P3 P4 Der Vorteil der formalen Umwandlung gegenüber dem Nachweis, dass ein Programm seine Spezifikationen erfüllt, besteht darin, dass der Unterschied zwischen zwei Umwandlungsergebnissen kleiner ist als zwischen einer Spezifikation und einem Programm. Korrektheitsbeweise für Programme sind sehr lang und gerade für große Systeme unpraktisch. Ein Umwandlungsprozess, der aus einer Abfolge von kleineren Schritten besteht, ist leichter zu überblicken. Auszuwählen, welche Umwandlung als nächste vorgenommen wird, ist jedoch eine anspruchsvolle Aufgabe, und es ist schwer, die Übereinstimmung zwischen den einzelnen Ergebnissen zu beweisen. Das bekannteste Beispiel für diesen formalen Entwicklungsprozess ist der Cleanroom-Prozess 1, der ursprünglich von IBM entwickelt wurde (Mills et al., 1987; Selby et al., 1987, Linger, 1994; Prowell et al., 1999). Der Cleanroom-Prozess beruht auf der schrittweisen Entwicklung der Software, wobei die Korrektheit jeder Phase nach ihrer Entwicklung durch einen formalen Ansatz bewiesen wird. In diesem Prozess gibt es keine Fehlertests, und die Systemtests konzentrieren sich auf die Zuverlässigkeit des Systems. Ich werde dies in Kapitel 19 besprechen. Sowohl der Cleanroom-Ansatz als auch ein anderer Ansatz der formalen Entwicklung, der auf der B-Methode basiert (Wordsworth, 1996), sind erfolgreich angewendet worden. Die ausgelieferten Systeme wiesen kaum Fehler auf und die Entwicklungskosten unterschieden sich nicht wesentlich von denen anderer Ansätze. Dieser Ansatz ist besonders für Systeme mit strengen Sicherheits- und Zuverlässigkeitsanforderungen geeignet. Der formale Ansatz erleichtert es den Entwicklern, einen Sicherheitsfall herzustellen, der dem Kunden oder Zertifikationsstellen beweist, dass das System tatsächlich die Anforderungen an die Betriebssicherheit und den Zugriffsschutz erfüllt. Außerhalb dieser speziellen Gebiete werden Prozesse, die auf formalen Umwandlungen basieren, nicht sehr oft eingesetzt. Sie erfordern Fachkenntnisse, bieten aber in der Praxis im Vergleich mit anderen Ansätzen keine nennenswerten Vorteile in Bezug auf Kosten oder Qualität. Der Hauptgrund dafür ist, dass die Interaktion zwischen Systemen kaum in eine formale Spezifikation passt, diese aber in den meisten Softwaresystemen einen großen Teil des Entwicklungsaufwands darstellt. 1 Cleanroom = Reinstraum, ein Fabrikationsraum mit kontrollierten Bedingungen bzgl. Temperatur, Staub, Luftbewegung.
62 Kapitel 3 Softwareprozesse 3.1.4 Wiederverwendungsorientierte Entwicklung In einem Großteil aller Softwareprojekte wird Software wiederverwendet. Normalerweise passiert dies informell, wenn die Mitarbeiter eines Projekts von einem Entwurf oder von Code wissen, der dem ähnelt, den sie brauchen. Sie suchen ihn heraus, verändern ihn nach ihren Bedürfnissen und bauen ihn in ihr System ein. Innerhalb des evolutionären Ansatzes, der in Abschnitt 3.1.2 beschrieben wird, wird Wiederverwendung als absolut notwendig für die schnelle Systementwicklung angesehen. Diese informelle Wiederverwendung findet unabhängig von dem Softwareprozess statt, der angewendet wird. In den letzten Jahren hat sich jedoch mit dem komponentenbasierten Software Engineering ein Entwicklungsansatz herauskristallisiert, der sich auf die Wiederverwendung stützt und immer mehr Anhänger findet. Dieser wiederverwendungsorientierte Ansatz beruht auf einer großen Menge wiederverwendbarer Softwarekomponenten, auf die zugegriffen werden kann, und auf einem Integrationsrahmen für diese Komponenten. Manchmal handelt es sich bei diesen Komponenten um eigenständige käufliche Systeme, die benutzt werden können, um eine spezielle Funktion beizusteuern, wie zum Beispiel Textformatierung, numerische Berechnungen usw. Das allgemeine Prozessmodell für die wiederverwendungsorientierte Entwicklung zeigt Abbildung 3.5. Abbildung 3.5 Wiederverwendungsorientierte Entwicklung Anforderungsspezifikation Analyse der Komponenten Anpassung der Anforderungen Systementwurf mit Wiederverwendung Entwicklung und Integration Systemvalidierung Obwohl die erste Phase der Anforderungsspezifikation und die Validierungsphase auch in anderen Prozessen vorkommen, sind die Zwischenstufen in einem wiederverwendungsorientierten Prozess andere: 1. Analyse der Komponenten: Auf der Basis der Anforderungsspezifikation wird nach Komponenten gesucht, mit denen diese Spezifikation implementiert werden kann. Meistens gibt es keine genaue Übereinstimmung, so dass die verwendeten Komponenten nur einen Teil der erforderlichen Funktionen zur Verfügung stellen. 2. Anpassung der Anforderungen: In dieser Phase werden die Anforderungen im Hinblick auf die gefundenen Komponenten analysiert und an diese Komponenten angepasst. Sollten Veränderungen nicht möglich sein, muss der Prozess wieder in die Phase der Komponentenanalyse eintreten, um nach alternativen Lösungen zu suchen. 3. Systementwurf mit Wiederverwendung: In dieser Phase wird der Rahmen für das System entworfen oder ein vorhandener Rahmen wiederverwendet. Die Entwickler betrachten die wiederverwendeten Komponenten und legen den Rahmen so an, dass er dazu passt. Wenn keine wiederverwendbaren Komponenten vorhanden sind, muss an dieser Stelle eventuell neue Software entworfen werden.
3.2 Prozesswiederholung 63 4. Entwicklung und Integration: Die Software, die nicht zur Wiederverwendung zur Verfügung steht, wird entwickelt und zusammen mit den anderen Komponenten und den käuflichen Systemen integriert. Die Systemintegration kann in diesem Modell auch Teil des Entwicklungsprozesses sein und muss nicht als eigenständiger Vorgang auftreten. Das wiederverwendungsorientierte Modell hat den offensichtlichen Vorteil, dass es die Menge an zu entwickelnder Software und somit auch die Kosten und Risiken verringert. Kompromisse bei den Anforderungen sind jedoch unvermeidbar, und das kann zu einem System führen, das die wirklichen Bedürfnisse des Benutzers nicht erfüllt. Außerdem geht ein Teil der Kontrolle über die Weiterentwicklung des Systems verloren, da sich neue Versionen wiederverwendeter Komponenten der Kontrolle der Organisation entziehen, die sie benutzt. 3.2 Prozesswiederholung Alle genannten Vorgehensmodelle haben ihre Vor- und Nachteile. Für die meisten großen Systeme müssen verschiedene Ansätze für unterschiedliche Teile des Systems benutzt werden, so dass ein gemischtes Modell angebracht ist. Außerdem müssen Prozesswiederholungen möglich sein, wo immer Teile des Prozesses wegen sich ändernder Systemanforderungen zu wiederholen sind. Die Arbeit, die bereits für den Entwurf und die Implementierung des Systems aufgewendet wurde, muss noch einmal geleistet werden, um die veränderten Anforderungen zu erfüllen. In diesem Abschnitt werde ich mich mit zwei gemischten (hybriden) Modellen beschäftigen, die verschiedene Entwicklungsansätze unterstützen und die ausdrücklich entworfen wurden, um Prozesswiederholungen zu unterstützen: 1. Die inkrementelle Entwicklung, bei der Spezifikation, Entwurf und Implementierung der Software in eine Folge von Erweiterungen zerlegt werden, deren Durchführung nacheinander erfolgt 2. Die spiralförmige Entwicklung, bei der sich die Entwicklung spiralförmig von innen nach außen bzw. von einem groben Entwurf zum fertigen System bewegt Das Wesentliche bei wiederholten Prozessen ist, dass die Spezifikation zusammen mit der Software entwickelt wird. Das steht jedoch im Widerspruch zu den Beschaffungsmodellen vieler Organisationen, in denen eine vollständige Systemspezifikation Teil des Vertrages ist. Bei einem inkrementellen Ansatz gibt es jedoch so lange keine vollständige Systemspezifikation, bis die letzte Erweiterung spezifiziert ist. Das erfordert eine neue Art von Vertrag, dem sich große Kunden wie Behörden nur schwer anpassen können. 3.2.1 Inkrementelle Entwicklung Das Wasserfall-Modell verlangt von den Kunden, sich auf eine Menge von Anforderungen festzulegen, noch bevor der Entwurf begonnen hat, und der Entwickler muss sich vor der Implementierung auf bestimmte Entwurfsstrategien festlegen. Während der Entwicklung Veränderungen an den Anforderungen vorzunehmen, kann bedeuten, dass die Anforderungen, der Entwurf und die Implementierung überarbeitet werden müssen. Die Vorteile des Wasserfall-Modells sind die einfache Verwaltung und eine klare Trennung von Entwurf und Implementierung, aus der robuste Systeme hervorgehen sollten, die sich bei Veränderungen gut anpassen lassen. Im Gegensatz dazu erlaubt es ein evolutionärer Ansatz, Entscheidungen über Anforderungen und Entwurf zu verschieben, aber er kann auch zu Software führen, die schlecht strukturiert und schwer zu verstehen und zu warten ist. Die inkrementelle Entwicklung ist ein Ansatz, der zwischen diesen beiden Modellen liegt und ihre Vorteile kombiniert.
64 Kapitel 3 Softwareprozesse Der inkrementelle Ansatz der Softwareentwicklung (Abbildung 3.6) wurde von Mills (Mills et al., 1980) als ein Mittel vorgeschlagen, den Überarbeitungsaufwand innerhalb des Entwicklungsprozesses zu reduzieren und den Kunden die Möglichkeit zu geben, Entscheidungen über detaillierte Anforderungen zu verschieben, bis sie ein wenig Erfahrung mit dem System gesammelt haben. Abbildung 3.6 Inkrementelle Entwicklung Grobe Definition der Anforderungen Zuordnung der Anforderungen zu Subsystemen Entwurf der Systemarchitektur Entwicklung einer Systemerweiterung Validierung der Erweiterung Integration der Erweiterung Validierung des Systems Fertiges System System unvollständig In einem inkrementellen Entwicklungsprozess entscheiden die Kunden im Groben, welche Leistungen das System zur Verfügung stellen soll. Sie legen fest, welche Leistungen ihnen am wichtigsten und welche unwichtig sind. Dann wird eine Anzahl von lieferbaren Teilsystemen und Erweiterungen vereinbart, wobei jede Erweiterung eine Teilmenge der Funktionen des Systems stellt. Die Dienste mit der höchsten Priorität werden zuerst an den Kunden geliefert. Sobald die Teilsysteme festgelegt sind, werden die Anforderungen für die im ersten Teilsystem bereitzustellenden Dienste im Detail definiert und dann mit Hilfe des geeignetsten Entwicklungsprozesses implementiert. Während dieser Entwicklungsarbeit können die Anforderungen für die Erweiterungen analysiert werden, Veränderungen am aktuellen Teil sind jedoch nicht mehr möglich. Sobald ein Teilsystem fertiggestellt und ausgeliefert wurde, kann der Kunde es zum Einsatz bringen. Das bedeutet, dass er bereits zu einem sehr frühen Zeitpunkt über einen Teil der Systemfunktionalität verfügen kann. Er kann die Funktionen ausprobieren und auf diese Weise Anforderungen für spätere Erweiterungen oder spätere Versionen des aktuellen Teilsystems ausarbeiten. Wenn neue Erweiterungen fertig gestellt wurden, werden sie in die bereits vorhandenen Teilsysteme integriert, so dass die Funktionalität des Systems sich mit jeder neuen Erweiterung verbessert. Die grundlegenden Funktionen des Systems können schon sehr früh innerhalb des Prozesses oder nach und nach implementiert werden, wann immer sie innerhalb einer Erweiterung erforderlich sind. Es ist nicht nötig, für die Entwicklung aller Erweiterungen denselben Prozess zu benutzen. Wenn die Dienste eines Teilsystems wohl definiert sind, kann für dieses System das Wasserfall- Modell benutzt werden. Ist die Spezifikation hingegen noch unklar, könnte das evolutionäre Modell zum Einsatz kommen. Dieser inkrementelle Entwicklungsprozess hat eine Reihe von Vorteilen: 1. Die Kunden brauchen nicht zu warten, bis das vollständige System geliefert wird, bevor sie es nutzen können. Das erste Teilsystem erfüllt ihre wichtigsten Anforderungen, so dass die Software sofort genutzt werden kann.
3.2 Prozesswiederholung 65 2. Die Kunden können frühe Teilsysteme als eine Art Prototyp benutzen und Erfahrungen sammeln, die in die Anforderungen für spätere Erweiterungen einfließen. 3. Das Risiko, dass das Projekt fehlschlägt, ist wesentlich geringer. Auch wenn in einigen Teilsystemen Probleme auftreten, ist es wahrscheinlich, dass andere erfolgreich an den Kunden ausgeliefert werden können. 4. Da die Funktionen mit der höchsten Priorität zuerst ausgeliefert werden, ist es unvermeidlich, dass diese wichtigen Systemfunktionen am intensivsten getestet werden. Das bedeutet, dass in den wichtigsten Teilen des Systems wahrscheinlich keine Softwareausfälle auftreten werden. Es gibt bei der inkrementellen Entwicklung jedoch auch einige Probleme. Die Teilsysteme sollten relativ klein sein (nicht mehr als 20000 Codezeilen) und jedes einzelne sollte eine bestimmte Systemfunktion liefern. Es kann sich also als schwierig erweisen, die Bedürfnisse des Kunden auf Teilsysteme der richtigen Größe abzubilden. Außerdem verlangen die meisten Systeme eine Anzahl grundlegender Funktionen, die von verschiedenen Teilen des Systems benutzt werden. Da die Anforderungen nicht detailliert festgelegt werden, bevor ein Teilsystem implementiert werden soll, ist es schwer, Funktionen zu erkennen, die alle Teile des Systems brauchen. Seit kurzem gibt es eine Weiterentwicklung dieses inkrementellen Ansatzes, die Extrem- Programmierung genannt wird (Beck, 1999). Diese basiert auf der Entwicklung und Auslieferung sehr kleiner Teilsysteme, der Einbeziehung des Kunden in den Prozess, der ständigen Verbesserung des Codes und der egolosen Programmierung, wie sie in Kapitel 23 erläutert wird. Becks Artikel beschreibt mehrere erfolgreiche Anwendungen dieses Ansatzes, aber es ist noch zu früh vorauszusagen, ob er zu einer weit verbreiteten Richtung in der Softwareentwicklung wird. 3.2.2 Spiralförmige Entwicklung Zu den derzeit bekanntesten Modellen eines Softwareprozesses gehört das Spiralmodell (Abbildung 3.7), das ursprünglich von Boehm (1988) vorgeschlagen wurde. Anstatt den Softwareprozess als eine Folge von Aktivitäten mit Rückwärtsbezügen von einer Aktivität zur anderen darzustellen, wird der Softwareprozess als eine Spirale veranschaulicht. Jede Windung der Spirale steht für eine Phase des Prozesses. So beschäftigt sich die innere Windung mit der Machbarkeit des Systems, die nächste mit der Definition der Systemanforderungen, die folgende mit dem Systementwurf usw. Jede Windung der Spirale ist in vier Segmente aufgeteilt: 1. Ziele aufstellen: Hier werden spezielle Ziele für diese Phase des Projekts definiert. Randbedingungen, denen der Prozess oder das Produkt unterliegt, werden bestimmt und es wird ein detaillierter Managementplan erstellt. Die Projektrisiken werden aufgelistet. Abhängig von diesen Risiken können alternative Strategien geplant werden. 2. Risiken einschätzen und verringern: Jedes der erkannten Projektrisiken wird intensiv analysiert, und es werden Schritte unternommen, um die Risiken zu verringern. Wenn zum Beispiel das Risiko besteht, dass die Anforderungen nicht angemessen sind, könnte ein Prototyp des Systems entwickelt werden. 3. Entwicklung und Validierung: Nach der Auswertung der Risiken wird ein Entwicklungsmodell ausgewählt. Wenn zum Beispiel die Risiken vor allem bei der Benutzeroberfläche liegen, wäre die evolutionäre Herstellung eines Prototyps ein angemessenes Entwicklungsmodell. Wenn Sicherheitsrisiken die Hauptsorge sind, wäre aber zum Beispiel eine Entwicklung mit Hilfe formaler Umformungen am besten. Das Wasserfall-Modell ist wahrscheinlich angebracht, wenn das größte erkannte Risiko die Integration von Subsystemen ist.
66 Kapitel 3 Softwareprozesse 4. Planung: Das Projekt wird überprüft, und es wird entschieden, ob mit der nächsten Windung der Spirale weitergemacht werden kann. Entscheidet man sich für diesen Schritt, werden Pläne für die nächste Phase aufgestellt. Abbildung 3.7 Das Boehm sche Spiralmodell des Softwareprozesses ( 1988 IEEE) Ziele, Alternativen und Randbedingungen feststellen Alternativen auswerten Risiken bestimmen und auflösen Nächste Phase planen REVIEW Anforderungsplan Plan des Lebenszyklus Entwicklungsplan Pläne für Integration und Tests Risikoanalyse Risikoanalyse Risikoanalyse Risikoanalyse Prototyp 1 Prototyp 2 Betriebskonzept SW- Anforderungen Entwurf V&V Akzeptanztest Wartung Prototyp 3 Funktionsfähiger Prototyp (Simulationen, Modelle, Benchmarks) Anforderungsvalidierung Produktentwurf Detailentwurf Code Komponententest Integrationstest Produkt der nächsten Ebene entwickeln und verifizieren Ein wichtiger Unterschied zwischen dem Spiralmodell und anderen Vorgehensmodellen ist die ausdrückliche Betrachtung der Risiken im Spiralmodell. Einfach ausgedrückt ist ein Risiko etwas, das schief gehen kann. Wenn zum Beispiel eine neue Programmiersprache benutzt werden soll, besteht das Risiko, dass die verfügbaren Compiler unzuverlässig sind oder keinen ausreichend effizienten Objektcode generieren. Risiken führen zu Problemen mit dem Projekt, wie Terminüberschreitungen und höhere Kosten. Daher ist die Verringerung der Risiken eine wichtige Aktivität im Projektmanagement. In Kapitel 4, das sich mit Projektmanagement beschäftigt, erläutere ich Risiken und Risikomanagement im Detail. Ein Spiralenzyklus beginnt mit der Festlegung von Zielen wie Leistungsfähigkeit, Funktionalität usw. Dann werden alternative Wege zu diesen Zielen und die damit zusammenhängenden Beschränkungen durchnummeriert. Jede Alternative wird mit jedem Ziel verglichen. Das endet normalerweise in der Erkennung von Stellen, an denen Projektrisiken auftreten könnten. Der nächste Schritt besteht darin, diese Risiken zum Beispiel durch eine detaillierte Analyse, das Erstellen von Prototypen und das Durchführen von Simulationen auszuwerten. Sobald die Risiken ausgewertet wurden, wird ein Stück weit entwickelt und danach die nächste Phase des Prozesses geplant.
3.3 Softwarespezifikation 67 Im Spiralmodell gibt es keine festen Phasen wie Spezifikation oder Entwurf. Vielmehr umfasst es andere Prozessmodelle. In einer Phase könnten Prototypen verwendet werden, um Unklarheiten in den Anforderungen zu beseitigen und so bestimmte Risiken zu verringern. Dann könnte eine konventionelle Wasserfall-Entwicklung folgen und schließlich eine formale Umformung durchgeführt werden, um die Teile des Systems zu entwickeln, an die hohe Sicherheitsanforderungen gestellt werden. 3.3 Softwarespezifikation In diesem und den folgenden drei Abschnitten werde ich die grundlegenden Aktivitäten der Spezifikation, Entwicklung, Validierung und Weiterentwicklung von Software erläutern. Die erste dieser vier Aktivitäten, die Softwarespezifikation, soll festlegen, welche Funktionen von dem System verlangt werden und welchen Beschränkungen der Betrieb und die Entwicklung des Systems unterliegen. Dieser Ablauf wird mittlerweile auch als Anforderungsanalyse (oder Requirements Engineering) bezeichnet. Die Anforderungsanalyse ist eine besonders kritische Phase des Softwareprozesses, da Fehler unweigerlich zu späteren Problemen beim Entwurf und der Implementierung des Systems führen. Der Prozess der Anforderungsanalyse wird in Abbildung 3.8 gezeigt. Dieser Prozess führt zur Erstellung eines Anforderungsdokuments, das die Spezifikation des Systems darstellt. Die Anforderungen werden in diesem Dokument normalerweise auf zwei Detailstufen dargestellt. Die Benutzer und Kunden brauchen eine grobe Aufstellung der Anforderungen, während die Systementwickler eine detailliertere Systemspezifikation benötigen. Abbildung 3.8 Ablauf der Anforderungsanalyse Bestimmung und Analyse der Anforderungen Spezifikation der Anforderungen Die Anforderungsanalyse besteht aus vier wesentlichen Phasen: 1. Die Durchführbarkeitsstudie: Es wird abgeschätzt, ob es möglich ist, die Bedürfnisse des Benutzers mit Hilfe aktueller Software- und Hardwaretechnologien zu erfüllen. Die Studie wird entscheiden, ob das vorgeschlagene System vom geschäftlichen Standpunkt aus kos- Durchführbarkeitsstudie Durchführbarkeitsbericht Validierung der Anforderungen Systemmodelle Benutzer- und Systemanforderungen Pflichtenheft
68 Kapitel 3 Softwareprozesse teneffektiv ist bzw. ob es innerhalb der Budget-Beschränkungen entwickelt werden kann. Eine Durchführbarkeitsstudie sollte relativ schnell und kostengünstig erstellt werden. Das Ergebnis sollte die Entscheidung ermöglichen, ob eine detailliertere Analyse sinnvoll ist. 2. Bestimmung und Analyse der Anforderungen: In dieser Phase werden die Systemanforderungen aus der Beobachtung bestehender Systeme, Diskussionen mit potenziellen Benutzern und Käufern, der Aufgabenanalyse usw. abgeleitet. Dazu kann die Entwicklung eines oder mehrerer unterschiedlicher Systemmodelle und Prototypen gehören. Sie helfen dem Analytiker, das zu spezifizierende System besser zu verstehen. 3. Die Spezifikation der Anforderungen: Dies ist der Prozess, in dem die während der Analyse gesammelten Informationen in ein Dokument umgesetzt werden, das einen Satz von Anforderungen definiert. In dieses so genannte Pflichtenheft können zwei Arten von Anforderungen aufgenommen werden. Benutzeranforderungen sind abstrakte Beschreibungen der Systemanforderungen für den Kunden und den Benutzer, während es sich bei den eigentlichen Systemanforderungen um eine detailliertere Auflistung der Funktionen handelt, die zur Verfügung gestellt werden sollen. 4. Validierung der Anforderungen: Diese Aktivität prüft, ob die Anforderungen realistisch, konsistent und vollständig sind. Während dieses Prozesses werden Fehler im Anforderungsdokument unweigerlich erkannt. Es muss dann verändert werden, um diese Probleme zu korrigieren. Natürlich werden die Abläufe innerhalb des Anforderungsprozesses nicht einfach nacheinander ausgeführt. Die Analyse der Anforderungen wird während der Definition und der Spezifikation weitergeführt, und dabei kommen oft neue Anforderungen zum Vorschein. Daher sind die Analyse, die Definition und die Spezifikation eng miteinander verknüpft. 3.4 Softwareentwurf und -implementierung Die Implementierungsphase der Softwareentwicklung ist ein Prozess, in dem die Systemspezifikation in ein ausführbares System umgewandelt wird. Zur Implementierung gehören stets auch Entwurfs- und Programmieraktivitäten, doch wenn ein evolutionärer Ansatz benutzt wird, kann mitunter auch eine Verfeinerung der Softwarespezifikation vorgenommen werden. Ein Softwareentwurf ist eine Beschreibung der Struktur der zu implementierenden Software, der Systemdaten, der Schnittstellen zwischen den Systemkomponenten und manchmal der verwendeten Algorithmen. Die Entwickler stellen nicht sofort einen fertigen Entwurf auf, sondern entwickeln diesen Entwurf iterativ über verschiedene Versionen. Während dieses Prozesses wird der Entwurf formalisiert und um Details erweitert, wobei ständig korrigierend auf frühere Entwürfe zurückgegriffen wird. Beim Entwurf kann es notwendig sein, mehrere Modelle des Systems auf verschiedenen Abstraktionsebenen zu entwickeln. Wenn ein Entwurf in immer kleinere Teile zerlegt wird, fallen Fehler und Lücken in den vorherigen Phasen auf. Diese Rückmeldungen erlauben es, frühere Entwurfsmodelle zu verbessern. Abbildung 3.9 zeigt ein Modell dieses Prozesses, das veranschaulicht, wie die Entwurfsbeschreibungen in den verschiedenen Phasen des Systems erstellt werden. Dieses Diagramm suggeriert, dass die Phasen des Entwurfsprozesses nacheinander stattfinden. Tatsächlich sind die Aktivitäten innerhalb des Entwurfsprozesses jedoch miteinander verwoben. Rückmeldungen von einer Phase zur anderen und die daraus folgende Überarbeitung des Entwurfs sind bei allen Entwurfsprozessen unvermeidbar. Das Ergebnis jeder Entwurfsaktivität stellt zugleich die Spezifikation für die nächste Phase dar. Diese Spezifikation kann eine abstrakte, formale Beschreibung sein, die die Anforderun-
3.4 Softwareentwurf und -implementierung 69 Abbildung 3.9 Ein allgemeines Modell des Entwurfsprozesses Spezifikation der Anforderungen Entwurfsaktivitäten Abstrakte Spezifikation Entwurf der Datenstrukturen Architekturentwurf Schnittstellenentwurf Komponentenentwurf Algorithmenentwurf Spezifikation der Datenstrukturen Systemarchitektur Softwarespezifikation Schnittstellenspezifikation Komponentenspezifikation Algorithmenspezifikation Entwurfsergebnisse gen verdeutlichen soll, oder sie kann beschreiben, wi bestimmte Teile des Systems umzusetzen sind. Je weiter sich der Entwurfsprozess voran bewegt, desto detaillierter werden die Spezifikationen. Das Endergebnis des Prozesses sind genaue Spezifikationen der zu implementierenden Algorithmen und Datenstrukturen. Die einzelnen Aktivitäten im Entwurfsprozess sind: 1. Architekturentwurf: Hier werden die das System bildenden Subsysteme und ihre Beziehungen bestimmt und dokumentiert. Dieses wichtige Thema wird in Kapitel 10 behandelt. 2. Abstrakte Spezifikation: Für jedes Teilsystem wird eine abstrakte Spezifikation erstellt, die die Funktionen und die Randbedingungen beschreibt, unter denen das Subsystem eingesetzt werden soll. 3. Schnittstellenentwurf: Für jedes Subsystem muss die Schnittstelle zu den anderen Subsystemen entworfen und dokumentiert werden. Diese Schnittstellenspezifikation muss absolut eindeutig sein, weil die Subsysteme auf diese Weise benutzt werden können, ohne dass die genaue Funktion des Subsystems bekannt sein muss. In dieser Phase können auch Methoden zur formalen Spezifikation eingesetzt werden, die Gegenstand von Kapitel 9 sind. 4. Komponentenentwurf: Bei diesem Schritt werden den verschiedenen Komponenten die jeweiligen Dienste zugeteilt und die Komponentenschnittstellen entworfen. 5. Entwurf der Datenstrukturen: Hier werden die Datenstrukturen ausgearbeitet und spezifiziert, die innerhalb des Systems benutzt werden sollen. 6. Algorithmenentwurf: Bei diesem Schritt werden Detailentwürfe und Spezifikationen der Algorithmen erstellt, die zur Bereitstellung der Dienste verwendet werden sollen. Dies ist ein sehr allgemeines Modell des Entwurfsprozesses, das in der Praxis oft angepasst werden muss. So könnten die letzten beiden Phasen, der Entwurf von Datenstrukturen und Algorithmen, Teil des Entwurfs- oder aber der Implementierungsphase sein. Wenn wiederverwendbare Objekte vorhanden sind, kann dies die Architektur des Systems und die Schnittstellen der Systemmodule beeinflussen. Es könnte bedeuten, dass sich die Anzahl der zu entwerfenden Komponenten erheblich verringert. Außerdem könnte ein erforschender Entwurfsansatz zum Einsatz kommen oder der Schnittstellenentwurf erst nach der Spezifikation der Datenstrukturen erfolgen.
70 Kapitel 3 Softwareprozesse 3.4.1 Entwurfsmethoden In vielen Projekten zur Softwareentwicklung ist der Softwareentwurf immer noch ein Ad-hoc- Prozess. Beginnend mit einer Menge von Anforderungen, häufig in natürlicher Sprache, wird ein informeller Entwurf hergestellt. Dann beginnt die Programmierung und der Entwurf wird verändert, während das System implementiert wird. Es gibt kaum oder nur wenig formales Änderungs- oder Entwurfsmanagement. Wenn die Implementierungsphase beendet ist, hat sich der Entwurf gegenüber der ersten Spezifikation normalerweise so sehr verändert, dass das ursprüngliche Entwurfsdokument eine inkorrekte und unvollständige Beschreibung des Systems ist. Ein methodischerer Ansatz des Softwareentwurfs wird von den strukturierten Methoden verfolgt, die sich aus einer Anzahl von Notationen und Richtlinien für den Softwareentwurf zusammensetzen. Zu den Beispielen für strukturierte Methoden gehören der strukturierter Entwurf (Constantine und Yourdon, 1979), die strukturierte Systemanalyse (Gane und Sarson, 1979), Jackson System Development (Jackson, 1983) und verschiedene Ansätze der objektorientierten Entwicklung (Robinson, 1992; Booch, 1994, Rumbaugh et al., 1991; Booch et al., 1999; Rumbaugh et al., 1999a, 1999b). Die Benutzung strukturierter Methoden umfasst normalerweise das Erstellen grafischer Systemmodelle und das Anfertigen großer Mengen an Entwurfsdokumentation. Es sind CASE-Werkzeuge (siehe Abschnitt 3.7) entwickelt worden, um bestimmte Methoden zu unterstützen. Strukturierte Methoden sind bereits in vielen großen Projekten erfolgreich zur Anwendung gekommen. Sie können eine erhebliche Kostensenkung bewirken, weil sie Standardnotationen benutzen und dafür sorgen, dass standardisierte Entwurfsdokumentation hergestellt wird. Keine Methode ist merklich besser oder schlechter als die andere. Der Erfolg oder Misserfolg von Methoden hängt oft davon ab, ob sie für die Gebiete geeignet sind, auf denen sie eingesetzt werden. Eine strukturierte Methode umfasst ein Modell des Entwurfsprozesses, Notationen zur Darstellung des Entwurfs, Berichtsformate, Regeln und Entwurfsrichtlinien. Obwohl es eine große Anzahl von Methoden gibt, haben sie viel gemeinsam. Strukturierte Methoden können einige oder alle der folgenden Modelle eines Systems unterstützen: 1. Ein Datenflussmodell, in dem das System anhand der während seiner Ausführung stattfindenden Datenumwandlungen beschrieben wird. 2. Ein so genanntes Entity-Relationship-Modell, das benutzt wird, um die Grundeinheiten des Systems und die Beziehungen zwischen ihnen zu beschreiben. Entity-Relationship-Modelle sind die gängige Technik, um Datenbankstrukturen zu beschreiben. 3. Ein strukturelles Modell, in dem die Systemkomponenten und ihre Interaktionen dokumentiert werden. 4. Objektorientierte Methoden umfassen ein Vererbungsmodell des Systems, Modelle der statischen und dynamischen Beziehungen zwischen Objekten und ein Modell davon, wie die Objekte zusammenspielen, wenn das System ausgeführt wird. Bestimmte Methoden ergänzen diese mit zusätzlichen Systemmodellen, wie zum Beispiel Zustandsdiagrammen, Entity-Lebensläufe, welche die Phasen zeigen, die jedes Objekt durchläuft usw. Die meisten Methoden schlagen die Benutzung eines zentralen Speichers für Systeminformationen oder eines Data Dictionary vor. Ich werde eine Anzahl von Ansätzen der Systemmodellierung in Kapitel 7 besprechen. In der Praxis ist die Anleitung, die diese Methoden geben, eher informell, so dass verschiedene Entwickler unterschiedliche Entwürfe erstellen werden. Die Methoden sind in Wirklichkeit Standardnotationen und die Verkörperung guter Entwicklungspraxis. Indem man sie anwendet und die Richtlinien beachtet, sollte man einen vernünftigen Entwurf erstellen kön-
3.4 Softwareentwurf und -implementierung 71 nen. Die Kreativität des Entwicklers ist immer noch gefordert, wenn es um die Zerlegung des Systems oder darum geht, sicherzustellen, dass der Entwurf die Spezifikationen angemessen widerspiegelt. Empirische Studien über Entwickler (Bansler und Bødker, 1993) haben gezeigt, dass sie sich selten ganz eng an Methoden halten. Sie suchen sich bestimmte Richtlinien aus und tragen dabei den lokalen Umständen Rechnung. 3.4.2 Programmierung und Fehlerbehebung Wenn ein System implementiert werden soll, folgt die Entwicklung eines Programms ganz natürlich aus dem Systementwurfsprozess. Obwohl einige Klassen von Programmen wie sicherheitsrelevante Systeme detailliert entworfen werden, bevor die Implementierung beginnt, kommt es häufiger vor, dass die späteren Phasen des Entwurfs und der Programmentwicklung verknüpft werden. So können CASE-Werkzeuge zum Einsatz kommen, um aus einem Entwurf ein Programmgerüst zu erzeugen. Dabei müssen Schnittstellen definiert und implementiert werden, und in vielen Fällen braucht der Programmierer nur Details der Funktionen jeder Programmkomponente beizusteuern. Die Programmierung ist eine individuell gestaltete Aktivität, und es gibt keinen allgemeinen Prozess, der normalerweise ausgeführt wird. Manche Programmierer fangen mit Komponenten an, die sie bereits vollständig verstehen, entwickeln diese und gehen dann zu weniger eindeutigen Komponenten über. Andere gehen den entgegengesetzten Weg und heben sich bekannte Komponenten bis zuletzt auf, weil sie wissen, wie sie entwickelt werden. Einige Entwickler definieren ihre Daten gerne so früh wie möglich und benutzen sie, um die Programmentwicklung voranzutreiben, während andere die Daten so lange wie möglich unspezifiziert lassen. Abbildung 3.10 Ablauf der Fehlerbehebung Fehler finden Fehlerbehebung entwerfen Fehler beheben Programm erneut testen Normalerweise testen die Programmierer den von ihnen entwickelten Code zumindest oberflächlich selbst. Das enthüllt oft Fehler im Programm, die korrigiert werden müssen. Dies wird Fehlerbehebung (debugging) genannt. Fehlertest und Fehlerbehebung sind zwei verschiedene Prozesse. Die Fehlertests stellen das Vorhandensein von Fehlern fest, wohingegen sich die Fehlerbehebung damit beschäftigt, diese Fehler zu finden und zu entfernen. Abbildung 3.10 zeigt einen möglichen Ablauf der Fehlerbehebung. Fehler im Code müssen gefunden und das Programm muss so angepasst werden, dass es seine Anforderungen erfüllt. Anschließend sind die Tests zu wiederholen, um sicherzugehen, dass die Veränderungen richtig vorgenommen wurden. Daher ist der Prozess der Fehlerbehebung sowohl Teil der Softwareentwicklung als auch der Softwaretests. Der Fehler Suchende muss Hypothesen über das sichtbare Verhalten des Programms aufstellen und diese in der Hoffnung testen, den Fehler zu finden, der die Unregelmäßigkeit in der Ausgabe verursacht hat. Das Testen von Hypothesen kann bedeuten, dass der Programmcode von Hand überprüft werden muss. Mitunter müssen auch neue Testfälle aufgestellt werden,