英语原文共 18 页
增量过程和敏捷过程的开发性能和产品质量的系统分析和比较
摘要：背景:尽管敏捷软件开发模型自20世纪90年代以来被广泛用作软件项目生命周期的基础，但是遵循可靠的经验方法并定量揭示使用这些模型相对于传统模型的效果的研究却很少。
目的:对某中型电信软件开发公司两个项目的增量过程和敏捷过程的开发性能和产品质量进行了系统的分析和比较，阐述了增量过程和敏捷过程的经验方法和结果。增量过程是瀑布模型的一种适应，而新引入的敏捷过程是统一软件开发过程、极限编程和Scrum的结合。
方法:采用定性与定量相结合的方法进行分析比较。它利用GQM方法设置度量目标，CMMI作为映射软件开发过程活动的参考模型，以及预定义的评估方法，在定量分析之前验证过程执行的一致性并且评估度量特征。
结果:比较结果表明，敏捷过程在生产率(79%)、缺陷密度(57%)、缺陷解决工作比(26%)、测试执行Vamp;V有效性(21%)和工作预测能力(4%)方面优于增量过程。这些结果表明，在项目中，遵循敏捷过程所获得的开发性能和产品质量优于遵循增量过程所获得的开发性能和产品质量。
结论:通过测量、分析和比较，可以全面地回顾这两个开发过程，并了解它们的优缺点。比较结果为敏捷过程在公司的组织范围内的部署提供了客观证据。
关键字：实证的方法 定量分析 定性分析 软件测量 过程性能 敏捷开发
一．简介
软件开发活动，如需求分析、设计、实现、测试和维护，在组织的软件开发生命周期内进行[1]。假设生命周期是从已经实现多年并被证明是成功的软件开发模型改编而来的。然而，许多软件项目在其生命周期中采用了不同的开发模型，却未能实现其目标。根据Standish Group在2009年进行的分析表明[2]，只有32％的软件项目报告成功，而44％是受到质疑的（逾期、超支及/或功能不足），24％是失败的（在完成或交付之前取消，从未使用过）。
在20世纪90年代之后的几年里，敏捷软件开发模型作为一种替代方案被提出。传统模型被定义为重视完全指定的问题，严格的规划，预定义的过程和定期文档[1]。另一方面，敏捷模型被定义为重视个人和交互而不是过程和工具，重视工作软件而不是全面的文档，重视客户协作而不是合同谈判，以及响应变更而不是遵循计划[3]。尽管敏捷软件开发模型自20世纪90年代以来被广泛用作软件项目生命周期的基础，但是定量地揭示使用这些模型比使用传统模型对开发性能的影响的研究却很少。在他们对敏捷软件开发的实证研究的系统评价中，Dybaring;和Dingsoslash;yr[4]声称在有限数量的报告研究中方法，数据和结果不成熟。Petersen和Wohlin [5]强调需要使用合理的经验方法研究敏捷和增量模型，并报告一个研究案例，揭示从计划驱动转变为增量和敏捷开发方法的影响。 另一方面，Van Waardenburg和van Vliet [6]研究了敏捷模型和计划驱动开发共存带来的挑战，并理性化两个组织如何应对这些挑战。
定量地揭示在不同环境下使用软件开发模型对开发性能和产品质量的影响是软件社区的主要需求之一。然而Gomez等人在一篇关于软件工程测量的系统综述中指出，在已发表的研究中，软件过程是测量最少的实体(占21%)。这主要是由于在实际测量和分析软件开发过程的性能时需要考虑各种问题。除了掌握过程管理，测量和统计方面的知识外，这项工作还需要执行一系列任务，例如：确定分析的目的，捕获过程上下文，识别过程组件，确保过程执行的一致性，收集过程数据，选择过程测量，确定分析方法，进行分析和解释分析结果。在比较两个或多个开发过程的性能时，协调过程范围作为比较的基础是另一项要完成的任务。除了这些挑战之外，只有少数系统和实用的方法[8,9]可以用作衡量软件开发过程性能的指南。
在本文中，我们解释了渐进过程和敏捷过程的开发性能以及产品质量的系统分析和比较的步骤与结果，这两个过程都适用于雇用65名开发人员的中型电信软件开发公司。 使用十六年的增量过程是瀑布模型的改编，而新引入的敏捷过程是统一软件开发过程，极限编程和Scrum的组合。 采用增量和敏捷过程的项目已经开展，以创建产品系列，并以每个项目的20个特征的开发为基础。
进行分析和比较所遵循的方法提出了将定性和定量方法结合起来得出结论。 本文详细描述了方法，并从其应用中提出了示例输出，这在文献中很难得到满足。 该方法利用目标问题度量方法（GQM）[8]设定绩效和质量测量目标，能力成熟度模型集成（CMMI） [10] 用于作为映射软件开发过程活动的参考模型，以及预定义的评估方法[11]，以此在定量分析之前验证过程执行的一致性并评估测量特征。 GQM方法被作为确定测量目标和所需措施的指南，并辅之以自下而上的方法，以便将所需的措施与可用的过程措施相协调。
本这篇文章由七个部分组成。第2节提供了关于传统和敏捷软件开发模型、软件度量基础和GQM方法、能力成熟度模型集成、称为定量过程管理评估方法的预定义评估方法以及软件开发模型比较研究的相关工作的背景信息。第3节提供了整个案例研究的概要，包括背景和范围、研究目标和设计，并分析了目标和措施。第4节描述了分析方法，并演示了增量过程分析的示例输出。 第5节介绍了比较的定量结果，并根据增量和敏捷过程的过程设定引出的定性数据讨论了这些结果背后的基本原理。 第6节阐述了案例研究对有效性的威胁，第7节提供了结论。
二.背景
2.1软件开发模型
用于开发软件产品的过程和活动的组织称为“软件开发生命周期”，也被称为“SDLC”。 SDLC旨在确保软件产品的系统化和面向目标的开发。 有几种模型描述了如何在传统和敏捷方法下构建此循环。
在传统的方法中，流程活动是预先计划的，进度是根据这个计划[1]来度量的。另一方面，在敏捷方法中，计划是增量的，更改流程以反映不断变化的客户需求相对更容易。敏捷模型的目标是响应不断变化的需求，快速地生成软件，并将这些产品提供给客户[12]。表1总结了传统模型和敏捷模型的特征。
表1：传统和敏捷软件开发模型的特点
|
开发模型 |
基本特征 |
|
传统瀑布式（计划驱动） |
-简单、线性、有序的活动[1,13] |
|
-定期和大量的文件 |
|
|
-活动包括可行性研究、需求分析、设计、实施及单元测试、集成及系统测试，以及运作及维修 |
|
|
-一项活动一旦完成，就很难再回到原来的状态 |
|
|
-在项目开始时可以清楚和完整地确定需求，并在之后可以限制对这些需求的更改 |
|
|
增量 |
-瀑布模型的修改版本[13] |
|
-软件是随着产品尺寸的增加而逐步开发的 |
|
|
-初始增量是具有紧急、高优先级功能的核心产品部件;接下来的增量按顺序交付给客户，每个增量都具有更广泛的功能 |
|
|
-当项目开始时需求不完整，并且可以及时提出时，这是有益的 |
|
|
演化式 |
-支持识别与客户一起开发的功能[1] |
|
-第一个功能对应于产品的一个主要部分，在一个周期内开发并交付给客户 |
|
|
-项目的成功是基于第一次演进进行评估的-如果成功了，将在接下来的演进中处理额外的需求 |
|
|
-当项目开始时存在技术上的不确定性，并且大部分产品功能是一次性交付时，这是有益的 |
|
|
螺旋式 |
-基于风险分析和原型开发的[14] |
|
-根据项目要求确定螺旋的阶段-周期 |
|
|
-螺旋系统分为四个部分:计划、风险分析、生产和用户评估 |
|
|
-在每一阶段，确定了风险，并为该阶段规划了一个原型;在这个阶段的最后，我们会评估目标，确定替代方案和约束条件 |
|
|
-其相对复杂的结构需要专门知识来适应 |
|
|
-当项目规模大且关键时是有益的 |
|
|
敏捷 极限编程 |
-包括加强客户关系和团队互动的实践，以及更多的反馈[15] |
|
-特性包括小版本、快速反馈、客户参与、交互和协调工作、持续集成和测试、相互代码所有权、有限的文档和结对编程 |
|
|
-当需求不稳定和不断变化时是有益的 |
|
|
特性驱动开发 |
-根据软件需求生成的特性工作[16] |
|
-在将新特性引入系统之前，将形成覆盖该特性的结构 |
|
|
-步骤包括;系统整体模型的开发，功能列表，面向功能的规划，面向功能的设计制作，进行面向功能的开发 |
|
|
-检查每一步的规则都被定义和遵守 |
|
|
-有利于关键系统的开发 |
|
|
方法论透彻派 |
-注重项目的适应性，以互动为导向的心态，以人为本[17] |
|
-有两项原则:(1)每次递增，每次递增一至三个月;(2)举办研讨会，在每次递增之前和之后讨论成功和失败 |
|
|
-其方法按难度分为白色、黄色、橙色、红色;颜色越深，方法越难 |
|
|
-根据项目的范围和危害性选择颜色合适的方法 |
|
|
SCRUM |
-侧重于项目管理的实践，不包括工程细节[18] |
|
-假设项目范围将在项目期间发生变化 |
|
|
-拥有可以避免不稳定和复杂性的实践，而不是软件开发的特定实践(例如，称为“sprint”的软件的每一个可执行增量都是在30天内完成并交付给客户的) |
|
|
动态系统开发 |
-使控制步骤的短期和快速的软件开发[19] |
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
