第2章 软件过程

1) 2) 3) 4)

Plan 软件规格说明 Do 软件开发 Check 软件确认 Action 软件演进
80年代后，软件能力成熟度模型已成为软件 过程改进的标准。
软件工程框架
目标 用 性 确 性 合 基 本 过 程 算 性 支 持 过 程
可
正
选取适宜的开发范型 原 采用合适的设计方法 则 提供高质量的工程支持
统一过程模型
• 统一过程模型（Rational Unified Process） 是种软件工程过程，它提供了如何在开发组织中 严格分配任务和职责的方法；统一过程模型是一 个过程产品，有自己的过程框架，捕获了现代软 件开发中的最佳实践。统一过程模型具有三大特 点：用例驱动，以架构为中心，迭代和增量开发。
(2) 需求分析
本阶段要回答的关键问题是“目标系统应当做什么？”
(3) 软件设计
设计是软件工程的技术核心。本阶段要回答的关键问题 是“如何实现目标系统？”
软件生存周期
各个阶段所要完成的基本任务
(4) 程序编码和单元测试
本阶段要解决的问题是“正确地实现已做的设计”，即 “如何编写正确的、可维护的程序代码？”
第二章 软件过程
2.1 软件过程概述

ISO 9000定义：软件工程过程是把输入转 化为输出的一组彼此相关的资源和活动。
从软件开发的观点看，它就是使用适当的 资源（包括人员、硬软件工具、时间等）， 为开发软件进行的一组开发活动，在过程 结束时将输入（用户要求）转化为输出 （软件产品）。


软件工程过程定义了: 方法使用的顺序、 要求交付的 文档资料、为保证质量和适应变化所需要的管理、 软件开发各个阶段完成的里程碑。 软件工程过程包含四种基本的过程活动：
– 在软件开发的过程中，需求不发生或发生很少变化， 并且开发人员可以一次性获取到全部需求。否则，由 于瀑布模型较差的可回溯性，在后续阶段中需求经常 性的变更需要付出高昂的代价。 – 软件开发人员具有丰富的经验，对软件应用领域很熟 悉。 – 软件项目的风险较低。瀑布模型不具有完善的风险控 制机制。
原型模型
敏捷模型
• “敏捷联盟”为了帮助希望使用敏捷方法来进行软件开发 的人们定义了12条原则：
(1) 我们首先要做的是通过尽早和持续交付有价值的软件来让客户满意。 (2) 需求变更可以发生在整个软件的开发过程中，即使在开发后期，我们也 欢迎客户对于需求的变更。敏捷过程利用变更为客户创造竞争优势。 (3) 经常交付可工作的软件。交付的时间间隔越短越好，最好2~3周一次。 (4) 在整个的软件开发周期中，业务人员和开发人员应该天天在一起工作。 (5) 围绕受激励的个人构建项目，给他们提供所需的环境和支持，并且信任 他们能够完成工作。 (6) 在团队的内部，最有效果和效率的信息传递方法是面对面交谈。 (7) 可工作的软件是进度的首要度量标准。 (8) 敏捷过程提倡可持续的开发速度。责任人、开发人员和用户应该能够保 持一种长期稳定的开发速度。 (9) 不断地关注优秀的技能和好的设计会增强敏捷能力。 (10) 尽量使工作简单化。 (11) 好的架构、需求和设计来源于自组织团队。 (12) 每隔一定时间，团队应该反省如何才能有效地工作，并相应调整自己的 行为。
2.2 软件过程
• • • 软件生命周期 软件过程概念 软件生命周期模型
软件生存周期
软件从定义开始，经过开发、使用和维护， 直到最终退役的全过程称为软件生存周期。 可将软件生存周期划分为3个过程共9个阶段。 3个过程是：软件定义过程、软件开发过程、 软件使用与维护过程。 9个阶段有：可行性研究、需求分析、概要设 计、详细设计、实现、组装测试、 验收测试、使用与维护、退役。
– – – – – – 可行性研究 需求分析 软件设计 编码 软件测试 软件维护 Nhomakorabea•
图 1-5 传统软件生存周期的各个阶段
软件过程标准
图 1-6 ISO12207软件生存周期过程标准框架
软件生存周期模型
• ISO12207标准将软件生存周期模型定义为：
– 一个包括软件产品开发、运行和维护中有关过程、活 动和任务的框架，其中这些过程、活动和任务覆盖了 从该系统的需求定义到系统的使用终止。
顺时针为进展方向
风险分析 实现计划 风险分析 开发计划 风险分析 需求精化计划
评审
生命周期计划 需求计划 需求评价 验收测试计划 组装测试计划
风险分析 原型1
原型2 建模 软件需求
原型3 模拟
可操作 的原型
决策
操作概念
需求确认 设计验证与确认 验收 测试
评价 详细 设计
软件产品 设计 单元 测试
编码
图 1-10 演化模型
维护 测试 实现
设计
分析
螺旋模型 • 螺旋模型通常用来指导大型软件项目的开 发。它把开发过程分为制定计划、风险分 析、实施开发和用户评估四类活动。风险 分析被扩展到了各个阶段中，因此采用螺 旋模型可以降低项目开发的风险。
成本 计划： 明确目标、约束条件 选择方案 风险分析 构造原型
瀑布模型的缺点


由于瀑布模型几乎完全依赖于书面的规格说明，很 可能导致最终开发出的软件产品不能真正满足用户 的需要。如果需求规格说明与用户需求之间有差异， 就会发生这种情况。 瀑布模型只适用于项目开始时需求已确定的情况。
瀑布模型
• 瀑布模型的优点是过程模型简单，执行容易；缺 点是无法适应变更。瀑布模型适应于具有以下特 征的软件开发项目：
工程实现
用户评价；阶段评审
实现
组装 测试
图1-4-3 螺旋模型
螺旋模型
• 螺旋模型综合了传统的生存期模型的优点，同时 扩展了增量模型管理任务的范围：风险分析，用 来弥补其不足。螺旋模型的另外一个特征是，只 有一个迭代过程真正开发可交付的软件。螺旋模 型也存在其缺点：一个周期执行时间太长；要有 方法和自动化工具支持，否则无法实施。 • 螺旋模型适应于风险较大的大型软件项目的开发。
瀑布模型

在20世纪80年代之前，瀑 布模型一直是唯一被广泛 采用的生命周期模型。 传统的瀑布模型如图所示。

图 1-7 瀑布模型
实际的瀑布模型


实际的瀑布模型是带 “反馈环”的，如图所 示。 图中实线箭头表示开发 过程，虚线箭头表示维 护过程。
瀑布模型的优点


可强迫开发人员采用规范化的方法。 严格地规定了每个阶段必须提交的文档。 要求每个阶段交出的所有产品都必须是经过验证 的。
• 把这个概念应用到开发过程中，可以发现所有软 件开发生存周期模型的内在基本特征：
– – – – 描述了开发的主要阶段 定义了每一个阶段要完成的主要过程和活动 规范了每一个阶段的输入和输出（提交物） 提供了一个框架，可以把必要的活动映射到该框架中
软件生命周期模型
• 常见的软件生命周期模型包括：
– 瀑布模型 – 原型模型 – 增量模型 – 喷泉模型 – 螺旋模型 – 统一过程模型 – 敏捷过程模型 – 微软工程模型
(5) 集成和系统测试
测试是控制软件质量的重要手段，本阶段的主要任务是做 集成测试和系统测试。
(6) 软件运行和维护
已交付的软件投入正式使用，便进入运行阶段。这一阶段 可能持续若干年。软件在运行中可能由于多方面的原因， 需要对它进行修改。
软件过程概念
• 软件过程又称为软件生存周期过程，是软件生存周期内 为达到一定目标而必须实施的一系列相关过程的集合。 它是围绕软件的活动序列，财务、市场等活动不属于软 件过程。 在传统的软件工程中，软件产品的生存周期一般可以划 分为6个阶段，分别是：
• 原型模型主要用于挖掘需求，或是进行某种技术或开发方 法的可行性研究，是一种开发人员为了快速而准确地获取 需求经常采用的方法。 • 在初步获取需求后，开发人员会快速地开发一个原型系统。 通过对原型系统进行模拟操作，开发人员可以更直观、更 全面和更准确地了解用户对待开发系统的各项要求，同时 还能挖掘到隐藏的需求。如果开发人员对将采用的开发技 术把握不大，也可以采用原型模型进行技术上的尝试，以 降低后续开发的风险。 • 原型系统通常针对软件开发系统的子功能模块，所以功能 相对不完善。此外，由于原型系统功能的局部性以及存在 阶段的局部性，在软件开发的实践中，原型模型通常结合 其他的软件开发模型共同使用，发挥作用。
增量模型
• 增量模型的不足为：
– 如果没有对用户的变更要求进行规划，那么产 生的初始增量可能会造成后来增量的不稳定； – 如果需求不像早期思考的那样稳定和完整，那 么一些增量就可能需要重新开发，重新发布； – 管理发生的成本、进度和配置的复杂性，可能 会超出组织的能力。
Company Logo
增量模型 • 增量模型适用于以下特点的软件项目。
敏捷模型
• 敏捷方法是一种轻量级的软件工程方法，相对于传统的软 件工程方法，它更强调软件开发过程中各种变化的必然性， 通过团队成员之间充分的交流与沟通以及合理的机制来有 效地响应变化。 • 敏捷开发启动于“敏捷软件开发宣言”。在2001年2月， 17位软件开发者在Utah召开了长达两天的会议，制订并签 署了“敏捷软件开发宣言”，该宣言声明如下： – 我们正在通过亲身实践以及帮助他人实践的方式来揭 示更好的软件开发之路，通过这项工作，我们认为： – 个体和交互胜过过程和工具； – 可工作软件胜过宽泛的文档； – 客户合作胜过合同谈判； – 响应变化胜过遵循计划。
统一过程模型
图 1-12 统一过程模型
统一过程模型 • 统一过程的工作流

在统一过程中，有6个核心工作流。
① 业务建模工作流。用商业用例为商业过程建立文 档。 ② 需求工作流。目标是描述系统应该做什么，确保 开发人员构建正确的系统。为此，需明确系统的 功能需求和非功能需求（约束）。 ③ 分析和设计工作流。其目标是说明如何做。结果 是分析模型和设计模型。