项目总结材料报告材料实用模板.docx

项目总结材料报告材料实用模板.docx

《项目总结材料报告材料实用模板.docx》由会员分享，可在线阅读，更多相关《项目总结材料报告材料实用模板.docx（10页珍藏版）》请在冰点文库上搜索。

项目总结材料报告材料实用模板

文件编号：

版本号：

1.0

<项目名称>

项目总结报告

部门：

编写：

审核：

批准：

日期：

YYYY.MM.DD

公司

文件修订记录

时间

作者

主要修订内容

YYYY.MM.DD

1引言

1.1目的

[阐明编写本总结报告的目的，指出读者对象。

]

1.2项目背景

[可包括本项目的来源、委托单位、开发单位和主管部门等。

]

1.3参考资料

2项目基本情况

2.1项目基本信息

项目中文全称：

客户：

项目经理：

项目开始日期：

项目结束日期：

项目成员：

2.2项目特征

项目所属类型：

采用的生命周期模型：

硬件平台：

应用领域：

使用工具：

开发语言：

数据库：

2.3项目目标

客户目标：

〔描述客户对项目的总体要求，以及需要达到的目标。

例如：

1.应当解决当前系统存在的一些问题，尤其是易用性、可靠性的问题；

2.应当允许平台的独立性；

3.应当能从所有的客户站点方便地进入平台。

〕

项目质量目标：

〔描述产品在交付时期应达到的质量要求，以及不同阶段的缺陷率控制要求。

例如：

1.交付时缺陷密度：

0.2缺陷/KLOC；

2.需求评审缺陷率：

10%～15%；

3.……。

〕

3项目执行结果

3.1交付产品

〔项目的主要交付产品列表〕：

产品名称

产品规模

规模单位

完成日期

是否通过验收

需求规格说明书

25

页

系统设计说明书

72

页

源代码

KLOC

可执行代码

用户手册

页

3.2主要功能和性能

〔研发项目专用。

〕

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

系统分析和设计基线

2004年6月11日

2004年6月7日

4

V2.5测试代码基线

2004年7月12日

2004年7月28日

-16

V2.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规模

〔研发项目专用，描述项目各阶段计划规模与实际规模的对比情况，并分析发生偏差的原因〕

阶段

里程碑

软件估计规模

（功能点）

软件实际规模

（功能点）

计划

软件计划评审通过

-

需求

需求规格说明书评审通过

-

设计

系统设计说明书评审通过

-

编码

源代码评审通过

-

测试

系统测试完成

-

发布

产品发布完成

-

3.4.4缺陷

〔描述项目各阶段发现的缺陷数，下面的例子是针对研发项目的，实施和维护项目可以根据各自项目的特点设置检查点。

〕

检查点

缺陷发现数目

用户需求评审

软件需求评审

架构设计评审

设计评审

代码评审

测试

图示分析：

〔根据分析图进一步分析现状发生的原因。

〕

3.4.5主要问题和风险

〔可以参考项目的问题列表和风险列表的格式〕

3.5可推行复用的软件技术成果

4项目开发工作评价

4.1产品质量评价

缺陷数

严重缺陷数

严重缺陷比率

缺陷密度

发布时

目标值

产品质量评价：

4.2技术方法评价

〔总结该软件项目或软件产品开发时所采用的各项技术〕

〔以下是示例：

〕

●对开发工具的评价：

✓UBS-HotBilling使用TT作为内存数据库，提高了应用处理的性能。

试点割接上线后正常运行，并且为OCS系统上线提供了实践依据，并积累了实施开发经验。

●对框架技术的评价：

从整个框架的整体使用效果来看并为达到预期的目的，我认为主要是由以下原因造成的：

✓框架本身存在有诸多不完善的地方，需要不断地进行改进，但在改进的过程中没有进行严格的控制，导致框架的整体设计失控；

✓框架本身有这样那样的问题，有些问题是目前无法解决的；

✓框架是建构在PFC的基础上的，项目组成员对PFC不是足够的精通，为维护框架带来难度。

✓建议：

模块化是产品化的基础，也是降低成本、提高开发效率保证软件质量的有效手段，需要有专人设计和维护框架。

●对设计方法的评价：

信息化项目的整体设计是由项目组全体成员完成的，鉴于我们目前的设计水平，我看还可继续这种方法，对设计的方法和思路进行广泛的借鉴，但一定要树立设计的权威性，对设计的变更要进行严格的控制。

●对团队开发的评价：

从整体上讲我们这个团队的能力还可以，但我认为它的生产效率并不高也就是说团队的整体建设不好，没有明确的学习方向分工，使整个团队在这段时间里整体能力没有太大的提高，我以前很想把我们的团队培养成那种学习型的优秀团队，可惜事与愿违这项工作没有取得什么实效。

5项目管理工作评价

5.1需求管理

〔研发项目专用〕

5.1.1需求完成情况

最初的需求数：

已实现的需求数：

已删除的需求数：

已修订的需求数：

新增的需求数：

5.1.2需求变更情况

〔总结项目的不同阶段所发生的需求变更次数及发生变更的主要原因。

〕

变更发生的阶段

需求变更次数

变更工作量

（从申请开始到变更结束发生的工作量）

用户需求定义

软件需求分析

设计

编码

测试

维护

需求变更的主要原因：

5.2计划管理

5.2.1计划变更情况

序号

变更发生阶段

变更原因

变更内容

变更是否允许

1

2

3

6经验教训

6.1项目成功经验

6.2项目失败教训

6.3项目组建议