私たちのドメインの設計フェーズと実装フェーズのそれほど厳密な分離
私は非常に大きな政府契約を結んでいる会社で働いています。政府プロジェクトの現実の一部として、私たちはエネルギー省から私たちに下される要件を処理する義務があり、ソフトウェア品質手順でそれらの要件を満たす責任があります。
この辺りで私たちがほとんどのことをする方法は非常に面倒で、NQA-1の要件が実際に要求するよりもはるかに進んでいます。これは、私のプロジェクトの管理上の安全でないソフトウェアを改訂するために、ユーザーに1行のコードを提供できるようにするために6か月のサイクルを見ていることを意味します。
現在、手続きの見直しを進めており、「設計・実装」の草案を見るまではとてもワクワクしていました。著者は、設計と実装が完全に別個のアクティビティである厳密なウォーターフォールモデルを狙っているようです。
最悪の部分は、実装を行うには、承認された設計ドキュメントが必要なことです（これは、このあたりのすべてのように、言うのは簡単です）。実装後に設計を変更する場合は、設計ドキュメントに戻って変更し、再承認を受けてから、実装に戻る必要があります。
私の意見では、これは狂気であり、実際には今日よりも悪いです。プロジェクトによっては、設計と実装の境界線が非常に簡単に曖昧になる可能性があり、完全な設計ドキュメントが完成する限り、それを順番に行う必要はありません。
私（および他の数人の関係する同僚）が私たちのケースをより厳密でないバージョンのウォーターフォールについて訴えることができるように、私たちは会議を持っています。
設計ドキュメントと実装の両方で想定している並列ワークフローを可能にするウォーターフォール設計のバリエーションはありますか？
または、両方の部分の間の反復アプローチを検討する価値があることをどのように実証できますか？
私はNQA-1に精通していませんが、 エネルギー省が提供する連邦プロジェクトディレクターの概要 を読みました。 NQA-1に関するIAEAスライドデッキ も見つけました。私の知る限り、NQA-1は、私が精通している他の品質管理基準と多少似ています。それはあなたが特定のことをしなければならないこと、そしてあなたが行われていることの特定の証拠を提供しなければならないことをあなたに伝えますが、あなたがそれらのことをどのように行うかを指示しません。これは、商用航空宇宙の世界におけるAS9100とDO-178の組み合わせに似ているようです。
両方のビジネスの観点から、すべてのプロジェクト（特に、NQA-1要件の範囲に含まれないプロジェクト）でNQA-1の要件を超えることには問題があります。私が読んでいる概要は、NQA-1および関連する規制が、「これらの構造、システム、およびコンポーネントの安全関連機能に影響を与える活動」に適用されることを具体的に示しています。概要では、安全関連の機能を実行しないシステムは、「ISO-9000などのそれほど厳しくない規制や規格に該当する可能性がある」とさえ述べています。
DO-178は、「設計保証レベル」と呼ばれるものを要求しています。ソフトウェアが安全性に与える影響に基づいて、より多くの要件がソフトウェアに課されます。これにより、機内エンターテインメントシステム用のソフトウェアを自動操縦用のソフトウェアとは異なる方法で開発できます。 NQA-1は、階層型アプローチではなく、バイナリ（yes/no）の場合があります。私の最初の推奨事項は、開発中のソフトウェアの評価を実行することです。 FDAガイダンスと航空宇宙産業ガイダンスはどちらも、システムの重要性と標準の適用可能性を判断する方法を提供します。 NQA-1に関連する文書の一部として同様のガイダンスが存在するのではないかと思います。あなたはその情報を見つけてそれを提示しなければならないでしょう。
NQA-1のさまざまなプロジェクトへの適用可能性に関する情報を提示し、それが適用されない場所を特定したら、NQA-1をフォローすることによるプロジェクトへの影響（ドルと時間の観点から考える）についてビジネスケースを作成できます。適用されません。
プロセスの観点から（特にISO-9001などに準拠している場合）、文書化されたプロセスでは、NQA-1に準拠する必要のあるプロジェクトと準拠しないプロジェクトを考慮する必要があります。すべてのプロジェクトに適用される1セットのプロセス文書を確認することにより、外部監査を簡素化する必要があります。私たち（航空宇宙産業）は、すべてのプロジェクトに適用される「最小基準」と、DO-178の各設計保証レベルの追加要件を定義することでこれを実現しています。
この時点で、すべてのプロジェクトにNQA-1を適用するのではなく、それらのプロジェクトのプロセスをそれほど厳しくしないことを主張する必要があります。ただし、それでも順次プロセスが残ります。あなたが目指しているプロセスは反復的であるため、規制された環境でアジャイル手法を採用する際に行われた作業を見ることができます。規制された環境でのスクラムのアプリケーションであるR-Scrumについていくつかの論文が書かれています。 Disciplined Agile Delivery は、作成者が「ガバナンス」と呼んでいるものを説明する新しいプロセスフレームワーク（リーンソフトウェア開発、スクラム、エクストリームプログラミング、およびRational Unified Processに基づく）です。規制された環境でアジャイルメソッドを使用する機能と相まって、アジャイル開発の利点をすぐに見つけることができるはずです。これは、重要でないプロジェクトだけでなく、ある程度、アジャイルメソッドを検討するための事例を提示するはずです。重要なプロジェクトも同様です。
アジャイル手法への移行が組織にとって大きな飛躍であることに懸念がある場合は、「フェーズが重複するウォーターフォール」または「刺身モデル」があります。 Steve McConnell（Peter DeGrace経由）はこれを Rapid Development で説明しています。それでも、概念、要件、アーキテクチャ設計、詳細設計、コーディング/デバッグ、およびシステムテストを順番に進めます。ただし、前のアクティビティが完全にサインオフされる前に、次のアクティビティを開始します。たとえば、詳細な設計作業を行っているときに、システムの一部がよく理解されている場合は、その部分のコーディングに取り掛かることができます。理想的には、システムのその部分の要件と設計は安定しており、詳細な設計は間違いを見つけるためにピアレビューされています。
航空宇宙（AS9100およびDO-178）および医療（ 医療機器に含まれるソフトウェアの市販前提出の内容に関するガイダンス 、 ソフトウェア検証の一般原則;業界およびFDAスタッフ向けの最終ガイダンス ）。これらは、大量のソフトウェアを使用する他の高度に規制された業界であり、規制の枠組み内で反復型開発を成功裏に実装しています。
ただし、この時点でできることは、いくつかの例を使用してケースを作成することだけです。組織によっては、アジャイルプロセスを採用していない組織に対処する準備をする必要があります。 NQA-1をプロジェクトに選択的に適用したり、反復型または反復型開発をサポートする文書化されたプロセスを開発したりできるからといって、組織がそうすることを選択するわけではありません。あなたは、あなたが持っているプロセスと単純に共存し、順次プロセスで作業する準備をする必要があります。
NQA-1の全文を見ずに、非常に信頼できる答えを書くのは難しいですが、これが議論の道を提供してくれることを願っています。