ＰＭＢＯＫのお勉強 その３７ － ７．２

（今日は理由あって、ＰＭＢＯＫを２つやります。
　あしたＲｕｂｙを２つやります）

今、

プロジェクトマネジメント　知識体系ガイド（PMBOKガイド）第４版
http://www.amazon.co.jp/dp/1933890681

のお勉強をしています。

前回は７．１章だったので、今回は７．２章です

---

■予算設定


＜＜インプット＞＞

・アクティビティ・コスト見積もり
　　７．１より

・見積もりの根拠
　　７．１より

・スコープベースライン
　　・スコープ記述書

　　・ワークブレークダウンストラクチャ
　　　　５．３より

　　・ＷＢＳ辞書
　　　　５．３より

・プロジェクトスケジュール
　　　　６．５より

・資源カレンダー

・契約

・組織のプロセス資産


＜＜ツールと技法＞＞
・コスト集約

・呼び設定分析

・専門家の判断
　　専門知識の情報源は以下のようなものがあるが、
　　これに限定されない
　　　　・母体組織内のほかの部門
　　　　・コンサルタント
　　　　・顧客を含むステークホルダー
　　　　・専門家の協会や技術関連の団体
　　　　・業界団体

・過去の関係

・限度額による資金調整


＜＜アウトプット＞＞
・コスト・パフォーマンス・ベースライン

・プロジェクト資金要求事項

・プロジェクト文書更新版
　　以下のものがあるが、これに限定されない
　　　　・リスク登録簿
　　　　・コスト見積もり
　　　　・プロジェクトスケジュール

ＰＭＢＯＫのお勉強 その３６ － ７．１

今、

プロジェクトマネジメント　知識体系ガイド（PMBOKガイド）第４版
http://www.amazon.co.jp/dp/1933890681

のお勉強をしています。

前回は６．６章でした。

今回から、

第７章　プロジェクト・コスト・マネジメント

に入ります。今回は、７．１章です

---

■７．１　コスト見積もり

＜＜インプット＞＞

・スコープ・ベースライン
　　スコープ記述書
　　　　５．２より
　　ワーク・ブレークダウン・ストラクチャー
　　　　５．３、４．３より
　　ＷＢＳ辞書
　　　　５．３より


・プロジェクト・スケジュール
　　　　６．３，６．４より


・人的資源計画書
　　　　９．１より


・リスク登録簿
　　　　１１．２より

・組織体の環境要因

・組織のプロセス資産


＜＜ツールと技法＞＞

・専門家の判断


・類推見積もり


・係数見積もり


・ボトムアップ見積もり


・三点見積もり
　　次の３点の見積もりを行う
　　　　最頻値
　　　　楽観値
　　　　悲観値

・予備設定分析


・品質コスト
　　８．１より

・ベンダー入札の分析


＜＜アウトプット＞＞

・アクティビティ・コスト見積もり


・見積もりの根拠
　　詳細資料としては、以下のものがある
　　　　・見積もりの根拠を記した文書
　　　　・すべての前提条件を記した文書
　　　　・すべての既知の制約条件を記した文書
　　　　・見積もり範囲の表示
　　　　・最終見積もりの信頼性レベルの提示


・プロジェクト文書更新版

「標準ソフトウエア工学教科書」を作ってみたいと思います その１５ ３．３

土日ではなくなってしまいましたが（＾＾；）

土日シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は、外部設計です。

---

■３．３　外部設計

　前回、要求分析で要求をだしたので、次に、この要求を満たすシステムを設計していきます。
　設計については、ここで、２つに分けて考えます。

　　１．ユーザーや外部システム等（ユースケースのアクター）で見える部分。
　　　　→インターフェース、特にユーザーインターフェース（ＵＩ）

　　２．ユーザーや外部システム等（ユースケースのアクター）で見えない部分

　１は外部に見えるところなので、外部設計、２は、内部部分なので、内部設計となります。
　今回は、このうち、外部設計について行います。

------

　外部設計に関して、一番大きな部分は、
　　　１．ユーザーとのインターフェースを決める、ユーザーインターフェース
　　　２．他システムがアクセスするＤＢ、ファイル部分
　　　３．Ｗｅｂサービス等の場合、通信部分のインターフェース（引数と返り）
　　　４．２．３の基本となるコード化

　画面メッセージを分ける場合もありますけど、それは、１に含まれると、ここでは考えましょう。
　２に関して、先ほどの説明だと、他に見えるところだけでもいいのでは？と思うかもしれませんが、このテーブルは見えて、あのテーブルは外部に出さないので、設計しないとなると、検証できなくなってくるので、この場合、外に見えるか否かにかかわらず、全体を設計します。

　なお、ユーザーインターフェースとの矛盾をチェックするために、仮に他システムがＤＢ、ファイルにアクセスしないとしても、外部設計でＤＢ、ファイル設計するのが普通だと思います。

　なお、４のコード化設計は行うのですが、１、２をしているときに自動的に出来てしまうので、意識して行うのは、１のＵＩ、２のＤＢ，ファイル定義で、最近のＷｅｂサービスにおいて、３を考えるという形です。
　なお、以降面倒なので、ＤＢ，ファイル設計と書かずに、ＤＢ設計としてしまいます。

--------------

　では、ＵＩ，ＤＢをどのように設計していくかですが、まず、前提について、確認してみます。
　前提として、要求仕様では、こんなことをしているのでした。

（１）プロジェクトの目的と、プロジェクトマネージャーは決まっている状態で、

（２）えらい人からえらくない人へ、仕事を分割していく
　　　→その仕事の範囲をざっくりと図や文にまとめる

（３）最終的に、仕事を受け持つ担当者に行き着く
　　　担当者のやるべきことを、入力と出力に着目して、記述する
　　　→機能要求

（４）機能要求以外（非機能要求）を何らかの方法で、えいやときめる（＾＾；）

（５）機能要求、非機能要求を要求仕様書という形でまとめる


つまり、（３）の段階で、入力と出力は、決まっているはずです。
なので、この入出力を検討します。

（あ）（３）の入出力を、画面、帳票、ＤＢなど、メディアごとに分ける。

（い）画面について
　　　　（い－１）画面全体のルックアンドフィールを決める
　　　　　　　→全体的な画面イメージ
　　　　　　　　（背景、大きなレイアウト、ナビゲーション等）

　　　　（いー２）（あ）で抽出した画面を、１画面にするか、複数のものを
　　　　　　　　　まとめるかなど考慮して、画面割りをきめる。

　　　　（い－３）画面をどのように遷移させていくか、画面遷移をきめる
　　　　　　　　　　　→追加する画面が出てくるかも

　　　　（い－４）各画面の画面レイアウトを決める

　　　　（い－５）い－３、い－４をまとめて、画面定義書とする
　　　　　　　　つまり、画面定義書は、画面遷移図と画面レイアウトからなる

　　　　（い－６）お客さんにチェックしてもらって、承認を得る


（う）ＤＢについて
　　　　（う－１）どのようなテーブルがいるか決める
　　　　　　　→正規化したりして

　　　　（う－２）テーブルの項目などを決める

　　　　（うー３）テーブルの妥当性を確認する
　　　　　　　　・入力したデータで、必要なものは保存されているか
　　　　　　　　・容量などの見積もりで、無茶はないか？

　帳票に関しては（い）の画面を帳票にかえて読み替えてください。ただし帳票遷移はありえないので、そこは無視します（い－３はない）
　Ｗｅｂサービスに関しては、（う）のテーブルをサービスに読み替えてください。
　　　　　

（え：成果物）結果として、画面定義書、ＤＢ定義書、帳票定義書、サービス定義書ができます。

------------

　Webアプリケーションの場合、画面をＨＴＭＬで記述しておくと、レイアウトは画面イメージを貼るだけだし、お客さんと確認するとき、ブラウザを使ってプレゼンできます（＝プロトタイプになる）。
　このＨＴＭＬで画面をつくるということが、後工程でとても楽になることなのですが、
　それは、後工程の話としておいておきます。

　上記のやり方だと、画面・帳票のレイアウト、遷移に関しては、この外部設計の段階で確定し、ＤＢはおおよそ決まります（内部設計や実装で変更もありえる）。

　ただし、画面設計はそこまでやらないという考えもあります。
　項目をこの段階では確定させない（確定できない）という考え方で、その場合、画面定義書は、内部設計でつくられます。
　が、この方法の場合、お客さんに見せるのがもっと後になり、画面が内部設計中に動くので、内部設計にダイナミックな修正が入ります。これを嫌う場合、ここ（＝外部設計）で大まかに確定してしまいます。

---