软件开发项⽬的风险
参加过项⽬制作的⼈ 都知道⼀个项⽬开发过程中 会遇到许多困难，很多事情都会影响⼀个软件开发的失败  风险是在项⽬中发⽣的⼀系列事件或不利结果的可能性。软件开发是⼀项⾼风险的活动，在项⽬开发过程的任何⼀个阶段都可能存在风险。采取积极的风险管理⽅式，可以使项⽬进程更加平稳，可以获得很⾼的跟踪和控制项⽬的能⼒，可以规避、转移风险，或缓解风险带来的不利影响。风险管理是对项⽬风险进⾏识别、分析、应对和监控的过程，是项⽬管理中很重要的管理活动，有效的实施软件风险管理是软件项⽬开发⼯作顺利完成的保证。风险管理的达成必须包括三个要素：⾸先，在项⽬开发计划中必须制定风险管理计划；第⼆，在项⽬预算中必须包含解决风险所需的经费；第三，评估风险时，风险的影响也必须纳⼊项⽬计划中。
下⾯就软件开发过程中经常发⽣的风险，
2.需求不明确
需求不明确是软件开发过程中经常可能遇到的问题，这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相⽭盾等多个⽅⾯。在软件开发过程的⽣命周期各阶段中，需求不明确所造成的浪费是最⼤的，必须尽早尽可能解决。确定⽤户需求是件⾮常困难的事情，我们常常从以下⼏个⽅⾯着⼿处理需求不明确问题：
(1) 让⽤户参与开发
提供⼀个协作开发环境，让⽤户参与开发过程。如果条件不允许，⾄少应该在每次迭代的需求分析和系统测试阶段，让客户能够参与开发。
在选择参与开发过程的⽤户时，⼀⽅⾯，要尽可能争取精通业务或计算机技术的⽤户参与。另⼀⽅⾯，如果开发的产品要在不同规模、不同类型的企业应⽤，应该选择具有代表性的⽤户参与。
仅仅让⽤户参与是不够的，应该采取⼀定的激励措施，提⾼⽤户参与的积极性。
(2) 开发⽤户界⾯原型
⽤户通常不善于精确描述⾃⼰的业务需求，系统分析员需要借助⽩板、⽩纸等沟通⽅式，帮助⽤户清楚表述需求。然后，开发⼀个⽤户界⾯原型，以便⽤户确认需求。⽤户界⾯原型的作⽤仅仅是收集⽤户需求，不应该再作它⽤，也不要给⽤户造成系统快要实现的错觉。
(3) 需求讨论会议
对于⽤户分布⼴、⽤户量⼤的项⽬，要全⾯收集⽤户需求，往往很困难，通常采取需求研计会议⽅式进⾏需求确认。通过在会议前⼏周调查各地、各部门⽤户需求意见，然后集中各地或各部门的⽤户代
表，举办⼀次需求研讨会，通过会议⽅式收集需求。本⽅法适合于具有⼀定信息系统使⽤经验的⽤户。
(4) 强化需求分析与评审
⾸先，需求分析是项⽬成功的基础，需要引起⾜够的重视，并分配充⾜的时间和⼈⼒，要让有经验的系统分析员负责，切忌让项⽬新⼿或程序员负责。其次，要进⾏需求评审，尽可能让⽤户参与需求评审，不要让需求评审流于⾏式。第三，也是最重要的⼀点，通过评审的需求规格说明书，要让⽤户⽅签字，并作为项⽬合同的附件，对双⽅都具有约束⼒。在公司内部要将通过评审的需求规格说明书，纳⼊配置管理。
3.项⽬缺少可见性
当⼀个项⽬经理或⼀名开发者说已经完成了80%的任务，您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间，甚⾄永远都不能完成[1]。软件开发项⽬，往往在项⽬进度和软件质量⽅⾯缺少可见性，项⽬越缺少可见性，项⽬就越难以控制，项⽬就越有可能失败。我们可以通过迭代开发、技术评审、持续集成来增强项⽬的可见性。
(1) 迭代开发
采⽤迭代的开发模型，将产品的交付过程分为多个阶段，按照功能递增式交付。以下是⼀些典型的迭代：
⼀次简短的先期迭代，以建⽴规模和前景并确定商业理由；
⼀次精化迭代，其间将为稳定的构架划定基线；
⼀次构建迭代，其间将实现⽤例并充实构架；
⼏次产品化迭代，将产品转移到⽤户。
每次迭代，都要充分接收⽤户的评审意见，以便为⾃我纠正。渐近式的功能交付，有利于降低开发⼈员的压⼒，增加⽤户的满意度，有利于增强项⽬的可见性，是最好的进展报告。
(2) 技术评审
技术评审是确保软件质量的重要环节，技术评审包括代码⾛查、会议评审和同⾏专家评审。代码⾛审可以是开发⼈员之间的交叉审查，或者是⾼级开发⼈员对普通开发⼈员的审查；会议评审⼀般应⾄少每两周进⾏⼀次，每次评审时间不宜太长；同⾏专家评审包括技术和业务两个⽅⾯的专家，经常性地让精通业务的⽤户专家参与项⽬评审，是项⽬成功的重要保证。
另外，充分利⽤质量审查的⼯具软件，也有利于提⾼代码质量。例如：在Eclipse开发环境中，可以集成Findbug、Checkstyle、PMD插件检查代码编写质量。
eclipse开发手机app(3) 持续集成
持续集成能够把最终的⼀次⼤规模的集成调试过程分散到项⽬开发时间表的每⼀周、每⼀天、甚⾄每个⼩时。让项⽬中的各个⼈员都能够随时掌握当前的整体进度，并迅速发现集成过程中出现的问题并进⾏解决[1]。
开发⼩组应制定持续集成的制度，⼀般情况下每⽇构建⼀次，可以利⽤Ant等构建⼯具进⾏Java应⽤程序的构建。⼩组成员应在每个功能开发完成后，及时向版本控制系统（如CVS）提交代码，⽽且不应该向版本控制系统提交有问题（编译通不过）的代码。
每⽇构建、持续集成，让项⽬进度跟踪⼯作更加容易。当项⽬⼩组每天重新编译系统时，已完成与未完成的功能清楚可见，⼩组成员能够简单地从软件的表现知道距离整体完成还有多远。
4.新技术引⼊
技术创新是⼀种具有探索性、创造性的技术经济活动。在开发过程中引⼊新技术，不可避免地要遇到各种风险。通过T形软件开发、充分论证、多阶段评审、同⾏经验等措施可降低新技术风险。
(1) T形软件开发
在项⽬开发早期，开发⼩组应该建⽴系统的架构，解决关键技术难题、开发系统的基础构件，并对系统所需要应⽤的技术做深度探索。例如：基于JavaEE5构建全国联⽹售票系统，涉及到分布式事务处理、海量数据存储、异构平台互连等关键问题，应该优先处理这些问题；对开发所涉及到的EJB3、JSF、JBoss Seam、Eclipse RCP等技术，要做深度探索。
图1 在第⼀阶段以“T”形开发系统⾻架[2]
越是技术复杂度⾼的项⽬，就越应该早地处理技术难题。如果在项⽬开发的中期或后期才发现架构有问题或是关键技术难题不能解决，则为时已晚。
(2) 充分论证
新技术开发是探索性很强的⼯作，潜在着许多失败的风险。在可⾏性分析阶段，要⼴泛搜集相关信息，设计多种可⾏⽅案，进⾏充分论证。在制定决策时，情报的数量和质量致关重要。掌握的信息越多、越准确，才能作出正确的的决策，项⽬失败的风险也就相对减少；反之，承担的风险就会增⼤。
(3) 同⾏经验
针对新技术，由于没有经验可借鉴，因此在探索过程中要充分利⽤互联⽹，通过搜索同⾏经验，往往事半功倍。要充分利⽤世界⽇益平坦化的优势，对于不能尽快解决的问题，可以先放⼀放，可能过不了⼏天，⽹上就有相类似问题的解决⽅案了。
5.技术兼容性风险
硬件产品之间、系统软件（操作系统、中间件、数据库管理系统）与主机设备之间、系统软件之间、应⽤软件与系统软件之间以及应⽤软件之间，都可能存在兼容性问题。往往系统集成的项⽬越复杂，兼容性问题就越有可能存在。
(1) 设计先⾏
在做系统的总体设计⽅案时，务必把好相关产品的选型关，确保⽹络、主机、系统软件与应⽤软件之间不要存在较⼤的技术兼容性问题。在⽹络平台建设⽅案中，明确相关设备的技术参数和配置要求。
(2) 售前产品测试
在做项⽬招投标⼯作时，要求投标⽅在售前提供产品兼容性测试，以避免在项⽬实施过程中才暴露技术兼容性问题。涉及应⽤软件开发的集成项⽬，要在开发⼯作的早期，做技术兼容性测试，以避免在项⽬开发后期才暴露技术兼容性问题。
例如，我们在开发深圳市汽车客运站售票及站务联⽹调度系统时，为了确保技术兼容，在做硬件招标时要求⼩型机设备⼚商提供售前技术兼容性测试⼯作，并将测试结果做为评标指标。在深圳市软件测试中⼼对IBM、SUN、HP三家公司提供的⼩型机进⾏测试时，暴露了许多应⽤软件、应⽤服务器、数据库和操作系统之间的技术兼容性问题，如果这些问题在系统实施时才暴露或处理，势必会拖延项⽬进度。
6.性能问题
由于先期设计不⾜，性能问题往往在系统切换或新系统使⽤⼀段时间后暴露。出现性能问题往往要进⾏⼤量的优化⼯作，甚⾄局部的或全⾯的重新设计。⽆论是⽤户还是开发者，谁都不希望出现性能问题。
(1) 性能规划
在系统设计时，应做好前期做性能规划，对可能出现性能问题的环节做到充⾜的估计。在做数据库设计时，应争取DBA参与。
另外，在技术⽅法⽅⾯，尽可能采取⼀些性能优化模式，如DTO、AJAX、延迟加载等，尽可能在开发过程中解决了性能问题。不⾄于到了项⽬后期才解决性能问题，既费钱⼜费时。
(2) 性能测试
在开发过程中，要重视性能测试和压⼒测试，尽可能模拟现实使⽤环境，搭建测试平台。另外，由于开发环境的计算机往往⽐⽣产环境的计算机配置⾼，在做测试时应尽量⼀些配置低的机器、较⼩的⽹络带宽进⾏测试。
(3) 充⾜的调试时间
在项⽬开发计划中，为后期性能优化留有余地。在对系统进⾏性能优化后，要进⾏性能测试和压⼒测试，可能还要做⼏次回归测试。因此，应该留有充⾜的时间和⼈⼒。
7.仓促上线
在项⽬实施过程中，系统切换上线环节最容易出纰漏。项⽬好不容易开发完成了，却在最后最后时刻功溃⼀匮。如果项⽬⼩，影响⾯窄倒不怎么重要；如果是影响⾯⼤的项⽬，则千万不可出现问题。在系统切换前，应充分考虑各种可能出现的问题，做好风险对策。
(1) 应急预案
⾯对各种不可预知的风险，要做好应急预案。正常运⾏的车站售票系统在春运、旅游黄⾦周，都会做
好应急预案。新系统切换时，更应该做好应急预案。应急预案中应做好最坏的打算，售票系统不能正常⼯作时，准备⼿⼯票就是最坏的打算。
(2) 分步切换
为了减少风险的影响，可以做系统分步切换的⽅案。例如：售票系统在切换时，往往⽤新系统售预售票，或者是⽤新系统售长途车站，⽤旧系统暂时售短程票。待新系统运⾏稳定后，再全⾯切换到新系统。针对多个⽤户单位的系统切换，也可分单位进⾏。
(3) 交叉培训
新旧系统切换过程中，⽤户都存在适应过程。除了在切换前做好操作培训外，还要在新旧系统切换过程中做好交叉培训。让⽤户提前⼀些时间上班，让早班的⽤户在交班时培训中班的⽤户，中班的⽤户培训晚班的⽤户。做好交叉培训能够让系统平衡过渡。
8.可⽤性问题
软件的可⽤性包括软件的使⽤是不是⾼效、是否容易学习、是否容易记忆、是否令⼈愉快、是否不易出错等诸多因素。往往由于软件的可⽤性差，导致⽤户不满意，甚⾄被市场淘汰。在项⽬开发中应注意可⽤性问题，避免软件出现可⽤性⽅⾯的风险。
(1) 了解⽤户
到⽤户⼯作现场，了解⽬标⽤户使⽤软件的真实⽬的，从⽤户的⾓度、从⽤户的⽴场出发，了解如何通过软件系统替代⽤户的业务处理流程中，最繁琐、最容易出问题、或者是⼤量重复劳动的环节，让软件提⾼⽤户的⼯作效能和效率。例如：售票系统中，使⽤频度最⾼的界⾯是售票界⾯，售票员最关⼼的是钱不要出错（多了没收、少了要赔），因此，应收款和余字体的显⽰应该突出、醒⽬；同样，票价和到达站也应该较为突出显⽰。通过快捷键、⼀键复位、数字⼩键盘等设计，尽量减少售票员敲击键盘的次数。否则，在⽇发旅客流量达七、⼋万⼈次的⼤型客运站，如果⽤户界⾯设计得不好，售票员⼀天⼯作下来，⼿指都会敲⿇⽊。
(2) 参与型设计
与⽤户协作，让⽤户参与⽤户界⾯的设计、评审与测试，确保⽤户能够全⾯地、及早地发现可⽤性等⽅⾯的问题，并及时纠正。
让客户参与设计，⽽不要让客户设计，项⽬经理或⾼级设计⼈员应该主导设计。
(3) 竞争性分析
通过对市场上同类竞争性产品进⾏分析，或者对这些产品进⾏实验性测试，了解这些产品的⽤户界⾯
问题，从⽽对新系统的开发提供启发。竞争性分析并不意味着可以剽窃别⼈的设计，⽽是通过分析竞争产品的优势和弱点，能够⽐以前的设计做得更好[5]。
(4) ⼀致性
如果⽤户知道同样的命令或同样的操作总会产⽣同样的效果，那么他们在使⽤系统时就会更加⾃信，同时也⿎励他们进⾏探索性学习，因为他们已经具备了使⽤系统新部分的基础知识[Lewis er al.1989]。
开发团队应遵循公司或⼩组制定的⽤户界⾯标准，就可以在很多⽅⾯保持⼀致性，切忌不要⼀个系统存在多种不同的界⾯风格。
9.结论
在信息系统集成项⽬中，风险是多种多样的，是⽆处不在的。在项⽬管理活动中，要积极⾯对风险，要培养。越早识别风险、越早管理风险，就越有可能规避风险，或者在风险发⽣时能够降低风险带来的影响。特别是在项⽬参与⽅多、涉及⾯⼴、影响⾯⼤、技术含量⾼的复杂项⽬，应加强风险管理。如果不主动驾驭风险，就会⾯临风险。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。