ALM-Methoden
Das Application Lifecycle Management (ALM) bietet eine weite Perspektive, die so lange besteht, bis die Anwendung nicht mehr verwendet wird. Die Methoden für ALM können variieren. Daher ist die Auswahl der richtigen Methode für Ihre Anforderungen für die Entwicklung von entscheidender Bedeutung. Ziel dieses Moduls und von ALM ist es, die Entwicklerproduktivität zu steigern, die Zusammenarbeit zwischen Teams zu verbessern und die Transparenz von Arbeitselementen zu gewährleisten.
In dieser Lerneinheit werden die Methoden für ALM erläutert. Es wird gezeigt, wie Sie anhand Ihrer Softwareentwicklungsanforderungen ermitteln, welche Methode verwendet werden sollte.
Für ALM gibt es verschiedene Ansätze. Jeder Ansatz hat je nach Art des Projekts und der verwendeten Software seine Vor‑ und Nachteile.
Die drei gängigsten Ansätze sind die Wasserfall-Methode, die agile Methode und die Spiralmethodik.
Die Wasserfallmethodik
Die Wasserfallmethodik ist ein sequenzieller Ansatz. Das Projekt ist in verschiedene Phasen unterteilt, die jeweils von der vorherigen in die nächste Phase übergehen, bis das Projekt abgeschlossen ist. Jede Phase wird mit klaren Ergebnissen, Prüfungen und Genehmigungen gründlich dokumentiert. Normalerweise beginnt die nächste Phase bei der Wasserfallmethodik erst, wenn die vorherige Phase abgeschlossen ist. Wenn Sie z. B. Finanz‑ und Betriebs-Apps implementieren, müssen für jede Integration alle Anforderungen definiert sein, bevor die Entwickler mit der Entwicklung beginnen können.
Die Wasserfallmethodik sollte in Betracht gezogen werden, wenn das Projekt unkompliziert ist, die Anforderungen bekannt und genau definiert sind, sich der gesamte Projektumfang nicht ändern soll und das Projekt auf einmal umgesetzt wird.
Agile Methodik
Die agile Methodik ist iterativ ausgelegt und konzentriert sich auf kontinuierliches Feedback, um die Arbeitsergebnisse entsprechend zu ändern und dem Projekt hinzuzufügen. Anders als bei der Wasserfallmethodik können sich die agilen Phasen ineinander wiederholen. Dies bedeutet, dass verschiedene Phasen gleichzeitig bearbeitet werden können. Wenn z. B. Anforderungen für eine Integration definiert sind, können die Entwickler mit der Arbeit an dieser Integration beginnen, auch wenn sich andere Integrationen noch in der Phase der Anforderungserfassung befinden. In der Regel werden agile Projekte in Sprints unterteilt, die jeweils eine bestimmte definierte Dauer haben (für gewöhnlich ein oder zwei Wochen). Diese Sprints enthalten eine Liste der Ergebnisse, die während des Sprints zu liefern sind.
Der agile Ansatz eignet sich dann, wenn die Anforderungen zu Beginn des Projekts unklar sind, entlang des Lebenszyklus der Anwendung zusätzliche Anforderungen oder Arbeitsergebnisse erwartet werden oder das Projekt nicht auf einmal freigegeben werden muss. Die agile Methodik eignet sich auch hervorragend für benutzerorientierte Projekte, insbesondere wenn sich das Projektteam voll und ganz dem Projekt widmet. Da der agile Ansatz viele Akteure einbezieht, die gleichzeitig an verschiedenen Projektteilen arbeiten, kann die Kommunikation und Koordination des Projekts zuweilen schwierig sein. Daher ist es von Vorteil, das Projektteam am selben Ort zu haben.
Aufgrund der iterativen Natur der agilen Methodik kann sich die Nachverfolgung als recht komplex erweisen. Oft werden Arbeiten neu priorisiert, wenn die zu erbringenden Leistungen über den ursprünglichen Sprint hinausgehen oder wenn später neue Sprints hinzugefügt werden müssen.
Spiralmethodik
Das Spiralmodell kombiniert Aspekte der Wasserfall‑ und agilen Methodik. Das Spiralmodell konzentriert sich auf die Risikobewertung, indem das Projekt in kleinere Segmente oder Zyklen unterteilt wird. Zu Beginn jedes Zyklus werden zur Erstellung eines Prototyps die Anforderungen und Ziele definiert. Jeder Zyklus durchläuft dieselben Schritte, um einen Prototyp zu erstellen. Am Ende eines Zyklus werden der Prototyp überprüft und der nächste Zyklus geplant.
Die Spiralmethodik eignet sich gut für umfangreiche, komplexe Systeme. Es ist eine angemessene Risikobewertung erforderlich, um Risikobereiche für Probleme zu identifizieren. Ohne Risikobewertung können Probleme in der Software auftreten, die die Kosten ggf. in die Höhe treiben.