2009/03/21 Takashi Tomiyama http://mobile-robots.way-nifty.com/daily_report/ 1 1. 2. 3. はじめに TSPiとは TSPiのプロセス概要 1. 2. 3. 4. 5. 6. 7. 立ち上げプロセス 開発戦略立案 開発計画立案 要件定義プロセス 設計プロセス 実装プロセス 統合とシステムテスト 8. 事後分析 4. 5. 6. 7. 自己管理 チームワーク 関連情報 参考資料 2 この資料の目的 動機 参考文献 ◦ TSPiを勉強して理解したことを資料としてアウトプットすることで、理 解した内容の定着を図る。 ◦ 今後TSPiのプロセスに従って開発を行うときに、プロセスの概要を 思い出すのに使用する。 ◦ 「反省の仕方」について、TSPで事後分析（ポストモーテム）というプ ロセスがあると聞いて、TSPを勉強してみたくなった。 ◦ PSPに関してはいろいろなところで取り上げられているが、TSPに関 してはインターネット上で（少なくとも日本語のサイトでは）情報が少 ないと思ったので、資料をUploadしたら面白いかなと思った。 ◦ [1] ワッツ・S・ハンフリー著、JASPIC TSP研究会訳；TSPiガイドブッ ク、翔泳社、2008. 3 Introduction to the Team Software Process ◦ チームでソフトウェを開発するためのソフトウェア開発プロセスと、 そのトレーニングコース。 ◦ 大規模開発（20人～）向けのTSP (Team Software Process)を４ ～５人で取り組めるように定義しなおした縮小版。 ◦ PSP（Personal Software Process）のトレーニングを受けているこ とを前提とする。 CMM, TSP, PSP ◦ CMM ◦ TSP ◦ PSP 組織に対する開発プロセス改善ガイドライン チームのための開発プロセスとトレーニングコース 個人のための開発プロセスとトレーニングコース 4 立ち上げ 開発の目的とゴールを定義し、チームを編成する。 開発戦略立案 システムの構築方法と代替案を提案し、選定する。 概念設計を行い、規模と時間の初期見積もりを得る。 開発計画立案 タスク、スケジュール、品質の計画を立てる。 要件定義 ソフトウェア要求仕様書を作成する。 設計 製品全体を主要なコンポーネントに分割する。 各コンポーネントの外部仕様を作成する。 各コンポーネントの最上位ロジックを設計する。 実装 各コンポーネントの詳細設計と実装を行う。 各コンポーネントの単体テストを行う。 統合とシステムテスト 事後分析 各コンポーネントを統合して、システムテストを行う。 計画と実績を比較して、プロセス改善提案を行う。 5 開発の目的とゴールを定義し、チームを編成する。 １．ゴールを設定する • 開発対象製品の目的を定義する。 • 製品が達成すべき不可欠な目標を定義する。 • 完成した製品の評価基準を示す。 ２．チームを編成する • チームメンバを集める。 • メンバに役割を割り当てる。 • チームのゴールを定義する。 ３．初回ミーティングを 行う • メンバーの役割について話し合う。 • 初回の開発サイクルのゴールについて話し 合い、合意する。 • 週次ミーティングを行う標準日時を設定す る。 6 週次ミーティングの目的 ◦ チーム内のコミュニケーションを図り、課題を共有し、意思決 定する。 ◦ 進捗データを収集、分析、レビューして必要ならばバランスを とる。 報告内容 ◦ ◦ ◦ ◦ ◦ ◦ 自分が割り当てられたタスクの活動状況 追跡中の課題とリスクの状況 計画に対してチーム全体で費やした時間とEV（獲得価値） その週に提出された品目、変更内容、残っているタスク 新たに発生した問題や懸念事項 来週の作業予定 7 システムの構築方法と代替案を提案し、選定する。 概念設計を行い、規模と時間の初期見積もりを得る。 １．戦略基準を確立する 利用可能な開発期間を超えるリスクを最小化 するような開発戦略の選定基準を定義する。 ２．概念設計を作成する 製品を構成する主要なコンポーネント、各コン ポーネントの主な機能、各コンポーネントの規 模を洗い出す。 ３．開発戦略を選択する • 開発戦略の代替案を提案し、評価する。 • 製品の機能を各開発サイクルに割り当てる。 • 機能の分割方法と統合方法を定義する。 ４．初期見積もりを行う • 概念設計を元に、現在のサイクルの成果物 について規模と時間を見積もる。 • 次回以降のサイクルの成果物について大 まかな規模と時間を見積もる。 8 システムの構築方法と代替案を提案し、選定する。 概念設計を行い、規模と時間の初期見積もりを得る。 ５．リスクを評価する ６．戦略を文書化する ７．構成管理計画を作成 する プロジェクトのリスクを特定、評価し、ITL（※） に記入する。 • 戦略記述フォームに開発する機能をリスト アップする。 • 機能を組み込む予定の開発サイクルを記 入する。 • 構成管理の手順を定義する。 • サポートツールを準備する。 ※ ILT： Issue Tracking Log（課題追跡ログ）。 9 以下のセットを開発戦略という。 ◦ 製品機能を定義、設計、実装、テストする順序 ◦ 将来の開発サイクルで製品を拡張する方法 ◦ 開発作業をチームメンバ間で分担する方法 開発戦略は、規模見積もりとリソース計画を行うた めに、TSPiプロセスの最初に作成する。 10 プロジェクト計画を策定するために概念設計を行う。 ◦ ユーザの要求をまとめた文書は自分が提供するものを記述したものではない ので、計画には使えない。 ◦ 概念設計はあくまで計画立案のツールなので、ここで多大な時間を使っては いけない。 ◦ 実際の設計は要求を分析し、インスペクションが完了した後。 概念設計を元に、仮定した製品の規模と開発に必要な時間を見積も る。 Key Questions ◦ 現在自分が知っている事柄に基づいて、この製品をどのように開発するの か？ ◦ この製品を作るために必要な主要コンポーネントは何か？ ◦ これらのコンポーネントが提供しなければならない機能は何か？ ◦ これらのコンポーネントはどれくらいの大きさになると思うか？ 11 タスク、スケジュール、品質の計画を立てる。 １．この開発サイクルで 作成する成果物をリスト アップする • 概念設計を元に、各コンポーネントの規模 を見積もる。 • ソースコード以外の成果物についても特定 し、規模を見積もる。 ２．タスク計画を作成する チームとエンジニアの時間見積もりを含むタス クリストを作成する。 ３. スケジュール計画を 作成する • スケジュールフォームに週次時間を記入す る。 • チーム全体のタスクフォームを作成する。 12 タスク、スケジュール、品質の計画を立てる。 ４．品質計画を作成する • 各フェーズで作り込む欠陥数を見積もる。 • 欠陥除去フェーズで達成する欠陥除去率を 見積もる。 ５．チームメンバ個々の計 画を作成する • 各フェーズで作り込む欠陥数を見積もる。 • 欠陥除去フェーズで達成する欠陥除去率を 見積もる。 ６．チームの作業負荷の バランスを調整する • チームと個々人の計画をレビューする。 • 作業負荷のバランスがとれていない部分を 特定する。 • タスクを割り当て直してバランスのとれた計 画を作成する。 13 1. 2. 3. 4. 今回の開発サイクルで作成する製品全体について、 フェーズ毎の欠陥作り込み数を見積もる。 チームが各欠陥除去フェーズで達成する欠陥除去 率を見積もる。 テストフェーズの欠陥除去率を見積もる。 欠陥除去率、レビューレート、インスペクションレート が基準値に近付くよう、欠陥除去フェーズの時間を 増減する。 （TSPiにおける用語定義） レビュー 自分で作成した成果物の欠陥を探し出す作業 インスペクション あるメンバが作成した成果物を複数人でレビューして欠陥を探し出す作業 14 TSPiでは、プロジェクト追跡の主なメトリクスとしてPV （計画価値）とEV（獲得価値）を使用する。 PV：Planned Value ◦ 計画された各タスクがその仕事全体に対する割合。 ◦ そのタスクが完了したときに初めてPVを与える。 EV：Earned Value ◦ その時点で完了している各タスクのPVの合計。 15 ソフトウェア要求仕様書を作成する。 １．要求記述書をレ ビューする • 製品に対する要求記述書をレビューする。 • 製品が実行すべき機能やその使われ方を 明確化する。 ２．要求仕様書（SRS）案 を作成する • 簡潔で具体的なユースケースを定義する。 • 製品の機能と外部インタフェースについて チームで合意した内容を文書化する。 ３．システムテスト計画 を作成する • システムがなすべきことについて合意した 内容を検証するためのテスト方法を計画する。 ４．SRS案とシステムテ スト計画のインスペク ションを行う • SRS案とテスト計画をチーム全体でインスペ クションし、不整合や欠陥を見つけ出す。 • 見つかった不整合や欠陥の修正担当者と 修正期限を決める。 SRS=Software Requirement Specification（ソフトウェア要求仕様書） 16 ソフトウェア要求仕様書を作成する。 ５．SRS案とシステムテ スト計画を更新する • 先のインスペクションから修正／訂正され た内容をSRS案とシステムテスト計画に反映さ せる。 ６．ユーザによるSRSレ ビューを行う • エンドユーザにSRS案をレビューしてもらい、 望むものが記述されていることに合意を得る。 ７．SRSをベースライン 化する • レビューを終えたSRSを公式にベースライン 化し、以後は「変更要求手続き」でしか変更し ないようにする。 17 目次 はじめに 1. 2. ◦ ◦ ◦ 5. ◦ ◦ ◦ ◦ ◦ ◦ システムへの機能要求 サイクル１での要求 サイクル２での要求 トップダウン構造 要求で使われる規則の ◦ ◦ 標準の順守 開発上の制約 特別なシステム要求 7. ◦ ◦ 8. ユーザインタフェース 画面レイアウト 設計／実装上の制約 6. 機能要求 3. 4. SRSの目的 問題の記述 チームプロジェクト情報 定義 外部インタフェース要求 文書化 互換性 参照と情報源 18 実行すべきテスト項目のリスト 各テストの目標 各テストに必要な支援資材 Support Material を直訳した ものと予想。内容としてはテス トに使用するテストツール、テ スト用サンプルデータなど。 ◦ これら支援資材の予想規模 ◦ その資材の開発にかかる時間の見積もり ◦ その資材の開発作業の完了時期 欠陥がない場合の実行時間、発見される欠陥数およ び各テスト時間の合計の見積もり テスト計画にある各品目を開発するために必要な作 業の見積もり 19 製品全体を主要なコンポーネントに分割する。 各コンポーネントの外部仕様を作成する。 各コンポーネントの最上位ロジックを設計する。 １．上位レベルの設計を 行う • 今回のサイクルの製品構造を定義する。 • コンポーネントに名前を付ける。 • ユースケースをこれらのコンポーネントに割 り当てる。 ２．設計標準を作成する 命名規則やインタフェース標準などの設計 標準を作成する。 ３．設計仕様書（SDS）を 作成する • チームメンバに設計作業を割り当てる。 • チームメンバはSDSのうち自分の担当分を 作成する。 20 製品全体を主要なコンポーネントに分割する。 各コンポーネントの外部仕様を作成する。 各コンポーネントの最上位ロジックを設計する。 ４．統合テストの計画を 作成する • 各コンポーネントのインタフェースをレ ビューし、それらをテストする方法を定義する。 ５．設計と統合テストの 計画をインスペクション する • すべてのユースケースが設計に盛り込まれ ているか、正しく設計されているか、統合テス ト計画が適切であるかインスペクションする。 • 見つかった不整合や欠陥の修正担当者と 修正期限を決める。 ６．SDSをベースライン 化する • インスペクション後の更新部分をSDSに反 映させ、SDSをベースライン化する。 21 製品全体の設計コンセプトを作成する。 ◦ 最初の開発サイクルの設計フェーズで行う。 ◦ ２回目以降のサイクルでは必要があれば変更、洗練する。 上位レベル設計に含まれる内容 ◦ ◦ ◦ ◦ ◦ 製品の全体構造定義 製品を構成するコンポーネントの名前付け コンポーネントに対する機能の割り付け コンポーネントの外部インタフェース仕様 コンポーネントに対するユースケースの割り付け 22 命名規則 コンポーネント間のインタフェース書式 エラーメッセージ 欠陥標準 LOCカウント標準 設計表現の標準 ◦ プログラムの階層名、ファイル名、変数名など ◦ 必要なら用語集を作る。 ◦ 変数、エラーコード、その他の条件 ◦ 一貫した、再利用可能なメッセージとメッセージ処理方法 ◦ 欠陥情報を収集、分析するために使用する。 ◦ TSPiではPSP欠陥型標準を使用することを推奨 ◦ LOC：Line Of Code ・・・ （ソースコードの）論理コード行数 ◦ プログラムの規模を計測するために使用する。 ◦ 設計の完全性、正確性向上に役立つ。 ◦ レビューやインスペクション時に見落としを防ぐ。 ◦ PSPの設計テンプレートを使ってもよい。 23 内部 外部 静的 論理仕様 テンプレート 機能仕様 テンプレート 動的 状態仕様 テンプレート 操作シナリオ テンプレート 詳しくは、PSPネットワークによる パーソナルソフトウェアプロセス技法の補助教材 http://www.kyoritsu-pub.co.jp/service/psp/dse_index.html の講義スライドの jlect10-1.ppt (443KB)を参照 24 各コンポーネントの詳細設計と実装を行う。 各コンポーネントの単体テストを行う。 １．実装の計画を立てる • 実装タスクを定義し、メンバーに割り当てる。 • メンバーは割り当てられたタスクの時間見 積もりと作業計画を作成する。 ２．詳細設計を行う • メンバーは担当分の詳細設計を行い、詳細 設計書にまとめる。 ３．単体テスト計画を立 てる • 単体テスト計画書を作成する。 • 単体テストのテストケース、テスト手順とテ ストデータを作成する。 ４．詳細設計のインスペ クションを行う • インスペクション対象のすべてのループ、ス テートマシン、実行テーブル等について適切 に設計されているかインスペクションする。 • 矛盾や欠陥があれば、欠陥記録ログに記 入する。 25 各コンポーネントの詳細設計と実装を行う。 各コンポーネントの単体テストを行う。 ５．コーディングとコード インスペクション ６．単体テストを行う • コーディングで作り込む欠陥数を見積もる。 • 各コンポーネントのソースコードを作成する。 • コンパイルエラーが除去されたソースコード について、自己レビューを行う。 • チームメンバに参加してもらい、コードイン スペクションを行う。 単体テスト計画書に従い、テストを実施する。 ７．コンポーネントの品 質をレビューする コードインスペクションと単体テストが済んだ コンポーネントについて、品質データをレ ビューし、ベースラインに入れるか修正するか を判断する。 ８．コンポーネントをリ リースする インスペクションで問題無ければ、そのコン ポーネントをリリースし、以降は構成管理の対 象とする。 26 設計は全体像から始めて、詳細に落としていく。しかし、レ ビューは詳細から始めて全体像に上がっていく方が効率 が良い。すなわち、レビューはボトムアップ戦略をとる方が 良い。 このボトムアップ戦略に従うために、実装も最下位レベル のオブジェクトから始めて、それからより高いレベルに移る のが良い。 このアプローチにより、最下位レベルのオブジェクト仕様に 関する問題を早期に見つけ出し、それらが広く実装される 前に修正を行うことができる。 また、最下位レベルのオブジェクトは再利用が最も簡単な ので、ボトムアップ実装戦略が再利用性も促進する。 27 設計にかける時間は、コーディング時間以上とすべき である。 設計レビューにかける時間は、設計時間の５０％以上 とすべきである。 コードレビューにかける時間は、コーディング時間の５ ０％以上、望ましくは７０％以上とすべきである。 コンパ売りで見つける少なくとも倍の欠陥をコードレ ビューで見つける。 レビューレートが時間当たり２００LOCを下回ることが 望ましい。 28 各コンポーネントを統合して、システムテストを行う。 １．テストの準備を行う • • • • 必要なビルド手順を定義する。 統合テスト手順とそれに必要な資材（※）を作成する。 システムテスト手順とそれに必要な資材を作成する。 各テストの規模と実行に必要な時間を見積もる。 • 必要なすべてのコンポーネントがそろって いることを確認して、製品をビルドする。 ２．ビルドする ３．統合テストを行う • 統合テスト計画に従い、テストを行う。 • テストデータや欠陥を記録する。 ４．システムテストを行う • システムテスト計画に従い、テストを行う。 • テストデータや欠陥を記録する。 ５．文書化する • ユーザに読んでもらう文書を作成する。 • 作成したユーザ文書をレビュー、訂正して 完成させる。 ※ テストケース、テスト用サンプルデータ、評価ツールなど 29 ビッグバン戦略 ◦ 全てのコンポーネントを一度にまとめて統合する。 ◦ メリット： シンプルなシステムではテスト開発の時間が最小になる。 ◦ デメリット： システムが大きく複雑になるほど統合テストで見つかる欠陥が増え、原因調 査と修正に時間がかかるようになる。 一度に一つ戦略 ◦ 使用可能なコンポーネントを一度に一つづつ追加する。 ◦ メリット： 問題が発生したコンポーネントを特定しやすい。 ◦ デメリット： テスト開発作業が多くなるかもしれない。 機能群戦略 ◦ 機能ごとに関連するコンポーネントを集めて統合する。 ◦ メリット： テストドライバなどを開発する必要がない。 フラットシステム戦略 ◦ 最上位レベルのコンポーネント統合から始めて、順次下位レベルのコンポーネントに掘 り下げていく。 ◦ メリット： システム全体に及ぶ課題を早期に検出できる。また、システム全体の骨格を 早く組み上げられる。 ◦ デメリット： まだ使用できないコンポーネントの代わりに、数多くのスタブを用意する必 要がある。 30 1. システムは、実行することになっている機能を正しく 実行するか？ 2. システムは、その品質ゴールを満たしているか？ 3. システムは、通常の条件下で正しく動作するか？ 4. システムは、通常でない条件下で正しく動作する か？ 31 第１案 （最も一般的な方法） ◦ ◦ ◦ ◦ 各機能のテスト 負荷をかけた状態でのテスト 使いやすさのテスト パフォーマンス計測 第２案 （機能単位） ◦ 選択した機能領域に焦点を合わせて網羅的にテストを行い、次第に他の機能領域に移 る。 ◦ ただし、システム全体のパフォーマンスなどを十分にチェックできないおそれがある。 第３案 （第１案と第２案の組み合わせ） ◦ より下位レベルの機能を、正常、異常、および負荷のかかった状態でテストすることから 始め、次第に上位レベルに移り、最後に最上位の機能をテストする。 ◦ ただし、この方法は重要な機能の組み合わせをテストするのに時間がかかる。 第４案 （第３案の逆） ◦ 最上位の機能を、正常、異常、および負荷のかかった状態でテストすることから始め、 次第に下位レベルに移る。 ◦ ただし、この方法は製品が十分高品質でないと通用しない。 32 ドキュメントがそろっていないプログラムは役に立たない。 ユーザマニュアルの構成は製品設計の構成と大きく異な る。 ◦ ◦ ◦ ◦ 製品の構造ではなく、読者のニーズに合わせること。 まずは始め方を扱うべき。 次に、ユーザがその製品で何ができるかを説明する。 エラーメッセージ、故障原因追究手続き、リカバリ手順に関する節 を含める。 よりユーザにとって読みやすくなるように・・・ ◦ ◦ ◦ ◦ ◦ ◦ 用語集を使って、普通の辞書には無い用語を定義する。 重要なトピックには索引を付ける。 詳細な目次を付ける。 文を短く書き、シンプルな単語と言い回しを使う。 リストや箇条書きを多用する。 大きな声で読み上げて、読み上げやすくなるように書きなおす。 33 計画と実績を比較して、プロセス改善提案を行う。 １．プロセスデータをレ ビューする • チームが行ったことに関するデータを調べる。 • うまくいったところ、うまくいかなかったところを 特定する。 • 問題のあるところにプロセス改善提案を出す。 ２．役割のパフォーマン スを評価する • 各メンバの役割について、うまくいったところと 問題があったところを特定する。 • 次回の開発サイクルに向けた改善提案を出 す。 ３．報告書を作成する • 今回の開発サイクルにおける報告書を作成、 レビュー、校正する。 ４．役割評価を行う • チームの実績および各役割の実施状況につ いて自分の見解を述べる。 • 各役割の難しさと貢献度を評価する。 34 チームとチームメンバが行ったことに関するデータを 調べる。 そのプロセスがうまく行ったところ、うまく行かなかった 所を特定する。 チームの実績を、チームのゴールおよび計画と比較 する。 問題のあるところと改善のニーズを特定する。 プロセス改善を考え出して、PIP（プロセス改善提案 書）にまとめる。 35 プロセスデータのレビューの一環として、品質につい てもレビューし、改善するために何が必要か見極める。 Key Questions ◦ ◦ ◦ ◦ ◦ 実績は計画と比べてどうだったか？ どんな教訓をこの経験から学んだか？ 今後、別の個人あるいはチームの基準を使うべきか？ どこに改善の機会があると判ったか、その理由は？ 次回訂正しなければならない問題があったか？ 36 目次 サマリー 役割報告 ◦ ◦ ◦ ◦ ◦ ◦ リーダーシップ 開発 計画立案 プロセス 品質 サポート エンジニア報告 • 自分がどのように役割を果たしたか。 • その役割の観点についてチームがどの ように実施した（と自分が考える）か。 チームメンバ各自の実績報告と改善提案。 結論を裏付ける具体的なデータを報告に盛 り込むこと。 37 チームの各メンバがチーム全体の実績に対してどの 程度貢献したか評価する。 ◦ 「役割の困難さ」と「貢献度」の視点で評価する。 改善の機会に焦点を合わせる。 ◦ 素直に、正直に、客観的に、建設的に。 ◦ 批判をするときは、次回もっとうまくその状況を処理する方法 の提案を添える。 38 Post Mortem = 検死解剖（司法解剖） 多くのプロジェクトは満足いく結果で終わっていない。 ◦ （日本では）プロジェクト終了時に「反省会」が行われるが、失敗に至った経緯 について弁明し、「反省の深さ」ばかり強調されて対応策の具体性が乏しい。 ◦ 表層的な症状を裏返したものは原因に届いておらず、改善策になりえない。 成功も失敗も、因果関係で考える。 「成功のパターン」を繰り返そう！ ポストモーテムでは、失敗だけでなく成功についても分析する。 ◦ なぜうまくいったのか、何が効果を発揮したのか、文字にして確認しよう。 ◦ うまくいった仕組みを見つけ出し、その「成功のパターン」を焼きつけよう。 ◦ ◦ ◦ ◦ 計画と実績を比較し、どうだったか？ うまく行ったところ、うまくいかなかった所はどこか？ どこに改善の余地があると判ったか？ その理由は？ この経験からどのような教訓を学んだか？ 参考 システムクリエイツ 清水氏； ソフトウェアエンジニアのためのホームページ http://homepage3.nifty.com/koha_hp/process/Proc.Square/Proc.Square.PO.htm 39 責任を持つ 定義されたゴールに向かって努力する 堅実な原理に従って生活する ◦ その問題に対処することを決心する。 ◦ 状況に左右されるのではなく、困難な状況を制御するために何ができるかを 前向きに考える。 ◦ 自分の権限や能力で対処できないことは、その権限や能力を持つ人に協力を 仰ぐ。 ◦ 現実を直視する。事実を述べる。 ◦ 明確なゴールを定義し、焦点と優先順位を確立する。 ◦ ゴールが不明確だと思ったら、自分の意見をまとめて、作業を開始する前にそ れらについて確認、合意する。 ◦ ◦ ◦ ◦ ◦ 現在の仕事に最善を尽くす。 メンバーを理解し、相互に援助しようと努力する。 卓越（エクセレンス）を目指して絶え間なく努力する。 規律を維持するために、習慣の力を利用する。 習慣を自然なものとするために、願望を動機付け、知識を獲得し、技術を磨く。 40 効果的なチームワークの８つの条件 ◦ ◦ ◦ ◦ ◦ ◦ ◦ チームの合意されたゴール 確立されたチームメンバーの役割 そこで作業が行われる協力的な環境 チームワークの共通プロセス その作業のための計画 チームゴール、役割と計画に対する相互のコミットメント チームメンバー全員の間での自由でオープンなコミュニケー ション ◦ チームメンバー全員が相互に尊敬しあって支援すること 41 TSPiのフォームやスクリプト類は、Software Engineering Instituteのウェブサイトから入手可能。 ◦ http://www.sei.cmu.edu/tsp/tools/tspi-form.html パーソナルソフトウェアプロセス技法の補助教材 CMMIモデル 公式日本語翻訳版 ◦ http://www.kyoritsupub.co.jp/service/psp/dse_index.html ◦ http://www.sei.cmu.edu/cmmi/translations/japane se/models/index.html 42 SRSの目次サンプル • IEEE Std. 830-1998の例 • 「若手SEのための要求のまとめ方」の例 • マイクロマウスSW要求仕様書の例 43 1. 2. 5. 仮定及び依存性 はじめに 1. 2. 3. 4. 5. 目的 範囲 用語定義 参考文献 概要 3. 1. 2. 3. 4. 5. 6. 7. 要求仕様の一般的な 説明 1. 2. 3. 4. 製品の背景 製品機能 ユーザ特性 制約 要求仕様の具体的な 説明 4. 5. 外部インタフェース 機能 性能要求 論理データベース要求 設計の制約 ソフトウェアの属性 要求仕様の段落構成 付録 索引 44 1. 1. 2. 3. 4. 5. 2. 品質属性 制約条件 物理的条件 セキュリティ目標 操作性 システムのライフサイクル と維持管理 9. 暫定仕様と依存性 システムの目的 システムの範囲 専門用語と略語の定義 参照 システム概要 前提条件 1. 開発の背景 2. 開発の制約条件 3. ユーザグループの定義 3. 3. 4. 5. 6. 7. 8. イントロダクション システム要件 1. 機能要求 2. 性能要求 4. インタフェース 1. 2. 3. 4. ユーザインタフェース ハードウェアインタフェース ソフトウェアインタフェース 通信インタフェース 45 1. 2. 3. 3. トライアル走行機能 4. 動作確認機能 5. エラー処理 変更履歴 はじめに 1. 対象範囲 2. 参考資料 3. 専門用語と略語 システム概要 1. 2. 3. 4. 5. 6. ハードウェア仕様 ハードウェア構成 基本機能 システム状態遷移 使用条件 使用環境 機能要件 1. 共通機能 2. 探索走行機能 4. 5. 6. 非機能要件 1. 目標性能 2. RAS（※）定義 開発条件 1. 設計手法 2. 開発環境 3. RAS充実方針 主要マイルストーン ※ Reliability（信頼性）, Availability（可用性）, Serviceability（保 守性）の頭文字をとったもの。 信頼性指標としてはMTBF（平均故障 間隔）、保守性指標としてMTTR（平均修理時間）、可用性指標として 稼働率を用いてシステムの信頼性を評価する。 稼働率＝ MTBF / (MTBF + MTTR) 46
© Copyright 2024 ExpyDoc
