买方将项目的全过程作为一个整体发包给同一个卖方的合同。需要特别注意的是，总承包合同要求只与同一个卖方订立承包合同，但并不意味着只订立一个总合同。可以采用订立一个总合同的形式，也可以采用订立若干个合同的形式。

• 采用总承包合同的方式一般适用于经验丰富、技术实力雄厚且组织管理协调能力强的卖方，这样有利于发挥卖方的专业优势，保证项目的质量和进度，提高投资效益。
• 采用这种方式，买方只需与一个卖方沟通，容易管理与协调

单项承包合同

--1对多，一个甲方分别对多个乙方，项目要集成要控制要协调

一个卖方只承包项目中的某一项或某几项内容，买方分别与不同的卖方订立项目单项承包合同。

采用项目单项承包合同的方式有利于吸引更多的卖方参与投标竞争，使买方可以选择在某一单项上实力强的卖方。同时也有利于卖方专注于自身经验丰富且技术实力雄厚的部分的建设，
但这种方式对于买方的组织管理协调能力提出了较高的要求。

经合同约定和买方认可，卖万将其承包项目的一部分或几部分项目( 非项目的主体结构)再发包给具有相应资质条件的分包方，与分包方订立的合同称为项目分包合同。

需要说明的是，订立项目分包合同必须同时满足5个条件，即:

• 经过买方认可。
• 分包的部分必须是项目非主体工作。
• 只能分包部分项目，而不能转包整个项目。
• 分包方必须具备相应的资质条件。
• 分包方不能再次分包。

卖方在原承包合同范围内向买方负责，而分包方与卖方在分包合同范围内向买方承担连带责任。如果分包的项目出现问题，买方既可以要求卖方承担责任，也可以直接要求分包方承担责任。//这个除非是三方合同，否则比较难以实现

总价合同--

风险乙方大

要求准确定义要采购的产品或服务，工作范围、性质和工作量清楚。

虽然允许范围变更，但通常会导致价格提高。

从付款的类型上来划分，总价合同又可以分为固定总价合同、总价加激励费用合同、总价加经济价格调整合同和订购单。

固定总价合同： --风险在卖方，在乙方；

2)总价加激励费用合同FPIF

总价加激励费用合同(Fixed Price Incentive Fee, FPIF) 为买方和卖方都提供了一定的灵活性，它允许有一定的绩效偏差，并对实现既定目标给予财务奖励。

奖励的计算方法可以有多种，但都与卖方的成本、进度或技术绩效有关。例如，规定目标工期以及提前完工的奖金。绩效目标一开始就要制定好，而最终的合同价格要待全部工作结束后根据卖方绩效加以确定。在FPIF合同中，要设置一个价格.上限(最高限价、天花板价格)，卖方必须完业中作并且要承担高于上限的全部成本，也就是说，买方付款的总数不得超过最高限价。

A项目： 项目总价11万，限价12万；乙方实际花费9万，节省2万，节省部分分摊甲方60%；---------9万+2*0.4=9.8万；

B项目，项目总价11万，限价12万；乙方实际成本高了，全部自己承担，甲方支付12万；

成本补偿合同：---买方风险大，适用范围：产品和服务无法明确定义，工作性质范围和工作量不好定义

成本补偿合同以卖方从事项目工作的实际成本作为付款的基础，即成本实报实销。在这种合同下，买方的成本风险最大。这种合同适用于买方仅知道要一个什么产 品但不知道具体工作范围的情况，也就是工作范围很不清楚的项目。当然，成本补偿合同也适用于买方特别信得过的卖方，想要与卖方全面合作的情况。

成本加固定费用合同(Cost Plus Fixed Fee, CPFF)为卖方报销履行合同工作所发生的一切合法成本(即成本实报实销)，并向卖方支付一笔固定费用作为利润，该费用以项目初始估算成本 (目标成本)的某一百分比计算。

费用只能针对已完成的工作来支付，并且不因卖方的绩效而变化。

除非项目范围发生变更，费用金额维持不变。这是最常用的成本补偿合同，对卖方有--定的制约作用。例如，表13-2是一个成本加固定费用合同的示例。

在CPIF合同下，如果卖方的实际成本低于目标成本，节余部分由双方按--定比例分成(例如，按照80/20的比例分享，即买方80%，卖方20%);如果卖方的实际成本高于目标成本，超过目标成本的部分由双方按比例分担(例如，基于卖方的实际成本，按照20/80的比例分担，即买方20%，卖方80%)。

A项目： 成本9万；节省2万；节省部分40%给乙方；所以9+2*0.4=9.8

B项目： 成本14万，超支3万；超支部分甲方需要支持60%；11万+3*0.6=12.8万；

成本加奖励费用合同(Cost Price Award Fee, CPAF) 为卖方报销履行合同工作所发生的一切合法成本(即成本实报实销)，买方再凭自己的主观感觉给卖方支付一笔利润，完全由买方根据自己对卖方绩效的主观判断来决定奖励费用，并且卖方通常无权申诉。

//奖励甲方定

工料合同， 工作范围和性质清楚，但是工作量不清楚，买方担工作量风险；卖方担单价风险；

工料合同(Time and Material, T&M)是指按项目工作所花费的实际工时数和材料数，按事先确定的单位工时费用标准和单位材料费用标准进行付款。这类合同适用干中作性质清楚，工作范围比较明确，但具体的工作量无法确定的项目。

在这种合同下，买方承担中等程度的成本风险，即承担工作量变动的风险，而卖方则承担单价风险。因此，工料合同在金额小、工期短、不复杂的项目上可以有效使用，但在金额大、工期长的复杂项目.上不适用。

工料合同是兼具成本补偿合同和总价合同的某些特点的混合型合同。在不能很快编写出准确工作说明书的情况下，经常使用工料合同来增加人员、聘请专家以及寻求其他外部支持。这类合同与成本补偿合同的相似之处在于，它们都是开口合同，合同价因成本增加而变化。

在授予合同时，买方可能并未确定合同的总价值和采购的准确数量。因此，如同成本补偿合同，工料合同的合同价值可以增加。很多组织会在工料合同中规定最高价格和时间限制，以防止成本无限增加。另--方面，由于合同中确定了一-些参数，工料合同又与固定单价合同相似。当买卖双方就特定资源类别的价格( 例如，高级工程师的小时费率或某种材料的单位费率)取得一致意见时，买方和卖方就预先设定了单位人力或材料费率(包含卖方利润)。

• 工作范围很明确具体，用总价合同。
• 工作性质清楚，范围不清楚，工作不复杂，又需要快速签订合同，则使用工料合同。
• 如果工作范围不清楚，则使用成本补偿合同。
• 如果双方分担风险，则使用工料合同; 如果买方承担成本风险，则使用成本补偿合同; 如果卖方承担成本风险，则使用总价合同。
• 如果是购买标准产品，且数量不大，则使用单边合同。

合同当事人之间无法就某一事项协商达成一 致意见，该事项就成为一个争议事项。解决争议的方法主要有替代争议解决方法(包括调解、仲裁等)和诉讼。替代争议解决方法由双方共同聘请的第三方提出解决方案;诉讼是向执法机关提出控告、申诉，要求评判曲直是非。

按照惯例，这两种解决方法通常是相互排斥的，即如果约定了仲裁且约
定了仲裁裁决的终局性，就不能向法院诉讼。仲裁是当事人自愿约定的，通常也会约定仲裁裁决具有终局的约束力。
在解决合同争议的方法中，其优先顺序为谈判(协商)、调解、仲裁、诉讼。

1)按索赔的目的分类
按索赔的目的分类，可分为工期索赔和费用索赔。

• 工期索赔就是要求买方延长项目工期,使原规定的完工日期顺延,从而避免违约罚金的发生;
• 费用索赔就是要求买方(或卖方)补偿费用损失，进而调整合同价款。

2)按索赔的依据分类
按索赔的依据分类，可分为合同规定的索赔、非合同规定的索赔。合同规定的索赔是指索赔涉及的内容在合同文件中能够找到依据，买方(或卖方)可以据此提出索赔要求。这种索赔不太容易发生争议;非合同规定的索赔是指索赔涉及的内容在合同文件中没有专门的文字叙述，但可以根据该合同某些条款的含义，推论出一定的索赔权。

3)按索赔的业务性质分类
按索赔的业务性质分类，可分为工程索赔和商务索赔。

• 工程索赔是指涉及项目执行过程中的施工条件、技术、范围等变化引起的索赔，一 般发生频率高，索赔费用大;
• 商务索赔是指在项目执行过程中的设备采购、运输、保管等方面引起的索赔事项。

4)按索赔的处理方式分类
按索赔的处理方式分类，可分为单项索赔和总索赔。

• 单项索赔就是采取一事一索赔的方式，即按每- -件索赔事项发生后，报送索赔通知书，编报索赔报告，要求单项解决支付，不与其他的索赔事项混在一起;
• 总索赔又称为综合索赔或一揽子索赔，即对整个项目中所发生的数起索赔事项，综合在一起进行索赔。

3.合可索赔流程
项目发生索赔事件后，一-般先由监理工程师调解，若调解不成，由政府建设主管机构进行调解，若仍调解不成，由经济合同仲裁委员会进行调解或仲裁。

在整个索赔过程中，遵循的原则是索赔的有理性、索赔依据的有效性、索赔计算的正确性。

索赔具体流程如下。
(1)提出索赔要求。当出现索赔事项时，索赔方以书面的索赔通知书形式，在索赔事项发生后的28天以内，向监理工程师正式提出索赔意向通知。
(2)报送索赔资料。在索赔通知书发出后的28天内，向监理工程师提出延长工期和(或)补偿经济损失的索赔报告及有关资料。索赔报告的内容主要有总论部分、根据部分、计算部分和证据部分。

索赔报告编写的一.般要求如下。
。索赔事件应该真实。
。责任分析应清楚、准确、有根据。
。充分论证事件给索赔方造成的实际损失。
。索赔计算必须合理、正确。
。文字要精炼、条理要清楚、语气要中肯。

(3)监理工程师答复。 监理工程师在收到送交的索赔报告有关资料后，于28天内给予答复，或要求索赔方进一步补充索赔理由和证据。

(4)监理工程师逾期答复后果。监理 工程师在收到承包人送交的索赔报告的有关资料后28天未予答复或未对承包人作进- - 步要求，视为该项索赔已经认可。

(5)持续索赔。当索赔事件持续进行时，索赔方应当阶段性向监理工程师发出索赔意向，在索赔事件终了后28天内，向监理工程师送交索赔的有关资料和最终索赔报告,监理工程师应在28天内给予答复或要求索赔方进-步补充索赔理由和证据。逾期未答复，视为该项索赔成立。.

(6)仲裁与诉讼。监理工程师对索赔的答复，索赔方或发包人不能接受，即进入仲裁或诉讼程序。

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

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

基线通常对应于开发过程中的里程碑(Milestone)， - - 个产品可以有多个基线，也可以只有一个基线。

交付给外部顾客的基线-般称为发行基线(Release)， 内部开发使用的基线一般称为构造基线(Build)。

对于每一个基线，要定义下列内容:建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。

在项目实施过程中，每个基线，都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。

配置库可以分开发库、受控库、产品库3种类型。
(1)开发库(Development Library), 也称为动态库、程序员库或工作库，用于开发人员当前正在开发的配置实体，如:新模块、文档、数据元素或进行修改的已有素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，需对其进行配置控制，因为这通常不会影响到项目的其他部分。

(2)受控库(Controlled Library),也称为主库，包含当前的基线加上对基线的变受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束将当前的工作产品存入受控库。

(3)产品库(Product Library), 也称为静态库、发行库、软件仓库，包含已发不用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系试之后，作为最终产品存入产品库内，等待交付用户或现场安装。

配置控制委员会(Configuration Control Board, CCB)，负责对配置变更做出评估、审批以及监督已批准变更的实施。

CCB建立在项目级，其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。CCB不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的CCB。小的项目CCB可以只有一个人，甚至只是兼职人员。
通常，CCB不只是控制配置变更，而是负有更多的配置管理任务,例如:配置管理计划审批、基线设立审批、产品发布审批等。

负责在整个项目生命周期中进行配置管理活动，具体有:

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

配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。配置控制委员会负责审批该计划。
配置管理计划的主要内容为:
1）覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付。

2）实施这些活动的规范流程
(3)实施这些活动的时间计划。
(4)负责实施这些活动的人员或组织，以及他们和其他组织的关系。

包括下述任务:

• 标识和记录变更申请，
• 分析和评价变更，
• 批准或否决变更申请，
• 变更的实施
• 变更的验证和确认
• 发布已修改的配置项

配置状态报告( Configuration Status Reporting ) : 也称配置状态统计[Configuration Status Accounting],其任务是有效地记录和报告管理配置所需要的信息,目的是及时、准确地给出配置项的当前状况,供相关人员了解,以加强配置管理工作。

配置状态报告应该包含以下内容。
[1]每个受控配置项的标识和状态。一旦配置项被置于配置控制下,就应该记录和保存它的每个后继进展的版本和状态。
[2]每个变更申请的状态和已批准的修改的实施状态。
[3]每个基线的当前和过去版本的状态以及各版本的比较。
[4]其他配置管理过程活动的记录。

配置审计(Configuration Audit)也称配置审核或配置评价，包括功能配置审计和物
理配置审计，分别用以验证当前配置项的一-致性和完整性。配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要
求一-不允许出现任何混乱现象，例如:

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

1)功能配置审计--配置项的一致性---
功能配置审计(Functional Configuration Audit) 是审计配置项的一 致性(配置项的实际功效是否与其需求- -致)，具体验证以下几个方面。

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

2)物理配置审计--验证配置项的完整性
物理配置审计( Physical Configuration Audit)是审计配置项的完整性(配置项的物理存在是否与预期一致)，具体验证如下几个方面。

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

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

[1]存储。

应通过下述方式确保存储的配置项的完整性: 选择存储介质使再生差错或损坏降至最低限度。根据媒体的存储期,以一定频次运行或刷新已存档的配置项。将副本存储在不同的受控场所,以减少丢失的风险。

[2]复制。复制是用拷贝方式制造软件的阶段。
应建立规程以确保复制的一致性和完整性。应确保发布用的介质不含无关项(如软件病毒或不适合演示的测试数据)。应使用适合的介质以确保软件产品符合复制要求,确保其在整个交付期中内容的完整性。

[3]打包。应确保按批准的规程制备交付的介质。应在需方容易辨认的地方清楚标出发布标识。

[4]交付。供方应按合同中的规定交付产品或服务。

[5]重建。应能重建软件环境,以确保发布的配置项在所保留的先前版本要求的未来一段时间里 是可重新配置的。

当事人订立合同，采取要约、承诺方式。

要约是希望和他人订立合同的意思表示，该意思表示应当内容具体确定，表明经受要约人承诺，要约人愿意受该意思表示约束;

• 要约邀请是希望他人向自已发出要约的意思表示，例如寄送的价目表、拍卖公告、招标公告、招股说明书、商业广告等，都是要约邀请。
• 投标人根据招标内容在约定期限内向招标人提交的投标文件，也可以看作是-一种要约。
• 另外，如果商业广告的内容符合要约规定的，则视为要约。

法律分析：

要约，是当事人一方向对方发出的希望与对方订立合同的意思表示。发出要约的一方称要约人，接受要约的一方称受要约人。不一定是甲方或者乙方。

要约邀请，是当事人订立合同的预备行为，只是引诱他人发出要约，不能因相关人的承诺而成立合同。在发出要约邀请以后，要约邀请人撤回其邀请，只要没给相关人造成信赖利益的损失，要约邀请人一般不承担责任，如寄送的价目表、拍卖公告、招标公告、招股说明书、商业广告等为要约邀请。因为要约邀请只是作出希望别人向自己发出要约的意思表示。因此，要约邀请可以向不特定的任何人发出，也不需要在要约邀请中详细表示，无论对于发出邀请人还是接受邀请人，都没有约束力。

要约可以撤回。撤回要约的通知应当在要约到达受要约人之前或者与要约同时到达受要约人。要约可以撤销。撤销要约的通知应当在受要约人发出承诺通知之前到达受要约人。有下列情形之- -的，要约不得撤销:
(1)要约人确定了承诺期限或者以其他形式明示要约不可撤销。
(2)受要约人有理由认为要约是不可撤销的，并已经为履行合同作了准备工作。

有下列情形之一的，要约失效:
(1)拒绝要约的通知到达要约人。
(2)要约人依法撤销要约。
(3)承诺期限届满，受要约人未作出承诺。
(4)受要约人对要约的内容作出实质性变更。

承诺是受要约人同意要约的意思表示。承诺应当以通知的方式作出，但根据交易习惯或者要约表明可以通过行为作出承诺的除外。承诺应当在要约确定的期限内到达要约人。.要约没有确定承诺期限的，承诺应当依照下列规定到达:
(1)要约以对话方式作出的，应当即时作出承诺，但当事人另有约定的除外。
(2)要约以非对话方式作出的，承诺应当在合理期限内到达。

要约以信件或者电报作出的，承诺期限自信件载明的日期或者电报交发之日开始计算。信件未载明日期的，自投寄该信件的邮戳日期开始计算。要约以电话、传真等快速通讯方式作出的，承诺期限自要约到达受要约人时开始计算。

承诺生效时合同成立，承诺通知到达要约人时生效。承诺不需要通知的，根据交易习惯或者要约的要求作出承诺的行为时生效。

承诺可以撤回。撤回承诺的通知应当在承诺通知到达要约人之前或者与承诺通知同时到达要约人。受要约人超过承诺期限发出承诺的，除要约人及时通知受要约人该承诺有效的以外，为新要约。受要约人在承诺期限内发出承诺，按照通常情形能够及时到达要约人，但因其他原因承诺到达要约人时超过承诺期限的，除要约人及时通知受要约人因承诺超过期限不接受该承诺的以外，该承诺有效。

承诺的内容应当与要约的内容- -致。 受要约人对要约的内容作出实质性变更的，为新要约。有关合同标的、数量、质量、价款或者报酬、履行期限、履行地点和方式、违约责任和解决争议方法等的变更，是对要约内容的实质性变更。承诺对要约的内容作出非实质性变更的，除要约人及时表示反对或者要约表明承诺不得对要约的内容作出任何变更的以外，该承诺有效，合同的内容以承诺的内容为准。

企业标准由企业组织制定，并按省、自治区、直辖市人民政府的规定备案。

对已有国家标准、行业标准或者地方标准的，鼓励企业制定严千国家标准行业标准或者地方标准要求的企业标准，在企业内部适用。

强制性标准；推荐性标准。

按照新的采用国际标准管理办法，我国标准与国际标准的对应关系有

• 等同采用(identical, IDT)、等同采用是指技术内容相同，没有或仅有编辑性修改，编写方法完全相对应;
• 修改采用(modified, MOD)、修改采用是指与国际标准之间存在技术性差异，并清楚地标明这些差异以及解释其产生的原因，允许包含编辑性修改;
• 等效采用( equivalent, EQ) 等效采用(修改采用)是指主要技术内容相同，技术上只有很少差异，编写方法不完全相对应;
• 非等效采用(not equivalent, NEQ)非等效采用是指与相应国际标准在技术内容和文本结构.上不同，它们之间的差异没有被清楚地标明。非等效还包括在我国标准中只保留了少量或者不重要的国际标准条款的情况，非等效不属于采用国际标准，

• 《软件工程术语》(GB/T 11457- -2006)、
• 《信息处理数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文件编辑符号及约定》(GB 1526-1989)
• 《信息处理系统计算机系统配置图符号及约定》(GB/T 14085--1993)等标准。

对于配置管理，有以下三种基线:

• 功能基线(最初通过的功能配置);
• 分配基线(最初通过的分配的配置)、
• 产品基线( 最初通过的或有条件地通过的产品配置)。

《信息技术软件生存周期过程》(GB/T 8566-2007)等标准。

《计算机软件文档编制规范》(GB/T 8567- 2006)和

《计算机软件需求规格说明规范》(GB/T 9385- -2008) 等标准。

GB/T 8567- -2006 详细给出了25种文档编制的格式(但在文档的归类中，却只给出了其中的18种文档)，

包括可行性研究(研究)报告、

1. 软件开发计划、
2. 软件测试计划、
3. 软件安装计划、
4. 软件移交计划、
5. 运行概念说明、
6. 系统/子系统需求规格说明、
7. 接口需求规格说明、
8. 系统子系统设计(结构设计)说明、
9. 接口设计说明、
10. 软件需求规格说明、
11. 数据需求说明、
12. 软件(结构)设计说明、
13. 数据库(顶层)设计说明、
14. 软件测试说明、
15. 软件测试报告、
16. 软件配置管理计划、
17. 软件质量保证计划、
18. 开发进度月报、
19. 项目开发总结报告、
20. 软件产品规格说明、
21. 软件版本说明、
22. 软件用户手册、
23. 计算机操作手册、
24. 计算机编程手册。

1. GB/T8567--2006

给出了这25种文件的具体内容，使用者可根据实际情况对该标准进行适当剪裁。
GB/T 8567- -2006还规定了面向对象的软件应编制以下文档:总体说明文档、用例图文档、类图文档、顺序图文档、协作图(通信图)文档、状态图文档、活动图文档、构件图文档、部署图文档、包图文档。

2. GB/I9385- 2008

GB/T9385--2008详细描述了SRS应该包含的内容及编写格式。该指南为软件需求实践提供了一个规范化的方法，不提倡将软件需求说明划分成等级，避免将它定义成更小的需求子集。该指南规定，SRS的内容应该包括以下4个方面。

(1)前言:包括目的、范围、定义、简称和缩略语、引用文件、综述。.
(2)总体描述/总体需求/概要需求

包括产品描述、产品功能、用户特点、约束、假设和依赖关系、需求分配。
(3)具体需求/详细需求
(4)支持信息:附录和索引。

SRS应该具有以下特性:无歧义性、完整性、可验证性、- -致性、可修改性、可追踪性(向后追踪、向前追踪)、运行和维护阶段的可使用性。

《信息技术软件产品评价质量特性及其使用指南》(GB/T 16260- -2006) 等标准。

GB/T 16260- -2006分为四个部分，分别是GB/T 16260.1- -2006、GB/T 16260.2-
2006、GB/T 16260.3- -2006 和GB/T 16260.4- -2006。 GB/T 16260.1- -2006中提出了软件生存周期中的质量模型，如图26-1所示。

软件产品质量可以通过测量内部属性(典型地是对中间产品的静态测度),也可以通过测量外部属性(典型地是通过测量代码执行时的行为)，或者通过测量使用质量的属性来评价。
目标就是使产品在指定的使用环境下具有所需的效用。

过程质量有助于提高产品质量，产品质量又有助于提高使用质量。

GB/T 16260.1- -2006定义了6个质量特性和21个质量子特性，它们以最小的重叠描述了软件质量。质量特性和质量子特性，如表26-6所示。

1.提出与接受变更申请
但在评估前应以书面形式的提出。一般项目经理，或者项目配置管理员负贵该相关信息的收集，以及对变更申请的初审。
2.对变更的初审
3.变更方案论证
变更方案的主要作用，首先是对变更请求是否可行实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源需求，以供CCB决策。

4. CCB审批

审查过程，是项目所有者根据变更申请及评估方案，决定是否变更项目基准。评审过程常包括客户、相关领域的专业人士等。审查通常是文档会签形式，重大的变更审查可以包括正式会议形式。
审查过程应注意分工，项目投资人虽有最终的决策权，但通常技术上并不专业。所以应当在评审过程中将专业评审、经济评审分开，对涉及项目目标和交付成果的变更,客户的意见应放在核心位置。
5.发出变更通知并组织实施
评审通过，基准的调整，包括项目目标的确认，最终成果、工作内容和资源、进度计划的调整。
需要强调的是，变更的通知，不只是包括项目实施基准的调整，更要明确项目的交付日期、成果对相关干系人的影响。如变更造成交付期的调整，应在变更确认时发布，而非在交付前公布。

6.变更实施的监控
要监控的，除了调整过的基准中，涉及变更的内容外，还应当对项目的整体基准是否反映项目实施情况负责。通过监控行动，确保项目的整体实施工作是受控的。变更实施的过程监控，
通常由项目经理负责基准的监控。管理委员会监控变更明确的主要成果、进度里程碑等，可以通过监理单位完成。
7.变更效果的评估
变更评估可以从以下几个方面进行评估:
(1)首要的评估依据，是项目的基准。
(2)还需结合变更的初衷来看，变更所要达到的目的是否已达成。
(3)评估变更方案中的技术论证、经济论证内容与实施过程的差距并促发解决。
8.判断发生变更后的项目是否已纳入正常轨道

(1)对进度变更的控制:包括以下主题。
。判断项目进度的当前状态。
●对造成进度变化的因素施加影响。
❸查明进度是否已经改变。
。在实际变化出现时对其进行管理。

(2)对成本变更的控制:包括以下主题。

• 对造成费用基准变更的因素施加影响。
• 当变更发生时，管理这些实际的变更。
• 保证潜在的费用超支不超过授权的项目阶段资金和总体资金。
• 监督费用绩效，找出与费用基准的偏差。
• 准确记录所有的与费用基准的偏差。
• 防止错误的、不恰当的或未批准的变更被纳入费用或资源使用报告中。.
• 就审定的变更，通知利害关系者。
• 采取措施，将预期的费用超支控制在可接受的范围内。

项目费用控制查找正、负偏差的原因，它是整体变更控制的一- 部分。

(3)对合同变更的控制:
合同变更控制系统规定合同修改的过程。
它包括文书工作、跟踪系统、争议解决程序以及批准变更所需的审批层次。
合同变更控制系统应当与整体变更控制系统结合起来。

版本发布准备

(1)进行相关的回退分析。
(2)备份版本发布所涉及的存储过程、函数等其他数据的存储及回退管理。
(3)备份配置数据，包括数据备份的方式，如Dmp方式。
(4)备份在线生产平台接口、应用、工作流等版本。
(5)启动回退机制的触发条件。
(6)对变更回退的机制职责的说明;如通知相关部门，确定需要回退的关联系统和
回退时间点等。

回退步骤:
(1)通知相关用户系统开始回退。
(2)通知各关联系统进行版本回退。
(3)回退存储过程等数据对象。
(4)配置数据回退。
(5)应用程序、接口程序、工作流等版本回退。
(6)回退完成通知各周边关联系统。
(7)回退后进行相关测试，保证回退系统能够正常运行，如进行SHAKEDOWN测试。
(8)通知用户回退完成。

企业的流程管理一.般分为生产流程层、运作层、计划层和战略层4个层次

业务流程分析的主要方法有价值链分析法、客户关系分析法、供应链分析法、基于ERP的分析法和业务流程重构等。

(1)价值链分析法。价值链分析法找出或设计出那些能够使顾客满意，实现顾客价值最大化的业务流程。价值链就是-一个创造价值的I工作流程，在这一总流程基础上， 可把企业具体的活动细分为生产指挥流程、计划决策流程、营销流程、信息搜集与控制流程、资金筹措流程等。其中有些业务流程特别重要，对形成企业核心竞争力起着关键作用，这样的业务流程称为基本业务流程，对应于价值链中的基本活动;其他业务流程是对企业的基本经营活动提供支持和服务，称为辅助业务流程，对应于价值链中的辅助活动。

(2)客户关系分析法。客户关系分析法就是把CRM用在业务流程的分析上。CRM的目标是建立真正以客户为导向的组织结构，以最佳的价值定位瞄准最具吸引力的客户，最大化地提高运营效率，建立有效的合作伙伴关系。从CRM的角度分析业务流程，企业的业务流程应当是以客户与企业的关系，以及客户行为为依据的，而不是传统的按照企业内部管理来实施的。

(3)供应链分析法。供应链分析法是从企业供应链的角度分析企业的业务流程，它源于SCM.供应链是指用一个整体的网络用来传送产品和服务，从原材料开始一直 到最终客户(消费者),它凭借-一个设计好的信息流、物流和资金流来完成。供应链分析法主要从企业内部供应链和外部供应链两个角度来分析企业的业务流程，分析哪些流程处于供应链的核心环节。

(4)基于ERP的分析法。ERP的基本思想是将企业的业务流程看作是--个紧密联接的供应链，将供应商和企业内部的采购、生产、销售，以及客户紧密联系起来，对供应链上的所有环节进行有效管理，实现对企业的动态控制和各种资源的集成和优化，从而提升:企业基础管理水平，追求企业资源的合理、高效利用。

(5)业务流程重构。通过重新审视企业的价值链,从功能成本的比较分析中，确定企业在哪些环节具有比较优势。在此基础上，以顾客满意为出发点进行价值链的分解与整合，改造原有的业务流程，实现业务流程的最优化。有关业务流程重构的详细知识，将在19.3节中进行介绍。

1. 业务流程图(Transaction Flow Diagram, TFD)、
2. 业务活动图示(Business Activity Mapping, BAM)
3. UML的活动图，
4. 标杆瞄准( Bench marking)、
5. IDEF ( Integration DEFinition method,集成定义方法)、IDEF是一系列建模、分析和仿真方法的统称，从IDEFO到IDEF14 (包括IDEF1X在内)共有16套方法,每套方法都是通过建模程序来获取某个特定类型的信息。在IDEF方法中，IDEFO可以用来对业务流程进行建模。IDEFO 是对企业所完成的各项活动及活动之间的相互关系的一-种结构化描述， 其基本要素是用“盒子”表示功能活动。IDEFO 的特点是其层次分解性，它利用- -套完整的、严密的规则，将一一个复杂的系统逐层往下分解，即较高层次的一个活动可以按需要细化成- -组较低层次上的活动。
6. Petri网、

   Petri网是对离散并行系统的数学表示。
   Petri网既有严格的数学表述方式，也有直观的图形表达方式，既有丰富的系统描述手段和系统行为分析技术。Petri网用于描述和分析系统中的控制流和信息流，尤其是那些有异步和并发活动的系统。经典的Petri网是简单的过程模型，由两种节点：库所和变迁，有向弧，以及令牌等元素组成的。

1. DEMO (Dynamic Essential Modeling of Organization,组织动态本质建模法)，DEMO万法定义了信恳系统中行为角色之间的通信万式，这种通信万式可以看作是一种对角色行为的支配方式，而这种支配方式是通过在行为角色之间创建指导其行动的约定来实现的，其理论基础是对话行为理论(speech action theory)。DEMO的核心是业务事务( business transaction), 业务流程由一系列的相关业务事务组成，业务事务是一种通信模式和客观行为，是通过两个行为角色实现，分别是发起者和执行者。一个业务事务包括三个阶段，分别是要求阶段、执行阶段和结果阶段。
2. 业务流程建模语言。

在流程设计过程中，为了更清晰地表达过程规则说明，陆续出现了- -些用于表示业务流程的工具，这些工具包括三类，分别是图形工具、表格工具和语言工具。

其中常见的图形工具包括程序流程图、IPO 图、N-S盒图、问题分析图、判定树，表格工具包括判定表；语言工具包括流程设计语言；

(4)问题分析图。问题分析图( Problem Analysis Diagram， PAD)是继PFD和N-S图之后，又一种描述详细设计的工具，它由日立公司于1979 年提出，也是一种支持结构化程序设计的图形工具。

PAD也包含五种基本控制结构，并允许递归使用。PAD的执行顺序是从最左主干线的上端的结点开始，自. 上而下依次执行。每遇到判断或循环，就自左而右进入下一层，从表示下一层的纵线上端开始执行，直到该纵线下端，再返回.上一层的纵线的转入处。如此继续，直到执行到主干线的下端为止。可以以PAD为基础，按照一个机械的变换规则编写计算机程序，PAD具有清晰的逻辑结构、标准化的图形等优点，更重要的是，它引导设计人员使用结构化程序设计方法，从而提高程序的质量。

BPR在追求顾客满意度和员工追求自我价值实现的流程中带来降低成本的结果，从而达到效率和效益改善的目的。

BPR在注重结果的同时，更注重流程的实现，并非以短期利润最大化为追求目标，而是追求企业能够持续发展的能力，因此，必须坚持

• 以流程为中心的原则、
• 团队式管理原则(以人为本的原则)和
• 以顾客为导向的原则。