IT项目管理——图书馆管理系统.doc

图书馆项目管理计划书

系（部）名 称 计算机与信息科学系
组 长
组 员
课 程 名 称 信息系统项目管理
指 导 教 师

日 期： 2012 年 05 月 28日

一、 图书馆项目范围说明书

项目范围说明阐述进行这个项目的原因或意义，形成项目的基本框架，使项目所有者或项目管理者能够系统地、逻辑地分析项目关键问题及项目形成中的相互作用要素，使项目干系人在项目开始实施前或项目相关文档编写以前，能够就项目的基本内容和结构达成一致；项目范围说明应当形成项目成果核对清单，作为项目评估的依据，在项目终止以后或项目最终报告完成以前进行评估，以此作
为评价项目成败的依据；范围说明还可以作为项目整个生命周期监控和考核项目实施情况的基础，和项目其他相关计划的基础。
项目的原因和意义：尽量采用学校现有的软硬件环境，及先进的管理系统开发方案，从而达到充分利用学校现有资源，提高系统开发水平的应用效果的目的。便于学校教师和学生图书管理，通过查询可立即定位该读者的相应的信息，可以对图书进行查询、增加、修改，读者可以预约已借图书。
边界问题：时间限定：50天（扣除节假日）
成本限定：25万之内
人员：6名（这里面的需求人员，模块设计人员也要同时协助开发人员工作，开发人员主要进行主模块代码的编写，以及数据的编码问题，对于需求人员和设计人员可以编写一些小模块，界面等）

角色与人员分工：一共要用到6个人员

所需人数
角色
主要职责分工

1
项目经理1名
01.项目沟通交流

02.项目进度掌控

03.核心技术框架制定

04.工作任务划分分配、审核、验收

05.开发平台建设

06.样例程序制作

07.日常管理工作

08.重要文档成果物的整理

09.测试验收各个模块

10.架构设计整个系统的核心权限部分

11.解决疑难技术问题

12.模块设计指导

1
模块设计人员
01.进行系统概要设计

02.详细设计

03编写设计说明书

04.跟开发人员一起完成开发工作

3
程序员（高级程序员）
01数据库编码

02.主要模块的代码编写

4
实施人员1名
01.将软件交给用户并安装

02.对使用端的人员进行培训

03.后期维护

5
需求分析人员一名（同时也是系统分析员，客户联络员）
01.进行需求调研，需求分析

02.协助开发人员完成变成工作

6
测试工程师1名
01.协助处理文档整理工作

02.协助验收审核各模块详细设计文档

03.协助项目经理协调项目待解决问题

2.项目概述
2.1工作内容
本系统主要用于学校教师和学生图书管理，主要任务是通过建立图书管理系统，完善学校图书录入、借还、预约，续借以及读者信息的管理，管理员通过查询可立即定位该读者的相应的信息，同时可以对图书进行查询、增加、修改，读者可以进入系统进行图书查询和预订已借图书和续借。针对这些问题设计此系统。

该项目各个阶段所要实现的目标，参与人员和每个阶段要评估标准如下：
需求分析
制定需求功能列表与客户达成共识
相关人：需求分析人员、项目经理、客户组
完成需求分析说明文档及评审
软件设计
给客户、程序组、测试组做设计展示并根据要求修改完成设计
相关人：需求分析人员、设计人员、
客户代表、项目经理
完成架构设计、系统设计、数据库设计和用户界面设计及评审
软件开发
完成全部代码编写、单元测试和模块集成测试
相关人：需求分析人员、设计人员、开发人员、项目经理
软件基本功能实现，没有阻碍测试工作进展的问题
软件测试
完成功能测试、系统测试、压力测试和回归测试
相关人：测试人员、 项目经理
软件系统测试计划全部完成并达到质量要求
验收产品
调试，交付软件给客户
相关人：实施人员、客户代表、项目经理
完成试运行报告，进行人员培训，客户满意

这个系统中大致的范围有：

二、 图书馆管理系统开发项目进度安排

在实际工作中，项目规模往往比较大，为了合理安排时间，使图书管理系统能顺利完成，进度安排使得尤为重要。
由于项目开始于2012年3月21日，于2012年5月31日完成。
活动
号
任务名称
工作日
（天）
开始时间
完成时间
紧前活动

图书管理系统
50
2012年3月21日
2012年5月31日

项目规划
3
2012年3月21日
2012年3月25日

1
模板确定
1
2012年3月21日
2012年3月21日

2
撰写项目计划报告
2
2012年3月22日
2012年3月25日
1
需求分析
9
2012年3月26日
2012年4月8日

3
需求调研
2
2012年3月26日
2012年3月27日
2
4
需求分析
4
2012年3月28日
2012年3月31日
3
5
需求确认
2
2012年4月1日
2012年4月5日
4
6
撰写需求分析说明书
1
2012年4月6日
2012年4月8日
5
软件设计
11
2012年4月9日
2012年4月23日

7
系统分析
3
2012年4月9日
2012年4月11日
6
8
模块设计
7
2012年4月12日
2012年4月22日
7
9
数据库设计
5
2012年4月12日
2012年4月18日
7
10
美工设计
3
2012年4月12日
2012年4月16日
7
11
撰写详细设计说明书
1
2012年4月23日
2012年4月23日
8,9,10
软件开发
16
2012年4月24日
2012年5月16日

12
硬件安装
1
2012年4月24日
2012年4月24日
11
13
环境配置
1
2012年4月25日
2012年4月25日
12
14
书籍管理
10
2012年4月26日
2012年5月10日
13
15
借阅管理
10
2012年4月26日
2012年5月10日
13
16
读者管理
9
2012年4月26日
2012年5月9日
13
17
查询管理
8
2012年4月26日
2012年5月8日
13
18
系统维护
14
2012年4月26日
2012年5月16日
13
软件测试
9
2012年5月17日
2012年5月29日

19
集成测试
4
2012年5月17日
2012年5月22日
14,15,16,17,18
20
系统测试
4
2012年5月23日
2012年5月28日
19
21
撰写系统测试报告
1
2012年5月29日
2012年5月29日
20
验收总结
2
2012年5月30日
2012年5月31日

22
撰写用户手册
1
2012年5月30日
2012年5月30日
21
23
人员培训
1
2012年5月30日
2012年5月30日
21
24
产品转移
1
2012年5月30日
2012年5月30日
21
25
经验总结
1
2012年5月31日
2012年5月31日
26,27,28

甘特图：
任务
3-21~4-1
4-2~4-13
4-14~4-25
4-26~5-7
5-8~5-19
5-20~5-31
项目规划
-----

模板确定
=

撰写项目计划报告
====

需求分析
-----
-------

需求调研
==

需求分析
====

需求确认
=
====

撰写需求分析说明书

===

软件设计

-----
----------

系统分析

===

模块设计

==
=========

数据库设计

==
=====

美工设计

==
===

撰写详细设计说明书

=

软件开发

  --
------------
---------

硬件安装

=

环境配置

=

书籍管理

============
==

借阅管理

============
==

读者管理

============
=

查询管理

============

系统维护

============
=========

软件测试

---
----------
集成测试

===
===
系统测试

======
撰写系统测试报告

=
验收总结

--
撰写用户手册

=
人员培训

=
产品转移

=
经验总结

=

图书管理系统的网络图：

（1）关键路径：
开始—>1—>2—>3—>4—>5—>6—>7—>8—>11—>12—>13—>18—>19—>20—>21—>22—>25—>结束
即是：模板确定—>撰写项目计划报告—>需求调研—>需求分析—>需求确认—>撰写需求分析说明书—>系统分析—>模块设计—>撰写详细设计说明书—>硬件安装—>环境配置—>系统维护—>集成测试—>系统测试—>撰写系统测试报告—>撰写用户手册—>经验总结
1+2+2+4+2+1+3+7+1+1+1+14+4+4+1+1+1=50（天）
那么这个系统的工期是50天。

三、 图书馆管理系统开发项目人员分配

项目人力资源计划就是决定在项目中的每一项工作中用什么样的人力资源，确定人力资源的数量、质量和结构。
1、项目团队的组织结构及其角色职能列表

A、 组织结构
图书管理系统的项目管理是采用项目型组织，各成员按照从事的项目组成不同的团队，并由指定的项目经理来协调和管理项目的运作。
a、职能型组织
b、项目型组织
c、矩阵型组织
弱矩阵型组织
平衡矩阵组织
强矩阵组织
d、复合型组织

B、 人员要求
a、 项目经理
1、有5年以上软件研发经验
2、能分析和判断大部分软件问题。对项目软件开发过程负责。有丰富的项目经验和很强的责任心。
3、有熟练的英文阅读能力和交流能力。
b、 调研分析员
1、计算机、软件工程等专业本科以上学历；
2、熟悉需求调研方法，具备较强的业务流程及业务模型分析设计能力；
3、 熟悉软件工程理论，掌握软件需求获取与分析方法；
4、 具备财务软件、物流系统软件、ERP\SAP等系统软件的需求分析经验优先考虑；
5、有较强的文档编写能力，有较强的团队协作精神
c、 系统分析员
1、精通Java语言，WEB编程，熟悉J2EE应用系统开发，熟悉Weblogic/Tomcat等应用服务器；
2、熟悉Oracle/SQLSERVER等数据库的设计与开发；
3、熟悉软件开发流程，具有需求分析和架构设计的实际经验；
4、能够控制客户需求，并能够处理好与客户之间的关系，有较强的文档撰写能力；
5、能够高效的管理与激发团队，使团队更具有凝聚力。
d、 模块设计员
1、精通java及数据库相关知识（至少3年以上开发经验，1年以上架构设计经验）；
2、熟悉面向对象的分析设计方法；
3、熟练使用UML工具进行建模设计，并能充分理解客户的需求并根据需求进行模块化和面向对象分析设计；
4、能够独立完成系统需求分析与概要设计设计工作；
5、有较强的系统需求分析、设计文档编写能力；
6、具有良好的团队协作精神，有较强的业务模型分析能力，思维清晰敏捷，逻辑分析能力强，善于与人沟通，能够承担一定的工作压力
e、 测试工程师
1、计算机、软件工程等相关专业；
2、具有五年以上软件开发或测试相关工作经验；
3、对人员管理、资源调配、测试方法改进等经验；
4、分析能力强，思维周密、积极主动，关注细节，勇于创新，良好的沟通技巧以及优秀的言语表达能力，具备良好的团队合作精神；
5、熟悉一些主流的软件工程方法论和思想，了解软件工程，软件生命周期模型基础；
6、熟悉软件配置管理理论工具
f、 实施人员
1.积极上进
2.有项目管理经验优先
3.肯吃苦,能出差
g、 客户联络员
1、 较强的沟通、理解和应变能力
2、 有刚正不阿的性格，吃苦耐劳的精神
3、 服从公司工作安排，能长期出差。

2、角色职能列表
角色
姓名
职责
项目经理
孙林
项目总体设计，制定和监控开发进度，制定相应的开发规范、负责各个环节的评审工作，协调各个成员（小组）之间开发。
调研分析员
李玲
实际调研，提供详细的策划方案和需求分析
系统分析员
李玲
根据需求分析报告进行总体分析，得出系统的概念模型
模块设计员
孙立平
根据系统分析结果对系统做模块化分及相关接口定义
程序员
张向阳
编写功能模块的实现代码并惊醒单元测试
测试工程师
林左婷
测试程序及系统的功能
实施人员
王雪岩
负责工程实施， 现场培训， 协助项目验收，需求的初步确认，项目维护。
客户联络员
王雪岩
与客户联系、协助其他人员与客户的交流

3、项目团队的知识地图与职责分配矩阵

A、 能力打分标准
5分：熟悉使用此方面的知识，有丰富的实践经验，能够领导其他成员完成相应的工作。
4分：熟悉此类只是，但经验不够丰富。
3分：对此类只是有一定的了解，需要进一步学习。
2分：对此类只是有过少量接触，不过缺乏深入了解。
1分：对此类只是完全没有了解。

B、 兴趣分打分标准
5分：此类工作完全符合本人的兴趣，对该工作抱有极大的热枕
4分：对该工作比较有兴趣，能够比较愉快的完成工作
3分：能偶以平常心态完成该项目工作，谈不上有兴趣。
2分：能够勉强接受该工作，尽量完成任务。
1分：非常厌恶此类工作。

C、 知识地图得分表
项目经理：孙林
项目成员：李玲，王雪岩，孙立平，张向阳，林左婷

孙林
李玲
孙立平
张向阳
林左婷
王雪岩
项目规划
能力分
4
3
4
3
3
3
兴趣分
4
1
3
3
2
2
需求分析
能力分
3
4
5
3
4
3
兴趣分
2
3
4
3
3
2
软件设计
能力分
4
4
3
4
3
4
兴趣分
2
3
3
5
4
3
编程实现
能力分
5
4
4
4
4
2
兴趣分
2
3
4
2
5
4
系统测试
能力分
3
4
2
4
4
4
兴趣分
2
3
4
2
5
2
验收总结
能力分
3
3
3
4
4
5
兴趣分
2
4
2
3
3
4

指责分配矩阵
责任分配矩阵（RAM）是用于对项目成员进行分工，明确其角色与职责的有效工具。通过责任分配矩阵，项目的每个具体任务都能落实到参与的团队每个人上。
· 谁负责（R = Responsible）， 即负责执行任务的角色，他/她具体负责操控项目、解决问题。
　　· 谁批准（A = Accountable）， 即对任务负全责的角色，只有经他/她同意或签署之后，项目才能得以进行。
　　· 谁支持（S = Supportive）， 即提供信息资源，辅助执行任务的人员。
· 通知谁 (I =Informed), 即拥有特权、应及时被通知结果的人员，却不必向他/她咨询、征求意见
· 咨询谁（C = Consulted）， 拥有完成项目所需的信息或能力的人员。

工作单元
孙林
李玲
孙立平
张向阳
林左婷
王雪岩
1
项目规划
R
I
A
S
I
C
2
需求分析
C
R
A
S
C
I
3
软件设计
A
I
R
I
A
S
4
软件开发
I
C
C
R
A
A
5
软件测试
I
A
A
S
R
A
6
验收总结
A
I
I
S
A
R
7
系统审核
R
I
S
I
I
I

3、成员考核

孙林
李玲
王雪岩
孙立平
张向阳
林左婷
项目成员特征
学历

工作年限

岗位

项目成员行为
勤奋

团队意识

遵守纪律

忠诚度

项目成员结果
CPI

SPI

工作质量

客户满意度

项目成员总评

四、 图书馆管理系统开发项目的成本估算：
图书馆项目的成本包括项目进行全过程所消耗的各种费用总和。根据工作分解结构制定出项目分摊估计表来有效的进行项目的成本计划。合同规定项目的总成本（包括软件开发成本、硬件成本和开发中的其他成本）是25万元人民币。
根据项目团队制定的工作分解结构，按照系统的生命期将本项目划分为六个活动，分别是项目规划、需求分析、软件设计、编程实现、系统测试、验收总结。对这六个活动进一步分解得到21个小活动。小活动的成本主要由劳动力成本（工资）和硬件成本构成。其中工资根据工期、人数和日工资来确定，硬件成本根据该项小活动的需求数量来确定。成本的估算采用自下而上估算法，先估算出每项小活动的预算，然后在算出大活动的预算，进而预算出整个项目的成本。

表1 图书馆项目工资标准计算表

资源名称
最大单位
标准费率
加班费率
每次使用成本
成本累算
基准日历
1
孙林
100%
￥330/工作日
￥50/小时
￥0.00
按比例
标准
2
孙立平
100%
￥220/工作日
￥40/小时
￥0.00
按比例
标准
3
李玲
100%
￥200/工作日
￥35/小时
￥0.00
按比例
标准
4
张向阳
100%
￥200/工作日
￥35/小时
￥0.00
按比例
标准
5
林左婷
100%
￥150/工作日
￥30/小时
￥0.00
按比例
标准
6
王雪岩
100%
￥220/工作日
￥40/小时
￥0.00
按比例
标准

表2 图书馆项目分摊估算表（单位：元）
活动
小活动
预算小活动分摊
预算大活动分摊
预算累计
项目规划
1、模板确定
1320

3960
1320
2、撰写项目计划报告
2640
3960

需求分析
3、需求调研
2640

11880
6600
4、需求分析
5280
11880
5、需求确认
2640
14520
6、撰写需求分析说明书
1320
15840

软件设计
7、系统分析
3960

25080
19800
8、模块设计
9240
29040
9、数据库设计
6600
35640
10、美工设计
3960
39600
11、撰写详细设计说明书
1320
40920

软件开发
12、硬件安装
25900

45700
66820
13、环境配置
1320
68140
14、代码实现
18480
86620

软件测试
15、集成测试
5280

11880
91900
16、系统测试
5280
97180
17、撰写系统测试报告
1320
98500
验收总结
18、撰写用户手册
1320

5280
99820
19、人员培训
1320
101140
20、产品转移
1320
102460
21、经验总结
1320
103780

表3： 图书馆项目其它经费预算表（单位：元）
１
差旅费
3500
交通费用、伙食费、住宿费以及差旅补贴等等
２
资料费
1500
图书费、资料费、复印费
３
通信费
2000
市话长话费、移动通信费、上网费、邮资
４
办公费
2000
购买办公用品
５
协作费
11000
业务协作招待费、项目团队加班伙食费
6
奖金及福利费
15000
奖金、节假日福利等
7
加班费
15000
根据加班费率计算
8
房租
9000
包含地税
９
水电费
1000

１０
项目监理费
5000
项目开发过程的监理费
１１
后期维护费
20000
上线后期半年的维护
１２
其他
5000
检测、维修费、消耗品、低易品、茶话会等
其他经费预算总计
90000

经过预算， 图书馆项目预算总金额为193780元。项目的合同规定总成本为250000，基本上达到22.5%的利润率。

五、 图书馆管理系统开发项目风险分析报告
1、软件开发项目的风险背景
信息产业的发展是目前发展最快的行业之一，也是对社会影响最大的一个行业，它不但为我们创造了巨大的财富，而且从各个方面改变着我们的生活，达到一个行业，小到一项服务。我们不得不承认软件是二十一世纪最不可思议的产品。
伴随着软件开发技术的不断更新、软件数量的增多、软件复杂程度不断加大、客户对产品的要求也在不断的提高，随之而来的是软件开发项目给软件开发企业和需求企业带来的巨大风险。软件开发项目的成功与否会直接影响到公司的生存。这对软件开发企业来讲应该是更大的难题。一方面是业务需求更加复杂。人们对软件质量和用途的期望大幅度提高，对业务系统的要求也越来越挑剔。另一方面是开发成本不断缩减。在此形势下，风险管理与控制已成为软件开发项目成败的关键。
软件开发项目由于其具有连续性、复杂性、少参照性，无标准规范等特点，其风险程度较高。目前国内的大多数软件开发企业还缺乏对软件开发项目的风险认识，缺少进行系统、有效的度量和评价的手段。据有调查数据显示，有15—35%的软件项目中途被取消，剩下的项目不是超期就是超出预算或是无法达到预期目标。另外，软件项目因风险控制和管理原因失败的约占90% ，可见，软件风险控制与管理在目前的软件开发项目中的重要性。
2、风险管理与风险控制介绍
1）风险管理
风险管理应是贯穿软件项目开发始末的一项重要任务，其中包括风险识别、风险评估、风险计划、风险解决和风险监控。它能让风险管理者主动“规避”风险，进行有效的风险管理。风险管理模型有：SEI风险管理模型、Riskit风险管理模型、SoftRisk风险管理模型、IEEE风险管理过程模型、CMMI风险管理模型、MSF风险管理模型等。在项目管理中，建立风险管理策略，在项目的生命周期中不断控制风险是非常重要的，风险管理主要包括五个阶段：
(1)风险识别：识别风险的方法常用的有现场观察法、座谈法、流程图法、财务报表法、相关部门配合法和环境分析法等。
(2) 风险评估：对已识别的风险要进行估计和评价，风险估计的主要任务是确定风险发生的概率与后果，风险评价则是确定该风险的经济意义及处理的费/效分析，常用的方法有：概率分布、外推法、多目标分析法等。
(3) 计划进度：按照评估后的风险结果，制定相应的风险管理进度表，为后续的风险管理提供参考。
(4) 风险处理：一般而言，风险处理有三种方法，① 风险控制法，即主动采取措施避免风险，消灭风险，中和风险或采用紧急方案降低风险。② 风险自留，当风险量不大时可以余留风险。③ 风险转移。
(5) 风险监控：包括对风险发生的监督和对风险管理的监督，前者是对已识别的风险源进行监视和控制，后者是在项目实施过程中监督人们认真执行风险管理的组织和技术措施。
2）风险控制
(1)建立有效的风险控制的组织机构
①设置风险管理岗位：在软件开发项目管理过程中设置风险管理岗位，该岗位的主要职责是在制订与评估规划时，从风险管理的角度对项目规划或计划进行审核并发表意见，不断寻找可能出现的任何意外情况，试着指出各个风险的管理策略及常用的管理方法，以随时处理出现的风险，风险管理者最好是由项目主管以外的人担任。风险管理岗位的人数依据项目大小来决定，一般2—3人较为适合。
②双项目经理：为项目开发项目设定两个项目经理岗位，一个负责技术岗位，另一个负责管理岗位。目前，国内的软件开发企业的项目经理一般都是一名，而且是技术出生的占绝对多数，他们主要擅长的是技术研发，在管理方面先天不足，这不利于项目风险管理和控制。通过增加专门的管理经理岗位，可以弥补技术出生的项目经理的不足，提升软件开发项目的管理水平。而且这样的经验也已得到了国外业界大多企业的认可。
(2) 建立有效的风险控制管理过程
风险管理过程包括培训，风险识别、风险分析、风险计划、执行计划、跟踪计划等活动，有效的风险管理过程应是学习型的、持续的和不断改进的。软件企业应建立自己的风险管理数据库作为风险管理的基础，并在实施中不断地更新和完善。
根据企业和项目的实际情况，进行科学的项目风险和控制，对项目的成功研发有着举足轻重的意义。在项目开发的过程中，进行必要的项目风险分析，制定符合项目特点的风险评估和监督机制，特别是要定期对项目的风险状况进行评估和监管，发现意外风险或者是风险超出预期的一定要重点关照。发现问题要立即上报，尽快解决。并建立风险监管日志，实行“岗位负责制”，将软件开发项目的风险降到最低

3、软件开发项目的风险来源及对项目成败的影响
软件开发项目风险是指在软件生命周期中所遇到的所有的预算、进度和控制等各方面的问题，以及由这些问题而产生的对软件项目的影响。软件项目风险经常会涉及许多方面，如：缺乏用户的参与，缺少高级管理层的支持，含糊的要求，没有计划和管理等，总体概括下来应该由楼六大方面。
1） 需求风险
很多项目在确定需求时都面临着一些不确定性。当在项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生错误的产品或者拙劣地建造预期的产品。每一种情况对产品来讲都可能致命的。
2） 相关性风险
许多风险都是因为项目的外部环境或因素的相关性产生的。经常我们在控制外部的相关性上做的不够，因此缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并且觉察潜在的问题。
3） 技术风险
软件技术的飞速发展和经验丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。在早期，识别风险从而采取合适的预防措施是解决风险领域问题的关键，
4） 管理风险
尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没有包括所有管理活动而感到惊奇。在大部分项目里，项目经理经常是写项目风险管理计划的人，他们有先天性的不足——自己检查自己的错误，这是最难的。然而，像这些问题可能会使项目的成功变得更加困难。如果不正视这些棘手的问题，它们就很有可能在项目进行的某个阶段影响项目本身。
5）自然风险
软件产品本身也属于一种应用型产品，同样会受到自然灾害的的影响。
项目风险分解图

4、 图书馆管理系统风险应对表

风险识别
风险定性与定量分析
风险应对
编号
WBS模块
风险事件
风险概率
风险影响描述
风险影响值
风险期望值
排序
级别
缓解策略策略
应急计划和巢湖发事件
风险处理措施
风险负责人
1
需求风险
需求分析不到位，导致数据模型建立好后无法使用
6%
10%≤成本增长<20%
0.2
0.12
8
四级
1、重新进行到位的需求分析
1当数据模型建立后无法使用时，即使重新做需求分析
一周
工作包负责人
2
需求风险
缺少有效的需求变化管理过程
10%
5%≤进度实施<10%
0.2
0.020
6
四级
1、及时和项目经理进行有效的沟通，确保需求的有效管理
1、当缺少有效的需求变化管理过程时，要及时，与相应的管理人员惊醒沟通，制定有效的变化管理
三天
工作包负责任
3
需求风险
客户不断变化需求
9%
工作质量受到较小的影响
0.1
0.009
9
四级
1、要做好与客户之间的沟通工作2、工作人员要做好应对必要变化的准备，满足客户的需求
当客户不断变化需求时，1、要做好与客户之间的沟通工作2、工作人员要做好应对必要变化的准备，满足客户的需求
一周
工作包负责人
4
需求风险
院图书馆调研经常推后
20%
10≤进度拖延<
0.4
0.080
1
三级
与客户相关人员惊醒有效沟通
当需求调研不能及时进行时，根据合理时间调研并与相关工作人员进行有效沟通并确定调研时间
两天
项目经理
5
需求风险
某些需求超出项目范围
25%
范围主要部分受到影响
0.2
0.050
3
三级
查看范围进度计划，并与客户，进行合理的沟通
1、某些需求超出项目范围时，1、明确列出超出项目范围需求，2查看范围进度计划，并与客户，进行合理的沟通
一天
项目经理
6
需求风险
漏掉某些模块或多了某些模块
6%
范围的次要不分受到影响
0.1
0.006
11
四级
查看范围进度计划，及时修改
当漏掉某些模块或多了某些模块时，1、查看范围进度计划，及时与项目经理进行沟通，如果漏掉某些模块，及时把漏掉的任务分配给相应的工作人员进行补充，如果多了一些设计模块，查看进度，并决定是否删除多出的模块
一周
工作包负责人
7
相关性风险
签订合同不科学不严谨，存在边界界定不清楚的问题
15%
10%≤进度实施<20%
0.4
0.060
10
四级
及时与客户进行有效沟通并重新修订合同
当合同有问题时，1、及时与客户进行有效沟通，并进行重新修订合同，2、重新根据需求制定更加完美的合同
桑拿天
项目经理
9
相关性风险
软硬件不兼容
1%
项目的最终产品实际上不能使用
0.8
0.040
12
四级
及时与供应商联系，并进行有效沟通，更换硬件设备
当软硬件不兼容时1、及时与供应商联系，并进行有效沟通，更换硬件设备2、如果无法更换，查看该硬件是否可以用在该系统的其他位置
三天
工作包负责人
10
相关性风险
病毒、黑客入侵造成系统无法正常工作
5%
项目的最终产品实际上不能使用
0.6
0.050
16
三级
做好系统安全防护
当病毒、黑客入侵造成系统无法正常工作时，1、及时进行系统体检，用相关工具杀毒，2、通过相关设备对系统进行有效保护防止系统再次收到攻击

11
技术风险
预算有误，导致开发过程无法进行
9%
10%≤进度实施<20%
0.2
0.018
7
四级
向投资者申请新的的资金
当预算有误，导致开发过程无法进行时，向投资者申请新的的资金，2、向投资者展示新的预算和以前错误的预算
一周
工作包负责人
12
技术风险
开发工具不可靠导致项目过程中的bug
5%
10%≤进度实施<20%
0.40.
0.032
5
四级
确定开发工具可靠
当开发工具不可靠时，1、及时做测试，发现bug。2、更换开发工具
一周
工作包负责人
13
技术风险
使用框架存在漏洞bug，导致项目失败
1%
质量降低需要得到有关领导的批准
0.2
0.002
13
四级
测试人员及时发现问题，开发人员及时解决问题
当使用框架存在漏洞bug，导致项目失败时，1、及时对框架进行修复2、更换更可靠的框架
一周
工作包负责人
14
管理风险
技术人员离职，模块任务无人完成
5%
10%≤进度实施<20%
0.3
0.050
2
三级
1、加强人员考核；确定人员的可靠性2、及时需找人员代替气工作
当技术人员离职，模块任务无人完成时1、加强人员考核；确定人员的可靠性2、及时需找人员代替气工作3、与当事人做及时沟通，
2天
项目经理
15
管理风险
不能按进度计划完成相应的任务
2%
10%≤进度实施<20%
0.3
0.060
14
四级
做好跟踪记录
当不能按进度计划完成相应的任务时，1、做好对每个人的及时跟踪记录，2、若不能按进度完成，应当进行加班完成相应任务
一周
工作包负责人
15
管理风险
进度进化不够完善导致整体任务滞后
5%
质量降低需要得到有关领导的批准
0.6
0.086
15
三级
及时调整计划
当进度进化不够完善导致整体任务滞后时1、及时调整计划2、将所差进度加班完成
2天
工作包负责人
16
自然风险
火灾、涝灾、地震等自然灾害

1%
质量降低需要得到有关领导的批准
0.3
0.020
16
三级
做好转移工作，降低损失程度
当火灾、涝灾、地震等自然灾害时1、做好系统备份的转移工作，把损失降低到最小2及时做出应急处理，是相关负责人做出快速反映。
三天
工作包负责人