1.1

軟件

1.2軟件工程

1.3軟件工程發展中的軟件開發方法與技術

1.4計算機輔助軟件工程

1.5軟件工程與其他相關學科的關系

1.6軟件工程職業道德規范

1.7軟件項目成敗情況統計

1.8全球軟件產業的現狀、趨勢與挑戰1.1軟件1.1.1軟件及軟件特性1.軟件軟件的定義是隨著計算機技術的發展而逐步完善的。在20世紀50年代，人們認為軟件就等于程序；60年代人們認識到軟件的開發文檔在軟件中的作用，提出軟件等于程序加文檔，但這里的文檔僅是指軟件開發過程中所涉及的分析、設計、實現、測試、維護等文檔，不包括軟件管理文檔；到了70年代人們又給軟件的定義中加入了數據。因此，軟件是計算機系統中與硬件相互依存的一部分，它包括：(1)在運行中能提供所希望的功能與性能的程序；(2)使程序能夠正確運行的數據及其結構；(3)描述軟件研制過程和方法所用的文檔。2.軟件的特性從廣義來說，軟件與硬件一樣也是產品，但兩者之間是有差別的，了解并理解這種差別對理解軟件工程是非常重要的。(1)軟件角色的雙重性。(2)軟件是被開發或設計的，而不是傳統意義上的被制造。(3)軟件不會“磨損”，但會退化。(4)絕大多數軟件都是定制的且是手工的。(5)軟件開發過程復雜且費用昂貴。1.1.2軟件的發展及分類1.軟件的發展自20世紀40年代出現了世界上第一臺計算機以后，經歷了幾十年的發展，計算機軟件經歷了程序設計、程序系統和軟件工程三個發展時期。表1.1列出了三個發展時期主要特征的對比，由此可以看出幾十年來軟件最根本的變化。2.軟件的分類軟件的應用非常廣泛，幾乎滲透到了各行各業。因此，要給出一個科學的、統一的、嚴格的計算機軟件分類標準是不現實也是不可能的，但可以從不同的角度對軟件進行適當的分類。常用的分類方法及意義如表1.2所示。1.1.3軟件危機及其產生的主要原因隨著社會對計算機應用需求的增長，軟件系統規模越來越龐大，生產難度和生產成本越來越高，軟件需求量劇增，質量沒有可靠的保證，軟件開發的生產率低等因素構成軟件生產的惡性循環。軟件生產的復雜性和高成本，使大型軟件的生產出現了很大的困難，因此出現了軟件危機。其具體表現如下：(1)開發人員和用戶之間存在矛盾。用戶在開發初期，由于各種原因往往不能準確地提出需求描述；開發人員在還沒有準確、完整地了解用戶的實際需求后就急于編程。(2)大型軟件項目需要組織一定的人力共同完成，多數管理人員缺少開發大型軟件系統的經驗；多數軟件開發人員缺乏協同方面的經驗；軟件項目開發人員不能有效地、獨立自主地處理大型軟件的全部關系和各個分支，因此容易產生疏漏和錯誤。(3)缺乏有力的方法學和工具方面的支持，過分依靠程序設計人員的技巧和創造性。重編程，輕需求分析；重開發，輕維護；重程序，輕文檔。這樣做的后果就是在軟件系統中“埋藏”了許多故障隱患，直接危害著系統的可靠性和穩定性。人們把在軟件開發與維護過程中遇到的一系列嚴重問題稱為軟件危機。1.1.4軟件危機的表現軟件危機的主要表現如下：(1)軟件開發進度難以預測；(2)軟件開發成本難以控制；(3)用戶對軟件產品的功能要求難以滿足；(4)軟件產品的質量無法保證，系統中的錯誤難以消除；(5)軟件產品難以維護；(6)軟件缺少適當的文檔資料；(7)軟件開發的生產速度難以滿足社會需求的增長。1.1.5解決軟件危機的途徑分析了造成軟件危機的原因后，人們開始探索用工程的方法進行軟件生產的可能性，即用軟件工程的概念、原理、技術和方法進行軟件的開發、管理、維護和更新。于是，計算機科學的一個領域——“軟件工程”誕生了。1.2軟件工程1.2.1軟件工程的概念軟件工程是指導計算機開發和維護的工程學科。借用傳統工程設計的基本思想，采用工程化的概念、原理、技術和方法來開發與維護軟件，突出軟件生產的科學方法，把經過時間考驗而證明正確的管理技術與當前能夠得到的最好的技術和方法結合進來，降低開發成本，縮短研制周期，提高軟件的可靠性和生產效率。軟件的工程化生產已成為軟件產業。軟件已成為產品，它涉及產值、市場、版權、法律保護等方面的問題。軟件工程是一門交叉學科，需要用管理學的原理和方法來進行軟件生產管理；用工程學的觀點來進行費用估算、制訂進度和實施方案；用數學方法來建立軟件可靠性模型以及分析各種算法。1.2.2軟件工程的三要素軟件工程以關注軟件質量為目標，由方法、工具和過程三個要素構成，如圖1.3所示。軟件工程方法為軟件開發提供了“如何做”的技術，涉及軟件工程的多個方面，如項目計劃與估算、軟件系統需求分析、數據結構、系統總體結構的設計、算法過程的設計、編碼、測試、維護等。軟件工具為軟件工程方法提供了自動的或半自動的軟件支撐環境。目前，已經推出了許多軟件工具，這些軟件工具集成起來，建立起稱之為計算機輔助軟件工程(ComputerAidedSoftwareEngineering，CASE)的軟件開發支撐系統。CASE將各種軟件工具、開發機器和一個存放開發過程信息的工程數據庫組合起來形成一個軟件工程環境。軟件工程的過程將軟件工程的方法和工具綜合起來，以達到合理、及時地進行計算機軟件開發的目的。過程定義了方法使用的順序、要求交付的文檔資料、為保證質量和協調變化所需要的管理及軟件開發各個階段完成的里程碑。1.2.3軟件工程的目標軟件工程研究的對象是大型軟件系統的開發過程，它研究的內容是生產流程，各生產步驟的目的、任務、方法、技術、工具、文檔和產品規格。軟件工程的基本目標是生產具有正確性、可用性及開銷合宜(合算性)的產品。正確性意指軟件產品達到預期功能的程度；可用性意指軟件基本結構、實現及文檔達到用戶可用的程度；開銷合宜意指軟件開發、運行的整個開銷滿足用戶的需求。在給定成本和進度的前提下，開發出具有適用性、有效性、可修改性、可靠性、可理解性、可維護性、可重用性、可移植性、可追蹤性、可互操作性和滿足用戶需求的產品。追求這些目標有助于提高軟件產品的質量和開發效率，降低維護的困難。(1)適用性：軟件在不同的系統約束條件下，使用戶需求得到滿足的難易程度。(2)有效性：軟件系統能最有效地利用計算機的時間和空間資源。各種軟件無不把系統的時/空開銷作為衡量軟件質量的一項重要技術指標。很多場合，在追求時間有效性和空間有效性時會發生矛盾，這時不得不犧牲時間有效性來換取空間有效性，或犧牲空間有效性以換取時間有效性。時/空折中是經常采用的技巧。(3)可修改性：允許對系統進行修改而不增加原系統的復雜性。支持軟件的調試和維護，是一個難以達到的目標。(4)可靠性：能防止因概念、設計、結構等方面的不完善而造成軟件系統的失效，具有挽回因操作不當而造成軟件系統失效的能力。(5)可理解性：系統具有清晰的結構，能直接反映問題的所在。可理解性有助于控制軟件的復雜性，并支持軟件的維護、移植或重用。(6)可維護性：軟件交付使用后，能夠對它進行修改，以改正潛伏的錯誤，改進性能和其他屬性，使軟件產品能適應環境的變化等。軟件維護費用在軟件開發費用中占有很大的比重。可維護性是軟件工程中一項十分重要的目標。(7)可重用性：把概念或功能相對獨立的一個或一組相關模塊定義為一個軟部件，可組裝在系統的任何位置，降低開發工作量。(8)可移植性：軟件從一個計算機系統或環境搬到另一個計算機系統或環境的難易程度。(9)可追蹤性：根據軟件需求對軟件設計、程序進行正向追蹤，或根據軟件設計、程序對軟件需求進行逆向追蹤的能力。(10)可互操作性：多個軟件元素相互通信并協同完成任務的能力。1.2.4軟件工程的開發原則軟件工程的目標為軟件開發提出了明確的要求。為了達到這些要求，在軟件開發過程中必須遵循下列軟件工程的原則：抽象、信息隱藏、模塊化、局部化、一致性、完整性和可驗證性。(1)抽象(Abstraction)：抽取事物最基本的特性和行為，忽略其非基本的細節，以控制軟件開發過程的復雜性，有利于軟件的可理解性和開發過程的管理。(2)信息隱藏(InformationHiding)：將模塊中的軟件設計內容和實現決策封裝起來，在系統的結構分析與設計中把模塊看成是一個“黑箱”，模塊內部的實現細節被隱藏，而外部只提供功能和接口的有關說明，使軟件開發人員能夠將注意力集中在更高層次的抽象上。(3)模塊化(Modularity)：將大的、復雜的程序，分成一個個邏輯上相對獨立、功能相對簡單的小程序，只要定義好這些小程序的接口和設計關系，就可以將復雜的程序分解為若干簡單的程序來處理，有助于信息隱藏和抽象，也有助于降低軟件系統的復雜性。(4)局部化(Localization)：在物理模塊內集中邏輯上相互關聯的計算資源，從物理和邏輯兩個方面保證系統中模塊內部的高內聚性和模塊之間的低耦合性，有助于模塊的獨立性。(5)一致性(Consistency)：整個軟件系統(包括程序和文檔)使用一致的概念、符號和術語，一致的程序內部接口和硬、軟件接口，一致的系統規格說明與形式化公理系統，一致的系統界面、編碼風格和數據組織形式等。一致性原則支持系統的正確性和可靠性。(6)完整性(Completeness)：軟件系統不丟失任何重要成分，系統具有服從需求的完整功能和實現功能所需的數據。(7)可驗證性(Verifiability)：大型軟件在功能分解和實施中，遵循系統容易檢查、測試、評審的原則，以保證軟件系統的正確性和可用性。1.2.5軟件工程涉及的人員1.利益相關者參與軟件過程(及每一個軟件項目)的利益相關者可以分為以下5類。(1)高級管理者：負責定義業務問題，這些問題往往會對項目產生很大的影響。(2)項目(技術)管理者：必須計劃、激勵、組織和控制軟件開發人員。(3)開發人員：擁有開發產品或應用軟件所需的技能。(4)客戶：闡明待開發軟件的需求，包括關心項目成敗的其他利益相關者。(5)最終用戶：軟件發布成為產品后直接與軟件進行交互的人。2.團隊負責人一個具有實戰能力的項目經理應該具有以下4種關鍵品質。(1)解決問題：具有實戰能力的軟件項目經理能夠準確地診斷出最為密切相關的技術問題和組織問題；能夠系統地制訂解決方案，適當地激勵其他開發人員來實現該方案；能夠將在過去項目中學到的經驗應用到新環境中；如果最初的解決方案沒有結果，則能夠靈活地改變方向。(2)管理者的特性：優秀的項目經理必須能夠掌管整個項目。必要時要有信心進行項目控制，同時還要允許優秀的技術人員按照他們的本意行事。(3)成就：為了優化項目團隊的生產效率，一位稱職的項目經理必須獎勵那些工作積極主動并且做出成績的人。必須通過自己的行為表明出現可控風險并不會受到懲罰。(4)影響和隊伍建設：具有實戰能力的項目經理必須能夠“理解”人。他必須能理解語言和非語言的信號，并對發出這些信號的人的要求做出反應。項目經理必須能在高壓力的環境下保持良好的控制能力。3.軟件團隊作為一種復雜的工程活動，軟件工程不是由獨立的個人而是由團隊進行的。通常情況下，一個團隊可以有多個小組，較小的小組由3～4人組成，較大的小組由10余人組成。在軟件工程團隊中，常見的分工角色有：(1)需求工程師，又稱為需求分析師：承擔需求開發任務。軟件產品的需求開發工作通常由多個需求工程師來完成，他們共同組成一個需求工程師小組，在首席需求工程師領導下開展工作。他們跟客戶一起工作，并把客戶想要實現的目標分解為離散的需求。通常一個團隊只有一個需求工程師小組。(2)軟件體系結構師：承擔軟件體系結構的設計任務。通常也是由多人組成一個小組，并在首席軟件體系結構師的領導下開展工作。通常一個團隊只有一個軟件體系結構師小組。(3)軟件設計師：承擔詳細設計任務。在軟件體系結構設計完成之后，可以將其部件分配給不同的開發小組。開發小組中負責分配部件詳細設計工作的人員就是軟件設計師。一個團隊可能有一個或多個開發小組。一個小組可能有一個或多個軟件設計師。(4)程序員：承擔軟件構造及模塊的測試任務。程序員與軟件設計師通常是同一批人，也是根據其所分配到的任務開展工作。(5)人機交互設計師：承擔人機交互設計任務。人機交互設計師與軟件設計師可以是同一批人，也可以是不同人員。在有多個小組的軟件工程團隊中，可以有一個單獨的人機交互設計師小組，也可以將人機交互設計師分配到各個小組。(6)軟件測試人員：承擔軟件測試任務。軟件測試人員通常需要獨立于其他的開發人員角色。一個團隊可能有一個或多個測試小組。一個小組可能有一個或多個軟件測試人員。(7)項目管理人員：負責計劃、組織、協調和控制軟件開發的各項工作。相比于傳統意義上的管理者，他們不完全是監督者和控制者，更多的是協調者。通常一個團隊只有一個項目管理人員。(8)軟件配置管理人員：管理軟件開發中產生的各種制品，具體工作是對重要制品進行標識、變更控制、狀態報告等。通常一個團隊只有一個軟件配置管理人員。(9)質量保證人員：在生產過程中監督和控制軟件產品質量的人員。通常一個團隊有一個質量保證小組，其由一個或多個人員組成。(10)培訓和支持人員：負責軟件交付與維護任務。他們可以是其他開發人員的一部分，也可以是獨立的人員。(11)文檔編寫人員：專門負責寫作軟件開發過程中各種文檔的人員。他們的存在是為了充分利用部分寶貴的人力資源，讓這些人從繁雜的文檔化工作中解放出來。“最好的”團隊結構取決于組織的管理風格、團隊里的人員數目與技能水平，以及問題的總體難易程度。Mantei提出了規劃軟件工程團隊結構時應考慮的7個項目因素：(1)待解決問題的難度；(2)開發程序的規模，以代碼行或者功能點來度量；(3)團隊成員需要共同工作的時間(團隊生存期)；(4)能夠對問題做模塊化劃分的程度；(5)待開發系統的質量要求和可靠性要求；(6)交付日期的嚴格程度；(7)項目所需要的友好交流的程度。軟件開發步驟與開發團隊中的角色的對應關系如圖1.4所示。1.3軟件工程發展中的軟件開發方法與技術從20世紀50年代開始至今，軟件的開發方法與技術都有了迅猛的發展，具體如下。1.?20世紀50年代20世紀50年代，人們的主要精力集中在硬件上，所以沒有出現專門針對軟件開發方法與技術的需求，也就沒有出現被普遍使用的軟件開發方法與技術。20世紀50年代的軟件工程的特點是：科學計算；以機器為中心進行編程；像生產硬件一樣生產軟件。2.?20世紀60年代由于缺乏正確科學知識的指導，也沒有多少經驗原則可以遵循，因此，20世紀60年代的軟件開發在總體上依靠程序員的個人能力，是“工藝式”的開發。20世紀60年代的軟件工程的特點是：業務應用；軟件不同于硬件；用軟件工藝的方式生產軟件。3.?20世紀70年代基于結構化程序設計理論，20世紀70年代早期開始廣泛使用結構化編程方法，它要求使用函數(過程)構建程序，使用塊結構和三種基本控制結構(消除goto語句)仔細組織函數(過程)的代碼，使用程序流程圖描述程序邏輯進行程序設計，使用逐步精化(StepwiseRefinement)、自頂向下的軟件開發方法進行軟件開發。到了20世紀70年代中后期，結構化方法從編程活動擴展到分析和設計活動，圍繞功能分解思想和層次模塊結構，使用數據流圖(DFD)、實體關系圖(ERD)和結構圖(StructureChart)，建立了結構化設計、結構化分析、Jackson結構程序設計(JSP)等結構分析與設計方法。控制復雜系統的復雜性是20世紀70年代追求的目標，這需要超越函數(程序)的層次，因為它的粒度太小。因此，20世紀70年代人們開始在更高抽象的模塊層次上探索控制復雜性的方法，產生了“低耦合高內聚”的模塊化、信息隱藏、抽象數據類型等重要思想，它們逐漸被吸收進結構化方法并推動了20世紀80年代面向對象編程的出現。20世紀70年代的軟件工程的特點是：結構化方法；瀑布模型；強調規則和紀律。它們奠定了軟件工程的基礎，是后續軟件工程發展的支撐。4.?20世紀80年代在20世紀80年代重要的技術中，除了少數是延續70年代的工作之外，大多數都是為了滿足提高生產力的要求而產生的。1)結構化方法20世紀70年代中后期基于結構化編程建立了早期的結構化方法，包括結構化分析與結構化設計。但是這時的結構化方法因為剛剛脫離編程，所以更多地還在關注軟件程序的構建。也就是說，20世紀70年代中后期的結構化分析和設計更強調為了最后編程而進行分析與設計，而不是為了解決現實問題而進行分析與設計。到了20世紀80年代，隨著結構化分析與設計向結構化編程的過渡，人們逐步開始將結構化分析與設計的關注點轉向問題解決和系統構建，產生了現代結構化方法，代表性的有信息工程(InformationEngineering)、Jackson系統開發(JSD)、結構化系統分析與設計方法(SSADM)、結構化分析和設計技術(SADT)及現代結構化分析(MSA)。相對于早期的結構化方法，20世紀80年代的現代結構化方法更注重系統構建而不是程序構建，所以更重視問題分析、需求規格和系統總體結構組織而不是讓分析與設計結果符合結構化程序設計理論，更重視階段遞進的系統化開發過程，而不是一切圍繞最后的編程進行。2)面向對象編程最早的面向對象編程思想可追溯到20世紀60年代的Simular-67語言，它是為了仿真而設計的程序設計語言，使用了類、對象、協作、繼承、多態(子類型)等最基礎的面向對象概念。20世紀70年代的Smalltalk就是完全基于面向對象思想的程序設計語言，它強化了一切皆是對象和對象封裝的思想，發展了繼承和多態。到了20世紀80年代中后期，隨著C++?的出現和廣泛應用，面向對象編程成為程序設計的主流。C++?只是在C語言中加入面向對象的特征，并不是純粹的面向對象語言。C++?保留了C的各種特性，這種謹慎的設計使得程序員可以順利地接受它，另一方面是因為面向對象語言支持復用和更適于復雜軟件開發的特點符合了20世紀80年代的生產要求。需要特別指出的是，雖然面向對象的概念起源很早，并且很多思想與結構化思想是完全不同的，但是面向對象本身不像結構化一樣有基于數學的程序設計理論的支撐，所以它是在吸收了很多結構化方法中發展出來的方法與技術之后才得到了程序正確性、清晰性和高質量的保障。Booch認為模塊化、信息隱藏等設計思想和數據庫模型的進步都是促使面向對象概念演進的重要因素。與結構化方法相比，面向對象方法中的結構和關系能夠為領域應用提供更加自然的支持，使得軟件的可復用性和可修改性更加強大。可復用性滿足了20世紀80年代追求生產力的要求，尤其是提高了圖形用戶接口(GUI)編程的生產力，這也是推動面向對象編程發展的重要動力。可修改性提高了軟件維護時的生產力。面向對象方法也為模塊內高內聚和模塊間低耦合提供了更好的抽象數據類型的模塊化，更加適合于復雜軟件系統的開發。3)軟件復用提高生產力的一種方式是避免重復生產，所以在20世紀80年代人們為了追求生產力，開始重視軟件復用。實踐經驗表明，軟件復用是提高生產力最有效的方法，可以將生產力提高10%～35%。除了面向對象方法之外，第4代語言、購買商用組件、程序生產器等都是20世紀80年代提出的能夠促進軟件復用的技術。20世紀80年代的軟件工程的特點是：追求生產力最大化；現代結構化方法/面向對象編程廣泛應用；重視過程的作用。5.?20世紀90年代1)面向對象方法與結構化編程的成功促進了結構化分析與設計方法的產生一樣，面向對象編程的成功也促進了面向對象分析與設計方法在20世紀90年代的產生，并促使面向對象分析與設計方法迅速被廣泛使用。20世紀90年代的面向對象方法的具體進展有：(1)出現了對象建模技術(OMT)、Booch方法、面向對象的軟件工程(OOSE)、類-責任-合作者(CRC)卡等一系列面向對象的分析與設計方法。(2)統一的面向對象建模語言UML的建立和傳播。(3)設計模式、面向對象設計原則等有效的面向對象實踐經驗被廣泛傳播和應用。2)軟件體系結構20世紀70年代開發復雜軟件系統的初步嘗試使得人們明確和發展了獨立的軟件設計體系，提出了模塊化、信息隱藏等最為基礎的設計思想。到了20世紀80年代中期，這些思想逐漸成熟，并且成功融入了軟件開發過程。這時，一些新的探索就出現了，其中包括面向對象設計，也包括針對大規模軟件系統設計的一些總結與思考。在對大規模系統的設計經驗進行總結時，人們發現越來越需要有一種更高抽象層次的設計體系來進行思想的匯總與提升。于是，研究者們在20世紀90年代初期正式提出了“軟件體系結構”這一主題，并結合90年代之后出現的軟件系統規模日益擴大的趨勢，在其后的10年中對其進行了深入的探索與研究。人們在體系結構的基本內涵、風格、描述、設計、評價等方面開展了卓有成效的工作，在21世紀初建立了一個比較系統的軟件體系結構方法體系。軟件體系結構使用部件、連接件和配置三個高抽象層次的邏輯單位，關注如何將大批獨立模塊組織形成一個“系統”而不是各個模塊本身，也就是說更重視系統的總體組織。軟件體系結構成為大規模軟件系統開發中處理質量屬性和控制復雜性的主要手段，改變了大規模軟件系統的開發方式，提高了大規模軟件系統開發的成功率和產品質量。3)人機交互為了吸引更多的用戶，贏得市場競爭，人們在20世紀90年代開始重視人機交互，提出“以用戶為中心”(User-CenteredDesign)的設計方法。人機交互的基本目標是開發更加友好的軟件產品，最低標準是讓普通人在使用軟件產品時比較順暢，較高標準是讓用戶在使用產品時感到滿足和愉悅。從20世紀50年代開始人機交互技術就一直在發展，但是直到90年代人們才開始重視如何將人機交互技術融入軟件工程，并建立了一些人機交互的軟件工程方法，包括快速原型、參與式設計、各種人機交互指導原則等。4)需求工程自“瀑布模型”起，人們就已經認識到并強調了需求分析的作用。但是，到了20世紀90年代，隨著“以企業為中心”軟件系統規模的增長，人們認識到需求處理除了核心的需求分析活動之外，還有其他的活動也需要慎重對待，要進行“需求工程”，即利用工程化的手段進行需求處理，以保證需求處理的正確進行。相比于傳統的需求分析，需求工程將用戶價值分析視為基本要求，重視產品分析、問題與目標分析、業務分析、與用戶的交流和溝通等。需求工程本質上反映了應用軟件與現實之間的聯系日益增強的事實。5)基于軟件復用的大規模軟件系統開發技術在大規模軟件系統開發中，為了解決復雜度與開發周期的兩難局面，人們充分利用了軟件復用思想，建立了多種基于軟件復用的大規模軟件系統開發技術，其中最為流行的是框架(Framework)和構件(Component)。框架是領域特定的復用技術。它的基本思想是根據應用領域的共性和差異性特點，建立一個靈活的體系結構，并實現其中比較固定的部分，留下變化的部分等待開發者補充。簡單地說，框架開發者完成了框架的總體設計和部分開發工作，然后將未開發的部分留作空白，等待框架的使用者填充。20世紀90年代，很多應用領域都建立了自己的開發框架。構件是在代碼實現層次上進行復用的技術。它的基本思想是給所有的構件定義一個接口標準，就像機械工程定義螺絲和螺母的標準規格一樣，這樣就可以忽略每個構件內部的因素，實現不同構件之間的通信和交互。構件通常是黑盒的二進制代碼，帶有專門的說明書，可以像機器零件那樣被獨立生產、銷售和使用。組件對象模型(COM)和JavaBean就是20世紀90年代產生并流行起來的構件標準。6)?Web開發技術Web應用的開發技術不同于傳統軟件形式。在20世紀90年代早期，人們主要使用HTML開發靜態的Web站點。到了90年代中后期，動態網頁技術、JSP、超文本預處理器、JavaScript等動態Web開發技術開始流行。人們建立了Web程序的數據描述標準XML。20世紀90年代軟件工程的特點是：以企業為中心的大規模軟件系統開發；追求快速開發、可變更性和用戶價值；Web應用出現。6.?21世紀00年代1)延續20世紀90年代的技術進展20世紀90年代產生的一些重要技術，在21世紀00年代繼續得到發展和完善：(1)軟件體系結構：到了2000年，軟件體系結構設計方法基本成熟，2000年之后開始廣泛使用。軟件體系結構的研究和探索工作繼續深入，轉向軟件體系結構設計決策的描述和產生過程。(2)需求工程：2000年之后的軟件需求工程逐漸與系統工程相融合，典型表現是越來越重視系統需求而不是軟件需求的分析，包括目標分析、背景環境分析、系統屬性分析等。(3)人機交互：隨著Web應用和小型設備應用越來越突出，21世紀前10年人機交互將Web的人機交互和小型設備的人機交互作為工作重點。(4)基于復用的大型軟件系統開發技術：Struts、Spring等針對Web的開發框架成為軟件開發的主流工具；更適應Web的WebService構件類型被應用得越來越廣泛。2)?Web技術發展隨著Web的發展，21世紀前10年的很多技術進展都與Web有關：(1)?20世紀90年代產生的各種動態Web開發技術成為軟件開發必不可少的部分。(2)適用于Web開發的構件中間件平臺?.NET和J2EE成為軟件開發的主流平臺。(3)瀏覽器/服務器模式(B/S)、N-Tier、面向服務的架構(SOA)、消息總線等適合于Web應用的體系結構風格被廣泛傳播。(4)針對Web的開發框架成為主流的軟件開發工具。(5)博客、即時通信等Web2.0技術出現并得到廣泛應用。3)領域特定的軟件工程方法 該方法從20世紀90年代開始出現，在21世紀前10年，軟件工程方法分領域深入成為主流。在技術領域方面，下列技術領域都出現了明顯的進展：(1)以網絡為中心的系統；(2)信息系統；(3)金融和電子商務系統；(4)高可信系統；(5)嵌入式和實時系統；(6)多媒體、游戲和娛樂系統；(7)小型移動平臺系統。在應用領域方面，越來越多的領域開始根據自身特點定義參照體系結構、開發框架、可復用構件和領域特定的編程語言。面向應用領域進行軟件開發的產品線(ProductLine)方法得到了越來越多的關注和使用。21世紀前10年軟件工程的特點是：大規模Web應用；大量面向大眾的Web產品；追求快速開發、可變更性、用戶價值和創新。1.4計算機輔助軟件工程計算機輔助軟件工程(CASE)是一組工具和方法的集合，用于輔助軟件開發、維護、管理過程中的各項活動，促進軟件過程的工程化和自動化，實現高效率和高質量的軟件開發。如今，CASE工具已經由支持單一任務的單個工具向支持整個開發過程的集成化軟件工程環境的方向發展，同時重視用戶界面的設計，不斷采用新理論和新技術，成為軟件工程領域的一個重要分支。CASE環境的組成構件如圖1.5所示。CASE環境應用應具有以下功能：(1)提供一種機制，使環境中的所有工具可以共享軟件工程信息。(2)每一個信息項的改變，可以追蹤到其他相關信息項。(3)對所有軟件工程信息提供版本控制和配置管理。(4)對環境中的任何工具可進行直接的、非順序的訪問。(5)在標準的分解結構中提供工具和數據的自動支持。(6)使每個工具的用戶共享人機界面的所有功能。(7)收集能夠改善過程和產品的各項度量指標。(8)支持軟件工程師之間的通信。目前，市場上有許多商業化的CASE工具，它們在一定程度上促進了軟件過程的工程化。1.5軟件工程與其他相關學科的關系軟件工程是一門交叉性的工程學科，如圖1.6所示。軟件工程以計算機科學和數學為基礎，將這些學科的基本原理應用于構造軟件的模型與算法，力求提出更系統化和更形式化的軟件開發方法，并采用適當的方法驗證即將開發的軟件。正確的軟件開發實踐更重要的是將工程化的原則和方法應用于軟件的分析與評價、規格說明、設計、實現、演化等過程。軟件工程運用工程科學的基本原理，結合特定領域的基礎知識和相關的專業知識，通過評估成本與確定權衡提出合理的問題解決方案，在軟件開發實踐的基礎上總結制定標準與規范，重用設計和設計制品。事實證明，成功的軟件開發往往離不開規范化的開發管理。軟件工程將管理科學應用于軟件開發的計劃、資源、質量、成本等管理，協調和控制整個過程與項目的進展，組織和建設開發團隊，實施風險分析和變更管理，最終實現軟件開發的目標。需要強調的是，由于軟件自身的特殊性，使得軟件工程與傳統工程存在著明顯的區別，它更強調抽象、建模、信息組織與表示以及變更管理，另外還包括軟件開發過程的質量控制活動，而且持續的演變(即“維護”)也尤為重要。1.6軟件工程職業道德規范職業道德是所有從業人員應當具備的最基本的道德素養，也是這些人員在其職業活動中應當遵循的最基本的行為準則。IEEE-CS和ACM聯合制定了《軟件工程職業道德和職業行為準則》，包括有關專業軟件工程師行為和決斷的8項原則，要求軟件工程人員應履行其實踐承諾，使軟件的需求分析、規格說明、設計、開發、測試和維護成為一項對社會有益和受人尊敬的職業。軟件工程師應當遵循的8項原則如下：(1)公眾：軟件工程人員應始終與公眾利益保持一致。(2)客戶和雇主：在與公眾利益保持一致的原則下，軟件工程人員應滿足客戶和雇主的最大利益。(3)產品：軟件工程人員應當確保他們的產品及其改進符合盡可能高的專業標準。(4)判斷：軟件工程人員應當具備公正和獨立的職業判斷力。(5)管理：軟件工程管理者和領導者應擁護和倡導合乎道德的有關軟件開發和維護的管理方法。(6)職業：在與公眾利益一致的原則下，軟件工程人員應當提高職業的信譽。(7)同行：軟件工程人員對其同行應持平等和支持的態度。(8)自我：軟件工程人員應當終身學習專業知識，促進合乎道德的職業實踐方法。1.7軟件項目成敗情況統計在20世紀90年代出現的大量軟件生產狀況調查中，以StandishGroup的CHAOS系列最引人注目。StandishGroup是美國的一家咨詢公司，它于1993年開始展開軟件狀況的調查，并隨后發布了一系列的調查報告，稱為CHAOS系列。在StandishGroup的調查中，將軟件項目分為以下3種類別：(1)在預計的時間之內，在預算的成本之下，完成預期的所有功能，則項目為成功項目(Success)。(2)已經完成，軟件產品能夠正常工作，但在生產中或者超支，或者超期，或者實現的功能不全，則項目為問題項目(ChallengedorFaulty)。(3)因無法進行而被中途撤銷，或者最終產品無法提交使用，則項目為失敗項目(FailedorImpaired)。1.8全球軟件產業的現狀、趨勢與挑戰目前，美國掌握全球軟件產業核心技術。從產業鏈角度的競爭格局來看，當前世界軟件市場形成了以美國、歐洲、印度、日本、中國等國為主的國際軟件產業分工體系，世界軟件產業鏈的上游、中游和下游鏈條分布逐漸明晰。全球軟件市場競爭格局如表1.4所示。從全球軟件行業的區域競爭狀況來看，主要存在國際化競爭日趨激烈、軟硬件結合更加緊密、定制和通用產品兩極化、資本重要性漸強等發展趨勢。中國的微信、抖音、支付寶、鴻蒙系統等軟件的開發和應用，說明我國的軟件產品已取得世界領先地位，但在芯片核心技術等“卡脖子”領域，我們還要奮起直追。只有依靠科技自立自強才能贏得未來。2.1軟件生命周期

2.2軟件過程的概念

2.3幾種典型的軟件過程模型

2.4微軟公司的軟件開發過程2.1軟件生命周期我國國家標準《計算機軟件文檔編制規范》(GB/T8567—2006)把軟件生命周期劃分為可行性與計劃研究階段、需求分析階段、設計階段、實現階段、測試階段、運行與維護階段六個階段。通常，人們把可行性與計劃研究階段、需求分析階段這兩個階段稱為軟件定義時期，把設計階段、實現階段、測試階段這三個階段稱為軟件開發時期，而把運行與維護階段稱為軟件運行與維護時期。軟件生命周期各個時期及階段的關系如圖2.1所示。2.1.1軟件生命周期中時期與階段的劃分以及各階段的任務1.軟件定義時期在軟件生命周期中，軟件定義時期又可分為可行性與計劃研究和需求分析兩個階段。1)可行性與計劃研究階段在可行性與計劃研究階段主要完成以下工作：(1)要確定該軟件的開發目標和總的要求。(2)要進行可行性分析。(3)投資-收益分析。(4)制訂開發計劃。(5)完成可行性分析報告。(6)完成開發計劃等文檔。2)需求分析階段在需求分析階段內，由系統分析人員對被設計的系統進行系統分析，確定該軟件的各項功能、性能需求和設計約束，確定文檔編制的要求。作為本階段工作的結果，一般地說軟件需求規格說明(也稱為軟件需求說明、軟件規格說明)、數據要求說明和初步的用戶手冊應該編寫出來，主要包括：(1)需求調查：對軟件的需求及其使用環境進行詳細調查，掌握用戶的要求和環境所能提供的條件。(2)功能、性能與環境約束分析：根據掌握的情況，對軟件系統的功能(即回答系統必須做什么)、性能(包括軟件的安全性、可靠性、可維護性、精度、錯誤處理、適應性、用戶培訓等)和環境約束(指待開發的軟件系統必須滿足運行環境方面的要求)進行分析研究，與用戶取得一致的認識。(3)編制軟件需求規格說明：把軟件系統的功能需求、性能需求、接口需求、設計需求、基本結構、開發標準、驗收原則等寫成軟件需求規格說明，并得到用戶的確認。(4)制定軟件系統的確認測試準則和用戶手冊概要：根據確認的軟件開發標準及驗收原則制定具體的軟件確認測試準則和用戶手冊概要或提綱。2.軟件開發時期軟件開發時期主要包括設計階段、實現階段以及測試階段。1)設計階段在設計階段內，系統設計人員和程序設計人員應該在反復理解軟件需求的基礎上，提出多個設計，分析每個設計能履行的功能并進行相互比較，最后確定一個設計，包括該軟件的結構、模塊(或CSCI)的劃分、功能的分配以及處理流程。在被設計系統比較復雜的情況下，設計階段應分解成概要設計階段和詳細設計階段兩個步驟。在一般情況下，應完成的文檔包括：軟件(結構)設計說明、詳細設計說明和測試計劃初稿。(1)概要設計階段包括以下工作：①建立軟件系統的總體結構。②定義功能模塊的接口。③設計全局數據庫和數據結構。④規定設計約束。⑤編制概要設計文檔。(2)詳細設計階段包括以下工作：①模塊詳細設計。②編制模塊的詳細規格說明。2)實現階段在實現階段內，要完成源程序的編碼、編譯(或匯編)和排錯調試，得到無語法錯的程序清單，要開始編寫進度日報、周報和月報，并且要完成用戶手冊、操作手冊等面向用戶的文檔的編寫工作，還要完成測試計劃的編制。(1)編碼：根據模塊詳細規格說明書，將詳細設計轉化為程序代碼。(2)單元測試：對模塊程序進行測試，驗證模塊功能及接口與詳細設計文檔的一致性，并形成單元測試報告。3)測試階段在測試階段：該程序將被全面地測試，已編制的文檔將被檢查審閱。一般要完成測試分析報告。作為開發工作的結束，所生產的程序、文檔以及開發工作本身將逐項被評價，最后寫出項目開發總結報告。測試階段包括組裝測試階段和確認測試階段。在整個開發過程中(即前五個階段中)，開發集體要按月編寫開發進度月報。(1)組裝測試階段包括以下工作：①模塊程序組裝與測試。②編制組裝測試報告。(2)確認測試階段包括以下工作：①軟件系統測試。②編制確認測試文檔。③軟件評審。3.軟件運行與維護時期在運行和維護階段，軟件將在運行使用中不斷地被維護，根據新提出的需求進行必要而且可能的擴充、刪改、更新和升級。(1)軟件的使用階段：將軟件安裝在用戶確定的運行環境中使用。(2)軟件的維護階段：對軟件產品進行修改或根據軟件需求變化做出響應，并對所有的維護寫出維護報告。(3)軟件的退役階段：軟件一旦完成了其使命，或者由于一個新的軟件生命周期的開始，就要終止對軟件產品的支持，這使得軟件停止使用。2.1.2軟件生命周期中各階段所占的百分比軟件生命周期中各階段所占的百分比和各階段的參與人員如表2.1所示。2.1.3軟件生命周期中各階段的文檔在軟件生存周期中，一般應產生以下基本文檔：(1)可行性分析(研究)報告；(2)軟件(或項目)開發計劃；(3)軟件需求規格說明；(4)接口需求規格說明；(5)系統/子系統設計(結構設計)說明；(6)軟件(結構)設計說明；(7)接口設計說明；(8)數據庫(頂層)設計說明；(9)?(軟件)用戶手冊；(10)操作手冊；(11)測試計劃；(12)測試報告；(13)軟件配置管理計劃；(14)軟件質量保證計劃；(15)開發進度月報；(16)項目開發總結報告；(17)軟件產品規格說明；(18)軟件版本說明等。2.1.4各類人員使用的文檔說明各類人員所使用的文檔如表2.2所示。2.2軟件過程的概念2.2.1軟件過程的定義軟件過程是用以開發和維護軟件及其相關產品的一系列方法、實踐、活動和轉換，包括軟件工程活動和軟件管理活動。2.2.2軟件過程的基本活動一般的軟件過程包括問題提出、軟件需求說明、軟件設計、軟件實現、軟件確認、軟件演化等基本活動。(1)問題提出：開展技術探索、市場調查等活動，研究系統的可行性和可能的解決方案，確定待開發系統的總體目標和范圍。(2)軟件需求說明：分析、整理和提煉所收集到的用戶需求，建立完整的分析模型，編寫軟件需求規格說明和初步的用戶手冊。通過評審需求規格說明，確保對用戶需求達到共同的理解與認識。(3)軟件設計：根據軟件需求規格說明文檔，確定軟件的體系結構，再進一步設計每個系統部件的實現算法、數據結構、接口等，編寫軟件設計說明書，并組織進行設計評審。(4)軟件實現：將所設計的各個子系統編寫成計算機可接受的程序代碼。(5)軟件確認：在設計測試用例的基礎上，測試軟件的各個組成模塊，并將各個模塊集成起來，測試整個產品的功能和性能是否滿足已有的規格說明。(6)軟件演化：整個軟件過程是一個不斷演化的過程，軟件開發覆蓋從概念的提出到形成一個可運行系統的整個過程，軟件維護則是系統投入使用后所產生的修改。2.2.3軟件過程的制品在軟件過程的不同階段，會產生不同的軟件制品，如需求規格說明書、設計說明書、源程序代碼與構件、測試用例、用戶手冊以及各種開發管理文檔等，表2.3列出了軟件過程的一些基本活動以及所產生的主要過程制品。2.2.4軟件項目從立項到結題的過程通常情況下，一個軟件項目從立項到結題要經過不同的階段，每個階段要完成相應的文檔。雖然每個企業最終形成的文檔不盡相同，但都是根據企業的實際情況，在國家標準的基礎之上進行適當刪減的結果，其基本內容如下。1.撰寫立項申請書一個項目要通過填報項目申報書，經相關部門的專家評審通過后才予以立項。2.簽署立項合同一個項目通過專家評審予以立項后，就要與立項相關部門簽署合同，該合同具有法律效力。3.撰寫開題報告雙方簽訂好合同后，在一個月內要完成項目開題及開題報告的撰寫并在相關專家的參與下完成開題工作。4.撰寫中期檢查報告項目進展到中期時，要接受相關部門的檢查，考核是否按任務書中的進度完成了該時間點應該完成的工作。5.撰寫項目結題報告書及項目開發總結報告項目完成時，需要撰寫項目結題報告及項目開發總結報告。項目開發總結報告的編制是為了總結本項目開發工作的經驗，說明實際取得的開發結果以及對整個開發工作的各個方面的評價。6.項目驗收提交項目驗收相關文檔后，在規定的時間內，相關部門對項目進行驗收。7.發結題證書項目驗收合格后，由相關部門在規定的時間內頒發結題證書。至此，該項目最終結題。2.3幾種典型的軟件過程模型2.3.1瀑布模型瀑布模型規定了各項軟件工程活動，包括制訂開發計劃、進行需求分析和說明、軟件設計、程序編碼、測試及運行維護。瀑布模型還規定了它們自上而下、相互銜接的固定次序，如同瀑布流水一樣逐級下落，如圖2.2所示。瀑布模型的基本思想：根據軟件生命周期中各階段的任務，從可行性研究與計劃開始，逐步進行階段性變換，直至通過確認測試并得到用戶確認的軟件為止。瀑布模型的特點如下：(1)階段間的順序性和依賴性：上一階段的變換結果是下一階段變換的輸入，相鄰兩個階段具有因果關系，每個階段完成任務后，都必須進行階段性評審，確認之后再轉入下一個階段。(2)文檔驅動性：要求每個階段必須完成規定的文檔并通過評審，以便盡早發現問題，改正錯誤。瀑布模型的優點：可強迫開發人員采用規范的方法，嚴格提交文檔，做好階段評審，從而使軟件過程易于管理和控制，有利于軟件的質量保障。瀑布模型的缺點：要求軟件開發初期就要給出軟件系統的全部需求，開發周期比較長，承擔的風險也比較大。軟件開發的實踐表明，上述各項活動之間并非完全是自上而下，呈線性圖式。實際情況是，每項開發活動均處于一個質量環(輸入—處理—輸出—評審)中。只有當其工作得到確認，才能繼續進行下一項活動，在圖2.2中用向下的箭頭表示；否則返工，在圖2.2中由向上的箭頭表示。2.3.2快速原型模型快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟件的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什么。第二步則在第一步的基礎上開發客戶滿意的軟件產品。顯然，快速原型方法可以克服瀑布模型的缺點，減少由于軟件需求不明確帶來的開發風險，具有顯著的效果，如圖2.3所示。快速原型的關鍵在于盡可能快速地建造出軟件原型，一旦確定了客戶的真正需求，所建造的原型將被丟棄。因此，原型系統的內部結構并不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。快速原型模型的基本思想：軟件開發人員根據用戶提出的軟件初步定義，快速開發一個原型，向用戶展示原型的功能和性能，在反復征求用戶對原型意見的過程中，進一步確認用戶的需求并對原型進行修改和完善，直到得到用戶確認的軟件定義，在確認的原型基礎上完成軟件系統的設計、實現、測試和使用與維護。快速原型模型的特點如下：(1)原型驅動：整個軟件過程圍繞著原型的快速開發和對原型的評價，通過原型確認用戶需求，以及通過原型的反復修改最終得到用戶確認的軟件定義。(2)過程的交互性和迭代性：軟件過程是由開發人員與用戶之間通過原型的評價和確認而進行的一個交互過程。而且這個過程不是簡單的重復，而是不斷改進和完善的迭代過程。快速原型模型的優點：允許用戶在軟件開發過程中完善對軟件系統的需求，開發周期相對有所縮短，成本比較低，有效地發揮用戶和開發人員之間的密切配合作用，使軟件過程更能體現逐步發展、逐步完善的原則。快速原型模型的缺點：頻繁的需求變化會使開發進程難于管理和控制，原型的快速開發和修改對技術要求比較高，需要有較好的工作基礎。2.3.3螺旋模型對于復雜的大型軟件，開發一個原型往往達不到要求。螺旋模型將瀑布模型與快速原型模型結合起來，并且加入兩種模型均忽略了的風險分析。螺旋模型沿著螺線旋轉，如圖2.4所示，在笛卡爾坐標的4個象限上分別表達了以下4個方面的活動：(1)制訂計劃——確定軟件目標，選定實施方案，弄清項目開發的限制條件；(2)風險分析——分析所選方案，考慮如何識別和消除風險；(3)實施工程——實施軟件開發；(4)客戶評估——評價開發工作，提出修正建議。沿螺線自內向外每旋轉一圈便開發出更為完善的一個新的軟件版本。螺旋模型的基本思想：螺旋模型是瀑布模型和快速原型模型的結合，其基本思想是借助構建原型來降低風險，把軟件開發的每一個階段都看作是增加了風險分析的快速原型模型。螺旋模型的每一個周期都包括需求定義、風險分析、工程實現和評審4個部分，軟件開發的整個過程就是這4個部分的迭代，每迭代一次，過程就完成一個周期，軟件開發就前進一個層次，系統就生成一個新的版本。螺旋模型的特點如下：(1)模型結合性：螺旋模型的每一個周期都應用了原型模型排除風險，在確認了原型之后，又啟動瀑布模型繼續過程的演化。因此，螺旋模型是瀑布模型和快速原型模型的結合，體現了兩個模型的優點。(2)過程迭代性：軟件開發過程的每個階段都是一次迭代，這種迭代不是過程的簡單重復，而是每旋轉一個圈就前進一個層次，得到一個新的版本。螺旋模型的優點：強調可選方案和約束條件有利于已有軟件的重用，有助于把軟件質量作為軟件開發的一個重要目標，減少過多或測試不足帶來的風險。維護被看成是模型的另一個周期，維護和開發之間沒有本質的區別。螺旋模型的缺點：要求軟件開發人員具有豐富的風險評估經驗和有關的專門知識，開發過程比較復雜，給過程管理和控制帶來一定的難度。2.3.4增量模型在增量模型中，軟件被作為一系列的增量構件來設計、實現、集成和測試，每一個構件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構成的。增量模型在各個階段并不交付一個可運行的完整產品，而是交付滿足客戶需求的一個子集的可運行產品。整個產品被分解成若干個構件，開發人員逐個構件地交付產品，這樣做的好處是軟件開發可以較好地適應變化，客戶可以不斷地看到所開發的軟件，從而降低開發風險，如圖2.5所示。增量模型也存在以下缺陷：(1)由于各個構件是逐漸并入已有的軟件體系結構中的，因此加入構件必須不能破壞已構造好的系統部分，這需要軟件具備開放式的體系結構。(2)在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性。在使用增量模型時，第一個增量往往是實現基本需求的核心產品。核心產品交付用戶使用后，經過評價形成下一個增量的開發計劃，它包括對核心產品的修改和一些新功能的發布。這個過程在每個增量發布后不斷重復，直到產生最終的完善產品。增量模型的基本思想：把軟件產品作為一系列的增量構件來設計、實現、集成和測試。開發時分批逐步向用戶提交產品，每次提交一個滿足用戶需求子集的增量構件，直到最后一次得到滿足用戶全部需求的完整產品為止。增量模型的特點：過程漸進性，即軟件過程分批次完成，每次提交一個滿足用戶需求子集的增量構件，產品規模逐漸增大，直到得到滿足用戶全部需求的完整產品為止。增量模型的優點：能在較短的時間內向用戶提交部分功能的構件，并且在逐步增加產品功能的過程中有充裕的時間學習和適應新的功能，減少一個全新軟件可能給用戶帶來的沖擊。增量模型的缺點：增量構件的劃分依賴于系統功能的構成和軟件開發人員的經驗，每次集成新的增量構件必須不能破壞原有軟件系統的結構，因此要求軟件系統的體系結構必須具有高度的開放性和可擴充性。2.3.5噴泉模型噴泉模型對軟件復用和生存周期中多項開發活動的集成提供了支持，主要支持面向對象的開發方法。“噴泉”一詞本身體現了迭代和無間隙特性。系統某個部分常常重復工作多次，相關功能在每次迭代中隨之加入演進的系統。所謂無間隙是指在開發活動，即分析、設計和編碼之間不存在明顯的邊界，如圖2.6所示。噴泉模型的基本思想：噴泉模型是典型的面向對象生命周期模型。“噴泉”這個詞描述了面向對象軟件開發過程的迭代和無縫特性。在噴泉模型中，代表開發過程不同階段的圓圈之間互相交疊，而且各項開發活動之間是無縫過渡的。每個階段內的向下箭頭代表著階段自身的迭代或求精，整個軟件過程呈現一種開發階段沿中軸向上，又在每一個階段向下回流的噴泉形態，所以稱為噴泉模型。噴泉模型的特點：(1)過程迭代性：在面向對象的方法中，軟件開發各個階段之間或一個階段內的各個步驟之間都存在迭代的過程，這一點要比面向數據流或面向數據的方法更為常見。(2)階段間的無間隙過渡性：用面向對象方法開發軟件時，在分析、設計、編碼等項開發活動之間并不存在明顯的邊界，不同階段互相交疊，各項開發活動之間無縫過渡。噴泉模型的優點：支持面向對象方法的軟件開發過程，提供軟件復用與生命周期中多項開發活動集成的機制。噴泉模型的缺點：噴泉模型本身就不是以面向過程為背景的，過程在噴泉模型中已被弱化，取而代之的是無間隙的階段過渡與重復迭代。2.3.6V形模型V形模型是瀑布模型的一個變種，如圖2.7所示。它同樣需要一步一步進行，前一個階段的任務完成之后才可以進行下一階段的任務。這個模型強調測試的重要性，它將開發活動與測試活動緊密地聯系在一起。每一步都將比前一階段進行更加完善的測試。V形模型的特點如下：(1)簡單易用，只要按照規定的步驟一步一步執行即可。(2)?V形模型強調測試過程與開發過程的對應性和并行性。(3)?V形模型沒有反映實際的開發過程，實際的開發過程會有很多的迭代過程，比如，實施過程中會發現設計中的問題，然后去修正，測試過程中也會返回前一段，重新做一些事情。V形模型使用指南：使用V形模型，要求開發過程嚴格按照順序進行，一個階段的輸出是下一個階段的輸入。同時，要并行考慮圖2.7中虛線所對應的過程。V形模型適合的場合：項目的需求在項目開始前很明確，解決方案在項目開始前也很明確，項目對系統的性能安全要求很嚴格。2.3.7形式化方法模型形式化方法模型特別適合于那些對安全性、可靠性和保密性要求極高的軟件系統開發，它采用形式化的數學方法將系統描述轉換成可執行的程序。形式化方法的過程模型如圖2.8所示，它首先將軟件需求描述提煉成采用數學符號表達的形式化描述，然后經過一系列的形式化轉換將形式化描述自動轉換成可執行程序，最后將整個系統集成起來進行測試。由于數學方法具有嚴密性和準確性，因此形式化方法開發過程所交付的軟件