スパイラルモデルとは、1つのシステムを機能ごとに分割して開発を繰り返す手法のことです。
さらにシンプルに言えば、「大きなシステムは作るの大変だから、何回かに分けて開発していこうね」というもの。
図にするとこんな感じです。
※図で要件定義を書き忘れたけど作り直すの面倒なので、許してください(*´ω｀)。
例えば、「受発注システム」という大きなシステムがあったとします。
※何を「受発注」するのかは、ご想像にお任せするとして。ついでに言うと、架空のシステムです。
「受発注システム」というシステムで、やりたいことをお客様に聞いたら、3つありました。
- 伝票登録をする機能
- 精算書・請求書を発行する機能
- 在庫も管理する機能
やりたいことが盛りだくさん。大変です。
そこで、伝票登録の機能で1つの開発。精算・請求の機能でさらに1回。在庫管理の機能で最後の1回。
要件定義⇒設計（基本設計・詳細設計）⇒プログラミング⇒テスト（単体・結合・総合）
を合計で3回、繰り返してシステムを完成させる。
これをそれっぽく言うと、「機能ごとに分割して開発を繰り返す手法」です。
スパイラルモデルは、機能ごとに分割して開発を繰り返す手法
スパイラルモデルは、機能ごとに分割して開発を繰り返す手法のことです。
1つのシステムを分割して開発するので、よく「一次開発」・「二次開発」みたいに言ったりします。
1つずつ開発していって、OKが出たら次に進む
例えば、冒頭の受発注システムの例。
まずは、一次開発として、受発注システムの根幹になりそうな「伝票登録システム」に着手。
※「伝票登録システム」は、「受発注システム」という大きな枠にぶらさがるので、「サブシステム」みたいに言ったりしますが、ついでにおぼえたってください(-_-;)。
英語のサブ(sub)は、「下位の、下流の」の意味！
「伝票登録システム」で、具体的にやりたいことを検討して、プログラミング。
完成して、お客様に見せてOKが出たら、次の開発の「請求・精算システム」に着手します。
「請求・精算システム」でもOKが出たら、さらにその次の「在庫管理システム」に着手。
何回かに分けたサブシステムを全部作り終わったら、晴れて「受発注システム」の完成となります。
それぞれの開発はウォーターフォールモデルで行われる
それぞれの開発（サブシステムの開発）は、ウォーターフォールモデルで行われます。
- 「受発注システム」の伝票登録の部分を開発
- 終わったら、精算・請求の部分を開発
- 終わったら、在庫管理の部分を開発
機能ごとに分割して、開発を繰り返していくイメージです。
スパイラルモデルのメリットは、他の開発手法のいいとこ取りをしてる？
よく、「スパイラルモデルは、ウォーターフォールモデルとプロトタイピングモデルを合わせたハイブリッド型」みたいに、それぞれの開発手法のいいとこ取りをしている的な説明を見ます。
・・・が、ひよこSE的にはかなり微妙と言うか、しっくりこない(*´ω｀)。
スパイラルモデルは、ウォーターフォールモデルの延長線上
スパイラルモデルは、機能ごとに分けた開発を１つずつウォーターフォールモデルで進めていくもの。
今回の例に挙げている「受発注システム」のように、大きな機能が３つあるけど、まとめて開発するのが大変だから機能ごとに分けて開発。
ウォーターフォールモデルの延長線上だとおもってください。
キリのいいところでお客様と認識のズレがないかを確認できる
何回かに分けた開発のキリがついたところ（言い換えると、サブシステムの開発が終わったところ）で、お客様の意見を聞いて、認識のズレがないかを確認できます。
それを、残りの開発に活かせるという点で、プロトタイピングモデルのメリットを活用できています。
説明に違和感が残るけどまぁ、いいやってところ
「スパイラルモデルは、ウォーターフォールモデルとプロトタイピングモデルのいいとこ取りをしている」といえば、確かにそうなのですが。
それぞれの開発で、できあがるものが「試作品か？」といわれれば、「いやいや、完成品だよ！」っていいたくなるので、「プロトタイピングモデルか？」と言われれば微妙なところ。
キリのいいところで確認して、細かい改善や意見の反映をして次のサブシステムの開発に活かせるから、間違いではないです。
単純に、「1度にまとめて全部作るのは大変だから、何回かに分けたよ。それぞれは、ウォーターフォールモデルでやる」っていってくれたほうが納得感があります。ひよこSE的には(*´ω｀)。
大事なのは、「開発工程を繰り返すこと」です。
基本情報でも、「開発工程(要件定義～テスト)を繰り返す」がキーワード！
まとめ
スパイラルモデルときたら、1つのシステムを機能ごとに分割して開発を繰り返す手法のこと。
機能ごとにウォーターフォールモデルで開発して、終わったらお客様に「これでいいですか？」と確認するのを繰り返して。
「すべての機能を合体させて、1システムを完成させる開発手法なんだなぁ～」と思ってくださいまし(-_-;)。
コメント