项目总结报告归纳.docxVIP

文件编号： 项目名称 项目总结报告 部门： 编写： 审核： 批准： 日期： 企业 文件订正记录 时间作者主要订正内容 目录 前言 1.1目的 [说明编写本总结报告的目的，指出读者对象。] 1.2项目背景 [可包含本项目的根源、拜托单位、开发单位和主管部门等。] 1.3参照资料 项目基本状况 2.1项目基本信息 项目中文全称： 客户： 项目经理： 项目开始日期： 项目结束日期： 项目成员： 2.2项目特色 项目所属种类： 采纳的生命周期模 型： 硬件平台： 应用领域： 使用工具： 开发语言： 数据库： 2.3项目目标 客目：〔描绘客目的体要求，以及需要达到的目 。比如： 当解决目前系存在的一些，特别是易用性、靠谱性的； 当允平台的独立性； 当能从全部的客站点方便地入平台。 〕 目量目：〔描绘品在交托期达到的量要求，以及不 同段的缺点率控制要求。比如： 交托缺点密度：0.2缺点/KLOC； 需求缺点率：10%～15%； ??。 〕 项目履行结果 3.1交托产品 〔目的主要交托品列表〕： 品名称品  模位  达成日期  能否通 模  收 需求格明  25 系明  72 源代  KLOC 可行代 用手册 3.2主要功能和性能 〔研发项目专用。〕 3.3项目遗留问题 3.4项目性能数据 3.4.1进度 里程碑 计划日期 项目开始 2004 年3月15日 需求基线 2004 年4月30日 系统架构设计 2004 年5月26日 系统剖析和设计基 2004 年6月11日 线 V2.5 测试代码基线 2004 年7月12日 V2.5 版系统公布 2004年8月1日 客户中期检查和验 2004 年9月30 日 收资料 V3.0 测试代码基线 2004 年10月4日 V3.0 系统公布 2004年11月17 日 项目结束 2004年11月30 日  实质日期 差别 2004 年3月15日 0 2004 年5月24日 -24 2004 年5月21日 5 2004年6月7日4 2004年7月28日-16 3.4.2工作量 3.4.2.1工作量散布 工作量散布： 〔可参照阶段报告里的工作量散布图〕 3.4.3规模 〔研发项目专用，描绘项目各阶段计划规模与实质规模的对照状况，并剖析发生误差 的原由〕 阶段 里程碑 软件预计规模 软件实质规模 （功能点） (功能点) 计划 软件计划评审经过 - 需求 需求规格说明书评审经过 - 设计 系统设计说明书评审经过 - 编码 源代码评审经过 - 测试 系统测试达成 - 公布 产品公布达成 -  3.4.4缺 陷 〔描绘项 目各阶段 发现的缺 陷数，下 面的例子是针对研发项目的，实行和保护项目能够依据各自项目的特色设置检查点。〕 检查点缺点发现数量 用户需求评 审 软件需求评 审 架构设计评 审 设计评审 代码评审 测试 图示剖析：〔依据剖析图进一步剖析现状发生的原由。〕 4.5主要问题微风险 〔能够参照项目的问题列表微风险列表的格式〕 3.5可实行复用的软件技术成就 项目开发工作评论 4.1产质量量评论 缺点数严重缺点数严重缺点比率缺点密度 公布时 目标值 产质量量评论： 4.2技术方法评论 〔总结该软件项目或软件产品开发时所采纳的各项技术〕 〔以下是示例：〕 对开发工具的评论： UBS-HotBilling使用TT作为内存数据库，提升了应用办理的性能。试点割接 上线后正常运转，而且为OCS系统上线供给了实践依照，并累积了实行开发经验。 对框架技术的评论：从整个框架的整体使用成效来看并为达到预期的目的，我以为主假如由以下原由造成的： 框架自己存在有诸多不完美的地方，需要不停地进行改良，但在改良的过程中没有进行严格的控制，致使框架的整体设计失控； 框架自己有这样那样的问题，有些问题是目前没法解决的； 框架是建构在PFC的基础上的，项目构成员对PFC不是足够的精晓，为保护框架带来难度。 建议：模块化是产品化的基础，也是降低成本、提升开发效率保证软件质量的有效手段，需要有专人设计和保护框架。 对设计方法的评论：信息化项目的整体设计是由项目组全体成员达成的，基于我们目前的设计水平，我看还可持续这类方法，对设计的方法和思路进行宽泛的借鉴，但必定要建立设计的威望性，对设计的更改要进行严格的控制。 对团队开发的评论：从整体上讲我们这个团队的能力还能够，但我以为它的生产效率其实不高也就是说团队的整体建设不好，没有明确的学习方向分工，使整个团队在这段时间里整体能力没有太大的提升，我从前很想把我们的团队培育成那种学习型的优异团队，惋惜适得其反这项工作没有获得什么实效。 项目管理工作评论 5.1需求管理 〔研发项目专用〕 1.1需求达成状况 最先的需求数： 已实现的需求数： 已删除的需求数： 已订正的需求数： 新增的需