`
yongtree
  • 浏览: 234591 次
  • 性别: Icon_minigender_1
  • 来自: 青岛
社区版块
存档分类
最新评论

开始设计开发ERP了

阅读更多

      去年下半年紧张的开发已经过去了,现在终于可以让自己歇一歇了。回首去年的一个过程,充满了挑战,充满了艰辛,也从中找到工作的乐趣,收获很多。上半年的工作流现在已经越来越多的在集团中使用了,甚是欣慰。下半年主持并设计开发了部门的软件实验室平台,第一阶段的开发工作已经结束,在不久就要正式上线了,域名是:http://www.po-soft.com,希望借此能在网上发展起一个虚拟的项目开发团队,并作为整个部门与外界沟通的平台。一年的辛勤工作换回来的是快速的成长,在部门里异军突起成为中坚力量,并得到集团颁发的“技术创新奖”,感谢所有人。
      荣誉代表过去,机会永在未来。新的一年,新的生活,新的挑战,如果说去年是在软件设计上小试身手的话,今年将在软件架构,大系统开发大展拳脚。忙里偷闲在看几本书《Effective Java》,《编程匠艺》,强力推荐这两本书,对每个从事软件开发的人来说,这两本书绝对提升你软件开发的质量。借此自己也策划写一个系列的文章《编程的美感》,希望讨论分享编程的艺术(已经发布了三篇,在http://yongtree.iteye.com上)。有时,没事也读读《庄子》,道家思想其实能非常好的指导软件系统的设计。
      回到题目,今年要开始设计并开发ERP了。最近学习了一些财务方面的知识,的确对于我这样的技术人员,学习这么专业的业务知识的确是一件头大的事情。同时,作为一个较大的ERP系统,除了了解相关的业务知识之外,基础平台的设计开发,整个系统架构的设计以及基于EJB的分布式实现,都是摆在我面前的一座座大山。作为自己自愿承担下来的任务,许多人也许不了理解,这不是自讨苦吃吗?那我为什么要开发ERP系统,我想说一下自己的一些看法。
      公司是一个医药集团,而集团IT部门是集团特别看重的,也是以后要大力发展的,信息化也是我们一直要坚持的。作为医药行业的背景,做医药行业的解决方案和产品,这才是我们未来的出路。我作为java开发人员,毕业一年多来大大小小做过几个项目了,除公司的电子商务平台(http://www.baiyjk.com),都是一些自己应用的小项目,虽然技术水平在不断的提高,但是沉淀下的东西不多。我希望自己做一些中、大项目,并能成为核心人员,只有这样才能提高自己的软件开发水平,才能为自己积累下一些东西。公司的现有的ERP系统M1,是一个非常好用的ERP平台,架构在C/S结构之上,是基于数据库的开发模式,由于现代软件的发展和基于数据库开发的局限性,M1面临着变革。由此开展的M2(对M1的改进)的设计和开发,已成为我们未来几年也重点做的工作。新的ERP将采用新的开发模式及架构,B/S结构、组件化、分布式,最大程度的满足医药行业的解决方案。部门人少,工作繁杂,但是终归需要投入人力来从事这项工作,年终的时候向领导表达了自己的想法,也得到领导的支持,终于这座大山向我压下来。我希望,通过自己辛勤的劳动,设计开发出这样一个系统,也希望通过这个系统,改变自己人生的轨迹,体现自己的价值,向着更高的目标迈进。
      该ERP平台采用EJB的组件化开发模式,基于B/S的多客户端的系统,开发过程艰巨而又漫长。对于该系统的开发,我的初步设想是:技术架构方面,以JBoss Seam为核心框架架构,以JBoss服务器作为EJB容器,客户端以JSF为主,可采用AJAX(EXTJS),Flex等多种客户端表现方式。第一个功能模块选择业务比较固定的财务系统,首要设计开发统一的基础组件,如组织机构,权限系统,日志系统,工作流系统等等,其次合理使用本地和远程SessionBean和MessageDrivenBean来整合各模块。在设计上尽量多的使用UML建模,以流程图,状态图和类图为主翻译和描述业务系统。并在项目中制定出适合自己的各种规范。具体的项目蓝图及开发过程将在以后的博客中进行介绍,或者访问http://www.po-soft.com/project/oecp/,加入我们的团队。
      接下来的路,任重而道远,加油。

5
0
分享到:
评论
10 楼 yongtree 2009-08-20  
treblesoftware 写道
EJB+JSF+Ajax+Flex,不清楚为什么找这样的一个架购方案,请赐教。

我认为使用Hibernate+Spring的数据持久+业务服务层架构是最为合理的,当然,如果涉及分布,那么可以加入EJB3。

多谢这位朋友的回复。这个项目其实对于我们来说,是在摸索的前进,现在的想法和当初的想法有了稍微的改变。EJB+JSF+Ajax+Flex,这不是要采用的架构方案。我们现在专注于EJB业务组件的开发,发布EJB业务组件是我们未来主要任务。我们也希望通过构建一个社区去繁荣更多的业务组件。至于客户端采用什么技术不是我们的重点,但是是我们自己的实现。现在在客户端我们采用了Seam(JSF,ajax4j,richfaces)。考虑Flex,并不是大面积的使用它,而是在工作流程和业务流程中,作为图形化流程设计器的解决方案。当然,如果有更好的解决方案,我们也会采用。但EJB业务组件这个核心不会变。
9 楼 treblesoftware 2009-08-19  
EJB+JSF+Ajax+Flex,不清楚为什么找这样的一个架购方案,请赐教。

我认为使用Hibernate+Spring的数据持久+业务服务层架构是最为合理的,当然,如果涉及分布,那么可以加入EJB3。
8 楼 yongtree 2009-03-07  
WiseNeuron 写道

我不清楚什么叫"直接操作数据库的开发模式"。 我觉得楼主有一个很有魄力的人,但是,你忘了一个现实,你们现有的ERP平台它是已经在使用了一段时间的系统,你很难将它完全替代的,原因很简单,里面的数据迁移如何安全的迁移到你新的系统中来? 相信这个风险你很难承担,你的集团领导也很难承担。只要设计原有系统的数据,你迁移时就必须研究它的关系,这是一个难点。 另外,如果你要避开这个数据迁移,有一个办法,就是让你的新系统使用原来的数据库和关系,然后扩展,但这就必然让你新的ERP的设计多少收到旧系统的束缚。 所以,完全推倒旧系统这种方案还是慎重考虑,我做了几年的开发,不管是日本还是国内,都是通过扩展旧系统来升级的,还没遇到过将旧的推翻重来的。

这位朋友说的很好,前期我在业务关系上还是采用现有的数据库,并做相应的扩展。而我们真正要做的是一个比前一个系统更加合理的系统,业务模块更多,系统架构更强,更能体现出医药行业的一些标准,我们把下一个系统做成医药行业的解决方案,而不仅仅是为了满足我们的需要,至于老系统,如果新系统能够更好的解决问题,我们会考虑慢慢过度的。
7 楼 zzq230 2009-03-06  
ERP是拿钱砸出来的
6 楼 WiseNeuron 2009-03-06  
我不清楚什么叫"直接操作数据库的开发模式"。 我觉得楼主有一个很有魄力的人,但是,你忘了一个现实,你们现有的ERP平台它是已经在使用了一段时间的系统,你很难将它完全替代的,原因很简单,里面的数据迁移如何安全的迁移到你新的系统中来? 相信这个风险你很难承担,你的集团领导也很难承担。只要设计原有系统的数据,你迁移时就必须研究它的关系,这是一个难点。 另外,如果你要避开这个数据迁移,有一个办法,就是让你的新系统使用原来的数据库和关系,然后扩展,但这就必然让你新的ERP的设计多少收到旧系统的束缚。 所以,完全推倒旧系统这种方案还是慎重考虑,我做了几年的开发,不管是日本还是国内,都是通过扩展旧系统来升级的,还没遇到过将旧的推翻重来的。
5 楼 sofar1218 2009-03-06  
可以看看openbravo
4 楼 yongtree 2009-03-05  
liujunsong 写道

这就是我对你那个系统开发的第一个问题:对于业务理解不理解,理解业务需要多大难度,业务究竟有多复杂,你们项目考虑过没有? 

我们处于企业的环境中,业务部门就是我们调研的对象,由于我们有长期做ERP的经验,也培养出一批即懂技术有懂业务的人才,同时公司早期开发过ERP,这方面应该不成问题。
liujunsong 写道

好了,既然现在有一套ERP系统,而且觉得不错,非常好用.
为什么不考虑在现有系统上增加扩展功能,继续发挥它的力量,非要推倒重来呢?

那个系统不是成品,而是在我们企业平台上进行开发的,我们的ERP平台即是ERP运行平台又是开发平台,但是直接操作数据库的开发模式,带来的不好的地方就是难以维护,需求一点小小的变化,带来的是动一处而动全身的改动。这样的系统已经不能满足现在需求的迅速变化,而采取面向对象,面向组件的开发模式,可以让我们的系统的重用性、维护性和扩展性都有质的提高。
liujunsong 写道

再说说你们系统用的这么多新技术,很多现在还在演化中,并不成熟.
而且你们是否有这么多的人力来研究这些东西,解决存在的技术问题呢?
-------------------------------------------------
我感觉你对于项目未来存在的风险,几乎是一无所知,自己在盲目乐观.

并不是说我们要广泛应用这些技术,每个系统也不可能是只有一种技术组成,那个系统没有AJAX,工作流用flex架构也是一种解决方案,技术总归要服务于解决问题的。EJB的确存在着很大的缺点,使用的人不是非常多,但是他是一种规范,一种标准,只要在java领域,标准永远不会垮掉的,即使偶尔的萎靡不振给其他开源框架一些机会,但是标准终归是要扛大旗的,spring现在不是也在向标准靠拢吗?EJB3的强势推出不是看到标准改进的力量了吗?同时JBoss Seam也逐渐的扛起企业开发的大旗,现在虽然不成熟,谁能保证它以后不会一统天下呢。前一个ERP我们用了5年多的时间,现在的ERP我们依然计划5年,有集团的支持,资金不是太大的问题,我们需要的就是专心去搞这样一个东西,5年后的事情谁也说不清楚,我们只有努力去做了。

对于您提供的这些建议,我们都会认真考虑,我也经常夜不能寐,因为做这样的系统的确是有非常大的困难,特别是对于我这样没有大项目经验的人来说,现在从事的的确有点超出能力范围了,但是对于我自己又必须走出这一步,这样自己才有进步的机会,才能达成系统架构的个人理想。
3 楼 liujunsong 2009-03-05  
我曾经参与过两个大型集团公司的财务系统开发和维护工作,亲手写出一行行代码.
自己感觉对于财务软件的开发维护,还是颇有心得的.
也曾经和国内最知名的财务软件ERP公司合作,看过他们开发的系统.
先不说ERP的业务范围有多大了,就仅仅限制在一个财务系统领域上,财务的业务复杂程度也是超过一般计算机开发人员想象的,可以肯定的说,如果没有在财务软件领域工作过三年以上,要想从业务方面理解财务软件本身都是很困难的事情.
不说计算机人员了,就光说财务人员吧,一个真正得力的财务工作人员,也是需要很多年的工作实践才能锻炼出来的.
------------------------------------------------------------------
这就是我对你那个系统开发的第一个问题:对于业务理解不理解,理解业务需要多大难度,业务究竟有多复杂,你们项目考虑过没有?
抛开业务的复杂性不谈,接下来说说技术方面的东西.
原文中谈到:
引用
公司的现有的ERP系统M1,是一个非常好用的ERP平台,架构在C/S结构之上,是基于数据库的开发模式,由于现代软件的发展和基于数据库开发的局限性,M1面临着变革。

好了,既然现在有一套ERP系统,而且觉得不错,非常好用.
为什么不考虑在现有系统上增加扩展功能,继续发挥它的力量,非要推倒重来呢?
基于数据库的开发模式,难道新的系统不用数据库不成?
你要想一想,原来那套系统,也并不是一次成型的,也是经过了开发,修改,升级多次反复,最后才好不容易稳定下来,开始发挥作用.
而现在一切要推倒重来,何必呢?
以你们现在新选择的架构,原来的程序估计全得扔掉重写,花这么多钱,真的能够达到目的吗?
我看肯定不行.
先说用户界面这部分,C/S的程序界面是非常灵活的,元素众多,而且在一个页面上可以做很多事情,也可以把数据缓存到本地文件中,减少和后台的数据交互过程;B/S呢,在用户界面上是一大退步,尤其在企业信息系统领域.界面单调不说,原来一个界面能干的事情,现在得分至少4个界面来做.
就我个人的经验,同样规模的系统,原来C/S开发,有1个主程序员,3个帮手就能干的工作,现在至少要3倍的人力,而且做出来的东西很难看,很难用.
C/S开发之所以块,一是因为可视化,直观,二是因为有强大的控件支持.而对于B/S来说,这两者都是没有的.
--------------------------------------------------
至于EJB技术,更是JB中的JB,除了使用更多的人力来解决就业问题外,几乎一无是处.
--------------------------------------------------
如果你们真的要大干一场,我建议你们先去调研一下市场上同行的产品都是怎么做的,
基于那种技术架构.
数据表大概有多少,
程序大概写了多少,
然后在系统开发之前,给自己的系统一个最基本的估计:
数据表: 多少张
应用程序: 多少类,多少行
以现有的人力开发效率,大概一个人月平均能写 多少行
以此估计,大概需要多长时间: ....
如果你估算的结果是:
代码: 10万行
开发效率: 1000行/人月-2000行/人月()
那么结论就是: 需要100-50个人月才能完成.
再加上调研,需求,测试,修改的时间.
我真不知道你们这系统能否做的完.
-------------------------------------------------
再说说你们系统用的这么多新技术,很多现在还在演化中,并不成熟.
而且你们是否有这么多的人力来研究这些东西,解决存在的技术问题呢?
-------------------------------------------------
我感觉你对于项目未来存在的风险,几乎是一无所知,自己在盲目乐观.
-------------------------------------------------
语言可能有所冒犯,请见谅.
2 楼 yongtree 2009-03-04  
liujunsong 写道

不知道你们公司出于啥考虑, 居然选择了这样一个技术架构 EJB+JSF+Ajax+Flex 这些技术中的任何一个,都可能导致项目的失败 加在一块儿,只能使项目更加复杂. 这样的项目,成功的机会很渺茫

以EJB为核心构建ERP组件,这是我们坚持要做的,至于其他的,是我的一种想法,可能想法比较幼稚,希望能指点一二。技术架构以JBoss Seam为主,ERP是一个方面,最终形成的可能是ERP的开发和运行平台。
1 楼 liujunsong 2009-03-04  
不知道你们公司出于啥考虑,
居然选择了这样一个技术架构
EJB+JSF+Ajax+Flex
这些技术中的任何一个,都可能导致项目的失败
加在一块儿,只能使项目更加复杂.
这样的项目,成功的机会很渺茫

相关推荐

Global site tag (gtag.js) - Google Analytics