軟件工程導論—軟件與軟件工程的基本概念

文章目錄

1. 軟件與軟件危機

1.1. 軟件的概念和特點

軟件一詞是在1960年代出現的，目前還沒有公認的定義。但一般來說，通常意義上的軟件是計算機系統中與硬件相互依存的另一部分，它是包括程序，數據及其相關文檔的完整集合。

其中，程序是按事先設計的功能和性能要求執行的指令序列；數據是使程序能正常操縱信息的數據結構；文檔是與程序開發，維護和使用有關的圖文材料。

與之相似的是，在1983年IEEE組織對軟件下的定義是：計算機程序、方法、規則、相關的文檔資料以及在計算機上運行程序時所必需的數據。

比軟件定義更重要的是，必須充分認識到軟件開發不是某種個體勞動的神祕技巧，而應該是一種組織良好、管理嚴密、各類人員協同配合、共同完成的工程項目。

軟件的特點：

軟件是一種邏輯實體，而不是具體的物理實體，因而它具有抽象性；
軟件的生產與硬件不同，它沒有明顯的製造過程；
在軟件的運行和使用期間，沒有硬件那樣的機械磨損，老化問題。但就目前的軟件工程環境應用而言，在不更新升級的情況下軟件的平均壽命大約爲5年；
軟件的開發和運行常常受到計算機系統的限制，對計算機系統有着不同程度的依賴性；
軟件的開發至今尚未完全擺脫手工藝的開發方式；
軟件本身是複雜的，軟件成本相當昂貴
相當多的軟件工作涉及到社會因素。

1.2. 軟件規模的分類與發展階段

軟件的分類並沒有一個絕對的標準，但一般情況下都會用軟件規模來對軟件進行分類，如下表：

類別	參加人員數	研製期限	產品規模(源程序行數)
微型	1	1~4周	0.5K
小型	1	1~6月	1K~2K
中型	2~5	1~ 2年	5K~50K
大型	5~20	2~3年	50K~ 100K
甚大型	100~1000	4~5年	1M
極大型	2000~5000	5~10年	1M~10M

軟件發展的三個時期及其特點

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

1.3. 軟件危機

1968年在西德Garmish召開的國際軟件工程會議上正式提出軟件危機的概念：計算機軟件的開發和維護過程所遇到的一系列嚴重問題。

1.3.1. 軟件危機的表現

軟件危機一般表現在以下五個大方面：

對軟件開發成本和進度的估算很不準確。 實際成本比估計成本有可能高出一個數量級，實際進度比預期進度拖延幾個月甚至幾年的現象並不罕見。軟件開發人員常常在對用戶要求只有模糊的瞭解，甚至對所要解決的問題還沒有確切認識的情況下，就匆忙着手編寫程序；另外軟件成本在計算機系統總成本中所佔的比例逐年上升。由於微電子學技術的進步和生產自動化程度不斷提高，硬件成本逐年下降，然而軟件開發需要大量人力，軟件成本隨着通貨膨脹以及軟件規模和數量的不斷擴大而持續土升。美國在1985年軟件成本大約已佔計算機系統總成本的90%。
難以準確獲取用戶需求，用戶不滿意； 通常情況下用戶也不知道自己想要什麼，導致開發時常常出現產品與預期不匹配的現象，實際上當前的軟件技術已經十分發達，搞明白了需求基本上都能通過技術實現，如下圖是軟件技術與需求之前的增長關係：
質量很不可靠，沒有適當的文檔。 軟件可靠性和質量保證的確切的定量概念剛剛出現不久，軟件質量保證技術(審查、複審和測試)還沒有堅持不懈地應用到軟件開發的全過程中，這些都導致軟件產品發生質量問題;計算機軟件不僅僅是程序，還應該有三整套文檔資料。這些文檔資料應該是在軟件開發過程中產生出來的，而且應該是"最新式的"(即和程序代碼完全一致的)。軟件開發組織的管理人員可以使用這些文檔資料作爲“里程碑”，來管理和評價軟件開發工程的進展狀況:軟件開發人員可以利用它們作爲通信工具，在軟件開發過程中準確地交流信息;對於軟件維護人員而言，這些文檔:資料更是必不可少的。
缺乏方法指導和工具支持，導致大型軟件系統經常失敗。 很多程序中的錯誤是非常難改正的，實際上不可能使這些程序適應新的硬件環境，也不能根據用戶的需要在原有程序中增加一些新的功能。"可重用的軟件"還是一個沒有完全做到的、正在努力追求的目標，人們仍然在重複開發類似的或基本類似的軟件
供不應求，軟件開發生產率跟不上計算機應用的迅速發展。 軟件開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢。軟件產品"供不應求"的現象使人類不能充分利用現代計算機硬件提供的巨大潛力。

1.3.2. 軟件危機產生的原因

客觀原因：軟件本身特點，例如邏輯部件複雜、規模龐大等等。

在軟件開發和維護的過程中存在這麼多嚴重問題，一方面與軟件本身的特點有關，另一方面也和軟件開發與維護的方法不正確有關。軟件不同於硬件，它是計算機系統中的邏輯部件而不是物理部件，在運行過程中不會因爲使用時間過長而被"用壞"，如果運行中發現了錯誤很可能是遇到了一個在開發時期引入的，在測試階段沒能檢測出來的錯誤。

軟件不同於一般程序，它的一個顯著特點是規模龐大，而且程序複雜性將隨着程序規模的增加而呈指數上升。

主觀原因：程序員不正確的開發方法，忽視需求分析，並且錯誤地認爲軟件開發等於程序編寫，輕視軟件維護。

主觀上的錯誤認識和作法主要表現爲忽視軟件需求分析的重要性，認爲軟件開發就是寫程序並設法使之運行，輕視軟件維護等。目前相當多的軟件專業人員對軟件開發和維護還有不少其他的糊塗觀念，在實踐過程中或多或少地採用了錯誤的方法和技術，這可能是使軟件問題發展成軟件危機的主要原因。

對用戶要求沒有完整準確的認識就匆忙着手編寫程序是許多軟件開發工程失敗的主要原因之一。另一方面還必須認識到程序只是完整的軟件產品的一個組成部分，一個軟件產品必須由一個完整的配置組成，主要包括程序、文檔和數據等成分，他們缺一不可。

軟件問題要儘早解決
作好軟件定義時期的工作，是降低軟件，成本提高軟件質量的關鍵。在實際的軟件開發中，在軟件開發的不同階段進行修改需要付出的代價是很不相同的，大約如下圖所示，它表示了錯誤發現的越晚，付出的代價越高。

因此可以說，輕視維護是一個巨大的錯誤。統計數據表明，實際上用於軟件維護的費用佔軟件總費用的55%~70%。軟件工程學的一個重要目標就是提高軟件的可維護性，減少軟件維護的代價。

1.3.3. 軟件危機如何解決

實際上就目前的手段而言，軟件工程只能解決主觀上造成軟件危機的原因，對於軟件本身特點，例如邏輯部件複雜、規模龐大等客觀原因，軟件工程是無能爲力的。

主觀危機的解決途徑主要有兩條：1、組織管理。2、技術措施

在組織管理可以採用工程項目管理方法；

在技術措施上提升軟件開發技術與方法，靈活運用軟件工具。應該推廣使用在實踐中總結出來的開發軟件的成功的技術和方法，並且研究探索更好更有效的技術和方法，儘快消除在計算機系統早期發展階段形成的一些錯誤概念和做法。並且應該開發和使用更好的軟件工具，在軟件開發的每個階段都有許多繁瑣重複的工作需要做，在適當的軟件工具輔助下，開發人員可以把這類工作做得既快又好。

爲了消除軟件危機，首先應該對計算機軟件有一個正確的認識，首當其衝的就是徹底消除"軟件就是程序"的錯誤觀念，要明確一個軟件必須由一個完整的配置組成，是程序、數據及相關文檔的完整集合。

2. 軟件工程學

2.1. 軟件工程學的概念

軟件工程學是在1968年，北約計算機科學會議上由Fritz Bauer提出的，他給出的軟件工程學的定義爲：用工程、科學和數學的原則與方法研製、維護計算機軟件的有關技術及管理方法。其中包含了三個要素：方法、工具、過程。

因此可以說，軟件工程學是一門指導計算機軟件開發和維護的工程學科，它包含了開發技術和工程管理兩方面。
軟件開發技術

軟件開發方法學
軟件工具
軟件工程環境

軟件工程管理

軟件管理學
軟件經濟學
軟件度量學

2.2. 軟件工程項目的基本目標

組織實施軟件工程項目，從技術上和管理上採取了多項措施以後，最終希望得到項目的成功。所謂成功指的是達到以下幾個主要的目標：

付出較低的開發成本；
達到要求的軟件功能；
取得較好的軟件性能；
開發的軟件易於移植；
需要較低的維護費用；
能按時完成開發工作，及時交付使用。

但是軟件工程的各個目標是不可能全部滿足的，下圖表示了軟件工程目標之間的關係，可見，軟件工程的最終目標只能是實現一個均衡的系統。

2.3. 軟件工程的八項原則

抽象
抽取事物最基本的特性和行爲，忽略非基本的細節。採用分層次抽象，自頂向下、逐層分解的辦法控制軟件開發過程的複雜性。例如，軟件瀑布模型、結構化分析方法、結構化設計方法，以及面向對象建模技術等都體現了抽象的原則。
封裝(信息隱蔽)
將模塊設計成“黑箱”，實現的細節隱藏在模塊內部，不讓模塊的使用者直接訪問。這就是信息封裝，使用與實現分離的原則。使用者只能通過模塊接口訪問模塊中封裝的數據。
模塊化
模塊是程序中邏輯上相對獨立的成分，是獨立的編程單位，應有良好的接口定義。如C語言程序中的函數過程，C++語言程序中的類。模塊化有助於信息隱蔽和抽象，有助於表示複雜的系統。
局部化
要求在一個物理模塊內集中邏輯上相互關聯的計算機資源，保證模塊之間具有鬆散的耦合，模塊內部具有較強的內聚。這有助於加強模塊的獨立性，控制解的複雜性。
確定性
軟件開發過程中所有概念的表達應是確定的、無歧義性的、規範的。這有助於人們之間在交流時不會產生誤解、
遺漏，保證整個開發工作協調致。
一致性
整個軟件系統(包括程序、文檔和數據)的各個模塊應使用一致的概念、符號和術語。程序內部接口應保持一致。軟件和硬件、操作系統的接口應保持一致。系統規格說明與系統行爲應保持一致。用於形式化規格說明的公理系統應保持一致。
完備性
軟件系統不丟失任何重要成分，可以完全實現系統所要求功能的程度。爲了保證系統的完備性，在軟件開發和運行過程中需要嚴格的技術評審。
可驗證性
開發大型的軟件系統需要對系統自頂向下逐層分解。系統分解應遵循系統易於檢查、測試、評審的原則，以確保系統的正確性。

2.4. 軟件工程的本質特徵

軟件工程關注於大型程序的構造
"大"與"小"的分界線並不十分清晰。通常把一個人在較短時間內寫出的程序稱爲小型程序，而把多人合作用時半年以上才寫出的程序稱爲大型程序。

軟件工程的中心課題是控制複雜性
軟件所解決的問題十分複雜，通常不得不把問題分解，使得分解出的每個部分是可理解的，而且各部分之間保持簡單的通信關係。用這種方法並不能降低問題的整體複雜性，但是卻可使它變成可以管理的。

軟件經常變化
絕大多數軟件都模擬了現實世界的某一部分。現實世界在不斷變化，軟件爲了不被很快淘汰，必須隨着所模擬的現實世界一起變化。因此，在軟件系統交付使用後仍然需要耗費成本，而且在開發過程中必須考慮軟件將來可能的變化。

開發軟件的效率非常重要
目前，社會對新應用系統的需求超過了人力資源所能提供的限度，軟件供不應求的現象日益嚴重。因此，軟件工程的一個重要課題就是，尋求開發與維護軟件的更好更有效的方法和工具。

和諧地合作是開發軟件的關鍵
軟件處理的問題十分龐大，必須多人協同工作才能解決這類問題。爲了有效地合作，必須明確地規定每個人的責任和相互通信的方法。紀律是成功地完成軟件開發項目的一個關鍵。

軟件必須有效地支持它的用戶
開發軟件的目的是支持用戶的工作。軟件提供的功能應該能有效地協助用戶完成他們的工作。

有效地支持用戶意味着必須仔細地研究用戶，以確定適當的功能需求、可用性要求及其他質量要求(例如，可靠
性、響應時間等)。有效地支持用戶還意味着，軟件開發不僅應該提交軟件產品，而且應該寫出用戶手冊和培訓材料。

在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人
軟件工程師是諸如Java程序設計、軟件體系結構、測試或統一建模語言(UML)等方面的專家，他們通常並不是圖書館管理、航空控制或銀行事務等領域的專家，但是他們卻不得不爲這些領域開發應用系統。缺乏應用領域的相關知識，是軟件開發項目出現問題的常見原因。

有時候，軟件開發者通過訪談、閱讀書面文件等方法瞭解到用戶組織的“正式”工作流程，然後用軟件實現這個工作流程。但是，決定軟件系統成功與否的關鍵問題是，用戶組織是否真正遵守這個工作流程

2.5. 軟件工程的七條基本原理

著名的軟件工程專家B.W.Boehm綜合學者們的意見，於1983年在一篇論文中提出了軟件工程的七條基本原理。這七條原理是確保軟件產品質量和開發效率的原理的最小集合。

這七條原理是互相獨立的，其中任意6條原理的組合都不能代替另一條原理。同時這七條原理又是相當完備的，雖然不能用數學方法嚴格證明它們是一個完備的集合，但是可以證明在此之前已經提出的一百多條軟件工程原理都可以由這七條原理的任意組合蘊含或派生。

七條基本原理：

用分階段的生命週期計劃嚴格管理
經統計發現，在不成功的軟件項目中有一半左右是由於計劃不周造成的。因此應該把軟件生命週期劃分成若千個階段，並相應地制定出切實可行的計劃，然後嚴格按照計劃對軟件的開發與維護工作進行管理。不同層次的管理人員都必須嚴格按照計劃各盡其職地管理軟件開發與維護工作，絕不能受客戶或上級人員的影響而擅自背離預定計劃；一般來說軟件的生命週期分爲定義階段、可行性研究階段、需求分析階段、程序設計階段、編碼階段、測試階段、運行維護階段。
堅持進行階段評審
軟件的質量保證工作不能等到編碼階段結束之後再進行，這樣說至少有兩個理由：
第一，大部分錯誤是在編碼之前造成的，根據統計，設計錯誤佔軟件錯誤的63%，編碼錯誤僅佔37%；
第二，錯誤發現與改正得越晚，所需付出的代價也越高；
因此，在每個階段都進行嚴格的評審，以便儘早發現在軟件開發過程中所犯的錯誤，是一條必須遵循的重要原則。
實行嚴格的產品控制
在軟件開發過程中改變需求是難免的，只能依靠科學的產品控制技術來順應這種要求。也就是說，當改變需求時，爲了保持軟件各個配置成分的一致性，必須實行嚴格的產品控制，其中主要是實行基準配置管理。
所謂基準配置又稱爲基線配置，它們是經過階段評審後的軟件配置成分。基準配置管理也稱爲變動控制，指的是一切有關修改軟件的建議，特別是涉及到對基準配置的修改建議，都必須按照嚴格的規程進行評審，獲得批准以後才能實施修改。絕對不能誰想修改軟件，就隨意進行修改。
採用現代程序設計技術
從提出軟件工程的概念開始，人們一直把主要精力用於研究各種新的程序設計技術，並進一步研究各種先進的軟件開發與維護技術。實踐表明，採用先進的技術不僅可以提高軟件開發和維護的效率，而且可以提高軟件產品的質量。
結果應能清楚地審查
軟件產品不同於一般的物理產品，它是看不見摸不着的邏輯產品。軟件開發人員的工作進展情況可見性差，難以準確度量，從而使得軟件產品的開發過程比一般產品的開發過程更難於評價和管理。爲了提高軟件開發過程的可見性，更好地進行管理，應該根據軟件開發項目的總目標及完成期限來規定開發組織的責任和產品標準，從而使得所得到的結果能夠清楚地審查。
開發小組的人員應該少而精
軟件開發小組的組成人員的素質應該好，而人數則不宜過多。素質高的人員的開發效率比素質低的人員的開發效率可能高几倍至幾十倍，而且素質高的人員所開發的軟件中的錯誤明顯少於素質低的人員所開發的軟件中的錯誤。
此外，隨着開發小組人員數目的增加，因爲交流情況討論問題而造成的通信開銷也急劇增加。當開發小組人員數爲N時，可能的通信路徑有N(N-1)/2條，可見隨着大數N的增大，通信開銷將急劇增加。
承認不斷改進軟件工程實踐的必要性
遵循上述六條基本原理，就能夠按照當代軟件工程基本原理實現軟件的工程化生產，但是，僅有上述6條原理並不能保證軟件開發與維護的過程能趕上時代前進的步伐。因此，Boehm提出應把承認不斷改進軟件工程實踐的必要性作爲軟件工程的第7條基本原理。按照這條原理，不僅要積極主動地採納新的軟件技術，而且要注意不斷總結經驗。

3. 軟件工程方法學

3.1. 軟件工程方法學的概念

軟件工程包括技術和管理兩方面的內容，是技術與管理緊密結合所形成的工程學科。通常把在軟件生命週期全過程中使用的整套技術方法的集合稱爲方法學(Methodology)，也稱爲範型(Paradigm)。

軟件工程方法學包含3個要素:

方法，是完成軟件開發的各項任務的技術方法，回答"怎樣做"的問題；
工具，是爲運用方法而提供的自動的或半自動的軟件工程支撐環境；
過程，是爲了獲得高質量的軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。

3.2. 傳統軟件工程與面向對象軟件工程

3.2.1. 傳統軟件工程與面向對象軟件工程的對比

目前使用得最廣泛的軟件工程方法學有傳統方法學（面向數據流/結構化方法學） 和 面向對象方法學。他們分別代表了兩種程序設計方法：即結構化程序設計(程序=數據結構+算法) 和 面向對象程序設計(程序=對象+請求消息)

兩種方法學的軟件開發流程如下所示：
傳統軟件工程：軟件分析→總體設計→詳細設計→面向過程的編碼→測試。會有一個清楚的流程體系。
面向對象軟件工程：軟件分析與對象抽取→對象詳細設計→面向對象的編碼→測試。

3.2.2. 傳統軟件工程的生命週期的三個階段

計劃時期。問題定義、可行性分析
問題定義階段必須回答的關鍵問題是"要解決的問題是什麼?"如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的。儘管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。通過對客戶的訪問調查，系統分析員扼要地寫出關於問題性質、工程目標和工程規模的書面報告，經過討論和必要的修改之後這份報告應該得到客戶的確認。
可行性研究階段要回答的關鍵問題是"對於上一個階段所確定的問題有行得通的解決辦法嗎?"系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計過程，也就是在較抽象的高層次上進行的分析和設計過程。可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的範圍，探索這個問題是否值得去解，是否有可行的解決辦法。可行性研究的結果是使用部門負責人作出是否繼續進行這項工程的決定的重要依據。可行性研究以後的那些階段將需要投入更多的人力物力。及時終止不值得投資的工程項目，可以避免更大的浪費。
開發時期。需求分析、軟件設計(總體設計、詳細設計)、編碼、測試(調試和綜合測試)
需求分析階段的任務仍然不是具體解決問題，而是確定"爲了解決這個問題，目標系統必須做什麼?"，主要是確定目標系統必須具備哪些功能。系統分析員必須和用戶密切配合，充分交流信息以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的算法表示在需求分析階段確定的系統邏輯模型是以後設計和實現系統的基礎。這個階段的一項重要任務，是用正式文檔準確地記錄對目標系統的需求，這份文檔通常稱爲規格說明書(specification)。
總體設計階段必須回答的關鍵問題是"概括地說，應該怎樣實現目標系統?"總體設計又稱爲概要設計。首先，應該設計出實現目標系統的幾種可能的方案。通常至少應該設計出低成本、中等成本和高成本等3種方案。軟件工程師在充分權衡各種方案的利弊的基礎上，推薦一個最佳方案。制定出實現最佳方案的詳細計劃。一個程序應該由若干個規模適中的模塊按合理的層次結構組織而成。總體設計的另一項主要任務就是設計程序的體系結構，也就是確定程序由哪些模塊組成以及模塊間的關係。
詳細設計階段的任務就是把解法具體化，也就是回答這個關鍵問題"應該怎樣具體地實現這個系統呢?"這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼詳細設計也稱爲模塊設計，在這個階段將詳細地設計每個模塊，確定實現模塊功能所需要的算法和數據結構。
編碼和調試階段的關鍵任務是寫出正確的、容易理解、容易維護的程序模塊。程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言(必要時用彙編語言)，把詳細設計的結果翻譯成用選定的語言書寫的程序，並且仔細測試(調試)編寫出的每一個模塊。
綜合測試階段的關鍵任務是通過各種類型的測試(及相立的調試)使軟件達到預定的要求。最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟件結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試；所謂驗收測試則是按照規格說明書的規定，由用戶對目標系統進行驗收。必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。
運行時期。軟件維護
軟件維護階段的關鍵任務是"通過各種必要的維護活動使系統持久地滿足用戶的需要"。通常有四類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟件錯誤；適應性維護，即修改軟件以適應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟件使它更完善；預防性維護，即修改軟件爲將來的維護活動預先做準備。每一項維護活動都實質上是經歷了一次壓縮和簡化了的軟件定義和開發的全過程。

4. 軟件開發模型

軟件開發模型實際上是軟件工程三要素中"過程"要素的展開，下面介紹幾種經典的軟件開發模型

4.1. 傳統開發模型

4.1.1. 瀑布模型(waterfall model)

瀑布模型一直是唯一被廣泛採用的生命週期模型，現在它仍然是軟件工程中應用得最廣泛的文檔驅動的過程模型。如下圖所示爲傳統的瀑布模型

瀑布模型區別與其他模型最大的特點有三個：

階段間具有順序性和依賴性
(1)必須等前一階段的工作完成之後，才能開始後一階段的工作；
(2)前一階段的輸出文檔就是後一階段的輸入文檔。因此，只有前一階段的輸出文檔正確，後一階段的工作才能獲得正確的結果。
推遲實現
對於規模較大的軟件項目來說，往往實現(編碼和測試)開始得越早最終完成開發工作所需要的時間反而越長。這是因爲，前面階段的工作沒做或做得不紮實，過早地考慮進行程序實現，往往帶來災難性後果瀑布模型在編碼之前設置了系統分析與系統設計的各個階段，清楚地區分邏輯設計與物!理設計，儘可能推遲程序的物理實現，是按照瀑布模型開發軟件的一條重要的指導思想
質量保證
軟件工程的基本目標是優質、高產。爲了保證所開發的軟件的質量，在瀑布模型的每個階段都應堅持兩個重要做法:
(1)每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務；
(2)每個階段結束前都要對所完成的文檔進行評審，以便儘早發現問題，改正錯誤。

傳統的瀑布模型過於理想化了，事實.上，人在工作過程中不可能不犯錯誤。實際的瀑布模型是帶"反饋環"的，如下圖所示。

實際的瀑布模型當在後面階段發現前面階段的錯誤時，需要沿圖中左側的反饋線返回前面的階段，修正前面階段的產品之後再回來繼續完成後面階段的任務。

4.1.2. 快速原型模型(rapid prototype model)

快速原型模型是低成本的，進行循環需求分析的一個快速開發模型。它的基本結構如圖所示。

原型是值快速建立起來的可以在計算機上運行的程序，它所能完成的功能往往是最終產品能完成的功能的一個子集，然後在用戶的不斷使用中探明用戶需求，不斷對原型進行改進，最終完成需求分析。

因此它的兩個最大的優點就是：

原型系統已經通過與用戶交互而得到驗證，據此產生的規格說明文檔正確地描述了用戶需求，因此，在開發過程的後續階段不會因爲發現了規格說明文檔的錯誤而進行較大的返工。
開發人員通過建立原型系統已經學到了許多東西，因此，在設計和編碼階段發生錯誤的可能性也比較小，這自然減少了在後續階段需要改正前面階段所犯錯誤的可能性。

4.2. 演化開發模型

4.2.1. 增量模型(incremental model)

增量模型也稱爲漸增模型。使用增量模型開發軟件時，把軟件產品作爲一系列的增量構件來設計、編碼、集成和
測試。每個構件由多個相互作用的模塊構成，並且能夠完成特定的功能。開發流程如下圖所示

下圖是每一個增量構建的實現過程圖：

增量模型能在較短時間內向用戶提交可完成部分工作的產品。逐步增加產品功能可以使用戶有較充裕的時間學
習和適應新產品，從而減少一個全新的軟件可能給客戶組織帶來的衝擊。

但是它也是有缺陷的，增量模型面臨的最大困難就是必須保證在把每個新的增量構件集成到現有軟件體系結構中時，必須不破壞原來已經開發出的產品。必須把軟件的體系結構設計得便於按這種方式進行擴充，向現有產品中加入新構件的過程必須簡單、方便，也就是說，軟件體系結構必須是開放的。

4.2.2. 螺旋模型(spiral model)

螺旋模型的基本思想是，使用原型及其他方法來儘量隆低風險。理解這種模型的一個簡便方法，是把它看作在每個階段之前都增加了風險分析過程的快速原型模型。從本質上來講，螺旋模型就是一個加入了風險分析的快速原型模型。

螺旋模型的主要優勢在於，它是風險驅動的。它的開發過程如圖所示：

一個螺旋式週期包括下面4個完整步驟：

確定目標，選擇方案，選定完成目標的策略
從風險角度分析該策略
啓動一個開發階段
評價前一步的結果，並計劃下一輪的工作

4.3. 面向對象開發模型

4.3.1. 構件集成模型(component integration model)

構建集成模型是一個典型的面向對象開發模型，它的一個典例就是各種開發IDE，例如Visual Studio，可以查找加載各種構建。

構建集成模型有着以下五個特點：面向對象、基於構件庫、融合螺旋模型特徵、支持軟件開發的迭代方法、軟件重用