问软件质量风险管理？

EN

我将跳过回答问题中没有意义或主要是基于意见的部分。

1. 那么，哪个计划实际上应该包含风险管理，还是应该是一个完全独立的文档？

大多数软件组织根本不这样做，或者是不正式的，所以你可以做任何你想做的事情。如果您认为这真的很重要，您需要咨询组织中的某个人，或者您的客户，或者您与您的客户的合同，或者您与客户的合同所指的标准文档。

1. 什么是真正的风险缓解和应急(很少的例子将真正帮助我)？

差别是很微妙的。你有一个计划--叫它1计划--你担心出了什么问题。你可以通过采取措施来减轻风险，如果出了问题，这些措施会降低风险。应急是B计划，如果出了问题使A计划不可能，你可以使用它。

下面是一个例子。假设您计划在本周末部署一个新版本。这个版本有一些非常复杂的新特性，其中一些可能有严重的bug。缓解计划可能是支付整个开发团队本周末在现场的费用，以防出问题。一个应急计划可能是回滚到以前的版本，直到错误可以修复和测试。

注意示例中计划之间的区别。对于缓解计划，我们采取措施，使计划A成功，即使出了问题。有了应急计划，我们就有了B计划，以备A计划失败时使用。此外，缓解计划要求在A计划之前或期间做一些额外的事情(除了计划之外)，而应急计划不一定要求做任何额外的事情，除非计划A失败。

没有什么能阻止你有一个缓解计划和一个应急计划。我认为，真正的要点是，有不同的方法来规划风险。

1. 风险管理和事件管理是相同的还是不同的？如果不同，那么它们之间又有什么区别呢？

风险管理就是在事情出错的时候让事情继续运作。事件管理是关于调查为什么出了问题，并弄清楚如何防止它再次发生。

在坏事发生之前，你要制定一个风险管理计划。在坏事发生后执行事件管理。

例如，如果你是一个负责任的石油公司，而你的风险是漏油，你的风险管理计划可能是购买漏油保险。(这将是一个缓解计划，以防止你倒闭，以防你被迫支付一大笔钱来清理损失。)对石油公司来说，事故管理意味着确定石油泄漏的原因，以及如何以同样的方式防止另一次石油泄漏。

谈到这个行业的安全关键方面，我想说的是，您的风险管理计划应该从一个公司级风险管理策略开始，它说明您将如何管理您所有工作中的风险方面，例如风险如何分类、哪些文档、测试策略等必须到位，以及哪些类型的人可以签署哪些类型或级别的风险--这通常会列出各种规范，比如DO-178 B。这份文件通常会详细说明公司关于各种紧急情况的政策，包括责任保险以尽量减少财务风险、所需的工作人员背景和资格、分包政策等。

一般情况下，该公司须备存一份事故登记册，内载该公司产品的任何实际或接近问题。每次发生新的重大或严重事件时，都应定期对此进行审查，并用于检查是否需要审查或修改任何政策或程序。

然后，每个项目通常都会有一个风险管理计划，为该项目规定将要采取的步骤和可能的具体应急计划，以及一个风险登记册，用于记录在任何时候提出的任何可能的风险，以及为减轻具体风险而采取的行动，即确保这些风险不会发生，或者如果它们发生，则将影响降到最低。

“风险管理计划”应规定：

• 开发人员处理在风险登记册中确定的每个风险，以及他们如何记录他们为减轻每个已识别的风险而采取的行动。
• “测试计划”记录了如何进行测试，以确保开发人员成功地处理了风险登记册中确定的每个风险，可能不包括那些被评定为非常不可能且影响最小的风险，以及记录这一细节所需的文档。

不要忘记，开发人员、测试设计人员和测试人员都有专业的谨慎责任，以确保如果存在风险，他们可以合理地预测，无论是否在风险登记册中，影响用户或其他人的安全，他们应该确保将其添加到风险登记册中，并对其进行测试，以确保已经成功地减轻了风险，即:仅仅因为您在发生错误时有了保险，这并不意味着您可以忽略这种可能性。

不同的行业和不同的国家有不同的标准，以确保这些文档都是正确的，因为航空软件行业DO-178 C是最常用的。

只是一些适用的标准：

• DO-178C航空电子软件
• 安全评估程序( ARP4761 )
• ARP4754 (系统开发过程)
• DO-248B (关于DO-178B澄清的最后报告)
• DO-254 (类似于DO-178B，但用于硬件)
• IEC 61508电气/电子/可编程电子安全相关系统的功能安全
• ISO/IEC 12207 (软件生命周期过程开发标准) ED-153 (软件安全保证指南)修改后的_条件/决策_覆盖度-178 B航空航天