《軟件工程》課件第1章 緒論

第1章緒論

1.1軟件工程的產(chǎn)生

1.2軟件工程的過程和軟件生存周期1.3軟件生存周期模型1.4軟件開發(fā)方法1.5軟件開發(fā)工具1.6小結(jié)習(xí)題1.1軟件工程的產(chǎn)生 1.1.1軟件的特點

“軟件”一詞是20世紀60年代才出現(xiàn)的，其定義為計算機程序及其說明程序的各種文檔。在該定義中，“程序”是計算任務(wù)的處理對象和處理規(guī)則的描述；“文檔”是有關(guān)計算機程序功能、設(shè)計、編制、使用的文字或圖形資料。軟件與硬件一起構(gòu)成了完整的計算機系統(tǒng)，它們是相互依存，缺一不可的。軟件是一種特殊的產(chǎn)品，它具有下列一些特性： (1)軟件是一種邏輯產(chǎn)品，它與物質(zhì)產(chǎn)品有很大的區(qū)別。軟件產(chǎn)品是看不見摸不著的，因而具有無形性。它是腦力勞動的結(jié)晶。它以程序和文檔的形式出現(xiàn)，保存在計算機存儲器的磁盤和光盤介質(zhì)上，通過計算機的運行才能體現(xiàn)它的功能和作用。

(2)軟件產(chǎn)品的生產(chǎn)主要是研制。其成本主要體現(xiàn)在軟件的開發(fā)和研制上，軟件開發(fā)研制完成后，通過復(fù)制就產(chǎn)生了大量的軟件產(chǎn)品。

(3)軟件產(chǎn)品不會用壞，不存在磨損、消耗問題。

(4)軟件產(chǎn)品的生產(chǎn)主要是腦力勞動，還未完全擺脫手工開發(fā)方式，大部分產(chǎn)品是“定做”的。

(5)軟件費用不斷增加，軟件成本相當昂貴。軟件的研制工作需要投放大量的、復(fù)雜的、高強度的腦力勞動，它的成本非常高。 1.1.2軟件生產(chǎn)的發(fā)展 自從第一臺計算機誕生以來，就開始了軟件的生產(chǎn)，到目前為止，已經(jīng)過了程序設(shè)計、程序系統(tǒng)和軟件工程三個時代。

1．程序設(shè)計時代(1946～1956年)

程序設(shè)計時代的生產(chǎn)方式是個體手工勞動，使用的工具是機器語言、匯編語言；開發(fā)方法是追求編程技巧，追求程序運行效率，使得程序難讀、難懂、難修改；硬件特征是價格高、存儲容量小、運行可靠性差；軟件特征是只有程序、程序設(shè)計概念，不重視程序設(shè)計方法。 2．程序系統(tǒng)時代(1956～1968年)

程序系統(tǒng)時代的生產(chǎn)方式是作坊式的小集團合作生產(chǎn)，生產(chǎn)工具是高級語言；開發(fā)方法仍舊靠個人技巧，但開始提出了結(jié)構(gòu)化方法；硬件特征是：速度、容量及工作可靠性有明顯提高，價格降低，銷售有爆炸性增長；軟件特征是：程序員數(shù)量猛增，其他行業(yè)人員大量進入這個行業(yè)，由于缺乏訓(xùn)練，開發(fā)人員素質(zhì)差。這時已意識到軟件開發(fā)的重要性，大量軟件開發(fā)的需求已被提出，但開發(fā)技術(shù)沒有新的突破，開發(fā)人員的素質(zhì)和落后的開發(fā)技術(shù)不適應(yīng)規(guī)模大、結(jié)構(gòu)復(fù)雜的軟件開發(fā)，因此產(chǎn)生了尖銳的矛盾，導(dǎo)致軟件危機的產(chǎn)生。 3．軟件工程時代(1968年至今)

軟件工程時代的生產(chǎn)方式是工程化的生產(chǎn)，使用數(shù)據(jù)庫、開發(fā)工具、開發(fā)環(huán)境、網(wǎng)絡(luò)、分布式、面向?qū)ο蠹夹g(shù)來開發(fā)軟件；硬件特征是：向超高速、大容量、微型化以及網(wǎng)絡(luò)化方向發(fā)展；軟件特征是：開發(fā)技術(shù)有很大進步，但是未能獲得突破性進展，軟件價格不斷上升，沒有完全擺脫軟件危機。

1.1.3軟件危機

1．軟件危機的產(chǎn)生 軟件發(fā)展第二階段的末期，由于計算機硬件技術(shù)的進步，計算機運行速度、容量和可靠性有顯著的提高，生產(chǎn)成本顯著下降，這為計算機的廣泛應(yīng)用創(chuàng)造了良好的條件。

一些復(fù)雜的、大型的軟件開發(fā)項目被提出來，但是，軟件開發(fā)技術(shù)一直未能滿足發(fā)展的要求。軟件開發(fā)中遇到的問題因找不到解決的辦法，使問題積累起來，形成了尖銳的矛盾，導(dǎo)致了軟件危機。

2．軟件危機的表現(xiàn) 軟件危機表現(xiàn)在以下幾方面：

(1)經(jīng)費預(yù)算經(jīng)常突破，完成時間一再拖延。由于缺乏軟件開發(fā)的經(jīng)驗和軟件開發(fā)數(shù)據(jù)的積累，使得開發(fā)工作的計劃很難制定。主觀盲目制定的計劃，執(zhí)行起來和實際情況有很大差距，使得開發(fā)經(jīng)費一再突破。由于對工作量和開發(fā)難度估計不足，計劃無法按時完成，而使得開發(fā)時間一再拖延。 (2)開發(fā)的軟件不能滿足用戶要求。開發(fā)初期對用戶的要求了解不夠明確，未能得到明確表達。開發(fā)工作開始后，軟件人員和用戶又未能及時交換意見，使得一些問題不能及時解決，導(dǎo)致開發(fā)的軟件不能滿足用戶的要求，使開發(fā)失敗。

(3)開發(fā)的軟件可維護性差。開發(fā)過程沒有統(tǒng)一的、公認的規(guī)范，軟件開發(fā)人員按各自的風(fēng)格工作，各行其事。開發(fā)過程無完整、規(guī)范的文檔，發(fā)現(xiàn)問題后進行雜亂無章的修改。程序結(jié)構(gòu)不好，運行時發(fā)現(xiàn)的錯誤也很難修改，導(dǎo)致軟件可維護性差。 (4)開發(fā)的軟件可靠性差。由于在開發(fā)過程中，沒有確保軟件質(zhì)量的體系和措施，在軟件測試時，又沒有嚴格的、充分的、完全的測試，提交給用戶的軟件質(zhì)量差，在運行中暴露出大量的問題。這種不可靠的軟件，輕者會影響系統(tǒng)正常工作，重者會發(fā)生事故，造成生命財產(chǎn)的重大損失。

3．軟件危機的原因 造成上述軟件危機的原因概括起來有以下幾方面。 (1)軟件的規(guī)模越來越大，結(jié)構(gòu)越來越復(fù)雜。隨著計算機應(yīng)用的日益廣泛，需要開發(fā)的軟件規(guī)模日益龐大，軟件結(jié)構(gòu)也日益復(fù)雜。1968年美國航空公司訂票系統(tǒng)達到30萬條指令；IBM360OS第16版達到100萬條指令，花了5000個人年；1973年美國阿波羅計劃達到1千萬條指令。這些龐大軟件的功能非常復(fù)雜，體現(xiàn)在處理功能的多樣性和運行環(huán)境的多樣性。有人曾估計，軟件設(shè)計與硬件設(shè)計相比，其邏輯量要多達10～100倍。對于這種龐大規(guī)模的軟件，其調(diào)用關(guān)系、接口信息復(fù)雜，數(shù)據(jù)結(jié)構(gòu)也復(fù)雜，這種復(fù)雜程度超過了人所能接受的程度。

(2)軟件開發(fā)的管理困難。由于軟件規(guī)模大，結(jié)構(gòu)復(fù)雜，又具有無形性，導(dǎo)致管理困難，進度控制困難，質(zhì)量控制困難，可靠性無法保證。 (3)軟件開發(fā)費用不斷增加。軟件生產(chǎn)是一種智力勞動，它是資金密集、人力密集的產(chǎn)業(yè)，大型軟件投入人力多，周期長，費用上升很快。

(4)軟件開發(fā)技術(shù)落后。在20世紀60年代，人們注重一些計算機理論問題的研究，如編譯原理、操作系統(tǒng)原理、數(shù)據(jù)庫原理、人工智能原理、形式語言理論等，不注重軟件開發(fā)技術(shù)的研究，用戶要求的軟件其復(fù)雜性與軟件技術(shù)解決復(fù)雜性的能力不相適應(yīng)，它們之間的差距越來越大。

(5)生產(chǎn)方式落后。軟件仍然采用個體手工方式開發(fā)。根據(jù)個人習(xí)慣和愛好工作，無章可循，無規(guī)范可依據(jù)，靠言傳身教方式工作。 (6)開發(fā)工具落后，生產(chǎn)率提高緩慢。軟件開發(fā)工具過于原始，沒有出現(xiàn)高效率的開發(fā)工具，因而軟件生產(chǎn)率低下。在1960～1980年期間，計算機硬件的生產(chǎn)由于采用計算機輔助設(shè)計、自動生產(chǎn)線等先進工具，使硬件生產(chǎn)率提高了100萬倍，而軟件生產(chǎn)率只提高了2倍，相差十分懸殊。

1.1.4軟件工程 為了克服軟件危機，人們從其他產(chǎn)業(yè)的工程化生產(chǎn)得到啟示，于是在1968年北大西洋公約組織的工作會議上首先提出“軟件工程”的概念，提出要用工程化的思想來開發(fā)軟件。從此，軟件生產(chǎn)進入了軟件工程時代。 1．軟件工程的定義 軟件工程是用科學(xué)知識和技術(shù)原理來定義、開發(fā)、維護軟件的一門學(xué)科。該定義說明了軟件工程是計算機科學(xué)中的一個分支，其主要思想是在軟件生產(chǎn)中用工程化的方法代替?zhèn)鹘y(tǒng)手工方法。工程化的方法借用了傳統(tǒng)的工程設(shè)計原理的基本思想，采用了若干科學(xué)的、現(xiàn)代化的方法技術(shù)來開發(fā)軟件。這種工程化的思想貫穿到需求分析、設(shè)計、實現(xiàn)，直到維護的整個過程。

2．軟件工程的性質(zhì) 軟件工程是涉及計算機科學(xué)、工程科學(xué)、管理科學(xué)、數(shù)學(xué)等領(lǐng)域的一門綜合性的交叉學(xué)科。計算機科學(xué)中的研究成果均可用于軟件工程，但計算機科學(xué)側(cè)重于原理和理論的研究，而軟件工程側(cè)重于如何建造一個軟件系統(tǒng)。 軟件工程要用工程科學(xué)中的觀點來進行費用估算，制定進度、計劃和方案；要用管理科學(xué)中的方法和原理進行軟件生產(chǎn)的管理；要用數(shù)學(xué)的方法建立軟件開發(fā)中的各種模型和各種算法，如可靠性模型，說明用戶需求的形式化模型等。 3．軟件工程的目標 軟件工程是一門工程性學(xué)科，目的是成功地建造一個大型軟件系統(tǒng)。所謂成功，是要達到以下幾個目標：付出較低的開發(fā)成本；達到要求的軟件功能；取得較好的軟件性能；開發(fā)的軟件易于移植；需要較低的維護費用；能按時完成開發(fā)任務(wù)，及時交付使用；開發(fā)的軟件可靠性高。

4．軟件工程的內(nèi)容 軟件工程研究的主要內(nèi)容是指軟件開發(fā)技術(shù)和軟件開發(fā)管理兩個方面。在軟件開發(fā)技術(shù)中，它主要研究軟件開發(fā)方法、軟件開發(fā)過程、軟件開發(fā)工具和環(huán)境。在軟件開發(fā)管理中，它主要研究軟件管理學(xué)、軟件經(jīng)濟學(xué)和軟件心理學(xué)等。 5．軟件工程面臨的問題 軟件工程有許多需要解決的棘手問題，如軟件費用、軟件可靠性、軟件可維護性、軟件生產(chǎn)率和軟件重用等。

1)軟件費用 由于軟件生產(chǎn)基本上仍處于手工狀態(tài)，軟件是知識高度密集的技術(shù)的綜合產(chǎn)物，人力資源遠遠不能適應(yīng)這種迅速增長的軟件社會要求，因而軟件費用上升的勢頭必然還將繼續(xù)下去。

2)軟件可靠性 軟件可靠性是指軟件系統(tǒng)能否在既定的環(huán)境條件下運行并實現(xiàn)所期望的結(jié)果。在軟件開發(fā)中，通常要花費40%的代價進行測試和排錯，即使這樣還不能保證以后不再發(fā)生錯誤，為了提高軟件可靠性，就要付出足夠的代價。

3)軟件可維護性 統(tǒng)計數(shù)據(jù)表明，軟件的維護費用占整個軟件系統(tǒng)費用的2/3，而軟件開發(fā)費用只占1/3。軟件維護之所以有如此大的花費，是因為已經(jīng)運行的軟件還需排除隱含的錯誤，新增加的功能要加入進去，維護工作又是非常困難的，效率又是非常低下的。因此，如何提高軟件的可維護性，減少軟件維護的工作量，也是軟件工程面臨的主要問題之一。 4)軟件生產(chǎn)率 計算機的廣泛應(yīng)用使得軟件的需求量大幅度上升，而軟件的生產(chǎn)又處于手工開發(fā)的狀態(tài)，軟件生產(chǎn)率低下，使得各國都感到軟件開發(fā)人員不足。這種趨勢將仍舊繼續(xù)下去。所以，如何提高軟件生產(chǎn)率，是軟件工程又一重要問題。

5)軟件重用 提高軟件的重用性，對于提高軟件生產(chǎn)率、降低軟件成本有著重要意義。當前的軟件開發(fā)存在著大量的、重復(fù)的勞動，耗費了不少的人力資源。軟件的重用有各種級別，軟件規(guī)格說明、軟件模塊、軟件代碼、軟件文檔等都可以是軟件重用的單位。軟件重用是軟件工程中的一個重要研究課題，軟件重用的理論和技術(shù)至今尚未徹底解決。1.2軟件工程的過程和軟件生存周期 1.2.1軟件工程的過程 軟件工程的過程規(guī)定了獲取、供應(yīng)、開發(fā)、操作和維護軟件時，要實施的過程、活動和任務(wù)。其目的是為各種人員提供一個公共的框架，以便用相同的語言進行交流。 這個框架由幾個重要過程組成，這些主要過程含有用來獲取、供應(yīng)、開發(fā)、操作和維護軟件所用的基本的、一致的要求。該框架還用來控制和管理軟件的過程。各種組織和開發(fā)機構(gòu)可以根據(jù)具體情況進行選擇和剪裁，可在一個機構(gòu)的內(nèi)部或外部實施。

軟件工程的過程沒有規(guī)定一個特定的生存周期模型或軟件開發(fā)方法，各軟件開發(fā)機構(gòu)可為其開發(fā)項目選擇一種生存周期模型，并將軟件工程的過程所含的過程、活動和任務(wù)映射到該模型中，也可以選擇和使用軟件開發(fā)方法來執(zhí)行適合于其軟件項目的活動和任務(wù)。軟件工程過程包含以下7個過程：

(1)獲取過程。獲取過程是需方按合同獲取一個系統(tǒng)、軟件產(chǎn)品或服務(wù)的活動。

(2)供應(yīng)過程。供應(yīng)過程是供方向需方提供合同中的系統(tǒng)、軟件產(chǎn)品或服務(wù)所需的活動。 (3)開發(fā)過程。開發(fā)過程是開發(fā)者和機構(gòu)為了定義和開發(fā)軟件或服務(wù)所需的活動。此過程包括需求分析、設(shè)計、編碼、集成、測試、軟件安裝和驗收等活動。

(4)操作過程。操作過程是操作者和機構(gòu)為了在規(guī)定的運行環(huán)境中為其用戶運行一個計算機系統(tǒng)所需要的活動。

(5)維護過程。維護過程是維護者和機構(gòu)為了管理軟件的修改，使它處于良好運行狀態(tài)所需要的活動。

(6)管理過程。管理過程是軟件工程過程中的各項管理活動，包括項目開始和范圍定義；項目管理計劃；實施和控制；評審和評價；項目完成。

(7)支持過程。支持過程對項目的生存周期過程給予支持。它有助于項目的成功并能提高項目的質(zhì)量。 1.2.2軟件生存周期 軟件生存周期是借用工程中產(chǎn)品生存周期的概念而得來的。引入軟件生存周期概念，對于軟件生產(chǎn)的管理、進度控制有著非常重要的意義，可使軟件生產(chǎn)有相應(yīng)的模式、相應(yīng)的流程、相應(yīng)的工序和步驟。 軟件生存周期是指一個軟件從提出開發(fā)要求開始直到該軟件報廢為止的整個時期。把整個生存周期劃分為若干階段，使得每個階段有明確的任務(wù)，把規(guī)模大、結(jié)構(gòu)復(fù)雜和管理復(fù)雜的軟件開發(fā)變得容易控制和管理。

軟件生存周期的各階段有不同的劃分。軟件規(guī)模、種類、開發(fā)方式、開發(fā)環(huán)境以及開發(fā)使用的方法都影響軟件生存周期的劃分。在劃分軟件生存周期的階段時，應(yīng)遵循的基本原則是各階段的任務(wù)應(yīng)盡可能相對獨立，同一階段各項任務(wù)的性質(zhì)盡可能相同，從而降低每個階段任務(wù)的復(fù)雜程度，簡化不同階段之間的聯(lián)系，有利于軟件項目開發(fā)的組織管理。通常，軟件生存周期包括可行性分析和項目開發(fā)計劃、需求分析、概要設(shè)計、詳細設(shè)計、編碼、測試、維護等活動，可將這些活動以適當方式分配到不同階段去完成。

1．可行性分析和項目開發(fā)計劃 可行性分析和項目開發(fā)計劃階段必須要回答的問題是“要解決的問題是什么”。該問題有行得通的解決辦法嗎?若有解決問題的辦法，則需要多少費用?需要多少資源?需要多少時間?要回答這些問題，就要進行問題定義、可行性分析，制定項目開發(fā)計劃。 用戶提出一個軟件的開發(fā)要求后，系統(tǒng)分析員首先要解決該軟件項目的性質(zhì)是什么，是數(shù)據(jù)處理問題還是實時控制問題，是科學(xué)計算問題還是人工智能問題等。還要明確該項目的目標是什么，該項目的規(guī)模如何等。

通過系統(tǒng)分析員對用戶和使用部門負責(zé)人的訪問和調(diào)查、開會討論，就可解決這些問題。 在清楚了問題的性質(zhì)、目標、規(guī)模后，還要確定該問題有沒有行得通的解決辦法。系統(tǒng)分析員要進行壓縮和簡化的需求分析和設(shè)計，也就是在高層次上進行分析和設(shè)計，探索這個問題是否值得去解決，是否有可行的解決辦法。最后要提交可行性研究報告。

經(jīng)過可行性分析后，確定該問題值得去解決，然后制定項目開發(fā)計劃。根據(jù)開發(fā)項目的目標、功能、性能及規(guī)模，估計項目需要的資源，即需要的計算機硬件資源，需要的軟件開發(fā)工具和應(yīng)用軟件包，需要的開發(fā)人員數(shù)目及層次。還要對軟件開發(fā)費用做出估算，對開發(fā)進度做出估計，制定完成開發(fā)任務(wù)的實施計劃。最后，將項目開發(fā)計劃和可行性分析報告一起提交管理部門審查。

2．需求分析 需求分析階段的任務(wù)不是具體地解決問題，而是準確地確定“軟件系統(tǒng)必須做什么?”確定軟件系統(tǒng)必須具備哪些功能。 用戶了解他們所面對的問題，知道必須做什么，但是通常不能完整、準確地表達出來，也不知道怎樣用計算機解決他們的問題。而軟件開發(fā)人員雖然知道怎樣用軟件完成人們提出的各種功能要求，但是，對用戶的具體業(yè)務(wù)和需求不完全清楚，這是需求分析階段的困難所在。 系統(tǒng)分析員要和用戶密切配合，充分交流各自的想法，理解用戶的業(yè)務(wù)流程，完整、全面地收集、分析用戶業(yè)務(wù)中的信息和處理，從中分析出用戶要求的功能和性能，然后完整、準確地將它們表達出來。這一階段要給出軟件需求說明書。

3．概要設(shè)計 在概要設(shè)計階段，開發(fā)人員要把確定的各項功能需求轉(zhuǎn)換成需要的體系結(jié)構(gòu)，在該體系結(jié)構(gòu)中，每個成分都是意義明確的模塊，即每個模塊都和某些功能需求相對應(yīng)。因此，概要設(shè)計就是設(shè)計軟件的結(jié)構(gòu)，該結(jié)構(gòu)由哪些模塊組成，這些模塊的層次結(jié)構(gòu)是怎樣的，這些模塊的調(diào)用關(guān)系是怎樣的，每個模塊的功能是什么。同時還要設(shè)計該項目的應(yīng)用系統(tǒng)的總體數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)庫結(jié)構(gòu)，即應(yīng)用系統(tǒng)要存儲什么數(shù)據(jù)，這些數(shù)據(jù)是什么樣的結(jié)構(gòu)，它們之間有什么關(guān)系等。

4．詳細設(shè)計 詳細設(shè)計階段就是為每個模塊完整的功能進行具體描述，把功能描述轉(zhuǎn)變?yōu)榫_的、結(jié)構(gòu)化的過程描述。即該模塊的控制結(jié)構(gòu)是怎樣的，先做什么，后做什么，有什么樣的條件判定，有些什么重復(fù)處理等，并用相應(yīng)的表示工具把這些控制結(jié)構(gòu)表示出來。

5．編碼 編碼階段就是把每個模塊的控制結(jié)構(gòu)轉(zhuǎn)換成計算機可接受的程序代碼，即寫成以某特定程序設(shè)計語言表示的“源程序清單”。當然，寫出的程序應(yīng)結(jié)構(gòu)好，清晰易讀，并且與設(shè)計相一致。 6．測試 測試是保證軟件質(zhì)量的重要手段，其主要方式是在設(shè)計測試用例的基礎(chǔ)上檢驗軟件的各個組成部分。測試分為模塊測試、組裝測試、確認測試。模塊測試是查找各模塊在功能和結(jié)構(gòu)上存在的問題。組裝測試是將各模塊按一定順序組裝起來進行的測試，主要是查找各模塊之間接口上存在的問題。確認測試是按軟件需求說明書上的功能逐項進行的，發(fā)現(xiàn)不滿足用戶需求的問題，決定開發(fā)的軟件是否合格、能否交付用戶使用等。

7．維護 軟件維護是軟件生存周期中時間最長的階段。已交付的軟件投入正式使用后，便進入軟件維護階段，它可以持續(xù)幾年甚至幾十年。軟件運行過程中可能由于各方面的原因，需要對它進行修改。其原因可能是運行中發(fā)現(xiàn)了軟件隱含的錯誤而需要修改；也可能是為了適應(yīng)變化了的軟件工作環(huán)境而需要做適當變更；也可能是因為用戶業(yè)務(wù)發(fā)生變化而需要擴充和增強軟件的功能等。 以上劃分的7個階段是在GB8567中規(guī)定的。在大部分文獻中將生存周期劃分為5個階段，即要求定義、設(shè)計、編碼、測試及維護。其中，要求定義階段包括可行性研究和項目開發(fā)計劃、需求分析，設(shè)計階段包括概要設(shè)計和詳細設(shè)計。1.3軟件生存周期模型 1.3.1軟件生存周期模型的概念 模型是為了理解事物而對事物做出的一種抽象，它忽略了不必要的細節(jié)，是事物的一種抽象形式、一個規(guī)劃、一個程式。 軟件生存周期模型是描述軟件開發(fā)過程中各種活動如何執(zhí)行的模型。

一個強有力的軟件生存周期模型對軟件開發(fā)提供了強有力的支持，為軟件開發(fā)過程中所有活動提供了統(tǒng)一的政策保證，為參與軟件開發(fā)的所有成員提供幫助和指導(dǎo)。它揭示了如何演繹軟件過程的思想，是軟件生存周期模型化技術(shù)的基礎(chǔ)，也是建立軟件開發(fā)環(huán)境的核心。 軟件生存周期模型確立了軟件開發(fā)和演繹中各階段的次序限制以及各階段活動的準則，確立開發(fā)過程所遵守的規(guī)定和限制，便于各種活動的協(xié)調(diào)以及各種人員的有效通信，有利于活動重用和活動管理。

軟件生存周期模型能表示各種活動的實際工作方式，各種活動間的同步和制約關(guān)系，以及活動的動態(tài)特性。生存周期模型應(yīng)該被軟件開發(fā)過程中的各類人員所理解，它應(yīng)該適應(yīng)不同的軟件項目，具有較強的靈活性，以及支持軟件開發(fā)環(huán)境的建立。 目前有若干種軟件生存周期模型，如瀑布模型、增量模型、螺旋模型、噴泉模型、變換模型、基于知識的模型和統(tǒng)一過程模型等。

1.3.2瀑布模型 瀑布模型是將軟件生存周期各活動規(guī)定為依線性順序聯(lián)接的若干階段的模型。它包括可行性分析、項目開發(fā)計劃、需求分析、概要設(shè)計、詳細設(shè)計、編碼、測試和維護。它規(guī)定了由前至后、相互銜接的固定次序，如同瀑布流水，逐級下落。 1．模型表示 瀑布模型如圖1.1所示。該模型說明整個軟件開發(fā)過程是按圖中5個階段進行的。每個階段的任務(wù)完成之后，產(chǎn)生右邊相應(yīng)的文檔(圖中只列出該階段最主要的文檔)，這些文檔經(jīng)過確認，表明該階段工作完成，并進入下一階段的工作。每個階段均以上一個階段的文檔作為開發(fā)的基礎(chǔ)，如果某一文檔出現(xiàn)問題，則要返回到上一個階段去重新進行工作。圖1.1瀑布模型 2．瀑布模型的特點 瀑布模型嚴格按照生存周期各個階段的目標、任務(wù)、文檔和要求來進行開發(fā)。它強調(diào)了每一階段的嚴格性，尤其是開發(fā)前期的良好需求說明，這樣，就能解決在開發(fā)階段后期修正不完善的需求說明將花費巨大的費用的問題。于是人們需付出很大的努力來加強各階段活動的嚴格性，特別是要求定義階段，希望得到完整、準確、無二義性的需求說明，以減少后面各階段不易估量的浪費。在傳統(tǒng)的觀念中，人們認為只要認真努力，總可以通過詳盡分析來確定完整、準確的需求說明，從而明確系統(tǒng)的各種需求，只要采用一套嚴格規(guī)定的術(shù)語及表達方式，就一定可以準確清楚地表達和通訊，以便在嚴格的開發(fā)管理下得到完美的結(jié)果。

在這種嚴格定義的模型中，開發(fā)人員試圖在每一活動過程結(jié)束后，通過嚴格的階段性復(fù)審與確認，得到該階段的一致、完整、準確和無二義性的良好文檔，以“凍結(jié)”這些文檔為該階段結(jié)束的標志，保持不變，作為下一階段活動的唯一基礎(chǔ)，從而形成一個理想的線性開發(fā)序列，以每一步的正確性和完整性來保證最終系統(tǒng)的質(zhì)量。 瀑布模型是以文檔形式驅(qū)動的，為合同雙方最終確認的產(chǎn)品規(guī)定了藍本，為管理者進行項目開發(fā)管理提供了基礎(chǔ)，為開發(fā)過程施加了“政策”或紀律限制，約束了開發(fā)過程中的活動。 瀑布模型以里程碑開發(fā)原則為基礎(chǔ)，提供各階段的檢查點，確保用戶需求，滿足預(yù)算和時間限制。

瀑布模型是一種整體開發(fā)模型，在開發(fā)過程中，用戶看不見系統(tǒng)是什么樣，只有開發(fā)完成，向用戶提交整個系統(tǒng)時，用戶就能看到一個完整的系統(tǒng)。 瀑布模型適合于功能和性能明確、完整、無重大變化的軟件開發(fā)。大部分的系統(tǒng)軟件就具有這些特征，例如編譯系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)和操作系統(tǒng)等。在開發(fā)前均可完整、準確、一致和無二義性地定義其目標、功能和性能等。 3．瀑布模型的局限性 對于當前的大型軟件項目，特別是應(yīng)用軟件項目，在開發(fā)前期用戶常常對系統(tǒng)只有一個模糊的想法，很難確定和表達對系統(tǒng)的全面要求。經(jīng)過詳細的要求定義，盡管可得到一份較好的需求說明，但卻很難期望該需求說明能將系統(tǒng)的一切都描述得完整、準確、一致并與實際環(huán)境相符，很難在邏輯上推斷出系統(tǒng)的運行效果，并以此達到各類人員對系統(tǒng)的共同理解。因此，要保證每個階段特別是定義階段是正確的、完整的。這是屬于理想情況，實際上是做不到或很難做到的。

由于知識背景的不同，工作中的疏漏和通訊媒介的局限性，使通訊中的誤解無法避免；隨著項目向前推進，用戶會產(chǎn)生新的要求，或因環(huán)境變化希望系統(tǒng)也能隨之變化。開發(fā)者也可能在設(shè)計中遇到某些未曾預(yù)料的實際困難，希望在需求中有所權(quán)衡。這些都成為進行嚴格線性開發(fā)的重大障礙，盡管通過加強復(fù)審與確認、全面測試和設(shè)立維護階段來緩解上述困難，但均未在根本上解決這些問題。 作為整體開發(fā)的瀑布模型，由于不支持軟件產(chǎn)品的演化，對開發(fā)過程中的一些很難發(fā)現(xiàn)的錯誤只有在最終產(chǎn)品運行時才能發(fā)現(xiàn)。瀑布模型缺乏對付變化的機制，因而最終產(chǎn)品將難以維護。

20多年來瀑布模型得到了廣泛的應(yīng)用。它在消除非結(jié)構(gòu)化軟件、降低軟件的復(fù)雜性、促進軟件開發(fā)工程化方面起了很大作用。但是，瀑布模型在大量的軟件開發(fā)實踐中也逐漸暴露出它的嚴重缺點。它是一種理想的線性開發(fā)模式，缺乏靈活性，特別是無法解決軟件需求不明確或不準確的問題。這些缺點給軟件開發(fā)帶來了嚴重影響，最終可能導(dǎo)致開發(fā)出的軟件并不是用戶真正需要的軟件，并且這一點在開發(fā)過程完成后才能發(fā)現(xiàn)，已為時太晚。針對這些情況，無疑需要進行返工，或者在運行中進行大量修改。不管是返工或進行大量修改都必須付出巨大的代價，給軟件開發(fā)帶來不必要的損失。同時，隨著軟件開發(fā)項目的規(guī)模日益擴大，瀑布模型缺乏靈活性的缺點引發(fā)的問題更為嚴重。

為克服瀑布模型的不足，現(xiàn)在已提出若干其他模型。 瀑布模型各階段的任務(wù)、內(nèi)容、方法、技術(shù)和文檔見第2～6章。

1.3.3增量模型 瀑布模型是一種整體開發(fā)模型。在開發(fā)過程中，用戶看不到軟件是什么樣子，只有開發(fā)完成后，整個軟件才會全部展現(xiàn)在用戶面前。這時如果用戶發(fā)現(xiàn)有不滿意的地方，為時已晚。

增量模型是一種非整體開發(fā)的模型。軟件在該模型中是“逐漸”開發(fā)出來的，開發(fā)出一部分，向用戶展示一部分，可讓用戶及早看到部分軟件，及早發(fā)現(xiàn)問題?；蛘呦乳_發(fā)一個“原型”軟件，完成部分主要功能，展示給用戶并征求意見，然后逐步完善，最終獲得滿意的軟件產(chǎn)品。該模型具有較大的靈活性，適合于軟件需求不明確、設(shè)計方案有一定風(fēng)險的軟件項目。增量模型的詳細介紹見第7章。 1.3.4螺旋模型 對于復(fù)雜的大型軟件，開發(fā)一個原型往往達不到要求。螺旋模型將瀑布模型與增量模型結(jié)合起來，加入了兩種模型均忽略了的風(fēng)險分析，彌補了這兩種模型的不足。 螺旋模型是一種風(fēng)險驅(qū)動的模型。在軟件開發(fā)中，有各種各樣的風(fēng)險。對于不同的軟件項目，其開發(fā)風(fēng)險有大有小。在制定項目開發(fā)計劃時，分析員要明確項目的需求是什么，需要多少資源，如何安排開發(fā)進度等一系列問題。但是，要給出準確無誤的回答是不容易的。分析員通?？蓱{借經(jīng)驗給出初步的設(shè)想，這難免會帶來一定的風(fēng)險。

同樣，在設(shè)計階段，給出的設(shè)計方案是否能實現(xiàn)用戶的功能，也會具有一定風(fēng)險。實踐表明，項目越復(fù)雜，設(shè)計方案、資源、成本和進度等因素的不確定性越大，項目開發(fā)的風(fēng)險也越大。因此，應(yīng)及時對風(fēng)險進行識別、分析和采取對策，從而消除或減少風(fēng)險的危害。 螺旋模型將開發(fā)過程分為幾個螺旋周期，每個螺旋周期大致和瀑布模型相符合。每個螺旋周期可分為4個步驟：第一，制定計劃，即確定目標，選定實施方案，明確開發(fā)限制條件；第二，風(fēng)險分析，即分析所選方案，識別風(fēng)險，通過原型消除風(fēng)險；第三，開發(fā)實施，即實施軟件開發(fā)；第四，用戶評估，即評價開發(fā)工作，提出修改意見，建立下一個周期的計劃。

螺旋模型適合于大型軟件的開發(fā)，它吸收了軟件工程“演化”的概念，使得開發(fā)人員和用戶對每個螺旋周期出現(xiàn)的風(fēng)險都有所了解，從而做出相應(yīng)的反應(yīng)。但是，使用該模型需要有相當豐富的風(fēng)險評估經(jīng)驗和專門知識，這使該模型的應(yīng)用受到一定限制。 螺旋模型的表示如圖1.2所示。

在圖1.2中，半徑的大小代表了完成現(xiàn)在步驟所需的費用累加。螺旋角度的大小代表了完成螺旋的每次循環(huán)需做的工作，模型反映了一個重要的概念，即每一次循環(huán)包含一次進展，該進展對產(chǎn)品的每一部分及每一級改進指出了從用戶需求文檔至每一單獨程序的編程步驟的相同次序。圖1.2螺旋模型 1．螺旋周期

1)用戶概念 這一周期是用戶概念級的需求，也是粗線條的、概要的需求和未經(jīng)開發(fā)者進行分析的需求。

2)軟件需求 這一周期定義不確定因素。這些不確定因素是項目風(fēng)險的重要來源。若是如此，則要制定風(fēng)險的費用效率策略。這可能涉及快速原型及其他方法的結(jié)合，一旦涉及不確定因素風(fēng)險被評估，下一步工作將由遺留的有關(guān)風(fēng)險來確定。 3)軟件設(shè)計 這一周期以性能和用戶接口風(fēng)險為主，采用演化開發(fā)技術(shù)，即采用原型化模型來解決風(fēng)險。若這個原型是可運行的、健壯的，則可作為下一步產(chǎn)品演化的基礎(chǔ)，那么緊接著的風(fēng)險驅(qū)動就是一系列的原型演化，這就使得項目只完成螺旋模型所有可能步驟的一個子集。

4)軟件實現(xiàn) 這一周期以程序開發(fā)或接口控制風(fēng)險占主導(dǎo)地位，下面將遵循基本的瀑布模型進行開發(fā)。 2．螺旋周期的步驟

1)確定目標、方案和限制條件 確定軟件產(chǎn)品各部分的目標，如性能、功能和適應(yīng)變化的能力等； 確定軟件產(chǎn)品各部分實現(xiàn)的各種方案，選擇如A設(shè)計、B設(shè)計、軟件重用和購買等； 確定不同方案的限制條件，如成本、規(guī)模、接口調(diào)度、資源分配和時間表安排等。 2)評估方案、標識風(fēng)險和解決風(fēng)險 對各個不同實現(xiàn)方案進行評估，對出現(xiàn)的不確定因素進行風(fēng)險分析，提出解決風(fēng)險的策略，建立相應(yīng)的原型。若原型是可運行的、健壯的，則可作為下一步產(chǎn)品演化的基礎(chǔ)。 螺旋模型的風(fēng)險驅(qū)動中，解決風(fēng)險可采用面向說明書、面向原型、面向模擬法和面向自動轉(zhuǎn)換的方法。在這種情況下，通過相應(yīng)的程序風(fēng)險大小及不同方法效率的分析來選擇合適的配合策略。類似地，風(fēng)險管理分析能決定投入其余工程活動的時間和工作量，如計劃、輪廓管理、質(zhì)量保證、正式確認和測試等。 3)開發(fā)確認產(chǎn)品 若以前的原型已解決了所有性能和用戶接口風(fēng)險，而且占主要位置的是程序開發(fā)和接口控制風(fēng)險，那么接下來應(yīng)采用瀑布模型的方法，進行用戶需求、軟件需求、軟件設(shè)計和軟件實現(xiàn)等階段。同時要對其做適當修改，以適應(yīng)增量開發(fā)。也就是說，可以選擇原型、模擬原型，這樣就導(dǎo)致了不同的步驟。

4)計劃下一周期工作 對下一周期的軟件需求、軟件設(shè)計和軟件實現(xiàn)進行計劃；對部分產(chǎn)品進行增量開發(fā)；或者是由部分組織和個人來開發(fā)軟件的各個部分?？稍O(shè)想有一系列平行的螺旋循環(huán)，每一個螺旋循環(huán)對應(yīng)一個組成部分，好像在圖中加入第三維，即加若干重疊的螺旋平面，不同的螺旋平面對應(yīng)于不同的軟件組成部分，以便分別演化。 與其他模型相似，在螺旋模型中，每次循環(huán)都以評審結(jié)束，評審涉及產(chǎn)品的原來人員或組織，評審覆蓋前次循環(huán)中開發(fā)的全部產(chǎn)品，包括下一次循環(huán)的計劃以及實現(xiàn)它們的資源。評審的主要任務(wù)是確保將所有的有關(guān)部分共同提交給下一階段。 1.3.5噴泉模型 噴泉模型是一種以用戶需求為動力，以對象作為驅(qū)動的模型。它適合于面向?qū)ο蟮拈_發(fā)方法。它克服了瀑布模型不支持軟件重用和多項開發(fā)活動集成的局限性。噴泉模型使開發(fā)過程具有迭代性和無間隙性。系統(tǒng)某些部分常常重復(fù)工作多次，相關(guān)功能在每次迭代中隨之加入演化的系統(tǒng)。無間隙是指在分析、設(shè)計和實現(xiàn)等開發(fā)活動之間不存在明顯的邊界。 噴泉模型如圖1.3所示。它以面向?qū)ο蟮能浖_發(fā)方法為基礎(chǔ)，以用戶需求作為噴泉模型的源泉。圖1.3噴泉模型

噴泉模型的特點如下：

(1)噴泉模型規(guī)定軟件開發(fā)過程有4個階段，即分析、系統(tǒng)設(shè)計、軟件設(shè)計和實現(xiàn)。

(2)噴泉模型的各階段相互重疊，它反映了軟件過程并行性的特點。

(3)噴泉模型以分析為基礎(chǔ)，資源消耗呈塔型，在分析階段消耗的資源最多。

(4)噴泉模型反映了軟件過程迭代的自然特性，從高層返回低層無資源消耗。

(5)噴泉模型強調(diào)增量開發(fā)，它依據(jù)分析一點，設(shè)計一點的原則，并不要求一個階段的徹底完成，整個過程是一個迭代的逐步提煉的過程。

(6)噴泉模型是對象驅(qū)動的過程，對象是所有活動作用的實體，也是項目管理的基本內(nèi)容。

(7)噴泉模型在實現(xiàn)時，由于活動不同，可分為系統(tǒng)實現(xiàn)和對象實現(xiàn)，這既反映了全系統(tǒng)的開發(fā)過程，也反映了對象族的開發(fā)和重用過程。 1.3.6基于知識的模型 基于知識的模型又稱智能模型，它把瀑布模型和專家系統(tǒng)結(jié)合在一起。該模型在開發(fā)的各個階段上都利用了相應(yīng)的專家系統(tǒng)來幫助軟件人員完成開發(fā)工作，使維護在系統(tǒng)需求說明一級上進行。為此，建立了各階段所需要的知識庫，將模型、相應(yīng)領(lǐng)域知識和軟件工程知識分別存入數(shù)據(jù)庫，以軟件工程知識為基礎(chǔ)的生成規(guī)則構(gòu)成的專家系統(tǒng)與含有應(yīng)用領(lǐng)域知識規(guī)則的其他專家系統(tǒng)相結(jié)合，構(gòu)成了該應(yīng)用領(lǐng)域的開發(fā)系統(tǒng)。

1．模型表示 基于知識模型的表示如圖1.4所示。該模型基于瀑布模型，在各階段都有相應(yīng)的專家系統(tǒng)支持。圖1.4基于知識的模型 1)支持需求活動的專家系統(tǒng) 支持需求活動的專家系統(tǒng)用來幫助減少需求活動中的二義性、不精確性和沖突易變的需求，這種專家系統(tǒng)要使用應(yīng)用領(lǐng)域的知識，要用到應(yīng)用系統(tǒng)中的規(guī)則，建立應(yīng)用領(lǐng)域的專家系統(tǒng)來支持需求活動。

2)支持設(shè)計活動的專家系統(tǒng) 支持設(shè)計活動的專家系統(tǒng)用于支持設(shè)計功能的CASE中的工具和文檔的選擇，這種專家系統(tǒng)要使用軟件開發(fā)的知識。 3)支持測試活動的專家系統(tǒng) 支持測試活動的專家系統(tǒng)用于支持測試自動化，利用基于知識的系統(tǒng)選擇測試工具，生成測試數(shù)據(jù)，跟蹤測試過程，分析測試結(jié)果。

4)支持維護活動的專家系統(tǒng) 支持維護活動的專家系統(tǒng)將維護新的應(yīng)用開發(fā)過程的重復(fù)，運行可利用的基于知識的系統(tǒng)來進行維護。

2．特點 知識模型以瀑布模型與專家系統(tǒng)的綜合應(yīng)用為基礎(chǔ)。該模型通過應(yīng)用系統(tǒng)的知識和規(guī)則幫助設(shè)計者認識一個特定的軟件的需求和設(shè)計，這些專家系統(tǒng)已成為開發(fā)過程的伙伴，并指導(dǎo)開發(fā)過程。

將軟件工程知識從特定領(lǐng)域分離出來，這些知識隨著過程范例收入知識庫，產(chǎn)生規(guī)則，在接受軟件工程技術(shù)的基礎(chǔ)上被編碼成專家系統(tǒng)，用來輔助軟件工程的開發(fā)。 在使用過程中，軟件工程專家系統(tǒng)與其他領(lǐng)域的應(yīng)用知識的專家系統(tǒng)連接起來，形成了特定的軟件系統(tǒng)，為開發(fā)一個軟件產(chǎn)品所應(yīng)用。

3．優(yōu)點 知識模型的優(yōu)點如下：

(1)通過領(lǐng)域的專家系統(tǒng)，可使需求說明更完整、準確和無二義性。 (2)通過軟件工程專家系統(tǒng)，提供一個設(shè)計庫支持，在開發(fā)過程中成為設(shè)計者的助手。

(3)通過軟件工程知識和特定應(yīng)用領(lǐng)域的知識和規(guī)則的應(yīng)用來提供開發(fā)的幫助。

4．缺點 知識模型的缺點如下：

(1)建立適合于軟件設(shè)計的專家系統(tǒng)是非常困難的，超出了目前的能力，是今后軟件工程的發(fā)展方向，要經(jīng)過相當長的時間才能取得進展。 (2)建立一個既適合軟件工程又適合應(yīng)用領(lǐng)域的知識庫也是非常困難的。

(3)目前的狀況是在軟件開發(fā)中正在應(yīng)用AI技術(shù)，在CASE工具系統(tǒng)中使用專家系統(tǒng)，用專家系統(tǒng)來實現(xiàn)測試自動化，在軟件開發(fā)的局部階段有所進展。

1.3.7變換模型 變換模型是一種適合于形式化開發(fā)方法的模型。從軟件需求形式化說明開始，經(jīng)過一系列變換，最終得到系統(tǒng)的目標程序。

變換模型主要用于軟件的形式化開發(fā)方法，一個形式化的軟件開發(fā)方法要提供一套思維方法和描述開發(fā)手段，如規(guī)范描述的原則、程序開發(fā)的一般過程、描述語言等，使開發(fā)者能利用數(shù)學(xué)概念和表示方法恰當合理地構(gòu)造形式規(guī)范，根據(jù)開發(fā)過程的框架及設(shè)計原則進行規(guī)范描述和系統(tǒng)化的設(shè)計，并對規(guī)范的性質(zhì)和設(shè)計的步驟進行分析的驗證。

1．模型表示 變換模型的表示如圖1.5所示。用于軟件形式化開發(fā)方法的變換模型分為模型規(guī)范的建立和規(guī)范到實現(xiàn)開發(fā)的一系列變換過程。圖1.5變換模型

2．開發(fā)過程

1)建立軟件系統(tǒng)的模型規(guī)范 將對實現(xiàn)環(huán)境和系統(tǒng)的功能需求進行分析，抽象出與系統(tǒng)有關(guān)的基本概念和固有屬性，并以此為基礎(chǔ)建立問題求解的抽象模型，稱為模型抽象。它由相互關(guān)聯(lián)的兩部分組成，即表示抽象和運算抽象。

2)表示抽象 表示抽象是模型規(guī)范構(gòu)造者在分析求解問題及其實現(xiàn)環(huán)境的基礎(chǔ)上，對形成系統(tǒng)可觀察屬性的對象域及其組成元素的形式描述。這種描述來源于對現(xiàn)實世界中求解問題及其環(huán)境的分析，與如何實現(xiàn)所描述的對象無關(guān)，需要恰當?shù)胤从乘鼈兣c求解問題相關(guān)的固有性質(zhì)。 3)運算抽象 運算抽象是定義若干運算來模擬系統(tǒng)中可能發(fā)生的事件，即圍繞表示抽象給出若干運算的規(guī)范描述。這種描述規(guī)定了運算所模擬的事件發(fā)生前后系統(tǒng)可觀察屬性的變化關(guān)系，即狀態(tài)轉(zhuǎn)換關(guān)系。

4)變換過程 當軟件系統(tǒng)模型規(guī)范的構(gòu)造完成之后，進一步開發(fā)滿足規(guī)范的實現(xiàn)系統(tǒng)。程序開發(fā)過程應(yīng)是設(shè)計和驗證并行的多步精化過程，對開發(fā)的每一步，均要慎重考慮該步開發(fā)是否正確，發(fā)現(xiàn)問題及時解決。只有這樣才能大大減少開發(fā)費用，保證最終產(chǎn)品的質(zhì)量和開發(fā)效率。

從抽象模型規(guī)范(M0)開始的理想多步開發(fā)過程可表示為M0→M1→M2→…→Mn的變換，其中，Mi+1是Mi的實現(xiàn)模型，變換中的每一步的“強度”都影響到整個變換的強度，還要論證每個Mi+1是Mi的正確實現(xiàn)。這種開發(fā)過程中的證明推理是以諸模型的形式化為前提的，也是保證最終的實現(xiàn)系統(tǒng)(Mn)正確實現(xiàn)模型規(guī)范的必要階段。

5)變換的獨立性 這種多步變換過程的一個重要性質(zhì)是每步變換對相關(guān)模型描述為“封閉的”，即每步變換的正確性僅與該步變換所依據(jù)的規(guī)范Mi以及對變換后的假設(shè)(如Mi+1)有關(guān)，變換步驟在這種意義下獨立于其他變換步驟。假若沒有這種獨立性，就無法控制錯誤的惡性蔓延，而變換步驟的經(jīng)驗也就是一句空話。 6)變換的設(shè)計 變換的設(shè)計過程是一種“發(fā)明”的過程。在模型具體化的變換過程中，具體實現(xiàn)模型的設(shè)計是開發(fā)者的職責(zé)。目前還沒有相當高級的規(guī)范能自動翻譯成高效程序代碼的工具，這種設(shè)計“發(fā)明”，是以開發(fā)者自己對正在設(shè)計中的系統(tǒng)的功能和使用環(huán)境的理解，是以實現(xiàn)效率及進一步開發(fā)的預(yù)測等程序設(shè)計經(jīng)驗以及對軟件開發(fā)基本原則的理解為基礎(chǔ)的。形式化開發(fā)方法僅提供給開發(fā)者一種嚴格有效的思維工具和描述工具，而不能代替開發(fā)者進行變換的“發(fā)明”。 3．特點 變換模型的特點如下：

(1)該模型只適合于軟件的形式化開發(fā)方法。

(2)必須有嚴格的數(shù)學(xué)理論和形式化技術(shù)支持。

(3)缺乏相應(yīng)的支持工具，處于手工處理方式。

(4)尚處于研究和實驗階段，距離實用前景尚有一段距離。

(5)對軟件開發(fā)人員要求較高。 1.3.8統(tǒng)一過程 統(tǒng)一過程是基于統(tǒng)一建模語言的軟件開發(fā)過程，它是用例驅(qū)動和風(fēng)險驅(qū)動的、以構(gòu)架為中心的、采用迭代和增量的軟件開發(fā)過程。該過程包括若干循環(huán)周期，每個循環(huán)周期包括四個階段：初始階段、細化階段、構(gòu)造階段和移交階段，每個階段包含若干次迭代，每次迭代又要執(zhí)行五種工作流：需求捕獲、分析、設(shè)計、實現(xiàn)和測試。

用例驅(qū)動意味著開發(fā)過程首先捕獲用例，然后在此基礎(chǔ)上進行分析、設(shè)計、實現(xiàn)和測試工作。風(fēng)險驅(qū)動意味著每個新發(fā)布版本都集中于解決或減少對項目成功影響最大的風(fēng)險。以構(gòu)架為中心意味著將系統(tǒng)的構(gòu)架用作構(gòu)思、構(gòu)造、管理和改善該系統(tǒng)的主要制品。迭代和增量開發(fā)意味著按專門的迭代計劃和評估標準產(chǎn)生一個內(nèi)部或外部版本所進行的一組明確的活動，而增量是系統(tǒng)中一個較小的、可管理的部分，指兩次構(gòu)造之間的差異，每次迭代至少產(chǎn)生一個新的構(gòu)造塊，從而向系統(tǒng)增加一個增量。

統(tǒng)一過程是經(jīng)過30多年的發(fā)展而形成的，它是吸收了各種生存周期模型的先進思想和豐富的實踐經(jīng)驗而產(chǎn)生的。它用于面向?qū)ο蟮拈_發(fā)方法，用統(tǒng)一建模語言來描述軟件系統(tǒng)的靜態(tài)結(jié)構(gòu)和動態(tài)行為。它把一個項目劃分為若干細小的項目，每個細小項目的開發(fā)就是一個小瀑布模型。整個系統(tǒng)是按增量方式逐漸積累出來的，這種積累是經(jīng)過迭代過程實現(xiàn)的。統(tǒng)一過程將成為軟件開發(fā)的主流過程。 統(tǒng)一過程的詳細介紹見第13章。1.4軟件開發(fā)方法 1.4.1結(jié)構(gòu)化方法 結(jié)構(gòu)化方法由結(jié)構(gòu)化分析、結(jié)構(gòu)化設(shè)計和結(jié)構(gòu)化程序設(shè)計構(gòu)成。它是一種面向數(shù)據(jù)流的開發(fā)方法。該方法簡單實用，應(yīng)用較廣，技術(shù)成熟。

所謂結(jié)構(gòu)化分析，就是根據(jù)分解與抽象的原則，按照系統(tǒng)中數(shù)據(jù)處理的流程，用數(shù)據(jù)流圖來建立系統(tǒng)的功能模型，從而完成需求分析。所謂結(jié)構(gòu)化設(shè)計，就是根據(jù)模塊獨立性準則、軟件結(jié)構(gòu)準則，將數(shù)據(jù)流圖轉(zhuǎn)換為軟件的體系結(jié)構(gòu)，用軟件結(jié)構(gòu)圖來建立系統(tǒng)的物理模型，實現(xiàn)系統(tǒng)的概要設(shè)計。所謂結(jié)構(gòu)化程序設(shè)計，就是根據(jù)結(jié)構(gòu)程序設(shè)計原理，將每個模塊的功能用相應(yīng)的標準控制結(jié)構(gòu)表示出來，從而實現(xiàn)詳細設(shè)計。

結(jié)構(gòu)化方法總的指導(dǎo)思想是自頂向下、逐步求精。它的基本原則是功能的分析與抽象。它是軟件工程中最早出現(xiàn)的開發(fā)方法，特別適合于數(shù)據(jù)處理領(lǐng)域的問題。相應(yīng)的支持工具較多，發(fā)展較為成熟。 結(jié)構(gòu)化方法對于規(guī)模大的項目及特別復(fù)雜的項目不太適應(yīng)，該方法難于解決軟件重用問題，難于適應(yīng)需求變化的問題，難于徹底解決維護問題。 結(jié)構(gòu)化方法的詳細介紹見第8章。 1.4.2Jackson方法 這是一種面向數(shù)據(jù)結(jié)構(gòu)的開發(fā)方法。因為一個問題的數(shù)據(jù)結(jié)構(gòu)與處理該問題數(shù)據(jù)結(jié)構(gòu)的控制結(jié)構(gòu)有著驚人的相似之處，該方法就是根據(jù)這一思想形成了最初的JSP(JacksonStructureProgramming)方法。該方法首先描述問題的輸入、輸出數(shù)據(jù)結(jié)構(gòu)，分析其對應(yīng)性，然后推出相應(yīng)的程序結(jié)構(gòu)，從而給出問題的軟件過程描述。

JSP方法是以數(shù)據(jù)結(jié)構(gòu)為驅(qū)動的，適合于小規(guī)模的項目。當輸入數(shù)據(jù)結(jié)構(gòu)與輸出數(shù)據(jù)結(jié)構(gòu)無對應(yīng)關(guān)系時，難于應(yīng)用該方法?；贘SP方法的局限性，又發(fā)展了JSD(JacksonSystemDevelopment)方法，它是JSP方法的擴充。 JSD方法是一個完整的系統(tǒng)開發(fā)方法。該方法首先建立現(xiàn)實世界的模型，再確定系統(tǒng)的功能需求，對需求的描述特別強調(diào)了操作之間的時序性，它以事件作為驅(qū)動，是一種基于進程的開發(fā)方法，應(yīng)用于時序特點較強的系統(tǒng)，包括數(shù)據(jù)處理系統(tǒng)和一些實時控制系統(tǒng)。

JSD方法對客觀世界及其同軟件之間的關(guān)系認識不完整，所確立的軟件系統(tǒng)實現(xiàn)結(jié)構(gòu)過于復(fù)雜，軟件結(jié)構(gòu)說明的描述采用第三代語言，這不利于軟件開發(fā)者對系統(tǒng)的理解及開發(fā)者之間的通信交流，這些缺陷在很大程度上限制了人們實際運用JSD方法的熱情。 1.4.3維也納開發(fā)方法(VDM)

維也納開發(fā)方法(即VDM)，自20世紀70年代初提出以來，已形成一種對大型系統(tǒng)軟件形式化開發(fā)的較有潛力的方法，在歐洲及北美有相當大的影響，到20世紀80年代已將它應(yīng)用到工程開發(fā)上。VDM是在1969年為開發(fā)PL/1語言時，由IBM公司維也納實驗室的研究小組提出的，當時成員有HansBekic,PeterLucas,DinesBjφrner,CliffB.Jones和W.Henhapl等。當時遇到的問題是如何對大型高級語言盡快用形式化說明來開發(fā)編譯系統(tǒng)，使語法、語義的定義更嚴密、更系統(tǒng)化。從軟件系統(tǒng)最高一級抽象到最終目標代碼生成，每一步都給出形式化說明。 VDM是一種形式化的開發(fā)方法，軟件的需求用嚴格的形式語言描述，把描述模型逐步變換成目標系統(tǒng)。VDM方法是從VDL的基礎(chǔ)上擴充而來的，VDL是在牛津大學(xué)的指稱語義概念基礎(chǔ)上應(yīng)用于編譯而形成的操作語義方法。而VDM是在這基礎(chǔ)上考慮更面向工程而形成的指稱語義方法，當時用它來形式定義PL/1的一個真子集。

VDM是一個基于模型的方法，它的主要思想是：將軟件系統(tǒng)當作模型來給予描述，具體說就是把軟件的輸入/輸出看作模型對象，而這些對象在計算機中的狀態(tài)可看作為該模型在對象上的操作。 VDM從抽象說明開始，對軟件系統(tǒng)功能條件給出定義，對其輸入/輸出用不同的數(shù)學(xué)域進行分類定義，這稱為語法域說明。具體說明對象的真正含義，稱為語義域說明。 對系統(tǒng)在計算機內(nèi)的狀態(tài)進行描述，稱為加工函數(shù)(或語義函數(shù))。前面的語義域和語法域都是用數(shù)學(xué)的域方程表示的，而加工函數(shù)是用數(shù)學(xué)函數(shù)形式表示的，所以VDM的軟件系統(tǒng)模型是代數(shù)式的說明。

VDM的每步開發(fā)借助于其強有力的描述工具語言Meta-IV。VDM方法到20世紀70年代末得到進一步的鞏固，開始在歐洲廣泛應(yīng)用，先是應(yīng)用于開發(fā)程序語言的語義形式說明，以后變成一般軟件的開發(fā)方法。這方面主要貢獻是C.BJones和D.Bjφrner，他們開辟了許多新領(lǐng)域的應(yīng)用。丹麥有一個專門研究VDM的信息中心，該中心研制了許多支撐VDM的工具，開發(fā)并發(fā)通信進程，并用VDM實現(xiàn)了對Ada語言的整個開發(fā)過程的描述。 1.4.4面向?qū)ο蟮拈_發(fā)方法 面向?qū)ο箝_發(fā)方法的基本出發(fā)點是盡可能按照人類認識世界的方法和思維方式來分析和解決問題?？陀^世界是由許多具體的事物、事件、概念和規(guī)則組成的，這些均可看成對象。面向?qū)ο蠓椒ㄕ且詫ο笞鳛樽罨镜脑?，它也是分析問題、解決問題的核心。由此可見，面向?qū)ο蠓椒ǚ先祟惖恼J識規(guī)律。計算機實現(xiàn)的對象與真實世界的對象有一一對應(yīng)的關(guān)系，不必做任何轉(zhuǎn)換，這就使面向?qū)ο笠子跒槿藗兯斫?、接受和掌握?/p>

面向?qū)ο箝_發(fā)方法包括面向?qū)ο蠓治觥⒚嫦驅(qū)ο笤O(shè)計和面向?qū)ο髮崿F(xiàn)。面向?qū)ο箝_發(fā)方法有Booch方法、Co