一种监控软件开发过程的方法、装置、终端及存储介质

技术领域

本申请属于计算机技术领域，尤其涉及一种监控软件开发过程的方法、装置、终端及存储介质。

背景技术

软件开发过程中的质量监控很大程度决定了软件产品的质量，因此，对软件开发过程中各个流程阶段进行质量监控非常有必要。然而，现有的软件开发流程监管软件功能简单，不能准确以及全面地对软件开发过程中的所有流程阶段实现质量监控，导致开发得到的软件产品质量差。

发明内容

有鉴于此，本申请实施例提供了一种监控软件开发过程的方法、装置、终端及存储介质，以解决现有的软件开发流程监管软件功能简单，不能准确以及全面地对软件开发过程中的所有流程阶段实现质量监控，导致开发得到的软件产品质量差的问题。

本申请实施例的第一方面提供了一种监控软件开发过程的方法，包括：

获取目标软件的开发过程中每个阶段分别对应的软件质量监控模型，其中，所述每个阶段分别对应的软件质量监控模型基于每个阶段对应的预设评分指标和预设评分计算方法构建得到，所述目标软件的开发过程包括需求分析阶段、计划管理阶段、开发阶段、测试阶段以及发布阶段；

根据每个阶段分别对应的软件质量监控模型，分别对每个阶段进行质量监控，得到每个阶段分别对应的质量评分；

根据每个阶段分别对应的质量评分，确定每个阶段是否需要调整。

本申请实施例的第二方面提供了一种监控软件开发过程的装置，包括：

获取单元，用于获取目标软件的开发过程中每个阶段分别对应的软件质量监控模型，其中，所述每个阶段分别对应的软件质量监控模型基于每个阶段对应的预设评分指标和预设评分计算方法构建得到，所述目标软件的开发过程包括需求分析阶段、计划管理阶段、开发阶段、测试阶段以及发布阶段；

质量监控单元，用于根据每个阶段分别对应的软件质量监控模型，分别对每个阶段进行质量监控，得到每个阶段分别对应的质量评分；

确定单元，用于根据每个阶段分别对应的质量评分，确定每个阶段是否需要调整。

本申请实施例的第三方面提供了一种监控软件开发过程的终端，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如上述第一方面所述的监控软件开发过程的方法的步骤。

本申请实施例的第四方面提供了一种计算机存储介质，所述计算机存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面所述的监控软件开发过程的方法的步骤。

本申请实施例的第五方面提供了一种计算机程序产品，当计算机程序产品在监控软件开发过程的终端上运行时，使得监控软件开发过程的终端执行上述第一方面所述的监控软件开发过程的方法的步骤。

本申请实施例提供的一种监控软件开发过程的方法、监控软件开发过程的装置、监控软件开发过程的终端及存储介质，具有以下有益效果：

本申请实施例，根据目标软件的开发过程中每个阶段对应的不同的预设评分指标和预设评分计算方法，构建了每个阶段对应的软件质量监控模型；基于每个阶段分别对应的软件质量监控模型，对每个阶段进行质量监控，得到每个阶段分别对应的质量评分；根据每个阶段分别对应的质量评分，确定每个阶段是否需要调整。其中，目标软件的开发过程包括需求分析阶段、计划管理阶段、开发阶段、测试阶段以及发布阶段。基于该方法，对软件开发过程中的所有流程阶段都进行了质量监控，实现了对软件开发过程中的全面质量监控；且由于每个阶段对应的软件质量监控模型，都是根据每个阶段对应的不同的预设评分指标和预设评分计算方法构建而成的，基于这些软件质量监控模型对每个阶段进行质量监控时，得到的质量评分更准确，进而根据每个阶段分别对应的质量评分，对每个阶段进行适应性调整，可使最终开发出的目标软件质量好、稳定性强。

附图说明

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

图1是本申请实施例提供的一种监控软件开发过程的方法的示意流程图；

图2是本发明另一实施例提供的一种监控软件开发过程的方法的示意流程图；

图3是本发明又一实施例提供的一种监控软件开发过程的方法的示意流程图；

图4是本发明再一实施例提供的一种监控软件开发过程的方法的示意流程图；

图5是本申请一实施例提供的一种监控软件开发过程的装置的示意图；

图6是本申请另一实施例提供的一种监控软件开发过程的终端的示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

软件开发过程中的质量监控很大程度决定了软件产品的质量，因此，对软件开发过程中各个流程阶段进行质量监控非常有必要。发明人意识到，现有的软件开发流程监管软件功能简单，不能准确以及全面地对软件开发过程中的所有流程阶段实现质量监控。例如，现有技术中通常只对软件开发过程中的开发阶段和测试阶段进行质量监控；且评价的方式比较单一，比如通过软件开发过程中是否遇到缺陷以及缺陷的数量来评估，导致开发得到的软件产品质量差、稳定性弱。

有鉴于此，本申请提供了一种监控软件开发过程的方法，该方法中，根据目标软件的开发过程中每个阶段对应的不同的预设评分指标和预设评分计算方法，构建了每个阶段对应的软件质量监控模型；基于每个阶段分别对应的软件质量监控模型，对每个阶段进行质量监控，得到每个阶段分别对应的质量评分；根据每个阶段分别对应的质量评分，确定每个阶段是否需要调整。其中，目标软件的开发过程包括需求分析阶段、计划管理阶段、开发阶段、测试阶段以及发布阶段。基于该方法，对软件开发过程中的所有流程阶段都进行了质量监控，实现了对软件开发过程中的全面质量监控；且由于每个阶段对应的软件质量监控模型，都是根据每个阶段对应的不同的预设评分指标和预设评分计算方法构建而成的，基于这些软件质量监控模型对每个阶段进行质量监控时，得到的质量评分更准确，进而根据每个阶段分别对应的质量评分，对每个阶段进行适应性调整，可使最终开发出的目标软件质量好、稳定性强。

请参见图1，图1是本申请实施例提供的一种监控软件开发过程的方法的示意流程图。本实施例中监控软件开发过程的方法的执行主体为终端、服务器等，其中，终端包括但不限于智能手机、平板电脑、计算机、个人数字助理(Personal Digital Assistant，PDA)等移动终端，还可以包括台式电脑等终端。本实施例中以执行主体为终端为例进行说明，如图1所示的监控软件开发过程的方法可包括S101～S104，具体如下：

S101：获取目标软件的开发过程中每个阶段分别对应的软件质量监控模型，其中，所述每个阶段分别对应的软件质量监控模型基于每个阶段对应的预设评分指标和预设评分计算方法构建得到，所述目标软件的开发过程包括需求分析阶段、计划管理阶段、开发阶段、测试阶段以及发布阶段。

可预先将目标软件的开发过程划分为需求分析阶段、计划管理阶段、开发阶段、测试阶段以及发布阶段。目标软件就是待开发的软件，可以理解为需要经过开发得到的我们最终想要的软件。软件的开发过程，通俗的讲就是基于软件设计思路和方法对该软件进行开发的整个过程，可以包括对目标软件预先设定的需求分析、该目标软件需要实现的功能、该目标软件对应的总体结构和各个模块、开发人员的工作分配、各个模块之间如何对接、实现该目标软件的算法、每个模块对应的编码方式、不同维度的测试、测试案例、发布时间、发布时需满足的条件等。根据包括的这些信息将目标软件的开发过程划分为需求分析阶段、计划管理阶段、开发阶段、测试阶段以及发布阶段。值得说明的是，不同的软件其对应的开发过程不同，最后划分得到的需求分析阶段、计划管理阶段、开发阶段、测试阶段、发布阶段这些阶段具体对应的内容也有可能不同。此处仅为示例性说明，对此不做限定。

可选地，在一种可能的实现方式中，可以根据开发人员的经验对目标软件的开发过程进行划分，也可以是开发人员将目标软件的开发过程对应的各个阶段的文档上传至终端，终端识别各个阶段的文档，即识别需求分析阶段、计划管理阶段、开发阶段、测试阶段以及发布阶段各自对应的文档，实现对目标软件的开发过程的划分。此处仅为示例性说明，对此不做限定。

每个阶段具体的开发方式不一样，相应地，每个阶段对应的软件质量监控模型也不同。可预先根据每个阶段对应的预设评分指标和预设评分计算方法，构建得到每个阶段分别对应的软件质量监控模型。其中，每个阶段对应的预设评分指标和预设评分计算方法均不相同。

示例性地，根据需求分析阶段对应的第一预设评分指标和第一预设评分计算方法，构建需求分析阶段对应的第一软件质量监控模型。第一预设评分指标包括：需求确认、需求文档、需求评审。其中，需求确认包括：开发之前完成是否大于50％的需求确认、开发至整个开发周期的一半之前是否完成大于50％的需求确认。需求文档包括：是否有明确的需求文档。需求评审包括：是否进行需求评审、是否测试参与需求评审。该需求分析阶段对应的总的质量评分，可根据实际情况进行调整，本实施例中，需求分析阶段对应的总的质量评分为20分，其中，需求确认对应10分，需求文档对应5分，需求评审对应5分。此处仅为示例性说明，对此不做限定。

第一预设评分计算方法包括：开发之前完成大于50％的需求确认，对应的评分为该项评分的满分，例如5分；开发之前完成20％～50％的需求确认，对应的评分为该项评分的一半，例如2.5分；开发之前完成小于20％的需求确认，对应的评分为零分，例如0分；开发至整个开发周期的一半之前完成大于50％的需求确认，对应的评分为该项评分的满分，例如5分；开发至整个开发周期的一半之前完成20％～50％的需求确认，对应的评分为该项评分的一半，例如2.5分；开发至整个开发周期的一半之前完成小于20％的需求确认，对应的评分为零分，例如0分。

第一预设评分计算方法还包括：有明确的需求文档，对应的评分为该项评分的满分，例如5分；没有明确的需求文档，对应的评分为零分，例如0分。

第一预设评分计算方法还包括：进行需求评审，对应的评分为2分；不进行需求评审，对应的评分为0分；测试参与需求评审，对应的评分为3分；测试不参与需求评审，对应的评分为3分。

根据上述列举出的第一预设评分指标和第一预设评分计算方法，构建得到需求分析阶段对应的第一软件质量监控模型。可根据该第一软件质量监控模型对目标软件的需求分析阶段进行质量监控。此处仅为示例性说明，对此不做限定。

示例性地，根据计划管理阶段对应的第二预设评分指标和第二预设评分计算方法，构建计划管理阶段对应的第二软件质量监控模型。第二预设评分指标包括：目标软件开发的版本计划合理性、故事(story)拆分合理性、story移交合理性。其中，目标软件开发的版本计划合理性包括：版本计划是否提前制定、是否有story的分期移交计划、测试是否参与分期移交计划制定、分期移交计划是否合理。story拆分合理性包括：story是否和线下拆分一致、story的拆分是否按照业务逻辑而不是按照(人头)任务分派、story是否拆分足够细。story移交合理性包括：Story是否按时移交、复杂功能移交后是否有充足的测试时间。该计划管理阶段对应的总的质量评分，可根据实际情况进行调整，本实施例中，计划管理阶段对应的总的质量评分为20分，其中，目标软件开发的版本计划合理性对应10分，story拆分合理性对应5分，story移交合理性对应5分。此处仅为示例性说明，对此不做限定。

第二预设评分计算方法包括：版本计划提前制定，对应的评分为2分，版本计划未提前制定，对应的评分为0分；有story的分期移交计划，对应的评分为3分，没有story的分期移交计划，对应的评分为0分；测试参与分期移交计划制定，对应的评分为2分，测试不参与分期移交计划制定，对应的评分为0分；分期移交计划合理，对应的评分为3分，分期移交计划不合理，对应的评分为0分。

第二预设评分计算方法还包括：story和线下拆分一致，对应的评分为2分；story和线下拆分不一致，对应的评分为0分；story的拆分按照业务逻辑而不是按照(人头)任务分派，对应的评分为2分；story的拆分按照(人头)任务分派，对应的评分为0分；story是否拆分按个数比例计算，对应的评分为预设常数与比例的乘积(例如统计得到没有超过3天的story比率为40％，对应的评分为6*0.4＝2.4分)。

第二预设评分计算方法还包括：Story全部按时移交，对应的分数为2分；Story部分按时移交，对应的评分为移交比例与2(2为Story全部按时移交时对应的分数)的乘积；复杂功能移交后有充足的测试时间，对应的分数为3分；复杂功能移交后没有充足的测试时间，对应的分数为0分。其中，当复杂功能移交后还有大于或等于整个开发周期30％的时间作为测试时间，判定复杂功能移交后有充足的测试时间；当复杂功能移交后还有小于整个开发周期30％的时间作为测试时间，判定复杂功能移交后没有充足的测试时间。

根据上述列举出的第二预设评分指标和第二预设评分计算方法，构建得到计划管理阶段对应的第二软件质量监控模型。可根据该第二软件质量监控模型对目标软件的计划管理阶段进行质量监控。此处仅为示例性说明，对此不做限定。

示例性地，根据开发阶段对应的第三预设评分指标和第三预设评分计算方法，构建开发阶段对应的第三软件质量监控模型。第三预设评分指标包括：开发设计、开发合规性。其中，开发设计包括：是否进行设计评审、是否交付详细的测试设计文档；开发合规性包括：是否有夹带修改、是否人为控制缺陷数量。该开发阶段对应的总的质量评分，可根据实际情况进行调整，本实施例中，开发阶段对应的总的质量评分为20分，其中，开发设计对应10分，开发合规性对应5分。此处仅为示例性说明，对此不做限定。

第三预设评分计算方法包括：进行设计评审，对应的分数为5分；不进行设计评审，对应的分数为0分；交付详细的测试设计文档，对应的分数为5分；未交付详细的测试设计文档，对应的分数为0分。

第三预设评分计算方法还包括：有夹带修改，对应的分数为5分；没有夹带修改，对应的分数为0分；人为控制缺陷数量，对应的分数为5分；非人为控制缺陷数量，对应的分数为0分。

根据上述列举出的第三预设评分指标和第三预设评分计算方法，构建得到开发阶段对应的第三软件质量监控模型。可根据该第三软件质量监控模型对目标软件的开发阶段进行质量监控。此处仅为示例性说明，对此不做限定。

示例性地，根据测试阶段对应的第四预设评分指标和第四预设评分计算方法，构建测试阶段对应的第四软件质量监控模型。第四预设评分指标包括：是否有测试案例评审环节、是否有测试进度报告、是否有用户验收测试(User Acceptance Test，UAT)进入通知、是否有UAT验收结果、是否准时完成系统测试、是否准时进行软件封板。该测试阶段对应的总的质量评分，可根据实际情况进行调整，本实施例中，测试阶段对应的总的质量评分为20分。此处仅为示例性说明，对此不做限定。

第四预设评分计算方法包括：有测试案例评审环节，对应的分数为2分；没有测试案例评审环节，对应的分数为0分；有测试进度报告，对应的分数为2分；没有测试进度报告，对应的分数为0分；有用户验收测试UAT进入通知，对应的分数为1分；没有用户验收测试UAT进入通知，对应的分数为0分；有UAT验收结果，对应的分数为1分；没有UAT验收结果，对应的分数为0分；准时完成系统测试，对应的分数为7分；不能准时完成系统测试，对应的分数为0分；准时进行软件封板，对应的分数为7分；不能准时进行软件封板，对应的分数为0分。

根据上述列举出的第四预设评分指标和第四预设评分计算方法，构建得到测试阶段对应的第四软件质量监控模型。可根据该第四软件质量监控模型对目标软件的测试阶段进行质量监控。此处仅为示例性说明，对此不做限定。

示例性地，根据发布阶段对应的第五预设评分指标和第五预设评分计算方法，构建发布阶段对应的第五软件质量监控模型。第五预设评分指标包括：目标软件对应的缺陷密度、目标软件对应的缺陷比例、是否冒烟通过、缺陷重修个数。该发布阶段对应的总的质量评分，可根据实际情况进行调整，本实施例中，发布阶段对应的总的质量评分为20分。此处仅为示例性说明，对此不做限定。

第五预设评分计算方法包括：缺陷密度小于或等于0.1，对应的分数为5分；缺陷密度大于0.1，且小于或等于0.2，对应的分数为2.5分；缺陷密度大于0.2，对应的分数为0分。缺陷比例小于或等于5％，对应的分数为5分；缺陷比例大于5％，且小于或等于20％，对应的分数为2.5分；缺陷比例大于20％，对应的分数为0分。是否冒烟通过，对应的分数为正常移交个数的比率与分数5的乘积。缺陷重修个数为0，对应的分数为5分；缺陷重修个数小于或等于5，对应的分数为2.5分；缺陷重修个数大于5，对应的分数为0分。

根据上述列举出的第五预设评分指标和第五预设评分计算方法，构建得到发布阶段对应的第五软件质量监控模型。可根据该第五软件质量监控模型对目标软件的发布阶段进行质量监控。此处仅为示例性说明，对此不做限定。

终端获取每个阶段分别对应的软件质量监控模型。即终端获取需求分析阶段对应的第一软件质量监控模型、计划管理阶段对应的第二软件质量监控模型、开发阶段对应的第三软件质量监控模型、测试阶段对应的第四软件质量监控模型以及发布阶段对应的第五软件质量监控模型。

S102：根据每个阶段分别对应的软件质量监控模型，分别对每个阶段进行质量监控，得到每个阶段分别对应的质量评分。

基于每个阶段对应的不同的软件质量监控模型，分别对每个阶段进行质量监控。示例性地，采集目标软件在开发至每个阶段时所产生的数据，通过每个阶段对应的软件质量监控模型中的预设评分指标和预设评分计算方法，对每个阶段产生的数据进行评分，得到每个阶段分别对应的质量评分。其中，采集目标软件在开发至每个阶段时所产生的数据，可以是开发人员上传的目标软件在开发至每个阶段时所产生的数据，也可以是在实际开发过程中，该目标软件在开发至每个阶段时所产生的数据。此处仅为示例性说明，对此不做限定。

请参见图2，图2是本发明另一实施例提供的一种监控软件开发过程的方法的示意流程图。可选地，在一种可能的实现方式中，如图2所示，上述S102可以包括S1021～S1022，具体如下：

S1021：采集所述目标软件在开发至第一阶段时产生的目标数据，所述第一阶段为所述每个阶段中的任一阶段。

S1022：基于所述第一阶段对应的软件质量监控模型中的预设评分指标和预设评分计算方法，对所述目标数据进行评分，得到所述第一阶段对应的质量评分。

每个阶段指的就是目标软件的开发过程中的需求分析阶段、计划管理阶段、开发阶段、测试阶段以及发布阶段。第一阶段可以依次为需求分析阶段、计划管理阶段、开发阶段、测试阶段以及发布阶段。

可预先获取目标软件对应的版本信息，基于该版本信息确定该目标软件目前处于哪个阶段。例如，可通过调用应用程序接口(Application Programming Interface，API)和/或预设的缺陷管理系统，自动获取到该目标软件对应的版本信息，该版本信息用于指示该目标软件目前处于哪个阶段。此处仅为示例性说明，对此不做限定。

示例性地，当第一阶段为需求分析阶段时，采集目标软件在开发至需求分析阶段时产生的目标数据。例如，该目标软件在需求分析阶段开发人员上传了需求确认进度文件、需求文档、需求评审请求，此时采集到的目标数据可以包括：需求确认进度文件、需求文档、需求评审请求。

根据需求分析阶段对应的第一软件质量监控模型中的第一预设评分指标和第一预设评分计算方法，对该目标数据进行评分。例如，根据需求确认进度文件中需求确认实际完成的情况，为该项进行打分。如根据该需求确认进度文件，只确定开发之前完成了大于50％的需求确认，对应的评分为5分。又例如，检测到需求文档中都为明确的需求，对应的评分为5分。目标数据中包含需求评审请求，该项对应的评分为5分。

对目标数据进行评分后，将每条数据对应的分数相加，得到需求分析阶段对应的质量评分。例如，将需求确认进度文件对应的5分、需求文档对应的5分以及需求评审请求对应的5分相加，得到15分，则需求分析阶段对应的质量评分为15分。此处仅为示例性说明，对此不做限定。

示例性地，当第一阶段为计划管理阶段时，采集目标软件在开发至计划管理阶段时产生的目标数据。例如，该目标软件在计划管理阶段开发人员上传了版本计划合理性文档、story拆分合理性文档、story移交合理性文档，此时采集到的目标数据可以包括：版本计划合理性文档、story拆分合理性文档、story移交合理性文档。其中，版本计划合理性文档包括版本计划提前制定、测试参与分期移交计划制定、分期移交计划合理。story拆分合理性文档包括story的拆分按照(人头)任务分派、story和线下拆分一致、没有超过3天的story比率为40％。story移交合理性文档包括Story全部按时移交、复杂功能移交后还有大于或等于整个开发周期30％的时间作为测试时间。

根据计划管理阶段对应的第二软件质量监控模型中的第二预设评分指标和第二预设评分计算方法，对该目标数据进行评分。例如，基于第二预设评分指标和第二预设评分计算方法，对版本计划提前制定评分为2分；没检测到story的分期移交计划，对应的评分为0分；测试参与分期移交计划制定，对应的评分为2分；story和线下拆分一致，对应的评分为2分；story的拆分按照(人头)任务分派，对应的评分为0分；没有超过3天的story比率为40％，对应的评分为6*0.4＝2.4分；Story全部按时移交，对应的分数为2分；复杂功能移交后还有大于或等于整个开发周期30％的时间作为测试时间，判定复杂功能移交后有充足的测试时间，对应的分数为3分。

对目标数据进行评分后，将每条数据对应的分数相加，得到计划管理阶段对应的质量评分。例如，将上述计划管理阶段对应的目标数据中各个数据的分数相加得到13.4分，即计划管理阶段对应的质量评分为13.4分。此处仅为示例性说明，对此不做限定。

示例性地，当第一阶段为开发阶段时，采集目标软件在开发至开发阶段时产生的目标数据。例如，采集到该开发阶段对应的目标数据包括：进行设计评审信息、详细的测试设计文档、有夹带修改、非人为控制缺陷数量。

根据开发阶段对应的第三软件质量监控模型中的第三预设评分指标和第三预设评分计算方法，对该目标数据进行评分。例如，基于第三预设评分指标和第三预设评分计算方法，对进行设计评审信息评分为5分；检测到详细的测试设计文档，对应的分数为5分；检测到有夹带修改，对应的分数为5分；检测到非人为控制缺陷数量，对应的分数为0分。

对目标数据进行评分后，将每条数据对应的分数相加，得到开发阶段对应的质量评分。例如，将上述开发阶段对应的目标数据中各个数据的分数相加得到15分，即开发对应的质量评分为15分。此处仅为示例性说明，对此不做限定。

示例性地，当第一阶段为测试阶段时，采集目标软件在开发至测试阶段时产生的目标数据。例如，采集到该测试阶段对应的目标数据包括：测试案例评审环节信息、测试进度报告、UAT验收结果、完成系统测试的时间、进行软件封板的时间。

根据测试阶段对应的第四软件质量监控模型中的第四预设评分指标和第四预设评分计算方法，对该目标数据进行评分。例如，基于第四预设评分指标和第四预设评分计算方法，对检测到的测试案例评审环节信息评分为2分；检测到测试进度报告，对应的分数为2分；未检测到用户验收测试UAT进入通知，对应的分数为0分；检测到UAT验收结果，对应的分数为1分；检测完成系统测试的时间在预设的完成时间内，对应的分数为7分；检测进行软件封板的时间未在预设的封板时间内，对应的分数为0分。

对目标数据进行评分后，将每条数据对应的分数相加，得到测试阶段对应的质量评分。例如，将上述测试阶段对应的目标数据中各个数据的分数相加得到12分，即开发对应的质量评分为12分。此处仅为示例性说明，对此不做限定。

示例性地，当第一阶段为发布阶段时，采集目标软件在开发至发布阶段时产生的目标数据。例如，采集到该发布阶段对应的目标数据包括：缺陷密度为0.15、目标软件对应的缺陷比例10％、正常移交个数的比率0.6、缺陷重修个数3。

根据发布阶段对应的第五软件质量监控模型中的第五预设评分指标和第五预设评分计算方法，对该目标数据进行评分。例如，基于第五预设评分指标和第五预设评分计算方法，对缺陷密度0.15评分为2.5分；目标软件对应的缺陷比例10％，对应的分数为2.5分；正常移交个数的比率0.6，对应的分数为5*0.6＝3分；缺陷重修个数3，对应的分数为2.5分。

对目标数据进行评分后，将每条数据对应的分数相加，得到发布阶段对应的质量评分。例如，将上述发布阶段对应的目标数据中各个数据的分数相加得到10.5分，即开发对应的质量评分为10.5分。此处仅为示例性说明，对此不做限定。

S103：根据每个阶段分别对应的质量评分，确定每个阶段是否需要调整。

可以预先设置每个阶段对应的不同的预设阈值，每个阶段对应的预设阈值用于判断每个阶段对应的质量评分是否达标，进而判断每个阶段是否需要调整。

当某个阶段需要调整时，以该阶段的目标数据中各个数据对应的分数为依据，对该阶段进行调整。例如，某个数据对应分数低，影响了该阶段总体的质量评分，则对该数据对应的事项进行相应的调整。此处仅为示例性说明，对此不做限定。

请参见图3，图3是本发明又一实施例提供的一种监控软件开发过程的方法的示意流程图。可选地，在一种可能的实现方式中，如图3所示，上述S103可以包括S1031～S1033，值得说明的是，S1032与S1033并列，根据质量评分与预设阈值的比较结果，确定S1031后执行S1032还是S1033，而并非在S1032后执行S1033，具体如下：

S1031：获取所述第一阶段对应的质量评分。

S1032：当检测到所述质量评分小于预设阈值时，确定所述第一阶段需要调整。或，S1033：当检测到所述质量评分大于或等于所述预设阈值时，确定所述第一阶段不需要调整。

示例性地，当第一阶段为需求分析阶段时，获取该需求分析阶段对应的第一预设阈值，该第一预设阈值用于判断需求分析阶段对应的质量评分是否达标，进而判断需求分析阶段是否需要调整。第一预设阈值可根据不同的目标软件进行调整，例如，第一预设阈值可以为12分，获取该需求分析阶段对应的质量评分为15分。

比较需求分析阶段对应的质量评分15分与第一预设阈值12分的大小，显然，需求分析阶段对应的质量评分大于第一预设阈值，确定需求分析阶段不需要调整。此处仅为示例性说明，对此不做限定。

示例性地，当第一阶段为计划管理阶段时，获取该计划管理阶段对应的第二预设阈值，该第二预设阈值用于判断计划管理阶段对应的质量评分是否达标，进而判断计划管理阶段是否需要调整。第二预设阈值可根据不同的目标软件进行调整，例如，第二预设阈值可以为15分，获取该计划管理阶段对应的质量评分为13.4分。

比较计划管理阶段对应的质量评分13.4分与第二预设阈值15分的大小，显然，计划管理阶段对应的质量评分小于第二预设阈值，确定计划管理阶段需要调整。此处仅为示例性说明，对此不做限定。

示例性地，当第一阶段为开发阶段时，获取该开发阶段对应的第三预设阈值，该第三预设阈值用于判断开发阶段对应的质量评分是否达标，进而判断开发阶段是否需要调整。第三预设阈值可根据不同的目标软件进行调整，例如，第三预设阈值可以为14分，获取该开发阶段对应的质量评分为15分。

比较开发阶段对应的质量评分15分与第三预设阈值14分的大小，显然，开发阶段对应的质量评分大于第三预设阈值，确定开发阶段不需要调整。此处仅为示例性说明，对此不做限定。

示例性地，当第一阶段为测试阶段时，获取该测试阶段对应的第四预设阈值，该第四预设阈值用于判断测试阶段对应的质量评分是否达标，进而判断测试阶段是否需要调整。第四预设阈值可根据不同的目标软件进行调整，例如，第四预设阈值可以为15分，获取该开发阶段对应的质量评分为12分。

比较测试阶段对应的质量评分12分与第四预设阈值15分的大小，显然，开发阶段对应的质量评分小于第四预设阈值，确定测试阶段需要调整。此处仅为示例性说明，对此不做限定。

示例性地，当第一阶段为发布阶段时，获取该发布阶段对应的第五预设阈值，该第五预设阈值用于判断发布阶段对应的质量评分是否达标，进而判断发布阶段是否需要调整。第五预设阈值可根据不同的目标软件进行调整，例如，第五预设阈值可以为10分，获取该开发阶段对应的质量评分为10.5分。

比较发布阶段对应的质量评分10.5分与第五预设阈值10分的大小，显然，发布阶段对应的质量评分大于第五预设阈值，确定发布阶段不需要调整。此处仅为示例性说明，对此不做限定。

可选地，在一种可能的实现方式中，当确定第一阶段需要调整时，该方法还可包括：基于预设规则对第一阶段进行调整；基于第一阶段对应的软件质量监控模型，对调整后的第一阶段进行质量监控，得到调整后的第一阶段对应的质量评分。

预设规则可以为检测影响该第一阶段对应的质量评分的主要数据，即对该第一阶段对应的质量评分影响较大的数据，对该数据进行相应调整。例如，第一阶段中某个数据对应的评分为0，该数据就为影响第一阶段对应的质量评分的主要数据。再具体分析评分为0的原因，根据不同的原因，采取不同的调整方式。若是缺少该数据，则补交该数据；若是该数据设置不合理，则重新设置该数据。此处仅为示例性说明，对此不做限定。

沿用S103中的例子，根据S103中的描述可得知，第一阶段为计划管理阶段时需要调整，第一阶段为测试阶段时需要调整。

示例性地，以第一阶段为计划管理阶段为例进行说明，计划管理阶段时需要调整，该计划管理阶段对应的质量评分为13.4分。通过S1022中的描述可知，该计划管理阶段没检测到story的分期移交计划，此数据对应的评分为0分；story的拆分按照(人头)任务分派，此数据对应的评分为0分。主要是这两项影响了该计划管理阶段对应的质量评分。因此，在对计划管理阶段进行调整时，可从这两个方面入手。例如，提交story的分期移交计划，story的拆分按照业务逻辑分派。此处仅为示例性说明，对此不做限定。

基于计划管理阶段对应的第二软件质量监控模型，对调整后的计划管理阶段再次进行质量监控，得到调整后的计划管理阶段对应的质量评分。例如，获取调整后的计划管理阶段对应的目标数据，根据计划管理阶段对应的第二软件质量监控模型中的第二预设评分指标和第二预设评分计算方法，对调整后的计划管理阶段对应的目标数据进行评分，得到调整后的计划管理阶段对应的质量评分。示例性地，调整后的计划管理阶段对应的目标数据中包含story的分期移交计划，此数据对应的分数为3分；story的拆分按照业务逻辑分派，此数据对应的分数为2分；其余各个数据对应的评分过程可参考S1032中的相关描述，此处不再赘述。

由上述可知，未调整前的计划管理阶段对应的质量评分为13.4分，调整后的计划管理阶段对应的质量评分为18.4分。可选地，在一种可能实现的方式中，可再次比较调整后的计划管理阶段对应的质量评分18.4分与第二预设阈值15分的大小，显然，计划管理阶段对应的质量评分大于第二预设阈值，确定调整后的计划管理阶段达标，不需要再次调整。若再次比较得到的结果还是计划管理阶段需要调整，则再次对调整后的计划管理阶段进行二次调整，直至计划管理阶段达标，不需要调整为止。此处仅为示例性说明，对此不做限定。

示例性地，以第一阶段为测试阶段为例进行说明，测试阶段需要调整，该测试阶段对应的质量评分为12分。通过S1022中的描述可知，该测试阶段进行软件封板的时间未在预设的封板时间内，对应的分数为0分。主要是这项影响了该测试阶段对应的质量评分。因此，在对测试阶段进行调整时，可从这个方面入手。例如，将软件封板的时间提前，使软件封板的时间在预设的封板时间内。

基于测试阶段对应的第四软件质量监控模型，对调整后的测试阶段再次进行质量监控，得到调整后的测试阶段对应的质量评分。例如，获取调整后的测试阶段对应的目标数据，根据测试阶段对应的第四软件质量监控模型中的第四预设评分指标和第四预设评分计算方法，对调整后的测试阶段对应的目标数据进行评分，得到调整后的测试阶段对应的质量评分。示例性地，调整后的测试阶段对应的目标数据中将软件封板的时间提前，使软件封板的时间在预设的封板时间内，即进行软件封板的时间在预设的封板时间内，此数据对应的分数为7分。其余各个数据对应的评分过程可参考S1022中的相关描述，此处不再赘述。

由上述可知，未调整前的测试阶段对应的质量评分为12分，调整后的测试阶段对应的质量评分为19分。可选地，在一种可能实现的方式中，可再次比较调整后的测试阶段对应的质量评分19分与第四预设阈值15分的大小，显然，调整后的测试阶段对应的质量评分大于第四预设阈值，确定调整后的测试阶段达标，不需要再次调整。若再次比较得到的结果还是测试阶段需要调整，则再次对调整后的测试阶段进行二次调整，直至测试阶段达标，不需要调整为止。此处仅为示例性说明，对此不做限定。

可选地，在一种可能实现的方式中，监控软件开发过程的方法还可包括：确定每个阶段对应的最终质量评分，当第一阶段需要调整时，最终质量评分为调整后的第一阶段对应的质量评分，当第一阶段不需要调整时，最终质量评分为未调整的第一阶段对应的质量评分；基于每个阶段对应的最终质量评分，计算目标软件对应的总体质量评分；当检测到总体质量评分大于或等于预设质量阈值时，生成目标软件对应的合格报告。当检测到总体质量评分小于预设质量阈值时，生成邮件信息，邮件信息用于提醒开发人员目标软件的开发过程不合格。

示例性地，由于每个阶段可能会需要调整，也可能不需要调整，因此，每个阶段对应的最终质量评分有所不同。还是以第一阶段进行表述，第一阶段为需求分析阶段、计划管理阶段、开发阶段、测试阶段以及发布阶段中的任一阶段。当第一阶段需要调整时，此时第一阶段对应的最终质量评分为调整后的第一阶段对应的质量评分，由于可能会调整多次，这里得调整后指的是最后一次调整，也可以理解为该第一阶段对应的质量评分达标时，此时第一阶段对应的质量评分即为该第一阶段对应的最终质量评分。

当第一阶段不需要调整时，此时第一阶段对应的最终质量评分为未调整的第一阶段对应的质量评分，即第一次采用该第一阶段对应的软件质量监控模型对第一阶段进行质量监控时，得到的第一阶段对应的质量评分。

例如，当第一阶段为需求分析阶段时，该需求分析阶段不需要调整，则需求分析阶段对应的最终质量评分为最初的质量评分15分。当第一阶段为计划管理阶段时，该计划管理阶段需要调整，则计划管理阶段对应的最终质量评分，为调整后的计划管理阶段对应的的质量评分18.4分。当第一阶段为开发阶段时，该开发阶段不需要调整，则开发阶段对应的最终质量评分为最初的质量评分15分。当第一阶段为测试阶段时，该测试阶段需要调整，则测试阶段对应的最终质量评分，为调整后的测试阶段对应的的质量评分19分。当第一阶段为发布阶段时，该发布阶段不需要调整，则发布阶段对应的最终质量评分为最初的质量评分10.5分。此处仅为示例性说明，对此不做限定。

将每个阶段对应的最终质量评分相加，得到的评分即为目标软件对应的总体质量评分。例如，将需求分析阶段对应的最终质量评分15分、计划管理阶段对应的最终质量评分18.4分、开发阶段对应的最终质量评分15分、测试阶段对应的最终质量评分19分、发布阶段对应的最终质量评分10.5分相加，得到目标软件对应的总体质量评分77.9分。此处仅为示例性说明，对此不做限定。

预设质量阈值用于判断目标软件对应的总体质量评分是否达标，即判断该目标软件的开发过程是否合格。预设质量阈值可根据不同的目标软件进行调整，例如，预设质量阈值可以为75分、85分、90分等，此处仅为示例性说明，对此不做限定。

示例性地，比较目标软件对应的总体质量评分与预设质量阈值的大小。当预设质量阈值为75分时，显然，目标软件对应的总体质量评分77.9分大于预设质量阈值75分，此时生成目标软件对应的合格报告。该合格报告用于表示该目标软件的开发过程合格了，即按照该开发过程中的每个阶段开发该目标软件，最终得到的目标软件是合格的。该合格报告可以包括该目标软件每个阶段对应的目标数据、每个阶段对应的质量评分、各个数据单独对应的质量评分、目标软件对应的总体质量评分等。此处仅为示例性说明，对此不做限定。

当预设质量阈值为85分时，显然，目标软件对应的总体质量评分77.9分小于预设质量阈值85分，此时生成邮件信息，该邮件信息用于提醒开发人员目标软件的开发过程不合格。即按照该开发过程中的每个阶段开发该目标软件，最终得到的目标软件是不合格的。开发人员在收到该邮件信息时，可以对该目标软件的整个开发过程进行审核，对每个阶段进行单独调整和/或调整每个阶段对应的预设阈值等，此处仅为示例性说明，对此不做限定。

当对每个阶段进行单独调整和/或调整每个阶段对应的预设阈值后，可再次通过本申请提供的监控软件开发过程的方法，对新的一轮的目标软件的开发过程进行质量监控，具体的监控过程不再赘述。

可选地，在一种可能实现的方式中，可在对每个阶段进行质量监控后，生成每个阶段对应的邮件，并将该邮件发送给开发人员，可及时提醒开发人员当前目标软件的开发进度，以及每个阶段的开发质量，便于开发人员及时进行调整，进而保证最后开发得到的目标软件质量好、稳定性强，实现了软件开发过程中的预警。

可选地，在一种可能实现的方式中，在目标软件开发前，邮件提醒开发人员，上传需求分析阶段需要用到的需求确认进度文件、需求文档、需求评审请求等信息。在目标软件对应的开发阶段，邮件提醒开发人员发送测试进度报告、UAT验收结果等，终端检测到这些数据后，可对通过第四软件质量监控模型对这些数据进行评分。

可选地，在一种可能实现的方式中，可根据每个阶段未调整前对应的质量评分、目标软件对应的总体质量评分、各个数据对应的单项评分、调整后的每个阶段对应的质量评分等，生成对比图、趋势图等。示例性地，将这些信息上传至预设的易绘图表系统，该易绘图表系统可根据这些信息生成目标软件对应的总体对比图、总体雷达图、总体趋势图，以及按照各个阶段生成的每个阶段对应的雷达图、趋势图、对比图。此处仅为示例性说明，对此不做限定。

本申请实施例中，根据目标软件的开发过程中每个阶段对应的不同的预设评分指标和预设评分计算方法，构建了每个阶段对应的软件质量监控模型；基于每个阶段分别对应的软件质量监控模型，对每个阶段进行质量监控，得到每个阶段分别对应的质量评分；根据每个阶段分别对应的质量评分，确定每个阶段是否需要调整。其中，目标软件的开发过程包括需求分析阶段、计划管理阶段、开发阶段、测试阶段以及发布阶段。基于该方法，对软件开发过程中的所有流程阶段都进行了质量监控，实现了对软件开发过程中的全面质量监控；且由于每个阶段对应的软件质量监控模型，都是根据每个阶段对应的不同的预设评分指标和预设评分计算方法构建而成的，基于这些软件质量监控模型对每个阶段进行质量监控时，得到的质量评分更准确，进而根据每个阶段分别对应的质量评分，对每个阶段进行适应性调整，可使最终开发出的目标软件质量好、稳定性强。且本方法通过每个阶段分别对应的软件质量监控模型，自动对每个阶段进行质量监控，开发人员不必再时刻盯着，使开发人员可以去做更多的其他工作，解放了开发人员的双手，侧面节省了开发软件的成本，提升了开发软件的效率、质量。

请参见图4，图4是本发明再一实施例提供的一种监控软件开发过程的方法的示意流程图。该方法可以包括S201～S204。其中，图4所示的步骤S201～S203可以参考图1对应的实施例中S101～S103的相关描述，为了简洁，这里不再赘述。下面将具体对步骤S204进行说明。

S204：将每个阶段分别对应的软件质量监控模型上传至区块链中。

将每个阶段阶段分别对应的软件质量监控模型上传至区块链中，即将需求分析阶段对应的第一软件质量监控模型、计划管理阶段对应的第二软件质量监控模型、开发阶段对应的第三软件质量监控模型、测试阶段对应的第四软件质量监控模型以及发布阶段对应的第五软件质量监控模型，分别上传至区块链中。

在本实施例中，将每个阶段分别对应的软件质量监控模型上传至区块链中，可保证其安全性和对用户的公正透明性。且将每个阶段分别对应的软件质量监控模型上传至区块链中，借助区块链上文件无法随意篡改的特性，能够避免每个阶段分别对应的软件质量监控模型被恶意篡改，便于后续用户可直接准确地获取到每个阶段分别对应的软件质量监控模型，也便于后续用户使用每个阶段分别对应的软件质量监控模型对目标软件的开发过程进行质量监控。

本示例所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。

请参见图5，图5是本申请一实施例提供的一种监控软件开发过程的装置的示意图。该装置包括的各单元用于执行图1～图4对应的实施例中的各步骤。具体请参阅图1～图4各自对应的实施例中的相关描述。为了便于说明，仅示出了与本实施例相关的部分。参见图5，包括：

获取单元310，用于获取目标软件的开发过程中每个阶段分别对应的软件质量监控模型，其中，所述每个阶段分别对应的软件质量监控模型基于每个阶段对应的预设评分指标和预设评分计算方法构建得到，所述目标软件的开发过程包括需求分析阶段、计划管理阶段、开发阶段、测试阶段以及发布阶段；

质量监控单元320，用于根据每个阶段分别对应的软件质量监控模型，分别对每个阶段进行质量监控，得到每个阶段分别对应的质量评分；

确定单元330，用于根据每个阶段分别对应的质量评分，确定每个阶段是否需要调整。

可选地，所述质量监控单元320具体用于：

采集所述目标软件在开发至第一阶段时产生的目标数据，所述第一阶段为所述每个阶段中的任一阶段；

基于所述第一阶段对应的软件质量监控模型中的预设评分指标和预设评分计算方法，对所述目标数据进行评分，得到所述第一阶段对应的质量评分。

可选地，所述确定单元330具体用于：

获取所述第一阶段对应的质量评分；

当检测到所述质量评分小于预设阈值时，确定所述第一阶段需要调整；或，

当检测到所述质量评分大于或等于所述预设阈值时，确定所述第一阶段不需要调整。

可选地，所述装置还包括：

调整单元，用于基于预设规则对所述第一阶段进行调整；

评分单元，用于基于所述第一阶段对应的软件质量监控模型，对调整后的第一阶段进行质量监控，得到所述调整后的第一阶段对应的质量评分。

可选地，所述装置还包括：

评分确定单元，用于确定每个阶段对应的最终质量评分，当所述第一阶段需要调整时，所述最终质量评分为调整后的第一阶段对应的质量评分，当所述第一阶段不需要调整时，所述最终质量评分为未调整的第一阶段对应的质量评分；

计算单元，用于基于每个阶段对应的最终质量评分，计算所述目标软件对应的总体质量评分；

第一生成单元，用于当检测到所述总体质量评分大于或等于预设质量阈值时，生成所述目标软件对应的合格报告

可选地，所述装置还包括：

第二生成单元，用于当检测到所述总体质量评分小于所述预设质量阈值时，生成邮件信息，所述邮件信息用于提醒开发人员所述目标软件的开发过程不合格。

可选地，所述装置还包括：

上传单元，用于将每个阶段分别对应的软件质量监控模型上传至区块链中。

请参见图6，图6是本申请另一实施例提供的一种监控软件开发过程的终端的示意图。如图6所示，该实施例的监控软件开发过程的终端4包括：处理器40、存储器41以及存储在所述存储器41中并可在所述处理器40上运行的计算机指令42。所述处理器40执行所述计算机指令42时实现上述各个监控软件开发过程的方法实施例中的步骤，例如图1所示的S101至S103。或者，所述处理器40执行所述计算机指令42时实现上述各实施例中各单元的功能，例如图5所示单元310至330功能。

示例性地，所述计算机指令42可以被分割成一个或多个单元，所述一个或者多个单元被存储在所述存储器41中，并由所述处理器40执行，以完成本申请。所述一个或多个单元可以是能够完成特定功能的一系列计算机指令段，该指令段用于描述所述计算机指令42在所述监控软件开发过程的终端4中的执行过程。例如，所述计算机指令42可以被分割为获取单元、质量监控单元以及确定单元，各单元具体功能如上所述。

所述监控软件开发过程的终端可包括，但不仅限于，处理器40、存储器41。本领域技术人员可以理解，图6仅仅是监控软件开发过程的终端4的示例，并不构成对监控软件开发过程的终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述监控软件开发过程的终端还可以包括输入输出终端、网络接入终端、总线等。

所称处理器40可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器41可以是所述监控软件开发过程的终端的内部存储单元，例如监控软件开发过程的终端的硬盘或内存。所述存储器41也可以是所述监控软件开发过程的终端的外部存储终端，例如所述监控软件开发过程的终端上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器41还可以既包括所述监控软件开发过程的终端的内部存储单元也包括外部存储终端。所述存储器41用于存储所述计算机指令以及所述终端所需的其他程序和数据。所述存储器41还可以用于暂时地存储已经输出或者将要输出的数据。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神范围，均应包含在本申请的保护范围之内。