In diesem Aritkel ist beschrieben worden welche mögliche Modelle für die Erstellung eines Projekts benutzt werden können. Nachdem ein der Entwickler ein Modell ausgewählt hat wird einer seiner ersten Fragen sein: "Wie Lange wird mein Projekt andauern?". Damit der Entwickler diese Frage beantworten kann wird widmit sich die zweite Hälfte dieses Artikels dem Zeitmanagement.


Wasserfallmodell

Das Wasserfallmodell gehört zu den einfachsten Modellen in der Softwareentwicklung. Es korrespondiert in der unmittelbaren Reihenfolge der Aktivitäten. Jeder Aktivität bildet eine abgeschlossene Phase. Im einfachsten Fall wird die Aktivität sequentiell durchlaufen. Es ist nicht möglich Rücksprünge während der Entwicklung zu tätigen. Aus diesem Grund hat es den Namen eines Wasserfalles bekommen, da er streng in eine Richtung geht. In dem Sinne, dass die Phasen nach unten fallen.

Jedoch kann es möglich sein, dass es Sinnvoll ist eine Phase zurück zu springen, weil man in der nächsten Phase gemerkt hat, dass die Anforderung fehlerhaft bzw. Lücken hat. Aus dem Grund beinhaltet das Modell von Royce (1970) Rückkopplungsschleifen, um maximal je einer Phase.

Des Weiteren ist das Wasserfallmodell dokumentengetrieben und besteht nicht nur aus Quelltext nach Royce. Aufgrund, dass systematisch Dokumente erstellt werden, wird jede Projektphase (Aktivität) klar getrennt. Aus dem Grund sind es ebenso klar definierte Meilensteine. Im Modell wird aufgezeigt, dass Implementierung und Test getrennt werden, womit viele Kritiker ein Problem haben, da diese beiden Schritte einher gehen sollten.

Dieses Modell ist für Projekte geeignet für Projekte bei den alle Anforderungen klar sind und während dem Projekt keine Änderungen dazukommen.

Quelle: Software-Qualität, Dirk W. Hoffmann Darstellung des Wasserfallmodells

 


 V-Modell

Das Vorgehens-Modell ist eine Erweiterung vom Wasserfall Modell unter der Betonung von Qualitätssicherungsaktivitäten. Dies geschieht durch eine Zuordnung von Maßnahmen zur Verifikation und Validation/Validierung. Die Kernphasen von dem Wassermodell bleiben erhalten, wird aber zusätzlich mit einem weiteren Ast erweiterte der wiederrum treppenartig nach oben steigt. Dies führ zu dem Namen V-Modell. Der linke zweigt zeigt die Entwicklungsschritte und der rechte Zweig zeigt die Qualitätsmaßnahmen. Die Aktivitäten, die sich auf einer Ebene befinden sind zusätzlich von der Entwicklungsebene zur Qualitätsebene verbunden. Die Qualitätsmaßnahmen werden in der Grafik XY in zwei Bereiche unterteilt: Verifikation und Validation.

Verifikation

Bei der Verifikation wird überprüft, ob das Produkt die Spezifikation erfüllt. In der Praxis wird somit die Implementierung gegen die Spezifikation abgeglichen. Die Spezifikation wird nicht hinterfragt und als korrekt angesehen. Bei den Tests werden somit die IST-Ergebnisse mit den SOLL Ergebnissen abgeglichen.

Validation

Bei der Validation wird die Spezifikation auf den geplanten Einsatzzweck überprüft. Konkret wird geprüft, ob das angefordert Produkt den Erwartungen von dem Kunden entspricht.

Quelle: Software-Qualität, Dirk W. Hoffmann Darstellung des V-Modells

 Das Modell ist besonders für relativ große Projekte geeignet, wegen der hohen Regelung. Bei kleinen Projekte kann dieses Modell einen zu großen Übermaß der Software-Bürokratie einnehmen.

 


RUP

Damit das Ziel während des Projektes nicht verfehlt wird, wird das zweidimensionale inkrementelle Rational Unified Process Modell, abgekürzt RUP, aus dem Software Engineering Bereich von IBM verwendet. Mit zweidimensionalem Vorgehen wird in der Softwareentwicklung die inhaltliche und zeitliche Prozessstruktur definiert. Inkrementell lässt sich durch kleine Schritte im Vorgehen definieren. Ursprünglich wird es für die Entwicklung von Software gebraucht. Weil es einem agilen Konzept folgt, können die Dokumente während dem Projekt weiterhin angepasst werden, um gegebenenfalls das Projekt anzupassen. Mit Agilität wird kein Prozess definiert, sondern Maxime, Werte und Grundsätze. RUP lässt sich allgemein in vier Phasen Abbildung XY unterteilen: Inception, also Projektsetup und Konzeptualisierung, Elaboration, nämlich Ausarbeitung und Entwurf, Construction, das heißt Implementierung und Transition, worunter die Übertragung und Inbetriebnahme gefasst werden kann.

Quelle: Software-Qualität, Dirk W. Hoffmann Es werden die Diziplinen und Phasen von dem Rup-Modell vorgestellt

 Die Phasen werden nacheinander durchlaufen. In den Phasen gibt es inkrementelle Iterationen, die Disciplines genannt werden. Die Disciplines werden über die ganzen Phasen hindurch bearbeitet und durchlebt, wie der Tabelle XY erkennbar ist.

 

Dokumentbezeichnung Der Inhalt des Dokuments
Projektplan Im Projektplan werden Termine, Kosten, Entwicklungartefakte und Prozessvorgaben festgehalten.
Requirement Specification Dieses beschreibt das methodische Vorgehen und den Ablauf, den die Software erfüllen muss.
Architecture Mit der Softwarearchitektur werden die Darstellung, die Ziele sowie die Einschränkungen und die logische Architektur festgelegt. Dieses Dokument wird in dieser Variante nicht für das Projekt relevant sein.
Domainanalyse Die Domainanalyse beschreibt, wie ein Softwareprojekt entwickelt werden soll. Dies beinhaltet eine Beschreibung der Domänenklassen sowie UML-Diagramme. Das Dokument wird in dieser Variante für das Projekt nicht relevant sein.
Testdokumentation In der Testdokumentation wird nachvollziehbar beschrieben werden, wie die Ergebnisse validiert werden.

Zu allererst wird in dem Projektplan ein grober Überblick, also eine Vision über die Beteiligten und Benutzern, den sogenannten Stakeholder, definiert. Dem folgen eine Problemdefinition sowie grobe Anforderungen und Risiken. Damit sollen die Ziele des Projektes schnell erfasst werden können. In den Anforderungen, den Requirement Specifications, werden die Entwicklungsergebnisse durch das Vorgehen und den Ablauf, die das Projekt erfüllen muss, festgehalten. Es wird genauer auf die Funktionalitäten, den Durchsatz und die Zuverlässigkeit eingegangen. Unabhängig vom Entwicklungsvorgang ändern sich die Anforderungen und es ist am Anfang problematisch, die Requirements umfassend zu spezifizieren. Deshalb gibt es zwei Lösungsansätze, um die Requirements während des Verlaufs genauer zu differenzieren:

Laissez-faire

Der Laissz-faire-Ansatz verfolgt den reaktiven Modus, also die Ad hoc-Änderungen, und ist für kleinere, autarke Projekte gedacht, da Ad hoc-Änderungen in komplexen Systemen gefährlich sind. Für sicherheits- und zuverlässigkeitssensible Bereiche ist dieser Ansatz nicht empfehlenswert.

Embrace Change

Mit der Embrace Change werden nicht alle Anforderungen von Anfang an im Detail erfasst. Es wird somit iterativ vorgegangen und die Änderung der Anforderung muss bewertet und kontrolliert werden.

 


Quellen:

[1] https://www.projektmanagementhandbuch.de/handbuch/projektplanung/projektphasen-und-meilensteine

[2] https://www.informatik.uni-bremen.de/st/lehre/swp0607/planung-1x2.pdf

[3] Grunlagen der Wirtschaftsinformatik, Andreas Fink, Gabriele Schneidereit, Stefan Voß, Physica Verlag, 2005

[4] Software-Qualität, Dirk W. Hoffmann, Springer Verlag, 2008

[5] Gegenüberstellung der Open Source Desired State Configuration Tools Ansible und Puppet mit anschließender deklarativen Administration von Windows und Linux-System, Stefan Kuppelwieser, Mai 2017, OTH Regensburg

[6] Logo von https://pixabay.com/de/idee-leer-papier-stift-gl%C3%BChbirne-1876659/

Suche

Kategorien

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern (Tracking Cookies). Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.