Erfahren Sie, wie die Continuous Quality Platform von Parasoft dabei hilft, Testumgebungen zu steuern und zu verwalten, um zuverlässig hochwertige Software zu liefern. Für Demo registrieren >>
Autonomes Fahren ist ein sehr wettbewerbsfähiger Bereich, und Entwicklergeschwindigkeit ist ein Mantra. Wer zuerst ein zertifiziertes Produkt auf den Markt bringen kann, hat einen erheblichen Vorteil gegenüber der Konkurrenz. Daher können Entwickler statische Analysen und andere Qualitätsinitiativen leicht als Hindernis betrachten. Insbesondere weil der Bereich des autonomen Fahrens nach Talenten hungert, stellen Unternehmen intelligente Entwickler ein, auch wenn sie keinen Hintergrund in Bezug auf Sicherheit haben. Entwickler mit einem Hintergrund ohne funktionale Sicherheitskultur kennen jedoch nicht alle Qualitätsprozesse, die für die sicherheitskritische Softwareentwicklung erforderlich sind. Dies kann das kulturelle Buy-In zu einer Herausforderung machen.
Manchmal scheint es so, als ob die Schaffung eines internen Konsenses für qualitätsorientierte Praktiken einen Master-Abschluss in Psychologie oder die Fähigkeiten eines ausgebildeten Verhandlungsführers erfordert. In früheren Projekten war ich dafür verantwortlich, statische Analysen und die Einhaltung von AUTOSAR C ++ 14-Kodierungsstandards als nachhaltig einzuführen Prozess. Autonome Fahrsoftware ist sehr innovativ und die dafür verwendeten Softwarekomponenten werden mit modernem C ++ entwickelt. Vor diesem Hintergrund ist der Codierungsstandard AUTOSAR C ++ 14 der am besten geeignete Standard für autonome Fahrsoftware, da er modernes C ++ unterstützt und für eine sicherheitsorientierte Entwicklung entwickelt wurde.
Um die Unüberzeugten zu überzeugen, habe ich mehrere Präsentationen gehalten, in denen verschiedene Aspekte erörtert wurden. Trotz all dieser Diskussionen und Vereinbarungen widersetzen sich einige Entwickler der Analyse des gesamten von ihnen erstellten Codes. Hier sind einige der wichtigsten Punkte, auf die ich mich konzentriere, um die richtigen Prozesse einzurichten:
Die autonome Fahrtechnik befindet sich in einem sehr frühen Stadium. Ein Großteil des erstellten Quellcodes ist nur ein Prototyp, um neue Ideen zu testen. Einige Entwickler möchten keine Zeit damit verschwenden, die Codierungsstandardkonformität zu gewährleisten. Sie möchten lediglich schnell etwas schreiben und es testen. Eine typische Geschichte, die ich gehört habe, lautet: „Ich möchte diesen neuen Algorithmus nur testen. Wenn er funktioniert, schreibe ich den Code neu, um ihn sauber zu machen.“ Das klingt unschuldig genug, aber die Realität ist, dass es nur eine wachsende technische Verschuldung gibt.
Wenn wir von Prototyp zu Prototyp wechseln, nehmen wir normalerweise viel Code mit, statistisch gesehen können es bis zu 80% des Codes sein. Wir können es uns also nicht leisten, einen Prototyp mit schlechtem Code zu erstellen und ihn später zu reparieren, da wir von Anfang an gewusst haben, dass wir dafür keine Zeit haben. Selbst wenn es sich um einen Prototyp handelt, muss der Code konform sein, da das Endprodukt eine erhebliche Menge an Code enthalten wird, der ursprünglich als Prototyp erstellt wurde.
Wenn Sie sich nicht darauf konzentrieren, es jetzt statt später zu tun, können Sie sich darauf konzentrieren, es jetzt zu tun Vermeiden Sie es, eine unbekannte Zeit zu verbringen Am Ende sehen die Entwickler darin, den Prozess zu verbessern, anstatt eine Verlangsamung einzuführen. Wenn Sie den Prozess effizient in den Workflow des Entwicklers integrieren können, ohne die Geschwindigkeit oder Kreativität zu beeinträchtigen, wird die Arbeit mit ihm viel einfacher. Es ist viel einfacher, etwas sauber und ordentlich zu halten, als am Ende ein großes Durcheinander zu beseitigen. Wenn Sie konsistente, wartbare Methoden zum Schreiben von kompatiblem Code erstellen, können Sie später weniger Probleme feststellen.
Aber selbst wenn Sie in der Lage sind, einen Prozess zur Einhaltung von Codierungsstandards frühzeitig erfolgreich einzuführen, wird zwangsläufig bereits eine (erhebliche) Menge an Code vorhanden sein, die bereits vom Team erstellt und teilweise vererbt wurde. Und während Sie das statische Analysetool (Parasoft C / C ++ - Test) und den Standard (AUTOSAR) auswählen, erstellt das Team in der Zwischenzeit viel Code ohne Compliance-Richtlinien! Daher ist es wichtig, auch eine Richtlinie für Legacy-Code zu erstellen. Zwei großartige Richtlinien sind:
Mit diesen Strategien können Sie Legacy-Code adressieren, neuen Code einführen und den Platz weiterhin aufgeräumt halten.
Um die Prozesse zur Einhaltung statischer Analyse- und Codierungsstandards in der gesamten Entwicklungsorganisation erfolgreich anzuwenden, profitieren Sie von den folgenden Schritten:
Ijaz ist ein Ingenieur für funktionale Sicherheit mit mehr als 14 Jahren Erfahrung in der Softwareentwicklung / -prüfung. Seine jüngsten Erfahrungen konzentrierten sich auf die selbstfahrende Technologie, führten die Implementierung von ISO 26262 an und erstellten simulierte Szenarien, um die selbstfahrende Technologie rigoros zu testen.