计划书风险分析写法.docx

《计划书风险分析写法.docx》由会员分享，可在线阅读，更多相关《计划书风险分析写法.docx（21页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、商业计划书风险分析写法资源（原材料/供应商）风险 市场不确定性风险市场研发风险四 五八 七生产不确定性风险成本控制风险市场竞争风险政策变化风险八.财务风险（应收帐款/坏帐）九.管理风险（含人事/人员流动/ 关键雇员依赖）十. 破产风险1、引言由于软件项目的研制需要开辟新的技术，或者使用许多已经过验证的技术和产品， 但产品生产数目普通较少，这些技术和加工工艺不容易达到成熟或者定型的程度。且 大型项目的研制需要长期大规模的组织、指挥协调工作，以及漫长的研制周期等，都会带来 种种难以预见的不确定性因素。这些不确定因素的存在使得软件项目能否按照预定的计 划一一费用、进度和性能完成研制任务往往难以预料，

2、不可能做到研制彻底成功，存在 着失败的风险。所以在项目研制的可行性分析和方案认证时，加强方案风险分析是十分 必要的。对风险的研究自七十年代末开始，其应用的风险分析方法与可靠性分析方法类似， 或者在此基础上进行扩充。目前，在风险研究方面，比较著名的方法有GERT （图解评 审技术），VERT （风险评审技术），RSINET （风险信息系统与网络评审技术）和 SLAM（多功能构摹仿真语言）等。GERT的基本特点是可以直接对网络模型进行计算机仿真 对项目产生影响的潜在的风险事件 是离散发生的，如自然灾害或者项目 队伍的某一成员离开。除了那些发 生可能性及造成的损失量都相对教 大的 风险来源以外还必须

3、对潜在的 风险 事件子细识别。在应用领域中, 普通的风险事件检查表是具体明确 的，而 潜在的风险很少 能明确描述, 例如：潜在风险的描述对潜在风险的描述应包括以下的估 替 风险征兆 风险征兆，有时也称触发器，是实际 风险事件的非直接证明。如：士气低 落可能是进度计划延误逼近的早期 预警信号；早期活动的成本超支则可 能是估计不正确的结果。风险量化创业的意义为社会创造价值一份属于自己的事业 改变自己的生活状况 展示自己的才华创业准备激情与理智立项与完整的计划资金风险及对策良好的心态：胜固欣然，败亦可喜!4 个 95%95%的失败不是由于项目本身，而是由于创业者 缺乏计划性、严密性、系统性95%的人

4、并非缺钱，而是缺少良好的资金运作， 从而导致资金链断裂95%的项目不是运作不下去，而是做项目的人没 有 坚持下去，缺少坚持到底的精神95%的项目在运作一段时间后彻底偏离了当初 的项 目计划与设想，彻底走样了四个动作拍脑门 拍胸脯 拍大腿 拍屁股有效计划的方法，戴明环，PDCA循环Pplan 计戈UDdo执行check检查Aaction 行动周而复始、大环带动小环、阶梯式上升 项目计划书八部曲 风险财务风险及对策 技术风险及对策 管理风险及防范 市场风险及防范 人材风险能力风险 市场分析品牌竞争策略组织与人力资源SOWT分析企业发展的四个阶段四个时期相应的人力资源策略人力资源的风险管理人力资源管

5、理中的风险管理是指在招聘、工作分析、职业计划、绩效考评、工作评估、 薪金管理、福利、员工培训、员工管理等各个环节中进行风险管理，防范人力资源管理中的风险发生。在进行人力资源管理时，我们往往重视招聘、培训、考评、薪资等各个具体内容的操 作，而忽视了其中的风险管理问题。其实，每一个企业在人事管理中都可能遇到风险，如招聘失败、新政策引起员工不满、技术骨干蓦地离职 等等，这些事件会影响公司的正常运转，甚至会对公司造成致命的打击。如何防范这些风险的发生，是我们应该研究的问题。特殊是高新技术 企业，由于对人的依赖更大，所以更需要重视人力资源管理中的风险管理。风险分类普通我们可以按人力资源管理中的各环节对风

6、险进行分类，如招聘风险、绩效考评风 险、工作评估风险、薪金管理风险、员工培训风险、员工管理风险等等。对高新技术企业来讲，招聘风险、绩效考评风险、薪金管理风险、 员工管理风险等显得更为重要。此外我们也可从已知风险、可预知风险、不可预知风险的角度对风险进行分类。对于 已知风险和可预知风险我们要采取积极地措施进行防范。风险识别要想防范风险，首先要进行风险识别。识别风险就是主动地去寻觅风险。比如员工管 理中，技术骨干离职风险可能会由以下几个方面产生1、待遇：他是否对他的待遇满意？2、工作成就感：他是否有工作成就感？3、自我发展：他是否在工作中提高了自己的能力？4、人际关系：他在公司是否有良好的人际关系

7、？5、公平感：他是否感到公司对他与别人是公平的？6、地位：他是否认为他在公司的地位与他对公司的贡献成正比？7、信心：他是否对公司的发展和个人在公司的发展充满了信心?8、沟通：他是否有机会与大家沟通、交流?9、关心：他是否能得到公司和员工的关心？10、认同：他是否认同企业的管理方式、企业文化、发展战略？11、其他：他是否有可能因为结婚、出国留学、继续深造等原因离职？人事经理要认真了解客观情况，对可能发生的风险进行有效识别，这是防范风险的第 一步。风险评估风险评估是对风险可能造成的灾害进行分析。主要通过以下几个步骤进行评估：1、根据风险识别的类型有针对性的进行调研；2、根据调研结果和经验，预测发生

8、的可能性，并用百分比表示发生可能性的程度；3、根据程度排定优先队列。比如说，人事经理可以通过与当事人交谈、发调查表等形式进行调研，并根据调研结 果和经验，确定该员工在各风险识别条目中离职的可能性。结果如下：(1) 10%(2) 20% (3) 10%(4) 0%(5) 50% (6) 20% (7) 0%(8) 30% (9) 0%(10) 0%(11) 0%。优先队列是：（5）、（8）、（2）、（6）、（1）、（3）、（4）、（7）、（9）、（10）、（1 1 ） o人事经理可以发现，该员工对公平、沟通较为不满，由于公平问题而离职的可能性最 大，其次是沟通问题。风险驾驭风险驾驭是解决风险评估

9、中发现的问题，从而消除预知风险。它普通由以下几个步骤 构成：1、针对预知风险进行进一步调研；2、根据调研结果，草拟消除风险方案；3、将该方案与相关人员讨论，并报上级批准；4、实施该方案。人事经理可针对公平问题和沟通问题，进行专项交谈或者调查，找出问题的根源，并 草拟相应的方案。如解决公平问题的方案如下：1、在制定公司规章制度时，广泛征求员工的意见；（通过调查发现，由于没有参预制度的制定，误认为制度本身不公平）2、向各部门发放公司制度合订本，方便员工了解公司制度；（通过调查发现，由于对某些制度的细节不很清晰，误以为制度执行不公平）3、将工资晋升标准公开，使工资晋升透明化；（通过调查发现，由于公司

10、工资晋升标准不明确，容易产生待遇不公平感）4、增加部门间交流；（通过调查发现，误认为其他部门工作轻松，而自己是最辛苦的，也容易产生不公平 感）人事经理可以将上述建议与大家讨论，最后由办公例会或者总经理批准通过。通过上述方案的实施，可能会增加大家的公平感，具体效果如何，还要进行调查得出 结论。风险监控当旧的风险消除后，可能又会浮现新的风险，所以风险识别、风险评估、风险驾驭这 几个环节要连续不断的进行下去，形成有效的监控机制。在一段时间以后，要对风险进行再分析，确保对风险制定的驾驭方案能够切实有效的 进行。并且要对执行中的问题进行再评估。此外要注意总结经验，为将来的风险 管理提供数据。规避项目资源

11、风险的几点建议、项目风险发生的根源极少听见有项目主管说他的项目没有任何风险而一切尽在掌握。对于一个项目来讲，风 险的浮现非往往见，把所有风险都拒之门外几乎没有可能，你几乎没有可能完美的解决“工 期”、“资源”、“质量”三者的天生的冲突，这些导致项目不可能彻底在规定的时间内、按规 定的预算由规定的人员完成。这是因为项目计划和预算本质上只是一种预测，在执行过程中 与实际情况肯定会有差异，这些预测和实际情况的差异性，就为项目各种各样的风险埋下了 伏笔。经过一些项目实践，我总结出项目风险产生的原因主要有以下几条。1 .项目计划中对风险管理没有引起足够的重视，导致风险发生以后手足无措。2 .轻蔑前期需求

12、工作，导致项目实际产品与客户预期的差别较大。3 .项目过程中过渡轻蔑文档管理，导致风险发生以后要末无据可依（通常指需求发生 变更以后，发现当初需求文档不完善），要末后继无人（通常是一些设计类文档，在人员发 生变动的时候，其它人看不懂文档，无法接手工作）。4 .轻蔑质量控制，导致主管得到的信息与实际差距较大，不能清晰的及时判断出真正 的风险是否已经发生。在项目运作过程中，如果只靠员工的报告来掌握项目发展是不够的。 事实上，员工都愿意报喜不报忧，在项目初期就浮现的问题苗头，如果不能传递上来，将在 后续阶段造成大更大的维漏。缺乏质量控制机制，也就是缺乏有效的“监督”人员来制约，是 造成这种情况的主要

13、原因。5 .轻蔑架构和概要设计。普通项目时间紧、资源有限，这样一些项目管理者在缺乏对 系统架构和其它技术方面的设计缺乏有效的论证的前提下，就凭借着经验匆匆启动项目，很 可能导致以后一旦因为客户需求变化等因素对整个系统的架构产生影响，导致系统大量的修 改。以前就我曾经经历过这种事情，简直让人崩溃。6 .缺乏积极的应对风险的措施。实际上，项目发生风险非常正常，不少风险甚至可以 预料是肯定会发生的，一旦比较大的风险发生，会直接对项目组每一个成员产生一些负面影响, 分析，其模型元素与相应的分析程序相配合，可以用来描述复杂的排队系统、项目管理 及生产线方面的问题，应用十分简便、灵便，而对时间、费用、性能

14、方面的问题不太适 合；SLAM是一种以FORTRAN为基础的构摹仿真语言，可进行离散网络、连续系统 及离散事件的综合仿真，能适应多种构模需要，但提供资源模块有限，仿真不能进行全 过程支持，不能支持图形建模等不足；VERT可处理时间、费用、性能等关键性风险参 数，能对多目标优化，具有较大的实用价值。在这些风险方法中，VERT对于时间、费 用和性能三个指标在处理水平上平等对待，既可独立地进行并行处理，也可通过数学关 系式而相互联系起来进行处理；节点的逻辑功能丰富，活动上的三项指标都可用一定的 概率分布、直方图或者数学关系式来描述，于是VERT网络模型比较接近实际系统的要求; VERT对于费用和性能

15、这二项指标，可按用户的需要灵便地加以应用。2、风险分析的概念风险的定义是：对目前所采取的行动，在未来没有达到预期结果（失败）的可能性。 其大小可用失败的概率和失败的后果两个变量来标识。风险分析有狭义和广义两种，狭义的风险分析是指通过定量分析的方法给出完成任 务所需的费用、进度、性能三个随机变量的可实现值的概率分布。而广义的风险分析则 是一种识别和测算风险，开辟、选择和管理方案来解决这些风险的有组织的手段。它包 括风险识别、风险评估和风险管理三方面的内容。本文中论及风险分析时，都采用后一 种定义。风险识别是指确定哪些可能导致费用超支、进度推迟或者性能降低的潜在问题，并 定性分析其后果。在这一步须

16、作的工作是分析系统的技术薄弱环节及不确定性较大之 处，得出系统的风险源，并将这些风险源组合成一格式文件供以后的分析参考。它属 于定性分析的范围。风险评估是指对潜在问题可能导致的风险及其后果实行量化，并 确定其严重程度。这其中可能牵涉到多种模型的综合应用，最后得到系统风险的综合 印象。而风险管理则是指在风险识别及风险分析的基础上采取各种措施来减小风险及 对风险实施监控。这也可以说是风险分析的最终目的。作为对风险概念的进一步界定，本文将简单介绍风险中的两种不同类型及风险分析 与可靠性分析的区别。2.1、 系统运行及项目研制风险第一类风险是系统运行风险。指当一部份系统运行时，由于种种不确定性因素或者

17、 系统本身硬件或者组元的失效而造成预定任务的完成不确定性以及由此而带来的系统 设备此时不少项目管理者不能以积极的态度应对，而是自乱了阵脚，很可能导致项目计划频繁变 更，项目节奏感被打乱并且逐渐开始失控。二、解决措施任何问题，如果找到了真正原因，其实已经向解决问题迈进了一大步。针对以上风险发 生的原因，我们可以采取以下一些策略来降低风险带来的损失甚至规避大多数风险。在项目计划中重视风险的评估不少项目主管在项目启动的时候认为既然团队已经建立好了，项目计划已经制定好了， 就可以憧憬着项目成功了。其实没有任何两个项目是一模一样的，任何项目都会有风险的。 在项目初期认真做好风险的评估，并且能让你的项目干

18、系人（特别是项目主管的掌控项目资 源的负责人）清晰这些风险，那末一旦风险发生，也可以更加从容不迫的应对，并且有理由 更好的协调资源，不至于让大家不知所措。要重视需求工作一个好的需求是连接业务层面和技术层面两类人，让他们达成一致的目标的关键，对于 大型的复杂的项目特别重要。好的需求可以很好的控制客户需求变更给项目带来的负面影 响，（不少项目都是这样，不断的需求变更导致不断的修改，如此反复，最后陷入无法自拔 的泥潭），因为客户一旦签字确认以后，这份需求就应该与商业合同一起具备法律效力而对 客户进行必要的约束；此外一份清晰的没有二义性的需求可以让开辟人员非常清晰自己应该 完成什么工作，测试人员很好的

19、编写测试用例，就是这份需求，可以大大降低项目组以后在 沟通、修改方面的成本，提高效率和产品质量。其实大部份人都知道“需求”的重要性，有些人肯定会说：“项目时间和资源有限，怎么 可能化那末多精力专门做需求呢？ 这是一种误区，需求并不一定要长篇累犊、事无具悉， 但是一定要有需求。具体需求怎么写，应该对整个项目做评估以后制定一个策略。比如因为 公司长期从事某方面业务，那末这些就可以写简单点；或者项目时间太紧，那末需求文档的 模版可以根据实际情况做一些必要的简化。不合格的需求，往往会因为当初一时的懒惰而让项目最终付出几倍的惨重代价。需求是 项目的一份纲领性文件，是以后项目路线的指挥棒，好的需求一定能清

20、晰的描述出整个项目： 包括都要做什么以及这些事情的优先级。比如知道优先级以后，项目的管理者就可以根据重 要性、难以程度而因人制宜的分派工作，特别遇到时间特殊紧张的情况下，可以说服客户先 上最重要的系统模块而把一些不重要的放在以后逐渐实施，这样把好钢都用在刀刃上，在资 源等方面受到不少限制的前提下，尽量做到大家的满意，这也为降低日后的风险打下了坚实 的基础。重视项目文档管理让项目主管最痛苦的事情莫过于：当一个重要成员半途离开项目组时，才发现他根本就 没有留下任何可用的文档。特别在IT项目中，人员流动性强，文档就是成员之间交接的重 要工具。但是不少主管很容易陷入“重技术实现，轻文档”的误区，他们总

21、是认为项目实施时 间紧迫，为了节省时间，可以在项目收尾阶段袭击写文档。要是项目周期稍长一点，到了最 后，谁还会清清晰楚记得每一个实现细节呢？如果下一个项目与此类似，以前的劳动成果还 有谁能继承得下来呢？固然，现在越来越多的公司已经注意到了管理好文档的重要性，普通可以借助VSS、 CVS、PVCS等工具来很好的对文档进行版本控制，但是有一点要特殊引起注意：单单关注 文档本身远远不够，还要重视文档的质量！即使是在现在不少管理很规范（比如已经通过了 CMM3、IS09000等认证）的公司，“重过程、轻质量”也是一个突出问题。普通在每一份文 档入基线以前，都要通过评审、同行评审等方式来对文档进行专门的

22、“轰击”以保证文档的有 效性，这些评审小组中如果能包括一些行业、技术方面的专家将时常能达到更好的效果，这 些专家彻底可以从公司外面礼聘。有了完善和有效的文档做基础，能降低不少项目过程中的风险。重视质量过程控制不少人通常认为，在的项目组中最重要的是主管和设计开辟人员，而认为项目中的质量 过程控制没有什么必要。但是在实际项目过程中，单靠研发人员提供的报告来判断项目进程、 确认是否有或者将有风险发生远远不够。因为大部份人喜欢报喜不报忧，而且汇报的内容大 部份只是他本人主管的认知，也缺乏通盘的考虑。越复杂的项目，越需要量化的管理，必须 有一种机制能让管理者真正掌握项目的实际发展情况，最有效的办法就是建

23、立质控部门与实 际的研发部门相互制约，监控测试项目实际情况和实际的问题，而不参预项目的具体实施。作为一个项目管理者，明确这种研发和质控的关系，除了更好的保证项目质量以外，还 能客观的反映项目实际情况，通过这些文档来表明每一个基线、每一个成员的工作量和完成质 量，对识别、预测项目风险意义重大，固然，这些措施也大大降低了项目过程中可能的风 险发生的概率。重视架构和概要设计在IT项目中，编码实施固然重要，但是对于一个比较复杂项目中的项目组来讲，如何 让不同角色的研发人员高效协作，将是更加要紧的问题。设计文档，特别是架构设计就是能够让这些研发资源更加高效协作，降低返工的有效手 段。有了这些设计作为指引

24、，研发人员就可以同步工作，共享公用的资源（比如，经过设计 分析以后，发现客户业务方面有A、B、C三个业务模块，但是其实这三个模块中有几乎50% 在技术实现上是公用的）。在实际设计的操作过程中，可能有时候项目组内部成员儿乎没有 一个有经验，那末最好还是礼聘一些外部的专家来帮忙，我在实际的项目中，发现这个效果 会比较好。有了这些有效的纲领性的技术文件，会在实际开辟过程中大大降低各种潜在的风险。采用积极的应对风险的措施让人遗憾的是，即便我们做了不少的事情来防止风险的发生，通常还会有风险发生。一 旦突如其来的风险发生了，例如：项目组核心成员蓦地病倒，客户组织结构发生调整或者虽 然当初签订了合同确认了需

25、求，但是客户业务调整了，那末我们总不能一意孤行的还是移交 给客户一套其实已经无法运转的系统吧。这些风险一旦发生，逃避不是办法，作为一个项目 主管来说，更加行之有效的办法是带领整个团队，用积极的心态、科学合理的方法来以最小 的代价克服它。固然，这也需要项目组的经验以及项目主管的综合素质来支撑。通常处理风险的过程分为三步走：识别？量化？应对。通过风险识别确定哪些风险可能 影响项目，并把风险归档作为以后过程财富的很好的积累，把产品、历史信息、其它相关信 息作为输入，利用检查表、流程图、面谈等手段，得出风险的来源、征兆等结论；风险量化 是指评价风险和它们之间的相互作用，从而评估项目可能结果的大概范围。

26、如果你想启动风 险量化过程，那末你需要首先知道这些风险的来源，量化是一项比较复杂的活动，除了采取 货币、时间等来衡量以外，最好借助专家的判断。有了比较量化的结果以后，项目主管就能 清晰的意识到风险的严重性，从而做出更加贴切的应对措施；有了以上的结果以后，就可以 制定风险应对措施来制定应对措施了。总之，知道了项目风险的原因和应对措施，对项目的顺利进行有非常重要的意义，不少 情况下，能否很好的处理好项目的风险会成为项目成败的关键，这种处理突发风险的能力也 成为衡量一个项目主管人员重要指标。的损坏或者人员的伤亡。这种风险由于其明显的危害性及影响性，目前进行研究得较多, 有代表性的如大型航天软件的运行

27、风险管理。已经发展成熟的分析方法有如FMECA（失 效模式与效应分析）、FTA （故障树分析）、ETA （事件树分析）及事件树/故障树分析 量化基础上的PRA （风险概率评估）和DPRA （动态概率风险评估）等。第二类风险是项目研制风险，这也是本文的主要研究范围。它是指大型项目研制开 发过程中，由于技术的难以保证、管理的不得力及经费的迟延导致研制出的系统性能降 低、费用超标、进度延迟等。这种风险由于其危害呈隐性，目前进行研究得较少。项目 研制风险普通包括技术风险、进度风险及费用风险。两类风险的不同之处在于，对于系统运行风险，系统已经存在，因对其分析必须从 单个硬件或者主元的失效及其综合影响上考

28、虑。而作为项目研制风险，由于并无一确定 的系统，系统研制成功本身便是研制任务的状态之一，这决定了它的分析方法与上述不 同，不能针对硬件分析，而须从事件的角度上进行考察。两类风险的另一个不同之处 在于项目风险的非刚性。所谓非刚性是指当风险源导致风险发生以后，造成的后果可 以修复。2.2、 系统运行风险与可靠性系统运行风险与可靠性分析是两个极易混淆的概念，它们都是指对于某种工艺过程 或者设备的失效或者运行状态的研究。但其分析的目的却有所不同，有必要在此作一简 单的区分。可靠性的定义是系统在一定时间内能够完成规定任务的概率。其研究的范畴在于系 统硬件或者组元的耐用程度，研究的最后结果是系统整体失效随

29、时间而变化的可能性。 而系统运行风险则是研究这种失败可能对社会造成的危害，其最后结果是造成的系统 设备损坏的或者人员伤亡的期望值。3、风险种类对软件项目的管理部门来说，在做出与规定费用按规定时间交付规定产品或者达到 规定性能水平的决断时，风险是永远存在的。软件项目管理部门因风险而导致工作失 败有三种方式：产品达不到规定的性能水平、实际费用过高、交付过迟等。就一个项目 而言，其面临的风险可分为五个方面：技术（与性能有关）、保障性（与性能有关）、 计划（与环境有关）、费用和进度。3.1、 技术风险技术风险可以定义为发展某项新设计所包含的风险，发展这项设计的目的是要将性 能水平在原有基础上提高一步，

30、但也可能因为受到某些新的约束条件的作用而使性能水平原封未动，甚至反而有所下降。技术风险的性质和原因随军用系统的设计而各不相同。许多技术风险往往是由于对新系统和新设备提出前所未有的性能要求造成的。3.2、 计划风险计划风险是包括获取和使用一些可能不受软件项目控制但又可能影响软件项目方 向的可用资源和活动。计划风险普通不会与改善技术水平有直接关系。计划风险可按一 些因素的性质和来源分类，这些因素有可能中断软件项目实施计划。造成软件中断的因 素主要以下几种：（1）与软件项目直接有关的高层权力机构决策造成的中断；（2） 一 些影响软件项目的事件或者行动造成的中断；（3）主要由于一些不能预见的与生产有

31、关的问题造成的中断；（4）因能力不足造成的中断。3.3、 保障性风险保障性风险是与系统的部署和维修有关的风险，这些系统指目前正在研制或者正在 部署的系统。保障性风险包含有技术和计划两个方面风险的特征。构成综合后勤保障 要素潜在的十种风险 源要素是：（1）维修规划；（2）人力和人员；（3）保障设备； （4）技术资料；（5）训练；（6）训练保障；（7）计算机资料保障；（8）设施；（9） 包 装、装卸、存储和运输；（10）设计接口。3.4、 费用和进度风险一些性能和设计技术问题有时要靠增加费用和延长进度来解决，这往往会使问题变 得复杂化。费用和进度增长指估计软件项目费用和进度与实际费用和时间之间的差

32、异。 因此，费用和进度增长会造成两个主要的费用/进度风险区：估计时定下不合理的低费 用/进度目标所造成的风险；要想满足合理的费用/进度目标，软件项目就必须给定一个 谨慎的风险。4、风险分析的步骤风险分析试图定量回答一些问题，这些问题与为了完成某个特定任务所研制的软件 和硬件性能上固有的效果范围有关，也与人们自身相互因素的作用和影响有关。风险分 析人员确定风险的方法是：把不希翼的事件发生的概率与每一个可预见的后果的大小相 结合。普通地，系统运行风险分析可以分为以下四个步骤：风险识别、检测某种情况， 确定潜在的风险范围；（2）风险量化，确定事件发生的概率以及产生的后果；（3）风险 影响评估和方案选

33、择，定量计算发生风险的后果和选择行动方案；（4）风险处理计划，描述处理风险的各种方法，并推荐具体的处理风险的行动。项目风险分析步骤也可以这 些步骤为参考。5、风险分析的方法我们知道，对于风险分析所作的工作大多局限于任务风险分析之中。这些方法对于 考虑项目风险领域的分析方法也有一定意义，风险分析方法可分为定性和定量两种，定 量的风险分析方法是在定性的基础上而实现的。下面，我们对这两类风险分析方法作简 要的论述。5.1、 定性风险分析方法定性风险分析的目的是界定风险源，并初步判明风险的严重程度，以给出系统风险 的综合印象，表1是一些定性风险分析方法的简介。易于看出，初步危（wei）险分析 是用于识

34、别系统中可能存在的风险源，而以下的几种方法则用于定性地量化各种风险 源可能对系统造成的破坏，从而判明系统风险大小。5.2、 定量风险分析方法定量风险分析是在定性分析的逻辑基础上，给出各个风险源的风险量化指标及其发 生概率，再通过一定的方法合成，得到系统风险的量化值。它是基于定性风险分析基础 上的数学处理过程。现发展较为成熟的方法有PRA （概率风险评估），DPRA （动态风 险概率评估）及仿真通用软件VERT （风险评审技术）等。PRA和DPRA都是在FTA分析基础上的量化，在可靠性及运行系统风险分析领域 内应用广泛。稍作改造，我们便可将其运用到项目风险分析领域。其分析步骤如下：（1） 识别项

35、目研制过程中的艰难环节，找出风险源；（2）对各风险源考察其在项目研制中 的地位，及相互逻辑关系，给出项目的风险源树；（3）标识各风险源后果大小，及风 险概率；（4）对风险源通过逻辑及数学方法进行组合，最后得到系统风险的度量。如 果是用DPRA进行评估，则尚须考虑它们在时间上的关系。另一种被广泛运用于风险评估的方法是VERT。VERT是国外在八十年代初期发 展的一通用仿真软件，它对项目研制构造过程网络，将各种复杂的逻辑关系抽象为时间、 费用、性能的三元组的变化。网络模型面向决策，统筹处理时间、费用、性能等风险关 键性参数，有效地解决多目标最优化问题，具有较大的实用价值。它的原理是通过丰富 的节点

36、逻辑功能，控制一定的时间流、费用流和性能流流向相应的活动。每次仿真运行， 通过蒙特卡洛摹拟，这些参数流在网络中按概率随机流向不同的部份，经历不同的活动而产生不同的变化，最后至某一终止状态。用户多次仿真后，通过节点采集到的各参数 了解系统情况以辅助决策。如果网络结构合理，逻辑关系及数学关系正确，且数据准确, 我们可以较好地摹拟实际系统研制时间、费用及性能的分布，从而知道系统研制的风险。6、风险分析的原则在风险分析时，应该遵循一些分析原则。下面是进行风险分析的几个普通性原则：(1)风险分析是软件设计的一部份，就像应力分析是传统软件设计实践的部份一 样；(2)风险分析是正式的、严谨的、定量化的；(3

37、)风险分析的目的是为了支持决策，应当把风险分析作为系统软件设计和研制 过程的一部份，而不应该过迟而无法做出主要的改变和资金的压力强迫在安全性和可靠 性上妥协，而这种妥协不能接受的情况下，作为一种反省进行；(4)风险分析可以按各种等级的详细程度、彻底程度和精密程度来进行；(5)风险分析详细、彻底、精确程度与分析项目的重要性和环境潜在的破坏程度 大小相一致；(6)在一个项目的早期概念阶段，能够而且应该实施近似的风险分析，随着设计 的逐渐开展，风险分析的精度和详细程度也随之提高。风险分析第十一章项目风险管理项目风险管理包括对项目风险进行 识别、分析和应对过程。它包括把正 面事件影响扩大到最大和把负面

38、事 件影响减到最小。风险识别风险识别包括确定可能对项目造成 影响的风险,并且把每一风险的特性 编制成文档.风险识别不是一次性活 动，必须在整个项目过程中时常进行. 风险识别应同时注意内部和外部的 风险.严格的说,风险仅包括遭受损 失或者损失的可能性.而在项目的背 景中，风险识别同时也与机会和威胁 有关.风险识别 产品描述 产品描述，项目产品的特性将会对识 别出的风险产生主要的影响使用成 熟的技术与需要革新和发明的产品 相比，承担较小的风险。风险识别的工具和技术检查表：检查表通常是由风险来源组 织而成的。来源包括：项目内容；其 他风险输出；项目产品或者技术事宜; 内部来源，如项目队伍成员的技能 等。绘制流程图：绘制流程图能匡助 项目队伍更好地理解风险的成因及 结果。访问调查：走访不同的项目干 系人将有助于风险识别，这些风险在 通常的计划活动中不易被发现。此外 还可以获取以前的调查记录。风险来源风险来源：风险来源是根据可能发生 的风险事件分类的。来源清单应该是 综合的，通常应该包括所有已识别的 事项，如风险发生频率、发生的可能 性、得失的大小等。普通风险来源包 括：风险来源描述对风险来源的描述通常应包括对以 下事项的估算：潜在的风险事件