移动通信计算机应用软件开发工作量评估方法研究课题汇报材料.ppt

黄色什么意思？ 页眉 * 页眉 * 分析方法论介绍 估算研究与借鉴 现状分析与关键发现 业界到北京移动的裁剪过程 模型的设计思路及使用 体现与北京移动的项目结合 调研来验证-量化数据的体现 下一步需要配合的工作 扩容类-可以使用用例 实施计划：团队/里程碑/提交物+backup时间表完成情况 对环境因子设置控制线，在评估过程中加强对团队特征因素的判断，避免评价不合理现象 加强厂商反馈工作量的判断 从项目的角度看，工具更适用于哪几个领域，领域特点 网络支撑的偏差大的原因： 未来应用和历史项目分析 页眉 * 页眉 * 业务支撑类项目偏正，项目周期比较长，需求实施过程中变更增加较多，由于是核心系统对系统的安全要求高，质量保障的活动加强（），实际工作量比合同工作量要多。建议，在需求反馈阶段，加强前期需求交流和沟通。同时降低项目开发实施上线周期，避免需求交叉的变更对实施的工作量增加，加强统一的需求管理流程控制。 管理支持类项目正负偏差情况都存在，说明项目立项阶段需求不够详细，用户需求随意性较强，在实施过程中，经过细化有不同程度的增减（随意性较强）。建议今后加强需求管理和投入成本的控制。 大型的管理支持类项目容易出现偏负较大现象，原因是，由于功能较多、规模较大，有类似功能可为复用，但甲方识别较难，厂商在立项或合同中重复计算工作量。建议在立项阶段加强把控，通过估算工具，识别复用模块的通用功能，加强工作量核查。 数据业务项目偏正，功能均为商用，扩容功能基本新增功能，对原有功能修改较少，因为面向客户，另外产品的功能性设计随意性较低，大部分为新增功能，但最初设计不十分细致，但后期会逐步细化。建议，新建类项目较多，由于招投标等影响，厂家降低了合同量。 页眉 * 页眉 * 页眉 * 分析方法论介绍 估算研究与借鉴 现状分析与关键发现 业界到北京移动的裁剪过程 模型的设计思路及使用 体现与北京移动的项目结合 调研来验证-量化数据的体现 下一步需要配合的工作 扩容类-可以使用用例 实施计划：团队/里程碑/提交物+backup时间表完成情况 win 页眉 * 已修订立项管理流程，融合了估算相关的活动，并识别出主要提交物和参与角色 要进行估算流程的发布，推广规范化的估算活动 页眉 * 页眉 * 分析方法论介绍 估算研究与借鉴 现状分析与关键发现 业界到北京移动的裁剪过程 模型的设计思路及使用 体现与北京移动的项目结合 调研来验证-量化数据的体现 下一步需要配合的工作 扩容类-可以使用用例 实施计划：团队/里程碑/提交物+backup时间表完成情况 2010年3月30日上午，在东直门综合楼十层南第一会议室，由计划建设部主持召开了移动通信计算机应用软件开发工作量评估方法研究课题预审会。网络部、数据业务部、信息系统部、物资供应部和网络运行支撑中心的相关领导和项目负责人参加了本次会议。 与会人员对课题涉及内容进行了充分讨论，形成如下主要评审意见： 一、随着软件开发在我公司项目中所占比重的逐年增加，建立一套合理、有效的软件开发工作量评估机制越来越重要，本课题的研究是非常有必要的，研究成果对未来的投资测算、项目管理和技术人员能力水平的提升，都具有实际意义； 二、软件开发工作量的评估是非常复杂的过程，要想取得好的效果，不仅需要合理、有效的工具，更需要与合作厂商建立信任，需要我方评估人员长期的知识积累； 三、利用工具辅助评估只是一个手段，目标是能培养我们的架构师，合理搭建软件架构和提升合理确认开发工作量的能力。后期推广前需给各部门做进一步培训，必要时相关部门可设立工具使用专员，通过各种手段全面提高项目管理人员综合能力； 四、工具的易用性及测算的准确度需要不断地修订，以及大量数据的积累、验证，在使用初期本工具可作为立项评估的一个辅助工具。在使用过程中，计划部将根据各部门和厂商的反馈意见，积极组织咨询单位循序渐进、逐步完善工具，待应用流畅、成熟、可推广性较强时再加大使用范围； 五、对于工具的使用，建议扩容类项目可直接使用该工具，而新建类需要招标的项目，可以在交流过程中利用该工具增强交流效果，但具体是否作为判断或评标标准可根据实际情况确定。 同时，对课题提出如下修改意见： 一、请调整估算因子的相关描述，使其更与我公司的实际情况相符并通俗易懂；同时请减少或固化凭厂家主观判断的估算因子的参数设置，使工具使用更加合理和简单； 二、请利用工具完成对历史典型项目的开发工作量分析工作，进一步确认、检验工具的适用性和准确性； 三、请明确本工具的适用范围，以及整个流程中厂商、我公司相关人员的角色和职责要求；明确我方项目管理人员在项目需求描述和分析能