一种基于业务活动驱动的软件开发方法、系统及终端

1.本发明属于软件开发领域，尤其涉及一种基于业务活动驱动的软件开发方法、系统及终端。


背景技术：

2.数字化、网络化和智能化技术应用正加速各个领域改革业务方向、提升业务信息化能力和重构业务流程等。这对特定领域的业务系统开发提出了新要求：
3.一是功能和数据共享要求增多。传统功能共享多采用开放少量指定的功能模块接口或者提供指定服务等方式实现，而数据共享则采用直接提供指定要求的数据访问视图或者通过服务实现数据交换。这两种方式对于固定的功能和数据共享有较好的支持，但难以解决领域内业务系统变化的共享需求，特别是时间相差较大和业务领域相差较大的新功能和数据共享访问需求。传统业务系统已经难以提供相关的再次开发服务支持，而不同业务系统的业务共享和数据共享无论是沟通还是技术实现都存在困难。在某些领域内，为了解决数据共享和功能共享问题，制定了技术标准和数据标准。但真正实现时，很少有人真正按照标准实现，特别是有一些标准本身存在理解和实现困难时，使业务开发企业更加不愿意按照技术标准和数据标准实施开发。
4.二是业务系统开发效率要求更高。很多领域的信息化能力已经得到了较大提高，搭建了自己的信息环境，建设了较多业务信息系统，具备了很高的信息化能力。在此基础上，新业务需求多是针对业务痛点、新业务需求和业务能力深化等方向提出的临时性业务开发需求，要求开发单位能够在较短时间内完成开发任务。软件工程领域为了实现快速开发，提出了敏捷开发概念，以降低开发的时间和经费成本。这种方法对于软件开发方的开发效率有较大提高，但对于业务方可能出现的业务流程变化、集成过去业务系统中的相同功能模块和新的数据集成共享方面都难以提供有效支持。对于发生改变的业务流程，只能通过软件开发方重构业务系统或者重新开发新业务系统以达到新需求。
5.三是降低开发成本和管理成本。随着信息化能力的提升，单位信息化系统开发和管理成本正急速增多。一方面新开发业务系统难度增加，正增加开发成本；二是业务系统共享和数据共享需求正增加集成成本；三是业务系统越多，管理成本也越多，管理的工作量也越多。因此降低单位开发成本，也成为了建设单位必须考虑的重要因素。
6.针对以上新需求，特定领域内的业务系统开发存在着开发速度快、开发成本低、集成容易和重构灵活等新要求，传统业务信息系统功能固定、接口固定和信息能力固定，业务流程固定，重构和开发效率受到软件开发公司的制约。针对新需求与传统业务信息系统之间的矛盾，研究发现依靠传统的开发方法难以获得有效解决方案。主要因为传统开发方法是以软件开发方为主角，以软件技术为核心，围绕软件开发流程组织软件开发。在此过程中，业务用户参与少、参与难，难以理解软件开发需求、软件开发设计等诸多过程中的术语和文档。业务系统部署后，业务用户将对系统功能、接口等了解不足，这种情况将随着时间的推移和后期支持服务的减少而加剧。
7.本发明立足于领域内业务系统需求共享、功能共享、架构共享和数据共享的思想，实现一个业务活动驱动的软件开发方法。本发明侧重于实现一个用户持续参与的软件需求开发方法和系统，并详细描述对后期软件开发过程的指导作用，强调用户如何了解后期软件设计的功能和接口。
8.本发明调研了过去软件需求开发方法。近几年，为了快速理解用户需求，将用户需求快速转换为系统设计，过去相继提出了用例驱动的需求获取方法、面向目标的需求获取方法以及基于场景的需求获取方法。段振华等人1提出了一种基于目标和场景的用例驱动需求获取方法，通过表格收集和挖掘用户需求，通过uml等工具将用户需求转换为用例图，实现软件系统的设计。该方法将基于目标和用例的方法结合起来使用，进一步提高需求与业务的紧密相关性。尽管这些方法都为用户需求的采集和分析提供了很好的解决方案。但是这种传统的需求采集和分析过程多是开发方主动，需求方被动，需求结果的描述多为专业开发人员设计和描述，普通用户难以理解和参与。另外，由于需求结果的描述主观性强，造成理解困难，开发效率低下，业务需求随着人员和时间的变化变得难以确定，难以避免重复开发和满足不同业务系统集成共享需求。
9.通过上述分析，现有技术存在的问题及缺陷为：
10.(1)需求开发缺乏用户持续参与。过去，软件开发方多通过用户访谈、头脑风暴、调查问卷等手段收集用户需求，这种收集过程具有时空局限性，用户无法持续参与需求采集过程，导致需求不完善或者需求描述不清晰，反复次数多，时间长，既影响开发效率，也影响产品效果。
11.(2)需求描述结构性差，客户理解困难。需求说明书是开发方在用户对需求描述的基础上，通过自身理解形成的文字、用例等。软件需求说明书往往专业性强，语言描述随意性大，而业务用户对专业描述理解困难，语言存在歧义。这些导致业务用户与开发方对需求理解存在差异，严重影响产品效果和开发效率。
12.(3)相同领域的不同业务系统需求难融通。当前，同一领域内的业务变化快，细分业务方向多，业务系统开发数量不断增长，造成功能模块重合多，这对不同业务系统共享功能模块和数据共享需求提出了更高要求。传统的需求开发过程多是开发方完成的纸质记录文件，难以阅读、查询和共享，且难以对业务需求进行明确的界定。因此，新旧业务系统的业务功能是否存在重合也难以明确界定。


技术实现要素：

13.针对现有技术存在的问题，本发明提供了一种基于业务活动驱动的软件开发方法、系统及终端。
14.本发明是这样实现的，一种基于业务活动驱动的软件开发方法，包括：
15.步骤一，保存利用半结构化自然语言三元结构描述的业务活动；
16.步骤二，生成可供绘制、修改或擦除的业务流程图场景，根据步骤一绘制业务流程图；
17.步骤三，根据所述业务活动列表和所述业务流程图，生成软件需求文档、接口文档、数据和功能共享文档。
18.进一步，所述步骤一具体过程为：
19.待开发业务信息系统的业务用户采用三元结构描述业务活动，即用单一实体(业务操作对象)加动词(业务活动动词)加单一实体(业务中被操作对象)这样的三元结构描述业务活动，其中实体可以是人、物或者系统中某一组成单元等，其中的业务活动动词是指业务流程中某一操作过程。在这个步骤中针对某一领域内的某一业务系统需求，一次增加修改或删除操作只允许一个业务用户进行，其他业务用户可以查询；同一领域内不同系统可以允许多个用户同时进行。业务活动的描述可以分层次描述，即同某一业务活动可以有子业务活动需求描述，但也必须采用三元结构描述。所有业务用户共同描述的某业务系统业务活动需求构成该业务系统的需求列表。在需求列表中，业务活动的描述不分先后。
20.进一步，所述步骤二具体过程为：
21.业务用户根据自己平时的业务处理过程，建立业务流程图，图中节点即为步骤一中的业务需求描述，图中的指针为业务过程的序列指导。如果存在可选择性过程，则为多个路径并行。如果有循环则可以增加首尾连接指针。其中每个业务流程图反映出某个业务独立的业务过程环节，具有不可中断性。在此步骤中，开发方可以与用户共同完善业务流程，还可返回到需求列表进一步完善业务需求描述。
22.进一步，所述步骤三的具体过程为：
23.利用所述业务活动和所述业务流程图构建用户需求与系统设计。开发方根据业务流程图和业务需求描述，进一步完善开发需求，对与用户进行共同确认。并在此基础上，进行功能设计和接口设计，设计的思路包括每个需求中的实体即为程序中的数据对象、每个业务流程图中的需求相当于一个独立的功能模块、每个业务流程图相当于一个服务等。
24.进一步，所述三元结构中三元包括一个动作、两个单一实体，所述结构为单一实体加单一动作加单一实体。前者所述单一实体为业务操作对象，所述动词为业务活动动词，后者所述单一实体为业务中被操作对象。
25.进一步，所述业务流程图中节点为所述步骤一中业务活动编号，图中指针为业务过程的序列指导，图中多个路径可并行，可增加首尾连接指针完成业务过程的循环。
26.本发明的另一目的在于提供一种基于业务活动驱动的软件开发系统，包括：
27.三元结构模块，用于描述业务活动；
28.业务流程模块，用于生成可供用户绘制、修改或擦除的业务流程图场景；在场景绘制时为用户提供所述业务活动记录提示等，指导用户快捷完成业务流程图绘制；检查业务流程图完整性；提供可供绘制顺序、条件和循环的方法。
29.交互模块，用于根据业务活动列表和业务流程图生成软件需求文档、接口文档、功能和数据共享文档，同时，提供外部访问接口，与软件设计相差文档、软件集成环境实现交互，使上述所描述业务活动和业务流程图能与软件实现映射关系，生成映射关系图或映射关系文档，以供开发人员和测试人员使用。
30.本发明的另一目的在于提供一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行所述基于业务活动驱动的软件开发方法的步骤。
31.本发明的另一目的在于提供一种信息数据处理终端，所述信息数据处理终端用于实现所述基于业务活动驱动的软件开发系统。
32.结合上述的技术方案和解决的技术问题，请从以下几方面分析本发明所要保护的
技术方案所具备的优点及积极效果为：
33.本发明立足于领域内业务系统需求共享、功能共享、架构共享和数据共享的思想，实现一个业务活动驱动的软件开发方法。本发明侧重于实现一个用户持续参与的软件需求开发方法和系统，并详细描述对后期软件开发过程的指导作用，强调用户如何了解后期软件设计的功能和接口。
34.本发明提供的需求开发系统使业务中的多个用户可以随时参与到业务需求的描述和业务流程的构建中，并在软件开发过程中关注需求的覆盖情况。
35.本发明提供的基于三元结构的半结构化自然语言描述，为用户和开发人员提供了一种基于自然语言的沟通语言。
36.本发明所采用的三元结构既有利于用户参与到需求的开发过程中，又有利于开发人员快速从需求中进行系统设计和模块开发，共享功能模块和数据集成，降低了开发成本，有效提升开发效率。
37.本发明的技术方案转化后的预期收益和商业价值为：本发明转换化后，能够给软件开发企业及信息系统建设单位分别带来较大经济效益和商业价值：
38.一是能够降低信息系统建设单位开发成本和管理成本。主要体现在：
①
通过功能模块共享降低开发成本。相同领域或相同单位，不同业务系统的通用功能模块重合较多，通过功能共享降低开发成本；
②
通过共享架构降低集成和维护成本。事实上，基于业务活动的软件开发强制开发使用建设单位已经存在的架构和服务支持技术，使不同业务系统更加容易集成，建设方更无需针对不同的业务系统进行维护和管理，降低了建设单位的集成和维护成本；
③
通过快速重构降低业务重构的成本。业务转换太快造成很多传统业务系统失效，利用本发明的功能共享模块和快速重构策略可以根据业务流程快速重构业务系统，降低业务系统开发投入成本，提高业务知应能力。
39.二是能够提高软件开发公司的软件开发效率。主要体现在：
①
专注于核心系统的开发。利用与现有共享功能集成的策略，可以使软件开发公司只专注于当前系统不存在的功能和业务服务；
②
提高软件开发开发效率。通过用户参与需求开发，将需求快速转换成设计的方法，软件开发公司能够减少与用户需求沟通过程，理解用户需求转换为系统设计的时间，提高软件开发效率。
40.三是本发明具有一些其他商业价值。主要体现在：
①
建设单位可以根据业务活动和业务流程检测软件开发方的系统功能实现情况；
②
软件需求可持续跟踪，建设单位可以避免较多重复开发；
③
建设方可以规范软件开发标准和行为，提高软件建设质量；
④
业务用户参与度深，为业务系统的测试和使用带来较为直接的影响。
41.总之，本发明能够降低软件开发方和建设方双方的开发成本，提高系统开发速度，实现不同业务系统的功能和数据集成和共享，具有较高的商业价值。
42.本发明的技术方案填补了国内外业内技术空白：本发明立足于业务用户的业务活动实现软件开发，改变了传统以软件开发方软件技术为核心的软件开发过程，关注以领域或者单位为整体的信息系统和数据集成与共享，对于建设单位信息化能力提升具有较大价值。
43.本发明的技术方案解决了人们一直渴望解决、但始终未能获得成功的技术难题：
44.现有技术所提供的需求采集方法缺乏用户持续参与，对于需求描述结构性差，理
解存在差异，同时相同领域的不同业务系统需求难融通。而本发明提供的基于业务活动驱动的软件开发系统，有利于将用户融入到软件开发中，也解决了当前领域内不同业务系统的系统集成和数据共享问题，既可降低开发成本，又可提高开发效率。
附图说明
45.图1是本发明实施例提供的基于业务活动驱动的软件开发方法流程图；
46.图2是本发明实施例提供的描述业务活动的三元结构；
47.图3是本发明实施例提供的描述业务流程的顺序有向图；
48.图4是本发明实施例提供的描述业务流程的分支有向图；
49.图5是本发明实施例提供的需求开发方法流程图。
具体实施方式
50.为了使本发明的目的、技术方案及优点更加清楚明白，以下结合实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
51.为了使本领域技术人员充分了解本发明如何具体实现，该部分是对权利要求技术方案进行展开说明的解释说明实施例。
52.如图1所示，本发明实施例提供的一种基于业务活动驱动的软件开发方法，包括：
53.s101，保存利用半结构化自然语言三元结构描述的业务活动；
54.s102，生成可供绘制、修改或擦除的业务流程图场景，根据s101绘制业务流程图；
55.s103，根据所述业务活动列表和所述业务流程图，生成软件需求文档、接口文档、数据和功能共享文档。
56.进一步，所述s101具体过程为：
57.待开发业务信息系统的业务用户采用三元结构描述业务活动，三元结构如图2所示，即用单一实体(业务操作对象)加动词(业务活动动词)加单一实体(业务中被操作对象)这样的三元结构描述业务活动，其中实体可以是人、物或者系统中某一组成单元等，其中的业务活动动词是指业务流程中某一操作过程。在这个步骤中针对某一领域内的某一业务系统需求，一次增加修改或删除操作只允许一个业务用户进行，其他业务用户可以查询；同一领域内不同系统可以允许多个用户同时进行。业务活动的描述可以分层次描述，即同某一业务活动可以有子业务活动需求描述，但也必须采用三元结构描述。所有业务用户共同描述的某业务系统业务活动需求构成该业务系统的需求列表。在需求列表中，业务活动的描述不分先后。
58.进一步，所述s102具体过程为：
59.业务用户根据自己平时的业务处理过程，建立业务流程图，图中节点即为步骤一中的业务需求描述，图中的指针为业务过程的序列指导。如果存在可选择性过程，则为多个路径并行。如果有循环则可以增加首尾连接指针。其中每个业务流程图反映出某个业务独立的业务过程环节，具有不可中断性。在此步骤中，开发方可以与用户共同完善业务流程，还可返回到需求列表进一步完善业务需求描述。
60.进一步，所述s103的具体过程为：
61.利用所述业务活动和所述业务流程图构建用户需求与系统设计。开发方根据业务流程图和业务需求描述，进一步完善开发需求，对与用户进行共同确认。并在此基础上，进行功能设计和接口设计，设计的思路包括每个需求中的实体即为程序中的数据对象、每个业务流程图中的需求相当于一个独立的功能模块、每个业务流程图相当于一个服务等。
62.进一步，所述业务流程图中节点为所述步骤一中业务活动编号，图中指针为业务过程的序列指导，图中多个路径可并行，可增加首尾连接指针完成业务过程的循环。
63.进一步，所述基于业务活动驱动的软件开发方法还包括：
64.于业务活动中添加子活动，所述子活动采用三元结构描述；
65.于业务活动中增加附加条件，所述附加条件可以多个，格式不限。
66.本发明实施例提供的业务活动列表如表1所示，序号要体现层次性、结构性；根据日常工作业务增加不同的业务流程图，形成不同的业务流程闭环，于工作完成停止增加业务流程图。
67.表1业务活动列表
[0068][0069][0070]
如图3所示，所述构建业务流程有序图还包括如下过程：
[0071]
业务活动列表中不存在所述业务流程需要的业务活动时，可增加业务活动，再进行描述。
[0072]
图3为业务用户描述自身的业务流程，体现出业务处理过程，流程图的序号必须是前面用户已经输入的业务需求。如果顺序结构，则按顺序通过有向箭头标识。如果是分支结构，即可能进行a业务活动，也可能进行b业务活动，则分为两个或多个路径分支，表1中的1可以按顺序为1.1、1.2、1.3，如果存在分支选择，如图4所示。
[0073]
不同业务用户输入的需求彼此之间是可见的，对于相同用语的业务需求输入时会显示模糊查询，提示用户可能存在相同的业务需求描述。
[0074]
进一步，所述基于业务活动驱动的软件开发方法还包括共享已经设计好的需求实现模块，促进不同业务系统的集成和数据共享。
[0075]
进一步，所述基于业务活动驱动的软件开发方法还包括利用人工、自动查找并标注不同业务系统或相同业务系统的业务流程有序图的异同。
[0076]
进一步，所述基于业务活动驱动的软件开发方法还包括，利用多种方法实现业务
系统构建，并在需求发生变更时，根据需求快速重构适应新需求的业务系统。
[0077]
本发明实施例还提供一种基于业务活动驱动的软件开发系统，包括：
[0078]
三元结构模块，用于描述业务活动；
[0079]
业务流程模块，用于生成可供用户绘制、修改或擦除的业务流程图场景；在场景绘制时为用户提供所述业务活动记录提示等，指导用户快捷完成业务流程图绘制；检查业务流程图完整性；提供可供绘制顺序、条件和循环的方法。
[0080]
需求实现模块，用于根据业务活动列表和业务流程图生成软件需求文档、接口文档、功能和数据共享文档，同时，提供外部访问接口，与软件设计相差文档、软件集成环境实现交互，使所述业务活动和业务流程图能与软件实现映射关系，生成映射关系图或映射关系文档，以供开发人员和测试人员使用。
[0081]
如图5所示，本发明实施例还提供了需求开发方法，具体过程如下：
[0082]
首先，业务相关用户登录系统按三元结构输入业务用户需求；
[0083]
然后，业务用户根据业务流程完成业务流程有序图；流程图的序号必须是前面用户已经输入的业务需求；
[0084]
其次，开发方与业务方统一术语，确认业务需求及业务流程；
[0085]
最后，开发方根据业务需求完成原型、功能、数据和功能共享等设计，标注需求覆盖情况；针对每个业务流程图应该提供共享服务接口，针对每个业务需求，特别是设计业务数据的需要提供共享。
[0086]
二、应用实施例。为了证明本发明的技术方案的创造性和技术价值，该部分是对权利要求技术方案进行具体产品上或相关技术上的应用实施例。
[0087]
本发明是凝练过去软件开发过程时需求开发经验的基础上，结合当前数据集成和功能集成共享的需求完成的。
[0088]
本发明促使用户通过三元结构和业务流程图描绘持续参与软件开发方的用户需求开发和系统功能开发，使用户详细了解系统的功能和需求情况，促使不同业务系统的集成与共享。本发明前期在某大学医院相关业务系统开发中采用，以此促进业务用户深度参与。使用过程中，由于本发明的需求业务系统还在开发明中，主要是开发人员通过三元结构描述用户需求，并通过用户需求绘制业务流程图，然后通过这些用户业务活动列表和业务流程图对用户的需求进一步确认，效果明显，业务用户易懂，参与感极强。
[0089]
当前，随着医院业务系统不断增多，信息处理能力增强，医院对数据集成共享和系统集成共享的需求越来越多，但却面临不同软件开发公司协调沟通困难，开发成本急剧上升等现实问题。根据这些现实问题，本发明根据业务活动和业务流程图，正着手实现无服务器(serverless)架构技术，运用函数即服务(faas)的思想，完成功能和数据的集成与共享。
[0090]
将本发明应用实施例提供的基于业务活动驱动的软件开发方法应用于信息数据处理终端，所述信息数据处理终端用于实现所述基于业务活动驱动的软件开发系统。
[0091]
应当注意，本发明的实施方式可以通过硬件、软件或者软件和硬件的结合来实现。硬件部分可以利用专用逻辑来实现；软件部分可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域的普通技术人员可以理解上述的设备和方法可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、cd或dvd-rom的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电
子信号载体的数据载体上提供了这样的代码。本发明的设备及其模块可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用由各种类型的处理器执行的软件实现，也可以由上述硬件电路和软件的结合例如固件来实现。
[0092]
三、实施例相关效果的证据。本发明实施例在研发或者使用过程中取得了一些积极效果，和现有技术相比的确具备很大的优势，下面内容结合试验过程的数据、图表等进行描述。
[0093]
本发明本发明实施例充分汲取了与用户对接需求时部分用户提供的极简用户需求描述的经验做法，提出了三元结构这一半结构化自然语言描述方法，即保证用户无需技术支撑参与需求开发，又能保证这一结构对后期开发的指导作用。这种半结构化方法的使用减少了与业务用户对接需求往返次数，提升了需求开发效率。未来，利用本发明本发明实施例方法，通过标准化注释结构或者其他方法，进一步增强需求开发与软件开发过程中的交互映射作用，发现软件需求与软件功能模块之间的映射关系，提高软件测试效率。
[0094]
本发明实施例还利用业务活动指导软件功能和数据的集成和共享，可以提高建设单位的深度参与，也提高开发单位的开发效率。并通过功能和数据的集成共享，降低双方的开发成本，提高开发效率。
[0095]
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，都应涵盖在本发明的保护范围之内。