【讨论贴】如何进行工程过程的QA审计?
范围:详细设计过程审核
概要设计过程审核
测试设计过程审核
需求开发过程审核
不仅仅是对工作产品审核
而是对设计过程的活动审核
如何开展?请大家发表意见 我来抛块砖头:
拿概要设计为例:
我们QA全程介入概要设计过程阶段,首先在概要设计计划下达时候,看看是否合适的人(即有相关经验的人)将从事这项工作?然后看看概要设计的输入工作产品是不是已经评审并基线化了?在设计过程中,相关的设计讨论是否实施了?相关的设计步骤是否落实了?设计过程结果和上游工作产品的一致性是否满足(就是所谓的需求追踪矩阵)?如果QA有更深入的能力,能从架构和业务逻辑上去检查设计的正确性。相关的设计方法和设计步骤是否得以贯彻?设计的最终工作产品是不是组织了合适的评审?评审过程是不是规范?基线化和配置管理工作做的如何?需求追踪矩阵是否得以延续维护?等等
不一而足。 楼主好强!! 对工作产品进行审核比较容易,可对过程如何进行有效的审核,比如评审,如何保证评审是合适的有效的。 Originally posted by skinapi at 2005-3-23 07:50 PM:
对工作产品进行审核比较容易,可对过程如何进行有效的审核,比如评审,如何保证评审是合适的有效的。
合理的计划
合适的人参与(上游产品输出人员,下游产品接收人员,测试验证人员,执行人员)
达到质量目标的度量数据 过程审计其实挺难的,但是对过程的控制和管理以及改进都会有很大的帮助。
我们现在想逐步实现这样的做法。 什么是QA呀???大哥 我是新手
请指教 QA(Quality Assessment)就是质量控制的人,审核意义上是份很严谨的工作,但是有点公司这步做了,是不是到达了真正意义上的审核,如果是为了通过CMM而做,只是形式上的,那就没什么意义了。 估计能把luoyear所提到的都做好了,做质量总监应该没问题的,呵呵~ 斑竹,有没有“工程过程的QA审计”相关的摸板和文章,请上传一下,给我们参考!!谢谢你!! Originally posted by luoyear at 2005-3-21 12:35:
我来抛块砖头:
拿概要设计为例:
我们QA全程介入概要设计过程阶段,首先在概要设计计划下达时候,看看是否合适的人(即有相关经验的人)将从事这项工作?然后看看概要设计的输入工作产品是不是已经评审并基线 ...
"如果QA有更深入的能力,能从架构和业务逻辑上去检查设计的正确性"
对此表示反对,有越俎代庖之嫌。
一个规范的组织体系中,SQA关注的是规范执行情况,除非已有相关的Design Guildline可供遵循,否则SQA关注这些将会成为用自己的短处管别人的长处。 通常QA人员不具备类似需求分析,系统架构等专业人员的专业深度,所以该角色的人不可能能够准确的检查专业领域的正确性。该角色只是确定在软件生命周期中项目成员是否按照规定进行相关的活动。所以我较为同意楼上的观点。
还有一点个人困惑。在我作SQA的过程中经常要组织一些评审活动来确保成果物的正确性,因此通常会邀请一些技术人员,部门经理,项目组成员。而这些人因为面子问题或是项目进度问题,在评审过程中敷衍了事,无法达到评审的效果,但是又不能硬性规定每人提出多少问题数。不知道各位有没有遇到国类似问题,你们是如何解决的? 我认为贵公司如果真的做到了上面说的从概要设计上开始进行测试,实在是相当不容易,一方面qa需要有足够的能力,和上游产品输出人员进行沟通,理解,另一方面如果具备更深入的能力需要对系统架构方面有着一定的了解。否则,评审工作实难进行,唯一可行的也许是验证其产品需求的正确性。
sgfsd
dsfgsdfgsdfg 我也是刚从事QA工作,现在我做的最多的就是评审工作,不知道为什么感觉各个开发人员不是很重视,评审会成了个形式。我在反思是我的问题还是公司的制度有什么漏洞。 用一个不太恰当的比喻 "天下攘攘,皆为利往"。如果参会的人员能从评审中受益,当然会积极啦。开评审会时,往往评审组长和组员都太忙,没有时间提前阅读文档,也就没有深入的分析思考,所以就提不出有价值的问题,会议就变成了形式。
这种时候,QA就要自己先做些功课,熟悉评审内容,技术功底和项目经验在此就派上用场了,然后在会议上提出问题引导大家进行有深度的讨论。经过几轮之后,大家就会了解评审的作用,也会更自觉的做评审前的准备工作,开会时也会更积极的参与。
一些个人经验,供大家参考。 原帖由 kaolaki 于 2005-8-2 12:15 发表
通常QA人员不具备类似需求分析,系统架构等专业人员的专业深度,所以该角色的人不可能能够准确的检查专业领域的正确性。该角色只是确定在软件生命周期中项目成员是否按照规定进行相关的活动。所以我较为同意楼上 ...
个人觉的遇到这种情况可以请公司高层领导参与评审会议,如技术副总/技术总监等.领导要为公司的整体利益着想,一般也就不可能再让下面走走过场.要不然出了问题,他也不好交待. 可以对评审的效率、效果进行考评。如评审设计文档,可以从每页发现缺陷数及每小时文档覆盖率等指标来对评审效率进行考评。可根据以往的数据,整理出一个数据区间。如果评审的结果落在这个区间,则评审的效率是正常的、可接受的。如果结果落在区间外,则要进行原因分析。
对于评审效果的考评,可以通过项目结束后,进行缺陷引入阶段的分析,以此来判定评审的有效性。 原帖由 kaolaki 于 2005-8-2 12:15 发表
通常QA人员不具备类似需求分析,系统架构等专业人员的专业深度,所以该角色的人不可能能够准确的检查专业领域的正确性。该角色只是确定在软件生命周期中项目成员是否按照规定进行相关的活动。所以我较为同意楼上 ...
我们公司的做法是:评审前项目经理发评审通知及评审材料,每个人对评审的产品提出问题,在评审会议上逐一过问题,会议后进行缺陷跟踪更正。 lihai
页:
[1]
2