仕様変更の管理

ソフトウェア開発において、
使用変更がゼロであるケースはまず無い。

かならず発生するものとして、準備はした方が良い。
ただし仕様が変わるということは、実装が変わるということであり、
あらかじめ手順を決めなければいけない。

口頭ベースで仕様変更を受け入れてしまえば、
他の箇所との整合性確認が非常に難しくなってしまう。
だからこそ、管理（コントロール）は必要だ。

計画変更の要因

プロジェクト計画が変更される要因は、大きく分けて２つある。

１つは外的要因。
１つは内的要因。

問題は要因ではなく、どのフェーズでの仕様変更か、ということである。

下流工程作業中に仕様変更があった場合、また上流工程から変更する必要があり、
作業量が増大するだけでなく、時間の消費、モチベーションの低下など
ろくなことが無い。

上流から下流に向けて、作業量が多くなるソフトウェア開発らしい。

変更管理とは何ぞや？

プロジェクトとは、様々な前提条件や制約条件の中で運営されるもの。
当初の計画通りに進行せず、計画変更を余儀なくされることも。

その変更に対して、どんな対処をするのか計画し、実行することこそ変更管理と言う。


変更管理するためには、仕様変更手順や仕様変更責任者などの管理体制は、
とうぜん計画しなければいけない。

それだけでなく、成果物の構成管理が絶対に必要になる。

プロジェクトの終結と評価

成果物をスポンサーに引き渡せば、プロジェクトは
終結となり、解散する。

同時に、プロジェクト完了報告書を作成する。
プロジェクトに関する実績記録、
最終的な成果物の一覧、
教訓などが記載される。

これはプロジェクト全体で１つ作成される。


中でも重要なのは、教訓である。
このプロジェクトを通じて、何を得たかが書かれている。

それは将来に実施されるプロジェクトにとって
有益な情報でなければいけない。

同じ失敗を繰り返さないために。

だからこそ、教訓は重要なのだ。

プロジェクトの計画概要

品質計画。
定性的品質目標と定量的品質目標の両方を設定する。
ソフトウェアの欠陥除去に関する計画を策定する。

進捗計画。
作業項目の順序を設定し、作業量も勘案して、
全体のスケジュールを作成する。

費用計画。
人件費を作業量から算定し、
ハードウェアに関する費用を合計して予算を作成する。

組織要員計画。
作業量・技術水準から必要員数・チーム編成を決定する。
開発環境整備のような支援する要員を含めて検討する。

契約管理計画。
顧客との契約、協力会社との契約の進め方を計画する。

生産性計画。
作業量の投入に対する成果物の割合の算定式を決定する。
成果物の完成に必要な工数の見積もり方式を決定する。
見積もり工数を算定する。

変更管理計画。
計画変更の要因と、対処方法・手順を決定する。