Build an Aircraft using Agileに関する私の質問のコメントの一般的な傾向を見ると、コスト以外の最大の問題は安全性のようです。
アジャイルを使用して安全なシステムを構築する (または安全であることを証明する) ことはできないと人々は感じていますか? すべての反復テストでこれが軽減されるわけではありませんか? アジャイルを使用して開発されたソフトウェアは、ウォーターフォールなどの対応するソフトウェアほど信頼できない可能性はありますか?
1166 次
5 に答える
5
アジャイルはプロジェクトを管理する方法であり、完成したプロジェクトの安全性をテストまたは検証する方法ではありません。
セーフティクリティカルシステムは、それが実際にタスクに対応していることを絶対的に確認するために、それが完了した後（機能的に）、依然として広範なテストを必要とします。この種の作業は、そのようなテストに特に焦点を当てている別のテスターチームに引き継がれることを期待しています。
アジャイルは、従来の製品ライフサイクルがビジネス目標を変更するのに十分な長さであるソフト要件に適していますが、セーフティクリティカルな環境では、急速に変化する要件や指定不足の要件は非常に悪いことだと思います。
ウォーターフォールを使用すると、コードに本質的な順序や安定性がもたらされるという考えは購入しません。個々のスプリントが適切に管理され、コードがテストおよびレビューされている場合、サイクルが短いほど、同じ品質のコードが生成されます。チャンク。
スクラムを使用すると、プロジェクトのタイムラインの早い段階で問題が発生したときに注意が必要になります。それは、パフォーマンスの低いマネージャー/開発者/誰にとっても隠れ場所を取り除く以外に何もしません。
要するに、構築したものをテストすることを期待しない限り、アジャイルメソッドを使用してあらゆる種類のシステムを構築することが可能です。テスターの方です。
于 2009-07-13T12:07:15.217 に答える
3
ここで誰もが見逃しているように見える安全上重要なシステムの全体的なポイントは、人命の損失を引き起こす可能性があるため (時には大規模に)、それらが正しいことを証明する必要があるということです。システムの要件が正確に指定されていること (多くの場合、Z や VDM などの正式な方法を使用)、設計がそれらの要件を反映していること (およびそのようなことが証明できること) を認可機関が満足していない限り、多くの場合、運用証明書が必要です。 ) と、コードが設計を正確に反映していること (再度そのことが証明されました)。
多くの場合、そのような証拠を提供するために製品をテストするオプションは存在しません (原子炉、ボーイング 777、セラック 25 など、なんでもいいので、バグがどこにあるかを確認してみましょう)。セーフティ クリティカル システム (特に SIL 3 以上に分類されるシステム) には、徹底的で包括的なドキュメントが必要です。これは、私が見る限り、あらゆる点でアジャイル マニフェストと完全に矛盾しています。安全性が重要なシステムのプログラマーは、ライセンス機関にソフトウェアの再評価を新たに要求することなしに、リリースされたソフトウェアに変更を加えることさえ許されません。めちゃくちゃ。
于 2010-04-16T19:52:14.703 に答える
3
この問題を明らかにする有名なソフトウェア障害がいくつかあります。特に、Ariane 5 Flight 501とTherac-25は、この問題を浮き彫りにするソフトウェア障害の例です。アリアン 5 ロケットは、誘導ソフトウェアの整数オーバーフローにより、打ち上げから 37 秒後に飛行経路を外れました。この事故で失われた機器は 3 億 7000 万ドルでしたが、人命の損失はありませんでした。同じことは、致死量の放射線で数人を殺した医療機器である Therac-25 についても言えません。
これらの問題は、より優れたソフトウェア手法で防ぐことができたでしょうか? 私はちょっと確信が持てません。アリアン 5 の失敗の原因となった管理上の決定は、ソフトウェアの構築方法とはほとんど関係がなく、Therac-25 の調査は、マシンが失敗することはあり得ないという信念によって妨げられました。
より良いテスト方法が役に立ったかもしれません。静的に型付けされた優れたコンパイラが整数オーバーフローを検出できなかったとは信じがたいことです。ビルトインの定理証明器を備えたPexのような新しいテスト手法には、コーナー ケースを検索する機能があり、Therac-25 に存在するセンサーの異常を特定できた可能性があります。
しかし、最高レベルの管理者から出荷のために製品を箱詰めする人々に至るまで、安全性に対する妥協のない取り組みがなければ、信頼できる技術はありません。
于 2009-07-10T15:57:32.440 に答える
-1
ほとんどのセーフティ クリティカルまたはミッション クリティカルなシステムは、ウォーターフォール モデルや正式なコード レビューなど、より標準的な開発構造の恩恵を受けることができます。このようなメソッドは、より構造化されたコード ベースを維持するのに役立ちます。ソフトウェア構築に関する優れた本 - 特にプロジェクトがすでにアジャイル プロセスを使用して開始されている場合 - Code Complete 2 ed.
于 2009-07-10T16:06:51.330 に答える