軟件產品WBS分解指引

1、軟件產品WB分解指南薇一、概述蒂同任何事物一樣，一個軟件產品或軟件系統(tǒng)也要經歷孕育、誕生、成長、成熟、衰亡等階段，一般 稱為“軟件生命周期”。軟件生命周期模型，通俗說就是，軟件開發(fā)過程中所遵循的模式，即把整個軟件 生存周期劃分為若干階段，使得每個階段有明確的任務，使規(guī)模大，結構復雜和管理復雜的軟件開發(fā)變的 容易控制和管理。蒁軟件生命周期模型和項目開發(fā)過程有非常緊密關系，它是經過多次實踐總結出來適合于不同項目使 用的經典、有效的軟件開發(fā)方法，它按照軟件生命周期的各個階段劃分任務，依照一定的規(guī)則和步驟，有 效地進行軟件開發(fā)。蚈選用恰當?shù)能浖芷谀Ｐ瓦M行軟件開發(fā)，可以提高產品質量；降低項目管理難

2、度；縮短開發(fā)進度；便于項目狀態(tài)跟蹤；為過程改進和度量提供基線；改善組織級的過程弱勢，提高過程能力成熟度級別。蚆為了便于分類匯總和統(tǒng)計各種生命周期模型的指標和數(shù)據(jù)，結合公司軟件開發(fā)過程的實際，我們選擇了常用的幾種基本模型進行了描述，項目開發(fā)小組在進行項目策劃時，可以根據(jù)模型的適用前提、優(yōu)缺點和項目的實際需要進行選擇，并在項目實施計劃中，參加評審。羈二、軟件生命周期模型芁常用的軟件生命周期模型有：瀑布模型、迭代模型、增量模型、原型模型等。螀以上所提到的件生命周期模型病不存在孰優(yōu)孰劣的問題，每一種模型在實際工作中都有所應用。只 要選擇了最適合的，并按照此模型的流程來開發(fā)軟件，都會取得成功。襖需要強調

3、的是，不管采用什么模型，項目實施中有四項活動是必不可少的需求、設計、編碼和 測試。不管是有意識還是無意識，這些活動都會出現(xiàn)在項目過程中。這也是最重要的四項活動，其他的活 動其實都是為這些活動服務的，不管是配置管理、風險管理，還是評審等等。蚅以下對各種常用的軟件生命周期模型的設計思想、WB劃分（Work Breakdown Structure ，即工作分解結構）、優(yōu)缺點、使用范圍進行分析。羂1、瀑布模型薇（ 1）基本思想膇瀑布模型（ Waterfall Model ）是最基本也最常用的一種生命周期模型，又稱線性模型。肄瀑布模型是一個項目開發(fā)架構，開發(fā)過程是通過設計一系列階段順序展開的，從系統(tǒng)需求

4、分析開始 直到產品發(fā)布和維護，每個階段都會產生循環(huán)反饋，因此，如果有信息未被覆蓋或者發(fā)現(xiàn)了問題，那么最 好 “返回”上一個階段并進行適當?shù)男薷模?項目開發(fā)進程從一個階段 “流動 ”到下一個階段， 這也是瀑布模型 名稱的由來。瀑布模型可以應用于軟件工程開發(fā)、企業(yè)項目開發(fā)、產品生產以及市場銷售等領域。螂瀑布模型的突出特征是文檔驅動。從需求分析到系統(tǒng)維護，每一項活動的工作成果就是此項活動所 產生的工作文檔，以及在此基礎上形成的產品。薈采用瀑布模型的項目依照該模型選定的階段順序進行，每一個階段的工作產品都是下一個階段工作 的輸入，每一個階段只有在上一個階段通過檢查，確認完成后才開始新的階段工作，所以項

5、目必須有明確 的階段里程碑，在每個階段結束時都要進行里程碑評審，以判定是否可以開始下一階段的工作。例如：在項目策劃沒有完成時，需求分析和設計工作就不能進行，同樣，在需求分析和設計沒有完成時就不開始編 碼。瀑布模型中，每個階段完成后，可以在下一個階段修改上一個階段的工作產品，但是必須按照基線 變更進行管理，如果發(fā)生變更，需要回溯前面所有階段的工作產品，以便使工作產品保持一致。螃說明：莁圖中標記為 播的階段為選定的里程碑，該階段完成時需進行里程碑評審活動，并對其輸出進行嚴格 的變更控制。芇（2）WBS戈U分羄此表僅作為參考，需根據(jù)項目所選定的標準過程的活動和任務進一步細化。膃階段和荿ID莆任務薂工

6、作成果名稱膂項目標準過 程蒅1羈起草項目任務書螞項目任務書袇2蚅審批項目任務書腿已批準的項目任務書羅3膄策劃準備衿項目實施計劃肄4薃啟動項目策劃蕿產品的功能結構圖、 WBS工作任務分解袂項目策劃階段莀項目頭施計劃：工作量估計，進度計劃，人力資源計劃，蒆5羃項目估計和成果列表軟/硬件、工具要求，風險管理計劃，培訓計劃，溝通計劃，膆項目策劃管交付工作產品清單等理規(guī)范薄6莂制訂項目計劃肀項目實施計劃（有些客戶需要 質量保證計劃（方案）、配置管理計劃（方案）等相關計劃）羇7袂項目計劃評審袁按照項目評審管理規(guī)范 的規(guī)定，QA組織對項目實施計 戈q組織評審，直到通過評審肅8薅審批項目計劃薁項目實施計劃獲得

7、相關領導的審批聿需求分析階段羄9莁需求調研袇開始按照需求調研計劃，米取需求調研記錄表進仃 調研，完成系統(tǒng)需求分析說明書初稿膄需求開發(fā)與莄10肂需求分析羈如果客戶需求不清晰需要密切跟蹤，要完成需求調研記錄管理規(guī)范跟蹤矩陣、需求不一致項列表螂需求不一致項袃肇相關修訂文檔，可能包括系統(tǒng)需求分析說明書和需求11罿協(xié)商處理不致項列表等文件薂螇需求規(guī)格說明書完善膅系統(tǒng)需求分析說明書正式稿、需求跟蹤管理表12螇需求規(guī)格說明書完善芃需求冋級評審相關記錄。聿13袈需求驗證肁驗證后的系統(tǒng)需求分析說明書、需求跟蹤管理表罿螅按照項目評審管理規(guī)范 的規(guī)定，QA組織對需求分析說14蚆需求分析階段評審明書的評審蚇15螄里程

8、碑評審（可選）芄完成項目里程碑報告并組織評審芀分析設計階肇蚃概要設計羀概要設計相關技術資料段螈分析設計管理規(guī)范16芅17肅設計文檔編寫螁概要設計說明書薇18蒂概要設計評審（可選）蒁概要設計說明書的評審（建議詳細設計或概要設計必須做一個正式評審）蚆19羈詳細設計芁詳細設計相關工具和技術資料襖20蚅文檔編寫羂詳細設計說明書腿21肄用戶界面設計螂用戶界面設計說明書芅22蒄數(shù)據(jù)庫設計腿數(shù)據(jù)庫設計說明書蚇23袃詳細設計評審罿設計評審記錄項目評審報告螆24莂里程碑評審（可選）蠆完成項目里程碑報告并組織評審蕿實現(xiàn)開發(fā)階螂蒀編程薀源代碼段25賺襖產品實現(xiàn)管26膀代碼走杳莇代碼走杳檢杳單理規(guī)范裊27羀單元測試葿

9、單元測試報告芄28蟻初步完成三大手冊芆初步完成系統(tǒng)安裝手冊用戶操作手冊項目維護手冊祎測試階段莁29芇集成測試羄測試bug清單螃項目測試管膂理規(guī)范30荿測試文檔莆項目測試計劃、測試用例、測試報告薂部署運行膆31蒅部署安裝使用羈系統(tǒng)部署用戶確認書需要用戶確認袂系統(tǒng)部署管膈理規(guī)范32袇客戶培訓蚅客戶培訓簽到表客戶培訓效果調杳表腿驗收羅膄內部驗收32衿在正式部署之前完成。項目內部驗收評審報告艿項目驗收管理規(guī)范肄33薃客戶驗收蕿客戶驗收計劃、客戶驗收報告羃34莀結項申請腿結項申請表膈結項階段蒆項目結項管莂35肀結項總結羆結項總結報告理規(guī)范袂36袁總結會議肇結項總結肅維護階段薁維護計劃審批維護工作啟動制定

10、項目維護計劃并通過審批37薅項目運行維38維護報告項目結束維護，完成項目維護總結報告護管理規(guī)范(3)優(yōu)缺點該模型的優(yōu)點： 階段分明、活動明確，為軟件開發(fā)工作提供一種結構化、有序的方法;每一階段是在上一階段徹底完成的情況下 過程控制可見性較強：按照順序開展每一個階段的工作,才啟動，可以保證每一個階段的開發(fā)質量都有保證，減少了返工; 開發(fā)過程中的各項文檔降低了溝通的成本，有利于及早發(fā)現(xiàn)問題，降低項目的階段成本; 文檔多，過程記錄比較全，有利于后期維護。該模型的缺點： 不能回溯： 項目從開始到發(fā)布可見的版本需要較長的周期， 用戶直到項目開發(fā)晚期才能了解產品的 真實面貌和質量，不易變更；如果必須回溯，

11、則回溯成本很大。 缺乏靈活性，不能跨階段操作； 文檔多，花費較多成本。（ 4）適用范圍 產品定義（或項目需求）和技術方案非常明確、用戶的需求有很好的了解； 對質量的要求高于對成本和進度的要求； 工期相對較寬裕； 開發(fā)隊伍技術力量較弱或缺乏經驗； 維護項目。2、迭代模型（ 1）基本思想迭代模型是RUP（ Rational Unified Process，統(tǒng)一軟件開發(fā)過程）推薦的周期模型。在 RUP中，迭代被定義為：迭代包括產生產品發(fā)布（穩(wěn)定、可執(zhí)行的產品版本）的全部開發(fā)活動和要使用該發(fā)布必需的所有其他外圍元素。在某種程度上，開發(fā)迭代是一次完整地經過所有工作流程的過程：需求、分析設計、實施和測試工

12、作流程。實質上，它類似小型的瀑布式項目。RU認為，所有的階段都可以細分為迭代。每一 次的迭代都會產生一個可以發(fā)布的產品，這個產品是最終產品的一個子集。圖2迭代模型的思想示意圖說明:迭代模型沿著螺線進行若干次迭代，圖中的四個象限代表了以下活動： 制定計劃：確定軟件目標，選定實施方案，弄清項目開發(fā)的限制條件； 風險分析：分析評估所選方案，考慮如何識別和消除風險； 實施工程：實施軟件開發(fā)和驗證； 客戶評估：評價開發(fā)工作，提出修正建議，制定下一步計劃。迭代模型由風險驅動， 強調可選方案和約束條件從而支持軟件的重用，有助于將軟件質量作為特殊目標融入產品開發(fā)之中。使用迭代模型進行軟件開發(fā)，項目活動包含以下

13、幾個階段： 初始階段初始階段有時也稱先啟階段。 初始階段的目標是為系統(tǒng)建立商業(yè)案例并確定項目的邊界。為了達到該目的必須識別所有與系統(tǒng)交互的外部實體，在較高層次上定義交互的特性。本階段具有非常重要的意義， 在這個階段中所關注的是整個項目進行中的業(yè)務和需求方面的主要風險。對于建立在原有系統(tǒng)基礎上的開 發(fā)項目來講，初始階段可能很短。 細化階段細化階段的目標是分析問題領域，建立健全的體系結構基礎， 編制項目計劃，淘汰項目中最高風險的 元素。為了達到該目的，必須在理解整個系統(tǒng)的基礎上，對體系結構做出決策，包括其范圍、主要功能和諸如性能等非功能需求。同時為項目建立支持環(huán)境，包括創(chuàng)建開發(fā)案例，創(chuàng)建模板、準則

14、并準備工具。 構造階段在構建階段，所有剩余的構件和應用程序功能被開發(fā)并集成為產品，所有的功能被詳細測試。從某種意義上說，構建階段是一個制造過程，其重點放在管理資源及控制運作以優(yōu)化成本、進度和質量。 交付階段交付階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代， 包括為發(fā)布做準備的產品測試，基于用戶反饋的少量的調整。在生命周期的這一點上，用戶反饋應主要集中在產品調整， 設置、 安裝和可用性問題，所有主要的結構問題應該已經在項目生命周期的早期階段解決了。畑-1廠一一一-一迭代«迭代知14一迭暑一1分楊和遜計一負i&U-_-M鐵補芟傅工作克項目諫一- 環(huán)壇圖3迭代模

15、型的幾個階段(2) WBS劃分實際采用迭代模型中， 項目階段仍可參考瀑布執(zhí)行。迭代模型實施重要的關鍵點是架構設計（概要設計）、制定迭代開發(fā)計劃。階段和 項目標準過程任務工作成果名稱項目策劃階段完成項目實施計劃項目實施計劃中 WBS分解要參考本表項目策劃管理規(guī)范項目迭代計劃（）項目迭代開發(fā)計劃必須有架構設計（概要設計）項目迭代開發(fā)計劃必須說明哪些是關鍵迭代，完成的時機以及預期成果下一個迭代，在前幾個迭代基礎上需要完善的要 點以及完善步驟架構（概要）設計（）概要設計說明書系統(tǒng)完成架構設計（概要設計）詳細需求分析、設計及實現(xiàn)第1個迭代需求分析迭代1的需求分析，形成需求說明書需求評審關鍵迭代需要組織評

16、審詳細設計直接做詳細設計，完成迭代設計說明書文檔編寫詳細設計說明書用戶界面設計用戶界面設計說明書數(shù)據(jù)庫設計數(shù)據(jù)庫設計說明書編程源代碼代碼走查按照項目實施計劃中質量控制點計劃要求完成代碼走杳檢杳單單元測試按照項目實施計劃中質量控制點計劃要求完成單元測試報告第一個迭代部署/集成按照項目迭代開發(fā)計劃 將迭代開發(fā)成果部署到統(tǒng) 一架構中。第一個迭代集成測試迭代后的開發(fā)成果部署到統(tǒng)一架構后做集成測試詳細需求分析、設計及按照項目迭代開發(fā)計劃 中的規(guī)劃實現(xiàn)，如果實現(xiàn)實現(xiàn)第2個迭代計劃有變化需要變更該計劃。詳細需求分析、設計及實現(xiàn)第N個迭代按照項目迭代開發(fā)計劃 中的規(guī)劃實現(xiàn)，如果實現(xiàn) 計劃有變化需要變更該計劃。

17、測試階段項目測試管理規(guī)范所有迭代按照 項目迭代開發(fā)計劃 全部實現(xiàn)后，需 要做系統(tǒng)測試。(3)優(yōu)缺點與傳統(tǒng)的瀑布模型相比較，迭代模型具有以下優(yōu)點： 降低了在一個增量上的開支風險。如果開發(fā)人員重復某個迭代，那么損失只是這一個開發(fā)有誤的迭代的花費； 降低了產品無法按照既定進度進入市場的風險。通過在開發(fā)早期就確定風險，可以盡早來解決而不至于在開發(fā)后期匆匆忙忙； 加快了整個開發(fā)工作的進度。因為開發(fā)人員清楚問題的焦點所在，他們的工作會更有效率； 由于用戶的需求并不能在一開始就做出完全的界定，它們通常是在后續(xù)階段中不斷細化的。因此， 迭代過程這種模式使適應需求的變化會更容易些。迭代模型的缺點： 風險管理成本

18、較高： 迭代模型本身強調風險，但風險管理本身也存在成本問題；如果風險管理成本過大，將會嚴重影響項目的利潤； 對項目組成員的要求非常高：在風險分析、進度管理等方面，需要有較高層次的人員配置及豐富的項目管理和項目實施的經驗。這對于開發(fā)隊伍技術力量較弱或缺乏經驗的團隊很難實施。(4)適用范圍 在項目開發(fā)早期需求可能有所變化; 分析設計人員對應用領域很熟悉; 高風險項目； 用戶可不同程度地參與整個項目的開發(fā)過程； 使用面向對象的語言或統(tǒng)一建模語言（Unified Modeling Language ， UML）； 使用 CASE （ Computer Aided Software Engineerin

19、g ，計算機輔助軟件工程）工具，如 Rose （ Rose是非常受歡迎的物件軟體開發(fā)工具）； 具有高素質的項目管理者和軟件研發(fā)團隊。3、增量模型（1）基本思想增量模型是通過對用戶需求的判斷，在定義了用戶要求和系統(tǒng)需求，進行總體構架設計后，采用序列化地創(chuàng)建產品的方法進行開發(fā)的過程。每一個線性序列產生軟件的一個可發(fā)布的“增量”，第一個建立的增量完成預計功能/性能的一部分（往往包含了核心功能，即實現(xiàn)了基本的需求），下一個增量實現(xiàn)另外的部分，增加更多的功能 /性能，然后與前面實現(xiàn)的增加進行集成，如此循環(huán)，直到系統(tǒng)完全實現(xiàn)。增量模型的特點是引進了增量包的概念，無須等到所有需求都出來，只要某個需求的增量包

20、出來即可進行開發(fā)。雖然某個增量包可能還需要進一步適應客戶的需求并且更改，但只要這個增量包足夠小，其影響對整個項目來說是可以承受的。其實現(xiàn)過程簡圖如下所示：圖4增量模型的思想示意圖說明:在策劃階段，項目經理需要與客戶協(xié)商確定增量的數(shù)目、規(guī)模、每一增量發(fā)布的時間表，在概要設計階段需要考慮各增量集成的順序、接口等問題，制定集成策略。增量循環(huán)的循環(huán)體可以根據(jù)項目的實際情況進行控制。增量模型本質上是迭代的， 但其強調每一個增量均發(fā)布一個可操作產品。早期的增量是最終產品的“可拆卸”版本，但提供了為用戶服務的功能，并且為用戶提供了評估的平臺。(2) WBS劃分階段和 項目標準過程任務工作成果名稱概要設計概要

21、設計概要設計相關技術資料、設計文檔編寫概要設計說明書概要設計評審（必須）設計評審記錄設計實現(xiàn)開發(fā)第一個增量（如A模塊）詳細設計A模塊詳細設計文檔編寫詳細設計說明書用戶界面設計用戶界面設計說明書數(shù)據(jù)庫設計數(shù)據(jù)庫設計說明書編程源代碼代碼走查代碼走杳檢杳單單元測試單元測試報告第一個增量測試增量產品測試發(fā)布第一個增量增量產品發(fā)布和部署設計實現(xiàn)開發(fā)第二個增量（如B模塊）詳細設計B模塊詳細設計文檔編寫詳細設計說明書用戶界面設計用戶界面設計說明書數(shù)據(jù)庫設計數(shù)據(jù)庫設計說明書編程源代碼代碼走查代碼走杳檢杳單單元測試單元測試報告第一個增量測試增量產品測試發(fā)布第一個增量增量產品發(fā)布和部署開發(fā)第N個增量(3)優(yōu)缺點該

22、模型的優(yōu)點:在達到初始需求之前可降低成本：采用增量模型可以靈活分配人員,剛開始不用投入大量人力資源。如果核心產品很受歡迎，則可增加人力實現(xiàn)下一個增量;可快速生產出可使用的系統(tǒng)：它提供了一種先推出核心產品的途徑,這樣即可先發(fā)布部分功能給客戶，對客戶起到鎮(zhèn)靜劑的作用;能夠有計劃地管理技術風險。該模型的缺點：系統(tǒng)集成難度大：由于各個構件是逐漸并入已有的軟件體系結構中的,各增量的集成難度增大，所以在概要設計階段需要制定詳細的集成策略；項目管理風險加大： 在開發(fā)過程中，需求的變化是不可避免的，增量模型的靈活性可以使其適應這種變化的能力大大優(yōu)于瀑布模型和快速原型模型, 程的控制失去整體性。但也很容易退化為

23、邊做邊改模型，從而使軟件過(4)適用范圍 用戶核心需求非常清楚; 項目人員不足； 產品可以分割成不同的階段分別完成。4、原型模型（1）基本思想原型模型通過向用戶提供原型獲取用戶的反饋，使開發(fā)出的軟件能夠真正反映用戶的需求。同時，原型模型采用逐步求精的方法完善原型，使得原型能夠“快速”開發(fā)，避免了像瀑布模型一樣在冗長的開發(fā) 過程中難以對用戶的反饋做出快速的響應。相對瀑布模型而言，原型模型更符合人們開發(fā)軟件的習慣，使 目前較流行的一種實用軟件生存期模型。原型模型是一種用戶需求驅動的方法，使得用戶在系統(tǒng)生存周期的設計階段起到積極的作用；它能減少系統(tǒng)開發(fā)的風險，特別是在大型項目的開發(fā)中，由于對項目需求

24、的分析難以一次完成，應用原型法效果更為明顯。原型模型根據(jù)其最終保留情況分為非拋棄型和拋棄型兩種：非拋棄型原型是先根據(jù)用戶的最主要的要求，開發(fā)出能實現(xiàn)系統(tǒng)最基本功能的一個原型，再根據(jù)用戶對原型使用與評價的意見，反復修改完善原型，直到等到用戶滿意的最終系統(tǒng)為止。原型模型從需求收集開始，軟件開發(fā)組與目標用戶一起定義軟件的總體目標，標識出已知的需求， 并規(guī)劃出進一步定義的區(qū)域。然后是“快速設計”。 快速設計建立軟件中對用戶可見的部分，即“原型”原型由用戶評估，并據(jù)此進一步精化用戶需求。逐步調整原型使其滿足用戶的要求，同時也使開發(fā)組對該軟件有 更好的理解，這個過程是迭代的，每一個迭代完成后均可生成一個可

25、用的產品版本。拋棄型原型模型一般用來描述和驗證用戶需求， 可以采用與實際開發(fā)所不同的開發(fā)工具， 建立模擬的數(shù)據(jù)庫系統(tǒng)，從而達到與用戶交流的最好效果。到用戶需求確定之后即不再繼續(xù)開發(fā)此原型。與非拋棄型原型模型的主要區(qū)別在于： 目的不同，拋棄型原型模型的目的是為了與用戶更好的溝通； 手段不同，拋棄型原型模型采用的技術手段與正式開發(fā)可以完全不同； 結果不同，拋棄型原型模型的工作產品不會在軟件研發(fā)中使用或大量使用，而多用于開發(fā)demo及驗證用戶需求的復合性。使用原型模型進行軟件開發(fā)，項目活動包含以下幾個階段： 確定用戶需求階段軟件項目負責人員根據(jù)用戶意向或市場調研等前期準備的資料、文檔， 對用戶需求進

26、行分析， 編寫用戶需求文檔。 建造 /修改原型階段項目組根據(jù)原型評價結果對設計原型進行建立、修改和完善，并記錄相關過程。 運行 /評價原型階段項目負責人協(xié)同市場人員與用戶對設計原型進行評價和討論，明確設計原型中要保留的和需去除的原型設計部分，提出需要進一步補充和完善的需求內容。重復上述過程，直至用戶需求全部明確為止。各階段需要遵循的項目標準過程參見PD 項目標準過程裁剪指南。圖6原型模型開發(fā)的幾個階段(2) WBS劃分非拋棄型原型模型的WB劃U分階段和過程ID從過程中選取任務工作成果名稱用戶需求分析需求開發(fā)與管理規(guī)范1獲取用戶需求需求調研記錄單2建立系統(tǒng)需求需求分析說明書3驗證需求已經驗證的軟

27、件系統(tǒng)需求建造/修改原型產品實現(xiàn)管理規(guī)范4搭建開發(fā)環(huán)境開發(fā)環(huán)境5編寫代碼源代碼、產品原型運行/評價原型6運行評價原型更新后需求分析說明書拋棄型原型模型的WB劃分任務類型ID任務工作成果名稱用戶需求分析1需求調查和分析需求調研記錄單建造/修改原型2用戶界面設計原型界面3與用戶交流修改界面修改后的原型界面4建立模擬數(shù)據(jù)庫模擬數(shù)據(jù)庫5開發(fā)源代碼，原型6功能測試及修改測試記錄和通過測試的工作產品運行/評價原型7原型運行冋題記錄表8評價原型原型評價表(3)優(yōu)缺點該模型的優(yōu)點: 符合人們認識事物的規(guī)律，系統(tǒng)開發(fā)循序漸進，反復修改，確保較好的用戶滿意度; 開發(fā)周期短，費用相對少; 由于有用戶的直接參與，系統(tǒng)

28、更加貼近實際，易學易用，減少用戶的培訓時間；該模型的缺點： 開發(fā)過程管理要求高，整個開發(fā)過程要經過“修改一評價一再修改”的多次反復； 用戶過早看到系統(tǒng)原型，誤認為系統(tǒng)就是這個模樣，易使用戶失去信心； 開發(fā)人員易將原型取代系統(tǒng)分析； 缺乏規(guī)范化的文檔資料，不利于系統(tǒng)的后期維護。（4）適用范圍該模型適合于： 處理簡單過程明確、涉及面窄的小型系統(tǒng)； 大型系統(tǒng)的需求階段，用原型去跟用戶交流，需求分析會更加明確和細化。該模型 不適合于： 大型、復雜系統(tǒng)，難以模擬； 存在大量運算、邏輯性強的處理系統(tǒng)； 管理基礎工作不完善、處理過程不規(guī)范的系統(tǒng)； 大量批處理的系統(tǒng)。三、軟件生命周期模型的選擇在眾多的開發(fā)模型和過程方法中，企業(yè)應選擇什么樣的開發(fā)模型，應從以下幾方面進行慎重考慮：1、實施推廣的難度但是各雖然各種開發(fā)模型的內容極其豐富， 定義項目各個階段的活動， 并提供了一大堆的文檔模板， 個開發(fā)模型的實施最終還是依靠人。項目管理團隊的管理能力和系統(tǒng)開發(fā)團隊的技術能力決定了所選擇開 發(fā)模型的實施難度。選擇一個適合項目團隊特點的開發(fā)模型尤為重要。2、項目管理的側重點以上各個開發(fā)模型的過程特點也各不相同，如瀑布模型是文檔驅動型的，迭代模型是風險驅動型的， 增量模型是任務驅