前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >系统架构师论文-论软件产品线技术

系统架构师论文-论软件产品线技术

作者头像
cwl_java
发布2019-10-26 20:50:41
6490
发布2019-10-26 20:50:41
举报
文章被收录于专栏:cwl_Javacwl_Java

论软件产品线技术

[摘要]

本人在测井行业的一个国有企业软件开发部工作,从2002年初开始,我陆续参加了多个测井软件开发项目,这些项目都是测井行业资料处理解释软件,具有很强的行业特征,其开发方向和应用范围都非常相似,从“测井资料处理集成软件"项目,开始我实施了软件产品线技术,虽然在开始阶段,由于经验不足和管理不善,遇到了一些问题,但是随着逐歩实施,都得到的纠正和有效控制,目前这几个软件项目都非常顺利的完成,实施工期明显缩短, 极大的提高了产品质量,本文就在这些项目中为什么实施软件产品线?在实施过程中遇到哪些问题?产品线开发支持工具选用情况和产品线实施带来的益处等进行论述,并分析总结在目前本单位产品线技术应用中存在的不足。

[正文]

本人在测井行业的一个国有企业软件开发部工作,在近几年来内,我陆续参加了几个的软件开发,2002年初参加“测井资料处理集成软件"项目,此项目的目的是集成本单位重点实验室研究成形的测井资料处理方法,提供一体化的应用,服务于各个测井公司,我负责底层平台设计和开发,2003年初参加“阵列感应实时分析软件"项目,主要针対单位自行研制测井仪器-阵列感应仪器MIT的现场资料实时处理,总体负责软件的设计和实现;2003年中, 参加国家级项目“山地地震和矢量地震勘探研究"的“成像勘探开发处理软件"子项目,本项目的目的是实现国内勘探解释方法和仪器的大整合,“成像勘探开发处理软件"子项目完成成像勘探部分的软件开发,我负责成像勘探部分软件架构设计和分析实现;2004年初,参与总公司科技局“测井综合应用平台"项目,性质与“测井资料处理集成软件"类似,但集成范围扩大到整个测井行业,我参与了总体架构组,并完全负责底层平台的设计。 这几个项目都是测井行业资料处理解释软件,具有很强的行业特征,其开发方向和应用范围都非常相似。几个项目表现了很多共性特征,如数据录入接口方面,都采用测井行业标准的数据格式CIF、LIS和E等;数据表现方面,采用图件可视化方式;数据管理方面,除了第二个实时解释项目采用文件系统外,其他均采用数据库存储,使用测井国际化标准组织P0SC的EPICentry规范,不仅如此,处理流程也大致相似,首先获取数据、进行数据转换,按照用户指定的方法进行资料处理,然后以形象化的方式反馈给用户一些处理特征,进行处理结果输出,各种资料归档等。除了这些共性外,几个项目也表现了一些个性特征,如“阵列感应实时分析软件"要求的实时性比较高,性能要求较高,采用文件系统,“测井资料处理集成软件"项目用于实验室方法集成,分析功能和研究性质略强于其他三个项目等,虽然存在个性,但是我认为几个项目更多地表现为一致性。 在这几个项目中我都实施了软件产品线技术。主要康因有以下几个: 1.本部门长期承接测井行业软件开发,开发范围清晰,且容易界定,在多个连续的项目中,存在一些共性开发。在早期项目中,由于构架和开发接口不统一,造成重复开发的弊端,实施产品线可以有效节省人力、物力和财力。 2.测井行业目前出现的软件都是层次架构,80%采用C/S模式,主要应用在测井资料处理上,其余采用B/S模式或者两种组合方式进行简单数据咨询和处理结果显示,有利于产品线架构设计。 3.由于行业特点,开发的软件很难适合所有的测井公司,而多数情况是量身定做,因此同一个项目可能出现多种软件版本,如华北油田专版,重点挂接生产测井解释功能,而长庆油田対斜井校正等方法较为重视,采用软件产品线可以方便解决这些问题。 4.同时,测井行业中,方法的更新较快,但是一般的软件使用的方法都相同,如“测井资料处理集成软件"项目目和“测井综合应用平台"项目使用同样的软件处理方法和图件绘制方式(测井行业特征,方法永远采用最新的),一旦解释方法和绘制方式改变,所有的软件要求能统一改变。 我在接手“测井资料处理集成软件"项目后,与其他开发人员向单位建议了软件产品线的开发技术,得到同意并开始实施。由于是新项目开始,而且软件规模不算很大,因此,我们直接采用了革命的方式,项目直接实施全新的软件产品线方式,我将团队分为两路,一路总结分析旧项目的软件,一路进行当前项目的分析界定,同时聘请行业专家和技术专家结合本项目从大局进行规划,首先进行行业分析,対行业分析结果与单位的规划进行整合,最后在形成的领域架构基础上进行当前系统的需求分析和设计界定,其中开发重点在核心资源库上,然后当前项目的软件直接复用资源库上的产品线构架和构件。 这几个项目完成后,本单位的核心资源库得到了丰富和充实,由这几个项目直接构成的核心资源包括两套产品线架构,分别适用于测井资料处理和测井资料检索管理两种开发类型;数据格式转换构件组,能够进行十几种测井原始数据进行转换和录入;测井图件绘制构件组,数据按照四十多种图形方式显示在通用的桌面系统、浏览器,并能以位图、矢量元文件、SVG和CGM进行输出;还有文件系统和数据库操作标准和一些商业构件库和中间件等。 几个项目完成的非常顺利,除了第一个项目的出现短暂延期外,其他项目大幅度缩短了开发周期,而且软件维护和版本升级非常方便,但在实施过程中我们也遇到了一些问题: 1.在第一个项目实施期间,经验不足,人员分工与过程组织不合理,核心构件与应用系统开发混淆,导致了开发设计的反反复复,延迟工期。 2.部分核心资源设计不合理,某些构件在老项目方便使用,但没有充分考虑新项目的特点,在新项目无法充分利用,如果直接修改冲突构件满足新项目,老项目的维护和更新又无法与新项目配套,在一段时间内存在同时维护多套多版本构件的情况。 3.资源管理不利,因为产品线实施需要非常强大的构件管理和配置管理,我的四个项目针対不同油田的应用每个项目都生成了多个软件产品,维护还包括了核心资源维护和应用系统维护,实施前期经常出现管理不善带来的负面影响。 到目前,我们逐歩解决了这些不利情况,主要是加强人才培训、资源管理和组织管理。在资源管理上,我们主要通过自动化工具来解决。目前支持产品线的工具不多,大多是构件的管理和组装工具,在系统分析设计和建模方面一直采用Rational的ROSE,软件配貫管理采用CVS,核心资源管理方面从初始的利用CVS转变到北大青鸟的公共软件构件库管理系统,它是采用了 B/S的多层体系结构,分布式的应用架构,基于EJB技术,具备较强的灵活性和扩 充性,支持刻面分类等多种分类模式,并提供基于角色的用户管理机制,使系统具有灵活的权限分配和安全的控制方式。在选择这些工具的选择上最重要的是核心资源管理工具选择,因为其他工具相対成熟且熟悉,而核心资源库是产品线最重要的部分,并须能进行统一的管理和识别,如关键词分类、枚举分类和刻面分类方法等,因此我们选择了北大青鸟的公共软件构件库管理系统来进行核心资源库的维护,它不仅满足上述要求,而且完全支持UDDIV2.0 标准规范,而且支持构件统一、描述、发现和集成。 产品线技术在本单位不断扩充与发展,到目前为止,形成了采集、通讯、解释处理等多方面的产品线架构和构件库,利用这些资源,可以方便快速地“组装"一个测井实用软件系统。通过实施软件产品线,本单位测井软件的开发模式逐渐规范,不同项目复用同一个或多个产品线架构,做到组件复用的最大化,实施工期明显缩短,极大的提高了产品开发过程和产品质量。虽然有了几年的技术和资源积累,我认为在本单位的产品线开发上还存在一些不 足,如在领域工程方面,缺乏具备深厚行业经验的领域分析人员,需要在不断的实践培养过程中,辅以本行业外部专家的咨询和辅导;在核心资源方面,缺乏高效的管理,虽然使用了较为方便的构件管理工具和其他辅助工具,但是其智能化欠缺,不是很成熟,同时构件的组装上,还是采用人工代码方式,缺少智能组装工具应用;还有就是管理和过程方面,传统单兵作战思想影响依然深远,国有企业开发人员或多或少有一定技术封闭性,不利于核心资源 积累,而且向团队开发和多部门协同开发转变存在一个阶段,需要更好的管理和更多时间的磨合。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2019-10-12 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 论软件产品线技术
    • [摘要]
      • [正文]
      相关产品与服务
      消息队列 TDMQ
      消息队列 TDMQ (Tencent Distributed Message Queue)是腾讯基于 Apache Pulsar 自研的一个云原生消息中间件系列,其中包含兼容Pulsar、RabbitMQ、RocketMQ 等协议的消息队列子产品,得益于其底层计算与存储分离的架构,TDMQ 具备良好的弹性伸缩以及故障恢复能力。
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档