予め予定した望ましい幅の中に諸活動を調整すること
- PDCA ( Plan Do Check Act )
Plan ( 計画 )、Do ( 実行 )、Chack ( 評価 )、Act ( 改善 ) の4つの管理サイクルを廻すことにより遂行される管理活動 - PDCAサイクルのうち、A(Act)で実施すること
資源の活用に関する改善目標の設定やプロセスの改善などを行う
- 品質計画
- 品質保証
プロジェクトで定めた品質基準を確実に満たすための、計画的かつ体系的な活動を行う - 品質管理
- QCD
- Quality ( 品質 )
- Cost ( 価格 )
- Delivery ( 納期 )
- QCDはトレード・オフの関係にある
- 品質の考え方
- 品質の作り込み
品質は、検査工程でエラーを発見することで作るものではなく、製造工程で作りこんでいくものだとする考え方 - 当たり前品質
開発されるソフトウェアが本来持つべき最低限の品質
不十分であるとユーザに不満足感を与える - 魅力的品質
開発されるソフトウェアが当たり前品質を超えて具備する、操作性など、付加価値的な品質 - 設計品質
外部設計、内部設計を通じて作りこまれるソフトウェア品質
設計仕様がユーザの要求に整合していることを指す - プログラム品質
プログラミングを通じて作りこまれるソフトウェア品質
プログラムが設計仕様通りに正しく動作することを指す
- 品質の作り込み
- デザインレビュー
計画・分析・設計などの各フェーズを振り返り、その成果物を吟味すること - 不良摘出目標数
レビューやテストを実施する前に、作りこまれた不良を予見し、発見すべき目標数 - 成果物に不具合があったとき、その修正内容が仕様どおりであることを確認する
- ソフトウェア品質の管理指標
成果物ごとのレビュー時間
- QCD
- 品質目標
- 定性的目標と定量的目標の両方を設定する
- 工程別定量的品質目標
- 計画・分析・設計
- 作成した設計書の枚数
- 実施したレビュー時間
- 発見エラー数
- 実施したレビュー時間÷作成した設計書の枚数
- 発見エラー数÷作成した設計書の枚数
- プログラミング
- コメントの行数合計
- 共通ルーチンのステップ数÷全ステップ数
- テスト
- プログラムステップ数
- 実施テスト項目数
- 発見バグ数
- 実施テスト項目数÷プログラムステップ数
- 発見バグ数÷プログラムステップ数
- 全工程
- 仕様変更数
- 計画・分析・設計
- 品質実績データの把握
- 記録項目
- レビュー
レビュー対象成果物、実施日、出席者、実施時間、エラー発見実績数、レビューした成果物の枚数 - テスト
テスト対象機能もしくはプログラム、テスト実施者、テスト項目およびその数、使用したテストデータ、バグ発見実績数、テストしたプログラム行数
- レビュー
- エラー記録票 ( バグ記録票 )
発見したエラー、バグを1件1枚で記録する - エラー一覧表 ( バグ一覧表 )
エラー、バグの解決状況を管理するために、エラー記録票(バグ記録票)をまとめたもの - レビュー(テスト)工程品質管理図
- レビュー(テスト)の進行状況と品質状況を把握する
- レビューの項目消化予定・実績はレビュー項目の残数を縦軸、レビュー日数を横軸にとった通常右下がりの曲線となる
- エラー発見予定・実績は累計エラー発見件数を縦軸、レビュー日数を横軸にとった通常右上がりの曲線となる
- 未解決エラー件数
- 発見されたが解決されていないエラー数
- 一定の数を超えていないことを確認する
- 管理図の例
- 記録項目
- 品質評価
- 差異分析
- 予定と実績を比較し、その際が大きい場合は原因を分析し、品質の評価を行う
- 定量的品質目標だけでなく定性的目標に付いても評価する
- 差異分析
- 品質改善
- 品質評価をした結果、品質不良と認められる設計書もしくはプログラムに対して品質改善を実施する
- 原因と改善策の例
- 開発要員のスキル不足
- 開発要員に教育研修を実施する
- 開発要員を交代させる
- チーム編成を変える
- 開発標準を遵守していない
- 開発標準の遵守を徹底する
- 開発標準を追加・変更する
- 仕様変更が多い
- 仕様変更を一時的に凍結する
- 仕様変更を実施する時期を後にずらす
- 設計仕様に曖昧さが多い
- 前工程に戻って再設計・再定義をしなおす
- 前工程のレビューを再実施する
- プロトタイプを作成し、仕様を早期に確定する
- 前工程のバグを引きずっている
- 前工程のテストを再実施、もしくは追加実施する
- 未経験の新技術部分にバグが集中している
- 新技術部分を切り離し、問題解決をする特別チームを編成する
- 開発要員のスキル不足
- リスクに対しては発生の予防と、発生による被害を最小限にする対策を行う
- 目的
- 納期・コスト・品質の3つをバランスよく保ち、適度な水準に安定させる
- プロジェクトの進行状況をステークホルダに示すことで安心感やより多くの支援を受ける
- 進捗実績の把握
- 進捗実績はプロジェクト運営時に常時把握しなければならない
- 進捗実績報告の重要性をメンバに認識させる
- 進捗計画で定めた進捗実績把握の方法に従って実績データを収集する
- 実績データと成果物を照合して実績データの正確さを検証する
- 総合テストの開始までに発注先から成果物が納品されることを確認する
- マイルストーンで予定通りに成果物が作成されたことを確認する
- 進捗実績の評価
- 差異分析
予定と実績の差を吟味し、その原因を究明すること - 予定と実績の差異を分析し、状況の判断を行う
- プロジェクトマネージャの判断で対応を決定する
- 差異分析
- 進捗遅延原因
- メンバへインタビューや成果物などの調査によって究明する
- プロジェクト内部に起因するもの
- 作業工数の見積り誤り
- 作業の見落とし
- 作業工数の過少見積り
- 分析ミス・設計ミス
- 上流工程での分析ミス・設計ミスが結合テスト工程やシステムテスト工程などの下流工程で発見された場合は、手戻り作業(修正作業)が発生するため大きな進捗遅れにつながる
- プログラムミスは影響範囲がそのプログラムに限定されるため、小さな進捗遅れの原因にしかならない場合が多い
- 開発環境の整備不良
- メンバの病欠や退職
- 作業工数の見積り誤り
- プロジェクト外部に起因するもの
- 仕様変更の多発
- 途中まで進捗した作業を最初に引き戻してしまうため、大きな遅延原因となる
- 仕様変更の多発
- 進捗遅延対策
- プロジェクトマネージャは、どの対策を取るのか、いつ行うのかなどを判断しなければならない
- 主な進捗遅延対策
- 作業順序の組換え
- 並行作業の実施
- 担当者の組換え
- 追加要員の投入
- 開発環境の整備
- 機能仕様の削減
- 部分的な本番稼動
- 本番稼動日の延期
- クラッシング
- スコープを縮小せずにプロジェクト全体のスケジュールを短縮する技法の一つ
- メンバの時間外勤務を増やしたり、業務内容に精通したメンバを新たに増員したりする
- クラッシングを行う際に、優先的に資源を投入すべきスケジュールアクティビティ
クリティカルパス上のスケジュールアクティビティ
- ファストトラッキング技法
- スケジュールの短縮技法の一つ
- 作業を同時並行で行うことにより納期を短縮すること
- 工期を短縮させるために、クリティカルパス上の作業に”ファストトラッキング”技法を適用した対策
全体の設計が完了する前に、仕様が固まっているモジュールを開発する
- クリティカルチェーン法
- 作業の依存関係と資源の依存関係の両方を考慮して、資源の競合が起きないようにスケジュールを管理する手法
- クリティカルパスを守るために、フィーディングバッファと所要期間バッファを設ける
- タスクのスケジューリングとバッファの設定方法
クリティカルパス上の最後のタスクの終了期と納期の間に、プロジェクト全体で使用するバッファを設定する
- 対策時のポイント
- 全体計画の見直し
- すぐに対策を行うのではなく、原因究明を行い、プロジェクト全体への影響度把握と全体計画の見直しを行う
- スケジュール・プロジェクト計画書の更新を行う
- ステークホルダとの調整
- ステークホルダへの説明と調整を行う
- ステークホルダ間の調整は代替案の比較によって進める
- 解決不能状態への対処
- 上級管理者へ報告し、判断を仰ぐ
- 進捗遅延対策の効果確認
- 進捗の遅れが回復しているかを確認し、効果が得られない場合は、再度、対策案を検討する
- 効果が一時的であると判断した場合は、遅延の再発防止策を検討する
- 全体計画の見直し
- 費用実績の把握
- 開発予算と実績の差異を監視し、必要に応じて計画変更を行う
- 財務会計データの一部を抽出・集計して費用実績を算出する
- 作業日報から稼動実績工数を把握する
- 作業日報と費用実績をまとめて原価実績報告書を作成する
- 予定と実績の差異を算定し、原価差異報告書にまとめる
- 成果物の手直しなどの問題対策が予算超過につながらないことを確認する
- 費用実績の評価
- (予定-実績)原価差異が小さい場合
- なにもしない
- (予定-実績)原価差異が大きい場合
- マイナスに大きい場合(原価超過)
- 対策を検討・実施する
- プラスに大きい場合(原価過少)
- 生産性が上がっている場合もあるが、進捗が予定よりも遅れている可能性もある
- マイナスに大きい場合(原価超過)
- 進捗管理や品質管理などの他の管理項目では何も問題が発生していないが原価差異だけが大きい場合は、状況を正しく把握出来ていない可能性が高い
- 原価差異分析手法
- EVA
- トレンドチャート
- 費用超過対策の実施
- 費用超過原因
- 計画時の見積り過少に起因するもの
- 作業工数の見積り誤り
- やるべき作業を見落とした
- 作業工数を少なめに見積もってしまった
- 購入品の見積り誤り
- サーバ台数、OS・開発ツールなどのライセンス数や単価を少なく見積もった
- 作業工数の見積り誤り
- 実行時のミスに起因するもの
- 分析ミス・設計ミス
- 開発環境の整備不良
- 想定外の問題発生に起因するもの
- 仕様変更の多発
- 提供された資料の誤り
- 計画時の見積り過少に起因するもの
- 費用超過対策
- 顧客との交渉
- 費用超過原因が顧客の仕様変更にある場合
- 仕様変更などの責任が顧客側にあることを証拠付ける資料を用意する
- 請負金額の改訂、仕様変更の凍結、必要機能の削減など
- 協力会社との交渉
- 費用超過原因が、協力会社の要員や作業の進め方にある場合
- 協力会社の要員の生産性が予想よりも低い場合には、それを証拠付ける資料を用意する
- 請負金額の改訂、要員の交替、作業方法の改善など
- 生産性の向上
- 作業方法や開発支援ツールを変更し生産性を向上させる
- 作業方法や開発ツールの変更には費用がかかるため、費用対効果を考えて導入する
- メンバのモラールの低下が原因の場合は、メンバと話し合いを行うことで解決策を考える
- 顧客との交渉
- 費用超過原因
- (予定-実績)原価差異が小さい場合
- 要員の動機付け
- 要員管理のポイントはメンバのやる気(モラール)を維持・向上させることにある
- 動機
目標を達成するための行動に駆り立てる要因 - モチベーション(動機付け)
動機を向上させること
- コミュニケーション
- 公式なコミュニケーション
- 計画書を配布する、実績法局所を提出する、会議に出席する、レビューを実施するなど
- 公式なコミュニケーションのほとんどは文書で行われ、また文書化される
- 非公式なコミュニケーション
- 雑談、手書きのメモを渡す、状況を口頭で聞くなど
- 非公式なコミュニケーションのほとんどは口頭で行われる
- 非公式なコミュニケーションが発端となり重大な問題点を発見する場合もあるので軽視できない
- 非公式なコミュニケーションを通して、公式なコミュニケーションで入手した情報の正確性や信憑性を評価する
- 問題点の発見と対策
- 主な問題点
- メンバ本人に起因するもの
- 病気や怪我
- 他のメンバとの相性
- 知識や経験不足
- メンバ本人に起因しない物
- 兼任している他の業務が多忙になった
- 派遣会社や協力会社からの命令、母体組織の人事異動により当該プロジェクトから外れることになった
- 以前に参画していたプロジェクトで発生した問題の対応
- 仕様変更により作業量が増加した
- 割り当てられた仕事が多すぎるもしくは少なすぎる
- メンバ本人に起因するもの
- 問題点の発見方法
- 公式なコミュニケーションによる方法
- 勤怠管理表、作業日報、作業進捗管理表などから作業量の適切さや負荷の状況を確認する
- 問題点一覧表を確認し、問題点が特定のメンバやチームに集中していないか確認する
- 非公式なコミュニケーションによる方法
- 作業場の巡回や雑談
- 仕事を離れたイベントの実施
- 公式なコミュニケーションによる方法
- 対策
- メンバ個人への対策
- カウンセリング
- 再教育
- 組織体制の見直し
- 他の責任者との交渉
兼任業務の負荷、優先順位の見直し - チーム編成の組み換え
- TRMの変更
- 要員交替・追加要因の投入
- 他の責任者との交渉
- メンバ個人への対策
- 主な問題点
- 公式なコミュニケーション
- 協力会社管理
受注したソフトウェア開発の一部を他社に委託する場合に、委託計画・実施・評価・改善活動を行い、ソフトウェア開発状況を管理すること - システム開発を外部に委託する場合に行う管理方法
一括請負の場合は、成果物を納入するまでの過程については、すべて委託先の責任とリスクで作業を実施するので、発注元が委託先の従業員に直接指示を出すことはできない - 人的資源計画
- チーム編成
- チーム育成
- チームマネジメント
- 契約に関する一般原則
- 契約自由の原則
- 契約は当事者が自由に決められるという原則
- 契約内容は、法律の強行規定を除き、当事者がが自由に決めて良い
- 契約優先の原則
- 強行規定を除く法律の規定と契約とでは、契約を優先するという原則
- 基本契約書
取引を開始する前に、会社の規模や新庄状況などを調査し、業者登録をする場合に締結する契約書 - 個別契約書
取引の内容について約束を決める契約書 - 守秘義務
契約を履行する過程において、契約当事者の双方が知り得た互いの営業上や技術上の秘密を他に漏らさない義務 - 瑕疵担保責任
仕事の目的物に瑕疵がある場合、その瑕疵を補修し被った被害を請負人が注文者に賠償する責任
- 契約自由の原則
- ソフトウェア開発でよく締結される契約
- 請負契約
- 委任契約
- 派遣契約
- パッケージ売買契約
- 保守契約
- SI契約
- アウトソーシング契約
- 費用に関する契約
- 定額契約
要求仕様が明確になっていない場合、納入者側のリスクが最も高くなる契約形態 - 実費償還契約
- 納入者の利益相当分を加えた金額を納入者に支払う契約
- コストプラス固定フィー契約 / コストプラス定額フィー契約
(CPFF契約)
請け負った作業の履行に対するコストが償還され、更にプロジェクトのコスト見積もりに対して一定比率の固定フィーを受け取る - コストプラスインセンティブフィー契約(CPIF契約)
請け負った作業の履行に対するコストが償還され、事前に取り決めたフィーと、契約で定めたパフォーマンス目標レベルの達成度に応じたインセンティブを受け取る
請け負った作業にかかったコストに加えて、契約時に合意したパフォーマンスの基準を達成した倍に受注者が所定の利益(フィー)を受け取る契約タイプ
- タイムアンドマテリアル契約
- 契約成立の時点で契約の全体総額を取り決めない契約方式
- 設定した単価に業務にかかった時間を掛け合わせる
- 定額インセンティブフィー契約 (FPIF契約)
あらかじめ目標コストを定め、実コストとの差異を納入者、購入者で分割する契約 - 単価契約
- 単価基準で契約を行うこと
- 定額契約
- ソフトウェア開発を請負契約で外部委託するときに、発注側が行わなければならないこと
成果物一覧や納期の提示 - 契約時に、受託者と委託者の作業範囲を明確にする
- 請負契約には法律上、作業状況の回答義務はないため、契約書に作業報告の義務を受託者に課すようにするケースが多い
- 契約に関するリスク管理
- 主なリスク
- 仕様変更の多発
- 予定していた生産性を達成できない
- 採用した新技術が不安定、性能不良となる可能性
- 法律や制度の変更
- リスク対策
- 契約の範囲を小さくする
- 期間を短くする、システム化の対象範囲を小さくする
- 請負契約の場合、契約の範囲を小さくすることは特に有効な対策となる
- リスクの少ない契約形態を選択する
- 派遣契約→委任契約→請負契約の順にリスクが少ない
- 不確定要素の多い上流工程(システム分析・要求定義フェーズなど)を委任契約、下流工程(外部設計以降)を請負契約とすることでリスクを軽減できる
- 契約金額・納期の見直し条項を入れる
- 民法が規定する請負契約では、委託者が当初想定した指示内容を変更するケースを想定しないため、見直し条項を追加する
- 入手した資料の品質に左右されないようにするための条項を入れる
- 受託者が利用する成果物の品質に問題があり、その問題が成果物に引き継がれた場合に免責されることを含める
- 守秘義務条項を入れる
- 契約の範囲を小さくする
- 主なリスク
- 協力会社との契約
- ソフトウェア開発の委託手順
- 計画フェーズ
- プロジェクト計画の確認
- 外注計画書の作成
- RFPの作成と説明
- 発注先選定
- 契約の締結
- 実行・評価フェーズ
- 実績把握
- 実績評価と対策の実施
- 成果物のレビュー・検収
- 支払い・完了報告書の作成
- 計画フェーズ
- プロジェクト計画の確認
社内では技術力や工数が不足していることを確認し、要員数・必要な技能・時期・を明らかにする - 外注計画書の作成
- 以下の事項を記載する
- 委託業務の内容
- 成果物
- 委託形態
- 委託時期
- 費用概算
- 外注管理方針
- 発注先候補
- 作成上の留意点
- 委託する業務の範囲を明確にする
- 費用を見積もる場合、協力会社に支払う費用だけでなく、社内の外注管理に必要な費用もかさんする
- 協力会社に遵守させる諸基準の備状況を評価し、不十分であればその整備作業も計画書に盛り込む
- 以下の事項を記載する
- RFPの作成
- RFPの記載事項
- 委託業務、成果物、委託形態、委託時期、外注管理方針など提案のための前提条件
- 提案書に記載すべき事項・要件
- 会社の概要、管理体制、総合的な技術力を示す指標
- 予定している要員の一覧表
- 見積金額及びその算定方法
- 事務的な連絡
- 提出期限、提出方法、選考結果の通知方法など
- 発注先候補に送付し、説明会を実施する
- RFPの記載事項
- 発注先選定
- 留意事項
- 見積金額だけでなく、品質その他の管理体制を加味して評価する
- 会社の規模や信用能力だけでなく、予定する作業方法、作業予定要員の知識や技能の評価を重視する
- 類似システム開発経験の有無を確認する
- その会社を発注先に選定した場合のリスクを評価する
- 二次選考が必要な場合には、その先行手順を決定する
- 提案書を入手する前に選考基準を作っておく
- 留意事項
- 契約の締結
- RFP、提案書に基づき契約書を作成する
- トラブルのもととなるため、契約締結前に作業を開始してはならない
- 実績把握
- 会議の開催や報告書の入手によって、協力会社の状況を把握する
- 会議では必ず議事録を作成する
- 実績把握方法は社内のものと同じでなければならない
- 実績評価と対策の実施
- 協力会社の進捗状況や品実状況が思わしくない場合には、何らかの対策を講じる
- 成果物のレビュー・検収
- 協力会社が作成した成果物をレビュー基準、検収基準に従ってレビュー、検収する
- 支払い・完了報告書の作成
- 完了報告書を作成し、次プロジェクトに課題や教訓を残す
- ソフトウェア開発の委託手順
- 生産性の計画
- ソフトウェア開発の生産性は、時間あたりに完成させる設計書枚数やソースプログラムのステップ数で考える
- ソフトウェアによって獲得される価値を、ソフトウェア開発に必要な作業量で割ったもの
- 生産性
投入する資源の量と産出した価値の比率 - 生産性=産出した価値/投入する資源の量
生産性＝品質×増幅効率×開発効率 - ソフトウェア開発の生産性=成果物の量/投入する作業工数
- プロジェクトマネージャは、生産性をどの程度見込むかの判断を行う
- 生産性の増減要因
- 採用するツールや開発環境の整備状況
- 開発するソフトウェアの規模、難易度、設計仕様の複雑さ
- 開発規模と生産性は、反比例する関係にある
- 開発済みドキュメント、プログラムの再利用度
- 過去に開発した成果物(設計書、仕様書、プログラムなど)を再利用出来れば、新規に開発すべき量が減少するので生産性が向上する
- ソフトウェアの生産性=完成させる成果物の量/投入する作業工数
=完成させる成果物の量/新規開発する成果物の量 × 新規開発する成果物の量/投入する作業工数
=増幅効率×開発作業効率 - 増幅効率
- 完成させる成果物の量を、新規に作成する成果物の量で割った値
- この率を向上させるには、過去に作った、もしくは他人が作った成果物を再利用する
- 増幅効率を上げれば生産性は向上する
- 共通ルーチン(関数)の全体に占める割合
- 共通ルーチンの全体に占める比率が高いと生産性は向上する
- 各メンバが開発するようが減少する
- 仕様変更の回数及び規模
- 仕様変更が多発すると生産性は低下する
- 仕様変更に関する工数をそのまま投入した工数に加算すると本来の生産性が分からなくなるため、別に集計する
- 生産性の予定(目標)
- プロジェクトで採用する生産性の定義と算定式を決定する
- 過去の生産性の実績値を調査する
- WBSや作業順序を見て作業予定状況を確認する
- プロジェクトの特殊性(採用する新技術や難易度など)を加味して、生産性の予定(目標値)を決定する
- 実績把握と評価
- 進捗管理によって把握される成果物の作成状況と組織要員管理での作業日報の工数の対比によって把握する
- 評価上の留意点と対策・検討
- 開発環境の整備などの前提条件
- 未整備であれば専任者を任命し、至急作業に着手させる
- 採用した技術・ツールなどの問題点や不具合
- 使用しているメンバにヒアリングを実施する
- 問題があれば代替手段の採用を検討する
- 開発規模
- 開発規模が急増しているならば、前提条件が大幅に変わっているので、生産性を含めて計画全体を見直す
- 開発済みドキュメント、プログラムの再利用率
- 再利用率が低い場合には再利用を促進するための説明会を実施する
- 共通ルーチンの占める比率
- 他人が作成したルーチンの使用を拒否するメンバに対するカウンセリング
- 成功例・失敗例のような生産性向上事例集を作成する
- 仕様変更の回数・規模・影響範囲
- 仕様変更が当初の想定よりも多い場合は、仕様凍結を検討し、ユーザ部門などと調整する
- 開発環境の整備などの前提条件
- 対象
- ドキュメント
- 設計ドキュメント、マニュアル
- ソースコード、定義ファイル
- オブジェクト、実行形式ファイル
- 開発環境、テスト環境
- OSのバージョンやパッチレベルの違いでアプリケーションの動作が異なる場合があるため、開発環境やテスト環境の内容を管理する
- パッケージソフトウェア、OS
- ドキュメント
- 計画変更要員
- 外部に起因
- 法律、制度の改正
- 経済環境の変化
- 競合他社の動向
- 接続する機器の変更
- ユーザの要求
- 内部に起因
- 分析ミス・設計ミス
- 性能不良
- 生産性不良
- 外部に起因
- バージョン管理
- ソフトウェアの構成要素であるソースファイルやドキュメントの版数を管理する
- バージョン
- 大きな仕様変更や構成変更の管理に使用する
- リビジョン
小規模な変更やバグ修正の管理に使用する - ベースライン
正式なレビューや承認を受け、ある版数として固定された成果物の集まり
- 構成管理
- コンピュータシステムの構成要素に生じる変更を管理すること
- 特にソースプログラムやドキュメントの変更管理を指す場合もある
- 構成管理ツールの利用
ソースコードだけでなくドキュメントを管理できるツールを積極的に利用する - 構成識別体系の確立
- 構成状況の記録
- 変更管理
- 障害や顧客からの仕様変更要求により設計やプログラムに対して加えられる変更を管理すること
- 要求された変更がどのバージョン、リビジョンに関連するのかを管理する
- 仕様変更は、予定数を計画し、その範囲内に収めるようにコントロールする
- 変更依頼書
ユーザの要求仕様が変更されたり、テストにより発見された問題を解消するために、仕様変更が発生した場合にそれを記入する依頼書 - 合意済みのシステム要件に対し、機能追加となる変更依頼を顧客から受けたときの受託側の対応
決定権を持つ会議や責任者が、変更を行うかどうかを判断する - 変更管理の流れ
- 変更要求の受付
- 変更内容の調査、検討、決定
検討結果によっては変更しない場合や、他の変更案件のタイミングに合わせて変更することもある - 変更の指示・実施・テスト・反映
- 報告
- 品目の完全性保証
- リリース管理及び出荷
- 事例
- ソフトウェア開発において、構成管理に起因しない問題
システムテストにおいて、単体テストレベルのバグが多発して、開発が予定通り進捗しない - ソフトウェア開発において、構成管理に起因する問題
- 開発者がバグを定められた手続に従わずに修正したので、今まで動作していたプログラムが、突然に不正な動作をする
- 仕様書、設計書及びプログラムのそれぞれが一致しないので、プログラム修正時にソースプログラムを解析しないと、修正すべきプログラムが特定できない
- 一つのプログラムから多数の派生プログラムが作られているが、派生元のバグ修正がすべての派生プログラムに反映されていない
- ソフトウェア開発において、構成管理に起因しない問題
