開発流れ

開発流れ
修正履歴
•
•
2011/11/15 新規作成
2011/11/16 ページ「単体テストフェーズの成果物について」に「データ作成する時、マスタ
データが基本的にないことはないだと考えていいだが、念のため、確認したほうがよい。」
を追加
各フェーズ（工程）
•
•
•
•
•
•
•
要件定義（基本は担当範囲外）
基本設計
詳細設計
コーディング（プログラミング、製造）
単体テスト
結合テスト
総合テスト、システムテスト、本番テスト（基本
は担当範囲外）
各フェーズの関係
要件定義
基本設計
詳細設計
指導⇔検証
指導⇔検証
指導⇔検証
総合テスト
結合テスト
単体テスト
コーディング
•
黒い「→」は開発の基本流れである。前のフェーズのＯｕｔｐｕｔは次フェーズのＩｎｐｕｔとなる。
必ず前のフェーズが全部終わってから次のフェーズに入るわけではないことを注意してくだ
さい。
• 赤い「→」は離れているフェーズの関係を示している。詳細設計と単体テストを例として説明
する。
詳細設計のＯｕｔｐｕｔは単体テストのＩｎｐｕｔとなり、単体テストは詳細設計通りで実装している
かどうかを検証する。
• 次のフェーズの実装より前のフェーズを修正しないといけない場合がある。
• プロジェクトより各フェーズの名称/有無が違い場合がある。基本設計を外部設計、内部設
計に分けるケースもある。あくまで、開発流れとＶ型のイメージを立ってもらうことがポイント
である。
各フェーズの入力資料と成果物
フェーズ
入力資料
成果物
要件定義
ユーザとの打ち合わせ、
運用中のシステム
要件定義書
基本設計
要件定義書
ガイド（サンプル）
Ｑ＆Ａ
横展開
仕様変更
テーブル定義書、
ＥＲ図、
メッセージ定義書、
コード定義書、
ＩＦ設計書、
画面遷移図、
各画面の画面（帳票）定義
書、
各画面の機能説明書、
各モック画面、
各一覧、
レビュー票
詳細設計
基本設計
ガイド（サンプル）
Ｑ＆Ａ
横展開
仕様変更
各画面の詳細設計書、
各機能（モジュールごと）
の詳細設計書、
チェックリスト、
レビュー票
各フェーズの入力資料と成果物（つづき）
フェーズ
入力資料
成果物
コーティング
詳細設計
ガイド（サンプル）
Ｑ＆Ａ
横展開
仕様変更
ソース（コメント付き）、
Ｊｕｎｉｔソース、
チェックリスト、
レビュー票
単体テスト
詳細設計書
ガイド（サンプル）
Ｑ＆Ａ
横展開
仕様変更
画面単体テスト仕様書、
画面単体テスト証跡（デー
タ）、
Ｊｕｉｎｔテスト仕様書（デー
タ）、
単体テストバグ票（Ｊｕｉｎｔも
含む）、
チェックリスト、
レビュー票
結合テスト
基本設計
ガイド（サンプル）
Ｑ＆Ａ
横展開
仕様変更
結合テスト仕様書、
結合テスト証跡（データ）、
結合テストバグ票、
チェックリスト、
レビュー票
各フェーズの入力資料と成果物（つづき）
フェーズ
総合テスト、システムテ
スト、本番テスト
入力資料
要件定義
Ｑ＆Ａ
横展開
仕様変更
成果物
各テスト仕様書、
各テスト証跡（データ）
説明
• 要件定義、総合テスト、システムテスト、本番テストは基本的にオフショア
の担当範囲外であるので上記に書いている入力資料と成果物は正しくな
い場合がある。
• 各フェーズでも誤りがあるはず。その誤りを指摘理由として
（１）上流設計と違い
（２）類似画面と違い
（３）常識。その他のシステムがやっているもの。Ｔａｂ順、入力桁数チェッ
ク、コピーペストより桁数チェックなど。
が考えられる。
基本設計フェーズの成果物について
テーブル定義書
• テーブルごとに作られるのは一般的。
そのテーブルにあるすべてのフィールドの日本語名、英語名、主キー、Ｎ
ｏｔＮｕｌｌ、型、桁数を明記するもの。
ＥＲ図
• テーブル間の関係を示すものである。
メッセージ定義書
• システム上に使われるメッセージを定義するものである。
Ｉｎｆｏｒｍａｔｉｏｎ、Ｗａｒｎｉｎｇ、Ｅｒｒｏｒ、Ｆａｔａｌに分けることもある。
メッセージＩＤとメッセージ内容を明記するもの。
コード定義書
• システム上に使われるコードを定義するものである。
コードごとにシートを分けるのは一般的。
ＩＦ設計書
• 各モジュールのＩｎｐｕｔ、Ｏｕｔｐｕｔを明記するものである。
特に、システムに使われる外部の部品の説明が重要。
ＩＦ以外、簡単なロジック記述があれば、理解しやすくなる。
（booleanの説明）
基本設計フェーズの成果物について（つづき）
画面遷移図
• 遷移元画面ＩＤ、名称、遷移元画面イベント（遷移を行うイベント）、遷移先
画面ＩＤ、名称を明記するものである。
画面（帳票）定義書
• 画面レイアウト、各画面項目の名称、位置、桁数、型、編集形式、表示内
容（選択リスト）、単項目チェック（オプション）、イベントを明記するもので
ある。
• 帳票の場合、画面レイアウト、各画面項目の名称、位置、桁数、型、編集
形式、表示内容を明記するものである。
機能説明書
• 画面以外、裏で行う処理を記述するものである。
単項目チェック（オプション）、関連チェック、業務チェック、ＤＢとのアクセ
ス、他機能（Ｕｔｉｌ）の呼び出す、遷移画面の設定、システムに使われるス
テータス、メッセージＩＤの設定などを記載するものである。
モック画面
• Ｈｔｍｌのことを指す。ユーザが承認されたのは一般的。画面定義書のレイ
アウトと一致するはずので、不一致の場合、どちらが正と確認する必要
がある。
詳細設計フェーズの成果物について
詳細設計は画面と画面以外に分けて作るのは一般的。
画面以外、モジュール単位で作るのは一般的。
（１）各画面の詳細設計書
Ｈｔｍｌに記載するロジック、ＪＳの実装、単項目チェックの実装を明記するも
のである。
（２）各機能（モジュールごと）の詳細設計書
使うモジュールのＩＦを確認した上、ソースの実装を指導できるように、作成す
るものである。
（３）チェックリスト
担当者が成果物をレビュー者に投げる前に自分で再度確認するリストであ
る。プロジェクトごとに特有のものが書かれるのは一般的。
（４）レビュー票
レビュー者が担当者の成果物を確認し、指摘を書くものである。
担当者がその指摘を対応してレビュー者の再度確認をもらう必要がある。
単体テストフェーズの成果物について
画面単体テスト仕様書
• 基本設計と詳細設計の画面定義書よりテストケースを作る。ブラックボッ
クステストである。
レイアウトとボタン動作と単項目チェックを確認する。
注意するのは境界値、最大値、最小値のテストが必要となる。基本的に、
単体テスト実施ガイドに書いてあるはず。
最大値のデータは「ＷＷＷＷＷＷＷＷＷ１ＷＷＷＷＷＷＷＷＷ２」のよう
に作成するのは薦めである。
データ作成する時、マスタデータ（マスタテーブル（入力画面がないもの）、
コード、メッセージ）が基本的にないことはないだと考えていいだが、念の
ため、確認したほうがよい。
画面単体テスト証跡（データ）
• 画面単体テストのケースごとに、データとそのケースを検証できるシステ
ムのハードコピーが必要である。
いうまでもないだが、データとハードコピーはそのケースを検証できるの
は一番重要。
Ｊｕｎｉｔ単体テスト仕様書
• Ｊｕｉｎｔはモジュールごとに作成する必要がある。その単体テスト仕様書も
同じ。テスト観点として、上位インタフェース、下位インタフェース、同値分
析、境界値、条件分岐が必要。
単体テストフェーズの成果物について（つづき）
単体テストバグ票
• 画面単体テスト、Ｊｕｉｎｔテストで発見した誤りを記入するものである。
検証するのはソースだけだけど、誤りはソースのみ発生ではなく、原因を分
析する必要がある。基本的には、
（１）テストに関する
テスト環境不備、テストデータ不備、テスト手法誤り（手順違反、仕様通り）な
ど
（２）ソースに関する
単純ミス、仕様理解間違い、仕様反映（取込み）漏れなど
（３）設計に関する
上流設計ミス
が考えられる。
注意：基本設計、詳細設計、単体テスト、結合テストの仕様書作成する前に
それぞれの作成ガイドを必ずよく読んでください。
ソース、Ｊｕｉｎｔを書く前に、それらの実装ガイド、実装イメージも確認する必
要がある。
単体テストフェーズの成果物について（つづき）
単体テストバグ票
• 画面単体テスト、Ｊｕｉｎｔテストで発見した誤りを記入するものである。
検証するのはソースだけだけど、誤りはソースのみ発生ではなく、原因を分
析する必要がある。基本的には、
（１）テストに関する
テスト環境不備、テストデータ不備、テスト手法誤り（手順違反、仕様通り）な
ど
（２）ソースに関する
単純ミス、仕様理解間違い、仕様反映（取込み）漏れなど
（３）設計に関する
上流設計ミス
が考えられる。
注意：基本設計、詳細設計、単体テスト、結合テストの仕様書作成する前に
それぞれの作成ガイドを必ずよく読んでください。
ソース、Ｊｕｉｎｔを書く前に、それらの実装ガイド、実装イメージも確認する必
要がある。

Download Report