《《软件质量保证》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《软件质量保证》PPT课件.ppt（23页珍藏版）》请在三一办公上搜索。
1、软件质量保证,SQA职责与活动,概要,质量管理发展及发展方向SQA职责及活动,质量管理发展,质量管理发展五个阶段质量管理发展方向,质量管理发展五个阶段,1900,手工操作者,专职检验员,1920,过程统计技术,1931,全面质量管理,1960,2000,以顾客为中心,阶段,时间,质量管理发展趋势 一个核心和两个基本改变,核心：由对结果的检验转向对过程精细的控制改变：管理范围的改变由针对以产品生产制造服务质量管理扩大到行政部门工作质量。关注焦点的转移由面向以产品生存周期的服务质量管理转向顾客满意为中心质量管理。,软件产业要经历三个不同时代,结构化生产时代(70年代中期至90年代中期)：结构化分析
2、；结构化设计；结构化程序设计；结构化测试；结构化审查与走查。以过程为中心的时代(从80年代中期至2010年前后)：寓质量和效率于生产过程之中；关于软件过程的主要流派(ISO 9000，CMM/PSP/TSP)。软件工业化生产时代(1995年开始)：基础技术(软件过程技术，面向对象技术，基于构件的开发技术)；主要问题(标准化，产业文化，政策法规)；对前途的估计(我国2005年可以进入软件工业化生产时代)。,对于SQA一些误解,误解一、如果发布出去的软件有质量问题，那是软件测试人员的错；软件的质量是做出来的，而不是测出来的,对SQA与测试工作的误解,误解二、软件测试技术要求不高，比编程容易多了；很
3、多人认为软件测试就是运行一下软件，然后看看结果对不对。但实际上，如何在有限的投入下，提高软件测试的效率和产出是一件很见功底的事情。所以，好的测试人员不仅要掌握各种测试技术和测试工具，还要具备丰富的编程经验和对BUG的敏感。另外，测试统计技术也是一项很特别的技术,对SQA与测试工作的误解,误解五、设计-实现-测试，软件测试是开发后期的一个阶段；实际上，软件测试贯穿整个软件产品生命期。一方面，软件测试也要经历测试计划、测试用例的设计和实现，以及测试运行一系列的阶段，因此，早在软件需求阶段，甚至更早，软件测试的工作就要开始了。另一方面，软件测试越早进行越好，因为BUG越早发现，BUG造成的影响和修改
4、的代价就越小。而且，软件测试并不仅仅针对程序，软件的需求、设计等等也要被测试,对SQA与测试工作的误解,误解十、SQA工作就是做测试；软件测试是一种有效的提高软件质量的手段，但测试毕竟是一种事后的、检验性的，如何在软件生产过程中保证软件过程的质量和效率其实比单纯的产品检验具有更重要的意义。不断地改进我们的软件过程是SQA的一项最重要的任务。,什么是软件质量,满足明确声明的功能和性能需求，明确文档化的开发过程以及专业人员开发的软件所具有的所有隐含特征（软件工程实践者理论）理解：软件需求是质量度量的基础，与需求不符就是质量不高制订的标准定义一组指导软件开发的标准，如果不能按照这些准则，就可能导致质
5、量不高通常隐含需求是不被提及的（如软件易维护性）,ANSI/IEEE 六個品質要素*正确性（correctness）：制作的功能，达到设计规范和满足使用者需求的程度；*可靠性（reliability）：在规定期限和条件下，仍能维持其性能水平的程度；*易使用性（usability）：使用者学习、操作、准备输入、理解输出所作努力的程度*效率（efficiency）：软件执行某项功能所需的计算机资源（含时间）的有效程度*可维护性（maintainability）：当环境改变或软件发生错误时，执行修改所做努力的程度*可移植性（portability）：从一个电脑系统或环境移到另一个电脑或环境的难易程度
6、,软件品質特性,SQA活动内容,建立软件质量保证活动的实体制订软件质量保证计划坚持各阶段的评审和审计，并跟踪其结果作合适处理监控软件产品的质量 采集软件质量保证活动的数据度量软件质量保证活动,软件品保活動,技术方法的使用使用良好的开发技术，以确保开发软件品质Object-Oriented,Structure Design 清楚而文件化的需求規格或外部功能規格訓練良好，且技術熟練的人員良好的專案管理技術正式技術複核的使用在軟體開發各階段中，有效的審查各項開發文件確保設計的正確性與有效性確保各組件間設計的一致性溝通各部門間的想法,軟體品保活動（續）,軟體測試標準的實行包含外部標準與內部標準開發標準
7、、文件標準、程式撰寫標準、測試執行準則.標準的改進是軟體業矯正與預防措施之重要項目 變動(Change)的控制建構管理、變更管制度量(measurement)記錄及報告,各阶段活动监督、审核和跟踪,评审：活动里程碑活动评审基线评审SCM评审SQA工作评审审计：工作基线审计SQA审计有背离之处，则对其进行标识、记录、并跟踪直至其符合。,最有效的軟體品保工具 有了相當好的軟體品保人員、品保計劃之後，尚必須具有最有效的工具，才能將整個軟體品保工作執行得相當透徹。甚麼是最有效的品保工具？答案是Peer Review。在所有的發展及維護過程中，Peer Review能找出相當多的問題。如何找出？茲分別敘
8、述如下：(1)在需求分析階段：藉由需求審查，以確定需求是否正確地定義。(2)在設計階段：藉由審查程式架構及細部設計與PDL。(3)在程式撰寫階段：藉由審查Source Code。(4)在軟體測試階段：藉由審查所有的測試文件。(5)在軟體維護階段：藉由審查所有的文件、Code、修改。Peer Review的指引(Guidelines)包括：(1)Review 時包括越少人越好，而且成員越早通知越好。(2)Review必須常舉行，而且必須包括很小部份的工作。(3)Review必須強調效率及注重所Review 的材料內容，其必須是該階段所能產生 的最佳產品。(4)Review 最好能有4小時以上的時
9、間來閱讀資料。(5)Review 最好能有Lead Engineer以上的人參加，以知道問題所在。,17,软件正式技术评审(review)指导,作業流程範例,異動需求產生,異動影響評估,審查,簽出建構管制區,異動結果評估,審查,交付迴歸測試,判定,異動結束,異動執行,簽入建構管制區,流程圖,權責單位/人,異動申請人,異動管制小組,異動管制小組,異動執行人/建構管制人員,異動執行人,異動執行人,異動管制小組,測試經理,測試經理,異動執行人/建構管制人員,記錄,異動申請記錄,異動影響評估記錄,異動影響評估審查記錄,建構項目簽出記錄,相關變更文件/軟體/程式記錄,異動報告,異動報告審查記錄,測試記錄
10、,測試審查,建構項目簽出記錄,異動申請結案記錄,異動申請人/異動執行人,Y,Y,Y,N,N,N,监控软件产品质量,对软件产品的验收把握采购软件的质量监控分承包商的软件质量保证工作,收集项目各个阶段数据,记录不协调事项跟踪不协调事项直至解决收集各阶段的评审和审计情况,缺陷密度(Defect Density),此項因素可以提供來作作為軟體設計與程式製作品質的一項數據。其輸入參數直接來自設計與Code Inspection的過程，其中缺陷(Defects)可能為需求、設計、程式製作等種類。其運算式為缺陷總數of 單元,4 5 6 7.14 15 16 17 18 19 20 21,0.5,1.5,1.0,CDR,Defect/Unit,Contract Month,Defects Discovered,Defects Corrected,22,度量和改善SQA活动,测量的目的是为了判断SQA活动的成本和进度状态。与其计划相比，SQA活动完成的里程碑数；在SQA活动中完成的工作，花费的工作量及支出的费用；与其计划相比，产品审计和活动评审的次数,
