X
024
5416
342工作量
3421工作量分布工作量分布：〔可参考阶段报告里的工作量分布图〕
343规模
〔研发项目专用，描述项目各阶段计划规模与实际规模的对比情况，并分析发生偏差的原因〕
阶段
计划需求设计编码测试发布
里程碑
软件估计规模（功能点）
软件计划评审通过
需求规格说明书评审通过
系统设计说明书评审通过
源代码评审通过

系统测试完成

产品发布完成
Page4of10
软件实际规模功能点
fXX项目总结报告
版本：XX
344缺陷
〔描述项目各阶段发现的缺陷数，下面的例子是针对研发项目的，实施和维护项目可以根据各自
项目的特点设置检查点。〕
检查点
缺陷发现数目
用户需求评审
软件需求评审
架构设计评审
设计评审
代码评审
测试
缺陷分布
4035302520151050
计划
需求
设计
编码
测试
实施
缺陷分布
图示分析：〔根据分析图进一步分析现状发生的原因。〕
345主要问题和风险
〔可以参考项目的问题列表和风险列表的格式〕
Page5of10
f35可推行复用的软件技术成果
XX项目总结报告
版本：XX
4项目开发工作评价
41产品质量评价
缺陷数发布时目标值产品质量评价：
严重缺陷数
严重缺陷比率
缺陷密度
42技术方法评价
〔总结该软件项目或软件产品开发时所采用的各项技术〕〔以下是示例：〕对开发工具的评价：
UBSHotBilli
g使用TT作为内存数据库，提高了应用处理的性能。试点割接上线后正常运行，并且为OCS系统上线提供了实践依据，并积累了实施开发经验。
对框架技术的评价：从整个框架的整体使用效果来看并为达到预期的目的，我认为主要是由以下原因造成的：框架本身存在有诸多不完善的地方，需要不断地进行改进，但在改进的过程中没有进行严格的控制，导致框架的整体设计失控；框架本身有这样那样的问题，有些问题是目前无法解决的；框架是建构在PFC的基础上的，项目组成员对PFC不是足够的精通，为维护框架带来难度。建议：模块化是产品化的基础，也是降低成本、提高开发效率保证软件质量的有效手段，需要有专人设计和维护框架。
对设计方法的评价：信息化项目的整体设计是由项目组全体成员完成的，鉴于我们目前的设计水平，我看还可继续这种方法，对设计的方法和思路进行广泛的借鉴，但一定要树立设计的权威性，对设计的变更要进行严格的控制。
对团队开发的评价：从整体上讲我们这个团队的能力还可以，但我认为它的生产效率并不高
Page6of10
fXX项目总结报告
版本：XX
也就是说团队的整体r