配置管理_配置管理计划 - 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
    很好的一个配置管理流程图,关心配置管理的朋友,相信此图会对你有帮助
  • 项目管理中的配置管理

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

    配置管理的目标:为了系统地控制配置变更,在系统的整个生命周期中维持配置的完整性和可跟踪性,标识系统在不同时间点上的配置。

    配置管理的主要活动:制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。

    配置审计的功能:
    (1)防止向用户提交不合格的产品;
    (2)发现不完善的实现;
    (3)找出各配置项不匹配或者不相容的现象;
    (4)确认配置项已在所要求的质量控制后纳入基线并入库保存;
    (5)确认记录和文档保持可追溯性。

    ————————————
    2017.11.05
    23:07

    展开全文
  • 配置管理入门

    2012-02-15 14:41:35
    软件开发过程中通常会产生各种产品,如代码,文档(需求文档、设计文档等)和交互文档(记录与客户开会情况),而这些产品可能被多人,多次修改过,因此需要管理,如记录谁在什么时候改过什么等,这就叫做配置管理。...
     软件开发过程中通常会产生各种产品,如代码,文档(需求文档、设计文档等)和交互文档(记录与客户开会情况),而这些产品可能被多人,多次修改过,因此需要管理,如记录谁在什么时候改过什么等,这就叫做配置管理。这些产品就叫做配置项。


    一、概要 1.1 内容
    规范配置管理活动,确保配置项正确地唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。
    1.2 适用范围
    对于不同类别的软件项目,配置管理的流程不同,可在本流程的基础上进行裁减。
    1.3 术语和缩略语
    1.3.1 软件配置管理(Software Configuration Management,SCM)
    软件配置管理是对软件修改进行标识、组织和控制的技术,用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。


    1.3.2 配置(Configuration)
    配置是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此配置包括了即将受控的所有产品特性,其内容及相关文档、软件版本、变更文档、软件运行的支持数据,以及其他一切保证软件一致性的组成要素,相对与硬件类配置,软件产品的配置包括更多的内容并具有易变性。

    1.3.3 配置项(Configuration Item,CI)
    凡是纳入配置管理范畴的工作成果统称为配置项(Configuration Item, CI),配置项逻辑上组成软件系统的各组成部分,一般是可以单独进行设计、实施和测试的。一个纯软件的CIs通常也称之为软件配置项(Computer Software Configuration Items,CSCIs)。

    配置项主要有两大类:
    1) 属于产品组成部分的工作成果,例如需求文档、设计文档、源代码、测试用例等;
    2) 项目管理和机构支撑过程产生的文档。这些文档虽然不是产品的组成部分,但是值得保存。
    每个配置项的主要属性有:名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里,确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。

    1.3.4 基线(Baseline)
    在配置管理系统中,基线就是一个CI或一组CIs在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素(配置项)的一个版本,且只确定一个版本。一般情况下,基线一般在指定的里程碑(Milestone)处创建,并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制,基线中的配置项被“冻结”了,不能再被任何人随意修改,对其的修改将严格按照变更控制要求的过程进行,在一个软件开发阶段结束时,上一个基线加上增加和修改的基线内容形成下一个基线。
    基线的主要属性有:名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”,为内部开发用的基线则称为一个“Build”。

    建立基线的好处:
    1) 重现性:及时返回并重新生成软件系统给定发布版的能力,或者是在项目中的早些时候重新生成开发环境的能力。当认为更新不稳定或不可信时,基线为团队提供一种取消变更的方法。
    2) 可追踪性:建立项目工件之间的前后继承关系。目的是确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。
    3) 版本隔离:基线为开发工件提供了一个定点和快照,新项目可以从基线提供的定点之中建立。作为一个单独分支,新项目将与随后对原始项目(在主要分支上)所进行的变更进行隔离。


    二、相关人权责
    2.1 项目经理(Project Manager,PM)
    责任:
    1) 与CCB协商确定项目起始基线和开发里程碑;
    2) 接受配置管理计划,并按相关规定贯彻执行;
    3) 接受配置控制委员会的报告。

    权利:
    1) 提出配置管理计划的修改要求;
    2) 提出管理管理的建议和要求。
    2.2 配置控制委员会(Configuration Control Board,CCB)

    责任:
    1) 制定和修改项目的配置管理策略;
    权利:
    1) 批准、发布配置管理计划;
    2) 建立、更改基线的设置,审核变更申请;
    3) 根据配置管理员的报告决定相应的对策。

    2.3 配置管理员(Configuration Management Officer,CMO)
    责任:
    1) 编制配置管理计划;
    2) 执行配置项管理方案;
    3) 执行版本控制和变更控制方案;
    4) 编制配置状态报告;
    权利:
    向CCB汇报有关配置管理流程中的不符合情况。

    2.4 程序库管理员(Program Librarian,PL)
    责任:
    1) 配置库的建立和权限分配;
    2) 配置管理工具的日常管理与维护;
    3) 配置库的日常操作和维护;
    权利:
    1) 各配置项的管理与维护;
    2) 对开发人员进行相关的培训。

    2.5 开发人员(Developer)
    责任:
    1) 根据确定的配置管理计划和相关规定,提交配置项和基线;
    2) 负责软件集成和版本生成。
    权利:
    按照软件配置管理工具的使用模型来完成开发任务。

    2.6 测试人员(Tester)
    责任:
    根据配置管理计划和相关规定,提交测试配置项和测试基线;
    权利:
    负责软件变更的测试验证。

    2.7 软件质量保证员(Software Quality Assurance,SQA)
    责任:
    负责配置审核并提交报告。
    权利:
    对配置审核中发现的不符合项,要求相关责任人进行纠正



    三、实施细则
    3.1 CCB的成立

    3.1.1 项目在设计发注后,由项目经理负责组织成立CCB。

    3.1.2 CCB成员组成
    CCB成员人数一般为奇数,人数在3~7人范围内。CCB成员一般包括:
    1) 项目经理PM;
    2) 配置管理员CMO;
    3) SQA;
    4) 测试人员Tester;
    5) 顾客代表;
    6) 主要开发人员等。

    3.1.3 CCB的决策机制
    寻求CCB成员的一致意见。若不能达成一致,可采取由顾客代表做出决策;或采取少数服从多数的原则,由CCB成员投票确定,投票超过半数即为通过。

    3.2 确定配置策略

    3.2.1 配置策略确定的时机
    CCB成立后,由CCB组织会议根据项目的开发计划确定各个里程碑和开发策略,CMO负责整理确定的项目基线和配置项列表,并在编制《配置管理计划》时列明,按约定的时机收集配置项和建立初始基线。

    3.2.2 配置项的范围
    1) 技术文档(Documents):项目开发计划、需求分析报告、软件设计书、质量保证计划、概要设计书、详细设计书、测试文档、技术报告、用户手册、总结报告等;
    2) 程序(Program):阶段产品、计算机程序、源程序、释放产品等;
    3) 工具(Tools):自动设计工具、开发工具、测试工具、维护工具等;
    4) 交互文档(Communications):与客户或项目组内交互产生文档,如会谈记录、E-mail、会议纪要、MSN记录等。

    3.3 制定配置管理计划

    3.3.1 《配置管理计划》的编制
    通常情况下,由CMO在设计发注后,开始编制《配置管理计划》;如有特殊需要,根据合同或项目要求,由CMO在某一项目或项目的某一阶段开始前制定《配置管理计划》。

    3.3.2 《配置管理计划》的内容
    《配置管理计划》应包括以下方面的内容:
    1) 该项目对配置管理的要求;
    2) 实施配置管理的责任人、组织及其职责;
    3) 需要开展的配置管理活动及其进度安排;
    4) 采用的方法和工具等。

    3.3.3 《配置管理计划》的由CCB负责审批。

    3.4 配置项标识规则

    3.4.1 配置项标识要求
    1) 合同有明确标识和追踪要求时,由开发人员按合同要求进行标识,以保证满足合同追踪要求。
    2) 在开发过程中项目组人员提交的配置项,由项目组人员按照本节相关部分标识规则进行标识。
    3) 项目组人员将要标识或已标识的配置项提交给CMO纳入配置库统一管理,并填写《配置状态报告》。

    3.4.2 配置项标识方式

    3.4.2.1 标识项
    配置项标识属性包括:名称、编号、文件状态、版本、作者、日期等。本文标识规则对名称、编号、文件状态和版本进行了描述和规定。

    3.4.2.2 名称
    文件名称的标识按文档模板中统一名称为准。
    a) 编号
    文档编号格式为CC_XXX_***_$$$_###,其中CC表示公司,XXX是项目的三位英文字母缩写表示,***_$$$表示文档类别,###表示文档顺序号。同时对应每个内容都有固定的一个索引文件CC_XXX_**_$$$_index,目的是为了为本类别下的文件建立一个概要说明列表,保证快速对文档进行识别和检索。

    3.4.2.3 文件状态
    文件状态分为“草稿”、“正式发布”和“修改中”三种。
    修改处于“草稿”状态的配置项不算是“变更”,无需CCB的批准,修改者按照版本控制规则执行即可。
    当配置项的状态成为“正式发布”,或者被“冻结”后,此时任何人都不能随意修改,必须依据配置变更控制的规则执行。

    3.4.2.4 文档版本控制
    对于计划性文档、技术文档和用户文档,其版本按修改的先后顺序确定。新生成的文档第一次发行为第一版,修改后第二次发行为第二版,以此类推。

    3.4.2.5 发行版本控制
    最终完成的软件版本用三位符号表示:“s.x.y”。各符号位的含义如下:
    1) “y”为第二次版本号,表示纠正错误时的版本升级,用一位数字表示:“1~9”,对上一次产品或项目中的缺陷做修正,第二次版本号增加;
    2) “x”为第一次版本号,表示增加功能时的版本升级,用一位数字表示:“0~9”。与上一产品或项目相比,功能进行了小量的增加或修正时,第一次版本号增加,第二次版本号为零,第二版本号为零时可以省略不写;
    3) “s”为主版本号。对产品作重大调整,或与已发行的上一产品相比,在功能与性能上有较大改善时主版本号增加;产品或项目概念全新,第一次完成,版本号为1.0。

    3.4.2.6 基线版本标识
    内部基线,如计划基线、设计基线等,在版本号前加Build,如Build 1.0;
    发行产品基线在版本号前加Release,如Release 2.0。
    展开全文
  • 软件配置管理

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

    千次阅读 2011-05-16 09:57:00
    一、概述配置管理(Configuration Management, CM)的目的,在使用配置识别、配置控制、配置状态记录及配置审计,来达到建立与维护工作产品的完整性。配置管理提供了结构化的,有序化的,产品化的管理软件工程的...
  • [项目管理]-第十章:配置管理

    千次阅读 2019-05-28 10:21:54
    第十章:配置管理(PPT.279) 1.配置管理的概念(PPT.281) 概念:是项目管理的一项内容,主要涉及对变更进行系统地控制,建立和维护在项目的 整个软件生存周期中软件项目产品的完整性。 主要包括: 1)标识在...
  • 第七章 软件配置管理

    万次阅读 2018-07-02 20:27:02
    本章内容提要软件配置管理的作用软件配置管理的相关概念建立软件配置管理环境版本控制系统集成分支管理变更管理配置审计和配置状态报告配置管理过程软件配置管理工具第一节 软件配置管理的作用星形网拓扑结构不同...
  • 在大型集群和分布式应用中,配置不宜分散到节点中,应该集中管理,为各种业务平台提供统一的配置管理服务。 随着业务的发展,应用系统中的配置通常会越来越多,常见的一些应用配置大致会有数据源配置,数据源组件...
  • 关于配置管理系统和配置管理项:  配置管理系统的定义是  整个项目管理系统的一个子系统。它由一系列正式的书面程序组成,用于对以下工作提供技术和管理方面的指导与监督:识别并记录产品、成果、服务或部件的...
  • 淘宝分布式配置管理服务Diamond

    万次阅读 2014-10-12 12:57:40
    这些实例使用了一些配置,为了更好地维护这些配置就产生了配置管理服务。通过这个服务可以轻松地管理这些应用服务的配置问题。应用场景可概括为: zookeeper的一种应用就是分布式配置管理(基于ZooKeeper的配置...
  • 高效组织的配置管理计划

    千次阅读 2014-08-19 06:54:31
    根据IEEE 828和CMM/CMMI,配置管理计划常常被认为是一份文档,确实的,对于一个大项目而言,往往需要制定项目自身的配置管理计划。但不是所有的组织都是软件外包组织,不是每个项目针对的是不同的客户。在非软件外包...
  • 配置管理之三类配置库

    万次阅读 2018-02-22 15:19:13
    1 三库管理原则项目配置管理的库分为开发库、受控库、产品库。这三个库是相互独立的物理库,其中受控库在逻辑上分为配置库和基线库。1.1 开发库存放代码、脚本等开发过程中的产物。由开发人员使用。只有开发人员可...
  • 随着软件系统的日益复杂化和用户需求、软件更新的频繁化,配置管理逐渐成为软件生命周期中的重要控制过程,在软件开发过程中扮演着越来越来重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面,同时对...
  • 总结Nacos配置管理操作流程 可以 做 ip hash定位使用哪台机器;每次都访问同一台机器 ,或者做共享session; 集群列表的配置文件,第3步通知的时候就是读取这里获取集群所有服务器列表 给配置文件中的集群列表发送给...
  • SQL 配置管理器找不到了

    万次阅读 多人点赞 2019-09-08 10:19:56
    想用数据库建立远程连接,于是想把数据库改成IP地址连接,突然发现配置管理器不见了!!!!???百度了一下,有人说可以用win + R打开后,输入SQLServerManager10.msc后确定,就可以找到了,大家可以试试,不知道...
  • 配置管理工作职责思考

    千次阅读 2016-06-30 14:30:41
    毕业刚好两年了,做配置管理差不多一年半吧。一开始的半年主要接触的质量管理工作,倒也和配置管理有些沾边。两年时间,说说现在我对配置管理的理解。等过些年再来看,期待到时有新的认识。我所理解的配置管理工作...
  • 项目级配置管理员的职责: 1 制定配置管理计划 2 建立并维护配置管理库 3 建立并发布基线 4 物理审计(PCA) 5 跟踪并关闭变更申请 6 报告配置状态 组织级CM的职责: 1 为项目组建立初始的配置库 2 向项目组成员...
  • java微服务Nacos配置管理

    千次阅读 2019-07-11 11:13:37
    介绍Nacos配置管理 Nacos 提供了动态配置服务,能让我们可以实时进行服务应用的配置变更,让配置管理变得更加高效和快捷。它基于 key/value 方式存储应用配置和其他元数据信息,为分布式系统中的外部化配置提供...
1 2 3 4 5 ... 20
收藏数 2,293,228
精华内容 917,291
关键字:

配置管理