软件产品线架构设计

摘要

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。

总结

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

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

时间: 2024-10-01 20:28:17

软件产品线架构设计的相关文章

架构设计:系统间通信(34)——被神化的ESB(上)

1.概述 从本篇文章开始,我们将花一到两篇的篇幅介绍ESB(企业服务总线)技术的基本概念,为读者们理清多个和ESB技术有关名词.我们还将在其中为读者阐述什么情况下应该使用ESB技术.接下来,为了加深读者对ESB技术的直观理解,我们将利用Apache Camel一起搭建一个ESB技术的服务实现,虽然这个示例不能把目前主流的ESB服务实现中所有功能模块都保罗进来,但至少可以让读者看到ESB技术核心服务完整的工作方式. 2.为什么需要ESB 2-1.ESB与SOA 2-1-1.SOA SOA(Serv

架构设计:系统存储(8)——MySQL数据库性能优化(4)

================================ (接上文<架构设计:系统存储(7)--MySQL数据库性能优化(3)>) 4-3.InnoDB中的锁 虽然锁机制是InnoDB引擎中为了保证事务性而自然存在的,在索引.表结构.配置参数一定的前提下,InnoDB引擎加锁过程是一样的,所以理论上来说也就不存在"锁机制能够提升性能"这样的说法.但如果技术人员不理解InnoDB中的锁机制或者混乱.错误的索引定义和同样混乱的SQL写操作语句共同作用,那么导致死锁出现的

web架构设计经验分享(转)

本人作为一位web工程师,着眼最多之处莫过于 性能与架构,本次幸得参与sd2.0大会,得以与同行广泛交流,于此二方面,有些心得,不敢独享,与众博友分享,本文是这次参会与众同撩交流的心得,有兴趣者可以查看视频 架构设计的几个心得: 一,不要过设计:never over design 这是一个常常被提及的话题,但是只要想想你的架构里有多少功能是根本没有用到,或者最后废弃的,就能明白其重要性了,初涉架构设计,往往倾向于设计大而化一的架构,希望设计出具有无比扩展性,能适应一切需求的增加架构,web开发领

当前一种先进实用的架构设计

目录 1系统架构图...1 2架构设计...3 2.1项目开发环境...3 2.2运行环境要求:...3 2.3 服务器架构平台:...4 2.4.架构逻辑设计...5 2.4.1 LVS+KEEPLIVED+SQUID+HAPROXY+JBOSS集群...5 2.4.2mysql集群...6 2.4.3fastdfs图片服务器集群...8 2.4.4acveMQ服务器集群...8 3 架构剖析...10 3.1负载均衡器解析...10 3.2 lvs解析...11 3.3keeplived解析

浅谈12306 核心模型设计思路和架构设计

春节期间,无意中看到一篇文章,文章中讲到12306的业务复杂度远远比淘宝天猫这种电商网站要复杂.后来自己想想,也确实如此.所以,很想挑战一下12306这个系统的核心领域模型的设计.一般的电商网站,购买都是基于商品的概念,每个商品有一定量的库存,用户的购买行为是针对商品的.当用户发起购买行为时,系统只需要生成订单并对用户要购买的商品减库存即可.但是,12306就不是那么简单了,具体复杂在哪里,我下面会进一步分析. 另外一个让我写这篇文章的原因,是我发现也许是否是因为目前12306的核心领域模型设计

架构设计:系统间通信(33)——其他消息中间件及场景应用(下3)

=================================== (接上文:<架构设计:系统间通信(32)--其他消息中间件及场景应用(下2)>) 5-7.解决方案三:非侵入式方案 以上两种方案中为了让业务系统能够集成日志采集功能,我们或多或少需要在业务系统端编写一些代码.虽然通过一些代码结构的设计,可以减少甚至完全隔离这些代码和业务代码的耦合度,但是毕竟需要业务开发团队花费精力对这些代码进行维护,业务系统部署时业务对这些代码的配置信息做相应的调整. 这里我们再为读者介绍一种非侵入式的日

SOA架构设计经验分享—架构、职责、数据一致性

阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DDD+GRASP进行分析和设计(防止主观的判断导致错误的假设) 5.SOA分布式下的数据一致性 5.1.分布式事务(基于DTC的分布式事务) 5.2.事务补偿(提供正向或反向的操作来让数据在业务上是一致的) 5.3.异步EDA(基于异步事件流来实现柔性的分布式事务) 6.总结 1.背景介绍 最近一段时

软件系统的架构设计

软件系统架构(Software Architecture)是关于软件系统的结构.行为.属性.组成要素及其之间交互关系的高级抽象.任何软件开发项目,都会经历需求获取.系统分析.系统设计.编码研发.系统运维等常规阶段,软件系统架构设计就位于系统分析和系统设计之间.做好软件系统架构,可以为软件系统提供稳定可靠的体系结构支撑平台,还可以支持最大粒度的软件复用,降低开发运维成本.如何做好软件系统的架构设计呢?笔者就这一问题做如下探讨分析. 软件系统架构设计方法步骤 基于体系架构的软件设计模型把软件过程划分

[转]SOA架构设计经验分享&mdash;架构、职责、数据一致性

阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DDD+GRASP进行分析和设计(防止主观的判断导致错误的假设) 5.SOA分布式下的数据一致性 5.1.分布式事务(基于DTC的分布式事务) 5.2.事务补偿(提供正向或反向的操作来让数据在业务上是一致的) 5.3.异步EDA(基于异步事件流来实现柔性的分布式事务) 6.总结 1.背景介绍 最近一段时