SWE1 2 Softwareprozesse

Software Engineering 1
2: Softwareprozesse
Prof. Dr. rer. nat. Alex Reichenbach

Themen der Veranstaltung
1. Prozessmodelle
2. Prozessaktivitäten
3. Umgang mit Änderungen und der Rational Unified Process
4. Verbesserung der Prozesse
Lernziele
 Verständnis von Softwareprozessen und Prozessmodellen für Software
 Kenntnis von 3 generischen Prozessmodellen und ihrer Anwendung
 Kenntnis der grundlegenden Prozessaktivitäten bei Anforderungsanalyse
(Requirements Eng.), Entwicklung, Test und Weiterentwicklung (Evolution)
 Verständnis, warum Umgang mit Änderungen ein integraler Bestandteil ist
Informatik, Software Engineering 1, A. Reichenbach Seite 2
Softwareprozesse
 Ende 60er: Softwareentwicklung als Kunst

 Situation: Software Misere unerträglich
 ➔ Softwareentwicklung als Ingenieursdisziplin
 NATO Konferenz 1969: Begriff des Software

Engineerings
 Einführung eines Prozessmodells für Software
Engineering

Der Softwareprozess
Definition: Ein Softwareprozess ist ein strukturiertes Set

zusammengehöriger Aktivitäten, die benötigt werden, um
ein Software-System zu entwickeln.
Es gibt viele verschiedene Softwareprozesse, aber alle

beinhalten vier grundlegende Aktivitäten:
Spezifikation, Entwurf, Validierung, Evolution

Grundlegende Aktivitäten in SW Prozessen
 Spezifikation
 Kunden und Entwickler definieren, was das System machen soll.
 Entwurf (Design) und Implementierung
 Definition der Organisation des Systems und seine Implementierung.
 Validierung
 Sicherstellen, daß die Spezifikationen erfüllt sind
(und die Kundenanforderungen).
 Evolution
 Anpassung des Systems aufgrund von Änderungen der Kunden- und
Marktanforderungen.

Software Prozessmodell
Definition: Ein Software Prozessmodell ist eine abstrakte

Repräsentation eines Prozesses. Es liefert die
Beschreibung eines Prozesses aus einer bestimmten
Perspektive.

Beschreibungen eines SW Prozesses
Außer „offensichtlichen“ Aktivitäten wie „Spezifikation eines

Datenmodells“ oder „Design einer Benutzerschnittstelle“ können
Beschreibungen eines SW Prozesses noch Folgendes beinhalten:
 Produkte, die das Ergebnis einer Prozessaktivität sind, zB

Architekturmodell, Software-Package
 Rollen, die die Verantwortlichkeiten der zuständigen Personen
definieren, zB Projektmanager, Entwickler
 Vor- und Nachbedingungen für Prozessaktivitäten, zB
Fertigstellung oder Aufnahme einer anderen Aktivität

Plangesteuerte und agile Prozesse
 Bei plangesteuerten Prozessen werden alle Aktivitäten

im Vorfeld geplant und der Projekt-Fortschritt wird
gegen diesen Plan gemessen.
 Bei agilen Prozessen wird inkrementell geplant, damit
läßt sich der Prozess einfacher veränderbaren
Kundenanforderungen anpassen.
 In der Praxis bestehen die meisten Prozesse auf einer
Mischung beider Strategien.
 Es gibt keine richtigen oder falsche Softwareprozesse!
Software Prozessmodelle
 Das Wasserfallmodell (waterfall model)

 Plangesteuerter Prozess.
 Abgegrenzte Phasen von Spezifikation und Entwicklung.
 Inkrementelle Entwicklung (incremental development)
 Spezifikation, Entwicklung und Validierung sind verzahnt.
 Das System wird als Folge von Versionen (Inkrementen) mit zunehmender
Funktionalität entwickelt. Kann plangesteuert oder agile sein.
 Integration und Konfiguration (re-use oriented SW engineering)
 Das System wird vorrangig aus vorhandenen, konfigurierbaren Komponenten
zusammengesetzt. Kann plangesteuert oder agile sein.
 In der Praxis werden große Systeme meist nach einem hybriden
Prozessmodell entwickelt.
Das Wasserfallmodell
Erstes veröffentlichtes Modell für
Softwareentwicklung (Royce, 1970).
Anforderungs-
analyse und
-definition
Entwurf des
Systems und
der Software
Implementierung
und
Modultests
Integration
und
Systemtests
Informatik, Software Engineering 1, A. Reichenbach Betrieb und Wartung Seite 10
Phasen des Wasserfallmodells
1. Anforderungsanalyse und -definition

 Anforderungen werden identifiziert und
die Dienstleistungen, Einschränkungen
und Ziele des Systems werden in
Zusammenarbeit mit den System-
benutzern aufgestellt.
 Dann Detailierung der Anforderungen und Definition der
Systemspezifikationen.

2. Entwurf des Systems und der

Software
 Beim Systementwurf werden
die Anforderungen entweder Hardware-
oder Softwaresystemen zugewiesen, indem
eine übergeordnete Systemarchitektur
festgelegt wird.
 Der Softwareentwurf konzentriert sich auf das Erkennen und
Beschreiben der grundlegenden abstrakten Softwaresysteme
und ihrer Beziehung untereinander.

3. Implementierung und Modultests

 Der Softwareentwurf wird durch eine
Menge an Programmen und Programm-
einheiten (Module) umgesetzt.
 Jedes Modul wird einzeln getestet ➔ Modultest
 Der Modultest stellt sicher, dass jede Einheit seine Spezifikation
erfüllt.

4. Integration und Systemtests

 Die ganzen Programmeinheiten werden
integriert und als Ganzes getestet
➔ Systemtest
 Der Systemtest stellt sicher, dass sämtliche
Softwareanforderungen erfüllt werden.
 Nach den Tests wird das System an den Kunden ausgeliefert
➔ Abnahmetests durch den Kunden

4. Betrieb und Wartung

 Ist normalerweise die längste Phase des
Produktlebenszyklus.
 Das System wird installiert und zum
Gebrauch freigegeben.
 Zur Wartung gehören
 Korrigieren bisher nicht entdeckter Fehler
 Verbesserung der Implementierung von Systemeinheiten
 Verbesserung des Systems im Falle neuer Anforderungen

Wasserfallmodell
 Jede Phase hat Start- und Endpunkte mit eindeutig

definierten Ergebnissen.
 In Meilensteinsitzungen am jeweiligen Phasenende
werden die Ergebnisdokumente verabschiedet
 Lastenheft
 Pflichtenheft
 Testprotokolle
 Produktdokumentation

Lastenheft (Anforderungsspezifikation)
 „Vom Auftraggeber festgelegte Gesamtheit der Forderungen an

die Lieferungen und Leistungen eines Auftragnehmers innerhalb
eines Auftrages“ (DIN 69901-5)
 Ergebnis einer Anforderungsanalyse
 Das Lastenheft beschreibt in der Regel, was und wofür etwas
gemacht werden soll.
 Formulierung der Anforderungen so allgemein wie möglich und so
einschränkend wie nötig.
 Auf Grundlage des Lastenhefts wird durch mögliche
Auftragnehmer ein Pflichtenheft erstellt.
 Was will der Kunde?
Pflichtenheft (Fachspezifikation)
 „Vom Auftragnehmer erarbeitetes Realisierungsvorhaben

aufgrund der Umsetzung des vom Auftraggeber vorgebenen
Lastenhefts.“ (DIN 69901-5)
 Beschreibt in konkreter Form, wie der Auftragnehmer die
Anforderungen des Auftraggebers zu lösen gedenkt, also das wie
und womit.
 Akzeptanz des Pflichtenhefts durch den Auftraggeber
➔ Beginn der Umsetzungsarbeit beim Auftragnehmer.
 Was genau wollen wir dem Kunden erstellen?

Probleme und Nachteile des Wasserfallmodells
 Abgrenzungsproblem
 Klar voneinander abgegrenzte Projektphasen sind oft unrealistisch
 Der Übergang zwischen den Phasen ist fließend: Teile des Systems können
sich noch in Planung befinden, während andere schon in der Implementierung
oder im Gebrauch sind.
 Abfolgeproblem
 Die nächste Phase sollte nicht beginnen, bevor die vorherige abgeschlossen
wurde. In der Praxis überlappen die Phasen.
 Softwareentwicklung ist kein einfacher, linearer Prozess, sondern umfaßt ua
Rückkopplungen ➔ ggf Aktualisierung von Dokumente

Probleme und Nachteile des Wasserfallmodells
 Unflexibel gegenüber Änderungen und im Vorgehen.

 Frühes Festschreiben der Anforderungen oft problematisch, da bei
(wahrscheinlichen) Änderungen hohe Kosten entstehen.
 Software wird erst lange nach Beginn des Entwicklungszyklus
tatsächlich eingeführt und genutzt
 später Return on Investment
 Einführung des vollständigen Systems zu einem bestimmten
Zeitpunkt (Big Bang)
 Fehler können erst spät erkannt werden
AIB, Software Engineering 1, Massold/Krauskopf Seite 20

Vorteile des Wasserfallmodells
 Transparenter Prozess (klare Abgrenzung der Phasen)

 Erzeugt in jeder Phase Dokumentationen. Projektfortschritt kann
gegenüber dem Entwicklungsplan geprüft werden.
 Sehr effektives Modell bei stabilen Anforderungen und klarer
Abschätzung von Kosten und Umfang.
 Bei Großprojekten mit paralleler Entwicklung an verschiedenen
Standorten hilft so ein Vorgehen bei der Koordination der
Teilprojekte.

Wasserfallmodell mit Rücksprung
 Hauptproblem des Wasserfallmodells

 Starre Aufteilung des Projekts in verschiedene Phasen
 Es müssen früh Verbindlichkeiten eingegangen werden, was es schwer macht,
auf neuen Kundenanforderungen zu reagieren.
➔ Weiterentwicklung zum
Wasserfallmodell mit Rücksprung
➔ Erweiterung um iterative Aspekte

Wasserfallmodell
Fazit
Das Wasserfallmodell sollte nur verwendet werden, wenn
die Anforderungen sehr genau spezifiziert sind und sich
sehr wahrscheinlich während der Entwicklung nicht
ändern. Sehr kompakte, kritische Systeme profitieren uU
von sehr detailierter früher Anforderungsanalyse und
integrativem Entwurf des Gesamtsytems.

Inkrementelle Entwicklung

Inkrementelle Entwicklung
 Wird heutzutage am Häufigsten eingesetzt

 Im plangesteuerten Ansatz
 Systeminkremente werden im Voraus bestimmt
 Im agilen Ansatz
 Frühe Systeminkremente werden ermittelt
 Die Entwicklung späterer Inkremente hängt vom
Projektfortschritt und den Prioritäten des Kunden ab.

Vorteile inkrementeller Entwicklung
 Jedes Inkrement enthält einen (weiteren) Teil der Funktionalität.

 Anpassungen an Anforderungsänderungen ist leichter möglich.
 Es muß wesentlich weniger Analyse und Dokumentation neu gemacht werden
als beim Wasserfallmodell.
 Rückmeldungen des Kunden lassen sich einfacher anhand bereits
fertiggestellter und getesteter Teile einholen und integrieren.
 Kunden können den aktuellen Entwicklungsstand während Demonstrationen
einsehen und kommentieren.
 Bereits nutzbare Software (mit Teilfunktionalität) kann schneller
ausgeliefert werden.
 Kunden erhalten früher Zugang zu und Nutzen von der Software als es mit
dem Wasserfallmodell möglich wäre.
Nachteile inkrementeller Entwicklung
Aus Managementsicht
 Der Prozess ist nicht sichtbar.
 Manager benötigen regelmäßig Deliverables, um den Forschritt zu messen.
 Wenn Systeme schnell entwickelt werden, sind Dokumente jeder Version des
Systems nicht kosteneffizient.
 Die Struktur des Systems wird wahrscheinlich mit dem
Hinzufügen neuer Inkremente langsam inkonsistent.
 Außer: Es werden Zeit und Kosten für Refactoring aufgewendet.
 Ansonsten: Regelmäßige Änderungen führen zu Inkonsistenzen in der Struktur
und neue Änderungen einzupflegen wird immer aufwändiger und teurer.
 Inkrementelle Auslieferung ist in der Praxis schwierig
 Einrichten und testen von Inkrementen stört ggf normale Arbeitsabläufe.
Nachteile inkrementeller Entwicklung
Aus organisatorischer Sicht

 Große Organisationen haben bürokratische Handlungsabläufe,
die sich im Laufe der Jahre etabliert haben
➔ oft Widerspruch zur inkrementellen Entwicklung
 Bürokratische Handlungsabläufe basieren oft auf gesetzlichen
Regelungen
 Vorschriften zur Rechnungslegung
 Veränderungen von Geschäftsabläufen sind wegen Abhängigkeiten zwischen
verschiedenen Prozessen uU nicht möglich.

Integration und Konfiguration
 Vorwort: In einem Großteil der Softwareprojekte wird Quellcode

sowieso (oft informell) wiederverwendet.
 Der Ansatz basiert auf Software Wiederverwendung (re-use) und
schafft Systeme, die vorwiegend aus der Integration von bereits
existierenden Komponenten oder Anwendungssystemen bestehen.
 Diese Komponenten sind meist zur Wiederverwendung geschaffen.
 Die wiederverwendeten Elemente können uU konfiguriert werden,
um ihre Funktionalität an spezifische Kundenanforderungen
anzupassen.
 Ist heutzutage ein gängiger Ansatz, um viele Arten von
Unternehmensanwendungssoftware zu erstellen.
Arten wiederverwendbarer Software
 Stand-alone Anwendungen, die nur noch konfiguriert

werden müssen (manchmal COTS – commercial-off-
the-shelf – genannt)
 Sammlung von Objekten, die als Package entwickelt
wurden, um mit einem Komponenten Framework wie
.NET oder J2EE integriert zu werden.
 Web Services, die gemäß Service Standards
entwickelt wurden und die remote ausgeführt werden.

Wiederverwendungsorientierte SW Entwicklung
 Spezifizierung der Anforderungen

 Passende Software finden und evaluieren
 Anforderungen anpassen
 Konfiguration des Anwendungssystems
 Adaptation und Integration der Komponenten
Vor- und Nachteile von Wiederverwendung
+ Reduzierte Kosten und Risiken, da weniger

Software von Grund auf entwickelt wird.
+ Schnellere Auslieferung und Einsatz des Systems.
− Kompromisse bzgl der Anforderungen sind
unumgänglich, so dass die Benutzeranforderungen
ggf nicht voll erfüllt sind.
− Keine Kontrolle über die Weiterentwicklung der
benutzen Elemente.

Diskussion
 Welches generische Softwareprozessmodell würden Sie für die

folgenden Systeme verwenden und wieso?
 Das ABS System eines Autos
 Ein Buchhaltungssystem für die Hochschule, welches ein Altsystem ersetzt
 Ein interaktives Reiseplanungssystem, welches dem Benutzer hilft, seine
Reise mit möglichst geringem CO2 Footprint zu planen
 Warum benötigt man bei dem Wiederverwendungsansatz 2

unterschiedliche Anforderungsanalysen?

Prozessaktivitäten
 Reale Softwareprozesse bestehen aus einer verzahnten Abfolge

von technischen, kollaborativen und Management Aktivitäten mit
dem Endziel, ein Softwaresystem zu spezifizieren, entwerfen,
implementieren und testen.
 Die vier grundlegenden Prozessaktivitäten (Spezifikation,
Entwicklung, Validierung und Evolution) sind in jedem realen
Entwicklungsprozess anders organisiert.

Die Anforderungsanalyse (Requirements Engineering)

Software Spezifikation
Definition: Die Software Spezifikation ist der Prozess in

dem festgelegt wird, welche Funktionalitäten benötigt
werden und unter welchen Bedingungen das System
entwickelt und betrieben werden soll.
 Benutzeranforderungen
 Grobe Aufstellung der Anforderungen aus Endbenutzersicht.
 Systemanforderungen
 Detailierte Aufstellung der Anforderungen unter Einbeziehung der
Systemumgebung.

 Erhebung und Analyse der Anforderungen

 Was benötigen die „Stakeholder“ bzw was erwarten sie?
Stakeholder: Jeder, der von dem System betroffen ist.
 Spezifikation der Anforderungen
 Detailierung der Anforderungen
 Validierung der Anforderungen
 Überprüfung der Gültigkeit der
Anforderungen

1. Erhebung und Analyse der

Anforderungen
 Ableitung der Systemanforderungen
 Beobachtung bestehender Systeme
 Interviews mit potentiellen Benutzern bzw Käufern
 Aufgabenanalyse
 etc
 Entwicklung eines oder mehrerer Systemmodelle und
Prototypen kann nötig sein ➔ Verbesserung des
Verständnisses des zu spezifizierenden Systems.

2. Spezifikation der Anforderungen

 Umsetzung der in der Analyse
gesammelten Informationen in ein
Dokument (Anforderungsspezifikation)
 Zwei Arten von Anforderungen
 Benutzeranforderungen: abstrakte Beschreibung des
Systemanforderungen für den Kunden und den Endbenutzer.
 Systemanforderungen: detailierte Auflistung der Funktionen, die
das System zur Verfügung stellen soll.

3. Validierung der Anforderungen

 Prüfen, ob Anforderungen realistisch,
konsistent und vollständig sind
 Erkennung von Inkonsistenzen und Fehlern
in der Anforderungsspezifikation.
 Änderung der Anforderungsspezifikation hinsichtlich der
gefundenen Fehler.

Software Entwurf und Implementierung
Definition: Entwurf und Implementierung bedeutet, aus

der Systemspezifikation ein lauffähiges System zu
erstellen.
 Software Entwurf (Design)

 Entwurf einer Softwarestruktur, die die Spezifikation verwirklicht.
 Implementierung (Erstellung)
 Übersetzung der Struktur in ein lauffähiges Programm.
 Entwurf und Implementierung sind iterative Prozesse, die in einer
engen Beziehung stehen und miteinander verwoben sein können.

Generelles Modell eines Entwurfsprozesses

Entwurfsaktivitäten
 Entwurf der Architektur

 Entwurf der Gesamtstruktur des Systems, Aufteilung in Hauptkomponenten
(Untersysteme oder Module), Definition ihrer Beziehungen zueinander und
ihrer Verteilung.
 Entwurf der Datenbank bzw Datenstrukturen
 Entwurf der Datenstrukturen und wie diese, wenn
zutreffend, in einer Datenbank repräsentiert werden.
 Entwurf der Schnittstellen
 Definition der Schnittstellen zwischen den Komponenten.
 Auswahl und Entwurf der Komponenten
 Suche nach wiederverwertbaren Komponenten bzw wenn nicht verfügbar,
Entwurf der Funktionalität.

Implementierung
 Die Software wird entweder durch Eigenprogrammierung

oder durch Konfiguration von Komponenten erstellt.
 Entwurf und Implementierung ist bei den meisten
Software Systemen ein verzahnter Prozess.
 Programmierung ist eine individuelle Aktivität, die
keinem Standardprozess folgt.
Sie dürfen kreativ sein! ☺
 Debugging ist der Prozess, mit dem man Fehler im
Programm findet und behebt.
Validierung von Software
 Verifizierung und Validierung (V & V) soll belegen,

dass ein System seiner Spezifikation genügt und die
Anforderungen des Kunden erfüllt.
 V & V enthält Reviews und Systemtests.
 Für Systemtests werden auf Basis der Anforderungs-
dokumente Testfälle abgeleitet und von dem System
mit Testdaten verarbeitet.
 Testen ist die am häufigsten ausgeführte V & V
Aktivität.
Stufen des Testens
 Komponententests
 Individuelle Komponenten werden unanhängig voneinander getestet.
 Komponenten können Funktionen oder Objekte sein oder kohärente Gruppen
dieser Elemente.
 Entwicklertools zur Testautomatisierung: JUnit, NUnit, CppUnit etc
 Systemtests
 Test des Gesamtsystems.
 Test auf komponentenübergreifende Funktionen ist besonders wichtig.
 Kundentests (Akzeptanz- und Abnahmetests)
 Mit Kundendaten und Stakeholdern testen um zu evaluieren, ob das System
die Kundenanforderungen erfüllt.

Testphasen in einem plangesteuerten
SW Prozess (V-Modell)

Software Evolution
 Software ist von Natur aus flexibel und kann sich

ändern.
 Da sich Anforderungen durch Änderungen im
Geschäftsfeld ändern können, müssen sich
Geschäftsanwendungen weiterentwickeln können.
 Auch wenn Entwicklung und Evolution de facto
getrennte Aktivitäten sind, so wird diese Trennung
immer mehr nichtig, da immer weniger Systeme
komplett neu entwickelt werden.

Evolution eines Systems

Quellcode ändert sich immer ...
 Faustregel: Es ist einfacher (und spannender ☺) neuen Code zu

schreiben als den eigenen oder fremden Code zu warten oder
weiterzuentwickeln.
 Die meisten SW Entwickler hoffen, nie Code warten oder weiterentwickeln zu
müssen.
 Reality-Check: Genau das ist es aber, womit die meisten ihre Zeit
verbringen.
 Tipp: Es zahlt sich grundsätzlich aus, Code so einfach und

verständlich wie möglich zu halten – egal bei welcher
Vorgehensweise.

Diskussion
 Warum ist es wichtig, die Erhebung von

Benutzeranforderungen und Systemanforderungen zu
trennen?

Zusammenfassung
 Softwareprozesse sind die Aktivitäten, die für die

Produktion eines Softwaresystems nötig sind.
 Software Prozessmodelle sind eine abstrakte
Repräsentation dieser Prozesse.
 Generelle Prozessmodelle beschreiben die
Organisation von Softwareprozessen. Beispiele für
diese Prozessmodelle sind das Wasserfallmodell oder
inkrementelle Entwicklung.

Zusammenfassung
 In der Anforderungsanalyse wird die Spezifikation der Software

entwickelt.
 Entwurf und Implementierung setzen die spezifizieren
Anforderungen um mit dem Ergebnis eines lauffähigen Systems.
 Softwarevalidierung stellt sicher, dass das System den
Spezifikationen entspricht und den wahren Bedürfnissen der
Benutzer entspricht.
 Als Softwareevolution wird der Prozess bezeichnet, in dem das
System Änderungen erfährt, um neue Anforderungen zu erfüllen.
Fast jede Software muss sich weiterentwicklen um nützlich zu
bleiben.

Umgang mit Änderungen
 Änderungen sind in großen SW Projekten unvermeidbar.

 Veränderungen im Geschäftsfeld führen zu neuen oder veränderten
Systemanforderungen.
 Neue Technologien eröffnen neue Möglichkeiten, um die Implementierung zu
verbessern.
 Änderung von Plattformen ziehen Änderungen in den Anwendungen nach
sich.
 Um Änderungen umzusetzen, müssen sowohl die Anforderungen

neu analysiert werden als auch neue Funktionalitäten
implementiert werden.

Kosten von Änderungen reduzieren
 Änderungen antizipieren
 In den Softwareprozess Aktivitäten einbauen, mit denen mögliche Änderungen
abgefangen werden können bevor zu viel umgebaut werden muss.
 zB kann erst einmal ein Prototyp erstellt werden, mit dem Schlüssel-
anforderungen dem Kunden demonstriert und mit ihm abgeglichen werden
können.
 Toleranz gegenüber Änderungen
 Den Softwareprozess so aufsetzen, dass Änderungen mit möglichst kleinen
Kosten untergebracht werden können.
 Normalerweise durch einen inkrementellen Prozess abgebildet. Änderungen
können dann in noch nicht entwickelten Inkrementen mit implementiert
werden, bzw es muss nur einer der vorherigen Inkremente neu entwickelt
werden.

Umgang mit sich verändernden Anforderungen
 Prototyping
 Eine Vor-Version des Systems oder System-Teils wird schnell
entwickelt, um die Kundenanforderungen gegenzuprüfen und
die Machbarkeit der Entwurfsentscheidungen zu testen.
 Inkrementelle Auslieferung
 Das System wird Stück für Stück an den Kunden ausgeliefert,
der es ausprobieren kann und seine Meinung rückmeldet.

Prototyping
 Definition: Ein Prototyp ist eine initiale Version eines

Systems, die verwendet wird, um Konzepte zu
demonstrieren und Entwurfsoptionen auszuprobieren.
 Ein Prototyp kann verwendet werden, um
 Während der Anforderungsanalyse die Erhebung und
Validierung der Anforderungen zu unterstützen
 Während der Entwurfsphase verschiedene Optionen
auszuprobieren und eine Benutzerschnittstelle zu entwerfen
 Während des Testens die Tests direkt aufeinanderfolgend
laufen lassen zu können
Vorteile des Prototypings
 Erhöhte Benutzerfreundlichkeit
 Näher am wirklichen Bedarf der Nutzer
 Bessere Entwurfsqualität
 Bessere Wartbarkeit
 Weniger Entwicklungsaufwand

Der Prototyping Prozess

Entwicklung des Prototypen
 Es gibt für schnelles Entwickeln eines Prototypen

(rapid prototyping) spezielle Sprachen und Werkzeuge
 Für gewöhnlich werden Funktionen weggelassen
 Prototypen sind auf Teile des Produkts zugeschnitten, die nicht
ausreichend verstanden werden
 Fehlerbehandlung und Sicherungsmaßnahmen sind oft nicht in
einem Prototypen implementiert
 Fokus eher auf funktionalen Anforderungen als auf nicht-
funktionalen Anforderungen wie Zuverlässigkeit oder
Sicherheit

Prototypen wegschmeißen!
 Prototypen sollten nach Gebrauch entsorgt werden.

Sie sind keine gute Grundlage für das eigentliche
System:
 Nicht-funktionale Anforderungen können uU nicht sinnvoll
integriert werden
 Prototypen sind meist undokumentiert
 Die Struktur ist oft nach mehreren Änderungen inkonsistent
geworden
 Der Prototyp wird wahrscheinlich nicht den normalen
Qualitätskriterien der Organisation entsprechen.

Inkrementelle Vorgehensweise
 Entwicklung und Auslieferung wird in inkrementelle

Teilprodukte heruntergebrochen, von denen jedes
einen Teil der Funktionalität zur Verfügung stellt.
 Benutzeranforderungen werden priorisiert und in
absteigender Priorität in die Inkremente eingeplant.
 Sobald die Entwicklung eines Inkrements begonnen
hat, sind die Anforderungen für diesen Teil fix.
Anforderungen für spätere Inkremente können sich
jedoch weiterhin entwickeln.

Inkrementelle Entwicklung und Auslieferung
 Inkrementelle Entwicklung
 Inkrementelle Entwicklung des Systems und Evaluierung jedes Inkrements
bevor die Entwicklung des nächsten Inkrements in Angriff genommen wird.
 Das ist der Normalfall bei agilen Methoden
 Evaluierung wird von Stakeholdern durchgeführt
 Inkrementelle Auslieferung
 Einsatz eines Inkrements für den Gebrauch beim Endbenutzer
 Realistischere Evaluation bgl der praktischen SW Benutzung
 Ersatz-Systeme können normalerweise nicht so entwickelt werden, da die
frühen Inkremente weniger Funktionalität als das Altsystem bereitstellt

Inkrementelle Auslieferung

Vorteile inkrementeller Auslieferung
 Der Kunde erhält mit jedem Inkrement einen

Gegenwert, dh bereits recht früh nutzbare Funktionen.
 Frühe Inkremente übernehmen Aufgaben eines
Prototypen und helfen die Anforderungen für spätere
Inkremente genauer zu spezifizieren.
 Geringeres Risiko eines kompletten Scheitern des
Gesamtprojekts.
 Die Systemfunktionalitäten mit der höchsten Priorität
werden automatisch am meisten getestet.
Probleme bei inkrementeller Auslieferung
 Viele Systeme benötigen ein Set grundlegender Funktionen, die

von verschiedenen Teilen des Systems genutzt werden
 Diese Funktionen können anfangs nicht so einfach identifiziert werden, da die
Anforderungen an Teile des Systems immer erst vor dem entsprechenden
Inkrement detailiert geplant werden.
 Das Wesen inkrementeller Prozesse besteht darin, dass die
Spezifikation parallel zur Implementierung der Software stattfindet
 Das widerspricht in den meisten Firmen den Richtlinien der
Beschaffungsabteilungen, da die Spezifikation des Systems meist essentieller
Teil des Vertrags ist.

Fazit inkrementelle Auslieferung
 Inkrementelle Entwicklung und Auslieferung ist für

folgende Systeme nicht das beste Vorgehensmodell
 Sehr große Systeme
 Viele Teams sind parallel an der Entwicklung beteiligt
 Verschiedene Orte der Entwicklung
 Eingebettete Systeme
 Software hängt von der Hardwareentwicklung ab
 Kritische Systeme
 Alle Anforderungen müssen zuerst komplett und sauber analysiert
sein, um Information- und Betriebssicherheit zu gewährleisten

Spiralmodell
nach Boehm
(1988)
Kombiniert die
Vermeidung von
Änderungen mit
Änderungstoleranz

Die Phasen des Spiralmodells
1. Festlegung der Ziele 1. 2.

 Spezifische Ziele für die nächste Phase
werden identifiziert und festgelegt.
2. Einschätzung und Verringerung der Risiken
 Risiken werden geschätzt und Maßnahmen
ergriffen, die größten Risiken zu minimieren.
3.
4.
3. Entwicklung und Validierung
 Ein Entwicklungsmodell wird gewählt, welches jedes der generischen Modelle
sein kann.
4. Planung
 Das Projekt wird überprüft und der nächste Umlauf der Spirale wird geplant.

Das Spiralmodell
 Großer Einfluß des Modells bei der Entwicklung

iterativer Modelle und Überlegungen zu risiko-
getriebenen Ansätzen in der Softwareentwicklung.
 Historisch – zu der Zeit wurde oft
 redundant entwickelt
 Benutzeranforderungen ignoriert
 unzuverlässige Software entwickelt
 ein Softwareprojekt ziemlich teuer
 Das Modell in Reinform wird selten für praktische

Softwareprojekte eingesetzt.
Vorteile des Spiralmodells
 Regelmäßige Überprüfung und uU neue Festlegung

des Prozessmodells, dieses ist nicht für die gesamte
Dauer des Projekts festgelegt.
 Erleichtert Wiederverwendung von Software durch
Betrachtung von Alternativen.
 Ermöglicht frühes Erkennen von Fehlern.
 Betont Qualitätsziele
 Integriert Entwicklung und Wartung

Nachteile des Spiralmodells
 Hoher Managementaufwand
 Für kleinere und mittlere Projekte eher nicht geeignet
 Oft nicht anwendbar, wenn ein anderes Modell mit
entsprechender Dokumentation vertraglich verienbart
ist.
 Erfordert Erfahrung in der Risikoschätzung.
 Muss für den Einsatz verfeinert werden.

Diskussion
 Schlagen Sie weitere Aktivitäten vor, die fortlaufende

Veränderungen der Software unterstützen können.

Der Rational Unified Process (RUP)
 Objektorientiertes, aktivitätsgetriebenes Vorgehensmodell

 Hybridmodell aus den 3 generischen Modellen
 Entstanden durch Arbeit an der UML (Unified
Modeling Language) und ähnlichen Prozessen
 UML: grafische Modellierungssprache zur Spezifikation,
Konstruktion und Dokumentation von Software (s. nächste VL)
 Beschreibt üblicherweise 3 Perspektiven
 Dynamische P.: beschreibt die Phasen über die Zeit hinweg
 Statische P.: beschreibt die ausgeführten Prozessaktivitäten
 Praxisbezogene P.: empfiehlt Vorgehensweisen (good practice)Seite 74
Informatik, Software Engineering 1, A. Reichenbach
Phasen im Rational Unified Process
Iteration der Phasen
Anfangs- Ausarbeitung Entwicklungs- Umstellung

phase phase
 Dynamische Perspektive

Phasen im RUP Iteration der Phasen
 Anfangsphase
Anfangs- Ausarbeitung Entwicklungs- Umstellung
phase phase
 Einrichten des Geschäftsfalls (business case) für das System.

 Ausarbeitung
 Verständnis für die Anwendungsdomäne und die
Systemarchitektur entwickeln.
 Entwicklungsphase
 Entwicklung des Systems, Implementierung und Test.
 Umstellung
 Das System in der Geschäftsumgebung zum Einsatz bringen.
Iterationen im RUP
 Iterationen innerhalb einer Phase

 Jede Phase in sich läuft iterativ ab.
 Die Ergebnisse werden inkrementell entwickelt.
 Phasenübergreifende Iterationen
 Die Gesamtheit der Phasen kann inkrementell immer wieder
iteriert werden.

Statische Arbeitsabläufe im RUP
Arbeitsablauf Beschreibung
Business Modeling Die Geschäftsprozesse werden mittels Geschäfts-
anwendungsfällen (business use cases) modelliert.
Anforderungen Mit dem System interagierende Aktoren werden
identifiziert und Anwendungsfälle (use cases), die die
Systemanforderungen modellieren, werden entwickelt.
Analyse & Design Ein Entwurfsmodell wird erstellt und mittels diverser
(Entwurf) Modelle dokumentiert: Architekturmodelle, Kompo-
nentenmodelle, Objektmodelle und Sequenzmodelle
Implementierung Die Komponenten werden in strukturierten Unter-
Systemen implementiert. Code kann tlw von den
Entwurfsmodellen automatisch generiert werden.

Statische Arbeitsabläufe im RUP
Arbeitsablauf Beschreibung
Test Testung ist ein interativer Prozess, der mit der
Implementierung verzahnt ist. Der Systemtest folgt der
Fertigstellung des Systems.
Bereitstellung Ein Release wird erstellt, auf den entsprechenden
(deployment) Rechnern installiert und an die Benutzer verteilt.
Konfiguration und Unterstützender Arbeitsablauf, der sich mit
Change Management Änderungen des Systems befaßt.
Projektmanagement Unterstützender Arbeitsablauf, der die Entwicklung des
Systems verwaltet.
Umgebung Dieser Arbeitsablauf sorgt dafür, dass das
Entwicklungsteam die benötigten Ressourcen hat.

Zusammenhang von dynamischer und statischer Perspektive
wikipedia.org
Empfohlene Vorgehensweisen im RUP
 Entwickle Software iterativ

 Plane die Inkremente auf der Basis der Kundenprioritäten und
liefere Funktionalität mit höchster Priorität vorrangig aus.
 Verwalte die Anforderungen
 Kundenanforderungen sowie ihre Änderungen müssen explizit
dokumentiert sein.
 Benutze komponentenbasierte Architekturen
 Organisiere die Systemarchitektur als Set wiederverwendbarer
Komponenten.

Empfohlene Vorgehensweisen im RUP
 Modelliere Software graphisch

 Benutze graphische UML Modelle um statische und
dynamische Aspekte der Software darzustellen.
 Verifiziere die Software Qualität
 Versichere Dich, dass die Software den Qualitätsstandards
des Auftrags- und Arbeitgebers entspricht.
 Kontrolliere Änderungen der Software
 Verwalte Softwareänderungen mit einem System für
Änderungs- und Konfigurationsmanagement.

Fazit Rational Unified Process
 Wichtigeste Neuerungen
 Trennung der Phasen und Prozessaktivitäten
 Phasen sind dynamisch und haben Ziele
 Arbeitsabläufe sind statisch und sind fachliche Aktivitäten, die nicht mit einer
einzelnen Phase verknüpft sind. Sie können während der Entwicklung
verwendet werden, um Ziele der einzelnen Phasen zu erreichen.
 Erkenntnis, dass Bereitstellung der Software in einer Benutzerumgebung Teil
des Prozesses ist
 Empfehlung
 RUP ist nicht für alle Entwicklungstypen geeignet
 zB nicht für die Entwicklung von eingebetteter Software
 RUP stellt jedoch einen Ansatz dar, der potentiell die drei allgemeinen
Vorgehensmodelle mit ihren Stärken kombiniert.
Diskussion
 Was ist der Vorteil davon, statische und dynamische

Sichten im RUP voneinander zu trennen?

Verbesserung von Prozessen
 Nicht nur Software entwickelt sich weiter, sondern

auch die Prozesse zur Entwicklung von Software.
 Softwareprozesse werden verbessert, um Qualität
 die Qualität von Software zuverbessern

 Kosten zu senken
 den Entwicklungsprozess zu beschleunigen Kosten Zeit
 Prozesse zu verbessern bedeutet, bestehende

Prozesse zu verstehen und diese dann anzupassen.

Verbesserungsansätze
 Prozessreifungsansatz
 Konzentriert sich auf die Verbesserung von Prozess- und Projektmanagement
und die Umsetzung passender und bewährter Software Engineering Praktiken.
 Der Prozessreifegrad zeigt an, in wie weit technische und Management-
Praktiken im Software Entwicklungsprozess umgesetzt worden sind.
 Agiler Ansatz (➔ Vertiefung am Ende des Semesters)
 Konzentriert sich auf iterative Entwicklung und Reduktion von Overhead im
Software Entwicklungsprozess.
 Hauptcharakteristik agiler Methoden sind die rasche Auslieferung von
Funktionalität und starke Ausrichtung auf Einbeziehung von Anforderungs-
änderungen.

Aktivitäten zur Prozessverbesserung
 Messen des Prozesses

 Messung von einem oder mehreren Attributen des Software
Prozesses oder Produkts ➔ Baseline für die Evaluierung
der Effektivität der Änderung.
 Analysieren des Prozesses
 Der aktuelle Prozess wird beurteilt und Schwächen sowie
Flaschenhals-Aktivitäten werden identifiziert. Prozessmodelle
zur Visualisierung des aktuellen Prozesses werden entwickelt.
 Ändern des Prozesses
 Voschlag von Prozessänderungen, die eine oder mehrer der Schwächen
adressieren. Nach Einführung der Änderung geht es wieder zum Messen, um
die Effektivität der Prozessänderung zu evaluieren.

Messen des Prozesses
 Sofern möglich, sollen quantitative Prozessmeßdaten (Metriken)

erhoben werden
 Wenn keine klar definierten Prozess-Standards vorhanden sind, müssen diese
erst einmal implementiert werden, bevor irgendwelche Messungen möglich
sind.
 Die Prozessmeßdaten sollen benutzt werden, um
Prozessverbesserungen zu evaluieren
 Es sollen nicht die Prozesse verändert werden, um die Prozessmeßdaten zu
verbessern!
 Der Antrieb hinter den Verbesserungen sollen sich aus Unternehmenszielen
herleiten.
 Hier kommen empirische Methoden zum Einsatz ...

Beispiele für Metriken
 Zeit
 die eine Prozessaktivität benötigt
 zB Zeitspanne oder benötigte Leistung zur Fertigstellung einer Aktivität oder
eines Prozesses
 Ressourcen
 die für einen Prozess oder eine Aktivität benötigt werden
 zB Gesamtleistung in Personentagen
 Häufigkeit
 des Auftretens bestimmter Ereignisse
 zB Anzahl entdeckter Fehler

Reifegrad der Kompetenz

Das CMU (SEI) Reifegradmodell (CMM)
 Das Capability Maturity Model (CMM) wurde ab 1986 am Software Engineering
Institute (SEI) der Carnegie Mellon University (CMU) entwickelt.
 Initiale Stufe: unkontrolliert
 Wiederholbare / gesteuerte Stufe
 Produktmanagement Prozeduren sind definiert und werden umgesetzt
 Definierte Stufe
 Produktmanagement Prozeduren und Strategien sind definiert und werden umgesetzt
 Gesteuerte / quantitativ gesteuerte Stufe
 Qualitätsmanagement Strategien sind definiert und werden umgesetzt
 Optimierende Stufe
 Strategien für Prozessverbesserungen sind definiert und werden umgesetzt
Diskussion
 Was sind die Vor- und Nachteile der Umsetzung des

Reifegradmodells?

Zusammenfassung
 Prozesse sollten Aktivitäten enthalten, die mit Anforderungs-

änderungen umgehen können. Prototypen sind nützlich, um sub-
optimale Entscheidungen bzgl Anforderungen und Entwurf zu
vermeiden.
 Prozesse können für iterative Entwicklung strukturiert werden, so
dass Änderungen möglich sind, ohne das Gesamtsystem zu
stören.
 Der Rational Unified Process ist ein aktuelles generisches
Prozessmodell, welches in Phasen (Anfangsp., Ausarbeitung,
Entwicklungsp., Umstellung) untergliedert ist, die Aktivitäten
(Anforderungen, Analyse, Entwurf, etc) jedoch von diesen Phasen
trennt.
Zusammenfassung
 Die grundlegenden Ansätze zur Verbesserung von Prozessen

sind
 Agiler Ansatz: Reduktion von Prozess-Overhead
 Prozessreifungsansatz: Verbesserung von Prozessmanagement und Einsatz
von Software Engineering Praktiken
 Das CMU Reifegradmodell definiert Reifegrade, die im Kern dem
Einsatz von Software Engineering Praktiken entsprechen.

SWE1 2 Softwareprozesse

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SWE1 2 Softwareprozesse

Hochgeladen von

Copyright:

Verfügbare Formate

Software Engineering 1

Prof. Dr. rer. nat. Alex Reichenbach

 Ende 60er: Softwareentwicklung als Kunst

 NATO Konferenz 1969: Begriff des Software

Informatik, Software Engineering 1, A. Reichenbach Seite 3

Definition: Ein Softwareprozess ist ein strukturiertes Set

Es gibt viele verschiedene Softwareprozesse, aber alle

Informatik, Software Engineering 1, A. Reichenbach Seite 4

Informatik, Software Engineering 1, A. Reichenbach Seite 5

Definition: Ein Software Prozessmodell ist eine abstrakte

Informatik, Software Engineering 1, A. Reichenbach Seite 6

Außer „offensichtlichen“ Aktivitäten wie „Spezifikation eines

 Produkte, die das Ergebnis einer Prozessaktivität sind, zB

Informatik, Software Engineering 1, A. Reichenbach Seite 7

 Bei plangesteuerten Prozessen werden alle Aktivitäten

 Das Wasserfallmodell (waterfall model)

1. Anforderungsanalyse und -definition

Informatik, Software Engineering 1, A. Reichenbach Seite 11

2. Entwurf des Systems und der

Informatik, Software Engineering 1, A. Reichenbach Seite 12

3. Implementierung und Modultests

Informatik, Software Engineering 1, A. Reichenbach Seite 13

4. Integration und Systemtests

Informatik, Software Engineering 1, A. Reichenbach Seite 14

4. Betrieb und Wartung

Informatik, Software Engineering 1, A. Reichenbach Seite 15

 Jede Phase hat Start- und Endpunkte mit eindeutig

Informatik, Software Engineering 1, A. Reichenbach Seite 16

 „Vom Auftraggeber festgelegte Gesamtheit der Forderungen an

 „Vom Auftragnehmer erarbeitetes Realisierungsvorhaben

Informatik, Software Engineering 1, A. Reichenbach Seite 18

Informatik, Software Engineering 1, A. Reichenbach Seite 19

 Unflexibel gegenüber Änderungen und im Vorgehen.

AIB, Software Engineering 1, Massold/Krauskopf Seite 20

 Transparenter Prozess (klare Abgrenzung der Phasen)

Informatik, Software Engineering 1, A. Reichenbach Seite 21

 Hauptproblem des Wasserfallmodells

Informatik, Software Engineering 1, A. Reichenbach Seite 22

Informatik, Software Engineering 1, A. Reichenbach Seite 23

Informatik, Software Engineering 1, A. Reichenbach Seite 24

 Wird heutzutage am Häufigsten eingesetzt

Informatik, Software Engineering 1, A. Reichenbach Seite 25

 Jedes Inkrement enthält einen (weiteren) Teil der Funktionalität.

Aus organisatorischer Sicht

Informatik, Software Engineering 1, A. Reichenbach Seite 28

 Vorwort: In einem Großteil der Softwareprojekte wird Quellcode

 Stand-alone Anwendungen, die nur noch konfiguriert

Informatik, Software Engineering 1, A. Reichenbach Seite 30

 Spezifizierung der Anforderungen

+ Reduzierte Kosten und Risiken, da weniger

Informatik, Software Engineering 1, A. Reichenbach Seite 32

 Welches generische Softwareprozessmodell würden Sie für die

 Warum benötigt man bei dem Wiederverwendungsansatz 2

Informatik, Software Engineering 1, A. Reichenbach Seite 33

 Reale Softwareprozesse bestehen aus einer verzahnten Abfolge

Informatik, Software Engineering 1, A. Reichenbach Seite 34

Informatik, Software Engineering 1, A. Reichenbach Seite 35

Definition: Die Software Spezifikation ist der Prozess in

Informatik, Software Engineering 1, A. Reichenbach Seite 36

 Erhebung und Analyse der Anforderungen

Informatik, Software Engineering 1, A. Reichenbach Seite 37

1. Erhebung und Analyse der

Informatik, Software Engineering 1, A. Reichenbach Seite 38