软件产品线架构设计

摘要

1、介绍行业应用软件背景，对比汽车行业和软件行业。

2、概念导入，从软件项目逐步引申到软件产品、软件产品线、软件平台、软件生产线等概念

3、管理和运营软件产品线

4、组织和构建一条软件生产线

5、提高生产力（Merge平台）

参考资料： 

1. 软件产品线设计思想。 

2. 关于平台的设计参考： 

认识大众汽车平台 https://wenku.baidu.com/view/52118fe171fe910ef12df8d8.html 

MQB、MLB、MEB 大众家的平台 http://www.pcauto.com.cn/client/782/7826488.html

3. 汽车行业PLM解决方案
https://wenku.baidu.com/view/34d86dec4afe04a1b071de90.html

 

背景

软件业相对与整车制造等传统行业属于新兴行业，发展时间相对较晚，发展的历史也相对较短，但其发展速度确一日千里，在软件行业内其的软件（操作系统、工具软件、编程语言等）和硬件的发展日新月异，这对传统行业提出了新的挑战，一方面传统行业认可其未来的发展也认识到必须与软件业相融合（即互联网+的思想），才能在未来突破瓶颈取得进一步的发展，各行业中的企业和公司都在不断的努力实施业务系统软件。而另一方面软件业的发展并没有从为传统行业服务的角度出发，同时由于发展时间较短，行业内缺少一批成熟的跨界人才，他们即在软件业是专家同时又深入了解传统行业发展特征，能够较好的实现将传统行业与软件也融合的目标。

这种情况导致的结果是实施系统软件的企业十分痛苦，往往购买了实施了10个业务模块，随着企业运营管理与系统功能的不一致性日益凸显，结果是往往是企业委曲求全以适应和有限度利用系统功能的目标，充分使用其中2-3个业务模块的功能，从而产生了大量的浪费，其中包括企业的投资成本、实施中产生的问题成本等，而这种浪费对系统提供方的软件团队（公司）来讲并不十分敏感，这个过程也可以说是客户在为团队的成长买单。

但这个过程是软件团队成熟、软件产品成型的必经之路，本文介绍的软件产品线架构设计的目标是规范和缩短这一过程，为软件研发团队由项目研发到产品研发的蜕变提出一种思路。

 

概念导入

第一步：整车产品线到软件产品线

软件业在行应用方面的发展主要是以借鉴和学习所涉及到的行业经验为主，例如软件工程的设计就是参照建筑工程过程而建立的。本文提及的软件产品线则以整车产品线的建立作为参照。

通过下面表格，快速建立从汽车产品线到软件产品线在概念方面的参照关系。

序号	整车领域概念	软件领域概念
1	整车成品 销售订单（车型+选配件）	项目交付物 客户需求（应用平台+定制组件）
2	选配件 采购方选择的可变化的配置部分，如真皮座椅、天窗、车身颜色、内饰颜色等。	定制组件 针对目标客户需求量身定制的专用组件。
3	车型设计 平台+变化件	软件产品 应用平台+标准组件
4	变化件 基于平台加入的如车身外壳等不同型号的总成、模块和零部件。	标准组件 针对行业特性设计的标准业务组件，包括预置的业务处理过程。
5	车型产品线 按照平台划分	软件产品线 按照应用平台划分
6	平台 将整车中不变的总成、模块、零部件整合为一个平台。	应用平台 系统中不变的部分：系统框架、权限管理、组件调用方式，运行环境等。

经过上面表格的整理，我们确实发现了软件产品线与整车产品线在逻辑概念方面可以建立对应的映射，由此可以证明应用整车行业产品线的管理方式进行软件产品线的管理是可行的，只要建立了合适的映射模型。

第二步：从整车生产线到软件生产线

 

整车生产线的建立是基于完成整车生产各工艺阶段的生产目标而建立的，一般分为冲压工艺（原料毛坯到车体毛坯）、焊装工艺（车体成型）、涂装工艺（车体喷漆）、总装工艺（总成装配），整车生产线造价昂贵、设计复杂，可适应针对预设的产品线进行多品种小批量的以生产订单为驱动的生产模式，其特征是生产线的设计一般是针对同平台的少数几款车型的产品线进行建立，变化相对可控，终端用户只能在设计好的几种变化件中进行选配。

反观软件产品的设计过程，往往以项目为单位，由于应用行业的没有成型的标准导致无法高效或者准确的为客户提供选配项目和标准，同时客户企业的业务任务由于缺乏计算思维无法提供准确的需求目标（客户业务人员往往在系统上线试运行期间和项目验收的前期，会爆发性的提出大量需求变更），加之研发团队在软件工程职责转换过程中导致的信息衰减，最终使得在项目实施过程中不断的出现需求偏离、设计偏离、需求细化、需求变更的事件，结果是研发团队付出超出预期30%以上的成本，并交付了高度定制化的业务组件。

相对于设计成熟、工艺完备、流水作业的整车生产线模式，软件产品的研发过程更像是纯手工操作的时代，而这即是软件生产线概念提出的驱动力

通过下面表格，提出了参照整车生产线特征，建立的软件生产线的目标。

序号	整车生产线（以总装工艺为例）	软件生产线
1	整车成品 生产订单（车型+选配件）	项目交付物 客户需求（应用平台+定制组件）
2	领料单 从库存领取生产订单产品所需的总成零部件。	业务组件需求清单 分解客户需求后的产品所需组件清单。
3	出库单 零件出库至生产线边。	组件库 选取预设的标准业务组件（具备普遍性），针对个性化需求需要开发后交付。
4	零部件装配及信息采集 在工人根据装配工序设计在目标工位完成零部件装配，并将信息记录MES系统内，作为后续追溯信息。	组件安装与配置 将业务组件安装至系统运行平台，这部分可以人工完成，也可以交由产品线架构系统完成。同时应用配置管理工具，基于MES可追溯性思想进行追溯信息管理。
5	整车质量检测 该工序由专用检测线完成，检测线系统提交整车质检单，由MES系统打印整车合格证	集成测试 一般使用测试工具完成回归测试、压力测试，辅以人工完成复杂业务流程测试。提交系统测试报告。
6	车辆发运和交付 由厂家司机将车辆运送至销售公司库房（或称成品发运库）	安装部署 由系统实施人员为客户完成系统的安装、调试、培训等工作。

 

管理和运营软件产品线

随着研发团队的发展，其运营的软件产品线将持续扩充，可以按照产品所属行业、应用平台划分为多个产品家族，每一个家族内的产品使用统一的运行平台（可能存在版本的区别），并处于相同或相似的业务领域。

每一个加入产品的发布都伴随着一系列的组织活动和交付物，整体运行架构参见下图：

产品线架构设计是基于对软件产品的认识（产品=平台+组件），结合整车生产过程中的总装装配工艺生产过程，借鉴了PLM部分思想提出的。图中的生产流向由左至右分别涉及到运行平台/组件的设计工艺、平台和组件的装配工艺、终检工艺和返修工艺，期间的在制品交付物包含运行平台、标准组件、定制组件、软件产品，整个生产过程使用MES系统中可追溯×××和配置管理，对运行平台、组件、发布的产品进行实施版本管理。

 

组织和构建一条软件生产线

软件生产线在软件产品线架构中处于核心位置，其目标是为各个工艺步骤提供了细化的说明部分，并针对生产过程存在关键问题提出解决方案。

运行平台的设计目标从支撑业务处理的底层功能入手，包括对组件的处理、组件依赖的开发工具库支撑、运行日志和监控方面的功能、系统运行授权类功能设计。

组件设计目标从对组件的管理角度入手，每一个组件信息中除了开发相关的工程代码、部署文件，还要包含版本信息，同时带有相关的需求文档、设计文档、用户手册等资源类文件，针对目标运行平台还要提供安装说明、配置说明等资料。

装配工艺的实现过程

1. 实例化运行平台（即项目环境），包括平台部署的代码、中间件、数据库等。

2. 实例化组件：

   a)      标准组件：从组件库中选取合适的组件，根据安装说明和配置说明将组件部署到运行平台上。

   b)     定制组件：遵循运行平台对组件开发的规约，结合具体的客户需求做定制化开发，并放置在定制组件库中进行管理，再部署在运行平台上。

3. 终检工艺部分应用回归测试、压力测试等工具进行系统化的测试，辅以人工完成复杂业务流程的测试，形成测试报告。

4. 返修工艺部分应用软件缺陷管理方法，平台或组件的缺陷进行修复，并通过小版本好的形式融入版本管理。

 

产品化的过程

应用软件产品线的管理方法之后，定制化交付到产品化研发的工作将从运行平台和组件库两方面进行：

1. 定制化的组件将逐步形成积累，并可以有计划的转变为标准组件。

2. 运行平台再不断的实施过程中将逐步完善。

 

再完善一下前文对产品的定位：

       更好的产品= 更完善的平台 + 更具适用性的组件

 

提高生产力

在应用软件产品线架构思想进行研发的过程中，运行平台是相对稳定的，一般情况下可以每3-6个月更新一个版本，而如何快速的开发标准组件和定制组件则成为产品线能否快速成型的关键问题。

针对这一部分我将在后续写一篇博客，专门介绍我研发的一个作品，快速开发平台Merge。

 

总结

本文参照整车生产线的工作模式提出了软件产品线架构设计，为研发领域软件的团队提出了由项目化交付转向产品化研发思路。

应用软件产品线架构进行软件产品的运营，在纯技术方面并没有不可逾越的鸿沟，难点在于将架构思想融入到团队的组织和管理过程中，并持续坚持下去。