[原创]论国内ERP产品开发模式

论国内ERP产品开发模式

[文章摘要]

随着企业信息化的快速发展，国内ERP产品供应商也越来越多，不管是外包的、OEM的还是自主研发的，一般都遵循软件开发过程的规范，就我们目前的开发环境、开发模式跟标准的开发过程还存在一定的冲突，各个阶段的工作中也存在一些问题，在此就常见的问题作一下简单例示，以做讨论。

[关键字]

需求规格、概要设计、详细设计、编码、调试、黑盒测试、白盒测试等

一、 软件需求阶段

概述：

软件设计前期的工作，通过到客户现场调研或其它各种途径搜集需求，主要完成对客户需求的确认、分析、评审等可行性研究的过程，明确什么需求可以实现、什么需求不可以实现，从而使需求文档化，形成需求规格说明文档，对所要实现的功能提出完整、准确、清晰、具体的要求，为下一步设计做准备。

主要工作：

一般需求必须要满足以下几方面要求：

l 完整性：需求必须完整，有始有终，还应包括用户需要的每一个功能细节。

l 一致性：需求必须有一致性，可以独立也可以与其它需求相关联，但不能与其它需求相矛盾。

l 现实性：对提出的需求要综合考滤，与现实的软、硬件平台相结合，不能夸大，需在现有技术的实现范围内。

l 真实性：需求必须来源于客户，真实有效，能解决客户所面临的问题，不能凭空想象。

此阶段的主要任务包括以下几个方面：

l 软件功能要求：主要是描述系统将要完成的那些大体功能及可实现性等。

l 软件性能要求：主要集中在效率方面，包括数据库的响应时间、数据准确度及耗用内存量等等。

l 运行环境方面：系统运行所必要的软件平台、硬件环境及相关接品的要求

l 系统对所需数据要求、静态或动态数据的配置等

l 条件允许的情况下，利用数据流程图软件将业务需求表达出来

l 编写软件需求规格说明书，提交评审

l 其它方面：主要包括对软件的易用性、可维护性、保密性及二次开发灵活性等方面的分析。

常见的问题：

l 需求分析人员对客户需求把握不准，很多需求都是通过市场、渠道、实施人员或其它途径反馈而来，多少有些失真，不能完全代表客户的意愿。

l 缺乏对需求的深入理解，很多软件公司都没有专门的需求分析人员，通常一人身兼数职，一般都是由开发人员来完成，开发人员除了编码外，还要完成软件设计文档的编写及对需求的把握等工作，这样就存在一个问题，开发人员往往对业务了解不是很深入，在把握需求的能力方面略显不足，可能会导致对客户需求不能深入的发掘。

l 客户需求不明确，变动较大，导致设计不稳定，改动频繁，这一方面也有客户的原因造成的，有时由于项目周期短，而客户需求又变动较大，造成相关的需求、设计文档延期，这种原因的存在也会对软件的通用性造成一定影响。

l 时间仓促，赶鸭子上架，估计大部分软件公司都存在这种情况，有时客户提出需求，由于时间紧急，只能临时抽调其它人员到客户现场调研，效果是可想而知的，会导致一系列的问题。

l 需求的积累，大部分需求还是在于平常的积累，经常会存在这种现象：开发一套新产品前，大家都在努力的收集需求，翻资料、找文档，通过各种渠道汇总，这样也只能达到临阵磨枪的效果，好的需求还是在于平常的积累，是通过日常维护过程中慢慢形成的。

l 等等

[@more@]

一、 软件设计阶段

概述：

软件需求分析完成后，根据需求规格说明书编写设计文档，软件设计总体分为两部分：概要设计和详细设计，此阶段的主要任务就是将需求规格说明文档转换为软件设计文档，将需求阶段提出的问题，一一解释，形成详细设计文档，并根据功能要求，定制相应数据结构、各种流程图等，为下一步编码做准备。

主要工作：

l 编写概要设计

l 编写详细设计

常见的问题：

l 缺少设计模板，模板作为开发规范的一种，有利于以后的开发、维护工作。也是对软件规范化的一种基本要求。

l 外界或内部因素干扰，很多软件公司都没有专门的设计人员，一般由资深开发人员兼任，包括一些大型软件公司也存在这种情况，设计和开发没有一定的界线，设计过程中有很多其它工作要做，往往打乱计划，不能按时按预期目标完成设计

l 设计人员与研发人员缺少沟通，有时设计人员太过理想化，导致设计出的产品开发语言无法实现或实现起来比较困难，而且严重影响产品的性能和效率，使开发任务无法按时完成。

l 设计文档不详细，有些需求表达不清楚，这个问题估计大部分软件公司都存在，造成这种现象的原因往往是设计和编码人员是同一人，最终代码都是自己写，所以有些东西自己清楚就可以，就懒的写出来了，这样会给以后的维护工作带来困难，工作交接时就显而易见。

l 对总体流程的把握程度不够，目前软件一般都是分模块化设计，各模块之间关系非常紧密，各业务流程之间也是紧密相联，所以在设计某一个功能或某一个模块时要综合考滤，不仅考滤功能，也要考滤与其它业务模块的接口问题

l 数据结构的定制，数据结构是整个软件系统的骨骼，所有业务的处理都围绕数据结构进行，数据结构合不合理对软件以后的维护和可扩展起重要的作用，所以定制数据结构也要综合全面考滤，对于核心的表要加强评审。

l 设计文档评审的重要性，评审工作是编码前的最后一关，但往往都忽略了这一点的重要性，做产品不全是研发部门的责任，与每个人都紧密相关，评审一般都存在这样的问题：新产品设计期间，大家都关注的比较少，只是几个写设计的人员在忙，等到评审的时候临时召集大家会议交流，大部分还是凭经验，有些深层的东西还是无法评论，导致新产品出来后无法达到预期目标，所以这段期间的交流非常重要，将设计的思想灌输到每个参与者中，达到信息共享的目的。

l 信息共享度比较差，也是一个比较重要的问题，这一点在整个软件周期的每个阶段都很重要，尤其是设计阶段，设计阶段是整个系统框架的搭建时期，与开发、维护及实施人员以后的工作都密切相关，最重要的就是考滤全面，如能及时达到信息共享，就会从各方面收集好的建议或意见，但现实中却存在很多问题，设计人员闷头做设计，很少与外界沟通，信息达不到共享，使开发人员编码时无法完全理解需求、使维护人员在后续的维护中比较吃力、使实施人员在与客户交流中遇到障碍等等。

l 等等

二、 软件开发阶段

概述：

软件设计完成，形成设计文档后，开发人员根据设计要求一一实现，并将各部分功能有机结合起来，形成最终软件产品。

主要工作：

l 将设计文档转化为程序源代码

l 对完成的功能进行单元测试、系统自测等

l 界面的美观及易用性设计

l 性能及效率优化

常见的问题：

l 对设计把握不准，理解程度不够，这一点与上一阶段提到的信息共享有很大关系，一般设计人员将详细设计完成后交由开发人员编码，对于复杂的功能如果开发人员前期不参与，那么实现起来可能会遇到困难，或与设计的思路有误差，所以前期与开发人员的沟通也很重要。

l 只懂语言不懂业务，不能很好的按业务逻辑编码，这也是普遍存在的现象，ERP软件比较注重业务，业务比较复杂也灵活，这就要求开发人员除要掌握开发语言外，还要熟悉所开发模块的业务流程，这样才能开发出高质量的代码。

l 只懂语言不懂数据库，这里说的数据库不一定要达到很熟悉，只需要了解基本的语法即可，这关系到软件的性能及效率问题，众所周知，ERP软件每一个功能基本上都跟数据库打交道，最基本的就是查询，如果SQL优化不好，就会导致效率非常低，业务处理也同理。

l 代码冗余，同一个功能实现方式有多种，不同的写法效率可能不同，所以在开发或维护过程中不能求快，要讲求方法，争取达到最优。

l 缺少对自写代码的测试，这一点也许是开发人员的通病，很少仔细检查自己写的代码或测试自己写的程序，一般都感觉没问题，这是不好的习惯，对自己写的代码要认真检查、严格测试。

l 软件的性能效率问题，这是每个软件产品都面临的问题，也是都存在的问题，客户经常抱怨“单据半天保存不上，查询半天出不来结果”，这些大部分还是代码的优化问题，包括数据库语法的优化等。

l 没有固定的开发规范或不按照开发规范执行，每个软件公司都有自己的一套开发规范，包括对象的命名、字体的设置、控件的大小等等，开发人员须按照此开发规范严格执行，才能达到界面统一的目的，但我们往往发现一些软件产品中存在这样的问题，各模块间同类功能的界面风格都不一样，这些都属于低级错误。

l 易用性的问题，随着软件功能越来越强大，客户对软件的易用性要求也越来越高，对开发和设计人员的要求也越来越高，不仅要考滤软件功能的实现，也要考滤软件的易用性。

l 代码文档化，主要体现在注释上，每个开发人员编码的思维不一样，对于一些复杂的代码很难一眼就看懂，这种现象也比较常见，往往几百行代码没有一条注释，维护起来非常困难，也很容易出错，所以在编码过程中要养成写注释的好习惯，将代码文档化，便以后期的维护与修改，提倡每个对象都应有自己的readme,介绍此对象的作用及内部每个函数、事件等的含义。

l 代码检查岗位，又称代码走查，主要负责对开发人员编写的代码进行检查，一般由资深开发人员专门负责或兼任，对软件的质量起非常大的作用，很多软件公司都没有这个岗位。

l 代码公用化，这一点比较重要，也是不断积累的过程，每个软件公司都有自己的公用库，对于一些常用的功能，可封装为公用程序，降低代码冗余度，也便于后期的维护。

l 等等

三、 软件测试阶段

概述：

当产品开发完成后需要提交测试部门做测试，软件测试的目的就是为了发现程序中的错误，测试的对象不仅仅是程序测试，还应该包括整个软件开发期内各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序。

主要工作：

软件测试的主要工作是验证和确认

l 验证：保证软件能否正确地实现一些特定功的能，确定软件生存周期中的一个特定阶段的产品是否达到前阶段确立的需求的过程。

l 确认：通过执行程序或人工分析功能判断软件是否存在问题。

测试类型有很多种，按开发过程的阶段可分为：单元测试、集成测试、确认测试、验收测试、系统测试，按实现角度可分为：黑盒测试、白盒测试等。

常见的问题：

l 开发、维护人员缺少自测，自测比较重要，每完成一个功能都要进行单元测试和系统测试

l 测试人员对业务理解不够，新产品提交测试后，需要经过一段时间的测试才能交付使用，如果测试人员对业务不了解，需要边熟悉产品边熟悉业务，就不能从深层次发现问题，只能达到黑盒测试的效果。

l 提前准备不足，产品测试周期一般不会太长，所以前期准备工作非常重要，怎样在开始测试就进入状态比较重要，前期准备工作主要包括业务知识培训、测试方法、重点测试功能等。

l 白盒测试的力度不够，测试人员对软件结构不了解，很少能从内部发现问题，“错误潜伏在角落里，聚集在边界上”，而白盒测试更可能发现它。

l 编制测试用例不全面，测试用例主要是快速、全面的测试并发现问题，所以定制一个好的测试用例非常重要，也可以利用一些测试工具辅助测试。

l 性能效率方面也是重点测试的对象，尽量将这种问题提前发现，不要等产品交付使用后让客户提出来。

l 等等

四、 软件维护阶段

概述：

软件维护是整个软件生命周期中比较重要的一个阶段，软件测试无误通过后，形成完整的软件产品交付客户使用，在使用过程中软件的原有功能和性能不能满足客户需求或软件发现错误需要修改等原因，需要对软件进行一系列的维护工作。

主要工作：

维护工作一般分为以下几种类型：

l 改正性维护：软件在使用过程中出现功能性错误，需要修改代码来处理

l 适应性维护：由于信息技术的发展，软、硬件平台更新较快，为适应这些变化所做的修改。

l 完善性维护：主要是针对使用过程中客户提出的需求及性能要求的维护

l 预防性维护：对下一步可预见的问题的维护。

整个维护过程一般由客户提出修改需求或性能要求，由设计或开发人员对需求评审，判断问题是否需要修改，并确定修改内容及影响范围，然后修改程序并测试修改部分及结合相关业务系统测试，编写维护文档或二次开发文档，最终交付客户使用。

常见的问题：

l 维护人员对客户需求的把握程度，维护的过程也是软件稳定的过程，维护人员对软件的稳定起着重要的作用，如果不能准确的把握客户需求，在对软件做修改时就力不从心，修改完的软件或新增的功能与客户提出的需求不符，这在现实中也是存在的，这样不仅做无用功，还影响软件的稳定性，所以在收到反馈的需求后，首先判断需求的通用性，如不通用直接否决掉，如通用则分析工作量视情况维护产品。

l 维护人员对所维护功能的熟悉程度，这也是影响软件稳定性的很重要的一方面，很多软件公司对软件维护不太重视，认为只要保证软件不出问题就可以，软件维护工作的任务重，时间紧，要达到快速、准确的处理问题，如果对功能不熟悉，效果可想而知。

l 修改问题认真、细心程度，不能修改一个问题带来好几个问题，软件问题的来源有很多种，有些是原来测试没有发现的，有些是外界因素造成的，还有一部分是维护人员在维护过程中修改引起的，这一点与维护人员的工作态度有很大关系，有时稍不注意就会引起其它问题，当然与上面提到的不熟悉软件功能也有关系，要尽量避免。

l 没有软件维护制度，软件的维护也需要一套完整的制度来遵守，问题应该有统一入口、统一出口，维护过程中我们经常会遇到这样的问题：客户或实施人员把一个问题同时反馈给好几个人，如果沟通不及时，就会造成工作重复，所以有时还是有必要按一定的制度去执行。

l 软件的二次开发，在维护过程中难避会遇到二次开发的问题，这非常不利于软件的稳定，软件每做一次二次开发基本上都会形成一个版本，影响补丁包的发放，也会加大后期维护的工作量。

l 另外在维护阶段电话、MSN、QQ、SKYPE等交流工具虽然经常用到，但也是影响工作效率的重要因素，对维护人员来讲还是尽量少用。

l 等等

[结束语]

总之，各阶段存在的问题都会影响工作效率，导致软件问题多、不稳定，所有问题归根到底最终还是人的问题，整个研发队伍就是一个团队，团队间最重要的就是沟通、协作，如何提高工作效率是我们共同追求的目标，找出最优的工作方法，改正工作中的不足，这样才能开发出高效的软件，“发展国产ERP，努力打造国产ERP软件的一片天空”也是我们一直追求和奋斗的目标。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/128503/viewspace-909955/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/128503/viewspace-909955/