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

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

Disciplined

Predictable

Immature

Mature

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

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

簡單是最根本的。

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

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

993.4結(jié)對編程

(PairProgramming

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

……另一方面：

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

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

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

編程方式避免cowboy式的編程好代碼的衡量標(biāo)準(zhǔn)：可讀性和可維護性對大部分的商業(yè)項目來說，更主要的顧慮是成本。好的代碼可以減少修改的成本。互相督促可以提高代碼的可讀性。

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

1)怕自己看上去傻

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

3)怕自己變的不重要（過時）

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

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

公正開明勇氣

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

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

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

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

4功能需求

4.1功能劃分4.2功能描述5性能需求5.1數(shù)據(jù)精確度5.2時間特性5.3適應(yīng)性6運行需求5.1用戶界面5.2硬件接口5.3軟件接口5.4故障處理7其他需求（檢測或驗收標(biāo)準(zhǔn)、可用性、可維護性可移植性、安全保密性）驗證需求驗需求證對需求文檔和制品進(jìn)行質(zhì)量評估，確保需求說明準(zhǔn)確、完整.包括以下內(nèi)容：正確性一致性完整性可行性必要性可檢驗性需求的可跟蹤性最后簽字確認(rèn)管理需求管理需求是組織、控制和文檔化需求的系統(tǒng)方法.建立基線以便在客戶和開發(fā)人員之間構(gòu)建一個約定.需求管理從標(biāo)識開始，建立跟蹤表.需求跟蹤表可以跟蹤需求的特征、來源、依賴、子系統(tǒng)和接口等關(guān)系.4.3基于會談的需求獲取方法非正式會談：提出一些可自由回答的問題.正式會談：提出一些事先準(zhǔn)備好的議題.情景分析：需求分析從對場景的評論中得到信息，然后再將其以形式化方式表示出來。使用用例建立原型界面序列執(zhí)行過程視點分析接受系統(tǒng)服務(wù)的當(dāng)前銀行客戶；銀行間自動柜員機有互惠協(xié)議的其他銀行的代表；從該系統(tǒng)中獲得管理信息的銀行支行管理者；負(fù)責(zé)系統(tǒng)日常運轉(zhuǎn)和處理客戶意見的支行柜臺職員；負(fù)責(zé)系統(tǒng)和客戶數(shù)據(jù)庫集成的數(shù)據(jù)庫管理者；負(fù)責(zé)保證系統(tǒng)信息安全的銀行信息安全管理者；將該系統(tǒng)視為銀行市場開拓手段的銀行市場開發(fā)部；負(fù)責(zé)硬件和軟件維護及升級的硬件和軟件維護工程師多視點的需求分析過程視點識別：包括發(fā)現(xiàn)接收系統(tǒng)服務(wù)的視點和發(fā)現(xiàn)提供給每個視點的特別服務(wù)。視點組織：包括組織相關(guān)的視點到層次結(jié)構(gòu)中，通用的服務(wù)放在較高的層次，并被較低層次的視點繼承。視點文檔編寫：包括對被識別的視點和服務(wù)描述的精煉。視點系統(tǒng)映射：包括在面向?qū)ο笤O(shè)計中通過封裝在視點中的服務(wù)信息識別對象。4.4基于調(diào)查的需求獲取方法制定調(diào)查表可靠可信分析4.5基于場景的需求獲取方法分析員與項目相關(guān)人員共同識別出情景，并捕獲這些情景的細(xì)節(jié)把細(xì)節(jié)加入到一個綱要的需求描述中時，情景特別有用情景是對交互實例片斷的描述，每個情景可能包含一個或多個交互，它們能在不同的細(xì)節(jié)層次上提供不同類型的情景信息情景開始于一個框架，在導(dǎo)出過程中，細(xì)節(jié)被逐漸增加，直到產(chǎn)生交互的一個完整的描述情景內(nèi)容在情景開始部分有一個系統(tǒng)狀態(tài)描述；關(guān)于標(biāo)準(zhǔn)事件流的描述；關(guān)于哪兒會出錯，以及如何處理錯誤的描述；有關(guān)其他可能在同一時間進(jìn)行的活動的信息；在情景完成后系統(tǒng)狀態(tài)的描述場景名：取款參與者：銀行客戶場景描述：1．插入有效的銀行卡；2．ATM機驗證該銀行卡；3．系統(tǒng)要求輸入銀行卡密碼，用戶輸入密碼；4．系統(tǒng)通過網(wǎng)絡(luò)向銀行內(nèi)部系統(tǒng)請求驗證密碼；5．若驗證通過，系統(tǒng)請求選擇業(yè)務(wù)，選擇取款；6．系統(tǒng)要求輸入取款金額，比如1000元；7．系統(tǒng)驗證是有足夠的現(xiàn)金，并請求驗證銀行內(nèi)部服務(wù)器處理取款；8．若處理成功，系統(tǒng)計算鈔票數(shù)目，并送出現(xiàn)金；9．用戶取走現(xiàn)金；10．系統(tǒng)打印憑條，用戶取走憑條；11．系統(tǒng)退出銀行卡，用戶取走銀行卡。4.6基于用例（用況）的需求獲取方法需求捕獲的目標(biāo)：發(fā)現(xiàn)真正的需求以適用于用戶、客戶和開發(fā)人員的方式加以表示系統(tǒng)用戶表示為一個參與者參與者在與用例進(jìn)行交互時使用系統(tǒng)用例向參與者提供某些有價值結(jié)果而執(zhí)行一些動作序列用例分析過程用例建模分析開發(fā)活動圖開發(fā)泳道圖用例分析用例著眼于為用戶增加價值，提供了一種捕獲功能需求的系統(tǒng)且直觀的方法，可驅(qū)動整個開發(fā)過程。用例從某個特定參與者的角度用簡單易懂的