LEVEL 2-5_软件质量保证

网络与交换技术国家重点实验室 1 软件能力成熟度模型 (CMM: Capability Maturity Model ) 张 雷 网络与交换技术国家重点实验室 2 LEVEL 2关键过程域  需求管理(Requirements management)  软件项目计划(Software Project Planning)  软件项目跟踪与监督(Software Project Tracking and Oversight)  软件分包 合同 劳动合同范本免费下载装修合同范本免费下载租赁合同免费下载房屋买卖合同下载劳务合同范本下载 管理(Software Subcontract Management)  软件质量保证(Software Quality Assurance)  软件配置管理(Software Configuration Management) 3 概述  目的  向管理者提供对软件项目的过程和产品的适当 的可视性  包括  评审和审计软件产品和活动以验证它们是否遵 守应用的规程和 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载  向软件项目和其它相关的经理提供这些评审和 审计的结果 4 概述  在软件项目的早期阶段，软件质量保证组参与软件项目的 制定计划、标准和规程等，这些计划、标准、和规程将增 加软件项目的价值并将满足项目和组织方针上的限制。  软件质量保证组参与制定计划、标准和规程，有助于确保 它们适合项目的需要，并且验证它们能否用于软件生命周 期中的评审和审计。  在整个生命周期中，软件质量保证组评审项目活动，审计 软件工作产品，并就软件项目是否正遵守已制定的计划、 标准和规程等给管理者提供可视性。 5 概述  不一致问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 首先在软件项目内部处理，尽可能地解决它。 对于那些无法在软件项目内部解决的问题，软件质量保 证组逐级上递该问题给适当层次的管理者去解决。  这个关键过程区域只包括该组履行软件质量保证职能的 实践。  识别软件质量保证组要评审和（或）审计的具体的活动 和工作产品的实践一般包含在其它关键过程区域的验证 实施共同特点中。 6 目标(Goals)  目标1  软件质量保证活动是有计划的  目标2  客观地验证软件产品和活动是否遵守适用的标准、规程 和需求  目标3  将软件质量保证活动和结果 通知 关于发布提成方案的通知关于xx通知关于成立公司筹建组的通知关于红头文件的使用公开通知关于计发全勤奖的通知 相关的组和个人  目标4  高级管理者处理在软件项目内部不能解决的不一致问题 7 执行约定 （Commitment to perform）  约定1  项目遵循书面的机构管理策略来实施软件质量 保证（SQA）  该策略一般规定  SQA职能在所有软件项目中占有一定地位  SQA组有一个向高级管理者报告的渠道  组织必须确定一种组织机构来支持那些要求独立性 的活动，例如SQA  高级管理者定期地评审SQA 活动和结果 8 执行能力 (Ability to perform)  能力1  存在一个负责协调和实施项目的软件质量保 证活动的小组（即SQA 组）  某些组，例如软件质量保证组，集中注意力于项 目活动，而其它组，例如软件工程过程组，则集 中关注全组织的活动 9 执行能力 (Ability to perform)  能力2  为进行SQA 活动提供足够的资源和投资  指派一个经理专门负责项目的SQA 活动  指派一个高级经理接收和处理软件不一致问题， 他具有SQA 方面的知识，并有权力采取适当的监 督行动  依次向高级经理报告SQA情况的所有经理均具有SQA的 知识、职责和权力。  有支持SQA 活动的工具 10 执行能力 (Ability to perform)  能力3  SQA 组的成员接受过完成相应的SQA任务所需的培训  能力4  软件项目的成员接受有关SQA 组的任务、职责、权 力和作用等方面的定向培训 11 执行的活动 (Activities performed)  活动1  按照已文档化的规程为软件项目制订SQA计划  该规程一般规定：  SQA 计划在整个项目策划的早期阶段制定，二者同步进行  由相关的组和个人评审该SQA 计划  对SQA 计划进行管理和控制。 12 执行的活动 (Activities performed)  活动2  SQA 组按照SQA 计划进行活动  该计划包括：  SQA 组的职责和权限  SQA 组的资源要求（包括职员、工具和设施）  项目的SQA 组活动的进度计划和资金  SQA 组参加制定项目的软件开发计划、标准和规程的活动  由SQA组实施的评价  由SQA 组进行的审计和评审  用作SQA 组评审和审计基础的项目标准和规程  用于对不一致问题建立文档和进行跟踪直至结束的规程  要求SQA 组生成的文档  向软件工程组和其它软件相关组提供反馈SQA活动信息的方法和频率 13 执行的活动 (Activities performed)  活动3  SQA 组参与制定和评审项目的软件开发计划、标准和 规程  SQA 就以下几个方面对计划、标准和规程提供咨询和评审：  与组织方针的一致性  与外部强加的标准和要求的一致性（例如工作说明所要求的标 准）  适合项目使用的标准  在软件开发计划中应阐述的问题  项目指定的其它问题。  SQA 组验证计划、标准和规程是否已到位，并可用于 评审与审计软件项目 14 执行的活动 (Activities performed)  活动4  SQA 组评审软件工程活动以验证其一致性  对照软件开发计划和指定的软件标准和规程去评 价活动  鉴别和记录存在的偏差，并跟踪到结束  验证纠正措施 15 执行的活动 (Activities performed)  活动5  SQA 组审计指定的软件工作产品以验证其一致性  在交付给顾客之前，评价可交付的软件产品  对照指定的软件标准、规程和合同要求评价软件工作产品  识别和归档存在的偏差，并跟踪到结束  验证纠正措施  活动6  SQA 组定期向软件工程组报告其活动的结果 16 执行的活动 (Activities performed)  活动7  按照书面规程，归档和处理软件活动和软件工作产品 中的偏差  该规程一般规定  将不符合软件开发计划和指定的项目标准及规程的问题写成 文档，并在可能时，由适当的软件作业领导、软件经理或项 目经理一起加以解决。  对于不能由软件作业领导、软件经理或项目经理一起加以解 决的偏差建立文档，并提交给指定的接收不一致问题的高级 经理  定期评审提交给高级经理的不一致问题直至解决它们为止  对不一致问题的文档进行管理和控制 17 执行的活动 (Activities performed)  活动8  合适时，SQA 组与客户的SQA 人员一起定期 评审SQA小组的活动和结果 18 测量和分析 (Measurement and analysis)  测量1  测量SQA 活动的成本消耗和进度情况  测量的例子有  SQA 活动的里程碑的完成情况，与计划作比较  在SQA 活动中所完成的工作、所化费的工作量和 所消耗的资金，与计划作比较  产品审计和活动评审的次数，与计划相比较 19 验证实施 (Verifying implementation)  验证1  高级管理者定期参与评审SQA 活动  验证2  项目经理既定期地根据实际需要随时评审 SQA 活动  验证3  独立于SQA 组的专家定期评审项目SQA 组的 活动和软件工作产品 20 总结  关键实践与目标的对应关系  目标1  约定1  能力1,2,3  活动1,2  测量1  验证2,3  目标2  约定1  能力1,2,3,4  活动2,3,4,5,6  测量1  验证2,3  目标3  约定1  能力1,2,3,4  活动6,7,8  测量1  验证1,2,3  目标4  约定1  能力1,2,3,4  活动6,7,8  测量1  验证1,2,3 进 入 准 则 1 . 方 针 明 确 2 . 能 力 具 备 3 . 项 目 已 定 义 4 . 已 有 两 项 必 要 的 规 程 输 入 1 . 软 件 工 作 说 明 文 件 2 . 合 同 中 的 相 关 说 明 或 协 议 3 . 相 关 的 标 准 和 规 程 ， 如 ： 过 程 标 准 、 开 发 标 准 、 测 试 标 准 等 1 . 按 规 程 为 项 目 制 定 S Q A P 2 . 按 计 划 进 行 S Q A 活 动 3 . 参 与 准 备 和 评 审 软 件 开 发 计 划 、 标 准 和 规 程 1 . 评 审 软 件 工 程 活 动 2 . 审 核 指 定 的 工 作 产 品 定 期 向 软 件 工 程 组 报 告 结 果 按 规 程 处 理 偏 差 并 建 立 文 档 与 客 户 的 S Q A 组 一 起 评 审 自 己 的 S Q A 活 动 和 发 现 退 出 准 则 1 . 产 品 符 合 需 求 2 . 数 据 记 录 完 整 、 并 受 控 输 出 1 . 软 件 S Q A 计 划 2 . 项 目 采 用 的 标 准 和 规 程 3 . 各 种 评 审 和 审 核 活 动 的 记 录 和 报 告 、 问 题 报 告 、 解 决 报 告 、 与 软 件 质 量 相 关 的 数 据 测 量 、 分 析 和 验 证 实 施 图示： ETVX总结 22 关于软件质量保证的讨论  质量的概念  软件评审 23 质量的概念  “质量管理的问题不在于人们不知道什么是质量，问题在 于人们认为他们自己对质量知道…”  软件质量  设计质量  设计者为一件产品规定的特征：需求、规约和设计。  符合质量  在制造过程中符合设计规约的程度：实现。  软件质量定义：软件要符合显式声明的功能和性能需求、显式文 档化的开发标准以及专业人员开发的软件所应具有的所有隐含特 征。——Roger S. Pressman 24 质量的概念  质量的核心  用户满意度的定义：  用户满意度＝合格产品＋好的质量＋在预算和进度表内交付  一个软件产品向用户提供了实质性的益处，他们可能愿意忍受偶 尔的可靠性和性能问题  质量控制  质量控制的核心：差异控制  软件质量控制：为了保证每一件工作产品都满足对它的需求而应 用于整个开发周期中的一系列审查、评审和测试  软件质量控制关键：所有工作产品都具有定义好的可度量的规约 25 质量成本  质量成本包括所有由质量工作或者进行与质量有关的活动 所导致的成本。  质量成本分为：预防成本，鉴定成本，故障成本  预防成本：大量的预防成本可以保证投资获得很好的回报  质量计划/正式技术评审/测试设备/培训  鉴定成本：为深入了解“首次通过”每个过程时产品的状态 而开展的活动  过程内和过程间的审查/设备校准和维护/测试 26 质量成本  故障成本  内部故障成本：产品交付前发现错误而引发的成本  返工  修复  故障模式分析  外部故障成本：与产品交付给客户后所发现的缺陷相关成本  解决客户的抱怨  退换产品  求助电话支持  保修工作 27 质量成本  “发现和修改一个缺陷的成本会随着从预防到 检测、到内部故障成本到外部故障成本而急剧 增加。”——IBM的报告  测试是必要的，但是它一种是非常昂贵的发现 错误的方式。  在过程早期发现错误可以大大减少测试和调试 成本。 28 质量保证  质量保证由管理层的审计和报告构成  目标是为管理层提供为获得产品质量信息所需的 数据  软件质量保证历史  1916年第一个正式的质量保证和控制 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 在贝尔实验 室出现  20世纪50－60年代，软件质量保证只由程序员承担  70年代，软件质量保证标准首先在军方的软件开发合 同中出现 29 软件质量保证  定义：为了保证软件高质量而必需的“有计划和系统化的 行动模式”  含义：组织中有许多参与者负有保证软件质量的责任， 包括：软件工程师、项目管理者、客户、销售人员和SQA 小组的成员  SQA小组充当客户在公司内部的代表：以客户的观点看待 软件  SQA小组职责：辅助软件工程小组得到高质量的最终产品  软件工程师的保证质量的方法：  采用可靠的技术和措施  进行正式的技术评审  执行计划周密的软件测试 30 软件评审  “软件评审就像水的过滤器一样，FTR往往延缓软件工程活 动的‘流’，太少，‘流’较脏；太多，‘流’较细…”  评审是借助人的差异性来  指出一个人或小组生产的产品所需进行的改进  确定产品中不需要或者不希望改进的部分  得到与没有评审相比更加一致、或者至少更加可预测 的技术工作的质量，从而使得技术工作更易于管理  评审的种类：  非正式评审: 技术问题的讨论  正式评审(FTR：Formal Technical Review Walkthrough, inspection)：最有效的过滤器 31 软件正式评审（FTR）  缺陷的放大和消除  “正如医生所说，某些疾病在其初发阶段是易于治愈的，但是难于识 别… … 然而，随着时间的推移，如果它们没有在最初被发现并治 疗的话，它们将会变得易于识别而难于治愈。”——Niccolo Machiavelli  FTR明显的优点: 较早发现错误(error, bug)，避免错误被 传到软件过程的后续阶段  FTR的目标：  在软件的任何一种表示形式中发现功能、逻辑或实现的错误  证实经过评审的软件的确满足需求  保证软件的表示符合预定义的标准  得到以一种一致的方式开发的软件  使项目更易于管理  提高项目的连续性和培训后备人员：了解大量原本不熟悉的部分 32 软件正式评审（FTR）  FTR会议约束  3-5人之间进行  提前准备，但是每人占用工作时间要少于2小时  会议时间不要超过2小时  关注软件的某个特定部分。（不要试图关注整个软件设 计，关注范围越小，越能发现问题） 33 软件正式评审（FTR）  FTR会议步骤  生产者通知管理者工作产品(需求规约，模块的详细设计，模块 的源代码等)已经完成，需要进行评审  管理者联系评审主席(Moderator)，主席准备相应的产品材料的 副本，分发到2，3个“评审者”。安排日程表，通常为次日  会议需要记录，生产者先做介绍，‘遍历’工作产品，作出解释， 回答提问。记录员记录发现的问题和错误  会议结束时，FTR与会者必须做出：工作产品是否被接受；是否 由于严重错误否决该产品或该产品错误改正后再进行评审；  与会者签名，发布评审总结报告 34 软件正式评审（FTR）  FTR指导原则  评审产品而不是评审生产者：千万不要审问，温和 地指出错误；不要试图贬低他人或羞辱他人。会议 气氛应该为轻松的和建设性的  制定日程并遵守日程：有人转移话题时主席要提醒  限制争论和辩驳：记录在案，会后进一步讨论  对各个问题都发表见解，但是不要试图解决所有记 录的问题：问题的解决应该放到会议后进行  做书面笔记：记录员可以在黑板上明显记录 35 软件正式评审（FTR）  限制人数并坚持事先准备：主席可以向评审者要求书 面意见(以标明评审者的确对材料进行了评审)  为每个可能要评审的工作产品建立一个检查表：为分 析、设计、编码、测试文档都建立检查表  为FTR分配资源和时间  对所有评审者进行某种正式培训：包括评审的心理学 因素  评审以前所做的评审：评审评审指南本身 36 统计软件质量保证  统计SQA：本质是质量的量化  包括的步骤：  收集和分类软件缺陷信息  尝试对每个缺陷的形成原因(例如：不符合规约、设计 错误、违背标准、与客户交流贫乏等)进行追溯  使用Pareto原则(80%的缺陷可以追溯到所有可能原因 中的20％)，将这些(20%)分离出来  一旦找到重要的少数原因，就可以开始纠正引起缺陷 的问题 37 统计软件质量保证  错误可以追溯到哪些原因：  规约不完整或规约错误(IES: Incomplete or Erroneous Specification)  与客户通信中所产生的误解(MCC: Misinterpretation of Customer Communication)  故意与规约偏离(IDS: Intentional Deviation from Specification)  违反编程规则(VPS: Violation of Programming Standard)  数据表示有错(EDR: Error in Data Representation)  构件接口不一致(ICI: Inconsistent Component Interface)  设计逻辑有错(EDL: Error in Design Logic) 38 统计软件质量保证  不完整或错误的测试(IET: Incomplete or Erroneous Testing)  不准确或不完整的文档(IID: Inaccurate or Incomplete Documentation)  将设计翻译成程序设计语言中的错误(PLT: Error in Programming Language Translation of Design)  不清晰或不一致的人机界面(HCI: Ambiguous or Inconsistent Human/Computer Interface)  杂项(MIS: Miscellaneous)  建立相应的表格，找出“重要的少数原因”，进行相应的措 施纠正：更严格的FTR，应用CASE等等。 39 质量改进指标  先根据软件工程过程划分步骤：分析，设计、 编码、测试、发布等等  阶段指标(PIi : Phase Index)  Ei =在软件工程过程中的第i 步发现的错误总数  Si =严重错误数，ws =10 : 加权因子  Mi =一般错误数，wm =3 : 加权因子  Ti =微小错误数，wt =1 : 加权因子  PSi =第i 步的产品规模(LOC, 设计说明、文档页数)  PIi ＝ ws (Si / Ei )+ wm (Mi / Ei )+ wt (Ti / Ei )  错误指标(EI: Error Index)  EI ＝ (i × PIi )/ PSi 40 软件可靠性和可用性的测量  可靠性：在特定环境和特定时间内，计算机程序 无故障运行的概率  可靠性度量：MTBF  MTBF：平均故障间隔时间(Mean Time Between Failure)  MTTF: 平均故障时间(Mean Time To Failure)  MTTR: 平均修复时间(Mean Time To Repair)  MTBF= MTTF+ MTTR  可用性：在某个给定时间点上程序能够按照需求 执行的概率。  可用性＝ MTTF/(MTTF+ MTTR)×100％  MTTR有时可作为软件可维护性的间接度量 41 SQA Hardware QA QA IV &V SCM System Engineering Software Development Software Test System Test Logistics Project Management Program Management (Sponsor) 图示： SQA组织架构 42 S E L E C T S Q A T A S K S S ec t i o n 3 S Q A P R O C E S S A C T I V I T Y S Q A T A S K D E S C R I P T I O N S Q A T A S K O U T P U T S S Q A o f S o ft w are P ro du c t s , T o o l s , an d F ac i l i t i e s S ec t i o n 3 . 1 S Q A M et ri cs S ec t i o n 3 . 5 S Q A R ep o rt i n g S ec t i o n 3 . 4 T ech n i ca l an d M an ag em en t R ev i ew s S ec t i o n 3 . 3 S o ft w are P ro ces s A u di t s S ec t i o n 3 . 2 F o r m a l I n s p e c tio n L o g o f S R S S o f tw a r e T o o l E v a lu a tio n P r o je c t F a c ilitie s E v a lu a tio n A u di t s co n du c t ed fo r co m p l i an ce w i t h P ro j ec t S D P an d S E I S W -C M M P art i c i p a t ed/ R ep o rt ed o n S R R , S D R , S S R , P D S , C D R , T R R , F Q R , P R R & M an ag em en t R ev i ew s P ro ces s A u di t R ep o rt S Q A M et ri cs R ep o rt 图示，SQA任务 43 S Q A a c t i v i t i e s i de n t i f i e d: 1 . 2 . S E L E C T S Q A T A S K S S e c t i o n 3 C R E A T E / M A IN T A IN S Q A P L A N S e c t i o n 4 C R E A T E / M A IN T A IN S Q A P R O C E D U R E S S e c t i o n 6 ID E N T IF Y S Q A T R A IN IN G S e c t i o n 7 ID E N T IF Y / S E L E C T S Q A T O O L S S e c t i o n 8 IM P R O V E P R O J E C T S Q A P R O C E S S E S S e c t i o n 9 S e l e c t t h e S Q A T a s k s t h a t S Q A w i l l p e rfo rm - Ide n t i f i e d S Q A t a s k s a re i n p u t s t o t h e S Q A P l a n . S Q A P R O C E S S A C T I V I T Y S Q A P R O C E S S D E S C R I P T I O N D o c u m e n t t h e p ro c e du re s fo r p e rfo rm i n g S Q A a c t i v i t i e s - R e p e a t a b i l i t y o f p e rfo rm i n g a s p e c i f i c t a s k Ide n t i fy re qu i re d t ra i n i n g t o p e rfo rm t h e S Q A t a s k s - i n p u t s t o t ra i n i n g b u dg e t Ide n t i fy t o o l s t o e n s u re qu a l i t y - c o m p a t i b i l i t y w i t h t h e s o ft w a re e n g i n e e ri n g e n v i ro n m e n t L o o k fo r e ff i c i e n c i e s a n d a re a s fo r i m p ro v e m e n t - c h a n g e s t o S Q A p o l i c y , p l a n , p ro c e s s e s , a n d p ro c e du re s S Q A P R O C E S S O U T P U T S T ra i n e d P e rs o n n e l P u rc h a s e T o o l P r o j e c t S Q A P la n S Q A P r o c e d u r e s Im p ro v e d p ro c e s s , p o l i c y , p ro c e du re s E S T A B L IS H S Q A O R G A N IZ A T IO N S e c t i o n 2 D e fi n e a n d e s t a b l i s h t h e S Q A o rg a n i z a t i o n IM P L E M E N T S Q A P L A N S e c t i o n 5 P l a n t h e S Q A a c t i v i t i e s i n p h a s e w i t h t h e s o ft w a re de v e l o p m e n t l i fe c y c l e Im p l e m e n t t h e S Q A t a s k s a s de fi n e d i n t h e a p p ro v e d P ro j e c t S Q A P l a n S Q A t a s k s b e i n g i m p l e m e n t e d P r o j e c t O r g a n i z a t i o n 图示： SQA过程 软件能力成熟度模型�(CMM: Capability Maturity Model ) LEVEL 2关键过程域 概述 概述 概述 目标(Goals) 执行约定�（Commitment to perform） 执行能力�(Ability to perform) 执行能力�(Ability to perform) 执行能力�(Ability to perform) 执行的活动�(Activities performed) 执行的活动�(Activities performed) 执行的活动�(Activities performed) 执行的活动�(Activities performed) 执行的活动�(Activities performed) 执行的活动�(Activities performed) 执行的活动�(Activities performed) 测量和分析�(Measurement and analysis) 验证实施�(Verifying implementation) 总结 幻灯片编号 21 关于软件质量保证的讨论 质量的概念 质量的概念 质量成本 质量成本 质量成本 质量保证 软件质量保证 软件评审 软件正式评审（FTR） 软件正式评审（FTR） 软件正式评审（FTR） 软件正式评审（FTR） 软件正式评审（FTR） 统计软件质量保证 统计软件质量保证 统计软件质量保证 质量改进指标 软件可靠性和可用性的测量 幻灯片编号 41 幻灯片编号 42 幻灯片编号 43