開発の流れ

Water fall model(ウォータフォール)

中規模～大規模開発で古くから用いられている手法です。「業務分析、要件定義」から始め「基本設計」「詳細設計」「実装」「テスト」「納品」と進めていきます。

メリット

• 要件定義と基本設計をしっかりやってから取り組むので予算を確保しやすい。
• 定型業務など仕様が明確な場合は開発作業に無駄が発生しない。

デメリット

• 設計フェーズに時間がかかる。
• 一旦決めた予算内での仕様変更はできない。仕様変更の場合は再見積となる。
• 完成後のバグを除く追加仕様や修正は基本的にできない。別料金。
• 要件定義書、基本設計書、詳細設計書、テスト計画書、テスト仕様書、ユーザー操作マニュアル等ドキュメントの管理が大変。
• 対外的なサービスを提供するシステムの場合、納品までの間に市場のニーズが変化してしまい。納品時期には使えないものになるリスクがある。

Agile model(アジャイル)

実現する機能を小さくわけて、本当に必要であろう機能のみを開発・テスト・リリースする。「実装～テスト～修正再実装」を繰り返しシステム要求の本質を体現していく手法。スタートアップの企業様ではこの手法で開発する事が多いです。

大まかな仕様（完成イメージ）はあるが、詳細まで決める事ができない。かつ、サービスをいち早く形にしてリリースしたい場合に有効。

メリット

• 最小機能単位の実装とテスト、修正を繰り返すため、機能要件の曖昧さを排除できる。
• 仕様が不明確な場合でもユーザーテストでシステム要求がより鮮明になる。
• その結果として「バグ」の早期発見にもつながり、品質向上が見込まれる。
• 最小単位での機能リリースが可能になり、市場のニーズをいち早く捕捉できる。

デメリット

• 発注者（利用者）がテストに参加するため、発注者のリテラシーがある程度高くなければならない。また、発注者のテスト負担が増える。
• リリース後も改善を繰り返すため開発する「対象システムのゴール」を明確にしないと終わりのない開発になる。
• 準委任契約での開発とする場合も多く、発注側の予算やスケジュールに余裕がないと途中終了となるケースもある。

Mixed model(上記の折衷型)

上記の折衷型で基本的にはウォータフォール的な全工程スケジュールと仕様を決めて数回の途中段階での内部レビューと検証を繰り返しながら完成品に近づけていく手法。

マーシャルアートではコスト見合いで主にこの手法を使う場合が多いです。