chapter_14软件质量概念130418.ppt

问题 软件质量为什么重要？ 质量不好会怎么样？ 是谁的责任？ 什么措施可以保证质量？ 美国加利福尼亚机动车辆局想把司机执照和车辆注册系统合并为一个系统，但几年之中，投入的成本暴涨到预期价格的6.5倍，最终，取消了项目，放弃了4500W美元投资； 美国航公公司把机票预订技术和汽车、旅店预订系统集中到一起，几年后，垮掉了，产生了一堆官司，注销了1.65亿美元项目； 2001年，超过4000个软件项目，美国、欧洲和亚洲的186个公司收集数据，发现： 有33%超过预算；53%项目需要消耗最初估算的189%；只有16.2%的项目按时并在预算内完成；大型公司中，只有9%的项目按时在预算汇总完成。 软件项目案例 案例角色和人物 要确保软件系统的质量(1/4) 软件项目已经开始实施，工作完全按照计划的要求进行，一切似乎非常顺利 按照计划要求，需求分析小组在需求分析截至时间的前一天撰写好了软件需求规格说明书，项目经理对他们的进度感到满意，因为他们没有拖延时间和进度 由于进度的紧迫性，需求分析完成后的第二天，项目开发组马上转入到了软件设计阶段的工作，令人欣慰的是软件设计的工作同样进展顺利，并且提前一周完成软件设计工作，撰写了软件设计规格说明书 尽管软件设计提前完成，项目组仍然决定立即进入编码阶段的工作，期望能够尽快完成在进度约束范围内完成编码工作，提交软件产品 要确保软件系统的质量(2/4) 各个程序员工作的非常卖力，已经编写了各个软件模块并且对所编写的各个软件模块进行了测试，认为软件已经没有什么大的问题，即使有也是微不足道的，最终将目标软件提交给了用户 用户在使用了该软件后发现了诸多的问题，用户对项目组的工作很有意见，于是项目组不得不重新作需求分析 软件没有完全满足他的要求 有些软件功能与他所想象的不一致 软件系统不稳定，经常出现死机现象 在将用户需求了解清楚之后，设计小组对该软件重新进行改造，发现软件结构不好，要对软件进行调整和修改非常困难 要确保软件系统的质量(3/4) 然而为了完成项目的要求，设计小组只好硬着头皮对软件设计进行修改和调整 经过调整后的软件系统问题更多，系统不稳定，有大量的错误，软件变得极为脆弱，为此项目组不得不推翻原有的设计，对整个软件重新进行设计和编码 项目最终在拖延了8个月后交货，然而此时项目组成员已经筋疲力尽 回顾整个项目的历程，项目组成员发现导致这种状况的主要原因是在整个项目实施过程中，项目组没有对项目进行有效的质量监控 软件开发项目如果不吸取该项目的经验教训，相信会重新犯这样的错误，经历这样的恶梦 要确保软件系统的质量(4/4) 有关软件质量的一些数据 20世纪80年代欧洲的“亚利安娜”火箭发射的失败 由于软件出现问题，美国DoD推迟B1轰炸机的部署 由于软件出现问题，美国DoD取消了耗资580亿美元的A12飞机的计划 大量的软件由于质量得不到保证，在交付给用户使用之后不得不被抛弃 案例提示我们 质量保证是极为重要的 在软件项目实施过程中必须提供待开发软件质量的可视性 缺乏质量保证，将会导致所开发的软件不能满足用户的期望和要求 缺乏质量保证，将会导致整个软件项目延期，甚至失败 质量是工程师考虑的唯一问题吗？ Robert Glass给出公式： 用户满意度= 合格的产品+ 好的质量+ 按预算和进度安排交付 14.2 软件质量 定义：在一定程度上应用有效的软件过程，创造有用的产品，为生产者和使用者提供明显的价值。 软件质量模型 软件质量要素直接影响软件开发过程各个阶段的产品质量。 由于对软件质量理解的不断深化，软件质量要素不是一成不变的。 McCall等人给出的软件质量要素共11个，分为三类，分别面向软件产品的运行、修正、转移。它们与特性的关系如图所示。 软件质量模型 正确性：在预定环境下，软件满足设计规格说明及用户预期目标的程度。它要求软件没有错误。 可靠性：软件按照设计要求，在规定时间和条件下不出故障，持续运行的程度。 效率：为了完成预定功能，软件系统所需的计算机资源的多少。 完整性：为了某一目的而保护数据，避免它受到偶然的，或有意的破坏、改动或遗失?的能力。 可使用性：对于一个软件系统，用户学习、使用软件及为程序准备输入和解释输出所需工作量的大小。 软件质量模型 可维护性：为满足用户新的要求，或当环境发生了变化，或运行中发现了新的错误时，对一个已投入运行的软件进行相应诊断和修改所需工作量的大小。 可测试性：测试软件以确保其能够执行预定功能所需工作量的大小。 灵活性：修改或改进一个已投入运行的软件所需工作量的大小。 软件质量模型 可移植性：将一个软件系统从一个计算机系统或环境移植到另一个计算机系统或环境?中运行时所需工作量的大小。 复用性：一个软件（或软件的部件）能再次用于其它应用（该应用的功能与此软件或