スパイラルモデル

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
スパイラルモデル(Boehm、1988)。多くの誤解は、この広く流通している図の過度の単純化に起因しています(この図にはいくつかの誤りがあります)。[1]

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

歴史

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

これらの初期の論文では、「プロセスモデル」という用語を使用して、スパイラルモデルだけでなく、インクリメンタル、ウォーターフォール、プロトタイピング、およびその他のアプローチを指します。ただし、他のプロセスモデルの機能のスパイラルモデルの特徴的なリスク主導のブレンドはすでに存在します。

スパイラルモデルステップの[R]リスク駆動型サブセット化により、モデルは、仕様指向、プロトタイプ指向、シミュレーション指向、自動変換指向、またはソフトウェア開発への他のアプローチの適切な組み合わせに対応できます。[3]

後の出版物で[1]ベームは、スパイラルモデルを「プロセスモデルジェネレーター」として説明しています。この場合、プロジェクトのリスクに基づいて選択すると、プロジェクトに適切なプロセスモデルが生成されます。したがって、インクリメンタル、ウォーターフォール、プロトタイピング、およびその他のプロセスモデルは、特定のプロジェクトのリスクパターンに適合するスパイラルモデルの特殊なケースです。

ベームはまた、元のスパイラルモデル図の過度の単純化から生じる多くの誤解を特定しています。彼は、これらの誤解の中で最も危険なものは次のとおりだと言います。

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

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

National Research Councilのレポート[4]では、このモデルが拡張され、人間のユーザーに関連するリスクが含まれるようになりました。

それらを「危険なスパイラルそっくりさん」とよりよく区別するために、ベームはスパイラルモデルのすべての本物のアプリケーションに共通する6つの特徴をリストしています。[要出典]

スパイラルモデルの6つの不変量

スパイラルモデルの本物のアプリケーションは、常に6つの特性を示すサイクルによって駆動されます。ベームは、不変量に違反する「危険なスパイラルそっくり」の例でそれぞれを示しています。[1]

アーティファクトを同時に定義する

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

この不変条件は、ウォーターフォールモデルの基礎となる仮定が適用されない設定で一連のインクリメンタルウォーターフォールパスを使用する「危険なスパイラルそっくり」プロセスを除外します。ベームは、これらの仮定を次のようにリストしています。

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

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

すべてのサイクルで4つの基本的なアクティビティを実行します

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

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

これらの活動のいずれかを省略または短縮するプロジェクトサイクルは、主要な利害関係者に受け入れられない、またはリスクが高すぎるオプションを追求することにより、労力を浪費するリスクがあります。

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

リスクが努力のレベルを決定する

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

たとえば、ソフトウェア製品のテストに追加の時間を投資すると、市場が粗雑な製品を拒否することによるリスクが軽減されることがよくあります。ただし、追加のテスト時間は、競合他社の早期の市場参入のためにリスクを高める可能性があります。スパイラルモデルの観点からは、全体的なリスクが最小化されるまでテストを実行する必要があります。[要出典]

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

リスクが詳細度を決定する

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

要件仕様を例として考えると、プロジェクトでは、正確な仕様によってリスクが軽減される機能を正確に指定する必要があります(たとえば、ハードウェアとソフトウェア間のインターフェース、プライムと下請け業者間のインターフェース)。逆に、プロジェクトでは、正確な指定によってリスクが高まる機能(たとえば、グラフィカルな画面レイアウト、既製のコンポーネントの動作)を正確に指定するべきではありません。

アンカーポイントマイルストーンを使用する

スパイラルモデルに関するベームの元の説明には、プロセスのマイルストーンは含まれていませんでした。後の改良で、彼は進行状況インジケーターとコミットメントのポイントとして機能する3つのアンカーポイントマイルストーンを紹介します。これらのアンカーポイントのマイルストーンは、重要な質問によって特徴付けることができます。

  1. ライフサイクルの目標。全員の勝利条件を満たすための技術的および管理的アプローチの十分な定義はありますか?利害関係者が答えが「はい」であることに同意した場合、プロジェクトはこのLCOマイルストーンをクリアしました。それ以外の場合は、プロジェクトを中止するか、利害関係者が別のサイクルにコミットして「はい」に到達しようとする可能性があります。
  2. ライフサイクルアーキテクチャ。すべての人の勝利条件を満たすための好ましいアプローチの十分な定義があり、すべての重大なリスクが排除または軽減されていますか?利害関係者が答えが「はい」であることに同意した場合、プロジェクトはこのLCAマイルストーンをクリアしました。それ以外の場合は、プロジェクトを中止するか、利害関係者が別のサイクルにコミットして「はい」に到達しようとする可能性があります。
  3. 初期作戦能力。システムを起動することで、すべての人の勝利条件を満たすためのソフトウェア、サイト、ユーザー、オペレーター、およびメンテナーの十分な準備がありますか?利害関係者が答えが「はい」であることに同意した場合、プロジェクトはIOCマイルストーンをクリアし、開始されます。それ以外の場合は、プロジェクトを中止するか、利害関係者が別のサイクルにコミットして「はい」に到達しようとする可能性があります。

この不変条件に違反する「危険なスパイラルそっくりさん」には、不十分に定義されたアーキテクチャを使用したソリューションの実装に多大なリソースを投入する進化的および段階的なプロセスが含まれます。[説明が必要]

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

システムとそのライフサイクルに焦点を当てる

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

参考文献

  1. ^ a b c ベーム、B(2000年7月)。「スパイラル開発:経験、原則、および改良」 (PDF)特別レポートソフトウェア工学研究所。CMU / SEI-2000-SR-008。
  2. ^ ベーム、B(1986年8月)。「ソフトウェア開発と拡張のスパイラルモデル」。ACMSIGSOFTソフトウェアエンジニアリングノート11(4):14–24。土井10.1145 /12944.12948S2CID207165409_ 
  3. ^ a b ベーム、B(1988年5月)。「ソフトウェア開発と拡張のスパイラルモデル」(PDF)IEEEコンピュータ21(5):61–72。土井10.1109 /2.59S2CID1781829_  
  4. ^ ピュー、RW; Mavor、AS、eds。(2007)。システム開発プロセスにおける人間とシステムの統合:新しい外観ワシントンDC:ナショナルアカデミープレス。ISBN 978-0-309-10720-4