项目总结报告模板Word格式.doc
《项目总结报告模板Word格式.doc》由会员分享,可在线阅读,更多相关《项目总结报告模板Word格式.doc(10页珍藏版)》请在冰豆网上搜索。
1.2 项目背景 2
1.3 参考资料 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
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年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工作量分布
l工作量分布:
〔可参考阶段报告里的工作量分布图〕
3.4.3规模
〔研发项目专用,描述项目各阶段计划规模与实际规模的对比情况,并分析发生偏差的原因〕
阶段
软件估计规模
(功能点)
软件实际规模
计划
软件计划评审通过
-
需求
需求规格说明书评审通过
设计
系统设计说明书评审通过
编码
源代码评审通过
测试
系统测试完成
发布
产品发布完成
3.4.4缺陷
〔描述项目各阶段发现的缺陷数,下面的例子是针对研发项目的,实施和维护项目可以根据各自项目的特点设置检查点。
检查点
缺陷发现数目
用户需求评审
软件需求评审
架构设计评审
设计评审
代码评审
图示分析:
〔根据分析图进一步分析现状发生的原因。
3.4.5主要问题和风险
〔可以参考项目的问题列表和风险列表的格式〕
3.5可推行复用的软件技术成果
4项目开发工作评价
4.1产品质量评价
缺陷数
严重缺陷数
严重缺陷比率
缺陷密度
发布时
目标值
产品质量评价:
4.2技术方法评价
〔总结该软件项目或软件产品开发时所采用的各项技术〕
〔以下是示例:
l对开发工具的评价:
ü
UBS-HotBilling使用TT作为内存数据库,提高了应用处理的性能。
试点割接上线后正常运行,并且为OCS系统上线提供了实践依据,并积累了实施开发经验。
l对框架技术的评价:
从整个框架的整体使用效果来看并为达到预期的目的,我认为主要是由以下原因造成的:
框架本身存在有诸多不完善的地方,需要不断地进行改进,但在改进的过程中没有进行严格的控制,导致框架的整体设计失控;
框架本身有这样那样的问题,有些问题是目前无法解决的;
框架是建构在PFC的基础上的,项目组成员对PFC不是足够的精通,为维护框架带来难度。
建议:
模块化是产品化的基础,也是降低成本、提高开发效率保证软件质量的有效手段,需要有专人设计和维护框架。
l对设计方法的评价:
信息化项目的整体设计是由项目组全体成员完成的,鉴于我们目前的设计水平,我看还可继续这种方法,对设计的方法和思路进行广泛的借鉴,但一定要树立设计的权威性,对设计的变更要进行严格的控制。
l对团队开发的评价:
从整体上讲我们这个团队的能力还可以,但我认为它的生产效率并不高也就是说团队的整体建设不好,没有明确的学习方向分工,使整个团队在这段时间里整体能力没有太大的提高,我以前很想把我们的团队培养成那种学习型的优秀团队,可惜事与愿违这项工作没有取得什么实效。
5项目管理工作评价
5.1需求管理
〔研发项目专用〕
5.1.1需求完成情况
最初的需求数:
已实现的需求数:
已删除的需求数:
已修订的需求数:
新增的需求数:
5.1.2需求变更情况
〔总结项目的不同阶段所发生的需求变更次数及发生变更的主要原因。
变更发生的阶段
需求变更次数
变更工作量
(从申请开始到变更结束发生的工作量)
用户需求定义
软件需求分析
维护
需求变更的主要原因:
5.2计划管理
5.2.1计划变更情况
序号
变更发生阶段
变更原因
变更内容
变更是否允许
1
2
3
6经验教训
6.1项目成功经验
6.2项目失败教训
6.3项目组建议