第13篇控制管理.PDFVIP

第13 章 控 制 管 理 教学提示：本章介绍了软件配置的概念，软件配置管理的任务；软件质量的定义，影 响软件质量的因素，软件质量保证的策略和过程，软件质量的度量；软件风险的识别、估 计、管理和评估，软件风险驾驭和监控。 教学要求：本章主要从概念上讲述有关软件工程控制管理的知识：要求学生掌握软件 配置管理的重要性和管理的内容；掌握软件质量保证的策略和过程；掌握软件风险的识别、 管理和驾驭。 软件开发技术和软件管理技术是软件生产过程中并驾齐驱的两架马车。只有对生产过 程进行科学的管理，做到技术落实、组织落实和费用落实，才能达到提高生产率、改善产 品质量的目的。软件管理主要体现在软件的项目管理中，它先于任何技术活动之前开始， 并且贯穿于软件的整个生命周期之中。 13.1 软件配置管理 在开发软件的过程中，变化是不可避免的。如果不能适当地控制和管理变化，势必造 成混乱并产生许多严重的错误。软件配置管理是在计算机软件整个生命期内管理变化的一 组活动。 13.1.1 软件管理的危机 在一个软件开发项目中，会有大量的所谓“产品”产生，典型的如，代码、文档(包括 技术文档、产品文档、管理文档) 、数据、脚本、执行文件、安装文件、配置文件甚至一些 参数等，这些产品实际上都是软件项目的直接产品，同时也都是项目资产。但随着软件技 术的不断更新、软件系统功能的日趋复杂以及参与人员数量的大规模增加，上述产品的数 量也急剧增加。这些产品还有一个独特的特征，就是由于所有的产品都以“信息”的形式 存放在计算机中，因此，与硬件比较而言，极容易被修改(不考虑权限问题)和变化。这样 虽然有助于灵活性的提高，随之而来的是管理复杂性也急剧增加。如何有效地管理这些产 品以及它们之间的关系成为一个棘手的问题。 另一方面，软件开发往往都是在“变化”中进行的。可以毫不夸张地说，对软件开发 项目而言，“变化是持续的、永恒的，不变是相对的”，找不到不会变化的项目。需求会 变，技术会变，系统架构会变，代码会变，甚至连环境都会变，所有的变化最终都要反映 到上述的项目产品中。如何应对这些变化，如何在受控的方式下引入变更，如何监控变更 的执行，如何检验变更的结果，如何最终确认并固化变更，如何使变更具有追溯性，这一 系列 问题都将直接影响项目的进行。 第 13 章 控制管理 ·243 · 另外，软件项目最终的目标是提交 “高质量”的软件产品给最终用户 。但是，我们经 常面临的一个问题是“提交了些什么？ ”，为什么会产生这个问题，是因为最终的“高质 量”、“可运行的”软件产品是由上千个甚至更多的“部件”按照某种特定的规则编译在 一起完成的，但是每个部件都有 自己特定的变化生命周期(Change Lifecycle) ，这样就产生 了一系列的版本，许多的部件以及各自的许多版本就形成天文数字般 的组合 。遗憾 的是， 其 中只有一种组合才是我们真正想要的。没有足够 的信息，没有合理的管理手段，我们将 面临危机(事实上，这种危机在许多项目中已经一再地出现了) 。 还有另外的一些问题对项目同样会产生影响 。比如，在软件项目组中，往往是许多人 一 配合工作，这时会出现一种需求：每个人要求工作在一个“独立 ”的工作环境中，也 就是要求每个人进 工作时，不能影响和干扰其他人的工作和成果。但同时，当经过一定 的授权或者认定后，还要求可以比较便捷地和其他人的工作进行配合 。这种既独立又联系 的关系，使得通常的管理手段显得力不从心。 综合上面的问题可以看出，大量的问题已经不再是单纯的技术问题，而是需要一项专 门的管理手段来处理。这个管理手段直接的目的就是保持项目的稳定性(虽然也能间接提高 质量) ，减少 因上述原因引 的项目混乱而造成的负面影响 。这就是“配置管理”的产生 原因。 13.1.2 软件配置管理 根据 IEEE 的定义，“软件配置管理(Software Configuration Management , SCM)是一门 应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性、