スパイラル開発について調べてみたので、ここにメモします。
スパイラル開発
スパイラル開発は、アジャイル開発と同じ反復型の開発手法で、画面や機能単位でユーザーに触れてもらいながら開発・改良を進めていく開発スタイルです。
対象のシステムを機能ごとに分割して、重要な機能から構築している開発手法です。開発チームや案件により異なりますが、開発工程で機能ごとに、『要件定義』→『設計』→『開発』→『テスト』→『レビュー』を複数回繰り返し、改善しながら完成を目指していきます。
スパイラル開発という名前は、工程を繰り返す形が螺旋状に見えることから名付けられたようです。
アジャイル開発との違い
ユーザーがプロジェクトの途中でソフトウェアに触れる際の品質を担保しないのがスパイラル開発の特徴となります。
プロジェクトのスケジュールを予め決めておき、一定の間隔でユーザーに品質を保証しない状態のソフトウェアに触れてもらい、フィードバックを得ることが可能です。
メリット
ウォーターフォール開発とアジャイル開発の良いところが取り入れられている点です。
- 全体のスケジュールを明確化し、スケジュール管理に重点を置ける
- 品質を担保せずユーザーが直接ソフトウェアに触れてもらうことで、認識のズレが確認可能
これにより、大きな出戻りを防ぐことを期待しているようです。
デメリット
スパイラル開発では、仕様やスケジュール変更に対応しやすいというメリットがありますが、全体像を把握しづらいという側面があります。
- プロジェクトの全体像が見えにくい
- 開発コストが肥大化するケースがある
その都度改善が行えるため、出戻りを防ぐ意味では効果的ですが、コストが大きく膨らんでしまうことが問題となることが多いみたいです。
これは、ユーザの要望を最大限に考慮した上で、スケジュール調整も含めた交渉力が必要となるようで色々大変そうです。
また、全体像を把握できないままの状態で計画変更が続くと、本来プロジェクトが目指している方向性からずれてしまうことが懸念されます。
流れ
開発の流れは、『要件定義』→『設計』→『開発』→『テスト』→『レビュー』を繰り返します。
要件定義
『要件定義』は開発するシステムの目的から、必要な機能を洗い出し、それらを仕様書にまとめます。
設計(基本設計)
『設計』は要件定義で決定された事項と調査結果に基づき、システムに実装する機能を選び、設計要件を明確化・具体化して設計仕様書を作成します。スパイラル開発では、基本設計の段階ですべての機能を設計せずに、優先度が高い機能のみで大枠を作成することがポイントです。機能や構成の基本的な仕様を策定する工程のため、発注者にもわかりやすいように、開発会社がシステムのアウトラインを決めます。このリリース前に作成するソフトは「プロトタイプ」と呼ばれるもので、試作品のことです。
設計(詳細設計)
基本設計のあとに行う詳細設計では、実際に手を動かすプログラマへ向けて「どのように機能を実装するのか」細部までを設計する工程です。詳細設計書を見ただけでプログラマがスムーズにプログラムを組めるように粒度で設計します。
開発
『開発』は、作成した設計をもとに、プログラムを作ります。
テスト
『テスト』は、機能を実装したあとに不具合がないか、問題なく動作するかをチェックし、不具合や問題点があれば修正します。
レビュー
『レビュー』は、作成したものを評価します。このフェーズはクライアントにも共有し、フィードバックを受けます。
プロトタイプは、サブシステムごとに作成し、「開発イメージとズレがないか」「使いにくい内容がないか」などの評価・レビューを受けます。認識のズレやエラーなどがあれば改善し、次のサブシステムに移ります。レビューで受けた要望を反映して、同じようにスパイラル開発を進め、プロトタイプを作成し、評価を受けるという流れです。
