教師：張為電話Q：2634422548軟件工程

2023/2/62為什么要學習軟件工程2023/2/632023/2/64為什么要學習這門課程正確理解和認識“軟件”的概念及其特點正確地理解,領悟和掌握軟件工程方法學掌握軟件工程的原則、方法和思想來系統地開發軟件，尤其是復雜、龐大軟件的開發了解和接觸各種軟件開發技術和工具培養和他人相互合作進行軟件開發、獨立解決問題的能力培養通過多種手段獲取新知識的能力培養邏輯思維能力,尤其是抽象能力軟件工程是軟件技術和管理人員必備的課程如何學習這門課程理論和實踐的結合

-->課題實習內容小組形式軟件開發過程驗收內容和標準（項目開發計劃、可行性研究報告、需求規格說明書、概要設計說明書、詳細設計說明書、測試計劃、測試分析報告、用戶操作手冊、項目開發總結報告、程序維護手冊、軟件修改報告、軟件問題報告、源代碼等文檔

）軟件工程目的體驗軟件工程各階段的主要工作，特別注意吸取教訓；

學會與他人合作，培養團隊精神，單干戶將得不到成績。有何意義？■本課將是學習以下課程的基礎綜合課程設計專業實習畢業設計■實際應用參與單位軟件系統建設工作參與軟件開發第一章軟件與軟件工程1.1軟件的概念1.2軟件工程的概念1.3軟件過程模型1.4敏捷軟件開發原則和應用1.5軟件工程人的因素9待增內容軟件系統及軟件元素系統子系統模塊/包構件/組件/中間件類屬性/方法/操作變量/運算新增內容：軟件過程測試（V模型）測試計劃測試需求測試設計邏輯設計數據/測試用例（輸入/輸出）設計測試編碼測試運行及報告測試總結及展望新增內容：編號文檔編號為閱讀定位而對根據文檔章節結構編號隨機文檔結構調整而改變本體編號因對工作內容本體識別需要而引入的標識符隨著本體的識別而產生終身不變常用符號前綴REQ:需求DGN:設計TST:測試1.1.1軟件與軟件的組成計算機科學對軟件的定義軟件是在計算機系統支持下,能夠完成特定功能和性能的程序、數據和相關的文檔

軟件可形式的表示為：

軟件=知識+程序+數據+文檔2023/2/6131.1軟件的概念程序：用計算機程序設計語言描述的。數據：程序加工的對象和結果。文檔：錄軟件開發的活動和中間制品，記錄軟件配置及變更，用于軟件專業人員和用戶的交流，用于軟件開發、過程管理和運行階段的維護。2023/2/614遵循標準保持程序、數據和文檔的一致性。1.1.2軟件生存周期軟件生存周期：軟件從概念形成、進化、運行到退役的全過程。圖1.1傳統軟件生存周期

2023/2/6151.1.3軟件的特點軟件是一種邏輯實體，不是物理實體，他具有抽象性軟件不會磨損和老化軟件主要是研制，生產是簡單的拷貝軟件成本昂貴，其開發方式至今尚未擺脫手工方式軟件維護不同于硬件維修，易產生新的問題軟件具有“復雜性”，其開發和運行常受到計算機系統的限制，即受環境影響大2023/2/616圖1.2軟硬件的故障率曲線硬件交付后，初期會暴露產品設計、制造中的問題，各零部件需要磨合，經長期使用會發生磨損、老化，于是故障率曲線呈“浴缸”形（如圖1.2a所示）。軟件不會磨損、老化，但軟件邏輯關系復雜、理解困難，維護過程中很可能產生新的缺陷（如圖1.2b所示）。2023/2/6171.1.4幾類常用的軟件系統軟件個人計算機軟件實時嵌入式軟件科學和工程計算軟件事務處理軟件人工智能軟件Web應用軟件2023/2/6181.1.5軟件的質量不同人對軟件質量的關注點和理解是不同的。用戶：關注軟件質量的外部屬性，如軟件的正確性、可靠性、有效性、完整性、可用性、可維護性、可移植性、可復用性等。軟件工程師：更關注軟件質量的內部屬性，通過提高軟件內部屬性，如模塊化、一致性、簡潔性、可測試性、自文檔化等，支持和保證軟件外部質量屬性的實現。國際標準化協會頒布的ISO9126(2001)將軟件質量要素確定為正確性、可靠性、有效性、可使用性、可維護性、可移植性六個。2011年3月國際標準化組織對ISO9126做了修訂和擴充，發布了ISO/IEC25010新標準,增加了安全性和兼容性。軟件要素和屬性之間的關系不是獨立的，有些是相關的,甚至是矛盾的。2023/2/619(1)正確性(correctness)。軟件滿足需求規約及完成用戶目標的程度。(2)可用性(usability)。

學習和使用軟件的難易程度，包括：操作軟件、為軟件準備輸入數據，解釋軟件輸出結果等。(3)可靠性(reliability)。

軟件完成預期功能，成功運行的概率。軟件可靠性反映了軟件無故障工作的狀況。(4)有效性(efficiency)。軟件系統利用計算機的時間資源和空間資源完成系統功能的能力。2023/2/620軟件工程8個質量要素：(5)可維護性(maintainability)。軟件制品交付用戶使用后，能夠對它進行修改，以便改正潛伏的缺陷、改進性能和其他屬性，使軟件制品適應環境的變化等等。由于軟件是邏輯產品，只要用戶需要可以無限期地使用下去，軟件維護是

不可避免的。軟件維護成本約

占整個生命周期

的40%至60%。

軟件維護費用高

的問題今天仍然沒有明顯改變。圖1.3軟件開發成本比重上升維護成本居高不下2023/2/621(6)可移植性(portability)。將軟件安裝在不同計算機系統或環境的難易程度。(7)安全性(security)。控制或保護程序和數據不受破壞的機制，以防止程序和數據受到意外的或蓄意的存取、使用、修改、毀壞或泄密。在網絡環境下計算機犯罪、惡作劇增多，軟件安全受到人們的高度重視。(8)可復用性(reusebility)。

概念或功能相對獨立的一個或一組相關模塊定義為一個軟構件。軟構件可以在多種場合應用的程度稱為構件的可復用性。2023/2/6221.1.6軟件的安全與保護軟件安全是軟件控制的系統始終處于不危及人的生命財產和生態環境的屬性。軟件安全包括兩個方面：（1）關鍵領域關鍵部位的計算機軟件必須正確、可靠的工作，要防止因概念、設計和結構等方面的不完善造成的系統失效，要具有挽回因設計、操作不當造成軟件系統失效的能力。（2）對進入軟件系統人的身份進行認證、對數據訪問進行控制，阻止計算機病毒、木馬的侵入，防止計算機失控，計算機內的重要信息被盜，給人們的財產和精神造成巨大損失。

2023/2/623軟件的安全與保護IEC國際標準SC65A-123（草案）把軟件危險程度分成四級，即災難性、重大、較大、較小。災難性計算機系統的失效會危及群眾的生命，摧毀設備、設施，造成巨大的經濟損失重大失效會危及人員生命，部分設備、設施嚴重損壞，造成大的經濟損失較大失效會造成人員傷害，給設備、設施造成一定損失較小不涉及安全性問題2023/2/624表1.1IECSC65A-123不同危險等級軟件的可靠性要求

連續控制系統

業務處理系統危險等級每小時發生危險故障的次數請求調用時發生故障的概率災難性

10-8~10-9

10-4~10-5重大

10-7~10-8

10-3~10-4較大

10-6~10-7

10-2~10-3較小

10-5~10-610-1~10-2

2023/2/6251.2軟件工程的概念1.2.1軟件工程的定義1.2.2軟件工程的發展1.2.3軟件工程的目標和原則1.2.4軟件開發的主要方法2023/2/6261.2.1軟件工程的定義IEE93給出的軟件工程定義：

①將系統的、規范的、可量化的方法應用于軟件的開發、運行和維護的過程；

②及上述方法的研究。軟件工程這一定義的第一部分要求，軟件開發、運行和維護的過程是“系統的”、“規范的”、“可量化的”。軟件工程定義的第二部分說明，軟件工程需要相關科學研究做基礎，需要方法學的支持。2023/2/627圖1.4軟件工程五要素軟件工程的項目、人、過程、方法和工具、軟件制品構成了軟件工程的五要素，它們既有區別又有聯系（如圖1.4所示）2023/2/6282004年ACM和IEEE/CS聯合推出的軟件工程知識體SWEBOK系統的定義了軟件工程學科的研究目標和主要內容，包括：

軟件需求、設計、構造、

測試、維護、配置管理、

軟件工程管理、軟件工程過程、

軟件工程工具和方法、軟件質量2023/2/629計算機系統4個不同的發展階段：時期主頻軟件第一代20世紀50年代初到60年代末103~105程序設計階段個體化生產軟件危機出現第二代20世紀60年代末期到80年代中期105~107程序系統階段作坊式生產軟件工程誕生第三代20世紀80年代中期到90年代末期107~108軟件工程階段工程化思想分布式系統第四代2000年至今109硬件與軟件綜合體系結構獨立學科1.2.2軟件工程的發展軟件危機的原因：2023/2/631問題出在哪里？①用戶對軟件需求的描述經常出現二義性、不確定性、遺漏或錯誤。

軟件開發過程中，經常提出變更軟件功能、界面、支撐環境等要求。2023/2/632②軟件開發人員對用戶需求的理解與用戶的本來愿望有差異。

這種差異用戶和開發人員可能還不知道，這必然導致開發出來的軟件產品與用戶要求不一致。2023/2/633③大型軟件項目需要組織一定的人力共同完成，多數管理人員缺乏開發大型軟件系統的經驗，而多數軟件開發人員又缺乏管理經驗。

各類人員的信息交流不及時、不準確、有時還會產生誤解2023/2/634人與人的交流比寫程序困難得多。④軟件項目開發人員不能有效地、獨立自主地處理大型軟件的全部關系和各個分枝，因此容易產生疏漏和錯誤。2023/2/635⑤缺乏有力的方法學和工具支持，過分地依靠程序設計人員在軟件開發過程中的技巧和創造性，加劇軟件產品的個性化。2023/2/636⑥軟件產品的特殊性和人類智力的局限性，使人們處理“復雜問題”困難重重。

所謂“復雜問題”的概念是相對的。一旦人們采用先進的組織形式、開發方法和工具提高了軟件的開發效率和能力，新的、更大的、更復雜的問題又擺在人們面前。2023/2/637軟件工程的發展綜上所述，軟件工程發展的主要因素是：信息社會的廣泛需求，軟硬件技術的進步，軟件從業人員卓有成效的工作，軟件產業的興起，軟件學科建設和人才培養，各國政府對軟件發展的重視等四十年來軟件工程逐步成熟，伴隨硬件的發展，軟件工程向著施工領域更廣泛、開發能力更強，過程更成熟,軟件質量、成本、進度更加可控的目標邁進。2023/2/638圖1.5影響軟件工程發展的關鍵要素2023/2/6391.2.3軟件工程的目標和原則軟件工程的目標在給定成本、進度的前提下，開發出滿足用戶或市場需要的高質量的軟件產品。為了達到這些目標，在軟件開發過程中必須根據軟件系統，特別是各子系統的功能、特點和實際情況，選取適宜的開發模型和設計方法，采用有效的軟件項目管理方法。過程中必須遵循的軟件工程原則：

抽象、信息隱藏、模塊化、局部化、一致性、

完全性和可驗證性。2023/2/6401.2.4軟件開發的主要方法常用的方法有：結構化方法、面向對象方法、及形式化開發方法等。近年來隨著網絡技術、多媒體技術的發展和構建大型復雜軟件的需要:網絡的軟件開發方法基于構件的軟件開發方法面向方面AOP的軟件開發方法人機界面及虛擬現實的軟件開發方法敏捷軟件開發方法這些方法支持軟件的分析、設計、編碼、測試，給出了指導軟件開發活動的基本原則、技術和步驟。2023/2/6411.結構化方法結構化方法是1970年代初至1980年代中廣泛使用的方法至今在科學計算、實時嵌入式應用軟件開發中仍在發揮作用結構化方法是從結構化的程序設計開始逐步擴展為，包括結構化分析、結構化設計、結構化程序設計的系統方法。結構化分析用分層的數據流圖和控制流圖開發系統的功能模型和數據模型。結構化設計按照系統功能模型，自頂向下，逐步求精，最終得到組成系統的模塊（子系統）及它們之間的控制關系。結構化程序設計用結構化的程序設計語言，遵循結構化的程序設計原則實現模塊功能，實現體系結構中每一功能模塊的過程屬性和算法描述。2023/2/6422.面向對象方法前提條件1980年代中期個人計算機圖形界面迅速普及，處理基于社會的信息系統問題需求廣泛，為面向對象方法的發展和推廣創造了條件。內容面向對象方法是以對象、對象關系構建軟件系統的方法。包括，面向對象分析、設計、編碼、測試。對象是類的實例，類用屬性、操作和關系描述。類是面向對象方法建模、設計、實現和測試的基礎。類具有良好的可復用性。UMLJ．Rumbaugh、I.Jacobson、G．Booch等人聯合開發對象管理組織(OMG)發布統一過程RUP將面向對象軟件開發的分析、設計和構造無縫聯接起來Rational

ROSE可方便地生成一系列的UML視圖2023/2/6433.形式化開發方法以軟件正確性為目標軟件需求規約用形式化需求規約語言(RSL)描述，如VDM的META—IV，CSP，Z語言等依靠嚴格的數學推理，保證軟件開發的正確性有效解決歧義性、完整性、一致性、安全性問題形式化語言支持形式化需求規約語言有嚴格的語法、語義定義，以及一系列的數學推演規則。通常語法、語義以集合論、數理邏輯或代數學為基礎。規則指明軟件規約必須滿足的數學性質，及軟件實現與軟件規約必須保持的一致性。正確地程序變換在此基礎上，利用變換模型和配套的開發工具，如程序變換工具、定理證明工具等進行一系列的程序變換，最后生成正確的程序代碼。2023/2/6441.3軟件過程模型1.3.1瀑布模型1.3.2增量過程模型1.3.3原型建造模型1.3.4螺旋模型1.3.5基于構件的過程模型1.3.6通用軟件過程模型2023/2/6451.3軟件過程模型軟件過程(process)：描述、開發、維護軟件制品，創建、管理和支持軟件項目的一系列活動。為了描述、規范軟件開發的管理和技術活動，需要建立軟件過程模型，對軟件開發過程的結構和屬性進行抽象。軟件過程模型定義了軟件開發活動，給出了它們之間的邏輯關系，為軟件工程管理提供里程碑和進度表；為軟件開發提供框架和方法。2023/2/646軟件過程模型軟件過程模型受軟件開發歷史環境的影響，可分為三種類型:(1)將軟件開發過程的分解與軟件生存周期劃分綁定在一起的瀑布模型及其變形。(2)軟件開發過程的分解與軟件生存周期劃分相對獨立的通用過程模型。(3)專用模型，包括基于構件的軟件過程模型、Web應用軟件過程模型、面向方面AOP的軟件過程模型、以形式化開發方法為基礎的變換模型等。2023/2/6471.3.1瀑布模型瀑布模型(waterfallmodel)也稱軟件生存周期模型，是W.Royce在1970年首先提出的。它們既是軟件開發過程的分解，也是軟件生存周期的階段劃分。瀑布模型按照各階段的目標和任務逐步進行開發，直至通過確認測試，向用戶交付最終軟件制品為止。

圖1.6軟件生存周期的瀑布模型2023/2/648利用瀑布模型進行軟件開發的

過程和生成的軟件制品2023/2/649反饋的瀑布模型實踐中，對某一階段軟件制品的評審會經常發現缺陷和疏漏，這時不得不暫停這一階段的活動，反饋到前面的有關階段修正缺陷、增補疏漏，然后再重復前面的工作，直至該階段通過評審后再進入下一階段。于是，瀑布模型演變成帶有反饋的瀑布模型，如圖1.8所示。圖1.8帶反饋的瀑布模型2023/2/650V字型瀑布模型另一種改進的瀑布模型是V字型瀑布模型，如圖所示。軟件的分析、設計過程與軟件測試過程一一對應，強化了軟件設計和測試的關系，加強了軟件的質量保證。圖1.9V字型瀑布模型2023/2/651瀑布模型的特點思路簡潔、明確上一階段的開發結果是下一階段開發的輸入，相鄰兩個階段具有因果關系，緊密相聯。階段分離、評審為了保障軟件開發的正確性，每一階段任務完成后，都必須對它的階段性制品（文檔、原型、程序等）進行評審，確認之后再轉入下一階段瀑布模型的可行性研究、需求、設計、編碼、測試分離，有利于軟件的體系結構設計，規范了軟件開發活動，有利于開發人員的組織、管理適用場景對于規模較小、軟件需求比較穩定的項目或子系統，采用瀑布模型能夠顯著提高軟件開發的質量和效率2023/2/652瀑布模型的缺點①需求難以確定必須要求客戶和系統分析員確定軟件需求后才能進行后續的軟件開發工作，但多數場合給出大型軟件項目的全部需求是困難的，有時甚至是不現實的；②初版開發時間長，缺陷發現晚需求確定后，用戶和軟件項目負責人要等相當長的時間(經過設計、實現、測試、運行)才能得到軟件的最初版本，如果用戶對這個軟件提出比較大的修改意見，那么整個軟件項目將會蒙受巨大的人力、財力和時間損失；③缺陷積累、放大開發人員在瀑布模型“上游”出現“過失”(mistake)會為軟件制品帶來“缺陷”(fault)并潛伏在軟件制品中，缺陷會誤導“下游”的開發活動，若未被發現，則軟件運行時會造成系統“故障”(failure)。造成修復成本高這時必須花力氣找到故障原因，修復缺陷，造成不應有的人力、財力和時間損失。2023/2/653使用瀑布模型的注意事項①需求明確后再施工；②每個階段的結果要及時評審和測試，發現的問題妥善處理后再開始下一階段的工作；③開發周期盡量短，盡快給用戶使用，得到反饋意見；④一次開發的軟件規模不宜過大。2023/2/654瀑布模型實踐中，很多物理系統中的實時軟件，或大型軟件系統的某些部分已經過嚴格的可行性論證和仿真實驗，需求是非常明確的，有些還能用嚴格的數學物理模型描述，如火箭控制系統的嵌入式軟件、軍用指揮控制系統的裝備軟件等。這樣的軟件過程就可以采用帶反饋的瀑布模型或V字瀑布模型。美國國防部標準2167-A規定，瀑布模型是國防部合同中軟件開發交付的依據，德國國防部1992年也強調了V字瀑布模型的作用。2023/2/6551.3.2增量過程模型動因：解決瀑布模型的不足對于軟件開發前需求基本確定的大型軟件項目，采用瀑布模型開發時間長、不能快速占領市場、不能在短期內得到用戶的反饋意見。增量過程模型的基本思想

開發人員與用戶協商將需求分解，劃分為一系列增量，并為增量排序，急需的增量排在前面先開發，不急需的放在后面。

每個增量都歷經需求、設計、編碼、測試、移交幾個階段（如圖1.10所示）。

根據增量間的依賴關系、開發人員和項目的實際情況，有些增量可串行開發，有些可并行開發。

在此過程中不斷開發、不斷集成、不斷交付，直到完成所有增量的開發，得到最終的軟件制品。2023/2/656

圖1.10增量過程模型2023/2/657例：開發字處理軟件第一個增量構件基本的文件管理、編輯、和文檔生成功能第二個增量構件更完善的編輯和文檔生成功能；第三個增量構件實現拼寫和語法檢查功能；第四個增量構件完成高級的頁面排版功能2023/2/658優點①不斷地發布軟件新版本，可及時獲得客戶的反饋，用于調整后續的軟件開發策略；②由于軟件需求是確定的，可先對軟件體系結構進行設計，能保持良好的軟件體系結構。缺點①增量規模不能大（開發不要超過20k行代碼），否則會暴露瀑布模型的缺點；②將客戶需求分解成增量序列必須對系統需求十分了解，并有頂層設計的經驗；③多數系統都需要基本服務，如何為基本服務定義增量，何時實現這些增量，處理起來比較困難。2023/2/659增量過程模型的特點1.3.3原型建造模型原型(prototyping)：是快速建立起來的可以在計算機上運行的程序，它所能完成的功能往往是最終產品能完成的功能的一個子集。原型向客戶展示了待開發軟件系統的全部或部分功能和性能，在征求客戶對原型意見的過程中，進一步修改、完善、確認軟件系統的需求并達到一致的理解。2023/2/660原型建造模型快速開發原型的途徑有三種：①利用計算機模擬軟件系統的人機界面和人機交互方式；②利用敏捷軟件開發方法開發一個工作原型，實現軟件系統重要的，容易產生誤解的部分功能；③找來若干個類似軟件，利用這些軟件向客戶展示軟件需求中的部分或全部功能。2023/2/661原型建造模型原型有兩類。(1)拋棄型原型(實驗性原型)利用原型定義和確認了軟件需求后，原型就完成了任務。開發人員就可以按照確認的需求進行軟件設計、編碼、測試。(2)應用型原型(進化性原型)

利用原型確認軟件需求后，對原型進一步加工、完善，使之成為系統的一部分。2023/2/662圖1.11原型建造模型1.3.4螺旋模型螺旋模型(spiralmodel)是TRW的B.Boehm在1988年提出的一種迭代模型。螺旋模型是從里向外，螺旋線每個回路表示的軟件過程都由四個階段組成。(1)定義目標(2)風險分析(3)開發和驗證(4)規劃2023/2/663圖1.12Boehm的螺旋模型2023/2/664螺旋模型適合大型軟件開發特別是電子商務、電子政務一類的業務軟件系統因為開發這類系統時，需求往往不能完全確定項目開始時開發人員與用戶協商，將能夠確定的需求、暫時不能確定的需求劃分為一系列的增量，并為增量排序，確定的、急需的增量排在前面，暫時不能確定或不急需的放在后面2023/2/665螺旋模型優點具有邊學習、邊建模，邊開發、邊使用、邊改進缺點由于需求的不確定性，軟件開發初期無法進行軟件體系結構設計，多次迭代會導致軟件體系結構變壞，為軟件理解和維護帶來困難2023/2/666通過迭代、進化，占領先機原型建造模型和螺旋模型既是迭代模型，又是進化模型實踐中，客戶利用迭代或增量模型盡快開發第一個版本的軟件制品，占領市場的有利商機，然后再逐步擴展系統功能，不斷推出后續版本1.3.5基于構件的過程模型基于構件的軟件開發以軟件復用為基礎，必須有可供選擇和使用的構件及集成構件的框架。構件的基本要素包括:接口定義（操作名、參數、異常處理）構件使用說明（如定義接口的語言，構件功能、性能）構件部署信息（指明部件如何“打包”成為可執行的實體）。它也是快速構建原型的有效方法，應用廣泛實踐中構件往往是異構的有些構件是傳統的軟件模塊，有些是面向對象的類或軟件包可能來自于多個供應商給軟件維護帶來困難2023/2/668基于構件的過程模型基于構件的軟件過程模型如圖所示。圖1.13基于構件的軟件開發模型2023/2/669基于構件的過程模型優點減少了軟件開發工作量，降低了軟件開發成本和風險，縮短了軟件交付時間。缺點為使用構件可能要修改需求，提供的軟件可能與用戶期望的系統不同。2023/2/6701.3.6通用軟件過程模型到了1990年代為了滿足社會對應用軟件廣泛、迫切的需求，適應多數應用軟件開發需要從創意開始、需求若明若暗、需求變更頻繁的實際情況，人們對常用的軟件過程進行了總結和擴展，將軟件開發過程的活動劃分為：

溝通、策劃、建模、構建、部署共五項，并以此為基礎，構建多種通用的軟件過程模型。2023/2/671通用軟件過程模型“溝通”活動：確定業務模型

項目立項，軟件系統工程師和領域專家、用戶的交流。不斷提取需求、篩選業務用例,逐步完善業務過程模型。溝通活動適應大型業務軟件需求提取、變更的需要。

溝通活動也是領域專家、用戶、軟件系統工程師共同學習、認識、確定用戶業務過程模型（也是待開發軟件的基本過程模型）的過程。“策劃”活動：評估項目整體風險分析、項目規劃、成本估算、制定項目計劃、項目跟蹤等。

策劃活動加強了軟件過程的項目管理。2023/2/672通用軟件過程模型“建模”活動：分析與設計軟件開發的需求建模和軟件體系結構設計“構建”活動：實現軟件開發的構件獲取或構件設計、編碼和測試。建模和構建活動是傳統軟件開發過程的核心。“部署”活動：交付發布軟件制品、現場安裝、運行、維護，及用戶培訓等。通用的軟件過程模型線性過程模型迭代過程模型增量過程模型進化過程模型并行過程模型2023/2/673通用軟件過程模型通用的軟件過程模型有下列幾種。（1）線性過程模型線性過程模型是在瀑布模型的基礎上發展起來的，如圖所示。

圖1.14線性過程模型2023/2/674（2）迭代過程模型迭代過程模型由帶反饋的瀑布模型發展而來。模型中允許溝通和策劃活動反復迭代。這是軟件系統工程師、管理人員與客戶反復交流、提取、確定軟件需求，形成待開發的需求用例、規約，進行風險分析、估算開發成本、制定項目計劃的過程。建模活動是一個迭代過程開發的軟件體系結構應滿足需求用例和需求規約的要求，應不斷優化，力求簡潔，符合軟件開發的原則，滿足開發的約束條件

圖1.15迭代過程模型2023/2/675（3）通用增量過程模型當軟件開發前，軟件需求能基本確定，能進行相對完整的軟件體系結構設計時，可采用通用增量過程模型

圖1.16通用的增量過程模型2023/2/676（4）通用進化過程模型原型過程模型和螺旋過程模型都是進化過程模型。包含通用軟件開發活動的原型模型如圖所示。

圖1.17通用原型過程模型利用軟件開發五項活動的通用螺旋模型如圖所示。

圖1.18通用螺旋過程模型2023/2/677（5）并行過程模型軟件開發的溝通、策劃活動與建模活動可以并行操作。溝通、策劃的結果和變更可及時反饋給建模活動。建模活動產生的軟件制品，如原型、需求規約、體系結構也可及時反饋給溝通、策劃活動參考。多數構建、部署活動始

于建模完成并通過評審

之后，因為構建活動工

作量大、參與的人比較

多，因此希望建模活動

生成的軟件體系結構質

量比較高、變更比較少，

這樣可以減少返工和產

品報廢。圖1.19并行過程模型2023/2/6781.4敏捷軟件開發原則和應用1.4.1敏捷軟件開發原則1.4.2敏捷軟件過程的極限編程實踐1.4.3敏捷軟件開發過程的應用2023/2/6791.4敏捷軟件開發原則和應用針對中小型事務處理軟件開發2001年RobertCMartin等21位經驗豐富的軟件開發專家針對中小型事務處理軟件開發采用大型、高可信軟件開發的標準帶來的文檔多、成本高、開發時間長等弊端，論述了他