设计任何相关利益系统(SoI)的出发点是了解潜在问题或机会所在的社会经济和技术背景。然后,企业战略目标和涉众需求、期望和需求代表了从业务或企业决策者的角度来看的问题或机会,同时也考虑了用户、收购方和客户的观点。
任务分析(MA)是更大的一组概念定义活动的一部分—— 一组系统工程活动,在这些活动中,业务或企业和涉众的问题空间和需求被仔细检查。这发生在开发任何正式的(SoI)定义之前,但可能需要在整个生命周期中重新审视。事实上,Concept Definition的活动决定了企业战略目标和业务需求是否将由新系统、对现有系统的更改、服务、操作更改或其他一些解决方案来处理。MA活动集中于确定解决方案的主要目的(它的“任务”),而涉众需求和需求活动则探索涉众在完成任务时希望拥有什么能力,并可能包括解决方案某些方面性能的一些细节。MA经常与涉众需求和需求活动一起迭代执行,以更好地理解问题(或机会)空间,以及解决方案空间。
目的和定义
MA 的目的是了解任务/市场问题或机会,分析解决方案空间,并启动可以解决问题或利用机会的潜在解决方案的生命周期。 MA 是一种与需求、能力差距或机会和解决方案相关的战略或运营分析,可应用于任何为其业务目标发展战略的组织。
MA,在某些称为 市场分析或业务分析的领域中,是对企业内运营问题或机会的识别、表示和评估。 问题空间中任务或业务功能的定义框架解决方案,无论是从直接应用到任务或业务功能方面,还是从结果解决方案的上下文方面来看。
MA 用于定义需要(或期望)的操作动作,而不是硬件/软件功能; 也就是说,它专注于定义问题空间,而不是解决方案空间。 MA 从业务愿景和运营概念 (ConOps) (IEEE. 1998) 以及包括使命(或业务职能)在内的其他组织战略目标和目标开始。 MA的主要产品是业务或任务需求,由初步生命周期概念支持——包括初步采购概念、初步运营概念(OpsCon)、初步部署概念、初步支持概念和初步退役概念. 然后将业务或任务需求详细说明并正式化为业务或任务需求。
MA 可能包括数学分析、建模、仿真、可视化和其他分析工具,以表示预期任务并确定如何最好地实现需求/目标。 MA 评估替代方法,以确定哪种方法最能支持利益相关者的需求(在物资和非物资解决方案备选方案中,也称为产品解决方案和服务/运营解决方案)。 因此,MA 定义问题空间并使用由企业目标驱动的质量属性约束来分析解决方案空间备选方案。
原理和概念
任务分析和作战概念
MA 以及术语 ConOps 和 OpsCon 在美国和英国的国防和航空航天组织中广泛用于分析和定义系统的预期运行方式,以及主要运行或运行场景的预期执行方式。 它们考虑了已识别场景的战略、运营和战术方面。 ANSI/AIAA G-043A-2012 (ANSI 2012) 确定术语“操作概念”和“操作概念”通常可以互换使用,但指出存在重要区别,因为它们都有不同的目的并用于满足不同的目的. ConOps 处于组织层面,由企业管理层准备并由业务管理层细化:
在组织层面,ConOps 解决了领导层运营组织的预期方式。 它可能指使用一个或多个系统(如黑匣子)来转发组织的目标和目的。 ConOps 文档描述了组织对业务内的整体运营或一系列运营的假设或意图,涉及要开发的系统、现有系统和可能的未来系统。 该文件经常体现在长期战略计划和年度运营计划中。 ConOps 文档作为组织指导未来业务和系统的整体特征的基础。 (ISO/IEC 2011)
ConOps 通知 OpsCon,OpsCon 由业务管理在任务分析活动中起草,并由利益相关者在 利益相关者需求和要求 活动中细化:
系统 OpsCon 文档描述了系统将做什么(而不是如何做)以及为什么(基本原理)。 OpsCon 是面向用户的文档,从用户的角度描述了待交付系统的系统特性。 OpsCon 文档用于向收购方、用户、供应商和其他组织要素传达整体的定量和定性系统特征。 (ISO/IEC 2011)
需要注意的是,OpsCon 有一个运营重点,应该得到其他概念的开发支持,包括部署概念、支持概念和退役概念。
为了确定适合不断发展的企业能力的技术解决方案,系统工程 (SE) 领导者与企业领导者和运营分析师互动以了解:
- 企业 ConOps 和未来的使命、业务和运营 (MBO) 目标;
- 作战概念和目标的特征(即约束、任务或作战场景、任务、资源、风险、假设和相关任务或作战);
- 当前如何执行具体任务或行动以及在这些领域存在哪些差距。
然后,他们在概念上探索并从备选的候选解决方案中进行选择。 这种交互确保了对问题空间和解决方案空间的全面理解。 备选的候选解决方案可以包括满足需求的各种方法,以及优化特定特性的方法的变体(例如,使用不同的卫星轨道参数分布来最大化覆盖或事件,同时最小化卫星数量) . 分析、建模和仿真以及贸易研究被用来选择替代方法(NDIA 2010)。
任务分析、ConOps 和 OpsCon 的概念也用于工业部门,例如航空管理和航空运输、医疗保健系统以及具有调整定义和/或术语的空间,例如操作概念、使用概念和/或技术概念. 例如,“任务分析”是用来描述卫星轨道的数学分析,以确定如何最好地实现太空任务的目标(ESA 2008)。
在业务领域,MA 通常主要作为市场分析进行。 维基百科将市场分析定义为一个过程:
. . . 研究特殊行业内特殊市场的吸引力和动态。 它是行业分析的一部分,而这又是全球环境分析的一部分。 通过所有这些分析,可以确定公司的机会、优势、劣势和风险。 最后,在优势、劣势、机会和威胁 (SWOT) 分析的帮助下,将定义公司的适当业务战略。 市场分析也称为市场记录调查,用于为公司的计划活动提供信息,特别是围绕库存、采购、劳动力扩张/收缩、设施扩张、资本设备购买、促销活动等决策公司的其他方面。 (维基百科贡献者,2012)
在任何使用这些概念的地方,很明显它们基于基本概念,例如操作模式(或系统状态)、 场景 (操作)、企业级 ConOps 和系统级操作概念、功能等. 关于ConOps和操作概念的更多解释,请参考 系统和软件工程-需求工程 (ISO/IEC 2011); 有用的信息可以在附件 A,“系统操作概念”和附件 B,“操作概念”(ISO/IEC 2011)中找到。
作为企业战略发展一部分的使命分析
大多数企业会定期根据其使命、愿景和定位重新评估其战略以实现其目标。 图 1 显示了企业战略开发和概念定义的交互,包括 MA 和利益相关者的需求和要求 活动,这些活动以迭代的方式参与,以充分开发战略并定义未来的能力和解决方案。
图 1. 企业战略和概念开发(Roedler 2012)。经 Garry Roedler 许可使用。 所有其他权利均由版权所有者保留。
随着企业发展战略,有必要对企业的每个要素进行支持性 MA 或战略分析,以确定实现未来目标的准备情况。 该分析检查当前状态以识别与目标实现相关的任何问题或机会,并帮助企业充分理解和定义问题空间。 该分析检查外部环境和接口以寻找影响和趋势,以及内部企业以衡量其能力和价值流差距。 此外,可以执行优势、劣势、机会和威胁 (SWOT) 分析。 随着问题空间的定义,利益相关者的需求也被定义并转化为利益相关者的需求,从而定义了所需的解决方案。 这些需求包括满足客户和任务需求的需求、企业核心流程和能力的未来状态,以及支持这些流程和能力绩效的推动因素。 最后,MA 再次参与检查解决方案空间。 确定跨越潜在解决方案空间的候选解决方案,从简单的操作更改到各种系统开发或修改。 应用各种技术来分析候选者,了解它们的可行性和价值,并选择最佳替代品。 确定跨越潜在解决方案空间的候选解决方案,从简单的操作更改到各种系统开发或修改。 应用各种技术来分析候选者,了解它们的可行性和价值,并选择最佳替代品。 确定跨越潜在解决方案空间的候选解决方案,从简单的操作更改到各种系统开发或修改。 应用各种技术来分析候选者,了解它们的可行性和价值,并选择最佳替代品。
过程方法
进程的活动
在 MA 过程中需要执行以下主要活动和任务:
- 查看并了解企业使命、愿景和 ConOps。
- 识别并定义与战略未来发展相关的任何差距和机会:
- 检查当前状态以识别与目标实现相关的任何问题或机会,包括现有系统的任何缺陷。
- 分析实际政治、经济、社会、技术、环境和法律 (PESTAL) 因素的背景,同时研究成本和有效性、安全和安全改进、性能改进或现有系统缺乏、市场机会、监管等敏感因素变化、用户的不满等。外部、内部和 SWOT 分析也应包括在内。 出于技术考虑,适当的 架构框架 表示,例如美国国防部架构框架 (DoDAF) 操作视图 (DoD 2010)、Zachman 框架(第 1 和 2 行) (Zachman 2008) 和开放组架构框架 (TOGAF) 架构开发方法 (ADM) (The Open Group 2010)在执行任务分析和利益相关者需求和要求时,阶段 A 和 B 应包含在概念定义中。
- 定义使命、业务和/或运营问题或机会,及其背景和任何关键参数,而不关注解决方案。
- 检查和评估解空间:
- 确定主要利益相关者(客户、用户、管理部门、法规等)。
- 识别高级操作模式或状态,或潜在用例。
- 确定跨越潜在解决方案空间的候选解决方案,从简单的操作更改到各种系统开发或修改。
- 识别可能满足操作或功能修改需求的现有系统、产品和服务。
- 推断可能需要哪些潜在的预期服务。 SoI 是一种潜在的但尚不存在的产品、服务或企业。 此外,解决方案可以是运营变更或现有产品或服务的变更。
- 执行适当的建模、仿真和分析技术,以了解备选候选解决方案的可行性和价值。 从这些服务和用例中建模或仿真操作场景,并通过与利益相关者和主题专家的审查来丰富它们。
- 定义基本的运营概念或市场战略,和/或业务模式。
- 从之前建模的操作场景和操作模式中,推断和表达操作概念或技术概念的用法。
- 收集和丰富需求、期望、场景和约束。
- 在任何提议的市场战略或业务模式的背景下验证任何潜在 SoI 的使命。
- 评估备选方案集并选择最佳备选方案。
- 对替代品进行贸易研究以区分替代品。
- 提供有关可行性、市场因素和替代方案的反馈,以用于完成企业战略和进一步行动。
- 定义初步部署概念、初步支持概念和初步退役概念。
任务分析工件
此过程可能会创建多个工件,例如:
- 对企业 ConOps 的修订建议;
- 初步操作概念文件或输入;
- 任务分析和定义报告(可能包含修改任务的建议);
- 一组业务需求;
- 初步生命周期概念(初步运行概念、初步部署概念、初步支持概念和初步退役概念;
- 系统分析 工件(例如,用例图、上下文图、序列/活动图、功能流程图);
- 贸易研究结果(替代品分析);
- 市场研究/分析报告;
- 一组业务(或任务)需求(通常包含在业务需求规范中)。
方法和建模技术
MA 使用多种技术,例如:
- 用例分析;
- 运营分析;
- 功能分析;
- 技术文件审查;
- 贸易研究;
- 造型;
- 仿真;
- 原型设计;
- 研讨会、访谈和问卷调查;
- 市场竞争评估;
- 基准测试; 和
- 组织分析技术(例如,优势、劣势、机会、威胁(SWOT 分析)和产品组合)。
实际考虑
任务分析和营销分析遇到的主要缺陷如表 1 所示。
表 1. 任务分析的主要缺陷。 (SEBoK 原创)
缺陷 |
描述 |
处理的系统级别错误 |
在系统工程的一开始就划定 SoI 的边界并定义系统的任务和目的时,一个典型的错误是将感兴趣的系统置于错误的抽象级别。 抽象级别可能太高或太低(分别位于上层系统或子系统中)。 这是说明系统始终包含在更大系统中的原则以及混淆 SoI 的目的和使命的结果。 |
缺少操作模式或场景 |
在业务产品或系统中,经常会遇到对操作模式和场景(SoI 将如何使用、在何种情况下等)的缺乏或不充分的描述。 |
表 2 展示了经过验证的任务分析和营销分析实践。
表 2. 任务分析经过验证的实践。 (SEBoK 原创)
实践 |
描述 |
操作场景模型 |
对任何类型的 SoI(包括业务系统)中的操作场景使用上述部分所述的建模技术。 |
上下文模型 |
将使用的上下文视为一个系统,并强迫自己对上下文的主要方面(功能、行为、物理等)使用建模技术。 |
|