【某软件项目开发的风险评估案例（论文）5800字】

某软件项目开发的风险评估案例目录TOC\o"1-2"\h\u27158某软件项目开发的风险评估案例 1157351.1风险定性评估 1293571.2风险定量评估 4193551.3风险评估结果 10常用的软件项目风险评估方法有很多，可分为两大类定性评估和定量评估。定性分析方法主要是通过分析需求分析阶段、设计阶段、编码阶段、集成和测试阶段常见的风险因素，如在软件需求分析阶段有错误的理解需求开发错误的软件系统设计困难实现的系统与客户的需求不一致测试困难理解错误系统不稳定编码困难无法在规定的时间内完成工作花费的时间长增加成本等风险因素。按照其发生的概率、对本阶段目标的影响力、对其它阶段目标的影响力，可以归纳出该风险相对软件开发的综合影响力。主要评定标准是从出现的概率的角度分为很高、高、一般、低、很低从对软件项目的影响力角度来讲分为很大、大、一般、小、很小。本章节通过采取定性风险评估和定量风评估方法，对表4.4最终得出的风险识别清单进行评估分析，并对风险要素进行排序，得出对项目风险影响较大的风险要素。1.1风险定性评估根据风险综合的评价理论，针对上一节识别出的风险清单列表3.4进行定性分析。项目经理和整个团队使用头脑风暴法对风险的影响和概率进行量化打分，并计算出风险程度如表1.1所示表1.1风险程度表编号识别代码风险描述影响概率风险程度01RR-01需求不太明确或者不太完整，描述过于笼统。导致用户、开发以及测试人员的理解不同，加剧了沟通成本0.860%0.4802RR-02需求频繁变更，没有确切的起始时间和结束时间，缺少对应的需求变更控制管理流程，随意答应产品经理修改。所有参与人贡不能拿到一个稳定的文挡输出0.860%0.4803RR-03需求分析不够，客户参加不度不足，消用户反馈的內容无法得到立即回应，造成事后商品与用户需求中间存有重特大差别0.850%0.304RR-04需求管理不标准，以致于文本文档错乱、要求设计方案错乱、没有一个规范的需求管理文档管理专用工具和步骤0.640%0.32续表1.1编号识别代码风险描述影响概率风险程度05RR-05需求分析不够，客户参加不度不足，消用户反馈的內容无法得到立即回应，造成事后商品与用户需求中间存有重特大差别0.830%0.2406TR-01项目技术架构混乱复杂，或者说没有架构0.860%0.4807TR-02开始没有统一的研发惊准规范，技术标准文培没有，界面、代码等设计编写风格不统一0.660%0.3608TR-03重复性代码较多，没有建立可复用的模块，也没有人专口负责代码定期的重构0.580%0.4009TR-04软件设计不符合面向对象设计的原则，各个模块接日设计不统，软件模块间稱合性很髙，改动一处就会影喃很多地方0.670%0.4210PR-01没有使用合适的项目管理工具来提高工作效率，比如代码管理工具、文档管理工具、bug管理工具等等。没有自动化的系统集成工具。没有使用配置管理工具，重复性工作太多，缺乏配置管理0.650%0.311PR-02没有使用配置管理工具，重复性工作太多，缺乏配置管理0.780%0.5612PR-03没有一套标准的开发管理流程，没有确定项目标准，代码管理混乱，各个阶段研发状态不明确0.770%0.4913MR-01领导力不足，项目管理经验不足，不能使团队离效合作0.860%0.4814MR-02人员的组织结构，分工，架构分配不合理，角色分工不明确0.540%0.2015MR-03任务分配没有发挥组员的特长，没有让正确的人做正确的工0.660%0.3616MR-04通管理有问题，沟通不畅。内部协调效率低下。0.810%0.0817MR-05管理层对团队的支持不够，有效的推动沟通不足0.830%0.24根据公司项目实际情况以及通过对公司层面专家的访谈最后制定出的的风险概率影响矩阵见表1.2，并定义出风险影响程度。供各项目评估参考。表1.2风险概率影响矩阵风险影响程度可能带来的后果风险发生概率80%60%50%30%10%0.8极高无法完成任务0.640.480.40.240.080.6高任务能正常完成，但是有严重影响，确定会延期0.480.360.240.180.06续表1.2风险影响程度可能带来的后果风险发生概率80%60%50%30%10%0.5中等任务有可能延期0.40.30.250.150.050.3低对任务完成有一点影响0.240.180.150.090.030.1极低正常完成0.080.060.050.030.01风险等级：1．高于0.48为高风险2．介于0.24和0.4之间中等风险3．低于0.24为低等风险通过对比TC公司的风险概率影响矩阵表1.1，结合表1.2得出的风险识别结果，得到每个风险的风险等级表1.3如下。方便下一步根据风险等级做出相应的控制措施。表1.3风险等级表编号识别代码风险描述影响概率风险程度优先级01RR-01需求不是很明确或者不太完整，描述过于笼统。导致用户、开发以及测试人员的理解不同，加剧了沟通成本0.860%0.48高02RR-02需求频繁变更，没有确切的起始时间和结束时间，缺少对应的需求变更控制管理流程，随意答应产品经理修改。所有参与人贡不能拿到一个稳定的文挡输出0.860%0.48高03RR-03需求分析不够，客户参加不度不足，消用户反馈的內容无法得到立即回应，造成事后商品与用户需求中间存有重特大差别0.850%0.3中04RR-04需求管理不标准，以致于文本文档错乱、要求设计方案错乱、没有一个规范的需求管理文档管理专用工具和步骤0.640%0.32中05RR-05需求分析不够，客户参加不度不足，消用户反馈的內容无法得到立即回应，造成事后商品与用户需求中间存有重特大差别0.830%0.24低06TR-01项目技术架构混乱复杂，或者说没有架构0.860%0.48高07TR-02开始没有统一的研发惊准规范，技术标准文培没有，界面、代码等设计编写风格不统一0.660%0.36中08TR-03重复性代码较多，没有建立可复用的模块，也没有人专口负责代码定期的重构0.580%0.40中续表1.3编号识别代码风险描述影响概率风险程度优先级09TR-04软件设计不符合面向对象设计的原则，各个模块接日设计不统，软件模块间稱合性很髙，改动一处就会影喃很多地方0.670%0.42中10PR-01没有使用合适的项目管理工具来提高工作效率，比如代码管理工具、文档管理工具、bug管理工具等等。没有自动化的系统集成工具。没有使用配置管理工具，重复性工作太多，缺乏配置管理0.650%0.3中11PR-02没有使用配置管理工具，重复性工作太多，缺乏配置管理0.780%0.56高12PR-03没有一套标准的开发管理流程，没有确定项目标准，代码管理混乱，各个阶段研发状态不明确0.770%0.49高13MR-01领导力不足，项目管理经验不足，不能使团队离效合作0.860%0.48高14MR-02人员的组织结构，分工，架构分配不合理，角色分工不明确0.540%0.20低15MR-03任务分配没有发挥组员的特长，没有让正确的人做正确的工0.660%0.36中16MR-04通管理有问题，沟通不畅。内部协调效率

低下0.810%0.08低17MR-05管理层对团队的支持不够，有效的推动沟通不足0.830%0.24低1.2风险定量评估定量风险分析过程的目的是定量分析每种风险的可能性及其对项目目标产生的后果，并分析项目的总体风险程度。此过程涉及的工作包括确定实现特定项目目标的可能性，确定项目面临的风险，确定可能需要的成本和应急准备金计划，确定每种风险对项目风险的相应贡献以及分析风险。需要最关注的事情是寻找理想成本的风险可实现的业务目标的时间表和范围。在本节中，在定性风险分析之后，使用层次分析法分析项目风险，确定风险权重，然后评估总体项目风险。层次分析过程(AHP)由美国运筹学专家和匹兹堡大学教授于本世纪提出。这是一种简单的方法，结合了定性和定量分析，可以对更复杂的决策问题做出决策。特别是，它量化了决策者的经验判断，这些决策者排列了人们思维过程的层次结构，逐层比较了相关因素，并逐层检验了比较结果的合理性，从而提供了更具说服力的基础。近年来，这种方法已在国内外广泛使用。分析层次结构过程根据考虑的不同观点，首先将比较元素划分为层次结构。例如，对于给定的业务决策A，可以从两个方面B1和B2考虑，共有C1、C2、C3、C4这4种可选择的方案，于是，该问题比较的层次化结构图如下AAB2B1C4C3C2C1图1.1层次结构图运用层次分析法进行软件项目风险评估的基本思路是首先找出软件项目中风险问题所牵连的主要风险因素，将这些因素按其隶属关系构造成层次模型，建立判定矩阵，通过对矩阵中各因素之间定性的比较之后，给各个风险因素加上重要性权值，然后经过定量计算得出每个风险因素相对重要性。通过分析我们得出TC公司软件项目的层次如下表所示表4.4项目风险层次结构一级二级三级项目总体风险需求风险RR-01需求不是很明确或者不太完整，描述过于笼统。导致用户、开发以及测试人员的理解不同，加剧了沟通成本。RR-02需求频繁变更，没有确切的起始时间和结束时间，缺少对应的需求变更控制管理流程，随意答应产品经理修改。所有参与人贡不能拿到一个稳定的文挡输出。RR-03需求分析不够，客户参加不度不足，消用户反馈的內容无法得到立即回应，造成事后商品与用户需求中间存有重特大差别。RR-04需求管理不标准，以致于文本文档错乱、要求设计方案错乱、没有一个规范的需求管理文档管理专用工具和步骤。RR-05需求分析不够，客户参加不度不足，消用户反馈的內容无法得到立即回应，造成事后商品与用户需求中间存有重特大差别。续表4.4一级二级三级项目总体风险技术风险TR-01项目技术架构混乱复杂，或者说没有架构。TR-02开始没有统一的研发惊准规范，技术标准文培没有，界面、代码等设计编写风格不统一。TR-03重复性代码较多，没有建立可复用的模块，也没有人专口负责代码定期的重构。TR-04软件设计不符合面向对象设计的原则，各个模块接日设计不统，软件模块间稱合性很髙，改动一处就会影喃很多地方。过程风险PR-01没有使用合适的项目管理工具来提高工作效率，比如代码管理工具、文档管理工具、bug管理工具等等。没有自动化的系统集成工具。没有使用配置管理工具，重复性工作太多，缺乏配置管理。PR-02没有使用配置管理工具，重复性工作太多，缺乏配置管理。PR-03没有一套标准的开发管理流程，没有确定项目标准，代码管理混乱，各个阶段研发状态不明确。管理风险MR-01领导力不足，项目管理经验不足，不能使团队离效合作。MR-02人员的组织结构，分工，架构分配不合理，角色分工不明确。MR-03任务分配没有发挥组员的特长，没有让正确的人做正确的工。MR-04通管理有问题，沟通不畅。内部协调效率低下。MR-05管理层对团队的支持不够，有效的推动沟通不足。根据上面的表格我们可以画出本公司软件项目风险层次结构图如下图1.2所示项目总体风险项目总体风险需求风险技术风险过程风险管理风险TR01TR02TR03PR01TR04PR02PR03MR02MR01MR03MR04MR05RR01RR02RR03RR04RR05图1.2风险结构图有了上面的风险结构图，项目组的成员根据头脑风暴法和专家评判法构造出二级目标对比一级目标的对比矩阵如下表4.5所示表4.5二级目标对比一级目标对比矩阵表项目总体风险需求风险技术风险过程风险管理风险需求风险1.00002.00003.00004.0000技术风险0.50001.00002.00003.0000过程风险0.33330.50001.00002.0000管理风险0.25000.33330.50001.0000根据层次分析理论对矩阵表4.5，计算各个风险的权重，最大特征值和一致性比例如表4.6二级目标对比一级目标对比矩阵和权重项目总体风险一致性比例：0.0116对“项目总体风险”的权重：1.0000；λmax：4.0310项目总体风险需求风险技术风险过程风险管理风险权重(Wi)需求风险1.00002.00003.00004.00000.4673技术风险0.50001.00002.00003.00000.2772过程风险0.33330.50001.00002.00000.1601管理风险0.25000.33330.50001.00000.0954对二级目标的中间层要素进行排序得出下表4.6所示排序权重表格表4.7中间层要素排序矩阵中间层要素权重排序需求风险0.46731技术风险0.27722过程风险0.16013管理风险0.09544同样的方法计算出三级指目标对二级目标的矩阵表，如下表4.7到表1.10表4.8需求风险三级目标对二级目标对比矩阵和权重需求风险一致性比例：0.0141对“项目总体风险”的权重：0.4673；λmax：5.0633需求风险RR-01RR-02RR-03RR-04RR-05WiRR-011.00002.00004.00005.00006.00000.4593RR-020.50001.00002.00003.00004.00000.2497RR-030.25000.50001.00002.00003.00000.1449RR-040.20000.33330.50001.00002.00000.0890RR-050.16670.25000.33330.50001.00000.0570表4.9技术风险三级目标对二级目标对比矩阵和权重技术风险一致性比例：0.0116对“项目总体风险”的权重：0.2772；λmax：4.0310技术风险TR-01TR-02TR-03TR-04WiTR-011.00002.00004.00005.00000.4593TR-020.50001.00002.00003.00000.2497TR-030.25000.50001.00002.00000.1449TR-040.20000.33330.50001.00000.0890表1.10过程风险三级目标对二级目标对比矩阵和权重过程风险一致性比例：0.0000对“项目总体风险”的权重：0.1601；λmax：3.0000技术风险PR-01PR-02PR-03WiPR-011.00001.00000.50000.2500PR-021.00001.00000.50000.2500PR-032.00002.00001.00000.5000表1.11管理风险三级目标对二级目标对比矩阵和权重管理风险一致性比例：0.0148对“项目总体风险”的权重：0.0954；λmax：5.0664需求风险MR-01MR-02MR-03MR-04MR-05WiMR-011.00000.25002.00003.00000.50000.1416MR-024.00001.00003.00006.00002.00000.4536MR-030.50000.20001.00002.00000.33330.0870MR-040.33330.16670.50001.00000.16670.0518MR-052.00000.50003.00006.00001.00000.2660通过上面的分析我们可以看出一致性校验的数值都小于1，因此可以认为每个权重的风险数据是有效的，对比三级目标的权重进行全面的排序得出下表1.11的排序表表1.12风险要素对决策目标的排序权重识别代码风险描述权重排序RR-01需求不是很明确或者不太完整，描述太宽泛。导致用户、开发以及测试人员的理解不同，加剧了沟通成本。0.21461TR-02开始没有统一的研发惊准规范，技术标准文培没有，界面、代码等设计编写风格不统一。0.12952续表1.11识别代码风险描述权重排序RR-02需求变更频繁，没有明确的起点巧终点，没有相应的需求变更控制管理流程，随意答应产品经理修改。所有参与人贡不能拿到一个稳定的文挡输出。0.11673PR-03没有一套标准的开发管理流程，没有确定项目标准，代码管理混乱，各个阶段研发状态不明确。0.08004TR-01项目技术架构混乱复杂，或者说没有架构。0.07685RR-03需求分析不足，用户参与度不够，用户反馈缓慢迟纯，导致后期产品和用户要求的出入很大。0.06776TR-03重复性代码较多，没有建立可复用的模块，也没有人专口负责代码定期的重构。0.04447MR-02人员的组织结构，分工，架构分配不合理，角色分工不明确。0.04338RR-04需求管理不规范，Ｗ至于文档混乱、需求设计凌乱、没有一个标准的需求管理文档管理工具和流程。0.04169PR-02没有使用配置管理工具，重复性工作太多，缺乏配置管理