软考配置和变更管理笔记

悟空瞎说
0 阅读19分钟
配置管理
  1. 完整性
  2. 可跟踪性
管理基础
  • 配置项：包括软件、硬件、和各种文档，如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议、电信服务等。
  • 典型胡配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的个种数据、设备型号及其部件等。
基线配置项
  • 可能包括所有胡设计文档肯源程序等。
非基线配置项
  • 可能包括项目胡各类计划肯报告等。
所有配置项操作权限应由配置（CMO）严格管理，基本原则是
  • 基线配置项向开发人员开放读取的权限。
  • 非基线配置向项目经理、CCB及相关人员开放。
配置状态
  • 配置项刚建立时，其状态为“草稿”
  • 配置项通过评审后，其状态为”正式“
  • 若更改配置项：则其状态变”修改“
  • 当配置项修改完毕并重新通过评审时，其状态变”正式“
配置项的版本号
  • 草稿-0.YZ
  • 正式-X. Y
  • 修改-X.YZ
配置项版本管理

在项目开发过程中，绝大部门的配置项都要经过的修改才能最终确定下来。对配置型的任何修改都将产生新的版本。由于我们不能保证新版一定比旧版本”好“，所以不能抛弃旧版本。版本管理的的按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快读准确地查找到配置项的任何版本。

配置基线

配置基线是由一组配置项组成，这些配置构成一个相对稳定的逻辑实体。基线的配置项被冻结”“了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。

  • 产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、以编译的可执行代码，测试大纲、使用手册等）是基线的一个例子。
  • 基线通常对应于开发过程的里程碑，一个产品可以多个基线，也可以只有一个基线。交付外部客户的基线一般称为发行基线，内部开发使用的基线一般称为构造基线。
  • 对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更的程序、批准变更基线所需的权限。
配置管理数据库
  1. 发布内容，包括每个配置项及其版本号；
  2. 经批准的变更可能影响到的配置项；
  3. 与某个配置项有关的所有变更请求；
  4. 配置项变更轨迹
  5. 特定的设备和软件
  6. 计划升级、替换或弃用的配置项；
  7. 与配置项有关的变更和问题。
  8. 来自于特定时期特定供应商的配置项。
  9. 受问题影响的所有配置项
配置库
  • 开发库：开发库也成为动态库、程序员库或工作库。用于保存开发人员当前正在开发的配置实体。如新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区、由开发人员自行控制。无需对其进行配置控制（可任意修改）
  • 受控库：受控库也称为主库，包含当前的基线以及对基线的变更。受控中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作的工作产品存入受控库。（可修改，需要走变更流程）
  • 产品库：产品库也称为静态库、发行库、软件仓库、包换已发布的使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，最为最终产品存入产品库内，等待交付用户或现场安装。（一般不再修改，真要修改的话需要走变更流程）

配置库的建库模式

  1. 按配置项的类型：这种模式适用于通用软件的开发组织。在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。【通用产品】
  2. 按开发任务建立相应的配置库:这种模式适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主。所以没必要把配置项严格分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。【定制产品】
角色与职责
  1. 配置管理负责人（配置经理）
    • 管理和决策整个项目生命周期中的配置活动
      • 管理所有活动，包括计划、识别、控制、审计和回顾；
      • 通过审计过程确保配置管理数据库的准确和真实；
      • 审批配置库或配置管理数据库的结构性变更；
      • 定义配置项责任人
      • 指派配置审计人员
      • 定义配置管理数据库范围，配置项属性、配置项之间关系和配置项状态；
      • 评估配置管理过程并持续改进；
      • 参与变更管理过程评估；
      • 对项目成员进行配置管理培训；
  1. 配置管理员
    • 负责整个项目生命周期中进行配置管理的主要实施活动
      • 建立和维护配置管理系统
      • 建立和维护配置库和配置管理数据库；
      • 配置项识别；
      • 建立和管理基线
      • 版本管理和配置控制
      • 配置状态报告
      • 配置审计
      • 发布管理和交付
  1. 配置项负责人
    • 确保所负责的配置型的准确和真实
      • 记录所有负责配置项的所有变更
      • 维护配置项之间的关系
      • 调查审计中发现的配置项差异，完成差异报告；
      • 遵从配置管理的过程
      • 参与配置管理过程评估。
管理活动
  1. 制动配置管理计划

配置管理计划是对如何开展项目配置工作的规划，是配置管理过程的基础，应该形成文件在整个项目生命周期内处于受控状态。CCB负责审批该计划

  1. 配置项标识

配置项识别是识别所有系统组件的关键配置，以及各项配置项间的关系和配置文档等结构识别。它包括为配置项分配表示和版本号等。配置项识别的配置管理的一项基础性工作，要确定项的范围、属性、标识符、基准线以及配置结构和命名规则等。

  1. 配置项控制

配置项控制即对配置项和基线的变更控制，包括：标识和记录变更申请，分析和评价变更、批准或否决申请、实现、验证和发布已修改的配置项等任务。

    • 变更申请：相关人员（如项目经理）填写变更申请表，说名要变更的内容、变更原因、受变更影响的关联配置的和有关基线、变更实施方案、工作量和变更实施人等，提交CCB
    • 变更评估：CCB负责组织对变更申请进行评估并确定
        • 变更对项目的影响
        • 变更内容是否有必要
        • 变更的范围是否考虑周全；
        • 变更的实施方案是否可行；
        • 变更工作量估计是否合理
        • CCB决定是否接受变更，并将决定通知相关人员。
    • 通告评估结果：CCB把关于每个变更申请的批准，否决或推迟的觉得通知受此处置意见影响的每个干系人。
    • 变更实施：项目经理组织修改的相关的配置项，并在相应的文档、程序代码或配置管理数据中记录变更信息。
    • 变更验证与确认：项目经理制定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的提交给CCB，由其确认变更是否已经按要求完成。
    • 变更的发布：配置管理员将变更的配置项纳入基线。配置管理员将变更内容和结果通知相关人员，并做好记录。
    • 基于配置库的变更控制
      • 将待升级的基线（假设版本号V2.1）从产品库中取出，放入受控库。
      • 程序员将欲修改的代码从受控库检出，放入自己的开发库中进行修改。代码被检出后即被锁定，以保证同一段代码只能被一个程序员修改，如果甲正对其修改， 乙就没法无法chekout
      • 程序员将开发库中修改的代码checkin受控库，代码锁定被解除，其他程序员就可以checkout该段代码了。
      • 软件产品的升级需改全部完成后，将受控中的新基线存产品库中（版本V2.2）
  1. 配置状态报告
    • 每个受控配置项的标识和状态
    • 每个变更申请的状态和已批准的修改的实施状态。
    • 每个基线的当前和过去版本的状态以及各版本的比较。
    • 其他配置管理过程活动的记录。
  1. 配置审计（配置审核或配置评价） 一致性和完成性
    • 配置审计实施是为了确保项目管理配置的有效性，不容许出现任何混乱现象
      • 防止向用户提交不适合的产品，如交付了用户手机的不正确版本。
      • 发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。
      • 找出各配置项间不匹配或不相容的现象。
      • 确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。
      • 确认记录和文档保持着可追溯性。
    • 物理配置审计是设计配置的完整性（配置项的物理存在是否与预期一致）
      • 要交付的配置项是否存在。
      • 配置项中是否包含了所有必须的项目。
    • 配置审计的场景
      • 实施新的配置库或配置管理数据库之后；
      • 对信息系统实施中重大变更前后；
      • 在一项软件发布和安装被导入实际运作环境之前
      • 灾难恢复之后或事件恢复正常之后；
      • 发现未经授权的配置项后
      • 任何其他必要的时候等。
  1. 配置管理回顾与改进
    • 配置管理回顾与改进即定期回顾配置管理活动的实施情况，在发现配置管理执行过程中有无问题，找到改进点，继而优化配置管理的过程。
      • 对本次配置管理回顾进行准备，设定时期和主题，通吃相关人等参与会议。根据配置管理绩效衡量指标，要求配置项责任人提供配置统计信息；
      • 召开配置管理回顾会议，在设定日期召开回顾会议，对配置管理报告进行汇报，听取各方意见，回顾上次过程改进计划执行情况；
      • 根据会议结论，制定并提交服务改进计划；
      • 根据过程改进计划、鞋套、落实改进。

变更管理

变更管理的实质，是根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足项目需求、提升项目价值。

  1. 变更管理与配置管理
    • 如果把项目整体的交付物视作项目的配置项,配置管理可视为对项目完整性管理的一套系统，当用于项目基准调整时，变更管理可视为其一部门。
  1. 变更产生的原因
    • 产品范围（成果）定义的过失或者疏忽。
    • 项目范围（工作）定义的过失和疏忽。
    • 增值变更
    • 应对风险的紧急计划或回避计划。
    • 项目执行过程与基准要求不宜行带的被动调整。
    • 外部事件
  1. 变更分类
    • 根据变更性质可分为：重大变更、重要变更和一般变更。通过不同审批权限。
    • 根据变更的迫切性可分为：紧急变更、非紧急变更。通过不同变更处理流程进行。
  1. 项目变更的含义
    • 变更管理，既是为使得项目基准与项目实际执行情况相一致，应对项目变化的一套管理方法
    1. 管理原则
    • 基准管理：基准是变更的依据
    • 变更控制流程化：所有变更都必须遵循这个控制流程进行控制。
    • 明确组织分工：至少应明确变更相关工作的评估、评审、职责的只能。
    • 评估变更的可能影响：变更的来源是多样的，即需要完成对客户可视的成果、交付期等变更操作，还需要完成对客户不可视的项目内部工作的变更。
    • 妥善保存变更产生的相关文档：确保其完整、及时、准确、清晰、是当时可以引入配置管理工具
  1. 角色与职责（除了项目经理和CCB外）,通常还会定义变更管理负责人、变更请求者、变更实施者和变更顾问微会员会
  • 项目经理

响应变更提出者的需求

评估变更对项目的影响及应对方案

将需求由技术要求转化为资源需求，供授权人决策；

并据评审实施（调整基准），确保项目基准反映项目实施情况

    • 变更管理负责人（变更经理）通常变更过程解决方案的负责人，
      • 负责整个变更过程方案的结果；
      • 负责变更管理的过程的监控
      • 负责协调相关的资源，保障所有变更按照预定过程顺利运作
      • 管理变更的日程安排；
      • 变更实施完成之后的回顾和关闭；
      • 承担变更相关责任，并且具有相应权限。
      • 可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等
    • 变更请求者：负责记录与提交变更请求单，具体为
      • 提交初步的变更方案和计划；
      • 初步评价变更的风险和影响，给变更请求设定适当的变更类型；
      • 对理解变更过程有能力要求等；
    • 变更实施者：需要拥有有执行变更方案的内容的技术能力，负责按照实施计划实施具体的变更任务。
    • 变更顾问委员会：负责对重大变更行使审批，提供专业意见和辅助审批
      • 在紧急变更时，其实被授权者审批权限
      • 定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等。
  1. 工作程序
    • 变更申请
      • 变更提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式，但在评估前应以书面形式提出。项目的干系人都可以提出变更申请，一般项目经理或项目配置管理员负责该相关信息的收集，以及对变更申请的初审。
    • 对变更的初审
      • 对变更提出方施加影响，确认变更的必要，确保变更是有价值的
      • 格式效验，完整性效验，确保评估所需信息准备充分。
      • 在干系人间就提出供评估的变更信息达成共识等。
      • 变更初审的常见方式为变更申请的审核流转。
    • 变更方案论证
      • 变更方案的主要作用, 受限是对变更请求是否实现进行论证，如果可能实现，则将技术要求转为资源需求，以供CCB决策。
      • 对于一些大型的变更，可以召开相关的变更论证会，通常需要变更顾问委员会（技术和经济方面的专家组成）进行相关论证，并将相关专家意见作为项目变更方案的一部门，报项目CCB作为决策参考。
    • 变更审查
      • 变更审查：评审过程通查包括客户、相关领域的专业人士等。审查通常采用文档、会签形式，重大的变更审查可以用正式会议形式。应当在评审过程中将专业评审、经济评审分开，对于设计项目和交付成果的变更，客户和服务对象的意见应该放在核心位置。
    • 发出通知并实施
      • 变更评审通过后，意味着基准的调整，同时确保变更方案中的资源需求及时到位。如果变更造成交付期调整，应在变更确认时发布，而非在交付前发布。
    • 实施监控
      • 变更试试的过程监控，通常有项目经理负责基准的监控。CCB监控变更明确的主要成果、进度里程碑等，也可以通过监理单位完成监控。
    • 效果评估
      • 评估依据是项目的基准
      • 结果变更目标，评估变更所要达到的目的是否可达成；
      • 评估变更方案中的技术论证、经济论证内容与实施过程的差距，并促使解决。
    • 变更收尾
      • 变更收尾是判断发生变更后的项目是否已纳入正常轨道。配置基准调整后，需要确认的是，资源配置是否寄到到位。若设计人员的调整，则需要更加关注。变更完成后对项目的整体监控应按的基准进行。
  1. 变更控制
  2. 版本发布和回退计划

版本发布前

    • 进行相关的回退分析；
    • 备份版本发布所涉及的存储过程、函数等其他数据的存储及回退管理。
    • 备份配置数据，包括数据备份的方式。
    • 备份在线生产平台接口、应用、工作流等版本。
    • 启动回退机制的触发条件
    • 对变更回退的机制职责的说明，如通知相关部门，确定需要回退的关联系统的和回退的时间点等。

回退步骤

      • 通知相关用户系统开始回退；
      • 通知各关联系统进行版本回退；
      • 回退存储过程等数据对象；
      • 配置数据回退
      • 应用程序、接口程序、工作流等版本回退；
      • 回退完成通知各周边关联系统；
      • 回退后进行相关测试，保证回退系统能够正常运行；
      • 通知用户回退完成等
项目文档管理
  • 开发文档：描述开发过程本身，可行性研究报告和项目任务书；需求规格说明书；功能规格说明；设计规格说明（包括程序和数据规格说明、开发计划、软件集成计划和测试计划、质量保证计划、安全和测试信息等）
  • 产品文档：培训手册；参考手册和用户指南，软件支持手册、产品手册和信息广告
  • 管理文档：开发过程的每个阶段的进度和进度变更的记录；软件变更情况的记录；开发团队的职业定义、项目计划、项目阶段包；配置阶段报告；
  1. 最低限度文档（1级文档）适合开发工作量低于一个人月的开发者自用程序；该文档应包含程序清单、开发记录、测试数据和程序简介
  2. 内部文档（2级文档）可用于没有与其他用户共享资源的专用程序。2级文档还包括程序清单内足够注释以帮助用户安装和使用程序
  3. 工作文档（3级文档）适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。
  4. 适合哪些要正式发型供普遍使用的软件产品。

  • 规则和方法

  • 文档书写规范：管理信息系统的文档涉及文本、图表和表格等多种类型，无论那种类型的文档都应该遵循统一的书写规范，包括符号的使用、程序中注释的使用、注明文档书写人及书写日期等。

  • 图表编号规则：在管理信息系统的开发过程用到很多的图表，对这些图表进行有规则地编号，可以方便图表的查找。

  • 文档目录编写标准：为了存档及未来使用的方便，应该编写文档目录。管理信息系统的文档目录应包含文档编码、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等。

  • 文档管理制度：文档的管理制度须根据组织实体的具体情况而定，主要包括建立文档的相关规范、文档借阅

CMMIDEV中的七个项目管理类过程域如下:集成项目管理(IntegratedPrQjectManagement，IPM)

项目监督与控制(PrQjectMonitonngandControl，PMC)

项目计划(PrQjectPlanning，PP)

量化项目管理(QuantitativePrQjectManagement，QPM)

需求管理(RequirementsManagement，REQM)

风险管理(RiskManagement，RSKM)供方协议管理(SupplierAgreementManagement，SAM)

avatar
文章
阅读
粉丝