演習課題第1章
21
0
0
全文
(2) 1.1演習の進め方 1.1.1状況設定 学習者は4~6名で1つのプロジェクトチームを構成します。プロジェクトチームは、別個のソフトウェア開発会 社に属す設定です。各ソフトウェア開発会社は、お客様より受注した「DVDレンタルシステム」のソフトウェアを 開発します。お客様からの情報は「2章課題仕様書」を参照します。 なお、2章にも記述されていますが、今回の開発は、全体のシステムのうち一部分になります。作業対象は、ソ フトウェアコード以外は、所定のエクセルファイルの、ワークシートタブが赤いものとなります。対象ワークシート の吹き出しを参考に、穴埋めでドキュメントを作成してください。. 1.1.2作業の手順 演習は以下の手順で作業を進めます。 各作業はプロジェクトチーム単位で作業を進めてください。 プロジェクト発足 課題システムを開発するためのプロジェクトを発足します。 架空の会社名、プロジェクトチーム名および、プロジェクト内での役割を決めます。 システム開発 お客様からの情報を読み取り、必要に応じてお客様にヒアリングを行い、システム開発を行います。 演習では、以下の工程を実施します。 •ソフトウェア要求分析 •ソフトウェア要件定義 •ソフトウェア方式設計 •ソフトウェア詳細設計 •ソフトウェアコードの作成およびソフトウェアユニットテスト •ソフトウェア結合およびソフトウェア結合テスト •ソフトウェア適格性確認テスト システム納品 作成したシステムとドキュメントをまとめ、お客様に納品します。. 1.1.3講師の役割 演習では、講師は課題システムの発注元である「お客様」および架空のソフトウェア開発会社内プロジェクト チームの「上司」の役割を担います。講師と接する際は、どの役割に対してなのかを意識してコミュニケーショ ンしてください。. Copyright 2012 IPA All Rights Reserved. 2.
(3) 1.1.4標準的なスケジュール 標準的なスケジュールを以下に示します。ただし、講義の進め方によって説明や演習の順序が前後すること もありますので、講師の指示に従って進めてください。. フェーズ. 1. 2. 3. 4. 5. ソフトウェア 要件定義. プロジェクト 発足. ソフトウェア 要求分析. ソフトウェア 要件定義1. ソフトウェア 要件定義2. ソフトウェア 要件定義 レビュー. フェーズ. 6. 7. 8. 9. 10. ソフトウェア 設計. ソフトウェア 方式設計1. ソフトウェア 方式設計2. ソフトウェア 詳細設計1. ソフトウェア 詳細設計2. ソフトウェア 設計レビュー. フェーズ. 11. 12. 13. 14. 15. 実装・テスト・ 評価. コード作成 および ユニットテスト. 結合 および 結合テスト. 適格性確認 テスト. レビュー および 納品. 1.1.5コミュニケーション プロジェクトの進捗状況や発生した問題についての情報を共有するために、定期的にプロジェクトチーム内お よび上司などの関係者とコミュニケーションをとってください。 典型的な例として、毎朝の作業開始前に定例会を行い、その結果について上司に報告する方法が一般的で す。 作業の進捗に遅延が発生した、または発生しそうな場合など、何らかの問題が発生した場合は、「問題点管 理票」に記入し、プロジェクトチーム内で対策を検討します。. 1.1.6ワークシート ワークシートにはファイル名の先頭に記号と番号が付いています。これらの意味は D:開発用(作成済み) X_D:開発用(作成対象) M:管理用 P:提供 となります。開発用ドキュメントのX_D記号が付いているものが主な作業対象になります。作成済みのドキュメ ントを参考にしながら、作成対象の作業を進めてください。 なお、管理用ドキュメントは記入例が書かれていますので、それを参考に記述してください。. Copyright 2012 IPA All Rights Reserved. 3.
(4) 1.2プロジェクト発足 1.2.1プロジェクト体制の決定 課題システムの開発は、架空のソフトウェア開発会社名、プロジェクトチーム名、およびプロジェクト内の役割 を決めて運営します。決定した体制は、「プロジェクト体制図」を作成し、管理用ドキュメントとします。. 1.2.2作業対象ファイル •M1プロジェクト体制図.xls •M2スケジュール表.xls •M3プロジェクト予算実績計算書.xls. 1.2.3プロジェクト内の役割 プロジェクト内では各自が以下の役割を分担します。チームの人数に応じて、分担を割り振ります。 プロジェクトリーダー、プロジェクトサブリーダー プロジェクトリーダーの主な役割は、定められた期間と予算内で、課題システムを納品できるようプロジェク ト運営を管理することです。サブリーダーも同様の観点からプロジェクトリーダーを補佐していきます。 これらの役割を認識して、以下の作業を行っていきます。 •発注元との交渉 •上司への報告 •プロジェクトの目標管理 •定例会の開催 テクニカルリーダー、テクニカルサブリーダー テクニカルリーダーの主な役割は、技術的な課題について、プロジェクト内で解決できるよう調査や実現性 の検討を行うことです。サブリーダーも同様の観点からテクニカルリーダーを補佐していきます。これらの役 割を認識して、以下の作業を行っていきます。 •他メンバーの技術フォロー •勉強会の開催 •作業の割り振り ライブラリリーダー、ライブラリサブリーダー ライブラリリーダーの主な役割は、作成したドキュメントやソフトウェアコードを、管理することです。ドキュメ ントの版数管理や、保管場所の一元管理を行い、必要なドキュメントの紛失などを防ぎます。サブリーダー も同様の観点から、ライブラリリーダーを補佐していきます。これらの役割を認識して、以下の作業を行って いきます。 •ドキュメントの版数管理 •ドキュメント化の推進 •ソフトウェアコードの版数管理 •作業の割り振り. Copyright 2012 IPA All Rights Reserved. 4.
(5) 1.2.4プロジェクト体制図の作成 開発プロジェクトの組織体制を明確にするために、「プロジェクト体制図」を作成します。 プロジェクトを円滑に推進するために、システム開発にかかわる要員の体制を明確にします。 お客様側の体制と、メーカー側の体制を明確にします。. 1.2.5スケジュール表の作成 スケジュールの進捗状況を管理するために、「スケジュール表」を作成します。 開発工程を単位として、各工程の開始と完了の予定を記入します。 できる限り各作業の規模を明確にし、その作業に必要な時間と体制を考慮して決めます。. 1.2.6プロジェクト予算・実績計算書の作成 システム開発にかかる費用を管理するために「プロジェクト予算・実績計算書」を作成します。 予算内でプロジェクト活動を行うために、システムエンジニア人件費やプログラマー人件費、コンピュータ利用 費や出張費など、詳細な項目単位で管理していきます。. Copyright 2012 IPA All Rights Reserved. 5.
(6) 1.3ソフトウェア要求分析 1.3.1作業概要 お客様からの情報「2.1お客様情報」をもとに、お客様からのソフトウェアに対するニーズを確認します。ニーズ はあいまいな部分を含んでいるため、必要に応じてお客様へのヒアリングを行うなどして、お客様が求めてい るニーズの見落としや、思い込みによる暗黙的なニーズなどを明確にしていきます。. 1.3.2作業対象ファイル •X_D1ニーズ概要.xls •M7連絡票.xls. 1.3.3ソフトウェアに対するニーズの確認 お客様が情報システムに対してどのような価値、思い、夢を抱いているのかを明確にします。そのうち、ソフト ウェアで実現できる部分を抽出します。ニーズを明らかにすることで、次のプロセスであるソフトウェア要件定義 の入力情報としていきます。. 1.3.4ニーズ概要の作成 「ニーズ概要」を作成します。. 1.3.4.1作業手順 •お客様とアポイントメントをとり、ヒアリングの場を設定する。 •お客様からの情報「第2章 演習課題仕様書」を読み込む。 •不明瞭な点や、暗黙的なニーズを抽出する。 •お客様にヒアリングを行い、不明瞭な点や暗黙的な「ニーズ概要」を作成する。. お客様との連絡について お客様との連絡手段としては、実際の現場では電話やメールを使うことになりますが、演習では、管理 用ドキュメント「連絡票」を使用します。事前にアポイントメントを取ってから、お客様先に伺います。. Copyright 2012 IPA All Rights Reserved. 6.
(7) 1.4ソフトウェア要件定義1 1.4.1作業概要 お客様のニーズを十分に抽出した後に、ソフトウェアとして実現するための要件を明確にしていきます。この 工程で、あいまいなニーズを、合否を判断することができる要件として定義していきます。要件にはソフトウェア として本質的に実現しなくてはならない機能と、使いやすさ、性能、保守のしやすさ、誤動作の起こりにくさな どに関する機能以外の非機能と分けて明確にしていきます。. 1.4.2作業対象ファイル •X_D2機能要件リスト.xls •X_D3非機能要件リスト.xls •X_D4用語辞書.xls. 1.4.3機能要件リストの作成 ソフトウェアとしての機能を明確にし、機能要件リストを作成します。. 1.4.3.1作業手順 •ソフトウェアで実現する、機能を抽出します。 •抽出した機能の抽象度の粒度を検討し、本質的な機能を定義します。 •各機能が実現できているか判断する基準を定めます。. 1.4.4非機能要件リストの作成 ソフトウェアとしての非機能を明確にし、非機能要件リストを作成します。. 1.4.4.1作業手順 •使いやすさ、性能、保守のしやすさ、誤動作の起こりにくさ、などの観点から、求められる要件を抽出します。 •抽出した要件が実現できているか判断する基準を定めます。. 1.4.5用語辞書の作成 機能要件リストなどドキュメントに使われる用語について、定義を明確にするために用語辞書を作成します。. 1.4.5.1作業手順 •機能要件リストの用語で、判断に迷う語句や、似たような用語で表現できる用語について、抽出します。 •抽出した用語について、厳密に意味を定義します。 •新たなドキュメントを作成するたびに、用語辞書に追記、修正の保守作業を行います。. Copyright 2012 IPA All Rights Reserved. 7.
(8) 1.5ソフトウェア要件定義2 1.5.1作業概要 お客様のニーズを実現するために、システムとお客様のインターフェースとなる部分についての要件を明確に します。また、ここまでに定義した要件についての確認のための条件と判断基準を明確にした、テスト仕様書 を作成します。. 1.5.2作業対象ファイル •X_D5画面一覧.xls •X_D6ソフトウェア適格性確認テスト仕様書兼成績書.xls 参考提供ドキュメント •P6品質管理計画書.xls. 1.5.3画面一覧の作成 システムとお客様のインターフェースとなる部分の一つとして、画面イメージの概要を示す一覧を作成します。. 1.5.3.1作業手順 •本質的な機能を実現するために、通常使用時の入出力情報を検討します。 •ユーザーインターフェースとして、必要となる画面概略を検討します。 •機能ごとに繰り返し、画面の一覧を作成します。. 1.5.4ソフトウェア適格性確認テスト仕様書の作成 ここまでに定義した要件についての確認のための条件と、判断基準を明確にし、ソフトウェア適格性確認テス ト仕様書を作成します。. 1.5.4.1作業手順 機能要件リストの項目ごとに、定義した内容が確認できる条件と、判断基準を検討します。 非機能要件リストの項目ごとに、定義した内容が確認できる条件と、判断基準を検討します。. Copyright 2012 IPA All Rights Reserved. 8.
(9) 1.6ソフトウェア要件定義レビュー 1.6.1作業概要 ソフトウェア要件定義で作成した成果物をレビューします。プロジェクトチーム内でレビューを行った後、お客 様と共同レビューを行い、定義したソフトウェア要件がお客様の要件を満たしているか確認します。. 1.6.2作業対象ファイル •X_D1ニーズ概要.xls •X_D2機能要件リスト.xls •X_D3非機能要件リスト.xls •X_D4用語辞書.xls •X_D5画面一覧.xls •X_D6ソフトウェア適格性確認テスト仕様書兼成績書.xls •M4レビュー報告書.xls •M7連絡票.xls •P6品質管理計画書.xls. 1.6.3ソフトウェア要件定義フェーズでの各成果物のレビュー ソフトウェア要件定義フェーズで作成した成果物について、チーム内でレビューを行います。. 1.6.3.1作業手順 •作成した成果物について、上流工程への追跡は可能か確認します。 •上流工程との一貫性は保たれているか確認します。 •内部での表現に一貫性は保たれているか確認します。 •テスト仕様書を設計するに当たって、条件や判断基準が適切に設定できるか確認します。. 1.6.4ソフトウェア要件の共同レビューの実施 お客様と共同レビューを実施し、ソフトウェア要件定義に抜け漏れや誤解がないか確認します。. 1.6.4.1作業手順 •お客様とアポイントメントをとり、レビューの場を設定する。 •ソフトウェア要件のプロジェクトチーム内でのレビューを行います。 •「レビュー報告書」にレビュー結果を記録し、対応方法などについて検討します。 •お客様先にて共同レビューを行い、ソフトウェア要件定義に抜け漏れや誤解がないか確認し合意します。. Copyright 2012 IPA All Rights Reserved. 9.
(10) 1.7ソフトウェア方式設計 1.7.1作業概要 ソフトウェア方式設計では、ソフトウェア品目ごとにソフトウェアコンポーネントの構成や、画面の遷移、画面レイ アウトの設計を行います。. 1.7.2作業対象ファイル •X_D7画面遷移図.xls •X_D8画面レイアウト.xls •X_D9DFD0.xls •X_D10ソフトウェア結合テスト仕様書兼成績書.xls 参考提供ドキュメント •P6品質管理計画書.xls. 1.7.3画面遷移図の作成 ソフトウェア要件定義で分析した、「画面一覧」を入力情報として、画面の遷移について設計します。. 1.7.3.1作業手順 •「画面一覧」からメニュー画面をグループ分けします。 •グループごとにどのように画面が移り変わっていくか検討します。 •同様に、「画面一覧」から出力情報の画面をグループ分けし、画面の移り変わりを検討します。. Copyright 2012 IPA All Rights Reserved. 10.
(11) 1.7.4画面レイアウトの作成 ソフトウェア要件定義で分析した、「画面一覧」を入力情報として、画面のレイアウト詳細について設計します。. 1.7.4.1作業手順 各画面で必要とされる入出力情報を確認します。 入出力情報をどのように表現するかを検討し、画面ごとにレイアウトを作成します。. 1.7.5DFD0の作成 要件定義で分析した本質的な機能でソフトウェアを分割し、それぞれをソフトウェアコンポーネントとして割り当 てます。. 1.7.5.1作業手順 •要件定義で分析した機能でソフトウェアコンポーネントに割り当てます。 •ソフトウェアコンポーネント間でのデータがどのように取り扱われていくかを検討します。. 1.7.6ソフトウェア結合テスト仕様書の作成 ソフトウェア方式設計のドキュメントから、ソフトウェア結合のためのテスト要求事項を定義し、ソフトウェア結合 テスト仕様書を設計します。. 1.7.6.1作業手順 •画面レイアウト、画面遷移図、DFD0を入力情報として、ソフトウェア結合のテスト仕様を設計します。 •テスト内容、テストデータ(条件)、期待値を明確にし、テスト仕様書に記入します。. Copyright 2012 IPA All Rights Reserved. 11.
(12) 1.8ソフトウェア詳細設計 1.8.1作業概要 ソフトウェア要件をソフトウェアコンポーネントからソフトウェアユニットに割り振ります。. 1.8.2作業対象ファイル •X_D11DFD.xls •X_D12プログラム概要.xls •X_D13モジュール構造図.xls •X_D14ソフトウェアユニット機能設計書(menu).xls •X_D14ソフトウェアユニット機能設計書(member).xls •X_D15詳細処理設計書(menu).xls •X_D15詳細処理設計書(member).xls •X_D17ソフトウェアユニットテスト仕様書兼成績書(menu).xls •X_D17ソフトウェアユニットテスト仕様書兼成績書(member).xls •X_D18関数一覧.xls 参考提供ドキュメント •P1命名規約.xls •P3レコードレイアウト.xls •P6品質管理計画書.xls. 1.8.3DFDの作成 ソフトウェアコンポーネントをさらに分割し、詳細化していきます。DFD0の各プロセスをSTS分析の手法などを 検討し、より具体的な実現方法を検討します。. 1.8.3.1作業手順 •DFD0の各プロセス内での処理をSTS分析などの手法を用いて分割します。 •分割後のプロセスの粒度が、同程度になるよう注意します。 •分割したプロセス間でのデータのやり取りについて検討します。 •分割したプロセスでの処理ができるだけ単機能になるまで分割を続けます。. 1.8.4プログラム概要の作成 ソフトウェアコンポーネントごとに、入出力データ項目を明確にし、ソフトウェアコンポーネントの処理概要を明 確にします。使用するファイルも確定します。. 1.8.4.1作業手順 •概要図に入出力の関連を記述します。 •処理概要を検討し、機能を十分に洗い出します。 •使用するファイルがあれば、そのファイルも確定します。. Copyright 2012 IPA All Rights Reserved. 12.
(13) 1.8.5モジュール構造図の作成 DFDで詳細化したソフトウェアユニットの、呼び出し関係を検討し、モジュール構造図を作成します。 上下(論理ー物理)、左右(入力ー出力)の関係も考慮して呼び出し関係を構成します。. 1.8.5.1作業手順 •DFDを合成します。 •ソフトウェアユニット間の呼出関係を図式化します。 •本質的な機能を実現する論理的なソフトウェアユニットを上位に配置します。 •それぞれの呼出関係で結合度や凝集度を検討します。. 1.8.6ソフトウェアユニット機能設計書の作成 ソフトウェアユニット内の処理と制御条件を明確にして、詳細処理手順を明確にするために、ソフトウェアユ ニット機能設計書を作成します。. 1.8.6.1作業手順 •ソフトウェアユニットの機能を確認するために、大まかな処理の手順を記述します。 •全体を大まかに考えて、段階的に詳細な処理を考えるようにします。. Copyright 2012 IPA All Rights Reserved. 13.
(14) 1.8.7詳細処理設計書の作成 ソフトウェアユニット内の処理単位に詳細な処理手順を記述します。. 1.8.7.1作業手順 •関数の名称を命名規約に基づいて設計します。 •引数の型と種類について設計します。 •戻り値の型と内容について設計します。 •ソフトウェア機能設計書に記述された大まかな処理を、個別の処理単位ごとに詳細な処理手順を記述します。. 1.8.8ソフトウェアユニットテスト仕様書の作成 ソフトウェア詳細設計のドキュメントから、ソフトウェアユニットのテスト要求事項を定義し、ソフトウェアユニットテ スト仕様書を設計します。 ここでは、ブラックボックステストだけではなく、詳細処理設計書からホワイトボックステストについても検討しま す。. 1.8.8.1作業手順 •ソフトウェアユニット機能設計書、詳細処理設計書を入力情報として、ソフトウェアユニットのテスト仕様を設計 します。 •テスト内容、テストデータ(条件)、期待値を明確にし、テスト仕様書に記入します。 •ホワイトボックステストではC1カバレッジの網羅性で設計します。. Copyright 2012 IPA All Rights Reserved. 14.
(15) 1.9ソフトウェア設計レビュー 1.9.1作業概要 ソフトウェア設計で作成した成果物をレビューします。プロジェクトチーム内でレビューを行った後、上司を含 めて共同レビューを行い、ソフトウェア要件定義の実現が可能であることを確認します。. 1.9.2作業対象ファイル •X_D7画面遷移図.xls •X_D8画面レイアウト.xls •X_D9DFD0.xls •X_D10ソフトウェア結合テスト仕様書兼成績書.xls •X_D11DFD.xls •X_D12プログラム概要.xls •X_D13モジュール構造図.xls •X_D14ソフトウェアユニット機能設計書(menu).xls •X_D14ソフトウェアユニット機能設計書(member).xls •X_D15詳細処理設計書(menu).xls •X_D15詳細処理設計書(member).xls •X_D17ソフトウェアユニットテスト仕様書兼成績書(menu).xls •X_D17ソフトウェアユニットテスト仕様書兼成績書(member).xls •X_D18関数一覧.xls •M4レビュー報告書.xls •P6品質管理計画書.xls. 1.9.3ソフトウェア設計フェーズでの各成果物のレビュー ソフトウェア設計フェーズで作成した成果物について、チーム内でレビューを行います。. 1.9.3.1作業手順 •作成した成果物について、上流工程への追跡は可能か確認します。 •上流工程との一貫性は保たれているか確認します。 •ソフトウェアコンポーネント間での表現に一貫性は保たれているか確認します。 •テスト仕様書を設計するに当たって、条件や判断基準が適切に設定できるか確認します。. 1.9.4ソフトウェア設計の共同レビューの実施 上司と共同レビューを実施し、ソフトウェア設計に抜け漏れや誤解がないか確認します。. 1.9.4.1作業手順 •上司とアポイントメントをとり、レビューの場を設定する。 •ソフトウェア要件のプロジェクトチーム内でのレビューを行います。 •「レビュー報告書」にレビュー結果を記録し、対応方法などについて検討します。 •共同レビューを行い、ソフトウェア設計に抜け漏れがないか確認し合意します。. Copyright 2012 IPA All Rights Reserved. 15.
(16) 1.10ソフトウェアコードの作成 1.10.1作業概要 ソフトウェアを構成する個々のソフトウェアユニットのソフトウェアコードをC言語で作成します。. 1.10.2作業対象ファイル •ソフトウェアコード(menu.c、menu.h、member.c、member.hなど) •X_D17ソフトウェアユニットテスト仕様書兼成績書(menu).xls •X_D17ソフトウェアユニットテスト仕様書兼成績書(member).xls •M4レビュー報告書.xls •M6不具合管理表.xls. 1.10.3ソフトウェアコードの作成 ソフトウェア詳細設計のドキュメントを入力情報として、ソフトウェアコードを作成します。. 1.10.3.1作業手順 •モジュール構造図、ソフトウェアユニット機能設計書、詳細処理設計書、関数機能設計書から、C言語でソフト ウェアコードを作成します。 •コーディング規約にのっとってソフトウェアコードを作成します。 •作成したソフトウェアコードは、コンパイルし文法上の誤りがあれば修正します。 •版数管理を適切に行います。. 1.10.3.2参考ドキュメントファイル •X_D13モジュール構造図.xls •X_D14ソフトウェアユニット機能設計書(menu).xls •X_D14ソフトウェアユニット機能設計書(member).xls •X_D15詳細処理設計書(menu).xls •X_D15詳細処理設計書(member).xls •D16関数機能設計書.xls •P5コーディング規約.xls. 1.10.4ソフトウェアコードの成果物レビュー ソフトウェアコードの自己レビュー、共同レビューを行います。. 1.10.4.1作業手順 自己レビューを徹底して行います。 自己レビュー完了後、他のメンバーにレビューを受けます。 レビュー記録を取ります。 レビューが完了するまで、テスト工程に進みません。. Copyright 2012 IPA All Rights Reserved. 16.
(17) 1.10.5ソフトウェアユニットテストの実施 ソフトウェアユニットテスト仕様書にのっとって、ソフトウェアユニットテストを実施します。. 1.10.5.1作業手順 •デバッグ用に戻り値の確認や、経路の確認のために必要な場所にprintf()などをソフトウェアコードに記述しま す。 •ソフトウェアユニットテスト仕様書の条件にそって、テストを実施します。 •テスト結果をソフトウェアユニットテスト成績書に記録します。 •不具合があった場合は、不具合管理票に記録し、対策を採ります。 記述例). if (target->next != NULL) { #ifdef DEBUF printf("R1¥n"); #endif /* 追加ノードのIDが小さいならば、ターゲットの後ろにノードを追加して終了する */ if (strncmp(new->id, target->next->id, MEMBER_ID_SIZE) < 0) { #ifdef DEBUF printf("R11¥n"); #endif new->next = target->next; target->next = new; break; }else { #ifdef DEBUF printf("R12¥n"); #endif target = target->next; /* ターゲットを更新して次のノードへ */ } } else { #ifdef DEBUF printf("R2¥n"); #endif /* 新しいノードをリストの末尾に追加して終了する */ new->next = NULL; target->next = new; break; }. Copyright 2012 IPA All Rights Reserved. 17.
(18) 1.11ソフトウェア結合 1.11.1作業概要 ソフトウェアを構成する個々のソフトウェアユニットを組み立て、設計した機能が実現できるかどうかを確認しま す。. 1.11.2作業対象ファイル •ソフトウェアコード(menu.c、menu.h、member.c、member.hなど) •X_D10ソフトウェア結合テスト仕様書兼成績書.xls •M6不具合管理表.xls. 1.11.3ソフトウェアの結合 コンパイルおよびリンクを実行し、各ソフトウェアユニットを結合します。. 1.11.3.1作業手順 •ソフトウェアユニットテストが完了したファイルから、デバッグ用に挿入したprintf()などを削除します。 •各ファイルをコンパイルおよびリンクし、ソフトウェアユニットを結合します。 •文法上の誤りがあれば修正します。 •版数管理を適切に行い、最新版ファイルの管理を注意します。. 1.11.4ソフトウェア結合テストの実施 ソフトウェア結合テスト仕様書にのっとって、ソフトウェア結合テストを実施します。. 1.11.4.1作業手順 •ソフトウェア結合テスト仕様書の条件にそって、テストを実施します。 •テスト結果をソフトウェア結合テスト成績書に記録します。 •不具合があった場合は、不具合管理票に記録し、対策を採ります。 •不具合を修正し、その不具合が解消されたかどうか、再テストで確認します。. Copyright 2012 IPA All Rights Reserved. 18.
(19) 1.12ソフトウェア適格性確認 1.12.1作業概要 完成したソフトウェアが定義した要件を満たしているか確認します。 結合テストで確認した機能が、お客様の要件を満たすかどうかの観点で確認します。. 1.12.2作業対象ファイル •ソフトウェアコード(menu.c、menu.h、member.c、member.hなど) •X_D6ソフトウェア適格性確認テスト仕様書兼成績書.xls •M6不具合管理表.xls. 1.12.3ソフトウェア適格性確認テストの実施 ソフトウェア適格性確認テスト仕様書にのっとって、ソフトウェア適格性確認テストを実施します。. 1.12.3.1作業手順 •ソフトウェア適格性確認テスト仕様書の条件にそって、テストを実施します。 •テスト結果をソフトウェア適格性確認テスト成績書に記録します。 •不具合があった場合は、不具合管理票に記録し、対策を採ります。 •不具合を修正し、その不具合が解消されたかどうか、再テストで確認します。. Copyright 2012 IPA All Rights Reserved. 19.
(20) 1.13テストレビュー 1.13.1作業概要 各テストの結果についてレビューを行い、品質を検証します。. 1.13.2作業対象ファイル •X_D17ソフトウェアユニットテスト仕様書兼成績書(menu).xls •X_D17ソフトウェアユニットテスト仕様書兼成績書(member).xls •X_D10ソフトウェア結合テスト仕様書兼成績書.xls •X_D6ソフトウェア適格性確認テスト仕様書兼成績書.xls •M6不具合管理表.xls •P6品質管理計画書.xls. 1.13.3テストフェーズでの各成果物のレビュー 各テスト工程での成果物である成績書をレビューします。テスト項目、不具合件数などを確認します。. Copyright 2012 IPA All Rights Reserved. 20.
(21) 1.14システム納品 1.14.1作業概要 お客様へのシステム納品に当たり、プロジェクトの成果物をまとめ、納品物として提出します。. 1.14.2作業手順 •以下に示す成果物をフォルダにまとめ、納品物とします。 1.ソフトウェア •. ソフトウェアコード. •. 実行形式ファイル. 2.ドキュメント一式 •. 管理用ワークシート. •. 開発用ワークシート. 1.14.3システムの納品 お客様からの指定時間までに、納品物をお客様に納品します。. Copyright 2012 IPA All Rights Reserved. 21.
(22)
関連したドキュメント
平成 21 年東京都告示第 1234 号別記第8号様式 検証結果報告書 A号様式 検証結果の詳細報告書(モニタリング計画).. B号様式
※各事業所が提出した地球温暖化対策計画書の平成28年度の排出実績が第二計画
計画断面 計画対象期間 策定期限 計画策定箇所 年間計画 第1~第2年度 毎年 10 月末日 系統運用部 月間計画 翌月,翌々月 毎月 1 日. 中央給電指令所
保管基準に従い、飛散、流出が起こらないように適切に保管 する。ASR 以外の残さ(SR
自動車環境管理計画書及び地球温暖化対策計 画書の対象事業者に対し、自動車の使用又は
処理処分の流れ図(図 1-1 及び図 1-2)の各項目の処理量は、産業廃棄物・特別管理産業廃 棄物処理計画実施状況報告書(平成
平成 28 年度は第2SC