项目总结报告总结归纳
发布时间:2020-05-17 09:48:26
发布时间:2020-05-17 09:48:26
文件编号:
<项目名称>
项目总结报告
部 门: | |
编 写: | |
审 核: | |
批 准: | |
日 期: | |
公司
文件修订记录
时间 | 作者 | 主要修订内容 |
[阐明编写本总结报告的目的,指出读者对象。]
[可包括本项目的来源、委托单位、开发单位和主管部门等。]
项目中文全称: | |
客户: | |
项目经理: | |
项目开始日期: | |
项目结束日期: | |
项目成员: | |
项目所属类型: | |
采用的生命周期模型: | |
硬件平台: | |
应用领域: | |
使用工具: | |
开发语言: | |
数据库: | |
客户目标: | 〔描述客户对项目的总体要求,以及需要达到的目标。例如: 1. 应当解决当前系统存在的一些问题,尤其是易用性、可靠性的问题; 2. 应当允许平台的独立性; 3. 应当能从所有的客户站点方便地进入平台。 〕 |
项目质量目标: | 〔描述产品在交付时期应达到的质量要求,以及不同阶段的缺陷率控制要求。例如: 1. 交付时缺陷密度:缺陷/KLOC; 2. 需求评审缺陷率:10%~15%; 3. ……。 〕 |
〔项目的主要交付产品列表〕:
产品名称 | 产品规模 | 规模单位 | 完成日期 | 是否通过验收 |
需求规格说明书 | 25 | 页 | ||
系统设计说明书 | 72 | 页 | ||
源代码 | KLOC | |||
可执行代码 | ||||
用户手册 | 页 | |||
〔研发项目专用。〕
里程碑 | 计划日期 | 实际日期 | 差异 |
项目开始 | 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 |
测试代码基线 | 2004年7月12日 | 2004年7月28日 | -16 |
版系统发布 | 2004年8月1日 | ||
客户中期检查和验收材料 | 2004年9月30日 | ||
测试代码基线 | 2004年10月4日 | ||
系统发布 | 2004年11月17日 | ||
项目结束 | 2004年11月30日 | ||
● 工作量分布:
〔可参考阶段报告里的工作量分布图〕
〔研发项目专用,描述项目各阶段计划规模与实际规模的对比情况,并分析发生偏差的原因〕
阶段 | 里程碑 | 软件估计规模 (功能点) | 软件实际规模 (功能点) |
计划 | 软件计划评审通过 | - | |
需求 | 需求规格说明书评审通过 | - | |
设计 | 系统设计说明书评审通过 | - | |
编码 | 源代码评审通过 | - | |
测试 | 系统测试完成 | - | |
发布 | 产品发布完成 | - | |
〔描述项目各阶段发现的缺陷数,下面的例子是针对研发项目的,实施和维护项目可以根据各自项目的特点设置检查点。〕
检查点 | 缺陷发现数目 |
用户需求评审 | |
软件需求评审 | |
架构设计评审 | |
设计评审 | |
代码评审 | |
测试 | |
图示分析:〔根据分析图进一步分析现状发生的原因。〕
〔可以参考项目的问题列表和风险列表的格式〕
缺陷数 | 严重缺陷数 | 严重缺陷比率 | 缺陷密度 | |
发布时 | ||||
目标值 | ||||
产品质量评价:
〔总结该软件项目或软件产品开发时所采用的各项技术〕
〔以下是示例:〕
● 对开发工具的评价:
✓ UBS-HotBilling使用TT作为内存数据库,提高了应用处理的性能。试点割接上线后正常运行,并且为OCS系统上线提供了实践依据,并积累了实施开发经验。
● 对框架技术的评价:从整个框架的整体使用效果来看并为达到预期的目的,我认为主要是由以下原因造成的:
✓ 框架本身存在有诸多不完善的地方,需要不断地进行改进,但在改进的过程中没有进行严格的控制,导致框架的整体设计失控;
✓ 框架本身有这样那样的问题,有些问题是目前无法解决的;
✓ 框架是建构在PFC的基础上的,项目组成员对PFC不是足够的精通,为维护框架带来难度。
✓ 建议:模块化是产品化的基础,也是降低成本、提高开发效率保证软件质量的有效手段,需要有专人设计和维护框架。
● 对设计方法的评价:信息化项目的整体设计是由项目组全体成员完成的,鉴于我们目前的设计水平,我看还可继续这种方法,对设计的方法和思路进行广泛的借鉴,但一定要树立设计的权威性,对设计的变更要进行严格的控制。
● 对团队开发的评价:从整体上讲我们这个团队的能力还可以,但我认为它的生产效率并不高也就是说团队的整体建设不好,没有明确的学习方向分工,使整个团队在这段时间里整体能力没有太大的提高,我以前很想把我们的团队培养成那种学习型的优秀团队,可惜事与愿违这项工作没有取得什么实效。
〔研发项目专用〕
最初的需求数: | |
已实现的需求数: | |
已删除的需求数: | |
已修订的需求数: | |
新增的需求数: | |
〔总结项目的不同阶段所发生的需求变更次数及发生变更的主要原因。〕
变更发生的阶段 | 需求变更次数 | 变更工作量 (从申请开始到变更结束发生的工作量) |
用户需求定义 | ||
软件需求分析 | ||
设计 | ||
编码 | ||
测试 | ||
维护 | ||
需求变更的主要原因:
序号 | 变更发生阶段 | 变更原因 | 变更内容 | 变更是否允许 |
1 | ||||
2 | ||||
3 | ||||