|
系统工程评估和控制(SEAC)的目的是提供关于技术计划(即系统工程管理计划(SEMP)或系统工程计划(SEP)和下属计划)的项目实际技术进度和风险的充分可见性。可见性允许项目团队在发现破坏性趋势时及时采取预防措施，或者在绩效偏离既定阈值或期望值时采取纠正措施。SEAC包括准备和进行审查和审计，以监测业绩。评审和测量分析的结果用于识别和记录发现/差异，并可能导致因果分析和纠正/预防措施计划。执行、跟踪和监控行动计划直至完成。(NASA 2007，第6.7节;SEG-ITS, 2009，章节3.9.3,3.9.10;INCOSE, 2010，第6.2条;SEI, 2007)
系统工程评估与控制过程概述
SEAC 过程涉及确定和启动适当的处理策略和行动，以处理在与项目相关的企业、基础设施或生命周期活动中发现的发现和/或差异。 分析发现/差异的原因有助于确定适当的处理策略。 实施经批准的预防、纠正或改进措施可确保在计划的技术、进度和成本目标范围内圆满完成项目。 在整套行动和优先事项的背景下审查针对发现和/或差异的潜在行动计划，以优化项目和/或组织的利益。 相互关联的项目被一起分析以获得一致且具有成本效益的解决方案。 SEAC 流程包括以下步骤：
- 根据计划监控和审查技术性能和资源使用情况
- 监控技术风险，将重大风险升级到项目风险登记册，并寻求项目资金以执行风险缓解计划
- 在项目审查中进行技术审查并报告结果
- 分析问题并确定适当的行动
- 管理行动以结束
- 进行交付后评估（也称为项目后审查）以获取与项目相关的知识（这可能是单独的技术评估，也可能作为项目评估和控制过程的一部分进行）。
以下活动通常作为项目评估和控制过程的一部分进行：
- 授权、放行和结束工作
- 根据计划监控项目绩效和资源使用情况
- 监控项目风险并授权项目资金支出以执行风险缓解计划
- 举行项目评审
- 分析问题并确定适当的行动
- 管理行动以结束
- 进行交付后评估（也称为项目后审查）以获取与项目相关的知识
SEAC 中使用的主要技术审查示例如 DAU (2010) 的表 1 所示。
表 1. 主要技术审查示例（DAU 2012）。 由国防采办大学 (DAU)/美国国防部 (DoD) 发布。
| 名称 | 描述 |
| 替代系统审查 |
多学科审查，以确保最终的需求集符合客户的需求和期望。 |
| 关键设计审查 (CDR) |
建立初始产品基线的多学科审查，以确保被审查的系统在当前分配的预算和时间表内具有满足能力开发文档要求的合理预期。 |
| 功能配置审计 |
对配置项（硬件和软件）的测试特性进行形式检查， 目的是验证实际性能是否符合功能基线中的设计和接口要求。 |
| 在职审查 |
进行多学科的产品和过程评估，以确保所审查的系统在操作上得到充分理解和管理的风险。 |
| 初步技术审查 |
支持项目初始项目目标备忘录提交的多学科审查。 |
| 综合基线审查 |
政府项目经理和承包商为建立绩效衡量基准而进行的联合评估。 |
| 操作测试准备审查 |
多学科的产品和流程评估，以确保系统能够以高成功率进行初始操作测试和评估，并确保系统有效并适合服务引入。 |
| 生产准备审查 (PRR) |
检查程序以确定设计是否已准备好投入生产，以及主承包商和主要分包商是否已完成充分的生产计划，而不会产生不可接受的风险，这些风险将违反进度、性能、成本或其他既定标准的阈值。 |
| 物理配置审计 |
在全速生产决策前后对正在生产的项目 的实际配置进行检查。 |
| 初步设计评审 (PDR) |
建立物理分配基线的技术评估，以确保被审查的系统有合理的期望被判断为操作有效和合适。 |
| 系统功能审查 (SFR) |
多学科审查，以确保建立系统的功能基线，并合理预期在当前分配的预算和时间表内满足初始能力文件或能力开发文件草案的要求。 |
| 系统需求审查 (SRR) |
多学科审查，以确保被审查的系统可以进入初始系统开发，并且从初始能力文档或能力开发文档草案得出的所有系统要求和性能要求都已定义和可测试，并且与成本一致，进度、风险、技术准备和其他系统限制。 |
| 系统验证审查 (SVR) |
多学科的产品和过程评估，以确保所审查的系统可以在成本（计划预算）、进度（计划进度）、风险和其他系统限制范围内进行低速初始生产和全速生产。 |
| 技术准备评估 |
一个系统的、基于指标的过程，用于评估关键技术要素的成熟度，例如维持驱动因素。 |
| 测试准备审查 (TRR) |
多学科审查，旨在确保被审查的子系统或系统已准备好进行正式测试。 |
与其他系统工程管理主题的联系
SE 评估和控制过程与 测量、计划 、决策管理和 风险管理过程密切相关。 测量 过程提供了用于将实际值与计划进行比较的指标 。规划 提供了构成监控计划的估计和里程碑，以及使用测量来监控进度的项目计划。 决策管理 使用项目监控的结果作为制定控制决策的决策标准。
实际考虑
与 SEAC 相关的主要缺陷和良好实践将在接下来的两节中描述。
陷阱
在规划和执行 SE 评估和控制过程中遇到的一些关键缺陷如表 2 所示。
表 2. 评估和控制的主要缺陷。 （SEBoK 原创）
| 名称 | 描述 |
| 无测量 |
由于评估和控制活动高度依赖于有洞察力的测量信息，因此独立于测量工作进行通常是无效的——你得到的就是你测量的。 |
| “及时”文化 |
有些事情比其他事情更容易衡量 - 例如，交付成本和进度。 不要专注于这些，而忽略更难衡量的事情，比如系统的质量。 避免“及时”的文化，即满足时间表优先于其他一切，但交付的内容不符合目的，导致需要返工项目。 |
| 没有牙齿 |
确保技术审查门有“牙齿”。 有时项目经理被授予权力（或可以向有权力的人提出上诉）以推翻闸门决定并允许工作继续进行，即使闸门已暴露出系统或相关工作产品的技术质量存在重大问题。 如果组织是强烈的日程驱动的，这是一个主要风险； 它没有时间把它做好，但不知何故它找到了时间再做一次（返工）。 |
| 过早的基线 |
不要过早地确定需求或设计的基线。 为了开始子系统或组件的开发，在完全理解或同意之前，通常会对基线系统要求和设计施加很大的压力。 这只是保证了高水平的返工。 |
良好实践
表 3 显示了从参考文献中收集的一些良好实践。
表 3. 经验证的评估和控制实践。 （SEBoK 原创）
| 姓名 | 描述 |
| 独立 |
根据经验和趋势分析，就资源、进度、技术状态和风险提供独立的（来自客户的）评估和建议。 |
| 同行评审 |
在提交审查之前，使用同行评审来确保产品工作的质量。 |
| 接受不确定性 |
沟通需求或设计中的不确定性，并接受不确定性是开发系统的正常部分。 |
| 风险缓解计划 |
如果项目承认需求存在不确定性，请不要在项目审查时惩罚他们——要求他们制定风险缓解计划来管理不确定性。 |
| 准时基线 |
仅在您需要时为需求和设计制定基线——当基于需求或设计的稳定性提交其他工作时。 如果必须开始工作并且要求或设计仍然不确定，请考虑如何在系统中构建稳健性以以最少的返工处理不确定性。 |
| 沟通 |
记录并向利益相关者传达现状调查结果和建议。 |
| 完全可见性 |
确保所有项目参与者都可以看到操作项和操作项状态以及其他关键状态项。 |
| 利用以前的根本原因分析 |
在执行根本原因分析时，请考虑先前相关发现/差异中记录的根本原因和解决数据。 |
| 并发管理 |
与测量和 风险管理活动同时计划和执行评估和控制 。 |
| 经验教训和事后分析 |
进行交付后评估或项目后审查以获取与项目相关的知识——例如，增加和改进估计模型、经验教训数据库、门审查清单等。 |
其他良好实践可以在 INCOSE（2010，第 6.2 条）、SEG-ITS（2009，第 3.9.3 和 3.9.10 节）、INCOSE（2010，第 5.2.1.5 节）和 NASA（2007，第 6.7 节）中找到。 |
