Tags:
create new tag
, view all tags

Überblick Software Projektmanagement

Rollen und Verantwortlichkeiten

  • Entwickler
  • Projektleiter
  • Kunde / Anwender

Vorgehensmodelle

Vorgehensmodelle sind geeignet, dem Projektleiter und den Entwicklern Hinweise zu geben, welche Tätigkeit als nächste auszuführen ist. Sie machen aber keine Aussagen über

  • die personelle Organisation
  • die Gliederung der Dokumentation
  • die Verantwortlichkeiten für Aktivitäten und Dokumente

Wenn obige Punkte hinzukommen, wird von einem Prozessmodell gesprochen (siehe unten). Welches Vorgehensmodell verwendet wird, hängt meist von der Art der Software, die entwickelt wird, ab. Programme und Softwaresysteme werden in drei Gruppen eingeteilt:

  • S-Programme: exakt und auch formal spezifiziert. Die Entwicklung ist abgeschlossen, wenn das Programm die Spezifikation erfüllt. Beispiel: Sortieralgorithmen, mathematische Funktionen
  • P-Programme: lösen Probleme der realen Welt, werden aufgrund eines Modells erstellt und solange modifiziert, bis eine akzeptable Lösung entstanden ist (Schachprogramme, Wettervorhersage etc.)
  • E-Programme: Programme, die in grössere soziotechnische Systeme eingebettet sind (die meisten Softwareprogramme)

Code and Fix

Schlechteste Variante aller Vorgehensmodelle: Tippen und korrigieren, bis das Programm stimmt. Leider sehr weit verbreitet, weil

  • man das Gefühl hat, schnell voranzukommen
  • die Arbeit schnell ein lauffähiges Programm liefert
  • die auszuführenden Tätigkeiten (Codieren und spontan Testen) einfach sind

Wasserfallmodell

Das Wasserfallmodell ist im Wesentlichen eine Darstellung der Tätigkeiten bei der Softareentwicklung (siehe [http://de.wikipedia.org/wiki/Wasserfallmodell][Graphik]]). Der Softwareentwicklungsprozess wird Phasen organisiert, dabei gehen die Phasenergebnisse wie bei einem Wasserfall immer als bindende Vorgaben für die nächst tiefere Phase ein. Dabei muss man aber auch den Weg zurück zulassen (gestrichelte Pfeile), weil kein Projekt ideal verläuft: In praktisch allen Fällen ändern sich die Anforderungen noch, wenn die Spezifikation bereits abgeschlossen ist, und ebenso werden Änderungen der Spezifikation und des Entwurfs nötig, wenn sich die ursprünglichen Vorgaben als nicht implementierbar erweisen.

Als Modell für das Projektmanagement ist das Wasserfallmodell ungeeignet, den die Zyklen verhindern, dass der Projektleiter den Fortschritt des Projekts objektiv beurteilen kann.

Prototyping

Aus der Erfahrung, dass viele Anforderungen erst erkannt werden, wenn das System vorhanden ist und eingesetzt wird, hat sich das Prototyping-Modell entwickelt. Dabei werden verschiedene Konzepte unterschieden:

  • Demonstrationsprototyp (zeigt prinzipielle Einsatzmöglichkeiten; Wegwerfprodukt)
  • Funktionale Prototypen (modellieren Ausschnitte aus dem GUI und Teile der Funktionalität)
  • Labormuster (modelliert einen technischen Aspekt des Zielsystems)
  • Pilotsystem (Funktionalität und Qualität reichen für einen vorübergehenden Einsatz)

Man kann Prototyping-Arten auch nach dem angestrebten Ziel unterscheiden:

  • Exploratives Prototyping (unterstützt die Analyse)
  • Experimentelles Prototyping (technische Umsetzung eines Entwicklungsziels)
  • Evolutionäres Prototyping (Prototyping als Prozess)

Iterative Software-Entwicklung

Die iterative Entwicklung gliedert ein grosses Projekt in eine Folge kleinerer Projekte. In das Enprodukt gehen alle Erfahrungen aus dem ersten Durchgang ein und auch neuere Entwicklungen (Markt, Technik). Software wird in mehreren geplanten und kontrolliert durchgeführten Iterationsschritten entwickelt. Ziel dabei ist, dass in jedem Iterationsschritt - beginnend bei der zweiten Iteration - das vorhandene System auf der Basis der im Einsatz erkannten Mängel korrigiert und verbessert wird. Bei jedem Iterationsschritt werden die charakteristischen Tätigkeiten Analysieren, Entwerfen, Codieren und Testen durchgeführt.

Inkrementelle Software-Entwicklung

Das zu entwickelnde System bleibt in seinem Gesamtumfang offen; es wir in Ausbaustufen realisiert. Die erste Stufe ist das Kernystem. Jede Ausbaustufe erweitert das vorhandene System und wird in einem eigenen Projekt erstellt. Mit der Bereitstellung einer Erweiterung ist in aller Regel auch eine Verbesserung der alten Nethz.Komponenten verbunden. Beispiel für Inkrementelle Software-Entwicklung sind Betriebssysteme wie Linux, Windows oder Mac OS.

Treppenmodell

Spiralmodell

Prozessmodelle

Phasenmodell

Das Phasenmodell teilt den Software-Lebenslauf in Abschnitte (Phasen) ein, die streng sequentiell durchlaufen werden. Für jede Phase gibt es ein eigenes Budget; dieses Budget wird erst freigegeben, wenn der vorangehende Meilenstein erreicht ist. Dann kann die nächste Phase beginnen. Im Gegensatz zum Wasserfallmodell gibt es im Phasenmodell keine Zyklen, eine abgeschlossene Phase kann nicht wieder geöffnet werden, sie ist Vergangenheit. Natürlich kann kein Prozessmodell verhindern, dass Fehler gemacht werden, die erst später auffallen, oder dass auf Grund neuer Einsichten frühere Entscheidungen revidiert werden müssen. Die Rückkehr in frühere Tätigkeiten findet jedoch (im Gegensatz zum Wasserfallmodell) im Budget und unter strenger Überwachung statt.

Das Phasenmodell bringt erheblichen Aufwand für die Organisation und für die Prüfungen mit sich. Dafür gibt es eine Reihe von Vorteilen:

  • Das Projekt ist präzise geplant und organisiert
  • Die Dokumente, deren Erstellung geplant wurde, werden geprüft
  • Der Personalbedarf ist frühzeitig geklärt
  • Die Durchführung der Prüfungen ist gewährleistet
  • Das 90%-fertig-Syndrom ist ausgeschlossen

V-Modell

Das V-Modell definiert für alle IDES vier obligatorische Prozesse (Kern-Vorgehensbausteine):

  1. Projektmanagement
  2. Qualitätssicherung
  3. Problem- und Änderungsmanagement
  4. Konfigurationsmanagement

Das Modell unterscheidet ferner drei zentrale Elemente:

  • Aktivitäten
  • Produkte
  • Rollen

Für jedes Projekt sind Vorgehensbausteine und Projektdurchführungsstrategie festgelegt. Eine Projektdurchführungsstrategie ordnet Entscheidungspunkte an, die erreicht werden müssen. An jedem Entscheidungspunkt müssen definierte Produkte fertig gestellt sein. Ein Vorgehensbaustein fasst alle Rollen, Produkte und Aktivitäten zusammen, die notwendig sind, um eine zentrale Projektaufgabe zu lösen. Vorgehensbausteine bauen aufeinander auf; jedes Projekt muss mindestens die die vier Kern-vorgehensbausteine enthalten. Produkte und Aktivitäten sind gruppiert und können gegliedert sein. Jedes Produkt wird durch genau eine Aktivität fertig gestellt. Produkte hängen voneinander ab. Rollen sind für Produkte verantwortlich und wirken an der Erstellung von Produkten mit.

Bewertung

Das V-Modell ist auf Grossprojekte angelegt und beinhaltet in seiner neuesten "XT"-Version auch agile Softwarekonzepte. Dadurch wird dieses Modell zu einer Art eierlegenden Wollmilchsau. Das Modell definiert eine enorme Menge an Aktivitäten, Produkten, Rollen und Durchführungsstrategien und scheint für kleinere und mittlere IDES nicht ohne weiteres geeignet zu sein.

Unified Process (UP)

Rollen, Aktivitäten und Artefakte

Der Unified Process soll die Vorteile von Phasenmodellen und nichtlinearen Prozessmodellen vereinen: Phasen erleichtern die Planung und das Management von Entwicklungsprojekten, Iterationen und inkrementelles Entwickeln helfen, Risiken frühzeitig zu erkennen und zu beseitigen. Wie in anderen Prozessmodellen auch finden sich beim UP Rollen, Aktivitäten und Prozesse. Der UP versteht unter einer Aktivität eine zusammenhängende Tätigkeit, die von einer Rolle in einem Arbeitsablauf ausgeführt wird. Eine Aktivität liefert ein definiertes Ergebnis und hat eine Menge von Artefakten als Eingabe. Mit einem "Artefakt" bezeichnet der UP jede explizit formulierte Information; dabei wird zwischen Dokumenten und Modellen (z.B. Use-Case-Modell) unterschieden. Artefakte werden im Rahmen von Aktivitäten durch Rollen erstellt, benutzt oder modifiziert.

Phasen

Der UP besteht aus folgenden Phasen:
  • Inception (Produktidee, Anforderungen verstehen, Start des Entwicklungsprojekts)
  • Elaboration (Architekturentscheidungen, Systemarchitektur, Prototyp, Risiken)
  • Construction (Implementation, Integration, Tests)
  • Transition (Verbesserung bis stabiler Zustand erreicht, Erfahrungen, Rückmeldungen)

In jeder Phase werden fünf Arbeitsabläufe ausgeführt:

  • Requirements
  • Analysis
  • Design
  • Implementation
  • Test

Jede Phase kann in mehrere Iterationen aufgeteilt werden, jede Iteration wird durch einen internen Meilenstein abgeschlossen. In jeder Phase werden die Arbeitsabläufe in unterschiedlicher Intensität durchgeführt. In der ersten Phase dominieren die Tätigkeiten zur Ermittlung der Anforderungen, in den späteren Phasen dominieren die Codierungs- und Testaktivitäten.

Rational Unified Process (RUP)

Der RUP ist eine Weiterentwicklung des UP und weitet den generischen UP zu einem vollwertigen Prozessmodell aus. Die Liste der Arbeitsabläufe wird durch folgende Punkte erweitert:

  • Business Modelling
  • Deployment
  • Configuration and Change Management
  • Project Mangement
  • Environment

Ausserdem beschreibt der RUP jede atomare Aktivität durch einen detaillierten Text, der die auszuführenden Schritte angibt. Allerdings täuscht der Prozess vor, dass die Software-Entwicklung algorithmisch durchgeführt werden kann. Es genügt nicht, nur formal nach der Prozessvorgabe zu arbeiten - viel wichtiger ist es, dass die in den Aktivitäten erzielten Arbeitsergebnisse brauchbar sind.

Cleanroom Development

  • Ein grosses Projekt wird durch ein inkrementelles Vorgehen aufgeteilt, also durch eine Serie kleinerer IDES ersetzt.
  • Der Aufwand für Analyse und Spezifikation ist weit höher als üblich - sie werden sehr gründlich inspiziert.
  • Den Entwicklern wird keine Möglichkeit gegeben, den Code zu compilieren und zu testen (!). Es wird von ihnen erwartet, dass sie Programme liefern, die sowohl semantisch als auch syntaktisch fehlerfrei sind.
  • Auf einen Test der einzelnen Nethz.Komponenten wird ganz verzichtet - sie werden integriert und insgesamt getestet.
  • Fehler werden nur in sehr geringem Umfang akzeptiert und nicht von den Testern, sondern von den Entwicklern behoben.

Viele nach dem Cleanroom-Ansatz durchgeführten IDES haben eingebettete Systeme realisiert, deren Zuverlässigkeit besonders kritisch ist. Allerdings sind die Anforderungen an die Entwickler hoch, da sie hochwertige Programme abliefern müssen, ohne sie getestet zu haben. Dem Cleanroom-Ansatz liegt ein streng sequentielles Konzept zu Grunde. Was nicht spezifiziert ist, kann nicht entwickelt werden. Software mit komplexer Bedienoberfläche und vielen Interaktionen basiert jedoch in der Regel nicht auf einer stabilen Spezifikation - diese wird explorativ nach dem Trial-and-Error Prinzip ermittelt. Darum sind solche IDES für den Cleanroom-Ansatz nicht geeignet.

Agile Prozesse

Als Antwort auf überbordene bürokratische Prozesse entstand die agile Bewegung, die das Ziel hat, den Ballast der "schweren Prozesse" abzuwerfen und den Kunden und die Software wieder in das Zentrum zu rücken. Alle agilen Prozesse

  • sind iterativ angelegt
  • verlangen die Arbeit in einer kleinen Gruppe (6-8 Personen)
  • lehnen die Idee einer grossen, reichlichen Dokumentation ab
  • nehmen den Kunden sehr wichtig und empfehlen oder verlangen seine Präsenz im Projekt
  • lehnen dogmatische Regelungen ab

Beispiele für agile Prozesse sind:

  • Extreme Programming
  • Adaptive Software Development
  • SCRUM
  • Crystal

Extreme Programming (XP)

XP basiert auf folgenden vier Werten:
  • Einfachheit
  • Feedback
  • Kommunikation
  • Mut

XP beschreibt mehrere Konzepte, die helfen, diese Werte und Prinzipien im Projekt umzusetzen:

Managementkonzepte

  • Integrales Team (Kunde ist zwingend im Projekt und jederzeit für Fragen/Diskussionen verfügbar)
  • Planungsspiel (Kunde gibt Anforderungen vor, Entwickler schätzen dafür benötigten Aufwand/Zeit)
  • kurze Release-Zyklen (wenige Wochen)
  • Standup-Meeting (tägl. Sitzung im Stehen, 15min)
  • Rückblick

Teamkonzepte

  • Gemeinsame Verantwortung für den Code
  • Codierrichtlinien
  • Erträgliche Arbeitsbelastung
  • Zentrale Metapher
  • Laufende Integration

Programmierkonzepte

  • Testgetriebene Entwicklung (Testen geht vor Implementieren)
  • Strukturverbesserung (Refactoring) (Beseitigung der Schwächen, bevor neue Funktionen realisiert werden)
  • Einfacher Entwurf
  • Paar-Programmierung (einer programmiert, der andere schaut zu)

Die Einfachheit der Konzepte ist teilweise vordergründig - die Realität entspricht jedoch oft nicht ganz den klaren Regeln. Es scheint, dass der lautstarke Protest gegen die "schweren" Prozessmodelle ein wesentlicher Teil des Programms ist. Bei vielen Projekten gibt es keinen einzelnen Kunden, sondern Experten und Benutzer, deren Anforderungen systematisch erhoben werden müssen.

Softwareentwicklung bei den Basisdiensten

Wahl eines Prozessmodells

Bei den Basisdiensten wird Software in der Regel inkrementell entwickelt. Dies wird sich wohl auch in Zukunft nicht ändern, da die Anforderungen zu Beginn eines Projekts nie ganz klar sind und das Feedback von Benutzern immer wieder zu Weiterentwicklungen führt. Es werden praktisch ausschliesslich E-Programme entwickelt (Programme, die in soziotechnische Systeme eingebettet sind). Die Wahl eines geeigneten Prozessmodells muss wohl im Ausschlussverfahren ermittelt werden. Ungeeignet für unsere Zwecke sind folgende Modelle:

  • V-Modell (nur für sehr grosse IDES sinnvoll, sehr personalintensiv)
  • Phasenmodell (inkrementielles Entwickeln nicht möglich)
  • RUP (zu detailliert, sehr Aufwändig)
  • Cleanroom Development (sehr hohe Anforderungen an Programmierer und Spezifikation)

Der Unified Process (UP) scheint für unsere Umgebung am besten geeignet zu sein. Hinzu kommen einige sinnvolle Konzepte agiler Prozesse:

  • Integrales Team
  • kurze Meetings
  • Codierrichtlinien
  • Laufende Integration
  • Testgetriebene Entwicklung

UP in den Basisdiensten

Folgende Tabelle zeigt Beispielhaft, wie die einzelnen Produkte (oder "Artefakte") eines Unified Process aussehen.

Disziplin Produkt Inception (1 x) Elaboration (n x) Construction (n x) Transition (1-2 x)
Business Modeling Domain Model   start    
Requirements Use-Case Model start refine    
Vision start refine    
Supplementary Specification start refine    
Glossary start refine    
Design Design Model   start refine  
SW Architecture Document   start    
Data Model   start refine  
Implementation Implementation Model   start refine refine
Project Management SW Development Plan start refine refine refine
Testing Test Model   start refine  
Environment Development Case start refine    

Use Cases

Use Cases zu definieren ist wohl eine der wichtigsten Aktivitägen innerhalb des Unified Process. Das Ziel eines Use Case Modells ist es, das Problem in Worten zu beschreiben, damit daraus die Anforderungen an die Software abgeleitet werden können. Folgende Schritte werden ausgeführt:

  1. Systemgrenzen wählen
  2. primäre Akteure und deren Ziele identifizieren
  3. Use Cases definieren

Der Use Case kann in unterschiedlichen Detailliertheitsgraden beschrieben werden. Ein sehr detaillierter Use Case besteht aus folgenden Teilen:

  • Beschreibung des primären Akteurs
  • "Stakeholders and Interest"
  • Preconditions
  • Success Guarantee (Postconditions)
  • Main Success Scenario (Basic Flow)
  • Extensions (Alternate Flows)
  • Special Requirements
  • Technology and Data Variations List
  • Frequency of Occurence
  • Open Issues

Die wichtigsten zwei Teile des Use Cases sind das sog. Main Success Scenario (oder Basic Flow) und seine Extenstions (oder Alternate Flows). Jeder Schritt im Main Success Scenario wird nummeriert, es wird jenes Szenario beschrieben, bei welchem nichts "schiefläuft". In den Extensions werden diejenigen Dinge beschrieben, die "schieflaufen" können; sie werden beispielsweise mit 2a, 2b, 3a, 4a, 4b, 4c bezeichnet (damit auf das entsprechende Sucess Scenario verwiesen werden kann). Es kommt oft vor, das die Ausnahmen (Extensions) einen weitaus grösseren Umfang annehmen als die Beschreibung des Normalfalles (Main Success). Es wird empfohlen, die Sätze mit dem Akteur zu beginnen und mit einem Verb fortzusetzen, z.B. "Administrator erteilt dem Benutzer den Service XY".

Vision

Fasst die "Vision" des Projektes zusammen. In knappen und prägnanten Sätzen sollten hier grossen Ideen formuliert werden: weshalb das Projekt beantragt wurde, wo die Probleme liegen, wer die Interessenten sind, was diese benötigen und wie die künftige Lösung aussehen sollte.

Domain Model

ein Domain Model ist eine Beschreibung der realen Welt in konzeptionellen Klassen und deren Verbindungen untereinander. Dabei handelt es sich nicht um Software-Klassen. Das Domain Model illustriert eine partielle Sicht oder Abstraktion auf das reale Problem und ignoriert uninteressante Details.

Glossary (Glossar)

Das Glossar ist eine Liste von wichtigen Begriffen und deren Definitionen. Sehr oft werden bestimmte Begriffe von Technikern anders verwendet als von "Stakeholders" (Interessensvertreter). Nicht alle möglichen Begriffe sollten definiert werden, sondern diejenigen, die unklar oder mehrdeutig sein können oder einer genaueren Erklärung bedürfen. Mit dem Glossar sollte so früh wie möglich begonnen werden. Geeignete Überschriften in der Tabelle: Begriff, Definition und Beschreibung, Alias

Design Model

Mit Design beschreibt man den Prozess, welcher die Architekur, die Nethz.Komponenten, Interfaces und andere Charakteristiken eines Systems definiert. Die Architektur einer Software ist ihre Struktur auf einer bestimmten Abstraktionsebene. Bewährte Lösungsstrukturen werden dokumentiert und wiederverwendet, man spricht dabei von Architekturmustern. Das MVC-Architekturmuster (Model/View/Controller) ist ein Beispiel für ein bekanntes Architekturmuster.

Entwurfsmuster befassen sich dagegen mit kleineren Einheiten. Sie bieten Lösungen für gängige Entwurfsprobleme auf der Ebene des Feinentwurfs von Nethz.Komponenten an. Ein Entwurfsmuster beschreibt das Schema einer Lösung für ein bestimmtes, in verschiedenen konkreten Zusammenhängen wiederkehrendes Entwurfsproblem. Architektur- und Entwurfsmuster dienen dazu, das Wissen über guten Software-Entwurf zu bewahren und wiederholt zu verwenden.

Software Architecture Document (SAD)

Das SAD hat das Ziel, die wichtigsten Software-Architektonischen Aspekte in einem Dokument zusammenzufassen. Das Dokument dient vor allem auch dazu, neue Projektmitglieder möglichst schnell in die Softwarearchitektur einzuführen und die wichtigsten Ideen zu vermitteln. Aus diesem Grunde sollte das Dokument auch für dieses Zielpublikum geschrieben werden.

Im SAD wird die Software Architektur aus sechs verschiedenen Blickwinkeln beschrieben:

  1. Logik
  2. Prozess
  3. Einsatz (Deployment)
  4. Daten
  5. Use Case
  6. Implementation

Das SAD kann erstellt werden, nachdem das System gebaut wurde (als Zusammenfassung und als Lernhilfe für spätere Entwickler) oder nach dem Erreichen eines bestimmten Meilensteins (als Lernhilfe für die jetzigen und zukünftigen Entwickler).

Data Model

Das Datenmodell beschreibt, wie die Daten in einer relationalen Datenbank (RDB) als Tabellen mit Relationen untereinander abgebildet werden. Für das Datenmodell wird meist eine spezialisierte Form der UML-Notation verwendet. Bei sehr vielen Tabellen tritt das Problem auf, dass durch die zahllosen Verbindungen mehr Verwirrung denn Klarheit gestiftet wird. Es wird empfohlen, nur die wichtigsten Verbindungen aufzu- zeichnen und genügend erklärenden Text hinzuzufügen.

Implementation Model

Das Implemenation Model bildet Design Artefakte als Software-Code ab.

SW Development Plan

Test Model

Development Case

Literatur

  • Die meisten der hier präsentierten Informationen stammen aus dem sehr empfehlenswerten Buch Software Engineering - Grundlagen, Menschen, Prozesse, Techniken von Jochen Ludewig und Horst Lichter (dpunkt 2006). Es ist sehr gut strukturiert und bietet einen sehr guten Überblick über Softwareentwicklung.
  • Applying UML and Patterns von Craig Larman (Prentice Hall 2002). Sehr detaillierte Einführung in die Objektorientierte Analyse, Design und dem Unified Process (UP).
Topic revision: r11 - 2010-10-05 - bircher
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback