´Д｀)< ワイの隠れ家

データ収集

納品間近になると、業務の発注元から「納品物 (Software) が充分に品質が高いことを証明する資料」を要求される。
開発終盤になってからそういったデータを集めるのは難しい。不具合修正に追われていたり、収集したいデータがなくなっている場合があるため。
そのため開発初期のときから予め必要なデータを集め、加工できる形にしておく。
また、収集データを開発にも生かせるようにする。

目的

1. 開発効率を上げる
   • 仕様変更が発生する傾向を明確にして設計材料にする
2. 製品の品質を上げる
   • 不具合が発生しやすい箇所を特定し、対策を立てやすくする
3. 納品先への説得材料とする

表示

• グラフは縦軸：発生数，横軸：日付 にする

1. 仕様変更の発生数グラフ
2. 不具合の発生数グラフ
3. 不具合修正完了数グラフ (修正完了日でカウント)

収集データ

1. 仕様変更の発生回数, 発生日時

• スケジュールや予算の話の材料にする
  1. 修正ID
  2. 種別 (仕様変更)
  3. 修正が発生する機能ID (大項目・中項目) 複数
  4. 修正予想工数 (設計・実装・試験)
  5. 修正消費工数 (設計・実装・試験)
  6. 修正開始日
  7. 修正完了日 (開始～完了日数は消費工数と一致しない)

1. 不具合の発生回数

• 不具合が起きやすい箇所の特定
  1. 修正ID
  2. 種別 (不具合)
  3. 修正が発生する機能ID (大項目・中項目) 複数
  4. 修正予想工数 (設計・実装・試験)
  5. 修正消費工数 (設計・実装・試験)
  6. 修正開始日
  7. 修正完了日 (開始～完了日数は消費工数と一致しない)

備考

• 機能ID 単位で設計書を作成する
  • 修正に対する設計は、該当する機能ID の設計書に記載する
  • チケットに記載している情報は設計書には記載しない
• 修正チケット上に修正に必要な全情報を載せる
  • 直接原因, 根本原因, 対策概要
  • 修正内容ごとに概要資料や設計書を作らない (情報を分散させない)
  • 図解もチケットに登録する