進行編碼、集成。也免不了會發(fā)現(xiàn)設計、需求不對的地方，對需求進行加的加，改的改，刪的刪。
5. 基于編碼的結果進行測試，以驗證軟件是否達到了需求。我們常常發(fā)現(xiàn)這時的需求與設計之前的需求已有了很大的變化。
6. 發(fā)布（部署）產(chǎn)品，進行項目收尾。
如果某一時間，客戶要知道項目進行到哪了，我們告訴他設計已完成，正進行編碼工作。當有需求變更時，相關的需求、設計又要來過。客戶能不懷疑我們的回答么？

解決方法

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

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

如果我們仔細查看項目的所有工作，會發(fā)現(xiàn)有些工作不是基于某個用例的，也與某些用例沒有直接關系，如何拿用例來計算它的工作量呢？在項目的開發(fā)中確定存在這些工作，如項目開始時的“了解軟件項目的故事”。但通過分析知道，在一個軟件項目中頂層用例的數(shù)量是不難預測的，也是說在這個時期要向關鍵人了解的用例數(shù)是可以預測的。我們不難發(fā)現(xiàn)，要了解的用例數(shù)越多，需求了解的工作量就越大。在相同類型的應用軟件開發(fā)中，需求了解的工作量與用例數(shù)量的比例是基本一致的。同理，了解系統(tǒng)隱喻，構造軟件框架、部署軟件的工作量與用例的量也是成比例的。

在沒有不熟習技術的前提下，根據(jù)本人的經(jīng)驗，同類軟件項目的工期與底層用例數(shù)或步驟數(shù)有著可計算的關系，如WEB應用軟件

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html