Sommerville_Software.Engineering.S.54-83.pdf

Einführungvalidierung, Architekturentwurf, Modultests usw. Sie unterstützen außerdem Prozessaktivitätenwie Dokumentation und die Verwaltung der Softwarekonfiguration.Wenn wir Prozesse beschreiben und diskutieren, dann meinen wir gewöhnlich dieAktivitäten in diesen Prozessen, wie das Spezifizieren eines Datenmodells, das Entwerfeneiner Benutzerschnittstelle usw., sowie die Reihenfolge dieser Aktivitäten.Doch außer Aktivitäten können Prozessbeschreibungen noch Folgendes enthalten:Produkte- das Ergebnis einer Prozessaktivität. Zum Beispiel könnte das Ergebnisder Aktivität des Architekturentwurfs ein Modell der Softwarearchitektur sein.Rollen- spiegeln die Verantwortlichkeiten der Leute wider, die in den Prozesseingebunden sind. Beispiele für Rollen sind Projektmanager, Konfigurationsmanager,Programmierer usw.0 Vor- und Nachbedingungen- Aussagen, die wahr sind, bevor und nachdem eineProzessaktivität durchgeführt oder ein Produkt hergestellt wurde. Beispielsweisekann es vor Beginn des Architekturentwurfs eine Vorbedingung sein, dass alleAnforderungen vom Kunden genehmigt wurden. Nach dem Ende dieser Aktivitätkönnte eine Nachbedingung sein, dass die UML-Modelle zur Beschreibung derArchitektur überprüft wurden.Softwareprozesse sind sehr komplex und, wie alle intellektuellen und kreativen Vorgänge,abhängig von menschlichen Entscheidungen und Urteilsvermögen. Es gibt keinenidealen Prozess und die meisten Unternehmen bzw. Organisationen haben ihreeigenen Softwareentwicklungsprozesse entwickelt. Die Prozesse haben sich so verändert,dass sie die Fähigkeiten der Menschen in einer Organisation und die Eigenschaftender Systeme ausnutzen, die entwickelt werden. Bei einigen Systemen, z. B. kritischenSystemen, ist ein klar strukturierter Entwicklungsprozess erforderlich. BeiGeschäftssystemen, bei denen sich die Anforderungen rasch ändern können, ist einweniger formaler, flexibler Prozess wahrscheinlich effektiver.Manchmal werden Softwareprozesse entweder als plangesteuert oder als agile Prozessekategorisiert. Plangesteuerte Prozesse sind Verfahren, bei denen alle Prozessaktivitätenim Voraus geplant werden und bei denen Fortschritt an diesem Plan gemessenwird. In agilen Prozessen, die ich in Kapitel 3 bespreche, ist das Planen inkrementeilund es ist leichter, den Prozess zu verändern, um die Änderungen der Kundenanforderungenwiderzuspiegeln. Wie Boehm und Thrner (2003) darlegen, ist jeder Ansatzfür unterschiedliche Softwarearten geeignet. In der Regel muss eine Balance zwischenplangesteuerten und agilen Prozessen gefunden werden.Obwohl es keinen "idealen" Softwareprozess gibt, können viele Unternehmen ihrenSoftwareprozess noch deutlich verbessern. Der Prozess beruht mitunter auf veraltetenTechniken oder ignoriert die Vorteile anerkannter Praktiken beim industriellen Software-Engineering.Tatsächlich benutzen viele Unternehmen bei der Entwicklung ihrerSoftware noch immer keinerlei Methoden aus dem Bereich des Software-Engineerings.Die Verbesserung von Softwareprozessen kann einfach durch eine Standardisierungder Prozesse erfolgen, bei der die Vielfalt von Softwareprozessen innerhalb des Unternehmensreduziert wird. Dies führt zu besserer Kommunikation und reduzierterSchulungszeit und macht eine automatisierte Unterstützung der Prozesse bezahlbar.Eine Standardisierung ist auch ein wichtiger erster Schritt bei der Einführung neuerSoftware-Engineering-Methoden und -Techniken. Ich werde in Kapitel26 auf die Verbesserungvon Softwareprozessen zurückkommen.

•Softwareprozesse----------2.1 VergehensmodelleWie ich in Kapitel 1 erläutert habe, handelt es sich bei einem Vorgehensmodell umeine vereinfachte Darstellung eines Softwareprozesses. Jedes Vorgehensmodell stellteinen Prozess aus einer bestimmten Sicht dar und liefert somit nur einen Teil derInformationen über diesen Prozess. Zum Beispiel zeigt ein Prozessaktivitätsmodell dieAktivitäten und ihre Abfolge, aber möglicherweise nicht die Rollen der Personen, diean diesen Aktivitäten beteiligt sind. In diesem Abschnitt führe ich einige sehr allgemeineVorgehensmodelle (auch Prozessparadigmen genannt) ein und stelle sie ausarchitektonischer Sicht vor. Das heißt, wir sehen die Struktur des Prozesses, aberkeine Details über die speziellen Abläufe.Diese allgemeinen Modelle sind keine endgültigen Beschreibungen der Softwareprozesse.Vielmehr sind sie nützliche Abstraktionen des Prozesses, die benutzt werdenkönnen, um verschiedene Ansätze der Softwareentwicklung darzustellen. Sie könnensich diese als Prozessrahmen vorstellen, die erweitert und angepasst werden können,um spezifischere Software-Engineering-Prozesse zu erzeugen.Die Vorgehensmodelle, die ich in diesem Kapitel erläutere, sind:D Das Wasserfallmodell: Dieses Modell stellt die grundlegenden Prozessabläufe wieSpezifikation, Entwicklung, Validierung und Evolution als eigenständige Phasendes Prozesses dar, wie zum Beispiel Anforderungensspezifikation, Softwareentwurf,Implementierung, Tests usw.II Inkrementelle Entwicklung: Dieser Ansatz verknüpft die Aktivitäten der Spezifikation,der Entwicklung und der Validierung. Das System wird als eine Folge vonVersionen (Inkremente) entwickelt, wobei jede Version neue Funktionalität zuder vorherigen hinzufügt.D Wiederverwendungsorientiertes Software-Engineering: Dieses Modell basiert aufder Existenz einer beträchtlichen Anzahl von wiederverwendbaren Komponenten.Der Systementwicklungsprozess beschäftigt sich mehr damit, diese Komponentenin ein System zu integrieren, als damit, neue Komponenten von Grundauf zu entwickeln.Diese Modelle schließen sich nicht gegenseitig aus und werden häufig zusammen verwendet,vor allem bei der Entwicklung großer Systeme. Für große Systeme ist es sinnvoll,einige der besten Eigenschaften des Wasserfallmodells und des Modells derinkrementeilen Entwicklung zu kombinieren. Man benötigt Informationen über diewesentlichen Systemanforderungen, um eine geeignete Softwarearchitektur zu entwerfen.Hier kann man nicht inkrementeil vorgehen. Doch Subsysteme innerhalbeines größeren Systems könnten mit unterschiedlichen Ansätzen entwickelt werden.Teile des Systems, die bereits gut verstanden sind, können mithilfe eines wasserfallbasiertenProzesses spezifiziert und entworfen werden. Die Teile des Systems jedoch,die wie die Benutzerschnittstelle im Voraus schwierig zu spezifizieren sind, solltenimmer unter Benutzung des inkrementeilen Ansatzes entwickelt werden.2.1.1 Das WasserfallmodellDas erste veröffentlichte Modell für die Softwareentwicklung wurde von allgemeinerenEntwicklungsprozessen abgeleitet (Royce, 1970). Dies wird in". Abbildung 2.1 veranschaulicht.Wegen der Kaskade von einer Phase zur nächsten wird dieses Modell

2.1 VorgehensmodelleWasserfallmodell oder der Softwarelebenszyklus genannt. Das Wasserfallmodell istein Beispiel eines plangesteuerten Prozesses- im Prinzip muss man alle Prozessaktivitäteninhaltlich und zeitlich planen, bevor man anfangen kann, an ihnen zu arbeiten.Anforderungs·definitionAbbildung 2.1: Das Wasserfallmode II.Die wichtigen Phasen des Wasserfallmodells spiegeln direkt die grundlegenden Entwicklungsaktivitätenwider:D Analyse und Definition der Anforderungen: Die Dienstleistungen, Einschränkungenund Ziele des Systems werden in Zusammenarbeit mit den Systembenutzernaufgestellt. Dann werden sie detaillierter definiert und dienen so als Systemspezifikationen.D System- und Softwareentwurf: Der Systementwurfsprozess weist die Anforderungenentweder Hard- oder Softwaresystemen zu, indem eine übergeordnete Systemarchitekturfestgelegt wird. Beim Softwareentwurf geht es um das Erkennen undBeschreiben der grundlegenden abstrakten Softwaresysteme und ihrer Beziehungenzueinander.D Implementierung und Modultests: In dieser Phase wird der Softwareentwurfdurch eine Menge von Programmen oder Programmeinheiten umgesetzt. Das Testender Module stellt sicher, dass jede Einheit ihre Spezifikation erfüllt.II Integration und Systemtest: Die einzelnen Programmeinheiten oder Programmewerden integriert und als Ganzes getestet um sicherzustellen, dass die Saftwareanforderungenerfüllt werden. Nach den Tests wird das Softwaresystem anden Kunden ausgeliefert.D Betrieb und Wartung: Normalerweise (aber nicht zwingend) ist dies die längstePhase innerhalb des Lebenszyklus. Das System wird installiert und zum Gebrauchfreigegeben. Zur Wartung gehören das Korrigieren von Fehlern, die in denfrüheren Phasen nicht entdeckt wurden, die Verbesserung der Implementierungvon Systemeinheiten und die Verbesserung des Systems, falls neue Anforderungenaufgedeckt werden.

SoftwareprozesseIm Prinzip gehen aus jeder Phase ein oder mehrere Dokumente hervor, die genehmigtoder abgenommen werden. Die nächste Phase sollte nicht beginnen, bevor nicht dievorherige abgeschlossen wurde. In der Praxis überlappen sich die Phasen und tauschenInformationen untereinander aus. So werden während des Entwurfs Problememit den Anforderungen entdeckt. Während des Programmierans fallen Fehler im Entwurfauf usw. Der Softwareprozess ist kein einfacher linearer Prozess, sondernumfasst Rückkopplungen von einer Phase zur vorherigen. Die in der jeweiligen Phaseerzeugten Dokumente müssen dann eventuell abgewandelt werden, um die vorgenommenenÄnderungen zu reflektieren.Wegen der hohen Kosten bei der Erstellung und Abnahme von Dokumenten könnendie Iterationen von Entwicklungsaktivitäten teuer sein und erhebliche Überarbeitungenverlangen. Daher wird normalerweise nach einer kleinen Anzahl von Wiederholungenein Teil der Entwicklung, zum Beispiel die Spezifikation, eingefroren undeine spätere Entwicklungsstufe angefangen. Probleme werden dabei zurückgestellt,ignoriert oder im Programm umgangen. Dieses verfrühte Einfrieren von Anforderungenkann allerdings bedeuten, dass das System nicht das tun wird, was der Benutzerwill. Es kann auch zu einem schlecht strukturierten System führen, weil Probleme imEntwurf durch Tricks in der Implementierung umgangen werden.Während der letzten Phase des Lebenszyklus (Betrieb und Wartung) wird die Softwarein Betrieb genommen. Dabei werden Fehler und Lücken in den ursprünglichen Anforderungenentdeckt. Es tauchen Programm- und Entwurfsfehler auf und der Bedarf anneuer Funktionalität 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 wiederholtwerden müssen.Das Wasserfallmodell ist konsistent zu anderen Systementwicklungsmodellen underzeugt in jeder Phase Dokumentationen. Dadurch bleibt der Prozess durchschaubar,sodass Manager den Fortschritt gemäß Entwicklungsplan überwachen können. DasHauptproblem ist jedoch die starre Aufteilung des Projekts in verschiedene Phasen.Zu einem frühen Zeitpunkt müssen Verbindlichkeiten eingegangen werden, was esschwer macht, auf neue Anforderungen des Kunden zu reagieren.Im Prinzip sollte das Wasserfallmodell nur Verwendung finden, wenn die Anforderungengut durchdacht sind und es eher unwahrscheinlich ist, dass es während derSystementwicklung zu gravierenden Änderungen kommt. Das Wasserfallmodell spiegeltjedoch die Art von Prozessen wider, die auch in anderen Ingenieurprojekten verwendetwird. Da es einfacher ist, ein gebräuchliches Managementmodell für dasgesamte Projekt zu benutzen, sind noch immer Softwareprozesse, die auf dem Wasserfallmodellbasieren, weitverbreitet.Eine wichtige Variante des Wasserfallmodells ist die formale Systementwicklung,wobei ein mathematisches Modell einer Systemspezifikation erzeugt wird. DiesesModell wird dann mithilfe von mathematischen Transformationen, die konsistenzerhaltendsind, zu ausführbarem Code verfeinert. Unter der Voraussetzung, dass Ihremathematischen Transformationen korrekt sind, können Sie also überzeugende Argumentedafür vorbringen, dass ein so erzeugtes Programm konsistent mit seiner Spezifikationist.Formale Entwicklungsprozesse wie solche, die auf der B-Methode (Schneider, 2001;Wordsworth, 1996) basieren, sind besonders für die Entwicklung von Systemen mitstrengen Betriebssicherheits-, Zuverlässigkeits- und Informationssicherheitsanforde-

2.1 Vorgehensmodellerungen geeignet. Der formale Ansatz erleichtert es den Entwicklern den Nachweis zurBetriebs- und Informationssicherheit zu erstellen. Dies zeigt dem Kunden oder denZertifikationsstellen, dass das System tatsächlich die Anforderungen an die BetriebsoderInformationssicherheit erfüllt.Prozesse, die auf formalen Transformationen basieren, werden im Allgemeinen nur inder Entwicklung von sicherheitskritischen Systemen eingesetzt. Sie erfordern besondereFachkenntnisse. Für den Großteil von Systemen bietet dieser Prozess im Vergleichmit anderen Ansätzen zur Systementwicklung keine nennenswerten Vorteile inBezug auf Kosten oder Qualität.Cleanroom-Software-Engineering•Ein Beispiel für einen formalen Entwicklungsprozess, der ursprünglich von IBM entwickelt wurde,ist der Cleanroom-Prozess. Im Cleanroom-Prozess wird jedes Softwareinkrement formal spezifiziertund diese Spezifikation wird in eine Implementierung umgewandelt. Die Korrektheit derSoftware wird durch einen formalen Ansatz bewiesen. ln diesem Prozess gibt es keine Modultestsund die Systemtests konzentrieren sich auf die Zuverlässigkeit des Systems.Das Ziel des Cleanroom-Prozesses ist die Null-Fehler-Software, sodass ausgelieferte Systeme einenhohen Zuverlässigkeitsgrad haben.http.!lwww.SoftwareEngineering-9. com/Web!CieanroomLink2.1.2 Inkrementeile EntwicklungDie inkrementeHe Entwicklung basiert darauf, eine Anfangsimplementierung zu entwickeln,die Benutzer zu Kommentaren und Hinweisen zu dieser Implementierungaufzufordern und sie über mehrere Versionen hinweg zu verbessern, bis ein angemessenesSystem entstanden ist (~Abbildung 2.2). Die Spezifikation, die Entwicklungund die Validierung werden nicht als separate Abläufe betrachtet, sondern werdengleichzeitig ausgeführt, wobei sie untereinander Rückmeldungen zügig austauschen.gleichzeitig stattfindendeAktivitätengrobeBeschreibungAbbildung 2.2: Inkrementelle Entwicklung.

SoftwareprozesseInkrementelle Softwareentwicklung ist ein fundamentaler Teil des agilen Ansatzes;sie ist besser als ein Wasserfallansatz für die meisten Geschäftsfälle, E-Commerce undindividuellen Systeme geeignet. Inkrementelle Entwicklung bildet die Art und Weiseab, wie wir Problerne lösen. Wir erarbeiten selten eine vollständige Problernlösung imVoraus, sondern bewegen uns schrittweise in Richtung einer Lösung und gehen einenSchritt zurück, wenn wir feststellen, dass wir einen Fehler gemacht haben. Beiminkrementeilen Entwickeln der Software ist es billiger und einfacher Änderungen einzuarbeitenals bei schon fertiger Software.Jedes Inkrement oder jede Version des Systems besitzt einen Teil der Funktionalität,die vom Kunden gebraucht wird. In der Regel enthalten die frühen Systeminkrementedie wichtigsten oder am dringendsten benötigten Funktionen. Dies bedeutet, dass derKunde das System zu einem relativ frühen Zustand in der Entwicklung evaluierenkann um festzustellen, ob es den Anforderungen entspricht. Falls dies nicht der Fallist, dann muss nur das aktuelle Inkrement geändert werden und es müssen eventuellneue Funktionen für spätere Inkremente definiert werden.Inkrementelle Entwicklung hat gegenüber dem Wasserfallmodell drei wesentlicheVorteile:D Die Kosten für die Anpassung an sich ändernde Kundenanforderungen werdenreduziert. Der Umfang der wiederholt durchzuführenden Analyse und Dokumentationist geringer als beim WasserfallmodelLII Es ist einfacher, Rückmeldungen der Kunden zu bereits fertiggestellten Teilen derEntwicklungsarbeit zu bekommen. Sie können sich bei Softwaredemonstrationendazu äußern und sehen, wie viel implementiert wurde. Den Fortschritt anbandvon Softwareentwurfsdokumenten zu beurteilen, fällt Kunden dagegen schwer.D Eine schnellere Auslieferung und Installation von verwendungsfähiger Softwarean den Kunden ist selbst dann möglich, wenn noch nicht die gesamte Funktionalitätenthalten ist. Die Kunden können die Software früher verwenden und darausNutzen ziehen, als es mit einem Wasserfallmodell möglich wäre.Inkrementelle Entwicklung in der einen oder anderen Form ist heute die am häufigsteneingesetzte Vorgehensweise für die Entwicklung von Anwendungssysternen. DieserAnsatz kann entweder plangesteuert, agil oder - am häufigsten jedoch - eineMischung dieser Methoden sein. In einem plangesteuerten Ansatz werden die Systeminkrementeim Voraus bestimmt. Bei einem agilen Vorgehen werden zwar die frühenInkremente ermittelt, die Entwicklung der späteren Inkremente hängt jedoch vom Projektfortschrittund von den Prioritäten des Kunden ab.Die inkrementeHe Entwicklung hat allerdings aus Managementsicht zwei Schwachpunkte:D Der Prozess ist nicht sichtbar: Manager brauchen in regelmäßigen Abständen Zwischenversionen,an denen sie den Fortschritt messen können. Wenn Systeme schnellentwickelt werden, ist es nicht kosteneffektiv, jede Version zu dokumentieren.II Die Systemstruktur wird tendenziell schwächer, wenn neue Inkremente hinzugefügtwerden. Solange nicht Zeit und Geld in die Überarbeitung zur Verbesserungder Software investiert werden, besteht die Tendenz, dass stetige Veränderungendie Struktur der Software beeinträchtigen. Die Integration von weiteren Saftwareänderungenwird zunehmend schwerer und teurer.

2.1 VergehensmodelleBei großen, komplexen Systemen mit einer langen Lebensdauer werden die Problemeder inkrementeilen Entwicklung schnell akut, wenn verschiedene Teams verschiedeneTeile des Systems entwickeln. Große Systeme benötigen einen stabilen Rahmenoder Architektur und die Verantwortlichkeiten von unterschiedlichen Teams, die anTeilen des Systems arbeiten, müssen bezüglich dieser Architektur klar festgelegt werden.Dies muss im Voraus geplant statt inkrementeil entwickelt werden.Man kann ein System inkrementeil entwickeln und es den Kunden zum Kommentierenvorführen, ohne es wirklich auszuliefern und in der Umgebung des Kunden einzurichten.Inkrementelle Auslieferung und Einrichtung bedeuten, dass die Softwarein realen betrieblichen Prozessen verwendet wird. Dies ist nicht immer möglich, dadas Ausprobieren der neuen Software die normalen Geschäftsabläufe stören kann. Ichbehandle die Vor- und Nachteile der inkrementeilen Auslieferung in Abschnitt 2.3.2.Probleme bei der inkrementeilen Entwicklung•Obwohl die inkrementeile Entwicklung viele Vorteile hat, so ist sie doch nicht ganz ohne Probleme.Der Hauptgrund für die Schwierigkeiten ist die Tatsache, dass große Organisationen bürokratischeHandlungsabläufe besitzen, die sich im Laufe der Zeit entwickelt haben und die unter Umständennicht mit einem intermelieren iterativen oder agilen Prozess harmonieren.Manchmal gibt es einen guten Grund für diese Handlungsabläufe- zum Beispiel um sicherzustellen,dass die Software gesetzliche Regelungen ordnungsgemäß umsetzt (z. B. die Vorschriften zurRechnungslegung gemäß dem Sarbanes-Oxley Actin den Vereinigten Staaten). Diese Geschäftsabläufezu verändern ist nicht immer möglich, sodass Konflikte zwischen den Prozessen unvermeidbarsind.http.l/www.SoftwareEngineering-9.com!Webllncrementa!Dev/Link2.1.3 Wiederverwendungsorientiertes Software-EngineeringIn einem Großteil aller Softwareprojekte wird Software wiederverwendet. Häufiggeschieht dies informell, wenn die Mitarbeiter eines Projekts von einem Entwurf odervon Code wissen, der dem ähnelt, der gebraucht wird. Sie suchen ihn heraus, verändernihn nach ihren Bedürfnissen und bauen ihn in ihr System ein.Diese informelle Wiederverwendung findet unabhängig von dem eingesetzten Entwicklungsprozessstatt. Im 21. Jahrhundert wurden jedoch Vorgehensmodelle derSoftwareentwicklung immer populärer, die den Schwerpunkt auf die Wiederverwendungbereits vorhandener Software legten. Wiederverwendungsorientierte Ansätzeberuhen auf einer großen Menge wiederverwendbarer Softwarekomponenten und aufeinem Integrationsrahmen für die Zusammenstellung diese Komponenten. Manchmalhandelt es sich bei diesen Komponenten um eigenständige käufliche Systeme (COTS­Systeme, Commercial Off-The-Shelf System), die benutzt werden können, um einespezielle Funktion beizusteuern, wie zum Beispiel Textverarbeitung oder Tabellenkalkulation.Ein allgemeines Prozessmodell für wiederverwendungsorientierte Entwicklung zeigt.., Abbildung 2.3. Obwohl die erste Phase der Anforderungsspezifikation und die Validierungsphaseauch in anderen Softwareprozessen vorkommen, sind die Zwischenstufenin einem wiederverwendungsorientierten Prozess andere. Diese Stufen sind:

SofihNareprozesseD Analyse der Komponenten: Auf Basis der Anforderungsspezifikation wird nachKomponenten gesucht, mit denen diese Spezifikation implementiert werdenkann. Meistens gibt es keine genaue Übereinstimmung, sodass die verwendetenKomponenten nur einen Teil der erforderlichen Funktionen zur Verfügung stellen.D Anpassung der Anforderungen: In dieser Phase werden die Anforderungen imHinblick auf die gefundenen Komponenten analysiert. Dann werden sie an dieverfügbaren Komponenten angepasst. Sollten Veränderungen nicht möglich sein,muss der Prozess wieder in die Phase der Komponentenanalyse eintreten, umnach alternativen Lösungen zu suchen.D Systementwurf mit Wiederverwendung: In dieser Phase wird der Rahmen für dasSystem entworfen oder ein vorhandener Rahmen wiederverwendet Die Entwicklerbetrachten die wiederverwendeten Komponenten und legen den Rahmen soan, dass er dazu passt. Wenn keine wiederverwendbaren Komponenten vorhandensind, muss an dieser Stelle eventuell neue Software entworfen werden.II Entwicklung und Integration: Die Software, die nicht extern beschafft werden kann,wird entwickelt und zusammen mit den anderen Komponenten und den COTS-Systemenintegriert. Die Systemintegration kann in diesem Modell auch Teil des Entwicklungsprozessessein und muss nicht als eigenständiger Vorgang auftreten.AnforderungsspezifikationAnalyse derKomponentenAnpassung derAnforderungenAbbildung 2.3: Wiederverwendungsorientiertes Software-Engineering.Es gibt drei Arten von Softwarekomponenten, die in einem wiederverwendungsorientiertenProzess eingesetzt werden können:D Webdienste, die im Hinblick auf Servicestandards entwickelt werden und die fürentfernte Aufrufe verfügbar sind;II Sammlungen von Objekten, die als Pakete entwickelt werden, um mit Komponenten-Framworkswie .NET oder JZEE integriert zu werden;D eigenständige Softwaresysteme, die für die Benutzung in einer bestimmten Umgebungkonfiguriert wurden.Wiederverwendungsorientiertes Software-Engineering hat den offensichtlichen Vorteil,dass es die Menge an zu entwickelnder Software und somit auch die Kosten undRisiken verringert. Außerdem wird die Software schneller geliefert. Kompromisse beiden 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 einTeil der Kontrolle über die Weiterentwicklung des Systems verloren, da sich neue Versionenwiederverwendeter Komponenten der Kontrolle der Organisation entziehen,die sie benutzt.

2.2 ProzessaktivitätenDie Wiederverwendung von Software ist sehr wichtig und ich habe mehrere Kapitel imdritten Teil des Buches diesem Thema gewidmet. Allgemeine Probleme und COTS­Wiederverwendung werden in Kapitel 16 behandelt, komponentenbasiertes Software­Engineering in Kapitel 17 und 18 und serviceorientierte Systeme in Kapitel 19.2.2 ProzessaktivitätenReale Softwareprozesse sind überlappende Abfolgen von technischen, auf Zusammenarbeitbasierenden und betriebswirtschaftliehen Aktivitäten mit dem Gesamtzielder Spezifikation, des Entwurfs, der Implementierung und des Testens eines Softwaresystems.Softwareentwickler benutzen bei ihrer Arbeit eine Vielzahl verschiedenerSoftwarewerkzeuge. Solche Werkzeuge unterstützen besonders das Bearbeitenverschiedener Dokumenttypen und die Verwaltung des immensen Umfangs vondetaillierten Informationen, die in einem großen Softwareprojekt erzeugt werden.Die vier grundlegenden Prozessaktivitäten der Spezifikation, Entwicklung, Validierungund Evolution sind in verschiedenen Entwicklungsprozessen unterschiedlichaufgeteilt. Im Wasserfallmodell werden sie nacheinander, während sie in der inkrementeilenEntwicklung gleichzeitig ausgeführt werden. Wie diese Aktivitäten ausgeführtwerden, hängt vom Softwaretyp, den Benutzern und den im Unternehmen herrschendenStrukturen ab. Beim Extreme Programming beispielsweise werden dieSpezifikationen auf Karten geschrieben. Tests sind bereits ausführbar und werden vorder eigentlichen Programmierung entwickelt. Eine Weiterentwicklung könnte eineerhebliche Systemrestrukturierung oder Refaktorierung (Refactoring) bedeuten.Werkzeuge für die Softwareentwicklung•Werkzeuge zur Softwareentwicklung {manchmal Computer-Aided-Software-Engineering- oderCASE-Werkzeuge genannt) sind Programme, die eingesetzt werden, um Softwareprozesse zuunterstützen. Zu diesen CASE-Werkzeugen zählen daher Entwurfseditoren, Data Dictionaries,Compiler, Debugger, Werkzeuge für die Systemerstellung usw.Softwarewerkzeuge unterstützen Prozesse, indem sie einige Abläufe automatisieren und Informationenüber die zu entwickelnde Software verfügbar machen. Beispiele für Aktivitäten, die automatisiertwerden können, sind• die Entwicklung grafischer Systemmodelle als Teil der Anforderungsspezifikation oder des Softwareentwurfs;• die Codeerzeugung aus diesen grafischen Modellen;• die Erzeugung von Benutzeroberflächen durch eine grafische Oberflächenbeschreibung, dieinteraktiv vom Benutzer erstellt wird;• die Behebung von Programmfehlern durch die Bereitstellung entsprechender Informationenüber ein laufendes Programm;• die automatische Übersetzung von Programmen, die in einer alten Version einer Programmiersprachegeschrieben sind, in eineneuere Version.Link

SoftwareprozesseWerkzeuge können mit einem Framework namens lnteractive Development Environment oder JDEkombiniert werden. Eine IDE stellt Funktionalität zur Verfügung, die Werkzeuge benutzen können,um einfacher miteinander kommunizieren und arbeiten zu können. Die Eclipse-IDE wird häufigeingesetzt und wurde so entworfen, dass viele verschiedene Arten von Softwarewerkzeugen integriertwerden können.http://www.SohwareEngineering-9.com/Web!CASE2.2.1 SoftwarespezifikationUnter der Softwarespezifikation bzw. Anforderungsanalyse versteht man den Prozesszum Verstehen und Definieren der vom System verlangten Funktionen sowie derBeschränkungen, denen der Betrieb und die Entwicklung des Systems unterliegen.Die Anforderungsanalyse ist eine besonders kritische Phase des Softwareprozesses, daFehler unweigerlich zu späteren Problemen beim Entwurf und der Implementierungdes Systems führen.Die Anforderungsanalyse (..,.Abbildung 2.4) hilft, ein vereinbartes Anforderungsdokumentzu erstellen, das ein System spezifiziert, welches die Anforderungen der Projektbeteiligtenerfüllt. Die Anforderungen werden normalerweise auf zwei Detailstufendargestellt. Die Endbenutzer und Kunden brauchen eine grobe Aufstellung der Anforderungen,während die Systementwickler eine detailliertere Systemspezifikationbenötigen.SystemmodelleAbbildung 2.4: Ablauf der Anforderungsanalyse.DurchführbarkeitsstudieDurchführbarkeitsberichtAnforderungsspezifikationDie Anforderungsanalyse besteht aus vier wesentlichen Aktivitäten:D Durchführbarkeitsstudie: Es wird abgeschätzt, ob es möglich ist, die Bedürfnissedes Benutzers mithilfe aktueller Software- und Hardwaretechnologien zu erfüllen.Die Studie entscheidet, ob das vorgeschlagene System vom geschäftlichenStandpunkt aus kosteneffektiv ist und ob es innerhalb der Budgetbeschränkungenentwickelt werden kann. Eine Durchführbarkeitsstudie sollte relativ schnellund kostengünstig erstellt werden. Das Ergebnis sollte die Entscheidung ermöglichen,ob eine detailliertere Analyse sinnvoll ist oder nicht.

2.2 Prozessaktivitäten0 Erhebung und Analyse der Anforderungen: In dieser Phase werden die Systemanforderungenaus der Beobachtung bestehender Systeme, Diskussionen mitpotenziellen Benutzern und Käufern, der Aufgabenanalyse usw. abgeleitet. Dazukann die Entwicklung eines oder mehrerer unterschiedlicher Systemmodelle undPrototypen gehören. Diese helfen Ihnen, das zu spezifizierende System besser zuverstehen.D Spezifikation der Anforderungen: Dies ist die Aktivität, bei der die während derAnalyse gesammelten Informationen in ein Dokument umgesetzt werden, daseinen Satz von Anforderungen definiert. In diesem Dokument können zwei Artenvon Anforderungen aufgenommen werden: Benutzeranforderungen sind abstrakteBeschreibungen der Systemanforderungen für den Kunden und den Endnutzer,während es sich bei den eigentlichen Systemanforderungen um eine detailliertereAuflistung der Funktionen handelt, die zur Verfügung gestellt werden sollen.D Validierung der Anforderungen: Diese Aktivität prüft, ob die Anforderungen realistisch,konsistent und vollständig sind. Während dieses Prozesses werden Fehlerim Anforderungsdokument unweigerlich erkannt. Es muss dann verändertwerden, um diese Probleme zu korrigieren.Natürlich werden die Abläufe innerhalb des Anforderungsprozesses nicht einfachnacheinander ausgeführt. Die Analyse der Anforderungen wird während der Definitionund der Spezifikation weitergeführt, dabei kommen oft neue Anforderungen zumVorschein. Die Analyse, die Definition und die Spezifikation sind daher eng miteinanderverknüpft. Bei agilen Methoden wie beim Extreme Programming werden dieAnforderungen entsprechend den Benutzerprioritäten Schritt für Schritt entwickeltund die Bestimmung der Anforderungen erfolgt durch Benutzer, die Teil des Entwicklerteamssind.2.2.2 Softwareentwurf und -implementierungDie Implementierungsphase der Softwareentwicklung ist ein Prozess, in dem die Systemspezifikationin ein ausführbares System umgewandelt wird. Zur Implementierunggehören stets auch Entwurfs- und Programmieraktivitäten, doch wenn ein inkrementeHerAnsatz benutzt wird, kann mitunter auch noch eine Verfeinerung derSoftwarespezifikation vorgenommen werden.Ein Softwareentwurf ist eine Beschreibung der Struktur der zu implementierendenSoftware, der Datenmodelle und -strukturen, die vom System benutzt werden, derSchnittstellen zwischen den Systemkomponenten und manchmal der verwendetenAlgorithmen. Die Entwickler stellen nicht sofort einen fertigen Entwurf auf, sondernentwickeln diesen Entwurf iterativ. Während der Entwicklung wird der Entwurf formalisiertund um Details erweitert, wobei ständig korrigierend auf frühere Entwürfezurückgegriffen wird.IJl.. Abbildung 2.5 ist ein abstraktes Modell dieses Prozesses, in dem die Eingaben desEntwurfsprozesses, Prozessaktivitäten und die Dokumente, die als Ausgaben diesesProzesses produziert werden, zu sehen sind. Dieses Diagramm suggeriert, dass diePhasen des Entwurfsprozesses nacheinander stattfinden. Tatsächlich sind die Aktivitäteninnerhalb des Entwurfsprozesses jedoch miteinander verwoben. Rückmeldungenvon einer Phase zur anderen und die daraus folgende Überarbeitung des Entwurfssind bei allen Entwurfsprozessen unvermeidbar.

SoftwareprozesseEntwurfseingaben~---------------------------------------,PlattforminformationAnforderungsspezifikationDatenbeschreibungEntwurfsaktivitätenr-------------------~-------------------,DatenbankentwurfEntwurfsausgabenSystemarchitekturDatenbankspezifikationSchnittstellenspezifikationKomponentenspezifikationAbbildung 2.5: Ein allgemeines Modell des Entwurfsprozesses.Die meisten Softwareprodukte haben Schnittstellen zu anderen Softwaresystemen.Dazu gehören das Betriebssystem, Datenbanken, Middleware und andere Anwendungssysteme.Diese bilden die "Softwareplattform", die Umgebung, in der die Softwareausgeführt wird. Informationen über diese Plattform sind eine unverzichtbareEingabe in den Entwurfsprozess, da die Entwickler entscheiden müssen, wie die Softwaream besten mit ihrer Umgebung integriert wird. Zur Anforderungsspezifikationgehört eine Beschreibung der Funktionalität, die die Software zur Verfügung stellenmuss, sowie die Performanz- und Verlässlichkeitsanforderungen. Wenn das Systemvorhandene Daten verarbeiten soll, dann kann die Beschreibung dieser Daten innerhalbder Plattformspezifikation erfolgen. Anderenfalls muss die Datenbeschreibungeine Eingabe des Entwurfsprozesses sein, sodass die Struktur der Systemdaten definiertwerden kann.Die Aktivitäten in dem Entwurfsprozess variieren je nach Art des zu entwickelndenSystems. Bei Echtzeitsystemen muss beispielsweise das Zeitverhalten im Entwurfberücksichtigt werden, dagegen wird möglicherweise keine Datenbank und somit keinDatenbankentwurf benötigt. Abbildung 2.5 zeigt vier Aktivitäten, die Teil des Entwurfsprozessesfür Informationssysteme sein können:D Architekturentwurf: Hier werden die Gesamtstruktur des Systems, die Hauptkomponenten(manchmal Subsysteme oder Module genannt) und ihre Verbindungensowie deren Verteilung bestimmt.II Schnittstellenentwurf: Hier definiert man die Schnittstellen zwischen den Systemkomponenten.Diese Schnittstellenspezifikation muss absolut eindeutig sein.Eine präzise Schnittstelle führt dazu, dass eine Komponente von anderen benutztwerden kann, ohne Kenntnisse über die Implementierung dieser Komponente zuhaben. Wenn eine Schnittstellenspezifikation vereinbart wurde, können die einzelnenKomponenten parallel entworfen und entwickelt werden.

2.2 ProzessaktivitätenD Komponentenentwurf: Hier wird für jede Systemkomponente ihm zJtkünftigeArbeitsweise festgelegt. Dies kann eine einfache Darstellung dHr t)fwartn!fmFunktionalität oder ein detailliertes Entwurfsmodell sein. Das Entwurfsmodellkann zur automatischen Erzeugung einer Implementierung verwendet wPrden.IJ Datenbankentwurf: Hier werden die Strukturen der Svstemdatun fmtworfun undfestgelegt, wie diese in einer Datenbank abgebildet .werdPn sollen. Auch himhängt der Arbeitsaufwand davon ab, ob eine vorhandom~ Datenbank wh•durver·wendet oder ob eine neue Datenbank erzeugt werden soll.All diese Aktivitäten führen zu einer Reihe von Ausgaben, difl ebenfalls in Abbildung2.5 zu sehen sind. Die Einzelheiten und die Repräsentation dieser Ausgabtm unterscheidensich erheblich. Für kritische Systeme müssen detailHorte Entwurfsdnkunwntationenangefertigt werden, welche präzise und akkurate Beschreibungen des Sys·tems liefern. Wenn ein modellgetriebener Ansatz benutzt wird, sind rlinsH Ausgabenmeistens Diagramme. Wenn agile Entwicklungsmethoden verwendet werdnn. erfolgtdie Ausgabe des Entwurfsprozesses nicht in Form separater Spezifikationsrlokumentn.sondern zunehmend als Darstellung im Programmcode.Strukturierte Entwurfsmethoden wurden in den 1970er und 191l0er Jalm·n entwickeltund waren die Vorläufer von UML und objektorientiertem Entwurf (Budgen. 2003).Diese Methoden basieren auf dem Prinzip, zunächst grafische Modelle des Systems zuproduzieren, aus denen in vielen Fällen automatisch Code erzeugt wird. Eine Weiterentwicklungder strukturierten Methoden ist die modellgetriebene Softwareentwicklung(Model-Driven Development, MDD; Schmidt, 2006), bei der Modelle der Sof1wareauf verschiedenen Abstraktionsebenen angefertigt werden. Bei MDD wird rnehr Wertauf Architekturmodelle mit Trennung zwischen abstrakten implementiorungsunabhängigenModellen und implementierungsspezifischen Modellen gelegt. Die Modelle werdenausreichend detailliert entwickelt, sodass das lauffähige System daraus generiertwerden kann. Ich diskutiere diesen Entwicklungsansatz in Kapitel 5.Wenn ein System implementiert werden soll, folgt die Entwicklung eines Programmsganz natürlich aus dem Systementwurfsprozess. Obwohl einige Klassen von Programmenwie sicherheitsrelevante Systeme detailliert entworfen werden, bevor die Implementierungbeginnt, kommt es häufiger vor, dass die späteren Phasen des Entwurfsund der Programmentwicklung verknüpft werden. So können Softwareentwicklungswerkzeugezum Einsatz kommen, um aus einem Entwurf ein Programmgerüst zuerzeugen. Dabei müssen Schnittstellen definiert und implementiert werden, und invielen Fällen braucht der Programmierer nur Details zur Funktionalität jeder Programmkomponentebeizusteuern.Die Programmierung ist eine individuell gestaltete Aktivität und es gibt dafür keinenallgemeingültigen Prozessverlauf. Manche Programmierer fangen mit Komponentenan, die sie bereits vollständig verstehen, entwickeln diese und gehen dann zu wenigereindeutigen Komponenten über. Andere gehen den entgegengesetzten \Neg und hebensich 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 benutzensie, um die Programmentwicklung voranzutreiben, während andere die Daten so langewie möglich unspezifiziert lassen.Normalerweise testen die Programmierer den von ihnen entwickelten Code zumindestoberflächlich selbst. Das enthüllt oft Fehler im Programm, die korrigiert werden müssen.Dies wird Fehlerbehebung (debugsing) genannt. Fehlertest und Fehlerbehebung

Softwareprozessesind zwei verschiedene Prozesse. Die Fehlertests stellen das Vorhandensein von Fehlernfest, wohingegen sich die Fehlerbehebung damit beschäftigt, diese Fehler zu findenund zu entfernen.Bei der Fehlerbehebung stellen Sie Hypothesen über das sichtbare Verhalten des Programmsauf und testen diese in der Hoffnung, den Fehler zu finden, der die Unregelmäßigkeitin der Ausgabe verursacht hat. Das Testen von Hypothesen kann bedeuten,dass der Programmcode von Hand überprüft werden muss. Mitunter sind auch neueTestfälle nötig, um das Problem zu lokalisieren. Interaktive Werkzeuge zur Fehlerbehebung(Debugger), die die Zwischenwerte von Programmvariablen anzeigen und dieauszuführenden Befehle verfolgen, unterstützen den Prozess der Fehlerbehebung.Strukturierte Methoden•LinkStrukturierte Methoden sind eine Vorgehensweise des Softwareentwurfs, bei der grafischeModelle definiert werden, die als Teil des Entwicklungsprozesses entwickelt werden sollen. DieMethode kann außerdem einen Prozess für die Entwicklung der Modelle und Regeln definieren,die auf jeden Modelltyp passen. Strukturierte Methoden führen zu einer standardisierten Systemdokumentationund sind deshalb besonders nützlich, weil sie einen Entwicklungsrahmen für wenigererfahrene und routinierte Softwareentwickler zur Verfügung stellen.htqJ.:#www.SoftwareEngineering-9.com/Web!Structured-methods2.2.3 SoftwarevalidierungDie Softwarevalidierung oder allgemeiner die Verifikation und Validierung (V&V) sollzeigen, dass ein System sowohl seine Spezifikationen erfüllt als auch den Erwartungendes Kunden des Systems entspricht. Der Programmtest, bei denen das Systemunter Benutzung von simulierten Testdaten ausgeführt wird, ist die Hauptvalidierungstechnik.Validierung könnte auch Überprüfungsprozesse wie Inspektionen undReviews in jeder Phase des Softwareprozesses vorsehen, von der Definition der Benutzeranforderungenbis hin zur Programmentwicklung. Durch den breiten Raum, dendas Testen einnimmt, entsteht der Hauptteil der Validierungskosten während undnach der Implementierung.Außer bei kleinen Programmen sollten Systeme nicht als eine einzige große Einheitgetestet werden. 111> Abbildung 2.6 zeigt einen Testprozess in drei Phasen, in demzuerst die Systemkomponenten, dann integrierte Subsysteme und schließlich dasGesamtsystem mit den vom Kunden gelieferten Daten getestet werden. Im Idealfallwerden Fehler in den Komponenten in einer frühen Prozessphase und Schnittstellenproblemespätestens bei der Systemintegration gefunden. Wann immer jedoch Fehlerentdeckt werden, müssen sie im Programm behoben werden, und das kann bedeuten,dass andere Testphasen zu wiederholen sind. Fehler in Programmkomponenten könnenzum Beispiel während der Integrationstests ans Tageslicht kommen. Der Testprozessist also iterativ, wobei Informationen aus den späteren Phasen als Feedback fürdie früheren Prozessabschnitte verwendet werden können.

2.2 ProzessaktivitätenSystemtestAbbildung 2.6: Testphasen.Die Phasen des Testprozesses sind die folgenden:D Entwickler- und Komponententests: Die Komponenten, die das Gesamtsvstmnbilden, werden von den gleichen Personen getestet, die auch das System ~ntwickeln.Jede Komponente wird unabhängig von anderen Systemkomponenten getestet.Komponenten können einfache Einheiten sein, wie z. B. Funktionen oderObjektklassen, oder aber zusammenhängende Gruppen dieser Einheiten. Werkzeugezur Testautomatisierung wie JUnit (Massol und Husted, 200:3). die Komponententestserneut ausführen können, wenn neue Versionen der Komponontenerzeugt werden, sind weitverbreitetD Systemtest: Die Systemkomponenten werden integriert und bilden ein vollständigesSystem. Dieser Prozess beschäftigt sich mit dem Auffinden von Fehlern, dieaus unerwarteten Interaktionen zwischen den Komponenten entstehen, sowiemit Schnittstellenproblemen zwischen den Komponenten. Er befasst sich auchmit dem Nachweis, dass das System seine funktionalen und nichtfunktionalenAnforderungen erfüllt. Außerdem werden die grundlegenden Systemeigenschaftengetestet. Bei großen Systemen kann es sich hierbei um einen mehrstufignnProzess handeln, bei dem Komponenten integriert werden, um Subsysteme zubilden, die wiederum einzeln getestet werden, bevor sie selbst integriert wer

SoftwareprozesseWenn ein plangesteuerter Softwareprozess benutzt wird (z. B. für die Entwicklungvon kritischen Systemen), wird das Testen von einer Menge von Testplänen gesteuert.Ein unabhängiges Team von Testern arbeitet mit diesen vorformulierten Testplänen,die aus der Spezifikation und dem Entwurf des Systems abgeleitet wurden.~Abbildung 2.7 zeigt, wie die Testpläne die Testaktivitäten mit den Entwicklungsaktivitätenverbinden. Dies wird manchmal das V-Modell der Entwicklung genannt(drehen Sie die Abbildung und Sie sehen das V).Plan fürAbnahmetestAbbildung 2.7: Testphasen in einem plangesteuerten Softwareprozess.Der Abnahmetest wird auch Alphatest genannt. Speziell erstellte Systeme werden füreinen einzelnen Kunden entwickelt. Der Alphatestprozess wird weitergeführt, bis derSoftwareentwickler und der Kunde sich einig sind, dass das ausgelieferte System eineakzeptable Implementierung der Anforderungen darstellt.Wenn ein System als Softwareprodukt auf den Markt kommen soll, werden oft sogenannteBetatests durchgeführt, bei denen das System an eine Anzahl zukünftiger Kundenausgeliefert wird, die sich verpflichten, das System zu benutzen und den SaftwareentwicklernProbleme zu melden. Dadurch wird das System echter Nutzungausgesetzt und es können Probleme gefunden werden, die die Softwareentwicklernicht voraussehen konnten. Das System wird den Rückmeldungen entsprechend verändertund entweder für weitere Betatests oder für den Verkauf freigegeben.2.2.4 Weiterentwicklung von SoftwareDie Flexibilität von Softwaresystemen ist einer der Hauptgründe, warum immer mehrSoftware in große, komplexe Systeme eingebunden wird. Sobald die Entscheidunggetroffen ist, Hardware herzustellen, ist es sehr teuer, am Hardwareentwurf Veränderungenvorzunehmen. An der Software können jedoch jederzeit während oder sogar nachder Systementwicklung Veränderungen vorgenommen werden. Selbst gravierende Änderungensind immer noch billiger als entsprechende Änderungen an der Systemhardware.In der Vergangenheit hat es immer eine Trennung zwischen dem Prozess der Saftwareentwicklungund dem der Softwareweiterentwicklung (Softwarewartung) gegeben.Die Softwareentwicklung wird als ein kreativer Vorgang angesehen, in dem einSoftwaresystem von einem Anfangskonzept bis hin zu einem lauffähigen System entwickeltwird. Die Softwarewartung wird hingegen manchmal als langweilig unduninteressant eingestuft. Obwohl die Wartungskosten die anfänglichen Entwicklungskostenoft um ein Vielfaches übersteigen, werden die Wartungsabläufe manchmal alsweniger herausfordernd betrachtet als die ursprüngliche Softwareentwicklung.

2.3 Umgang mit ÄnderungenDiese Trennung zwischen Entwicklung und Wartung wird immer unwichtiger. Nurwenige Softwaresysteme sind völlig neue Systeme und daher ist es wesentlich sinnvoller,Entwicklung und Wartung als einen kontinuierlichen Vorgang zu betrachten.Anstatt sich zwei getrennte Prozesse vorzustellen, ist es realistischer, das Software­Engineering als einen evolutionären Vorgang (IJJo. Abbildung 2.8) zu betrachten, in demdie Software während ihrer Lebenszeit ständig verändert wird, um sich wandelndenAnforderungen und Kundenbedürfnissen anzupassen.Abbildung 2.8: Weiterentwicklung eines Systems.2.3 Umgang mit ÄnderungenBei allen großen Softwareprojekten sind Veränderungen unvermeidlich. Die Systemanforderungenändern sich, wenn das Unternehmen, das das System in Auftraggibt, auf externe Anforderungen reagieren muss oder wenn sich die Prioritäten derGeschäftsführung wandeln. Mit dem Einsatz neuer Technologien ergeben sich neueEntwurfs-und Implementierungsmöglichkeiten. Welches Softwareprozessmodelldaher auch immer benutzt wird- es ist unabdingbar, dass Änderungen an der sich inEntwicklung befindenden Software eingepflegt werden können.Änderungen erhöhen die Kosten der Softwareentwicklung, weil dann in der Regelbereits erledigte Arbeitsschritte noch einmal durchgeführt werden müssen. DiesenVorgang bezeichnet man als Rework. Wenn beispielsweise die Beziehungen zwischenden Anforderungen in einem System untersucht und danach neue Anforderungenfestgelegt wurden, dann muss die Anforderungsanalyse teilweise oder ganz wiederholtwerden. Um den neuen Anforderungen gerecht zu werden, könnte es daraufhinnotwendig werden, das System neu zu entwerfen, bereits entwickelte Programme zuändern und das System noch einmal zu testen.Es gibt zwei verwandte Ansätze, die benutzt werden können, um die Kosten desRework zu reduzieren:D Vermeidung von Änderungen: Der Softwareprozess enthält Aktivitäten, die möglicheÄnderungen vorwegnehmen können, bevor nennenswertes Rework erforderlichwird. Zum Beispiel könnte ein Prototypsystem entwickelt werden, umdem Kunden einige Hauptmerkmale des Systems vorzuführen. Dieser kann dannmit dem Prototyp experimentieren und seine Anforderungen verfeinern, bevor erhöheren Softwareproduktionskosten zustimmt.0 Toleranz der Änderungen: Der Prozess ist so ausgelegt, dass Änderungen zu relativniedrigen Kosten eingearbeitet werden können. Dies setzt in der Regel irgendeineForm von inkrementeUer Entwicklung voraus. Die Implementierung von geplantenÄnderungen kann in solche Inkremente ausgelagert werden, die bis jetzt noch

SofhNareprozessenicht entwickelt wurden. Wenn dies nicht möglich ist, dann muss vielleicht nurein einziges Inkrement (ein kleiner Teil des Systems) modifiziert werden, um dieÄnderungen einzuarbeiten.In diesem Abschnitt stelle ich zwei Möglichkeiten vor, mit Änderungen und sichändernden Systemanforderungen umzugehen. Diese sind:D Entwicklung von Systemprototypen: Eine Version des Systems oder eines Systemteilswird schnell entwickelt, um die Anforderungen des Kunden und dieMachbarkeit einiger Entwurfsentscheidungen zu überprüfen. Dadurch wird dieVermeidung von Änderungen unterstützt, da es den Benutzern erlaubt, mit demSystem vor der Auslieferung zu experimentieren, und sie so ihre Anforderungenverfeinern können. Die Anzahl der Anforderungen, die nach der Auslieferungverändert werden müssen, wird damit wahrscheinlich reduziert.II Inkrementelle Auslieferung: Die inkrementell erstellten Teilsysteme werden anden Kunden ausgeliefert, der damit experimentieren und Kommentare abgebenkann. Dieses Vorgehen unterstützt sowohl die Vermeidung von Änderungen alsauch die Änderungstoleranz. Die vorzeitige Festlegung der Anforderungen fürdas gesamte System wird vermieden und Änderungen können in spätere Inkrementezu relativ geringen Kosten eingearbeitet werden.Das Konzept des Refactoring, vor allem der Verbesserung der Struktur und Organisationeines Programms, ist ebenfalls ein wichtiger Mechanismus, der Änderungstoleranzunterstützt. Ich komme darauf in Kapitel 3 zurück, wo agile Methoden behandeltwerden.2.3.1 SoftwareprototypenEin Prototyp ist eine erste Version eines Softwaresystems, der dazu verwendet wird,Konzepte zu demonstrieren, Entwurfsmöglichkeiten auszuprobieren und Erkenntnisseüber das Problem und seine möglichen Lösungen zu gewinnen. Eine schnelle,iterative Entwicklung des Prolotyps ist von entscheidender Bedeutung, um die Kostenzu begrenzen und den Systembeteiligten schon in einem frühen Stadium des Saftwareprozessesetwas zum Experimentieren zu geben.Ein Prototyp kann im Softwareentwicklungsprozess eingesetzt werden, um Änderungenvorwegzunehmen, die nötig werden könnten:0 Beim Requirements-Engineering-Prozess hilft ein Prototyp bei der Ermittlungund Validierung der Systemanforderungen.IJ Beim Systementwurf kann der Prototyp verwendet werden, um einzelne Saftwarelösungenzu untersuchen und den Entwurf der Benutzeroberfläche zu unterstützen.Anhand von Systemprototypen können die Benutzer erkennen, wie gut das System siebei der Arbeit unterstützt. Sie gewinnen dadurch möglicherweise neue Ideen fürAnforderungen und können Stärken und Schwächen in der Software erkennen. Siekönnen dann neue Systemanforderungen vorschlagen. Darüber hinaus können bei derEntwicklung des Prototyps fehlerhafte und übersehene Anforderungen aufgedecktwerden. In einer Spezifikation mag eine Funktion nützlich und wohldefiniert erscheinen.Wenn diese Funktion jedoch mit anderen kombiniert wird, stellen die Benutzer

2.3 Umgang mit Änderungenhäufig fest, dass ihre anfängliche Auffassung falsch oder unvollständig war. Die Systemspezifikationkann in diesem Falle angepasst werden, um die neuen Erkenntnissein den Anforderungen widerzuspiegeln.Ein Prototyp kann während des Systementwurfs verwendet werden, um Entwurfsalternativenzu realisieren und die Machbarkeit des vorgeschlagenen Entwurfs zu überprüfen.So kann zum Beispiel vom Datenbankentwurf ein Prototyp erstellt werden, um zutesten, ob er einen möglichst effizienten Datenzugriff für die häufigsten Benutzerabfragenunterstützt. Prototypen sind auch ein wesentliches Hilfsmittel beim Entwurf vonBenutzeroberflächen. Wegen der dynamischen Eigenschaften von Benutzeroberflächensind textuelle Beschreibungen und Diagramme nicht ausreichend, um die Anforderungenan Benutzeroberflächen zu beschreiben. Deshalb ist schnelles Prototyping (rapidprototyping) unter Einbeziehung der Endbenutzer der einzig sinnvolle Weg, um grafischeBenutzeroberflächen für Softwaresysteme zu entwickeln.Ein Vorgehensmodell für die Prototypentwicklung zeigt..,. Abbildung 2.9. Das Ziele derPrototypenentwicklung sollten am Beginn des Prozesses deutlich gemacht werden.Dabei kann es sich um die Entwicklung eines Systems zur Erprobung der Benutzeroberfläche,zur Bewertung funktionaler Systemanforderungen oder zur Demonstrationder Anwendungsmöglichkeiten für das Management handeln. Ein und derselbe Prototypkann nicht alle Anforderungen erfüllen. Wenn die Ziele nicht klar definiert sind,kann es beim Management oder Endbenutzer zu Missverständnissen über den Einsatzdes Prototyps kommen. Folglich werden diese Personen möglicherweise nicht denNutzen erhalten, den man sich von der Prototypentwicklung versprochen hatte.PrototypzielefestlegenPrototypfunktionalitätdefinierenPrototypplanFunktionsbeschreibungAbbildung 2.9: Der Vorgang der Prototypentwicklung.Im nächsten Schritt wird entschieden, was der Prototyp beinhalten und- vielleichtnoch wichtiger- was nicht darin enthalten sein sollte. Um die Kosten bei der Prototypentwicklungzu senken und die Auslieferung zu beschleunigen, könnten Sie einigeFunktionen beim Prototyp weglassen. Sie könnten nichtfunktionale Anforderungenan die Reaktionszeit oder die Speicherverwaltung abschwächen. Fehlerbehandlungund -bearbeitung können ignoriert werden, wenn der Prototyp nicht zur Demonstrationder Benutzeroberfläche verwendet wird. Die Anforderungen an Zuverlässigkeitund Programmqualität können ebenfalls verringert werden.Die letzte Phase des Prozesses ist die Erprobung und Auswertung des Prototyps. In dieserPhase müssen Vorbereitungen für die Benutzerschulung getroffen werden und diegesetzten Ziele für den Prototyp sollten zur Erstellung eines Bewertungsplans herangezogenwerden. Benutzer brauchen Zeit, um sich an ein neu es System zu gewöhnen undin ein normales Anwenderverhalten hineinzufinden. Sobald sie das System im praktischenBetrieb benutzen, werden sie Anforderungsfehler und -lücken erkennen.

- SoftwareprozesseEin generelles Problem bei der Entwicklung eines Prototyps ist, dass der Prototypeventuell nicht in der gleichen Weise wie das endgültige System verwendet wird. DieTester des Prototyps sind möglicherweise keine typischen Systembenutzer. Die Zeitzum Kennenlernen des Prototyps während der Bewertungsphase reicht unter Umständennicht aus. Wenn der Prototyp langsam ist, wird man bei der Bewertung dieArbeitsweise darauf abstimmen und Systemfunktionen mit langen Rechenzeiten vermeiden.Wenn man dann beim endgültigen System über bessere Reaktionszeiten verfügt,wird man es auf andere Weise nutzen.Entwickler werden manchmal durch ihre Vorgesetzten unter Druck gesetzt, für dieeinmalige Verwendung vorgesehene Prototypen auszuliefern, besonders wenn es Terminverschiebungenbei der Auslieferung der endgültigen Version gibt. Dies ist jedochaus folgenden Gründen unklug:D Es ist eventuell unmöglich, den Prototyp auf nichtfunktionale Anforderungenwie Leistungsfähigkeit, Informationssicherheit, Stabilität und Zuverlässigkeit zutrimmen, auf die bei der Prototypentwicklung keine Rücksicht genommenwurde.II Schnelle Änderungen während der Entwicklung führen zwangsläufig dazu, dassder Prototyp nicht dokumentiert ist. Die einzige Entwurfsspezifikation ist derPrototypcode. Das reicht für langfristige Wartung nicht aus.0 Die während der Prototypentwicklung durchgeführten Änderungen haben wahrscheinlichdie Systemstruktur verschlechtert. Die Wartung des Systems wird somitschwierig und teuer sein.IJ Bei der Entwicklung eines Prototyps wird normalerweise keine Rücksicht auf organisationsspezifischeQualitätsstandards genommen.Prototypen müssen nicht ausführbar "zu" sein, um nützlich zu sein. Auf Papiererstellte Modelle der Benutzeroberfläche eines Systems (Rettig, 1 994) können denBenutzern effektiv dabei helfen, den Oberflächenentwurf zu verfeinern und dieAnwendungsszenarios durchzuarbeiten. So etwas lässt sich ohne große Kosten entwickelnund in wenigen Tagen herstellen. Eine Erweiterung dieser Technik ist ein sogenannter"Wizard-of-Oz"-Prototyp, bei dem lediglich die Benutzeroberfläche entwickeltist. Die Benutzer experimentieren mit dieser Oberfläche, aber ihre Eingaben werden aneine Person weitergeleitet, die sie interpretiert und die entsprechende Antwort ausgibt.2.3.2 Inkrementeile AuslieferungDie inkrementeile Auslieferung (.,.Abbildung 2.10) ist ein Ansatz des Software­Engineerings, bei dem einige der inkrementeil entwickelten Teilsysteme an den Kundenausgeliefert und zur Benutzung in einer betrieblichen Umgebung eingesetzt werden. Ineinem inkrementeilen Auslieferungsprozess entscheiden die Kunden im Groben, welcheLeistungen das System zur Verfügung stellen soll. Sie legen fest, welche Leistungenihnen am wichtigsten und welche unwichtig sind. Dann wird eine Anzahl von lieferbarenTeilsystemen vereinbart, wobei jedes Inkrement eine Teilmenge der Funktionen desSystems bereitstellt. Die Zuordnung der Dienste zu den Teilsystemen hängt von derPriorität der Dienste ab, wobei Dienste mit der höchsten Priorität zuerst implementiertund ausgeliefert werden.

2.3 Umgang mit Änderungengrobe Definitionder AnforderungenZuordnung der Anforderungenzu InkrementenEntwurf derSystemarchitekturIntegration desInkrementsAbbildung 2.10: Inkrementeile Auslieferung.Sobald die inkrementeil zu entwickelnden Teilsysteme festgelegt sind, werden dieAnforderungen für die im ersten Teilsystem bereitzustellenden Dienste im Detail definiertund dieses Inkrement wird entwickelt. Während dieser Entwicklungsarbeit könnendie Anforderungen für die Inkremente analysiert werden, Veränderungen amaktuellen Teil sind jedoch nicht mehr möglich.Sobald ein Teilsystem fertiggestellt und ausgeliefert wurde, kann der Kunde es inBetrieb nehmen. Das bedeutet, dass er bereits zu einem sehr frühen Zeitpunkt übereinen Teil der Systemfunktionalität verfügen kann. Er kann die Funktionen ausprobierenund auf diese Weise Anforderungen für spätere Teilsysteme abklären. Sind neueInkremente fertiggestellt, werden sie in die bereits vorhandenen Teilsysteme integriert,sodass sich die Funktionalität des Systems mit jeder neuen Erweiterung verbessert.Dieser inkrementeile Auslieferungsprozess hat eine Reihe von Vorteilen:D Die Kunden können frühe Teilsysteme als eine Art Prototyp benutzen und Erfahrungensammeln, die in die Anforderungen für spätere Erweiterungen einfließen.Anders als Prototypen sind dies Teile des realen Systems, sodass sie sich nichterneut umstellen müssen, wenn das vollständige System verfügbar ist.0 Die Kunden brauchen nicht zu warten, bis das gesamte System geliefert wird, bevorsie es nutzen können. Das erste Teilsystem erfüllt ihre wichtigsten Anforderungen,sodass die Software sofort eingesetzt werden kann.0 Der Prozess bewahrt den Vorteil der inkrementellen Entwicklung dahingehend,dass es relativ leicht sein sollte, Änderungen in das System einzuarbeiten.II Da die Funktionen mit der höchsten Priorität zuerst ausgeliefert werden und Inkrementedanach integriert werden, sind diese wichtigen Systemfunktionen amintensivsten getestet. Das bedeutet, dass in den wichtigsten Teilen des Systemsweniger Softwareausfälle auftreten sollten.75

SoftwareprozesseEs gibt bei der inkrementellen Entwicklung jedoch auch einige Probleme:D Die meisten Systeme verlangen eine Anzahl grundlegender Funktionen, die vonverschiedenen Teilen des Systems benutzt werden. Da die Anforderungen nichtdetailliert festgelegt werden, bevor ein Teilsystem implementiert werden soll, istes daher schwer, Funktionen zu erkennen, die alle Teile des Systems brauchen.D Iterative Entwicklung kann außerdem schwierig werden, wenn ein Ersatzsystementwickelt wird. Die Benutzer wollen die gesamte Funktionalität des alten Systemsund sind oft nicht willens, mit einem unvollständigen neuen System zu experimentieren.Daher ist es schwierig, nützliche Rückmeldungen der Kunden zuerhalten.D Das Wesentliche bei iterativen Prozessen ist, dass die Spezifikation zusammenmit der Software entwickelt wird. Das steht jedoch im Widerspruch zu den Beschaffungsmodellenvieler Unternehmen, in denen eine vollständige SystemspezifikationTeil des Vertrages ist. Bei einem inkrementeilen Ansatz gibt es jedochso lange keine vollständige Systemspezifikation, bis die letzte Erweiterung spezifiziertist. Das erfordert eine neue Art von Vertrag bzw. Übereinkommen, demsich große Kunden wie Behörden nur schwer anpassen können.Es gibt einige Systemarten, für die inkrementeHe Entwicklung und Auslieferung nichtdas beste Vorgehensmodell ist. Dies betrifft sehr große Systeme, bei denen an der Entwicklunghäufig Teams beteiligt sind, die an verschiedenen Orten arbeiten, sowieeinige eingebettete Systeme, bei denen die Software von der Hardwareentwicklungabhängt, und kritische Systeme, bei denen alle Anforderungen analysiert sein müssen,um auf Interaktionen zu testen, die die Informationssicherheit und die Betriebssicherheitdes Systems gefährden könnten.Diese Systeme leiden natürlich an demselben Problem der unsicheren und sichändernden Anforderungen. Um dieses Problem anzugehen und einige der Vorteile derinkrementeilen Entwicklung auszunutzen, könnte daher ein Prozess eingesetzt werden,bei dem ein Systemprototyp iterativ entwickelt wird und der als Plattform fürExperimente mit den Systemanforderungen und dem Systementwurf verwendet wird.Mit der Erfahrung, die aus diesem Prototyp gewonnen wird, können endgültige Anforderungenvereinbart werden.2.3.3 Das Spiralmodell nach BoehmEin risikogesteuertes Softwareprozess-Framework (das Spiralmodell) wurde zuerstvon Boehm (1988) vorgeschlagen. Es ist in~ Abbildung 2.11 zu sehen. Hier wird derSoftwareprozess als eine Spirale dargestellt anstaU als eine Folge von Aktivitäten mitRückwärtsbezügen von einer Aktivität zur anderen. Jede Windung der Spirale stehtfür eine Phase des Prozesses. So beschäftigt sich die innere Windung mit der Machbarkeitdes Systems, die nächste mit der Definition der Systemanforderungen, die folgendemit dem Systementwurf usw. Das Spiralmodell kombiniert die Vermeidung vonÄnderungen mit Änderungstoleranz. Es geht davon aus, dass Änderungen ein Ergebnisvon Projektrisiken sind, und beinhaltet explizite Risikomanagementaktivitäten,um diese Risiken zu reduzieren.

2.3 Umgang mit ÄnderungenZiele, Alternativen undRandbedingungen feststellenBetriebAbbildung 2.11: Das Spiralmodell des Softwareprozesses nach Boehm (ÖIEEE, 1988).Jede Windung der Spirale ist in vier Segmente aufgeteilt:0 Ziele aufstellen: Hier werden spezielle Ziele für diese Phase des Projekts definiert.Rahmenbedingungen, denen der Prozess oder das Produkt unterliegt, werdenbestimmt und es wird ein detaillierter Managementplan erstellt. Die Projektrisikenwerden aufgelistet. Abhängig von diesen Risiken können alternativeStrategien geplant werden.0 Risiken einschätzen und verringern: Jedes der erkannten Projektrisiken wird intensivanalysiert und es werden Schritte unternommen, um die Risiken zu verringern.Wenn zum Beispiel das Risiko besteht, dass die Anforderungen nicht angemessensind, könnte ein Prototyp des Systems entwickelt werden.D Entwicklung und Validierung: Nach der Auswertung der Risiken wird ein Entwicklungsmodellausgewählt. Wenn zum Beispiel die Risiken vor allem bei derBenutzeroberfläche liegen, dann wäre die Herstellung eines "Wegwerf-Prototyps"das beste EntwicklungsmodelL Wenn Betriebssicherheit das Hauptrisiko ist, dannwäre aber zum Beispiel eine Entwicklung mithilfe formaler Umformungen angemessen.Und das Wasserfallmodell ist wahrscheinlich das beste Entwicklungsmodell,wenn das größte erkannte Risiko die Integration von Subsystemen ist.IJ Planung: Das Projekt wird überprüft und es wird entschieden, ob mit der nächstenWindung der Spirale weitergemacht werden kann. Entscheidet man sich fürdiesen Schritt, werden Pläne für die nächste Phase aufgestellt.77

SoftwareprozesseDer Hauptunterschied zwischen dem Spiralmodell und anderen Vorgehensmodellenliegt in der ausdrücklichen Betrachtung der Risiken im SpiralmodelL Ein Spiralenzyklusbeginnt mit der Festlegung von Zielen wie Leistungsfähigkeit, Funktionalitätusw. Dann werden alternative Wege zu diesen Zielen und die damit zusammenhängendenBeschränkungen durchnummeriert. Jede Alternative wird mit jedem Ziel verglichenund die Stellen, an denen Projektrisiken auftreten können, werden erkannt.Der nächste Schritt besteht darin, diese Risiken zum Beispiel durch eine detaillierteAnalyse, das Erstellen von Prototypen und das Durchführen von Simulationen auszuwerten.Sobald die Risiken ausgewertet wurden, wird ein Stück weit entwickelt und danachdie nächste Phase des Prozesses geplant. Einfach ausgedrückt ist ein Risiko etwas, dasschiefgehen kann. Wenn zum Beispiel eine neue Programmiersprache benutzt werdensoll, besteht das Risiko, dass die verfügbaren Compiler unzuverlässig sind oder keinenausreichend effizienten Objektcode generieren. Risiken führen zu Softwareänderungenund 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 22 erläutere ich das Risikomanagement als wichtigen Teil desProjektmanagements im Detail.2.4 Der Rational Unified ProcessDer Rational Unified Process (RUP; Krutchen, 2003) ist ein Beispiel für ein modernesVorgehensmodell, das aus der Arbeit an der UML und dem damit verbundenen UnifiedSoftware Development Process (Rumbaugh et al., 1999a; Arlow und Neustadt,2005) abgeleitet wurde. Ich habe hier eine Beschreibung eingefügt, da es ein gutes Beispielfür ein hybrides Vorgehensmodell ist. Der Prozess vereinigt Elemente aus allenallgemeinen Vorgehensmodellen (Abschnitt 2.1), veranschaulicht empfohlene Vorgehensweisenfür Spezifikation und Entwurf (Abschnitt 2.2) und unterstützt die Entwicklungvon Prototypen und die inkrementeile Auslieferung (Abschnitt 2.3).Der RUP trägt der Tatsache Rechnung, dass herkömmliche Vorgehensmodelle nur eineeinzige Sicht des Prozesses darstellen. Der RUP wird hingegen normalerweise aus dreiPerspektiven heraus beschrieben:D eine dynamische Perspektive, die die Phasen des Modells zeitlich darstellt;D eine statische Perspektive, die die ausgeführten Prozessaktivitäten darstellt;D eine praxisbezogene Perspektive, die die während des Prozesses empfohlenenVorgehensweisen vorschlägt.Bei den meisten Beschreibungen des RUP wird versucht, die statische und dynamischePerspektive in einem einzigen Diagramm zusammenzufassen (Krutchen, 2003).Meiner Meinung nach erschwert dieser Ansatz das Verständnis für den Prozess, deshalbbeschreibe ich jede dieser Perspektiven separat.Beim RUP handelt es sich um ein phasenorientiertes Modell, das für den Softwareprozessvier einzelne Phasen unterscheidet. Anders als beim WasserfallmodelL bei demdie Phasen mit Prozessaktivitäten gleichgesetzt werden, sind die Phasen des RUPenger mit geschäftlichen als mit fachlichen Belangen verbunden . ..,. Abbildung 2.12zeigt die Phasen im RUP. Diese lauten wie folgt:

2.4 Der Rational Unified ProcessD Konzeption: Das Ziel der Konzeptionsphase besteht in der Ausarbeitung einesGeschäftsfalls für das System. Hier müssen Sie alle externen Einheiten (Menschenund Systeme) festlegen, die mit dem System zusammenwirken und dieseInteraktionen definieren. Anschließend verwenden Sie diese Informationen, umdie Geschäftsrelevanz des Systems zu beurteilen. Wenn der Beitrag gering ist,kann das Projekt nach dieser Phase annulliert werden.D Entwurf: Die Ziele der Entwurfsphase liegen darin, ein Verständnis für den Problemhereichzu entwickeln, einen Architekturrahmen für das System festzulegen,den Projektplan zu entwickeln und die größten Risiken des Projekts zu erkennen.Wenn diese Phase abgeschlossen ist, sollten ein Anforderungsmodell für das System(zum Beispiel eine Menge von UML-Anwendungsfällen), eine Architekturbeschreibungund ein Entwicklungsplan für die Software vorhanden sein.D Konstruktion: Die Konstruktionsphase umfasst im Wesentlichen den Systementwurf,die Programmierung und Tests. Teile des Systems werden parallel entwickeltund während dieser Phase integriert. Wenn diese Phase abgeschlossen ist,sollte ein funktionierendes Softwaresystem mit entsprechender Dokumentationvorliegen, das nun an die Benutzer ausgeliefert werden kann.II Übergabe: In der letzten Phase des RUF wird das System von der Entwicklergemeinschaftan die Benutzergemeinschaft übergeben und in einer realen Umgebungbetrieben. Diese Phase wird bei den meisten Vorgehensmodellen ignoriert,ist jedoch eine teure und manchmal auch problematische Angelegenheit. NachAbschluss dieser Phase sollten Sie über ein Softwaresystem mit entsprechenderDokumentation verfügen, dass in seiner realen Arbeitsumgebung ordnungsgemäßfunktioniert.Konzeption Entwurf Konstruktion ÜbergabeAbbildung 2.12: Phasen im Rational Unified Process.Die Wiederholung innerhalb des RUP wird auf zwei Arten unterstützt. Jede Phasekann iterativ ausgeführt werden, wobei die Ergebnisse schrittweise entwickelt werden.Die Phasen können ebenfalls insgesamt iterativ ausgeführt werden, wie der inAbbildung 2.12 schleifenförmig verlaufende Pfeil als Übergang zur Konzeption verdeutlicht.Die statische Sicht des RUP konzentriert sich auf die Aktivitäten während des Entwicklungsprozesses.Diese werden in der RUF-Beschreibung als Arbeitsabläufebezeichnet. Der Prozess legt sechs Hauptarbeitsabläufe und drei unterstützendeArbeitsabläufe fest. Da der RUP in Verbindung mit der UML entworfen wurde, ist dieBeschreibung des Arbeitsablaufs auf die verbundenen UML-Modelle wie Sequenzmodelle,Objektmodelle usw. ausgerichtet. Die Hauptarbeitsabläufe der Entwicklungund die unterstützenden Arbeitsabläufe werden in.,. Abbildung 2.13 beschrieben.

SoftwareprozesseArbeitsablaufGeschäftsprozessmodellierung(Business Modeling)Anforderungsanalyse(Requirements)Analyse und Entwurf(Analysis & Design)Implementierung(lmplementation)Tests (Test)Auslieferung (OeploymenfJ--------------------------Konfigurations- und Änderungsmanagement( Configuration &Change Management)Projektmanagement(Project Management)Infrastruktur (Environment)BeschreibungAbbildung 2.13: Statische Arbeitsabläufe im Rational Unified Process.Die Geschäftsprozesse werden mit Geschäftsanwendungsfällenmodelliert.Es werden Akteure bestimmt, die mit dem System interagieren, undAnwendungsfälle entwickelt, um die Systemanforderungen zumodellieren.Unter Zuhilfenahme von Architekturmodellen, Komponentenmodellen,Objektmodellen und Ablaufmodellen wird ein Entwurfsmodell erzeugtund dokumentiert.Die Komponenten im System werden in Subsysteme implementiert undstrukturiert. Durch automatische Codegenerierung aus Entwurfsmodellenwird dieser Prozess beschleunigt.Beim Testen handelt es sich um einen iterativen Prozess, der in Verbindungmit der Implementierung ausgeführt wird. Wenn die Implementierungabgeschlossen ist, werden die Systemtests durchgeführt.Ein Produkt wird freigegeben, an Benutzer verteilt und an derenArbeitsplatz installiert.Dieser unterstützende Arbeitsablauf verwaltet Systemänderungen(siehe Kapite/25).Dieser unterstützende Arbeitsablauf verwaltet die Systementwicklung(siehe Kapite/21und 23).Bei diesem Arbeitsablauf werden dem Softwareentwicklungsteamdie entsprechenden Softwarewerkzeuge zur Verfügung gestellt.Der Vorteil von dynamischen und statischen Sichten liegt darin, dass die Phasen desEntwicklungsprozesses nicht mit spezifischen Arbeitsabläufen verbunden sind.Zumindest in der Theorie können alle RUP-Arbeitsabläufe in allen Phasen des Prozessesaktiv sein. In den frühen Phasen des Prozesses wird der größte Aufwand inArbeitsabläufe wie Geschäftsprozessmodellierung und Anforderungsanalyse fließen,in späteren Phasen in Tests und Auslieferung.Die praxisbezogene Perspektive des RUF beschreibt empfohlene Vergehensweisen fürdas Software-Engineering zum Einsatz bei der Systementwicklung. Sechs grundlegendeVergehensweisen werden empfohlen:D Software iterativ entwickeln: Schrittweise Planung des Systems ausgehend vonden Prioritäten des Kunden sowie Entwicklung der Systemfunktionen mit derhöchsten Priorität in einer frühen Phase des Entwicklungsprozesses.D Anforderungen verwalten: Eindeutige Dokumentation der Kundenanforderungensowie Verfolgung der geänderten Anforderungen. Analyse der Auswirkungendieser Änderungen auf das System, bevor diese angenommen werden.D Komponentenbasierte Architekturen verwenden: Aufteilung der Systemarchitekturin Komponenten, wie bereits zuvor in diesem Kapitel erläutert.

ZusammenfassungII Software visuell modellieren: Verwenden grafischer UML-Modelle zur Darstellungstatischer und dynamischer Sichten der Software.D Softwarequalität verifizieren: Sicherstellen, dass die Software die Qualitätsstandardsdes Unternehmens erfüllt.111 Änderungen der Software steuern: Verwaltung der Softwareänderungen mithilfeeines Änderungsmanagementsystems und Konfigurationsverwaltungsverfah.renssowie den dazu notwendigen Werkzeugen.Der RUP ist nicht für alle Entwicklungstypen geeignet, z. B. nicht für die Entwicklungeingebetteter Software. Er stellt jedoch einen Ansatz dar, de.r potenziell die drei allgemeinenVorgehensmodelle kombiniert, die in Abschnitt 2.1 besprochen wurden. Diewichtigsten Neuerungen betreffen die Trennung der Phasen und Arbeitsabläufe sowiedie Erkenntnis, dass die Bereitstellung der Software in einer Benutzerumgebung Teildes Prozesses ist. Phasen sind dynamisch und haben Ziele. Arbeitsabläufe sind statischund sind fachliche Aktivitäten, die nicht mit einer einzelnen Phase verknüpftsind, sondern während der Entwicklung verwendet werden können, um die Ziele dereinzelnen Phasen zu erreichen.Zusammenfassung• Softwareprozesse sind die Aktivitäten, die bei der Erstellung von Softwaresystemen beteiligtsind. Vorgehensmodelle sind abstrakte Darstellungen dieser Prozesse.• Allgemeine Vorgehensmodelle beschreiben den Aufbau von Softwareprozessen. Beispiele dieserallgemeinen Modelle sind das Wasserfallmodel I, inkrementeile Entwicklung und wiederverwendungsorientierteEntwicklung.• Die Anforderungsanalyse ist der Prozess, bei dem die Softwarespezifikation entwickelt wird.Spezifikationen dienen dazu, den Systementwicklern die Systemanforderungen des Kundenmitzuteilen.• Der Entwurfs- und Implementierungsprozess beschäftigt sich mit der Umwandlung der spezifiziertenAnforderungen in ein ausführbares Softwaresystem. Bei diesem Prozess können systematischeEntwurfsmethoden benutzt werden.• Die Softwarevalidierung ist der Prozess, bei dem überprüft wird, ob das System mit seiner Spezifikationübereinstimmt und ob es die wirklichen Bedürfnisse des Benutzers erfüllt• Die Weiterentwicklung von Software findet statt, wenn bestehende Softwaresysteme verändertwerden müssen, um an neue Anforderungen angepasst zu werden. Veränderungen kommenständig vor und die Software muss sich weiterentwickeln, um nützlich zu bleiben.• Prozesse sollten Aktivitäten enthalten, die den Umgang mit Änderungen unterstützen. Dazukönnte eine Prototypphase gehören, die hilft, falsche Entscheidungen bei Anforderungen undEntwurf zu vermeiden. Prozesse können für iterative Entwicklung und Auslieferung strukturiertsein, sodass Änderungen vorgenommen werden können, ohne das Gesamtsystem zu stören.• Beim Rational Unified Process handelt es sich um ein modernes allgemeines Vorgehensmodell,das zwar in Phasen unterteilt ist (Konzeption, Entwurf, Konstruktion und Übergabe), jedoch dieAktivitäten (Anforderungsanalyse, Analyse und Entwurf usw.) von diesen Phasen trennt.

SoftwareprozesseErgänzende LiteraturManaging Software Qua!ity and Business Risk. Dies ist in erster Linie ein Buch über Softwaremanagement,aber es enthält auch ein ausgezeichnetes Kapitel (Kapitel 4) über Prozessmodelle.(M. Ould, John Wiley & Sons, 1999.).. Process Models in Software Engineering". Dieser Artikel bietet einen ausgezeichneten Überblicküber eine breite Palette von möglichen Vorgehensmodellen im Software-Engineering. (W. Scacchiin Encydopaedia of Software Engineering, J.J. Marciniak (Hrsg.), John Wiley & Sons, 2001 .)http.:l!www.ics. uäedu!* * *wscacchi/Papers/SE-EncydProcess-Models-SE-Encyc.pdlThe Rational Unified Process - An lntroduction (3. Auflage). Derzeit das am besten zu lesendeBuch über RUP. Krutchen beschreibt den Prozess sehr ausführlich. Ich hätte mir allerdingsgewünscht, dass er verstärkt auf die Probleme eingegangen wäre, die die Verwendung dieses Prozessesin der Praxis mit sich bringen kann. (P. Krutchen, Addison-Wesley, 2003.)Übungen0 Schlagen Sie das am besten geeignete allgemeine Vorgehensmodell vor, das als Grundlagefür die Entwicklung der folgenden Systeme dienen kann. Begründen Sie Ihre Entscheidungauf der Basis des Systemtyps, der entwickelt wird:a. ein System, das bei einem Auto das Antiblockiersystem steuertb. ein Virtuai-Reality-System zur Unterstützung der Softwarewartungc. ein Buchhaltungssystem, das in einer Universität das bestehende System ersetztd. ein interaktives Reiseplanungssystem, das den Nutzern hilft, Reisen mit den geringstenAuswirkungen auf die Umwelt zu planenD Erklären Sie, warum inkrementeile Entwicklung der effektivste Ansatz für die Entwicklungvon Geschäftssystemen ist. Warum ist dieses Modell weniger geeignet für Echtzeitsysteme?D Betrachten Sie noch einmal das wiederverwendungsbasierte Vorgehensmodell aus Abbildung2.3. Erklären Sie, warum es entscheidend ist, zwei separate Aktivitäten zur Anforderungsanalysein dem Prozess zu haben.II Erklären Sie, warum es wichtig ist, während der Anforderungsanalyse zwischen der Entwicklungder Benutzeranforderungen und der Entwicklung der Systemanforderungen zu unterscheiden.II Beschreiben Sie die Hauptabläufe im Softwareentwurfsprozess und ihre Ergebnisse. ZeigenSie mithilfe eines Diagramms die möglichen Beziehungen zwischen den Ergebnissen dieserAktivitäten auf.II Erklären Sie, warum Änderungen in komplexen Systemen unvermeidlich sind und geben SieBeispiele von Softwareprozessaktivitäten (abgesehen von Prototypen und inkrementeHerAuslieferung), die helfen Änderungen vorherzusagen und die die zu entwickelnde Softwarerobuster gegenüber Änderungen machen.

ÜbungenD Erklären Sie, warum Systeme, die als Prototypen entwickelt wurden, normalerweise nicht alsProduktionssysteme benutzt werden sollten .D Erklären Sie, warum das Spiralmodell nach Boehm ein anpassungsfähiges Modell ist, das sowohlAktivitäten zur Vermeidung von Änderungen als auch zur Änderungstoleranz unterstützt.ln der Praxis wurde dieses Modell nicht häufig eingesetzt. Überlegen Sie, warum diesso ist.D Worin liegen im Rational Unified Process die Vorteile statischer und dynamischer Sichten imVergehensmodellen?li!] Historisch gesehen hat die Einführung von Technologien tief greifende Auswirkungen aufden Arbeitsmarkt gehabt und, zumindest zeitweilig, Menschen ihren Arbeitsplatz weggenommen.Diskutieren Sie, ob die Einführung von umfassender Prozessautomatisierungdieselben Auswirkungen für Softwareentwickler haben wird. Wenn Sie das nicht glauben,begründen Sie Ihre Meinung. Wenn Sie hingegen glauben, dass diese Technologie Karrierechanceneinschränken wird, ist es dann moralisch vertretbar, wenn die betroffenen Entwicklersich aktiv und passiv dagegen wehren?