第一個步驟是市場調研，技術和市場要結合才能體現最大價值。 第二個步驟是需求分析，這個階段需要出三樣東西，使用者檢視，資料詞典和使用者操作手 冊。 使用者檢視是該軟體使用者（包括終端使用者和管理使用者）所能看到的頁面樣式，這裡麵包含了 很多操作方面的流程和條件。 資料詞典是指明資料邏輯關係並加以整理的東東，完成了資料詞典，資料庫的設計就完成 了一半多。 使用者操作手冊是指明瞭操作流程的說明書。 請注意，使用者操作流程和使用者檢視是由需求決定的，因此應該在軟體設計之前完成，完成 這些，就為程式研發提供了約束和準繩，很遺憾太多公司都不是這樣做的，因果顛倒，順 序不分，開發工作和實際需求往往因此產生隔閡脫節的現象。 需求分析，除了以上工作，筆者以為作為專案設計者應當完整的做出專案的效能需求說明 書，因為往往效能需求只有懂技術的人才可能理解，這就需要技術專家和需求方（客戶或 公司市場部門）能夠有真正的溝通和了解。 第三個步驟是概要設計，將系統功能模組初步劃分，並給出合理的研發流程和資源要求。 作為快速原型設計方法，完成概要設計就可以進入編碼階段了，通常採用這種方法是因為 涉及的研發任務屬於新領域，技術主管人員一上來無法給出明確的詳細設計說明書，但是 並不是說詳細設計說明書不重要，事實上快速原型法在完成原型程式碼後，根據評測結果和 經驗教訓的總結，還要重新進行詳細設計的步驟。 第四個步驟是詳細設計，這是考驗技術專家設計思維的重要關卡，詳細設計說明書應當把 具體的模組以最＇乾淨＇的方式(黑箱結構）提供給編碼者，使得系統整體模組化達到最 大；一份好的詳細設計說明書，可以使編碼的複雜性減低到最低，實際上，嚴格的講詳細 設計說明書應當把每個函式的每個引數的定義都精精細細的提供出來，從需求分析到概要 設計到完成詳細設計說明書，一個軟體專案就應當說完成了一半了。換言之，一個大型軟 件系統在完成了一半的時候，其實還沒有開始一行程式碼工作。 那些把作軟體的程式設計師簡單理解為寫程式碼的，就從根子上犯了錯誤了。 第五個步驟是編碼，在規範化的研發流程中，編碼工作在整個專案流程裡最多不會超過1/ 2，通常在1/3的時間，所謂磨刀不誤砍柴功，設計過程完成的好，編碼效率就會極大提 高，編碼時不同模組之間的進度協調和協作是最需要小心的，也許一個小模組的問題就可 能影響了整體進度，讓很多程式設計師因此被迫停下工作等待，這種問題在很多研發過程中都 出現過。編碼時的相互溝通和應急的解決手段都是相當重要的，對於程式設計師而言，bug永 遠存在，你必須永遠面對這個問題，大名鼎鼎的微軟，可曾有連續三個月不發補丁的時候 嗎？從來沒有！ 第六個步驟是測試 測試有很多種： 按照測試執行方，可以分為內部測試和外部測試 按照測試範圍，可以分為模組測試和整體聯調 按照測試條件，可以分為正常操作情況測試和異常情況測試 按照測試的輸入範圍，可以分為全覆蓋測試和抽樣測試 以上都很好理解，不再解釋。 總之，測試同樣是專案研發中一個相當重要的步驟，對於一個大型軟體，3個月到1年的外 部測試都是正常的，因為永遠都會又不可預料的問題存在。 完成測試後，完成驗收並完成最後的一些幫助文件，整體專案才算告一段落，當然日後少 不了升級，修補等等工作，只要不是想透過一錘子買賣騙錢，就要不停的跟蹤軟體的運營 狀況並持續修補升級，知道這個軟體被徹底淘汰為止。
第一個步驟是市場調研，技術和市場要結合才能體現最大價值。 第二個步驟是需求分析，這個階段需要出三樣東西，使用者檢視，資料詞典和使用者操作手 冊。 使用者檢視是該軟體使用者（包括終端使用者和管理使用者）所能看到的頁面樣式，這裡麵包含了 很多操作方面的流程和條件。 資料詞典是指明資料邏輯關係並加以整理的東東，完成了資料詞典，資料庫的設計就完成 了一半多。 使用者操作手冊是指明瞭操作流程的說明書。 請注意，使用者操作流程和使用者檢視是由需求決定的，因此應該在軟體設計之前完成，完成 這些，就為程式研發提供了約束和準繩，很遺憾太多公司都不是這樣做的，因果顛倒，順 序不分，開發工作和實際需求往往因此產生隔閡脫節的現象。 需求分析，除了以上工作，筆者以為作為專案設計者應當完整的做出專案的效能需求說明 書，因為往往效能需求只有懂技術的人才可能理解，這就需要技術專家和需求方（客戶或 公司市場部門）能夠有真正的溝通和了解。 第三個步驟是概要設計，將系統功能模組初步劃分，並給出合理的研發流程和資源要求。 作為快速原型設計方法，完成概要設計就可以進入編碼階段了，通常採用這種方法是因為 涉及的研發任務屬於新領域，技術主管人員一上來無法給出明確的詳細設計說明書，但是 並不是說詳細設計說明書不重要，事實上快速原型法在完成原型程式碼後，根據評測結果和 經驗教訓的總結，還要重新進行詳細設計的步驟。 第四個步驟是詳細設計，這是考驗技術專家設計思維的重要關卡，詳細設計說明書應當把 具體的模組以最＇乾淨＇的方式(黑箱結構）提供給編碼者，使得系統整體模組化達到最 大；一份好的詳細設計說明書，可以使編碼的複雜性減低到最低，實際上，嚴格的講詳細 設計說明書應當把每個函式的每個引數的定義都精精細細的提供出來，從需求分析到概要 設計到完成詳細設計說明書，一個軟體專案就應當說完成了一半了。換言之，一個大型軟 件系統在完成了一半的時候，其實還沒有開始一行程式碼工作。 那些把作軟體的程式設計師簡單理解為寫程式碼的，就從根子上犯了錯誤了。 第五個步驟是編碼，在規範化的研發流程中，編碼工作在整個專案流程裡最多不會超過1/ 2，通常在1/3的時間，所謂磨刀不誤砍柴功，設計過程完成的好，編碼效率就會極大提 高，編碼時不同模組之間的進度協調和協作是最需要小心的，也許一個小模組的問題就可 能影響了整體進度，讓很多程式設計師因此被迫停下工作等待，這種問題在很多研發過程中都 出現過。編碼時的相互溝通和應急的解決手段都是相當重要的，對於程式設計師而言，bug永 遠存在，你必須永遠面對這個問題，大名鼎鼎的微軟，可曾有連續三個月不發補丁的時候 嗎？從來沒有！ 第六個步驟是測試 測試有很多種： 按照測試執行方，可以分為內部測試和外部測試 按照測試範圍，可以分為模組測試和整體聯調 按照測試條件，可以分為正常操作情況測試和異常情況測試 按照測試的輸入範圍，可以分為全覆蓋測試和抽樣測試 以上都很好理解，不再解釋。 總之，測試同樣是專案研發中一個相當重要的步驟，對於一個大型軟體，3個月到1年的外 部測試都是正常的，因為永遠都會又不可預料的問題存在。 完成測試後，完成驗收並完成最後的一些幫助文件，整體專案才算告一段落，當然日後少 不了升級，修補等等工作，只要不是想透過一錘子買賣騙錢，就要不停的跟蹤軟體的運營 狀況並持續修補升級，知道這個軟體被徹底淘汰為止。