スパイラルモデル

スパイラルモデルは、リスク主導のソフトウェア開発プロセスモデルです。スパイラル モデルは、特定のプロジェクト固有のリスク パターンに基づいて、チームが増分型、ウォーターフォール型、進化型プロトタイピングなどの 1 つ以上のプロセス モデルの要素を採用するようにガイドします。

このモデルは、1986 年の論文「ソフトウェア開発と拡張のスパイラル モデル」でBarry Boehmによって初めて説明されました。 ^[2] 1988 年に Boehm は同様の論文^[3]をより広い読者層に向けて発表しました。これらの論文では、スパイラル モデルについて論じたその後の多くの出版物で再現された図が紹介されています。

これらの初期の論文では、「プロセス モデル」という用語が、スパイラル モデルだけでなく、増分、ウォーターフォール、プロトタイピング、その他のアプローチにも使用されています。ただし、スパイラル モデルの特徴であるリスク主導で他のプロセス モデルの機能を融合する機能は、すでに存在しています。

スパイラルモデルのステップをリスク主導でサブセット化することで、仕様指向、プロトタイプ指向、シミュレーション指向、自動変換指向、またはその他のソフトウェア開発アプローチを適切に組み合わせたモデルを実現できます。[ ^3]

^{その後の出版物[1]}で、Boehmはスパイラルモデルを「プロセスモデルジェネレーター」と表現しています。これは、プロジェクトのリスクに基づいた選択によって、プロジェクトに適したプロセスモデルが生成されるものです。したがって、増分、ウォーターフォール、プロトタイピングなどのプロセスモデルは、特定のプロジェクトのリスクパターンに適合するスパイラルモデルの特殊なケースです。

ボーム氏は、オリジナルのスパイラル モデル図の過度な単純化から生じる誤解もいくつか指摘しています。その中で最も危険な誤解は次のものだと彼は言います。

• 螺旋は単に滝の増分の連続であるということ。
• すべてのプロジェクト活動が単一のスパイラルシーケンスに従うこと。
• 図内のすべてのアクティビティは、示された順序で実行する必要があります。

これらの誤解は、いくつかのプロジェクトのリスク パターンには当てはまるかもしれませんが、ほとんどのプロジェクトには当てはまりません。

全米研究評議会の報告書^[4]では、このモデルは人間の使用者に関連するリスクも含めるように拡張されました。

これらを「危険な螺旋の類似物」とより明確に区別するために、Boehm は螺旋モデルのすべての本物の応用に共通する 6 つの特徴を挙げています。^{[引用が必要]}

螺旋モデルの本格的な応用は、常に6つの特徴を示すサイクルによって駆動されます。Boehmは、不変条件に違反する「危険な螺旋類似物」の例でそれぞれを説明しています。^[1]

プロジェクトの主要な成果物を順番に定義すると、多くの場合、利害関係者の「勝利条件」(目標と制約) を満たすシステムを開発できる可能性が高まります。

この不変条件により、ウォーターフォール モデルの基本的な前提が適用されない設定で、一連の増分ウォーターフォール パスを使用する「危険なスパイラル類似」プロセスが除外されます。Boehm はこれらの前提を次のように列挙しています。

1. 要件は実装前にわかっています。
2. 要件には、コスト、スケジュール、パフォーマンス、安全性、ユーザー インターフェイス、組織への影響などによるリスクなど、未解決の高リスクの影響はありません。
3. 要件の性質は、開発や進化の過程であまり変化しません。
4. 要件は、ユーザー、顧客、開発者、保守担当者、投資家など、すべての主要なシステム関係者の期待と一致しています。
5. 要件を実装するための適切なアーキテクチャが十分に理解されています。
6. 順番に進めるには十分なカレンダー時間があります。

これらの仮定が当てはまる状況では、要件を指定せずに順番に進めないことはプロジェクトのリスクとなります。したがって、ウォーターフォール モデルは、スパイラル モデルのリスク主導の特殊なケースになります。

この不変量は、スパイラル モデルの各サイクルで発生する必要がある 4 つのアクティビティを識別します。

1. 成功に不可欠なすべての関係者の勝利条件を考慮してください。
2. 勝利条件を満たすための代替アプローチを特定し、評価します。
3. 選択したアプローチから生じるリスクを特定し、解決します。
4. 成功に不可欠なすべての関係者から承認を得て、次のサイクルを追求するコミットメントを得ます。

これらのアクティビティのいずれかを省略または省略するプロジェクト サイクルでは、主要な利害関係者に受け入れられない、またはリスクが高すぎるオプションを追求することで労力を無駄にするリスクがあります。

一部の「危険なスパイラル類似」プロセスでは、主要な関係者を特定の連続フェーズまたはサイクルから除外することで、この不変条件に違反します。たとえば、システム保守担当者と管理者は、システムの定義と開発に参加するよう招待されない場合があります。その結果、システムは勝利条件を満たせないリスクがあります。

あらゆるプロジェクト活動 (要件分析、設計、プロトタイピング、テストなど) について、プロジェクト チームはどの程度の労力で十分かを決定する必要があります。本物のスパイラル プロセス サイクルでは、全体的なリスクを最小限に抑えながらこれらの決定が行われます。

たとえば、ソフトウェア製品のテストにさらに時間を費やすと、粗悪品が市場で拒否されるリスクが軽減されることが多い。しかし、追加のテスト時間によって、競合他社が早期に市場に参入するリスクが増大する可能性がある。スパイラル モデルの観点からは、テストは総リスクが最小になるまで実行し、それ以上は実行しない方がよい。^{[引用が必要]}

この不変条件に違反する「危険なスパイラル類似物」には、スケーラビリティの問題によるリスクを無視する進化プロセスや、製品の将来の増分に対応するために再設計または交換する必要がある技術アーキテクチャに多額の投資を行う増分プロセスが含まれます。

プロジェクト チームは、あらゆるプロジェクト成果物 (要件仕様、設計ドキュメント、テスト計画など) について、どの程度の詳細があれば十分かを判断する必要があります。本物のスパイラル プロセス サイクルでは、全体的なリスクを最小限に抑えながらこれらの決定が行われます。

要件仕様を例にとると、プロジェクトでは、正確な仕様によってリスクが軽減される機能（ハードウェアとソフトウェア間のインターフェース、元請け業者と下請け業者間のインターフェースなど）を正確に指定する必要があります。逆に、正確な仕様によってリスクが増大する機能（グラフィカル画面レイアウト、既製コンポーネントの動作など）は、プロジェクトでは正確に指定しないでください。

Boehm によるスパイラル モデルの当初の説明には、プロセス マイルストーンは含まれていませんでした。その後の改良で、彼は進捗状況の指標とコミットメント ポイントとして機能する 3 つのアンカー ポイント マイルストーンを導入しました。これらのアンカー ポイント マイルストーンは、主要な質問によって特徴付けることができます。

1. ライフサイクル目標。全員の勝利条件を満たすための技術的および管理的アプローチが十分に定義されていますか? 関係者が答えが「はい」に同意する場合、プロジェクトはこの LCO マイルストーンをクリアしています。そうでない場合は、プロジェクトを中止するか、関係者が「はい」に到達するために別のサイクルに取り組むことができます。
2. ライフ サイクル アーキテクチャ。全員の勝利条件を満たすための推奨アプローチが十分に定義されており、すべての重大なリスクが排除または軽減されていますか? 関係者が答えが「はい」に同意する場合、プロジェクトはこの LCA マイルストーンをクリアしたことになります。そうでない場合は、プロジェクトを中止するか、関係者が「はい」に到達するために別のサイクルに取り組むことができます。
3. 初期運用能力。システムを立ち上げることで、ソフトウェア、サイト、ユーザー、オペレーター、および保守担当者が全員の勝利条件を満たすのに十分な準備が整っていますか? 関係者が答えが「はい」に同意すれば、プロジェクトは IOC マイルストーンをクリアし、立ち上げられます。そうでない場合は、プロジェクトを中止するか、関係者が「はい」に到達するために別のサイクルに取り組むことができます。

この不変条件に違反する「危険なスパイラル類似物」には、定義が不十分なアーキテクチャを持つソリューションの実装に多大なリソースを投入する進化的および漸進的なプロセスが含まれます。^{[説明が必要]}

3 つのアンカー ポイント マイルストーンは、 Rational Unified Process (RUP) に簡単に適合します。LCO は RUP の開始フェーズと詳細化フェーズの境界を示し、LCA は詳細化フェーズと構築フェーズの境界を示し、IOC は構築フェーズと移行フェーズの境界を示します。

この不変条件は、システム全体の重要性と、そのライフサイクル全体にわたる長期的な懸念を強調します。ソフトウェア コードの初期開発に重点を置きすぎる「危険なスパイラル類似」は除外されます。これらのプロセスは、公開されているオブジェクト指向または構造化ソフトウェアの分析と設計のアプローチに従い、プロジェクトのプロセス ニーズの他の側面を無視することで発生する可能性があります。