摘要： 本文从业务领域建模的统一视角入手，重点分析了当前软件工程理论在业务需求建模中规范化工作的缺位，并从一定角度探讨了如何完整地通过相应的业务需求描述模型视角来完成业务需求的描述。
Abstract： Starting from the perspective of unity with the business model， this paper focuses on the analysis of the absence of current software engineering standardization work in the business requirement modeling， and discusses how to complete the business requirements description through corresponding business requirements description model from a certain angle.
关键词： 领域建模；规范化；应用
Key words： domain modeling；standardization；application
中图分类号：TP311.5 文献标识码：A 文章编号：1006-4311（2014）30-0234-02
1 软件工程理论的现状
软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。在现代社会中，软件应用于多个方面，一直指导着业务系统的系统开发与项目管理。
2 软件工程业务需求建模过程中的问题
虽然，目前各个行业在业务信息化方面取得了较好的成绩，但结合业务系统信息化过程管理及业务实际应用情况仍然存在如下几点问题：
2.1 全局观问题 各行各业的应用的通病都是如此：前期由于急于应付各项业务改革，各业务子系统如雨后春笋般涌现，虽然临时性满足了业务改革的需求，但终归由于缺乏全局观的指导而导致业务信息数据的割裂，无法顺利地进行数据共享。发现问题后则进行系统集成的信息共享补救工作，开发了大量的数据接口，暂时满足了现阶段的业务需求，但却无人可以将业务各子系统间的数据流转过程及子系统间如何协调完成数据处理的全过程明明白白地说清楚。如果把众多业务子系统比作是人体的“五脏六腑”，业务处理过程比作“新陈代谢”的话，我们现阶段仅仅只清楚脏腑个体内的新陈代谢，至于脏腑间如何协调完成全局的新陈代谢则很模糊。这就如同一个医生仅仅分别了解胃、小肠、大肠的功能，却不清楚“消化系统”是如何工作的一样，缺乏全局观是很致命的。
2.2 业务描述性问题 具体到各个行业业务来说，一般满足同一套业务需求的应用系统都会先后经历不同软件应用实施公司的多个版本，而每家公司都必须重复性地与各业务经办人及其业务部门进行需求调研、需求确认。在大量的业务需求调研过程中我们发现，各级业务人员、各大业务软件实施人员甚至已上线的各大子系统之间的描述业务的术语混乱，不统一而导致对业务描述的随意性给业务人员之间、软件实施人员、软件技术开发人员在业务沟通及软件实现层面带来极大的障碍，经常存在有些业务基础概念有两个名称都可以表述或两个字面意思很相近的名称描述的概念却完全是两回事的现象。因此，统一业务术语从而形成行业标准化的业务规范迫在眉睫。
2.3 技术兼容性问题 业务是靠业务术语来描述的，也正是由于业务人员的业务术语混乱导致业务需求描述没有标准，所以软件实施公司必须进行反复的需求沟通、需求确认。那么是否统一了业务术语并形成对全省业务需求描述的业务标准就一劳永逸了呢？答案是否定的。因为业务需求描述的业务标准仅仅是用规范的语言描述了业务要做什么，并没有描述业务的功能在软件中是怎么做的，只有对业务实现的技术细节进行相关程度的标准化才能让不同实施公司的同一软件产品进行兼容。还是把众多业务子系统比作是人体的“五脏六腑”，它们协调进行着人体的新陈代谢，如果要实现对“五脏六腑”的移植手术，前提必须是两人的脏腑配型成功，否则就会发生排异反应，因此脏腑配型与否是有一个衡量标准的。同理，正是通过对子系统的技术标准化实现了兼容性才能顺利地进行业务子系统的替换而不影响整体业务的运转。因而，进行技术分析并形成行业标准化的技术规范势在必行。
2.4 软件验收难问题 由于软件是个很抽象的东西，它不像大楼那样有实物，哪里是办公室，哪里是楼梯，哪里是走廊一目了然。一般人都可以走进某栋大楼看看该建筑的设计架构是否合理。软件质量到底如何，非计算机软件专业人士是无法检验的，因此软件验收一直没有一个可行的标准。再类比一下人体，人体的运作也非常复杂，而西医却有一套可行的体检指标标准来判别人体的健康与否。前面制定的业务标准和技术标准就像两把尺子，完全可以对某个业务子系统的功能性和兼容性两方面进行测量。当然，软件验收标准还要充实内容，最后制定的软件验收标准就是要跟踪软件项目，对软件合同签署、软件设计标准、软件初始化上线、软件运行维护等多个软件项目过程进行“体检”，看看软件项目是否达到预计目标从而满足验收条件。因此，形成行业标准化的业务软件验收规范也是极其重要的。
3 具体实施工作的开展
“工欲善其事，必先利其器”，光靠技术部门的力量要完成如此庞大的工程绝不是件容易的事情，必须充分、灵活地调动软件实施公司人员、相关业务部门业务骨干人员的积极性和主动性，发挥技术部门的协调组织力，以上述预定的三大业务标准为目标，保证行业业务梳理工作的顺利开展。
工作开展安排如下：
①由技术部门协调组织各家实施公司人员并协同各业务部门从当前正在上线运行的多个业务系统中的业务术语进行梳理、明确业务术语的用途，并运用规范化的业务术语来描述业务模型，包括各子系统业务流程图、跨系统全局业务流程图、流程过程中数据单据的流转细节，特别是要梳理数据单据广泛的数据勾稽关系，从而形成行业业务规范。
②由技术部门协调组织各家实施公司人员针对以上所形成的业务规范对软件底层实现制定相关程度的子系统实现及接口规范，形成行业技术规范；其中包括后台数据库表、字段名及业务意义规范、核心业务对象模型规范、核心业务处理单元规范、子系统间数据接口规范。
③最后基于上述两个规范，并对业务软件项目的合同信息、部署配置信息、运行维护信息等信息进行分析处理形成包含软件项目整个生命周期的业务软件验收标准。
4 工作总结
总之，通过上述工作的深入开展，充分发挥各行业单位中技术部门的协调组织能力、业务部门的业务主导力和软件实施公司的业务技术融合力与执行力，在软件工程方法学的指导下通过进一步完善对业务需求的领域建模及描述，更好地加强软件实施公司、业务人员、技术人员之间的协调与沟通，让各个行业的需求建模趋于方法统一化、模式统一化。
参考文献：
[1]胡阔见，魏长江.基于构件的领域工程实现[J].计算机工程与科学，2008（04）.
[2]胡慧.基于领域工程的构件的软件开发技术研究[J].电脑知识与技术，2009（33）.
[3]陈晓桦，刘心松.需求分析与获取的方法学与技术[J].计算机应用，1995（02）.