CMMI 项目计划实战

淘宝网学习发展系统升级项目项目计划

文件状态:

[√] 草稿

[  ] 正式发布

[  ] 正在修改

文件标识:

NV-QR-TB-PP-01

当前版本:

V1.0

作    者:

Rick

完成日期:

2009-09-30

深圳市XX软件有限公司

版 本 历 史

版本/状态

作者

参与者

起止日期

备注

1.0

Rick

2009-09-29 / 2000-09-30

20

zinger

2009-10-16

 目 录 

0. 文档介绍 4

0.1 文档目的 4

0.2 文档范围 4

0.3 读者对象 4

0.4 参考文献 4

0.5 术语与缩写解释 4

1. 项目介绍 4

1.1客户与最终用户介绍 4

1.2 开发方介绍 5

1.3项目特性和范围 5

2. 项目过程定义 9

2.1标准生命周期 9

2.2 方法与工具 9

2.3项目过程定义的改进 9

3项目目标 10

3.1项目交付物列表 10

3.2假设、依赖和约束 10

4.下属计划清单 11

5.预算和进度计划 11

5.1工程预算 11

5.2工作量估计 12

5.3 任务起止日期 12

6.风险管理计划 13

7.数据管理计划 14

8.项目资源计划 16

9.知识和技能培训计划 17

10.相关人员参与计划 17

10.1项目组织结构 17

10.2人员计划 18

10.3相关人员参与计划 18

11.需求管理计划 19

11.1需求跟踪说明 19

11.2需求变更处理 19

11.3需求管理列表 19

11.4 需求管理的资源、相关人员参与、任务分配情况 20

12.项目计划的管理计划 20

12.1 项目计划的更新 20

12.2 项目计划的资源、人员参与、任务分配情况 21

13.项目监督与控制计划 21

131项目会议 21

13.2项目里程碑 22

13.3 控制阈值 22

13.4 项目监督与控制计划的资源、任务分配、人员参与情况 23

14.度量与分析计划 23

14.1 度量与分析情况 23

14.2 度量分析资源、人员参与情况 25

15. 质量保证计划 25

15.1 质量保证计划 25

15.2 质量保证的资源、人员参与情况 25

16. 配置管理计划 26

16.1 配置管理计划 26

16.2 配置管理的资源、人员参与情况 26

附录 27

术语定义 27

机构领导审批 27

附录项目计划变更控制报告 29

0文档介绍

本文档编写于项目开发前期,对项目中各个方面进行按排和证划。

0.1 文档目的

保证在项目开发过程中,各个项目组或成员能够有计划的展开工作。

0.2 文档范围

本文档主要为制定淘宝网学习发展系统升级项目实施计划。包含项目介绍、各项计划的制定以及人员,资源的分配。

0.3 读者对象

执行人,出资人,相关人,项目小组全体成员。

0.4 参考文献

0.5 术语与缩写解释

缩写、术语

解 释

PP

项目规划,Project Planning

新为

深圳市新为软件有很公司

淘宝

淘宝

1项目介绍

1.1客户与最终用户介绍

本项目的客户(主办)方为淘宝网,淘宝网是亚洲最大网络零售商圈,致力于打造全球首选网络零售商圈,由阿里巴巴集团于2003510日投资创办。淘宝网目前业务跨越C2C(个人对个人)、B2C(商家对个人)两大部分。截至2008年一季度,淘宝网注册会员超6200万人,覆盖了中国绝大部分网购人群;2008年一季度,淘宝网交易额突破188亿;2007年全年成交额突破433亿。根据2007年第三方权威机构调研,淘宝网占据中国网购市场70%以上市场份额,C2C市场占据80%以上市场份额。

本项目的最终用户包括淘宝网、支付宝及阿里巴巴集团的内部员工。

1.2 开发方介绍

本项目的开发方为深圳市新为软件有限公司淘宝项目组,项目负责人为Rick

1.3项目特性和范围

  淘宝网在2006年即成功实施新为SmartLearning 2006学习发展系统,随着淘宝网及阿里巴巴集团业务的不断发展,员工队伍的不断扩大,原有系统已不能满足企业培训学习管理需求,淘宝决定采用新为最新的SmartLearning 2009学习发展系统升级原学习发展系统,同时通过适当的定制开发更好地满足业务需求。项目范围具体包括:

一、 实施SmartLearning 2009学习发展系统的下列模块

SmartLearning 2009 Enterprise Edition 学习发展系统企业版

功能模块

二级菜单

三级菜单

个人事务

我的课程

 

面授培训班

 

我的测评

参加考试

模拟练习

课后作业

调查与申请

问卷调查

需求调查

需求申请

课程选修

职业生涯规划

学习路径

能力素质模型

我的档案

我的积分

学习档案

考试成绩

练习成绩

培训档案

我的知识库

学习论坛

共享资料

个人设定

 

资源计划

机构管理

 

讲师管理

 

课程管理

 

能力模型

学习途径定义

知能模型管理

岗位知能模型

需求管理

需求调查管理

需求调查审批

需求申请管理

需求申请审批

计划管理

学习计划填报

学习计划审批

学习计划跟踪

培训管理

培训实施

项目管理

项目审批

报名管理

成绩核定

培训评估

满意度评估

满意度分析

培训总结审阅

培训档案

培训归档申请

培训归档审批

培训记录台账

培训记录汇总

学习管理

必修课程安排

 

选修课程审批

 

岗位学习管理

 

群组学习管理

 

学习过程监控

 

考评管理

题库管理

 

试卷管理

 

考试安排

 

练习安排

 

考试监控

 

人工评卷

 

成绩管理

 

积分管理

积分选项管理

 

积分规则管理

 

积分目标管理

 

积分明细台账

 

统计报表

需求报表*

需求申请查询

需求调查统计

培训报表*

培训记录台帐

培训记录汇总

培训总结台帐

学习报表*

项目进度汇总

学员进度统计

学员学习履历

课程统计分析

考试报表*

考试成绩汇总

考生成绩查询

成绩分组比较

答题分组比较

成绩分布统计

试题使用统计

积分报表*

个人积分排名

部门积分排名

积分明细查询

学员积分统计

部门积分统计

分类积分统计

信息管理

新闻公告管理

 

问卷调查管理

 

共享资料管理

 

学习论坛管理

 

系统管理

组织管理

 

用户管理

 

岗位管理

 

角色管理

 

系统设置

常规设置

菜单设置

通知设置

日志设置

分类类型设置

排行榜设置

模块设置

用户管理设置

试题管理设置

考评管理设置

试卷管理设置

资源计划设置

培训管理设置

学习管理设置

共享资料设置

流程设置

审批环节设置

审批流程设置

操作日志

 

在线用户

 

二、 定制开发以下功能特性

u 实现与淘宝已有K2工作流的集成,审批流程在K2系统中完成。

u 实现与淘宝旺旺的接口,用于发送系统通知。

u 实现下述模块的部分产品功能修改定制:

1) 培训管理-项目管理

2) 培训管理-项目管理-培训项目信息

3) 资源计划-讲师管理

4) 培训管理-人员填报-选择用户

5) 培训管理-项目管理-人员确定

6) 我的课程-培训报名

7) 调查与申请-培训需求申请

8) 培训管理-满意度评估

9) 考评管理

10) 考评管理-题库管理

具体要求请参见用户需求说明书。

2项目过程定义

2.1标准生命周期

请在过程栏内填入项目选用的组织标准过程。如果为适应项目的需求而修改了组织标准过程,请在备注栏内详细说明。下表为示例

过程

预期工作周期(周)

备注

需求分析

0.5

必须

设计

0.5

必须

编码 

2

必须

测试

2

必须

维护

4

必须

2.2 方法与工具

提示: 

本节将描述或参考软件开发所使用的方法和工具(手工或自动),例如, 面向对象的程序设计方法,Microsoft Project等,下面表格为举例,请根据实际情况裁剪或增加。

软件过程

方法

工具

系统分析与设计

面向对象分析与设计

VSTS

系统编码与实现

面向对象的编程方法

C#ASP.NET 2.0

系统测试

白盒与黑盒、模块与整体相结合的测试方法。

VSTSLoadRunner

版本控制

自动控制

VSTS

Bug跟踪

自动控制

VSTS

2.3项目过程定义的改进

列出本项目需要改进项目过程定义的情况。举例如下:

下列情况下,应考虑改进项目定义的软件过程:

l 组织标准软件过程的改变;

l 出现的问题可能会影响项目达到质量目标;

l 新技术和方法的引入;

l 缺陷预防活动。

3项目目标

为项目按期完成,提供可靠依据。

3.1项目交付物列表

下表仅作为参考使用:

工作产品名称

文档标识号

计划完成日期

I or R*

项目计划书

NV-QR-TB-PP-01 项目计划V1.0

2009-09-30

I

配置管理计划

NV-QR -TB-CMP-01

2009-09-30

质量保证计划

NV-QR -TB-QAP-01

2009-09-30

需求规格说明书

NV-QR -TB-RD-01

2009-09-30

R

概要设计报告

用户界面设计报告

模块设计报告

数据库设计报告

软件代码

2009-10-20

I

测试用例

NV-QR -TB-ST-02

2009-10-30

测试计划

NV-QR -TB-ST-01

2009-10-30

测试报告

NV-QR -TB-ST-03

2009-10-30

R

操作手册

2009-10-30

R

用户手册

2009-10-30

R

注:I=项目组内审查,   R=QA评审,   采用审查还是评审由项目组决定。

3.2假设、依赖和约束

提示:

(1) 请说明在项目开发过程中应当遵循的标准或规范,注意可能存在特殊的行业规定,请不要遗漏。

(2) 请说明相关项目可能对本项目造成的影响。

(3) 假设是指项目把某些条件暂时认为是真实的,作为估计、计划等的基础。

(4) 依赖是指项目能够按预定计划进行所必须依靠的外部条件。

(5) 约束仅仅指技术约束,它是一个软件产品必须满足的环境条件。

4.下属计划清单

提示:下属计划(Subordinate Plan)是对《项目计划》的补充。《项目计划》需要机构的审批,但下属计划一般只需要项目经理(或其他负责人)审批即可。

下属计划的名称

建议负责人

位置

预计产生时间

《预算和进度计划》

 Rick

《风险管理计划》

 Rick

《数据管理计划》

 Rick

《项目资源计划》

Rick

《知识和技能计划》

Rick

《项目相关人参与计划》

 Rick

《需求管理计划》

 Rick

《项目计划的管理计划》

 Rick

《项目监督与控制计划》

 Rick

《度量分析计划》

 Shinely

《质量保证计划》

 Shinely

《配置管理计划》

 Milly

下属计划如果比较简单可以安排在项目计划中,详细文档模板在有关组织过程域当中,此项目计划模板中仅将主要内容摘录出。

5.预算和进度计划

5.1工程预算

WBS拆分图:

根据WBS拆解包分析,总共为36个工作日,三级包为9个,平均为4个工作日/包。

5.2工作量估计

阶段

工作量(人小时)

需求分析阶段

25*8

系统设计阶段

5*8

代码实现阶段

20*8

系统测试阶段

5*8

系统实施阶段

10*8

5.3 任务起止日期

5.3 项目成本计算

员工成本:

38工作日*200=7200元。

软件成本:

开发台台:5000

数据库:3000

操作系统:500

3.硬件平台:

5台电脑*3500

合计:7200+5000+3000+500+17500=

6.风险管理计划

注:风险影响度等级为1-10,风险概算为0-1,风险系数为 风险影响度等级*风险概算

项目阶段

风险名称

风险影响度

风险概率

风险系数

初始阶段

项目设计与实现情况不符

   6

   0.3

  1.8

客户沟通出现不同意见

   5

   0.3

  1.5 

客户方提供相应接口不及时

   5

   0.5

  2.5

实施阶段

设备出现导常

   2

   0.1

  0.2 

系统重大BUG未被发现

   6

   0.4

  2.4

项目进度改变

   6

   0.5

  3.0

开发人员辞职

   5

   0.5

  2.5

数据异常

   3

   0.1

  0.3

收尾阶段

客户方负责人更换

   9

   0.7

  6.3

问题不能及时解决

   7

   0.5

  3.5

风险解决方案:

1.项目设计与实现情况不符:

及时修改需求文本,重新评估。

2.客户沟通出现不同意见:

及时找中间人员协调好。

3. 客户方提供相应接口不及时

暂搁下当前功能开发,继续下一工作,等客户提供完整内容后再确定开发。

4.设备出现导常

准备备份机器,时常备份。

5. 系统重大BUG未被发现

深入研究BUG来源及对功能的影响,按程度做相应过渡处理。

6.项目进度改变

7.开发人员辞职

及时跟人力部商量,招新员工接手工作。

8. 客户负责人更换:

及时与其沟通,确保前期需求的一致性。

7.数据管理计划

  数据管理计划如下:

(1) 数据管理文件列表

      

名称

内容

存储介质/存储位置

提供人

时间

项目管理过程规范和文件模版

项目管理过程规范,质量手册和文件模版

电子/见《配置管理计划》-资料库

EPG

项目开始

客户相关资料

该项目客户提供的资料

电子/见《配置管理计划》-资料库

客户

整个项目周期

培训管理相关资料

培训记录或技术资料

电子/资料库

研发部

培训期

人事行政管理

考勤记录

电子/资料库

行政部

每月底

基线库

需求说明书

设计说明书

测试用例

代码、用户手册

操作手册等

电子/见《配置管理计划》-基线库

 项目组

见《任务与进度计划》

受控库

项目计划

度量与分析的数据

项目监控报告等

电子/见《配置管理计划》-受控库

项目组

见《任务与进度计划》

资料库

相关的资料

模板

客户资料

行政管理等

电子/见《配置管理计划》-资料库

项目组

事件触发

开发库

开发过程中产生的文档。代码

电子/见《配置管理计划》-开发库

项目组

时间触发

沟通管理

项目过程中的各成员相互沟通的邮件

电子项目经理截图保存本项目文件夹内

项目组

时间触发

纸质文件

项目实施过程中产生的所有纸质文件如:值班表等

纸质项目经理收存

项目组

时间触发

  在数据采集过程中,对数据的采集主要参照《生命周期度量元》中要求的各种度量元来收集数据,对数据的收集存储可按照数据采集和存储规程来执行,项目经理每周五负责收集整理相关数据,这些数据主要来源于成员日志,结果大部分可存储于周报或度量表中,以供度量分析使用,具体度量参照度量分析计划

2)数据管理实施规则

1. 本项目所有产生的数据,文件等材料的管理均由配置管理员负责。详细计划见《配置管理计划》

2. 对于非电子文件,由配置管理员扫描后村档;所有文件要定期备份,定期检查文件的完整性和正确性。

3. 电子文件的保密性,由配置管理员根据项目经理提出的配置库权限要求,设置配置库的存取权限

4. 对项目组外的提供给项目经理的资料数据,由项目经理负责接收,检查合格后转交给配置管理员;需要提供给项目组外的数据资料,由项目经理从配置管理员处得到合适版本,并提交给相应人员。

3) 数据管理活动安排

数据管理活动

活动说明

数据内容

幅度、时间

负责人

日报收集

每天项目组成员将填好的日志提交到FTP上具体位置见配置管理计划)),项目经理随机抽查周五项目经理总结周报提供情况编写工作度量表

工作情况

每周

 

数据收集和整理

配置管理员将产生的数据归并存档,并给出存档的标记,路径

相关文件

事件触发

 

数据安全检查

每周五下午对数据执行安全性和保密性进行检查

相关文件安全性

每周五

 

数据状态报告

配置管理员每星期五给出配置状态报告

发送数据情况记录

每周五

 

整理交付件

到项目末期,配置管理员将文件打包,核对后交个项目经理

项目产生的所有文档

项目验收结束

 

 

8.项目资源计划

资源列表:

    

资源名称

级别

详细情况

获取方式与时间

使用说明

 开发服务器5

1

CPU:3.0

内存:2G

硬盘:500G

 已有

 

 测试服务器1

3

CPU:3.0

内存:2G

硬盘:500G

 已有

 

团队服务器 1

1

CPU:3.0

内存:2G

硬盘:500G

 已有

注意:

1、 关键项可以是软件、服务器、内存、处理器、存储设备、I/O信道容量等等;

2、 本节是系统支撑部重点填写。

9.知识和技能培训计划

项目所需的知识和技能

知识技能是否具备

知识技能培训计划实施日期

参与人

负责人

备注

K2工作流接口

2009-09-30

Rick

Tomato,Rocky

HHR,

Shinely

Rick

淘宝旺旺接口

2009-09-30

Rick

Tomatio,RockyHHR,

Shinely

Rick

10.相关人员参与计划

10.1项目组织结构

规划小组制定本项目的角色职责表,并为已知的项目成员分配角色(一个人可以兼多个角色)。

角色

职责

人员

工作说明

机构领导

负责整体监督该项目

 Tim

监督

项目经理

负责整个项目的开发,控制项目进度

 Rick

监督控制执行

需求分析员

调查分析系统需求

 Rocky

Rick

写需求报告

系统设计员

设计整个系统的功能

 Rick

写设计报告

程序员

编写功能代码

 Rick

 Gavin

 Raymond

编写代码

测试员

测试各功能模块(白)

 Frank

测试

质量保证员

测试保证该系统性能

 Shinely

HHR

配置管理员

配置整个项目过程中所产生的东西

 Milly

10.2人员计划

起止日期

人数

姓名

职能

技能简介

2009-8-16

2009-10-29

1

Rick

项目经理

2009-8-16

2009-10-29

2

Gavin

Raymond

开发人员

2009-10-21

2009-10-29

 1

Frank

测试员

 

20099-11

2

Shinely

HHR

质量保证员

10.3相关人员参与计划

 

任务/参与人

参与时间

高层经理

项目经理

开发人员

测试人员

QA

CM

专家

维护人 员

需求分析

 2009-8-16

需求评审会议

 2009-9-11

项目计划

 2009-9-14

项目计划评审会议

 2009-9-17

需求里程碑会议

 2009-9-17

设计

 2009-9-18

设计评审会议

 2009-9-25

设计里程碑会议

 2009-9-25

编码会议

 2009-9-27

编码里程碑会议

 2009-10-20

测试用例评审会议

 2009-10-22

测试

 2009-10-23

测试里程碑会议

2009-10-29

维护

11.需求管理计划

从原始需求到需求变更,都要经过分析,评审,确认,入库。作为项目实施的依据,需求不管在任时间都是实施的依据。

11.1需求跟踪说明

1. 获取对需求的理解,在需求规格说明确定后,召开需求评审会议

2. 获取对需求的承诺,在需求评审通过后,获取公司对需求的确认。

3. 管理需求变更,在接到需求变更后,根据《需求跟踪距阵》的图做变更影响分析,确定是否接受需求变更,填写需求控制报告,如果接受需求变更,修改需求规格说明书,并重新进行评审。然后修改受其影响的项目文件和相关代码。

4. 按照项目计划中的需求管理计划填写《需求跟踪矩阵》

5. 标识项目工作产品与需求的之间的不一致性,通过对《需求跟踪矩阵》的填写和分析可能会发现需求与工作产品的不一致性。遇到这样的问题就记录在《需求跟踪矩阵》的问题记录和解决措施中

11.2需求变更处理

描述本项目遵循的需求变更管理流程。举例如下:

每一个需求进行更改时要遵循下面:

1. 通知项目组全体成员;

2. 重新分析需;

3. 召开需求评审会议,并获得CCB的批准,如果评审通过则执行45;如果评审不通过,则将相应结果提交给需求变更申请人,并附上理由。

4. 在需求变更通过后,按照配置管理基线变更相应的流程

5. 通知全体项目组成员,按新基线进行。

6. 修改受其影响的项目相关文件和相关代码 

11.3需求管理列表

   需求管理活动

时机

人员

角色

完成准则

需求建立、发布批准

需求评审通过后

Dennis

Tim

CCB

需求评审记录

需求承诺

需求建立和需求变更被批准后

Rick

项目经理

需求承诺记录

需求变更

需求变更申请提出

Dennis

Tim

CCB

需求变更请求被拒绝或评审通过

建立、维护需求跟踪矩阵

每个阶段结束

需求变更批准后

Rick

项目经理 

建立和维护记录

识别需求与项目计划和工作产品的不一致性

对项目计划变更时

工作产品(工程)变更

需求变更时

Rick

项目经理

需求不一致跟踪表中有记录

统计需求变化率

每周

Rick

项目经理

需求跟踪矩阵中的统计信息

维护需求状态表

每周

Rick

项目经理

需求变更状态表中

11.4 需求管理的资源、相关人员参与、任务分配情况

      

需求开发资源

 Rick,Rocky,Tim

需求开发

 Rick

需求跟踪

 Rick

需求评审与承诺

 Dennis,Tim,Rick,HHR,Shinely,Rocky

12.项目计划的管理计划

12.1 项目计划编写人员及时间

预算和进度计划

 Rick,Tim,Rocky,HHR,Shinely,Dennis

2009-10-16

风险管理计划

 Rick,HHR,Shinely

2009-10-16

数据管理计划

 Rick

2009-10-16

项目资源计旬

 Rick

2009-10-16

知识和技能培训计划

 Rick,Tim,Rocky,HHR,Shinely,Dennis

2009-10-16

相关人员计划

 Zinger

2009-10-12

需求管理计划

 Rick

2009-10-5

项目监督计划

 Shinely

2009-10-1

度量与分析计划

 Shinely

2009-10-23

质量保证计划

 Rick

2009-10-16

配置管理计划

 mily

2009-10-18

13.项目监督与控制计划

131项目会议

本项目在该项目生命周期内将会安排如会议:

会议召集人

会议时间/频度

会议内容

会议记录方式

Rick

需求评审

需求说明书的内容

文本记录需求说明书不妥的地方

Rick

设计评审

讨论设计文档

文本,记录需要修改的地方

Rick

编码评审

代码的内容

文本,记录相关的内容

Rick

测试用例评审

测试用例文档

文本,记录相关的内容

该项目周期内主要阶段将会安排这些会议,具体会议视开发周期内的具体情况,如有需要将会不定期安排项目会议,具体内容将有会议召集人安排,每周召开周会,讨论项目费用、资源、工作成果及规模、项目进度、风险管理、人员的完成情况、数据管理、项目情况、任务工作量跟踪、知识与技能跟踪、无法解决问题上报。每个里程碑结束召开里程碑会议,讨论除了周会中要讨论的问题,另外就是需求管理、项目监控、项目计划、度量与分析、过程与质量保证、配置管理六个过程域的情况。

13.2项目里程碑

里程碑是项目进度的关键点,这一部分将包括以下几项:

1. 跟踪和更新项目里程碑

项目经理

2. 间检查和跟踪项目里程碑

每个项目里程碑结束后的第二天

3. 什么类型的报告将被提交?

每个阶段的的成果内容,设计报告,变更报告,会议记录,评审报告等。

4. 定义一个时间偏差控制范围

 本项目的偏差范围一般在2天,如果实际偏差很大,应及时召开评审会议讨论

5. 重大变化时,怎样修正项目里程碑

重大变化时,首先召开项目会议讨论,然后根据讨论结果看是否有必要修改项目里程碑,如有必要可以终止该项目另建立一个项目。

6.每阶段项目里程碑所要提交产物

  注:各成果均是在各里程碑结束后给出,然后进行下一个里程碑。

生命周期

里程碑名称

起止时间

预期工作成果

需求分析

 需求分析

2009-8-16

2009-9-11

需求分析报告

设计

 设计

2009-9-18

2009-9-25

系统详细设计报告

编码

 编码

2009-9-28

2009-10-20

系统代码

测试

编写测试用例

2009-9-18

2009-9-25

测试用例

测试

2009-10-22

测试报告

维护

编写用户手册

2009-10-30

用户手册

编写操作手册

2009-10-30

操作手册

13.3 控制阈值

进度期望值(±20%) 进度的控制阈值是指阶段偏差

质量期望值:±5%
缺陷清除率:一级 100% 二级 97% 三级 95%

一级缺陷N个(系统瘫痪、功能不对、内存超界,数据库损坏)

二级缺陷N个(严重影响系统运行的问题,有已知解决方案)

三级缺陷N个(操作人员感觉不方便,不影响必须的运行和任务基本功能的问题,和所有不影响系统能力的缺陷)

工作量(±20%) 工作量的控制阈值是指阶段偏差

规模(±10%) 规模的控制阈值是指阶段偏差

13.4 项目监督与控制计划的资源、任务分配、人员参与情况

项目计划用资源

 Rick,Tim,Dennis

项目监控人员

 Rick,HHR,Shinely

周会

 项目组全部成员

里程碑会议

 项目组成员+EPG

14.度量与分析计划

14.1 度量与分析情况

负责人根据项目组成员每天的日志,总结报告。根据项目详细计设文档进行度量当天是否达到预期标,并将结果发送给相关人。

度量与分析活动

活动说明

时间/频度

负责人

验证频率/时间

验证人

个人工作量采集

每天每个人自己填相关日志、每周由项目经理统计工作量,汇总。填写《开发类活动数据采集》、《非开发类活动数据采集》、《数据采集汇总》

每周

Rick

周五

  Shinely

填写《项目度量表》中的进度偏差

按照项目时间和项目计划中的时间比较填写进度偏差表

项目计划结束后的每阶段结束

Rick

每周五

 Shinely

填写《项目度量表》中的工作量偏差

在各里程碑结束由《数据采集汇总》计算出偏差,自动生成“工作量比例图”和偏差表,用于项目监控的指导和分析

里程碑结束

Rick

每周五

Shinely

填写《项目度量表》中的过程效率

按照评审会议和测试进度填写《项目度量表》中的过程效率中的相应数据

里程碑结束

Rick

阶段末

Shinely

填写《项目度量表》中的需求变更率

在需求确认后,填写初始需求个数,在项目进展过程中根据需求变化个数统计需求变化率和稳定度

事件触发

Rick

事件触发

Shinely

Milly

填写《项目度量表》中的缺陷分布图

项目经理每周根据所有成员的活动了解缺陷情况,填写相应的数据,每周更新

每周

Rick

每周五

Shinely

填写《项目度量表》中的规模偏差

根据规模偏差情况,及时采集数据填写《项目度量表》中的规模偏差

事件触发

Rick

事件触发

Shinely

项目监控报告进行分析

项目经理每周根据《项目度量表》的内容和偏差情况,编写《项目监控报告(周报)》进行分析总结。每个里程碑编写《项目监控报告(里程碑报告)》对整个里程碑进行分析总结,对重大问题要及时报告给公司中高层经理。

每周五

Rick

每周五

 Shinely

目标:上述这些任务能够使项目经理及时总结发现,项目各阶段存在的问题,及时做好防范纠正工作,从而使项目能够按时按质完成。

各阶段度量时,发现的偏差程度控制可参考《项目度量表》中的质量目标,来确定该阶段是否存在问题,是否在计划之内。

公司的商业目标:提高技术质量,扩展更多市场,以获取更多的业务和效益

  注:

1. 上述的各种表和图,均填写到《项目度量表.xls》对应的表中。

本阶段的度量元的选取主要参照《生命周期度量模型》

14.2 度量分析及人员参与情况

     

度量与分析用资源

 RickShinely

度量分析人员

 Rick,Milly,Shinely

日志提供者

 项目组全体成员

15质量保证计划

 15.1 质量保证计划

 见《CB-QR-project -QAP-01质量保证计划》

 15.2 质量保证的资源、人员参与情况

 

质量保证计划资源

 RickDennisShinelyHHR

质量保证计划的执行

 ShinelyHHR

质量保证计划的评审承诺

 ShinelyHHR

16配置管理计划

16.1 配置管理计划

见《CB-QR-project-CMP-01配置管理计划》

16.2 配置管理的资源、人员参与情况

配置管理计划资源

 RickDennisMilly

配置管理计划执行

 Milly

配置管理计划的评审承诺

 MillyShinely

附录 

术语定义

【列出本项目或本档中用到的专门术语的定义和缩写词的原文,以便在本项目中提供统一的沟通语言,以及对本文档进行适当的解释。】

机构领导审批

提示:

1机构领导根据“项目计划检查表”认真审批《项目计划》

2如果是合同项目,可能还要请客户审批,视具体情况而定。

项目计划检查表

结论

项目的目标明确吗?可以验证吗?

项目的范围清楚吗?

对项目的规模和复杂性的估计可信吗?

对项目的工作量估计可信吗? 

对项目的成本估计可信吗?

项目的过程控制方案合理吗?

项目所有角色的职责清楚吗?

人员安排合理吗?

项目所需的软件硬件资源合理吗? 

项目开支计划合理吗?

任务分配合理吗?

进度合理吗?

……

审批结论

[  ] 批准该计划 

[  ] 不批准

意见建议

机构领导签字

附录项目计划变更控制报告

项目计划的变更申请

申请变更的

《项目计划》

输入名称,版本,完成日期等信息

需要变更的内容

及其理由

评估计划变更将对

项目造成的影响

项目经理签字

变更申请的审批意见

高级经理审批

审批意见:

签字,日期

客户代表审批

(合同项目)

审批意见:

签字,日期

更改项目计划

变更后的

《项目计划》

输入名称,版本,完成日期等信息

项目经理签字

重新审批项目计划

高级经理审批

审批意见:

签字,日期

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值