软件质量模型
| http://blog.csai.cn/user1/14480/archives/2006/3777.html |
关于软件质量的定义，曾给出过多种定义。
·ANSI/IEEE Std 729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。
·M.J.Fisher定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。
也就是说，为满足软件的各项精确定义的功能、性能需求，符合文档化的开发标准，需要相应地给出或设计一些质量特性及其组合，作为在软件开发与维护中的重要考虑因素。如果这些质量特性及其组合都能在产品中得到满足，则这个软件产品质量就是高的。
软件质量反映了以下三方面的问题：
·软件需求 是度量软件质量的基础 。不符合需求的软件就不具备质量。
·规范化的标准定义了一组开发准则，用来指导软件人员用工程化的方法来开发软件。如果不遵守这些开发准则，软件质量就得不到保证。
·往往会有一些隐含的需求没有显式地提出来。如软件应具备良好的可维护性。如果软件只满足那些精确定义了的需求而没有满足这些隐含的需求，软件质量也不能保证。
软件质量是各种特性的复杂组合。它随着应用的不同而不同，随着用户提出的质量要求不同而不同。因此，有必要讨论各种质量特性，以及评价质量的准则，还要介绍为保证质量所进行的各种活动。
早在1976年，由Boehm等提出软件质量模型的分层方案。1979年McCall等人改进Boehm
质量模型又提出了一种软件质量模型。模型的三层次式框架如图12-4-1所示。质量模型中的质量概念基于11个特性之上。而这11个特性分别面向软件产品
的运行、修正、转移。它们与特性的关系如图12-4-1所示。
McCall等认为，特性是软件质量的反映，软件属性可用做评价准则，定量化地度量软件属性可知软件质量的优劣。
图 12-4-1 McCall软件质量模型
McCall等人的质量特性定义如下：
什么是质量保证？它是为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动。质量保证是面向消费者的活动，是为了使产品实现用户要求的功能，站在用户立场上来掌握产品质量的。这种观点也适用于软件的质量保证。
软件质量保证由各项任务构成，这些任务的参与者有两种人：软件开发人员和质量保证人员。前者负责技术工作，后者负责质量保证的计划、监督、记录、分析及报告工作。
软件开发人员 通过采用可靠的技术方法和措施，
进行正式的技术评审，执行计划周密的软件测试来保证软件产品的质量。软件质量保证人员则辅助软件开发组得到高质量的最终产品。1993
年美国SEI推荐了一组有关质量保证的计划、监督、记录、分析及报告的SQA活动 。这些活动将由一个独立的SQA小组执行（或协助）：
1.为项目制定SQA计划
该计划在制定项目计划时制定，由相关部门审定。它规定了软件开发小组和质量保证小组需要执行的质量保证活动，其要点包括：需要进行哪些评价？需要进行哪
些审计和评审？项目采用的标准；错误报告的要求和跟踪过程；SQA小组应产生哪些文档？为软件项目组提供的反馈数量等。
2.参与开发该软件项目的软件过程描述
软件开发小组为将要开展的工作选择软件过程 ，SQA小组则要评审过程说明，以保证该过程与组织政策 、内部的软件标准 、外界所制定的标准（如ISO 9001）以及软件项目计划的其他部分相符。
3.评审各项软件工程活动
核实其是否符合已定义的软件过程。SQA小组识别 、记录和跟踪所有偏离过程的偏差，核实其是否已经改正。
4.审计产品
审计指定的软件工作产品，核实其是否符合已定义的软件过程中的相应部分。
SQA小组对选出的产品进行评审，识别、记录和跟踪出现的偏差，核实其是否已经改正，定期向项目负责人报告工作结果。
5.记录与处理
确保软件工作及工作产品中的偏差已被记录在案，并根据预定规程进行处理。偏差可能出现在项目计划、过程描述、采用的标准或技术工作产品中。
6.跟踪
记录所有不符合部分，并向上级管理部门报告。跟踪不符合的部分直到问题得到解决。
除了进行上述活动外 ，SQA小组还需要协调变更的控制与管理，并帮助收集和分析软件度量的信息。
软件质量及质量模型
----软件质量是一个复杂的概念，不同的人从不同的角度来看软件质量问题，会有不同的理解。从用户的角度看，质量就是满足客户的需求；从开发者的角度看，质量
就是与需求说明保持一致；从产品的角度看，质量就是 产品的内在特点；从价值的角度看，质量就是客户是否 愿意购买。
----在软件项目开发过程中，项目经理眼中的质量就是能"令人满意"地工作以完成预期功能的软件产品。所谓"令 人满意"，包括功能、性能、接口需求及其他指标，如可靠性、可维护性、可复用性和正确性。然而在实际工作中，一旦出现问题时，项目管理人员必须权衡利弊，作出取舍，在满足某一个指标的同时，牺牲另外一个或几个指标。比如为了按期交货，需对软件功能进行分类，在第 一个版本中实现优先级较高的功能，在第二个版本中实 现优先级较低的功能。因此，项目经理需要一个对其工 作有指导意义的质量模型和度量方法。该模型一方面可 以帮助项目经理生产出符合标准的软件产品，另一方面 帮助项目经理识别可能影响产品质量的风险。
----如上所述，项目经理需要一个易于理解的质量模型来帮助他评估软件的质量和对风险进行识别、管理。目前 已有很多质量模型，它们分别定义了不同的软件质量属 性。比较常见的三个质量模型是McCall模型（1977年）、Boehm模型（1978年）和ISO9126（1993年）。
----在项目开始的时候，项目经理应该根据客户的需求及项目的特点，选择一组项目管理目标，针对这组目标，设计一套数据测量和统计的方法。这组管理目标应该与
软件产品和软件过程的属性相关，而这些属性能反映目 标实现的概率。
----例如，从实用的角度出发，我们可以选择下面一组管理目标：需求的质量、产品的质量、开发的有效性、测试 的有效性。
----这组目标既反映软件产品的质量属性，又反映软件过程的质量属性。模型的目标必须能通过一组属性来测量，以帮助对风险的定义和分类。
风险
----风险就是遭受损失的可能性。软件开发风险管理过程包括风险的识别、评估和排序及风险的监控。
----对不同项目和不同的项目经理，上述风险区域的顺序 可能是不同的。进行风险管理对质量模型提出了两点要 求：一是要求模型支持对风险的量化表示；二是要求模 型支持对整个项目的风险评估。即对风险的测量应该可以经归纳汇总得到某一软件阶段或整个项目所面临的风险。
----当项目的风险被识别和量化以后，应该对它们进行分类。如可以按采取措施的不同进行分级：
----低级按当前趋势推进，非常可能实现其目标，无需制定应急计划；
----中级按当前趋势推进，有可能实现其目标，需要制定应急计划；
----高级按当前趋势推进，很难实现其目标，需立即制定应急计划。
----分类工作通常需要统计数据的支持，且应由有经验的分析员来完成。
质量模型和风险评估
----一旦项目经理选定了管理目标，且定义了相关的质量属性，就应该着手定义测量标的。这些测量标的适用于 整个软件生命周期，包括初期阶段，这将有助于在软件开发的初期发现潜在的问题。
需求质量
----1．需求质量及其风险
----需求是软件开发活动的基础，与需求相关的质量属性包括明确性、完整性、可理解性、需求的波动性、可跟踪性。
----软件需求定义包括功能需求，即软件应做哪些工作；
性能需求，即做多少和做多快；接口需求，即软件与谁接口、如何接口和怎样接口。如果需求不明确、不完整或不易理解，就会出现最终产品不能满足需求的风险。
----2．需求的质量属性及其测量
----(1)明确性
----不明确的需求是指那些有多种含意的需求，这类需求在实现时，不同的开发人员会有不同的理解。有两组测量数据可以用来评估需求文档的明确性：一组是不明确
的需求用语，一组是不确定的需求用语。
----不明确用语：适当的、合适的、适用的、不限于、通常、至少、不时。
----不确定用语：可以、也许、作为候选。
----需求的不明确性可以从不明确或不确定的需求用语中反映出来。
----(2)完整性
----完整的需求文档要求对需求的描述足够详细，使设计和实现可以在此基础上进行。用于评估需求完整性的测量标的可以选择文档中"待定"或"待补充"等用语的数目，这些地方往往是需求需要补充或修改的地方。
----(3)可理解性
----有两个标的物可以反映需求的可理解性：一个是需求文档的编号结构，另一个是可读性评估。通常，需求的编号结构（即其深度和广度）反映了需求文档的质量；另 外，索引的可读性也是影响需求可理解性的重要因素之一。
----(4)需求的波动性
----需求的波动性是指需求的变化频率。需求变化对软件质量的影响随着开发工作的接近完成而越来越大，波动性的测量标的是在某一时间段里，需求的变化条目数与
需求的总条目数之百分比。对变化条目的统计应来自项目的配置管理系统。
----(5)可跟踪性
----软件需求是从系统需求中分析得来的，系统需求应对其进行跟踪，以确保软件需求在系统设定的环境下正常工作。软件需求也须对其设计、实现及测试过程进行跟
踪，以确保其作为软件一部分的正确性。有两个可跟踪性的测量标的物，一是没有系统需求进行跟踪的软件需求条目数；另一个是没有跟踪到代码和测试的软件需求数。
----3．需求风险
----已被公认的一点是，质量差的需求文档及多变的需求是项目风险的主要来源。需求的波动性是风险的一个重要因素，需要下大力量对其进行测量，以减少其影响。
需求变化发生得越晚，产生的影响越大，风险也越大。值得一提的是，对需求风险的测量应贯穿整个软件生命周期。
产品质量
----1．产品质量及其风险
----软件开发项目的主要目的就是生产符合项目需求的代码和文档。因此，需要进行测量的质量属性有：体系/结构、复用性、可维护性及文档与代码的一致性。
----2．软件质量属性和测量标的
----体系/结构、复用性和可维护性使用相同的质量属性，包括复杂性、程序大小及两者的关系。
----(1)复杂性
----人们已经普遍认为，高复杂性的模块不仅难以理解，而且容易出错。因此，复杂性对软件质量及可维护性和复用性有着直接的影响。
----对复杂性的测量，有许多种类型的标的物，例如：
----逻辑复杂性线性无关的测试路径数目；
----数据复杂性数据类型和参数传递数目；
----调用复杂性从模块进、出的调用数目；
----嵌套级别条件语句嵌套的深度。
----其中，逻辑复杂性与程序的可测试性和可维护性直接相关。
----(2)程序大小
----对程序大小的测量主要是计算代码行数，计数方法主要有：代码行数（头文件、定义、执行及不可执行语句）、非注释行及非空代码行数、可执行代码行数三种。
----模块的大小是质量的一个标识，一般的工业标准是每个模块50～100行代码。更大的模块将难以理解，因而会降低可维护性和复用性。
----3．内部文档
----文档是代码内容的说明。它可以是与代码分离的手册，也可以是在程序中的注释。对内部文档的测量标的，我们建议选择在程序中的注释。
----在计算注释行数时，在线和非在线的注释行数都应该统计在内。在线的注释包括在可执行的语句里面，许多工具都忽略了对在线注释的统计。
实现有效性及其风险
----实现有效性是指在项目计划的活动中，最大限度地发挥资源的效能。与这一目标相关的属性及其测量标的有：
----资源的使用资源在项目的不同阶段的使用情况。对资源测量一般以"人·时"为单位，测量通常针对在生命周期不同阶段的活动进行，这些活动是由项目定义的。应
该进行测量的主要活动有：需求分析、编码、测试、改错、培训等。
----完成率某一项活动或任务完成的百分数。任务和产品部件的完成率是一个项目能否按期交付产品的标识物。如果有详细的计划，完成率是可以测量的，而且可以作
出计划与实际完成情况的比较图。
----需要强调的是，资源的使用率和任务的完成率不应该用来计算开发人员的生产率，一旦如此，开发人员往往会停止合作。
----在设计阶段，甚至在实现阶段，如果把大量的精力花在与需求有关的活动上，项目将会面临很大的风险。
测试的有效性及其风险
----所谓有效测试的目的是查找并修改软件中的错误，识别易发生错误的软件，按时完成测试工作，使软件能令人满意地工作。
----一旦代码通过单元测试之后，正式的测试（包括系统测试、集成测试及验收测试）就开始了。这一过程的目的是找出子系统和各组件间由于未预料到的交互而产生
的错误，同时确认系统提供了需求中所描述的功能。
----测试有效性的属性及测量标的是：
----正确性在这里，正确性的定义是代码完成需求定义的程度，其含意之一是软件必须是没有错误的。错误是在测试和复审过程中查找出来的。
----正确性的测量标的物是如下错误信息：检测日期、修改完毕日期、错误级别、测试案例号、错误来源、修改错误影响到的代码。
----通过统计，我们发现在测试中找到的错误数目累计分布情况大致如下：
----即随时间的推移，错误的累计数将会达到某一极限值。
----正确性就是报告发现的错误数量，在测试过程进行到1/3时，根据经验曲线，预测总的错误数目。
----通过代码模块和子系统发生的错误数可以预测风险。
即对发生的错误数超过了平均值的代码段应该进行重
点分析，看是否应进行返工。
联合风险评估
----对有些风险的评估，也许需要考虑其他质量目标的测量结果。例如，高需求波动率仅通过需求的变化数是无法测量的，还必须在需求阶段结束后统计所有项目人员
花在需求管理活动上的时间。一个很有意义的测量标的是花在每一个需求改变上的平均时间，它是用总需求变化数除相应时间段内花在需求分析上的总时间。
----另外一个风险评估的测量标的物是对模块按其大小和复杂性进行风险分级，同时考虑在模块中发现的关键错误的数目。很明显，模块越大，复杂性越高，且发现的
关键错误越多，该模块产生风险的概率也越大。
----以上介绍的质量模型是在参考国外的一些质量模型的基础上，根据我公司多年软件开发的经验建立起来的，它具有下列特点：
----(1)模型是动态的，不是静态的，它可以反映开发过程中的多个顺时状态，模型产生的数据可用来在项目的各里程碑处预测项目风险。
----(2)该模型引入了一整套完整的测量机制，包括质量目标、质量属性和对软件产品及开发过程的测量标的。
----(3)模型易于理解，同时也很实用。我们可以根据项目的具体特点在开发的不同阶段引入适当的质量目标。模型的另一个特点是它的测量标的物所基于的质量属性
是那些项目经理所关心的质量属性。模型包括了对数据
分析方法的指南。
TAG: