质量与可靠性

,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,当前软件质量的现状,软件质量的基本概念,软件质量保证,软件的可靠性,软件开发中的可靠性控制,软件配置管理,软件质量与可靠性,1,0,当前软件质量的现状,来自北京航空航天大学可靠性工程研究所的数据,软件项目中途中止的占25%,软件产品在交付时通常在产品中还残留15%的缺陷,软件公司化在软件返工（修改）上的资源为30-44%,软件失效往往比硬件失效高一个数量级,2,中船总某军舰上计算机软件问题：,中船总某军舰计算机CPU运行850小时,故障120多次 软件占70% MTBF10h,致命故障12次 软件占70% MTBF100h,0,当前软件质量的现状（续）,3,主动控制技术（ACT）试验机,我国第一架试验机由于软件故障而坠机,在我国正在研制的若干型号的机型中，由软件引起的故障与由硬件引起的故障之比已达3:1。有些型号在试飞阶段，软件故障占故障总数的80%。,0,当前软件质量的现状（续）,4,0,当前软件质量的现状（续）,NASA（美国航空航天局）的统计,5,1 软件质量的基本概念,软件质量的定义,软件质量特性,软件质量模型,软件质量的度量和评价,6,1.1软件质量的定义,ANSI/IEEE Std 729-1983的定义,与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体,M.J. Fisher的定义,所有描述计算机软件优秀程度的特性的组合,7,质量特性及其组合，是软件开发与维护中的重要考虑因素,为满足软件的各项精确定义的功能、性能需求，符合文档化的开发标准，需要相应地给出或设计一些质量特性及其组合。,如果这些质量特性及其组合都能在产品中得到满足，则这个软件产品质量就是高的。,1.1软件质量的定义（续）,8,软件需求是度量软件质量的基础,不符合需求的软件就不具备质量。,标准还定义了一组开发准则开发准则是软件质量的保证,软件质量还在不断的发展和完善,软件质量是各种特性的复杂组合。它随着应用的不同而不同，随着用户提出的质量要求不同而不同。,1.1软件质量的定义（续）,9,1.2软件质量特性,软件质量特性，反映了软件的本质,讨论一个软件的质量，问题最终要归结到定义软件的质量特性。,定义一个软件的质量，就等价于为该软件定义一系列质量特性。,人们通常把影响软件质量的特性用,软件质量模型,来描述。,10,1.3软件质量模型,软件质量特性通常用,分层模型,来定义，它包括,基本质量特性,和,二次特性,基本质量特性,可以由一些子质量特性定义和度量。,二次特性,在必要时又可由它的一些子质量特性定义和度量。,著名的软件质量模型,1976年,Boehm,质量模型,1979年,McCall,质量模型,1985年,ISO,质量模型,11,1.3.1 Boehm质量模型,12,1.3.2 McCall质量模型,13,1.3.3,ISO,的软件质量评价模型,按照,ISO/TC97/SC7/WG3/1985-1-30/N382,，软件质量度量模型由三层组成,软件质量,需求,评价准则,（SQRC）,软件质量,设计,评价准则,（SQDC）,软件质量,度量,评价准则,（SQMC）,高层和中层建立国际标准，低层可由各使用单位视实际情况制定,14,1.3.3,ISO,的软件质量评价模型(续),15,1.3.4 ISO,质量特性国际标准,（ISO/IEC9126- 1991 ）,质量特性,：,功能性,可靠性,可维护性,效率,可使用性,可移植性,16,1.3.4 ISO,质量特性国际标准（续）,（ISO/IEC9126- 1991 ）,推荐21个子特性：,适合性 准确性 互用性 依从性 安全性 成熟性 容错性 可恢复性 可理解性 易学习性 操作性 时间特性 资源特性 可分析性 稳定性 可变更性 可测试性 可安装性 可替换性 适应性 一致性,17,1.3.4 ISO,质量特性国际标准（续）,（ISO/IEC9126- 1991 ）,质量特性的相互影响,18,1.4,软件质量的度量和评价,软件质量特性度量有两类：,预测型,验收型,预测度量,是利用定量或定性的方法，估算软件质量的评价值，以得到软件质量的比较精确的估算值。,验收度量,是在软件开发各阶段的检查点，对软件的要求质量进行确认性检查的具体评价值，它是对开发过程中的预测进行评价。,1.4.1,软件质量度量的种类,19,预测度量又分为：,尺度度量,二元度量,尺度度量，是一种定量度量。它适用于一些能够直接度量的特性。如,出错率,二元度量，是一种定性度量。它适用于一些只能间接度量的特性，例如，,可使用性,、,灵活性,等等。,1.4.2,预测度量,20,尺度度量检查表,1.4.2,预测度量（续）,21,二元度量检查表,1.4.2,预测度量（续）,22,通过对照检查项目，确定一种质量特性的有无。,例如，在设计和编码阶段的复杂性度量，利用,尺度度量方法,来做。对模块复杂性的度量采用McCabe 环路度量。,对于,二元度量,，可针对检查表中每一项都应给以记分，指定信息存在时记 “1”，否则记 “0”。表中所有各项的分数相加，即得度量结果。,1.4.3,预测度量的实施,23,2,软件的质量保证,质量保证的概念,软件质量保证的主要任务,质量保证的基本措施,质量保证的实施,软件的结构特性与评价标准,24,2.1,质量保证的概念,什么是质量保证，它是,为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动,。,质量保证是,面向消费者的活动,，是为了使产品实现用户要求的功能，站在用户立场上来掌握产品质量的。,软件的质量保证就是向用户提供满意的高质量的软件产品。,25,软件的质量保证活动也和一般的质量保证活动一样，是确保软件产品从诞生到消亡为止的所有阶段的质量的活动。即,为了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动,。,2.1,质量保证的概念（续）,26,2.2,软件质量保证的主要任务,用户要求定义,熟练掌握,正确定义用户要求的技术,熟练使用,定义软件需求的支持工具,掌握,收集和积累有关用户业务领域的各种业务的资料和技术,的技能,。,减少重复劳动和无效劳动,既有软件是否可以复用,新生产软件应具有,复用性,重视需求测试，减少,因需求规格说明有误,、,设计有误,而造成的,返工,建立互相交流、信息往来通畅、具横向交流特征的信息流通网,27,掌握开发新软件的方法,采用先进的开发技术：如,结构化技术,、,面向对象技术,使用数据库技术或网络化技术,使用新型开发工具或环境,改进开发过程,组织外部协作,必须,明确规定,进度管理,、,质量管理,、,交接检查,、,维护体制,等各方面的要求,，,建立,跟踪检查,的体制,2.2,软件质量保证的主要任务（续）,28,发挥每个开发者的能力,开发者必须有学习各,专业业务知识,、,生产技术,和,管理技术,的能动性。,制定,技术培训计划,、,技术水平标准,。,提高软件开发的工程能力,要想生产出高质量的软件产品必须有高水平的,软件工程能力,。,在软件开发环境或软件工具箱的支持下,，,运用先进的开发技术,、,工具和管理方法开发软件的能力,。,2.2,软件质量保证的主要任务（续）,29,提高计划和管理质量的能力,项目开发初期计划阶段的项目计划评价,计划执行过程中及计划完成报告的评价,将评价、评审工作在工程实施之前就列入整个开发工程的工程计划中,提高软件开发项目管理的精确度,2.2,软件质量保证的主要任务（续）,30,2.3.1,确定软件等级，实行分级管理,在需求分析阶段应根据软件失效后对系统安全性和性能的不同影响程度，将软件划分为若干个等级。一般，可根据软件的安全性、重要性将软件划分为关键软件、重要软件和一般软件。在软件研制过程中，应视软件的等级采取不同的管理措施。,2.3,质量保证的基本措施,31,2.3.2,给出关键、重要软件的可靠性指标,在确定软件可靠性指标时应注意：,a. 采用使用部门能观察到且可验证的指标,b. 分配时按软件安全关键程度适当加权,c. 给出指标时应明确验收方法。,常用的软件可靠性指标有：,MTBF、MTTF,可用性A,MDT,初期故障率,2.3,质量保证的基本措施（续）,32,2.3.3,制定软件的可靠性、安全性设计准则,a.每个阶段的具体质量要求和判据,；,b.需求分析、设计和编程阶段需遵守可靠性、安全性设计准则和相应的设计检查单；,c. 每阶段应进行的具体验证和评价活动类型、活动计划和责任者及其职责。,2.3,质量保证的基本措施（续）,33,2.3.4,认真编制符合国军标规定的软件设计文档,应及时、认真地根据GJB438A-96或其它相应标准的要求，对级别不同的软件编制相应当文档。,在转阶段评审中，必须对相应的软件文档进行认真评审。,2.3,质量保证的基本措施（续）,34,2.3.5 严格进行软件的阶段评审,软件研制单位应认真组织并严格进行软件的阶段评审；特别应认真组织好软件需求评审，软件详细设计评审，软件测试和验收评审。在评审前必须确定方式、内容、要求和评审组成员。在评审应对评审中的问题进行更改、跟踪归零。,2.3,质量保证的基本措施（续）,35,2.3.6 加强软件的配置管理,应根据国军标有关规定对软件配置标识、配置控制、配置状况记录和配置审核进行管理。必须制定“软件配置管理计划”，并按计划实施规定的管理活动。,应按照型号软件的研制进程对软件的版本进行标识并实施控制。,软件研制单位应建立本单位的软件开发库，受控库和成品库，并制定各软件库的管理规程。已归档软件产品的更改必须严格履行审批手续，更改后的软件必须进行回归测试，并重新归档。,2.3,质量保证的基本措施（续）,36,2.3.7 强化软件测试,a) 制定软件测试计划,b) 在软件研的同时进行测试,c) 规范软件的测试,d) 安全关键软件的第三方测试,2.3,质量保证的基本措施（续）,37,2.3.8,建立闭环的软件故障报告、分析和纠正系统(,SFRACAS,),在系统分析和设计阶段开始，就应建立SFRACAS，在软件测试过程中，应按有关规定记录、整理、分析有关故障数据，实施闭环控制，有效地消除软件缺陷、故障，控制软件研制工作的质量。,在软件各开发、测试部门及外场测试部门及外场试验，使用部门应建立问题报告制度，软件的更改必须认真填写“软件问题报告单”及“软件更改报告单”。对软件的更改记录和信息应纳入系统承制单位的信息闭环管理系统。,2.3,质量保证的基本措施（续）,38,2.4,质量保证活动的实施-TPDCA,Target,设定质量目标。,Plan,设定评测检查项目(质量评价准则)。制定实现质量目标的方法或手段。,Do,制作高质量的规格说明和程序。在接受质量检查前先做自我检查。,Check,质量检查，评价结果用质量图的形式表示,Action,：,对评价发现的问题进行改进活动，如果实现并达到了质量目标就转入下一个工程阶段。,这样重复“,Plan,”到“,Action,”的过程,，直到整个开发项目完成,。,39,40,2.5,软件的结构特性与评价标准,逻辑数据层次,评价标准,全部数据元素定义完毕,所有层次的操作符定义完毕,功能层次,评价标准,全部功能元素定义完毕,所有层次的操作符定义完毕,逻辑数据与功能的对应关系,评价准则,所有数据都与功能对应,所有功能元素都与数据对应,逻辑数据与功能的相互关系个数（局部）,41,物理数据层次,评价准则,全部数据元素定义完毕,物理数据之间的所有指针定义完毕,上述指针都具有层次性,模块层次,评价准则,所有模块定义完毕,模块之间所有控制关系定义完毕,上述关系都是标准过程调用形式,各层次上的模块大小适当,2.5,软件的结构特性与评价标准（续）,42,物理数据与模块的对应关系,评价准则,所有物理数据都与模块对应,所有模块都与物理数据对应,对应于一个物理数据的模块数（以一对一为好）,功能与模块的对应关系,评价准则,所有功能都与模块对应,对应模块的功能个数（以一对一为好）,2.5,软件的结构特性与评价标准（续）,43,3 软件可靠性与可靠性工程,软件生存期与软件寿命的关系,软件可靠性定义,测试中的可靠性分析,SPQL评价,软件可靠性工程,软件可靠性的测试与验证,44,3.1,软件生存期与软件寿命的关系,软件寿命的基本概念,一切有生命的东西都有“,寿命,”,概念延伸:产品的寿命就是指该产品从出厂直到丧失使用价值的持续时间。,从软件工程的角度来说，,软件产品的寿命是指软件的整个生存期,。,从用户的角度来看，更关心的是软件在交付使用后的情况,MTBF：,平均失效间隔时间,软件在使用期间能够正常工作的持续时间叫做软件的,使用寿命,。,软件的使用寿命与使用环境有关。,45,软件故障与失效,软件发生,失效,(failure),标志着软件一次使用寿命的结束,失效是由,故障,引起的：设计者的失误致使系统中留下,错误的设计（bug）,使软件存有,故障(fault),，这些故障导致系统的错误执行,错误,(,error,),，从而导致系统无法达到预期的结果,失效(failure)。,故障往往是物理地或静态地存在的，而失误、错误和失效都是系统的一种动态的转瞬即逝的现象,发生过失效的软件通常仍然是可用的。只有当软件频繁失效，或者公认已经“过时”了的时侯，软件才被废弃，,意味着当前这一版本软件寿命的终结。,3.1,软件生存期与软件寿命的关系（续）,46,3.2,软件可靠性定义,软件可靠性,软件在,给定的时间间隔,及,规定的环境条件,下，,按设计要求,，,成功地运行程序，实现规定的功能,的概率。,环境条件,指的是,软件的使用环境,。无论什么软件，如果不对它的使用环境加以限制，都是会失效的。这种失效的数据，不能用来度量软件的可靠性。,规定的时间,一般为软件的,运行时间,，,是一个随机变量,47,规定的功能,在考虑软件可靠性时，首先应当明确,软件的功能是什么,，,哪些功能是主要的,，,哪些功能是次要的,。一般从软件需求分析说明和设计说明中可以了解这些情况。,由于功能不同，失效带来的损失就不一样。因此，还要明确,哪些失效是致命的,，,哪些失效是非致命的,，,哪些又是容易修复的,。此外，还要明确，,怎样才算是完成了一个规定的功能,。,成功地运行程序,指不仅程序能正确地运行，满足用户对它的功能要求， 而且当程序一旦受到意外的伤害，或系统故障时，能尽快恢复，仍能正常地运行。,3.2,软件可靠性定义（续）,48,3.3,测试中的可靠性分析,利用测试的统计数据，估算软件的可靠性,推测错误的产生频度，即推测错误产生的时间间隔,估算错误产生频度的一种方法是估算平均失效等待时间,MTTF,(,Mean Time To Failure,),推测残留在程序中的错误数,评价测试的精确度和覆盖率,49,SPQL,:软件产品质量水平(Software Product Quality Level),SPQL,用如下公式度量：,SPQL AcCv,其中,Ac,(,Test Accuracy,) ,测试的精确度，它反映了测试的,质量,；测试质量可以用测试的,故障捕捉率,和,遗漏率,来衡量,Cv,(,Test Coverage,) ,测试的覆盖度，它反映了测试的,数量,。测试数量可以是,执行的测试用例数,、,确认的程序路径数,等等,3.4 SPQL,评价,50,Ac,的意义,：表明在测试的过程中以多大的把握捕捉了软件中潜在的故障。,Ac,的,测定,：预先植入播种故障，然后通过测试，根据播种故障的捕捉率来推测原有故障的捕获率。,3.4.1 测试精确度Ac,51,Cv,的意义,：表明在整个测试期间发现软件潜在故障的可能性有多大。,Cv,的测定,：可通过被测对象软件潜在的原有故障的捕捉率来测定的。,3.4.2,测试覆盖率,Cv,52,3.5.1,软件可靠性工程的基本概念,软件可靠性工程,(,SRE)Software Reliability Engineering,：,为了达到软件产品的可靠性要求而进行的一系列软件工程活动。,软件可靠性工程涉及以下四方面活动和有关技术：,软件可靠性,分析,：进行软件可靠性的需求分析、指标分配、故障树分析、故障模式和影响分析、软件开发过程中有关软件可靠性的的特性分析,软件可靠性,设计和实现,：,进行防错设计、容错设计、检错设计、纠错设计、故障恢复设计、软件可靠性增长,3.5,软件可靠性工程,53,3.5.1,软件可靠性工程的基本概念,软件可靠性,测量,、,测试和评估,：,在软件生存周期各阶段进行有关软件可靠性设计、制造和管理方面的,属性测量,，进行基于软件运行剖面的测试用例随机输入的软件,测试,、软件可靠性,预计,、软件可靠性,估计,、软件可靠性验证、,软件可靠性,管理,：,确定影响软件可靠性的因素，制定必要的设计和实现准则以及对软件开发各阶段软件可靠性相关的过程和产品的要求，依据上述有关测量数据和分析结果控制和改进开发过程，进行风险管理，改进费用效益关系，改进开发过程，对采购或重用的软件进行可靠性管理，,3.5,软件可靠性工程（续）,54,3.5.1,软件可靠性工程的基本概念,实施软件可靠性工程要解决三个问题,即软件可靠性指标的确定与分配,软件可靠性要求的实现,软件可靠性的验证。,3.5,软件可靠性工程（续）,55,3.5.2 为什么要实施,软件可靠性工程(SRE)？,1. SRE can help solve the most important software development problem, making you and your organization more competitive.,能够解决软件开发中的大多数重要问题，提升竞争力,2.,SRE is a proven, standard, widespread best practice.,经过证实的、权威的、普遍的最佳工程实践,3.,SRE is widely applicable.,广泛的适用性,4.,SRE cost is low.,低廉的成本,5.,SRE schedule impact is minor.,基于,SRE,的计划、进度非常合理,6.,SRE has additional advantages.,其他优势,3.5,软件可靠性工程（续）,56,3.5.3 Just Right准则,对软件可靠性的要求应该是,Just Right，,这与软件测试的,Good enough,一样，也是权衡投入产出比的一种原则,1.,选择可靠性指标，比如故障率,2.,选定故障率的公共测量方法,3.,为每个相关系统设定系统总目标故障率,FIO ( failure intensity objective),4.,开展如下工作：,A.,找出软件的总,FIO,B.,设计软件可靠性策略，用最低的开发成本，来满足软件,FIO,和目标进度的要求，,3.5,软件可靠性工程（续）,57,3.5.3 Just Right准则,如何确定可靠性指标,采用用户（系统）能观察到且可验证的指标,依据系统可靠性指标进行分配,分配时按软件安全关键程度适当加权,给出指标时明确验收方法,3.5,软件可靠性工程（续）,58,3.5.3 Just Right准则,常用的软件可靠性指标,MTBF,、MTTF,可用性,A,MDT（Mean Down Time）,初期故障,偶然故障,3.5,软件可靠性工程（续）,59,3.5.4 可靠性指导方针,Failure Impact,Hundreds of deaths, more than $10,9,cost,One or two deaths around $10,6,cost,Around $1000 cost,Around $100 cost,Around $10 cost,Typical FIO(Failures/hr),10,-9,10,-6,10,-3,10,-2,10,-1,Time Between Failures,114,000 years,114 years,6 weeks,100 hr,10 hr,3.5,软件可靠性工程（续）,60,可靠性指导方针的应用,可接受的Down机时间,5 分钟/年,5 分钟/月 or 1 小时/年,10 分钟/周 or 9小时/年,可靠性,5 nines(0.99999),4 nines(0.9999),3 nines(0.999),3.5.4 可靠性指导方针的应用,3.5,软件可靠性工程（续）,61,结果,分析,可靠性,评估,测试,运行,软件配置和规格说明书,剖面,用例,结果,预期结果和故障判据,失效数据,选取测,试用例,构造运,行剖面,被测软件,软件可靠性模型,激励器,主控机,仿真器,输入信号信息,输出信号控制,运行剖面构造,测试用例生成,网络通讯,数据收集/比较/分析,可靠性评估、预计,目标系统,子系统仿真与,数据交联控制,实时数据记录,测试用例,实时控制命令,实时输入信号,实时运行结果,控制命令,3.6,软件可靠性的测试与验证,62,结果,分析,排错与,回归测试,评估和,预计,参数,估计,停止,测试,测试,运行,软件配置和规格说明书,剖面,用例,结果,预期结果和故障判据,软件,目标值,未达目标,已达目标,参数,软件可靠性模型,选取测,试用例,构造运,行剖面,被测软件,3.6,软件可靠性的测试与验证（续）,63,4 软件开发过程中的质量控制,软件开发的主要阶段,软件开发各阶段的质量控制,评审在质量控制中的作用,64,系统分析和软件定义,软件需求分析,设计,概要设计,详细设计,代码编写和单元测试,软件测试,部件测试,集成测试,系统测试,验收,生产,4 软件开发中的质量控制,4.1 软件开发的主要阶段,65,4.21 系统分析和软件定义,主要工作：,分析系统要求和使用环境.拟定软件研制任务书,完成标志：,软件研制任务书(或类似作用的文件),管理任务：,1.拟订质量(可靠性、安全性)大纲要求 2.确定资源保证 3.组织交办、承办双方协调，承制方大力支持,质量控制手段：,1.制定软件质保计划 2.评审软件研制任务书 3.明确软件验收方法,4.2 软件开发各阶段的质量控制,66,4.2.2 软件需求分析,主要工作：,1.确定运行环境 2.确定功能、性能和接口要求，编写需求规格说明 3.确定关键软件4.制定项目开发计划 5.制定计算机软件/硬件系统测试计划,完成标志：,1.软件需求规格说明 2.项目开发计划3.计算机软件系统测试计划(初步),管理任务：,1.制定质量大纲实施计划 2.组织评审3.进行配置管理 4.进行进度管理 5.组织交办、承办双方协调并由交办方认可,质量控制手段：,1.评审软件需求规格说明 2.与开发部门一起确定安全/关键软件 3.评审系统测试计划,4.2 软件开发各阶段的质量控制（续）,67,4.2.3 设计概要设计,主要工作：,1.建立总体结构、划分模块 2.定义各功能模块接口 3.进行可靠性、安全性分析和设计 4.制定计算机软件部件集成和测试计划,完成标志：,1.概要设计说明 2.计算机软件部件集成和测试计划(初步),管理任务：,1.组织评审 2.组织记录并报告问题 3.进行配置管理 4.进行进度管理,质量控制手段：,1评审概要设计说明 2.评审软件集成测试计划,4.2 软件开发各阶段的质量控制（续）,68,4.2.4 设计详细设计,主要工作：,1.设计模块内的算法和细节 2.确定模块间详细接口信息 3.拟订软件单元测试方案,完成标志：,1.详细设计说明,管理任务：,1.组织评审 2.组织记录并报告问题 3.进行配置管理 4.进行进度管理,质量控制手段：,1.评审详细设计说明 2.检查配置管理与质保运行情况,4.2 软件开发各阶段的质量控制（续）,69,4.2.5 编码和单元测试,主要工作：,1.编写源程序 2.进行调试 3.进行静态分析和单元测试 4.编写软件使用说明 5.设计测试用例，编写测试程序,完成标志：,1.源程序 2.测试用例，测试程序 3.软件使用说明(初稿),管理任务：,1.组织验证与评审 2.组织记录并报告问题 3.进行配置管理 4.进行进度管理,质量控制手段：,1.代码走查 2.评审单元测试结果,4.2 软件开发各阶段的质量控制（续）,70,4.2.6 部件测试,主要工作：,1.执行计算机软件部件集成和测试计划 2.编写计算机软件部件集成和测试分析报告 3.完成编写软件使用说明,完成标志：,1.可运行的程序系统及数据 2.部件测试计划 3.部件测试分析报告 4.软件用户手册操作手册,管理任务：,1.加强测试2.分析风险3.组织评审、记录并报告问题4.确定可否提交系统集成和测试5. 进行配置管理6.进行进度管理,质量控制手段：,1.评审软件用户手册 2.评审软件操作手册 3.检查软件部件测试结果,4.2 软件开发各阶段的质量控制（续）,71,4.2.7 集成测试,主要工作：,1.测试整个程序 2.试用软件使用说明 3.编写配置项测试分析报告,完成标志：,1.集成测试分析报告,管理任务：,1.分析并报告问题 2.组织问题追踪 3.进行配置管理 4.组织转阶段评审,质量控制手段：,1.检查软件集成测试结果2.检查软件系统测试结果3.检查软件FRACAS运行情况4.确保安全/关键软件的第三方测试,4.2 软件开发各阶段的质量控制（续）,72,4.2.8 系统测试,主要工作：,1按系统集成和测试(系统联试)要求进行系统测试,完成标志：,1.系统集成和测试(系统联试)分析报告,管理任务：,1.分析并报告问题 2.组织问题追踪 3.进行配置管理 4.组织转阶段评审,质量控制手段：,1.检查软件集成测试结果2.检查软件系统测试结果3.检查软件FRACAS运行情况4.确保安全/关键软件的第三方测试,4.2 软件开发各阶段的质量控制（续）,73,4.2.9 验收,主要工作：,1.验收测试与审计(可利用原有测试与审计结果) 2.组织并进行移交软件产品,完成标志：,1. 软件验收报告 2. 产品移交文件,管理任务：,1.组织进行验收测试 2.组织记录并报告问题 3.进行配置管理,质量控制手段：,1.组织软件产品的交付前验收 2.评审验收测试与回归测试,4.2 软件开发各阶段的质量控制（续）,74,4.2.10 生产,主要工作：,1.编制软件生产操作规程 2.按固化程序操作规程生产软件产品,完成标志：,软件产品,管理任务：,质量控制手段：,评审软件生产操作规程2.对软件生产过程进行质量控制,4.2 软件开发各阶段的质量控制（续）,75,4.3.1 过程控制的重要手段,评审,评审对象：,1.文档 2.计划 3.报告,4.3.2,软件开发中,缺陷的引入和转移特性,继承,前一阶段遗漏的缺陷,放大,前一阶段遗漏的缺陷,本阶段,引入,的缺陷,本阶段,克服,的缺陷,转移,至下一阶段的缺陷,4.3 评审在质量控制中的作用,从前一阶段来的缺陷数,从前一阶段来的缺陷数,开发阶段,继承,的缺陷数,放大,的缺陷数,本阶段,引入,的缺陷数,克服,缺陷的能力(比例）,传向下一阶段来的缺陷数,76,4.3 评审在质量控制中的作用,4.3.3 无评审的缺陷扩大模型,0%,概要设计,0,0,10,0%,详细设计,6,6,25,20%,实现,10,81,25,10,6,4,37,10,27,50%,软件部件测试,93,0,0,50%,软件配置项测试,47,0,0,50%,系统联试,24,0,0,24,47,93,12,93,77,4.3 评审在质量控制中的作用,4.3.4 有评审的缺陷扩大模型,70%,概要设计,0,0,10,50%,详细设计,2,2,25,60%,实现,5,30,25,3,2,1,15,5,10,50%,软件部件测试,24,0,0,50%,软件配置项测试,12,0,0,50%,系统联试,6,0,0,6,12,24,3,24,78,5 软件配置管理,软件配置管理的概念,软件配置管理的基本方法,版本控制,变更控制,79,5.1,软件配置管理的概念,5.1.1 软件配置管理(SCM),在软件建立时,变更是不可避免的,变更加剧了项目中软件人员之间的混乱,协调软件开发使得混乱减到最小的技术叫做配置管理,。,配置管理是一组标识、组织和控制修改的活动,，目的是使错误达到最小并最有效地提高生产率。,SCM活动的目标,(1) 标识变更；,(2) 控制变更；,(3) 确保变更正确地实现；,(4) 向其他有关的人报告变更。,80,5.1.2 软件配置,在软件工程中产生的所有信息项（文档、报告、程序、表格、数据）构成了,软件配置,。,软件配置是软件的具体形态在某一时刻的瞬时影像。,随着软件工程过程的进展，,软件配置项,(,SCI,)数目快速增加。系统规格说明可繁衍出软件项目实施计划和软件需求规格说明。它们又依次繁衍出建立信息层次的其它文档。,5.1,软件配置管理的概念（续）,81,5.1.3 基线,基线是软件生存期中各开发阶段末尾的特定点，又称里程碑。,由正式的技术评审而得到的SCI协议和软件配置的正式文本才能成为基线。,基线的,作用是把各阶段工作的划分更加明确化,，以便于检验和肯定阶段成果。,5.1,软件配置管理的概念（续）,82,5.1,软件配置管理的概念（续）,5.1.3 软件开发各阶段的基线,83,5.1.4 项目数据库,一旦,一个SCI成为基线,，,就把它存放到项目数据库中,。,当软件组织成员想要,对基线SCI进行修改时,，,须把它从项目数据库中复制到该工程师的专用工作区中,。,例如，把一个,名为B的SCI,从项目数据库复制到工程师的专用工作区中,。,工程师在B（B的副本）上完成要求的变更,，,再用B来更新B,。,有些系统中把这个基线SCI锁定。在变更完成、评审和批准之前，不许对它做任何操作。,5.1,软件配置管理的概念（续）,84,5.1.4 项目数据库,85,5.2,软件配置管理的基本方法,5.2.1 软件配置项（SCI）,系统规格说明,软件项目实施计划,软件需求说明,可执行的原型,初步的用户手册,设计规格说明,源代码清单,测试计划和过程、测试用例和测试结果记录,操作和安装手册,可执行程序（可执行程序模块、连接模块）,数据库描述（模式和文件结构、初始内容）,正式的用户手册,86,5.2.1 软件配置项,（SCI）,维护文档（软件问题报告、维护请求、工程变更次序）,软件工程标准,项目开发总结,除以上所列SCI以外，许多软件工程组织还把,配置控制之下的软件工具,列入其中，即,编辑程序,、,编译程序,、,其它CASE工具的特定版本,。因为要使用这些工具来生成文档、程序和数据，如果编译程序的版本不同，可能产生的结果也不同。,5.2,软件配置管理的基本方法,（续）,87,5.2.2 配置对象,若干个SCI够成一个配置对象,，在项目数据库中用一个,单一的名字来组织它们,。,一个配置对象有一个,名字,和一组,属性,，并通过某些联系“连接”到其它对象。,每个对象与其它对象的联系用箭头表示。箭头指明了一种构造关系。,双向箭头则表明一种相互关系,。如果对“源代码”对象作了一个变更，软件工程师就可以根据这种相互关系确定，其它哪些对象（和SCI）可能受到影响。,5.2,软件配置管理的基本方法,（续）,88,配置对象,89,5.2.3 配置管理的任务,标识单个的SCI,标识和管理软件各种版本,控制变更,审查软件配置,报告所有加在配置上的变更。,5.2,软件配置管理的基本方法,（续）,90,5.2.4 标识SCI,为了方便,对软件配置项,（SCI）,进行控制和管理,，首先应给它们,命名即对SCI进行标识,对象类别,基本对象,：,是由软件工程师在分析、设计、编码和测试时所建立的,文本单元,。例如，基本对象可能是需求规格说明中的一节，一个模块的源程序清单、一组用来测试一个等价类的测试用例。,复合对象,：,是基本对象的组合或基本对象与其它复合对象的组合。,5.2,软件配置管理的基本方法,（续）,91,5.2.4 标识SCI,标识由,名字、描述、资源、实现,等构成,对象的,名字,明确地标识对象。,对象,描述,包括：,SCI类型,（如文档、程序、数据）、,项目标识,、,变更,和或,版本信息,。,资源,包括由对象,产生的,、,处理的,、,引用的,或,其它需要,的,一些实体,。,基本对象,的,实现,是指向,文本单元,的指针,，,复合对象,的,实现,为null。,5.2,软件配置管理的基本方法,（续）,92,5.2.5 对象之间的关系,对象的层次关系：,一个对象可以是一个复合对象的一个组成部分，用联系,标识,。,对象的相互关联关系：,对象跨越对象层次的分支相互关联。这种交叉的结构联系用,标识,5.2,软件配置管理的基本方法,（续）,93,5.2.6 演变图,任何对象都可能要做多次变更。,对于每一配置对象都可以建立一个演变图,，用演变图记叙对象的,变更历史,。,5.2,软件配置管理的基本方法,（续）,94,5.3.1 什么是版本控制,版本控制是SCM的基础，它管理并保护开发者的软件资源。,版本控制管理在软件工程过程中建立起,配置对象的不同版本,。,版本管理可以把,一些属性结合到各个软件版本,上。,通过,描述所希望的属性集合,来,确定,（或,构造,）,所想要的配置,。,使用,演变图,来表示系统的不同版本。,5.3,版本控制,95,5.3.2 版本控制的主要任务,集中管理档案，安全授权机制,：,版本管理的操作,将开发组的档案集中地存放在服务器上,，,经系统管理员授权给各个用户,。,用户通过登入（,check in,）和检出（,check out,）的方式访问服务器上的文件，未经授权的用户无法访问服务器上的文件。,软件版本升级管理,：,每次登入时，在服务器上都会生成新的版本。,任何版本都可以随时检出编辑，同一应用的不同版本可以像树枝一样向上增长。,5.3,版本控制（续）,96,5.3.2 版本控制的主要任务,加锁功能,：,目的是,在文件更新时保护文件,，,避免不同用户更改同一文件时发生冲突,。,某一文件一旦被,登入,，,锁即被解除,，该文件可被其它用户使用。,在,更新一个文件之前锁定它,，避免变更没有锁定的项目源文件。,5.3,版本控制（续）,97,5.4.1 变更控制的意义,软件生存期内全部的软件配置是软件产品的真正代表,，必须使其保持,精确,。,软件工程过程中,某一阶段的变更,，均要,引起软件配置的变更,，这种变更必须严格加以,控制,和,管理,，保持修改信息。,变更控制包括,建立控制点,和,建立报告与审查制度,。,5.4,变更控制,98,5.4,变更控制（续）,5.4.2 变更控制过程,99,5.4,变更控制（续）,5.4.2 变更控制过程,100,5.4.,2,变更控制过程,首先用户提交书面的,变更请求,，详细申明变更的,理由,、变更,方案,、变更的,影响范围,等。,然后由,变更控制机构,确定控制变更的,机制,、评价其,技术价值,、潜在的,副作用,、对其它配置对象和系统功能的综合,影响,以及项目的,开销,、并把评价的结果以,变更报告,的形式提交给变更控制负责人。,对每个批准了的变更产生一个,工程变更顺序,（,ECO,），描述进行的变更、必须考虑的约束、评审和审计的准则等。,要做变更的对象从项目数据库中,检出,（,check out,），对其做出,变更,，并实施适当的,质量保证活动,。然后再把对象,登入,（,check in,）到数据库中并使用适当的版本控制机制建立软件的下一版本。,5.4,变更控制（续）,101,5.4.,3,软件变更不同情况,为改正小错误需要的变更,。它是必须进行的，通常不需要从管理角度对这类变更进行审查和批准。但是，如果发现错误的阶段在造成错误的阶段的后面，例如在实现阶段发现了设计错误，则必须遵照标准的变更控制过程，把这个变更正式记入文档，把所有受这个变更影响的文档都做相应的修改。,5.4,变更控制（续）,102,5.4.,3,软件变更的不同情况,为了增加或者删掉某些功能、或者为了改变完成某个功能的方法而需要的变更,。这类变更必须经过某种正式的变更评价过程，以估计变更需要的成本和它对软件系统其它部分的影响。,如果变更的代价比较小且对软件系统其它部分没有影响，或影响很小，通常应批准这个变更。,如果变更的代价比较高，或者影响比较大，则必须权衡利弊，以决定是否进行这种变更。,如果同意这种变更，,需要进一步确定由谁来支付变更所需要的费用。,如果是用户要求的变更，则用户应支付这笔费用；否则，必须完成某种成本效益分析，以确定是否值得做这种变更。,5.4,变更控制（续）,103,5.4.,3,软件变更的不同情况,这种变更报告和审查制度，对变更控制来说起了一个安全保证作用。,在一个SCI成为基线之前，可以对所有合理的项目和技术申请进行非正式的变更；,一旦某个SCI经过正式的技术评审并得到批准，它就成了基线。以后如果需要对它变更，就必须得到项目负责人的批准，或者必须得到变更控制负责人的批准。,5.4,变更控制（续）,104,谢谢大家,本讲义部分取材于北京航空航天大学可靠性工程研究所，特此致谢,深圳旋极公司,2001.8,105,