參與者的特性：
- 參與者位於系統外部，它不屬於系統的一部分，所以我們不需要去建造參與者。
- 只有會使用系統，會跟系統互動，會跟系統交換資訊者，才會視系統的參與者。
- 參與者會啟動、參與使用案例，所以找到參與者，就可以引道我們找到使用案例。
- 我們雖然不需要建造參與者，但是卻需要考慮介面。系統需要提供介面讓參與者使用，或者系統需要使用到參與者提供的介面。
尋找參與者的問題表：
- 誰會來使用這個系統？
- 誰會來安裝這個系統？
- 誰會來啟動這個系統？
- 誰會來維護這個系統？
- 誰會來關閉這個系統？
- 那些其他的系統會來使用這個系統？
- 誰會從這個系統取得資訊？
- 誰會提供資訊給這個系統？
- 在預設的時間到時，有時麼事情會自動發生嗎？
- 那些其他的系統會與這個系統連線的？
- 可有硬體設備會與這個系統連線？
- 那些資料庫會與這個系統連線？
- 公司內部有哪些人員會來使用這個系統？
- 公司外部可有什麼樣的人士會來使用這個系統？
- 當特定的時間或事件發生時，這個系統需要自動通知什麼人，或者是自動通知其他系統嗎？
參與者種類表：
| 種類 | 細項 | 參與者 |
| 人 | 公司內部的人 | |
| 公司外部的人 | ||
| 系統 | 其他系統（內部） | |
| 其他系統（外部） | ||
| 硬體設備 | ||
系統簡述：
- 系統名稱：
- 系統簡述：＜用三兩句話點出系統的主要特色＞
- 重點整理：
- ＜最好可以使用條列式的方式，將討論到的或者想到重要的，一一條列下來，方便日後回顧。＞
使用案例的問題表：
- 參與者想要從這個系統獲得什麼樣的功能？
- 這個系統儲存資訊嗎？那些參與者將建立、讀取、更新或刪除這些資訊？
- 當系統內部狀態有變動時，這個系統需要通知參與者嗎？
- 是否有什麼外部事件是這個系統需要知道的？當這些外部事件發生時，那些參與者會通知這個系統？
- 這個系統需要定期執行什麼工作嗎？
- 當發生了某些重要的外部事件時，這個系統需要自動執行什麼工作嗎？
- 這個使用案例的名稱夠明確嗎？是不是可以從這個使用案例的名稱，直接判斷出它的產出？
- 這個使用案例會有多樣產出結果嗎？還是這些產出結果，其實是在不同的時間點產出的？
使用案例要點表：
| 使用案例 | 要點 | 說明 |
| 名稱 | 產出 | |
| 重要步驟 | ||
| 議題 |
使用案例敘述最簡版：
- 使用案例：＜名稱＞
- 事件流程：
- ＜起始點＞
- ＜終結點＞
替代流程的問題表：
- 在這個流程步驟上頭，是否還有其他替代的動作？
- 在這個流程步驟上頭，是否會發生什麼樣的錯誤？
- 在整個使用案例執行過程中，是否隨時可能發生其他未記錄在敘述中的動作？
- 參與者輸入資料時，是否會提供不完整的資料，需要重新補上的？
- 是否會出現錯誤的資料，需要特別處理的？
- 參與者是否會在操作期間，臨時中斷流程？
- 參與者是否會在使用案例期間，隨時取消互動？
- 參與者是否會想要挑選其他的執行方法？
- 參與者在流程執行過程中，會不會有需要協助的地方？
- 系統發生當機時，是否需要特殊的處置？
- 系統反應時間過長時，是否需要特殊的對應方法？
替代流程分類表：
- 替代流程：
- 替代1：不完整的資料
- 替代2：錯誤的資料
- 替代3：取消或中斷操作
- 替代4：其他的執行方法
- 替代5：需要協助
- 替代6：系統當機或無回應
包含關係要點表：
- 需要共享的相同流程，才能夠獨立出來
- 暫存資料或者存取資料庫的動作，不要輕易獨立出來。
- 如果只是一兩句相同的流程敘述，不需要大費周章地獨立出來。
擴充關係要點表：
- 謹慎地使用擴充關係，避免因為濫用擴充關係，而讓使用案例圖變得很難理解。
- 擴充關係通常使用在系統上線之後的改版，可以在不變動已經寫好的使用案例敘述的情況下，利用擴充關係，加上一段新的使用案例敘述，以滿足新的需求。
- 不一定會執行的流程，可以放置在替代流程中；要是想要跟其他使用案例共用這段流程的話，也可以改用擴充關係。
切分次系統使用案例的步驟表：
- 判斷原先的系統使用案例比較適合分配給哪個次系統，然後幫這個次系統新增一個同名的次系統使用案例。
- 再者，原先的系統使用案例敘述中，大部分的流程步驟，都留給這個同名的次系統使用案例。
- 然後，將不適合流在新的次系統使用案例中的其餘步驟切分出來，分配給其他次系統，形成其他次系統內部的次系統使用案例。在分派的時候，可以趁機再一次檢視並修訂使用案例敘述，成為新的次系統使用案例敘述。
- 接著，更新次系統的使用案例圖，以及重新整理次系統使用案例敘述。
- 最後，繪製其他次系統的使用案例圖，以及撰寫這些次系統使用案例敘述。
使用案例圖和使用案例敘述的完整性檢視：
- 您是否有發現任何新的參與者？以及，是否有哪些參與者是不需要的？
- 是否有任何參與者不小心被移進系統內了？或者，有任何事物應該位於系統內部，可是卻不小心被移到系統外了？
- 是否所有參與者的名稱和說明都是有意義，而且閱讀者都能夠容易理解？
- 您是否有發現任何新的使用案例？是否有遺漏掉任何使用案例呢？
- 是否所有使用案例的名稱和敘述都是有意義，而且閱讀者都能夠容易理解？
- 在所有的使用案例敘述中，是否至少描述了一條主要流程？
- 在所有的使用案例敘述中，是否都有描述替代流程？
決定使用案例的細膩度：
- 誰需要閱讀並且逼准這份使用案例敘述文件？
- 誰需要使用這份使用案例敘述文件？
- 這份使用案例敘述文件用來做什麼的？
估計工時=>
使用案例點計算公式：
未經調整的使用案例點=參與者總權重+使用案例總權重 技術複雜因子=0.6+(0.01*技術總權重) 環境因子=1.4+(-0.03*環境總權重) 使用案例點=未經調整的使用案例點*技術複雜因子*環境因子 工時=使用案例點*20人時(或28人時) 參與者加權值： 簡單型參與者：這類型的參與者通常是其他系統，採用程是介面與我們所開發的系統互動。簡單型參與者的加權值是1。 一般型參與者：這類型的參與者有兩種：第一種是採用特殊協定互動的其他系統；第二種是採用文字模式互動的人類使用者。普通型參與者的加權值是2。 複雜型參與者：這類型的參與者就是我們常見的人類使用者，採用豐富且親和力高的圖形介面。複雜型參與者的加權值是3。 使用案例加權值(依業務量)： 簡單型使用案例：這類型的使用案例擁有少於3個的業務量，它的加權值是5。 一般型使用案例：這類型的使用案例擁有4～7個的業務量，它的加權值是10。 複雜型使用案例：這類型的使用案例擁有多於7個的業務量，它的加權值是15。 使用案例加權值(依物件量)： 簡單型使用案例：這類型的使用案例使用了少於5種的分析物件，它的加權值是5。 一般型使用案例：這類型的使用案例使用了5～10種的分析物件，它的加權值是10。 複雜型使用案例：這類型的使用案例使用了多於10種的分析物件，它的加權值是15。 技術因子和加權值
(強烈等級評分：0是最弱的，3是中等強度，5是最強烈的等級。)
因子 說明 加權值 強烈等級 技術權重 T1 分散式系統
2 T2 反應時間(連線)
1 T3 終端使用者效能
1 T4 複雜的內部處理
1 T5 程式碼可重用程度
1 T6 容易安裝
0.5 T7 容易使用
0.5 T8 便於攜帶
2 T9 容易更改
1 T10 同步性
1 T11 包含特殊的安全機制
1 T12 提供直接存取給第三方
1 T13 特殊的使用者培訓設施要求
1 環境因子和加權值
(強烈等級評分：0是最弱的，3是中等強度，5是最強烈的等級。)
因子 說明 加權值 強烈等級 技術權重 E1 熟悉循環式開發方法
1.5 E2 應用領域的經驗
0.5 E3 物件導向的經驗
1 E4 分析師的能力
0.5 E5 幹勁
1 E6 穩定的需求
2 E7 兼職的工作人力
-1 E8 困難的程式語言
-1 負面因子：
E1～E6，強烈等級低於3的個數；E7～E8，強烈等級高於3的個數；兩個數字加總，即為負面因子個數。 ≦2：專案的總負面因子少於或等於2時，可以採用20人時來估算。 3～4：專案的總負面因子個數等於3或4時，可以採用28人時來估算。 ≧5：專案的總負面因子個數大於或等於5時，專案失敗的可能性非常高，最好可以調整專案，直到專案的負面因子個數降到5以下為止。
沒有留言:
張貼留言