軟件工程第1章學習內容

第1章軟件工程學概述1.1軟件危機1.2軟件工程1.3軟件生命周期1.4軟件過程1.5小結習題迄今為止，計算機系統已經經歷了4個不同的發展階段，但是，我們仍然沒有徹底擺脫“軟件危機”的困擾，軟件已經成為限制計算機系統發展的瓶頸。為了更有效地開發與維護軟件，軟件工作者在20世紀60年代后期開始認真研究消除軟件危機的途徑，從而逐漸形成了一門新興的工程學科——計算機軟件工程學(通常簡稱為軟件工程)。

1.1軟件危機

計算機軟件發展至今經歷了三個不同的發展時期：程序設計時期（20世紀50年代——60年代）軟件時期（20世紀60年代中期——70年代）軟件工程時期（20世紀70年代——現在）

軟件的發展程序設計語言(Programming)機器語言匯編語言ALGOL60FORTRANCOBOLBASIC軟件(Software)1960程序文檔數據軟件危機引出軟件工程(SoftwareEngineering)軟件開發工程化1968NATO軟件開發階段與瀑布模型軟件工程標準

焦點目標-----少資源、高效益-----在人力投入、開發期、成本、質量諸方面求得最佳風險----需求：不明與變更----人員流動----軟件知識產權保護----不存在絕對無缺陷的軟件產品如期完成預算內完成達到質量要求（需求和希望）軟件項目成功的標志軟件的特點軟件是一種邏輯實體，具有抽象性這個特點使它與其他工程對象有著明顯的差異人們可以把它記錄在紙上、內存和磁盤、光盤上，但卻無法看到軟件本身的形態，必須通過觀察、分析、思考、判斷，才能了解它的功能、性能等特性軟件沒有明顯的制造過程一旦研制開發成功，就可以大量拷貝同一內容的副本，所以對軟件的質量控制，必須著重在軟件開發方面下工夫軟件的特點軟件在使用過程中，沒有磨損、老化的問題軟件在生存周期后期不會因為磨損而老化，但會為了適應硬件、環境以及需求的變化而進行修改，而這些修改又不可避免地引入錯誤，導致軟件失效率升高，從而使得軟件退化當修改的成本變得難以接受時，軟件就被拋棄軟件對硬件和環境有著不同程度的依賴性這導致了軟件移植的問題軟件的特點軟件的開發至今尚未完全擺脫手工作坊式的開發方式，生產效率低軟件是復雜的，而且以后會更加復雜軟件是人類有史以來生產的復雜度最高的工業產品軟件涉及人類社會的各行各業、方方面面，軟件開發常常涉及其他領域的專門知識，這對軟件工程師提出了很高的要求軟件的特點軟件的成本相當昂貴軟件開發需要投入大量、高強度的腦力勞動，成本非常高，風險也大現在軟件的開銷已大大超過了硬件的開銷軟件工作牽涉到很多社會因素許多軟件的開發和運行涉及機構、體制和管理方式等問題，還會涉及到人們的觀念和心理這些人的因素，常常成為軟件開發的困難所在，直接影響到項目的成敗OS360操作系統被認為是一個典型的案例。到現在為止，它仍然被使用在IBM360系列主機中。共約100萬條指令，花費了5000個人年；經費達數億美圓，而結果卻令人沮喪，錯誤多達2000個以上，系統根本無法正常運行。FredBrooks在隨后他的大作《人月神話》（TheMythicalMan-Month）中曾經承認，在他管理這個項目的時候，他犯了一個價值數百萬美元的錯誤。財產的損失：軟件的錯誤可能導致巨大的財產損失。歐洲阿里亞娜火箭的爆炸就是一個最為慘痛的教訓。造成1000萬美元的損失。原因是FORTRAN程序：

DO5I=1，3

誤寫為：DO5I=1.3人員傷亡：由于計算機軟件被廣泛應用于包括醫院等與生命息息相關的行業。這也使得軟件的錯誤導致人員傷亡成為了可能。在工業上，某些嵌入式系統導致機器的不正常運轉，從而將一些人推入了險境。1967年蘇聯“聯盟一號”載人宇宙飛船在返航時，由于軟件忽略一個小數點，在進入大氣層時因打不開降落傘而燒毀。

在計算機系統發展的早期時代(20世紀60年代中期以前)，通用硬件相當普遍，軟件卻是為每個具體應用而專門編寫的。這時的軟件通常是規模較小的程序，編寫者和使用者往往是同一個(或同一組)人。這種個體化的軟件環境，使得軟件設計通常是在人們頭腦中進行的一個隱含的過程，除了程序清單之外，沒有其他文檔資料保存下來。從20世紀60年代中期到70年代中期是計算機系統發展的第二代時期，這個時期的一個重要特征是出現了“軟件作坊”，廣泛使用產品軟件。

但是，“軟件作坊”基本上仍然沿用早期形成的個體化軟件開發方法。隨著計算機應用的日益普及，軟件數量急劇膨脹。在程序運行時發現的錯誤必須設法改正；用戶有了新的需求時必須相應地修改程序；硬件或操作系統更新時，通常需要修改程序以適應新的環境。上述種種軟件維護工作，以令人吃驚的比例耗費資源。更嚴重的是，許多程序的個體化特性使得它們最終成為不可維護的。“軟件危機”就這樣開始出現了!1968年北大西洋公約組織的計算機科學家在聯邦德國召開國際會議，討論軟件危機問題，在這次會議上正式提出并使用了“軟件工程”這個名詞，一門新興的工程學科就此誕生了。按軟件的功能進行劃分：系統軟件操作系統數據庫管理系統設備驅動程序通信處理程序等軟件的分類支撐軟件文本編輯程序文件格式化程序磁盤向磁帶向數據傳輸的程序程序庫系統支持需求分析、設計、實現、測試和支持管理的軟件應用軟件商業數據處理軟件工程與科學計算軟件計算機輔助設計／制造軟件系統仿真軟件智能產品嵌入軟件醫療、制藥軟件事務管理、辦公自動化軟件計算機輔助教學軟件按軟件規模進行劃分：類別參加人員數 研制期限源程序行數

微型

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～10M 按軟件工作方式劃分：實時處理軟件分時軟件交互式軟件批處理軟件按軟件服務對象的范圍劃分：

項目軟件產品軟件按使用的頻度進行劃分：一次使用頻繁使用按軟件失效的影響進行劃分：高可靠性軟件一般可靠性軟件

軟件危機是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。這些問題絕不僅僅是不能正常運行的軟件才具有的，實際上，幾乎所有軟件都不同程度地存在這些問題。概括地說，軟件危機包含下述兩方面的問題：如何開發軟件，以滿足對軟件日益增長的需求；如何維護數量不斷膨脹的已有軟件。具體地說，軟件危機主要有以下一些典型表現。1.1.1軟件危機的介紹(1)對軟件開發成本和進度的估計常常很不準確。實際成本比估計成本有可能高出一個數量級，實際進度比預期進度拖延幾個月甚至幾年的現象并不罕見。這種現象降低了軟件開發組織的信譽。而為了趕進度和節約成本所采取的一些權宜之計又往往損害了軟件產品的質量，從而不可避免地會引起用戶的不滿。(2)用戶對“已完成的”軟件系統不滿意的現象經常發生。軟件開發人員常常在對用戶要求只有模糊的了解，甚至對所要解決的問題還沒有確切認識的情況下，就匆忙著手編寫程序。軟件開發人員和用戶之間的信息交流往往很不充分，“閉門造車”必然導致最終的產品不符合用戶的實際需要。(3)軟件產品的質量往往靠不住。軟件可靠性和質量保證的確切的定量概念剛剛出現不久，軟件質量保證技術(審查、復審和測試)還沒有堅持不懈地應用到軟件開發的全過程中，這些都導致軟件產品發生質量問題。(4)軟件常常是不可維護的。很多程序中的錯誤是非常難改正的，實際上不可能使這些程序適應新的硬件環境，也不能根據用戶的需要在原有程序中增加一些新的功能。“可重用的軟件”還是一個沒有完全做到的、正在努力追求的目標，人們仍然在重復開發類似的或基本類似的軟件。(5)軟件通常沒有適當的文檔資料。計算機軟件不僅僅是程序，還應該有一整套文檔資料。這些文檔資料應該是在軟件開發過程中產生出來的，而且應該是“最新式的”(即和程序代碼完全一致的)。軟件開發組織的管理人員可以使用這些文檔資料作為“里程碑”，來管理和評價軟件開發工程的進展狀況；軟件開發人員可以利用它們作為通信工具，在軟件開發過程中準確地交流信息；對于軟件維護人員而言，這些文檔資料更是必不可少的。缺乏必要的文檔資料或者文檔資料不合格，必然給軟件開發和維護帶來許多嚴重的困難和問題。(6)軟件成本在計算機系統總成本中所占的比例逐年上升。由于微電子學技術的進步和生產自動化程度不斷提高，硬件成本逐年下降，然而軟件開發需要大量人力，軟件成本隨著通貨膨脹以及軟件規模和數量的不斷擴大而持續上升。美國在1985年軟件成本大約已占計算機系統總成本的90%。(7)軟件開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢。軟件產品“供不應求”的現象使人類不能充分利用現代計算機硬件提供的巨大潛力。

在軟件開發和維護的過程中存在這么多嚴重問題，一方面與軟件本身的特點有關，另一方面也和軟件開發與維護的方法不正確有關。1.1.2產生軟件危機的原因由于軟件本身的特點，管理和控制軟件開發過程相當困難，而且軟件維護較難軟件是一種高智力活動，由復雜的邏輯、復雜的運算和復雜的關聯等構成1.1.2產生軟件危機的原因由于對軟件開發與軟件維護的不正確方法，產生了軟件危機----軟件規模越來越大，功能越來越強，導致軟件結構非常復雜----忽視軟件開發前期的需求分析----開發過程沒有統一的、規范的方法論的指導，文檔資料不齊全，忽視人與人的交流----忽視測試階段的工作，提交用戶的軟件質量差----輕視軟件的維護；等等1.1.2產生軟件危機的原因對軟件看法的改變早期那些被認為是優秀的程序常常很難被別人看懂，通篇充滿了程序技巧現在人們普遍認為優秀的程序除了功能正確，性能優良之外，還應該容易看懂、容易使用、容易修改和擴充

軟件不同于硬件，它是計算機系統中的邏輯部件而不是物理部件。由于軟件缺乏“可見性”，在寫出程序代碼并在計算機上試運行之前，軟件開發過程的進展情況較難衡量，軟件的質量也較難評價，因此，管理和控制軟件開發過程相當困難。此外，軟件在運行過程中不會因為使用時間過長而被“用壞”，如果運行中發現了錯誤，很可能是遇到了一個在開發時期引入的在測試階段沒能檢測出來的錯誤。因此，軟件維護通常意味著改正或修改原來的設計，這就在客觀上使得軟件較難維護。

軟件不同于一般程序，它的一個顯著特點是規模龐大，而且程序復雜性將隨著程序規模的增加而呈指數上升。為了在預定時間內開發出規模龐大的軟件，必須由許多人分工合作，然而，如何保證每個人完成的工作合在一起確實能構成一個高質量的大型軟件系統，更是一個極端復雜困難的問題，不僅涉及許多技術問題，諸如分析方法、設計方法、形式說明方法、版本控制等，更重要的是必須有嚴格而科學的管理。軟件(software)是計算機系統中與硬件(hardware)相互依存的另一部分，它包括：程序(program)——是按照事先設計的功能和性能要求執行的指令序列相關數據(data)——是程序能正常操縱信息的數據結構說明文檔(document)——是與程序開發維護和使用有關的各種圖文資料什么是軟件軟件本身獨有的特點確實給開發和維護帶來一些客觀困難，但是人們在開發和使用計算機系統的長期實踐中，也確實積累和總結出了許多成功的經驗。如果堅持不懈地使用經過實踐考驗證明是正確的方法，許多困難是完全可以克服的，過去也確實有一些成功的范例。但是，目前相當多的軟件專業人員對軟件開發和維護還有不少糊涂觀念，在實踐過程中或多或少地采用了錯誤的方法和技術，這可能是使軟件問題發展成軟件危機的主要原因。

與軟件開發和維護有關的許多錯誤認識和作法的形成，可以歸因于在計算機系統發展的早期階段軟件開發的個體化特點。錯誤的認識和作法主要表現為忽視軟件需求分析的重要性，認為軟件開發就是寫程序并設法使之運行，輕視軟件維護等。

事實上，對用戶要求沒有完整準確的認識就匆忙著手編寫程序是許多軟件開發工程失敗的主要原因之一。只有用戶才真正了解他們自己的需要，但是許多用戶在開始時并不能準確具體地敘述他們的需要，軟件開發人員需要做大量深入細致的調查研究工作，反復多次地和用戶交流信息，才能真正全面、準確、具體地了解用戶的要求。對問題和目標的正確認識是解決任何問題的前提和出發點，軟件開發同樣也不例外。急于求成，倉促上陣，對用戶要求沒有正確認識就匆忙著手編寫程序，這就如同不打好地基就蓋高樓一樣，最終必然垮臺。事實上，越早開始寫程序，完成它所需要用的時間往往越長。

一個軟件從定義、開發、使用和維護，直到最終被廢棄，要經歷一個漫長的時期，這就如同一個人要經過胎兒、兒童、青年、中年和老年，直到最終死亡的漫長時期一樣。通常把軟件經歷的這個漫長的時期稱為生命周期。軟件開發最初的工作應是問題定義，也就是確定要求解決的問題是什么；然后要進行可行性研究，決定該問題是否存在一個可行的解決辦法；接下來應該進行需求分析，也就是深入具體地了解用戶的要求，在所要開發的系統(不妨稱之為目標系統)必須做什么這個問題上和用戶取得完全一致的看法。

經過上述軟件定義時期的準備工作才能進入開發時期，而在開發時期首先需要對軟件進行設計(通常又分為概要設計和詳細設計兩個階段)，然后才能進入編寫程序的階段，程序編寫完之后還必須經過大量的測試工作(需要的工作量通常占軟件開發全部工作量的40%～50%)才能最終交付使用。所以，編寫程序只是軟件開發過程中的一個階段，而且在典型的軟件開發工程中，編寫程序所需的工作量只占軟件開發全部工作量的10%～20%。

另一方面還必須認識到程序只是完整的軟件產品的一個組成部分，在上述軟件生命周期的每個階段都要得出最終產品的一個或幾個組成部分(這些組成部分通常以文檔資料的形式存在)。也就是說，一個軟件產品必須由一個完整的配置組成，軟件配置主要包括程序、文檔和數據等成分。必須清除只重視程序而忽視軟件配置其余成分的糊涂觀念。作好軟件定義時期的工作，是降低軟件成本提高軟件質量的關鍵。如果軟件開發人員在定義時期沒有正確全面地理解用戶需求，直到測試階段或軟件交付使用后才發現“已完成的”軟件不完全符合用戶的需要，這時再修改就為時已晚了。

嚴重的問題是，在軟件開發的不同階段進行修改需要付出的代價是很不相同的，在早期引入變動，涉及的面較少，因而代價也比較低；而在開發的中期軟件配置的許多成分已經完成，引入一個變動要對所有已完成的配置成分都做相應的修改，不僅工作量大，而且邏輯上也更復雜，因此付出的代價劇增；在軟件“已經完成”時再引入變動，當然需要付出更高的代價。根據美國一些軟件公司的統計資料，在后期引入一個變動比在早期引入相同變動所需付出的代價高2～3個數量級。圖1.1定性地描繪了在不同時期引入一個變動需要付出的代價的變化趨勢。圖1.1引入同一變動付出的代價隨時間變化的趨勢

通過上面的論述不難認識到，輕視維護是一個最大的錯誤。許多軟件產品的使用壽命長達10年甚至20年，在這樣漫長的時期中不僅必須改正使用過程中發現的每一個潛伏的錯誤，而且當環境變化時（例如硬件或系統軟件更新換代）還必須相應地修改軟件以適應新的環境，特別是必須經常改進或擴充原來的軟件以滿足用戶不斷變化的需要。所有這些改動都屬于維護工作，而且是在軟件已經完成之后進行的，因此維護是極端艱巨復雜的工作，需要花費很大代價。統計數據表明，實際上用于軟件維護的費用占軟件總費用的55%~70%。軟件工程學的一個重要目標就是提高軟件的可維護性，減少軟件維護的代價。

為了消除軟件危機，首先應該對計算機軟件有一個正確的認識。正如1.1.2節中講過的，應該徹底消除在計算機系統早期發展階段形成的“軟件就是程序”的錯誤觀念。一個軟件必須由一個完整的配置組成，事實上，軟件是程序、數據及相關文檔的完整集合。其中，程序是能夠完成預定功能和性能的可執行的指令序列；數據是使程序能夠適當地處理信息的數據結構；文檔是開發、使用和維護程序所需要的圖文資料。1.1.3消除軟件危機的途徑

1983年IEEE為軟件下的定義是：計算機程序、方法、規則、相關的文檔資料以及在計算機上運行程序時所必需的數據。雖然表面上看來在這個定義中列出了軟件的5個配置成分，但是，方法和規則通常是在文檔中說明并在程序中實現的。更重要的是，必須充分認識到軟件開發不是某種個體勞動的神秘技巧，而應該是一種組織良好、管理嚴密、各類人員協同配合、共同完成的工程項目。必須充分吸取和借鑒人類長期以來從事各種工程項目所積累的行之有效的原理、概念、技術和方法，特別要吸取幾十年來人類從事計算機硬件研究和開發的經驗教訓。應該推廣使用在實踐中總結出來的開發軟件的成功的技術和方法，并且研究探索更好更有效的技術和方法，盡快消除在計算機系統早期發展階段形成的一些錯誤概念和做法。應該開發和使用更好的軟件工具。正如機械工具可以“放大”人類的體力一樣，軟件工具可以“放大”人類的智力。在軟件開發的每個階段都有許多繁瑣重復的工作需要做，在適當的軟件工具輔助下，開發人員可以把這類工作做得既快又好。如果把各個階段使用的軟件工具有機地集合成一個整體，支持軟件開發的全過程，則稱為軟件工程支撐環境。總之，為了解決軟件危機，既要有技術措施(方法和工具)，又要有必要的組織管理措施。軟件工程正是從管理和技術兩方面研究如何更好地開發和維護計算機軟件的一門新興學科。1.第一代軟件工程

—

傳統的軟件工程2.第二代軟件工程—對象工程3.第三代軟件工程—過程工程4.第四代軟件工程—構件工程軟件工程的發展已經歷了四個重要階段：1.2軟件工程1.第一代軟件工程

—

傳統的軟件工程

60年代末到70年代為了克服“軟件危機”(Softwarecrisis)提出“軟件工程”的名詞,將軟件開發納入工程化的軌道，基本形成軟件工程的概念、框架、技術和方法。稱為傳統的軟件工程。2.第二代軟件工程—對象工程

80年代中到90年代，面向對象的方法與技術得到發展，研究的重點轉移到面向對象的分析與設計，演化為一種完整的軟件開發方法和系統的技術體系，稱為對象工程。3.第三代軟件工程—過程工程

80年代中開始，人們在軟件開發的實踐過程中認識到：提高軟件生產率，保證軟件質量的關鍵是“軟件過程”，是軟件開發和維護中的管理和支持能力，逐步形成軟件過程工程。4.第四代軟件工程—構件工程

90起年代，基于構件（Component）的開發方法取得重要進展，軟件系統的開發可通過使用現成的可復用構件組裝完成，而無需從頭開始構造，以此達到提高效率和質量，降低成本的目的。稱為構件工程。概括地說，軟件工程是指導計算機軟件開發和維護的一門工程學科。采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟件并有效地維護它，這就是軟件工程。人們曾經給軟件工程下過許多定義，下面給出兩個典型的定義。1.2.1軟件工程的介紹1968年在第一屆NATO會議上曾經給出了軟件工程的一個早期定義：“軟件工程就是為了經濟地獲得可靠的且能在實際機器上有效地運行的軟件，而建立和使用完善的工程原理。”這個定義不僅指出了軟件工程的目標是經濟地開發出高質量的軟件，而且強調了軟件工程是一門工程學科，它應該建立并使用完善的工程原理。1993年IEEE進一步給出了一個更全面更具體的定義：“軟件工程是：①把系統的、規范的、可度量的途徑應用于軟件開發、運行和維護過程，也就是把工程應用于軟件；②研究①中提到的途徑。”

雖然軟件工程的不同定義使用了不同詞句，強調的重點也有差異，但是，人們普遍認為軟件工程具有下述的本質特性。1.軟件工程關注于大型程序的構造

“大”與“小”的分界線并不十分清晰。通常把一個人在較短時間內寫出的程序稱為小型程序，而把多人合作用時半年以上才寫出的程序稱為大型程序。傳統的程序設計技術和工具是支持小型程序設計的，不能簡單地把這些技術和工具用于開發大型程序。事實上，在此處使用術語“程序”并不十分恰當，現在的軟件開發項目通常構造出包含若干個相關程序的“系統”。2.軟件工程的中心課題是控制復雜性通常，軟件所解決的問題十分復雜，以致不能把問題作為一個整體通盤考慮。人們不得不把問題分解，使得分解出的每個部分是可理解的，而且各部分之間保持簡單的通信關系。用這種方法并不能降低問題的整體復雜性，但是卻可使它變成可以管理的。注意，許多軟件的復雜性主要不是由問題的內在復雜性造成的，而是由必須處理的大量細節造成的。3.軟件經常變化絕大多數軟件都模擬了現實世界的某一部分。現實世界在不斷變化，軟件為了不被很快淘汰，必須隨著所模擬的現實世界一起變化。因此，在軟件系統交付使用后仍然需要耗費成本，而且在開發過程中必須考慮軟件將來可能的變化。4.開發軟件的效率非常重要目前，社會對新應用系統的需求超過了人力資源所能提供的限度，軟件供不應求的現象日益嚴重。因此，軟件工程的一個重要課題就是，尋求開發與維護軟件的更好更有效的方法和工具。5.和諧地合作是開發軟件的關鍵軟件處理的問題十分龐大，必須多人協同工作才能解決這類問題。為了有效地合作，必須明確地規定每個人的責任和相互通信的方法。事實上僅有上述規定還不夠，每個人還必須嚴格地按規定行事。為了迫使大家遵守規定，應該運用標準和規程。通常，可以用工具來支持這些標準和規程。總之，紀律是成功地完成軟件開發項目的一個關鍵。6.軟件必須有效地支持它的用戶開發軟件的目的是支持用戶的工作。軟件提供的功能應該能有效地協助用戶完成他們的工作。如果用戶對軟件系統不滿意，可以棄用該系統，至少也會立即提出新的需求。因此，僅僅用正確的方法構造系統還不夠，還必須構造出正確的系統。有效地支持用戶意味著必須仔細地研究用戶，以確定適當的功能需求、可用性要求及其他質量要求(例如，可靠性、響應時間等)。有效地支持用戶還意味著，軟件開發不僅應該提交軟件產品，而且應該寫出用戶手冊和培訓材料，此外，還必須注意建立使用新系統的環境。7.在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人創造產品這個特性與前兩個特性緊密相關。軟件工程師是諸如Java程序設計、軟件體系結構、測試或統一建模語言(UML)等方面的專家，他們通常并不是圖書館管理、航空控制或銀行事務等領域的專家，但是他們卻不得不為這些領域開發應用系統。缺乏應用領域的相關知識，是軟件開發項目出現問題的常見原因。軟件工程師不僅缺乏應用領域的實際知識，他們還缺乏該領域的文化知識。例如，軟件開發者通過訪談、閱讀書面文件等方法了解到用戶組織的“正式”工作流程，然后用軟件實現了這個工作流程。但是，決定軟件系統成功與否的關鍵問題是，用戶組織是否真正遵守這個工作流程。對于局外人來說，這個問題更難回答。

自從1968年在聯邦德國召開的國際會議上正式提出并使用了“軟件工程”這個術語以來，研究軟件工程的專家學者們陸續提出了100多條關于軟件工程的準則或“信條”。著名的軟件工程專家B.W.Boehm綜合這些學者們的意見并總結了TRW公司多年開發軟件的經驗，于1983年在一篇論文中提出了軟件工程的7條基本原理。他認為這7條原理是確保軟件產品質量和開發效率的原理的最小集合。1.2.2軟件工程的基本原理

這7條原理是互相獨立的，其中任意6條原理的組合都不能代替另一條原理，因此，它們是缺一不可的最小集合，然而這7條原理又是相當完備的，人們雖然不能用數學方法嚴格證明它們是一個完備的集合，但是，可以證明在此之前已經提出的100多條軟件工程原理都可以由這7條原理的任意組合蘊含或派生。下面簡要介紹軟件工程的7條基本原理。1.用分階段的生命周期計劃嚴格管理有人經統計發現，在不成功的軟件項目中有一半左右是由于計劃不周造成的，可見把建立完善的計劃作為第一條基本原理是吸取了前人的教訓而提出來的。

在軟件開發與維護的漫長的生命周期中，需要完成許多性質各異的工作。這條基本原理意味著，應該把軟件生命周期劃分成若干個階段，并相應地制定出切實可行的計劃，然后嚴格按照計劃對軟件的開發與維護工作進行管理。不同層次的管理人員都必須嚴格按照計劃各盡其職地管理軟件開發與維護工作，絕不能受客戶或上級人員的影響而擅自背離預定計劃。2.堅持進行階段評審

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

軟件工程包括技術和管理兩方面的內容，是技術與管理緊密結合所形成的工程學科。所謂管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到既定目標的過程。通常把在軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學(methodology)，也稱為范型(paradigm)。在軟件工程領域中，這兩個術語的含義基本相同。1.2.3軟件工程方法學

軟件工程方法學包含3個要素：方法、工具和過程。其中，方法是完成軟件開發的各項任務的技術方法，回答“怎樣做”的問題；工具是為運用方法而提供的自動的或半自動的軟件工程支撐環境；過程是為了獲得高質量的軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。目前使用得最廣泛的軟件工程方法學，分別是傳統方法學和面向對象方法學。1.傳統方法學傳統方法學也稱為生命周期方法學或結構化范型。它采用結構化技術(結構化分析、結構化設計和結構化實現)來完成軟件開發的各項任務，并使用適當的軟件工具或軟件工程環境來支持結構化技術的運用。這種方法學把軟件生命周期的全過程依次劃分為若干個階段，然后順序地完成每個階段的任務。采用這種方法學開發軟件的時候，從對問題的抽象邏輯分析開始，一個階段一個階段地進行開發。

前一個階段任務的完成是開始進行后一個階段工作的前提和基礎，而后一階段任務的完成通常是使前一階段提出的解法更進一步具體化，加進了更多的實現細節。每一個階段的開始和結束都有嚴格標準，對于任何兩個相鄰的階段而言，前一階段的結束標準就是后一階段的開始標準。在每一個階段結束之前都必須進行正式嚴格的技術審查和管理復審，從技術和管理兩方面對這個階段的開發成果進行檢查，通過之后這個階段才算結束；如果沒通過檢查，則必須進行必要的返工，而且返工后還要再經過審查。審查的一條主要標準就是每個階段都應該交出“最新式的”(即和所開發的軟件完全一致的)高質量的文檔資料，從而保證在軟件開發工程結束時有一個完整準確的軟件配置交付使用。文檔是通信的工具，它們清楚準確地說明了到這個時候為止，關于該項工程已經知道了什么，同時奠定了下一步工作的基礎。此外，文檔也起備忘錄的作用，如果文檔不完整，那么一定是某些工作忘記做了，在進入生命周期的下一個階段之前，必須補足這些遺漏的細節。把軟件生命周期劃分成若干個階段，每個階段的任務相對獨立，而且比較簡單，便于不同人員分工協作，從而降低了整個軟件開發工程的困難程度；在軟件生命周期的每個階段都采用科學的管理技術和良好的技術方法，而且在每個階段結束之前都從技術和管理兩個角度進行嚴格的審查，合格之后才開始下一階段的工作，這就使軟件開發工程的全過程以一種有條不紊的方式進行，保證了軟件的質量，特別是提高了軟件的可維護性。總之，采用生命周期方法學可以大大提高軟件開發的成功率，軟件開發的生產率也能明顯提高。

目前，傳統方法學仍然是人們在開發軟件時使用得十分廣泛的軟件工程方法學。這種方法學歷史悠久，為廣大軟件工程師所熟悉，而且在開發某些類型的軟件時也比較有效，因此，在相當長一段時期內這種方法學還會有生命力。此外，如果沒有完全理解傳統方法學，也就不能深入理解這種方法學與面向對象方法學的差別以及面向對象方法學為何優于傳統方法學。因此，本書不僅講述面向對象方法學，也講述傳統方法學。2.面向對象方法學當軟件規模龐大，或者對軟件的需求是模糊的或會隨時間而變化的時候，使用傳統方法學開發軟件往往不成功，此外，使用傳統方法學開發出的軟件，維護起來仍然很困難。結構化范型只能獲得有限成功的一個重要原因是，這種技術要么面向行為(即對數據的操作)，要么面向數據，還沒有既面向數據又面向行為的結構化技術。眾所周知，軟件系統本質上是信息處理系統。離開了操作便無法更改數據，而脫離了數據的操作是毫無意義的。數據和對數據的處理原本是密切相關的，把數據和操作人為地分離成兩個獨立的部分，自然會增加軟件開發與維護的難度。與傳統方法相反，面向對象方法把數據和行為看成同等重要，它是一種以數據為主線，把數據和對數據的操作緊密地結合起來的方法。概括地說，面向對象方法學具有下述4個要點。(1)把對象(object)作為融合了數據及在數據上的操作行為的統一的軟件構件。面向對象程序是由對象組成的，程序中任何元素都是對象，復雜對象由比較簡單的對象組合而成。也就是說，用對象分解取代了傳統方法的功能分解。(2)把所有對象都劃分成類(class)。每個類都定義了一組數據和一組操作，類是對具有相同數據和相同操作的一組相似對象的定義。數據用于表示對象的靜態屬性，是對象的狀態信息，而施加于數據之上的操作用于實現對象的動態行為。(3)按照父類(或稱為基類)與子類(或稱為派生類)的關系，把若干個相關類組成一個層次結構的系統(也稱為類等級)。在類等級中，下層派生類自動擁有上層基類中定義的數據和操作，這種現象稱為繼承。(4)對象彼此間僅能通過發送消息互相聯系。對象與傳統數據有本質區別，它不是被動地等待外界對它施加操作，相反，它是數據處理的主體，必須向它發消息請求它執行它的某個操作以處理它的數據，而不能從外界直接對它的數據進行處理。也就是說，對象的所有私有信息都被封裝在該對象內，不能從外界直接訪問，這就是通常所說的封裝性。

面向對象方法學的出發點和基本原則，是盡量模擬人類習慣的思維方式，使開發軟件的方法與過程盡可能接近人類認識世界解決問題的方法與過程，從而使描述問題的問題空間(也稱為問題域)與實現解法的解空間(也稱為求解域)在結構上盡可能一致。傳統方法學強調自頂向下順序地完成軟件開發的各階段任務。事實上，人類認識客觀世界解決現實問題的過程，是一個漸進的過程。人的認識需要在繼承已有的有關知識的基礎上，經過多次反復才能逐步深化。在人的認識深化過程中，既包括了從一般到特殊的演繹思維過程，也包括了從特殊到一般的歸納思維過程。用面向對象方法學開發軟件的過程，是一個主動地多次反復迭代的演化過程。面向對象方法在概念和表示方法上的一致性，保證了在各項開發活動之間的平滑(即無縫)過渡。面向對象方法普遍進行的對象分類過程，支持從特殊到一般的歸納思維過程；通過建立類等級而獲得的繼承性，支持從一般到特殊的演繹思維過程。正確地運用面向對象方法學開發軟件，則最終的軟件產品由許多較小的、基本上獨立的對象組成，每個對象相當于一個微型程序，而且大多數對象都與現實世界中的實體相對應，因此，降低了軟件產品的復雜性，提高了軟件的可理解性，簡化了軟件的開發和維護工作。對象是相對獨立的實體，容易在以后的軟件產品中重復使用，因此，面向對象范型的另一個重要優點是促進了軟件重用。面向對象方法特有的繼承性和多態性，進一步提高了面向對象軟件的可重用性。

概括地說，軟件生命周期由軟件定義、軟件開發和運行維護(也稱為軟件維護)3個時期組成，每個時期又進一步劃分成若干個階段。軟件定義時期的任務是：確定軟件開發工程必須完成的總目標；確定工程的可行性；導出實現工程目標應該采用的策略及系統必須完成的功能；估計完成該項工程需要的資源和成本，并且制定工程進度表。這個時期的工作通常又稱為系統分析，由系統分析員負責完成。軟件定義時期通常進一步劃分成3個階段，即問題定義、可行性研究和需求分析。1.3軟件生命周期開發時期具體設計和實現在前一個時期定義的軟件，它通常由下述4個階段組成：總體設計，詳細設計，編碼和單元測試，綜合測試。其中前兩個階段又稱為系統設計，后兩個階段又稱為系統實現。維護時期的主要任務是使軟件持久地滿足用戶的需要。具體地說，當軟件在使用過程中發現錯誤時應該加以改正；當環境改變時應該修改軟件以適應新的環境；當用戶有新要求時應該及時改進軟件以滿足用戶的新需要。通常對維護時期不再進一步劃分階段，但是每一次維護活動本質上都是一次壓縮和簡化了的定義和開發過程。下面扼要介紹軟件生命周期每個階段的基本任務。1.問題定義問題定義階段必須回答的關鍵問題是：“要解決的問題是什么?”如果不知道問題是什么就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。通過對客戶的訪問調查，系統分析員扼要地寫出關于問題性質、工程目標和工程規模的書面報告，經過討論和必要的修改之后這份報告應該得到客戶的確認。2.可行性研究這個階段要回答的關鍵問題是：“對于上一個階段所確定的問題有行得通的解決辦法嗎?”為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計過程，也就是在較抽象的高層次上進行的分析和設計過程。可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。可行性研究的結果是使用部門負責人作出是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程項目才值得繼續進行下去。可行性研究以后的那些階段將需要投入更多的人力物力。及時終止不值得投資的工程項目，可以避免更大的浪費。3.需求分析這個階段的任務仍然不是具體地解決問題，而是準確地確定“為了解決這個問題，目標系統必須做什么”，主要是確定目標系統必須具備哪些功能。用戶了解他們所面對的問題，知道必須做什么，但通常不能完整準確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟件開發人員知道怎樣用軟件實現人們的要求，但是對特定用戶的具體要求并不完全清楚。因此，系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的算法表示系統的邏輯模型。在需求分析階段確定的系統邏輯模型是以后設計和實現目標系統的基礎，因此必須準確完整地體現用戶的要求。這個階段的一項重要任務，是用正式文檔準確地記錄對目標系統的需求，這份文檔通常稱為規格說明書(specification)。4.總體設計這個階段必須回答的關鍵問題是：“概括地說，應該怎樣實現目標系統?”總體設計又稱為概要設計。首先，應該設計出實現目標系統的幾種可能的方案。通常至少應該設計出低成本、中等成本和高成本等3種方案。軟件工程師應該用適當的表達工具描述每種方案，分析每種方案的優缺點，并在充分權衡各種方案的利弊的基礎上，推薦一個最佳方案。此外，還應該制定出實現最佳方案的詳細計劃。如果客戶接受所推薦的方案，則應該進一步完成下述的另一項主要任務。

上述設計工作確定了解決問題的策略及目標系統中應包含的程序，但是，怎樣設計這些程序呢?軟件設計的一條基本原理就是，程序應該模塊化，也就是說，一個程序應該由若干個規模適中的模塊按合理的層次結構組織而成。因此，總體設計的另一項主要任務就是設計程序的體系結構，也就是確定程序由哪些模塊組成以及模塊間的關系。5.詳細設計

總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：“應該怎樣具體地實現這個系統呢?”這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明的作用很類似于其他工程領域中工程師經常使用的工程藍圖，它們應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。詳細設計也稱為模塊設計，在這個階段將詳細地設計每個模塊，確定實現模塊功能所需要的算法和數據結構。6.編碼和單元測試這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言(必要時用匯編語言)，把詳細設計的結果翻譯成用選定的語言書寫的程序，并且仔細測試編寫出的每一個模塊。7.綜合測試這個階段的關鍵任務是通過各種類型的測試(及相應的調試)使軟件達到預定的要求。最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟件結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定，由用戶對目標系統進行驗收。

必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。為了使用戶能夠積極參加驗收測試，并且在系統投入生產性運行以后能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。通過對軟件測試結果的分析可以預測軟件的可靠性；反之，根據對軟件可靠性的要求，也可以決定測試和調試過程什么時候可以結束。應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果保存下來，作為軟件配置的一個組成部分。8.軟件維護維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。通常有4類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟件錯誤；適應性維護，即修改軟件以適應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟件使它更完善；預防性維護，即修改軟件為將來的維護活動預先做準備。雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求(或報告問題)，分析維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟件設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟件定義和開發的全過程。每一項維護活動都應該準確地記錄下來，作為正式的文檔資料加以保存。在實際從事軟件開發工作時，軟件規模、種類、開發環境及開發時使用的技術方法等因素，都影響階段的劃分。軟件過程是為了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。在完成開發任務時必須進行一些開發活動，并且使用適當的資源，在過程結束時將把輸入轉化為輸出。因此，ISO9000把過程定義為“使用資源將輸入轉化為輸出的活動所構成的系統。”此處，“系統”的含義是廣義的：“系統是相互關聯或相互作用的一組要素。”1.4軟件過程過程定義了運用方法的順序、應該交付的文檔資料、為保證軟件質量和協調變化所需要采取的管理措施，以及標志軟件開發各個階段任務完成的里程碑。為獲得高質量的軟件產品，軟件過程必須科學、有效。沒有一個適用于所有軟件項目的任務集合。因此，科學、有效的軟件過程應該定義一組適合于所承擔的項目特點的任務集合。通常，一個任務集合包括一組軟件工程任務、里程碑和應該交付的產品。通常使用生命周期模型簡潔地描述軟件過程。生命周期模型規定了把生命周期劃分成哪些階段及各個階段的執行順序，因此，也稱為過程模型。實際從事軟件開發工作時應該根據所承擔的項目的特點來劃分階段，但是，下面講述典型的軟件過程模型時并不是針對某個特定項目講的，因此只能使用“通用的”階段劃分方法。由于瀑布模型與快速原型模型的主要區別是獲取用戶需求的方法不同，因此，下面在介紹生命周期模型時把“規格說明”作為一個階段獨立出來。此外，問題定義和可行性研究的主要任務都是概括地了解用戶的需求，為了簡潔地描述軟件過程，把它們都歸并到需求分析中去了。同樣，為了簡潔起見，把總體設計和詳細設計合并在一起稱為“設計”。

在20世紀80年代之前，瀑布模型一直是惟一被廣泛采用的生命周期模型，現在它仍然是軟件工程中應用得最廣泛的過程模型。傳統軟件工程方法學的軟件過程，基本上可以用瀑布模型來描述。圖1.2所示為傳統的瀑布模型。按照傳統的瀑布模型開發軟件，有下述的幾個特點。1.4.1瀑布模型圖1.2傳統的瀑布模型1.階段間具有順序性和依賴性這個特點有兩重含義：①必須等前一階段的工作完成之后，才能開始后一階段的工作；②前一階段的輸出文檔就是后一階段的輸入文檔，因此，只有前一階段的輸出文檔正確，后一階段的工作才能獲得正確的結果。2.推遲實現的觀點對于規模較大的軟件項目來說，往往編碼開始得越早最終完成開發工作所需要的時間反而越長。這是因為，前面階段的工作沒做或做得不扎實，過早地考慮進行程序實現，往往導致大量返工，有時甚至發生無法彌補的問題，帶來災難性后果。瀑布模型在編碼之前設置了系統分析與系統設計的各個階段，分析與設計階段的基本任務規定，在這兩個階段主要考慮目標系統的邏輯模型，不涉及軟件的物理實現。清楚地區分邏輯設計與物理設計，盡可能推遲程序的物理實現，是按照瀑布模型開發軟件的一條重要的指導思想。3.質量保證的觀點軟件工程的基本目標是優質、高產。為了保證所開發的軟件的質量，在瀑布模型的每個階段都應堅持兩個重要做法：（1）每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務。完整、準確的合格文檔不僅是軟件開發時期各類人員之間相互通信的媒介，也是運行時期對軟件進行維護的重要依據。（2）每個階段結束前都要對所完成的文檔進行評審，以便盡早發現問題，改正錯誤。事實上，障改正錯誤所需付出的代價也越越是早期階段犯下的錯誤，暴露出來的時間就越晚，排除故高。因此，及時審查，是保證軟件質量，降低軟件成本的重要措施。傳統的瀑布模型過于理想化了，事實上，人在工作過程中不可能不犯錯誤。在設計階段可能發現規格說明文檔中的錯誤，而設計上的缺陷或錯誤可能在實現過程中顯現出來，在綜合測試階段將發現需求分析、設計或編碼階段的許多錯誤。因此，實際的瀑布模型是帶“反饋環”的，如圖1.3所示（圖中實線箭頭表示開發過程，虛線箭頭表示維護過程）。當在后面階段發現前面階段的錯誤時，需要沿圖中左側的反饋線返回前面的階段，修正前面階段的產品之后再回來繼續完成后面階段的任務。圖1.3實際的瀑布模型瀑布模型有許多優點：可強迫開發人員采用規范的方法（例如，結構化技術）；嚴格地規定了每個階段必須提交的文檔；要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證。各個階段產生的文檔是維護軟件產品時必不可少的，沒有文檔的軟件幾乎是不可能維護的。遵守瀑布模型的文檔約束，將使軟件維護變得比較容易一些。由于絕大部分軟件預算都花費在軟件維護上，因此，使軟件變得比較容易維護就能顯著降低軟件預算。可以說，瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅動的模型。但是，“瀑布模型是由文檔驅動的”這個事實也是它的一個主要缺點。在可運行的軟件產品交付給用戶之前，用戶只能通過文檔來了解產品是什么樣的。但是，僅僅通過寫在紙上的靜態的規格說明，很難全面正確地認識動態的軟件產品。而且事實證明，一旦一個用戶開始使用一個軟件，在他的頭腦中關于該軟件應該做什么的想法就會或多或少地發生變化，這就使得最初提出的需求變得不完全適用了。事實上，要求用戶不經過實踐就提出完整準確的需求，在許多情況下都是不切實際的。總之，由于瀑布模型幾乎完全依賴于書面的規格說明，很可能導致最終開發出的軟件產品不能真正滿足用戶的需要。所謂快速原型是快速建立起來的可以在計算機上運行的程序，它所能完成的功能往往是最終產品能完成的功能的一個子集。如圖1.4所示（圖中實線箭頭表示開發過程，虛線箭頭表示維護過程），快速原型模型的第一步是快速建立一個能反映用戶主要需求的原型系統，讓用戶在計算機上試用它，通過實踐來了解目標系統的概貌。1.4.2快速原型模型通常，用戶試用原型系統之后會提出許多修改意見，開發人員按照用戶的意見快速地修改原型系統，然后再次請用戶試用……一旦用戶認為這個原型系統確實能做他們所需要的工作，開發人員便可據此書寫規格說明文檔，根據這份文檔開發出的軟件可以滿足用戶的真實需求。從圖1.4可以看出，快速原型模型是不帶反饋環的，這正是這種過程模型的主要優點：軟件產品的開發基本上是線性順序進行的。能做到基本上線性順序開發的主要原因如下：圖1.4快速原型模型（1）原型系統已經通過與用戶交互而得到驗證，據此產生的規格說明文檔正確地描述了用戶需求，因此，在開發過程的后續階段不會因為發現了規格說明文檔的錯誤而進行較大的返工。（2）開發人員通過建立原型系統已經學到了許多東西（至少知道了“系統不應該做什么，以及怎樣不去做不該做的事情”），因此，在設計和編碼階段發生錯誤的可能性也比較小，這自然減少了在后續階段需要改正前面階段所犯錯誤的可能性。

軟件產品一旦交付給用戶使用之后，維護便開始了。根據所需完成的維護工作種類的不同，可能需要返回到需求分析、規格說明、設計或編碼等不同階段，如圖1.4中虛線箭頭所示。快速原型的本質是“快速”。開發人員應該盡可能快地建造出原型系統，以加速軟件開發過程，節約軟件開發成本。原型的用途是獲知用戶的真正需求，一旦需求確定了，原型將被拋棄。因此，原型系統的內部結構并不重要，重要的是，必須迅速地構建原型然后根據用戶意見迅速地修改原型。

UNIXShell和超文本都是廣泛使用的快速原型語言，最近的趨勢是，廣泛地使用第四代語言（4GL）構建快速原型。當快速原型的某個部分是利用軟件工具由計算機自動生成的時候，可以把這部分用到最終的軟件產品中。

增量模型也稱為漸增模型，如圖1.5所示。使用增量模型開發軟件時，把軟件產品作為一系列的增量構件來設計、編碼、集成和測試。每個構件由多個相互作用的模塊構成，并且能夠完成特定的功能。使用增量模型時，第一個增量構件往往實現軟件的基本需求，提供最核心的功能。第二個增量構件提供更完善的編輯和文檔生成功能；第三個增量構件實現拼寫和語法檢查功能；第四個增量構件完成高級的頁面排版功能。1.4.3增量模型把軟件產品分解成增量構件時，應該使構件的規模適中，規模過大或過小都不好。最佳分解方法因軟件產品特點和開發人員的習慣而異。分解時惟一必須遵守的約束條件是，當把新構件集成到現有軟件中時，所形成的產品必須是可測試的。

采用瀑布模型或快速原型模型開發軟件時，目標都是一次就把一個滿足所有需求的產品提交給用戶。增量模型則與之相反，它分批地逐步向用戶提交產品，整個軟件產品被分解成許多個增量構件，開發人員一個構件接一個構件地向用戶提交產品。從第一個構件交付之日起，用戶就能做一些有用的工作。顯然，能在較短時間內向用戶提交可完成部分工作的產品，是增量模型的一個優點。圖1.5增量模型增量模型的另一個優點是，逐步增加產品功能可以使用戶有較充裕的時間學習和適應新產品，從而減少一個全新的軟件可能給客戶組織帶來的沖擊。使用增量模型的困難是，在把每個新的增量構件集成到現有軟件體系結構中時，必須不破壞原來已經開發出的產品。此外，必須把軟件的體系結構設計得便于按這種方式進行擴充，向現有產品中加入新構件的過程必須簡單、方便，也就是說，軟件體系結構必須是開放的。但是，從長遠觀點看，具有開放結構的軟件擁有真正的優勢，這樣的軟件的可維護性明顯好于封閉結構的軟件。

因此，盡管采用增量模型比采用瀑布模型和快速原型模型需要更精心的設計，但在設計階段多付出的勞動將在維護階段獲得回報。如果一個設計非常靈活而且足夠開放，足以支持增量模型，那么，這樣的設計將允許在不破壞產品的情況下進行維護。事實上，使用增量模型時開發軟件和擴充軟件功能（完善性維護）并沒有本質區別，都是向現有產品中加入新構件的過程。從某種意義上說，增量模型本身是自相矛盾的。它一方面要求開發人員把軟件看作一個整體，另一方面又要求開發人員把軟件看作構件序列，每個構件本質上都獨立于另一個構件。除非開發人員有足夠的技術能力協調好這一明顯的矛盾，否則用增量模型開發出的產品可能并不令人滿意。

圖1.5所示的增量模型表明，必須在開始實現各個構件之前就全部完成需求分析、規格說明和概要設計的工作。由于在開始構建第一個構件之前已經有了總體設計，因此風險較小。圖1.6描繪了一種風險更大的增量模型：一旦確定了用戶需求之后，就著手擬定第一個構件的規格說明文檔，完成后規格說明組將轉向第二個構件的規格說明，與此同時設計組開始設計第一個構件……用這種方式開發軟件，不同的構件將并行地構建，因此有可能加快工程進度。但是，使用這種方法將冒構件無法集成到一起的風險，除非密切地監控整個開發過程，否則整個工程可能毀于一旦。圖1.6風險更大的增量模型軟件風險是任何軟件開發項目中都普遍存在的實際問題，項目越大，軟件越復雜，承擔該項目所冒的風險也越大。軟件風險可能在不同程度上損害軟件開發過程和軟件產品質量。因此，在軟件開發過程中必須及時識別和分析風險，并且采取適當措施以消除或減少風險的危害。1.4.4螺旋模型

構建原型是一種能使某些類型的風險降至最低的方法。正如1.4.2節所述，為了降低交付給用戶的產品不能滿足用戶需要的風險，一種行之有效的方法是在需求分析階段快速地構建一個原型。在后續的階段中也可以通過構造適當的原型來降低某些技術風險。當然，原型并不