第一部分軟件工程與過程(1-3)

1、課程總學時： 32課程性質：考 試先修要求：語言程序設計、數據結構 數據庫技術等主講老師：劉冬懿 聯(lián)系方式ldy_軟件工程教學方式：教學方式： 課堂講授（多媒體教學）；課堂講授（多媒體教學）； 學生上機實習；學生上機實習； 通過通過Email與與Web進行網上輔導。進行網上輔導。 考查方式：考查方式：平時成績平時成績10%（考勤）；（考勤）；作業(yè)成績作業(yè)成績20%（平時作業(yè)）（平時作業(yè)）期末考試占期末考試占70%。 課程教材課程教材作者：作者： 竇萬峰竇萬峰 出版社：機械工業(yè)出版社出版社：機械工業(yè)出版社 軟件工程導論軟件工程導論張海藩張海藩 清華大學出版社清華大學出版

2、社 參考書目參考書目 (References) 實用軟件工程實用軟件工程 （第二版）（第二版）鄭人杰、殷人昆、陶永雷鄭人杰、殷人昆、陶永雷 清華大學出版社清華大學出版社 軟件工程設計導論軟件工程設計導論-過程、原過程、原理與模式理與模式(UML2.0版版) (美美)Christopher Fox 清華大學出版社清華大學出版社 參考書目參考書目 (References)Introduction to the Personal Software ProcessWatts S.Humphrey吳超英等譯 人民郵電出版社人民郵電出版社 Introduction to the Team Software

3、 ProcessWatts S.Humphrey韓丹韓丹等譯 人民郵電出版社人民郵電出版社 參考書目參考書目 (References) Frederick P. Brooks著著 清華大學出版社清華大學出版社 Tom Demarco著著 清華大學出版社清華大學出版社 參考書目參考書目 (References)相關網站1 IBM開發(fā)者:http:/ UML China: http:/ 3 軟件工程俱樂部：/4 UML軟件工程組織：http:/ 5 軟件工程專家網：http:/ 中國系統(tǒng)分析員：http:/ 我們國家有30多所軟件學院，但是幾百

4、個高校都有計算機系，它們的區(qū)別主要是：計算機專業(yè)主要是計算機科學與工程，軟件學院主要是計算機軟件這個學科，而且軟件工程這個專業(yè)還要展開，比如：需求分析，面向對象的需求分析和設計，項目管理，進度控制，統(tǒng)一建模語言，文檔寫作等。軟件工程是不是背背就能過的課軟件工程絕對不是背背就能過的課，計算機理論可能是一個人就能研究出來，軟件工程是成千萬網軟件工程師幾十年來失敗的教訓凝結成的結晶。計算級專業(yè)的人必須具備任何語言1小時上手的能力，最起碼要在10分鐘把hello world做出來。 學好課程，只是萬里長征的第一步即使你學好了以上課程，我們仍然差得很遠，我們只弄清學什么了，但是還不知道做什么。所以我們要

5、盡可能的多做設計，別一個人們悶著頭做，兩三個人合作一個項目，不會交流的計算機人員30歲以后肯定會下崗。題目呢，盡量是一些簡單的底層開發(fā)，可以去國外大學網站上搜一搜，要自信你一定能做出來，畢竟不是什么難題，而是我們應當具備的素質。 竇萬峰計算機科學與技術學院南京師范大學2013年9月第一部分：軟件工程基礎什么是軟件工程？什么是工程化思想？什么是軟件過程？有哪些過程模型？如何選擇與建立過程模型？什么是統(tǒng)一過程？什么是敏捷過程？有哪些模型？什么是軟件工程實踐？第1章 軟件工程概述（內容提要）軟件的本質軟件工程的基本概念軟件工程化思想軟件工程兩大范型軟件工程思想與基本原理軟件工程基本活動什么是軟件？三

6、要素：軟件=程序+文檔+數據特性：復雜性一致性退化性易變性移植性高成本程序是按事先設計的功能和性能要求編寫的指令序列；數據是使程序能正常操縱信息的數據結構；文檔是與程序開發(fā)、維護和使用有關的圖文材料。軟件技術演化第一階段：程序設計階段。1946年到60年代初，其主要特征是程序生產方式為個體手工方式。 第二階段：程序系統(tǒng)階段。60年代初到70年代初，軟件工程學科誕生。軟件的開發(fā)方式由個體生產發(fā)展到了小組生產，軟件的開發(fā)與維護費用以驚人的速度增加，維護困難，導致軟件危機。第三階段：傳統(tǒng)軟件工程階段。20世紀70年代中期至80年代中期，軟件工程師把工程化的思想加入到軟件的開發(fā)過程中，用工程化的原則、

7、方法和標準來開發(fā)和維護軟件。第四階段：面向對象階段。20世紀80年代中期至今，面向對象的方法學受到了人們的重視，促進了軟件業(yè)的飛速發(fā)展，軟件產業(yè)在世界經濟中已經占有舉足輕重的地位。發(fā)展趨勢軟件服務多樣性：中間件開放性：新型中間件平臺軟件危機兩個方面的問題：如何開發(fā)軟件如何維護軟件表現：規(guī)模大復雜度增加需求量增大價格昂貴供需差增大開發(fā)速度慢質量難以保證軟件錯誤的實例ARIANE 5 火箭1996 年 6 月，耗資 70 億美元，發(fā)射 37 秒后爆炸發(fā)射失敗的原因在于軟件的錯誤 軟件錯誤程序中試圖將 64 位浮點數轉換成 16 位整數時產生溢出缺少錯誤處理程序對數據溢出進行管理備份軟件復制而成 嚴

8、格地遵守軟件確認過程可以避免這種錯誤9軟件錯誤的實例Therac 25 放射醫(yī)療儀事故 1986 年由于軟件錯誤導致放射過量，2 人死亡 溢出錯誤是導致問題的主要原因之一 千年蟲問題 迫于計算機存儲空間的限制，程序員將日期縮減為 2 位數 世界各地更換或升級 2000 年問題軟件的花費超過數億美元 其他 電子郵件的病毒 拒絕訪問等的網絡攻擊 網絡事務的安全問題11軟件危機解決途徑軟件危機解決途徑重視需求分析，明確與確切表達需求重視與客戶溝通與交流統(tǒng)一的、公認的方法論和規(guī)范指導重視設計和實現過程的資料充分的檢測工作軟件工程定義B.W.Boehm的定義：運用現代科學技術知識來設計并構造計算機程序及

9、為開發(fā)、運行和維護這些程序所必須的相關文件資料。Fritz Bauer的定義：軟件工程是為了經濟地獲得能夠在實際機器上有效運行的可靠軟件而建立和使用的一系列完善的工程化原則。1983年美國IEEE軟件工程標準術語的定義為：軟件工程是開發(fā)、運行、維護和修復軟件的系統(tǒng)方法，其中“軟件”的定義為：計算機程序、方法、規(guī)則、相關的文檔資料以及在計事機上運行時所必需的數據。軟件工程化思想軟件工程化思想把軟件看作是一個工程產品兩個方面：軟件開發(fā)技術軟件工程管理原因：缺乏軟件過程控制能力能力成熟模型（Capability Maturity Model）體現:工程化管理軟件工程的三要素軟件工程的三要素 軟件工程

10、以關注軟件質量為目標，包括過程、方法和工具三個要素。 過程 支持軟件生命周期的所有活動 方法 為軟件開發(fā)過程提供“如何做”的技術 工具 為軟件開發(fā)方法提供自動的或半自動的軟件支撐環(huán)境30方法質量工具過程軟件工程基本原理軟件工程基本原理推遲實現原理逐步求精原理分解與抽象原理信息隱蔽原理質量保證原理軟件工程基本原則軟件工程基本原則分階段的軟件生存周期堅持進行階段評審實行嚴格的產品控制采用現代程序設計技術明確職責開發(fā)小組的人員應少而精不斷改進開發(fā)過程軟件工程兩大范型軟件工程兩大范型結構化開發(fā)范型特征：結構化技術要么面向行為，要么面向數據構成結構化開發(fā)范型的技術包括：結構化分析結構化設計結構化編程結構

11、化測試結構化維護軟件工程兩大范型軟件工程兩大范型面向對象范型特征：將對象視作一個融合了數據及在其上操作的行為的、統(tǒng)一的軟件組件。技術包括：面向對象分析面向對象設計面向對象編程面向對象測試面向對象維護優(yōu)勢：對象的概念符合業(yè)務或領域的客觀實際維護容易結構化方法 vs. 面向對象方法計算機35測試問題域需求分析總體設計詳細設計編程自然語言傳統(tǒng)的編程語言分析與設計的鴻溝計算機問題域面向對象分析面向對象設計面向對象編程面向對象測試自然語言面向對象的編程語言重型與輕型軟件工程重型軟件工程文檔齊全規(guī)范化和程式化周期長推遲實現輕型軟件工程非正式交流重視代碼重視測試響應需求變化軟件工程活動軟件工程活動溝通活動計

12、劃活動建?；顒訉崿F活動部署活動維護活動管理活動過程改進活動小結軟件工程的是主旨以工程化的思想進行軟件開發(fā)，以生產高質量和高效率的軟件。軟件工程化思想的核心是，把軟件看作是一個工程產品。軟件工程方法學分別是傳統(tǒng)結構化范型和面向對象范型。軟件工程活動包括開發(fā)活動、管理活動和過程改進活動。第2章 軟件過程（內容提要）什么是軟件過程？什么軟件生命周期？能力成熟度模型敏捷過程結對編程軟件過程定義：軟件過程是為了開發(fā)出軟件產品，或者是為了完成軟件工程項目而需要完成的有關軟件工程的活動通常使用生命周期模型簡潔地描述軟件過程層次：軟件工程是一門建立在以質量焦點為基礎的層次化綜合技術過程:定義階段和管理方法:技

13、術支持工具:自動化實施支持軟件過程框架軟件過程框架定義：框架是實現整個軟件開發(fā)活動的基礎，并且那些與過程有關的角色、職責的定義以及實現也都離不開框架的支持兩個方面的內容組織及管理框架技術及工具框架軟件過程環(huán)境組織、管理的角色和職責技術環(huán)境軟件過程框架軟件過程框架組織與管理框架：過程改進活動及角色與職責技術與工具框架：技術及自動化活動工具框架活動：溝通策劃建模構建部署軟件生存周期過程（表2-1）系統(tǒng)語境的過程協(xié)議過程組（2個過程，13個活動，52個任務）項目過程組（7個過程，23個活動，72個任務）技術過程組（11個過程，26個活動，64個任務）組織上項目使能過程組（5個過程，15個活動，48個

14、任務）針對軟件開發(fā)的過程軟件實現過程組（7個過程，7個活動，39個任務）軟件支持過程組（8個過程，25個活動，68個任務）軟件復用過程組（3個過程，14個活動，62個任務）軟件過程模型軟件過程模型把軟件生命周期中各項開發(fā)活動的流程用一個合理的框架開發(fā)模型來規(guī)范描述，這就是軟件過程模型,也稱為軟件生命周期模型.軟件過程模型是一種就是軟件過程抽象.軟件過程模型是從一個特定的角度表現一個過程，一般使用直觀的圖形標識軟件開發(fā)的過程，主要根據軟件的類型、規(guī)模，特別是軟件的開發(fā)方法、開發(fā)環(huán)境等多種因素確立過程模型。軟件過程技術產品與過程選擇軟件過程過程評估CMMI/CMMISO9001:2000個人軟件過

15、程（PSP）：是一種可用于控制、管理和改進個人工作方式的自我持續(xù)改進過程，是一個包括軟件開發(fā)表格、指南和規(guī)程的結構化框架。團隊軟件過程(TSP)：幫助軟件開發(fā)組織建立成熟和紀律性的工程實踐，生產安全和可信的軟件個人軟件過程（PSP）內容PSP0是PSP的個人度量過程，其目的是建立個體過程基線。PSP1是個人規(guī)劃過程，引入了基于估計的計劃方法PROBE，用自己的歷史數據來預測新程序大小和開發(fā)時間，并使用線性回歸方法估計參數，確定置信區(qū)間以評價預測的可信程度。PSP2是個人質量管理，根據程序的缺陷建立檢測表，按照檢測表進行設計復查和代碼復查，以便及早發(fā)現缺陷，使修復缺陷的代價最小。PSP3的目標是

16、把個體開發(fā)小程序所能達到的生產效率和生產質量，延伸到大型程序。團隊軟件過程(TSP)TSP 采用了循環(huán)遞增的開發(fā)策略，整個軟件生產過程由多個循環(huán)出現的開發(fā)周期組成，每個開發(fā)周期劃分出若干個相對獨立的階段。TSP 提供了如下方法：計劃評審設計和編碼標準設計和代碼評審方法缺陷評審質量分析能力成熟度模型能力成熟度模型CMM(Capability Maturity Model)是指“能力成熟度模型”CMM是由美國卡內基梅隆大學的軟件工程研究所（SEI）開發(fā)的軟件成熟度模型。思想：管理軟件過程的方法不當引起的問題，導致新軟件技術的運用并不會自動提高軟件的生產率和質量。CMM為軟件企業(yè)的過程能力提供了一個

17、階梯式的改進框架，它基于過去所有軟件工程過程改進的成果，吸取了以往軟件工程的經驗教訓，提供了一個基于過程改進的框架。能力成熟度模型集成（CMMI-Capability Maturity Model Integration）是CMM模型的最新版本。CMM概述為企業(yè)的發(fā)展規(guī)定過程成熟級別，分為5級（Version 1.0）：初始級（Initial）：一般企業(yè)皆具有可重復級（Repeatable）：成功經驗可以重復定義級（Defined）：一套完整的企業(yè)過程，人員自覺遵守（培訓）管理級（Managed）：過程&產品可度量和控制優(yōu)化級（Optimizing）：過程持續(xù)改進從無序到有序、從特殊到

18、一般、從定性管理到定量管理、最終達到動態(tài)優(yōu)化CMM概述（續(xù)）2. Repeatable1. Initial3. Defined4. ManagedDisciplined ProcessStandard, Consistent ProcessPredictable ProcessContinuously Improving ProcessUnpredictable and poorly controlledCan repeat previously mastered tasksProcess characterized, fairly well understoodProcess measure

19、d and controlledFocus on process improvement5.OptimizingProject Management Integrated Engineering ProcessProduct and Process QualityManaging ChangeDisorder Disciplined Predictable Immature Mature CMM的概念模型關鍵過程域KPA：代表一組相關的工作（活動）。每個KPA都有一個確定的目標，完成該目標即認為過程能力的提高。一般特性CF（Common Features）：進一步細分KPA的工作。五個特性：承

20、諾（commitment）準備（ability）執(zhí)行（activity）度量分析（measurement & analysis）驗證（verifying implementation）CMM的五個級別Level 1：初始級過程無序且不可見OutInCMM的五個級別Level 2：可重復級Milestone可見，按計劃開發(fā)CMM的五個級別Level 2的6個KPA：側重于管理需求管理（Requirements Management）軟件項目計劃（Software Project Planning）軟件項目的跟蹤和監(jiān)控（Software Project Tacking and Oversi

21、ght）軟件子合同管理（Software Subcontract Management）軟件質量保證（Software Quality Assurance）軟件配置管理（Software Configuration Management）CMM的五個級別Level 3：定義級每個階段的內部活動可見標準過程和項目定義過程裁剪CMM的五個級別Level 3的7個KPA：工程過程企業(yè)理念機構過程關注（Organization Process Focus）機構過程定義（Organization Process Definition）培訓計劃（Training Program）集成軟件管理（Integr

22、ated Software Management）過程裁剪和定義軟件產品工程（Software Product Engineering）過程執(zhí)行組間協(xié)調（Intergroup Coordination）對等審查（Peer Reviews）CMM的五個級別Level 4 管理級過程可度量，預測值與結果之間的偏差可控CMM的五個級別Level 4的2個KPA：預測量化管理定量過程管理（Quantitative Process Management）過程度量軟件質量管理（Software Quality Management）產品度量CMM的五個級別Level 5 優(yōu)化級過程動態(tài)調整、新技術的采用C

23、MM的五個級別Level 5的3個KPA：動態(tài)優(yōu)化缺陷預防（Defect Prevention）技術改變管理（Technology Change Management）過程改變管理（Process Change Management）能力成熟度模型集成CMMI-Capability Maturity Model Integration是CMM模型的最新版本。CMMI有兩種表示方法：和軟件CMM一樣的階段式表現方法連續(xù)式的表現方法過程管理項目管理工程支持CMMI的目標是質量、時間表和最低的成本關鍵實踐CMM結構CMM標準的使用軟件過程的改進(SPI，Software Process Improv

24、ement)軟件過程評估(SPA，Software Process Assessment)軟件能力評價(SCE Software Capability Evaluation)敏捷過程敏捷不是一個過程，是一類過程的統(tǒng)稱。敏捷方法的兩大主要特征：對“適應性”的強調對“人”的關注做法：快速響應:引入迭代式的開發(fā)手段將整個軟件生命周期分解為若干個小的迭代周期獲取切實有效的客戶反饋提出12條基本原則敏捷開發(fā)12條原則我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。 經常性地交付可以工作的軟件，交付的間隔可以從幾個

25、星期到幾個月，交付的時間間隔越短越好。在整個項目開發(fā)期間，業(yè)務人員和開發(fā)人員必須天天都在一起工作。圍繞被激勵起來的個體來構建項目，給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。敏捷開發(fā)12條原則(續(xù))在團隊內部，最具有效果并富有效率的傳遞信息的方法，就是面對面的交談。工作的軟件是首要的進度度量標準。敏捷過程提倡可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應該能夠保持一個長期的、恒定的開發(fā)速度。不斷地關注優(yōu)秀的技能和好的設計會增強敏捷能力。 簡單是最根本的。 最好的構架、需求和設計出于自組織團隊。 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調整。極限編程

26、極限編程（eXtreme Programming，XP）是一種軟件工程方法學，是敏捷開發(fā)中最富有成效的方法學之一由KentBeck在1996年提出具有強溝通、簡化設計、迅速反饋等特點適合于規(guī)模小、進度緊、需求不穩(wěn)定、開發(fā)小項目的小團隊。極限編程特點：XP模型是“輕量型”或“靈活”的軟件過程模型與面向對象語言結合的開發(fā)方案“專家協(xié)作”的開發(fā)方式，解決難點問題重視客戶反饋核心有四個要點：交流簡單反饋勇氣交流開發(fā)人員與客戶的交流開發(fā)人員之間的交流使用結對編程開發(fā)人員與管理人員的交流簡單設計的簡單編碼的簡單注釋的簡單測試的簡單反饋客戶對軟件的反饋測試代碼對功能代碼的反饋先測試，后編程勇氣接受任務的勇氣

27、XP常見問題XP適合于小型項目（10人左右）?結對編程，搭檔如何安排?實施結對編程、集體代碼所有權之后，如何考核單個開發(fā)人員？77Pair Programming( 結對編程 )結對編程結對編程(Pair-Programming) 是XP中非常重要的實踐之一。定義：兩個人坐在同一臺計算機前面，使用相同的鍵盤和鼠標來開發(fā)同樣的一個模塊，一個稱為駕駛者(Driver)，負責代碼的鍵入，另外一個稱為領航員(Navigator)，負責監(jiān)看與決策，包括低級錯誤和方向性的錯誤。當出現的一個問題對其中一個人來說，難以解決，而恰好是另外一個人的強項的時候，那么角色就會發(fā)生轉換。Pair Programming

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

29、ogramming。Pair Programming的疑問Pair Programming和Solo Programming的比較一些研究數據：1999年，University of Uath.兩組學生，一組獨自工作，一組Pair Programming。Pair Programming的歷史 1995年，Larry Constantine在他的專欄中第一次提到了在他在P. J. Plaughers software company, Whitesmiths, Ltd觀察到一個現象：Collaborative Programming“兩個程序員一起工作，可以比以往更快的交出完成并經過測試的代碼

30、，而且這些代碼幾乎是沒有Bug的?！盋ollaborative Software Process（相對PSP）1996年，Kent Beck，Ward Cunningham 和Ron Jeffries一起提出了Extreme Programming（XP），其中吸收了Collaborative Programming，并稱為Pair Programming。Pair Programming是XP的一個key practice，也是XP成功的關鍵。隨著XP在世界范圍內被采用和練習，Pair Programming開始被接受。為什么要Pair Programming“The Human eye h

31、as an almost infinite capability for not seeing what it does not want to see Programmers, if left to their own devices, will ignore the most glaring errors in their output-errors that anyone else can see in an instant.” - Gerald Weinberg“Knowledge is commonly socially constructed through collaborati

32、ve efforts toward shared objectives or by dialogues and challenges brought about by difference in persons perspective” - Salomon“三個臭皮匠，勝過一個諸葛亮” - ?不間斷的不間斷的Code Review1. Peer Code Review，即程序員之間的互相Review缺乏Design Review不能持久,定時Code Review對需求和設計的不了解導致無法實現有效的Review2. Team Code Review什么時候開會做Review？不可能Team天

33、天開會無法對所有的設計和Code進行Review面子問題效率低傳統(tǒng)開發(fā)過程的Review（例如印度的InfoSys公司）的問題：不間斷的不間斷的Code ReviewPair Programming提供不間斷的Design review，Unit Test Review，Code Review，Document Review，避免了效果差的Team Code Review，也比抽查式的Peer Code Review有更好的質量。(CMM Level 3)Pair Programming中，任何一段代碼都至少被兩雙眼睛看過，兩個腦袋思考過。結合Collective code ownership

34、和小的Task (Small Engineering Task)，代碼被不斷的Review。編程方式編程方式避免cow boy式的編程好代碼的衡量標準：可讀性和可維護性硬件設備價格的下降和速度的提升，使得代碼效率不是考慮的重點（對大多數的商業(yè)應用）。對大部分的商業(yè)項目來說，更主要的顧慮是成本。而成本中人工占最大的比例。好的代碼可以減少修改的成本。Pair Programming的互相督促可以提高代碼的可讀性。Pair是一個最小單位的Team,而任何人都是工作在這樣一個Team中。Developer的言行都會影響到其他的Developer( Partner)，也受到其他Developer的影響。

35、Pair Programming避免了“我的Code”，使得代碼的責任不屬于某個人，而是屬于一個Pair和整個Team，從而做到Collective Code Ownership，也避免個人英雄主義。迫使程序員必須頻繁的交流，增進知識經驗的交流(Cross-Training)。團隊合作以人為本以人為本同伴的潛在壓力( Peer Pressure )。Pair Programming的過程也是一個互相督促的過程。由于這種督促的壓力，使得程序員更認真的工作。每個人每天的有效工作時段不超過3-4個小時。Pair Programming中Driver和Navigator的互換可以讓程序員輪流工作，從而

36、避免出現過度思考而導致觀察力和判斷力出現偏差。潛意識的有利競爭。當人在一個團隊中工作，總是下意識的努力展現自己的優(yōu)點。工作及時得到同伴的肯定，自信心和成就感(Self-Satisfaction)增強。覺得工作是一件愉快( Enjoyable )的事情。結對建議Extreme Programming對實施的程序員提出了更高的要求。這種要求不是技術水平，也不是學歷水平也不是工作經驗。這種要求是對一個人的心智，道德，修養(yǎng)的更高要求。程序員的四怕： 1) 怕自己看上去傻 2) 怕被認為是沒用的 3) 怕自己變的不重要（過時） 4) 怕自己不夠好Pair Programming中，編碼不再是私人的工作，

37、而是一種公開的“表演”。程序員的代碼，工作方式，技術水平都變得公開和透明。XP開發(fā)人員素質 一個XP開發(fā)人員具備這樣一些基本素質：誠實，公正，開明，勇敢和謙卑！在這些素質的基礎之上，才是對技術水平，能力和天分等的要求。誠實誠實 公正公正開明開明 勇氣勇氣 謙卑謙卑 具備這些素質才能克服“四怕”，才能成為一個成熟和專業(yè)的Developer。如何結對編程Driver 寫設計文檔(Class diagram等)，進行編碼(Unit Test and Business Object)等XP開發(fā)流程。Navigator 審閱Driver的文檔、Driver對編碼等開發(fā)流程的執(zhí)行；考慮Unit Test的

38、覆蓋程度；是否需要和如何Refactoring；幫助Driver解決具體的技術問題。Driver和Navigator不斷輪換角色，不要連續(xù)工作超過一小時，每一小時休息15分鐘。Navigator要控制開發(fā)時間。主動參與 雖然每個Engineering Task都有owner，但不能一旁觀者的心態(tài)來做。任何一個Task都首先是兩個人的責任，也是所有人的責任。沒有“我的Code”、”你的Code”或“她的Code”，只有“我們的Code”。如何結對編程只有水平上的差距，沒有級別上的差異。一個Pair,盡管可能大家的級別資歷不同，但不管在分析，設計或編碼，雙方都擁有平等的決策權利。Pairs之間互換

39、Partner。每個Task都應該和不同的Developer配對。每隔一天，甚至是半天，互換Partners。但Task的owner因該繼續(xù)留該Task的Pair中。如果Pair中的一人請假，另一人應盡量不要寫Production Code。Pair一起加班94沒有結對編程就沒有XPPair Programming是XP所有的Practices中最被爭議和被認為是最難接受。Pair Programming是獲得XP最大價值的關鍵。沒有Pair Programming,無法實現有效的Continuous Code Review,代碼質量下降。沒有Peer Pressure，流程的執(zhí)行很容易出現偏

40、差。沒有Pair Programming，Communication很容易弱化，進而影響Team work。Pair Programming象XP流程中的粘合劑，把各個環(huán)節(jié)連接起來實現最大的價值。95沒有結對編程就沒有XP這是引進XP時最難被接受的規(guī)則。但如果在采用其它XP的慣例和規(guī)則時，拋棄Pair Programming，那么會面對以下問題：如何進行有效的Design Review如何進行有效的Code Review如何保證代碼質量如何保證流程的執(zhí)行如何增進Communication如何進行Cross-Training如何增強Teamwork96Pair Programming和Open

41、SourceOpen Source現象:Open Source Project的代碼質量比很多的商業(yè)軟件（項目）都好。和Pair Programming的共性：有效的Code ReviewCollective code ownershipDistributed Pair Programming分布式的Pair Programming:兩個Programmers身處不同的物理位置，通過Sharing 軟件來實現Pair Programming。需要Sharing軟件能提供 桌面共享，文字交談，語音交談，甚至是視頻交流。目前這種方法還沒有被認可，主要出現在學校的關于XP的研究項目中.面臨的問題：I

42、nternet的網路延遲工作時段的約定Pair Programming和Solo Programming的比較雖然Pair Programming的學生在剛開始的階段比獨自工作的學生花在同樣Task的時間較多，但很快Pair Programming的學生的時間開始大幅度的下降。而獨立工作的學生需要花費比Pairs更多的時間來達到接近的代碼質量。Pair Programming和Solo Programming的比較比較研究項目后的問卷調查發(fā)現：Pair Programming能用較少的時間生產更高質量的代碼。Pair Programming的學生們認為自己比一個人的時候更勤奮和更聰明的工作，因

43、為不想讓自己的partner失望。Pair Programming的學生認為自己比一個人的時候更專著,緊湊和由紀律的工作，而且是持續(xù)的（因為來自Partner的Pair-Pressure）。而獨立工作的學生也可以專著和緊湊的工作，但往往不持續(xù)。Pair Programming的學生對自己的工作更有信心和成就感。Pair Programming的學生覺得工作很愉快，很愿意很partner一起工作。在緊張時間安排和繁重的工作壓力下，獨自工作的學生很容易蛻變?yōu)闆]有紀律的Programmer。Pair Programming是個漸進的過程有效率的Pair Programming不是一天就能做到的。Pa

44、ir Programming是一個相互學習，相互磨合的一個漸進過程。Developers需要時間來適應這種新的開發(fā)模式。剛開始的Pair Programming很可能不比Solo Programming有更高的效率。但適應后的Pairs的開發(fā)質量和開發(fā)時間都比Solo Programming有大幅度的改善。結對編程優(yōu)勢：可以減少風險可以使團隊生產效率更高是知識傳播的最好途徑可以打造出最佳的合作團隊。可以生成更好的代碼三個方面的應用：教育學結對學習工業(yè)界結對開發(fā)與編程分布式結對編程環(huán)境結對編程研究教育學研究結對編程學習效果研究結對雙方的相容性研究結對編程過程研究軟件工業(yè)界結對編程實踐方式社會動力

45、學研究個人編程能力的增強分布式結對編程結對編程開發(fā)環(huán)境研究開發(fā)結對編程工具的需求適合開展分布式結對編程的工具研究結對編程與測試驅動開發(fā)測試驅動開發(fā)（Test Driven Development,TDD）思想：開發(fā)之前首先完成測試用例編寫；然后編寫代碼和測試；測試通過后即需增加新功能。優(yōu)勢：測試優(yōu)先，保證質量結合結對編程結對編程與代碼重構重構就是代碼的重新設計。目的：得到好的代碼和架構，易修改、易理解適應需求結對編程：審查代碼理解代碼反饋結對編程與簡單設計簡單設計：達到目前需求即可結對編程可以達到簡單結對編程方法面對面結對編程分布式結對編程軟件工程實踐軟件工程實踐的精髓是理解問題、計劃解決方案

46、、實施計劃和檢查結果的精確度等方面通用的框架活動包括：溝通計劃建模部署普適性活動軟件工程實踐核心原則：存在價值保持簡潔維護視圖生產者要讓消費者理解面向未來計劃復用認真思考軟件工程實踐溝通實踐：包括決定項目涉及人的信息和溝通需求計劃實踐：是軟件開發(fā)過程的準備階段，包括定義問題、可行性分析、制定計劃模型實踐：創(chuàng)建分析模型和設計模型小結軟件工程是一種層次化技術，包括過程、技術和工具。軟件過程是為了獲得高質量軟件所需要完成的一系列任務的框架，它規(guī)定了完成各項任務的工作步驟。軟件過程框架定義了若干個小的框架活動，為完整的軟件開發(fā)過程建立了基礎。軟件過程框架的通用過程框架活動包括溝通、計劃、建模、構建和部

47、署。能力成熟度模型（CMM）是改進軟件過程的有效策略。它的基本思想是通過改進對軟件過程的管理來提高軟件生產率和軟件質量。敏捷方法是一組敏捷實踐技術的總稱，包括極限編程、自適應軟件開發(fā)、動態(tài)系統(tǒng)開發(fā)和特征驅動開發(fā)等等。軟件工程實踐包括概念、原則、方法和在整個軟件開發(fā)過程中所使用的工具。軟件工程實踐的通用框架活動包括溝通實踐、計劃實踐、建模實踐、構造實踐和部署實踐。第3章 軟件過程模型（內容提要）瀑布模型增量模型螺旋模型協(xié)同開發(fā)模型面向對象模型面向方面的軟件開發(fā)軟件生存周期軟件也有一個從生到死的過程，這個過程一般稱之為軟件的軟件生存周期或生命周期（Software Development Life

48、 Cycle）軟件生存周期可劃分為定義、開發(fā)和運行三個時期，每個時期又細分為若干個階段。把整個軟件生存周期劃分為若干階段，使得每個階段有明確的任務，使規(guī)模大，結構復雜和管理復雜的軟件開發(fā)變的容易控制和管理。軟件生存周期包括可行性分析、項目計劃、需求分析、軟件設計、編碼與測試、維護等階段，每個階段有包含一系列的活動。瀑布模型瀑布模型將軟件生命周期劃分為軟件計劃、需求分析和定義、設計、實現、測試、運行和維護這6個階段，規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水逐級下落。從本質來講，它是一個軟件開發(fā)架構，開發(fā)過程是通過一系列階段順序展開的，從系統(tǒng)需求分析開始直到產品發(fā)布和維護，每個階段都會

49、產生循環(huán)反饋.瀑布模型示意圖瀑布模型它是一個軟件開發(fā)架構，開發(fā)過程是通過一系列階段順序展開的。每個階段都會產生循環(huán)反饋各個階段產生的文檔是維護軟件產品時必不可少的，沒有文檔的軟件幾乎是不可能維護的。瀑布模型是一種文檔驅動的過程模型瀑布模型特點順序性和依賴性推遲實現質量保證的觀點是一種線性模型強調文檔的作用增量模型增量模型（Incremental Model）也稱為漸增模型，是在項目的開發(fā)過程中以一系列的增量方式開發(fā)系統(tǒng)。軟件被作為一系列的增量構件來設計、實現、集成和測試，每一個構件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構成.增量方式包括：增量開發(fā)：以一定的時間間隔開發(fā)部分工作軟件

50、增量提交：以一定的時間間隔增量方式向用戶提交工作軟件及相應文檔增量模型融合了線性順序模型的基本成份和原型實現模型的迭代特征。增量模型分為漸增模型和原型模型漸增模型是瀑布模型的變種，有兩類漸增模型：增量構造模型：它在瀑布模型基礎上，對一些階段進行整體開發(fā)整體開發(fā)，對另一些階段進行增量開發(fā)。前面的開發(fā)階段按瀑布模型進行整體開發(fā)，后面的開發(fā)階段按增量提增量提交交。演化提交模型：它在瀑布模型的基礎上，所有階段都進行增量開發(fā)增量開發(fā)，也就是說不僅是增量開發(fā)，也是增量提交增量提交。增量構造模型需求分析設計編碼1測試1測試2編碼2編碼3測試3螺旋模型螺旋模型（Spiral Model）是結合了瀑布模型和快速

51、原型模型的迭代開發(fā)模型強調了其他模型均忽略了的風險分析：風險識別風險分析風險控制特別適合于大型復雜的系統(tǒng)每一個周期都包括需求定義、風險分析、工程實現和評審螺旋模型示意圖螺旋模型活動四個象限分別代表了以下活動：制定計劃：確定軟件目標，選定實施方案，確定項目開發(fā)的限制條件； 風險分析：分析評估所選方案，考慮如何識別和消除風險；實施工程：實施軟件開發(fā)和驗證；客戶評估：評價開發(fā)工作，提出修正建議，制定下一步計劃。螺旋模型是風險驅動的模型面向對象過程模型面向對象過程模型面向對象是一種的程序設計方法，或者說它是一種程序設計范型。基本思想是使用對象，類，繼承，封裝，消息等基本概念來進行程序設計。面向對象的要

52、素： 抽象：強調實體的本質、內在的屬性，忽略一些無關緊要的屬性。類實現了對象的數據（即狀態(tài)）和行為的抽象，是對象的共性的抽象。封裝性：指所有軟件部件內部都有明確的范圍以及清楚的外部邊界。 共享性：面向對象的特征：對象惟一性；分類性；繼承性；多態(tài)性（多形性）。統(tǒng)一過程統(tǒng)一過程A software development process：是一個將用戶需求轉是一個將用戶需求轉化為軟件系統(tǒng)所需要的活動的集合?；癁檐浖到y(tǒng)所需要的活動的集合。A process framework：一個簡單的過程，也是一個通用一個簡單的過程，也是一個通用的過程框架。的過程框架。Component-based：軟件構件軟件

53、構件+接口接口The standard - employing the UML（Unified Modeling Language）use-case drivenarchitecture-centriciterative and incrementalThe Evolution of the Unified Process1967: a predecessorof Objectory1976-80: formalization &generalization1997: Objectory 4.11987-95: Objectory 1.0-3.8SDLA book: The Unifi

54、ed ProcessA product: The Rational Unified Process1998: Unified ProcessOMTBoochRationals best practices: Kruchten Royce and many othersThe Next Industry StandardA Software Development ProcessSoftware development is the process of developing software from requirements.New or changedrequirementsNew or

55、changed systemSoftware DevelopmentProcess統(tǒng)一過程是用況驅動的用況模型(use case model)要素:用戶（user）用況（use case）動作（action）用況驅動（use-case driven）：用況可以驅動開發(fā)過程：用況不只是確定系統(tǒng)需求的工具，還能驅動系統(tǒng)設計、實現和測試的進行。不能孤立地選擇用況UC: 吃晚餐 用戶動作 系統(tǒng)響應 點餐上開胃菜上主餐請上點心上點心買單結賬開收據拿走收據統(tǒng)一過程是以構架為中心的軟件構架包含了系統(tǒng)中最重要的靜態(tài)和動態(tài)特征構架刻畫了系統(tǒng)的整體設計，突出系統(tǒng)的重要特征構架的價值依賴于執(zhí)行該任務的人的素質過程可以幫助構架設計師確定正確的目標用況和構架的關系：用況對應功能(function)構架對應表現形式（form）用況和構架相互影響，并必須進化統(tǒng)一過程是以構架為中