项目总结报告模板.docx
- 文档编号:1421302
- 上传时间:2022-10-22
- 格式:DOCX
- 页数:10
- 大小:318.05KB
项目总结报告模板.docx
《项目总结报告模板.docx》由会员分享,可在线阅读,更多相关《项目总结报告模板.docx(10页珍藏版)》请在冰豆网上搜索。
项目总结报告模板
文件编号:
版本号:
1.0
〈项目名称〉
项目总结报告
部门:
编写:
审核:
批准:
日期:
YYYY.MM.DD
文件修订记录
时间作者主要修订
内容
YYYY.MM.DD
1
引言
2
1.1目
的
2项目背
・・・2
3参考资
2
2
2项目基本情
况
2
2.1项目基本信
息
2
2.2项目特
征
2
2・3项目目
标
3
3项目执行结
果
3
3.1交付产
品
3
3.2主要功能和性
能
3
3.3项目遗留问
题
4
3・4项目性能数
据
4
3.5可推行复用的软件技术成
果
.6
4项目开发工作评
价
6
4.1产品质量评
价
6
4.2技术方法评
价
6
5项目管理工作评
价
7
5.1需求管
理
7
5.2计划管
理
8
6经验教
训
8
6.1项目成功经
验
8
6・2项目失败教
训
8
6.3项目组建
议
8
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
0
需求基线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
2
3
6经验教训
6.1项目成功经验
6.2项目失败教训
6.3项目组建议
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 总结报告 模板
![提示](https://static.bdocx.com/images/bang_tan.gif)