软件项目管理与案例分析 (7)

华中科技大学软件学院 THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

第 3 章 软件开发过程管理

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

本章内容提要CMM和 CMM和ISO9000 传统软件开发生命周期模型 扩展软件开发生命周期模型 质量计划 案例分析 本章小结 复习思考题2

3.1

3.2

3.3

3.4

3.5

3.6

3.7

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.1 CMM和ISO9000 和软件过程是指人们用于开发和维护软件及其相关产品的一系列活动、 是指人们用于开发和维护软件及其相关产品的一系列活动、方 实践和革新。 法、实践和革新。

软件开发过程管理是指在软件开发过程中，除了先进技术和开发方法外， 是指在软件开发过程中，除了先进技术和开发方法外，还有一 整套的管理技术。 整套的管理技术。

软件过程改进是针对软件生产过程中会对产品质量产生影响的问题而进行的， 是针对软件生产过程中会对产品质量产生影响的问题而进行的， 它的直接结果是软件过程能力的提高。 它的直接结果是软件过程能力的提高。 现在常见的软件过程改进方法： 现在常见的软件过程改进方法：ISO 9000,SW-CMM和由多 ， 和由多 种能力模型演变而来的CMMI。 种能力模型演变而来的 。3

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.1.1 SW-CMM和CMMI 和SW-CMM简介 SW-CMM简介为了保证软件产品的质量，1991年美国卡内基·梅隆大学软 为了保证软件产品的质量，1991年美国卡内基· 年美国卡内基 件工程研究所(CMU/SEI) 件工程研究所(CMU/SEI)将软件过程成熟度框架进化为软件能 力成熟度模型(Capability Maturity Model For Software,简 力成熟度模型( Software, SW-CMM),并发布了最早的SW ),并发布了最早的SW1.0版 称SW-CMM),并发布了最早的SW-CMM 1.0版。 SW-CMM为软件企业的过程能力提供了一个阶梯式的进化框架 SW-CMM为软件企业的过程能力提供了一个阶梯式的进化框架 阶梯共有五级。 ,阶梯共有五级。

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.1.1 SW-CMM和CMMI 和

1 初始级 建立基本的项 无序、混乱的 目管理过程。 软件过程。依 文档化、标准 相似项目，重 持续的对过程 赖个别人的努 复以往成果。 化和标准的软 进行改进。 软件过程和产 力和机遇。 件软件过程。 品质量有详细 的度量标准。

2 可重复级

3 已定义级

5 优化级 图 CMM分级标准

4 已管理级

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.1.1 SW-CMM和CMMI 和KPA及 KPA及KP除第一级外， 除第一级外，SW-CMM的每一级都是按完全相同的结构组成 的每一级都是按完全相同的结构组成 每一级包含了实现这一级目标的若干关键过程域( ),每 的。每一级包含了实现这一级目标的若干关键过程

域(KPA),每 ), 进一步包含若干关键实施活动( ),无论哪个KPA,它 ),无论哪个 个KPA进一步包含若干关键实施活动(KP),无论哪个 进一步包含若干关键实施活动 ， 们的实施活动都统一按六个公共属性进行组织，即每一个KPA都包 们的实施活动都统一按六个公共属性进行组织，即每一个 都包 含六类KP: 含六类 ： 1. 目标 2. 实施保证 3. 实施能力 4. 执行活动 5. 度量分析 6. 实施验证6

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.1.1 SW-CMM和CMMI 和

CMMI简介 CMMI简介由于不同领域能力成熟度模型存在不同的过程改进， 由于不同领域能力成熟度模型存在不同的过程改进，重复的 培训、评估和改进活动以及活动不协调等一些问题。 培训、评估和改进活动以及活动不协调等一些问题。于是由美国 国防部出面，美国卡内基·梅隆大学软件工程研究所 梅隆大学软件工程研究所( 国防部出面，美国卡内基 梅隆大学软件工程研究所(CMU/SEI 月发布的CMMI 1.1版本包括四个领域：软件工程 版本包括四个领域： )于2001年12月发布的 年 月发布的 版本包括四个领域 )、系统工程 )、集成的产品和过程开发 (SW)、系统工程(SE)、集成的产品和过程开发(IPPD)、 )、系统工程( )、集成的产品和过程开发( )、 采购( )。 采购(SS)。

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.1.1 SW-CMM和CMMI 和CMMI有两种不同的实施方法 CMMI有两种不同的实施方法连续式--主要是衡量一个企业的项目能力 连续式--主要是衡量一个企业的项目能力 -- 阶段式-- --主要是衡量一个企业的成熟度 阶段式--主要是衡量一个企业的成熟度

CMMI的五个台阶 CMMI的五个台阶完成级 管理级 定义级 量化管理级 优化级

每一个台阶都是上面一阶台阶的基石。 每一个台阶都是上面一阶台阶的基石。要上高层台 阶必须首先踏上较低一层台阶。 阶必须首先踏上较低一层台阶。8

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.1.2 ISO9000质量标准 质量标准ISO9000所谓“ 不是指一般意义上的一个质量保证标准， 所谓“ISO9000”不是指一般意义上的一个质量保证标准，而是一 不是指一般意义上的一个质量保证标准 族系列标准的统称。 族系列标准的统称。

作用─ ─ ─ ─ ─ ─ 强化品质管理，提高企业效益；增强客户信心， 强化品质管理，提高企业效益；增强客户信心，扩大市场份 额； 获得了国际贸易“通行证” 消除了国际贸易壁垒； 获得了国际贸易“通行证”,消除了国际贸易壁垒； 节省了第二方审核的精力和费用； 节省了第二方审核的精力和费用； 在产品品质竞争中永远立于不败之地； 在

产品品质竞争中永远立于不败之地； 有效地避免产品责任； 有效地避免产品责任； 有利于国际间的经济合作和技术交流。 有利于国际间的经济合作和技术交流。9

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.1.3 三者之间的比较选择SW-CMM还是CMMI的考虑 选择SW-CMM还是CMMI的考虑 SW 还是CMMI─实施企业的业务特点。 实施企业的业务特点。 实施企业的业务特点 ─实施企业对过程改进的熟悉程度。 实施企业对过程改进的熟悉程度。 实施企业对过程改进的熟悉程度 ─实施企业对过程改进项目的预算。 实施企业对过程改进项目的预算。 实施企业对过程改进项目的预算 ─实施企业是否可以使用阶段式的演进路线。 实施企业是否可以使用阶段式的演进路线。 实施企业是否可以使用阶段式的演进路线 ─实施 实施CMM与CMMI可以平滑的转换。 可以平滑的转换。 实施 与 可以平滑的转换

ISO9001与CMM的关系 ISO9001与CMM的关系─ISO9001和CMM既有区别又相互联系，两者不可简单地互相替 和 既有区别又相互联系， 既有区别又相互联系 代。 ─取得 取得ISO9001认证并不意味着完全满足 认证并不意味着完全满足CMM某个等级的要求。 某个等级的要求。 取得 认证并不意味着完全满足 某个等级的要求 ─取得 取得CMM第2级(或第 级)不能笼统地认为可以满足 或第3级 不能笼统地认为可以满足 不能笼统地认为可以满足ISO9001的 取得 第 级 或第 的 要求。 要求。10

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

本章内容提要CMM和 CMM和ISO9000 传统软件开发生命周期模型 扩展软件开发生命周期模型 质量计划 案例分析 本章小结 复习思考题11

3.1

3.2

3.3

3.4

3.5

3.6

3.7

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.2 传统软件开发生命周期模型软件生命周期软件从需求确定、设计、开发、测试直至投入使用， 软件从需求确定、设计、开发、测试直至投入使用，并在使用中不 断地修改、增补和完善， 断地修改、增补和完善，直至被新的系统所替代而停止该软件的使用的 全过程。 全过程。

可划分为以下子阶段1.可行性研究 可行性研究 2.需求分析和定义 需求分析和定义 3.总体设计 总体设计 4.详细设计 详细设计 5.编码(实现) 编码( 编码 实现) 6.软件测试、运行 维护 软件测试、 软件测试 运行/维护 据此相继产生了瀑布模型、螺旋模型、进化模型、原型模型、 据此相继产生了瀑布模型、螺旋模型、进化模型、原型模型、增量 模型等。本节分别对这几种传统的软件开发生命周期模型予以介绍。 模型等。本节分别对这几种传统的软件开发生命周期模型予以介绍。12

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.2.1 瀑

布模型系统需求 软件需求 分析 设计 编码 测试 运行

瀑布模型总结文档驱动的模型 阶段间具有顺序性和依 赖性 项目开发周期较长 实际项目很少按照该模 型给出的顺序进行

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.2.2 原型模型

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.2.2 原型模型model特点 Prototyping model特点在需求定义之前， 在需求定义之前，需要快速构建一个系统 根据构建系统的优缺点，用户给开发人员提出反馈意 根据构建系统的优缺点， 见 根据反馈意见修改软件需求规格， 根据反馈意见修改软件需求规格，以便系统可以更正 确地反映用户的需求 减少各种假设以及风险

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.2.3 增量模型增量1 增量分 分 设 设 编 编 测 测

第一个增量发布

增量2 增量

分 分

设 设

编 编

测 测

第二个增量发布

增量3 增量

分 分

设 设

编 编

测 测

第三个增量发布

增量4 增量

分 分

设 设

编 编

测 第四个增量发布 测

开发进度

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.2.3 增量模型

增量模型总结融合了瀑布模型和原型的迭代特征。 融合了瀑布模型和原型的迭代特征。 每一个增量均发布一个可操作产品。 每一个增量均发布一个可操作产品。

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.2.4 进化模型听取用户 意见

建造/ 建造/修改 原型

这个模型 可看作是重复执 行的多个瀑布模 型。

用户测试 运行原型

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.2.5 螺旋模型制订计划 决定目标 方案和限制 累计 成本 风险分析 评价方案， 评价方案，识别 风险、 风险、消除风险 风 风 险 风 险 提交线 评审 原型1 原型 需求计划 生存期 计划 开 发 集 计 划 成 与 测 试 分 析 原型2 原型 软件 需求 需求 确认 设计确认 与验证 验收 实现 客户评估 测试 原型3 原型 软件 产品 设计 单元 集成 与 测试 测试 开发、 开发、验证 下一产品 实施工程19

险 分 析

分 析 可运行 原型

详细设计

编码

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

3.2.5 螺旋模型

螺旋模型总结基于风险驱动的开发模型, 基于风险驱动的开发模型, 使用原型法或其它方法来 尽量降低风险。 尽量降低风险。 适用于需求不明确的大规模软件项目

THE SCHOOL OF SOFTWARE ENGINEERING OF HUST

本章内容提要CMM和 CMM和ISO9000 传统软件开发生命周期模型 扩展软件开发生命周期模型 质量计划 案例分析 本章小结 复习思考题21

3.1

3.2

3.3

3.4

3.5

3.6

3.7

本文来源：https://www.bwwdw.com/article/wax4.html