Sichere Software durch agile Entwicklung

Die Entwicklung neuer Software ist eine schwierige und komplexe Angelegenheit. Um die Vorhersehbarkeit und Steuerbarkeit von IT-Projekten zu verbessern, haben wir als Community eine Reihe von Standards und Prozessen entwickelt und implementiert. Allerdings können wir diesen Bereich noch nicht mit Fertigungsprozessen vergleichen. In der Produktion kommt nach dem Design des Produktproduktionsprozesses die Verifizierungs- und Debugging-Phase, sodass wir nach mehreren Iterationen einen relativ effizienten und stabilen Prozess sehen können, bei dem am Ende der Linie ein Produkt in regelmäßigen Abständen mit einem Minimum von Abfall und unfertige Produkte – sei es ein Handy oder aber auch ein Auto.

Andererseits können wir bei der Softwareentwicklung jede Anfrage als neues Produkt betrachten, das schließlich integriert in das Ganze das Endprodukt bildet. Jede Anfrage ist einzigartig und ihre Variabilität ist enorm. Daher wird das zum Debuggen einer physischen Produktproduktionslinie verwendete Verfahren nicht funktionieren. Aber es gibt mehrere Ansätze, wie wir versuchen, dieses Problem zu lösen. Solange die Software nicht kritisch ist und somit keine Gefahr besteht, dass ihre Unvollkommenheit die Gesundheit von Menschen gefährdet oder große finanzielle Schäden verursacht, setzen wir sogenannte agile Prozesse ein. Durch die Implementierung dieser Prozesse können wir in relativ kurzer Zeit stabile Software genau nach den Anforderungen in der vorgegebenen Zeit und zu den geschätzten Kosten erstellen.

Kritische Softwareentwicklung und agiler Ansatz

Was aber, wenn es sich um kritische Software handelt, die extremen Anforderungen an Zuverlässigkeit (z. B. 99,95 % Verfügbarkeit während der Produktlebensdauer), Sicherheit oder Performance unterliegt? Einige Bereiche können sich Softwarefehler nicht leisten, da sie zu Verletzungen, Tod oder umfangreichen Schäden führen können. Das sind zum Beispiel Automotive, Medizin, Industrie und andere.

Die Anforderungen an die Softwareentwicklung für diese Anwendungen erfordern einen ganzheitlichen Ansatz, der durch das sogenannte V-Modell definiert wird. Dieses Modell erfordert zunächst die Definition von Systemanforderungen, Systemarchitektur, Softwareanforderungen und Design. Erst dann geht es an die Umsetzung selbst, die anschließend auf verschiedenen Ebenen getestet wird.

Feige. 1: V-Modell

In diesem Fall empfiehlt uns ein intuitiver Ansatz, zunächst Zeit für die Analyse aller Anforderungen aufzuwenden und basierend auf dieser Analyse Systemanforderungen vorzuschlagen. Diese Anforderungen werden anschließend in einer Reihe von Reviews überprüft und ausgeschmückt und anschließend dem Design der Systemarchitektur gewidmet. Viele von Ihnen kennen diesen Ansatz unter dem Namen Wasserfallsystem. Wir wissen bereits aus Erfahrung, dass dieses System nicht die notwendigen Ergebnisse bringt.

Also, was sind die Optionen? In unserem Projekt haben wir dieses Problem gelöst, indem wir einen agilen Ansatz angepasst haben . Allerdings ist das kein ScrumBut, wenn statt eines funktionierenden agilen Systems viele Kompromisse implementiert werden, die das ursprünglich gut konzipierte und komponierte Regelwerk letztlich zunichte machen. Mit einem maßgeschneiderten agilen Vorgehen haben wir das gesamte Projektteam in den sogenannten System- und Softwareteil aufgeteilt .

Das Systemteam besteht aus einer Gruppe von Analysten und einem Product Owner, der sie zusammenbringt und ihre Aktivitäten synchronisiert. Andererseits besteht das Softwareteam aus mehreren unabhängigen, sogenannten komponenten- und funktionsübergreifende Feature-Teams. Das bedeutet, dass jedes Implementierungsteam die erforderlichen Rollen hat, um die gesamte Bandbreite an Artefakten zu erstellen, die vom Entwicklungsstandard gefordert werden. Dazu gehören ein Requirements Engineer, ein Softwarearchitekt, ein Entwickler, ein Tester und nicht zuletzt ein Scrum Master, der in diesem Team den Entwicklungsprozess verantwortet.

Das Systemteam arbeitet dann in sechswöchigen Iterationen, in denen Analysten Anforderungen analysieren und klären. Anschließend trifft das Software-Team ein, das in drei zweiwöchigen Iterationen die vorgegebenen Systemanforderungen umsetzt. Während der Implementierung arbeitet das Systemteam an den Anforderungen für die nächsten 3 zweiwöchigen Iterationen. Auf diese Weise arbeiten beide Teams ohne Ausfallzeiten parallel.

Feige. 2: Know-how-Transfer zwischen System- und Softwareteam

Wie ist der Know-how-Transfer zu begreifen?

Es sieht einfach aus, aber der typischerweise problematische Vorgang des Know-how-Transfers zwischen diesen beiden Gruppen ist einem erfahrenen Leser sicherlich nicht entgangen . Um die klassischen Wehwehchen des Know-how-Transfers zu vermeiden, haben wir ein Maßnahmenpaket vorgeschlagen , das uns hilft, diese Kernaufgabe mit möglichst geringem Informations- und Zeitverlust durchzuführen:

• Eine Reihe von Workshops von Analysten für Implementierungsteams. Hier stellt jeder Analyst vor, welche Veränderungen in dem von ihm betreuten Bereich geplant sind. Der Workshop ist eine energieintensive und teure Aktivität, da fast das gesamte Team daran teilnimmt, daher sind Zeitmanagement und ehrliche Vorbereitung entscheidende Erfolgsfaktoren.
• Analyse der Systemanforderungen durch Softwarearchitekten , die Teil von Implementierungsteams sind; Dies ist eine Offline-Aktivität, bei der Architekten in Workshops die Systemanforderungen durchgehen, sie verstehen und ein Lösungskonzept vorschlagen müssen. Dieses Konzept wird in Form von Softwaretickets nach Priorität sortiert im Product Backlog festgehalten.
• WAS Planung , wo die Funktionalität in ein, zwei Sätzen nochmal vorgestellt wird. Das Team hat die Möglichkeit, Fragen zu stellen und der Analyst und der Softwarearchitekt antworten. Wie der Name des Treffens schon sagt, steht die Frage nach dem WAS im Vordergrund, aber auch kurze Reflexionen zu WIE-Fragen sind zulässig.
• Die WIE-Planung ist bereits ein internes Team-Event. Ziel ist es, eine detaillierte Lösung vorzuschlagen und einen Plan zu erstellen, wer sich um welche Funktionalität kümmert.

Die Erfahrungen aus dem laufenden Projekt zeigen, dass eine solche Synchronisierung trotz einiger Zeitaufwendigkeit in Form eines reibungslosen Ablaufs und einer guten Vorhersehbarkeit des Tempos, in dem wir als Team arbeiten können, Früchte trägt.

Kontaktieren Sie uns um mehr zu erfahren.