第 3 章软件开发过程管理

第 3 章软件开发过程管理

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

3.1 CMM和ISO9000 • 软件过程　　是指人们用于开发和维护软件及其相关产品的一系列活动、方法、实践和革新。 • 软件开发过程管理　　是指在软件开发过程中，除了先进技术和开发方法外，还有一整套的管理技术。 • 软件过程改进　　是针对软件生产过程中会对产品质量产生影响的问题而进行的，它的直接结果是软件过程能力的提高。　　现在常见的软件过程改进方法：ISO 9000，SW-CMM和由多种能力模型演变而来的CMMI。

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

3.1.1 SW-CMM和CMMI 1 初始级 2 可重复级建立基本的项目管理过程。相似项目，重复以往成果。无序、混乱的软件过程。依赖个别人的努力和机遇。 3 已定义级文档化、标准化和标准的软件软件过程。持续的对过程进行改进。软件过程和产品质量有详细的度量标准。 5 优化级 4 已管理级图 CMM分级标准

3.1.1 SW-CMM和CMMI • KPA及KP • 　　除第一级外，SW-CMM的每一级都是按完全相同的结构组成的。每一级包含了实现这一级目标的若干关键过程域（KPA），每个KPA进一步包含若干关键实施活动（KP），无论哪个KPA，它们的实施活动都统一按六个公共属性进行组织，即每一个KPA都包含六类KP： • 1. 目标 • 2. 实施保证 • 3. 实施能力 • 4. 执行活动 • 5. 度量分析 • 6. 实施验证

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

3.1.1 SW-CMM和CMMI • CMMI有两种不同的实施方法 • 连续式－－主要是衡量一个企业的项目能力 • 阶段式－－主要是衡量一个企业的成熟度 • CMMI的五个台阶 • 完成级 • 管理级 • 定义级 • 量化管理级 • 优化级 • 每一个台阶都是上面一阶台阶的基石。要上高层台阶必须首先踏上较低一层台阶。

3.1.2 ISO9000质量标准 • ISO9000 所谓“ISO9000”不是指一般意义上的一个质量保证标准，而是一族系列标准的统称。 • 作用 • 强化品质管理，提高企业效益；增强客户信心，扩大市场份额； • 获得了国际贸易“通行证”，消除了国际贸易壁垒； • 节省了第二方审核的精力和费用； • 在产品品质竞争中永远立于不败之地； • 有效地避免产品责任； • 有利于国际间的经济合作和技术交流。

3.1.3 三者之间的比较 • 选择SW-CMM还是CMMI的考虑 • 实施企业的业务特点。 • 实施企业对过程改进的熟悉程度。 • 实施企业对过程改进项目的预算。 • 实施企业是否可以使用阶段式的演进路线。 • 实施CMM与CMMI可以平滑的转换。 • ISO9001与CMM的关系 • ISO9001和CMM既有区别又相互联系，两者不可简单地互相替代。 • 取得ISO9001认证并不意味着完全满足CMM某个等级的要求。 • 取得CMM第2级(或第3级)不能笼统地认为可以满足ISO9001的要求。

3.2 传统软件开发生命周期模型 • 软件生命周期　　软件从需求确定、设计、开发、测试直至投入使用，并在使用中不断地修改、增补和完善，直至被新的系统所替代而停止该软件的使用的全过程。 • 可划分为以下子阶段 1.可行性研究 • 2.需求分析和定义 • 3.总体设计 • 4.详细设计 • 5.编码（实现） • 6.软件测试、运行/维护 • 　　据此相继产生了瀑布模型、螺旋模型、进化模型、原型模型、增量模型等。本节分别对这几种传统的软件开发生命周期模型予以介绍。

系统需求 软件需求分析设计编码测试运行 3.2.1 瀑布模型 • 瀑布模型总结 • 文档驱动的模型 • 阶段间具有顺序性和依赖性 • 项目开发周期较长 • 实际项目很少按照该模型给出的顺序进行

3.2.2 原型模型

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

增量1 第一个增量发布增量2 第二个增量发布增量3 第三个增量发布第四个增量发布增量4 开发进度 3.2.3 增量模型

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

听取用户 意见建造/修改原型用户测试运行原型 3.2.4 进化模型这个模型可看作是重复执行的多个瀑布模型。

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

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

3.3.1 极限模型 • 　极限模型简介 • 2001年，为了避免许多公司的软件团队陷入不断增长的过程泥潭，一批业界专家一起概括出了一些敏捷开发过程的方法：SCRUM，Crystal，特征驱动软件开发（Feature Driven Development，简称FDD），自适应软件开发（Adaptive Software Development，简称ASD），以及最重要的极限编程（eXtreme Programming,简称XP）。

3.3.1 极限模型 极限编程将开发阶段的4个活动（分析、设计、编码和测试）混合在一起，在全过程中采用迭代增量开发、反馈修正和反复测试。

3.3.1 极限模型 • XP开发模型核心思想： • 交流（Communication） • 简单（Simplicity ） • 反馈（Feedback） • 进取（Aggressiveness）

3.3.1 极限模型 • 优点 • 采用简单计划策略，不需要长期计划和复杂模型，开发周期短； • 在全过程采用迭代增量开发、反馈修正和反复测试的方法，能够适应用户经常变化的需求。 • 缺点 • 目前主要在小规模项目上应用并取得成功，但是否适用于中等规模或大规模软件产品，需慎重考虑； • 由于这个模型较新产品交付后维护成本是否降低，不能确定； • 对编码人员的经验要求高

3.3.2 Rational统一过程（RUP）

3.3.2 Rational统一过程（RUP） • 用例驱动 • Concise, simple, and understandable • 以体系结构为中心 • Effective basis for large-scale reuse • 增量和迭代开发 • 基于风险前驱的原则，渐进地展开分析、设计及其相关活动，每个迭代都会提供一次验证和调整模型机会，推动软件质量的提升。

0 M M n QA RTM/W 3.3.3 微软产品开发周期模型产品开发阶段产品规划阶段 M1…Mn Function Spec Product Vision 微软产品周期模型发布阶段 CC QFEs ZBB RTM/W Alpha Golden Masters Beta RC1…RCn 测试阶段

3.4.1 质量与质量规划 • 软件质量 • 是“所有描述计算机软件优秀程度的特性的组合”。 • 　软件质量度量模型由三层组成 • 第一层为质量特性 • 第二层为质量子特性 • 第三层称为度量

3.4.1 质量与质量规划 • ISO／IEC9126 – 1991（GB／T16260 – 1996）标准标准定义的6个质量特性 • 功能性 • 可靠性 • 易使用性 • 高效性 • 可维护性 • 可移植性 • 质量规划 • 　指识别哪些质量标准适用于软件项目，并确定如何满足这些标准的要求

3.4.2 质量体系、质量手册和质量计划 • 质量体系 • 　指为保证产品、过程或服务质量，满足规定（或潜在）的要求，由组织机构、职责、程序、活动、能力和资源等构成的有机整体。 • 质量手册 • 是描述企业质量体系的文件。 • 质量计划 • 　是质量管理（质量计划编制、质量保证和质量控制）的第一过程域。

3.4.2 质量体系、质量手册和质量计划 • 质量体系、质量手册和质量计划之间的关系质量体系好比一个国家的法制机构，质量手册就如同宪法，是质量体系的文档化的体现。而为每个项目制定的质量计划类似地方法规，它在符合质量手册的前提下，根据自身的要求与特殊性，通过适当的裁减修正而来。 • 关系图

3.4.3 项目质量计划的内容 • 项目实施总体目标 • 质量 • 时间 • 成本 • 　　三者是一个相互制约、相互影响的统一体，其中任一项目标变化，都会引起另两个目标变化，并受其制约。 • 项目分类 • 质量倾斜型体系 • 工期倾斜型体系 • 成本倾斜型体系

3.4.3 项目质量计划的内容 • 编写软件质量计划涉及的范围相当广，不论是项目选型、软件开发各阶段，还是配置管理、岗位职责与团队组织，又或是其他如项目制度的制定等等方面，都应该是包含在项目质量计划中的内容。

3.4.4 质量目标 • 软件生命周期三大阶段（以传统的瀑布模型为例） • 软件定义 • 软件开发 • 软件使用与维护

3.4.4 质量目标 • 　各阶段的关键元素

3.4.5 项目质量计划的编写 • 质量计划 • 应说明项目管理小组如何具体执行它的质量策略。 • 目的规划出哪些是需要被跟踪的质量工作，并建立文档，此文档可以作为软件质量工作指南，帮助项目经理确保所有工作按计划完成。 • 编写准则具体情况具体对待，没有统一定律。

3.4.6 按照质量计划实施有效的质量控制 质量计划确定后，按其建立的质量管理体系，各责任单位必须按PDCA质量环的要求，实施有效的质量控制。 • 质量控制可分为两个阶段 • 监测 • 控制质量控制应贯穿于项目的整个过程。 • 　项目收尾的两个阶段 • 项目评估 • 项目终止项目收尾阶段的质量控制是一个非常重要而又容易忽视的内容。

3.5 案例分析 • HRMS系统 • 　即人力资源管理系统，是为某跨国企业的ISS部门而开发的。 • HRMS系统生存期模型选择过程 • 　针对本项目的开发特点，参考企业的生存期模型说明和软件过程体系，决定采用迭代增量式模型。

3.5 案例分析 H R M S 项目生存期模型

讲述了软件开发过程管理需要掌握的部分知识。讲述了软件开发过程管理需要掌握的部分知识。介绍了ISO9000，CMM和CMMI三种常见的软件过程改进方法，并比较了它们之间的异同，对于选取哪种方法给予了建议。详细介绍了多种软件开发生命周期模型的特点、优缺点，对于软件开发中的相当重要的项目选型工作提供了参照。此外还介绍了质量计划的定义和详细的模版。(质量计划的制定对于软件质量控制的重要性非同小可，它涉及的范围很广，需要制定的内容相当多，部分内容读者可以在其它章节去详细了解。) 3.6 本章小结

3.7 复习思考题 • CMM和CMMI的五个级别分别是什么？CMM和CMMI的关系是什么？ • 在软件企业中推行ISO9000的意义何在？ • 传统的软件开发生命周期可以分为哪几个子阶段？ • 原型模型可以细分为哪两种？它们的内容是什么？ • 你觉得进化模型和螺旋模型有哪些相似之处吗？它们的核心思想是什么？ • 质量体系、质量手册和质量计划的联系何在？ • 在需求分析阶段需要监控的关键元素是什么？

第 3 章软件开发过程管理