用例設計在軟體開發專案計劃中的應用（轉）

前言
軟體開發專案計劃為專案管理服務的，本文用專案管理的眼光去看待專案計劃的內容。應用本文的方法制定的專案計劃可以：
1. 讓專案的時間、成本、進度的估算可以透過簡易的公式進行一次性計算得到
2. 讓不瞭解專案實現技術的人，如客戶、投資者、管理者及願意瞭解專案的人員很容易地瞭解專案的時間、成本、進度的狀態及其完工估算
3. 讓專案工作量的分配更具體、更客觀，對成員的績效表現顯而易見
4. 使專案之間的工作績效具有可比性

例項
一般情況下我們的專案計劃是這樣的：
1. 第一層是專案開發的實際階段
2. 第二層是所在階段的工作
3. 第三層是對較大工作量的工作做進一步分解

問題
這樣的計劃有以下幾個缺點：
1. 不適應迭代開發的工作模式。多數應用軟體的開發不是純粹“瀑布開發模型”，當到達後面的階段時，不可避免的發現以前階段的工作沒有真正完成，需要繼續進行。例如，設計階段時，極有可能會發現分析需求階段中漏了一個功能沒有考慮進去，以致分析需求階段沒有真正完成而需要繼續。
2. 計劃的實際執行資料不能作為專案的完成估算的依據。 比如調研和需求確認階段完成時，依據該階段的實際執行資料不能預知專案將在什麼時間結束，在什麼成本範圍完成。有以下幾個原因：
1) 階段本身的界限是不清晰的
2) 階段之間的時間、成本、進度的分配關係並不確定
3. 這些估算資料難以被以後的開發計劃所借鑑。當一個專案或一個階段結束後，我們總會想在這個已執行完成的計劃的上面得到一點關於估算方面的經驗或教訓，如：
1) 這個專案的總開發成本與其他專案相比，是多了還是少了？
2) 設計分析階段的時間分是不是不與專案的需求不匹配？
3) 哪個階段的成本分配有問題？
4) 各項工作的平均時間合不合適？
按上面的計劃，我們不能夠很好的回答這些問題，是因為這個計劃是按階段來劃分的，實際工作中，這些階段的界限並不明顯，無法得到準確的資料。
4. 當需求變更時，不知把這些變更的工作放入專案計劃的哪個階段。因為這些變更往往包含了很多的階段。有人建議把它們放到一個叫做“需求變更”的特殊階段中，但這些變更是不可預知的，它幾乎分佈到專案的整個開發過程中，我們又如何在計劃是反應它們呢？

實際過程
在介紹本文的方法以前，瞭解RUP(rational unified process) 的朋友，知道軟體開發過程並不是我們想象的如此簡單。它告訴我們在同一個時間內所有的開發階段是有可能共存的。也是說整個開發過程可以是多個迭代同時進行。
我們回顧一下日常的開發過程：
1. 得知有一個專案需要開發。有可能是老闆告訴你的，也可能是業務部門告訴你的，總之我們要為它而工作了，同時確信老闆同意開始這個專案
2. 對這個專案涉及的人員及其需求進行調查。這裡的需求包括了所有專案的需求，比如老闆對這個專案的要求及期望，使用者對這個專案的期望，開發人員對這個專案的期望。這時，我們很快會發現，調查所有人是不可能的，調查所有需求也是不可能的。因此，
1) 我們會先找幾個關鍵人物，瞭解他們的期望，確定系統的邊界（或叫輪廓，XP(Extreme Programming)中把它叫系統隱喻）；
2) 再把系統劃分為幾個部分，確定先做哪個部分後做哪個部分；
3) 再一個一個部分對需求進行調查
當我們在調查的時候，常常會發現新的部分之間的關聯，這使我們不得不對這兩個部分的內容進行檢查，加的加，改的改，刪的刪。
3. 基於調查的結果進行設計。這個時間，我們經過對這些需求的分析、歸類，設計一個開發的模型以支援這些需求。設計時也免不了會發現需求不對的地方，對需求進行加的加，改的改，刪的刪。
4. 基於設計的結果進行編碼、整合。也免不了會發現設計、需求不對的地方，對需求進行加的加，改的改，刪的刪。
5. 基於編碼的結果進行測試，以驗證軟體是否達到了需求。我們常常發現這時的需求與設計之前的需求已有了很大的變化。
6. 釋出（部署）產品，進行專案收尾。
如果某一時間，客戶要知道專案進行到哪了，我們告訴他設計已完成，正進行編碼工作。當有需求變更時，相關的需求、設計又要來過。客戶能不懷疑我們的回答麼？

解決方法
做過軟體開發的人就會知道，上面的過程描述中有很大的問題。我們的做過程並沒有錯，一個一個需求，一個一個功能的實現，有變更時就一個一個變更的實現，大家都這樣做，也只有這樣做。對於一個應用軟體專案來講，而不太可能真正的按軟體書上寫的過程一個一個過程的做下去，集中10天做完所有的需求，集中20天內做完所有設計。
做的過程沒有錯，把過程描述出來，為什麼就錯了？原因很簡單：我們在描述時，總喜歡套用一些“模式”，一些書寫的“方法”，而不是按實際的過程描述。如果我們不套用任何模式，將會如何呢？我們再來描述一遍上面的過程：
1. 瞭解軟體專案的故事（story）。開始一個軟體應用專案，瞭解關鍵人物都有哪些？他們要求是一個什麼樣的系統？把這些要求描述成一個一個的故事，如果稍稍規範一點。就會象這樣：
1) 這個系統的目標是為了誰解決什麼問題
2) 第一步做什麼，系統反饋什麼
3) 第二步做什麼，系統反饋什麼
4) …
5) 問題解決了，結束本故事
我們會仔細的看這些故事，發現有些地方看不懂，於是我們就去問清楚，有些事情是那個描述故事的A也不清楚的，但A告訴我們B會懂，於是我就問B；有些事情A也不知道有誰會知道，我們就把它放在一邊，等知道的時候再問，繼續看其他的故事。
2. 瞭解系統隱喻，構造軟體框架。永遠也問不清楚所有的事情，所以當我們知道整個系統的是為了解決什麼問題，將用什麼辦法來解決它（暫時叫做系統隱喻），關鍵人物也認可時，我們就不再問下去了。我們依據這個系統隱喻去構造一個最上面的故事。然後，只關心與這個故事有關的故事。同時構造一個程式框架以支援專案的開發
3. 實現故事。在軟體框架上，實現一個故事，再實現一個故事，…
4. 實現變更。有時發現事情並沒有想象的簡單，於是就變更它，這就要求我們實現這些次變更。它象實現故事一樣：實現一次變更，再實現一次變更，…
5. 部署軟體。感覺軟體已達到了可被接受的預想或合適的要求了，就釋出這個軟體。

上面所說的故事就是我們常說的用例（use case）。我們可以使用用例的形式來描述整個系統的計劃內容，並計算它的工作量，為工作之間、專案之間的績效提供一個統一的衡量標準。
這時，我們發現：
1. 由故事（有些專案可以用故事所包含的步驟）的數量可計算出開發的工作量
2. 我們實際開發工作過程的時間、成本、進度是可以被不瞭解專案實現技術的人所感知的

如果我們仔細檢視專案的所有工作，會發現有些工作不是基於某個用例的，也與某些用例沒有直接關係，如何拿用例來計算它的工作量呢？在專案的開發中確定存在這些工作，如專案開始時的“瞭解軟體專案的故事”。但透過分析知道，在一個軟體專案中頂層用例的數量是不難預測的，也是說在這個時期要向關鍵人瞭解的用例數是可以預測的。我們不難發現，要了解的用例數越多，需求瞭解的工作量就越大。在相同型別的應用軟體開發中，需求瞭解的工作量與用例數量的比例是基本一致的。同理，瞭解系統隱喻，構造軟體框架、部署軟體的工作量與用例的量也是成比例的。

在沒有不熟習技術的前提下，根據本人的經驗，同類軟體專案的工期與底層用例數或步驟數有著可計算的關係，如WEB應用軟體中，一個底層故事的開發時間大約為1.5個人日。這個是經驗資料，在不同的公司可能有所不同。網上也有文章證明不同規模的應用軟體，故事與程式程式碼的行數有一定的計算關係。這樣我們的不同專案，或同一專案的不同故事之間，在時間、成本、進度上就具有了可比性。
同時，我們發現：
3. 讓專案的時間、成本、進度的估算可以透過簡易的公式進行一次性計算得到
4. 讓專案工作量的分配更具體、更客觀，對成員的績效表現顯而易見
5. 使專案之間的工作績效具有可比性

要注意的問題
1. 在不同層次上的用例有著不一樣的工作量比例，一定要分清。比如WEB應用軟體的用例可以這樣劃分：
用例層次　 對應系統的物件
頂層　　　 專案，如網上商城
上層　　　 子系統，如網上商城＼使用者管理
中層　　　 流程，如網上商城＼使用者管理中＼註冊流程
底層　　　 頁面，如網上商城＼使用者管理中＼註冊流程＼第一個頁面
2. 這種用例與工作量的比例關係，是建立一定量的基礎之上的，比如20個以上才有這個比例關係。對於一般應用軟體的計劃及績效的計算是合適的，但對於個例是不適用的，不能憑這個比例來衡量某幾個用例的工作量。

總結
好了，下面總結一下本文方法的實現步驟：
1. 瞭解軟體專案的故事。從專案關鍵人物那瞭解到系統的主要故事有哪些，併力求描述清楚
2. 瞭解系統隱喻，構造軟體框架
3. 實現故事。先實現頂層故事；再一個一個故事實現
4. 故事變更。實現一次變更，再實現一次變更，…
5. 部署軟體[@more@]