Wäre es beispielsweise unglaublich gefährlich, dies für die Avionik-Software zu tun?
Beachte, ich verstehe Agile nicht ganz.
Ich habe an Flugsicherungssystemen gearbeitet, die im Wesentlichen einen Wasserfall-Prozess verwenden, und diese Projekte hätten definitiv von agilen Praktiken profitieren können. Ich mag es nicht, darüber nachzudenken, wie viel von diesem Code "aus Versehen" funktioniert hat, ohne irgendeinen automatischen Regressionstest auf Einheitenebene. Und die Anforderungen, die im Voraus gestellt werden, sind eine Art Ablenkungsmanöver. Es ist zwar richtig, dass Luft- und Raumfahrt-Systeme wahrscheinlich so nahe sind, dass Sie im Voraus festgelegte Anforderungen haben, aber Sie haben immer noch Argumente über die Bedeutung von mehrdeutigen Anforderungen, die nur dann auftauchen, wenn das System ist soll im Abnahmetest sein. Oder Sie haben Durchsatzprobleme, die niemand in Betracht gezogen hat, die sich aufgrund der Big-Bang-Integration spät im Spiel zeigen. Test-First, Spike-Lösungen, kontinuierliche Integration, Paar-Programmierung - ich denke, dass all dies die Projekte verbessert hätte, an denen ich gearbeitet habe.
UPDATE: Ganz zu schweigen davon, wie oft die "Design-Dokumente" am Ende des Projekts eine Lüge waren, weil sich das Design notwendigerweise angesichts der Realität entwickelte. Agile erkennt die Tatsache von emergentem Design, das in Waterfall-Projekten genauso zutrifft wie in jedem anderen, anstatt zu versuchen, so zu tun, als könne man das Design schon vor dem Schreiben von Code bekommen.
Ich arbeite in der Luft- und Raumfahrt (speziell Satelliten) und wir verwenden einen hybriden Ansatz, weil wir uns zwei unterschiedlichen Anliegen stellen müssen: den Anforderungen der realen Welt und den Anforderungen der Geschäftsprozesse.
Wir verwenden einen Wasserfall-ischen Ansatz für Raumfahrzeuganforderungen und kritische Abschnitte, weil Änderungen am Satelliten langsam und selten sind, und das Verschrauben dort schlecht ist.
Aber für die sich ständig ändernden Geschäftsprozesse verwenden wir einen agilen Ansatz, weil wie sie das Raumfahrzeug bewegen, ändert sich ständig aufgrund von Kundenanforderungen. Verschrauben bedeutet im schlimmsten Fall, dass der Benutzer nicht-so-nette Ergebnisse bekommt.
Ich habe nicht genug Erfahrung in diesem Bereich (außer einem Benutzer von Luftfahrtsystemen), um meine eigene wirklich unabhängige Meinung zu bilden. Aber all die Dinge, die ich über die kritischen Systeme lese, die die beste Erfolgsbilanz haben, lassen mich glauben, dass Wasserfall der beste Weg ist. Es ist möglich, weil die Leute bereit sind, die zusätzliche Verschwendung von Gefrieranforderungen zu berücksichtigen, um die Sicherheit zu fördern. Kompromisse sind ein bisschen anders in diesem Fall, denke ich.
Bestimmung der Anwendbarkeit agiler Praktiken für Mission und lebenskritische Systeme
Kurz gesagt, es gibt keine "Agile" Programmierung. Es gibt eine Reihe von Praktiken. Einige eignen sich besser als andere, aber im Allgemeinen wird jedes Projekt von einigen Praktiken profitieren.
Der größte Bereich, um den sich Menschen normalerweise kümmern, ist Modellierung und Architektur. Es gibt viele Teams, die agile Praktiken einsetzen - zum Beispiel kenne ich Mitglieder des Fun3d-Teams mit der NASA - sie nutzen Agile Praktiken und Umgang mit Dingen wie Space Shuttle-Unterstützung.
Es gibt mehrere Gruppen, die sich dieser Art von Arbeit widmen - so ist es möglich. Sie müssen sich Ihrer Risiken bewusst sein - wie jede andere Methode auch.
Agile sollte ein disziplinierter Prozess sein. Was auch immer Ihr Prozess ist, Sicherheitsfragen sollten in diesem Fall im Vorfeld behandelt werden. Ich sehe nicht, wie man in Iterationen liefert, ein kontinuierliches Build-System verwendet, die Prozessor-Burn-Raten berechnet, Stand-Up-Meetings hat, den Kunden aktiv beschäftigt hat, etc. würde die Sicherheit beeinträchtigen.
Es gibt viele Überlegungen. Der erste ist, was Ihre Sicherheitskritikalität ist. Wenn Ihre Antwort "A" oder "B" (und wirklich "A") ist, dann absolut NICHT. Sie werden nicht Agile in Form oder Form machen. Es gibt sehr strenge Kodierungsstandards, Dokumentationsstandards und Prozessstandards, die von Level A Software benötigt werden (mein Hintergrund von ungefähr 15 Jahren). Dies beinhaltet:
Sie müssen also nicht nur Ihren Code, Ihr Design und Ihre Anforderungen zertifizieren, sondern auch Toolsets, Compiler, automatisierte Testgeräte und so weiter.
Kurz gesagt, es ist wirklich keine kleine Leistung und es wird nicht mit einem kleinen Team gemacht werden. Ebenso sind Schnittstellen wirklich solide und sehr spezifisch sowie statisch. Das Ändern der Schnittstellen erfordert in der Regel die Koordination mit 3+ Unternehmen (Airframe-Fertigung, Vender 1 im Gespräch mit Vender 2).
Um ehrlich zu sein, kann eine Änderung um 12 Zeilen Code bis zu $ 170.000 kosten. Natürlich wird eine Codeänderung von 500 Zeilen 190.000 $ betragen. Kurz gesagt, es gibt einen enormen Prozess-Overhead, der mit Level A-Code verbunden ist (viel weniger mit Level B, noch weniger mit C und sehr wenig mit Level D), was kleine Iterationen sehr teuer macht; dh. es kostet viel Geld, um eine vollgetankte und fliegende 777 zu bekommen, um eine kleine Änderung zu testen. Sogar Systemtestlabors von großen Verkehrsflugzeugen werden eine Verbrennungsrate von $ 10.000 / Tag haben.
Zum Beispiel: Level A: HUD, Schubumkehrer, Power-Systeme, FADEC (Motorsteuerung) Level B: Sekundäre Schaltlogik, Vocal Communication Systeme. Level C: Im Flug Datenlinks. Level D: In Flugunterhaltungssystemen.
Level D und vielleicht Level C könnten Kandidaten für Agile sein.
Ich denke, das hängt davon ab, wie die Sicherheitsanforderungen in den Prozess integriert sind. Wenn es sich um eine zusätzliche Testreihe handelt, steht das nichts im Widerspruch zur agilen Programmierung. Ich denke, dass agile Methoden Ihnen helfen können, sicherere Software zu produzieren, weil agile Projekte tendenziell von höherer Qualität sind als Wasserfall-Projekte. Wichtig ist, dass die zusätzliche Qualitätssicherung, die Sie installiert haben, auch für die agilen Methoden verwendet wird.
Aber wenn die Sicherheitsanforderungen auf den Bauprozess angewendet werden, steht das im Widerspruch zu agilen Methoden.
Tatsächlich gibt es eine Variation des Wasserfallmodells, das sogenannte V-Modell, das beispielsweise von IEC61508 favorisiert wird. Es ist Wasserfall-Art, aber mit Vorkehrungen für die Wiederholung (en) des grundlegenden Projektzyklus. Der Hauptzweck der Wiederholungen in diesem Fall besteht darin, Probleme zu behandeln, die in verschiedenen Phasen des Prozesses festgestellt wurden. Die Grundidee ist, dass je später Sie auf ein Problem stoßen, desto weiter zurück in Ihrem Prozess müssen Sie gehen, um die Auswirkungen Ihrer Änderungen zu kümmern und zu überprüfen.
Also ist es nicht wirklich agil, aber ...: -)
Sie könnten den agilen Ansatz verwenden, aber der erste Pass müsste Ihre Sicherheitsaspekte beinhalten oder zumindest dafür sorgen, dass Sie sich nicht in den Fuß schießen und das Ganze neu schreiben. Aber ich stimme Brian zu, es ist wahrscheinlich besser, den Wasserfall-Ansatz für solche Projekte zu verwenden.
Auf der EuroStar 2009-Konferenz sprach Gittie Ottosen darüber, wie sie agil in ihrem Unternehmen vorgehen. Beeindruckend ist, dass diese Firma Systematic Software für Flugzeuge, Militär usw. entwickelt. Sie tun dies in Übereinstimmung mit CMMI 5, ISO 9001 und AQAP 150 & amp; 2110. Agile kann also auf Systeme mit hohen Regularien angewendet werden. Vielleicht versuchen Sie, diese Präsentation nachzuschlagen und versuchen Sie, mehr Informationen von ihm zu bekommen.
Tags und Links real-time agile safety-critical sdlc