系统工程：风险识别
风险识别的目的是对事件的早期和连续识别，如果发生，这些事件将对项目实现绩效或能力结果目标的能力产生负面影响。它们可能来自项目内部或外部来源。
风险识别是风险管理过程中的关键第一步，其中还包括：
阅读风险管理简介要了解有关最初在Miter Systems工程指南中发表的有关此资源集合的更多信息。
风险标识：上下文
风险识别是风险管理过程的关键第一步。
风险识别的目的是对事件的早期和连续识别，如果发生，这些事件将对项目实现绩效或能力结果目标的能力产生负面影响。它们可能来自项目内部或外部来源。
有多种类型的风险评估，包括计划风险评估，风险评估以支持投资决策，替代方案分析以及对运营或成本不确定性的评估。风险识别需要匹配支持风险知名决策所需的评估类型。对于收购计划，第一步是确定计划目标和目标，从而在整个团队中促进对计划成功所需的内容的共同理解。这给出了上下文，并界定了确定和评估风险的范围。
MITER SE角色和期望：预计从事政府计划的斜切系统工程师（SES）将确定可能影响该项目和计划的风险。期望他们编写和审查清晰，明确且得到证据支持的风险陈述。
确定系统工程计划中的风险
有多种风险来源。对于风险识别，项目团队应审查计划范围，成本估算，时间表（包括对关键路径的评估），技术成熟度，关键绩效参数，绩效挑战，利益相关者的期望与当前计划，外部和外部依赖关系，实施，实施挑战，集成，互操作性，可援助性，供应链漏洞，处理威胁的能力，成本偏差，测试事件期望，安全，安全等。此外，来自类似项目，利益相关者访谈和风险清单的历史数据为考虑风险的领域提供了宝贵的见解。
风险识别是一个迭代过程。随着计划的进行，将获得有关该计划的更多信息（例如，特定设计），并将调整风险声明以反映当前的理解。随着项目在整个生命周期的发展，新风险将被确定。
最佳实践和经验教训
- 操作风险。了解您支持的功能的运营性质以及对最终用户，他们的任务及其功能运营的风险。了解操作需求/任务将有助于您欣赏风险的严重性及其对最终用户的影响。这是风险分析的关键部分，意识到如果在运营期间出现风险，可能会出现现实世界的影响。通常，如果操作用户能够完成任务（例如，任务保证），则愿意接受一定程度的风险，但是您需要帮助用户了解他们接受的风险并评估选择，余额和替代方案可用的。
- 技术成熟度。与行业和学术界合作并利用行业和学术界，以了解所考虑的技术以及随着时间的推移的可能过渡。一种方法是根据不披露协议与供应商合作，以了解能力及其去向，以便评估风险。
- 非发育项目（NDI）。NDI包括商业企业和政府武装项目。要管理风险，请考虑NDI提供商的生存能力。提供商有市场份额吗？与竞争对手相比，提供商是否具有适当的寿命？提供商如何解决功能问题和发布修复等？特定NDI的用户群是什么？提供商可以演示NDI，最好在类似于客户的设置中？政府可以使用NDI创建原型吗？所有这些因素将有助于评估NDI和提供商的可行性风险。从其他委托该地区或使用已评估的NDI的斜切人员那里寻求答案。
- 收购驱动程序。强调关键能力推动者，尤其是那些替代方案的能力。评估并确定主要驱动因素，并强调其在制定降低风险建议时相关的风险。如果能力的特定方面对其成功并不重要，则应评估其风险，但不必是风险管理的主要重点。例如，如果提出的用户界面有风险，但是市场有许多替代方案，那么所提出的方法的成功可能对能力的整体成功而言至关重要。另一方面，信息安全功能可能至关重要。如果只有一种替代方法满足需求，则应强调它。通过评估需求和设计并确定存在的替代方案来确定主要的成功驱动因素。成功的关键途径是独特的解决方案吗？确保关键的路径分析包括整个系统工程周期，而不仅仅是开发（即系统开发本身，可能是“小菜一碟”，但是在积极的操作情况下进行范围可能是一个主要风险）。
- 使用能力演变来管理风险。如果特定的要求是推动由于独特的开发，Edge-Edevelope绩效需求等而导致高风险的实施，则应与用户讨论其关键性。可能会推迟需求，并且开发界应评估未来何时满足。帮助用户和开发人员衡量特定能力应承担的风险（以及时间表和成本影响）应对要求更快地获得风险较小的能力。在制定建议时，请考虑技术的可行性和有关相关实施成功的知识，并没有评估现在实施而不是未来的风险。在推迟能力时，请注意不要通过交易近期轻松成功的陷阱，以换取可能对整体成功至关重要的多种高风险要求的未来。
- 关键性能参数（KPPS）。与用户紧密合作以建立KPP。计划取消的总体风险可以集中在未能满足KPP的情况下。与用户合作，以确保参数能够响应任务需求并在技术上可行。这些参数不应如此宽大，以至于可以轻松满足他们的任务需求；他们也不应该如此严格，以至于没有大力的努力或推动技术就无法满足他们的身份，这两种技术都可以使计划处于危险之中。寻求过去的运营，实验，绩效评估和行业实施的结果，以帮助确定绩效可行性。
- 外部和内部依赖性。拥有企业的观点可以帮助收购方，计划经理，开发人员，集成商和用户欣赏开发工作依赖性的风险。随着以服务为导向的方法的出现，该计划将更加依赖于他们打算在计划开发工作中使用的其他人提供的服务的可用性和操作。与服务开发商合作，以确保创建高质量的服务，并将思想投入到这些服务的维护和发展中。与开发计划人员合作评估可用的服务，其质量以及计划在使用和依赖该服务方面的风险。同样，与创建服务相关，而不是使用其他企业工作的服务有风险。帮助确定在未来的某个时间过渡到企业服务的内部服务的风险和潜在利益。
- 集成和互操作性（I＆I）。我几乎将永远是主要的危险因素。它们是依赖性的形式，在这些形式中，已经判断整合或互操作的价值覆盖其固有的风险。企业联合架构，按需组合功能和设计模式等技术可以帮助政府计划并执行导航I＆I风险的路线。
- 网络安全。网络安全几乎是每个发展的风险。其中一些是由于该领域政府需求和要求的独特性。其中一些是因为在反对网络攻击方面存在固有的困难。创建防御能力来覆盖攻击的范围是具有挑战性和风险的。帮助政府开发弹性方法（例如，应急计划，备份/恢复等）。在与国际合作伙伴的联盟运营中，跨系统启用信息共享提出了技术挑战和政策问题，这些问题转化为发展风险。与供应链管理相关的信息安全问题是如此广泛而复杂，以至于即使对威胁的基本认识也是一个巨大的挑战。
- 技能等级。开发商，集成商，政府和其他利益相关者的技能或经验水平可能导致风险。寻找不足的技能，并在整个公司范围内填补任何空白。这样一来，请帮助您同时教育政府团队成员，以携带公司技能和经验。
- 成本风险。计划通常会创建政府的成本估算，以考虑风险。当您开发和完善该计划的技术和其他风险时，相关的成本估计也应发展。成本估计不是一次性活动。
- 历史信息作为风险识别指南。来自类似政府计划的历史信息可以为未来的风险提供宝贵的见解。在采取行动报告，练习摘要和实验结果之后，在各种操作课程中寻找有关操作挑战和风险的信息。客户经常有这些存储库可以访问。政府领导人通常会传达其战略需求和挑战。了解并将其分解为您对客户所需的最重要功能的评估，并作为风险评估的基础。
过去的绩效评估和收购计划和承包商的经验教训经常获得帮助评估风险的历史数据。在许多情况下，MITER员工将协助政府为特定收购准备绩效信息。AF具有过去的绩效评估指南（PPEG），该指南识别可用于未来政府来源选择的信息类型。该信息存储库可以帮助提供以前挑战的背景信息，以及它们可能再次出现的何处，包括特定类型的开发活动以及特定承包商。
供应商产品有许多技术评估，可以访问以确定各种产品的风险和生存能力。工具评估评估的一个斜切存储库是包含有关分析工具的指导和经验的分析工具。使用此类资源，并寻求其他尝试过原型和实验产品和技术的人，可以帮助评估特定努力的风险。 - 如何写风险 - 最佳实践。编写风险陈述的最佳实践协议是条件 - 然后构造。该协议适用于为几乎任何环境设计的风险管理过程。人们认识到，风险本质上是概率的，如果发生的话，这种风险会带来不必要的后果。
是什么条件 - 然后构造？这健康）状况反映今天已知的内容。这是确定风险事件的根本原因。就这样健康）状况是发生的事件，目前正在发生，或者将确定发生。风险事件是未来可能发生的事件健康）状况当前的。
这如果是与健康）状况当前的。认识到如果和健康）状况作为双重。共同检查时，可能会有一些方法可以直接干预或纠正风险事件的根本根（健康）状况）使得该事件的后果（如果发生）不再威胁到该项目。这如果是风险陈述的概率部分。
这然后如果发生风险事件，将会影响工程系统项目的后果或后果。 - 鼓励团队确定风险。一些政府项目和计划中的文化阻止了风险的识别。这可能是因为跟踪，监测和缓解风险的风险管理活动被视为繁重而无助。在这种情况下，与团队讨论识别风险的好处以及无法在您的脑海中管理所有这些的好处（例如，确定优先级，需要参与的人，缓解措施）可能很有用。协助政府团队执行一个流程，该过程将管理投资与项目成果之间的价值保持平衡。总的来说，当项目范围，时间表和成本目标得到满足或通过行动计划成功缓解时，正在实现良好的平衡，项目团队认为风险管理活动为项目提供价值。跨队表示是必须;风险不应由个人或系统工程团队严格确定（上面的风险来源）。
- 考虑组织和环境因素。组织，文化，政治和其他环境因素，例如利益相关者的支持或组织优先事项，与仅技术因素构成更大或更多的风险。这些风险应在整个项目的一生中确定并积极缓解。缓解活动可能包括监视可能影响计划或项目任务的立法授权或紧急变更，可能影响用户要求或能力有用性的组织变更，或者可能影响资金的政治支持的变化。在每种情况下，考虑对计划的风险，并确定与利益相关者讨论的行动选择。
- 包括利益相关者在风险身份识别中。项目和计划通常具有多个利益相关者，这些利益相关者为结果带来各种风险。他们包括运营商，他们可能被新系统不堪重负；用户，可能没有经过适当培训或担心自己的工作；可能不支持新能力的主管似乎会降低其权威；和政策制定者，他们关注立法批准和成本。此外，重要的是要包括所有利益相关者，例如认证和认证机构，如果无意间忽略，则可以在该计划后期构成主要风险。利益相关者可能会敏锐地意识到各种环境因素，例如未决的立法或政治计划支持，这可能会给政府或委员会项目团队不知道的项目带来风险。将利益相关者包括在风险识别过程中，以帮助浮出这些风险。
- 写清晰的风险声明。使用条件 - 如果以后的格式有助于交流和评估风险陈述并制定缓解策略。根本原因是引入风险的潜在条件（例如，设计方法可能是原因），IF反映了概率（例如，概率评估是否会发生风险陈述的IF），然后传达对计划的影响（例如，增加资源以支持测试，额外的时间表和疑虑以达到绩效）。基于明确阐明的风险陈述，缓解策略几乎总是更好。
- 随着风险评估和缓解策略的制定，预计风险声明修改。一旦团队评估影响，就可以完善风险声明是通常的。在评估和记录潜在风险影响（成本，时间表，技术或时间表）时，对风险的理解和陈述可能会发生变化。例如，在评估软件计划单的风险影响时，可能会完善风险声明，包括需要按日期和/或进一步澄清影响。
- 请勿在风险声明中包括缓解声明。请注意不要将缓解声明引入风险声明的陷阱。风险是潜在的负面影响的不确定性。有些人迅速跳动到缓解风险的结论，而不是确定应减轻的风险（通过确定的缓解措施），而是将风险识别为次优的设计方法。例如，风险陈述可能是：如果承包商不使用XYZ进行测试，则测试将失败。关注的是测试充足。如果承包商不用可测量的结果进行分析测试，则该程序可能不会通过有限的用户测试。使用XYZ可能是减少测试充足风险的缓解选择。
- 在评估风险概率和影响之前，请勿跳入缓解策略。考虑进一步分析，可能会改进或更改风险，这可能会影响最有效/最期望的缓解措施。工程师经常跳入解决方案。最好转到“风险影响评估”和“优先级”文章中讨论的下一步，首先分解和理解问题。最终，这将导致一项与关注点密切相符的策略。