软件生命周期模型08611.pptVIP

? 2009 BUPT TSEG 北京邮电大学 通信软件工程中心 2.5.2 敏捷模型 (7)在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈；工作的软件是首要的进度度量标准；敏捷过程提倡可持续的开发速度； (8)责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度； (9)不断地关注优秀的技能和好的设计会增强敏捷能力； (10)简单是最根本的； (11)最好的构架、需求和设计出于自组织团队； (12)每隔一定时间，团队会在如何才能更有效地工作方面进行反省，对自己的行为进行调整。 ? 2009 BUPT TSEG 北京邮电大学 通信软件工程中心 2.5.2 敏捷模型 敏捷建模核心实践 项目干系人的积极参与 正确使用工件 集体所有制 测试性思维 并行创建模型 创建简单的内容 简单地建模 公开展示模型 切换到另外的工件 小增量建模 和他人一起建模 用代码验证 使用最简单的工具 ? 2009 BUPT TSEG 北京邮电大学 通信软件工程中心 2.5.2 敏捷模型 敏捷模型补充实践： 使用建模标准 逐渐应用模式（pattern） 丢弃临时模型 合同模型要正式 为外部交流建模 为帮助理解建模 重用现有的资源 不到万不得已不更新模型 ? 2009 BUPT TSEG 北京邮电大学 通信软件工程中心 极限编程 极限编程(eXtreme Programming，XP)是敏捷模型的一种实现过程，由Kent?Beck在1996年提出 。 ? 2009 BUPT TSEG 北京邮电大学 通信软件工程中心 极限编程 极限编程的12个实践 ： （1）小版本。为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。 （2）规划游戏。就是客户需求，以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，开发人员进行分析，设定优先级别，并进行技术实现。当然游戏规则可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。 ? 2009 BUPT TSEG 北京邮电大学 通信软件工程中心 极限编程 （3）现场客户。极限编程要求客户参与开发工作，客户需求就是客户负责编写的，所以要求客户在开发现场一起工作，并为每次迭代提供反馈。 （4）隐喻。隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异。 （5）简单设计。极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的迭代周期就会加长。 ? 2009 BUPT TSEG 北京邮电大学 通信软件工程中心 极限编程 （6）重构。重构是极限编程先测试后编码的必然需求，为了整体软件可以先进行测试，对于一些软件要开发的模块先简单模拟，让编译通过，到达测试的目的。然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。 （7）测试驱动开发。极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。 （8）持续集成。集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成(整体测试)是与客户沟通的依据，也是让客户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。 ? 2009 BUPT TSEG 北京邮电大学 通信软件工程中心 极限编程 （9）结对编程。这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个编码，一个检查，增加专人审计是为了提供软件编码的质量。两个人的角色经常变换，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。 （10） 代码共有。在极限编程里没有严格文档管