軟件工程基礎與案例教程

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

Disciplined

Predictable

Immature

Mature

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

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

簡單是最根本的。

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

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

993.4結對編程

(PairProgramming

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

……另一方面：

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

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

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

編程方式避免cowboy式的編程好代碼的衡量標準：可讀性和可維護性對大部分的商業項目來說，更主要的顧慮是成本。好的代碼可以減少修改的成本。互相督促可以提高代碼的可讀性。

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

1)怕自己看上去傻

2)怕被認為是沒用的

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

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

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

公正開明勇氣

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

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

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

需求獲取內容提要關于用戶需求和軟件需求需求獲取過程基于會談的需求獲取方法基于調查的需求獲取方法基于場景的需求獲取方法基于用例的需求獲取方法4.1關于用戶需求和軟件需求用戶需求：業務需求與源于系統的特定領域的需求用戶需求是站在用戶角度描述軟件必須要完成的業務需求，通過使用實例文檔或場景說明中予以詳細描述。軟件需求：從軟件角度來看，用戶希望軟件能夠完成哪些功能和受到哪些約束，稱為軟件需求功能需求：描述系統預期提供的功能或服務非功能需求：指那些不直接與系統具體功能相關的一類需求業務需求領域需求反映應用領域的基本問題，直接影響到系統的可用性。例如：圖書館系統的功能需求基于標準用戶界面將一些文檔輸出到本地打印機或網絡打印機上，但因為版權限制，這些文檔打印之后應立即刪除。功能需求軟件系統的功能需求描述可以有許多方式：文字描述圖表表示功能需求可以以不同的詳細程度反復編寫和細化功能需求描述應該完整而且一致和準確完整性意味著用戶所需的所有的服務應該全部給出描述一致性意味著需求描述不能前后矛盾準確性是指需求不能出現模糊和二義性的地方4.2需求獲取過程需求獲取主要是理解客戶需要什么、分析要求、評價可行性、協商合理的方案、無歧義地詳細說明方案、確認規格說明、管理需求以至將這些需求轉化為可行系統.過程包括：溝通導出需求精化需求可行性研究與客戶和用戶協商編寫需求規格說明驗證需求管理需求溝通業務領域的共利益者（如業務管理人員，市場營銷人員，產品管理人員）定義業務用例確定市場的范圍初略地可行性分析確定項目范圍的工作說明導出需求導出需求應理解問題范圍問題：系統的邊界，是客戶和開發者共同關心的部分理解問題：確定業務需求、需求沖突、說明有歧義和不可測試的需求易變問題：分清需求穩定部分和易變部分收集活動：識別真正的客戶/用戶正確理解客戶的需求耐心聽取客戶意見和思考盡量使用符合客戶語言習慣的表達精化需求開發一個精確的技術模型，用以說明軟件的功能、特征和約束。精化是一個分析建模動作，由一系列建模和求精任務構成定義了問題的信息域，功能域和行為域可行性研究可行性研究的目的是確定用最小的代價，在盡可能短的時間內確定問題是否能夠解決可行性研究的輸入是系統的一個框架描述和高層邏輯模型輸出是一份需求開發評價報告，對需求工程和系統開發是否值得做的具體建議和意見三個問題：系統是否符合機構的總體要求？系統是否可以在現有的技術條件、預算和時間限制內完成？系統能否把已存在的其他系統集成？與客戶和用戶協商調節沖突和問題需求排序識別和分析與每項需求相關的風險、開發工作量、成本和交付時間編寫軟件需求規格說明一個規格說明可以是一份寫好的文檔、一套圖形化的模型、一個形式化的數學模型、一組使用場景、一個原型或以上各項的任意組合。軟件需求規格（SRS，SoftwareRequirementSpecification）是需求分析任務的最終“產品”，它是客戶、管理者、分析工程師、測試工程師、維護工程師交流的標準和依據。軟件需求規格描述了系統的數據、功能、行為、性能需求、設計約束、驗收標準、以及其他與需求相關的信息。SRS模板，包括用戶需求和系統需求（表4-1）需求規格文檔標準（表4-1）1引言1.1編寫目的1.2項目背景（單位和與其他系統的關系）1.3定義（專門術語和縮寫詞）2任務概述2.1目標2.2運行環境2.3條件限制3數據描述3.1靜態數據3.2動態數據3.3數據庫描述3.4數據字典3.5數據采集

4功能需求

4.1功能劃分4.2功能描述5性能需求5.1數據精確度5.2時間特性5.3適應性6運行需求5.1用戶界面5.2硬件接口5.3軟件接口5.4故障處理7其他需求（檢測或驗收標準、可用性、可維護性可移植性、安全保密性）驗證需求驗需求證對需求文檔和制品進行質量評估，確保需求說明準確、完整.包括以下內容：正確性一致性完整性可行性必要性可檢驗性需求的可跟蹤性最后簽字確認管理需求管理需求是組織、控制和文檔化需求的系統方法.建立基線以便在客戶和開發人員之間構建一個約定.需求管理從標識開始，建立跟蹤表.需求跟蹤表可以跟蹤需求的特征、來源、依賴、子系統和接口等關系.4.3基于會談的需求獲取方法非正式會談：提出一些可自由回答的問題.正式會談：提出一些事先準備好的議題.情景分析：需求分析從對場景的評論中得到信息，然后再將其以形式化方式表示出來。使用用例建立原型界面序列執行過程視點分析接受系統服務的當前銀行客戶；銀行間自動柜員機有互惠協議的其他銀行的代表；從該系統中獲得管理信息的銀行支行管理者；負責系統日常運轉和處理客戶意見的支行柜臺職員；負責系統和客戶數據庫集成的數據庫管理者；負責保證系統信息安全的銀行信息安全管理者；將該系統視為銀行市場開拓手段的銀行市場開發部；負責硬件和軟件維護及升級的硬件和軟件維護工程師多視點的需求分析過程視點識別：包括發現接收系統服務的視點和發現提供給每個視點的特別服務。視點組織：包括組織相關的視點到層次結構中，通用的服務放在較高的層次，并被較低層次的視點繼承。視點文檔編寫：包括對被識別的視點和服務描述的精煉。視點系統映射：包括在面向對象設計中通過封裝在視點中的服務信息識別對象。4.4基于調查的需求獲取方法制定調查表可靠可信分析4.5基于場景的需求獲取方法分析員與項目相關人員共同識別出情景，并捕獲這些情景的細節把細節加入到一個綱要的需求描述中時，情景特別有用情景是對交互實例片斷的描述，每個情景可能包含一個或多個交互，它們能在不同的細節層次上提供不同類型的情景信息情景開始于一個框架，在導出過程中，細節被逐漸增加，直到產生交互的一個完整的描述情景內容在情景開始部分有一個系統狀態描述；關于標準事件流的描述；關于哪兒會出錯，以及如何處理錯誤的描述；有關其他可能在同一時間進行的活動的信息；在情景完成后系統狀態的描述場景名：取款參與者：銀行客戶場景描述：1．插入有效的銀行卡；2．ATM機驗證該銀行卡；3．系統要求輸入銀行卡密碼，用戶輸入密碼；4．系統通過網絡向銀行內部系統請求驗證密碼；5．若驗證通過，系統請求選擇業務，選擇取款；6．系統要求輸入取款金額，比如1000元；7．系統驗證是有足夠的現金，并請求驗證銀行內部服務器處理取款；8．若處理成功，系統計算鈔票數目，并送出現金；9．用戶取走現金；10．系統打印憑條，用戶取走憑條；11．系統退出銀行卡，用戶取走銀行卡。4.6基于用例（用況）的需求獲取方法需求捕獲的目標：發現真正的需求以適用于用戶、客戶和開發人員的方式加以表示系統用戶表示為一個參與者參與者在與用例進行交互時使用系統用例向參與者提供某些有價值結果而執行一些動作序列用例分析過程用例建模分析開發活動圖開發泳道圖用例分析用例著眼于為用戶增加價值，提供了一種捕獲功能需求的系統且直觀的方法，可驅動整個開發過程。用例從某個特定參與者的角度用簡單易懂的