新过程改进方法与实践案例 978 7 302 23431 9 第三部分 实践案例 Ch11 软件外包企业的问题分析和改进.ppt

主题 11.1 外包企业的现状 11.2 CMMI对外包企业的适用性 11.3 企业背景与工作流程 11.4 外包工程中的问题 11.5 与CMMI过程域的映射表 11.6 需求管理改进 11.7 项目估算改进 11.8 项目监控改进 11.9 验证和确认的改进 11.10 技术解决方案的改进 11.11 产品集成的改进 外包企业的现状 单个金额在1?000万美元以上的合同只占合同总数的1.6%，金额在500万～1?000万美元之间的占1.9%，金额在100万～500万美元之间的占7.7%，金额在50万～100万美元之间的占12.7%，而大多数合同的金额在50万美元以下，占总数的76.1% CMMI对外包企业的适用性 虽然受2008年下半年开始的金融危机的影响，印度Infosys公司的2009年业务和利润仍然在增长。 其原因在于，这些公司在接单的时候，能够准确地评估项目的规模、进度、资金、风险等因素，在执行的过程中，能够应对需求因素的变化。 企业背景与工作流程 NLST是一家主要以承包国外订单为主要业务的软件企业。 外包工程中的问题分析 11.4.1 需求理解和管理问题 11.4.2 项目估算缺乏有效性 11.4.3 项目监控力度不够 11.4.4 缺少对编码规范和质量的控制 11.4.5 设计与编码脱节 11.4.6 缺少必需的集成过程 11.4.7 评审缺乏有效性 11.4.8 功能测试缺乏有效性 需求理解和管理问题 项目组对需求的理解不够充分。 其表现为在项目开发进程中，所定义的需求无法指导后续设计，以及部分需求产生了二义性。 2) 对于较大的需求变更，由于需要重新估算工期和成本，并且要在任务承接单中明确了核算成本，所以比较容易控制。 但对于较小的需求变更，就缺少有效的管理机制，当较小的变更积少成多时，问题就突显出来，最终不仅影响工期和成本，也对项目整体的质量造成不可预计的影响。 基于以上两点原因，当客户方提出迭代开发的要求时，往往造成项目后期比较被动，疲于确认前期需求，无法管理频繁的变更，严重影响项目的开发。 项目估算缺乏有效性 虽然公司有估算委员会对项目的规模、工作量、工期进行估算，但是，由于缺乏专业的估算方法， 没有历史数据供参考。 估算过分依赖于估算人员的经验，导致估算的结果时好时坏： 经常做的项目类型估算较准； 没有做过或很少做的项目类型偏差较大，估算结果的准确性非常差。 项目监控力度不够 项目的监控力度基本取决于项目经理的个人能力，公司没有明确而统一的项目汇报机制： 1) 当项目组成员承担多个项目的工作时，项目经理很难准确、快速地识别出该员工承担的本项目工作的进展和问题。 2) 工作报告与已定义的WBS(工作分解结构)描述不符，缺乏对项目任务的跟踪。 3) 工作报告中缺少定量的工作描述，仅依据工作报告仍然无法得到量化的进展指标。 缺少对编码规范和质量的控制 虽然企业已经规定要对所有项目代码进行走查，并提供了检查单. 但在实际运用的过程中发现，由于: 代码检查人员工作量过大、 工期安排过紧， 往往没有进行充分的代码检查就提交了检查结果，甚至很明显的不符合编码规范的问题都没有发现。 设计与编码脱节 项目缺少详细设计的活动和工作产品定义。 各项目组往往直接使用概要设计书指导编码，其理由是节省时间，尽快进入编码，以保证工期。 但是，经过对各阶段工期、工作量的分析对比发现：虽然设计工期缩短了，但编码工期实际上是增加了；编码阶段变成了在不断地确认需求、细化设计、沟通接口的过程中进行。 特别是，一旦有实习员工或新员工加入项目组，因为他们没有前期的介入，不了解需求，同时又没有可以指导他们进行编码的文档，所以基本上无法开展编码工作。 缺少必需的集成过程 有明确地定义系统集成的过程和活动，项目组对集成的重视程度也明显不足： 1) 集成后的系统，在模拟系统环境下就出错，特别是涉及软件系统与外部系统或硬件的连接及接口方面的时候，问题尤为突出。 2) 集成活动缺乏定义与监控，测试中发现问题难以快速定位。 3) 进入系统测试后，经常发现准备不足。集成中的缺陷严重影响了测试的开展。 评审缺乏有效性 基本上没有执行正式评审；只进行单人审核，一般由项目经理或项目组内高级技术人员执行。 没有评审计划，也没有评审记录，出现了与代码检查类似的问题。 审核工作都是作为附加任务分派给员工的，没有专门的日程安排或日程安排过紧。 而严格的技术评审往往又需要较多的时间来完成。 久而久之，评审逐渐流于形式，未达到应有的目的，反而增加了无效的工作量。 功能测试缺乏有效性 项目组一直用黑盒法进行单元测试。 在编码结束后即刻进行功能测试，起到了一定的效果。 但是，同时也产生问题： 单元测试与系统测试的区分