加速更新中ing~~~~

第13章 项目合同管理

13.1 合同管理相关基础概念

13.1.1 合同的类型

0. 按项目范围划分：项目总承包合同、项目单项承包合同、项目分包合同

• 项目总承包合同：买方将项目的全过程作为一个整体发包给同一个卖方的合同。采用总承包合同的方式一般适用于经验丰富、技术实力雄厚且组织管理协调能力强的卖方，这样有利于发挥卖方的专业优势，保证项目的质量和进度，提高投资效益。采用这种方式，买方只需与一个卖方沟通，容易管理与协调。
• 项目单项承包合同：一个卖方只承包项目中的某一项或某几项内容，买方分别与不同的卖方订立项目单项承包合同。采用项目单项承包合同的方式有利于吸引更多的卖方参与投标竞争，使买方可以选择在某一单项上实力强的卖方。同时也有利于卖方专注于自身经验丰富且技术实力雄厚的部分的建设，但这种方式对于买方的组织管理协调能力提出了较高的要求。
• 项目分包合同： 经合同约定和买方认可，卖方将其承包项目的某一部分或某几部分项目(非项目的主体结构)再发包给具有相应资质条件的分包方，与分包方订立的合同称为项目分包合同。其中订立项目分包合同必须同时满足以下5个条件： ① 经过买方认可 ② 分包的部分必须是项目非主体工作 ③ 只能分包部分项目，而不能转包整个项目 ④ 分包方必须具备相应的资质条件 ⑤ 分包方不能再次分包。

2. 按项目付款方式划分：可将合同分为两大类:即总价和成本补偿类。还有第三种常用合同类型，即混合型的工料合同。
3. 总价合同

• 固定总价合同：（买方喜欢），价格在一开始就被确定，并且不允许改变，成本增加都由卖方承担。
• 总价加激励费用合同：允许有一定的绩效偏差，并对实现既定目标给予财务奖励，要设置一个价格上限，卖方必须完成工作并且要承担高于上限的全部成本。
• 总价加经济价格调整合同：卖方履约要跨越相当长的周期（数年）、维持多种长期关系。
• 订购单：当非大量采购标准化产品时，通常可以由买方直接填写卖方提供的订购单，卖方照此供货。由于订购单通常不需要谈判，所以又称为单边合同。

4. 成本补偿合同

成本补偿合同向卖方支付为完成工作而发生的全部合法实际成本(可报销成本)，外加一笔费用作为卖方的利润。成本补偿合同也可为卖方超过或低于预定目标而规定财务奖励条款。在这种合同下，买方的成本风险最大。这种合同适用于买方仅知道要一个什么产品但不知道具体工作范围的情况，也就是工作范围很不清楚的项目。当然，成本补偿合同也适用于买方特别信得过的卖方，想要与卖方全面合作的情况。其又可分为：

• 成本加固定费用合同：为卖方报销履行合同工作所发生的一切合法成本（即成本实报实销），并向卖方支付一笔固定费用作为利润。
• 成本加激励费用合同：为卖方报销履行合同工作所发生的一切合法成本（即成本实报实销），并在卖方达到合同规定的绩效目标时，向卖方支付预先确定的激励费用。
• 成本加奖励费用合同：为卖方报销履行合同工作所发生的一切合法成本（即成本实报实销），买方再凭自己的主观感觉给卖方支付一笔利润。

5. 工料合同

又称为单价合同，计划价格*实际量（量实报实销，激发积极性）。

工料合同是指按项目工作所花费的实际工时数和材料数，按事先确定的单位工时费用标准和单位材料费用标准进行付款。这类合同适用于工作性质清楚，工作范围比较明确，但具体的工作量无法确定的项目。工料合同在金额小、工期短、不复杂的项目上可以有效使用，但在金额大、工期长的复杂项目上不适用。

6. 合同类型的选择

• (1)如果工作范围很明确，且项目的设计已具备详细的细节，则使用总价合同。
• (2)如果工作性质清楚，但范围不是很清楚，而且工作不复杂，又需要快速签订合同，则使用工料合同。
• (3)如果工作范围尚不清楚，则使用成本补偿合同。
• (4)如果双方分担风险，则使用工料合同; 如果买方承担成本风险，则使用成本补偿合同; 如果卖方承担成本风险，则使用总价合同。
• (5)如果是购买标准产品，且数量不大，则使用单边合同

13.1.2 合同的内容

项目合同的内容应包括以下各项：

(1)项目名称 (2)标的内容和范围 (3)项目的质量要求 (4)项目的计划、进度、地点、地域和方式。 (5)项目建设过程中的各种期限 (6)技术情报和资料的保密 (7)风险责任的承担 (8)技术成果的归属 (9)验收的标准和方法 (10)价款、报酬(或使用费)及其支付方式 (11)违约金或者损失赔偿的计算方法 (12)解决争议的方法 (13)名词术语解释

13.2 合同管理过程

合同管理包括：合同签订管理、合同履行管理、合同变更管理、合同档案管理、合同违约索赔管理。

13.2.1 合同的签订管理

为了使签约各方对合同有一致理解，建议如下：

（1）使用国家或行业标准的合同格式。 （2）为避免因条款的不完备或歧义而引起合同纠纷，因此在达成交易和签订合同前，有必要使双方进一步对他们所同意的条款有一致的认识。对合同标的的描述务必要达到准确、简练、清晰的标准要求，切忌含混不清。例如：

• 对合同标的为设备买卖的，一定要写明设备的名称、品牌、计量单位和价格，切忌只写“购买计算机一台”之类的描述。
• 对合同标的是提供服务的，一定要写明服务的质量、标准或效果要求等，切忌只写“按照行业的通常标准提供服务或达到行业通常的服务标准要求等”之类的描述。

（3）对合同中质量条款应具体写清规格、型号、适用的标准等，避免合同订立后因为适用标准是采用国际、国家、地方、行业还是其他标准等问题产生纠纷。 （4）对于合同中需要变更、转让、解除等内容也应详细说明。 （5）如果合同有附件，对于附件的内容也应精心准备，并注意保持与主合同一致，不要相互之间产生矛盾。 （6）对于既有投标书，又有正式合同书、附件等包含多项内容的合同，要在条款中列明适用顺序。 （7）为避免合同纠纷，保证合同订立的合法性、有效性，当事人可以将签订的合同到公证机关进行公证。 （8）避免方案变更导致工程变更，从而引发新的误解 （9）注意合同内容的前后一致性

13.2.2 合同的履行管理

合同当事人之间无法就某一事项协商达成一致意见，该事项就成为一个争议事项。解决争议的方法主要有替代争议解决方法（包括调解、仲裁等）和诉讼。在解决合同争议的方法中，其优先顺序为谈判（协商）、调解、仲裁、诉讼。

13.2.3 合同的变更管理

一般具备以下条件才可以变更合同：

① 双方当事人协商，并且不因此而损坏国家和社会利益。 ② 由于不可抗拒力导致合同义务不能执行。 ③ 由于另一方在合同约定的期限内没有履行合同，并且在被允许的推迟履行期限内仍未履行

项目合同的变更给另一方当事方造成损失的，除依法可以免责的以外，应由责任方负责赔偿。当事人一方要求修改合同时，应当首先向另一方用书面的形式提出。另一方当事人在接到有关变更项目合同的申请后，应及时做出书面答复。如果同意变更，即表明合同的变更发生法律效力。

13.2.4 合同的档案管理

合同档案管理（文本管理）是整个合同管理的基础。合同档案管理还包括正本和副本管理、合同文件格式等内容。在文本格式上，为了限制执行人员随意修改合同，一般要求采用电脑打印文本，手写的旁注和修改等不具有法律效力。

13.2.5 合同违约索赔管理

优先顺序为谈判（协商）、调解、仲裁、诉讼索赔和反索赔统称为合同索赔。（索赔就是乙方向甲方提出的，就叫做索赔，甲方向乙方提出的，就叫做反索赔）

1. 索赔的概念与分类

（1）按索赔的目的分类：可分为工期索赔和费用索赔。（性质：经济补偿，非惩罚）

（2）按索赔的依据分类：合同规定的索赔、非合同规定的索赔

（3）按索赔的业务性质分类：工程索赔、商务索赔

（4）按索赔的处理方式分类：单项索赔、总索赔

2. 索赔的起因和原则

3. 合同索赔流程

项目发生索赔事件后，一般先由监理工程师调解，若调解不成，由政府建设主管机构进行调解，若仍调解不成，由经济合同仲裁委员会进行调解或仲裁。在整个索赔过程中，遵循的原则是索赔的有理性、索赔依据的有效性、索赔计算的正确性。索赔具体流程如下：

(1) 提出索赔要求。当出现索赔事项时，索赔方以书面的索赔通知书形式，在索赔事项发生后的28天以内，向监理工程师正式提出索赔意向通知。 (2) 报送索赔资料。在索赔通知发出后的28天内，向监理工程师提出延长工期和(或)补偿经济损失的索赔报告及有关资料。 (3) 监理工程师答复。监理工程师在收到送交的索赔报告有关资料后，于28天内给予答复，或要求索赔方进一步补充索赔理由和证据。 (4) 监理工程师逾期答复后果。监理工程师在收到承包人送交的索赔报告的有关资料后28天未予答复或未对承包人作进一视为该项索赔已经认可。 (5) 持续索赔。当索赔事件持续进行时，索赔方应当阶段性向监理工程师发出索赔意向，在索赔事件终了后28天内，向监理工程师送交索赔的有关资料和最终索赔报告，监理工程师应在28天内给予答复或要求索赔方进一步补充索赔理由和证据。逾期未答复，视为该项索赔成立。 (6) 仲裁与诉讼。监理工程师对索赔的答复，索赔方或发包人不能接受，即进入仲裁或诉讼程序。（涉及到的时间是28天）

4. 合同解释的原则

① 主导语言原则。当两者不一致时，应该以主导语言文本为准。 ② 适用法律原则。合同中应该规定以哪个国家的法律作为合同的适用法律，合同的解释必须根据适用法律进行。 ③ 整体解释原则。特殊条件优先于一般条件，具体规定优先于笼统规定，手写条文优先于印刷条文，单价优先于总价，价格的文字表达优先于阿拉伯数字表达，技术规范优先于图纸。 ④ 公平诚信原则。如果按整体解释原则进行解释后仍含糊不清，则可按不利于合同起草一方（一般为买方）

第14章 信息文档管理与配置管理

14.1 信息系统项目文档及其管理

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

0. 软件文档一般分为三类：开发文档、产品文档、管理文档

（1）开发文档描述开发过程本身，基本的开发文档包括：

• 可行性研究报告和项目任务书
• 需求规格说明
• 功能规格说明
• 设计规格说明，包括程序和数据规格说明
• 开发计划
• 软件集成和测试计划
• 质量保证计划
• 安全和测试信息

（2）产品文档描述开发过程的产物，基本的产品文档包括：

• 培训手册
• 参考手册和用户指南
• 软件支持手册
• 产品信息和信息广告

（3）管理文档记录项目管理的信息

• 开发过程的每个阶段的进度和进度变更的记录
• 软件变更情况记录
• 开发团队的职责定义
• 项目计划、项目阶段报告
• 配置管理计划

2. 文档质量等级可以分为四级：

（1）最低限度文档（1级文档）

适合开发工作了低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介

（2）内部文档（2级文档）

可用于没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。

（3）工作文档（3级）

适用于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。

（4）正式文档（4级文档）

适合要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（如工资计算）的程序需4级文档。四级文档遵守GB8567的有关规定。

14.2 配置管理

配置管理定义：应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报 告变更处理和实现状态并验收与规定的需求遵循性。

配置管理包括6个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付

14.2.1 配置管理的概念

1. 配置项

典型的配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。

※ 另外，测试报告、会议纪要、工作记录不计入配置项的内容，这些文档一经形成不再修改。

配置项可以分为基线配置项和非基线配置项两类，例如：

基线配置项可能包括所有的设计文档和源程序等； 非基线配置项可能包括项目的各类计划和报告等；

所有配置项的操作权限应由CMO严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。

2. 配置项的状态

配置项的状态可分为“草稿”、“正式”和“修改”三种

• 配置项刚建立时，其状态为草稿；
• 配置项通过评审后，其状态为正式；
• 此后若更改配置项，则其状态变为修改。
• 当配置项修改完毕并重新通过评审时，其状态又变为正式。

3. 配置项版本号

配置项的版本号规则与配置项状态相关。

1）处于“草稿”状态的配置项的版本号格式为0.YZ，YZ的数字范围为01～99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。

2）处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1～9。Y为次版本号，取值范围为0～9。

配置项第一次成为“正式”文件时，版本号为1.0。

如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本一次为1.0，1.1，…。当附件的变动积累到一定程度时，配置项的Y值可适量增加，Y值增加一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增大X值。

3）处于“修正”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值。参见上述规则2）

4. 配置项版本管理

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

5. 配置基线

配置基线（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。 一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。产品的一个测试版本(可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等)是基线的一个例子。 ​ 基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线，内部开发使用的基线一般称为构造基线。 ​ 对于每一个基线，定义的内容:建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。项目实施过程中，每个基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。

6. 配置库

配置库可以分为：DL开发库、CL受控库、PL产品库三种类型

• DL-开发库：也称为动态库、程序员库、工作库。用于保存开发人员当前正在开发的配置实体，如：新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被至于版本管理之下，由开发人员自行控制，库中的信息可能有较为频繁的修改，无需进行配置控制，可以任意修改。
• CL-受控库：也称为主库。包含当前的基线加上对基线的变更，受控库中的配置项被置于完全的配置管理之下。在先息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。可以修改，需要走变更流程。
• PL-产品库：也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。一般不再修改，真要修改的话需要走变更修成。

配置库的建库模式有两种：按配置项类型建库和按任务建库

• 按配置项的类型分类建库，适用于通用软件的开发组织；使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。
• 按开发任务建立相应的配置库，适用于专业软件的开发组织。

7. 配置库权限设置

8. 配置控制委员会

配置控制委员会（CCB），负责对配置变更做出评估、审查以及监督已批准变更的实施。CCB的成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。CCB不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的CCB。对于小的项目，CCB可以只有一个人，甚至只是兼职人员。 ​ 通常，CCB不只是控制配置变更，而是负有更多的配置管理任务，例如:配置管理计划审批、基线设立审批、产品发布审批等。

9. 配置管理员

配置管理员（CMO），负责在整个项目生命周期中进行配置管理活动，具体活动内容：

• 编写配置管理计划
• 建立和维护配置管理系统
• 建立和维护配置库
• 配置项识别
• 建立和管理基线
• 版本管理和配置控制
• 配置状态报告
• 配置审计
• 发布管理和交付
• 对项目成员进行配置管理培训

14.2.2 配置管理的目标和方针

1. 确定配置管理目标

软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。高级项目经理应确保以下配置管理目标得以实现：

• 确保软件配置管理计划得以制订，并经过相关人员的评审和确认
• 应该识别出要控制的项目产品有哪些，并且制订相关控制策略，以确保这些项目产品被合适的人员获取。
• 应制定控制策略，以确保项目产品在受控制范围内更改
• 应该采取适当的工具和方法，确保相关组别和个人能够及时了解到软件基线的状态和内容。

14.2.3 日常配置管理活动

1. 制定配置管理计划

配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础。配置管理计划由配置管理员制定，配置控制委员会负责审批该计划。其主要内容为：

• 配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付。
• 实施这些活动的规范和流程。
• 实施这些活动的进度安排。
• 负责实施这些活动的人员或组织，以及他们和其他组织的关系。

2. 配置标识

配置标识也称配置识别，包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征。配置标识是配置管理员的职能，基本步骤如下：

（1）识别需要受控的配置项。

（2）为每个配置项指定唯一性的标识号。

（3）定义每个配置项的重要特征。

（4）确定每个配置项的所有者及其责任。

（5）确定配置项目进入配置管理的时间和条件。

（6）建立和控制基线。

（7）维护文档和组件的修订与产品版本之间的关系。

3. 配置控制

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

某软件产品升级流程：

① 将待升级的基线(假设版本号为V2.1)从产品库中取出，放入受控库。 ② 程序员将欲修改的代码段从受控库中检出(Checkout) ，放入自己的开发库中进行修改。代码被Checkout后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Checkout。 ③ 程序员将开发库中修改好的代码段检入(Checkin)受控库。Checkin后，代码的“锁定”被解除，其他程序员可以Checkout该段代码了。 ④ 软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中(软件产品的版本号更新为V2.2,旧的V2.1版并不删除，继续在产品库中保存)。

4. 配置状态报告

配置状态报告也称配置状态统计，其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。其应该包含以下内容：

• 每个受控配置项的标识和状态。一旦配置项被置于控制下，就应该记录和保存其每个后续进展的版本和状态。
• 每个变更申请的状态和已批准的修改的实施状态。
• 每个基线的当前和过去版本的状态以及各版本的比较。
• 其他配置管理过程活动的记录。

配置状态报告应着重反映当前基线配置项的状态，以向管理者报告系统开发活动的进展情况。配置状态报告应定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实地反映各配置项的情况。

5. 配置审计

配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。其作用是：

• 防止向用户提交不适合的产品，如交付了用户手册的不正确版本。
• 发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。
• 找出各配置项间不匹配或不相容的现象。
• 确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。
• 确认记录和文档保持这可追溯性。

功能配置审计是审计配置项的一致性（配置项的实际功效是否与其需求一致），具体验证以下几个方面

• 配置项的开发已圆满完成。
• 配置项已达到配置标识中规定的性能和功能特征。
• 配置项的操作和支持文档已完成并且是符合要求的。

物理配置审计是审计配置项的完整性（配置项的屋里存在是否与预期一致）：具体验证以下几个方面：

• 要交付的配置项是否存在
• 配置项中是否包含了所有必需的项目。

6. 发布管理和交付

发布管理和交付活动的主要任务是：有效控制软件产品和文档的发行和交付，在软件产品的生存期内妥善保存代码和文档的母拷贝。

• 存储。
• 复制。
• 打包。应确保按批准的规程制备交付的介质。应在需方容易辨认的地方清楚标出发布标识。
• 交付。供方应按合同中的规定交付产品或服务。
• 重建。应能重建软件环境，以确保发布的配置项在所保留的先前版本要求的未来一段时间里是可重新配置的。

欢迎您的关注与私信~~~~~~

希望可以帮助到您