1、第十四章 软件质量管理,从质量保证到质量认证 质量保证 软件可靠性 配置管理 ISO9000 国际标准 CMM软件能力成熟度模型,从软件质量保证到质量认证,质量管理的三个阶段 质量检验 全面质量管理TQC 质量认证 CMM软件能力成熟度模型 ISO 9000国际标准,质量是产品的生命,不论生产什么产品,质量都是极端重要的。软件产品开发周期长,耗费巨大的人力和物力,更必须特别注意保证质量。 一、软件质量软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说,软件质量是软件符合明确地叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。上述
2、定义强调了下述的三个要点。,14.1 软件质量,软件需求是度量软件质量的基础,与需求不一致就是质量不高。 指定的标准定义了一组指导软件开发的准则,如果没有遵守这些准则,几乎肯定会导致质量不高。 通常,有一组没有显式描述的隐含需求(例如,期望软件是容易维护的)。如果软件满足明确描述的需求,但却不满足隐含的需求,那么软件的质量仍然是值得怀疑的。,图14.1软件质量因素与产品活动的关系,影响软件质量的主要因素从管理角度对软件质量的度量。可以把这些质量因素划分成三组,它们分别反映用户在使用软件产品时的三种不同倾向或观点。这三种倾向是:产品运行,产品修改和产品转移。,一、软件质量 (续),二、软件质量保
3、证措施 软件质量保证(Software Quality Assurance,SQA)的措施主要有: 基于非执行的测试(也称为复审):用于保证软件在编码之前各阶段产生的文档的质量 基于执行的测试:在程序编写出来之后进行,是保证软件质量的最后一道防线 程序正确性证明:用数学方法来严格验证程序是否与对它的说明完全一致,14.2 质量保证,参加软件质量保证的人员分为: 软件工程师:通过采用可靠的技术方法和度量、进行正式的技术复审以及完成计划周密的测试保证软件质量 SQA小组:辅助软件工程小组以获得高质量的软件产品,包括计划、监督、记录、分析和报告。,二、软件质量保证措施 (续),1、技术复审的必要性正
4、式技术复审的明显优点是,能够较早地发现错误,防止错误被传播到软件过程的后续阶段。正式技术复审实际上是一类复审方法,包括走查(Walkthrough)和审查(Inspection)等具体方法。走查的步骤比审查少,而且没有审查那样正规。,二、软件质量保证措施 (续),2、走查 (1)参与者驱动法参与者按照事先准备好的列表,提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须对每个质疑做出回答,要么承认确实有错误,要么对质疑做出解释。 (2)文档驱动法文档编写者向走查组成员仔细解释文档。走查组成员在此过程中不时针对事先准备好的问题或解释过程中发现的问题提出质疑。这种方法可能比第一种方法更彻底
5、,往往能检测出更多错误。经验表明,采用文档驱动法时许多错误是由文档讲解者自己发现的。,二、软件质量保证措施 (续),3、审查审查的范围要比走查广泛得多,它的步骤也比较多。一般来说,审查有5个基本步骤。(1)综述:由负责编写文档的一名成员向审查组成员综述该文档。综述会议结束时把文档分发给每位与会者。(2)准备:评审员仔细阅读文档。最好列出在审查中发现的错误的类型,并按发生频率把错误类型分级,以辅助审查工作的进行。这些列表有助于评审员们把注意力集中到最常发生错误的区域。,二、软件质量保证措施 (续),(3)审查:评审组仔细走查整个文档。和走查一样,这一步的目的也是找出文档中的错误,而不是改正它们。
6、审查组组长必须在一天之内写出一份关于审查的报告。通常每次审查会不超过90分钟。(4)返工:文档的作者负责解决在书面报告中列出的所有错误及问题。(5)跟踪:组长必须确保所提出的每个问题都得到了圆满的解决(要么修正了文档,要么澄清了被误认为是错误的条目)。必须检查对文档所做的每个修正,以确保没有引入新的错误。如果在审查过程中返工量超过5%,则应该召集审查组再对文档全面地审查一遍。,3、审查 (续),可用错误检验表辅助发现错误或对错误进行发分类。,二、软件质量保证措施 (续),4、程序正确性证明正确性证明的基本思想是证明程序能完成预定的功能。因此,应该提供对程序功能的严格数学说明,然后根据程序代码证
7、明程序确实能实现它的功能说明。如果在程序的若干个点上,设计者可以提出关于程序变量及它们的关系的断言,那么在每一点上的断言都应该永远是真的。假设在程序的P1,P2,Pn等点上的断言分别是a(1),a(2),a(n),其中a(1)必须是关于程序输入的断言,a(n)必须是关于程序输出的断言。为了证明在点Pi和Pi+1之间的程序语句是正确的,必须证明执行这些语句之后将使断言a(i)变成a(i+1)。如果对程序内所有相邻点都能完成上述证明过程,则证明了输入断言加上程序可以导出输出断言。如果输入断言和输出断言是正确的,而且程序确实是可以终止的(不包含死循环),则上述过程就证明了程序的正确性。,二、软件质量
8、保证措施 (续),14.3 软件可靠性,基本概念 1. 软件可靠性的定义 对于软件可靠性有许多不同的定义,其中多数人承认的一个定义是: 软件可靠性是程序在给定的时间间隔内,按照规格说明书的规定成功地运行的概率。,2. 软件的可用性通常用户也很关注软件系统可以使用的程度。一般来说,对于任何其故障是可以修复的系统,都应该同时使用可靠性和可用性衡量它的优劣程度。 软件可用性的一个定义是:软件可用性是程序在给定的时间点,按照规格说明书的规定,成功地运行的概率。如果在一段时间内,软件系统故障停机时间分别为td1,td2,正常运行时间分别为tu1,tu2,则系统的稳态可用性为:,其中 Tup = tui
9、Tdown = tdi如果引入系统平均无故障时间MTTF和平均维修时间MTTR的概念,则(5.1)式可以变成平均维修时间MTTR是修复一个故障平均需要用的时间,它取决于维护人员的技术水平和对系统的熟悉程度,也和系统的可维护性有重要关系。平均无故障时间MTTF是系统按规格说明书规定成功地运行的平均时间,它主要取决于系统中潜伏的错误的数目,因此和测试的关系十分密切。 ,3. 估算平均无故障时间的方法软件的平均无故障时间MTTF是一个重要的质量指 标,往往作为对软件的一项要求,由用户提出来。为 了估算MTTF,首先引入一些有关的量。 (1). 符号在估算MTTF的过程中使用下述符号表示有关的数量:
10、ET测试之前程序中错误总数;IT程序长度(机器指令总数);测试(包括调试)时间;Ed()在0至期间发现的错误数;Ec()在0至期间改正的错误数。,(2). 基本假定 根据经验数据,可以作出下述假定。 在类似的程序中,单位长度里的错误数ET/IT近似为常数。美国的一些统计数字表明,通常0.5 10-2 ET/IT210-2 也就是说,在测试之前每1000条指令中大约有520个错误。 失效率正比于软件中剩余的(潜藏的)错误数,而平均无故障时间MTTF与剩余的错误数成反比。,此外,为了简化讨论,假设发现的每一个错误都立即正确地改正了(即,调试过程没有引入新的错误)。因此Ec()=Ed()剩余的错误数
11、为Er()=ET-Ec()单位长度程序中剩余的错误数为r()=ET/Ir-Ec()/IT,(3). 估算平均无故障时间经验表明,平均无故障时间与单位长度程序中剩余 的错误数成反比,即其中K为常数,它的值应该根据经验选取。美国的一些统 计数字表明,K的典型值是200。估算平均无故障时间的公式,可以评价软件测试的进 展情况。此外,由(5.5)式可得因此,也可以根据对软件平均无故障时间的要求,估 计需要改正多少个错误之后,测试工作才能结束。,(4). 估计错误总数的方法a. 植入错误法使用这种估计方法,在测试之前由专人在程序中随 机地植入一些错误,测试之后,根据测试小组发现的错 误中原有的和植入的两
12、种错误的比例,来估计程序中原 有错误的总数ET。假设人为地植入的错误数为Ns,经过一段时间的测试 之后发现ns个植入的错误,此外还发现了n个原有的错 误。如果可以认为测试方案发现植入错误和发现原有错 误的能力相同,则能够估计出程序中原有错误的总数为 Nt = *Ns其中Nt即是错误总数ET的估计值。,b. 分别测试法为了随机地给一部分错误加标记,分别测试法使用两个测试员(或测试小组),彼此独立地测试同一个程序的两个副本,把其中一个测试员发现的错误作为有标记的错误。具体做法是,在测试过程的早期阶段,由测试员甲和测试员乙分别测试同一个程序的两个副本,由另一名分析员分析他们的测试结果。用表示测试时间
13、,假设:=0时错误总数为B0;=1时测试员甲发现的错误数为B1;=1时测试员乙发现的错误数为B2;=1时两个测试员发现的相同错误数为bc。,如果认为测试员甲发现的错误是有标记的,即程序中有标记的错误总数为B1,则测试员乙发现的B2个错误中有bc个是有标记的。假定测试员乙发现有标记错误和发现无标记错误的概率相同,则可以估计出测试前程序中的错误总数为 使用分别测试法,在测试阶段的早期,每隔一段时间分析员分析两名测试员的测试结果,并且用(5.8)式计算B0。如果几次估算的结果相差不多,则可用B0的平均值作为ET的估计值。此后一名测试员可以改做其他工作,由余下的一名测试员继续完成测试工作,因为他可以继
14、承另一名测试员的测试结果,所以分别测试法增加的测试成本并不太多。,14.4 配置管理,软件配置管理的主要目的就是控制在软件开发过程中的各种变化、修改的管理,从某种意义上是软件质量保证的一部分,但专注于软件各个成份的变化和修改的控制,从而保证各个成份之间的一致性。软件配置管理从总的来说包括识别软件变化、控制变化、保证变化正确进行以及向感兴趣的其他人员报告变化。,软件配置管理活动,包括: 识别软件成份,并具体确定软件配置管理的对象 软件成份的版本控制(version control),维持各个成份之间一致的版本 变化控制(change control):以严格的过程控制软件成份的变化 配置审核(c
15、onfiguration auditing):保证所要进行的变化正确地实现 报告(reporting):向其他相关成员报告软件成份的变化,14.4 配置管理 (续),软件配置管理不同于软件维护。维护是在软件交付给用户使用后才发生的,而软件配置管理是在软件项目启动时就开始,并且一直持续到软件退役后才终止的一组跟踪和控制活动。软件配置管理的目标是,使变化更容易被适应,并且在必须变化时减少所需花费的工作量。,14.4 配置管理 (续),一、软件配置 1、软件配置项软件过程的输出信息可以分为三类: (1)计算机程序(源代码和可执行程序); (2)描述计算机程序的文档(供技术人员或用户使用); (3)数
16、据(程序内包含的或在程序外的)。上述这些项组成了在软件过程中产生的全部信息,我们把它们统称为软件配置,而这些项就是软件配置项。可以把软件配置管理看作是应用于整个软件过程的软件质量保证活动,是专门用于管理变化的软件质量保证活动。 导致软件配置项发生变化的原因:书P257-258共5点,14.4 配置管理 (续),2、基线基线是一个软件配置管理概念,它有助于我们在不严重妨碍合理变化的前提下来控制变化。IEEE把基线定义为:已经通过了正式复审的规格说明或中间产品,它可以作为进一步开发的基础,并且只有通过正式的变化控制过程才能改变它。,一、软件配置 (续),基线就是通过了正式复审的软件配置项。在软件配
17、置项变成基线之前,可以迅速而非正式地修改它。一旦建立了基线之后,虽然仍然可以实现变化,但是,必须应用特定的、正式的过程(称为规程)来评估、实现和验证每个变化。书例:软件配置项与基线,P258-259共13点,一、软件配置 (续),二、软件配置管理过程软件配置管理是软件质量保证的重要一环,它的主要任务是控制变化,同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告。具体来说,软件配置管理主要有五项任务:标识、版本控制、变化控制、配置审计和报告。,14.4 配置管理 (续),1、标识软件配置中的对象为了控制和管理软件配置项,必须单独命名每个配置项,然后用面向
18、对象方法组织它们。可以标识出两类对象:基本对象和聚集对象(可以把聚集对象作为代表软件配置完整版本的一种机制)。每个对象都有一组能惟一地标识它的特征:名字、描述、资源表和“实现”。其中,对象名是无二义性地标识该对象的一个字符串。,二、软件配置管理过程 (续),2、版本控制版本控制联合使用规程和工具,以管理在软件工程过程中所创建的配置对象的不同版本。借助于版本控制技术,用户能够通过选择适当的版本来指定软件系统的配置。实现这个目标的方法是,把属性和软件的每个版本关联起来,然后通过描述一组所期望的属性来指定和构造所需要的配置。,二、软件配置管理过程 (续),图14.2 演化图,2、版本控制 (续),上
19、面提到的“属性”,既可以简单到仅是赋给每个对象的特定版本号,也可以复杂到是一个布尔变量串(开关),该布尔变量串指明了施加到系统上的功能变化的特定类型。为构造一个程序的给定版本的适当变体,可以赋给每个构件一个“属性元组”。所谓“属性元组”实际上是一个特征表,当构造软件某版本的特定变体时,该特征表将指出是否应该使用这个构件。为每个变体都赋上一个或多个属性。,2、版本控制 (续),图14.3 版本和变体,2、版本控制 (续),黑白,彩色,3、变化控制对于大型软件开发项目来说,无控制的变化将迅速导致混乱。变化控制把人的规程和自动工具结合起来,以提供一个控制变化的机制。需建立统一的变化控制授权(chan
20、ge ontrol authority)机构,由该机构负责控制进入基线后的所有软件成份的变化。,二、软件配置管理过程 (续),变化控制过程:识别变化提交变化报告变化控制授权机构审查审查通过,将变化要求插入到工程变化序列当处理这个变化时确定该变化所涉及的软件配置管理对象将这些软件配置管理对象退出基线实施真正的变化测试和评审变化被正确实现将变化后的软件配置管理对象加入基线建立软件配置管理对象的新的版本评估这种变化对其他软件配置管理对象的影响建立整个软件新的版本发布软件新的版本,3、变化控制 (续),变化控制过程如图14.4(书P262)所示,访问和同步控制如下图所示。,2,1,4、配置审计为确保适
21、当地实现了所需要的变化,我们从两方面采用措施:正式的技术复审;软件配置审计。正式的技术复审(见14.2.2节)关注被修改后的配置对象的技术正确性。复审者评估该配置对象以确定它与其他软件配置项的一致性,并检查是否有遗漏或副作用。软件配置审计通过评估配置对象的那些通常不在复审过程中考虑的特征,而成为对正式技术复审的补充,二、软件配置管理过程 (续),5、状态报告配置状态报告是软件配置管理的一项任务,它回答下述问题: (1)发生了什么事? (2)谁做的这件事? (3)这件事是什么时候发生的? (4)它将影响哪些其他事物?,二、软件配置管理过程 (续),14.5 IEEE1058.1 软件项目管理计划
22、标准,一个软件项目管理计划主要由三部分组成:要做的工作,要用的资源,要花的经费。软件开发需要各种资源,主要资源有:开发软件的人员,运行软件所需要的硬件和支持软件(例如,操作系统和版本控制软件)。对资源的使用将随着时间变化。在大型项目中,资源消耗Rc随时间t的变化可以用Rayleigh分布近似表示:,图13.1 资源消耗随时间变化,当时间t=k时,所需要的资源量达到峰值。,管理工作分成两类。一类工作贯穿于项目全过程,不与软件开发的特定阶段相关联,这类工作称为项目职责,例如,项目管理和质量控制。另一类工作与产品开发的特定阶段相联系,这类工作称为活动或任务。一个活动是一个大的工作单元,有它的开始时间
23、和结束时间;它消耗资源,例如消耗计算机时间和人力;它产生工作产品,例如预算、进度表、设计文档、源代码或用户手册。一项活动又包含一系列任务,一个任务是应该管理的最小工作单元。因此,在项目管理中有三种工作,分别是项目职责、活动(大工作单元)和任务(小工作作单元)。项目管理将贯穿于整个项目开发的始终。,14.5 IEEE1058.1 软件项目管理计划标准 (续),计划中的关键内容涉及工作产品的完成情况。工作产品预定完成的日期称为“里程碑”。为了确定一件工作产品是否真正到达了一个里程碑,必须通过一系列由开发组成员、管理部门和客户代表进行的审查。一个典型的里程碑是完成概要设计并且通过了审查的日期。一旦一
24、个工作产品经过审查并被一致通过,它就成为一个基线。只有经过12.3.2中描述的正式过程才能修改基线。,14.5 IEEE1058.1 软件项目管理计划标准 (续),一个工作包不仅定义了工作产品,而且定义了人员需求、开发期限、资源、负责人姓名和验收该工作产品的标准资金当然是软件项目计划的一个关键组成部分,必须拟定出详细的资金预算和资金分配方案。资金分配应该针对每个项目职责和活动,它是时间的函数。,14.5 IEEE1058.1 软件项目管理计划标准 (续),IEEE软件项目管理计划内容: 1引言 2项目组织 3管理过程 4技术过程 5工作包、进度和预算 6附加部分,14.5 IEEE1058.1
25、 软件项目管理计划标准 (续),1. 引言这部分由5个小部分组成,描述了要开发的项目和产品的概况。(1) 项目概览简要地描述项目目标、要交付的产品、有关活动及其工作产品。此外,还要列出里程碑、所需的资源、主要的进度以及主要预算。(2) 项目交付列出所有要交付给客户的软件配置项和交付的日期。,IEEE软件项目管理计划内容,(3) 软件项目管理计划的演变没有什么计划能一成不变地执行。软件项目管理计划和其他计划一样,必须随着经验的积累以及客户方与开发方的变化而变化。在这部分描述改变计划的正式规程和机制。(4) 参考资料在这部分列出软件项目管理计划引用的所有参考文档。(5) 术语定义和缩写词这些信息确保每个人都能以同样方式理解软件项目管理计划。,1. 引言 (续),2. 项目组织这部分中的4个小部分,从软件过程的角度和开发者的组织结构的角度,说明了产品是怎样开发的。(1) 过程模型根据活动(例如,产品设计或产品测试)和项目职责(例如,项目管理或配置管理)来确定过程模型。过程模型的关键内容有里程碑、基线、评审、工作产品以及可交付性。(2) 组织结构描述开发组织的管理结构。在组织中划定权限和明确责任是很重要的。(3) 组织的边界和界面,IEEE软件项目管理计划内容 (续),