项目管理课程设计.docx

学生课程设计报告
课程名称： 项目管理课程设计
题 目： 超市结算系统
年　 级：　　2011级　　　
专　 业：信息管理与信息系统
学　　号：
姓　　名：
指导教师：　　 　 　
完成地点：管理学院综合实验室
完成日期： 2014年6月1日
20 13 学年至20 14 学年度第 2 学期
目录
0、导言................................................1
1、提出项目............................................1
2、选择项目............................................2
3、建立项目组织........................................2
4、项目立项............................................5
5、项目范围管理计划....................................7
6、项目时间管理计划....................................10
7、项目成本管理计划....................................17
8、项目质量管理计划....................................22
9、项目人力资源管理计划................................25
10、项目沟通管理计划...................................28
11、项目风险管理计划...................................30
12、项目采购管理计划...................................36
13、项目配置管理计划...................................37
14、项目集成管理计划...................................41
0、导言
超市结算系统的目的是是实现超市结算过程中自动化所需要的一切功能，包括管理货物，支持用户结算，统计货物销售情况等。系统将提供给超市前台，会计以及经理等管理人员使用，进行日常任务，工作的管理，提高工作效率。同时将实现各项功能的完善封装以及建立友好的图形用户界面使得用户能较快的上手使用。
1、提出项目
1.1 超市结算系统
1.2 设计一个小游戏的应用
1.3 .开发一个电子商务网站
内容
超市结算系统
小游戏
电子商务网站
项目如何诞生
为了方便顾客付款，收银员的快速结算，以及加快对退货赠品等事项的处理。附近超市提出了开发一个操作便捷，界面清晰的超市结算系统。

运用已学的知识能够做到
对网站网页的风格设计较感兴趣
项目特征
需求较易弄清、涉及的知识面广、具有一定的可操作性
规模小，容易实现
方向难以明确，对安全性，稳定性要求高
生命周期
需求分析、系统的方案设计、设计系统、结束设计、维护系统
确定游戏类别规模、设计游戏，验证游戏
确定使用人群，需求分析，整体设计，网站详细设计，结束设计，安全维护
项目阶段
1. 需求调查，弄清客户需求
2. 根据客户需求，制定几套设计方案
3. 用户选择方案，查找需要的资料
4. 进行系统设计，并实时修改
5. 客户验收系统，做好相关的维护工作
1. 查找资料选择小型的容易操作的游戏类别
2. 进行游戏的结构设计（包括游戏的计分方法、游戏的模式等）
3. 设计游戏
4. 试玩游戏，检验游戏的稳定性
1. 综合团队的意见，确定网站的方向。
2. 进行市场调查，做出需求分析
3. 确定网站的整体风格，网页数等
4. 分配任务进行详细设计
5. 结束设计，进行安全测试，进行网站维护
交付的成果
可供客户方便使用的超市结算系统
一个简单的射击小游戏
安全稳定的旅游电子商务网站
2、选择项目
提出的三个项目具有一定的相似性，都是运用计算相关的知识进行设计开发的。如何选择项目，采用加权评分的方法进行评分选择。
整体分析如下表 备注：1.所有指标的权重之和为100
2.分数由1到100表示程度加深
指标
权重
超市结算系统
小游戏
电子商务网站
总体规模
20%
80
50
75
知识运用范围
15%
70
30
70
信息收集量
15%
50
30
60
人员数量
10%
30
10
35
时间成本
15%
60
20
70
资金成本
5%
20
10
20
收获
20%
60
30
40
项目权重得分
100%
59
29.5
57.5
结果显示：开发超市结算系统的项目权重的得分最高，所以选择的项目为超市结算系统。
3、建立项目组织
3.1项目授权
3.1.1 《乙方项目授权书》(见附录1)
3.1.2 《项目章程》
一、项目概述：
1、项目名称：超市结算系统
2、项目背景：
21世纪我国的超市产业飞速发展，其经营模式更为复杂，旧的管理体制已经无法适应超市的发展，这就迫切的需要引进新的管理技术。超市的数据和业务越来越庞大，而计算机就是一种高效的管理系统，这就需要我们把超市的管理与计算机结合起来，从而超市管理系统应运而生。依靠现代化的计算机信息处理技术来管理超市，节省了大量的人力、物力，改善了员工的并且能够快速反映出商品的进、销、存等状况和各种反馈信息分析，使管理人员快速对市场的变化做出相应的决策，加快超市经营管理效率。
3、项目目的：
通过网络传递销售信息可以不受距离的限制的优势，我们可以借阅许多的人力和物力，方便管理，由此可以减少不必要的开支，通过超市管理系统提高超市的销售效率，同时提高超市的经济效益。
4、 项目主要工作：
系统计划：问题定义和可行性研究，写出项目计划书和可行性研究报告
系统需求分析：分析目标和任务，画出数据流程图，编写数据字典
系统总体设计：画出系统结构图，找出所有的系统模块，并开始设计数据库，编写概要设计说明书
系统详细设计：画出基本逻辑结构图，N-S结构流程图，代码设计，用户界面设计，数据输入与显示，控制界面的设计，系统安全控制设计，编写详细设计文档
系统测试：对系统记性全面的测试
系统实施与维护： 系统的实施以及对系统运行后的维护
二、项目目标：
1、时间目标：本项目要求于_2014__年_3_月_24_日开始，于_2014__年_6_月_1_日结束。项目的结束以正式发布项目结项通知的日期为准。
2、可交付成果目标：
本项目要求最终交付如下的成果：
2.1 项目应于2014年6月29日前提交__超市结算系统和用户使用说明书__。由__项目经理__负责组织评审，须满足的质量要求为：_系统能在三日内快速完成安装，_用户能在15个工作日内学会使用系统，系统在三个月内能无错的稳定运行_。
2.2. 项目应于2014年6月29日前提交_系统的各项说明书，测试报告_________。由_项目经理_负责组织评审，须满足的质量要求为：__系统开发设计过程中的各阶段的文档都有，文档的格式，内容符合规定_____。
3、 费用目标：
本项目总预算为：￥_25000.00___元整。
三、项目管理团队:
3.1 项目赞助人： ；
3.2 项目经理： ；
3.3 项目PMO代表： ；
3.4 项目技术负责人：__；
四、项目团队成员名单
序号
姓名
所属部门
项目工作内容
技能要求
预计开始日期
预计工期
（工作日）
1

项目经理
领导项目小组进行项目的所有工作
领导、管理能力

2

设计部门
负责项目的设计
项目设计能力

3

生产部门
负责项目的生产
项目生产能力

4

研发部门
负责项目的研发
系统研发能力

3.2 项目组织结构
项目设计主管
项目研发主管
项目生产主管
项目经理

3.3 项目经理选择
3.3.1项目经理选择：
项目
项目管理知识
应用领域相关知识、标准和规则
项目环境知识
管理知识和技能
人际关系技能
等级
优秀
优秀
良好
良好
优秀
总评
优秀
3.3.2项目经理能力考评：
4、项目立项
4.1 项目名称及来源
项目名称：超市结算系统
项目属性：虚拟项目
项目发起人及简介：
武汉中商平价连锁分公司（简称"中商平价"）是武汉中商集团股份有限公司下属的三大连锁公司之 一，是一家以超市连锁经营为主的商业零售企业。
中商平价成立于2000年，经过近8年的不断发展，目前已发展成为拥有连锁门店30余家，网点遍布湖北武汉、襄樊、荆门、荆州、仙桃、黄石、黄冈、大冶等12地市，年销售达35亿元的大型连锁企业，在华中地区位于前三甲，旗下年销售过亿元的综合型大卖场6个，社区超市和区域公司购物广场24个，总经营总面积达35万余平方米。
武汉中商平价超市连锁有限责任公司（简称中商平价），是大型上市企业武汉中商集团股份有限公司旗下的全资子公司，是主营超市业态的现代化连锁商业企业。
位于民族大道的中商平价曙光超市也是武汉中商平价连锁超市中的一家。其重要面对的客户群为周边的学校的学生和居民。因此其产品类型有限。为了方便顾客付款，收银员的快速结算，以及加快对退货赠品等事项的处理。超市管理人员提出了开发一个操作便捷，界面清晰的超市结算系统。
4.2、拟定《甲方招标书》（见附录）
4.3、拟定《乙方投标书》（见附录）
1.4、项目合同
4.5项目利益相关者分析
利益相关者：曙光超市的管理人员、收银员、顾客，项目团队—我们项目组。
关键项目利益相关者分析表
因素
超市的高层管理人员
收银员
项目团队
系统安全性
需要良好的系统安全性，保障超市信息的安全。需要仔细的探讨安全性。
系统便于灵活运用，不会出现死机、卡机、或商品信息录入错误等
根据客户的要求，采取一定的措施，确保系统安全。可能对项目完成的时间，所需的成本有一定的影响
系统的总体开发时间
过长无法尽快使用，过短对系统的稳定性不放心
在软件开发时期，可以用已有的软件暂时代替，所以影响不大
需要把握好开发时间，时间越长可能开发的系统效果越好，但成本也会加大
系统操作的难易程度
操作简便的系统，便于管理者提取信息，制定计划
便于操作的系统能过加快结算的速度，提高工作效率
简便的操作界面，对开发的要求提高，需要不断完善
系统开发的模型选取
无影响
无影响
采用快速原型法，更好的了解客户需求，设计出客户需要的系统
选取原有系统作为参照
能过减少系统开发的资金投入，便于理解使用
便于理解，能尽快的掌握，但可能出现操作失误
增加了开发的工作量开发的难度减弱
系统成功开发的标准
客户的消费信息能够准确的录入，信息统计分类准确，系统稳定
便于理解操作，系统稳定
达到客户要求，系统安全稳定
4.6 确定项目的生命周期
将整个项目分为如下几个阶段：
阶段
简介
备注
项目启动

里程碑
1.需求识别
识别客户需求
系统需求分析报告
2.系统定义
对系统进行客观完整的描述

项目计划

里程碑
1.可行性研究
分析项目实施的条件需求，判定项目能否实现
可行性研究报告
2.概要设计
对系统进行初步设计
相应的设计文档
3.详细设计
对系统进行具体明确的设计
详细设计文档
项目实施

里程碑
1..系统实现
对系统进行实现
完整的超市收银系统
2.系统测试
测试系统的性能，安全性等方面
测试报告
用户验收

1.系统验收
交与客户验收

2.系统运维
对系统进行维护

4.7 最佳管理实践
企业团队的管理最终是对人的管理。很多成员除了对物质利益的需求以外，还需要提升自我，实现自我价值。因此团队的管理采用人性化的管理方式，根据不同成员的个性特点分配相应的任务，发挥他们的主观能动性，营造一种积极活跃的团队氛围。
5、项目范围管理计划
5.1、项目章程：
超市结算系统项目章程
项目名称: 超市结算系统
授权时间：2014年3月24日
项目开始日期：2014年3月24日 项目结束日期：2014年6月1日
关键进度里程碑：
l 3月31日完成需求调查，结束需求报告的撰写
l 4月13日完成总体设计，提交总体设计报告
l 5月11日系统设计完成
l 5月18日完成系统安装
预算：系统开发所需硬件和软件主要采用已有版本，项目的主要成本为人工成本，该项目预算为2000元。
项目经理：
项目目标：基于客户需求，在6月1日前完成系统设计，并能安全稳定的替代旧的系统。
方式：
l 针对系统服务对象，进行信息收集
l 集体探讨项目的整体架构
l 将系统测试贯穿到系统整体开发过程中
角色及责任
姓名 角色 职位 联系方式
发起人 经理
项目经理 经理
项目组成人员 PMO代表
项目组成人员 设计总监
项目组成人员 工程师
签署人：（上述全部利益相关者签名）

意见（由上述利益相关者手写或打印）
“我希望大家能够积极的工作，在规定的时间内高效率的完成整个项目”
——项目经理
“我希望大家合作愉快” ——PMO代表
工作分解结构WBS
6、 项目时间管理计划
6.1项目进度计划
6.1.1项目活动的依赖关系
在甘特图中，确定各个子项目的依赖关系，由前置任务可以看出，在项目过程中，基本按照项目的流程进行，如图所示：
图一
6.1.2活动历时
活动从2014年3月24日开始，2014年6月1日结束。总历时50个工作日。
其中启动项目3个工作日、编制项目计划3个工作日、执行任务23个工作日、控制任务5个工作日、结束任务15个工作日。
6.1.3前导式网络图
图二
图三
6.1.4确定关键路径和时差
由甘特图所示，确定的关键路径如图
图四
根据甘特图上各个子任务的状态，确定最早开始时间和最晚开始时间，由于项目主要是按照项目分解的流程工作，所以项目的自由时差和总是差相对较少，下图为EXCL表截图：
图五
6.1.5确定里程碑
3月31日完成需求调查，结束需求报告的撰写
4月13日完成总体设计，提交总体设计报告
5月11日系统设计完成
5月18日完成系统安装
6.2详细项目进度计划
对于项目的详细进度，主要包括各个子任务的工作时间、总工程历时和里程碑任务的提交时间，如图所示
图六
PDM图：
图七
图八
显示关键路径：
图九
时差：
图十
6.2最佳管理实践
利用软件开展项目的时间管理，协助沟通的软件能够帮助项目经理同项目的利益相关者交换与进度有关的消息，决策支持模型能够帮助项目经理分析权衡各种进度方案。
3、项目工作分解结构（WBS）
1、 项目启动
2、 启动任务
2.1与项目发起人的启动会议
2.2研究类似项目
2.3草拟项目要求
2.5制定项目章程
2.6签署合同
3、 编制任务计划
3.1系统计划
3.1.1系统定义
3.1.2可行性分析
3.1.3撰写项目计划书
3.2系统需求分析
3.2.1需求调查
4、 执行任务
4.1分析任务
4.1.1研究旧系统
4.1.2设计任务
4.2详细设计
4.2.1模块设计
5、 控制任务
5.1预览报告
5.2系统测试
6、 结束任务
6.1客户验收
6.1.1验收系统
6.1.2交付各阶段相关报告
7、 结束项目
7、 项目成本管理计划
7.1 成本估算
7.1.1 合同成本估算
根据以往类似的项目经验，通过类比估算方法，对项目进行了粗略的成本估算，对于此次项目的估算金额为25000.00元。
7.1.2 详细成本估算
l 制定资源计划，进行资源分配
“超市结算系统”项目的资源数据库
资源名称
标准工资率（元/小时）
加班工资率（元/每小时）
项目经理
50.00
60.00
商业分析员
40.00
50.00
数据库分析员
40.00
50.00
技术人员
40.00
50.00
“超市结算系统”项目的资源分配
工作任务
资源分配
与项目发起人的启动会议
项目经理[50%],数据库分析员[50%],商业分析员[50%],技术人员[50%]
草拟项目要求
商业分析员,项目经理[50%]
制定项目章程
项目经理
系统定义
项目经理
可行性分析
商业分析员[50%],数据库分析员[50%],技术人员[50%]
编写计划书
项目经理,技术人员[50%]
进行需求调查
商业分析员
撰写需求报告书
商业分析员,项目经理[50%]
研究旧系统
项目经理[50%],技术人员
设计系统模块
数据库分析员,技术人员
模块具体设计
技术人员,数据库分析员
模块间接口设计
技术人员
编码
技术人员
系统测试
项目经理,技术人员
检查各阶段的报告
项目经理
验收系统
项目经理
交付系统相关报告
项目经理
系统维护
技术人员
l 确定每项活动的成本：
工作任务
成本
与项目发起人的启动会议
￥392.00
草拟项目要求
￥520.00
制定项目章程
￥400.00
签署合同
￥0.00
系统定义
￥400.00
可行性分析
￥320.00
编写计划书
￥560.00
进行需求调查
￥320.00
撰写需求报告书
￥0.00
研究旧系统
￥1,800.00
设计系统模块
￥2,560.00
模块具体设计
￥3,200.00
模块间接口设计
￥1,600.00
编码
￥1,280.00
系统测试
￥3,600.00
检查各阶段的报告
￥0.00
验收系统
￥800.00
交付系统相关报告
￥800.00
系统维护
￥3,200.00
l 确定项目总成本：项目总成本为￥21,752.00
7.2 成本预算
7.3 项目详细成本计划
资源分配
项目成本计划
7.4 挣值分析
7.4.1 输入实际数据
在实际进度中，项目已经实施完成了编制任务计划阶段，而接下来的任务便是执行任务。下图为输入项目实际进度与成本信息时的甘特图
7.4.2 得到跟踪甘特图
7.4.3 进行挣值分析
全部盈余分析如下图所示
7.4.4 后续应对措施：
通过7.4.2中的跟踪甘特图以及7.3项目详细成本的比较得出，项目的整个进展过程相对较有序，并且在严格按照WBS中的计划在执行，但是，我认为，在后期的工作中可以对于项目的进度进行调整，可以一最好的效率完成此次项目。
7.5 最佳管理实践
在项目的实施过程中要注意项目进度的管理，一个项目的实施进度最先影响到项目的成本，所以，在一个项目小组中，各个人员要懂得配合以及团结，以整个项目的进展为前提展开项目的实施，才能高效率高质量的完成项目。
8、 项目质量管理计划
8.1、质量目标
（1）产品的质量标准
a) 满足客户的需求;
b) 能在有系统故障或者、数据输入无效或操作等意外环境下，系统能做出适当的响应；
c) 有足够的计算机资源来完成预定的功能；
d) 能够有效的控制未经授权的人使用软件或者数据；
e) 能使用户较轻松的理解和使用该系统；
f) 在一定程度上能够诊断和改正错误；
g) 能够修改或改正在运行的系统需要的工作量；
h) 可测试；
i) 能被其他相关的程序再次使用；
j) 较同类产品相比价格低廉、系统稳定；
k) 按时完成系统并及时维护升级。
（2）项目质量标准
a) 按时完成任务并提交相关文档；
b) 符合开发企业的行业技术标准；
c) 项目具有良好的保密性；
d) 有良好的技术性能。
8.2、质量策略
l 选择合适的开发技术；
l 做好项目开发人员的培训；
l 做好用户的使用培训；
l 向用户灌输质量观点；
l 在项目进行的过程中进行过程规划等一系列的活动；
l 确定相关的质量标准。
8.3、质量保证活动
l 在产品的开发设计阶段，采取措施减少由于设计原因为产生的质量隐患；
l 在管理过程中不断对产品的质量进行多方面的检测，并及时作出反馈；
l 跟踪问题的解决情况；
l 收集新方法，提供过程改进的依据；
l 在产品制成后进行检测。
8.4、质量控制活动
A. 技术评审：评审的对象包括软件需求规格说明书、软件设计方案、测试计划、用户手册、维护手册、系统开发过程、产品发布说明等；
B. 代码走查：以此检测其他此时方法无法检测到的错误；
C. 代码会审：由一组人通过阅读、讨论和争议对程序进行静态分析；
D. 软件测试；
E. 缺陷追踪。
8.5、质量保证的报告途径
l 做书面的产品设计和产品开发的报告，并通过小组会议进行评审；
l 管理过程中定时进行检测，并及时以书面或者口头方式向项目经理做汇报；
l 项目经理对于已经检测到的错误进行监督和跟踪，并做好记录；
l 对于改进的过程，进行小组的评审，评审通过后以书面形式对新技术以及改进的过程做出书面报告，递交至上级；
l 产品制成，进行测试，对于测试的结果以书面形式进行汇报。
8.6、记录的收集、维护和保存
项目经理负责对各类报告以及各项评审的内容、过程及结果进行收集和保存。
8.7、最佳管理实践
有效提高交付成果的质量则需要：
l 通过强有力的领导，从上至下贯彻质量观念；
l 建立组织项目管理体系；
l 建立项目级的激励制度，并设法和鼓励全员参与管理；
l 着力提高项目实施过程中产生的各种文档的质量；
l 用规范的程度度模型来指导自身的组织和体系结构建设；
l 掌控好质量与成本的关系，在有限的成本下尽量通过良好的管理来实现更高的质量；
l 形成质量改进的习惯，真正发挥质量改进的作用。
9、 项目人力资源管理计划
9.1责任分配矩阵RAM

系统工程
需求分析
系统开发
测试工程
结束验收
2.1
R

P

2.2
R P

2.3
R P

2.4
R P

R P

R P

R P

R P

R P

R P

R P

R P

R P

4.3

R P

5.1

R P

5.2

R P

R P

R P
6.2

R P
图9-1 责任分配矩阵
上图为责任分配矩阵，R表示责任组织部门，P代表执行组织部门。把WBS活动工作分配到组织的单位部门中。
在主要的分配过程中，按照部门的职能划分相应的责任和执行的责任，例如在WBS中的5.1系统测试，此次活动的责任组织部门和执行组织部门都是测试工程，是按照部门的功能确定的。
9.2人力资源管理
9.2.1创建资源日历
创建资源日历，输入事件的名称、开始时间和结束时间，在事件的名称下面输入愚人节，把时间设置为四月一日开始，并在四月一日结束。
9.2.2分析资源使用情况
在视图的资源使用状况中查看资源的使用状况，本项目没有出现过度使用资源的状况，在资源的分配上比较合理的平衡资源。
9.2.3资源平衡
如出现资源的过度使用可以通过视图-工具栏-资源管理操作，会出现资源管理工具，此时会弹出资源分配视图查看。
9.3项目人员计划
在资源管理的调配中可以在工具—资源调配的方法进行资源的分配。
9.4最佳管理实践
最佳管理实践也可以通过资源分配的方法来选出最适合工作的地方，在课本中最佳实践中公司通过其雇员的意见来制作最佳雇主的排行榜。
10、 项目沟通管理计划
项目沟通管理计划是对于项目全过程的沟通工作，沟通方法、沟通渠道等各个方面的计划与安排。
10.1项目进程中的信息类型
文本信息：项目章程、合同、计划书、需求报告书、阶段测试报告、系统的相关报告等。
实时信息：项目各阶段的实施情况、进程中出现的问题、任务的完成情况、项目干系人与项目团队的沟通情况、成本与时间的进行情况等等。
10.2项目信息实时查询和管理方法
10.2.1信息查询方式
通过电子邮件、询问项目经理或项目组成员、QQ、电话、微信等实时聊天工具进行查询。
10.2.2信息更新和发布方式
通过召开全体会议、电子邮件、群通话、电话通话进行信息的更新和发布。
10.3项目组成员的沟通方式
正式沟通：通过召开会议、发送电子邮件的方式进行正式沟通。
非正式沟通：通过面对面、电子邮件、电话、第三方转达或QQ、微信等实时聊天工具进行沟通、。
10.4项目交流会议计划
召开项目的周例会，在每周五的下午四点到六点，讨论本周的项目进行情况、问题处理情况、成本与时间的花费情况，下周工作安排与重大信息的发布，记录会议中的问题解决方法。
10.5问题报告制度
项目发起人
项目经理
高层领导
开发小组

问题报告由开发小组向上逐级上报，如在上一层解决反馈回来，则终止上报。问题的反馈也是逐级反馈的。
10.6项目报告制度
项目报告制度由项目组向项目经理与高层管理人员报告。主要是通过会议进行项目的报告。
项目发起人
项目经理
高层领导
开发小组

10.7最佳管理实践
阿拉斯加航空公司使用基维百科后促进了项目沟通与合作。基维百科给项目管理带来的益处包括，更优质的文件，提高了信任度和文件共享度，持续增长的信息和链接。
11、项目风险管理计划
11.1 识别计划
序号
风险识别
风险评估
风险应对措施
潜在的风险事件
风险发生的后果
可能性
严重性
风险值
风险等级
应对措施
预防措施
1
需求不明确
客户不接受产品或拒绝付款
0.5
9
5.4
300
派遣经验丰富的需求分析师与客户进行深入的交流，明确客户的主要需求，引导客户对项目做出正确的描述。
事先进行需求评审
2
项目范围定义不明确
项目没完没了
0.8
9
7.2
360
要求需求小组按照客户的要求变更项目范围。
需求要在事先定义清楚并获得客户的确认。
3
项目目标不明确
导致项目进度拖期或成本超支。
0.6
8
4.8
240
修改项目目标。
事先明确项目目标
4
与客户沟通不够
软件不能满足客户需求
0.5
9
4.5
270
立即与客户进行沟通
制定沟通管理计划
5
需求小组对客户业务了解不够
软件不能实现业务功能
0.6
9
5.4
270
修改软件
加强与了解并让客户参与
6
需求小组没有真正理解客户需求
软件不能萍踪客户需求
0.8
10
8
560
根据客户需求修改
让客户确认需求报告
7
需求分析报告没有得到客户的确认
客户拒绝签字、验收
0.5
10
5
250
取消项目或修改项目
事先获得客户确认
8
需求不断变化
项目变得没完没了
0.8
9
7.2
360
提交CCB讨论、决定
建立范围变更程序
9
缺乏有效的需求变化管理过程
项目不能按时、按预算完成
0.5
8
4
160
对需求变化进行评审
建立需求变更程序
10
任务定义不够充分
项目不能按时、按预算完成
0. 6
8
4.8
240
重新定义
事先与客户达成共识
11
缺乏有经验的分析员
分析错误或不可行
0.4
10
4
200
培训或换人
配备有经验的分析员
12
设计偏离客户需求
软件不能萍踪需求，客户拒绝接受
0.5
10
5
250
修改设计
进行设计评审
13
软件功能漏项
客户不满意
0.4
8
3.2
160
增加相应的功能
进行设计评审、获得客户确认
14
程序员对系统设计的理解上出现偏差
软件实现不了设计的功能，客户拒绝接受
0.6
9
5.4
108
修改代码
进行设计评审
15
程序员开发能力差
项目进度拖期
0.4
9
3.6
160
培训或换人
配备精兵强将
16
程序员不熟悉开发工具
项目进度拖期、质量问题
0.3
8
2.4
96
立即改进
提前准备
17
设计错误导致编码实现困难
质量问题
0.4
10
4
200
修改设计
编码之前进行设计评审
18
客户要求增加功能
项目进度拖期、成本超支
0.8
7
5.6
280
修改程序
事先确定范围目标
19
项目将会时间提前
质量问题
0.4
8
3.2
160
加班加点或增加资源
合同固定交付时间
20
程序员离开
项目执行不下去
0.5
10
5
200
临时替补人
与相关人员签订合同
21
开发团队内部沟通不够
接口混乱、质量问题
0.5
8
4
164
修改程序
制定内部沟通计划
22
没有切实可行的测试计划
项目拖期、质量问题发现不了
0.2
9
1.8
90
修改测试计划
事先评审测试计划
23
测试人员不能按时到位
项目进度拖期
0.2
7
1.4
42
临时安排测试人员
制定出人力资源计划
24
测试人员经验不够
程序问题发现不了
0.4
6
2.4
72
培训或换人
选择有经验的人员
25
测试设备故障
项目拖期
0.3
8
2.4
96
修理或换设备
加强设备预防性维修
26
测试期间出现重大问题
客户拒绝接受产品
0.4
10
4
200
修改程序
分步测试
27
没有有效的备份方案
数据丢失无法挽救
0.4
9
3.6
106
重新开始
异地双重备份
28
测试发现的问题迟迟解决不了
项目进度拖期
0.3
9
2.7
135
加快解决
专家会诊解决
29
设备不能按时到位
项目进度拖期
0.3
8
2.4
92
催设备供应商
提前采购或合同约束
30
运行时质量问题多
客户投诉
0.6
8
4.8
172
即时解决问题
事先进行局部运行
31
客户突然要求增加功能
项目进度拖期、成本超支
0.7
8
5.6
280
作出相应修改
事先确定项目范围和功能要求
32
重要的记录、文件、数据丢失
客户投诉、要求赔偿
0.3
9
2.7
135
重新生成数据
做好备份
33
系统崩溃
客户要求承担损失
0.2
10
2
60
加紧修复
事先备份
34
出现故障，用户维护人员解决不了
客户投诉
0.8
8
6.4
512
派技术人员帮助解决
事先培训客户系统维护人员
35
用户手册错误多
客户投诉
0.3
6
1.8
72
修改错误
专人检查
36
培训手册没有按时准备好
客户投诉，培训不能按时进行
0.3
5
1.5
45
加班加点准备
提前准备出来
37
培训效果差
客户不满意
0.3
6
1.8
54
重新培训
确定标准、充分准备、把好培训师质量关
11.2 风险级别分析
11.2.1 “概率-影响”矩阵图

风险18
风险2、6、8、34

风险24
风险1、3、4、5、7、9、10、11、12、13、14、15、17、19、20、21、26、30、32

风险23、35、36、37
风险16、22、25、27、28、29、32、33
概率
高
0.8~1.0
中
0.4~0.7
低
0.1~0.3
低 中 高
1~3 4~7 8~10
影响
11.2.2 风险等级

中度风险
低风险
高风险

1.0
0.8
0.6失败的概率
0.4
0.2
0
0.2 0.4 0.