軟件工程基礎與案例教程 課件 第1、2部分 軟件工程基礎；結構化分析、設計與測試

軟件工程基礎與案例教程

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

Disciplined

Predictable

Immature

Mature

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

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

簡單是最根本的。

最好的構架、需求和設計出于自組織團隊。

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

993.4結對編程

(PairProgramming

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

……另一方面：

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

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

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

編程方式避免cowboy式的編程好代碼的衡量標準：可讀性和可維護性對大部分的商業(yè)項目來說，更主要的顧慮是成本。好的代碼可以減少修改的成本?；ハ喽酱倏梢蕴岣叽a的可讀性。

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

1)怕自己看上去傻

2)怕被認為是沒用的

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

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

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

公正開明勇氣

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

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

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

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

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

其中：

零件信息=零件編號+零件名稱+數(shù)量+價格+1{供應者}3

分量定義：

零件編號=8位字符；

零件名稱=20位字符；

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

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

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

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

處于空閑時，電梯移動到第一層。

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

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

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