Flow

開発の流れ 大まかな流れです。
ドキュメントをどこまで用意するかはケースバイケースになります。

・顔合わせ
・要件定義書受領(クライアント様作成)
・要件ヒアリング(コンサルティング業務になるため別途費用)
・見積もり、納期概算
・発注(契約締結)
・外部設計
 ・ユースケース(基本設計)
 ・画面設計
  ・画面一覧
  ・画面遷移図
  ・画面UIポリシー
  ・画面モックアップ
 ・データベース論理設計
 ・外部システムI/F設計(外部システムとの連携があれば)
 ・非機能要件定義
  ・システム要件
  ・レスポンスタイム
  ・セキュリティ
  ・サーバ構成
・内部設計
 ・データベース物理設計
 ・ロジック設計(詳細設計)
 ・バッチ設計
・実装
・運用環境構築(契約による)
・テスト
 ・単体テスト(機能単体、もしくはロジック単体で行うテスト)
 ・結合テスト(全ての機能の整合性を加味したテスト)
・検収(クライアント様)
・納品
・リリース
・保守(契約による)

また、外部に開発を依頼した事がないお客様向けに開発手法を説明いたします。
主に下記の2つに別れます。

詳細説明の為にwikiにリンクを追加しています。
概ねの方向性としてお考えください。
簡単に、それぞれのメリット、デメリットを説明します。

メリット
・各フェーズを分ける事でリスクを減らす
・次フェーズ以降も継続するのか都度判断できる
・完成形を意識し、設計しているので、出来上がりが見えやすい(差異が出にくい)
・コストの見通しが良い

デメリット
・一度決まった仕様を変える事が困難
・破錠した際、大惨事になる

この点を踏まえると、業務システムなどに向いています。

しかし大規模システムでは全フェーズの予算と納期を一番初めに決めてしまう事が多くあります。
理由は発注側からすればビジネスに直結するシステムなので納期と予算を明確にしたいからでしょう。
受注側も大きな利益になるため、一括で受けようとします。
ただし、設計者の業務知識が浅かったり、実装者にノウハウがない場合、
後からの膨大な仕様変更と、それでも納期は変わらないという事態に収集がつかなくなり、世に言うデスマーチと化します。
そして納期をオーバーしたり、テスト期間が短かい為、バグだらけの品質の低いシステムが出来上がります。

熟練者でも一発で成功させるのは難しい手法で、現在では反復型と合わせた手法を取る場合が多い様です。

メリット
・短期間でリリースできる
・コストが低い
・仕様変更に強い

デメリット
・意図していた仕様とズレる事がある
・トータルのコストが見えづらい

WEB系の開発は断然こちらが多いです。(コストや納期はシステムの規模にもよります)
「リリースしてからユーザーの意見を取り入れたい、まず反応を見たい、コストを抑えたい。」というのが大半です。
ですから初めから思いつく全ての機能は実装せず、段階を踏んで実装していきます。
比較的短期間で設計、実装、納品を繰り返し、費用と納期はその都度決定していきます。

なぜコストが低いのか、それはドキュメントを作成しないからです。
作って壊してを繰り返す中で、ドキュメントを保守する費用はバカにならず、予算が出ない場合が多々あります。
もちろん、本来は反復型開発、アジャイル開発でもドキュメントは必要です。
では何が仕様なのか、それは実装されている物が全てです。机の上で考えている暇があったら手を動かせ。という方針でもあります。
#予算があればドキュメントを作成する方が確実です。

これにはデメリットがあり、発注者が意図していた仕様と違う。
一定期間が過ぎた後の修正時に何が正しい仕様だったのか分からなくなる。
引継ぎ時に現状の仕様把握という名のソース調査が必要。といった事態が起こる可能性があります。

この辺りはバージョン管理システム「git」、プロジェクト管理システム「redmine」を使う事である程度緩和する事もできます。
・ソースの修正履歴から判断
・過去のチケットから判断

最近ではテストケースを用意するという方法もあります。
自動テスト化することで一定の品質を担保します。

このようなデメリットを差し引いても、短期間で反復して開発を行う為、仕様変更に強く、 一度走り出したら止まれない「ウォーターフォール開発」とは違い、都度判断できるタイミングがある「反復型開発」は主流になりつつあります。 その点で、比較的システムの寿命が短い、もしくは常に進化するWEBサービス系のシステムに向いています。



Extra

余談

コンピューターは万能ですが、中身を作っている人間は万能ではありません。というごく普通の話なのに物理的な要素が絡まないシステム開発では何でも魔法のように解決できると思われている事が多く、その戒め的な例えでよく使われます。

私が言っている物理的な要素とは、例えば家を建てるには基礎にコンクリート、骨組みに木材などそういう物です。

こちらも似たような話で、100人月の案件があり、100人用意したら1ヶ月で終わるのかと言えば、そんな訳ないのは誰でもわかるハズなのに、これまた物理的な要素が存在しない上に、安易に人を足せば解決すると思っていると大概は失敗するというお話です。
リンク先でも書かれている通りですが、人数が増えればそれだけ意志の疎通を取るのが難しくなります。それらを統括して纏める人間も必要になります。 人数が増えればエンジニアのスキルも理解度もバラバラ、プロジェクトのためだけに集められた、悪く言えば寄せ集めのチーム。これらをまとめ、高い品質のシステムが簡単にできると思いますか?想像に難しくないでしょう。