信息系统文档和配置管理

简单列出了软件项目管理过程中产生的文档是如何分类管理，如何做好配置管理的，以及配置管理要做的步骤，需要可收藏。

• 信息系统相关文档
  • 文档的种类
    • 开发文档
      • 开发文档描述开发过程本身，基本的开发文档包括以下八个方面：
      • 可行性研究报告和项目任务书
      • 需求规格说明
      • 功能规格说明
      • 设计规格说明，包括程序和数据规格说明
      • 开发计划
      • 软件集成和测试计划
      • 质量保证计划
      • 安全和测试信息
    • 产品文档
      • 产品文档描述开发过程的产物，基本包括以下四个方面：
      • 培训手册
      • 参考手册和用户指南
      • 软件支持手册
      • 产品手册和信息广告
    • 管理文档
      • 管理文档记录项目管理的信息
      • 开发过程的每个阶段的进度和进度变更的记录
      • 软件变更情况的记录
      • 开发团队的职责定义
      • 项目计划、项目阶段报告
      • 配置管理计划
    • 文档质量分级
      • 最低限度文档（1级文档），适合开发工作量低于一个人月的开发者自用程序。包括程序清单、开发记录、测试数据和程序简介
      • 内部文档（2级文档），可用于没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
      • 工作文档（3级文档），适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序
      • 正式文档（4级文档），适合那些要正式发行供普遍使用的软件产品
  • 文档管理的规则和方法
    • 文档编写规范
    • 图标编号规则
    • 文档目录编写标准
    • 文档管理制度
• 配置管理
  • 定义
    • 配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科
  • 配置管理活动
    • 配置管理包括6个活动
      • 制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付
    • 配置项
      • 外部交付的软件产品和数据
      • 指定的内部软件工作产品和数据
      • 指定的用于创建或支持软件产品的支持工具
      • 供方/供应商提供的软件和客户提供的设备/软件
      • 项目计划书
      • 需求文档
      • 设计文档
      • 源代码
      • 可执行代码
      • 测试用例
      • 运行软件所需的各种数据
      • 所有配置项的操作权限有配置管理员管理，基线配置项向开发人员开发只读权限；非基线配置项向PM、CCB及相关人员开发
    • 配置项状态
      • 配置项状态可分为“草稿”、“正式”、“修改”三种
    • 配置项版本号
      • 处于“草稿”状态的配置项的版本号格式为0.YZ，YZ的数字范围为01~99
      • 处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1~9。Y为次版本号，取值范围为0~9
      • 配置项第一次成为“正式”文件时，版本号为1.0
      • 处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值。
    • 配置项版本管理
    • 配置基线
      • 基线通常对应于开发过程中的里程碑
      • 交付给外部顾客的基线一般称为发行基线，内部开发使用的基线一般称为构造基线
      • 建立基线的事件
      • 受控的配置项
      • 建立和变更基线的程序
      • 批准变更基线所需的权限
      • 每个基线定义的内容
      • 基线为开发工作提供了一个定点和快照
      • 新项目可以再基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离
      • 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法
      • 可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误
      • 建立基线的好处
    • 配置库
      • 开发库
        • 动态库或工作库，用于保存开发人员当前在开发的配置实体
        • 动态库是开发人员的个人工作区，由开发人员自行控制，无需对其进行配置控制
      • 受控库
        • 成为主库，包含当前的基线加上对基线的变更
        • 受控库中的配置项被置于完全的配置管理之下
        • 在开发的某个阶段工作结束时，将当前的工作产品存入受控库
      • 产品库
        • 也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下
        • 在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装
      • 建库
        • 有两种建库模式：按配置项类型建库和按任务建库
        • 按配置项的类型分类建库：适用于通用软件的开发组织，产品的继承性较强
        • 按开发任务建立相应的配置库，适用于专业软件的开发组织，采用这种设置策略比较灵活
    • 配置库权限设置
    • 配置控制委员会CCB
      • 负责对配置变更做出评估、审批以及监督已批准变更的实施
      • CCB建立在项目级，其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等
      • CCB不是控制配置变更，而是负有更多的配置管理任务，例如基线审批，配置管理计划审批
    • 配置管理员CMO
      • 编写配置管理计划
      • 建立和维护配置管理系统
      • 建立和维护配置库
      • 配置项识别
      • 建立和管理基线
      • 版本管理和配置控制
      • 配置状态报告
      • 配置审计
      • 发布管理和交付
      • 对项目成员进行配置管理培训
    • 配置管理系统
      • 是用来进行配置管理的软件系统
  • 配置管理方针
    • 确定配置管理目标
      • 确保软件配置管理计划得以制订，并经过相关人员的评审和确认
      • 应该识别出要控制的项目产品有哪些，并且制订相关控制策略，以确保这些项目产品被适合的人员获取
      • 应制订控制策略，以确保项目产品在受控制范围内更改
      • 应该采取适当的工具和方法，确保相关组别和个人能够及时了解到软件基线的状态和内容
    • 确定配置管理的方针
  • 日常配置管理活动
    • 制订配置管理计划
      • 配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付
      • 实施这些活动的规范和流程
      • 实施这些活动的进度安排
      • 负责实施这些活动的人员或组织，以及他们和其他组织的关系
      • 配置管理计划包括的内容
    • 配置项标识
      • 识别需要受控的配置项
      • 为每个配置项指定唯一性的标识号
      • 定义每个配置项的重要特征
      • 确定每个配置项的所有者及其责任
      • 确定配置项进入配置管理的时间和条件
      • 建立和控制基线
      • 维护文档和组件的修订与产品版本之间的关系
      • 配置项标识是配置管理员的职能，需要包括这些步骤
    • 配置控制
      • 变更申请
      • 变更评估
        • 变更对项目的影响
        • 变更的内容是否必要
        • 变更的范围是否考虑周全
        • 变更的实施方案是否可行
        • 变更工作量估计是否合理
        • CCB组织对变更申请评估需确定的内容
        • CCB决定是否接受变更，并将决定通知相关人员
      • 通告评估结果
      • 变更实施
      • 变更验证与确认
      • 变更发布
      • 基于配置库的变更控制
        • 将待升级的基线（假设版本号为V2.1）从产品库中取出，放入受控库
        • 程序员将欲修改的代码段从受控库中检出（Check out），放入自己的开发库中进行修改。
        • 代码被Check out后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Check out
        • 程序员将开发库中修改好的代码段检入（Check in）受控库。Check in后，代码的“锁定”被解除，其他程序员可以Check out该段代码了
        • 软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（软件产品的版本号更新为V2.2，旧的V2.1版并去删除，继续在产品库中保存）
        • 以某个软件产品升级为例讲述配置库变更控制
    • 配置状态报告
      • 每个受控配置项的标识和状态
      • 每个变更申请的状态和已批准的修改的实施状态
      • 每个基线的当前和过去版本的状态以及各版本的比较
      • 其他配置管理过程活动的记录
      • 配置状态报告包括的内容
    • 配置审计
      • 作用
        • 防止向用户提交不适合的产品
        • 发现不完善的实现
        • 找出各配置项已在所要求的质量控制审核之后纳入基线并入库保存
        • 确认记录和文档保持着可追溯性
      • 功能配置审计
        • 配置项的开发已圆满完成
        • 配置项已达到配置标识中规定的性能和功能特征
        • 配置项的操作和支持文档已完成并且是符合要求的
        • 是审计配置项的一致性（配置项的实际功效是否与其需求一直）
      • 物理配置审计
        • 要交付的配置项是否存在
        • 配置项中是否包含了所有必需的项目
        • 是审计配置项的完整性（配置项的物理存在是否与预期一致）
    • 发布管理和交付
      • 存储
        • 将副本存储在不同的受控场所，以减少丢失的风险
      • 复制
        • 建立规程以确保复制的一致性和完整性
        • 确保发布用的介质不含无关项
        • 使用适合的介质以确保软件产品符合复制要求，确保其在整个交付期中内容的完整性
      • 打包
      • 交付
      • 重建
  • 配置管理工具
    • 开源的工具：SVN、GIT、CVS
• 信息文档管理与配置管理