下载掌阅APP，畅读海量书库
立即打开
逻辑分解流程的作用是生成详细的功能需求，从而使NASA的工程和项目能够实现满足利益相关者期望的目标。逻辑分解流程用于确定系统在每个层级上应当完成“什么”才能使得项目成功。逻辑分解流程利用功能分析方法来构造系统的架构，对系统顶层（较高层级）的需求进行分解，并把它们向较低层级进行分配，直到项目所需要的最低层级。
逻辑分解流程用于如下方面：
●对所定义的技术需求（如功能需求、性能需求、行为需求和时间需求）及需求之间的关联关系增强理解。
●为了得到设计方案开发流程的输入，将较高层级需求分解为一组逻辑分解模型，以及与分解的模型相对应的一组派生技术需求。
图4.3-1所示是逻辑分解流程的典型流程框图，图中给出了在逻辑分解流程中需要考虑的典型输入、输出和活动。
图4.3-1 逻辑分解流程的典型流程框图
逻辑分解流程中需要的典型输入包括如下内容。
● 技术需求集 ：一组经确认的需求，表示对于待解决问题的描述。这些需求通过功能分析和性能分析已经建立，并得到了客户和其他利益相关者的批准。获取的需求应写入相应文档，如系统需求文档（SRD）、产品需求文档（PRD）和接口需求文档（IRD）。
● 技术指标集 ：基于期望和需求建立起来的度量指标集。该指标集将被跟踪和评估，以决定整个系统或产品的有效性及客户的满意度。其中的指标包括效能指标（MOE）和性能指标（MOP），以及上述指标的一个特别子集——技术性能指标。更详细的信息参见6.7.2.6.2节。
1.确定一个或多个逻辑分解模型
逻辑分解流程的第一步是建立系统架构模型，这一步非常关键。系统架构用于定义系统中的硬件、软件、在系统回路中的人员、保障人员、系统通信、运行使用等要素形成的基础结构及要素间的关联关系。这些要素由NASA机构、使命任务主管部门、工程/项目开发团队实现完成，或分配到更低层级开展工作。系统架构的建立过程推动系统要素和需求进一步分解为更低层级的功能和需求，直到能够完成系统设计工作并满足系统需求。分解后的子系统之间和单元之间的接口及关联关系也同时被确定。
一旦确立了顶层（上一层级）的功能需求和约束条件，系统设计人员就可以应用功能分析方法开始规划和论证系统的概念架构。系统架构可以被视为由系统功能单元构成的战略性组织，这种结构组织使得单元之间的地位、关系、依赖性和接口能够被清晰地定义和理解。系统架构在战略层面注重系统的整体结构，注重各单元之间如何协同配合对系统整体做出贡献，不是关注各个单元自身的独立工作。采用系统架构使得系统的各个单元可以相互独立开发，同时又能确保它们组合在一起共同工作时可以有效地实现顶层（上一层级）的需求。
与功能分解过程中的其他要素相同，在系统的顶层开发一个良好的层次架构很重要。这个开发过程是创造性的、递归的、协同的和迭代的，能达到对项目最终目标和约束条件的最佳理解，同样也能达到对实现目标产品交付的潜在技术途径的良好认知。
鉴于对项目顶层的（或上一层级的）最终需求及约束条件的关注，系统架构设计师应当至少开发一个能够达成工程目标的系统概念架构，当然能开发出多个更好。每个架构的构想都涉及功能单元的技术规范（说明单元做什么）、它们之间的相互关系（接口定义）和运行使用构想。运行使用构想涉及从开始运行使用到使命任务结束，分布在不同地点和处于不同环境下的各个部段、子系统、单元、人员、样机等如何形成系统整体运行效果。
架构构想的开发过程应当是递归和迭代的，要从利益相关者和外部评审者那里得到意见反馈，同样也要从子系统设计人员和使用人员那里得到反馈。这些反馈意见应当尽可能多，以提高有效完成工程最终目标的可能性，同时降低成本和进度超出的可能性。
在架构构想开发的早期，可能有多个构想被开发出来。但成本和进度上的约束条件将限制工程或项目长时间同时维持多个架构构想的开发。所有NASA工程的架构设计须在规划和论证阶段完成。对于多数NASA项目（及紧耦合的工程）来说，将会在阶段A为其中一个架构单独设定控制基线。架构偶尔会在高层发生变更，这是因为向低层的分解在设计方案、成本或进度方面产生的复杂性引起变更的必要。当然，正如图2.5-3所示，开发过程中变更发生的越晚，则开销越昂贵。
除架构设计师的创造性思想外，还有许多软件工具可运用于系统架构的开发。这些主要是建模和仿真工具、功能分析工具、架构框架搭建工具和权衡研究工具。例如，可以采用美国国防部的体系架构框架（DODAF）方法构建系统架构。随着每个架构构想的开发，架构分析模型、模型组件和组件运用也会在项目的推进过程中更加逼真地开发出来。功能分解、需求开发和权衡研究的工作也随后展开。随着需求向下层的分解和设计方案的成熟，这些活动将多次迭代并反馈到不断演化的架构构想中。
DOD架构框架（DODAF）
在过去十年中，架构框架技术的进步使之成为用于对演化的复杂体系进行描述和特征化的新方法。在此氛围下，架构描述非常有用，可用于确保利益相关者的需求被清晰理解和排序、确保优先考虑关键细节（如互操作性），以及确保主要投资决策基于战略性考虑。认识到这一点，美国国防部确立了在投资规划、采办和联合能力集成方面指定使用DODAF的政策。
架构可以理解为“组件的结构及其相互关联关系，以及全程控制其设计与演化的原则和指南。”（基于美国电气和电子工程师协会（IEEE）的STD 610.12标准定义。）为了描述架构，DODAF定义了若干视图： 作战运用视图、系统视图和技术标准视图 。此外，还包括字典和综合摘要信息（见下图）。
在每一个视图中，DODAF包含特定的产品。例如，在作战运用视图中，包含作战运用节点的描述、它们的关联性，以及信息交换需求。在系统视图中，包含所有作战运用节点和相互关联构成的系统描述。并非所有DODAF产品都与NASA系统工程相关，但它的基础概念和形式体系可以用于技术需求定义及决策分析流程的复杂问题结构描述。
2.分配技术需求，解决冲突并设定控制基线
功能分析是用于系统架构开发和功能需求分解的主要方法。它是确定和描述系统必须执行的功能，并找出这些功能之间的关联关系，以满足系统目标的系统化过程。功能分析方法明确系统的功能、需要开展的权衡研究、系统接口特征和需求的客观依据，并将它们关联起来。这些通常都基于所研究系统的运行使用构想。
进行功能分析有如下三个关键步骤：
（1）将系统顶层需求转化为实现这些需求可能需要展现出的功能。
（2）将功能分解和分配到产品分解结构的更低层级。
（3）确定和描述功能接口和子系统接口。
这个流程包括分析每个系统需求，确定为满足需求而需要实现的所有功能。每一项被确定的功能用输入、输出、故障模式、故障的后果和接口需求进行描述。这个流程自顶向下不断重复，因而子系统功能可以被看作更大功能组合的一部分。通过刻画功能的逻辑顺序，系统任何特定的运行使用都能通过这种端到端的逻辑顺序路径进行追溯。
这个流程是迭代和递归的，且一直持续到完成对架构和系统中所有必要层次需求的分析、定义，并设定控制基线。几乎可以肯定，功能分解有多种可替换的方式。例如，与航天器上宇航员的通信可以有多种途径：无线电通信、激光通信和互联网等。因此，需求分解结果高度地依赖于工程师开展分析工作时的创造性、熟练程度和经验积累。随着进入架构和系统较低层级的分析，以及随着系统已经被较好地理解，系统工程师应当保持开放的思想和信念，回顾和修改之前已建立的架构和系统需求。这些变更又需要再次通过系统架构和功能逻辑分解下去，递归过程一直持续到系统被完整地定义，所有需求都被理解且在可行性、可验证性和内在一致性方面达成共识。只有做到这样，系统架构和需求的控制基线方能确定。
3.获取工作产品
在开展逻辑分解流程中的各项活动时所产生的其他工作产品也应当能够获得，其中包括所做出的关键决策、支持决策的客观依据、前提假设及总结的经验教训。
逻辑分解流程中的典型输出包括如下内容。
● 逻辑分解模型 ：这些模型定义系统需求与功能的关系及需求与系统行为的关系。其中，系统架构模型定义系统各组件（如硬件、软件、系统回路中的人员、服务保障人员、通信组件、运行操作单元等）的基础结构和相互之间的关系，以及定义将需求分解到足够低层级的基础，以保证设计工作能够完成。
● 派生的系统技术需求 ：该需求在本流程输入的已设定控制基线的需求中并未明确陈述，出现在流程实施过程中对所选定的系统架构做出定义时。设定控制基线的需求和派生的需求都应当在系统架构和功能层级中进行分配。
● 逻辑分解的工作产品 ：指在本流程活动中产生的其他产品。
以产品分解结构和工作分解结构为代表进行系统分解的方式，已经成为关于所需产品系统的重要观点。工作分解结构是对完成项目需要开展的工作做层次化分解。关于工作分解结构开发的进一步信息可参见6.1.2.1节。工作分解结构中包含了产品分解结构，产品分解结构是关于诸如硬件、软件、信息产品（文档、数据库等）进行的层次化分解。产品分解结构在逻辑分解流程和功能分析流程中运用。产品分解结构需要展开到的最低层级应有明确的且能够辨识出的工程师和管理者。图6.1-4给出了产品分解结构的一个示例。
有很多技术可用于进行系统功能分析，下面列出一些常用的方法：
（1）功能流框图法：用来描述任务的顺序和任务关系。
（2）N 2 图法（或N×N交互矩阵法）：用来从系统的观点确认主要因素之间的交互关系或接口。
（3）时间线分析法：用来按时间顺序描述那些对时间敏感的功能。