Copyright 2012 IPA All Rights ReservedCopyright 2012 IPA All Rights Reserved 7 1.4ソフトウェア要件定義1 1.4.1作業概要お客様のニーズを十分に抽出した後に、ソフトウェア

1Copyright 2012 IPA All Rights Reserved


1.1演習の進め方

1.1.1状況設定

学習者は4～6名で1つのプロジェクトチームを構成します。プロジェクトチームは、別個のソフトウェア開発会社に属す設定です。各ソフトウェア開発会社は、お客様より受注した「DVDレンタルシステム」のソフトウェアを開発します。お客様からの情報は「2章課題仕様書」を参照します。

なお、2章にも記述されていますが、今回の開発は、全体のシステムのうち一部分になります。作業対象は、ソ

フトウェアコード以外は、所定のエクセルファイルの、ワークシートタブが赤いものとなります。対象ワークシートの吹き出しを参考に、穴埋めでドキュメントを作成してください。

1.1.2作業の手順

演習は以下の手順で作業を進めます。

各作業はプロジェクトチーム単位で作業を進めてください。

プロジェクト発足

課題システムを開発するためのプロジェクトを発足します。

架空の会社名、プロジェクトチーム名および、プロジェクト内での役割を決めます。

システム開発

お客様からの情報を読み取り、必要に応じてお客様にヒアリングを行い、システム開発を行います。

演習では、以下の工程を実施します。

•ソフトウェア要求分析

•ソフトウェア要件定義

•ソフトウェア方式設計

•ソフトウェア詳細設計

•ソフトウェアコードの作成およびソフトウェアユニットテスト

•ソフトウェア結合およびソフトウェア結合テスト

•ソフトウェア適格性確認テスト

システム納品

作成したシステムとドキュメントをまとめ、お客様に納品します。

1.1.3講師の役割

演習では、講師は課題システムの発注元である「お客様」および架空のソフトウェア開発会社内プロジェクトチームの「上司」の役割を担います。講師と接する際は、どの役割に対してなのかを意識してコミュニケーションしてください。


1.1.4標準的なスケジュール

標準的なスケジュールを以下に示します。ただし、講義の進め方によって説明や演習の順序が前後することもありますので、講師の指示に従って進めてください。

1.1.5コミュニケーション

プロジェクトの進捗状況や発生した問題についての情報を共有するために、定期的にプロジェクトチーム内および上司などの関係者とコミュニケーションをとってください。

典型的な例として、毎朝の作業開始前に定例会を行い、その結果について上司に報告する方法が一般的です。

作業の進捗に遅延が発生した、または発生しそうな場合など、何らかの問題が発生した場合は、「問題点管理票」に記入し、プロジェクトチーム内で対策を検討します。

1.1.6ワークシート

ワークシートにはファイル名の先頭に記号と番号が付いています。これらの意味は

D：開発用（作成済み）

X_D：開発用（作成対象）

M：管理用

P：提供

となります。開発用ドキュメントのX_D記号が付いているものが主な作業対象になります。作成済みのドキュメントを参考にしながら、作成対象の作業を進めてください。

なお、管理用ドキュメントは記入例が書かれていますので、それを参考に記述してください。

フェーズ 1 2 3 4 5

ソフトウェア要件定義

プロジェクト発足

ソフトウェア要求分析

ソフトウェア要件定義1

ソフトウェア要件定義2

ソフトウェア要件定義レビュー

フェーズ 6 7 8 9 10

ソフトウェア設計

ソフトウェア方式設計1

ソフトウェア方式設計2

ソフトウェア詳細設計1

ソフトウェア詳細設計2

ソフトウェア設計レビュー

フェーズ 11 12 13 14 15

実装・テスト・評価

コード作成およびユニットテスト

結合および結合テスト

適格性確認テスト

レビューおよび納品


1.2プロジェクト発足

1.2.1プロジェクト体制の決定

課題システムの開発は、架空のソフトウェア開発会社名、プロジェクトチーム名、およびプロジェクト内の役割を決めて運営します。決定した体制は、「プロジェクト体制図」を作成し、管理用ドキュメントとします。

1.2.2作業対象ファイル

•M1プロジェクト体制図.xls

•M2スケジュール表.xls

•M3プロジェクト予算実績計算書.xls

1.2.3プロジェクト内の役割

プロジェクト内では各自が以下の役割を分担します。チームの人数に応じて、分担を割り振ります。

プロジェクトリーダー、プロジェクトサブリーダー

プロジェクトリーダーの主な役割は、定められた期間と予算内で、課題システムを納品できるようプロジェクト運営を管理することです。サブリーダーも同様の観点からプロジェクトリーダーを補佐していきます。

これらの役割を認識して、以下の作業を行っていきます。

•発注元との交渉

•上司への報告

•プロジェクトの目標管理

•定例会の開催

テクニカルリーダー、テクニカルサブリーダー

テクニカルリーダーの主な役割は、技術的な課題について、プロジェクト内で解決できるよう調査や実現性の検討を行うことです。サブリーダーも同様の観点からテクニカルリーダーを補佐していきます。これらの役割を認識して、以下の作業を行っていきます。

•他メンバーの技術フォロー

•勉強会の開催

•作業の割り振り

ライブラリリーダー、ライブラリサブリーダー

ライブラリリーダーの主な役割は、作成したドキュメントやソフトウェアコードを、管理することです。ドキュメントの版数管理や、保管場所の一元管理を行い、必要なドキュメントの紛失などを防ぎます。サブリーダーも同様の観点から、ライブラリリーダーを補佐していきます。これらの役割を認識して、以下の作業を行っていきます。

•ドキュメントの版数管理

•ドキュメント化の推進

•ソフトウェアコードの版数管理

•作業の割り振り


1.2.4プロジェクト体制図の作成

開発プロジェクトの組織体制を明確にするために、「プロジェクト体制図」を作成します。

プロジェクトを円滑に推進するために、システム開発にかかわる要員の体制を明確にします。

お客様側の体制と、メーカー側の体制を明確にします。

1.2.5スケジュール表の作成

スケジュールの進捗状況を管理するために、「スケジュール表」を作成します。

開発工程を単位として、各工程の開始と完了の予定を記入します。

できる限り各作業の規模を明確にし、その作業に必要な時間と体制を考慮して決めます。

1.2.6プロジェクト予算・実績計算書の作成

システム開発にかかる費用を管理するために「プロジェクト予算・実績計算書」を作成します。

予算内でプロジェクト活動を行うために、システムエンジニア人件費やプログラマー人件費、コンピュータ利用費や出張費など、詳細な項目単位で管理していきます。


1.3ソフトウェア要求分析

1.3.1作業概要

お客様からの情報「2.1お客様情報」をもとに、お客様からのソフトウェアに対するニーズを確認します。ニーズ

はあいまいな部分を含んでいるため、必要に応じてお客様へのヒアリングを行うなどして、お客様が求めているニーズの見落としや、思い込みによる暗黙的なニーズなどを明確にしていきます。


•X_D1ニーズ概要.xls

•M7連絡票.xls

1.3.3ソフトウェアに対するニーズの確認

お客様が情報システムに対してどのような価値、思い、夢を抱いているのかを明確にします。そのうち、ソフトウェアで実現できる部分を抽出します。ニーズを明らかにすることで、次のプロセスであるソフトウェア要件定義の入力情報としていきます。

1.3.4ニーズ概要の作成

「ニーズ概要」を作成します。

1.3.4.1作業手順

•お客様とアポイントメントをとり、ヒアリングの場を設定する。

•お客様からの情報「第2章演習課題仕様書」を読み込む。

•不明瞭な点や、暗黙的なニーズを抽出する。

•お客様にヒアリングを行い、不明瞭な点や暗黙的な「ニーズ概要」を作成する。

お客様との連絡について

お客様との連絡手段としては、実際の現場では電話やメールを使うことになりますが、演習では、管理用ドキュメント「連絡票」を使用します。事前にアポイントメントを取ってから、お客様先に伺います。


1.4ソフトウェア要件定義1

1.4.1作業概要

お客様のニーズを十分に抽出した後に、ソフトウェアとして実現するための要件を明確にしていきます。この工程で、あいまいなニーズを、合否を判断することができる要件として定義していきます。要件にはソフトウェアとして本質的に実現しなくてはならない機能と、使いやすさ、性能、保守のしやすさ、誤動作の起こりにくさなどに関する機能以外の非機能と分けて明確にしていきます。


•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作業手順

•機能要件リストの用語で、判断に迷う語句や、似たような用語で表現できる用語について、抽出します。

•抽出した用語について、厳密に意味を定義します。

•新たなドキュメントを作成するたびに、用語辞書に追記、修正の保守作業を行います。


1.5ソフトウェア要件定義2

1.5.1作業概要

お客様のニーズを実現するために、システムとお客様のインターフェースとなる部分についての要件を明確にします。また、ここまでに定義した要件についての確認のための条件と判断基準を明確にした、テスト仕様書を作成します。


•X_D5画面一覧.xls

•X_D6ソフトウェア適格性確認テスト仕様書兼成績書.xls

参考提供ドキュメント

•P6品質管理計画書.xls

1.5.3画面一覧の作成

システムとお客様のインターフェースとなる部分の一つとして、画面イメージの概要を示す一覧を作成します。

1.5.3.1作業手順

•本質的な機能を実現するために、通常使用時の入出力情報を検討します。

•ユーザーインターフェースとして、必要となる画面概略を検討します。

•機能ごとに繰り返し、画面の一覧を作成します。

1.5.4ソフトウェア適格性確認テスト仕様書の作成

ここまでに定義した要件についての確認のための条件と、判断基準を明確にし、ソフトウェア適格性確認テスト仕様書を作成します。

1.5.4.1作業手順

機能要件リストの項目ごとに、定義した内容が確認できる条件と、判断基準を検討します。

非機能要件リストの項目ごとに、定義した内容が確認できる条件と、判断基準を検討します。


1.6ソフトウェア要件定義レビュー

1.6.1作業概要

ソフトウェア要件定義で作成した成果物をレビューします。プロジェクトチーム内でレビューを行った後、お客様と共同レビューを行い、定義したソフトウェア要件がお客様の要件を満たしているか確認します。


•X_D1ニーズ概要.xls

•X_D2機能要件リスト.xls

•X_D3非機能要件リスト.xls

•X_D4用語辞書.xls

•X_D5画面一覧.xls


•M4レビュー報告書.xls

•M7連絡票.xls


1.6.3ソフトウェア要件定義フェーズでの各成果物のレビュー

ソフトウェア要件定義フェーズで作成した成果物について、チーム内でレビューを行います。

1.6.3.1作業手順

•作成した成果物について、上流工程への追跡は可能か確認します。

•上流工程との一貫性は保たれているか確認します。

•内部での表現に一貫性は保たれているか確認します。

•テスト仕様書を設計するに当たって、条件や判断基準が適切に設定できるか確認します。

1.6.4ソフトウェア要件の共同レビューの実施

お客様と共同レビューを実施し、ソフトウェア要件定義に抜け漏れや誤解がないか確認します。

1.6.4.1作業手順

•お客様とアポイントメントをとり、レビューの場を設定する。

•ソフトウェア要件のプロジェクトチーム内でのレビューを行います。

•「レビュー報告書」にレビュー結果を記録し、対応方法などについて検討します。

•お客様先にて共同レビューを行い、ソフトウェア要件定義に抜け漏れや誤解がないか確認し合意します。


1.7ソフトウェア方式設計

1.7.1作業概要

ソフトウェア方式設計では、ソフトウェア品目ごとにソフトウェアコンポーネントの構成や、画面の遷移、画面レイアウトの設計を行います。


•X_D7画面遷移図.xls

•X_D8画面レイアウト.xls

•X_D9DFD0.xls

•X_D10ソフトウェア結合テスト仕様書兼成績書.xls



1.7.3画面遷移図の作成

ソフトウェア要件定義で分析した、「画面一覧」を入力情報として、画面の遷移について設計します。

1.7.3.1作業手順

•「画面一覧」からメニュー画面をグループ分けします。

•グループごとにどのように画面が移り変わっていくか検討します。

•同様に、「画面一覧」から出力情報の画面をグループ分けし、画面の移り変わりを検討します。


1.7.4画面レイアウトの作成

ソフトウェア要件定義で分析した、「画面一覧」を入力情報として、画面のレイアウト詳細について設計します。

1.7.4.1作業手順

各画面で必要とされる入出力情報を確認します。

入出力情報をどのように表現するかを検討し、画面ごとにレイアウトを作成します。

1.7.5DFD0の作成

要件定義で分析した本質的な機能でソフトウェアを分割し、それぞれをソフトウェアコンポーネントとして割り当てます。

1.7.5.1作業手順

•要件定義で分析した機能でソフトウェアコンポーネントに割り当てます。

•ソフトウェアコンポーネント間でのデータがどのように取り扱われていくかを検討します。

1.7.6ソフトウェア結合テスト仕様書の作成

ソフトウェア方式設計のドキュメントから、ソフトウェア結合のためのテスト要求事項を定義し、ソフトウェア結合テスト仕様書を設計します。

1.7.6.1作業手順

•画面レイアウト、画面遷移図、DFD0を入力情報として、ソフトウェア結合のテスト仕様を設計します。

•テスト内容、テストデータ（条件）、期待値を明確にし、テスト仕様書に記入します。


1.8ソフトウェア詳細設計

1.8.1作業概要

ソフトウェア要件をソフトウェアコンポーネントからソフトウェアユニットに割り振ります。


•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


1.8.3DFDの作成

ソフトウェアコンポーネントをさらに分割し、詳細化していきます。DFD0の各プロセスをSTS分析の手法などを検討し、より具体的な実現方法を検討します。

1.8.3.1作業手順

•DFD0の各プロセス内での処理をSTS分析などの手法を用いて分割します。

•分割後のプロセスの粒度が、同程度になるよう注意します。

•分割したプロセス間でのデータのやり取りについて検討します。

•分割したプロセスでの処理ができるだけ単機能になるまで分割を続けます。

1.8.4プログラム概要の作成

ソフトウェアコンポーネントごとに、入出力データ項目を明確にし、ソフトウェアコンポーネントの処理概要を明確にします。使用するファイルも確定します。

1.8.4.1作業手順

•概要図に入出力の関連を記述します。

•処理概要を検討し、機能を十分に洗い出します。

•使用するファイルがあれば、そのファイルも確定します。


1.8.5モジュール構造図の作成

DFDで詳細化したソフトウェアユニットの、呼び出し関係を検討し、モジュール構造図を作成します。

上下（論理ー物理）、左右（入力ー出力）の関係も考慮して呼び出し関係を構成します。

1.8.5.1作業手順

•DFDを合成します。

•ソフトウェアユニット間の呼出関係を図式化します。

•本質的な機能を実現する論理的なソフトウェアユニットを上位に配置します。

•それぞれの呼出関係で結合度や凝集度を検討します。

1.8.6ソフトウェアユニット機能設計書の作成

ソフトウェアユニット内の処理と制御条件を明確にして、詳細処理手順を明確にするために、ソフトウェアユニット機能設計書を作成します。

1.8.6.1作業手順

•ソフトウェアユニットの機能を確認するために、大まかな処理の手順を記述します。

•全体を大まかに考えて、段階的に詳細な処理を考えるようにします。


1.8.7詳細処理設計書の作成

ソフトウェアユニット内の処理単位に詳細な処理手順を記述します。

1.8.7.1作業手順

•関数の名称を命名規約に基づいて設計します。

•引数の型と種類について設計します。

•戻り値の型と内容について設計します。

•ソフトウェア機能設計書に記述された大まかな処理を、個別の処理単位ごとに詳細な処理手順を記述します。

1.8.8ソフトウェアユニットテスト仕様書の作成

ソフトウェア詳細設計のドキュメントから、ソフトウェアユニットのテスト要求事項を定義し、ソフトウェアユニットテスト仕様書を設計します。

ここでは、ブラックボックステストだけではなく、詳細処理設計書からホワイトボックステストについても検討します。

1.8.8.1作業手順

•ソフトウェアユニット機能設計書、詳細処理設計書を入力情報として、ソフトウェアユニットのテスト仕様を設計します。

•テスト内容、テストデータ（条件）、期待値を明確にし、テスト仕様書に記入します。

•ホワイトボックステストではC1カバレッジの網羅性で設計します。


1.9ソフトウェア設計レビュー

1.9.1作業概要

ソフトウェア設計で作成した成果物をレビューします。プロジェクトチーム内でレビューを行った後、上司を含めて共同レビューを行い、ソフトウェア要件定義の実現が可能であることを確認します。


•X_D7画面遷移図.xls

•X_D8画面レイアウト.xls

•X_D9DFD0.xls


•X_D11DFD.xls

•X_D12プログラム概要.xls








•X_D18関数一覧.xls



1.9.3ソフトウェア設計フェーズでの各成果物のレビュー

ソフトウェア設計フェーズで作成した成果物について、チーム内でレビューを行います。

1.9.3.1作業手順

•作成した成果物について、上流工程への追跡は可能か確認します。

•上流工程との一貫性は保たれているか確認します。

•ソフトウェアコンポーネント間での表現に一貫性は保たれているか確認します。

•テスト仕様書を設計するに当たって、条件や判断基準が適切に設定できるか確認します。

1.9.4ソフトウェア設計の共同レビューの実施

上司と共同レビューを実施し、ソフトウェア設計に抜け漏れや誤解がないか確認します。

1.9.4.1作業手順

•上司とアポイントメントをとり、レビューの場を設定する。

•ソフトウェア要件のプロジェクトチーム内でのレビューを行います。

•「レビュー報告書」にレビュー結果を記録し、対応方法などについて検討します。

•共同レビューを行い、ソフトウェア設計に抜け漏れがないか確認し合意します。


1.10ソフトウェアコードの作成

1.10.1作業概要

ソフトウェアを構成する個々のソフトウェアユニットのソフトウェアコードをC言語で作成します。


•ソフトウェアコード(menu.c、menu.h、member.c、member.hなど)




•M6不具合管理表.xls

1.10.3ソフトウェアコードの作成

ソフトウェア詳細設計のドキュメントを入力情報として、ソフトウェアコードを作成します。

1.10.3.1作業手順

•モジュール構造図、ソフトウェアユニット機能設計書、詳細処理設計書、関数機能設計書から、C言語でソフトウェアコードを作成します。

•コーディング規約にのっとってソフトウェアコードを作成します。

•作成したソフトウェアコードは、コンパイルし文法上の誤りがあれば修正します。

•版数管理を適切に行います。

1.10.3.2参考ドキュメントファイル






•D16関数機能設計書.xls

•P5コーディング規約.xls

1.10.4ソフトウェアコードの成果物レビュー

ソフトウェアコードの自己レビュー、共同レビューを行います。

1.10.4.1作業手順

自己レビューを徹底して行います。

自己レビュー完了後、他のメンバーにレビューを受けます。

レビュー記録を取ります。

レビューが完了するまで、テスト工程に進みません。


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 DEBUFprintf("R11¥n");

#endifnew->next = target->next;target->next = new;break;

｝else {#ifdef DEBUF


target = target->next; /* ターゲットを更新して次のノードへ */}

} else {#ifdef DEBUF


/* 新しいノードをリストの末尾に追加して終了する */new->next = NULL;target->next = new;break;

}


1.11ソフトウェア結合

1.11.1作業概要

ソフトウェアを構成する個々のソフトウェアユニットを組み立て、設計した機能が実現できるかどうかを確認します。





1.11.3ソフトウェアの結合

コンパイルおよびリンクを実行し、各ソフトウェアユニットを結合します。

1.11.3.1作業手順

•ソフトウェアユニットテストが完了したファイルから、デバッグ用に挿入したprintf()などを削除します。

•各ファイルをコンパイルおよびリンクし、ソフトウェアユニットを結合します。

•文法上の誤りがあれば修正します。

•版数管理を適切に行い、最新版ファイルの管理を注意します。

1.11.4ソフトウェア結合テストの実施

ソフトウェア結合テスト仕様書にのっとって、ソフトウェア結合テストを実施します。

1.11.4.1作業手順

•ソフトウェア結合テスト仕様書の条件にそって、テストを実施します。

•テスト結果をソフトウェア結合テスト成績書に記録します。


•不具合を修正し、その不具合が解消されたかどうか、再テストで確認します。


1.12ソフトウェア適格性確認

1.12.1作業概要

完成したソフトウェアが定義した要件を満たしているか確認します。

結合テストで確認した機能が、お客様の要件を満たすかどうかの観点で確認します。





1.12.3ソフトウェア適格性確認テストの実施

ソフトウェア適格性確認テスト仕様書にのっとって、ソフトウェア適格性確認テストを実施します。

1.12.3.1作業手順

•ソフトウェア適格性確認テスト仕様書の条件にそって、テストを実施します。

•テスト結果をソフトウェア適格性確認テスト成績書に記録します。


•不具合を修正し、その不具合が解消されたかどうか、再テストで確認します。


1.13テストレビュー

1.13.1作業概要

各テストの結果についてレビューを行い、品質を検証します。








1.13.3テストフェーズでの各成果物のレビュー

各テスト工程での成果物である成績書をレビューします。テスト項目、不具合件数などを確認します。


1.14システム納品

1.14.1作業概要

お客様へのシステム納品に当たり、プロジェクトの成果物をまとめ、納品物として提出します。

1.14.2作業手順

•以下に示す成果物をフォルダにまとめ、納品物とします。

1.ソフトウェア

• ソフトウェアコード

• 実行形式ファイル

2.ドキュメント一式

• 管理用ワークシート

• 開発用ワークシート

1.14.3システムの納品

お客様からの指定時間までに、納品物をお客様に納品します。

Documents

Copyright 2012 IPA All Rights ReservedCopyright 2012 IPA All Rights Reserved 7 1.4ソフトウェア要件定義1 1.4.1作業概要 お客様のニーズを十分に抽出した後に、ソフトウェア

Copyright 2012 IPA All Rights ReservedCopyright 2012 IPA All Rights Reserved 7 1.4ソフトウェア要件定義1 1.4.1作業概要お客様のニーズを十分に抽出した後に、ソフトウェア