SW-Lebenslauf (Prozessmodelle Klasse 1)

• Projekt

• kontinuierlicher Prozess

Der Lebnslauf von SW ist ein Projekt oder ein kontinuierlicher Prozess

• Klasse (Prozessmodell)

• Objekt (Prozessinstanz)

= Objekt

Ein einzelnes Projekt, in dem reale Handlungen stattfinden und das ein greifbares Ergebnis liefern soll

= Klasse

Eine Schablone für eine Menge von Objekten, die alle nach dem gleichen Schema ablaufen sollen

• Steuerungssicht

• Organisationssicht

• Qualitätssicherung

• Projektmanagement

• Dokumenttion

• Konfigurationsmanagement

ist eine Prozessinstanz

Nur die Steuerungssicht des Prozessmodells

Nichtgreifbarkeit der Produkte

• eingeschränkte Sichtbarkeit

• fehlendeshaptisches Erlebnis

• Anfangsdatum

• zeitlicher Ablaufplan

• Enddatum

• speziefische Zielsetzung

• Randbedingungen

• festgelegte Zuständigkeit

• Budget

Auftraggeber:

• Marketingabteilung des UN

Geld:

• Entwicklungsbudget des UN

Produkt:

• Standart-Software , Shrinkware

Auftraggeber:

• extern

Geld:

• Zahlung durch externen Auftragsgeber auf Basis eines Vertrags

Produkt:

• Individualsoftware

Auftraggeber:

• Interner Budget-Inhaber

Geld:

• Verrechnung über Kostenstellen

Produkt:

• SW zur Optimierung firmeninterner Abläufe

Auftraggeber:

• Extern

Geld:

• Zahlung durch externen Auftragsgeber auf Basis eines Vertrags

Produkt:

• Software in einem größeren Systemkontext eingebettet.Besonders hohe Qualitätsanforderungen

• Anwendung meinst unbewusst

• Keine Anforderungsspezifikationen, kein Entwurf

• Kodierung und Ad-hoc-Tests wechseln sich ab und sind die einzigen explizit ausgewiesesen Tätigkeiten

• vorerst das Gefühl schnell voran zu kommen

• es ist schnell ein lauffähiges Programmm verfügbar

• Tätigkeiten (Kodieren, Testen) sind relativ einfach und gut voneinander abgrenzbar

• Projekt ist nicht planbar (entscheidende Informationen fehlen)

• Arbeitsteilige Aufgaben sind nicht durchfürbar

• da Anforderungen nicht explizit vorliegen, ist deren Erfüllung unwahrscheinlich

• Prüfungen sind ineffektiv da keine Soll-Vorgaben existieren

• Fehlender Entwurf führt zu schlecht strukturierten Programmen

• Mängel werden erst sehr spät entdeckt —> so ist ihre Beseitigung sehr kostspielig

• Konzepte und Entscheidungen können durch fehlende Dokumentation nicht rekonstruiert oder weitergegeben werden

• Geordnete Menge von Aktivitäten (=Projektphasen)

• Ergebnisse der Aktivitäten sind Dokumente

• Ergebnisse werden an nachgelagerte Aktivitäten weitergegeben

• Entwicklung erfolgt in Stufen/Kaskaden

  (Ergebnisse fließen wie Wasser über diese hinunter)

• Wenig bis keine Iteration„

• Überlappung der Aktivitäten möglich

• Einfach

• Einsteigerfreundliche Möglichkeit Struktur in den SW-Prozess zu bringen

• Vermischung von Aktivitäten und Phasen

• keine Qualitätssicherungsaspekte

• Einbanstraße —> Moving Targets werden ignoriert

• Kundenkontakt / -rückkopplung nur zu Beginn und am Ende

  
  

• Herstellung vorläufiger Versionen einer Hard- oder Software zum Zweck von

  • Benutzer-Feedback

  • Machbarkeitsstudien

  • Untersuchung von Eigenschaften zur Unterstützung des Entwicklungsprozesses

• Vorläufige Versionen sind „Wegwerfprototypen“

• Reaktion auf Probleme herkömmlicher Prozessmodelle

• Auftraggeber kann Anforderungen oft nicht präzise formulieren

• Diskussion unterschiedlicher Lösungsmöglichkeiten

• Fortwährende Kommunikation zwischen Entwicklern und Anwendern

• Kein Zurückziehen des Herstellers bis zur Vorstellung des Endprodukts

• Überprüfung, ob spezielle Anforderungen (z.B. Echtzeitbedingungen) haltbar sind

• Konflikt: Auftraggeber interpretiert Prototyp als fertige SW

==> ist ein provisorisches aber lauffähiges Softwaresystem, veranschaulicht Aspekte der Nutzerschnittstelle oder der Funktionalität.

Eine vorläufige Variante, Gestalt oder ein Beispiel eines Systems, das als Vorlage für spätere Stadien oder die abschließende, vollständige Version des Systems dient.

• sie sind lauffähig

• sie realisieren ausgewählte Aspekte des Zielsystems

• sie werden von Klienten geprüft und detailliert bewertet

• Welches Erkenntnisinteresse verfolgen wir mit dem Prototypen (z.B.Aufgaben)?

• Wer entwickelt den Prototypen?

• Wer bewertet den Prototypen?

• Welche Ressourcen stehen für dieEntwicklung des Prototypen zurVerfügung (Zeit, Geld)?

==> dient zur Akquisition eines Auftrags, wird dann ”weggeworfen”

• ist ein „Wegwerfprodukt“

• zeigt prinzipielle Einsatzmöglichkeiten

• zeigt mögliche Handhabung

• verwendung in Start- & Akquisephase

• ausreichend weit vom Zielsystementfernt, so dass keine falschen Erwartungen geweckt werden.

• Abbildung von Ausschnitten des GUI sowie Teilen der Funktionalität

• Unterstützung der Anforderungsanalyse

==> zum internen Experimentieren, fokussiert einen technische Aspekt des Zielsystems

• fokussiert einen technische Aspekt des Zielsystems (z.B. Architektur oder Funktionalität)

• Experimentalsystem der Entwickler für z.B. Machbarkeitsstudien

• kann Teil des Zielsystems werden

==> breists Kern des Zielsystems wird nach Benutzerprioritäten weiterentwickelt

• Funktionsumfang und Qualität mind. für temporären Einsatz ausreichend

• Realisierung eines abgeschlossenen Teil des Zielsystems

• komfortable, sichere Bedienbarkeit (wenn GUI enthalten)

• Benutzungsdokumentation vorhanden

• sukzessiver Ausbau ⇒ Teil des Zielsystems

• Ziel: Schrittweise Anpassung eines Systems an sich ändernde Anforderungen, die nicht zuverlässig vorausgesehen werden können

• Übergang zu evolutionärem Prozess

• weniger Prototyp als Pilotsystem

• vgl. auch „Perpetual Beta”

• Ziel: Klärung von Anforderungen und Eigenschaften des Zielsystems

• Diskussion von Alternativen

• Demonstrationsprototypen und funkt. Prototypen

• häufig Rapid Prototyping genannt

• Ziel: Feststellung der Aufgabenangemessenheit eines Lösungsansatzes bevor in massive Aufwände investiert wird

• Kommunikation zwischen Benutzern und Entwicklern

• funkt. Prototypen und Labormuster

• Große Projekte sind a priori nicht vollständig planbar

• Anforderungen lassensich meist nichtvollständig zu Beginn erheben und bleiben überdie Projektdauer selten stabil

• Zerlegung des Projekts in viele kleine (Teil-) Projekte => Iterationsschritte

• Korrektur von im Einsatz auftretender Mängel in jedem Iterationsschritt

• Systemoptimierung in jedem Iterationsschritt

• Aktivitäten des Wasserfallmodells (Analyse, Entwurf, Kodierung, Test) in jeder Iteration

• Funktionsumfang z.B. einer Standard-Software wächst sukzessive von Release zu Release

• Nach einer gewissen Zeit der Wartung ist die Architektur des beim Kunden im Einsatz befindlichen Systems erodiert.

• Ausgehend vom Kernsystem wird pro neuem Inkrement ein vollständiges Projektaufgesetzt.

• In dem Projekt werden neue Funktionen realisiert (vgl. inkrementell) sowie die alten Systembestandteile überarbeitet.

• Frühes Kundenfeedback ab Kernsystem bzw. Inkrement 1

• Relativ kurze Entwicklungszeiten pro Inkrement

  • Bei deren Einsatz entdeckte Fehler lassen sich kostengünstig korrigieren

• Kurze „Time to Market“ bei weitestmöglicher Offenheit für neueAnforderungen

Es basiert auf risikogetriebenem Verhalten.

Es wiederholt folgende Schritte bis Projekt erfolgreich abgeschlossen oder gescheitert ist:

1. Analyse sämtlicher Risiken, die ein Projekt beeinflussen

   —> Finden sich keine Risiken mehr, so gilt das Projekt als erfolgreich abgeschlossen

2. Risikobewertung, um eine Rangfolge der Risiken zu erhalten

3. Versuch, das größte Risiko zubeseitigen

   —> gelingt dies nicht, so gilt das Projekt als gescheitert

• Unlösbare Probleme werden schnell erkannt, weil Sie wahrscheinlich amgrößten Risiko scheitern

• Nach der Bewältigung der größten Risiken, stabilisiert sich das Projekt sehr schnell