系统集成项目管理工程师（软考中级）—— 第二十章 文档和配置管理 笔记分享

• 前言

  现在分享一些笔记给大家，希望能够帮助大家并顺利通过软考。

• 幕布地址：第二十章 文档和配置管理 - 幕布

• 概述

  • 大数据

    

• 1版本管理

  • 分类

    • 1.开发文档

      • 描述开发过程本身
      • 可行性研究报告和项目任务书;需求规格说明;功能规格说明;设计规格说明，包括程序和数据规格说明;开发计划;软件集成和测试计划;质量保证计划;安全和测试信息

    • 2.产品文档

      • 描述开发过程的产物
      • 培训手册;参考手册和用户指南;软件支持手册;产品手册和信息广告

    • 3.管理文档

      • 记录项目管理的信息
      • 开发过程的每个阶段的进度和进度变更的记录;软件变更情况的记录;开发团队的职责定义

  • 分级

    • 1级最低限度文档

      • 适合开发工作量低于一个人月的开发者自用程序

    • 2级内部文档

      • 可用于没有与其他用户共享资源的专用程序

    • 3级工作文档

      • 适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序

    • 4级正式文档

      • 适合那些要正式发行供普遍使用的软件产品

  • 规则方法

    • 1.文档书写规范

      • 应该遵循统一的书写规范，包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等

    • 2.图表编号规则

      • 对这些图表进行有规则的编号，可以方便图表的查找

        

    • 3.文档目录编写标准

    • 4.文档管理制度

      • 应该建立相应的文档管理制度

• 2配置管理

  • 周期

    • 涵盖了项目的整个生命周期

  • 活动

    • 制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付

  • 内容

    • 项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据

  • 注意点

    • 测试报告、会议纪要、工作记录不计入配置项的内容;因为一经形成就不好修改了

  • 操作权限

    • 管理
      • 由配置管理人员(CMO)严格管理
    • 原则
      • 基线配置项
        • 向软件开发人员开放读权限
        • 包括所有的设计文档和源程序
      • 非基线配置项
        • 向PM，变更控制委员会CCB及相关人员开放
        • 包括项目的各类计划和报告等

  • 配置项状态

    

    • tips
      • 配置项刚建立时，其状态为“草稿“
      • 配置项通过评审后，其状态变为“正式”。
      • 此后若更改配置项，则其状态变为“修改”
      • 当配置项修改完毕并重新通过评审时,其状态又变为“正式”

    • 草稿

      • 0.YZ
      • YZ的数字范围为01～99。随着草稿的修正，YZ的取值应递增。
      • YZ的初值和增幅由用户自己把握

    • 正式

      • X.Y
      • X为主版本号，取值范围为1~9。Y为次版本号，取值范围为0~9

    • 修改

      • X.YZ
      • 配置项正在修改时，一般只增大Z值，X.Y值保持不变
      • 配置项修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值

  • 版本控制

    • 作用于多个配置管理活动之中，如创建配置项、配置项的变更和配置项的评审等
    • 在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来
    • 对配置项的任何修改都将产生新的版本
    • 由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本
    • 目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本

  • 基线

    • 定义

      • 由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改
      • 对基线的变更必须遵循正式的变更控制程序
      • 在建立基线以前，工作产品所有者能快速、非正式的对产品做出变更。在基线建立后，变更要通过评价和验证变更的正式程序来控制。

    • 组成

      • 由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体
      • 基线中的配置项被冻结了，不能再被任何人随意修改。
      • 基线对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线
      • 将总价值给客户的基线称为一个发行基线“Release",
      • 为内部开发用的基线则称为一个构造基线“Build"。
      • 配置项是可以更改的，在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来，只是需要做好版本控制管理

    • 例子

      • 一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线
      • 产品的一个测试版本(可能包括需求分析说明书、.概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等）是基线的一个例子

    • 内容

      • 建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限

  • 分类

    • 1.开发库

      • 也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配茜实体，动态中的配置项被置于版本管理之下
      • 开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改

    • 2.受控库

      • 也称为主库，包含当前的基线加上对基线的变更
      • 受控库中的配置项被置于完全的配置管理之下
      • 在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库

    • 3.产品库

      • 也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下
      • 在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装

  • 建库模式

    • 配置项的类型

      • 适用于通用软件的开发组织
      • 产品的继承性往往较强，工具比较统一，对并行开发有一定的需求
      • 有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率
      • 并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦

    • 开发任务

      • 适用于专业软件的开发组织
      • 使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格地分类存储，人为增加目录的复杂性
      • 对于研发性的软件组织来说，采用这种设置策略比较灵活

    • 工具

      • 软件
        • VSS CVS
      • 手工

  • 权限

    • 操作权限

      

    • 受控库

      

    • 产品库

      

  • 配置标识识别

    • 1.识别需要受控的配置项
    • 2.为每个配置项指定唯一性的标识号
    • 3.定义每个配置项的重要特征
    • 4.确定每个配置项的所有者及其责任
    • 5.确定配置项进入配置管理的时间和条件
    • 6.建立和控制基线
    • 7.维护文档和组件的修订与产品版本之间的关系

  • 配置管理员职责

    • 1.编写配置管理计划
    • 2.建立和维护配置管理系统
    • 3.建立和维护配置库
    • 4.配置项识别
    • 5.建立和管理基线
    • 6.版本管理和配置控制
    • 7.配置状态报告
    • 8.配置审计
    • 9.发布管理和交付
    • 10.对项目成员进行配置管理培训

  • 配置管理计划

    • 1.配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付
    • 2.实施这些活动的规范和流程
    • 3.实施这些活动的进度安排
    • 4.负责实施这些活动的人员或组织，以及他们和其他组织的关系

  • 配置状态报告

    • 定义

      • 也称配置状态统计,其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。应着重反映当前基线配置项的状态，以向管理者报告系统开发活动的进展情况

    • 内容

      • 1.每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态
      • 2.每个变更申请的状态和已批准的修改的实施状态
      • 3.每个基线的当前和过去版本的状态以及各版本的比较
      • 4.其他配置管理过程活动的记录

  • 配置控制

    • 1.变更申请

      • 相关人员如项目经理填写变更申请表

    • 2.变更评估仓

      • CCB决定是否接受变更，并将决定通知相关人员。

    • 3.通告评估结果

    • 4.变更实施

      • 项目经理组织修改相关的配置项，并在相应的文档或程序代码中记录变更信息。

    • 5.变更验证与确认

      • 项目经理指定人员对变更后的配置项进行测试或验证。

    • 6.变更的发布

      • 配置管理员将变更内容和结果通知相关人员，并做好记录。

    • 7.基于配置库的变更控制

      

      • ①将待升级的基线从产品库中取出，放入受控库;
      • ②程序员将欲修改的代码段从受控库中检出(Check out)，放入自己的开发库中进行修改。代码被Check out后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Check out;
      • ③程序员将开发库中修改好的代码段检入(Check in)受控库。Check in后，代码的“锁定”被解除，其他程序员可以Check out该代码段了;
      • ④软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中

  • 配置审计

    • 目的

      • 1.防止向用户提交不适合的产品，如交付了用户手册的不正确版本
      • 2.发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更
      • 3.找出各配置项间不匹配或不相容的现象
      • 4.确认配置项己在所要求的质量控制审核之后纳入基线并入库保存
      • 5.确认记录和文档保持着可追溯性

    • 分类

      • 功能配置审计 一致性
        • 1.配置项的开发已圆满完成
        • 2.配置项已达到规定的性能和功能特定特性
        • 3.配置项的运行和支持文档已完成并且是符合要求的
      • 物理配置审计 完整性
        • 1.每个构建的配置项符合相应的技术文档
        • 2.配置项与配置状态报告中的信息相对应

  • 发布管理与交付

    • 包含:存储、复制、打包、交付、重建