第二章软件过程

第二章 软件过程

一、软件生命周期

软件生命周期(Life Cycle)，也称生存周期，指软件产品从提出、产生、发展到成熟，直至衰亡的整个时间段。

软件生命周期的组成阶段：

(1) 软件定义阶段：做什么？问题定义→可行性研究→需求分析

(2) 软件开发阶段：如何做？总体设计→详细设计→编码和单元测试→综合测试

(3) 运行维护阶段：纠错、适应性修改、增强性修改、预防性修改

二、软件过程的定义

当开发产品或构建系统时，遵循一系列可预测的步骤（路线图）是非常重要的，它有助于及时交付高质量的产品。

(1)所遵循的路线图就称为“软件过程”。

(2)软件过程贯穿软件开发的各阶段，并建立阶段里程碑（Milestones）；

(3)管理者在软件工程过程中需要对软件开发的质量、进度、成本进行评估、管理和控制；

(4)技术人员在软件过程中需采用相应的方法和工具生成软件工程产品，如模型、文档、数据、报告、表格等。

三、软件过程的作用

软件开发过程的作用是：

(1)成为开发组活动顺序的向导。

(2)详细说明需要开发哪些制品，何时开发。

(3)指导每一个成员及整个开发组的工作。

(4)提供监控、度量产品和活动所依据的准则。

— 软件过程是软件项目管理控制的基础，它为项目提供稳定性、可控性和有组织性，能有效避免混乱。

— 若没有一个良好定义的过程，开发组将各行其是，成功与否完全依赖个别优秀的人才，这不是能够长久的。

四、软件过程的组成要素 （活动、动作、任务）

软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。

（1）活动(activity)：实现宽泛的大目标。

（2）动作(action)：阶段目标。

（3）任务(task)：关注小而明确的目标，产生实际产品。

— 软件过程由活动组成，活动由动作组成，动作由任务组成。

五、基本框架活动和典型的普适性活动

软件过程框架(process framework)定义了若干个框架活动，及一些适用于整个软件过程的普适性活动

1.基本框架活动

一个通用的软件工程过程框架通常会包含以下5个基本的框架活动：

（1） 沟通：在技术工作开始前，先和利益相关者进行沟通与协作，以理解项目目标，并收集需求。

（2） 策划：制定项目计划，包括需要执行的技术任务、可能的风险、资源需求、工作产品、工作进度计划等。

（3）建模：构思软件的体系结构、构件如何结合等。（4）构建：包括编码和测试。

（5）部署：交付全部软件或部分增量，由用户使用并反馈意见。

2.典型的普适性活动

在软件过程中，还需要补充一些贯穿始终的普适性活动，可帮助团队管理和控制进度、质量、变更和风险。

（1）软件项目跟踪与控制：根据计划评估当前进度，并采取必要的措施保证项目按进度计划进行。

（2）风险管理：对可能影响项目成果或质量的风险进行评估。

（3）软件质量保证

（4）技术评审：评估软件工程的产品，尽量在错误传播到下一个活动之前发现并清除错误。

（5） 测量：定义和收集过程、项目和产品的度量。

（6） 软件配置管理：管理变更所带来的影响。

（7）可复用管理：定义产品复用标准，建立构件复用机制。

（8）工作产品的准备和生产

六、过程流

过程流(process flow)：描述了在执行顺序和执行时间上，如何组织框架中的活动、动作和任务。有以下4类：

七、通用过程模型

— 软件过程常使用“过程模型”来表述。

一个通用的软件过程模型，包括以下工作：

（1）选择一种过程流。

（2）定义框架活动：针对给定的问题、开发人员和利益相关者，制定每个框架活动中需要完成哪些动作。（ 例如在沟通活动中，可能包括启动、需求获取、需求系统、谈判、规格说明、确认等动作。）

（3） 明确任务集：为每个动作制定所需要的任务集。

— 任务集由工作任务、相关工作产品、质量保证点和项目里程碑等部分组成。

— 对于不同的软件项目，即便是相同的动作，确定的任务集也可能不一样。

（4）编写或查找过程模式。

八、过程模式

1.过程模式的定义

— 开发团队在软件过程里会遇到很多问题，如果团队能得到已有的经过验证的解决方案，将有助于快速地分析和解决问题。因此在软件过程中，最好能将遇到的过程问题、问题 环境、解决方案等记录下来，形成过程模式(process pattern)。

— 过程模式提供了一个模板，一种在软件过程的背景下，统一描述问题解决方案的方法。 — 可以在不同抽象层次上定义模式，比如针对整个过程的、针对框架活动的、针对动作的、针对任务的等。

例子：

— 模式名称：需求不清

— 目的：该模式描述了一种构建模型（或原型系统）的方法可以反复评估，以便识别和确定软件需求。

— 类型:阶段模式。

— 启动条件：①确定利益相关者；②已经建立起利益相关者和间的沟通方式；③利益相关者确定了需要解决的主要问题基本业务需求和项目约束条件有了初步了解。

— 问题：需求模糊或者不存在，但都清楚地认识到项目存在要通过软件解决。利益相关者不确认他们想要什么；即他件需求。

— 解决办法：描述了原型开发过程。

— 结束条件：开发了软件原型，识别了基本的需求（例如，征、处理功能等），并获得了利益相关者的认可。随后，

①原型系统可以通过一系列的增量开发，演化成为软件产统被抛弃，采用其他过程模式建立产品软件。

— 相关的模式：客户沟通、迭代设计、迭代开发、客户评价

九、过程模型

1.通用过程模型

软件过程常使用“过程模型”来表述。

— 一个通用的软件过程模型，包括以下工作：

（1）选择一种过程流。

（2） 定义框架活动：针对给定的问题、开发人员和利益相关者，制定每个框架活动中需要完成哪些动作。（例如在沟通活动中，可能包括启动、需求获取、需求系统、

谈判、规格说明、确认等动作。）

（3）明确任务集：为每个动作制定所需要的任务集。

— 任务集由工作任务、相关工作产品、质量保证点和项目里程碑等部分组成。

— 对于不同的软件项目，即便是相同的动作，确定的任务集也可能不一样。

（4）编写或查找过程模式。

2. 过程模型的选择要点

（1）无论要开发软件的大小，都应选择一个合适的软件过程模型。

（2）选择何种软件过程模型，依赖于项目的性质、所构造软件的特点、采用的方法、需要的控制，以及项目团队，不同类型的软件或系统可能需要采用完全不同的软件过程。

（3） 软件过程不是教条，它不是对如何构建软件的严格规定，而应是一种可适应性调整的方法，要让软件过程适合于项目团队和要开发的产品。

十、惯用过程模型（传统过程模型）

1.惯用过程模型的含义

— 软件工程发展到现在，已经出现了很多不同的过程模型，其中有一些可归属为“传统过程模型”。

— 传统过程模型以秩序和一致性作为主要问题，规定了一整套的过程元素，包括：过程流、框架活动、软件工程动作、任务、工作产品、质量保证、变更控制机制等。

— 常见的几种传统过程模型：瀑布模型、V模型、增量过程模型、原型开发模型、螺旋模

型、协同模型。

2. 瀑布模型

（1）概念： 瀑布模型(waterfall model)是软件工程最早的范例，也称经典生命周期，它提出了一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过计划、建模、构建和部署的过程，最终提供一个完整的软件并提供持续的技术支持。

（2）特点

— 在瀑布模型中，相邻二阶段之间存在因果关系，上一阶段的结果是下一阶段的输入。 — 瀑布模型推迟了软件实现，强调在软件实现前必须进行分析和设计工作。

— 瀑布模型非常规范：

1. 强迫开发人员采用规范的技术方法；

2. 严格规定每个阶段必须提交的文档(这些文档往往成为该阶段的里程碑)—“由文档驱动”

3. 每个阶段结束前必须进行正式的、严格的技术审查和管理复审。

— 在实际应用时，往往会添加上“反馈”机制。

（3）V模型：V模型是瀑布模型的一个变体，它的过程流和瀑布模型一致，但V模型描述了质量保证动作同沟通、建模相关动作以及早期构建相关的动作之间的关系。

（4）W模型

（5）评价

适用条件：需求明确而稳定，如

— 对已有系统仅做适应性调整或增强性工作。

— 需求明确的新系统。

优点：

— 具有系统性、可控性，克服了软件开发的随意性。

— 以阶段评审和文档控制为手段，能及时发现并纠正缺陷。

问题：

— 实际项目很少按照该模型给出的顺序进行。

— 客户常常难以清楚地给出需求，模型缺乏灵活性。

— 客户须要有耐心，只有在项目接近尾声时才能得到可执行程序。

— 若在可执行程序评审之前没有发现系统中存在的重大缺陷，将可能造成惨重损失。 — 线性流程，开发人员常需要等待，造成“阻塞状态”。

— 若每个阶段规定了过多的文档，会极大地增加工作量。

— 若管理人员以文档的完成情况来评估项目完成进度，往往会产生错误的结论。

3. 增量模型

（1）该模型先对系统最核心或最清晰的需求进行分析、设计、实现、测试，再按优先级逐步对

后续需求进行上述工作，并集成到系统中，逐步形成一个完整系统。

（2）增量模型的特点

— 增量过程模型综合了线性、并行、演化三种过程流的特征。

— 对于每个增量，使用的是线性过程流；

— 增量之间有并行；

— 整个过程类似于演化，本质上也是迭代的。

— 每一个增量都应提交一个可以运行的产品。

— 每次增量得到的产品要交由客户使用或仔细评价，并根据使用或评价的结果制定下一个增量计划。

— 每次增量需求的划分与增量实现的集成是以不影响系统体系结构为前提的。

（3）评价

优点：

— 适用于人手不足的情况：早期的增量可以由少量人员实现，若核心产品的口碑不错，则再投入更多人力。

— 客户的需求可以逐步提出来。

— 能在较短时间内提交可运行产品，增强了客户的信心。

— 可以规避技术风险：例如，系统需要利用某个正在开发的新硬件，则可以在早期的增量中避免使用这个硬件，以保证部分功能按时交付，不至于造成过分的延期。

缺点：

— 增量粒度难以选择；

— 确定所有的基本业务服务比较困难。

4. 原型开发

（1）概念：原型：模拟某种产品的原始模型（“样机”）。

— 在获得一组基本需求后，可以先通过快速地分析和设计，构造出一个小型的软件系统原型。 用户使用原型系统，开发人员根据用户反馈修改或重建系统。

（2）原型开发的目的

（3）原型开发的特点

— 原型系统应仅包括主要功能及重要接口，不包括系统的细节（如异常处理等）。 — 原型系统强调“快速”，不宜釆用过多的新技术。

— 原型提供了用户与开发人员良好的沟通手段：批评指责一个已有的事物，要比空洞地描述自己的设想容易得多。

— 原型系统是临时系统，通常应该被丢弃，但有时也可以将其演化成实际系统（实际系统以质量为纲）。

— 原型的若干高质量的程序片段和开发工具可用于实际系统的开发。

— 原型可作为一种技术，用于其它过程模型中。

（4）评价

优点：

— 用户能亲身感受到实际系统，很直观。

— 开发者使用成熟技术，能很快建造出一些东西。

缺点：

— 原型是粗糙的，没考虑软件总体质量和长期的可维护性。

— 开发者常要在实现上进行折衷以使得原型能尽快工作，如不合适的语言、低效的算法等。 — 文档容易被忽略。

— 建立原型的许多工作会被浪费掉。

— 对于大型的或流程复杂的系统，不经系统分析而直接用原型

来模拟是很困难的。

— 对于大量运算的、逻辑性较强的程序模块，很难构造原型。

5. 螺旋模型

（1）概念：螺旋模型结合了原型的迭代性质和瀑布模型的系统性和可控性特点，能快速开发软件的增量版本。

（2）螺旋模型的特点

— 螺旋模型要求在所有阶段始终进行风险分析和管理，是一种“风险驱动”的过程模型。 — 螺旋模型沿螺线顺时针旋转，自内向外每旋转一圈便开发出更完善的一个新版本。 — 和增量模型不同，螺旋模型并不要求每一个螺旋的产品都是可以运行的程序。例如：第一圈螺旋仅仅开发出产品规格说明，后面的螺旋才推出具体的程序。

— 螺旋模型不是当软件交付后就结束过程，而是应用在软件的整个生命周期中。

（3）评价

适用情况：大型系统和软件。

优点：

— 增加了风险分析和风险管理，把软件质量作为软件开发的一重要目标。

— 把原型作为降低风险的机制，且在开发的任意阶段均可使用原型实现。

— 将维护也看成一种开发。

缺点：

— 模型的成功依赖于风险评估技术的水平。

— 每一轮螺旋都要重新计划并修改开销。

6. 协同模型

— 协同开发模型，也称协同工程，能表达任意阶段活动的状态，以及它们之间存在的并发性。

— 协同模型定义了一系列事件，这些事件将触发软件工程活动、动作或者任务的状态转换。 — 协同模型可用于所有类型的软件开发。

十一、专用过程模型

1.基于构件的开发

（1）概念：

— 基于构件的开发：利用预先包装好的软件构件(如模块、类、软件包等)来构造应用。 — 基于构件的开发本质上是演化模型，其步骤为：

1. 对于该问题领域研究和评估可用的基于构件的产品，识别可选构件。

2. 考虑构件集成的问题。

3. 设计软件架构以容纳这些构件。

4. 将构件集成到架构中。

5. 进行充分的测试以保证功能正常。

— 构件组装模型的开发过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程。

（2）评价

适用情况：主要针对于面向对象的项目。

优点：— 充分利用软件复用，提高了软件开发的效率。

— 构建使得多个项目可以同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。

缺点：— 缺乏通用的构件组装结构标准，风险较大。

— 构件可重用性和系统高效性之间不易协调。

— 过分依赖于构件，构件质量影响着最终产品的质量。

2.形式化方法模型

— 形式化方法：使用严格的数学符号，编写软件产品的数学规格说明，再将这些形式化的数学说明翻译生成代码。

— 形式化方法使软件开发人员可以应用严格的数学符号来说明、开发和验证基于计算机的

系统。

— 形式化方法不依靠特定的评审，而是运用数学分析，诸如歧义性、不完整、不一致等问

题都更易被发现和改正。

问题：— 开发昂贵且费时。

— 很少有软件开发者具有使用形式化方法所必要的背景知识，需要多方面的培训。 — 难以将该模型作为与客户进行通信的机制。

3. 面向方面的软件开发

— 关注点：客户需要的属性或者技术兴趣点。

— 有些关注点是系统的高层属性（如安全性、容错能力），有些关注点影响了系统的功能（如商业规则的应用），还有些强调系统性（如任务同步或内存管理）。

— 如果某个关注点涉及系统多个方面的功能、特性和信息，这些关注点通常称为横切关注点(Crosscutting Concern)。

— 方面性需求(Aspectual Requirement)：定义那些对整个软件体系结构产生影响的横切关注点。

— 面向方面的软件开发(AOSD)：为定义、说明、设计和构建方面提供过程和方法，它是

对横切关注点局部表示的一种机制，超越了子程序和继承的方法。

十二、统一过程模型（重量级）

1. 统一过程(UP/RUP)

RUP：Rational Unified Process

RUP是一个面向对象的基于web的程序开发方法论，它建立了迭代、增量的过程流，提供了演进的特性。

RUP从传统软件过程中挖掘了最好的特征和性质，也可用敏捷软件开发中的许多最好的原则来实现。

RUP既是一种软件过程模型，又是一种支持面向对象软件开发的工具，它将软件开发过程要素和软件工件要素整合在统一的框架中。

RUP实际上是一种重量级过程，描述得非常完善和具体，特别适用于大型软件团队开发大型项目，实际应用时也可进行裁剪简化。

2. RUP的阶段

五个阶段：起始、细化、构建、转换、生产。

每个阶段结束于一个主要里程碑，并在阶段结尾进行评估，若评估结果满意则允许进入下一阶段。

3. RUP的核心工作流

— RUP用“工作流(Workflow)”来描述任务及其工作产品。

— 6个核心过程工作流：

1. 商业建模（Business Modeling）2. 需求（Requirements）

3. 分析和设计（Analysis & Design）4. 实现（Implementation）

5. 测试（Test）6. 部署（Deployment）

— 3个核心支持工作流：

1. 配置和变更管理（Configuration & Change Management）

2. 项目管理（Project Management）3. 环境（Environment）

4.RUP的特点

— 特点：用例驱动，以架构为核心，迭代且增量。

— 重视与客户的沟通，从用户的角度描述系统，编写用例，并保持该描述的一致性。 — 利用UML进行需求和设计的可视化建模。

— 采用面向对象的开发，可利用类实现代码复用。

— 使用组件体系结构，使软件体系架构更具弹性。

— 有一整套对应的工具，能进行需求管理、质量核查、变更控制等过程管理。 — 针对所有关键的开发活动为每个开发成员提供了必要的

准则、模板和工具指导。

十三、敏捷开发（轻量级）

1. 敏捷开发的含义

— 敏捷开发方法保留了软件过程中基本的框架活动：沟通、策划、建模、构建和部署，但将其缩减到一个推动项目组朝着构建和交付发展的最小任务集。因此敏捷方法也被称为轻量级方法、精简方法。

— 敏捷开发强调：

— 开发人员和客户之间主动和持续的沟通。

— 小而高度自主的项目团队。

— 让客户满意和软件的早期增量发布。

— 超越分析和设计（但不排斥这类活动）的发布。

— 整体精简开发，并使用最小化的软件工程工作产品。

2. 敏捷开发应遵循的原则

（1） 最优先：通过尽早、持续地交付有价值的软件来使客户满意。

（2） 即使在开发后期，也欢迎改变需求。敏捷过程利用变更为客户创造竞争优势。

（3）经常性地交付可运行软件，交付间隔可以从几个星期到几个月，间隔越短越好。

（4）在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

（5）围绕有积极性的个人构建项目，给他们提供所需的环境和支持，并信任他们能够完成工作。

（6） 在团队内部，最具有效果和效率的信息传递方法就是面对面的交谈。

（7） 可运行软件是进度的首要度量标准。

（8）提倡可持续的开发速度。责任人、开发者和用户应该能够长期保持稳定的开发速度。

（9）不断地关注优秀的技能和好的设计会增强敏捷能力。

（10）简单---使未完成的工作最大化的艺术--是根本的。

（11） 最好的构架、需求和设计出自于自组织的团队。

（12） 每隔一定时间，团队会反省如何才能更有效地工作，并相应地调整自己的行为。

3. XP过程

— XP过程包括四个关键活动：策划 设计 编码 测试

— XP推荐使用面向对象方法进行开发。

十四、CMM/CMMI

— CMM：能力成熟度模型，如SW-CMM软件CMM、SE-CMM系统工程CMM等。 — CMMI：软件能力成熟度模型集成。

— CMM/CMMI是一种用于评价软件承包能力以改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。

— CMM包括5个等级，共计18个过程域，52个目标，300多个关键实践。

— CMM自1987年开始实施认证，现已成为软件业权威的评估认证体系。