ALM-orientierte Software-Entwicklungsprozesse versprechen Software in „kurzer“ Zeit mit „hoher“ Qualität entwickeln zu können. Die Implementierung der Software basiert auch hier auf Anforderungen von definierten Stakeholdern.

In diesem Blog möchte ich gerne betrachten, wie Anforderungen mit ihren unterschiedlichen Ausprägungen auf unterschiedlichen Abstraktionsebenen in einer ALM-orientierten Entwicklung behandelt werden können.

Betrachten wir hierzu den iterativen ALM Prozess mit den vier Hauptphasen „Define“, „Develop“, „Operate“ und „Adapt“. Die ersten drei Phasen stammen aus der Beschreibung aus [1].

Das Portfolio eines Unternehmens definiert zunächst übergeordnete Ziele, die nicht notwendigerweise auf Funktionen des zu entwickelnden Softwaresystems abzielen.

Diese Ziele und die Anforderungen der Stakeholder (Kundenanforderungen) an das System sind Input für die Definition (Phase „Define“) der Software. Innerhalb dieser Phase werden aus den meist natürlich sprachlich formulierten Anforderungen Features definiert. Die Features beschreiben konkrete Funktionen des Systems, welche den Nutzern zur Verfügung stehen. Diese Features können z.B. mit Hilfe von Use Case Diagrammen und -Beschreibungen spezifiziert werden. Häufig werden die Features auch als Systemanforderungen bezeichnet.

In der Phase „Develop“ des betrachteten ALM Prozesses entstehen aus den Features zunächst „Design Elemente“. Diese können z.B. durch Klassendiagramme, Sequenz- oder Datenflussdiagramme dargestellt werden. Aus diesen bereits sehr formalen „Design Elementen“ wird dann letztlich der Code des Systems implementiert. Teilweise kann dieser auch aus den formalen „Design Elementen“ automatisch generiert werden. Da wir uns hier auf Anforderungen konzentrieren, möchten wir an dieser Stelle nicht auf das kontinuierliche Testen während der Entwicklung eingehen.

In der Phase „Operate“ werden die Funktionen das System oder Teile des Systems in einer operativen Umgebung eingesetzt. Hier kann es passieren, dass der Anwender des Systems Änderungen an der Software wünscht. Hier hat er die Möglichkeit die Änderungswünsche als Ticket in den Prozess zurückzuspielen.

In der Phase „Adapt“ werden die eingegangen Tickets bewertet. Tickets, aus welchen ein Change Request resultiert, werden weiter analysiert. In dieser Analyse entstehen neue oder geänderte Anforderungen, welche wiederum als Input für die Phase „Design“ fungieren. Hier schließt sich der iterative Prozess.

Dieser Beitrag gibt einen kleinen Überblick darüber, wie Anforderungen in ihren unterschiedlichen Ausprägungen innerhalb eines ALM Prozesses eingegliedert werden können. In folgenden Blogbeiträgen wollen wir weitere spannende Aspekte des ALM näher betrachten, erläutern und auch hinterfragen.

 

Quellen:

[1] Richard Hundhausen: Professional Scrum Development with Microsoft® Visual Studio® 2012