系统分析与设计极限编程

1、极限编程eXtreme Programming主要内容 系统开发方法 系统开发生命周期22软件开发方法演变 结构化开发方法 面向对象开发方法 面向服务开发方法3结构化开发方法 早期的软件设计往往是程序员的个人英雄的单打独斗，一个程序往往就代表了一个软件，这个独立的程序包括了用户界面、应用逻辑、通信和数据管理的所有功能。结构化开发方法也称为面向过程的开发方法，要开发一个应用系统，首先将该系统划分为多个功能块，每个功能块下面又可以划分为多个子功能，然后以功能为主线开发各个模块，将这些模块组合起来就构成了完整的应用系统。由于结构化方法开发的系统是紧内聚的系统，即软件内部各部分之间是通过调用等方法紧密

2、集成的，所以一个复杂的软件系统往往其内部的逻辑十分复杂。 结构化程序开发的核心思想可以概括为： 程序=算法+数据结构4 软件工业的发展导致结构化开发方法遇到了最大的困惑：软件的可复用性不好。一个软件系统的组成部分很难被复用到其他软件系统的开发中，这一切都是因为结构化方法是以“功能”来划分软件系统的组成部分的，这样的开发方法适应小作坊式的小系统的开发，而对于流水线式的软件开发就远远不够了。5面向对象开发方法 现实世界是由一个一个的个体组成的，这些个体称为对象，比如人、车辆、房子等，对象之间有各种联系。软件系统也是如此，所以不应该从面向功能的角度来开发软件，这样就忽视了软件系统的本来结构。面向对象

3、方法把软件系统设计为一个一个的对象，研究对象之间有这样那样的关联。 面向对象的开发方法好比是工业流水线生产中先制作一个一个的模板，称为类，类的内部是各种属性和方法，是高内聚的。类与类之间是低耦合的，即互相之间几乎没有什么联系，一个类的修改几乎不影响其他类，一个一个的类可以很好地被复用。在类的基础上根据不同的软件系统进行实例化，称为对象。使用若干个对象来构建一个真正的软件系统。将软件系统设计为可以高度封装并继承的类，既符合软件系统的认识本质，同时也很好地解决了软件的复用问题。6 一段时间以来，面向对象的方法好像成了万能的开发方法。随着认识的深入，基于Internet和Intranet网络诞生的一

4、些新的应用，比如，ERP（企业资源计划）、EAI（企业应用集成）等又对软件系统的复用提出了新的要求。这些系统往往都是由一个一个的软件系统通过网络集成起来的，往往复用的粒度要比类宽泛得多。在这样的系统中，类作为软件复用的单位是否就是最恰当的？7 网络是由电子邮件、Web网站、网络电子商务等各种各样的网络服务组成。各种各样的网络服务构成了丰富多彩的网络世界。可以将服务作为软件系统的复用单位，设想一下构建EAI、ERP这样的系统是否会更有意义？8面向服务开发方法 面向服务的开发方法认为基于网络的各种软件系统实际上都是由各种网络服务构建起来的。软件公司可以通过网络发布各种各样的服务，开发人员在网络上各

5、取所需，寻找与自己系统相关的服务组合起来就可以构建自己的软件系统。这就是微软在Visual Studio 2005中大力倡导的XML Web Service技术。 XML Web Service技术发展的一个美妙场景是：软件系统的开发不再是少数专业人员和公司的专利，开发人员也无须掌握多么深奥的开发技术，只需要在网络上订购相关的服务，然后将这些服务组合成自己的系统就可以。9与面向对象开发方法的比较 其实两者是从不同的力度来考察软件的开发方法，并不矛盾。面向服务的力度比面向对象要宽泛，也就是说，一般情况下，一种网络服务很可能是由若干个类组成的，极端情况下，一个服务就是由一个类提供的。 面向服务的开

6、发方法还有一个重要的特点就是可以让开发人员集中精力考虑软件系统的实现逻辑，而不是拘泥于具体的技术细节。10主要内容 系统开发方法 系统开发生命周期1111软件开发是一种对人类智慧的管理，对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的工作单元，这与冰冷的机器是不可比的，所以在中国的历史上，管理人是最难的工作；“学而优则仕”的观点就是让最聪明的人应该选出来做官，做官就是管理人的。软件开发不仅是代码编程，而是人员的有效组织，如何既发挥人的主观能动性，避免情绪变化对工作的影响，又可以让大家有效的交流，让多个大脑的思路统一，快速完成目标呢？多年来软件企业的管理者一直在不断地探索

7、。12软件开发过程中会遇到的问题1.疲于应付变化的需求满足需求变化增加软件价值、需求细化于发现新知识的时候、合理的需求规模、迭代式地挖掘、细化和实现需求、应用敏捷实践使代码的设计简洁和灵活，易于变化（测试驱动开发，持续集成，结对编程）2.质量不尽如人意质量产生于开发过程，而非后期测试、质量产生于简约的设计，而非补丁、全员参与质量保证、测试提前，频繁，自动化地进行（TDD，持续集成）、频繁、小量的重构持续优化设计3.无法按时交付及时交付可用功能为客户创造更多价值、成功交付前的所有工作都不能称为“完成”、频繁交付，迭代式开发、持续集成，确保软件随时处于“可用”状态13瀑布模型瀑布模型(Waterf

8、all Model)是Royce在1970年提出的，他把大型软件开发分为：分析与编程，象工厂流水线一样把软件开发过程分成各种工序，并且每个工序可以根据软件产品的规模、参与人员的多少进一步细分成更细的工序。该模型非常符合软件工程学的分层设计思路，所以成为软件开发企业使用最多的开发模型。14极限编程诞生于一种加强开发者与用户的沟通需求，让客户全面参与软件的开发设计，保证变化的需求及时得到修正。要让客户能方便地与开发人员沟通，一定要用客户理解的语言，先测试再编码就是先给客户软件的外部轮廓，客户使用的功能展现，让客户感觉到未来软件的样子，先测试再编码与瀑布模型显然是背道而驰的。同时，极限编程注重用户反

9、馈与让客户加入开发是一致的，让客户参与就是随时反馈软件是否符合客户的要求。有了反馈，开发子过程变短，迭代也就很自然出现了，快速迭代，小版本发布都让开发过程变成更多的自反馈过程，有些象更加细化的快速模型法。当然极限编程还加入了很多激励开发人员的“措施”，如结队编程、40小时工作等。15敏捷软件开发与极限编程 敏捷软件开发概述 敏捷方法与规范化方法的关系 极限编程实践案例16 一些经验丰富的软件设计师在应对快速交付、需求易变的开发要求实践中分别总结出自己独特且有效的软件开发方法，被业界概括为敏捷软件开发方法。其中以“极限编程”最为流行。17敏捷软件开发 敏捷软件开发方法其实不是一个具体的过程，而是

10、一个涵盖性术语。用于概括那些应需而生的具有类似价值观的软件开发方式和方法，这些方法一般都具有以人为核心、循环迭代、响应变化等特点，着眼于能高质量地快速交付客户满意的工作软件。18敏捷联盟2001年初，一批业界专家聚集在一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷(Agile)联盟。在随后的几个月中，他们创建出了一份价值观声明。也就是敏捷联盟宣言(The Manifesto of theAgile Alliance)。19敏捷联盟宣言我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为： 个体和交互 胜过 过程和工具

11、 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 虽然右项也有价值，但我们认为左项具有更大的价值20敏捷联盟宣言个体和交互胜过过程和工具人是获得成功的最为重要的因素。合作、沟通以及交互能力要比单纯的编程能力更为重要。21敏捷联盟宣言 可以工作的软件胜过面面俱到的文档 没有文档的软件是一种灾难。 过多的文档比过少的文档更糟22敏捷联盟宣言客户合作胜过合同谈判指明了需求、进度以及项目成本的合同存在根本上的缺陷。成功的项目需要频繁有序的客户反馈。为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。23敏捷联盟宣言响应变化胜过遵循计划计划赶不上变化。响

12、应变化的能力决定一个项目的成败。较好的做计划策略是：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。24“敏捷联盟”的价值观可见，敏捷的软件开发方法的理念是，在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品的方法；在满足软件质量要求的前提下，力求适应变化和提高开发效率。25敏捷软件开发的原则1. 敏捷开发而言，最重要的是通过尽早和不断交付有价值的软件来满足客户的需求。2. 敏捷开发欢迎需求的变化，即使是开发后期。敏捷过程能够驾驭变化并以此为客户创造竞争优势。3. 经常交付可以工作的软件，从几个星期到几个月，时间间隔越短越好。4. 业务人员和开发人员应该在

13、整个项目过程中始终朝夕在一起工作。5. 围绕斗志高昂的人进行软件开发，给他们提供适宜的环境，满足他们的需要，并相信他们能够完成任务。266. 在团队中，最有效率也最有效果的信息表达方式是面对面的交谈。7. 可以工作的软件是进度的主要度量标准。8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该总是维持不变的节奏。9. 对优秀的技能与好的设计的不断追求将有助于提高敏捷能力。10. 简单尽可能减少工作量的艺术是至关重要的。11. 最好的架构、需求和设计都源自自组织的团队。12. 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。27敏捷方法与规范化方法的关系 “敏捷宣言”把

14、关注的焦点从传统的计划驱动、基于过程的方法转移到更轻量、适应性更强的开发范型。 但并不意味着可以忽略对传统方法中强过程规范和严格准则的需要，这些软件开发方法为规范软件开发的过程，提高软件项目的成功率起了重要的作用。28 如同过于繁琐与官僚化的过程和文档阻碍软件开发一样，过度地强调简单与抛弃文档也会对软件项目造成伤害。 纯粹的敏捷开发方法同样要求软件企业组织管理能力和开发人员个人非常高的素质 传统的计划驱动方法的擅长领域通常是大型、复杂的系统，这些系统时常具有关键的安全性或者其他高可靠性的属性。需求应该相当稳定，环境也具有相当的可预见性。 敏捷方法则更适用于那些系统和开发团队规模较小、客户和系统

15、的使用者随时可以到位、需求和环境容易变化的项目。29 为了维持相关性并符合客户的需要和期望，国防和其他大型系统必须找到适当的途径在它们的方法学中融合敏捷性。但仍必须把规范作为适应性的基础。 典型地，可以将敏捷方法与统一软件开发过程(RUP)等规范方法相结合。比如，RUP作为整体框架，负责最初前景分析、商业计划，敏捷建模负责业务建模，具体开发使用XP等敏捷方法。而在整个项目的项目管理、配置管理、质量管理使用RUP。进一步可将SW-CMM作为整个过程改进的目标，根据CMM五级目标可以制定与过程改进相符的阶段目标和长远目标。30代表性的敏捷开发方法 极限编程(eXtreme Programming，

16、简称XP) 特征驱动软件开发（Feature DrivenDevelopment，简称FDD） 动态系统开发（Dynamic Systems Development Methodology，简称DSDM) 自适应软件开发(Adaptive Software Development，简称ASD) SCRUM Crystal31极限编程极限编程(eXtreme Programming,简称XP)是敏捷方法中最著名的一个。它由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个敏捷开发过程。由Kent Beck提出，是Agile方法中最引人注目的一个，XP最初实践于1997年Crysler公

17、司的C3项目(Smalltalk开发），适用于10人以下项目组、开发地点集中的场合，广泛用于需求模糊和挥发性强的场合，IONA公司的Obix技术支持小组在采用了XP方法后，软件生产率提高了67%。32典型敏捷方法极限编程(XP) XP方法的基础是4个价值观念： 沟通。大多数项目的失败源于沟通不畅，所以要进行一些能够推动积极沟通的实践。 简单。开发能够满足客户需要的最简单的产品。 反馈。开发者必须要获取并且重视来自客户、系统的反馈以及相互之间的反馈。 勇气。准备好做出支持其他原则和实践的艰难决定。33 XP在4个价值观之上，又定义12个的必须遵循的实践： 1. 完整团队：XP项目的所有参与者（开

18、发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。 2. 计划游戏：计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。 3. 客户测试：作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。34 4. 简单设计：团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。 5. 结对编程：所有的产品软件都是由两个

19、程序员、并排坐在一起在同一台机器上构建的。 6. 测试驱动开发：编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。35 7. 改进设计：随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。 8. 持续集成：团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。 9. 集体代码所有权：任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个

20、人都可以参与任何其它方面的开发。36 10. 编码标准：系统中所有的代码看起来就好像是一人单独编写的。 11. 隐喻：将整个系统联系在一起的全局视图的概念。它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。 12. 可持续的速度：团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，把项目看作是马拉松长跑，而不是全速短跑。37 极限编程是一组简单、具体的实践，这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些

21、实践进行修改后再采用。极限编程把软件开发过程重新定义为聆听、测试、编码、设计的迭代循环过程，确立了测试-编码-重构(设计)的软件开发管理思路。38极限编程实践细则极限编程的12个核心实践具体分来有如下四个方面一些细则内容：1. 计划 写出用户素材； 根据发布版本计划编制进度表； 频繁发布小版本: 度量项目速度； 这个项目划分为多个迭代； 每次迭代开始前制定迭代计划； 角色互换； 每日立式晨会； 根据项目情况对XP作出调整。39极限编程实践细则2. 设计 简单； 选取一个系统比喻； 在设计会上使用CRC卡片； 通过探针方案降低风险； 不要过早加入任何功能； 尽可能的进行重构。40极限编程实践细则

22、3. 编码 客户一直在场； 代码必须符合相应的编码标准； 首先编写单元测试； 必须实行结对编程； 严格的串行代码集成； 频繁地进行代码集成； 实行代码共有制； 将优化工作留到最后； 不要加班。41极限编程实践细则4. 测试 所有代码必须有单元测试； 所有代码发布前必须100%通过所有对应的单元测试； 发现了错误必须要增加相应的测试； 经常运行接受测试并且公布其结果。42XP方法的12个核心实践1.完整的团队（Whole Team）：所有的小组成员应在同一个工作地点工作，成员中必须有一个现场用户（On-site User），由他提出需求，确定开发优先级，通常还设一个“教练”（Coach）角色，教练指导XP方法的实施，以及与外部的沟通和协调2.计划对策（Planning Game）：包括两类：发布计划和迭代（Iteration）计划3. 系统比喻（Metaphor）：系统比喻是待开发软件的一个每个成员都熟悉的形象化比喻，相当于一个粗略的软件体系结构4. 小发布（Small release）：经常、不断地发布可运行的、具有商