スパイラルモデル：履歴、特性、段階、例 - 技術 - 2025

スパイラルモデルは、アプリケーション開発プロセスの原型です。これは、ソフトウェア開発は、確立された目的が達成されるまで繰り返される反復サイクルであるという仮説に基づいています。ソフトウェアの開発時に発生する可能性がある多数のリスクを処理する機能があります。

これは、リスク管理をサポートするための最も重要なモデルの1つです。その名前が示すように、このモデルはらせん状に表示され、モデルのさまざまな段階がさまざまなサイクルで分布しています。モデルのサイクル数は固定されておらず、プロジェクトごとに異なる場合があります。

分析、評価、計画、開発。ソフトウェア開発スパイラルソース：Beao commons.wikimedia.org

歴史

創作

スパイラルモデルは、アメリカの数学者でソフトウェアエンジニアリングの教授であるバリーベームによって定義されました。複雑なアプリケーションの開発に関する1986年のコンセプトを発表した後、1988年に彼の記事「ソフトウェア開発と改善のスパイラルモデル」でより包括的なフレームワークで彼のモデルを発表しました。

この1988年の出版物の一部は、スパイラルモデルをグラフィカルに表しており、ソフトウェア開発プロセスがスパイラルのように見え、サイクルによってサポートされている様子を包括的に示しています。

ベームは、建設的コストモデル（COCOMO）、ソフトウェアプロセスのスパイラルモデル、要件の決定と管理へのG理論（win-win）アプローチなど、ソフトウェアエンジニアリングへの数多くの貢献で知られています。ソフトウェアの。

ウォーターフォールモデルの代替

ベームは彼の出版物で、以前に確立されたウォーターフォールモデルの可能な代替策としてスパイラルモデルを説明しました。これは、彼の実践の基礎としても機能しました。

スパイラルモデルは、循環的発達について議論した最初のモデルではありませんでしたが、反復が重要である理由を説明した最初のモデルでした。当初計画されていたように、それは反復が通常6か月から2年の範囲である大規模で複雑なプロジェクトを対象としています。

このモデルは、ウォーターフォールモデルとは異なり、ソフトウェア開発タスクが直線的に設計されていることを前提とせず、むしろ反復的なタスクと見なします。

この循環モデルは、モデルベースのソフトウェアエンジニアリングアーキテクチャ（MBASE）と極端なプログラミングに影響を与えました。

スパイラルモデルの特徴

リスク管理

このモデルが他のソフトウェアプロセスモデルと大きく異なる点は、リスクを明示的に認識することです。したがって、リスクを繰り返し評価し、開発中の製品を毎回検証することにより、大規模なソフトウェアプロジェクトの失敗を大幅に削減します。

このコンピューターモデルには、ウォーターフォールモデル、プロトタイピングモデル、反復モデル、進化モデルなど、ソフトウェアライフサイクルの他のほぼすべてのモデルのコンポーネントが含まれています。

このため、他のモデルでは一般的に処理できないほとんどすべての種類のリスクを処理できます。ただし、コンポーネントが非常に多いため、このモデルは他のソフトウェア開発モデルよりもはるかに複雑です。

スパイラルの説明

スパイラルの各回転は、モデルの4つの段階を表す4つの象限が常に通過する完全なサイクルを表します。

スパイラルのサイズが大きくなるにつれて、進歩も大きくなります。したがって、ステージは1回だけではなく、らせん状に数回実行されます。

この周期的な繰り返しにより、プロジェクトは確立された目標にゆっくりと近づきますが、開発プロセスが失敗するリスクは大幅に最小限に抑えられます。

ジェネリック

4つのステージはサイクルの基本的な目標を実装するだけですが、各サイクルで明示する必要はありません。

各サイクルの順序も厳密に決定されていません。したがって、モデルはいつでも他のモデルと組み合わせることができます。

フレキシブル

プロジェクトのフェーズごとに目的の定義、リスク分析、開発、計画のプロセスを個別に実行するため、非常に柔軟性があります。

メタモデル

他のモデルが含まれているため、メタモデルと見なされます。たとえば、スパイラルが単一のサイクルである場合、この古典的なモデルの段階的なアプローチが組み込まれているため、ウォーターフォールモデルを表します。

また、プロトタイピングモデルアプローチを使用して、各サイクルの最初にプロトタイプを組み立て、リスクを管理します。

さらに、スパイラルの反復は、最終的なシステムが構築される進化のレベルと見なすことができるため、進化のモデルと互換性があります。

ステージ

目的、代替案、制約を決定する

システム要件は、パフォーマンス、ハードウェア/ソフトウェアインターフェイス、成功の主要な指標など、可能な限り詳細に定義されています。現在の開発サイクルにどのような目標を関連付ける必要があるかが考慮されます。

さらに、その実装のさまざまな代替案が検討されます。既存のコンポーネントの購入、再利用、またはアウトソーシングなど

同様に、コスト、スケジュールとインターフェース、時間の消費などの制限が決定されます。

リスク評価

提案されたすべての代替案が評価されます。目的と制約は、最適なソリューションを選択するための参照を決定する役割を果たします。

さらに、経験の欠如、新技術、厳しいスケジュール、不十分なプロセスなど、プロジェクトの成功を妨げる可能性のあるリスクが特定され、最もリスクの低い最も収益性の高い戦略が実施されます。

最後に、プロトタイピング、シミュレーション、分析モデル、ユーザー調査などの方法が使用されます。

開発とテスト

必要な開発はすべて、テクノロジーと選択されたソリューションを使用して行われます。反復のたびに、アプリケーションのより良いバージョンが作成されます。

実際のコードは、希望する結果が得られるまで数回記述およびテストされ、その後、将来の開発ステップの基礎として機能します。

次のサイクルの計画

1つのサイクルが完了すると、次のサイクルの計画が始まります。この計画は、次の目的の定義を考慮して、サイクルの目的が達成された場合にプロジェクトを通常どおり続行することです。

開発の前の段階で問題が判明した場合は、他のソリューションを見つけることもできます。既存の戦略は、以前に定義された代替案の1つまたは新しい代替案で置き換えることができます。これにより、指定された目標に到達するための新しい試みが開始されます。

例

米軍は、Future Fighting Systems（SCF）近代化プログラムの開発とアップグレードにスパイラルモデルを採用しました。

2003年に正式に発足したSCFは、非常に高速で柔軟な戦場のネットワークにリアルタイムで接続された車両を軍に装備することを想定していました。

プロジェクトは、それぞれ約2年の4つの開発スパイラルに分割されました。スパイラル1は2008年に開始され、使用と評価のためのプロトタイプを提供する予定でした。

スパイラル1の完成後、スパイラル2は2010年に開始される予定でした。最終的な製品開発は2015年に提供される予定でした。

2005年8月、ボーイングはプロジェクトの最初の主要なマイルストーンの完了を発表しました。これはシステムの機能的なオーバーホールでした。ボーイングアンドサイエンスアプリケーションインターナショナルコーポレーションがプロジェクトの共同リーダーでした。

しかし、ペンタゴンは2005年10月、イラク戦争とハリケーンカトリーナからの援助によるコストへの影響が大きいため、プロジェクトを延期することを推奨しました。

このミッションでスパイラルモデルの利点を証明できず、予算削減が発生した後、プロジェクトは2009年にキャンセルされました

利点

循環構造

このタイプの構造により、定期的なチェックにより、ソフトウェアの設計要件と技術要件の間の問題が暗黙的に解消されます。

危機管理

先に進む前に、製品の各段階でリスクが分析されます。これは、潜在的なリスクを克服または軽減するのに役立ちます。

すべての従業員は、このモデルでのリスク分析の非常に重要性の恩恵を受け、おそらく他のプロセスモデルに対する最大の利点を表しています。

定期的なリスク評価は、経験値がないために一般に特定のリスクの可能性に関連付けられている新しい技術環境を使用する場合に役立ちます。

顧客の参加とフィードバック

お客様は、プロジェクトが完了するまで、プロジェクトの各段階に関与します。したがって、プロジェクトの次のバージョンを改善するために、さまざまなフィードバックを収集できます。

また、スパイラル状の前進により、いつでもフィードバックを得ることができます。したがって、顧客とユーザーを開発プロセスの最初から統合できます。

大規模なプロジェクトに最適

これは、予算管理がクライアントと開発者にとって優先事項である大規模で複雑なプロジェクトで特に人気があり、目立つものです。ソフトウェアプロジェクトのコスト、リソース、品質を最大限に制御できます。

短所

高価な

リスク分析には高度な専門知識が必要となるため、非常に費用がかかる可能性があります。さらに、プロジェクトの開発にはかなりの時間がかかるため、オーバーヘッドが増える可能性があります。

かなり複雑

プロジェクトの非常にアクティブで複雑な事前管理が必要であり、各サイクルは継続的かつ注意深く制御および文書化されます。

多くのサイクルがあり、それぞれが異なるステージを通過するため、他のモデルよりも比較的複雑であり、したがって、ドキュメント化プロセスの労力が増大します。

多くの場合利用できないリスク分析と管理の知識は不可欠です。

時間管理

サイクル数が不明であるため、時間の管理は困難です。さらに、重要な決定を1つのサイクル内で行う必要がある場合、または次のサイクルを計画するときに追加のアクションを行う必要がある場合は、開発プロセスをいつでも遅らせることができます。

多くのステップ

テストの多様性にもかかわらず、プログラムの未完成の部分が完成したシステムに到達する可能性があるため、ソフトウェア開発で多くのステップを踏むことは必ずしも好ましいことではありません。

その結果、概念的なエラーや不整合が最終製品に影響を与える危険が常にあります。

参考文献

1. ビクターフォントジュニア（2019）。スパイラルモデル。SDLCの究極のガイド。取得元：ultimatesdlc.com。
2. Ionos（2019）。スパイラルモデル：リスク主導のソフトウェア開発プロセスモデル。取得元：ionos.com。
3. Techuz（2018）。スパイラルモデルとは スパイラルソフトウェア開発ライフサイクル（SDLC）の簡単な説明。techuz.comから取得。
4. ワンストップテスト（2020）。スパイラルモデル。取得元：onestoptesting.com。
5. オタクのためのオタク（2020）。ソフトウェアエンジニアリング-スパイラルモデル。取得元：geeksforgeeks.org。
6. チャンドゥ（2019）。ソフトウェア工学におけるスパイラルモデル。取得元：medium.com。