ユースケースポイント法

1. ﾌﾟﾛｼﾞｪｸﾄ 開始 ユースケースポイント法 ＜ユースケースポイント法とは＞ 　プロジェクトが完了するまでの工数（人時）を、ユースケースに基づいて見積もる。 　具体的には、アクターのタイプとユースケースの複雑さをベースとし、それを技術要因（技術的な難しさ）と環境要因（メンバーの経験レベル）を加味して補正する。 • UCP＝ UUCP×TCF×EF • UUCP （未調整UCP）＝①＋② • TCF （技術要因の重み）＝0.6＋（0.01×③） • EF （環境要因の重み） ＝1.4＋（－0.03×④） • UCP×20 人時 （危険指数≦2 ） • 工数＝ 　 UCP×28 人時 （危険指数＝3又は4 ） • 　　　　 　 ﾌﾟﾛｼﾞｪｸﾄの再計画（危険指数≧5） • 　　ただし、　危険指数＝EFのE1～E6で2以下の数＋E7～E8で4以上の数

2. ﾌﾟﾛｼﾞｪｸﾄ 開始 ユースケースポイント法 ＜アクターの重み付け＞

3. ﾌﾟﾛｼﾞｪｸﾄ 開始 ユースケースポイント法 ＜ユースケースの重み付け＞

4. ﾌﾟﾛｼﾞｪｸﾄ 開始 ユースケースポイント法 ＜技術要因（Technical Complexity Factor）の重み付け＞（係数は0～5の6段階）

5. ﾌﾟﾛｼﾞｪｸﾄ 開始 ユースケースポイント法 ＜環境要因（Environmental Factor）の重み付け＞（係数は0～5の6段階）

6. ﾌﾟﾛｼﾞｪｸﾄ 開始 見積りの演習問題 　今回は、インターネット入試システムの全体機能のうち、①出願手続、②選抜、③合格発表の３つのユースケースを対象としたシステムを構築する。 　これらのユースケースのうち、③はトランザクションが３個以下の単純な処理であり、 ①と②は４個から７個の平均的な処理である。また、教官や学生課にはグラフィカルな使いやすい画面を提供し、志願者にはメールによるインタフェースを提供する。 　技術的な難しさとしては、次の点があげられる。 ・レスポンスとオンラインでの効率性を重視している。 ・エンドユーザが計算機に不慣れであるため、プログラムのインストールが容易で、使い勝手がよくなければならない。 ・教官や学生課の担当者がマルチユーザのスタイルで利用する。 ・入試のルールは変わりやすいのでシステムの拡張性が必要。 ・入試業務という性格上、セキュリティが極めて大事。 これら以外の項目に関しては、平均的なレベルとする。特に、コードの再利用や移植性に関しては、予算の都合上考慮しないことにする。 　環境要因としては、次の点が気になるところである。 ・開発メンバーの顔ぶれを見ると、今回採用する段階的なシステム開発のプロセスに慣れている人がいない。 ・入試関係のシステムの構築は初めてである。 ・オブジェクト指向技術を全面的に採用する予定であるが、この技術に詳しいメンバーがいない。 また、プラス要因としては、次の２点があげられる。 ・メンバーは全員専任であり、このプロジェクトの成功を確信して燃えている。 ・入試業務の仕様は検討に検討を重ねており、要件が変更することはない。 さらに、プロジェクトリーダの能力は平均レベルであり、プログラミング言語はPHPという新しいが習熟しやすいものを採用する。

7. 志願者 学生課 教官 ﾌﾟﾛｼﾞｪｸﾄ 開始 見積りの演習問題 インターネット入試 サポートシステム 入学資格審査 登録手続き 受験準備 出願手続き 選抜 合格発表 入学手続き

8. ﾌﾟﾛｼﾞｪｸﾄ 開始 見積りの演習問題 ■ユースケース名：選抜 ■要約：入学願書、学業成績、論文、面談に基づいて合格者を決める。 ■基本パス： • 教官は、志願者が提出した入学願書、学業成績、論文に基づいて書類審査合格者を決める。 • 教官は、書類審査不合格者に、メールで連絡する。 • 教官は、書類審査合格者と、メールで面談の日程を決める。 • 教官は、書類審査の内容に関して面談を実施する。 • 教官は、書類審査と面談の結果に基づいて最終合格者を決める。 ■拡張パス： 1a. 論文の内容に不明点がある： 1a1.　教官は、志願者にメールで問い合わせる。 ■トリガー：出願手続きが終了。 ■事前条件：入学願書、学業成績、論文が準備完了。 ■事後条件：最終合格者のリストが作成済み。