オブジェクト指向開発

システム開発
要求フェーズ
基本計画	現状の問題点を調査・分析し，解決策を検討
	機能や性能など，システムに対するユーザ要求を定義
	費用や実現可能性を分析し，システム化計画を立案
分析フェーズ
外部設計	ユーザ側の立場で，システムの機能や性能などを決定
	システムをサブシステムに分割
	画面，帳票，コード，論理データなどを設計
設計フェーズ
内部設計	コンピュータの処理に適した設計
	まとまった機能ごとにサブシステムをプログラムに分割
	機能分割・構造化，物理データ設計，入出力詳細設計
プログラム設計	プログラムの構造設計
	まとまった機能ごとにプログラムをモジュール分割
	テストケースの設定
実装とテスト
プログラミング	モジュールの処理手順の設計
	コーディングの実行
	単体テスト計画の立案および実施
テスト	結合テストの実施
	システムテストの実施
	本番と同じシステム環境やデータで，運用テストの実施
保守・運用	ユーザへの引渡し
	システムの不具合の修理
	機能改良や機能追加

ソフトウェアを開発する時に一番最初にしなければならないことは，何を作りたいのかをはっきりさせることである．これを「要求分析」と言う．

これは当たり前のように思えるが，多くの場合，これをしっかり考えずに「まず出来る所から手をつけよう」とプログラミングを始めてしまい，要求ではなく実現レベルで物を考えがちである．

「要求」と「実現方法」をはっきり分けて考えないと，もっと効率的で良い実現方法を考えようという気がなくなってしまい，以前のやり方の悪い点までわざわざ手をかけて真似することになってしまう．これでは時間も無駄になるし開発者の士気にも影響する．だから「要求」をきちんと考えそれについて最良の「実現方法」を考えるようにする．多くの場合，最良の実現方法が一番プログラムが楽に作れる．それは要求を一番素直に実現する方法だからである．ソフトの世界では「単純であることが最良の方法」なのだ．だから最良の実現方法を考えるための土台として「何が要求されているのか」をまず考える必要がある．

要求分析では，システムに何ができなくてはいけないのかをすべて明確にする．要求分析の結果は「要求仕様書」という文書である．この文書では，これから作るソフトにどんな機能があってどんな性能を発揮しなければいけないかを記述する．この文書は開発側と依頼側の双方によって作られ一種の契約書の役割をする．

どういったソフトウェアを作れば要求を満たせるのかを考えるのが仕様分析のステージである．仕様分析のステージのアウトプットは仕様書である．

仕様書とは「何をすればいいのか」を規定するもので，「それをどのように解決するのか」はここでは問題としない．まずは解決すべき問題をはっきりさせるのが目的である．

仕様分析フェーズでは，最終的にソフトウェアの仕様ができる．仕様というのは，ソフトを起動するとどんな画面が出てどこのボタンを押すとどういう動作をして……という，ソフトウェアの動作を規定したものである．この仕様通りに作りさえすれば，誰に作らせても同じ物ができてくるはずのものである．

仕様分析を甘く見てはいけない．これは大ざっぱに言って全工程の3割を費す非常に手間のかかる工程である．そしてその成果物は残念ながら単なる書類である．だから多くの場合これを飛ばしてすぐプログラミングにかかってしまいがちである．少しでもプログラムが動いた方がうれしいし見栄えがするからである．しかしその誘惑に負けてはいけない．

仕様が決まってしまえば，あとはソフトを作るだけである．そのためにまずは「構造設計」を始める．構造設計ではソフトをどう分割して，それぞれにどういう機能を持たせたらよいかを設計する．ソフトウェアをいくつかの部品に分割し，さらにそれを分割し……というように再帰的に全体を部分に分割していく．それが終わったら次は詳細設計である．それぞれの部品について実現方法を考える．

構造設計は，自動車の設計に例えるとエンジンやブレーキといった部品を組合せて車体を設計する事にあたるす．そしてエンジンそのものを開発するのが詳細設計である．これらの成果は最終的には「設計仕様書」となる．