第一部分軟件工程基礎(chǔ)1

1、軟件工程方法與實(shí)踐(第3版)竇萬峰計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院南京師范大學(xué)2016年12月 第一部分：軟件工程基礎(chǔ)什么是軟件工程？什么是軟件危機(jī)？如何解決？什么是軟件過程？有哪些過程模型？如何選擇與建立過程模型？什么是統(tǒng)一過程？什么是敏捷過程？有哪些方法？什么是結(jié)對(duì)編程？有何優(yōu)缺點(diǎn)？第1章 軟件工程概述（內(nèi)容提要）什么是軟件？軟件的要素有哪些？什么是軟件工程？其要素有哪些？軟件危機(jī)與工程化思想軟件工程基本原理與基本原則軟件工程方法學(xué)什么是軟件？三要素：軟件=程序+文檔+數(shù)據(jù)特性：復(fù)雜性一致性退化性易變性移植性高成本軟件技術(shù)演化第一階段：程序設(shè)計(jì)階段。1946年到60年代初：個(gè)體手工方式。 第二階段：程

2、序系統(tǒng)階段。60年代初到70年代初：小組化生產(chǎn)，出現(xiàn)軟件危機(jī)。第三階段：傳統(tǒng)軟件工程階段。20世紀(jì)70年代中期至80年代中期：把工程化的思想引入到軟件開發(fā)中，結(jié)構(gòu)化方法的發(fā)展，規(guī)?；浖_發(fā)。第四階段：面向?qū)ο箅A段。20世紀(jì)80年代中期至今：面向?qū)ο蠓椒▽W(xué)發(fā)展，軟件定制和滿足客戶需求。發(fā)展趨勢軟件服務(wù)：云服務(wù)、大數(shù)據(jù)服務(wù)多樣性：中間件開放性：新型中間件平臺(tái)軟件危機(jī)兩個(gè)方面的問題：如何開發(fā)軟件如何維護(hù)軟件表現(xiàn)：規(guī)模大、復(fù)雜度增加供需差增大價(jià)格昂貴開發(fā)速度慢質(zhì)量難以保證軟件危機(jī)解決途徑重視需求分析，明確與確切表達(dá)需求重視與客戶溝通與交流統(tǒng)一的、公認(rèn)的方法論和規(guī)范指導(dǎo)重視設(shè)計(jì)和實(shí)現(xiàn)過程的資料充分的檢

3、測工作軟件工程定義軟件工程運(yùn)用現(xiàn)代科學(xué)技術(shù)知識(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ù)軟件工程管理原因：缺乏軟件過程控制能力能力成熟模型（Capability Maturity Model）體現(xiàn):工程化管理軟件工程管理軟件工程基本原理推遲實(shí)現(xiàn)原理逐步求精原理分解與抽象原理信息隱蔽原理質(zhì)量保證原理軟件工程基本原則分階段的軟件生存周期堅(jiān)持進(jìn)行階段評(píng)審實(shí)行嚴(yán)

4、格的產(chǎn)品控制采用現(xiàn)代程序設(shè)計(jì)技術(shù)明確職責(zé)開發(fā)小組的人員應(yīng)少而精不斷改進(jìn)開發(fā)過程軟件工程兩大范型結(jié)構(gòu)化開發(fā)范型特征：結(jié)構(gòu)化技術(shù)要么面向行為，要么面向數(shù)據(jù)構(gòu)成結(jié)構(gòu)化開發(fā)范型的技術(shù)包括：結(jié)構(gòu)化分析結(jié)構(gòu)化設(shè)計(jì)結(jié)構(gòu)化編程結(jié)構(gòu)化測試結(jié)構(gòu)化維護(hù)軟件工程兩大范型面向?qū)ο蠓缎吞卣鳎簩?duì)象視作一個(gè)融合了數(shù)據(jù)及在其上操作的行為的、統(tǒng)一的軟件組件。技術(shù)包括：面向?qū)ο蠓治雒嫦驅(qū)ο笤O(shè)計(jì)面向?qū)ο缶幊堂嫦驅(qū)ο鬁y試面向?qū)ο缶S護(hù)優(yōu)勢：對(duì)象的概念符合業(yè)務(wù)或領(lǐng)域的客觀實(shí)際維護(hù)容易重型與輕型軟件工程重型軟件工程文檔齊全規(guī)范化和程式化周期長推遲實(shí)現(xiàn)輕型軟件工程非正式交流重視代碼重視測試響應(yīng)需求變化小結(jié)軟件工程的是主旨以工程化的思想進(jìn)行軟

5、件開發(fā)，以生產(chǎn)高質(zhì)量和高效率的軟件。軟件工程化思想的核心是，把軟件看作是一個(gè)工程產(chǎn)品。軟件工程方法學(xué)分別是傳統(tǒng)結(jié)構(gòu)化范型和面向?qū)ο蠓缎?。?章 軟件過程（內(nèi)容提要）什么是軟件過程？軟件產(chǎn)品與過程軟件生存周期軟件工程活動(dòng)軟件過程定義：軟件過程是為了開發(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)容組

6、織及管理框架技術(shù)及工具框架軟件過程環(huán)境組織、管理的角色和職責(zé)技術(shù)環(huán)境軟件過程框架組織與管理框架：過程改進(jìn)活動(dòng)及角色與職責(zé)技術(shù)與工具框架：技術(shù)及自動(dòng)化活動(dòng)工具框架活動(dòng)：溝通策劃建模構(gòu)建部署軟件生存周期過程（表2-1）系統(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ù)）針對(duì)軟件開發(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ù)）軟件產(chǎn)品與

7、過程把軟件看成產(chǎn)品，必然注重軟件的質(zhì)量，決定了軟件過程、周期和成本。產(chǎn)品依賴過程，其就是過程定義的一系列活動(dòng)和任務(wù)的結(jié)果。軟件產(chǎn)品越復(fù)雜，其開發(fā)周期也越長，開發(fā)成本越高。軟件過程評(píng)估產(chǎn)品與過程選擇軟件過程過程評(píng)估CMMI/CMMISO9001:2000個(gè)人軟件過程（PSP）團(tuán)隊(duì)軟件過程(TSP)個(gè)人軟件過程（PSP）內(nèi)容PSP0是PSP的個(gè)人度量過程，其目的是建立個(gè)體過程基線。PSP1是個(gè)人規(guī)劃過程，引入了基于估計(jì)的計(jì)劃方法PROBE，用自己的歷史數(shù)據(jù)來預(yù)測新程序大小和開發(fā)時(shí)間，并使用線性回歸方法估計(jì)參數(shù)，確定置信區(qū)間以評(píng)價(jià)預(yù)測的可信程度。PSP2是個(gè)人質(zhì)量管理，根據(jù)程序的缺陷建立檢測表，按照

8、檢測表進(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è)相對(duì)獨(dú)立的階段。TSP 提供了如下方法：計(jì)劃評(píng)審設(shè)計(jì)和編碼標(biāo)準(zhǔn)設(shè)計(jì)和代碼評(píng)審方法缺陷評(píng)審質(zhì)量分析軟件生存周期軟件也有一個(gè)從生到死的過程，這個(gè)過程一般稱之為軟件的軟件生存周期或生命周期（Software Development Life Cycle）軟件生存周期可劃分為定義、開發(fā)和運(yùn)行三個(gè)時(shí)期，每個(gè)時(shí)期又細(xì)分為若干個(gè)階段。把整

9、個(gè)軟件生存周期劃分為若干階段，使得每個(gè)階段有明確的任務(wù)，使規(guī)模大，結(jié)構(gòu)復(fù)雜和管理復(fù)雜的軟件開發(fā)變的容易控制和管理。軟件生存周期包括可行性分析、項(xiàng)目計(jì)劃、需求分析、軟件設(shè)計(jì)、編碼與測試、維護(hù)等階段，每個(gè)階段有包含一系列的活動(dòng)。軟件過程活動(dòng)溝通活動(dòng)計(jì)劃活動(dòng)建?；顒?dòng)實(shí)現(xiàn)活動(dòng)部署活動(dòng)維護(hù)活動(dòng)管理活動(dòng)過程改進(jìn)活動(dòng)小結(jié)大多數(shù)軟件開發(fā)過程都有一個(gè)共同的軟件過程框架，即溝通、策劃、建模、構(gòu)建和部署的過程。每個(gè)過程有包含一系列小的任務(wù)或活動(dòng)。對(duì)于開發(fā)大型復(fù)雜的軟件，建議采用重型軟件過程模型，如螺旋模型、統(tǒng)一過程模型等；對(duì)于需求穩(wěn)定或簡單的軟件，建議采用輕型軟件過程模型，如極限編程、瀑布模型等。軟件工程活動(dòng)包括溝

10、通活動(dòng)、計(jì)劃活動(dòng)、建?；顒?dòng)、構(gòu)造活動(dòng)、部署活動(dòng)、維護(hù)活動(dòng)、管理活動(dòng)和過程改進(jìn)活動(dòng)。第3章 軟件過程模型（內(nèi)容提要）瀑布模型增量模型螺旋模型構(gòu)建集成模型統(tǒng)一過程模型軟件過程模型把軟件生命周期中各項(xiàng)開發(fā)活動(dòng)的流程用一個(gè)合理的框架開發(fā)模型來規(guī)范描述，這就是軟件過程模型,也稱為軟件生命周期模型.軟件過程模型是一種就是軟件過程抽象.軟件過程模型是從一個(gè)特定的角度表現(xiàn)一個(gè)過程，一般使用直觀的圖形標(biāo)識(shí)軟件開發(fā)的過程，主要根據(jù)軟件的類型、規(guī)模，特別是軟件的開發(fā)方法、開發(fā)環(huán)境等多種因素確立過程模型。瀑布模型瀑布模型將軟件生命周期劃分為軟件計(jì)劃、需求分析和定義、設(shè)計(jì)、實(shí)現(xiàn)、測試、運(yùn)行和維護(hù)這6個(gè)階段，規(guī)定了它們自

11、上而下、相互銜接的固定次序，如同瀑布流水逐級(jí)下落。從本質(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)文檔的作用增量模型增量模型（Incremental Model）也稱為漸增模型，是在項(xiàng)目的開發(fā)過程中以一系列的增量方式開發(fā)系統(tǒng)。軟件被

12、作為一系列的增量構(gòu)件來設(shè)計(jì)、實(shí)現(xiàn)、集成和測試，每一個(gè)構(gòu)件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構(gòu)成.增量方式包括：增量開發(fā)：以一定的時(shí)間間隔開發(fā)部分工作軟件增量提交：以一定的時(shí)間間隔增量方式向用戶提交工作軟件及相應(yīng)文檔增量模型融合了線性順序模型的基本成份和原型實(shí)現(xiàn)模型的迭代特征。增量模型分為漸增模型和原型模型漸增模型是瀑布模型的變種，有兩類漸增模型：增量構(gòu)造模型：它在瀑布模型基礎(chǔ)上，對(duì)一些階段進(jìn)行整體開發(fā)，對(duì)另一些階段進(jìn)行增量開發(fā)。前面的開發(fā)階段按瀑布模型進(jìn)行整體開發(fā)，后面的開發(fā)階段按增量提交。演化提交模型：它在瀑布模型的基礎(chǔ)上，所有階段都進(jìn)行增量開發(fā)，也就是說不僅是增量開發(fā)，也

13、是增量提交。增量構(gòu)造模型需求分析設(shè)計(jì)編碼1測試1測試2編碼2編碼3測試3螺旋模型螺旋模型（Spiral Model）是結(jié)合了瀑布模型和快速原型模型的迭代開發(fā)模型強(qiáng)調(diào)了其他模型均忽略了的風(fēng)險(xiǎn)分析：風(fēng)險(xiǎn)識(shí)別風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)控制特別適合于大型復(fù)雜的系統(tǒng)每一個(gè)周期都包括需求定義、風(fēng)險(xiǎn)分析、工程實(shí)現(xiàn)和評(píng)審螺旋模型示意圖螺旋模型活動(dòng)四個(gè)象限分別代表了以下活動(dòng)：制定計(jì)劃：確定軟件目標(biāo)，選定實(shí)施方案，確定項(xiàng)目開發(fā)的限制條件； 風(fēng)險(xiǎn)分析：分析評(píng)估所選方案，考慮如何識(shí)別和消除風(fēng)險(xiǎn)；實(shí)施工程：實(shí)施軟件開發(fā)和驗(yàn)證；客戶評(píng)估：評(píng)價(jià)開發(fā)工作，提出修正建議，制定下一步計(jì)劃。螺旋模型是風(fēng)險(xiǎn)驅(qū)動(dòng)的模型面向?qū)ο筮^程模型面向?qū)ο笫且环N

14、的程序設(shè)計(jì)方法，或者說它是一種程序設(shè)計(jì)范型。基本思想是使用對(duì)象，類，繼承，封裝，消息等基本概念來進(jìn)行程序設(shè)計(jì)。面向?qū)ο蟮囊兀?抽象：強(qiáng)調(diào)實(shí)體的本質(zhì)、內(nèi)在的屬性，忽略一些無關(guān)緊要的屬性。類實(shí)現(xiàn)了對(duì)象的數(shù)據(jù)（即狀態(tài)）和行為的抽象，是對(duì)象的共性的抽象。封裝性：指所有軟件部件內(nèi)部都有明確的范圍以及清楚的外部邊界。 共享性：面向?qū)ο蟮奶卣鳎簩?duì)象惟一性；分類性；繼承性；多態(tài)性（多形性）。構(gòu)件集成模型構(gòu)件集成模型是基于構(gòu)件的開發(fā)模型構(gòu)件集成模型：整個(gè)系統(tǒng)模塊化復(fù)用構(gòu)件庫中的軟件構(gòu)件構(gòu)件集成模型是演化形的，開發(fā)過程是迭代的5個(gè)階段：軟件的需求分析和定義體系結(jié)構(gòu)設(shè)計(jì)構(gòu)件庫建立應(yīng)用軟件構(gòu)建測試和發(fā)布構(gòu)件集成模型

15、需求分析和定義體系結(jié)構(gòu)設(shè)計(jì)構(gòu)件庫建立測試和發(fā)布應(yīng)用軟件構(gòu)建1：N統(tǒng)一過程A software development process：是一個(gè)將用戶需求轉(zhuǎn)化為軟件系統(tǒng)所需要的活動(dòng)的集合。A process framework：一個(gè)簡單的過程，也是一個(gè)通用的過程框架。Component-based：軟件構(gòu)件+接口The standard - employing the UML（Unified Modeling Language）use-case drivenarchitecture-centriciterative and incrementalThe Evolution of the Unifi

16、ed Process1967: a predecessorof Objectory1976-80: formalization &generalization1997: Objectory 4.11987-95: Objectory 1.0-3.8SDLA book: The Unified ProcessA product: The Rational Unified Process1998: Unified ProcessOMTBoochRationals best practices: Kruchten Royce and many othersThe Next Industry Stan

17、dardA Software Development ProcessSoftware development is the process of developing software from requirements.New or changedrequirementsNew or changed systemSoftware DevelopmentProcess統(tǒng)一過程是用況驅(qū)動(dòng)的用況模型(use case model)要素:用戶（user）用況（use case）動(dòng)作（action）用況驅(qū)動(dòng)（use-case driven）：用況可以驅(qū)動(dòng)開發(fā)過程：用況不只是確定系統(tǒng)需求的工具，還能驅(qū)動(dòng)

18、系統(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)系：用況對(duì)應(yīng)功能(function)構(gòu)架對(duì)應(yīng)表現(xiàn)形式（form）用況和構(gòu)架相互影響，并必須進(jìn)化統(tǒng)一過程是以構(gòu)架為中心的構(gòu)架設(shè)計(jì)師應(yīng)遵循的四個(gè)步驟：針對(duì)通用用況，創(chuàng)建一個(gè)粗略的構(gòu)架輪廓處理已經(jīng)確定的重要用況子集用況完善繼續(xù)上述過程統(tǒng)一過程是迭代和增量的劃分為袖珍項(xiàng)目（mini-project）:一個(gè)增量的迭代過程迭代是指工作流中的步驟,迭代過程必須是受控的目

19、標(biāo)：處理一組過程,風(fēng)險(xiǎn)分析做法：標(biāo)識(shí)與描述用況選定構(gòu)架創(chuàng)建設(shè)計(jì)選擇構(gòu)件實(shí)現(xiàn)設(shè)計(jì)驗(yàn)證Phases in the Software LifecycleThe Unified Process has four phases:Inception Defining the scope of the projectElaboration Planning, specifying features and designing architectureConstruction Building the productTransition Transitioning the product into its u

20、ser communitytimeInceptionElaborationConstructionTransitionMajor milestones統(tǒng)一過程模型統(tǒng)一過程（Unified Process，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è)核心工作流需求(Requirements Capture)：致力于開發(fā)正確的系統(tǒng)分析(Analysis)：更精確地理解需求設(shè)計(jì)(Design)：深入理解與非功能

21、性需求和約束相聯(lián)系的問題實(shí)現(xiàn)(Implementation)：實(shí)現(xiàn)系統(tǒng)與集成測試(Test)：驗(yàn)證實(shí)現(xiàn)的結(jié)構(gòu)核心工作流統(tǒng)一過程準(zhǔn)則準(zhǔn)則迭代的開發(fā)軟件需求管理基于構(gòu)件的體系結(jié)構(gòu)可視化軟件建模驗(yàn)證軟件質(zhì)量控制軟件的變更統(tǒng)一過程主要的優(yōu)點(diǎn)是提高了團(tuán)隊(duì)生產(chǎn)力工作流與模型RequirementsCaptureDesignImplementationTestAnalysisUse CaseModelDesignModelDeploymentModelImplementationModelAnalysisModelTestModelEach workflow is associated with one o

22、r more models.統(tǒng)一過程生命周期產(chǎn)品源代碼各種手冊相關(guān)交付品模型用況模型分析模型設(shè)計(jì)模型實(shí)現(xiàn)模型實(shí)施模型測試模型領(lǐng)域模型或業(yè)務(wù)模型統(tǒng)一過程生命周期里程碑和里程碑用途開發(fā)過程工作流：需求分析設(shè)計(jì)實(shí)現(xiàn)測試一個(gè)綜合的過程軟件開發(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)過程統(tǒng)一過程的目標(biāo)：指導(dǎo)開發(fā)人員有效地實(shí)現(xiàn)并實(shí)施滿足客戶需求的系統(tǒng)。效率：

23、成本、質(zhì)量、交付時(shí)間用況驅(qū)動(dòng)過程RequirementsAnalysis & DesignImplementationTestUse Cases bind these workflows together模型用況模型分析模型設(shè)計(jì)模型實(shí)現(xiàn)模型實(shí)施模型測試模型小結(jié)軟件開發(fā)模型是指軟件開發(fā)全部過程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架，能清晰、直觀地表達(dá)軟件開發(fā)全過程，明確規(guī)定了要完成的主要活動(dòng)和任務(wù)，用來作為軟件項(xiàng)目工作的基礎(chǔ)。瀑布模型是一種線性模型，文檔驅(qū)動(dòng)的模型。增量提交模型采用一系列的增量方式開發(fā)系統(tǒng)。螺旋模型結(jié)合瀑布模型和快速原型，是一種風(fēng)險(xiǎn)驅(qū)動(dòng)的開發(fā)模型構(gòu)件集成模型利用模塊化方法將整個(gè)系統(tǒng)模塊化，復(fù)用構(gòu)

24、件庫中的軟件構(gòu)件，通過組合手段提高應(yīng)用軟件系統(tǒng)過程的效率和質(zhì)量。統(tǒng)一過程模型是以用例驅(qū)動(dòng)的，以架構(gòu)為中心，迭代和增量的過程。第4章 敏捷軟件開發(fā)方法敏捷軟件開發(fā)過程SCRUM開發(fā)過程極限編程結(jié)對(duì)編程敏捷過程敏捷不是一個(gè)過程，是一類過程的統(tǒng)稱。敏捷方法的兩大主要特征：對(duì)“適應(yīng)性”的強(qiáng)調(diào)對(duì)“人”的關(guān)注做法：快速響應(yīng):引入迭代式的開發(fā)手段將整個(gè)軟件生命周期分解為若干個(gè)小的迭代周期獲取切實(shí)有效的客戶反饋提出12條基本原則敏捷開發(fā)12條原則我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價(jià)值的軟件來使客戶滿意。即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。 經(jīng)常性地交付可以工作的軟

25、件，交付的間隔可以從幾個(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)部，最具有效果并富有效率的傳遞信息的方法，就是面對(duì)面的交談。工作的軟件是首要的進(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)地對(duì)自己

26、的行為進(jìn)行調(diào)整。SCRUM開發(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í)間周期。沖刺訂單s

27、print backlog:一個(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ì)sprint planning會(huì)議每日立會(huì)Daily Scrum會(huì)議沖刺評(píng)審會(huì)Sprint review會(huì)議沖刺反思會(huì)Sprint retrospective會(huì)議實(shí)施Scrum的過程分解產(chǎn)品訂單成沖刺訂單召開沖刺計(jì)劃會(huì)議進(jìn)入沖刺開發(fā)周期，每天需要召開立會(huì)整個(gè)沖刺周期結(jié)束，召開沖刺評(píng)審會(huì)團(tuán)隊(duì)召開沖刺反思會(huì)以上循環(huán)進(jìn)行Scrum文檔產(chǎn)品訂單文檔沖刺訂單文檔燃盡圖極限編程極限編程（eXtreme

28、Programming，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é)對(duì)編程開發(fā)人員與管理人員的交流簡單設(shè)計(jì)的簡單編碼的簡單注釋的簡單測試的簡單反饋客戶對(duì)軟件的反饋測試代碼對(duì)功能代碼的反饋先測試，后編程勇氣接受任務(wù)的勇氣XP常見問題XP適合于小型

29、項(xiàng)目（10人左右）?結(jié)對(duì)編程，搭檔如何安排?實(shí)施結(jié)對(duì)編程、集體代碼所有權(quán)之后，如何考核單個(gè)開發(fā)人員？87Pair Programming( 結(jié)對(duì)編程 )結(jié)對(duì)編程結(jié)對(duì)編程(Pair-Programming) 是XP中非常重要的實(shí)踐之一。定義：兩個(gè)人坐在同一臺(tái)計(jì)算機(jī)前面，使用相同的鍵盤和鼠標(biāo)來開發(fā)同樣的一個(gè)模塊，一個(gè)稱為駕駛者(Driver)，負(fù)責(zé)代碼的鍵入，另外一個(gè)稱為領(lǐng)航員(Navigator)，負(fù)責(zé)監(jiān)看與決策，包括低級(jí)錯(cuò)誤和方向性的錯(cuò)誤。當(dāng)出現(xiàn)的一個(gè)問題對(duì)其中一個(gè)人來說，難以解決，而恰好是另外一個(gè)人的強(qiáng)項(xiàng)的時(shí)候，那么角色就會(huì)發(fā)生轉(zhuǎn)換。Pair Programming的角色(Role)Driv

30、er The one who typesNavigator The one who watches the back角色可以互換的疑問： 一個(gè)程序兩個(gè)人寫是不是一種浪費(fèi)（可是兩份工資，雙倍資源哦）？ 編程從來是一個(gè)人的活動(dòng)。學(xué)校里這么教的，一直以來也是做么做的。 我不喜歡被人盯著工作，這樣我不自在，無法工作。 這個(gè)笨家伙老是問問題，他/她不會(huì)看書么？我都無法專心工作了。 另一方面： Pair Programming被很多的大師級(jí)程序員推崇；不少大學(xué)都展開對(duì)Pair Programming的研究，并得到正面的結(jié)論； 很多嘗試過的Developer都開始喜歡Pair Programming。Pai

31、r Programming的疑問Pair Programming和Solo Programming的比較一些研究數(shù)據(jù)：1999年，University of Uath.兩組學(xué)生，一組獨(dú)自工作，一組Pair Programming。不間斷的Code Review1. Peer Code Review，即程序員之間的互相Review缺乏Design Review不能持久,定時(shí)Code Review對(duì)需求和設(shè)計(jì)的不了解導(dǎo)致無法實(shí)現(xiàn)有效的Review2. Team Code Review什么時(shí)候開會(huì)做Review？不可能Team天天開會(huì)無法對(duì)所有的設(shè)計(jì)和Code進(jìn)行Review面子問題效率低傳統(tǒng)開發(fā)過

32、程的Review（例如印度的InfoSys公司）的問題：不間斷的Code Review提供不間斷的Design review，Unit Test Review，Code Review，Document Review，避免了效果差的Team Code Review，也比抽查式的Peer Code Review有更好的質(zhì)量。Pair Programming中，任何一段代碼都至少被兩雙眼睛看過，兩個(gè)腦袋思考過。代碼被不斷的Review。編程方式避免cow boy式的編程好代碼的衡量標(biāo)準(zhǔn)：可讀性和可維護(hù)性對(duì)大部分的商業(yè)項(xiàng)目來說，更主要的顧慮是成本。好的代碼可以減少修改的成本。互相督促可以提高代碼的可讀

33、性。以人為本同伴的潛在壓力( Peer Pressure )。Pair Programming的過程也是一個(gè)互相督促的過程。由于這種督促的壓力，使得程序員更認(rèn)真的工作。每個(gè)人每天的有效工作時(shí)段不超過3-4個(gè)小時(shí)。Pair Programming中Driver和Navigator的互換可以讓程序員輪流工作，從而避免出現(xiàn)過度思考而導(dǎo)致觀察力和判斷力出現(xiàn)偏差。潛意識(shí)的有利競爭。當(dāng)人在一個(gè)團(tuán)隊(duì)中工作，總是下意識(shí)的努力展現(xiàn)自己的優(yōu)點(diǎn)。工作及時(shí)得到同伴的肯定，自信心和成就感(Self-Satisfaction)增強(qiáng)。覺得工作是一件愉快( Enjoyable )的事情。結(jié)對(duì)建議Extreme Program

34、ming對(duì)實(shí)施的程序員提出了更高的要求。這種要求不是技術(shù)水平，也不是學(xué)歷水平也不是工作經(jīng)驗(yàn)。這種要求是對(duì)一個(gè)人的心智，道德，修養(yǎng)的更高要求。程序員的四怕： 1) 怕自己看上去傻 2) 怕被認(rèn)為是沒用的 3) 怕自己變的不重要（過時(shí)） 4) 怕自己不夠好Pair Programming中，編碼不再是私人的工作，而是一種公開的“表演”。程序員的代碼，工作方式，技術(shù)水平都變得公開和透明。XP開發(fā)人員素質(zhì) 一個(gè)XP開發(fā)人員具備這樣一些基本素質(zhì)：誠實(shí)，公正，開明，勇敢和謙卑！在這些素質(zhì)的基礎(chǔ)之上，才是對(duì)技術(shù)水平，能力和天分等的要求。誠實(shí) 公正開明 勇氣 謙卑 具備這些素質(zhì)才能克服“四怕”，才能成為一個(gè)成

35、熟和專業(yè)的Developer。如何結(jié)對(duì)編程Driver 寫設(shè)計(jì)文檔(Class diagram等)，進(jìn)行編碼(Unit Test and Business Object)等XP開發(fā)流程。Navigator 審閱Driver的文檔、Driver對(duì)編碼等開發(fā)流程的執(zhí)行；考慮Unit Test的覆蓋程度；是否需要和如何Refactoring；幫助Driver解決具體的技術(shù)問題。Driver和Navigator不斷輪換角色，不要連續(xù)工作超過一小時(shí)，每一小時(shí)休息15分鐘。Navigator要控制開發(fā)時(shí)間。99沒有結(jié)對(duì)編程就沒有XPPair Programming是XP所有的Practices中最被爭議和

36、被認(rèn)為是最難接受。Pair Programming是獲得XP最大價(jià)值的關(guān)鍵。沒有Pair Programming,無法實(shí)現(xiàn)有效的Continuous Code Review,代碼質(zhì)量下降。沒有Peer Pressure，流程的執(zhí)行很容易出現(xiàn)偏差。沒有Pair Programming，Communication很容易弱化，進(jìn)而影響Team work。Pair Programming象XP流程中的粘合劑，把各個(gè)環(huán)節(jié)連接起來實(shí)現(xiàn)最大的價(jià)值。100沒有結(jié)對(duì)編程就沒有XP這是引進(jìn)XP時(shí)最難被接受的規(guī)則。但如果在采用其它XP的慣例和規(guī)則時(shí)，拋棄Pair Programming，那么會(huì)面對(duì)以下問題：如何進(jìn)行有效的Design Review如何進(jìn)行有效的Code Review如何保證代碼質(zhì)量如何保證流程的執(zhí)行如何增進(jìn)Communication如何進(jìn)行Cross-Training如何增強(qiáng)TeamworkDistributed Pair Programming分布式的Pair Programming: