科达公司ERP软件开发的需求风险及其管理

题 目： 科达公司ERP软件开发的需求风险及其管理 学 院： 商学院 专 业： 项目管理 姓 名： 张芳宁 指导教师： 郭燕青 教授 完成日期： 2014年4月28日 毕业论文任务书毕业论文题目：科达公司ERP软件开发需求风险及其管理选题意义、创新性、科学性和可行性论证：研究项目管理的风险，尤其是研究软件项目的变更需求风险十分有助于软件项目最后的成功。选题也正是出于对于软件项目风险管理的重视，希望借题通过案例来重申软件项目风险，特别是软件项目变更需求的风险来强调其意义，并给出自己的见解。主要内容： 本文主要由四部分组成。第一部分主要介绍该论文的写作意义及目的。第二部分介绍本文研究的背景。第三部分的主要介绍了本文引用的分析方法以及调研的分析过程。在第四部分给出笔者在对该项目调查后对于软件项目风险管理的意见。最后，在第五部分将给出总结概述。目的要求： 通过论文的写作，主要目的是将风险管理的理论知识以及一些相关分析方法，灵活运用到实际问题的分析过程中，培养理论联系实际,并能够在实践中发现问题、分析问题、解决问题的能力；本文以无锡科达仪器有限公司为例，进行分析研究，通过坐标评估和风险控制给出对于风险管理的某些认识。论文写作要求理论联系实际，有针对性的提出解决问题的建议。计 划 进 度 ：完成毕业论文，具体时间如下：1.2013.12.31-2014.1.16 收集资料，确定论文选题，完成论文任务书；2. 2014.1.17-2014.3.1 修改论文提纲；3. 2014.3.2-2014.3.31 修改论文初稿；4. 2014.4.1-2014.4.20 进一步修改论文修改稿； 5. 2014.4.20-2014.4.28 论文定稿。 指 导 教 师 签 字： 主管院长（系主任）签字： 年 月 日辽 宁 大 学本科毕业论文（设计）指导记录表论文题目科达公司ERP软件开发的需求风险及其管理学生姓名张芳宁学 号100610112年级、专业2010级项目管理指导教师姓名郭燕青指导教师职称教授所在院系商学院第一次指导（对确定题目、毕业论文（设计）任务书的指导意见）：对论文写作进行讲解：1、如何进行论文选题首先搜集资料，然后进行论选题，确定论文题目；2、如何拟定大纲大纲主要包括三方面：提出问题、分析问题、解决问题；3、如何填写论文任务书选题确定下来后，完成大纲，明确写作目的及内容后再完成任务书填写。指导方式：（请选择） 面谈 电话 电子邮件 指导教师签字： 2013年 12 月 20 日第二次指导（对论文提纲的指导意见）：1、强调论文提纲的三步结构：提出问题、分析问题、解决问题 。2、案例分析要有明确的步骤，要系统化。3、论文标题添加确切企业名称。指导方式：（请选择） 面谈 电话 电子邮件 指导教师签字： 2014年 2 月 13 日第三次指导（对初稿的指导意见）：1、 论文逻辑上要有一定的套路。2、 内容应用必要的理论与方法进行问题的确定与其原因分析，然后找出对策。3、 同时格式上要符合学校的要求。4、 层次过于复杂化。指导方式：（请选择） 面谈 电话 电子邮件 指导教师签字： 2014年 3 月 31 日第四次指导（对修改稿的指导意见）：1、修改论文第二章节部分内容。2、修改参考文献的格式。3、按辽宁大学论文格式进行排版。指导方式：（请选择） 面谈 电话 电子邮件 指导教师签字： 2014 年4月15日第五次指导（对是否定稿、进入答辩及其它指导意见）：内容基本符合要求，需对论文格式进行最后修改，确保符合学校统一要求，修改后可定稿、打印。指导方式：（请选择） 面谈 电话 电子邮件 指导教师签字： 2014年 4 月 30 日主管院长（主任）签名 院系盖章 年 月 日注：指导意见如不够填写可加附页指导教师评语学 生：张芳宁 专 业：项目管理 论文题目：科达公司ERP软件开发的需求风险及其管理 论文共 19 页，设计图纸 0 张。 指导教师评语：指导教师评分： 指导教师签字： 年 月 日辽宁大学毕业论文（设计）成绩评定单评阅人评语：评阅人评分：评阅人签字： 年 月 日答辩委员会评语：院（系）毕业论文答辩委员会（小组）于 年 月 日审查了 届 专业学生 的毕业论文。答辩委员会评语：答辩成绩：答辩委员会成员：答辩委员会（小组）组长签字： 年 月 日 毕业论文（设计）成绩：评阅人评分：指导教师评分 ：答辩成绩：总成绩：院长（系主任）签字： 年 月 日注：评阅人评分满分为100分，指导教师评分满分为100分，答辩成绩满分为100分；总成绩为三者的算术平均值（四舍五入）。摘 要软件产业的发展是目前发展最快的行业之一，也是对社会影响最大的一个行业，它不但为我们创造了巨大的财富，而且从各个方面改变着我们的生活，大到一个行业，小到一项服务。我们不得不承认软件是二十一世纪最不可思议的产品。目前国内的软件企业不太关心软件项目的风险管理，结果造成软件项目经常性的延期、超过预算，甚至失败。成功的项目管理一般都对项目风险进行了良好的管理。因此任何一个系统开发项目都应将风险管理作为软件项目管理的重要内容。风险管理的好坏在很大程度上决定了软件开发过程中的顺利、成功与否,因此,在软件开发过程中项目风险管理十分重要。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目不能实现。如果对项目进行风险管理，就可以最大限度的减少风险的发生。但是，目前国内的软件企业不太关心软件项目的风险管理，结果造成软件项目经常性的延期、超过预算，甚至失败。软件项目风险管理目的在于探索软件风险的概念、特殊性，风险识别、分析、应对的具体方法和策略，以降低或克服软件风险的危害性，从而提高软件的质量。成功的项目管理一般都对项目风险进行了良好的管理。因此任何一个系统开发项目都应将风险管理作为软件项目管理的重要内容。本文希望通过对捷鼎软件有限公司进行的科达仪器有限公司ERP软件开发项目的调查研究来剖析软件开发过程中的项目风险管理的过程、方法、意义。本文主要由四部分组成。第一部分主要介绍该论文的写作意义及目的。第二部分介绍本文研究的背景。第三部分的主要介绍了本文引用的分析方法以及调研的分析过程。在第四部分给出笔者在对该项目调查后对于软件项目风险管理的意见。最后，在第五部分将给出总结概述。关键词：软件项目管理；ERP软件开发；需求风险；管理对策AbstractThe current development of software industry is one of the fastest growing industries,what is also one of the biggest influence on society. At all aspects, it is an industry, a service that not only creating a huge wealth for us, but also changing our life. We have to admit that the software is the most incredible products in the 21st century.Software project risk will influence the realization of the project plan, if the project risk become reality, it is possible to affect the progress of the project, add to the cost of the project, and even make the software project cannot be implemented. If the project risk management can be done, it will minimize the occurrence of risk. However, the current domestic software enterprises are not so concerned about software project risk management that a software project is often late and over budget, even failure. A software project risk management aims to explore the concept of software risk and particularity, risk identification, analysis, specific methods and strategies to deal with, in order to reduce or overcome the dangers of software risk, so as to improve the quality of software. Successful project management is generally good for project risk management. So any system development project risk management should be used as an important part of the software project management.This article hopes to accoding a project by Jieding how to develop ERP software in Keda,to investigate the project and study to analyze the project risk management about the process of software development process, methods and significance.This paper consists of four parts. The first part mainly introduces the significance and purpose of the paper writing. The second part introduces the research background. The third part mainly introduces the reference, the methods of this paper analyses and the analysis of the research process. In the fourth section the author will pull out some suggestion for software project risk management. Finally, in the fifth part will summarize overview.Key words: soft project of management ; development of ERP; risk of request ; method of managementII目 录摘 要IAbstractII第一章 绪论11.1选题背景11.2选题的目的和意义21.3本文主要内容2第二章 背景介绍32.1 ERP软件开发及其需求风险控制的现状32.2 理论依据42.2.1需求分析42.2.2软件需求内容52.2.3风险管理5第三章 科达公司ERP软件开发的需求风险分析63.1科达公司ERP软件开发项目的风险现状分析63.2捷鼎软件公司对于科达公司ERP开发项目的需求风险管理过程分析73.3科达公司ERP软件开发中存在的主要需求风险103.3.1科达公司的需求将可能不断变更103.3.2科达公司的信息化配合力度不够113.3.3科达公司不能表达自身需求11第四章 科达公司ERP软件开发的需求风险管理对策114.1 建立有效的需求风险控制的组织机构114.2 完善可靠的需求风险控制的管理过程124.3 针对主要风险的具体对策134.3.1进行库存管理134.3.2建立组织保障，明确的责任分工144.3.4建立良好的沟通环境和氛围16第五章 结论16参考文献18致 谢19科达公司ERP软件开发的需求风险及其管理对策第一章 绪论1.1选题背景软件产业的发展是目前发展最快的行业之一，也是对社会影响最大的一个行业，它不但为我们创造了巨大的财富，而且从各个方面改变着我们的生活，大到一个行业，小到一项服务。我们不得不承认软件是二十一世纪最不可思议的产品。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目不能实现。如果对项目进行风险管理，就可以最大限度的减少风险的发生。但是，目前国内的软件企业不太关心软件项目的风险管理，结果造成软件项目经常性的延期、超过预算，甚至失败。软件项目风险管理目的在于探索软件风险的概念、特殊性，风险识别、分析、应对的具体方法和策略，以降低或克服软件风险的危害性，从而提高软件的质量。成功的项目管理一般都对项目风险进行了良好的管理。因此任何一个系统开发项目都应将风险管理作为软件项目管理的重要内容。在项目风险管理中，存在多种风险管理方法与工具，软件项目管理只有找出最适合自己的方法与工具并应用到风险管理中，才能尽量减少软件项目风险，促进项目的成功。目前，风险管理被认为是软件项目中减少失败的一种重要手段。当不能很确定地预测将来事情的时候，可以采用结构化风险管理来发现计划中的缺陷，并且采取行动来减少潜在问题发生的可能性和影响。风险管理意味着危机还没有发生之前就对它进行处理，这就提高了项目成功的机会并减少了不可避免风险所产生的后果。只有进行很好的风险管理才能有效地控制项目的成本、进度、产品需求，同时可以阻止意外的发生。这样，项目经理可以将精力更多地放到项目的及时提交上，不用像救火队员一样，处于被动状态。同时，风险管理可以防止问题的出现，即使出现问题，也可以降低其危害程度。可以说你不跟踪风险，风险就跟踪你。正如Tom Gilb所说，“如果你不主动攻击风险，风险就会主动攻击你”。软件开发项目由于其具有连续性、复杂性、少参照性，无标准规范等特点，其风险程度较高。目前，国内的大多数软件开发企业还缺乏对软件开发项目的风险认识，缺少进行系统、有效的度量和评价的手段。据有调查数据显示，有1535%的软件项目中途被取消，剩下的项目不是超期就是超出预算或是无法达到预期目标。另外，软件项目因风险控制和管理原因失败的约占90% ，可见，软件风险控制与管理在目前的软件开发项目中的重要性。1.2选题的目的和意义软件风险管理在软件项目管理中起着重要的作用。首先,有效的风险管理可以提高项目的成功率。第二,风险管理可以提高团队的协调性。风险分析可以让每个人的团队成员具有良好的估计困难的能力,准备了意想不到的问题,大大提高团队成员的信心,稳定团队。第三,有效的风险管理可以帮助项目经理抓住重点,将主要关注主要风险,将从被动到主动救火工作。在全球软件业高速发展的今天，软件项目的实施情况却不甚理想。据统计，约80%90%信息化投资没有达到预期目标，80的项目超期或超预算，40%的项目以失败告终，只有不足25%的项目达到预期的技术和业务目标。这种局面的出现是与软件项目本身所蕴含的诸多风险密切相关的，如技术风险、管理风险、需求风险等；而能够对需求风险进行有效控制则是决定整个项目成败的关键。研究项目管理的风险，尤其是研究软件项目的变更需求风险十分有助于软件项目最后的成功。选题也正是出于对于软件项目风险管理的重视，希望借题通过案例来重申软件项目风险，特别是软件项目变更需求的风险来强调其意义，并给出自己的见解。1.3本文主要内容本文希望通过软件开发过程中的风险的研究给出自己的看法与解析。本文主要是通过案例分析来结构软件项目风险管理。其中本文通过无锡一家仪器厂的一个项目，突出抓住软件项目需求变更风险而行文的。本文所述的科达公司获得了无锡市工业和信息产业局下达的一笔技术改造无息贷款，要求其专门用于进行企业信息化建设。为此，公司老总责成信息部经理雷某牵头，要求今年必须上马ERP软件。经过一段时间的选型，科达公司最终与一家ERP公司捷鼎软件公司签订了ERP软件的集成开发合同。按照合同要求，最后开发的系统必须将ERP的管理思想融入到系统之中，内容模块要覆盖企业的人财物、产供销、设计、研发、质量、工艺等所有内容，并且要实现与条形码的集成，技术构架上采用C/S模式，网络操作系统采用Windows NT，数据库系统采用SQL Server。捷鼎软件公司在接到项目后，高度重视该项目，立即形成项目小组。项目小组由10人组成，包括一位项目经理和其他技术水平过硬的程序员。项目由ERP软件开发项目组项目经理负责，立即投入软件开发。本文希望通过对捷鼎软件有限公司进行的科达仪器有限公司ERP软件开发项目的调查研究来剖析软件开发过程中的项目风险管理的过程、方法、意义。本文主要由四部分组成。第一部分主要介绍该论文的写作意义及目的。第二部分介绍本文研究的背景。第三部分的主要介绍了本文引用的分析方法以及调研的分析过程。在第四部分给出笔者在对该项目调查后对于软件项目风险管理的意见。最后，在第五部分将给出总结概述。第二章 背景介绍2.1 ERP软件开发及其需求风险控制的现状ERP是建立在信息技术基础上，通过对企业销售、生产、采购、物流等各个环节。以及人力资源、生产设备、资金等企业内部资源的有效控制和管理。实现企业内部资源的优化配置，提高企业生产效率和市场响应能力的管理平台。1993年，Ganner Group定义：ERP是一种基于供应链管理思想的信息化管理系统。企业领导大多重视信息技术对企业的现代化作用，不少大大小小的企业建设了自己的系统，取得了令人满意的效果。但应当注意的是并不是所有的企业都对自己的ERP软件开发效果十分满意。企业开发ERP需要投入大量资金和人力去建设，动辄几十万乃至上百万。而往往最后不能取得应有的效果，有的甚至最终彻底失败，给企业造成重大经济损失，影响了企业的正常经营活动，严重的甚至导致企业倒闭。从20世纪80年代开始到现在。国内有千余家企业建设了MRP/ERP,20年来我国企业在应用MRP/ERP系统方面投入了80亿元人民币，但据信息产业部调查。真正意义上能发挥作用的只占约10%,达到预期目标的更是寥寥无几。如北京市三露厂、哈尔滨医药集团、广州标致汽车公司等公司实施ERP相继宣布失败。国内企业如此。国外企业实施ERP情况又如何呢？国外ERP实施成功率在30%-35%,成功率也不是很理想。着名的DELL公司，在耗时2年投入2亿多美元后。不得不疲惫不堪地宣布停止实施ERP系统；年收入超过50亿美元的美国药品销售龙头企业-福克斯一梅亚公司，从1994年开始实施ERP系统，历时两年半后不仅没有取得任何成效，反而使订单处理能力下降到2.4%,最终仅以8000万美元被收购，这是一个实施ERP更为可怕的结果，而这种结果居然发生了。总之，无论从国内还是国外看，ERP实施的成功率非常低，远远低于期望目标，失败率很高，建设ERP风险是很高的。建设ERP不仅仅意味着高的收益，也伴随着较高的风险性，居高不下的风险性使不少的企业还在持观望态度。而在ERP软件开发的众多风险当中，需求风险往往是策略上的主要风险之一。在全球软件业高速发展的今天，软件项目的实施情况却不甚理想。据统计，约80%90%信息化投资没有达到预期目标，80的项目超期或超预算，40%的项目以失败告终，只有不足25%的项目达到预期的技术和业务目标。这种局面的出现是与软件项目本身所蕴含的诸多风险密切相关的，如技术风险、管理风险、需求风险等；而能够对需求风险进行有效控制则是决定整个项目成败的关键。2.2 理论依据2.2.1需求分析所谓“需求分析”，是指在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。需求分析阶段的任务是确定软件系统功能。在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中越来越多的人认识到它是整个过程中最关键的一个过程。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件实际上不可能达到顾客的需要，或者软件无法在规定的时间里完工。需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。（1）问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。（2）分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。（3）制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题)，向下一阶段提交。(4)评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。2.2.2软件需求内容 (1)客户需求客户需求（需要什么、期望什么、限制什么、外部接口是什麽等）是可以理解成客户为什么要做本系统，要解决什么问题，客户对系统有怎样的期望，希望能具备一些怎样的特点，简单的说，就是客户的需要是什么。一般表现为系统功能、性能、界面等要求；（2)产品需求产品需求是能满足客户需求，并对软件产品规格进行了详细描述的需求，产品派生需求（如法规、习惯性做法、性能需求等），在产品需求的开发时增加上去；软件设计师可以根据产品需求进行设计、编码等工作。（3)产品组件需求产品组件需求，是对产品需求的进一步细化，产品可能会分割成几个子系统、几个部分，每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口及界面要求、数据库等，这些可以认为是产品组件需求。分配需求（为每个产品组件分配需求）依赖于设计（技术解决方案），功能需求是软件实现、还是硬件实现，是分配到产品组件的硬件还是软件，如手机产品拨打电话的功能需求，是通过触摸屏和软体实现，还是通过手机按键（硬件）的方式实现，所以产品组件的需求是依赖与设计（技术解决方案）；有分配产品组件需求就有接口需求（内部和外部接口等），有模块和组件，就有接口与界面、数据库等2.2.3风险管理风险管理应是贯穿软件项目开发始末的一项重要任务，其中包括风险识别、风险评估、风险计划、风险解决和风险监控。它能让风险管理者主动“规避”风险，进行有效的风险管理。风险管理模型有：SEI风险管理模型、Riskit风险管理模型、SoftRisk风险管理模型、IEEE风险管理过程模型、CMMI风险管理模型、MSF风险管理模型等。在项目管理中，建立风险管理策略，在项目的生命周期中不断控制风险是非常重要的，风险管理主要包括五个阶段：(1)风险识别：识别风险的方法常用的有现场观察法、座谈法、流程图法、财务报表法、相关部门配合法和环境分析法等。(2) 风险评估：对已识别的风险要进行估计和评价，风险估计的主要任务是确定风险发生的概率与后果，风险评价则是确定该风险的经济意义及处理的费/效分析，常用的方法有：概率分布、外推法、多目标分析法等。(3) 计划进度：按照评估后的风险结果，制定相应的风险管理进度表，为后续的风险管理提供参考。(4) 风险处理：一般而言，风险处理有三种方法， 风险控制法，即主动采取措施避免风险，消灭风险，中和风险或采用紧急方案降低风险。 风险自留，当风险量不大时可以余留风险。 风险转移。(5) 风险监控：包括对风险发生的监督和对风险管理的监督，前者是对已识别的风险源进行监视和控制，后者是在项目实施过程中监督人们认真执行风险管理的组织和技术措施。第三章 科达公司ERP软件开发的需求风险分析3.1科达公司ERP软件开发项目的风险现状分析科达公司的项目组通过头脑风暴法、德尔菲法进行风险的主观评测，最后还是采取了风险坐标法表法最终确定了最终的风险排序。并将最后的结果通过量化风险条目检查表中的条目来评估风险。图1是根据众多数据根据检查表法综合得出对这个三层结构检查表的量化风险分析结果：其中捷鼎软件公司项目组成员最终决定以需求风险管理进行本次软件开发的风险管理。图1也表现了科达公司ERP软件开发项目的风险现状。图1 风险识别结果3.2捷鼎软件公司对于科达公司ERP开发项目的需求风险管理过程分析（1）需求获取通过与科达公司的领导层、业务层人员的访谈式沟通，对现有系统的观察，以及对开发任务进行分析，从而发现、捕获和修订用户需求，如图2所示。从图2中可以看出，该ERP软件开发项目中存在的诸多需求。主要包含基线需求和扩展需求。其中基线需求包括了对于用户要求基线需求扩展需求软件需求图2 需求获取过程（2）需求确认捷鼎软件公司通过获取到的需求进行系统需求调查与科达ERP软件开发项目小组中的人员科达公司ERP软件开发项目负责人进行沟通，通过沟通来对不一致的需求进行剔除；对于双方达成共同理解或获得用户认可的部分，双方进行承诺。（3）建立需求状态根据表1的需求状态表进行进一步核准。防止科达公司对于软件开发结果的不确定性。表1 需求状态表状态值定 义已建议该需求已被有权提出需求的人建议已批准该需求已被分析，估计了其对项目余下部分的影响，已用一个确定的产品版本号或创建编号分配到相关基线中，软件开发团队已同意实现该需求已实现已实现需求代码的设计、编写和单元测试已验证使用所选择的方法已验证了实现的需求，用例测试和检测，审查该需求跟踪与测试用例相符已删除计划的需求已从基线中删除，但包括一个原因说明和作出决定的人员（4）需求验证需求规格说明书提交之后，捷鼎软件公司开发人员与科达ERP开发项目负责人一起，就需求规格说明书的内容，通过审查、模拟或快速原型等途径，验证需求的正确性和可行性。验证的内容包括：需求的正确性。捷鼎软件公司开发人员和科达公司有关人员进行复查，以确保将该ERP软件开发的需求充分、正确地表达出来。只有用户代表才能确定用户需求的正确性，这就是一定要有用户积极参与的原因。没有用户参与的需求评审，将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是软件需求分析人员或者评审者的凭空猜测。需求的一致性。在软件开发前捷鼎软件公司必须解决所有需求间的不一致部分。验证没有任何冲突和含糊的需求。需求的完整性。捷鼎软件公司验证了是否所有可能的状态、状态变化、转入、产品和约束都在需求中描述；尽量不遗漏任何必要的需求信息。在知道缺少某项信息，捷鼎公司的项目人员会用“待确定”作为标识来标明这项缺漏，并且，在软件正式开发之前，捷鼎软件公司项目人员尽量解决需求中所有的“待确定”项。需求的可行性。验证需求是否实际可行。例如，科达公司提出一个“远程存取速度必须是与本地一样”的要求，那是不可行的。每一项需求都必须是在已知系统和环境的限制范围内可以实施的。为避免不可行的需求，最好在获取需求的过程中，始终有一位软件工程小组的组员与需求分析人员在一起工作，由他来负责检查技术可行性。需求的可检验性。捷鼎项目组需要验证是否能写出测试用例来满足需求；检查一下每项需求是否能通过设计测试用例或其他的验证方法（如用演示、检测等）来确定产品是否确实按需求实现了。对于需求不可验证，项目组则需要确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾、不可行或有二义性的需求也是不可验证的。需求的可跟踪性。捷鼎项目组需要验证需求是否是可跟踪的；是否能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接。这种可跟踪性要求每项需求以一种结构化的、细粒度的方式编写并单独标明，而不是大段大段地叙述。（5）需求承诺在本阶段，捷鼎项目组和科达公司方的责任人，对通过了双方验证和同行评审的系统需求，进行签字并作出承诺。使得该承诺具有商业合同的同等效果。图3是需求承诺事例书。需求承诺无锡市科达仪器有限公司ERP软件开发项目需求文档xxx需求规格说明书，版本号：x. x. x, 是建立在XXX与XXX双方共同对需求理解的基础之上，同意后续的开发工作根据该工作产品开展。如果需求发生变化，双方将共同遵循项目定义的“变更控制规程”执行。需求的变更将导致双方重新协商成本、资源和进度等。 甲方签字： 乙方签字： 签字日期： 签字日期：图3 需求承诺书（6）需求跟踪在整个软件开发过程中，捷鼎都需要进行需求跟踪，其目的是为了建立和维护从科达公司需求开始到测试之间的一致性与完整性，确保所有的实现都是以科达公司的需求为基础的，确保对于需求实现是否全部覆盖，同时确保所有的输出与用户需求的符合性。捷鼎软件项目小组的需求跟踪主要是正向跟踪的方式；即以科达有限公司需求为切入点，检查需求规格说明书中的每个需求是否都能在后继工作产品中找到对应点。项目组通过正向跟踪建立与维护需求跟踪矩阵。需求跟踪矩阵保存了需求与后续开发过程输出的对应关系。矩阵单元间可能存在“一对一”、“一对多”的关系。表2是简单的需求跟踪矩阵示例。使用需求跟踪矩阵的使用让捷鼎项目组更加容易发现需求与后续工作产品之间的不一致，有助于开发人员及时纠正偏差，避免做无用功。表2 需求跟踪矩阵需求代号需求规格说明书V1.0设计文档V1.2代码1.0测试用例测试记录R001R002标题或标识符标题或标识符代码文件名称测试用例标识测试记录标识（7）需求变更控制事先预言所有的相关需求是不可能的。系统原计划的操作环境会改变，用户的需求会改变，甚至系统的角色也有可能改变。实现和测试系统的行为可能导致对正解决的问题产生新的理解和洞察，这种新的认识就有可能导致需求变更。需求变更通常会对项目的进度、人力资源产生很大的影响。这是软件开发企业非常畏惧的问题，也是必须面临与需要处理的问题。3.3科达公司ERP软件开发中存在的主要需求风险在捷鼎公司需求风险分析过程，项目组不难发现在他们面前存在着两个主要的问题，这些问题很有可能会影响用户需求的获取。3.3.1科达公司的需求将可能不断变更科达公司正处于一种快速发展的阶段，组织机构和管理流程还不断在变化，这种情况下，有可能出现软件的开发速度赶不上企业的发展变化，有经验的人员都知道，这样的系统将陷入一种没完没了的修改之中。这样给本次的ERP软件开发带来极大的需求风险。3.3.2科达公司的信息化配合力度不够在调研中发现科达公司的信息化基础非常薄弱。一个800多人、年销售额超10亿元的企业，目前应用计算机信息管理系统的部门和人员很少。常用的计算机软件只有一个非常简单的内部OA系统，一套税务局制定的财务管理系统，以及研发部门一套三维的CAD辅助设计软件，而销售管理、采购管理、人事管理、库存管理等，都还是用Office中的Excel进行相关的数据分析。在这种情况下，捷鼎软件公司原来已经制定好的项目实施计划受到了很大的影响。因为他们原先计划指定的主要步骤包括：调研、分析、设计、分批编码、试运行、分批系统切换、总体集成和验收。但是，目前企业的基础较差，调研工作的进展不理想，已经直接影响到其他工作。3.3.3科达公司不能表达自身需求在走访中笔者发现科达公司决策层之所以要开发ERP是因为企业管理水平低，所以要上ERP,以期提高整个企业的管理水平，他们并不十分了解ERP功能、工作流程、工作方式的不同之处。而由于企业管理水平低，上ERP的基础不牢靠，必须先提高管理水平，上ERP才能成功，否则就容易失败。简单来说就是：上ERP的失败，是因为企业管理水平低；因为企业管理水平低，所以要上ERP。更有甚者，多数决策者认为这个ERP软件开发是万能的，一旦开发应用成功就能解决绝大多数的实际问题，而对于本公司的业务规则以及流程等不愿多提。这种现象增加了需求分析工作难度，极大的带来了需求风险。 第四章 科达公司ERP软件开发的需求风险管理对策4.1 建立有效的需求风险控制的组织机构 在一个系统中,结构决定着系统的主要功能和主要的运行方式。因此在进行有效的需求风险控制过程中需要建立有效的组织机构。至于哪种组织机构购更适合开发ERP，更能够有效的控制需求风险并不可一言蔽之。笔者认为组织机构应该是适合的有效率的扁平化组织结构。在项目管理中大多数采用的是传统的金字塔式组织结构,管理过程中暴露了很多问题,如:管理层次多,信息传递慢,横向联系少,决策不及时等,严重影响了项目管理的效率。扁平化组织结构作为一种对金字塔式组织结构的改进形式,可以避免一些问题的出现。因此,笔者认为应该建立扁平化的组织机构以加强需求风险控制的能力。扁平化组织结构作为一种新的组织结构,已经在一些国际化公司试行,并将成为企业组织结构变革的方向。目前,国内对扁平化组织结构的特征、效率和实施方案等方面的研究成果主要集中在组织结构柔性定量分析、扁平化组织结构四大典型特征、组织结构与信息传递效率关系、计算机在组织结构扁平化实施中的具体方案等方面,很少涉及到扁平化组织结构抗风险能力方面的研究。对于一个企业组织,除了正常的可预见成本之外,更多的支出就是风险损失,特别是在当今科技日新月异、社会环境瞬息万变的时代,风险的研究和管理就显得尤为重要。本文以复杂的社会化环境为背景,着重研究组织结构分岔在消除和化解组织结构风险损失中的作用,分析柔性与化解组织结构风险能力之间的相关性及扁平化组织结构的柔性水平,进而系统分析扁平化组织结构在降低组织结构风险上的优势。同时，管理人员的支持与重视是进行有效需求风险控制管理的先决条件，企业各级管理人员不仅要有强烈的需求风险管理意识，而且要积极参与到需求风险管理中去。建立起以企业高级管理人员负责的风险管理组织架构，制定风险管理过程、确定风险管理工具以及管理监控风险，维护风险管理工具库。4.2 完善可靠的需求风险控制的管理过程需求风险控制的管理过程是一种获取、组织并记录系统需求的系统化方案，以及 一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。需求风险控制的管理的目的是在顾客和将处理顾客需求的软件项目组之间建立对顾客需求的共同理解。使软件需求受控，并建立供软件工程和管理使用的基线。使软件计划、产品和活动与软件需求保持一致。需求风险控制的管理应该上升到组织的高度。需求风险控制的管理应该是领导带头、全员参与、持续改进的，因此，可通过如下几个方面来加以改进。（1）建立规范需求风险管理的组织文化。组织文化是组织成员共有的价值和信念体系，这一体系在很大程度上决定了组织成员的行为方式。组织应当建立起规范风险管理的企业文化，让所有员工认识到需求风险控制的管理过程是项目管理不可或缺的有机部分并贯穿于整个项目的始终。（2）需求风险控制的管理过程优化。有效的需求风险控制的管理过程应是学习型的、持续的和不断进化的。软件企业应建立自己的风险管理数据工具库以作为需求风险控制的管理过程的基础，并在实施中不断地更新与完善。需求风险控制的管理过程的学习性主要体现在培训活动上，培训的内容包括风险管理技术以及工具的使用，培训可以取材于需求风险控制的管理过程数据工具库，使需求风险控制的管理过程不断地从历史经验中学习过程的各个活动构成了循环，贯穿于项目始终，以保证需求风险控制的管理过程的持续性过程中的每个活动在循环中都和数据库进行交互，不断采集并更新数据，在各个活动的循环中不断加以改进。（3）适当的授权和激励。授权。企业的管理者要勇于授权、敢于放权。制订各级、各类人员的风险管理责任制，明确任务和职权，各司其职，密切配合，做到权责合一，以形成一个高效、协调、严密的风险管理系统。激励。企业的管理者应建立合理的激励机制，根据员工的风险管理责任制对员工进行考评，作为奖罚的依据，调动员工进行风险管理的积极性。4.3 针对主要风险的具体对策 对于上述的可能存在的风险，应该从培训、考察、宣传入手，在企业各个层面组织各类培训。例如，ERP基本知识的普及培训、先进管理思想的培训、企业流程的培训等；并组织B仪表的相关人员到其他企业学习、考察，亲身感受信息化应用的效果。首先，捷鼎软件公司的开发人员可以对企业流程进行分类：第一类，可以确定下来的流程；第二类，可以变通的流程；第三类，有可能变化的流程，但变化的情况可以举例；第四类，肯定会变，但不知道怎么变的流程。不同的流程在软件设计中采用不同的解决办法：第一二类按正常的方法设计；第三类，采用参数控制法；第四类，细分业务单元，采用用户流程自定义。4.3.1进行库存管理抓住科达公司决策者最迫切和最关心的问题。例如，整个ERP系统开发初期，库存管理是企业管理的重要组成部分，库存的主要功能是在供给和需求之间建立缓冲，减缓供需矛盾。库存作为生产、采购、物料需求计划、销售、成本的依据，保证库存数据的准确性、完整性与及时性，是保证生产、财务、成本、销售、采购等其他系统顺利上线的关键，也是整个系统成功与否的关键。开发人员在开发过程中利用一切机会了解决策者关心的问题，同时也让他们了解项目的情况。在诸如专题汇报、协调会议、领导视察、阶段性成果演示等过程中，用简短明确的语言或文字抓住领导最关心的问题，引导他们了解和重视项目的开发，当决策者认识到项目的重要性时，需求分析工作在人力、物力、时间上就有了保障。4.3.2建立组织保障，明确的责任分工捷鼎软件公司应该成立相应的项目组或工程组，包括：产品管理组、质量与测试组、程序开发组、用户代表组和后勤保障组。产品管理组负责确定和设置项目目标，根据需求的优先级确定功能规范，向相关人员通报项目进展。程序管理组负责系统分析，根据软件开发标准协调日常开发工作确保及时交付开发任务，控制项目进度。程序开发组负责按照功能规范要求交付软件系统。质量与测试组负责保证系统符合功能规范的要求，测试工作于开发工作是独立并行的。用户代表组负责代表用户方提出需求，负责软件的用户方测试。后勤保障组负责确保项目顺利进行的后勤保障工作。4.3.3做好软件需求变更的控制。软件需求经常变化的问题是每个开发人员、每个项目经理都会遇到的问题，也是最头痛的问题。一旦发生了需求变化，就不得不修改软件设计、重写程序代码、修改测试用例、调整项目计划等。做过项目的人都会有这样的经历：一个项目做了很久，感觉总是做不完，就像一个“无底洞”，用户总是有新的需求要项目开发方来做。系统开发出以后，用户不断提出新要求，每天追着开发人员解决问题，没完没了的往下做。这个现象的本质问题就是需求变更所引发的。在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项到研发和维护。需求的变更可以发生在任何的阶段，即使到项目后期，例如，测试阶段，用户也会根据测试的实际效果，再提出一些变更要求，其实这种后期的变更会对项目产生很严重