项目总结报告模板.docx

资源描述

项目总结报告模板.docx

《项目总结报告模板.docx》由会员分享，可在线阅读，更多相关《项目总结报告模板.docx（23页珍藏版）》请在冰点文库上搜索。

项目总结报告模板.docx

项目总结报告模板

""系统

项目总结报告

编号:

版本：

1.0

作者：

日期：

审批：

日期：

1项目信息

1.1项目背景

林林物资供应处承担着林杯生产建设的物资供应任务，每年要完成80亿元人民币左右的采购。

物资管理体制也有“归口管理、集中采购、统一储备、统一结算”的要求。

同时物资供应处是****汁算机应用较好的单位，已经有很好的软硬件基础。

所以应用一套覆盖供应处业务需求的完整系统成为最迫切的需求。

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

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

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

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

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

林林公司在询期咨询和调研过程中对供应处现有的业务做了诊断，预见了"

物流、资金流信息系统建设预期收益：

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

2、

3、

4、

5、

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

大幅降低的库存成本

快速的市场反应能力

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

6、

领先一步的竞争优势

1.2开发工具和环境

分类

环境

预计环境

实际环境

硬件

应用服务器

Sun48004domainCD

数据库服务器

Sun48004domainAB

报表服务器

SunV880

Sun48004domainCD

软件

操作系统

Solaris8

Solaris9

数据库

Oracle9iUS7ASCII

Oracle9iZH16GBK

应用服务器

iPlanet6.5

SunOneiAS7.0

Java集成环境

Eclipse

JDK版本

131

142

Framework

Struts

2项目数据

2.1里程碑回顾

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

2.1.1项目启动

起始时间：

从2002-12-25到2003-01-07

工作内容：

项H准备、UML培训、方法论培训

提交产品：

1、需求开发计划。

2.1.2需求开发

起始时间：

从2003-01-07到2003-03-22

工作内容：

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

2、

1、需求规格说明书（共5分册）

页面原型

3、

4、

5、

****物流资金流项|_|术语表

工作量佔算表（功能点）

工作量佔算表（页面原型）

6、

7、

8、

9、

UseCase图

需求矩阵

软件开发计划书

需求规格说明书

2.13需求分析和设计（第一阶段）

起始时间：

从2003-03-23到2003-08-17

工作内容：

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

1、项U汇报0326,0330,0414,0818

2、

3、

4、

5、

Rose需求文档

完善word需求文档（需求确认签字后的）

ppt需求文档

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

6、

7、

数据库设汁初稿（发料、计划、收料、采购）

struts培训教材

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

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

工作内容：

需求优化、数据库设计、java接口设计、培训、程序开发测试提交产品：

I、数据库设计slof.pdm（计划、采购、收发存、检验、供应商、编码模块设计）开发计划1、2、3、4（Excel表，用于PCT跟踪）页面规范及标准单据编号规则配置管理计划

开发测试验收（PCT）流程

设计说明书（分模块）

数据库设汁说明书-数据字典（Word文档）

struts在iPlanet下的部署说明2.1.5开发阶段5—12和双轨运行（东营时期）

起始时间：

从2003-11-23到2004-04-28

工作内容：

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

开发计划5-I2（Excel表，用于PCT跟踪）

设计说明书（分模块）

卡机接口方案

数据初始化方案

数据接口方案

培训教材（分模块）

用户手册（分模块）

问题反馈汇总单系统试运行监测报告

10、报表平台开发计划

II、供应商平台开发计划

12、决策平台开发计划

2.1.6单轨运行（正式运行）

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

工作内容：

实施、运行、反馈修改

提交产品：

1、新需求问题清单

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

3、移交报告

4、发布清单

2.1.7项目验收

起始时间：

从2004-08-09到2004-08-18

工作内容：

验收准备、项U验收

提交产品；

1、验收报告

2、项U总结报告

22规模统计

序号

分类

工作产品

个数

单位

需求

需求规格说明书

910

页

需求

页面原型

1200

贝

需求

UseCase

628

个

设计

逻辑类UML

2089

个

设计

数据库表个数

249

个

设计

数据库约束个数（外键）

个

设计

接口表个数

个

编码

javaBean个数

2196

个

编码

Jsp个数（.do文件）

2749

个

测试

测试用例个数

618

个

实施

用户手册页数

1558

页

实施

用户手册插图个数

2181

个

实施

培训人次数

3768

次

实施

现场支持和回访

>7500

次

2.3工作量统计

项目组人数

最大Max.24人

最小MiriS人

实际工作量

58446.5人时

7036人日/327人月

24工作量分布

阶段

任务

评审

学习

总计

需求分析

4461.2

1041.9

1122.4

6625.5

设计

6721.2

2800.5

1680.3

11202

编码

24906.5

1136

1144.5

27187

测试

6498

502

402.5

7402.5

实施

4014

项U管理

2015.5

合计

48616.4

5480.4

4349.7

58446.5

各阶段任务分布分析

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

数据分析：

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

主要的培训包括：

1、方法论的培训

2、UML的培训

3、新技术培训

4、学生的培训

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

2.5工作量比例统计

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

任务类型

整个生命周期

需求

分析

设计

编码

实施

需求

2795.5

1506.5

445.5

278

490

75.5

分析

3830

1722

1408.5

56.5

643

设计

11202

5043.5

2747.5

2608

803

编码

27187

3671

7034

11180

5302

项U管理

2015.5

372.5

474

769

400

测试

7402.5

784

2966.5

2530

1122

实施

4014

2027

1987

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

各阶段工作*分布图

□碍求■分析□设计

□编码■项hl管理□测试

■实施

7%5%7%

46%

数据分析：

从各阶段比例来看，我们的实际比例和估算报价的比例有些差异，标准报价是按照编码工作量进行佔算报价的，以编码的3.3倍为总工作量。

这说明两个问题：

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

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

各阶段工作量分布

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

1、分析设计质量不高。

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

3、新技术的摸索工作。

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

2.6成本统计（按实际工作量）

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

万元

序号

人员

时间

费率

成本

484

170

¥82,280.00

2348

125

¥293,500.00

3975

¥29&125.00

3787

¥284,025.00

1030.5

100

¥103,050.00

1237.5

100

¥123,750.00

XXX

1174

170

¥199,580.00

3449.5

100

¥344,950.00

1382

¥103,650.00

2975

125

¥371,875.00

1608

100

¥160,800.00

232

100

¥23,200.00

896

100

¥89,600.00

3599.5

¥269,962.50

2043

¥153,225.00

3489

Y261.675.00

3216.5

¥241.237.50

2725

¥204,375.00

735

¥55,125.00

2470

¥185,250.00

2515

¥18&625.00

1280

100

¥128,000.00

205

¥15,375.00

436

100

¥43,600.00

1424

100

¥142,400.00

310

¥23,250.00

3136.5

¥235,237.50

2365

¥177,375.00

1276

100

¥127,600.00

100

¥0.00

321

¥24,075.00

合计

56125

¥4,954,772.50

2.7缺陷分布

2.7.1缺陷清除率100%

缺陷检测阶段

缺陷注入阶段

总计

所占缺陷百分比

需求

设计

编码

其它

需求评审

296

6.37%

设计评审

423

9.10%

代码评审

542

11.66%

系统测试

358

482

2468

3388

72.88%

验收测试

0.00%

总计

358

482

3010

4649

100%

公式：

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

发现的缺陷）

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

口需求评审■设计评审□代码评审□系统测试■脸收测试

数据分析：

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

各阶段缺陷分布情况

■验收测试□系统测试

□代码评审■设il•评审

□需求评审

数据分析：

山于需求、设讣评审的丄作不到位，导致其它缺陷比较多，建议以后的项U加强需求和设计评审。

同类项U海油服仓储系统缺陷914个，""项U的工作

量是海油服仓储的4倍，同比下缺陷要低。

2.7.2缺陷发生的模块

模块名称

缺陷数

所占缺陷百分比

计划管理

464

13.70%

采购管理

145

4.28%

收料管理

498

14.70%

发料管理

485

14.32%

库存管理

307

9.06%

付款管理

2.72%

检验管理

157

4.63%

合同管理

125

3.69%

价格管理

225

6.64%

供应商管理

0.97%

网上供应商

2.89%

废旧物资

0.71%

配送管理

0.91%

编码管理

2.15%

系统管理

282

8.32%

综合查询

0.18%

统计报表

302

8.91%

其它

1.21%

总数

3388

100%

数据分析：

按照各模块的开发顺序来看，缺陷主要集中在计划、收发料模块，这部分动手比较早，所以缺陷比较多。

经过儿次缺陷总结会议和大家对业务的熟悉，降低了同类型缺陷的发生。

2.7.3缺陷严重级别

严重级别

缺陷数

所占缺陷百分比

灾难性的

0.06%

严重的

2.48%

—般性的

3302

97.46%

合汁

3388

100%

2.7.4缺陷类型统计

缺陷类型

缺陷数

所占缺陷百分比

功能缺陷

2024

59.74%

指派缺陷

1361

40.17%

接口缺陷

0.09%

合汁

3388

100%

2.8风险管理

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

1、WEB下卡机的使用，刷卡结算。

山于普安联盟用Delphi写的动态连接库，在IE客户端调用有一定的困难。

所以是风险中最大的技术风险。

提前预测：

山XXX和XXX最终解决。

2、报表工具选型与使用。

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

提前预测：

由张桐解决。

3、结算模块的财务接口设计。

与财务系统的接口在技术实现上存在一定的难度,数据的传递也很难保证实时性。

提前预测：

由XXX解决。

4、数据移植方案与实施系统与原有旧系统的差异比较大，所以数据的迁移是比较大的风险。

数据比较复杂，对帐工作也比较复杂。

提前预测：

由XXX解决。

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

提前预测：

由XXX解决。

6、权限分配与菜单显示。

胜利系统有上千个菜单项，层次比较多，检索査询的

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

提前预测：

山张新瑞解决。

7、月度对帐与结账。

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

提前预测：

山XXX、金光涛解决

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

提前预测：

山张舸、廖巍解决。

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

提前预测：

山XXX、李兵解决

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

提前预测：

由XXX、黎希最终解决。

3项目总结

3.1项目收获

3.1.1团队的建设

""项U培养出了一个效率高、响应快的团队，现在胜利项目释放的设汁、开发人员在XXXX等项U中充当绝对主力的角色。

主要表现在以下方面：

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

业务知识的培训与传递。

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

项U实施和管理理论的继承性。

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

3.1.2业务的积累

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

企业分级计划业务

2、

3、

4、

企业采购和招标业务

企业合同管理业务

企业检验管理业务

企业进销存管理业务

企业财务结算业务

企业供应商管理业务

企业物料加工业务

企业配送管理业务

10、企业价格管理业务

3.13技术的积累

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

1、Struts框架的全面应用。

SunOneiAS7.0企业版的应用。

报表工具的应用。

与硬件设备的交互。

财务接口的设计与实现。

菜单的动态生成技术。

页面冻结技术。

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

3.1.4客户的认可

项U实施过程中表现了专业化的服务精神，在实施中总结了一系列的和客户沟通的方法。

得到客户的充分认可。

具体采用的措施如下：

1、电话服务、

邮件服务、

现场服务、

发动群众、定期汇报、定期向有关领导汇报项U进展悄况和问题解决悄况。

3.2项目损失

4开发和管理过程

4.1过程说明

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

采用的过程

裁剪说明

需求管理过程

没有裁减

项U计划及跟踪过程

没有裁减

配置管理过程

没有裁减

质量保证过程

没有裁减

4.2过程改进建议

4.2.1需求管理改进意见

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

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

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

3、SCCB进行审批，通过后进行变更处理。

不通过变更记录处于挂起状态，通知客户并和客户达成一致。

（项U经理）

其它流程和公司一致。

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

1、对于过大的项U例会不宜太频繁，导致整体效率低。

可以采用局部会议的形式，只和相关人员和受影响的人员或受影响的组进行即可。

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

3、评审的过程没有问题，但过程的执行和控制很难把握。

没有量化的指标，例如大项U的需求规格说明书评审时间，评审会议次数范围等等。

423配置管理过程改进意见

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

2、发布子过程，在实施中应该可以多次发布，所以实施中应该增加产品发布计划子过程。

W为这直接影响客户的使用。

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

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

4.2.4质量保证过程改进意见

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

2、QA的工作很难到位。

展开阅读全文