IPM集成项目管理.ppt

过程改进组对项目裁剪结果进行评审，对项目组提出的偏离过程标准申请进行审批。 过程改进组对项目组裁剪时考虑的因素和裁剪的理由进行分析，用以改进本准则和指南。 项目组在决定替换某个关键实践或子实践时，务必慎重。项目组应该确保自己清楚的理解了将要裁减的过程单元或过程活动的意图，理解为什么当前项目环境需要“替代过程活动”或者不需要实现该过程活动，清楚的说明为什么“替代过程活动”能够提供同样的过程能力。 裁剪时要考虑组织结构，包括人员的构成和各小组的划分设置。基本原则是过程中描述的某些或某项任务应该有人负责完成，而不一定非要具有相应名称的小组；或者也可以是由一个小组完成过程中所有任务，不一定该小组有什么固定头衔。 关于客户（最终用户）关系的考虑： 理想化的应该是有一个专门的客户代表负责系统的需求，客户代表有时间和相关知识，并且愿意积极参与开发过程，如评审等。但是实际的客户可能与此大相径庭，客户只关心产品，不想不愿也缺乏必要的专业素质参与开发过程；甚至在有些项目环境（如开发通用软件），最终用户甚至都无法确定。因此，商业开发中，对于客户参与应该作出适当的解释，这一责任可以通过项目责任者来承担。 5、业务目标和裁剪程度 裁剪公司标准过程库作为一种通用的过程模型，因为面对的项目类型不同，所以只能强调一些比较普遍的业务目标，如开发费用的降低、提高质量、保证进度、连续的过程改进等。这些业务目标都很重要，但是对于特定的项目而言，应该明确这些目标的优先级，然后根据每个过程单元与项目目标的相互关系，以作出适当的裁剪。 CMMI体系文件和标准过程库的阐述一般非常严格和正式，项目中可能认为这种严格和正式程度对于项目是一种额外负担，实践表明，强调过程纪律与正式性也能够大大提高产品生产率、质量和保证进度。除非特殊要求项目对标准过程活动的裁剪比例应在5％－15％以下。 6、裁剪方法 项目可以使用检查清单来裁剪标准过程单元，有必要的时候对每一个过程单元都使用下面的一整套检查清单（也可以合并）。 公司 标准 过程 单元 框架 检查 清单 结构 项目组使用标识符来表示项目对标准过程的裁剪。 标 识 符 说 明 表 7、裁剪指南 7.1 裁剪过程单元 裁剪删减过程单元 可能的原因： 客户要求 项目开发过程部分外包 如将编码部分外包出去，则将软件实现过程单元裁剪，转而增加项目分包控制。 前提条件： 被删减的过程单元所应产生的主要工作产品必须已经存在或在预期时间内可以得到 例1：A项目合同中没有需求分析，但系统功能说明书必须已经存在并可以得到，从而保证后续的设计和开发活动可以开展； 例2：B项目将编码部分外包，源代码在预期时间内必须可以得到。 过程单元被删减，但过程单元中产生的工作产品的质量必须受控。 例如：A项目中要对系统功能说明书进行正式、全面的检查，以确保设计、开发人员能充分理解最终用户的需求；B项目中需对承包方的编码过程进行监控，对源代码进行验收。 合并过程单元 可能的原因 所选用的生命周期（如采用原型模型开发时，在需求分析阶段，构造原型用于帮助用户理解问题，实验求解方案，原型可能会逐步进化为设计模型，这种情况下，软件需求和软件设计阶段可以合并）。 前提条件 过程单元合并，计划、跟踪活动可以合并，但过程单元所应产生的主要工作产品不能减少。 可能产生的问题： 过程单元合并后，各类活动开展的次序较难控制。 过程单元合并后，基线减少，不同的开发人员可能同时使用不同版本的工作产品，配置管理有一定难度。 增加过程单元 可能的原因 对必须选用的开发方法、开发工具事先进行研究。 如研发型的项目，可能需要对新工具、方法进行研究评估后，才能转入实质的项目开发工作。 7.2 裁剪活动 删减活动 项目过程监控中的周例会可以删减。 原因：项目规模小，软件项目组人员很少，日常工作中能方便地进行交流，不必采取周例会的方式。 ? 裁剪活动频度 项目沟通机制中的技术交流活动的频度可以裁剪。 原因：项目技术难度不大，项目组开发人员都能很好地掌握该项目所用的技术、方法和工具，则交流活动的间隔时间可以长一些。 软件实现中的系统构造频度可以裁剪。 原因：根据项目功能内聚性的强弱，可以采用每天构造（功能内聚强）、每周构造（功能内聚较强）等方式。 “系统构造频度”指构建次数（产品设计次数）；编译、集成、集成测试和接口测试次数。 “项目功能内聚性的强弱”指功能模块间的关联关系强弱。 像一些大公司，比如微软都是白天写代码，晚上就用机器自动编译。 裁剪活动正式度 项目估算中的估计小组人员数量可以裁剪。 原因：项目规模小，且