软件工程实践(10)质量和风险管理.ppt

1、北京理工大学软件工程实践,汤铭端 中国航天科工集团公司706所,第十讲,质量管理与质量保证 评审与审查 风险管理,目的与内容,掌握质量的概念 了解质量管理和质量保证的内容和过程 掌握评审和审查的过程 了解和掌握风险管理的概念与过程,质量管理,质量的概念,质量定义：反映实体满足明确和隐含需要能力的特性综合 定义的说明： 明确需要：指合同中用户明确提出的要求与需要 隐含需要：指由生产企业通过市场调研进行识别与探明的要求或需要 特性：实体所特有的性质，反映了实体满足需要的能力,软件质量的定义,ANSI/IEEE Std 729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征

2、或特性的全体”。 M.J. Fisher 定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。,质量特性及其组合,为满足软件的各项精确定义的功能、性能需求，符合文档化的开发标准，需要相应地给出或设计一些质量特性及其组合。 如果这些质量特性及其组合都能在产品中得到满足，则这个软件产品质量就是高的。 软件需求是度量软件质量的基础。不符合需求的软件就不具备质量。 标准定义了一组开发准则，用来指导软件人员用工程化的方法来开发软件。如果不遵守这些开发准则，软件质量就得不到保证。 软件质量是各种特性的复杂组合。它随着应用的不同而不同，随着用户提出的质量要求不同而不同。,什么是软件质量,项目的质量,质

3、量的类型： 质量，通常指产品的质量，广义的还包括工作的质量。产品质量是指产品的使用价值及其属性； 而工作质量则是产品质量的保证，它反映了与产品质量直接有关的工作对产品质量的保证程度。,项目的质量 从项目作为一次性的活动来看，项目质量体现在由WBS反映出的项目范围内所有的阶段、子项目、项目工作单元的质量所构成，也即项目的工作质量； 从项目作为一项最终产品来看，项目质量体现在其性能或者使用价值上，也即项目的产品质量。,产品质量与过程质量,软件质量特性与模型,软件质量特性，反映了软件的本质。讨论一个软件的质量，问题最终要归结到定义软件的质量特性。 定义一个软件的质量，就等价于为该软件定义一系列质量特

4、性。 人们通常把影响软件质量的特性用软件质量模型来描述。,软件质量模型,软件质量特性定义成分层模型 最基本的叫做基本质量特性，它可以由一些子质量特性定义和度量。 二次特性在必要时又可由它的一些子质量特性定义和度量。 1976年 Boehm质量模型 1979年 McCall质量模型 1985年 ISO质量模型,McCall软件质量11特性,使用性 正确性 可靠性 效率 完整性 适应性,测试性 维护性 移植性 重用性 互操作性,Boehm质量模型,ISO的软件质量评价模型,按照ISO/TC97/SC7/WG3/1985-1-30/N382，软件质量度量模型由三层组成 软件质量需求评价准则（SQRC

5、） 软件质量设计评价准则（SQDC） 软件质量度量评价准则（SQMC） 高层和中层建立国际标准，低层可由各使用单位视实际情况制定,（ISO/IEC9126，1991年）质量特性,质量特性：功能性、可靠性、可维护性、效率、可使用性、可移植性 推荐21个子特性：适合性 准确性 互用性 依从性 安全性 成熟性 容错性 可恢复性 可理解性 易学习性 操作性 时间特性 资源特性 可分析性 稳定性 可变更性 可测试性 可安装性 可替换性 适应性 一致性,质量成本,质量成本是实施单位为了保证和提高产品质量、满足用户需要而支出的费用，以及因未达到质量标准而产生的一切损失费用的总和。 简单地说，质量成本可被分成

6、“一致成本”和“不一致成本” 一致成本包括：培训、指导、查证、确认、测试、维持、测量、审查等的费用 不一致成本包括：损耗、返工、维修、产品回收、投诉处理等的费用 通过缩减一致成本来节省费用会带来灾难性后果 第一次要完全正确,另外的区分费用的通用方法,预防成本 关注第一个以及以后诸个无瑕疵产品对顾客需求满足程度的预先成本 如设计评价、培训、QA、供给调查等预防活动 评估成本 评价产品或过程以确定如何满足所有客户需求相关的费用 如产品检查、测试、设计评审等 内部故障成本 与满足客户需求在脱离组织控制前出现故障相关的费用 如损耗、返工、维修、停工期、瑕疵评估、损耗评估等 外部故障成本 与那些需求没能

7、满足的客户的决定相关的费用 如客户退货和补贴、客户抱怨评估、检查、调查、纠正等,总质量成本,预防,评估,内部故障,外部故障,节约,当前,未来,最小化质量总成本,50%或更多的质量成本来自内外部的故障 故障的完全消除是一个理想但非有效的解决方案 Juran： 只要每单位的评价和预防费用低于非一致成本，资源会分配到预防和评价中 当预防和评价成本开始增加每单位的质量成本时，策略是维持质量不变 最小化质量总成本,内外部故障成本,评估和预防成本,总质量成本,100%次品,100%合格品,最优质量成本,每单位合格产品的质量成本,最小质量成本,质量管理的内容,质量计划 质量控制 质量保证,戴明环PDCA P

8、：Plan-计划 D：Do-实施 C：Check-检查 A：Action-处理,质量管理,质量管理即在质量方面指挥和控制组织的协调活动 质量管理是指确定质量方针、目标和职责并在质量体系中通过诸如质量策划、质量控制、质量保证和质量改进并使其实施的全部管理职能的活动 质量方针 质量目标 质量策划 质量控制 质量保证 质量改进,戴明环PDCA环,P：Plan-计划 D：Do-实施 C：Check-检查 A：Action-处理,质量计划,质量计划的目的主要是确保项目的质量标准能够得以满意的实现，其关键是在项目的计划期内确保项目按期完成，同时要处理与其他项目计划之间的关系。,质量计划的内容,需达到的质量

9、目标 质量工作具体流程 在项目各个不同阶段，职责、权限和资源的具体分配 项目实施中需采用的具体的书面程序和指导书 有关阶段适用的试验、检查、检验和评审大纲 达到质量目标的测量方法 随项目的进展而修改和完善质量计划的程序 为达到项目质量目标必须采用的其它措施,项目质量控制,质量控制主要是监督项目的实施结果，将项目的结果与事先制定的质量标准进行比较，找出其存在的差距，并分析形成这一差距的原因，质量控制同样贯穿于项目实施的全过程。项目的结果包括产品结果（如交付）以及管理结果（如实施的费用和进度）。质量控制通常是由质量控制部门或类似的质量组织单元实施，但是也并非总是如此。,质量保证,质量保证是所有计划

10、和系统工作实施达到质量计划要求的基础，为项目质量系统的正常运转提供可靠的保证，它应该贯穿于项目实施的全过程之中。在ISO9000系列实施之前，质量保证通常被描述在质量计划之中。 质量保证通常是由质量保证部门或者类似的组织单元提供，但是不必总是如此。质量保证通常提供给项目管理组以及实施组织（内部质量保证）或者提供给客户或项目工作涉及的其它活动（外部质量保证）。,“质量保证”与“保证质量”,保证质量是质量控制的任务 用户不提QA，项目实施者也要进行质量控制，保证项目质量满足用户要求 QA是以保证质量为基础，进一步引伸到提供质量“信任”这一基本目的 QA的主要工作是促进完善质量控制，以便准备好客观证

11、据，并根据对方的要求有计划、有步骤地开展提供证据的活动 “保证”有“保险”的意义,软件质量保证,软件质量保证的目的是向管理者提供适当的对软件项目正使用的过程和正构造产品的可视性。 软件质量保证包括评审和审计软件产品和活动以验证它们符合适用的规程和标准，给项目和其它有关的经理提供这些评审和审计的结果。,SQA的问题处理渠道,首先在软件项目内部处理符合性问题，如可能的话就地解决它。 对于那些无法在软件项目内部解决的问题，软件质量保证组逐级上递该问题到管理者的恰当层次以求得解决。,SQA的目标,目标1 软件质量保证活动是有计划的。 目标2 软件产品和活动遵守适用的标准、规程和需求的情况得到客观的验证

12、。 目标3 受影响的组和个人接到软件质量保证活动和结果的通知。 目标4 高级管理者处理在软件项目内部不能解决的不符合问题。,SQA的独立性,存在负责协调和实施项目的SQA的组 SQA有一个向高级管理者报告的渠道，它独立于：项目经理，软件工程组，其它的有关组 组织机构支持那些要求独立性的活动，如SQA 独立性应该： 给担当SQA角色的个人提供组织上的自由度，使他们成为高级管理者在软件项目上的“耳目”。 使得担当SQA角色的个人免受他们正在评审的软件项目的管理者所作的性能评价的影响。 使高级管理者相信正在报告的有关项目过程和产品的信息是客观的。,SQA过程活动,活动1 按照已建档的规程为软件项目制

13、订SQA计划 活动2 按照SQA计划进行SQA组的活动 活动3 SQA组参与准备和评审项目的软件开发计划、标准和规程 活动4 SQA组评审软件工程活动以验证符合性 活动5 SQA组审计指定的软件工作产品以验证符合性 活动6 SQA组定期向软件工程组报告其活动的结果 活动7 按照已文档化的规程对在软件活动和软件工作产品中所鉴别出的偏差建立文档并加以处理 活动8 SQA组与顾客的SQA人员一起对它的活动和发现进行定期评审,SQA计划的内容,1. SQA组的职责和权力 2. SQA组的资源要求 3. 项目的SQA组活动的进度表和投资 4. SQA组参加制定项目的软件开发计划、标准和规程的情况 5.

14、将由SQA完成的评价 6. 将由SQA组进行的审计和评审 7. 将用作SQA组评审和审计的基础的项目的标准和规程 8. 用于对不符合性问题建立文档和进行跟踪直至结束的规程 9. 要求SQA组生成的文档 10.就SQA活动给软件工程组和其它软件有关组提供反馈信息的方法和频率,软件可靠性与容错设计,软件可靠性,软件可靠性定义,在给定时间间隔内和特定的环境下，软件按规格说明成功运行的概率。,软件可靠性的主要指标,借用硬件可靠性的定量度量方法来度量软件的可靠性： MTBF:平均故障间隔时间 MTTF:平均故障时间 t1，t2, ., tn:失效时间,软件可靠性定义的要素,(1)环境条件 规定软件的使用

15、环境 (输入数据要求和环境) (2)规定时间 时间t是随机变量。 (3)规定的功能 (4)成功运行,软件容错技术,提高软件质量和可靠性的技术: 避开错误技术 容错技术 对无法避开的差错，使其影响减至最小的技术,什么是容错软件？,定义1：规定功能的软件，在一定程度上对自身错误的作用具有屏蔽能力的软件； 定义2：规定功能的软件，在一定程度上能从错误状态自动恢复到正常状态的软件； 定义3：规定功能的软件，在因错误而发生错误时，仍能在一定程度上完成预期的功能的软件。,容错的一般方法,实现容错计算的方法（容错资源）： 错误检测算法 错误恢复算法 软件冗余备份 容错软件 主体：常规软件所需资源 附加体：容

16、错资源 实现容错计算的主要手段是冗余,容错,冗余技术分类： 结构冗余 静态冗余 动态冗余 混合冗余 信息冗余 时间冗余,软件的容错系统结构 多版本结构 恢复块结构,结构冗余：静态冗余,3模冗余、多模冗余 3模（TMR）表决系统的结构,结构冗余：动态冗余,多重模块待机储备,相继运行 待机储备系统结构,结构冗余：混合冗余,混合冗余 H（N，K）结构,信息冗余,以检测或纠正信息在运算或传输中的错误为目的而外加的一部分信息 误差校正码： 奇偶码 定重码 循环码 ,时间冗余,以重复执行指令（指令复执）或程序（程序复算）来消除瞬时错误带来的影响 常用的程序复算方法：程序滚回技术,容错结构：多版本结构,把同

17、一功能的不同版本的程序(多为子系统或模块级)并行联结到系统中,构成冗余并行模型 多版本程序示意图,容错结构：恢复块结构,恢复块的工作方式,评审与审查,Review & Inspection,概论,在软件的研制过程中必须进行的一项重要工作，就是软件的验证与确认。 软件验证是确定软件开发周期中的一个给定阶段产品是否达到前阶段确立的需求的过程。它包括评审、审查、测试、检查、审计等项活动。 软件确认是在软件开发过程结束时对软件进行评价，以确认它和软件需求是否相一致的过程。也可以说，确认是“端到端”的验证。,什么是验证与确认,验证和确认是两项相辅相成的工作，但它们之间却极易混淆。 软件工程权威Barry

18、 W. Boehm曾巧妙地用两句形式相似但内容不同的话作过精辟的描述： Verification: Are we building the product right? Validation: Are we building the right product? 验证：我们正正确地制造产品吗？ 确认：我们正制造正确的产品吗？,为什么IV&V,不论项目大小如何，软件验证与确认很大程度地影响着软件的质量。 人总是会犯错误的，而没有经过验证的软件将难以正常工作。 有典型事例说明在开发期间每1000行代码中发现有20到50个错误，而即使是在系统测试之后每1000行代码中仍有1.5到4个错误。 软件验证

19、与确认的目标是把错误减少到可以接受的水平。 软件的验证与确认工作占用整个项目的30%90%的资源。,验证与确认V形图,软件开发工作开始于图的左上角，沿左边的产生“软件规格”侧向下进行到“”的底端，其间要逐阶段进行验证； 之后沿右边的产生“软件产品”侧向上，之间对应着它们对“软件规格”的验证。 形图强调在左侧按照输入验证每个输出及在右侧根据“软件规格”验证软件产品。,V形图验证与确认说明,根据系统需求验证软件需求 根据软件需求验证概要设计 根据概要设计验证详细设计 根据详细设计验证编码 用单元测试验证详细设计 用组装测试验证概要设计 用确认测试验证软件需求 用系统联试验证系统需求,通过评审进行I

20、V&V,对软件的工作产品进行验证的一个重要方法是评审。 评审是把工作产品或工作产品集提交给项目人员、经理、用户、顾客或其它感兴趣各方进行评价或批准的过程或会议。 评审一般有技术评审、审查、走查、审计等多种形式。 检查阶段工作的管理评审称作阶段评审。,为什么要及早进行评审,1)程序中的大部分错误是在编码之前造成的。据统计，设计及之前阶段产生的错误大约占63，而编码错误仅占37。 2)错误的检测与改正时间越晚，所付出的代价也就越高。通过对一些大型软件项目的分析表明；如果在需求和设计阶段发现一个错误，改正所需费用为1；那么在测试前发现该错误，改正费用则为6.5；在测试时发现，改正费用为15；而在交付

21、使用后再发现，改正费用则高达67。 3)错误还会被“放大”。,阶段评审,评审的目的 阶段评审在软件研制的各个阶段完成了预定工作时进行，目的是检查该阶段工作是否完成，是否达到了规定的质量和技术要求，检查计划管理、质量管理、风险管理、配置管理的执行情况，决定是否可以转入下一个研制阶段。 各研制阶段结束时均应进行阶段评审。,评审组成员 评审由项目组上级主管机构组织，组长由上级主管领导担任。成员包括： 1）主管领导； 2）同行专家； 3）质量管理人员； 4）科研（计划）管理人员； 5）项目组成员； 6）交办方代表（必要时）。,阶段评审程序（1）,（1）评审前的准备 准备阶段评审汇报和被评审文件。汇报内

22、容： 1）本阶段研制工作的主要内容和完成情况； 2）为保证产品质量所做的质量保证工作； 3）计划落实和配置管理情况； 4）本阶段出现的主要问题及解决情况； 5）结论及建议。 （2）确定评审人员和日期 （3）评审组分工 （4）评审组审阅评审文件 承办单位提前三天将评审文件提交评审组审阅,阶段评审程序（2）,（5）评审会议 1）软件研制项目组作阶段评审汇报； 2）评审组询问、讨论、审查各项工作，项目组答辩； 3）评审组作出评审结论并由组长宣布。 （6）填写评审总结报告 （7）评审后的工作 评审结论入配置管理、保存备案、交上级审批。 项目组针对修改意见和改进建议，经审批进行修改补充。 项目组根据评审

23、意见，转入下一研制阶段。,阶段评审表,在每次阶段评审时，都必须履行正式手续，填写必要的评审表格，以利于项目管理和质量检查。 阶段评审表由三张子表组成 子表1是对评审中发现问题的记录 子表2是评审总结报告 子表3是评审小组成员登记与签字表 对于在评审中发现的软件问题，用软件问题报告单对问题进行详细的描述。,技术评审,以下技术评审过程是欧洲航空局最佳实践过程之一 目的 技术评审的目的是对具体的工作产品集（如文档、源代码）进行评价，并对管理提供以下信息： 它们符合前一阶段制定的软件规格； 它们已按照项目的标准和方法完成； 所有的更改都正确地得到完成，并只影响对更改规定的范围。,组织,技术评审过程由评

24、审组来执行，评审组中有以下的角色： 负责人 秘书 成员,职责,负责人的责任包括： 提名评审组； 组织评审并通知所有参加者评审的时间、地点和日程； 会议前向所有参加者分发评审项并在必要时分配评审项； 必要时组织评审组开展准备工作； 主持评审会议； 发布技术评审报告。 必要时秘书应协助负责人，并负责记录评审组发现的问题、作出的决定和建议。,职责,各评审组成员检查评审项并参加评审会议。 如果被评审项规模大、复杂或需要各种专业的专家技能才能进行有效的评审，那么负责人可以在成员中分配评审项。,输入,适当时，对技术评审过程的输入包括： 评审会议日程； 对目的的陈述； 评审项（如被评审的软件需求规格说明、软

25、件概要设计说明）； 评审项应符合的上阶段给出的软件规格（如评审软件详细设计说明时所对应的软件概要设计说明）； 评审项使用的计划、标准及指南； 与评审项有关的评审差异表、软件问题报告单，修改报告单； 软件质量保证人员的报告。,活动=准备+评审会议,准备 负责人起草日程表，并将其与目的、被评审项、规格、计划和指南一起散发给评审组。 评审组成员对评审项进行检查。通过完成评审差异表来对在检查中发现的每个问题进行记录。将评审差异表退还给秘书。 负责人将每张评审差异表按主要的、次要的或编辑上的进行分类 由秘书按被评审项中偏差的位置对评审差异表进行排序。,活动=准备+评审会议,评审会议 1)开始； 2)展示

26、被评审项； 3)评审差异表的分类； 4)对主要的评审差异表的评审； 5)对其它的评审差异表的评审； 6)结论。,评审结论,典型的结论是： 授权进行下一步的工作，条件是完成更改工作和采取措施； 授权进行限定部分的工作； 执行决定的附加工作。 如未能对达成一致意见和得出结论，则： 在评审报告中记录非主流的不同观点； 由一名或多名成员在会议外寻找解决方法； 把问题移交给上一级管理部门。,输出,报告摘要； 成员名单； 被评审项的确定； 按照分类编组的带处置标志的评审差异表、软件问题报告单、软件修改报告单等； 措施清单，以及各措施的人员责任和预期完成日期； 结论。 输出可采取会议记录的形式，或采取独立报

27、告的形式。 报告应足够详细，以便于管理部门判断发生了什么事。 如果在评审期间难以达成一致意见，可建议评审组成员对输出不签字。,软件审查,软件审查可用于编码前发现详细设计中的缺陷，在测试前发现代码的缺陷。软件审查也可以用于验证测试设计、测试用例和测试过程。 软件审查是有效的。通过审查，可以查出开发过程所带给项目的全部缺陷的50%。 软件审查是经济的，因为它可以大大减少缺陷的数量和降低消除缺陷的费用。在缺陷产生后尽可能短的时间内发现缺陷可以： 使软件开发者增强查找缺陷产生原因的意识，以便减少类似缺陷再出现的可能性； 使查找缺陷的工作量减少，因为不需要在许多可能的组成部分以外去诊断哪个组成部分有缺陷

28、。,审查的目的,软件审查的目的是查出文档或代码中的缺陷。,软件审查的组织,主任：主任领导审查并主持审查会。主任应具备完成这项工作的技能，而不必要精通所审查的项目。他（她）必须是公平的、客观的。鉴于这些原因，主任常常从与项目无关的职员中选出。最好他们受过有关审查过程的培训。 秘书：秘书负责记录审查会的记录，特别是记录发现的每个缺陷的细节。 阅读员：阅读者引导审查组遍历被审查项。 审查员：审查员在审查时确定和描述被审查项的缺陷。选择的审查员应能代表各种观点（如：设计员、编码员和测试员）。 作者：作者是被审查项的编制人员。作者主要回答关于被审查项的问题，并负责所有的修改。 一个人可担任上述一种或多种

29、角色。没有人既担任作者又担任其它角色。,软件审查的输入,被审查项（如源代码，或其它文档） 被审查项应符合的规格（如详细设计） 审查检查单 应用于被审查项的标准和指南 审查报告表 从上一次审查中获得的缺陷表,活动=综述、准备、审查会、修改、补充活动,综述是对被审查项进行介绍。 之后审查员对被审查项进行熟悉，作好参加审查会的准备。 然后，审查员在审查会上检查被审查项、确定缺陷并决定是否对缺陷进行纠正。 修改工作包括对故障的修复。 补充活动是指检查在审查会上作出的所有决定是否都得到了执行。,审查的时间和速度,代码审查的初始参考值： 准备：每小时125行非注释源代码； 审查会：每小时90行非注释源代码

30、。 对伪码或PDL的审查，上述数字应加倍。 审查会不应超过两个小时。,软件审查活动,综述：综述的目的是向审查组介绍被审查项。主任介绍要审查的范围，然后详细介绍设计的具体的范围，再将输入分配给参加者。,软件审查活动,准备：主任、阅读员和审查员对输入进行熟悉。通过阅读下列资料来做好代码审查的准备： 要审查的代码设计规范； 编码标准； 含以前审查发现的普遍编码错误的代码审查检查单； 被审查的代码。 被审查项的缺陷要在评审差异表中记录，并在审查过程中合适的时候进行宣布。准备工作应单独进行，而不要在会议上进行。,软件审查活动-审查会,主任检查成员的准备工作，报告和记录各成员所花费的时间。 由阅读员引导会

31、议遍历被评审项。对文件阅读员可总结某些部分的内容，并一行一行地读完所有内容。对代码阅读员应覆盖每个逻辑块，至少详细讨论每个分支一次。审查员利用检查单来发现普遍错误。 秘书对阅读中发现的缺陷立即进行记录。包括下列的内容： 严重性、技术分类、位置、描述 不记录确定的任何解决措施。审查组应避免寻找解决措施，而应集中精力发现缺陷。 在审查会结束前，审查组应作出下列中的一种决定： 当修改完成之后（如果有）接收该审查项； 当修改完成之后由主任负责接收该审查项； 重新审查整个被审查项（如果5%以上需要修改）。 秘书应在之前起草会议纪要，以便修改工作能及时地进行。,软件审查活动,修改 审查之后，软件作者纠正缺陷清单中列出的缺陷。 补充活动 修改之后，补充活动验证所有的缺陷都得到了正确的纠正，而无其它缺陷被引入。 主任负责补充活动。 其它补充活动是： 依据不同错误类型变化的频率修改检查单； 分析缺陷统计资料，也许会导致对软件验证与确认工作的改进。,软件审查的输出,缺陷单 缺陷统计 审查报告,技术评审和审查指南,事先必须建立技术评审和审查工作指南，分发给所有的评审（审查）人员共同遵守。一个不受控制的评审会常常出错，可能会比不评审更坏。,技术评审和审查指南的基本内容,(1) 评审产品，不评审生产者 (2