軟件工程基礎(chǔ)與案例教程 課件 第一部分 軟件工程基礎(chǔ)(1-4)_第1頁
軟件工程基礎(chǔ)與案例教程 課件 第一部分 軟件工程基礎(chǔ)(1-4)_第2頁
軟件工程基礎(chǔ)與案例教程 課件 第一部分 軟件工程基礎(chǔ)(1-4)_第3頁
軟件工程基礎(chǔ)與案例教程 課件 第一部分 軟件工程基礎(chǔ)(1-4)_第4頁
軟件工程基礎(chǔ)與案例教程 課件 第一部分 軟件工程基礎(chǔ)(1-4)_第5頁
已閱讀5頁,還剩152頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

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

(微課視頻版)第一部分:軟件工程理論基礎(chǔ)什么是軟件工程?軟件工程的思想是什么?軟件工程有哪些基本原理和原則?軟件過程與過程模型的關(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ā)展趨勢軟件服務(wù):云服務(wù)、大數(shù)據(jù)服務(wù)多樣性:中間件開放性:新型中間件平臺1.2關(guān)于軟件工程軟件危機(jī)的出現(xiàn)問題:如何開發(fā)軟件如何維護(hù)軟件表現(xiàn):規(guī)模大、復(fù)雜度增加供需差增大價(jià)格昂貴開發(fā)速度慢質(zhì)量難以保證案例軟件危機(jī)解決途徑重視需求分析,明確與確切表達(dá)需求重視與客戶溝通與交流統(tǒng)一的、公認(rèn)的方法論和規(guī)范指導(dǎo)重視設(shè)計(jì)和實(shí)現(xiàn)過程的資料充分的檢測工作軟件工程概念軟件工程運(yùn)用現(xiàn)代科學(xué)技術(shù)知識來設(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ù)軟件工程管理原因:缺乏軟件過程控制能力能力成熟模型(CapabilityMaturityModel)體現(xiàn):工程化管理軟件工程管理1.3軟件工程基本原理與原則基本原理推遲實(shí)現(xiàn)逐步求精分解與抽象信息隱蔽質(zhì)量保證基本原則分階段的軟件開發(fā)堅(jiān)持進(jìn)行階段評審實(shí)行嚴(yán)格的產(chǎn)品控制采用先進(jìn)的程序設(shè)計(jì)技術(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è)計(jì)(SD)結(jié)構(gòu)化編程(SP)結(jié)構(gòu)化測試(ST)結(jié)構(gòu)化維護(hù)(SM)1.4軟件工程范型面向?qū)ο蠓缎吞卣鳎簩ο笠曌饕粋€(gè)融合了數(shù)據(jù)及在其上操作的行為的、統(tǒng)一的軟件組件。技術(shù)包括:面向?qū)ο蠓治觯∣OA)面向?qū)ο笤O(shè)計(jì)(OOD)面向?qū)ο缶幊蹋∣OP)面向?qū)ο鬁y試(OOT)面向?qū)ο缶S護(hù)(OOM)優(yōu)勢:對象的概念符合業(yè)務(wù)或領(lǐng)域的客觀實(shí)際維護(hù)容易1.5軟件工程基本活動(dòng)溝通計(jì)劃建模實(shí)現(xiàn)部署維護(hù)管理過程改進(jìn)小結(jié)軟件工程的是主旨以工程化的思想進(jìn)行軟件開發(fā),以生產(chǎn)高質(zhì)量和高效率的軟件。軟件工程化思想的核心是,把軟件看作是一個(gè)工程產(chǎn)品。軟件工程方法學(xué)分別是結(jié)構(gòu)化開發(fā)范型和面向?qū)ο箝_發(fā)范型。第2章軟件過程與模型內(nèi)容提要軟件生存周期軟件過程與框架軟件過程選擇與評估軟件能力成熟度模型軟件過程模型傳統(tǒng)的軟件過程模型面向?qū)ο筮^程模型2.1軟件生存周期軟件也有一個(gè)從生到死的過程,這個(gè)過程一般稱之為軟件的軟件生存周期或生命周期(SoftwareDevelopmentLifeCycle)軟件生存周期可劃分為定義、開發(fā)和運(yùn)行三個(gè)時(shí)期,每個(gè)時(shí)期又細(xì)分為若干個(gè)階段。把整個(gè)軟件生存周期劃分為若干階段,使得每個(gè)階段有明確的任務(wù),使規(guī)模大,結(jié)構(gòu)復(fù)雜和管理復(fù)雜的軟件開發(fā)變的容易控制和管理。軟件生存周期包括問題定義與可行性分析、軟件項(xiàng)目計(jì)劃、需求分析、軟件設(shè)計(jì)、實(shí)現(xiàn)與測試、運(yùn)行與維護(hù)等階段,每個(gè)階段有包含一系列的活動(dòng)。2.2軟件過程與框架定義:軟件過程是為了開發(fā)出軟件產(chǎn)品,或者是為了完成軟件工程項(xiàng)目而需要完成的有關(guān)軟件工程的活動(dòng)通常使用生存周期模型簡潔地描述軟件過程層次:軟件工程是一門建立在以質(zhì)量焦點(diǎn)為基礎(chǔ)的層次化綜合技術(shù)過程:定義階段和管理方法:技術(shù)支持工具:自動(dòng)化實(shí)施支持軟件過程框架與管理定義:框架是實(shí)現(xiàn)整個(gè)軟件開發(fā)活動(dòng)的基礎(chǔ),并且那些與過程有關(guān)的角色、職責(zé)的定義以及實(shí)現(xiàn)也都離不開框架的支持兩個(gè)方面的內(nèi)容組織及管理框架技術(shù)及工具框架軟件過程環(huán)境組織、管理的角色和職責(zé)技術(shù)環(huán)境軟件過程框架組織與管理框架:過程改進(jìn)活動(dòng)及角色與職責(zé)技術(shù)與工具框架:技術(shù)及自動(dòng)化活動(dòng)工具框架活動(dòng):溝通策劃建模構(gòu)建部署軟件過程框架包括一組普適的過程、活動(dòng)和任務(wù)。具體包括:系統(tǒng)語境的過程協(xié)議過程組(2個(gè)過程,13個(gè)活動(dòng),52個(gè)任務(wù))項(xiàng)目過程組(7個(gè)過程,23個(gè)活動(dòng),72個(gè)任務(wù))技術(shù)過程組(11個(gè)過程,26個(gè)活動(dòng),64個(gè)任務(wù))組織上項(xiàng)目使能過程組(5個(gè)過程,15個(gè)活動(dòng),48個(gè)任務(wù))針對軟件開發(fā)的過程軟件實(shí)現(xiàn)過程組(7個(gè)過程,7個(gè)活動(dòng),39個(gè)任務(wù))軟件支持過程組(8個(gè)過程,25個(gè)活動(dòng),68個(gè)任務(wù))軟件復(fù)用過程組(3個(gè)過程,14個(gè)活動(dòng),62個(gè)任務(wù))整個(gè)系統(tǒng)的生存周期包括了43個(gè)過程、123個(gè)活動(dòng)和405項(xiàng)任務(wù)。2.3軟件過程選擇與評估軟件過程選擇把軟件看成產(chǎn)品,必然注重軟件的質(zhì)量,決定了軟件過程、周期和成本。產(chǎn)品依賴過程,其就是過程定義的一系列活動(dòng)和任務(wù)的結(jié)果。軟件產(chǎn)品越復(fù)雜,其開發(fā)周期也越長,開發(fā)成本越高。當(dāng)軟件比較復(fù)雜,開發(fā)周期比較長(一般持續(xù)一年及以上),開發(fā)成本比較高時(shí),團(tuán)隊(duì)就要選擇重型軟件過程,比如螺旋模型或者統(tǒng)一過程模型等。當(dāng)軟件較為簡單或需求比較穩(wěn)定時(shí),一般開發(fā)周期也比較短(三個(gè)月以內(nèi)),開發(fā)人員也比較少(一般4-8人),這樣的軟件就可以采用輕型軟件過程,比如極限編程方法或者瀑布模型等。軟件過程評估產(chǎn)品與過程選擇軟件過程過程評估CMMI/CMMISO9001:2000個(gè)人軟件過程團(tuán)隊(duì)軟件過程個(gè)人軟件過程(PSP)PSP0是PSP的個(gè)人度量過程,其目的是建立個(gè)體過程基線。PSP1是個(gè)人規(guī)劃過程,引入了基于估計(jì)的計(jì)劃方法PROBE,用自己的歷史數(shù)據(jù)來預(yù)測新程序大小和開發(fā)時(shí)間,并使用線性回歸方法估計(jì)參數(shù),確定置信區(qū)間以評價(jià)預(yù)測的可信程度。PSP2是個(gè)人質(zhì)量管理,根據(jù)程序的缺陷建立檢測表,按照檢測表進(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ì)軟件過程(TSP)TSP采用了循環(huán)遞增的開發(fā)策略,整個(gè)軟件生產(chǎn)過程由多個(gè)循環(huán)出現(xiàn)的開發(fā)周期組成,每個(gè)開發(fā)周期劃分出若干個(gè)相對獨(dú)立的階段。TSP提供了如下方法:計(jì)劃評審設(shè)計(jì)和編碼標(biāo)準(zhǔn)設(shè)計(jì)和代碼評審方法缺陷評審質(zhì)量分析2.4軟件能力成熟度模型CMM(CapabilityMaturityModel)是指“能力成熟度模型”CMM是由美國卡內(nèi)基-梅隆大學(xué)的軟件工程研究所(SEI)開發(fā)的軟件成熟度模型。思想:管理軟件過程的方法不當(dāng)引起的問題,導(dǎo)致新軟件技術(shù)的運(yùn)用并不會(huì)自動(dòng)提高軟件的生產(chǎn)率和質(zhì)量。CMM為軟件企業(yè)的過程能力提供了一個(gè)階梯式的改進(jìn)框架,它基于過去所有軟件工程過程改進(jìn)的成果,吸取了以往軟件工程的經(jīng)驗(yàn)教訓(xùn),提供了一個(gè)基于過程改進(jìn)的框架。能力成熟度模型集成(CMMI--CapabilityMaturityModelIntegration)是CMM模型的最新版本。什么是CMM?為企業(yè)的發(fā)展規(guī)定過程成熟級別,分為5級(Version1.0):初始級(Initial):一般企業(yè)皆具有可重復(fù)級(Repeatable):成功經(jīng)驗(yàn)可以重復(fù)定義級(Defined):一套完整的企業(yè)過程,人員自覺遵守(培訓(xùn))管理級(Managed):過程&產(chǎn)品可度量和控制優(yōu)化級(Optimizing):過程持續(xù)改進(jìn)從無序到有序、從特殊到一般、從定性管理到定量管理、最終達(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)鍵過程域KPA:代表一組相關(guān)的工作(活動(dòng))。每個(gè)KPA都有一個(gè)確定的目標(biāo),完成該目標(biāo)即認(rèn)為過程能力的提高。一般特性CF(CommonFeatures):進(jìn)一步細(xì)分KPA的工作。五個(gè)特性:承諾(commitment)準(zhǔn)備(ability)執(zhí)行(activity)度量分析(measurement&analysis)驗(yàn)證(verifyingimplementation)CMM的五個(gè)級別Level1:初始級過程無序且不可見OutInCMM的五個(gè)級別Level2:可重復(fù)級Milestone可見,按計(jì)劃開發(fā)CMM的五個(gè)級別Level2的6個(gè)KPA:側(cè)重于管理需求管理(RequirementsManagement)軟件項(xiàng)目計(jì)劃(SoftwareProjectPlanning)軟件項(xiàng)目的跟蹤和監(jiān)控(SoftwareProjectTackingandOversight)軟件子合同管理(SoftwareSubcontractManagement)軟件質(zhì)量保證(SoftwareQualityAssurance)軟件配置管理(SoftwareConfigurationManagement)CMM的五個(gè)級別Level3:定義級每個(gè)階段的內(nèi)部活動(dòng)可見標(biāo)準(zhǔn)過程和項(xiàng)目定義過程裁剪CMM的五個(gè)級別Level3的7個(gè)KPA:工程過程+企業(yè)理念機(jī)構(gòu)過程關(guān)注(OrganizationProcessFocus)機(jī)構(gòu)過程定義(OrganizationProcessDefinition)培訓(xùn)計(jì)劃(TrainingProgram)集成軟件管理(IntegratedSoftwareManagement)-過程裁剪和定義軟件產(chǎn)品工程(SoftwareProductEngineering)-過程執(zhí)行組間協(xié)調(diào)(IntergroupCoordination)對等審查(PeerReviews)CMM的五個(gè)級別Level4管理級過程可度量,預(yù)測值與結(jié)果之間的偏差可控CMM的五個(gè)級別Level4的2個(gè)KPA:預(yù)測+量化管理定量過程管理(QuantitativeProcessManagement)-過程度量軟件質(zhì)量管理(SoftwareQualityManagement)-產(chǎn)品度量CMM的五個(gè)級別Level5優(yōu)化級過程動(dòng)態(tài)調(diào)整、新技術(shù)的采用CMM的五個(gè)級別Level5的3個(gè)KPA:動(dòng)態(tài)優(yōu)化缺陷預(yù)防(DefectPrevention)技術(shù)改變管理(TechnologyChangeManagement)過程改變管理(ProcessChangeManagement)能力成熟度模型集成CMMI--CapabilityMaturityModelIntegration是CMM模型的最新版本。CMMI有兩種表示方法:和軟件CMM一樣的階段式表現(xiàn)方法連續(xù)式的表現(xiàn)方法過程管理項(xiàng)目管理工程支持CMMI的目標(biāo)是質(zhì)量、時(shí)間表和最低的成本關(guān)鍵實(shí)踐CMM結(jié)構(gòu)CMM標(biāo)準(zhǔn)的使用軟件過程的改進(jìn)(SPI,SoftwareProcessImprovement)軟件過程評估(SPA,SoftwareProcessAssessment)軟件能力評價(jià)(SCESoftwareCapabilityEvaluation)2.5軟件過程模型把軟件生命周期中各項(xiàng)開發(fā)活動(dòng)的流程用一個(gè)合理的框架—開發(fā)模型來規(guī)范描述,這就是軟件過程模型,也稱為軟件生命周期模型.軟件過程模型是一種就是軟件過程抽象.軟件過程模型是從一個(gè)特定的角度表現(xiàn)一個(gè)過程,一般使用直觀的圖形標(biāo)識軟件開發(fā)的過程,主要根據(jù)軟件的類型、規(guī)模,特別是軟件的開發(fā)方法、開發(fā)環(huán)境等多種因素確立過程模型。2.6傳統(tǒng)的軟件過程模型瀑布模型增量模型螺旋模型瀑布模型瀑布模型將軟件生命周期劃分為軟件計(jì)劃、需求分析和定義、設(shè)計(jì)、實(shí)現(xiàn)、測試、運(yùn)行和維護(hù)這6個(gè)階段,規(guī)定了它們自上而下、相互銜接的固定次序,如同瀑布流水逐級下落。從本質(zhì)來講,它是一個(gè)軟件開發(fā)架構(gòu),開發(fā)過程是通過一系列階段順序展開的,從系統(tǒng)需求分析開始直到產(chǎn)品發(fā)布和維護(hù),每個(gè)階段都會(huì)產(chǎn)生循環(huán)反饋.瀑布模型示意圖瀑布模型它是一個(gè)軟件開發(fā)架構(gòu),開發(fā)過程是通過一系列階段順序展開的。每個(gè)階段都會(huì)產(chǎn)生循環(huán)反饋各個(gè)階段產(chǎn)生的文檔是維護(hù)軟件產(chǎn)品時(shí)必不可少的,沒有文檔的軟件幾乎是不可能維護(hù)的。瀑布模型是一種文檔驅(qū)動(dòng)的過程模型瀑布模型特點(diǎn)順序性和依賴性推遲實(shí)現(xiàn)質(zhì)量保證的觀點(diǎn)是一種線性模型強(qiáng)調(diào)文檔的作用增量模型增量模型(IncrementalModel)也稱為漸增模型,是在項(xiàng)目的開發(fā)過程中以一系列的增量方式開發(fā)系統(tǒng)。軟件被作為一系列的增量構(gòu)件來設(shè)計(jì)、實(shí)現(xiàn)、集成和測試,每一個(gè)構(gòu)件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構(gòu)成.增量方式包括:增量開發(fā):以一定的時(shí)間間隔開發(fā)部分工作軟件增量提交:以一定的時(shí)間間隔增量方式向用戶提交工作軟件及相應(yīng)文檔增量模型融合了線性順序模型的基本成份和原型實(shí)現(xiàn)模型的迭代特征。增量模型分為漸增模型和原型模型漸增模型是瀑布模型的變種,有兩類漸增模型:增量構(gòu)造模型:它在瀑布模型基礎(chǔ)上,對一些階段進(jìn)行整體開發(fā),對另一些階段進(jìn)行增量開發(fā)。前面的開發(fā)階段按瀑布模型進(jìn)行整體開發(fā),后面的開發(fā)階段按增量提交。演化提交模型:它在瀑布模型的基礎(chǔ)上,所有階段都進(jìn)行增量開發(fā),也就是說不僅是增量開發(fā),也是增量提交。增量構(gòu)造模型需求分析設(shè)計(jì)編碼1測試1測試2編碼2編碼3測試3螺旋模型螺旋模型(SpiralModel)是結(jié)合了瀑布模型和快速原型模型的迭代開發(fā)模型強(qiáng)調(diào)了其他模型均忽略了的風(fēng)險(xiǎn)分析:風(fēng)險(xiǎn)識別風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)控制特別適合于大型復(fù)雜的系統(tǒng)每一個(gè)周期都包括需求定義、風(fēng)險(xiǎn)分析、工程實(shí)現(xiàn)和評審螺旋模型示意圖螺旋模型活動(dòng)四個(gè)象限分別代表了以下活動(dòng):制定計(jì)劃:確定軟件目標(biāo),選定實(shí)施方案,確定項(xiàng)目開發(fā)的限制條件;風(fēng)險(xiǎn)分析:分析評估所選方案,考慮如何識別和消除風(fēng)險(xiǎn);實(shí)施工程:實(shí)施軟件開發(fā)和驗(yàn)證;客戶評估:評價(jià)開發(fā)工作,提出修正建議,制定下一步計(jì)劃。螺旋模型是風(fēng)險(xiǎn)驅(qū)動(dòng)的模型2.7面向?qū)ο筮^程模型面向?qū)ο笫且环N的程序設(shè)計(jì)方法,或者說它是一種程序設(shè)計(jì)范型?;舅枷胧鞘褂脤ο螅?,繼承,封裝,消息等基本概念來進(jìn)行程序設(shè)計(jì)。面向?qū)ο蟮囊兀撼橄螅簭?qiáng)調(diào)實(shí)體的本質(zhì)、內(nèi)在的屬性,忽略一些無關(guān)緊要的屬性。類實(shí)現(xiàn)了對象的數(shù)據(jù)(即狀態(tài))和行為的抽象,是對象的共性的抽象。封裝性:指所有軟件部件內(nèi)部都有明確的范圍以及清楚的外部邊界。共享性:面向?qū)ο蟮奶卣鳎簩ο笪┮恍?;分類性;繼承性;多態(tài)性(多形性)。構(gòu)件集成模型構(gòu)件集成模型是基于構(gòu)件的開發(fā)模型構(gòu)件集成模型:整個(gè)系統(tǒng)模塊化復(fù)用構(gòu)件庫中的軟件構(gòu)件構(gòu)件集成模型是演化形的,開發(fā)過程是迭代的5個(gè)階段:軟件的需求分析和定義體系結(jié)構(gòu)設(shè)計(jì)構(gòu)件庫建立應(yīng)用軟件構(gòu)建測試和發(fā)布構(gòu)件集成模型需求分析和定義體系結(jié)構(gòu)設(shè)計(jì)構(gòu)件庫建立測試和發(fā)布應(yīng)用軟件構(gòu)建1:N統(tǒng)一過程Asoftwaredevelopmentprocess:是一個(gè)將用戶需求轉(zhuǎn)化為軟件系統(tǒng)所需要的活動(dòng)的集合。Aprocessframework:一個(gè)簡單的過程,也是一個(gè)通用的過程框架。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ū)動(dòng)的用況模型(usecasemodel)要素:用戶(user)用況(usecase)動(dòng)作(action)用況驅(qū)動(dòng)(use-casedriven):用況可以驅(qū)動(dòng)開發(fā)過程:用況不只是確定系統(tǒng)需求的工具,還能驅(qū)動(dòng)系統(tǒng)設(shè)計(jì)、實(shí)現(xiàn)和測試的進(jìn)行。不能孤立地選擇用況統(tǒng)一過程是以構(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ì)過程可以幫助構(gòu)架設(shè)計(jì)師確定正確的目標(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è)計(jì)師應(yīng)遵循的四個(gè)步驟:針對通用用況,創(chuàng)建一個(gè)粗略的構(gòu)架輪廓處理已經(jīng)確定的重要用況子集用況完善繼續(xù)上述過程…統(tǒng)一過程是迭代和增量的劃分為袖珍項(xiàng)目(mini-project):一個(gè)增量的迭代過程迭代是指工作流中的步驟,迭代過程必須是受控的目標(biāo):處理一組過程,風(fēng)險(xiǎn)分析做法:標(biāo)識與描述用況選定構(gòu)架創(chuàng)建設(shè)計(jì)選擇構(gòu)件實(shí)現(xiàn)設(shè)計(jì)驗(yàn)證PhasesintheSoftwareLifecycleTheUnifiedProcesshasfourphases:Inception—DefiningthescopeoftheprojectElaboration—Planning,specifyingfeaturesanddesigningarchitectureConstruction—BuildingtheproductTransition—TransitioningtheproductintoitsusercommunitytimeInceptionElaborationConstructionTransitionMajormilestones統(tǒng)一過程模型統(tǒng)一過程(UnifiedProcess,UP)是風(fēng)險(xiǎn)驅(qū)動(dòng)的、基于用況技術(shù)的、以架構(gòu)為中心的、迭代的、可配置的軟件開發(fā)流程。統(tǒng)一過程是以用況驅(qū)動(dòng)的,以構(gòu)架為中心,迭代和增量的過程。統(tǒng)一過程是一個(gè)軟件開發(fā)過程,是一個(gè)通用的過程框架:初始細(xì)化構(gòu)造移交統(tǒng)一過程的四個(gè)階段統(tǒng)一過程五個(gè)核心工作流需求捕獲(RequirementsCapture):致力于開發(fā)正確的系統(tǒng)分析(Analysis):更精確地理解需求設(shè)計(jì)(Design):深入理解與非功能性需求和約束相聯(lián)系的問題實(shí)現(xiàn)(Implementation):實(shí)現(xiàn)系統(tǒng)與集成測試(Test):驗(yàn)證實(shí)現(xiàn)的結(jié)構(gòu)核心工作流軟件開發(fā)的四個(gè)要素人員項(xiàng)目產(chǎn)品過程人員至關(guān)重要開發(fā)過程影響人員角色會(huì)發(fā)生變化角色實(shí)例項(xiàng)目創(chuàng)造產(chǎn)品三要素:一系列變化一系列迭代組織模式產(chǎn)品不僅僅是代碼軟件系統(tǒng)制品系統(tǒng)包含一組模型什么是模型?視圖模型內(nèi)部模型間的關(guān)系過程指導(dǎo)項(xiàng)目過程:一個(gè)模板過程過程實(shí)例軟件開發(fā)過程工作流過程具體化過程的價(jià)值工具用況驅(qū)動(dòng)開發(fā)統(tǒng)一過程的目標(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í)施模型測試模型小結(jié)大多數(shù)軟件開發(fā)過程都有一個(gè)共同的軟件過程框架軟件開發(fā)模型是指軟件開發(fā)全部過程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架,表達(dá)軟件開發(fā)全過程,規(guī)定了要完成的主要活動(dòng)和任務(wù),用來作為軟件項(xiàng)目工作的基礎(chǔ)。軟件過程分為個(gè)人軟件過程PSP和團(tuán)隊(duì)軟件過程TSP。CMM為軟件企業(yè)的過程能力提供了一個(gè)階梯式的改進(jìn)框架,包括初始級、可重復(fù)級、已定義級、可管理級和優(yōu)化級5個(gè)級別。軟件過程模型的選擇取決于軟件的特性和開發(fā)團(tuán)隊(duì)的特性。對于開發(fā)大型復(fù)雜的軟件,建議采用重型軟件過程模型,如螺旋模型、統(tǒng)一過程模型等;對于需求穩(wěn)定或簡單的軟件,建議采用輕型軟件過程模型,如極限編程、瀑布模型等。第3章敏捷軟件工程方法內(nèi)容提要:敏捷軟件工程過程SCRUM軟件開發(fā)過程極限編程結(jié)對編程3.1敏捷軟件工程過程敏捷不是一個(gè)過程,是一類過程的統(tǒng)稱。敏捷方法的兩大主要特征:對“適應(yīng)性”的強(qiáng)調(diào)對“人”的關(guān)注做法:快速響應(yīng):引入迭代式的開發(fā)手段將整個(gè)軟件生命周期分解為若干個(gè)小的迭代周期獲取切實(shí)有效的客戶反饋提出12條基本原則敏捷開發(fā)12條原則我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價(jià)值的軟件來使客戶滿意。即使到了開發(fā)的后期,也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。

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

簡單是最根本的。

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

每隔一定時(shí)間,團(tuán)隊(duì)會(huì)在如何才能更有效地工作方面進(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)意、嘗試錯(cuò)誤,所以沒有一種固定的流程可以保證方案成功。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ù)語訂單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ì)議沖刺評審會(huì)Sprintreview會(huì)議沖刺反思會(huì)Sprintretrospective會(huì)議實(shí)施Scrum的過程分解產(chǎn)品訂單成沖刺訂單召開沖刺計(jì)劃會(huì)議進(jìn)入沖刺開發(fā)周期,每天需要召開立會(huì)整個(gè)沖刺周期結(jié)束,召開沖刺評審會(huì)團(tuán)隊(duì)召開沖刺反思會(huì)。。。以上循環(huán)進(jìn)行Scrum文檔產(chǎn)品訂單文檔沖刺訂單文檔燃盡圖3.3極限編程極限編程(eXtremeProgramming,XP)是一種軟件工程方法學(xué),是敏捷開發(fā)中最富有成效的方法學(xué)之一由KentBeck在1996年提出具有強(qiáng)溝通、簡化設(shè)計(jì)、迅速反饋等特點(diǎn)適合于規(guī)模小、進(jìn)度緊、需求不穩(wěn)定、開發(fā)小項(xiàng)目的小團(tuán)隊(duì)。極限編程特點(diǎn):XP模型是“輕量型”或“靈活”的軟件過程模型與面向?qū)ο笳Z言結(jié)合的開發(fā)方案“專家協(xié)作”的開發(fā)方式,解決難點(diǎn)問題重視客戶反饋核心有四個(gè)要點(diǎn):交流簡單反饋勇氣交流開發(fā)人員與客戶的交流開發(fā)人員之間的交流使用結(jié)對編程開發(fā)人員與管理人員的交流簡單設(shè)計(jì)的簡單編碼的簡單注釋的簡單測試的簡單反饋客戶對軟件的反饋測試代碼對功能代碼的反饋先測試,后編程勇氣接受任務(wù)的勇氣XP常見問題XP適合于小型項(xiàng)目(10人左右)?結(jié)對編程,搭檔如何安排?實(shí)施結(jié)對編程、集體代碼所有權(quán)之后,如何考核單個(gè)開發(fā)人員?

993.4結(jié)對編程

(PairProgramming

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

……另一方面:

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

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

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

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

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

1)怕自己看上去傻

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

3)怕自己變的不重要(過時(shí))

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

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

公正開明勇氣

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

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

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

需求獲取內(nèi)容提要關(guān)于用戶需求和軟件需求需求獲取過程基于會(huì)談的需求獲取方法基于調(diào)查的需求獲取方法基于場景的需求獲取方法基于用例的需求獲取方法4.1關(guān)于用戶需求和軟件需求用戶需求:業(yè)務(wù)需求與源于系統(tǒng)的特定領(lǐng)域的需求用戶需求是站在用戶角度描述軟件必須要完成的業(yè)務(wù)需求,通過使用實(shí)例文檔或場景說明中予以詳細(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)用戶界面將一些文檔輸出到本地打印機(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需求獲取過程需求獲取主要是理解客戶需要什么、分析要求、評價(jià)可行性、協(xié)商合理的方案、無歧義地詳細(xì)說明方案、確認(rèn)規(guī)格說明、管理需求以至將這些需求轉(zhuǎn)化為可行系統(tǒng).過程包括:溝通導(dǎo)出需求精化需求可行性研究與客戶和用戶協(xié)商編寫需求規(guī)格說明驗(yàn)證需求管理需求溝通業(yè)務(wù)領(lǐng)域的共利益者(如業(yè)務(wù)管理人員,市場營銷人員,產(chǎn)品管理人員)定義業(yè)務(wù)用例確定市場的范圍初略地可行性分析確定項(xiàng)目范圍的工作說明導(dǎo)出需求導(dǎo)出需求應(yīng)理解問題范圍問題:系統(tǒng)的邊界,是客戶和開發(fā)者共同關(guān)心的部分理解問題:確定業(yè)務(wù)需求、需求沖突、說明有歧義和不可測試的需求易變問題:分清需求穩(wěn)定部分和易變部分收集活動(dòng):識別真正的客戶/用戶正確理解客戶的需求耐心聽取客戶意見和思考盡量使用符合客戶語言習(xí)慣的表達(dá)精化需求開發(fā)一個(gè)精確的技術(shù)模型,用以說明軟件的功能、特征和約束。精化是一個(gè)分析建模動(dòng)作,由一系列建模和求精任務(wù)構(gòu)成定義了問題的信息域,功能域和行為域可行性研究可行性研究的目的是確定用最小的代價(jià),在盡可能短的時(shí)間內(nèi)確定問題是否能夠解決可行性研究的輸入是系統(tǒng)的一個(gè)框架描述和高層邏輯模型輸出是一份需求開發(fā)評價(jià)報(bào)告,對需求工程和系統(tǒng)開發(fā)是否值得做的具體建議和意見三個(gè)問題:系統(tǒng)是否符合機(jī)構(gòu)的總體要求?系統(tǒng)是否可以在現(xiàn)有的技術(shù)條件、預(yù)算和時(shí)間限制內(nèi)完成?系統(tǒng)能否把已存在的其他系統(tǒng)集成?與客戶和用戶協(xié)商調(diào)節(jié)沖突和問題需求排序識別和分析與每項(xiàng)需求相關(guān)的風(fēng)險(xiǎn)、開發(fā)工作量、成本和交付時(shí)間編寫軟件需求規(guī)格說明一個(gè)規(guī)格說明可以是一份寫好的文檔、一套圖形化的模型、一個(gè)形式化的數(shù)學(xué)模型、一組使用場景、一個(gè)原型或以上各項(xiàng)的任意組合。軟件需求規(guī)格(SRS,SoftwareRequirementSpecification)是需求分析任務(wù)的最終“產(chǎn)品”,它是客戶、管理者、分析工程師、測試工程師、維護(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ù)語和縮寫詞)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ù)庫描述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其他需求(檢測或驗(yàn)收標(biāo)準(zhǔn)、可用性、可維護(hù)性可移植性、安全保密性)驗(yàn)證需求驗(yàn)需求證對需求文檔和制品進(jìn)行質(zhì)量評估,確保需求說明準(zhǔn)確、完整.包括以下內(nèi)容:正確性一致性完整性可行性必要性可檢驗(yàn)性需求的可跟蹤性最后簽字確認(rèn)管理需求管理需求是組織、控制和文檔化需求的系統(tǒng)方法.建立基線以便在客戶和開發(fā)人員之間構(gòu)建一個(gè)約定.需求管理從標(biāo)識開始,建立跟蹤表.需求跟蹤表可以跟蹤需求的特征、來源、依賴、子系統(tǒng)和接口等關(guān)系.4.3基于會(huì)談的需求獲取方法非正式會(huì)談:提出一些可自由回答的問題.正式會(huì)談:提出一些事先準(zhǔn)備好的議題.情景分析:需求分析從對場景的評論中得到信息,然后再將其以形式化方式表示出來。使用用例建立原型界面序列執(zhí)行過程視點(diǎn)分析接受系統(tǒng)服務(wù)的當(dāng)前銀行客戶;銀行間自動(dòng)柜員機(jī)有互惠協(xié)議的其他銀行的代表;從該系統(tǒng)中獲得管理信息的銀行支行管理者;負(fù)責(zé)系統(tǒng)日常運(yùn)轉(zhuǎn)和處理客戶意見的支行柜臺職員;負(fù)責(zé)系統(tǒng)和客戶數(shù)據(jù)庫集成的數(shù)據(jù)庫管理者;負(fù)責(zé)保證系統(tǒng)信息安全的銀行信息安全管理者;將該系統(tǒng)視為銀行市場開拓手段的銀行市場開發(fā)部;負(fù)責(zé)硬件和軟件維護(hù)及升級的硬件和軟件維護(hù)工程師多視點(diǎn)的需求分析過程視點(diǎn)識別:包括發(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)文檔編寫:包括對被識別的視點(diǎn)和服務(wù)描述的精煉。視點(diǎn)系統(tǒng)映射:包括在面向?qū)ο笤O(shè)計(jì)中通過封裝在視點(diǎn)中的服務(wù)信息識別對象。4.4基于調(diào)查的需求獲取方法制定調(diào)查表可靠可信分析4.5基于場景的需求獲取方法分析員與項(xiàng)目相關(guān)人員共同識別出情景,并捕獲這些情景的細(xì)節(jié)把細(xì)節(jié)加入到一個(gè)綱要的需求描述中時(shí),情景特別有用情景是對交互實(shí)例片斷的描述,每個(gè)情景可能包含一個(gè)或多個(gè)交互,它們能在不同的細(xì)節(jié)層次上提供不同類型的情景信息情景開始于一個(gè)框架,在導(dǎo)出過程中,細(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)的描述場景名:取款參與者:銀行客戶場景描述:1.插入有效的銀行卡;2.ATM機(jī)驗(yàn)證該銀行卡;3.系統(tǒng)要求輸入銀行卡密碼,用戶輸入密碼;4.系統(tǒng)通過網(wǎng)絡(luò)向銀行內(nèi)部系統(tǒng)請求驗(yàn)證密碼;5.若驗(yàn)證通過,系統(tǒng)請求選擇業(yè)務(wù),選擇取款;6.系統(tǒng)要求輸入取款金額,比如1000元;7.系統(tǒng)驗(yàn)證是有足夠的現(xiàn)金,并請求驗(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)作序列用例分析過程用例建模分析開發(fā)活動(dòng)圖開發(fā)泳道圖用例分析用例著眼于為用戶增加價(jià)值,提供了一種捕獲功能需求的系統(tǒng)且直觀的方法,可驅(qū)動(dòng)整個(gè)開發(fā)過程。用例從某個(gè)特定參與者的角度用簡單易懂的

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論