Frequently used words (click to add to your profile)

javac++androidlinuxc#objective-cqtwindows誰得cocoapythonphprubygameguibathyscaphec翻訳omegat計画中(planning stage)frameworktwittertestdomvb.netdirectxbtronarduinopreviewerゲームエンジン

ページ一覧

Wikiガイド(Guide)

サイドバー (Side Bar)

データ収集

納品間近になると、業務の発注元から「納品物 (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 の設計書に記載する
    • チケットに記載している情報は設計書には記載しない
  • 修正チケット上に修正に必要な全情報を載せる
    • 直接原因, 根本原因, 対策概要
    • 修正内容ごとに概要資料や設計書を作らない (情報を分散させない)
    • 図解もチケットに登録する