搜索
软件质量保证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活动中完成的工作，花费的工作量及支出的费用；与其计划相比，产品审计和活动评审的次数