Vorgehensmodelle zum Softwareentwicklungsprozess

 + andere TechDocs
+ Softwarearchitekt
+ SW-Dokumentation
+ UML, MDA
+ Patterns
+

Vorgehensmodelle zum Softwareentwicklungsprozess empfehlen Richtlinien für Rollen (Verantwortlichkeiten), Phasen, Aufgaben, Aktivitäten, Methoden und Dokumente (Artefakte, Arbeitsergebnisse).



Inhalt

  1. Vorbemerkungen
  2. Sechs Qualitätsmerkmale für Softwareprodukte nach ISO 9126 (DIN 66272)
  3. Softwarearchitekturrelevante Aufgaben bei XP, Scrum, RUP und beim V-Modell
  4. Wasserfallmodell
  5. Scrum
  6. XP
  7. RUP
  8. V-Modell [XT]
  9. OEP
  10. Links auf weiterführende Informationen



Vorbemerkungen

Nach Untersuchungen von Standish Group, Gartner Group, Cutter Consortium und Center for Project Management sind im Durchschnitt:

Softwareentwicklung ist in besonderem Maße geprägt von Fehleinschätzungen. Sehr häufig wird der Zeitbedarf zu kurz geschätzt, sowohl für die Projektorganisation als auch für den Kommunikationsbedarf und die Programmierdauer. Im Endergebnis produziert ein Programmierer im längerfristigen Durchschnitt:

Kaum ein Programmierer wird dies glauben, da kurzfristig natürlich wesentlich mehr Codezeilen erstellt werden, aber wenn Sie nach einem halben Jahr Projektlaufzeit den effektiven Produktivcode zusammenzählen, werden Sie ähnliche Zahlen bestätigt finden. Dies gilt zumindest für Team-geeigneten, dokumentierten, zuverlässigen, test- und wartbaren Code. Für technische Code Reviews werden übrigens 1200 Codezeilen pro Tag angesetzt.

Auf Grund des erhöhten Organisations- und Kommunikationsbedarfs lässt sich die Projektdauer nicht einfach durch weitere Mitarbeiter verkürzen. Nach Brooks, Rausch-Schott und Retschitzegger gilt folgende Näherungsformel für die optimale Teamgröße:

Wenn also ein Projekt auf 16 Personenmonate geschätzt wird, wäre die optimale Teamgröße 4 Personen. Dies beinhaltet allerdings lediglich einen Vorschlag für die optimale Gruppengröße. Die sich ergebende Projektlaufzeit ist auf Grund des Kommunikationsbedarfs länger als 'ProjektdauerInPersonenMonaten' geteilt durch die 'MitarbeiterZahl'!

Die Meinungen zur optimalen Vorgehensweise in Softwareentwicklungsprojekten sind sehr konträr. Einige häufig wiederzufindende Praktiken bzw. Forderungen sind:



Sechs Qualitätsmerkmale für Softwareprodukte nach ISO 9126 (DIN 66272)

ISO 9126

Softwarearchitekturrelevante Aufgaben bei XP, Scrum, RUP und beim V-Modell

Die folgende Tabelle vergleicht in stark vereinfachender Weise XP, Scrum, RUP und das V-Modell aus Sicht des Softwarearchitekten:


  XP Scrum RUP V-Modell
Fokus des Modells Entwicklungsprozess Entwicklungsprozess Projektprozess Unternehmensprozess
Wichtige Rollen Kunde, Softwareentwickler Product Owner, ScrumMaster, Team Softwarearchitekt Systemdesigner, Softwareentwickler,
technischer Autor
Machbarkeit,
Risiko		 Alle Beteiligte Product Owner (zus. mit Team) Architekt PM (Projektmanagement)
Priorisierung,
Iterationsplanung		 "Stories" zus. mit Kunde vor jeder Iteration Product Owner (zus. mit Team) Architekt Systemdesigner, Projektleiter
Architekturkonzept Entwickler,
aber nur gerade benötigte Architektur		 Team (zus. mit Product Owner) Architekt Entwickler
Testplanung Entwickler Team wenig Unterstützung
durch Architekt		 QS (Qualitätssicherung)
Änderungen Entwickler Product Owner Architekt KM (Konfigurationsmanagement)
Statusberichte,
Dokumentation		 Alle Beteiligte,
aber möglichst wenig Dokumentation		 Product Owner, ScrumMaster Architekt Mehrere Rollen
Bewertung leichtgewichtige Methodologie,
wenig Dokumentation/Overhead,
agil, iterativ,
Architektur wird von allen definiert,
geringer Einführungsaufwand,
aber funktioniert nur mit homogenem Team		 leichtgewichtige Methodologie,
wenig Overhead,
agil, iterativ,
Sprint-Timeboxing,
geringer Einführungsaufwand		 schwergewichtige Methodologie,
formalisierter strukturierter Prozess,
Use-Case-getrieben, iterativ,
architekturzentriert,
Rolle des Architekten klar definiert,
hoher Einführungsaufwand		 sehr formalisiert und dokumentenzentriert,
Architektenaufgaben auf mehrere Rollen verteilt,
hoher Einführungsaufwand

Solche und ähnliche Vergleiche werden gerne angestellt, obwohl es eigentlich nicht ganz korrekt ist, die Modelle in dieser Form zu vergleichen, da der Fokus auf unterschiedlichen aufeinander aufbauenden Prozessebenen liegt. Zum Beispiel kann das Projektprozessmodell RUP um ein Plug-in für das Entwicklungsprozessmodell XP erweitert werden. Auch dX von Robert Martin zeigt, wie XP mit RUP aussehen kann ("dX" ist ironischerweise ein auf den Kopf gestelltes "XP").

Weiteres zu Softwarearchitekturen und den Aufgaben des Softwarearchitekten finden Sie unter Softwarearchitekt.



Wasserfallmodell

Das klassische Wasserfallmodell erlaubt Iterationen nur zwischen zwei aufeinanderfolgenden Phasen und durchläuft relativ starr sequentiell folgende Phasen:


     Zielerforschung, Anforderungen <-┐
     |                                |
     └->  Analyse, Lastenheft, Auftrag  <-┐
         |                                |
         └->     Pflichtenheft, Design      <-┐
             |                                |
             └->        Implementierung         <-┐
                 |                                |
                 └->       Test, Verifikation       <-┐
                     |                                |
                     └->   Abnahme, Betrieb, Wartung


Scrum

Eine Zusammenfassung zu Scrum finden Sie unter scrum.htm.



XP

Extreme Programming

XP (Extreme Programming) beschreibt eine agile iterative Vorgehensweise beim Softwareentwicklungsprozess mit leichtgewichtiger Methodologie und wenig Dokumentation und Overhead.

Schwerpunkte sind:

Weiteres siehe http://www.extremeprogramming.org und http://www.xprogramming.com.



RUP

Anklicken für Vergrößerung

RUP (Rational Unified Process) ist eine Vorgehensweise beim Softwareentwicklungsprozess mit eher schwergewichtiger Methodologie, vielen formalen Definitionen und Dokumenten, iterativ, architekturzentriert, Use-Case-getrieben, wohldefiniert und sehr strukturiert.

RUP teilt das Projekt in vier Phasen:

RUP definiert Workflows für neun Kernaufgaben (Disciplines):

Innerhalb der Phasen gibt es inkrementelle Iterationen über die Workflows, die teilweise ähnlich dem Wasserfallmodell abgearbeitet werden. Zu jedem Zeitpunkt bietet RUP Planungshilfen, Leitlinien, Checklisten und Best Practices.

Die konsequente und komplette Nutzung von RUP macht erst bei Teams mit über 10 Personen Sinn. Es sind über 30 Rollen für über 130 Aktivitäten vorgesehen und es werden über 100 verschiedene Artefakttypen (Arbeitsergebnistypen) vorgeschlagen, die erzeugt, dokumentiert und verwaltet werden müssen.

Allerdings kann RUP sehr weitgehend reduziert und angepasst werden ("Tailoring"). Es gibt sogar ein RUP-Plug-in für das XP-Vorgehensmodell.

Zu den zu erstellenden Artefakten gehören unter anderem folgende Dokumenttypen:

Weiteres siehe http://www.ibm.com/software/awdtools/rup.



V-Modell [XT]

V-Modell

V-Modell ist ein Vorgehensmodell zum Softwareentwicklungsprozess, also eine Richtschnur für die Organisation und Durchführung von IT-Vorhaben. Das "V-Modell 97", auch EstdIT (Entwicklungsstandard für IT-Systeme des Bundes) genannt, bzw. der Nachfolger "V-Modell XT" ist bei vielen zivilen und militärischen Vorhaben des Bundes verbindlich vorgeschrieben. Es ist ein wenig mit dem Wasserfallmodell vergleichbar, aber frühe Phasen werden mit späten über Testdaten verbunden (V-förmig, siehe Abbildung). Es ist auch iterativ anwendbar und kann mit OOAD und UML eingesetzt werden. Phasen und zeitliche Abläufe stehen nicht im Vordergrund. Es ist sehr stark formalisiert und dokumentenzentriert und muss vor der Anwendung angepasst werden ("Tailoring").

Zum "V-Modell 97" sind in drei Bänden drei Standardisierungsebenen beschrieben:

Das V-Modell ist in vier Submodelle gegliedert:

Seit 2005 gibt es mit "V-Modell XT" (eXtreme Tailoring) einen Nachfolger des "V-Modells 97". Es ist organisationsneutral, flexibel nach dem Baukastenprinzip anpassbar und wird durch Dokumentvorlagen wie beispielsweise Plan- oder Angebotsbausteine unterstützt. Es unterliegt keiner Einschränkung durch Nutzungsrechte und kann lizenzfrei beliebig adaptiert und eingesetzt werden.

Das V-Modell XT sieht sowohl "Auftraggeber-Projekte" als auch "Auftragnehmer-Projekte" vor. Der Auftraggeber ist normalerweise für die Definition der Anforderungen im "Lastenheft", für die "Ausschreibung" und für die "Prüfspezifikation Lieferung" für die Abnahme verantwortlich. Die Rolle des Auftraggebers kann bei internen Projekten natürlich auch durch die Fachabteilung besetzt werden. Der Auftragnehmer führt die Systemerstellung durch, begleitet durch weitere Dokumente.

Das nach dem Tailoring entstandene projektspezifische V-Modell enthält "Vorgehensbausteine" (z.B. SW-Entwicklung) mit "Produkttypen" (z.B. SW-Architektur), "Aktivitätstypen" (z.B. SW-Architektur erstellen) und "Rollen" (z.B. SW-Architekt). In der "Projektdurchführungsstrategie" (z.B. inkrementelle Systementwicklung) werden Meilensteine, Entscheidungspunkte und der zeitliche Ablauf vorgegeben, die Ausführung wird in "Projektfortschrittsentscheidungen" dokumentiert.

Das V-Modell XT erwartet als Minimum folgende Ergebnisprodukte:

Insbesondere für Softwareentwicklung interessant sind:

Genauere Beschreibungen und Templates zu den genannten Dokumenten erhalten Sie unter:
http://www.v-modell-xt.de, http://www.v-modell.iabg.de und http://www.kbst.bund.de.



OEP

Anklicken für Vergrößerung

OEP (Object Engineering Process) ist ein von Bernd Oestereich entwickeltes auf OOAD (objektorientierte Analyse und Design), UML und UP (Unified Process) basierendes Vorgehensmodell zur objektorientierten Softwareentwicklung. OEP ist ein iterativ-inkrementeller, agiler, anwendungsfallgetriebener, architekturzentrierter Entwicklungsprozess. OEP ist zugeschnitten auf die Entwicklung betrieblicher Informationssysteme als mehrschichtige objektorientierte Client-Server-Architektur und weniger gut geeignet für die Entwicklung technischer Systeme.

Weiteres siehe http://www.oose.de/oep.

Es folgt eine vereinfachte Kurzübersicht zu den von Oestereich für die objektorientierte Analyse (OOA) vorgeschlagenen Schritten (anders als hier dargestellt teilweise iterativ; ausführliche Beschreibung siehe Buch: Oestereich, Objektorientierte Softwareentwicklung, 2001, 3486255738):

  1. Systemidee und Zielsetzung entwickeln:
    Was soll erreicht werden, Ideen, Visionen, Absichtsbekundungen und Wünsche. Freitext, ca. halbe Seite.
  2. Anforderungsbeitragende (Stakeholder) identifizieren:
    Auftraggeber, Gesetzgeber, Projektbetroffene, Systembetroffene, Anwender, Kunden, Support, Vertrieb und Projektgegner. Tabellarische Unterscheidung in: Fachexperten, Anforderungsverantwortliche und Systembetroffene/Akteure.
  3. Geschäftsprozesse identifizieren:
    Systemidee mit UML-Anwendungsfalldiagramm (Use Case Diagram, «workflow») visualisieren. Geschäftsprozesse mit jeweils einem UML-Aktivitätsdiagramm (Ablaufdiagramm mit zeitlich aufeinander folgenden Schritten) abstrakt beschreiben. Fachliche und am Geschäft beteiligte Akteure abstrakt beschreiben.
    Ein Anwendungsfall (Use Case) beschreibt eine zeitlich ununterbrochene Interaktion eines oder mehrerer Akteure mit einem System.
    Ein Geschäftsprozess kann aus mehreren Anwendungsfällen bestehen und stellt eine Zusammenfassung von fachlich zusammenhängenden Aktivitäten dar, die durchgeführt werden, um einen Geschäftsvorfall ergebnisorientiert zu bearbeiten.
    Ein Geschäftsvorfall (z.B. Antrag) entsteht durch ein Ereignis (z.B. Antragseingang) und hat fachliche Ergebnisse (z.B. Vertrag).
  4. Interessen der Anforderungsbeitragenden (Stakeholder) identifizieren:
    Beschreibung der Ziele und Interessen, Aufzählung wichtiger geforderter Systemeigenschaften und Identifizierung von Problemen und Schwachstellen, alles aus Sicht der Anforderungsbeitragenden.
  5. Geschäftsanwendungsfälle (Business Use Case) identifizieren:
    Identifizierung der Geschäftsanwendungsfälle («business») (eventuell in Form von Stories) und deren Auslöser und Ergebnisse sowie Identifizierung auszuschließender Geschäftsanwendungsfälle («business» {excluded}).
    Ein Geschäftsanwendungsfall (Geschäftsfall, Business Use Case) beschreibt einen Anwendungsfall in abstrakter fachlicher Form aus Sicht des Anwenders.
  6. Anwendungsfälle essenziell beschreiben:
    Beschreibung der geschäftlichen Intentionen der Geschäftsanwendungsfälle («essential»). Definition der Auslöser, Vorbedingungen und eingehenden Informationen sowie der Ergebnisse, Nachbedingungen und ausgehenden Informationen. Entkopplung der Anwendungsfälle zu einzelnen kohärenten fachlichen Sachverhalten (eventuell mit «include» und «extend»).
  7. Systemanwendungsfälle identifizieren:
    Konkretisierung der essenziellen Anwendungsfallbeschreibungen unter Berücksichtigung konkreter Umgebungsbedingungen, Anforderungen und technischer Gegebenheiten. Eventuell Aufteilung eines essenziellen Geschäftsfalls in mehrere Systemanwendungsfälle, wenn unterschiedliche technische Systeme verwendet werden (z.B. Telefon, Fax, E-Mail, Web).
  8. Materialsammlung und -studie:
    Untersuchung von bestehenden Materialien, Gegenständen, Beispielen, Muster, Formulare, Vordrucke, Korrespondenzen und Beschreibungen.
  9. Anforderungen (Requirements) beschreiben:
    Funktionale Anforderungen (Anwendungsfälle), Benutzbarkeit (Usability), Effizienz (Performance), Zuverlässigkeit (Reliability), Änderbarkeit / Erweiterbarkeit / Wartbarkeit / Administrierbarkeit (Supportability), Gesetze, Standards und Testanforderungen. Unterscheidung in Pflichtanforderungen, optionale Anforderungen, Absichten, Vorschläge und Kommentare.
  10. Geschäftsklassen identifizieren:
    Identifizierung der fachlichen Gegenstände/Konzepte und Modellierung der strukturellen fachlichen Zusammenhänge in einem einfachen Analyse-Klassenmodell, ohne zu viele Details, aber mit Assoziationen, Assoziationsrollen und Multiplizitäten. Das Analyse-Klassenmodell soll für den Auftraggeber oder die Fachabteilung verständlich sein.
  11. Fachliches Glossar anlegen:
    Definition und Begriffskonsolidierung aller fachlichen Begriffe, aller Klassen des Analyse-Klassenmodells und aller Assoziationsrollen.
  12. Anwendungsfall-Ablaufmodell entwickeln:
    Modellierung aller Anwendungsfälle sowohl des Standardablaufs als auch des vollständigen Ablaufs inklusive aller fachlichen Ausnahmen und Varianten in UML-Aktivitätsdiagrammen. Für alle elementaren Aktivitäten Modellierung sowohl aller eingehenden als auch aller resultierenden Objekte und Daten in zu UML-Objektflussdiagrammen erweiterten Aktivitätsdiagrammen.
  13. Systemschnittstelle beschreiben:
    Schnittstellenbeschreibungen zu allen ein- und ausgehenden Daten, Objekten und Ereignissen. Beschreibung der Dialoge, Ausgabeerzeugnisse, Daten-Schnittstellen und funktionalen Schnittstellen.
  14. Exploratives Schnittstellen-Prototyping:
    Häufig lauffähige und benutzbare Sequenzen von Dialogentwurfprototypen. Eventuell auch Auswertungen, Formulare, Simulationen oder Berechnungen.

Das objektorientierte Design (OOD) könnte folgendermaßen ablaufen:

  1. Anwendungsarchitektur definieren:
    Systemdesign bezieht sich auf bestimmte Anwendungsarchitektur, die zuerst definiert werden muss. Eine übliche Anwendungsarchitektur wäre eine komponentenbasierte Three-Tier-Architektur mit einer Präsentationsschicht auf den Clients (Dialog-Steuerung), einer Geschäftslogikschicht auf Servern (Dialog-Agent, Workflow-Steuerung, Anwendungsfallsteuerung, fachliche Komponente, externe Komponenten) und einer zentralen Datenhaltung (Datenbankserver).
  2. Fachliche Komponenten identifizieren:
    Definition eines ersten fachlichen Komponentenmodells auf Basis des Analyse-Klassenmodells, von Workflow-Komponenten («workflow») zu jedem Geschäftsprozess und von Anwendungsfallsteuerungskomponenten («use-case-control») zu jedem Anwendungsfall.
  3. Komponentenspezifische Klassenmodelle entwickeln:
    Entwicklung von lösungsorientierten komponentenspezifischen Design-Klassenmodellen für jede Komponente. Auflösung komponentenübergreifender Klassenbeziehungen und Ersetzung durch komponentengerechte Schnittstellen (Factory-, Observer-, Object-Interface).
  4. Zustandsmodelle (weiter-)entwickeln:
    Identifizierung der fachlichen Zustände, der Zustandsänderungen verursachenden Operationen, der zustandsabhängigen Operationen und der Nachfolgezustände im UML-Zustandsdiagramm. Zustandsmodellierung z.B. mit Zustandsautomat, Zusicherungen, Zustandsattributen oder Zustands-Entwurfsmuster.
  5. Komponentenabhängigkeiten identifizieren und ggf. restrukturieren:
    Überprüfung sowohl der strukturellen als auch der dynamischen Zusammenhänge und Abhängigkeiten zwischen den Komponenten mit dem Ziel der Minimierung der Kopplungen und Abhängigkeiten. Per zu UML-Objektflussdiagrammen erweiterten Aktivitätsdiagrammen (oder alternativ per UML-Sequenz- oder -Kollaborationsdiagramm) werden separierbare Verantwortlichkeitsbereiche (swim lanes) ermittelt.
  6. Komponentenschnittstellen entwerfen:
    Aus Aktivitäten (z.B. der Anwendungsfallsteuerungskomponente und der fachlichen Komponenten) werden Schnittstellenbeschreibungen («interface») und Datentransferobjekte («structure») abgeleitet.
  7. Zusammenarbeitsmodelle entwickeln:
    UML-Sequenz- oder -Kollaborationsdiagramme für alle Anwendungsfälle sowohl für den Standardablauf als auch die wichtigsten Ablaufvarianten entwerfen. In der Regel dienen diese Diagramme nur zur Ermittlung von Erkenntnissen über die benötigten Operationen und Datentransferobjekte und werden im weiteren Verlauf nicht mehr benötigt.
  8. Ablauforientierte Komponententests entwickeln:
    Entwurf von Tests für alle Anwendungsfälle und Schnittstellen, möglichst automatisierbar (z.B. mit JUnit).
  9. Klassentests entwickeln:
    Entwurf von Tests für alle Operationen unter Berücksichtigung aller möglichen Zustände/Umgebungsbedingungen, möglichst automatisierbar (z.B. mit JUnit).
  10. Attribute definieren:
    Überprüfung aller Klassenattribute (z.B. Klassenzuordnung, eventuell eigene Klasse, Enumeration, Zusicherungen).
  11. Dialoge spezifizieren:
    Zuordnung der Dialogkontexte und Dialogkomponenten zu Aktivitäten der UML-Aktivitätsdiagramme und zu Subsystemen. Spezifizierung der Dialogkomponenten und Definition von clientseitig auszuführenden Vorabüberprüfungen.
  12. Überprüfung des Designs:
    Prinzipien der Objektorientierung, Design Patterns, Architektur, Namenskonventionen, Konsistenz, Effizienz, Erweiterbarkeit, Flexibilität, Testbarkeit, Benutzerfreundlichkeit, Zuverlässigkeit, Sicherheit, Korrektheit, Vollständigkeit, Widerspruchsfreiheit, Überprüfbarkeit, Nachvollziehbarkeit, Übersichtlichkeit, ...


Links auf weiterführende Informationen



Weitere Themen: andere TechDocs | UML, MDA | Patterns
© 2001-2007 Torsten Horn, Aachen