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

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

軟件危機(jī)第四節(jié)

軟件工程第五節(jié)

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

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

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

軟件工程軟件的概念及特點(diǎn)軟件的概念

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

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

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

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

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

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

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

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

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

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

可以分階段提交有時(shí)用戶(hù)不同意

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

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

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

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

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

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

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

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

通俗易懂不適于窗口界面

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

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

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

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

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

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

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

可以估算性（Estimatable）短小（Small）

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

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

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

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

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

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

集體所有權(quán)測(cè)試驅(qū)動(dòng)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.需求驗(yàn)證與評(píng)審4.1需求分析概述144

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

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

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

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

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

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

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

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

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