获得的产品与提供的产品

传统系统工程 (TSE) 的重点在于提供满足利益相关者需求的产品和相关服务。 对于获得的产品，需方指定需求和要求，选择供应商进行开发和供应，然后接收所需的产品和服务。 收单方在接受后，通常拥有、运营和维护由开发商提供的产品和支持系统。 提供的产品是由供应商根据开发机会向产品的潜在用户提供产品和服务的机会提供的，其业务目标通常以对利益相关者的增值来衡量。

在提供产品系统和相关服务时，拥有和提供产品和服务的企业通常与其他供应商达成协议，以提供在其整个生命周期中使用的元素、方法和工具。 反过来，供应企业可能会与供应商就建立供应链达成进一步的协议。 处理供应链的复杂性必须考虑到成本、风险和进度，因此会对产品或服务的成熟度产生影响。 （参见第 5 部分系统工程组织战略知识领域 (KA)下的文章 。）

收购的产品

根据 ISO/IEC 15288 (2015) 的协议流程，对产品或服务的特定需求通常会导致收购方和供应商之间达成某种形式的协议。 需方规定了对预期产品或服务特性的需求和要求，并且可能会或可能不会对供应商计划如何组织其对产品或系统的生命周期处理提出具体要求。

协议所涉及的正式程度各不相同，并且受客户是政府实体还是商业实体的强烈影响。 政府合同通常包含严格的规范和其他在商业合同中很少见的独特要求。 除了功能和性能规范之外，政府采购代理通常还会指定设计特征。 设计规范通过明确定义产品物理特性的细节来限制产品系统工程 (PSE)。 政府收购方还可以指定如何设计和开发产品或如何生产产品。 政府规范往往更长，更详细，

在与政府或类似企业签订合同时，PSE 必须找出与合同中特定条款的含义相关的分歧，并与合同合作，以书面形式解决规范中的所有歧义和问题。 不这样做可能会导致法律纠纷和政府声称产品替代，这可能会妨碍产品系统的接受并导致经济处罚。

为政府客户开发产品系统需要PSE在企业内部进行彻底的审查和内部协调，以防止其提交不符合要求的提案，因为要求没有完全理解。

提供的产品

给定机会或感知机会，企业可能决定开发产品或服务并将其提供给更广阔的潜在市场。 产品或服务的属性通常通过调查和/或预测潜在的市场渗透率来确定。 供应商确定适当生命周期模型的结构和操作，以实现预期结果（Pugh 1990）。

供应链和分销渠道

在生命周期的不同阶段向产品或服务的所有者提供产品和服务对于成功至关重要。 正是这种更广泛的利益系统 (WSOI) 是必须妥善处理的外包整体论，以便提供成功的产品或服务。 下面的图 1 提供了供应链结构的描述。

图 1. 供应链结构（Lawson 2010）。 经 Harold “Bud” Lawson 许可转载。 所有其他权利均由版权所有者保留。

在图 1 中，需要注意的是，在与供应商的协议中，外包可能涉及交付完整的系统描述解决方案或其中的一部分。 例如，供应商可以在给定由收购方制定的一组利益相关者要求的情况下，开发和提供符合架构解决方案的系统。 反过来，供应商可以通过外包给其他供应商而成为其交付结果的一部分的获取者。

在生产方面，与供应商的外包协议可以从完全生产责任到仅提供由收购方集成的系统元素的实例。 再一次，这些供应商可以成为从外包给其他供应商的部分交付的收购方。

在使用方面，对于重要的系统，可以与供应商签订外包协议以提供运营服务，例如运营医疗保健信息系统。 与供应商的进一步协议可能涉及各种形式的物流，旨在维持系统产品或服务或以帮助台的形式提供帮助。 同样，同意提供与使用相关的服务的供应商可以成为其他供应商服务的获取者。

对于所有供应链来说，重要的是供应方为利益系统的生命周期贡献某种形式的附加值的概念。 供应链系统资产的妥善管理是企业运营的重要组成部分。 事实上，供应链本身就是一个由收购方和供应方作为系统要素组成的企业利益系统。 肯定有一个由协议关系联系在一起的结构。 此外，供应链的运作会导致紧急行为。 供应链系统成为企业系统组合中重要的基础设施资产，构成了扩展企业的基础。

类似于供应链，产品系统的分销渠道可以是产品供应商和各种分销商之间的复杂关系网络，例如包裹递送公司、仓库、服务站、批发网点、零售机构、操作员培训和认证机构等。 分销渠道的性质可能对产品系统的架构或设计产生重大影响。

PSE 可能需要在产品设计中包含特殊功能，以适应分销渠道元素的需求，例如，重载系紧或起重支架、保护性运输包、零售营销展示、产品手册、安装手册、操作员认证包、培训材料等。 有时可能需要创建产品的特殊版本（或实例），用于培训操作员和用户以证明安全或可靠操作、环境测试和资格认证、产品演示和用户测试、专利申请、负载测试和可扩展性演示，以及用于接口拟合检查和质量平衡认证，仅举一些例子。

产品生命周期和产品采用率

每个产品的生命周期遵循如下所示的典型增量开发阶段 (Wasson 2006, 59-65)。 要设计的特定产品可以在该产品的先前“模型”之前，如下面的产品模型生命周期所示，并且以后可以被该产品的较新模型取代。 值得注意的是，没有一套标准的生命周期阶段。 下面的示例是可以构建阶段的多种方式之一。

图 2. 与产品模型生命周期相关的产品生命周期（Wasson 2006）。 经 John Wiley & Sons, Inc. 许可转载。版权所有者保留所有其他权利。

从行业的角度来看，管理产品的生命周期不仅仅涉及工程方面：

产品生命周期管理 (PLM) 是管理产品从概念到设计和制造再到服务和处置的整个生命周期的过程。 PLM 集成了人员、数据、流程和业务系统，并为公司及其扩展企业提供了产品信息骨干。 （CIM 数据 2012）

有许多 PLM 工具和服务可用于促进复杂产品生命周期的开发和管理，尤其是产品线管理（在此处插入产品线管理部分的链接）。

图 3. 从行业角度看的产品生命周期。 （来源： http : //commons.wikimedia.org/wiki/File:Product%E2%80%99s_lifecycle.jpg#filelinks 于 2012 年 2 月 6 日访问。制造工程实验室的 NIST 计划，由美国联邦政府发布，公共领域)

产品和产品模型生命周期由产品采用率驱动，如下图所示，这是大多数工程产品通常经历的（Rogers 2003）。 随着产品达到市场饱和（即，在下面曲线的下降斜率上），通常会有一个新的、升级版本的产品准备好投放市场。 PSE 在确定交付此新版本的最佳时机以及当时最有价值的特性和功能集方面发挥着关键作用。

图 4. Rogers创新采用曲线。 （来源： http ://en.wikipedia.org/wiki/File: Diffusionofideas.PNG 于 2012 年 2 月 6 日访问，由 Tungsten 发布，公共领域）

集成产品团队和集成产品开发

在整个 KA 中讨论的产品系统要求不同学科在其从概念到产品处置或报废的整个生命周期中的成功参与。 90 年代中期的快速技术创新和市场压力要求开发过程（主要是投入产出系列）缩短其开发时间和开发成本，并提高产品质量以保持竞争力。 对于商业企业而言，90 年代将新产品部署到市场的典型开发时间已经缩短到 6-12 个月，而竞争激烈的前沿信息技术产品甚至需要 3-6 个月。

对这些压力的最初反应是并行工程。 并行工程是“……对产品及其相关过程的集成、并行设计的系统方法，包括制造和支持，以使开发人员从一开始就考虑从概念到处置的产品生命周期的所有要素，包括质量、成本、进度和最终用户要求。”这个定义已经演变成集成产品开发 (IPD)，因为它更能描述这种并发性，以描述整个产品团队的持续集成，包括工程、制造、测试和支持贯穿整个生命周期后来，随着过程的重要性得到认可，术语被修改为集成产品和过程开发或 IPPD (INCOSE 2012)。

INCOSE 系统工程手册 v. 3.2.2 很好地描述了 IPT 和 IPDT 过程； 不同类型的 IPDT； 组织和运行 IPDT 的步骤； IPDT 的好例子，特别是对于已获取的系统； 并很好地讨论了要避免的 IPDT 陷阱。 (INCOSE 2012)

IPD/IPPD 帮助计划、捕获、执行和评估计划，以帮助设计、测试、构建、交付和支持满足不同利益相关者要求的产品。 IPD/IPPD 通过协调人员 (IPT) 和流程以实现产品目标（客户满意度），概述了部署、维护、评估和持续改进流程和工具所需的必要基础设施。 集成产品开发流程 (IPDP) 的实施需要采用集成方法进行项目规划，通常包括以下内容：业务战略、项目管理和控制、项目规划、产品需求和架构开发、产品设计和开发、生产和部署、产品验证和确认，以及操作和维护支持。

在每个开发阶段，都有一个决策门，帮助确定 IPDP 是否可行进入产品开发的下一阶段。 IPD 利用多功能 IPT 来优化单个产品和流程，以满足总体成本和性能目标。 IPT 是一个跨职能的团队，通常包括项目中所有相关利益相关者的代表，他们聚集在一起使用相关的 IPDP 向外部或内部客户交付集成产品。 IPT 的主要功能是确保交付给最终客户的产品的业务、技术和经济完整性以及整体成功。 IPT 执行量身定制的 IPDP 并遵循相关的 SE 流程来交付满足客户需求、克服外部约束、

就商业企业而言，产品开发与业务战略（短期和长期）、以投资回报 (ROI)、市场占有率/覆盖率和业务目标定义的其他战略衡量的利益相关者增值密切相关. 因此，产品集成团队包括战略规划人员、业务经理、财务经理、市场经理、质量保证经理、客户代表和最终用户，以及收购产品所需的其他学科。 Phillips (2001)、Annachino (2003) 和 Morse (2007) 对这个主题进行了很好的讨论。

架构、要求和标准的作用

产品系统的架构属性受 ISO/IEC 42010 标准 (ISO/IEC 2011) 中指出的各个利益相关者的关注点的影响。 利益相关者根据他们的具体观点表达了不同的观点。 这些视图对于建立需求至关重要，并且是负责定义实现所需产品或服务所需的功能、结构和关系的人员的输入。

在产品系统的讨论中已经确定了许多利益相关者。 可以根据 ISO/IEC 15288 标准（2015）提供的生命周期思维来识别一组重要的利益相关者，例如，这样的一组可能由所有者、构思者、开发者、生产者、用户和维护者组成正如 Lawson (2010) 所讨论的那样。 如前所述，这些利益相关者应在生命周期的所有阶段进行合作，以指定需求、验证需求是否得到满足以及验证所生产的产品是否提供了所需的功能。

除了已确定的两个标准外，还有各种与产品的特殊方面相关的标准，例如安全和安保，以及适用于项目管理和生命周期考虑的标准，例如要求和质量管理。

建模、仿真、原型设计和实验的作用

建模、模拟、原型制作和实验是旨在提高利益相关者知识和对系统各方面的共同理解以在大量时间和资金投入之前降低系统开发和操作风险的技术。 这方面的例子如下：

• 了解未来需求：“作战实验是陆军作战需求确定过程的核心。 在相关的战术竞争场景中使用真实的士兵和单位进行高保真建设性、虚拟和实时模拟的渐进式和迭代式组合为陆军领导者提供了对未来作战能力的洞察”（美国陆军，2012 年），
• 仿真用于在提交最终物理设计之前预测和优化具有良好数学或逻辑模型的系统性能方面，以及在物理测试过于困难、危险或昂贵的情况下验证和验证系统设计，例如，在广泛的交战场景中检查军事系统的性能包络，其中测试发射数千发子弹以获得统计上有效的数据显然是负担不起的，确保核电站的安全功能能够在广泛的范围内正确运行强调情景等，
• 原型（物理和虚拟）以多种方式用于检查系统性能、可用​​性、实用性的各个方面，并验证模型和模拟，作为收敛到最终设计的迭代过程的一部分，
• 在制造环境中，生产的第一批产品通常是“原型”，旨在确保生产过程在进行高速生产之前正常工作，并且通常不运送给最终用户，而是用于密集测试以验证设计，和
• 模拟还广泛用于培训和营销目的。 对于培训，人机界面的准确模型和操作环境的表示允许操作员完成大部分培训，而无需将操作时间放在真实系统上，使他们能够在安全和可重复的环境中学习战斗和事故场景的应急程序; 例如，航空公司和军事飞行员现在主要在模拟器上进行训练。 各种保真度级别的系统模拟器用于让客户和最终用户熟悉系统的潜在特性和优势、可用的选项和权衡，以及开发和采购过程早期的集成问题。

所有这些方法都使用系统及其环境的各种物理和数学表示，因此建模是模拟、原型设计和实验的推动力。

软件在产品功能中的作用越来越大

商业产品的一个重要趋势是软件在越来越广泛的产品中越来越重要。 从手机、相机、汽车、测试设备到医疗设备，所有东西现在都在软件中实现了基本功能。 软件在为许多产品提供所需功能方面发挥着越来越重要的作用。 在许多类型的产品中嵌入软件占产品功能的增加部分。 在汽车等有形产品中，软件有助于提高功能和可用性（巡航控制、气候控制等）。 在保险等无形产品中，软件有助于提高运营效率、数据可访问性等。

向融合了传感和激活功能的“物”互联网发展的趋势现在开始渗透。 服务系统工程 文章 中还描述了在服务证明中使用各种软件产品。

IT 和软件的最新进展有助于它们在 PSE 中的使用增加。 尽管软件开发已经是一个非常复杂的领域，但软件在产品开发和功能中的作用与日俱增。

有必要拓宽软件工程师的视野，不仅要从软件方面考虑问题解决，还要使用系统思维方法。 为此，软件工程师需要能够批判性地思考问题以及问题或机会的可能解决方案及其对业务目标的影响。

产品集成与接口控制

集成是“将系统的较小单元组合成较大单元的一组活动”（Eisner 2008）。 产品可能由多个系统、子系统、组件、零件等组成，它们必须作为一个整体协同工作，以在预期的操作环境中以指定的性能水平提供所提供产品的功能。 产品集成不仅需要硬件和软件组件的协同工作，还需要组织、流程、人员、设施以及制造、分销、维护、客户支持、销售渠道等资源。Grady (2010) 将将上述信息分为三个基本集成组件：功能组织、产品集成和流程集成。

PSE 在确保产品组件之间定义良好的接口、交互、关系、信息交换和流程要求方面发挥着重要作用。 这些要求是端到端产品集成的基线、记录、跟踪、验证和验证，并在其生命周期内维护和确保产品提供的完整性。 系统工程层次分解层次允许在不同抽象层次上进行需求定义和分配，以定义产品架构的构建块； 这些构建块被分配给集成产品开发团队 (IPDT) 进行详细设计和开发。 IPDT 或系统工程集成团队 (SEIT) 必须与所有相关参与者互动，以便在较低开发层生成适当的架构块规范，用于产品的架构配置和配置跟踪。 当构建块组合在一起时，接口需求、信息交换以及实体之间的交互和关系将根据基线进行验证。 一旦一个配置项根据基线构建和测试，在更高级别进行测试和验证以获得最终的产品配置； 最终产品配置只能通过配置控制委员会 (CCB) 的正式批准进行更改。 注意：缩写 CCB 通常用于表示变更控制委员会，除了配置控制之外，

接口协议、规范和接口设计通常通过接口控制文档（ICD）和接口设计描述（IDD）记录； 在某些情况下，根据产品的复杂性以及内部和/或外部接口的类型，会创建一个接口控制工作组 (ICWG) 来分析接口的更改并确定其基线，以便进一步向 CCB 推荐。

配置项 (CI) 可以是硬件 (HWCI)、软件 (SWCI)、固件、子系统、组件、非开发项、商业现货 (COTS) 项、需方提供的设备和/或流程。 请参阅 Wasson (2006)、Grady (2006) 和 INCOSE SE 手册 v. 3.2.2，了解配置和界面控制的更详细说明。

由于新产品的发布/增强、零件的维修/更换、操作系统的升级/更新、计算机基础设施、软件模块、组织变化、流程和/或方法和程序的变化，产品在其生命周期中可能会经历数百次变化因此，需要建立强大的簿记和活动控制机制来识别、控制、审计、帐户和跟踪接口、交互以及维护产品配置状态所需的实体之间的关系（Eisner 2008）。 然后通过配置管理过程控制产品配置和 CI。

配置管理和风险管理

配置管理 (CM) 处理产品的识别、控制、审计、状态核算和可追溯性方面，并广泛涵盖系统工程过程的簿记和控制活动 (Eisner 2001)。 对基线（配置项、操作基线、功能基线、行为基线）或产品基线的任何产品配置更改都通过工程更改请求 (ECR) 和/或配置更改请求 (CCR) 提交给配置控制委员会 (CCB) ）。 然后，CCB 分析请求以了解 CI 影响以及授权或拒绝变更请求的可行性（时间和成本）。 缺乏对 CI 和产品基线的适当控制和跟踪可能会导致特性、功能、数据、接口等丢失， 导致回溯和 CI 版本丢失，这可能会影响所提供的产品。 所有批准的更改都必须进行基线化、记录和测试，以确保向后兼容性并确保符合集成产品功能。 因此，产品的成功实施和生命周期管理要求高度规范的 CM 流程保持对产品及其组件的适当控制。 请参阅 INCOSE Systems Engineering Handbook v. 3.2.2 (2012) 详细描述了 CM 过程。

风险管理处理任何系统中技术、成本、进度和程序风险的识别、评估和优先级排序。 几乎所有工程系统都是在一定程度的风险和不确定性下设计、建造和运行的，同时要实现多个而且往往是相互冲突的目标。 随着现代系统中引入更大的复杂性和新技术，潜在的风险显着增加。 因此，整个管理决策过程应该包括对所有已识别、合格和评估的风险进行广泛的成本效益分析（Haimes 2008）。 风险管理涉及协调和最具成本效益的资源应用，以最小化、监控和控制系统工程过程中所有已识别风险的概率和/或影响。 风险管理过程需要多个学科的参与，包括决策的经验、定量和规范判断方面。 此外，风险评估和管理应该整合并纳入更广泛的整体方法中，以便技术管理可以帮助将风险管理要求与整体系统工程要求保持一致。 因此，在系统工程总体规划中包含一个定义明确的风险管理计划来处理风险分析，这对于任何系统的长期和持续成功都是至关重要的（Blanchard 和 Fabrycky 2011）。 风险评估和管理应整合并纳入更广泛的整体方法中，以便技术管理有助于使风险管理要求与整体系统工程要求保持一致。 因此，在系统工程总体规划中包含一个定义明确的风险管理计划来处理风险分析，这对于任何系统的长期和持续成功都是至关重要的（Blanchard 和 Fabrycky 2011）。 风险评估和管理应整合并纳入更广泛的整体方法中，以便技术管理有助于使风险管理要求与整体系统工程要求保持一致。 因此，在系统工程总体规划中包含一个定义明确的风险管理计划来处理风险分析，这对于任何系统的长期和持续成功都是至关重要的（Blanchard 和 Fabrycky 2011）。