您好, 访客   登录/注册

软件质量度量模型探讨

来源:用户上传      作者:

  摘要:随着软件项目需求增长,软件开发过程和质量度量的研究十分活跃。怎样把握好软件度量模型分析和软件过程的关系,显得十分重要。由于软件度量体系模型用在软件开发过程中,对软件质量提高和保障有积极的现实价值。本文就质量控制的度量模型做些探讨。
  关键词:质量度量;模型
  中图分类号:TP311.52 文献标识码:A文章编号:1007-9599 (2011)05-0000-01
  Software Quality Measurement Model
  Fan Xuedong
  (Xi'an Institute of Foreign Affairs,Xi’an710077,China)
  Abstract:With the growth demand for software projects,software
  development process and quality metrics research is very active.How grasp goos software measure model relationship between analysis and software process,it is extremely important.As software measure system model used in the software development process,software quality improvement and protection value of a positive reality.In this paper,do the quality control of measurement model.
  Keywords:Quality measure;Mode
  一、度量体系模型分析:
  目前计算机行业普遍认为:软件工程度量的方式分直接度量和间接度量两种:1.直接度量:对过程的直接度量包括度量投入的成本、完成的工作量等等;对产品的直接度量包括产生的代码行数LOC、文档的页数、缺陷数/千代码行、软件执行速度等等。2.间接度量:软件的正确性、效率、可靠性、可维护性、可用性等难以直接度量。一般通过对其他项目直接度量的结果进行分析,获取对本项目的间接度量结果。
  从另一个方面看,软件度量又可以分为面向规模的度量、面向功能的度量、面向个人的度量。面向规模的度量用以收集与直接度量有关的软件工程输出的信息和质量信息;面向功能的度量提供直接度量的尺度;面向个人的度量收集个人工作方式与效率方面的信息。可以根据面向规模的基本度量数据作一些简单的计算分析,进行面向规模的生产率、质量和单位成本的间接度量,例如:生产率=KLOC/人月;质量=错误数/KLOC;单位成本=成本数/KLOC。坚持度量并记录度量结果,积累组织的历史数据。利用这些历史数据,能够更科学地把握自己的工程能力,对工程项目作出更为精确的估算。使用KLOC作为关键度量准则已经有大量的案例,并且许多著名的度量模型也直接以KLOC作为输入;但是,这种方法不适应采用非过程化语言开发的实践,对于项目估算也存在不便,因为在项目开发初期,也没有现成的KLOC数据可用。随着面向对象方法的应用,也有人提出了以系统的对象数作为基本度量单位进行规模度量的方法。面向功能的度量是对软件和软件开发过程的一种间接度量方法。这种方法并不把注意力集中在生产结果(KLOC)上,而是以软件应当满足的“功能性”、“实用性”作为度量原始依据。
  二、软件质量度量
  软件质量特性可以定义为一种层次模型。ISO9000标准中,中国国家软件产品标准中都对软件的质量及其度量要素进行了规定和描述。软件产品质量度量贯穿于软件工程过程的始终。产品交付前的质量度量为评价设计、编码、测试工作提供了一个量化根据。这一阶段的质量度量包括程序复杂性度量、模块有效性度量等;软件交付后,在运行维护阶段进行的度量主要关注软件中残存的反映可靠性的差错数和系统可维护性方面。
  度量软件质量的标准是用户对软件的需求,不符合需求的软件便不具备质量。标准的软件工程过程中,定义了一系列开发准则,用来指导软件人员用工程化方法开发软件,若不遵循这些准则,软件质量就得不到保证。质量定义中所提到的“需求”,既包括明确定义了的需求,也包括隐含的需求。因此,软件的可扩充性、可维护性就成了支持实现隐含需求的质量指标。度量软件产品的质量,除了严格度量最终产品的质量之外,还应包含对需求分析产品、设计产品、编码产品、测试产品等所有软件产品的全面度量。软件质量的定性、定量度量,可在开发过程中,结合各项技术产品的度量来进行。如对需求分析产品完备性,设计产品对需求项覆盖程度,编码产品对设计实现情况,测试用例对需求项的覆盖情况,模块聚合度、耦合度情况的度量,都可以作为间接的质量度量方法。在许多软件质量度量方法中,使用最广泛的是事后度量或验收度量,它包括对产品的正确性、可维护性、完整性和可用性的度量。(1)正确性:软件是否能正确地执行所要求的功能。可以用缺陷数/KLOC来度量;在产品交付后,根据标准的时间周期(一般为一年),按照反馈的用户报告中的缺陷数进行度量。(2)可维护性:利用平均变更时间MTTC(Mean Time To Change)间接度量软件的可维护性。(3)完整性:这个属性反映软件系统抗拒针对它的安全攻击(事故或人为)的能力。完整性 = ∑(1-危险性×(1-安全性))。其中,危险性指一定时间内特定攻击发生的概率,安全性是排除特定类型攻击的概率。两者都可以从估算或历史数据中得出。(4)可用性:即“用户友好性”。可以从四个角度度量:学习应用软件所花费的代价;为达到有效使用软件所花费的时间;使用软件带来的生产率净增值;通过问卷调查得到的用户的主观评价。还要注意度量陷阱。卡尔•威格在其《软件度量的十大陷阱》一文中总结了软件度量应该避免的十大陷阱:1.缺乏管理承诺;2.度量得太多太早;3.度量得太少太晚;4.度量了错误的事项;5.度量定义不严密;6.度量用于评估个人;7.度量用于激励而非理解;8.仅仅收集但不使用数据;9.缺乏沟通和培训;10.曲解度量数据。
  对软件生产率和软件质量的度量,管理者能够建立改进软件工程过程目标。从而对整个开发组织的工作产生直接的影响。从另一个角度来看,充分地了解工作能力的现状,就有可能确立正确的改进目标。所以,必须通过对能力、效率、质量的度量进行度量数据的收集、计算与分析,并且将历史度量数据、当前度量数据进行集成,建立工程过程的“度量基线”,利用基线来评估各类改进工作的效用,估算新项目的规模、工作量、预测成本、质量指标。度量基线由以往的软件开发项目收集到的度量数据构成。有人将其称之为“数字化的经验”。
  三、结论
  软件度量仅仅是增进软件理解、预测、评价、控制和改善的富有助益的路径。如果仅仅寄希望于以统计为基础的软件度量来获取软件开发完美科学性不尽合理。必须善用度量数据。度量的目的是为了提升软件工程过程和软件产品的质量。不要用一个项目组的生产率和另一个组的生产率数据进行对比,也不能以此来评价两个小组的绩效和个人的表现。影响生产率的因素很多,如人的因素、问题因素、过程因素、产品因素、资源因素等。简单地根据生产率度量数据对比来评定人员绩效是不公平的,这样做可能严重影响工程师的工作热情,还会影响到今后度量数据的真实性。
  
  
  

转载注明来源:https://www.xzbu.com/8/view-8727001.htm