极限编程中的质量控制

摘要：极限编程是近年来非常流行的敏捷软件开发方法，与其它敏捷软件开发方法一样，强调软件开发过程的自适应性和以人优先的价值观[1]，这与传统的重量级软件开发方法强调对开发过程的控制相反。那么，敏捷软件开发方法能否开发出高质量的软件产品呢?本文探讨在极限编程中如何进行软件质量控制，既保持“敏捷”的特点，又能作为一种成熟的软件开发过程，为客户提供高质量的软件产品。

　　Abstract: Extreme Programming is the most popular method among all the Agile Software Development methods, which are characterized by the self-adaptive nature and people-first orientation[1]. Can Agile Methods provide same quality product such like the process-oriented heavyweight method? This paper explores the potentiality of Extreme Programming to produce high quality software, and discuss how to control software quality in Extreme Programming and make it become a mature software process while still keeps agile.

　　关键字：

　　极限编程 质量控制 过程控制 软件过程成熟度模型

　　Keywords:

　　Extreme Programming Quality Control

　　Process Control CMM

　　1. 概述

　　1.1 极限编程

　　极限编程是基于简洁、交流、反馈和勇气4个价值观的一种敏捷软件开发方法。它以其13个核心实践为标志[2]：

　　1)现场客户(On-site Customer)：要求至少有一名实际的客户代表在整个项目开发周期在现场负责确定需求、回答团队问题以及编写功能验收测试;

　　2)计划博弈(Planning Game)：将软件开发过程划分成许多迭代周期，在每一个迭代周期前结合项目进展和技术情况，确定下一周期要开发与发布的系统范围;

　　3)小型发布(Small Release)：强调在非常短的周期内以递增的方式发布新版本，从而可以很容易地估计每个迭代周期的进度，便于控制工作量和风险，同时，也可以及时处理用户的反馈;

　　4)客户测试(Customer Tests)：在每次小型发布之前，由客户编写测试用例，参加产品的合格性测试;

　　5)简单设计(Simple Design)：代码的设计尽可能的简单，只要满足当前功能的要求，不多也不少;

　　6)结对编程(Pair Programming)：由两个开发人员在同一台电脑上共同编写解决同一问题的代码，通常一个人负责写编码，而另一个负责保证代码的正确性与可读性;

　　7)测试驱动(Test-Driven Development)：强调"测试先行"(Test Before)。在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都得以通过;

　　8)设计重整(Refactoring/ Design Improvement): 又称代码重构，在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能;

　　9)持续集成(Continuous Integration)：提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试;

　　10)代码集体拥有(Collective Code Ownership)：开发小组的每个成员都有更改代码的权利，所有的人对于全部代码负责;

　　11)代码规范(Coding Standard)：强调通过指定严格的代码规范来进行沟通，尽可能减少不必要的文档;

　　12)系统隐喻(System Metaphor)：通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统;

　　13)适当的节奏(Sustainable Pace)，又称每周40小时工作制。

　　1.2 软件质量控制

　　所谓软件质量，可以用软件中的错误密度表示。质量越高，错误密度越小，由于软件开发过程中随时可能引入软件错误，软件质量控制的目的就是要排除软件中的错误。传统上，评审和测试是进行软件质量控制的基本方法。评审是对软件的中间产品如软件需求规格说明、软件设计说明、软件测试设计进行错误检查和规范遵从性检查的主要手段，而测试主要是查找软件的最终产品，即软件运行代码中的错误。

　　软件开发过程的质量控制通常是与开发阶段的划分相关联的。在典型的瀑布开发过程中，软件开发过程通常划分为软件需求分析、软件设计、软件实现和软件测试等阶段。对软件质量进行粗控(如图1所示)时，把每一个软件开发阶段当作一个黑盒子，对每一个黑盒子的输入输出进行质量控制。该控制方法又可称基线控制方法：将软件开发过程划分为若干条基线，每一条基线意味着上一开发阶段的结束和下一开发阶段的开始，因此在每一条基线到来时需要评审或测试本阶段的工作产品，进行缺陷修正后，结束本阶段工作，而该阶段产品作为下一阶段工作的输入。

　　在有些项目中，需要对软件质量和软件过程作更加严格的控制，项目各开发阶段不再被当作黑盒子，而是一个透明的玻璃盒子，在各阶段内部过程中被插入若干控制点，使用多种方法如同行评审、走查、审计等方法查找软件错误，对软件质量进行监控。这种质量精控的过程如图2所示。

　　

　　图1软件质量的粗控

　　

　　图2软件质量的精控

　　评审和测试是软件质量保证的基本技术，在已定义的质量控制点使用软件质量保证技术是软件质量控制的过程化方法，如何保证这些方法的有效性，监督这些方法的有效执行则是质量管理的内容。

　　2. 极限编程的质量控制

　　极限编程看似一个顺乎人本能的、自由的软件开发过程，而事实上其核心实践却包含了严格的质量控制技术。

　　2.1 极限编程软件质量的外部控制过程

　　极限编程的整个软件开发过程是由若干小的迭代周期完成，每一周期实现部分用户需求，完成后进行一次小型发布，然后根据用户的反馈和进一步的要求，开始下一周期的开发。在每次小型发布之前，通过客户测试对该周期完成的产品进行合格性检查，而每当一个迭代周期完成后，需要确定下一周期要开发与发布的系统范围，以便开始下一次迭代过程。而下一周期开发范围的确定，是由现场客户参与确认的。极限编程软件质量的外部控制过程如图3所示。在此，现场客户的参与相当于从用户的角度对软件需求进行评审，而客户测试相当于传统意义的软件验收测试。可以认为，现场客户和客户测试两个核心实践是极限编程软件开发过程中每一个重要节点的质量保证手段。

　　

　　图3极限编程的质量外部控制过程

　　2.2 极限编程内部软件质量控制过程

　　在每个迭代周期内部，软件开发过程仍然可以划分为软件设计、编码、单元测试等过程，但这些过程不再具有完全的线性关系，而是互相交错迭代(极限编程的每一迭代周期的实践过程流图如图4所示)。除此之外，极限编程不看重软件文档的作用，其观点是：编写规范、书写简洁、结构清晰的代码本身就是最好的软件文档。因此，在极限编程中，基于软件文档的软件评审不再适用，同时，烦琐的小组评审制也不适宜用于“敏捷”过程。尽管如此，极限编程却有更加严格的软件质量控制手段进行内部质量控制。事实上，它绝大多数核心实践的目的都是提高软件质量。

　　a) 代码规范

　　代码的易分析性、易维护性是重要的软件质量因素，通过制定代码规范，极限编程让所有的程序员能够编写出风格统一、结构清晰、易于理解、易于维护的源代码，既是提高软件质量的重要途径，也是代码代替文档的重要前提。代码规范是质量控制的基础，而代码规范的依从性检查则是通过“结对编程”、“设计重整”、“代码集体拥有”等实践进行检查的。

　　b) 结对编程

　　结对编程是一种典型的同行评审方式。该实践的宗旨是两个人的智慧比一个人强。由两个开发人员在同一台电脑上共同编写解决同一问题的代码，通常一个人坐在前端进行键盘操作，写代码，而另一个人坐在后面负责保证代码的正确性与可读性，相当于以个人评审的形式进行代码审查或静态测试。与此同时，另一个坐在旁边还可以考虑不同的设计思路和测试思路。

　　c) 设计重整

　　又称代码重构，在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能;当一段代码的设计不够完善、不够简洁、不够规范，对其进行设计重整，设计重整是同行评审或自我评审的结果。它导致更加完善的设计或编码。

　　d) 测试驱动的软件开发过程

　　对测试的高度重视是极限编程的一个重要特点。极限编程中，测试划分为单元测试、持续集成和客户测试，这与传统的单元测试、集成测试和确认测试测试过程相对应。同时，极限编程强调“测试先行”的原则，即使对于单元测试，也要求在进行编码之前先写测试用例，既能在编写测试用例过程中从测试的角度对软件设计进行评审，又能保持测试设计的独立性。

　　综上所述，极限编程的核心实践提供了用于软件开发过程内部进行质量控制的一套精心的手段。在开发过程的每一个迭代周期完成后，通过客户测试完成系统合格性检查，而在迭代周期的内部，通过“结对编程”、“测试先行”、“单元测试”等实践，几乎在每一个设计、每一个模块编码完成后，都对其进行了错误排除，以期获得“干净”的软件模块;而每一次新的模块加入系统，通过“持续集成”，排除软件接口错误，又能得到“干净”的系统。

　　

　　图4 极限编程每一迭代周期内部的实践过程流图

　　3. 在“信任”与“控制”之间建立平衡

　　极限编程的许多核心实践实际都是经过实践千锤百炼的准则，这些准则使得极限编程成为一个比较成熟的软件过程，下表总结了极限编程的核心实践对于CMM关键过程区域的满足度[3]：(√表示部分满足，√√表示在适当的环境下几乎满足，--表示未涉及。)

　　2级 KPA满足度3级 KPA

　　满足度高级 KPA满足度

　　需求管理√√组织过程焦点 软件过程管理--

　　软件项目规划√√组织过程定义√软件质量管理--

　　软件项目跟踪与监视√√培训方案--

　　软件子合同管理--集成软件管理--故障预防√

　　软件质量保证√软件生产工程√√技术变更管理--

　　软件配置管理√组件协调√√过程变更管理--

　　同行评审√√

　　尽管极限编程有如此众多的核心实践支持软件质量的控制?可是这些核心实践能被不折不扣地执行吗?结对编程能象传统的同行评审那样有效吗?软件的测试设计足够发现软件错误吗?软件的测试是否100%覆盖了软件需求或设计?这些问题怎么回答?敏捷软件开发方法强调以人优先，认为软件开发人员是负责任的专业人员，他们有动机将程序写得尽可能的好，测试尽可能充分，希望为客户提供高质量的产品，应该得到充分的“信任”。可是，即便软件开发人员有提供高质量软件产品的动机，可是他们具备相应的经验吗?如果不加控制，敏捷方法的下场会不会象早期的快速软件开发方法(RAD)最终变成声名昭著的“快而脏”(Rapid And Dirty)一样。

　　为此，在“信任”和“控制”之间建立适当的平衡是必要的。

　　极限编程中的两个角色在质量控制方面起着非常重要的作用，他们是教练(Coach)和追踪员(Tracker)。教练是极限编程中举足轻重的人物，是项目的幕后指挥，总能发现开发过程中出现的真正的问题，用恰当的方式给与解决。他最主要的任务是随时调整项目组的软件开发方向，以期达到最佳结果。而追踪员的职责是在不影响开发人员的情况下收集项目的过程数据如计划的执行情况、软件的缺陷数、软件错误的改正日志等等，为教练提供统计数据和项目的定量分析结果。[2]

　　因此，教练和追踪员的职责实际已经涵盖了CMM第4级中的两个关键过程区域：软件质量管理和软件过程管理。可以认为教练和追踪员两个角色的设置使极限编程可以走向更高的过程成熟度。

　　在实践中，也有一些团队仍然使用专职的有经验的质量保证工程师负责质量保证任务(对于敏捷软件组织，一个庞大的QAG是不适合的)，承担追踪员的职责和教练在质量管理方面的职责。其目的也是实现软件质量管理目标。

　　4. 结论

　　极限编程的核心实践活动本身提供了适用于敏捷软件开发方式的一整套质量控制方法，设立质量保证角色，或者重视发挥“教练”和“追踪员”两个角色的作用，在对程序员的“信任”和“控制”之间建立平衡，是确保质量控制过程的实施，使极限编程方法既保持敏捷又能成为高度成熟软件过程的关键。

　　参考文献

　　[1] Martin Fowler. The New Methodology[C/OL], http://www.martinfowler.com/articles/newMethodology.html, 2003-04

　　[2] Beck Kent. Extreme Programming Explained: Embrace Change[M]. Boston: Addison-Wesley,1999.

　　[3] Mark C.Paulk. Extreme Programming from a CMM Perspective[J]. IEEE Software,2001,18(6):19-26.

　　作者简介

　　袁静，女，高级工程师，硕士，1992年毕业于国防科技大学计算机软件专业，主要研究方向：软件工程。曾制定西安卫星测控中心软件工程以及软件过程规范，负责神舟飞船测控软件的质量保证工作。2002年9月 ——2003年9月于英国谢菲尔德大学计算机科学系作访问学者，进行极限编程方法研究，同时任该校学生极限编程项目组顾问。

原文转自：http://www.ltesting.net