Transcript ユースケース名
ﾌﾟﾛｼﾞｪｸﾄ 開始
ユースケースポイント法 ＜ユースケースポイント法とは＞ プロジェクトが完了するまでの工数（人時）を、ユースケースに 基づいて見積もる。 具体的には、アクターのタイプとユースケースの複雑さをベース とし、それを技術要因（技術的な難しさ）と環境要因（メンバーの 経験レベル）を加味して補正する。
UCP
＝
UUCP
×
TCF
×
EF
UUCP （未調整 UCP ）＝①＋② TCF （技術要因の重み）＝ 0.6
＋（ 0.01
×③） EF （環境要因の重み） ＝ 1.4
＋（－ 0.03
×④）
工数＝
UCP
×
20
人時
UCP
×
28
人時 （危険指数
≦
（危険指数＝
2 3
） 又は
4
） ﾌﾟﾛｼﾞｪｸﾄの再計画（危険指数
≧ 5
）
ただし、 危険指数＝ EF の E1 ～ E6 で 2 以下の数＋ E7 ～ E8 で 4 以上の数 All Rights Reserved Copyright © 2004, Takashi Kobayashi 1
ﾌﾟﾛｼﾞｪｸﾄ 開始
ユースケースポイント法
＜アクターの重み付け＞ タイプ 単純 平均 複雑 意味 プログラムによるインタフェース 対話型またはプロトコルのインタフェース グラフィカルインタフェース アクター名 係数 理由 係数 1 2 3 合計 ① All Rights Reserved Copyright © 2004, Takashi Kobayashi 2
ﾌﾟﾛｼﾞｪｸﾄ 開始
ユースケースポイント法
＜ユースケースの重み付け＞ タイプ 単純 平均 複雑 意味 3 以下のトランザクション／ 4 以下の分析クラス 4 ～ 7 のトランザクション／ 5 ～ 10 の分析クラス 8 以上のトランザクション／ 11 以上の分析クラス ユースケース名 係数 理由 係数 5 10 15 合計 ② All Rights Reserved Copyright © 2004, Takashi Kobayashi 3
ﾌﾟﾛｼﾞｪｸﾄ 開始
ユースケースポイント法
＜技術要因（ Technical Complexity Factor ）の重み付け＞（係数は 0 ～ 5 の 6 段階） 要因 意味 重み 係数 値 理由 T1 T2 T3 T4 T5 T6 T7 分散ｼｽﾃﾑ ﾚｽﾎﾟﾝｽ / ｽﾙｰﾌﾟｯﾄ性能を重視 ｵﾝﾗｲﾝでｴﾝﾄﾞﾕｰｻﾞの効率を重視 内部処理が複雑 ｺｰﾄﾞを再利用する ｲﾝｽﾄｰﾙしやすい 使いやすい 2 1 1 1 1 0.5
0.5
T8 T9 T10 T11 T12 移植性が高い 変更しやすい 並列処理を行なう 特別なｾｷｭﾘﾃｨ機能が必要 第三者に直接ｱｸｾｽを提供 2 1 1 1 1 T13 特別なﾕｰｻﾞﾄﾚｰﾆﾝｸﾞが必要 合計 1 ③ All Rights Reserved Copyright © 2004, Takashi Kobayashi 4
ﾌﾟﾛｼﾞｪｸﾄ 開始
ユースケースポイント法
＜環境要因（ Environmental Factor ）の重み付け＞（係数は 0 ～ 5 の 6 段階） 要因 意味 重み 係数 値 理由 E1 E2 採用するﾌﾟﾛｾｽに慣れている その分野での開発経験がある 1.5
0.5
E3 E4 E5 E6 E7 採用する方法論に慣れている ﾌﾟﾛｼﾞｪｸﾄﾘｰﾀﾞの能力が高い ﾌﾟﾛｼﾞｪｸﾄに対するやる気がある 要件が安定している ﾒﾝﾊﾞｰにﾊﾟｰﾄﾀｲﾑｽﾀｯﾌがいる 1 0.5
1 2 -1 E8 難しいﾌﾟﾛｸﾞﾗﾐﾝｸﾞ言語を使用 合計 -1 ④ All Rights Reserved Copyright © 2004, Takashi Kobayashi 5
ﾌﾟﾛｼﾞｪｸﾄ 開始
見積りの演習問題
今回は、インターネット入試システムの全体機能のうち、①出願手続、②選抜、③合格発表の３つの ユースケースを対象としたシステムを構築する。 これらのユースケースのうち、③はトランザクションが３個以下の単純な処理であり、 ①と②は４個か ら７個の平均的な処理である。また、教官や学生課にはグラフィカルな使いやすい画面を提供し、志願 者にはメールによるインタフェースを提供する。 技術的な難しさとしては、次の点があげられる。 ・レスポンスとオンラインでの効率性を重視している。 ・エンドユーザが計算機に不慣れであるため、プログラムのインストールが容易で、使い勝手がよくな ければならない。 ・教官や学生課の担当者がマルチユーザのスタイルで利用する。 ・入試のルールは変わりやすいのでシステムの拡張性が必要。 ・入試業務という性格上、セキュリティが極めて大事。 これら以外の項目に関しては、平均的なレベルとする。特に、コードの再利用や移植性に関しては、予 算の都合上考慮しないことにする。 環境要因としては、次の点が気になるところである。 ・開発メンバーの顔ぶれを見ると、今回採用する段階的なシステム開発のプロセスに慣れている人が いない。 ・入試関係のシステムの構築は初めてである。 ・オブジェクト指向技術を全面的に採用する予定であるが、この技術に詳しいメンバーがいない。 また、プラス要因としては、次の２点があげられる。 ・メンバーは全員専任であり、このプロジェクトの成功を確信して燃えている。 ・入試業務の仕様は検討に検討を重ねており、要件が変更することはない。 さらに、プロジェクトリーダの能力は平均レベルであり、プログラミング言語は PHP という新しいが習熟 しやすいものを採用する。 All Rights Reserved Copyright © 2004, Takashi Kobayashi 6
ﾌﾟﾛｼﾞｪｸﾄ 開始
見積りの演習問題
インターネット入試 サポートシステム 入学資格審査 登録手続き 志願者 受験準備 出願手続き 選抜 合格発表 入学手続き 学生課 教官 All Rights Reserved Copyright © 2004, Takashi Kobayashi 7
ﾌﾟﾛｼﾞｪｸﾄ 開始
見積りの演習問題
■ユースケース名：選抜 ■要約：入学願書、学業成績、論文、面談に基づいて合格者を決める。 ■基本パス： 1.
2.
3.
4.
5.
教官は、志願者が提出した入学願書、学業成績、論文に基づいて書類審査合格者 を決める。 教官は、書類審査不合格者に、メールで連絡する。 教官は、書類審査合格者と、メールで面談の日程を決める。 教官は、書類審査の内容に関して面談を実施する。 教官は、書類審査と面談の結果に基づいて最終合格者を決める。 ■拡張パス： 1a. 論文の内容に不明点がある： 1a1.
教官は、志願者にメールで問い合わせる。 ■トリガー：出願手続きが終了。 ■事前条件：入学願書、学業成績、論文が準備完了。 ■事後条件：最終合格者のリストが作成済み。 All Rights Reserved Copyright © 2004, Takashi Kobayashi 8