软件产品的业务功能实现方法、装置和计算机设备与流程

    专利查询2022-07-07  122



    1.本技术涉及软件产品迭代技术领域,特别是涉及一种软件产品的业务功能实现方法、装置、计算机设备和存储介质。


    背景技术:

    2.随着互联网行业市场环境快速的变化,以及面对激烈的竞争市场和企业自身对业务的拓展,企业需要对自身的软件产品进行不断地迭代。也就是,企业针对软件产品的迭代,需要不断重复用户需求分析、形成产品技术文档、功能研发、测试上线、迭代效果分析等各阶段的研发工作。大量重复且多方协作的工作将会严重制约团队效率和软件产品的质量提高。大部分企业采用敏捷开发模式以进行产品迭代方法,通过缩短单次迭代的周期,达到短期交付的效果,加快了软件产品更新速度,并且降低需求改变带来的风险,来保证产品设计改进紧跟用户多变的需求,进而逐步完善产品。
    3.但是,单次迭代周期的缩短一方面是压缩了用户需求分析的时间,降低了需求分析的准确性,导致软件产品设计改进偏离用户需求,进而导致迭代效果不如预期;另一方面同时也压缩了研发测试上线时间,导致研发出的软件产品质量下降,研发不得不再花时间进行修复,从而成本变高。
    4.因此,当前通过缩短单次软件产品的迭代的周期,以达到短期交付迭代后的软件产品的方式,虽然加快了软件产品的更新速度,但是迭代出的软件产品可能出现不满足用户需求的问题,以及可能出现软件产品质量下降需要修复而造成软件产品迭代的效率低的问题。


    技术实现要素:

    5.基于此,有必要针对上述技术问题,提供一种软件产品的业务功能实现方法、装置、计算机设备和存储介质,能够提升软件产品的功能迭代效率。
    6.一种软件产品的业务功能实现方法,包括:获取软件产品的业务功能的产品需求信息;根据产品需求信息识别是否需要开发业务功能的功能代码;若确定不需要开发业务功能的功能代码,则根据产品需求信息生成业务功能的业务策略;根据业务策略调用业务功能的功能代码,以实现软件产品的业务功能。
    7.在其中一个实施例中,根据产品需求信息识别是否需要开发业务功能的功能代码,包括:识别是否接收到已配置的输入项的输入项信息,输入项信息与产品需求信息关联;若接收到输入项信息,则确定不需要开发业务功能的功能代码;根据产品需求信息生成业务功能的业务策略,包括:根据输入项信息生成业务功能的业务策略。
    8.在其中一个实施例中,根据产品需求信息识别是否需要开发业务功能的功能代码,包括:若接收到新增的基于产品需求信息开发的输入项以及输入项的输入项信息,基于输入项信息识别是否需要开发业务功能的功能代码;若确定不需要开发业务功能的功能代码,则根据产品需求信息生成业务功能的业务策略,包括:若确定不需要开发业务功能的功
    能代码,则根据输入项信息生成业务功能的业务策略。
    9.在其中一个实施例中,基于输入项信息识别是否需要开发业务功能的功能代码,包括:将输入项信息进行业务功能的功能代码调用测试;若测试结果表征功能代码调用成功,则确定不需要开发业务功能的功能代码;若测试结果表征功能代码调用失败,则确定需要开发业务功能的功能代码。
    10.在其中一个实施例中,确定需要开发业务功能的功能代码之后,还包括:在接收到表征业务功能的功能代码的开发完成的信息时,确定不需要开发业务功能的功能代码。
    11.在其中一个实施例中,确定不需要开发业务功能的功能代码之后,还包括:确定新增的基于产品需求信息开发的输入项的输入项信息验证成功;根据输入项信息生成业务功能的业务策略,包括:当输入项信息验证成功时,根据输入项信息生成业务功能的业务策略。
    12.在其中一个实施例中,根据输入项信息生成业务功能的业务策略,包括:获取业务策略的流程逻辑信息;根据流程逻辑信息识别输入项信息对应的流程节点;将输入项信息与对应的流程节点进行关联;基于关联后的流程逻辑信息生成业务策略。
    13.一种软件产品的业务功能实现装置,包括:获取模块,用于获取软件产品的业务功能的产品需求信息;识别模块,用于根据产品需求信息识别是否需要开发业务功能的功能代码;生成模块,用于若确定不需要开发业务功能的功能代码,则根据产品需求信息生成业务功能的业务策略;实现模块,用于根据业务策略调用业务功能的功能代码,以实现软件产品的业务功能。
    14.一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,处理器执行计算机程序时实现上述任一实施例方法的步骤。
    15.一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现上述任一实施例方法的步骤。
    16.上述软件产品的业务功能实现方法、装置、计算机设备和存储介质,获取软件产品的业务功能的产品需求信息,根据产品需求信息识别是否需要开发业务功能的功能代码,若确定不需要开发业务功能的功能代码,则根据产品需求信息生成业务功能的业务策略,根据业务策略调用业务功能的功能代码,以实现软件产品的业务功能。当实现了软件产品的业务功能时,即可实现软件产品的迭代。
    17.传统的软件产品迭代方式中,从大数据中获取到软件产品的用户需求数据时,需要基于用户需求数据生成产品技术文档,进而由业务和开发测试等人员基于产品技术文档评定出需要研发的业务功能,再由研发人员基于业务功能设置代码逻辑,从而实现软件产品的业务功能。整个软件产品的迭代过程,由研发人员设置迭代的软件产品的整体代码逻辑,从而造成软件产品迭代的效率低。
    18.本技术的一种软件产品的业务功能实现方法,当接收到软件产品的业务功能的产品需求信息时,基于业务功能的产品需求信息识别是否需要开发业务功能的功能代码。若确定不需要开发业务功能的功能代码,则说明软件产品需要迭代的业务功能可以通过现有的业务功能的功能代码实现,无需研发人员重新开发业务功能的功能代码。此时,可根据产品需求信息生成业务功能的业务策略。由于无需研发人员开发对应业务功能的功能代码,可以由业务人员控制系统基于产品需求信息生成业务功能的业务策略,解放研发人员的技
    术劳动。进而,由于业务功能的功能代码已存在,可直接基于业务策略调用业务功能的功能代码,以实现软件产品的业务功能,进而实现软件产品的迭代。整个软件产品的迭代过程,可减少研发人员的技术开发工作量,提高软件产品的迭代效率。
    附图说明
    19.图1为一个实施例中一种软件产品的业务功能实现方法的应用环境图;
    20.图2为一个实施例中一种软件产品的业务功能实现方法的流程示意图;
    21.图3为一个具体实施场景中一种软件产品的业务功能实现方法的流程示意图;
    22.图4为一个实施例中一种软件产品的业务功能实现方法的工作原理的原理示意图;
    23.图5为一个实施例中一种软件产品的业务功能实现装置的结构框图;
    24.图6为一个实施例中计算机设备的内部结构图。
    具体实施方式
    25.为了使本技术的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本技术进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本技术,并不用于限定本技术。
    26.本技术提供的一种软件产品的业务功能实现方法,应用于如图1所示的应用环境中。如图1所示,数据库中存储大量的用户行为大数据。用户需求分析平台102从数据库中拉取用户行为大数据,进而基于用户行为大数据分析用户行为,通过用户行为进行数据加工,数据加工后得到用户需求信息。其中,用户需求分析平台102可以是由软件产品的前端业务人员操作。由用户需求分析平台102基于用户大数据分析得到软件产品中需要新增或更改的业务功能的产品需求信息,再将该产品需求信息通过数据加工成标准的数据格式,作为输入信息发送到软件产品管理平台104。软件产品管理平台104获取软件产品的业务功能的产品需求信息,根据产品需求信息识别是否需要开发业务功能的功能代码,若确定不需要开发业务功能的功能代码,则根据产品需求信息生成业务功能的业务策略,根据业务策略调用业务功能的功能代码,以实现软件产品的业务功能。其中,软件产品管理平台104可由一个或多个电子设备构成。
    27.在一个实施例中,如图2所示,提供了一种软件产品的业务功能实现方法,以该方法应用于图1中的软件产品管理平台104为例进行说明,包括以下步骤:
    28.s202,获取软件产品的业务功能的产品需求信息。
    29.本实施例中,由用户需求分析平台102基于用户大数据分析得到软件产品中需要新增或更改的业务功能的产品需求信息,再将该产品需求信息通过数据加工成标准的数据格式的输入项。其中,产品需求信息中包含业务功能的相关信息,如包含业务功能的名称以及业务功能对应的数值。例如,迭代后的软件产品需要实现在借款环节新增若用户当前设备为新设备需要加验人脸认证这一项业务功能,产品需求信息中包含表征用户当前设备为新设备的名称信息,以及表征用户当前设备为新设备的数值或表征用户当前设备不是新设备的数值。每个来借款的用户行为数据将会落到数据库中,通过比对用户当前设备信息和上一次设备信息数据得出当前用户设备是否为新设备,通过数据加工为业务功能需要的产
    品需求信息。
    30.s204,根据产品需求信息识别是否需要开发业务功能的功能代码。
    31.本实施例中,产品需求信息中包含业务功能的相关信息,基于产品需求信息可以确定出对应的业务功能,进而可以识别出是否需要开发业务功能的功能代码。若产品需求信息识别出需要开发的软件产品的业务功能已存在并可调用,则识别出无需开发该业务功能的功能代码,后续执行的业务功能调用中,可直接调用业务功能的功能代码。例如,上述软件产品中借款环节新增若用户当前设备为新设备需要加验人脸认证这一项业务功能,产品需求信息包含借款环节新增若用户当前设备为新设备需要加验人脸认证这一信息,而判断当前设备是否为新设备的输入项已在软件产品的登录环节业务中已实现,可以复用此信息,加验人脸的业务功能在借款环节已存在,因此借款环节新增若用户当前设备为新设备需要加验人脸认证无需开发对应的功能代码。
    32.s206,若确定不需要开发业务功能的功能代码,则根据产品需求信息生成业务功能的业务策略。
    33.本实施例中,若确定不需要开发业务功能的功能代码,则只需要基于产品需求信息调整软件产品对应的业务策略即可。具体地,根据产品需求信息生成业务功能的业务策略。例如上述产品需求信息包含借款环节新增若用户当前设备为新设备需要加验人脸认证这一信息,生成的业务策略为新设备识别
    ‑‑
    新设备需要加验人脸认证
    ‑‑
    人脸认证成功
    ‑‑
    借款环节的下一个流程节点。
    34.s208,根据业务策略调用业务功能的功能代码,以实现软件产品的业务功能。
    35.本实施例中,软件产品管理平台执行业务策略时,调用业务功能的功能代码,从而实现软件产品的业务功能,进而实现软件产品的业务策略,完成软件产品的迭代。具体地,软件产品管理平台读取业务策略中的策略信息,策略信息中包含业务功能的标识信息,通过标识信息调用已开发的业务功能的功能代码,从而实现软件产品的业务功能。例如上述生成的业务策略为新设备识别
    ‑‑
    新设备需要加验人脸认证
    ‑‑
    人脸认证成功
    ‑‑
    借款环节的下一个流程节点,当识别到策略信息中“新设备需要加验人脸认证”这一流程节点时,直接调用已有的人脸认证的功能代码即可。当业务策略中所有的流程节点执行完毕时,软件产品实现了借款环节这一迭代后的业务,从而实现软件产品的迭代。
    36.上述一种软件产品的业务功能实现方法,当接收到软件产品的业务功能的产品需求信息时,基于业务功能的产品需求信息识别是否需要开发业务功能的功能代码。若确定不需要开发业务功能的功能代码,则说明软件产品需要迭代的业务功能可以通过现有的业务功能的功能代码实现,无需研发人员重新开发业务功能的功能代码。此时,可根据产品需求信息生成业务功能的业务策略。由于无需研发人员开发对应业务功能的功能代码,可以由业务人员控制系统基于产品需求信息生成业务功能的业务策略,解放研发人员的技术劳动。进而,由于业务功能的功能代码已存在,可直接基于业务策略调用业务功能的功能代码,以实现软件产品的业务功能,进而实现软件产品的迭代。整个软件产品的迭代过程,可减少研发人员的技术开发工作量,提高软件产品的迭代效率。
    37.在一个实施例中,上述根据产品需求信息识别是否需要开发业务功能的功能代码,包括:识别是否接收到已配置的输入项的输入项信息,输入项信息与产品需求信息关联;若接收到输入项信息,则确定不需要开发业务功能的功能代码;上述根据产品需求信息
    生成业务功能的业务策略,包括:根据输入项信息生成业务功能的业务策略。
    38.该实施例中,对于已开发的功能代码的业务功能,软件产品管理平台配置对应的输入项。若用户触发选择已配置的输入项的输入项信息以进行信息输入时,软件产品管理平台接收到输入项信息,即可识别出对应的业务功能不需要开发业务功能的功能代码。进而,软件产品管理平台根据输入项信息生成业务功能的业务策略。
    39.例如,将上述通过接收已配置的输入项的输入项信息的方式作为需求类型一。需求类型一的类型描述:新增的业务策略并不需要开发输入项,仅需要业务人员自行调整业务策略即可。即,业务人员通过选择对应的输入项的内容,向软件产品管理平台输入输入项信息,从而基于输入项信息调整业务策略即可,无需开发人员开发输入项,也不需要开发输入项对应的业务功能的功能代码。其中,基于需求类型一的软件产品功能迭代,改进前后的迭代流程如下:
    40.新迭代流程:用户需求分析-》修改业务策略-》业务策略验收通过后上线-》迭代效果分析。老迭代流程:用户需求分析-》形成产品技术文档-》业务和开发测试等人员同步需求和评审需求-》业务功能研发-》业务功能测试-》业务功能验收通过后上线-》迭代效果分析。新迭代流程相对与老迭代流程,由于不涉及到业务功能以及业务功能的功能代码的开发,业务人员可以基于产品需求信息自动调整业务策略,减少了与开发人员沟通以及开发的时间,大大降低了软件产品的迭代时间成本。
    41.举例:借款环节新增若用户当前设备为陌生设备需要加验人脸认证,因陌生设备的输入项已经在软件产品的登录环节有实现,因此仅需要修改借款环节账户安全的业务策略即可实现软件产品的迭代。按照上述新迭代流程和老迭代流程执行该软件产品的迭代时,其效果分别为:新迭代方法平均需要时间为0.5天,平均故障量为0个;老迭代方法平均需要时间为5天,平均故障量为1个。由此可知,采用本实施例的一种软件产品的业务功能实现方法,能够减少软件产品的迭代时间成本,并且保证软件产品迭代的效率。
    42.在一个实施例中,上述根据产品需求信息识别是否需要开发业务功能的功能代码,包括:若接收到新增的基于产品需求信息开发的输入项以及输入项的输入项信息,基于输入项信息识别是否需要开发业务功能的功能代码。上述若确定不需要开发业务功能的功能代码,则根据产品需求信息生成业务功能的业务策略,包括:若确定不需要开发业务功能的功能代码,则根据输入项信息生成业务功能的业务策略。
    43.该实施例中,若软件产品管理平台未配置有产品需求信息对应的输入项,则需要开发对应的输入项,并将开发后的输入项增加到软件产品管理平台。当软件产品管理平台接收到的输入项信息来源于新增的输入项时,需进一步基于输入项信息识别是否需要开发业务功能的功能代码。若基于输入项信息识别不需要开发业务功能的功能代码时,确定业务功能的功能代码已存在并可调用,则根据输入项信息生成业务功能的业务策略。
    44.例如,将上述新增的基于产品需求信息开发的输入项以及输入项的输入项信息这一需求作为需求类型二,需求类型二的类型描述:新增的业务策略需要开发输入项,但对客户端的交互无需新增业务功能。即,开发人员基于产品需求信息开发输入项,并通过在输入项填写内容的方式向软件产品管理平台输入输入项信息,软件产品管理平台基于输入项信息判断是否需要开发业务功能的功能代码,若不需要开发业务功能的功能代码,则基于输入项信息调整业务策略即可,无需开发人员开发输入项对应的业务功能的功能代码。其中,
    基于需求类型二的软件产品功能迭代,改进前后的迭代流程如下:
    45.新迭代流程:用户需求分析-》形成新增输入项的产品技术文档-》业务和开发测试等人员同步需求和评审需求-》输入项开发-》输入项测试-》输入项验收-》业务修改策略-》策略验收通过后上线-》迭代效果分析。老迭代流程:用户需求分析-》形成产品技术文档-》业务和开发测试等人员同步需求和评审需求-》业务功能研发-》业务功能测试-》业务功能验收通过后上线-》迭代效果分析。通过对比可知,新迭代流程中输入项开发逻辑主要为数据加工不涉及对客户端流程和兼容历史逻辑,因此相对简单,理解和沟通成本会降低,输入项开发后,由于不涉及到业务功能以及业务功能的功能代码的开发,业务人员可以基于产品需求信息自动调整业务策略,减少了与开发人员沟通以及开发的时间,大大降低了软件产品的迭代时间成本。
    46.举例:为了保障用户借款交易安全,在用户近1天输入交易密码连续错误次数达到2次以上或近3天输入交易密码连续错误次数达到3次以上或近7天输入交易密码连续错误次数达到5次以上就需要在借款提交前再做一次人脸验证,调用人脸验证的代码逻辑已有,客户端无需新增。然而,由于软件产品管理平台中没有相似的输入项可用,需向大数据或开发提供需要的输入项。输入项为:用户近1天/3天/7天(自然日)交易密码连续输入失败次数。其效果分别为:新迭代方法平均需要时间为3天,平均故障量为1个;老迭代方法平均需要时间为15天,平均故障量为1个。由此可知,采用本实施例的一种软件产品的业务功能实现方法,能够减少软件产品的迭代时间成本,并且保证软件产品迭代的效率。
    47.在一个实施例中,上述基于输入项信息识别是否需要开发业务功能的功能代码,包括:将输入项信息进行业务功能的功能代码调用测试;若测试结果表征功能代码调用成功,则确定不需要开发业务功能的功能代码;若测试结果表征功能代码调用失败,则确定需要开发业务功能的功能代码。在一个示例中,确定需要开发业务功能的功能代码之后,还包括:在接收到表征业务功能的功能代码的开发完成的信息时,确定不需要开发业务功能的功能代码。
    48.该实施例中,上述基于输入项信息识别是否需要开发业务功能的功能代码的方式为:通过输入项信息对业务功能的功能代码调用测试,即对客户端的该业务功能进行功能测试,若测试成功,则表明业务功能的功能代码调用成功,确定不需要开发业务功能的功能代码。若测试失败,则表明业务功能的功能代码调用失败,确定需要开发业务功能的功能代码。当业务功能的功能代码需要开发时,研发人员对业务功能的功能代码进行开发,并对开发的业务功能的功能代码进行测试,软件产品管理平台对业务功能的功能代码进行验收后,确定不需要开发业务功能的功能代码。
    49.例如,将上述需要开发输入项以及基于输入项信息识别出需要开发业务功能的功能代码这一需求作为需求类型三,需求类型三的类型描述:新增的业务策略需要开发输入项,且对客户端的交互需新增对应的业务功能。即,开发人员基于产品需求信息开发输入项,同时基于输入项信息开发业务功能的功能代码。其中,基于需求类型二的软件产品功能迭代,改进前后的迭代流程如下:
    50.新迭代流程:用户需求分析-》形成产品技术文档-》业务和开发测试等人员同步需求和评审需求-》输入项开发以及对客户端的业务功能研发-》部署业务策略-》功能测试-》策略和功能验收通过后上线-》迭代效果分析。老迭代流程:用户需求分析-》形成产品技术
    文档-》业务和开发测试等人员同步需求和评审需求-》业务功能研发-》业务功能测试-》业务功能验收通过后上线-》迭代效果分析。
    51.新迭代流程从流程上看相比较之前新增了业务策略部分的输入项开发以及对客户端的业务功能研发,但因业务逻辑均在业务策略中管理,因此开发侧业务逻辑需求的开发相对较为简单,因此新迭代流程一方面能缩短开发时间,也减少了开发过程中因不理解业务逻辑需要多次沟通的问题,另一方面有助于后续快速进行上述需求类型一的迭代。
    52.举例:为提升用户借款体验,新增支持生物识别的方式验证用户的交易安全,当用户设置了生物识别且借款交易金额在2w以下,推荐用户使用生物识别验证交易安全实现快捷交易。在软件产品的业务功能中,未接入过生物识别,因此客户端需要新增生物识别校验交易安全的识别方式这一业务功能,并且需要新增输入项。新增输入项为:是否设置过生物识别和借款金额。其效果分别为:新迭代方法平均需要时间为20天,故障量为2个。老迭代方法平均需要时间为30天,故障量为5个。由此可知,采用本实施例的一种软件产品的业务功能实现方法,能够减少软件产品的迭代时间成本,并且保证软件产品迭代的效率。
    53.在一个实施例中,上述确定不需要开发业务功能的功能代码之后,还包括:确定新增的基于产品需求信息开发的输入项的输入项信息验证成功。上述根据输入项信息生成业务功能的业务策略,包括:当输入项信息验证成功时,根据输入项信息生成业务功能的业务策略。
    54.该实施例中,新增输入项时,需要对输入项以及输入项信息进行验证。验证通过后,软件产品管理平台基于输入项信息生成业务功能的业务策略。
    55.基于上述需求类型一、需求类型二以及需求类型三,以下给出一个具体的实施例,以说明三种需求类型在软件产品迭代中的处理方式:
    56.对于不同的产品需求,软件产品的迭代的流程会有所不同。如图3所示,软件产品管理平台可以由业务端、大数据端以及研发和测试端组成。业务端可以由软件产品的前端业务人员进行操作管理,大数据端可以由用户数据管理人员进行操作管理,研发和测试端可以由研发人员进行操作管理。
    57.举例分析现有的上述三种需求类型需要的迭代流程。参见图3,当通过用户需求分析确定软件产品迭代对应的业务功能的类型属于上述需求类型一时,对应图3中的“1仅修改业务策略的需求”这一流程。当通过用户需求分析确定软件产品迭代对应的业务功能的类型属于上述需求类型二时,对应图3中“2需要开发输入项
    ”‑“
    不需要开发对客户端的业务功能
    ”‑“
    输入项验收通过”这一流程。当通过用户需求分析确定软件产品迭代对应的业务功能的类型属于上述需求类型三时,对应图3中“2需要开发输入项
    ”‑“
    需要开发对客户端的业务功能
    ”‑“
    对客户端的业务功能进行开发并测试
    ”‑“
    业务功能/输入项验收通过”这一流程。
    58.由此可知,上述实施例的一种软件产品的业务功能实现方法,能够将对客户端的交互逻辑由代码变成业务策略,可在在业务端的决策平台上部署,由开发和测试端调用决策平台对应的业务策略接口实现用户端的交互,在实现客户端的软件产品的迭代时,无需由开发和测试端统一研发,设置软件产品的整套逻辑代码,通过配置的方式也可实现软件产品的快速迭代。
    59.在一个实施例中,上述根据输入项信息生成业务功能的业务策略,包括:获取业务策略的流程逻辑信息;根据流程逻辑信息识别输入项信息对应的流程节点;将输入项信息
    与对应的流程节点进行关联;基于关联后的流程逻辑信息生成业务策略。
    60.该实施例中,业务策略中包含实现软件产品的某一业务的整套逻辑流程,通过实现业务策略中的整套逻辑流程实现软件产品的某一业务。软件产品管理平台获取业务策略的整套逻辑流程对应的流程逻辑信息,根据流程逻辑信息识别输入项信息对应在整套逻辑流程中的流程节点,将输入项信息与对应的流程节点进行关联,关联后得到生成业务策略。因此,软件产品管理平台实现业务策略时,运行业务策略对应的整套逻辑流程,当运行到输入项信息与对应的流程节点时,调用业务功能的功能代码,以实现业务功能,进而实现业务策略,从而完成软件产品的迭代。
    61.以下基于一具体应用场景,详细说明上述一种软件产品的业务功能实现方法:
    62.一种软件产品的业务功能实现方法的工作原理参见图4所示。本技术的一种软件产品的业务功能实现方法,基于大数据分析和智能化决策实现软件产品的功能迭代,主要通过将对客户端的交互逻辑由代码转变为业务策略在决策平台上部署,不再由开发通过代码管理业务逻辑,而是由业务人员来部署和控制迭代逻辑,从而可以加快软件产品的功能迭代效率。结合图3,具体地实现流程如下:
    63.1.由业务人员分析用户需求,主要基于用户大数据分析,形成软件产品的技术方案文档。
    64.2.由大数据或开发人员将用户数据加工为业务逻辑需要的输入项,不需要新增输入项则由业务人员直接修改已配置的输入项的输入项信息,以通过输入项的输入项信息修改业务策略。
    65.3.由开发人员来开发用户端的交互,用户端交互相比较迭代前没有变化则不需要开发。
    66.4.由测试人员进行软件产品的功能测试以及输入项测试。
    67.5.由业务人员进行功能/输入项验收,通过后上线到决策平台。
    68.6.由业务人员将业务策略部署到决策平台,由业务人员来验证业务策略是否正常。
    69.7.由业务人员进行软件产品的迭代效果分析。
    70.有上述例子可知,本技术的一种软件产品的业务功能实现方法,能够提升软件产品的功能迭代效率:通过自动化的工具打破业务与it的边界,由业务人员自身管理业务逻辑,而不需要多方沟通,降低协调成本和研发成本。此外,还可提升用户满意度。应用大数据分析和商业智能分析提升用户需求分析的准确性,更加高效地应对客户需求、提升用户满意度,提高企业核心竞争力。
    71.应该理解的是,虽然流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,附图中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些子步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
    72.本技术还提供一种软件产品的业务功能实现装置,如图5所示,该装置包括获取模块502、识别模块504、生成模块506以及实现模块508。获取模块502,用于获取软件产品的业
    务功能的产品需求信息;识别模块504,用于根据产品需求信息识别是否需要开发业务功能的功能代码;生成模块506,用于若确定不需要开发业务功能的功能代码,则根据产品需求信息生成业务功能的业务策略;实现模块508,用于根据业务策略调用业务功能的功能代码,以实现软件产品的业务功能。
    73.在其中一个实施例中,根据产品需求信息识别是否需要开发业务功能的功能代码,包括:识别是否接收到已配置的输入项的输入项信息,输入项信息与产品需求信息关联;若接收到输入项信息,则确定不需要开发业务功能的功能代码;根据产品需求信息生成业务功能的业务策略,包括:根据输入项信息生成业务功能的业务策略。
    74.在其中一个实施例中,根据产品需求信息识别是否需要开发业务功能的功能代码,包括:若接收到新增的基于产品需求信息开发的输入项以及输入项的输入项信息,基于输入项信息识别是否需要开发业务功能的功能代码;若确定不需要开发业务功能的功能代码,则根据产品需求信息生成业务功能的业务策略,包括:若确定不需要开发业务功能的功能代码,则根据输入项信息生成业务功能的业务策略。
    75.在其中一个实施例中,基于输入项信息识别是否需要开发业务功能的功能代码,包括:将输入项信息进行业务功能的功能代码调用测试;若测试结果表征功能代码调用成功,则确定不需要开发业务功能的功能代码;若测试结果表征功能代码调用失败,则确定需要开发业务功能的功能代码。
    76.在其中一个实施例中,确定需要开发业务功能的功能代码之后,还包括:在接收到表征业务功能的功能代码的开发完成的信息时,确定不需要开发业务功能的功能代码。
    77.在其中一个实施例中,确定不需要开发业务功能的功能代码之后,还包括:确定新增的基于产品需求信息开发的输入项的输入项信息验证成功;根据输入项信息生成业务功能的业务策略,包括:当输入项信息验证成功时,根据输入项信息生成业务功能的业务策略。
    78.在其中一个实施例中,根据输入项信息生成业务功能的业务策略,包括:获取业务策略的流程逻辑信息;根据流程逻辑信息识别输入项信息对应的流程节点;将输入项信息与对应的流程节点进行关联;基于关联后的流程逻辑信息生成业务策略。
    79.关于软件产品的业务功能实现装置的具体限定可以参见上文中对于软件产品的业务功能实现方法的限定,在此不再赘述。上述软件产品的业务功能实现装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中,也可以以软件形式存储于计算机设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。
    80.在一个实施例中,提供了一种计算机设备,该计算机设备可以是支持软件产品管理平台运行的服务器,其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中,该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部设备连接,以接收外部设备的数据信息。该计算机程序被处理器执行时以实现一种软件产品的业务功能实现方法。
    81.本领域技术人员可以理解,图6中示出的结构,仅仅是与本技术方案相关的部分结
    构的框图,并不构成对本技术方案所应用于其上的计算机设备的限定,具体的计算机设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
    82.在一个实施例中,提供了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,处理器执行计算机程序时实现以下步骤:获取软件产品的业务功能的产品需求信息;根据产品需求信息识别是否需要开发业务功能的功能代码;若确定不需要开发业务功能的功能代码,则根据产品需求信息生成业务功能的业务策略;根据业务策略调用业务功能的功能代码,以实现软件产品的业务功能。
    83.在其中一个实施例中,处理器执行计算机程序实现上述的根据产品需求信息识别是否需要开发业务功能的功能代码步骤时,具体实现以下步骤:识别是否接收到已配置的输入项的输入项信息,输入项信息与产品需求信息关联;若接收到输入项信息,则确定不需要开发业务功能的功能代码;处理器执行计算机程序实现上述的根据产品需求信息生成业务功能的业务策略步骤时,具体实现以下步骤:根据输入项信息生成业务功能的业务策略。
    84.在其中一个实施例中,处理器执行计算机程序实现上述的根据产品需求信息识别是否需要开发业务功能的功能代码步骤时,具体实现以下步骤:若接收到新增的基于产品需求信息开发的输入项以及输入项的输入项信息,基于输入项信息识别是否需要开发业务功能的功能代码;处理器执行计算机程序实现上述的若确定不需要开发业务功能的功能代码,则根据产品需求信息生成业务功能的业务策略步骤时,具体实现以下步骤:若确定不需要开发业务功能的功能代码,则根据输入项信息生成业务功能的业务策略。
    85.在其中一个实施例中,处理器执行计算机程序实现上述的基于输入项信息识别是否需要开发业务功能的功能代码步骤时,具体实现以下步骤:将输入项信息进行业务功能的功能代码调用测试;若测试结果表征功能代码调用成功,则确定不需要开发业务功能的功能代码;若测试结果表征功能代码调用失败,则确定需要开发业务功能的功能代码。
    86.在其中一个实施例中,处理器执行计算机程序时还实现以下步骤:在接收到表征业务功能的功能代码的开发完成的信息时,确定不需要开发业务功能的功能代码。
    87.在其中一个实施例中,处理器执行计算机程序时还实现以下步骤:确定新增的基于产品需求信息开发的输入项的输入项信息验证成功;根据输入项信息生成业务功能的业务策略,包括:当输入项信息验证成功时,根据输入项信息生成业务功能的业务策略。
    88.在其中一个实施例中,处理器执行计算机程序实现上述的根据输入项信息生成业务功能的业务策略步骤时,具体实现以下步骤:获取业务策略的流程逻辑信息;根据流程逻辑信息识别输入项信息对应的流程节点;将输入项信息与对应的流程节点进行关联;基于关联后的流程逻辑信息生成业务策略。
    89.在一个实施例中,提供了一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现以下步骤:获取软件产品的业务功能的产品需求信息;根据产品需求信息识别是否需要开发业务功能的功能代码;若确定不需要开发业务功能的功能代码,则根据产品需求信息生成业务功能的业务策略;根据业务策略调用业务功能的功能代码,以实现软件产品的业务功能。
    90.在其中一个实施例中,计算机程序被处理器执行实现上述的根据产品需求信息识别是否需要开发业务功能的功能代码步骤时,具体实现以下步骤:识别是否接收到已配置的输入项的输入项信息,输入项信息与产品需求信息关联;若接收到输入项信息,则确定不
    需要开发业务功能的功能代码;计算机程序被处理器执行实现上述的根据产品需求信息生成业务功能的业务策略步骤时,具体实现以下步骤:根据输入项信息生成业务功能的业务策略。
    91.在其中一个实施例中,计算机程序被处理器执行实现上述的根据产品需求信息识别是否需要开发业务功能的功能代码步骤时,具体实现以下步骤:若接收到新增的基于产品需求信息开发的输入项以及输入项的输入项信息,基于输入项信息识别是否需要开发业务功能的功能代码;计算机程序被处理器执行上述的若确定不需要开发业务功能的功能代码,则根据产品需求信息生成业务功能的业务策略步骤时,具体实现以下步骤:若确定不需要开发业务功能的功能代码,则根据输入项信息生成业务功能的业务策略。
    92.在其中一个实施例中,计算机程序被处理器执行实现上述的基于输入项信息识别是否需要开发业务功能的功能代码步骤时,具体实现以下步骤:将输入项信息进行业务功能的功能代码调用测试;若测试结果表征功能代码调用成功,则确定不需要开发业务功能的功能代码;若测试结果表征功能代码调用失败,则确定需要开发业务功能的功能代码。
    93.在其中一个实施例中,计算机程序被处理器执行时还实现以下步骤:在接收到表征业务功能的功能代码的开发完成的信息时,确定不需要开发业务功能的功能代码。
    94.在其中一个实施例中,计算机程序被处理器执行时还实现以下步骤:确定新增的基于产品需求信息开发的输入项的输入项信息验证成功;根据输入项信息生成业务功能的业务策略,包括:当输入项信息验证成功时,根据输入项信息生成业务功能的业务策略。
    95.在其中一个实施例中,计算机程序被处理器执行实现上述的根据输入项信息生成业务功能的业务策略步骤时,具体实现以下步骤:获取业务策略的流程逻辑信息;根据流程逻辑信息识别输入项信息对应的流程节点;将输入项信息与对应的流程节点进行关联;基于关联后的流程逻辑信息生成业务策略。
    96.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限,ram以多种形式可得,诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。
    97.以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
    98.以上所述实施例仅表达了本技术的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本技术构思的前提下,还可以做出若干变形和改进,这些都属于本技术的保护范围。因此,本技术专利的保护范围应以所附权利要求为准。
    转载请注明原文地址:https://tc.8miu.com/read-1710.html

    最新回复(0)