软件项目的风险分析报告

1、 软件工程的风险分析 软件工程工程的开发也存在各种各样的风险,有些风险甚至是灾难性的.R.CharetteR.Charette 认为,风险与将要发生的事情有关,它涉及诸如思想、观念、行为、地点、时间等多种因素；风险随条件的变化而改变,人们改变、 选择、 限制与风险密切相关的条件可以减少风险,但改变、 选择、 限制条件的策略往往是不确定的.在软件开发过程中,人们关心的问题是,什么风险会导致软件工程的彻底失败顾客需求、开发环境、目标机、时间、本钱的改变对软件工程的风险会产生什么影响人们必须抓住什么时机、 采取什么举措才能有效地减少风险、顺利完成任务所有这些问题都是软件开发过程中不可预防并需要妥善处

2、理的.软件工程的风险分析包括：风险标识、风险估算、风险评价和风险治理四局部 1 1、风险标识 从宏观上看,风险可以分为工程风险、技术风险和商业风险三类.由于工程在预算、进度、人力、资源、顾客和需求等方面的原因对软件工程产生的不良影响称为工程风险.软件在设计、 实现、 接口、验证和维护过程中可能发生的潜在问题,如规格说明的二义性、 采用陈旧或尚不成熟的技术等等,对软件工程带来的危害称技术风险.开发了一个没人需要的优质软件,或推销部门不知如何销售这一软件产品,或开发的产品不符合公司的产品销售战略,等等,称为商业 风险.这些风险有些是可以预料的,有些是很难预料的.为了帮助工程治理人员、工程规划人员全

3、面了解软件开发过程存在的风险,BoehmBoehm 建议设计并使用各类风险检测表标识各种风险. 2 2、风险估算 软件工程治理人员可以从影响风险的因素和风险发生后带来的损失两方面来度量风险.为了对各种风险进行估算,必须建立风险度量指标体系；必须指明各种风险带来的后果和损失；必须估算风险对软件工程及软件产品的影响；必须给由风险估算的定量结果. 3 3、风险评价和治理 在风险分析过程中,经常使用三元组RI,LI,XIRI,LI,XI描述风险.其中 RIRI 代表风险,LILI 表示风险发生的概率,XIXI 是风险带来的影响,I=1,2,I=1,2,L L 是风险序号,表示软件工程共有L L 种风险

4、.软件开发过程中,由于工程超支、 进度拖延和软件性能下降都会导致软件工程的终止,因此多数软件工程的风险分析都需要给由本钱、 进度和性能三种典型的风险参考量.当软件工程的风险参考量到达或超过某一临界点时,软件项目将被迫终止.在软件开发过程中,本钱、进度、性能是相互关联的.例如,工程投入本钱的增长应与进度相匹配,当工程投入的本钱与工程拖延的时间超过某一临界点时,工程也应该终止进行.通常风险估算过程可分为 四步：定义工程的风险参考量；定义每种风险的三元组RI,LI,XIRI,LI,XI; ;定义工程被迫终止的临界点；预测几种风险组合对参考量的综合影响. 三元组RI,LI,XIRI,LI,XI是风险治

5、理的根底.设高级职员流动给工程带来的风险为 RoRo 根据历史的经验或直观感觉,高级职员离开课题组的概率：LILI=70%=70%.这一事件的由现带来的影响 XIXI 是工程开发时间延长 15%,15%,工程本钱增加 20%20%o o 于是工程负责人可以采取以下风险治理举措： 高性能：cutcon】e=550,000 (1)(1)工程开始以前应限制产生风险的原因,在工程开工后应 想方设法减轻风险影响. (2)(2)了解导致工程开发人员变动的原因,在工程开发期间应限制上述原因,尽量减少人员的流动. (3)(3)在工作方法和技术上应采取适当举措,预防因人员流动给工作带来损失. (4)(4)工程在

6、开发过程中应及时公布并交流工程开发的信息. (5)(5)建立组织机构,确定文档标准,并及时生成文档. (6)(6)对工作进行集体复审,使多数人都能了解工作的细节, 跟上工作进度. (7)(7)为关键技术准备后备人员. 软件工程,尤其是大型工程有二项非常重要的因素,会 影响整个工程的进度与质量,它们分别是：“人、“流程与“技术. “人是工程中最难预料与掌控的一项要素,人可分成两部 份,一是客户,二是开发团队. “技术是指软件工程所使用的开发半台,主要指开发环境及开发语言.是最容易掌握的部份. “流程是指软件开发流程或是工程流程,定义流程的目的是要掌控所有的情况.工程的最大敌人是时间及预算,这两者

7、都是有限的,如何在有限预算内准时完成工程,可说是一项艺术. “人因素分析 “人是指客户和开发团队,其中开发团队的因素对项目影响很大,对于这方面影响因素主要分析如下： 人员技能未到达要求 在工程开始之初,我们假设工程成员都能够到达组织级的要求,但往往并不是每个成员都能够到达要求.而且工程中每个成员的生产率差异可能很大,也给工程进度安排造成影响.所以在工程始之初,应该对工程成员的技能进行一次总体的评估,对于大家都欠缺的技能,应该安排统一的培训,后续需要对培训的效果进行跟踪；对于个别人员技能欠缺的,应该单独预留自我学习时间或通过以师带徒的方式进行培养,使其技能能够尽快到达要求： 对于工程新员的工作和

8、任务,应该增强评审和检查,保证输由不由现大的偏差而导致后续大量的返工.对于这方影响因素主要分析如下： ,工程成员责任心不强 态度决定一切,细节决定成败.对于工程过程中的各项任务,经常由现由于工程成员责任心不强敷衍了事,导致产生的工件质量较差,引起大量返工的情况.在这种情况下,工程更应该增强工程标准的建设,工程经理应增强同这些成员的单独沟通,增强工程的团队建设和集体荣誉感.让工程成员感觉到做的系统是他们自己的产品,而不是公司的项目,工程经理的工程. 工程沟通问题 在软件工程中,保证工程各种角色和成员中的高效沟通是很重要的,如何建立起快捷顺畅的沟通渠道,采用最正确的沟通方式来解决问题,必须在工程中

9、经常强调.如果一周的工程任务花存实际做事情上有 2 2 天,而花在沟通上却占用了 3 3 天,这时必须及时分析和总结原因.沟通最重要的就是要在最短的时间里面,采用各种方法或工具,使交流双方或多方达成一致. 工程人员流失 工程人员特别是工程关键成员在工程进行过程中的流失,对工程影响很大,对于这种情况,应该在工程开始之初,就作为专门的风险进行跟踪,并考虑具体的应对举措. “流程因素分析 软件的开发流程般定义为：需求分析一可行性分析一概要设计一结构化设计一详细设计一编码一软件测试一软件维护. “流程中软件工程的风险,主要表达存 4 4 个阶段：软 件需求阶段、软件设计阶段、软件实现阶段和软件维护阶段

10、 软件需求阶段 软件的开发是以用户的需求开始,在大多数情况下,用户需求要靠软件开发方诱导,才能保证需求的完整,再以的形式形成?用户需求?这一重要的文档.需求分析更多的是开发方确认需求的可行性和一致性的过程,在此阶段需要和用户进行广泛的交流和确认.需求和需求分析的任何疏漏造成的损失,会在软件系统的后续阶段被一级级地放大,因此本阶段的风险最大. 软件设计阶段 设计的主要目的在于软件功能正确地反映了需求,需求的不完整和对需求分析的不完整或者错误,在设计阶段将被成倍地放大.设计阶段的主要任务是完成系统体系结构的定义,使之能够完成需求阶段的即定目标；另一方面也是检验需求的致性和需求分析的完整性和正确性.

11、 设计阶段的风险主要来自于系统分析人员.分析人员存设计系统结构时过于定制,系统的可扩展性较弱,会给后期维护带来巨大的负担和维护本钱的激增.对用户来说系统的使用比例会有明显的折扣,甚至会造成软件寿命过短.反之,软件结构的过于灵活和通用,必然引起软件实现的难度增加,系统的复杂度上升,可靠性降低,给实现和测试阶段带来风险,系统的稳定性也会受到影响.从另一个角度上看,用户需求和将来软件运行环境的变化都是必然的,目前软件设计的所渭的“通用性是否就能很好的适应将来需求和运行环境的变化,都是需要认真折衷的,而这种折中也蕴涵着很大的风险. 设计阶段蕴涵的另一种风险来自于设计文档.文档的不健全不仅会造成实现阶段

12、的困难,更会在后期的测试和维护造成灾难性的后果,例如根本无法对软件系统进行版本级,甚至是发现的简单错误都无从更正. 软件实现阶段 软件的实现从莫种意义上讲是软件代码的生产.源代码木身也是文档的一局部,同时它又是将来运行于计算机系统之上的实体.源代码书的标准性,可读性是该阶段的主要风险来源.标准的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到最低限度,从而减小了系统整合的风险. 软件维护阶段 软件维护包含两个主要的维护阶段,一个是软件生产完 毕到软件试运行阶段的维护,这个阶段是一种实环境的测试 性维护,其主要目的是发现在测试环境中不能或末发现的问 图1 “技术因素分析 存软件工程开发

13、和建设的过程中,技术因素是一个非常 重要的因素.工程组一定要本着工程的实际要求,选用适宜、 成熟的技术,千万不要无视工程的实际情况选用一些虽然先进但并非工程所必须且自己又不熟悉的技术.如果工程所要求的技术工程成员不具备或掌握不够,那么需要重点关注该风险因素. 建立工程治理流程 那么如何解决这些问题,实际上很多模型已经给由了答案,比方 RUPRUP、QoSQoS、XPXP 等,但是大家在学习和使用这些模型的时候,往往觉得这些模型提由的概念和实施比拟难以操作,另外就是不管是 RUPRUP、Q0sQ0s 还是 XP,XP,既然是一个方法模型,就不可预防要描述为一个完整的、系统化的理论模型,否那么就表

14、达不由理论的完整和逻辑的严谨.下面我们只是把以软件设计为核心的开发治理流程化,预防在频繁发生外界变化的情况下,变被动为主动. 软件工程治理除了根据既定的治理流程进行有效的控 制,还要对各阶段的文档进行标准化治理,保证文档的完整和标准化,为软件后期的维护提供有力的支持. 排 序 输入 风险事件 可能 性 影响 风险 值 采取的举措 1 客户的 需求不明确,增 70% 50% 35% 请专业需求分析师和客户代表具体 sow 加需求,导致需 求蔓延. 深入细节的交谈,多了解客户的想 法,站在客户的角度上思考问题. 2 合同 进度要求紧,合 同金额和日期 有限. 30% 50% 15% 可以请一些实习

15、的学生做辅助工 作,一来降低本钱,二来可以加快 进度. 3 历史项 目信息 开发人员对测 试工作不重视 30% 40% 12% 1)强制性要求每段代码保存测试单 元,由 SQA 检查. 4 WBS 对需求的开放式系统标准没有适宜的测试案例 20% 80% 16% 找专业的测试公司完成测试工作 5 历史项 目信息 开发人员的流 动 15% 60% 9% 1) 注意工程团队的沟通,及时 了解开发人员的动态. 2) 限制好工程过程中的文档 3) 从其它的工程组解调人员 4) 从外部招聘有过此类开发经 验人员 6 系统设 计评审 没有足够的时 间进行产品测 试 50% 50% 25% 1) 采取加班的方法 2) 修改方案去掉一些任务 3) 与客户商量延长一些时间 7 需求和 方案 米用新技术可 能导致进度的 延期 50% 30% 15% 1) 培训开发人员 2) 找专家作指导 3) 采取边开发