Sichere Software durch agile Entwicklung

Categories: AgileTechnology

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.

Author

Agile.jpg

Author

GlobalLogic Marketing

View all Articles

Top Insights

Homeoffice Whitepaper

Homeoffice Whitepaper

AtlassianCloudSecurityAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

Top Authors

Luca Jungemann

Luca Jungemann

Online Marketing Manager

Kateryna Vasylieva

Kateryna Vasylieva

Specialist, People Development

Olga Cherevata

Olga Cherevata

Lead Recruitment Specialist

Victoria Polishchuk

Victoria Polishchuk

Specialist, People Development

Olena Lisovska

Olena Lisovska

Recruitment specialist, Consultant

Blog Categories

  • URL copied!