配置管理_配置管理计划 - CSDN
配置管理 订阅
配置管理(Configuration Management,CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。 展开全文
配置管理(Configuration Management,CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。
信息
外文名
Configuration Management
用    于
软件开发
中文名
配置管理
解    释
通过技术对软件产品进行控制
配置管理简介
配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。一致性、可追溯性,使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。 [1]  早在七十年代初期加利福利亚大学的Leon Presser教授就撰写了一篇论文,提出控制变更和配置的概念,之后在1975年,他成立了一家名为SoftTool的公司,开发了自己的配置管理工具:CCC,这也是最早的配置管理工具之一。之后,随着软件开发规模的逐渐增大,越来越多的公司和团队意识到了软件配置管理的重要性,而相应的软件配置管理工具也如雨后春笋一般,纷纷涌现,比较有代表性的有:Marc Rochkind的SCCS(Source Code Control System)和Walter Tichy的RCS(Revision Control System),这两种工具对日后的配置管理工具的发展做出了重大的贡献,目前绝大多数广泛使用的配置管理工具基本上都是基于这两者的设计思想和体系架构。配置管理在软件开发过程和项目管理过程中的作用随着软件系统的日益复杂化和用户需求、软件更新的频繁化,配置管理逐渐成为软件生命周期中的重要控制过程,在软件开发过程中扮演着越来越来重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面,同时对软件开发过程的宏观管理,即项目管理,也有重要的支持作用。良好的配置管理能使软件开发过程有更好的可预测性,使软件系统具有可重复性,使用户和主管部门用软件质量和开发小组有更强的信心。软件配置管理的最终目标是管理软件产品。由于软件产品是在用户不断变化的需求驱动下不断变化,为了保证对产品有效地进行控制和追踪,配置管理过程不能仅仅对静态的、成形的产品进行管理,而必须对动态的、成长的产品进行管理。由此可见,配置管理同软件开发过程紧密相关。配置管理必须紧扣软件开发过程的各个环节:管理用户所提出的需求,监控其实施,确保用户需求最终落实到产品的各个版本中去,并在产品发行和用户支持等方面提供帮助,响应用户新的需求,推动新的开发周期。通过配置管理过程的控制,用户对软件产品的需求如同普通产品的订单一样,遵循一个严格的流程,经过一条受控的生产流水线,最后形成产品,发售给相应用户。从另一个角度看,在产品开发的不同阶段通常有不同的任务,由不同的角色担当,各个角色职责明确,泾渭分明,但同时又前后衔接,相互协调。好的配置管理过程有助于规范各个角色的行为,同时又为角色之间的任务传递提供无缝的接合,使整个开发团队像是一个交响乐队一样和谐而又错杂地行进。正因为配置管理过程直接连接产品开发过程、开发人员和最终产品,这些都是项目主管人员所关注的重点,因此配置管理系统在软件项目管理中也起着重要作用。配置管理过程演化出的控制、报告功能可帮助项目经理更好地了解项目的进度、开发人员的负荷、工作效率和产品质量状况、交付日期等信息。同时配置管理过程所规范的工作流程和明确的分工有利于管理者应付开发人员流动的困境,使新的成员可以快速实现任务交接,尽量减少因人员流动而造成的损失。
收起全文
精华内容
参与话题
  • 配置管理-学习笔记

    千次阅读 2019-04-23 10:34:54
    配置管理 配置管理是描述、跟踪、控制和汇报所有IT基础架构中所有设备或系统的管理流程。这些设备和系统被称为配置项,通过该管理流程实现对所有配置项的有效管理、跟踪和控制,以支持IT服务和基础设施成功运行。 ...

    配置管理

        配置管理是描述、跟踪、控制和汇报所有IT基础架构中所有设备或系统的管理流程。这些设备和系统被称为配置项,通过该管理流程实现对所有配置项的有效管理、跟踪和控制,以支持IT服务和基础设施成功运行。

        1.配置项
        配置项是指基础架构组件或基础架构有关的项目,包括软件、硬件和各种文档,如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议电信服务等。这些组件或项目已经或将受到配置管理的控制。

        2.配置基准线
        配置基准线是指一个产品或系统在某一特定时刻的配置状况,这种配置不仅体现了其产品或系统的结构,还反映了其具体内容,从而使得以后可以按照上述配置重建该产品或系统。尽管被作为基准线的这个配置状态以后可能发生改变,但这个基准线本身保持不变。

        3.配置管理数据库(CMDB)
        配置管理数据库是指包含每个配置项及配置项之间重要关系的详细资料的数据库。
        配置管理数据库管理所有配置项及其关系,以及与这些配置项有关的事件、问题、变更和发布及其相关员工、供应商和业务部门信息,此外,配置管理数据库保存多种服务的详细信息及这些服务于IT组件之间的关系,最后,配置管理数据库保存配置项的财物信息,如供应商、购买费用、购买日期。

        4.最终软件库
        最终软件库是一个存放和保管所有已批准的最终版本的软件配置的地方,是软件正本存放的物理性仓库或逻辑性存储空间。最终软件库也可能包括一个用来保管外购软件正本的物理性参考。

    目标
        所有配置项能够被识别和记录
        配置项当前和历史状态得到回报
        维护配置项记录的完整性
        提高IT环境的稳定性
        确保IT资产的有效控制和管理
    范围
        配置管理的范围是IT生产环境的所有配置项,包括生产环境的服务器、存储设备、机房环境、应用软件、网络设备、板卡、重要的客户端、合同、文档等,具体内容包括识别、控制、汇报和审核等行为。

    主要活动:
        配置管理流程的基本活动主要包括配置管理计划、配置识别、配置项控制、配置状态报告、配置审验、配置管理数据库备份、存储和保管等。

    配置项记录示例

    配置项分类
    编号 类别 子类 条目
    1 硬件类 服务器 UNIX主机
    2 PC服务器
    3 存储 磁盘整列
    4 光纤交换机
    5 磁带库
    6 网络设备 路由器
    7 交换机
    8 端口
    9 Modem
    10 光电转换器
    11 防火墙
    12 VPN网关
    13 其他网络设备
    14 机房环境 空调
    15 不间断电源
    16 机柜
    17 桌面PC 台式机
    18 笔记本电脑
    19 外设 打印机
    20 扫描仪
    21 复印机
    22 其他
    23 软件类 应用软件 自主开发软件
    24 外包开发软件
    25 商业软件
    26 系统软件 操作系统
    27 数据库应用
    28 中间件
    29 其他
    30 工具软件  
    31 文档类 管理类  
    32 技术类  
    33 工程类  
    34 合同类 产品购买合同
    35 维护合同
    配置项分类
    大类 二级类 设备
    主机 物理主机类 x86服务器
    小型机
    逻辑主机类 VM
    LPAR
    Ldom
    软件实例类 操作系统 ESXI
    Windows
    AIX
    Solaris
    Linux
    应用软件 应用软件
    数据库类 HANA
    DB2
    SQL Server
    Oracle
    My SQL
    中间件类 Tomcat
    Apache
    IIS
    Netweaver
    WebSphere
    WebLogic
    网络设备类 传输设备 路由设备
    交换机设备
    网络安全类 审计设备
    漏洞扫描设备
    防火前设备
    入侵监测设备
    VPN
    负载均衡类 负载均衡
    存储设备类 磁盘阵列类 LUN
    磁盘阵列
    宽带类 宽带
    光纤交换机 光纤交换机
    环境设备类 配电类 配电柜
    动力类 UPS
    环控类 空调
    基础类 机柜
    业务服务类 插件类 监控程序
    业务系统类 业务系统
    投标
    附件存储信息 招投标  
    方案  
    文档  
    基本配置项信息 资产名称名称  
    资产编号  
    状态 使用中
    位置  
    采购日期  
    到货日期  
    预警日期  
    生命周期(月)  
    保修期(月)  
    资产原值  
    部门  
    负责人  
    使用人  
    折旧年限  

     

    配置项状态
    编号 状态 说明
    1 借出 设备借给其他单位使用
    2 入库 设备已经出入备件库
    3 已安装 设备已经完成安装
    4 测试中 正在测试中
    5 运行中 设备处于正常运行状态
    6 维护中 正处于维护
    7 报废 设备已经被报废
    8 丢失 设备丢失
    9 借用 设备借自于其他单位
    10 闲置 设备处于闲置状态,指用途不明确的未使用设备
    11 热备 备用可以被系统自动切换投入使用
    12 冷备 设备处于冷备用状态,可以有人工切换投入使用
    13 调拨 设备处于调拨的过程中
    配置项状态
    编号 关系 说明 示例
    1 安装在。。。上 Install on 数据库安装在主机上
    2 连接关系 connect with 主机与网络相连
    3 依赖关系 Depend on 应用依赖于中间件
    4 使用关系 use 谁使用某台PC机
    5 运行于。。。上 Perform on 应用于OS上

     

    配置项属性
      设备编码   名称
      品牌   型号
      序列号   状态
      物理位置   IP地址
      购买日期   CUP
      内存   备注(描述设备具体细节)
      售后服务   操作系统
      售后联系电话   硬盘(硬盘大小)
      显示器(规格、型号)   使用部门
      固定资产编号   使用人员
      维护部门   维护人员
      最近审核日期   维护合同

     

    与其他流程的关系
        配置管理流程在运作过程中需要其他流程为其提供信息,如变更管理流程提供的有关IT
        组件变更的信息、采购流程提供的有关IT组件采购信息。配置管理同时为其他流程提供配置管理报告和配置管理数控中的信息。

        事件管理:需要配置项等方面的信息,以确定配置项的具体位置和责任人,了解是否存在于配置项有关的问题和知名错误。

        问题管理:需要根据配置项管理所提供的基础架构配置方面的信息分析问题或知名错误与配置项之间的关系,并根据配置管理数据库中的信息对事件和问题进行调查和分析,如通过比较基础架构的实际配置与配置管理数据库中的被批准的配置来发现基础架构的缺陷。

        变更管理:根据配置管理数据库中提供的配置项之间的相互关系的信息,来估计摸个特定的IT组件的变更对其他组件可能产生的影响,同时变更管理为配置管理提供有关IT基础架构变更方面的信息,以更新配置管理数据库。

        发布管理:为配置管理提供有关IT基础架构配置变更的发布计划和版本信息以及已实施变更的配置项的信息。另外,在实施变更和发布前,发布管理需要根据配置管理提供配置项信息确定发布的类型和范围。

     

    衡量指标
        IT资产管理方面
            在配置管理数据库中发现的配置项属性出现错误的比例
            成功通过审查和验证的配置项的比例
            审查和验证配置项的速度和准确性
        提高IT服务质量方面
            因配置项信息不准确而导致的IT服务运营故障比例
            组件修复速度
            客户对服务和终端设备的满意度
            没有变更单而配置管理数据库没有更新的次数
            有变更单但配置管理数据库没有更新的次数
            配置项实体配置错误的次数
            审计过程中配置项状态差异百分比及其趋势
            增加的新配置向的数量及其趋势
            报废的配置项的数量及其趋势
            修改的配置项的数量及其趋势
            上一次的改进行动计划的落实情况

    展开全文
  •  配置管理(Configuration Management, CM)的目的,在使用配置识别、配置控制、配置状态记录及配置审计,来达到建立与维护工作产品的完整性。  配置管理提供了结构化的,有序化的,产品化的管理软件工程的方法...

    一、概述
      配置管理
    (Configuration Management, CM)的目的,在使用配置识别、配置控制、配置状态记录及配置审计,来达到建立与维护工作产品的完整性。
      配置管理提供了结构化的,有序化的,产品化的管理软件工程的方法。它涵盖了软件生命周期的所有领域并影响所有数据和过程。配置管理是指用于控制系统一系列变化的学科。通过一系列技术,方法和手段来维护产品的历史,标识和定位产品独有的版本,并在产品的开发和发布阶段控制变化。通过有序管理和减少重复性工作,配置管理保证了生产的质量和效率。可以说不懂软件项目的配置管理,就不懂软件开发管理,不对软件项目进行配置管理,就没有进行软件项目开发管理。
      二、配置管理的基本概念
      1、配置标识
      IEEE中的定义:识别产品的结构、产品的构件及其类型,为其分配唯一的标识符,并以某种形式提供对它们的存取。
      可以理解为:标识软件系统的结构,标识独立部件(工作产品),并使它们是可访问的。配置标识的目的,是在整个生命周期中标识系统各部件并提供对软件过程及其软件产品的跟踪能力。即:怎么命名?版本如何设置?放到哪里?哪些是受控的?受控的级别是什么?读写的权限是什么?
      2、配置变更控制
      IEEE中的定义:通过建立产品基线,控制软件产品的发布和在整个软件生命周期中对软件产品的修改。
      可以理解为:软件生命周期中控制软件产品的发布和变更,目的是建立确保软件产品质量的机制。即怎么变更?谁控制变更?谁来分析变更的影响范围?变更后如何验证、入库以及恢复?
      3、配置状态统计
      IEEE中的定义:记录并报告构件和修改请求的状态,并收集关于产品构件的重要统计信息。
      可以理解为:记录和报告变更过程,目标是不间断记录所有基线项的状态和历史,并进行维护。每次基线的生成和变更都能让相关者知道变了什么?为什么变?变化前后的状态是什么?
      4、配置审计
      IEEE中的定义:确认产品的完整性并维护构件间的一致性,即确保产品是一个严格定义的构件集合。
      可以理解为:验证软件产品的构造是否符合需求、标准、或合同的要求,目的是根据配置管理的过程和程序,验证所有的软件产品已经产生并有正确标识和描述,所有阶段的工作产品都一致并满足系统的需求,并且所有的变更需求都已解决。
      三、配置管理计划
      《配置管理计划》一般是《项目综合管理计划》的子计划。在项目策划的时候我们就要制定这个计划。
      1、配置管理活动的职责分配
        a)配置管理员:识别和标识配置项,建立和维护配置库;配置库管理;执行配置审计
        b)配置控制委员会(CCB):批准基线库的生成;评估和审核变更请求,并确保批准的更改得到实施.
        c)QA:配置管理活动审查
      2、配置管理的资源
        a)配置库的服务器
        b)配置库工具
        c)配置库的访问方式3、识别配置项
      对于配置项,可以给出一个比较简单的定义,即软件过程的输出信息可以分为4个主要类别:
        a)计算机程序(源代码及可执行程序)
        b)描述计算机程序的文档(针对技术开发者和用户)
        c)数据(包含在程序内部或外部)
        d)项目管理的有关文件、信息记录等
      在实际项目中,我们如何识别配置项?
        a)《项目过程裁剪定义》中要产出的工作产品
        b)源代码、可执行程序
        c)数据(包含在程序内部或外部)
        d)客户提供的文档、工具
        e)需要提交给客户的其他工作产品。
      4、配置项的控制级别
      IEEE中基线的定义是这样的:已经正式通过审核批准的某规约或产品,它因此可作为进一步开发的基础,并且只能通过正式的变化控制过程改变。
      在项目中我们一般把配置项分为3种控制级别:
        a)数据项:数据项是指对变更不作控制的配置项;
        b)受控项:受控项是指不需要进行基线控制但变更后需要得到相关人员确认或通知到相关人员的配置项。
        c)基线项:基线项是指需要严格执行基线变更流程的配置项。
      一般数据项就是我们大部分企业说的工作区。
      5、配置项的标识与控制
      在配置库中,配置项都应该有一个合适的目录去存放和分类。放入之特定目录下的配置项也必须严格按照“文件命名规则”来命名,并且这些配置项要按照“版本设置规则”来标识版本。
      在配置库中各种配置项的操作权限都应严格管理。我们一般是通过目录的访问权限来控制的,所以配置库的目录结构与配置项的访问权限也有着密切的关系,配置项的权限设置的原则如下:
        a)基线配置项:只有配置管理员有写的权限,项目组全员开放读的权限。
        b)受控配置项:PM、CCB读写权限,项目组全员或相关人员开放读的权限。
        c)数据配置项:PM、CCB、配置项的责任人或开发小组开放读写权限,项目组全员开放读的权限。
      6、基线计划
      在配置管理中基线发布是一个重要活动,基线发布的时间点一般就是项目里程碑时间点。通常会有下列基线:需求基线、设计基线、代码基线、交付基线等。
      在计划中我们要依据《项目综合管理计划》的里程碑时间点,结合项目管理的需要,设定项目的基线计划。即项目过程中发布哪些基线,这些基线发布的时间点,发布的责任人。
      同时我们也要明确定义基线的版本规则,因为基线也是在不断变更的。 

      7、配置审计计划
      配置审计的时机:
        a)一般基线发布前对要进入基线的配置项进行配置审计。
        b)如果2条基线的发布时长超过2个月时,应该在时间2个基线发布中适当安排配置审计,建议是1个月1次。
        c)产品交付前必须要进行配置审计。
      我们在计划中要规划好配置审计的概要时间。这样有利于配置审计的及时开展。
      8、配置管理计划
      定义各类配置项如库、出库的准则和操作流程。
      定义基线变更的准则和操作流程。
      明确配置库的备份及维护的方法,当出现异常后如何恢复的预案等。
      版本发布的准则、发布流程及发布计划,如测试版本、β版本、Release版本等。
      四、配置管理的主要活动
      1、配置状态报告

      配置状态报告是一个配置管理中一个很重要的活动,多个开发组保持开发一致的重要活动。我们的配置状态报告的主要对象是基线库。
      配置状态报告要报告的内容有:基线库的基线项的清单、基线项的名称、版本、存放位置。
      在每次基线变更后,状态报告还要能说明。哪些基线项变了、为什么变、变化前的版本是什么、变化后的版本是什么。
      2、基线变更流程
      一般项目管理中,基线变更的控制权限是CCB(配置变更委员会)。基线变更控制一般是由两种变更方式,需求变更、内部变更。下图是基线变更的流程。


     3、配置审计
      在CMMI模型中明确将配置审计分为物理审计和功能审计,在定义中与IEEE是没有冲突的。在CMMI模型中对物理审计和功能审计的定义如下:
        a)物理审计:验证已构建出的配置项符合定义和描述它的技术文档的审计行为。
        b)功能审计:验证配置项的开发已经被完全满足的审计行为,即验证配置项已经达到了在功能或已分配的配置标识中刻画的性能和功能特性,并且其运行和支持文档是完整的和满意的。
      配置审计的范围:物理审计的范围是受控项和基线项,功能审计的范围是基线项。
      功能审计是验收的前提条件,不同的角色所做的功能审计侧重点不同。
      配置审计的步骤:
        a)准备《配置审计检查单》,这个检查单包含所有受控项和基线项的状态,受控项清单包含受控项的命名、控制级别、存放位置、当前版本、控制权限等状态信息。基线项的状态就是最新的《配置状态报告》中配置项的状态。
        b)依据配置审计的计划时间去执行配置审计。
        c)根据《配置审计检查单》对配置库进行物理审计。责任人:CM发起并参与、CCB。
        d)根据《配置审计检查单》对配置库进行功能审计。责任人:CM发起并参与、需求人员、CCB(PM、及各Leader)及相关人员。
        e)QA监督配置审计是否按照标准流程来进行,并记录不一致问题。
        f)每次配置审计要将审计结果记录到《配置审计报告》中,记录和跟踪配置审计检查出的问题。
      物理审计的方法:
      根据《配置审计检查单》去检查,该有的配置项是否都有了?文件命名与计划中的命名规则是否一致?存放位置与计划是否一致?版本设置与计划中的版本设置规则是否一致?控制权限是正确?
      功能审计的方法:
        a)检查与需求的一致性、完整性:根据《需求追踪矩阵》对配置库的基线项进行检查,看看所有需求是否都已经不多不少地被实现了?并纳入了基线库?如果物理审计中基线项的审计没有问题,我们也可以通过《需求追踪矩阵》对《配置状态报告》中基线项进行检查,看看所有需求是否都已经不多不少地被实现了?
        b)验证工作产品与需求的符合程度:查看所有基线项评审和测试报告,看看所有的基线项是否都已经通过各级评审及测试?
        c)交付给客户的文档与软件的功能一致性:检查交付客户的文档是否与当前最新的基线中的需求一致?
      4、配置管理活动的QA审查
      配置管理过程的审查:
      确保配置管理的记录和配置项是完整的、一致的和准确的审查行为,客观评价管理过程与其过程描述、标准和规程的符合性并处理不一致问题。
      配置管理活动的QA检查时机:
      定期检查配置管理工作,依据基线和配置审计计划检查这些基线的建立变更及配置审计活动。
      检查内容:
        a)检查配置管理的各种记录、报告等与配置库中的物理的配置项实体是否一致、完整、准确
        b)是否每次新建和变更基线都有完整的申请记录
        c)每次基线新建和变更的审核流程是否执行并有记录
        d)基线库中的产品是否经过了功能审计
        e)每次配置审计的问题是否都被跟踪直到关闭
        f)配置库的权限是否都是正确分配的
        g)配置库的目录结构是否都与《配置管理计划》一致

    展开全文
  • 配置管理流程图

    2020-07-29 14:20:04
    很好的一个配置管理流程图,关心配置管理的朋友,相信此图会对你有帮助
  • 第七章 软件配置管理

    万次阅读 2018-07-02 20:27:02
    本章内容提要软件配置管理的作用软件配置管理的相关概念建立软件配置管理环境版本控制系统集成分支管理变更管理配置审计和配置状态报告配置管理过程软件配置管理工具第一节 软件配置管理的作用星形网拓扑结构不同...

    本章内容提要

    软件配置管理的作用
    软件配置管理的相关概念
    建立软件配置管理环境
    版本控制
    系统集成
    分支管理
    变更管理
    配置审计和配置状态报告
    配置管理过程
    软件配置管理工具

    第一节  软件配置管理的作用


    星形网拓扑结构


    不同程序员对程序的更改会产生冲突


    软件项目中可能遇到如下的问题:

    找不到某个文件的历史版本;
    开发人员使用错误的程序版本;
    开发人员未经授权修改代码或文档;
    人员流动,交接工作不彻底;
    无法重新编译软件的某个历史版本;
    因协同开发,或者异地开发,版本变更混乱导致整个项目失败;
    ……

    •  软件项目进行中面临着持续不断的变化,变化可能导致混乱,而软件配置管理就是用于控制变化。
    •  软件配置管理(Software Configuration Management, SCM)是指一套管理软件开发和维护过程中所产生的各种中间软件产品的方法和规则。它是控制软件系统演变的学科。

    软件配置管理的目标

    • 标志变更
    • 控制变更
    • 确保变更正确实现
    • 向受变更影响的组织和个人报告变更

    软件配置管理的效果

    • 记录软件产品的演化过程。
    • 确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置。
    • 最终保证软件产品的完整性、一致性、可追溯性。

    软件配置管理的主要功能

    • 版本控制:采用相应的流程和工具,对软件开发过程中产生的各种文件的版本进行管理。是软件配置管理的核心内容。
    • 变更管理:为防止开发人员对软件的随意变更而进行的管理上的审核过程,包括变更请求、变更评估、变更批准/拒绝、变更实现。
    • 其它:配置审计、配置状态统计等。

    第二节  软件配置管理的相关概念

    • 软件配置项(Software Configuration Item, SCI)

        软件配置管理的对象,一个软件配置项是项目中一个特定的、可文档化的工作产品集。
        常见的软件配置项:需求规格说明书、设计规格说明书、源代码、测试计划、测试用例、用户手册。
        构造软件的工具和软件赖以运行的环境也常常列入配置管理的范畴。

    • 基线(Baseline)

        已经正式通过复审和批准的某规约和产品,它因此可作为进一步开发的基础,并且只能通过正式的变化控制过程来改变。

    • 各开发阶段结束时形成里程碑基线。


    在软件配置管理中,基线的含义在不同的应用场合会有所不同。

    • 软件配置控制委员会(Software Configuration Control Board, SCCB)

        负责管理软件配置项变更的组织。

    评估变更
    批准/拒绝变更申请
    在项目生存期内规范变更申请流程
    对变更所产生的后续影响进行监督和控制。
    与项目管理层沟通

    第三节 建立软件配置管理环境

    在企业级:
    (1)建立工具集
    (2)建立规范
    在项目级:
    (1)识别和标志配置项
    (2)建立配置库

    3.1 企业级的工作

    (1)建立工具集

    • 一个企业的配置管理工具应该统一购买、安装、设置和维护。以节约资源,提高工作效率。不要每个项目都搞一套工具。
    • 情况差别很大的项目可以考虑使用不同的工具,但要尽量减少工具的种类。

    (2)建立软件配置管理规范

    • 在企业级建立标准的软件配置管理规范,如变更控制流程、版本编号规则、缺陷跟踪流程、分支策略等。
    • 一个软件项目可使用标准的软件配置管理规范,如果有特殊需要,可对其进行剪裁,或重新制定规范。重新制定的项目规范,如果今后有很多类似的项目,可把其上升为企业级标准规范。

    3.2 项目级的工作

    (1)识别和标志配置项

    • 将软件项目中需要进行控制的工作产品定义为软件配置项(SCI)。
    • 配置项分为两类:

    基本配置项:软件开发者在项目开发过程中所创建的基本工作单元。
    集成配置项:一个集成配置项是基本配置项或其它集成配置项的集合。

    (2)建立配置库
    • 配置管理库,简称配置库,是配置管理环境的核心,使用配置管理工具建立。
        配置库存储配置项(SCI)、修改请求、变化记录等,并提供对库中所存储文件的版本控制。
    • 为不同的人员(如开发人员、测试人员、集成人员、项目管理者)分配不同的访问配置库的权限。
    • 配置库中的配置项每经历一次改变将形成一个新的版本并被分配相应的版本标志。配置库中通常以增量方式存储配置项的各个版本,以减少空间消耗并增强版本处理的灵活性。
    • 例如:一个配置项最初从开发者的工作空间提交到配置库,形成最初版本,如1.0,此后每修改和提交一次版本就会变化,如1.1,1.2,……,配置库采用增量方式存储每个版本,以节省空间。可以在任何时候得到配置项的任何版本。

    第四节 版本控制

    4.1 配置库的检入检出机制
    4.2 防止版本覆盖的两种方法
    4.3 适时更新工作空间
    4.4 记录源代码整体版本
    4.5 保存安装包
    4.6 软件版本编号方法
    4.7 项目外资源的版本控制

    4.1 配置库的检入检出机制

        

    配置库的检入检出和版本控制机制解决了团队软件开发中的两个重要问题:

    • 访问控制:保证具有相应权限的人员才能修改配置项。
    • 并行控制:保证不同人员同时对某配置项进行的修改不会互相覆盖。

    4.2 防止版本覆盖的两种方法   

    • 第一种方法:串行(加锁-解锁)。
        程序员在修改文件之前,版本控制工具将文件加锁,其他人不能对它进行修改。该程序员修改完毕,将文件再检入到配置库中时,版本控制工具再将其解锁,其他人才能进行修改。
        特点:效率较低,应尽量减小加锁范围。
    • Visual SourceSafe (VSS),微软出品的版本控制工具,默认支持第一种方法。通过设置,也可支持第二种方法。
    • 第二种方法:并行(修改-合并)。不同的程序员可同时修改某一文件,修改完成后,在某一合适的时刻进行合并(由版本控制工具辅助完成)。
       特点:效率较高
      Subversion(SVN)、ClearCase(CC)都同时支持以上两种方法,但以第二种方法为主。

      市面上还有几十种版本控制工具,它们都至少支持以上两种方法中的一种

    配置项的演化图(Evolution Graph)

    4.3 适时更新工作空间

    • 开发人员在自己的工作空间中工作的时候,配置库中可能已有了很大的变化,其他开发人员已向配置库提交了很多代码。这样,自己的工作空间中的代码就有过时的风险,使得自己开发的代码不能与其他人最新的代码共同工作。
    • 因此开发人员需要适时地更新(update)自己的工作空间。
    • Subversion中的更新就叫“update”。其它一些工具还有另外的称呼,如变基(Rebase),重新配置(Reconfig)等。
    • 什么时候更新?
    1.  在开始一个新任务的时候,如开发一个新功能模块,修改一处代码等。这时的更新建立了关于这个任务的初始工作环境。不要在一开始的时候就落伍
    2.  在完成任务的过程中,可能需要更新。特别是在任务持续时间较长的情况下。要跟上时代的步伐
    3.  在任务完成后,即将提交的时候,最好做一次更新,并测试一下,以保证自己新写的代码,可以与别人的代码一起工作。保证提交有基本的质量。做事要善始善终
        注意:更新工作空间也不必要太频繁

    4.4 记录源代码整体版本

    • 在软件项目周期的不同时期会产生不同的版本,且在同一时期也会有不同的版本。
    • 因此需要记录软件的整体版本,明确软件的每个版本都包含哪些特定版本的源程序文件。
    记录源代码整体版本的方法:
    • 方法一:在软件开发过程中,当某一版本形成时,复制其所有源代码。一些版本控制工具提供的复制(Copy)命令即可完成这一任务。
    • 方法二:记录某个整体版本,只需要记录这个版本是由哪些文件的具体哪个版本组成的。因此可以在相关文件的特定版本上打个标签(Label/Tag),标签的名字,就是整体版本的名字。
    • Subversion支持以上第一种方法。此外,Subversion总是自动地产生新的整体版本。程序员的每一次提交,都会产生一个新的源代码整体版本号,将这一整体版本号分配给所有源程序文件。因此Subversion实际上也支持以上第二种方法。
    • ClearCase采用的是第二种方法。

    基线及其质量状态

    • 在谈论源代码版本管理的时候,基线(Baseline)的含义是,被明显地标志和记录下来的源代码整体版本。
    • 基线具有质量状态:
    1.  刚刚标记出来的时候,其质量未知(Initial);
    2.  编译链接和打包通过后,其质量是通过构建的(Built);
    3. 如果通过了一定程度的测试,其质量是通过测试的(Tested);
    4. 如果通过了详尽测试,可以发布,其质量是可发布的(Released)。
    • 当基线由一个较低的质量状态达到了一个更高的质量状态时,就产生了一个基线提升(Baseline Promotion)。
    • Subversion可以用版本属性来表示基线的质量状态。
    • ClearCase UCM明确地支持基线提升。不仅有相应的命令,也可以在图形界面中操作和查看。

    4.5 保存安装包

    • 在发布软件之前,或在对软件进行系统测试或验收测试之前,需要生成安装包。安装包同样需要保存,并标上相应的版本号,原因如下:
    1.  将来在需要该安装包时,可以迅速准确地得到它,不必从源代码开始重新编译、打包,这样可以节省时间。
    2.  用户或系统测试人员发现的软件Bug,有可能是由安装包的生成过程造成的,保存了安装包,可以快速地定位Bug的原因。
    • ClearCase不仅存储和管理源代码,也存储和管理由源代码生成的内容,这些内容被称为“导出对象”(Derived Object),包括可执行文件、库文件、数据文件等。安装包也是导出对象的一种。

    4.6 软件版本编号方法

    • 源代码文件、文档文件和产品整体(源代码整体和安装包)都有版本号(Version Number)。
    • 版本号的命名,目前业界尚无统一做法。
    产品整体版本编号
           数字顺序型版本编号
                  普通版本编号
                  α和β版本编号
           属性版本编号
    配置管理工具的自动版本编号

    数字顺序型版本编号

    • 普通版本编号
        产品的版本号由若干数字组成,数字之间用“.”分隔。一种典型的编号策略如下:
        x.y.z,x为主版本号,y为特征版本号,z为缺陷修复版本号。
    1. 主版本号的增加表示提供给客户的主要产品功能的增强。
    2. 特征版本号的增加表示产品新增了一些特征或做了一些重要修改。
    3. 缺陷修复版本号的增加表示在软件产品上做了一些缺陷修复工作。
    • 当某一级版本号增加时,其下级版本号要清零。
    • α和β版本编号
    1. 在普通版本编号后面增加一个大写字符A或者B来分别表示α版本或β版本。例如1.2.4A或1.2.4B。
    2. 如果存在多次的α发布和β发布,可在A或B后面添加一个数字来说明发布的次数,例如:1.2.5A1,1.3.0B2。

    属性版本编号

    • 开发团队内部对版本号也有要求。
    • 把版本的重要属性反映在版本标识中。可以包括的属性有:客户名、开发语言、开发状态、硬件平台、生成日期、技术特征、质量状态等。例如:
        J2SDK.v.l.2.2:10/31/2000-18:00,native threads, jit-122
        

    配置管理工具的自动版本编号

    • 为了唯一识别配置库中某个配置项的某个版本,配置管理工具会自动为配置项进行版本编号,其编号规则固化在配置管理工具中。
    • 例如常用的两级制版本编号规则:前一级标志分支,后一级标志同一分支中的特定版本,多个前后级标志串联起来可以表示任何复杂的版本。两级标志之间用“.”或“/”连接,分支的标志可能使用字母,也可能使用数字。

    4.7 项目外资源的版本控制

    • 除项目中所产生的源代码、文档、数据等配置项外,项目所使用的一些外部资源也应纳入版本控制。


    • 把外部资源纳入版本控制并不意味着一定要把它们放入配置库。
    • 以二进制形式存在的软件包一般不适合放进配置库,特别是当它很大的时候。可以保存在共享目录里,加上适当的描述说明和适当的存取权限。
    • 在项目中,要记录清楚使用了哪些外部资源,什么版本。可以用文本文件或表格的形式记录,并放入配置库中。

    第五节 系统集成

    5.1 集成有什么作用?
    5.2 集成的一般步骤
    5.3 集成中的测试和纠错
    5.4 使用集成成果
    5.5 持续集成和持续交付
    5.6 多层集成
    5.7 集成中的构建

    5.1 集成有什么作用?

    • 系统集成(System Integration),简称集成,就是把软件产品的各个组成部分组合在一起,使产品作为一个整体是可以运行的。
    • 集成要对软件进行编译、链接和打包,并要对软件产品进行粗略测试(Rough test),也称冒烟测试(Smoke test),证明其基本可运行,值得送交测试人员进行详细测试。

    软件开发过程分析

    软件开发一般按如下过程:
    (1)开发人员在开始一个开发任务前,用配置库的最新代码更新自己的工作空间,编译链接。
    (2)开发人员分别在自己的工作空间中完成开发任务。
    (3)开发人员在提交前,用配置库中的最新代码更新自己的工作空间,编译、链接和测试(主要测本次任务所做的修改),通过后提交到配置库中。
    (4)为了保证软件质量,测试人员要定期或不定期地从配置库中取出所有最新代码,编译、链接和打包后,进行系统地、全面地测试。测试过程中如果发现bug,提交到缺陷跟踪系统中,进行修复。
    以上开发过程在规模较大,开发人员较多的项目中,很可能出现以下问题。
    (1)测试人员从配置库中取出最新代码后,编译链接不通过,通过后,又几乎不能运行,阻塞测试进程。
    (2)开发人员在用配置库中的最新代码更新自己工作空间后,经常编译链接不通过,阻塞开发进程。

    为什么会出现问题?

    • 开发人员由于疏忽大意等原因,提交的代码有质量问题,或忘记提交一些文件。
    • 即使开发人员的工作完全正确(提交前已更新了工作空间,并通过了测试),仍有可能出现以上问题,因为不同开发人员所做的程序改动,可能是不相容的。

    怎样解决问题?

    • 加入集成工作:定期或不定期地把配置库中的最新代码取出,进行编译、链接、打包和粗略测试,及时发现和解决问题,使配置库中的代码具有一定的质量,并形成基线,供测试和开发人员使用。

    • 开发和测试人员即使不使用基线,也同样能从集成得到好处。

    由谁来集成?

    • 开发人员要适时更新自己的工作空间,使自己开发的模块能够与产品整体协调工作,这实际上也是集成工作。只是其关注点是局部性的。
    • 集成工程师(Integrater/Integration Engineer)也称构建工程师(Buider/Build Engineer)负责全局性的集成,他把各开发人员提交的代码修改汇集在一起,确保产品整体是集成的,并且具有一定的质量。这种集成工作称为狭义集成(Narrow Integration),而更一般意义上的集成称为广义集成(General Integration)。

    5.2 集成的一般步骤

    • Step 1:确保开发人员都提交了相关的源代码。为了更严格地进行控制,可以预先制定一个列表,规定本次要集成哪些工作,在集成开始前检查一遍是不是所有规定的模块都已提交,列表之外的改动有没有被提交。在必要的时候(比如产品即将发布前),每次提交都必须得到授权。
    • Step 2:冻结或者标识将要集成的源代码。必须明确集成了哪些内容,即集成了哪些文件,以及文件的哪些版本。为此需要冻结源代码,在集成前禁止开发人员向版本库提交,或者用打标签的方式把当前的整体版本标志出来。
    • Step 3:取出要集成的源代码。最好存放在一个全新的工作空间,不包含一些杂项,如一些编译的中间文件和结果文件,尚未提交的本地修改等。
    • Step 4:编译、链接和打安装包。这一过程通常称为构建(Build)。如果遇到了问题,需要修改源代码,回到第一步。
    • Step 5:安装并粗略测试。如果发现问题,修改了源代码后,回到第一步。
    • Step 6:标志和储存集成成果。集成成果有两个:一个是源代码的整体版本(基线),一个是生成的安装包。通常还要生成一个“发布说明”,说明本次集成了哪些功能和修改。
    • Step 7:通知相关人员本次集成完成。即发布集成成果。

    5.3 集成中的测试和纠错

    • 集成过程中,编译链接通过后,要做粗略测试,或称冒烟测试。
    • 测试不宜太多太细,否则会降低集成的频率,延缓基线的产生,阻塞后续的开发和测试工作。
    • 粗略测试的目的是排除那些严重的、对后续工作有严重影响的错误。
    • 把所有可能出现的严重问题按照严重程度排序,选择前面的若干问题,作为检测对象。
    • 针对这些问题编写测试用例。
    • 如果能自动执行这些测试用例,则可以显著提高集成的效率,提高集成的测试强度,有利于频繁地集成。
    • 如果在测试中发现了问题,通常采取以下两种方式处理:
    1.  对于容易解决的问题,立即着手解决;
    2. 如果问题比较棘手,需要开发人员仔细研究,那么通常应把引起问题的提交从配置库中剔除,也就是回退合并,使本次集成不再包含该提交。
    • 开发人员在修复问题后,再次提交到配置库,与此同时,配置库中还可能出现了其他开发人员正常的提交,两者混杂在一起,如何处理?
    • 方法一:在集成工程师开始集成之时,先把配置库锁上,除非允许,禁止提交。如果集成过程中发现了问题,由相关人员修复,在取得权限后,把修复提交到配置库。直到集成完成产生基线后,再解锁配置库。该方法较保守,可能会阻碍开发过程。
    • 方法二:在集成工程师开始集成之时,把配置库中要集成的分支(称为“集成分支”)锁上。如果在集成过程中有开发人员要提交,就开辟临时分支,让程序员提交到临时分支上。集成完成后,再把该分支上的内容合并回集成分支。
    • 方法三:集成工程师始终不锁集成分支。当集成遇到问题时,如果集成分支上已经有新的正常提交,就为本次集成开辟出一个临时分支,把为本次集成所做的修复提交到临时分支上,并在临时分支上产生基线,再把基线合并回集成分支。
    • 方法四:集成工程师始终不锁集成分支。当集成遇到问题时,即使集成分支上已经有新的正常提交,也把为本次集成所做的修复提交到集成分支上。当集成工程师再次编译构建时,不仅包括了为本次集成所做的修复,也包括了新的正常提交。本方法最为简便,但有一定的风险。
    • 究竟采用哪种方法,视具体项目情况而定。

    5.4 使用集成成果

    • 测试人员会使用集成生成的安装包进行详尽的测试。
    • 集成所产生的软件源代码整体的一个基线对开发人员是有用的。
    • 开发人员在更新自己的工作空间时,如果每次都是更新到软件最新的代码,则有可能出现编译链接不通过的情况,阻碍自己的开发工作。
    • 解决方法:更新工作空间时,不更新到配置库中的最新内容,而是更新到最近一次集成产生的基线。这种方法称为间接工作流(Non-immediate Workflow)。
    • 而更新到最新内容的方法称为直接工作流(Immediate Workflow)。
    • Subversion默认使用直接工作流,也可以实现间接工作流。ClearCase默认使用间接工作流,也可以设置为直接工作流。

    间接工作流和直接工作流

    间接工作流的缺点

    • 1.如果一个程序员需要拿到其他程序员最新的代码修改才能继续工作,而其他程序员的最新代码修改还没有被集成到基线中,那么只有等待,直到下一次集成完毕后产生新的基线。
    • 2.程序员在提交程序修改时,只能保证自己的修改在上一个基线里没有问题,而不能保证在版本库中最新的软件版本里没有问题。

    解决方法

    • 方法1:做出折衷,如果需要的最新代码不在基线中,就使用直接工作流;在提交修改之前,也使用直接工作流。
    • 方法2:加快集成的频率,快到配置库里的最新代码一旦有问题,几乎可以立即被发现,并被立即解决。从而保证即使是用直接工作流,每次更新得到的也是被集成后有一定质量的基线。

    5.5 持续集成和持续交付

    • 为了尽可能快地发现和纠正配置库里源代码的问题,保证在绝大部分时间里配置库里的源代码是没有问题的,不对开发人员产生负面影响,需要提高集成的频率,例如每天、每半天、每两小时甚至更短的时间间隔,执行一遍集成,这种方法称为持续集成。
    • 提高集成频率也要有个度,因为每次集成要付出一定代价(编译、链接、打包和粗略测试)。当提高集成频率的好处被所付出的代价抵消时,就要考虑是否应该这样做。

    持续集成的自动化

    • 由于集成的频率很高,持续集成通常需要自动化工具的支持,将编译、链接、打包、部署和测试(通过自动化测试脚本)连贯地自动执行下来,并自动报告集成成功或所发现的问题。
    • 自动化的集成不仅可以提高集成的速度,还可以提高集成的准确性和可重复性。
    • CruiseControl是开源的持续集成工具。
    • Build Forge是IBM Rational出品的构建和发布管理系统,能够很好地支持持续集成。
    • 持续集成工具可以在适当时机启动集成过程,例如周期性地(如每两分钟)探测集成分支上有没有新的提交,一旦有新的提交就启动新一轮的集成。
    • 持续集成工具可自动把配置库中的最新(集成分支末端的)代码下载到本地。这通常调用版本控制工具的一行命令就能完成。
    • 自动执行编译、链接、打包操作。这通常调用开发工具的一行或几行命令就能完成。
    • 自动执行粗略测试。这要求预先设置好测试环境,准备好测试数据,并编写自动测试脚本。
    • 最后自动创建基线,收集相关信息,例如本次集成包含了哪些修改等,生成“发布说明”。
    • 以上过程的任意一步如果出现了问题,持续集成工具会立即报告给相关人员(通过邮件、短信等方式)。

    自动化的持续集成

    频繁更新和提交

    • 开发人员频繁地更新工作空间和提交自己的改动,也能尽早发现源代码集成问题。
    • 开发人员使用配置库中的基线或最新代码更新自己的工作空间后,进行编译、链接和检测(属于广义集成),可发现一部分问题。
    • 开发人员频繁地提交改动,也有利于集成工程师尽早发现和排除代码集成问题。
    • 频繁地提交少量改动还有利于减少不同开发人员执行的任务之间的等待。

    • 提高更新和提交的频率也要有个度,因为这些操作需要时间。
    • 要特别注意,不要因为提交逻辑上不完整的改动而对其他开发人员、测试人员和集成工程师造成困扰。
    • 不要对提交做一些僵化的硬性规定。例如:在提交前必须执行完一个较大的、不能自动执行的测试用例集;每天下班前必须提交当天的修改。

    持续交付

    • 当完成了软件的某一版本后,可将软件交付给用户使用,这种交付(delivery)活动往往不是一次性的,而是多次的,甚至是频繁的,即持续交付(continuous delivery)。
    • 持续交付的目的有以下两个:
    1.  尽快发现和解决系统在用户使用环境中出现的问题。
    2.  尽快向用户提供新功能,为用户创造价值,并尽快对市场新动向做出反应。

    5.6 多层集成

    • 典型情景:几个人共同完成一个大的任务,需要紧密配合,频繁交流。此时他们每个人所完成的任务不宜频繁提交到开发团队所有人使用的公共环境里。因此他们有必要组成一个“小圈子”,每个人完成了自己的程序模块后,先提交到小圈子里,在小圈子里集成无误后,再提交到公共环境中,与其它程序再进行集成。
    • 两层或两层以上的集成称为多层集成(Multilevel Integration).

    • 使用多层集成的情况:
    1.  多个人合作完成一个任务,需要互相高度配合,而该任务作为一个整体,与其它任务关联不大,此时应考虑使用多层集成。
    2. 大型项目开发人员众多,源代码也庞大复杂。研发团队分成了若干研发小组,每个小组负责完成一个组件(或一个子系统),此时可以考虑在每个小组内做第一层集成,然后再做小组间的总的集成。

    复合基线

    • 一个系统是由不同的组件组成的,各组件的集成工程师都会通过集成形成本组件的一系列基线。
    • 系统的总体集成工程师取得各个组件的特定基线,通过集成,形成系统整体的一个基线,即复合基线(Composite Baseline)。
    • 复合基线在基于组件的软件开发中有重要作用。

    • ClearCase UCM提供了复合基线功能。Subversion需要手工记录复合基线,或通过编写脚本来实现复合基线功能。

    组件集成的工作方式

    • 方式1:通常情况下,组件的集成是在最近一次系统总体集成创建的复合基线上工作。组件集成工程师取得复合基线中其它组件的基线,与本组件一起集成。
    • 方式2:也有可能,组件集成工程师需要取得其它组件的最新基线,与本组件一起集成。
    • 方式3:在少数情况下,组件集成工程师需要取得其它组件中最新的代码修改,然后与本组件一起集成。
    • 具体使用哪种方式,视具体情况而定。

    组件开发人员的工作方式

    • 方式1:使用配置库中最新的代码更新自己的工作空间,即直接工作流。
    • 方式2:使用配置库中本组件和其它组件的最新基线更新自己的工作空间,属间接工作流。
    • 方式3:使用配置库中的复合基线更新自己的工作空间,也属间接工作流。
    • 使用哪种方式也取决于具体情况。
    • 大型项目中,组件的开发人员通常只修改与自己相关的一个或几个组件,而其它组件对他来说应该是只读的,以防止随意修改。

    工具支持

    • 以上不同工作方式的工具支持:
    • Subversion可让程序员人工进行配置和设置,也可以借助一些脚本来完成。
    • ClearCase引入了UCM项目的概念。一个UCM项目包括了一个或多个组件的开发。一个软件项目可以包括多个UCM项目。通过合理地设置UCM项目,进而适时创建基线和复合基线,能够对基于组件的开发起到不错的支持作用。有时也需要写一些脚本来完成特定功能。

    5.7 集成中的构建

    • 构建(Build)就是从源代码生产出安装包的过程。包括:
    1.  编译
    2. 链接:生成可执行程序
    3. 打包:把所有对用户有用的东西打成一个安装包
    • 构建有时可能不包括打包,比如程序员编译和链接程序后进行测试,此时构建过程就只包括编译和链接。

    保证构建的可重复性

    • 构建可能会遇到的问题:
    1. 产品的某个版本,在源代码没有改变的情况下,这次构建后产品没问题,下次构建出现了Bug。
    2.  产品的某个版本,一个人构建后产品没有问题,另一个人构建后却出现了问题。
    3.  产品的某个版本,现在构建没有问题,一段时间(也许是几年或者更长)后再构建却出现了问题。
    • 构建结果的不可预测会给软件开发和维护带来困扰!
    • 保证构建的可重复性就是指保证每次构建一个具体的产品版本,得到的结果是相同的。
    为了达到这一要求,需要保证:
    • 构建的输入(所有源代码、文档、数据等)是固定和明确的。
    • 构建的工具和环境是固定和明确的。包括特定品牌和版本的编译器、打包工具、操作系统,以及硬件配置。
    • 参数设置是固定和明确的。包括编译、链接和打包的命令参数,工具和环境的配置参数(例如操作系统的环境变量)。
    • 构建过程是固定和明确的。比如Ant文件、相关的脚本;操作的执行顺序等。
    为了做到以上几点,通常有以下策略:
    • 自动化:尽可能将构建过程自动化,减小出差错的可能性。例如使用构建工具来执行脚本。
    • 文档化:详细记录构建过程、构建环境等信息,使任何人都可根据这个记录文档来正确执行构建过程,得到正确结果。
    • 与源代码的版本绑定:将构建工具、配置参数、执行脚本、说明文档等与源代码一起放到配置库中。一旦导出了特定版本的源代码,也就同时导出了对应该版本的所有这些内容。

    加快构建速度

    • 全量构建:完全重新编译源代码,继而链接、打包,不利用上次构建所生成的中间结果。
    • 增量构建:尽可能地利用上次构建的成果,只重新编译那些发生了改变(和受改变影响)的源代码。特点:速度更快,但不如全量构建可靠。
    原则:
    • 在追求构建速度的时候,倾向于使用增量构建,例如程序员自己构建的时候。
    • 在强调构建的可靠性的时候,倾向于使用全量构建,例如集成工程师进行构建的时候。
    其它措施
    • 使构建自动化:使用Ant、Makefile等构建工具,将整个构建过程自动化。
    • 分布式构建:把构建任务分解,分布到多个计算机(或多个CPU)上并行构建。
    ClearCase自带的构建工具Clearmake支持Unix平台上的并行分布构建。

    第六节 分支管理


    分支(Branch)是软件版本演化图中的一条路径,是软件的一个独立演化的版本序列。
    在配置库中,各分支是独立存储的。
    • 在软件版本演化图的众多分支中,有一条是主线(mainline),也称主干(trunk)。所有其它分支都从主线分出,并有可能会合并回主线。

    1.为什么要使用分支?

    • 原因一:需要创建一个不同的版本。


    • 原因二:一组人员需要在一个相对独立的环境中互相配合共同完成一个大的任务。

    • 深层次原因:软件开发进程面临着两个基本问题(一对矛盾),即适当隔离和适当共享。
    • 适当隔离:在工作过程中,各人或各组需独立地工作,不希望被别人意外地干扰,也不希望干扰别人。
    • 适当共享:各人或各组的工作,应该在适当的时候,以适当的方式,共享和集成。
    • 分支同时对隔离和共享提供了支持。
    1.  一条分支被创建后,它的生长是独立的,工作在一条分支上,不会与主线或其它分支相互影响。
    2.  分支的起点是分支的基础,是分支继承的内容;不同分支上的工作成果,可在适当的时候合并。

    2.分支的合并

    • 分支的合并是指把一条分支上的版本的内容,带到另一条分支(例如主线)上。分为两种情况。
    1.  整个分支上的工作成果均合并过去。

        2. 只将分支上的一部分工作成果合并过去

    • 分支的合并是一种复制行为,合并后被合并分支上的各版本不会受任何影响。

    3.分支典型应用一:多层集成

    • 整个项目团队使用主线,“小圈子”是一个分支。在分支上的工作不影响主线。在分支末端进行一次集成,然后合并到主线上。

    4.分支典型应用二:管理交迭

    • 交迭(Overlap)就是指软件不同版本的开发在时间上重叠。
    • 典型情景一:某软件的1.0版本基本成型,等待发布。此时软件的大部分功能都已完成,但还有少量辅助功能没有完成,并可能存在很多缺陷,等待测试和修复。在1.0版的完善和测试期间,大部分程序员处在空闲状态,等待测试人员通知修复缺陷。直到1.0版软件达到质量要求,发布出去,然后再开始2.0版的开发。
    • 解决方法:
            为了使1.0版的完善工作和2.0版的升级开发工作并行,可利用分支。


    • 典型情景二:在做系统集成工作之前,需要冻结代码,防止开发人员在集成工作期间,随意提交新的修改,影响集成工作。如果集成的时间比较长的话,必然会影响软件开发工作的效率。
    • 解决方法:
            为了使集成工作不阻滞开发工作,可使用分支。

    5.分支典型应用三:管理变体

    • 变体(Variant)是同一类软件产品,它们有很多相同之处,却又有所区别。
    • 变体之间虽然相似,但不可能进行合并。
    • 产生变体的最常见原因包括:
    1.  因支持不同的操作系统而产生变体

        例如同一个软件产品在Windows系统上和Unix系统上的不同版本。两种版本所调用的操作系统接口以及开发环境都有很大差别。

         2. 因客户定制而产生变体

        对于同一种软件产品,不同的客户提出的要求有区别,例如财务管理系统,不同客户的财务管理制度、管理流程是有区别的,因此需要特殊定制,从而产生变体。

        3. 因不同的功能集产生变体       

       软件不同的变体是针对不同的消费群体的需要而制作的。例如Windows Vista有七个版本:家庭类的初学者版、家庭基础版、家庭标准版和家庭终极版;商务类的小企业版、专业版和企业版。

    • 用分支支持变体的第一种方法:为每一个变体创建一个分支。

    • 第二种方法:为变体不同的版本创建不同的分支。

    6. 关注主线的演进

    • 不管版本树的分支有多少,都应该有一条主线,作为开发工作的主流,集中精力于主线的演进,其它分支以主线为基础进行开发。
    • 例如,当软件存在多个变体时,不能不分主次地为每一个变体创建一个分支,各自独立开发。

    错误的版本树形状


    正确的版本树形状

    有问题的版本演化策略

    • 该策略存在的问题:
    1.  分支层数太深,可能会超出版本控制工具的分支层数范围。
    2. 文件的版本演化历史信息复杂,分布在不同的分支中。
    3. 开发人员需要经常更换分支,容易出错。

    7. 分支管理要点

    • 分支不能随意创建,必须有所规划,适当管理。
    • 分支管理要注意以下几点:
    1.  分支要有明确的目的。分支应有一个名字,简略说明分支的目的。
    2. 分支要规划好何时创建,从何处创建。
    3.  分支要规划好是否合并?合并到哪里?分支上所有的工作成果都要合并,还是有选择地合并?
    4. 分支要规划相关角色和权限:谁有权读取分支上的内容或向分支提交?分支的合并及分支上的集成工作由谁负责?谁负责创建、删除和重新命名分支?
    5. 分支的规划要全盘考虑,看版本树的整体图景,而不要只关注手边的工作。

    第七节 变更管理

    7.1 影响变更控制方法的因素
    7.2 严格的变更控制流程
    7.3 任务管理

    7.1 影响变更控制方法的因素

    • 对软件原有配置项的改变叫做变更(change)。对变更必须进行有效的管理,避免其产生负面影响。
    • 变更管理(控制)方法主要受以下因素影响:变更的规模、变更的影响面、变更发生的时间、开发过程模型、研发团队的规模。

    1.变更规模对变更控制的影响

    • 有些变更可以较快完成,且规模较小,比如缺陷的修复,对功能进行的少量增强。对于这类比较小的,数量又比较多的变更,可采用缺陷跟踪的方式来跟踪和管理。
    • 有些变更需要不少的人力和时间,对项目的进度和预算都有影响,对这样的大型变更,就需要更严格的控制和企业高层的介入。

    2.变更影响面对变更控制的影响

    • 有些变更只会影响到产品的局部,而有些变更则可能会产生广泛的影响,例如公用函数库的变化。
    • 对于有广泛影响的变更,必须有更为严格的控制,变更前要广泛征求意见,认真评估,变更后要通知大家,发生了什么改变。

    3.变更发生时间对变更控制的影响

    • 越到项目后期,变更的代价就越大,因此对变更的控制就越严格,也越不容易接受变更。
    • 在项目末期,通常只会接受缺陷修复和小的功能增强。

    4.过程模型对变更控制的影响

    • 在瀑布模型中,项目各阶段的工作是顺序执行下来的,前一阶段的工作成果是后一阶段工作的输入,它要求前一阶段的工作成果一旦确定下来后,尽量不发生变化,否则对后续工作的影响太大。
    • 在瀑布模型中,要更严格地控制变更。而在迭代型/适应型过程模型中,可以有更多的变更。
    • 迭代过程模型的核心思想是“尽早反馈”。
    • 迭代过程模型把一个大项目在时间轴上划分为若干个小周期,每个小周期称为一个迭代(Iteration)。几乎每次迭代结束时,都会产生一个可见的成果(可运行的软件包)。用户可对该成果进行评估,提出修改意见。研发团队也可以在短短的一个迭代周期内就发现需求、设计等方面的问题,从而可在下一个迭代中进行变更。
    • 迭代过程模型对待变更的态度更为现实、更为积极,在采用迭代式开发的项目中,变更更为频繁。
    • 通常在一次迭代开始之初,研发团队讨论确定本次迭代要进行哪些变更。但在每次迭代进行过程中,一般不会接受大的变更,因为每次迭代应该有相对确定的任务。

    5.研发团队规模对变更控制的影响

    • 在小型团队里,当变更发生时,人员之间可以采用随意的沟通方式。但在规模较大的团队中,可能需要采取一些正规的方式解决沟通和协作问题,使变更得到控制,例如建立变更控制委员会,将变更请求条目的状态变化自动发送邮件通知相关人员。

    7.2 严格的变更控制过程

    变更请求

    变更评估


    变更审批

    根据评估结果对变更作出决策:
    • 直接实现变更
    • 挂起或延迟变更
    • 拒绝变更

    变更实现


    7.3 任务管理

    • 任务(Task)是由软件项目团队人员所执行的一个活动,它生成或改变配置项。
    • 变更是通过执行任务完成的。

    7.3.1 任务流程的设置
    7.3.2 任务流程中的权限设置
    7.3.3 建立任务间的关系
    7.3.4 自动邮件通知
    7.3.5 任务信息的设置
    7.3.6 任务数据对项目管理的支持

    7.3.1 任务流程的设置

    • 为了控制变更,保证任务结果的质量,任务需要按照一定的流程执行。
    • 优秀的配置管理工具可以对任务流程进行定制,如ClearQuest、JIRA。
    • 任务流程可使用状态模型图或状态转移矩阵表示。

                            典型的缺陷任务(缺陷跟踪)流程的状态模型图

                           典型的缺陷任务(缺陷跟踪)流程的状态转移矩阵

                                                  典型的新任务流程的状态模型图

    7.3.2 任务流程中的权限设置

    • 在任务流程中,不同的人员角色具有不同的职责和权限。
    • 配置管理工具应能够设置在任务的每个状态下可由那些角色执行哪些动作。
    • 任务流程涉及的常见的人员角色包括项目管理人员、开发人员、开发小组长、测试人员、测试小组长、集成人员。
    • 项目管理者包括项目经理及其他变更控制委员会成员,其权限包括创建、取消、分配任务,使任务处于新建、已取消、已分配等状态。
    • 开发小组负责人的权限是在任务处于已分配状态时根据需要对任务进行重分配或取消不必要的任务;在任务处于评审状态时批准或驳回任务已完成的修改;对处于已推迟和正在工作状态中的任务,可根据小组人员安排情况,在组内重新分配。
    • 开发人员的权限是:在任务处于已分配状态时,接受任务,使之处于工作状态;如果认为任务无效(例如缺陷不能重现或与其它缺陷报告重复),可以把任务退回;在任务完成后可提出评审申请。
    • 测试负责人的权限包括:当认为缺陷确实是无效时,可把缺陷取消;对测试人员已验证的缺陷进行审查,如果没有问题可最终关闭缺陷任务,否则可打回测试结果,要求测试人员重新验证。
    • 测试人员的权限包括:对于被退回的缺陷任务,可对缺陷报告进行补充和澄清,再重新分配给开发人员;对开发人员已解决的缺陷进行测试验证,如果通过将缺陷置于已验证状态,如果不通过则驳回该缺陷的修改结果。
    • 集成人员的权限是:如果由开发人员提交的任务结果导致集成失败,可驳回任务结果,由开发人员继续完善;如果集成成功,可将任务标记为“已集成”状态。

    7.3.3 建立任务间的关系

    • 父子关系。将一个复杂的任务分解为多个子任务,由相同或不同的人员去完成。
    • 配置管理工具应该建立父任务和子任务之间的关联性,并可自动在它们之间同步,例如只有当所有子任务都已完成并通过验证,父任务才能通过验证。
    • 依赖关系。任务之间必须按照一定的顺序去执行,一个任务开始或完成后,另一个任务才能开始或完成。
    • 重复关系。重复关系一般出现在缺陷修复任务之间。由不同的人员报告的缺陷实际上是一个问题,为了避免后续开发人员重复分析处理同一个问题,应在这些缺陷任务之间建立重复关系。开发人员只要处理其中一个任务,其它任务就会自动同步地发生状态变化。

    7.3.4 自动邮件通知

    • 当任务的状态发生改变后(例如一个任务被分配给了一个开发人员),相关人员应及时得到通知。自动邮件通知是最常用的一种方式。
    • 在配置管理工具中实现自动邮件通知一般需要以下步骤:
    • (1)设置邮件服务器。
      一般应使用局域网中的邮件服务器。
      需设置邮件服务器的名称、SMTP端口等信息。


    • (2)设置邮件通知方案。
      邮件通知方案规定了当任务流程中一个动作发生时,应向哪些用户发送邮件。
      在配置管理工具中,应该可以新建或修改邮件通知方案。
    • (3)把邮件通知方案赋给项目。一个邮件通知方案可用于多个项目。

                                                         JIRA的邮件通知方案编辑界面

    7.3.5 任务信息设置

    • 正确地设置任务信息不仅有利于变更控制,而且可以为项目管理和过程改进提供丰富的数据。
    • 优秀的配置管理工具(如ClearQuest、JIRA)可以对任务信息进行定制。
    • 任务信息通常包括描述信息、范围信息、人员信息、附加信息等。
    • (1)任务描述信息
    1.  任务标志:任务的唯一标识符;
    2. 任务标题:简单描述任务的单行文本;
    3. 任务详细描述:详细地描述任务的细节,是任务执行者主要的依据;
    4. 优先级:确定任务执行的优先顺序;
    5. 严重程度:通常用于缺陷任务,表示缺陷对系统的影响程度,例如可分四级:1-Fatal, 2-Critical, 3-Major, 4-Minor;
    6. 影响:任务影响的一些活动;
    7. 状态:任务当前在处理流程中所处的状态;
    • (2)范围信息
    1.  产品:标明任务属于哪个产品。
    2. 版本:标明任务属于产品的哪个发行版本;
    3. 模块:标明任务属于产品中的哪个模块;
    4. 功能:主要用于缺陷任务,说明缺陷是由哪个功能引起的。
    •  (3)人员信息
    1.  执行者:任务在当前状态下的执行者;
    2. 报告者:任务的提出者。
    • (4)附加信息
    1.  估计花费时间:估计完成该任务所花费的时间,单位为小时;
    2.  实际花费时间:完成该任务所实际花费的时间,单位为小时;
    3. 缺陷发现方式:如测试、评审、用户使用发现等。
    4.  缺陷引入阶段;
    5.  缺陷原因分析;
    6. 附件:有利于任务执行的一些资料,如错误发生时的屏幕截图、日志文件等。

    7.3.6 任务数据对项目管理的支持

    • 项目是通过执行所有的任务完成的,所以从配置管理系统所记录下的任务信息中,可以提取出丰富的支持项目管理的数据度量,例如:
    • 有关项目进度的度量:
    1.  项目当前完成的功能数和总功能数的比例;
    2. 当前已解决缺陷数和未解决缺陷数的比例;
    3. 每周新发现的缺陷数趋势图;
    4. 未完成的任务趋势图,按周统计。
    • 有关产品质量的度量:
    1.  缺陷模块分布,反映各模块的质量;
    2. 缺陷严重级别分布,反映产品的总体质量;
    • 有关工作效率的度量:
    1.  缺陷发现方法分布,反映测试、评审工作的效率;
    2. 任务在特定状态下停留(老化)的时间分布,反映开发人员的响应速度;
    3. 每周返工的缺陷数,反映缺陷修复的有效性。

    如何获取和展示数据

    • 软件配置工具应该提供便利的机制,为项目人员查找所需的数据,并以表格或图形的方式显示出来。
    • 例如,ClearQuest提供了许多固定的数据查找、统计模板,用户只需要双击相应的模板就能得到所需的数据;用户可以在已有模板的基础上做调整,定义出新的模板;用户还可以从头设计自己的数据查找模板,以实现更复杂的查询、统计和报表功能。
    • JIRA、Bugzilla也有数据统计和报表功能。

    第八节 配置审计和配置状态报告

    • 配置审计的目的是验证配置项的特性是否满足特定标准和规范。属于“过程检查活动”。
    • 通常在软件开发每个阶段结束后,或产品发行之前,都要进行配置审计,它是正式技术复审的一种补充。
    配置库中是否已纳入了所有已标志的配置项?
    配置项的名称和版本标志是否符合规范?
    配置库中的配置项存储位置是否符合规定?
    是否在配置项中显著标明了每次所作的修改?
    配置项的变更是否符合变更控制流程?
    是否定期备份了配置库?
    ……
    • 不要把配置审计误解为“对配置库中的每个配置项都检查一遍”。不要在配置审计上花太多的时间。
    • 配置审计的对象是项目的主要配置项,如果主要配置项符合规范,就可以认为配置管理符合既定的规范。反之,如果质量人员在审计的时候发现主要配置项比较混乱,那么应当告知当事人及时更正。
    • 配置状态报告
        记录和报告配置项变更处理过程的相关信息。这些信息包括一个已批准的配置识别清单,变更请求当前的
    处理状态,以及批准的变更的实现情况。
        对于大型项目的开发,配置状态报告非常重要,它促进了人员之间的通信,有利于人员之间协调一致地工
    作。
    • 配置状态报告所记录的数据,有时需要经过统计分析而得到综合数据,例如每月或每周产生的变更请求数、处理的缺陷数,当前未处理的缺陷数,当前处在某一状态的变更数,等等。统计分析结果可以用分布图、趋势图等形式直观地显示出来。这些综合数据对软件项目管理有着重要意义。

    第九节 配置管理过程


    1.制订计划

            制订计划,需要考虑到产品开发过程中,软件配置管理的方方面面:
    • 配置项的识别和标记:源代码、安装包、文档。
    • 配置管理工具。
    • 变更管理规则:变更请求、并行修改、版本间差异等等。
    • 配置管理的角色和职责如何划分?人员是否需要培训?
    • 配置审计计划和配置库备份计划。
    • 作为计划的成果,常常是一份软件配置管理计划(SCM Plan)文档。
    • 制订软件配置管理计划,一般由软件配置管理工程师主导,由项目经理审批。
    • 软件配置管理计划模版

    2. 做好准备

    需要在工具、过程、人员三个方面做好准备。
    • 工具:如果在组织级已经提供了适用的软件配置管理工具,则只需简单地为这个项目做初始化工作,比如创建项目、创建目录、往版本控制工具中导入初始版本、设置合适的参数,等等。如果组织级并未提供合适的工具,则需要考虑工具的选择、购买、安装、设置等。
    • 过程:如果在组织级已经确立了通用的软件配置管理过程,则应该考虑拿来使用,也可能根据项目的实际情况,进行适当的裁剪和定制。如果组织没有确立或完全确立通用的软件配置管理过程,则可能需要为项目特别制定软件配置管理过程。
    • 人员:首先要保证各个软件配置管理相关岗位,已经有合适的人选,特别是软件配置管理工程师和集成工程师。其次要保证各个角色已经有足够的能力,来完成软件配置管理方面的工作,如果欠缺经验和能力,应该考虑进行相关培训。

    3.日常工作

    • 项目组的所有人员在产品开发过程中都会参与配置管理的日常工作,如源代码和文档的版本控制、系统集成、变更管理等。
    • 软件配置管理工程师主要负责保证软件配置管理系统的正常运行。例如配置管理工具的维护工作和手动备份工作,人员权限的管理,帮助使用者解决工具和流程方面的疑难问题等。

    4.监控、调整与改进

    • 监控的目的在于及时发现软件配置管理中的问题并纠正。
    • 随着项目的进展,项目的软件配置管理策略、方法可能需要调整;随着对软件配置管理认识的不断提高和经验的积累,会对软件配置管理的流程和工具进行调整和改进。
    • 软件配置管理的监控、调整与改进工作可能由软件配置管理工程师主导,也可能由质量保证人员主导,另外过程改进人员也常常参与。

    5.收尾

    • 在产品发布,项目收尾阶段,软件配置管理同样需要进行收尾。主要包括两个方面:软件资产的整理和归档、软件配置管理本身的总结和共享工作。
    • 在项目收尾时,软件资产的整理归档进入关键时刻,这个时候保存的软件资产是业已成型的软件资产,是最有价值的资产。
    • 软件资产的整理和归档,包括对源代码、安装包、文档的妥善保存;包括对各个历史版本,特别是发布产品对应的历史版本的妥善保存。同样重要的还有对开发环境的整理和归档,对变更请求等相关数据,也应该进行整理和归档,保证将来仍可查询。
    • 软件配置管理本身,也是一种资产,称作过程资产。在项目即将结束时,应对整个项目过程中的软件配置管理工作进行总结,得到的经验教训,供以后其它项目参考。
    • 在整个项目过程中,可能对软件配置管理流程或工具进行了调整和改进,要考虑是否有可能将这些调整与改进加入到组织一级的软件配置管理中,供以后其它项目使用。

    第十节 软件配置管理工具

    软件配置管理工具
    CVS概述

    CVS常用操作

    1. 软件配置管理工具

    • 软件配置管理工具的主要功能

    版本控制
    变更管理
    配置审核
    状态统计(查询和报告)
    问题跟踪(跟踪缺陷和变更)
    访问控制和安全控制

    • 常用的配置管理工具

    ClearCase & ClearQuest
    CVS
    Subversion(SVN)
    PVCS
    Harvest
    Visual SourceSafe(VSS)

    2. CVS概述

    • CVS (Concurrent Versions System, 并发版本系统)是一个被广泛应用的配置管理工具。

        UNIX和Linux的发行版一般都带有CVS服务器,Eclipse内建有CVS客户端。
        CVS是自由软件,可免费获取其安装包和源代码。

    •  CVS提供了多种途径帮助开发团队成员之间的版本同步和开发通信,辅助解决版本冲突,提高协同开发的效率。

    CVS的几个特性

    • C/S模式



    • 基于“修改—合并”的并发控制

    客户端check out后,有文件的一份独立拷贝。
    开发者在自己的工作目录中修改文件。
    若有版本冲突,则与其它开发者的修改合并,然后提交(check in)。

    • 记录不同版本之间的差别

    CVS安装包的获取

    • CVS支持Unix、Linux、Windows、Mac平台。

        可从http://www.march-hare.com下载其安装包和源代码。

    • CVS在Windows上的版本称为CVSNT。
    • tortoiseCVS —Windows上的一个常用的CVS客户端。自由软件,官方网站:http://www.tortoisecvs.org/。

    3. CVS常用操作

    创建仓库(repository)
    导入项目/模块
    检出项目/模块
    修改并提交(检入)文件
    更新文件
    取回文件的某个历史版本
    文件比较

    案例分析

    “软件缺陷管理和度量系统”项目的配置管理计划

    本章小结

    理解软件配置管理的作用和有关软件配置管理的相关概念(配置项、基线、SCCB)。
    了解建立软件配置管理环境的方法。
    理解配置库的检入检出机制和防止版本覆盖的方法。
    理解适时更新工作空间、记录源代码整体版本、保存安装包的必要性和方法。
    掌握软件版本编号的常用方法。
    理解系统集成的含义,了解其一般步骤。
    理解持续集成、分层集成的含义。
    理解构建的含义和保证构建可重复性的方法。了解加快构建速度的方法。
    理解分支管理的相关概念、作用、方法和典型应用。
    了解影响变更管理的因素。
    理解严格的变更控制过程。
    了解配置审计和配置状态报告的作用。
    了解配置管理过程
    了解软件版本控制工具的常用操作功能。

    参考文献

    董越. 未雨绸缪—理解软件配置管理. 电子工业出版社,2008.5
        该书以通俗易懂的语言讲述了软件配置管理的基本原理,内容较为实用。
    董越. 软件集成策略—如何有效率地提升质量.电子工业出版社,2013.7
        该书系统地讲述了软件系统集成的原理。



























































        


            


























































































    展开全文
  • 软件配置管理

    千次阅读 2019-06-20 12:49:20
    第一章 1,软件配置管理用于控制变化 ...3,软件配置管理是一种标识、组织和控制修改的技术,软件配置管理应用于整个软件工程过程 4,SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现...

    第一章

    1,软件配置管理用于控制变化

    2,软件配置管理(Software Configuration Management, SCM)是指一套管理软件开发和维护过程中所产生的各种中间软件产品的方法和规则,它是控制软件系统演变的学科。

    3,软件配置管理是一种标识、组织和控制修改的技术,软件配置管理应用于整个软件工程过程

    4,SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更

    5,从某种角度讲,SCM的目的是使错误降为最小并最有效地提高生产效率。

    6,软件配置管理定义:

    软件配置管理是贯穿于整个软件过程中的保护性活动,它被设计用来:

    (1) 标识变化;(2) 控制变化;(3) 保证变化被适当的发现;(4) 向其他可能有兴趣的人员报告变化

    7,配置管理是否有成效取决于三个要素:人、规范、工具。

    8,软件配置是一个软件产品在生存期各个阶段的不同形式(记录特定信息的不同媒体)和不同版本的程序、文档及相关数据的集合,或者说是配置项的集合

    9,软件配置是一个集合,该集合中的每一个元素称为该软件产品软件配置中的一个配置项(Software Configuration Item,SCI)。

    10,常见的软件配置项:需求规格说明书、设计规格说明书、源代码、测试计划、测试用例、用户手册等

    11,基线(Baseline)是指一个(或一组)配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。基线是软件生命周期中各开发阶段的一个特定点,它的作用是把开发各阶段工作的划分更加明确化,使本来连续的工作在这些点上断开,以便于检查与肯定阶段成果

    12,基线是已经正式通过复审和批准的某规约和产品,它因此可作为进一步开发的基础,并且只能通过正式的变化控制过程来改变。基线通常标志开发过程一个阶段的结束(里程碑)。

    13,里程碑(Milestone)是检查点 (Check Point),检查点不一定是里程碑,因为检查点还可以是时间、计划和事件

    14,功能基线:所规定的对待开发软件系统的规格说明

    15,指派基线:又称为分配基线,指在软件需求分析阶段结束时,经过正式评审和批准的软件需求的规格说明,指派基线是最初批准的指派配置标识。

    16,产品基线:指在软件组装与系统测试阶段结束时,经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明,产品基线是最初批准的产品配置标识

     

    17,软件配置控制委员会(Software Configuration Control Board, SCCB)负责管理软件配置项变更的组织。

    具体责任如下:

    评估变更;批准变更请求;在生命周期内规范变更申请流程;对变更进行反馈;与项目管理层沟通

    18,软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。它的基本目标包括:

    • 目标 1: 软件配置管理的各项工作是有计划进行的。
    • 目标 2: 被选择的项目产品得到识别,控制并且可以被相关人员获取。
    • 目标 3: 已识别出的项目产品的更改得到控制。
    • 目标 4: 使相关组别和个人及时了解软件基准的状态和内容。

    第二章

    1,软件配置管理角色

    PM: 项目经理;CCB: 配置控制委员会;CMO: 配置管理员;SIO: 系统集成员;DEV: 开发人员

    2,项目经理(Project Manager,PM)

    根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。

    职责:制定和修改项目的组织结构和配置管理策略;批准、发布配置管理计划;

    决定项目起始基线和开发里程碑;接受并审阅配置控制委员会的报告。

    配置控制委员会(Configuration Control Board,CCB)

    负责指导和控制配置管理的各项具体活动的进行,为项目经理的决策提供建议。

    职责:定制开发子系统;定制访问控制;制定常用策略;建立、更改基线的设置,审核变更申请;根据配置管理员的报告决定相应的对策。

    配置管理员(Configuration Management Officer,CMO)

    根据配置管理计划执行各项管理任务,定期向CCB提交报告并列席CCB的例会。

    职责:软件配置管理工具的日常管理与维护;提交配置管理计划;各配置项的管理与维护;执行版本控制和变更控制方案;完成配置审计并提交报告;对开发人员进行相关的培训;识别软件开发过程中存在的问题并拟定解决方案。

    系统集成员(System Integration Officer,SIO)

    系统集成员负责生成和管理项目的内部和外部发布版本。

    职责:集成修改;构建系统;完成对版本的日常维护;建立外部发布版本。

    开发人员(Developer,DEV)

    开发人员的职责就是根据组织内确定的软件配置管理计划和相关规定,按照软件配置管理工具的使用模型来完成开发任务。

    34,软件配置管理过程包括7项基本活动:

    (1) 制定配置管理计划;(2) 识别和标志配置项;(3) 搭建配置管理环境;(4) 配置项的版本控制;(5) 基线变更管理;(6) 配置审核;(7) 配置状态统计

    5,制定配置管理计划

     

    • 配置管理计划的主要内容:

    配置管理组织及其职责;配置管理工具和配置库的组织结构;配置项标志和基线定义;

    变更管理流程;配置审核和配置状态统计

     

    6,识别和标志配置项:

    (1)为每一个配置项分配唯一的标志;建立配置项间的对应关系

    (2)两类配置项:

    • 基本配置项:软件开发者在项目开发过程中所创建的基本工作单元。
    • 集成配置项:一个集成配置项是基本配置项或其它集成配置项的集合。

    7,搭建配置管理环境

    配置管理环境是用于进行软件配置管理的系统环境,其中最重要的是配置管理库,简称配置库

    配置库存储配置项 (SCI)、修改请求、变化记录等,并提供对库中所存储文件的版本控制

    一般需采用配置管理工具来建立配置库。

     

    8,配置项的版本控制

    • 配置库的检入检出和版本控制机制解决了软件开发中的两个重要问题
      • 访问控制:保证具有相应权限的人员才能修改配置项。
      • 并行控制:保证不同人员同时对某配置项进行的修改不会互相覆盖。
    • 对配置项的修改(不同版本间的差别)应被记录下来。

      更动者(姓名及其身份);更动日期和时间;被更动SCI(名及其版本号);

      更动内容及其位置;更动原因;受此更动影响的诸SCI名表。

    • 软件产品版本编号方法
      • 数字顺序型版本编号

      普通版本编号

      • x.y.z,x为主版本号,y为特征版本号,z为缺陷修复版本号,如V3.10.16。
      • 主版本号的增加表示提供给客户的主要产品功能的增强。
      • 特征版本号的增加表示产品新增了一些特征或做了一些重要修改。
      • 缺陷修复版本号的增加表示在软件产品上做了一些缺陷修复工作。

      α和β版本编号

      • 在普通版本编号后面增加一个大写字符A或者B来分别表示α版本或β版本。例如1.2.4A或1.2.4B。
      • 如果存在多次的α发布和β发布,可在A或B后面添加一个数字来说明发布的次数,例如:1.2.5A1,1.3.0B2。

      α测试是由公司内部的用户在模拟实际操作环境下进行的测试。

      β测试是由软件的多个用户在实际使用环境下进行的测试。

      • 属性版本编号

        把版本的重要属性反映在标识中。可以包括的属性有:客户名、开发语言、开发状态、硬件平台、生成日期等。例如: J2SDK.v.l.2.2:10/31/2000-18:00,native threads, jit-122

        • 包含的信息丰富,方便了查询和管理,版本间的关系易于保持,但由于太复杂,一般只用于软件组织内部的管理

       

    9,基线变更管理

     

     

    • 变更批准或拒绝

    根据评估结果对变更作出决策:

    直接实现变更;挂起或延迟变更;拒绝变更

    对于批准的变更,要确定其实现进度:

    立即实现变更;在特定的日期实现变更;在软件另外的版本中实现

    • 变更实现

    10,配置审核

    配置管理活动审核:确保所有配置管理活动符合已批准的软件配置管理规程

    基线审核:审核基线配置项的完整性和一致性,从而保证基线配置项可被正确地构造。

    11,配置状态统计和报告

    变更请求的数量。变更管理活动的执行情况。

    配置管理系统存储量的变化。配置管理系统和SCCB在运作中发生异常的次数

    第三章

    1,CMM/CMMI将软件配置管理的活动分为6个方面,每个方面又再进行了细分

    SCM过程管理;软件配置标识;软件配置控制;软件配置状态统计;软件配置审计;软件发布管理和交付

    2,在CMM和CMMI中,将配置管理的目的定义为"建立和维护产品的完整性",

    3,配置完整性(对标准的理解)

    • 产品完整性:项目提交的工作成果是"产品集合完整、子产品正确"的
    • 产品集合完整:产品包含的子产品(配置项)是完整的
    • 子产品正确:子产品(配置项)达到了需求要求,满足标准、规程的要求

    4,三库管理:三库的概念源自CMM/CMMI,即开发库、受控库和产品库。配置项在三库之间迁移,一级比一级的控制更严格。

    5,软件开发组日常的工作在开发库中开展,当工作达到里程碑时,再迁移到受控库,在受控库中经过更严格的测试后,再上升到产品库,最后发布。

    6,在实践中,三库常常被实现为物理上的三库,而不是通过逻辑的方式来实现,三库物理隔离带来的最大问题是配置项失去了历史可追溯性

    7,实现三库的指导思想应该是逻辑上独立,物理上在一起,通过权限与流程的控制来实现配置项在不同库之间的流转,以及相应角色的人员对相应库的访问。

    1. CMM2在配置管理方面主要针对于实现部分;CMM3将配置管理扩展到需求、规格说明、设计和工具
    2. SCM意义

    记录软件产品的演化过程;

    确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置;

    最终保证软件产品的完整性、一致性、追朔性、可控性;。

    10,每个基线都将接受配置管理的严格控制,对其的修改将严格按照变更控制要求的过程进行,在一个软件开发阶段结束时,上一个基线加上增加和修改的基线内容形成下一个基线,这就是"基线管理"的过程

    11,建立基线的好处:重现性;可追踪性;版本隔离。

    基线管理的步骤:

    (1) 在开发前确定基线的"配置";(2) 基线批准前,根据"配置"检查配置项是否齐备;

    (3) 对各个配置项,确认其版本的正确性;(4) 对每个配置项建立基线标志;

    (5) 基线变更管理;(6) 基线的各类报告和审计信息。

    12,变更管理的流程:

    (获得)提出变更请求;由CCB审核并决定是否批准;

    为(被接受)修改请求分配人员,提取SCI,进行修改;

    提交修改后的SCI,并测试(或者评审);重建软件的适当版本;

    复审(审计)所有SCI的变化;发布新版本。

    ---可以通过两种表格来帮助发现受到变更影响的内容,一种是《需求跟踪表》,一种是《配置项依赖关系表》

     

    13,配置库管理

    (1)设置配置库(即文件夹设置)和设置版本的分支

    (2)为每个配置项从建立开始就划分成3个不同的分支:私有分支、集成分支、公共(主干)分支

    私有分支(开发人员的私有开发空间):开发人员

    集成分支(开发团队的公共空间):由系统集成员及相关指定人员负责:所有涉及多人协调的开发工作(如集成测试等)都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限,而其他成员只有只读权限。

    公共(主干)分支(整个软件开发组织的公共空间):系统集成员:各个开发小组在现阶段的任务完成后,将可以发布的版本归并到该分支上,对组织内的全体软件人员开放只读权限

     

    上面定义的3类工作空间(分支)由配置管理员统一管理

     

    (3)按配置项类型分类建库和按任务建库。

    (4)配置库的日常工作:对配置库的定期备份;清除无用的文件和版本;检测并改进配置库的性能等

     

    14,配置审计:主要作用是作为变更控制的补充手段,来确保某一变更需求已被切实实现

    记录了谁修改了这个工件,什么时候做的修改,为什么原因做出这个改动,以及修改了哪些地方。 (Who、When、Why、What)

    • 同时配置审计工作该应当说明如下信息:

    (1) 变更要求被完成,并且对附加的修改已经执行了 (2) 采用了正确的正式验证手段

    (3) 遵循了标准的要求 (4) 变更的4W信息被完整记录,并和相关配置项关联

    • 配置审计有两种:
    • PCA (Physics Configuration Audit)-----非配置管理人员

    主要是检查版本是否正确一致。(1) 配置项是否齐备;(2) 版本是否齐全,由非配置管理人员来进行。

    • FCA (Function Configuration Audit) -----CMO

    检查配置项是否完整,各种过程文档是否齐备、正确、与需求是否一致,归结为两点,即完全和齐备。

    15,配置审计

    • When:软件交付或release时;每个阶段结束时;对于维护性项目,周期性地进行
    • Who:非本项目组成员;其他项目中的配置控制者;内部审计者;SCM小组
    • 配置审计步骤(How-审计流程)
    • (1) 由项目经理决定何时进行配置审计工作(识别配置审计的时间[PM])
    • (2) 质量保证组或项目组的配置管理组制定该项目的配置审计人员(指派审计者[QA/Audit Group])
    • (3) 项目经理和配置审计员决定审计范围(定义审计范围[PM&Auditors])
    • (4) 配置审计员准备配置审计检查单(准备配置审计Checklist[Auditor])
    • (5) 配置审计员安排时间审计文档和记录,审计活动可能涉及到:项目范围,配置项的入库(check in)及出库(check out),评审记录,配置项的变更历史,测试记录,文件的命名,变更请求和版本的编号等

    (通过评审(Review)、文档记录进行审计[Auditor])

    • (6) 配置审计员在审计中发现不一致现象,并作记录(识别不符合项[Auditor])
    • (7) 由项目经理负责消除不一致现象(关闭不符合项[PM])
    • (8) 配置审计员验证所有发现的不一致现象确已得到解决(验证[Auditor])

     

    16,配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情况

    应该是定期进行,并尽量通过CASE工具自动生成,用数据库中的客观数据来真实的反映各配置项的情况。

    应着重反映当前基线配置项的状态,以作为对开发进度报告的参照

     

    17,软件配置管理最佳实践:

    统一标识配置项并存入安全的配置管理系统;控制和审计配置项的变更;合理组织配置项;

    在项目的里程碑建立相应的基线;记录和跟踪变更请求;过程驱动的软件配置管理;

    维护稳定而一致的工作空间;支持并行开发;尽早和持续集成;

    确保有能力重现软件的构建过程;把握好工具、流程和人员三者之间的关系;善用模式和反模式;

    18,模式可以指导我们如何成功应用前人的实践,避免犯前人犯过的错误,提高SCM的实施成功率。

    反模式是指那些在特定情况下不应该采取的策略和方式。

     

    第4章

    1,软件配置管理计划: 人员及职责;配置管理软硬件资源;配置项计划;基线计划;配置库备份计划

    2,配置库管理报告: 基本信息;项目成员的操作权限;配置项记录;基线记录;配置库备份记录;配置项交付记录;配置库重要操作日志

    3,配置项变更控制报告: 变更申请;审批变更申请;变更配置项;结束变更

    4,配置状态报告 (Configuration Status Report)目的:有效记录和报告管理配置所需要的信息,及时、准确地给出软件配置项的当前状态,供相关人员了解,以加强配置管理工作

    • 内容
      • 各份变更请示概要:变更请求号、日期、申请人、状态、估计工作量、实际工作量、发行版本、变更结束日期
      • 基线库状态:库标识、至某日预计库内配置项数、实际配置项数
      • 发行信息:发行版本、计划发行时间、实际发行日期、说明
      • 备份信息:备份日期、介质、备份存放位置
      • 配置管理工具状态
      • 配置管理培训状态

    5,配置审计目的:验证配置项信息与配置标识(需求、标准、流程…)的一致性,4"W"

    配置审计报告内容:配置项状态统计;基线库基线统计;变更统计;审计中发现的主要问题

    第5章

    1,配置管理模式分类: 描述工作区结构的模式 描述码线结构的模式

    2,码线(codeline)--源代码文件与组成某个软件组件的其他人工制品(配置项)随着时间而变更的进展过程。

    码线包含沿着一条路径发展的各个配置项的每个版本

    3,与码线有关的模式:主线活动开发线; 码线策略; 私用版本; 版本线; 版本预备线; 任务分支4,与工作区有关的模式: 私有工作区;储存库; 私有系统构造; 集成构造; 第三方码线;任务级提; 冒烟测试; 单元测试; 回归测试

    1. 主线——问题: 如何使当前活动码线的数目保持在容易管理的水平,避免项目的版本树长得太宽太密?如何使合并的开销减至最小?

      解决方案:简化分支模型:开发单个产品版本时,在主线上进行开发。分支时,先考虑总体战略,然后再创建分支

    6,分支是组织文件版本和显示版本历史的手段,是隔离变更的强有力机制。

    7,主线既要使码线的并发性达到最大,又要使推迟集成可能造成的问题减至最小

    8,私有工作区——问题: 如何跟上不断变化的码线并取得进展,而不会为环境变化而分心?

    • 解决方案:以隔离工作的方法控制变更 (Isolate your work to change control)
    1. 储存库——问题:如何获得填充新工作区的正确组件的正确版本11,
    2. 冒烟测试(Smoke Test)如何知道系统在你变更后仍能工作?

    描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程;

    是确定和修复软件缺陷的最经济有效的方法;缺点在于覆盖面很有限。执行者是开发人员或版本编译人员

    12,每次构造都必须进行冒烟测试,以显而易见的方式验证应用未被损坏。

    13,单元测试((Unit Test)):如何测试模块经你变更后是否仍能像预期一样工作

    14,回归测试((Regression Test)):如何确保现有的代码没有因你进行其他改进而变得更糟?

    15,每日构建 (Daily Build)

    就是把一个软件项目的所有的最新的代码从配置库中取出,然后从头进行编译、链接和运行。通常由工具自动完成(构建自动化)。

    daily build 的另一个重要功能就是验证软件中各模块关系是否正确,也可称为"每日集成"。

     

    第9章

    1,版本库(Repository):按照一定格式存储了所有数据,包括文件和目录

    经过授权的客户端可以连接到版本库,读写库中的文件

    版本库和普通文件服务器的不同:版本库会记录每一次的更改

    2,版本控制系统的核心任务:协作编辑和数据共享

    3,拷贝-合并模型假定文件是可以通过上下文合并的。通常情况下,文本文件(例如源代码以及用纯文本,HTML,TXT等格式保存的文档)因为其内部结构直观可知,容易理解上下文,所以用拷贝-合并方案较好。而二进制文件(例如用Microsoft Word格式说,PDF等格式保存的文档及图片,声音,可执行文件,库等)内部结构复杂,且不容易理解更改处的上下文,采用锁定-解锁方案较好

    4,Subversion主要采用拷贝-修改-合并模型,配合锁定-修改-解锁模型管理数据的共享

    5,工作拷贝(Working Copy)是本地机器的一个普通的目录,是私有工作区

    6,修订版本(Revision):每当一次提交完成后,版本库的文件系统就进入了一个新的状态,叫做一次修订(Revision)。在版本库中,最新的一个修订版本称为HEAD

    7,CheckOut:从版本库中取出某个目录的拷贝到本机上某个目录的操作

    例:svn co svn://192.168.0.1/svnrepos/skizcorp/trunk

    -r 1452 会检出1452版,如果存在的话;-N:不递归(仅针对顶层目录),否则目录递归(默认,常用)

    8,Update:把版本库的修改同步到本地

    • 例1:up    直接把工作拷贝更新到最新版(HEAD版)
    • 例2:up -r 2007    更新到2007版
    • 例3:up doc/design    只更新doc/design下的文件

    9,BASE版:某个文件的BASE版本是指存放在管理目录.svn中的该文件拷贝的版本,Revert会使该文件回到BASE版本

    10,Revert,是指放弃对某个文件的修改------revert abc.c 丢弃对abc.c的所有修改

    11,当文件发生冲突时,SVN会额外创建3个不受版本控制的文件

    12,add:把一个文件加入SVN版本控制系统;delete:从版本控制系统中移除;

    move(rename):移动或者重命名;mkdir:创建目录;copy:拷贝;commit:提交;

    status:检查工作拷贝的状态;diff:检查更改的内容

    13,分支(Branch)是开发的一条"支线"。它独立于其他开发的线路,并且和其他线路并行开发

    • 所有的分支都有共同的历史,有着原先共同的主线(Trunk)

    14,创建分支使用copy命令:copy 源目录 目标目录

    • 例:先把目录checkout到本地,在本地执行copy命令后提交至版本库

    svn co svn://localhost/
    svn copy trunk/ branches/mybranch
    svn commit –m "My branch created"

    • svn copy svn://localhost/trunk svn://localhost/branches/mybranch –m "My branch"

    15,Switch操作可以使工作拷贝在不同的分支之间或者在位于不同服务器上相同的版本库的分支间切换。它的作用是改变工作拷贝对应的URL:switch [--relocate] 目标URL

    16,分支的合并是指把修改从分支拷贝到主干或者把主干的修改拷贝到分支的过程。

    • 传统方法:diff + patch(只适用于文件内容)
      • 例子:取出主干2000版到2007版的修改,然后把它应用到工作拷贝

        svn diff –r 2000:2007 svn://localhost/trunk > patchfile
         patch –p0 < patchfile

    • merge 初始版本树 最终版本树 目标(能够处理目录树的修改,而不限于单个文件内容)

    例子

    • merge svn://localhost/trunk@2000 svn://localhost/trunk@2007 my_wc
    • merge –r 2000:2007 svn://localhost/trunk my_wc

    17,tag:通常tag对应于milestone,是一个完整可用的版本,不能修改,是只读的

    branch:是trunk或tag的分支,可以修改,是可写的,用于做并行开发

     

    18,常用的SVN命令:

    命令名称

    功能

    svn add 

    往版本库中添加新的文件

    svn checkout 

    将文件checkout到本地目录

    svn cleanup 

    递归清理工作拷贝

    svn commit 

    将改动的文件提交到版本库

    svn copy 

    拷贝文件

    svn delete 

    删除文件

    svn diff 

    比较差异

    svn export 

    导出目录树

    svn import 

    导入目录树

    svn info 

    打印作者、时间戳、日志信息大小和日志信息

    svn list 

    版本库下的文件和目录列表

    svn lock 

    文件加锁

    svn log 

    查看日志

    svn merge 

    将两个版本之间的差异合并到当前文件

    svn mkdir 

    创建纳入版本控制下的新目录

    svn move 

    移动一个文件或目录

    svn resolved 

    移除工作副本的目录或文件的"冲突"状态

    svn revert 

    恢复本地修改

    svn status 

    查看文件或者目录状态

    svn switch 

    代码库URL变更

    svn unlock 

    文件解锁

    svn update

    更新到某个版本

     

     

    第8章

    1,两种版本控制模型

    • Lock-Modify-Unlock Model (加锁-修改-解锁):CVS,SVN,VSS2005
    • Copy-Modify-Merge Model (拷贝-修改-合并):VSS6.0,PCVS

    2,基于"拷贝—修改—合并"的并发控制

    • 客户端check out后,有文件的一份独立拷贝。
    • 开发者在自己的工作目录中修改文件。
    • 若有版本冲突,则使用合并(merge)功能与其它开发者的修改合并,然后提交(check in)。

     

    第6章

    1,常用的配置管理工具:Visual SourceSafe(VSS); CVS; Subversion(SVN); Borland StarTeam; IBM Rational ClearCase & ClearQuest; Hansky Firefly

    ClearCase,Firefly支持异地开发,与开发工具的集成非常好,价格昂贵

    VSS仅支持windows,其他支持常见平台,与vs无缝集成,与其他开发工具集成性差

    2,软件配置管理工具的主要功能:

    版本控制;变更管理;配置审核(配置审计)

    配置状态统计(查询和报告);问题跟踪(跟踪缺陷和变更);访问控制和安全控制

    3,ClearCase主要应用于复杂产品的并行开发、发布和维护,其功能划分为四个范畴:版本控制(Version Control)、工作空间管理(Workspace Management)、构造管理(Build Management)、过程控制(Process Control)。

    4,ClearCase把所有版本控制的数据存放在一个永久、安全的存储区中,这个存储区被称为版本对象类(Version Object Bases)

    A VIEW selects versions of elements

    What is seen is the result of an ordered set of rules called a configuration specification (config spec).

    Selected versions appear in a standard directory tree with recognizable file names.

    View分为SnapShot View和Dynamic View,Snapshot view是ClearCase在服务器上存储的文件和目录的一个本地镜像,Dynamic View是动态试图,它并不在本地存储任何文件,始终和服务器保持一致。

    1. 软件配置管理工具选择:功能;是否符合团队特点?性能;费用是;售后服务;易用性

     

     

     

    序号

    活动名称

    角色

    活动描述

    参考

    1 

    • 计划配置管理

    配置管理经理

    CCB

    • 制定配置管理策略
    • 制定变更控制策略
    • 编写配置管理计划
    • 评审配置管理计划

     

    《配置管理计划》模板

     

    2 

    • 创建配置管理环境

    配置管理经理

    • 设置硬件环境
    • 设置网络环境
    • 设置软件环境

      建立一个配置管理库,储存项目中定义的配置项;安装配置管理工具,例如: VSS等。

    • 提供配置管理培训

     

    VSS使用手册》

    《组织管理配置库使用指南》

    3 

    • 配置项的标识

    配置管理经理

    • 对文档类的配置项进行的标识,参见附录B
    • 对程序(coding、模型)的配置项进行标识

    《软件开发文档命名约定》

    4 

    • 建立基线

    配置管理经理

    集成员

    • 标识基线:根据配置管理计划,对经过测试或者评审通过的工件进行标识。
    • 审批基线:CCB负责召开会议,评审配置管理经理建立的基线。
    • 发布基线:将建立的基线向相关人员发布。

    《配置管理计划模板》

     

    《基线策略指南》

    5 

    • 报告配置状态

    配置管理经理

    根据配置管理计划,收集配置活动数据, 编写配置状态报告。

     

    《配置状态报告》模板

    6 

    • 执行配置审计

    配置管理经理

    • 根据配置管理计划定期地执行配置审计,它包括:
      物理审计
      功能审计
    • 编写配置审计报告

     

    《配置审计报告》模板

    7 

    • 变更控制管理

    CCB

    任意角色

    • 参见《变更控制规范》

    《文档变更请求》

     

     

     

     
     
     
    展开全文
  • 微服务配置管理

    2019-04-30 11:27:45
    微服务配置管理 !!!!!!!!!!!!!!!!!! 1、不同的微服务是由不同的团队,不同的组织去负责开发和维护的,每个微服务采用不同的技术栈,而且配置文件名、配置文件放置的目录可能是五花八门,所以配置...
  • 软件生命周期和配置管理

    千次阅读 2018-06-09 21:13:47
    一、软件开发生命周期(SDLC)1、...软件管理的复杂性 3、软件的质量现有的模型:瀑布模型、v模型、增量模型、原型法、螺旋模型三、不同模型的介绍和比较1、瀑布型瀑布模型又称为经典生命周期,他提出了一个系统的...
  • 配置管理之三类配置库

    万次阅读 2018-02-22 15:19:13
    1 三库管理原则项目配置管理的库分为开发库、受控库、产品库。这三个库是相互独立的物理库,其中受控库在逻辑上分为配置库和基线库。1.1 开发库存放代码、脚本等开发过程中的产物。由开发人员使用。只有开发人员可...
  • [项目管理]-第十章:配置管理

    千次阅读 2019-05-28 10:21:54
    第十章:配置管理(PPT.279) 1.配置管理的概念(PPT.281) 概念:是项目管理的一项内容,主要涉及对变更进行系统地控制,建立和维护在项目的 整个软件生存周期中软件项目产品的完整性。 主要包括: 1)标识在...
  • 因为 SQL Server 配置管理器是 Microsoft 管理控制台程序的一个管理单元而不是单独的程序,所以,当运行 Windows 10 时,SQL Server 配置管理器不显示为一个应用程序。  方法一: win8 /win10 打开sqlserver的SQL...
  • SQL 配置管理器找不到了

    万次阅读 多人点赞 2019-09-08 10:19:56
    想用数据库建立远程连接,于是想把数据库改成IP地址连接,突然发现配置管理器不见了!!!!???百度了一下,有人说可以用win + R打开后,输入SQLServerManager10.msc后确定,就可以找到了,大家可以试试,不知道...
  • 操作系统:windows 2008 R2。 操作:如标题。 解决方法:
  • win10 如何打开sql server配置管理

    万次阅读 2017-11-17 21:41:37
    windows7,windows8中可以在开始菜单然后microsoft SQL Server文件下找到。 但windows10下发现找不到了,经过一翻百度后发现windows10隐藏起了。 查找过程是 win键+R键 找开运行其后在里输入 SQLServerManager10....
  • 项目管理中的配置管理

    千次阅读 2017-11-05 23:07:59
    配置管理的目标:为了系统地控制配置变更,在系统的整个生命周期中维持配置的完整性和可跟踪性,标识系统在不同时间点上的配置。配置管理的主要活动:制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计...
  • VS配置管理

    万次阅读 2016-12-10 22:37:13
    可以在VS的配置管理器中,配置当前活动解决方案采用debug和release模式,还可以设置活动解决方案平台,即win32或x64。还可以配置整个解决方案哪些项目需要生成,哪些不用,在多项目编译时间较长的情况下还是挺有作用...
  • SQL Server配置管理器没有任何项目

    万次阅读 热门讨论 2017-09-10 23:20:51
    今天安装了SQL2017后,连接数据库发现报sql错误2,想着是MSSQLSERVER服务没开,就去配置管理器打开,但是发现新安装的sql,显示没有任何项目 辗转查了好久才发现导致的原因是:安装sql过程中,添加实例为当前系统...
  • 必须使用“角色管理工具”安装或配置Microsoft .NET Framework 3.5 SP1   解决方法如下: 打开“服务器管理器” ,在“功能”选项中选择“添加功能”并在“添加功能向导”中选择“.NET Framework 3.5...
  • 配置管理口管理曙光服务器

    万次阅读 2018-04-24 17:43:00
    曙光服务器自带的管理口默认没有配置IP,需要进到BIOS中先配置管理IP,再通过管理口管理服务器。下面简单介绍如何配置管理口IP以及如何登陆管理界面。一、配置管理口IP服务器开机后,在提示界面按DEL键进入BIOS界面...
  • Apollo配置中心介绍

    万次阅读 2018-03-06 17:13:38
    一、背景 ...对于配置的期望值越来越高:配置修改后实时生效、灰度发布、分环境、分集群管理配置、完善的权限、审核机制等。 所以传统的配置文件越来越无法满足开发人员的需求。所以就有了apoll...
1 2 3 4 5 ... 20
收藏数 2,313,101
精华内容 925,240
关键字:

配置管理