通勤中にぽちぽちとまとめた結果をアップしておきます。
・要素を抜き出しているだけなので、別途つながりを検討する必要があり。
・一般的なウォーターフォール開発の流れで。
→ ただし、顧客の要望を取り込めるように、顧客からのフィードバックを用意する。
→ アジャイル開発の場合は別途作成する（予定…予定は未定）
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 | >> 要件定義 >> 顧客要望まとめ >> 業務分析 >> 機能要件 >> 性能要件 >> 顧客スケジュール >> システム概要設計 >> 見積もり >> 全体スケジュール >> 期間見積 >> 配員計画 >> 金額見積>> 見積提出 >> 交渉>> プロジェクト計画>> 設計工程 >> システム設計 >> オブジェクト指向設計 >> データ構造設計 >> ネットワーク構造設計 >> ユーザーインターフェース設計 >> 画面設計 >> 顧客レビュー>> 実装工程 >> 詳細設計、内部設計 >> 実装 >> 単体試験 >> 結合試験>> 試験工程 >> 試験計画 >> 不具合票の取り回し >> システム試験 >> 機能試験 >> 性能試験 >> 負荷試験 >> ユーザー試験 >> 実装へフィードバック >> 運用試験>> システム導入 >> 導入計画 >> 導入作業 >> 導入試験 >> 運用マニュアル >> 試験運用>> 運用 >> 初期サポート >> 初期障害対処 >> 運用研修/教育>> 保守 >> 限界値チェック >> ナレッジベースへの蓄積 >> 変更要望 >> 障害対処 |
PMBOK の用語に合わせようと思ったけど、PMBOK の場合、実装(programing)が薄すぎるのでやめました。詳細設計から結合試験までを【実装工程】としました。全体のバランスのためです。
パレードの法則から言えば、より金額の掛かっているところ（あるいはリスクの高いところ）にプロジェクトの投資を注力するべきで、その他は現状の流れに任せてもよい、という考えです。お金もスタッフも限りがありますからね。ビジネス的に対費用効果を考える、ということです。
