軟件工程理論與實踐（第3版）全套教學(xué)課件

第1章軟件工程概述全套可編輯PPT課件目錄2第一節(jié)軟件的概念及特點第二節(jié)

軟件危機第四節(jié)

軟件工程第五節(jié)

軟件開發(fā)方法第六節(jié)

軟件工程工具第七節(jié)

職業(yè)道德第三節(jié)

軟件工程軟件的概念及特點軟件的概念

計算機軟件是由專業(yè)人員開發(fā)并長期維護(hù)的軟件產(chǎn)品。完整的軟件產(chǎn)品包括了在各種不同容量和體系結(jié)構(gòu)計算機上的可執(zhí)行的程序，運行過程中產(chǎn)生的各種結(jié)果，以及以硬復(fù)制和電子表格等多種方式存在的軟件文檔。4軟件的特點51）具有抽象性2）無明顯的制造過程3）存在退化問題4）對計算機系統(tǒng)有著不同程度的依賴性5）尚未完全擺脫人工的開發(fā)方式6）軟件本身是復(fù)雜的7）成本相當(dāng)昂貴8）相當(dāng)多的軟件工作涉及社會因素第二節(jié)軟件危機1.2.1軟件危機的表現(xiàn)與原因1.2.2軟件危機的啟示1.2軟件危機1.2.1軟件危機的表現(xiàn)與原因在軟件開發(fā)的過程中，會經(jīng)常出現(xiàn)一些不能按時完成任務(wù)、產(chǎn)品質(zhì)量得不到保證、工作效率低下和開發(fā)經(jīng)費嚴(yán)重超支等現(xiàn)象。計算機軟件的開發(fā)、維護(hù)和應(yīng)用過程中普遍出現(xiàn)的這一些嚴(yán)重的問題便是軟件危機。主要表現(xiàn)1）產(chǎn)品的功能或特性與需求不符2）相比硬件，軟件代價過高3）質(zhì)量難以保證，難以發(fā)揮硬件潛能4）難以準(zhǔn)確估計開發(fā)、維護(hù)的費用和開發(fā)周期5）難以控制開發(fā)風(fēng)險，開發(fā)速度趕不上市場變化6）軟件產(chǎn)品修改、維護(hù)困難7）軟件文檔不完備，存在內(nèi)容與產(chǎn)品不符的情況71.2軟件危機1.2.2軟件危機的啟示

軟件危機給我們的最大啟示，是使我們更加深刻的認(rèn)識到軟件的特性以及軟件產(chǎn)品開發(fā)的內(nèi)在規(guī)律。軟件產(chǎn)品是復(fù)雜的人造系統(tǒng)，具有復(fù)雜性、不可見性和易變性，難以處理。個人或小組在開發(fā)小型軟件時使用到的非常有效的編程技術(shù)和過程，在開發(fā)大型、復(fù)雜系統(tǒng)時難以發(fā)揮同樣的作用。從本質(zhì)上講，軟件開發(fā)的創(chuàng)造性成分很大、發(fā)揮的余地也很大，很接近于藝術(shù)。它介于藝術(shù)與工程之間的某一點，并逐步向工程一段漂移，但很難發(fā)展到完全的工程。81.2軟件危機1.2.2軟件危機的啟示計算機和軟件技術(shù)的快速發(fā)展，提高了用戶對軟件的期望，促進(jìn)了軟件產(chǎn)品的演化，對軟件產(chǎn)品提出了新的、更多的需求，難以在可接受的開發(fā)進(jìn)度內(nèi)保證軟件的質(zhì)量。幾乎所有的軟件項目都是新的，而且是不斷變化的。項目需求在開發(fā)過程中會發(fā)生變化，而且很多原來預(yù)想不到的問題會出現(xiàn)，對設(shè)計和實現(xiàn)手段進(jìn)行適當(dāng)?shù)恼{(diào)整是不可避免的?！叭嗽律裨挕爆F(xiàn)象——生產(chǎn)力與人數(shù)并不成正比。9第三節(jié)軟件工程1.3.1軟件工程的概念1.3.2軟件工程的基本目標(biāo)和原則1.3.3軟件過程1.3軟件工程1.3.1軟件工程的概念I(lǐng)EEE對軟件工程的定義為：1）將系統(tǒng)化、嚴(yán)格約束的、可量化的方法應(yīng)用于軟件的開發(fā)、運

行和維護(hù)，即將工程化應(yīng)用于軟件2）對1）中所述方法的研究具體說來，軟件工程是以借鑒傳統(tǒng)工程的原則、方法，以提高質(zhì)量，降低成本為目的指導(dǎo)計算機軟件開發(fā)和維護(hù)的工程學(xué)科。它是一種層次化的技術(shù)111.3軟件工程工具層方法層過程層質(zhì)量保證層12工程學(xué)計算機科學(xué)管理學(xué)經(jīng)濟學(xué)心理學(xué)數(shù)學(xué)1.3軟件工程1.3.1軟件工程的概念軟件工程的根基在于對質(zhì)量的關(guān)注；軟件工程的基礎(chǔ)是過程層，它定義了一組關(guān)鍵過程區(qū)域的框架，使得軟件能夠被合理和及時地開發(fā)；軟件工程的方法提供了建造軟件在技術(shù)上需要“做什么”，它覆蓋了一系列的任務(wù)，包括需求分析、設(shè)計、編程、測試和支持等；軟件工程的工具對過程和方法提供了自動的或半自動的支持。而軟件工程本身是一個交叉學(xué)科，涉及多種學(xué)科領(lǐng)域的相關(guān)知識，包括工程學(xué)、數(shù)學(xué)、計算機科學(xué)、經(jīng)濟學(xué)、管理學(xué)、心理學(xué)等。1.3軟件工程1.3.1軟件工程的14關(guān)注質(zhì)量過程方法工具軟件工程1.3.2軟件工程研究的內(nèi)容

軟件工程研究的內(nèi)容主要包括以下兩個部分：軟件開發(fā)技術(shù):主要研究軟件開發(fā)方法、軟件開發(fā)過程、軟件開發(fā)工具和環(huán)境。軟件開發(fā)過程管理:主要研究軟件工程經(jīng)濟學(xué)和軟件管理學(xué)。三要素

目標(biāo)1.3軟件工程1.3.2軟件工程的基本目標(biāo)和原則軟件工程要達(dá)到的基本目標(biāo)包括：達(dá)到要求的軟件功能取得較好的軟件性能開發(fā)出高質(zhì)量的軟件付出較低的開發(fā)成本需要較低的維護(hù)費用能按時完成開發(fā)工作，及時交付使用軟件工程的7條基本原則：用分階段的生命周期計劃進(jìn)行嚴(yán)格的管理堅持進(jìn)行階段評審實行嚴(yán)格的版本控制采用現(xiàn)代程序設(shè)計技術(shù)軟件工程結(jié)果應(yīng)能清楚的審查開發(fā)小組的人員應(yīng)該少而精承認(rèn)不斷改進(jìn)軟件工程實踐的必要性151.3軟件工程1.3.1軟件過程軟件的誕生和生命周期是一個過程，我們總體上稱這個過程為軟件過程。軟件過程是為了開發(fā)出軟件產(chǎn)品，或者是為了完成軟件工程項目而需要完成的有關(guān)軟件工程的活動，每一項活動又可以分為一系列的工程任務(wù)。任何一個軟件開發(fā)組織，都可以規(guī)定自己的軟件過程，所有這些過程共同構(gòu)成了軟件過程。過程定義了運用方法的順序，應(yīng)該交付的文檔資料，為保證軟件質(zhì)量和協(xié)調(diào)變化所需要采取的管理措施，以及標(biāo)志軟件開發(fā)各個階段任務(wù)完成的里程碑。通常，使用生命周期模型簡潔地描述軟件過程。生命周期模型規(guī)定了把生命周期劃分為哪些階段及各個階段的執(zhí)行順序，因此也稱為過程模型。16第四節(jié)軟件過程模型瀑布模型快速原型模型增量模型螺旋模型噴泉模型基于組件的開發(fā)模型統(tǒng)一軟件開發(fā)過程模型幾種模型的對比幾種模型之間的關(guān)系選擇軟件過程模型FourThreeTwoOne在軟件工程中，人們通過建立抽象的軟件過程模型，把軟件生命周期中的各個活動或步驟安排到一個框架中，將軟件開發(fā)的全過程清晰且直觀地表達(dá)出來。軟件過程模型的特點：描述了主要的開發(fā)階段定義了每個階段要完成的主要任務(wù)和活動規(guī)范了每個階段的輸入和輸出提供了一個框架，把必要的活動映射到這個框架中18軟件過程模型瀑布模型瀑布模型是一種線性的開發(fā)模型，具有不可回溯性。開發(fā)人員必須等前一階段的任務(wù)完成后，才能開始進(jìn)行后一階段的工作，并且前一階段的輸出往往就是后一階段的輸入。由于其不可回溯性，如果在軟件生命周期的后期發(fā)現(xiàn)并要改正前期的錯誤，那么需要付出很高的代價。傳統(tǒng)的瀑布模型是文檔驅(qū)動的。如圖所示。19瀑布模型的優(yōu)點是過程模型簡單，執(zhí)行容易；缺點是無法適應(yīng)變更。瀑布模型適應(yīng)于具有以下特征的軟件開發(fā)項目。在軟件開發(fā)的過程中，需求不發(fā)生或發(fā)生很少變化，并且開發(fā)人員可以一次性獲取到全部需求。否則，由于瀑布模型較差的可回溯性，在后續(xù)階段中需求經(jīng)常性的變更需要付出高昂的代價。軟件開發(fā)人員具有豐富的經(jīng)驗，對軟件應(yīng)用領(lǐng)域很熟悉。軟件項目的風(fēng)險較低。瀑布模型不具有完善的風(fēng)險控制機制。20瀑布模型快速原型模型快速原型的基本思想是快速建立一個能反映用戶主要需求的原型系統(tǒng)，讓用戶在計算機上試用它，通過實踐來了解目標(biāo)系統(tǒng)的概貌。通常，用戶試用原型系統(tǒng)之后會提出許多修改意見，開發(fā)人員按照用戶的意見快速地修改原型系統(tǒng)，然后再次請用戶試用……反反復(fù)復(fù)地改進(jìn)，直到原型系統(tǒng)滿足用戶的要求。21快速原型模型適用于具有以下特征的軟件開發(fā)項目。已有產(chǎn)品或產(chǎn)品的原型（樣品），只需客戶化的工程項目簡單而熟悉的行業(yè)或領(lǐng)域有快速原型開發(fā)工具進(jìn)行產(chǎn)品移植或升級22快速原型模型01020304增量模型是把待開發(fā)的軟件系統(tǒng)模塊化，將每個模塊作為一個增量組件，從而分批次地分析、設(shè)計、編碼和測試這些增量組件。運用增量模型的軟件開發(fā)過程是遞增式的過程。相對于瀑布模型而言，采用增量模型進(jìn)行開發(fā)，開發(fā)人員不需要一次性地把整個軟件產(chǎn)品提交給用戶，而是可以分批次進(jìn)行提交。23增量模型增量模型的最大特點就是將待開發(fā)的軟件系統(tǒng)模塊化和組件化?；谶@個特點，增量模型具有以下優(yōu)點。將待開發(fā)的軟件系統(tǒng)模塊化，可以分批次地提交軟件產(chǎn)品，使用戶可以及時了解軟件項目的進(jìn)展。以組件為單位進(jìn)行開發(fā)降低了軟件開發(fā)的風(fēng)險。一個開發(fā)周期內(nèi)的錯誤不會影響到整個軟件系統(tǒng)。開發(fā)順序靈活。開發(fā)人員可以對構(gòu)件的實現(xiàn)順序進(jìn)行優(yōu)先級排序，先完成需求穩(wěn)定的核心組件。當(dāng)組件的優(yōu)先級發(fā)生變化時，還能及時地對實現(xiàn)順序進(jìn)行調(diào)整。增量模型的缺點是要求待開發(fā)的軟件系統(tǒng)可以被模塊化。如果待開發(fā)的軟件系統(tǒng)很難被模塊化，那么將會給增量開發(fā)帶來很多麻煩。24增量模型增量模型適用于具有以下特征的軟件開發(fā)項目。軟件產(chǎn)品可以分批次地進(jìn)行交付待開發(fā)的軟件系統(tǒng)能夠被模塊化軟件開發(fā)人員對應(yīng)用領(lǐng)域不熟悉，難以一次性地進(jìn)行系統(tǒng)開發(fā)項目管理人員把握全局的水平較高25增量模型螺旋模型26螺旋模型螺旋模型是一種用于風(fēng)險較大的大型軟件項目開發(fā)的過程模型。該模型將瀑布模型與快速原型模型結(jié)合起來，并且加入了這兩種模型忽略了的風(fēng)險分析。它把開發(fā)過程分為制定計劃、風(fēng)險分析、實施工程和客戶評估4種活動。螺旋模型適應(yīng)于風(fēng)險較大的大型軟件項目的開發(fā)。它的優(yōu)點是將風(fēng)險分析擴展到各個階段中，大幅度降低了軟件開發(fā)的風(fēng)險。但是這種模型的控制和管理較為復(fù)雜，可操作性不強，對項目管理人員的要求較高。27噴泉模型是一種過程模型，同時也支持面向?qū)ο箝_發(fā)。在面向?qū)ο蟮姆椒ㄖ?，分析模型和設(shè)計模型采用相同的符號標(biāo)示體系，各階段之間沒有明顯的界限，而且常常重復(fù)、迭代地進(jìn)行?！皣娙币辉~體現(xiàn)了面向?qū)ο蠓椒ǖ牡蜔o間隙性。迭代是指各階段需要多次重復(fù)，例如，分析和設(shè)計階段常常需要多次、重復(fù)進(jìn)行，以更好的實現(xiàn)需求。無間隙性是指各個階段之間沒有明顯的界限，并常常在時間上互相交叉，并行進(jìn)行。噴泉模型主要用于面向?qū)ο蟮能浖椖?，軟件的某個部分通常被重復(fù)多次，相關(guān)對象在每次迭代中隨之加入漸進(jìn)的軟件成分。噴泉模型28基于組件的開發(fā)模型基于組件的開發(fā)模型使用現(xiàn)有的組件以及系統(tǒng)框架進(jìn)行產(chǎn)品開發(fā)。在確定需求之后，開發(fā)人員開始從現(xiàn)有的組件庫中篩選合適的組件，并對組件功能進(jìn)行分析。在對組件分析之后，開發(fā)人員可能適當(dāng)修改需求來適應(yīng)現(xiàn)有組件，也可能修改組件或?qū)ふ倚碌慕M件。組件篩選完成之后，開發(fā)人員需要根據(jù)需求設(shè)計或使用現(xiàn)有的成熟開發(fā)框架復(fù)用這些組件，一些無法利用現(xiàn)有組件的地方，則需要進(jìn)行單獨的開發(fā)，新開發(fā)的組件在經(jīng)歷時間考驗之后也會加入到組件庫中。最后將所有組件集成在一起，進(jìn)行系統(tǒng)測試。29基于組件的開發(fā)模型充分的體現(xiàn)了軟件復(fù)用的思想，降低了開發(fā)成本和風(fēng)險，并加快了產(chǎn)品開發(fā)。統(tǒng)一軟件開發(fā)過程模型統(tǒng)一軟件開發(fā)過程（RationalUnifiedProcess，RUP）模型是基于UML（統(tǒng)一建模語言）的一種面向?qū)ο筌浖_發(fā)模型。它解決了螺旋模型的可操作性問題，采用迭代和增量遞進(jìn)的開發(fā)策略，并以用例驅(qū)動為特點，集中了多個軟件開發(fā)模型的優(yōu)點。RUP模型是迭代模型的一種。RUP模型的示意圖如圖所示。30圖1中的縱軸以工作的內(nèi)容為組織方式，表現(xiàn)了軟件開發(fā)的工作流程。工作流程可以分為核心工作流程和核心支持工作流程。圖1中的橫軸以時間為組織方式，表現(xiàn)了軟件開發(fā)的4個階段：先啟、細(xì)化、構(gòu)建和產(chǎn)品化，每個階段中都可能包含若干次迭代。這4個階段按照順序依次進(jìn)行，每個階段結(jié)束時都有一個主要里程碑。階段與里程碑的關(guān)系如圖2所示。

圖1統(tǒng)一軟件開發(fā)過程模型圖2階段與里程碑的關(guān)系統(tǒng)一軟件開發(fā)過程模型統(tǒng)一軟件開發(fā)過程模型是基于迭代思想的軟件開發(fā)模型。采用迭代的軟件工程思想可以多次執(zhí)行各個工作流程，有利于更好地理解需求、設(shè)計出合理的系統(tǒng)架構(gòu)，并最終交付一系列漸趨完善的成果?？梢哉f，迭代是一次完整地經(jīng)過所有工作流程的過程?；诮y(tǒng)一軟件開發(fā)過程模型所構(gòu)造的軟件系統(tǒng)，是由軟件構(gòu)件建造而成的。這些軟件構(gòu)件定義了明確的接口，相互連接成整個系統(tǒng)。在構(gòu)造軟件系統(tǒng)時，RUP采用架構(gòu)優(yōu)先的策略。軟件架構(gòu)概念包含了系統(tǒng)中最重要的靜態(tài)結(jié)構(gòu)和動態(tài)特征，架構(gòu)體現(xiàn)了系統(tǒng)的總體設(shè)計。架構(gòu)優(yōu)先開發(fā)的原則是RUP開發(fā)過程中至關(guān)重要的主題。統(tǒng)一軟件開發(fā)過程模型適用的范圍極為廣泛，但是對開發(fā)人員的素質(zhì)要求較高。32統(tǒng)一軟件開發(fā)過程模型幾種過程模型的對比序號模型名稱優(yōu)點缺點適用范圍1瀑布模型

簡單好學(xué)逆轉(zhuǎn)性差

需求不發(fā)生或發(fā)生很小變化2快速原型模型

開發(fā)速度快不利于創(chuàng)新

已有產(chǎn)品的原型3增量模型

可以分階段提交有時用戶不同意

系統(tǒng)可拆卸和組裝4螺旋模型將風(fēng)險分析拓展到各個階段中建設(shè)周期長龐大、復(fù)雜、高風(fēng)險項目5噴泉模型提高開發(fā)效率不利于項目的管理面向?qū)ο箝_發(fā)6統(tǒng)一軟件開發(fā)過程模型

需求可變風(fēng)險大

有高素質(zhì)軟件團隊7基于組件的開發(fā)模型提高開發(fā)效率封裝的過程需要編寫大量代碼可組裝構(gòu)件的系統(tǒng)8敏捷模型提高開發(fā)效率不適合大團隊、大項目小團隊，小項目331．瀑布模型與RUP模型之間的關(guān)系在宏觀上，瀑布模型是靜態(tài)模型，RUP模型是動態(tài)模型。RUP模型的每一次迭代，實際上都需要執(zhí)行一次瀑布模型，都要經(jīng)歷先啟、細(xì)化、構(gòu)建、產(chǎn)品化這4個階段，完成瀑布模型的整個過程。在微觀上，瀑布模型與RUP模型都是動態(tài)模型。瀑布模型與RUP模型在每一個開發(fā)階段（先啟、細(xì)化、構(gòu)建、產(chǎn)品化）的內(nèi)部，都需要有一個小小的迭代過程，只有進(jìn)行這樣的迭代，開發(fā)階段才能做得更好。瀑布模型中有RUP模型，反過來，RUP模型中也有瀑布模型。34幾種過程模型之間的關(guān)系2．瀑布模型與增量模型之間的關(guān)系增量模型是把待開發(fā)的軟件系統(tǒng)模塊化，將每個模塊作為一個增量組件，一個模塊接著一個模塊地進(jìn)行開發(fā)，直到開發(fā)完所有的模塊。在開發(fā)每個模塊時，通常都是采用瀑布模型，從分析、設(shè)計、編碼和測試這幾個階段進(jìn)行開發(fā)。所以，增量模型中有瀑布模型，即宏觀上是增量模型，微觀上是瀑布模型。增量模型也體現(xiàn)了迭代思想，每增加一個模塊，就進(jìn)行一次迭代，執(zhí)行一次瀑布模型，所以，增量模型本質(zhì)上是迭代的。35幾種模型之間的關(guān)系3．瀑布模型與快速原型模型之間的關(guān)系快速原型的基本思想是快速建立一個能反映用戶主要需求的原型系統(tǒng)，在此基礎(chǔ)上之后的每一次迭代，都可能會用到瀑布模型?？焖僭湍Ｐ椭胁坏说Ｐ偷乃枷?，而且包含了瀑布模型的思想。36幾種模型之間的關(guān)系4．瀑布模型與螺旋模型之間的關(guān)系螺旋模型是瀑布模型和快速原型模型的結(jié)合，快速原型模型是原型模型的簡化，原型模型又是迭代模型和瀑布模型的組合，這些模型之間是相互依存的、彼此有關(guān)的。螺旋模型每一次順時針方向旋轉(zhuǎn)，相當(dāng)于順時針方向迭代一次，都是走完一次瀑布模型，這就是瀑布模型與螺旋模型之間的關(guān)系。實際上，瀑布模型與噴泉模型也有關(guān)系。37幾種模型之間的關(guān)系

各種軟件過程模型反映了軟件生命周期表現(xiàn)形式的多樣性。在生命周期的不同階段也可采用不同的軟件過程模型。在具體的軟件開發(fā)過程中，可以選擇某種軟件過程模型，按照某種開發(fā)方法，使用相應(yīng)的工具進(jìn)行軟件開發(fā)。在選擇軟件過程模型時需要考慮以下幾點。符合軟件自身的特性，如規(guī)模、成本和復(fù)雜性等滿足軟件開發(fā)進(jìn)度的要求對軟件開發(fā)的風(fēng)險進(jìn)行預(yù)防和控制具有計算機輔助工具的支持與用戶和軟件開發(fā)人員的知識和技能相匹配有利于軟件開發(fā)的管理和控制38選擇軟件過程模型一般來說，結(jié)構(gòu)化方法和面向數(shù)據(jù)結(jié)構(gòu)方法可采用瀑布模型或增量模型進(jìn)行軟件開發(fā)；而面向?qū)ο蠓椒刹捎每焖僭湍Ｐ汀娙Ｐ突騌UP模型進(jìn)行軟件開發(fā)。在實際的軟件開發(fā)過程中，選擇軟件過程模型并非是一成不變的，有時還需要針對具體的目標(biāo)要求進(jìn)行裁剪、修改等，從而構(gòu)成完全適合開發(fā)目標(biāo)要求的軟件過程模型。現(xiàn)實中的軟件系統(tǒng)有各種各樣，軟件開發(fā)方式也千差萬別。對同一個問題，不同的開發(fā)組織可能選擇不同的開發(fā)模型（過程模型）去解決，開發(fā)出的軟件系統(tǒng)也不可能完全一樣，但是其基本目標(biāo)都是一致的，即應(yīng)該滿足用戶的基本功能需求，否則，再好的軟件系統(tǒng)也是沒有意義的。39選擇軟件過程模型40軟件過程模型實例第五節(jié)軟件開發(fā)方法1.5.1基本的軟件開發(fā)方法1.5.2開源軟件開發(fā)方法1.5.3群體化軟件開發(fā)方法1.5軟件開發(fā)方法1.5.1基本的軟件開發(fā)方法軟件開發(fā)方法是一種使用定義好的技術(shù)集及符號表示組織軟件生產(chǎn)的過程，它的目標(biāo)是在規(guī)定的時間和成本內(nèi)，開發(fā)出符合用戶需求的高質(zhì)量的軟件。常見的軟件開發(fā)方法包括：1)結(jié)構(gòu)化方法2)面向數(shù)據(jù)結(jié)構(gòu)方法3)面向?qū)ο蠓椒?)形式化方法此外，軟件開發(fā)方法還有問題分析法、可視化開發(fā)方法等。421.5軟件開發(fā)方法1.5.2開源軟件開發(fā)方法開源軟件開發(fā)指的是由開源軟件項目開發(fā)開源軟件或類似原件的過程，其中，開源軟件的源代碼是公開可用的。這些軟件產(chǎn)品及其源代碼在開源許可下可用，它們常常被用于研究、更改和改進(jìn)其設(shè)計。開源項目可分為以下4類：1)各種各樣的軟件程序和庫2)發(fā)行版3)其他開源項目4)書籍或獨立文檔項目431.5軟件開發(fā)方法1.5.2開源軟件開發(fā)方法開源項目的工作方式：1)意識到項目需求的個人宣布了公開開發(fā)項目的意圖2)開發(fā)人員在代碼庫上工作，將其作為開源程序的第一個版本發(fā)布3)到期項目的源代碼向公眾發(fā)布4)一個完善的開源項目可以由感興趣的外部用戶派生441.5軟件開發(fā)方法1.5.3群體化軟件開發(fā)方法群體化軟件開發(fā)方法最大的特點是面向公眾。核心原則：1)開放2)平等3)共享4)全局行動相關(guān)模型：1)代碼與證據(jù)緊密耦合的可信軟件演化模型2)創(chuàng)作與生產(chǎn)緊密耦合的軟件開發(fā)過程模型3)協(xié)同、共享、監(jiān)控與分析緊密耦合的服務(wù)支撐模型451.5軟件開發(fā)方法1.5.3群體化軟件開發(fā)方法群體化軟件開發(fā)方法將軟件開發(fā)過程全面開放并快速迭代，不斷發(fā)布系統(tǒng)原型，吸引互聯(lián)網(wǎng)大眾體驗，借助互聯(lián)網(wǎng)平臺開展各種形式的交流、協(xié)同和共享，實現(xiàn)群體需求及創(chuàng)意的匯聚。軟件開發(fā)團隊對大眾需求創(chuàng)意進(jìn)行識別審查，借助工業(yè)化生產(chǎn)的強組織模式來組織軟件開發(fā)過程，實現(xiàn)高質(zhì)量軟件產(chǎn)品的輸出。群體化軟件方法將大眾群體的軟件創(chuàng)作過程有機融入開發(fā)團隊的軟件產(chǎn)品的輸出。群體化軟件方法將大眾群體的軟件創(chuàng)作過程有機融入開發(fā)團隊的軟件生產(chǎn)流程中，能夠充分發(fā)揮大眾群體和開發(fā)團隊在軟件開發(fā)過程中各自的優(yōu)勢，有效地支持網(wǎng)絡(luò)環(huán)境下的軟件開發(fā)。46基本的軟件開發(fā)方法對比471.5軟件開發(fā)方法序號方法名稱優(yōu)點缺點適用范圍1面向過程的方法

簡單好學(xué)不適應(yīng)窗口界面，維護(hù)困難

大型工程計算，實時數(shù)據(jù)跟蹤處理，各種自動化控制系統(tǒng)，以及系統(tǒng)軟件實現(xiàn)等領(lǐng)域2面向?qū)ο蟮姆椒?/p>

功能強大，易于維護(hù)不易掌握

互聯(lián)網(wǎng)絡(luò)時代，完全由用戶交互控制程序執(zhí)行過程的應(yīng)用軟件和系統(tǒng)軟件的開發(fā)3面向數(shù)據(jù)的方法

通俗易懂不適于窗口界面

以關(guān)系數(shù)據(jù)庫管理系統(tǒng)為支撐環(huán)境的信息系統(tǒng)建設(shè)4形式化方法準(zhǔn)確、嚴(yán)謹(jǐn)難于上手和應(yīng)用對安全性要求極高，不容許出錯的軟件系統(tǒng)，如軍事、醫(yī)藥、交通等領(lǐng)域第六節(jié)軟件工程工具1.6軟件工程工具軟件工程的工具對軟件工程中的過程和方法提供自動的或半自動的支持?？梢詭椭浖_發(fā)人員方便、簡捷、高效地進(jìn)行軟件的分析、設(shè)計、開發(fā)、測試、和管理等工作。有效地利用工具軟維護(hù)件可以提高軟件開發(fā)的質(zhì)量，減少成本，縮短工期，方便軟件項目的管理。軟件工程工具通常有3種分類標(biāo)準(zhǔn)：按照功能劃分按照支持的過程劃分按照支持的范圍劃分491.6軟件工程工具按功能劃分可視化建模工具程序開發(fā)工具自動化測試工具文檔編輯工具配置管理工具項目管理工具50按支持的過程劃分設(shè)計工具維護(hù)工具編程工具1.6軟件工程工具按支持的范圍劃分可以分為窄支持、較寬支持和一般支持工具。窄支持工具支持軟件工程過程中的特定任務(wù)，一般將其稱之為工具。較寬支持支持特定的過程階段，一般由多個工具集合而成，稱之為工作臺較寬支持支持特定的過程階段，一般由多個工具集合而成，稱之為工作臺一般支持支持覆蓋軟件過程的全部或大部分階段，包含多個不同的工作臺，稱之為環(huán)境。511.6軟件工程工具在需求分析與系統(tǒng)設(shè)計階段，常用的CASE（計算機輔助軟件工程）工具有面向通用軟件設(shè)計的MicrosoftVisio、用于面向?qū)ο筌浖O(shè)計的RationalRose、用于數(shù)據(jù)庫設(shè)計的PowerDesigner，除此之外近幾年還出現(xiàn)了更加集成化的工具，如EnterpriseArchitect、RationalSoftwareArchitect和StarUML等。這些工具通過簡化UML圖的繪制工作，以及強大的模型轉(zhuǎn)換功能（諸如正向工程、反向工程、數(shù)據(jù)庫模型轉(zhuǎn)化等），大大簡化了設(shè)計以及從設(shè)計向編碼轉(zhuǎn)化的工作。521.6軟件工程工具名稱編程語言TurboPascalPascalDevC++C/C++CodeblocksC/C++CLionC/C++/C#VisualStudioC++/VB/C#/JavaScript等VisualStudioCodeC++/VB/C#/JavaScript等GoLandGoRubymineRubyWebstormJavasciptPHPstormPHPPycharmPythonEclipseJavaIntelliJIdeaJavaXCodeObjective-C/Swift在編碼階段，集成開發(fā)環(huán)境（IDE）通過提供代碼高亮、補全，內(nèi)置調(diào)試工具等功能，大大提高了效率。IDE主流的實例如表所示。531.6軟件工程工具名稱編程語言CUnitCCppUnitC++JUnitJAVANUit.NETPerlTestingPerlMocha/Should.jsNode,js內(nèi)置unittest模塊/pytestPythonPHPUnitPHP內(nèi)置Test::Unit模塊Ruby在測試階段，通常會使用自動化測試工具進(jìn)行測試。除單元測試工具外，較為流行的自動化測試工具包括C/S功能測試工具WinRunner，性能測試工具LoadRunner、Jmeter，測試管理工具TestDirector、Jira，Web服務(wù)測試工具QTester（簡稱QT）、SoapUI等。單元測試工具通常與語言及開發(fā)框架關(guān)聯(lián)密切，部分實例如表所示。541.6軟件工程工具名稱編程語言CUnitCCppUnitC++JUnitJAVANUit.NETPerlTestingPerlMocha/Should.jsNode,js內(nèi)置unittest模塊/pytestPythonPHPUnitPHP內(nèi)置Test::Unit模塊Ruby除了這幾個階段，軟件開發(fā)過程還包括諸多其他活動，而其中最重要的便是配置管理與項目管理。配置管理通常分為不同模式，每一種模式均有對應(yīng)的工具，較為著名的有MicrosoftVSS、CVS、SVN等，近年來較常用的為Git。而項目管理領(lǐng)域最普遍使用的為微軟公司開發(fā)的MicrosoftProject，該軟件提供了強大的項目管理功能，基本能夠滿足企業(yè)級項目管理全部需求。此外，近年來隨著敏捷開發(fā)的興起，諸如基于Scrum的PingCode，以及基于看板（Kanban）的Teambition等輕量級開發(fā)平臺也擁有了廣大的用戶群體。除此之外，在軟件過程的其他活動中同樣存在眾多CASE工具。在原型設(shè)計方面有快速原型構(gòu)建系統(tǒng)Dreamweaver，在協(xié)作文檔管理方面有在線協(xié)作辦公系統(tǒng)MicrosoftOfficeOnline，還有在線協(xié)作軟件設(shè)計平臺Processon等。55第七節(jié)軟件工程人員的職業(yè)道德1.7軟件工程人員的職業(yè)道德

作為一名專業(yè)的軟件開發(fā)人員，必須認(rèn)識到有限的工作包括更多的額外責(zé)任，而不僅僅是應(yīng)用技術(shù)；我們必須保持一貫標(biāo)準(zhǔn)，不要利用技術(shù)和能力來制造一些損害軟件工程行業(yè)聲譽的事情。57標(biāo)準(zhǔn)1)保密2)能力3)知識產(chǎn)權(quán)4)計算機濫用1.7軟件工程人員的職業(yè)道德

ACM/IEEE道德準(zhǔn)則包含以下八項原則：1)公眾2)客戶和雇主3)產(chǎn)品4)判斷力5)管理6)職業(yè)7)同事8)自我581.7軟件工程人員的職業(yè)道德軟件開發(fā)人員在開發(fā)產(chǎn)品和選擇為哪些公司工作時應(yīng)該注意的道德問題：1)保護(hù)客戶數(shù)據(jù)2)知識產(chǎn)權(quán)3)版權(quán)擁有權(quán)4)許可協(xié)議5)道德問題解決方案6)道德教育59謝謝聆聽第2章敏捷軟件開發(fā)

目錄622.1敏捷方法2.2Scrum2.3看板2.4極限編程（XP）2.5CI／CD2.1敏捷方法概念與價值觀原則與方法概述敏捷軟件開發(fā)是軟件開發(fā)行業(yè)的一個大流行語，它是管理軟件開發(fā)項目的一種不同方式。它不是一種特定的軟件開發(fā)方法，而是一組基于敏捷軟件開發(fā)宣言中表達(dá)的價值和原則的方法和實踐的總稱。64概念及價值觀敏捷軟件開發(fā)開始于“敏捷軟件開發(fā)宣言”。在2001年2月，17位軟件開發(fā)方法學(xué)家在美國猶他州召開了長達(dá)兩天的會議，制訂并簽署了“敏捷軟件開發(fā)宣言”，該宣言給出了4個價值觀：個體與交互高于過程和工具可運行軟件高于詳盡的文檔與客戶協(xié)作高于合同（契約）談判對變更及時響應(yīng)高于遵循計劃65“敏捷聯(lián)盟”制定的12條原則可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)敏捷過程提倡可持續(xù)的開發(fā)速度。不斷地關(guān)注優(yōu)秀的技能和良好的設(shè)計會增強敏捷能力。盡量使工作簡單化。

好的架構(gòu)、需求和設(shè)計來源于自身組織團隊。每隔一定時間,團隊?wèi)?yīng)該反省如何才能有效地工作,并相應(yīng)地調(diào)整自己的行為。66通過盡早和持續(xù)交付有價值的軟件來讓客戶滿意需求變更可以發(fā)生在整個軟件的開發(fā)過程中經(jīng)常交付可工作的軟件

業(yè)務(wù)人員和開發(fā)人員應(yīng)該天天在一起工作圍繞受激勵的個人構(gòu)建項目在團隊的內(nèi)部,最有效果和效率的信息傳遞方法是面對面交談。不同的敏捷方法最廣泛使用的敏捷方法包括：Scrum極限編程（XP）看板（Kanban）特征驅(qū)動開發(fā)精益軟件開發(fā)水晶（Crystal）動態(tài)系統(tǒng)開發(fā)方法67敏捷軟件開發(fā)方法如左圖，是敏捷開發(fā)流程的舉例。682.2Scrum概述Sprint每日站會用戶故事Backlog結(jié)對編程2.2.1概述Scrum中的三種角色產(chǎn)品經(jīng)理：產(chǎn)品經(jīng)理負(fù)責(zé)規(guī)劃產(chǎn)品，并將研發(fā)這種產(chǎn)品的愿景傳達(dá)給團隊。敏捷主管（ScrumMaster）：ScrumMaster幫助團隊盡其所能地完成工作。ScrumMaster對團隊成員在做的事情沒有指揮權(quán)，但對這一過程擁有指揮權(quán)。Scrum團隊：Scrum團隊由5~7名成員組成。與傳統(tǒng)的開發(fā)團隊不同，成員們沒有固定角色。團隊成員間相互幫助、共享成果，旨在完成全部的工作。Scrum團隊需要做好整體規(guī)劃，并為每次迭代劃分合適的工作量。70Scrum有一套其獨特且固定的管理方式，從角色、工件和不同形式的會議三個維度出發(fā)，來保證執(zhí)行過程更高效。例如在每次Sprint開始前會確立整個過程：迭代規(guī)劃、每日站會、迭代演示和回顧，并在Sprint期間用可視化工件確認(rèn)進(jìn)度和收集客戶反饋。2.2.1概述71Scrum的會議步驟整理產(chǎn)品需求清單確定迭代規(guī)劃梳理產(chǎn)品需求清單每日站會迭代演示迭代回顧2.2.1概述Scrum項目所需的常用工件Scrum任務(wù)板：用戶可以用Scrum任務(wù)板使Sprint任務(wù)清單形象化。任務(wù)板可以用不同的形式來呈現(xiàn)，比較傳統(tǒng)的做法有索引卡，便利貼或白板。Scrum任務(wù)板通常分為三列：待辦事項，正在進(jìn)行中和已完成。團隊需要在整個Sprint過程中不斷更新。用戶故事：用戶故事是從客戶角度對軟件提出功能的描述。它包括用戶類型細(xì)分，他們想要什么以及他們?yōu)槭裁葱枰Ｈ急M圖：縱軸表示任務(wù)總量估計，橫軸表示迭代時間。剩下工作可以通過不同的點位或者其他的指標(biāo)來表示。722.2.2SprintSprint（沖刺）是Scrum團隊一起完成增量工作的實際時間段。敏捷專家DaveWest建議，工作越復(fù)雜，未知數(shù)越多，沖刺應(yīng)該越短。但這實際上取決于具體的團隊情況所有的事件——從計劃到回顧——都發(fā)生在Sprint階段。一旦一個Sprint的時長被確定，它就必須在整個開發(fā)期間保持一致。732.2.3每日站會74這是一個每天在同一時間（通常是上午）和地點舉行的超短會議，以保持會議的簡單性。每日Scrum的目標(biāo)是讓團隊中的每個人都保持同步，與Sprint目標(biāo)保持一致，并為接下來的24小時制定計劃。一種常見的開站會的方法是讓每個團隊成員回答如下三個關(guān)于實現(xiàn)Sprint目標(biāo)的問題：我昨天做了什么？我今天計劃做什么？有什么問題嗎？2.2.4用戶故事3C原則卡片（Card）：用戶故事一般寫在小的記事卡片上?？ㄆ峡赡軙懮瞎适碌暮喍堂枋?，工作量估算等。交談（Conversation）：用戶故事背后的細(xì)節(jié)來源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通。確認(rèn)（Confirmation）：通過驗收測試確認(rèn)用戶故事被正確完成。75實際開發(fā)流程中，最為重要的是做好用戶故事的劃分。用戶故事是從用戶的角度來描述用戶渴望得到的功能。用戶的三個要素：角色：誰要使用這個功能活動：需要完成什么樣的功能商業(yè)價值：為什么需要這個功能，這個功能帶來什么樣的價值INVEST原則獨立性（Independent）

可協(xié)商性（Negotiable）有價值（Valuable）

可以估算性（Estimatable）短?。⊿mall）

可測試性（Testable）2.2.4用戶故事右圖為實際開發(fā)記錄舉例762.2.5BacklogBacklog的關(guān)鍵要點如下所述清楚地表述列表中每個需求任務(wù)給用戶帶來的價值,作為優(yōu)先級排序的重要參考動態(tài)的需求管理而非“凍結(jié)”方式需求分析的過程是可迭代的77Backlog是Scrum中經(jīng)過優(yōu)先級排序的動態(tài)刷新的產(chǎn)品需求清單，用來制定發(fā)布計劃和迭代計劃。使用Backlog可以通過需求的動態(tài)管理應(yīng)對變化，避免浪費，并且易于優(yōu)先交付對用戶價值高的需求。

2.2.6結(jié)對編程結(jié)對編程的好處程序員通?？梢愿斓亟鉀Q問題由于兩個程序員具有相同缺點和盲點的可能性要小得多,因此可出現(xiàn)更少的錯誤,可縮短測試的時間和降低測試的成本程序員之間的互相激勵、幫助和監(jiān)督,可降低編程的枯燥性和程序員懶惰的可能性個別的人員流動對項目進(jìn)展造成的影響就會相對小。概念：結(jié)對編程,即兩個程序員肩并肩地坐在同一臺計算機前合作編程,在一個程序員編程的同時,另一個負(fù)責(zé)檢查代碼的正確性和可讀性。782.3看板概述Scrum與看板的區(qū)別2.3.1概述80看板作為可視化框架可以用于敏捷方法，能夠清晰地向項目成員展示整個項目進(jìn)度。當(dāng)需要對系統(tǒng)進(jìn)行小幅度改動的時候，可以采用看板方法來輕量化解決這個問題，因為看板本身并不需要額外去制定流程?？窗鍒D是項目中實施看板的常見工具。2.3.1概述無論用哪種形式來創(chuàng)建看板圖，看板都會有一個原則：劃分為不同列來代表其工作狀態(tài)?？窗屙椖堪ㄈ缦?條核心原則：可視化工作流程限制工作進(jìn)度管理和改進(jìn)流程制定明確的執(zhí)行策略持續(xù)改進(jìn)812.3.2Scrum與看板的區(qū)別Scrum與看板有所不同，看板對團隊的個人能力要求較高，更靈活，適合新開發(fā)的產(chǎn)品，而Scrum適合成熟一點的產(chǎn)品和團隊。在實際的小團隊項目敏捷開發(fā)中，Scrum和看板都是不錯的選擇，且可視具體情況，靈活調(diào)整迭代的周期，在兩種模式上進(jìn)行自定義的微調(diào)。822.3.2Scrum與看板的區(qū)別如果團隊需要在某特定的時間發(fā)布或推廣產(chǎn)品，以達(dá)到一定的市場預(yù)期的話，則團隊一般會將需求進(jìn)行拆分和細(xì)化，拆分為較小的需求后，團隊可以通過檢查每個Sprint的進(jìn)度并進(jìn)行調(diào)整，從而預(yù)測交付時間，進(jìn)而確保整個項目成功交付，這時Scrum是首選的方式。其次，由于Scrum承諾在每個Sprint內(nèi)不對計劃做修改，如果團隊經(jīng)常會應(yīng)對緊急情況或者修改任務(wù)的優(yōu)先級，那么看板方法因其靈活的工作流程可以更好地適應(yīng)。再者，在Scrum中每個Sprint的時間長度是固定的（1~4周），并且每個Sprint結(jié)束后會交付潛在可交付產(chǎn)品的增量，如果項目需要有固定的交付時間（1~4周），那么Scrum是比較好的選擇。最后如果團隊不足5人，在人員方面可能無法發(fā)揮Scrum的最大功效或存在一定的浪費，那么建議使用看板方法。832.3.2Scrum與看板的區(qū)別84Scrum看板開發(fā)方式要求定時迭代沒指定定時限迭代，可以分開計劃、發(fā)布、過程改進(jìn)，可以事件驅(qū)動而不是限定時限團隊在每個迭代承諾一定數(shù)目的工作承諾不是必須的以速度（Velocity）作為計劃和過程改進(jìn)的度量數(shù)據(jù)使用開發(fā)周期作為計劃和過程改進(jìn)的度量數(shù)據(jù)指定跨功能團隊沒有指定跨功能團隊，也容許專門團隊工作任務(wù)細(xì)分，可于一個迭代中完成沒有指定工作任務(wù)大小指定使用燃燒圖沒有指定任何圖表2.3.2Scrum與看板的區(qū)別85Scrum看板開發(fā)方式間接限制開發(fā)中工作（每個迭代）設(shè)定開發(fā)中工作的限制（每個工作流程狀態(tài)）規(guī)定估算過程沒有指定任何估算方式在迭代中不能加入新工作任務(wù)只要生產(chǎn)力容許，可以隨時加工作任務(wù)由單一團隊負(fù)責(zé)SprintBacklog多個團隊和團員分享看板指定3個角色（產(chǎn)品經(jīng)理、ScrumMaster、Scrum團隊）沒有指定任何團隊角色Scrumboard在每個迭代后重設(shè)看板反映持久開發(fā)情況規(guī)定優(yōu)先化的productbacklog優(yōu)先級是非必須的2.4極限編程概述XP的四個價值觀2.4.1概述極限編程是一種實踐性較強的規(guī)范化的軟件開發(fā)方法，它強調(diào)用戶需求和團隊工作。XP特別適用于軟件需求模糊且容易改變、開發(fā)團隊人數(shù)少于10人、開發(fā)地點集中（比如一個辦公室）的場合。極限編程包含了一組相互作用和相互影響的規(guī)則和實踐。在項目計劃階段，需要建立合理和簡潔的用戶故事。在設(shè)計系統(tǒng)的體系架構(gòu)時，可以采用CRC（Class，Responsibility，Collaboration）卡促使團隊成員共同努力。代碼的質(zhì)量在極限編程項目中非常重要。為了保證代碼的質(zhì)量，可以采用結(jié)對編程以及在編碼之前構(gòu)造測試用例等措施。合理的測試用例及較高的測試覆蓋率是極限編程項目測試所追求的目標(biāo)。872.4.1極限編程XP所推崇的規(guī)則和方法如右圖所示882.4.2XP的4個價值觀交流：交流不僅能使相關(guān)人員更為精確的理解需求，而是能夠盡可能避免因為需求變

更導(dǎo)致的不一致.簡單：簡單是XP推崇的理念，一切都使用最簡單、最小代價的方式達(dá)到目的，以及用最簡潔的達(dá)到客戶的要求。反饋：及時高效的反饋能夠確保開發(fā)工作的正確性，并能夠在發(fā)生錯誤時更及時地糾正偏差。勇氣：敏捷方法要求與其他人密切的合作，充分信任他人，也信任自己，這需要勇氣892.4.3XP的 12個核心實踐完整的團隊

結(jié)對編程計劃策略

設(shè)計改進(jìn)系統(tǒng)隱喻

持續(xù)集成小型發(fā)布

集體所有權(quán)測試驅(qū)動

編碼標(biāo)準(zhǔn)簡單設(shè)計

工作安排902.5CI/CD概述CI/CD的優(yōu)勢2.5.1CI/CD概述CI/CD是一套使軟件開發(fā)的構(gòu)建、測試和部署階段自動化的方法。自動化可縮短交付時間，并提高整個開發(fā)生命周期的可靠性。CI/CD中的CI代表持續(xù)集成。CD是指連續(xù)交付或連續(xù)部署，具體取決于團隊選擇如何推動代碼更改以進(jìn)行生產(chǎn)。持續(xù)集成和持續(xù)交付是CI/CD中的兩個不同流程，具有不同的用途CI完成自動構(gòu)建和測試步驟，以確保代碼更改能夠可靠合理地合并到代碼倉庫中CD提供了向最終用戶交付代碼地快速無縫方法CI／CD的目標(biāo)是幫助開發(fā)人員以速度和效率交付軟件。團隊不斷將代碼交付到生產(chǎn)中，運行新功能和錯誤修復(fù)的持續(xù)流程。CI／CD概覽如圖所示922.5.1CI/CD概述持續(xù)集成（CI）：持續(xù)集成是不斷將更新集成到代碼庫的方法。CI提供一個一致的自動化流程，包括構(gòu)建、測試和合并新軟件。持續(xù)交付（CD）：持續(xù)交付是指持續(xù)地將各類更改(包括新功能、缺陷修復(fù)、配置變化等)安全、快速、高質(zhì)量地落實到生產(chǎn)環(huán)境或用戶手中的能力。持續(xù)交付從持續(xù)集成結(jié)束的地方開始。CD使開發(fā)人員能夠隨時向不同的環(huán)境和最終用戶部署常規(guī)軟件更改。所有進(jìn)入CD過程的代碼必須首先通過CI。持續(xù)測試：持續(xù)測試是運行自動測試的方法，而代碼更改則通過CI和CD進(jìn)行。932.5.1CI/CD概述單個CI/CD過程可以具有多種類型的測試單元測試（確保單個功能在構(gòu)建過程中正確執(zhí)行的CI測試）集成測試（檢查組件和服務(wù)是否都協(xié)同工作）功能測試（確保功能按團隊預(yù)期執(zhí)行）驗收測試（性能、可擴展性、應(yīng)力、容量等）靜態(tài)代碼分析（檢查語法問題和漏洞）自動測試（如API測試和安全測試）并非每個CI/CD過程都需要有所有這些測試，但持續(xù)測試的目標(biāo)始終相同。942.5.2CI/CD的優(yōu)勢更快、更可靠的版本發(fā)布更高的可見性早期錯誤檢測快速反饋循環(huán)更快樂的開發(fā)和運維團隊952.6DevOps概述生命周期敏捷軟件開發(fā)、CI/CD和DevOps工具概述DevOps是從敏捷發(fā)展起來的。它添加了新的過程和工具，將CI/CD的持續(xù)迭代和自動化擴展到軟件交付生命周期的其余部分。在流程的每一個步驟中，它實現(xiàn)了開發(fā)和運維之間的密切協(xié)作。972.6.1生命周期DevOps生命周期（當(dāng)以線性方式描述時，有時稱為持續(xù)交付管道）是一系列迭代的、自動化的開發(fā)過程，或工作流，在一個更大的、自動化的、迭代的開發(fā)生命周期中執(zhí)行，旨在優(yōu)化高質(zhì)量軟件的快速交付。其生命周期如下圖所示。982.6.1生命周期工作流的名稱和數(shù)量可以根據(jù)所詢問的對象而有所不同，但它們通常可以歸結(jié)為以下六種策劃開發(fā)集成或構(gòu)建部署運維學(xué)習(xí)另外三個重要的連續(xù)工作流發(fā)生在這些工作流之間持續(xù)測試安全合規(guī)992.6.2

敏捷開發(fā)、CI-CD和DevOps敏捷開發(fā)和DevOps的理念相似，都是為了更好更快地發(fā)布產(chǎn)品，但又不完全相同，而CI/CD是實現(xiàn)這兩者理念的一種方法敏捷開發(fā)的核心是，擁抱變化與快速迭代持續(xù)集成（CI）、持續(xù)交付和持續(xù)部署（CD）提供了一個優(yōu)秀的DevOps環(huán)境，對于整個團隊來說，好處與挑戰(zhàn)并行。無論如何，頻繁部署、快速交付以及開發(fā)測試流程自動化都將成為未來軟件工程的重要組成部分。1002.6.2

敏捷開發(fā)、CI-CD和DevOpsDevOps之所以逐漸流行起來，是因為一下幾個因素容器技術(shù)開始成熟，特別是docker等技術(shù)的大行其道微服務(wù)架構(gòu)技術(shù)的廣泛使用敏捷開發(fā)流程的深入人心DevOps帶來的變革DevOps帶來的變革具體為角色分工：打破傳統(tǒng)團隊隔閡，讓開發(fā)、運維緊密結(jié)合，高效協(xié)作研發(fā)：專注研發(fā)、高度敏捷、持續(xù)集成產(chǎn)品交付：高質(zhì)量、快速、頻繁、自動化、持續(xù)交付1012.7敏捷開發(fā)實例102謝謝聆聽第3章

可行性研究與項目開發(fā)計劃105項目立項概述第一節(jié)可行性研究第二節(jié)制定項目開發(fā)計劃第三節(jié)目錄content第一節(jié)項目立項概述項目立項概述任何一個完整的軟件工程項目都是從項目立項開始的。項目立項包括項目發(fā)起、項目論證、項目審核和項目立項四個過程107SWOT03.項目審核1.項目發(fā)起4.項目立項2.項目論證項目立項概述項目經(jīng)過可行性研究并且認(rèn)為可行后，還需要報告主管領(lǐng)導(dǎo)或單位，以獲得項目的進(jìn)一步審核，并得到他們的支持。108項目通過可行性研究和主管部門的批準(zhǔn)后，將其列入項目計劃的過程，叫做項目立項。在發(fā)起一個項目時，項目發(fā)起人或單位為尋求他人的支持，要以書面材料的形式遞交給項目的支持者和領(lǐng)導(dǎo)，使其明白項目的必要性和可行性。項目發(fā)起項目論證過程，也就是可行性研究過程。可行性研究就是指在項目進(jìn)行開發(fā)之前，根據(jù)項目發(fā)起文件和實際情況，對該項目是否能在特定的資源、時間等制約條件下完成做出評估，并且確定它是否值得去開發(fā)?？尚行匝芯康慕Y(jié)論有以下三種情況：（1）可行，按計劃進(jìn)行（2）基本可行，需要對解決方案作出修改（3）不可行，終止項目項目論證項目發(fā)起項目發(fā)起第二節(jié)可行性研究可行性研究的任務(wù)可行性研究的步驟110可行性研究的任務(wù)可行性研究需要從多個方面進(jìn)行評估，主要包括：計劃可行性戰(zhàn)略可行性社會可行性社會可行性技術(shù)可行性操作可行性市場可行性經(jīng)濟可行性風(fēng)險可行性111可行性研究的任務(wù)技術(shù)可行性技術(shù)可行性主要研究待開發(fā)的系統(tǒng)的功能、性能和限制條件，確定現(xiàn)有技術(shù)能否實現(xiàn)有關(guān)的解決方案，在現(xiàn)有的資源條件下實現(xiàn)新系統(tǒng)的技術(shù)風(fēng)險有多大。這里的資源條件是指已有的或可以得到的軟硬件資源，現(xiàn)有的開發(fā)項目的人員的技術(shù)水平和已有的工作基礎(chǔ)。在評估技術(shù)可行性時，需要考慮以下情況：

了解當(dāng)前最先進(jìn)的技術(shù)，分析相關(guān)技術(shù)的發(fā)展是否支持新系統(tǒng)確定資源的有效性，如新系統(tǒng)的軟硬件資源是否具備，開發(fā)項目的人員在技術(shù)和時間上是否可行等分析項目的開發(fā)的技術(shù)風(fēng)險，即能在給定的資源和時間等條件下，設(shè)計并實現(xiàn)系統(tǒng)的功能和性能等112可行性研究的任務(wù)操作可行性操作可行性是對開發(fā)系統(tǒng)在一個給定的工作環(huán)境中能否運行或運行好壞程度的衡量。操作可行性研究決定在當(dāng)前的政治意識形態(tài)、法律法規(guī)、社會道德、民族意識以及系統(tǒng)運行的組織機構(gòu)或人員等環(huán)境下，系統(tǒng)的操作是否可行。經(jīng)濟可行性可行性研究成本--效益分析是可行性研究的重要內(nèi)容，它用于評估基于項目的經(jīng)濟合理性，給出項目開發(fā)的成本論證，并將估算的成本與預(yù)期的利潤進(jìn)行對比。一般說來，基于項目的成本由4個部分組成：購置并安裝軟硬件及有關(guān)設(shè)備的費用；項目開發(fā)費用；軟硬件系統(tǒng)安裝、運行和維護(hù)費用；人員的培訓(xùn)費用。項目開發(fā)效益包括經(jīng)濟效益和社會效益兩部分。經(jīng)濟效益是指所使用系統(tǒng)為用戶增加的收入，可以通過直接的或統(tǒng)計的方法估算；社會效益只能用定性的方法估算?？尚行匝芯康娜蝿?wù)任務(wù)人力/%可行性研究4～5需求分析10～25設(shè)計20～25編碼15～20測試和調(diào)試30～40113典型環(huán)境下各個階段需要投入的人力百分比1.成本估算代碼行技術(shù)

。代碼行技術(shù)是比較簡單的定量估算方法，它將開發(fā)每個軟件功能的成本與實現(xiàn)這個功能需要用的源代碼行數(shù)聯(lián)系起來。通常根據(jù)經(jīng)驗和歷史數(shù)據(jù)估算實現(xiàn)一個功能所需要的源代碼行數(shù)。一旦估算出源代碼行數(shù)后，用每行代碼的平均成本乘以行數(shù)即可確定軟件的成本。每行代碼的平均成本主要取決于軟件的復(fù)雜程度和人員的薪資水平。任務(wù)分解技術(shù)。首先將開發(fā)項目分解為若干個相對獨立的任務(wù)，再分別估算每個任務(wù)單獨開發(fā)的成本，最后累加起來就可得出開發(fā)項目的總成本。經(jīng)濟可行性2.成本-效益分析開發(fā)成本：使用代碼行技術(shù)或任務(wù)分解技術(shù)進(jìn)行估算運行費用：取決于系統(tǒng)操作的費用（涉及操作人員、工作時間和消耗物資等），以及維護(hù)費用經(jīng)濟效益：因使用新系統(tǒng)而增加的收入加上使用新系統(tǒng)可以節(jié)省的運行費用114可行性研究的任務(wù)經(jīng)濟可行性3.貨幣的時間價值通常使用利率的形式表示貨幣的時間價值。假設(shè)年利率為i，如果現(xiàn)在存入P，則n年后可以得到的價值為：F=P(1+i)^nF就是P在n年后的價值。反之，如果n年后能收入F，那么這些貨幣的現(xiàn)在價值就是：P=F/(1+i)^n115可行性研究的任務(wù)經(jīng)濟可行性可行性研究的任務(wù)例如：有這樣一個庫房管理系統(tǒng)，它每天能產(chǎn)生一份訂貨報告。假定開發(fā)該系統(tǒng)共需50000元，系統(tǒng)開發(fā)完后及時訂貨，以免商品短缺，估算一下，每年可以節(jié)約25000元，5年則可以總共節(jié)約125000元。假定年利率為5%，利用上面計算貨幣現(xiàn)在價值的公式，可以計算出開發(fā)完該庫房管理系統(tǒng)后，每年預(yù)計節(jié)省費用的現(xiàn)在價值，如右表所示。年將來值（元）(1+i)n現(xiàn)在值（元）累計的現(xiàn)在值（元）1250001.0523809.5223809.522250001.1022675.7446485.263250001.1621595.9468081.204250001.2220567.5688648.765250001.2819588.15108236.92116將來的收入折算成現(xiàn)在值4.投資回收期投資回收期是衡量一個項目價值的常用方法。投資回收期就是使累計的經(jīng)濟效益等于最初投資所需要的時間。很明顯，投資回收期越短，所獲得的利潤就越快，因此該項目就越值得開發(fā)。117可行性研究的任務(wù)經(jīng)濟可行性5.純收入純收入是衡量一個項目價值的另一項經(jīng)濟指標(biāo)。純收入就是在軟件生命周期中軟件系統(tǒng)的累計經(jīng)濟效益（折合成現(xiàn)在值）與投資之差。這相當(dāng)于比較投資開發(fā)一個軟件系統(tǒng)和將錢存在銀行中（或貸給其他企業(yè)）這兩種方案的優(yōu)劣。如果純收入為零，則項目的預(yù)期效益和在銀行存款一樣，而且開發(fā)一個軟件系統(tǒng)要冒風(fēng)險，從經(jīng)濟觀點來看，這個項目可能是不值得投資的。如果純收入小于零，這個項目顯然不值得投資開發(fā)。118可行性研究的任務(wù)經(jīng)濟可行性119可行性研究的步驟進(jìn)行可行性研究的步驟不是固化的，而是根據(jù)項目的性質(zhì)、特點以及開發(fā)團隊的能力有所區(qū)別。一個典型的可行性研究的步驟可以歸結(jié)為以下幾步1.明確系統(tǒng)的目標(biāo)在這一步，可行性分析人員要訪問相關(guān)人員，閱讀分析可以掌握的材料，確認(rèn)用戶需要解決的問題的實質(zhì)，進(jìn)而明確系統(tǒng)的目標(biāo)以及為了達(dá)到這些目標(biāo)所需的各種資源。2.分析研究現(xiàn)行系統(tǒng)現(xiàn)行系統(tǒng)是新系統(tǒng)重要的信息來源。新系統(tǒng)應(yīng)該完成現(xiàn)行系統(tǒng)的基本功能，并在此基礎(chǔ)上對現(xiàn)行系統(tǒng)中存在的問題進(jìn)行改善或修復(fù)?？梢詮?個方面對現(xiàn)有系統(tǒng)進(jìn)行分析：系統(tǒng)組織結(jié)構(gòu)定義、系統(tǒng)處理流程分析和系統(tǒng)數(shù)據(jù)流分析。系統(tǒng)組織結(jié)構(gòu)可以用組織結(jié)構(gòu)圖來描述。系統(tǒng)處理流程分析的對象是各部門的業(yè)務(wù)流程，可以用系統(tǒng)流程圖來描述。系統(tǒng)數(shù)據(jù)流分析與業(yè)務(wù)流程緊密相連，可以用數(shù)據(jù)流圖和數(shù)據(jù)字典來表示。120可行性研究的步驟3.設(shè)計新系統(tǒng)的高層邏輯模型這一步從較高層次設(shè)想新系統(tǒng)的邏輯模型，概括地描述開發(fā)人員對新系統(tǒng)地理解和設(shè)想。4.獲得并比較可行的方案開發(fā)人員可根據(jù)新系統(tǒng)的高層邏輯模型提出實現(xiàn)此模型的不同方案。在設(shè)計方案的過程中要從技術(shù)、經(jīng)濟等角度考慮各方面的可行性。然后，從多個方案中選擇出最合適的方案。121可行性研究的步驟5.撰寫可行性研究報告可行性研究的最后一步就是撰寫可行性研究報告。此報告包括項目介紹、可行性分析過程和結(jié)論等內(nèi)容?？尚行匝芯康慕Y(jié)論一般有以下三種：（1）可以按計劃進(jìn)行軟件項目的開發(fā)（2）需要解決某些存在的問題（如資金短缺、設(shè)備陳舊和開發(fā)人員短缺等）或者需要對現(xiàn)有的解決方案進(jìn)行一些調(diào)整或改善后才能進(jìn)行軟件項目的開發(fā)。（3）待開發(fā)的軟件項目不具有可行性，立即停止該軟件項目。122可行性研究的步驟可行性研究實例假設(shè)開發(fā)某個計算機應(yīng)用系統(tǒng)的投資額為3000元，該計算機應(yīng)用系統(tǒng)投入使用后，每年可以節(jié)約1000元，5年內(nèi)節(jié)約5000元。3000元是現(xiàn)在投資的錢，假定年利率為12%，請計算該系統(tǒng)的純收入和投資回收期。年節(jié)省利率現(xiàn)在值（元）累計的現(xiàn)在值（元）110001.12892.86892.86210001.2544797.191690.05310001.404928711.782401.83410001.573519635.523037.35510001.762342567.433604.78123純收入最終結(jié)果：3604.78-3000=604.78元投資回收期：3+(3000-2401.83)/(3037.35-2401.83)=3.94年第三節(jié)制定項目開發(fā)計劃在可行性研究之后，就可得知一個軟件項目是否值得開發(fā)。如果值得開發(fā)，則開發(fā)人員應(yīng)制訂相應(yīng)的項目開發(fā)計劃。計劃的合理性和準(zhǔn)確性往往關(guān)系著項目的成功與否。計劃應(yīng)考慮周全，要考慮到一些未知因素和不確定因素，以及要考慮到可能的修改。計劃應(yīng)盡量準(zhǔn)確，盡可能提高數(shù)據(jù)的可靠性。125制定項目開發(fā)計劃項目計劃軟件開發(fā)計劃軟件開發(fā)計劃是軟件工程中的一種管理文檔，主要是對所要開發(fā)軟件的人員、進(jìn)度、費用、軟件開發(fā)環(huán)境和運行環(huán)境的配置和硬件設(shè)備的配置等進(jìn)行說明和規(guī)劃，是項目管理人員對項目進(jìn)行管理的依據(jù)，管理員據(jù)此對項目的費用、進(jìn)度和資源進(jìn)行控制的和管理項目概述：說明項目的各項主要工作；說明軟件的功能和性能；為完成項目應(yīng)具備的條件；甲方和乙方應(yīng)承擔(dān)的工作、完成期限和其他限制條件；應(yīng)交付的軟件名稱，所使用的開發(fā)語言及存儲形式；應(yīng)交付的文檔等)。實施計劃：說明任務(wù)的劃分，各項任務(wù)的責(zé)任人；說明項目開發(fā)進(jìn)度，按階段應(yīng)完成的任務(wù)，用圖表說明每項任務(wù)的開始時間和完成時間；說明項目的預(yù)算，各階段的費用支出預(yù)算等。人員組織及分工：說明開發(fā)該項目所需人員的類型、組成結(jié)構(gòu)和數(shù)量等。交付期限：說明項目應(yīng)交付的日期等。126制定項目開發(fā)計劃項目開發(fā)計劃的主要內(nèi)容謝謝聆聽第4章需求分析與結(jié)構(gòu)化分析

目錄1294.1

需求分析概述4.2結(jié)構(gòu)化分析方法4.3結(jié)構(gòu)化分析建模4.4結(jié)構(gòu)化分析圖形工具4.1需求分析概述4.1需求分析概述1314.1.1

需求分析的任務(wù)和原則

1.為什么需要需求分析

為了開發(fā)出真正滿足用戶需要的軟件產(chǎn)品，明確地了解用戶需求是關(guān)鍵。雖然在可行性研究中，已經(jīng)對用戶需求有了初步的了解，但是很多細(xì)節(jié)還沒有考慮到?？尚行匝芯康哪康氖窃u估系統(tǒng)是否值得去開發(fā)，問題是否能夠解決，而不是對需求進(jìn)行定義。如果說可行性分析是要決定“做還是不做”，那么需求分析就是要回答“系統(tǒng)必須做什么”這個問題。需求分析是一個非常重要的過程，它完成的好壞直接影響了后續(xù)軟件開發(fā)的質(zhì)量。4.1需求分析概述1322.確定系統(tǒng)的運行環(huán)境要求

系統(tǒng)運行時的硬件環(huán)境要求，如對計算機的CPU、內(nèi)存、存儲器、輸入/輸出方式、通信接口和外圍設(shè)備等的要求；軟件環(huán)境要求，如操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)和編程語言等的要求。4.1需求分析概述1333.確定系統(tǒng)的功能性需求和非功能性需求需求可以分為兩大類，功能性需求和非功能性需求，前者定義了系統(tǒng)做什么，后者定義了系統(tǒng)工作時的特性。功能需求：軟件系統(tǒng)的最基本的需求表述，包括對系統(tǒng)應(yīng)該提供的服務(wù)，如何對輸入做出反應(yīng)，以及系統(tǒng)在特定條件下的行為描述。在某些情況下，功能需求還必須明確系統(tǒng)不應(yīng)該做什么，這取決于開發(fā)的軟件類型、軟件未來的用戶、以及開發(fā)的系統(tǒng)類型。所以，功能性的系統(tǒng)需求，需要詳細(xì)地描述系統(tǒng)功能特征、輸入和輸出接口、異常處理方法等。非功能性需求：包括對系統(tǒng)提出的性能需求、可靠性和可用性需求、系統(tǒng)安全以及系統(tǒng)對開發(fā)過程、時間、資源等方面的約束和標(biāo)準(zhǔn)等。性能需求指定系統(tǒng)必須滿足的定時約束或容量約束，一般包括速度（響應(yīng)時間）、信息量速率（吞吐量、處理時間）和存儲容量等方面的需求。4.1需求分析概述1344.進(jìn)行有效的需求分析一般情況下，用戶并不熟悉計算機的相關(guān)知識，而軟件開發(fā)人員對相關(guān)的業(yè)務(wù)領(lǐng)域也不甚了解，用戶與開發(fā)人員之間對同一問題理解的差異和習(xí)慣用語的不同往往會為需求分析帶來很大的困難。所以，開發(fā)人員和用戶之間充分和有效的溝通在需求分析的過程中至關(guān)重要。有效的需求分析通常都具有一定的難度，這一方面是由于交流障礙所引起的，另一方面是由于用戶通常對需求的陳述不完備、不準(zhǔn)確和不全面，并且還可能在不斷的變化。所以開發(fā)人員不僅需要在用戶的幫助下抽象現(xiàn)有的需求，還需要挖掘隱藏的需求。此外，把各項需求抽象為目標(biāo)系統(tǒng)的高層邏輯模型對日后的開發(fā)工作也至關(guān)重要。合理的高層邏輯模型是系統(tǒng)設(shè)計的前提。4.1需求分析概述1355.需求分析的兩個階段

首先，是需求分析的建模階段，即在充分了解需求的基礎(chǔ)上，要建立起系統(tǒng)的分析模型。

其次，是需求分析的描述階段，就是把需求文檔化，用軟件需求規(guī)格說明書的方式把需求表達(dá)出來。4.1需求分析概述1366.軟件需求規(guī)格說明書

軟件需求規(guī)格說明書是需求分析階段的輸出，它全面、清晰地描述了用戶需求，因此是開發(fā)人員進(jìn)行后續(xù)軟件設(shè)計的重要依據(jù)。軟件需求規(guī)格說明書應(yīng)該具有清晰性、無二義性、一致性和準(zhǔn)確性等特點。同時，它還需通過嚴(yán)格的需求驗證、反復(fù)修改的過程才能最終確定。01020304GOAL4.1需求分析概述137在需求分析的過程中應(yīng)該遵守一些原則首先，需求分析是一個過程，它應(yīng)該貫穿于系統(tǒng)的整個生命周期中，而不是僅僅屬于軟件生命周期早期的一項工作。其次，需求分析應(yīng)該是一個迭代的過程。由于市場環(huán)境的易變性以及用戶本身對于新系統(tǒng)要求的模糊性，需求往往很難一步到位。通常情況下，需求是隨著項目的深入而不斷變化的。所以需求分析的過程還應(yīng)該是一個迭代的過程。此外，為了方便評審和后續(xù)的設(shè)計，需求的表述應(yīng)該具體、清晰，并且是可測量的、可實現(xiàn)的。最好能夠?qū)π枨筮M(jìn)行適當(dāng)?shù)牧炕１热纾合到y(tǒng)的響應(yīng)時間應(yīng)該低于0.5秒；系統(tǒng)在同一時刻最多能支持30000個用戶。4.1需求分析概述1384.1.2需求分析的步驟為了準(zhǔn)確獲取需求，需求分析必須遵循一系列的步驟。只有采取了合理的需求分析的步驟，開發(fā)人員才能更有效地獲取需求。一般來說，需求分析分為需求獲取、分析建模、需求描述和需求驗證4步。以下將分步進(jìn)行介紹。4.1需求分析概述139

需求獲取就是收集并明確用戶需求的過程。系統(tǒng)開發(fā)方人員通過調(diào)查研究，要理解當(dāng)前系統(tǒng)的工作模型、用戶對新系統(tǒng)的設(shè)想與要求。在需求獲取的初期，用戶提出的需求一般模糊而且凌亂，這就需要開發(fā)人員能夠選取較好的需求分析的方法，提煉出邏輯性強的需求。而且不同用戶的需求有可能發(fā)生沖突，對于發(fā)生沖突的需求必須仔細(xì)考慮并做出選擇。獲取需求的方法有多種，比如問卷調(diào)查、訪談、實地操作、建立原型等。

1.需求獲取4.1需求分析概述140

獲取到需求后，下一步就應(yīng)該對開發(fā)的系統(tǒng)建立分析模型了。模型就是為了理解事物而對事物做出的一種抽象，通常由一組符號和組織這些符號的規(guī)則組成。對待開發(fā)系統(tǒng)建立各種角度的模型有助于人們更好地理解問題。通常，從不同角度描述或理解軟件系統(tǒng)，就需要不同的模型。常用的建模方法有數(shù)據(jù)流圖、實體關(guān)系圖、狀態(tài)轉(zhuǎn)換圖、控制流圖、用例圖、類圖、對象圖等。

2.分析建模4.1需求分析概述141

需求描述就是指編制需求分析階段的文檔。一般情況下，對于復(fù)雜的軟件系統(tǒng)，需求階段會產(chǎn)生3個文檔:系統(tǒng)定義文檔（用戶需求報告）、系統(tǒng)需求文檔（系統(tǒng)需求規(guī)格說明書）、軟件需求文檔（軟件需求規(guī)格說明書）。而對于簡單的軟件系統(tǒng)而言，需求階段只需要輸出軟件需求文檔就可以了。軟件需求規(guī)格說明書主要描述軟件部分的需求，簡稱SRS（SoftwareRequirementSpecification），它站在開發(fā)者的角度，對開發(fā)系統(tǒng)的業(yè)務(wù)模型、功能模型、數(shù)據(jù)模型、行為模型等內(nèi)容進(jìn)行描述。經(jīng)過嚴(yán)格的評審后，它將作為概要設(shè)計和詳細(xì)設(shè)計的。

3.需求描述4.1需求分析概述142文檔與軟件規(guī)模的對應(yīng)關(guān)系4.1需求分析概述143

需求分析的第四步是驗證以上需求分析的成果。需求分析階段的工作成果是后續(xù)軟件開發(fā)的重要基礎(chǔ)，為了提高軟件開發(fā)的質(zhì)量，降低軟件開發(fā)的成本，必須對需求的正確性進(jìn)行嚴(yán)格的驗證，確保需求的一致性、完整性、現(xiàn)實性、有效性。確保設(shè)計與實現(xiàn)過程中的需求可回溯性，并進(jìn)行需求變更管理。

4.需求驗證與評審4.1需求分析概述144

需求評審就是將需求規(guī)約文檔發(fā)布給利益相關(guān)者進(jìn)行檢查，發(fā)現(xiàn)需求規(guī)約中存在缺陷（如錯誤、不完整性、二義性等）的過程。對工作產(chǎn)品的評審有兩類方式，一類是正式技術(shù)評審，也稱同行評審，另一類是非正式技術(shù)評審。對于任何重要的工作產(chǎn)品，都應(yīng)該至少執(zhí)行一次正式技術(shù)評審。在進(jìn)行正式技術(shù)評審前，需要有人員對要進(jìn)行評審的工作產(chǎn)品進(jìn)行把關(guān)，確認(rèn)其是否具備進(jìn)入評審的初步條件。需求評審的規(guī)程與其他重要工作產(chǎn)品（如系統(tǒng)設(shè)計文檔、源代碼）的評審規(guī)程非常相似，主要區(qū)別在于評審人員的組成不同。前者由開發(fā)方和客戶方的代表共同組成，而后者通常來源于開發(fā)方內(nèi)部。4.1需求分析概述1454.1.3需求管理

為了更好的進(jìn)行需求分析并記錄需求結(jié)果，需要進(jìn)行需求管理。需求管理是一種用于查找、記錄、組織和跟蹤系統(tǒng)需求變更的系統(tǒng)化方法?？捎糜冢韩@取、組織和記錄系統(tǒng)需求使客戶和項目團隊在系統(tǒng)變更需求上達(dá)成并保持一致

有效需求管理的關(guān)鍵在于維護(hù)需求的明確闡述、每種需求類型所適用的屬性，以及與其他需求和其他項目工件之間的可追蹤性。01020304GOAL4.1需求分析概述1464.1.3需求管理

需求管理實際上是項目管理的一個部分，它涉及以下3個主要問題：（1）識別、分類、組織需求，并為需求建立文檔（2）需求變化，是建立對需求不可避免的變化是如何提出、如何協(xié)商、如何驗證以及如何形成文檔的過程（3）需求的可追蹤性，即帶有維護(hù)需求之間以及與系統(tǒng)的其他制品之間依賴關(guān)系的過程4.1需求分析概述1474.1.4需求分析的常用方法

需求分析的方法有多種，下面只簡單介紹功能分解方法、結(jié)構(gòu)化分析方法、信息建模方法和面向?qū)ο蟮姆治龇椒ā?.1需求分析概述1484.1.4需求分析的常用方法（1）功能分解方法功能分解方法是將一個系統(tǒng)看成是由若干功能模塊組成的，每個功能又可分解為若干子功能及接口，子功能再繼續(xù)分解，即功能、子功能和功能接口成為了功能分解方法的3個要素。功能分解方法采用的是自頂向下、逐步求精的理念。4.1需求分析概述149（2）結(jié)構(gòu)化分析方法結(jié)構(gòu)化分析方法是一種從問題空間到某種表示的映射方法，其邏輯模型由數(shù)據(jù)流圖和數(shù)據(jù)詞典構(gòu)成并表示。它是一種面向數(shù)據(jù)流的需求分析方法。它主要適用于數(shù)據(jù)處理領(lǐng)域問題。第4章將詳細(xì)介紹這種方法。4.1需求分析概述150（3）信息建模方法模型是用某種媒介對相同媒介或其他媒介里的一些事物的表現(xiàn)形式。從一個建模角度出發(fā)，模型就是要抓住事物的最重要方面而簡化或忽略其他方面。簡而言之，模型就是對現(xiàn)實的簡化。建立模型的過程，稱為建模。建?？梢詭椭斫庹陂_發(fā)的系統(tǒng)，這是需要建模的一個基本理由。并且，人對復(fù)雜問題的理解能力是有限的。建?？梢詭椭_發(fā)者縮小問題的范圍，每次著重研究一個方面，進(jìn)而對整個系統(tǒng)產(chǎn)生更加深刻的理解?？梢悦鞔_地說，越大、越復(fù)雜的系統(tǒng)，建模的重要性也越大。信息建模方法常用的基本工具是E-R圖，其基本要素由實體、屬性和關(guān)系構(gòu)成。它的核心概念是實體和關(guān)系，它的基本策略是從現(xiàn)實中找出實體，然后再用屬性對其進(jìn)行描述。4.1需求分析概述151（4）面向?qū)ο蟮姆治龇椒?/p>

面向?qū)ο蟮姆治龇椒ǖ年P(guān)鍵是識別問題域內(nèi)的對象，分析它們之間的關(guān)系，并建立3類模型，它們分別是:描述系統(tǒng)靜態(tài)結(jié)構(gòu)的對象模型描述系統(tǒng)控制結(jié)構(gòu)的動態(tài)模型描述系統(tǒng)計算結(jié)構(gòu)的功能模型

其中，對象模型是最基本、最核心、最重要的。面向?qū)ο笾饕紤]類或?qū)ο?、結(jié)構(gòu)與連接、繼承和封裝、消息通信，只表示面向?qū)ο蟮姆治鲋袔醉椬钪匾卣?。類的對象是對問題域中事物的完整映射，包括事物的數(shù)據(jù)特征（即屬性）和行為特征（即服務(wù)）。4.1需求分析概述1524.1.5原型設(shè)計

原型設(shè)計是指在項目的前期階段，系統(tǒng)分析人員根據(jù)對客戶需求的理解和客戶希望實現(xiàn)的結(jié)果，快速地給出一個翔實地產(chǎn)品雛形，然后與客戶反復(fù)協(xié)商修改。01020304GOAL4.2結(jié)構(gòu)化分析方法4.2結(jié)構(gòu)化分析方法154

一種考慮數(shù)據(jù)和處理的需求分析方法被稱作結(jié)構(gòu)化分析方法（StructuredAnalysis，簡稱SA法），是70年代由YourdonConstaintine及DeMarco等人提出和發(fā)展，并得到廣泛的應(yīng)用。它基于“分解”和“抽象”的基本思想，逐步建立目標(biāo)系統(tǒng)的邏輯模型，進(jìn)而描繪出滿足用戶要求的軟件系統(tǒng)?！胺纸狻笔侵笇τ谝粋€復(fù)雜的系統(tǒng)，為了將復(fù)雜性降低到可以掌握的程度，可以把大問題分解為若干個小問題，然后再分別解決。4.2結(jié)構(gòu)化分析方法155最頂層描述了整個目標(biāo)系統(tǒng)X中間層將目標(biāo)系統(tǒng)劃分為若干個模塊，每個模塊完成一定的功能最底層是對每個模塊實現(xiàn)方法的細(xì)節(jié)性描述4.2結(jié)構(gòu)化分析方法156結(jié)構(gòu)化分析方法是一種面向數(shù)據(jù)流的需求分析方法，其中數(shù)據(jù)作為獨立實體轉(zhuǎn)換，數(shù)據(jù)建模定義了數(shù)據(jù)的屬性和關(guān)系，操作數(shù)據(jù)的處理建模表明當(dāng)數(shù)據(jù)在系統(tǒng)流動時處理如何轉(zhuǎn)換數(shù)據(jù)。4.2結(jié)構(gòu)化分析方法1571)建立當(dāng)前系統(tǒng)的“具體模型”：系統(tǒng)的“具體模型”就是現(xiàn)實環(huán)境的忠實寫照，這樣的表達(dá)與當(dāng)前系統(tǒng)完全對應(yīng)，因此用戶容易理解。2)抽象出當(dāng)前系統(tǒng)的邏輯模型：分析