项目总结报告-模板

****系统项目总结报告

编号：

版本: 1.0

1.1 项目背景

****物资供应处承担着****生产建设的物资供应任务，每年要完成80亿元人民币左右的采购。物资管理体制也有“归口管理、集中采购、统一储备、统一结算”的要求。同时物资供应处是****计算机应用较好的单位，已经有很好的软硬件基础。所以应用一套覆盖供应处业务需求的完整系统成为最迫切的需求。

物资供应信息化过程中需要解决如下问题：

1、业务流程需要进一步的统一、规范和优化。

2、物流、资金流、信息流没能同步发生变化，信息共享性和继承应用没有发挥出应有的价值和作用。

3、多数的统计报表仍依靠手工方式统计，不仅增加统计人员的工作量，而且报表上报周期长，易出错。

4、海量的业务数据没有形成历史数据库，不能为领导决策提供科学有力的支持。

****公司在前期咨询和调研过程中对供应处现有的业务做了诊断，预见了****物流、资金流信息系统建设预期收益：

1、提高企业精细化管理和规范化运作的水平

2、规范核心业务流程，配置最佳业务模式

3、大幅降低的库存成本

4、快速的市场反应能力

5、极大提高的用料单位满意度

6、领先一步的竞争优势

1.2 开发工具和环境

2.1里程碑回顾

根据项目的实施情况，我们分7个里程碑。

2.1.1项目启动

起始时间：从2002-12-25到2003-01-07

工作内容：项目准备、UML培训、方法论培训

提交产品：

1、需求开发计划。

2.1.2需求开发

起始时间：从2003-01-07到2003-03-22

工作内容：需求分析方法论培训，页面原型、项目估算、系统分析，制定计划提交产品：

1、需求规格说明书(共5分册)

2、页面原型

3、****物流资金流项目术语表

4、工作量估算表(功能点)

5、工作量估算表(页面原型)

6、Use Case图

7、需求矩阵

8、软件开发计划书

9、需求规格说明书

2.1.3需求分析和设计(第一阶段)

起始时间：从2003-03-23到2003-08-17

工作内容：项目汇报，需求确认，需求优化、数据库设计、概要设计、开发培训提交产品：

1、项目汇报0326，0330，0414，0818

2、Rose需求文档

3、完善word需求文档(需求确认签字后的)

4、ppt需求文档

5、优化的业务流程和静态原型

6、数据库设计初稿(发料、计划、收料、采购)

7、struts培训教材

2.1.4设计和开发阶段1、2、3、4(武汉时期)

起始时间：从2003-08-17到2003-11-22

工作内容：需求优化、数据库设计、java接口设计、培训、程序开发测试

提交产品：

1、数据库设计slof.pdm(计划、采购、收发存、检验、供应商、编码模块设计)

2、开发计划1、2、

3、4(Excel表，用于PCT跟踪)

3、页面规范及标准

4、单据编号规则

5、配置管理计划

6、开发测试验收(PCT)流程

7、设计说明书(分模块)

8、数据库设计说明书-数据字典(Word文档)

9、struts在iPlanet下的部署说明

2.1.5开发阶段5－12和双轨运行(东营时期)

起始时间：从2003-11-23到2004-04-28

工作内容：详细设计、程序开发测试、数据准备、实施准备、安装、客户培训提交产品：

1、开发计划5-12(Excel表，用于PCT跟踪)

2、设计说明书(分模块)

3、卡机接口方案

4、数据初始化方案

5、数据接口方案

6、培训教材(分模块)

7、用户手册(分模块)

8、问题反馈汇总单

9、系统试运行监测报告

10、报表平台开发计划

11、供应商平台开发计划

12、决策平台开发计划

2.1.6单轨运行(正式运行)

起始时间：从2004-04-28到现在

工作内容：实施、运行、反馈修改

提交产品：

1、新需求问题清单

2、软件问题清单及修改记录

3、移交报告

4、发布清单

2.1.7项目验收

起始时间：从2004-08-09到2004-08-18

工作内容：验收准备、项目验收

提交产品：

1、验收报告

2、项目总结报告

2.2 规模统计

2.3 工作量统计

2.4 工作量分布

以下是根据数据做的分析结果：

数据分析：从任务分布上看，前期需求和设计阶段学习和评审的比重比较大，很多时间都浪费在学习、培训和评审上。主要的培训包括：

1、方法论的培训

2、UML的培训

3、新技术培训

4、学生的培训

数据分析：从学习曲线上来看，下降幅度比较大，由于团队组建初期多数都是学生，各SA也达不到项目要求，在编码和测试阶段学习的比重就不多了，团队逐渐走向成熟。

2.5 工作量比例统计

统计各类型任务的工作量比例及在各阶段的投入比例

以下是根据数据做的分析结果：

数据分析：从各阶段比例来看，我们的实际比例和估算报价的比例有些差异，标准报价是按照编码工作量进行估算报价的，以编码的3.3倍为总工作量。这说明两个问题：

1、胜利项目的平均生产率比较高，高于公司的平均水平，和现场开发有关。

2、开发初期代码开发的工作量估计不足。

数据分析：从工作量分布情况来看，分析阶段存在大量编码工作，但此阶段编码大多被废弃，因为：

1、分析设计质量不高。

2、学生写代码没有经验。

3、新技术的摸索工作。

实施阶段的编码工作量很大，说明实施中有需求的变更，导致重新设计和编码、测试工作。

2.6 成本统计(按实际工作量)

各阶段各角色投入比例，单位：万元

2.7 缺陷分布

2.7.1缺陷清除率100%

公式：

缺陷清除率= 发布验收前发现的缺陷/ （发布验收前发现的缺陷+ 验收测试发现的缺陷）

所占缺陷百分比= 当前阶段引入的缺陷数/ 所有检测到的缺陷数

数据分析：从数据中可以看出，我们在系统测试中的缺陷比较大，说明评审工作做的不到位，特别是需求和设计评审。

数据分析：由于需求、设计评审的工作不到位，导致其它缺陷比较多，建议以后的项目加强需求和设计评审。同类项目海油服仓储系统缺陷914个，****项目的工作量是海油服仓储的4倍，同比下缺陷要低。

2.7.2缺陷发生的模块

数据分析：按照各模块的开发顺序来看，缺陷主要集中在计划、收发料模块，这部分动手比较早，所以缺陷比较多。经过几次缺陷总结会议和大家对业务的熟悉，降低了同类型缺陷的发生。

2.7.3缺陷严重级别

2.7.4缺陷类型统计

2.8 风险管理

项目中的存在技术风险、时间风险等多个风险，以下只罗列技术风险：

1、WEB下卡机的使用，刷卡结算。由于普安联盟用Delphi写的动态连接库，在IE客户端调用有一定的困难。所以是风险中最大的技术风险。

提前预测：由XXX和XXX最终解决。

２、报表工具选型与使用。****报表繁多，而且上报到中石化，所以报表工具的选取成为一个严重的技术问题，选取的不好可能会导致开发难度大和工作量大等问题。

提前预测：由张桐解决。

３、结算模块的财务接口设计。与财务系统的接口在技术实现上存在一定的难度，数据的传递也很难保证实时性。

提前预测：由XXX解决。

４、数据移植方案与实施。****系统与原有旧系统的差异比较大，所以数据的迁移是比较大的风险。数据比较复杂，对帐工作也比较复杂。

提前预测：由XXX解决。

５、iPlanet下系统安装与调试，系统采用Struts技术，开始设计并没有考虑到关键计算机资源，所以调试在Tomcat下进行，只是理论上认为可以发布。

提前预测：由XXX解决。

6、权限分配与菜单显示。胜利系统有上千个菜单项，层次比较多，检索查询的

速度比较慢，所以实现菜单的动态分配在算法上要优化。

提前预测：由张新瑞解决。

7、月度对帐与结账。结账是物流系统中最重要的环节，涉及到对帐和对报表的影响，所以实现起来比较困难。

提前预测：由XXX、金光涛解决

8、单据打印控件选择与实现，单据打印是最常用的功能，和打印机和控件的选择也密不可分。

提前预测：由张桐、廖巍解决。

9、审批的后台实现，审批是业务环节中比较重要的部分，实现起来也比较复杂，设计的难度也比较大。

提前预测：由XXX、李兵解决

10、iAS7.0档机，系统实施运行很长时间来经常出现宕机现象，影响系统的使用，客户意见很大。

提前预测：由XXX、黎希最终解决。

3项目总结

3.1 项目收获

3.1.1团队的建设

****项目培养出了一个效率高、响应快的团队，现在胜利项目释放的设计、开发人员在××××等项目中充当绝对主力的角色。主要表现在以下方面：

1、技术架构的统一和推广。

2、业务知识的培训与传递。

3、工作态度和敬业精神的感染力。

4、项目实施和管理理论的继承性。

5、对以后团队建设的推动力。

3.1.2业务的积累

****项目的业务范围覆盖了石油行业上游企业的所有业务需求，在行业内具有推广价值，主要积累的业务方向如下：

1、企业分级计划业务

2、企业采购和招标业务

3、企业合同管理业务

4、企业检验管理业务

5、企业进销存管理业务

6、企业财务结算业务

7、企业供应商管理业务

8、企业物料加工业务

9、企业配送管理业务

10、企业价格管理业务

3.1.3技术的积累

****系统采用了最新的技术和最新的中间件产品，技术上也有所突破，主要表现在以下方面：

1、Struts框架的全面应用。

2、Sun One iAS7.0企业版的应用。

3、报表工具的应用。

4、与硬件设备的交互。

5、财务接口的设计与实现。

6、菜单的动态生成技术。

7、页面冻结技术。

8、系统按流程和企业特点自由配置技术。

3.1.4客户的认可

项目实施过程中表现了****专业化的服务精神，在实施中总结了一系列的和客户沟通的方法。得到客户的充分认可。具体采用的措施如下：

1、电话服务、问题的跟踪和记录

2、邮件服务、每个问题有专门人员做回答。

3、现场服务、到客户现场解决问题。

4、发动群众、让比较熟悉的业务人员进行操作培训。

5、定期汇报、定期向有关领导汇报项目进展情况和问题解决情况。

3.2 项目损失

项目设计、开发、实施过程中有很多不足，主要表现在如下方面：

1、对于这么大的项目前期在开发方法论上有很大争议。

2、开发框架的选型上没有经过很好的评估。

3、对项目的技术风险的发现太迟。

4、套用使用CMM过程，对过程的不理解。

5、项目中很多无效的评审，浪费很多时间。

6、前期对困难估计不足，

7、对项目的进度过于乐观，导致各阶段都有延误。

8、项目费用的超支。

4开发和管理过程

4.1 过程说明

项目实施时，公司还没有过CMM3级，按照CMM2级过程实施。

4.2 过程改进建议

4.2.1需求管理改进意见

关于3.2节的变更流程过于复杂，在客户现场无法实施，客户提出问题都时紧急问题，我们在客户现场的变更流程如下：

1、接到客户变更请求（客户）

2、变更影响范围分析（主分析员）

3、SCCB进行审批，通过后进行变更处理。不通过变更记录处于挂起状态，通知客户并和客户达成一致。（项目经理）

其它流程和公司一致。

4.2.2计划及跟踪过程改进意见

1、对于过大的项目例会不宜太频繁，导致整体效率低。可以采用局部会议的形式，只和相关人员和受影响的人员或受影响的组进行即可。

2、计划跟踪应该每天进行跟踪，得到汇总值。

3、评审的过程没有问题，但过程的执行和控制很难把握。没有量化的指标，例如大项目的需求规格说明书评审时间，评审会议次数范围等等。

4.2.3配置管理过程改进意见

1、项目级管理过程应该从售前阶段开始，至项目验收后三个月结束。

2、发布子过程，在实施中应该可以多次发布，所以实施中应该增加产品发布计划子过程。因为这直接影响客户的使用。

3、开发库关闭后，产品维护的过程没有定义。

4、没有产品分支的处理流程。

4.2.4质量保证过程改进意见

1、QA的评审检查单不太符合实际情况，只能做表面检查。

2、QA的工作很难到位。