项目方案模板
项目方案模板
PAGE / NUMPAGES
项目方案模板
项目实行方案模板
目录
第 1 章 项目概括
3
项目建设内容及范围
3
项目整体建设范围
3
项目内容
3
第 2 章 项目实行方案
4
项目实行
4
项目启动阶段
5
需求调研、需求剖析阶段
6
设计阶段
7
客户化开发、实行与测试阶段
8
系统实行部署阶段
8
上线试运转阶段
9
查收阶段
9
项目管理
11
项目组织架构
12
进度计划和管理
14
项目管理方法
20
质量管理
29
需求管理
31
交流和监控体制
33
风险管理
34
配置管理
36
第 3 章 培训方案
40
人员培训方案
40
培训目标
40
培训方式
40
培训内容
40
培训内容
41
培训方案设计
42
标准规范系统培训
42
基础知识培训
42
应用系统培训
42
现场培训
43
1
培训资料
43
第 4 章 软硬件部署
44
系统部署构造
44
系统网络拓扑构造
45
设备部署机房环境要求
45
电压和频次改动范围要求
45
电源插座种类要求
45
接地电阻要求
46
温度湿度要求
46
平台系统部署软件需求
46
平台系统服务器需求
46
正式部署环境要求
46
开发测试部署环境要求
47
其余需求
47
办公场所需求
47
网络环境
48
2
第 1章 项目概括
1.1 项目建设内容及范围
项目整体建设范围
1、服务对象
1）
2）1 家典型要点工控公司。
2、主要用户
包含信党政机关和要点工控系统营运单位。
项目内容
序号 名称
XXX系统
XXX平台
3
4
此中：
1、风险防备系统系统包含采买一套监测设备、一套风险剖析设备，并将互
联网监测系统整体归入监控平台管理，供应 3 年监控技术服务及升级服务。
2、XXX平台主要包含。
。
3
第 2章 项目实行方案
项目实行方案包含项目实行和项目管理。
2.1 项目实行
从项目实行的角度详尽描绘了主要实行阶段的主要参加人员、 工作内容和相应的工作方法。依照我们对有关领域的经验提出对本项目建设计划。
我方在项目管理方面有着自己一套科学而先进的项目管理方法论， 这套方法论已经在实行的所有的项目中获取了查验。
项目管理方法论是公司最重要的一项中心竞争能力，是我们能够对客户承诺项目成功的信心所在。
我方项目管理方法论成立在以下 5 项重要原则的基础上：
与客户共同商讨对项目成功权衡标准的定义，并以此作为两方工作的共同标准和价值观。
拟订仔细的项目计划，明确立义项目阶段和阶段交托成就。将一个大型
的复杂的任务分解为能够量化和能够详细履行的分解工作任务， 并明确立义每一个分解任务所需要达到的工作成就，使得项目整体目标得以有效的保证。
与客户的充足交流，经过各项例会制度，周报和月报制度等使客户能够全面认识项目进展状况，保证项目的交托一直与客户的预期保持一致。
明确立义项目组织构造和工作职责，并设定相应的查核标准和方法，保证项目各方能够有效的共同工作。
成立明确的文档管理，人员管理，配置管理，风险管理，估量管理，进度管理，采买管理，集成管理和改正管理规范与制度以保证项目的整体质量和各环节的配合。
针对平台实行工作，将其分为了以以下图所示的 6 个阶段：
4
图 2-1 项目实行阶段表示图
说明：
考虑到本系统的建设周期，设计、实现、实行以及试运转部分将出现迭代：
第一次迭代过程保证系统主要功能能够正常使用。
第二次迭代过程保证工信厅安全综合服务平台项目其余辅助功能能够使
用。
下边第一对各阶段的工作进行说明：
项目启动阶段
阶段工作目标
本阶段的工作目标是从项目目标、 项目范围、项目工作方法以及后勤保障方面为系统建设项目的顺利进行成立基础。
阶段工作内容
本阶段的工作内容包含：
组织项目所需的各项资源，包含：人员确立、办公环境、网络及通信环境、个人工作设备、开发环境、现场工作环境及生活环境；
确认工作范围： 针对项目招标方案中对工作范围的描绘， 进一步与工信厅安全综合服务平台项目负责人议论确立项目工作范围；
拟订项目计划： 依据项目招标方案中拟订的项目计划， 与工信厅安全综合服务平台项目负责人从头审察和进一步成立仔细的项目主计划；
确立项目管理规范： 依据项目管理规范要求， 针对本系统建设项目进行适合
5
裁剪，以知足本项目管理的要求；
确立质量规范－明确立义项目各阶段工作成就的格式、审察流程和查收标
准。
召开项目启动会： 招集项目组全体成员、 有关实行厂商及工信厅安全综合服务平台项目构成员，经过项目启动会的形式进一步明确上述各部分要求。
阶段工作成就：
《项目施工实行方案》
2.1.2 需求调研、需求剖析阶段
阶段工作目标
本阶段的工作目标是经过对工信厅有关业务、 周边业务和现有系统和软硬件环境的的深入仔细的剖析，并联合行业先进做法，为项目顶层设计成立基础。
阶段工作内容
有效需求管理的要点在于保护需求的明确论述、每种需求种类所合用的属性，以及与其余需乞降其余项目工作产品之间的可追踪性。
1．管理不一样层次的需求
项目先期，客户提出的需求一般不是直接面向软件需求的， 是从业务的角度描绘他们的问题或许是需要。
依据这些需要定义软件系统的解决方案， 确立系统供应哪些服务， 也就是软件系统的特色。
在与客户获得一致的特色集上能够定义出更加特定的软件需求。
软件需求包含功能性需乞降非功能性需求。
不一样的客户以及在项目不一样期间也可能提出特色或软件需求层次的需求。
管理这些不一样抽象级别和目的需求，保证需求是齐备的。
2．成立可追踪性
经过需求的属性、需求之间的依靠关系以及需求与其余工作产品之间的依靠
关系，管理需求的可追踪性。用来认识需求的根源、管理项目的规模、管理需求
的改正、评估需求改正对项目的影响、 评估测试故障对需求的影响、 核实所有需
求都已实现、核实应用程序不过履行了预期的任务。
3．管理需求改正
6
定义需求时不论如何慎重当心，也总会有可变要素。对需求改正进行管理，使团队的工作遇到控制， 以便它能够高效的发现改正、 进行影响剖析而且系统地把那些既必需又可接受的改正集成到系统中。
4．需求定义
细化业务和系统目标；
定义清楚、简洁、一致、可测试、无二义性的业务需求；
鉴于对业务需求摆列优先级：一定有，应当有，能够有，将会没有。
5．需求剖析
成立业务数据模型，精准描绘信息和过程需求；
查验供应业务所需的信息的数据和业务数据模型中的数据元素在源系统中的是可用的而且具备一定的特征。
阶段工作成就
此阶段的项目工作成就将包含：
《系统业务调研报告》
《系统需求规格说明书》
设备采买及到货查收、上架；
设计阶段
阶段工作目标
本阶段的工作目标是对系统进行整体设计，并对各有关子系统进行详尽设计，进而为系统的实现阶段成立依照。
阶段工作内容
本阶段的工作内容包含：
顶层初步设计
系统整体设说明书
数据接口及数据同步设计
7
阶段工作成就
本阶段的工作成就包含：
《顶层设计》
《管理体制建设》
《纲要设计方说明书》
《详尽设计说明书》
客户化开发、实行与测试阶段
阶段工作目标
本阶段的工作目标是依据系统整体设计及各模块设计方案，进行系统的建设、开发和部署。
阶段工作内容
系统配置＆部署；
系统接口实现；
项目顶层初步设计评审；
应用系统接口开发和测试。
阶段工作成就
本阶段的工作成就包含：
各第三方软硬件及文档及《平台实行方案》
系统实行部署阶段
阶段工作目标
本阶段的工作目标是对系统进行部署实行，以保证系统的试运转。
阶段工作内容
本阶段的工作包含：
软硬件的安装部署；
8
系统数据初始化；
编制用户手册；
技术培训；
用户培训；
阶段工作成就
本阶段的工作成就包含：
《用户培训计划》
《用户操作手册》
《实行报告》
《查收报告》
上线试运转阶段
阶段工作目标
本阶段的工作目标是经过一段时间的系统试运转， 帮助用户熟习系统， 发现并解决系统产生的问题，为系统正式投入使用打下基础。
阶段工作内容
本阶段的工作内容包含：
组织系统各方面用户使用系统；
成立系统问题发现、追踪和解决体制；
问题发现和办理；
查收阶段
查收对象
项目名称：平台（一期）（以下简称“项目” ）。
查收对象为该项目的有关文档技术文档， 系统运转状况、 顶层设计等建设内
容。
9
项目查收的前提条件
所有建设项目依照合同要求所有建成，并知足使用要求；
已经过软件系统测试评审；
软件已部署在生产环境上；
各种技术文档和查收资料齐备，切合合同的内容；
查收步骤
编写查收方案（计划书）
成立项目查收小组
实行测试查完工作时，应当作立项目查收小组，详细负责查收事宜。
项目查收的实行
严格依照查收方案对项目应用软件、系统文档资料等进行全面的测试和验
收。
提交查收报告
项目查收完成，对项目系统设计、建设质量、设备质量、软件运转状况等做出全面的评论， 得出结论性建议， 对不合格的项目不予查收， 对遗留问题提出详细的解决建议。
查收内容和标准
1、查收的内容包含以下几个部分：
查收内容包含：按功能要求的可履行软件、开发计划文档、设计文档、使用说明书等。
查收评测工作主要包含：文档剖析、方案拟订、现场测试、问题单提交、测试报告。
10
文档查收标准一般包含：文档齐备性、内容针对性、内容充足性、内容
一致性、文字明确性、图表详确性、易读性、文档价值等。
2、需要评审的资料包含以下几部分：
需求规格说明书、纲要设计说明书、系统保护手册、用户操作手册。
软件开发管理文档：项目计划书、用户培训计划、开发进度月报。
查收结论
查收结果分为：查收合格、需要复讲和查收不合格三种。
切合项目建设标准、系统运转安全靠谱， 视为查收合格； 因为供应资料不详难以判断， 或目标任务达成不足 80%而又难以确立其原由等致使查收结论辩议较大的，视为需要复议。
1、项目凡拥有以下状况之一的，按查收不合格办理：
所供应的查收资料不齐备或不真切的；
实行过程中出现重要问题，还没有解决和作出说明，或项目实行过程及结果等存在纠葛还没有解决的；
没有对系统进行试运转，或许试运转不合格；
违犯法律、法例的其余行为。
2、查收结论确认和办理
由工信厅和我方共同依据查收建议和有关资料得出结论，并进行确认。
项目交接
项目完工查收合格后 , 应办理项目交接手续。项目的移交包含项目实体移交
和项目文档移交部分。
2.2 项目管理
本章描绘了项目的管理特色和管理要求， 并依据本项目的特色给出了工信厅拟实行项目的组织架构， 管理方案和初步的进度计划， 列出了项目的成就交托物。
11
并介绍了有关的项目管理方案，包含：质量管理，需求管理，配置管理，软件发
布与部署，项目追踪与监控，风险管理等内容。
项目组织架构
组织构造
我们建议项目采纳以下的组织形式：
图 2-2 项目组织构造图
项目的组织构造将分为三个层次： 领导层、管理层和履行层， 每个层次负责
不一样的项目职能。
XXX（业主单位）
XXX（承建单位）
XXX（承建单位）
领导层
项目领导小组
管理层
项目负责人
项目经理
项目负责人
业
业务负责人
咨询顾问
咨询顾问
执
务
各业务部门的业务
业务专家
业务专家
行
层
专家
需求剖析师
需求剖析师
层
技
实行人员
应用系统开发经理
规划编制员
术
系统剖析师
12
层 架构设计师
安全剖析师
开发工程师
测试工程师
实行人员
1、领导层
项目领导层
项目领导层将负责对项目整体方向的控制， 并经过项目领导委员会的形式对项目过程中产生的重要问题进行议论剖析和决议。
2、履行层
负责项目中心业务需求剖析与设计、 技术路线以及中心技术的设计， 草拟业务需求文档项目履行层将在项目管理层的领导下达成对项目的规划设计、 系统需求剖析、系统整体设计、系统开发、系统测试、文档整理、系统配置等各方面的
详细工作。分为业务组和技术组，包含规划设计组、项目实行组、甲方实行组和应急小组。涵盖的角色如上表。
规划设计组
规划设计组包含顶层设置编制组、 综合管理服务体制建设编制组， 负责本项目的顶层设计方面的业务需求认识、规划编制、标准规范编制等工作。
项目实行组
项目实行组包含系统研发组、 测试组、现场实行组， 负责整个项目系统需求调研、系统设计开发、上线功能测试测试、现场实行及培训有关工作。
甲方实行组
负责项目实行平时工作追踪、协调、功能测试、问题反应追踪等有关工作。
项目主要成员
甲方成员
序
项目组角色
姓名
工作职责
号
1
领导、专家成员
领导成员，负责项目整体协调。
2
项目实行负责人
负责项目详细实行、实行进度监察、现
13
场工作详细协调等。
乙方成员
序
项目组角色
姓名
工作职责
号
1
领导、专家成员
项目领导专家成员， 负责整体项目协调
及专家咨询。
2
领导、专家成员
研究中心专家成员， 负责整体项目协调
及专家咨询。
3
项目经理
负责整体实行、项目进度控制及协调。
4
项目副经理
辅助项目经理，负责项目实行、现场项
目进度、项目报告等。
5
项目副经理
辅助项目经理，负责系统研发、实行及
有关现场工作等。
6
软件工程师
负责软件部分开发实行
7
系统集成工程师
负责硬件设备部署以及有关中间件数
据库等部署
研究中心规划编制负责人， 辅助项目经
8
规划编制
理，负责对整体规划、体制系统等编制
等工作。
监理成员
序
项目组角色
姓名
工作职责
号
1
项目总监
XXX
负责项目整体监理及进度监监工作。
2
监理工程师
XXX
负责现场项目实行监理工作。
3
监理工程师
XXX
负责现场项目实行监理工作。
进度计划和管理
项目进度计划
：
序
阶段 内容 开端 / 截止 工作日 文档
号
1、系统设备采买及环境部署
14
2
设备采买
设备采买
3
设备到货查收
设备到货查收
4
开发环境部署
设备环境部署
5
采买设备部署
6
设备网络联调
系统联调
7
设备与系统联调
2、软件开发
9
计划阶段
计划编制
10
计划阶段
项目启动会
计划阶段小计
12 需求调研、剖析
需求阶段
13 需求评审
需求阶段小计
15
纲要设计
16
设计阶段
17
数据库设计
18
详尽设计
设计阶段小计
20
数据库实现
21
XXX系统
实现阶段
22
XXX系统
23
XXX系统
2014
年 10 月 20 日 /
15
2014
年 11 月 7 日
2014
年 11 月 10 日 /
设备到货查收文
2014
年 11 月 10 日
1
档
2014
年 10 月 28 日 /
3
2014
年 10 月 30 日
2014
年 11 月 10
日 /
系统部署及配置
2014
年 11 月 10
日
2
文档
2014
年 11 月 11
日 /
2
2014
年 11 月 12
日
系统接口配置文
2014 年 12 月 18 日 /2015/1/3
15
档
2014
年 10 月 8 日 /
1
项目实行计划表
2014
年 10 月 8 日
2014
年 10 月 9 日 /
1
计划表细项议论
2014
年 10 月 9 日
2014 年 10 月 8 日 /2014/10/9
2
2014
年 10 月 10 日
9
/2014/10/21
需求规格说明书
2014
年 10 月 22 日
1
/2014/10/22
2014
年 10 月 9 日
10
/2014/10/22
2014 年 10 月 23 日
/2014/10/27
3 纲要设计说明书
2014
年 10 月 28 日
数据库详尽说明
/2014/10/29
2
书
2014
年 10 月 30 日
系统详尽设计说
/2014/11/5
5
明书
2014
年 10 月 23 日
10
/2014/11/5
2014 年 11 月 6 日 /2014/11/6
1
2014 年 11 月 7 日
8
/2014/11/18
有关代码
2014 年 11 月 19 日
8
/2014/11/28
2014 年 11 月 19 日
25
/2014/12/23
15
24
XXX系统
2014
年 11 月 19 日
20
/2014/12/16
25
XXX系统
2014
年 12 月 17 日
20
/2015/1/13
26
实现阶段小计
2014
年 11 月 6 日 /2015/1/13
49
27
测试准备
2015
年 1 月 14 日 /2015/1/14
1
系统使用说明书
系统测试方案书
28
功能测试
2015
年 1 月 15 日 /2015/1/21
5
测试报告
测试阶段
项目初步查收报
29
性能测试
2015
年 1 月 15 日 /2015/1/21
5
告
30
BUG修正
2015
年 1 月 22 日 /2015/1/28
5
31
测试阶段小计
2015
年 1 月 14 日 /2015/1/28
11
32
安装
2015
年 1 月 29 日 /2015/1/29
1
系统培训报告
33
试运转
2015
年 1 月 30 日 /2015/2/19
15
系统试运转报告
试运转阶段
34
BUG修正
2015
年 2 月 20 日 /2015/2/26
5
35
投运
2015
年 2 月 27 日 /2015/2/27
1
3、顶层设计、体制建设
37
编制
2014
年 10 月 23 日
顶层设计文档、
/2014/12/3
30
体制建设文档
38
编制阶段
评审
2014
年 12 月 4 日 /2014/12/5
2
39
订正
2014
年 12 月 8 日
5
/2014/12/12
40
整体项目共计
2014
年 10 月 23 日
37
/2014/12/12
4、工控实行
42
需求调研、剖析
2014
年 12 月 13 日
4
/2014/12/16
需求阶段
需求规格说明书
2014
年 12 月 17 日
43
需求评审
1
/2014/12/17
44
需求阶段小计
2014
年 12 月 13 日
5
/2014/12/17
45
实现阶段
接口开发
2014
年 12 月 18 日 /2015/1/8
20有关代码
46
实现阶段小计
2014
年 12 月 18 日 /2015/1/8
20
47
整体项目共计
2014
年 12 月 13 日 /2015/1/8
注 : 测试、试运转
25
阶段与“一、软
16
件开发”同步进
行。
5、监控接口开发
49
需求调研、剖析
2014
年 11 月 6 日
4
/2014/11/10
需求阶段
需求规格说明书
2014
年 11 月 11 日
50
需求评审
1
/2014/11/11
51
需求阶段小计
2014
年 11 月 6 日
5
/2014/11/11
52
实现阶段
接口开发
2014
年 12 月 18 日 /2015/1/3
15有关代码
53
实现阶段小计
2014
年 12 月 18 日 /2015/1/3
15
注 : 测试、试运转
54
整体项目共计
2014
年 11 月 6 日 /2015/1/3
阶段与“一、软
20
件开发”同步进
行。
图 2-3 项目实行计划
主要里程碑成就物
序号 阶段 成就物
合同签订
项目启动
3 项目小构成立、项目实行计划确立 《项目实行方案》
一、 XXX顶层设计
需求调研、需求剖析
6
顶层设计编制
《顶层设计》议论稿
7
顶层设计初审
《顶层设计》初审稿
顶层设计草稿订正编制
9 顶层设计终审及终审编制 《顶层设计》
二、 XXX体制建设
17
需求调研、需求剖析
12
XXX体制编制
《 XXX体制》议论稿
13
XXX体制初审
《 XXX体制》初审稿
XXX体制草稿订正编制
15 XXX体制终审及终审编制 《 XXX体制》
三、 XXX平台
17
需求调研、需求剖析
《需求规格说明书》
《系统纲要设计说明书》
18
系统纲要设计及评审
《系统数据库设计说明书》
《技术开发规范》
19
系统开发设计
《系统详尽设计说明书》
《系统操作手册》
20
系统测试
《系统测试方案》
《系统测试报告》
21
系统培训
《系统培训计划》
22
项目初步查收
《初验报告》
23
项目试运转
《试运转报告》
系统功能完美
系统正式运转
四、 XXX系统
设备采买、供货
28
设备上架、到货查收
《到货查收报告》
29
系统安装、入网联调
《系统接入方案》
培训
正式运转
五、项目整体查收
项目查收资料整理
34 项目整体查收 《查收申请》
18
《查收方案》
《查收报告》
进度管理方法
计划是项目管理的基准， 现代质量管理以为“计划胜于查验”， “过程决定
质量”，关于项目履行来讲相同是这样。 计划是项目履行的指导， 计划是控制的
基准，计划是项目各方交流的平台。计划拟订的过程重申渐进明细和分解。
往常应用软件开发过程中项目计划简单出现的问题有：
1．项目计划纷乱、无序，也就是说不可以从项目计划中看到项目履行全貌。
对项目履行指导意义不大。
2．项目计划不过在项目开始时进行拟订，在履行过程中不对计划进行及时
管理，致使项目计划无效，同时失掉对项目履行的指导意义。
3．项目计划不完好，不过在目前所关注的环节存在计划，致使项目履行工
作不可以整体上全面协调的推动。
本项目项目计划追踪和控制建议：
1．项目计划层次区分
项目计划可分为：项目里程碑计划、子项目计划、周项目计划 3 个层次。充足表现项目管理中渐进明细和分解的原则。
项目里程碑计划作为项目各参加方均认同的项目阶段目标指导性文件， 项目各参加方均需对其负责。
对里程碑计划进行渐进明细形成子项目计划， 子项目计划要说明里程碑计划中阶段目标的实现步骤和方法。
在子项目计划的指导下形成项目各参加方的周项目计划， 周项目计划作为项目进度风险控制的最小单元， 依据周项目计划的履行状况进行查核， 并及时形成调整举措。
2．项目计划有效性和完好性
“计划赶不上变化”，在项目履行的过程中必定会发生各种各种的状况变
化，如各个层次的项目计划不可以获取及时的改正控制和管理， 项目计划将渐渐与
19
项目履行状况脱节并无效。
项目计划有效性的丧失必定致使项目工作堕入无序状态，最后致使项目目标不可以按期实现，甚至造成项目失败。
在形成各个阶段或维度的子项目计划时， 特别重要的一点是要保证项目计划的完好性。假如子项目计划存在缺失， 会造成项目履行中的重要缺点， 对整体项目履行产生重要影响。
针对项目计划的有效性和完好性问题提出本项目中有关项目管理建议：
（1）项目管理组肩负项目计划的改正控制和管理职能，对项目计划的有效性负全面责任。
（2）成立项目计划改正控制流程。在项目履行状况发生重要改正时，有关方一定向本项目管理组提出改正申请； 项目管理组依据状况及时组织项目有关方审察项目改正，并进行风险剖析，更新项目计划并通知项目各方。
（3）项目整体计划和子项目计划拟订，要进行有关评审，在评审通事后方可奏效。
（4）成立项目计划表记系统，包含项目计划版本表记。每次项目计划的改正均需更新表记，并说明改正原由和进行有关风险的说明。
3．项目计划的履行状况追踪
本着提早发现问题的原则， 按期的对项目计划的履行状况进行追踪， 并对跟
踪结果进行宣告。追踪的频度与项目履行状况有关， 能够每周、双周等频度进行。
项目管理方法
项目评审
评审主要包含里程碑评审、同行评审和追踪，此中里程碑评审是管理评审，
同行评审和追踪属于同行评审的两种形式。
（1）里程碑评审
里程碑评审的主要活动包含以下内容
[ 第 1 步 ] 项目经理负责组织里程碑评审活动
[ 第 2 步 ] 议论里程碑报告、评估报告
[ 第 3 步 ] 项目经理负责形成项目里程碑报告
20
[ 第 4 步 ] 确立下一个阶段的计划能否需要改正
里程碑评审后，质量保证员依照评审记录， 监察问题更正和改正的履行状况。
（2）项目进度及问题追踪
追踪的主要步骤以下：
[ 第 1 步 ] 项目经理负责项目整体进度以及实行过程中详细问题的的追踪，
一般来讲，参加追踪人员可选择项目组内的人员， 但应注意追踪时防止追踪自己
达成的工作产品部分。
[ 第 2 步 ] 项目经理负责将要追踪的工作产品及有关资料在追踪前一天发送
给参加追踪的人员
[ 第 3 步 ] 参加追踪的人员按计划进行追踪，并将追踪出的问题形成评审记
录
[ 第 4 步 ] 项目经理汇总评审记录，并对追踪出的问题进行分工，同时追踪
问题的解决状况，直至问题解决结束。
[ 第 5 步 ] 项目经理负责形成评审报告，记录本次追踪的结论，参加追踪的
人员，统计本次追踪的工作量、发现的问题种类个数、改正的问题个数等。
进度监控
项目要拟订合理的进度安排， 并保证项目能够按计划进行。
项目经理以及各
组负责人依据项目特色、 客户需求、识其余风险、可能存在的限制安排项目进度；
在项目履行过程中按期对所属范围内的项目进展状况进行监控， 辨别与剖析实质
进展与计划的偏离原由，采纳纠正举措进行调整，必需时进行正式的计划改正。
1．进度安排
进行合理的进度安排是进行监控的前提， 考虑迭代的生命周期模型， 项目采纳分阶段细化项目进度的策略。
在项目初始策划阶段， 项目拟订总进度表， 内容包含各主要里程碑和各迭代点；在每主要里程碑结束，细化下一里程碑的计划；
在每次迭代策划阶段， 拟订本次迭代的进度表， 细化本次迭代内的项目活动。
进度安排时能够依照以下步骤进行：
确立可用的资源。在编制进度表时，知道在何时以何种形式获得何种资源是必需的，这类对资源可用性的认识程度是需要不停进化的。
21
确立项目日历和资源日历。项目日历和资源日历标了然在该项目中或许关于某一资源来说哪些日期是用于工作的时间。
依据任务的依靠关系和预计工期列出项目的要点路径，为要点路径上的各个要点任务分派资源，为非要点路径上的其余任务分派资源。
进度的安排能够使用表格形式或许图形形式进行表示。
2．进度调整
项目依照进度表的安排履行并控制项目进度， 并依据项目状态对进度进行调整。使用进度表监控项目进展，进度控制的内容有：
对造成进度变化的要素施加影响， 以保证这类变化朝着有益的方向发展。
采集项目实质进度状态数据，与计划进度数据进行比较，确立项目进度能否已发生变化。
当在实质变化发生和正在发生时，对这类变化实行管理。
依据项目状态对进度进行调整， 进度调整包含两种种类， 改平时调整、 按期调整和项目进度发生重要改正时的调整。
平时调整指项目各级负责人平时对进度表的更新活动， 能够是每日或许每周进行，一般包含对以下内容的调整：
调整某个任务的工期、计划开始时间或结束时间。在调整时要注意与该
任务拥有依靠关系的其余任务的变化， 特别是要注意要点路径的变化， 检查所进行的调整能否致使项目里程碑结束日期或许项目日期发生变化。
依据人员负荷和进度变化调整资源的分派，为某个任务从头指定资源。
采集并记录进度实质数据，一般包含任务的实质开始时间、实质结束时
间等。
按期调整是指项目经理在迭代内里程碑、迭代结束和阶段结束经过正式评审项目进展，依据项目达成状况对项目进度的调整。
当项目进度发生重要改正时， 如需求改正惹起的， 需要调整项目进度表， 此时需要对节余工作进行从头预计， 从头拟订后续任务的进度表， 包含调整迭代计
22
划以及项目整体计划。
资源监控
资源是指在项目运转过程中所需要的人力资源。
资源监控是指项目充足、 有效地利用所波及人员的过程， 包含辨别并管理这些资源以及在不一样阶段需要的数目、状态等信息，保证项目的正常睁开。在项目策划阶段，策划适合的资源安排
到各项项目任务中， 形成完好的人员装备管理计划； 在项目实行过程中， 经过邮件、周例会和里程碑总结等正式和不正式的手段对人员的状态进行监控。
一旦出现不行防止的人员改正问题，依照规定的流程进行工作交接。
本项目的资源监控有两个主要特色：
工作般配原则：保证为项目装备切合项目活动能力要求的工程和管理人
员；
动向人员构造：依据不一样阶段项目对人员的不一样需求考虑投入不一样能力和不一样数目的人员。
1．人员策划
需要辨别为达成项目所波及的所有人员角色、 所需的经验技术、 数目要求以及投入时间等信息，成立人员需求表。
鉴于以上需求， 获取切合项目以上需求的技术和管理人员； 获取的门路包含本领业部内部、 公司内部其余事业部或社会招聘。
获取人员的主要考虑人员的工作能力和娴熟程度， 拥有近似项目的技术和管理经验背景优先， 同时也要考虑个人喜好和个人特色以及时间上可能性。
依据项目进度的要乞降任务的安排， 为每项任务分派人力资源以及每项资源在各个时间段内（天、周、月或许其余时间间隔）达成的工时，形成完好的人员装备管理计划。
在人员装备管理计划中，以图或表的形式描绘了资源分派和人员负荷等情
况。
2．人员改正
项目经理追踪人员装备管理计划以监控项目人员的投入状况， 并在每周和每
23
里程碑长进行总结，监控的主要内容包含：
人员投入的数目以及投入的人员技术能否能够知足项目实行要求；
能否需要为项目人员供应必需的培训；
人员负荷能否不均衡；
人员能否流失或有流失的可能；
在项目周会和里程碑会议上， 高级管理者、客户方和项目经理评审以上人员状况，拟订合理的举措以办理人员管理中碰到的一些问题。
因为人员辞职或工作改动会惹起项目中人员的改正。
项目经理睬剖析人员改正所带来的影响， 尽量控制人员改动， 关于不行防止的人员改动要办理好工作交接，以使工作能够全面、 顺利的交接， 降低工作交接对项目工作带来的风险和问题。
以下图描绘了人员改正主要活动的流程：
改正恳求
剖析影响
对目前工 作内容
和产品进行整理和完
善
拟订交接计划
确 定 新 负 按计划交接
责人
明 确 交 接
限期
工作交接评审
召 开 交 接
短会
改正结束
图 2-4 项目实行人员改正流程
关于以上人员改正活动需要注意以下内容：
24
新负责人应尽量选择在有关领域有经验的人员（因为是半途接手，难度较大）；
假如选择本项目中已肩负其余工作任务的人员作为新负责人，则必定要正确胸怀其负荷，并要明确其接手后的责任；
交接限期的确定应以工作能够有效交接为中心，可能的状况下部门应在工作交接结束后，才最后赞同原担当辞职或改动工作；
交接计划要与项目经理和被交接者商讨拟订，计划中应包含要进行哪些交接活动、时间、内容及有关人员安排等，应当包含有关培训和自学的内容。
项目经理要对工作交接的结果进行检查，判断有关工作能否都已经顺利交接；假如存在问题，需要与有关人员商讨后续计划。
风险管理
在软件开发中， 风险是某种不确立要素， 在其正常散布范围内， 它能够危及
项目成功或致使项目失败。所以有效的管理项目风险是项目成功的要点。
1．风险管理策略
依据风险发生的可能性和对项目影响的严重程度， 定义风险等级：高、重要、中等、较小、低。风险对策：主要描绘应付风险的策略。风险管理的中心思想不
是被动地等候（等到风险变为现实、成为问题或致使项目失败），而是决定如何应付风险。关于每个风险，有 3 种主要的可行举措：
风险躲避：从头组织项目，使风险没法影响项目；
风险转移：从头组织项目，让其余方肩负该风险（客户、厂商、银行、其余主题等）；
风险接受：决定接受这类可能发生的风险。监督风险征兆，假如风险出现，则制定应急计划，决定要采纳的举措。
假如接受风险，还要采纳两种举措及：风险减少：采纳一些及时的、正面主动的步骤来减小风险发生的可能性或影响。
拟订应急计划： 假如风险变为实质问题，应当采纳的举措。
25
3．项目风险和对策
以下提出项目可能的风险及应付策略：
（1）软件需求
波及业务的软件系统， 常常会出现这样的问题： 系统开发达成了， 但没有知足客户的业务需求； 需求常常发生变化， 致使开发范围的延伸。
防止软件需求的风险，才能项目成功。化解风险的策略：
理解客户需要解决的问题：经过业务建模，认识客户的业务流程和业务
需求；
增强与客户的交流：用例建模立足用户角度描绘，为详细的需求供应了充足的上下文信息，是连接用户和开发者的纽带和交流方式；
提早采集客户的反应：每次迭代都会产生系统可履行的部分，经过提早部署演示来发掘用户的反应建议，改良关于需求理解的误差；
控制需求改正：改正恳求可能来自于客户和最后用户、设计人员、开发人员、测试人员、技术支持部门等，成立改正控制流程管理改正。
（2）架构 / 技术风险
可履行构架指的是系统的部分实行，该构架用于演示选定的系统功能和特
征，特别是那些知足非功能性需求的功能和特色。
利用该构架能够降低性能、 吞吐量、容量、靠谱性以及其余方面的风险。
迭代开发在精化阶段的要点活动是确立架构并为构架成立基线， 在该阶段经过几次的迭代和测试改正， 到精化结束时稳固的架构基线已经成立， 性能等主要技术风险尽早的被发现和解决。
进而在建立阶段能够在一个牢固的基础上达成系统功能的全面增添，而不用担忧损坏系统。
质量管理
软件质量保证过程的目的是为项目组的软件开发过程供应指导， 为管理层就
软件项目过程供应管理信息，为提高软件质量供应手段。
因为开发软件系统或软件产品的过程是决定项目成功与否的要点要素， 所以
软件质量保证的工作是评审和审计软件活动和软件产品。
26
软件质量保证过程需要达到的目标包含：
软件质量保证活动是有计划的活动；
软件产品和活动与合用的标准、过程和需求的一致性需经客观考证；
软件质量保证活动及成就应及时通知到受影响的组织和个人；
软件项目内部未能解决的有争议问题，由上司管理部门办理；
软件质量保证过程定义以下：
由质量保证员负责向项目组人员进行 PPQA定向培训；
由质量保证员负责编写质量保证计划；
由质量保证员负责对软件项目过程及其余公司规范及过程进行质量保证，软件项目过程包含：软件销售管理过程、需求开发过程、需求管理过程、项目计划和追踪过程、软件设计过程、软件编码过程、软件测试过程、项目实行过程、配置管理过程、改正过程、评审过程，其余过程包含：培训管理过程、组织过程焦点过程、组织过程定义过程；
关于项目内部不可以解决的问题，由质量保证员报告给高层管理者；
交流管理
项目交流管理的目的是能够及时、 适合地产生、采集、公布、储存项目信息。
交流管理是人、 建议和信息之间的要点纽带， 是成功所一定的。
参加项目的每一
个人都一定做好以项目“语言”方式传达和接收信息的准备， 同时还一定理解他
们以个人身份波及的信息将如何影响整个项目。
1．交流原则
为了保证及时有效地进行交流，本项目确立以下交流原则：
保证客户能够最大程度地参加项目工程和管理活动；
保证与客户提早交流需求，以除去需求中的不确立性；
按期与客户交流项目各里程碑和各迭代的进度和进展状况；
保证各阶段的主要成就物及时提交给客户，以便客户评审；
27
关于项目出现的重要问题，提早报告给客户以便客户认识项目。
2．存在交流需求的组织一般包含：
项目与客户；
项目合作方；
项目组内部，当项目成职工作地点不在同一地址时，要早先确立异地开发的交流体制，保证项目信息的交流顺畅。
3．交流的方式一般包含：
报告，比如周报、里程碑总结等；
会议，包含评审、议论等。
4．交流的程度一般包含参加和认识，详细参加程度需要依据详细项目需求
进行调整：
参加：参加内容的拟订和查验，比如项目计划的编制和评审；
认识：不参加跟内容有关的拟订和查验活动，对信息内容认识即可。
5．交流的内容，分为三类：
计划：包含项目计划和迭代计划的拟订与评审；
进展：包含每个迭代状态和里程碑状态的评审；
工程文档：包含每个工程阶段主要输出物的评审。
6．项目交流体制
项目的交流管理体制以下表所示：
组织 /发
交流方式
分类
交流内容
布方
项目
客户
报告
会议
项目计划
项目
--
参加
项目计划
项目计划评审会
计划
有关方配共计划
项目
--
参加
协作项目计划
协作计划评审会
人员计划
项目
--
参加
项目成员和角
色规划
28
监理计划
监理方
--
-参加
监理计划
监理计划评审
计划改正
项目
--
参加
最新项目计划
最新项目计划评
审会
周报
项目周进展和存在
项目
--
认识
项目周报
--
问题剖析
里程碑
项目里程碑总
里程碑总结与评
总结报
项目里程碑总结
项目
--
参加
结
审会
告
状态评
渐进的进展状态
项目
--
参加
状态评估
状态评估会
估
需求
需求规格
项目
--
参加
需求有关报告
需求议论
剖析规
架构设计
设计模型
项目
--
参加
剖析设计报告
剖析设计议论
划
数据库设计
开发实
源代码 编码规范
项目
--
参加
--
实现功能测试
现
功能测
测试计划
测试用例
测试环境
测试数
项目
--
参加
测试有关文档
功能测试议论
试
据 缺点报告
部署计划 数据迁徙
部署
用户培训 系统集成
项目
--
参加
部署有关文档
部署议论
上线割接 查收测试
阶段总
按商务合同规定的
项目
--
参加
阶段总结报告
部署评审会
结会
阶段
质量管理
质量控制
质量控制的目的是保证：
达成项目内容并达到预约的目标
最后的系统是稳固的和可用的
保证项目按预约计划达成
所以，在项目进行中，需要建立若干控制点，以保证项目的质量可控。
质量控制队伍独立于项目实行小组， 作为项目成功的重要要素和保障， 在项目履行过程中一直与项目实行小组保持亲密联系。
从另一个角度察看和监察项目的睁开，帮助 PMO发现和解决项目履行中的问题保证项目的成功。
29
能够采纳以下步骤实行全面质量控制：
1．成立标准化工作流程
项目启动时， 项目组应依据项目范围、 项目要求，第一组织人力编制项目流程、工作标准及相应工作手册，形成工作方法系统，实现项目工作的流程化、标准化，并对项目人员进行培训，使他们认识和恪守项目流程和要求。
2．推行阶段性成就提交与改正控制
项目拥有生命周期， 这就为我们区分项目阶段供应了依照。
一个大项目可分红若干阶段，每个阶段有自已的任务和成就。
这样一方面便于管理和控制项目进度，另一方面能够增强处目人员和用户的信心。
在每个阶段末要提交部分红果物， 作为下一阶段开发的基础。
成就物提交以后不是不可以改正， 而是其改正要经过必定的审批程序， 而且波及到项目计划的调整。
3．推行里程碑式的审察与版本控制
里程碑式审察就是在项目生命周期每个阶段结束以前， 都正式使用结束标准
对该阶段提交的成就进行严格技术审察，假如发现问题，应及时在阶段内解决。
版本控制是保证软件项目顺利进行的重要手段。 版本控制的含义是经过给文
档和程序言件编上版本号， 记录每次的改正信息， 使项目部的所有成员都认识文
档和程序的修悔过程。
4．测试
要采纳适合的手段，对需求检查、系统剖析、系统设计、实现和文档进行功
能测试。
5．用户单位增强监察
为进一步增强处目质量控制，要增强用户单位对项目质量的监察。
质量保证
软件质量保证过程的目的是为软件项目组的软件项目过程供应指导， 为管理
层就软件项目过程供应管理信息，为提高软件质量供应手段。
因为开发软件系统或软件产品的过程是决定项目成功与否的要点要素， 所以
软件质量保证的工作是评审和审计软件活动和软件产品。
30
软件质量保证过程需要达到的目标包含：
软件质量保证活动是有计划的活动；
软件产品和活动与合用的标准、过程和需求的一致性需经客观考证；
软件质量保证活动及成就应及时通知到受影响的组织和个人；
软件项目内部未能解决的有争议问题，由上司管理部门办理；
软件质量保证过程定义以下：
由质量保证员负责向项目组人员进行 PPQA定向培训；
由质量保证员负责编写质量保证计划；
由质量保证员负责对软件项目过程及其余公司规范及过程进行质量保证，软件项目过程包含：软件销售管理过程、需求开发过程、需求管理过程、项目计划和追踪过程、软件设计过程、软件编码过程、软件测试过程、项目实行过程、配置管理过程、改正过程、评审过程，其余过程包含：培训管理过程、组织过程焦点过程、组织过程定义过程；
由质量保证员对软件工作产品进行质量保证， 依照工作产品规范 / 模板检查项目工作产品；
质量保证员应参加项目的管理评审和技术评审；
由质量保证员按期与不按期地将检查结果报告给有关人员；
关于项目内部不可以解决的问题，由质量保证员报告给高层管理者；
需求管理
在软件项目中， 所有的项目有关方都感兴趣的就是需求剖析阶段。 这部分工
作若办理好了， 能开发出很优秀的产品， 同时会使项目各方感觉满意。 若办理不
好，则会致使误会、挫折、阻碍以及潜伏质量和业务价值上的威迫。因为需求分
析确立了软件工程和项目管理的基础， 所以所有项目有关方一定重视需求剖析过
程。
软件需求包含四个层次：业务需求、用户需求、功能需求、非功能需求。优
31
秀需求所拥有的特征： 完好性、正确性、可行性、必需性、区分优先级、 无二义、可考证。
需求分为需求开发和需求管理。需求开发包含：问题获取、剖析、编写规格说明和考证四个阶段。需求管理包含成立和保护软件需求。
甲方在需求活动中的权益和义务。
往常来说，甲方在需求活动中有以下权益：
1．要求剖析人员使用切合客户语言习惯的表达。
2．要求剖析人员认识客户系统的业务及目标。
3．要求剖析人员组织需求获取期间所介绍的信息，并编写软件需求规格说
明。
4．要求开发人员对需求过程中所产生的工作结果进行解说说明。
5．要求开发人员在整个交流过程中保持和保护一种合作的职业态度。
6．要求开发人员对产品的实现及需求都要供应建议，取出想法。
7．描绘产品使其拥有易用、好用的特征。
8．能够调整需求，赞同重用已有的软件组件。
9．当需要对需求进行改正时，对成本、影响、得失有个真切可信的评估。
10．获取知足客户功能和质量要求的系统， 而且这些要求是开发人员赞同的。
甲方在需求活动中有以下义务：
1．给剖析人员解说业务及说明业务方面的术语等专业问题。
2．抽出时间清楚地说明需求其实不停完美。
3．当说明系统需求时，力争正确详尽。
4．需要时要及时对需求做出决议。
5．要尊敬开发人员的成本估量和对需求的可行性剖析。
6．对单项需求、系统特征或使用实例区分优先级。
7．评审需求文档和原型。
8．一旦知道要对项目需求进行改正，要立刻与开发人员联系。
9．在要求需求改正时，应依照开发组织确立的工作过程来办理。
10．尊敬需求项目中开发人员采纳的流程（过程）。
需求改正控制流程
32
软件需求作为系统功能的范围界定和说明， 其改正一定进行严格的改正控制
管理。本项目中，建议成立以下需求改正控制流程：
1．成立需求改正控制委员会，由项目管理组、项目业务技术组构成，并向
项目领导组负责。
2．软件开发面对初始经评审后的需求。
3．在项目履行过程中，如发生需求改正，需求改正提出者需提交所在单位
业务技术组该维度负责人员， 由该维度负责人员署名确认后提交需求改正控制委
员会，并通知项目组。
4．如项目组对需求改正无异议，该需求将进行开发实行。
5．如项目组对需求改正有异议或该改正的评估剖析结果对项目造成重要影
响，该需求将提交需求改正控制委员会合体议论， 依据议论结果断定该需求的处
理方式。
6．需求成立一致的表记系统，以方便其管理。
交流和监控体制
在项目履行过程中，能够经过以下手段对项目履行状况进行追踪和监控：
召开项目例会
项目负责人在每周召开项目例会， 项目周报、项目实行计划进度追踪状况是例会的重要输入，例会的主要内容包含但不限于：
项目状态检查及进度追踪；
当周重要事项的报告；
下周详尽工作计划；
改正恳求状态检查；
近期需提交的工作产品状态检查；
项目成职工作状况检查
其余各组负责人在每周提早召开本组项目例会， 参加项目负责人召开的项目例会。
编制项目周报
各组负责人每周编制“项目周报”，提交给项目负责人；
33
项目负责人汇总各组负责人周报， 按期或不按期向客户方、 监理方报告项目进展。
编制里程碑总结
a) 各组负责人在每个里程碑结束， 编制“里程碑总结报告”， 提交项目负责
人；
项目负责人汇总各组里程碑总结，向客户方报告项目里程碑进展。
召开管理评审会议
项目负责人在重要里程碑结束或项目进展异样时， 组织各组负责人和必需人员，召开管理评审会议，安排项目进展工作，对重要问题进行解决。
管理评审会议重视关注项目状态和管理协调问题， 技术问题不作为管理评审的主要内容， “里程碑总结报告”、 “项目管理问题管理表”是管理评审的重要输入。
5、项目会议纪要
项目会议是整个项目实行过程中项目组常态的共同方式， 会议纪要一致由监理方记录和形成最后会议纪要， 作为项目实行过程的构成部分， 发给项目组主要成员。
风险管理
风险管理过程
风险管理作为项目重要的预防活动， 将会比出现问题后的纠正更加有效的提高项目质量， 降低项目成本， 保证项目按期达成。
项目各阶段开始前辨别该阶段存在的各种风险， 早先进行缓解， 并拟订应急方案， 将项目风险对项目造成的影响降低到最低。
风险剖析
项目任务书下达后，在项目策划阶段由项目经理组织项目构成员、 项目总监、公司项目管理人员以及部门有关资深人员召开风险评估会议；
在会议上发给会议成员项目先期的有关资料， 参照组织文件的 “ 风险种类
34
与示例 ” 辨别出开发 / 实行过程中的所有风险，明确风险种类，拟订风险控制举措。项目经理负责依照会议结果填写《项目风险管理表》；
项目的各阶段开始前， 或项目发生重要改正时， 由项目经理共同项目构成员辨别新的风险， 修正先期辨别出的不正确的风险， 调整风险控制举措， 封闭已消逝或已发生的风险，进一步完美《项目风险管理表》，依照评审要求进行适合等级、形式的评审；
注意事项：
为保证风险控制与风险看管的有效履行，拟订的风险控制举措应清楚描绘时间、人员、活动，不要简单描绘概括性风险控制策略；
在项目实行过程中若有需与客户磋商的重要活动（比如产品交托、系统割接等）， 项目经理一定会同客户代表在实行行进行风险剖析，以保证该项活动的顺利实行；
《项目风险管理表》 成立以及每次更新后， 项目经理一定将风险管理的有关信息以适合形式见告项目构成员， 并负责将《项目风险管理表》 发送给所有项目构成员及公司受风险影响的各级有关人员，保证风险管理过程的全员参加。
2．风险控制
项目经理 组织项目构成员依照已确立的风险控制举措实行风险控制；
项目经理 负责风险控制举措实行后依如实质履行状况完美《项目风险管理表》的 “ 控制举措 ” 列信息。
3．风险看管
部门项目管理人员依据已拟订的控制举措对项目风险进行追踪看管， 以保证
风险控制举措的确实实行。
将对控制举措的考证信息及时填写入 《项目风险管理
表》；
部门项目管理人员在项目总结阶段，以达成的《项目风险管理表》为依照，
共同 项目经理对该项目进行过程中的风险进行整理总结，填写 “ 项目风险总
结剖析 ”，负责对组织文件的 “ 风险示例 ” 进行更新，为其余项目的风险
管理供应实用的信息。
35
项目风险剖析
项目各阶段开始进行风险辨别与控制， 并对应不一样阶段总结出各自典型的风
险，给出相应的风险级别微风险值计算方法。 本项目建设过程中可能存在的主要
风险有：
序
风险名称
控制举措
号
1
需求未能明确，比方
业务部门需要全力参加到数据中心的建设中，增强交流渠
需求不一致，需求模
道，扩大需求调研在整个工程安排的比率。两方分专业设
糊等
立需乞降设计负责人，归口一致管理。
2
设备配置不可以知足
在需求调研达成此后，依据系统设计需要提出硬件配置要
系统的设计要求
求，并对现有设备进行评估，最大限度的利用现有设备和
网络环境。假如必需，提早履行增补硬件设备的采买
3
内部多部门配合，外
因为本项目的建设波及多个部门，的数据根源于各个业务
部厂商、单位协调
专业信息不一样的系统，如何协调有关资源成为项目建设中
重中之重。所以成立项目领导小组，指定专人协调，筹备
必需的项目配