项目管理课程设计

1、学生课程设计报告 课程名称： 项目管理课程设计 题 目： 超市结算系统 年 级：2011级 专 业：信息管理与信息系统 学号： 姓名： 指导教师： 完成地点：管理学院综合实验室 完成日期： 2014年6月1日 20 13 学年至20 14 学年度第 2 学期目录0、导言.11、提出项目.12、选择项目.23、建立项目组织.24、项目立项.55、项目范围管理计划.76、项目时间管理计划.107、项目成本管理计划.178、项目质量管理计划.229、项目人力资源管理计划.2510、项目沟通管理计划.2811、项目风险管理计划.3012、项目采购管理计划.3613、项目配置管理计划.3714、项目集成

2、管理计划.410、导言 超市结算系统的目的是是实现超市结算过程中自动化所需要的一切功能，包括管理货物，支持用户结算，统计货物销售情况等。系统将提供给超市前台，会计以及经理等管理人员使用，进行日常任务，工作的管理，提高工作效率。同时将实现各项功能的完善封装以及建立友好的图形用户界面使得用户能较快的上手使用。1、提出项目1.1 超市结算系统1.2 设计一个小游戏的应用1.3 .开发一个电子商务网站内容超市结算系统小游戏电子商务网站项目如何诞生 为了方便顾客付款，收银员的快速结算，以及加快对退货赠品等事项的处理。附近超市提出了开发一个操作便捷，界面清晰的超市结算系统。运用已学的知识能够做到对网站网页

3、的风格设计较感兴趣项目特征需求较易弄清、涉及的知识面广、具有一定的可操作性规模小，容易实现方向难以明确，对安全性，稳定性要求高生命周期需求分析、系统的方案设计、设计系统、结束设计、维护系统确定游戏类别规模、设计游戏，验证游戏确定使用人群，需求分析，整体设计，网站详细设计，结束设计，安全维护项目阶段1. 需求调查，弄清客户需求2. 根据客户需求，制定几套设计方案3. 用户选择方案，查找需要的资料4. 进行系统设计，并实时修改5. 客户验收系统，做好相关的维护工作1. 查找资料选择小型的容易操作的游戏类别2. 进行游戏的结构设计（包括游戏的计分方法、游戏的模式等）3. 设计游戏4. 试玩游戏，检验

4、游戏的稳定性1. 综合团队的意见，确定网站的方向。2. 进行市场调查，做出需求分析3. 确定网站的整体风格，网页数等4. 分配任务进行详细设计5. 结束设计，进行安全测试，进行网站维护交付的成果可供客户方便使用的超市结算系统一个简单的射击小游戏安全稳定的旅游电子商务网站2、选择项目 提出的三个项目具有一定的相似性，都是运用计算相关的知识进行设计开发的。如何选择项目，采用加权评分的方法进行评分选择。整体分析如下表 备注：1.所有指标的权重之和为1002.分数由1到100表示程度加深指标权重超市结算系统小游戏电子商务网站总体规模20%805075知识运用范围15%703070信息收集量15%503

5、060人员数量10%301035时间成本15%602070资金成本5%201020收获20%603040项目权重得分100%5929.557.5结果显示：开发超市结算系统的项目权重的得分最高，所以选择的项目为超市结算系统。3、建立项目组织3.1项目授权 3.1.1 乙方项目授权书(见附录1) 3.1.2 项目章程 一、项目概述： 1、项目名称：超市结算系统 2、项目背景： 21世纪我国的超市产业飞速发展，其经营模式更为复杂，旧的管理体制已经无法适应超市的发展，这就迫切的需要引进新的管理技术。超市的数据和业务越来越庞大，而计算机就是一种高效的管理系统，这就需要我们把超市的管理与计算机结合起来，从

6、而超市管理系统应运而生。依靠现代化的计算机信息处理技术来管理超市，节省了大量的人力、物力，改善了员工的并且能够快速反映出商品的进、销、存等状况和各种反馈信息分析，使管理人员快速对市场的变化做出相应的决策，加快超市经营管理效率。3、项目目的： 通过网络传递销售信息可以不受距离的限制的优势，我们可以借阅许多的人力和物力，方便管理，由此可以减少不必要的开支，通过超市管理系统提高超市的销售效率，同时提高超市的经济效益。4、 项目主要工作： 系统计划：问题定义和可行性研究，写出项目计划书和可行性研究报告 系统需求分析：分析目标和任务，画出数据流程图，编写数据字典系统总体设计：画出系统结构图，找出所有的系

7、统模块，并开始设计数据库，编写概要设计说明书 系统详细设计：画出基本逻辑结构图，N-S结构流程图，代码设计，用户界面设计，数据输入与显示，控制界面的设计，系统安全控制设计，编写详细设计文档 系统测试：对系统记性全面的测试 系统实施与维护： 系统的实施以及对系统运行后的维护二、项目目标：1、时间目标：本项目要求于_2014_年_3_月_24_日开始，于_2014_年_6_月_1_日结束。项目的结束以正式发布项目结项通知的日期为准。2、可交付成果目标：本项目要求最终交付如下的成果： 2.1 项目应于2014年6月29日前提交_超市结算系统和用户使用说明书_。由_项目经理_负责组织评审，须满足的质量

8、要求为：_系统能在三日内快速完成安装，_用户能在15个工作日内学会使用系统，系统在三个月内能无错的稳定运行_。 2.2. 项目应于2014年6月29日前提交_系统的各项说明书，测试报告_。由_项目经理_负责组织评审，须满足的质量要求为：_系统开发设计过程中的各阶段的文档都有，文档的格式，内容符合规定_。3、 费用目标： 本项目总预算为：￥_25000.00_元整。三、项目管理团队:3.1 项目赞助人： ；3.2 项目经理： ；3.3 项目PMO代表： ；3.4 项目技术负责人：_；四、项目团队成员名单序号姓名所属部门项目工作内容技能要求预计开始日期预计工期（工作日）1项目经理领导项目小组进行项

9、目的所有工作领导、管理能力 2设计部门负责项目的设计项目设计能力3生产部门负责项目的生产项目生产能力4研发部门负责项目的研发系统研发能力3.2 项目组织结构项目设计主管项目研发主管项目生产主管项目经理3.3 项目经理选择 3.3.1项目经理选择：项目项目管理知识应用领域相关知识、标准和规则项目环境知识管理知识和技能人际关系技能等级优秀优秀良好良好优秀总评优秀 3.3.2项目经理能力考评：4、项目立项4.1 项目名称及来源 项目名称：超市结算系统 项目属性：虚拟项目 项目发起人及简介： 武汉中商平价连锁分公司（简称中商平价）是武汉中商集团股份有限公司下属的三大连锁公司之 一，是一家以超市连锁经营

10、为主的商业零售企业。 中商平价成立于2000年，经过近8年的不断发展，目前已发展成为拥有连锁门店30余家，网点遍布湖北武汉、襄樊、荆门、荆州、仙桃、黄石、黄冈、大冶等12地市，年销售达35亿元的大型连锁企业，在华中地区位于前三甲，旗下年销售过亿元的综合型大卖场6个，社区超市和区域公司购物广场24个，总经营总面积达35万余平方米。 武汉中商平价超市连锁有限责任公司（简称中商平价），是大型上市企业武汉中商集团股份有限公司旗下的全资子公司，是主营超市业态的现代化连锁商业企业。位于民族大道的中商平价曙光超市也是武汉中商平价连锁超市中的一家。其重要面对的客户群为周边的学校的学生和居民。因此其产品类型有限

11、。为了方便顾客付款，收银员的快速结算，以及加快对退货赠品等事项的处理。超市管理人员提出了开发一个操作便捷，界面清晰的超市结算系统。4.2、拟定甲方招标书（见附录）4.3、拟定乙方投标书（见附录）1.4、项目合同4.5项目利益相关者分析 利益相关者：曙光超市的管理人员、收银员、顾客，项目团队我们项目组。关键项目利益相关者分析表因素超市的高层管理人员收银员项目团队系统安全性需要良好的系统安全性，保障超市信息的安全。需要仔细的探讨安全性。系统便于灵活运用，不会出现死机、卡机、或商品信息录入错误等根据客户的要求，采取一定的措施，确保系统安全。可能对项目完成的时间，所需的成本有一定的影响系统的总体开发时

12、间过长无法尽快使用，过短对系统的稳定性不放心在软件开发时期，可以用已有的软件暂时代替，所以影响不大需要把握好开发时间，时间越长可能开发的系统效果越好，但成本也会加大系统操作的难易程度操作简便的系统，便于管理者提取信息，制定计划便于操作的系统能过加快结算的速度，提高工作效率简便的操作界面，对开发的要求提高，需要不断完善系统开发的模型选取无影响无影响采用快速原型法，更好的了解客户需求，设计出客户需要的系统选取原有系统作为参照能过减少系统开发的资金投入，便于理解使用便于理解，能尽快的掌握，但可能出现操作失误增加了开发的工作量开发的难度减弱系统成功开发的标准客户的消费信息能够准确的录入，信息统计分类准

13、确，系统稳定便于理解操作，系统稳定达到客户要求，系统安全稳定4.6 确定项目的生命周期将整个项目分为如下几个阶段：阶段简介备注项目启动里程碑1.需求识别识别客户需求系统需求分析报告2.系统定义对系统进行客观完整的描述项目计划里程碑1.可行性研究分析项目实施的条件需求，判定项目能否实现可行性研究报告2.概要设计对系统进行初步设计相应的设计文档3.详细设计对系统进行具体明确的设计详细设计文档项目实施里程碑1.系统实现对系统进行实现完整的超市收银系统2.系统测试测试系统的性能，安全性等方面测试报告用户验收1.系统验收交与客户验收2.系统运维对系统进行维护4.7 最佳管理实践企业团队的管理最终是对人的

14、管理。很多成员除了对物质利益的需求以外，还需要提升自我，实现自我价值。因此团队的管理采用人性化的管理方式，根据不同成员的个性特点分配相应的任务，发挥他们的主观能动性，营造一种积极活跃的团队氛围。5、项目范围管理计划5.1、项目章程：超市结算系统项目章程项目名称: 超市结算系统授权时间：2014年3月24日项目开始日期：2014年3月24日 项目结束日期：2014年6月1日关键进度里程碑：l 3月31日完成需求调查，结束需求报告的撰写l 4月13日完成总体设计，提交总体设计报告l 5月11日系统设计完成l 5月18日完成系统安装预算：系统开发所需硬件和软件主要采用已有版本，项目的主要成本为人工成

15、本，该项目预算为2000元。项目经理：项目目标：基于客户需求，在6月1日前完成系统设计，并能安全稳定的替代旧的系统。方式：l 针对系统服务对象，进行信息收集l 集体探讨项目的整体架构l 将系统测试贯穿到系统整体开发过程中角色及责任姓名 角色 职位 联系方式 发起人 经理 项目经理 经理 项目组成人员 PMO代表 项目组成人员 设计总监 项目组成人员 工程师 签署人：（上述全部利益相关者签名）意见（由上述利益相关者手写或打印）“我希望大家能够积极的工作，在规定的时间内高效率的完成整个项目” 项目经理“我希望大家合作愉快” PMO代表 工作分解结构WBS6、 项目时间管理计划 6.1项目进度计划

16、6.1.1项目活动的依赖关系 在甘特图中，确定各个子项目的依赖关系，由前置任务可以看出，在项目过程中，基本按照项目的流程进行，如图所示： 图一6.1.2活动历时 活动从2014年3月24日开始，2014年6月1日结束。总历时50个工作日。 其中启动项目3个工作日、编制项目计划3个工作日、执行任务23个工作日、控制任务5个工作日、结束任务15个工作日。6.1.3前导式网络图 图二 图三6.1.4确定关键路径和时差 由甘特图所示，确定的关键路径如图 图四根据甘特图上各个子任务的状态，确定最早开始时间和最晚开始时间，由于项目主要是按照项目分解的流程工作，所以项目的自由时差和总是差相对较少，下图为EX

17、CL表截图： 图五6.1.5确定里程碑 3月31日完成需求调查，结束需求报告的撰写4月13日完成总体设计，提交总体设计报告5月11日系统设计完成5月18日完成系统安装6.2详细项目进度计划对于项目的详细进度，主要包括各个子任务的工作时间、总工程历时和里程碑任务的提交时间，如图所示 图六 PDM图： 图七 图八 显示关键路径： 图九时差： 图十6.2最佳管理实践 利用软件开展项目的时间管理，协助沟通的软件能够帮助项目经理同项目的利益相关者交换与进度有关的消息，决策支持模型能够帮助项目经理分析权衡各种进度方案。3、项目工作分解结构（WBS）1、 项目启动2、 启动任务 2.1与项目发起人的启动会议

18、 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

19、.00元。7.1.2 详细成本估算l 制定资源计划，进行资源分配“超市结算系统”项目的资源数据库资源名称标准工资率（元/小时）加班工资率（元/每小时）项目经理50.0060.00商业分析员40.0050.00数据库分析员40.0050.00技术人员40.0050.00“超市结算系统”项目的资源分配工作任务资源分配与项目发起人的启动会议项目经理50%,数据库分析员50%,商业分析员50%,技术人员50%草拟项目要求商业分析员,项目经理50%制定项目章程项目经理系统定义项目经理可行性分析商业分析员50%,数据库分析员50%,技术人员50%编写计划书项目经理,技术人员50%进行需求调查商业分析员撰写

20、需求报告书商业分析员,项目经理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模

21、块具体设计￥3,200.00模块间接口设计￥1,600.00编码￥1,280.00系统测试￥3,600.00检查各阶段的报告￥0.00验收系统￥800.00交付系统相关报告￥800.00系统维护￥3,200.00l 确定项目总成本：项目总成本为￥21,752.007.2 成本预算7.3 项目详细成本计划资源分配项目成本计划7.4 挣值分析7.4.1 输入实际数据在实际进度中，项目已经实施完成了编制任务计划阶段，而接下来的任务便是执行任务。下图为输入项目实际进度与成本信息时的甘特图7.4.2 得到跟踪甘特图7.4.3 进行挣值分析全部盈余分析如下图所示7.4.4 后续应对措施：通过7.4.2中的

22、跟踪甘特图以及7.3项目详细成本的比较得出，项目的整个进展过程相对较有序，并且在严格按照WBS中的计划在执行，但是，我认为，在后期的工作中可以对于项目的进度进行调整，可以一最好的效率完成此次项目。7.5 最佳管理实践在项目的实施过程中要注意项目进度的管理，一个项目的实施进度最先影响到项目的成本，所以，在一个项目小组中，各个人员要懂得配合以及团结，以整个项目的进展为前提展开项目的实施，才能高效率高质量的完成项目。8、 项目质量管理计划8.1、质量目标（1）产品的质量标准a) 满足客户的需求;b) 能在有系统故障或者、数据输入无效或操作等意外环境下，系统能做出适当的响应；c) 有足够的计算机资源来

23、完成预定的功能；d) 能够有效的控制未经授权的人使用软件或者数据；e) 能使用户较轻松的理解和使用该系统；f) 在一定程度上能够诊断和改正错误；g) 能够修改或改正在运行的系统需要的工作量；h) 可测试；i) 能被其他相关的程序再次使用；j) 较同类产品相比价格低廉、系统稳定；k) 按时完成系统并及时维护升级。（2）项目质量标准a) 按时完成任务并提交相关文档；b) 符合开发企业的行业技术标准；c) 项目具有良好的保密性；d) 有良好的技术性能。8.2、质量策略l 选择合适的开发技术；l 做好项目开发人员的培训；l 做好用户的使用培训；l 向用户灌输质量观点；l 在项目进行的过程中进行过程规划

24、等一系列的活动；l 确定相关的质量标准。8.3、质量保证活动l 在产品的开发设计阶段，采取措施减少由于设计原因为产生的质量隐患；l 在管理过程中不断对产品的质量进行多方面的检测，并及时作出反馈；l 跟踪问题的解决情况；l 收集新方法，提供过程改进的依据；l 在产品制成后进行检测。8.4、质量控制活动A. 技术评审：评审的对象包括软件需求规格说明书、软件设计方案、测试计划、用户手册、维护手册、系统开发过程、产品发布说明等；B. 代码走查：以此检测其他此时方法无法检测到的错误；C. 代码会审：由一组人通过阅读、讨论和争议对程序进行静态分析；D. 软件测试；E. 缺陷追踪。8.5、质量保证的报告途径

25、l 做书面的产品设计和产品开发的报告，并通过小组会议进行评审；l 管理过程中定时进行检测，并及时以书面或者口头方式向项目经理做汇报；l 项目经理对于已经检测到的错误进行监督和跟踪，并做好记录；l 对于改进的过程，进行小组的评审，评审通过后以书面形式对新技术以及改进的过程做出书面报告，递交至上级；l 产品制成，进行测试，对于测试的结果以书面形式进行汇报。8.6、记录的收集、维护和保存项目经理负责对各类报告以及各项评审的内容、过程及结果进行收集和保存。8.7、最佳管理实践有效提高交付成果的质量则需要：l 通过强有力的领导，从上至下贯彻质量观念；l 建立组织项目管理体系；l 建立项目级的激励制度，并

26、设法和鼓励全员参与管理；l 着力提高项目实施过程中产生的各种文档的质量；l 用规范的程度度模型来指导自身的组织和体系结构建设；l 掌控好质量与成本的关系，在有限的成本下尽量通过良好的管理来实现更高的质量；l 形成质量改进的习惯，真正发挥质量改进的作用。9、 项目人力资源管理计划 9.1责任分配矩阵RAM系统工程需求分析系统开发测试工程结束验收2.1RP2.2R P2.3R P2.4R P3.1.1R P3.1.2R P3.1.3R P3.2.1R P3.2.2R P4.1.1R P4.1.2R P4.2.1R P4.2.2R P4.3R P5.1R P5.2R P6.1.1R P6.1.2R

27、P6.2R P图9-1 责任分配矩阵 上图为责任分配矩阵，R表示责任组织部门，P代表执行组织部门。把WBS活动工作分配到组织的单位部门中。 在主要的分配过程中，按照部门的职能划分相应的责任和执行的责任，例如在WBS中的5.1系统测试，此次活动的责任组织部门和执行组织部门都是测试工程，是按照部门的功能确定的。 9.2人力资源管理 9.2.1创建资源日历 创建资源日历，输入事件的名称、开始时间和结束时间，在事件的名称下面输入愚人节，把时间设置为四月一日开始，并在四月一日结束。 9.2.2分析资源使用情况 在视图的资源使用状况中查看资源的使用状况，本项目没有出现过度使用资源的状况，在资源的分配上比较

28、合理的平衡资源。 9.2.3资源平衡 如出现资源的过度使用可以通过视图-工具栏-资源管理操作，会出现资源管理工具，此时会弹出资源分配视图查看。 9.3项目人员计划 在资源管理的调配中可以在工具资源调配的方法进行资源的分配。 9.4最佳管理实践 最佳管理实践也可以通过资源分配的方法来选出最适合工作的地方，在课本中最佳实践中公司通过其雇员的意见来制作最佳雇主的排行榜。10、 项目沟通管理计划 项目沟通管理计划是对于项目全过程的沟通工作，沟通方法、沟通渠道等各个方面的计划与安排。 10.1项目进程中的信息类型文本信息：项目章程、合同、计划书、需求报告书、阶段测试报告、系统的相关报告等。实时信息：项目

29、各阶段的实施情况、进程中出现的问题、任务的完成情况、项目干系人与项目团队的沟通情况、成本与时间的进行情况等等。 10.2项目信息实时查询和管理方法 10.2.1信息查询方式通过电子邮件、询问项目经理或项目组成员、QQ、电话、微信等实时聊天工具进行查询。 10.2.2信息更新和发布方式 通过召开全体会议、电子邮件、群通话、电话通话进行信息的更新和发布。 10.3项目组成员的沟通方式 正式沟通：通过召开会议、发送电子邮件的方式进行正式沟通。 非正式沟通：通过面对面、电子邮件、电话、第三方转达或QQ、微信等实时聊天工具进行沟通、。 10.4项目交流会议计划 召开项目的周例会，在每周五的下午四点到六点

30、，讨论本周的项目进行情况、问题处理情况、成本与时间的花费情况，下周工作安排与重大信息的发布，记录会议中的问题解决方法。 10.5问题报告制度项目发起人项目经理高层领导开发小组 问题报告由开发小组向上逐级上报，如在上一层解决反馈回来，则终止上报。问题的反馈也是逐级反馈的。 10.6项目报告制度 项目报告制度由项目组向项目经理与高层管理人员报告。主要是通过会议进行项目的报告。 项目发起人项目经理高层领导开发小组 10.7最佳管理实践 阿拉斯加航空公司使用基维百科后促进了项目沟通与合作。基维百科给项目管理带来的益处包括，更优质的文件，提高了信任度和文件共享度，持续增长的信息和链接。11、项目风险管理

31、计划 11.1 识别计划序号风险识别风险评估风险应对措施潜在的风险事件风险发生的后果可能性严重性风险值风险等级应对措施预防措施1需求不明确客户不接受产品或拒绝付款0.595.4300派遣经验丰富的需求分析师与客户进行深入的交流，明确客户的主要需求，引导客户对项目做出正确的描述。事先进行需求评审2项目范围定义不明确项目没完没了0.897.2360要求需求小组按照客户的要求变更项目范围。需求要在事先定义清楚并获得客户的确认。3项目目标不明确导致项目进度拖期或成本超支。0.684.8240修改项目目标。事先明确项目目标4与客户沟通不够软件不能满足客户需求0.594.5270立即与客户进行沟通制定沟通

32、管理计划5需求小组对客户业务了解不够软件不能实现业务功能0.695.4270修改软件加强与了解并让客户参与6需求小组没有真正理解客户需求软件不能萍踪客户需求0.8108560根据客户需求修改让客户确认需求报告7需求分析报告没有得到客户的确认客户拒绝签字、验收0.5105250取消项目或修改项目事先获得客户确认8需求不断变化项目变得没完没了0.897.2360提交CCB讨论、决定建立范围变更程序9缺乏有效的需求变化管理过程项目不能按时、按预算完成0.584160对需求变化进行评审建立需求变更程序10任务定义不够充分项目不能按时、按预算完成 0.684.8240重新定义事先与客户达成共识11缺乏有

33、经验的分析员分析错误或不可行0.4104200培训或换人配备有经验的分析员12设计偏离客户需求软件不能萍踪需求，客户拒绝接受0.5105250修改设计进行设计评审13软件功能漏项客户不满意0.483.2160增加相应的功能进行设计评审、获得客户确认14程序员对系统设计的理解上出现偏差软件实现不了设计的功能，客户拒绝接受0.695.4108修改代码进行设计评审15程序员开发能力差项目进度拖期0.493.6160培训或换人配备精兵强将16程序员不熟悉开发工具项目进度拖期、质量问题0.382.496立即改进提前准备17设计错误导致编码实现困难质量问题0.4104200修改设计编码之前进行设计评审18

34、客户要求增加功能项目进度拖期、成本超支0.875.6280修改程序事先确定范围目标19项目将会时间提前质量问题0.483.2160加班加点或增加资源合同固定交付时间20程序员离开项目执行不下去0.5105200临时替补人与相关人员签订合同21开发团队内部沟通不够接口混乱、质量问题0.584164修改程序制定内部沟通计划22没有切实可行的测试计划项目拖期、质量问题发现不了0.291.890修改测试计划事先评审测试计划23测试人员不能按时到位项目进度拖期0.271.442临时安排测试人员制定出人力资源计划24测试人员经验不够程序问题发现不了0.462.472培训或换人选择有经验的人员25测试设备故

35、障项目拖期0.382.496修理或换设备加强设备预防性维修26测试期间出现重大问题客户拒绝接受产品0.4104200修改程序分步测试27没有有效的备份方案数据丢失无法挽救0.493.6106重新开始异地双重备份28测试发现的问题迟迟解决不了项目进度拖期0.392.7135加快解决专家会诊解决29设备不能按时到位项目进度拖期0.382.492催设备供应商提前采购或合同约束30运行时质量问题多客户投诉0.684.8172即时解决问题事先进行局部运行31客户突然要求增加功能项目进度拖期、成本超支0.785.6280作出相应修改事先确定项目范围和功能要求32重要的记录、文件、数据丢失客户投诉、要求赔偿

36、0.392.7135重新生成数据做好备份33系统崩溃客户要求承担损失0.210260加紧修复事先备份34出现故障，用户维护人员解决不了客户投诉0.886.4512派技术人员帮助解决事先培训客户系统维护人员35用户手册错误多客户投诉0.361.872修改错误专人检查36培训手册没有按时准备好客户投诉，培训不能按时进行0.351.545加班加点准备提前准备出来37培训效果差客户不满意0.361.854重新培训确定标准、充分准备、把好培训师质量关11.2 风险级别分析 11.2.1 “概率-影响”矩阵图风险18风险2、6、8、34风险24风险1、3、4、5、7、9、10、11、12、13、14、15

37、、17、19、20、21、26、30、32风险23、35、36、37风险16、22、25、27、28、29、32、33概率高0.81.0中0.40.7低0.10.3 低 中 高 13 47 810 影响 11.2.2 风险等级中度风险低风险高风险 1.0 0.8 0.6失败的概率 0.4 0.2 0 0.2 0.4 0.6 0.8 1.0 失败的后果11.3 TOP10风险清单排序风险序号风险事件可能性影响程度风险值风险级别风险应归措施16需求小组没有真正理解客户需求0.8108560要求需求小组按照客户的要求变更项目范围。22项目范围定义不明确0.897.2360需求要在事先定义清楚并获得客

38、户的确认。38需求不断变化0.897.2369提交CCB讨论、决定434出现故障，用户维护人员解决不了0.886.4512要求需求小组按照客户的要求变更项目范围。518客户要求增加功能0.875.6280修改程序631客户突然要求增加功能0.785.6280作出相应修改714程序员对系统设计的理解上出现偏差0.695.4108修改代码85需求小组对客户业务了解不够0.695.4270修改软件910任务定义不够充分0.684.8240重新定义103项目目标不明确0.684.8240修改项目目标11.4最佳管理实践 1、人力资源风险的应对措施 （1）和有关资源部门充分沟通，达成共识，建立人员的稳定

39、和释放机制，在开发周期内保持人员的相对稳定，资源线调动资源需要和产品部协调，并将此作为产品线考核资源线的一个指标。 （2）针对人员缺乏经验，需要进行系列的培训组织，保证项目开发人员及时了解产品知识。工作交接规范化，保证产品开发不会因为人员变动受到大的冲击。 （3）对项目组进行良好组织，使得每一个开发活动的信息能被广泛传播和交流。 （4）对所有工作进行详细复审，避免只有一个人熟悉该项工作情况出现。 （5）对于每一个关键技术岗位都指定一个后备人员2、对于需求变动的缓解措施 （1）在进行需求分析时和市场人员甚至用户进行充分沟通。 （2）定出基线进行详细评审。 （3）周知版本计划，并用市场销售指导书指

40、导市场人员签单时注意公司产品的规格，引导用户 （4）严格控制需求的变更，建立需求变更控制机制 （5）及时调整计划；并周知所有项目有关人员 3、对于技术因素的缓解措施 （1）使用模块化、层次化开发模式，尽量降低系统复杂性 （2）加强评审4、 进度风险的缓解措施（1）强化周报，月报，例会等措施 （2）定期（如月）更新日程表 5、 商业风险的缓解措施 （1）重点关注关键路径 （2）客户定期，充分沟通12、项目采购管理计划 由于项目所需的工具都具有，所以为做采购计划。13、项目配置管理计划13.1导言 13.1.1目的 本计划的目的在于对所开发的超市进销存软件规定各种必要的配置管理条款，以保证所交付的

41、超市进销存软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 13.1.2定义本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。13.2组织及职责 13.2.1 要求：在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。 13.2.2 分工

42、及其职责（1） 组长： 总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责； 负责监督在软件配置管理工作中认真执行软件工程规范；（2）项目的专职配置管理人员： 检查在作配置更改时的质量保证措施； （3）各子系统的配置管理人员 具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查； （4）用户代表： 负责反映用户对配置管理的要求，并协助检查各类人员对软件配置管理计划的执行情况； （5）项目专职的配置管理人员： 协助组长开展各项软件配置管理活动，负责审查所采用的配置管理工具、技术和方法，并负责汇总、维护和保存有关软件配置管理活动的各项记录。1

43、3.3配置管理环境遵守如下标准、条例和约定：A 软件开发库、软件受控库与软件产品库的操作规程与管理规程；B 系统、子系统、模块和程序单元的命名约定；C 文档和测试用例的命名和管理规程。 这引起命名约定、操作规程与管理规程应由CADCSC项目技术组负责制订，并应认真听取各子系统项目负责人的意见，最后报项目总体组审批。在执行过程中，如果发现某些条款需要修改，则必须办理正规的审批手续，最后要经项目总体组批准。13.4配置管理活动1、 配置标识（1）文档所有为本项目编制的文档，都要符合规定。超市进销存软件系统及其所属的各个子系统所编写的文档数目，可根规定作适当的剪裁。剪裁方案由技术组提出建议，报总体组

44、批准。（2） 程序所有属于本项目的程序、分程序、模块和程序单元，都要按照由项目技术组制订，且经总体组批准的软件系统的命名约定的规定来标识。（3） 各类基线所有属于本项目及其各子系统的各类基线，首先要按照任务书、软件需求规格说明书的规定确定其技术内容，然后按照软件系统的上述命名约定的规定来标识。2、配置控制软件配置的更改管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。配置控制的要点如下：A 修改批准权限；对本项目各个子系统及其专用支持软件的功能基线、指派基线、产品基线及其集成系统的任何修改（称为A类修改），都必须通过项目配置管理小组讨论，并必须经总体组批准；对本项目各个子系统及其专用支持软件的其他阶段产品的任何修改（称为B类修改），都必须通过本项目各个子系统的配置管理人员审查，并经项目的软件配置管理小组与各个子系统负责人的共同批准并报项目总体组备案。 B 修改审批程序：上述两类修改的审批程序如表1。C 修改控制工具：修改控制工具是协助