Ein Angebot von

Functional Safety Software Engineering: Problemfälle Prozess & Qualität

| Autor / Redakteur: Dr. Joachim Schlosser* / Sebastian Gerstl

Handlungsempfehlungen für Entwicklungsorganisationen

Wenn Ihre Organisation vor der Herausforderung steht, nun nach ISO 26262 zu entwickeln, dann lohnt es, sich für die Umsetzung in Entwicklungsprozesse auch nach Automotive SPICE anzusehen. Speziell als Zulieferer werden Sie sich ohnehin mit dem Wunsch des OEM konfrontiert sehen, das Projekt oder gleich die ganze Entwicklungsorganisation nach Automotive SPICE gemäß ISO 33020 Level 1, 2 oder 3 prüfen zu lassen, und zwar für alle Gewerke, auch diejenigen, die nicht sicherheitsgerichtet sind.

Eine gute Faustregel lautet: Wer SPICE Level 2 erreicht hat, der ist für ISO 26262 in Sachen Qualität schon ganz brauchbar aufgestellt. Wer SPICE Level 3 erreicht hat, steht gut da. Falls Ihre Organisation bislang noch gar nichts in Sachen ASPICE unternommen hat, dann wäre jetzt ein guter Zeitpunkt, um damit zu beginnen. Das Schöne an den qualitätsgerichteten Forderungen von ASPICE und ISO 26262 ist ja, dass das kein Hexenwerk ist.

Für viele Menschen in der Organisation bedeutet es auch, umzudenken. Die Erkenntnis, dass Programmieren für sich selbst eben etwas anderes ist als Software zu entwickeln für Maschinen von zwei Tonnen Gewicht, die mit mehr als hundert Kilometern pro Stunde im ungesicherten Straßenraum unterwegs sind. Und wenn diese Erkenntnis bei den Menschen gereift ist – und das tut sie bei den Allermeisten sehr rasch – dann braucht es eine Organisation, die das Qualitätsbewusstsein mit Infrastruktur unterstützt anstatt mit überstürzter Hast zu torpedieren.

Handlungsempfehlungen für OEMs als Beauftragende

Sind Sie Teil eines OEMs, der selbst entwickelt, gelten vorstehende Empfehlungen. Sind Sie in der Rolle des Beauftragenden, dann lohnt es sich, qualitativ und im Sinne der pünktlichen Einlieferung der Gewerke, so früh als möglich auf die Prozessarbeit hinzuweisen und diese einzufordern.

Letztendlich bekommt Ihre Organisation als Kunde Ihrer Zulieferer das, was sie bezahlt. Werden also Zulieferer stets noch weiter im Preis gedrückt, wird die Lieferantenorganisation eher früher als später so unter Kostendruck stehen, dass eben unter dem Teppich das Parkett nicht mehr sauber und kleinteilig verlegt ist. Rohe dünne Bretter müssen dann herhalten. Drücken Sie noch weiter, kann unter dem Teppich dann gar kein Parkett mehr vorhanden sein.

Die Kosten für die nächste Entwicklung, die auf einem bestehenden System auf-baut, hängen auch von der Erstellungsqualität ab. Musste aus Kostengründen das Gewerk schneller erstellt werden, als der Qualität zuträglich war, dann werden Sie mehr Mühen und Aufwand bezahlen müssen, bestehendes auf den aktuellen Stand zu bringen und wiederzuverwenden. Hier geht es nicht nur um den Aufwand, sondern auch um die „geerbten“ Schwächen oder Fehler und damit verbundenen Gefahren und Risiken.

Software Engineering als Grund-Disziplin

Wir alle haben mal gelernt, wie das geht. In jedem Studiengang Informatik gibt es – sei es im Grundstudium oder Hauptstudium – eine Vorlesung „Software Engineering“ oder „Software-Technik.“ In der Definition nach Balzert heißt es: „Software-Technik: Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden, Konzepten, Notationen und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Software-Systemen.“ [8, p. 17]

Software Engineering ist eben nicht „ich setz mich mit zwanzig anderen hin und klopfe Code auf ein Steuergerät“. Die Qualitätsanteile aller Normen und Modelle wie ISO 26262, SPICE [9], Automotive SPICE, CMMI [10] fordern letztendlich nur, dass wir ordentlich entwickeln, und dass wir dokumentieren, wie wir vorgehen.

Eine Verletzung dieser Prinzipien und daraus folgenden Praktiken in professionellen Softwaresystemprojekten ist Problem der Selbstwirksamkeit einzelner wie auch ein systematisches Problem von Organisationen. Jeder, als einzelne Person der Entwicklungsmannschaft, wie auch als Führungspersonal in allen Hierarchieebenen, ist aufgerufen, selbst Teil der Lösung zu sein und sich die Prinzipien ordentlichen Arbeitens wieder vor Augen zu führen und diese mit sinnvollen Maßnahmen in der Organisation fest zu verankern.

Eliminieren und Automatisieren

In diesem Abschnitt finden sich geordnet nach den obigen Prinzipien einige minimal erforderliche Prozess- und Vorgehensfelder, über die Sie sich in Ihrer Organisation Gedanken machen müssen, wenn Sie wieder die Grundlagen qualitativer Arbeit berücksichtigen wollen, und wenn die ISO 26262 kein Schock sein soll.

Die Auflistung ist angelehnt an [11] (siehe Bildergalerie).

Das Erstellen und Dokumentieren einer Prozessinfrastruktur ist nichts, was ein Entwickler und Qualitätsbeauftragter eben mal an einem Nachmittag erreicht. Zusammen genommen ergibt die Build-Infrastruktur mit allem, was dazu gehört, die Development Operations, kurz DevOps [23].

Für alle Felder gilt: Eliminieren vor Automatisieren. Die ISO 26262 schreibt vieles vor, was prinzipiell sicherzustellen ist. Das heißt jedoch nicht, dass dies stets von Menschen gemacht werden muss. Während Prozesse eher nicht eliminiert werden können, ist das für einzelne manuelle Arbeitsprodukte schon der Fall. Niemand hat etwas von manuell erstellten Reports in Folienform. Reporting an und für sich, um beim Beispiel zu bleiben, kann dann weitgehend automatisiert werden, so dass die relevanten Kennzahlen automatisch aus Projekt- und Buildsystem gezogen und in menschenlesbare Form gebracht werden.

Eliminieren beschreibt also die Prozessveränderung, in der die Organisation prüft, inwieweit Templates tatsächlich als solche befüllt werden müssen, oder die ISO 26262 im Geiste auch mit anderen, einfacheren Darreichungsformen erfüllt werden kann.

Automatisieren umfasst dann die Prozessveränderung, in der die verbleibenden Schritte von manueller Bearbeitung soweit als möglich in automatische Prozesse über-führt werden. Dies ist vor allem bei Reporting auf allen Ebenen von Softwaremetriken bis zur Zusammenfassung von Konformitätsbetrachtungen und Release Management möglich, bei der Verifikation und Test, bei Change Management, aber auch unterstützend bei Reviews. Ebenso kann „Automatisieren“ Methoden der Modellbasierten Softwareentwicklung enthalten, bei denen Algorithmik direkt aus Verhaltensmodellen erzeugt wird.

Vor allem beim Automatisieren gilt es, mit Augenmaß vorzugehen. Nicht alles muss sofort automatisiert werden. Manche Tätigkeiten finden so selten statt, dass eine Automatisierung mehr Aufwand verbraucht, als sie einspart. Zwar sind die besten Menschen, die das einschätzen können, diejenigen, die die Tätigkeit durchführen. Jedoch gilt es sich bewusst zu machen, dass diese Menschen teilweise ihre Identität aus diesen Tätigkeiten beziehen und somit einer Automatisierung eher ablehnend gegenüberstehen. Um das Dilemma der Automatisierung und Eliminierung aufzulösen, braucht es eine ehrliche Diskussion über Identitäten und höhere Wertschöpfung. Keiner will einfach wegautomatisiert werden, jedoch wollen die meisten Mitarbeiter eine höhere Wertschöpfung erreichen, wenn man mit ihnen offen darüber spricht.

Literaturverzeichnis

[1] ISO, "ISO 26262: Road Vehicles – Functional Safety. Part 1-7," ISO Copyright Office, Geneva, 2011.

[2] VDA QMC Working Group 13 / Automotive SIG, Automotive SPICE Process Reference Model / Process Assessment Model, 3.1 Hrsg., VDA Quality Management Center, 2017.

[3] ISO/IEC JTC 1/SC 7 Software and systems engineering, Information technology -- Process assessment -- Process measurement framework for assessment of process capability, ISO, 2015.

[4] Kugler Maag CIE, „Automotive SPICE v3.1 Pocket Guide,“ Kornwestheim, 2018.

[5] R. Messnarz, I. Sokic, S. Habel, F. König und O. Bachmann, „Extending Automotive SPICE to cover Functional Safety Requirements and a Safety Architecture,“ in EuroSPI 2011: Systems, Software and Service Process Improvement, Berlin-Heidelberg, 2011.

[6] E. Petry, „Automotive SPICE® & ISO/CD 26262: Their Mutual Relationship,“ in Fifth Automotive SPIN Italia Workshop, Milano, 2009.

[7] „Manifesto for Software Craftsmanship,“ 2009. [Online]. Available: http://manifesto.softwarecraftsmanship.org/.

[8] H. Balzert, Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering, 3. Auflage Hrsg., Heidelberg: Springer Akademischer Verlag, 2009.

[9] ISO/IEC JTC 1/SC 7 Software and systems engineering, ISO/IEC 15504 Information technology – Process assessment: Part 5 – „An exemplar software life cycle process assessment model“, ISO, 2012.

[10] CMMI Product Development Team, CMMI for Systems Engineering/Software Engineering. Version 1.1 Continuous Representation, Pittsburgh: Software Engineering Institute, Carnegie Mellon University, 2002.

[11] J. Schlosser und M. Hillbrand, „Scrum für Embedded-Software. Gut – aber aus anderen Gründen, als Ihr Manager glaubt,“ in Embedded Software Engineering ESE Kongress, Sindelfingen, 2017.

[12] B. Collins-Sussman, B. W. Fitzpatrick and C. M. Pilato, "Version Controll with Subversion," 2017. [Online]. Available: http://svnbook.red-bean.com/index.de.html.

[13] S. Chacon and B. Straub, Pro Git book, US: Apress, 2009.

[14] "Jenkins Handbook," [Online]. Available: https://jenkins.io/doc/book/. [Accessed 11 10 2017].

[15] „GoCD: Open Source Continuous Delivery and Automation Server,“ [Online]. Available: https://www.gocd.org/. [Zugriff am 11 10 2017].

[16] „Polyspace. Making Critical Code Safe and Secure,“ MathWorks, [Online]. Available: https://de.mathworks.com/products/polyspace.html. [Zugriff am 11 10 2017].

[17] „Klocwork: Source Code Analysis Tools for Security & Reliability,“ [Online]. Available: https://www.klocwork.com/. [Zugriff am 11 10 2017].

[18] „BullseyeCoverage Code Coverage Analyzer,“ [Online]. Available: http://www.bullseye.com/. [Zugriff am 11 10 2017].

[19] M. Doar, Practical JIRA Administration, UK: O'Reilly, 2011.

[20] P. Hodgson, „Feature Branching vs. Feature Flags: What’s the Right Tool for the Job?,“ 23 05 2017. [Online]. Available: https://devops.com/feature-branching-vs-feature-flags-whats-right-tool-job/. [Zugriff am 11 10 2017].

[21] W. Buchwalter, „A Git Workflow for Continuous Delivery,“ 21 06 2016. [Online]. Available: https://blogs.technet.microsoft.com/devops/2016/06/21/a-git-workflow-for-continuous-delivery/. [Zugriff am 11 10 2017].

[22] "Docker - Build, Ship, and Run Any App, Anywhere," [Online]. Available: https://www.docker.com/. [Accessed 11 10 2017].

[23] G. Kim, J. Humble, P. Debois, J. Willis and T. Demmig, Das DevOps-Handbuch, Heidelberg: O'Reilly / dpunkt.verlag GmbH, 2017.

[24] B. Gloger, Scrum: Produkte zuverlässig und schnell entwickeln, 5. Auflage Hrsg., München: Carl Hanser Verlag, 2016.

[25] W. Cunningham, „Manifest für Agile Softwareentwicklung,“ 2001. [Online]. Available: http://agilemanifesto.org/iso/de/manifesto.html.

[26] J. Schlosser und G. Sandmann, „Keine Angst vor Autosar – Leitfaden und nutzenbetrachtung für Funktionsentwickler,“ ATZelektronik, Bd. 4, Nr. 2, pp. 66-72, 2009.

[27] T. Schneider, „Achieving Cloud Scalability with Microservices and DevOps in the Connected Car Domain,“ in Software Engineering (Workshops), Wien, 2016.

[28] W. Cunningham and others, "Manifest für Agile Softwareentwicklung," 2001. [Online]. Available: http://agilemanifesto.org/iso/de/manifesto.html.

[29] J. Sutherland and J. Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time, UK: Random House Business Books, 2014.

[30] J. Schlosser, „Frühe Verifikation von Regelungssystemen mit Model-Based Design,“ in Embedded Software Engineering Konress, Sindelfingen, 2011.

[31] J. Schlosser, Architektursimulation von verteilten Steuergerätesystemen, Berlin: Logos Verlag, 2006.

[32] M. Hillbrand, „Agile Methoden skalieren, aber bitte nicht dogmatisch! Erfolgreich skalieren!,“ OBJEKTspektrum, Nr. 2, 2017.

[33] E. Petry, „How to Upgrade SPICE-Compliant Processes for Functional Safety,“ in Tenth International SPICE Conference, Pisa, 2010.

(Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband Embedded Software Engineering Kongress 2018 entnommen.)

Der Autor

Dr. Joachim Schlosser: Informatiker und Autor
Dr. Joachim Schlosser: Informatiker und Autor (Bild: www.joachimschlosser.de)

* Dr. Joachim Schlosser arbeitet bei Elektrobit Automotive, einem Softwarehaus für die Automobilbranche, als Manager im Consulting. Er führt Informatiker und Ingenieure, die Automobilhersteller und Zulieferer zu Agilen Entwicklungsmethoden, Funktionaler Sicherheit und Software-Architektur beraten.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 45783874 / Safety & Security)