合同又称契约(Contract)平等主体的自然人、法人、其他组织之间设立、变更、终止民事权利义务关系的协议。合同条款有合同双方自行商定。一般包括:1当事人的名称2标的3数量4质量5价款或报酬6履行期限、地点和方式7违约责任8解决争议的方法9验收标准和时间。 2.合同的实质要件:1甲方2乙方3标的(最高限价)4效力。合同的订立采用邀约和承诺是形式。 3.合同的法律特征:1)合同是一种民事法律行为2)合同以设立、变更或终止民事权利义务关系为目的3)合同是两个及其以上的当事人意思表示一致的协议4)合同各方当事人在平等、自愿的基础上产生民事法律行为。合同可以是书面(电报、电传、传真、电子邮件、电子数据交换)、口头或其他形式订立。法律、法规规定或双方协商采用采用书面形式的应当采用书面合同。 4.有效合同的原则:1)合同当事人应具有相应的民事权利能力和相应的民事权利义务。2)意思表示真实。3)不违反法律或社会公共利益。
无效合同的情形:1)一方以欺诈、胁迫的手段订立合同的。2)恶意串通,损害国家、集体或第三人利益。3) 以合法形式掩盖非法目的的。3) 违反法律、行政法规的强制性规定。
12.2项目合同的分类1.按信息系统项目范围分:总承包合同、单项合同(项目分成多个包)、分包合同(1.非关键、非主体2.甲方同意3.具有相应的资质4.不得再次分包)。
2.按付款/支付方式分:总价合同(范围明确)、单价合同、成本加酬金(工时材料)合同。当不能迅速确定工作量时,时间和材料合同,适用动态的增加人员、专家或其他外部支持人员等情况。 12.3 项目合同签订
1.违约责任:1)继续履行2)采取补救措施3)赔偿损失(消极的动激励)4)支付违约金或定金 2.邀约方对合同的一致理解。承诺是要约人同意邀约意思表示。3.合同不明确的处理情况
注:替代争议解决程序(争议问题解决程序)是,用于一种相对非正式的方式,用于解决针对合同的不同意见的,其目的是无需通过法庭寻求正式的法律援助(救济)而就解决问题。 12.4项目合同管理 签订、履行、变更、档案、终止管理 隐蔽工程检查有问题乙方负责；没有问题有监理方和甲方赔偿。
13.合同索赔处理1.索赔的分类 单1)按索赔的目的分类:工期索赔和费用索赔； 2)按索赔的依据分类:合同规定的索赔和非合同规定的索赔；3) 按索赔的业务性质分类:工程索赔和商务索赔；4) 按索赔的处理方式分类:单项索赔和总索赔。
合同管理中存在的问题:1.没有签订合同或缺少某些条款2.合同约定不明(时间、地点、质量要
第 26 页 共 37 页
求、费用等)3.合同执行中没有留下相应的记录4.项目变更中没有相应的合同变更。 第13章项目收尾管理 包括合同收尾和管理收尾
13.1 项目收尾的内容括合同收尾主要是履行合同，关闭合同。 管理(行政、检查，包括项目评估和总结)收尾是项目的后评价，需要召开绩效评审会，总结经验教训，更新组织过程资产。 项目收尾的具体内容主要是项目验收、项目总结和项目评估审计。 13.1.1项目验收 重点
1.项目验收 项目的正式验收包括验收项目产品、文档及已经完成的交付成果。
验收需要正式的验收报告。验收测试工作可以由业主和承建单位共同进行,也可以由第三方公司进行,但无论哪种方式都需要双方认可的正式文档为依据进行验收测试。
如果验收测试未获通过,则应立即查找原因,一般会转向变更环节进行修改和补救。 如果项目验收测试正式通过,则标志着项目验收的完成。系统集成项目的验收工作步骤1.系统测试。对信息系统进行全面的测试,依照双方合同约定的系统环境,以确保系统功能和技术设计满足业主的需求,并能正常运行。系统测试阶段应包括编制测试用例, 建立测试环境,逐条进行测试测试。2.系统的试运行。信息系统通过双方测试以后,可以开始试运行。3.系统的文档验收。在经过系统测试后,系统的文档应逐步移交给业主方(集成项目涉及的文档:系统集成项目介绍、系统集成项目最终报告、信息系统说明手册、信息系统维护手册、软硬件产品说明书、质量保证书等) 4.项目的最终验收报告。在系统试运行后的约定时间,双方可以进行项目的最终验收工作。通常情况下,大项目都分为试运行和最终验收两个步骤。对一般项目而言,可以将系统测试和试运行合并进行,但需要对最终验收过程加以确认。
最终验收报告就是业主方认可承建方的项目工作的最主要文件之一,这是确认项目工作结束的重要标志性工作。对信息系统而言，最终验收标志着项目的结束和售后服务的开始。 13.1.2项目总结
项目总结收集整理项目过程文档和经验教训.项目总结属于项目收尾的管理收尾。 1.项目总结的意义 背诵
一般的项目总结会的意义:1.了解项目全过程的工作情况及相关团队或团队成员的绩效状况2.理解出现的问题并进行改进措施的总结3.了解项目全过程中出现的值得吸取的经验并进行总结4.对总结后的文档进行讨论,通过后即存入公司知识库,从而纳入企业的过程资产。项目总结会应第 27 页 共 37 页
讨论如下内容。
2.一般的项目总结会应讨论如下内容。背诵 13.5案例3
(1)项目绩效。 (2)技术绩效。(3)成本绩效。(4)进度计划绩效(5)项目的沟通。 (6)识别问题和解决问题。 (7)意见和建议。
13.1.3项目评估和审计将项目所有工作加以客观评价,从而使项目全体成员的成果形成绩效结论。 1.项目评估-事后评估 项目评估依据: (l)盈利要求。 (2)客户满意度要求。 (3)后续项目指标要求。 (4)内部满意度要求。
项目审计-项目管理部门与财务部门共同进行。项目收尾阶段的文档:1.项目文档介绍2.项目最终报告3. 项目最终验收报告4.系统说明手册5.系统维护手册6.软硬件产品说明书、质量保证书7.项目评估报告8.项目审计报告9.项目总结会会议记录 3. 项目收尾过程中存在的问题
1.未达到验收条件便进入了验收环节,此时系统测试尚未完成。 2.未按变更流程处理客户对软件的修改要求。 3.配置管理存在问题,修改软件后,未及时修改文档。
4.未签验收报告便进行项目总结。5.项目总结未能反映项目的真实情况。
第14章 配置管理
14.1配置管理的概念
《计算机软件产品开发文件指南》指出,从重要性和质量要求方面,分为非正式文档和正式文档；从项目周期的软件文档分为三类:开发文档、产品文档、管理文档。
1.开发文档:描述开发过程本身,包括:1.可行性研究报告和项目任务书2.需求规格说明3.功能规格说明4.设计规格说明5.开发计划6.软件集成和测试计划7.质量保证计划、标准8.项目进度计划、配置管理计划9.安全和测试信息例如测试计划、数据字典10.项目开发总结报告
2.产品文档:描述开发过程产物,包括1.培训手册2.参考手册和用户指南3.软件支持手册4.产品手册和信息广告
3.管理文档:建立在项目管理信息的基础上,计划、变更记录项目管理信息。1.每个阶段进度记录2.软件变更情况记录3.开发的判定记录4.职责定义等5.进度、绩效、项目总结报告6.成本计划
信息系统文档的管理主要体现在文档书写规范、图标编写规则、文档目录编写标准、文档
第 28 页 共 37 页
管理制度等几个方面。
配配置管理是用技术的和管理的指导和监督来标识和用文档记录配置项的功能和物理特征、控制这些特征的变更、记录和报告变更处理过程和现实状态、验证与规定需求的一致性。配置管理的一个重要内容就是对变更加以控制,使变更对成本、工期、质量的影响降低到最小。 1.配置项是配置管理的对象。包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需要的各种数据,它们是经过评审和检查通过后进入软件配置管理。配置项的两类:产品的工作成果(需求文档、设计文档、源代码、可执行代码、测试用例)、项目管理的文档(工作计划、项目质量报告、项目跟踪报告)。
所有配置项的操作权限有CMO严格管理。基本原则是:基线向软件开发人员开发读取权限；非基线配置项向PM、CCB及相关人员开放。访问权限有CMO分配,应得到QA批准。 2.配置库就是存储配置项的仓库。
3.基线:对于配置管理,有三种基线:功能基线、分配基线、产品基线。 4.配置管理活动和流程:配置管理的(流程)主要工作中级 重点09.5-45
1.配置管理活动:配置识别、变更控制、状态报告和配置审计。
2.配置管理主要包括(1)制定配置管理计划(2)配置识别(确定配置标识规则)与建立基线(3)建立配置管理系统(4)实施变更管理(5)版本管理(6)配置状态报告 (7)配置审计/审核(功能配置审计和物理配置审计) 案例06
项目配置管理的任务(流程7个):建立并维护配置管理才组织方针1.制定配置管理计划2确定配置标识规则3.实施变更控制4.报告配置状态5.配置审核6.进行版本管理和发行管理。高级 14.2 制定配置管理计划
配置管理计划的主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。配置管理员CMO负责制定配置管理计划,CCB负责审批配置管理计划。所有配置项的操作权限由CMO严格管理,基本原则是:基线配置项向软件开发人员开发读取权限；非基线配置项向PM、CCB及相关人员开放。配置控制委员会(Configuration Control Board,CCB)(变更控制委员会)审批该计划。人员不一定面面俱到。 14.3 配置标识与建立基线
基线由一组配置项组成,基线是一组经过正式审查且达成一致的范围或工作产品,相对稳定只能
第 29 页 共 37 页
有指定的CMO通过配置管理流程进行修改。基线不能再被任何人任意修改。这些配置项构成了一个相对稳定的逻辑实体。CMO根据项目计划文档,配置管理计划、配置项管理表等创建或发行基线(基线一般分为功能基线:系统分析和软件定义结束时、分配基线:需求分析阶段、管理基线:软件组装和测试结束时)。基线配置项不包括计划！
识别配置项即识别将置于配置管理之下的配置项和有关的工作产品。
1.识别配置项 定义每个配置项的重要特征以及识别其所有者是配置管理员的关键职责。内容有:1)识别需要受控的软件配置项2)给每个产品和它的组件及相关文档分配唯一的标识3)定义每个配置项的重要特征及识别其所有者4)识别组件、数据及产品获取点和准则5)建立和控制基线6)维护文件和组建的修订与产品版本的关系。主要步骤:1.识别配置项2.为配置项制定唯一的标识号3. 确定配置项的重要特征4.确定配置项进入配置管理的时间5.确定每个配置项的拥有者责任6.填写《配置管理表》7.审批《配置管理表》
3.创建基线或发行基线 (功能、产品、发行基线)的主要步骤:1)CMO识别配置项2)为配置项分配标识3)为项目项创建配置库,并给每个采用分配权限4)各团队成员根据自己的权限操作配置库5)创建基线或发行基线并获得CCB的授权。 14.4 建立配置管理系统
配置管理中的人员:1.PM(负责人)2.CCB(提供决策建议)3.CMO(执行配置管理任务,向CCB定期提交报告)4.开发人员:根据配置管理计划和相关规定,按照配置管理的使用模型完成开发任务。 变更管理的任务:分析变更,根据成本/效益和涉及的技术判断变更的必要性,确定是否进行变更；记录和跟踪变更；采取措施保证变更受控。
1.配置库存放配置项的仓库,作用:1.记录与配置相关的所有信息,其中存放受控的软件配置项是项目的主要内容。2.利用库中的信息评级变更的后果,这对配置变更有着重要的作用。 3.从库中提取配置管理过程的管理信息,利用库中的信息查询回答许多配置管理的问题。 1配置库的类型4类库:1)动态库,也称开发(工作)库:供开发人员使用,修改频繁,无需对其做任何限制。包括:新模块、文档、数据元素或进行修改的已有元素。动态库是软件工程师的工作区,由工程师控制。2)受控库也称主控库或系统库:用于管理当前基线和对基线的变更(半成品)。介于动态库和静态库之间。包括配置单元和被提升被集成到配置库中的组件。软件工程师和其他人员自由复制受控库中的单元和组件。
第 30 页 共 37 页