Experience Embedded

Professionelle Schulungen, Beratung und Projektunterstützung

Wie viel Agilität verträgt die Zertifizierung?

Autoren: Ingo Nickles, VectorSoftware, Martin Heininger, HEICON

Beitrag - Embedded Software Engineering Kongress 2015

 

Das agile Manifest spricht Punkte in Software Entwicklungsprojekten an, denen man gerade bei langjähriger Projekterfahrung nahezu uneingeschränkt zustimmen kann. Ihren Ursprung haben die agilen Methoden in der Entwicklung von IT-Software. Bei der Entwicklung von sicherheitskritischen Embedded Systemen/Software stehen auf den ersten Blick andere Aspekte im Vordergrund. Gibt es Möglichkeiten, diese beiden Welten zusammenzubringen? Um beides vergleichen zu können, werden die zugrundeliegenden Prinzipien analysiert und daraus dann entsprechende Schlüsse gezogen.

Schauen wir uns zunächst einmal den Originaltext des agilen Manifests an (siehe Bild 1, PDF). Der Grundgedanke des agilen Manifestes ist es, den Kundenwunsch in den absoluten Mittelpunkt zu stellen. Dinge, die nicht direkt dem Kundennutzen dienen, erhalten eine niedrigere Priorität. Umfassende Dokumentation stellt z.B. einen geringeren Kundennutzen dar, als funktionierende Software. Ähnlich verhält es sich auch mit den anderen 3 Punkten des Manifestes.

Einen weiteren Aspekt kann man in folgendem Prinzip erkennen: "Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen."

Hier verbergen sich die schon oft diskutierten sich selbstorganisierenden Teams. Darüber hinaus werden motivierte und leistungsfähige Teams vorausgesetzt.

Des Weiteren deuten folgende Prinzipien darauf hin, dass die Begründer des agilen Manifestes eher kleinere Projekte vor Augen hatten:

"Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne."

"Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht."

  • Kundenwunsch im Mittelpunkt
  • motivierte und leistungsfähige Entwicklungsteams sowie
  • tendenziell kleinere Projekte


sind zusammengefasst die 3 wichtigsten Elemente, auf die das agile Manifest basiert.

Prinzipien der Entwicklung sicherheitskritischer, embedded Systeme/Software

Nun betrachten wir den Entwicklungsprozess bei Projekten im Bereich der Funktionalen Sicherheit. Hinter diesem Begriff steht die Entwicklung von sicherheitskritischen, embedded Systemen. Was sind die wesentlichen Punkte hier? Für die Software-Entwicklung steht folgende Feststellung im Mittelpunkt der Aktivitäten:

Es gibt keine Methode, die garantiert, dass Software fehlerfrei entwickelt werden kann! Ein einzelner Fehler kann Menschenleben gefährden!

Diese Erkenntnis stellt ein Dilemma dar. Es gibt keine Entwicklungsmethode für industrielle Projekte, welche fehlerfreie Software garantieren kann. Vielmehr haben sich in den letzten Jahrzehnten einige Prozesse und Methoden herauskristallisiert, bei deren Anwendung die Anzahl der Fehler minimiert werden kann. Ein Meilenstein in dieser Entwicklung stellt sicher die Einführung des Standards DO-178 für zivile Luftfahrtprojekte in den 80er Jahren dar. Wenn man heute die funktionalen Sicherheitsstandards verschiedener Branchen vergleicht, dann lässt sich feststellen, dass sich bei der Software-Entwicklung einige grundlegende, branchenübergreifende Prozesse etabliert haben. Diese Prozesse senken die Software-Fehlerrate auf ein gesellschaftlich akzeptiertes, sehr niedriges Niveau.

Die wesentlichen Inhalte sind hier:

  • Schriftlich dokumentierte Requirements
  • Nachweis der korrekten (fehlerfreien) Implementierung durch sehr umfangreiche Verifikationsmethoden (Schwerpunkt Test, aber auch Review, Analyse)
  • Verifikation der Verifikation
  • Nachweis eines deterministischen Verhaltenes der Software (=> Worst-Case-Betrachtungen)
  • Hinterfragen der Test- und Requirements-Qualität z.B. durch Nachweis der strukturellen Coverage

 
Schriftliche Dokumentation aller Arbeitsergebnisse, 4-Augen-Prinzip und Herstellung einer umfassenden Transparenz sind zusammengefasst die wesentlichen Elemente, auf der die Software-Entwicklung in der Funktionalen Sicherheit beruht. Bei Funktionalen Sicherheitsprojekten der höchsten Kritikalitätsstufe hat die reine Software-Codierung oft nur noch einen Umfang von 20% des Gesamtprojektes. 80% des Aufwands fließt in das Validieren, Verifizieren und Dokumentieren.

Wie das nachfolgende Diagramm (siehe Bild 2, PDF) veranschaulicht, standen diese Tätigkeiten beim Agilen Manifest nicht im Mittelpunkt.

Schlussfolgerung

Wenn man nun FuSi-Projekte mit agilen Entwicklungsmethoden durchführen möchte, ergeben sich folgende potentielle Konfliktfelder (siehe Bild 3, PDF). Das Erfolgsgeheimnis liegt darin, die oben genannten Punkte zu analysieren und die für das eigene Projekt passenden Konsequenzen entsprechend zu ziehen. Wie kann man die Prinzipienkonflikte aktiv auflösen?

Beim ersten Punkt (Requirements / User Stories) müssen die Notwendigkeiten der Funktionalen Sicherheit berücksichtigt werden, d.h. es muss eine Datenbank mit den Requirements gepflegt werden. Die User Stories werden zu dokumentierten Requirements, d.h. in den Planungen für die Sprints werden die Requirements in Form von User Stories berücksichtigt. Der Produktbacklog enthält entsprechend die Requirements aus der Datenbank. Eine kundenorientierte Priorisierung der Implementierung wird vorgenommen. Unklare Requirements von hoher Priorität werden damit zeitnah geklärt. Durch aktive Einbeziehung des Kunden in das Projekt erhält man auch schnell eine Rückmeldung des Kunden zu den Requirements und der Implementierung.

Die Tests müssen den formalen Anforderungen der entsprechenden FuSi-Norm genügen. Wenn Sie aber als Kriterium des "Definition of Done" verwendet werden, können Sie sogar agile Projekte noch besser machen.

In besonders sicherheitskritischen Projekten (SIL3, SIL4, ASIL C, ASIL D) kann es aufgrund des großen Verifikationsaufwands generell Sinn machen, eines der agilen Teams als reines Verifikationsteam zu führen. Damit hat man die notwendige Unabhängigkeit sichergestellt, und der große Umfang der Tests (jeder Fehler muss gefunden werden) wird personell angemessen berücksichtigt.

Die starke Interaktion in embedded Projekten zwischen HW-, Mechanik- und Software-Entwicklung muss natürlich berücksichtigt werden. Es ergeben sich daraus aber keine Konsequenzen für die individuelle Arbeit der agilen Software-Teams. Es ist Aufgabe des Product Owners, den Informationsaustausch zur Hardware- und Mechanik-Entwicklung sicherzustellen.

Ähnliches gilt, wenn der Start von Produktionen und ähnliche Termine einen klaren Rahmen für die Entwicklung von embedded Systemen vorgeben. Allerdings ist dieser Rahmen in der Regel groß genug, dass innerhalb davon die Selbstbestimmung der agilen Teams trotzdem vollständig zur Anwendung kommen kann.

Fazit

Bei FuSi-Projekten sind die schriftlichen Dokumentationen der Arbeitsergebnisse sowie das 4-Augen-Prinzip feststehende Punkte, die man nicht wegdiskutieren kann. Wie sonst sollte man spätestens im Schadensfall (wenn das Produkthaftungsgesetzt greift und damit die passende Norm der Funktionalen Sicherheit nachzuweisen ist) beweisen können, dass man gemäß dem aktuellen Stand der Technik entwickelt hat?

Andererseits sind die wesentlichen Stärken der agilen Entwicklung die kurzen Planungszyklen und die starke Kommunikation der Teammitglieder. Die Aufgabe besteht nun darin, diese agilen Prinzipien über reine Software-Architektur- und -Codiertätigkeiten hinaus auf das Validieren, Verifizieren und Dokumentieren anzuwenden. Dies ist der Schlüssel für die erfolgreiche agile Entwicklung von FuSi-Projekten.

Die bei agilen Projekten propagierte Kundenorientierung und der Einsatz von leistungsstarken und motivierten Teams ist bei allen Projekten ein wesentliches Erfolgskriterium. Die Anwendung von agilen Methoden für Großprojekte geht über die hier gemachten Überlegungen hinaus und wurde daher nicht näher betrachtet.

 

Beitrag als PDF downloaden


Agil & Scrum - unsere Trainings & Coachings

Wollen Sie sich auf den aktuellen Stand der Technik bringen?

Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Agil & Scrum.

Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.


Agil & Scrum - Fachwissen

Wertvolles Fachwissen zum Thema Agil & Scrum steht hier für Sie zum kostenfreien Download bereit.

Zu den Fachinformationen

 
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.