本标准描述了软件获娶供应、开发、运作和维护过程中的风险管理过程。本标准适用于软件项目中的风险管理，也可用于系统级或组织级风险的管理。 GB/T 20918-2007 信息技术 软件生存周期过程 风险管理 GB/T20918-2007 标准下载解压密码：www.bzxz.net

ICS_35.080
中华人民共和国国家标准
GB/T20918—2007
信息技术
软件生存周期过程
风险管理
Information technology---Software life cycle processes-Riskmanagement
2007-04-30发布
中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会
2007-07-01实施
规范性引用文件Www.bzxZ.net
术语和定义
本标准的应用
软件生存周期中的风险管理
附录A（资料性附录）
附录B（资料性附录）
附录C（资料性附录）
参考文献
风险管理计划
避险措施请求
风险处理计划
GB/T20918--2007
本标准的附录A、附录B和附录C为资料性附录。本标准由中华人民共和国信息产业部提出。本标准由全国信息技术标准化技术委员会归口。本标准起草单位：中国电子技术标准化研究所。本标准主要起草人：陈静、韩红强、王玮、杨根兴。GB/T20918—2007
GB/T20918-2007
软件风险管理是进行有效决策并与软件组织交流结果的关键准则。风险管理的目的在于，在潜在的管理和技术上的问题出现以前对其加以标识，以便采取措施减少或排除这些问题出现的概率和/或影响。风险管理是一个关键工具，有助于持续地确定项目计划的可行性，改进对于那些影响软件生存周期活动和软件产品质量与性能的潜在问题所进行的查找和识别，改进对于软件项目的积极管理。成功地实施本标准，可：
—标识潜在问题；
了解这些风险的概率和后果；
—确定所涉及风险的优先次序；一给出超出其风险阈值的每个潜在风险可供选择的处理建议；一对超出其值的风险选择合适的处理措施；监督每项处理措施的有效性；
——获取信息来改进风险管理策略；定期评价并改进风险管理过程和规程。本标准支持软件产品和服务的获取、供应、开发、运行和维护。本标准是为那些负责组织中定义、策划、实施或支持软件风险管理的人员而编写的。使用领域、软件项目或产品所在的软件生存周期的阶段和组织的具体特性将影响本标准在实践中的应用。本标准定义了一个适用于所有与软件有关的工程和管理准则的持续的软件风险管理过程。风险管理过程由许多重复运行的活动和任务组成。该过程定义了风险管理过程的最小活动集、要求的和获取的风险管理信息及其在管理风险中的用法。本标准所定义的风险管理过程适用于在组织级或项目级使用，也适用于不同类型和规模的项目及处在不同生存周期阶段的项目，并支持不同共利益者的观点。由于个别组织和项目将对本标准进行剪裁以满足其具体情况和需要，因此，本标准不规定为实施风险管理的任何具体风险管理技术或相关组织结构的用法。本标准的用户可参考IECStd60812：1985、IECStd61025：1990或IECGuide60300-3-9：1995的指南来选择和使用不同的风险分析技术与方法。然而，本标准无保留地支持使用能使风险管理成为一个持续过程的工具和技术。鼓励项目中的所有相关人员以电子形式获取并交流与风险有关的信息。本标准可单独使用，也可与GB/T8566一起使用。当单独使用本标准时，本标准提供了对应用于整个软件生存周期的软件风险管理过程的完整且自包含的描述。
当本标准与GB/T8566一起使用时，本标准在GB/T8566一2007所定义的软件生存周期过程集合中增加了一个管理风险的过程。这意味着本标准假定涉及风险处理的活动遵从GB/T8566的管理惯例。因此，典型的风险处理将使用相同的管理措施。本标准持这样的观点，软件风险管理是软件工程技术和管理过程的重要组成部分，它不能由一个单独的组织元素执行。如果出于某些原因，例如：由于软件项目的规模和性质、包含的风险的大小和数量，或者将不遵循GB/T8566，而要求由一个单独的组织元素来执行风险处理，则本标准仍适用。为便于与GB/T8566标准一起使用，本标准按GB/T8566的术语和格式进行编写。IV
1范围
1.1目的
信息技术软件生存周期过程
风险管理
GB/T20918—2007
本标准描述了软件获取、供应、开发、运作和维护过程中的风险管理过程。建议整个组织中的技术和管理人员都使用本标准。
本标准的目的是为软件供方，需方、开发者和管理者提供适合于管理广泛、多样的风险的一组过程要求。本标准不提供详细明确的风险管理技术，但致力于定义一个任何技术都可应用于其中的风险管理过程。
1.2应用领域
本标准定义了个惯穿于软件生存周期的风险管理过程。它适合由组织采用，用于所有适当的项目或单个项目。尽管添标准是为软件项目中的风险管理而编写的，但它也可用于系统级或组织级风险的管理。
本标准可以与GB/8566一起使用，也可以单独使用。1.2.1与GB/T8566寸起使用
GB/T8566描述软件的获取、供应开发，运作和维护的标准过程。该标准考虑刻积极地管理风险是成功进行软件项目管理的关键因素。/GB/T8566标准中多处提到风险和风险管理，但却没有给出风险管理的过程。本标准给出了这个过程。为了支持管理者、参与者和其他共利益者等各方的观点，在任何领域或生存周期阶段，本标准都可用于管理组织级风险或者项目级风险。在由GB/T8566所给出的生存周期过程框架中，风险管理是一个“组织的生存周期过程”。在一个组织级生存周期过程中使用该过程的组织负责该过程中的活动和任务。因此，组织应确保过程存在并发挥作用。
当和GB/T8566
起使用时，本标准慢定GB/T8566的其他管理和技术过程拟行风险处理，并描述与这些过程的正确关系
1.2.2单独使用本标准
本标准可以不依赖安任何特定的软件生存周期过程标准而单独使用：当以种方式使用时，将运用本标准风险处理的附加条款。1.3符合性
组织或项目在计划中列出并执行本标准第5章中描述的活动和任务中的所有要求（用“应”规定为必须执行的），就可以声称符合本标准。在不依赖于GB/T8566而使用本标准的那些实例中有关风险处理的附加要求在5.1.4.2中给出。
1.4免责声明
本标准建立了软件风险管理过程、活动和任务的最小要求集。实施这些要求，或根据本标准编写软件风险管理计划或软件避险措施请求，并不能确保与软件相关的风险或其他风险消失。符合本标准的任一团体并不能免除任何社会、道德、财务或法律的责任。2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注目期的引用文件，其随后所有1
GB/T20918-2007
的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。信息技术软件生存周期过程（GB/T8566--2007，ISO/IEC12207：1995、GB/T8566
1SO/IEC12207/Amd.1:2002、ISO/IEC12207/Amd.2:2004,IDT)GB/T18492-2001
3术语和定义
：系统和软件完整性级别（idtISO/IEC15026：1998）信息技术
下列术语和定义适用于本标准。3.1
后果consequence
事件的结果，
注1：一个事件可能有多个后果。注2：后果可能是正面的，也可能是负面的，然而，安全方面的后果总是负面的。注3：后果可以定量或定性地表示。3.2
事件event
一组特定情形的出现。
注1：事件可能是确定的，也可能是不确定的。注2：事件可能是单个出现，也可能是一系列出现。注3：事件发生的概率可在一段时间内进行估计。3.3
相关方
interested party
对一个组织的业绩或成就感兴趣的个人或团体。例如：顾客、所有者、组织内的人员、供方、银行家、合作伙伴和社团。
注：团体可包括一个组织、组织的一部分或多个组织。3.4
概率probability
事件可能发生的程度。
注1：IS03534-1：1993中的1.1给出了概率的数学定义：随机事件的概率是0～1之间的一个实数.它与很长时间内事件发生的相对频率有关，或与事件可能发生的置信度有关。对于高置信度的事件，其概率接近于1。注2；描述风险时可以使用频率，面不使用概率。注3：可用类别或等级来选择概率的置信度，如：稀少、不一定、中等、很可能、几乎一定，或者难以置信、不太可能、可能性极小、偶然、很可能、频繁的。3.5
项目风险概要
project risk profile
项目当前的和历史上的与风险相关的信息：在一个项目中，所有单个风险概要的摘要或汇集，注：项目风险概要信息包括风险管理环境，按年代顺序排列的风险记录及它们的单个风险概要、优先次序、风险相关的测度、处理状态、应急计划和避险措施请求。项目风险概要包括所有单个风险的风险概要的集合，还包含当前的和历史上的风险状态。见风险概要和风险状态，3.6
事件的概率及其后果的组合。
注1：术语\风险”通常仅用于至少存在负面后果可能性的情形。注2：在某些情况下.风险从偏离期望的结果或可能的事件中产生。2
注3：见ISO/IEC指南51中与安全有关的议题。risk acceptance
风险接受
接受风险的决定。
注：风险接受取决于风险准则。3.8
riskaction request
避险措施请求
对于所确定的超过阈值的一个或多个风险而建议的处理可选方案和支持信息。3.9
风险类别
riskcategory
对风险源类型的描述(例如，技术、法律、组织、安全、经济、工程、费用和进度）。3.10
风险准则
risk criteria
评估风险重要性所引用的条款。GB/T209182007
注：风险准则包括相关代价和利益、法律和法定需求、社会经济和环境方面、共利益者关系、优先权及其他评估输人。
风险预估
riskexposure
风险给个人、项目或组织造成的潜在损失；风险出现概率及其出现后果大小的函数，注：风险预估通常定义为概率和后果大小的乘积，即，预期值。本标准采用包括风险预估的定性表示的更广义的观点。
riskmanagementplan
风险管理计划
对一个组织或项目内执行风险管理过程的要素和资源如何实施的描述。3.13
riskmanagementprocess
风险管理过程
在整个产品或服务的生存周期中，系统地标识、分析、处理和监督风险的一个持续的过程。3.14
风险管理体系
riskmanagementsystem
在组织的管理体系中涉及管理风险的要素的集合。注1：管理体系要素可包括战略策划、决策和处理风险的其他过程。注2：风险管理体系中反映组织文化。3.15
风险概要
riskprofile
一个风险的当前的和历史上的风险状态信息按年代顺序排列的记录。3.16
风险状态
riskstate
与单个风险有关的项目风险信息注：涉及单个风险的信息可包括当前描述、起因、概率、后果、估计范围、估计置信度、处理、阅值及风险达到其阔值时间的估计。
直riskthreshold
风险阐值
引发一些共利益者采取措施的条件。注：基于不同的风险准则，可以为每个风险、风险类别和风险组合定义不同的风险阈值。3
GB/T20918—2007
风险处理risktreatment
选择并实施缓解风险的措施的过程。注1；术语\风险处理”有时用于表示--些风险处理措施。注2：风险处理措施包括避免、缓解、转移或接受风险。3.19
（风险）源source
具有潜在后果的项或活动。
注：在安全的环境中，源是一个危险（引用ISO21EC指南-51：1999）3.20
共利益者stakeholder
对风险产生影响、受风险影响或感到自已受风险影响的任何个人、团体或组织。注1：决策人员也是共利益者。
注2：术语\共利益者\括有关当事人，但比其含义更广（当事人在IS09000.2000中定义）4本标准的应用
为便于和GB/8566一起使用，本标准用与GB/T8566的过程描述相同的约定编写。这里讨论的风险管理生存周期过程可分为十系列活动，每个活动的需求又规定为一系列任务。二级条（X.X)表示过程，三级条（X。XJX）表示活动，四级条（X.X.X.×）表示任务。在GB/T8566所给出的软件生存周期过程框架中，风险管理是十个“组织级生存周期过程”。在一个组织级生存周期过程中，使用该过程的组织负责该过程中的活动和任务。组织应确保过程存在并发挥作用。
本标准支持软件产品和服务的获取、供应、开发、运作和维护。应用本标准不需特殊的软件生存周期过程模型。
软件风险管理在与组织的风险管理过程一起使用时最有效。本标准的过程、活动和任务应与组织的其他风险管理的惯例和系统融为一体。如果组织没有风险管理过程，本标准也可作为建立组织风险管理过程的指南。
此外，虽然本标准的应用集中于软件风险，但该过程也应与组织的问题管理方法相结合并协调一致，例如，在必须实施应急计划的情况下，风险处理活动应以与其他项目管理活动相同的方式进行管理。软件生存周期中的风险管理
5.0风险管理目的
风险管理的目的在于持续地标识并缓解风险。成功实施风险管理的结果为：确定了风险管理的执行范画，
b）定义并实施了适当的风险管理策略；在策略中标识了风险，并在项目执行期间随其进展标识风险；c）
分析风险，确定了使用有关资源来监督这些风险的优先次序；d)
定义、应用并评估了风险测试，以便确定风险状态的变更和监督肾活动的进展；采取了适当的措施来减缓或避免风险的影响。f）
5.1风险管理过程
在整个产品或服务的生存周期中，风险管理过程是一个持续地系统地处理风险的过程。该过程包括下列活动：
a）策划并实施风险管理；
管理项目风险概要；
执行风险分析；
执行风险监督；
执行风险处理；
评价风险管理过程。
GB/T20918—2007
风险管理过程如图1所示。注意，假定执行风险处理是全部技术和管理过程的一部分。①技术和管理
管理决策
②策划和实施
风险管理
改进行动
③执行风险处理
项目风险概要和
避险措施请求
执行风险分析
③管理项目
风险概要
③执行风险监督
项目风险概要
?评价风险管理过程
图1风险管理过程模型
下面论述中的数字表示图中相应的方框。涉及共利益者的管理和技术过程定义了风险管理过程必须支持的信息需求（即：共利益者需要做出涉及风险的决定的信息)①。将这些信息需求传递给“策划和实施风险管理”和“管理项目风险概要”活动。在“策划和实施风险管理\活动②中定义了将执行的风险管理的总的方针政策、要使用的规程及要应用的专门技术等。
在“管理项目风险概要”活动③中，收集当前的和历史的风险管理环境及风险状态信息。项目风险概要包括所有单个风险概要（即：关于单个风险的当前的和历史的风险信息）的汇总，及所有的风险状态。
“执行风险分析”活动④识别风险，确定其可能性及结果，确定其风险预估，并为已确定的将超出风险值的风险准备避险措施请求的处理建议。在整个“执行风险分析”活动中，持续地更新和维护项目风险概要信息。
将处理建议与其他风险状态及其处理状态一起送至管理部门③进行评审。对发现的任何不可接受5
GB/T20918-2007
的风险，管理部门决定执行什么风险处理，为要求处理的风险制定风险处理计划，使这些计划与其他管理计划和其他正在进行的活动相协调。在\执行风险监督”活动③期间，持续地对所有风险进行监督，直到不再需要监督为止。此外，要寻找新的风险和新的风险源。
要求定期评价风险管理过程，以确保其有效性。在“评价风险管理过程”活动②中，为改进过程或改进组织的或项目的能力以管理风险，收集用户的和其他的反馈信息。在“策划和实施风险管理”活动②中，实施作为评价结果规定的改进。在整个产品生存周期中，持续地应用软件风险管理过程。不过，一旦风险管理过程开始，风险管理过程的活动和任务就以送代的方式与单个风险交互作用。例如，在执行风险分析活动④中，在评价任务本身时，由于获取的风险方面的知识的增加，使得在执行风险评价期间，风险可能被重新估计好几次。风险管理过程不是“瀑布”过程。5.1.1策划并实施风险管理
“策划和实施风险管理”活动的目的在于建立一个软件风险管理过程。只要建立了组织风险管理过程，相应的软件风险管理过程就宜与之相匹配。本活动应确定执行风险管理的人员，定义所要使用的特殊风险管理过程，分配实施过程所需的资源，并定义如何在共利益者间沟通和协调风险及其处理。本活动宜在项目的开始就执行。活动中所产生的信息应记录在类似附录A的风险管理计划中。注：IEEEStd1058：1998要求，在软件项目管理计划中应有风险警理计划的文档集。本活动包含5.1.1.1～5.1.1.5中所列的任务。5.1.1.1确定风险管理方针
应明确定义描述风险管理的风险管理方针。在这些方针下，风险管理得以执行。这些方针应支持收集共利益者所需的风险相关信息。这些方针宣涉及：a）管理和人员如何实施、监管并支持风险管理；b）如何获取并维护共利益者正在进行的风险管理承诺；如何协调共利益者间的风险管理过程；c）
d）如何完成风险管理过程中的人员定位和培训；e）共利益者如何、多长时间沟通并评审风险信息，例如项目风险概要；如何使资源可用于处理风险。
只要可行，政策宜与现有的组织风险管理政策相结合。可以引用定义上述政策的已形成文档的组织风险管理政策，但是项目的特征要形成文档，5.1.1.2确定风险管理过程
要实施的风险管理过程的描述应形成文档并予以公布。实施风险管理过程的规程描述宜包括：a）对风险进行重新分析和监督的频率；b）要求的风险分析类型（定量和/或定性）；用于估计风险概率和后果的标度和说明，以其测量不确定性；c）
使用的风险阈值类型；
用于追踪和监督风险状态的测度类型；e）
风险处理的优先顺序如何；
风险管理过程支持的共利益者的看法；g）
需考虑的风险源和风险种类。
在这个任务中，宜选择与项目情况匹配的风险管理过程、特殊规程和技术。注：IEC60300-3-9:1995指南提供了选择和使用常用的风险分析技术的指南。IECStd61508-7：2000提供了与测度有关的有用材料和与软件安全性有关的技术。只要可行，风险管理过程宜与现有的组织风险管理过程密切结合。可以引用定义了前面所列内容6
的已形成文档的组织风险管理过程，但是项目的待征要形成文档。5.1.1.3确定职责
GB/T20918—2007
应明确地标识负责执行风险管理的部门及其角色和职责。在组织单位内，应指定部门负责风险管理过程。
5.1.1.4分配资源
应给予负责部门足够的资源来执行风险管理过程。5.1.1.5确定风险管理过程评价
应给出有关评价和改进风险管理过程的过程描述，以及获取什么样的信息以总结经验教训。任何运用本过程之前获得的经验教训都宜加人到本过程的实现中。5.1.2管理项目风险概要
“管理项目风险概要”活动的目的在于产生-个随着风险处理而展开的历史的和当前协调的风险呈现视图，使风险能充分、简洁地与相关的共利益者沟通。它包括风险管理环境、当前风险状态及风险历史。
在整个软件生存周期内应对项目风险概要进行维护。本活动包含5.1.2.1~5.1.2.4所列的任务。5.1.2.1定义风险管理环境
应定义风险管理过程环境，并形成文档。风险管理环境的定义应包括避险措施请求支持的一个或多个共利益者观点的描述，以及要对其进行管理的一个或多个风险种类。对于特别重要的软件安全保密性、安全性或其他种类的软件风险可分别进行说明。
注：可将IEEEStd1228：1994、1ECStd60300系列标准、IECStd61508系列标准和本标准一起用于说明与软件安全性有关的风险。
风险管理环境的定义也应包括下列技术和管理上的描述：a）目标（例如，项目成功所必须满足的关键技术、政治或经济性能准则是什么？)；b）假定（例如，除项自控制之外还应考虑的？）；c）约束条件（例如，对项目进行了什么限制？)。也宜包括可能影响风险分析或风险处理（例如，项目是否能公开地沟通与风险相关的信息，或是否有原因禁止)的任何其他相关信息。5.1.2.2确定风险阐值
定义风险接受条件的风险阀值应在每个风险的风险状态中定义并形成文档。风险阅值是无需共利益者明确评审便可接受的受测风险准则的最大级别。应为单个风险或风险组合定义风险阈值。也应给作为一个整体的项目定义风险值。宜依照GB/T18492-2001的规定，从系统完整性级别推导出软件的风险阈值。也可根据成本、进度、技术和其他相关后果或预估值定义风险阀值。表明某个风险何时可能超过其风险阀值的测度应在其风险状态中定义并形成文档。注：IEEEStd1012：1998描述了在策划验证和确认活动时如何使用完整性级别。GB/个18492一2001论述了款件完整性级别的用法。IEC61508-5：1998提供了确定安全性完整性级别的方法。5.1.2.3确定并维护项目风险概要应确定并维护项目风险概要。项目风险概要包括全部的项目风险信息、所有单个风险的风险概要的汇集，也包括当前的和历史的风险状态。项目风险概要至少应包括：a）风险管理环境；
按时间顺序排列的每个风险状态的记录，包括它们的概率、后果和风险值；c）根据共利益者提供的风险准则而定的每个风险的优先次序；d）避险措施请求及其处理状态。7
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。