版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)
文檔簡介
軟件工程基礎(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)軟件危機(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ù)雜度增加供需差增大價格昂貴開發(fā)速度慢質(zhì)量難以保證案例軟件危機(jī)解決途徑重視需求分析,明確與確切表達(dá)需求重視與客戶溝通與交流統(tǒng)一的、公認(rèn)的方法論和規(guī)范指導(dǎo)重視設(shè)計和實現(xiàn)過程的資料充分的檢測工作軟件工程概念軟件工程運用現(xiàn)代科學(xué)技術(shù)知識來設(shè)計并構(gòu)造計算機(jī)程序及為開發(fā)、運行和維護(hù)這些程序所必須的相關(guān)文件資料。軟件工程是為了經(jīng)濟(jì)地獲得能夠在實際機(jī)器上有效運行的可靠軟件而建立和使用的一系列完善的工程化原則。軟件工程是開發(fā)、運行、維護(hù)和修復(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)化維護(hù)(SM)1.4軟件工程范型面向?qū)ο蠓缎吞卣鳎簩ο笠曌饕粋€融合了數(shù)據(jù)及在其上操作的行為的、統(tǒng)一的軟件組件。技術(shù)包括:面向?qū)ο蠓治觯∣OA)面向?qū)ο笤O(shè)計(OOD)面向?qū)ο缶幊蹋∣OP)面向?qū)ο鬁y試(OOT)面向?qū)ο缶S護(hù)(OOM)優(yōu)勢:對象的概念符合業(yè)務(wù)或領(lǐng)域的客觀實際維護(hù)容易1.5軟件工程基本活動溝通計劃建模實現(xiàn)部署維護(hù)管理過程改進(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)與測試、運行與維護(hù)等階段,每個階段有包含一系列的活動。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ā)成本比較高時,團(tuán)隊就要選擇重型軟件過程,比如螺旋模型或者統(tǒng)一過程模型等。當(dāng)軟件較為簡單或需求比較穩(wěn)定時,一般開發(fā)周期也比較短(三個月以內(nèi)),開發(fā)人員也比較少(一般4-8人),這樣的軟件就可以采用輕型軟件過程,比如極限編程方法或者瀑布模型等。軟件過程評估產(chǎn)品與過程選擇軟件過程過程評估CMMI/CMMISO9001:2000個人軟件過程團(tuán)隊軟件過程個人軟件過程(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ì)量,延伸到大型程序。團(tuán)隊軟件過程(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è)理念機(jī)構(gòu)過程關(guān)注(OrganizationProcessFocus)機(jī)構(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)、測試、運行和維護(hù)這6個階段,規(guī)定了它們自上而下、相互銜接的固定次序,如同瀑布流水逐級下落。從本質(zhì)來講,它是一個軟件開發(fā)架構(gòu),開發(fā)過程是通過一系列階段順序展開的,從系統(tǒng)需求分析開始直到產(chǎn)品發(fā)布和維護(hù),每個階段都會產(chǎn)生循環(huán)反饋.瀑布模型示意圖瀑布模型它是一個軟件開發(fā)架構(gòu),開發(fā)過程是通過一系列階段順序展開的。每個階段都會產(chǎn)生循環(huán)反饋各個階段產(chǎn)生的文檔是維護(hù)軟件產(chǎn)品時必不可少的,沒有文檔的軟件幾乎是不可能維護(hù)的。瀑布模型是一種文檔驅(qū)動的過程模型瀑布模型特點順序性和依賴性推遲實現(xiàn)質(zhì)量保證的觀點是一種線性模型強(qiáng)調(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ā)模型強(qiáng)調(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ū)ο蟮囊兀撼橄螅簭?qiáng)調(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和團(tuán)隊軟件過程TSP。CMM為軟件企業(yè)的過程能力提供了一個階梯式的改進(jìn)框架,包括初始級、可重復(fù)級、已定義級、可管理級和優(yōu)化級5個級別。軟件過程模型的選擇取決于軟件的特性和開發(fā)團(tuán)隊的特性。對于開發(fā)大型復(fù)雜的軟件,建議采用重型軟件過程模型,如螺旋模型、統(tǒng)一過程模型等;對于需求穩(wěn)定或簡單的軟件,建議采用輕型軟件過程模型,如極限編程、瀑布模型等。第3章敏捷軟件工程方法內(nèi)容提要:敏捷軟件工程過程SCRUM軟件開發(fā)過程極限編程結(jié)對編程3.1敏捷軟件工程過程敏捷不是一個過程,是一類過程的統(tǒng)稱。敏捷方法的兩大主要特征:對“適應(yīng)性”的強(qiá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ù))在團(tuán)隊內(nèi)部,最具有效果并富有效率的傳遞信息的方法,就是面對面的交談。工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)。敏捷過程提倡可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強(qiáng)敏捷能力。
簡單是最根本的。
最好的構(gòu)架、需求和設(shè)計出于自組織團(tuán)隊。
每隔一定時間,團(tuán)隊會在如何才能更有效地工作方面進(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ā)團(tuán)隊Scrum術(shù)語訂單backlog:可以預(yù)知的所有任務(wù),包括功能性的和非功能性的所有任務(wù)。沖刺sprint:一次跌代開發(fā)的時間周期。沖刺訂單sprintbacklog:一個sprint周期內(nèi)所需要完成的任務(wù)。主管scrumMaster:負(fù)責(zé)監(jiān)督整個Scrum進(jìn)程,修訂計劃的一個團(tuán)隊成員。時間盒time-box:一個用于開會時間段。沖刺計劃會sprintplanning會議每日立會DailyScrum會議沖刺評審會Sprintreview會議沖刺反思會Sprintretrospective會議實施Scrum的過程分解產(chǎn)品訂單成沖刺訂單召開沖刺計劃會議進(jìn)入沖刺開發(fā)周期,每天需要召開立會整個沖刺周期結(jié)束,召開沖刺評審會團(tuán)隊召開沖刺反思會。。。以上循環(huán)進(jìn)行Scrum文檔產(chǎn)品訂單文檔沖刺訂單文檔燃盡圖3.3極限編程極限編程(eXtremeProgramming,XP)是一種軟件工程方法學(xué),是敏捷開發(fā)中最富有成效的方法學(xué)之一由KentBeck在1996年提出具有強(qiáng)溝通、簡化設(shè)計、迅速反饋等特點適合于規(guī)模小、進(jìn)度緊、需求不穩(wěn)定、開發(fā)小項目的小團(tuán)隊。極限編程特點: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中非常重要的實踐之一。定義:兩個人坐在同一臺計算機(jī)前面,使用相同的鍵盤和鼠標(biāo)來開發(fā)同樣的一個模塊,一個稱為駕駛者(Driver),負(fù)責(zé)代碼的鍵入,另外一個稱為領(lǐng)航員(Navigator),負(fù)責(zé)監(jiān)看與決策,包括低級錯誤和方向性的錯誤。當(dāng)出現(xiàn)的一個問題對其中一個人來說,難以解決,而恰好是另外一個人的強(qiáng)項的時候,那么角色就會發(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):可讀性和可維護(hù)性對大部分的商業(yè)項目來說,更主要的顧慮是成本。好的代碼可以減少修改的成本?;ハ喽酱倏梢蕴岣叽a的可讀性。
以人為本同伴的潛在壓力(PeerPressure)。PairProgramming的過程也是一個互相督促的過程。由于這種督促的壓力,使得程序員更認(rèn)真的工作。每個人每天的有效工作時段不超過3-4個小時。PairProgramming中Driver和Navigator的互換可以讓程序員輪流工作,從而避免出現(xiàn)過度思考而導(dǎo)致觀察力和判斷力出現(xiàn)偏差。潛意識的有利競爭。當(dāng)人在一個團(tuán)隊中工作,總是下意識的努力展現(xiàn)自己的優(yōu)點。工作及時得到同伴的肯定,自信心和成就感(Self-Satisfaction)增強(qiáng)。覺得工作是一件愉快(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如何增強(qiáng)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)險可以使團(tuán)隊生產(chǎn)效率更高是知識傳播的最好途徑可以打造出最佳的合作團(tuá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)用戶界面將一些文檔輸出到本地打印機(jī)或網(wǎng)絡(luò)打印機(jī)上,但因為版權(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)是否符合機(jī)構(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)品”,它是客戶、管理者、分析工程師、測試工程師、維護(hù)工程師交流的標(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)、可用性、可維護(hù)性可移植性、安全保密性)驗證需求驗需求證對需求文檔和制品進(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)前銀行客戶;銀行間自動柜員機(jī)有互惠協(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é)硬件和軟件維護(hù)及升級的硬件和軟件維護(hù)工程師多視點的需求分析過程視點識別:包括發(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機(jī)驗證該銀行卡;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ā)過程。用例從某個特定參與者的角度用簡單易懂的語言說明一個特定的使用場景。要開始開發(fā)用例,應(yīng)列出特定參與者執(zhí)行的功能或者活動。用例模型幫助客戶、用戶和開發(fā)人員在如何使用系統(tǒng)方面達(dá)成共識。用例圖描述部分用例模型,顯示帶有聯(lián)系的用例和參與者的集合POS機(jī)系統(tǒng)用例建模POS機(jī)系統(tǒng)是電子收款機(jī)系統(tǒng),通過計算機(jī)化用于處理銷售和支付,記錄銷售信息。該系統(tǒng)包括計算機(jī)、條碼掃描儀、現(xiàn)金抽屜等硬件,以及使系統(tǒng)運轉(zhuǎn)的軟件和為不同服務(wù)的應(yīng)用程序提供接口。POS機(jī)系統(tǒng)為例說明用例建模分析過程。POS機(jī)系統(tǒng)的問題描述收銀員可以記錄銷售商品信息,系統(tǒng)計算總價。收銀員能夠通過系統(tǒng)處理支付,包括現(xiàn)金支付、信用卡支付和支票支付。經(jīng)理還能處理顧客退貨。系統(tǒng)要求具有一定的容錯性,即如果遠(yuǎn)程服務(wù)(如庫存系統(tǒng))暫時中斷,系統(tǒng)必須仍然能夠獲取銷售信息并且至少能夠處理現(xiàn)金付款。POS機(jī)必須支持日益增多的各種的客戶終端和接口,比如多種形式的用戶圖形界面、觸摸屏輸入、無線PDA等。系統(tǒng)需要一種機(jī)制提供靈活的處理不同客戶獨特的業(yè)務(wù)邏輯規(guī)則和定制能力。POS機(jī)系統(tǒng)部分用例圖用例圖用例圖包括:參與者、用例、關(guān)聯(lián)和邊界四個要素。參與者:用小人形表示用例:用橢圓表示關(guān)聯(lián):用直線表示說明參與者驅(qū)動某個用例邊界:用矩形框表示,說明系統(tǒng)關(guān)注點。開發(fā)用例用例使用非正式的描述性風(fēng)格編寫,也可以使用某個結(jié)構(gòu)化的格式編寫,有些格式更強(qiáng)調(diào)描述的直觀性。用例不同部分說明用例名稱以動詞開始描述用例名稱范圍要設(shè)計的系統(tǒng)級別“用戶目標(biāo)”或者是“子功能”主要參與者調(diào)用系統(tǒng),使之交付服務(wù)渋眾及其關(guān)注點關(guān)注該用例的人,及其需要前置條件開始前必須為真的條件成功保證成功完成必須滿足的條件主成功場景典型的、無條件的、理想方式的成功場景擴(kuò)展成功或失敗的替代場景特殊需求相關(guān)的非功能性需求技術(shù)和數(shù)據(jù)變元素不同的I/O方法和數(shù)據(jù)格式發(fā)生頻率影響對實現(xiàn)的調(diào)查、測試和時間安排雜項未決問題等用例場景用例名稱:處理一次銷售范圍:POS機(jī)應(yīng)用級別:用戶目標(biāo)主要參與者:收銀員涉眾及其關(guān)注點:收銀員:希望能夠準(zhǔn)確、快速地輸入,而且沒有支付錯誤,因為如果少收貨款,將從其薪水眾扣除。售貨員:希望自動更新銷售提成顧客:希望以最小代價完成購買活動并得到快速服務(wù)。希望便捷、清晰地看到所輸入的商品項目和價格。希望得到購買憑證,以便退貨。公司:希望準(zhǔn)確地記錄交易,滿足顧客要求。希望確保記錄了支付授權(quán)服務(wù)的支付票據(jù)。希望有一定的容錯性,即便在某些服務(wù)器構(gòu)件不可用時(如遠(yuǎn)程信用卡驗證),也能夠完成銷售。希望能夠自動、快速地更新帳戶和庫存信息。經(jīng)理:希望能夠快速執(zhí)行超控操作,并易于更正收銀員的不當(dāng)操作。前置條件:收銀員必須經(jīng)過確認(rèn)和認(rèn)證。成功保證(或后置條件):存儲銷售信息,更新帳戶和庫存信息,記錄提成,生成票據(jù),記錄支付授權(quán)的批準(zhǔn)。主成功場景1.顧客攜帶所購商品或服務(wù)到收銀臺通過POS機(jī)付款。2.收銀員開始一次新的銷售交易。3.收銀員輸入商品條碼。4.系統(tǒng)逐步記錄出售的商品,并顯示該商品的描述、價格和累計額。價格通過一組價格規(guī)則來計算。收銀員重復(fù)3~~4步,直到輸入結(jié)束。5.系統(tǒng)顯示總額和計算折扣。6.收銀員告知顧客總額,并請顧客付款。7.顧客付款,系統(tǒng)處理支付。8.系統(tǒng)記錄完整的銷售信息,并將銷售和支付信息發(fā)送到外部的賬務(wù)系統(tǒng)(進(jìn)行賬務(wù)處理和提成)和庫存系統(tǒng)(更新庫存)。9.系統(tǒng)打印票據(jù)。10.顧客攜帶商品和票據(jù)離開。開發(fā)活動圖UML活動圖通過提供特定的場景內(nèi)交流的圖形化表示來補(bǔ)充用例。活動圖符號:兩端為半圓形的矩形表示一個特定的系統(tǒng)功能箭頭表示通過系統(tǒng)的流判定菱形表示判定分支水平線、分叉點和連接表示并發(fā)活動對象節(jié)點表示活動對象活動圖通常能夠既表示控制流又表示數(shù)據(jù)流。UML活動圖代替?zhèn)鹘y(tǒng)的數(shù)據(jù)流圖(DataFlowDiagram)表示法處理銷售用例活動圖泳道圖UML泳道圖(swimlane)是活動圖的一種有用的變形可以讓建模人員表示用例所描述的活動圖,同時看哪個參與者或分析類對活動矩形所描述的活動負(fù)責(zé)。泳道用縱向分割圖的并列條形部分表示,就像游泳池中的泳道,也稱特定分區(qū)。UML泳道圖通常對于涉及眾多參與者的非常復(fù)雜的業(yè)務(wù)過程建模具有價值。泳道圖小結(jié)需求分析也稱為需求工程,是一個非常重要而有很復(fù)雜的,需要交替進(jìn)行,反復(fù)迭代的過程。從用戶角度看,需求分為業(yè)務(wù)需求和用戶需求,從軟件角度看,需求分為功能需求和非功能需求。需求分析過程分為溝通、導(dǎo)出需求、精化需求、可行性研究、與客戶和用戶協(xié)商、編寫規(guī)格說明、驗證需求和管理需求等活動。需求獲取方法主要包括會談、調(diào)查表、場景分析和用例分析等。用例建模根據(jù)外部使用者從使用系統(tǒng)或業(yè)務(wù)分析出發(fā),抽取出系統(tǒng)的業(yè)務(wù)需求和領(lǐng)域要求,并精化為系統(tǒng)的需求。用例模型包括用例視圖模型、用例場景和用例活動圖或泳道圖。第二部分結(jié)構(gòu)化軟件工程范型結(jié)構(gòu)化軟件分析與設(shè)計要建立哪些模型?概要設(shè)計與詳細(xì)設(shè)計的關(guān)系是什么?軟件概要設(shè)計主流的技術(shù)是什么?軟件詳細(xì)設(shè)計主流的技術(shù)是什么?軟件測試包括哪些過程和主要技術(shù)?關(guān)注一下問題內(nèi)容提要:結(jié)構(gòu)化分析概述結(jié)構(gòu)化分析模型數(shù)據(jù)流分析方法數(shù)據(jù)建模分析方法狀態(tài)分析方法結(jié)構(gòu)化分析過程軟件需求規(guī)格說明文檔第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ù),其過程是創(chuàng)建描述信息內(nèi)容和數(shù)據(jù)流模型,依據(jù)功能和行為對系統(tǒng)進(jìn)行劃分,并描述必須建立的系統(tǒng)要素。5.1結(jié)構(gòu)化分析概述充分理解問題開發(fā)快速原型描述軟件需求建立軟件高層模型確定軟件需求優(yōu)先級驗證軟件需求結(jié)構(gòu)化需求分析指導(dǎo)性活動結(jié)構(gòu)化分析方法是一種半形式化的分析與建模技術(shù),其過程包括對軟件相關(guān)的各種信息進(jìn)行分析,抽取其本質(zhì)特征,創(chuàng)建描述數(shù)據(jù)、功能和行為的模型。結(jié)構(gòu)化分析模型的主要目標(biāo):描述客戶的需要;為軟件設(shè)計建立基礎(chǔ);定義在軟件完成后可以確認(rèn)的一組需求。5.2結(jié)構(gòu)化分析模型系統(tǒng)模型從以下不同的角度表述系統(tǒng):從外部來看,它是對系統(tǒng)分析上下文或系統(tǒng)環(huán)境建模;從行為上看,它是對系統(tǒng)行為建模;從結(jié)構(gòu)上看,它是對系統(tǒng)的體系結(jié)構(gòu)和系統(tǒng)處理的數(shù)據(jù)結(jié)構(gòu)建模。結(jié)構(gòu)化的需求分析模型:系統(tǒng)行為模型:數(shù)據(jù)流模型,用來描述系統(tǒng)中的數(shù)據(jù)處理過程狀態(tài)轉(zhuǎn)換模型,用來描述系統(tǒng)如何對事件做出響應(yīng)實體—關(guān)系模型:關(guān)心的是尋找系統(tǒng)中的數(shù)據(jù)及其之間的關(guān)系,卻不關(guān)心系統(tǒng)中包含的功能。5.2結(jié)構(gòu)化分析模型數(shù)據(jù)字典實體-關(guān)系圖數(shù)據(jù)流圖加工規(guī)約數(shù)據(jù)對象描述狀態(tài)轉(zhuǎn)換圖控制規(guī)約結(jié)構(gòu)化分析模型結(jié)構(gòu)分析模型結(jié)構(gòu)的核心是數(shù)據(jù)字典(DD,DataDictionary),包含了軟件使用或生產(chǎn)的所有數(shù)據(jù)對象描述的中心庫。分析模型結(jié)構(gòu)的中間層有三種視圖:數(shù)據(jù)流圖(DFD,DataFlowDiagram)服務(wù)于兩個目的:一是指明數(shù)據(jù)在系統(tǒng)中移動時如何被變換,二是描述對數(shù)據(jù)流進(jìn)行變換的功能和子功能。實體—關(guān)系圖(E-RD,Entity-RelationshipDiagram)描述數(shù)據(jù)對象間的關(guān)系,用來進(jìn)行數(shù)據(jù)建模活動的記號。狀態(tài)轉(zhuǎn)換圖(STD,StateTransitionDiagram)指明作為外部事件的結(jié)果,系統(tǒng)將如何動作。分析模型結(jié)構(gòu)的外層是規(guī)約描述:在實體—關(guān)系圖中每個數(shù)據(jù)對象的屬性可以使用數(shù)據(jù)對象來描述。在數(shù)據(jù)流圖中出現(xiàn)的每個加工/處理的功能描述包含在加工規(guī)約中。軟件控制方面的附加信息包含在控制規(guī)約中結(jié)構(gòu)化分析模型組成面向數(shù)據(jù)流的建模是一種結(jié)構(gòu)化需求分析方法,簡稱數(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)的所有名字的一個集合,并包括有關(guān)命名實體的描述數(shù)據(jù)字典有以下兩個作用:它是所有名字信息管理的有效機(jī)制作為連接軟件分析、設(shè)計、實現(xiàn)和進(jìn)化階段的開發(fā)機(jī)構(gòu)的信息存儲數(shù)據(jù)字典應(yīng)該由四類元素的定義組成:數(shù)據(jù)流數(shù)據(jù)流分量數(shù)據(jù)存儲處理對于處理,可用輸入—處理—輸出(IPO,Input-Process-Output)視圖描述更方便數(shù)據(jù)字典應(yīng)對組成的數(shù)據(jù)元素定義進(jìn)行自頂向下的分解。分解的原則是:當(dāng)包含的元素不需要進(jìn)一步定義,且每個和工程有關(guān)的人都清楚時為止數(shù)據(jù)字典中應(yīng)該包括關(guān)于數(shù)據(jù)的信息:一般信息(名字、別名、描述等)定義(數(shù)據(jù)類型、長度、結(jié)構(gòu)等)使用特點(值的范圍、使用頻率、使用條件、使用方式、條件值等)控制信息(用戶、使用特點、改變數(shù)、使用權(quán)等)分組信息(文檔結(jié)構(gòu)、從屬結(jié)構(gòu)、物理位置等)三種類型的任意組合定義數(shù)據(jù)字典中的任何條目。順序:順序連接兩個或多個分量元素。一般用加號表示順序連接關(guān)系。選擇:從兩個或多個可選的分量元素中選取一個。選擇運算符用方括號表示,對于多個可供選擇的元素,用“|”符號分隔。例如,[A-1|A-2|A-3]表示三個可選數(shù)據(jù)元素。重復(fù):描述的分量元素重復(fù)零次或多次。例如,
都表示數(shù)據(jù)元素A的下限為1,上限為5。數(shù)據(jù)字典數(shù)據(jù)流分析步驟數(shù)據(jù)流圖要素分析:根據(jù)問題確定數(shù)據(jù)的源點、終點、數(shù)據(jù)流、數(shù)據(jù)存儲和處理等。構(gòu)建數(shù)據(jù)流圖:根據(jù)數(shù)據(jù)流圖要素繪制數(shù)據(jù)流圖。建立數(shù)據(jù)字典:對數(shù)據(jù)流分析中所涉及的所有要素進(jìn)行詳細(xì)的規(guī)格描述。一個工廠采購部每天需要一張定貨報表。零件的入庫、出庫事務(wù)通過計算機(jī)終端輸入給定貨系統(tǒng)。當(dāng)某零件的庫存數(shù)少于給定的庫存量臨界值時,就應(yīng)該再次定貨。定貨的零件數(shù)據(jù)有:零件編號、名稱、數(shù)量、價格、供應(yīng)者等。數(shù)據(jù)流分析:數(shù)據(jù)源點:倉管員(負(fù)責(zé)入庫或出庫事務(wù)給定貨系統(tǒng));數(shù)據(jù)終點:采購員(接收每天的定貨報表);數(shù)據(jù)流:事務(wù),定貨;數(shù)據(jù)存儲:定貨信息,庫存清單;處理:處理事務(wù),產(chǎn)生報表。例5.1訂貨軟件的數(shù)據(jù)流圖畫基本系統(tǒng)模型采購員事務(wù)定貨報表倉管員訂貨系統(tǒng)第1次求精第2次求精數(shù)據(jù)字典卡片方式示例名字:訂貨報表別名:訂貨信息描述:每天一次需要訂貨的零件表定義:訂貨報表=1{零件信息}50
其中:
零件信息=零件編號+零件名稱+數(shù)量+價格+1{供應(yīng)者}3
分量定義:
零件編號=8位字符;
零件名稱=20位字符;
數(shù)量=[1|2|3|4|5];
價格={數(shù)值類型};
供應(yīng)者=24位字符位置:輸出到打印機(jī)軟件建模的一個重要方面就是要定義系統(tǒng)處理的邏輯結(jié)構(gòu)。最廣泛采用的數(shù)據(jù)建模技術(shù)是實體-關(guān)系模型,它描述數(shù)據(jù)實體、關(guān)聯(lián)及實體屬性。實體關(guān)系模型可用ERD(Entity-RelationshipsDiagram實體關(guān)系圖)來表示:實體關(guān)聯(lián)實體屬性基數(shù)5.4數(shù)據(jù)建模分析方法例5.2圖書館管理系統(tǒng)實體關(guān)系圖1借還記錄預(yù)約記錄借/還/續(xù)借
1M10..510包含預(yù)約借書者圖書書目借書者:借書證號、姓名、性別、借書數(shù)、最大借書數(shù)、罰金金額、有效期。圖書:書號、ISBN號、狀態(tài)。書目:ISBN號、書名、作者、出版社、摘要、目錄、叢書名、收藏數(shù)、在館數(shù)、預(yù)約數(shù)。借還記錄:書號、借書證號、借出日期、應(yīng)還日期、續(xù)借次數(shù)。預(yù)約記錄:ISBN號、借書證號、預(yù)約日期。實體屬性狀態(tài)分析方法主要任務(wù)是建立軟件的狀態(tài)模型。狀態(tài)模型是一種描述系統(tǒng)對內(nèi)部或者外部事件響應(yīng)的行為模型。它描述系統(tǒng)狀態(tài)和事件,以及事件引發(fā)系統(tǒng)在狀態(tài)間的轉(zhuǎn)換。這種模型適用于描述實時系統(tǒng)。狀態(tài)機(jī)建模方法步驟:系統(tǒng)狀態(tài)、行為與事件分析構(gòu)建狀態(tài)圖5.5狀態(tài)分析方法狀態(tài)模型一般采用狀態(tài)轉(zhuǎn)換圖(簡稱狀態(tài)圖)的標(biāo)記方法狀態(tài)圖描述了系統(tǒng)中某些復(fù)雜對象的狀態(tài)變化狀態(tài)是可觀察的行為模式,用圓角矩形表示;變遷表示狀態(tài)的轉(zhuǎn)換,用箭頭表示;事件是引發(fā)變遷的消息,用箭頭上的標(biāo)記表示。狀態(tài)圖還可以用事件后的方括號表示先決條件,只有當(dāng)這個條件為真時,才會發(fā)生狀態(tài)變化;用狀態(tài)自身的弧線箭頭表示先決條件不為真時,狀態(tài)不會改變。狀態(tài)轉(zhuǎn)換圖問題描述在一幢有m層的大廈中安裝一套n部電梯的產(chǎn)品,按照下列條件求解電梯在各樓層之間移動的邏輯關(guān)系:每部電梯有m個按鈕,每一個按鈕代表一個樓層。當(dāng)按下一個按鈕時該按鈕指示燈亮,同時電梯駛向相應(yīng)的樓層,當(dāng)?shù)竭_(dá)相應(yīng)樓層時指示燈熄滅。除了最底層和最高層之外,每一層樓都有兩個按鈕分別指示電梯上行和下行。按下按鈕后指示燈就開始亮,當(dāng)電梯到達(dá)此樓層時指示燈熄滅,電梯暫停并執(zhí)行開門和關(guān)門動作,并向所需要的方向移動。當(dāng)電梯無升降運動時,關(guān)門并停在當(dāng)前樓層。電梯系統(tǒng)狀態(tài)分析電梯在運行過程一般具有下列狀態(tài):空閑:無請求時,電梯處于休息狀態(tài);暫停:上下乘客時,電梯處于暫停,開門和關(guān)門;上行:電梯處于向上運行狀態(tài);下行:電梯處于向下運行狀態(tài);處于第一層:初始啟動,電梯會在第一層等待狀態(tài);向第一層移動:長時間
處于空閑時,電梯移動到第一層。
狀態(tài)事件及行為分析電梯控制系統(tǒng)的事件有:向上:驅(qū)動電梯向上運行;向下:驅(qū)動電梯向下運行;停止:停止電梯運行;無請求:沒有乘客請求乘坐電梯;長時間無請求:長時間沒有乘客請求乘坐電梯。繪制電梯對象的狀態(tài)圖問題描述繪制數(shù)據(jù)流圖確定計算機(jī)化部分定義數(shù)據(jù)定義處理邏輯定義物理資源確定輸入和輸出規(guī)格確定數(shù)據(jù)規(guī)模、格式、硬件要求編寫規(guī)格說明書5.6結(jié)構(gòu)化分析過程1、問題描述圖書銷售店從各出版社購買圖書,并將其銷售給大學(xué)、公司和個人客戶。書店庫存流行的圖書,并根據(jù)需要訂購其他圖書。書店提供大學(xué)訂購服務(wù),并根據(jù)客戶和訂購量提供優(yōu)惠?,F(xiàn)在書店希望實現(xiàn)計算機(jī)化管理,將如何做?分析上述問題,確定需要有哪些商務(wù)功能(入賬、出賬和庫存),系統(tǒng)是批處理方式還是聯(lián)機(jī)方式,硬件設(shè)備情況,實現(xiàn)計算機(jī)化管理的目的是什么等目標(biāo)??梢钥闯?,其目的是為了銷售圖書和圖書管理以及賬目管理。例5.4書店圖書銷售軟件結(jié)構(gòu)化分析步驟
2、繪制數(shù)據(jù)流圖系統(tǒng)的自動化方案選擇,取決于客戶的投資和目標(biāo)。一般必須利用成本—效益分析對數(shù)據(jù)流圖各個部分的操作分析決定以批處理方式還是以聯(lián)機(jī)方式執(zhí)行。
本例的第一個方案是以批處理方式處理出賬、訂購圖書,用聯(lián)機(jī)方式處理訂單的有效性檢查、聚集訂單和開發(fā)貨清單;第二個方案是除發(fā)貨票據(jù)使用聯(lián)機(jī)方式或批處理方式外,其余都用聯(lián)機(jī)方式。3、確定需要計算機(jī)化部分本例的數(shù)據(jù)流和數(shù)據(jù)存儲有“訂單”、“圖書數(shù)據(jù)”、“顧客數(shù)據(jù)”、“賬目”、“發(fā)貨清單”等等。4、定義數(shù)據(jù)確定了產(chǎn)品的數(shù)據(jù)元素,就可以分析每個處理具體做什么了。例如,分析“生成賬目”中“給教育部門打折扣”細(xì)節(jié)。5、定義處理邏輯加工邏輯也稱為過程說明,用于描述數(shù)據(jù)流圖中加工邏輯的處理算法或過程處理邏輯的描述軟件需求分析的描述通常采用一種規(guī)范的需求規(guī)格文檔。需求規(guī)格說明文檔,即軟件需求規(guī)格說明書(SoftwareRequirementSpecification,SRS)是需求分析任務(wù)的最終“產(chǎn)品”。需求規(guī)格說明文檔的讀者5.7軟件需求規(guī)格說明文檔SRS描述要求SRS應(yīng)滿足以下各個方面的描述要求:l只敘述軟件的外部行為l定義軟件實現(xiàn)上的約束l是容易改變的l成為軟件維護(hù)人員的參考工具l記錄軟件的整個生命周期l應(yīng)對未料到的事件給出可接受的反應(yīng)SRS標(biāo)準(zhǔn)內(nèi)容SRS各個部分的簡要介紹。(1)引言部分。陳述關(guān)于計劃文檔的背景和為什么需要該軟件,解釋軟件是如何與其他軟件協(xié)同工作的。(2)任務(wù)概述。陳述軟件的目標(biāo)、運行環(huán)境和軟件的規(guī)模等。(3)數(shù)據(jù)描述。給出軟件必須解決的問題的詳細(xì)描述,并記錄了信息內(nèi)容和關(guān)系、輸入/輸出數(shù)據(jù)及其結(jié)構(gòu)。(4)功能描述。給出解決問題所需要的每個功能,包括每個功能的處理過程、設(shè)計約束等。(5)性能需求。描述性能特征和約束,包括時間約束、適應(yīng)性等。(6)運行需求。給出交互的用戶界面要求,與其他軟/硬件的接口,以及異常處理等。(7)其他需求。給出軟件維護(hù)性各個方面的要求。結(jié)構(gòu)化分析方法是一種自頂向下,逐步分解的面向數(shù)據(jù)和數(shù)據(jù)流的建模方法。結(jié)構(gòu)化分析模型工具有數(shù)據(jù)流圖、數(shù)據(jù)字典、實體關(guān)系圖和狀態(tài)轉(zhuǎn)換圖等。數(shù)據(jù)流圖和數(shù)據(jù)字典常用于結(jié)構(gòu)化分析,用于描述軟件的數(shù)據(jù)處理及其流程的信息,它們一起被稱為軟件邏輯模型。實體關(guān)系圖和狀態(tài)轉(zhuǎn)換圖輔助描述軟件所涉及的實體動態(tài)變化行為。小結(jié)內(nèi)容提要結(jié)構(gòu)化設(shè)計概述軟件設(shè)計過程結(jié)構(gòu)化設(shè)計原理模塊獨立性度量軟件結(jié)構(gòu)化設(shè)計軟件詳細(xì)設(shè)計第6章結(jié)構(gòu)化設(shè)計6.1結(jié)構(gòu)化設(shè)計概述軟件設(shè)計是把軟件需求“變換”為用于構(gòu)造軟件的藍(lán)圖。所以,它的“輸入”是需求分析各種模型元素,“輸出”是軟件設(shè)計模型和描述。軟件設(shè)計的目標(biāo)是對將要實現(xiàn)的軟件的體系結(jié)構(gòu)、數(shù)據(jù)模型、軟件模塊間的接口,以及所模塊采用的算法給出詳盡的描述。軟件設(shè)計任務(wù):數(shù)據(jù)設(shè)計體系結(jié)構(gòu)設(shè)計接口設(shè)計構(gòu)件設(shè)計總體設(shè)計,也稱為概要設(shè)計,軟件結(jié)構(gòu)設(shè)計,或高層設(shè)計。分析需求規(guī)格說明模塊劃分,形成具有預(yù)定功能的模塊組成結(jié)構(gòu)表示出模塊間的控制關(guān)系給出模塊之間的接口軟件詳細(xì)設(shè)計,也稱為(模塊)過程設(shè)計,或低層設(shè)計。設(shè)計模塊細(xì)節(jié)確定模塊所需的算法和數(shù)據(jù)結(jié)構(gòu)等6.2軟件設(shè)計過程方案設(shè)計方案選取推薦最佳方案功能分解和軟件結(jié)構(gòu)設(shè)計數(shù)據(jù)庫設(shè)計編制設(shè)計文檔審查和復(fù)審軟件概要設(shè)計步驟詳細(xì)設(shè)計是為軟件概要設(shè)計階段給出的軟件結(jié)構(gòu)圖中的各個模塊設(shè)計處理過程的細(xì)節(jié),確定模塊所需的算法和數(shù)據(jù)結(jié)構(gòu)等。詳細(xì)設(shè)計主要描述每個模塊或構(gòu)件的設(shè)計細(xì)節(jié),主要包括模塊或構(gòu)件的處理邏輯、算法、接口等。詳細(xì)設(shè)計的內(nèi)容包括:(1)模塊或構(gòu)件描述:描述模塊或構(gòu)件的功能,以及需要解決的問題,這個模塊或構(gòu)件在什么時候可以被調(diào)用,為什么需要這個模塊或構(gòu)件。(2)算法描述:確定模塊或構(gòu)件的處理算法和步驟,包括公式、邊界和特殊條件,甚至參考資料等。(3)數(shù)據(jù)描述:描述模塊或構(gòu)件內(nèi)部的數(shù)據(jù)結(jié)構(gòu)。詳細(xì)設(shè)計可采用流程圖、PDL語言、盒圖、判定表等描述算法的圖、表和偽代碼來表示。設(shè)計過程不應(yīng)該受“隧道視野”的限制設(shè)計對于分析模型應(yīng)該是可跟蹤的設(shè)計不應(yīng)該從頭做起
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(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)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 專業(yè)化通風(fēng)空調(diào)安裝項目協(xié)議2024版A版
- 三方債務(wù)責(zé)任轉(zhuǎn)移協(xié)議2024版
- 2025年度農(nóng)業(yè)園區(qū)場地租賃安全管理合同范本4篇
- 專業(yè)勞務(wù)分包協(xié)議(2024年版)樣本版A版
- 二零二四實習(xí)生就業(yè)權(quán)益與培訓(xùn)協(xié)議范本規(guī)范5篇
- 2025年度測繪數(shù)據(jù)安全保密協(xié)議4篇
- 專業(yè)標(biāo)識標(biāo)牌定制及施工服務(wù)協(xié)議版B版
- 專業(yè)攝影委托協(xié)議細(xì)則(2024年)版B版
- 2024物業(yè)管理權(quán)轉(zhuǎn)讓服務(wù)合同
- 2024版食品安全購銷合作合同范本一
- 微機(jī)原理與接口技術(shù)考試試題及答案(綜合-必看)
- 勞務(wù)投標(biāo)技術(shù)標(biāo)
- 研發(fā)管理咨詢項目建議書
- 濕瘡的中醫(yī)護(hù)理常規(guī)課件
- 轉(zhuǎn)錢委托書授權(quán)書范本
- 一種配網(wǎng)高空作業(yè)智能安全帶及預(yù)警系統(tǒng)的制作方法
- 某墓園物業(yè)管理日常管護(hù)投標(biāo)方案
- 蘇教版六年級數(shù)學(xué)上冊集體備課記載表
- 內(nèi)蒙古匯能煤電集團(tuán)有限公司長灘露天煤礦礦山地質(zhì)環(huán)境保護(hù)與土地復(fù)墾方案
- 22S702 室外排水設(shè)施設(shè)計與施工-鋼筋混凝土化糞池
- 2013日產(chǎn)天籟全電路圖維修手冊45車身控制系統(tǒng)
評論
0/150
提交評論