软件项目总结报告-xxxx

xxxxx服务平台

总结报告

）

{

xxxx（北京）科技有限公司]

2017年12月

《

一引言

编写目的

XXX有限公司（以下简称“xxxx”）2017年4月25日接受xxxx（以下简称“xxxxx”）委托对三个微信公众号进行升级改造，至今三个公众号的开发任务已经完美完成。写此项目总结报告，首先是为了向xxxx展示xxxx的开发成果，其次是对双方合作工程的一个总结，让我们在以后的合作中能更加顺利、更加完美的完成委托方交给我们的任务。

；

背景

项目名称：XXXX创新创业服务平台

系统名称：XXXX服务管理平台

委托方：

承建方：

二开发成果展示

XXXXXX开发成果

&

XXXX

>

会员导入下载导入模板后，根据模板填写导入会员信息，进

行批量导入。

参数设定对各部门联系电话，人才框架图进行维护。三项目总结状态

进度

*

进度按期完成，因本项目涉及三个公众号不同的业务功能点较多，项目组克服了时间紧，任务重的不利因素，圆满的完成了任务。

工作量

因项目组人员有限，时间紧，工作量比较饱和，另外在开发的过程中存在需求的变更，无形中也增加了不少的工作量，实际的工作量超出了计划预期，后通过赶工的方式赶上了进度。

成本

工作量的增加使时间成本和人员成本都增加了不少，但尚在可控范围内。

规模

代码和文档规模总体上和计划相当，略有增长。

风险

风险主要是需求不明确或需求发生变更所引起的。在项目开发过程中，各部门随着业务的变更，使得系统需求发生变更构成了一定的技术风险，这些风险在相当程度上影响了项目的进度。本项目的风险主要表现在：

需求不断扩充和变更引起的风险

KPA状态

需求管理

需求管理的好坏往往决定这项目的成败。项目开始时，项目组首先建立了需求管理计划。经过和用户的多次沟通和讨论，获取了用户的需求，形成了需求基线，并纳入了版本管理。在设计阶段，用户提出了一些需求方面的变更，经过项目组CCB讨论，同意变更，于是项目组成员进行了相应变更。后经过CCB验证，变更符合要求，变更有效。

里程碑评审

需求阶段的评审：需求分析完成后，需求规格说明书提交到后，项目组相关专家进行了评审。

设计阶段的评审：系统设计阶段完成后，项目组组织有关专家对系统设计进行了评审。

测试阶段的评审：系统开发阶段完成后，项目测试组对系统进行了是否按照需求文档进行开发的评审。

其他

项目部署期间出现的问题，有些是程序的原因，有些则是数据的原因，在导入到数据库之前，整理和规范数据是必要的前提。

四经验教训

原型是用来获取需求的工具，但不应当成需求。

需求要尽可能的明确，不能把问题留到编码阶段。

在需求彻底了解的前提下，尽可能为设计和开发、测试多留时间，才不至于出现前松后紧的现象。

五建议

在项目需求调研阶段应注重对用户业务的理解，加强需求的把握，增强和用户的沟通。项目设计开发阶段要考虑增加必要的系统冗余，以保证日后的需求变更和系统升级。

六结论

项目总体比较成功，工期和成本控制上基本符合预期，开发过程中，团队合作紧密，加班加点，有效保证了交付工期。虽然有很多不是很完美需要改进的地方，但相对于时间紧、任务急，人力有限的实际情况，项目的实施应该还算顺利，这也要得益于客户的积极配合。虽非尽善尽美，但经过用户内测和一系列的优化，争取能最大程度上让客户满意。