第一单元-软件工程质量管理概述

第一单元软件工程质量管理概述,宋喜莲,学习这门课的现实意义,项目管理铁三角,2020/5/30,成本,质量,进度,学习这门课的现实意义,2020/5/30,1.1软件质量管理内涵,迪斯尼狮子王缺陷英特尔浮点除法缺陷程序员的千年虫问题Windows的输入法漏洞爱国者导弹缺陷,2020/5/30,1.1软件质量管理内涵,软件交付客户使用前是无形的，需要人脑理解的“逻辑”产品。软件项目的需求60%以上都是“隐形”的。软件产品用于处理客户业务，隔行如隔山。生产制造企业建立在“生产线”的基础上，软件行业是知识密集型行业，“大脑”充当了生产线上的设备，发挥不稳定且难以规范。开发人员对文档重视不够，难以统一项目团队对最终交付产品的认识。,2020/5/30,1.1软件质量管理内涵,2020/5/30,质量管理大师约瑟夫朱兰（JosephM.Juran）,产品的质量就是适用性（fitnessforuse）。即产品在使用的过程中满足客户(使用)要求的程度。大部分(80%以上)质量问题是管理层的错误而并非工作层的技巧问题。质量三部曲：质量策划、质量控制、质量改进,1.1软件质量管理内涵,质量管理大师菲利浦克劳斯比（PhilipB.Crosby）,2020/5/30,质量是符合要求，而不是最好。预防产生质量，检验不能提高质量。每个工作环节的标准必须是零缺陷。用纠正不符合项所产生的价值来衡量质量。,1.1软件质量管理内涵,产品和服务的质量改进需要持之以恒。,P(Plan)D(Do)C(Check)A(Action),每个人都有客户，如果他不知道自己的客户需要的是什么，那么他还没有了解自己的工作。,1.1软件质量管理内涵,2020/5/30,统计质量控制之父休哈特全面质量控制之父费根堡姆质量工程学创始人田口玄一QC小组之父石川馨,石川馨,1.1软件质量管理内涵,有些软件开发者仍然相信软件质量是在编码之后才应该开始担心的事情。要提高软件产品质量只能通过软件研发过程的质量的提高来实现。要严格管理软件项目按照已定义的生命周期模型、各个过程的流程、模版、准则、项目计划及其从属计划等。,2020/5/30,1.2软件质量模型-McCall模型,2020/5/30,1.2软件质量模型-McCall模型,正确性：一个程序满足她的需求规约和实现用户任务目标的程度。可靠性：一个程序满足一所需的精确度完成它的预期功能的程度效率：一个程序完成其功能所需的计算资源和代码的度量。完整性：对未授权人员访问软件或数据的可控制程度。可用性：学习、操作、准备输入和解释程序输出所需的工作量。可维护性：定位和修复程序中一个错误所需的工作量。灵活性：修改一个运行的程序所需的工作量。可测试性：测试一个程序以确保她完成所期望的功能所需的工作量。可移植性：把一个程序从一个硬件和或软件系统环境移植到另一个环境所需的工作量。可复用：性一个程序可以在另外一个应用程序中复用的程度互连性：连接一个系统和另一个系统所需的工作量。,2020/5/30,1.2软件质量模型-Boehm模型,Boehm模型着手于软件总体的功效，也就是说，对于一个软件系统而言，除了有用性以外，它的开发过程必定是一个时间，金钱和能量的消耗过程。考虑到系统交付时使用它的用户类型，Boehm模型从几个维来考虑软件的效用。总功效可以被分解成可移植性，有效性，可维护性。其中，有效性可以细分为可靠性，效率，运行工程可维护性可以细分为测试性，可理解性，可修改性。,2020/5/30,1.2软件质量模型-ISO9126,功能性：适合性、准确性、互操作性、依从性、安全性。可靠性：成熟性、容错性、可恢复性。可用性：可理解性、易学性、可操作性。效率：时间特性、资源特性。可维护性：可分析性、可改变性、稳定性、可测试性。可移植性：适应性、可安装性、一致性、可替换性。,2020/5/30,1.3软件缺陷,软件缺陷（defect）常常被叫做Bug，是软件在生命周期各个阶段存在的不满足给定需求属性的问题。偏差（variance）谬误（fault）失败（failure）问题（problem）矛盾（inconsistency）错误（error）毛病（incident）异常（anomy)Bug的来由：1945-9，使用大量继电器的MarkII突然死机，F板70号继电器异常,1.3软件缺陷,IEEE(1983)729中软件缺陷的定义：从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。,2020/5/30,1.3软件缺陷,软件缺陷的主要类型/现象：功能、特性没有实现或部分实现设计不合理实际结果和预期结果不一致运行出错，包括运行中断、系统崩溃、界面混乱数据结果不正确、精度不够用户不能接受的其他问题，如存取时间过长、界面不美观,1.3软件缺陷-缺陷判断规则,软件未正确实现说明书要求的功能；软件出现了说明书指明不应该出现的错误；软件实现了说明书未提到的功能；软件未实现说明书虽未明确提及但应该实现的目标；软件难以理解、不易使用、运行速度缓慢或者最终用户认为不好。,2020/5/30,1.3软件缺陷-缺陷的产生,项目期限的压力产品的复杂度沟通不良开发人员的疲劳、压力或受到干扰缺乏足够的知识、技能和经验不了解客户的需求缺乏动力,1.3软件缺陷-构成比例,1.3软件缺陷-缺陷的发现阶段,1.3软件缺陷-修复费用,2020/5/30,1.3软件缺陷-缺陷的分类,致命的(fatal)：造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失、主要功能完全丧失等。严重的(critical)：系统主要功能部分丧失，数据不能保存，系统次要功能完全丧失，系统所提供的功能或服务受到明显影响。一般的(major)：系统的次要功能没有完全实现，但不影响用户的正常使用。微小的(minor)：操作不方便或遇到麻烦，但不影响功能的操作和执行,2020/5/30,1.3软件缺陷-缺陷的分类练习,提示信息不准确操作时间长主要功能完全丧失字体不美观次要功能没有完全实现一运行即死机按钮稍小文字排列不齐数据未保存不上Logo拼写错误主要功能部分丧失,2020/5/30,致命的(fatal)严重的(critical)一般的(major)微小的(minor),1.4软件质量管理过程及相关岗位1,2020/5/30,质量保证(QA)小组PPQAProcess/Product,项目组开发人员,质量控制(QC)小组-软件测试人员,过程改进小组EPG,1.4软件质量管理过程及相关岗位2,软件项目组：项目经理Projectmanager需求分析师系统设计师程序员软件配置管理人员ThememberofSCMG测试工程师Testengineer软件质量管理人员ThememberofSQAG,2020/5/30,1.4软件质量管理过程及相关岗位3,软件测试部门：部门经理测试用例设计工程师白盒测试工程师黑盒测试工程师自动化测试工程师测试结果分析工程师,2020/5/30,1.4软件质量管理过程及相关岗位