如何看到网站的建设时间,东软网站建设,设计的有趣的网站推荐,上海注册公司哪里政策好前言
本章的知识点预计上午会考1-2分#xff0c;下午可能会考#xff0c;一般与其他管理领域进行结合考查。学习要以教材为主。
目录
15.1 信息和文档管理
15.1.1 信息和文档
15.1.2 信息#xff08;文档#xff09;管理规则和方法
15.2 配置管理
15.2.1 基本概念
…前言
本章的知识点预计上午会考1-2分下午可能会考一般与其他管理领域进行结合考查。学习要以教材为主。
目录
15.1 信息和文档管理
15.1.1 信息和文档
15.1.2 信息文档管理规则和方法
15.2 配置管理
15.2.1 基本概念
15.2.2 角色与职责
15.2.3 目标与方针
15.2.4 管理活动
15.3 变更管理
15.3.1 基本概念
15.3.2 角色与职责
15.3.3 工作程序
15.3.4 变更控制
15.3.5 版本发布和回退计划
15.4 本章练习 15.1 信息和文档管理
信息系统相关信息文档是指某种数据媒体和其中所记录的数据。
15.1.1 信息和文档
1 信息系统信息
信息系统中的信息可以分为用户信息、业务信息、经营管理信息和系统运行信息等。
2 信息系统文档
▲开发文档
描述开发过程本身。
①可行性研究报告和项目任务书②需求规格说明③功能规格说明④设计规格说明包括程序和数据规格说明⑤开发计划⑥软件集成和测试计划⑦质量保证计划⑧安全和测试信息。
▲产品文档
描述开发过程的产物。
①培训手册②参考手册和用户指南③软件支持手册④产品手册和信息广告。
▲管理文档
记录项目管理的信息。
①开发过程的每个阶段的进度和进度变更的记录②软件变更情况的记录③开发团队的职责定义④项目计划、项目阶段报告⑤配置管理计划。
文档的质量通常分为4级。包括
最低限度文档1级文档适合开发工作量低于一个人·月的开发者自用程序。该文档应包含程序清单开发记录测试数据和程序简介。
内部文档2级文档可用于没有与其他用户共享资源的专用程序。2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
工作文档3级文档适合于由同一单位内若干人联合开发的程序或可被其他单位使用的程序。
正式文档4级文档适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质如工资计算的程序需要4级文档。
15.1.2 信息文档管理规则和方法
信息系统文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面。
①文档书写规范应该遵循统一的书写规范包括符号的使用图标的含义、程序中注释行的使用注明文档书写人及书写日期等
②图表编号规则对这些图表进行有规则的编号可以方便查找图表图表编号规则如下图15-1所示 ③文档目录编写标准
④文档管理制度应该建立相应的文档管理制度。
● 信息文档定级保护
应根据侵害可能影响对象和影响程度对信息系统项目的信息文档进行分析并定级按相应的定级保护策略进行管理。
①根据项目干系人和项目价值目标的识别影响对象主要包括
个人、法人和其他组织的合法权益和经济利益
社会秩序、公共利益
国家安全。
②对影响对象的侵害影响程度归结为
无影响
造成一般损害
造成严重损害
造成特别严重损害。
基于以上定级方法组织可以将项目信息文档结合自身业务的特点来定义分级标准并建立相应的分级管理策略。
特别要注意的是在项目应用时应结合客户要求和合同要求建立项目信息文档管理策略。文档中有密级要求的应注意保密和权限管理。项目干系人签字确认后的文档要与相关联的电子文档——对应这些电子文档还应设置为只读。
● 信息文档配置管理
在信息系统项目中配置管理可用于问题分析、变更影响度分析、异常分析等因此配置项与真实情况的匹配度和详细度非常重要。在组织实施信息系统项目过程中常常会遇到变更的发生。变更一般有主动变更和被动变更两种。
·主动变更是主动发起的变更常用于提高项目收益包括降低成本、改进过程以及提高项目的便捷性和有效性等
·被动变更常用于范围变化、异常、错误和适应不断变化的环境等如随需求的增加相应需要增加系统的功能或投资等。
变更管理是对变更从提出、审议、批准、实施到完成的整个过程的管理。
15.2 配置管理
配置管理是为了系统地控制配置变更在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性而标识信息系统建设在不同时间点上配置的学科。
15.2.1 基本概念
1.配置项(Configuration Item, Cl)
配置项的定义为“为配置管理设计的硬件、软件或两者的集合它在配置管理过程中作为一单个实体来对待”。
比较典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等它们经评审和检查通过后进入配置管理。
配置项可以分为基线配置项和非基线配置项两类
●基线配置项可能包括所有的设计文档和源程序等
●非基线配置项可能包括项目的各类计划和报告等。
所有配置项的操作权限应由配置管理员严格管理基本原则是
●基线配置项向开发人员开放读取的权限
●非基线配置项向项目经理、CCB及相关人员开放。
2.配置项状态
配置项的状态可分为“草稿”、“正式”和“修改”三种。
●配置项刚建立时其状态为“草稿”。配置项通过评审后其状态变为“正式”。
●此后若更改配置项则其状态变为“修改”。当配置项修改完毕并重新通过评审时其状态又变为“正式”。配置项状态变化如下图15-2所示 3.配置项版本号
①处于“草稿”状态的配置项的版本号格式为O.YZYZ的数字范围为0199。随着草稿的修正YZ的取值应递增。YZ的初值和增幅由用户自己把握。
②处于“正式”状态的配置项的版本号格式为X.YX为主版本号取值范围为19。Y为次版本号取值范围为09。配置项第一次成为“正式”文件时版本号为1.0。
③处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时一般只增大Z值X.Y值保持不变。当配置项修改完毕状态成为“正式”时将Z值设置为0增加X.Y值。
4.配置项版本管理
在信息系统项目开发过程中绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本避免发生版本丢失或混淆等现象并且可以快速准确地查找到配置项的任何版本。
5.配置基线
配置基线由一组配置项组成这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。产品的一个测试版本可能包括需求分析说明书、概要设计说明书、详细设计说明书、己编译的可执行代码、测试大纲、测试用例、使用手册等是基线的一个例子。基线通常对应于开发过程中的里程碑一个产品可以有多个基线也可以只有一个基线。交付给外部顾客的基线一般称为发行基线内部开发使用的基线一般称为构造基线。对于每一个基线要定义下列内容建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。
6.配置管理数据库
配置管理数据库主要内容包括
①发布内容包括每个配置项及其版本号
②经批准的变更可能影响到的配置项
③与某个配置项有关的所有变更请求
④配置项变更轨迹
⑤特定的设备和软件
⑥计划升级、替换或弃用的配置项
⑦与配置项有关的变更和问题
⑧来自于特定时期特定供应商的配置项
⑨受问题影响的所有配置项。
7.配置库
配置库可以分开发库、受控库、产品库3种
①开发库。开发库也称为动态库、程序员库或工作库用于保存开发人员当前正在开发的配置实体如新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区由开发人员自行控制。无须对其进行配置控制。【可以任意的修改】。
②受控库受控库也称为主库包含当前的基线以及对基线的变更受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时将当前的工作产品存入受控库。【可以修改需要走变更流程】。
③产品库、产品库也称为静态库、发行库、软件仓库包含已发布使用的各种基线的存档被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后作为最终产品存入产品库内等待交付用户或现场安装。【一般不再修改要修改的话需要走变更流程】。
配置库的建库模式有两种按配置项类型建库和按开发任务建库。
①按配置项的类型分类建库。这种模式适用于通用软件的开发组织。在这样的组织内往往产品的继承性较强工具比较统一对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的所以可能会造成开发人员的工作目录结构过于复杂带来一些不必要的麻烦。
②按开发任务建立相应的配置库。这种模式适用于专业软件的开发组织。在这样的组织内使用的开发工具种类繁多开发模式以线性发展为主所以没必要把配置项严格分类存储人为增加目录的复杂性。对于研发性的软件组织来说采用这种设置策略比较灵活。
15.2.2 角色与职责
配置管理相关角色常包括配置控制委员会CCB、配置管理负责人、配置管理员和配置项负责人等。
1 配置控制委员会CCB
配置控制委员会也称为变更控制委员会它不只是控制变更也负有更多的配置管理任务具体工作包括
①制定和修改项目配置管理策略
②审批和发布配置管理计划
③审批基线的设置、产品的版本等
④审查、评价、批准、推迟或否决变更申请
⑤监督己批准变更的实施
⑥接收变更与验证结果确认变更是否按要求完成
⑦根据配置管理报告决定相应的对策。
2 配置管理负责人
配置管理负责人也称配置经理负责管理和决策整个项目生命周期中的配置活动具体有
①管理所有活动包括计划、识别、控制、审计和回顾
②负责配置管理过程
③通过审计过程确保配置管理数据库的准确和真实
④审批配置库或配置管理数据库的结构性变更
⑤定义配置项责任人
⑥指派配置审计员
⑦定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态
⑧评估配置管理过程并持续改进
⑨参与变更管理过程评估
⑩对项目成员进行配置管理培训。
3 配置管理员
配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动具体有
①建立和维护配置管理系统
②建立和维护配置库或配置管理数据库
③配置项识别
④建立和管理基线
⑤版本管理和配置控制
⑥配置状态报告
⑦配置审计
⑧发布管理和交付。
4 配置项负责人
配置项负责人确保所负责的配置项的准确和真实
①记录所负责配置项的所有变更
②维护配置项之间的关系
③调查审计中发现的配置项差异完成差异报告
④遵从配置管理过程
⑤参与配置管理过程评估。
15.2.3 目标与方针
1 管理目标
针对信息系统开发项目常需要通过实施软件配置管理达到配置管理的目标即在整个软件生命周期中建立和维护项目产品的完整性。
2 管理方针
为了实现配置管理目标组织应定义配置管理过程制定配置管理相关制度。
15.2.4 管理活动
配置管理的日常管理活动主要包括6个主要活动:
①制订配置管理计划写一个文档叫做配置管理计划规定如何做好配置管理;
②配置项标识识别出需要把哪些东西作为配置项来管理;
③配置项控制配置项有一些变更需要做好配置变更的控制;
④配置状态报告需要报告配置项的状态是什么样的;
⑤配置审计做好审计看有哪些好的哪些不好的经验教训以及效果怎么样
⑥配置管理回顾与改进定期回顾配置管理活动的实施情况发现在配置管理执行过程中有无问题找到改进点继而优化配置管理过程。
1 制定配置管理计划
配置管理计划是对如何开展项目配置管理工作的规划是配置管理过程的基础应该形成文件并在整个项目生命周期内处于受控状态。CCB负责审批该计划。
2 配置项标识
配置项识别是针对所有信息系统组件的关键配置以及各配置项间的关系和配置文档等结构进行识别的过程。它包括为配置项分配标识和版本号等。配置项识别是配置管理员的职能。
配置项识别的基本步骤如下
识别需要受控的配置项为每个配置项指定唯一的标识号定义每个配置项的重要特征确定每个配置项的所有者及其责任确定配置项进入配置管理的时间和条件建立和控制基线维护文档和组件的修订与产品版本之间的关系。
3 配置项控制
配置项控制即配置项和基线的变更控制包括变更申请、变更评估、通告评估结果、变更实施、变更验证与确认、变更的发布、基于配置库的变更控制等任务。
▲变更申请。相关人员如项目经理填写变更申请表说明要变更的内容、变更的原因、受变更影响的关联配置项和有关基线、变更实施方案、工作量和变更实施人等并提交给CCB。
▲变更评估。CCB负责组织对变更申请进行评估并确定
①变更对项目的影响
②变更的内容是否必要
③变更的范围是否考虑周全
④变更的实施方案是否可行
⑤变更工作量估计是否合理。
CCB决定是否接受变更并将决定通知相关人员。
▲通告评估结果。CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。
▲变更实施项目经理组织修改相关的配置项并在相应的文档、程序代码或配置管理数据中记录变更信息。
▲变更验证与确认项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交给CCB由其确认变更是否已经按要求完成。
▲变更的发布配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果通知相关人员并做好记录。
▲基于配置库的变更控制
现以某软件产品升级为例其过程简述为 ①将待升级的基线假设版本号为V2.1从产品库中取出放入受控库。 ②程序员将欲修改的代码段从受控库中检出Checkout放入自己的开发库中进行修改。代码被检出后即被“锁定”以保证同一段代码只能同时被一个程序员修改如果甲正对其修改乙就无法Check out。 ③程序员将开发库中修改好的代码段检入Checkin受控库。检入后代码的“锁定”被解除其他程序员可以Check out该段代码了。 ④软件产品的升级修改工作全部完成后将受控库中的新基线存入产品库中软件产品的版本号更新为V2.2旧的V2.1版并不删除继续在产品库中保存。 基于配置库的变更控制见下图15-3。 4 配置状态报告
配置状态报告应该包含以下内容
①每个受控配置项的标识和状态
②每个变更申请的状态和已批准的修改的实施状态。
③每个基线的当前和过去版本的状态以及各版本的比较。
④其他配置管理过程活动的记录等。
5 配置审计
配置审计也称配置审核或配置评价包括功能配置审计和物理配置审计分别用以验证当前配置项的一致性和完整性。配置审计的实施是为了确保项目配置管理的有效性性体现了配置管理的最根本要求不允许出现任何混乱现象。包括
①防止向用户提交不适合的产品如交付了用户手册的不正确版本。
②发现不完善的实现如开发出不符合初始规格说明或未按变更请求实施变更。
③找出各配置项间不匹配或不相容的现象。
④确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。
⑤确认记录和文档保持着可追溯性。
功能配置审计是审计配置项的一致性配置项的实际功效是否与其需求一致)验证①配置项的开发已圆满完成②配置项已达到配置标识中规定的性能和功能特征③配置项的操作和支持文档己完成并且是符合要求的。
物理配置审计是审计配置项的完整性配置项的物理存在是否与预期一致验证①要交付的配置项是否存在②配置项中是否包含了所有必需的项目。
一般来说配置审计应当定期进行应当进行配置审计的场景包括
①实施新的配置库或配置管理数据库之后
②对信息系统实施重大变更前后
③在一项软件发布和安装被导入实际运作环境之前
④灾难恢复之后或事件恢复正常之后
⑤发现未经授权的配置项后
⑥任何其他必要的时候等。
6 配置管理回顾及改进
配置管理回顾与改进是指定期回顾配置管理活动的实施情况目的是发现在配置管理执行过程中有无问题找到改进点优化配置管理过程。
配置管理回顾与改进活动包括
①对本次配置管理回顾进行准备设定日期和主题通知相关人等参加会议。根据配置管理绩效衡量指标要求配置项责任人提供配置项统计信息
②召开配置管理回顾会议在设定日期召开回顾会议对配置管理报告进行汇报听取各方意见回顾上次过程改进计划执行情况
③根据会议结论制订并提交服务改进计划
④根据过程改进计划协调落实改进。
15.3 变更管理
15.3.1 基本概念
1 项目变更的含义
变更管理的实质是根据项目推进过程中越来越丰富的项目认知不断调整项目努力方向和资源配置最大程度地满足项目需求提升项目价值。
2 变更产生的原因
变更的常见原因①产品范围成果定义的过失或者疏忽。②项目范围工作定义的过失或者疏忽。③增值变更。④应对风险的紧急计划或回避计划。⑤项目执行过程与基准要求不一致带来的被动调整。⑥外部事件。
3 变更分类
根据变更性质可分为重大变更、重要变更和一般变更。通过不同审批权限控制。
根据变更的迫切性可分为紧急变更、非紧急变更。通过不同变更处理流程进行。
4 变更管理原则
变更管理的原则是项目基准化、变更管理过程规范化。包括
▲基准管理基准是变更的依据。
▲变更控制流程化所有变更都必须遵循这个控制流程进行控制。
▲明确组织分工至少应明确变更相关工作的评估、评审、执行的职能。
▲与干系人充分沟通须征求项目重要干系人的意见获得对项目变更的支持。
▲变更的及时性变更宜早不宜晚只做必须要变更的。由于变更可能带来连锁反应所以可做可不做的尽量不做。
▲评估变更的可能影响变更的来源是多样的既需要完成对客户可视的成果、交付期等变更操作还需要完成对客户不可视的项目内部工作的变更。
▲妥善保存变更产生的相关文档确保其完整、及时、准确、清晰适当时可以引入配置管理工具。
5 变更管理与相关活动的关系
▲变更管理与项目整合管理的关系
变更管理是项目整合管理的一部分实施整体变更控制过程贯穿项目始终。
▲变更管理与配置管理的关系
项目的配置管理计划应规定哪些项目组件受控于配置控制程序。对配置项的任何变更都应该提出变更请求并经过变更控制。配置管理重点关注可交付产品包括中间产品及各过程文档而变更管理则着眼于识别、记录、批准或否决对项目文件、可交付产品或基准的变更。
变更管理过程中包含的部分配置管理活动配置项识别、配置状态记录、配置确认与审计。
15.3.2 角色与职责
信息系统项目中通常会定义变更控制委员会CCB、变更管理负责人、变更请求者、变更实施者和变更顾问委员会等。
项目经理在变更中的作用是
响应变更提出者的需求
评估变更对项目的影响及应对方案
将需求由技术要求转化为资源需求供授权人决策
依据变更评审结果调整基准确保项目基准反映项目实施情况并监控变更及已批准的变更正确实施。
1 变更控制委员会CCB
变更控制委员会是由主要项目干系人代表组成的一个正式团体它是决策机构不是作业机构通过评审手段决定项目基准是否能变更。其主要职责包括
①负责审查、评价、批准、推迟或否决项目变更
②将变更申请的批准、否决或推迟的决定通知受此处置意见影响的相关干系人
③接收变更与验证结果确认变更是否按要求完成。
2 变更管理负责人
也称变更经理通常是变更管理过程解决方案的负责人其主要职责包括
①负责整个变更过程方案的结果
②负责变更管理过程的监控
③负责协调相关的资源保障所有变更按照预定过程顺利运作
④确定变更类型组织变更计划和日程安排
⑤管理变更的日程安排
⑥变更实施完成之后的回顾和关闭
⑦承担变更相关责任并且具有相应权限
⑧可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。
3 变更请求者
需要具备理解变更过程的能力要求提出变更需求。其主要职责包括
①提出变更需求记录并提交变更请求单
②初步评价变更的风险和影响给变更请求设定适当的变更类型。
4 变更实施者
需要具备执行变更方案的技术能力按照批准的变更计划实施变更的内容包括必要时的恢复步骤。其主要职责包括
①负责按照变更计划实施具体的变更任务
②负责记录并保存变更过程中的产物将变更后的基准纳入项目基准中
③参与变更正确性的验证与确认工作。
5 变更顾问委员会
主要职责包括
①在紧急变更时可以对被授权者行使审批权限
②定期听取变更经理汇报评估变更管理执行情况必要时提出改进建议等。
15.3.3 工作程序
变更的流程如下
①变更申请
变更的提出应当及时以正式方式进行并留下面记录。变更的提出可以是各种形式但在评估前应以书面形式提出。项目的干系人都可以提出变更申请但一般情况下都需要经过指定人员进行审批一般项目经理或者项目配置管理员负责相关信息的收集以及对变更申请的初审。
②对变更的初审
变更初审的目的主要包括
①对变更提出方施加影响确认变更的必要性确保变更是有价值的
②格式校验完整性校验确保评估所需信息准备充分
③在干系人间就提出供评估的变更信息达成共识等。
变更初审的常见方式为变更申请文档的审核流转。
③变更方案论证
变更方案的主要作用首先是对变更请求是否可实现进行论证如果可能实现则将变更请求由技术要求转化为资源需求以供CCB决策。对于一些大型的变更可以召开相关的变更方案论证会议通常需要由变更顾问委员会相关技术和经济方面的专家组成进行相关论证并将相关专家意见作为项目变更方案的一部分报项目CCB作为决策参考。
④变更审查
评审过程常包括客户、相关领域的专业人士等。审查通常是文档、会签形式重大的变更审查可以采用正式会议形式。应当在评审过程中将专业评审、经济评审分开对于涉及项目目标和交付成果的变更客户和服务对象的意见应放在核心位置。
⑤发出通知并实施
变更评审通过后意味着基准的调整同时确保变更方案中的资源需求及时到位。如果变更造成交付期的调整应在变更确认时发布而非在交付前公布。
⑥实施监控
变更实施的过程监控通常由项目经理负责基准的监控。CCB监控变更的主要成果、进度里程碑等也可以通过监理单位完成监控。
⑦效果评估
变更评估的关注内容主要包括
评估依据是项目的基准
结合变更的初衷来看变更所要达到的目的是否已达成
评估变更方案中的技术论证、经济论证内容与实施过程的差距并促发解决。
⑧变更收尾
变更收尾是判断发生变更后的项目是否已纳入正常轨道。配置基准调整后需要确认的是资源配置是否及时到位若涉及人员的调整则需要更加关注。变更完成后对项目的整体监控应按新的基准进行。
15.3.4 变更控制
项目规模小、与其他项目的关联度小时变更的提出与处理过程可在操作上力求简便、高效。但小项目的变更仍应注意对变更产生的因素施加影响如防止不必要的变更减少无谓的评估提高必要变更的通过效率等对变更的确认应当正式化变更的操作过程应当规范化。
▲变更申请的控制
变更申请是变更管理流程的起点故应严格控制变更申请的提交。变更控制的前提是项目基准健全变更处理的流程事先达成共识。严格控制是指变更管理体系能确保项目基准反映项目的实施情况。变更申请的提交首先应当确保覆盖所有变更操作这意味着如果变更申请操作可以被绕过那么变更申请的严格管理便毫无意义。
▲变更内容的控制
①对进度变更的控制
②对成本变更的控制
③对合同变更的控制。合同变更控制是规定合同修改的过程它包括文书工作、跟踪系统、争议解决程序以及批准变更所需的审批层次。合同变更控制应当与整体变更控制结合起来。
▲变更类型的控制
①标准变更的控制
标准变更通常是低风险、预先授权的变更这类变更已得到充分理解和完整记录并且可以在不需要额外授权的情况下实现。它们通常作为服务请求发起但也可以是操作改变。当创建或修改标准变更时对于任何其他变更应进行全面的风险评估和授权。此风险评估不需要在每次实施标准变更时重复只有在对此类执行方式修改时进行评估。
②正常变更的控制
正常变更通常是常规的、较低风险的变更依据15.3.3节的工作程序通过已确定的变更授权角色和变更管理流程进行管理。组织可通过使用自动化来提高变更效率使用连续集成和连续部署的自动化管道控制大部分变更控制过程。
③紧急变更的控制
紧急变更通常不包括在变更计划中必须快速响应尽快实施例如业务中断故障或事故、安全攻击等。处理紧急变更的程序在需要时可以精简遇到紧急变化时和决策权限变更时可以临时调整如少数了解业务风险的高级管理人员和重要干系人的决策权发生变化时。
▲变更输入输出的控制
①变更输入的控制主要包括
·项目控制变更的基准、项目计划、配置管理计划、项目文件和组织过程资产等
·变更前的项目工作绩效报告
·提出的变更请求和变更方案等。
②变更输出的控制主要包括
·批准的变更请求
·更新的项目基准更新的项目计划、配置管理计划、项目文件和变更日志等
·变更后的项目工作绩效报告对比变更执行效果
·共享经验教训如偏差产生的原因己采取的行动措施以及所吸取的经验教训使其成为本项目和实施组织内其他项目历史数据的组成部分。
15.3.5 版本发布和回退计划
版本发布前的准备工作包括
①进行相关的回退分析
②备份版本发布所涉及的存储过程、函数等其他数据的存储及回退管理
③备份配置数据包括数据备份的方式
④备份在线生产平台接口、应用、工作流等版本
⑤启动回退机制的触发条件
⑥对变更回退的机制职责的说明如通知相关部门确定需要回退的关联系统和回退时间点等。
回退步骤通常包括
①通知相关用户系统开始回退
②通知各关联系统进行版本回退
③回退存储过程等数据对象
④配置数据回退
⑤应用程序、接口程序、工作流等版本回退
⑥回退完成通知各周边关联系统
⑦回退后进行相关测试保证回退系统能够正常运行
⑧通知用户回退完成等。
15.4 本章练习 至此本文分享的内容结束啦
