軟件工程過程：原理、方法與工具PPT完整全套教學(xué)課件

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