━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■第23回 ソフトウェアのプロセスモデル（後編）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
前回からの続きです。
前回はウォーターフォールモデルを紹介しました。
今回から購読されている方は、バックナンバーをご覧ください。
●スパイラルモデル
前回紹介した、ウォーターフォールモデルは後戻りができません。
しかし、後戻りができないとうことはリスクもあります。
フェーズが進んだ後で、要求分析で決定したことが実現できないなど大幅な
変更が発生したときに、そのまま進むしかなくなります。
すると、技術や納期、予算などを考慮して、妥協したシステムが出来上がる
ことがあります。
こういった問題がある程度起こりえることを受け入れてしまい、要求分析か
らテストまでの工程を何度も繰り返すのがスパイラルモデルです。
スパイラルモデルはウォーターフォールモデルの欠点を補ったモデルですの
で、品質の高いシステムを作りやすくなります。
しかし、メンバーがスパイラルモデルの本質をきちんと理解している必要が
あり、「ここで間違ってても２週目で直せばいいや」といった適当な気持ち
で作業を進めるとその強みが全く活かされません。
ウォーターフォールモデルは確かに後戻りできませんが、後戻りできないが
故に、真剣に分析しなければならなくなります。
（それでも適当な人も結構いますが．．．）
誤解している人が多いのですが、スパイラルモデルは品質を上げるために問
題を先送りするのではありません。
ちょっと考えれば分かりますが、そんな適当なやり方がモデルになるはずも
ありませんよね。
ウォーターフォールモデルと同様に真剣に開発を行い、その成果を反省して
再び要求分析から見直していくのです。
従って、２週目は最初の要求仕様が大きく変更される可能性もあるのです。
●プロトタイプモデル
プロトタイプモデルは、開発の初期段階でサンプル的なプロトタイプを作成
し、これをユーザーに評価してもらうことで、仕様のずれを無くしていく手
法です。
要求仕様どおりに作成したのに、納品後にユーザー側から「こんなものを作
れと言った覚えは無い」といった揉め事が起こることがあります。
開発者側もきちんと説明しているつもりでも、やはり実際に動いている姿を
見ないとイメージはなかなか掴めないものです。
ならば、完全版ではないものの、動作がイメージできるくらいのプロトタイ
プを見せ、ユーザーに決めてもらおうというのが目的です。
メリットとしては、やはり仕様のずれが起こりにくいことがありますが、ユ
ーザー側が使っているうちに、どんどんエスカレートした要求を出してしま
い、かえって決まらなくなってしまうこともあります。
また、プロトタイプを作成するにも時間がかかりますので、大規模システム
では向いていません。
小規模開発に適しています。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━