求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
要资料
 
追随技术信仰

随时听讲座
每天看新闻
 
 
目录
第一部分:SEBoK介绍
SEBoK 简介
系统工程导论
SEBoK 用户和用途
第二部分:系统工程基础
系统基础
系统方法在工程系统中的应用
系统科学
系统思维
用模型表示系统
第三部分:系统工程与管理
系统工程 STEM 概述
基于模型的系统工程 (MBSE)
生命周期过程简介
生命周期模型
概念定义
系统定义
系统实现
系统实施
系统集成
系统验证-1
系统验证-2
系统部署和使用
系统部署
系统操作
系统维护
Logistics
系统工程管理
技术规划
评估和控制
决策管理
风险管理
配置管理
信息管理
质量管理
度量管理
业务和任务分析
业务和任务分析
系统工程标准
相关标准
系统工程标准的应用
系统工程标准的校准与比较
服务的生命周期管理
第四部分:系统工程的应用
产品系统工程
服务系统工程
企业系统工程
Systems_of_Systems(SOS)
医疗系统工程
第五部分:启用系统工程
支持业务和企业执行系统工程
支持团队执行系统工程
支持个人执行系统工程
第六部分:系统工程相关领域
系统工程和环境工程
系统工程和工业工程
系统工程与地理空间/大地测量工程
系统工程和项目管理
系统工程和软件工程
系统工程与质量属性
第七部分:系统工程实施实例
系统工程实施示例:信息系统
系统工程实施示例:防御系统
系统工程实施示例:交通系统
系统工程实施示例:医疗系统
系统工程实施示例:空间系统
系统工程实施示例:管理系统
系统工程实施 : 矩阵示例
第八部分:新兴的知识
新兴的主题
 
 
目录
产品系统工程
译者:火龙果Alice
2250 次浏览
7次  

产品系统工程(PSE)是新产品开发过程(NPDP)的核心,它需要成功地开发和部署产品到不同的细分市场。市场可以是基于消费者的(例如,私营企业或普通消费者),也可以是公共的(非营利性)。公共市场解决一个国家或地区的战略需求,如军事、医疗、教育、交通和能源需求。NPDP有两个明显重叠和综合的活动:

  1. 系统工程: 这包括概念生成、工程设计/开发和部署
  2. 市场开发: 这包括市场研究、市场分析、产品接受度和市场增长(扩散)以及采用率

NPDP还包括可制造性/可生产性,物流和配送,产品质量,产品处置,符合标准,利益相关者的增值,以及满足客户的期望。还必须考虑到企业内部的能力,如客户支持、销售和市场营销、维护和维修、人员培训等。

主题

SEBoK 的每个部分都分为知识领域 (KA),这些知识领域是具有相关主题的信息分组。 KA 依次被划分为主题。 本 KA 包含以下主题:

产品系统工程背景文章讨论了产品类型,以及产品与企业的业务目标相一致的需求。并讨论了PSE、产品开发和技术开发之间的关系。

产品元素之间的各种类型的连接,以及启用系统(enabling-systems)的概念在产品作为系统基础的文章中被介绍。它还讨论了产品架构、建模、分析以及与各种专业工程领域的集成。

产品启动和产品提供与不同的业务流程有着密切的联系。主要的联系包括商业发展、市场推广、产品线、质量管理、项目管理、运作管理、供应链管理等。这些和其他主题在与产品系统工程相关的业务活动一文中进行了描述。

当产品基于系统定义实现时,它们就出现了。实现系统的结果是,系统的实例要么作为产品交付给特定的收购方(基于协议),要么直接提供给买家和用户。PSE的关键方面在“产品系统工程关键方面”一文中进行了讨论,该文章讨论了诸如获得产品与提供产品、产品生命周期和采用率、集成产品团队(IPTs)和集成产品开发团队(IPDTs)、产品架构、需求和标准等方面。

最后“产品系统工程专题活动”,介绍了PSE在从概念到产品部署的不同阶段所进行的一些专题活动。

关键术语和概念

产品

产品是由某些人或某些过程(如制造过程、软件源代码编译和集成、层次构造、创造性写作过程或数据处理)创建的工件。

一般来说,商业产品被定义为劳动所产生的东西,或行为或过程的结果。它源自动词produce,源自拉丁语prōdūce(re) (to)领导或带来。从1575年开始,product这个词指的是生产出来的任何东西,从1695年开始,product这个词指的是一个或多个被生产出来的东西。

在经济和商业中,产品属于更广泛的商品范畴。“产品”一词的经济含义最早是由政治经济学家Adam Smith.使用的。在市场营销中,产品是任何可以提供给市场以满足需求的东西。在零售行业,产品被称为商品。在制造业中,产品作为原材料购买,作为制成品出售。商品通常是原材料,如金属和农产品,但商品也可以是任何在公开市场上广泛获得的东西。在项目管理中,产品是构成或有助于交付项目目标的项目可交付成果的正式定义。在保险业中,保单被认为是由制定合同的保险公司提供出售的产品。

产品系统

产品系统是终端产品和这些终端产品的支持产品的组合。产品系统的这一概念如图 1 所示。在ANSI/EIA 632-2003标准中,仅使用了术语系统,但该标准的范围显然仅限于产品系统。

图1所示。产品系统组件(ANSI/EIA 632)。节选自“系统工程流程”(EIA-632),版权所有©(1999)TechAmerica。保留所有权利。本文经许可转载。版权所有人保留所有其他权利。

终端产品也可以被视为具有自己的元素或子系统的系统,每个元素或子系统都有自己的支持产品,如图 2 所示。产品开发过程通常只关注终端产品的工程设计。 当支持产品本身很复杂或它们与终端产品的关系很复杂时,PSE 是必不可少的。 否则,使用传统的产品开发流程就足够了。

图 2. 终端产品和支持产品 (ANSI/EIA 632)。 摘自“系统工程流程”(EIA-632),版权所有 © (1999) TechAmerica。 版权所有。 经许可转载。 所有其他权利均由版权所有者保留。

产品实现系统 (Product Realization System)

产品实现系统是能够 实现 产品系统的相关系统。 它包括 所有用于使干预系统[即产品系统,在这种情况下]得到充分构思、开发、生产、测试​​和部署的资源 (Martin 2004)。 Lawson(2010)将此称为系统耦合图 中的响应系统。 干预系统是为了解决如图 3 所示的上下文中的一些感知问题而被实现(或构想和实现)的系统。

图 3. 创建干预以解决问题的实现系统(Martin 2004)。 经航天许可转载。 所有其他权利均由版权所有者保留。

实现系统可以是服务系统(如知识领域服务系统工程中所述)或企业系统(如知识领域中企业系统工程中所述)。 当实现系统是服务系统时,服务可以通过设计产品系统而不开发或创建它来部分地实现系统。 该设计服务系统可以将设计传递给制造服务系统,将设计转变为物理制品。 通常建立一个企业是为了将不同的服务编排成一个有凝聚力的整体,该整体可以有效地执行以实现该企业的战略目标。

产品实现系统利用(Magrab 等 2010)中描述的产品实现过程或(Wheelwright 和 Clark 1992)中描述的产品开发过程。

产品维护系统(Product Sustainment System)

当实现系统将产品系统交付到其预期的环境中时,产品通常需要一组服务来保持该产品的可操作性。 在需要时,这个其他系统称为产品维护系统。 它由各种使能产品和运营服务组成。 与实现系统和部署的产品系统相关的维护系统如图 4 所示。请注意,实现可能需要为正在开发的特定干预(产品)系统开发或修改维护。

图 4. 支持已部署产品系统的产品维护系统(Martin 2004)。 经航天许可转载。 所有其他权利均由版权所有者保留。

产品系统工程、服务系统工程和企业系统工程

PSE 与大多数关于该主题的教科书(例如 Wasson(2006)、Sage 和 Rouse(2009)以及 Blanchard 和 Fabrycky(2011))中的传统系统工程 (TSE) 一致。 但是,它们并没有涵盖 PSE 的全部范围,因为它们往往只关注硬件和软件产品。 其他需要设计的产品包括人员、设施、数据、材料、流程、技术、程序和媒体(Martin 1997;Lawson 2010)。 产品系统工程背景中提供了有关各种产品之间区别的进一步讨论 文章。 产品系统领域可以是数据密集型(例如运输系统)、设施密集型(例如化学加工厂)、硬件密集型(例如防御系统)或技术密集型(例如搜索和救援系统)。 大多数产品系统是几种不同类型产品的组合,这些产品必须完全集成才能为不同的利益相关者实现完整的增值潜力。

服务系统工程 (SSE) 和企业系统工程 (ESE) 相比,PSE 有一些独特的考虑:

  • 通常,产品是产品线的一部分,其中产品线和构成该产品线的产品必须同时进行设计。
  • 产品通常由多个供应商生产的零件和子组件组成。 这需要与供应链密切合作,以确保提供成功的产品。
  • 大型复杂产品通常需要一系列冗长而复杂的组装、集成和测试步骤。 在集成过程中,在初始产品设计期间做出的许多关键假设可能会受到挑战。
  • 产品通常需要对其安全性或节能和环境兼容性等其他因素进行认证。 电子产品通常需要认证,以确保电磁兼容性和有限的电子发射进入无线电频谱。 运输产品需要安全操作认证。
  • 产品通常具有复杂的分销网络,因为它们并不总是在终端用户可能需要的地方开发。 作为该分销网络的一部分,可能有仓库、仓库、多式联运、批发商、经销商和零售店。 这给产品的交付、维护和支持带来了挑战。
  • 产品必须与实现系统和维护系统一起设计。 有时需要在产品系统、实现系统和维护系统的特性和功能之间进行权衡。

这些考虑因素和其他因素将在该知识领域下的文章中讨论。 ESE 的职责之一是跨企业的多个产品线管理这些不同的考虑因素,同时最大限度地提高利润和客户满意度。 SSE 通常依赖于 PSE 产生的产品。 服务通常基于产品基础架构,包括数据处理、硬件、软件、数据存储、数据输入设备、显示设备、服务交付设施和技术、服务台技术人员、维护人员、服务提供目录和印刷材料等元素. 服务基础设施中的这些产品中的每一个都可能需要使用其自己的 PSE 生命周期进行单独设计。

创造价值

一个创造产品的企业,也必须创造出在客户眼中超过产品成本的价值。 这适用于营利性和非营利性私营和公共企业。 产品的创建和交付可能是收购协议或直接向买家或用户提供的结果。 为了保持竞争力,企业还需要了解全球经济的影响、行业趋势、技术开发需求、新技术突破的影响、细分市场的创建及其期望,最重要的是,不断变化的客户期望。

Ring (1998) 定义了具有三个层次的系统价值循环,系统方法必须考虑这些层次以提供现实世界的利益:

  1. 利益相关者价值
  2. 客户需求
  3. 系统解决方案

只有在时间、成本和其他适合关键利益相关者的资源的背景下考虑价值,才能充分实现价值。

将产品特性与相关的运营活动相结合

产品的用户将产品视为可以在自己利益相关的系统中使用的资产(Lawson 2010)。 因此,在提供产品时,预期的操作形式成为确定产品特性的驱动因素。 在某些情况下,特别是对于军事相关产品,所需的操作活动被称为操作概念(ConOps),在商业企业的情况下,系统的预期用途是通过某种形式的产品 市场服务描述 来描述的。 产品的预期用途是市场/客户驱动的,因此产品特性必须与运营意图保持一致。

架构作为价值评估的基础

企业可以使用体系结构将产品开发从单个产品转移到底层产品线体系结构,该体系结构结合了企业所需的灵活性,以根据特定客户要求快速定制新技术和功能(Phillips 2001)。 在确定产品系统的架构时,可能会出现各种替代设计。 每个架构备选方案都将根据其对终端用户和其他利益相关者的价值贡献进行评估。

评价标准在产品选择中的作用

在评估产品系统价值时,必须考虑用于确定 产品 替代品(替代架构和技术)在可生产性、质量、效率、性能、成本、进度和最重要的是为满足客户的要求或市场机会而提供的覆盖范围。

权衡在价值最大化中的作用

备选方案的评估必须包括相互冲突的属性之间的权衡。 例如,为了追求卓越的质量和效率,必须在进度和成本方面进行权衡。 请参阅第 3 部分中有关测量的文章。权衡是在开发过程的不同阶段进行的:在产品或系统级别、子系统和架构定义级别以及技术级别(Blanchard 和 Fabrycky 2011)。

进行权衡分析的方法有很多种,例如:效用理论、层次分析法、Pugh 选择法、多目标决策、多属性效用分析和多变量分析。 对于软件,软件工程研究所 (SEI) 提供了“架构权衡分析方法 (ATAM)”(Kazman 等人,2000 年),用于评估与质量属性目标相关的软件架构。 ATAM 评估暴露了可能阻碍实现组织业务目标的架构风险。 ATAM 不仅揭示了架构满足特定质量目标的程度,而且还提供了对这些质量目标如何相互作用以及它们如何相互权衡的洞察。

扩大软件在产品价值创造中的作用

软件在为许多产品提供所需功能方面的作用越来越大。 在多种产品(如交通工具、家用电器和生产设备)中嵌入软件,占产品功能的比重越来越大。 当前的趋势是开发包含传感和激活功能的系统网络。 在服务系统工程 知识领域 中描述了在提供服务中使用各种软件产品。

产品系统工程背景

产品类型

根据定义,系统由相互作用的元素组成。 系统本身通常是一个更大系统的一个元素,每个元素通常也可以被视为一个独立的系统。

一个 系统元素由一个或多个产品组成。 需要生产或获取产品。 有些可以按原样获得或采购,无需制造或修改。 其他需要设计,在某些情况下,需要系统设计(Martin 1997)。 基本产品类型如下图所示。

产品类型不限于硬件或软件。 许多其他类型的产品执行满足利益相关者需求所必需的功能。 有些仅与某些行业或领域相关,例如土木工程结构、航运或海军领域的船舶。 系统工程师必须记住不要将系统所需的行为单独分配给硬件和软件元素。

虽然我们可以将产品的概念与具体的对象联系起来,例如计算机芯片、电话、飞机,甚至指挥、控制和通信中心,但组织或流程也可以是产品。 有时产品不够复杂,不足以证明执行产品 SE 的合理性,只需要产品设计工程。 企业 SE 和服务 SE 应确定产品是否需要产品 SE。

产品分类

对于任何正在开发的系统,系统工程师必须决定要包含哪些正确的元素。 这不是不言而喻的,因为基本的产品类型不一定是相互排斥的。 例如,有些人会认为设施包含硬件和人员。 其他人会认为设施与硬件和人员分开。 有些会包括材料作为硬件的一部分,而另一些则不会。 创建产品类型的分类可以帮助系统工程师清楚而彻底地思考要包括哪些组件。

业务目标和产品

在开发和推出新产品时,企业必须使该产品与其业务目标、内部能力和竞争保持一致。 它必须使最终产品与预期实现和维持它的系统保持一致。

新产品概念必须基于分析,即除了产品潜力之外,还探索企业利用该潜力的能力,包括组织文化、重点、目标和流程等因素。 必须分析当前和未来的市场和技术。 竞争的几个维度也是如此:竞争对手的产品和他们的计划,进入新市场和产品扩展,包括新功能、特性或服务。 这些以及企业对其做出反应的能力也必须得到监控,以使企业长期保持竞争力。

自 1970 年代以来,经济全球化加速,迫使企业响应全球需求,而不仅仅是本地或区域需求。 在由此产生的竞争激烈的商业环境中,企业必须分析他们的财务目标、市场地位和他们参与的业务部门,以便了解需要哪些产品。

对于全新的产品、产品改进、新市场的渗透以及现有市场的增长,情况都是如此。

产品系统工程与产品开发的关系

产品开发是将新产品推向市场的过程。 产品 SE (PSE) 考虑完整的产品系统——即产品在其所有支持元素的背景下。 PSE 采用完整的生命周期视角,“ from cradle to grave” or “dust to dust. ”。

基于技术的产品开发可能被认为来自两个来源。 一是创新增强现有技术,是针对相对短期的市场窗口。 另一个涉及长期研究,以确定实现这一概念所需的技术发展。 这些技术可能在不久的将来无法预见其可用性,这意味着在达到概念验证、初始运营能力 (IOC) 或原型设计阶段之前可能需要大量投资和较长的交付周期,更不用说承诺实现实际产品供应。 一些作者声称,第二个来源的系统工程过程和新产品开发 (NPD) 过程是一回事。

战略计划(长期应用研究)在军用飞机或生物工程等领域实现新产品正是来自第二个来源。 当研究解决有关科学或国家/地区利益技术问题的基本问题时,就会出现突破。

本文集中讨论基于技术的产品开发的第一个来源,即由不断发展的市场需求驱动的产品开发,以增强现有技术。

产品开发模式

当利用现有或近期的技术创新来产生新的产品创意时,产品开发可能会遵循以下任何一种情况(Phillips 2001):

  • 产品开发可以使用成熟的技术来帮助企业提高当前运营的效率。
  • 产品开发可以使用成熟的技术来帮助企业进行新的运营。
  • 产品开发可以使用前沿技术来提高当前运营的效率。
  • 产品开发可以使用前沿技术来帮助企业进行新的运营。

产品本身可能只是对现有产品或其外观的修改,它可能具有新的或不同的特征,为客户提供额外的利益,它可能是全新的,满足新定义的客户需求或市场.

现有的实现或维护系统可能不足以开发给定的产品。 例如,可能需要改变开发实践,使用不同的测试方法或设施,或者升级制造设备和程序。 可能需要改进客户支持程序和新培训的支持人员,升级维护设施和工具,或改进备件交付技术。

市场压力

产品开发过程必须是动态的、适应性强的,并且在成本、上市时间、性能和质量方面在全球范围内具有竞争力。 这是因为在全球经济中不断的技术创新和不断发展的市场和客户需求需要快速响应。

产品本身通常是多学科的; 产品开发必须有密切的参与,不仅要从不同的专业工程领域(机械、电气、工业、材料等),还要从金融领域分析开发(包括生产)、营销和销售的总成本了解市场行为和接受度、制造商和分销商以及法律和公共关系专家。

所有这些都要求企业评估他们如何创造他们的产品和服务。 结果是努力简化开发过程。 这方面的一个例子是集成产品团队 (IPT) 的部署,有时称为集成产品开发团队 (IPDT)。

产品系统工程

产品系统工程致力于有效利用公司资源,以实现业务目标并交付优质产品。 产品系统工程活动范围从概念到分析再到设计,并确定如何改变概念和物理因素以制造满足客户要求的最具成本效益、环保的产品。 设计产品系统需要跨学科方法,包括对产品及其相关要素(如制造、维护、支持、物流、淘汰和处置)的分析; 这些都是属于实现系统或维护系统的活动。 系统工程和分析的正确应用可确保及时平衡地使用人力、财力、

产品与购买它们的客户一样多样化,并且没有普遍接受的方法、流程和技术 (MPT) 用于对产品及其支持子系统进行端到端分析。 每个产品都需要根据先前的经验和最佳实践来调整现有的 MPT,例如 Toyota (Hitchens 2007)、MITRE (Trudeau 2010) 和 NASA (NASA SELDP 2011)。 产品系统工程通过执行以下任务帮助开发产品和子系统的端到端分析:

  • 确定产品系统的总体需求范围;
  • 定义产品和系统要求;
  • 考虑产品系统不同元素之间的所有交互;
  • 组织和整合工程学科;
  • 建立包括审查、评估和反馈在内的规范方法,并确保有序和有效的进展。

不断发展的需求和要求,以及不断的技术创新,甚至可能在部署之前就使承诺的产品开发过时。 这导致了系统工程专业人士之间关于系统工程过程需要变得更快适应的辩论。 正在研究和提出基于平台的解决方案来解决其中一些挑战(基础设施即服务、平台即服务和软件即服务)(MITRE 2010;Boehm 2010)。

集成产品开发流程

集成产品开发流程 (IPDP) 从了解市场需求和制定战略开始,以创造满足或超过客户期望的产品,响应不断变化的客户需求,适应不断变化的业务环境,并结合系统思维来产生新颖的想法和合作利益相关者广泛参与,创造价值。 IPDP 是一个不断发展的过程,致力于实现其成本、性能、特性和上市时间有助于提高公司盈利能力和市场份额的产品。 马格拉布等人。 (2010) 从四个不同阶段讨论了 IPDP; 图 1 提供了 IPDP 的快照以及在每个阶段执行的主要任务。

第一阶段:产品识别

在产品识别阶段,企业的目标是确定一个企业范围的战略,该战略向下延伸到单个产品战略,从而为公司带来良好的业务投资。 在此阶段,除了产品的地理覆盖范围外,还确定了产品的潜在市场。 这一阶段的发展表明强烈的客户需求、潜在市场和地理范围的确定、企业核心能力与产品战略的匹配度、业务盈利能力(投资回报率、损益)等。

在此阶段,集成产品团队 (IPT) 首先为项目开发 IPDP,通常是通过定制公司 IPDP 标准。 IPT 评估所需的技术创新、现有技术的可行性、技术开发的预计时间和成本,以及与市场、财务和技术风险等相关的风险。这一阶段还考虑了持续改进 (CI) 流程的投入,以在现有产品中开发新功能和增强功能,以满足新的市场需求或客户需求。

第二阶段:概念部署

概念开发阶段的主要目标是为潜在产品生成可行的概念,并开发满足产品经济可行性和客户满意度的性能目标的 MPT。 这些概念设计必须确保公司的核心竞争力能够满足生产产品的要求,同时通过对替代工艺的广泛分析考虑市场可行性、可制造性和技术可行性。

在这一阶段,SE 支持 IPT 识别不同的运营场景和运营模式、产品的功能需求、技术和性能风险、产品的主要组成部分和它们之间所需的接口等。在几个 IPT 之间迭代交换概念,并且根据产品的复杂性,可能需要一个系统工程集成团队来确保分析所有可能的解决方案。 在此阶段,来自 CI 流程的输入有助于分析新技术/流程,包括对现有技术的升级,并创建可增强客户体验的产品。

第三阶段:设计和制造

在设计和制造阶段,实际产品被实现和制造。 此阶段首先为产品创建工程图、产品配置项规格、“X 设计”(DFX)、制造设计计划、生产计划和时间表、测试生产运行以确保产品满足客户要求和质量标准,以及全面的生产、物流和配送计划。

在此阶段,产品设计和制造工程团队与运营经理密切合作,创建 MPT,从端到端的角度管理产品的技术工作。 此阶段的一些 SE 活动包括产品集成、验证和确认计划; 关键场景下产品系统的建模、仿真、测试和评估; 启动准备计划,包括最终用户测试计划、操作准备等。在此阶段,开发并记录 MPT,以正确处理有缺陷的零件、流程或功能。 CI 过程输入包括产品和过程性能增强以及持续的生命周期操作支持。

第四阶段:产品发布

在产品发布阶段,产品被交付到其潜在市场。 在生产和部署期间,开发 MPT 以确保产品满足其质量目标、满足客户要求并实现业务计划目标。 这需要客户关怀、物流、维护、培训等方面的规定,以及监控产品和产品系统技术性能和产品质量的 CI 流程。 CI 过程是通过使用客户满意度调查以及远程或手动观察、记录和分析过程性能指标、技术性能指标、质量指标等的广泛数据收集来实现的。

图 1. 集成产品开发流程。 (SEBoK 原创)

产品系统工程与技术开发的关系

随着技术进步的加速,产品生命周期变得更短,特别是对于高科技产品。 因此,企业面临着与市场趋势、技术趋势或客户期望失去同步的过时或过时产品的风险。

产品系统工程应该将技术变化和趋势的意识带入新产品创意或创新的分析中。 这会影响产品技术可行性分析的时间和成本投入。 结果应包括所需技术开发的路线图,然后用于创建新产品的总体路线图。

在这些情况下,新产品创意对新技术开发提出了要求。

另一方面,当技术发展或突破推动产品创新或产生新市场时,技术发展也可能产生对产品特性和功能的要求。 决定引入产品的决定因素包括技术成熟度 (TRL)、集成技术成熟度 (IRL)、制造技术成熟度 (MRL)、系统技术成熟度 (SRL) 以及企业启动产品体系。

了解组成产品的实体(即组件或元素)对于系统工程师来说并非易事。 新产品需要开发多种技术的情况并不罕见,包括新材料、电子元件、软件、维护和维修程序、流程或组织结构。 为了成功部署和正确使用产品,所有这些发展都必须纳入 IPDP。

图 2. 构成产品系统的基本产品类型(Martin 1997)。 本材料经 John Wiley & Sons, Inc. 许可复制。版权所有者保留所有其他权利。

产品类型示例

每种产品类型的示例如下所示(Martin 1997)。

表 1. 产品类型(Martin 1997)。 本材料经 John Wiley & Sons, Inc. 许可复制。

类型 例子
硬件 计算机处理器单元、雷达发射器、卫星有效载荷、电话、柴油发动机、数据存储设备、网络路由器、飞机起落架
软件 计算机操作系统、固件、卫星控制算法、机器人控制代码、电话交换软件、数据库应用
人员 宇航员、计算机操作员、文员、业务主管、莱卡(宇航员狗)、公交车司机、收银员、维修技师
设施 航天火箭发射台、仓库大楼、航运码头、机场跑道、铁轨、会议室、交通隧道、桥梁、局域网电缆
数据 人员记录、卫星遥测数据、指挥和控制指令、客户满意度评分
材料 石墨复合材料、纸、金、混凝土、石材、玻璃纤维、雷达吸收材料、覆层金属、集成电路基板、磁记忆芯
媒体 数据存储媒体(磁带、磁盘、存储卡)、信号传输媒体(双绞线、光纤电缆、射频频谱)、通信媒体(电视、广播、杂志)、社交媒体(博客、Twitter、Facebook)
技术 焊接、故障技巧响应流程、变更通知处理、电话应答协议、项目调度、数据排序算法

材料可以被认为是基本原材料,如钢,或复杂材料,如复合金属、石墨复合材料或建筑骨料。 人员通常不被视为“产品”,但这可能会根据相关系统的类型而改变。 美国国家航空航天局 (NASA) 太空计划“系统”肯定会产生宇航员。 当人员被视为产品时,通常不可能简单地找到并雇用具有必要知识、技能和经验的人员。 这些人员“产品”通常可以使用产品 SE 方法开发(Martin 1996)。 例如,您可以为系统中的每个人指定要求(即,所需的知识、技能和经验)。 可以为每个人指定接口, 并且可以对每个人(即每个潜在产品)的成熟度进行评估。 这些是产品 SE 如何应用于个人产品的几个示例。

在企业系统工程中,我们可能需要教育和培训系统来构成我们人事系统的一部分,以培养具有适当能力和能力的人。

产品作为一个系统的基础

产品元素和连接

产品系统由产品要素和两种联系组成:要素之间的联系,以及系统环境中要素与事物之间的联系。 可以受系统影响或可以影响系统的那部分环境称为“上下文”。

元素之间的连接包含交互和关系(Hybertson 2009)。 连接不仅仅是一个接口。

交互发生在系统内部或外部元素之间的 界面 上,可以定义为数据、材料、力或能量的交换。 具有交互性质的连接可以在各种工程工件中表示:原理框图、数据流图、自由体图、接口控制图、端口规范、能量传输图等。 产品系统工程 (PSE) 通常在接口控制文档、接口设计文档、接口需求文档或等效文档中定义交互。

连接还包括元素之间的关系。 这些关系可以是空间的、运动相关的、时间的或社会的。

空间关系:

  • 一个元素在另一个元素之下
  • 两个元素 相距 x 个单位
  • 一个元素在另一个元素之内

运动相关的关系:

  • 两个元素的相对速度为 v 个单位
  • 两个元素之间的相对加速度是 一个单位

时间关系:

  • 一个元素先于另一个元素存在
  • 两个元素必须同时存在
  • 两个元素必须在时间上相隔 t 个单位

社会关系:

  • 人为因素对系统有一种专题的感觉
  • 一个人为因素拥有另一个(非人类)元素
  • 人为因素以特定方式理解系统的操作

与时间无关的关系仍然会随着时间而改变。 例如,在一种操作模式期间位于另一个元素内部的元素可以在不同的操作模式期间位于它之外。 因此,不应假设非时间关系在时间上必然是静态的。

关系可以在工程工件中表示,包括时序图、时间线图、任务参考配置文件、能力路线图和项目进度表。

社会关系包括人类因素在系统中所扮演的角色之间的隐含或明确的社会义务或期望。 可以为这些角色分配不同的权限、职责和责任。 请参阅文章Team Dynamics 中有关组织行为的讨论 。 在设计这样的产品系统时,可能需要考虑组织行为理论和人为因素。

人类与系统的非人为因素之间也可能存在社会关系。 这可能涉及人类如何“感受”系统中的事物,甚至可能涉及整个系统。 利益相关系统内部或外部的人可能对系统如何运行、其局限性和能力以及安全有效地运行它的最佳方式有不同程度的“理解”。 “所有权”关系在确定谁可以操作或更改系统的某些配置或模式等方面可能很重要。

产品系统中有许多这样的社会关系,在执行 PSE 时常常被忽视或误解。 社会关系可以影响产品系统的整体性能或行为,直至决定其成败。

核心产品及其赋能产品和运营服务

各种系统(它们本身就是产品或服务)支持产品的开发、交付、运营和最终处置,如图 1 所示。支持系统的概念在 ISO/IEC 15288 标准 (2015) 中定义。

图 1. 支持系统示例(Lawson 2010)。 经 Harold “Bud” Lawson 许可转载。 所有其他权利均由版权所有者保留。

在图中,利益相关的系统 (SoI) 在使用阶段作为交付产品或提供的服务投入运行,而在支持阶段同时提供维护和物流(由产品维护系统提供)。 这两个阶段通常是并行执行的,它们提供了观察产品或服务属性或操作和支持方式的任何变化需求的机会。 进行更改会迭代生命周期并产生新的或改进的产品或功能。

交付的产品及其支持系统共同形成了一个更广泛的兴趣系统 (WSOI)。 项目设计使能系统是一种基于企业的系统资产,它建立了组织项目的策略和方法,以便在整个生命周期内执行。 在许多较大的组织中,这种类型的支持系统是制度化的,可以基于项目管理协会 (PMI) 的建议。

产品系统应被视为使能服务系统。 也就是说,一旦部署,产品系统就会提供有助于企业运营的服务。 对 收单方 而言,SoI 为用户提供运营服务。 这在几个层面上都是正确的:

  • 硬件和软件产品用于提供服务系统,
  • 企业将产品整合为系统资产,并使用它们来实现运营,以及
  • 提供的产品集成到系统的系统中。

产品架构、建模和分析

IEEE 标准 1471-2000 将架构定义为“体现在其组件中的系统的基本组织、它们之间的关系以及与环境的关系,以及指导其设计和发展的原则”(IEEE 2000)。 同样,ISO/IEC 42010-2011 将架构定义为“系统在其环境中的基本概念或属性,体现在其元素、关系以及其设计和演进的原则中”(ISO/IEC 2011)。

产品的目的(利益相关者的需求)由产品系统(SoI)实现。 由于产品系统由不同的实体(组件、组件、子系统、信息、设施、流程、组织、人员等)组成,这些实体共同产生任何实体都无法单独实现的结果,因此构建产品是基于整个系统的方法。 使用整个系统方法进行架构意味着定义、记录、设计、开发、制造、分发、维护、改进和证明产品目标的正确实施,包括功能(“什么”)、行为(使用或预期操作)、逻辑(实体之间的交互和关系)和物理构造(Wasson 2006;Maier 2009;Blanchard 和 Fabrycky 2011)。

系统架构师从最高抽象级别开始,在识别组件、组件或子系统之前,专注于需求、功能、系统特征和约束(关注点)。 这是系统视图,用于表示利益相关者的市场服务描述或运营概念(对机会/问题空间的理解)。

随着对需求的更好理解,接下来要记录的是不同抽象级别的架构描述,代表各种利益相关者的利益。 这些是架构模型。 它们以产品系统的详细系统、操作、行为和物理要求的形式为产品目的定义可能的解决方案空间。

然后使用不同的建模技术来分析不同类型的需求。 对于操作场景和不同的操作模式,有层次分解和分配、架构框图(ABD)、功能框图(FBD)、功能流程图(FFBD)和用例图。 对于硬件和/或软件组件之间的交互和关系,有序列图、活动图、状态图和数据流图。 有关模型和建模的介绍,请参见(Maier 2009)第 8 章。

对解决方案空间的分析可以生成详细的技术规范、工程图、蓝图、软件架构、信息流等,这些都描述了产品系统中的实体。 一个实体的需求限制了它的属性和特征、性能水平、操作能力和设计约束。 在设计和集成期间,实体特征可以追溯到需求(需求 可追溯性 是 SE 的一个关键方面)。 在需求阶段创建的验证和确认计划是测试认证产品是否达到预期目的的基础。

总的来说,发生的事情是将一组需求转化为满足利益相关者需要的产品和过程。 该架构由一组模型表示,这些模型传达了产品意图和目的的集成视图,以及所有不同参与实体之间所需的交互和接口。 产品的目的是根据业务目标(市场、成本、功能、性能和交付时间)来阐明的。 这组模型包括足够的多样性,可以将信息适当地传达给利益相关者、设计师/开发人员、专业工程、运营、制造商、管理人员以及营销和销售人员。

已经开发了不同的架构框架来指导产品团队为商业和公共企业定义产品架构。 一般来说,架构框架描述了一个“视图”,意思是“从一组相关的利益相关者关注点的角度代表整个系统的模型集合”。 架构框架的主要例子是 Zachman 框架 (Zachman 1992)、开放组架构框架 (TOGAF) (TOGAF 2011)、增强型电信运营地图 (e-TOM),仅举几个商业领域的例子。 对于公共企业,一些架构框架包括国防部架构框架 (DODAF 2.0) (DoD 2010)、联邦企业架构框架 (FEAF) (FEA 2001)、

获得的产品和提供的产品之间的差异在定义产品系统需求方面起着重要作用。 被收购产品由收购方直接进行生命周期管理; 例如,获得的防御系统由国防机构定义、开发、测试、拥有、操作、维护和升级。

图 2. 系统架构描述元素(改编自 Wasson 2006)。 经 John Wiley & Sons Inc. 许可转载。版权所有者保留所有其他权利。

专业工程集成

INCOSE SE 手册 将专业工程定义为:

“分析系统的特定功能,需要专题技能来识别需求并评估它们对系统生命周期的影响。”

属于这一概括性定义的专业领域包括后勤支持、电磁兼容性分析、环境影响、人为因素、安全和健康分析以及培训。 利益相关系统的独特特征、要求和设计挑战都有助于确定适用的专业领域。

许多专业工程领域对于从事产品系统开发、部署和维护工作的系统工程师来说通常很重要。 例如,后勤支持对于需要维护和维修的现场产品系统至关重要。 支持系统所必需的服务、材料、零件和软件的交付必须在开发活动的早期考虑。 在系统要求和概念定义完成之前,通常应该考虑这些因素。 为了在早期充分整合这些专业学科,系统工程师需要知道哪些专业与正在开发的系统相关,它们如何与系统工程过程相关,以及如何将它们整合到生命周期过程中。

对于具有大量硬件内容并在具有挑战性的环境中运行的产品系统,通常必须考虑以下专业工程领域:

  • 可制造性,
  • 可靠性和可维护性,
  • 认证(在人身安全成为问题的情况下必不可少),
  • 后勤支持,
  • 电磁兼容性(如果它们辐射),
  • 对环境造成的影响,
  • 人为因素,
  • 安全和健康,
  • 训练。

必须理解和考虑这些专业领域与系统工程过程的关系。 关系的关键方面是:

  • 当需要考虑专业时,
  • 它提供了哪些基本数据或信息,
  • 在系统工程过程中不包括专业的后果,
  • 系统工程师应如何与专业工程师互动。

Grady (2006) 提供了包括可靠性工程在内的许多专业工程学科的概述和参考资料; 零件、材料和工艺工程(PMP); 可维护性工程、可用性、可生产性工程、设计成本/生命周期成本 (DTC/LCC)、人因工程、腐蚀预防和控制 (CPC)、系统安全工程、电磁兼容性 (EMC) 工程、系统安全工程、质量特性工程和环境影响工程。

Eisner (2008) 将专业工程列为系统工程的“三十个要素”之一。 “专业工程是指一组必须在一些但不是全部的系统工程工作上探索的工程主题。 换句话说,有些系统涉及这些专题学科,有些则不涉及。 专业工程领域的例子包括电磁兼容性和干扰、安全、物理安全、计算机安全、通信安全、需求预测、面向对象设计和价值工程。” 我们在本文中考虑的一些专业工程,艾斯纳包括在他的系统工程的“三十个要素”中,但不作为专业工程要素的一部分。

没有标准的专业工程学科列表。 什么被认为是专业工程取决于系统工程所属的社区,有时还取决于客户的偏好。

与产品系统工程相关的业务活动

本主题讨论产品系统工程与企业中发生的其他“(公司的)业务部门”和管理活动之间的接口。

市场营销、产品生命周期管理和质量管理

产品系统工程(PSE)包括与相关业务活动(如营销、产品生命周期管理(PLM)和质量)的关键和可靠接口。传统上,PLM一直是集成产品开发过程(IPDP)中的一个关键阶段,并继续是产品部署后生命周期管理的重要工具。PLM是PSE端到端视图的重要组成部分。另一个组件是“广度”组件,它捕获每个生命周期阶段与系统相关的所有内容。最近,焦点已经开始从只管理产品生命周期的想法转移到包括产品线(系列)或产品平台本身管理的扩展视图。这提高了可持续性、灵活性,缩短了开发时间,并大大降低了成本,因为新产品或增强型产品并非每次都是从零开始推出的。

PSE 还包括与营销功能的接口; 特别是,PSE 与业务和市场开发组织密切合作,以获取目标市场的产品需求和预期运营,以确定产品推出和产品引入的可能阶段。 在从概念到退役的整个产品生命周期中,市场分析至关重要,因为每个生命周期阶段都需要非常不同的营销方法。 在概念开发过程中,营销必须帮助确定潜在市场、可寻址的细分市场、定义产品以及这些市场的产品/创新要求。 在产品推出阶段,营销必须创造需求并促使早期客户尝试产品。 在成长和成熟阶段, 营销必须提高公众意识,发展品牌,并区分产品及其功能和功能发布,以与新的市场进入者竞争。 在饱和期间,随着关注点从顶线(增加市场份额)转移到底线(提高生产和分销效率)考虑,营销必须帮助管理不断减少的销量和收入。

PSE 和质量之间的联系同样重要。 PSE 和质量之间的关系也反映了包括产品和机会在内的广阔视野,也反映了公司的内部目标、流程和能力。 历史上已广泛使用关注有形产品的质量方案。 承认并符合 PSE 整体观点的最新方法已经开始使用。 ISO 9000 于 1988 年发布,是一系列标准,侧重于流程和组织,而不是产品本身。 此外,它还对产品和服务的设计提出了具体要求。 ISO 9001 已为许多其他针对特定领域量身定制的方案提供了“平台”。 国际航空航天质量小组的共同努力, AS9100 包含 ISO 9100 的所有基本要求,并扩展了对航空、航天和国防工业至关重要且特定的进一步要求。 同样,QS-16949 是基于 ISO 9001 的技术标准,但经过扩展以满足全球汽车行业的特定要求。 PSE 应该在任何质量管理体系的设计和实施中发挥重要作用。 见上的文章质量管理。

用于开发的能力成熟度模型集成 (CMMI)是一种过程改进方法,其目标是帮助组织提高绩效。 CMMI 可用于指导整个项目、部门或整个组织的过程改进。 虽然最初用于软件工程和组织开发,但 CMMI 的使用正在扩展到其他领域,因为它为组织提供了有效过程改进的基本要素。 根据卡内基梅隆软件工程研究所的说法,CMMI 描述了“从临时的、不成熟的过程到具有改进的质量和有效性的有纪律的、成熟的过程的进化改进路径”。 (SEI 2010)。

项目管理与业务发展

PSE要求的端到端视图需要与项目管理和业务开发活动建立牢固的关系。PSE鼓励的“并行”思维必然需要多个项目并行推进,但需要高度协调。从这个意义上讲,PSE和项目管理(参见系统工程和项目管理)是两个高度交织的学科,已经证明它们能够为利益相关者产生协同效应和附加值。

系统工程(engineering)管理策划(plan)(SEMP)是一份关键文件,涵盖了确保相关系统实现其预期目标和任务所需的活动、里程碑、组织和资源需求。SEMP通常在概念设计阶段制定,其一个关键目标是提供结构、政策和程序,以促进系统开发和实施所需项目和活动的优化管理(Blanchard和Fabrycky,2011)。

有效且灵活的PSE功能可以为企业或公司的业务开发做出重要贡献。业务开发活动的主要目标是确定新类型的业务/产品/服务,这些业务/产品/服务被认为可以解决现有或潜在的需求和差距(新市场),吸引新客户使用现有产品,并打入现有市场。PSE对生命周期的端到端观点可以通过情报收集、对市场接受或拒绝的反馈、战略分析、提案开发和活动开发来支持市场开发。最后,PSE应鼓励在新产品开发中考虑多个因素,以促进市场开发。例如,在成熟的公司中,业务发展通常可以包括与其他第三方公司建立战略联盟。在这些情况下,公司可以利用彼此的专业知识和/或知识产权来提高识别、研究和将新业务和新产品推向市场的可能性。见(Sørensen 2012)。

供应链管理与分销渠道管理

PSE 为企业的供应链管理功能提供以下信息:

  • 产品规格(包括产品的预期用途),
  • 产品验收标准(用于接受供应商交付的产品),
  • 产品测试和鉴定计划和程序,包括哪些是供应商的责任,哪些是需方的责任,
  • 与每个产品相关的接口规范,
  • 供应商认证标准(包括预先认证的供应商名单),
  • 对供应商交付的产品质量的反馈。

供应链管理将在必要时在系统工程和产品工程师的同意和协调下管理合格供应商的识别和认证。

PSE 为企业中的分销渠道管理功能提供以下信息:

  • 产品规格(包括产品的预期用途),
  • 产品用户手册(包括安装和维护文档),
  • 产品包装(用于安全交付产品和在零售渠道展示),
  • 产品合格数据(证明产品符合其设计要求),
  • 产品认证数据(证明产品已通过安全可靠操作认证),
  • 用户支持说明,
  • 操作员认证标准。

分销渠道管理将在必要时在系统工程和产品工程师的同意和协调下管理合格分销商的识别和认证。

能力管理与运营管理

能力的定义方式多种多样,但每种定义都与“做有用的事情的能力”的概念一致。 最终用户获取产品和服务是为了启用和提高他们的操作能力,让他们做一些有用的事情,无论是在军事背景下(例如,武器系统提高了进行有效军事行动的能力),还是在社会背景下(例如,汽车可以提高满足家庭交通需求的能力)。 用户获取产品(例如,军事装备、汽车、航空公司和出租车公司提供的“产品化”服务等)以有助于满足他们的能力需求。

能力管理 包括识别和量化满足企业目标所需的能力(现有的、新的或修改的),以及跨 能力的所有组成部分选择一组连贯的产品和服务这将被集成以提供所需的功能。 所以通常,对“产品系统”的需求来源于能力管理。 能力管理可能包括权衡过程,以充分利用现有产品或现有产品的低风险演变,反之,识别何时只能通过新一代产品或什至新型产品才能令人满意地满足能力需求的产品。 在某些情况下,新提供的产品或颠覆性技术(例如,喷气发动机、核武器和互联网)为新的或改进的能力创造了机会,在这种情况下,能力管理的重点是确保所有需要的能力组件都到位以进行利用新产品或新技术提供的机会。 请参阅 能力工程

运营管理使用一组集成的产品系统为企业及其利益相关者提供价值。 运营管理涉及将新产品系统投入运营,通常同时保持业务连续性,因此过渡计划和相关指标至关重要; 接下来,运营管理解决以下一些问题:在能力的所有组成部分中实现全面运营效率,应对事件,应对重大中断的应急计划,调整系统以应对新的工作方式并提供新的服务满足新的企业需求并适应新的产品系统进入服务,并最终计划停止服务或重大服务升级。 PSE 通过定义所有依赖项以在其他系统和服务上成功运行,并通过为备件和维修、报废管理和系统升级提供持续的工程支持来支持运营管理。 已对服务阶段的系统工程进行了分析(Elliott 等人,2008 年),最好将其视为以更高速度进行的相同基本系统工程过程(Kemp 和 Linton,2008 年),并且需要详细了解由当前环境和使用情况。 运行期间的配置管理和配置状态核算对于高价值和高完整性的系统非常重要,以确保任何更改都旨在适应“原样”系统,这可能与“原样”系统有很大不同

产品工程、组装、集成和测试

产品工程通常会产生一个工程模型,该模型用作组装、集成和测试 (AIT) 产品系统的“蓝图”。 这些 AIT 活动可以在原型版本以及交付给最终用户的最终生产版本上执行。 在针对复杂产品执行 AIT 的领域特定行业中拥有丰富的经验。 不幸的是,在一般文献中写的很少。 Wasson (2006) 和 de Jong (2008) 涵盖了其中一些方面。 另请参阅系统集成和 系统验证。

对于软件产品,代码模块的集合通过某种形式的集成程序(通常称为“make”)进行集成。 然后对集成模块进行测试,以通过软件测试各种潜在路径。 由于软件可以很容易地更改,因此通常使用基于测试套件的某种形式的回归测试来验证软件的正确性。 另一种常见的测试方法是通过 Voas 和 McGraw (1998) 描述的故障注入。

生产、测试和认证

系统工程师通常通过电气和机械设计团队间接从事生产工作。 在开发周期中,有时系统工程和生产之间的直接接口和工作关系是适当的,并且可以提高程序和系统成功的可能性。 在程序的早期,必须检查系统概念以确定它是否可生产。 应与生产工程师一起审查要求和概念设计,以评估与系统生产相关的风险。 如果确定了重大风险,则可能需要采取措施提高组织的生产能力、修改设计并可能更改要求,以将已确定的风险降低到可接受的水平。 生产原型或生产证明 (POM) 单元可能是必要的,以降低风险并证明已准备好继续进行设计和系统开发。 同样,系统工程师必须在产品开发阶段的早期确定系统是可测试的。 在将要求发布给设计团队之前,应将要求映射到检查、分析、演示和测试的验证方法。 必须检查映射到测试的所有要求,以确定测试方法和与完成必要测试相关的风险,作为产品认证、验收和发布过程的一部分。 在识别出风险时,系统工程师必须与测试工程师一起开发必要的测试能力。 在将要求发布给设计团队之前,应将要求映射到检查、分析、演示和测试的验证方法。 必须检查映射到测试的所有要求,以确定测试方法和与完成必要测试相关的风险,作为产品认证、验收和发布过程的一部分。 在识别出风险时,系统工程师必须与测试工程师一起开发必要的测试能力。 在将要求发布给设计团队之前,应将要求映射到检查、分析、演示和测试的验证方法。 必须检查映射到测试的所有要求,以确定测试方法和与完成必要测试相关的风险,作为产品认证、验收和发布过程的一部分。 在识别出风险时,系统工程师必须与测试工程师一起开发必要的测试能力。

产品交付和产品支持

大多数产品在使用阶段的生命周期比在开发阶段要长得多。 与产品支持相关的成本通常高于开发产品的成本。 这两个事实使得产品系统工程师将产品交付和支持视为开发过程中最早活动的一部分非常重要。 产品的设计决定了所需的维护和支持。 系统要求是影响设计以实现所需产品支持的首要手段。 如果客户未定义维护、可靠性和支持要求,则系统工程师必须定义这些要求以实现客户、用户和负责支持的组织认为在财务上可接受的支持方法和成本。

产品系统工程的主要方面

获得的产品与提供的产品

传统系统工程 (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. 从行业角度看的产品生命周期。 来源:于 2012 年 2 月 6 日访问。制造工程实验室的 NIST 计划,由美国联邦政府发布,公共领域)

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

图 4. Rogers创新采用曲线。 来源: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)。

产品系统工程专题活动

产品系统工程具有产品特有的活动。本文讨论了其中的许多问题。

随着新系统的开发,必须验证和验证开发的系统是否足够成熟,可以作为可操作的产品或服务发布。

这一成熟度概念由美国国家航空航天局 (NASA) 正式确定(Mankins 1995),后来经过修改以供国防部 (DoD)、空军研究实验室 (AFRL) 和美国能源部使用(DoE) 以及越来越多的非政府组织。 技术成熟度 (TRL) 是一种衡量的指标。 最初的 NASA TRL 规模有九个不同的级别,从 观察和报告的基本原理(TRL 1) 到 通过成功的任务操作“飞行证明”的实际系统(TRL 9)。 国防部使用的 TRL 规模如表 1 所示。

表 1. 评估关键技术的技术成熟度(Mankins 1995)。 由美国宇航局空间访问和技术办公室高级概念办公室发布。

  描述
1. 遵守和报告的基本原则。 最低水平的技术准备。 示例可能包括对技术基本属性的论文研究。
2. 制定技术概念和/或应用。 发明的开始。 示例仅限于分析研究。
3. 分析和实验的关键功能和/或概念的特征证明。 包括分析和实验室研究,以物理验证对技术的单独元素的预测。 示例包括尚未集成的组件。
4. 实验室环境中的组件验证。 集成了基本技术组件。 与最终系统相比,这是相对“低保真度”的。
5.相关环境中的组件验证。 基本技术组件与合理逼真的支持元素相结合,因此可以在模拟环境中进行测试。
6. 相关环境下的原型演示。 在相关环境中测试的代表性原型系统。 代表技术已证明准备就绪的重要一步。 示例包括在高保真实验室环境或模拟操作环境中测试原型。
7. 操作环境中的原型演示。 在计划的操作系统附近或附近进行原型设计。 代表 TRL 6 的主要设置,需要在操作环境中演示实际系统原型。
8、系统通过测试论证合格。 技术证明可以在其最终形式和预期条件下工作。 代表真正系统开发的结束。 示例包括系统的开发测试和评估。
9. 通过成功的任务操作证明的系统。 该技术在最终形式和任务条件下的实际应用,例如在操作测试和评估中遇到的情况。

TRL 的使用对生命周期的结构和操作有影响,如第 3 部分所述; 它们可以更好地管理和控制技术固有的风险,以及更好地控制成本和方案开发的时间表。 然而,正如 Smith (2005) 所指出的那样,TRL 没有提供对 TRL 的程序影响、技术关键性和优先级、软件老化和准备情况的评估。 尽管 TRL 已被证明可用于评估技术性能,如实验室或测试环境中所证明的那样,但它们并不能告知人们是否可以以负担得起的方式实际生产技术产品。 制造技术成熟度 (MRL) 的概念已被纳入以扩展 TRL 的想法,以便它可以包含可生产性问题。

图 1. 技术成熟度及其与系统采购里程碑的关系(Morgan 2008)。 由美国空军制造技术部发布。

技术成熟度是学术界和政府机构的一个活跃研究领域,涉及将技术组件集成到复杂系统中(集成技术成熟度 (IRL)),以解决现有和成熟技术开发之间的接口成熟度。 TRL 适用于关键的使能技术,这些技术通常体现在子系统、装配级别或系统组件级别。 从单个技术到整个系统时使用系统就绪级别 (SRL)。 SRL 模型是系统中各个 TRL 及其与其他技术 IRL 的后续集成点的函数(Sauser 2006)。

另一个成熟度方面与提供现成的产品有关,称为商业现货 (COTS)。 此类产品,无论是硬件、软件还是两者的混合,都有望达到成熟程度,以便获得它们的人可以依赖其操作特性,并且 COTS 产品的文档足以为其提供适当的指导。利用。

PSE 应该意识到,如果操作环境或其他要求超过了 COTS 产品的设计限制(例如,在非常高或非常冷的温度、高冲击或振动水平下操作),则 COTS 的 TRL 评估会发生巨大变化。

产品认证

产品认证既针对特定领域也针对特定产品,通常与人类安全和健康、满足特定政府法规的需求或承保人出于保险目的而要求的相关。 认证由第三方(独立于开发商)执行,该第三方向客户或用户提供产品质量、安全性和可靠性的保证。

INCOSE SE 手册将产品认证定义为“证明某一产品已通过建筑规范或国家认可的测试标准等法规中规定的性能或质量保证测试或资格要求,或符合一系列规定的过程。管理质量或最低性能要求。” (INCOSE 2012)

INCOSE SE 手册还定义了四种验证方法:检查、分析、演示和测试 (INCOSE 2012)。 此外,它将认证定义为第五种验证方法,即由外部机构根据法律或行业标准进行验证,而无需指示该机构如何验证要求。 例如,电子设备在欧洲需要 CE 认证,在美国和加拿大需要 UL 认证 (INCOSE 2012)。

最著名的认证是适航认证,它关系到飞机的飞行安全。 在美国,该认证的测试由美国联邦航空管理局 (FAA) 执行。 政府认证在联邦药物管理局 (FDA) 是主要认证机构的医疗系统领域也很常见。 一些认证基于技术协会定义的标准,例如美国机械工程师协会 (ASME)。 技术标准和认证的结合使产品开发人员能够执行符合政府标准的认证,而无需政府直接参与该过程。

在其他国家和其他受监管领域,如通信、建筑安全、核系统、运输系统(包括船舶、火车和汽车)、环境影响和能源使用,也有同等的政府组织。 系统工程师必须了解正在开发的领域和产品所需的认证。 认证机构必须尽早参与开发工作,以确保必要的认证包含在系统要求、系统开发计划和为完成开发而提供的资金中。 当需要进行系统更改和升级时,系统工程师必须确定是否需要重新认证产品,并将其包含在系统升级的计划和资金中。

启用产品认证

PSE 必须考虑和认可其他授权产品的认证,例如飞机飞行员的操作员认证以确保飞行安全,以及核电厂操作员的认证以确保防止或减轻核辐射影响。 北美电力可靠性公司 (NERC) 的认证计划中显示了这方面的一个示例:

为了支持 NERC 的使命,系统操作员认证计划的任务是确保雇主拥有一支符合最低资格的系统操作员队伍。 这些最低资格是通过国际公认的流程和程序为认证人员的机构设定的。 认证计划促进系统操作员绩效领域的卓越表现,并鼓励系统操作员保持好奇和知情。(NERC 2012)

生产资格测试 (PQT) 是另一种类型的认证,DAU (2005) 将其描述为:

在全速生产 (FRP) 决策之前完成的技术测试,以确保制造过程、设备和程序的有效性。 该测试还用于为材料放行所需的独立评估提供数据,以便评估者能够针对所述要求确定材料的充分性。 这些测试是对从第一个生产批次中随机抽取的一些样品进行的,如果工艺或设计发生重大变化并且当第二个或替代来源上线时,则会重复这些测试。

在机密环境中部署计算和网络设备通常需要安全认证和认可 (C&A)。 可能需要设施认证以确保容纳设备的建筑物能够为设备的安全和高效运行提供适当的环境。 可能需要高海拔电磁脉冲 (HEMP) 认证,以确保建筑物及其设备能够承受来自核武器的 HEMP 的影响。 与 HEMP 类似的认证类型是 TEMPEST 测试,以确保不允许敏感的电子发射离开高度安全的设施。 TEMPEST 是一个代号,指的是对危害排放的调查和研究,而不是首字母缩略词。

技术规划与插入

技术规划可以是企业功能或程序功能。 作为企业职能的技术规划通常每年进行一次,以确定来年独立研发所需的资金。 作为程序功能的技术规划发生在程序的早期,并且通常在系统的整个生命周期中持续存在。 产品系统的设计高度依赖于具有可接受风险并满足客户成本、进度和性能要求的技术的可用性。 只有在系统工程师进行概念设计、技术评估、

MITRE 系统工程指南(MITRE 2011) 为技术规划提供了以下定义:

技术规划是规划程序或系统的技术演进以实现其未来愿景或最终状态的过程。 技术规划可能包括期望的客户成果、技术预测和进度计划、要求和规划,以及技术插入点。 目标是随着时间的推移通过技术插入实现定义的技术最终状态。

参与技术规划的系统工程师必须了解未来的愿景和系统要求,并将这些与当前和预期的未来技术联系起来,这些技术可以应用于当前开发阶段的系统设计,以及系统未来可能的升级。 为此,系统工程师必须获取并保持其设计领域中现有和正在开发的技术的知识。 系统工程师还将提供系统用户和研究社区之间的基本连接,以提供技术开发人员和系统设计人员之间的一致性。

技术规划和插入通常要求系统工程师执行技术准备情况评估,评估与计划技术相关的成熟度水平和风险。 不成熟的、有风险的技术需要降低风险的活动,包括原型设计和产品开发以及提供能力和风险量化的测试活动。 风险降低活动提供了评估和更新设计以降低风险所需的数据。

产品路线图和发布计划

产品路线图提供了一个大纲,显示了产品计划发布的时间,并包括产品主要和次要功能的概述。 应创建内部和外部产品路线图。 路线图的形式将取决于所使用的开发方法。 瀑布式、迭代式和螺旋式开发模型导致不同的路线图和发布计划。 系统工程师必须是创建路线图的团队中不可或缺的成员。 需求应该映射到每个计划的发布。 测试计划必须适应开发模型和发布计划。

产品路线图应与适用于产品的技术路线图保持一致。 应在技术纳入产品开发计划和包含这些技术的产品发布路线图之前完成。

产品路线图对于具有许多软件版本和功能升级的软件密集型系统至关重要。 为每个版本提供的需求、测试计划和功能的识别是产品开发过程的基本驱动力。 这些项目的明确定义可以在交付客户正在寻找和将支持的功能之间产生差异,或者产品不能满足客户的需求并被放弃。

知识产权管理

系统工程师还必须将管理知识产权作为其工作的一部分。 现有的系统工程文献很少涉及这个主题。 然而,有许多教科书和管理相关文献提供了额外的信息,例如“工程师的知识产权”(Irish 2005)。 知识产权可以被视为 理性思维过程的无形输出,具有一定的知识或信息价值,通常通过使用版权、专利和/或商业秘密来保护(Irish 2005)。 下面列出了一些更重要的知识产权类型,并附有简要说明:

  • 专有信息:任何使公司(或企业)比其竞争对手更具优势的信息通常是专有的。
  • 专利:专利是保护发明或发现权利的主要机制。 作为全面披露如何实施发明的交换,颁发政府将授予在有限的时间内排除他人实施发明的权利,通常为 15 至 20 年(在美国,专利通常持续 17 年)自发布之日起)。
  • 外观设计专利:在某些国家/地区,使用更合适的术语“外观设计注册”或其他名称 来指代这些专利。 它们保护装饰设计的权利,前提是这些设计是新颖的和创造性的,即在制作时 不明显。 在美国,外观设计专利的最长期限为 14 年。
  • 商标:商标标识商业商品的原产地,并不强于其实际使用和保护其免受侵权、侵占或稀释的努力。 在某些情况下,商标可能会在政府机构注册。 公司最有价值的资产之一是公司名称,它也是公司的主要商标。
  • 版权:版权主张保护著作、音乐作品和艺术作品等作品不被他人复制,即不被剽窃。 版权声明必须在受保护作品首次出版时以法律规定的方式发出。

零件、材料和流程管理

系统工程师需要清楚地了解由于零件、材料和工艺 (PM&P) 问题导致的任务失败或无法按时部署系统的后果,因为这些要素是整个任务可靠性和项目成功的基础。 PM&P 管理在恶劣环境(如外层空间和水下)以及系统故障可能对公共安全造成灾难性影响的情况下(如核电、桥梁和隧道以及化学加工厂)尤为重要。

一般而言,从事电子系统设计和制造的原始设备制造商 (OEM) 具有处理 PM&P 的书面政策,有时采用 PM&P 管理手册的形式。 PM&P 控制程序的要素包括:

  • 适用于系统的 PM&P 要求;
  • 计划或项目批准的零件清单 (PAPL) 的代号;
  • 任命 PM&P 控制委员会 (PMPCB);
  • 为报废使用制定零件应力降额政策和零件参数降额政策;
  • 零件的最低资格、质量控制和筛选要求的定义。

PM&P 管理指南由 MIL-HDBK-512 (DoD 2001) 和 ANSI/AIAA R-100 (2001) 提供,它们确定了 PM&P 计划的整体管理过程元素。 PM&P 需要解决的其他问题包括:有害材料、稀土元素、冲突材料和假冒材料。

 


您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码: 验证码,看不清楚?请点击刷新验证码 必填



2250 次浏览
7次
欢迎参加课程:
数据建模方法与工具
MBSE(基于模型的系统工程)
基于 UML 和EA进行分析设计