Aufbau eines lebenswichtigen Systems mit Agile

Question

Betrachtet man den allgemeinen Trend der Kommentare in meiner Frage über Bau eines Flugzeugs mit Agile Das größte Problem neben den Kosten scheint die Sicherheit zu sein.

Sind die Leute der Meinung, dass es nicht möglich ist, mit agilen Methoden ein sicheres System zu bauen (oder zu beweisen, dass es sicher ist)? Wird dies nicht durch all die iterativen Tests gemildert? Ist es wahrscheinlich, dass ein Stück Software, das mit agilen Methoden entwickelt wurde, niemals so zuverlässig sein wird wie ein Gegenstück zu einer Wasserfallmethode?

Answer 1

Agile ist eine Methode zur Verwaltung eines Projekts, nicht eine Methode zum Testen oder Überprüfen der Sicherheit eines fertigen Projekts.

Ein sicherheitskritisches System muss auch nach seiner Fertigstellung noch ausgiebig getestet werden (in Bezug auf die Funktionalität), um absolut sicher zu sein, dass es tatsächlich den Anforderungen entspricht. Ich würde erwarten, dass diese Art von Arbeit einem separaten Team von Testern übertragen wird, das sich speziell auf solche Tests konzentriert.

Agiles Vorgehen eignet sich gut für weiche Anforderungen, bei denen der herkömmliche Produktlebenszyklus lang genug ist, um die Geschäftsziele zu ändern. In einem sicherheitskritischen Umfeld wären sich schnell ändernde oder zu wenig spezifizierte Anforderungen jedoch eine sehr schlechte Sache.

Ich glaube nicht, dass die Wasserfallmethode dem Code eine gewisse Ordnung oder Stabilität verleiht - wenn die einzelnen Sprints gut verwaltet werden, der Code getestet und überprüft wird, dann würde der kürzere Zyklus Code von gleicher Qualität hervorbringen, nur eben in Stücken.

Die Anwendung von Scrum gibt Ihnen eine Vorwarnung zu einem früheren Zeitpunkt im Projektverlauf, wenn die Dinge problematisch werden - es wird nichts anderes tun, als Verstecke für schlecht arbeitende Manager/Entwickler/wer auch immer zu beseitigen.

Kurz gesagt, es ist möglich, jede Art von System mit agilen Methoden zu entwickeln, solange Sie nicht erwarten, dass es das, was Sie entwickelt haben, testet. Das ist Sache der Prüfer.

Answer 2

Es gibt eine Reihe von öffentlichkeitswirksamen Softwarefehlern, die dieses Problem verdeutlichen. Im Besonderen, Ariane 5 Flug 501 und die Therac-25 sind beides Beispiele für Softwarefehler, die dieses Problem verdeutlichen. Die Ariane-5-Rakete kam 37 Sekunden nach dem Start aufgrund eines Ganzzahlüberlaufs in der Steuerungssoftware von ihrer Flugbahn ab. Der Unfall kostete 370 Millionen Dollar an verlorener Ausrüstung, aber es gab keine Todesopfer. Das Gleiche gilt für die Therac-25, ein medizinisches Gerät, das mehrere Menschen mit einer tödlichen Strahlendosis tötete.

Hätten diese Probleme mit einer besseren Software-Methodik verhindert werden können? Ich bin mir da nicht so sicher. Die Entscheidungen des Managements, die zum Scheitern der Ariane 5 beitrugen, hatten wenig mit der Art und Weise zu tun, wie die Software konstruiert war, und die Untersuchung der Therac-25 wurde durch den Glauben behindert, dass ein Versagen der Maschine nicht möglich sei.

Bessere Testmethoden hätten helfen können. Es ist schwer vorstellbar, dass ein guter statisch typisierter Compiler den Integer-Überlauf nicht gefunden hätte. Neue Testmethoden wie Pex mit seinem eingebauten Theorembeweiser in der Lage, nach Eckfällen zu suchen, und hätte die Sensoranomalien des Therac-25 erkennen können.

Aber keine Technik ist zuverlässig, wenn man sich nicht kompromisslos für die Sicherheit einsetzt, und zwar von der höchsten Führungsebene bis hinunter zu den Mitarbeitern, die das Produkt für den Versand verpacken.

Answer 3

Der GANZE Punkt bei sicherheitskritischen Systemen, den alle hier zu übersehen scheinen, ist, dass sie aufgrund ihres Potenzials, Menschenleben zu gefährden (manchmal in großem Maßstab), nachweislich korrekt sein müssen. Häufig ist ein Betriebszertifikat erforderlich, es sei denn, eine Genehmigungsbehörde ist davon überzeugt, dass die Anforderungen an das System genau spezifiziert wurden (oft unter Verwendung formaler Methoden wie Z und VDM), dass der Entwurf diese Anforderungen widerspiegelt (und dies auch nachgewiesen werden kann) und dass der Code den Entwurf genau widerspiegelt (was ebenfalls nachgewiesen werden kann).

In den meisten Fällen gibt es nicht die Möglichkeit, das Produkt zu testen, um einen solchen Nachweis zu erbringen (OK, Jungs, lasst uns mit dem Kernreaktor, der Boeing 777, der Therac 25 - was auch immer - loslegen und sehen, wo die Fehler sind). Sicherheitskritische Systeme (insbesondere solche der Kategorie S.I.L. 3 und höher) benötigen eine gründliche und umfassende Dokumentation, die in jeder Hinsicht im Widerspruch zum Agilen Manifest steht, soweit ich das beurteilen kann. Programmierer von sicherheitskritischen Systemen dürfen nicht einmal Änderungen an der veröffentlichten Software vornehmen, ohne eine neue Neubewertung der Software bei der Genehmigungsbehörde zu beantragen, und das zu Recht, wenn man bedenkt, mit welcher Strenge die Korrektheit der ersten Version nachgewiesen werden muss und welche katastrophalen Folgen ein Fehler hat.

Answer 4

Agile ist ein dynamisches Entwicklungsmodell - Sie verwenden es, wenn sich Anforderungen an Ihre Anwendung schnell und unvorhersehbar ändern sollen. Auch wenn die Anzahl Ihrer Entwickler noch zählbar ist. Sie verwenden es NICHT, nur weil es modern/in/hip/cool ist.

Sicherlich kann man mit Unit-Tests Fehler finden, aber sie beweisen nie deren Abwesenheit. Das Ändern/Hinzufügen von Anforderungen an die Anwendung während der Entwicklung beinhaltet in hohem Maße das Hinzufügen versteckter Fehler.

Für genau geplante Anwendungen, wie sie für sicherheitskritische Anwendungen typisch sind, sollten Sie eher statische Entwicklungsmodelle wie das Wasserfall- oder V-Modell verwenden.

Answer 5

Die meisten sicherheits- oder unternehmenskritischen Systeme können von einer eher standardisierten Entwicklungsstruktur wie dem Wasserfallmodell und formalen Codeüberprüfungen profitieren. Solche Methoden helfen, eine besser strukturierte Codebasis zu erhalten. Tolles Buch über Softwareentwicklung - vor allem, wenn das Projekt bereits mit einem agilen Prozess begonnen hat - Code Complete 2 ed.