第8章软件置管理.ppt

本章结束，谢谢! * * * 在20世纪60年代末70年代初提出，当时加利福利亚大学圣巴巴拉分校的Leon Presser教授在承担美国海军的航空发动机研制合同期间，撰写了一篇名为“Change and Configuration Control”的论文，提出控制变更和配置的概念，这篇论文同时也是他在管理该项目（这个过程进行过近一千四百万次修改）的一个经验总结。 Leon Presser在1975年成立了一家名为SoftTool的公司，开发了配置管理工具：Change and Configuration Control（CCC），这是最早的配置管理工具之一。国外已经有30多年历史的软件配置管理，在国内的发展却是在21世纪这几年的事，在上世纪九十年代，国内的软件企业很少会重视软件的配置管理。 项目组在完成配置项的标识之后，应按照机构标准、结合项目具体情况，定义项目基线，说明每个基线的配置项组成。注意，对某一个特定的基线而言，其配置项组成是随着项目进展而逐步增加的，并且组成基线的任何一个配置项的变更都会引起基线的变更。因此，跟踪、控制基线变更、确保基线的完整性是配置管理的一大要点。 * 在项目开发过程中，我们建议必须包含需求基线和产品基线，其他基线可以由项目经理根据实际情况裁剪。需要明确各个基线包含的配置项，确定各个基线的生产时间。 变更控制活动遵循的流程为：提出变更申请（填写《配置项变更申请表》）——评估变更影响范围（更新《配置项变更申请表》）——评审变更申请（更新《配置项变更申请表》——执行变更任务（更新《配置项变更申请表》——验证变更结果（更新《配置项变更申请表》）——更新配置库，其中根据配置项的类型及变更影响的范围来确定是由项目经理审批变更，还是有CCB来评审变更。 * * 配置管理方针 项目组软件配置管理应有专人负责（称配置管理员）；中小型项目，由项目经理或指定专人担任配置管理员，负责项目配置管理。大规模项目，应建立配置管理小组（CM组），在项目经理领导或授权下负责项目配置管理。 配置管理贯穿软件生命周期全过程，但分两个阶段：从需求到产品发布的开发阶段，配置管理由项目经理或指定专人负责；发布后进入产品维护阶段，由负责该产品技术支持部门指定的配置管理员负责。 在整个开发阶段，各类工作产品（配置项）及其变更是项目配置管理的重点；而开发环境、测试环境和运行环境的描述文档则只作为配置项纳入配置管理，受到控制。 在产品维护阶段，配置管理的重点则包括变更控制、版本控制和基线管理。 项目启动后就应开始配置管理活动，包括：定义、标识配置项，定义基线，建立配置库和基线库，确定访问权限，控制配置库/基线库的签出（Check out）和签入（Check in）。 在项目计划阶段，应编写配置管理计划（CM计划），与项目开发计划一起提交评审；在产品发布后进入维护阶段，也应编写CM计划。 按评审确认的CM计划建立基线、审计配置库和基线，及时报告配置状态。 每一个产品的所有配置项的变更均应得到管理和控制。 （每一个项目组的）软件产品最终集成（产品发布基线，或产品发布后的产品维护阶段定期生成的基线），由项目配置管理员负责实施，技术支持的配置管理员负责监督。 配置管理方针（续） 配置管理流程图 代码类配置项（源代码、可执行代码以及相关的数据文件）的划分由项目组结合项目具体情况确定（例如，一个单元或模块的代码作为一个配置项），代码类配置项的命名必须结合软件产品的特征，而版本编号则应符合机构统一规定。 开发环境、测试环境和运行环境描述，单独成文，并作为单独的配置项进行管理。 文档类配置项，比如：需求类文档、计划类文档、设计类文档、测试用例/方案文档、测试报告、用户手册等。实际执行时项目组应遵照机构标准并结合项目具体情况加以适当裁剪。 配置项分类 配置项识别的参考标准： 可能被两个或两个以上组使用的工作产品； 无论是因为错误还是因为需求变更而导致变更的工作产品； 工作产品相关依赖，其中一个变更会导致另外一个变更； 对项目非常重要的工作产品（环境类文档应当属于这一类）。 机构应制定如下配置项标识命名规则： 文档类配置项命名规则， 文档版本编号规则， 代码类配置项命名规则， 单元（模块）源代码和执行码版本编号规则。 配置项识别及标识 编制配置管理计划 配置管理计划的形成时间：项目计划初步阶段形成草稿，项目计划细化阶段定稿，并与项目开发计划一起评审。 根据《机构标准软件过程》中的列表，识别本项目中的配置项，并作为配置管理计划的一部分。在项目经理的指导下，配置管理员完成配置管理计划。 明确各类基线包含的工作产品及建立的时间、标识等。 需求基线（SRS_BL）:在软件需求规格说明书批准时建立； 计划基线（PLN_BL）:在项目计划批准时建立； 设计基线（DE