软件工程基础与案例教程 课件 第一部分 软件工程基础（1-4）

软件工程基础与案例教程

(微课视频版)第一部分：软件工程理论基础什么是软件工程？软件工程的思想是什么？软件工程有哪些基本原理和原则？软件过程与过程模型的关系是什么？什么是敏捷软件开发？如何进行用例建模？第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基于用例（用况）的需求获取方法需求捕获的目标：发现真正的需求以适用于用户、客户和开发人员的方式加以表示系统用户表示为一个参与者参与者在与用例进行交互时使用系统用例向参与者提供某些有价值结果而执行一些动作序列用例分析过程用例建模分析开发活动图开发泳道图用例分析用例着眼于为用户增加价值，提供了一种捕获功能需求的系统且直观的方法，可驱动整个开发过程。用例从某个特定参与者的角度用简单易懂的