信管-第14章-信息文档管理与配置管理

信息文档管理与配置管理-内容整理笔记

信息系统项目文档及其管理

信息系统项目相关信息（文档）

• 含义

  • 信息系统相关信息（文档）是指：某种数据媒体和其中所记录的数据

• 特点

  • 具有永久性，并可以由人/机器阅读，通常仅用于描述人工可读的东西

• 种类

  • 开发文档
    • 可行性研究报告和项目任务书
    • 需求规格说明
    • 功能规格说明
    • 设计规格说明（程序和数据规格说明）
    • 开发计划
    • 软件集成和测试计划
    • 质量保证计划
    • 安全和测试信息
  • 产品文档
    • 培训手册
    • 参考手册和用户指南
    • 软件支持手册
    • 产品手册和信息广告
  • 管理文档
    • 开发过程的每个阶段的进度和进度变更的记录
    • 软件变更情况的记录
    • 开发团队的职责定义
    • 项目计划、项目阶段报告
    • 配置管理计划

• 文档质量等级

  • 最低限度文档（1级）：适合开发工作量低于一个人月的开发者自用程序

  包括：程序清单、开发记录、测试数据和程序简介

  • 内部文档（2级）：可用于没有与其他用户共享资源的专用程序

  除1级文档所提供的信息外，2级文档还包括：程序清单内足够的注释以帮助用户安装和使用程序

  • 工作文档（3级）：适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序
  • 正式文档（4级）：适合那些要正式发行供普通使用的软件产品

  关键性程序/具有重复管理应用性质（eg:工资计算）的程序需要4级文档。4级文档遵守GB/T8567-2006的有关规定

信息系统项目文档管理的规则和方法

• 主要体现方面

  • 文档书写规范

  包括：符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等

  • 图表编号规则
  • 文档目录编写标准

  包含：文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等
  文档编号一般为“分类结构”，可采用同图标编号类似的编号规则
  文档名称：要书写完整规范
  格式或载体：是指原始单据/报表、磁盘文件、磁盘文件打印件、大型图表、重要文件原件、光盘存档等

  • 文档管理制度

  需根据组织实体的具体情况而定，主要包括：
  建立文档的相关规范：是指文档书写规范、图标编号规则和文档目录编写标准等。
  文档借阅记录的登记制度
  文档使用权限控制规则

配置管理

含义

• 在GB/T 11457-2006中，将“配置管理”正式定义为：应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，来控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性

主要活动

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

配置管理

• 配置项

  • 在GB/T 11457-2006中，对配置项的定义：为配置管理设计的硬件、软件或二者的集合，在配置管理过程汇总作为一个单个实体来对待
  • 典型配置项包括
    • 项目计划书
    • 需求文档
    • 设计文档
    • 源代码
    • 可执行代码
    • 测试用例
    • 运行软件所需的各种数据
  • 所有配置项的操作权限应由CMO（配置管理员）严格管理

  基本原则
  基线配置项向开发人员开发读取的权限
  非基线配置项向PM、CCB及相关人员开放

• 配置项状态

• 配置项版本号

• 配置项版本管理

  • 目的：按照一定的规则保存配置项额所有版本，避免发生版本丢失或混淆等现象，并可快速准确地查找到配置项的任何版本

• 配置基线（常简称为“基线”）

  • 是由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体

  • 建立基线的好处

    • 基线为开发工作提供了一个定点和快照
    • 新项目可以在基线的订单上建立

    新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离

    • 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法
    • 可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误

• 配置库

  • 存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具，利用库中的信息可回答许多配置管理的问题

  • 类型

    • 开发库（又称：动态库、程序员库或工作库）用于保存开发人员当前正在开发的配置实体

    动态中的配置项被置于版本管理之下；
    动态库是开发人员的个人工作区，由开发人员自行控制

    • 受控库（又称：主库）：包含当前的基线加上对基线的变更
    • 产品库（又称：静态库、发行库、软件仓库）：包含已发布使用的各种基线的存档，被放置于完全的配置管理之下

  • 建库模式

    • 配置项类型建库，适用于通用软件的开发组织
      • 优点：产品的继承性较强，工具比较统一，对并行开发有一定的需求，有利于对配置项的同意管理和控制，也能提高编译和发布的效率
      • 缺点：可能会造成开发人人的工作目录结构过于复杂，带来一些不必要的麻烦
    • 按任务建库，适用于专业软件的开发组织

• 配置控制委员会（CCB）

  • 负责对配置变更做出评估、审批以及监督已批准变更的实施

• 配置管理员

  • 负责在整个项目生命周期中进行配置管理活动
    • 编写配置管理计划
    • 建立和维护配置管理系统
    • 建立和维护配置库
    • 配置项识别
    • 建立和管理基线
    • 版本管理和配置控制
    • 配置状态报告
    • 配置审计
    • 发布管理和交付
    • 对项目成员进行配置管理培训

• 配置库权限设置

• 配置管理系统

  • 是用来进行配置管理的软件系统
  • 目的：是通过确定配置管理细则和提供规范的配置管理软件，加强信息系统开发过程的质量控制，增强信息系统开发过程的可控性，确保配置项（包括各种文档、数据和程序）的完备、清晰、一致和可追踪性、以及配置项状态的可控制性

配置管理的目标和方针

• 确定配置管理目标
  • 软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性
  • 目标
    • 确保软件配置管理计划得以制订，并经过相关人员的评审和确认
    • 应该识别出要控制的项目产品有哪些，并且制订相关控制策略，以确保这些项目产品被合适的人员获取
    • 应制订控制策略，以确保项目产品在受控制范围内更改
    • 应该采取适当的工具和方法，确保相关组别和个人能够及时了解到软件基线的状态和内容
• 确定配置管理的方针

日常配置管理活动

• 制定配置管理计划
  • 是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态
  • 主要内容
    • 配置管理活动，覆盖的主要活动包括：配置标识、配置控制、配置状态报告、配置审计、发布管理与交付
    • 实施这些活动的规范和流程
    • 实施这些活动的进度安排
    • 负责实施这些活动的人员或组织，以及他们和其他组织的关系
• 配置标识（也称之为：配置识别）
  • 包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征
  • 基本步骤
    • 识别需要受控的配置项
    • 为每个配置项指定唯一性的标识号
    • 定义每个配置项的重要特征
    • 确定每个配置项的所有者及其责任
    • 确定配置项进入配置管理的时间和条件
    • 建立和控制基线
    • 维护文档和组件的修订与产品版本之间的关系
• 配合控制（也就是“配置项和基线的变更控制”）
  • 包括下属任务
    • 标识和记录变更申请
    • 分析和评价变更
    • 批准或否决申请
    • 实现、验证和发布已修改的配置项
  • 变更申请（主要是陈述）：要做什么变更，为什么要做，以及打算怎么做变更
  • 变更评估
    • 变更对项目的影响
    • 变更的内容是否必要
    • 变更的范围是否考虑周全
    • 变更的实施方案是否可行
    • 变更工作量估计是否合理
  • 通告评估结果
  • 变更实施
  • 变更验证与确认
  • 变更的发布
  • 基于配置库的变更控制
• 配置状态报告（又称之为“配置状态统计”）

  • 任务：有效地记录和报告管理配置所需要的信息

  • 目的：及时，准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作

  • 包括内容

    • 每个受控配置项的标识和状态

    注：一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态

    • 每个变更申请的状态和已批准的修改的实施状态
    • 每个基线的当前和过去版本的状态以及个版本的比较
    • 其他配置管理过程活动的记录

  • 着重反应当前基线配置项的状态，以向管理者报告系统开发活动的进展情况

• 配置审计（又称之为“配置审核或配置评价”）
  • 包括：功能配置审计和屋里配置审计，分别用以验证当前配置项的一致性和完整性
  • 功能配置审计
    • 是审计配置项的一致性（配置项的实际功效是否与其需求一致）
    • 配置项的开发已圆满完成
    • 配置项已达到配置标识中规定的性能和功能特征
    • 配置项的操作和支持文档已完成并且是符合要求的
  • 物理配置审计
    • 是审计配置项的完整性（配置项的物理存在是否与预期一致）
    • 要交付的配置项是否存在
    • 配置项中是否包含了所有必需的项目
• 发布管理和交付
  • 主要任务：有效控制软件产品和文档的发行和交付，在软件产品的生存期内妥善保存代码和文档的母拷贝
  • 存储
    • 选择存储介质使再生差错或损坏降至最低限度
    • 根据媒体的存储期，以一定频次运行或刷新已存档的配置项
    • 将副本存储在不同的受控场所，以减少丢失的风险
  • 复制
    • 应建立规程以确保复制的一致性和完整性
    • 应确保发布用的介质不含无关项（eg:软件病毒或不适合演示的测试数据）
    • 应使用适合的介质以确保软件产品符合复制要求，确保其在整个交付期中内容的完整性
  • 打包
    • 应确保按批准的规程制备交付的介质。
  • 交付
    • 供方应按合同中的规定交付产品或服务
  • 重建
    • 应能重建软件环境，以确保发布的配置项在所保留的先前版本要求的未来一段时间内的可重新配置的

文档管理、配置管理工具

工具综述

• 常用付费软件配置管理工具
  • Rational ClearCase（CC）
    • IBM Rational公司的旗舰产品之一，全球领先的软件配置管理工具
    • 广泛地应用于众多的企业级软件工程实践之中，拥有众多的企业级用户
    • 提供C/S和B/S两种架构的配置管理解决方案，提供了全面的软件配置管理功能
    • 特点
      • 独有的存储库VOB (Version Object Bases)
      • 可视化的文件版本树
      • 并行开发
      • 版本历史记录
      • 自动的比较和版本间的合并
      • 工作空间管理
  • Perforce
  • CA CCC
  • Havest Merant PVCS
  • Microsoft VSS, CVS
• 常用的开源免费的软件配置管理工具
  • SVN
    • CollabNet提供开发，是集中式版本控制之王
    • 运行方式
      • 独立服务器
      • 借助apache运行
    • 优点
      • 支持重命名
      • 开发的时候不一定要锁定
      • 多平台
      • 更好地客户端支持
      • 更好地与外围工具集成
      • 方便
      • 速度与稳定性不错
  • GIT
    • 优势
      • 更方便的Merge
      • 更方便地管理
      • 更健壮的系统
      • 对网络的依赖性更低
      • 更少的“仓库污染”
  • CVS
  • 概要: 比较
    • GIT的速度比SVN快
    • SVN是集中式管理，GIT是分布式管理
      • 集中式：只有在服务器上才有一个代码仓库，只能在服务器进行统一管理
      • 分布式：本地有个代码仓库，开发者可在本地提交
    • SVN使用分支较为笨拙，GIT可轻松用于无限分支
    • SVN必须联网才能工作，GIT支持本地版本控制工作

    • 旧版本的SVN会在每一个目录置放一个.svn，GIT只会在根目录拥有一个.git

      
      
      信息文档管理与配置管理.png