600 likes | 793 Views
7. 软件质量保证. ISO 9000. ISO 9000 是一个质量体系,制定了质量保障的规范与标准 ISO 9001 是适用于硬件、软件、流程材料和服务四大类的 9000 族标准,包含 20 个子项 我国已建立等同采用的质量保障标准族 GB/T 19000. ISO9000-3. 软件开发、供应、维护中应用 ISO9001 的指南 是指南,不是标准 强调的是供应商和顾客的关系,不是工程师该如何做. CMM. 应美国联邦政府评估软件供应商的能力的要求,由美国卡内基 — 梅隆大学软件工程研究院推出的能力成熟度模型;
E N D
ISO9000 ISO 9000是一个质量体系,制定了质量保障的规范与标准 ISO 9001是适用于硬件、软件、流程材料和服务四大类的9000族标准,包含20个子项 我国已建立等同采用的质量保障标准族GB/T 19000
ISO9000-3 软件开发、供应、维护中应用ISO9001的指南 是指南,不是标准 强调的是供应商和顾客的关系,不是工程师该如何做
CMM 应美国联邦政府评估软件供应商的能力的要求,由美国卡内基—梅隆大学软件工程研究院推出的能力成熟度模型; 将软件企业的生产能力划分为5个成熟度等级,等级愈高的企业,其软件过程的可见度愈好、软件过程的可控性愈高、产品性能的预见性以及软件项目的风险评估亦愈来愈准确。企业的生产能力以及产品质量也就愈来愈高; 强调企业软件生产过程的持续改进; 此外CMM也不仅仅应用于软件开发组织内,它也可作为认证机构的认证工具和用户考核一个企业是否达到其所要求的能力的依据。
CMM家族 CMM集成产品集 SA-CMM(软件获取能力成熟度模型):用于单位获取和采购基于软件的应用系统的软件过程 SE-CMM(系统工程能力成熟度模型):描述一个单位为保证实现一个好的系统工程的主要元素 IDEAL模型 ;一个单位用于启动、规划和实现过程改善措施蓝图的模型,概括了建立一个成功的过程改善项目的必要步骤。
CMM 的五层体系结构 优化级 (1) 持续改进过程 可预计过程 已管理级 (4) 标准化、一致化过程 已定义级 (3) 训练过程 可重复级 (2) 初始级 (1)
CMM结构 成熟度级别 CMM 级别 目标 关键过程区域 关键惯例 关键惯例 成熟度级别 关键过程区域 关键惯例
CMM五级特征 初始级:企业一般不具备稳定的软件开发与维护的环境。常常在遇到问题的时候,就放弃原定的计划而只专注于编程与测 试。 可重复级:建立了管理软件项目的政策以及为贯彻执行这些政策而定的措施。基于以往项目的经验来计划与管理新的项目。 定义级:有关软件工程与管理工程的一个特定的、面对整个企业的软件开发与维护的过程的文件将被制订出来。同时,这些过程是集成到一个协调的整体。这就称为企业的标准软件过程。 定量管理级:企业对产品与过程建立起定量的质量目标,同时在过程中加入规定得很清楚的连续的度量。作为企业的度量方案,要对所有项目的重要的过程活动进行生产率和质量的度量。软件产品因此具有可预期的高质量。 优化级:整个企业将会把重点放在对过程进行不断的优化。企业会采取主动去找出过程的弱点与长处,以达到预防缺陷的目标。同时,分析有关过程的有效性的资料,作出对新技术的成本与收益的分析,以及提出对过程进行修改的建议。
个体软件过程PSP PSP是由美国卡内基梅陇大学软件工程研究所开发出来的,它的推出在软件工程界引起了极大的轰动。PSP描述了很多资深软件工程师解决软件工程问题的方法,特别是有关软件项目计划和软件质量控制方面的先进方法。 使用自底向上的方法来改进过程,向每个软件工程师表明过程改进的原则,使他们能够明白如何有效地生产出高质量的软件。 为基于个体和小型群组软件过程的优化提供了具体而有效的途径。其研究与实践填补了CMM的空白。
个体软件过程PSP • 软件工程师的任务 • 开发出高质量的软件产品 • 在预期的费用内进行 • 在预定的进度下完成任务 • 作为一个软件工程师,无论开发的部分在整个产品中是多么小或是多么不重要,潜伏在其中的任何缺陷都可能毁坏整个系统。 • 为了生产出高质量的软件系统,每个软件工程师都必须学会高质量的工作。
个体软件过程PSP • 如何提高工作质量 • 提高工作质量仅靠努力是不行的,在很大程度上工作方式决定了所能得到的结果,因此要想提高工作亮亮,必须改进工作方式,即进行过程改进。 • PSP • 软件工程师应该计划要做的工作,然后按照这个计划来工作。这样就能够在规定的预算和时间内开发高质量的产品。个体软件工程(PSP)就是为使软件工程师更好第工作而设计的一个框架。它指出如何估计和计划工作,如何按照这些计划来跟踪自己的性能,以及如何提高程序的质量。
TSP 致力于开发高质量的产品,建立、管理和授权项目小组,并且指导他们如何在满足计划费用的前提下,在承诺的期限范围内,不断生产并交付高质量的产品。
实现TSP方法需要具备的条件 整个软件开发小组至少应在CMM的第二级(可重复层)。 全体软件开发人员必须经过PSP的培训。 开发小组成员应在2到20个人之间。
CMM、PSP和TSP组成的软件过程框架 建立 组织级能力 CMM 原则 TSP 生产并交付 费用 高质量的产品 期限 技能 建立 PSP 个人的技能
CMM对企业的要求和帮助 基于CMM模型的软件成熟度实践要求 要求尽量采用更加规范的开发标准和方法; 使用更加科学和精确的度量手段; 选择更便于管理和使用的开发工具. 因此 造成了整个工程的可重构性、可分解性和最优化; 明确了整个项目中必要和不必要的工作; 明确了整个项目的风险,以及各个阶段进行评估的指标与应急措施
ISO9000与CMM的关系 ISO9000相当于CMM二级和三级的一部分内容(有人称为2.5级) CMM和ISO9000认证本身没有优劣之分 CMM是一个动态的过程 对于预算、项目周期管理等ISO9000涉及不够的内容,CMM有所覆盖
ISO9000与CMM的区别 ISO9000是通用的国际标准,适用于各类组织。 CMM是美国军方为评价软件供应商的质量水平,委托SEI开发的一个评价模型,只用于软件业。 CMM更详细,更专业。 ISO9000只建立了一个可接受水平,而CMM是一个具有五个水平的评估工具。 ISO9000聚焦于供应商和用户间的关系,而CMM更关注软件的开发过程。
TickIT-欧洲的规则 是根据ISO9000认证软件开发组织的体系(system) 是为软件的需要对ISO9000的诠释(interpretation) 包括对审核员的表现和竞争力的一组标准要求 包括对审核员标准化培训的课程 包括审核员注册的程序(scheme) 从事TickIT认证的认证机构的认可制度
ISO9000认证 ISO9000: 机构必须经过认可 人员必须取得注册 经认可的认证中心可发证书 结论只有通过或不通过
CMM认证(1) CMM: 评审员由SEI认定/授权 每隔两年重新评定一次资格 基本要求是: 至少10年软件开发/质量保证经验 至少两年软件项目管理经验 评估框架同ISO9000类似 结果报SEI 评定结果有五个等级
CMM认证(2) 目前全球通过CMM五级的企业已有23家 印度通过CMM5级的企业就有15家 CMM在中国 北京鼎新信息系统开发有限公司ASDC (中国首家通过CMM2级评审) 沈阳东大阿尔派软件股份有限公司(成功通过CMM2级评审) 摩托罗拉中国软件中心 (通过国际CMM顶级5级认证) 联想软件事业部 (通过CMM2级)
TickIT认证 TickIT: 机构必须取得UKAS(英国皇家认可委员会)的认可 审核员必须是TickIT审核员(经过专门的认可) 其它基本同ISO9000一致
软件企业的认证与认可选择 在数量上,软件、计算机及相关企业采用ISO9000认证的为最多。 欧洲的企业较多地采取TickIT/ISO9001认证 的方式。 申请CMM认证的多为美国的公司或者是有美国背景的公司。 在已取得CMM认证的企业当中,以CMM2级居多,能够达到5级的企业寥寥可数,甚至3、4级的都不多
软件开发过程指南:RUP 是软件工程化过程,它提供了在开发机构中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下确保满足最终用户需求的高质量产品。 RUP对于所有的关键开发活动 提供了能使用准则模板工具指导来进行访问的知识基础。
RUP的静态结构 开发流程定义了"谁""何时""如何"做"某事"。四种主要的建模元素被用来表达 RUP 角色(Workers),"谁" 活动(Activities),"如何" 产物(Artifacts),"某事" 工作流(Workflows),"何时" 2014/10/9 26
2014/10/9 27
2014/10/9 28
产物可以具有不同的形式: 模型,如 Use-Case 模型或设计模型 模型组成元素,即模型中的元素,比如类,用例(use case) 或子系统般的元素 文档,如商业案例或软件结构文档 源代码 可执行文件 2014/10/9 29
2014/10/9 30
RUP 初始阶段的目标是为系统建立商业案例和确定项目的边界。 明确软件系统的范围和边界条件,括从功能角度的前景分析、产品验收标准和哪些做与哪些不做的相关决定 明确区分系统的关键用例(Use-case) 和主要的功能场景 展现或者演示至少一种符合主要场景要求的候选软件体系结构 对整个项目做最初的项目成本和日程估计(更详细的估计将在随后的细化阶段中做出) 估计出潜在的风险(主要指各种不确定因素造成的潜在风险) 准备好项目的支持环境 2014/10/9 32
RUP 初始阶段的评审标准: 风险承担者就范围定义成本日程估计达成共识 以客观的主要用例证实对需求的理解 成本/日程、优先级、风险和开发过程的可信度 被开发体系结构原型的深度和广度 实际开支与计划开支的比较 2014/10/9 33
RUP 细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。 确保软件结构、需求、计划足够稳定;确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度。 针对项目的软件结构上的主要风险已经解决或处理完成。 通过完成软件结构上的主要场景建立软件体系结构的基线。 建立一个包含高质量组件的可演化的产品原型。 说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和时间范围内。 建立好产品的支持环境。 2014/10/9 34
RUP 细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。 确保软件结构、需求、计划足够稳定;确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度。 针对项目的软件结构上的主要风险已经解决或处理完成。 通过完成软件结构上的主要场景建立软件体系结构的基线。 建立一个包含高质量组件的可演化的产品原型。 说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和时间范围内。 建立好产品的支持环境。 2014/10/9 35
RUP 细化阶段主要的审核标准: 产品的蓝图是否稳定? 体系结构是否稳定? 可执行的演示版是否显示风险要素已被处理和可靠的解决 构建阶段的计划是否足够详细和精确?是否被可靠的审核基础支持? 如果当前计划在现有的体系结构环境中被执行而开发出完整系统,是否所有的风险承担人同意该蓝图是可实现的? 实际的费用开支与计划开支是否可以接受? 2014/10/9 36
RUP 在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详尽的测试。 通过优化资源和避免不必要的返工达到开发成本的最小化 根据实际需要达到适当的质量目标 据实际需要形成各个版本(Alpha,Beta,and other test release) 对所有必须的功能完成分析、设计、开发和测试工作 采用循环渐进的方式开发出一个可以提交给最终用户的完整产品 确定软件站点用户都为产品的最终部署做好了相关准备 达成一定程度上的并行开发机制 2014/10/9 37
RUP 构建阶段主要的审核标准包括回答以下的问题: 产品是否足够稳定和成熟得发布给用户? 是否所有的风险承担人准备好向用户移交? 实际费用与计划费用的比较是否仍可被接受? 2014/10/9 38
RUP 在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详尽的测试。 通过优化资源和避免不必要的返工达到开发成本的最小化 根据实际需要达到适当的质量目标 据实际需要形成各个版本(Alpha,Beta,and other test release) 对所有必须的功能完成分析、设计、开发和测试工作 采用循环渐进的方式开发出一个可以提交给最终用户的完整产品 确定软件站点用户都为产品的最终部署做好了相关准备 达成一定程度上的并行开发机制 2014/10/9 39
RUP 交付阶段的目的是将软件产品交付给用户群体 进行 Beta 测试以期达到最终用户的需要 进行 Beta 测试和旧系统的并轨 转换功能数据库 对最终用户和产品支持人员的培训 提交给市场和产品销售部门 和具体部署相关的工程活动 协调 Bug 修订/改进性能和可用性(Usability)等工作 基于完整的 Vision 和产品验收标准对最终部署做出评估 达到用户要求的满意度 达成各风险承担人对产品部署基线已经完成的共识 达成各风险承担人对产品部署符合 Vision 中标准的共识 2014/10/9 40
RUP 交付阶段的审核标准主要包括以下两个问题: 用户是否满意? 实际费用与计划费用的比较是否仍可被接受? 2014/10/9 41
RUP的三大特点 用例驱动 以架构为中心 迭代和增量开发 2014/10/9 42
用例驱动 为了捕获附加在需求上的价值 “你希望系统为每个用户做什么” 直观 驱动过程 设计构架:选择适当的用例集合作为稳定的构架基础 编写用户手册的起点 2014/10/9 43
用例驱动 用例不仅可以用来确定系统需求 它还可以驱动系统设计、实现和测试的进行 用例驱动开发过程(use-case driven) 用例可以驱动过程,但是我们不能孤立地选择用例,它们与系统构架协调发展。用例驱动系统构架,系统构架又将影响用例的选择 2014/10/9 44
以架构为中心 建造一个能停放汽车的车库 首先,建造者需要考虑用户希望怎样使用该车库.其中一个用例是要遮蔽汽车,即要能把车驶入、停放、驶出 用户是否还想把车库作其它用途呢?假如他希望把车库作为一个家用工作间,那么建照者就向导要采光要求——要设计几扇窗户和一盏电灯 许多工具都需要用电,因此还要设计几个电源插座 。。。,其实,建造者已经在创建一种简单的架构 2014/10/9 45
以架构为中心 建造一栋摩天大厦 建筑工程师:绘制一套建筑物方法面面的建筑图纸 结构工程师:决定支撑楼架柱子的尺寸,地基承受墙、电梯、水、电、空调、卫生等结构 这些工作对于建筑工人的工作来说可能还不够,很多专业人员绘制有关材料选择、通风子系统、电力子系统、供水子系统等细节的图纸和详细说明 建筑设计师对工作全面负责,而其他各类设计人员负责补充细节问题 不同的工作者使用不同的建筑图纸来获得对建筑物的全面了解 2014/10/9 46
以架构为中心 软件构架作用与建筑物构架所起的作用类似 软件构架受到了软件应用平台,可重用的软件组件、实施问题、与遗留系统的集成等多种因素的影响。 构架刻画整体设计,忽略细节,因而依赖于人的经验的判断“什么是重要的” 过程可以帮助构架设计师确定正确的目标,如易理解性、适于将来变化的柔性以及可重用性等 2014/10/9 47
以架构为中心 约束和使能因素 用例 系统软件 中间件 架构 遗留系统 标准和政策 非功能性需求 经验 分布需要 以前的构架 架构模式 2014/10/9 48
以架构为中心 • 首先,从不是专门针对用例的构架(如平台)开始,创建一个粗略的构架轮廓。尽管这部分构架与用例无关,但构架设计师必须在创建轮廓之前对用例有一个全面的了解 • 构架设计师着手处理已经确定的重要用例子集,详细描述每一个用例,并通过子系统,类和构件来实现 • 随着用例的描述趋于完善,构架的更多部分将显现出来,从而也使更多的用例趋于完善 用例 驱动 指导 架构 2014/10/9 49
以架构为中心 在 David Garlan 和 Mary Shaw 所著的An Introduction to Software Architecture书中提出软件架构是设计的一个层次: “除了对计算所依赖的算法和数据结构进行设计外,对整个系统的结构进行设计越来越成为一个新的问题。结构方面的内容包括 系统的整体组织和全局控制结构,通信协议,同步和数据访问; 如何将功能分配给设计元素; 系统物理分布; 设计元素的合成方法,扩展性和性能以及各种设计结果的选择" 2014/10/9 50