您好,欢迎访问三七文档
软件质量保证SQA职责与活动概要质量管理发展及发展方向SQA职责及活动质量管理发展质量管理发展五个阶段质量管理发展方向质量管理发展五个阶段1900手工操作者专职检验员1920过程统计技术1931全面质量管理19602000以顾客为中心阶段时间质量管理发展趋势一个核心和两个基本改变核心:由对结果的检验转向对过程精细的控制改变:管理范围的改变–由针对以产品生产制造服务质量管理扩大到行政部门工作质量。关注焦点的转移–由面向以产品生存周期的服务质量管理转向顾客满意为中心质量管理。软件产业要经历三个不同时代•结构化生产时代(70年代中期至90年代中期):结构化分析;结构化设计;结构化程序设计;结构化测试;结构化审查与走查。•以过程为中心的时代(从80年代中期至2010年前后):寓质量和效率于生产过程之中;关于软件过程的主要流派(ISO9000,CMM/PSP/TSP)。•软件工业化生产时代(1995年开始):基础技术(软件过程技术,面向对象技术,基于构件的开发技术);主要问题(标准化,产业文化,政策法规);对前途的估计(我国2005年可以进入软件工业化生产时代)。对于SQA一些误解误解一、如果发布出去的软件有质量问题,那是软件测试人员的错;软件的质量是做出来的,而不是测出来的对SQA与测试工作的误解误解二、软件测试技术要求不高,比编程容易多了;很多人认为软件测试就是运行一下软件,然后看看结果对不对。但实际上,如何在有限的投入下,提高软件测试的效率和产出是一件很见功底的事情。所以,好的测试人员不仅要掌握各种测试技术和测试工具,还要具备丰富的编程经验和对BUG的敏感。另外,测试统计技术也是一项很特别的技术对SQA与测试工作的误解误解五、设计-实现-测试,软件测试是开发后期的一个阶段;实际上,软件测试贯穿整个软件产品生命期。一方面,软件测试也要经历测试计划、测试用例的设计和实现,以及测试运行一系列的阶段,因此,早在软件需求阶段,甚至更早,软件测试的工作就要开始了。另一方面,软件测试越早进行越好,因为BUG越早发现,BUG造成的影响和修改的代价就越小。而且,软件测试并不仅仅针对程序,软件的需求、设计等等也要被测试对SQA与测试工作的误解误解十、SQA工作就是做测试;软件测试是一种有效的提高软件质量的手段,但测试毕竟是一种事后的、检验性的,如何在软件生产过程中保证软件过程的质量和效率其实比单纯的产品检验具有更重要的意义。不断地改进我们的软件过程是SQA的一项最重要的任务。什么是软件质量满足明确声明的功能和性能需求,明确文档化的开发过程以及专业人员开发的软件所具有的所有隐含特征(软件工程实践者理论)理解:–软件需求是质量度量的基础,与需求不符就是质量不高–制订的标准定义一组指导软件开发的标准,如果不能按照这些准则,就可能导致质量不高–通常隐含需求是不被提及的(如软件易维护性).ANSI/IEEE六個品質要素*正確性(correctness):–所製作的功能達到設計規範與滿足使用者需求的程度*可靠性(reliability):–於規定之期間和條件下,仍能維持其性能水準的程度*易使用性(usability):–使用者學習、操作、準備輸入、理解輸出所作努力的程度*效率(efficiency):–軟體執行某項功能所需電腦資源(含時間)的有效程度*可維護性(maintainability):–當環境改變或軟體發生錯誤時,執行修改所做努力的程度*可移植性(portability):–從一個電腦系統或環境移到另一電腦系統或環境的容易程度软件品質特性SQA活动内容建立软件质量保证活动的实体制订软件质量保证计划坚持各阶段的评审和审计,并跟踪其结果作合适处理监控软件产品的质量采集软件质量保证活动的数据度量软件质量保证活动軟體品保活動•技術方法的使用–使用良好的開發技術,以確保開發軟體品質•Object-Oriented,StructureDesign…–清楚而文件化的需求規格或外部功能規格–訓練良好,且技術熟練的人員–良好的專案管理技術•正式技術複核的使用–在軟體開發各階段中,有效的審查各項開發文件•確保設計的正確性與有效性•確保各組件間設計的一致性•溝通各部門間的想法軟體品保活動(續)•軟體測試•標準的實行–包含外部標準與內部標準–開發標準、文件標準、程式撰寫標準、測試執行準則...–標準的改進是軟體業矯正與預防措施之重要項目•變動(Change)的控制–建構管理、變更管制•度量(measurement)•記錄及報告各阶段活动监督、审核和跟踪评审:活动–里程碑活动评审–基线评审–SCM评审–SQA工作评审审计:工作–基线审计–SQA审计有背离之处,则对其进行标识、记录、并跟踪直至其符合。最有效的軟體品保工具有了相當好的軟體品保人員、品保計劃之後,尚必須具有最有效的工具,才能將整個軟體品保工作執行得相當透徹。甚麼是最有效的品保工具?答案是PeerReview。在所有的發展及維護過程中,PeerReview能找出相當多的問題。如何找出?茲分別敘述如下:(1)在需求分析階段:藉由需求審查,以確定需求是否正確地定義。(2)在設計階段:藉由審查程式架構及細部設計與PDL。(3)在程式撰寫階段:藉由審查SourceCode。(4)在軟體測試階段:藉由審查所有的測試文件。(5)在軟體維護階段:藉由審查所有的文件、Code、修改。PeerReview的指引(Guidelines)包括:(1)Review時包括越少人越好,而且成員越早通知越好。(2)Review必須常舉行,而且必須包括很小部份的工作。(3)Review必須強調效率及注重所Review的材料內容,其必須是該階段所能產生的最佳產品。(4)Review最好能有4小時以上的時間來閱讀資料。(5)Review最好能有LeadEngineer以上的人參加,以知道問題所在。17正式技術審核之基本觀念及指引:1.審核的是產品,而不是審核產品設計製作者。2.為正式審核安排資源及時程。3.預定議程表(Agenda),並維持該議程時間表。4.限制參加人數,堅持事先準備。5.為審核者預做有效的訓練。6.複核你先前的審核。7.對要審核的產品先列一份檢討清單(Checklist)。8.列出問題區,但是不要想要解決所有問題。9.限制爭執及爭吵。10.資料記錄白紙黑字。软件正式技术评审(review)指导作業流程範例異動需求產生異動影響評估審查簽出建構管制區異動結果評估審查交付迴歸測試判定異動結束異動執行簽入建構管制區流程圖權責單位/人異動申請人異動管制小組異動管制小組異動執行人/建構管制人員異動執行人異動執行人異動管制小組測試經理測試經理異動執行人/建構管制人員記錄異動申請記錄異動影響評估記錄異動影響評估審查記錄建構項目簽出記錄相關變更文件/軟體/程式記錄異動報告異動報告審查記錄測試記錄測試審查建構項目簽出記錄異動申請結案記錄異動申請人/異動執行人YYYNNN监控软件产品质量对软件产品的验收把握采购软件的质量监控分承包商的软件质量保证工作收集项目各个阶段数据记录不协调事项跟踪不协调事项直至解决收集各阶段的评审和审计情况缺陷密度(DefectDensity)此項因素可以提供來作作為軟體設計與程式製作品質的一項數據。其輸入參數直接來自設計與CodeInspection的過程,其中缺陷(Defects)可能為需求、設計、程式製作等種類。其運算式為缺陷總數#of單元4567…...14151617181920210.51.51.0CDRDefect/UnitContractMonthDefectsDiscoveredDefectsCorrected22度量和改善SQA活动测量的目的是为了判断SQA活动的成本和进度状态。与其计划相比,SQA活动完成的里程碑数;在SQA活动中完成的工作,花费的工作量及支出的费用;与其计划相比,产品审计和活动评审的次数
本文标题:软件质量保证
链接地址:https://www.777doc.com/doc-3166028 .html