SQA的工作内容和工作方法.doc

SQA的工作内容和工作方法
      1、 计划
      针对具体项目制定 SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点：
      有重点：依据企业目标以及项目情况确定审计的重点
      明确审计内容：明确审计哪些活动，那些产品
      明确审计方式：确定怎样进行审计
      明确审计结果报告的规则：审计的结果报告给谁
      2、审计/证实
      依据 SQA计划进行SQA审计工作，按照规则发布审计结果报告。
      注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。
      审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。
      3、问题跟踪
      对审计中发现的问题，要求项目组改进，并跟进直到解决。

六、SQA的素质
      过程为中心：应当站在过程的角度来考虑问题，只要保证了过程， QA就尽到了责任。
      服务精神：为项目组服务，帮助项目组确保正确执行过程
      了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识
      了解开发：对开发工作的基本情况了解，能够理解项目的活动
      沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。
七、SQA活动
      软件质量保证（SQA）是一种应用于整个软件过程的活动，它包含：
      1、一种质量管理方法
      2、有效的软件工程技术（方法和工具）
      3、在整个软件过程中采用的正式技术评审
      4、一种多层次的测试策略
      5、对软件文档及其修改的控制
      6、保证软件遵从软件开发标准
      7、度量和报告机制
   SQA与两种不同的参与者相关 —— 做技术工作的软件工程师和负责质量保证的计划、监督、记录、分析及报告工作的SQA小组 。
   软件工程师通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件测试来考虑质量问题，并完成软件质量保证和质量控制活动。
   SQA小组的职责是辅助软件工程小组得到高质量的最终产品。SQA小组完成:
（1）为项目准备SQA计划。该计划在制定项目规定项目计划时确定，由所有感兴趣的相关部门评审。
·需要进行的审计和评审；
·项目可采用的标准；
·错误报告和跟踪的规程；
·由SQA小组产生的文档；
·向软件项目组提供的反馈数量。
（2）参与开发项目的软件过程描述。评审过程描述以保证该过程与组织政策，内部软件标准，外界标准以及项目计划的其他部分相符。
（3）评审各项软件工程活动，对其是否符合定义好的软件过程进行核实记录、跟踪与过程的偏差。
（4）审计指定的软件工作产品，对其是否符合事先定义好的需求进行核实。对产品进行评审，识别、记录和跟踪出现的偏差；对是否已经改正进行核实；定期将工作结果向项目管理者报告。
（5）确保软件工作及产品中的偏差已记录在案，并根据预定的规程进行处理。
（6）记录所有不符合的部分并报告给高级领导者。
八、正式技术评审（FTR）
  正式技术评审是一种由软件工程师和其他人进行的软件质量保障活动。
1. 目标：
(1) 发现功能、逻辑或实现的错误
(2) 证实经过评审的软件的确满足需求
(3) 保证软件的表示符合预定义的标准
(4) 得到一种一致的方式开发的软件
(5) 使项目更易管理
2、评审会议
3-5人参加，不超过2小时，由评审主席、评审者和生产者参加，必须做出下列决定中的一个 :
（1）工作产品可不可以不经修改而被接受；
（2）由于严重错误而否决工作产品；
（3）暂时接受工作产品。
3、评审总结报告、回答
评审什么？由谁评审？结论是什么？
评审总结报告是项目历史记录的一部分，标识产品中存在问题的区域，作为行政条目检查表以指导生产者进行改正。
4、评审指导原则
（1）评审产品，而不是评审生产者。注意客气地指出错误，气氛轻松。
（2）不要离题，限制争论。有异议的问题不要争论但要记录在案。
（3）对各个问题都发表见解。问题解决应该放到评审会议之后进行。
（4）为每个要评审的工作产品建立一个检查表。应为分析、设计、编码、测试文档都建立检查表。
（5）分配资源和时间。应该将评审作为软件工程任务加以调度。
（6）评审以前所做的评审
九、统计软件质量保证
1、对所有错误进行分类统计
IES    规约不完整或规格说明错
MCC  未理解用户意图
IDS    故意偏离规格说明
VPS    违背编程标准
EDR    数据表示有错
ICI     构件接口不一致
EDL    设计逻辑有错
IET     测试不完全或有错
IID     不准确或不完整的文档
PLT     设计的程序设计语言翻译错
HCI     不清晰或不一致的人机界面
MIS     杂项错误
按严重，一般和微小级别统计各类错误的次数所占百分比，以及所有错误的数量及百分比。例如，建立一张类似如下的表格。

 然后考虑“重要少数”的错误指标，提出改进意见。
2、根据软件过程中的每个步骤计算错误指标。
Ei = 第i发现的错误总数
Si = 严重错误数
Mi = 一般错误数
Ti = 微小错误数
PS = 第i步的产品规模( LOC，设计陈述，文档页数)
Ws，Wm，Wt分别是严重，一般，微小错误的加权因子, 推荐取值，Ws=10，Wm=3，Wt=1
软件工程 在过程的每一步中，计算各阶段的阶段指标
PIi = Ws（Si / Ei）+Wm（Mi / Ei）+Wt（Ti / Ei）
错误指标
Ei= ∑（i×PIi）/ PS
  =（PI1 + 2PI2 + 3PI3 + … + i*PIi）/ PS
错误指标与上面表格中收集的信息相结合可以得出软件质量整体改进指标。七、质量保证与检验
确保每个开发过程的质量，防止把软件差错传播到下一个过程，因此，检验的目的有两个：
1．切实搞好开发阶段的管理，检查各开发阶段的质量保证。
2．预先防止软件差错给用户造成损失。
检验的类型有:
1．供货检验：对委托外单位承担开发作业，而后买进或转让的构成软件产品的部件，规格说明，半成品或产品的检查。
2．中间检验 / 阶段评审
目的是为了判断是否可进入下阶段进行后续开发，避免将差错传播到后续工作中。
3．验收检验：
确认产品是否已达到可以进行产品检验的质量要求。
4．产品检验：
判定向用户提供的软件产品是否达到令人满意的程度。
十、检验项目内容
1．需求分析
需求分析→功能设计→实施计划
检查：开发目的；目标值；开发量；所需资源；各阶段的产品作业内容及开发体制的合理性。
2．设计
结构设计→数据设计→过程设计
检查：产品的计划量与实际量；评审量；差错数；评审方法，出错导因及处理情况，阶段结束的判断标准。
3．实现
程序编制→单元测试→集成测试→确认测试.检查内容除上述外，加测试环境及测试用例设计方法。
4．验收
说明书检查；程序检查。
1．3质量保证实施

      软件质量评价标准。
1．质量需求准则：着眼点是是否满足用户的要求
2．质量设计准则：开发者在设计实现时是否按软件需求保证了质量
3．质量度量准则：为质量度量规定了一些检查项目:
   精密度量：根据质量度量准则进行详细度量
   全面度量
   简易度量

      五个实施步骤
1．Target：以用户需求和开发任务为依据，对质量需求准则，质量设计准则的质量特性设定质量目标进行评价。
2．Plan：设定适合于待开发软件的评测检查项目，一般设定20—30个。
3．DO：在开发标准和质量评价准则的指导下，制作高质量的规格说明书和程序。
4．Check：以Plan阶段设定的质量评价准则进行评价，算出得分，以质量图的形成表示出来，比较评价结果的质量得分和质量目标看其是否合格。
5．Action：对评价发现的问题进行改进活动，重复Plan到Action的过程直到开发项目完成。
1．4  软件可靠性
      可靠性统计定义：
在给定的环境和给定的时间间隔内，按设计要求成功运行程序的概率。
二、软件可靠性的主要指标
MTBF —— 平均故障间隔时间
MTTF —— 平均故障时间
MTTR —— 平均修复时间
MTBF = MTTF + MTTR
软件可用性是指在某个给定时间点程序能够按照需求执行的概率。
可用性 = MTTF /（MTTF+MTTR）×100%
1．5   ISO9000 质量标准
ISO9000标准被很多国家采用，包括欧盟的所有成员， 加拿大、墨西哥、美国、澳大利亚、新西兰和太平洋区域。为了注册成为ISO9000中包含的质量保证系统模型中的一种，一个公司的质量系统和操作应该由第 三方审计者仔细检查，查看其标准的符合性以及操作的有效性。成功注册之后，这一公司将收到由审计者所代表的注册实体颁发的证书。此后，每半年进行一次检查 性审计。
ISO9001是应用于软件工程质量保证标准。这一标准中包含了高效的质量保证系统必须体现的20条需求。因为ISO9001标准，适用于所有的工程行业，因此，为帮助解释该标准在软件过程中的使用而专门开发了一个ISO指南的子集ISO9000—3。
ISO9001描述的需求涉及到管理责任，质量系统，合约评审，设计控制，文档和数据控制，产品标识和跟踪，过程和控制，审查和测试，纠正和预防性动作，质量控制记录，内部质量审计，培训，服务以及统计技术的主题。