企业ERP系统开发总结及建议

企业ERP系统开发总结及建议

作者:成晓旭

对于像我们这种规模的大型公司,自己建设、实施和维护满足公司特定管理要求的管理信息系统,是目前部分大型公司建设企业ERP的常见思路。比如:XXXX、XXXX、XXXX、XXXX等等知名企业。


其实:这种ERP系统建设方式,我本人并不看好和推荐:社会分工进一步精细化的今天,让更专业的团队去做更专业的事情是大势所趋。然而,既然公司采用这种方式建设自己的综合信息管理系统,本着把事情做好、让公司放心的原则,让来年更有效的为公司综合信息管理系统提供支撑,结团队一年来的开发、维护工作、提出几点浅见:


1加强相似业务流程、管理模式的抽象与提炼,通过系统分析与设计、并编码实现成我们自己的基础架构源码库。下面用简单的源码统计工具,针对今年开发上线的新、旧两个版本的XX系统,进行代码行数统计分析情况:


通过重新开发系统基础架构,减少系统代码量,相信就能极大地降低系统后期的测试、调试、维护、升级的复杂度和工作量。


2注重新建子系统、功能模块、业务构件、甚至是最简单的一个新单元、新类的重新分析、设计和实现。针对目前整个系统的在新运行情况和日常的维护工作量,我们不大可能有充足的人力和时间,来整体重新构建各个在线的子系统。但新业务需求的实现时有发生。既然是新增功能、新写代码,我们更有理由摒弃原来不太好的开发方式和思路,采用一些更专业、更成熟软件开发模式与架构,至少让新增的功能块从上线开始,就有较好的稳定性、较高的可复用度、较强的可扩展性。坚持这样,才能逐渐、逐渐地提升整个软件系统的内部质量特性、才能逐渐、逐渐地减少系统的维护工作量;否则,随着软件代码量的日益增加、系统功能的日益复杂、业务需求的频繁变化,已建系统对新需求变动的满足难度势必越来越大:“雪球效应”很可能发生在系统支撑小组,导致系统支撑小组最终很难再继续有效地支撑下去。


3为支撑小组的软件开发、维护工作选择适合的软件开发方法论,并结合具体工作实践进行裁剪或增补。根据团队实际工作情况的引入更合适的软件开发方法,将极大改善开发团队的工作效率、提升交付软件产品的内外品质:已是不容质疑的事实。传统的软件开发方法、信息化软件开发方法、统一软件开发方法,都不太适合我们公司系统这种“应用需求变动频繁、支撑资源配置紧张”的现状。

建议采用敏捷软件开发方法的原则与模式:

1.准确把握公司生产管理及运营需求;

2,适度设计并保持设计的灵活性;

3.简单开发以满足当前需求;

4.频繁重构与迭代保持系统当初的设计原则;

5.测试驱动开发和加强单元测试从最底层开始确保系统的健壮性。


4在公司系统的开发、维护、支撑过程中,建议一定要坚持系统建设初期的分析、设计、编码原则,至少最起码的基线原则必须坚持。进公司几个月来,听到、看到太多的、很好的原则在现实面前妥协的情况。表面上看,我们的妥协当时是缩短了开发时间、提高响应公司领导决策、或者财务、人力、总经办等部门经理的管理要求;其实,事后我们往往为违背这些原则付出了更大的代价。众所周知,任何项目系统的建设,在人力、时间、质量等方面都是受限制并且相互制约的。软件系统的经典的设计模式与原则也是人所共知的,最终软件产品的质量在很大程度上,就取决于开发团队在软件构建过程中,对原则的坚持力度与执行力度上。


6加强系统测试、尤其是开发初期的单元测试。在系统开发、维护工作中,很多次发现这样的现象:运行很久的程序功能突然发生一个异常,通过跟踪代码,错误居然被定位很基本的指针保护或逻辑错误上,而这些错误极易在单元测试中被覆盖、发现和解决,相反,在系统后期的组件测试、集成测试、回归测试、系统测试阶段较难再现。这类问题还反应了我们原来的测试用例的代码覆盖率不高。

为新的一年能够更加有效地响应公司发展战略规范、支撑企业信息化战略的落地与实施,对支撑团队来年的系统工作提出几点要求,概况如下:

1.准确把握公司信息化的当前需求但不求全责备;

2.采用经典、成熟的设计原则与模式但不过渡设计;

3.尽量用简单的编码来实现当前功能;

4.通过频繁的重构来坚持期初的设计和实现原则;

5.维护和新增功能前尽可能先重构再重用、杜绝通过“代码复制”实现相似的系统功能;

6.加强单元测试,保证系统构件的可靠性与健壮性、将软件BUG的大部分解决在单元开发期间。

最后分享个人的以前做项目的经验:“用精巧、优雅的设计来应对需求的瞬息万变;用重构与迭代来维持良好的系统体系架构;注重单元测试保障系统内部、外部品质”。

你可能感兴趣的:(设计模式,测试)