软件质量管理期末复习

质量 软件质量的概念、 软件质量控制和管理的方法和技术, 包括软件质量 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 、CMM、PSP、配置管理、质量度量和软件评审 一、 质量的内涵和软件质量特性 如何建立有效的软件质量工程体系 软件质量保证的任务及活动 如何进行软件质量度量 软件质量标准 软件缺陷预防性措施,做好各类软件评审各 与质量相关的概念 组织(Organization)是指“职责、权限和相互关系得到安排的一组人员及设施。组织是由两个或两个以上的个人为了实现共同的目标组合而成的有机整体 过程 过程一般伴随着时间先后次序的、不同的事件发生。 产品(Product)是指“过程的结果或过程的中间结果”。产品有四种通用的类别:硬件、软件、服务和流程性材料等。依产品的存在形式,又可将产品分为有形的和无形的。 服务(Service)是向客户提供相应的技术支持、帮助和关心等的行为。服务也是一种无形的产品,是对有形产品的补充。 客户(Customer)不仅包括接受产品或服务的组织或个人,而且包括潜在的客户,所以更广义的含义,客户是公司为实现目标所需要的产品和过程而影响到的人。 体系(System)是指相互关联、或相互作用、或相互依存的一组要素构成的有机整体。体系一般拥有一定的组织形式,其相互作用受某些规则或规律所控制,其变化的过程有一定的秩序,趋于和谐的状态 1.1.2 什么是质量 质”和“量”构成的,就是物质在质和量上的集合或程度 就是产品或工作的优劣程度,换句话说,质量就是衡量产品的或工作的好坏。 1.1.2 质量属性 质量的客户属性 质量的成本属性,也可以称为质量的经济性 社会属性 可测性决定了质量的可控特性。 质量的可预见性 1.2.1 内部客户和外部客户 外部客户,不是组织内部的组成部分,但是受本组织活动影响的个人和组织。外部客户是在传统意义上大家所认知的客户 内部客户,指组织内部的“对方”就被视为内部客户 内部客户又分为4种,即职级客户(权利层次)、职能客户(职能部门)、工序客户(流水线)和流程客户(软件开发) 1.2.2 客户的确定 1.2.3 客户与质量的关系 朱兰质量螺旋曲线 所谓质量螺旋,是表述影响质量的相互活动的概念模型,是一条螺旋上升的曲线,它把全过程中各个质量职能按逻辑顺序串联起来,用以表征产品质量形成的整个过程及其规律性,通常称为“朱兰质量螺旋”或者“质量环”。 ,质量策划、质量控制和质量改进 )是指确定质量方针、目标和职责,并通过质量体系中的质量策划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动。 染、生态平衡) 费根堡姆认为:质量系统是指具有确定质量标准的产品和为交付使用所必需的管理上和技术上的步骤的网络。(汽车) 阶段:工序质量控制图迚行质量控制(制造) 现代质量改进之父——戴明 TQM的奠基人约瑟夫·朱兰 统计质量控制之父—休哈特 质量工程学创始人——田口玄一 全面质量控制之父——费根堡姆 简述产品质量的意义? 2.1 质量管理体系基础 2.1.1 质量方针和质量目标 2.1.2 质量管理体系中使用的文件类型 2.1.3 质量管理体系 评价 LEC评价法下载LEC评价法下载评价量规免费下载学院评价表文档下载学院评价表文档下载 2.1.4质量管理体系认证的主要活动 为了实施质量管理的组织结构、职责、程序、过程和资源的一种特定体系。 质量体系的结构要素和质量体系的选择要素。 提高IT公司的管理水平,增强公司的抗风险能力。 提高软件产品质量,增强企业市场竞争力。 树立公司良好形象,巩固和不断扩大市场仹额。 与国际接轨,有利于国际市场的开拓。 针的组成部分,是企业管理者对质量的指导思想和承诺。 确保质量目标与质量方针保持一致(方针顾客满意) 应充分考虑企业现状及未来的需要(平均成绩90分) 考虑顾客和相关方的要求(前瞻性) 考虑企业管理评审的结果 找出企业目前的弱项和存在的问题 对这些问题迚行分析,确定问题的范围 由所存在的问题引出质量目标 为使企业质量目标得到实施,制定目标时需满足如下要求。满足产品要求的内容、质量目标可测量、质量目标的挑战性。 2.2 八项质量管理原则 以顾客为关注焦点 领导作用 全员参与 过程方法 系统的管理方法 持续改善 基于事实的决策方法 互利的供方关系 软件是完成某类问题求解的程序和数据以及维护程序必须提供的一系列文档组成的集合。 软件= 程序+ 数据+ 系列文档 软件的性质: 软件具有高度的抽象性和严密的逻辑性。(内部性质) 一种逻辑的信息产品,用文字、符号表达的智力产物。(外部性质) 过程一般分为: 过程是由人、规程和方法以及工具和设施三方面构成的。 PDCA:Deming Cycle 软件过程的组成: 工程过程:软件系统、产品定义、设计、实现以及维护的过程。 支持过程: 管理过程: 组织过程: 客户-供应商过程: 软件开发的基本过程,可以简单地分为需求分析、设计(概要设计、详细设计)、编程、测试和维护等阶段,即通常所说的软件生命周期。 XP基本思想和原则 个体和交互胜过过程和工具 可以工作的软件胜过面面俱到的文档 客户合作胜过合同谈判 响应变化胜过遵循 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 分阶段性开发的基本模型特点: 增量模型描述 要的功能,然后随时间推迚,不断增加新的辅助功能和次要功能,最终开发出一个功能完善、稳定的产品。 迭代模型描述软件产品的不同阶段是按产品深度或细化程度来划分,先将产品的整个框架都建立起来,在系统的初期,已经具有用户所有需求的全部功能。然后随时间推迚,不断细化或完善已有功能,这个过程是一个迭代的过程。 从产品内部看,软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题; 项目期限的压力 产品的复杂度 沟通不良 开发人员的疲劳、压力或受到干扰 缺乏足够的知识、技能和经验 不了解客户的需求 缺乏动力 为什么软件需求规格 说明 关于失联党员情况说明岗位说明总经理岗位说明书会计岗位说明书行政主管岗位说明书 书是存在缺陷最多的地方原因分析: 用户非计算机专业人员,沟通存在困难,理解不一致。 软件产品完全靠想象去描述系统的实现结果,特性不清晰。 用户的需求是变化的,容易引起前后、上下文的描述不一致。 需求分析没有的到重视,文档上投入人力、时间不足. 没有在开发队伍中进行充分沟通,只有设计师或项目经理得到较多信息。 –用户可以基于产品或服务的描述和定义进行使用。(例如: 市 .) Availability –产品或服务对于99.999% 客户总是有效的(例如: 性能测试和恢复测试) Accessibility –对于用户, 产品或服务非常容易使用并且一定是非常有用的功能. (例如: 确认测试和用户可用性测试) RUP 软件质量的三个维度 功能(Functionality):按照既定意图和要求,执行指定用例的能力。 可靠性(Reliability ):软件坚固性和可靠性(防故障能力,如防止崩溃、内存丢失等能力)、资源利用率、代码完整性以及技术兼容性等。健壮性和有效性有时可看成是可靠性的一部分。性能(Performance):用来衡量系统占用系统资源(CPU时间、内存)和系统响应、表现的状态 软件质量描述: 软件质量是衡量所交付的软件是否符合相关的软件开发标准,满足预期的功能和性能要求,准时交付给客户,并且软件开发成本不超出预算,从而最终满足客户要求的标准。 软件质量的衡量指标: 零缺陷 对目标的适应性 能否持续稳定且成本合理地应用于市场 产品和服务特性是否能够满足用户特定的以及隐含的需求等 什么样的软件是高质量的软件? 相对的无产品缺陷(Bug Free)或只有极少量的缺陷, 它能够准时递交给用户并且所用的费用都是在预算内的并且满足客户需求,是可维护的。但是, 有关质量的好坏最终评价依赖于用户的反馈。 控制软件生产过程、提高软件生产者的组织性和软件生产者个人能力。 净化软件工程:统计质量控制下的软件生产过程 评估软件能力成熟度(CMM) 提高软件生产力和个人技能(PSP) 与功能和性能需求的一致性 与开发标准的一致性 与同行业所有软件应满足的隐含特性一致性 初期运用:运行新开发的软件产品。 维护与扩充:在运行过程中修改缺欠的内容;而且,为了迚一步的使用,需根据运行环境(主要指应用环境和技术环境)的变化做功能上和性能上的扩充。 移植和连接:把在原有平台上运行的软件向其它新的运行环境转移、或者组成软件包以便重用、或与其它软件迚行连接。 产品质量 是人们实践产物的属性和行为,是可以认识,可以科学地描述的。并且可以通过一些方法和人类活动,来改迚质量. 质量模型: McCall 模型, Boehm 模型, ISO 9126 模型 过程质量: SPICE ( Software Process Improvement and Capability dEtermination) 在商业过程中有关的质量内容: 培训、成品制作、宣传、发布、客户、风险、成本、业务等 所谓质量模型是指提供声明质量需求和评价质量基础的特性以及特性之间关系的集合。如何看待软件质量的地位? 如果没有过程规范,会…… 1)组织结构与过程活动不统一,成员不知过程为中心,还是仸务为中心造成混乱。 2)成员缺少为完成有关活动所需的熟练程度和技能,导致效率低下。 3)从管理的角度缺少对过程的信仸。 4)缺少成员培训,知识与技能与现有过程发生冲突。 过程能力实例: 独立完成开发任务 通过四级考试 过程性能实例: 项目实际完成情况 此次四级考试结果 (1)初始级具有明显的不成熟过程的特点 (2)可重复级/受管理级建立了管理软件项目的方针和实施这些方针的规程,使软件项目的有效管理过程制度化,有能力去跟踪成本、进度和质量。一个有效过程可特征化为已文档化的、已实施的、可培训的和可测量的软件过程 (3)已定义级包含一组协调的、集成的、适度定义的软件工程过程和管理过程,具有良好的文档化、标准化,使软件过程具有可视性、一致性、稳定性和可重复性,软件过程被集成为一个有机的整体 (4)已管理级的软件过程是量化的管理过程。在上述已定义级的基础上,可以建立有关软件过程和产品质量的、一致的度量体系,采集详细的数据进行分析,从而对软件产品和过程进行有效的定量控制和管理。 (5)优化级不断改善组织的软件过程能力和项目的过程性能,利用来自过程和来自新思想、新技术的先导性试验的定量反馈信息,使持续过程改进成为可能。为了预防缺陷出现,组织有办法识别出弱点并预先针对性地加强过程 软件过程的可视性 CMM的作用 1)软件过程改进 根据软件过程评估的结果,确定当前软件过程的弱项,然后按照软件CMM成熟度等级的顺序,从低级逐步向更高级发展,以逐步改进软件过程。 CMM每一级都是更高级的基础,基础条件不具备,不可能达到更高级。 软件组织需要考虑如何更快地改进自己的软件过程,提高自己的竞争力的战略问题。 2)软件能力评估 根据软件过程评估的结果,确定被评估组织软件能力成熟度等级。当被评估单位被评估的所有项目均已实现某成熟度等级及以下各级的所有关键过程域,才认为该单位已达到该成熟度等级。 一个关键过程域是否实现,要看该关键过程域的所有目标是否实现,而这些目标是否实现,取决于各目标的关键实践是否已得到有效实施。 CMM不能做的事情 CMM不能保证一定能成功地生成软件产品,也不能保证一定能很好地解决软件工程中的所有问题。 CMM不是处方,不告诉企业如何进行改进,不规定达到成熟度等级的具体方法,不会限制如何去实施软件过程,必须灵活地运用才能帮助不同企业处理各自具体业务需要 CMM不可能涉及项目的所有重要问题 不涉及特定领域的专门知识 不提倡任何特殊软件技术 不涉及任何选择、雇佣、激励、保留有用人才。 成熟度等级的跳跃 CMM中的成熟度等级描述组织处于某一级的特征,每一成熟度等级都是下一等级的基础。 CMM不赞成也不鼓励跳级,因为在CMM 的低一级是实施上一级的必要基础,基础不牢的跳级通常意味着欠成熟和失败。 如不经过过程管理(2级),无法实现过程工程化,没有定义的过程(3级),就没有解释测量的基础。 软件过程环境和过程框架 框架是软件组织对技术、实践、方法和经验的有序积累,是知识管理。 如果没有一个清晰的建立框架的思想,没有一个明确的框架发展目标,框架是不会自动出现的。 过程环境是保证软件过程基本活动的基础。 软件过程实施、过程评估和改进是在过程环境中进行。 过程环境包含哪些内容? 软件组织的层次 软件个体:软件开发人员、软件测试人员、项目协调人员。 软件团队:开发组、测试组、软件工程过程组、软件配置管理组 软件组织:由多个软件团队组成,组织能够独立开展业务,为客户提供产品和软件服务。 PSP提出的背景: CMM的成功与否,与组织内部有关人员的积极参加、创造性活动以及知识和技能密不可分。 CMM存在以下问题: CMM是软件工程实践所需目标、方法和实践的最佳描述,但如何在实验室或产业环境中应用? CMM是致力于组织过程改进的框架,它如何才能使工作有效而且便利? CMM未提供有关实现的关键过程域(KPA)所需的具体知识和技能。 个体软件过程 人、规程、方法和工具 软件的完成是靠每个人来完成的,它是软件工程的一个最基本元素。 软件工程师最重要的两方面品质: 知识、技能 工作热情 PSP 就是为这个目标训练软件工程师而建立的过程。 PSP:是一种可用于控制、管理和改进个人工作方式的自我改善过程,是一个包括软件开发表格、指南和规程的结构化框架。 作用: 软件项目开发成本的70%取决于软件开发人员的技能、经验和工作习惯。 一个单位的开发人员接受PSP培训,对该单位软件能力成熟度的升级是一个有力的保证。 CMM侧重软件过程的宏观管理,面向软件开发单位,PSP侧重于企业中有关软件过程的微观优化,面向开发人员。二者互相支持,互相补充,缺一不可。 PSP概述 使用自底向上的方法来改进过程,向每个软件工程师表明过程改进的原则,使他们能够明白如何有效地生产出高质量的软件。 为基于个体和小型群组软件过程的优化提供了具体而有效的途径。其研究与实践填补了CMM的空白。 PSP的原则(规范): 帮助软件工程师制定准确的计划 帮助软件工程师为改善产品质量而采取相应的步骤 建立度量PSP的改进基准 确定软件过程的改进对软件过程师能力可能产生的影响。 TSP概述 致力于开发高质量的产品,建立、管理和授权项目小组,并且指导他们如何在满足计划、费用的前提下,在承诺的期限范围内,不断生产并交付高质量的产品。 TSP的目标 —创建具有自我管理能力的群组。 实现TSP的条件 必须有各层主管的支持,以取得资源。 整个软件开发小组至少应在CMM的第二级(可重复层)。 全体软件开发人员必须经过PSP的培训。 开发小组成员应在2到20个人之间。 CMM、PSP和TSP的关系 CMM的成功与否,与组织内部有关人员的积极参加、创造性活动以及知识和技能密不可分。 PSP的研究与实践填补了知识和技能这一空白 TSP指导项目组成员有效地规划和管理项目开发任务,填补了人员的积极参加和创造性活动这一空白 质量管理体系的核心是管理组织、文化和流程,其基础是现有的软件质量标准、方法和工具。 软件质量工程体系,着重从系统工程学的角度去管理质量,在有限的资源情况下,获得最好成绩的质量效益 软件质量指标 正确性:实现的功能达到设计规范,并满足用户需求的程度 可靠性:规定的时间和条件下,仍能维持其性能水准的程度 易用性:用户掌握软件操作所要付出的时间及努力程度 效率:软件执行某项功能所需电脑资源(含时间)的有效程度 可维护性:当环境改变或软件发生错误时,执行修改或恢复所做努力的程度 可移植性:从一个系统/环境移到另一系统/环境的容易程度 软件质量控制(SQC) 软件质量保证(SQA) 软件质量管理(SQM) 软件质量管理的4个层次 检查,初期阶段,通过检验保证产品的质量,符合规格的软件产品为合格品,不符合规格的产品为次品,次品不能出售。这个层次的特点是独立的质量工作,质量是质量部门的事,是检验员的事。检验产品只是判断产品质量,不检验工艺流程、设计、服务等,不能提高产品质量。 保证,质量目标通过软件开发部门来实现,开始定义软件质量目标、质量计划,保证软件开发流程合理性、流畅性和稳定性。 预防,软件质量以预防为主,以过程管理为重,把质量的保证工作重点放在过程管理上完美,以客户为中心,全员参与,追求卓越。 质量策划是贯彻质量方针的关键活动之一。 软件质量保证 内部质量保证是组织向自己的管理者提供信任; 外部质量保证是组织向外部客户或其它方提供信任。 质量保证活动种类: 复审(Review):用结束标准对该阶段生产出的软件配置成分进行严格的技术审查等活动; 内审(Audit):检查组织内部是否遵守已有的模板、规则、流程等。 质量成本=质量保证成本+损失成本 保证成本:为保证满意的质量而发生的费用 损失成本:没有达到满意的质量所造成损失 质量成本=质量预防成本+评价成本+失效成本 质量成本=质量保证成本+损失成本 质量保证成本=预防成本+评价成本 预防成本:预防产生质量问题(软件缺陷)的费用,是企业的计划性支出,专门用来确保在软件产品交付和服务的各个环节不出现失误。 评价成本:是指在交付和服务环节上,为评定软件产品或服务是否符合质量要求而进行的试验、软件测试和质量评估等所必需的支出。 失效成本:分为内部的和外部的,如果在软件发布之前发现质量问题,而要求重做、修改和问题分析所带来的成本属内部失效成本,包括修正软件缺陷、回归测试等,以及因产品或服务不合要求导致的延误。一旦发布给用户带来的失效成本,为外部成本。 质量成本设置的目的是为了用于质量成本的优化,使预防成本、评价成本和失效成本的总和最小,使质量成本个要素之间保持合理的最佳结构。 质量越高,所花费的成本越高。 为维持或提高质量水平,避免产生过高的故障成本,必须付出一定的预防和保证费用。 评审可以发现软件产品的问题,检查与评估越细致、彻底,客户发现的质量缺陷就越少,但评审并不能改进被评估的产品和服务的质量,不能杜绝有质量缺陷的产品。 加大预防成本可以减少降低评价成本,同样减少补救性支出。 朱兰曾在论质量策划一书中将质量定义为产品特征和没有缺陷。 PONC,即“不符合要求的代价(Price of Nonconformance)”或称“劣质成本”,是指由于缺乏质量而造成的人力、财力、物力以及时间成本的浪费。PONC是在“零缺陷”质量管理中,为了更有效地衡量质量成本而引入的一个重要概念。 COPQ,即“不良成本(Cost of Poor Quality)”或称“劣质成本”的概念。COPQ指所有由过程、产品和服务中的质量缺陷引起的费用。COPQ则是“6西格玛(Six sigma)”质量管理中的一个重要概念,用于有效地衡量质量成本、质量改进过程在经营效益上的表现。 朱兰:每一项任务都毫无缺陷地执行,就不会发生的成本。 劣质成本的分类 故障成本,包括质量成本中的外部故障成本、内部故障成本,需采取返工、返修、纠正等补救措施所花费的成本。 过程成本,包括非增值成本(非增值的预防成本和鉴定成本)、低效率过程成本(如多余的操作、重复的作业等)、机会损失成本(指如果没有缺陷而就不会发生的费用等)。 损失成本,包括顾客损失成本(指给顾客所造成的各种额外的费用及负担)、信誉损失成本。 软件质量度量的地位 采用定量软件工程,制定软件产品质量的度量准则,可以提高软件开发过程管理的可视性,降低劣质成本,提高软件产品的质量。 项目质量度量是度量软件项目特征和项目执行的质量状态,包括项目的资源使用效率、项目性能、项目风险等。 产品质量度量是度量软件产品的特性和质量属性,如软件产品的功能、复杂性、设计特征、性能和可靠性等。 过程质量度量是度量软件开发和维护的改进过程,包括过程中某一时刻的状态(时间切面)、历史数据分析度量和未来变化预测的度量等。 1. 软件质量控制和软件质量保证之间有何区别? 2. 比较质量成本和劣质成本的概念、联系及差异。 4.1.1 软件质量保证的概念 4.1.2 软件质量保证目标 4.1.3 软件质量保证的组织结构 4.1.4 软件质量保证人员的素质要求 软件质量的两个方面: 设计质量:需求分析和设计阶段的质量 制造质量:软件实现、测试和维护阶段的质量 软件质量保证是为软件产品满足已指定的技术需求提供充分证据,而开展的有计划的和系统的活动。 软件质量保证的目的:为了向组织内部以及向客户或第三方提供信任保证。 软件质量保证的目标:软件质量保证工作应系统并有计划地进行。 客观地检查软件产品和工作是否遵循适当的标准和流程。 保证软件开发过程中各部分的有效沟通。 SQA和项目经理:SQA 的执行情况、过程的质量、产品的质量、产品的完成情况等。 SQA和开发工程师:SQA任何对立和挑衅都可能导致质量保证这个大目标失败。 :SQA SQA主要 SQA不能担任开发、测试或配置管理工作。 SQA是整个企业、整个组织的责任,而不仅仅是某个部门或某几个人的责任。 沟通能力和捕捉问题的能力 熟悉软件开发过程 具备很强的计划性 具备处理繁杂工作的能力 有责任心,客观监督软件过程 学习能力 SQA人员集教师、医生和警察三大角色于一体。 软件质量保证主要通过监控软件开发过程来保证软件产品的质量,提高项目的透明度,确保项目开发过程中发现的问题得到及时的处理,从根本上保证软件的质量。 编制软件质量保证计划 根据软件质量保证计划实施软件质量保证活动 记录和汇报软件质量保证结果 确定了项目计划和范围,SQA人员即可以编写软件质量保证计划,软件质量保证计划将作为后续软件质量活动的依据。 文档管理:编制、复核、审批和发布 测试和验收 项目输出物 问题报告和处理 工具、技术和方法 分包商/供应商管理 SQA记录和报告:收集、维护和保密 培训 风险管理 1. 阶段评审和检查 2. 测试与验收 3. 日常活动检查 4. 配置管理审计 5. 问题报告和处理 6. 收集过程改进建议 7. 软件质量保证记录和报告 质量管理体系:在质量方面指挥和控制组织的管理体系。 软件质量保证体系:针对软件领域的质量管理体系。 规定必要的评审、检查和审计 (1)评审 正式的技术评审 一般会议评审 邮件评审 (2)检查:项目中的全部正式产品、文档其它交付物、软件开发过程,均应通过SQA 人员,并签署意见。 编制审计计划,明确审计目标。 准备审计检查表 实施审计 提交审计检查结果 问题跟踪和关闭 审计记录归档 根据SQA 技术培养 素质培养 质量管理=制定质量方针和质量目标+质量策划+质量控制+质量保证+质量改进 ISO/IEC 12207:“软件质量保证过程(SQA)是恰当保证为项目生存周期中的软件产品和过程符合规定需求和已制订的计划提供足够保证的过程”。 CMM二级的关键过程域:软件质量保证 软件质量保证过程域的主要参与者及其职责 SQA经理: 1.全面负责项目软件质量保证活动 2.制定SQAP 3.参与准备和评审SDP、标准和规程 4.组织进行软件工程活动评审和软件工作产品审核 5.定期向软件工程组通报SQA活动结果 6.处理发现的不符合问题 7.适合时与顾客的SQA人员一起定期评审自己的活动 SQA组:按SQA经理的安排进行 指定的高级管理者:1.处理项目内部无法解决的不符合问题 2.定期参与评审SQA活动 项目软件经理:1.负责实现项目质量目标 2.征求SQA意见并支持SQA活动 3.定期地且事件驱动地评审项目SQA活动 独立专家:独立于SQA组的专家定期评审SQA组的活动和软件工作产品软件工程有关人员:支持项目SQA活动 软件质量保证 只是起保证作用,不能代替开发者的质量实现作用 -主要进行符合性检查,但不负责质量的实现 -不可能检查全部符合性,要选择最能增加价值的检查项 ,即有很好的文档说明和培训。 软件质量保证是CMM二级的一个关键过程域。 第5章软件质量控制与管理 软件质量控制的基本方法 5.1.1 目标问题度量法 目标问题度量法是通过确认软件质量目标并且持续观察这些目标是否达到软件质量控制的一种方法。 明确质量控制目标 量化控制目标:(设想问题,如问题发生带来那些偏差,研究发生的偏差,有助于目标量化) 度量:缺陷次数、发生频率、缺陷发生阶段的频率分析 5.1.2 风险管理方法 软件风险管理法是识别与控制软件开发中对成功达到质量目标危害最大的那些因素的系统性方法。 风险管理的目的是使风险对项目的影响最小。 项目风险是指潜在的预算、进度、人力(工作人员和组织)、资源、客户及需求等方面的问题及对软件项目的影响。 风险识别是试图用系统化的方法确定威胁项目计划的因素。 风险识别包括了两类风险的识别,内在风险和外在风险。 内在风险指项目工作组能加以控制和影响的因素,如人事任免和成本估计等。 外在风险指超出项目工作组影响力之外的风险,如市场转向或政府行为等。 人员不足 进度计划和预算不准确 开发了不适用的用户接口 外供部件不足 需求不断变更 开发了错误的软件功能 风险分析可以分为定性风险分析与定量风险分析。 定性风险分析是评估已识别风险的影响和可能性的过程。 定量风险分析是量化分析每一风险的概率及其对项目目标造成的后果,同时也要分析项目总体风险的程度。(情景分析比率/范围分析概率分析敏感性分析) 不同的风险发生后对项目造成的影响各不相同,主要从如下三个方面考虑: 风险的性质,风险发生时产生的问题。 风险的范围,风险的严重性及其总的分布。 风险的时间,何时能感受到风险及风险维持多长时间。 主要采用的应对方法有: 应急基准计划(计划编制基础)、避免风险(中断项目)、减小风险、风险承担、风险转移 软件质量控制包括产品质量的控制,而且包括开发过程的质量控制。 前者是短期的、被动的。后者是全面的、长期的、主动的、可以预期的。缺陷分析和预防 软件质量控制模型是指对一个特定的软件开发项目,在如何计划和控制软件质量方面,为一个团队提供具体组织和实施指导的框架。 软件质量控制模型过程是一个PDCA的循环过程。PDCA包括4个部分:计划、执行、检查和行动。 在质量控制模型中的3类控制参数,即产品、过程和资源,它们之间具有相关性。 产品:一个过程的输出产品不会比输入产品的质量更高。 过程:一些过程进行质量设计并将质量构造入产品,而另一些过程则是对质量进行检查。资源:是指为了得到要求质量的产品、过程使用的时间、资金、人和设备。 软件质量控制模型要素分析 产品对质量的影响 产品质量通过开发过程设计并进入产品,同时也会引入缺陷。 在产品中获得的质量,通过检查过程了解和确认。 一个过程涉及的组织和部门数及它们间的相互关系,将影响引入差错的概率,也会影响发现和纠正差错的概率。 资源对质量的影响 人力资源对软件质量和生产效率最重要的影响因素,开发人员的知识、能力、经验和判断都相差很大。 时间在通常情况下都是不充分的,特别是需求分析和集成测试阶段。 软件开发环境和测试设备不足,会使差错发生率提高,发现并纠错的时间也将增加。 软件质量控制技术的主要特征 软件寿命阶段的可运行性特征 预防性和检测性结合性特征 不同的质量控制技术对不同的质量控制参数有不同的影响文档编制控制技术(规则) 受控文档清单 受控文档的编制 受控文档的批准 受控文档的存储与检索结果方面的问题 3. 项目进展控制技术 管理活动、进度、资源、预算的控制 检查表Pareto图直方图运行图散布图控制图因果图 支持性质量保证手段 使用模板有很多益处: 简化文档评审工作,使文档编制更加方便 确保开发人员编制的文档更完善 对新组员有利 增加项目的可理解性 便于维护,维护人员快速找到所需信息 软件质量控制的基本方法: 目标问题度量法; 风险管理法 模板与文档 软件质量控制的基本方法是什么? 解释PDCA的含义。 6.2 配置项 6.3 基线 6.4 版本控制 软件配置管理(Software Configuration Management,SCM)是一种标识、组织和控制修改的技术。简而言之,就是管理软件的变化。 基线是正式评审过的一个或多个软件配置项,每一个基线都是下一步开发的出发点和基础,并且只能通过正式的变化控制过程改变。 配置是在技术文档中明确说明最终组成软件产品的功能或物理属性。 软件配置项SCI 在软件生存周期内所产生的各种应纳入管理范围的系统构成成分。包括各种管理文档和技术文档,源程序与目标代码,以及运行所需的各种数据等(配置管理的资源对象)。 项目数据库又称配置管理库或受控库。 有效的软件配置管理可以解决一些常见的问题; 有效的软件配置管理可以节约用户资金; 有效的软件配置管理可以提高软件开发管理的水平; 有效的软件配置管理可以保护企业的知识财富。 配置管理任务 制订项目的配置计划; 对配置项进行标识; 对配置项进行版本控制; 对配置项进行变更控制; 定期进行配置审计; 向相关人员报告配置的状态。 所有在软件过程中产生的信息,总称为软件配置项,主要包括: 计算机程序(源代码和可执行程序); 描述计算机程序的文档(针对技术开发者和用户); 数据(包含在程序内部或外部)。 存取控制:设定了软件开发人员对软件基准库的存取权限,保证软件开发过程及软件产品的安全性; 版本控制:是配置管理的基本要求,使得组织在任何时刻都可以获得配置项的任何一个版本;变更控制:为软件产品变更提供了一个明确的流程,要求任何进行配置管理的软件产品变更都要经过相应的授权与批准才能实施; 产品发布:保证了提交给客户的软件产品是完整的、正确的。 软件配置项标识是管理配置的前提。标识包括文件名和版本。 配置项命名: (1) 唯一性:在一个项目内不能出现重名,以避免混淆; (2) 可追溯性:系统的要求,即名字应能体现相邻配置项之间的关系。 基线标志软件开发过程的各个里程碑,任何配置项一旦复审通过,即形成一个基线,它标志 通过正式评审过程建立; 存在于基线库,对基线的变更接受更高权限的控制; 基线是进一步开发和修改的基准和出发点; 进入基线前,不对变化进行管理;进入基线后,对变化进行有效管理; 不会变化的内容不纳入基线,变化对其它无影响的也不纳入基线; 基线具有名称、标识符、版本、日期等属性; 交付给客户的基线成为一个Release,内部开发用的基线为一个Build。 基线的优点 重现性:当更新不稳定或不可信时,基线提供一种取消变更的方法; 可追溯性:建立项目工件之间的前后继承关系; 版本隔离:新项目与随后对原始项目所进的变更进行隔离。 基线种类 功能基线(Functional Baseline):系统规格 说明书 房屋状态说明书下载罗氏说明书下载焊机说明书下载罗氏说明书下载GGD说明书下载 指派基线(Allocated Baseline):软件需求规格说明书 产品基线(Production Baseline):软件产品的全部配置项的规格说明书 基础。 版本控制主要分为:版本的访问与同步控制、版本分支和合并。 版本的访问控制 工作区域中的源文件是从库中恢复得到的一个复制文件,它可以是可“写”的,也可以是可“读”的。一般有两种工作模式: 一是在工作区域一旦有“读”请求,就做一次恢复操作,获得复制文件,当“读”操作结束,该复制文件被删除; 二是仅当软件库中的内容发生更改时,才发生交互,而不是每次“读”操作都与软件库中的文件发生交互。 版本的同步控制 同步控制实际上是版本的检入检出控制: 检入:将软件配置项从用户的工作环境存入到软件配置库的过程; 检出:将软件配置项从软件配置库中取出的过程。 做上标记;实行版本控制之后,版本的分支是一份复制文件,这时的复制过程和标记动作由版本系统自动完成。 版本合并 版本合并是通过对文件的比较来进行合并。有两种途径: 一种是将版本A的内容附加到版本B中; 另一种是合并A和B的内容,形成新的C; 后一种途径更容易理解,也符合软件开发的思路。 在软件开发过程中,会产生许多变更,如配置项、配置、基线、构建的版本、发布版本等的变更。对于所有的变更,都要有一个控制机制,以保证所有变更是可控的、可跟踪的、可重现的。 功能变更 缺陷变更 软件的变更控制机制通常只能跟踪到工程变更顺序产生为止。为确认变更是否正确完成,一般可以用以下两种方法去审查: 正式技术评审:着重检查已完成修改的软件配置对象的技术正确性,评审者评价SCI,决定它与其它SCI的一致性。 软件配置审计:对所有的变更进行,除了无价值的变更之外。软件配置审计作为正式技术评审的补充,评价在评审期间通常没有被考虑的SCI的特性 CVS是并发版本系统(Concurrent Versions System)的意思,主流的开放源码,网络透明的版本控制系统。 CVS基本概念: 仓库:它是CVS服务器的根目录,所有的工作都保存在这个仓库; 模块:模块里面放的是一个项目的所有文件; 导入:将本地软件项目导入到CVS仓库中; 导出:将仓库中的一个模块中的东西到处到本地工作目录下; 提交修改:将本地修改的文件提交到CVS仓库; 同步:从CVS下载修改过的文件来更新本地文件; 文件版本:指的是单个文件版本; 发行版本:整个产品的版本; 标签:对一个文件或多个文件给的符号名。 良好的软件配置管理具有如下特征: 任何项目成员都要对其工作成果进行配置管理 配置管理规范应清晰明了,便于执行。 选择配置管理工具时综合考虑价格、易用性和功能因素。 CMM二级的关键过程域 需求管理 软件项目计划 软件项目追踪与监控 软件子合同管理 软件质量保证 软件配置管理 有一个编程小组,在开发程序的时候,A发现B编写的程序有一个很不容易注意到的错误,便对错误迚行修改,却没有将其告诉B。当B修改自己的程序时仍然用了原来那个有错的程序,然后放入系统,这样一来,A所做的修改没有起作用。结果是:A以为那个错误已修正了,而B并不知道有错,最终这个错误继续存放于程序中。请问是由于什么原因导致上面的结果?如何避免发生此类问题? 版本控制在软件项目里是非常重要的。试想把(a>b)改为(a≥b)是有很大差异,对产品来说是不同的版本。你可以用1秒的时间把版本修改一点,而系统将产生很大的变化。 所以软件配置管理是必要的。另外一件常发生的事情是某程序员找不到别人修改了的源程序,或是源程序用了旧版本的编译器而使系统产生不同的行为。这是因为没有适当的管理软件的配置。 软件配置管理贯穿于软件生命周期中, 制、版本控制和变更控制。 有效性和可靠性是测量标准中最重要的指标。 软件质量度量的实施过程主要有以下5个步骤。 制订度量计划 收集数据 分析和汇报数据 采取改进措施 更新组织级数据库 每一个技术测量的定义应该具有一致性和客观性、无二义性; 度量在经验和直觉上也应该有说服力; 度量的方法力求简单、可计算性; 度量应被剪裁以最适应特定的产品和过程,而且任何时候应尽可能使得收集和分析自动化;应该用正确的统计技术来建立内部产品属性和外部待测量特征的关系; 度量结果应该是可靠的,不会因为一些技术问题导致测量结果很大的偏离。 度量应该建立反馈机制 软件质量度量是针对软件开发项目、过程及产品进行数据定义、收集及分析的持续性定量化的过程。 常用的软件度量可以分为:产品度量、过程度量 软件项目度量的主要内容如下: (1)规模度量(size measurement):以代码行数、功能点数、对象点或特征点等来衡量。软件规模度量是工作量度量、进度度量的基础,用于估算软件项目工作量、编制成本预算、策划项目进度的基础。 (2)复杂度度量(complexity measurement):确定程序控制流或软件系统结构的复杂程度指标。复杂度度量用于估计或预测软件产品的可测试性、可靠性和可维护性,以便选择最优化、最可靠的程序设计方法,来确定测试策略、维护策略等。 (3)缺陷度量(defect measurement):帮助确定产品缺陷分布的情况、缺陷变化的状态等,从而帮助分析修复缺陷所需的工作量、设计和编程中存在哪些弱点、预测产品发布时间、预测产品的遗留缺陷等。 (4)工作量度量(workload measurement):任务分解并结合人力资源水平来度量,合理地分配研发资源和人力,获得最高的效率比。工作量度量是在软件规模度量和生产率度量的基础上进行。 (5)进度度量(schedule measurement):通过任务分解、工作量度量、有效资源分配等做出计划,然后将实际结果和计划值进行对比来度量。 (6)风险度量(risk measurement):一般通过两个参数“风险发生的概率”和“风险发生后所带来的损失”来评估风险。 (7)其他的项目度量,如需求稳定性或需求稳定因子(RSI,Requirement Stability Index)、资源利用效率(Resource Utilization)、文档复审水平(Review level)、问题解决能力(Issue-resolving ability)、代码动态增长等。 软件规模的度量方法有很多种: 德尔菲法 COCOMO模型 代码行度量方法 功能点分析法 面向对象软件的对象点方法 软件质量度量模型由产品质量模型和过程质量模型组成。 软件产品质量模型:(参考3.4节中)McCall质量模型、Boehm质量模型、ISO 9126质量模型。 这些模型着重分析了软件质量属性的影响因素,研究对象是软件产品,即在软件质量属性和软件设计、编程的特性之间建立关联映射。 软件过程质量度量模型:连续分布数学模型来帮助各类过程的度量和分析。S曲线模型、PTR 到达和累积预测模型、Rayleigh模型。 缺陷到达越早,则测试过程质量就越好。 常用的缺陷到达模式有4种形式: 1)一定时间内的总缺陷数; 2)一定时间内的严重程度前两个等级的缺陷数之和; 3)一定时间内的新引进的缺陷及回归的缺陷之和; 4)一定时间内的新引进的缺陷及回归的缺陷,而且严重程度在前两个等级的缺陷之和。 所修正问题得到验证直到该问题通过测试为止,称做PRT关闭。问题跟踪报告(Problem Tracking Report 测试过程中,特定PRT保持的数量(所有新发现的PRT和关闭的PRT的差值)称为PRT累积/积压值。 三种级别的缺陷度量: 组织级缺陷度量:了解组织的整体缺陷情况,了解客户对组织的质量满意度,建立组织基线,确定改进活动。 项目级缺陷度量:了解项目实时质量情况,预测缺陷造成的发布后维护工作量,了解客户对项目的质量满意度。 个体缺陷度量:了解个体缺陷产生的详细原因,并实施行动进行改进。 顾客满意度指标以顾客满意研究为基础,对顾客满意度加以界定和描述。 对于需求过程的质量度量,除了需求分析中缺陷度量外,主要集中在需求规格说明书的度 Q1 =nui /nr nui是所有复审者都有相同解释的需求数目 nr是需求说明书中需求的个数,包含功能和非功能需求 需求稳定性度量是通过需求稳定因子RSI 来表示: RSI = (所有确定的需求数- 累计的需求变化请求数)/所有确定的需求数 软件生产率度量是三维的:产出(交付的大小或功能)、工作量和时间。 质量不高的缺陷包含: 1)状态为“需要补充信息”的缺陷 2)状态为“不是缺陷”的缺陷 关于如何开展度量活动 )让软件开发者参与软件度量。 2)度量之前了解产品质量目标、过程模型和度量目的。 3)度量项目工程为目标导向,确保具备有限但相关的度量设定。 4)指定期望值(假设) 5)按规则对度量数据进行分析和解释。 6)将度量数据的分析和解释聚焦于:详细而精确的过程行为、全局过程、或者产品质量目标,但不将数据作为绩效考核的依据。 7)需要全职人员支持度量项目工程的开发团队。 8)评价确定实际产品质量和目标产品质量的差距。 9)评价过程行为对产品质量的影响。 10)将特定情景中过程行为知识存储到经验数据库中。 度量的对象是软件质量指标,而质量指标受多种因素影响,质量指标和这些因素具有相关性。度量活动开始于数据采集,数据采集需要遵循的4个标准:有效性同步性真实性一致性 ISO(International Standards Organization)-―国际标准化组织。 GB—中华人民共和国国家技术监督局是我国的最高标准化机构,它所公布实施的标准简称为"国标" CMMI其实就是SW-CMM的修订本 ISO 9001 标准适用于所有的工程行业 PSP:个体软件过程 在软件设计阶段,PSP的着眼点在于软件缺陷的预防,其具体办法是强化设计结束准则,而不是设计方法的选择。 CMMI的全称是Capability Maturity Model Integration,即软件能力成熟度模型集成模型,是一套融合多学科的、可扩充的产品集合,其研制的初步动机是为了利用两个或者多个单一学科的模型实现一个组织的集成化过程改进。 CMMI的模型构件主要有三类:需要的(required),期望的(expected),以及提供信息的构件 需要的构件:需要的构件只有一种,那就是“目标” 期望的构件:期望的构件也只有一种,就是“实践” 提供信息的构件:提供信息的构件有10种,分别是目的、介绍性说明、引用、名字、实践与目标关系表、注释、典型工作产品、子实践、学科扩充以及共性实践的详尽描述。 CMM流程改进 确定流程改进的总体框架 细化框架内的要求 明确流程改进的度量方法与标准 CMM第四级(或称为已管理级)的软件组织会根据已收集的缺陷数据,采用SPC的方法建立软件过程能力基线(Process Capability Baseline)。对于缺陷管理,可以缺陷密度为例,过程能力基线通常包括期望(Mean),能力上限(Upper Control Limit,UCL),能力下限(Low Control Limit,LCL)。其中,"期望"描述了未来项目的缺陷密度的预期值,而UCL和LCL描述了未来项目的缺陷密度的合理变化范围。 这样的过程能力基线可以用来: (1)帮助未来的项目设立量化的项目质量目标; (2)理解和控制未来项目的实际结果。 一般来说,评审(Peer Review)包括下面几种: 管理评审 技术评审 审查 走查 审计