技术开发是技术规划得以成功实施的主要手段，是产品开发得以高效完成的基本保障。本节中，笔者从技术开发的特点要求、技术开发的项目类别，以及技术开发中的架构开发、构件开发、平台开发等的流程和活动，谈一谈技术开发的相关内容。
一、特点要求
同样作为研发领域的执行环节，技术开发与产品开发有着很多相似之处。但是，因为开发目的、客户对象、开发内容、交付形态等的不同，技术开发与产品开发还是有着很大的不同，故而有其本身特有的管理要求。
1）技术开发的特点
开发目的方面，技术开发是为了更好为企业中长期战略目标的达成、产品战略的实施和产品开发的高效，提供必要和坚实的技术支撑。
预算来源方面，技术开发是服务于企业所有的产品线，故而，技术开发的预算通常来自于企业的战略预算，财务角度则主要关注其成本竞争力。
需求来源方面，技术开发的需求，是在综合多个产品线的技术需求的基础上，基于架构设计和技术要素的要求转换而来。
交付形态方面，技术开发的交付成果是各产品线所需的通用核心能力，要求该能力符合高可靠、高性能、易扩展等要求。另外，技术开发的交付成果需要进一步集成到产品来进行充分验证，并与产品一起来达到量产质量要求。
客户对象方面，技术开发的客户对象是各产品开发团队（PDT），要很好地支持PDT基于客户需求进行产品的二次开发和产品的快速上市。
2）技术开发的要求
因为存在上述特点，技术开发在团队职责和功能任务等方面具有本身特有的管理要求：
市场类功能任务方面，重点关注战略支撑、需求控制和技术内部推广，不涉及对外销售，不涉及定价、预测、上市准备、订单履行等市场活动。
财务类功能任务方面，重点关注成本核算和目标成本的达成，不关注收入和利润等收入性指标。
服务支持类功能任务方面，重点关注如何更好地支持PDT进行产品开发中的二次开发。
制造类功能任务方面，技术开发的交付成果需要集成到产品中才能完成最后的转产，因此，技术开发流程中不需要单独定义相应的量产活动。
采购类功能任务方面，重点关注的是外购CBB的寻源、采购和整合。
研发类功能任务方面，平台、组件等类型的技术开发流程，需要有一个迁移阶段来保证交付成果能顺利迁移到产品，并有效支持产品验证和转产。
二、项目类型
根据模块化产品定义的理念，企业往往将产品的实现元素分为这么几个层次：技术要素、器件/组件、子系统、平台、产品线和产品，其中，产品线和产品属于产品规划和产品开发的范畴，技术要素、器件/组件和平台属于技术规划和技术开发的范畴。另外，为了确保产品的高可靠、易扩展和实现元素之间的和谐融合，需要在产品架构的指导或约束下，进行实现元素的设计和开发。
实际上，在技术规划时，已经根据技术的层次和内容的不同，将技术开发任务做了明确区分，区分为架构的开发、器件/组件的开发、平台的开发，等等。与之对应，技术开发项目也基本可分为架构开发、构件开发（本节以“构件”，代指技术要素、器件/组件和子系统等类型的产品构件）、平台开发等三种类型。
图4.48 产品实现元素的分层和技术开发项目的分类
架构是指一个系统的一个或多个结构（视图），它包括组成系统的元素、元素的外部可见属性和元素之间的相互关系（SEI给出的架构定义）。架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本结构，以及指导系统设计与演化的原理（IEEE给出的架构定义）。
由上述定义可知，架构是一种系统工程方法，它以多种结构视图的形式（至少包括静态的模块视图、动态的过程/进程视图和系统实例的部署视图），定义和管理“系统”的复杂性，包括系统元素或构件之间、构件与环境之间的关系，以及关系演变的原理和规则，是系统设计的指导和约束。
一个具有良好架构的系统，系统的内部结构、构件之间的逻辑关系、系统与外部环境的接口，等等，有着清晰和整洁的定义，系统的演变也有规律可循。故而，此类系统具有高可靠、高性能、易理解、易维护、易扩展等优点。
以架构的系统工程方法来定义、设计、开发和维护产品，是与产品的机、电、软一体化趋势下的必然要求。通常，机、电、软一体化的产品，其系统复杂度远高于单纯的机械产品，产品的模块化、平台化，以及生命周期中的持续迭代，也需要有清晰的架构定义来进行指导和约束。
因此，高复杂、模块化、平台化的技术开发，首先要完成架构的开发，交付成果就包括产品系统的多结构（视图），以及产品迭代演进的原理和规则。
2. 构件
构件代表那些可支撑多个产品实现的通用能力，是产品结构中技术要素、器件、组件、子系统等产品构件的统称。
典型的构件是产品中一组实现特定功能，具有接口要素、性能及规格的实体单元，也就是所谓的基础模块（Building Blocks，简称BB），以及具有跨产品高重用度的共用基础模块（Common Building Blocks，简称CBB）。
在交付形态上，构件是产品的部件，需要进一步与其他部件集成，才能形成客户所需的产品。构件也只有集成到产品并进行充分验证后，才能和产品一起达到量产质量要求。
简要来说，构件的开发，是综合了多个产品（线）的通用能力需求，先于产品开发而进行的技术开发，是技术开发的主要分支。
3. 平台
平台是特定架构及基于此架构的一组技术构件的有机集合。我们可以用一个简单的数学公式来表示平台与架构、构件等之间的关系：
平台为产品提供通用基础能力，产品以平台为基础加上客户化特性，就能快速形成不同产品系列。因此，平台具备这么几个特征：1）基于特定架构；2）共享性、通用性；3）具有较高的战略价值；4）高度可集成性、可快速实施；5）具备二次开发能力、易扩展；6）与产品之间的界面清晰，可实现上层功能的技术无关性。
从平台的定义和特征可知，平台开发需要在架构开发和相关构件开发的基础上进行，必须先完成架构的开发和相关构件的开发，才能进行平台的开发。
三、架构开发
在机、电、软一体化的产品中，机械、电气电子、软件等产品构件，因为其技术形态不同，在功能机理、构件属性和接口关系等方面有着各自不同的特点和要求，往往要以领域的形式来进行架构的设计和开发。
实际上，纯机械形态的产品基本上只有平台的概念，而架构则主要是针对电气电子、软件等而言，这才有电气电子（简称E/E）架构、软件架构的说法。因此，与之对应的架构，也称为领域架构。产品构件的重用，实际是基于领域架构的重用。
图4.49 架构开发的流程示意
1.需求分析阶段
架构开发的需求分析阶段有两个关键步骤：
1）业务建模。理解目标系统所处的背景或更大系统的结构、业务及其动态特性。
2）领域需求。确定领域系统需要考虑的要求，规范，进而刻画和确定系统需求的规格。
上述关键步骤分解进一步为功能任务，具体包括：
1）组建项目组。
2）基于目标领域系统所在的上下文语境（Context），建立业务模型和领域模型。
3）分析领域包需求，使用用例分析方法和质量属性场景方法定义系统需求规格。
4）参考需求分析的结果，制定或调整项目计划。
需求分析阶段的阶段输入有：目标领域系统的上下文语境、领域包需求；阶段输出有：领域模型、系统需求规格和项目计划。
2. 逻辑架构设计阶段
架构开发的逻辑架构设计阶段有两个关键步骤：
1）领域分析。对目标领域系统内部进行功能分析，分解得到分析模块，并基于问题域视角，探索系统内部，建立领域的分析模型。
2）设计逻辑架构。基于解域视角，参考分析模型，进行逻辑架构设计，构建设计模型，获得领域架构，以支持领域的质量属性需求。
逻辑架构设计阶段的阶段输入有：领域模型、系统需求规格和项目计划；阶段输出有：领域分析模型、领域逻辑架构。
3. 实现分析阶段
架构开发的实现分析阶段，主要工作内容有：
1）选择实现技术，构建实现模型，确定领域平台/CBB与产品的边界。
2）对逻辑架构及其构建块或设计模块（Deployable Module或Design Module，简称DM）进行实现分析，划分出领域内公共的核心资产（平台/CBB）、核心资产的需求规格，以及它们和产品应用件的界限。
3）获得软件/硬件等实现组件，得到领域内核心资产（平台/CBB）实现架构。
实现分析阶段的阶段输入有：领域分析模型、领域逻辑架构、项目计划；阶段输出有：领域实现模型、领域内公共核心资产、需求规格及应用边界。
4.物理架构设计阶段（可选）
企业可根据自身实际情况选择是否采纳物理架构设计阶段，后者的工作内容包括：
1）构建部署模型，获得平台及产品的物理架构。
2）规划物理构件和进程，并部署构建块（功能模块）/交互模块到物理构件和进程。
3）定义物理构件之间的物理接口，以及进程之间的并发关系。
物理架构设计阶段的阶段输入有：领域实现模型，领域内公共核心资产清单、需求规格及应用边界定义；阶段输出有：部署架构、进程架构、物理构件的物理接口定义、进程间并发关系定义。
5. 架构评估
架构开发的决策评审和技术评审主要以架构评估的形式来进行，可以从评估的内容、方法和时机等方面做详细要求。
架构评估的内容有：1）评价架构是否能够实现业务需求和质量属性需求；2）评价架构的适宜性和竞争力；3）发现架构的风险和改进点。
架构评估的方法，可借鉴“架构权衡分析法（Architecture Tradeoff Analysis Method，简称ATAM）”。企业可在ATAM分析法的基础上，结合自身实际情况做适当地调整和完善，形成符合自身需要的架构评估方法。大方向上，架构评估方法：1）要强调场景化、具体化的质量属性要求和架构方案对质量属性的实现，2）要强调获取利益相关方的观点，3）要强调对架构决策进行验证。
架构评估的时间点安排方面：1）对于新设计的架构，在完成架构设计后进行架构评估；2）对于已经存在的架构，可以在出现新领域时对现有架构进行适应性评估，或是新需求引起架构的变化或演进时，在制定架构修改方案前对现有架构进行评估。
四、构件开发
构件是平台的组成部分，是多产品（线）共用的通用能力和产品部件，面向的是多产品的通用能力需求。构件开发的流程和活动具有以下特点：
一方面，与产品开发相比，构件开发中的市场类功能任务、财务类功能任务、制造类功能任务、采购类功能任务，等等，要简单得多，或是需要做适当地裁剪。
另一方面，构件需要与其他构件一起，集成到平台或最终产品中进行产品验证。因此，构件的开发流程中，需要有一个专门的迁移阶段，用来管理构件开发成果的迁移和集成。
图4.50 构件开发流程的阶段划分和决策评审/技术评审的设置
1. 阶段划分与功能任务
构件开发的结构化流程，可分为概念、计划、开发、迁移等四个阶段，而没有单独的验证和发布阶段。其中，通过概念、计划、开发等阶段的工作，当成果输出达到成熟度要求（技术迁移标准）以后，就需要迁移给产品或平台的开发团队，以实现技术成果的快速转换。在迁移阶段的后期，主要是提供技术维护。
1）概念阶段
构件开发的概念阶段，要重点关注为所支撑的多个产品系统提供核心能力的通用需求，侧重于评估构件的技术竞争力及目标成本的达成。
概念阶段的主要工作有：A. 接收开发项目任务书；B. 组建技术开发团队/TDT；C. 确定技术开发需求，进行概念设计，确定备选概念；D. 进行概要构件模块设计和选择；E. 制定初始供应商选择计划；F. 分析市场机会以评估财务结果和风险；G. 确定所要用到的平台或技术方案；H. 制定构件的初始BOM/工程变更发布计划；I. 制定初步商业计划（重点关注对产品战略的支持）；J. 制定端到端2级项目计划；K. 重点关注和制订迁移计划；L. 组织、支持并完成技术评审TR1；M.组织、支持并完成概念决策评审CDCP。
概念阶段的阶段输出主要有：初始供应商选择计划、平台或技术选择方案、构件初步BOM/工程变更发布计划、初步商业计划、端到端2级项目计划、迁移计划，等等。
2）计划阶段
构件开发的计划阶段，重点关注从计划到迁移的项目计划，关注构件向平台或产品的迁移，以及如何提供技术支持的迁移计划。
计划阶段的主要工作有：A. 制定全球产品支持计划；B. 更新技术路标和CBB承诺；C. 完成概要设计；D. 完成技术方案设计，包括系统设计、软件设计、硬件设计、整机设计等子系统方案设计；E. 确定开发计划；F. 制定最终的供应商选择计划；G. 订购原型机所需的器件；H. 制定端到端4级项目计划；I. 制定最终版商业计划；J.组织、支持并完成技术评审TR2和TR3：K. 组织、支持并完成计划决策评审PDCP。
计划阶段的阶段输出主要有：全球产品支持计划、概要设计、技术方案设计、最终版开发计划、供应商选择计划、相关器件订购单、端到端4级项目计划、最终版商业计划，等等。
3）开发阶段
构件开发的开发阶段，要完成初始技术的开发。构件一旦通过验证，就要进行技术成果的迁移准备，并发布构件的最终规格和相关文档。期间，如果有知识产权方面的要求，还需要提交相关的标准或专利。
开发阶段的主要工作有：A. 进行构件的设计和开发（到TR4A）；B. 准备并构建原型机及其技术文档；C. 完成构件功能验证/BBFV（到TR4）；D. 完成与高一级（平台或产品）的分层集成；E. 支持完成高一级（平台或产品）的BBFV、系统设计验证/SDV；F. 支持完成产品的系统集成测试/SIT；G. 组织、支持并完成技术评审TR4/TR4A/TR5；H. 组织、支持并完成技术迁移决策评审TDCP。
开发阶段的阶段输出主要有：构件原型机及技术文档、构件功能验证/BBFV报告、签发的技术可迁移通知单，等等。
4）迁移阶段
构件开发的迁移阶段，始于可迁移决策评审TDCP的通过，终于技术生命周期结束，也就是所有使用此构件的用户产品生命周期结束。期间，需要将构件迁移给产品或平台，根据迁移计划支持各个用户开发团队TR4到GA的所有活动，保证构件有效集成到产品或平台。
迁移阶段的主要工作有：A. 正式将技术成果及相关文档迁移给用户PDT：B. 支持产品/平台的任务书开发；C. 支持平台/产品的设计与开发、系统联调、生产验证等活动；D. 解决出现的相关技术问题，直到应用此技术的产品成功上市；E. 组织开发过程中的经验教训复盘和总结；F. 组织、支持并完成项目结束的决策评审EDCP。
迁移阶段的阶段输出主要有：技术支持培训文档、技术支持的问题跟踪记录、经验教训总结报告、签发的项目关闭通知书，等等。
2. 技术评审与决策评审
构件开发流程中的技术评审有6个，分别是：1）TR1，构件包需求和概念评审；2）TR2，需求的分解、分配和规格评审；3）TR3，概要设计评审；4）TR4A，模块和BBFV验证结果评审；5）TR4A，SDV测试结果评审；5）TR5，SIT测试、性能、可靠性、环境、内部鉴定/认证、内部标杆测试、UCD和开发阶段Beta测试结果等的评审。
构件开发流程中的决策评审有4个，分别是：1）概念决策评审CDCP；2）计划决策评审PDCP；3）技术可迁移决策评审TDCP；4）项目关闭决策评审EDCP。
构件开发流程中的技术评审和决策评审，在评审流程和组织形式等方面，与产品开发流程中的技术评审和决策评审基本类似。实际上，企业应该根据构件开发的内容，对技术评审和决策评审进行适当地裁剪。比如，对于需求明确和低风险的项目，TR1可合并到TR2中。如果设计规格明确，TR1、TR2可合并到TR3中，CDCP可合并到PDCP；对于纯软件类项目，TR4A可合并到TR5。
需要特别说明的是，构件开发中的可迁移决策评审TDCP，主要是评估构件向产品或平台迁移的准备度是否达到相应的质量要求。
五、平台开发
分析完了技术开发中的架构开发和构件开发，平台开发的流程和活动就比较明确了。既然，平台是特定架构及基于此架构的一组技术构件的有机集合；那么：
1）在开发内容方面，平台开发包括架构开发，再加上一组技术构件的开发，是先完成架构的开发，再进行相关技术构件，也就是平台构件的开发。如果已经有成熟的架构，就需要根据平台构件的开发结果，对架构做适当地更新。
2）在开发流程方面，平台构件的开发流程与前文所说的构件开发流程完全类似。只不过，平台构件开发完成以后是先迁移到平台，再以平台的形式，提供给产品开发团队进行二次开发。
3）在项目组织方面，平台开发项目往往是项目群。其中，既可能包括架构开发项目，也包括一个一个的平台构件开发项目，还可能牵涉到外购CBB的采购和整合。
4）在计划安排方面，要先完成架构和平台构件的开发，再进行平台开发，然后，平台开发要在其所支持的产品开发项目的开发阶段之前完成。
5）在成果交付方面，平台开发的成果交付往往是“1+N”，是先完成架构开发（作为架构的“1”），然后在统一架构的指导和约束下，以持续迭代的方式进行增量交付——作为构件的“N”，边设计，边开发、边集成，边验证，边交付，边使用。
