（工商管理专业论文）风险管理在软件开发中的应用.pdf

0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 摘要 随着我国对外软件出口加工行业的蓬勃发展，软件界的各种问题也越来越多。没 有实行项目风险管理是很多问题的根源。作为一个在软件出口型企业工作了十余年的 软件从业人员，迫切希望从实际工作中总结出一套解决软件开发风险的方法。本文参 考了国内外对于项目风险管理的研究成果，结合了基本的项目管理知识，运用了一些 软件过程成熟度模型和经济学的基本工具，提出了一套切实可行的针对软件企业的风 险管理的系统方法。其基本框架是：把项目风险的因素分成项目过程的特定风险、组 织架构保障不足带来的系统风险、人力资源管理的因素造成的风险等三种风险类型。 着重对项目需求界定和估算原则、风险计划和跟踪的管理过程等企业级风险管理能力 等，运用能力成熟度模型、风险管理模型和经济学理论进行解析，找出应对这三种风 险类型的一套项目风险管理方法。 关键词：风险管理过程改进组织架构 0 3 2 0 2 5 2 9 5 李军风险管理在软件开发中的应用 a b s t r a c t p r o b i e m so ft h es o f t w a r ef i e l di n c r e a s eg r a d u a l l ya c c o r d i n gt oa c t i v e d e v e l o p m e n to ft h es o f t w a r ee x p o r ti n d u s t r yo fo u rc o u n t r y i ti st h er o o t o ft h ep r o b l e m st h a tp r o j e c ts e l d o mm a n a g er i s k s a sa ne m p l o y e ew h ow o r k e d i nas o f t w a r ee n t e r p r i s ef o rt e ny e a r s ，ik e e n l yh o p et os u m m a r i z ei tt ot h e m e t h o do fs o l v i n gt h er i s ku s i n gt h ek n o w - h o wf r o ma c t u a lw o r k t h ef o l l o w i n gt e x tw i l lg i v eo u tas y s t e m a t i cm e t h o db yu s i n gb a s i c k n o w l e d g eo fp r o j e c tm a n a g e m e n tr e f e r r i n gt ot h er e s u l to ft h er e s e a r c ho f d o m e s t i ca n df o r e i g np r o j e c tr i s km a n a g e m e n t ，a n do p e r a t i n gab a s i ct o o lo f s o f t w a r ec a p a b i l i t ym a t u r i t ym o d e la n dm l c r o e c o n o m i c s t h eb a s i cb o n eo ft h et e x ti s ：d i v i d et h ef a c t o r so ft h ep r o j e c tr i s ki n t o 3t y p e s ：s y s t e m a t i cr i s kb r o u g h tb yo r g a n i z a t i o nf r a m e w o r ko ft h ep r o c e s s d e f i n i t i o n ：c e r t a i nr i s kb r o u g h tb yt h el a c ko fp r o j e c tp r o c e s sm a n a g e m e n t ： a n dt h ee l e m e n to fm a np o w e r t h et e x tp u t sf o c u so nt h ep r i n c i p l eo ft h e r e q u i r e m e n ta n a l y s i sa n de s t l m a t i o na c t i o n s ，a n da l s op u tt h ep r o c e s so ft h e r i s km a n a g e m e n tp l a n n i n ga n dt r a c k i n ga c t i o n st ot h ee m p h a s i st a r g e t ia m t r y i n gt of o r m u l a t eaw a yo fm a n a g i n gt h ep r o j e c tr i s kb yt h et h e o r yo ft h e c a p a b i l i t y m a t u r i t ym o d e l ，t h ep r o c e s sm o d e lo fr i s km a n a g e m e n t ，a n dt h e m l c r o e c o n o m l c s k e yw o r d s ：r i s km a n a g e m e n t ：p r o c e s si m p r o v e m e n t ：o r g a n i z a t i o nf r a m e w o r k - 2 一 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 引言 我是一名软件项目经理。品尝过项目过程的艰辛，经历过痛苦的软件危机，也享 受过成功的喜悦。在历经数年的磨练中，发现风险管理对于项目开发的成败起着决定 性的作用。在写这篇论文的时候，实在是希望能给自己这些年的项目管理好好地来个 总结，找出今后努力的方向。恰巧，今年夏天，我又担任了一个新的项目，在国外进 行项目前期的需求分析和预算商谈中，再次体会到了项目风险给软件业带来的冲击。 究竟怎样才能使一个项目做到客户和开发商双赢? 在日益残酷的价格竞争中怎样使 企业拥有持续竞争力? 面对越来越精明和多变的客户，在谨小滇微地精耕细作的同 时，还有什么需要大胆尝试? 企业的人才流动率又开始抬头，内忧外患，面对日益增 加的工作压力，怎么办? 我从重新翻阅过去5 年间从事过的项目开始着手，丝毫不意外地发现，大凡不如 意的项目都具有几个共同特征：客户给的需求不完整，变更频繁，我们被动地跟在后 面加班返工；工期紧张导致开发过程的某些重要环节走“捷径”，最终品质不良；估 算经验不足，数度被套；营业额指标的压力以及为维持和客户的关系，很多从一开始 就知道是亏的项目，也不得不接。我确信这些问题暴露了在我的项目管理中还有很多 不健康不正常的因素存在。 自然而然地，把m b a 的这些年学习联系在了一起。 通过学习决策论，了解了对于那些未来不确定风险因素的决策方法。通过学习运 营管理，了解了如何安排关键路径，如何给出高置信度的进度估计。通过学习微观经 济学和财务管理，了解了对整个生命周期里的现值计算以及成本收益分析，这大大丰 富了我在风险管理的投入产出上的思路。还有关于创新技术管理方面的一些思想模式 也给了我很大的启发。全面质量管理的6 西格马让我感到了过程化管理的重要陛。把 这些知识用到考察我的那些过去的项目，我终于明白，一定要用经济学头脑和商人哲 学来处理软件开发的风险管理，严格遵守科学规律，走好每一步，对各项管理活动要 精于计算。正如拿破仑曾经说过“ia mu s e dt ot h i n k z n gt h r e eo rf o u rm o n t h si n a d v a n c ea b o u t 曲a tim u s td o a n dic a l c u l a t eo nt h ew o r s t i fit a k es om a n y p r e c a u t i o n si t i sb e c a u s ei ti sm yc u s t o mt ol e a v en o t h i n gt oc h a n c e ”防 患于未然，看来，项目管理也是一个把不精确逐渐转化为精确的过程。这启发了我对 风险管理的兴趣。很多同行碰到了和我一样的困惑，希望通过写这篇论文让我能更早 地摆脱这个泥潭吧。 很多国内外的专家学者对于项目管理的论述集中在了项目管理的9 大知识领域 ( 项目综合管理，范围，时间，成本，质量，人力资源，沟通，风险和采购管理) 以 0 3 2 0 2 5 2 9 5 李军风险管理在软件开发中的应用 及5 个过程组( 启动，计划，实施，控制和收尾) 。这些当然是很重要的。但我认为 对于国内的软件开发企业，没必要面面俱到。凡事都要有个度，不能为了管理而管理。 抓住项目风险的最主要罪魁祸首，花心思改善这些方面，就能在短时间里改变困境。 本文的主要写作思路和框架如下： ( 1 )概述风险管理的基本思想，阐明软件项目的风险及其原因。归纳出开发 过程改进，组织架构保证和人力资源改善三个主要风险对策。 ( 2 ) 具体阐述如何进行开发过程改进。把项目风险中最主要的几个因素进行 说明。分别阐述了避免需求界定过程的风险( 包括权衡功能性价比，避 免规模不经济等) ，避免需求变更混乱造成的风险，还有在规模估算的 2 种常用方法的陷阱和对策，工作量估算的c o c o m o 模型和我的意见， 进度计划的风险考虑，以及风险跟踪监控活动的决策要点。这些软件工 程的阶段蕴含了大量的高优先度的风险，必须谨慎对待。 ( 3 )说明如何构建良好的组织架构。具体说明如何建立企业的开发规程和学 习模式，保证风险管理体制，塑造良好的风险管理文化，以构建稳定和 谐的组织开发环境，来确保能够依赖组织的力量控制项目风险。 ( 4 )说明如何解决人力资源问题。简单叙述如何建立良好的人力资源配置， 提高工作效率，并对人力资源外包等利弊进行分析。 ( 5 )结论。从项目过程改进消除特定项目风险，从组织架构保证消除企业开 发系统风险，从人的因素来稳定开发团队，提高团队的生产率。 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 1 风险管理概述 1 1 什么是风险 风险管理是- - f l 科学。“风险”一词据说起源于意大利语，是勇于挑战的意思。 起先，这只是一项游戏，看对机会的把握。它的核心就是后来的概率论。我们现在也 是把“风险”作为“失败的可能性”的同义词在使用。但实际上这并不全面。至少， 风险的大小和损失的大小有直接关系，也和结果出现的概率有关。所以，简单说来， “风险”应该是以下的算式： 风险= 负面事件的发生概率 一旦发生造成的损失 当然，“风险”的定义应该还拥有更多的参数，比如，风险久拖不治的程度，和 因人而异的风险承受力等其他因素。时间是一个重要的参数。要知道，病入膏肓就是 风险防治不利的结局的最好诠释。 在实际工作中，我不止一次地发现，所谓负面事件实际上是由一群具有正相关性 的更细小负面事件组成，他们每个都具有发生概率和损失，他们并不独立，而是起连 带反应。这在软件开发行业特别普遍。在这个事在人为的行业里，人的因素是非常重 要的。 比如人的高流动性，对很多开发因素产生潜在威胁。它会影响的团队技术能力， 一旦需要培训代替者会增加成本，同时还影响团队内部沟通( 可能是正面的) ，影响 生产率，影响任务分担，还影响软件的维护成本。每个变量时刻都在发生着增值或贬 值的变化，对于一个团队而言，几乎在任意小的时间跨度里，团队实力都在发生着微 小的变化。有时是日积月累，从量变到质变。而有些则是直接革命性的跳跃或崩债。 它的变化曲线是间断式的。如何对这些细微的风险变化进行分析，把它控制在可接受 的范围，是一门动态管理的学问。 1 2 什么是风险管理 风险管理是指如何在一个肯定有风险的环境中把风险降至最低限度的管理过程。 当中包括了对风险的辨别，度量、评估和应对策略等一系列过程。由于有资源限制， 所以人们希望能够花最少的资源去尽可能化解最大的危机。这是风险管理的宗旨。 一般会对识别出的主要风险进行量化分析，依次排列出最重要的若干个风险予以 优先解决。每个风险的解决对策不尽相同，包括规避、转移、缓解、接受等各种方针。 确定风险对应方针后，就是编制风险应对计划，把风险的描述、风险应对的责任人、 风险对应策略及行动计划、应急计划等记录在册。时刻监督风险的发展与变化情况， 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 并确定随着某些风险的消失而带来的新的风险。还要不断丰富风险数据库、更新风险 识别检查列表、注重项目风险管理经验的积累和总结，形成风险管理意识和文化。 在风险管理中，风险分析是重要的一环。一般先找出风险源，并初步判明风险的 严重程度。然后对给出的各个风险源量化指标及其发生概率，再通过一定的方法合成， 得到系统风险的量化值。定量分析是基于定陛分析基础上的数学处理过程。在风险分 析中有以下几个主要的方法和概念。 ( 1 ) 敏感性分析 敏感性分析的目的，是考察与事件有关的一个或多个主要因素在发生变化时对该 项目的影响程度的大小。通过敏感性分析，使我们可以了解和掌握在哪些参数的估算 上如果有错或是使用的数据不太可靠可能造成致命偏差，而哪些则可以有回旋余地， 这样的分析有助于我们找准关键环节上的风险要点进行调查研究和分析测算。 ( 2 ) 概率分析 概率分析是运用概率论和数理统计方法，来预测和研究各种不确定因素对事件影 响的一种定量分析方法。通过概率分析可以对风险情况做出比较准确的判断。很多时 候还运用模拟的方法，把各个有概率分布的风险因素依次进行独立模拟( 虽然在软件 业中更多的使用历史数据，而非随机数据) ，得出每个风险要素的期望值，然后求出 整个事件的总体系统风险的风险值。 ( 3 ) 盈亏平衡分析 盈亏平衡分析是根据风险防治的效果和代价等数据，计算和分析风险管理的成本 和收益这两者之间的关系，从中找出规律，并确定成本和收益相等时的风险管理盈亏 平衡点的一种分析方法。目的是确定最合理的风险管理力度，做到管理效益最大化。 特别在一些脑力劳动行业，防范风险依靠人力的成分比较多，但并不意味着投入越多 就越能降低风险，有时候正相反。 ( 4 ) 风险偏好策略 风险应对策略有很多。比如，小中取大、大中取小、最大数学期望原则、最大可 能原则等等。根据决策者的风险偏好因素，采取合适的决策策略。在乐观派和悲观派 的两种不同策略的选择中取得平衡，基于平均值的估计往往容易被接受。另外，控制 好方差，提高整个事件的抗风险能力的置信度。 风险管理的这些方法在我要论述的软件开发行业同样能发挥重要的作用，因为在 这个行业中充满了高风险，而人们还没有足够的意识来防范软件项目风险。特别是运 用风险管理的一些普遍理论来指导项目风险管理。 0 3 2 0 2 5 2 9 5 李军风险管理在软件开发中的应用 1 3 软件项目的风险管理状况 在至今几乎5 0 年的时间里，同计算机有关的人一直在经历着各种各样的软件危 机。业界也一直在试图解决这些问题并改进解决问题的方法。软件危机大致有如下特 征： 项目失控的概率高。 软件的问题： 质量不可靠。 延期交货。 维护困难。 开发效率低下。 难以移植，不可重用。 业界研究表明，对项目风险管理的重视程度还远远不够。5 5 的失控项目( 发生 了成本严重超支或者进度严重拖延的项目) 根本没有进行过风险管理，3 8 的失控项 目只做了一些风险管理工作( 但其中一半在项目进行过程中并未处理被发现了的风 险) ，而另外7 的失控项目也并不知道他们是否进行了风险管理工作。这个研究表明， 实施风险管理对提高项目成功的可能陛、防止项目失控是至关重要的。 深入剖析软件危机，我们可以发现软件开发业界过去所面临的问题有很多原因， 而且许多原因至今仍未消除。 客户和开发者对系统的需求缺乏了解和统一认识。 搜集和分析需求的方法往往支离破碎，没有整体感。 估算技巧较差，估算所受到的外界压力也大。 缺乏需求变化管理。 程序员间的生产率差异较大。 难以监控软件项目进程。 组间沟通以及组内成员之间的沟通不好。 难以衡量程序员的表现。 下面，结合我熟悉的对日软件开发行业来详细说明软件项目风险的现状。 对日软件开发时下在上海软件出口加工中占据最重要的份额。日本是世界上最大 的软件及系统集成市场之一，几乎所有的日本企业都运用计算机系统进行日常管理。 随着近两年，日本经济的逐渐复苏，i t 投资又重新开始活跃。很多企业发现，光靠 日本国内市场已经远远不能满足企业生存发展的需要，必须向世界扩张。这导致了很 多企业纷纷改造原来的系统，软件系统也开始了全球化。突然爆发的大量软件系统开 发订单使得日本软件企业争相扩大规模以应对巨大的市场机会。大量的日本软件企业 纷纷到中国投资，招兵买马，急速扩张。然而，在人力资源外包的选择上，日本和美 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 国的选择不同。美国选择印度，是因为印度有着良好的软件开发流程管理能力和印度 的英语语言优势，加上时差，可以实现几乎2 4 小时连轴不问断开发。而日本则更青 睐中国，是因为距离和文化的相近，也因为中国诱人的巨大的i t 市场前景。 中国各地方政府也纷纷把软件加工出口作为地方上的一个重要的经济增长点，设 立了高新技术开发区，并以各种优惠条件吸引外资的加入。与此相呼应，各种软件培 训学校也十分火爆。几乎所有重点高校都专门成立了软件学院。有少数还专门针对日 本市场，提前培养学生的日语和日本软件开发流程等基本知识的教育。同时，包括很 多国际化的大公司，纷纷成立了全球软件开发服务中心，专门开发日本客户发过来的 软件外包订单。这种势头使得对日软件开发管理人才一直非常热门。 不过近年来，中国软件开发的总体质量并不理想，良莠不齐，人力资源的成本却 在不断上升，使得日本企业已经开始将眼光转向东南亚的一些国家。这对那些以科技 产业和人才带动地方经济的地区将造成极大的潜在威胁，也将严重影响围绕着软件产 业而兴起的各行各业。 我在对日软件开发企业工作了十数年，总结这个行业主要有以下几个问题： 很多企业成立的时间都不长，没有足够的开发经验积累。很多企业的项目开发流 程不规范。开发经验数据比较缺乏。在做项目估算时经常没有足够充分的证据来 佐证。这造成管理层经常拒绝项目经理的预算方案。工程线表也容易受外力影响 变得不合理。 企业规模偏小，没有足够资金支持来进行开发过程规范化改进，致使开发质量不 高，事后维护和返工的代价高昂。开发过程的不成熟是造成行业开发风险的最大 因素之一。 业界倾向于做冒险式的项目估算以争取订单，经常出现销售额很高，利润率为负 数的恶性经营。即便赔钱也要拿到项目的情况比比皆是。 日本客户的需求变化比较频繁。加上服从客户意愿，维持与客户的良好关系一直 是日本企业的服务理念，所以，经常出现开发中途发生需求变化却不能改变原来 的预算的怪现象。这使得处在开发流程中下游的中国企业处在被动的状态。“随 需应变”在软件开发业界并不是个受欢迎的现象。但这是现实课题，谁解决得好 就能赢得客户。 人员流动率高。很多企业的年离职率高达3 0 以上。3 5 年后全是新面孔的现象 很普遍。比起欧美软件公司，对日软件开发企业的薪水相对较低，发展空间也更 有限，虽然在员工培训上投资也不小，但很大一块是日语培训。这对于很多软件 开发人员来说，吸引力并不大。降低成本是企业主要考虑的任务。积累几年工作 经验的员工的跳槽率更高。造成企业开发管理能力严重不足，员工的平均日语水 平不高，和客户的交流有障碍。 很多项目都是短期的小项目。小项目在某些方面的风险更集中，因为没有回旋余 0 3 2 0 2 5 2 9 5 李军风险管理在软件开发中的应用 地，更容易发生偏差。 我感觉由于以下的原因，软件危机在今后一段时间内还将继续存在下去。 缺少训练有素的、有经验的软件项目经理。 有经验的软件开发者的高离职率导致软件质量下降。 新的软件系统的沉重需求导致软件开发过程中的偷工减料。 软件工程作为一门学科还在发展，尚不稳定。 软件风险管理理论虽然起步，但没有合适的风险管理工具可用。 软件危机具有的这些特性，决定了对软件项目风险的防范和对策存在很多不同的 策略，是彻底根治，还是预防为主，还是减小损失，这些都取决于人们对各种策略的 整体综合判断。 纵观以上，可以把软件开发中的风险归结为以下几大风险要素： 开发过程的因素 组织架构的因素 人力因素 其中，开发流程是最直接也最稳定的提高防范风险能力的因素。而组织则能潜移 默化中提供企业文化和工作作风的保证，能保证项目和人才同时进步。人在这样的环 境中不断学习，不断自主创新，从而提高自己，提高企业实力。这是一个良性循环。 也是软件企业为了生存下来必须追求的目标。 1 4 软件项目的风险管理成功要素 好的软件项目风险管理应该是默默无闻地进行的。当进行有效的风险管理时，软 件项目基本不会产生什么问题。为了让项目管理的工作看似容易，需要在别人不易察 觉的背后，付出计划，管理和深谋远虑。结合软件开发企业的现状和问题，我认为应 当先从以下几个环节进行改进，这些很多也是软件危机中暴露得最多的问题。 1 开发过程改进。 虽然日本客户对产品质量的要求近乎苛刻，但是过程的改进并不是求大求全就能 肯定能保证质量和效率的。不一定要象c m m 或c m m i 要求的那样面面俱到，只要抓住 薄弱环节，通过各种风险对应机制不断地将不确定因素转化为可接受的风险。特别是 强化需求管理，切实做好估算和进度计划，并且注意风险跟踪和数据测量，这些阶段 的过程改进都会是最直接和最有效的。 2 组织架构保证 组织架构保证是包括组织如何通过制定政策和标准，使得组织形成一种稳定的项 目管理文化，能够有健壮的体制保证软件项目风险管理的正规化。这一点常常通过资 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 格或认证反映出企业的软件开发资质。当然这也是赢得合同的一个重要加分因素a 而 更重要的是塑造一个学习形组织，使企业具备在竞争环境中敏锐的发现新知识和分析 风险的能力，并且在内部形成一些共享知识平台和开发管理数据库，来减少开发的成 本，培养自己的核心竞争力。 3 人力因素 人是一个关键因素，通过不断的互相沟通和意识交流把不确定因素转化为风险进 行管理。按照风险管理计划，通过执行计划来管理各种风险。在软件行业里对员工的 岗位安排和激励是一个比其他竞争对手更严峻更棘手的课题。如何在项目中妥善地安 排各种层次的员工参与其中，既保持较好的工作效率，又能不断带动新员工尽快成长， 是一个倍受关注的课题。另外，在项目人力资源不足的时候，是内部消化还是外包， 这需要在考虑降低成本的同时也要兼顾保证企业持续发展的能力，作出理智的抉择。 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 2 开发过程改进 2 1 开发过程概述 很多软件开发企业都设计了一套规范的开发过程，这个过程应该是一个普适而广 泛的定义，根据项目的大小，范围和预算等各种条件，软件项目小组可以裁减掉不适 合自己的过程，保留为了开发当前项目所必需的最小过程集合。大家通过评审讨论确 定最后的合适的开发管理过程。一般说来，在一个软件项目周期里，有一系列相互关 联的部分时间有重叠的各组活动过程组成整个开发过程。整个开发周期大致包括项目 启动，计划，实施，控制和收尾等过程。在各个过程中需要投入的管理工作量是不同 的。如图2 1 所示： 融 * 需 烘 剐 舡 图2 i 软件项目的过程组 每个过程的主要任务大致如下： 启动过程 包括开始项目和项目的某个阶段的有关活动。启动一个项目要做的事有：必须有 人负责定义项目的商业需求，有人为项目提供经费，有人承担项目管理的角色。事实 上在项目的每个子阶段也都有各自的启动过程，为了判断项目工作是否应该按原计划 继续下去，需要重新考察最新的需求。甚至在开发完了阶段，也需要启动相关结束工 作，确认所有工作都已完成，确保客户能够接受项目成果，团队对开发过程的经验教 训进行总结归档，并最终解散全部项目资源以便重新配置。 计划过程 包括编制和不断修改成一个可行的计划。编制项目计划可以确定某时间点上项目 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 的范围，进度，明确各项活动的实施时间，人员，成本以及需要采购的资源。为了应 对项目条件的变化和组织环境的变更，项目生命周期中的每个阶段都常常会对计划加 以调整。 实施过程 包括组织并协调人员和其他资源，以便实施项目计划并生产出产品或可交付成果 物。一般而言，实施过程包括组建一支项目团队，进行有关领导工作，确保项目质量， 发布有关信息，采购必要的资源，交付实际工作的成果等。 控制过程 就是要通过对照计划对项目的进度进行监督和测评，并在必要的时候采取纠正行 动。为了确保项目目标的实现，一般的控制过程至少包括执行状态评审和绩效考核。 如果有必要进行某些变更，项目组必须有人负责对这些变更进行识别，分析和监控。 收尾过程 主要是指进行正式的项目或项目阶段验收工作，使其有序地结束。这里会涉及到 诸如项目文件的存档，工作的总结，知识的记录，以及正式的验收交货工作等。 2 1 1 风险管理是和开发同步的过程 风险管理并不是独立于开发管理过程之外的一个单独的过程。它也不是附属品， 它就是开发管理过程本身。因为对于项目经理来说，如何把握住项目前进的速度和方 向，保持对项目的持续的风险监控，避开危险，及时化解问题，这些风险管理的课题 就是软件项目管理的核心。在开发管理过程的开始阶段包含了极高的风险要素，并且 在开发过程中也需要对监视中的风险状态进行分析，并及时调整对策，因此风险管理 需要用完善的过程化来稳定其管理作用。 一般而言，项目组成员在项目初始阶段一起编制风险管理计划，通过回顾过去类 似项目的风险历史数据，结合企业制定的风险检查列表，根据当前项目的特性来识别 特定风险。一般是通过头脑风暴的方法，分成开发范围，时间，成本，质量等几个领 域来进行考量。比如，整体上计划是否不充分，有无资源配置不充足或错误，开发范 围的定义是否欠妥，对质量的要求是否暧味不清楚，进度估算是否有错误，生产率等 成本要素的估算是否存在较大误差，成员的质量意识是否有问题，是否需要某些培训 等。但是有些潜在风险更适合用单独面谈的方法来识别，比如工作人员责任心，大家 的沟通能力会否存在障碍等等。还有包括人员稳定性的问题也应该通过单独面谈的方 式进行确认。在这个阶段列出所有可以预计到的项目风险列表。 然后对这些风险进行定性分析，把风险按照失败的概率的高中低和失败的后果的 大中小记入以下的风险概率一影响图( 图2 2 ) 。对于低到中的风险应该适当投资进行 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 风险管理，而那些高风险的项目则应该及时放弃或设法降低它的风险程度。 恒 幡 窭 g 餐 水 小 失败的后果大 图2 2 风险概率一影响图 在定性分析之后，进行必要的定量分析，包括边际成本一收益的分析，净值的计 算，或者使用决策树等方法，对项目的各种风险以及对策方法的投资效益进行相互比 较，选出最适合的方案作为风险应对预案记录在风险管理计划表中。在这个计划表中 应该包括风险对策的几种基本措施，风险规避，风险接受，风险转移，风险减轻等。 当然仅仅写在风险管理计划表是不够的。项目风险管理不能停留在最初的风险分 析上，因为识别出的风险可能会消失，或者它的概率和损失发生了变化，或者又有新 的风险被发现。对于风险暴露的这种动态变化，项目团队对风险进行跟踪控制，及时 更新风险管理计划表，循环地使用定性分析和定量分析，以动态地管理风险或应对风 险事件的发生。 2 1 2 风险管理过程的度 大多数的软件工程方法，都是为了早点知道哪些以前担心发生的事晴会真的再现 发生，但天下没有免费的午餐，任何东西都有代价，为了这个“早点知道”，我们需 要付出的可能是过度工程以及其带来的副作用。因此风险控制也不能无限制，需要权 衡。 项目的主要目标是按时按质按预算地完成软件项目任务，所有的活动都应该围绕 这个目标进行。一个风险管理活动是否应该保留或应该如何进行，要完全以是否有利 于项目目标为准则。风险管理需要考虑成本一收益平衡。在项目开发过程中的风险管 理投入和产出的关系，可以用下图来简单表示。可以看出，对风险管理的投入使得风 0 3 2 0 2 5 2 9 5 李军风险管理在软件开发中的应用 险的暴露( 损失) 和投入成本达到平衡的点，是最优的风险控制。 成本 最优风 险控制 图2 3 风险管理的投入一产出关系 任何的管理活动都需要在任务本身直接成本以外增加一块额外的间接管理成本， 就看这个投资换来的收益价值是不是足够大。所以，不能为了管理而管理。管理是有 目标的。但是，在很多软件企业里，出现了教条主义，照搬照抄人家的开发过程，有 些还不顾项目特性，盲目求大求全，却忘记了最基本的东西；项目的目标。这种本末 倒置的现象说明了很多人对于开发过程的理解还很片面，没有合理取舍，合理运用。 也正是考虑到这个度的问题，我认为，目前很多对日软件开发企业要优先考虑解 决的是以下几个开发前期工程的风险管理过程的改进： 需求界定过程 需求管理过程 估算及计划过程 风险控制和跟踪过程 下面将逐一阐述我在这几个关键开发过程的工作中的对于风险管理的理解。 2 2 需求界定过程 风险界定过程的目的是通过落成明确的需求说明书，使得客户和开发者对系统的 需求统一认识。这个过程在很多对日软件开发企业中经常是，派驻一些中方人员往日 本客户处，进行现场的需求搜集和分析，并且和客户就某些功能要求进行反复磋商， 以达成双方都满意的需求。 需求的界定是对开发团队而言极端重要的阶段，需要考虑几个重要因素以降低开 发风险，这个过程的工作完成得越好，项目的发展就越能向好的方向靠拢。一般有以 下几个原则需要掌握： 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 注意性能与成本的关系，不盲目追求性能。 注意规模不经济的现象。 注意移植改造的开发不同于全新开发的道理。 2 2 1 性能与成本效益 很常见，在每次开发中客户总会希望产品的性能能够达到其最高界限，但是这经 常就是过剩的要求。有些要么是根本不会被频繁用到，要么根本就对性能不甚敏感。 这些要求需要开发人员在需求界定阶段和客户进行妥善分析，让客户知道投资在这些 性能上的代价和可能带来的好处之间的得失大小。一般采取制作一张优先度和重要度 的二维矩阵表格，将每个性能要求逐一填到相应的象限中。最后排出一个顺序，对于 那些位置靠后的，开发成本却又较大的性能要求项目，应该舍弃或延期开发。这些性 能使工作量更加庞大，费用急剧增加，但在实践中又未能给客户和维护人员带来任何 帮助。这样的提议需要是中肯的，经得起推敲的，并最终能有利于双方的。 通常要特别注意以下的这些性能要求： 1 即时响应时间。过剩的即时响应时间是不必要的，根据使用场合和使用频率来确 定响应时间才是明智的。否则会导致系统负荷过重，吃力不讨好。 2 极度的精确性。比如一个日常的m i s 系统，不需要象实时系统那样的准确陛要求。 3 人工智能。诸如自然语言输入，语音理解，数据模式识别等。纯朴的，人性化的， 又兼具灵活性的性能往往才是客户的希望。 4 大量花哨的界面。这些会耗费巨大，但有时只是徒然增加使人迷惑的显示方式而 已。 总之，对于任何软件产品的性能和功能特征，要评价它对系统效率的贡献及对产 品开发成本的占用程度。在软件项目存在的性能成本收益关系大致可以用下图2 4 表示。那些斜率趋平的功能特征就是最需要慎重考虑的，它们往往投入巨大却收效甚 微。如果碰到这些处于软件产品成本的收益递减阶段的功能特征，就应该和客户进行 妥善的磋商，尽量将它们排除，这样做既能降低开发的风险，又能获得客户的信任。 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 2 2 2 规模不经济 图2 4 软件产品性能和成本收益的关系 经济学中把在更大规模中的生产率降低称为规模不经济。较大的软件项目容易出 现规模不经济，其主要原因如下： 1 为了能支持更多程序员并行工作，需要编制详细的单元级的完整说明书，这使得 相对需要进行更多的产品设计。 2 需要相对更多的工作量来验证与确认更多的需求和设计说明书。 3 在较大项目中，程序员即使拿到了充分的说明书，仍然需要花费相对多的时间进 行交流和解决接口问题。 4 需要相对较多的单元集成活动。 5 需要更多的广泛的集成级测试。 6 管理项目需要更多的工作量。往往随着管理幅度的增加而指数级增加。 对日开发软件一般是在严格约束条件下运行，客户要求的产品往往是运行在一个 已经使用过多年的硬件，软件，规则和操作过程的成熟的系统中。项目通常需要花费 0 3 2 0 2 5 2 9 5 李军风险管理在软件开发中的应用 更多的工作量来适应变更和修改。这些因素也造成了大型项目较低的生产率，也导致 较大的规模不经济。 而且，一旦完成需求分析和设计，项目规模越大，就越是要投入一个庞大的程序 员小组，并行地进行详细设计，编码和单元测试。否则，项目将要多花很长的时间才 能完成。这在客户方一般是不希望也不能接受的。因为如果开发期限过长，会使产品 可能需要承受更多的变更，或者，交货时产品早就过时了。当然，大量投入开发人员 的这种策略会造成一个问题：项目投入的人员曲线存在更大的峰值，也消耗更多的工 作量。空的时候大家没活干，忙的时候大家加班加点。这些都是由于软件规模过大， 造成人员投入的波峰波谷波动过大造成的。软件企业的很多成本耗费在这种波峰波谷 无法正常填平所耗费的多余成本上的。 应对这种规模不经济的方法最好是：选择核心功能优先开发，选择螺旋形开发周 期，以避免最终产品和客户的初衷不一致。并且适当地通过去掉某些功能，或者将某 些功能的开发推迟到以后的某个时候，分批分次地来实现，降低开发规模，又降低开 发成本，避免饱一顿饿一顿的现象。 2 2 3 移植开发改造开发的影响因子 在实际开发中，许多软件产品都是由新开发的部分，加上以前开发的但需要经过 修改才能用于新产品中的那些部分组成。这些程序的工作量计算，一般是以移植或改 造后的新加入程序量来计算。但是。我们不能忽略，在许多情况下，他们会需要花费 很多的工作量用于： 1 重新设计这些要进行改造的软件，以满足新的要求。 2 改写部分原来的代码，以适应重新设计的特点或新产品环境的变化。 3 将改造，移植而来的代码集成到新环境中去，需要进行测试最终得到软件产品。 一般很容易低估改造工作量的成本，客户也会偏向于强调开发难易度的降低，并 抬高代码重用比率来为压低估算做铺垫。开发人员所掌握的信息很多来自客户方，只 知道有可用来移植的对象物，但并不清楚该对象物的内在品质。所以在进行改造估算 时，建议参考两个一般性指导原则： 1 开发人员要格外谨慎，防止被表面的可移植论断所迷惑。 2 可选取现有软件的一小部分具有代表性的组件，详细了解它的内部功能。很多时 候我们会发现很多复杂因素和副作用的因素。 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 2 3 需求管理过程 需求管理过程的目的是和客户建立一种共同的理解，一起遵循按照客户需求开发 软件项目的规则。需求管理包括就软件项目的需求同客户建立一个协议并加以管理。 该协议称为“指定给软件的系统需求”。该协议包括技术需求和非技术需求( 例如交 付日期) 两个方面。协议是在整个软件生命周期中估算、计划、执行和跟踪软件项目 活动的基础。需求管理的重要性就是合同的重要性。它是开发方切实维护自己利益和 客户利益的重要手段。通过需求管理，可以控制项目的系统需求，为软件工程和管理 应用建立基线。并且，保持软件计划、产品和活动与项目的系统需求一致。 因为在需求变更状态不明确和难以下决定的时候，需求管理可以减小变更带来的 混乱。我相信很多开发组织都可以使用正式的需求变更控制。好处之一是可以使变更 带来的影响达到最小化，另外一个好处是变更可以使相关的人尽快响应。如果一个需 求管理过程不是很好，那么很多人都要浪费大量的时间。 需求管理过程的执行需要首先向客户明确以下前提，并保证组织内外资源的到 位： 在项目的生命过程中，对每个项目的需求分析必须以文档形式管理及分配。 需求要包括技术需求和非技术需求。 为管理给定需求提供了充足的资源或资金。 需求一定要有文档依据，口说无凭。这在对日开发过程中是很重要的。特别在会 议，电话等场合一定要有议事录并得到参与方的承认才可生效。 需求必须包括： 1 影响和决定软件项目活动的非技术需求。例如，协议、条件和合同条款。 实例有： 要交付的产品 交货日期 里程碑日期 2 软件的技术需求。 实例有： 最终综合功能 性能需求 运行约束条件 程序设计语言，平台，环境 界面需求 3 用于确认软件产品是否满足给定需求的验收标准。 需求管理必须找到在软件工程领域有经验和专长的人员来管理。需求管理的后续 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 经常伴随的是一个痛苦的交涉过程，牵涉到预算，成本，外部压力，内部抱怨等，一 般在对日项目开发中，多由项目经理或项目经理来直接管理需求。而且，最好还能有 可供使用的支持管理需求的工具。普遍使用的是制表软件。用一张管理台帐来进行统 一管理，定期发送给客户进行确认。 需求管理必须包括以下基本内容： 1 项目组在进入软件项目之前要评审给定需求。 1 ) 确定有无不完整或遗漏的给定需求。 2 ) 评审给定需求以确定它们是否： 可行、能实现 清楚、适当 彼此一致 可以测试 3 ) 对可能有问题的需求进行反馈，由需求界定人员进行必要的修改。 2 项目组将给定需求作为软件开发计划、工作产品和活动的基础。 对需求进行版本控制，在一定时间内所使用工作产品的版本是明确的，也就是要 有基线管理，并以可受控的方式进行修改，更改的履历都要记录并可以追踪。 3 评审给定需求的更改，并合并到软件项目中。 1 ) 评估对现有开发的影响，和客户或内部其他小组协商后对开发计划进行适当更改。 2 ) 对给定需求的更改引起的软件计划，工作产品和活动的必要更改，并且特别就更 改的需求可能带来的风险重新进行： 识别 评估 计划 通知相关小组和个人 跟踪到结束 归档 2 4 估算及计划过程 估算及计划过程的目的是为实施和管理软件项目制定合理的计划，包括对要完成 的工作进行估算、确定必要的约定和制定工作计划。这个计划为实施和管理软件项目 活动提供基础，并根据软件项目资源、约束条件和能力向软件项目的客户提出承诺。 软件计划制定步骤包括：估计软件工作产品及其资源的需求规模、制定进度计划、 识别与评估软件风险以及协商有关事前约定等。为建立软件开发计划，有时可能需要 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 反复这些步骤。 2 4 1 估算的意义 随着需求逐渐变得清晰，软件开发方和客户方都想得到一个对开发成本和开发时 间适度准确的“估算”。 估算特别重要，因为它用项目需要的资源以及资源可以使用的时间这两个数量确 定了项目的“边界”。它还以成本和满足完成日期的能力的方式确定了一个项目是否 被认为是可行的。在软件开发项目由外部供应商承担的时候，估算成了软件开发方和 客户方之间合同的基础。这个合同规定了供应商交付什么，何时交付，客户要付多少 钱。许多合同还因为延期交货或质量不好而规定了违约条款等。 软件开发方要能够以项目交付时间和总成本的形式向客户报价。不恰当的估算会 给软件开发方和客户方双方带来各种问题，例如： 1 在估算过高的情况下，投标的软件开发方可能因竞争对手估算得更准确，报价更 低而失去这个项目。 2 在估算过低的情况下，软件开发方将会遭受损失还会延期交付。这种延迟可能招 致与客户的不和，并可能招来处罚。 2 4 2 估算存在的问题 然而实际的估算过程，在运用中却经常出现尴尬，有很多复杂的因素纠缠在估算 过程中。估算的问题在于，项目经理在设计完成前就试图量化成本，工作量和交付日 期。为了报价所做的估算通常都是基于非常粗略的需求定义。很多日本客户也喜欢在 需求只达到一个粗略状态的时候就要求供应商报价。这更加剧了估算的难度。甚至在 出现竞争对手的时候，估算成了一个形式，关心的问题变成了客户到底有多少预算。 显然，这和估算本身的科学性背道而驰。当然更多的估算还是确实的从开发过程和技 术角度考虑过的。许多估算都是错误的( 通常是较低) ，并因此没有得到足够的资源 和足够的时间。因为对项目的了解不够充分，时间太紧，以及各种直接或间接的为了 达到一个“可接受”的估算结果而施加在估算者身上的压力，使得估算通常是很痛苦 的。 存在于对日软件开发的估算过程中的问题主要有以下原因： 1 不现实的估算。估算常常是由客户愿意支付的价格以及竞争对手的报价所决定。 2 没有时间做估算。准备报价和做出估算通常是在一种匆忙的状态下进行的。这迫 使估算者跳过详细过程而草率的进行假设，并进而导致粗略的不正确的估算。事 0 3 2 0 2 5 2 9 5 李军 风险管理在软件开发中的应用 后，人们会认识到没有充足的时间和资源准备估算并评审估算结果是很不明智的。 3 不完整或不正确的需求。估算过程的第一步是把需求转化为规模估算。如果需求 就不准确或被遗漏，估算就不会准确。这也反映了为什么要在开始估算前确保需 求的准确和完整的重要性。 4 没有过去的历史数据可用。估算不仅基于需求，还应该基于过去的关于生产率的 数据以及影响生产率的因素。很多企业历史短根本没有经验数据的积累，有些虽 然积累了一些数据但没有注意到不同项目在生产率上有相当大的差异，从而都会 使估算碰到障碍。 5 包括客户，管理层，开发人员，都错误认为生产率和软件规模无关。 6 客户和管理层经常不假思索地认为生产率与被施加的进度无关。4 个人做6 个月 的项目，如果要压缩至3 个月，那就投入8 个人对付。人员数量和时间是不可以 互换。如果工期压缩一半，这个项目的工