軟件工程基礎(chǔ)與案例教程 課件 第1、2部分 軟件工程基礎(chǔ)；結(jié)構(gòu)化分析、設(shè)計(jì)與測(cè)試

軟件工程基礎(chǔ)與案例教程

(微課視頻版)第一部分：軟件工程理論基礎(chǔ)什么是軟件工程？軟件工程的思想是什么？軟件工程有哪些基本原理和原則？軟件過(guò)程與過(guò)程模型的關(guān)系是什么？什么是敏捷軟件開發(fā)？如何進(jìn)行用例建模？第1章軟件工程概述內(nèi)容提要：關(guān)于軟件關(guān)于軟件工程軟件工程基本原理與基本原則軟件工程范型軟件工程基本活動(dòng)1.1關(guān)于軟件軟件概念：三要素：軟件=程序+文檔+數(shù)據(jù)軟件特性：復(fù)雜性一致性退化性易變性移植性高成本軟件開發(fā)技術(shù)演化軟件技術(shù)發(fā)展階段。1946年到60年代初：個(gè)體手工方式。結(jié)構(gòu)化和面向?qū)ο蟪绦蛟O(shè)計(jì)階段。60年代初到80年代初：小組化生產(chǎn)，出現(xiàn)軟件危機(jī)。軟件工程階段。20世紀(jì)90年代中期至今：把工程化的思想引入到軟件開發(fā)中，結(jié)構(gòu)化方法的發(fā)展，規(guī)?；浖_發(fā)。面向?qū)ο蠓椒▽W(xué)發(fā)展，軟件定制和滿足客戶需求。發(fā)展趨勢(shì)軟件服務(wù)：云服務(wù)、大數(shù)據(jù)服務(wù)多樣性：中間件開放性：新型中間件平臺(tái)1.2關(guān)于軟件工程軟件危機(jī)的出現(xiàn)問(wèn)題：如何開發(fā)軟件如何維護(hù)軟件表現(xiàn)：規(guī)模大、復(fù)雜度增加供需差增大價(jià)格昂貴開發(fā)速度慢質(zhì)量難以保證案例軟件危機(jī)解決途徑重視需求分析，明確與確切表達(dá)需求重視與客戶溝通與交流統(tǒng)一的、公認(rèn)的方法論和規(guī)范指導(dǎo)重視設(shè)計(jì)和實(shí)現(xiàn)過(guò)程的資料充分的檢測(cè)工作軟件工程概念軟件工程運(yùn)用現(xiàn)代科學(xué)技術(shù)知識(shí)來(lái)設(shè)計(jì)并構(gòu)造計(jì)算機(jī)程序及為開發(fā)、運(yùn)行和維護(hù)這些程序所必須的相關(guān)文件資料。軟件工程是為了經(jīng)濟(jì)地獲得能夠在實(shí)際機(jī)器上有效運(yùn)行的可靠軟件而建立和使用的一系列完善的工程化原則。軟件工程是開發(fā)、運(yùn)行、維護(hù)和修復(fù)軟件的系統(tǒng)方法。軟件工程三要素工程化思想把軟件看作是一個(gè)工程產(chǎn)品兩個(gè)方面：軟件開發(fā)技術(shù)軟件工程管理原因：缺乏軟件過(guò)程控制能力能力成熟模型（CapabilityMaturityModel）體現(xiàn):工程化管理軟件工程管理1.3軟件工程基本原理與原則基本原理推遲實(shí)現(xiàn)逐步求精分解與抽象信息隱蔽質(zhì)量保證基本原則分階段的軟件開發(fā)堅(jiān)持進(jìn)行階段評(píng)審實(shí)行嚴(yán)格的產(chǎn)品控制采用先進(jìn)的程序設(shè)計(jì)技術(shù)明確責(zé)任開發(fā)小組的人員應(yīng)少而精不斷改進(jìn)開發(fā)過(guò)程1.4軟件工程范型結(jié)構(gòu)化開發(fā)范型特征：結(jié)構(gòu)化技術(shù)要么面向行為，要么面向數(shù)據(jù)構(gòu)成結(jié)構(gòu)化開發(fā)范型的技術(shù)包括：結(jié)構(gòu)化分析（SA）結(jié)構(gòu)化設(shè)計(jì)（SD）結(jié)構(gòu)化編程（SP）結(jié)構(gòu)化測(cè)試（ST）結(jié)構(gòu)化維護(hù)（SM）1.4軟件工程范型面向?qū)ο蠓缎吞卣鳎簩?duì)象視作一個(gè)融合了數(shù)據(jù)及在其上操作的行為的、統(tǒng)一的軟件組件。技術(shù)包括：面向?qū)ο蠓治觯∣OA）面向?qū)ο笤O(shè)計(jì)（OOD）面向?qū)ο缶幊蹋∣OP）面向?qū)ο鬁y(cè)試（OOT）面向?qū)ο缶S護(hù)（OOM）優(yōu)勢(shì)：對(duì)象的概念符合業(yè)務(wù)或領(lǐng)域的客觀實(shí)際維護(hù)容易1.5軟件工程基本活動(dòng)溝通計(jì)劃建模實(shí)現(xiàn)部署維護(hù)管理過(guò)程改進(jìn)小結(jié)軟件工程的是主旨以工程化的思想進(jìn)行軟件開發(fā)，以生產(chǎn)高質(zhì)量和高效率的軟件。軟件工程化思想的核心是，把軟件看作是一個(gè)工程產(chǎn)品。軟件工程方法學(xué)分別是結(jié)構(gòu)化開發(fā)范型和面向?qū)ο箝_發(fā)范型。第2章軟件過(guò)程與模型內(nèi)容提要軟件生存周期軟件過(guò)程與框架軟件過(guò)程選擇與評(píng)估軟件能力成熟度模型軟件過(guò)程模型傳統(tǒng)的軟件過(guò)程模型面向?qū)ο筮^(guò)程模型2.1軟件生存周期軟件也有一個(gè)從生到死的過(guò)程，這個(gè)過(guò)程一般稱之為軟件的軟件生存周期或生命周期（SoftwareDevelopmentLifeCycle）軟件生存周期可劃分為定義、開發(fā)和運(yùn)行三個(gè)時(shí)期，每個(gè)時(shí)期又細(xì)分為若干個(gè)階段。把整個(gè)軟件生存周期劃分為若干階段，使得每個(gè)階段有明確的任務(wù)，使規(guī)模大，結(jié)構(gòu)復(fù)雜和管理復(fù)雜的軟件開發(fā)變的容易控制和管理。軟件生存周期包括問(wèn)題定義與可行性分析、軟件項(xiàng)目計(jì)劃、需求分析、軟件設(shè)計(jì)、實(shí)現(xiàn)與測(cè)試、運(yùn)行與維護(hù)等階段，每個(gè)階段有包含一系列的活動(dòng)。2.2軟件過(guò)程與框架定義：軟件過(guò)程是為了開發(fā)出軟件產(chǎn)品，或者是為了完成軟件工程項(xiàng)目而需要完成的有關(guān)軟件工程的活動(dòng)通常使用生存周期模型簡(jiǎn)潔地描述軟件過(guò)程層次：軟件工程是一門建立在以質(zhì)量焦點(diǎn)為基礎(chǔ)的層次化綜合技術(shù)過(guò)程:定義階段和管理方法:技術(shù)支持工具:自動(dòng)化實(shí)施支持軟件過(guò)程框架與管理定義：框架是實(shí)現(xiàn)整個(gè)軟件開發(fā)活動(dòng)的基礎(chǔ)，并且那些與過(guò)程有關(guān)的角色、職責(zé)的定義以及實(shí)現(xiàn)也都離不開框架的支持兩個(gè)方面的內(nèi)容組織及管理框架技術(shù)及工具框架軟件過(guò)程環(huán)境組織、管理的角色和職責(zé)技術(shù)環(huán)境軟件過(guò)程框架組織與管理框架：過(guò)程改進(jìn)活動(dòng)及角色與職責(zé)技術(shù)與工具框架：技術(shù)及自動(dòng)化活動(dòng)工具框架活動(dòng)：溝通策劃建模構(gòu)建部署軟件過(guò)程框架包括一組普適的過(guò)程、活動(dòng)和任務(wù)。具體包括：系統(tǒng)語(yǔ)境的過(guò)程協(xié)議過(guò)程組（2個(gè)過(guò)程，13個(gè)活動(dòng)，52個(gè)任務(wù)）項(xiàng)目過(guò)程組（7個(gè)過(guò)程，23個(gè)活動(dòng)，72個(gè)任務(wù)）技術(shù)過(guò)程組（11個(gè)過(guò)程，26個(gè)活動(dòng)，64個(gè)任務(wù)）組織上項(xiàng)目使能過(guò)程組（5個(gè)過(guò)程，15個(gè)活動(dòng)，48個(gè)任務(wù)）針對(duì)軟件開發(fā)的過(guò)程軟件實(shí)現(xiàn)過(guò)程組（7個(gè)過(guò)程，7個(gè)活動(dòng)，39個(gè)任務(wù)）軟件支持過(guò)程組（8個(gè)過(guò)程，25個(gè)活動(dòng)，68個(gè)任務(wù)）軟件復(fù)用過(guò)程組（3個(gè)過(guò)程，14個(gè)活動(dòng)，62個(gè)任務(wù)）整個(gè)系統(tǒng)的生存周期包括了43個(gè)過(guò)程、123個(gè)活動(dòng)和405項(xiàng)任務(wù)。2.3軟件過(guò)程選擇與評(píng)估軟件過(guò)程選擇把軟件看成產(chǎn)品，必然注重軟件的質(zhì)量，決定了軟件過(guò)程、周期和成本。產(chǎn)品依賴過(guò)程，其就是過(guò)程定義的一系列活動(dòng)和任務(wù)的結(jié)果。軟件產(chǎn)品越復(fù)雜，其開發(fā)周期也越長(zhǎng)，開發(fā)成本越高。當(dāng)軟件比較復(fù)雜，開發(fā)周期比較長(zhǎng)（一般持續(xù)一年及以上），開發(fā)成本比較高時(shí)，團(tuán)隊(duì)就要選擇重型軟件過(guò)程，比如螺旋模型或者統(tǒng)一過(guò)程模型等。當(dāng)軟件較為簡(jiǎn)單或需求比較穩(wěn)定時(shí)，一般開發(fā)周期也比較短（三個(gè)月以內(nèi)），開發(fā)人員也比較少（一般4-8人），這樣的軟件就可以采用輕型軟件過(guò)程，比如極限編程方法或者瀑布模型等。軟件過(guò)程評(píng)估產(chǎn)品與過(guò)程選擇軟件過(guò)程過(guò)程評(píng)估CMMI/CMMISO9001:2000個(gè)人軟件過(guò)程團(tuán)隊(duì)軟件過(guò)程個(gè)人軟件過(guò)程（PSP）PSP0是PSP的個(gè)人度量過(guò)程，其目的是建立個(gè)體過(guò)程基線。PSP1是個(gè)人規(guī)劃過(guò)程，引入了基于估計(jì)的計(jì)劃方法PROBE，用自己的歷史數(shù)據(jù)來(lái)預(yù)測(cè)新程序大小和開發(fā)時(shí)間，并使用線性回歸方法估計(jì)參數(shù)，確定置信區(qū)間以評(píng)價(jià)預(yù)測(cè)的可信程度。PSP2是個(gè)人質(zhì)量管理，根據(jù)程序的缺陷建立檢測(cè)表，按照檢測(cè)表進(jìn)行設(shè)計(jì)復(fù)查和代碼復(fù)查，以便及早發(fā)現(xiàn)缺陷，使修復(fù)缺陷的代價(jià)最小。PSP3的目標(biāo)是把個(gè)體開發(fā)小程序所能達(dá)到的生產(chǎn)效率和生產(chǎn)質(zhì)量，延伸到大型程序。團(tuán)隊(duì)軟件過(guò)程(TSP)TSP采用了循環(huán)遞增的開發(fā)策略，整個(gè)軟件生產(chǎn)過(guò)程由多個(gè)循環(huán)出現(xiàn)的開發(fā)周期組成，每個(gè)開發(fā)周期劃分出若干個(gè)相對(duì)獨(dú)立的階段。TSP提供了如下方法：計(jì)劃評(píng)審設(shè)計(jì)和編碼標(biāo)準(zhǔn)設(shè)計(jì)和代碼評(píng)審方法缺陷評(píng)審質(zhì)量分析2.4軟件能力成熟度模型CMM(CapabilityMaturityModel)是指“能力成熟度模型”CMM是由美國(guó)卡內(nèi)基－梅隆大學(xué)的軟件工程研究所（SEI）開發(fā)的軟件成熟度模型。思想：管理軟件過(guò)程的方法不當(dāng)引起的問(wèn)題，導(dǎo)致新軟件技術(shù)的運(yùn)用并不會(huì)自動(dòng)提高軟件的生產(chǎn)率和質(zhì)量。CMM為軟件企業(yè)的過(guò)程能力提供了一個(gè)階梯式的改進(jìn)框架，它基于過(guò)去所有軟件工程過(guò)程改進(jìn)的成果，吸取了以往軟件工程的經(jīng)驗(yàn)教訓(xùn)，提供了一個(gè)基于過(guò)程改進(jìn)的框架。能力成熟度模型集成（CMMI--CapabilityMaturityModelIntegration）是CMM模型的最新版本。什么是CMM？為企業(yè)的發(fā)展規(guī)定過(guò)程成熟級(jí)別，分為5級(jí)（Version1.0）：初始級(jí)（Initial）：一般企業(yè)皆具有可重復(fù)級(jí)（Repeatable）：成功經(jīng)驗(yàn)可以重復(fù)定義級(jí)（Defined）：一套完整的企業(yè)過(guò)程，人員自覺(jué)遵守（培訓(xùn)）管理級(jí)（Managed）：過(guò)程&產(chǎn)品可度量和控制優(yōu)化級(jí)（Optimizing）：過(guò)程持續(xù)改進(jìn)從無(wú)序到有序、從特殊到一般、從定性管理到定量管理、最終達(dá)到動(dòng)態(tài)優(yōu)化CMM基本內(nèi)容2.Repeatable1.Initial3.Defined4.ManagedDisciplinedProcessStandard,ConsistentProcessPredictableProcessContinuouslyImprovingProcessUnpredictableandpoorlycontrolledCanrepeatpreviouslymasteredtasksProcesscharacterized,fairlywellunderstoodProcessmeasuredandcontrolledFocusonprocessimprovement5.OptimizingProjectManagementIntegratedEngineeringProcessProductandProcessQualityManagingChangeDisorder

Disciplined

Predictable

Immature

Mature

CMM基本內(nèi)容關(guān)鍵過(guò)程域KPA：代表一組相關(guān)的工作（活動(dòng)）。每個(gè)KPA都有一個(gè)確定的目標(biāo)，完成該目標(biāo)即認(rèn)為過(guò)程能力的提高。一般特性CF（CommonFeatures）：進(jìn)一步細(xì)分KPA的工作。五個(gè)特性：承諾（commitment）準(zhǔn)備（ability）執(zhí)行（activity）度量分析（measurement&analysis）驗(yàn)證（verifyingimplementation）CMM的五個(gè)級(jí)別Level1：初始級(jí)過(guò)程無(wú)序且不可見OutInCMM的五個(gè)級(jí)別Level2：可重復(fù)級(jí)Milestone可見，按計(jì)劃開發(fā)CMM的五個(gè)級(jí)別Level2的6個(gè)KPA：側(cè)重于管理需求管理（RequirementsManagement）軟件項(xiàng)目計(jì)劃（SoftwareProjectPlanning）軟件項(xiàng)目的跟蹤和監(jiān)控（SoftwareProjectTackingandOversight）軟件子合同管理（SoftwareSubcontractManagement）軟件質(zhì)量保證（SoftwareQualityAssurance）軟件配置管理（SoftwareConfigurationManagement）CMM的五個(gè)級(jí)別Level3：定義級(jí)每個(gè)階段的內(nèi)部活動(dòng)可見標(biāo)準(zhǔn)過(guò)程和項(xiàng)目定義過(guò)程裁剪CMM的五個(gè)級(jí)別Level3的7個(gè)KPA：工程過(guò)程＋企業(yè)理念機(jī)構(gòu)過(guò)程關(guān)注（OrganizationProcessFocus）機(jī)構(gòu)過(guò)程定義（OrganizationProcessDefinition）培訓(xùn)計(jì)劃（TrainingProgram）集成軟件管理（IntegratedSoftwareManagement）－過(guò)程裁剪和定義軟件產(chǎn)品工程（SoftwareProductEngineering）－過(guò)程執(zhí)行組間協(xié)調(diào)（IntergroupCoordination）對(duì)等審查（PeerReviews）CMM的五個(gè)級(jí)別Level4管理級(jí)過(guò)程可度量，預(yù)測(cè)值與結(jié)果之間的偏差可控CMM的五個(gè)級(jí)別Level4的2個(gè)KPA：預(yù)測(cè)＋量化管理定量過(guò)程管理（QuantitativeProcessManagement）－過(guò)程度量軟件質(zhì)量管理（SoftwareQualityManagement）－產(chǎn)品度量CMM的五個(gè)級(jí)別Level5優(yōu)化級(jí)過(guò)程動(dòng)態(tài)調(diào)整、新技術(shù)的采用CMM的五個(gè)級(jí)別Level5的3個(gè)KPA：動(dòng)態(tài)優(yōu)化缺陷預(yù)防（DefectPrevention）技術(shù)改變管理（TechnologyChangeManagement）過(guò)程改變管理（ProcessChangeManagement）能力成熟度模型集成CMMI--CapabilityMaturityModelIntegration是CMM模型的最新版本。CMMI有兩種表示方法：和軟件CMM一樣的階段式表現(xiàn)方法連續(xù)式的表現(xiàn)方法過(guò)程管理項(xiàng)目管理工程支持CMMI的目標(biāo)是質(zhì)量、時(shí)間表和最低的成本關(guān)鍵實(shí)踐CMM結(jié)構(gòu)CMM標(biāo)準(zhǔn)的使用軟件過(guò)程的改進(jìn)(SPI，SoftwareProcessImprovement)軟件過(guò)程評(píng)估(SPA，SoftwareProcessAssessment)軟件能力評(píng)價(jià)(SCESoftwareCapabilityEvaluation)2.5軟件過(guò)程模型把軟件生命周期中各項(xiàng)開發(fā)活動(dòng)的流程用一個(gè)合理的框架—開發(fā)模型來(lái)規(guī)范描述，這就是軟件過(guò)程模型,也稱為軟件生命周期模型.軟件過(guò)程模型是一種就是軟件過(guò)程抽象.軟件過(guò)程模型是從一個(gè)特定的角度表現(xiàn)一個(gè)過(guò)程，一般使用直觀的圖形標(biāo)識(shí)軟件開發(fā)的過(guò)程，主要根據(jù)軟件的類型、規(guī)模，特別是軟件的開發(fā)方法、開發(fā)環(huán)境等多種因素確立過(guò)程模型。2.6傳統(tǒng)的軟件過(guò)程模型瀑布模型增量模型螺旋模型瀑布模型瀑布模型將軟件生命周期劃分為軟件計(jì)劃、需求分析和定義、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試、運(yùn)行和維護(hù)這6個(gè)階段，規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水逐級(jí)下落。從本質(zhì)來(lái)講，它是一個(gè)軟件開發(fā)架構(gòu)，開發(fā)過(guò)程是通過(guò)一系列階段順序展開的，從系統(tǒng)需求分析開始直到產(chǎn)品發(fā)布和維護(hù)，每個(gè)階段都會(huì)產(chǎn)生循環(huán)反饋.瀑布模型示意圖瀑布模型它是一個(gè)軟件開發(fā)架構(gòu)，開發(fā)過(guò)程是通過(guò)一系列階段順序展開的。每個(gè)階段都會(huì)產(chǎn)生循環(huán)反饋各個(gè)階段產(chǎn)生的文檔是維護(hù)軟件產(chǎn)品時(shí)必不可少的，沒(méi)有文檔的軟件幾乎是不可能維護(hù)的。瀑布模型是一種文檔驅(qū)動(dòng)的過(guò)程模型瀑布模型特點(diǎn)順序性和依賴性推遲實(shí)現(xiàn)質(zhì)量保證的觀點(diǎn)是一種線性模型強(qiáng)調(diào)文檔的作用增量模型增量模型（IncrementalModel）也稱為漸增模型，是在項(xiàng)目的開發(fā)過(guò)程中以一系列的增量方式開發(fā)系統(tǒng)。軟件被作為一系列的增量構(gòu)件來(lái)設(shè)計(jì)、實(shí)現(xiàn)、集成和測(cè)試，每一個(gè)構(gòu)件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構(gòu)成.增量方式包括：增量開發(fā)：以一定的時(shí)間間隔開發(fā)部分工作軟件增量提交：以一定的時(shí)間間隔增量方式向用戶提交工作軟件及相應(yīng)文檔增量模型融合了線性順序模型的基本成份和原型實(shí)現(xiàn)模型的迭代特征。增量模型分為漸增模型和原型模型漸增模型是瀑布模型的變種，有兩類漸增模型：增量構(gòu)造模型：它在瀑布模型基礎(chǔ)上，對(duì)一些階段進(jìn)行整體開發(fā)，對(duì)另一些階段進(jìn)行增量開發(fā)。前面的開發(fā)階段按瀑布模型進(jìn)行整體開發(fā)，后面的開發(fā)階段按增量提交。演化提交模型：它在瀑布模型的基礎(chǔ)上，所有階段都進(jìn)行增量開發(fā)，也就是說(shuō)不僅是增量開發(fā)，也是增量提交。增量構(gòu)造模型需求分析設(shè)計(jì)編碼1測(cè)試1測(cè)試2編碼2編碼3測(cè)試3螺旋模型螺旋模型（SpiralModel）是結(jié)合了瀑布模型和快速原型模型的迭代開發(fā)模型強(qiáng)調(diào)了其他模型均忽略了的風(fēng)險(xiǎn)分析：風(fēng)險(xiǎn)識(shí)別風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)控制特別適合于大型復(fù)雜的系統(tǒng)每一個(gè)周期都包括需求定義、風(fēng)險(xiǎn)分析、工程實(shí)現(xiàn)和評(píng)審螺旋模型示意圖螺旋模型活動(dòng)四個(gè)象限分別代表了以下活動(dòng)：制定計(jì)劃：確定軟件目標(biāo)，選定實(shí)施方案，確定項(xiàng)目開發(fā)的限制條件；風(fēng)險(xiǎn)分析：分析評(píng)估所選方案，考慮如何識(shí)別和消除風(fēng)險(xiǎn)；實(shí)施工程：實(shí)施軟件開發(fā)和驗(yàn)證；客戶評(píng)估：評(píng)價(jià)開發(fā)工作，提出修正建議，制定下一步計(jì)劃。螺旋模型是風(fēng)險(xiǎn)驅(qū)動(dòng)的模型2.7面向?qū)ο筮^(guò)程模型面向?qū)ο笫且环N的程序設(shè)計(jì)方法，或者說(shuō)它是一種程序設(shè)計(jì)范型。基本思想是使用對(duì)象，類，繼承，封裝，消息等基本概念來(lái)進(jìn)行程序設(shè)計(jì)。面向?qū)ο蟮囊兀撼橄螅簭?qiáng)調(diào)實(shí)體的本質(zhì)、內(nèi)在的屬性，忽略一些無(wú)關(guān)緊要的屬性。類實(shí)現(xiàn)了對(duì)象的數(shù)據(jù)（即狀態(tài)）和行為的抽象，是對(duì)象的共性的抽象。封裝性：指所有軟件部件內(nèi)部都有明確的范圍以及清楚的外部邊界。共享性：面向?qū)ο蟮奶卣鳎簩?duì)象惟一性；分類性；繼承性；多態(tài)性（多形性）。構(gòu)件集成模型構(gòu)件集成模型是基于構(gòu)件的開發(fā)模型構(gòu)件集成模型：整個(gè)系統(tǒng)模塊化復(fù)用構(gòu)件庫(kù)中的軟件構(gòu)件構(gòu)件集成模型是演化形的，開發(fā)過(guò)程是迭代的5個(gè)階段：軟件的需求分析和定義體系結(jié)構(gòu)設(shè)計(jì)構(gòu)件庫(kù)建立應(yīng)用軟件構(gòu)建測(cè)試和發(fā)布構(gòu)件集成模型需求分析和定義體系結(jié)構(gòu)設(shè)計(jì)構(gòu)件庫(kù)建立測(cè)試和發(fā)布應(yīng)用軟件構(gòu)建1：N統(tǒng)一過(guò)程Asoftwaredevelopmentprocess：是一個(gè)將用戶需求轉(zhuǎn)化為軟件系統(tǒng)所需要的活動(dòng)的集合。Aprocessframework：一個(gè)簡(jiǎn)單的過(guò)程，也是一個(gè)通用的過(guò)程框架。Component-based：軟件構(gòu)件+接口Thestandard--employingtheUML（UnifiedModelingLanguage）use-casedrivenarchitecture-centriciterativeandincremental發(fā)展過(guò)程1967:apredecessorofObjectory1976-80:formalization&generalization1997:Objectory4.11987-95:Objectory1.0-3.8SDLAbook:TheUnifiedProcessAproduct:TheRationalUnifiedProcess1998:UnifiedProcessOMTBoochRational’sbestpractices:KruchtenRoyceandmanyothersTheNextIndustryStandardASoftwareDevelopmentProcessSoftwaredevelopmentistheprocessofdevelopingsoftwarefromrequirements.NeworchangedrequirementsNeworchangedsystemSoftwareDevelopmentProcess統(tǒng)一過(guò)程是用況驅(qū)動(dòng)的用況模型(usecasemodel)要素:用戶（user）用況（usecase）動(dòng)作（action）用況驅(qū)動(dòng)（use-casedriven）：用況可以驅(qū)動(dòng)開發(fā)過(guò)程：用況不只是確定系統(tǒng)需求的工具，還能驅(qū)動(dòng)系統(tǒng)設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試的進(jìn)行。不能孤立地選擇用況統(tǒng)一過(guò)程是以構(gòu)架為中心的軟件構(gòu)架包含了系統(tǒng)中最重要的靜態(tài)和動(dòng)態(tài)特征構(gòu)架刻畫了系統(tǒng)的整體設(shè)計(jì)，突出系統(tǒng)的重要特征構(gòu)架的價(jià)值依賴于執(zhí)行該任務(wù)的人的素質(zhì)過(guò)程可以幫助構(gòu)架設(shè)計(jì)師確定正確的目標(biāo)用況和構(gòu)架的關(guān)系：用況對(duì)應(yīng)功能構(gòu)架對(duì)應(yīng)表現(xiàn)形式用況和構(gòu)架相互影響，并必須進(jìn)化統(tǒng)一過(guò)程是以構(gòu)架為中心的構(gòu)架設(shè)計(jì)師應(yīng)遵循的四個(gè)步驟：針對(duì)通用用況，創(chuàng)建一個(gè)粗略的構(gòu)架輪廓處理已經(jīng)確定的重要用況子集用況完善繼續(xù)上述過(guò)程…統(tǒng)一過(guò)程是迭代和增量的劃分為袖珍項(xiàng)目（mini-project）:一個(gè)增量的迭代過(guò)程迭代是指工作流中的步驟,迭代過(guò)程必須是受控的目標(biāo)：處理一組過(guò)程,風(fēng)險(xiǎn)分析做法：標(biāo)識(shí)與描述用況選定構(gòu)架創(chuàng)建設(shè)計(jì)選擇構(gòu)件實(shí)現(xiàn)設(shè)計(jì)驗(yàn)證PhasesintheSoftwareLifecycleTheUnifiedProcesshasfourphases:Inception—DefiningthescopeoftheprojectElaboration—Planning,specifyingfeaturesanddesigningarchitectureConstruction—BuildingtheproductTransition—TransitioningtheproductintoitsusercommunitytimeInceptionElaborationConstructionTransitionMajormilestones統(tǒng)一過(guò)程模型統(tǒng)一過(guò)程（UnifiedProcess，UP)是風(fēng)險(xiǎn)驅(qū)動(dòng)的、基于用況技術(shù)的、以架構(gòu)為中心的、迭代的、可配置的軟件開發(fā)流程。統(tǒng)一過(guò)程是以用況驅(qū)動(dòng)的，以構(gòu)架為中心，迭代和增量的過(guò)程。統(tǒng)一過(guò)程是一個(gè)軟件開發(fā)過(guò)程，是一個(gè)通用的過(guò)程框架：初始細(xì)化構(gòu)造移交統(tǒng)一過(guò)程的四個(gè)階段統(tǒng)一過(guò)程五個(gè)核心工作流需求捕獲(RequirementsCapture)：致力于開發(fā)正確的系統(tǒng)分析(Analysis)：更精確地理解需求設(shè)計(jì)(Design)：深入理解與非功能性需求和約束相聯(lián)系的問(wèn)題實(shí)現(xiàn)(Implementation)：實(shí)現(xiàn)系統(tǒng)與集成測(cè)試(Test)：驗(yàn)證實(shí)現(xiàn)的結(jié)構(gòu)核心工作流軟件開發(fā)的四個(gè)要素人員項(xiàng)目產(chǎn)品過(guò)程人員至關(guān)重要開發(fā)過(guò)程影響人員角色會(huì)發(fā)生變化角色實(shí)例項(xiàng)目創(chuàng)造產(chǎn)品三要素：一系列變化一系列迭代組織模式產(chǎn)品不僅僅是代碼軟件系統(tǒng)制品系統(tǒng)包含一組模型什么是模型？視圖模型內(nèi)部模型間的關(guān)系過(guò)程指導(dǎo)項(xiàng)目過(guò)程：一個(gè)模板過(guò)程過(guò)程實(shí)例軟件開發(fā)過(guò)程工作流過(guò)程具體化過(guò)程的價(jià)值工具用況驅(qū)動(dòng)開發(fā)統(tǒng)一過(guò)程的目標(biāo)：指導(dǎo)開發(fā)人員有效地實(shí)現(xiàn)并實(shí)施滿足客戶需求的系統(tǒng)。效率：成本、質(zhì)量、交付時(shí)間用況驅(qū)動(dòng)開發(fā)RequirementsAnalysis&DesignImplementationTestUseCasesbindtheseworkflowstogether模型用況模型分析模型設(shè)計(jì)模型實(shí)現(xiàn)模型實(shí)施模型測(cè)試模型小結(jié)大多數(shù)軟件開發(fā)過(guò)程都有一個(gè)共同的軟件過(guò)程框架軟件開發(fā)模型是指軟件開發(fā)全部過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架，表達(dá)軟件開發(fā)全過(guò)程，規(guī)定了要完成的主要活動(dòng)和任務(wù)，用來(lái)作為軟件項(xiàng)目工作的基礎(chǔ)。軟件過(guò)程分為個(gè)人軟件過(guò)程PSP和團(tuán)隊(duì)軟件過(guò)程TSP。CMM為軟件企業(yè)的過(guò)程能力提供了一個(gè)階梯式的改進(jìn)框架，包括初始級(jí)、可重復(fù)級(jí)、已定義級(jí)、可管理級(jí)和優(yōu)化級(jí)5個(gè)級(jí)別。軟件過(guò)程模型的選擇取決于軟件的特性和開發(fā)團(tuán)隊(duì)的特性。對(duì)于開發(fā)大型復(fù)雜的軟件，建議采用重型軟件過(guò)程模型，如螺旋模型、統(tǒng)一過(guò)程模型等；對(duì)于需求穩(wěn)定或簡(jiǎn)單的軟件，建議采用輕型軟件過(guò)程模型，如極限編程、瀑布模型等。第3章敏捷軟件工程方法內(nèi)容提要：敏捷軟件工程過(guò)程SCRUM軟件開發(fā)過(guò)程極限編程結(jié)對(duì)編程3.1敏捷軟件工程過(guò)程敏捷不是一個(gè)過(guò)程，是一類過(guò)程的統(tǒng)稱。敏捷方法的兩大主要特征：對(duì)“適應(yīng)性”的強(qiáng)調(diào)對(duì)“人”的關(guān)注做法：快速響應(yīng):引入迭代式的開發(fā)手段將整個(gè)軟件生命周期分解為若干個(gè)小的迭代周期獲取切實(shí)有效的客戶反饋提出12條基本原則敏捷開發(fā)12條原則我們最優(yōu)先要做的是通過(guò)盡早的、持續(xù)的交付有價(jià)值的軟件來(lái)使客戶滿意。即使到了開發(fā)的后期，也歡迎改變需求。敏捷過(guò)程利用變化來(lái)為客戶創(chuàng)造競(jìng)爭(zhēng)優(yōu)勢(shì)。

經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個(gè)星期到幾個(gè)月，交付的時(shí)間間隔越短越好。在整個(gè)項(xiàng)目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。圍繞被激勵(lì)起來(lái)的個(gè)體來(lái)構(gòu)建項(xiàng)目，給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。敏捷開發(fā)12條原則(續(xù))在團(tuán)隊(duì)內(nèi)部，最具有效果并富有效率的傳遞信息的方法，就是面對(duì)面的交談。工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)。敏捷過(guò)程提倡可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個(gè)長(zhǎng)期的、恒定的開發(fā)速度。不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會(huì)增強(qiáng)敏捷能力。

簡(jiǎn)單是最根本的。

最好的構(gòu)架、需求和設(shè)計(jì)出于自組織團(tuán)隊(duì)。

每隔一定時(shí)間，團(tuán)隊(duì)會(huì)在如何才能更有效地工作方面進(jìn)行反省，然后相應(yīng)地對(duì)自己的行為進(jìn)行調(diào)整。3.2SCRUM軟件開發(fā)過(guò)程Scrum是一種迭代式增量軟件開發(fā)過(guò)程，適合于敏捷軟件開發(fā)。Scrum的基本假設(shè)：開發(fā)軟件就像開發(fā)新產(chǎn)品，無(wú)法一開始就能定義軟件產(chǎn)品最終的方案，過(guò)程中需要研發(fā)、創(chuàng)意、嘗試錯(cuò)誤，所以沒(méi)有一種固定的流程可以保證方案成功。Scrum有明確的最高目標(biāo)，熟悉開發(fā)流程中所需具備的最佳典范與技術(shù)，具有高度自主權(quán)，緊密地溝通合作，以高度彈性解決各種挑戰(zhàn)，確保每天、每個(gè)階段都朝向目標(biāo)有明確的推進(jìn)。Scrum角色主管產(chǎn)品負(fù)責(zé)人開發(fā)團(tuán)隊(duì)Scrum術(shù)語(yǔ)訂單backlog:可以預(yù)知的所有任務(wù)，包括功能性的和非功能性的所有任務(wù)。沖刺sprint:一次跌代開發(fā)的時(shí)間周期。沖刺訂單sprintbacklog:一個(gè)sprint周期內(nèi)所需要完成的任務(wù)。主管scrumMaster:負(fù)責(zé)監(jiān)督整個(gè)Scrum進(jìn)程，修訂計(jì)劃的一個(gè)團(tuán)隊(duì)成員。時(shí)間盒time-box:一個(gè)用于開會(huì)時(shí)間段。沖刺計(jì)劃會(huì)sprintplanning會(huì)議每日立會(huì)DailyScrum會(huì)議沖刺評(píng)審會(huì)Sprintreview會(huì)議沖刺反思會(huì)Sprintretrospective會(huì)議實(shí)施Scrum的過(guò)程分解產(chǎn)品訂單成沖刺訂單召開沖刺計(jì)劃會(huì)議進(jìn)入沖刺開發(fā)周期，每天需要召開立會(huì)整個(gè)沖刺周期結(jié)束，召開沖刺評(píng)審會(huì)團(tuán)隊(duì)召開沖刺反思會(huì)。。。以上循環(huán)進(jìn)行Scrum文檔產(chǎn)品訂單文檔沖刺訂單文檔燃盡圖3.3極限編程極限編程（eXtremeProgramming，XP）是一種軟件工程方法學(xué)，是敏捷開發(fā)中最富有成效的方法學(xué)之一由KentBeck在1996年提出具有強(qiáng)溝通、簡(jiǎn)化設(shè)計(jì)、迅速反饋等特點(diǎn)適合于規(guī)模小、進(jìn)度緊、需求不穩(wěn)定、開發(fā)小項(xiàng)目的小團(tuán)隊(duì)。極限編程特點(diǎn)：XP模型是“輕量型”或“靈活”的軟件過(guò)程模型與面向?qū)ο笳Z(yǔ)言結(jié)合的開發(fā)方案“專家協(xié)作”的開發(fā)方式，解決難點(diǎn)問(wèn)題重視客戶反饋核心有四個(gè)要點(diǎn)：交流簡(jiǎn)單反饋勇氣交流開發(fā)人員與客戶的交流開發(fā)人員之間的交流使用結(jié)對(duì)編程開發(fā)人員與管理人員的交流簡(jiǎn)單設(shè)計(jì)的簡(jiǎn)單編碼的簡(jiǎn)單注釋的簡(jiǎn)單測(cè)試的簡(jiǎn)單反饋客戶對(duì)軟件的反饋測(cè)試代碼對(duì)功能代碼的反饋先測(cè)試，后編程勇氣接受任務(wù)的勇氣XP常見問(wèn)題XP適合于小型項(xiàng)目（10人左右）?結(jié)對(duì)編程，搭檔如何安排?實(shí)施結(jié)對(duì)編程、集體代碼所有權(quán)之后，如何考核單個(gè)開發(fā)人員？

993.4結(jié)對(duì)編程

(PairProgramming

)什么是結(jié)對(duì)編程結(jié)對(duì)編程(Pair-Programming)是XP中非常重要的實(shí)踐之一。定義：兩個(gè)人坐在同一臺(tái)計(jì)算機(jī)前面，使用相同的鍵盤和鼠標(biāo)來(lái)開發(fā)同樣的一個(gè)模塊，一個(gè)稱為駕駛者(Driver)，負(fù)責(zé)代碼的鍵入，另外一個(gè)稱為領(lǐng)航員(Navigator)，負(fù)責(zé)監(jiān)看與決策，包括低級(jí)錯(cuò)誤和方向性的錯(cuò)誤。當(dāng)出現(xiàn)的一個(gè)問(wèn)題對(duì)其中一個(gè)人來(lái)說(shuō)，難以解決，而恰好是另外一個(gè)人的強(qiáng)項(xiàng)的時(shí)候，那么角色就會(huì)發(fā)生轉(zhuǎn)換。PairProgramming的角色(Role)DriverTheonewhotypesNavigatorTheonewhowatchestheback角色可以互換的疑問(wèn)：一個(gè)程序兩個(gè)人寫是不是一種浪費(fèi)（可是兩份工資，雙倍資源哦）？編程從來(lái)是一個(gè)人的活動(dòng)。學(xué)校里這么教的，一直以來(lái)也是做么做的。我不喜歡被人盯著工作，這樣我不自在，無(wú)法工作。這個(gè)笨家伙老是問(wèn)問(wèn)題，他/她不會(huì)看書么？我都無(wú)法專心工作了。

……另一方面：

PairProgramming被很多的大師級(jí)程序員推崇；不少大學(xué)都展開對(duì)PairProgramming的研究，并得到正面的結(jié)論；很多嘗試過(guò)的Developer都開始喜歡PairProgramming。PairProgramming的疑問(wèn)PairProgramming和SoloProgramming的比較一些研究數(shù)據(jù)：

1999年，UniversityofUath.兩組學(xué)生，一組獨(dú)自工作，一組PairProgramming。不間斷的CodeReview1.PeerCodeReview，即程序員之間的互相Review缺乏DesignReview不能持久,定時(shí)CodeReview對(duì)需求和設(shè)計(jì)的不了解導(dǎo)致無(wú)法實(shí)現(xiàn)有效的Review2.TeamCodeReview什么時(shí)候開會(huì)做Review？不可能Team天天開會(huì)無(wú)法對(duì)所有的設(shè)計(jì)和Code進(jìn)行Review面子問(wèn)題效率低傳統(tǒng)開發(fā)過(guò)程的Review（例如印度的InfoSys公司）的問(wèn)題：不間斷的CodeReview

提供不間斷的Designreview，UnitTestReview，CodeReview，DocumentReview，避免了效果差的TeamCodeReview，也比抽查式的PeerCodeReview有更好的質(zhì)量。 PairProgramming中，任何一段代碼都至少被兩雙眼睛看過(guò)，兩個(gè)腦袋思考過(guò)。代碼被不斷的Review。

編程方式避免cowboy式的編程好代碼的衡量標(biāo)準(zhǔn)：可讀性和可維護(hù)性對(duì)大部分的商業(yè)項(xiàng)目來(lái)說(shuō)，更主要的顧慮是成本。好的代碼可以減少修改的成本?；ハ喽酱倏梢蕴岣叽a的可讀性。

以人為本同伴的潛在壓力(PeerPressure)。PairProgramming的過(guò)程也是一個(gè)互相督促的過(guò)程。由于這種督促的壓力，使得程序員更認(rèn)真的工作。每個(gè)人每天的有效工作時(shí)段不超過(guò)3-4個(gè)小時(shí)。PairProgramming中Driver和Navigator的互換可以讓程序員輪流工作，從而避免出現(xiàn)過(guò)度思考而導(dǎo)致觀察力和判斷力出現(xiàn)偏差。潛意識(shí)的有利競(jìng)爭(zhēng)。當(dāng)人在一個(gè)團(tuán)隊(duì)中工作，總是下意識(shí)的努力展現(xiàn)自己的優(yōu)點(diǎn)。工作及時(shí)得到同伴的肯定，自信心和成就感(Self-Satisfaction)增強(qiáng)。覺(jué)得工作是一件愉快(Enjoyable)的事情。結(jié)對(duì)建議ExtremeProgramming對(duì)實(shí)施的程序員提出了更高的要求。這種要求不是技術(shù)水平，也不是學(xué)歷水平也不是工作經(jīng)驗(yàn)。這種要求是對(duì)一個(gè)人的心智，道德，修養(yǎng)的更高要求。程序員的四怕：

1)怕自己看上去傻

2)怕被認(rèn)為是沒(méi)用的

3)怕自己變的不重要（過(guò)時(shí)）

4)怕自己不夠好PairProgramming中，編碼不再是私人的工作，而是一種公開的“表演”。程序員的代碼，工作方式，技術(shù)水平都變得公開和透明。開發(fā)人員素質(zhì)

一個(gè)XP開發(fā)人員具備這樣一些基本素質(zhì)：誠(chéng)實(shí)，公正，開明，勇敢和謙卑！在這些素質(zhì)的基礎(chǔ)之上，才是對(duì)技術(shù)水平，能力和天分等的要求。誠(chéng)實(shí)

公正開明勇氣

謙卑具備這些素質(zhì)才能克服“四怕”，才能成為一個(gè)成熟和專業(yè)的Developer。如何結(jié)對(duì)編程Driver–寫設(shè)計(jì)文檔(Classdiagram等)，進(jìn)行編碼(UnitTestandBusinessObject)等XP開發(fā)流程。Navigator–審閱Driver的文檔、Driver對(duì)編碼等開發(fā)流程的執(zhí)行；考慮UnitTest的覆蓋程度；是否需要和如何Refactoring；幫助Driver解決具體的技術(shù)問(wèn)題。Driver和Navigator不斷輪換角色，不要連續(xù)工作超過(guò)一小時(shí)，每一小時(shí)休息15分鐘。Navigator要控制開發(fā)時(shí)間。

111沒(méi)有結(jié)對(duì)編程就沒(méi)有XPPairProgramming是XP所有的Practices中最被爭(zhēng)議和被認(rèn)為是最難接受。PairProgramming是獲得XP最大價(jià)值的關(guān)鍵。沒(méi)有PairProgramming,無(wú)法實(shí)現(xiàn)有效的ContinuousCodeReview,代碼質(zhì)量下降。沒(méi)有PeerPressure，流程的執(zhí)行很容易出現(xiàn)偏差。沒(méi)有PairProgramming，Communication很容易弱化，進(jìn)而影響Teamwork。PairProgramming象XP流程中的粘合劑，把各個(gè)環(huán)節(jié)連接起來(lái)實(shí)現(xiàn)最大的價(jià)值。

112沒(méi)有結(jié)對(duì)編程就沒(méi)有XP這是引進(jìn)XP時(shí)最難被接受的規(guī)則。但如果在采用其它XP的慣例和規(guī)則時(shí)，拋棄PairProgramming，那么會(huì)面對(duì)以下問(wèn)題：如何進(jìn)行有效的DesignReview如何進(jìn)行有效的CodeReview如何保證代碼質(zhì)量如何保證流程的執(zhí)行如何增進(jìn)Communication如何進(jìn)行Cross-Training如何增強(qiáng)TeamworkDistributedPairProgramming分布式的PairProgramming:兩個(gè)Programmers身處不同的物理位置，通過(guò)Sharing軟件來(lái)實(shí)現(xiàn)PairProgramming。需要Sharing軟件能提供桌面共享，文字交談，語(yǔ)音交談，甚至是視頻交流。目前這種方法還沒(méi)有被認(rèn)可，主要出現(xiàn)在學(xué)校的關(guān)于XP的研究項(xiàng)目中.面臨的問(wèn)題：Internet的網(wǎng)路延遲工作時(shí)段的約定PairProgramming和SoloProgramming的比較比較研究項(xiàng)目后的問(wèn)卷調(diào)查發(fā)現(xiàn)：PairProgramming能用較少的時(shí)間生產(chǎn)更高質(zhì)量的代碼。PairProgramming的學(xué)生們認(rèn)為自己比一個(gè)人的時(shí)候更勤奮和更聰明的工作，因?yàn)椴幌胱屪约旱膒artner失望。PairProgramming的學(xué)生認(rèn)為自己比一個(gè)人的時(shí)候更專著,緊湊和由紀(jì)律的工作，而且是持續(xù)的（因?yàn)閬?lái)自Partner的Pair-Pressure）。而獨(dú)立工作的學(xué)生也可以專著和緊湊的工作，但往往不持續(xù)。PairProgramming的學(xué)生對(duì)自己的工作更有信心和成就感。PairProgramming的學(xué)生覺(jué)得工作很愉快，很愿意很partner一起工作。在緊張時(shí)間安排和繁重的工作壓力下，獨(dú)自工作的學(xué)生很容易蛻變?yōu)闆](méi)有紀(jì)律的Programmer。PairProgramming是個(gè)漸進(jìn)的過(guò)程有效率的PairProgramming不是一天就能做到的。PairProgramming是一個(gè)相互學(xué)習(xí)，相互磨合的一個(gè)漸進(jìn)過(guò)程。Developers需要時(shí)間來(lái)適應(yīng)這種新的開發(fā)模式。剛開始的PairProgramming很可能不比SoloProgramming有更高的效率。但適應(yīng)后的Pairs的開發(fā)質(zhì)量和開發(fā)時(shí)間都比SoloProgramming有大幅度的改善。結(jié)對(duì)編程優(yōu)勢(shì)：可以減少風(fēng)險(xiǎn)可以使團(tuán)隊(duì)生產(chǎn)效率更高是知識(shí)傳播的最好途徑可以打造出最佳的合作團(tuán)隊(duì)?？梢陨筛玫拇a三個(gè)方面的應(yīng)用：教育學(xué)結(jié)對(duì)學(xué)習(xí)工業(yè)界結(jié)對(duì)開發(fā)與編程分布式結(jié)對(duì)編程環(huán)境結(jié)對(duì)編程與測(cè)試驅(qū)動(dòng)開發(fā)測(cè)試驅(qū)動(dòng)開發(fā)（TestDrivenDevelopment,TDD）思想：開發(fā)之前首先完成測(cè)試用例編寫；然后編寫代碼和測(cè)試；測(cè)試通過(guò)后即需增加新功能。優(yōu)勢(shì)：測(cè)試優(yōu)先，保證質(zhì)量結(jié)合結(jié)對(duì)編程結(jié)對(duì)編程與代碼重構(gòu)重構(gòu)就是代碼的重新設(shè)計(jì)。目的：得到好的代碼和架構(gòu)，易修改、易理解適應(yīng)需求結(jié)對(duì)編程：審查代碼理解代碼反饋結(jié)對(duì)編程與簡(jiǎn)單設(shè)計(jì)簡(jiǎn)單設(shè)計(jì)：達(dá)到目前需求即可結(jié)對(duì)編程可以達(dá)到簡(jiǎn)單結(jié)對(duì)編程方法面對(duì)面結(jié)對(duì)編程分布式結(jié)對(duì)編程小結(jié)軟件工程是一種層次化技術(shù)，包括過(guò)程、技術(shù)和工具。軟件過(guò)程是為了獲得高質(zhì)量軟件所需要完成的一系列任務(wù)的框架，它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。軟件過(guò)程框架定義了若干個(gè)小的框架活動(dòng)，為完整的軟件開發(fā)過(guò)程建立了基礎(chǔ)。軟件過(guò)程框架的通用過(guò)程框架活動(dòng)包括溝通、計(jì)劃、建模、構(gòu)建和部署。敏捷方法是一組敏捷實(shí)踐技術(shù)的總稱，包括極限編程、Scrum方法、結(jié)對(duì)編程等等。第4章

需求獲取內(nèi)容提要關(guān)于用戶需求和軟件需求需求獲取過(guò)程基于會(huì)談的需求獲取方法基于調(diào)查的需求獲取方法基于場(chǎng)景的需求獲取方法基于用例的需求獲取方法4.1關(guān)于用戶需求和軟件需求用戶需求：業(yè)務(wù)需求與源于系統(tǒng)的特定領(lǐng)域的需求用戶需求是站在用戶角度描述軟件必須要完成的業(yè)務(wù)需求，通過(guò)使用實(shí)例文檔或場(chǎng)景說(shuō)明中予以詳細(xì)描述。軟件需求：從軟件角度來(lái)看，用戶希望軟件能夠完成哪些功能和受到哪些約束，稱為軟件需求功能需求：描述系統(tǒng)預(yù)期提供的功能或服務(wù)非功能需求：指那些不直接與系統(tǒng)具體功能相關(guān)的一類需求業(yè)務(wù)需求領(lǐng)域需求反映應(yīng)用領(lǐng)域的基本問(wèn)題，直接影響到系統(tǒng)的可用性。例如：圖書館系統(tǒng)的功能需求基于標(biāo)準(zhǔn)用戶界面將一些文檔輸出到本地打印機(jī)或網(wǎng)絡(luò)打印機(jī)上，但因?yàn)榘鏅?quán)限制，這些文檔打印之后應(yīng)立即刪除。功能需求軟件系統(tǒng)的功能需求描述可以有許多方式：文字描述圖表表示功能需求可以以不同的詳細(xì)程度反復(fù)編寫和細(xì)化功能需求描述應(yīng)該完整而且一致和準(zhǔn)確完整性意味著用戶所需的所有的服務(wù)應(yīng)該全部給出描述一致性意味著需求描述不能前后矛盾準(zhǔn)確性是指需求不能出現(xiàn)模糊和二義性的地方4.2需求獲取過(guò)程需求獲取主要是理解客戶需要什么、分析要求、評(píng)價(jià)可行性、協(xié)商合理的方案、無(wú)歧義地詳細(xì)說(shuō)明方案、確認(rèn)規(guī)格說(shuō)明、管理需求以至將這些需求轉(zhuǎn)化為可行系統(tǒng).過(guò)程包括：溝通導(dǎo)出需求精化需求可行性研究與客戶和用戶協(xié)商編寫需求規(guī)格說(shuō)明驗(yàn)證需求管理需求溝通業(yè)務(wù)領(lǐng)域的共利益者（如業(yè)務(wù)管理人員，市場(chǎng)營(yíng)銷人員，產(chǎn)品管理人員）定義業(yè)務(wù)用例確定市場(chǎng)的范圍初略地可行性分析確定項(xiàng)目范圍的工作說(shuō)明導(dǎo)出需求導(dǎo)出需求應(yīng)理解問(wèn)題范圍問(wèn)題：系統(tǒng)的邊界，是客戶和開發(fā)者共同關(guān)心的部分理解問(wèn)題：確定業(yè)務(wù)需求、需求沖突、說(shuō)明有歧義和不可測(cè)試的需求易變問(wèn)題：分清需求穩(wěn)定部分和易變部分收集活動(dòng)：識(shí)別真正的客戶/用戶正確理解客戶的需求耐心聽取客戶意見和思考盡量使用符合客戶語(yǔ)言習(xí)慣的表達(dá)精化需求開發(fā)一個(gè)精確的技術(shù)模型，用以說(shuō)明軟件的功能、特征和約束。精化是一個(gè)分析建模動(dòng)作，由一系列建模和求精任務(wù)構(gòu)成定義了問(wèn)題的信息域，功能域和行為域可行性研究可行性研究的目的是確定用最小的代價(jià)，在盡可能短的時(shí)間內(nèi)確定問(wèn)題是否能夠解決可行性研究的輸入是系統(tǒng)的一個(gè)框架描述和高層邏輯模型輸出是一份需求開發(fā)評(píng)價(jià)報(bào)告，對(duì)需求工程和系統(tǒng)開發(fā)是否值得做的具體建議和意見三個(gè)問(wèn)題：系統(tǒng)是否符合機(jī)構(gòu)的總體要求？系統(tǒng)是否可以在現(xiàn)有的技術(shù)條件、預(yù)算和時(shí)間限制內(nèi)完成？系統(tǒng)能否把已存在的其他系統(tǒng)集成？與客戶和用戶協(xié)商調(diào)節(jié)沖突和問(wèn)題需求排序識(shí)別和分析與每項(xiàng)需求相關(guān)的風(fēng)險(xiǎn)、開發(fā)工作量、成本和交付時(shí)間編寫軟件需求規(guī)格說(shuō)明一個(gè)規(guī)格說(shuō)明可以是一份寫好的文檔、一套圖形化的模型、一個(gè)形式化的數(shù)學(xué)模型、一組使用場(chǎng)景、一個(gè)原型或以上各項(xiàng)的任意組合。軟件需求規(guī)格（SRS，SoftwareRequirementSpecification）是需求分析任務(wù)的最終“產(chǎn)品”，它是客戶、管理者、分析工程師、測(cè)試工程師、維護(hù)工程師交流的標(biāo)準(zhǔn)和依據(jù)。軟件需求規(guī)格描述了系統(tǒng)的數(shù)據(jù)、功能、行為、性能需求、設(shè)計(jì)約束、驗(yàn)收標(biāo)準(zhǔn)、以及其他與需求相關(guān)的信息。SRS模板，包括用戶需求和系統(tǒng)需求（表4-1）需求規(guī)格文檔標(biāo)準(zhǔn)（表4-1）1引言1.1編寫目的1.2項(xiàng)目背景（單位和與其他系統(tǒng)的關(guān)系）1.3定義（專門術(shù)語(yǔ)和縮寫詞）2任務(wù)概述2.1目標(biāo)2.2運(yùn)行環(huán)境2.3條件限制3數(shù)據(jù)描述3.1靜態(tài)數(shù)據(jù)3.2動(dòng)態(tài)數(shù)據(jù)3.3數(shù)據(jù)庫(kù)描述3.4數(shù)據(jù)字典3.5數(shù)據(jù)采集

4功能需求

4.1功能劃分4.2功能描述5性能需求5.1數(shù)據(jù)精確度5.2時(shí)間特性5.3適應(yīng)性6運(yùn)行需求5.1用戶界面5.2硬件接口5.3軟件接口5.4故障處理7其他需求（檢測(cè)或驗(yàn)收標(biāo)準(zhǔn)、可用性、可維護(hù)性可移植性、安全保密性）驗(yàn)證需求驗(yàn)需求證對(duì)需求文檔和制品進(jìn)行質(zhì)量評(píng)估，確保需求說(shuō)明準(zhǔn)確、完整.包括以下內(nèi)容：正確性一致性完整性可行性必要性可檢驗(yàn)性需求的可跟蹤性最后簽字確認(rèn)管理需求管理需求是組織、控制和文檔化需求的系統(tǒng)方法.建立基線以便在客戶和開發(fā)人員之間構(gòu)建一個(gè)約定.需求管理從標(biāo)識(shí)開始，建立跟蹤表.需求跟蹤表可以跟蹤需求的特征、來(lái)源、依賴、子系統(tǒng)和接口等關(guān)系.4.3基于會(huì)談的需求獲取方法非正式會(huì)談：提出一些可自由回答的問(wèn)題.正式會(huì)談：提出一些事先準(zhǔn)備好的議題.情景分析：需求分析從對(duì)場(chǎng)景的評(píng)論中得到信息，然后再將其以形式化方式表示出來(lái)。使用用例建立原型界面序列執(zhí)行過(guò)程視點(diǎn)分析接受系統(tǒng)服務(wù)的當(dāng)前銀行客戶；銀行間自動(dòng)柜員機(jī)有互惠協(xié)議的其他銀行的代表；從該系統(tǒng)中獲得管理信息的銀行支行管理者；負(fù)責(zé)系統(tǒng)日常運(yùn)轉(zhuǎn)和處理客戶意見的支行柜臺(tái)職員；負(fù)責(zé)系統(tǒng)和客戶數(shù)據(jù)庫(kù)集成的數(shù)據(jù)庫(kù)管理者；負(fù)責(zé)保證系統(tǒng)信息安全的銀行信息安全管理者；將該系統(tǒng)視為銀行市場(chǎng)開拓手段的銀行市場(chǎng)開發(fā)部；負(fù)責(zé)硬件和軟件維護(hù)及升級(jí)的硬件和軟件維護(hù)工程師多視點(diǎn)的需求分析過(guò)程視點(diǎn)識(shí)別：包括發(fā)現(xiàn)接收系統(tǒng)服務(wù)的視點(diǎn)和發(fā)現(xiàn)提供給每個(gè)視點(diǎn)的特別服務(wù)。視點(diǎn)組織：包括組織相關(guān)的視點(diǎn)到層次結(jié)構(gòu)中，通用的服務(wù)放在較高的層次，并被較低層次的視點(diǎn)繼承。視點(diǎn)文檔編寫：包括對(duì)被識(shí)別的視點(diǎn)和服務(wù)描述的精煉。視點(diǎn)系統(tǒng)映射：包括在面向?qū)ο笤O(shè)計(jì)中通過(guò)封裝在視點(diǎn)中的服務(wù)信息識(shí)別對(duì)象。4.4基于調(diào)查的需求獲取方法制定調(diào)查表可靠可信分析4.5基于場(chǎng)景的需求獲取方法分析員與項(xiàng)目相關(guān)人員共同識(shí)別出情景，并捕獲這些情景的細(xì)節(jié)把細(xì)節(jié)加入到一個(gè)綱要的需求描述中時(shí)，情景特別有用情景是對(duì)交互實(shí)例片斷的描述，每個(gè)情景可能包含一個(gè)或多個(gè)交互，它們能在不同的細(xì)節(jié)層次上提供不同類型的情景信息情景開始于一個(gè)框架，在導(dǎo)出過(guò)程中，細(xì)節(jié)被逐漸增加，直到產(chǎn)生交互的一個(gè)完整的描述情景內(nèi)容在情景開始部分有一個(gè)系統(tǒng)狀態(tài)描述；關(guān)于標(biāo)準(zhǔn)事件流的描述；關(guān)于哪兒會(huì)出錯(cuò)，以及如何處理錯(cuò)誤的描述；有關(guān)其他可能在同一時(shí)間進(jìn)行的活動(dòng)的信息；在情景完成后系統(tǒng)狀態(tài)的描述場(chǎng)景名：取款參與者：銀行客戶場(chǎng)景描述：1．插入有效的銀行卡；2．ATM機(jī)驗(yàn)證該銀行卡；3．系統(tǒng)要求輸入銀行卡密碼，用戶輸入密碼；4．系統(tǒng)通過(guò)網(wǎng)絡(luò)向銀行內(nèi)部系統(tǒng)請(qǐng)求驗(yàn)證密碼；5．若驗(yàn)證通過(guò)，系統(tǒng)請(qǐng)求選擇業(yè)務(wù)，選擇取款；6．系統(tǒng)要求輸入取款金額，比如1000元；7．系統(tǒng)驗(yàn)證是有足夠的現(xiàn)金，并請(qǐng)求驗(yàn)證銀行內(nèi)部服務(wù)器處理取款；8．若處理成功，系統(tǒng)計(jì)算鈔票數(shù)目，并送出現(xiàn)金；9．用戶取走現(xiàn)金；10．系統(tǒng)打印憑條，用戶取走憑條；11．系統(tǒng)退出銀行卡，用戶取走銀行卡。4.6基于用例（用況）的需求獲取方法需求捕獲的目標(biāo)：發(fā)現(xiàn)真正的需求以適用于用戶、客戶和開發(fā)人員的方式加以表示系統(tǒng)用戶表示為一個(gè)參與者參與者在與用例進(jìn)行交互時(shí)使用系統(tǒng)用例向參與者提供某些有價(jià)值結(jié)果而執(zhí)行一些動(dòng)作序列用例分析過(guò)程用例建模分析開發(fā)活動(dòng)圖開發(fā)泳道圖用例分析用例著眼于為用戶增加價(jià)值，提供了一種捕獲功能需求的系統(tǒng)且直觀的方法，可驅(qū)動(dòng)整個(gè)開發(fā)過(guò)程。用例從某個(gè)特定參與者的角度用簡(jiǎn)單易懂的語(yǔ)言說(shuō)明一個(gè)特定的使用場(chǎng)景。要開始開發(fā)用例，應(yīng)列出特定參與者執(zhí)行的功能或者活動(dòng)。用例模型幫助客戶、用戶和開發(fā)人員在如何使用系統(tǒng)方面達(dá)成共識(shí)。用例圖描述部分用例模型，顯示帶有聯(lián)系的用例和參與者的集合POS機(jī)系統(tǒng)用例建模POS機(jī)系統(tǒng)是電子收款機(jī)系統(tǒng)，通過(guò)計(jì)算機(jī)化用于處理銷售和支付，記錄銷售信息。該系統(tǒng)包括計(jì)算機(jī)、條碼掃描儀、現(xiàn)金抽屜等硬件，以及使系統(tǒng)運(yùn)轉(zhuǎn)的軟件和為不同服務(wù)的應(yīng)用程序提供接口。POS機(jī)系統(tǒng)為例說(shuō)明用例建模分析過(guò)程。POS機(jī)系統(tǒng)的問(wèn)題描述收銀員可以記錄銷售商品信息，系統(tǒng)計(jì)算總價(jià)。收銀員能夠通過(guò)系統(tǒng)處理支付，包括現(xiàn)金支付、信用卡支付和支票支付。經(jīng)理還能處理顧客退貨。系統(tǒng)要求具有一定的容錯(cuò)性，即如果遠(yuǎn)程服務(wù)（如庫(kù)存系統(tǒng)）暫時(shí)中斷，系統(tǒng)必須仍然能夠獲取銷售信息并且至少能夠處理現(xiàn)金付款。POS機(jī)必須支持日益增多的各種的客戶終端和接口，比如多種形式的用戶圖形界面、觸摸屏輸入、無(wú)線PDA等。系統(tǒng)需要一種機(jī)制提供靈活的處理不同客戶獨(dú)特的業(yè)務(wù)邏輯規(guī)則和定制能力。POS機(jī)系統(tǒng)部分用例圖用例圖用例圖包括：參與者、用例、關(guān)聯(lián)和邊界四個(gè)要素。參與者：用小人形表示用例：用橢圓表示關(guān)聯(lián)：用直線表示說(shuō)明參與者驅(qū)動(dòng)某個(gè)用例邊界：用矩形框表示，說(shuō)明系統(tǒng)關(guān)注點(diǎn)。開發(fā)用例用例使用非正式的描述性風(fēng)格編寫，也可以使用某個(gè)結(jié)構(gòu)化的格式編寫，有些格式更強(qiáng)調(diào)描述的直觀性。用例不同部分說(shuō)明用例名稱以動(dòng)詞開始描述用例名稱范圍要設(shè)計(jì)的系統(tǒng)級(jí)別“用戶目標(biāo)”或者是“子功能”主要參與者調(diào)用系統(tǒng)，使之交付服務(wù)渋眾及其關(guān)注點(diǎn)關(guān)注該用例的人，及其需要前置條件開始前必須為真的條件成功保證成功完成必須滿足的條件主成功場(chǎng)景典型的、無(wú)條件的、理想方式的成功場(chǎng)景擴(kuò)展成功或失敗的替代場(chǎng)景特殊需求相關(guān)的非功能性需求技術(shù)和數(shù)據(jù)變?cè)夭煌腎/O方法和數(shù)據(jù)格式發(fā)生頻率影響對(duì)實(shí)現(xiàn)的調(diào)查、測(cè)試和時(shí)間安排雜項(xiàng)未決問(wèn)題等用例場(chǎng)景用例名稱：處理一次銷售范圍：POS機(jī)應(yīng)用級(jí)別：用戶目標(biāo)主要參與者：收銀員涉眾及其關(guān)注點(diǎn)：收銀員：希望能夠準(zhǔn)確、快速地輸入，而且沒(méi)有支付錯(cuò)誤，因?yàn)槿绻偈肇浛?，將從其薪水眾扣除。售貨員：希望自動(dòng)更新銷售提成顧客：希望以最小代價(jià)完成購(gòu)買活動(dòng)并得到快速服務(wù)。希望便捷、清晰地看到所輸入的商品項(xiàng)目和價(jià)格。希望得到購(gòu)買憑證，以便退貨。公司：希望準(zhǔn)確地記錄交易，滿足顧客要求。希望確保記錄了支付授權(quán)服務(wù)的支付票據(jù)。希望有一定的容錯(cuò)性，即便在某些服務(wù)器構(gòu)件不可用時(shí)（如遠(yuǎn)程信用卡驗(yàn)證），也能夠完成銷售。希望能夠自動(dòng)、快速地更新帳戶和庫(kù)存信息。經(jīng)理：希望能夠快速執(zhí)行超控操作，并易于更正收銀員的不當(dāng)操作。前置條件：收銀員必須經(jīng)過(guò)確認(rèn)和認(rèn)證。成功保證（或后置條件）：存儲(chǔ)銷售信息，更新帳戶和庫(kù)存信息，記錄提成，生成票據(jù)，記錄支付授權(quán)的批準(zhǔn)。主成功場(chǎng)景1.顧客攜帶所購(gòu)商品或服務(wù)到收銀臺(tái)通過(guò)POS機(jī)付款。2.收銀員開始一次新的銷售交易。3.收銀員輸入商品條碼。4.系統(tǒng)逐步記錄出售的商品，并顯示該商品的描述、價(jià)格和累計(jì)額。價(jià)格通過(guò)一組價(jià)格規(guī)則來(lái)計(jì)算。收銀員重復(fù)3~~4步，直到輸入結(jié)束。5.系統(tǒng)顯示總額和計(jì)算折扣。6.收銀員告知顧客總額，并請(qǐng)顧客付款。7.顧客付款，系統(tǒng)處理支付。8.系統(tǒng)記錄完整的銷售信息，并將銷售和支付信息發(fā)送到外部的賬務(wù)系統(tǒng)（進(jìn)行賬務(wù)處理和提成）和庫(kù)存系統(tǒng)（更新庫(kù)存）。9.系統(tǒng)打印票據(jù)。10.顧客攜帶商品和票據(jù)離開。開發(fā)活動(dòng)圖UML活動(dòng)圖通過(guò)提供特定的場(chǎng)景內(nèi)交流的圖形化表示來(lái)補(bǔ)充用例?；顒?dòng)圖符號(hào)：兩端為半圓形的矩形表示一個(gè)特定的系統(tǒng)功能箭頭表示通過(guò)系統(tǒng)的流判定菱形表示判定分支水平線、分叉點(diǎn)和連接表示并發(fā)活動(dòng)對(duì)象節(jié)點(diǎn)表示活動(dòng)對(duì)象活動(dòng)圖通常能夠既表示控制流又表示數(shù)據(jù)流。UML活動(dòng)圖代替?zhèn)鹘y(tǒng)的數(shù)據(jù)流圖（DataFlowDiagram）表示法處理銷售用例活動(dòng)圖泳道圖UML泳道圖（swimlane）是活動(dòng)圖的一種有用的變形可以讓建模人員表示用例所描述的活動(dòng)圖，同時(shí)看哪個(gè)參與者或分析類對(duì)活動(dòng)矩形所描述的活動(dòng)負(fù)責(zé)。泳道用縱向分割圖的并列條形部分表示，就像游泳池中的泳道，也稱特定分區(qū)。UML泳道圖通常對(duì)于涉及眾多參與者的非常復(fù)雜的業(yè)務(wù)過(guò)程建模具有價(jià)值。泳道圖小結(jié)需求分析也稱為需求工程，是一個(gè)非常重要而有很復(fù)雜的，需要交替進(jìn)行，反復(fù)迭代的過(guò)程。從用戶角度看，需求分為業(yè)務(wù)需求和用戶需求，從軟件角度看，需求分為功能需求和非功能需求。需求分析過(guò)程分為溝通、導(dǎo)出需求、精化需求、可行性研究、與客戶和用戶協(xié)商、編寫規(guī)格說(shuō)明、驗(yàn)證需求和管理需求等活動(dòng)。需求獲取方法主要包括會(huì)談、調(diào)查表、場(chǎng)景分析和用例分析等。用例建模根據(jù)外部使用者從使用系統(tǒng)或業(yè)務(wù)分析出發(fā)，抽取出系統(tǒng)的業(yè)務(wù)需求和領(lǐng)域要求，并精化為系統(tǒng)的需求。用例模型包括用例視圖模型、用例場(chǎng)景和用例活動(dòng)圖或泳道圖。第二部分結(jié)構(gòu)化軟件工程范型結(jié)構(gòu)化軟件分析與設(shè)計(jì)要建立哪些模型？概要設(shè)計(jì)與詳細(xì)設(shè)計(jì)的關(guān)系是什么？軟件概要設(shè)計(jì)主流的技術(shù)是什么？軟件詳細(xì)設(shè)計(jì)主流的技術(shù)是什么？軟件測(cè)試包括哪些過(guò)程和主要技術(shù)？關(guān)注一下問(wèn)題內(nèi)容提要：結(jié)構(gòu)化分析概述結(jié)構(gòu)化分析模型數(shù)據(jù)流分析方法數(shù)據(jù)建模分析方法狀態(tài)分析方法結(jié)構(gòu)化分析過(guò)程軟件需求規(guī)格說(shuō)明文檔第5章結(jié)構(gòu)化分析結(jié)構(gòu)化分析（SA，StructuredAnalysis）方法是20世紀(jì)70年代，由E.Yourdon等人倡導(dǎo)的一種適用于大型數(shù)據(jù)處理系統(tǒng)的、面向數(shù)據(jù)流的需求分析方法。結(jié)構(gòu)化分析方法是一種傳統(tǒng)的軟件建模技術(shù)，其過(guò)程是創(chuàng)建描述信息內(nèi)容和數(shù)據(jù)流模型，依據(jù)功能和行為對(duì)系統(tǒng)進(jìn)行劃分，并描述必須建立的系統(tǒng)要素。5.1結(jié)構(gòu)化分析概述充分理解問(wèn)題開發(fā)快速原型描述軟件需求建立軟件高層模型確定軟件需求優(yōu)先級(jí)驗(yàn)證軟件需求結(jié)構(gòu)化需求分析指導(dǎo)性活動(dòng)結(jié)構(gòu)化分析方法是一種半形式化的分析與建模技術(shù)，其過(guò)程包括對(duì)軟件相關(guān)的各種信息進(jìn)行分析,抽取其本質(zhì)特征,創(chuàng)建描述數(shù)據(jù)、功能和行為的模型。結(jié)構(gòu)化分析模型的主要目標(biāo)：描述客戶的需要；為軟件設(shè)計(jì)建立基礎(chǔ)；定義在軟件完成后可以確認(rèn)的一組需求。5.2結(jié)構(gòu)化分析模型系統(tǒng)模型從以下不同的角度表述系統(tǒng)：從外部來(lái)看，它是對(duì)系統(tǒng)分析上下文或系統(tǒng)環(huán)境建模；從行為上看，它是對(duì)系統(tǒng)行為建模；從結(jié)構(gòu)上看，它是對(duì)系統(tǒng)的體系結(jié)構(gòu)和系統(tǒng)處理的數(shù)據(jù)結(jié)構(gòu)建模。結(jié)構(gòu)化的需求分析模型：系統(tǒng)行為模型：數(shù)據(jù)流模型，用來(lái)描述系統(tǒng)中的數(shù)據(jù)處理過(guò)程狀態(tài)轉(zhuǎn)換模型，用來(lái)描述系統(tǒng)如何對(duì)事件做出響應(yīng)實(shí)體—關(guān)系模型：關(guān)心的是尋找系統(tǒng)中的數(shù)據(jù)及其之間的關(guān)系，卻不關(guān)心系統(tǒng)中包含的功能。5.2結(jié)構(gòu)化分析模型數(shù)據(jù)字典實(shí)體-關(guān)系圖數(shù)據(jù)流圖加工規(guī)約數(shù)據(jù)對(duì)象描述狀態(tài)轉(zhuǎn)換圖控制規(guī)約結(jié)構(gòu)化分析模型結(jié)構(gòu)分析模型結(jié)構(gòu)的核心是數(shù)據(jù)字典（DD，DataDictionary），包含了軟件使用或生產(chǎn)的所有數(shù)據(jù)對(duì)象描述的中心庫(kù)。分析模型結(jié)構(gòu)的中間層有三種視圖：數(shù)據(jù)流圖（DFD，DataFlowDiagram）服務(wù)于兩個(gè)目的：一是指明數(shù)據(jù)在系統(tǒng)中移動(dòng)時(shí)如何被變換，二是描述對(duì)數(shù)據(jù)流進(jìn)行變換的功能和子功能。實(shí)體—關(guān)系圖（E-RD，Entity-RelationshipDiagram）描述數(shù)據(jù)對(duì)象間的關(guān)系，用來(lái)進(jìn)行數(shù)據(jù)建模活動(dòng)的記號(hào)。狀態(tài)轉(zhuǎn)換圖（STD，StateTransitionDiagram）指明作為外部事件的結(jié)果，系統(tǒng)將如何動(dòng)作。分析模型結(jié)構(gòu)的外層是規(guī)約描述：在實(shí)體—關(guān)系圖中每個(gè)數(shù)據(jù)對(duì)象的屬性可以使用數(shù)據(jù)對(duì)象來(lái)描述。在數(shù)據(jù)流圖中出現(xiàn)的每個(gè)加工/處理的功能描述包含在加工規(guī)約中。軟件控制方面的附加信息包含在控制規(guī)約中結(jié)構(gòu)化分析模型組成面向數(shù)據(jù)流的建模是一種結(jié)構(gòu)化需求分析方法，簡(jiǎn)稱數(shù)據(jù)流分析方法數(shù)據(jù)流分析方法采用自頂向下逐層分解，描繪滿足用戶要求的軟件模型表示：數(shù)據(jù)流圖：描述系統(tǒng)處理過(guò)程數(shù)據(jù)字典：模型中的數(shù)據(jù)信息集合5.3數(shù)據(jù)流分析方法數(shù)據(jù)源點(diǎn)或終點(diǎn)變換數(shù)據(jù)的處理數(shù)據(jù)存儲(chǔ)數(shù)據(jù)流或或或數(shù)據(jù)流圖：表示軟件的行為模型數(shù)據(jù)字典是分析模型中出現(xiàn)的所有名字的一個(gè)集合，并包括有關(guān)命名實(shí)體的描述數(shù)據(jù)字典有以下兩個(gè)作用：它是所有名字信息管理的有效機(jī)制作為連接軟件分析、設(shè)計(jì)、實(shí)現(xiàn)和進(jìn)化階段的開發(fā)機(jī)構(gòu)的信息存儲(chǔ)數(shù)據(jù)字典應(yīng)該由四類元素的定義組成：數(shù)據(jù)流數(shù)據(jù)流分量數(shù)據(jù)存儲(chǔ)處理對(duì)于處理，可用輸入—處理—輸出（IPO，Input-Process-Output）視圖描述更方便數(shù)據(jù)字典應(yīng)對(duì)組成的數(shù)據(jù)元素定義進(jìn)行自頂向下的分解。分解的原則是：當(dāng)包含的元素不需要進(jìn)一步定義，且每個(gè)和工程有關(guān)的人都清楚時(shí)為止數(shù)據(jù)字典中應(yīng)該包括關(guān)于數(shù)據(jù)的信息：一般信息（名字、別名、描述等）定義（數(shù)據(jù)類型、長(zhǎng)度、結(jié)構(gòu)等）使用特點(diǎn)（值的范圍、使用頻率、使用條件、使用方式、條件值等）控制信息（用戶、使用特點(diǎn)、改變數(shù)、使用權(quán)等）分組信息（文檔結(jié)構(gòu)、從屬結(jié)構(gòu)、物理位置等）三種類型的任意組合定義數(shù)據(jù)字典中的任何條目。順序：順序連接兩個(gè)或多個(gè)分量元素。一般用加號(hào)表示順序連接關(guān)系。選擇：從兩個(gè)或多個(gè)可選的分量元素中選取一個(gè)。選擇運(yùn)算符用方括號(hào)表示，對(duì)于多個(gè)可供選擇的元素，用“|”符號(hào)分隔。例如，[A-1|A-2|A-3]表示三個(gè)可選數(shù)據(jù)元素。重復(fù)：描述的分量元素重復(fù)零次或多次。例如，

都表示數(shù)據(jù)元素A的下限為1，上限為5。數(shù)據(jù)字典數(shù)據(jù)流分析步驟數(shù)據(jù)流圖要素分析：根據(jù)問(wèn)題確定數(shù)據(jù)的源點(diǎn)、終點(diǎn)、數(shù)據(jù)流、數(shù)據(jù)存儲(chǔ)和處理等。構(gòu)建數(shù)據(jù)流圖：根據(jù)數(shù)據(jù)流圖要素繪制數(shù)據(jù)流圖。建立數(shù)據(jù)字典：對(duì)數(shù)據(jù)流分析中所涉及的所有要素進(jìn)行詳細(xì)的規(guī)格描述。一個(gè)工廠采購(gòu)部每天需要一張定貨報(bào)表。零件的入庫(kù)、出庫(kù)事務(wù)通過(guò)計(jì)算機(jī)終端輸入給定貨系統(tǒng)。當(dāng)某零件的庫(kù)存數(shù)少于給定的庫(kù)存量臨界值時(shí)，就應(yīng)該再次定貨。定貨的零件數(shù)據(jù)有：零件編號(hào)、名稱、數(shù)量、價(jià)格、供應(yīng)者等。數(shù)據(jù)流分析：數(shù)據(jù)源點(diǎn)：倉(cāng)管員（負(fù)責(zé)入庫(kù)或出庫(kù)事務(wù)給定貨系統(tǒng)）；數(shù)據(jù)終點(diǎn)：采購(gòu)員（接收每天的定貨報(bào)表）；數(shù)據(jù)流：事務(wù)，定貨；數(shù)據(jù)存儲(chǔ)：定貨信息，庫(kù)存清單；處理：處理事務(wù)，產(chǎn)生報(bào)表。例5.1訂貨軟件的數(shù)據(jù)流圖畫基本系統(tǒng)模型采購(gòu)員事務(wù)定貨報(bào)表倉(cāng)管員訂貨系統(tǒng)第1次求精第2次求精數(shù)據(jù)字典卡片方式示例名字：訂貨報(bào)表別名：訂貨信息描述：每天一次需要訂貨的零件表定義：訂貨報(bào)表=1{零件信息}50

其中：

零件信息=零件編號(hào)+零件名稱+數(shù)量+價(jià)格+1{供應(yīng)者}3

分量定義：

零件編號(hào)=8位字符；

零件名稱=20位字符；

數(shù)量=[1|2|3|4|5]；

價(jià)格={數(shù)值類型}；

供應(yīng)者=24位字符位置：輸出到打印機(jī)軟件建模的一個(gè)重要方面就是要定義系統(tǒng)處理的邏輯結(jié)構(gòu)。最廣泛采用的數(shù)據(jù)建模技術(shù)是實(shí)體-關(guān)系模型，它描述數(shù)據(jù)實(shí)體、關(guān)聯(lián)及實(shí)體屬性。實(shí)體關(guān)系模型可用ERD（Entity-RelationshipsDiagram實(shí)體關(guān)系圖）來(lái)表示：實(shí)體關(guān)聯(lián)實(shí)體屬性基數(shù)5.4數(shù)據(jù)建模分析方法例5.2圖書館管理系統(tǒng)實(shí)體關(guān)系圖1借還記錄預(yù)約記錄借/還/續(xù)借

1M10..510包含預(yù)約借書者圖書書目借書者：借書證號(hào)、姓名、性別、借書數(shù)、最大借書數(shù)、罰金金額、有效期。圖書：書號(hào)、ISBN號(hào)、狀態(tài)。書目：ISBN號(hào)、書名、作者、出版社、摘要、目錄、叢書名、收藏?cái)?shù)、在館數(shù)、預(yù)約數(shù)。借還記錄：書號(hào)、借書證號(hào)、借出日期、應(yīng)還日期、續(xù)借次數(shù)。預(yù)約記錄：ISBN號(hào)、借書證號(hào)、預(yù)約日期。實(shí)體屬性狀態(tài)分析方法主要任務(wù)是建立軟件的狀態(tài)模型。狀態(tài)模型是一種描述系統(tǒng)對(duì)內(nèi)部或者外部事件響應(yīng)的行為模型。它描述系統(tǒng)狀態(tài)和事件，以及事件引發(fā)系統(tǒng)在狀態(tài)間的轉(zhuǎn)換。這種模型適用于描述實(shí)時(shí)系統(tǒng)。狀態(tài)機(jī)建模方法步驟：系統(tǒng)狀態(tài)、行為與事件分析構(gòu)建狀態(tài)圖5.5狀態(tài)分析方法狀態(tài)模型一般采用狀態(tài)轉(zhuǎn)換圖（簡(jiǎn)稱狀態(tài)圖）的標(biāo)記方法狀態(tài)圖描述了系統(tǒng)中某些復(fù)雜對(duì)象的狀態(tài)變化狀態(tài)是可觀察的行為模式，用圓角矩形表示；變遷表示狀態(tài)的轉(zhuǎn)換，用箭頭表示；事件是引發(fā)變遷的消息，用箭頭上的標(biāo)記表示。狀態(tài)圖還可以用事件后的方括號(hào)表示先決條件，只有當(dāng)這個(gè)條件為真時(shí)，才會(huì)發(fā)生狀態(tài)變化；用狀態(tài)自身的弧線箭頭表示先決條件不為真時(shí)，狀態(tài)不會(huì)改變。狀態(tài)轉(zhuǎn)換圖問(wèn)題描述在一幢有m層的大廈中安裝一套n部電梯的產(chǎn)品，按照下列條件求解電梯在各樓層之間移動(dòng)的邏輯關(guān)系：每部電梯有m個(gè)按鈕，每一個(gè)按鈕代表一個(gè)樓層。當(dāng)按下一個(gè)按鈕時(shí)該按鈕指示燈亮，同時(shí)電梯駛向相應(yīng)的樓層，當(dāng)?shù)竭_(dá)相應(yīng)樓層時(shí)指示燈熄滅。除了最底層和最高層之外，每一層樓都有兩個(gè)按鈕分別指示電梯上行和下行。按下按鈕后指示燈就開始亮，當(dāng)電梯到達(dá)此樓層時(shí)指示燈熄滅，電梯暫停并執(zhí)行開門和關(guān)門動(dòng)作，并向所需要的方向移動(dòng)。當(dāng)電梯無(wú)升降運(yùn)動(dòng)時(shí)，關(guān)門并停在當(dāng)前樓層。電梯系統(tǒng)狀態(tài)分析電梯在運(yùn)行過(guò)程一般具有下列狀態(tài)：空閑:無(wú)請(qǐng)求時(shí),電梯處于休息狀態(tài)；暫停:上下乘客時(shí),電梯處于暫停，開門和關(guān)門；上行:電梯處于向上運(yùn)行狀態(tài)；下行:電梯處于向下運(yùn)行狀態(tài)；處于第一層:初始啟動(dòng),電梯會(huì)在第一層等待狀態(tài)；向第一層移動(dòng)：長(zhǎng)時(shí)間

處于空閑時(shí)，電梯移動(dòng)到第一層。

狀態(tài)事件及行為分析電梯控制系統(tǒng)的事件有：向上：驅(qū)動(dòng)電梯向上運(yùn)行；向下：驅(qū)動(dòng)電梯向下運(yùn)行；停止：停止電梯運(yùn)行；無(wú)請(qǐng)求：沒(méi)有乘客請(qǐng)求乘坐電梯；長(zhǎng)時(shí)間無(wú)請(qǐng)求：長(zhǎng)時(shí)間沒(méi)有乘客請(qǐng)求乘坐電梯。繪制電梯對(duì)象的狀態(tài)圖問(wèn)題描述繪制數(shù)據(jù)流圖確定計(jì)算機(jī)化部分定義數(shù)據(jù)定義處理邏輯定義物理資源確定輸入和輸出規(guī)格確定數(shù)據(jù)規(guī)模、格式、硬件要求編寫規(guī)格說(shuō)明書5.6結(jié)構(gòu)化分析過(guò)程1、問(wèn)題描述圖書銷售店從各出版社購(gòu)買圖書，并將其銷售給大學(xué)、公司和個(gè)人客戶。書店庫(kù)存流行的圖書，并根據(jù)需要訂購(gòu)其他圖書。書店提供大學(xué)訂購(gòu)服務(wù)，并根據(jù)客戶和訂購(gòu)量提供優(yōu)惠?，F(xiàn)在書店希望實(shí)現(xiàn)計(jì)算機(jī)化管理，將如何做？分析上述問(wèn)題，確定需要有哪些商務(wù)功能（入賬、出賬和庫(kù)存），系統(tǒng)是批處理方式還是聯(lián)機(jī)方式，硬件設(shè)備情況，實(shí)現(xiàn)計(jì)算機(jī)化管理的目的是什么等目標(biāo)?？梢钥闯?，其目的是為了銷售圖書和圖書管理以及賬目管理。例5.4書店圖書銷售軟件結(jié)構(gòu)化分析步驟

2、繪制數(shù)據(jù)流圖系統(tǒng)的自動(dòng)化方案選擇，取決于客戶的投資和目標(biāo)。一般必須利用成本—效益分析對(duì)數(shù)據(jù)流圖各個(gè)部分的操作分析決定以批處理方式還是以聯(lián)機(jī)方式執(zhí)行。

本例的第一個(gè)方案是以批處理方式處理出賬、訂購(gòu)圖書，用聯(lián)機(jī)方式處理訂單的有效性檢查、聚集訂單和開發(fā)貨清單；第二個(gè)方案是除發(fā)貨票據(jù)使用聯(lián)機(jī)方式或批處理方式外，其余都用聯(lián)機(jī)方式。3、確定需要計(jì)算機(jī)化部分本例的數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)有“訂單”、“圖書數(shù)據(jù)”、“顧客數(shù)據(jù)”、“賬目”、“發(fā)貨清單”等等。4、定義數(shù)據(jù)確定了產(chǎn)品的數(shù)據(jù)元素，就可以分析每個(gè)處理具體做什么了。例如，分析“生成賬目”中“給教育部門打折扣”細(xì)節(jié)。5、定義處理邏輯加工邏輯也稱為過(guò)程說(shuō)明，用于描述數(shù)據(jù)流圖中加工邏輯的處理算法或過(guò)程處理邏輯的描述軟件需求分析的描述通常采用一種規(guī)范的需求規(guī)格文檔。需求規(guī)格說(shuō)明文檔，即軟件需求規(guī)格說(shuō)明書（SoftwareRequirementSpecification，SRS）是需求分析任務(wù)的最終“產(chǎn)品”。需求規(guī)格說(shuō)明文檔的讀者5.7軟件需求規(guī)格說(shuō)明文檔SRS描述要求SRS應(yīng)滿足以下各個(gè)方面的描述要求：l只敘述軟件的外部行為l定義軟件實(shí)現(xiàn)上的約束l是容易改變的l成為軟件維護(hù)人員的參考工具l記錄軟件的整個(gè)生命周期l應(yīng)對(duì)未料到的事件給出可接受的反應(yīng)SRS標(biāo)準(zhǔn)內(nèi)容SRS各個(gè)部分的簡(jiǎn)要介紹。（1）引言部分。陳述關(guān)于計(jì)劃文檔的背景和為什么需要該軟件，解釋軟件是如何與其他軟件協(xié)同工作的。（2）任務(wù)概述。陳述軟件的目標(biāo)、運(yùn)行環(huán)境和軟件的規(guī)模等。（3）數(shù)據(jù)描述。給出軟件必須解決的問(wèn)題的詳細(xì)描述，并記錄了信息內(nèi)容和關(guān)系、輸入/輸出數(shù)據(jù)及其結(jié)構(gòu)。（4）功能描述。給出解決問(wèn)題所需要的每個(gè)功能，包括每個(gè)功能的處理過(guò)程、設(shè)計(jì)約束等。（5）性能需求。描述性能特征和約束，包括時(shí)間約束、適應(yīng)性等。（6）運(yùn)行需求。給出交互的用戶界面要求，與其他軟/硬件的接口，以及異常處理等。（7）其他需求。給出軟件維護(hù)性各個(gè)方面的要求。結(jié)構(gòu)化分析方法是一種自頂向下，逐步分解的面向數(shù)據(jù)和數(shù)據(jù)流的建模方法。結(jié)構(gòu)化分析模型工具有數(shù)據(jù)流圖、數(shù)據(jù)字典、實(shí)體關(guān)系圖和狀態(tài)轉(zhuǎn)換圖等。數(shù)據(jù)流圖和數(shù)據(jù)字典常用于結(jié)構(gòu)化分析，用于描述軟件的數(shù)據(jù)處理及其流程的信息，它們一起被稱為軟件邏輯模型。實(shí)體關(guān)系圖和狀態(tài)轉(zhuǎn)換圖輔助描述軟件所涉及的實(shí)體動(dòng)態(tài)變化行為。小結(jié)內(nèi)容提要結(jié)構(gòu)化設(shè)計(jì)概述軟件設(shè)計(jì)過(guò)程結(jié)構(gòu)化設(shè)計(jì)原理模塊獨(dú)立性度量軟件結(jié)構(gòu)化設(shè)計(jì)軟件詳細(xì)設(shè)計(jì)第6章結(jié)構(gòu)化設(shè)計(jì)6.1結(jié)構(gòu)化設(shè)計(jì)概述軟件設(shè)計(jì)是把軟件需求“變換”為用于構(gòu)造軟件的藍(lán)圖。所以，它的“輸入”是需求分析各種模型元素，“輸出”是軟件設(shè)計(jì)模型和描述。軟件設(shè)計(jì)的目標(biāo)是對(duì)將要實(shí)現(xiàn)的軟件的體系結(jié)構(gòu)、數(shù)據(jù)模型、軟件模塊間的接口，以及所模塊采用的算法給出詳盡的描述。軟件設(shè)計(jì)任務(wù)：數(shù)據(jù)設(shè)計(jì)體系結(jié)構(gòu)設(shè)計(jì)接口設(shè)計(jì)構(gòu)件設(shè)計(jì)總體設(shè)計(jì)，也稱為概要設(shè)計(jì)，軟件結(jié)構(gòu)設(shè)計(jì)，或高層設(shè)計(jì)。分析需求規(guī)格說(shuō)明模塊劃分，形成具有預(yù)定功能的模塊組成結(jié)構(gòu)表示出模塊間的控制關(guān)系給出模塊之間的接口軟件詳細(xì)設(shè)計(jì)，也稱為（模塊）過(guò)程設(shè)計(jì)，或低層設(shè)計(jì)。設(shè)計(jì)模塊細(xì)節(jié)確定模塊所需的算法和數(shù)據(jù)結(jié)構(gòu)等6.2軟件設(shè)計(jì)過(guò)程方案設(shè)計(jì)方案選取推薦最佳方案功能分解和軟件結(jié)構(gòu)設(shè)計(jì)數(shù)據(jù)庫(kù)設(shè)計(jì)編制設(shè)計(jì)文檔審查和復(fù)審軟件概要設(shè)計(jì)步驟詳細(xì)設(shè)計(jì)是為軟件概要設(shè)計(jì)階段給出的軟件結(jié)構(gòu)圖中的各個(gè)模塊設(shè)計(jì)處理過(guò)程的細(xì)節(jié)，確定模塊所需的算法和數(shù)據(jù)結(jié)構(gòu)等。詳細(xì)設(shè)計(jì)主要描述每個(gè)模塊或構(gòu)件的設(shè)計(jì)細(xì)節(jié)，主要包括模塊或構(gòu)件的處理邏輯、算法、接口等。詳細(xì)設(shè)計(jì)的內(nèi)容包括：（1）模塊或構(gòu)件描述：描述模塊或構(gòu)件的功能，以及需要解決的問(wèn)題，這個(gè)模塊或構(gòu)件在什么時(shí)候可以被調(diào)用，為什么需要這個(gè)模塊或構(gòu)件。（2）算法描述：確定模塊或構(gòu)件的處理算法和步驟，包括公式、邊界和特殊條件，甚至參考資料等。（3）數(shù)據(jù)描述：描述模塊或構(gòu)件內(nèi)部的數(shù)據(jù)結(jié)構(gòu)。詳細(xì)設(shè)計(jì)可采用流程圖、PDL語(yǔ)言、盒圖、判定表等描述算法的圖、表和偽代碼來(lái)表示。設(shè)計(jì)過(guò)程不應(yīng)該受“隧道視野”的限制設(shè)計(jì)對(duì)于分析模型應(yīng)該是可跟蹤的設(shè)計(jì)不應(yīng)該從頭做起