# 14. V-Model Waterfall ________________________________________ 【電子合本版】Code Complete 第2版 完全なプログラミングを目指して（上巻：1部） https://bookplus.nikkei.com/atcl/catalog/05/589000/ アジャイルサムライ――達人開発者への道 https://shop.ohmsha.co.jp/shopdetail/000000001901/ ________________________________________ ## 1. 基礎知識 ________________________________________ ### 1.0. 前提 本稿で示す開発対象の前提 1. 基幹システムまたはECサイトである 2. エンターテイメント性主導ではなく、業務目的主導でよい 3. リプレース案件あるいはセカンドシステム案件 4. 完全新規部分が全体の3割を超えない ________________________________________ ### 1.1. ソフトウェアを構築するということ 方針の選択 1. 犬小屋には犬小屋の、家には家の、原子炉には原子炉の建築計画を 2. 洗濯機、冷蔵庫、キャビネット、窓、ドア、浴室設備は買えばいい 3. ただし、オーダーメイドの内装をご所望ならその限りではない 4. 柱や梁は必ず始めに決めるが、床材や壁の色は後からでも良い 準備の重要性 1. 上流工程は必須だ 2. 上流工程ができない者に対して、時間を増やしても無駄だ 3. 反復型プロジェクトでも、要求とアーキテクチャを特定するのは同じ 4. 上流工程に欠陥は、下流に欠陥より10倍以上の修正コストがかかる 開発方針の選択 1. 逐次型は、「要求がかなり安定」「開発者が業務分野を熟知」に推奨 2. 反復型は、「要求が不明で変化」「開発者が業務分野に無知」に推奨 課題、要求、解決策 1. 課題を解決しようとする前に、課題が何かを見極める 2. 課題が適切でも、要求が明記されていないと的を射れない 3. 課題と要求が適切でも、解決方法が間違っていると失敗する 4. 機能は重要ではない。ビジネス価値を踏まえた要求の解決にこそ意味がある 5. 6歳の子供に説明できないことは、本当は理解できていないのだ 計画と調整 1. 画面設計以降で、要件が1/4は変わる事を見越して計画する 2. 興奮した顧客には、スケジュールとコストという文言が効く 3. それでもだめなら、仕様変更を手順化し数値化し追加コスト明示 4. 納品するべきかどうかが曖昧な場合（些末な設計書等）、その文書をもとに後続の作業がいつ存在するのかを考える ※ 以降の説明は、原則WFモデルを選択した前提としています ________________________________________ ### 1.2. 打ち合わせ原則 打ち合わせのやり方 1. 打ち合わせ不要で決められる部分は、Redmine等で済ませる 2. ニュアンス確認・成果物のレビュー等を目的で行う 3. 各会議ごとに定義（ゴール）を明確にする 4. 議題項目表(agenda)を必ず用意する 5. agendaは前日までに送り、先方に予め目を通してもらう 6. agendaに追記する形で議事録とする 7. agendaは結論のない議事録である。概ねA4用紙1~2枚である 8. client持ち帰り宿題を青色、それ以外は赤として追記していく 9. 打ち合わせが終わったら、双方のやるべき次の1手が明確である 議事録の形式 1. タイトル、日付、時間、場所、参加者、vendor成果物、client成果物 2. 状況確認 3. 主議題内容（QA確認項目あるいはレビュー成果物など） 4. その他の議題内容 5. 次回予定、vendor宿題、clinet宿題 6. その他確認・質問 小手先テクニック 1. 「会議でスマートに見せる100の方法」。3割ぐらい使える 2. 「エリック・エヴァンスのドメイン駆動設計」。敵=認識齟齬 ________________________________________ ### 1.3. QCDSトレードオフ これらは、トレードオフの関係しかありえない - Quality - Cost - Delivery - Scope ※ Sは、業界によってService/Support/Safetyなどである ________________________________________ ### 1.4. 受容物と成果物・納品物の管理 バージョン管理について ```text - ソースはgit - ソース以外はsvn - どちらも用意してないなら、ファイル名_yyyymmdd_何をしたかの概要.xxx ``` 典型的なファイル置き場のディレクトリ構成 ```text - 10_管理 - 01_契約 - 基本契約書.docx - NDA.docx - 個別契約書.docx - 02_提案書 - ○○構築提案書.pptx - 03_全体計画 - プロジェクト計画書.pptx - マスタスケジュール.xlsx - 体制図.docx - 全システム概要図.xlsx - 成果物一覧.xlsx - 担当者連絡先一覧.xlsx - 会議体・レビュー手順等.xlsx - 工程別全体計画 - 全体テスト計画.xlsx - 全体移行計画.xlsx - 全体教育計画.xlsx - 04_フォーマット - 0、ファイル雛型：汎用 - project名_第1回アジェンダ.docx - 1、ファイル雛型：営業ヒアリング - project名_概算見積.xlsx - project名_要望確認.xlsx - 2、ファイル雛型：提案書 - project名_システム概要(空).docx - project名_マスタスケジュール(空).docx - project名_見積書.xlsx - project名_実施体制図.docx - project名_提案書(docx版).docx - project名_提案書(pptx版).pptx - 3、ファイル雛型：契約書 - [雛形]取引基本契約書(受注の場合）.doc - [雛形]取引基本契約書(弊社発注の場合）.doc - [雛形]秘密保持契約書(受注の場合）.doc - [雛形]秘密保持契約書(弊社発注の場合）.doc - project名_個別発注書(空).docx - 4、ファイル雛型：要件定義 - project名_課題管理表(Redmine等推奨).xlsx - project名_外部IF一覧(空).xlsx - project名_機能一覧(空).xlsx - project名_業務フロー図(空).docx - project名_方式設計.xlsx - project名_要件定義書.docx - 5、ファイル雛型：基本設計 - project略称_画面設計書_XX01D01_ほげほげポップアップ.xlsx - 6、ファイル雛型：大規模プロジェクト用（PMO関連） - project名_ステアリングコミッティ報告資料(空).xlsx - project名_工程開始終了判定基準(空).xlsx - project名_進捗集計表(空).xlsx - 05_プロジェクト状況 - 01_進捗管理 - 02_課題管理（通常はRedmine等で管理） - 03_QA・Todo（通常はRedmine等で管理） - 04_リスク管理（通常はRedmine等で管理） - 05_仕様変更管理（通常はRedmine等で管理） - 06_不具合管理（通常はRedmine等で管理） - 20_要件定義 - RD01_業務フロー図 - RD02_機能要件記述書 - 30_基本設計 - ED00_システム方針 - ED01_画面設計書 - ED02_帳票設計書 - ED03_バッチ設計書 - ED04_コード定義 (* OTLTや表示メッセージ定義のこと。ソースのことではない) - ED05_テーブル定義 - 移行 - 40_詳細設計（内訳は基本設計と同様） - 50_実装・単体テスト - DEV01_コード（通常はgit） - DEV02_DB（通常はgit） - DEV03_リソース（通常はgit） - UT01_単体テストケース - UT02_単体テスト結果エビデンス - 移行（通常はgit） - 60_結合テスト - ITa - 01_ITaテストケース - 02_ITb結果エビデンス - ITb - 00_業務シナリオ - 01_ITbテストケース - 02_ITb結果エビデンス - 70_システムテスト - ST01_システムテストケース - ST02_システムテスト結果エビデンス - ITc_強化テストケース - ITc_強化テスト結果エビデンス - 80_ユーザーテスト - 90_移行・教育 - 98_インフラ - 99_受領資料 - 機能一覧.xlsx - 用語集.xlsx ``` ________________________________________ ## 2. 各フェーズの役割 ________________________________________ ### 2.1. 要約 見積関係式 ```text 機能一覧数　　　　 = 画面数 + バッチ数 + 外部連携数 概算 　　　 = 機能一覧数 * (24 + 機能一覧数/3) 見積金額　　　　　 = (人日/20 * 80) ^ 1.013 ベンダー顧客工数比 = 5 : 1 要件定義の金額　　 = 10% *FP実工数グラフは、緩やかなべき関数である *管理工数10%とするか、工数係数1.013乗するかは好み。～6000万辺りまでは誤差の範囲 ``` 各フェーズ フェーズ |概要 ----------|------------------------------------------------------ 営業体制 |顧客営業管理。不在/アポ到達/アポ拒否/受注、困り事は何 営業教育 |どんな顧客、どんなトーク、費用対効果推測 アポ |アポ、インバウンド、提案依頼書受容、初期ヒアリング ヒアリング|概算見積、要望一覧 提案 |提案書、見積書、マススケ、実施体制図、システム概要 受注 |基本契約書、NDA、個別発注書、支払い方法の説明 要件定義 |やりたいこと決める。性能要件、たたき台MOCK 基本設計 |ER、機能間整合性、UIUX・方式設計、画面Fix 詳細設計 |DBView、結合条件、SQLレビュー、SQL入出力正解網羅表 実装 |ー UT |詳細設計に対するテスト等 ITa |画面間テスト、サブシステム内テスト ITb |サブシステム間テスト ST |業務シナリオベーステスト UAT |最終確認 - 最低限の納品成果物 1. 開発計画書 - スケジュール/会議予定 - 決定ルール・情報共有・会議体・連絡先 - 体制図 2. 業務管理報告書（Redmineから出力できれば各種それ） - スケジュール状況 - 課題管理状況 - 仕様変更一覧 - 外部システム変更申請 3. コミュニケーションドキュメント - 議事録 - 外部システムQA 4. 設計書・テスト - 画面設計書 - DB定義書 - 機能テスト - 負荷試験 - セキュリティ試験 5. システム一式 - ソースコードまたはgit納品 - デプロイスクリプトまたはgit納品 6. インフラ情報 - インフラ構成 - pemなどssh秘密鍵 7. 操作説明書（要求された場合） 8. システム保守運用説明書（要求された場合） 工程と工数と工期の目安 項目 |業要|シ要|基本|詳細|実装|単テ|結テ|シテ|運テ --------|----|----|----|----|----|----|----|----|---- 工数比 | 4%| 6%| 15%| 15%| 21%| 14%| 15%| 10%|- 工期比 | 8%| 12%| 15%| 15%| 15%| 10%| 15%| 10%|- 人月速度| 30| 20| -| 4| -| 3.5| 8| 12|- - 目安 ```text 全体工数、全体費用 : 要件定義工数 * 10 1次受けで要件定義までで撤退する場合の請求額 : 10%（SE単価 > 製造単価なので少し赤字） 1次受けで基本設計までで撤退する場合の請求額 : 25%（SE単価 > 製造単価なので少し赤字） 2次受けで詳細設計～ITa まで請け負う場合の請求額 : 75%（適正は65%だが、コミュニケーションロス等で75%とする） ``` 守るべき割合 ```text - 業務要件+システム要件を10倍すると全体工数になる - 工数の20%以上は、業務要件～基本設計に割く - 工期の30%以上は、業務要件～基本設計に割く ``` 人日工数クラスサンプル class|要件|設計| 実単| 結テ|シテ|運テ|合計|備考 -----|----|----|-----|-----|----|----|----|----- S | 3| 9| 10.5| 4.5| 3|- | 30|極めてな複雑な機能※1※2 A | 2| 6| 7| 3| 2|- | 20|複雑な機能 B | 1.5| 4.5| 6.0| 2.5| 1.5|- | 16|典型的なトランザクションデータ画面。切り上げ C | 1| 3| 3.5| 1.5| 1|- | 10|子テーブルのない単純なマスタ画面、一般的な改修 D |0.25|0.75|0.875|0.375|0.25|- | 2.5|改修時：軽微な回収 E | 0| 0| 0.2| 0.2| 0|- | 0.4|改修時：リンクや固定文言の変更 - ※1 ほとんどの場合は適切に機能分解できてないため、項目を分解すること ※2 開発時のマイルストーンやイテレーションにも影響するため、項目を分解すること ________________________________________ ### 2.2. 営業ヒアリングから契約締結 営業ヒアリング 内容 |~1000万|1000万~|4000万~ -------------------------------|-------|-------|------- 提案依頼書（先方が作る） |○ |○ |○ 概算見積 |○ |○ |○ 要望一覧 |○ |○ |○ 提案書 |○ |○ |○ 見積書 |○ |○ |○ マスタスケジュール |○ |○ |○ 実施体制図 |○ |○ |○ システム概要 |○ |○ |○ - 補足 ```text クライアント＝決裁者がその人から買いたいと思うか？（決裁者＋自己開示＋共感） 1. ヒアリング訪問2時間 * 2回まで無料。資料の別会社への使いまわし、アイミツ相談もござれ 2. ヒアリング訪問3回目以降から、手数料1回1万円（営業判断で契約締結時の営業費に回してもOK） 3. 営業が直接部門（工費に含まれない）なら、営業費として工費見積金額の2％を見積を追加すること ``` 契約書類 内容 |~1000万|1000万~|4000万~ -------------------------------|-------|-------|------- 基本契約書 |○ |○ |○ NDA |○ |○ |○ 個別発注書 |○ |○ |○ - ________________________________________ ### 2.3. キックオフ プロジェクト計画書 内容 |~1000万|1000万~|4000万~ -------------------------------|-------|-------|------- プロジェクト計画書本体 *1 |簡易 |○ |○ ＿変更履歴 |簡易 |○ |○ ＿目次 |○ |○ |○ ＿I プロジェクト概要 |簡易 |○ |○ ＿＿1. プロジェクトの基本方針 |○ |○ |○ ＿＿＿プロジェクトの目的 *2 |○ |○ |○ ＿＿＿QCD優先順位 |○ |○ |○ ＿＿＿納期目標 |○ |○ |○ ＿＿＿品質目標 |○ |○ |○ ＿＿2. 体制 |別紙 |別紙 |別紙 ＿＿3. システムの概要 |別紙 |別紙 |別紙 ＿＿4. 工程定義 |○ |○ |○ ＿＿＿マスタスケジュール |別紙 |別紙 |別紙 ＿＿＿工程定義 *3 |○ |○ |○ ＿＿＿顧客責任タスク *4 |○ |○ |○ ＿＿＿開発会社責任タスク *5 |○ |○ |○ ＿＿5. 要件 |○ |○ |○ ＿＿＿業務要件 |○ |○ |○ ＿＿＿その他の要件 |別紙 |別紙 |別紙 ＿＿6. 契約情報 |簡易 |簡易 |○ ＿＿＿協力会社担当業務 |ー |ー |○ ＿＿＿個別計画書要否 |ー |ー |○ ＿＿＿成果物一覧 |○ |○ |○ ＿＿＿納品方法 |○ |○ |○ ＿＿＿検収方法 |○ |○ |○ ＿＿＿検収観点 |○ |○ |○ ＿＿7. 納品後の対応 |○ |○ |○ ＿II 運営 |簡易 |○ |○ ＿＿1. コミュニケーション管理 |○ |○ |○ ＿＿＿連絡窓口 |○ |○ |○ ＿＿＿ファイル連携ルール |○ |○ |○ ＿＿＿メールルール |○ |○ |○ ＿＿＿会議体 |○ |○ |○ ＿＿＿議事録作成ルール |○ |○ |○ ＿＿＿会議運営ルール |○ |○ |○ ＿＿＿QA管理方法 |○ |○ |○ ＿＿2. プロジェクト変更管理 |ー |ー |○ ＿＿＿基本方針 |ー |ー |○ ＿＿＿プロジェクト変更の定義 |ー |ー |○ ＿＿＿管理方法 |ー |ー |○ ＿＿＿運営方針 |ー |ー |○ ＿＿3. 仕様変更管理 |○ |○ |○ ＿＿＿基本方針 |○ |○ |○ ＿＿＿仕様変更の定義 |○ |○ |○ ＿＿＿管理方法 |○ |○ |○ ＿＿＿運営方針 |○ |○ |○ ＿＿4. リスクの管理 |ー |ー |○ ＿＿＿基本方針 |ー |ー |○ ＿＿＿リスク定義 |ー |ー |○ ＿＿＿管理方法 |ー |ー |○ ＿＿＿運営方針 |ー |ー |○ ＿＿5. 課題の管理 |○ |○ |○ ＿＿＿基本方針 |○ |○ |○ ＿＿＿課題の定義 |○ |○ |○ ＿＿＿管理方法 |○ |○ |○ ＿＿＿運営方針 |○ |○ |○ ＿＿6. 定量による進捗管理 |ー |簡易 |○ ＿＿＿基本方針 |ー |○ |○ ＿＿＿WBSとRedmineの運用 |ー |簡易 |○ ＿＿＿WBS策定方法 |ー |簡易 |○ ＿＿＿進捗報告 |ー |○ |○ ＿＿＿計画変更ルール |ー |簡易 |○ ＿＿7. レビューによる品質管理 |ー |簡易 |○ ＿＿＿基本方針 |ー |○ |○ ＿＿＿品質目標の決め方 |ー |簡易 |○ ＿＿＿品質評価の算出 |ー |簡易 |○ ＿＿＿成果物レビュー実施方針 |ー |○ |○ ＿＿8. 不具合管理 |簡易 |簡易 |○ ＿＿＿基本方針 |○ |○ |○ ＿＿＿管理方法 |簡易 |簡易 |○ ＿＿＿対応フロー |簡易 |簡易 |○ ＿＿9. 工程開始終了基準管理 |ー |ー |○ ＿＿＿基本方針 |ー |ー |○ ＿＿＿基準の決め方とサイクル |ー |ー |○ マスタスケジュール |簡易 |○ |○ 体制図および緊急連絡先 |○ |○ |○ システム概要フロー |○ |○ |○ プロジェクト成果物一覧 |○ |○ |○ 文書ファイル命名規約 |ー |ー |○ フォーマット：ステコミ報告書 |ー |ー |○ フォーマット：週次進捗集計表 |ー |ー |○ フォーマット：工程基準一覧 |簡易 |簡易 |○ フォーマット：議事録 |簡易 |簡易 |○ RFP |簡易 |簡易 |○ - ```text *1 本紙は番号ごとに1ページずつ計16ページ、各別紙はA4用紙1枚を目安 *2 プロジェクトの目的は、改善・革新したい事を4点以内で明確にする *3 V字モデル or 反復モデルの各工程の意味や方針をクライアントに理解してもらう *4 顧客がやらなければならないことがあることを理解してもらう *5 開発会社が何をやり何をしないのかを理解してもらう ``` ________________________________________ ### 2.4. 要件定義 業務要件定義/システム要件定義：成果物一覧 内容 |~1000万|1000万~|4000万~|目的または備考 -------------------------------|-------|-------|-------|------------------------ 業務フロー図 |○ |○ |○ |顧客に作ってもらう 機能要件記述書およびMOCK |簡易 |簡易 |○ |画面orバッチ単位で列挙 ＿＿概念エンティティ |簡易 |簡易 |○ |ー ＿＿プロセス定義書 |ー |ー |○ |機能フロー図 システム概要フロー |ー |ー |○ |サブシステムの関係を図示 機能一覧 |簡易 |○ |○ |ー 外部IF一覧 |簡易 |○ |○ |ー 画面設計標準フォーマット |ー |○ |○ |ー 方式設計書 |簡易 |○ |○ |ー 業務統一用語一覧 |ー |ー |○ |ー - 要件定義チェックリスト ```text [機能要求] - システムへの入力が、入力元、精度、範囲、頻度を含め、要件が明記されているか - システムからの出力が、出力先、精度、範囲、頻度を含め、要件が明記されているか - Webページやレポートなどの出力形式が明記されているか - 外部とのハードウェア・ソフトウェアインターフェースがすべて明記されているか - 外部通信インターフェースが、ハンドシェイク、エラーチェック、通信プロトコル含めすべて明記されているか - ユーザーが実行したいと考えているタスクがすべて明記されているか - 各タスクで使用するデータと各タスクで生じるデータがすべて明記されているか [非機能要求] - 応答時間要求は明記されているか - 処理時間、データ転送速度、システムスループットなど、時間に関するその他検討事項が明記されているか - セキュリティレベルが明記されているか - ソフトウェア障害の影響、障害から保護するクリティカルデータ、エラーの検出と回復手順といった信頼性が明記されているか - 最低限必要なメモリとディスク空き容量が明記されているか - 機能変更、インターフェース変更に対する保守性の扱いが明記されているか - 様々なレベルでの成功、失敗の基準は明記されているか [要求の品質] - 要求はユーザーの言葉で書かれているか。ユーザーが理解できているか - 要求の矛盾を解決できているか - 競合する要求の妥協点が明記されているか - 要求は要求であるか。設計に踏み込んでいないか - 要件定義書を全く別の会社に渡しても、伝わるか - 全ての要求は、課題と解決策の両方に紐づいているか（課題の解決策が要求や設計になるため） - 各要求をテストする手順（システムテスト）が想定できているか - 要件変更が起きる可能性が高そうな部分が列挙されているか - 要求は妥当なものか ``` ________________________________________ ### 2.5. 基本設計 内容 |~1000万|1000万~|4000万~|目的または備考 -------------------------------|-------|-------|-------|------------------------------- 画面設計書 |簡易 |○ |○ |ー 帳票設計書 |簡易 |○ |○ |ー バッチ設計書 |簡易 |○ |○ |ー 外部IF設計書 |簡易 |○ |○ |ー プロセス定義書 |ー |ー |○ |要件定義と同一 システム関連図 |ー |ー |ー |システム概要フローとほぼ同じ 画面遷移図 |簡易 |簡易 |○ |ー コード定義書 |簡易 |○ |○ |ー メッセージ定義書 |ー |簡易 |○ |ー バッチジョブ定義書 |簡易 |簡易 |○ |ジョブ一覧、ジョブフロー含む テーブル定義書 |○ |○ |○ |ER図、テーブル一一覧含む 概念ERデータフロー図 |ー |簡易 |○ |概念ERのCRUDを明確化 テスト・教育計画書 |ー |簡易 |○ |合格基準やテスト範囲の定義等*1 - ```text *1 実際のユーザー、システム、結合、単体の各テストケースは次の工程以降で作る ``` 基本設計のチェックリスト ```text - 方式設計は定められているか - #08. Coding を参照のこと - 事前に行う設計とコーディングしながら設計する内容の切り分けは明確か？ - コーディング規約またはサンプルはあるか - アーキテクチャに対応するコーディングプラクティスはあるか？ - エラー処理 - セキュリティ対策 - レイヤー設計 - API設計 - DRY - パフォーマンス考慮度合い - コミットからマージまでの手順は合理的かつ守られているか？ - tddか、単体テストは書くのか、書かないのか？ - クロスレビューを徹底するか？ - 環境類 - 言語 - バージョン管理 - フレームワーク - 非標準ライブラリ、有料ライブラリはどこまで使い、許容するか？ - エディタ、デバッガ、テストランナー、構文チェッカー等、導入は行えているか？ ``` 画面設計書の要素（トランザクションスクリプト形式） 要素 |要件|基本|詳細|別名 ---------------------|----|----|----|-------------------------------- （画面遷移図） |○ |- |- |ウィンドウ設計_1 ※ サブシステム毎に1つあればよい 画面イメージ&処理概要|○ |- |- |ウィンドウ設計_2、画面レイアウト&処理概要 画面項目一覧 |- |○ |- |ウィンドウ部品設計、画面項目仕様 イベント一覧 |- |○ |- |イベント設計 バリデーション一覧 |- |○ |- |チェック仕様 処理 |- |△ |○ |処理設計、画面処理仕様の処理部、in-process-out-result クエリ |- |△ |○ |IOデータ項目設計、画面処理仕様のクエリ部 SQL |- |- |○ |SQL モード（新規/編集）等がある場合は、必要に応じて分ける ________________________________________ ### 2.6. 詳細設計～ユーザーテストでの納品物 内容 |~1000万|1000万~|4000万~|略称|目的または備考 -------------------------------|-------|-------|-------|----|------------------------------- 業務シナリオ（全体） |ー |簡易 |○ |ー |業務フローの最新版。業務フローとシステムを明確化する 業務シナリオ（サブシステム）　 |ー |簡易 |○ |ー |業務フローの最新版。業務フローとシステムを明確化する 業務シナリオ（個別） |ー |簡易 |○ |ー |業務フローの最新版。業務フローとシステムを明確化する ソース一式 |○ |○ |○ |ー |ー インフラ情報 |○ |○ |○ |ー |ー 詳細設計書 |ー |ー |ー |ー |原則として納品対象としない 単体テスト設計書 |ー |ー |ー |UT |原則として納品対象としない。SQLテストやUnitTest 単体テスト結果 |ー |ー |ー |ー |原則として納品対象としない 画面（バッチ）間テスト設計書 |○ |○ |○ |ITa |画面設計書に対する対 画面（バッチ）間テスト結果 |○ |○ |○ |ー |ー サブシステム間テスト設計書 |ー |簡易 |○ |ITb |業務シナリオ（個別、サブシステム）に対する対 サブシステム間テスト結果 |ー |簡易 |○ |ー |ー システムテスト設計書 |ー |ー |○ |ST |業務シナリオ（全体）に対する対 システムテスト結果 |ー |ー |○ |ー |ー 負荷試験テスト設計書 |簡易 |簡易 |○ |ー |ー 負荷試験テスト結果 |簡易 |簡易 |○ |ー |ー セキュリティテスト設計書 |簡易 |簡易 |○ |ー |ー セキュリティテスト結果 |簡易 |簡易 |○ |ー |ー 操作説明書 |※ |※ |※ |ー |しっかりとしたのを要求される場合、別工数・別金額 システム保守運用マニュアル |※ |※ |※ |ー |しっかりとしたのを要求される場合、別工数・別金額 - ________________________________________ ## 3. Test ________________________________________ ### 3.1. 各テストフェーズの目的を決めるということ 1. そのテストの目的・観点（どういうレベルの内容を確認したいのか） 2. 網羅性の担保（網羅列挙するための元ネタ資料はどれだった） ________________________________________ ### 3.2. 典型的なWebシステムの観点 レベル |略称|対 |観点 ----------|----|----|--------------------------------------------------------------- 費用対効果|ー |プ計|費用対効果は良いか。コンサルが確認 ユーザー |UAT |業要|テスト運用できるか。顧客自身が原則確認 システム |ST |シ要|要件定義の内容を満たせているか 外部結合 |ITb |基本|サブシステムや他システム間テスト 内部結合 |ITa |基本|画面間テスト、サブシステム内テスト 単体 |UT |詳細|ユニットテスト。SQL、ビジネスロジック - ※ サブシステム同士を疎結合（複数サブシステムテーブルの最小化）が重要 単体テストが保証すること、しないこと - 保証すること 1. ビジネスロジック（個々の表示条件やバリデーション判定）が仕様通りか 2. CRUD内容が仕様通りか - 保証しないこと 1. 他の画面にCRUDされたデータを読み込む内容が、この画面の求める仕様通りか 2. 他の画面がCRUDするデータの書きこんだ内容が、他の画面が求める仕様通りか ITaやITbが保証すること、しないこと - 保証すること 1. (ITa)マスタやサブシステム内の別画面によるCRUD内容が、その画面で仕様通りに読まれるか 2. (ITb)上記をサブシステムを跨いだ画面で検証する - 保証しないこと 1. 要件通りである事 2. 業務シナリオを満たせること（ただし実際には検出を前倒し、ITbで検証する） システムテストが保証すること、しないこと - 保証すること 1. システム要件定義の要件を満たせているか 2. 業務シナリオ通りに動かすことができるか - 保証しないこと 1. 業務要件定義の要件を満たせているか（ただし実際には検出を前倒し、STで検証する） 2. 費用対効果の面から利益が出るか