首页软件开发正文

软件开发量化指标（软件开发量化考核机制）

软件开发 2023-01-20T21:47:11 1920

今天给各位分享软件开发量化指标的知识，其中也会对软件开发量化考核机制进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！本文目录一览： 1、软件开发常见指标

今天给各位分享软件开发量化指标的知识，其中也会对软件开发量化考核机制进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

1、软件开发常见指标
2、什么是软件项目技术指标
3、浅谈软件开发过程的质量度量技术
4、如何评估软件质量
5、敏捷开发效率怎么量化
6、如何量化考核软件开发人员绩效

软件开发常见指标

1.进度方面

实际进度的计划进度的偏差情况，Gantt图和Pert图。

返工时间占项目总时间的比例情况

项目能够容忍的最大的处理变更的时间

三级强调了偏差的范围，四级强调严格的上下限控制(控制图)

2.工作量

实际工作量和计划工作量的偏差

三级增加对好质量成本和坏质量成本相关工作量的度量(COGQ,COPQ)

对项目返工，评审，测试和处理变更工作量的分别度量

3.成本

计划成本和实际成本的偏差

三级强调了成本和进度的性能指示器(挣值分析)

三级强调了偏差的范围，四级强调严格的上下限控制(控制图)

五级强调了会提供可选择的过程改进和缺陷预防策略供选择，而这个是在对项目的成本和效益做了比较和平衡后得出的。

4.软件质量保证

不合格项的信息

SQA具体的审核信息

5.Review的结果

Review的活动项的状态

6.问题报告

问题项的具体状态(打开,处理,关闭)

问题的原因的分析，对问题的分类的统计

问题的平均处理周期度量

7.同行评审和缺陷

同行评审的缺陷的打开和关闭的情况统计

缺陷密度

缺陷移除率和缺陷泄漏率

同行评审的效率，评审速率的度量

同行评审的覆盖率

四级强调对缺陷分类后的帕累托分析

四级强调对同行评审的关键特征项的控制图分析

8.需求的度量

需求的规模的情况

需求的稳定度或需求的变更率

需求变更的不同类型的分布情况

需求变更处理的效率和周期度量

9.培训

实际安排课程和计划课程的对比

实际参与人员和计划参与人员的对比

对培训的成本和花费的度量

对培训取得的效果的度量

10.测试过程

测试的生产率的度量

测试规模的度量

对测试BUG的分类后的帕累托分析

生命周期不同阶段发现缺陷的数量分布，泄漏情况

测试BUG的密度

什么是软件项目技术指标

软件技术指标分成"功能指标"和"非功能指标".

1. 功能指标,即软件所能提供的各种功能和用途;

2. 非功能指标,包括软件产品的各种性能参数,如安全性/扩展性/部署方便性/可用性等.

扩展资料：

用户视角

对用户而言，性能就是响应时间。用户甚至不关心响应时间中哪些是软件造成的，哪些是硬件造成的。但用户感受到的响应时间既有客观成分，也有主观成分，甚至是心理因素。

管理员视角

管理员需要使用软件提供的管理功能等手段来方便普通用户使用。这类用户首先关注普通用户感受到的软件性能。其次，管理员需要进一步关注如何利用管理功能进行性能调优。

开发人员视角

开发人员的视角与管理员的视角基本一致，但开发人员需要更深入地关注软件性能。在开发过程中，开发人员希望能够尽可能地开发出高性能的软件。

参考资料来源：百度百科-软件性能

参考资料来源：百度百科-软件技术指标

软件开发量化指标（软件开发量化考核机制）

浅谈软件开发过程的质量度量技术

摘要：本文讨论软件开发过程中度量对质量管理的重要性。如果没有度量，没有对软件过程的可见度，就无法控制软件质量。

关键词：软件开发质量度量

软件工程的唯一目标是生产出高质量的软件“。软件质量保证”(Software Quality Assurance，简称SQA)是一种应用于整个软件过程的保护性活动。目的是验证在软件开发过程中是否遵循了合适的过程和标准。SQA应用软件质量度量技术使其在软件生命周期各阶段均得以保证。

软件度量是测度。测度用于整个软件过程：辅助估算、质量控制、生产率评估、及项目控制，目的是改进它。软件工程管理和其它工程管理相比有其特殊性。首先，软件是知识产品，进度和质量都难以度量，生产效率也难以保证。其次，软件系统复杂程度也是超乎想象的。正因为软件如此复杂和难以度量，为生产出高质量的软件这个目的，软件工程质量度量显得更加重要。

1、软件需求是进行“质量”度量的基础软件质量度量考虑两种不同的质量：设计质量和符合质量。设计质量包括系统的需求、规约和设计。符合质量则主要关注实现问题，如果实现了设计、得到的系统满足需求和性能目标，则符合质量较高,缺乏需求符合性则质量不高;指定的质量标准定义了一组软件开发的准则，缺乏开发标准就缺少质量“;隐含需求”没有满足，软件质量也值得怀疑。

为了保证软件产品满足需求，质量控制应用于整个开发周期的一系列审查、复审和测试。质量控制的任务就是策划可行的质量管理活动，然后正确地执行和控制这些活动以保证绝大多数的缺陷可以在开发过程中被发现。质量控制在创建工作产品的过程中还包括一个反馈循环。度量和反馈相结合，使得监测产品不满足规约时可调整开发过程。质量控制将视为整个制造过程的一部分。

2、软件度量的三个步骤

软件度量有数据收集、度量计算及度量评估三个必须执行的步骤。要度量软件质量，可通过创建一个包含过程及产品测量的数据库，让软件工程师及管理者能够更好地了解他们所做的工作及所开发的产品各个时段的质量状态。

软件工程是一种层次化技术，包括过程、方法和工具，它对技术或实体的分析、设计、建造、验证和管理。其基础是过程层，软件过程是建造高质量软件需要完成的任务框架，它定义了软件开发中采用的方法，而方法层是技术上如何实现，工具层对过程和方法提供自动化和半自动化工具的支持。软件工程探索软件开发过程的研究现状，以有组织的质量保证为基础。质量管理刺激了不断的过程改进，正是这种改进导致了更加成熟的软件工程方法的`不断出现。

3、软件工程用技术度量评估质量软件工程的最高目标就是产生高质量的系统、应用软件或产品。为了达到这个目标，软件工程师必须掌握在成熟的软件过程背景下对有效的方法及现代化的工具(如CASE)之应用。由于硬件成本持续降低，可支持运行CASE工具的工作站和网络已经成为软件工程使用的工作平台，CASE工具可完成一些特定的软件开发过程。这些工具提供给软件设计者以图形方式描述软件设计的能力，这样就易于维护、易于交叉检查、易于理解。除此之外，优秀的软件工程师及优秀的软件工程管理者必须不时评估是否能够达到高质量的目标。

4、有用的软件质量的测量指标

为了保证软件质量，人们用直接的或间接的测量方法测度质量因素，书中提出四种常用测量指标：正确性：正确性是软件完成所需的功能的程度。正确性的最常用的测量是每千行(KLOC)的缺陷数，在这里，缺陷定义为验证出来的与需求不符的地方。

可维护性：指遇到错误时程序能被修改的容易程度;环境发生变化时程序能够适应的容易程度，用户希望改变需求时程序被增强的容易程度。可维护性无法直接测量，采用间接测量。如面向时间的度量用平均修改时间(mean-time-to-change,MTTC)，即分析改变的需求、设计合格的修改方案、并将修改的结果发布给用户所花的时间。

完整性：现在软件完整性日益重要。它测量系统在安全方面的抗攻击能力。这些攻击可能发生在软件的三个主要成分上：程序、数据及文档。为了测量完整性必须加入两个附加的属性：威胁和安全性。一个系统的完整性可以定义为：完整性=Σ[l—威胁×(1—安全性)]可用性：即“用户友好性”。根据四个特性量化“用户友好性”：(1)学会系统所需的体力的和/或智力的投入;(2)使用系统达到中等效率所需的时间;(3)当系统由某个具有中等效率的人使用时，测量到的生产率的净增长率(与被该系统替代的老系统相比);以及(4)用户对系统的态度的主观评估(可以通过调查表获得)。

上述的四个因素仅仅是被建议作为软件质量测量显的众多因素中的一个样板，软件质量因素还有：健壮性、效率、可用性、风险、可理解性、可维修性、灵活性(适应性)、可测试性、可移植性(、有一种定量度量的方法是：用原来程序设计和调试的成本除移植时需用的费用)。可再用性、可运行性等等。

5、结语

差异控制是软件工程质量控制的核心。要生产出高质量的软件，就要注意差异控制，注意项目需求分析。在需求分析阶段要注意：(1)质量指标对不同人群、不同目的、不同时段要求可能不同，具体质量控制指标需供需双方共同约定;(2)质量指标与度量标准、目的相关，一般的情况是高指标具有高技术难度、需要高投入、较长开发期;(3)软件开发不同于其他产品的制造，软件的整个过程都是设计过程(没有制造过程);(4)软件开发不需要使用大量的物质资源，而主要是人力资源。

充分认识软件工程的目标，为确保目标实现切实采用的软件度量技术，控制所有过程的质量，满足顾客和组织内部双方的需要和利益，定期评价质量体系，生产出高质量软件。 ;

如何评估软件质量

Q：最近我们组想自己审视一下软件质量，但是缺少相关的经验知识（组内没有qa)。想向你了解一下，现在常用的软件质量评估方法? 你有关于软件质量相关的文章推荐吗？或者有哪些书籍推荐?

A：软件质量评估，我暂时还一时想不起来。对于软件质量（测试）相关的书籍我这有基本，具体的可以参考我之前参加的播客：和，里面有书籍的介绍。

单纯的评估这块，我之前做过一个软件测试成熟度模型，可以用于评估团队的测试能力。

Q：其实我有一个问题，软件质量该如何体现。感觉测试何软件质量有区别，但是我说不出来。特别是现在客户非常依赖手动测试，有专门的测试部门

A：首先，质量是个很大的概念，本质是一种主观感受。我们通常所指的狭义质量为可靠性，软件的可靠性可以通过线上bug数来衡量（或者数量的变化趋势）。更加准确的计算为线上bug数/开发中的bug数。

这个指标是量化可靠性的其中一种理论，由于业界本身对于软件质量的度量还没有统一的结论，我们可以采用这个值作为相对值进行对比。例如当比率很大时，可靠性质量很不好。

还有一个评估方法是工业界的的质量体系。也就是说，你的开发流程需要符合一定的标准，我就认为你的质量是有保证的。但是这个方式比较复杂而且不好量化

线上bug数属于简单粗暴型，用比例会准确一下是因为产品的规模不同，线上bug数是不同的。

在回答了上述问题后，我对自己的答安并不十分自信，因为我的观点是来源于自己的经验加上一些碎片话的知识。

为了更加准确的找寻关于“软件质量” 的概念，我再次查阅了维基百科：。

如上所示软件质量的定义与软件测试一样，并没有统一的定义。大的有三个维度的定义：

这段话的最后部分也指出了最早的质量定义是主观的感受。后面还提到了用户满意度。

总之，准确的定义软件质量依然是困难的，不过，我们还是有一些可以依据的定义，他们采用的是质量模型：

如 ISO/IEC 9126的定义的：

以及 CISQ's quality model

由于软件质量定义暂时难已统一，并且是主观的感受。那么评估它也就显得比较主观了。

当然，最简单的非软件测试莫属，那么Bug数毫无疑问的成为了一种可行的评估方式，因为软件测试最早的定义即是，“为了发现错误而执行程序的过程”，其中的错误，我们就可以狭义的理解为Bug。那这里又会存在一个问题，什么bug才有测量意义呢？

根据上述软件质量的定义，“用户”，“客户”，这些真正使用软件的人的感受才是最能反应质量的，所以说，“用户”， “客户”遇到的bug 才是更加符合质量的定义的可用于反应软件质量的Bug类型。（也就是我们所说的线上Bug）

另外，我们可以参考IT界的一些常用的定义来评估质量，例如：

ISO 9126-3

所提到的质量模型，我们可以通过检查软件开发过程中，以及软件自身是否具备某些特质，以及对应于该特质相关的用于评估的属性来评估软件的质量是好是坏。例如：

我们通过右侧的属性来评估左侧的质量特性：

从而得到一个综合的质量评估结果。

尽管上面给出了很多属性，但是相信大家读完了，依然疑惑，即便是有了这些属性，每个属性本身也并非都是标准化，且容易度量的，如coding practices即是典型的例子，里面提到了compliance with OO，可是这一点却是评估的人不同，显然量化的结果是不同，假如OO compliance的满分是10分，对于某OO设计，打6，还是7分，还是8，就仁者见仁，智者见智了。

假如我们狭义的理解质量为质量模型中的可靠性，需要check的点：

尽管已经有了这么多点，上面最后一句依然表明了可靠性的衡量需要考虑被评估软件本身的架构以及使用的第三方库，然后通过自定义的check点来做。也就是说，这个需要可靠性的评估标准，需要因地制宜，看情况而定。显然这种措辞依然表达出了主观标准的意思。

也正是如此，我们身边的日常用品的质量往往会打着IOS9001/IOS9002质量体系认证，来表明其质量是保证的，也就是说，我的产品是在质量保证的流程体系下生产出来的。这样以来，貌似这种评估定义，跟上述定义大体类似，实际上都是难以准确度量的，更大的意义也许是跟没有质量保证的产品去分开吧。

总之，度量软件质量是如此的复杂，且不一定真的能够准确量化质量。那倒不如就在开发过程中时刻按照这些check list约束开发过程，让开发过程是在有保证的情况下交付软件。让真正的质量交给时间，交给我们的线上去体现吧。这也想汽车界的著名质量杂志的JD Power的做法，用线上故障数来评估质量吧（对于汽车，准确的是每百辆故障数）。

敏捷开发效率怎么量化

敏捷开发讲究的是团队的自我改进，讲究的是通过自我管理达到团队整体效能的提升，因此对于敏捷开发的绩效考核一定不要考核到个人头上，那将严重破坏敏捷团队的自管理，破坏团队内部的协作精神。

绩效考核和敏捷开发在理念上是存在一定冲突的，绩效考核更注重通过外部压力促进绩效的提升，而敏捷开发更注重通过内部的自我改进动力促进绩效提升，所以对敏捷团队做绩效考核一定要慎之又慎，否则极易破坏敏捷团队的自我改进动力，将其从与客户共赢为中心的导向变成以绩效指标为中心，那就不再是敏捷了。如果要做绩效考核的话，对于敏捷开发团队的考核只能做到团队整体级别。在选取指标时要与敏捷的精神想匹配，可以从与客户的合作关系、团队内部的协作、响应变更的速度、可使用的工作组件的发布速度等角度去设计指标。至于开发工作的量化，可以考虑将功能点估算作为软件规模的度量方法，相对比较客观一些，但这个指标不能反映开发过程中变更带来的额外工作量。所有指标都有局限性，关键看公司想获得什么商业目标。