软件开发项目风险管理的几点体会

1、参与过人型软件项bl的人部会认识到许多事惜部可能出错，但出错就可能给项hl带来 危害、损失或比它不利影响。M.险足在项日屮发生的-系列事件或不利结果的可能性。软件 开发楚项髙风险的活动，在项|开发过軒的任何一个阶段都町能存在风险。采取积极的风 险管埋方式，可以使项日进稈更加平稳，可以获得很髙的跟踪和控制项日的能力，可以规避、 转移风险，或缓解风险带来的不利影响。风.险管理是对项I风险进行识别、分析、应对和监 控的过程，是项I管理中很重要的管理活动，仃效的实施软件风险管理是软件项II开发丁作 顺利完成的保证。风险符理的达成必须包括匚个要素：首先，在项I开发计划屮必须制定风险管理计划； 第二，在项

2、I预算中必须包含解决风险所需的经费：第三，评估风险时，风险的购响也必须 纳入项I计划中。下血就软件开发过程屮经常发工的风险，谈谈我们采取的预防抬施。2. 需求不明确需求不明确是软件开发过軒屮经常町能遇到的问题，这类问题往往表现在潘求范I期未界 定、需求木细化、需求描述不淸楚、盂求遗漏、需求互相矛盾等多个方面。在软件开发过程 的生命周期并阶段中，需求不明确所造成的浪费是最人的，必须尽早尽可能解决。确定用户 需求楚件非常因难的事请，我们常常从以下几个方由1看手处理需求不明确问题：(1) 让用户参与开发提供一个协作开发环境.让用户参与开发过秤如果条件不允许至少应该在每次迭代 的需求分析和系统测试阶段

3、，让客户能够参与开发。在选择参与开发过程的用户时，一方血，要尽对能争取精通业务或计算机技术的川户参 与。另一方血，如果开发的产品要在不同规模、不同类型的企业皿用，应该选择具有代农性 的用户参与。仅仅让用户参与是不够的，应该采取一定的激励措施.提高川户参与的枳极性。(2) 开发用户界血原型用户通常不善于精确描述|己的业务需求，系统分析员需要借助白板、广I纸等沟通方式, 帮助用户清楚表述需求。然后，开发一个用户界面原型,以便用户确认需求。用户界面原型 的作用仅仅是收集用户盂求，不应该再作它用，也不要给用户造成系统快要实现的错觉。(3) 需求讨论会议对于用户分布广、用户帚犬的项II,要全血收集川户需

4、求，往往很困难，通常采取需求 研计会议方式进行需:求确认。通过在会议前几周调杏各地、各部门用户需求总见，然后集中 各地或各部门的用户代表，举办一次需求研讨会，通过会议方式收集需求C木方法适合于具 有一定信息系统使用经验的用户。(4) 强化需求分析与评审首先，需求分析是项日成功的基础，需要引起足够的巫视，并分配充足的时间和人力， 要让尙经验的系统分析员负贵，切忌让项日新手或程序员负贵。其次，要进行需求评审，尽 可能让用户参与需求评审，不要让需求评审流于行式。第三，也是最乘要的一点，通过评审 的需求规格说明书，要让用户方签字，并作为项H合同的附件，对双方都具有约束力。在公 U-J内部要将通过评审的

5、需求规楙说明书，纳入祀置管理.3. 项目缺少可见性十一个项II经理或一名开发打说(2经完成了 80%的任务，您必须保持审慎的态度。冈 为剩下的20%可能还需:要X0%的时间，誤至永远部不能完成I；软件开发坝日，往往在项 1=1进度和软件质就方面缺少可见性，项日越缺少可见性，项日就越难以控制，项1=1就越仃可 能失败。我们诃以通过迭代开发、技术评审、持续集成來増强项I的可见性。(1) 迭代开发采用迭代的开发模型，将产品的交付过程分为多个阶段，按照功能递增式交付。以下是 一些典翌的迭代：一次简短的先期迭代，以建立规模和前景并确定商业理山；一次箱化迭代.其间将为稳定的构架圳定基线：一次构建迭代，其间

6、将实现丿I例并充实构架；几次产品化迭代，将产品转移到用户群。每次迭代，部要充分接收用八的评审意见，以便为臼我纠止。渐近式的功能交付，勺利 F降低开发人员的压力，增加用户的满意度，有利于增强项目的可见性，是瑕好的进展报告。(2) 技术评审技术评中是确保软件质帚的重要环节，技术评审包括代码走任、会议评审和同行专家评 审。代码走审可以是开发人员之间的交叉审杳，或者是高级开发人员对普通开发人员的审杳; 会议评审一般臧至少每两周进行一次，每次评审时间不宜太长；同行专家评审包括技术和业 务两个方血的专家，经常性地让将通业务的用户专家参与项I评审，是项I I成功的巫要保证。另外,充分利用质量审竇的工具软件,

7、也有利于提高代码质量。例如：在Eclipse开发 ”、境屮，可以集成Findbug、CheckstylePMD插件检金代码编与质昴。(3) 持续集成持续集成能够把最终的次人规模的集成调试过种分敢到项hl开发时间表的每-周、每 一入、决金每个小时。让项日屮的乞个人员都能够随时芈握当前的胳体进度，并迅速发现集 成过程屮出现的问题并进行解决I 1 O开发小组应制定持续集成的制度，i般情况下每I构建一次，可以利用Ant等构建T.具 litff Java hv.用程序的构建，小组成员应在毎个功能开发完成后，及时向版木控制系统(如 CVS)提交代码，而且不应该向版木控制系统提交有问题(编译通不过)的代码。

8、每II构建、持续集成，让项LI进度跟踪丁作更加容易。当项II小组每天巫新编译系统时, 己完成弓未完成的功能淸楚可见，小纽成员能够简巾地从软件的表现知道距离幣体完成还右 多远。4. 新技术引入技术创新是-种具佝探索性、创造性的技术经济活动。衣开发过秤中引入新技术，不可 避免地要遇到衿种风险。通过T形软件开发、充分论证、多阶段评审、同行经验等措施可 降低新技术风险。(1) T形软件开发在项H开发早期，开发小组应该建立系统的架构，解决关键技术难题、开发系统的基础 构fl并对系统所需要应川的技术做深度探索。例如：基于JavaEE5构建全国联网代栗系统, 涉及到分布式事务处理、海帚:数据存储、异构平台互

9、连等关键问题，应该优先处理这些问题: 对开发所涉及到的FR2、JSF. JRossSeam. Eclipse RCP 技术要做深度探索- 图1在第一阶段以“T”形开发系统骨架2越绘技术复杂度高的项II，就越应该早地处理技术难题。如果在项II开发的中期或拆期 才发现架构佇问题或是关键技术难题不能解决，则为时12晩，(2) 充分论证新技术开发是探索性很强的T作，潜在着许多失败的凤险。在可行性分析阶段，要广泛 搜集柿关信息，设计多种可行方案，进行充分论证。在制定决策时，惜报的数帚和质帚致关 乘要，掌握的信息越多、越准确，才能作出正确的的决策.项II失败的风险也就相对减少; 反之，承担的风险就会增人。

10、同行经验针对新技术，由于没有经验可借鉴，因此在探索过秤屮要充分利用互联网，通过搜索同 行经验，往往事半功倍。要允分利用世界口益平坦化的优势，对丁不能尽快解决的问题，4 以先放倣，可能过不了几天，网上就佇相类似问题的解决方案了。5. 技术兼容性风险破件产品Z间、系统软件(操作系统、屮间件、数据库管理系统)与主机设备之间、系 统软件之间、应用软件与系统软件之间以及丿“用软件之间，都可能存在兼容性问题。往往系 统集成的项日越复杂，兼容性问题就越右可能存在。(1) 设计先行在做系统的总体设计方案时，务必把好相关产品的选型关，确保网络、上机、系统软件 与应川软件之间不要存在较人的技术兼容性问题。在网络平

11、台建设方案中，明确相关设备的 技术参数和配置要求.(2) 售前产品测试在做项II招投林作时，要求投林方在售前提供产品兼容性测试，以避免在项II实施过 卅中才暴霸技术兼容性问题。涉及应用软件开发的集成项目，要在开发作的早期，做技术 兼容性测试，以避免在项口开发厉期才暴銘技术兼容性问题.例如，我们在开发深圳市汽车客运站售栗及站务联网凋度系统时，为了确保技术兼容, 在做硕件招标时要求小型机设备厂商提供售前技术兼容性测试丁作，并将测试结果做为评标 指标。在深圳市软件测试中心对IBM、SUN、HP三家公司提供的小型机进行测试时,暴露 了许多臧用软fl、应用服务器、数据库和操作系统之间的技术兼容性问题，如

12、杲这些问题在 系统实施时才暴露或处理，势必会拖延项II进度。6. 性能问题由于先期设计不足，性能问题往往在系统切换或新系统使用一段时间斤暴露。出现性能 问题往往要进行人帚的优化匸作，共至局部的或全血的重新设计。无论是川户还绘开发者， 淮祁不希望出现性能问题。(1)性能规划在系统设计时，应做好前期做性能规划，对町能出现性能问题的环节做到充足的估计。 在做数据库设计时，应爭取DBA参与。另外，在技术方法方血，尽可能采取一些性能优化模式，如DTO、AJAX、延迟加载等, 尽可能在开发过祝中解决了性能问题。不至于到了项II后期才解决性能问题，既费钱又费时。 性能测试在开发过秤中，要求视性能测试和爪力测

13、试，尽诃能模拟现实使用”、境，搭建测试平台。 另外,由于开发环境的计算机往往比生产环境的计算机配置高,在做测试时应尽量找一些配 置低的机器、较小的网络带宽进行测试。(3) 充足的调试时间在项日开发i十划中，为际期性能优化留有余地。在对系统进行性能优化肩，要进彳J：性能 测试和压力测试，町能还要做几次冋归测试。因此，应该驸有充址的时间和人力。7. 仓促上线在项日实施过程中，系统切换上线环节最容易出纯漏。项日好不容易开发完成了，却在 最JnfiJn时刻功溃一匮。如果项日小.彫响血牢倒不怎么垂要；如果是影响血人的项口，则 T力不可出现问题。在系统切换前，应充分考虑冷种可能出现的问题，做好风险对策。(

14、1) 应急预案血对并种不可预知的风险，要做好皿急预案。正常运行的车站售票系统在春运、旅游黄 金周，部会做好应急预案。新系统切换时，更应该做好丿“急预案。应急预案中应做好最坏的 打算，您票系统不能止常匸作时，准备手匸票就是最坏的打算，(2) 分步切换为了减少风险的影响，可以做系统分步切换的方案。例如：住票系统在切换时，往往用 新系统售预售栗，或者是用新系统售长途车站，用in系统暂时售短程栗。待新系统运行稳定 后，再全血切换到新系统。针对多个用户单位的系统切换.也可分单位进行。交叉培训新I口系统切换过卅中，用户祁存奋适应过程。除了在切换前做好操作培训外，还要在新 !系统切换过秤中做好交义培训。让用

15、门提前一些时间上班.让早班的用户在交班时培训中 班的川户，中班的川户培训晚班的川户。做好交叉培训能够让系统半衡过渡。8. 可用性问题软件的可用性包括软件的使用是不是高效、是台容易学:习、是台容易记忆、足否令人愉 快、圮否不易出错等诸多因索。往往由于软件的可用性羌，导致用户不满意，共至被市场淘 汰。在项目开发中应注意可用性问题,避免软件出现可用性方面的风险。(I) 了解用户到用户丁作现场，了解I标用户使用软件的真实II的，从用户的角度、从用户的立场出 发，了解如何通过软件系统替代用户的业务处理流秤屮，最繁琐、最容易岀问题、或淆是人 吊巫复芳动的”、节，讣软件提高用户的T.作效能和效率。例如：儕票

16、系统屮，使用频度故高 的界rfn是售票界血，售票员最关心的是钱不要出错(餌了没收、少了要赔)，因此，应收款 和找余字体的显不应该突出、酹1丨；同样，票价和到达站也应该较为突出显示。通过快捷键、 一键复位、数字小键盘等设计，尽杲减少售票员敲击键盘的次数。占则，在LI发旅客流帚达 七、八力人次的人型客运站，如果用户界面设汁得不好，您票员-天丁作下来，手指部会敲 麻木。(2) 参与型设计与用户协作，让用户参与用户界血的设计、评审与测试，确保用户能够全血地、及早地 发现可用性等方面的问题，并及时纠正。让客户参与设计，而不要让客户设计，项口经理或高级设计人员应该上导设计。(3) 竞争性分析通过对市场上同类竞争性产鼎进行分析，或者对这些产鼎进行丈验性测试，r解这些产 品的川户界血问题，从而对新系统的开发提供启发。竟彳性分析并不盘味希诃以剽窃别人的 设计，而址通过分析竞争产品的优势和弱点，能够比以前的设汁做得更好5。-致性如果用八知道同样的命令或同样的操作总会产生同样的效果，那么他们在使用系统时就 会更加自信，同时也鼓励他们进行探