開発モデルについて，調べる機会があったのでメモしておく．
調査記録なので，間違い等が含まれる可能性がある．

はじめに

開発プロセスとは

開発の企画からリリース，運用・保守までの作業段階．以下のように分けられる．

1. 要件定義
   • 機能やパフォーマンス等の条件の明確化
2. 基本設計(外部設計)
   • UIや入出力等
3. 詳細設計(内部設計)
   • 具体的な機能の設計
4. 実装
5. 単体テスト
6. 結合テスト
7. 総合テスト
8. 導入・運用

開発モデルとは

開発プロセスを実施する順番・形式をモデル化したもの．

1. ウォーターフォールモデル

最も基本的な開発モデル．前のプロセスの成果物を基に次のプロセスの作業を行う．

• 主流．ドキュメントの作成量が多い．
• 大規模システム開発に有効とされる

メリット

• 計画を立て易い
  • 各開発プロセスの区切りが明確で，流れを把握しやすい
• 進捗管理がし易い

デメリット

• 上流工程でしか要件定義をしない
• 仕様変更の影響が強い
  • 手戻りの発生
• 成果物管理の稼働不可
  • 成果物の作成が重みになる

2. プロトタイピングモデル

• 比較的小規模な開発向け．
• プロトタイプをユーザに提示し，システムの機能を確認してもらう
  • 評価と改善を繰り替えし，要件に見合った製品を作り上げる

メリット

• 設計段階でユーザの意見が取り入れられるため，手戻りが少なくなる

デメリット

• プロトタイプ作りから始めるため，手間と費用がかかる

3. 繰り返し型開発モデル

ウォーターフォールにおける，手戻りの大きいデメリットを改善するために考えられた．

3.1 スパイラルモデル

ソフトウェア全体を，独立性の高いサブシステムに分割する

• 要件定義⇒設計⇒プログラミング⇒テスト の流れを繰り返す
• 開発のリスクが最小となるように改良しながらシステムを育てる
  1. リスク分析・代替手段評価
  2. 開発と検証
  3. 次のフェーズの計画
  4. 目標の設定・代替手段検討

メリット

• リスクの現象が計れる
• 大きな手戻りが発生しにくい
  • ユーザとの認識の違い，設計・要件定義のミスを早期発見可能
• 仕様変更に対応しやすい

デメリット

• システムの分割方法によっては運用しにくい
• ユーザに仕様変更の余地を与えてしまう
• プロジェクト全体の管理が困難
  • 終了時期の見極めが難しい

3.2 インクリメンタルモデル(漸増型)

要求を一度に全て実現するのではなく，開発単位毎に新規の増分を追加していく．
スパイラルモデルとは，繰り返しの範囲が異なる．
スパイラルモデルは 要求定義〜テスト工程 を繰り返すが，インクリメンタルモデルは要求定義は最初の1回だけ行い，それ以後の 設計〜テスト工程 のみを繰り返す．

• 最初にシステム全体の要求定義を行う
  • ソフトウェアを独立性の高い機能に分割する
• 機能ごとに並行して開発を行う
  • 各機能について段階的にリリースする

メリット

• 機能毎のソフトウェア構造がまったく異なるもの，依存関係のないものに適している
  • 繰り返しの単位の独立性が保てる
• 機能毎に開発する
  • 全ての機能が揃っていなくても，最初のリリースからシステムの動作を確認できる

デメリット

• 開発単位間に共通した構造が存在した場合，二重に開発を行ってしまう
  • 保守性に問題が生じる
• 細部まで作り込んでしまうと，修正が大変

3.3 イテレーションモデル(反復型)

何度も薄く色を塗ることで，最終的にしっかりとした色へもっていくイメージ．
スパイラルモデルとの違いは，分割の仕方．
スパイラルモデルは 設計〜テスト工程 を繰り返すが，イテレーションモデルは 機能追加 の工程を繰り返し，各機能の完成度を高めていく．

• ソフトウェアの全体，あるいは部分について，最初は薄く作り，少しずつ肉付けしていく
  • システムの要素をとりあえず完成させ，段階的に要素を開発・追加してく
• OS の開発に向いている
  • どんなモジュールからも呼び出すカーネル(プロセス管理等)を先に開発する
  • カーネルのモジュールを利用しながらシェルを追加して行く

エヴォリューショナルモデルと同義(たぶん…)．

メリット

• 徐々に確認しながら肉付けし，中身を濃くしていける
  • 非常に重要かつ複雑なソフトウェアの箇所に対して有効

デメリット

• ユーザーの要求が発散してしまい，ソフトウェアがいつまでたっても完成しないリスクがある

UP(Unified Process)

開発モデルというわけじゃないけど，このタイミングで書いておく．
UP は有名な反復型プロセス(イテレーション + インクリメンタル)フレームワーク．
実際の現場では，インクリメンタルモデル，イテレーションモデルをミックスした戦略がよくとられる．

• 機能単位の開発：インクリメンタル戦略
• コアアーキテクチャの開発：イテレーション戦略

最終目標

品質の高いソフトウェアを開発するためのガイドラインを提供する

思想

• ユーザーの求める真の要求を満足させる
• 要求や環境の変化に対応できる
• ソフトウエア開発のリスクを減少させる
• 再利用可能なコンポーネントベースのシステムを実現する

アプローチ

• ユースケース駆動
  • ユースケースを出発点として開発する
  • 反復の度に1つ以上のユースケースを実装していく
• アーキテクチャセントリック
  • アーキテクチャ中心で開発する
  • 開発早期でアーキテクチャを確立する
  • 開発者視点ではなく，ユーザ視点(ユースケース)から考える
    • 開発者視点の関連モジュールではなく，ユースケースを実現するモジュール群を優先して開発する
• 反復型開発
  • 要求，成果物，人，リスク等を管理しつつ，マイルストーンを設定した計画のもとで反復開発を行う

フェーズ

1. インセプション(方向づけ)フェーズ
   • アイデアのプロトタイプの開発と評価
   • 開発を進めるべきか，止めるべきかを判断する
2. エラボレーション(推敲)フェーズ
   • システム構築のための核となるアーキテクチャベースラインを作る
   • 骨組みと黄金ルート(必ず通る基本のルート)を作る
3. コンストラクション(作成)フェーズ
   • システムとして仕上げる
   • β版のリリースが目標
4. トランジション(移行)フェーズ
   • β版のリリース
   • フィールドでの評価結果の反映.

3.4 アジャイルプロセスモデル

• 重厚長大な開発手法(UP)に対するアンチテーゼ
  • 小さいシステムはもっと簡単に作っても良い
• 状況に対して柔軟かつ迅速に対応する
• イテレーションを区切り，必須度の高い機能から定義・開発して行く

メリット

• 最低限だが使用可能なソフトを早期リリース可能
• 優先度の低い開発を後続のイテレーションに後回しに出来る

デメリット

• 大規模システムに向かない
• 場当たり的なシステムになってしまう可能性がある
• 習熟した技術者によってのみ成し遂げられる

参考文献

開発手法の基礎、ウォーターフォールモデルの特徴とは
第12回　システム開発の工程とソフトウェア開発モデル | めざせ!情報処理技術者試験
【問題5】ソフトウェア開発モデルについて
第10回 開発プロセスの上手な組み合わせ
インクリメンタル開発とイテレーション開発
Part1　Unified Process，その生い立ちと構造を知る
第5講 オブジェクト指向開発とは何か
Part1 Unified Process，その生い立ちと構造を知る
第１回 RUPはどこに消えたのか？
テーマ０１：ソフトウェア開発モデル
What's the difference between incremental software process model, evolutionary model, and the spiral model?
1.ソフトウェア開発手法 - it-shikaku.jp