系统集成项目信息文档和配置管理.docx
《系统集成项目信息文档和配置管理.docx》由会员分享，可在线阅读，更多相关《系统集成项目信息文档和配置管理.docx（24页珍藏版）》请在冰豆网上搜索。
系统集成项目信息文档和配置管理
系统集成项目信息（文档）和配置管理
15.1信息系统项目相关信息（文档）及其管理
15.1-1信息系统项目相关信息（文档）
1.信息系统项目相关信息（文档）含义
信息系统相关信息（文档）是指某种数据媒体和其中所记录的数据。
它具有永久性,并可以由人或机器阅读,通常仅用于描述人工可读的东西。
在软件工程中,文档常常用来表示对括动、需求、过程或结果,进行描述、定义、规定、报告或认证的任何书面或图示的信息。
2.信息系统项目相关信息（文档）种类
《计算机软件产品开发文件编制指南》（本章简称《指南》）明确了软件项目文档的具体分类。
《指南》中提出文档从重要性和质量要求方面可以分为非正式文档和正式文档;从项目周期角度可分为开发文档、产品文档、管理文档:
更细致一点还可分为14类文档文件,具体有可行性研究报告、项目开发计划、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、用户手册、操作手册、模块开发卷宗、测试计划、测试分析报告、开发进度月报和项目开发总结报告。
15.1.2信息系统项目相关信息（文档）管理的规则和方法
管理信息系统文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目泵编写标准和文档管理制度等几个方面。
（1）文档书写规范。
管理信息系统的文档资料涉及文本、图形和表格等多种类型,无论是哪种类型的文档都应该遵循统一的书写规范,包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等。
例如,在程序的开始要用统一的格式包含程序名称、程序功能、调用和被调用的程序、程序设计人等。
（2）图表编号规则。
在管理信息系统的开发过程中用到很多的图表,对这些图表进行有规则的编号,可以方便图表的查找。
图表的编号一般采用分类结构。
根据生命周期法的5个阶段,可以给出图I5-I所示的分类编号规则。
根据该规则,就可以通过图表编号判断该图表出于系统开发周期的哪一个阶段,属于哪一个文档,文档中的哪一部分内容及第几张图表。
第5、6位,流水码
第3、4位,文档内容
第2位,各阶段的文档
第1位,生命周期法各阶段
图15-1图表编号规则
（3）文档目录编写标准。
为了存档及未来使用的方便,应该编写文档目录。
管理信息系统的文档目录中应包含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等。
文档编号一般为分类结构,可以采用同图表编号类似的编号规则。
文档名称要书写完整规范。
格式或载体指的是原始单据或报表、磁盘文件、磁盘文件打印件、大型图表、重要文件原件、光盘存档等。
（4）文档管理制度。
为了更好地进行信息系统文档的管理,应该建立相应的文档管理制度。
文档的管理
制度需根据组织实体的具体情况而定,主要包括建立文档的相关规范、文档借阅记录的
登记制度、文档使用权限控制规则等。
建立文档的相关规范是指文档书写规范、图表编
号规则和文档目录编写标准等。
文档的借阅应该进行详细的记录,并且需要考虑借阅人
是否有使用权限。
在文档中存在商业秘密或技术秘密的情况下,还应注意保密。
15.2配置管理
配置管理是为了系统的控制醌置变更,在系统的整个生命周期中维持配置的完整性
和可跟踪性,而标识系统在不同时间点上配置的学科（ber97）。
在IEEE610.12-90中,
将“配置管理”正式定义为“应用技术的和管理的指导和监督来:
标识和用文档记录配
置项的功能和物理特征、控制对这些特征的变更、记录和报告变更处理过程和实现状态、验证与规定的需求的一致性。
”
软件配置管理是一个支持性的软件生命周期过程（IEEE12207.0-96）,它有益于项目
管理、开发和维护活动、各种保证活动、最终产品的客户和用户。
尽管硬件配置管理和
软件配置管理的实现有所不同,配置管理的概念可以应用于所有要控制的项。
软件配置管理包括4个主要活动:
配置识别、变更控制、状态报告和配置审计,详
见下文。
15.2.1配置管理有关的概念
1.配置项
IEEE对配置项的定义为“硬件、软件或二者兼有的集合,为配置管理指定的,在配
置管理过程中作为一个单独的实体对待。
”[见IEEE-610文本】
以下内容都可以作为配置项进行管理:
外部交付的软件产品和数据、指定的内部软
件工作产品和数据、指定的用于创建或支持软件产品的支持工具、供方,供应商提供的软件和客户提供的设备,软件。
典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据,它们经评审和检查通过后进八软件
配置管理。
2.配置库
配置库是一组受控制的、辅助软件开发、使用和维护的软件及相关的文档
（IEEE610.12-90）,它在软件发布管理和交付活动中,起着器械性的作用。
3.配置管理活动和流程
配置管理活动和讲e程主要包括制定配置管理计划、配置识别与建立基线、建立配置管理系统、版本管理、配置状态报告和配置审计。
4.配置管理系统
软件配置管理系统是软件工程化的重要组成部分。
目的是通过确定软件配置管理细
则和提供规范的软件配置项管理软件系统,加强软件研制过程的质量控制,增强软件研
制过程的可控性.确保软件配置管理项（包括各种文档、数据和程序）的完备、清晰、
一致和可追踪性,以及技术状态的可控制性。
5.基线
一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷
和用户文档构成一条基线。
基线一经放行,就可以作为从配置管理系统检索源代码文卷（配置项）和生成可执行文卷的工具。
在建立基线之前,工作产品的所有者能快速、非正式地对工作产品做出变更。
但基
线建立之后,变更要通过评价和验证变更的正式程序来控制。
15.2.2髓陡配置管理计划
1,配置管理计划编制工作的基本步骤
为给定项目制订软件配置管理过程计划时,应该与组织的上下文、可应用的约束、
普遍接受的指南、项目的本质（例如规模和关键性）保持一致。
覆盖的主要活动包括软
件配置标识、软件配置控制、软件配置状态报告、软件配置审计、软件发布管理与交付。
另外,一般还要考虑一些问题,例如组织与责任、资源与进度、工具选择与实现、销售
商与子合同控制、接口控制等。
制订计划活动的结果记录在软件配置管理计划中,它要
接受软件质量保证的评审和审计。
2.配置管理计划的主要内容
配置管理计划的主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付
计划、备份计划、配置审计和评审、变更管理等。
变更管理委员会（ChangeControlBoard,CCB）审批该计划。
15.2.3配置识别与建立基线
1.配置识别的基本步骤
配置识别是“配置管理的一个要素,包括选择一个系统的配置项和在技术文档中记
录配置项的功能和物理特性。
”[见IEEE-610文本】
配置识别是配置管理员的职能,包括如下内容。
（1）识别需要受控的软件配置项。
（2）给每个产品和它的组件及相关的文档分配唯一的标识。
（3）定义每个配置项的重要特征以及识别其所有者。
（4）识别组件、数据及产品获取点和准则。
（5）建立和控制基线。
（6）维护文档和组件的修订与产品版本之间的关系。
所有配置项都应按照相关规定统一编号,按照相应的模板生成,并在文档中的规定
章节（部分）记录对象的标识信息。
在引入软件配置管理工具进行管理后,这些配置项
都应以一定的目录结构保存在配置库申。
所有配置项的操作权限应由CMO（配置管理员）严格管理,基本原则是:
基线配置项向软件开发人员开放读取的权限;非基线配置
项向PM、CCB及相关人员开放。
2.建立基线的目的及其在项目实施中的应用
配置项的识别是配置管理活动的基础,也是制定配置管理计划的重要内容。
软件配
置项分类软件的开发过程是一个不断变化着的过程,为了在不严重阻碍合理变化的情况
下来控制变化,软件配置管理引入了“基线”这一概念。
根据这个定义,我们在软件的
开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类,例如,基
线配置项可能包括所有的设计文档和源程序等;非基线配置项可能包括项目的各类计划
和报告等。
对于每一个基线,要定义下列内容:
建立基线的事件、受控的项、建立和变更基线
的程序、批准变更基线所需的权限。
在项目实施过程中,每个配置项的基线都要纳入配
置控制,对这些基线的更新只能采用正式的变更管理过程。
这确保了基线的变更只反映
已批准的组件部分的变更。
15.2.4建立配置管理系统
1.建立配置管理方案的基本步骤
基本步骤如下。
（1）组建配置管理方案构造小组。
这个小组负责构造配置管理过程中的所有工作,包括了解本组织的现有开发、管理
现状,选择配置管理工具,制订配置管理规范,安排试验项目的实施,沟通部门间关系,获得管理者支持和开发人员的认同。
配置管理过程构造小组应该包括如下成员。
④小组负责人。
其对整个构造过程负责。
主要职责是协调与其他部门或与上级主
管的关系,监督工作进程,协调小组内部关系。
@技术支持专家。
其负责在技术、设备方面为本组提供支持和服务,井负责本组
同其他部门就技术问题进行联络,如了解相关项目情况、开发环境和开发人员状况等。
③配置管理技术专家。
其对配置管理过程的构造和配置管理工具十分熟悉。
主要
任务是指导配置管理过程的构造,帮助制订配置管理规章,负责对开发人员进行配置管理工具的培训。
通常由配置管理工具提供商或专门的配置管理顾问机构的人员担当此任。
④配置管理系统用户代表。
他们是从将来要在实际的项目开发过程中使用该系统、
遵循该过程的开发人员中挑选出来的。
他们负责从构造初期了解配置管理系统和规程,根据开发羟验协助制订、修改配置管理规程,并在试验项目中担任部分开发角色。
这部分成员应包括软件开发项目经理、设计人员、编码、测试和构造、发布人员。
该项目小组成立后,将按后述步骤开展配置管理过程的构造工作。
（2）对目标机构进行了解、评估。
目标机构的调查评估工作由配置管理技术专家领导,配置管理系统用户代表参与,提供基本信息,并由小组负责人协调,对相关部门人员进行深入调查获得较全面的数据。
对目标机构的了解、评估应从人员、技术、工作流程、现有项目和期望值几方面入手。
（3）配置管理工具及其提供商评估。
通过对组织的评估,了解该组织的现状和需求后,就需要选择适合该组织的配置管理工具。
市场上现有的配置管理工具不下数十种,它们各有所长,在功能、性能等方面有较大的差别,只有对产品及其提供商进行仔细地分析评估,核对目标机构的需求,才能挑选出合适的工具,实现一个理想的配置管理过程。
这种评估可从三个方面进行:
配置管理工具的评估、供应商评估和其他用户使用经验的评估。
（4）制订实施计划。
实施计划由如下部分组成;必要性和影响因素、人员组织和分工、进度计划和风险管理。
（5）定义配置管理流程。
配置管理流程是软件开发机构进行配置管理的依据,也是配置管理构造小组最重要
的工作成果。
配置管理流程规定开发过程中需要做哪些配置管理方面的工作,由谁做、如何做。
制订配置管理流程的方法是:
通过对目标机构的调查、评估,定义现有的配置管理流程,由配置管理技术专家对它进一步分析,结合常规的配置管理方法制订出新的流程。
之后,依据选定的配置管理工具的功能,将新流程中可自动化的环节交由配置管理工具处理,其他环节由新制订的配置管理规范控制。
除了制订配置管理规范外,该小组还应制订出适合目标机构的配置管理基本章程。
该章程应包括配置管理部门的设立、该部门的职能（通常是负责监督配置管理规范的执行情况,对配置规范进行完善,并担当日常的内部配置管理过程支持任务）,定义配置管理过程与开发过程的协调关系,以及各开发阶段的开发人员构成、在配置管理流程中的责任划分等。
一般来说,配置管理包括配置项标识,配置项控制（修改控制）、配置状态报告和配
置审计4个方面的活动。
配置管理规范的制订也应按这4个方面内容进行。
每一个方面要考虑的问题如下。
①配置项标志制订文档或文件编号、标记体系,定义文档和文件之间昀联系。
②确定受控的配置项的取舍,如软件源码、硬件描述文件、中间文件、目标文件、
测试方案和系统数据等。
确定产品版本、基线的标志体系。
③确定库程序的标志和管理机制。
配置项控制确定产品版本的演化策略,规定何
时、何人创建新的基线,如何创建。
确定修改变更控制委员会的人员组成、职能和工作程序。
④确定修改请求的处理流程和终止条件。
⑤确定修改请求处理过程中各开发人员的职能。
确定修改请求和所生成结果的对
应机制。
⑥确定文档的修改方式。
⑦确定配置项的提取方式。
配置状态报告定义报告的内容、形式和提交方式。
⑧确定产品的发行事宜,包括发行时间如何确定、发行说明的生成发布方式及发
行方式等。
配置审计确定审计的执行人员、执行时机,审计的内容和方式。
⑨确定发现问题后的处理方法。
（6）试验项目的实施。
这一阶段的任务是选取目标机构中的一个现有项目,按既定的配置管理流程进行开发和配置管理工作。
这种试验的目的是在一定风险范围内,通过实地运作来确定所选配置管理工具、所制订的配置管理规范是否能满足目标机构的需要。
（7）全面实施。
经过试验项目证实、校正后的配置管理流程就可以在目标机构的各个项目、各个相关工作环节中去应用、实施,最终使醌置管理过程日常化、规范化。
全面实施过程主要
第15章信息（文档）和配置管理413
由配置管理部门根据新的配置管理流程来指导。
配置管理过程构造小组的作用趋于浈化,主要起监督和支持作用。
该小组在全面实施过程中逐步解散,小组中部分成员可转移到配置管理部门中去。
2.建立配置库
1）配置库的类型
配置库可以分为动态库（开发库、程序员库、工作痒）、受控库（主库）、静态库（软件仓库）和备份库4种类型。
（l）动态库。
也称为开发库、程序员库或工作库,用于保存开发人员当前正在开发
的配置实体。
动态库通常包括新模块、文档、数据元素或进行修改的已有元素。
动态库是软件工程师的工作区,由工程师控制。
（2）受控库。
也称为主库或系统库,是用于管理当前基线和控制对基线的变更。
受
控库包括配置单元和被提升并集成到配置项中的组件。
软件工程师和其他人员可以自由地复制受控库中的单元或组件。
然而,必须有适当的权限授权变更。
受控库中的单元或组件用于创建集成、系统和验收测试或对用户发布的构建,
（3）静态库。
也称为软件仓库或软件产品库,用于存档各种广泛使用的已发布的基线。
静态库用于控制、保存和检索主媒介。
（4）备份库。
包括制作软件和相关构架、数据和文档的不同版本的复制品。
在各点
的及时备价,可以每天、每周或每月执行备份。
2）配置库的建库模式
决定配置库的结构是配置管理活动的重要基础。
一般常用的是两种组织形式:
按配置项类型分类建库和按任务建库。
按配置项的类型分类建库的方式经常被一些咨询服务公司所推荐,它适用于通用的应用软件开发组织。
这样的组织,往往产品的继承性较强,工具比较统一,对并行开发有一定的需求。
使用这样的库结构有利于对配置项的统一管理和控制,同时也能提高编译和发布的效率。
但由于这样的库结构并不是面向各个开发团队的开发任务的,所以可
能会造成开发人员的工作目录结构过于复杂,带来一些不必要的麻烦。
而接任务建立相应的配置库,则适用于专业软件的研发组织。
在这样的组织内,使
用的开发工具种类繁多,开发模式以线性发展为主,所以就没有必要把配置项严格地分
类存储,人为增加目录的复杂性。
因此,对于研发性的软件组织来说,还是采用这种设
置策略比较灵活。
3）用于建立配置库的工具
可以用vss、cvs等工具建立配置库,进行选择时考虑以下内容。
（1）所支持的组件类型。
工具是否支持文档（文本）、代码（源代码、目标代码和
可执行文件）、图解的表示和数据。
（2）版本策略。
用于维护版本历史的方法是什么。
（3）SCM模型。
模型是否仅基于源文件修改或者关注版本、基线和软件工程学范例。
（4）数据管理。
如何存储配置实体。
（5）系统生成什么类型的报告。
（6）用户界面和查询能力。
系统是否有易用和健壮的用户界面?
有哪种类型的信息
查询可供使用,是否易用。
（7）可追溯性。
将一个配置实体和其他实体联系是否容易。
（8）自动构建方法。
当发生变更时,使用什么技术来创建新的版本。
（9）安全性。
使用什么机制来控制配置实体的存取。
（10）测试管理。
能否使用工具管理测试用例和测试结果。
（1]）定制化管理。
能否定制这个工具以满足本土化的SCM过程和需要。
（12）集成。
这个工具是否能和其他的SCM工具集成,或者这个工具是否能和连接SCM环境的工具集成。
15.2.5版本管理
1.配置项状态变迁规则
配置项的状态可分为“草稿”、“正式”和“修改”三种。
配置项刚建立时,其状态
为“草稿”。
配置项通过评审后,其状态变为“正式”。
此后若更改配置项,则其状态变
为“修改”。
当配置项修改完毕并重新通过评审时,其状态又变为“正式”。
配置项状态变化如图15-2所示。
圈15-2配置项状态变化
2.配置项版本号标识
配置顼的版本号规则与配置项的状态相关。
（1）处于“草稿”状态的配置项的版本号格式为O.YZ,YZ的数字范围为01~99。
随着草稿的修正,YZ的取值应递增。
YZ的初值和增幅由用户自己把握。
（2）处于“正式”状态的配置项的版本号格式为X.Y,X为主版本号,取值范围为
1~9。
Y为次版本号,取值范围为0~9。
配置项第一次成为“正式”文件时,版本号为1.0。
如果配置项升级幅度比较小,可以将变动部分制作成配置项的附件,附件版本依次
为1.o,I.l,……。
当附件的变动积累到一定程度时,配置项豹Y值可适量增加,Y值增加一定程度时,X值将适量增加。
当配置项升级幅度比较大时,才允许直接增大X值。
（3）处于“修改”状态的配置项的版本号格式为X.YZ。
配置项正在修改时,一般
只增大Z值,X.Y值保持不变。
当配置项修改完毕,状态成为“正式”时,将Z值设置
为O,增加X.Y值。
参见上述规则
（2）。
3.配置项版本控制
配置项的版本控制作用于多个配置管理活动之中,如创建配置项、配置项的变更和
配置项的评审等。
在项目开发过程中,绝大部分的配置项都要经过多次的修改才能最终确定下来。
对配置项的任何修改都将产生新的版本。
由于我们不能保证新版本一定比旧版本“好”,所以不能抛弃旧版本。
版本控制的目的是按照一定的规则保存配置项的所有版本,避免发生版本丢失或混淆等现象,并且可以快速准确地查找到配置项的任何版本。
15.2.6变更控制
1.变更申请
相关人员如项目经理埂写变更申请表,说明要变更的内容、变更的原因、受变更影响的关联配置项、工作量和变更实施人等,并提交给CCB。
2。
变更评估
CCB负责组织对变更申请进行评估并确定以下内容。
（1）变更的内容是否合理。
（2）变更的范围是否正确、考虑周全。
（3）受影响的配置项是否已被充分考虑,是否需要同时进行变更。
（4）工作量估计是否合理。
（5）如有变更实箍方案,评估基线变更的实施方案是否合理。
根据变更影响大小,可以由CCB组长确定由哪些人参如此评估。
CCB决定是否接受变更,并将决定通知相关人员。
3。
变更实施
CM工程师在测试库或开发库中开辟工作空间,从受控库中取出相关的配置项放于
工作空间,分配权限给变更实施人。
项目经理组织修改相关的配置项,并在相应的文档或程序代码中记录变更信息,同时填写报告。
变更实施人完成变更并提交后,项目经理指派其他的人员完成单元测试/代码走查。
4.变更验证与确认
项目经理指定人员对变更后的配置项进行测试或验证,如走查、评审,填写相应
报告。
项目经理应将变更与验证的结果提交CCB组长审批,由其确认变更是否已经按要
求完成。
如果是基线变更,必要时CCB组长应召集CCB会议确认基线变更的结果。
5.变更的发布
配置管理员将变更内容和结果通知相关人员,并做好记录。
15.2.7配置状态报告
1.配置状态报告的内容
配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情况。
这样的报告应该是定期进行,并尽量通过CASE工具自动生成,用数据库中的客观数据来真实地反映各配置项的情况。
配置状态报告应该跟踪以下方面:
产品描述记录、每个受控软件组件的状态、每个构建版发布的内容和状态、每个基线的内容、配置验证记录、变更状态记录（缺陷和改进）和所有位置的所有配置项的安装状态。
2.状态说明
配置状态报告应着重反映当前基线配置项的状态,以作为对开发进度报告的参照。
为了说明项目状态对变更的情况,也应当进行报告。
有时,对配置库的情况也进行说明,例如备份次数,磁盘占用空问等。
只要是关心的信息,均可作为状态报告的内容。
这些信息进行育效记录,往往可以作为项目度量的重要数据来源。
15.2.8配置审计
1.实施配置审计的作用
配置审计的主要作用是作为变更控制的补充手段,来确保某一变更需求已被切实实现。
2.功能配置审计
功能配置审计是进行审计以验证以下几个方面。
’
（l）配置项的开发已圆满完成。
（2）配置项已达到规定的性能和功能特定特性。
（3）配置项的运行和支持文档已完成并且是符合要求的。
【见IEEE-610文本】
功能配置审计可以包括按测试数据审计正式测试文档、审计验证和确认报告、评审所有批准的变更、评审对以前交付的文档的更新、抽查设计评审的输出、对比代码和文档化的需求、进行评审以确保所有测试已执行。
功能配置审计还可以包括依据功能和性能需求进行额外的和抽样的测试。
3.物理配置审计
物理配置审计是进行审计以验证如下方面。
（1）每个构建的配置项符合相应的技术文档。
（2）配置项与配置状态报告中的信息相对应。
物理配置审计可以包括审计系统规格说明书的完整性、审计功能和审计报告、了解不符合采取的措施、对比架构设计和详细设计组件的一致性、评审模块列表以确定符合己批准的编码标准、审计手册（如用户手册、操作手册）的格式、完整性和与系统功能描述的符合性等。
第16章变更管理
变更管理的大致作用与基本操作原则,已在整体管理、范围管理等相关章节中介绍。
由于变更管理方法在项目管理中的重要性,本章对此专门进行论述。
变更在信息系统工程建设过程中经常发生,许多项目失败的原因就是由于对变更的处理不当。
有些变更是积极的,有些则是消极的,做好变更管理可以使项目的质量、进度和成本管理更有效。
16.1项目变更的基本概念
项目变更是指在信息系统项目的实施过程中,由于项目环境或者其他原因而对项目产品的功能、性能、架构、技术指标、集成方法、项目的范围基准、进度基准和成本基准等方面做出的改变。
变更管理的实质,是根据项目推进过程中越来越丰富的项目认知,不断调整项目努力方向和资源配置,最大程度地满足客户等相关于系人的需求,提升项目价值。
16.1.1项目变更的含义
变更管理就是为使得项目基准与项目实际执行情况相一致,对项目变更进行管理的
一套方法。
其可能的两个结果是或者拒绝变更,或者调整基准。
从资源增值视角看,变更的实质,是在项目过程中,按一定流程,根据变化了的情况而更新方案、调整资源
升级会员 