ＰＭＢＯＫのお勉強 その４６ － １０．１

今、

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

のお勉強をしています。

前回で９章はおわり。

今回から

１０章　プロジェクト・コミュニケーション・マネジメント

で今回は１０．１章です

---

■１０．１　ステークホルダー特定


＜＜インプット＞＞

・プロジェクト憲章

・調達文書

・組織体の環境要因

・組織のプロセス資産


＜＜ツールと技法＞＞

・ステークホルダー分析
　　以下の手順で行う
　　　手順１：かかわりを持つ可能性のある全てのステークホルダーの特定
　　　　　　　と関連情報を特定
　　　手順２：ステークホルダーの分類
　　　　　　　　分類モデルには以下のようにあるが、これらに限定されない
　　　　　　　　　　・権力と関心度のグリッド
　　　　　　　　　　・権力と関与度のグリッド
　　　　　　　　　　・関与度と影響度のグリッド
　　　　　　　　　　・セイリエンス・モデル
　　　手順３：主要なステークホルダーがどう反応し、対応するか評価


・専門家の判断


＜＜アウトプット＞＞

・ステークホルダー登録簿
　　以下のような事項が全て含まれるが、これらに限定されない
　　　　・識別情報
　　　　・評価情報
　　　　・ステークホルダー分類


・ステークホルダー・マネジメント戦略
　　以下のような要素が含まれる
　　　　・プロジェクトに重大な影響を与える主要なステークホルダー
　　　　・ステークホルダーに望まれる、プロジェクトの参加度合い
　　　　・ステークホルダーのグループとマネジメント
　　一般にステークホルダー・マネジメント戦略の表示は、
　　　ステークホルダー分析マトリックスである。

初めてのＲｕｂｙを読む その４５ ９．３

「初めてのRuby」を読むの続き

今日は

９章　本書を越えて

９．３　データベース

から

---

■データベース

・各種のデータベースに対応するライブラリがgem形式で提供されている
　→ActiveRecordライブラリを利用する
　　　→Ruby on railsで利用されているＯ／Ｒマッピングライブラリ

---

９．３は、これだけ（＾＾；）

ペルソナ分析は、非機能要件抽出の確認に使えるかもしれない

ペルソナ分析というのがある。
利用者、消費者などの、ある人物像を明確にするために、その人物は、どういう人かというプロフィールを明確にして(ペルソナ）、それにもとづき、この人ならこう考えるだろうという分析をしていく方法

詳しくは

３．ペルソナ分析
http://www.videoi.co.jp/diagnosis/persona.html

がわかりやすいですかね・・・

ペルソナ法を用いたユーザ中心の要求分析方法
http://www.seto.nanzan-u.ac.jp/msie/gr-thesis/it/proc/2003/00mt056.pdf

なんていう卒論もあるくらい（南山の青山先生のところ）


　で、これなんだけど、話聞いてると、非機能要件の検証というか、確認のときに向いていると思った。

---

　要求獲得作業において、そのシステムにかかわるステークホルダーと、その考え方（価値観）を分析する。まあ、それにＣＡＴＯＷ分析なんかが使われるんだけど、このとき、ステークホルダーのペルソナも明確にしておく。

　その場合、たとえば、「社長」なんていうのは会社に１人だから、その人のペルソナでいいけど、
　ユーザーとか言う場合、いろんな種類のひとがいるわけで、その典型例を数人（いくつかのペルソナ）用意しておく。

　要求分析になると、そのシステムの機能や成果物をもとに、ユースケース（利用場面？）をきめて、それ(＝ユースケース）にかかわる人や他システム（アクター）を明確化していく。

　ユースケースが細かくなり、入出力と手順がはっきり言える時点で、そのユースケースの内容を記述する（ユースケース記述やアクティビティ図で）。

　で、機能要件がきまるので、今度は、機能要件に対する非機能要件を、チェックリストなどを利用したり、ヒアリングなどで抽出する。

---

　で、問題は、この機能要件、非機能要件の検証をしないといけない。


　機能要件の検証の仕方は、ある程度見えている。

　入力(事前条件）に対して手順どおりのアクティビティを行ったら、出力（事後条件）が得られるか、

　そのとき、制約（不変条件）に違反していないかを確かめればいい。
　確かめる気になるのであれば、形式仕様を使って確かめることも出来る。

---

　問題は、非機能要件。
　デッドロックなどについては、モデル検査で確認できる。
　問題は、ルックアンドフィールなどの確認。

　明確な方法はなかった。

　だけど、ペルソナを使えば、ここで

　「このペルソナの人が、
　　このユースケースにおいて、
　　こういう風になってたら、
　　こう感じるよね」

　というのは、確認できそうな気がする。
　こういう風に感じるはずというのを、モデル化というか、明文化できれば、検証も出来そうな気がする

　そういう意味で、「ペルソナ分析は、非機能要件抽出の確認に使えるかもしれない」

11月7日(月)のつぶやき

23:39 from gooBlog production
ライブドアの社名消滅、「データホテル」へ http://t.co/WiG1PwYT
by xmldtp on Twitter