Softwareprozesse

Marcel Lüthi
Departement Mathematik und Informatik

Organisation von Aktivitäten

Zentrale Fragen:

Wie lange sollen wir das tun?

Was sollen wir als nächstes tun?

Ein Softwaresystem zu programmieren beinhaltet viele verschiedene Schritte. Wir müssen Anforderungen idenifizieren, Dokumentieren, Spezifikationen schreiben, Verifizieren, Implementieren, die Software auslieferen, und vieles mehr. Bei jeder Aktivität müssen wir uns aber folgende Fragen stellen: - Wiche lange soll ich diese Aktivität machen? Sollen wir also zum Beispiel über Monate an der Anforderungsanalyse arbeiten, oder wollen wir dies immer in kurzen Phasen machen? Die zweite Frage die wir beantworten müssen ist, welche Aktivität mache ich, wenn die aktuelle Aktivität an der ich arbeite abgeschlossen ist?

Software Prozessmodelle

Prozessmodelle:

Bestimmen Aktivitäten
Legen Ordnung und Beziehung zwischen Aktivitäten fest
Definieren wann man zur nächsten Aktivität übergehen kann

Versuch, den Lebenszyklus zu organisieren.

Ziele von Prozessmodellen

Standardisierung
Vorhersagbarkeit
Produktivität
Hohe Produktqualität
Planung von Zeit und Budget

Gute Prozessmodelle erreichen dabei folgende Ziele: - Sie standardisieren einen Prozess. Dies hat den Vorteil, dass wir erfolgreiche Prozess wiederverwenden können. Ausserdem müssen wir bei standardisiserten Prozessen nicht alle Projektmitarbeiter in jedem Projekt neu Schulen, wie den die Entwicklung nun organisiert ist. Standardisierte Prozess können studiert und analysiert werden, und in kursen wie diesem gelehrt werden. - Ein weiteres wichtiges Ziel ist die Vorhersagbarkeit. Wir möchten, dass wir wenn wir in einem bestimmten Schritt sind immer wissen, wie lange es noch dauert, bis wir zu den nächsten Aktivitäten kommen. Dies erlaubt uns unsere Ressources optimal zu planen. Wenn wir zum Beispiel in der Anforderungsanalyse sind, und wissen, dass es noch 2 Monate dauert, bis die ersten Teile implementiert werden, können wir unsere Entwickler in dieser Zeit noch an anderen Projekten arbeiten lassen. Natürlich möchten wir auch, dass die Prozessmodelle zu einer hohen Produktivität der Mitarbeiter und einer hohen Produktqualität führne. Und schlussendlich sollten usn Prozessmodelle auch helfen, den Zeitaufwand und damit auch das Budget zu planen.

Softwareprozess: Blackbox-Sicht

Interaktion mit Benutzer nur am Anfang/Ende
Nicht geeignet für Software.

Fehler in Anforderungen werden erst am Ende entdeckt.
Qualitätseigenschaften nicht von Endprodukt ableitbar.

Eine Mögliche Sicht auf Softwareprozesse, wäre, dass wir diese Als Blackbox betrachten. Der Benutzer kommt mit Anforderungen, wir nehmen diese als Softwareingenieure entgegen, und führen dann selbständig unseren Softwareprozess durch. Am Ende kommt dann das fertige Programm heraus, welches wir dem Benutzer übergeben. Wir haben also nur am Anfang und am Ende eine Interaktion mit dem Auftraggeber oder Benutzer. Wir können uns leicht vorstellen, dass dies keine ideale Sichtweise auf den Softare prozess ist. Das Problem ist, dss wir mit so einem Prozess, Fehler in den Anforderungen erst am Endbe des Projekts sehen würden. Und dann ist es schon zu spät. Ausserdem lassen sich dass wir viele Qualitätseigenschaften nur aus dem Prozess und Nicht vom Endprodukt ableiten. Der Bentzer hätte also keine Möglichkeit, zu überprüfen, ob die gewünschten Qualitätsmerkmale erreicht würden.

Softwareprozess: Whitebox-Sicht

Interaktion mit Benutzer in jeder Projektphase

Eingehen auf Veränderungen möglich

Erster Ansatz: "Code and fix" Modell

Probleme:

Unmöglich Vorhersagen zu treffen
Unmöglich zu managen

Das erste Modell, das wir uns ansehen wollen ist das Code and Fix Modell. Die Idee hier ist, dass wir etwas programmieren, und falls es noch nicht den Anforderungen des Benutzers entspricht, wird es entsprechend angepasst. Dieser Zyklus wird solange iteriert, bis das Programm den Anforderungen entspricht. Diese Modell erfüllt unsere formulierten Ziele nicht. Insbesondere ist es unmöglich, bei diesem Prozess genaue Vorhersagen zu machen, die den Entwicklungsprozess plan und managbar machen würden. Dieses Modell wurde praktiziert, bevor sich Software Engineering als Disziplin etabliert hat, und hat direkt zur Softwarekrise geführt.

Schrittweiser Ansatz: Wasserfall Modell

Stark strukturierter Prozess
Dokumentlastig (Dokument nach jeder Phase)

Prozess strukturiert und planbar
Implementation erst wenn Anforderungen verstanden sind

Der vielleicht bekannteste Softwareprozess ist das Wasserfall Modell. Das Wasserfall modell ist ein stark strukturierter prozess. Wir beginnen mit einer Machbarkeitsstudie, identifizieren die Anforderungen, Speziifzieren und designen das System und dann implementieren und testen wir dieses. Wenn alles in Ordnung ist, machen wir einen Release und das System geht in den Wartungszustand über. Der Ganze Prozess ist sehr Dokumentlastig. Die Dokumente dienen als Schnittstelle zwischen den Phasen, die oft auch von unterschiedlichen Teams durchgeführt werden. Dieser Prozess erfüllt unsere Ziele viel besser. Der Prozess ist klar strukturiert und wir haben, falls sich die Anforderungen nicht verändern, eine hohe planbarkeit. Die Aktivitäten folgen auch einer logischen Reihenfolge: Die Implementation wird erst gemacht, wenn die Anforderungen verstanden sind, und das System richtig spezifiziert ist.

Wasserfall Modell: Probleme

Änderung in Anforderungen nicht berücksichtigt
Kein Feedback zwischen den Phasen
Keine Parallelisierung
Fixes Einführungsdatum für ganzes System

Originalpaper beschreibt diese Probleme

Royce, Winston W. "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1–9.

Trotzdem gibt es wahrscheinlich kein anderes Prozessmodell, welches so oft kritisiert wurde. Das Problem ist, dass das Modell von einer idealen Welt ausgeht, bei dem sich die Anforderungen nie ändern. Auch gibt es keine vorgesehenen Feedback loops, die es erlauben, Wissen, dass beispielsweise während der Implementation erlangt wurde, wieder zurück in die Anforderungen oder die Spezifikation fliessen zu lassen. Ein Weiteres Probleme ist, dass die Phasen strikt sequentiell durchgeführt werden, und deshalb keine Paramellelsierung der ARbeiten möglich sind. Zum Schluss führt dieses Modell auch dazu, dass das System erst als ganzes zu einem fixen Einführtstag eingeführt werden kann. Wir haben nicht die Möglichkeit, ein erstes Teilsystem unabhängig vom ganzen System einzuführen. Es entbehrt nicht einer gewissen Ironie, das im originalpaper von Winston Royce, in welchem das Modell vorgestellt wurde, bereits auf diese Problem hingewiesen wurde und auch Lösungsansätze dazu beschrieben wurden. Diese wurden dann jedoch lange von der Industrie ignoriert, was zum schlechten Ruf dieses Prozessmodells geführt hat.

Wasserfall Modell mit Feedback

Feedback an vorherige Stufe oft nicht ausreichend.

V-Modell

Wasserfallmodell mit Feedback über mehrere Stufen

Eine weitere Variante vom Wasserfall modell ist das V-Model. Bei diesem Modell wird jeder Stufe im Entwicklungsprozess explizit ein Validierungsschritt gegenüber gestellt. Das Programm Design wird getestet und validiert, indem Unit und Integrationstest durchgeführt werden. Das System Design wird über einen Systemtest validiert und die Anforderungen via eines Akzeptanztests. Wenn bei diesen Schritten fehler gefunden werden, kann das Modell vom entsprechenden Entwicklugnsschritt auf der Linken Seite wieder ausgeführt werden und somit der Fehler behoben werden. Natürlich gilt aber auch hier, dass Fehler die bereits in der Anforderungsanalyse gemacht wurden, sehr teuer werden können.

Wasserfall Modell mit Prototyping

(Throw-away) Prototyp um Anforderungen und Design zu verstehen/verifizieren

Eine andere Möglichkeit ist es, in einer frühen Projektphase einen Prototypen zu erstellen. Dieser Prototyp wird mit minimalem Aufwand umgesetzt. Das Ziel ist es, möglichst früh im Projekt möglichst viele wichtige Aspekte über das System zu lernen. Ein Prototyp hilft in vielerlei Hinsicht: Zuerst hilft er, die Machbarkeit eines Projekts besser einschätzen zu können. Wenn wir dem Auftraggeber bereits früh im Projekt ein funktionierendes System zeigen können, hilft dies die Anforderungen zu konkretisieren, Fehler aufzudecken und inkonsistenzen aufzudecken. Die Entwicklung eines Prototypen hilft uns auch mögliche Designs auszutesten und technische Herausforderungen zu identifizieren. In der Projektplanung wird das erstellen des Prototyps explizit mit eingeplant. Man sollte auch der Versuchung wiederstehen, den entwickelten Prototypen am Ende als Grundlage für die Implementation zu nehmen. Von Beginn weg sollte klar sein, dass dieser Prototyp ur dazu da ist Erfahrung zu gewinnen und danach weggeworfen wird. Nur dann ist man frei genug um verschiedene Varianten auszuprobieren, ohne dabei durch Qualitätsanforderungen und anderen Einschränkungen des finalen Systems beeinträchtigt zu werden.

Spiralmodell

Von Conny aus der deutschsprachigen Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=3697528

Risikoabschätzung in jedem Durchlauf.

Ein anderes Prozessmodell, das explizit die Idee von Prototpen aufnimmt, ist das Spiralmodell. Hier wird die Software in verschiedenen Zyklen entwicklet. Jeder Zyklus besteht aus vier Phasen, Festlegen der Ziele, Beurteilen der Risiken, Entwicklung und Test, und Planung des nächsten Zyklus. Diese Zyklen werden beliebig oft iteriert. Zentral für dieses Modell ist, dass in jedem Zyklus eine Risikoabschätzung durchgeführt wird. Die Punkte die in jedem Zyklus als sehr Risikoreich respektive Unsicher beurteilt werden, werden durch implementation von einem Prototypen oder einer Simulation geklärt. Nachdem diese Punkte geklärt sind, werden typischerweise die Üblichen Phasen vom Wasserfallmodell durchgeführt, bevor wir wieder die Ziele für den nächsten Zyklus definiern und die Risiken abgeschätzt werden.

Wachstumsmodelle

Grundidee: Gliederung in kleine, aufeinander aufbauende, betriebsfähige Releases

System wird nicht konstruiert sondern wächst.

Eine Radikal andere Idee wird mit den sogenannten Wachstumsmodellen verfolgt. Die Grundidee ist, dass zuerst nur ein minimales System gebaut wird, dass dann sukzessive in vielen kleinen Releases zu einem kompletten System ausgebaut wird. Statt einem grossen Release, haben wir also viele kleine Releases. Die Software wird also nicht auf einem konstruiert, sondern sie wächst kontinuierlich in Richtung des vollständigen Systems. In jedem solchen Release werden alle Entwicklungsphasen, von Anforderungsanalyse bis Verifikation durchlaufen. Da wir aber immer nur kleine Änderungen vornehmen, ist jede Iteration viel einfacher und deshalb weniger Risikoreich. Ausserden könenn wir viel besser auf Änderung in den Anforderungen reagieren.

Wachstumsmodelle

Abbildung nach: Pfleeger & Atlee, Software Engineering, Abbildung 2.9

Disziplin und gute Planung werden verlangt, damit es nicht zu Code and Fix Modell verkommt.

Wir unterscheiden dabei zwei verschiedene Ansätze: Das Inkrementelle und das Iterative Modell. Beim Inkrementellen Modell beginnen wir mit minimaler Funktionalität, die wir dann sukkzessive Ausbauen. In jedem Schritt kommt also neue Funktionalität hinzu. Beim Iterativen Modell entwickeln wir in einem ersten Schritt bereits das gesamtsystem. Die gesamte Funktionalität ist also schon im ersten Release vorhanden. Jedoch sind die einzelnen Funktionalitäten in einem ersten Release unter umständen nur sehr einfach implementiert und noch nicht im gewünschten Endzustand. Mit jedem Release werden dann einzelne Funktionen verbessert, bis wir am Ende das System in der gewünschten Qualität haben. In der Praxis müssen wir bei diesem Programm aufpassen, dass wir trotzdem jede Iteration gut planen, da das Modell ansosnten zum Code and Fix Modell, mit all seinen Nachteilen verkommt.

Agile Softwareentwicklung

Adapted from: Planbox - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=19543504

Softwareprozesse

Marcel Lüthi Departement Mathematik und Informatik

Organisation von Aktivitäten

Software Prozessmodelle

Ziele von Prozessmodellen

Softwareprozess: Blackbox-Sicht

Softwareprozess: Whitebox-Sicht

Erster Ansatz: "Code and fix" Modell

Schrittweiser Ansatz: Wasserfall Modell

Wasserfall Modell: Probleme

Wasserfall Modell mit Feedback

V-Modell

Wasserfall Modell mit Prototyping

Spiralmodell

Wachstumsmodelle

Wachstumsmodelle

Agile Softwareentwicklung

Marcel Lüthi
Departement Mathematik und Informatik