軟件工程課件

第一章軟體工程概述

1.1電腦軟體本節(jié)內(nèi)容1.1.1軟體的定義1.1.2軟體的特點(diǎn)1.1.3軟體的分類1.1.1軟體的定義軟體是程式的完善和發(fā)展，是經(jīng)過嚴(yán)格的正確性檢驗(yàn)和實(shí)際試用，並具有相對穩(wěn)定的文本和完整的文檔資料的程式。Wirth中指出：在結(jié)構(gòu)化程式設(shè)計(jì)：程式＝演算法＋數(shù)據(jù)結(jié)構(gòu)在軟體工程中：軟體＝程式＋文檔。IEEE定義：軟體是電腦程式、規(guī)程以及運(yùn)行電腦系統(tǒng)所需要的文檔和數(shù)據(jù)。1.1.1軟體的定義另一種對軟體的公認(rèn)解釋是：軟體是包括程式、數(shù)據(jù)及其相關(guān)文檔的完整集合。程式是按照事先設(shè)計(jì)的功能和性能要求執(zhí)行的指令序列；數(shù)據(jù)是使程式能正常操縱資訊的數(shù)據(jù)結(jié)構(gòu)；文檔是與程式開發(fā)、維護(hù)和使用有關(guān)的圖文材料。1.1.2軟體的特點(diǎn)（1）軟體是一種邏輯實(shí)體，具有抽象性。（2）軟體的開發(fā)過程中沒有明顯的製造過程。（3）軟體在運(yùn)行和使用期間，沒有硬體那樣的機(jī)械磨損和老化問題，但存在軟體退化問題。（4）軟體的開發(fā)和運(yùn)行常常受到電腦系統(tǒng)的約束和限制，不同程度地依賴電腦硬體。（5）軟體的開發(fā)至今未完全擺脫手工藝的開發(fā)方式，大部分軟體還是定制的，很難通過組裝方式完成軟體開發(fā)。1.1.2軟體的特點(diǎn)（6）軟體是複雜的。實(shí)際需求的複雜性程式邏輯的複雜性（7）軟體研製成本相當(dāng)高，在電腦系統(tǒng)中軟體成本比例逐步增加。（8）軟體投入運(yùn)行時(shí)還涉及到許多社會(huì)因素。1.1.3軟體的分類根據(jù)軟體服務(wù)對象的範(fàn)圍不同：通用軟體：操作系統(tǒng)、資料庫等；定制軟體：企業(yè)ERP、衛(wèi)星控制系統(tǒng)等；根據(jù)軟體完成功能所處的層次不同：系統(tǒng)軟體中間件軟體應(yīng)用軟體1.1.3軟體的分類系統(tǒng)軟體：指能與電腦硬體緊密配合在一起，使電腦系統(tǒng)各個(gè)部件、相關(guān)的軟體和數(shù)據(jù)協(xié)調(diào)、高效地工作的軟體。操作系統(tǒng)設(shè)備驅(qū)動(dòng)程式通信處理程式1.1.3軟體的分類中間件遮罩了底層操作系統(tǒng)的複雜性，使程式開發(fā)人員面對一個(gè)簡單而統(tǒng)一的開發(fā)環(huán)境，將注意力集中在自己的業(yè)務(wù)上，不必再為程式的移植而重複工作，從而大大減少了技術(shù)上的負(fù)擔(dān)。中間件軟體：為了解決分佈異構(gòu)系統(tǒng)的集成問題而開發(fā)的軟體，是處於操作系統(tǒng)軟體與用戶的應(yīng)用軟體的中間的通用服務(wù)，具有標(biāo)準(zhǔn)的介面和協(xié)議。1.1.3軟體的分類中間件的種類包括：消息中間件數(shù)據(jù)訪問中間件應(yīng)用伺服器對象中間件交易中間件安全中間件1.1.3軟體的分類中間件的十大優(yōu)越性：

(1)

縮短應(yīng)用的開發(fā)週期

(2)節(jié)約應(yīng)用的開發(fā)成本

(3)減少系統(tǒng)初期的建設(shè)成本

(4)降低應(yīng)用開發(fā)的失敗率

(5)保護(hù)已有的投資

(6)簡化應(yīng)用集成

(7)減少維護(hù)費(fèi)用

(8)提高應(yīng)用的開發(fā)品質(zhì)

(9)保證技術(shù)進(jìn)步的連續(xù)性

(10)增強(qiáng)應(yīng)用的生命力1.1.3軟體的分類應(yīng)用軟體：在特定領(lǐng)域內(nèi)開發(fā)，為特定目的服務(wù)的一類軟體。商業(yè)數(shù)據(jù)處理軟體工程與科學(xué)計(jì)算軟體電腦輔助設(shè)計(jì)／製造軟體系統(tǒng)仿真軟體智能產(chǎn)品嵌入軟體醫(yī)療、制藥軟體事務(wù)管理、辦公自動(dòng)化軟體電腦輔助教學(xué)軟體電腦網(wǎng)絡(luò)軟體1.1.3軟體的分類按照軟體的規(guī)模：類別參加人員數(shù)開發(fā)週期產(chǎn)品規(guī)模（LOC）微型11～4周0.5k小型11～6月1k～2k中型2～51～2年5k～50k大型5～202～3年50k～100k甚大型100～10004～5年1M(=1000k)極大型2000～50005～10年1M～10M1.1.3軟體的分類按軟體工作方式不同：即時(shí)處理軟體分時(shí)軟體互動(dòng)式軟體批處理軟體按照支撐應(yīng)用開發(fā)的工具類型可以將其劃分為：支持軟體開發(fā)過程的工具支持軟體維護(hù)過程的工具支持軟體管理過程和支持過程的工具1.2軟體的發(fā)展和軟體危機(jī)本節(jié)內(nèi)容1.2.1軟體發(fā)展階段1.2.2軟體危機(jī)1.2.3軟體危機(jī)的解決途徑1.2.1軟體發(fā)展階段程式設(shè)計(jì)階段：20世紀(jì)50至60年代程式系統(tǒng)階段：20世紀(jì)60至70年代 軟體工程階段：20世紀(jì)70至90年代現(xiàn)代軟體工程階段：20世紀(jì)90年代至今1.2.1軟體發(fā)展階段

階段程式設(shè)計(jì)程式系統(tǒng)（現(xiàn)代）軟體工程特點(diǎn)

軟體所指程式程式及說明書程式、文檔和數(shù)據(jù)程式設(shè)計(jì)語言彙編及機(jī)器語言高級(jí)語言軟體語言軟體工作範(fàn)圍程式編寫包括設(shè)計(jì)和測試軟體生存期需求者程式設(shè)計(jì)本人少數(shù)用戶市場用戶開發(fā)軟體的組織個(gè)人開發(fā)小組開發(fā)小組及大中型軟體開發(fā)機(jī)構(gòu)軟體規(guī)模小型中小型大中小型決定品質(zhì)的因素個(gè)人程式技術(shù)小組技術(shù)水準(zhǔn)管理水準(zhǔn)開發(fā)技術(shù)和手段副程式/程式庫結(jié)構(gòu)化程式設(shè)計(jì)資料庫、開發(fā)工具、開發(fā)環(huán)境、工程化開發(fā)方法、標(biāo)準(zhǔn)和規(guī)範(fàn)、網(wǎng)路及分佈式開發(fā)、面向?qū)ο蠹夹g(shù)、軟體複用維護(hù)責(zé)任者程式設(shè)計(jì)者開發(fā)小組專職維護(hù)人員硬體特徵價(jià)格高/存儲(chǔ)容量小

工作可靠性差降價(jià)、速度、容量及工作可靠性明顯提高向超高速、大容量、微型化及網(wǎng)路化發(fā)展軟體特徵完全不受重視軟體技術(shù)的發(fā)展不能滿足需求，出現(xiàn)軟體危機(jī)開發(fā)技術(shù)有進(jìn)步，但未獲突破性進(jìn)展，價(jià)高，未完全擺脫軟體危機(jī)1.2.2軟體危機(jī)20世紀(jì)60年代後，隨著電腦軟體應(yīng)用領(lǐng)域增多，軟體規(guī)模不斷擴(kuò)大，軟體系統(tǒng)功能多，邏輯複雜，不斷擴(kuò)充，從而導(dǎo)致許多系統(tǒng)開發(fā)出現(xiàn)了不良的後果：系統(tǒng)存在大量錯(cuò)誤，可用性和可靠性差；系統(tǒng)無法增加新功能，難於維護(hù)；系統(tǒng)無法按照計(jì)畫時(shí)間完成；最嚴(yán)重的徹底失敗。軟體危機(jī)舉例20世紀(jì)60年代IBM公司開發(fā)的（OS/360）系統(tǒng)就是一個(gè)很好的例子。該系統(tǒng)由4000多個(gè)模組組成，約100萬條指令，人工為5000人年（一個(gè)人年為一個(gè)人工作一年的工作量），耗費(fèi)達(dá)數(shù)億美元。該系統(tǒng)投入運(yùn)行後發(fā)現(xiàn)了2000多個(gè)錯(cuò)誤，發(fā)佈過19個(gè)版本，而以後每個(gè)版本的更新均有1000多個(gè)大大小小的錯(cuò)誤存在。系統(tǒng)開發(fā)陷入了僵局。OS/360系統(tǒng)的負(fù)責(zé)人F.D.Brooms曾這樣形象地描述了開發(fā)過程中的困難和混亂：“……像一頭巨獸在泥潭中作垂死掙扎，掙扎得越猛，泥漿就沾得越多，最後沒有一個(gè)野獸能逃脫淹沒在泥潭中的命運(yùn)……程式設(shè)計(jì)就像是這樣一個(gè)泥潭……一批批程式員在泥潭中掙扎……沒人料到問題竟會(huì)這樣棘手……”。1.2.2軟體危機(jī)所謂軟體危機(jī)（SoftwareCrisis）就是電腦軟體在開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題，具體表現(xiàn)在：軟體開發(fā)成本難以估算，無法制定合理的開發(fā)計(jì)畫；用戶的需求無法確切表達(dá)；軟體品質(zhì)存在問題；軟體的可維護(hù)性差；缺乏文檔資料；軟體成本難以控制；1.2.3軟體危機(jī)的解決途徑產(chǎn)生軟體危機(jī)的原因：軟體系統(tǒng)本身的複雜性；軟體開發(fā)的方法和技術(shù)不合理；程式設(shè)計(jì)方法學(xué)討論程式的性質(zhì)、程式設(shè)計(jì)的理論和方法軟體工程方法運(yùn)用工程化原則和方法組織軟體開發(fā)工作1968年提出1.3軟體工程本節(jié)內(nèi)容1.3.1軟體工程定義1.3.2軟體工程要素1.3.3軟體工程的目標(biāo)和原則1.3.4軟體工程基本原理1.3.1軟體工程定義1968年10月，F(xiàn)ritzBauer首次提出了“軟體工程”的概念：軟體工程是為了經(jīng)濟(jì)地獲得能夠在實(shí)際機(jī)器上高效運(yùn)行的可靠軟體而建立和使用的一系列好的工程化原則。Boehm為軟體工程下的定義：運(yùn)用現(xiàn)代科學(xué)技術(shù)知識(shí)來設(shè)計(jì)並構(gòu)造電腦程式及為開發(fā)、運(yùn)行和維護(hù)這些程式所必需的相關(guān)檔資料。1.3.1軟體工程定義Fairley認(rèn)為：軟體工程學(xué)是為在成本限額以內(nèi)按時(shí)完成開發(fā)和修改軟體產(chǎn)品所需的系統(tǒng)生產(chǎn)和維護(hù)的技術(shù)和管理的學(xué)科。IEEE電腦學(xué)會(huì)將“軟體工程”定義為：⑴應(yīng)用系統(tǒng)化的、規(guī)範(fàn)化的、定量的方法來開發(fā)、運(yùn)行和維護(hù)軟體，即：將工程應(yīng)用到軟體；⑵對⑴中各種方法的研究。從以上定義可以看出，軟體工程的含義：（1）工程概念在軟體領(lǐng)域裏的一個(gè)特定應(yīng)用（2）軟體工程涉及軟體產(chǎn)品的所有環(huán)節(jié)1.3.2軟體工程要素軟體工程包括三個(gè)要素：方法、工具和過程。方法：提供了“如何做”的技術(shù)；工具：提供了自動(dòng)的或半自動(dòng)的軟體支撐環(huán)境；過程：將軟體工程的方法和工具綜合起來以達(dá)到合理、及時(shí)地進(jìn)行電腦軟體開發(fā)的目的；1.3.3軟體工程的目標(biāo)和原則軟體工程的目標(biāo)可概括為：生產(chǎn)具有正確性、可用性以及開銷適宜的軟體產(chǎn)品。正確性指軟體產(chǎn)品達(dá)到預(yù)期功能的程度。可用性指軟體基本結(jié)構(gòu)、實(shí)現(xiàn)及文檔為用戶可用的程度。開銷合宜是指軟體開發(fā)、運(yùn)行的整個(gè)開銷滿足用戶要求的程度。軟體工程的最終目的是擺脫手工生產(chǎn)軟體的狀況，逐步實(shí)現(xiàn)軟體研製和維護(hù)的自動(dòng)化。1.3.3軟體工程的目標(biāo)和原則軟體工程研究內(nèi)容：軟體開發(fā)技術(shù)：根據(jù)不同的軟體類型，按不同的觀點(diǎn)和原則，對軟體開發(fā)中應(yīng)遵循的策略、原則、步驟和必須產(chǎn)生的文檔資料等作出規(guī)定，從而使軟體的開發(fā)能夠進(jìn)入規(guī)範(fàn)化和工程化的階段，以克服早期的手工作坊生產(chǎn)中的隨意性和非規(guī)範(fàn)性做法。包括：軟體開發(fā)方法學(xué)、開發(fā)過程模型、開發(fā)工具、軟體工程環(huán)境軟體工程管理軟體按工程化生產(chǎn)時(shí)的重要環(huán)節(jié)，它要求按照預(yù)先制定的計(jì)畫、進(jìn)度和預(yù)算執(zhí)行，以實(shí)現(xiàn)預(yù)期的經(jīng)濟(jì)效益和社會(huì)效益。包括：軟體管理學(xué)、軟體工程經(jīng)濟(jì)學(xué)、軟體心理學(xué)等內(nèi)容1.3.3軟體工程的目標(biāo)和原則使用軟體工程開發(fā)軟體系統(tǒng)的過程中，要堅(jiān)持四項(xiàng)基本原則：選取適宜的開發(fā)模型；採用合適的設(shè)計(jì)方法；提供高質(zhì)量的工程支持；重視開發(fā)過程的管理；1.3.4軟體工程基本原理八條一般原理：（1）抽象（2）資訊隱藏（3）模組化（4）局部化（5）確定性（6）一致性（7）完備性（8）可驗(yàn)證性1.3.4軟體工程基本原理七條基本原理（1）用分階段的生命週期計(jì)畫嚴(yán)格管理（2）堅(jiān)持進(jìn)行階段評審（3）實(shí)行嚴(yán)格的產(chǎn)品控制（4）採用現(xiàn)代程式設(shè)計(jì)技術(shù)（5）結(jié)果應(yīng)能清楚地審查（6）開發(fā)小組的人員應(yīng)少而精（7）承認(rèn)不斷改進(jìn)軟體工程實(shí)踐的必要性1.4通信軟體工程本節(jié)內(nèi)容1.4.1通信系統(tǒng)1.4.2通信軟體1.4.3通信軟體工程1.4.1通信系統(tǒng)通信系統(tǒng)基本組成1.4.1通信系統(tǒng)通信網(wǎng)：眾多點(diǎn)對點(diǎn)通信系統(tǒng)通過交換系統(tǒng)按一定拓?fù)浣Y(jié)構(gòu)組合在一起就構(gòu)成了通信網(wǎng)。通信網(wǎng)的組成：硬體：用戶終端設(shè)備、傳輸設(shè)備、交換設(shè)備軟體：通信網(wǎng)為能很好地完成資訊的傳遞和交換所必需的一整套協(xié)議、標(biāo)準(zhǔn)，包括網(wǎng)路結(jié)構(gòu)、信令方式、協(xié)議和介面、網(wǎng)路管理、技術(shù)體制標(biāo)準(zhǔn)等1.4.1通信系統(tǒng)通信網(wǎng)系統(tǒng)基本功能：⑴基本的傳輸和交換功能。⑵業(yè)務(wù)控制功能。⑶網(wǎng)路管理功能。1.4.2通信軟體凡是用來實(shí)現(xiàn)兩個(gè)或多個(gè)實(shí)體（電腦、電信終端、交換設(shè)備等）之間相互通信的軟體都可稱為通信軟體。電信軟體：電話交換軟體、移動(dòng)通信軟體、智能網(wǎng)軟體等；電腦網(wǎng)絡(luò)軟體：網(wǎng)路協(xié)議軟體、網(wǎng)路應(yīng)用軟體；1.4.2通信軟體電信軟體類型1.4.2通信軟體⑴基本呼叫處理軟體：負(fù)責(zé)呼叫接續(xù)和呼叫狀態(tài)轉(zhuǎn)移的處理。⑵業(yè)務(wù)獨(dú)立邏輯處理模組：將交換機(jī)側(cè)相同的處理功能抽象封裝而成，如智能網(wǎng)。⑶資源管理：為業(yè)務(wù)控制軟體提供資源控制和管理功能。⑷業(yè)務(wù)控制：在通信網(wǎng)業(yè)務(wù)能力基礎(chǔ)上提供業(yè)務(wù)的生成、配置、接入、管理等功能。⑸客戶服務(wù)：客戶關(guān)係管理系統(tǒng)（CRM：CustomerRelationshipManagement），包括業(yè)務(wù)開通、業(yè)務(wù)保障、業(yè)務(wù)計(jì)量；⑹產(chǎn)品開發(fā)與管理電信軟體分類：OSS（OperationSupportSystem，運(yùn)行支撐系統(tǒng)），包括(1)~(4)BSS（BusinessSupportSystem，經(jīng)營支撐系統(tǒng)），包括(5),(6)電信業(yè)內(nèi)將BSS和OSS結(jié)合起來統(tǒng)稱為BOSS（BusinessandOperationSupportSystem，運(yùn)營支撐系統(tǒng)）。某電信運(yùn)營商系統(tǒng)規(guī)劃實(shí)例1.4.3通信軟體工程通信軟體工程就是將軟體工程知識(shí)應(yīng)用於通信領(lǐng)域，完全遵循軟體工程的三要素：過程、方法和工具，只是在過程、方法和工具中要結(jié)合通信軟體的特點(diǎn)。通信系統(tǒng)是全程全網(wǎng)系統(tǒng)，需遵守協(xié)議標(biāo)準(zhǔn)；系統(tǒng)協(xié)作，在資訊建模同時(shí)，需考慮行為建模；分析階段採用UML來表達(dá)軟體系統(tǒng)的功能需求和資訊需求；用MSC圖描述系統(tǒng)與外部環(huán)境的交互以及內(nèi)部對象之間的資訊交互；在系統(tǒng)設(shè)計(jì)階段採用SDL來形式化描述系統(tǒng)設(shè)計(jì)；即時(shí)軟體開發(fā)工具：TelelogicTau1.5軟體工程知識(shí)體系本節(jié)內(nèi)容1.5.1軟體工程知識(shí)體系指南簡介1.5.2軟體工程知識(shí)體系知識(shí)域1.5.1軟體工程知識(shí)體系指南簡介IEEE電腦學(xué)會(huì)的職業(yè)實(shí)踐委員會(huì)主持的一個(gè)專案，目的：促進(jìn)世界範(fàn)圍內(nèi)對軟體工程的一致觀點(diǎn)；闡明軟體工程相對其他學(xué)科（如電腦科學(xué)、專案管理、電腦工程和數(shù)學(xué)等）的位置，並確立它們的分界；刻畫軟體工程學(xué)科的內(nèi)容；提供使用知識(shí)體系的主題；為開發(fā)課程表和個(gè)人認(rèn)證與許可材料提供一個(gè)基礎(chǔ)；1.5.2軟體工程知識(shí)體系知識(shí)域本章內(nèi)容2.1軟體工程過程2.2軟體生命週期2.3軟體過程模型2.4傳統(tǒng)軟體生命週期模型2.5新型軟體生命週期模型2.1軟體工程過程軟體工程過程是為了獲得軟體產(chǎn)品，在軟體工具的支持下由軟體工程師完成的一系列軟體工程活動(dòng)。軟體規(guī)格說明（specification）：規(guī)定軟體的功能及其使用限制；軟體開發(fā)（development）：產(chǎn)生滿足規(guī)格說明的軟體；軟體確認(rèn)（validation）：通過有效性驗(yàn)證以保證軟體能夠滿足客戶的要求；軟體演進(jìn)（evolution）：為了滿足客戶的變更要求，軟體必須在使用過程中進(jìn)行不斷地改進(jìn)。2.2軟體生命週期軟體有一個(gè)孕育、誕生、成長、成熟、衰亡的生存過程。這個(gè)過程即為電腦軟體的生命週期（LifeCycle）。軟體生命週期的六個(gè)基本步驟制定計(jì)畫需求分析設(shè)計(jì)程式編碼測試運(yùn)行維護(hù)制定計(jì)畫確定要開發(fā)軟體系統(tǒng)的總目標(biāo)；給出功能、性能、可靠性以及介面等方面的要求；完成該軟體任務(wù)的可行性研究；估計(jì)可利用的資源(硬體，軟體，人力等)、成本、效益、開發(fā)進(jìn)度；制定出完成開發(fā)任務(wù)的實(shí)施計(jì)畫，連同可行性研究報(bào)告，提交管理部門審查；需求分析對用戶提出的要求進(jìn)行分析並給出詳細(xì)的定義；編寫軟體需求說明書或系統(tǒng)功能說明書及初步的系統(tǒng)用戶手冊；提交管理機(jī)構(gòu)評審；設(shè)計(jì)概要設(shè)計(jì)—把各項(xiàng)需求轉(zhuǎn)換成軟體的體系結(jié)構(gòu)。結(jié)構(gòu)中每一組成部分都是意義明確的模組，每個(gè)模組都和某些需求相對應(yīng)；詳細(xì)設(shè)計(jì)—對每個(gè)模組要完成的工作進(jìn)行具體的描述，為根源程式編寫打下基礎(chǔ)；編寫設(shè)計(jì)說明書，提交評審。程式編碼把軟體設(shè)計(jì)轉(zhuǎn)換成電腦可以接受的程式代碼，即寫成以某一種特定程式設(shè)計(jì)語言表示的“根源程式清單”；寫出的程式應(yīng)當(dāng)是結(jié)構(gòu)良好、清晰易讀的，且與設(shè)計(jì)相一致的；測試單元測試，查找各模組在功能和結(jié)構(gòu)上存在的問題並加以糾正；組裝測試，將已測試過的模組按一定順序組裝起來；按規(guī)定的各項(xiàng)需求，逐項(xiàng)進(jìn)行有效性測試，決定已開發(fā)的軟體是否合格，能否交付用戶使用；運(yùn)行維護(hù)改正性維護(hù)：運(yùn)行中發(fā)現(xiàn)了軟體中的錯(cuò)誤需要修正；適應(yīng)性維護(hù)：為了適應(yīng)變化了的軟體工作環(huán)境，需做適當(dāng)變更；完善性維護(hù)：為了增強(qiáng)軟體的功能需做變更。2.3軟體過程模型模型是實(shí)際事物、實(shí)際系統(tǒng)的抽象。軟體過程模型也稱做軟體生命週期模型，是從一個(gè)特定角度提出的對軟體過程的簡化描述，是對軟體開發(fā)實(shí)際過程的抽象，它包括構(gòu)成軟體過程的各種活動(dòng)、軟體工件（artifact）以及參與角色等。軟體生命週期模型描述從軟體需求定義直至軟體經(jīng)使用後廢棄為止，跨越整個(gè)生存期的軟體開發(fā)、運(yùn)行和維護(hù)所實(shí)施的全部過程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架，同時(shí)描述生命週期不同階段產(chǎn)生的軟體工件，明確活動(dòng)的執(zhí)行角色等。2.4傳統(tǒng)軟體生命週期模型2.4.1瀑布模型2.4.2V模型和W模型2.4.3原型方法2.4.4演化模型2.4.5增量模型2.4.6螺旋模型2.4.7噴泉模型2.4.8構(gòu)件組裝模型2.4.9快速應(yīng)用開發(fā)模型2.4.1瀑布模型WinstonRoyce在軟體生命週期概念的基礎(chǔ)上，於1970年提出了著名的“瀑布模型”（waterfallmodel）。維護(hù)評價(jià)2.4.1瀑布模型瀑布模型中的每一個(gè)開發(fā)活動(dòng)具有下列特徵：本活動(dòng)的工作對象來自於上一項(xiàng)活動(dòng)的輸出，這些輸出一般是代表本階段活動(dòng)結(jié)束的里程碑式的文檔。根據(jù)本階段的活動(dòng)規(guī)程執(zhí)行相應(yīng)的任務(wù)。產(chǎn)生本階段活動(dòng)相關(guān)產(chǎn)出——軟體工件，作為下一活動(dòng)的輸入。對本階段活動(dòng)執(zhí)行情況進(jìn)行評審。2.4.1瀑布模型瀑布模型的優(yōu)缺點(diǎn)優(yōu)點(diǎn)缺點(diǎn)降低了軟體開發(fā)的複雜程度，而且提高了軟體開發(fā)過程的透明性，提高了軟體開發(fā)過程的可管理性。模型缺乏靈活性，特別是無法解決軟體需求不明確或不準(zhǔn)確的問題。推遲了軟體實(shí)現(xiàn)，強(qiáng)調(diào)在軟體實(shí)現(xiàn)前必須進(jìn)行分析和設(shè)計(jì)工作。模型的風(fēng)險(xiǎn)控制能力較弱。

以專案的階段評審和文檔控制為手段有效地對整個(gè)開發(fā)過程進(jìn)行指導(dǎo)，保證了階段之間的正確銜接，能夠及時(shí)發(fā)現(xiàn)並糾正開發(fā)過程中存在的缺陷，從而能夠使產(chǎn)品達(dá)到預(yù)期的品質(zhì)要求。瀑布模型中的軟體活動(dòng)是文檔驅(qū)動(dòng)的，當(dāng)階段之間規(guī)定過多的文檔時(shí)，會(huì)極大地增加系統(tǒng)的工作量；而且當(dāng)管理人員以文檔的完成情況來評估專案完成進(jìn)度時(shí)，往往會(huì)產(chǎn)生錯(cuò)誤的結(jié)論。2.4.2V模型和W模型1980年代後期PaulRook提出了V模型W模型Evolutif公司在V模型的基礎(chǔ)上提出了W模型2.4.3原型方法原型方法的產(chǎn)生瀑布模型、V模型和W模型都將軟體生命週期劃分成獨(dú)立串行的幾個(gè)階段，前一個(gè)階段沒有完成便無法開始下一階段的工作。然而完整而準(zhǔn)確的需求規(guī)格說明是很難得到的，因?yàn)椋涸陂_發(fā)早期用戶往往對系統(tǒng)只有一個(gè)模糊的想法，很難完全準(zhǔn)確地表達(dá)對系統(tǒng)的全面要求隨著開發(fā)工作的推進(jìn)，用戶可能會(huì)產(chǎn)生新的要求開發(fā)者有可能在設(shè)計(jì)與實(shí)現(xiàn)的過程中遇到一些沒有預(yù)料到的實(shí)際困難，需要以改變需求來解脫困境2.4.3原型方法原型指模擬某種最終產(chǎn)品的原始模型；原型方法指在獲得一組基本需求後，通過快速分析構(gòu)造出一個(gè)小型的軟體系統(tǒng)原型，滿足用戶的基本要求。用戶通過使用原型系統(tǒng)，提出修改意見，從而減少用戶與開發(fā)人員對系統(tǒng)需求的誤解，使需求盡可能準(zhǔn)確。原型方法主要用於明確需求，但也可以用於軟體開發(fā)的其他階段。2.4.3原型方法原型的三種作用類型：（1）探索型：弄清用戶對目標(biāo)系統(tǒng)的要求，確定所期望的特性；探討多種實(shí)現(xiàn)方案的可行性。主要針對需求模糊、用戶和開發(fā)者對專案開發(fā)都缺乏經(jīng)驗(yàn)的情況。（2）實(shí)驗(yàn)型；用於大規(guī)模開發(fā)和實(shí)現(xiàn)之前，考核技術(shù)實(shí)現(xiàn)方案是否合適、分析和設(shè)計(jì)的規(guī)格說明是否可靠。（3）進(jìn)化型：在構(gòu)造系統(tǒng)的過程中能夠適應(yīng)需求的變化，通過不斷地改進(jìn)原型，逐步將原型進(jìn)化成最終的系統(tǒng)。它將原型方法的思想擴(kuò)展到軟體開發(fā)的全過程，適用於需求經(jīng)常變動(dòng)的軟體專案。2.4.3原型方法由於運(yùn)用原型的目的和方式不同，在使用原型時(shí)可採取以下兩種不同的策略：廢棄策略：原型主要用於回饋和評價(jià)，據(jù)此設(shè)計(jì)出完整、準(zhǔn)確、一致、可靠的最終系統(tǒng)。系統(tǒng)構(gòu)造完成後，原來的原型系統(tǒng)就被廢棄不用。探索型和實(shí)驗(yàn)型原型屬於這種策略。追加策略：原型作為最終系統(tǒng)的核心，然後通過不斷地?cái)U(kuò)充修改，逐步追加新要求，最後發(fā)展成為最終系統(tǒng)。它對應(yīng)於進(jìn)化型原型。2.4.3原型方法原型方法的特點(diǎn)：（1）從認(rèn)知論的角度看，原型方法遵循了人們認(rèn)識(shí)事物的規(guī)律，因而更容易為人們所普遍接受，這主要表現(xiàn)在：①人們對任何事物的認(rèn)知都不可能一蹴而就、盡善盡美；②認(rèn)識(shí)和學(xué)習(xí)的過程都是循序漸進(jìn)的；③對於事物的描述，往往都是受環(huán)境的啟發(fā)而不斷完善的；④人們批評指責(zé)一個(gè)已有的事物，要比空洞地描述自己的設(shè)想容易得多，改進(jìn)一些事物要比創(chuàng)造一些事物容易得多。2.4.3原型方法⑵原型方法將模擬的手段引入分析的初期階段，溝通了人們的思想，縮短了用戶和開發(fā)人員之間的距離。這主要表現(xiàn)在：①所有問題的討論都是圍繞某一個(gè)確定原型而進(jìn)行的，彼此之間不存在誤解和答非所問的可能性，為準(zhǔn)確認(rèn)識(shí)問題創(chuàng)造了條件。②有了原型才能啟發(fā)人們對原來想不起來或不易準(zhǔn)確描述的問題有一個(gè)比較確切的描述；③能夠及早地暴露出系統(tǒng)實(shí)現(xiàn)後存在的一些問題，促使人們在系統(tǒng)實(shí)現(xiàn)之前就加以解決。2.4.3原型方法原型提供了用戶與開發(fā)人員良好的溝通手段，易於被人們接受，使用原型方法有以下好處：原型方法有助於增進(jìn)軟體人員和用戶對系統(tǒng)服務(wù)需求的理解；原型方法提供了一種有力的學(xué)習(xí)手段；使用原型方法，可以容易地確定系統(tǒng)的性能，確認(rèn)各項(xiàng)主要系統(tǒng)服務(wù)的可應(yīng)用性，確認(rèn)系統(tǒng)設(shè)計(jì)的可行性，確認(rèn)系統(tǒng)作為產(chǎn)品的結(jié)果；軟體原型的最終版本，有的可以原封不動(dòng)地成為產(chǎn)品，有的略加修改就可以成為最終系統(tǒng)的一個(gè)組成部分，這樣有利於建成最終系統(tǒng)。2.4.3原型方法原型法的適用範(fàn)圍和局限性：對於一個(gè)大型系統(tǒng)，如果不經(jīng)過系統(tǒng)分析得到系統(tǒng)的整體劃分，而直接用原型來模擬是很困難的。對於大量運(yùn)算的、邏輯性較強(qiáng)的程式模組，原型方法很難構(gòu)造出該模組的原型來供人評價(jià)。對於原有應(yīng)用的業(yè)務(wù)流程、資訊流程混亂的情況，原型構(gòu)造與使用有一定的困難。對於一個(gè)批處理系統(tǒng)，由於大部分活動(dòng)是內(nèi)部處理的，因此應(yīng)用原型方法會(huì)有一定的困難。2.4.3原型方法原型方法存在的問題：文檔容易被忽略。建立原型的許多工作會(huì)被浪費(fèi)掉。專案難以規(guī)劃和管理。2.4.3原型方法1984年Boar提出一系列影響原型方法選擇的因素方面適用原型法不適用原型法系統(tǒng)結(jié)構(gòu)聯(lián)機(jī)事務(wù)處理系統(tǒng)、相互關(guān)聯(lián)的應(yīng)用系統(tǒng)批處理系統(tǒng)邏輯結(jié)構(gòu)有結(jié)構(gòu)系統(tǒng)，如運(yùn)行支持系統(tǒng)、管理資訊系統(tǒng)基於大量演算法和邏輯結(jié)構(gòu)的系統(tǒng)用戶特徵積極參與、積極決策應(yīng)用約束線上運(yùn)行系統(tǒng)的補(bǔ)充專案管理專案負(fù)責(zé)人願(yuàn)意使用原型方法專案負(fù)責(zé)人不願(yuàn)意使用原型方法專案環(huán)境需求複雜易變、性能要求高需求明確固定2.4.3原型方法原型方法的應(yīng)用過程2.4.3原型方法原型方法可以支持軟體生命週期的不同階段輔助或代替分析階段輔助設(shè)計(jì)階段代替分析與設(shè)計(jì)階段代替分析、設(shè)計(jì)和實(shí)現(xiàn)階段代替全部開發(fā)階段2.4.3原型方法支持原型構(gòu)造的軟體複用技術(shù)所謂複用就是利用一些從早先軟體開發(fā)過程中收集到的、對建立新系統(tǒng)有用的資訊來構(gòu)建新系統(tǒng)。從複用的內(nèi)容角度可以劃分其類型為：數(shù)據(jù)複用：實(shí)現(xiàn)不同數(shù)據(jù)環(huán)境的移植；模組複用：COM/DCOM、JavaBean/EJB、CORBA結(jié)構(gòu)複用：領(lǐng)域內(nèi)通用業(yè)務(wù)邏輯；實(shí)現(xiàn)MVC（Model-View-Control，模型－視圖－控制器）體系結(jié)構(gòu)的Struts框架、實(shí)現(xiàn)資料庫訪問邏輯複用的Hibernate框架等設(shè)計(jì)複用：MDA（ModelDrivenArchitecture，模型驅(qū)動(dòng)體系結(jié)構(gòu)）規(guī)格說明複用：規(guī)格說明可使用或者可參照使用。2.4.3原型方法軟體複用的兩種實(shí)現(xiàn)機(jī)制：合成複用：構(gòu)件是基礎(chǔ)，構(gòu)件以抽象數(shù)據(jù)類型為理論基礎(chǔ)，將功能實(shí)現(xiàn)細(xì)節(jié)與數(shù)據(jù)結(jié)構(gòu)封裝在構(gòu)件內(nèi)部，對外有著精心設(shè)計(jì)的介面，供外部使用者構(gòu)造應(yīng)用時(shí)調(diào)用。構(gòu)件本身可以是對某一函數(shù)、過程、副程式、數(shù)據(jù)類型、演算法等可複用軟體成份的抽象，利用構(gòu)件來構(gòu)造軟體系統(tǒng)，有較高的生產(chǎn)率和較短的開發(fā)週期。生成複用：利用可複用的模式（Patterns），通過生成程式產(chǎn)生一個(gè)新的應(yīng)用程式或程式段2.4.4演化模型使用瀑布模型人們認(rèn)識(shí)到，由於需求很難調(diào)研充分，所以很難一次性開發(fā)成功。演化模型提倡兩次開發(fā)：第一次是試驗(yàn)開發(fā)，得到試驗(yàn)性的原型產(chǎn)品，其目標(biāo)只是在於探索可行性，弄清軟體需求；第二次在此基礎(chǔ)上獲得較為滿意的軟體產(chǎn)品。2.4.4演化模型演化模型分類：探索式演化模型拋棄式演化模型演化模型的特點(diǎn)：優(yōu)點(diǎn)：明確用戶需求、提高系統(tǒng)品質(zhì)、降低開發(fā)風(fēng)險(xiǎn)；缺點(diǎn)：難於管理、結(jié)構(gòu)較差、技術(shù)不成熟；演化模型適用範(fàn)圍：需求不清楚；小型或中小型系統(tǒng)；開發(fā)週期短2.4.5增量模型Mills等人於1980年提出，指首先對系統(tǒng)最核心或最清晰的需求進(jìn)行分析、設(shè)計(jì)、實(shí)現(xiàn)、測試並集成到系統(tǒng)中。再按優(yōu)先順序逐步對後續(xù)的需求進(jìn)行上述工作，逐步建設(shè)成一個(gè)完整系統(tǒng)的開發(fā)方法。2.4.5增量模型使用增量模型開發(fā)字處理軟體時(shí)，可以按照以下優(yōu)先順序進(jìn)行增量開發(fā)：第一個(gè)增量實(shí)現(xiàn)基本的檔管理、編輯和文檔生成功能；第二個(gè)增量實(shí)現(xiàn)更加完善的編輯和文檔生成功能；第三個(gè)增量實(shí)現(xiàn)拼寫和文法檢查功能；第四個(gè)增量完成高級(jí)的頁面佈局功能。2.4.5增量模型增量模型的優(yōu)點(diǎn)：有利於增加客戶對系統(tǒng)的信心；降低系統(tǒng)失敗風(fēng)險(xiǎn)；提高系統(tǒng)可靠性；提高了系統(tǒng)的穩(wěn)定性和可維護(hù)性；增量模型的缺點(diǎn)：增量粒度難以選擇；確定所有的基本業(yè)務(wù)服務(wù)比較困難。2.4.6螺旋模型Boehm於1988年提出，主要針對大型軟體專案的開發(fā)。大型軟體專案的特點(diǎn)：（1）需求功能複雜，無法一開始就明確；開發(fā)週期長，中途需求經(jīng)常變化；（2）往往存在諸多風(fēng)險(xiǎn)因素，在不同程度上損害軟體開發(fā)過程和軟體產(chǎn)品的品質(zhì)，所以必須對風(fēng)險(xiǎn)進(jìn)行管理。螺旋模型最大特點(diǎn)就是引入了明確的風(fēng)險(xiǎn)管理。2.4.6螺旋模型四個(gè)象限制定計(jì)畫風(fēng)險(xiǎn)分析實(shí)施工程客戶評價(jià)2.4.6螺旋模型制定計(jì)畫：確定軟體專案目標(biāo)；明確對軟體開發(fā)過程和軟體產(chǎn)品的約束；制定詳細(xì)的專案管理計(jì)畫；根據(jù)當(dāng)前的需求和風(fēng)險(xiǎn)因素，制定實(shí)施方案，並進(jìn)行可行性分析，選定一個(gè)實(shí)施方案，並對其進(jìn)行規(guī)劃。風(fēng)險(xiǎn)分析：明確每一個(gè)專案風(fēng)險(xiǎn)，估計(jì)風(fēng)險(xiǎn)發(fā)生的可能性、頻率、損害程度，並制定風(fēng)險(xiǎn)管理措施規(guī)避這些風(fēng)險(xiǎn)。實(shí)施工程：針對每一個(gè)開發(fā)階段的任務(wù)要求執(zhí)行本開發(fā)階段的活動(dòng)?？蛻粼u估：客戶使用原型，回饋修改意見；根據(jù)客戶的回饋，對產(chǎn)品及其開發(fā)過程進(jìn)行評審，決定是否進(jìn)入螺旋線的下一個(gè)回路。

2.4.7噴泉模型噴泉模型也稱迭代模型，認(rèn)為軟體開發(fā)過程的各個(gè)階段是相互重疊和多次反復(fù)的，就象噴泉一樣，水噴上去又可以落下來，既可以落在中間，又可以落到底部。各個(gè)開發(fā)階段沒有特定的次序要求，完全可以並行進(jìn)行，可以在某個(gè)開發(fā)階段中隨時(shí)補(bǔ)充其他任何開發(fā)階段中遺漏的需求。優(yōu)點(diǎn)：提高開發(fā)效率縮短開發(fā)週期缺點(diǎn)：難於管理2.4.8構(gòu)件組裝模型構(gòu)件組裝模型利用模組化思想將整個(gè)系統(tǒng)模組化，並在一定構(gòu)件模型的支持下複用構(gòu)件庫中的一個(gè)或多個(gè)軟體構(gòu)件，通過組裝高效率、高質(zhì)量地構(gòu)造軟體系統(tǒng)。構(gòu)件組裝模型本質(zhì)上是演化的，開發(fā)過程是迭代的。構(gòu)件組裝模型的開發(fā)過程就是構(gòu)件組裝的過程，維護(hù)的過程就是構(gòu)件升級(jí)、替換和擴(kuò)充的過程。2.4.8構(gòu)件組裝模型優(yōu)點(diǎn)：充分利用軟體複用，提高了軟體開發(fā)的效率。允許多個(gè)專案同時(shí)開發(fā)，降低了費(fèi)用，提高了可維護(hù)性，可實(shí)現(xiàn)分步提交軟體產(chǎn)品。缺點(diǎn)：缺乏通用的構(gòu)件組裝結(jié)構(gòu)標(biāo)準(zhǔn)，風(fēng)險(xiǎn)較大；構(gòu)件可重用性和系統(tǒng)高效性之間不易協(xié)調(diào)；由於過分依賴於構(gòu)件，構(gòu)件品質(zhì)影響著最終產(chǎn)品的品質(zhì)。2.4.9快速應(yīng)用開發(fā)模型快速應(yīng)用開發(fā)（RapidApplicationDevelopment，RAD）是一個(gè)增量型的軟體開發(fā)過程模型，強(qiáng)調(diào)極短的開發(fā)週期。2.4.9快速應(yīng)用開發(fā)模型RAD模型的缺點(diǎn)：並非所有應(yīng)用都適合採用RAD，如果一個(gè)應(yīng)用不能被模組化，那麼構(gòu)造應(yīng)用的構(gòu)件就無法快速獲取由於時(shí)間約束，開發(fā)人員和客戶必須在較短的時(shí)間內(nèi)完成一系列的需求分析，溝通配合不當(dāng)都會(huì)導(dǎo)致應(yīng)用RAD模型的失敗RAD適合於管理資訊系統(tǒng)的開發(fā)，對於其他類型的應(yīng)用系統(tǒng)，如技術(shù)風(fēng)險(xiǎn)較高、與週邊系統(tǒng)的互操作性較高等，不太合適2.5新型軟體生命週期模型2.5.1RUP2.5.2敏捷模型2.5.1RUPRUP（RationalUnifiedProcess）統(tǒng)一過程模型是由Rational公司（現(xiàn)被IBM公司收購）開發(fā)的一種軟體工程過程框架，是一個(gè)面向?qū)ο蟮幕秝eb的程式開發(fā)方法論。RUP既是一種軟體生命週期模型，又是一種支持面向?qū)ο筌涹w開發(fā)的工具，它將軟體開發(fā)過程要素和軟體工件要素整合在統(tǒng)一的框架中。2.5.1RUPRUP的基本結(jié)構(gòu)2.5.1RUPRUP中的軟體生命週期在時(shí)間上被分解為四個(gè)順序的階段：初始階段（Inception）、細(xì)化階段（Elaboration）、構(gòu)造階段（Construction）和交付階段（Transition）。每個(gè)階段結(jié)束於一個(gè)主要的里程碑(MajorMilestones)，並在階段結(jié)尾執(zhí)行一次評估以確定這個(gè)階段的目標(biāo)是否已經(jīng)滿足。如果評估結(jié)果令人滿意的話，可以允許專案進(jìn)入下一個(gè)階段。2.5.1RUPRUP的9個(gè)核心工作流6個(gè)核心過程工作流商業(yè)建模（BusinessModeling）需求（Requirements）分析和設(shè)計(jì)（Analysis&Design）實(shí)現(xiàn)（Implementation）測試（Test）部署（Deployment）2.5.1RUP3個(gè)核心支持工作流：配置和變更管理（Configuration&ChangeManagement）專案管理（ProjectManagement）環(huán)境（Environment）2.5.1RUP初始階段目標(biāo)是為系統(tǒng)建立商業(yè)案例（businesscase）並確定專案的邊界。商業(yè)案例包括專案的驗(yàn)收規(guī)範(fàn)、風(fēng)險(xiǎn)評估、所需資源估計(jì)、階段計(jì)畫等。要確定專案邊界，需識(shí)別所有與系統(tǒng)交互的外部實(shí)體，並在較高層次上定義外部實(shí)體與系統(tǒng)交互的特性，主要包括識(shí)別外部角色（actor）、識(shí)別所有用例並詳細(xì)描述一些重要的用例。階段結(jié)束里程碑：生命週期目標(biāo)（LifecycleObjective）里程碑，包括一些重要的文檔，如：專案構(gòu)想（vision）、原始用例模型、原始業(yè)務(wù)風(fēng)險(xiǎn)評估、一個(gè)或者多個(gè)原型、原始商業(yè)案例等。需要對這些文檔進(jìn)行評審，以確定正確理解用例需求、專案風(fēng)險(xiǎn)評估合理、階段計(jì)畫可行等。2.5.1RUP細(xì)化階段目標(biāo)是分析問題領(lǐng)域，建立健全的體系結(jié)構(gòu)基礎(chǔ)，編制專案計(jì)畫，完成專案中高風(fēng)險(xiǎn)需求部分的開發(fā)。里程碑：生命週期體系結(jié)構(gòu)（LifecycleArchitecture）里程碑。包括風(fēng)險(xiǎn)分析文檔、軟體體系結(jié)構(gòu)基線、專案計(jì)畫、可執(zhí)行的進(jìn)化原型、初始版本的用戶手冊等。通過評審確定軟體體系結(jié)構(gòu)已經(jīng)穩(wěn)定、高風(fēng)險(xiǎn)的業(yè)務(wù)需求和技術(shù)機(jī)制已經(jīng)解決、修訂的專案計(jì)畫可行等。2.5.1RUP構(gòu)造階段將所有剩餘的技術(shù)構(gòu)件和穩(wěn)定業(yè)務(wù)需求功能開發(fā)出來，並集成為產(chǎn)品，所有功能被詳細(xì)測試。從某種意義上說，構(gòu)造階段只是一個(gè)製造過程，其重點(diǎn)放在管理資源及控制開發(fā)過程以優(yōu)化成本、進(jìn)度和品質(zhì)。里程碑：初始運(yùn)行能力（InitialOperationalCapability）里程碑。包括可以運(yùn)行的軟體產(chǎn)品、用戶手冊等，它決定了產(chǎn)品是否可以在測試環(huán)境中進(jìn)行部署。此刻，要確定軟體、環(huán)境、用戶是否可以開始系統(tǒng)的運(yùn)行。2.5.1RUP移交階段移交階段的重點(diǎn)是確保軟體對最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發(fā)佈做準(zhǔn)備的產(chǎn)品測試，基於用戶回饋的少量調(diào)整。里程碑：產(chǎn)品發(fā)佈(ProductRelease)里程碑。此時(shí)，要確定最終目標(biāo)是否實(shí)現(xiàn)，是否應(yīng)該開始產(chǎn)品下一個(gè)版本的另一個(gè)開發(fā)週期。在一些情況下這個(gè)里程碑可能與下一個(gè)週期的初始階段的相重合。2.5.1RUPRUP的迭代增量開發(fā)思想RUP是融合了噴泉模型和增量模型的一種綜合生命週期模型。每一次迭代就是為了完成一定階段性小目標(biāo)而從事的一系列開發(fā)活動(dòng)。2.5.1RUPRUP通過迭代增量建模思想提高了風(fēng)險(xiǎn)控制能力，這體現(xiàn)在：⑴迭代計(jì)畫安排是風(fēng)險(xiǎn)驅(qū)動(dòng)的，高風(fēng)險(xiǎn)因素集中在前兩個(gè)階段解決，特別是體系結(jié)構(gòu)級(jí)的風(fēng)險(xiǎn)在細(xì)化階段就得到瞭解決，及早降低了系統(tǒng)風(fēng)險(xiǎn)；⑵每一次迭代都包括需求、設(shè)計(jì)、實(shí)施、部署和測試活動(dòng)，因此，每一個(gè)中間產(chǎn)品都得到了集成測試，而且這個(gè)集成測試是在一個(gè)統(tǒng)一的軟體體系結(jié)構(gòu)指導(dǎo)下完成的；2.5.1RUP⑶每一個(gè)階段結(jié)束時(shí)還有嚴(yán)格的品質(zhì)評審，保證里程碑文檔的品質(zhì)；⑷由於中間版本的產(chǎn)品是逐步產(chǎn)生的，而且核心功能和性能需求已經(jīng)包含在前面的版本中，所以，可以根據(jù)市場競爭的情況適時(shí)推出中間版本，降低市場風(fēng)險(xiǎn)。2.5.1RUPRUP的最佳實(shí)踐：⑴短時(shí)間分區(qū)式的迭代：2～6周，不鼓勵(lì)時(shí)間推遲；⑵適應(yīng)性開發(fā)：小步驟、快速回饋和調(diào)整；⑶在早期迭代中解決高技術(shù)風(fēng)險(xiǎn)和高業(yè)務(wù)價(jià)值的問題；⑷不斷地讓用戶參與迭代結(jié)果的評估，並及時(shí)獲取回饋資訊，以逐步闡明問題並引導(dǎo)專案進(jìn)展；⑸在早期迭代中建立內(nèi)聚的核心架構(gòu)。2.5.1RUP⑹不斷地驗(yàn)證品質(zhì)；儘早、經(jīng)常和實(shí)際地測試；⑺使用用例驅(qū)動(dòng)軟體建模：用例是獲取需求、制定計(jì)畫、進(jìn)行設(shè)計(jì)、測試、編寫終端用戶文檔的驅(qū)動(dòng)力量。⑻可視化軟體建模：使用UML（UnifiedModelingLanguage，統(tǒng)一建模語言）進(jìn)行軟體建模。⑼仔細(xì)地管理需求：不要草率地對待需求，而要有機(jī)地進(jìn)行需求的提出、記錄、等級(jí)劃分、追蹤。拙劣的需求管理是專案陷入麻煩的一個(gè)常見原因。⑽實(shí)行變更請求和配置管理。2.5.1RUPRUP是一個(gè)通用的過程範(fàn)本，包含了很多開發(fā)指南、工件、開發(fā)過程所涉及到的角色說明等，因此，具體開發(fā)機(jī)構(gòu)在應(yīng)用RUP開發(fā)專案時(shí)要做裁剪。RUP裁剪可以分為以下幾步：⑴確定本項(xiàng)目需要的工作流。⑵確定每個(gè)工作流需要的工件。⑶確定4個(gè)階段之間的演進(jìn)計(jì)畫。以風(fēng)險(xiǎn)控制為原則，決定每個(gè)階段實(shí)施的工作流，每個(gè)工作流的執(zhí)行程度，生成的工件及其完成程度等。⑷確定每個(gè)階段內(nèi)的迭代計(jì)畫。規(guī)劃RUP的4個(gè)階段中每次迭代開發(fā)的內(nèi)容。⑸規(guī)劃工作流內(nèi)部結(jié)構(gòu)。用活動(dòng)圖（activitydiagram）規(guī)劃工作流中涉及的角色、角色負(fù)責(zé)的活動(dòng)及產(chǎn)出的工件。2.5.2敏捷模型敏捷建模（AgileModeling，AM）是由ScottW.Ambler從許多的軟體開發(fā)過程實(shí)踐中歸納總結(jié)出來的一些敏捷建模價(jià)值觀、原則和實(shí)踐等組成的，它只是一種態(tài)度，不是一個(gè)說明性過程。AM是對已有生命週期模型的補(bǔ)充，它本身不是一個(gè)完整的方法論，在應(yīng)用傳統(tǒng)的生命週期模型時(shí)可以借鑒AM的過程指導(dǎo)思想。2.5.2敏捷模型敏捷建模的價(jià)值觀：個(gè)人和交互勝過過程和工具；實(shí)用的軟體勝過面面俱到的文檔；客戶合作勝過合同談判；回應(yīng)變化勝過遵循計(jì)畫。溝通、簡單、回饋、勇氣、謙遜2.5.2敏捷模型敏捷建模原則：(1)優(yōu)先考慮的是通過儘早地和不斷地提交有價(jià)值的軟體使客戶滿意；(2)即使到了開發(fā)的後期，也歡迎改變需求；(3)敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢；(4)經(jīng)常性地交付可以工作的軟體，交付的間隔可以從幾個(gè)星期到幾個(gè)月，交付的時(shí)間間隔越短越好；(5)圍繞被激勵(lì)起來的個(gè)體來構(gòu)建專案；(6)給他們提供所需的環(huán)境和支持，並且信任他們能夠完成工作；2.5.2敏捷模型(7)在團(tuán)隊(duì)內(nèi)部，最具有效果並富有效率的傳遞資訊的方法，就是面對面的交談；工作的軟體是首要的進(jìn)度度量標(biāo)準(zhǔn)；敏捷過程提倡可持續(xù)的開發(fā)速度；(8)責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個(gè)長期的、恒定的開發(fā)速度；(9)優(yōu)秀的技能和好的設(shè)計(jì)會(huì)增強(qiáng)敏捷能力；(10)簡單是最根本的；(11)最好的構(gòu)架、需求和設(shè)計(jì)出於自組織團(tuán)隊(duì)；(12)每隔一定時(shí)間，團(tuán)隊(duì)會(huì)在如何才能更有效地工作方面進(jìn)行反省，對自己的行為進(jìn)行調(diào)整。2.5.2敏捷模型敏捷建模核心實(shí)踐專案干係人的積極參與正確使用工件集體所有制測試性思維並行創(chuàng)建模型創(chuàng)建簡單的內(nèi)容簡單地建模公開展示模型

切換到另外的工件

小增量建模

和他人一起建模

用代碼驗(yàn)證

使用最簡單的工具

2.5.2敏捷模型敏捷模型補(bǔ)充實(shí)踐：使用建模標(biāo)準(zhǔn)逐漸應(yīng)用模式（pattern）丟棄臨時(shí)模型合同模型要正式為外部交流建模為幫助理解建模重用現(xiàn)有的資源不到萬不得已不更新模型極限編程極限編程(eXtremeProgramming，XP)是敏捷模型的一種實(shí)現(xiàn)過程，由Kent

Beck在1996年提出。極限編程極限編程的12個(gè)實(shí)踐：（1）小版本。為了高度迭代，與客戶展現(xiàn)開發(fā)的進(jìn)展，小版本發(fā)佈是一個(gè)可交流的好辦法，客戶可以針對性提出回饋。但小版本把模組縮得很小，會(huì)影響軟體的整體思路連貫，所以小版本也需要總體合理的規(guī)劃。（2）規(guī)劃遊戲。就是客戶需求，以客戶故事的形式，由客戶負(fù)責(zé)編寫。極限編程不講求統(tǒng)一的客戶需求收集，也不是由開發(fā)人員整理，而是採取讓客戶編寫，開發(fā)人員進(jìn)行分析，設(shè)定優(yōu)先順序別，並進(jìn)行技術(shù)實(shí)現(xiàn)。當(dāng)然遊戲規(guī)則可進(jìn)行多次，每次迭代完畢後再行修改。客戶故事是開發(fā)人員與客戶溝通的焦點(diǎn)，也是版本設(shè)計(jì)的依據(jù)，所以其管理一定是有效的、溝通順暢的。極限編程（3）現(xiàn)場客戶。極限編程要求客戶參與開發(fā)工作，客戶需求就是客戶負(fù)責(zé)編寫的，所以要求客戶在開發(fā)現(xiàn)場一起工作，並為每次迭代提供回饋。（4）隱喻。隱喻是讓專案參與人員都必須對一些抽象的概念理解一致，也就是我們常說的行業(yè)術(shù)語，因?yàn)闃I(yè)務(wù)本身的術(shù)語開發(fā)人員不熟悉，軟體開發(fā)的術(shù)語客戶不理解，因此開始要先明確雙方使用的隱喻，避免歧異。（5）簡單設(shè)計(jì)。極限編程體現(xiàn)跟蹤客戶的需求變化，既然需求是變化的，所以對於目前的需求就不必過多地考慮擴(kuò)展性的開發(fā)，講求簡單設(shè)計(jì)，實(shí)現(xiàn)目前需求即可。簡單設(shè)計(jì)的本身也為短期迭代提供了方便，若開發(fā)者考慮“通用”因素較多，增加了軟體的複雜度，開發(fā)的迭代週期就會(huì)加長。極限編程（6）重構(gòu)。重構(gòu)是極限編程先測試後編碼的必然需求，為了整體軟體可以先進(jìn)行測試，對於一些軟體要開發(fā)的模組先簡單模擬，讓編譯通過，到達(dá)測試的目的。然後再對模組具體“優(yōu)化”，所以重構(gòu)包括模組代碼的優(yōu)化與具體代碼的開發(fā)。重構(gòu)是使用了“物理學(xué)”的一個(gè)概念，是在不影響物體外部特性的前提下，重新優(yōu)化其內(nèi)部的機(jī)構(gòu)。這裏的外部特性就是保證測試的通過。（7）測試驅(qū)動(dòng)開發(fā)。極限編程是以測試開始的，為了可以展示客戶需求的實(shí)現(xiàn)，測試程式優(yōu)先設(shè)計(jì)，測試是從客戶實(shí)用的角度出發(fā)，客戶實(shí)際使用的軟體介面著想，測試是客戶需求的直接表現(xiàn)，是客戶對軟體過程的理解。測試驅(qū)動(dòng)開發(fā)，也就是客戶的需求驅(qū)動(dòng)軟體的開發(fā)。（8）持續(xù)集成。集成的理解就是提交軟體的展現(xiàn)，由於採用測試驅(qū)動(dòng)開發(fā)、小版本的方式，所以不斷集成(整體測試)是與客戶溝通的依據(jù)，也是讓客戶提出回饋意見的參照。持續(xù)集成也是完成階段開發(fā)任務(wù)的標(biāo)誌。極限編程（9）結(jié)對編程。這是極限編程最有爭議的實(shí)踐。就是兩個(gè)程式員合用一臺(tái)電腦編程，一個(gè)編碼，一個(gè)檢查，增加專人審計(jì)是為了提供軟體編碼的品質(zhì)。兩個(gè)人的角色經(jīng)常變換，保持開發(fā)者的工作熱情。這種編程方式對培養(yǎng)新人或開發(fā)難度較大的軟體都有非常好的效果。（10）代碼共有。在極限編程裏沒有嚴(yán)格文檔管理，代碼為開發(fā)團(tuán)隊(duì)共有，這樣有利於開發(fā)人員的流動(dòng)管理，因?yàn)樗械娜硕际煜に械木幋a。（11）編碼標(biāo)準(zhǔn)。編碼是開發(fā)團(tuán)隊(duì)裏每個(gè)人的工作，又沒有詳細(xì)的文檔，代碼的可讀性是很重要的，所以規(guī)定統(tǒng)一的標(biāo)準(zhǔn)和習(xí)慣是必要的，有些象編碼人員的隱喻。（12）每週40小時(shí)工作。極限編程認(rèn)為編程是愉快的工作，不輕易加班，今天的工作今天做，小版本的設(shè)計(jì)也為了單位時(shí)間可以完成的工作安排。本章內(nèi)容3.1基於電腦系統(tǒng)的系統(tǒng)分析3.2可行性分析3.3系統(tǒng)體系結(jié)構(gòu)建模3.4系統(tǒng)流程圖3.5系統(tǒng)分析總結(jié)3.1基於電腦系統(tǒng)的系統(tǒng)分析本節(jié)內(nèi)容3.1.1電腦系統(tǒng)工程3.1.2系統(tǒng)需求識(shí)別3.1.1電腦系統(tǒng)工程Webster定義的電腦系統(tǒng)是：元素的集合或排列，這些元素被組織在一起，以便通過處理外部資訊完成某些預(yù)定的目標(biāo)。這些系統(tǒng)元素是：軟體：指程式、數(shù)據(jù)結(jié)構(gòu)和相關(guān)文檔。硬體：指提供計(jì)算能力的電子設(shè)備和提供外部功能的機(jī)電設(shè)備（感測器、馬達(dá)等）。人員：指使用硬體和軟體的用戶和其他人員。文檔：指手冊、表格和其他表示系統(tǒng)使用和操作的描述性資訊。資料庫：指系統(tǒng)所具有的資訊模型，是系統(tǒng)中對資訊具有存取功能的一個(gè)主要部分。過程：指定義每一種系統(tǒng)元素的特定使用步驟或使用環(huán)境。

3.1.1電腦系統(tǒng)工程電腦系統(tǒng)工程是一個(gè)問題求解活動(dòng)，目的是揭示、分析所期望的功能、性能、介面和約束條件，並把它們分配到各個(gè)系統(tǒng)元素中去。電腦的系統(tǒng)工程包括：硬體工程、軟體工程、人機(jī)工程和數(shù)據(jù)庫工程，每一項(xiàng)工程的作用就是明確和細(xì)化系統(tǒng)的功能和性能的範(fàn)圍和內(nèi)容，產(chǎn)生一個(gè)能與其他系統(tǒng)元素適當(dāng)集成的可操作的系統(tǒng)元素。硬體工程軟體工程3.1.2系統(tǒng)需求識(shí)別系統(tǒng)分析目標(biāo)識(shí)別用戶要求；進(jìn)行技術(shù)分析並進(jìn)行評價(jià)；把功能分配給系統(tǒng)元素；建立成本和進(jìn)度限制；生成系統(tǒng)規(guī)格說明（包括軟體和硬體）?？赏ㄟ^回答以下問題協(xié)助完成系統(tǒng)分析過程系統(tǒng)的總體目標(biāo)是什麼？系統(tǒng)所期望的功能和性能是什麼？系統(tǒng)的可靠性和品質(zhì)要求是什麼？成本與進(jìn)度限制如何？有無軟硬體製造和購買的需求？有效的技術(shù)方案有哪些？將來系統(tǒng)可能有哪些擴(kuò)充？3.2可行性分析本節(jié)內(nèi)容：3.2.1可行性分析的任務(wù)和步驟3.2.2經(jīng)濟(jì)可行性分析3.2.3技術(shù)可行性分析為什麼要進(jìn)行可行性分析影響系統(tǒng)開發(fā)的因素有哪些？時(shí)間因素資源因素成本和利潤的因素技術(shù)條件和能力的因素系統(tǒng)分析和可行性分析的目的是明確系統(tǒng)是否值得做，避免投資損失衡量軟體系統(tǒng)是否值得做的標(biāo)準(zhǔn)：能否帶來經(jīng)濟(jì)效益、企業(yè)效益或社會(huì)效益。援引柳傳志的一段話：“沒錢賺的事我們不幹；有錢賺但投不起錢的事不幹；有錢賺也投得起錢但沒有可靠的人選，這樣的事也不幹?！?.2.1可行性分析的任務(wù)和步驟首先，針對專案確定問題域並對問題域進(jìn)行概要的分析和研究，初步確定專案的規(guī)模、約束和限制條件。其次，針對問題域中的關(guān)鍵和核心問題進(jìn)行簡要的需求分析，抽象出問題域的邏輯結(jié)構(gòu)，並構(gòu)建邏輯模型。最後從邏輯模型出發(fā)，通過小規(guī)模的設(shè)計(jì)和技術(shù)實(shí)現(xiàn)論證，探索出若干種可供選擇的解決方案，並對每種方案進(jìn)行可行性方面的論證?？尚行苑治鲋饕性谝韵滤膫€(gè)方面：經(jīng)濟(jì)可行性分析 技術(shù)可行分析法律可行性分析 實(shí)施方案的選擇3.2.2經(jīng)濟(jì)可行性分析軟體開發(fā)為何要進(jìn)行經(jīng)濟(jì)方面的分析？軟體開發(fā)需要有投資，有投資就需要有收益。目的是從經(jīng)濟(jì)角度評價(jià)一個(gè)新專案是否可行、是否劃算，從而幫助投資人或者用戶正確地做出是否投資於這個(gè)專案的開發(fā)決策。如何進(jìn)行經(jīng)濟(jì)可行性的分析？成本/效益分析是對軟體的開發(fā)成本和可能取得的效益進(jìn)行權(quán)衡比較。短期/長遠(yuǎn)利益分析而是從另一種角度來評價(jià)成本和效益之間的關(guān)係。軟體成本的估算方法軟體開發(fā)體現(xiàn)為最終可運(yùn)行的軟體系統(tǒng)以及相應(yīng)的開發(fā)過程，為此有以下估算軟體成本的方法：代碼行技術(shù)每行代碼的成本×代碼行數(shù)；代碼行數(shù)：根據(jù)經(jīng)驗(yàn)和歷史數(shù)據(jù)估計(jì)；每行代碼成本：根據(jù)軟體複雜度和開發(fā)人員工資估計(jì)；功能點(diǎn)技術(shù)以軟體功能作為測量依據(jù)；功能點(diǎn)測量法；任務(wù)分解技術(shù)將整個(gè)開發(fā)過程分解為幾個(gè)獨(dú)立的任務(wù)；評估每個(gè)任務(wù)的成本，再求和得到整個(gè)系統(tǒng)的成本；每個(gè)任務(wù)成本＝每人月平均成本×人月數(shù)；軟體成本的估算方法經(jīng)驗(yàn)估算模型根據(jù)以往經(jīng)驗(yàn)總結(jié)出軟體成本估算模型，軟體規(guī)模（例如LOC）作為模型的輸入；不同的專案需要對模型參數(shù)進(jìn)行相應(yīng)調(diào)整；COCOMO模型BarryBoehm在《軟體工程經(jīng)濟(jì)學(xué)》仲介紹的軟體估算模型，稱為COCOMO（ConstructiveCostMOdel），該模型為分層模型，分為基本模型、中級(jí)模型和高級(jí)模型。軟體方程式：多變量模型軟體成本的估算方法軟體的其他成本估算：除了以上主要的軟體開發(fā)成本之外，還必須考慮支撐軟體開發(fā)所必需的市場、銷售和行政等項(xiàng)的開支，根據(jù)經(jīng)驗(yàn)有如下內(nèi)容需要考慮：辦公室房租、現(xiàn)場開發(fā)住宿費(fèi)等。辦公用品，如桌、椅、書櫃、照明電器、空調(diào)等。電腦、印表機(jī)、網(wǎng)路等硬體設(shè)備。電話、傳真等通訊設(shè)備以及通訊費(fèi)用。資料費(fèi)。辦公消耗，如水電費(fèi)、列印複印費(fèi)等。行政人員的工資。差旅費(fèi)、國內(nèi)外出差補(bǔ)貼等。做市場調(diào)查、可行性分析、需求分析的交際費(fèi)用。公司人員培訓(xùn)費(fèi)用。產(chǎn)品宣傳費(fèi)用。如果用Internet作宣傳，則要考慮建設(shè)Web站點(diǎn)的費(fèi)用。軟體開發(fā)的效益度量貨幣的時(shí)間價(jià)值：由於任何軟體專案大都是投資在前，取得效益在後，因此要考慮到貨幣的時(shí)間價(jià)值。設(shè)年利率為i，現(xiàn)存入P元，若計(jì)複利則n年後貨幣價(jià)值為反之，若n年能收入F元，那麼這些錢的現(xiàn)值是軟體開發(fā)的效益度量例如：某企業(yè)花20萬引進(jìn)資訊化系統(tǒng)後，每年節(jié)省9.6萬元的人力成本，若該軟體生命週期為5年，銀行年利率5%，請計(jì)算其節(jié)約的成本的當(dāng)前價(jià)值是多少？解：因?yàn)椋核裕旱趎年節(jié)約成本當(dāng)前價(jià)值=第n年節(jié)約成本/(1+0.05)n軟體開發(fā)的效益度量投資回收期：就是使累計(jì)的經(jīng)濟(jì)效益等於最初的投資費(fèi)用所需的時(shí)間。投資回收期越短，就能越快獲得利潤。設(shè)上例中的投資回收期為N，則：（N-2）*8.29=20-17.85N=2.259年純收入：就是在整個(gè)生存期之內(nèi)系統(tǒng)的累計(jì)經(jīng)濟(jì)效益（折合成現(xiàn)在值）與投資之差。純收入>0說明值得投資純收入=0等於把資金存入銀行純收入<0說明不值得投資上例中的純收入為：41.563-20=21.563萬元軟體開發(fā)的效益度量投資回收率：設(shè)想把數(shù)量等於投資額的資金存入銀行，每年年底從銀行回收的錢等於系統(tǒng)每年預(yù)期可以獲得的效益，在時(shí)間等於系統(tǒng)壽命時(shí)，正好把在銀行中的存款全部取完。這個(gè)假想的年利率就等於投資回收率。P＝F1／(1+j)+F2／(1+j)2+…+Fn／(1+J)n其中，P是現(xiàn)在的投資額；Fi是第i年年底的效益（i＝1,2,…,n）；n是系統(tǒng)的使用壽命，j是投資回收率。3.2.3技術(shù)可行性分析技術(shù)可行性分析主要考慮以下幾項(xiàng)內(nèi)容：開發(fā)風(fēng)險(xiǎn)：在給定的限制範(fàn)圍內(nèi)，能否設(shè)計(jì)出系統(tǒng)，並實(shí)現(xiàn)必須的功能和性能？資源可用性：是否有充足的熟練技術(shù)人員可以支配？其他必要的資源（軟體和硬體）對建造系統(tǒng)可用麼？技術(shù)條件：相關(guān)的技術(shù)條件是否能夠支持系統(tǒng)的開發(fā)？最終得出一個(gè)在技術(shù)層面上的決策基礎(chǔ)：可行，還是不可行！技術(shù)可行性分析的機(jī)制Blanchard和Fabrycky定義了在系統(tǒng)的技術(shù)可行性分析中使用建模方法的一組標(biāo)準(zhǔn)：能動(dòng)態(tài)地表示系統(tǒng)的配置並能進(jìn)行評估，要求配置項(xiàng)很容易理解和操縱、並且與現(xiàn)實(shí)操作足夠接近。模型應(yīng)該盡可能全面的包括所有相關(guān)的因素，並且應(yīng)體現(xiàn)結(jié)果的可重複性。模型應(yīng)該關(guān)注那些關(guān)鍵問題的因素，並且抑制和回避那些不重要的因素。模型設(shè)計(jì)應(yīng)該足夠簡單，以允許快速實(shí)現(xiàn)。模型設(shè)計(jì)應(yīng)該易於修改和/或擴(kuò)展。3.3系統(tǒng)體系結(jié)構(gòu)建模本節(jié)內(nèi)容：3.3.1構(gòu)建系統(tǒng)級(jí)體系結(jié)構(gòu)3.3.2系統(tǒng)結(jié)構(gòu)的規(guī)格說明定義3.3.3分配與權(quán)衡3.3.1構(gòu)建系統(tǒng)級(jí)體系結(jié)構(gòu)每個(gè)基於電腦的系統(tǒng)可用輸入-處理-輸出（IPO）的結(jié)構(gòu)來為資訊的變換和處理建模，在附加經(jīng)常使用的用戶介面處理和維護(hù)自測試處理特性，構(gòu)成了系統(tǒng)體系結(jié)構(gòu)範(fàn)本。通過創(chuàng)建一個(gè)系統(tǒng)結(jié)構(gòu)模型，為後期的需求分析和設(shè)計(jì)奠定了基礎(chǔ)，同時(shí)也是技術(shù)可行性分析建模的主要方法。體系結(jié)構(gòu)語境圖ACD最高層的系統(tǒng)體系結(jié)構(gòu)叫做體系結(jié)構(gòu)語境圖ACD。語境圖建立了待實(shí)現(xiàn)系統(tǒng)與系統(tǒng)運(yùn)行環(huán)境之間的資訊邊界： 定義了系統(tǒng)使用資訊的所有外部生產(chǎn)者；系統(tǒng)創(chuàng)建消息的所有外部消費(fèi)者；所有通過介面通信或完成維護(hù)和自測的實(shí)體；構(gòu)建ACD實(shí)例描述分類帶傳送系統(tǒng)（CLSS）分類站處設(shè)置PC程式軟體，能夠通過掃描輸入帶上的產(chǎn)品的條碼，根據(jù)系統(tǒng)存儲(chǔ)的產(chǎn)品分類資訊對產(chǎn)品進(jìn)行分類，並結(jié)合傳送帶的速度，對分類控制器硬體進(jìn)行控制，對產(chǎn)品進(jìn)行分類。此外，程式還可以與中央工廠自動(dòng)化主機(jī)進(jìn)行通信；並與分類站操作人員進(jìn)行交互，支持資訊查詢和故障診斷。CLSS的ACDCLSS的AFD體系結(jié)構(gòu)流程圖AFD的擴(kuò)展最初的AFD中的每個(gè)圓角矩形又可被擴(kuò)展為另一個(gè)專門描述它的體系結(jié)構(gòu)範(fàn)本。每個(gè)子系統(tǒng)的說明描述和在子系統(tǒng)間流動(dòng)的所有數(shù)據(jù)的定義構(gòu)成了系統(tǒng)規(guī)約的重要元素。3.3.2系統(tǒng)結(jié)構(gòu)的規(guī)格說明定義結(jié)構(gòu)圖的規(guī)格說明（ADS）給出了每個(gè)子系統(tǒng)的資訊、各個(gè)子系統(tǒng)之間的資訊流以及每個(gè)子系統(tǒng)的“系統(tǒng)模組描述”。規(guī)格說明還可能具有一個(gè)“結(jié)構(gòu)詞典”，即在規(guī)格說明中出現(xiàn)的每一個(gè)資訊項(xiàng)的清單，以及每個(gè)資訊項(xiàng)的說明。例如AFD中的“部分號(hào)碼”的說明如下：

資訊項(xiàng)名稱部分號(hào)碼資訊項(xiàng)說明產(chǎn)品類型首碼+數(shù)字標(biāo)識(shí)+成本類型類型（數(shù)據(jù)或控制）數(shù)據(jù)來源（外部實(shí)體或子系統(tǒng)）條碼閱讀器控制子系統(tǒng)去處（外部實(shí)體或子系統(tǒng)）資料庫訪問子系統(tǒng)通信路徑（名稱）內(nèi)部軟體介面3.3.3分配與權(quán)衡3.4系統(tǒng)流程圖本節(jié)內(nèi)容：3.4.1符號(hào)3.4.2示例3.4.3分層3.4.1符號(hào)3.4.2示例3.4.3分層如果系統(tǒng)比較複雜，可以採用流程圖分層次地描述系統(tǒng)。高層的系統(tǒng)流程圖描述系統(tǒng)總體概貌，定義其中的關(guān)鍵功能。對每個(gè)關(guān)鍵功能再進(jìn)一步擴(kuò)展為獨(dú)立的流程圖。3.5系統(tǒng)分析總結(jié)本節(jié)內(nèi)容：3.5.1系統(tǒng)規(guī)格說明書3.5.2可行性分析報(bào)告本章內(nèi)容4.1什麼是軟體的需求4.2軟體需求分析的目標(biāo)和任務(wù)4.3軟體需求分析建模的原則和方法4.4軟體需求工程4.5軟體需求分析過程本章目標(biāo)為何要進(jìn)行軟體的需求分析？軟體的需求分析處於軟體生命週期的那個(gè)階段？起到什麼作用？怎樣才能做好軟體需求分析？軟體需求分析的過程和步驟是什麼？軟體需求分析的最終結(jié)果是什麼？4.1什麼是軟體的需求4.1.1需求的定義4.1.2需求分析失敗案例4.1.1需求的定義需求來源於用戶的一些“需要”，這些“需要”被分析、確認(rèn)後形成完整的文檔，該文檔詳細(xì)地說明了產(chǎn)品“必須或應(yīng)當(dāng)”做什麼。Boehm給出軟體需求的定義：研究一種無二義性的表達(dá)工具，它能為用戶和軟體人員雙方都接受，並能夠把“需求”嚴(yán)格地、形式地表達(dá)出來?！靶枨蟆⒃O(shè)計(jì)、編程、測試四者究竟哪個(gè)環(huán)節(jié)最重要？”首先，每個(gè)環(huán)節(jié)都是很重要，任何一個(gè)環(huán)節(jié)出現(xiàn)問題，都會(huì)導(dǎo)致軟體的品質(zhì)問題。但是，從風(fēng)險(xiǎn)管理的角度來看，需求是軟體產(chǎn)品的起源，因而是最重要的一個(gè)環(huán)節(jié)。4.1.2需求分析失敗案例某大型的電信設(shè)備供應(yīng)商，案例中涉及6個(gè)部門A,B,C,D,E和F，它們之間的關(guān)係如下圖所示：F客戶E：網(wǎng)管軟體承包商D銷售機(jī)構(gòu)A：增值業(yè)務(wù)研發(fā)機(jī)構(gòu)C：專案管理機(jī)構(gòu)B：核心平臺(tái)研發(fā)機(jī)構(gòu)一年前，B研製了一種數(shù)據(jù)接入伺服器的原型。B對A講：“我們的接入伺服器前途很好，請你們幫助開發(fā)網(wǎng)管軟體（屬於增值業(yè)務(wù)範(fàn)疇），大家合作把產(chǎn)品做好，一起發(fā)財(cái)?！盌對B和A講：“你們把接入伺服器和網(wǎng)管軟體做好，我們負(fù)責(zé)賣，掙了錢大家一起分。”4.1.2需求分析失敗案例A覺得機(jī)會(huì)難得，於是向C申請立項(xiàng)。立項(xiàng)後，A把專案外包給專業(yè)做網(wǎng)管軟體的公司E，期望半年內(nèi)完成。由於接入伺服器是B的，於是A和E就派開發(fā)人員到B處搞需求分析。B的接入伺服器並不成熟，老在變，三方折騰了好久，最終E用了一年時(shí)間把接入伺服器的網(wǎng)管軟體做出來了。

E把網(wǎng)管軟體交付給A，A付清了E的開發(fā)費(fèi)用，再把網(wǎng)管軟體交付給D，D再賣給客戶F（某地電信局）。F對D講：“你們的網(wǎng)管軟體不是我們想要的東西，等你們把軟體改好後我們再付錢?！盌趕緊對A講：“兄弟阿，貨已經(jīng)出手了，但是不對路，請趕緊把它改好，不然大家都沒錢賺?！盇很憤怒，怨天不公：“我們辛苦了一年，又花了很多錢，可是產(chǎn)品做完了卻沒人要，豈有此理！”4.1.2需求分析失敗案例禍不單行的是，C來找A的麻煩：“你們的專案延期半年多了，經(jīng)費(fèi)也用光了，請儘快結(jié)束專案?！盇的那位專案經(jīng)理為此每天愁眉苦臉，他的上司請來幾位參謀商量對策，設(shè)法把事情搞定。大家挖空心思只想出一個(gè)餿主意：既然套子是B下的，那麼就把套子還給B。要設(shè)法把“那麼好”的網(wǎng)管產(chǎn)品轉(zhuǎn)讓給B，只要B能給我們成本費(fèi)，以後就跟B拜拜。這個(gè)案例的問題根源在於進(jìn)行軟體開發(fā)之前沒有搞清楚網(wǎng)管軟體的需求，這都是B,A,E閉門造車惹的禍。最可悲的是，相關(guān)責(zé)任人關(guān)心的是如何把事情“完成”，而不是深刻瞭解用戶的具體需求。這種類似的事情在軟體開發(fā)行業(yè)中經(jīng)常發(fā)生而且還會(huì)繼續(xù)發(fā)生，最主要的是每發(fā)生一次就損失大量的人力和物力。4.2軟體需求分析的目標(biāo)和任務(wù)需求分析是一項(xiàng)必須的軟體工程活動(dòng)。它在系統(tǒng)需求分析和軟體設(shè)計(jì)之間起到橋樑的作用：它使得軟體開發(fā)人員在系統(tǒng)分析的基礎(chǔ)上深入描述軟體的功能和性能、指明軟體和其他系統(tǒng)元素的介面，建立軟體必須滿足的約束條件。它允許軟體開發(fā)人員對關(guān)鍵問題進(jìn)行細(xì)化，並構(gòu)建相應(yīng)的分析模型：數(shù)據(jù)、功能和行為模型。分析模型成為設(shè)計(jì)模型的基礎(chǔ)，需求規(guī)格說明書也為軟體測試人員和用戶提供了軟體品質(zhì)評估的依據(jù)。它能準(zhǔn)確表達(dá)用戶對系統(tǒng)的各項(xiàng)要求。4.2軟體需求分析的目標(biāo)和任務(wù)軟體需求分析的對象是用戶要求。其任務(wù)是要準(zhǔn)確地定義新系統(tǒng)的目標(biāo)?；卮鹣到y(tǒng)必須“做什麼”的問題並編制需求規(guī)格說明書。作為目標(biāo)系統(tǒng)的參考，需求分析的任務(wù)就是借助於（業(yè)務(wù)）系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型，解決目標(biāo)系統(tǒng)的“做什麼”的問題。軟體開發(fā)的目標(biāo)需求分析的目標(biāo)4.2軟體需求分析的目標(biāo)和任務(wù)（1）獲得當(dāng)前系統(tǒng)的物理模型：分析、理解當(dāng)前系統(tǒng)（人工處理或原電腦系統(tǒng)）是如何運(yùn)行的，瞭解其組織機(jī)構(gòu)、輸入輸出、資源利用情況和日常數(shù)據(jù)處理過程。（2）抽象出當(dāng)前系統(tǒng)的邏輯模型：在理解當(dāng)前系統(tǒng)“怎樣做”的基礎(chǔ)上，抽取其“做什麼”的本質(zhì)。（3）建立目標(biāo)系統(tǒng)的邏輯模型：分析目標(biāo)系統(tǒng)與當(dāng)前系統(tǒng)邏輯上的差別，明確目標(biāo)系統(tǒng)到底要“做什麼”，進(jìn)而從當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型。（4）對邏輯模型的補(bǔ)充：包括說明目標(biāo)系統(tǒng)的用戶介面、系統(tǒng)細(xì)節(jié)和性能限制等。4.3需求分析建模的原則和方法4.3.1數(shù)據(jù)建模4.3.2功能和行為建模4.3.3問題劃分需求分析的三元模型需求分析方法的一組操作性原則是：問題的資訊域必須被表示和理解。軟體將完成的功能必須被定義。軟體的行為（作為外部事件的結(jié)果）必須被表示。描述資訊、功能和行為的模型必須被劃分，使得可以用層次的方式揭示細(xì)節(jié)。分析過程應(yīng)該遵從自頂向下，逐層細(xì)化的原則。需求分析的三元模型：數(shù)據(jù)模型——第1條原則功能模型——第2條原則行為模型——第3條原則需求工程的指導(dǎo)性原則首先要正確地理解問題，再建立分析模型。記錄每個(gè)需求的起源及原因，保證需求的可回溯性。開發(fā)一個(gè)能使用戶能夠瞭解人機(jī)交互過程的原型。因?yàn)閷涹w品質(zhì)的感覺經(jīng)?；秾槊妗坝押眯浴钡母杏X。使用多個(gè)需求視圖。建立數(shù)據(jù)模型、功能模型和行為模型，為軟體工程師提供三種不同的視圖，增加識(shí)別不一致性的基礎(chǔ)。給需求賦予優(yōu)先順序。緊張的開發(fā)時(shí)間要求儘量避免一次性實(shí)現(xiàn)每個(gè)軟體需求，應(yīng)採用迭代增量的開發(fā)模型。努力刪除歧義性。因?yàn)榇蠖鄶?shù)需求以自然語言描述，存在歧義性的可能性，正式的技術(shù)評審是發(fā)現(xiàn)並刪除歧義性的一種有效方法。4.3.1數(shù)據(jù)建模資訊域包含三個(gè)不同的數(shù)據(jù)和控制視圖：資訊內(nèi)容和關(guān)係；資訊流；資訊結(jié)構(gòu)。資訊流表示了數(shù)據(jù)和控制在系統(tǒng)中流動(dòng)時(shí)變化的方式資訊內(nèi)容表示了個(gè)體數(shù)據(jù)和控制對象；數(shù)據(jù)和控制對象可和其他的數(shù)據(jù)和控制對象關(guān)聯(lián)資訊結(jié)構(gòu)表示了各種數(shù)據(jù)和控制項(xiàng)的內(nèi)部組織4.3.2功能和行為建模功能模型：對進(jìn)入軟體的資訊和數(shù)據(jù)進(jìn)行變換和處理的模組，它必須至少完成三個(gè)常見功能：輸入、處理和輸出。行為模型：大多數(shù)軟體對來自外界的事件做出反應(yīng)，這種刺激／反應(yīng)特徵形成了行為模型的基礎(chǔ)。行為模型創(chuàng)建了軟體狀態(tài)的表示，以及導(dǎo)致軟體狀態(tài)變化的事件的表示。功能模型和行為模型的作用如下：模型能夠幫助軟體開發(fā)人員快速準(zhǔn)確的理解系統(tǒng)所涉及的資訊、功能和動(dòng)態(tài)行為；模型可成為後期軟體設(shè)計(jì)的基礎(chǔ)，為軟體設(shè)計(jì)人員提供了設(shè)計(jì)軟體功能的視圖化表示；模型能夠成為軟體測試和軟體評審的重要依據(jù)4.3.3問題劃分需求問題域涉及面廣泛而且複雜，以至於難以進(jìn)行整體理解。為此，需要將這樣的問題劃分為易於理解的子問題，並建立各子問題間的關(guān)係以使得可以完成整個(gè)功能。軟體的資訊、功能和行為域可以被劃分。在本質(zhì)上，劃分將問題分解為其構(gòu)成成分。在概念上，建立資訊或功能的層次結(jié)構(gòu)表示，通過進(jìn)行自頂向下的分析，進(jìn)而暴露更多的細(xì)節(jié)問題，並在各層次上進(jìn)行各功能元素的分配。4.4軟體需求工程軟體的需求分析是一系列複雜的軟體工程活動(dòng)，為了便於對需求進(jìn)行更好的管理，人們把所有與需求直接相關(guān)的活動(dòng)通稱為需求工程。需求工程需求開發(fā)需求變更控制需求管理需求確認(rèn)需求跟蹤需求獲取需求分析需求定義用戶需求說明書軟體需求規(guī)格說明書需求跟蹤矩陣

需求評審報(bào)告

需求變更控制報(bào)告4.5軟體需求分析過程4.5.1軟體需求獲取的對象及注意事項(xiàng)4.5.2需求獲取4.5.3需求類別4.5.4需求分析與綜合4.5.5需求建模4.5.6編制需求分析文檔4.5.7需求確認(rèn)4.5.8需求分析評審4.5.1軟體需求獲取的對象及注意事項(xiàng)需求獲取的對象：用戶“用戶”（user）是一種泛稱，它可細(xì)分為：“客戶”（Customer）：掏錢買軟體的用戶“最終用戶”（Enduser）：真正操作軟體的用戶“間接用戶”（或稱為關(guān)係人）如果軟體是面向企業(yè)用戶的，那麼客戶與最終用戶通常不是同一個(gè)人。如果軟體是面向個(gè)人用戶的，那麼客戶與最終用戶通常是同一個(gè)人。軟體需求獲取的注意事項(xiàng)用戶無法清晰地表達(dá)需求本身不清楚要做什麼知道做什麼卻表達(dá)不準(zhǔn)確需求分析員的職責(zé)就是設(shè)法搞清楚用戶真正的需求。雙方或多方對需求的理解往往存在歧義需求會(huì)經(jīng)常發(fā)生變化：避免由於溝通不充分而發(fā)生的變更；歡迎因環(huán)境變化造成的變更；需求變更並不可怕，可怕的是需求變更失去控制，導(dǎo)致專案混亂。4.5.2需求獲取目的獲取用戶（客戶與最終用戶）的需求資訊，經(jīng)過分析後產(chǎn)生《用戶需求說明書》。角色與職責(zé)需求分析員調(diào)查、分析用戶的需求，客戶與最終用戶提供必要的需求資訊。啟動(dòng)準(zhǔn)則需求分析員已經(jīng)確定輸入任何與用戶需求相關(guān)的材料主要步驟第一步：準(zhǔn)備調(diào)查第二步：調(diào)查與記錄第三步：分析需求資訊第四步：撰寫《用戶需求說明書》第五步：需求確認(rèn)輸出《用戶需求說明書》結(jié)束準(zhǔn)則需求分析員已經(jīng)撰寫完成《用戶需求說明書》，確保無拼寫、排版等錯(cuò)誤。並確保《用戶需求說明書》的內(nèi)容無二義性，且涵蓋了所有的用戶需求。度量需求分析員統(tǒng)計(jì)工作量和上述文檔的規(guī)模，彙報(bào)給專案經(jīng)理。需求獲取流程：需求獲取的準(zhǔn)備工作需求獲取的準(zhǔn)備工作圍繞三項(xiàng)展開：調(diào)查什麼？通過什麼方式去調(diào)查？“何人”在“何時(shí)”調(diào)查？首先，應(yīng)起草需求調(diào)查問題表，將重點(diǎn)鎖定在該問題表內(nèi)，否則調(diào)查工作將變得漫無邊際。其次，應(yīng)當(dāng)確定需求調(diào)查的方式，比如：與用戶交談，向用戶提問題。參觀用戶的工作流程，觀察用戶的操作。向用戶群體發(fā)調(diào)查問卷。與同行、專家交談，聽取他們的意見。需求獲取的記錄準(zhǔn)備工作完畢後，需求分析員按照計(jì)畫執(zhí)行調(diào)查。在調(diào)查過程中隨時(shí)記錄（或存儲(chǔ)）需求資訊，建議採用表格的形式，如下圖：需求標(biāo)題1調(diào)查方式調(diào)查人調(diào)查對象時(shí)間、地點(diǎn)需求資訊記錄基本要素如“是什麼”、“為什麼”等需求獲取注意事項(xiàng)如果與用戶約好了時(shí)間，切勿遲到或早退。要注意禮節(jié)，盡可能獲得用戶的好感，並為下次打擾他們埋下伏筆。需求分析員應(yīng)事先瞭解用戶的身份、背景，以便隨機(jī)應(yīng)變。需求調(diào)查應(yīng)該先瞭解宏觀問題，再瞭解細(xì)節(jié)問題。如果雙方氣氛融洽，可以採用靈活的訪談形式，輕易不要打斷用戶的談話。當(dāng)雙方對某些問題的交流合乎邏輯地結(jié)束後，即可繼續(xù)討論問題表中的其他問題。盡可能避免為用戶添麻煩，但也不能怕給用戶添麻煩而降低需求調(diào)查的力度。避免片面地聽取某些用戶的需求而忽視其他用戶的需求。撰寫用戶需求說明書對收集到的所有需求資訊進(jìn)行分析，消除錯(cuò)誤，歸納與總結(jié)共性的用戶需求。按照規(guī)定的文檔範(fàn)本撰寫《用戶需求說明書》，調(diào)查過程中獲取的需求資訊可以作為《用戶需求說明書》的附件。之後應(yīng)當(dāng)邀請同行專家和用戶一起評審《用戶需求說明書》，盡最大努力使《用戶需求說明書》能夠正確無誤地反映用戶的真實(shí)意願(yuàn)。用戶需求說明書與

軟體需求規(guī)格說明書的區(qū)別前者主要採用自然語言來表達(dá)用戶需求，其內(nèi)容相對於後者而言比較粗略，不夠詳細(xì)。後者是前者的細(xì)化，更多地採用電腦語言和圖形符號(hào)來刻畫需求，軟體需求是軟體系統(tǒng)設(shè)計(jì)的直接依據(jù)。兩者之間可能並不存在一一映射關(guān)係，因?yàn)檐涹w開發(fā)商會(huì)根據(jù)產(chǎn)品發(fā)展戰(zhàn)略、企業(yè)當(dāng)前狀況適當(dāng)?shù)卣{(diào)整軟體需求，例如用戶需求可能被分配到軟體的數(shù)個(gè)版本中。軟體開發(fā)人員應(yīng)當(dāng)依據(jù)《軟體需求規(guī)格說明書》來開發(fā)當(dāng)前產(chǎn)品。4.5.3需求類別功能需求：列舉出所開發(fā)軟體在功能上應(yīng)做什麼，這是最主要的需求。性能需求：給出所開發(fā)軟體的技術(shù)性能指標(biāo)，尤其是系統(tǒng)的即時(shí)性和其他時(shí)間要求，如回應(yīng)時(shí)間、處理時(shí)間、消息傳送時(shí)間等；資源配置要求，精確度，數(shù)據(jù)處理量等要求。環(huán)境需求：是對軟體系統(tǒng)運(yùn)行時(shí)所處環(huán)境的要求。在硬體方面，採用什麼機(jī)型、有什麼外部設(shè)備、數(shù)據(jù)通信介面等等。在軟體方面，採用什麼支持系統(tǒng)運(yùn)行的系統(tǒng)軟體（指操作系統(tǒng)、網(wǎng)路軟體、資料庫管理系統(tǒng)等）。在使用方面，需要使用部門在制度上、操作人員的技術(shù)水準(zhǔn)上應(yīng)具備什麼樣的條件等等。4.5.3需求類別可靠性需求：指軟體的有效性和數(shù)據(jù)完整性。各種軟體在運(yùn)行時(shí)失效的影響各不相同。在需求分析時(shí)，應(yīng)對所開發(fā)軟體在投入運(yùn)行後不發(fā)生故障的概率，按實(shí)際的運(yùn)行環(huán)境提出要求。安全保密要求：工作在不同環(huán)境的軟體對其安全、保密的要求顯然是不同的，應(yīng)當(dāng)把這方面的需求恰當(dāng)?shù)刈龀鲆?guī)定。用戶介面需求：軟體與用戶介面的友好性是用戶能夠方便有效愉快地使用該軟體的關(guān)鍵之一。4.5.3需求類別資源使用需求：指所開發(fā)軟體