項目一軟件工程基礎任務一理解軟件及軟件工程任務二熟悉軟件開發流程任務三認識軟件質量模型與CMMI模型

任務一理解軟件及軟件工程

自1968年北大西洋公約組織科技委員會在聯邦德國召開的國際學術會議上第一次提出軟件工程一詞以來，軟件工程已成為計算機軟件的一個重要分支和研究方向。軟件工程是指應用計算機科學、數學及管理科學等原理，以工程化的原則和方法來解決軟件問題的工程，其目的是提高軟件生產率和軟件質量，降低軟件成本。

操作一軟件

1．軟件定義

國家標準(GB)中對計算機軟件的定義為：與計算機系統的操作相關的計算機程序、規程、規則以及可能有的文件、文檔及數據。通常認為軟件是計算機系統中與硬件相互依存的另一部分，是包括程序、數據以及相關文檔的完整集合。其中，程序是軟件開發人員根據用戶需求開發的、用程序設計語言描述的、適合計算機執行的指令(語句)序列；數據是使程序能夠正常操作信息的數據結構；文檔是與程序開發、維護和使用有關的圖文資料。應該注意，程序并不是軟件，程序只是軟件的組成部分。

軟件按照功能可以分為應用軟件、系統軟件、支撐軟件(或工具軟件)，見表1-1。

表1-1軟?件?分?類?表

2．軟件特點

軟件產品不同于其他硬件產品，有其自身的特點：

(1)軟件是一種邏輯實體，是人類智慧的表現形式。軟件看不見、摸不著，其包裝、載體、印刷的文檔都不是其本身。

(2)軟件產品的生產過程與硬件不同。它沒有明顯的制作過程，不同于傳統意義上的硬件制造，至今尚未完全擺脫手工開發方式，開發效率受到很大的限制。

(3)軟件產品的使用與維護同硬件不同。軟件在運行、使用期間不存在磨損、老化問題，但可能存在錯誤，需要進行維護。

(4)軟件的開發、運行對計算機系統具有依賴性。軟件受計算機系統的限制，這導致了軟件移植的問題。

(5)軟件的復雜性隨其規模的增加迅速增大。大規模的硬件系統可以分解成小的子系統和部件，分別進行獨立的設計和制造后裝配到一起，只要符合預先定義的接口要求，就可以保證整個系統的正常運行。軟件系統的各個模塊之間有各種邏輯聯系，一起運行于同一個系統空間，模塊越多，相互的影響和關聯就越復雜，導致整個軟件的復雜度隨規模增大而指數性地增長。

(6)軟件的成本非常昂貴。

(7)軟件的開發是一個復雜的過程，其中包括管理和技術兩個層面。

操作二軟件危機

1．軟件的發展歷程

計算機系統總是離不開軟件，然而早期的硬件、軟件是融于一體的，為了使得某臺計算機設備能夠完成某項工作，不得不給它專門配置程序。隨著計算機技術的快速發展和計算機應用領域的迅速拓寬，自20世紀60年代中期以來，軟件需求迅速增長，軟件數量急劇膨脹，于是，軟件從硬件設備中分離了出來，不僅成為了獨立的產品，并且逐漸發展成為一個專門的產業領域。觀察軟件的發展，可以發現軟件生產有三個發展階段，即程序設計階段、程序系統階段和軟件工程階段。

1)程序設計階段

20世紀50至60年代中期，隨著硬件的飛速發展，計算機實現批量生產，逐步商業化，從一定程度上帶動了軟件的發展，然而軟件生產仍然以個體為主。這一時期的程序通常是針對特定計算機或者特定任務編制的專用程序，程序規模小，編寫強調算法效率和對計算機資源的充分利用，但沒有系統化方法和管理理論指導軟件開發。

2)程序系統階段

大約在20世紀60年代中期到70年代中期，出現了多道程序、多用戶系統和第一代數據庫管理系統等新技術。以IBM的S/360為代表的通用商業化大型計算機的出現為起點，一些軟件開發人員集合起來，專門為特定用戶在大型計算機上開發大型軟件系統，編程語言和程序設計理論開始成熟，軟件生產以軟件作坊的形式出現。由于缺乏工程管理和系統化方法指導軟件開發和管理，許多軟件因為各種各樣的原因開發失敗或是無法維護，從而引發了軟件危機。為解決軟件危機，軟件工程學科誕生了。

3)軟件工程階段

在20世紀70年代中期到80年代中后期，結構化的工程方法獲得了廣泛應用，并成為一種成熟的軟件工程方法學。應該說，采用工程的原理、技術和方法實施軟件產品開發，以適應軟件產業化發展的需要，成為這個時期諸多軟件企業的追求目標。

當今時代是一個軟件產業高速發展的時期，以軟件為特征的“智能”產品不斷涌現。尤其是網絡通信技術、數據庫技術與多媒體技術的結合，徹底改變了軟件系統的體系結構，使得計算機的潛能獲得了更大程度的釋放。可以說，以計算機軟件為核心的信息技術的高速發展，已經使得人們的生活方式與生活節奏發生了根本性的變化。“軟件工程”自產生以來，人們就寄希望于它去沖破“軟件危機”這朵烏云。但是，軟件危機現象并沒有得到徹底排除，特別是，一些老的危機問題可能解決了，但接著又出現了許多新的危機問題，于是不得不去尋找一些更新的工程方法。應該說，正是危機問題的不斷出現，推動著軟件工程方法學的快速發展。

2．軟件危機

20世紀60年代末70年代初，西方工業發達國家經歷了一場“軟件危機”。這場軟件危機表現在：一方面軟件十分復雜，價格昂貴，供需差日益增大；另一方面軟件開發又常常受挫，質量差，制定的進度表和完成日期很少能按時實現，研制過程很難管理，即軟件的研制往往失去控制。我們稱軟件開發和維護過程中所遇到的這一系列嚴重問題為軟件危機。這些問題絕不僅僅是不能正常運行的軟件才具有的，實際上，幾乎所有軟件都不同程度地存在這些問題。具體來說，軟件危機主要有以下一些方面的典型表現：

(1)軟件開發成本、進度的估計很不準確。軟件開發機構制定的項目計劃跟實際情況有很大差距，使得開發預算一再被突破。由于對工作量和開發難度估計不足，進度計劃無法按時完成，開發時間一再拖延，這種現象嚴重降低了軟件開發機構的信譽。

(2)軟件產品常常與用戶的要求不一致。在開發過程中，軟件開發人員和用戶之間缺乏信息交流。開發人員常常是在對用戶要求只有模糊了解的情況下就倉促上陣，匆忙著手編寫程序。由于這些問題的存在，導致開發出來的軟件不能滿足用戶的實際應用需要。

(3)軟件產品質量可靠性差。軟件開發過程中，沒有建立起確實有效的質量保證體系。一些軟件項目為了趕進度或降低軟件開發成本，甚至不惜降低軟件質量標準、偷工減料。

(4)軟件文檔不完整、不一致。計算機軟件不僅僅是程序，在軟件開發過程中還應該產生出一系列的文檔資料。實際上，軟件開發非常依賴這些文檔資料。在軟件開發過程中，軟件開發機構的管理人員需要使用這些文檔資料來管理軟件項目；技術人員則需要利用文檔資料進行信息交流；用戶也需要通過這些文檔資料來認識軟件，對軟件進行驗收，熟悉軟件的安裝、操作等。但是，由于軟件項目管理工作的欠缺，軟件文檔往往不完整，對軟件的描述經常不一致，很難通過文檔去跟蹤軟件開發過程中軟件產品規格的變更。

(5)軟件產品可維護性差。軟件中的錯誤非常難改正，軟件很難適應新的硬件環境，很難根據用戶的需要在原有軟件中增加一些新的功能。這樣的軟件是不便于重用的，以前開發的軟件，一旦過時就不得不完全丟棄。

(6)軟件生產率低。軟件生產率跟不上硬件的發展速度，不能適應計算機應用的迅速普及，使得現代計算機硬件提供的巨大潛力不能被充分利用。

軟件危機現象最初出現在軟件發展的第二個階段——程序系統階段。自那時起，軟件工作者就一直在探尋導致軟件危機的原因，并期望能通過對軟件危機原因的分析，找到一種行之有效的、能夠克服軟件危機的方法、策略。通過對一系列危機現象的研究，人們總結發現，產生軟件危機的原因主要體現在以下幾個方面：

(1)軟件具有不可見性。軟件不同于硬件，它是計算機系統中的邏輯部件，缺乏“可見性”。硬件錯誤往往可以通過它的物理現象直接反映出來，例如出現不正常的發熱、噪音現象等，但軟件錯誤沒有這些直觀表現，軟件中存在的程序行錯誤，必須等到這行程序執行時才有可能被發現。因此，軟件錯誤比起硬件錯誤來更難被發現。軟件的不可見特性也使得對軟件項目的量化管理更難實施，對軟件質量的量化評價更難操作。

(2)軟件系統規模龐大。軟件成為產品以后已不同于早期程序，隨著功能的增多，其規模、復雜程度越來越大。例如,1968年美國航空公司訂票系統達到30萬條指令，IBM360OS第16版達到100萬條指令，1973年美國阿波羅計劃達到1000萬條指令。這些龐大規模的軟件系統，其復雜程度已超過了人所能接受的程度，但是，面對更復雜的軟件系統，其開發卻仍然需要依靠開發人員的個人創造與手工操作。

(3)軟件生產工程化管理程度低。軟件生產的工程化管理是軟件作為產品所必需的，這意味著軟件也需要像硬件一樣，在軟件分析、設計完成之后，才能考慮軟件的實現。應該說，工程化管理能夠降低解決問題的代價。但是，許多軟件的開發往往是在分析、設計沒有完成的情況下，就已經進入編碼實現階段。由于前期準備工作不充分，致使軟件項目管理混亂，嚴重影響軟件項目成本、開發進度和軟件質量。

(4)對用戶需求關心程度不夠。軟件開發機構不熟悉用戶業務領域。軟件技術人員所關注的僅僅是計算機技術，他們不太愿意和用戶溝通，輕視對用戶的需求調查，也缺乏有效的用戶調查策略和手段。這就使得用戶的需求意愿得不到充分反映，甚至被錯誤理解。實際上，軟件是為用戶開發的，只有用戶才能真正了解他們自己的需要。由于沒有對用戶做大量深入細致的調查研究，以致軟件需求規格定義不準確，并最終使得完成后的軟件不能適應用戶的應用需要。

(5)對軟件維護重視程度不夠。在軟件產品開發過程中，開發者很少考慮這個軟件今后還需要提供維護。但是，軟件的使用周期漫長，軟件錯誤具有隱蔽性，許多年之后軟件仍可能需要改錯。另外，軟件的工作環境也可能會在幾年后發生改變，用戶也可能在軟件運行幾年以后，要求對它增加新的功能。這些都屬于軟件維護問題。實際上，軟件的可維護性是衡量軟件質量的一項重要指標，軟件可維護性高，軟件就便于修正、改版和升級，由此可以使軟件具有更長的使用壽命。

(6)軟件開發工具自動化程度低。盡管軟件開發工具比30年前已經有了很大的進步，但直到今天，軟件開發仍然離不開工程人員的個人創造與手工操作，軟件生產仍不可能像硬件設備的生產那樣，達到高度的自動化。

操作三軟件工程

1.軟件工程定義

軟件工程是指研究軟件生產的一門學科，也就是將完善的工程原理應用于經濟地生產既可靠又能在實際機器上有效運行的軟件。

1983年美國《IEEE軟件工程標準術語》對軟件工程下的定義為：“軟件工程是開發、運行、維護和修復軟件的系統方法。”其中“軟件”的定義為：計算機程序、方法、規則、相關的文檔資料以及在計算機上運行時所必需的數據。軟件工程是指應用計算機科學、數學及管理科學等原理，以工程化的原則和方法來開發與維護軟件的學科。其目的是在規定的時間、規定的開發費用內開發出滿足用戶需求的高質量的軟件系統(高質量是指錯誤率低、好用、易用、可移植、易維護等)。

2．軟件工程目標

軟件工程目標是基于軟件項目目標的成功實現而提出的，主要體現在以下幾個目標上：

(1)軟件開發成本較低；

(2)軟件功能能夠滿足用戶的需求；

(3)軟件性能較好；

(4)軟件可靠性高；

(5)軟件易于使用、維護與移植；

(6)能按時完成開發任務，并及時交付使用。

3.軟件工程三要素

軟件工程技術是指軟件工程所具有的技術要素。作為軟件開發與維護的工程方法學，軟件工程具有三個方面的技術要素，即軟件工程方法、軟件工具和軟件工程過程。

軟件工程方法是指完成軟件開發與維護任務時，應該“如何做”的技術方法。它所涉及的任務貫穿于軟件開發、維護的整個過程之中，包括軟件需求分析、軟件結構設計、程序算法設計等諸多任務。而其方法則體現在使用圖形或某種特殊語言來表現這些任務中需要建立的軟件系統模型，如數據流模型、軟件結構模型、對象模型、組件模型等。主要的軟件工程方法有結構化方法和面向對象方法。

(1)結構化方法。結構化方法是傳統的基于軟件生命周期的軟件工程方法，自20世紀70年代產生以來，獲得了極有成效的軟件項目應用。結構化方法是以軟件功能為目標來進行軟件構建的，包括結構化分析、結構化設計、結構化實現和結構化維護等內容，能夠很好地適應結構化編程工具，例如C、Pascal語言等。它主要使用數據流模型來描述軟件的數據加工過程，并可以通過數據流模型，由對軟件的分析順利過渡到對軟件的結構設計。

(2)面向對象方法。面向對象方法是以軟件問題域中的對象為基本依據來構造軟件系統模型的，包括面向對象分析、面向對象設計、面向對象實現和面向對象維護等內容。確定問題域中的對象成分及其關系，建立軟件系統對象模型，是面向對象分析與設計過程中的核心內容。自20世紀80年代以來，人們提出了許多有關面向對象的方法，其中，由Booch、Rumbaugh、Jacobson等人提出的一系列面向對象方法成為了主流方法，并被結合為統一建模語言(UML)，成為了面向對象方法中的公認標準。面向對象方法能夠最有效地適應面向對象編程工具，例如C++、Java等，并特別適用于面向用戶的交互式系統的開發。軟件工具是為了方便軟件工程方法的運用而提供的具有自動化特征的軟件支撐環境。軟件工具通常也稱為CASE，它是計算機輔助軟件工程(Computer-AidedSoftwareEngineering)的英文縮寫。CASE工具覆蓋面很廣，包括分析建模、設計建模、源代碼編輯生成、軟件測試等。表1-2所列是一些常用的CASE工具類別。表1-2常用的CASE工具類別軟件工程過程是指為了開發軟件產品，開發機構在軟件工具的支持下，按照一定的軟件工程方法所進行的一系列軟件工程活動。實際上，這一系列的活動也就是軟件開發中開發機構需要制定的工作步驟，它應該是科學的、合理的，否則將影響軟件開發成本、進度與產品質量。因此，軟件工程過程也就涉及了軟件產品開發中有哪些工作步驟，各個工作步驟分別具有什么樣的工作特征，以及各個工作步驟分別需要產生一些什么結果等方面的問題。

4.軟件工程基本原則

軟件工程是關于軟件項目的工程方法學，其價值只能通過具體的軟件項目才能真正體現出來。為保證在軟件項目中能夠有效地貫徹與正確地使用軟件工程規程，需要有一定的軟件工程原則來對軟件項目加以約束。一些研究軟件工程的專家學者分別從不同的角度陸續提出過許多關于軟件工程的原則或“信條”，其中，著名的軟件工程專家B.W.Boehm經過總結，提出了以下7條基本原則：

(1)采用分階段的生命周期計劃，以實現對項目的嚴格管理。軟件項目的開展，需要計劃在先、實施在后。統計表明，50%以上的失敗項目是由于計劃不周而造成的。在軟件開發、維護的漫長生命周期中，需要完成許多性質各異的工作，假若沒有嚴格有效的計劃對項目工作的開展加以約束，則必將使之后項目中的諸多工作處于一種混亂狀態。

采用分階段的生命周期計劃，實現對項目的嚴格管理，即意味著：應該把軟件項目按照軟件的生命周期分成若干階段，以階段為基本單位制定出切實可行的計劃，并嚴格按照計劃對軟件的開發、維護實施有效的管理。

(2)堅持階段評審制度，以確保軟件產品質量。軟件質量是通過軟件產品反映出來的，但是，軟件質量的形成貫穿于整個軟件開發過程之中。大量的軟件開發事實表明，軟件中的許多錯誤是在開始進行編碼之前就已經形成了。根據有關統計：軟件設計錯誤占了軟件錯誤的63%，而編碼錯誤則僅占37%。

采用階段評審制度，也就是要求在軟件產品形成過程中，能夠對其質量實施過程監控，以確保軟件在每個階段都能夠具有較高質量。

實際上，軟件錯誤發現得越早，則錯誤越容易修正，為此所需付出的代價也就越少。因此，在每個階段都進行嚴格的評審，也有利于從管理制度上減少為保證質量的成本代價。

(3)實行嚴格的產品控制，以適應軟件規格的變更。軟件規格是軟件開發與軟件驗收的基本依據，是不能隨意變更的。在軟件開發過程中若出現了軟件規格的變更，也就意味著軟件的開發費用因此增加了。

但是，在軟件開發過程中，改變軟件規格有時又是難免的，特別是那些需要較長的開發周期的軟件項目。例如，那些為專門用戶定制開發的軟件系統，就有可能因為用戶的業務領域、服務方式發生了改變，而使軟件功能有了新的要求。面對用戶的新要求，顯然不能硬性禁止，而只能依靠科學的產品控制技術來適應。實際上，許多通用軟件產品也存在規格變更這個問題，例如，軟件開發機構為了使自己的軟件產品能夠在更多的環境下工作，而不得不針對所開發的軟件產品推出諸多不同的版本。實行嚴格的產品控制，就是當軟件規格發生改變時，能夠對軟件規格進行跟蹤記錄，以保證有關軟件產品的各項配置成分保持一致性，由此能夠適應軟件規格的變更。

(4)采用先進的程序設計技術。許多先進的軟件工程方法往往都起源于先進的程序設計技術。例如，20世紀70年代初出現的C、Pascal，這些結構化的程序設計語言，不僅成為了當時先進的程序設計技術，而且由此帶來了結構化的軟件分析、設計方法。自20世紀80年代以來，隨著C++、Java等程序設計語言的產生，面向對象程序設計技術成為了更加先進的技術，并由此推動了面向對象軟件分析、設計方法的發展。自20世紀90年代開始，建立在面向對象程序設計技術基礎上的組件技術又隨之誕生了，于是，基于組件技術的軟件工程方法學也就不斷涌現了出來。采用先進的程序設計技術會獲得諸多方面的好處。它不僅會帶來更高的軟件開發效率，而且所開發出的軟件會具有更好的質量，更加便于維護，并且往往具有更長久的使用壽命。例如，組件技術通過創建比起“類”來更加抽象、更具有通用性的基本組件，可以使軟件開發如同可插入的零件一樣裝配。這樣的軟件，不僅開發容易、維護便利，而且可以根據特定用戶的需要，更加方便地進行改裝。

(5)軟件成果應該能夠清楚地審查。軟件成果是軟件開發的各個階段產生出來的一系列結果，是對軟件開發給出評價的基本依據，包括系統文檔、用戶文檔、源程序、資源數據和最終產品等內容。

針對軟件開發給出有效的評價，是軟件工程必須關注的重要內容。但是，軟件產品是無形的邏輯產品，缺乏明確的物理度量標準。比起一般物理產品的開發，軟件開發工作進展情況可見性差，其開發更難于管理與評價。因此，為了提高軟件開發過程的可見性，更好地管理軟件項目和評價軟件成果，應該根據軟件開發項目的總目標及完成期限，規定軟件開發組織的責任和軟件成果標準，從而使所得到的結果能夠清楚地被審查。

(6)開發小組的人員應該少而精。這條基本原則具有以下兩點含義：

其一，軟件開發小組組成人員的素質應該好。軟件開發是一種需要高度負責、高度協作的高智力勞動，因此，其對人員素質的要求也就主要體現在智力水平、協作能力、團隊意識和責任意識等幾個方面。實際上，由高素質人員組成的開發隊伍能夠形成一支很強的開發團隊，具有比由一般人員組成的開發隊伍高出幾倍、甚至幾十倍的開發效率，也能夠完成更加復雜的項目任務。其二，軟件開發小組的成員人數不宜過多。軟件的復雜性和無形性決定了軟件開發需要大量的通信。隨著軟件開發小組人員數目的增加，人員之間因為交流信息、討論問題而造成的通信開銷會急劇增大，這勢必影響人員之間的相互協作與工作質量。因此，為了保證開發小組的工作效率，開發小組成員人數一般不應超過5人。由于這個原因，一些有許多成員參加的大型項目，也就需要分成多個子項目，然后分別交給多個項目小組去完成。

(7)承認不斷改進軟件工程實踐的必要性。軟件工程的意義重在實踐，作為一門工程方法學，它所推出的一系列原則、方法和標準，不僅來源于工程實踐，而且也需要在工程實踐中不斷地改進、完善。實際上，不同的軟件開發機構可以根據自己的具體情況，建立起具有自己特征的軟件工程規程體系。應該講，前述的六條基本原則，是實現軟件開發工程化這個目標的必要前提。但是，僅有這六條原則，還不足以保證軟件開發工程化進程能夠持久地進行下去。因此，Boehm提出了“承認不斷改進軟件工程實踐的必要性”，這表明：軟件工程在實際應用中，應該積極主動地采納新的軟件技術，并不斷總結新的工程經驗。

軟件技術在不斷進步，軟件的應用領域也在不斷拓寬，軟件工程必須緊緊跟上新時代軟件的發展，才能獲得更加持久的生命力。

任務二熟悉軟件開發流程

操作一軟件生命周期

如任何事物一樣，軟件也有其孕育、誕生、成長、成熟和衰亡的生存過程，一般稱其為“軟件生命周期”。具體來說，軟件生命周期是指軟件產品從提出、實現、使用維護到停止使用并退役的過程。

軟件生命周期一般分為6個階段，即制定計劃、需求分析、設計、編碼、測試、運行和維護。軟件開發的各個階段之間的關系不可能是順序且線性的，而應該是帶有反饋的迭代過程。在軟件工程中，這個復雜的過程用軟件開發模型來描述和表示。軟件生命周期由軟件定義、軟件開發和軟件維護三個時期組成，每個時期又可進一步劃分成若干個階段。

1．軟件定義時期

(1)問題定義：這是軟件生存期的第一個階段，主要任務是弄清用戶要計算機解決的問題是什么。

(2)可行性研究：任務是為前一階段提出的問題尋求一種至數種在技術上可行、在經濟上有較高效益的解決方案。

2．軟件開發時期

(1)需求分析：弄清用戶對軟件系統的全部需求，主要是確定目標系統必須具備哪些功能。

(2)總體設計：設計軟件的結構，即確定程序由哪些模塊組成以及模塊間的關系。

(3)詳細設計：針對單個模塊的設計。

(4)編碼：按照選定的語言，把模塊的過程性描述翻譯為源程序。

(5)測試：通過各種類型的測試(及相應的調試)使軟件達到預定的要求。

3．軟件維護時期

這是軟件生存周期的最后一個時期。軟件人員在這一時期的工作，主要是做好軟件維護。維護的目的，是保證軟件在整個生存周期內滿足用戶的需求和延長軟件的使用壽命。

操作二常用的軟件開發模型

為了指導軟件的開發，用不同的方式將軟件生存周期中的所有開發活動組織起來，形成不同的軟件開發模型。軟件開發模型是跨越整個軟件生存周期的系統開發、運行和維護所實施的全部工作和任務的結構框架，它給出了軟件開發活動各階段之間的關系。常見的軟件開發模型有瀑布模型、螺旋模型、快速原型模型、噴泉模型等。本節將簡單地比較并分析瀑布模型、螺旋模型、快速原型模型、噴泉模型等軟件開發模型。

1.瀑布模型

瀑布模型即生存周期模型，其核心思想是按工序將問題化簡，將功能的實現與設計分開，便于分工協作，即采用結構化的分析與設計方法將邏輯實現與物理實現分開。瀑布模型將軟件生命周期劃分為軟件計劃、需求分析和定義、軟件設計、軟件實現、軟件測試、軟件運行和維護這6個階段，規定了它們自上而下、相互銜接的固定次序，如同瀑布流水逐級下落。采用瀑布模型的軟件過程如圖1-1所示。圖1-1采用瀑布模型的軟件過程瀑布模型是最早出現的軟件開發模型，在軟件工程中占有重要的地位，它提供了軟件開發的基本框架。瀑布模型的本質是一次通過，即每個活動只執行一次，最后得到軟件產品，也稱為“線性順序模型”或者“傳統生命周期”。其過程是從上一項活動接收該項活動的工作對象作為輸入，利用這一輸入實施該項活動應完成的內容，給出該項活動的工作成果，并作為輸出傳給下一項活動，同時評審該項活動的實施，若確認，則繼續下一項活動，否則返回前面、甚至更前面的活動。瀑布模型有利于大型軟件開發過程中人員的組織及管理，有利于軟件開發方法和工具的研究與使用，從而提高了大型軟件項目開發的質量和效率。然而軟件開發的實踐表明，上述各項活動之間并非完全是自上而下且呈線性圖式的，因此瀑布模型存在如下嚴重的缺陷：

(1)由于開發模型呈線性，所以當開發成果尚未經過測試時，用戶無法看到軟件的效果。這樣軟件與用戶見面的時間間隔較長，也增加了一定的風險。

(2)在軟件開發前期發現的錯誤傳到后面的開發活動中時，可能會擴散，進而可能會造成整個軟件項目開發失敗。

(3)在軟件需求分析階段，完全確定用戶的所有需求是比較困難的，甚至可以說是不太可能的。

2.螺旋模型

螺旋模型將瀑布模型和演化模型(EvolutionModel)結合起來，它不僅體現了兩個模型的優點，而且還強調了其他模型均忽略了的風險分析。這種模型的每一個周期都包括需求定義、風險分析、工程實現和評審4個階段，由這4個階段進行迭代。軟件開發過程每迭代一次，軟件開發就前進一個層次。采用螺旋模型的軟件過程如圖1-2所示。

螺旋模型的基本做法是在“瀑布模型”的每一個開發階段前引入非常嚴格的風險識別、風險分析和風險控制，它把軟件項目分解成一個個小項目，每個小項目都標識一個或多個主要風險，直到所有的主要風險因素都被確定。圖1-2采用螺旋模型的軟件過程螺旋模型強調風險分析，使得開發人員和用戶對每個演化層出現的風險有所了解，繼而做出應有的反應，因此特別適用于龐大、復雜并具有高風險的系統。對于這些系統，風險是軟件開發不可忽視且潛在的不利因素，它可能在不同程度上損害軟件開發過程，影響軟件產品的質量。減小軟件風險的目標是在造成危害之前，及時對風險進行識別及分析，決定采取何種對策，進而消除或減少風險的損害。

與瀑布模型相比，螺旋模型支持用戶需求的動態變化，為用戶參與軟件開發的所有關鍵決策提供了方便，有助于提高目標軟件的適應能力，并且為項目管理人員及時調整管理決策提供了便利，從而降低了軟件開發風險。但是，我們不能說螺旋模型絕對比其他模型優越，事實上，這種模型也有其自身的如下缺點：

(1)采用螺旋模型需要具有相當豐富的風險評估經驗和專門知識，在風險較大的項目開發中，如果未能夠及時標識風險，勢必造成重大損失。

(2)過多的迭代次數會增加開發成本，延遲提交時間。

3.快速原型模型

快速原型又稱原型實現模型，它從需求收集開始，需要開發者和客戶在一起定義軟件的總體目標，標識出已知的需求，并規劃出需要進一步定義的區域；然后進行“快速設計”，即集中于軟件中那些對用戶/客戶可見的部分的表示，以創建原型，并由用戶/客戶評估并進一步細化待開發軟件的需求；隨后逐步調整原型使其滿足客戶的要求，同時也使開發者對將要做的事情有更好的理解。這個過程是迭代的，其流程從聽取客戶意見開始，隨后是建造及修改原型、客戶測試運行原型，然后往復循環，直到客戶對原型滿意為止。采用快速原型模型的軟件過程如圖1-3所示。圖1-3采用快速原型模型的軟件過程快速原型模型的最大特點是能夠快速實現一個可實際運行的系統的初步模型，供開發人員和用戶進行交流和評審，以便較準確地獲得用戶的需求。該模型采用逐步求精的方法使原型逐步完善，即每次經用戶評審后修改、運行，不斷重復直到雙方認可。這個過程是迭代過程，它可以避免在瀑布模型冗長的開發過程中看不見產品雛形的現象。其優點一是開發工具先進、開發效率高，使總的開發費用降低、時間縮短；二是開發人員與用戶交流直觀，可以澄清模糊需求，調動用戶積極參與，能及早暴露系統實施后潛在的一些問題；三是原型系統可作為培訓環境，有利于用戶培訓和開發同步，開發過程也是學習過程。快速原型模型的缺點是產品原型在一定程度上限制了開發人員的創新，沒有考慮軟件的整體質量和長期的可維護性。由于達不到質量要求，產品可能被拋棄而采用新的模型重新設計，因此快速原型模型不適合嵌入式、實時控制及科學數值計算等大型軟件系統的開發。

原型模型和增量模型都是從概要需求出發開發的，但二者有明顯不同。增量模型從一些不完整的系統需求出發開始開發，在開發過程中逐漸發現新的需求，然后進一步充實完善該系統，使之成為實際可用的系統。原型模型的目的是發現并建立一個完整并經過證實的需求規格說明，然后以此作為正式系統的開發基礎，因此原型開發階段的輸出是需求規格說明，這是為了降低整個軟件生成期的費用而拉大需求分析階段的一種方法，大部分原型是“用完就扔”的類型。

4.噴泉模型

噴泉模型是一種以用戶需求為動力、以對象為驅動的模型，主要用于描述面向對象的軟件開發過程。該模型認為軟件自下而上的開發過程中，各階段是相互重疊和多次反復的，類似一個噴泉，水噴上去又可以落下來。各個開發階段沒有特定的次序要求，并且可以交互進行，可以在某個開發階段中隨時補充其他任何開發階段中的遺漏。采用噴泉模型的軟件過程如圖1-4所示。圖1-4采用噴泉模型的軟件過程噴泉模型主要用于面向對象的軟件項目。軟件的某個部分通常被重復多次，相關對象在每次迭代中隨之加入漸進的軟件成分，各活動之間無明顯邊界，例如設計和實現之間沒有明顯的邊界，這也稱為“噴泉模型的無間隙性”。由于對象概念的引入，表達分析、設計及實現等活動只用對象類和關系，從而可以較容易地實現活動的迭代和無間隙。噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動，設計活動結束后才開始編碼活動，該模型的各個階段沒有明顯的界限，開發人員可以同步進行開發。其優點是可以提高軟件項目開發效率，節省開發時間，適應于面向對象的軟件開發過程。由于噴泉模型在各個開發階段是重疊的，因此在開發過程中需要大量的開發人員，因此不利于項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。任務三認識軟件質量模型與CMMI模型

操作一軟件質量模型

軟件質量是指與軟件產品滿足明確規定的和隱含的需要的能力有關的特征或特性的組合。軟件質量的特性是多方面的，但必須包括：與明確確定的功能和性能需求的一致性，所有能滿足給定需要的特性；與明確成文的開發標準的一致性；與所有專業開發的軟件所期望的隱含特性的一致性；顧客或用戶認為能滿足其綜合期望的程度，也即軟件的組合特性，它確定軟件在使用中將滿足顧客預期要求的程度。目前已有很多質量模型，它們分別定義了不同的軟件質量屬性。比較常見的三個質量模型是McCall模型(1977年)、Boehm模型(1978年)和ISO9126模型(1993年)。McCall等認為，特性是軟件質量的反映，軟件屬性可用作評價準則，定量地度量軟件屬性可知軟件質量的優劣。圖1-5給出了McCall模型的組成部分。圖1-5McCall質量模型軟件質量保證的主要活動內容歸納如下：

質量方針的制定與展開；

質量保證方針和質量保證標準的制定；

質量保證體系的建立與管理；

各階段的質量評審；

確保設計質量；

重要質量問題的提出與分析；

總結實現階段的質量保證活動；

整理面向用戶的文檔資料和說明書等；

產品質量鑒定、質量保證系統鑒定；

質量信息的收集、分析和使用。

操作二CMMI模型

CMMI的全稱為CapabilityMaturityModelIntegration，即能力成熟度模型集成。CMMI為改進一個組織的各種過程提供了一個單一的集成化框架，該框架消除了各個模型的不一致性，減少了模型間的重復，增加了透明度和理解，建立了一個自動的、可擴展的框架，因而能夠從總體上改進組織的質量和效率。CMMI的主要關注點包括成本效益、明確重點、過程集中和靈