目录
- 导读
- [19.1 配置管理](#19.1 配置管理)
* - [19.2 变更管理](#19.2 变更管理)
- 项目变更及其原因
- 项目变更的分类
- 项目变更的含义
- 变更管理的原则
*- [① 基准管理](#① 基准管理)
- [② 变更控制流程化](#② 变更控制流程化)
- [③ 明确组织分工](#③ 明确组织分工)
- [④ 评估变更的可能影响](#④ 评估变更的可能影响)
- [⑤ 妥善保存变更产生的相关文档](#⑤ 妥善保存变更产生的相关文档)
- 与变更有关的角色与职责
* - 变更程序
- 变更控制
* - 软件版本发布(独立知识点)
- [19.3 项目文档管理](#19.3 项目文档管理)
- 信息系统文档的含义
* - 信息系统项目文档的种类
- 文档质量级别
* - 文档管理的规则和方法
*
- 信息系统文档的含义
- 本章总结
- 单词
- 附本
导读
- 第一部分是配置管理非常重要.
- 第二部分是变更管理,变更管理本来也很重要,但是因为在项目整合管理,已经专门把实施整体变更控制过程讲完,所以这的变更管理重要但是学习的代价没那么大.
- 第三部分比较简单就是项目的文档管理,会介绍一下项目有哪些种类的文档,各类文档具体是做什么的.
- 除整合管理之外,其他9个知识领域,一共有10个子计划,除10个子计划之外,还有两个子计划,一个是变更管理计划,一个就是配置管理计划,配置管理计划是整个项目管理计划的一个重要内容.
19.1 配置管理
- 不管做的是偏重于硬件类的项目,还是软件类的项目,还是系统集成项目,现在配置管理都特别重要,实际上一个产品就是包括软硬件集成的产品,它必然涉及到很多的配置项,需要记录每个配置项具体的一些细节,如果这些配置项参数弄乱的话,整个系统后果不堪设想.
- 笔者 : 就相当于零部件管理的账本,记录各种零部件的型号,出厂,材料这些信息.
- 笔者 : 类比思维本章做的事情简单的类比就是相当于打游戏的存档功能,版本就是每个存档,基线就是游戏的主线任务,开发库在研发的中的游戏,受控库,在预测试的游戏,产品库,正式发行的游戏版本.配置库就类似于游戏的历史记录,你有个游戏机,你妈妈就是配置管理负责人,就是管你的,在游戏里他注册了家长身份,就可以是配置管理员,你的账户是孩子账户,就是配置项负责人,虽然你是打游戏的,但是,要在游戏软件里受家长管理员限制,还要受实际你妈妈的控制.
什么是配置管理
- 配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性，而标识信息系统建设在不同时间点上配置的学科。(控制配置变更实际上是为控制配置项的变更,为完成配置项的变更,把配置项信息记录下来,这件事就叫配置管理,而且配置管理要贯穿整个IT系统的生命周期.)
- 应用技术加管理的指导和监控方法,功能特征和物理特征都要记录下来,目标是控制这些特征的变更,就是每一个配置项的所有特征,如果变更的话,都需要进行控制.配置管理跟跟变更管理息息相关,只是关注角度不一样,配置管理是关注特征或者状态,而变更管理关注变更的流程,两者要结合起来
- 国内的信息技术服务标准也有关于配置管理的重要性.配置管理是一个非常基础配件工作,每个项目都应该做好.不管是硬件类的还是软件类的配置项,都需要进行配置管理,但配置管理的概念可以应用于各种信息系统项目,这就是配置管理在整个it项目里的重要性,所有项目都应该进行配置管理.
什么是配置项
定义
- 配置项 （ Configuration Item，Cl ) ：为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待（ GB / T 11457《信息技术软件工程术语》(笔者 : 就是一本字典)）(不管是某个硬件的部件还是某个软件的部件或者某个文件文档,只要他能做为一个单独的实体看待,就可以是一个配置项.)
信息系统配置项范围
- 配置项是组件或与其有关的项目，包括软件、硬件和各种文档，如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议、电信服务等。配置项应受到配置管理的控制.(只识别某件事作为配置项,就应该纳入配置管理的范畴)
软件项目配置项范围
- 配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等它们经评审和检查通过后进入配置管理。(从IT软件类项目看配置项,配置项的涵盖范围特别广,包罗万象.实际不是把所有内容都作为配置项,而是把你认为比较重要的,比如需求文档里的需求规格说明书,可以把它纳入配置项,用户平时收集的需求文件可以作为配置项,也可以不把它纳入配置管理.)
配置项分类
- 基线配置项 ：包括所有的设计文档和源程序等.(基线是要严格受控的,实际上配置管理主要关注基线配置项.软件项目最重要就是源代码,设计文档和源代码是整个软件项目的精华,一般是作为基准,基准配置项目,基线就是基准.)
- 非基线配置项 ：项目的各类计划和报告等.(其他辅助的一些文件一些报告,就是各类计划和项目报告都可以作为非基线的配置项.)
配置项操作基本原则
- 基线配置项 ：向开发人员开放读取的权限.(基线控制项控制的更严格一些就行,必须向开发组开发,开发组成员互相工作是有依赖的,不开放别人怎么调动接口,怎么进行模块整合.)
- 非基线配置项 ：向 PM 、CCB 及相关人员开放.
提示 : 所有配置项的操作权限应由 CMO（ 配置管理员 ）严格管理 .(不管实际的项目有没有人,都要认为所有项目都应该有一个人专门负责配置管理,他日常工作就是干这些事,但可以是兼职的,职位叫配置管理员.所有配置项的操作权限由配置管理员去通过配置管理系统,给某些人分配某些配置项目的访问或者读写权限.)
配置项示例
- 配置项的主要属性 ：名称、标识符、文件状态、版本、作者、日期等.(基线时间点有些配置项可能已经完成入库进入配置库,有些还没做可以写到这里,最后如果一旦完成的话,形成V1.0版本之后,可以把配置项纳入到/上传到配置管理系中.)
配置项的状态
- 可将配置项状态分为"草稿 " 正式 " 和 " 修改 " 三种 (只要是配置项,必然在这种三种状态之间转换.)
- 配置项刚建立时，其状态为 " 草稿 "
- 配置项通过评审后，其状态变为 " 正式 "
- 此后若更改配置项，则其状态变为 " 修改 "
- 当配置项修改完毕并重新通过评审时，其状态又变为 " 正式 "
- 草稿比如被分配负责写概要设计文件,项目经理决定把它纳入配置管理系统作为配置项目,分配你负责或者你负责领几个团队成员起草概要设计,起草的时候,每天修改几次无所谓,根本不需要纳入配置管理系统,可以纳入配置管理但是不受控.
- 比如给你分配一个开发库,你可以每天修改之后,直接在你的开发库里随便改草稿状态,完全不需要审批,但是某天你确定整个概要设计,概要设计说明书完成,就需要评审一下,项目内外或者其他干系人评审,经过评审之后,状态转成正式发布V1.0版本,一旦首次纳入正式发布,就再也回不到草稿状态,永远回不去,因为你已经把配置项纳入正规的配置管理(这叫主库).
- 还要修改怎么办,设计之后,客户需求改变,设计说明书可以改,如果修改的话得提变更,状态变成修改状态,整个还是受控的,修改之后变成2.0版本,再经过审批之后,再入库成为2.0版本,又回到主库.
- 注意配置项只有三个状态草稿,正式和修改,一旦通过首次评审,就在正式和修改状态进行转换.
配置项版本号标识规则
- 草稿状态一般也不需要特别的标识,因为有一个开发库,正常的配置管理系统或者版本管理系统它会自动编号.
- 一旦经过评审之后,配置项要配成正式状态,正式状态就是x点y,x是1-9之间y就是正式的大版本,它会升级,x的升级是比较大的一个更改,小版本都不轻易更改.正是版本的变化要非常谨慎.
- 修改状态稍微了解,修改状态x是大于等于一的,一点x,一点x点yz,两位小数代表它是修改状态,并且x是超过一大于等于1,一旦修改结束再回到正式状态,一般来讲都是把版本号变成小数点后一位,这是代表正式状态.
提示 : 配置项第一次成为 " 正式 " 文件时，版本号为 1.0.
配置项版本管理
- 关于每个配置项的版本管理的一些知识.
版本控制/版本管理的重要性
- 配置管理中所说的版本包括各种文件、技术文档和程序版本。一般来说，所有的配置项均应列入版本控制的范畴。原因 ：
- 绝大部分的配置项都要经过多次的修改才能最终确定下来.(为啥要做版本控制,因为绝大部分配置项都需要多次修改才能最终确定下来,特别是IT项目一次成型的东西很少,因为IT项目就是一个鉴定明细,一个基本特征.)
- 对配置项的任何修改都将产生新的版本.(对代码修改/对文件修改,任何修改都会产生一个新的版本,不控制它就乱.)
- 我们不能保证新版本一定比旧版本好，不能丢弃旧版本.(未必修改之后,还没有前面的好,不能保证新版本一定比旧版本好,所以不能丢弃旧版本.)
版本控制/版本管理的目的
- 版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。(为什么要保留所有版本,可以快速准确的查找到配置项的任何版本.)
配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等. (版本管理的重要性,未来几乎在配置管理的每一个步骤都需要涉及版本控制这件事.所以现在很多人把配置管理系统,就叫版本控制软件.例如:Git/SVN.)
配置基线
定义
- 配置基线（ Baseline ，也称基准 ）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体，是一组经过正式审查并且达成一致的范围或工作产品。基线是开发工作的基础。 (一个配置项可以做一个基准,但是一般来说是一组配置项.最后形成基准之后基准要入库,进入到配置管理库必须经过批准,因为基准是后边开发/测试/监控的一个基础,没有基准怎么去确定未来的开发是合格还是不合格,怎么确定未来的进度是提前还是落后,怎么确定你未来花的成本是超值还是节约,各方面都得有基准,需求或者范围事先要确定,这叫需求基准.关于成本有成本基准,关于进度时间确定的进度计划表叫进度基准,所以每个基准是一堆逻辑上相关的配置项.比如:项目是小型项目,经常是把需求规格说明书这个文件作为需求基准,所以需求基准里除包括需求规格说明书,还包括用户的文件.就是基准里可以包括多个配置项或者一个配置项都行,每个基准都是由一组由逻辑关系组成的一堆配置项.)
基线重要性
- 配置基线可用于管理对象中的授权产品、标准配置项、开发和测试新配置的起点、作为提供给IT系统用户的配置的标准(如标准工作站)、作为提供新软件的起点等。 (一般的基准,有需求基准,有进度成本基准,有成本基准,有质量基准,还有未来要发布某个版本叫release,每个版本都可以做一个发布基准,发布基准里包括服务器,包括CPU内存是多大,软件才应该给他携带什么版本的软件,包括服务器端软件,客户端软件等这堆东西未来都要交给客户,所以要做一个发布基准.所以基准既是后期开发的一个基础,也是未来通过基准这种方式,把需要交付的内容交付给客户.)
示例
一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一个基线。
例如，可以把【 需求规格说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册 】这些配置项整合到一块，形成一个基线
- (基准定义可以由项目经理或者配置管理员来设置.)
基线中的配置项被 " 冻结 " 了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序. (一旦把这些配置项放到基准,一旦基准被批准,所有内容包括配置项作为冻结就不允许修改(没有特殊情况就不改了).什么情况下可以修改,项目里没什么不可以修改,但是某个配置项表示需求规格说明书已经纳入基准,基准已经发布出去,基准为1.0版本,此种情况也是可以改,整个基准的修改,基准里任何一个配置项的修改,都必须走整体变更控制流程,而且对基准的修改很严格,必须CCB去批准基准修改,只要走流程CCB同意改,基准是可以改的,对基线的/基准的变更必须遵循正式的变更控制流程.)
为什么要建立基准
- 建立基线的价值 ：
- ( 1 ) 基线为项目工作提供了一个定点和快照.(快照就是版本内容就不变,基线就是定点,指的就是快照时间点.)
- ( 2 ) 新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离.(一个新的项目有了一个主线开发,但是同一时刻另外一个小组也可以在这个项目上做开发,成为一个分支,需求基准会变,经过整体变控制主线变成V2.0,但是没关系分支还可以在V1.0环境继续开发,这就是隔离.就是跟基准的后期变化相隔离.)
- ( 3 ) 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法.(就是关于基准的版本问题,就是未来的基于旧期版本做的不好的话,可以把分支取消掉,基于新版本再重新进行就好.)
- ( 4 ) 可以利用基线重新建立基于某个特定发布版本的配置，以重现己报告的错误.(软件针对某个版本出现错误,另外一个版本没有出现错误,所以基准可以帮助确定错误,这是重要性.)
结论 : 所有项目都要建立基准,因为基准对项目很重要.
内容
- 对于每一个基线，要定义下列内容 ：
- 建立基线的事件 (针对需求的基准,还是针对哪方面的基准.)
- 受控的配置项 (基准里要确定多个或者一个配置项,基准包括哪些配置项.)
- 建立和变更基线的程序 (需求基准建立好,如果需求发生变更,变更流程怎么办得写清楚.)
- 批准变更基线所需的权限 (基准理配置项都完备,谁有资格确定它基准V1.0版本,基准已经通过审核,就是批准基准的所需权限.)
基线通常对应于开发过程中的里程碑
交付给外部顾客的基线一般称为发行（Release）基线
内部使用的基线一般称为构造基线或内部（Build）基线
- 需求完成形成一个需求基准,设计完成形成一个设计基准,代码完成形成一个代码或者可执行的成绩基准,最后交给客户的的基准叫发行基准(release)客户得到版本一般都叫release,内部的或者开源项目版本号叫build,build不是正式发行的,build是内部发行的测试版本.就是还没最终发布,如果尝试使用的话,可以去下载build版本.release和build需要背记
配置管理数据库
概念
- 使用配置管理数据库来管理配置项它是指包含每个配置项及配置项之间重要关系的详细费料的数据库。对于信息系统并发项旨，常使用**配置库 (Configuration Library)**实施配置数据的管理。(若干配置项组合成基准或者基线,发现配置管理要管理的内容太繁杂,所以怎么去记录这些配置项,应该有个专门记录的位置,就叫配置管理数据库.就是专门有个数据库来存放配置项,还有配置项之间的复杂关系.因为每一个配置项内容都很繁琐,所以配置管理数据库内容挺多,标题叫配置管理数据库,实际上会重点介绍一个概念配置库,配置库就是配置数据库.)
主要内容
- 配置管理数据库主要内容包括 ：
- ① 发布内容，包括每个配置项及其版本号；
- ② 经批准的变更可能影响到的配置项；
- ③ 与某个配置项有关的所有变更请求；
- ④ 配置项变更轨迹；
- ⑤ 特定的设备和软件；
- ⑥ 计划升级、替换或弃用的配置项；
- ⑦ 与配置项有关的变更和问题；
- ⑧ 来自于特定时期特定供应商的配置项；
- ⑨ 受问题影响的所有配置项。
跟配置项相关的所有内容都要记录到配置管理数据库.(比如 : 飞机一共有250万个零部件,每个零部件都是都是一个配置项,所有配置项都要记录到配置管理数据库,每个配置项,每个零部件具体的规格要求技术要求得有,采购日期得有,对方供应商,供应商的情况也都得有,每个配置项的预期交付日期,验收情况等,都得进入到配置管理数据库,数据量巨大.)
配置项详解
- 配置算理数据库管理所有配置项及其关系，以及与这些配置项有关的事件、问题己知错、变更和发布及相关的员工、供应商和业务部门信息；保荐多种服务的详细信息及这些服务与T组件之间的关系；保存配置项的财务信息，如供应商、购买费用和购买日期等。
配置库
定义
- 配置库（ Configuration Library ）用于存放配置项并记录与配置项相关的所有信息，它是配置管理的有力工具。(配置管理数据库或者配置库,也可以叫配置管理系统,很多人都把它作为版本控制的软件来来用.配置管理必然需要配置库所以它重要.)
配置库好处
- 配置库可回答许多配置管理问题 ：
- ① 哪些用户已提取了某个特定的系统版本. (谁从配置故里篇拿到什么配置项目.)
- ② 运行一个给定的系统版本需要什么硬件和系统软件. (每个确定的版本所需要的运行环境,在配置库里要记录.)
- ③ 一个系统到目前已生成了多少个版本，何时生成的. (配置库必然有个最重要的功能就是做版本控制.)
- ④ 如果某一特定的构件变更了，会影响到系统的哪些版本. (每个release都是由很多配置项组成.之间关系要记录进配置库.)
- ⑤ 一个特定的版本曾提出过哪几个变更请求. (有配置库之后很简单.)
- ⑥ 一个特定的版本有多少已报告的错误. (每个配置项的错误也要记录进配置库.)
所有IT项目必须有配置库.
配置库的类型
- 开发库不受控,组织或者项目给所有程序员,每个程序员分配一个账号一个密码每个人都有一个库,就是他的一个开发库,每个人开发的代码,自己在他的库里随便改,每天改都行,每天改好几次也行,这种叫动态库(开发库).根本就不要做控制,因为做控制代价太大.(笔者:企业给开发人员自己使用的库)
- 受控库非常重要,必然特别关注,只要是纳入控制管理的东西就属于受控,一般都是有一个设计文档,经过评审之后变成V1.0版本,马上进入进入受控库.受控库里的版本升级,必须走整体变更控制流程,整个阶段结束或者整个项目结束的时候,实际工作至少在某个阶段结束之后,工作产生的中间结果放入受控库,放入受控库是必然存在一个时间点,但是实际上都比时间点早,在整个项目或者阶段中间,如果认为某个基准可以发布,经过评审之后,就应该把它放到受控库里去.(笔者:企业实际生产用的库)
- 最后发行的版本的产品,才放到产品库,开发是动态库,产品库是静态,也是要受控的,等着用户从库里取出来安装到本地.(笔者:相当于已经封装版本的软件的库)
- 受控库和产品库之间的区别:受控库虽然受控但是一般内部特别关注的,对外接口就是真的要把最终产品交给客户之前,要把开发好的产品转移到产品库或者静态库,而且一般来讲也是除去开源软件,产品库或者release发行库不允许撤回,只能做版本更新,release1.0版本有bug怎么办,你发布1.1版本,再有bug1.2版本,就是产品库是静态的,很少改但会不断的增添东西.
配置库建库模式
- 如果是配置管理员的话建立配置库的方式有两种.题目就是建立配置库.
- 配置库就是做一个目录结构,不同的可交互放到不同的目录下,作为的配置库.
- 按配置项类型分类建库 : 就是整个是配置库的根目录子目录怎么分的,关键是子目录,子目录是按配置项的类型(比如按照文档类型的配置项),放到目录文档,然后源代码都放到第二个目录,调试测试用例放到目录,可执行的代码就是exe代码放到目录,这种就是按照配置项类型.图中分成四种类型建立目录,每个类型,文档类的再分目录开发文档,测试文档等,源代码也可以再分服务器的源代码,手机端源代码等,这种分类方法,这种建库的方式,就是按配置项类型分库,目录肯定是越来越复杂.
- 按任务建库 :软件开发类项目几乎都是按任务不同的任务类型或者阶段来建库,图中所有按照需求文件放到库,按照设计放到库,编码放到库,测试交付放到库,这就是按任务类型来划分的,而不是按配置项的类型,软件行业人士按任务类型更合适.
角色与职责
配置管理负责人
定义
- 也称配置经理，负责管理和决策整个项目生命周期中的配置活动. (项目里不光有项目经理,还有配置经理,就专门负责配置管理,角色可以重叠,项目经理担任配置经理也可以.)
工作/职责
- ① 管理所有活动，包括计划、识别、控制、审计和回顾； (管理所有配置方面的活动)
- ② 负责配置管理过程； (所有过程如果出现问题都由他去负责)
- ③ 通过审计过程确保配置管理数据库的准确和真实；
- ④ 审批配置库或配置管理数据库的结构性变更；(如果配置库发生变更的话,需要配置经理进行审批)
- ⑤ 定义配置项责任人； (每个配置项还有一个角色叫配置项负责人,是由配置经理审批的)
- ⑥ 指派配置审计员；
- ⑦ 定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态； (架构性的东西都是由配置经理做设计)
- ⑧ 评估配置管理过程并持续改进；
- ⑨ 参与变更管理过程评估； (对变更管理过程进行评估,因为变更管理主要是针对配置项的,所以变更管理一定要由配置经理参与.)
- ⑩ 对项目成员进行配置管理培训。
配置管理员
定义
- 配置管理员（ Configuration Management Officer , CMO ）负责在整个项目生命周期中进行配置管理的主要实施活动. (在配置经理的指导之下,每天专门去维护配置库的人,叫配置管理员.所有的具体内容是配置经理规划,但是实施的话,是由配置管理员进行实施,需要配置管理员懂配置管理系统技术.配置管理的角色非常重要)
工作/职责
-
① 建立和维护配置管理系统：
-
② 建立和维护配置库或配置管理数据库； (由管理员去建立三类库(开发库,受控库,产品库))
-
③ 配置项识别； (具体的进行配置项的识别)
-
④ 建立和管理基线;
-
⑤ 版本管理和配置控制；
-
⑥ 配置状态报告；(由配置管理员生成配置状态报告)
-
⑦ 配置审计；(配置管理员进行或者配合进行配置审计,因为现在很多配置管理系统都是自动生成状态报告,自动可以进行配置审计,配置管理员去操作即可)
-
⑧ 发布管理和交付。(配置管理最后一个步骤或者配置管理的内容,要进行发布和交付管理.)
配置项负责人
定义
- 配置项负责人确保所负责的配置项的准确和真实. (配置项的负责人没什么权限,每个配置项分配一个人叫配置项的负责人)
工作/职责
-
① 记录所负责配置项的所有变更；(只针对于配置项的变更要记录下来.)
-
② 维护配置项之间的关系；(配置项的负责人维护他的配置项和别人的配置项之间的关系.)
-
③ 调查审计中发现的配置项差异，完成差异报告；(负责审计的时候,配置项如果发生问题的话,配置项管理负责找出或者报告偏差.)
-
④ 遵从配置管理过程；(在进行配置项管理的过程当中,要遵从配置管理过程)
-
⑤ 参与配置管理过程评估。(要参与配置管理过程的评估)
配置项负责人是由配置经理来分配的,不是配置管理员
目标与方针
- 方针是一个指导性的东西,原则性的东西,应该先说配置管理的方针,再说配置管理的目标,因为目标东西是很具体的,是应该能达成KPI的.
配置管理目标
概念
- 在信息系统项目中，配置管理的目标主要用以定义并控制信息系统的组件维护准确的配置信息.
目标
- 配置管理目标包括 (需要阅读一下) ：
- ① 所有配置项能够被识别和记录;
- ② 维护配置项记录的完整性；
- ③ 为其他管理过程提供有关配置项的准确信息;
- ④ 核实有关信息系统的配置记录的正确性并纠正发现的错误;
- ⑤ 配置项当前和历史状态得到汇报；
- ⑥ 确保信息系统的配置项的有效控制和管理.
实现整体配置管理目标
- 需要建立完整的配置项管理过程，实现对所有配置项的有效管理，以保证所有配置项及时正确地识别、记录和查询，配置元素当前和历史状态得到汇报以及配置元素记录的完整性。(为实现目配置管理目标,应该建立完整的配置管理过程,对所有配置项进行有效管理,才能实现是配置管理总的目标)
软件配置管理目标
- 针对信息系统开发项目，常需要实施软件配置管理，软件配置管理目标包括(全是针对于软件的) ：
- ① 确保软件配置管理计划得以制订，并经过相关人员的评审和确认；
- ② 应该识别出要控制的项目产品有哪些，并且制定相关控制策略，以确保这些项目产品被合适的人员获取;
- ③ 应制定控制策略，以确保项目产品在受控制范围内更改；
- ④ 应该采取适当的工具和方法，确保相关组别和个人能够及时了解到软件基线的状态和内容。
配置管理方针
方针概念
- 为了实现配置管理目标，组织应定义配置管理过程，制定配置管理相关制度。
- 管理层和项目负责人应该明确配置管理方面的角色和责任，并提供适合的培训。
- 项目组成员应严格按照配置管理过程文件规定的要求执行，履行配置管理职责。
- 配置管理工作应该享有资金和管理决策支持等。
- 配置管理的系统性应在整个项目生命周期中得到控制.
- 配置管理应基于项目类型和支付物等定义覆盖全面的管理范围，如信息系统开发项目中对对外交付的软件产品，以及那些被选定的在项目中使用的支持类工具等。
- 组织应定期开展配置审计活动。
如何做确保方针成功
- 配置管理关键成功因素包括 ：
- ① 所有配置项应该记录；(实际上应该是所有要纳入配置管理的配置项应该记录)
- ② 配置项应该分类；
- ③ 所有配置项要编号；(重要,所有配置项都需要有编号)
- ④ 应该定期对配置库或配置管理数据库中的配置项信息进行审计；(定期审计)
- ⑤ 每个配置项在建立后，应有配置负责人负责；(为每个配置项分配一个配置项负责人)
- ⑥ 要关注配置项的变化情况；(配置项负责人去关注每一个配置项的变化)
- ⑦ 应该定期对配置管理进行回顾；
- ⑧ 能够与项目的其他管理活动进行关联。(配置管理本身不光跟变更关系很大,而且跟项目里其他的内容可能也有很大关系.比如因为干系人最后要到产品库里去下载项目,他需要版本,不能总是不提供,不然就会说明整个项目有问题.)
配置管理活动
- 配置管理的日常管理活动主要包括 ：
- 制订配置管理计划 (做计划就是要做制定配置管理计划)
- 配置项识别
- 配置项控制 (最重要日常工作中,配置管理员要进行配置项的控制或者配置项的管理)
- 配置状态报告
- 配置审计
- 配置管理回顾与改进
制订配置管理计划
- 除整合管理之外,其他9个知识领域,一共有10个子计划,除10个子计划之外,还有两个子计划,一个是变更管理计划,一个就是配置管理计划,配置管理计划是整个项目管理计划的一个重要内容.
定义
- 配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。CCB负责审批该计划。(配置管理计划是一个重要的子计划,重要到变更得CCB负责审批的程度,CCB就是变更控制委员会,负责审批重大的变更.)
主要内容
- 配置管理计划的主要内容需要浏览 ：
- 配置管理的目标和范围。
- 配置管理活动主要包括配置项标识、配置项控制、配置状态报告、配置审计、发布管理与交付等。
- 配置管理角色和责任安排。
- 实施这些活动的规范和流程，如配置项命名规则。
- 实施这些活动的进度安排，如日程安排和程序。
- 与其他管理之间（ 如 : 变更管理等 ）的接口控制。
- 负责实施这些活动的人员或团队，以及他们和其他团队之间的关系。
- 配置管理信息系统的规划，包括配置数据的存放地点、配置项运行的受控环境、与其他服务管理系统的联系和接口、构建和安装支持工具等。
- 配置管理的日常事务，包括许可证控制、配置项的存档等。
- 计划的配置基准线、重大发布、里程碑，以及针对以后每个期间的工作量计划和资源计划。
关于配置管理方方面面的东西,包括怎么进行配置管理,怎么去识别配置项,怎么为配置项分配标识,怎么去做配置审计,每个配置项的命名规则,如何进行发布等,都写到配置管理计划里.
配置项识别
定义
- 配置项识别是识别所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结构识别。它包括为配置项分配标识和版本号等。配置项识别是配置管理的一项基础性工作，要确定配置项的范围、属性、标识符、基准线以及配置结构和命名规则等。 (就是项目里用到的服务器,准备开发的软件包括代码,还有用到的数据等都要纳入配置项,不仅要识别配置项,还要识别各个配置项之间的关系或者结构,这是配置项识别.不仅要识别配置项,还要识别基准,基准的识别也属于配置项识别的范畴)
配置项识别要做哪几个活动
-
( 1 ) 确定配置项范围。识别配置项范围、配置项级别与细节.
-
( 2 ) 确认和记录配置项属性。预先确认和记录各配置项，特别是高风险或关键配置项的属性。配置项属性一般包括配置项的名称、编号、类别、版本号、责任人、来源、提供日期、许可证号、目前状态、计划状态、父配置项关联、子配置项关联、事件号、问题号、变更请求号、变更号、备注等内容。
-
( 3 ) 为配置项定义标识符。赋予每个配置项一个唯一的标识符并维护这些标识的准确性
-
( 4 ) 确定配置基准线。完整的配置基准线应该包括 ：
-
① 过去的、当前的和计划中的发布信息；
-
② 过去的、当前的和计划中的变更信息；
-
③ 批准和实施变更时信息系统的状态和有关文档；
-
④ 实施发布时信息系统的状态和有关文档；
-
⑤ 按标准规范配置的硬件和软件。
-
-
( 5 ) 确定配置结构。确定信息系统的配置结构，说明配置项的层次结构和各配置项之间的关系。
-
( 6 ) 确定配置项命名规则。可应用于配置项标识、配置文档、变更和基准线等。
用什么方式分配唯一编码
- 每个配置项可以通过自身的字符、拷贝号/序列号和版本号等标识唯一识别。
- 版本号识别出哪些变化的版本属于同一配置项.
- 同一配置项的不同版本可以在同一时刻共存.
- 制定命名规则时应充分考虑未来可能的版本增长.
- 标识应相对较短，但有其具体含义，并尽可能使用现有规则.
- 版本记录、变更记录以及其他与信息系统有关的配置项都需要标识.
配置项命名规则
- 配置项命名规则应能体现 ：
- ① 配置结构内各配置项间的层级关系；
- ② 每个配置及其相关文档间的关系；
- ③ 各配置项及其相关文档间的关系；
- ④ 文档与变更间的关系等。
整个配置管理或者配置项东西,配置项如果是复杂的系统,配置项可能是有级别的,配置项命名规则里要求考虑,配置项之间的层级关系,还有配置项之间的关联,还要考虑文档与变更间的关系.
配置项控制
- 配置项控制即对配置项和基线的变更控制. (对配置项和基准的变更进行控制,所以标题全称应该是配置项变更的控制或者对配置项进行变更控制.)
1、变更申请
- 变更申请主要陈述 ：要做什么变更，为什么要做，打算怎么做变更；相关人员填写变更申请表，提交CCB. (对配置项的变更要提出申请,因为配置项里边指的是受控的或者基准的配置项,所以应该提交给CCB.)
2、变更评估
- CCB负责组织对变更申请进行评估并确定 ：变更的影响、变更是否必要、是否考虑周全、实施方案是否可行、工作量估计是否合理.(对配置项的变更请求进行影响的评估.包括未来怎么实施,变更的工作量会怎么样,如何实施等.)
3、通告评估结果
响的干素大，站巢被否决，应通知提茁大CCB把变更电请的批准。否决或推迟的决定通知受此处置意见影响的干系人。如果变更批准，应该通知受影.(通知或者通告评估的结果,或者是批准,或者说拒绝,或者是悬停状态,就是待审批状态.当前先别决定,等一个月之后各种评估结果出来.)
4、变更实施
- 项目经理组织修改相关的配置项，并在相应的文档或代码中记录变更信息.(如果是通过批准的变更请求才做变更实施,变更实施因为是执行一个操作,肯定是项目经理负责进行变更的实施.)
5、变更验证与确认
- 项目经理指定人员对变更后的配置项进行测试或验证，将结果提交CCB，确认变更是否按要求完成.(变更实施之后,如果客户要求做某个配置项的变更,具体产品的变更,变更之后要做变更的验证与确认.就是是不是按照想当初批准的变更要求去实施变更,测试和验证一下.)
6、变更的发布
- 配置管理员将变更后的配置项纳入基线，将变更内容和结果通知相关人员.(就是发布,如果版本升级之后,配置管理员把经过验证或者确认的新的版本发布出去,形成新的版本基准.)
7、基于配置库的变更控制
- 变更经常会连锁引起多处变更，会涉及到参与开发工作的许多人员。例如、测试引发的需求的修改很可能涉及到需求规格说明、概要设计、详细设计和代码等相关文档，甚至会使测试计划随之变更.(基于配置库的变更控制不是一个步骤,是告诉大家所有配置项变更的时候,要基于配置库东西进行变更控制.)
基于配置库的变更如何进行操作
现在产品版本号是2.1版本发行版本,进行版本升级,预期要升级成2.2版本怎么做.
- 可以把V2.1版本按流程复制到入控库或者主库地方,(实际生产环境下配置库不需要复制,因为发行之前就是V2.1版本,代码就是可执行的,就是在受控库)
按照官方教程理解
- 第一步把要变更或者升级的2.1版本,复制到受控库受控.
- 第二步开发者从受控库里把2.1版本的代码剪(叫check out)出来(就是从库里边把代码或者文件或者文档取出来),放到逻辑上是本地中央处理器,开发库就是动态库,进行日常的修改是不受控的.
- 第三步经过一周之后升级完成,经过评审之后2.2版本,满足客户需求或者需求规格说明书,才能把基准的代码存入(check in)受控库.
- 第四步由配置管理员从受控库里把2.2版本代码放到产品库(一旦受控存入之后就锁定,就变成主库,就严格受控).
- 四个步骤终于完成升级,从使用者的角度2.2版本终于发行出来,2.1版本还在.
流程
- ① 将待升级的基线（ 假设版本号为 V 2.1 ）从产品库中取出，放入受控库
- ② 程序员将代码段从受控库中检出（ Check out ），放入自己的开发库中进行修改。代码被 Check out 后,即被"锁定"以保证同一段代码只能同时被一个程序员修改
- ③ 程序员将开发库中修改好的代码段检入（ Check in ）受控库。Check in 后，代码的"锁定"被解除，其他程序员可以 Check out 该段代码了
- ④ 软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（ 软件产品的版本号更新为V 2.2 ，旧的 V 2 . * 版并不删除，继续在产品库中保存 ）
配置状态报告
定义
- 配置状态报告（ Configuration Status Reporting ）也称配置状态统计（ Configuration Status Accounting ），是配置管理的一个组成部分，其任务是有效地记录报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作.(配置状态报告对动态演化着的配置项)(配置状态报告实际上就是统计报告.实际上就是由配置管理员定期的或者不定期也行,每周把配置库里配置项的状态,整理汇报出来让大家知道,这件事叫配置状态报告.从配置管理员角度讲,就是一个配置统计,现在主要的主流的配置管理系统有自动的出报告的功能.配置状态报告就是相当对这一周此时此刻,所有配置项静态的一个快照或者照片)
内容
- 配置状态报告应该包含 ：
- 每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态
- 每个变更申请的状态和己批准的修改的实施状态.(如果有变更申请的话,变更的执行状态也要有.)
- 每个基线的当前和过去版本的状态以及各版本的比较.
- 其他配置管理过程活动的记录.
包含内容都是放到配置状态统计里.
配置审计
- 审计是关于整个配置管理活动或者配置管理系统的整体的一个评价.
定义
- 配置审计也称配置审核或配置评价，用以验证当前配置项的一致性和完整性
作用
- 配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求，不充许出现任何混乱现象，作用 (为什么要进行配置审计) ：
- ① 防止向用户提交不适合的产品，如交付了用户手册的不正确版本；(防止向用户提交不适合的产品,就是不正确版本,用户手册等.)
- ② 发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更;(及时发现不符合初始要求的各种变更.)
- ③ 找出各配置项间不匹配或不相容的现象；(找出配置项之间的不匹配不相容.)
- ④ 确认配置项己在所要求的质量控制审核之后纳入基线并入库保存：(就是整个流程是不是做了质量控制审核之后,纳入基线,并且正确的入库保存.)
- ⑤ 确认记录和文档保持着可追溯性等。(确认记录和文档保持着追溯性.)
所有配置管理都是要强调可追溯性,到底是否实现可追溯性,可以通过配置审计,来审计一下.
进行配置审计的场景
- 配置审计应当定期进行，应当进行配置审计的场景包括 ：
- ① 实施新的配置库或配置管理数据库之后.
- ② 对信息系统实施重大变更前后.
- ③ 在一项软件发布和安装被导入实际运作环境之前.
- ④ 灾难恢复之后或事件恢复正常之后.
- ⑤ 发现未经授权的配置项后.
- ⑥ 任何其他必要的时候等。
什么时候需要进行配置审计,总体原则就是可以是定期的,也可以是临时的进行审计,或者有突发事件发生也可以审计.
配置审计方法
解析
-
配置审计一般有两种手段,一种叫功能审计,一种叫物理审计.
-
功能审计或者叫功能配置审计,对代码进行进行一致性的审计或者功能审计,实际上主要的手段就是测试,测试一下代码是不是实现当初他的功能,就是跟功能要求是否一致,这叫功能审计.
-
一致性审计具体验证主要包括就是①验证配置项的开发是否已经完成,②是否达到配置标识中规定的性能和功能特征,③就代码不光有可运行代码,代码要正确,还得有代码操作手册,用户手册,也得有整合这些东西.
-
物理审计或者物理配置审计,它强调的是完整性,配置管理计划或者配置项识别的时候,要求产生需求基线1.0版本,结果过了几天后需求基线本来要求有三个文件,要知道三个文件在不在,配置管理系统里记录的每个文件,到物理位置打开文件,看文件的版本跟配置管理系统里记录版本是不是一致.如果某个文件在配置管理系统里记录得文件是V1.0版本,结果到真实的物理位置一查文件版本是V1.2版本,这种物理上不一致的情况要找出来,这种审核叫物理审计或者物理配置审计.
-
功能审计审计的是配置项的一致性,物理审计审计的是配置项的完整性,最好是两者同时都要审计.
部分配置审计工作可由审计软件完成，但即使发现不一致的情况，也不允许自动更新配置库，必须由有关负责人调查后再进行更新.(很大一部分审计都可以软件完成,配置管理软件审计出来不一致,不能自己去更新,配置项必须由相关的负责人(配置项目负责人)或者配置管理员去更新,配置管理软件只能提示.)
配置管理回顾与改进
- 整个配置管理活动或者配置管理流程,不是一成不变的,任何事情都有改进的余地,所以在配置管理活动里最后一个是配置管理的回顾与改进.
定义
- 即定期回顾配置管理活动的实施情况，发发现在配置管理执行过程中有无问题找到改进点，继而优化配置管理过程。(定期的回顾配置管理活动的实施情况,看一下项目配置管理执行过程中有没有问题,如果有问题或者有需要改进的地方,就持续改进,让配置管理过程越来越好.)
配置管理回顾和改进的四项工作
- 配置管理回顾及改进活动包括 ：
- ① 对本次配置管理回顾进行准备，设定日期和主题，通知相关人等参加会议。根据配置管理绩效衡量指标，要求配置项责任人提供配置项统计信息；(对回顾进行准备)
- ② 召开配置管理回顾会议，在设定日期召开回顾会议，对配置管理报告进行汇报听取各方意见，回顾上次过程改进计划执行情况；(召开回顾会议,就是回顾质量,配置管理方面的东西,叫配置管理回顾会)
- ③ 根据会议结论，制订并提交服务改进计划；(根据回顾的内容,制定一个服务改进的计划,就是配置管理服务的改进计划.)
- ④ 根据过程改进计划，协调、落实改进等。(要根据配置管理改进计划进行协调落实)
小结
- 配置管理非常复杂,所有IT项目都应该做配置管理,配置管理管理主体是配置项,配置管理里除配置库要分配职责角色,还要实施一些配置管理活动.
19.2 变更管理
- 其实变更管理应该是配置管理的内容,但是教材里把版本发布这件事放到变更控制后边,大家可以认为是一个独立的小知识点.
项目变更及其原因
定义
- 项目变更管理，指信息系统工程建设项目的实施过程中，由于项目环境或者其他的原因而对项目的功能、性能、架构、技术指标、集成方法、项目进度等方面做出的改变.
变更管理实质
- 变更管理实质 ：根据越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足项目需求，提升项目价值(所有项目特别是IT类项目,对项目的就是信息或者对项目的认知,刚开始很肤浅,越来越深入,最大程度的满足项目需求,通过进行调整要提升项目的价值(变更管理对项目的最大的贡献).越是敏捷项目就越强调,可以通过变更提升项目的价值,有一个认知就是变更不一定是坏事.)
变更的常见原因
- 产品范围 ( 成果 ) 定义的过失或者疏忽.
- 项目范围 ( 工作 ) 定义的过失或者疏忽.
- 增值变更.(项目执行过程中,规划已经结束,开始执行,项目进程过程当中,突然有一个新技术,还省一半钱,中间要临时去替换新技术,这种就是增值变更,增值变更是好的,变更就可以节约时间或者节约项目成本或者提高效率.)
- 应对风险的紧急计划或回避计划.(项目过程当中,如果识别出某个风险,决定采取回避或者其他措施,执行回避措施需要调整工作内容或者基准.)
- 项目执行过程与基准要求不一致带来的被动调整.(项目执行过程中,与基准要求不一致带来的被动调整,就是监控过程当中,发现项目进度已经延误,需要赶工,赶工就是一种变更,就是想办法把进度基准追回来.)
- 外部事件.(突发的事件包括政府一个新的制度,外边发生自然灾害等,都可能导致项目的变更.)
提示 : 所有项目是渐进明细的，变更难以避免.(任何项目特别是IT项目,变更不是难以避免,是不可能避免)
项目变更的分类
为什么要把变更从这些角度分类?
- 不同类型的变更审批的流程应该不一样,审批权限应该不一样,重大变更或者重要变更,一般CCB审批,如果比较小的,一般不太重要的变更,一般是项目经理审批就行,所以变更性质不同,变更审批权可能不一样.
- 根据变更的紧急或者紧迫程度,就是紧急变更还有非紧急变更,不同情况下,需要处理流程不一样,紧急变更那可能走一个紧急变更处理流程,项目经理现场审批,甚至值班的工程师审批就行,非紧急变更,可能走复杂的申报流程.
- 每个行业的项目,变更分类都不太一样.不同领域的项目,弱电工程项目变更,应用开发项目的变更,集成项目的变更,IT咨询的变更,就是不同行业的变更,根据变更内容.
项目变更的含义
项目管理和变更管理的区别
-
项目管理关注基准,但是是作为监控或者执行的依据.
-
变更管理也关注基准,但是在关注的着眼点不一样,变更管理关注变更的流程,为使项目基准与实际执行情况一致要走流程.
项目管理和变更管理的联系
- 两者之间的关联:变更管理属于项目管理的一部分,某个基准变更最后通过变更管理之后,有两种结果,或者拒绝变更或者基准有问题,可以去调整基准,也可以认为项目里对所有基准的变更,都得走变更管理,调整之后的基准返回来又去指导项目管理里的执行和监控.
从资源增值角度看变更
- 在项目过程中，按一定流程，根据变化情况制定方案，调整资源的配置或将储备资源运用于项目之中，满足项目需求、达成新目标.(从资源管理的角度讲,通过变更这件事,可以让资源更加有效的流动起来,更加有效的利用,最后达成项目目标,所以变更可以促进资源增值.)
变更管理的原则
- 变更管理的总体原则 ：项目基准化、变更管理过程规范化.
① 基准管理
- 基准是变更的依据。建立初始基准后，每次变更通过评审后，都应重新确定基准.(基准版本要升级)
② 变更控制流程化
- 采用符合项目需要的变更管理流程，所有变更必须走流程。流程化的作用在于将变更的原因、资源、方案、干系人的共识、等元素综合起来，按科学的顺序进行(为什么要走流程.因为变更流程可以将变更的原因,资源的发展的该结构识等等结合起来.)
③ 明确组织分工
- 至少应明确变更相关工作的评估、评审、执行的职能(在变更管理流程当中,谁负责评估,谁负责评审,谁负责执行变更.)
④ 评估变更的可能影响
- 变更的来源多样，有客户能感知的，也有客户不可感知的(所有变更总的原则只要提出来,就要对变更的影响进行评估.)
⑤ 妥善保存变更产生的相关文档
- 确保其完整、及时、准确、清晰，可引I入配置管理工具，如 : ClearCase 、VSS、CVS 等.(属于辅助性的工作,**为什么说变更管理跟配置管理信息相相关呢?**因为妥善保存变更相关文档,需要通过配置管理工具来保存变更相关的文档.)
与变更有关的角色与职责
变更控制委员会 CCB
- 也称配置控制委员会（Chang Control Board , CCB ），负责裁定接受哪些变更。由项目所涉及的多方人员共同组成，通常包括用户和实施方的决策人员.(要很多关键干系人坐到一块开会,对变更做决策,所以他是一个决策机构,因为一块开会代价比较大,所以是只有基准性的或者重大变更才走CCB变更,方案不是CCB提出来的,变更方案应该是提前项目经理领着团队成员提出来的,CCB只是做决策.)
CCB的定位
- CCB是决策机构，不是作业机构.
- 通常CCB的工作是通过评审手段来决定项目基准是否能变更，但不提出变更方案.
项目经理
- 项目经理是受业主委托对项目经营过程负责者。其正式权力由项目章程取得，而资源调度的权力通常由基准中明确。基准中不包括的储备资源需经授权人批准后方可使用。
项目经理在变更中的定位
- 响应变更，评估影响及应对方案，供授权人决策.(所谓的影响变更,不是影响变更本身,就是你项目经理可以提前影响能导致变更那些原因那些因素,就是尽量别发生负面变更,这叫影响变更.供决策人就是供CCB来进行决策.)
- 根据评审结果调整基准，确保基准反映项目实施情况.(如果是CCB同意变更,就得根据审批结果去领着团队成员去实施变更,如果需要调整基准就要根据CCB的决策去调整基准,这是项目经理在变更中的定位.)
变更管理负责人
定义
- 也称变更经理，通常是变更管理过程解决方案的负责人.(配置管理有配置管理负责人,变更管理有变更管理负责人,所以叫变更经理.对整个项目里变更管理的过程总的进行方案的决策,主要职责其实跟配置经理一样,只不过他关注的是变更管理的架构和流程,包括变更类型的确定等,都是由变更经理来负责的.)
主要职责
- 其主要职责包括 ：
- ① 负责整个变更过程方案的结果；
- ② 负责变更管理过程的监控；
- ③ 负责协调相关的资源，保障所有变更按照预定过程顺利运作；
- ④ 确定变更类型，组织变更计划和日程安排；
- ⑤ 管理变更的日程安排；
- ⑥ 变更实施完成之后的回顾和关闭；
- ⑦ 承担变更相关责任，并且具有相应权限；
- ⑧ 可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。
变更请求者
定义
- 负责记录与提交变更请求单.(除变更经理还有变更的请求者,具体变更的请求者去填写变更请求单.变更请求者不是提出变更的人,客户不是变更请求者,变更请求者是项目经理接收到变更之后,由项目经理指定项目内部的人员,负责提交变更申请单,他要做的工作提交初步的变更方案和计划,肯定不是客户在做.)
主要职责
- 具体为 ：
- ① 提交初步的变更方案和计划；
- ② 初步评价变更的风险和影响，给变更请求设定适当的变更类型；
- ③ 对理解变更过程有能力要求等。(变更请求者应该有能力去理解变更请求和变更过程,所以他不应该是变更的提出者,如果是变更提出者本身是团队成员,提出变更也可以,但是客户不应该是变更请求者.)
变更实施者
- 需要拥有有执行变更方案的内容的技术能力，负责按照实施计划实施具体的变更任务。(有能力去实施批准的变更的团队成员.)
变更顾问委员会
定义
- 负责对重大变更行使审批，提供专业意见和辅助审批.(变更顾问委员会就是跟专家判断一样,有问题大家开个会,跟CCB不是一个组成,CDB是最终批准或拒绝的组成,变更顾问委员会是有重大问题需要咨询的时候,去咨询顾问委员会.)
主要职责
- 具体为 ：
- ① 在紧急变更时，其中被授权者行使审批权限；
- ② 定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等。
变更程序
变更流程步骤(重点内容)
解析
- 第一步是变更申请的提出和接受,所有变更都是项目干系人提出来的,任何一方都可以提变更,所以人人可提变更,但是所有变更提出来之后,必须书面记录,由变更请求者形成书面的变更申请单或者变更请求单.
- 第二步对变更进行初审,初审一般是指项目经理领着团队成员初步审查一下.目的:① 项目经理可以影响提出方,确认它的变更的必要性.② 各方面是否信息充分.③初审还包括与干系人达成共识,就是双方最终确定要提出请求,就是团队或者项目经理准备接受请求.
- 第三步对变更方案进行论证,工作量更大一点,实际上项目团队要做的是根据变更请求来确定实现变更的影响,实施方案可以有很多个方案,对方案进行提出或者论证,把结果转给第四步变更审查.
- 第四步变更审查,对于重大变更或者基准变交给CCB决策,由CDB决定变更是否批准或者是否拒绝,如果是比较小的变更比较紧急的变更,一般的变更变更审查可以是项目经理就可以决定.
- 第五步发出变更通知(对于基准变更),由项目经理组织实施变更,在项目管理中,所有变更不管是批准还是拒绝的变更,发出变更通知之前都得记录到变更日志,只不过在流程里边没有强调变更日志.
- 第六步在变更实施的过程当中,要进行变更实施的监控,主要是由项目经理进行监控,CCB也可能派人进行监控.
- 第七步变更效果的评估,变更结束,实施客户要求的变更之后,看一下变更是否达到当初的目的,实施过程当中是否跟当初的预期没有差距.
- 第八步叫变更收尾,判断变更后项目是否正常,确认资源是否及时到位,新的基准是否可以正常的应用于项目.
变更控制
- 对于不同类型的项目,可能变更的实施有不同的特点.
对于大型项目
-
特点 ：调整基准的成本高，随意调整可能导致基准失效、项目干系人冲突、资源浪费、项目执行情况混乱等。
-
方案 ：强调变更的提出、处理规范化，应分批处理、分优先级等方式以提高效率.
大型项目如果一旦进行调整基准成本很高,会产生很多很多冲突,所以结论对于大型项目,所有变更必须规范化但因为变更会对整个项目产生巨大的影响,所以可以就是分批处理,分优先级的方式处理变更,这样可以提高效率.
对于小型项目
-
特点 ：与其他项目关联度小.
-
方案 ：变更的提出与处理过程可在操作上力求简便、高效.
小型项目本身就是规模小,而且跟别的项目没什么关联,可以整个流程在操作上力求简便高效.
应注意
- 对变更产生因素施加影响；防止不必要的变更和评估，提高必要变更的审批效率.(可能导致变更因素施加影响,防止不必要的变更.)
- 对变更的确认应当正式化.(如果是有变更的话,对变更的确认应当正式化,就是审批流程要正式化.)
- 变更的操作过程应当规范化.(即使是小项目,整个变更流程也应该规范,只不过流程的实施上可以力求简便高效.)
变更申请的控制
定义
- 变更申请是变更管理流程的起点，故应严格控制(严格控制是指：变更管理体系确保项目基准能反映项目的实施情况)变更申请的提交。(在变更提交阶段,变更申请是变更管理流程的起点,故应严格控制变更申请的提交.)
总体要求
- 变更控制的前提是++项目基准健全，变更处理的流程事先共识.++ (所有项目都是严格控制基准)
变更申请的提交应注意两点 ：
- ① 应当确保覆盖所有变更操作，这意味着如果变更申请操作可以被绕过则此处的严格便毫无意义.(所有变更都得走正式的变更申请流程,所有变更必须提申请.)
- ② 应根据变更的影响和代价提高变更流程的效率。并在某些情况下使用进度管理中的快速跟进等方法.(根据变更的影响和代价,提高变更流程的效率.)
变更过程的控制
- 如何进行变更过程的控制
对进度变更的控制
- 判断项目进度的当前状态.
- 对造成进度变化的因素施加影响
- 查明进度是否已经改变.(在项目里边要确认或者查明,进度是否已发生变化.)
- 在实际变化出现时对其进行管理.(进度方面出现问题,出现变更的时候,要进行变更管理.)
对合同变更的控制
- 合同变更控制系统规定合同修改的过程
- 它包括文书工作、跟踪系统、争议解决程序以及批准变更所需的审批层次
- 合同变更控制系统应当与整体变更控制系统结合起来.
对成本变更的控制(看一遍)
- 对造成费用基准变更的因素施加影响
- 确保变更请求获得同意
- 当变更发生时，管理这些实际的变更
- 保证潜在的费用超支不超过授权的项目阶段资金和总体资金
- 监督费用绩效，找出与费用基准的偏差
- 准确记录所有的与费用基准的偏差
- 防止错误的、不恰当的或未批准的变更被纳入费用或资源使用报告
- 就审定的变更，通知利害关系者
- 采取措施，将预期的费用超支控制在可接受的范围内 (涵盖前两种类型,项目里成本变更难度最大,关注点最多.)
查找正、负偏差的原因是整体变更控制的一部分，会影响质量、进度等.(变更控制过程当中不仅要找到进度或者成本的偏差,而且要找偏差出现的原因,才能就是有针对性的制定变更的策略或者变更方案,解决偏差.)
软件版本发布(独立知识点)
- 软件版本就是对外发布给客户版本,发布之前的注意事项,要准备要做哪些东西,这是软件版本发布前的准备,发布前就要做一个回退计划,回退计划很重要.
软件版本发布前的准备
定义
- 为确保版本发布的成功，在版本发布前应对每次版本发布进行管理(每个版本发布之前都得做版本发布管理.)
准备工作内容
- 版本发布前的准备工作包括 ：
- ① 进行相关的回退分析.(发布新版本之前,能确保版本会成功,所以就要考虑回退这件事,还进行回退分析.)
- ② 备份版本发布所涉及的存储过程、函数等其他数据的存储及回退管理.(版本之前先要备份,该备份的东西要备份,)
- ③ 备份配置数据，包括数据备份的方式.(是对数据进行备份.)
- ④ 备份在线生产平台接口、应用、工作流等版本.(各种接口应用工作流进行备份,这些东西都有固定的版本)
- ⑤ 启动回退机制的触发条件.(什么情况下要回退到老版本,把条件写出来.)
- ⑥ 对变更回退的机制职责的说明；如通知相关部门，确定需要回退的关联系统和回退时间点等.(实际上就是回退机制整个过程,对过程如果进行改变的话,如何进行改变,谁有资格整批回退流程,把职责写清楚)
版本发布回退步骤
定义
- 版本发布前应对风险进行相应的评估，对版本发布的过程检查单（ Checklist ) 做严格的评审。确定相应的回退范围，制定相应的回退策略。(版本发布的时候,第一步做什么,第二步做什么,第三步做什么,这叫检查单 .回退范围就是全部回退还是分模块回退.)
回退步骤
- 回退步骤通常包括 ：
- ① 通知相关用户系统开始回退；(通知相关用户系统开始回退,大家不要进行操作,要回退.)
- ② 通知各关联系统进行版本回退；
- ③ 回退存储过程等数据对象；(把一些旧的版本的存储过程和数据进行回退)
- ④ 配置数据回退；
- ⑤ 应用程序、接口程序、工作流等版本回退；
- ⑥ 回退完成通知各周边关联系统；
- ⑦ 回退后进行相关测试，保证回退系统能够正常运行；(比较重要,回退到老版本之后,还得测试一下老版本是否正常运行,就是保证回退之后的系统能正常运行.)
- ⑧ 通知用户回退完成等。(告诉客户已经退回到旧版本,大家按旧版本继续运行.)
影响
- 项目还需要对引起回退的原因进行深入分析、总结经验，避免下次回退发生。对执行回退计划中出现的问题进行分析，完善回退的管理。
19.3 项目文档管理
信息系统文档的含义
在信息系统中
- 信息系统文档，或称信息系统项目相关信息，是指某种数据媒体和其中所记录的数据它具有永久性，并可以由人或机器阅读，通常仅用于描述人工可读的东西(要对文档进行管理,因为它具有永久性.)
在软件工程中
- 在软件工程中，文档常常用来表示对活动、需求、过程或结果，进行描述、定义规定、报告或认证的任何书面或图示的信息(图形表格也属于文档的内容)
信息系统项目文档的种类
-
开发文档，描述开发过程本身 (开发文档是描述具体开发过程的本身,不是结果是描述开发过程,而且还不是项目管理过程,而是开发过程.可以认为就是软件工程进行各种工作,包括需求分析,进行设计,测试等,有很多辅助的文件,这些文件就属于开发文档.)
- 可行性研究报告和项目任务书
- 需求规格说明
- 功能规格说明
- 设计规格说明，包括程序和数据规格说明
- 开发计划
- 软件集成和测试计划
- 质量保证计划 (质量保证属于开发,因为质量是是跟产品本身相关的,为了提高好的产品,要把质量集成到开发过程,所以质量保证属于开发文档.)
- 安全和测试信息
-
管理文档，记录项目管理的信息(管理文档就是项目管理过程当中,那些辅助一些的文件.)
-
开发过程的每个阶段的进度和进度变更的记录
-
软件变更情况的记录
-
开发团队的职责定义(开发团队的职责的定义就是OBS)
-
项目计划、项目阶段报告(项目计划应该是项目管理的计划)
-
配置管理计划(配置管理因为配置跟变更相关,变更是属于项目管理的,所以配置管理计划属于管理文档.)
-
产品文档，描述开发过程的产物(产品文档是强调最后交付的产品的,所以它是描述开发过程的产物.产品文档就是宣传产品有多么好的信息广告.)
- 培训手册
- 参考手册和用户指南
- 软件支持手册
- 产品手册和信息广告
文档质量级别
- 质量级别从1到4依次增强,级别越来越高.
最低限度文档 ( 1级文档 )
- 适合开发工作量低于 4 个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介.(最低限度文档是很小的开发团队或者个人开发的东西,自己写,写出来自己保留,根本就不给别人看.)
内部文档 ( 2级文档 )
- 可用于没有与其他用户共享资源的专用程序。除1级文挡提供的信息外，2 级文档包括程序清单内足够的注释以帮助用户安装和使用程序.(内部文档就是比最低限度文档稍微好一点点,稍微正式一点点,要写注释,这样未来你可以看懂注释.)
工作文档 ( 3级文档 )
- 适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序.(工作文档适合于由同一单位内若干人联合开发程序,这种情况下写的文档叫工作文档,可以是内部共享,也可以是跟其他部门或者单位共享这些文档.)
正式文档 ( 4级文档 )
- 适合正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（ 如 ：工资计算 ）的程序需要4级文档。4级文档遵守 GB / T 8567-2006《 计算机软件文档编制规范 》的有关规定.(正式文档实际上只要你写的各种文档,比如用户需求规格说明书,概要设计说明书,只要是你参考了或者符合计算机软件文档编写规范规定的标准,那就是属于四级文档.软件产品包括文档,各种说明书.)
文档管理的规则和方法
文档书写规范
- 管理信息系统的文档资料涉及文本、图形和表格等多种类型，这些文档都应该遵循统一的书写规范.(书写规范参考国标也可以,参考企业内部的也可以.)
图表编写规范
- 对图表进行有规则的编号，可以方便图表的查找.
示例 ：图表编号规则
解析
- 211203
- 2第一位表示规划阶段启动阶段
- 1第二位表示项目管理计划
- 12第三位表示第十二章
- 03第四位表示项目管理计划
- 图标编号表示第12章的第三个图表
- 企业里项目里是按编码编的,所以看到图表就应该知道到项目管理计划第12章去找图表.
文档目录编写标准
- 文档目录中应包含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等.(不管是电子的文档还是纸质的文档,都应该符合文档编写标准)
文档管理制度
- 文档的管理制度需根据组织实体的具体情况而定，主要包括建立文档的相关规范、文档借阅记录的登记制度、文档使用权限控制规则等.(范围更广一些就是整个文档管理的制度,尽管现在很多企业很多文档采取电子化手段,但是如果使用过文档借阅管理系统,发现有的系统里叫迁入迁出(也有叫借阅的),就是谁什么时间把看电子文档,阅读时间是多少,看完之后还得象征性的或者主动的做一个迁入,都属于文档管理.)
本章总结
- 第一小节学习的非常重要就是配置管理,因为整个课程体系只有在19.1详细解释配置管理了,所以这是重点.
- 第二小节学习的是变更管理,因为专门有一个过程在讲,所以要结合过程,快速回顾一下如何进行变更,变更的分类和特点,还有变更流程.
- 最后一个小节把文档管理的一些注意事项进行解释.
单词
| 序号 | 单词 | 简写 | 翻译 | 描述 |
|---|---|---|---|---|
| 1 | Configuration Item | Cl | 配置项 | |
| 2 | Chang Control Board | CCB | 变更控制委员会 | |
| 3 | Baseline | 配置基线 ,也称基准 | ||
| 4 | Release | 发行基线 | ||
| 5 | Build | 构造基线或内部基线 | ||
| 6 | Configuration Library | 配置库 | ||
| 7 | Development Library | 开发库 | ||
| 8 | Controlled Library | 受控库 | ||
| 9 | Product Library | 产品库 | ||
| 10 | Configuration Management Officer | CMO | 配置管理员 | |
| 11 | Check out | 检出 | ||
| 12 | Check in | 检入 | ||
| 13 | Configuration Status Reporting | 配置状态报告 | ||
| 14 | Configuration Status Accounting | 配置状态统计 | ||
| 15 | Checklist | 检查单 |
附本
| 软件文件名称 | 版本 | 相关文章推荐 |
|---|---|---|
| 《信息技术软件工程术语》 | GB/T11457 | https://handynastyliu.lanzn.com/ivugS2pjzl3g |
| 《信息技术服务运行维护第1部分：通用要求》 | GB/T28827.1 | https://handynastyliu.lanzn.com/ibYuK2pjzlkd |