项目总结报告模板Word文档下载推荐.docx

项目总结报告模板Word文档下载推荐.docx

《项目总结报告模板Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《项目总结报告模板Word文档下载推荐.docx（10页珍藏版）》请在冰豆网上搜索。

3参考资

2

2项目基本情

况

2.1项目基本信

息

2.2项目特

征

2・3项目目

标

3

3项目执行结

果

3.1交付产

品

3.2主要功能和性

能

3.3项目遗留问

题

4

3・4项目性能数

据

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

.6

4项目开发工作评

价

6

4.1产品质量评

4.2技术方法评

5项目管理工作评

7

5.1需求管

理

5.2计划管

8

6经验教

训

6.1项目成功经

验

6・2项目失败教

6.3项目组建

议

Pagelof10

1引言

1・1目的

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

］

1・2项目背景

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

1・3参考资料

2项目基本情况2.1项目基本信息

项目中文全称：

客户：

项目经理：

项目开始日期：

项目结束日期：

项目成员：

2.2项目特征

项目所属类型：

采用的生命周期模型：

硬件平台：

应用领域：

使用工具：

开发语言：

数据库：

X

X.

客户目标••—描述客户对

如:

及需要达到的目标

性

重目标・・—描述产品在交付怖

解应器能从所有的客户站点方便地进入平台。

1/X•

廈率控制要求。

例如：

算交付时缺陷密度：

0.2缺陷/KL0C；

2.陷率：

10%〜15%；

3-……o

;

<

诲完成日.期应达用页交主1••2少顼曹枭要交付产13.

3・3项目遗留问题

3・4项目性能数据

3.4・1进度

里程碑计划日期实际日其］差异

项目开始2004年3月1E

日2004年3月15H

需求基线2004年4月3（

日2004年5月24日

-24

系统架构设计2004年5

月26日2004年5月2

1日5

系统分析和设计基线20（

4年6月11日2004句

月7日4

V2.5测试代码基线2004

年7月12H2004年

月28H-16

V2.5版系统发布2004年

8月1日

客户中期检查和验收20（

材料

4年9月30日

V3.0测试代码基线2004

年10月4日

V3.0系统发布2004年1

L月17日

项目结束2004年11月-

0日

3.4.21作量

3.4.2.1匚作量分布

工作量分布：

（可参考阶段报告里的工作量分布图）

3.4.3规模

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

里程碑

软件估计规模软f

（功能点）（功有

卜实际规模阶段

纟点）

计划软件计

划评审通过-

需求需求拟

格说明书评审通过-

设计系统设

计说明书评审通过-

编码源代征

评审通过-

测试系统测

试完成-

发布产品发

布完成-

3.4.4缺陷

（描述项目各阶段发现的缺陷数，下而的例子是针对研发项目的，实施和维护项目可以根据各自

项目的特点设置检查点。

）

检查点缺陷发现;

欢目

用户需求评审

软件需求评审

架构设计评审

设计评审

代码评审

测试

缺陷分布

图示分析：

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

3.4.5主要问题和风险

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

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

4项目开发工作评价

4.1产品质量评价

缺陷数严重缺

陷数严重缺陷比率縮

:

陷密度

发布时

目标值

产品质量评价:

4.2技术方法评价

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

（以下是示例：

对开发工具的评价：

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

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

对框架技术的评价：

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

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

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

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

建议：

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

对设计方法的评价：

信息化项目的整体设计是由项目组全体成员完成的，鉴于我们目前的设

计水平，我看还可继续这种方法，对设计的方法和思路进行广泛的借鉴，但一定要树立设计的权威性，对设计的变更要进行严格的控制。

对团队开发的评价：

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

5项目管理工作评价5.1需求管理

（研发项目专用）

5.1・1需求完成情况

最初的需求数：

已实现的需求数：

已删除的需求数：

已修订的需求数：

新增的需求数：

5.1・2需求变更情况

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

变更发生的阶段需求变更次

放变更工作量

（从申请开始到变更

结束发生的工作量）

用户需求定义

软件需求分析

设计

编码

维护

需求变更的主要原因:

5.2计划管理

5.2・1计划变更情况

序号变更:

良生阶段变更原因

变更内容变更是否允许

1

3

6经验教训

6.1项目成功经验

6.2项目失败教训

6.3项目组建议