修复率计算方法和装置与流程

本发明涉及移动终端软件版本变更领域，特别涉及修复率计算方法和装置。

背景技术：

随着智能化产品的日益发展，移动终端已经成为用户使用热度最高的电子设备，移动终端中所具备的功能越来越多，性能也越来越强大。但随之而来的，移动终端软件所包含的源码行数也越来越多，而达到千万级别。

由于源码行数越来越多，导致了几乎每个移动终端项目的每一个软件版本的系统测试都会产生或发现几百个故障或变更，整个项目下来至少产生或发现几千个软件故障或变更。面对如此巨大的软件故障和变更数量，常常使得软件版本的质量状态处于模糊状态。

因此，如何更好的展示移动终端软件版本的质量状态，以及展示每个软件版本的变更收敛趋势，成为软件管理和开发过程中十分需要的问题。

技术实现要素：

本发明的主要目的是提供一种修复率计算方法和装置，旨在更好的展示移动终端软件版本的质量状态。

为实现上述目的，本发明提出的一种修复率计算方法，用于移动终端软件版本变更的修复率计算，所述软件版本变更的单个变更项目的流程包括：在项目提交成功时进入项目提交状态并且等待项目决策，通过项目决策而进入项目执行或项目拒绝状态，在所述项目执行并且评审合格时进入项目验收状态；

所述修复率计算方法包括如下步骤：

获得未解决项目数量，所述未解决项目包括处于所述项目提交和项目执行状态的变更项目；

获得已解决项目数量，所述已解决项目包括处于所述项目拒绝和项目验收状态的变更项目；

根据所述未解决项目数量和所述已解决项目数量获得所述移动终端软件版本变更的修复率。

优选的，所述“根据所述未解决项目数量和所述已解决项目数量获得所述移动终端软件版本变更的修复率”的步骤具体包括：

将所述已解决项目数量作为所述修复率的分子；

将所述未解决项目数量与所述已解决项目数量相加之和作为所述修复率的分母；

将所述分子和分母组成所述修复率的数值。

优选的，所述变更项目的流程还包括项目关闭，所述变更项目至少通过以下通道进入所述项目关闭状态：

通过项目决策而进入所述项目关闭状态；

通过项目拒绝状态而进入项目关闭状态；

通过项目验收状态而进入项目关闭状态。

优选的，所述已解决项目还包括当期通过项目决策和项目拒绝而变为项目关闭状态的变更项目，所述当期为指上一版本期限和下一版本期限这两个版本之间的时间间隔。

优选的，所述项目决策具体包括：

第一变更委员会决策，用于决策变更项目的后续流程包括：进入项目执行、项目推迟执行、项目拒绝、项目关闭、项目提交至第二变更委员会或者项目推迟提交至第二变更委员会状态；

第二变更委员会决策，用于决策变更项目的后续流程包括：进入项目执行、项目拒绝或项目关闭状态。

本发明提供的一种修复率计算装置，用于移动终端软件版本变更的修复率计算，所述软件版本变更的单个变更项目的流程包括：在项目提交成功时进入项目提交状态并且等待项目决策，通过项目决策而进入项目执行或项目拒绝状态，在所述项目执行并且评审合格时进入项目验收状态；

所述修复率计算装置包括：

第一数量模块，用于获得未解决项目数量，所述未解决项目包括处于所述项目提交和项目执行状态的变更项目；

第二数量模块，用于获得已解决项目数量，所述已解决项目包括处于所述项目拒绝和项目验收状态的变更项目；

计算模块，用于根据所述未解决项目数量和所述已解决项目数量获得所述移动终端软件版本变更的修复率。

优选的，所述计算模块包括：

分子单元，用于将所述已解决项目数量作为所述修复率的分子；

分母单元，用于将所述未解决项目数量与所述已解决项目数量相加之和作为所述修复率的分母；

数值单元，用于将所述分子和分母组成所述修复率的数值。

优选的，所述变更项目的流程还包括项目关闭，所述变更项目至少通过以下通道进入所述项目关闭状态：

通过项目决策而进入所述项目关闭状态；

通过项目拒绝状态而进入项目关闭状态；

通过项目验收状态而进入项目关闭状态。

优选的，所述已解决项目还包括当期通过项目决策和项目拒绝而变为项目关闭状态的变更项目，所述当期为指上一版本期限和下一版本期限这两个版本之间的时间间隔。

优选的，所述项目决策具体包括：

第一变更委员会决策，用于决策变更项目的后续流程包括：进入项目执行、项目推迟执行、项目拒绝、项目关闭、项目提交至第二变更委员会或者项目推迟提交至第二变更委员会状态；

第二变更委员会决策，用于决策变更项目的后续流程包括：进入项目执行、项目拒绝或项目关闭状态。

本发明所提供的修复率计算方法，通过获得未解决项目数量和已解决项目数量，再通过未解决项目数量和已解决项目数量来获得修复率，从而可以更准确，更真实的展示软件版本的质量，以及软件版本变更的收敛趋势。通过获得的修复率为参考指标，可以供研发和管理人员持续进行软件版本改进过程，以及质量预防监控，从而不断提升移动终端项目软件版本的整体质量，达到提升移动终端软件版本的整体用户体验和开发效率，提升产品的核心竞争力的效果。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图示出的结构获得其他的附图。

图1为实现本发明各个实施例的移动终端一个可选的硬件结构示意图；

图2为如图1所示的移动终端的无线通信系统示意图；

图3为本发明修复率计算方法采用的软件版本变更流程图；

图4为本发明修复率计算方法第一实施例的流程图；

图5为本发明修复率计算方法第二实施例的流程图；

图6为本发明修复率计算方法第三实施例的流程图；

图7为图3所示的软件版本变更流的详细流程图；

图8为本发明修复率计算装置一实施例的模块示意图；

图9为图8中所示的计算模块的模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

基于上述移动终端硬件结构以及通信系统，提出本发明方法各个实施例。

本发明修复率计算方法，用于移动终端软件版本变更的修复率计算。请参看图3，所述软件版本变更的单个变更项目的流程包括：在项目提交成功时进入项目提交状态并且等待项目决策，通过项目决策而进入项目执行或项目拒绝状态，在所述项目执行并且评审合格时进入项目验收状态。

请参看图4，本发明修复率计算方法第一实施例，所述修复率计算方法包括如下步骤：

步骤S100，获得未解决项目数量，所述未解决项目包括处于所述项目提交和项目执行状态的变更项目。

步骤S200，获得已解决项目数量，所述已解决项目包括处于所述项目拒绝和项目验收状态的变更项目。

步骤S300，根据所述未解决项目数量和所述已解决项目数量获得所述移动终端软件版本变更的修复率。其中，可以根据所述未解决项目数量和所述已解决项目数量的比值来获得修复率，从而评判软件版本的质量；也可以根据未解决项目数量的增加速度和已解决项目数量增加速度的差值来获得修复率，从而评判软件版本的质量；还可以根据已解决项目数量占总项目数量的比重来获得修复率，从而评判软件版本的质量；当然，还可以通过其他模型来展示修复率，达到评判软件版本的质量，在此不再赘述。

本实施例，通过获得未解决项目数量和已解决项目数量，再通过未解决项目数量和已解决项目数量来获得修复率，从而可以更准确，更真实的展示软件版本的质量，以及软件版本变更的收敛趋势。通过获得的修复率为参考指标，可以供研发和管理人员持续进行软件版本改进过程，以及质量预防监控，从而不断提升移动终端项目软件版本的整体质量，达到提升移动终端软件版本的整体用户体验和开发效率，提升产品的核心竞争力的效果。

请参看图5，本发明修复率计算方法第二实施例，本实施例以第一实施例为基础，对其中的步骤S300进行进一步限定。所述步骤S300“根据所述未解决项目数量和所述已解决项目数量获得所述移动终端软件版本变更的修复率”的步骤具体包括：

步骤S310，将所述已解决项目数量作为所述修复率的分子。

步骤S320，将所述未解决项目数量与所述已解决项目数量相加之和作为所述修复率的分母。

步骤S330，将所述分子和分母组成所述修复率的数值。

本实施例，通过计算已解决项目占所有已解决项目和未解决项目的比重，从而能够较准确和清楚的展示软件版本的修复率。

优选的，所述变更项目的流程还包括项目关闭，所述变更项目至少通过以下通道进入所述项目关闭状态：

通过项目决策而进入所述项目关闭状态；例如项目决策时发现该项目为重复提交项目。

通过项目拒绝状态而进入项目关闭状态；例如项目拒绝后，并没有异议，则进入项目关闭状态。

通过项目验收状态而进入项目关闭状态；例如，项目验收后，经再次验证没有异议则进入项目关闭状态。

本实施例，通过增加关闭状态，则进入关闭状态的变更项目能够得到终结，从而避免整个软件版本变更的管理系统越来越大，而导致管理效率变低。

请参看图6，本发明修复率计算方法第三实施例，本实施例以第二实施例为基础，对其中的步骤S200进行进一步限定，采用步骤S210来替换步骤S200，具体的：

步骤S210，获得已解决项目数量，所述已解决项目包括处于所述项目拒绝和项目验收状态的变更项目，以及当期通过项目决策和项目拒绝而变为项目关闭状态的变更项目；所述当期为指上一版本期限和下一版本期限这两个版本之间的时间间隔。

本实施例，通过统计当期通过项目拒绝和通过决策拒绝而进入项目关闭状态，则能够在项目关闭而减少系统负担的同时，准确的统计当期的软件版本修复率，达到较准确的展示系统质量和软件版本变更的收敛趋势。需要强调，通过项目验收状态而进入项目关闭状态的项目变更不纳入所述分子和分母的计算。

请参看图7，具体的，所述项目决策具体包括：

第一变更委员会决策，用于决策变更项目的后续流程包括：进入项目执行、项目推迟执行、项目拒绝、项目关闭、项目提交至第二变更委员会或者项目推迟提交至第二变更委员会状态。

第二变更委员会决策，用于决策变更项目的后续流程包括：进入项目执行、项目拒绝或项目关闭状态。

本实施例，通过设置第一变更委员会决策和第二变更委员会决策，则能够起到一定的项目决策纠错和项目重要性区分的效果。并且，新增“推迟”状态，也可以更适应实际研发流程，例如由于实现方面的原因(如资源短缺、发生重大故障等)，将一个需求推迟到后续版本中。本实施例中，项目推迟执行状态和项目推迟提交至第二变更委员会状态皆不纳入所述分子和分母的计算。

进一步的，所述项目执行包括项目指派和项目完成两个状态。项目指派并且指派对象同意，则指派成功，否则退回而重新指派；项目完成时如果通过评审则进入后续项目验收流程，否则重新进行项目指派流程。

本发明还提供了一种修复率计算装置，用于移动终端软件版本变更的修复率计算。

如图3所示，所述软件版本变更的单个变更项目的流程包括：在项目提交成功时进入项目提交状态并且等待项目决策，通过项目决策而进入项目执行或项目拒绝状态，在所述项目执行并且评审合格时进入项目验收状态；

请参看图8，本发明修复率计算装置一实施例。所述修复率计算装置包括：

第一数量模块400，用于获得未解决项目数量，所述未解决项目包括处于所述项目提交和项目执行状态的变更项目。

第二数量模块500，用于获得已解决项目数量，所述已解决项目包括处于所述项目拒绝和项目验收状态的变更项目。

计算模块600，用于根据所述未解决项目数量和所述已解决项目数量获得所述移动终端软件版本变更的修复率。

其中，可以根据所述未解决项目数量和所述已解决项目数量的比值来获得修复率，从而评判软件版本的质量；也可以根据未解决项目数量的增加速度和已解决项目数量增加速度的差值来获得修复率，从而评判软件版本的质量；还可以根据已解决项目数量占总项目数量的比重来获得修复率，从而评判软件版本的质量；当然，还可以通过其他模型来展示修复率，达到评判软件版本的质量，在此不再赘述。

本实施例，通过获得未解决项目数量和已解决项目数量，再通过未解决项目数量和已解决项目数量来获得修复率，从而可以更准确，更真实的展示软件版本的质量，以及软件版本变更的收敛趋势。通过获得的修复率为参考指标，可以供研发和管理人员持续进行软件版本改进过程，以及质量预防监控，从而不断提升移动终端项目软件版本的整体质量，达到提升移动终端软件版本的整体用户体验和开发效率，提升产品的核心竞争力的效果。

请参看图9，优选的，所述计算模块600包括：

分子单元，用于将所述已解决项目数量作为所述修复率的分子。

分母单元，用于将所述未解决项目数量与所述已解决项目数量相加之和作为所述修复率的分母。

数值单元，用于将所述分子和分母组成所述修复率的数值。

本实施例，通过计算已解决项目占所有已解决项目和未解决项目的比重，从而能够较准确和清楚的展示软件版本的修复率。

优选的，所述变更项目的流程还包括项目关闭，所述变更项目至少通过以下通道进入所述项目关闭状态：

通过项目决策而进入所述项目关闭状态；例如项目决策时发现该项目为重复提交项目。

通过项目拒绝状态而进入项目关闭状态；例如项目拒绝后，并没有异议，则进入项目关闭状态。

通过项目验收状态而进入项目关闭状态；例如，项目验收后，经再次验证没有异议则进入项目关闭状态。

本实施例，通过增加关闭状态，则进入关闭状态的变更项目能够得到终结，从而避免整个软件版本变更的管理系统越来越大，而导致管理效率变低。

优选的，所述已解决项目还包括当期通过项目决策和项目拒绝而变为项目关闭状态的变更项目，所述当期为指上一版本期限和下一版本期限这两个版本之间的时间间隔。

本实施例，通过统计当期通过项目拒绝和通过决策拒绝而进入项目关闭状态，则能够在项目关闭而减少系统负担的同时，准确的统计当期的软件版本修复率，达到较准确的展示系统质量和软件版本变更的收敛趋势。需要强调，通过项目验收状态而进入项目关闭状态的项目变更不纳入所述分子和分母的计算。

优选的，所述项目决策具体包括：

第一变更委员会决策，用于决策变更项目的后续流程包括：进入项目执行、项目推迟执行、项目拒绝、项目关闭、项目提交至第二变更委员会或者项目推迟提交至第二变更委员会状态。

第二变更委员会决策，用于决策变更项目的后续流程包括：进入项目执行、项目拒绝或项目关闭状态。

本实施例，通过设置第一变更委员会决策和第二变更委员会决策，则能够起到一定的项目决策纠错和项目重要性区分的效果。并且，新增“推迟”状态，也可以更适应实际研发流程，例如由于实现方面的原因(如资源短缺、发生重大故障等)，将一个需求推迟到后续版本中。本实施例中，项目推迟执行状态和项目推迟提交至第二变更委员会状态皆不纳入所述分子和分母的计算。

进一步的，所述项目执行包括项目指派和项目完成两个状态。项目指派并且指派对象同意，则指派成功，否则退回而重新指派；项目完成时如果通过评审则进入后续项目验收流程，否则重新进行项目指派流程。

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

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是移动终端，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。