takoyaki_umaaaa
edit== データ収集
納品間近になると、業務の発注元から「納品物 (Software) が充分に品質が高いことを証明する資料」を要求される。[[br]]
開発終盤になってからそういったデータを集めるのは難しい。不具合修正に追われていたり、収集したいデータがなくなっている場合があるため。[[br]]
そのため開発初期のときから予め必要なデータを集め、加工できる形にしておく。[[br]]
また、収集データを開発にも生かせるようにする。[[br]]
[[br]]
=== 目的
1. 開発効率を上げる
* 仕様変更が発生する傾向を明確にして設計材料にする
1. 製品の品質を上げる
* 不具合が発生しやすい箇所を特定し、対策を立てやすくする
1. 納品先への説得材料とする
[[br]]
=== 表示
* グラフは縦軸：発生数，横軸：日付 にする
1. 仕様変更の発生数グラフ
1. 不具合の発生数グラフ
1. 不具合修正完了数グラフ (修正完了日でカウント)
[[br]]
=== 収集データ
1. 仕様変更の発生回数, 発生日時
* スケジュールや予算の話の材料にする
1. 修正ID
1. 種別 (仕様変更)
1. 修正が発生する機能ID (大項目・中項目) 複数
1. 修正予想工数 (設計・実装・試験)
1. 修正消費工数 (設計・実装・試験)
1. 修正開始日
1. 修正完了日 (開始～完了日数は消費工数と一致しない)
1. 不具合の発生回数
* 不具合が起きやすい箇所の特定
1. 修正ID
1. 種別 (不具合)
1. 修正が発生する機能ID (大項目・中項目) 複数
1. 修正予想工数 (設計・実装・試験)
1. 修正消費工数 (設計・実装・試験)
1. 修正開始日
1. 修正完了日 (開始～完了日数は消費工数と一致しない)
[[br]]
=== 備考
* 機能ID 単位で設計書を作成する
* 修正に対する設計は、該当する機能ID の設計書に記載する
* チケットに記載している情報は設計書には記載しない
* 修正チケット上に修正に必要な全情報を載せる
* 直接原因, 根本原因, 対策概要
* 修正内容ごとに概要資料や設計書を作らない (情報を分散させない)
* 図解もチケットに登録する