第十四章项目采购管理思维导图模板_ProcessOn思维导图、流程图

编制采购计划

编制采购计划的输入、输出

输入

范围基准

①范围说明书 ②工作分解结构（WBS） ③WBS词典

项目干系人的需求文档

①制定采购计划时，需要考虑的有关项目需求的重要信息 ②合同和法律方面的要求可能会包括健康、安全、安全设施、绩效、环境、保险、知识产权、平等就业机会、许可证和许可等。

合作协议

组队协议是一个法定的合同协设，指两个或两个以上实体之间形成合作关系、或合 资企业、或者由相关方约定的其他合作协定

风险记录

风险记录包括与风险相关的信息，如已识别的风险、风险的成因、风险所有者、风 险分析结果、风险的优先级、风险的分类和风险应对措施。在编制采购计划中，必须考 虑风险因素。风险记录也叫风险登记册。

与风险相关的合同

与风险相关的合同决定包括保险、合作、服务和其他条款，一旦发生风险时可以明 确各方应承担的具体责任。

活动资源要求

活动资源要求包括对人员、设备或地点的具体需求的信息

项目进度

项目进度包含要求的时间期限或者交付日期的信息。

活动成本估计

活动成本估计得出的评估被用来作“自制／外购”比较的基础。活动成本估计也叫活 动成本估算。

性能价格比基准

该基准为预算提供细节

事业环境因素

①市场条件 ②可从市场得到的产品服务和成果、供应商过去的绩效，以及它们的绩效是基于什么样的条款与条件。

组织过程资产

①正式的采购政策、程序、方针 ②用于定制采购管理计划与选择合同类型的管理系统 ③基于过去的经验，组织与以往有资格的卖方建立起的多层次的供货系统

输出

采购管理计划

①采用的合同类型 ②是否采用独立估算作为评估标准，由谁来准备独立估算？何时进行独立估算。 ③如果项目的执行组织设有采购、合同或者发包部门，项目管理团队本身能采取哪些行动？ ④标准的采购文件 ⑤管理多个供应商 ⑥协调采购与项目的其他方面，如进度与绩效报告 ⑦对计划的采购造成任何约束和假定 ⑧处理从卖方购买产品所需的提前订货期，并与他们一起协调项目进度制定过程 ⑨进行”自制，外购“裁决，并与活动资源估算过程，制定进度计划过程联系起来。 ⑩确定每个合同的可交付成果的安排日期，并与进度定制过程、进度控制过程相协调 ⑪确定履约保证金或者保险合同，以减轻项目的风险 ⑫为卖方提供指导，以帮助其制定与维护工作分解结构 ⑬确定用于采购或合同工作说明书的形式和格式 ⑭确定通过资格预审的卖方 ⑩管理合同的评估卖方的衡量指标

采购工作说明书

①“自制／外购”决定。 ②变更申请

用于编制采购计划过程的技术、方法

“自制／外购”决定。

任何预算限制都可能是影响“自制／外购”决定的因素。如果决定购买，还要进一步 决定是购买还是租借。“自制／外购”分析应该考虑所有相关的成本，无论是直接成本还 是间接成本。例如，在考虑外购时，分析应包括购买该项产品的实际支付的直接成本， 也应包括购买过程的间接成本。

专家判断

专家可由具有专门知识、来自于多种 渠道的团体和个人提供。包括： (l)项目执行组织中的其他单位。 (2)顾问。 (3)专业技术团体。 (4)行业集团。

合同类型

固定总价合同或者总包合同

这类合同为定义明确的产品或服务规定一个固定的总价。固定总价合同也可以包括 为了实现或者超过规定的项目目标（如交货日期、成本和技术绩效以及能被量化和测量 的任何任务）时采取的激励措施。

成本补偿合同

这类合同为卖方报销实际成本，通常加上一些费用作为卖方利润。成本通常分为直 接成本和间接成本。直接成本指直接、单独花在项目上的成本（例如，全职员工在为项 目工作时的薪水）。间接成本，通常指分摊到项目上的经营费用（例如，间接的参与到 项目中的管理层的工资、办公室水电费等）。间接成本一般接直接成本的一定百分比计 算。成本补偿合同也常常包括对达到或超过既定的项目目标（例如进度目标或总成本目 标等）的奖励。成本补偿合同还可以分为以下三类。 ①成本加酬金合同。 项目成本=允许成本十一定酬金 ②成本加固定酬金合同。 项目成本=允许成本十固定酬金 ③成本加数励酬金合同。 项目成本=允许成本十根据合同执行绩效决定酬金（或者执行绩效不好也要负 担超出的成本）

时间和材料合同

时间和材料合同是包含成本补偿合同和固定总价合同的混合类型。当不能迅速确定 准确的工作量时，时间和材料合同适用于动态增加人员、专家或其他外部支持人员等情 况。

工作说明书

工作说明书(SOW)是对项目所要提供的产品、成果或服务的描述。对内部项目而 言，项目发起者或投资人基于业务需要、或产品或服务的需求提出工作说明书。内部的 工作说明书有时也叫任务书。工作说明书包括的主要内容有前言、服务范围、方法、假 定、服务期限和工作量估计、双方角色和责任、交付资料、完成标准、顾问组人员、收 费和付款方式、变更管理等。

工作说明书的格式之一如下。 (1)前言。对项目背景等信息作简单描述。 (2)项目工作范围。详细描述项目的服务范围，包括业务领域、流程覆盖、系绕范 围及其他等。 (3)项目工作方法。项目拟使用的主要方法。 (4)假定。项目进行的假定条件，具体内容需双方达成。 (5)工作期限和工作量估计。项目的时间跨度和服务期限， 项目，需评估服务工作人天，并估算项目预算。 (6)双方角色和责任。分为供应商的职责和发包商的职责， 责进行描述。 对于按人天计算费用的 并对关键角色的工作职 (7)交付件。列出项目的主要交付物的资料，并对交付件的内容与质量要求进行 描述。 (8)完成以及验收标准。列出项目的完成标准和阶段完成标准，完成标准作为项目 验收的依据内容。 (9)服务人员。列出供应商的人员名单及顾问资格信息。描述在什么情况下可进行 供应商人员的变更。 (IO)聘用条款。对聘用供应商人员的级别要求、经验要求及其他相关条款。 (Il)收费和付款方式。项目的付款方式、费用范围和涉税条款等。 (12)变更管理。项目变更的管理过程、相关规定与约束条件等。 (13)承诺。双方承诺均已阅读，理解并同意遵循上述协议书及其条款的约束。而且双方同意，所提到的服务条款及其附件（包括工作说明书、变更授权以及双方协议中 的任何独立完整的陈述），取代所有的建议书或其他在此之前的书面或日头协议等。 (14)保密。遵守保密协议（保密条款另行签署）。 签署接受 xxx 公司（供应商）xxx 公司（发包商） 授权签名：授权签名： 姓名：____日期：一姓名：日期： 职位：职位：

工作说明书与项目范围说明书的区别：工作说明书是对项目所要提供的产品或服务 的叙述性的描述。项目范围说明书则通过明确项目应该完成的工作而确定了项目的范围。

询价

询价的输入

①组织过程资产 ②采购管理计划 ③采购文件

询价的方法和技术

①投标人会议 ②刊登广告 ③制定合格卖方清单

询价的输出

①合格卖方清单 ②采购文件 ③建议书

合同及合同收尾

采购管理的相关概念和主要过程

概念和术语

什么是采购

采购是从项目团队外部获得产品、服务或成果的完整的购买过程 在一次采购过程中，有卖方和买方双方参与或多方参与，他们的目标不同甚至冲突， 各方在一定市场条件下依据有关法律相互影响和制约。通过依法、合法和标准化的采购 管理，采购可以达到降低成本、增加项目利润的作用。 IT 项目采购的对象一般分为工程、产品／货物和服务三大类，有时工程或服务会以项 目的形式通过招投标过程成交。

对采购的基本要求

采购必须满足技术与质量要求，同时应满足经济性或价格合理的要求

采购管理的主要过程

①编制采购计划：。决定采购什么，何时采购，如何采购。 ②编制询价计划。记录项目对于产品、服务或成果的需求，并且寻找潜在的供 应商。 ③询价、招投标。获取适当的信息、报价、投标书或建议书。 ④供方选择。审核所有建议书或报价，在潜在的供应商中选择，并与选中者进行谈判最终合同。 ⑤合同的管理和收尾

编制询价计划

编制询价计划过程的输入

①采购管理计划 ②工作说明书 ③项目管理计划 ④自制/外购决定

编制询价计划过程所需的工具与技术

①标准表格 ②专家判断

询价计划过程的输出

①采购文件 ②评估标准 ③工作说明书

常见的询价文件

方案邀请书

方案邀请书（Request For Proposal，RFP）是用来征求潜在供应商建议的文件，有人 称RFP 为请求建议书，下面给出其格式示例（假定采购对象为项目产品的某个子系统， 此时就是把该子系统外包出去）。 第一部分：前言 1.1 公司情况介绍 1.2 子项目的背景与目标 1.3 相关项目简要介绍 第二部分：RFP 综述 2.1 发布本RFP 的目的 2.2 保密要求 2.3 答复规则（供应商答复的建议书必须按照一定的买方要求编写） 2.4 进度的垦程碑计划 第三部分：子项目综述（本部分内容简要介绍了与子项目有关的更为详细的基础信 息，为供应商编写建议书提供依据） 3.1 业务目标 3.2 范围 3.3 计划进度配合要求 3,4 现有IT 基础、工具、标准介绍 第四部分：建议书编写要求 第五部分：联系人与联系方式

报价邀请书

价邀请书（Request For Quoting，RFQ）是一种主要依据价格选择供应商时，用于 征求潜在供应商报价的文件。一般项目执行组织多在涉及简单产品的招标中使用RFQ。 有人称RFQ 为请求报价单。最简单的一种形式就是报价单，下面给出其格式示例。 买方名称、联系人、联系方式 产品名称 型号 规格（参数） 单位、单价、数量、合计总价 批发价格／折扣／税金 送货方式／时间 付款方式，时间

询价计划编制过程常用到的其他文件

除方案邀请书、报价邀请书外，用于不同类型采购的文件还包括征求供应商意见书 ( Request For Information，RFI)、投标邀请书（Invitation for Bid, IFB）、招标通知、洽谈 邀请以及承包商初始建议征求书。具体使用的采购术语可根据采购的行业和地点而变化。 这些文件都在编制采购计划阶段使用，具体的用法如下。 RFI 用来征求供应商意见，以使需求明确化。如果需求很明确，则用方案邀请书， 征求供应商的建议书( Proposal)。招标或要求供应商报价前，使用报价邀请书，以作为 招标底价及比价的参考（前提是给所有供应商的报价格式都是一样的，知果不一样，则 无法比较，也失去了意义）。随着这些过程的进展，需求不明确及预算不精确的风险被大 大降低。

确定对投标的评判标准

这些评估标准的例子 如下。 (1)对于需求的理解。卖方的建议书对采购工作说明书的响应情况如何？ 2)总成本或者全生命周期成本（包括建设成本与运营成本）。卖方的总成本是否 最低（总成本=采购成本加上运营成本）? (3)技术能力。卖方是否具有所需的技能和知识，或者能否让买方相信具有所需的 技能和知识？ (4)风险。工作说明书中含有多少风险？有多少风险稳皂被转移到卖方？ (5)管理方案。卖方是否具备，或者是否有理由让买方相信能制定一套确保项目成 功的管理过程和程序？ (6)技术方案。卖方建议的技术方法、具体技术、解决方案和服务是否满足采购文 件的要求，或者卖方能提供比预期更好的结果。 (7)保证。卖方给最终产品的售后保证是什么？多长期限？ (8)财务实力。卖方是否具有，或者是否有理由让买方相信能获得所需的财务资源|? (9)生产能力和兴趣。卖方是否有能力和兴趣满足潜在的未来的需求？ (10)业务规模和类型。卖方企业是否符合一种买方定义的或政府规定的作为中标 条件的业务规模和类型，例如具有系统集成资质二级、金融行业为主营业务的企业才能 参加投标。 (11)卖方过去的业绩。卖方过去的经验有哪些？ (12)参考瓷料。卖方能提供的来自以前客户的参考资料有哪些？以便证实卖方的 工作经验，同时检验卖方是否符合合同的要求。 (13)知识产权。卖方在他们工作过程中、或者提供的服务中、或者项目生产的产 品中是否要求知识产杈？例如项目最终提交的软件版权归谁？ (14)专利权。卖方在他们工作过程中、或者提供的服务中、或者项目生产的产品 中是否要求专利权？

招标

招标人及其权利和义务

招标人的权利

招标人是依照《中华人民共和国招标投标法》规定提出招标项目、进行招标的法人或者是其他组织 权利如下： ①招标人有权自行选择招标代理机构，委托其办理招标事宜。招标人具有编制招 标文件和组织评标能力的，可以自行办理招标事宜。 (2)自主选定招标代理机构并核验其资质条件。 (3)招标人可以根据招标项目本身的要求，在招标公告或者投标邀请书中，要求潜 在投标人提供有关资质证明文件和业绩情况，并对潜在投标人进行资格预审；国家对投 标人资格条件有规定的，按照其规定。 (4)在招标文件要求提交投标文件截止时间至少15 日前，招标人可以以书面形式 对已发出的招标文件进行必要的澄清或者修改。该澄清或者修改内容是招标文件的组成 都分。 (5)招标人有权也应当对在招标文件要求提交的截止时间后送达的投标文件拒收。 (6)开标由招标人主持。 (7)招标人根据评标委员会提出的书面评估报告和推荐的中标候选人确定中标人。 招标人也可以授权评标委员会直接确定中标人。

招标人的义务

(l)招标人委托招标代理机构时，应当向其提供招标所需要的有关资料并支付委 托费。 (2)招标人不得以不合理条件限制或者排斥潜在投标人，不得对潜在投标人实行歧 视待遇。 (3)招标文件不得要求或者标明特定的生产供应者，以及含有倾向或者排斥潜在投 标人的其他内容。 (4)招标人不得向他人透露已获取招标文件的潜在投标人的名称、数量，以及可能 影响公平竞争的有关招标投标的其他情况。招标人设有标底的，标底必须保密。 (5)招标人应当确定投标人编制投标文件所需要的合理时间。但是，依法必须进行 招标的项目，自招标文件开始发出之日起至提交投标文件截止之日止，最短不得少于 20 日。 (6)招标人在招标文件要求提交投标文件的截止时间前收到的所有投标文件，开标 时都应当众予以拆封、宣读。 (7)招标人应当采取必要的措施，保证评标在严格保密的情况下进行。 (8)中标人确定后，招标人应当向中标人发出中标通知书，并同时将中标结果通知 所有未中标的中标人。 (9)招标人和中标人应当自中标通知书发出之日起30 日内，按照招标文件和中标 人的投标文件订立书面合同。

招标代理机构

招标代理机构的法律地位

第十五章 信息（文档）和配置管理

信息系统项目相关信息信息（文档）及其管理

信息系统项目相关信息（文档）

信息系统项目相关信息（文档）含义

信息系统相关信息（文档）是指某种数据媒体和其中所记录的数据。它具有永久性，并可以由人或机器阅读，通常仅用于描述人工可读的东西。在软件工程中，文档常常用 来表示对括动、需求、过程或结果，进行描述、定义、规定、报告或认证的任何书面或图示的信息。

信息系统项目相关信息（文档）种类

《计算机软件产品开发文件编制指南》（本章简称《指南》）明确了软件项目文档的具 体分类。《指南》中提出文档从重要性和质量要求方面可以分为非正式文档和正式文档； 从项目周期角度可分为开发文档、产品文档、管理文档：更细致一点还可分为14 类文档 文件，具体有可行性研究报告、项目开发计划、软件需求说明书、数据要求说明书、概 要设计说明书、详细设计说明书、数据库设计说明书、用户手册、操作手册、模块开发 卷宗、测试计划、测试分析报告、开发进度月报和项目开发总结报告。

信息系统项目相关信息（文档）管理的规则和方法

文档书写规范

管理信息系统的文档资料涉及文本、图形和表格等多种类型，无论是哪种类型的文 档都应该遵循统一的书写规范，包括符号的使用、图标的含义、程序中注释行的使用、 注明文档书写人及书写日期等。例如，在程序的开始要用统一的格式包含程序名称、程 序功能、调用和被调用的程序、程序设计人等。

图标编号规则

在管理信息系统的开发过程中用到很多的图表，对这些图表进行有规则的编号，可 以方便图表的查找。图表的编号一般采用分类结构。根据生命周期法的5 个阶段，可以 给出图I5-I 所示的分类编号规则。根据该规则，就可以通过图表编号判断该图表出于系 统开发周期的哪一个阶段，属于哪一个文档，文档中的哪一部分内容及第几张图表。 第5、6 位，流水码 第3、4 位，文档内容 第2 位，各阶段的文档 第1 位，生命周期法各阶段 图15-1 图表编号规则

文档目录编写标准

为了存档及未来使用的方便，应该编写文档目录。管理信息系统的文档目录中应包 含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、 保管人等。文档编号一般为分类结构，可以采用同图表编号类似的编号规则。文档名称 要书写完整规范。格式或载体指的是原始单据或报表、磁盘文件、磁盘文件打印件、大 型图表、重要文件原件、光盘存档等。

文档管理制度

为了更好地进行信息系统文档的管理，应该建立相应的文档管理制度。文档的管理 制度需根据组织实体的具体情况而定，主要包括建立文档的相关规范、文档借阅记录的 登记制度、文档使用权限控制规则等。建立文档的相关规范是指文档书写规范、图表编 号规则和文档目录编写标准等。文档的借阅应该进行详细的记录，并且需要考虑借阅人 是否有使用权限。在文档中存在商业秘密或技术秘密的情况下，还应注意保密。

配置管理

配置管理有关概念

配置项

IEEE 对配置项的定义为“硬件、软件或二者兼有的集合，为配置管理指定的，在配 置管理过程中作为一个单独的实体对待。 以下内容都可以作为配置项进行管理：外部交付的软件产品和数据、指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具、供方，供应商提供的软 件和客户提供的设备，软件。典型配置项包括项目计划书、需求文档、设计文档、源代码、 可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入软件配置管理

配置库

配置库是一组受控制的、辅助软件开发、使用和维护的软件及相关的文档 (IEEE610.12-90)，它在软件发布管理和交付活动中，起着器械性的作用。

配置管理活动和流程

配置活动和流程主要包括制定配置管理计划、配置识别与建立基线、建立配置 管理系统、版本管理、配置状态报告和配置审计。

配置管理系统

软件配置管理系统是软件工程化的重要组成部分。目的是通过确定软件配置管理细 则和提供规范的软件配置项管理软件系统，加强软件研制过程的质量控制，增强软件研 制过程的可控性．确保软件配置管理项（包括各种文档、数据和程序）的完备、清晰、 一致和可追踪性，以及技术状态的可控制性。

基线

一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷 和用户文档构成一条基线。基线一经放行，就可以作为从配置管理系统检索源代码文卷 （配置项）和生成可执行文卷的工具。 在建立基线之前，工作产品的所有者能快速、非正式地对工作产品做出变更。但基 线建立之后，变更要通过评价和验证变更的正式程序来控制。

配置管理计划

配置管理计划编制工作的基本步骤

为给定项目制订软件配置管理过程计划时，应该与组织的上下文、可应用的约束、 普遍接受的指南、项目的本质（例如规模和关键性）保持一致。覆盖的主要活动包括软 件配置标识、软件配置控制、软件配置状态报告、软件配置审计、软件发布管理与交付。另外，一般还要考虑一些问题，例如组织与责任、资源与进度、工具选择与实现、销售 商与子合同控制、接口控制等。制订计划活动的结果记录在软件配置管理计划中，它要接受软件质量保证的评审和审计。

配置管理计划的主要内容

配置管理计划的主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付 计划、备份计划、配置审计和评审、变更管理等。变更管理委员会(Change Control Board， CCB)审批该计划。

配置识别与建立基线

配置识别的基本步骤

配置识别是“配置管理的一个要素，包括选择一个系统的配置项和在技术文档中记 录配置项的功能和物理特性。”[见IEEE-610 文本】 配置识别是配置管理员的职能，包括如下内容。 (1)识别需要受控的软件配置项。 (2)给每个产品和它的组件及相关的文档分配唯一的标识。 (3)定义每个配置项的重要特征以及识别其所有者。 (4)识别组件、数据及产品获取点和准则。 (5)建立和控制基线。 (6)维护文档和组件的修订与产品版本之间的关系。 所有配置项都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定 章节（部分）记录对象的标识信息。在引入软件配置管理工具进行管理后，这些配置项 都应以一定的目录结构保存在配置库申。所有配置项的操作权限应由CMO（配置管理 员）严格管理，基本原则是：基线配置项向软件开发人员开放读取的权限；非基线配置 项向PM、CCB 及相关人员开放。

建立基线的目的及其在项目实施中的应用

配置项的识别是配置管理活动的基础，也是制定配置管理计划的重要内容。软件配 置项分类软件的开发过程是一个不断变化着的过程，为了在不严重阻碍合理变化的情况 下来控制变化，软件配置管理引入了“基线”这一概念。根据这个定义，我们在软件的 开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类，例如，基 线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划 和报告等。 对于每一个基线，要定义下列内容：建立基线的事件、受控的项、建立和变更基线的程序、批准变更基线所需的权限。在项目实施过程中，每个配置项的基线都要纳入配 置控制，对这些基线的更新只能采用正式的变更管理过程。这确保了基线的变更只反映 已批准的组件部分的变更。

建立配置管理系统

建立配置管理方案的基本步骤

组建配置管理方案构造小组

配置管理过程构造小组应该包括如下成员。 ④小组负责人。其对整个构造过程负责。主要职责是协调与其他部门或与上级主 管的关系，监督工作进程，协调小组内部关系。 ②技术支持专家。其负责在技术、设备方面为本组提供支持和服务，井负责本组 同其他部门就技术问题进行联络，如了解相关项目情况、开发环境和开发人员状况等。 ③配置管理技术专家。其对配置管理过程的构造和配置管理工具十分熟悉。主要 任务是指导配置管理过程的构造，帮助制订配置管理规章，负责对开发人员进行配置管 理工具的培训。通常由配置管理工具提供商或专门的配置管理顾问机构的人员担当此任。 ④配置管理系统用户代表。他们是从将来要在实际的项目开发过程中使用该系统、 遵循该过程的开发人员中挑选出来的。他们负责从构造初期了解配置管理系统和规程， 根据开发羟验协助制订、修改配置管理规程，并在试验项目中担任部分开发角色。这部 分成员应包括软件开发项目经理、设计人员、编码、测试和构造、发布人员。该项目小 组成立后，将按后述步骤开展配置管理过程的构造工作。

对目标机构进行评估

目标机构的调查评估工作由配置管理技术专家领导，配置管理系统用户代表参与， 提供基本信息，并由小组负责人协调，对相关部门人员进行深入调查获得较全面的数据。 对目标机构的了解、评估应从人员、技术、工作流程、现有项目和期望值几方面入手。

配置管理工具及其提供商评估

通过对组织的评估，了解该组织的现状和需求后，就需要选择适合该组织的配置管 理工具。市场上现有的配置管理工具不下数十种，它们各有所长，在功能、性能等方面 有较大的差别，只有对产品及其提供商进行仔细地分析评估，核对目标机构的需求，才 能挑选出合适的工具，实现一个理想的配置管理过程。这种评估可从三个方面进行：配 置管理工具的评估、供应商评估和其他用户使用经验的评估。

制定实施计划

实施计划由如下部分组成；必要性和影响因素、人员组织和分工、进度计划和风险 管理。

定义配置管理流程

制订配置管理流程的方法是：通过对目标机构的调查、评估，定义现有的配置管理 流程，由配置管理技术专家对它进一步分析，结合常规的配置管理方法制订出新的流程。 之后，依据选定的配置管理工具的功能，将新流程中可自动化的环节交由配置管理工具 处理，其他环节由新制订的配置管理规范控制。除了制订配置管理规范外，该小组还应 制订出适合目标机构的配置管理基本章程。该章程应包括配置管理部门的设立、该部门 的职能（通常是负责监督配置管理规范的执行情况，对配置规范进行完善，并担当日常 的内部配置管理过程支持任务），定义配置管理过程与开发过程的协调关系，以及各开发 阶段的开发人员构成、在配置管理流程中的责任划分等。 一般来说，配置管理包括配置项标识，配置项控制（修改控制）、配置状态报告和配 置审计4 个方面的活动。配置管理规范的制订也应按这4 个方面内容进行。每一个方面 要考虑的问题如下。 ①配置项标志制订文档或文件编号、标记体系，定义文档和文件之间昀联系。 ②确定受控的配置项的取舍，如软件源码、硬件描述文件、中间文件、目标文件、 测试方案和系统数据等。确定产品版本、基线的标志体系。 ③确定库程序的标志和管理机制。配置项控制确定产品版本的演化策略，规定何 时、何人创建新的基线，如何创建。确定修改变更控制委员会的人员组成、职能和工作 程序。 ④确定修改请求的处理流程和终止条件。 ⑤确定修改请求处理过程中各开发人员的职能。确定修改请求和所生成结果的对 应机制。 ⑥确定文档的修改方式。 ⑦确定配置项的提取方式。配置状态报告定义报告的内容、形式和提交方式。 ⑧确定产品的发行事宜，包括发行时间如何确定、发行说明的生成发布方式及发 行方式等。配置审计确定审计的执行人员、执行时机，审计的内容和方式。 ⑨确定发现问题后的处理方法。

实验项目的实施

这一阶段的任务是选取目标机构中的一个现有项目，按既定的配置管理流程进行开 发和配置管理工作。这种试验的目的是在一定风险范围内，通过实地运作来确定所选配 置管理工具、所制订的配置管理规范是否能满足目标机构的需要。

全面实施

经过试验项目证实、校正后的配置管理流程就可以在目标机构的各个项目、各个相 关工作环节中去应用、实施，最终使醌置管理过程日常化、规范化。全面实施过程主要由配置管理部门根据新的配置管理流程来指导。配置管理过程构造小组的作用趋于浈化， 主要起监督和支持作用。该小组在全面实施过程中逐步解散，小组中部分成员可转移到 配置管理部门中去。

建立配置库

配置库的类型

配置库可以分为动态库（开发库、程序员库、工作痒）、受控库（主库）、静态库（软 件仓库）和备份库4 种类型。 (l)动态库。也称为开发库、程序员库或工作库，用于保存开发人员当前正在开发 的配置实体。动态库通常包括新模块、文档、数据元素或进行修改的已有元素。动态库 是软件工程师的工作区，由工程师控制。 (2)受控库。也称为主库或系统库，是用于管理当前基线和控制对基线的变更。受 控库包括配置单元和被提升并集成到配置项中的组件。软件工程师和其他人员可以自由 地复制受控库中的单元或组件。然而，必须有适当的权限授权变更。受控库中的单元或 组件用于创建集成、系统和验收测试或对用户发布的构建， (3)静态库。也称为软件仓库或软件产品库，用于存档各种广泛使用的已发布的基 线。静态库用于控制、保存和检索主媒介。 (4)备份库。包括制作软件和相关构架、数据和文档的不同版本的复制品。在各点 的及时备价，可以每天、每周或每月执行备份。

配置库的建库模式

决定配置库的结构是配置管理活动的重要基础。一般常用的是两种组织形式：按配 置项类型分类建库和按任务建库。 按配置项的类型分类建库的方式经常被一些咨询服务公司所推荐，它适用于通用的 应用软件开发组织。这样的组织，往往产品的继承性较强，工具比较统一，对并行开发 有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编 译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可 能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。 而接任务建立相应的配置库，则适用于专业软件的研发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格地分 类存储，人为增加目录的复杂性。因此，对于研发性的软件组织来说，还是采用这种设 置策略比较灵活。

用于建立配置库的工具

可以用vss、cvs 等工具建立配置库，进行选择时考虑以下内容。 (1)所支持的组件类型。工具是否支持文档（文本）、代码（源代码、目标代码和 可执行文件）、图解的表示和数据。 (2)版本策略。用于维护版本历史的方法是什么。 (3) SCM 模型。模型是否仅基于源文件修改或者关注版本、基线和软件工程学范例。 (4)数据管理。如何存储配置实体。 (5)系统生成什么类型的报告。 (6)用户界面和查询能力。系统是否有易用和健壮的用户界面？有哪种类型的信息 查询可供使用，是否易用。 (7)可追溯性。将一个配置实体和其他实体联系是否容易。 (8)自动构建方法。当发生变更时，使用什么技术来创建新的版本。 (9)安全性。使用什么机制来控制配置实体的存取。 (10)测试管理。能否使用工具管理测试用例和测试结果。 (1])定制化管理。能否定制这个工具以满足本土化的SCM 过程和需要。 (12)集成。这个工具是否能和其他的SCM 工具集成，或者这个工具是否能和连接 SCM 环境的工具集成。

版本管理

配置项状态变迁规则

配置项的状态可分为“草稿”、“正式”和“修改”三种。配置项刚建立时，其状态 为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变 为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。

配置项版本号标识

配置顼的版本号规则与配置项的状态相关。 (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)。

配置项版本控制

配置项的版本控制作用于多个配置管理活动之中，如创建配置项、配置项的变更和配置项的评审等。在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终 确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本控制的目的是按照一定的规则保存配置项的所有 版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

变更控制

变更申请

相关人员如项目经理填写变更申请表，说明要变更的内容、变更的原因、受变更影 响的关联配置项、工作量和变更实施人等，并提交给CCB。

变更评估

CCB 负责组织对变更申请进行评估并确定以下内容。 (1)变更的内容是否合理。 (2)变更的范围是否正确、考虑周全。 (3)受影响的配置项是否已被充分考虑，是否需要同时进行变更。 (4)工作量估计是否合理。 (5)如有变更实箍方案，评估基线变更的实施方案是否合理。 根据变更影响大小，可以由CCB 组长确定由哪些人参如此评估。 CCB 决定是否接受变更，并将决定通知相关人员。

变更实施

CM工程师在测试库或开发库中开辟工作空间，从受控库中取出相关的配置项放于 工作空间，分配权限给变更实施人。 项目经理组织修改相关的配置项，并在相应的文档或程序代码中记录变更信息，同 时填写报告。 变更实施人完成变更并提交后，项目经理指派其他的人员完成单元测试／代码走查。

变更验证与确认

项目经理指定人员对变更后的配置项进行测试或验证，如走查、评审，填写相应 报告。 项目经理应将变更与验证的结果提交CCB 组长审批，由其确认变更是否已经按要 求完成。如果是基线变更，必要时CCB 组长应召集CCB 会议确认基线变更的结果。

变更的发布

配置管理员将变更内容和结果通知相关人员，并做好记录。

配置状态报告

配置状态报告的内容

配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情 况。这样的报告应该是定期进行，并尽量通过CASE 工具自动生成，用数据库中的客观 数据来真实地反映各配置项的情况。 配置状态报告应该跟踪以下方面：产品描述记录、每个受控软件组件的状态、每个 构建版发布的内容和状态、每个基线的内容、配置验证记录、变更状态记录（缺陷和改 进）和所有位置的所有配置项的安装状态。

状态说明

配置状态报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。 为了说明项目状态对变更的情况，也应当进行报告。有时，对配置库的情况也进行说明， 例如备份次数，磁盘占用空问等。只要是关心的信息，均可作为状态报告的内容。这些 信息进行育效记录，往往可以作为项目度量的重要数据来源。

配置审计

实施配置审计的作用

配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现

功能配置审计

功能配置审计是进行审计以验证以下几个方面。 ’ (l)配置项的开发已圆满完成。 (2)配置项已达到规定的性能和功能特定特性。 (3)配置项的运行和支持文档已完成并且是符合要求的。【见IEEE-610 文本】 功能配置审计可以包括按测试数据审计正式测试文档、审计验证和确认报告、评审 所有批准的变更、评审对以前交付的文档的更新、抽查设计评审的输出、对比代码和文 档化的需求、进行评审以确保所有测试已执行。 功能配置审计还可以包括依据功能和性能需求进行额外的和抽样的测试。

物理配置审计

物理配置审计是进行审计以验证如下方面。 (1)每个构建的配置项符合相应的技术文档。 (2)配置项与配置状态报告中的信息相对应。 物理配置审计可以包括审计系统规格说明书的完整性、审计功能和审计报告、了解 不符合采取的措施、对比架构设计和详细设计组件的一致性、评审模块列表以确定符合 己批准的编码标准、审计手册（如用户手册、操作手册）的格式、完整性和与系统功能 描述的符合性等。

第十四章 项目采购管理

第十四章项目采购管理