CN114281312A - 软件系统的构建方法、装置及计算机可读存储介质 - Google Patents

Abstract

本申请提供了一种软件系统的构建方法、装置、计算机可读存储介质及处理器，该方法通过基于获取目标项目的业务功能需求和非功能指标，解析相关架构得到第一解析结果，解析相关架构主要工作是在立项材料的基础上依据项目功能需求范围、非功能技术指标要求，细化架构解决方案，并且分析系统的范围，明确本次项目应用功能，所涉及规划的系统边界，并分析四大架构，设计典型交易线；对相关参量进行解析，得到第二解析结果，最后根据第一解析结果和第二解析结果，来构建实现目标项目的软件系统，最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义，进而解决现有技术中软件系统的构建方法不支持业务建模类需求的问题。

Description

软件系统的构建方法、装置及计算机可读存储介质

技术领域

本申请涉及软件系统构建技术领域，具体而言，涉及一种软件系统的构建方法、装置、计算机可读存储介质及处理器。

背景技术

现有技术中构建一个软件系统一般分为需求分析阶段和系统设计阶段两个阶段，需求分析阶段的主要任务是通过开发人员与用户之间的广泛交流，不断澄清一些模糊的概念，最终形成一个完整的、清晰的、一致的需求说明。而当明确了用户的需求之后，下一步的任务就是对未来的软件系统进行设计，它是确定系统实现的关键工作。需求分析和设计的方法对软件开发过程而言是十分重要的，因此必须有一套切实可行的方法来指导项目成员进行相关工作。需求分析解决的是“做什么”的问题，系统设计则是解决“怎么做”的问题。

现有技术中的软件系统的构建方法基本是针对功能点需求进行设计，不支持业务建模类需求，即不具备对业务建模类需求的承接能力。

发明内容

本申请的主要目的在于提供一种软件系统的构建方法、装置、计算机可读存储介质及处理器，以解决现有技术中软件系统的构建方法不支持业务建模类需求的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种软件系统的构建方法，该包括：获取目标项目的业务功能需求和非功能指标；基于所述业务功能需求和所述非功能指标，解析相关架构得到第一解析结果，所述相关架构包括至少以下之一：应用架构、数据架构、技术架构、安全架构；对相关参量进行解析，得到第二解析结果，所述相关参量包括至少以下之一：所述非功能指标、运维需求、业务运行场景；根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统。

进一步地，获取目标项目的业务功能需求包括：获取业务模型组的应用和组件开发需求定义；根据所述业务模型组的应用和组件开发需求定义，通过相关分析操作确定所述目标项目的业务功能需求，所述相关分析操作包括至少以下之一：功能差异分析、CPC还原分析、数据差异分析、产品匹配性分析。

进一步地，根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统的过程中，所述方法还包括：根据所述第一解析结果和所述第二解析结果，识别系统工作流和系统用例；定义已识别的所述系统工作流和已识别的所述系统用例。

进一步地，根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统的过程中，所述方法还包括：根据所述第一解析结果和所述第二解析结果，识别应用组件业务数据范围；根据所述应用组件业务数据范围确定应用组件数据模型。

进一步地，在根据所述应用组件业务数据范围确定应用组件数据模型之后，所述方法还包括：根据所述应用组件数据模型对应用组件的功能进行识别，对应用组件的功能进行识别包括至少以下之一：识别业务对象构件、识别应用组件服务、识别批处理服务、识别产品参数；基于已经识别到的所述应用组件的功能，定义至少以下之一：业务对象构件、应用组件服务、批处理服务、应用组件非功能设计方案。

进一步地，在基于已经识别到的所述应用组件的功能，定义至少以下之一：业务对象构件、应用组件服务、批处理服务、应用组件非功能设计方案之后，所述方法还包括：将ATS与ACS对接、OLAP联机服务与数据封装服务对接、批处理服务与数据访问服务对接；将应用、应用组件、集成功能和所述非功能指标分解到应用架构各层。

进一步地，在将应用、应用组件、集成功能和所述非功能指标分解到应用架构各层之后，所述方法还包括：生成渠道前端展示层和渠道后端服务层；确定受理模式，且在确定所述受理模式之后，确定交易的列表和交易的流程；进行服务构建和分布式要素的设计，所述分布式要素包括分表因子和分表分库策略；进行数据管理层物理数据模型和数据接口物理的设计。

进一步地，根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统的过程中，所述方法还包括：识别目标组件外呼的应用集成和所述目标组件对外发布的应用集成；识别与行外系统、原有系统以及跨应用组件之间的数据传输功能；根据业务流程及组件概要设计，确定通过消息传输的交易、源系统和目标系统；识别数据集成需求。

根据本申请的另一方面，提供了一种软件系统的构建装置，包括：获取单元、第一解析单元、第二解析单元和构建单元，获取单元用于获取目标项目的业务功能需求和非功能指标；第一解析单元用于基于所述业务功能需求和所述非功能指标，解析相关架构得到第一解析结果，所述相关架构包括至少以下之一：应用架构、数据架构、技术架构、安全架构；第二解析单元用于对相关参量进行解析，得到第二解析结果，所述相关参量包括至少以下之一：所述非功能指标、运维需求、业务运行场景；构建单元用于根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统。

根据本申请的另一方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质包括存储的程序，其中，在所述程序运行时控制所述计算机可读存储介质所在设备执行上述任意一种所述的方法。

根据本申请的另一方面，还提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行上述任意一种所述的方法。

应用本申请的技术方案，通过基于获取目标项目的业务功能需求和非功能指标，解析相关架构得到第一解析结果，上述解析相关架构主要工作是在立项材料的基础上依据项目功能需求范围、非功能技术指标要求，细化架构解决方案，并且分析系统的范围，明确本次项目应用功能，所涉及规划的系统边界，并分析四大架构，设计典型交易线；对相关参量进行解析，得到第二解析结果，最后根据第一解析结果和第二解析结果，来构建实现上述目标项目的软件系统，最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义，进而解决现有技术中软件系统的构建方法不支持业务建模类需求的问题。

附图说明

构成本申请的一部分的说明书附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了根据本申请实施例的软件系统的构建方法的流程图；

图2示出了根据本申请实施例的软件系统的构建装置的示意图；

图3示出了根据本申请的实施例的信息系统全生命周期实施系统分析设计工艺定位的流程图；

图4示出了根据本申请的实施例的信息系统全生命周期实施系统和分析设计工艺整体工序流程图；

图5示出了根据本申请的实施例的应用分析流程图；

图6示出了根据本申请的实施例的架构分析细化流程图；

图7示出了根据本申请的实施例的实施分析流程图；

图8示出了根据本申请的实施例的实施分析流程图；

图9示出了根据本申请的实施例的定义应用流程图；

图10示出了根据本申请的实施例的定义组件C’数据模型流程图；

图11示出了根据本申请的实施例的识别应用组件功能流程图；

图12示出了根据本申请的实施例的识别定义应用组件流程图；

图13示出了根据本申请的实施例的识别集成功能流程图；

图14示出了根据本申请的实施例的定义集成功能流程图；

图15示出了根据本申请的实施例的分解功能至各应用层级流程图；

图16示出了根据本申请的实施例的设计基于渠道服务层的应用流程图；

图17示出了根据本申请的实施例的设计基于渠道整合层的应用流程图；

图18示出了根据本申请的实施例的设计产品服务层的应用流程图；

图19示出了根据本申请的实施例的设计基于流程整合平台的工作流流程图；

图20示出了根据本申请的实施例的设计基于集成层的应用集成流程图；

图21示出了根据本申请的实施例的设计基于管理决策层的组件流程图；

图22示出了根据本申请的实施例的设计基于数据管理层的数据集成流程图；

图23示出了根据本申请的实施例的数据迁移方案设计流程图；

图24示出了根据本申请的实施例的开发数据迁移程序流程图；

图25示出了根据本申请的实施例的数据迁移检核执行流程图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应该理解的是，当元件(诸如层、膜、区域、或衬底)描述为在另一元件“上”时，该元件可直接在该另一元件上，或者也可存在中间元件。而且，在说明书以及权利要求书中，当描述有元件“连接”至另一元件时，该元件可“直接连接”至该另一元件，或者通过第三元件“连接”至该另一元件。

正如背景技术中所介绍的，现有技术中由于现有技术中的软件系统的构建方法基本是针对功能点需求进行设计，导致现有技术中的软件系统不支持业务建模类需求，即不具备对业务建模类需求的承接能力，为解决现有技术中软件系统的构建方法不支持业务建模类需求的问题，本申请的实施例提供了一种软件系统的构建方法、装置、计算机可读存储介质及处理器。

根据本申请的实施例，提供了一种软件系统的构建方法。

图1是根据本申请实施例的软件系统的构建方法的流程图。如图1所示，该方法包括以下步骤：

步骤S101，获取目标项目的业务功能需求和非功能指标；

具体地，上述非功能指标是指在IT系统建设过程中，除了关注系统的显性功能，还需要关注系统不容易看到的能力。例如，系统的性能、可用性、可靠性、可维护性、扩展性等等。

步骤S102，基于上述业务功能需求和上述非功能指标，解析相关架构得到第一解析结果，上述相关架构包括至少以下之一：应用架构、数据架构、技术架构、安全架构；

其中，安全架构以安全设计目标为目标，以达到：可信凭据、身份验证和身份验证协议：部署和管理可信凭据、身份验证和身份验证协议；对存储信息的访问控制：根据角色、职责和隐私政策控制对存储信息的访问；系统和流程的访问和使用控制：控制对与角色、职责和隐私政策一致的系统和流程的访问和使用；信息保护：根据信息分类、控制和流动政策保护存储或传输的信息；正确可靠运行的保证：确保组件和服务的正确可靠运行；防御威胁：确保减轻威胁；防御欺诈：确保减少欺诈。

关于应用架构(Application Architecture)：在具体领域(例如商业银行)的架构实践中，应用、数据、技术是三个不可或缺的因素，而其中数据又是连接应用和技术的纽带。应用架构决定或者影响了业务的实现，业务操作产生了数据，数据在银行各个应用系统之间进行流转，同时数据的存储、处理以及流转都需要技术的支撑。当商业银行的应用越来越多，数据之间的依赖关系也越来越复杂。数据从单一系统产生，在多个系统内进行传递，完成完整的业务流程，或者用于整合、分析和决策。在此过程中，银行越来越关注数据存储的有效性、处理的效率、流转的及时性和一致性等问题，这些问题就需要通过合理的数据架构设计来解决。

数据架构设计贯穿于数据的全生命周期，从数据产生、流转、整合、分析应用、归档和消亡各个环节，对数据的模型策略、访问机制和存储方式进行设计。无论数据的逻辑模型组织，还是数据的物理存储，其目的是为了满足不同的数据操作的有效和便捷性需求。

技术架构是支撑应用和数据的技术基础，其领域涵盖应用及数据服务所需要的技术组件、技术平台，以及支持开发、运维所需要的环境工具、技术能力等。在银行信息系统架构规划中，技术架构具体体现为支撑数据快速、安全传输的网络基础环境，保障应用及数据稳定、高效运行的计算和存储资源，适应应用需求灵活、通用的基础软件，以及为保障业务连续性所进行灾备设计等内容。

步骤S103，对相关参量进行解析，得到第二解析结果，上述相关参量包括至少以下之一：上述非功能指标、运维需求、业务运行场景；

其中，运维需求是指运维和运行管控指标需求，业务运行场景是指应用和应用组件在生产运行过程中的不同运行状态。业务运行场景分析主要包括业务运行场景来源和业务运行场景分类两个方面。

步骤S104，根据上述第一解析结果和上述第二解析结果，构建实现上述目标项目的软件系统。

具体地，基于获取目标项目的业务功能需求和非功能指标，解析相关架构得到第一解析结果，上述解析相关架构主要工作是在立项材料的基础上依据项目功能需求范围、非功能技术指标要求，细化架构解决方案，并且分析系统的范围，明确本次项目应用功能，所涉及规划的系统边界，并分析四大架构，设计典型交易线；典型交易线：根据项目实施所划定的应用、应用组件范围，基于前期用户工作流程定义和典型交易场景应用解决方案，进行典型交易的系统实现过程(简称交易线)设计，其典型交易线的设计场景并集应覆盖项目相关应用组件、技术组件、数据组件、及安全组件的关键部件，对外部用户提供的是端到端的服务。对相关参量进行解析，得到第二解析结果，最后根据第一解析结果和第二解析结果，来构建实现上述目标项目的软件系统，最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义，进而解决现有技术中软件系统的构建方法不支持业务建模类需求的问题。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在本申请的一种实施例中，获取目标项目的业务功能需求包括：获取业务模型组的应用和组件开发需求定义；根据上述业务模型组的应用和组件开发需求定义，通过相关分析操作确定上述目标项目的业务功能需求，上述相关分析操作包括至少以下之一：功能差异分析、CPC还原分析、数据差异分析、产品匹配性分析，基于业务模型组的应用和组件开发需求定义并通过上述分析，得以拿到业务功能需求。其中，业务模型组用于构建模型，应用和组件开发需求定义指的是系统的开发需求。

其中，CPC是指产品、客户和渠道。在这里CPC是广义的CPC，泛指用于去除部门级业务流程模型差异化，抽象形成企业级流程模型的各种变量因子。除了产品、客户、渠道之外，还有机构、角色、商户、金融介质、物品等等。

在本申请的一种实施例中，根据上述第一解析结果和上述第二解析结果，构建实现上述目标项目的软件系统的过程中，上述方法还包括：根据上述第一解析结果和上述第二解析结果，识别系统工作流和系统用例；定义已识别的上述系统工作流和已识别的上述系统用例，通过分析和描述系统工作流节点，定义流程控制逻辑，识别流程服务。依据已识别出的系统用例列表，根据渠道特性分类，采用系统用例的方法，描述系统用例。

其中，工作流：在指定的业务场景下，通过对业务功能端到端的串接，形成一个完整业务流程的视图。系统用例：专有名词，是一种描述系统功能性需求的方法。使用系统用例的方法来描述4级任务在系统中的处理过程。说明流程模型中第四级任务所对应的第五级步骤中需要系统实现的功能需求。

在本申请的一种实施例中，根据上述第一解析结果和上述第二解析结果，构建实现上述目标项目的软件系统的过程中，上述方法还包括：根据上述第一解析结果和上述第二解析结果，识别应用组件业务数据范围；根据上述应用组件业务数据范围确定应用组件数据模型。

具体地，通过定义应用组件数据模型(旨在识别应用组件业务数据范围)来识别应用组件业务数据范围，进一步定义组件数据模型。例如应用组件使用的业务数据范围可以分为C模型中定义的基础业务数据，以及C模型以外的派生或指标类业务数据，这些数据组成了C’模型属性。为提升数据模型对应用非功能特性的支持，对数据模型进一步进行反规范化调整。最后对结果的规范性进行检查，生成模型间的映射关系，为后续构建实现上述目标项目的软件系统，最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义做好基础。

在本申请的一种实施例中，在根据上述应用组件业务数据范围确定应用组件数据模型之后，上述方法还包括：根据上述应用组件数据模型对应用组件的功能进行识别，对应用组件的功能进行识别包括至少以下之一：识别业务对象构件、识别应用组件服务、识别批处理服务、识别产品参数；基于已经识别到的上述应用组件的功能，定义至少以下之一：业务对象构件、应用组件服务、批处理服务、应用组件非功能设计方案。

其中，识别业务对象构件：采用自顶向下的方法，从流程模型中定义的业务流程操作步骤中识别业务对象构件。业务对象构件：也称为BOC(Business Object Component)，是业务规则的技术实现。作为作用于业务对象上内在的固定业务规则，来源于对各任务步骤的标准化抽象，其输入输出来源于步骤的输入和输出。

识别应用组件服务：采用自顶向下的方法，从流程模型中定义的四级任务和柜面需规中识别应用组件服务。应用组件服务API：应用组件服务API，也称为ACS(ApplicationComponent Service)，是稳态的业务操作规格(Specification)，来源于任务。考虑到IT分布式架构设计约束，适用于不跨分区CU业务对象的操作。应用组件服务来源于标准化任务进行场景还原分析后的抽象，是一种业务对象的控制记录视图的其输入和输出来源于对应的任务。应用组件服务的集合是企业对外领域能力(Capability)的体现。应用组件服务API的实现封装了所包含业务对象服务相关的业务规则。

识别批处理服务：批处理：即是一种通用的业务功能，也可做为通用服务被调用。批处理功能从操作上分为联机和非联机两种形式。

识别产品参数：识别产品参数是将本项目范围内需实施的基础产品中包含的产品条件，以一一对应方式识别为产品参数，初步生成产品参数列表，用于反馈给产品建模组，补充完善产品模型。

应用组件非功能设计方案：按照已确定的非功能指标及约束，对涉及应用组件的具体条目进行设计细化，例如：维护能力、扩展能力等。

具体地，应用组件服务ACS对应用组件外部提供粒度定义良好的服务功能。批处理服务侧重于后台数据的批量处理功能。业务对象构件BOC是业务规则的技术实现。是作用于业务对象上的固定业务规则，来源于对各任务步骤的标准化抽象，其输入输出来源于步骤的输入和输出，定义应用组件是针对已经识别出来的应用组件功能，分别定义ACS服务的输入输出接口，处理逻辑；定义批处理服务的触发方式、处理流程等；确定可售产品范围；定义业务对象构件的输入输出和具体规则；定义应用组件非功能设计方案，对最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义做好进一步的基础。

其中，业务对象构件：也称为BOC(Business Object Component)，是业务规则的技术实现。作为作用于业务对象上内在的固定业务规则，来源于对各任务步骤的标准化抽象，其输入输出来源于步骤的输入和输出。

在本申请的一种实施例中，在基于已经识别到的上述应用组件的功能，定义至少以下之一：业务对象构件、应用组件服务、批处理服务、应用组件非功能设计方案之后，上述方法还包括：将ATS与ACS对接、OLAP联机服务与数据封装服务对接、批处理服务与数据访问服务对接；将应用、应用组件、集成功能和上述非功能指标分解到应用架构各层。

具体地，通过将ATS与ACS对接、OLAP联机服务与数据封装服务对接、批处理服务与数据访问服务对接，达到实施交叉检查，并完善设计的目的；进而得以将应用、组件、集成功能和非功能指标分解到应用架构各层。

其中，应用交易服务API：应用交易服务API，也称为ATS(ApplicationTransaction Service),是敏态的业务操作规格(Specification)，来源于前端应用(如柜面、网银等)与后台组件的交互，或者分布式架构设计下的跨分区对业务对象进行的操作。交易服务的输入和输出来源于特定3级活动工作流交互的输入和输出，或跨分区CU业务对象任务的输入和输出。

应用组件服务API：应用组件服务API,也称为ACS(Application ComponentService)，是稳态的业务操作规格(Specification)，来源于任务。考虑到IT分布式架构设计约束，适用于不跨分区CU业务对象的操作。应用组件服务来源于标准化任务进行场景还原分析后的抽象，是一种业务对象的控制记录视图的其输入和输出来源于对应的任务。应用组件服务的集合是企业对外领域能力(Capability)的体现。应用组件服务API的实现封装了所包含业务对象服务相关的业务规则。

OLAP联机服务：需要暴露的数据分析处理类候选联机服务。

在本申请的一种实施例中，在将应用、应用组件、集成功能和上述非功能指标分解到应用架构各层之后，上述方法还包括：生成渠道前端展示层和渠道后端服务层；确定受理模式，且在确定上述受理模式之后，确定交易的列表和交易的流程；进行服务构建和分布式要素的设计，上述分布式要素包括分表因子和分表分库策略；进行数据管理层物理数据模型和数据接口物理的设计，得以做进一步的细化设计。

其中，分库是指从单个数据库拆分成多个数据库的过程,将数据散落在多个数据库中。分表:从单张表拆分成多张表的过程,将数据散落在多张表内。分表因子：按什么因子分表。

在本申请的一种实施例中，根据上述第一解析结果和上述第二解析结果，构建实现上述目标项目的软件系统的过程中，上述方法还包括：识别目标组件外呼的应用集成和上述目标组件对外发布的应用集成；识别与行外系统、原有系统以及跨应用组件之间的数据传输功能；根据业务流程及组件概要设计，确定通过消息传输的交易、源系统和目标系统；识别数据集成需求。

具体地，识别应用集成主要识别本组件外呼的应用集成和本组件对外发布的应用集成；识别数据传输主要识别与行外系统、原有系统以及跨应用组件之间的数据传输功能。识别消息传输主要任务是识别消息传输功能需求。识别数据集成功能主要是分析识别数据集成需求。通过上述识别为后续构建实现上述目标项目的软件系统，最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义做好基础。

本申请实施例还提供了一种软件系统的构建装置，需要说明的是，本申请实施例的软件系统的构建装置可以用于执行本申请实施例所提供的用于软件系统的构建方法。以下对本申请实施例提供的软件系统的构建装置进行介绍。

图2是根据本申请实施例的软件系统的构建装置的示意图。如图2所示，该装置包括获取单元10、第一解析单元20、第二解析单元30和构建单元40；

获取单元10，用于获取目标项目的业务功能需求和非功能指标；

第一解析单元20，用于基于上述业务功能需求和上述非功能指标，解析相关架构得到第一解析结果，上述相关架构包括至少以下之一：应用架构、数据架构、技术架构、安全架构；

第二解析单元30，用于对相关参量进行解析，得到第二解析结果，上述相关参量包括至少以下之一：上述非功能指标、运维需求、业务运行场景；

构建单元40，用于根据上述第一解析结果和上述第二解析结果，构建实现上述目标项目的软件系统。

具体地，基于获取单元获取目标项目的业务功能需求和非功能指标，第一解析单元解析相关架构得到第一解析结果，上述解析相关架构主要工作是在立项材料的基础上依据项目功能需求范围、非功能技术指标要求，细化架构解决方案，并且分析系统的范围，明确本次项目应用功能，所涉及规划的系统边界，并分析四大架构，设计典型交易线；第二解析单元对相关参量进行解析，得到第二解析结果，最后根据第一解析结果和第二解析结果，构建单元来构建实现上述目标项目的软件系统，最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义，进而解决现有技术中软件系统的构建方法不支持业务建模类需求的问题。

在本申请的一种实施例中，获取单元包括第一获取模块和第一处理模块，第一获取模块用于获取业务模型组的应用和组件开发需求定义；第一处理模块用于根据上述业务模型组的应用和组件开发需求定义，通过相关分析操作确定上述目标项目的业务功能需求，上述相关分析操作包括至少以下之一：功能差异分析、CPC还原分析、数据差异分析、产品匹配性分析，基于业务模型组的应用和组件开发需求定义并通过上述分析，得以保证后续第一解析和第二解析结果的准确性。其中，业务模型组用于构建模型，应用和组件开发需求定义指的是系统的开发需求。

在本申请的一种实施例中，构建单元包括第一识别模块和第二处理模块，识别模块用于根据上述第一解析结果和上述第二解析结果，识别系统工作流和系统用例；第二处理模块用于定义已识别的上述系统工作流和已识别的上述系统用例，通过分析和描述系统工作流节点，定义流程控制逻辑，识别流程服务。依据已识别出的系统用例列表，根据渠道特性分类，采用系统用例的方法，描述系统用例。

在本申请的一种实施例中，构建单元还包括第二识别模块和第三处理模块，第二识别模块用于根据上述第一解析结果和上述第二解析结果，识别应用组件业务数据范围；第三处理模块用于根据上述应用组件业务数据范围确定应用组件数据模型。其中，识别应用组件业务数据范围：应用组件需要实现的数据范围。

具体地，通过定义应用组件数据模型来识别应用组件业务数据范围，进一步定义组件数据模型。例如应用组件使用的业务数据范围可以分为C模型中定义的基础业务数据，以及C模型以外的派生或指标类业务数据，这些数据组成了C’模型属性。为提升数据模型对应用非功能特性的支持，对数据模型进一步进行反规范化调整。最后对结果的规范性进行检查，生成模型间的映射关系，为后续构建实现上述目标项目的软件系统，最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义做好基础。

在本申请的一种实施例中，构建单元还包括第三识别模块和第四处理模块，在第三处理模块根据上述应用组件业务数据范围确定应用组件数据模型之后，第三识别模块用于根据上述应用组件数据模型对应用组件的功能进行识别，对应用组件的功能进行识别包括至少以下之一：识别业务对象构件、识别应用组件服务、识别批处理服务、识别产品参数；第四处理模块基于已经识别到的上述应用组件的功能，定义至少以下之一：业务对象构件、应用组件服务、批处理服务、应用组件非功能设计方案。

具体地，应用组件服务ACS对应用组件外部提供粒度定义良好的服务功能。批处理服务侧重于后台数据的批量处理功能。业务对象构件BOC是业务规则的技术实现。是作用于业务对象上的固定业务规则，来源于对各任务步骤的标准化抽象，其输入输出来源于步骤的输入和输出，定义应用组件是针对已经识别出来的应用组件功能，分别定义ACS服务的输入输出接口，处理逻辑；定义批处理服务的触发方式、处理流程等；确定可售产品范围；定义业务对象构件的输入输出和具体规则；定义应用组件非功能设计方案，对最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义做好进一步的基础。

在本申请的一种实施例中，构建单元还包括第五处理模块和第六处理模块，在第四处理模基于已经识别到的上述应用组件的功能，定义至少以下之一：业务对象构件、应用组件服务、批处理服务、应用组件非功能设计方案之后，第五处理模块将ATS与ACS对接、OLAP联机服务与数据封装服务对接、批处理服务与数据访问服务对接；第六处理模块将应用、应用组件、集成功能和上述非功能指标分解到应用架构各层。

具体地，通过将ATS与ACS对接、OLAP联机服务与数据封装服务对接、批处理服务与数据访问服务对接，达到实施交叉检查，并完善设计的目的；进而得以将应用、组件、集成功能和非功能指标分解到应用架构各层。

在本申请的一种实施例中，构建单元还包括构建模块、第七处理模块、第八处理模块和第九处理模块，在第六处理模块将应用、应用组件、集成功能和上述非功能指标分解到应用架构各层之后，构建模块生成渠道前端展示层和渠道后端服务层；第七处理模块确定受理模式，且在确定上述受理模式之后，确定交易的列表和交易的流程；第八处理模块进行服务构建和分布式要素的设计，上述分布式要素包括分表因子和分表分库策略；第九处理模块进行数据管理层物理数据模型和数据接口物理的设计，得以做进一步的细化设计。

在本申请的一种实施例中，构建单元还包括第四识别模块、第五识别模块、第十处理模块和第六识别模块，第四识别模块识别目标组件外呼的应用集成和上述目标组件对外发布的应用集成；第五识别模块识别与行外系统、原有系统以及跨应用组件之间的数据传输功能；第十处理模块根据业务流程及组件概要设计，确定通过消息传输的交易、源系统和目标系统；第六识别模块识别数据集成需求。

具体地，识别应用集成主要识别本组件外呼的应用集成和本组件对外发布的应用集成；识别数据传输主要识别与行外系统、原有系统以及跨应用组件之间的数据传输功能。识别消息传输主要任务是识别消息传输功能需求。识别数据集成功能主要是分析识别数据集成需求。通过上述识别为后续构建实现上述目标项目的软件系统，最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义做好基础。

所述软件系统的构建装置包括处理器和存储器，上述获取单元、第一解析单元、第二解析单元和构建单元等均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。

处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来解决现有技术中软件系统的构建方法不支持业务建模类需求的问题。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质包括存储的程序，其中，在所述程序运行时控制所述计算机可读存储介质所在设备执行所述软件系统的构建方法。

本发明实施例提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行所述基于获取单元获取目标项目的业务功能需求和非功能指标，第一解析单元解析相关架构得到第一解析结果，上述解析相关架构主要工作是在立项材料的基础上依据项目功能需求范围、非功能技术指标要求，细化架构解决方案，并且分析系统的范围，明确本次项目应用功能，所涉及规划的系统边界，并分析四大架构，设计典型交易线；第二解析单元对相关参量进行解析，得到第二解析结果，最后根据第一解析结果和第二解析结果，构建单元来构建实现所述目标项目的软件系统，最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义，进而解决现有技术中软件系统的构建方法不支持业务建模类需求的问题。

本发明实施例提供了一种设备，设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现至少以下步骤：获取目标项目的业务功能需求和非功能指标；基于所述业务功能需求和所述非功能指标，解析相关架构得到第一解析结果，所述相关架构包括至少以下之一：应用架构、数据架构、技术架构、安全架构；对相关参量进行解析，得到第二解析结果，所述相关参量包括至少以下之一：所述非功能指标、运维需求、业务运行场景；根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统。

进一步地，获取目标项目的业务功能需求包括：获取业务模型组的应用和组件开发需求定义；根据所述业务模型组的应用和组件开发需求定义，通过相关分析操作确定所述目标项目的业务功能需求，所述相关分析操作包括至少以下之一：功能差异分析、CPC还原分析、数据差异分析、产品匹配性分析。

进一步地，根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统的过程中，所述方法还包括：根据所述第一解析结果和所述第二解析结果，识别系统工作流和系统用例；定义已识别的所述系统工作流和已识别的所述系统用例。

进一步地，根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统的过程中，所述方法还包括：根据所述第一解析结果和所述第二解析结果，识别应用组件业务数据范围；根据所述应用组件业务数据范围确定应用组件数据模型。

进一步地，在根据所述应用组件业务数据范围确定应用组件数据模型之后，所述方法还包括：根据所述应用组件数据模型对应用组件的功能进行识别，对应用组件的功能进行识别包括至少以下之一：识别业务对象构件、识别应用组件服务、识别批处理服务、识别产品参数；基于已经识别到的所述应用组件的功能，定义至少以下之一：业务对象构件、应用组件服务、批处理服务、应用组件非功能设计方案。

进一步地，在基于已经识别到的所述应用组件的功能，定义至少以下之一：业务对象构件、应用组件服务、批处理服务、应用组件非功能设计方案之后，所述方法还包括：将ATS与ACS对接、OLAP联机服务与数据封装服务对接、批处理服务与数据访问服务对接；将应用、应用组件、集成功能和所述非功能指标分解到应用架构各层。

进一步地，在将应用、应用组件、集成功能和所述非功能指标分解到应用架构各层之后，所述方法还包括：生成渠道前端展示层和渠道后端服务层；确定受理模式，且在确定所述受理模式之后，确定交易的列表和交易的流程；进行服务构建和分布式要素的设计，所述分布式要素包括分表因子和分表分库策略；进行数据管理层物理数据模型和数据接口物理的设计。

进一步地，根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统的过程中，所述方法还包括：识别目标组件外呼的应用集成和所述目标组件对外发布的应用集成；识别与行外系统、原有系统以及跨应用组件之间的数据传输功能；根据业务流程及组件概要设计，确定通过消息传输的交易、源系统和目标系统；识别数据集成需求。本文中的设备可以是服务器、PC、PAD、手机等。

本申请还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有至少如下方法步骤的程序：获取目标项目的业务功能需求和非功能指标；基于所述业务功能需求和所述非功能指标，解析相关架构得到第一解析结果，所述相关架构包括至少以下之一：应用架构、数据架构、技术架构、安全架构；对相关参量进行解析，得到第二解析结果，所述相关参量包括至少以下之一：所述非功能指标、运维需求、业务运行场景；根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统。

进一步地，获取目标项目的业务功能需求包括：获取业务模型组的应用和组件开发需求定义；根据所述业务模型组的应用和所述组件开发需求定义，通过相关分析操作确定所述目标项目的业务功能需求，所述相关分析操作包括至少以下之一：功能差异分析、CPC还原分析、数据差异分析、产品匹配性分析。

进一步地，根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统的过程中，所述方法还包括：根据所述第一解析结果和所述第二解析结果，识别系统工作流和系统用例；定义已识别的所述系统工作流和已识别的所述系统用例。

进一步地，根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统的过程中，所述方法还包括：根据所述第一解析结果和所述第二解析结果，识别应用组件业务数据范围；根据所述应用组件业务数据范围确定应用组件数据模型。

进一步地，在根据所述应用组件业务数据范围确定应用组件数据模型之后，所述方法还包括：根据所述应用组件数据模型对应用组件的功能进行识别，对应用组件的功能进行识别包括至少以下之一：识别业务对象构件、识别应用组件服务、识别批处理服务、识别产品参数；基于已经识别到的所述应用组件的功能，定义至少以下之一：业务对象构件、应用组件服务、批处理服务、应用组件非功能设计方案。

进一步地，在基于已经识别到的所述应用组件的功能，定义至少以下之一：业务对象构件、应用组件服务、批处理服务、应用组件非功能设计方案之后，所述方法还包括：将ATS与ACS对接、OLAP联机服务与数据封装服务对接、批处理服务与数据访问服务对接；将应用、应用组件、集成功能和所述非功能指标分解到应用架构各层。

进一步地，在将应用、应用组件、集成功能和所述非功能指标分解到应用架构各层之后，所述方法还包括：生成渠道前端展示层和渠道后端服务层；确定受理模式，且在确定所述受理模式之后，确定交易的列表和交易的流程；进行服务构建和分布式要素的设计，所述分布式要素包括分表因子和分表分库策略；进行数据管理层物理数据模型和数据接口物理的设计。

进一步地，根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统的过程中，所述方法还包括：识别目标组件外呼的应用集成和所述目标组件对外发布的应用集成；识别与行外系统、原有系统以及跨应用组件之间的数据传输功能；根据业务流程及组件概要设计，确定通过消息传输的交易、源系统和目标系统；识别数据集成需求。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

实施例

图3示出了根据本申请的实施例的信息系统全生命周期实施系统分析设计工艺定位的流程图，如图3所示：

本实施例涉及一种信息系统全生命周期实施系统分析设计工艺定位的方案，该方案在本申请中主要涉及分析和设计阶段。

上述分析和涉及阶段其组成了如图4所示，即图4示出了根据本申请的实施例的信息系统全生命周期实施系统和分析设计工艺整体工序流程图，本工艺始于分析阶段，并进一步细分为应用分析、架构分析和实施分析三个子阶段。主要工作内容包括确定项目目标、实施范围和策略、接收建模成果、分析技术类需求、分析非功能及约束条件、分析和设计整体架构(或详细架构)，为项目设计阶段提供输入。

设计阶段承接系统分析成果，并进一步细分为识别、定义、分解、细化子阶段。设计阶段由识别应用功能、定义应用、定义组件C’数据模型、识别应用组件功能、定义应用组件、识别集成功能、定义集成功能、分解功能非功能至应用架构层级、设计基于各应用架构层级的应用组成。

图5示出了根据本申请的实施例的应用分析流程图，如图5所示，应用分析是本工艺分析阶段的一道工序。应用分析的主要目的是依据业务模型组的应用和组件开发需求定义，通过功能差异分析、CPC还原分析、数据差异分析、产品匹配性分析等工序任务，最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义。

图6示出了根据本申请的实施例的架构分析细化流程图，如图6所示，架构分析的主要工作是在立项材料的基础上依据项目功能需求范围、非功能技术指标要求，细化架构解决方案。分析系统的范围，明确本次项目应用功能，所涉及规划的系统边界，并分析四大架构，设计典型交易线

图7示出了根据本申请的实施例的实施分析流程图，如图7所示，实施分析是由于业务建模中体现的是标准化的业务功能需求描述，但是并未包含非功能需求相关指标的描述和系统运维监控相关要求，也缺乏系统在不同运行场景的功能和性能要求变化情况，需要在实施分析部分进行分析和补充。主要是分析非功能指标，明确应用监控指标主要目的是，分析运维需求，分析应用和应用组件业务运行场景。

图8示出了根据本申请的实施例的实施分析流程图，如图8所示，识别应用功能工序基于项目实施范围内的3级活动识别、抽象和精炼系统工作流，基于还原后的3级活动识别、抽象和精炼系统用例。对项目应用分析说明书中的用户工作流程进行分析，参照系统工作流识别原则，确定实现用户工作流程的系统工作流。逐一分析CPC还原后的3级活动，识别还原后的业务场景，并确定与业务场景相关联的4级任务，以每个业务场景中所包含的系统行为识别为系统用例。

其中，3级活动：企业级建模的第三级活动。4级任务：企业级建模的第四级任务。

图9示出了根据本申请的实施例的定义应用流程图，如图9所示，定义应用工序基于流程建模成果，定义已识别的系统工作流和系统用例。通过分析和描述系统工作流节点，定义流程控制逻辑，识别流程服务。依据已识别出的系统用例列表，根据渠道特性分类，采用系统用例的方法，描述系统用例。

图10示出了根据本申请的实施例的定义组件C’数据模型流程图，如图10所示，定义组件C’数据模型旨在识别应用组件业务数据范围，进一步定义组件C＇数据模型。应用组件使用的业务数据范围可以分为C模型中定义的基础业务数据，以及C模型以外的派生或指标类业务数据，这些数据组成了C’模型属性。为提升数据模型对应用非功能特性的支持，对数据模型进一步进行反规范化调整。最后对结果的规范性进行检查，生成模型间的映射关系。

图11示出了根据本申请的实施例的识别应用组件功能流程图，如图11所示，识别应用组件功能工序基于业务建模成果对应用组件的功能进行识别，主要包括识别业务对象构件BOC、应用组件服务ACS、识别批处理服务、识别产品参数。应用组件服务ACS对应用组件外部提供粒度定义良好的服务功能。批处理服务侧重于后台数据的批量处理功能。业务对象构件BOC是业务规则的技术实现。是作用于业务对象上的固定业务规则，来源于对各任务步骤的标准化抽象，其输入输出来源于步骤的输入和输出。

图12示出了根据本申请的实施例的识别定义应用组件流程图，如图12所示，定义应用组件是针对已经识别出来的应用组件功能，分别定义ACS服务的输入输出接口，处理逻辑；定义BOC、定义OLAP服务、定义OLTP服务、定义批处理服务的触发方式、处理流程等；确定可售产品范围；定义业务对象构件的输入输出和具体规则；定义应用组件非功能设计方案。其中，OLTP(on-line transaction processing)为联机事务处理，OLAP(On-LineAnalytical Processing)为联机分析处理，OLTP是做事务处理，OLAP是做分析处理。从对数据库操作来看，OLTP主要是对数据的增删改，OLAP是对数据的查询。

图13示出了根据本申请的实施例的识别集成功能流程图，如图13所示，识别集成功能包括四部分：识别应用集成、识别数据传输、识别消息传输和识别数据集成。识别应用集成主要识别本组件外呼的应用集成和本组件对外发布的应用集成；识别数据传输主要识别与行外系统、原有系统以及跨应用组件之间的数据传输功能。识别消息传输主要任务是识别消息传输功能需求，根据业务流程及组件概要设计，确定需通过消息传输的交易及源/目标系统。识别数据集成功能主要是分析识别数据集成需求。

图14示出了根据本申请的实施例的定义集成功能流程图，如图14所示，定义集成功能的主要工作内容是定义应用集成功能、定义数据传输功能，定义消息传输功能和定义数据集成功能。应用集成功能主要指项目应用/组件与行外系统、行内原有系统和跨应用组件的应用集成功能；数据传输功能主要指项目应用/组件与行外系统、原有系统以及跨平台的数据传输功能；消息传输功能是将识别出的消息传输功能需求进行详细定义，以便与关联系统对接。数据集成功能定义主要包括数据集成层数据模型设计、及实体清单列表，识别不同数据的存储区，及定义数据集成管理功能。

图15示出了根据本申请的实施例的分解功能至各应用层级流程图，如图15所示，分解功能至各应用层级工序的目的是完成ATS与ACS、OLAP联机服务与数据封装服务、批处理服务与数据访问四类功能对接的设计和非功能对接的设计，实施交叉检查，并完善设计；进而将应用、组件、集成功能和非功能指标分解到应用架构各层。

图16示出了根据本申请的实施例的设计基于渠道服务层的应用流程图，如图16所示，设计基于渠道服务层的应用是设计电子渠道、自助渠道、员工渠道等渠道的应用。首先，根据系统用例所在的平台和渠道确定设计模式，然后设计渠道前端展示层，定义前端界面，之后进一步完善前端界面所联动渠道后端服务层交易的接口设计，员工渠道引起打印凭证的，还需对凭证格式进行设计。

图17示出了根据本申请的实施例的设计基于渠道整合层的应用流程图，如图17所示，设计基于渠道整合层的应用首先要进行适配器的开发设计，再进行交易设计。交易设计包括：进行受理模式的选择；在确定受理模式后，定义交易的列表，确定交易的流程，以及交易的接口报文设计。

图18示出了根据本申请的实施例的设计产品服务层的应用流程图，如图18所示，设计基于产品服务层的组件工序基于前序工艺的产出，做进一步的细化设计，主要工作内容有:设计服务构件；批处理细化设计，如定时及日终批处理(服务)，批转联处理(服务)等；分布式要素设计，如分表因子，分表分库策略等；设计数据D模型、数据库细化设计，包括分表策略、数据分库、数据存储、清理等策略的设计。数据D模型：物理数据模型。

图19示出了根据本申请的实施例的设计基于流程整合平台的工作流流程图，如图19所示，设计基于流程整合平台的工作流工序的目标是设计系统跨角色、跨时序流程服务。根据系统工作流设计来完成流程服务及接口的设计，为渠道提供集成工作流。

图20示出了根据本申请的实施例的设计基于集成层的应用集成流程图，如图20所示，设计基于集成层的应用集成不仅包括以上设计结果，还需要各服务系统提供服务接口适配器，而服务接口适配器通常是各服务系统完成各平台设计后产生的

图21示出了根据本申请的实施例的设计基于管理决策层的组件流程图，如图21所示，设计基于管理决策层的组件工序用于描述项目在对管理决策层的统一报表系统有报表需求时，如何进行相关服务的设计。

图22示出了根据本申请的实施例的设计基于数据管理层的数据集成流程图，如图22所示，设计基于数据管理层的数据集成工序的目标是完成数据管理层物理数据模型和数据接口物理设计，进行数据映射和ETL设计，为后续开发测试工作提供依据和指导。同时，完成数据质量检核和备份归档等数据集成管理工作设计工作。

图23示出了根据本申请的实施例的数据迁移方案设计流程图，如图23所示，数据迁移方案设计工序用于描述在数据迁移过程中，如何进行现有系统数据到目标系统数据的映射关系、数据转换规则和转换后数据检核规则的设计。

图24示出了根据本申请的实施例的开发数据迁移程序流程图，如图24所示，开发数据迁移程序工序的主要目的是根据数据迁移需求和数据迁移方案，设计和实现数据迁移程序。

图25示出了根据本申请的实施例的数据迁移检核执行流程图，如图25所示，数据迁移检核执行工序的主要目的是对执行数据迁移全过程，通过多轮清洗、补录、转换、检核，验证迁移过程的可行性、合理性，不断提高迁移数据质量。执行数据迁移过程，主要是明确组件从卸数到最后完成迁移的步骤、时序，并及时在专用环境中进行数据检核。

从以上的描述中，可以看出，本申请上述的实施例实现了如下技术效果：

1)、本申请的软件系统的构建方法，基于获取目标项目的业务功能需求和非功能指标，解析相关架构得到第一解析结果，上述解析相关架构主要工作是在立项材料的基础上依据项目功能需求范围、非功能技术指标要求，细化架构解决方案，并且分析系统的范围，明确本次项目应用功能，所涉及规划的系统边界，并分析四大架构，设计典型交易线；对相关参量进行解析，得到第二解析结果，最后根据第一解析结果和第二解析结果，来构建实现所述目标项目的软件系统，最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义，进而解决现有技术中软件系统的构建方法不支持业务建模类需求的问题。

2)、本申请的软件系统的构建装置，基于获取单元获取目标项目的业务功能需求和非功能指标，第一解析单元解析相关架构得到第一解析结果，上述解析相关架构主要工作是在立项材料的基础上依据项目功能需求范围、非功能技术指标要求，细化架构解决方案，并且分析系统的范围，明确本次项目应用功能，所涉及规划的系统边界，并分析四大架构，设计典型交易线；第二解析单元对相关参量进行解析，得到第二解析结果，最后根据第一解析结果和第二解析结果，构建单元来构建实现所述目标项目的软件系统，最终形成和明确项目的范围、项目需实现的业务功能需求清单及定义，进而解决现有技术中软件系统的构建方法不支持业务建模类需求的问题。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (11)

1.一种软件系统的构建方法，其特征在于，包括：

获取目标项目的业务功能需求和非功能指标；

基于所述业务功能需求和所述非功能指标，解析相关架构得到第一解析结果，所述相关架构包括至少以下之一：应用架构、数据架构、技术架构、安全架构；

对相关参量进行解析，得到第二解析结果，所述相关参量包括至少以下之一：所述非功能指标、运维需求、业务运行场景；

根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统。

2.根据权利要求1所述的方法，其特征在于，获取目标项目的业务功能需求，包括：

获取业务模型组的应用和组件开发需求定义；

根据所述业务模型组的应用和组件开发需求定义，通过相关分析操作确定所述目标项目的业务功能需求，所述相关分析操作包括至少以下之一：功能差异分析、CPC还原分析、数据差异分析、产品匹配性分析。

3.根据权利要求1所述的方法，其特征在于，根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统的过程中，所述方法还包括：

根据所述第一解析结果和所述第二解析结果，识别系统工作流和系统用例；

定义已识别的所述系统工作流和已识别的所述系统用例。

4.根据权利要求1所述的方法，其特征在于，根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统的过程中，所述方法还包括：

根据所述第一解析结果和所述第二解析结果，识别应用组件业务数据范围；

根据所述应用组件业务数据范围确定应用组件数据模型。

5.根据权利要求4所述的方法，其特征在于，在根据所述应用组件业务数据范围确定应用组件数据模型之后，所述方法还包括：

根据所述应用组件数据模型对应用组件的功能进行识别，对应用组件的功能进行识别包括至少以下之一：识别业务对象构件、识别应用组件服务、识别批处理服务、识别产品参数；

基于已经识别到的所述应用组件的功能，定义至少以下之一：业务对象构件、应用组件服务、批处理服务、应用组件非功能设计方案。

6.根据权利要求5所述的方法，其特征在于，在基于已经识别到的所述应用组件的功能，定义至少以下之一：业务对象构件、应用组件服务、批处理服务、应用组件非功能设计方案之后，所述方法还包括：

将ATS与ACS对接、OLAP联机服务与数据封装服务对接、批处理服务与数据访问服务对接；

将应用、应用组件、集成功能和所述非功能指标分解到应用架构各层。

7.根据权利要求6所述的方法，其特征在于，在将应用、应用组件、集成功能和所述非功能指标分解到应用架构各层之后，所述方法还包括：

生成渠道前端展示层和渠道后端服务层；

确定受理模式，且在确定所述受理模式之后，确定交易的列表和交易的流程；

进行服务构建和分布式要素的设计，所述分布式要素包括分表因子和分表分库策略；

进行数据管理层物理数据模型和数据接口物理的设计。

8.根据权利要求1所述的方法，其特征在于，根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统的过程中，所述方法还包括：

识别目标组件外呼的应用集成和所述目标组件对外发布的应用集成；

识别与行外系统、原有系统以及跨应用组件之间的数据传输功能；

根据业务流程及组件概要设计，确定通过消息传输的交易、源系统和目标系统；

识别数据集成需求。

9.一种软件系统的构建装置，其特征在于，包括：

获取单元，用于获取目标项目的业务功能需求和非功能指标；

第一解析单元，用于基于所述业务功能需求和所述非功能指标，解析相关架构得到第一解析结果，所述相关架构包括至少以下之一：应用架构、数据架构、技术架构、安全架构；

第二解析单元，用于对相关参量进行解析，得到第二解析结果，所述相关参量包括至少以下之一：所述非功能指标、运维需求、业务运行场景；

构建单元，用于根据所述第一解析结果和所述第二解析结果，构建实现所述目标项目的软件系统。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括存储的程序，其中，在所述程序运行时控制所述计算机可读存储介质所在设备执行权利要求1至8中任意一项所述的方法。

11.一种处理器，其特征在于，所述处理器用于运行程序，其中，所述程序运行时执行权利要求1至8中任意一项所述的方法。

Images