软件开发计划编制风险产生的后果

上传人:bin****86 文档编号:60322211 上传时间:2018-11-15 格式:DOCX 页数:22 大小:28.10KB
返回 下载 相关 举报
软件开发计划编制风险产生的后果_第1页
第1页 / 共22页
软件开发计划编制风险产生的后果_第2页
第2页 / 共22页
软件开发计划编制风险产生的后果_第3页
第3页 / 共22页
软件开发计划编制风险产生的后果_第4页
第4页 / 共22页
软件开发计划编制风险产生的后果_第5页
第5页 / 共22页
点击查看更多>>
资源描述

《软件开发计划编制风险产生的后果》由会员分享,可在线阅读,更多相关《软件开发计划编制风险产生的后果(22页珍藏版)》请在金锄头文库上搜索。

1、为了适应公司新战略的发展,保障停车场安保新项目的正常、顺利开展,特制定安保从业人员的业务技能及个人素质的培训计划软件开发计划编制风险产生的后果软件开发的需求风险分析摘要:随着软件开发技术的不断更新、软件数量的不断增多、软件复杂程度不断加大、客户对产品的要求也在不断的提高,随之而来的是市场对软件开发项目需求的不断变化,这便给软件开发企业和需求企业带来的巨大风险。市场对软件开发项目的需求会直接影响到公司的生存。这对软件开发企业来讲应该是更大的难题。本文通过对当前软件行业的需求风险状况进行分析,列举软件开发项目的需求风险来源,并进行分析,总结需求风险产生的原因和对项目成败的影响,最后给出软件开发项目

2、在需求风险管理和控制方面的建议。关键字:软件开发需求风险风险分析一、对需求风险的理解产品开发过程中,由于产品需求本身的隐含性、用户与开发者之间的沟通障碍,以及需求随着时间、用户的变化而变更等原因,可能使需求分析偏离实际需求而最终导致产品开发的失败,这种可能性称为需求风险。软件开发项目风险是指在软件生命周期中所遇到的所有的预算、进度和控制等各方面的问题,以及由这些问题而产生的对软件项目的影响。需求分析是软件开发过程中最初始、最基础的工作,也是最重要的工作之一,其成败将直接并最终决定软件开发的成败,并且呈倍增效应。需求分析的关键是使隐含的需求明确,使变更的需求可控,采用座谈会、需求调查表、需求启发

3、、角色扮演等方法可以使需求明确化;采用面向对象的方法及UML工具、领域专家的全程参与、需求分级、二次开发接口等方法可以使需求变更处于可控范围内。实践证明,这些都是控制需求风险的有效方法。二、需求的获取产品前景和项目范围应该在软件开发项目早期,编写一份包括业务需求在内的前景和范围文档,并将它作为添加新需求和修改现有需求的指导。需求开发所需的时间将每个软件开发项目中需求开发所耗费的实际工作量记录下来,这样就可以判断出需求开发是否充分,并可以改进未来项目的工作计划。需求规格说明的完整性和正确性为了确保需求是客户真正需要的,应该以用户任务为中心,应用用例技术来获取需求。创新产品的需求对软件开发项目中的

4、第1个产品,不太容易把握市场对软件产品的反映。定义非功能需求由于我们一般都会强调产品的功能,所以很容易忽略产品的非功能性需求。客户对产品需求意见一致确定那些主要的客户,并采用产品代言人的方法,保证有足够的客户代表的积极参与未加说明的需求一般的客户会有一些隐含的期望要求,但并未以文档的方式说明出来。尽量识别客户可能做出的任何假设。把已有的产品作为需求基线来源把通过逆向工程发现的需求编成文档,让客户来评审这些需求,确保其正确性和相关性。根据需要提出解决方案软件产品分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图。三、需求风险的来源软件项目风险经常会涉及许多方面,如:缺乏用户的参与,缺少高级

5、管理层的支持,含糊的要求,没有计划和管理等,这里我们主要分析需求的风险。很多开发项目在确定需求时都面临着一些不确定性。当在开发项目早期容忍了这些不确定性,并且在项目进展过程当中得不到解决,这些问题就能对项目的成功造成非常大的威胁。如果不控制与需求相关的风险因素,就很有可能产生错误的软件产品或者拙劣地建造预期的软件产品。每一种情况对产品来讲都可能致命的。需求风险的来源包括:没有足够用户参与、不断增加的用户需求、模棱两可的市场需求、不必要的特性、过于精简的规格说明、被忽略的用户分类、不准确的产品开发计划。软件开发项目风险中与客户相关的风险因素有:(一)对软件产品缺少清晰的认识,(二)对产品需求缺少

6、认同,(三)开发者在做需求调查中客户参与不够,(四)市场中没有优先需求,(五)不确定的需要导致出现新的市场,(六)不断变化市场需求,(七)缺少有效的需求变化管理过程,(八)对需求的变化缺少相关分析等。四、需求风险的管理软件开发项目管理人员可以运用对风险管理来提高对造成项目损失的条件的警惕,在市场需求获取阶段要有用户的积极参与。精明的产品开发管理者不但能认识到它能带来风险的条件,而且将它编入风险清单,并依据以往产品开发项目的经验估计其可能性和影响。如果用户一直没有参与,风险危害值将会扩大以至危害项目的成功。即使不能控制项目可能遇到的所有风险,风险管理也能使软件开发项目管理者看清形势,做出的决策是

7、有所依据。(一)制定风险管理计划对于一个软件开发项目,你可以把控制风险的计划放在软件项目管理计划里面。但是一个大项目则需要有一份独立的风险管理计划,包括用于识别、评估、编写、跟踪产品开发风险的各种方法与途径。这份计划还应包括风险管理活动的角色和责任。通常情况下,项目小组为他们的关键活动制定了计划,但是在项目中并没有按计划去实施或者没能按实际情况进行及时的调整。一定要坚持按照所采取的风险管理活动计划去执行。项目的进度安排上也应该要给风险管理留出足够时间来确保项目并未浪费早期投资在风险计划制定上面。工程项目的工作分类细目结构中包括降低风险的活动、状态报告,与更新风险清单。和其它项目管理活动一样,需

8、要建立起周期性的监控措施。保持对十来个有最大危害的风险的高度重视,并追踪降低风险措施的有效性。当完成一项活动后,重新评估那项风险的可能性和影响,更新风险清单和其它相关的计划。当控制住原本有很高优先级的风险后,必然有新条目会进入前十条。值得注意的是,不要仅仅因为完成了一项降低风险的活动而人为增加一条风险来进行控制。应当想想降低风险的方法是否真的减少了风险的危害,使它减少到了一个可以接受的水平。周期性地进行需求风险跟踪可以使项目经理了解风险对软件产品开发项目的威胁,没有得到有效控制的需求风险应该上报高层管理人员,他们可能开始采取一些纠正措施,也可能不管风险,依旧按照原来的业务决策思路进行。即使不能

9、控制项目可能遇到的所有风险,风险管理也能帮助我们看清形势,做出合理的决策。具体管理措施1、首先要明确你当前软件开发项目面临的一些与需求有关的风险,不要把当前的问题当作风险,一定要是那些还未发生的事情。将风险的因素编写成文档,为每项需求风险推荐至少一种可能的降低风险的方法。2、召集代表开发、市场、客户和管理各方面的涉众召开风险“集体研讨”会议。尽力找出更多与需求有关的风险因素。估计每项风险发生的可能性及其影响,两者乘积就是风险危害值。通过按风险危害值降序排列找到最高的五项风险。为每项风险安排一个负责人负责实施降低风险的活动。五、结束语软件开发项目中的需求风险是所有风险中的一个不可忽视的组成部分,

10、对其认识的必要性不言而喻,应该重视对它的分析,对需求风险的合理管理也是软件开发项目项目管理中不可或缺的部分。参考文献:1黄国光,周勇.软件需求工程,清华大学出版社,XX.(5).2陶履彬.工程风险分析理论与实践,同济大学出版社,XX.(12).参加过项目制作的人都知道一个项目开发过程中会遇到许多困难,很多事情都会影响一个软件开发的失败风险是在项目中发生的一系列事件或不利结果的可能性。软件开发是一项高风险的活动,在项目开发过程的任何一个阶段都可能存在风险。采取积极的风险管理方式,可以使项目进程更加平稳,可以获得很高的跟踪和控制项目的能力,可以规避、转移风险,或缓解风险带来的不利影响。风险管理是对

11、项目风险进行识别、分析、应对和监控的过程,是项目管理中很重要的管理活动,有效的实施软件风险管理是软件项目开发工作顺利完成的保证。风险管理的达成必须包括三个要素:首先,在项目开发计划中必须制定风险管理计划;第二,在项目预算中必须包含解决风险所需的经费;第三,评估风险时,风险的影响也必须纳入项目计划中。下面就软件开发过程中经常发生的风险,2.需求不明确需求不明确是软件开发过程中经常可能遇到的问题,这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发过程的生命周期各阶段中,需求不明确所造成的浪费是最大的,必须尽早尽可能解决。确定用户需求是件非常困

12、难的事情,我们常常从以下几个方面着手处理需求不明确问题:(1)让用户参与开发提供一个协作开发环境,让用户参与开发过程。如果条件不允许,至少应该在每次迭代的需求分析和系统测试阶段,让客户能够参与开发。在选择参与开发过程的用户时,一方面,要尽可能争取精通业务或计算机技术的用户参与。另一方面,如果开发的产品要在不同规模、不同类型的企业应用,应该选择具有代表性的用户参与。仅仅让用户参与是不够的,应该采取一定的激励措施,提高用户参与的积极性。(2)开发用户界面原型用户通常不善于精确描述自己的业务需求,系统分析员需要借助白板、白纸等沟通方式,帮助用户清楚表述需求。然后,开发一个用户界面原型,以便用户确认需

13、求。用户界面原型的作用仅仅是收集用户需求,不应该再作它用,也不要给用户造成系统快要实现的错觉。(3)需求讨论会议对于用户分布广、用户量大的项目,要全面收集用户需求,往往很困难,通常采取需求研计会议方式进行需求确认。通过在会议前几周调查各地、各部门用户需求意见,然后集中各地或各部门的用户代表,举办一次需求研讨会,通过会议方式收集需求。本方法适合于具有一定信息系统使用经验的用户。(4)强化需求分析与评审首先,需求分析是项目成功的基础,需要引起足够的重视,并分配充足的时间和人力,要让有经验的系统分析员负责,切忌让项目新手或程序员负责。其次,要进行需求评审,尽可能让用户参与需求评审,不要让需求评审流于

14、行式。第三,也是最重要的一点,通过评审的需求规格说明书,要让用户方签字,并作为项目合同的附件,对双方都具有约束力。在公司内部要将通过评审的需求规格说明书,纳入配置管理。3.项目缺少可见性当一个项目经理或一名开发者说已经完成了80%的任务,您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间,甚至永远都不能完成1。软件开发项目,往往在项目进度和软件质量方面缺少可见性,项目越缺少可见性,项目就越难以控制,项目就越有可能失败。我们可以通过迭代开发、技术评审、持续集成来增强项目的可见性。(1)迭代开发采用迭代的开发模型,将产品的交付过程分为多个阶段,按照功能递增式交付。以下是一些典型的迭代:一

15、次简短的先期迭代,以建立规模和前景并确定商业理由;一次精化迭代,其间将为稳定的构架划定基线;一次(来自:写论文网:软件开发计划编制风险产生的后果)构建迭代,其间将实现用例并充实构架;几次产品化迭代,将产品转移到用户群。每次迭代,都要充分接收用户的评审意见,以便为自我纠正。渐近式的功能交付,有利于降低开发人员的压力,增加用户的满意度,有利于增强项目的可见性,是最好的进展报告。(2)技术评审技术评审是确保软件质量的重要环节,技术评审包括代码走查、会议评审和同行专家评审。代码走审可以是开发人员之间的交叉审查,或者是高级开发人员对普通开发人员的审查;会议评审一般应至少每两周进行一次,每次评审时间不宜太长;同行专家评审包括技术和业务两个方面的专家,经常性地让精通业务的用户专家参与项目评审,是项目成功的重要保证。另外,充分利用质量审查的工具软件,也有利于提高代码质量。例如:在Eclipse开发环境中,可以集成Findbug、Checkstyle、PMD插件检查代码编写质量。(3)持续集成持续集成能够把最终的一次大规模的集成调试过程分散到项目开发时间表的每一周、每一天、甚至每个小时。让项目中的各个人员都能够随时掌握当前的整体进

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 办公文档 > 总结/报告

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号