Vorgehensmodelle

Auch als Softwareentwicklungsprozessmodelle (SEPM) bekannt.

• Softwareentwicklungsprozessmodelle definieren
  • Durchzuführende Aktivitäten
  • Arbeitsablaufplan
  • Zwischen- & Endprodukte
  • Fertigungskriterien
  • Mitarbeiterqualifikation
  • Verantwortlichkeiten und Kompetenzen
• Viele SEPM können und müssen für die konkreten Anforderungen konfiguriert werden
• Ein Softwareentwicklungsprozess (SEP) ist eine Ausprägung eines SEPM
• Sequenzielle vs. iterative Entwicklung
• Schwergewichtige vs. leichtgewichtige Verfahren
• Methodenunabhängig vs. methodenspezifisch (Methode im Sinne von Paradigma)
• Geringe vs. intensive Benutzerbeteiligung

• Ur-Modell der Softwareentwicklung
• Etwas Code schreiben, anschließend verbessern
• Nachteile:
  • Nach mehrfachem Beheben von Problemen geht die Strukturierung verloren
  • Sogar gut entworfener Code entspricht nicht den Anforderungen der Anwender bzw. Kunden
  • Für größere Projekte ungeeignet

• Phasen werden nacheinander durchlaufen: operational plan, ~ specification, coding specification, coding, parameter testing, assembly testing, shakedown, system evaluation

• Erweitert Stufen-Modell um Rückkopplungsschleifen
• Überarbeitung über mehrere Stufen ist aufwändig und teuer, daher nur Rückkopplung auf unmittelbar vorhergehende Stufe
• Probleme:
  • Dokumentationsgetrieben: Beginn der nachfolgenden Phase erst nach Abschluss der Dokumentationsarbeiten an vorangehender Phase
  • In Praxis wenig geeignet bei interaktiven Anwendungen

• Ausgehend von einem Produktkern werden die übrigen Produktbestandteile nacheinander entwickelt
• Negative Auswirkungen ergeben sich insbesondere für die Codequalität aufgrund mangelnder Modularität und schlechter Eignung zur Weiterentwicklung

• Alle Anforderungen werden zunächst möglichst vollständig erfasst
• Teilsysteme werden mit allen erforderlichen Aktivitäten entwickelt und ausgeliefert
• Zwei prinzipielle Probleme
  • Zu langes Verharren in Anforderungsermittlung
  • Je nach Domäne können sich Anforderungen schnell ändern

• Erzeugt aus der formalen Spezifikation eines Softwareprodukts ein ausführbares Programm → Änderungen ausschließlich in der Spezifikation; ausführliches Testen
• Probleme sind eingeschränkte Transformations- und Evolutionsmöglichkeiten und zu umfangreiche Wissensbasen

• Konfigurierbares Modell
• Jedes Teilprodukt durchläuft zyklisch vier Schritte
  1. Identifikation der Ziele des Teilprodukts
  2. Bewertung der Alternativen unter Berücksichtigung der Ziele und Randbedingungen
  3. Auswahl des geeignetsten Modells (Berücksichtigung von Risiken)
  4. Planung des nächsten Zyklus
• Vorteile
  • Periodische Überprüfung, ggf. Korrektur des Prozessablaufs
  • Keine Festlegung auf ein einziges Prozessmodell
  • Wiederverwendung durch Betrachtung von Alternativen
• Nachteile
  • Hoher Managementaufwand
  • Für kleine und mittlere Projekte ungeeignet
  • Ungenügende Kenntnis über Identifikation und Management von Risiken

• Umfasst vier Teilmodelle (Systemerstellung, Qualitätssicherung, Konfigurationtsmanagement, Projektmanagement)
• Sieht hierarchisch gegliederte Aktivitäten vor (stark vereinfacht)
• Ist äußerst komplex und muss vor seiner Anwendung auf die aktuellen Erfordernisse angepasst werden (engl. „tailoring“)
  • Soll helfen die Papierflut einzudämmen, aber gleichzeitig verhindern, dass wichtige Dokumente fehlen
  • Ausschreibungsrelevantes ~: Streichung verzichtbarer Aktivitäten und (Teil-)Produkte
  • Technisches ~: nochmal aktuell als verzichtbare Aktivitäten & Produkte streichen
• Um Qualitätssicherung erweiterte Spezialisierung des Wasserfallmodell
• Dokumentengetriebenes SEPM
• Komplex und aufwändig → nicht für kleine Projekte geeignet

• Weiterentwicklung des V-Modell 97 durch Bundesverteidigungs- & innenministerium
• Soll weiterhin hohen Qualitätsstandard sichern, dabei aber iterative, inkrementelle und agile Vorgehensweisen unterstützen

• Vorläufer agiler SEPMs
  • Agile Softwareentwicklung zeichnet sich durch geringen bürokratischen Aufwand und wenige, flexible Regeln aus.
• Für kleine Projekte in sich rasch ändernden Domänen konzipiert
  • Kleine Inkremente
  • Rückmeldung des Kunden kann im nächsten Inkrement berücksichtigt werden
  • hohe Codequalität angestrebt
• Beruht auf 13 Praktiken
  • Ganzes Team
    • Repräsentant des Kunden ist unverzichtbares Teammitglied (Anforderungen nennen, Prioritäten setzen, Projekt steuern)
    • Weitere Rollen: Analytiker, Modellierer, Tester,… (auch in 1 Person)
    • Teammitglieder sollen Generalisten, keine Spezialisten sein
  • Planungsspiel
    • Versionsplanung ist Grobplanung des Projekts
    • Iterationsplanung legt Anforderungen der nächsten 14 Tage fest
  • Kundentests
    • Automatische Akzeptanztest (im Sinne Regressionssteuerung)
  • Kleine Versionen
    • Neue, kleine Versionen in kurzen Abständen (max. 14 Tage)
    • Kunde kann und soll diese Version testen
    • Trägt erheblich zu einer besseren Sichtbarkeit bei
  • Einfaches Design
    • Anforderung wird auf Grundlage eines möglichst einfachen Entwurfs implem.
    • Keine Mutmaßung über möglichen Anforderungsänderungen
  • Programmierung zu Zweit (pair programming)
    • Teammitglieder sollten zwecks Wissensverteilung regelmäßig getauscht werden
  • Test-getriebene Entwicklung
    • Vor Implementierung einer Anforderung wird zuerst ihr Test im Sinne eines Regressionstests implementiert
    • Unit-Test vs. Integrationstest (min. 2 mal pro Tag)
    • 100% Testabdeckung des Codes angestrebt
  • Design-Verbesserung bzw. Refaktorisierung
    • Auffinden und beseitigen von Codeduplikaten
    • Maximieren der Kohäsion, minimieren der Kopplung
  • Fortlaufende Integration
    • Täglich mehrere Builds
  • Kollektiver Codebesitz
    • Jeder Entwickler im Team kann den gesamten Code einsehen und ändern
  • Programmierstandard
    • Strikte Verwendung eines gemeinsamen PS. (vgl. Kollektiver Codebesitz)
  • Metapher
    • Soll Funktionsweise eines Programms möglichst anschaulich beschreiben
  • Nachhaltiges Tempo
    • Permanentes Leisten von Überstunden verringert die Qualität

• Modell
• RUP
• Vorgehensmodelle in der Wikipedia
• Vorgehensmodell zur Softwareentwicklung