戻る トップメニュー
| . |
改善計画書とテスト計画書(小規模フリーランスが必要な改善計画書とテスト計画書の最低限の知識) 改善計画書とテスト計画書をレビューして規模を明確にしてから仕事を受けよう。 具体的な書き方を説明するまえに、 下記のダウンロードで空の改善計画書とテスト計画書が取り込んでください。 改善計画書とテスト計画書のテンプレート DownLoad
ご注意:
このドキュメントは改善が目的です。
規模が小さくても新規の開発には使用できません。
依頼者や関係者との調正
大手のソフトハウスでは2010年ごろから下記のスタイルがとられるようになった。
・ドキュメントを最初に作り、これを合意し、契約する。
・受注者はそこに記述された作業をする。
・受注者はそこに記述されたテストをする。
・依頼者はテスト結果を確認し、受注者の作業が完了する。
さて、依頼者がこのことを経験していれば問題ないのだが、
知らない場合、説明し理解してもらう必要があります。
ドキュメントを最初に作るには、現状をいつでも自由に操作できる
環境またはテスト環境を用意してもらう必要があります。
また関係するソースをいつでも自由に見ることのできる環境も必要です。
ドキュメントを作るには、ある程度の時間もかかります。
もし、理解してもらえない場合。断りましょう。
改善計画書の概要の記入方法依頼名改善依頼名でも改善業務名でもかまわない。 改善ではなく新規の開発の場合もある。 依頼者も受注者もわかりやすい名称を書く。 依頼概要
改善の概要を記述します。
その処理を作業するユーザの目線で、
処理のどの部分を何から何に変更するかを表現します。
依頼項目.依頼番号
依頼者が管理しているこの依頼の番号。
ない場合は受注者が管理しやすい番号。
依頼項目.項目番号と項目名
項目番号: 連番
項目名: 項目の名前
項目の分け方
・修正するプログラム(ファイル)の場所ごとに項目に分割する。
予定
開始日: 実質的に改善計画書の作業の開始日。
レビュー予定日: 計画書を作る合意を得たとき、レビュー予定日を決めておく。
(改善の規模におうじて複数回設定する)
承認日:
承認されたら、以降の以下の日程を確定する。(これは重要)
改善開始日:
中間フォロー日:
移行日: 段階的に移行する場合はそれぞれ個別に移行日を設定
完了予定日:
移行作業内容内容
移行作業がある場合は志の内容を詳しく記述し、ない場合は「なし」を記述
納入物
ソフトウエアの納入:
具体的に納入の方法を記述
ユーザ用の手順書:
改善の影響で書き直し場合、前手順書の変更部分等の位置を記述、
ない場合は「なし」を記述
その他資料
資料を詳しく記述する。ない場合は「なし」を記述
・資料の使用目的
・どのような人が使うか
・使用タイミング
作成部署/作成者
自分の場合、または元受けの会社等
改善計画書の項目の記入方法依頼番号-項目番号 ~ 当項目内ページ
依頼番号-項目番号: 表紙の依頼項目の依頼番号-項目番号
依頼名: 表紙の依頼名
依頼項目名: 表紙の依頼項目の依頼項目名
当項目内ページ: 当ページが複数になる場合のページ数/総数
この項目の修正概要この項目(この改善箇所)の修正概要。 依頼者とプログラマー両方に解る表現。 調査
下記内容をプログラムが作れる深度で調査し、記述する。
・修正箇所のあるプログラム(ファイル)
・修正箇所の処理名と行のからまで
・修正箇所はどのようにするか
・修正の参考にする他システムがある場合、そのプログラム(ファイル)と参考部位
・修正に対する制約
・例:修正対象の画面表示は修正前と同じ形状
・例:修正前も修正後も画面操作は同じであること
修正の詳細
具体的に修正内容をプログラムがつくれるレベルで記述する。
テスト計画書の記入方法依頼番号-項目番号 ~ 当項目内ページ
改善計画書と同じ
テストの番号と確認内容
番号: この項目での確認内容の連番
確認内容: この項目での確認内容(この列は必要に応じて列幅を調整する)
テスト組み合わせ条件と操作の1からn
確認内容に対するテスト条件または操作を記述
複数の条件や操作の組み合わせがある場合は1からnの列を作る
(この列は必要に応じて列幅を調整する)
予定結果
この行のテスト条件または操作での予想結果
確認と資料
この列以降は、この項目の作業が終了し、テストに入ってから記入
この行のテスト条件または操作での結果を記入
・可否: 予定の結果であるか?
・日: テスト日
・者: テスト担当者
・番号: テストのエビデンス
|
. |