一种应用软件全生命周期数字化开发方法与流程

1.本发明涉及应用软件开发领域，尤其涉及一种应用软件全生命周期数字化开发方法。


背景技术：

2.随着计算机技术的发展，信息化、智能化技术在企业的运用越来越广泛和深入，但应用软件的开发过程却基本处于手工作业方式，缺乏支撑应用软件各阶段的信息化平台，部分针对某阶段的平台相互间又是独立的，无法贯通，各阶段之间只能通过文档衔接，文档需要人去理解，导致两个阶段之间的过程效率低下，理解的偏差会导致差错的和谬误，这些差错向下一个阶段传递和放大，当测试阶段发现问题再向前追溯时会造成更大的成本和工期增加；软件工程各阶段之间鸿沟导致软件工程的整体效能难以大幅度提升。
3.应用系统就是用计算机做业务，因此业务需求是应用系统最关键的阶段，业务需求如何提出、如何表达，业务需求的一致性、精确性如何保证，如果需求不在这个阶段精确化，那在什么时候修正，依据什么修正，这些问题一直没有彻底解决，如此含混的进入软件需求阶段，实际上就进入了解决方案层，偏离了业务这个根本。业务需求由于缺乏精准表达业务的方法和手段，业务需求就势必存在含混、不一致等缺陷，这些问题向下一阶段蔓延，会导致更大的混乱和差错。没有精准的业务需求，软件需求失去了根本、迷失了方向，只能以功能为抓手，以完成业务操作为目的，失去了业务系统以制度操控的灵活性和可持续的发展能力。面向功能的设计是机械的、技术的围绕功能实现而设计，尽管从专业的技术视角遵从高内聚、低耦合等设计原则，缺少了业务的指引，难以克服功能之间的混乱耦合和功能错落重叠，使应用系统失去了业务领域原本具备的随制度而变的柔性和发展能力，导致系统僵硬和难于适应发展变化、维护成本高、生命周期短。因此如何将制度数字化并引入到应用系统之中是亟待解决的关键问题。
4.开发阶段可用的工具和平台是很多的，有代码编辑调试的、界面开发的、数据库开发的，种类繁多，但相互独立，难于协同，数据标准规范难于在各平台之间统一贯彻。
5.软件过程是一个复杂的工程，目前的项目管理软件亦是独立的，与开发过程是分裂的，没有与软件开发过程融为一体，项目信息需要通过人工录入获取，不仅增加项目工作量，而且存在信息不及时、不准确等问题。从目前应用软件过程的现状来分析，问题在于各阶段没有贯通的方法和技术，尽管在每个阶段都有工具和平台支撑，相互之间无法贯通，只能通过文档衔接，无法逾越两个阶段之间的鸿沟，需要手工作业来拟合，因此就难以从整体上大幅度提高应用软件的生产效率和质量。另一方面，由于没有精确表达业务需求的方法，以软件需求为起点、以功能为导向的设计开发，使传统的软件工程构建的应用系统成为一个僵硬的业务处理系统，而不是一个依据制度运行的柔性业务执行系统。


技术实现要素：

6.本发明提供一种应用软件全生命周期数字化开发方法，以克服上述技术问题。
7.一种应用软件全生命周期数字化开发方法，包括，
8.s1、获取企业的业务架构，所述业务架构包括架构对象以及相应的架构关系，其中架构对象为企业的机构、部门、岗位、业务事项、业务制度，架构关系包括一个企业包含一个或多个机构，一个机构包含一个或多个部门，一个部门包含一个或多个岗位，一个岗位对应一个或多个业务事项，业务事项包括一个或多个业务过程和业务操作，业务制度用于表示业务过程和业务操作之间的逻辑关系，业务过程是执行一个或多个业务操作的逻辑过程，通过业务描述语言对业务事项和业务制度进行数字化定义并生成可执行的数字化脚本；
9.s2、构建业务执行引擎，其用于对可执行的数字化脚本进行解析并执行，包括判断可执行的数字化脚本的类型，若数字化脚本的类型为流程，则解析数字化脚本并执行流程，若数字化脚本的类型为过程，则解析数字化脚本并执行过程；
10.s3、根据执行后的数字化业务需求确定开发应用软件的软件需求，软件需求包括多个具体描述单元，具体描述单元包括一个或多个业务需求；
11.s4、根据软件需求进行设计开发，包括设计数据库、数据对象，根据软件需求所对应的业务需求生成代码框架，开发人员根据软件需求所对应的业务需求编写代码；
12.s5、对开发的应用软件进行测试和部署。
13.优选地，所述通过业务描述语言对业务事项和业务制度进行数字化定义并生成可执行的数字化脚本包括：获取业务事项和业务制度所使用的元素，对元素进行数字化定义，根据业务描述语言中的业务事项语言对业务事项进行数字化定义，根据业务描述语言中的业务过程语言对业务过程进行数字化定义，根据业务描述语言中的业务操作语言对业务操作进行数字化定义，根据数字化定义后的业务事项、业务过程、业务操作对业务制度进行数字化定义，将数字化定义后的元素、业务事项、业务过程、业务操作、业务制度生成数字化脚本。
14.优选地，所述根据业务描述语言中的业务事项语言对业务事项进行数字化定义是指获取与业务事项对应的业务制度和岗位，根据业务制度所表示的业务过程和业务操作之间的逻辑关系，按流程次序定义各岗位执行的业务过程或业务操作，包括业务过程或业务操作相互之间的逻辑关系、流转、并发、汇集的流程约束。
15.优选地，所述根据业务描述语言中的业务过程语言对业务过程进行数字化定义是指获取与业务过程对应的业务制度，根据业务制度所表示的业务操作之间的逻辑关系，按流程次序定义业务操作，包括业务过程的处理逻辑、执行条件、执行次序。
16.优选地，所述根据业务描述语言中的业务操作语言对业务操作进行数字化定义是指确定业务操作的输入参数、入参合规检查、操作步骤和逻辑、输出参数、出参合规检查，并生成源代码框架。
17.一种应用软件全生命周期数字化开发技术平台，其特征在于，包括业务架构定义模块、业务执行引擎模块、软件需求定义模块、设计开发模块、软件测试部署模块，
18.业务架构定义模块，其用于获取企业的业务架构，所述业务架构包括架构对象以及相应的架构关系，其中架构对象为企业的机构、部门、岗位、业务事项、业务制度，架构关系包括一个企业包含一个或多个机构，一个机构包含一个或多个部门，一个部门包含一个或多个岗位，一个岗位对应一个或多个业务事项，业务事项包括一个或多个业务过程和业务操作，业务制度用于表示业务过程和业务操作之间的逻辑关系，业务过程是执行一个或
多个业务操作的逻辑过程，通过业务描述语言对业务事项和业务制度进行数字化定义并生成可执行的数字化脚本；
19.业务执行引擎模块，其用于对可执行的数字化脚本进行解析并执行，包括判断可执行的数字化脚本的类型，若数字化脚本的类型为流程，则解析数字化脚本并执行流程，若数字化脚本的类型为过程，则解析数字化脚本并执行过程；
20.软件需求定义模块，根据执行后的数字化业务需求确定开发应用软件的软件需求，软件需求包括多个具体描述单元，具体描述单元包括一个或多个业务需求；
21.设计开发模块，根据软件需求进行设计开发，包括设计数据库、数据对象，根据软件需求所对应的业务需求生成代码框架，开发人员根据软件需求所对应的业务需求编写代码；
22.软件测试部署模块，其用于对开发的应用软件进行测试和部署。
23.本发明提供一种应用软件全生命周期数字化开发方法，通过对业务事项、业务制度数字化，将数字化后的业务事项、业务制度贯彻软件工程各阶段，从整体上大幅度提高应用软件的生产效率，同时基于软件过程构建依据数字化业务制度执行的应用系统，可以通过应用系统对业务制度进行调整、优化，提高了应用系统随需而变的能力，不断满足日益增长的业务需求。
附图说明
24.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图做一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
25.图1是本发明方法流程图；
26.图2是本发明在业务需求阶段工作方法的示意图；
27.图3是本发明软件需求阶段工作示意图；
28.图4是本发明设计开发阶段工作示意图；
29.图5是本发明单元测试工作过程的流程图；
30.图6是本发明功能测试工作过程的流程图。
具体实施方式
31.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
32.图1为本发明方法流程图，如图1所示，本实施例的方法可以包括：
33.s1、获取企业的业务架构，所述业务架构包括架构对象以及相应的架构关系，其中架构对象为企业的机构、部门、岗位、业务事项、业务制度，架构关系包括一个企业包含一个或多个机构，一个机构包含一个或多个部门，一个部门包含一个或多个岗位，一个岗位对应一个或多个业务事项，业务事项包括一个或多个业务过程和业务操作，业务制度用于表示
业务过程和业务操作之间的逻辑关系，业务过程是执行一个或多个业务操作的逻辑过程，通过业务描述语言对业务事项和业务制度进行数字化定义并生成可执行的数字化脚本；
34.业务架构是按机构、部门、岗位、业务事项梳理出来的层级关系是业务需求的基础，业务需求的核心内容是通过业务描述语言对各具体业务事项进行精准的数字化定义，如图2所示。业务架构梳理主要包括如下内容：企业的组织架构、各业务部门的岗位及岗位职责、各岗位包含的业务事项、按类收集业务名词、动词。这个分类是按照业务域来做的，取决于具体业务。这部分工作仅需要了解业务事项处理过程中都会涉及到哪些岗位、哪些过程和操作，并为它们起一个妥帖的名字，按照业务域进行分类归集即可，目的是为后续使用业务描述语言详细描述业务事项时有一个共同的业务语义基础。业务域是指按照业务归属或业务执行过程进行归类的一组业务。机构、岗位、过程、操作、业务名词等都会成为后续需求定义的元数据，可以保障需求表达的一致性，避免重复和差错，提高后续各项工作的效率。
35.根据企业业务架构，对企业各相关业务事项通过业务描述语言，对业务事项的处理过程和制度进行数字化的精准描述，企业在开展业务的过程中，业务事项可能由客户触发，也可能由内部触发(例如盘点库存、统计报表)，也可能由外部关联机构或系统触发，因此这里统一称之为业务事项。业务制度是指做具体的事项时候所依据的企业业务流程、规则、约束条件等，它是由一个个的业务过程、业务操作、算法按照规则逻辑组合在一起的。业务操作是指记录、变更、删除业务状态的行为，称之为操作，有时也称为作业，业务过程通常对应一项专业的业务制度，往往是一个或多个业务操作的逻辑组合。
36.根据每个业务事项，参照业务制度，找相关岗位的业务人员，按照业务描述语言的语法要求详细的描述处理步骤。同时对过程和操作分别用业务过程语言和业务操作语言进行定义，这样形成对每个业务过程和业务操作的数字化定义。业务过程和业务操作的数字化定义是业务事项描述的重要基础，它们会被各种业务事项共享，随着需求的展开，这些业务过程和业务操作的数字化定义会逐步完备趋于稳定。
37.业务描述语言用于清晰、一致地描述业务事项的形式化语言的统称。它由三个子语言组成。
38.业务事项语言(bml):用于清晰、一致的定义业务事项的形式化语言。业务事项通常是一个流程，由不同岗位执行某些业务过程或业务操作完成一个业务事项的处理。它退化的情况可以是一个过程或一个简单是业务操作。它是针对这个业务事项的制度定义，与后面两个语言结合，可以精准的定义数字化的企业制度。
39.业务过程语言(bpl):用于清晰、一致的定义业务过程的形式化语言。它通常是一个简单的过程，需要依据具体的业务制度，通过几个业务操作的逻辑组合完成。它配合bml，定义各业务事项共享的细粒度的具体业务制度。
40.业务操作语言(bol):用于清晰、一致的定义业务操作逻辑的形式化语言。操作是业务事项的基础动作，涉及专业的业务知识，例如如何记账、管理产品、管理客户以及合约等。
41.通过业务描述语言对业务事项和业务制度进行数字化定义并生成数字化脚本包括获取业务事项和业务制度所使用的元素，对元素进行数字化定义，所述元素包括但不限于问题、目标、机构、部门、岗位、职责、领域词汇、业务分类、业务逻辑、用户界面、系统接口、
数据类型、结构、查询、报表、参数、权限、响应时间、吞吐能力、动态容量、静态容量；
42.所述根据业务描述语言中的业务事项语言对业务事项进行数字化定义是指获取与业务事项对应的业务制度和岗位，根据业务制度所表示的业务过程和业务操作之间的逻辑关系，按流程次序定义各岗位执行的业务过程或业务操作，包括业务过程或业务操作相互之间的逻辑关系、流转、并发、汇集等流程约束。
43.所述根据业务描述语言中的业务过程语言对业务过程进行数字化定义是指用业务过程语言定义一个专业的业务处理过程，它对应着一个专项的业务处理制度，它通常是一个或多个业务操作的逻辑组合，可以被多个业务事项共享使用，通过业务过程语言数字化定义业务过程的处理逻辑、执行条件、执行次序等。
44.所述根据业务描述语言中的业务操作语言对业务操作进行数字化定义是指依据业务规定对一个具体的业务操作进行逻辑定义，确定该业务操作的输入参数、入参合规检查、操作步骤和逻辑、输出参数、出参合规检查等；业务操作是企业业务处理的底层逻辑，它会被业务过程和业务事项共享使用，是业务处理过程中的细微逻辑，本操作语言仅定义该项业务操作的输入输出参数和用形式化化语言定义其处理的逻辑过程，并据此，生成具体操作程序的源代码框架，具体代码需在开发阶段编码实现。如前所述这部分涉及业务处理的细微逻辑，又是系统中相对稳定的部分，建议通过程序代码实现，但不排除后续版本通过业务操作语言解释执行或自动化生成代码。
45.根据数字化定义后的业务事项、业务过程、业务操作对业务制度进行数字化定义，包括业务事项、业务过程、业务操作之间的逻辑关系、并发、汇集等顺序。
46.通过对各类业务事项的研究，经过综合分析、抽象构建了业务事项处理过程的基本形态：
47.某岗位执行(xx操作/过程)
48.如果(金额》x){
49.某岗位执行过程(xx操作/过程)}
50.否则{
51.某岗位执行(xx操作/过程)}
52.……
53.xx过程对应专业岗位的专业过程，采用业务过程语言进行表达。它通常是企业某部门内处理某项具体业务的制度。
54.xx操作对应的是具体的业务操作行为，采用业务操作语言进行表达。它们通常是企业某部门内业务人员的具体业务操作行为，它们是与具体业务无关的，用于完成业务事项的底层业务逻辑。
55.s2、构建业务执行引擎，其用于对数字化脚本进行解析并执行，包括判断数字化脚本的类型，若数字化脚本的类型为流程，则解析数字化脚本并执行流程，若数字化脚本的类型为过程，则解析数字化脚本并执行相应过程；
56.业务执行引擎是对业务描述语言解析执行的执行器，它将使用业务描述语言描述业务事项、业务制度，通过业务驱动引擎实现制度的自动化执行，从而实现所需即所得，而在传统需求分析最后输出的是文档，开发人员通过阅读文档来编码实现业务系统，理解的偏差或交流的偏差会导致最终结果与期望有差异，本实施例让业务人员能够参与到需求中
来，实际业务执行过程使用业务描述语言对业务和制度进行数字化定义，应用系统则依据数字化需求智能化执行业务处理过程；在可视化的业务描述语言支持下，业务人员可以方便灵活的进行需求创新和业务创新，新的业务编辑完成后，通过测试、审批后即可发布运行，使企业能够以最快的速度、最低的成本实现业务创新，不断的满足市场和客户的最新需求。
57.由业务执行引擎完成业务事项的具体处理，使业务处理的主体逻辑通过业务描述语言完成，不需要编码实现，最大程度降低代码开发量，实现企业业务架构的流程层和过程层的全数字化驱动，同时配合开发平台的ui配置工具，可以实现所需即所得，构建业务人员可以轻松驾驭的数字化智能应用系统，使业务与技术良好解耦，业务创新和需求创新与应用系统无关，业务描述语言可以完整表达业务创新、需求创新和制度创新，零编码即可部署到应用系统运行，这种应用系统就是一个懂得业务描述语言的智能业务处理系统。
58.s3、将执行后的数字化脚本作为数字化业务需求，根据数字化的业务需求确定开发应用软件的软件需求，获取执行后的流程脚本，根据流程脚本对应用架构、平台架构、技术架构、硬件架构等给出数字化需求定义，同时根据流程需求划分多个具体描述单元，每个具体描述单元包括一个或多个过程需求，获取执行后的过程脚本，根据过程脚本对系统的功能需求进行定义，功能需求包括确定分析数据需求，制定系统数据标准，再构建用户交互页面、服务交互接口，以及与其他系统间的交互接口。如图3所示，左侧描述功能性需求，功能性需求描述完成后，目标系统的界面可以呈现在用户面前，配合运行平台，一个可运行的准应用系统可以提供业务部门进行审核，使系统评审前移，将问题在需求阶段暴露和解决。右侧是依据业务需求阶段的目标要求展开的非功能性需求，主要涉及系统性能、处理能力、安全等方面进行详细描述，各相关项有标准化模板，以便于各项非功能性描述的精确性和可测量。
59.本阶段完成后，业务系统各业务事项的制度级逻辑已经被精确定义，可以形成业务事项的运行脚本由平台的业务执行引擎驱动执行，各类接口包括ui均已完成，无需设计开发，设计阶段的工作得到了高度简化，主要集中在具体数据存储和基础操作模块(基础服务)的设计工作；自动化文档生成系统可以输出符合项目管理标准要求的《软件需求说明书》。
60.依据用户现实生产过程中存在的问题以及期望系统为其解决哪些问题而提出的目标和要求，通过对问题及目标的层层分解，得出每一个具体目标。以此来做为系统是否达成目标的验收依据。系统目标包括功能性目标与非功能性目标。
61.其中，功能性目标为：从功能视角提出的目标，包括系统需向哪些用户提供哪些具体的功能，以及实现的方式要求；这些目标会被一个或多个业务事项的需求覆盖。
62.非功能性目标为：针对系统的吞吐量、响应时间、可用性、可伸缩性、可拓展性、可维护性、多语言支持等提出具体的量化指标。
63.依据业务需求，对数据类型、数据元、数据字典、代码、参数、数据对象等进行描述表达，实现元数据层面的标准化、数字化管理和运用。
64.数据类型：对应用系统所涉及到的数据类型(数字、数值、字符、日期)进行统一管理。
65.数据元：依赖数据类型，是对数据类型进一步抽象，标准化其长度及小数位。
66.数据字典：依赖数据元，是系统的数据基础。数据字典是系统中所有基础数据概念的集合，例如：个人存款账户中的18位账号，代表在账户体系下账号这一完整的基础业务元素。
67.代码：数据元素有多种类型(例如：性别、证件类型等)，描述出其代码值(例如：0代表女性，1代表男性)。
68.数据对象：表示一类业务数据元素的集合。这部分工作主要标准化每个元素的命名、类型、长度。同时确定数据对象之间的关系。例如：描述个人存款账户信息，需包括账户名、账号、开户行、余额等元素信息。
69.首先明确事项用于完成哪个业务目标，其次在业务需求基础上完善业务事项表达。先确定业务事项输入元素，完善输入元素在业务操作步骤中的数据交互及处理，最后得出事项的输出元素。对业务操作、算法的输入输出进行详细描述，同时对其内部逻辑进行概要说明，描述以目标为驱动，首先明确作业、算法的预期目标并基于描述详细说明其实现步骤，此为开发编码的重要依据。
70.通过平台可视化页面定义工具，设计系统的用户交互界面。确定页面与业务事项的交互关系(页面中的操作元素，例如：按钮、表格等与业务事项进行关联)，至此目标系统的界面可以呈现在用户面前，页面与服务间的交互也建立起来。
71.架构规划是系统非功能性目标为依据，对应用架构、平台架构、技术架构、硬件架构等给出规划。
72.应用架构：组织架构中的部门已经将微系统的划分界定清楚。具体确定了业务领域主要的业务模块及结构。
73.平台架构：是应用系统的技术支撑体系，满足应用系统的技术需求，如服务调度、数据访问、消息、缓存等等。
74.技术架构：从扩展性、灵活性、安全性等方面进行规划，本实施例的技术平台apos(application operating system)承接这部分需求的主体功能，为应用系统提供统一通用的能力和技术支撑，例如：安全体系、组织架构、用户管理、权限控制、服务调度、一致性管理、文件传输、加解密、消息、缓存、数据访问、日志、公告等。平台能够支持灵活选配，可完全不用，把开发环境指向企业既有的技术环境即可，可部分使用，亦可全部使用。
75.硬件架构：根据吞吐量、响应时间等非功能性要求，结合实际环境要求给出系统的硬件、网络架构。
76.s4、根据软件需求进行设计开发，包括设计数据库、数据对象、api接口等，根据软件需求所对应的业务需求生成代码框架，开发人员根据软件需求所对应的业务需求编写代码；如图4所示，左侧为服务端接口、数据库设计、基础操作、算法的工作步骤；右侧为系统架构设计步骤，在设计开发领域，以需求为指引，以数字化、可视化设计平台为基础，来构建系统。进入到设计开发阶段，前面的所需即所得已经完成了软件工程的许多重要工作，此阶段工作量已经降到了最低。
77.设计工作主要需要完成业务账簿信息化的存储结构(设计数据库表)。开发工作主要集中于底层基础业务逻辑和前端界面的特殊业务控制方面的设计。平台完成从需求到设计开发、测试的全过程管理，各阶段的产物均在平台中数字化存储，可自动的生成各阶段的标准文档如：业务需求说明书、软件需求说明书、设计说明书、操作手册、运维手册、业务制
度、业务操作说明书等。
78.数据库设计属于设计开发阶段，使用平台定义数据库表结构，使用数据标准(数据类型、数据元、数据字典)来标准化元素的名称、类型、长度信息。数据库表定义完成后，可执行生成建表语句并链接目标库执行。
79.基础业务逻辑来源于业务操作，平台根据软需中业务操作的描述生成代码模板，开发人员依据业务操作的具体描述完成逻辑代码编写。
80.系统界面在软需阶段已经完成，设计开发阶段在此基础上完成业务逻辑控制代码编写即可。例如：转账业务中，转账金额必须大于0，且不能超过账户余额等业务规则控制逻辑。
81.s5、对开发的应用软件进行测试和部署。测试的过程可以一般地分解为“分析－实施”两个大的阶段，测试管理平台将依此主要划分为测试分析、测试实施、缺陷管理三大板块，图5为测试过程，在测试过程中，提高测试质量的关键是测试需求分析，提高测试效率的关键是测试流程和方式的设计和优化。任何业务都可以表达为流程、规则和要素。如果把一个业务的流程、规则和要素加以适当的形式化表达，就可以得到测试分析得以展开的可靠基点。由此把功能测试划分为业务级、流程级、要素级三个级别的测试。
82.业务级：业务级测试完全面向业务功能、业务制度开展测试分析活动；
83.流程级：流程级测试需分析整体业务流程相关、数据流转、产品全生命周期等，完成对各种业务流场景的测试覆盖；
84.界面要素级：分离业务，对界面ui的分析测试，单纯针对界面各要素分析，与具体业务无关。
85.业务操作为业务流程最小、最基本单元，属于独立的行为过程。因此将业务操作的测试归类为单元测试。平台提供对业务操作自动化测试能力。
86.1、对业务操作进行静态分析，通过klocwork、qac、testbed等工具进行静态分析，分析程序分支、路径等程序逻辑。
87.2、按路径、条件等生成测试案例及测试数据，按照程序分析结果对应业务需求描述生成测试案例，用于统计案例覆盖率；按程序定义的参数类型、长度等生成测试数据，并设置预期返回结果数据。
88.3、自动执行，选择要执行的案例调用执行，执行结果自动对比预期结果，相符的执行通过，不符的执行失败，记录全部执行结果。
89.4、缺陷管理，执行案例的结果可关联至缺陷管理平台记录跟踪管理。
90.5、测试覆盖统计分析，根据对业务操作代码分析和最终生成的案例统计，即可得出测试覆盖率，参考此数据可对未覆盖的部分加强业务覆盖分析。
91.6、测试执行统计分析，在测试执行过程中可即时查看测试执行统计数据，已执行/未执行，执行成功/执行失败。
92.对业务事项的测试定位为业务级的功能测试，如图6所示，对业务事项的测试过程分为两部分：测试分析、测试执行。
93.测试分析：
94.1.提取业务规则，测试分析活动从提取业务规则开始，条目化提取规则，使得每一条业务规则仅表达一项业务内容。根据业务事项提炼形成测试操作步骤。
95.2.规则分析，业务规则提取后，结合适当的测试分析方法(等价类、边界值、正交组合、功能分解)对规则逐条分析，标注正常、异常测试条件、确认测试空间等。
96.测试执行：
97.1、生成测试案例，测试分析过程结束后，即可生成测试案例。测试要点由测试分析条件组合而成，案例性质由条件标注，操作步骤由业务事项确定的具体场景提炼，测试预期在部署测试空间时确定并可附加检查点。业务操作为业务事项的案例检查点。由此，测试案例的基本要素即以确定。
98.2、测试案例执行，测试执行分为人工和自动化，自动化测试是以案例为单元，针对每个案例自动执行测试脚本，执行结果与预期结果进行比对，相符的执行通过，不符的执行失败，记录全部执行结果。
99.在执行过程中实现管理测试证迹关联上测试案例，即可在案例执行后实现自动生成测试报告。
100.3、缺陷管理，在案例执行后，标准失败的案例可关联缺陷平台登记缺陷并跟踪管理。
101.4、测试覆盖统计分析，测试分析过程中，根据规则提取对应于对业务事项的业务覆盖统计分析，可得出对业务事项测试覆盖率，理论上对业务需求的覆盖率要近于100％。
102.5、测试执行统计分析，在测试执行过程中可即时查看测试执行统计数据，已执行/未执行，执行成功/执行失败
103.根据软件需求中定义的输入输出、界面规则生成案例(或人工分析)，平台通过多年积累出公共要素(如日期、身份证号、性别等)、行业要素的规则库、案例库，从而形成有复用价值的测试资产库。
104.界面要素测试过程同业务级测试过程基本相同，主要划分为测试分析、测试执行两大部分。
105.测试分析：根据软件需求定义的输入输出要素，逐个要素提取要素规则，针对界面的规则单独分析(界面跳转等)，再由要素规则生成要素测试案例。
106.测试执行：同业务测试执行过程，关联至缺陷管理平台记录跟踪管理缺陷。
107.使用平台建设系统的目标代码分为两部分，一部分是业务描述参数及用户界面描述参数，一部分是由开发人员编写的基础服务(业务操作)代码。平台提供参数的封板及发布功能，将参数发布到发布库中，供生产使用。源代码部分配合源代码管理工具、自动构建工具发布到发布库(镜像仓库)中，其中源代码管理工具包括git、svn、cvs，git为分布式管理架构，svn、cvs为集中式管理架构，同时根据系统架构生成对应的发布脚本文件，实现自动化部署。并对发布过程进行全面监控。技术平台提供完备的运维管理功能，包括：实时监控、故障排查、作业管理、运行分析、运维报告、智能巡检、分析等。
108.一种应用软件全生命周期数字化开发技术平台，其特征在于，包括业务架构定义模块、业务执行引擎模块、软件需求定义模块、设计开发模块、软件测试部署模块，
109.业务架构定义模块，其用于获取企业的业务架构，所述业务架构包括架构对象以及相应的架构关系，其中架构对象为企业的机构、部门、岗位、业务事项、业务制度，架构关系包括一个企业包含一个或多个机构，一个机构包含一个或多个部门，一个部门包含一个或多个岗位，一个岗位对应一个或多个业务事项，业务事项包括一个或多个业务过程和业
务操作，业务制度用于表示业务过程和业务操作之间的逻辑关系，业务过程是执行一个或多个业务操作的逻辑过程，通过业务描述语言对业务事项和业务制度进行数字化定义并生成可执行的数字化脚本；
110.业务执行引擎模块，其用于对可执行的数字化脚本进行解析并执行，包括判断可执行的数字化脚本的类型，若数字化脚本的类型为流程，则解析数字化脚本并执行流程，若数字化脚本的类型为过程，则解析数字化脚本并执行过程；
111.软件需求定义模块，根据执行后的数字化业务需求确定开发应用软件的软件需求，软件需求包括多个具体描述单元，具体描述单元包括一个或多个业务需求；
112.设计开发模块，根据软件需求进行设计开发，包括设计数据库、数据对象，根据软件需求所对应的业务需求生成代码框架，开发人员根据软件需求所对应的业务需求编写代码；
113.软件测试部署模块，其用于对开发的应用软件进行测试和部署。
114.整体的有益效果：
115.本发明提供一种应用软件全生命周期数字化开发方法，通过对业务事项、业务制度数字化，将数字化后的业务事项、业务制度贯彻软件工程各阶段，从整体上大幅度提高应用软件的生产效率，并构建出依据数字化业务制度执行的应用系统，同时可以通过应用系统对业务制度进行调整、优化和创新，提高应用系统随需而变和可持续创新发展的能力。
116.最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。