第一章軟件工程過程：原理、方法與工具軟件工程過程【ch01】軟件工程過程.pptx【ch02】軟件工程模型與方法.pptx【ch03】軟件需求.pptx【ch04】軟件設計.pptx【ch05】軟件構造.pptx【ch06】軟件測試.pptx【ch07】軟件維護.pptx【ch08】軟件配置管理.pptx【ch09】軟件項目管理.pptx【ch10】軟件質量.pptx全套可編輯PPT課件01軟件過程定義1.1軟件過程定義軟件過程是一組相互關聯的活動，將輸入工作產品轉換為輸出工作產品。至少，軟件過程的描述包括所需的輸入、轉換工作活動和生成的輸出。如圖1-2所示，軟件過程可能還包括其輸入和輸出標準，并將工作活動分解為任務，這是軟件過程管理的最小單位。軟件過程輸入可能是觸發事件或另一個軟件過程的輸出。輸入標準應該在一個軟件過程開始之前得到滿足。在成功地完成一個軟件過程之前，必須滿足所有指定的條件，包括輸出工作產品或工作產品的驗收標準。1.1軟件過程定義1.1軟件過程定義軟件過程可能包括子過程。軟件需求驗證的輸入通常是軟件需求規范和執行驗證所需的資源（人員、驗證工具、足夠的時間）。軟件需求驗證的任務可能包括需求審查、原型和模型驗證。這些任務包括個人和團隊的工作任務。軟件需求驗證的輸出通常是一個經過驗證的軟件需求規范，它為軟件設計和軟件測試過程提供了輸入。軟件需求驗證與軟件需求過程的其他子過程通常會以不同的方式進行交叉和迭代。軟件需求過程及其子過程可以在軟件開發或修改過程中多次輸入或輸出。1.1軟件過程定義軟件過程的完整定義可能還包括角色和能力、IT支持、軟件工程技術和工具、執行過程所需的工作環境、用于確定執行過程的效率和有效性的方法與度量。此外，軟件過程可能包括交叉技術、協作和管理活動。定義軟件過程的符號包括組織活動的文本列表和自然語言描述的任務、數據流圖、狀態圖、業務流程建模標注、集成定義、Petri網和統一建模語言活動圖。流程中的轉換任務可以定義為軟件過程：一個軟件過程可以被指定為一個有序的步驟，或者作為待完成任務的工作檢查表。必須強調的是，沒有最好的軟件過程或軟件過程集，必須根據每個項目和每個組織的內容選擇、調整和應用軟件過程。1.1.1軟件過程管理軟件過程管理的兩個目標是，實現軟件過程的效率與有效性和生產工作產品的系統方法的效率與有效性，無論是在個人、項目或組織層面，還是在引入新的或改進的過程方面。過程隨期望而改變，一個新的或修改后的過程將提高過程的效率與有效性，同時提高所生產工作產品的質量。引入一個新的過程、改進現有的過程或者改變現有的組織和框架（技術插入或工具的改變）是密切相關的，因為所有這些的目的通常都是為了改進軟件產品的成本、開發進度或質量。過程的改變不僅對軟件產品有影響，還經常會導致結構的改變。改變一個過程或引入一個新過程會在整個組織結構中產生連鎖反應。例如，對IT基礎設施、工具和技術的更改通常需要過程改變。在第一次部署新過程時，可能會修改現有的過程（例如，在軟件開發項目中引入檢查活動可能會影響軟件測試過程一一參見第6章和第10章）。這些情況也可以稱為“過程演化”。如果修改是廣泛的，那么可能需要在組織培養和業務模型中進行更改以適應過程改變。1.1.2軟件過程框架軟件過程框架因組織的規模和復雜性及組織內的項目而異。小型、簡單的組織和項目有小而簡單的框架需求，大型、復雜的組織和項目必須有更大、更復雜的軟件過程框架。在后一種情況下，可以建立各種組織單元（如軟件工程過程組或指導委員會）來監督軟件過程的實現和改進。一個常見的誤解是，建立一個軟件過程框架和實現可重復的軟件過程將增加軟件開發和維護的時間及成本。當然，引入或改進軟件過程需要付出一定的代價。然而，經驗表明，通過提高效率、避免返工，以及使用更可靠和可負擔得起的軟件，以系統地改進軟件過程，往往會降低成本。因此，軟件過程性能影響軟件質量。1.1.2軟件過程框架軟件過程框架定義了若干框架活動，為實現完整的軟件工程過程建立了基礎。這些活動可廣泛應用于所有軟件開發項目，無論項目的規模和復雜性如何。此外，軟件過程框架還包含一些適用于整個軟件過程的普適性活動。一個通用的軟件過程框架通常包含以下5個活動。（1）溝通在技術工作開始之前，和客戶（及其他干系人）的溝通與協作是極其重要的。其目的是理解干系人的項目目標，并收集需求以定義軟件特性和功能。（2）策劃如果有地圖，那么任何復雜的旅程都可以變得簡單。軟件項目好比是一個復雜的旅程，策劃活動就是創建一張“地圖”，以指導團隊的項目旅程。這張地圖稱為軟件項目計劃。它定義和描述了軟件工程工作，包括需要執行的技術任務、可能的風險、資源的需求、工作產品和工作進度計劃。1.1.2軟件過程框架（3）建模無論你是工程師、建筑師還是木匠，每天的工作都離不開模型。你會畫一張草圖來輔助理解整個項目大的構想一體系結構、不同的構件如何結合，以及其他一些特性。如果需要，可以把草圖不斷細化，以便更好地理解問題并找到解決方案。軟件工程師也是如此，需要利用模型來更好地理解軟件需求，并完成符合這些需求的軟件設計。（4）構建必須要對所做的設計進行構建，包括編碼（手寫的或者自動生成的）和測試。后者用于發現編碼中的錯誤。（5）部署部署是指軟件（全部或者部分增量）交付給用戶，由用戶對其進行評測并給出反饋意見。1.1.2軟件過程框架軟件過程框架活動由很多普適性活動來補充實現。通常，這些普適性活動貫穿軟件項目始終，以幫助軟件團隊管理與控制項目的進度、質量、變更和風險。典型的普適性活動包括如下活動。（1）軟件項目跟蹤和控制：項目組根據計劃來評估項目進度，并且采取必要的措施來保證項目按進度計劃進行。（2）風險管理：對可能影響項目成果或者產品質量的風險進行評估。（3）軟件質量保證：確定和執行保證軟件質量的活動。1.1.2軟件過程框架（4）技術評審：評估軟件工程產品，盡量在錯誤傳播到下一個活動之前發現并清除它。（5）測量、定義和收集軟件過程、項目及產品的度量：幫助團隊在發布軟件時滿足干系人的要求。同時，測量還可與其他軟件框架活動和普適性活動配合使用。（6）軟件配置管理：在整個軟件過程中管理變更所帶來的影響。（7）可復用管理：定義工作產品復用的標準（包括軟件構件），并且建立構件復用機制。（8）工作產品的準備和生產：包括生產工作產品（如建模、文檔、日志、表格和列表等）所必需的活動。1.1.2軟件過程框架軟件過程框架如圖1-3所示。可以看出，每個框架活動都由一系列軟件工程動作構成：每個軟件工程動作都要由一個任務集來定義，這個任務集明確了將要完成的工作任務、將要生產的工作產品、所需要的質量保證點，以及用于表明過程狀態的項目里程碑。1.1.2軟件過程框架在軟件過程中，使用過程流來描述對軟件過程框架中的活動、動作和任務如何在執行順序和執行時間上進行組織。常用的過程流包括線性過程流、迭代過程流、演化過程流和并行過程流。線性過程流從溝通到部署順序執行5個活動，如圖1-4所示。迭代過程流在執行下一個活動前重復執行之前的一個或多個活動，如圖1-5所示。1.1.2軟件過程框架演化過程流采用循環的方式執行各個活動，每次循環都能產生更完善的軟件版本，如圖1-6所示。并行過程流將一個或多個活動與其他活動并行執行，如圖1-7所示。02軟件生命周期1.1.2軟件過程框架01基本過程基本過程定義了與軟件生產直接相關的過程，即軟件從無（或原有）到（新）有到運營的過程，包括軟件的獲取、供應、開發、運行和維護。（1）獲取過程，是指獲取方為得到一個軟件產品所進行的一系列活動，包括確定獲取產品的需求定義、投標準備、合同準備和修改、對供應方的監督及驗收完成和結束。（2）供應過程，是指為獲取方提供軟件產品所進行的一系列活動，包括理解產品需求、應標準備、合同簽訂、計劃制訂、實施和控制、評價及交付完成。（3）開發過程，是指組織開發軟件所從事的一系列活動，包括需求分析、系統設計、編碼、測試、安裝及驗收。在開發過程中還貫穿了其他軟件過程的實施。1.1.2軟件過程框架01基本過程（4）運行過程，是指操作人員日常使用軟件的過程。該過程是指用戶和操作人員在用戶業務運行環境中，使用軟件投入運行所進行的一系列活動。其目的是在軟件開發過程完成后，將軟件從開發環境轉移到用戶的業務環境中運行時，對用戶的要求提供咨詢和幫助，并對運行效果做出評價。這個過程為開發過程和維護過程提供反饋信息。運行管理方可根據對軟件項目的總體要求，按照軟件管理過程的內容對運行過程進行管理。（5）維護過程，是指維護人員所從事的一系列活動。其目的是在保持軟件整體性能的同時進行修改，使其達到某一需求，直至其被廢止。維護包括改正性、適應性和完善性維護。維護過程包括過程實現、問題分析與修改、修改實施、維護評審和驗收、移植和軟件退役等。在維護過程中還貫穿了其他軟件過程的實施。1.1.2軟件過程框架02支持過程支持過程是指為了保證基本過程的正常運行、目標的實現和質量的提高所從事的一系列過程。它們可被基本過程的各個過程部分或全部采用，并由它們自己的組織或一個獨立組織負責實施，也可由用戶負責實施。（1）文檔過程，用于記錄任何其他過程所產生的特定信息的一組活動。（2）配置管理過程，用于捕獲和維護開發過程中所產生的信息和產品的一組活動，以便于后續開發與維護。（3）質量保證過程，用于客觀地保證產品和相關過程與需求文檔和計劃保持一致的一組活動。1.1.2軟件過程框架02支持過程（4）驗證過程，用于檢驗產品的活動，是依據實現的需求定義和產品規范，確定某項活動的產品是否滿足所給定或所施加的要求和條件的過程。驗證過程一般根據軟件項目需求，按不同深度確定驗證產品所需要的活動，包括分析、評審和測試，其執行具有不同程度的獨立性。為了節約費用和有效進行，驗證活動應盡早與采用它的過程（如獲取、開發、運行和維護）相結合。該過程的成功實施期望帶來如下結果：根據需要驗證的產品所制訂的規范（如產品規格說明）實施必要的檢驗活動；有效地發現各類階段性產品所存在的缺陷，并跟蹤和消除缺陷。1.1.2軟件過程框架02支持過程（5）確認過程，用于確認產品的活動。這是一個確定需求和最終的、已建立的系統或軟件（產品）是否滿足特定的預期用途的過程，集中判斷產品中所實現的功能、特性是否滿足客戶的實際需要。確認過程和驗證過程構成了軟件測試缺一不可的組成部分，也可以將之看作質量保證活動的重要支持手段。確認應該盡量在早期階段進行，如階段性產品的確認活動。確認和驗證相似，也具有不同程度的獨立性。該過程的成功實施期望帶來如下結果：根據客戶實際需要，確認所有產品相應的質量準則，并實施必要的確認活動；提供有關證據，以證明開發出的產品滿足或適應指定的需求。1.1.2軟件過程框架02支持過程（6）聯合評審過程，由雙方使用的、評估其他活動的狀態和產品的活動。聯合評審過程評價一項活動的狀態和產品所需遵循的規范及要求，一般要求供、需雙方共同參加。其評審活動在整個合同有效期內進行，包括管理評審和技術評審。管理評審主要依據合同的目標，與客戶就開發進度、內容、范圍和質量標準進行評估、審查，使雙方通過充分交流達成共識，以保證開發出客戶滿意的產品。該過程的成功實施期望帶來如下結果：與客戶、供應商及其他利益相關方（或獨立第三方）對開發的活動和產品進行評估；為聯合評審的實施制訂相應的計劃與進度，跟蹤評審活動，直至結束。1.1.2軟件過程框架02支持過程（7）審核過程，用于確定項目與需求、計劃與合同的符合程度。審核過程判斷各種軟件活動是否符合用戶的需求、質量計劃和合同所需要的其他各種要求。審核過程發生在軟件組織內部，也稱內部評審。審核一般采用獨立的形式對產品及所采用的過程加以判斷、評估，并按項目計劃中的規定，在預先確定的里程碑（代碼完成日、代碼凍結日和軟件發布日等）之前進行。對于審核中出現的問題，應加以記錄，并按要求輸入問題解決過程。該過程的成功實施期望帶來如下結果：判斷是否與指定的需求、計劃及合同相一致；由合適的、獨立的一方來安排對產品或過程的審核工作；確定其是否符合特定需求。1.1.2軟件過程框架02支持過程（8）問題解決過程，一組在分析和根除存在問題時所要執行的活動。不論問題的性質或來源如何，這些問題都是在實施開發、運行、維護或其他過程期間暴露出來的，需要得到及時糾正。問題解決過程的目的是及時提出相應對策、形成文檔，以保證所有暴露的問題得到分析和解決，并能預見到這一問題領域的發展趨勢。該過程的成功實施期望帶來如下結果：采用及時的、有明確職責的、文檔化的方式，以確保所有發現的問題都經過了相應的分析并得到解決；提供一種相應的機制，以識別所發現的問題并根據相應的趨勢采取行動。1.1.2軟件過程框架03組織過程（1）管理過程，是指軟件生命周期過程中管理者所從事的一系列活動和任務，如對獲取、供應、開發、運行、維護或支持過程的活動進行管理，目的是在一定的周期和預算范圍內有效地利用人力、資源、技術和工具完成預定的軟件產品，實現預期的功能和其他質量目標。管理過程是在整個軟件生命周期中為工程過程、支持過程和獲取/供應過程的實踐活動提供指導、跟蹤和監控的過程，從而保證軟件過程按計劃實施并能到達預定目標。管理過程是軟件生命周期中的基本管理活動，為軟件過程和執行制訂計劃，幫助軟件過程建立質量方針、配置資源，對軟件過程的特性和表現進行度量，收集數據，負責產品管理、項目管理、質量管理和風險管理等。一個有效的、可行的軟件過程能夠將人力資源、流程和實施方法結合成一個有機的整體，并能全面地展現軟件過程的實際狀態和性能，從而可以監督和控制軟件過程的實現。1.1.2軟件過程框架03組織過程對軟件過程的監督、控制實際孕育著一個管理的過程。管理過程包括：項目管理，是指計劃、跟蹤和協調項目執行及生產所需資源。項目管理過程的活動，包括軟件基本過程的范圍確定、策劃、執行和控制、評審和評價等。質量管理，是指對項目產品和服務的質量加以管理，從而獲得最高的客戶滿意度。此過程包括在項目及組織層次上建立對產品和過程質量管理的關注。風險管理，是指在整個軟件生命周期中對風險不斷地進行識別、診斷和分析，以回避、降低或消除風險，并在項目及組織層次上建立有效的風險管理機制。子合同商管理，是指選擇合格子合同商并對其進行管理。1.1.2軟件過程框架03組織過程（2）基礎設施過程，是指建立和維護其他過程所需的基礎設施的過程。例如，軟件工具、技術、標準及開發、支持、運行與維護所需的設施。其主要活動是定義并建立各個過程所需要的基礎設施，并在其他相關過程執行時維護其所建立的基礎設施。（3）改進過程，是指建立、評估、度量、控制和改進軟件生命周期過程的過程。其主要活動是制訂一套組織計劃，評估相關過程，并實施分析和改進過程。（4）培訓過程，是指為軟件產品提供人員培訓的過程。其主要活動是制訂人員培訓計劃、開發培訓資料及培訓計劃的實施。1.2.2軟件生命周期模型01瀑布模型瀑布模型是典型的軟/硬件開發模型，該模型也稱傳統軟件生命周期模型。如圖1-9所示，它包括需求分析、設計、編碼、集成與系統測試、運行與維護幾個階段。在每個階段分別提交以下產品：軟件需求規格說明、系統設計說明、實際代碼和測試用例、最終產品、產品升級等。工作產品流經“正向”開發的基本步驟路徑。“反向”的步驟流表示對前一個可提交產品的重復變更。由于所有開發活動都具有非確定性，因此是否需要重復變更，僅在下一個階段或更后的階段才能認識到。這種“返工”不僅在以前階段的某個地方有需要，而且對當前正在進行的階段也同樣重要。1.2.2軟件生命周期模型01瀑布模型1.2.2軟件生命周期模型01瀑布模型該模型的主要特點是：每個階段都以驗證/確認/測試活動作為結束，其目的是盡可能多地消除本階段產品中存在的問題。在隨后階段里，盡可能對前面階段的產品進行迭代。瀑布模型是第一個被完整描述的過程模型，是其他過程模型的鼻祖。其優點是：容易理解、管理成本低。瀑布模型的主要成果是通過文檔從一個階段傳遞到下一個階段。各階段間原則上不連續也不交疊，因此可以預先制訂計劃來降低計劃管理的成本。它不提供有形的軟件成果，除非到生命周期結束時。但文檔產生并提供了貫穿整個生命周期的進展過程的充分說明，允許基線和配置在早期接受控制，并且前一個階段作為下一個階段被認可的、文檔化的基線。1.2.2軟件生命周期模型01瀑布模型它的缺點表現為：用戶必須能夠完整、正確和清晰地表達其需要。但在實際系統開發中，經常會出現用戶與開發人員溝通存在巨大差異，用戶提出的需求含糊又被開發人員隨意解釋，以及用戶需求會隨著時間推移不斷變化等問題。可能要花費更多的時間來建立一些用處不大的文檔。在開始的兩個或三個階段中，很難評估真正的進度狀態。在一個項目的早期階段，過分強調基線和里程碑處的文檔。開發人員一開始就必須理解其應用范圍。當接近項目結束時，會出現大量的集成和測試工作。直到項目結束之前，都不能演示系統的能力。1.2.2軟件生命周期模型01瀑布模型瀑布模型的一個變體就是v模型，如圖1-10所示。它在每個環節中都強調了測試（并提供了測試的依據），同時又在每個環節中都做到了對實現者和測試者的分離。由于測試者相對于實現者的關系是監督、考察和評審，因此測試者相當于在不斷地做回顧和確認。在圖1-10中，左半部分是分析和設計，是軟件設計實現的過程，同時伴隨著質量保證活動—一審核的過程，也就是靜態測試過程；右半部分是對左邊結果的檢驗，是動態測試的過程，即對分析和設計的結果進行測試，以確認它們是否滿足用戶的需求。1.2.2軟件生命周期模型01瀑布模型1.2.2軟件生命周期模型01瀑布模型V模型被廣泛應用于軟件外包中。由于勞動力短缺等多種原因，很多企業把項目直接外包給國內/國外的開發團隊。項目成果的階段性考查成為第一要務，因為這直接決定了何時、如何，以及由誰來進入下一個環節。因此，v模型變得比其他模型更為實用。模型的左半部分由接受外包任務的團隊或者公司負責，而右半部分則由企業中有豐富經驗的工程人員負責。這樣既節省人力，又可以保證工程質量。事實上，即使圖1-10左半部分的外包任務是由多個團隊同時承接的，負責右半部分的工程人員也不需要更多的投入。1.2.2軟件生命周期模型02增量模型增量模型是由瀑布模型演變而來的，它是對瀑布模型的精化。該模型有一個假設，即需求可以分段，成為一系列增量產品，對每個增量可以分別進行開發，如圖1-11所示。在開始開發時，需求就很明確，并且軟件還可以被適當地分解為一些獨立的、可交付的產品，稱為構造增量；在開發中，希望盡快提交其中的一些增量產品。1.2.2軟件生命周期模型02增量模型圖1-12表達了如何利用瀑布模型來開發增量模型中的構造增量。盡管該圖表示對不同增量的設計和實現完全可以是并發的，但在實際中，可以按任意期望的并行程度進行增量開發。1.2.2軟件生命周期模型02增量模型增量模型作為瀑布模型的一個變體，具有瀑布模型的所有優點。此外，它還有以下優點：①第一個可交付版本所需要的成本和時間是很少的。②開發由增量表示的小系統所承擔的風險是不大的。③由于很快發布了第一個版本，因此可以減少用戶需求的變更。④允許增量投資，即在項目開始時，可以僅對一個或兩個增量投資。然而，如果增量模型不適于某些項目，或使用有誤，則有以下缺點：①如果沒有對用戶的變更要求進行規劃，那么產生的初始增量可能會造成后來增量的不穩定。②如果需求不像早期考慮的那樣穩定和完整，那么一些增量可能需要重新開發、重新發布。③管理成本、進度和配置的復雜度，可能會超出組織的能力。1.2.2軟件生命周期模型03演化模型演化模型顯式地把增量模型擴展到需求階段。從圖1-13可以看出，為了得到構造增量2，使用了構造增量1來精化需求。這一精化可以有多個來源和路徑。在演化模型中，仍然可以使用瀑布模型來管理每個增量。一旦理解了需求，就可以像實現瀑布模型那樣開始設計階段和編碼階段。1.2.2軟件生命周期模型03演化模型演化模型的優點和缺點與增量模型類似。特別地，演化模型還具有以下優點：在需求不能予以規范時，可以使用演化模型。用戶可以通過運行系統的實踐，對需求進行改進。與瀑布模型相比，需要更多用戶/獲取方的參與。1.2.2軟件生命周期模型03演化模型演化模型的缺點表現為：演化模型的使用仍然處于初步探索階段，因此具有較大的風險，需要進行有效的管理。該模型的使用很容易成為不編寫需求分析或設計文檔的借口，即便能夠很清晰地描述需求分析或設計也是如此。用戶/獲取方不理解該方法的自然屬性，因此當結果不夠理想時，可能產生抱怨。當需求和產品定義沒有被很好地理解，并需要快速地開發和創建一個能展示產品外貌與功能的最初版本時，特別適合使用演化模型。這些早期的增量能幫助用戶確認和調整需求并幫助他們尋找相應的產品定義。1.2.2軟件生命周期模型04原型模型原型模型是增量模型的一種形式。在開發真實系統前，首先需要構建一個簡單的系統原型，實現用戶與系統的交互，用戶在對原型進行使用的過程中，不斷發現問題，從而達到進一步細化系統需求的目的。開發人員在已有原型的基礎上，通過逐步調整原型來確定用戶的真正需求，進而開發出用戶滿意的系統。如圖1-14所示為原型模型。1.2.2軟件生命周期模型04原型模型原型模型可以克服瀑布模型的缺點，減少因為需求不明確造成的開發風險。它的關鍵之處在于，能盡可能快速地建立原型。一旦確定了用戶的真正需求，所建造的原型將被丟棄。因此，使用原型模型進行軟件開發，最重要的是必須迅速建立原型，隨之迅速修改原型，以反映用戶的需求，而不是系統的內部結構。1.2.2軟件生命周期模型05螺旋模型螺旋模型是由Boehm提出的另一種開發模型。在這一模型中，開發工作是迭代進行的，即只要完成了開發的一個迭代過程，另一個迭代過程就開始了。該模型關注解決問題的基本步驟，由此可以標識問題，標識一些可選方案，最終選擇一個最佳方案，遵循動作步驟并實施后續工作。盡管螺旋模型和一些迭代模型在框架與全局體系結構上是等同的，但它們所關注的階段及其活動是不同的。開發人員和用戶使用螺旋模型可以完成如下工作：確定目標、方案和約束。識別風險和效益的可選路線，選擇最優方案。開發本次迭代可供交付的內容。評估完成情況，規劃下一個迭代過程。交付給下一步，開始新的迭代過程。1.2.2軟件生命周期模型05螺旋模型螺旋模型是由Boehm提出的另一種開發模型。在這一模型中，開發工作是迭代進行的，即只要完成了開發的一個迭代過程，另一個迭代過程就開始了。該模型關注解決問題的基本步驟，由此可以標識問題，標識一些可選方案，最終選擇一個最佳方案，遵循動作步驟并實施后續工作。盡管螺旋模型和一些迭代模型在框架與全局體系結構上是等同的，但它們所關注的階段及其活動是不同的。開發人員和用戶使用螺旋模型可以完成如下工作：確定目標、方案和約束。識別風險和效益的可選路線，選擇最優方案。開發本次迭代可供交付的內容。評估完成情況，規劃下一個迭代過程。交付給下一步，開始新的迭代過程。1.2.2軟件生命周期模型05螺旋模型螺旋模型擴展了增量模型的管理任務范圍，因為增量模型基于以下假定：需求是最基本的，并且是唯一的風險。在螺旋模型中，決策和降低風險的空間是相當廣泛的。螺旋模型的另一個特征是，實際上只有一個迭代過程用于真正開發可交付的產品。如果項目的開發風險很大，或用戶不能確定系統需求，螺旋模型就是一個好的生命周期模型。螺旋模型強調了原型構造。需要注意的是，螺旋模型不必要求原型，但構造原型比較適合這一過程模型。螺旋模型最重要的優勢是，隨著成本的增加，風險隨之降低。時間和資金花得越多，風險越低，這恰好是在快速開發項目中所需要的。1.2.2軟件生命周期模型06統一過程模型螺旋模型最重要的優勢是，隨著成本的增加，風險隨之降低。時間和資金花得越多，風險越低，這恰好是在快速開發項目中所需要的。統一過程模型吸取已有模型的優點，克服了瀑布模型過分強調序列化和螺旋模型過于抽象的不足，總結了多年來軟件開發的最佳經驗。其優點如下：迭代化開發，提前認識風險。需求管理，及早達成共識。基于構件，搭建彈性構架。可視化建模，打破溝通壁壘。持續驗證質量，降低缺陷代價。管理變更，有序積累資產。1.2.2軟件生命周期模型06統一過程模型如圖1-15所示，在統一過程模型中，其橫向按時間順序來組織，將軟件開發周期分成4個階段，并以項目的狀態作為開發周期階段的名字：初始、細化、構造和移交。每個階段目標明確。1.2.2軟件生命周期模型06統一過程模型每個階段的結束都有一個主要里程碑，如圖1-16所示。實質上，每個階段就是兩個主要里程碑之間的時間跨度。1.2.2軟件生命周期模型06統一過程模型該模型的縱向按項目的實際工作內容——工作流來組織，如圖1-15所示。工作流通常表示為一個內聚的、有序的活動集合。在統一過程模型中有以下9個核心工作流。業務建模工作流：對整體項目業務建模。需求工作流：分析問題空間并改進需求產品。分析與設計工作流：解決方案建模并進化構架和設計產品。實現工作流：編程并改進實現和實施產品。測試工作流：評估過程和產品質量的趨勢。部署工作流：將最終產品移交給用戶。配置與變更管理工作流：統一化管理軟件配置，并降低變更的損失。項目管理工作流：控制過程并保證獲得所有項目相關人員的取勝條件。環境工作流：自動化過程并改進維護環境。1.2.2軟件生命周期模型06統一過程模型在統一過程模型中，明確體現了：計劃、需求和構架以明確的同步點一起進化。風險管理，以及如何客觀地度量進展和質量。借助提高功能的演示使系統能力得以進化。1.2.2軟件生命周期模型07敏捷過程模型敏捷過程強調短期交付、用戶的緊密參與，強調適應性而不是可預見性，強調為滿足當前的需要而不考慮將來的簡化設計，只將最必要的內容文檔化，因此也被稱為“輕量級過程”。敏捷開發保留了基本的框架活動：溝通、策劃、建模、構建和部署，但將其縮減到一個推動項目組朝著構建和交付方向發展的最小集。敏捷聯盟定義了“敏捷”需要遵循的12條原則：（1）最優先要做的事是，通過盡早和持續交付有價值的軟件使用戶滿意。（2）歡迎需求的變更，即使在軟件開發的后期也是如此。敏捷過程利用項目需求變更為用戶提升市場競爭優勢。（3）頻繁地向用戶交付可運行的軟件產品。從幾周到幾個月，交付的時間間隔越短越好。1.2.2軟件生命周期模型07敏捷過程模型（4）在整個項目開發周期中，業務人員和開發團隊應該天天在一起工作。（5）圍繞有積極性的個人來構建項目，為他們提供所需的環境和支持，并信任他們能夠完成工作。（6）在開發團隊內部，效率最高、成效最大的信息傳遞方法是面對面地交流。（7）可運行軟件是進度的首要度量標準。（8）敏捷過程提倡可持續開發。（9）不斷地關注優秀的技能和優秀的設計會增強敏捷能力。（10）簡單一把不必要的工作最小化的藝術是根本。（11）最好的構架、需求和設計源自組織團隊。（12）每隔一段時間，團隊應該反省如何才能更有效地工作，并相應調整自己的行為。1.2.3軟件過程適應預定義的軟件開發生命周期、軟件產品生命周期及單個軟件過程通常需要被修改以更好地滿足本地需求。組織環境、技術創新、項目規模、產品關鍵性、法規要求、行業慣例和企業文化可能決定需求的適應性。對單個軟件過程和軟件生命周期模型（開發和產品）的適應可能包括在軟件過程、活動、任務和程序中添加更多細節，以解決關鍵問題。它可能包括使用一組替代的活動來達到軟件過程的目的和結果。適應可能還包括從開發或產品生命周期模型中刪除一些軟件過程或活動，因為它們顯然不適合要完成的工作范圍。1.2.4實踐考慮在實踐中，軟件過程和活動常常是交叉、重疊和同時應用的。定義離散軟件過程的軟件生命周期模型，具有嚴格指定的輸入/輸出標準和規定的邊界及接口，應該被認為是一種理想化情況。很多時候，必須對其加以調整，以反映組織環境和業務環境中軟件開發和維護的現實情況。另一個實踐的考慮因素是：軟件過程（如配置管理、構造和測試）應該可以調整，以方便軟件的操作、支持、維護、遷移和退役。在定義和裁剪軟件生命周期模型時，需要考慮的補充因素包括：所需標準、指令和策略的一致性，用戶需求，軟件產品的臨界性，組織的成熟度和能力。其他因素還包括工作的性質（如現有軟件的修改與新開發軟件的關系）和應用領域（如航空航天與酒店管理）。03軟件過程評估與改進1.3.1軟件過程評估與改進模型軟件過程評估模型通常包括軟件過程的評估標準，這些過程被認為是良好的實踐。這些實踐可能只處理軟件開發過程，也可能包括軟件維護、軟件項目管理、系統工程或人力資源管理等主題。軟件過程改進模型強調持續改進的迭代周期。軟件過程改進周期通常包括測量、分析和更改的子過程。計劃一行動一檢查一執行（Plan-Do-Check-Act）模型是一種眾所周知的軟件過程改進的迭代方法。其改進活動包括：確定和優先考慮所需的改進（計劃）；引入改進，包括變更管理和培訓（行動）；與以前或示范的軟件過程結果和成本相比較，評估改進情況（檢查）；做進一步的修改（執行）。該模型可用于改進軟件過程，以增強缺陷預防。1.3.2軟件過程評估方法軟件過程評估方法可以定性或定量。定性評估依賴于專家的判斷；定量評估通過對客觀證據的分析為軟件過程打分，這些客觀證據表明已確定的軟件過程的目標和結果的實現情況。軟件過程評估的典型方法包括計劃、事實調查（問卷調查、訪談和觀察工作實踐）、收集和驗證過程數據、分析和報告等。軟件過程評估依賴于評估人主觀的、定性的判斷，或者客觀存在或未定義的工件、記錄和其他證據。根據軟件過程評估的目的，在軟件過程評估期間執行的活動和評估活動的工作分配是不同的。軟件過程評估可以用于開發對軟件過程改進提出建議的能力級別，或者用于獲得軟件過程成熟度級別，以便獲得合同或授予的資格。軟件過程評估結果的質量取決于軟件過程評估方法、獲得數據的完整性和質量、評估團隊的能力和客觀性，以及評估過程中審查的證據。軟件過程評估的目標是獲得洞察力，確定一個或多個軟件過程的現狀，并為軟件過程改進提供基礎；通過遵循一致性檢查表來執行軟件過程評估。1.3.3連續式和階段式軟件過程評估01連續式評級表示（1）不完整級。不完整級的流程是未執行或部分執行的流程。因為無法滿足流程領域的一個或多個特定目標，以及沒有將部分執行流程進行制度化，所以連續式表示能力級別0級沒有一般目標。（2）已執行級。已執行級的流程是一個能完成產出工作產品所需工作的流程，流程領域的特定目標都被滿足。由已執行級所導致的重大改善可能會隨著時間推移而失去，因為它們沒有被制度化。應用制度化（已管理級和已定義級的一般執行方法）可以確保維持改善。（3）已管理級。已管理級的流程是一個已執行的流程。它會根據政策規劃與執行流程，任用具備技能的人員，并給予足夠的資源以產出可控制的產品；納入相關的關鍵人員；進行監督、控制及審查；評估遵循流程說明的程度。已管理級所反映的流程規范，確保現有的執行方法都在有壓力的情況下，仍維持運作。1.3.3連續式和階段式軟件過程評估01連續式評級表示（4）已定義級。已定義級的流程是一個已管理級的流程。流程根據組織的指引調試組織標準流程，流程說明需要維護，并將流程相關經驗納入組織流程資產。已管理級與已定義級間的重要差異在于標準、流程說明與程序的范圍。在已管理級中，每個流程特定案例中的標準、流程說明與程序都可以有相當的差異；在已定義級中，項目的標準、流程說明與程序由組織標準流程調試而得，以符合特定項目或組織單位的要求，因此更具一致性。已定義級的流程說明通常比已管理級的嚴謹。一個已定義級流程會清楚地說明目的、輸入、允入準則、活動、角色、度量、驗證步驟、輸出、允出準則。在已定義級中，透過了解流程活動之間的互動關系及流程和工作產品的詳細度量，能夠更主動地管理流程。1.3.3連續式和階段式軟件過程評估02階段式評級表示（1）初始級。在初始級，軟件過程的特點是無秩序，有時甚至是混亂的。軟件開發組織一般不能提供開發和維護軟件的穩定環境。當組織中缺乏健全的管理實踐時，不適當的規劃和反應式的驅動體系會減少良好的軟件工程實踐所帶來的效益。初始級組織的軟件過程能力是不可預測的。（2）可重復級。在可重復級，已建立了基本的項目管理過程，可用于對成本、進度和功能特性進行跟蹤。對類似的應用項目有章可循，并能重復以往所取得的成功。達到可重復級的目的是，使軟件項目的有效管理過程制度化，這使得組織能重復在以前類似項目中的成功實踐。有效軟件過程具有如下特征：已文檔化、已實施、已培訓、已測量和能改進。處于可重復級的軟件開發組織，對軟件項目已制訂軟件管理和控制措施。對項目實際可行的軟件管理和控制措施必須是根據以前項目總結出的經驗和當前項目的實際需求而制訂的。1.3.3連續式和階段式軟件過程評估02階段式評級表示可重復級的關鍵過程域的側重點就是為軟件項目建立項目管理和控制措施。它包括以下6個關鍵過程域。①需求管理（RequirementsManagement，RM）②軟件項目計劃（SoftwareProjectsPlanning，SPP）③軟件項目跟蹤和監督（SoftwareProjeetTrackingandOversight，SPTO）④軟件轉包合同管理（SoftwareSubcontractManagement，SSM）⑤軟件質量保證（SoftwareQualityAssurance，SQA）⑥軟件配置管理（SoftwareConfigurationManagement，SCM）1.3.3連續式和階段式軟件過程評估02階段式評級表示（3）已定義級。在已定義級，用于管理的和工程的軟件過程均已文檔化、標準化，并形成了整個軟件組織的標準過程。全部項目均采用與實際情況相吻合的、適當修改后的標準軟件過程來進行操作。項目根據其特征剪裁組織的標準軟件過程，從而建立它們自己定義的軟件過程，稱為項目定義軟件過程。一個項目定義的軟件項目過程應包含一組集成的、協調的、妥善定義的軟件工程過程和管理過程。妥善定義的軟件過程具有如下特征：關于準備就緒的條件、輸入、標準，進行工作的規程、驗證機制、輸出，以及關于完成的判據等。已定義級組織的軟件過程概括為已標準化的和一致的，因為無論軟件工程活動還是管理活動，過程都是穩定的和可重復的。1.3.3連續式和階段式軟件過程評估02階段式評級表示已定義級的關鍵過程域既涉及項目，又涉及組織，因為組織建立起了對所有項目都有效的軟件工程過程和管理過程規范化的基礎設施。已定義級的關鍵過程域包括以下7個。①組織過程焦點（OrganizationProcessFocus，OPF）②組織過程定義（OrganizationProcessDefinition，OPD）③培訓程序（TrainingProgram，TP）④集成軟件管理（IntegratedSoftwareManagement，ISM）⑤軟件產品工程（SoftwareProductEngineering，SPE）⑥組間協調（IntergroupCoordination，IC）⑦同級評審（PeerReviews，PR）1.3.3連續式和階段式軟件過程評估02階段式評級表示（4）已管理級。在已管理級，軟件過程和產品質量有詳細的度量標準。軟件過程和產品質量得到了定量的認識和控制。組織對軟件過程和產品都設置了定量的質量目標，并經常對此進行測量和檢查。作為組織測量大綱的一部分，所有項目都對其重要的軟件過程活動、生產率和質量進行測量和檢查。利用一個全組織的軟件過程數據庫收集和分析從項目定義軟件過程中得到的數據。已管理級的軟件過程均已配備有妥善定義的和一致的度量，這些度量為定量地評價項目的軟件過程和產品打下基礎。1.3.3連續式和階段式軟件過程評估02階段式評級表示在已管理級，軟件過程具有精確定義的、一致的評價方法，這些評價方法為評估項目的軟件產品和質量奠定了一個量化的基礎。量化控制將使軟件開發真正變成一種工業生產活動。已管理級的關鍵過程域包括以下兩個。①定量過程管理（QuantityProeessManagement，QPM）②軟件質量管理（SoftwareQualityManagement，SQM）1.3.3連續式和階段式軟件過程評估02階段式評級表示（5）優化級。在優化級，通過對來自軟件過程、新概念和新技術等方面的各種有用信息的定量分析，能夠不斷地、持續性地對軟件過程進行改進。為了預防缺陷出現，組織應能夠有效地識別出軟件過程的弱點，并預先加強防范。在采用新技術并建議更改全組織的標準軟件過程之前，必須進行費用效益分析。在費用效益分析中，應充分利用采集的有關軟件過程有效性的數據。。優化級的關鍵過程域包括以下三個：缺陷預防；技術改革管理；過程變更管理。04軟件過程工具1.4軟件過程工具軟件過程工具能幫助組織或團隊定義完整的軟件過程模型（框架活動、質量保證檢查點、里程碑和工作產品等），也能為軟件工程師與項目經理跟蹤和控制軟件過程提供技術路線圖或模板。代表性的工具介紹如下。（1）GDPA這是由德國的Bremen大學（http：//rmatik.uni-bremen.de/uniform/gdpa）開發的一套軟件過程定義工具包，它提供了大量的軟件過程建模和管理工具。1.4軟件過程工具（2）ALM平臺應用程序生命周期管理（ApplicationLifecyeleManagement，ALM）是指軟件開發從需求分析開始，歷經項目規劃、項目實施、配置管理、測試管理等階段，直至最終被交付或發布的全過程管理。典型的ALM平臺包括需求管理、項目規劃、項目跟蹤與執行、質量保證和版本管理等功能模塊。目前市面上比較流行的ALM平臺有Integrity（PTC）、Polarian（Simense）、RationalALM（IBM）、PVCSProfessional（Serena）、HPEApplicationLifecycleManagement（MicroFocus）和DevSuite（TechExcel）。1.4軟件過程工具按照工具類型不同又可細分如下。知識管理：TechExcelKnowledgeWise（TechExcel）。需求管理：DOORSTelelogic（IBM）、TechExcelDevSpec（TechExcel）。缺陷跟蹤：RationalClearQuest（IBM）、TechExcelDevTrack（TechExcel）、TeamTrack（Serena）、StarTeam（Borland）。項目規劃和項目管理：MSProject（Microsoft）、VisualStudioTeamSystem（Microsoft）、TechExcelDevPlan（TechExcel）。測試管理：TechExcelDevTest（TechExcel）。配置管理：RationalClearCase（IBM）、TechExcelVersionLink（TechExcel）、Firefly（Hansky）。1.4軟件過程工具（3）ProVisionBPMx這是由OpenText公司（https：//）開發的一套工具包，提供了很多可以輔助軟件過程定義和工作流自動化的工具。更多和軟件過程相關的工具還可以從SWEBOK網站（https：//puterorg/web/swebok）上獲取。目前，越來越多的軟件過程工具可以支持在地理位置上分散的（虛擬）團隊合作的項目，軟件工程人員可以通過云計算工具和專門的基礎設施來使用。感謝觀看軟件工程過程：原理、方法與工具第二章軟件工程過程：原理、方法與工具軟件工程模型與方法01建模2.1.1建模的原則建模為軟件工程師提供了一種系統的方法，用于表示正在研究的軟件的重要方面，促進做出關于軟件或其中元素的決策，并將這些重要決策傳達給利益相關社區中的其他人。指導此類建模活動有三個通用的原則。①建模要點：好的模型通常并不代表軟件在每種可能條件下的所有方面或特征。建模通常只涉及所開發軟件中需要特定答案的那些方面或特征，抽象出任何不必要的信息。這種方法使模型易于管理和有用。②提供透視：建模提供了正在研究的軟件的視圖，并使用一組定義的規則來表達每個視圖中的模型。這種透視驅動方法為模型提供了維度（如結構視圖、行為視圖、時態視圖、組織視圖和其他相關視圖）.將信息組織到視圖中需要使用適當的符號、詞匯、方法和工具，并將建模工作集中在與該視圖相關的特定問題上。③啟用有效的通信：建模需要使用軟件應用領域的詞匯表、建模語言和語義表達。2.1.2模型的性質與表達模型的性質是區分特定模型的顯著特征，用于表征所選建模符號及所用工具的完整性、一致性和正確性。模型的性質包括以下內容。完整性：在模型中實現和驗證所有需求的程度。一致性：模型不包含沖突的需求、斷言、約束、功能或組件描述的程度。正確性：模型滿足其需求和設計規范而無缺陷的程度。模型用于表示現實世界中的對象及其行為，以回答有關軟件如何運行的特定問題。通過探索、模擬或審查的方式來詢問模型，可能會暴露模型和模型所涉及軟件中的不確定性區域。這些不確定性，以及與需求、設計和實現有關的未解答的問題可以被適當地處理。模型的主要表示元素是實體。實體可以表示具體工件（如處理器、傳感器或機器人）或抽象工件（如軟件模塊或通信協議）。2.1.3語法、語義和語用理解建模結構的精確含義也是很困難的。建模語言是通過語法和語義規則來定義的。對于文本建模語言，語法是使用定義有效語言結構的符號語法定義的，如巴科斯范式（Backus-NORForm，BNF）。對于圖形建模語言，語法是使用稱為元模型的圖形模型定義的。與BNF一樣，元模型定義了圖形建模語言的有效語法結構，同時也定義了如何組合這些構造來生成有效的模型。建模語言的語義指定了附加到模型中的實體和關系的意義。例如，由一條線連接的兩個盒子組成的簡單圖表可以進行多種解釋。從實際出發選擇建模語言，有利于理解特定軟件模型的語義，包括如何使用該建模語言來表達該模型中的實體和關系，建模者的經驗基礎，以及建模所處的上下文。意義是通過模型傳遞的，即使在信息不完整的情況下也是通過抽象來傳達的。語用學解釋了意義是如何體現在模型及其上下文中的，并有效地傳達給其他軟件工程師。2.1.4前置條件、后置條件和不變量當對功能或方法進行建模時，軟件工程師通常從一組假設開始。這些假設是在功能或方法執行之前、期間和之后對軟件的狀態進行的。這些假設對于功能或方法的正確操作至關重要，并作為一組前置條件、后置條件和不變量進行分組討論。前置條件：在執行功能或方法之前必須滿足的一組條件。如果這些前置條件在執行功能或方法之前不成立，則該功能或方法可能產生錯誤的結果。后置條件：在功能或方法成功執行后保證為真的一組條件。通常，后置條件表示軟件狀態如何變化、傳遞給功能或方法的參數如何變化、數據如何變化或者返回值如何受到影響。不變量：操作環境中的一組條件。它們在功能或方法執行之前和之后持續存在。這些不變量對于軟件和功能或方法的正確操作是相關的，也是必要的。02模型的類型2.2模型的類型信息模型集中關注數據和信息。信息模型是一種抽象表示，用于標識和定義數據實體的一組概念、屬性、關系及約束。從問題的角度來看，語義或概念信息模型通常用于為正在建模的軟件提供一些形式和上下文，而不關心該模型如何實際映射到軟件的實現上。語義或概念信息模型是一種抽象，因此它僅包含概念化信息的真實世界視圖所需的概念、屬性、關系及約束。隨后對語義或概念信息模型的轉換，將導致在軟件中實現的邏輯模型和物理數據模型的細化。01信息模型2.2模型的類型行為模型識別并定義被建模軟件的功能。行為模型一般采用三種基本形式：狀態機、控制流模型和數據流模型。狀態機將軟件模型提供為已定義狀態、事件和轉換的集合。軟件通過在建模環境中發生的保護或無保護的觸發事件的方式，從一種狀態轉換為另一種狀態。控制流模型描述了一系列事件如何導致進程被激活或停用。數據流行為的典型代表是數據通過進程向數據存儲或數據接收器移動的一系列步驟。02行為模型2.2模型的類型結構模型說明了軟件的物理或邏輯組成。結構模型確定了正在實施或建模的軟件與其運行環境之間的定義邊界。結構模型中使用的一些常見結構構造方式有實體的組合、分解、泛化和特化，確定實體之間的相關關系和基數，過程或功能接口的定義。UML為結構模型提供的結構圖包括類、組件、對象、部署和包圖。03結構模型03模型分析2.3模型分析為了使軟件完全滿足干系人的需求，從需求獲取過程到代碼實現，完整性至關重要。完整性是指所有指定需求都已實現和驗證的程度。模型的完整性檢查可以使用結構分析和狀態空間可達性分析（確保狀態模型中的所有路徑都由一組正確的輸入到達）等技術的建模工具自動完成，也可以使用檢查或其他評審技術（如軟件質量評審）手動實現。如果發現錯誤和警告，則表明需要采取糾正措施，以確保模型的完整性。01完整性分析一致性是指模型不包含沖突的需求、斷言、約束、功能或組件描述的程度。通常，模型的一致性檢查可以使用建模工具的自動分析功能完成，也可以使用檢查或其他評審技術手動實現。與完整性一樣，如果發現錯誤和警告，則表明需要采取糾正措施。02一致性分析2.3模型分析正確性是指模型滿足其軟件需求和軟件設計規范，沒有缺陷，并最終滿足干系人的需求的程度。正確性分析包括驗證模型的語法正確性（正確使用建模語言的語法和結構）和驗證模型的語義正確性（正確使用建模語言的結構來表示模型的含義）。對于要分析語法和語義正確性的模型，可以自動分析（如使用建模工具檢查模型語法正確性），或手動查找（如使用檢查或其他評審技術）可能的缺陷，然后在軟件發布之前刪除或修復已確認的缺陷。03正確性分析2.3模型分析開發軟件通常涉及許多工作產品的使用、創建和修改，如計劃文檔、過程規范、軟件需求規格說明書、圖表、設計和偽代碼、手寫和工具生成的代碼、手動或自動的測試用例和報告及文件和數據。這些工作產品可能通過各種依賴關系（如使用、實現和測試）進行關聯。伴隨軟件的開發、管理、維護或擴展，需要映射和控制這些可追溯關系，以證明軟件需求與模型和許多工作產品的一致性。使用可追溯性通常可以改善軟件工作產品的管理和軟件過程的質量，它還向干系人提供所有需求已得到滿足的保證。一旦軟件被開發和發布，可追溯性就可以進行變更分析，因為可輕松變更其與工作產品的關系，以評估變更帶來的影響。建模工具通常提供一些自動或手動方法來規范和管理需求、設計、代碼和測試實體之間的可追溯性鏈接，正如模型和其他工作產品中所表示的那樣。04可追溯性分析2.3模型分析交互分析的重點是用于在模型中完成特定任務或功能的實體之間的通信流或控制流關系。該分析檢查模型不同部分之間交互的動態行為，包括其他軟件層（如操作系統、中間件和應用程序）。對于某些應用程序來說，檢查應用程序和用戶界面之間的交互也很重要。一些建模環境軟件為研究軟件建模的動態行為提供了仿真工具。仿真為軟件工程師提供了一個分析選項，可以審查交互設計，并驗證軟件的不同部分能夠協同工作，以提供預期的功能。05交互分析04軟件工程方法2.4.1啟發式方法啟發式方法是基于經驗的軟件工程方法，已在軟件產業中得到了廣泛的應用。該主題領域包含三個廣泛的討論類別：結構化分析和設計方法、數據建模方法及面向對象的分析和設計方法。結構化分析和設計方法：模型主要從功能或行為角度開發，從軟件的高級視圖（包括數據和控制元素）開始，然后通過越來越詳細的設計逐步分解或細化模型組件。詳細設計最終會匯聚到非常具體的軟件細節或規范上。這些細節或規范必須被編碼（手動、自動生成或同時生成）、構建、測試和驗證。數據建模方法：數據模型是從所使用的數據或信息的角度構建的。數據表和關系定義該數據模型。這種數據建模方法主要用于定義和分析支持數據庫設計或數據庫存儲的數據需求。這些需求通常存在于業務軟件中，其中數據作為業務系統資源或資產進行主動管理。面向對象的分析和設計方法：面向對象模型表示為封裝數據和關系，并通過方法與其他對象交互的一組對象的集合。對象可以是真實世界的項目，也可以是虛擬的項目。模型使用圖表構建，以構成軟件的選定視圖。模型的逐步細化形成了詳細設計。然后，詳細設計通過連續迭代或者使用某種機制將其轉換并演化為模型的實現視圖，其中包含了最終軟件產品發布和部署的代碼及打包方法。2.4.2形式化方法式化方法通過應用嚴格的基于數學的符號和語言來指定、開發和驗證軟件。該方法使用規范語言，以系統、自動或半自動的方式檢查軟件模型的一致性、完整性和正確性。形式化方法涉及規范語言、程序細化和導出、形式驗證和邏輯推理。規范語言：規范語言為形式化方法提供數學基礎。規范語言是在軟件規范、需求分析和設計階段用于描述特定輸入/輸出行為的形式化高級計算機語言（不是經典的第三代編程語言）。規范語言不是直接可執行的語言，它通常由符號、語法、使用符號的語義和一組對象允許的關系組成。程序細化和導出：程序細化是通過一系列轉換來創建較低級別（或更詳細）規范的過程。通過連續的轉換，軟件工程師導出程序的可執行表示形式。可以對規范進行細化，添加細節，直到模型可以用第三代編程語言或所選規范語言的可執行部分來表述為止。這種細化是通過定義具有精確語義屬性的規范來實現的。規范不僅必須列出實體之間的關系，而且必須闡明這些關系和操作的確切運行時含義。2.4.2形式化方法式化方法通過應用嚴格的基于數學的符號和語言來指定、開發和驗證軟件。該方法使用規范語言，以系統、自動或半自動的方式檢查軟件模型的一致性、完整性和正確性。形式化方法涉及規范語言、程序細化和導出、形式驗證和邏輯推理。形式驗證：模型檢查是一種正式的驗證方法。它通常涉及執行狀態空間探索或可達性分析，以證明所代表的軟件設計具有或保留了某些感興趣的模型屬性。模型檢查的一個例子是在事件或消息到達的所有可能情況下驗證程序行為的分析。形式驗證需要嚴格指定模型及其操作環境。該模型通常采用有限狀態機或其他形式定義的自動機的形式。邏輯推理：邏輯推理是一種設計軟件的方法。它涉及在設計的每個重要模塊周圍指定前置條件和后置條件，并使用數學邏輯開發那些前置條件和后置條件必須在所有輸入下保持的證明。這為軟件工程師提供了一種在不必執行軟件的情況下預測軟件行為的方法。一些集成開發環境（IntegratedDevelopmentEnvironments，IDE）包含了表示這些證明的方法及設計或代碼。2.4.3原型方法軟件原型設計是一種創建不完整或最低功能版本的軟件的活動，通常用于嘗試特定的新功能，征求對軟件需求或用戶界面的反饋，進一步探索軟件需求、軟件設計或實現選項，以及獲得對軟件的一些其他有用的見解。軟件工程師首先選擇一種原型方法來理解軟件中最不易理解的方面或組件。這種方法與其他軟件工程方法不同，后者通常首先從最易理解的部分開始開發。通常，如果不進行大量的開發返工或重構，原型產品就不會成為最終的軟件產品。原型類型：這涉及開發原型的各種方法。原型可以作為丟棄的代碼或紙產品被開發出來，可以作為新的軟件設計的藍本，也可以作為可執行的規范。原型類型的選擇基于項目所需的結果類型、質量及緊迫性。原型目標：原型的目標是指原型設計工作所服務的特定產品。原型目標可以是需求規范、架構設計元素或組件、算法或人機界面。原型評估技術：軟件工程師或其他干系人可以通過多種方式使用或評估原型，主要由最初導致原型開發的潛在原因驅動。原型可以根據實際實施的軟件或目標需求集（如需求原型）進行評估或測試。原型還可以作為未來軟件開發工作的模型（如在用戶界面規范中）。2.4.4敏捷方法敏捷方法誕生于20世紀90年代，因為需要減少大型軟件開發項目中使用基于計劃的重量級方法的巨大開銷。敏捷方法被認為是輕量級方法，因為它的特點是：迭代開發周期短、自行組織團隊、設計更簡單、代碼重構、測試驅動開發、用戶參與頻繁，以及強調在每個開發周期中創建一個可演示的工作產品。RAD：主要用于數據密集型業務系統的應用程序開發。XP：將故事或場景用于需求分析。Scrum：這種敏捷方法比其他方法更適合項目管理。FDD：這是一種模型驅動的、簡短的、迭代的軟件開發方法，其過程包括5個階段：①開發一個產品模型以涵蓋領域的范圍；②創建需求或特征列表；③構建特征開發計劃；④為迭代特定的特征進行設計；⑤編碼、測試和集成這些特征。FDD類似于增量軟件開發方法。它也類似于XP，只不過代碼所有權分配給了個人而不是團隊。FDD強調軟件的整體架構方法，這有助于在第一次就正確地構建功能，而不是強調持續重構。感謝觀看軟件工程過程：原理、方法與工具第三章軟件工程過程：原理、方法與工具軟件需求01基本概念IEEE軟件工程標準詞匯表中定義需求為：（1）用戶為了解決問題或達到某些目標所需要的條件或能力。（2）系統或系統部件為了滿足合同、標準、規范或其他正式文檔所規定的要求而需要具備的條件或能力。（3）對（1）或（2）的一個條件或一種能力的一種文檔化表述。IEEE的定義中同時包括了用戶的觀點（1）和開發者的觀點（2），它強調了“需求”的兩個不可分割的方面：需求是以用戶為中心的，是與問題相聯系的；需求要被清晰、明確地寫在文檔中。3.1.2軟件需求層次3.1.2軟件需求層次01業務需求業務需求描述組織為什么要執行系統（組織希望獲得的業務收益）。其關注點在于組織或者提出系統要求的用戶有哪些業務目標。我們假設有家航空公司打算把機場的柜臺工作人員成本降低25%，為此，人們通常想到的解決方案是建一個自助服務終端，供乘客在機場自行辦理登機手續。軟件項目的出資方、目標用戶、實際用戶的管理層、市場部門或者產品規劃部門一般都會有業務需求。人們喜歡將業務需求記錄在愿景或范圍文檔之中。還有一些戰略性指導文檔有時也會用于此目標，包括項目圖表、業務實例及市場（或者營銷）需求文檔。3.1.2軟件需求層次02用戶需求用戶需求描述了用戶使用軟件產品必須完成的目標或者任務，并且這個軟件產品要能夠為用戶提供價值。用戶需求還包括對用戶滿意度最為關鍵的軟件產品特性或特征的描述。用例、用戶故事及事件響應表都是用戶需求的表示方式。在理想狀態下，這種信息由實際用戶代表提供。用戶需求表達的是，用戶希望通過系統來完成哪些具體工作。通過機場自助服務終端“辦理登機手續”是“用例”的典型例子。如果將其寫為“用戶故事”，同樣的用戶需求可能是這樣的：“作為一名乘客，我想辦理登機手續，以便能夠登機。”還有一點不能忘記，即大多數軟件項目都有若干個用戶類別和其他干系人，還必須獲取他們的需求。3.1.2軟件需求層次03功能需求功能需求說的是軟件產品在特定條件下所展示出來的行為，主要描述開發人員需要實現的功能以便用戶能夠完成自己的任務（用戶需求），進而滿足業務需求。可見，這三種需求環環相扣，對軟件項目的成功至關重要。人們經常將功能需求記錄為傳統意義上的“應當”句式：“乘客應當能夠隨時打印自己已經辦好登機手續的所有航段的登機牌”，或者“如果乘客沒有指定座位偏好，航班預訂系統就應當為他分配座位”。3.1.3軟件需求分類01功能需求和非功能需求根據需求是否有效，可以將需求分為功能需求和非功能需求。功能需求是和系統主要工作相關的需求，即：在不考慮物理約束的情況下，用戶希望系統能夠執行的活動，這些活動可以幫助用戶完成任務。功能需求主要表現為系統和環境之間的行為交互。非功能需求包括性能需求、質量屬性、對外接口、約束這4個類別。其中，質量屬性對系統成敗的影響極大，因此在某些情況下，非功能需求又被用來特指質量屬性。性能需求是系統整體或其組成部分應該擁有的性能特征。3.1.3軟件需求分類02產品需求和過程需求根據需求是產品的還是過程的，將需求分為產品需求和過程需求。對過程的需求可能會約束合同的選擇、要采用的軟件過程或要遵守的標準。產品需求是要開發的軟件的需求或約束（如“軟件應確保學生在注冊課程之前滿足所有前置條件”）。過程需求本質上是對軟件開發的約束（如“軟件應該使用RUP過程開發”）。某些軟件需求會產生隱式的過程需求。確認技術的選擇就是一個例子。另一個例子是使用非常嚴格的分析技術（如正式的規范方法）來減少可能導致軟件不可靠的故障。過程需求也可由開發組織、客戶或第三方（如安全監管機構）直接強制執行。3.1.3軟件需求分類03緊急需求一些需求是軟件的緊急屬性，即單個組件無法解決這個需求，而需要所有的軟件組件相互操作。例如，呼叫中心的吞吐量取決于電話系統、信息系統和運營商在實際操作條件下如何互動。緊急屬性非常依賴于系統架構。04量化需求軟件需求規格說明應盡量清楚、明確，并在適當情況下進行量化。重要的是，避免模糊和無法確認的需求，即取決于主觀判斷解釋的需求（如“軟件應該是可靠的”“軟件應該是用戶友好的”）。這對于非功能需求尤為重要。量化需求規格說明的兩個例子如下：呼叫中心的吞吐量必須提高20%；系統運行過程中，1小時之內產生致命錯誤的概率要小于1×10°。吞吐量需求處于非常高的位置，需要用于獲取許多詳細的需求。3.1.3軟件需求分類05系統需求和軟件需求系統需求中，“系統”是指元素通過相互作用來實現既定的目標，這些元素包括由國際軟件和系統工程委員會（InternationalCouncilonSoftwareandSystemsEngineering，INCOSE）定義的硬件、軟件、固件、人員、信息、技術、設施、服務和其他支持元素。系統需求是整個系統的需求。在包含所有軟件組件的系統中，軟件需求來源于系統需求。以有限的方式定義“用戶需求”，作為系統客戶或最終用戶的需求。系統需求包括用戶需求、其他干系人（如監管機構）的需求，以及非可識別人力資源的需求。3.1.3軟件需求分類06需求優先級優先級越高，滿足軟件總體目標的需求就越重要。通常按固定點等級進行分類，如強制的、高度期望的、可取或可選的。優先級通常與開發和實施的成本平衡。07需求的范圍需求的范圍是指需求對軟件和軟件組件的影響程度。某些需求，特別是某些非功能需求，具有全局范圍，因為它們的滿意度不能分配給離散組件。因此，具有全局范圍的需求可能會強烈地影響軟件架構和許多組件的設計，而具有局部范圍的需求可能會提供許多設計選擇，并且對其他需求的滿意度幾乎沒有影響。3.1.3軟件需求分類08波動性或穩定性一些需求會在軟件的生命周期中發生變化，甚至在開發過程中也會發生變化。如果可以對需求發生變化的可能性進行一些估計，這將非常有用。例如，在銀行應用程序中，計算和計入客戶賬戶利息的功能需求可能比支持特定類型的免稅賬戶的需求更穩定。前者反映了銀行業領域的一個基本特征（可以賺取利息），而后者可能會因政府立法的變化而過時。標記潛在的不穩定需求可以幫助軟件工程師建立容錯性更好的設計。3.1.4需求工程01起始如何開始一個軟件項目？有沒有一個獨立的事件能夠成為新的基于計算機的系統或產品的催化劑？需求會隨時間的推移而發展嗎？這些問題沒有確定的答案。在某些情況下，一次偶然的交談就可能導致大量的軟件工程工作。但是多數軟件項目都是在確定了商業要求或發現了潛在的新市場、新服務后才開始的。業務領域的干系人（如業務管理員、市場人員、產品管理人員）定義業務用例，確定市場的寬度和深度，進行粗略的可行性分析，并確定項目范圍的工作說明。所有這些信息都取決于變更，但是應該充分地與軟件工程組織及時進行討論。在項目起始階段，要建立基本的理解，包括：存在什么問題？誰需要解決問題？所期望的解決方案的性質是什么？干系人和開發人員之間達成初步交流合作的效果如何？3.1.4需求工程02獲取軟件系統或軟件產品的目標是什么？想要實現什么？軟件系統和軟件產品如何滿足業務的要求？最終軟件系統或軟件產品如何用于日常工作？這些問題看上去非常簡單，但實際上并非如此。獲取階段最重要的是建立目標。軟件工程師的工作就是與干系人約定，鼓勵他們誠實地分享目標。一旦抓住目標，就應該建立優化機制，并（為滿足干系人的目標）建立潛在架構的合理性設計。范圍問題發生在系統邊界不清楚的情況下，或用戶的說明帶有不必要的技術細節，這些細節可能會導致混淆而不是澄清系統的整體目標。理解問題一般發生在用戶并不完全確定自己需要什么的情況下，包括：對其計算環境的能力和限制所知甚少，對問題域沒有完整的認識，與需求工程師在溝通上存在問題，忽略了那些他們認為是“明顯的”信息，確定的需求和其他用戶的需求相沖突，需求規格說明有歧義或不可測試。易變問題一般發生在需求隨時間推移而變更的情況下。為了幫助解決這些問題，需求工程師必須以有組織的方式開展需求收集活動。3.1.4需求工程03細化在起始和獲取階段獲得的信息將在細化階段進行擴展和提煉。該任務的核心是開發一個精確的需求模型，用以說明軟件的功能、特征和信息的各個方面。細化是由一系列的用戶場景建模和求精任務驅動的。這些用戶場景描述了如何讓最終用戶和其他參與者與系統進行交互。解析每個用戶場景以便提取分析類—一最終用戶可見的業務域實體。應該定義每個類的屬性，確定每個類所需要的服務，確定類之間的關聯和協作關系，并完成各種補充圖。3.1.4需求工程04協商業務資源有限，而用戶卻提出了過高的要求，這是常有的事。另一個相當常見的現象是，不同的用戶提出了相互沖突的需求，并堅持“我們的特殊要求是至關重要的”。需求工程必須通過協商來調整沖突。應該讓用戶和其他干系人對各自的需求進行排序，然后按優先級討論沖突。使用迭代的方法給需求排序，評估每項需求的成本和風險，處理內部沖突，刪除、組合或修改需求，以便參與各方均能達到一定的滿意度。3.1.4需求工程05規格說明在基于計算機的系統（和軟件）的環境下，術語“規格說明”對不同的人有不同的含義。規格說明可以是一份寫好的文檔、一套圖形化的模型、一個形式化的數學模型、一組使用場景、一個原型或上述各項的任意組合。有人建議應該開發一個“標準模板”并將之用于規格說明。他們認為這樣將促使以一致的從而也更易于理解的方式來表示需求。然而，在開發規格說明時保持靈活性也是必要的。對大型系統而言，文檔最好采用自然語言和圖形化模型來編寫。而對于技術環節明確的較小軟件產品或軟件系統，使用場景可能就足夠了。3.1.4需求工程06確認在確認這一步將對需求工程的工作產品進行質量評估。需求確認要檢查規格說明，并保證以下內容：已無歧義地說明了所有的系統需求；已檢測出不一致性、疏忽和錯誤，并予以糾正；工作產品符合為過程、項目和產品建立的標準。07管理對于基于計算機的系統，其需求會變更，而且變更的需求將貫穿于系統的整個生命周期。需求管理是用于幫助項目組在項目進展中標識、控制和跟蹤