1、文件编号：版本号：1.0项目总结报告部 门： 编 写： 审 核： 批 准： 日 期： YYYY.MM.DD 公司文件修订记录时间 作者 主要修订内容YYYY.MM.DDXX 项目总结报告 版本：X.XPage 1 of 10 目 录1.引言21.1 目的 .21.2 项目背景 .21.3 参考资料 .22 项目基本情况 .22.1 项目基本信息 .22.2 项目特征 .22.3 项目目标 .33 项目执行结果 .33.1 交付产品 .33.2 主要功能和性能 .33.3 项目遗留问题 .43.4 项目性能数据 .43.5 可推行复用的软件技术成果 .64 项目开发工作评价 .64.1 产品质量
2、评价 .64.2 技术方法评价 .65 项目管理工作评价 .75.1 需求管理 .75.2 计划管理 .86 经验教训 .86.1 项目成功经验 .86.2 项目失败教训 .86.3 项目组建议 .8XX 项目总结报告 版本：X.XPage 2 of 10 1 引言引言1.1 目的目的阐明编写本总结报告的目的，指出读者对象。1.2 项目背景项目背景可包括本项目的来源、委托单位、开发单位和主管部门等。1.3 参考资料参考资料2 项目基本情况项目基本情况2.1 项目基本信息项目基本信息项目中文全称：客户：项目经理：项目开始日期：项目结束日期：项目成员：2.2 项目特征项目特征项目所属类型：采用的生
3、命周期模型：硬件平台：应用领域：使用工具：开发语言：数据库：XX 项目总结报告 版本：X.XPage 3 of 10 2.3 项目项目 目标目标客户目标： 描述客户对项目的总体要求，以及需要达到的目标。例如：1. 应当解决当前系统存在的一些问题，尤其是易用性、可靠性的问题；2. 应当允许平台的独立性；3. 应当能从所有的客户站点方便地进入平台。项目质量目标： 描述产品在交付时期应达到的质量要求，以及不同阶段的缺陷率控制要求。例如：1. 交付时缺陷密度：0.2 缺陷/KLOC；2. 需求评审缺陷率：10% 15%；3. 。3 项目执行结果项目执行结果3.1 交付产品交付产品项目的主要交付产品列表
4、：产品名称 产品规模 规模单位 完成日期 是否通过验收需求规格说明书 25 页系统设计说明书 72 页源代码 KLOC可执行代码用户手册 页3.2 主要功能和性能主要功能和性能研发项目专用。 XX 项目总结报告 版本：X.XPage 4 of 10 3.3 项目遗留问题项目遗留问题3.4 项目性能数据项目性能数据3.4.1 进度进度里程碑 计划日期 实际日期 差异项目开始 2004 年 3 月 15 日 2004 年 3 月 15 日 0需求基线 2004 年 4 月 30 日 2004 年 5 月 24 日 -24系统架构设计 2004 年 5 月 26 日 2004 年 5 月 21 日
5、5系统分析和设计基线 2004 年 6 月 11 日 2004 年 6 月 7 日 4V2.5 测试代码基线 2004 年 7 月 12 日 2004 年 7 月 28 日 -16V2.5 版系统发布 2004 年 8 月 1 日 客户中期检查和验收材料2004 年 9 月 30 日V3.0 测试代码基线 2004 年 10 月 4 日 V3.0 系统发布 2004 年 11 月 17 日 项目结束 2004 年 11 月 30 日 3.4.2 工作量工作量3.4.2.1 工作量分布 工作量分布：可参考阶段报告里的工作量分布图3.4.3 规模规模研发项目专用，描述项目各阶段计划规模与实际规模的
6、对比情况，并分析发生偏差的原因XX 项目总结报告 版本：X.XPage 5 of 10 3.4.4 缺陷缺陷描述项目各阶段发现的缺陷数，下面的例子是针对研发项目的，实施和维护项目可以根据各自项目的特点设置检查点。 检查点 缺陷发现数目用户需求评审软件需求评审架构设计评审设计评审代码评审测试0510152025303540计 划 需 求 设 计 编 码 测 试 实 施缺 陷 分 布缺 陷 分 布图示分析：根据分析图进一步分析现状发生的原因。 阶段 里程碑软件估计规模（功能点）软件实际规模(功能点)计划 软件计划评审通过 -需求 需求规格说明书评审通过 -设计 系统设计说明书评审通过 -编码 源代
7、码评审通过 -测试 系统测试完成 -发布 产品发布完成 -XX 项目总结报告 版本：X.XPage 6 of 10 3.4.5 主要问题和风险主要问题和风险可以参考项目的问题列表和风险列表的格式3.5 可推行复用的软件技术成果可推行复用的软件技术成果4 项目开发工作评价项目开发工作评价4.1 产品质量评价产品质量评价缺陷数 严重缺陷数 严重缺陷比率 缺陷密度发布时 目标值产品质量评价：4.2 技术方法评价技术方法评价总结该软件项目或软件产品开发时所采用的各项技术 以下是示例： 对开发工具的评价： UBS-HotBilling 使用 TT 作为内存数据库，提高了应用处理的性能。试点割接上线后正常
8、运行，并且为 OCS 系统上线提供了实践依据，并积累了实施开发经验。 对框架技术的评价：从整个框架的整体使用效果来看并为达到预期的目的，我认为主要是由以下原因造成的： 框架本身存在有诸多不完善的地方，需要不断地进行改进，但在改进的过程中没有进行严格的控制，导致框架的整体设计失控； 框架本身有这样那样的问题，有些问题是目前无法解决的； 框架是建构在 PFC 的基础上的，项目组成员对 PFC 不是足够的精通，为维护框架带来难度。 建议：模块化是产品化的基础，也是降低成本、提高开发效率保证软件质量的有效手段，需要有专人设计和维护框架。 对设计方法的评价：信息化项目的整体设计是由项目组全体成员完成的，
9、鉴于我们目前的XX 项目总结报告 版本：X.XPage 7 of 10 设计水平，我看还可继续这种方法，对设计的方法和思路进行广泛的借鉴，但一定要树立设计的权威性，对设计的变更要进行严格的控制。 对团队开发的评价：从整体上讲我们这个团队的能力还可以，但我认为它的生产效率并不高也就是说团队的整体建设不好，没有明确的学习方向分工，使整个团队在这段时间里整体能力没有太大的提高，我以前很想把我们的团队培养成那种学习型的优秀团队，可惜事与愿违这项工作没有取得什么实效。5 项目管理工作评价项目管理工作评价5.1 需求管理需求管理研发项目专用5.1.1 需求完成情况需求完成情况最初的需求数：已实现的需求数：已删除的需求数：已修订的需求数：新增的需求数：5.1.2 需求变更情况需求变更情况总结项目的不同阶段所发生的需求变更次数及发生变更的主要原因。 变更发生的阶段 需求变更次数 变更工作量（从申请开始到变更结束发生的工作量）用户需求定义软件需求分析设计编码测试维护XX 项目总结报告 版本：X.XPage 8 of 10 需求变更的主要原因：5.2 计划管理计划管理5.2.1 计划变更情况计划变更情况序号 变更发生阶段 变更原因 变更内容 变更是否允许1236 经验教训经验教训6.1 项目成功经验项目成功经验6.2 项目失败教训项目失败教训6.3 项目组建议项目组建议
