關鍵字：用例設計
軟件開發項目計劃為項目管理服務的，本文用項目管理的眼光去看待項目計劃的內容。應用本文的方法制定的項目計劃可以： 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. 部署軟件
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/