软件工程-软件过程与软件过程模型

软件工程系列文章一

软件过程

软件开发的中所遵循的线路图称为 “软件过程”

能力成熟度模型 (CMM)

CMM 将软件过程改进分为以下 5 个成熟度级别

初始级 (Initial)

软件的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的完成完全依赖个人的努力和英雄式核心人物的作用

可重复级 (Repeatable)

建立了基本的项目管理过程和实践来跟踪项目的费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功

已定义级 (Defined)

管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件

已管理级 (Managed)

制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制

优化级 (Optimized)

加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进

CMM 模型提供了一个框架，将软件过程改进的进化步骤组织成 5 个成熟度等级，为过程不断改进奠定了循序渐进的基础。这 5 个成熟度等级定义了一个有序的尺度，用来测量一个组织的软件过程成熟度和评价其软件过程能力

能力成熟度模型集成 (CMMI)

CMM 的成功导致了适用不同学科领域的模型的衍生，但一个工程常常涉及多个交叉学科，因此有必要将各种过程改进的工作集成起来。CMMI 是若干过程模型的综合和改进

CMMI 提供了两种表示方法：阶段式模型和连续式模型

1. 阶段式模型

阶段式模型的结构类似于 CMM，它关注组织的成熟度。CMMI-SE/SW/IPPD 1.1 版中有 5 个成熟度等级

初始的：过程不可预测且缺乏控制
已管理的：过程为项目服务
已定义的：过程为组织服务
定量管理的：过程已度量和控制
优化的：集中于过程改进

2. 连续式模型

连续式模型关注每个过程域的能力，一个组织对不同的过程可以达到不同的过程域能力等级 (Capability Level, CL) 。CMMI 中包括 6 个过程域能力等级，等级号为 0~5。能力等级包括共性目标及相关的共性实践，这些实践在过程域内被添加到特定目标和实践中。当组织满足过程域的特定目标和共性目标时，就说该组织达到了那个过程域的能力等级

CL₀ (未完成的) ：过程域未执行或未得到 CL₁ 中定义的所有目标
CL₁ (已执行的) ：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标
CL₂ (已管理的) ：其共性目标集中于已管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程，项目遵循已文档化的计划和过程描述，所有正在工作的人都有权使用足够的资源，所有工作任务和工作产品都被监控、控制和评审
CL₃ (已定义级的) ：其共性目标集中于已定义的过程的制度化。过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改进
CL₄ (定量管理的) ：其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的定量目标作为管理准则
CL₅ (优化的) ：使用量化 (统计学) 手段改变和优化过程域，以满足客户要求的改变和持续改进计划中的过程域的功效

软件过程模型

软件过程模型习惯上也称为软件开发模型，它是软件开发全部过程、活动和任务的结构框架。典型的软件过程模型有瀑布模型、增量模型、演化模型 (原型模型、螺旋模型) 、喷泉模型、基于构件的开发模型和形式化方法模型等

瀑布模型

瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行与维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水逐级下落

瀑布模型为软件的开发和维护提供了一种有效的管理模式，根据这一模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，所以它是以文档作为驱动、适合于软件需求很明确的软件项目的模型

瀑布模型假设，一个待开发的系统需求是完整的、简明的、一致的，而且可以先于设计和实现完成之前产生

瀑布模型的优点是，容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试不足之处是，客户必须能够完整、正确和清晰地表达他们的需要；在开始的两个或三个阶段中，很难评估真正的进度状态；当接近项目结束时，出现了大量的集成和测试工作；直到项目结束之前，都不能演示系统的能力在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算

V 模型

瀑布模型的一个变体是 V 模型

V 模型描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。随着软件团队工作沿着 V 模型左侧步骤向下推进，基本问题需求逐步细化，形成问题及解决方案的技术描述。一旦编码结束，团队沿着 V 模型右侧的步骤向上推进工作，其实际上是执行了一系列测试 (质量保证活动) ，这些测试验证了团队沿着 V 模型左侧步骤向下推进过程中所生成的每个模型。V 模型提供了一种将验证确认活动应用于早期软件工程工作中的方法

增量模型

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”

当使用增量模型时，第一个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品

增量模型作为瀑布模型的一个变体，具有瀑布模型的所有优点。此外，它还有以下优点：第一个可交付版本所需要的成本和时间很少；开发由增量表示的小系统所承担的风险不大；由于很快发布了第一个版本，因此可以减少用户需求的变更；运行增量投资，即在项目开始时，可以仅对一个或两个增量投资

增量模型有以下不足之处：如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布；管理发生的成本、进度和配置的复杂性可能会超出组织的能力

演化模型

软件类似于其他复杂的系统，会随着时间的推移而演化。在开发过程中，常常会面临以下情形：商业和产品需求经常变化，直接导致最终产品难以实现；严格的交付时间使得开发团队不可能圆满地完成软件产品，但是必须交付功能有限的版本以应对竞争或商业压力；很好地理解了核心产品和系统需求，但是产品或系统拓展的细节问题却没有定义。在上述情况和类似情况下，软件开发人员需要一种专门应对不断演变的软件产品的过程模型

演化模型是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本。演化模型特别适用于对软件需求缺乏准确认识的情况。典型的演化模型有原型模型和螺旋模型等

原型模型 (Prototype Model)

并非所有的需求都能够预先定义，大量的实践表明，在开发初期很难得到一个完整的、准确的需求规格说明。这主要是由于客户往往不能准确地表达对未来系统地全面要求，开发者对要解决的应用问题模糊不清，以至于形成的需求规格说明常常是不完整的、不准确的，有时甚至是有歧义的。此外，在整个开发过程中，用户可能会产生新的要求，导致需求的变更。而瀑布模型难以适应这种需求的不确定性和变化，于是出现了快速原型 (Rapid Prototype) 这种新的开发方法。原型方法比较适合于用户需求不清、需求经常变化的情况。当系统规模不是很大也不太复杂时，采用该方法比较好

原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。当然，能够采用原型方法是因为开发工具的快速发展，使得能够迅速地开发出一个让用户看得见、摸得着的系统框架。这样，对于计算机不是很熟悉的用户就可以根据这个框架提出自己的需求。开发原型系统首先确定用户需求，开发初始原型，然后征求用户对初始原型的改进意见，并根据意见修改原型

原型模型开始于沟通，其目的是定义软件的总体目标，标识需求，然后快速制定原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其进行建模，并构建原型。被开发的原型应交付给客户使用，并收集客户的反馈意见，这些反馈意见可在下一轮中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发

螺旋模型

对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足

螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，每个螺旋周期分为如下 4 个工作步骤

制定计划。确定软件的目标，选定实施方案，明确项目开发的限制条件
风险分析。分析所选的方案，识别风险，消除风险
实施工程。实施软件开发，验证阶段性产品
用户评估。评价开发工作，提出修正建议，建立下一个周期的开发计划

螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，从而做出应有的反应。因此，该模型特别适用于庞大、复杂并且具有高风险的系统

与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高软件的适应能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发的风险。在使用螺旋模型进行软件开发时，需要开发人员具有相当丰富的风险评估经验和专门知识。另外，过多的迭代次数会增加开发成本，延迟提交时间

喷泉模型

喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性

迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统，无间隙是指在开发活动 (如分析、设计、编码) 之间不存在明显地边界，也就是说，它不像瀑布模型那样，在需求分析活动结束后才开始设计活动，在设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行

喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行。其优点是可以提高软件项目的开发效率，节省开发时间。由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理。此外，这种模型要求严格管理文档，使得审核的难度加大

统一过程 (UP) 模型

统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由 UML 方法和工具支持。迭代的意思是将整个软件开发项目划分为许多个小的“袖珍项目”，每个“袖珍项目”都包含正常软件项目的所有元素：计划、分析和设计、构造、集成和测试，以及内部和外部发布

统一过程定义了 4 个技术阶段及其制品

起始阶段 (Inception Phase)

初始阶段专注于项目的初创活动，产生的主要工作产品有构想文档 (Vision Document) 、初始用例模型、初始项目术语表、初始业务用例、初始风险评估、项目计划 (阶段及迭代) 、业务模型以及一个或多个原型 (需要时)
精化阶段 (Elaboration Phase)

精化阶段在理解了最初的领域范围之后进行需求分析和架构演进，产生的主要工作产品有用例模型、补充需求、分析模型、软件体系结构描述等
构建阶段 (Construction Phase)

构建阶段关注系统的构建，产生实现模型，产生的主要工作产品有设计模型、软件构件、集成的软件增量、测试计划及步骤、测试用例以及支持文档
移交阶段 (Transition Phase)

移交阶段关注于软件提交方面的工作，产生软件增量，产生的主要工作产品有提交的软件增量、β 测试报告和综合用户反馈

每次迭代产生包括最终系统的部分完成的版本和任何相关的项目文档的基线，通过逐步迭代基线之间相互构建，直到完成最终系统。在每个迭代中有 5 个核心工作流：

捕获系统应该做什么的需求工作流
精化和结构化需求的分析工作流
在系统架构内实现需求的设计工作流
构造软件的实现工作流
验证实现是否如期望那样工作的测试工作流

随着 UP 的阶段进展，每个核心工作流的工作量发生了变化。4 个技术阶段由主要里程碑所终止

初始阶段：生命周期目标
精化阶段：生命周期架构
构建阶段：初始运作功能
移交阶段：产品发布

统一过程的典型代表是 RUP (Rational Unified Process) 。RUP 是 UP 的商业扩展，完全兼容 UP，但比 UP 更完整、更详细

敏捷方法

敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。通过在软件开发过程中加入灵活性，敏捷方法 (Agile Development) 使用户能够在开发周期的后期增加或改变需求

敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念 (敏捷宣言)

1. 极限编程 (XP)

XP 是一种轻量级 (敏捷) 、高效、低成本、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为 4 个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期

4 大价值观：沟通、简单性、反馈和勇气
5 大原则：快速反馈、简单性假设、逐步修改、提倡修改和优质工作
12 个最佳实践
- 计划游戏 (快速制定计划、随着细节的不断变化而完善)
- 小型发布 (系统的设计要能够尽可能早地交付)
- 隐喻 (找到合适的比喻传达信息)
- 简单设计 (只处理当前的需求，使设计保持简单)
- 测试先行 (先写测试代码，然后再编写程序)
- 重构 (重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求)
- 结对编程
- 集体代码所有制
- 持续集成 (可以按日甚至按小时为客户提供可运行的版本)
- 每周工作 40 个小时
- 现场客户 (系统最终用户代表应该全程配合 XP 团队)
- 编码标准

2. 水晶法 (Crystal)

水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论

认为人对软件质量有重要的影响，因此随着项目质量和开发人员素质的提高，项目和过程的质量也随之提高。通过更好地交流和经常性的交付，软件生产力得到提高

3. 并列争求法 (Scrum)

并列争求法使用迭代的方法，其中，把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。多个自组织和自治的小组并行地递增实现产品，协调是通过简短的日常情况会议来进行，就像橄榄球中的“并列争球”。步骤如下：

4. 自适应软件开发 (ASD)

ASD 有 6 个基本的原则

有一个使命作为指导
特征被视为客户价值的关键点
过程中的等待是很重要的，因此“重做”与“做”同样关键
变化不被视为改正，而是被视为对软件开发实际情况的调整
确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求
风险也包含其中

5. 敏捷统一过程 (AUP)

敏捷统一过程 (Agile Unified Process, AUP) 采用“在大型上连续”以及在“小型上迭代”的原理来构建软件系统。采用经典的 UP 阶段性活动 (初始、精化、构建和转换) ，提供了一系列活动，能够使团队为软件项目构想出一个全面的过程流。在每个活动里，一个团队迭代使用敏捷，并将有意义的软件增量尽可能快地交付给最终用户。每个 AUP 迭代执行以下活动

建模。建立对商业和问题域的模型表述，这些模型“足够好”即可，以便团队继续前进
实现。将模型翻译为源代码
测试。像 XP 一样，团队设计和执行一系列的测试来发现错误以保证源代码满足需求
部署。对软件增量的交付以及获取最终用户的反馈
配置及项目管理。着眼于变更管理、风险管理以及对团队的任一制品的控制。项目管理追踪和控制开发团队的工作进展并协调团队活动
环境管理。协调标准、工具以及适用于开发团队的支持技术等过程基础设施