CN115640225A - 软件项目质量评估方法、装置、存储介质、计算机设备 - Google Patents

Abstract

本申请提供了一种软件项目质量评估方法、装置、存储介质、计算机设备。该方法包括：向项目管理系统发送第一获取请求，以获取目标项目的需求质量信息；向开发管理系统发送第二获取请求，以获取目标项目的代码质量信息；根据需求质量信息得到需求质量评分，根据代码质量信息得到代码质量评分；根据需求质量评分和代码质量评分，得到目标项目的综合质量评分。该评估方法着眼于需求和开发这两大环节对软件项目进行量化评估，可为改进项目开发、提高软件开发质量提供数据参考。

Description

软件项目质量评估方法、装置、存储介质、计算机设备

技术领域

本申请涉及软件开发技术领域，尤其涉及一种软件项目质量评估方法、装置、存储介质、计算机设备。

背景技术

一个软件项目的开发工作一般通过业务或产品提出需求，再由开发团队基于需求进行开发工作，代码开发完成后进行软件测试，在测试通过后即可上线。由于软件开发的环节较多，为了发现开发中的问题以提高开发效率，急需一种可以对软件项目的整个开发过程进行量化评估的工具。

发明内容

本申请的目的旨在至少能解决上述的技术缺陷之一，特别是现有技术中难以量化评估软件项目质量的技术缺陷。

第一方面，本申请实施例提供了一种软件项目质量评估方法，包括：

向项目管理系统发送第一获取请求，以获取目标项目的需求质量信息；

向开发管理系统发送第二获取请求，以获取目标项目的代码质量信息；

根据需求质量信息得到需求质量评分，根据代码质量信息得到代码质量评分；

根据需求质量评分和代码质量评分，得到目标项目的综合质量评分。

在其中一个实施例中，需求质量信息包括：需求文档质量、需求文档评审次数、评审会议耗时和需求缺陷统计信息。

在其中一个实施例中，项目管理系统用于根据需求评估报告确定需求文档质量和需求缺陷统计信息，根据评审会议纪要信息确定需求文档评审次数和评审会议耗时。

在其中一个实施例中，根据需求质量信息得到需求质量评分，包括：

根据需求文档质量、需求文档评审次数、评审会议耗时和需求缺陷统计信息确定各自对应的需求质量子评分；

根据各需求质量子评分以及各需求质量子评分对应的权重值，确定需求质量评分；

其中，需求文档评审次数的需求质量子评分所对应的权重值等于评审会议耗时的需求质量子评分所对应的权重值，且大于需求缺陷统计信息的需求质量子评分所对应的权重值，需求缺陷统计信息的需求质量子评分所对应的权重值等于需求文档质量的需求质量子评分所对应的权重值。

在其中一个实施例中，代码质量信息包括：代码文档质量、提测准时情况、冒烟缺陷数量、严重代码缺陷占比、代码缺陷修复耗时以及代码缺陷总数。

在其中一个实施例中，开发管理系统用于根据代码评估报告确定代码文档质量、冒烟缺陷数量、严重代码缺陷占比、代码缺陷修复耗时以及代码缺陷总数，根据目标项目各模块的开发结束时间和实际提测时间之间的差异，确定提测准时情况。

在其中一个实施例中，根据代码质量信息得到代码质量评分，包括：

根据代码文档质量、提测准时情况、冒烟缺陷数量、严重代码缺陷占比、代码缺陷修复耗时以及代码缺陷总数确定各自对应的代码质量子评分；

根据各代码质量子评分以及各代码质量子评分对应的权重值，确定代码质量评分；

其中，冒烟缺陷数量的代码质量子评分对应的权重值大于严重代码缺陷占比的代码质量子评分对应的权重值，严重代码缺陷占比的代码质量子评分对应的权重值等于代码缺陷修复耗时的代码质量子评分对应的权重值，代码文档质量、提测准时情况、代码缺陷总数的代码质量子评分对应的权重值相等且小于代码缺陷修复耗时的代码质量子评分对应的权重值。

第二方面，本申请实施例提供了一种软件项目质量评估装置，包括：

第一请求模块，用于向项目管理系统发送第一获取请求，以获取目标项目的需求质量信息；

第二请求模块，用于向开发管理系统发送第二获取请求，以获取目标项目的代码质量信息；

第一评分模块，用于根据需求质量信息得到需求质量评分，根据代码质量信息得到代码质量评分；

第二评分模块，用于根据需求质量评分和代码质量评分，得到目标项目的综合质量评分。

第三方面，本申请实施例提供了一种计算机设备，包括一个或多个处理器，以及存储器，存储器中存储有计算机可读指令，计算机可读指令被一个或多个处理器执行时，执行上述任一实施例中的软件项目评估方法的步骤。

第四方面，本申请实施例提供了一种存储介质，存储介质中存储有计算机可读指令，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行上述任一实施例中的软件项目评估方法的步骤。

从以上技术方案可以看出，本申请实施例具有以下优点：

通过从项目管理系统和开发管理系统分别提取需求质量信息和代码质量信息，并利用一定的评分细则将开发过程中与需求和开发这两个环节有关的记录量化为需求质量评分和代码质量评分，最后综合需求质量评分和代码质量评分得到对目标项目的质量进行评估的综合质量评分。该评估方法着眼于需求和开发这两大环节对软件项目进行量化评估，可为改进项目开发、提高软件开发质量提供数据参考。

附图说明

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

图1为本申请实施例提供的软件项目质量评估方法的流程示意图；

图2为本申请实施例提供的软件项目质量评估装置的模块示意图；

图3为本申请实施例提供的计算机设备的内部结构图。

具体实施方式

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

第一方面，本申请实施例提供了一种软件项目质量评估方法，请参阅图1，包括步骤S102至步骤S108。

S102，向项目管理系统发送第一获取请求，以获取目标项目的需求质量信息。

S104，向开发管理系统发送第二获取请求，以获取目标项目的代码质量信息。

可以理解，在企业内部会存在各类办公系统，如项目管理系统和开发管理系统。项目管理系统用于开发中的软件项目进行需求管理，主要使用对象包括产品经理，如对任意一个开发中的软件项目提交需求文档(Product Requ-irement Document，PRD文档)、邀请开发人员进行需求研讨、需求解决顺序、需求解决情况跟进等等。因此，项目管理系统中记录的数据可用于评估需求质量好坏，该部分数据即为需求质量信息。项目管理系统响应于第一获取请求即可从多个开发中的软件项目中确定目标项目，并提取出目标项目的需求质量信息返回给请求方。

开发管理系统用于对开发中的软件项目进行开发管理，主要使用对象包括开发人员，如提交代码进行测试、管理开发周期、代码缺陷记录等等。因此，开发管理系统中记录的数据可用于评估代码质量好坏，该部分数据即为代码质量信息。开发管理系统响应于第二获取请求即可从多个开发中的软件项目中确定目标项目，并提取出目标项目的代码质量信息返回给请求方。

S106，根据需求质量信息得到需求质量评分，根据代码质量信息得到代码质量评分。

需求质量信息中包含与需求质量有关的多种记录，可以通过预设的需求质量评分细则，将各记录量化为对应的需求质量子评分。为综合各需求质量子评分，可以对各需求质量子评分进行加权求和，得到需求质量评分。可根据每种记录对需求质量的影响大小调整权重，影响越大则权重值越高。

类似的，代码质量信息中包含与代码质量有关的多种记录，可以通过预设的代码质量评分细则，将各记录量化为对应的代码质量子评分。为综合各代码质量子评分，可以对各代码质量子评分进行加权求和，得到代码质量评分。可根据每种记录对代码质量的影响大小调整权重，影响越大则权重值越高。

S108，根据需求质量评分和代码质量评分，得到目标项目的综合质量评分。

由于软件项目提出需求和代码开发是最重要的两个环节，基于这两个评分得到对目标项目的质量进行量化评估的综合质量评分。需求质量评分和代码质量评分可采用加权求和的方式得到综合质量评分，根据企业对这两个环节的重视程度分配需求质量评分和代码质量评分对应的权重值，如更重视代码质量，则将代码质量评分的权重设置得大于需求质量评分的权重。

基于本实施例中的软件项目评估方法，通过从项目管理系统和开发管理系统分别提取需求质量信息和代码质量信息，并利用一定的评分细则将开发过程中与需求和开发这两个环节有关的记录量化为需求质量评分和代码质量评分，最后综合需求质量评分和代码质量评分得到对目标项目的质量进行评估的综合质量评分。该评估方法着眼于需求和开发这两大环节对软件项目进行量化评估，可为改进项目开发、提高软件开发质量提供数据参考。

在其中一个实施例中，需求质量信息包括：需求文档质量、需求文档评审次数、评审会议耗时和需求缺陷统计信息。具体而言，需求文档是软件功能开发的基础，需求文档质量与需求文档中关于软件功能的描述的清楚、详尽程度有关，需求文档质量越好，则意味着开发人员和更快了解产品经理的思路，有助于开发人员保质保量地进行开发。需求文档有时需要经过开发人员和产品经理开展评审会议讨论，需求文档评审次数即为开展评审会议的次数，评审会议耗时则为所有评审会议的总超时。需求文档评审次数过多或评审会议耗时过大都意味着该需求文档存在较大问题，需要高频、长时间的讨论才能确定，对项目进展影响较大。需求缺陷统计信息可包括需求缺陷数量和解决需求缺陷耗时。需求缺陷指的是产品经理提出的违反客观规律、业务逻辑等需求所带来的代码缺陷。解决需求缺陷耗时即为解决这些需求缺陷耗费的时间。需求缺陷将导致项目做了许多无用的额外工作，对项目进展影响较大。

在其中一个实施例中，项目管理系统用于根据需求评估报告确定需求文档质量和需求缺陷统计信息，根据评审会议纪要信息确定需求文档评审次数和评审会议耗时。具体而言，项目管理系统可生成需求评估问卷，由统计人员进行填写。将需求文档质量分为多个档次，如规范、不规范和缺失。在审核过程中发现缺少相应的需求文档，则在需求评估问卷关于需求文档质量处填写缺失。在审核过程中发现需求文档出现任一项违规事项，则确定该需求文档不规范，在需求评估问卷关于需求文档质量处填写不规范，否则确定该需求文档规范。违规事项包括但不限于：描述过于简单的需求(“一句话需求”)；缺少必要定义的需求；引用历史文档但没有给出访问地址的需求；经过修改但未标识出修改区域的需求；调用外部接口，但未附上接口说明的需求。统计人员还可根据开发人员和测试人员的反馈，确定需求缺陷统计信息。在需求评估问卷填写完成后，即得到需求评估报告。将需求评估报告上传项目管理系统即可。由于开展评审会议会在项目管理系统留下时间记录，根据相关的记录(即据评审会议纪要信息)可提取出需求文档评审次数和评审会议耗时。

在其中一个实施例中，根据需求质量信息得到需求质量评分，包括：

1)根据需求文档质量、需求文档评审次数、评审会议耗时和需求缺陷统计信息确定各自对应的需求质量子评分。可以理解，需求文档质量、需求文档评审次数、评审会议耗时和需求缺陷统计信息都是从不同角度反映需求质量的记录，每种记录都有相应的评分细则。根据各记录的内容和对应的评分细则，即可得到与各记录一一对应的需求质量子评分。例如，以100分为满分为例，需求文档质量的评分细则为：需求文档质量为规范则对应的需求质量子评分为100，需求文档质量为不规范则对应的需求质量子评分为50，需求文档质量为缺失则对应的需求质量子评分为0。需求文档评审次数的评分细则为：评审1次则对应的需求质量子评分为100，评审2次则对应的需求质量子评分为50，评审超过2次则对应的需求质量子评分为0。评审会议耗时(会议时长乘参会人员总数)的评分细则为：小于4小时则对应的需求质量子评分为100，4～23小时则对应的需求质量子评分为50，大于23小时则对应的需求质量子评分为0。需求缺陷统计信息的评分细则为：当需求缺陷数量大于1或解决需求缺陷耗时在两天以上，则对应的需求质量子评分为50，当需求缺陷数量大于3或解决需求缺陷耗时在三天以上，则对应的需求质量子评分为20，当需求缺陷数量大于5或解决需求缺陷耗时在五天以上，则对应的需求质量子评分为0，其他情况则对应的需求质量子评分为100。

2)根据各需求质量子评分以及各需求质量子评分对应的权重值，确定需求质量评分。

其中，需求文档评审次数的需求质量子评分所对应的权重值等于评审会议耗时的需求质量子评分所对应的权重值，且大于需求缺陷统计信息的需求质量子评分所对应的权重值，需求缺陷统计信息的需求质量子评分所对应的权重值等于需求文档质量的需求质量子评分所对应的权重值。可以理解，本实施例中对评审次数和评审会议耗时的关注程度较高，即认定这两个记录对需求质量的影响较大，因此将这两个记录的权重值设为最大且相等。而需求缺陷统计信息和需求文档质量的重要程度稍弱，则将其权重值设置得小于前两个记录且相等。例如，需求缺陷统计信息和需求文档评审次数的需求质量子评分所对应的权重值均为30％，需求缺陷统计信息和需求文档质量的需求质量子评分所对应的权重值均为20％。

在其中一个实施例中，代码质量信息包括：代码文档质量、提测准时情况、冒烟缺陷数量、严重代码缺陷占比、代码缺陷修复耗时以及代码缺陷总数。具体而言，代码文档是软件项目运行的基础，代码文档的可读性、可维护性、可拓展性等都会影响软件项目上线后的运行情况。提测准时情况反映开发人员将开发完成的代码文档提交测试的时间是否准时，由于软件项目开发的各个环节都有相应的排期，前序环节如果未准时完成，将导致整个项目的上线时间推后，对项目进展影响较大。冒烟缺陷指的是导致代码基本功能难以稳定运行的缺陷，例如，用户数据丢失、系统死机、模块无法启动等等。代码文档存在冒烟缺陷则意味着该代码文档存在较为基础的问题，将对软件项目造成极大影响。严重代码缺陷指的是对软件的功能造成影响的代码缺陷，具体如何划分代码严重程度，可根据企业内部设定的标准进行，例如，当出现死循环、导致数据库发生死锁、数据通讯错误、数值计算错误、功能不符、数据流错误、程序接口错误等任一项的时候，则认为出现了严重代码缺陷。代码缺陷修复耗时以及代码缺陷总数都将反映在出现代码缺陷时所需要额外进行的工作量，均对软件项目的进展有较大影响。

在其中一个实施例中，开发管理系统用于根据代码评估报告确定代码文档质量、冒烟缺陷数量、严重代码缺陷占比、代码缺陷修复耗时以及代码缺陷总数，根据目标项目各模块的开发结束时间和实际提测时间之间的差异，确定提测准时情况。可以理解，项目管理系统可生成代码评估问卷，由统计人员进行填写。将代码文档质量分为多个档次，如规范、不规范和缺失。在审核过程中发现缺少相应的代码文档，则在代码评估问卷关于代码文档质量处填写缺失。在审核过程中发现代码文档出现任一项违规事项，则确定该代码文档不规范，在代码评估问卷关于代码文档质量处填写不规范，否则确定该代码文档规范。违规事项包括但不限于：缺少重要的配置信息、缺少对引用接口的描述，缺少改动域、分支等的改动信息。统计人员还可根据测试人员的反馈，确定冒烟缺陷的数量、严重代码缺陷占比、代码缺陷修复耗时以及代码缺陷总数，并将这些数据填入代码评估问卷中。在代码评估问卷填写完成后，即得到代码评估报告。将代码评估报告上传开发管理系统即可。由于将代码文档会在开发管理系统留下时间记录，开发管理系统根据代码文档的实际提测时间是否超过原定的开发结束时间，即可确定提测准时情况为准时或者延迟。

在其中一个实施例中，根据代码质量信息得到代码质量评分，包括：

1)根据代码文档质量、提测准时情况、冒烟缺陷数量、严重代码缺陷占比、代码缺陷修复耗时以及代码缺陷总数确定各自对应的代码质量子评分。可以理解，代码文档质量、提测准时情况、冒烟缺陷数量、严重代码缺陷占比、代码缺陷修复耗时以及代码缺陷总数都是从不同角度反映代码质量的记录，每种记录都有相应的评分细则。根据各记录的内容和对应的评分细则，即可得到与各记录一一对应的代码质量子评分。例如，以100分为满分为例，代码文档质量的评分细则为：代码文档质量为规范则对应的代码质量子评分为100，代码文档质量为不规范则对应的代码质量子评分为50，代码文档质量为缺失则对应的代码质量子评分为0。提测准时情况的评分细则为：提测准时情况为准时则对应的代码质量子评分为100，提测准时情况为延迟则对应的代码质量子评分为0。冒烟缺陷数量的评分细则为：冒烟缺陷数量大于0则对应的代码质量子评分为0，否则为100。严重代码缺陷占比的评分细则为：严重代码缺陷占比小于10％则对应的代码质量子评分为100，严重代码缺陷占比在10％以上则对应的代码质量子评分为50，严重代码缺陷占比在30％以上则对应的代码质量子评分为0。代码缺陷修复耗时的评分细则为：代码缺陷修复耗时在5天以下则对应的代码质量子评分为100，代码缺陷修复耗时大于5天则对应的代码质量子评分为50，代码缺陷修复耗时大于10天则对应的代码质量子评分为0。代码缺陷总数的评分细则为：代码缺陷总数小于10个则对应的代码质量子评分为100，代码缺陷总数超过10个则对应的代码质量子评分为50，代码缺陷总数超过30个则对应的代码质量子评分为0。

2)根据各代码质量子评分以及各代码质量子评分对应的权重值，确定代码质量评分。

其中，冒烟缺陷数量的代码质量子评分对应的权重值大于严重代码缺陷占比的代码质量子评分对应的权重值，严重代码缺陷占比的代码质量子评分对应的权重值等于代码缺陷修复耗时的代码质量子评分对应的权重值，代码文档质量、提测准时情况、代码缺陷总数的代码质量子评分对应的权重值相等且小于代码缺陷修复耗时的代码质量子评分对应的权重值。可以理解，本实施例中对冒烟缺陷数量的关注程度最高，因此将冒烟缺陷数量的权重值设为最大。其次是严重代码缺陷占比和代码缺陷修复耗时，将这两个记录的权重值设置为仅次于冒烟缺陷数量且相等。最后则为代码文档质量、提测准时情况和代码缺陷总数。例如，冒烟缺陷数量的代码质量子评分对应的权重值为30％，严重代码缺陷占比和代码缺陷修复耗时的代码质量子评分对应的权重值为20％，代码文档质量、提测准时情况和代码缺陷总数的代码质量子评分对应的权重值为10％。

第二方面，本申请实施例提供了一种软件项目质量评估装置，请参阅图2，包括第一请求模块210、第二请求模块220、第一评分模块230和第二评分模块240。第一请求模块210用于向项目管理系统发送第一获取请求，以获取目标项目的需求质量信息。第二请求模块220用于向开发管理系统发送第二获取请求，以获取目标项目的代码质量信息。第一评分模块230用于根据需求质量信息得到需求质量评分，根据代码质量信息得到代码质量评分。第二评分模块240用于根据需求质量评分和代码质量评分，得到目标项目的综合质量评分。

关于软件项目质量评估装置的具体限定可以参见上文中对于软件项目质量评估方法的限定，在此不再赘述。上述软件项目质量评估装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

第三方面，本申请实施例提供了一种计算机设备，包括一个或多个处理器，以及存储器，存储器中存储有计算机可读指令，计算机可读指令被一个或多个处理器执行时，执行上述任一实施例中的软件项目评估方法的步骤。

第四方面，本申请实施例提供了一种存储介质，存储介质中存储有计算机可读指令，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行上述任一实施例中的软件项目评估方法的步骤。

示意性地，如图3所示，图3为本申请实施例提供的一种计算机设备的内部结构示意图，该计算机设备300可以被提供为一服务器。参照图3，计算机设备300包括处理组件302，其进一步包括一个或多个处理器，以及由存储器301所代表的存储器资源，用于存储可由处理组件302的执行的指令，例如应用程序。存储器301中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件302被配置为执行指令，以执行上述任意实施例的文本识别方法。

计算机设备300还可以包括一个电源组件303被配置为执行计算机设备300的电源管理，一个有线或无线网络接口304被配置为将计算机设备300连接到网络，和一个输入输出(I/O)接口305。计算机设备300可以操作基于存储在存储器301的操作系统，例如WindowsServer TM、Mac OS XTM、Unix TM、Linux TM、Free BSDTM或类似。

本领域技术人员可以理解，图3中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间可以根据需要进行组合，且相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种软件项目质量评估方法，其特征在于，包括：

向项目管理系统发送第一获取请求，以获取目标项目的需求质量信息；

向开发管理系统发送第二获取请求，以获取所述目标项目的代码质量信息；

根据所述需求质量信息得到需求质量评分，根据所述代码质量信息得到代码质量评分；

根据所述需求质量评分和所述代码质量评分，得到所述目标项目的综合质量评分。

2.根据权利要求1所述的方法，其特征在于，所述需求质量信息包括：需求文档质量、需求文档评审次数、评审会议耗时和需求缺陷统计信息。

3.根据权利要求2所述的方法，其特征在于，所述项目管理系统用于根据需求评估报告确定所述需求文档质量和所述需求缺陷统计信息，根据评审会议纪要信息确定所述需求文档评审次数和所述评审会议耗时。

4.根据权利要求2所述的方法，其特征在于，所述根据所述需求质量信息得到需求质量评分，包括：

根据所述需求文档质量、所述需求文档评审次数、所述评审会议耗时和所述需求缺陷统计信息确定各自对应的需求质量子评分；

根据各所述需求质量子评分以及各所述需求质量子评分对应的权重值，确定所述需求质量评分；

其中，所述需求文档评审次数的所述需求质量子评分所对应的权重值等于所述评审会议耗时的所述需求质量子评分所对应的权重值，且大于所述需求缺陷统计信息的所述需求质量子评分所对应的权重值，所述需求缺陷统计信息的所述需求质量子评分所对应的权重值等于所述需求文档质量的所述需求质量子评分所对应的权重值。

5.根据权利要求1所述的方法，其特征在于，所述代码质量信息包括：代码文档质量、提测准时情况、冒烟缺陷数量、严重代码缺陷占比、代码缺陷修复耗时以及代码缺陷总数。

6.根据权利要求5所述的方法，其特征在于，所述开发管理系统用于根据代码评估报告确定所述代码文档质量、所述冒烟缺陷数量、所述严重代码缺陷占比、所述代码缺陷修复耗时以及所述代码缺陷总数，根据所述目标项目各模块的开发结束时间和实际提测时间之间的差异，确定所述提测准时情况。

7.根据权利要求5所述的方法，其特征在于，所述根据所述代码质量信息得到代码质量评分，包括：

根据所述代码文档质量、所述提测准时情况、所述冒烟缺陷数量、所述严重代码缺陷占比、所述代码缺陷修复耗时以及所述代码缺陷总数确定各自对应的代码质量子评分；

根据各所述代码质量子评分以及各所述代码质量子评分对应的权重值，确定所述代码质量评分；

其中，所述冒烟缺陷数量的所述代码质量子评分对应的权重值大于所述严重代码缺陷占比的所述代码质量子评分对应的权重值，所述严重代码缺陷占比的所述代码质量子评分对应的权重值等于所述代码缺陷修复耗时的所述代码质量子评分对应的权重值，所述代码文档质量、所述提测准时情况、所述代码缺陷总数的所述代码质量子评分对应的权重值相等且小于所述代码缺陷修复耗时的所述代码质量子评分对应的权重值。

8.一种软件项目质量评估装置，其特征在于，包括：

第一请求模块，用于向项目管理系统发送第一获取请求，以获取目标项目的需求质量信息；

第二请求模块，用于向开发管理系统发送第二获取请求，以获取所述目标项目的代码质量信息；

第一评分模块，用于根据所述需求质量信息得到需求质量评分，根据所述代码质量信息得到代码质量评分；

第二评分模块，用于根据所述需求质量评分和所述代码质量评分，得到所述目标项目的综合质量评分。

9.一种计算机设备，其特征在于，包括一个或多个处理器，以及存储器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述一个或多个处理器执行时，执行如权利要求1至7任一项所述的软件项目评估方法的步骤。

10.一种存储介质，其特征在于，所述存储介质中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如权利要求1至7任一项所述的软件项目评估方法的步骤。

Images