目录

1.学习目的.......................................................................................... 2

1.1用途......................................................................................... 2

1.2要求......................................................................................... 2

2.学习态度.......................................................................................... 2

3、学习内容....................................................................................... 3

4、学习心得....................................................................................... 5

5.自我评价.......................................................................................... 6

6.学习成果.......................................................................................... 7

软件工程课程总结

1.学习目的

1.1用途

    在本学期的软件工程课程中我们大略学习了软件的开发过程，需要哪些工具，具体建模模式和方法以及这些模型和方法是如何实现软件的某一功能的，让我们在脑海里形成了系统的关于软件开发的流程图，为今后的关于软件工程的学习打下基础，同时为我们开发软件带来方便。通过这学期以来的学习，虽说课本中的很多内容仍不能清晰地理解掌握，但对于软件工程确实也有了更明晰系统的概念和理解，同时也在老师授课下对许多以前未所听闻的开发软件和开发方法如UML模型等有了初步的了解，深感这是一门博大精深而十分有用的学问，需要我们认真进一步地学习。

1.2要求

    关于软件工程的学习，我对自己的要求是：①掌握老师课堂上指出的重点内容，并在课后通过各种手段作一定的深入了解。②认真记下重要的笔记，保证按时完成老师交代的作业并及时上交，同时检查自己是否仍有不懂的知识。③积极和同学讨论自己对于书本中一些方法、模型的理解和感受。④上课不旷课逃课，不迟到早退。

2.学习态度

    在这个学期的《软件工程》这一门课程的学习中，我的学习态度端正，从没有旷课逃课、请假、迟到早退等行为，上课认真记下老师讲过的重点知识的笔记，下课也和朋友讨论刚学的模型和方法如瀑布模式、增量模式、用例图的画法、活动图的作用等，受益良多。也有按时完成老师布置的作业并及时上交给老师检查。但是有一点让我惭愧的是，我的课外阅读量太少，对软件的了解仍然有待加强，在今后的学习中，我一定会加强这方面的阅读并好好的运用在软件开发中。

3、学习内容

    软件的定义：软件是能够完成预定功能和性能的可执行的计算机程序和使程序正常执行所需要的数据，加上描述程序的操作和使用的文档。软件的特征：①软件有对硬件不可缺失的依赖。②软件有不同与硬件的生产流程。软件不是制造出来的，而是开发出来的。硬件生产的最大成本是复杂的制造工艺，而软件的最大成本则是分析与设计。③软件有不同与硬件的生命过程。包括：磨合期、正常使用期、老化期。

    软件危机：①软件开发成本、进度失控。②软件质量不能获得有效保证。③软件不能满足用户应用需要。④软件可维护性差。

 软件生存周期：一个软件从定义到开发、使用和维护，直到最终被弃用，要经历一个漫长的时期，通常把软件经历的这个漫长的时期称为生存周期。软件的生存周期可分为三个阶段：软件定义期、软件开发期、运行维护期。

    瀑布模式：是传统的软件开发模式，其中的“瀑布”是对这个模式的形象表达，由山顶倾泻下来的水，自顶向下、逐渐细化。其特点是：线性化过程；分为分析、设计、编码、集成等几个阶段，并且各阶段逐级推进，不允许跨越。里程碑管理；阶段评审；文档驱动；简洁便于工程应用的线性化过程步骤，并可以通过里程碑管理机制而使项目进程量化。其明显的优点就是没个阶段结束前都要对所完成的阶段成果进行评审，这使得软件的错误能够在个阶段内尽早发现并尽早解决，总的来说瀑布模式具有良好的质量保证机制，有很强的生命力。

    原型进化模式：对软件进行直接模拟或仿真，只需要分析用户的需求框架后进行原型创建，再根据用户的使用评价对原型系统进行逐步细化与完善，通过版本更新逐步满足用户对于软件的多方面需要。

    增量模式：开发过程有三个任务域，分别是设计结构、开发构件和集成系统，它既有完善的工程管理机制，又能适应用户需求变更，有利于质量的监控，并且各局部基于构件构造，有利于逐步构建与完善；由于先交付核心构件可利于降低项目的技术风险。

软件项目管理：①软件项目组，组建优秀的团队可以开发出高质量的软件产品。任务开发团队要求小而精，成员大多在8人以内，主要成员有项目组长、开发人员、资料管理员和软件测试员。②项目组管理机制：民主分权制、主程序员负责制、置业项目经理负责制、层级负责制。③项目计划是为了使软件开发各项工作有秩序地进行，包括任务分配和进度安排，甘特图和任务网络图是用来描述进度计划的工具。项目计划书可以作为软件开发的工作指南。④项目成本估算，由于项目有来自各方面的成本包括工资开支、场地费、差旅费、设备费和资料费等，但是软件主要是对人力成本的估算，常用的方法有程序代码成本估算法等。⑤风险管理包括很多不确定的风险因素，如计划风险、管理风险、需求风险、技术风险、人员风险、产品风险、用户风险和商业风险等等，而风险管理的主要任务是：风险识别、风险评估、和风险防范。⑥软件文档管理，软件文档是工程模式软件开发的成果体现。按照软件文档形式分类包括正式文档和非正式文档；按照国家标准分类包括可行性分析报告、项目开发计划、需求规格说明书、测试计划、概要设计说明书、数据库设计说明书、详细设计说明书、模块开发卷宗、用户操作手册、系统维护手册、测试分析报告、系统试运行计划、开发进度月报、项目开发总结报告。按照软件文档被使用范围分类包括技术文档、管理文档和用户文档。⑦软件配置管理：包括配置规划、软件变更控制、软件版本控制和质量控制计划。⑧软件质量管理：包括质量标准、质量计划、质量保证、质量指标。

    计算机系统由硬件、软件、数据资源、网络资源、使用系统的人等诸多元素。有三种典型的计算机体系结构：①主机结构，主机集中了全部智能，并依靠终端接口与外部设备连接。②Client/Server结构，智能分布于服务器与客户机，并依靠网络连接成系统，其中，服务器处于核心位置，提供被动核心服务；客户机处于边缘位置，可主动访问服务器，寻求服务支持。③Browser/server结构，可适应互联网远程交互的特殊结构，基于Web服务器构建。

    需求分析：系统开发前期需求分析很重要，它是为了有效解决用户问题的需要进行的一项工程活动，所需要考虑的需求问题是功能需求、数据需求、性能需求和接口需求，开发者承担分析任务，核心是用户。其步骤有三个：①获取客户需求，客户泛指某个人或机构部门等，一般方法是调查，包括访谈、座谈、问卷、跟班和收集资料，需求规约可表达用户的软件价值。②建立需求模型，它是用户需求的图解，一些常用的模型有：业务树图、用例图、活动图。分别用于结构化需求建模、系统业务举例和反映系统工作流程。③进行需求验证，要验证的主要内容有：有效性验证、一致性验证、完整性验证、现实性验证和可检验性验证。

    结构化分析建模：它是建立在需求规约基础上的，对软件问题进行全面解说，包括四个方面：①数据建模，它与数据库设计密切相关，ER图涉及实体、关系、属性等图形元素，在业务层面建立数据库概念模型，一般用于前期的建模构想。②功能建模，是对系统数据加工的图解，数据流程图是常用的建模工具，涉及数据接口、数据处理、数据流、数据存储等图形元素，用于描述系统数据加工细节。③行为建模，行为模型用于说哦名软件系统与环境的交互，状态转换图常用的软件行为建模工具涉及状态、事件等图形元素。⑤数据字典，是用于定义软件的元素，使软件元素获得严肃的、详密的、精确的规格说明。需求分析模型中的数据、功能、行为等诸多方面的元素，都有必要通过数据字典给予细节说明，以达到对系统较完整全面的规格定义。

    基于UML对象面向对象分析建模：UML是统一建模语言，有统一的语法、语义和语用规则，其建模过程的特点是：用例驱动、以构架为中心和增量迭代，通过包实现对模型的有效的一体化管理。包括三部分：①用例建模，它面向用户需求的，能够反映系统的用户价值，用例图的基本元素有用例、参与者、交流；用例之间有泛化、延伸和包含关系。②活动建模，活动图用于描述系统动态过程，主要图形元素有：活动、转换、起点、终点、判断、并发、同步、泳道等。可描述高层业务级活动，涉及整个业务流程，针对每个用例活动建模，反映用例内部活动细节。③类分析建模，这里就只考虑实体类，实体类所代表的数据相互之间通常有一定的关系，依靠这种关系可形成有组织的程序数据结构。实体类之间的主要数据关系有：关联、聚类、泛化。

4、学习心得

    在《软件工程》的学习中，我了解了什么是“软件危机”，透过软件工程于解决“软件危机”的重要性、软件工程三条重要线索、软件工程知识体系函括内容及软件工程各类生存期模型，我对软件工程思想及“工程化”软件开发的流程有了较系统的了解。透过软件工程的起源，我认识到：实现软件工业的产业化，软件工程必须是真正意义上的工程化。从软件开发三条线索（开发、管理、改进）来看，软件开发的过程必须规范化，软件开发各阶段都必须形成相应文档，编码必须依照通用可读性严格遵照编程规范；软件项目管理的核心是项目规划和项目跟踪控制，保证软件工程开发的成功完成，软件开发流程的规范化在软件项目中有着重要的作用，通过不断地优化和规范过程，企业可以提高软件生产能力。从需求分析到维护，透过软件的开发流程具体实施的学习，我对软件项目开发的流程也有了更深的理解，例如通过需求设计报告、概要设计报告、详细设计报告三份作业的完成虽然很不完善，但仍让我对需求分析建模和设计中用到的方法有了更好的理解并熟悉了三份文档的格式。同时，这门课更正我不少的错误观念：比如编码规范问题，以前我总觉得个人写的程序只要能运行不管别人看不看得懂，注释可有可无，想法越独特代码量越少或内存损耗越小就越好，学了这门课才理解这样的代码可读性很差，通用性不好，维护起来很不方便，代码的可读通用性重要性不亚于正确性和运行效率；以前除了代码的源文件其他文档都不甚重要，学了这门课才知道软件开发中每一阶段都有文档的产生，其管理与应用也是一门大学问。此外，这门课程里讲授了很多我以前从未接触过的方法和软件如UML模型、visio的强大绘图建模功能、project的项目规划与跟踪作用等等，这些知识不仅能应用于软件工程，也能应用于其他的很多领域，这门课结束了，但这些方面学习我还将继续的。

5.自我评价

    我觉得在这门课程的学习中，我很认真。我按照自己对自己的要求认真执行。对老师课堂上指出的重点内容在课后作了详细的复习，并通过各种手段作了一定的深入了解。认真记下了重要的笔记，按时完成了老师交代的作业并及时上交，同时检查自己是否仍有不懂的知识。积极和同学讨论自己对于书本中一些方法、模型的理解和感受，加了自己对知识的理解。也做到了上课不旷课逃课，不迟到早退。

    同时，我还觉得学习这门课让我很快乐，虽然遇到过很多难题，有过很多的疑惑，但最后都在老师和同学的帮助中化解了，软件工程是我最喜欢的科目之一，其他科目中系统工程和软件工程可以相辅相成，我也很喜欢。在短短十六周十六节课的学习中，我对软件开发的开发模式、模块划分、模型构建等过程有了深入的了解。以前不知道模型是什么，总以为建模是一件特别无聊又耗时间的事，但是在学习了软件工程后，我才终于认识到模型是多么有趣的东西。另外，在软件工程中学到的一些方法可以帮助我在数据库建模、C++程序设计划分模块时更快地找到重点，它给了我一个方向。所以我认为，在这十六节课里，我是学到了东西的，为这十六节课花的时间和精力对我来说是值得的。

6.学习成果

这个学期的收获很多。在此我举两个例子。

1.我学会了怎么画数据流图，如自动阅卷系统的数据流图。

   

图1.“自动阅卷系统”数据流图

2.我学会了画用例图进行用例建模。如学生成绩管理用例图。

图2.学生成绩管理用例图

第二篇：软件工程课程(期末)论文

软件工程课程（期末）论文

论文题目：软件项目风险管理与方法探讨

院    系：      信息技术学          

班    级：*************************

作    者：        ******           

学    号：      **************        

指导教师：       **********            

撰写时间：2012年12月24—20##年1月4日

信息技术学院

摘  要

随着软件产业的迅速发展,软件的规模越来越大,复杂性也越来越高,伴随而来的项目风险也愈加难以控制，软件项目的风险管理已经成为软件技术因素之外决定项目成败的关键。因此，研究软件项目风险管理对于软件开发、软件项目管理及软件产品质量都具有重要意义。本文首先从软件项目风险管理研究的背景及意义出发，叙述了在软件项目开发中风险管理的重要性；其次，重点从软件项目风险管理的5个步骤，即风险识别、风险分析、风险计划、风险监控和风险对策，介绍了软件项目风险管理研究的理论基础与方法；最后，给出了减轻或防止风险发生的几种合理、有效的风险应对措施。

关键词：软件风险；风险管理；风险过程分析；风险应对措施

Abstract

With the rapid development of the software industry, the size of the software is more and more big and the complexity is also more and more high. This lead to the project risk is more and more difficult to control. software project risk management has become a software technology factors besides decided to project success or failure of the key. Therefore, the software project risk management for software development, software project management and software product quality is of important significance. This paper from the software project risk management based on the research background and significance, described in the software project development in the importance of risk management; Second, focus from software project risk management of the five steps, namely, risk identification, risk analysis, risk plan, risk monitoring and risk countermeasures, this paper introduces the software project risk management study of the theoretical basis and methods; Finally, the paper puts forward the relieve or prevent the occurrence of a risk the risk of several reasonable and effective measures.

Key words：Software risk; Risk management; process of risk analysis; Risk measures

目录

第一章 绪论... 1

1.1 研究背景... 1

1.2 研究意义... 1

1.3 研究现状... 1

1.4本文研究内容、研究方法与技术路线... 2

1.4.1 本文研究内容... 2

1.4.2 本文研究方法与技术路线... 2

1.5 本文的创新点... 2

第二章 软件项目风险管理的理论基础与方法综述... 3

2.1. 软件项目风险管理理论基础... 3

2.1.1 软件项目风险定义... 3

2.1.2 软件项目风险分类... 3

2.1.3 软件项目风险特点... 3

2.1.4 软件项目风险处理方式... 3

2.1.5 软件项目风险管理框架体系... 4

2.2 软件项目风险管理研究方法... 5

2.2.1 软件项目风险识别方法... 5

2.2.2 软件项目过程风险分析... 6

2.2.3 软件项目风险管理... 7

2.2.4 软件项目风险评估与监控... 8

第三章 软件项目管理中的风险管理应对措施... 10

第四章 总结... 11

参考文献:. 12

第一章 绪论

1.1 研究背景

软件产业已经成为国际竞争的焦点和各国竞相发展的战略性先导产业，发展软件产业对于提升我国的产业竞争力，走新型工业化道路和确保国家安全，具有重要的战略意义。目前，随着软件产业规模的快速增长，软件正以其特有的影响力和渗透力，应用于国民经济各行各业，渗透到人们日常工作和社会生活的各个方面。

软件的重要性正日渐凸显，然而，软件开发项目却常常遭受失败的打击。软件业界，软件项目进度延期、预算超支、开发的系统不能满足用户需求等，最后导致项目失败的现象十分普遍。据美国Standish Group通过分析13522个软件项目得出结论：只有1/3的项目是成功的；82%的项目延期，43%的项目超出预算。在分析众多导致软件项目频繁遭受如此巨大失败的原因时，人们得出了一个结论：缺乏有效的风险管理方法是导致软件项目失败的重要原因之一。

目前软件项目风险管理理论研究已基本成熟，已有一定数量的风险管理方法、模型等研究成果，但仍有必要，针对不同国家的国情、不同的企业规模、不同类型的软件项目，研究与其相适应的风险管理方法体系。

1.2 研究意义

从软件项目的特殊性来看，软件项目风险与传统工程项目风险有着本质区别，导致传统工程项目风险管理理论与方法并不完全适用于软件项目，因此需要针对软件项目与软件项目风险的特征，研究软件项目风险管理理论与方法。从学科发展的角度来看，研究软件项目风险管理理论与方法，可以丰富和完善软件项目风险管理研究成果，促进软件项目管理学科的发展建设。从近三十年的软件项目风险管理研究成果来看,国外该领域的研究，无论在理论还是应用实践方面，都有着丰富的成果和经验。国内该领域的研究还处于初步阶段，如何借鉴国外的成果和经验，并结合我国国情、软件产业和软件企业发展的环境，进行软件项目风险管理理论、方法与实践的研究，是一项具有现实意义和挑战性的课题，需要经历一个较长时期的研究和发展。

1.3 研究现状

纵观国内外研究现状，从研究内容看，国外软件项目风险管理研究偏重建立完善的理论体系，并配套有系统的方法、技术和工具，国内该领域研究处于学习和吸收国外已有理论和方法的阶段，研究成果主要集中于风险管理方法，有关风险管理理论体系的研究成果很少。从研究风格看,以美国为首的国外软件项目风险管理研究特别强调应用管理规范的建立,相对不太重视引入传统的数理方法，国内研究偏重于数理方法的应用,研究成果大多是单个方法在软件风险管理某步骤中的应用，还没有形成系统的方法体系。从研究方向看，国外研究大多针对大型软件项目，国内研究则针对中小型软件项目。从涉及的相关学科看,主要应用到软件工程、风险管理、项目管理、质量管理、数理统计学、模糊数学以及决策理论等。

1.4本文研究内容、研究方法与技术路线

1.4.1本文研究内容

本文主要围绕软件项目风险管理过程中风险识别、风险分析、风险计划、风险跟踪和风险对策5个步骤进行研究，并给出可以减轻或防止风险发生的合理、有效的风险应对措施。

1.4.2本文研究方法与技术路线

本文主要围绕软件项目风险管理过程中风险识别、风险分析、风险计划、风险跟踪和风险对策5个管理过程展开研究，研究主要采用文献研究法，通过收集、研读国内外相关图书、文献资料，分析和整理现有软件项目风险管理理论与方法研究成果，探讨减轻或防止软件项目风险发生的风险应对措施。

1.5 本文的创新点

本文的创新点可归纳为：通过分析归纳现有软件项目风险管理理论与方法研究成果在实践中的应用和可能存在的缺陷与不足，并给出了一些常用的可以减轻或防止软件项目风险发生的风险应对措施。

第二章 软件项目风险管理的理论基础与方法综述

2.1. 软件项目风险管理理论基础

2.1.1软件项目风险定义

软件项目风险是指在软件项目生命周期内，由于某些不确定性而可能导致软件项目偏离预定目标，造成软件项目损失（进度、成本、质量）的风险事件。

2.1.2软件项目风险分类

为了有效地进行软件项目风险管理，有必要对风险进行分类。按照不同的分类标准，可对软件项目风险进行不同的分类。从风险来源来分，技术风险、管理风险、人员风险、需求风险等。从风险对项目目标的影响来分，进度风险、费用风险、质量风险。从软件组织角度来分，发生在组织外部的风险，称为外部风险，反之，发生在组织内部的风险，称为内部风险。由于外部风险是组织不可控制的，而在进行项目风险管理时，通常只研究组织可以控制的那部分风险，即内部风险。

2.1.3软件项目风险特点

风险与将要发生的事情有关，它涉及诸如思想、观念、行为、地点、时间等多种因素；风险随条件的变化而改变，人们通过改变、选择、控制与风险密切相关的条件可以减少风险，但改变、选择、控制条件的策略往往是不确定的。软件项目管理的风险来自于软件项目自身的特点：

1、软件产品不可见。

开发的进展以及软件的质量是否符合要求难于度量，从而使软件的管理难于把握。

2、软件的生产过程不存在绝对正确的过程形式。

不同的软件开发项目应当采用不同的或者说是有针对性的软件开发过程，而真正合适的软件开发过程是在软件项目开发完成后才能明了的。因此项目开发之初只能根据项目的特点和开发经验进行选择，并在开发过程中不断的调整；

3、大型软件项目往往是“一次性”的。

以往的经验可以被借鉴的地方不多。回避和控制软件管理风险的惟一办法就是设立监督制度，进行有效的风险监控和管理。同时，风险本身又具有以下特点：

(1)不确定性：刻画风险的事件可能发生也可能不发生；

(2)损失性：如果风险变成了现实，就会产生恶性后果或者损失；

(3)进行风险分析时，重要的是量化不确定性的程度及与每个风险相关的损失的程度；

(4)当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了；

(5)在能够标识出软件项目中的“真正风险”之前，先要能识别出所有对于管理者以及开发者而言均为明显的风险是很重要的。

2.1.4软件项目风险处理方式

软件风险管理工作就是在风险成为影响软件项目成功的威胁之前，识别、着手处理并消除风险的源头。项目开发过程中对风险进行控制管理可以大大提高软件开发的成功性，一般可以在一下几个层次上定位、管理风险：

(1)危机管理：即所谓“救火模式”，就是在风险已经造成麻烦后才着手处理它们；

(2)失败处理：察觉到了风险并迅速做出反应，但只是在风险发生之后；

(3)风险缓解：事先制定好风险发生后的补救措施，但不做任何防范措施；

(4)着力预防：将风险识别与风险防范作为软件项目的一部分加以规划和执行；

(5)消灭根源：识别和消除可能产生风险的根源。前3项都是被动进行的，对项目已造成一定、甚至重大的损失，正所谓“亡羊补牢，为时已晚”。所以应当着力于预防风险，更好的是消除风险根源。

2.1.5软件项目风险管理框架体系

从软件项目风险管理的发展历史看,Boehm于1989年出版的专著《软件风险管理》,奠定了该领域的理论基础，在随后近30年中,又陆续出现了几种框架体系。现总结和比较如下：

1、Boehm和 Charette 的风险管理框架

Boehm在《软件风险管理》中,将软件项目风险管理分为风险评估和风险控制两大部分,其中风险评估又分为风险识别、风险分析和风险的优先级排序,风险控制又分为风险管理计划、风险解决和风险监控。软件项目风险管理的另一位创始人 Charette 构建的风险管理框架,则直接将其分为风险分析和风险管理两部分,其中风险分析包括识别、估算和评价,风险管理包括计划、控制和监控。二者的理论框架(如表1所示)。

表1 　Boehm 和 Charette 的风险管理框架

从本质上讲,二者风险管理框架基本相同。从内容上看,与其他工程项目风险管理也没有实质性差别。

2、Higuera 和 Haimes的持续风险管理框架模型

Higuera和Haimes提出的软件项目风险管理框架,是美国卡内基 ·梅隆大学软件工程研究所( SEI)风险管理体系中的一部分。该体系将风险管理划分为风险识别、分析、计划、跟踪、控制5个步骤,风险管理的方式是连续循环的,其核心是风险沟通。它要求在项目生命期的所有阶段都关注风险管理,即所谓持续风险管理(CRM)框架模型(如图1所示)。

图 1 SEI的持续风险管理框架模型

SEI的模型在Boehm和Charette的模型基础上有所改进,注重了软件项目的过程特点。但这一模型只是在理论上对风险管理的过程有了初步认识,而如何把风险管理演绎成一个动态、持续的风险管理过程,未作详细阐述。

3、Hall的六学科模型

Hall的六学科风险管理模型(如图2所示),将风险管理分解为6个学科。其中: E代表预想,是把思想转化为目标的学科,用于研究软件产品的远期规划; P代表计划,是为软件目标分配资源的学科; W代表工作,是指产品计划的执行; M代表度量,是比较期望值和实际值的学科,两个值的差异用于调整项目计划; I代表改进,是从过去经验中学习的学科,它通过分析基准和项目度量结果,找出改进的方向; D代表发现,是预知未来的学科,它通过对不确定性的评价和对困惑的思考,考虑机会和风险的均衡,预先指导计划和规划的改变。

图 2 Hall 的六学科风险管理模型

2.2 软件项目风险管理研究方法

2.2.1软件项目风险识别方法

软件项目风险管理力求系统化地确定风险对项目计划(估算、进度、资源分配)的威胁，在可能时避免风险，在必要时控制风险。为了规避风险、控制风险，首先应识别风险，发现项目可能的风险。识别风险就是试图确定系统中的各种风险因素和事件，并预测它的不良后果和发生情况。风险识别可以通过项目组集体讨论完成，或凭借管理者的经验进行。从已有成果看,软件项目风险识别的研究方法大致有以下几种:

1)风险清单法。 Boehm给出了top 10风险序列,并提出了顶级十大风险源清单。随后,他指出在软件项目开发生命期的每个重要阶段,都可进行top 10风险清单的调查和修改,并将风险管理加入软件项目开发生命期模型。Boehm还提出了软件项目开发期的螺旋式模型,使项目管理人员可对软件项目进行动态风险追踪。Barki 等通过总结列出了35项风险变量；Jones描述了60项最常见的风险因素。这些成果对于开展风险识别、提供风险源素材具有很大的帮助。

2)风险识别法(TBI).Marvin等提出的基于分类的风险识别法,主要是从项目分类学的角度考虑风险,对项目的风险项进行分类,从单纯的清单列表走向由分类树与问卷识别过程的统一,从而使软件项目风险项具有结构性的特点。另外,它也秉承了动态管理的特点,使风险识别及后续处理有计划、分步骤、周期性地在项目生命期内进行。

3)基于分类的问卷调查表法(TBQ)。该方法是由专家根据项目特点设计风险管理问卷调查表,对企业有关人员进行问卷调查,并根据调查结果对数据进行统计分析。文献在问卷调查的基础上提出一种簇分析方法,对507个软件项目管理人员进行问卷调查。文献在此基础上进一步扩展,提出一种软件风险和性能的层次模型,并对调查结果作了统计分析。

2.2.2软件项目过程风险分析

1、 软件需求阶段的风险

软件的开发是从用户的需求开始，最后以书面的形式形成《用户需求规格说明》这一重要的文档。需求分析是开发方确认需求的可行性和一致性的过程，在此阶段开发方需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被逐级放大，我们把错误发现阶段与修复代价间的关系分成0-20，则后续阶段修复代价(如表2所示)，因此本阶段的风险最大。需求分析是软件设计及实现的基础，在整个软件开发中处于核心地位，需求分析中产生的风险是软件项目失败的主要因素。

表2 错误发现阶段与修复代价间的关系

2、 设计阶段的风险

设计阶段的主要任务是完成系统体系结构的定义，使之能够完成需求阶段的目标。因此需求本身的不完整和对需求分析的不完整及错误的描述或理解，都会在设计阶段被成倍地放大。

设计本身的风险主要来自于系统分析人员。分析人员在设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成本的激增。对用户来说系统的使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险，系统的稳定性也会受到影响。

从另一个角度上看，业务规则的变化，或说用户需求和将来软件运行环境的变化都是必然的情况，目前软件设计的所谓“通用性”是否就能很好的适应将来需求和运行环境的的变化，是需要认真折衷的，这种折中也蕴涵着很大的风险。

设计阶段蕴涵的另一种风险来自于设计文档。设计文档不健全不仅会造成实现阶段的困难，更会给后期的测试和维护工作带来灾难性的后果，例如根本无法对软件系统进行版本升级。

3、 实现阶段的风险

软件的实现从某种意义上讲是软件代码的生产。原代码本身也是文档的一部分，同时它又是将来运行于计算机系统之上的实体。源代码书写的规范性、可读性是该阶段的主要风险来源。规范的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到最低限度， 从而减小了系统整合的风险。

4、 运行、维护阶段的风险

从软件工程的角度看，软件维护费用约占总费用的55％～70％，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。

在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。

在软件系统运营期间，主要的风险源自于技术支持体系的无效运转。科学的方法是有一支客户支持队伍不断收集运行中发现的问题，并将解决问题的方法传授给软件系统的所有使用者。

2.2.3软件项目风险管理

软件项目风险管理是指软件项目组织对软件项目生命周期内可能遇到的风险进行识别、评估、应对和监控，以减少风险的概率和损失，尽可能以最小成本，在最大程度上实现项目目标的科学管理方法。软件项目风险管理主要包括两方面工作：预防风险，在风险没有发生或者风险尚未造成一定危害程度之前，采取积极主动的措施缓解和最小化可预见风险导致的损失；风险发生后的补救，即事先制定好风险发生后的应急措施，并风险发生后的第一时间执行应急措施。项目风险管理的三目标(进度、成本和质量)与项目管理的三目标是一致的。但是，对于软件项目而言，软件质量的风险问题多属于软件可靠性研究范畴，对于软件和软件开发过程的质量审度也有专门的部门（软件质量保证 SQA）和专门的学科分枝与相应技术来解决，如软件度量学、统计过程控制等。因而，在软件项目风险理中主要关注的是软件项目的进度和成本目标。

本文对现有软件项目风险管理架构体系及理论研究文献归纳总结后得出一个结论：软件项目风险管理是一个过程，是软件项目管理的重要组成部分。在软件项目生命周期中持续不断地识别、评估、控制风险是非常重要的。通常，将软件项目风险管理过程划分为五个步骤：风险管理规划、风险识别、风险评估、风险应对计划、风险监控（如图3所示）。

图 3

2.2.4软件项目风险评估与监控

1、 软件项目风险评估

软件项目风险评估，试图从两方面评估每一个风险：①风险发生的可能性或概率；②如果风险发生了，所产生的后果。

风险评估活动包括了4个活动：首先建立一个尺度，以反映风险发生的可能性；然后描述风险的后果；再估算风险对项目以及产品的影响；最后标注风险预测的整体精度，以免产生误解。

风险评估的依据是如下形式的三元组:[r,l,x]，其中，r表示风险，l表示风险发生的概率，x表示风险产生的影响。

进行风险评估必须定义一个风险参考水平值，对于大多数软件项目而言，主要的风险因素(性能、成本、支持、进度)也代表了风险参考水平值。即，对于性能下降、成本超支、支持困难、进度延迟(或这4种的组合)，都有一个参考水平值的要求，超过参考水平值就会导致项目被迫终止。如果风险的组合所产生的问题引起一个或多个参考水平值被超过，则工作

将会停止。

建立风险表，是一种简单的风险预测和评估技术，在第1列列出所有风险，第2列给出每个风险的类型，每个风险发生的概率值有项目组成员分别估算，然后求其平均值，得到一个具有代表性的概率值，将它写在第3列上，接下来就是评估每个风险所造成的影响。

根据概率及影响对风险进行排序。高发生概率、高影响的风险放在表的上方，低概率、低影响风险移到表的下方。在风险表上定义一条终止线：只有那些在线上的风险才会得到进一步的关注，而在线下的风险则需要再评估以完成第2次排序。

从管理的角度考虑风险影响及概率：一个具有高影响但发生概率很低的风险因素不应该花太多的管理时间；而高影响且发生概率为中到高的风险，以及低影响且高概率的风险，应该首先列入管理考虑之中。所有中止线之上的风险都必须进行管理。风险表中标有RMMM (risk mitigation monitoring and management)的列指向相应的风险缓解、监控和管理计划。风险表（如表3所示）。

表3 风险表

2、 风险缓解和监控

风险缓解是一种问题避免活动，风险监控是一种项目跟踪活动，是对解决风险的过程进行监控。风险监控还可以包括识别新的风险并将其反馈到正在进行的风险管理进程中等方面的工作。

风险监控的主要目的是评估一个被预测的风险是否真正发生了；保证为风险而定义的缓解步骤被正确地实施；收集能够用于未来风险分析的信息。

在很多情况下，项目中发生的问题可以追溯的不止一个风险，风险监控应该试图在整个项目中确定“起源”即什么风险引起了什么问题。

第三章 软件项目管理中的风险管理应对措施

软件风险要完全避免或消除，几乎不可能。但可以通过一些措施减轻或防止风险发生。下面提供几种方法可以帮助我们控制、减轻或防止风险发生。

1.接受风险

当采取其他风险规避方法的费用超过风险事件造成的损失数额时，可采取自留风险的方法。风险自留是处理风险最普通的方法，它可以是被动的，也可以是主动的。

2.规避风险

通常在两种情况下采用风险回避方法：

①某种特定风险所致的损失概率和损失程度相当大；

②应用其他风险处理技术的成本超过其产生的经济效益，采用风险回避措施可使项目受损失的可能性最小。采取风险回避策略，最好在项目活动尚未实施时，这时对项目损失最小。放弃或改变正在进行的项目，付出的代价一般都比较高。

3.缓解和降低风险

与风险回避相比，风险减轻措施是一种积极的风险处理手段，是指项目班子对不愿放弃也不愿转移的风险，通过降低其损失发生的可能性，缩小其后果不利影响的损失程度来达到控制目的的各种控制技术或方法。这类措施是对付无预警信息项目风险的主要应对措施之一，实际上就是减轻风险的措施。

4.转移风险

这类风险控制措施多数是用来对付那些概率小、但是损失大，或者项目组织很难控制项目风险的情况。转移风险的实现大多是借助于协议或合同，将损失的法律责任或财务后果转由他人承担。转移风险主要有五种方式：

①出售。通过买卖契约将风险转移给其他单位，类似于风险回避，区别在于风险有了新的承担者；

②发包。通过从项目执行组织外部获取货物、工程或服务而把风险转移出去。

第四章 总结

通过分析现有研究成果，作者对有关软件风险作出如下总结：

首先，软件产业是我国的基础性、战略性产业，也是信息产业发展的灵魂和核心之一。而软件项目由于其特殊性和复杂性，相比较于传统项目具有更高的风险。实践表明，软件项目的失败率极高，而缺乏有效的软件项目风险管理是公认的导致项目失败的重要原因之一。因此，研究软件项目风险管理理论与方法具有迫切性和实际意义。

其次，软件风险是在软件项目开始之后才开始对项目的开发起负面的影响，风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的失败。因此，在进行项目管理的过程中，必须采用适合自己的风险管理方法，进行风险管理，以确保软件项目在规定的预算和期限内完成。

最后,软件项目风险管理是一门实践性很强的学科,必须不断探求软件开发项目的规律和特点,紧密与软件工程的最新实践相结合,才会使其具有更强的生命力。

参考文献

[1] 卢有杰，卢家仪．项目风险管理[M]．北京：清华大学出版社，1998．

[2] 雷胜强．国际工程风险管理与保险[M]．北京：中国建筑工业出版社，1996．

[3] 张维迎．博弈论与信息经济学[M]．上海：上海人民出版社,1996．

[4] 卢有杰，卢家仪．项目风险管理[M]．北京：清华大学出版社，2000．__

[5] 丁义明,方福康.风险概念分析[J ] .系统工程学报,2001 , 16 (5) : 4022406.

[6] 覃征．软件项 目管理[M]．北京：清华大学出版社，2004．

[7] 黄全舟．软件开发过程与风险管理研究[J]_计算机工程与设计，2006，27(5)：786—788．

[8] 陶刘强，成筠．浅析软件开发中的风险管理[J]．中国管理信息化，2006(2)：88—90．

[9] 潘春光, 陈英武, 汪　浩 软件项目风险管理理论与方法研究综述 20## .5

[10] 赵蔷， 解争龙， 田俊华， 郭新明  软件项目风险管理研究 2007.7

[11] Hughes B,Cotterell M. 软件项目管理(廖彬山、王慧). 北京：机械工业出版社,2007:1~16，129~150.

[12] 刘钧. 风险管理概论. 北京：中国金融出版社,2005.

[13] 周松 刘竹旺 软件项目管理中的风险识别与管理.

[14]方德英，寇纪淞，李萍，等.IT 项目风险管理保障体系设计[J].商业研究，2006(342).

[15]左怀远，米根锁. 软件项目中的风险管理研究[J]. 世界科技研究与发展. 2008(03).