まず、ソフトウェア要件管理プロセス
3つの主要な計画：
レンジプラン\スケジュール\プログラム費（コストベースライン、スケジュールベースライン）
ソフトウェア要件
需要は、機能性とソフトウェアのパフォーマンスのためのユーザーの要求を意味し何のパフォーマンスに、完成された機能の種類を、ユーザーが何かをしたいソフトウェアです。
レベルのソフトウェア要件
プロジェクトの故障解析の理由
ソフトウェア要件管理プロセス
必要条件誘出
需要分析（機能的行動データモデル、モデリング）
要求仕様を書きます
ニーズの検証
基本的なミッション要求工学
必要条件誘出
ベースライン：需要の評価
ニーズ分析の定義
エンドユーザーがシステム概念モデルの確立を見ている要件の抽象的な記述であるため、分析が必要です。
需要分析モデル
要件仕様
- 基本的な要件の分析が完了している記号は、要求仕様の完全な仕様の形成であります
- 要求仕様の調製は、両側が全体の開発努力のための基礎作り、オリジナルのソフトウェアの規定の共通の理解を持っているユーザーとソフトウェア開発者を有効にすることです。
ソフトウェアの要求仕様の原則
- 現実から機能分離、つまり、「何を」ではなく「どのように達成するために」を記述するために
- 特定の仕様記述言語の使用
- あなただけの大きなシステムをソフトウェア要素をされて開発している場合は、システム全体もの明細書に記載された大の中に含まれています
- 仕様は、システムの動作環境を含める必要があります
- 仕様を理解するためのモデルでなければなりません
- 仕様は不完全許可と拡張を可能する必要があります
仕様参考書類
- 入門
- システム定義
- アプリケーション環境
- 機能仕様
- 性能要件
- 提出します
- 実装上の制約
- 品質について
- 他の
- 署名認証
ニーズの検証
- 需要があなたのために右でありますか？
- 需要が行うのと同じですか？
- 需要がそれを完了するのですか？
- 需要はそれが実用的でしょうか？
- 需要が必要なのか？
- 需要はそれが検証可能でしょうか？
- 需要が追跡可能な権利でありますか？
- 最終的な署名
需要の総変化
要件の変更管理
- ニーズが制御プロセスを変更識別する
- 確立変更管理委員会（SCCB）
- 行動要件変更の影響分析
- トラッキングの変更は、すべての作業製品の需要に影響を与えます
- ドキュメントのバージョンとデマンド制御のベースライン需要のバージョンを確立
- 保守要件が歴史を変えます
- 各要件の状況を追跡
- 測定は、安定性を必要とします
要件の変更管理
管理と制御の要件のベースラインプロセス
デマンド変更管理システム
変更の需要を制御する方法について説明し、正式な文書
変更承認システムを構築
タスク分解の第二に、定義
WBS（ワーク・ブレークダウン・ストラクチャー）
タスク分解プロセスは、操作がより簡単に、プロジェクトはより小さく、より管理しやすく、プロジェクトまたはサブプロジェクトの作業の内訳をよりに細分されます。
タスク分解はWBS（ワーク・ブレークダウン・ストラクチャー）の結果。
WBS志向の成果。
最低レベルのワーク・パッケージ（ワークパッケージ）が成果をWBS
WBSの例
PMIは、WBSを定義します
プロジェクトのスコープ全体を整理し、定義し、プロジェクト成果のパケット指向の要素である。WBSは、作業に含まれていないことは、プロジェクトの作業ではありません
これは、分解プロセスは、罰金に粗いからのプロジェクトである、階層ツリー構造です。作業分解構造は、より詳細な各プロジェクト要素の階層的な記述を表し
PMIは、ワークパッケージを定義します
WBS成果の最低レベル
ワークパッケージは責任のみ対象とすべきです
成果は、計画と実施のためのプロジェクトマネージャー、他に割り当てられた、またはサブプロジェクトの途中で完了することができます
第三に、タスク分解の種類
タイプ
- インベントリ
- チャート
チャートの種類
リストタイプ
1.変更カウンター
1.1プログラムの2つのバージョンを比較
1.1.1前処理
1.1.2ファイルの比較
1.1.3結果の処理
1.2を添加し、コードの行を識別するために改訂されたプログラムで削除します
1.2.1コードの追加の行を識別する
1.2.2コードの削除された行を識別
手順1.3統計的改変後のコードの行の数は、追加および削除します。
1.3.1コードの行数の統計的に増加
コードの1.3.2統計削除行
コード統計の線の1.4総数
1.5倍に設定すると、変更を示すためにマーク
1.6プログラムの頭の中で記録的な増加を変更
第四に、タスク分解法
タスク分解処理
分解
- アナロジー：類似プロジェクトへのWBSの参照
- テンプレート：、共通のテンプレートを介してそれらを追加または削除
- トップダウン
- ボトムアップ
WBSテンプレートの例
分解 - 上から下へ
分解 - ボトムアップ
分解作業構造（WBS）ステップ
プロジェクトの構成要素を特定し、打破
OK分解標準
ダウン詳細なブレークかどうかを確認
プロジェクトの成果を決定します
分解の正しさを確認してください（ビルド番号）
WBS番号付けシステム
WBSとOBS（組織ブレークダウンストラクチャ）
標準的な分解
- 生存
- 機能性成分
分解基準は均一でなければなりません
学生管理
人生の分解によると、
-
- エンコードのテストを提出した計画と設計要件
- 分解生成物の組成によると、
- 1.1入学管理
- 1.2プレースメントの管理
- 1.3学生レコード管理
- 1.4生徒の成績管理
- あなたは、両方の規格分解を使用することはできません
- 入学管理配置管理、学生の記録管理のデザイン生徒の成績管理計画は、符号化テストを提出する必要があります
分解試験規格の結果
- プロジェクトマネージャーが変化するのでサイズおよび数のWBS分解は、プロジェクトによって異なり
- プロジェクトに関連するすべての情報を収集
- 似たものをプロジェクトWBS、利害関係者との協議を参照してください。
- テンプレートは、最低のレベルを指す制御及び管理可能であるが、不必要な小さすぎ、好ましくは7つの以上の層を回避することができます
- 推奨ソフトウェアプロジェクトのタスク分解40時間
- 注：8分の80のルール
- 各ワークパッケージは、提出を持っている必要があります
- タスクの標準的な定義が完了しています
- 各WBSは、責任の配分に資するなければなりません
- あなたは、WBS辞書を用意することができます
- 利害関係者との最後のレビュー
WBS辞書コンテンツ
