第1章軟件工程概述11.1

軟件的概念、特點和分類2軟件的概念程序、軟件與軟件產品獨唱

小合唱-->合唱-->萬人大合唱

|||

簡單程序較復雜程序軟件軟件是計算機系統中與硬件相互依存的另一部分,它包括程序、數據、相關文檔的完整集合以及完善的售后服務。軟件=程序+數據+文檔+服務3軟件的特點1.軟件是一種邏輯實體，而不是具體的物理實體。2.軟件的生產于硬件不同。3.在軟件的運行和使用期間，沒有硬件那樣的機械磨損，老化問題。失效率時間磨合調整磨損用壞硬件失效曲線失效率時間軟件失效曲線理想曲線實際曲線4軟件的特點4.軟件的開發和運行常常受到計算機系統的限制，對計算機系統有著不同程度的依賴。5.軟件的開發至今尚未完全擺脫手工業的開發方法。6.軟件是復雜的，人類能夠創造的最復雜的產物是計算機軟件。7.軟件成本相當昂貴。8.相當多的軟件工作涉及到社會因素。5軟件的分類1.按軟件的功能劃分⑴系統軟件操作系統數據庫管理系統設備驅動程序通信處理程序等6軟件的分類⑵支撐軟件文本編輯程序文件格式化程序磁盤向磁帶向數據傳輸的程序程序庫系統支持需求分析、設計、實現、測試和支持管理的軟件7軟件的分類⑶應用軟件商業數據處理軟件工程與科學計算軟件計算機輔助設計／制造軟件系統仿真軟件智能產品嵌入軟件醫療、制藥軟件事務管理、辦公自動化軟件計算機輔助教學軟件8軟件的分類2.按軟件規模劃分類別參加人員數研制期限源程序行數

微型 1 1～4周0.5k小型1 1～6月1k～2k中型2～5 1～2年5k～50k大型5～20 2～3年50k～100k甚大型100～10004～5年1M(=1000k)極大型2000～50005～10年1M～10M9軟件的分類3.按軟件工作方式劃分

⑴實時處理軟件

⑵交互式軟件

⑶分時軟件

⑷批處理軟件4.按軟件服務對象的范圍劃分

⑴項目軟件

⑵產品軟件10軟件的分類5.按軟件使用的頻度劃分

⑴僅供一次使用的軟件

⑵頻繁使用的軟件6.按軟件的失效⑴高可靠性軟件。⑵一般可靠性軟件。111.2

軟件的發展和軟件危機

12軟件的發展軟件的發展大體經歷了如下三個階段：

①程序設計階段，約為50至60年代

特點：依賴于個人編程’技巧’，開發不規范，開發成本難控制，其交付的產品主要是程序。②程序系統階段，約為60至70年代特點：軟件開發是以小組的形式出現，提交的軟件產品除了程序外還有相應的使用說明書。③軟件工程階段，約為70年代以后特點：開發方法遵循工程化的方法，按照軟件生命周期分階段開發軟件，提交的軟件產品除了程序之外，還有嚴格的文檔。13計算機軟件發展的三個時期及特點

時間特點程序設計程序系統軟件工程軟件所指程序程序及說明書程序、文檔、數據、服務主要程序設計語言匯編及機器語言高級語言軟件語言軟件工作范圍程序編寫包括設計和測試軟件生存期需求者程序設計本人少數用戶市場用戶開發軟件的組織個人開發小組開發小組及大中型開發機構軟件規模小型中小型大中小型決定質量的因素個人程序技術小組技術水平管理水平開發子程序程序庫結構化程序設計數據庫、開發工具、開發環境、工程化開發方法、標準和規范、網絡和分布式開發、面向對象技術維護責任者程序設計者開發小組專職維護人員硬件特征價格高存儲容量小工作可靠性差降價、速度、容量及工作可靠性有明顯提高向超高速、大容量、微型化及網絡化方向發展軟件特征完全不受重視軟件技術的發展不能滿足需要，出現軟件危機開發技術有進步，但未獲突破性進展，價高，未完全擺脫軟件危機14軟件工程的發展的四個重要階段1、第一代軟件工程

—

傳統的軟件工程2、第二代軟件工程

—對象工程3、第三代軟件工程

—過程工程4、第四代軟件工程

—構件工程

60年代末到70年代為了克服“軟件危機”(Softwarecrisis)提出“軟件工程”的名詞,將軟件開發納入工程化的軌道，基本形成軟件工程的概念、框架、技術和方法。稱為傳統的軟件工程。15軟件工程的發展的四個重要階段1、第一代軟件工程

—

傳統的軟件工程2、第二代軟件工程

—對象工程3、第三代軟件工程

—過程工程4、第四代軟件工程

—構件工程

80年代中到90年代，面向對象的方法與技術得到發展，研究的重點轉移到面向對象的分析與設計，演化為一種完整的軟件開發方法和系統的技術體系，稱為對象工程。16軟件工程的發展的四個重要階段1、第一代軟件工程

—

傳統的軟件工程2、第二代軟件工程

—對象工程3、第三代軟件工程

—過程工程4、第四代軟件工程

—構件工程

80年代中開始，人們在軟件開發的實踐過程中認識到：提高軟件生產率，保證軟件質量的關鍵是“軟件過程”，是軟件開發和維護中的管理和支持能力，逐步形成軟件過程工程。17軟件工程的發展的四個重要階段1、第一代軟件工程

—

傳統的軟件工程2、第二代軟件工程

—對象工程3、第三代軟件工程

—過程工程4、第四代軟件工程

—構件工程

90起年代，基于構件（Component）的開發方法取得重要進展，軟件系統的開發可通過使用現成的可復用構件組裝完成，而無需從頭開始構造，以此達到提高效率和質量，降低成本的目的。稱為構件工程。18軟件開發方法的模型隨意編程面向過程面向對象面向組件面向配置組件面向WebService19什么是軟件危機定義：軟件危機是計算機軟件在它的開發和維護過程中所遇到的一系列嚴重問題。主要包含兩方面的問題：

⑴如何開發軟件，怎樣滿足對軟件日益增長的需求；

⑵如何維護數量不斷膨脹的已有軟件。20軟件危機的現象⑴對軟件開發成本和進度的估計常常很不準確。⑵用戶對“已完成的”軟件系統不滿意的現象經常發生。⑶軟件產品的質量往往靠不住。⑷軟件常常是不可維護的。⑸軟件通常沒有適當的文檔資料。計算機軟件不僅僅是程序，還應該有一整套文檔資料。⑹軟件成本在計算機系統總成本中所占的比例逐年上升。⑺軟件開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢。21軟件危機的原因⑴客觀：軟件本身特點軟件的規模龐大、復雜性高。⑵主觀：不正確的開發方法，軟件開發和維護有許多錯誤的認識和作法。忽視需求分析軟件開發=程序編寫輕視軟件維護22軟件的神話——管理者的神話負責軟件的管理者像大多數其他管理者一樣，都有巨大的壓力，要維持預算，保持進度和提高質量。神話：我們已經有了關于建造軟件的標準和規程的書籍，難道它們不能給人們提供所有其需要知道的信息嗎？事實：不錯，關于標準的書籍已經存在，但真正用到了它們嗎？軟件實踐者知道它們存在嗎？它們是否反映了現代軟件開發的過程？它們完整嗎？很多情況下對于這些問題的答案是“否”。23軟件的神話——管理者的神話神話：我們已經有了很多很好的軟件開發工具，而且，我們為它們買了最新的計算機。事實：為了使用最新型號的計算機、工作站和PC機去開發高質量的軟件，我們已經投入了太多的費用。實際上，計算機輔助軟件工程（CASE）工具比起硬件而言，對于獲得高質量和高生產率更為重要，但大多數軟件開發者并未使用它們。24軟件的神話——管理者的神話神話：如果我們已落后于計劃，可以增加更多的程序員來趕上進度。事實：軟件開發并非像制造一樣是一個機械過程。用Brooks的話來說，“給一個已經延遲的軟件項目增加人手只會使其更加延遲”。看起來，這句話與人的直覺正好相反。但實際上，增加新人，原來正在工作的開發者必須花時間來培訓新人，這樣就減少了他們花在項目開發上的時間。人手可以增加，但只能在計劃周密、協調良好的情況下。25軟件的神話——用戶的神話需要計算機軟件的用戶可能就是鄰桌，或是另一個技術組，也可能是市場／銷售部門，或另一個公司。在許多情況下，用戶相信關于軟件的神話，因為負責軟件的管理者和開發者很少去糾正用戶的錯誤理解。神話導致了用戶過高的期望值，并引起對開發者的極端不滿。神話：有了對目標的一般描述就足以開始寫程序了——我們可以以后補充細節。事實：不完善的系統定義是軟件項目失敗的主要原因。關于待開發項目的應用領域、功能、性能、接口、設計約束及確認標準的形式化的、詳細的描述是必需要的。這些內容只有通過用戶和開發者之間的通信交流才能確定。26軟件的神話——用戶的神話神話：項目需求總是在不斷變化，但這些變化能夠很容易地滿足，因為軟件是靈活的。事實：軟件需求確實是經常變化的，但這些變化產生的影響會隨著其引入的時間不同而不同。如果我們很注重早期的系統定義，這時需求變化就可很容易地適應。用戶能夠復審需求，并提出對修改建議，這時對成本的影響會相對較小。當在軟件設計過程中才要求修改時，對成本的影響就會提高的很快。資源已經消耗了，設計框架已經建立了，這時的變化可能會引起大的改動，需要額外的資源和大量的設計修改：如額外的花費。實現階段（編碼和測試階段）功能、性能、接口及其它方面的改變對成本會產生更大的影響。當軟件已投入使用后再要求修改，這時所花費的代價比起較早階段做同樣修改所花的代價可能是幾何級數級的增長。27例子某公園有一游船碼頭，負責人請一位軟件開發人員實現計算機系統輔助游船管理系統，要求如下：當游客向租船處租船時，向租船處查詢是否有可租用的船只，如果租船處有空船，管理員就準備好船只，幫助游客上船，并在聯機終端上打入一個信息“S”，表示租船周期開始。計算機自動把當時時鐘值送入信息域。當游客還船時，管理員打入另一個信息“E”，表示租船周期結束。由管理員向游客結算租船時間及費用。一天結束時，管理員要用一些管理信息總結每天工作狀況，要求系統打印出租船次數=NNN

平均租船時間=MMM

顯然，這樣一個系統的功能包括二個部分：

⑴計算輸入流的信息

⑵打印輸出28確定算法我們知道平均租船時間就是總的時間除以租船次數總的時間=第一條船結束時間-第一條船開始時間+第二條船結束時間-第二條船開始時間+…

或總的時間=（第一條船結束時間+第二條船結束時間+…）-（第一條船開始時間+第二條船開始時間+…）29編寫系統程序BEGINOPENMESSAGE_STREAMNUMBER=0TOTALTIME=0GETMESSAGEDOWHILENOTEND_OF_STREAMIFCODE=STHENNUMBER=NUMBER+1TOTAL_TIME=TOTAL_TIME-START_TIMEELSETOTAL_TIME=TOTAL_TIME+END_TIMEENDIFPRINT“NUMBEROFSESSION=”NUMBERIFNUMBER<>0THENPRINT“AVERAGESESSIONTIME=”TOTAL_TIME/NUMBERENDIFCLOSEMASSAGE_STREAMEND;30系統提出修改①找出一天中最長租用時間：

LONGGEST_SESSION_TIME=PPP②要求把每天的報告分成兩個，一個是上午情況，另一個是下午情況。③通信線路出了毛病，丟掉了一些信息。要求修改系統——從計算報告中刪除一切不完整的租船信息。對于上述的修改，除了把原系統廢棄之外。實在無法對其作什么修改來滿足這一新的要求。而時間及經費都不允許他這么做了。結論：并不是任意設計出來的軟件都能夠適應在軟件壽命期內變化的要求，即軟件的靈活性不是絕對的。31軟件的神話——開發者的神話那些至今仍被軟件開發者相信的神話是由幾十年的程序設計文化培植起來的。而這種舊的觀念和方式是很難改變的。神話：一旦我們寫出了程序并使其正常運行，我們的工作就結束了。事實：有人說過：“越早開始寫程序，就要花越長的時間完成它”，大量的數據表明在一個程序上所投入的50%到70%的努力是花在第一次將程序交給用戶之后。32軟件的神話——開發者的神話神話：在程序真正運行之前，沒有辦法評估其質量。事實：從項目一開始就可以應用的最有效的軟件質量保證機制之一是正式的技術復審。軟件復審是“質量的過濾器”，比起通過測試找到某類軟件錯誤要有效的多。神話：一個成功的項目唯一應該提交的就是運行程序。事實：運行程序僅是仍軟件配置的一部分，軟件配置包括：程序、文檔和數據。文檔是成功開發的基礎，更重要的是，文檔為軟件維護提供了指導。33軟件危機解決途徑組織管理工程項目管理方法技術措施軟件開發技術與方法軟件工具341.3

軟件工程35軟件工程的提出“軟件工程”一詞是1968年北大西洋公約組織（NATO）在聯邦德國召開的一次會議上首次提出的，這個會議專門討論了軟件危機問題。它反映了軟件人員認識到軟件危機的出現及謀求解決這一危機的努力，因此，這次會議被看作是軟件發展史上一個重要的里程碑。36軟件工程定義采用工程的概念、原理、技術和方法來計劃、開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以較經濟的手段獲得能在實際機器上運行的可靠軟件的一系列方法。簡言之：工程方法+管理技術+技術方法37軟件工程原理著名的軟件工程專家B.W.Boehm提出了軟件工程的七條基本原理。這七條原理是確保軟件產品質量和開發效率的原理的最小集合。這七條原理是互相獨立的，其中任意六條原理的組合都不能代替另一條原理，因此，它們是缺一不可的最小集合，然而這七條原理又是相當完備的，人們雖然不能用數學方法嚴格證明它們是一個完備的集合，但是，可以證明在此之前已經提出的100多條軟件工程原理都可以由這七條原理的任意組合蘊含或派生。38軟件工程原理⒈用分階段的生命周期計劃嚴格管理不成功的軟件項目中有一半左右是由于計劃不周造成的。⒉堅持進行階段評審軟件的質量保證工作不能等到編碼階段結束之后再進行。⒊實行嚴格的產品控制在軟件開發過程中不應隨意改變需求，因為改變一項需求往往需要付出較高的代價。⒋采用現代程序設計技術采用先進的技術既可提高軟件開發的效率，又可提高軟件維護的效率。39軟件工程原理⒌結果應能清楚地審查根據軟件開發項目的總目標及完成期限，規定開發組織的責任和產品標準，從而使得所得到的結果能夠清楚地審查。⒍開發小組的人員應該少而精開發小組人員的素質和數量是影響軟件產品質量和開發效率的重要因素。小組人員增加，交流情況和討論問題而造成的通訊開銷也急劇增加，人數為N，可能的通訊路徑有N(N-1)。

⒎

承認不斷改進軟件工程實踐的必要性不僅要積極主動地采納新的軟件技術，而且要注意不斷總結經驗。40軟件工程學的范疇軟件工程學軟件工程技術軟件工程管理軟件開發方法學軟件工具軟件工程環境軟件經濟學軟件管理學41軟件工程三要素軟件工程包括三要素：方法、工具和過程。⑴軟件工程方法為軟件開發提供了“如何做”的技術。⑵軟件工具為軟件工程方法提供了自動的或半自動的軟件支撐環境。⑶軟件工程的過程則是將軟件工程的方法和工具綜合起來以達到合理、及時地進行計算機軟件開發的目的。42什么是軟件工程過程定義：軟件工程過程是為獲得軟件產品，在軟件工具的支持下由軟件工程師完成的一系列軟件工程活動。針對不同類型的軟件產品，同一軟件開發機構也可能采用多個不同的軟件工程過程。43軟件工程過程的基本活動⑴軟件規格說明：規定軟件的功能及其運行的限制；⑵軟件開發：產生滿足規格說明的軟件；⑶軟件確認：確認軟件能夠完成客戶提出的要求；⑷軟件改進：為滿足客戶的變更要求，軟件必須在使用的過程中改進。44軟件工程過程的特性⑴易理解性。⑵可見性：每個過程活動均能以明確的結果告終，使過程的進展對外可見。⑶可支持性：易得到計算機輔助軟件工程（CASE）工具的支持。⑷可接受性：易于為軟件工程師接受和使用。⑸可靠性：不會出現過程錯誤，或發現在產品出現故障之前。⑹健壯性：不受意外發生的問題干擾。⑺可維護性：過程可隨軟件機構需求的變更或隨認定的過程改進而演進。⑻速度：從規格說明起，就能較快地完成開發而交付。45軟件工程項目的基本目標⑴付出較低的成本；⑵達到要求的軟件功能；⑶取得較好的軟件性能；⑷開發的軟件易于移植；⑸需要較低的維護費用；⑹能按時完成開發工作，及時交付使用。46軟件工程目標之間的關系47軟件工程框架及原則1．選取適宜的開發模型；2．采用合適設計方法；3．提供高質量工程支持；4．重視開發過程管理。48軟件工程面臨的問題

(1)軟件費用

(2)軟件可靠性

(3)軟件維護

(4)軟件生產率

(5)軟件重用491.4

軟件生命周期50軟件生命周期的定義定義：軟件生命周期是指軟件產品從考慮其概念開始到該軟件產品不再能使用為止的整個時期。軟件生命周期可分為三個階段：即定義階段、開發階段和運行維護階段，每個階段需完成幾個任務。51劃分軟件生命周期的目的和實質⑴便于控制開發工作的復雜性。⑵通過有限的步驟，把用戶的需求從抽象的邏輯概念逐步轉化為具體的物理實現。52軟件生命周期各階段的基本任務－定義階段定義階段主要集中于“做什么”，即在定義過程中，軟件開發人員試圖弄清楚要處理什么信息，預期完成什么樣的功能和性能，希望有什么樣的系統行為，建立什么樣界面，有什么設計約束，以及定義一個成功系統的確認標準是什么。在本階段需完成三項任務：53系統定義系統定義必須回答的關鍵問題是：“要解決的問題是什么？”如果不知道問題是什么就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。系統定義是軟件生命周期中最簡短的任務，一般只需要一天甚至更少的時間。54可行性研究可行性研究要回答的關鍵問題是：“對于上一個階段所確定的問題有行得通的解決辦法嗎？”為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程?？尚行匝芯繎摫容^簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。55需求分析需求分析的任務仍然不是具體地解決問題，而是準確地確定“為了解決這個問題，目標系統必須做什么”，主要是確定目標系統必須具備哪些功能。系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的算法表示系統的邏輯模型。56軟件生命周期各階段的基本任務－開發階段開發階段集中于“如何做”。即在開發過程中，軟件工程師試圖定義數據如何結構化，功能如何轉換為軟件體系結構，過程細節如何實現，界面如何表示，設計如何轉換成程序設計語言，測試如何運行。在本階段需完成四項任務：57總體設計總體設計必須回答的關鍵問題是：“概括地說，應該如何解決這個問題？”通常至少應該考慮下述幾類可能的方案：①低成本的解決方案。系統只能完成最必要的工作，不能多做一點額外的工作。②中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力在實踐中將證明是很有價值的。③高成本的“十全十美”的系統。這樣的系統具有用戶可能希望有的所有功能和特點。58詳細設計總體設計以比較抽象概括的方式提出了解決問題的辦法。詳細設計的任務就是把解法具體化，也就是回答下面這個關鍵問題：“應該怎樣具體地實現這個系統呢？”通常用HIPO圖（層次圖加輸入／處理／輸出圖）、PAD圖或PDL語言（過程設計語言）描述詳細設計的結果。59編碼和單元測試編碼和單元測試的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。60綜合測試綜合測試的關鍵任務是通過各種類型的測試（及相應的調試），使軟件達到預定的要求。最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟件結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標系統進行驗收。必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。為了使用戶能夠積極參加驗收測試，并且在系統投入生產性運行以后能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。61軟件生命周期各階段的基本任務－軟件維護維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。通常有四類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟件錯誤；適應性維護，即修改軟件以適應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟件使它更完善；預防性維護，即修改軟件為將來的維護活動預先做準備。每一項維護活動都應該準確地記錄下來，作為正式的文檔資料加以保存。62軟件生命周期各階段任務一覽表階段關鍵問題結束標準系統定義問題是什么？關于規模和目標的報告書可行性研究有可行的解嗎？系統的高級邏輯模型；數據流圖成本／效益分析需求分析系統必須做什么？系統的邏輯模型；數據流圖；數據字典；算法描述總體設計概括地說，應該如何解決這個問題？可能的解法：系統流程圖；成本／效益分析；推薦的系統結構；層次圖或結構圖詳細設計怎樣具體地實現這個系統？編碼規格說明：HIPO圖或PDL編碼和單元測試正確的程序模塊源程序清單；單元測試方案和結果綜合測試符號要求的軟件綜合測試方案和結果；完整一致的軟件配置維護持久地滿足用戶需求的軟件完整準確的維護記錄631.5

軟件開發模型64軟件開發模型在整個軟件開發的發展過程中，為了要從宏觀上管理軟件的開發和維護，就必須對軟件的發展過程有總體的認識和描述，即要對軟件過程建模。幾十年來，軟件開發生命周期模型的發展有了很大的變化，提出了一系列的模型以適應軟件開發發展的需要。65編碼--修正模型在軟件開發早期，開發只有兩個階段，被簡單的分成編寫程序代碼和修改程序代碼。拿到項目，馬上就根據需要，開始編寫程序。編完代碼，調試通過，就算基本完成任務，拿給用戶用。如果應用中有什么錯誤，或有什么新的要求，要重新修改代碼。66編碼--修正模型的弊端1．代碼缺少統一規劃，低估了設計的重要性，使得代碼結構隨著修改的次數增加變得越來越壞。以至錯誤越來越難改，甚至無法改。2．即使有的軟件計劃很好，但往往其結果并非用戶所需要的。造成軟件開發的風險非常大。這主要是沒有重視需求而造成的。3．由于對測試、維護修改方面考慮不周，使得代碼維護修改非常困難。67瀑布模型由于吸取了開發早期的教訓，人們開始將軟件開發視為工程來管理。類似于其他的工程管理，軟件開發也具有一定的工序?！败浖芷凇边@一概念真正被提了出來，并將軟件生命周期劃分成：制定計劃，需求分析、軟件設計、程序編寫、軟件測試、運行與維護等六個部分。68瀑布模型69瀑布模型的特點⑴從上一項開發活動接受該項活動的工作對象，作為輸入。⑵利用這一輸入，實施該項活動應完成的工作內容。⑶給出該項活動的工作成果，作為輸出傳給下一項活動。⑷對該項目活動實施的工作成果進行評審。若工作得到確認，則繼續進行下一次開發活動，否則返回前一項，甚至更前項的活動。70瀑布模型優點⑴消除非結構化軟件。⑵降低軟件的復雜度。⑶促進軟件開發工程化。71瀑布模型存在的問題⑴階段與階段劃分完全固定，階段間產生的大量文檔，極大地增加了工作量。⑵由于開發模型呈線性，所以當開發成果尚未經過測試時，用戶無法看到軟件的效果。這樣，軟件與用戶見面的時間較長，也增加了一定的風險。⑶前面未發現的錯誤傳到后面的開發活動中，可能會擴散，進而可能會造成更不理想的效果。72平行瀑布模型考慮對瀑布模型的進一步改進。對瀑布模型的各階段之間的轉換時，不一定要求完全按順序進行。而是以適當的并行開展各階段的工作。在上一階段尚未完成結束前，就可以開設后一階段的工作。根據不同的情況可有不同的并行度：⑴用戶想法不穩定，如：每天都變換想法，要求不太清楚的話，則增加并行度。⑵短期顯示成果的壓力大，則可增加并行度。⑶如果可靠性要求高；要求各方面控制和配合很嚴格；資源及預算嚴密；技術錯誤的后果嚴重時，則需減少并行度。73原型模型常有這種情況，用戶定義了軟