XX项目总结报告 版本：X.X
3.3 项目遗留问题 3.4 项目性能数据
3.4.1 进度
里程碑 项目开始 计划日期 2004年3月15日 2004年4月30日 2004年5月26日 2004年6月11日 2004年7月12日 实际日期 2004年3月15日 2004年5月24日 2004年5月21日 2004年6月7日 2004年7月28日 差异 0 -24 5 4 -16 需求基线 系统架构设计 系统分析和设计基线 V2.5测试代码基线 V2.5版系统发布 客户中期检查和验收材料 V3.0测试代码基线 V3.0系统发布 项目结束 2004年8月1日 2004年9月30日 2004年10月4日 2004年11月17日 2004年11月30日
3.4.2 工作量
3.4.2.1 工作量分布 ? 工作量分布：
〔可参考阶段报告里的工作量分布图〕
3.4.3 规模
〔研发项目专用，描述项目各阶段计划规模与实际规模的对比情况，并分析发生偏差的原因〕
Page 4 of 10
XX项目总结报告 版本：X.X
软件估计规模 （功能点） - - - 软件实际规模 (功能点) - - - 阶段 计划 需求 设计 编码 测试 发布 里程碑 软件计划评审通过 需求规格说明书评审通过 系统设计说明书评审通过 源代码评审通过 系统测试完成 产品发布完成
3.4.4 缺陷
〔描述项目各阶段发现的缺陷数，下面的例子是针对研发项目的，实施和维护项目可以根据各自项目的特点设置检查点。〕 检查点 用户需求评审 软件需求评审 架构设计评审 设计评审 代码评审 测试 缺陷发现数目 缺陷分布4035302520151050计划需求设计编码测试实施
图示分析：〔根据分析图进一步分析现状发生的原因。〕
缺陷分布Page 5 of 10
XX项目总结报告 版本：X.X
3.4.5 主要问题和风险
〔可以参考项目的问题列表和风险列表的格式〕
3.5 可推行复用的软件技术成果
4 项目开发工作评价
4.1 产品质量评价
发布时 目标值 缺陷数 严重缺陷数 严重缺陷比率 缺陷密度 产品质量评价：
4.2 技术方法评价
〔总结该软件项目或软件产品开发时所采用的各项技术〕
〔以下是示例：〕
? 对开发工具的评价：
? UBS-HotBilling使用TT作为内存数据库，提高了应用处理的性能。试点割接上线后正常运行，并且为OCS系统上线提供了实践依据，并积累了实施开发经验。
? 对框架技术的评价：从整个框架的整体使用效果来看并为达到预期的目的，我认为主要是由以下原因造成的：
? 框架本身存在有诸多不完善的地方，需要不断地进行改进，但在改进的过程中没有进行严格的控制，导致框架的整体设计失控；
? 框架本身有这样那样的问题，有些问题是目前无法解决的；
? 框架是建构在PFC的基础上的，项目组成员对PFC不是足够的精通，为维护框架带来难度。
? 建议：模块化是产品化的基础，也是降低成本、提高开发效率保证软件质量的有效手段，需要有专人设计和维护框架。
? 对设计方法的评价：信息化项目的整体设计是由项目组全体成员完成的，鉴于我们目前的设Page 6 of 10
XX项目总结报告 版本：X.X
计水平，我看还可继续这种方法，对设计的方法和思路进行广泛的借鉴，但一定要树立设计的权威性，对设计的变更要进行严格的控制。
? 对团队开发的评价：从整体上讲我们这个团队的能力还可以，但我认为它的生产效率并不高也就是说团队的整体建设不好，没有明确的学习方向分工，使整个团队在这段时间里整体能力没有太大的提高，我以前很想把我们的团队培养成那种学习型的优秀团队，可惜事与愿违这项工作没有取得什么实效。
5 项目管理工作评价
5.1 需求管理
〔研发项目专用〕
5.1.1 需求完成情况
最初的需求数： 已实现的需求数： 已删除的需求数： 已修订的需求数： 新增的需求数：
5.1.2 需求变更情况
〔总结项目的不同阶段所发生的需求变更次数及发生变更的主要原因。〕
变更发生的阶段 需求变更次数 变更工作量 （从申请开始到变更结束发生的工作量） 用户需求定义 软件需求分析 设计 编码 测试 维护
Page 7 of 10
XX项目总结报告 版本：X.X
需求变更的主要原因：
5.2 计划管理
5.2.1 计划变更情况
序号 1 2 3
变更发生阶段 变更原因 变更内容 变更是否允许 6 经验教训
6.1 项目成功经验 6.2 项目失败教训 6.3 项目组建议
Page 8 of 10
相关推荐：
loading