2.7 CMMI2级——进程与产品质量保证(Process and Product Quality Assurance)

2.7 CMMI2级——过程与产品质量保证(Process and Product Quality Assurance)
什么叫“SQA”?很多人知道是“Software Quality Assurance”,中文翻译叫“软件质量保证”,但有谁真正理解SQA的含义呢?
很多公司都会有“质量保证部”,这些质量保证部有哪些职能呢?大家可以做一下选择,下面这些选项,你会选哪些呢?
A.测试
B.审核产品的质量
C.审核是否按照过程开展工作
D.审核工作产品是否符合过程要求
E.其它(大家可以自己列出来)

另外也请大家判断一下以下问答是否有问题:
问题:什么人适合做SQA?
回答:软件管理高手以及技术专家。
问题:设计评审时,如果SQA认为设计不合理,应该怎样办?
回答:按照SQA的要求来做。

SQA的意思是软件质量保证,这样翻译有没有问题呢?反过来问,软件质量是由什么保证的?是不是仅靠CMMI 2级中的PPQA就可以搞定呢?

软件的质量,是由某个人决定的?还是由团队决定的?还是过程决定的?


CMM2级的时候,还是叫“SQA”,但到CMMI2级,已经“更名”为:PPQA(Process and Product Quality Assurance),中文名称为:过程和产品质量保证。质量保证主要针对两个方面,一个是保证按过程执行,另外一个就是保证工作产品符合过程要求。那是不是这个PA做好了,就一定可以保证质量呢?答案是:不是,质量还要似乎组织遵照执行的过程的质量。


澄清了SQA,下面我们开始说说PPQA这个PA。

这个PA有两个SG,我们分别来看看。

SG1: Adherence of the performed process and associated work products and services to applicable process descriptions,standards,and procedures is objectively evaluated.
中文大意是:依据一定的标准的客观地评估被执行的过程及相应的工作产品。这里要注意几点:
1)要有一定的标准,这是基础。
2)评估要客观。
3)要对过程、产品都进行评估。

SP1.1: Objectively evaluate the designed performed processes against the applicable process descriptions,standards,and procedures.
中文大意是:依据一定的标准客观地评价过程。

SP1.2: Objectively evaluate the designated work products and services against the applicable process descriptions,standards,and procedures.
中文大意是:依据一定的标准客观地评价工作产品。
如何检查软件生产活动,保证按照组织的相应规定进行了,无非就是两个方面,一个是看看活动的过程是否按照组织的要求进行,另外一个方面就是看看活动过程中产生的工作产品是否符合组织的要求,例如是否符合模板要求、是否有要求的内容等。
这两个SP看上去简单,其实要做好,要做到两点:
1)组织定义的过程、工作产品的模版一定要明确、合理,并且具有可检查性。
2)QA对要理解要检查的过程和工作产品。

SG2: Noncompliance issues are objectively tracked and communicated,and resolution is ensured.
中文大意是:发现的问题要客观地被跟踪、沟通并解决。

SP2.1: Communicate quality issues and ensure resolution of noncompliance issues with the staff and managers.
中文大意是:要和员工和管理者进行沟通,并保证解决问题。这个SP有两点要求:
1.QA发现的问题一定要与相关的员工和管理者进行有效的沟通。
2.要保证发现的问题最后被解决。

SP2.2: Establish and maitain records of the quality assurance activities.
中文大意是:建立和维护质量保证活动的记录。

PPQA只有4个SP,非常简单,但要做好很不容易,下面列举一下QA工作中常见的问题:
1.QA与被检查者的关系不好。
2.被检查者以应付的心态应付QA的检查。
3.QA经常埋怨被检查者不按规定干活。
4.被检查者埋怨QA不理解项目的状况,只会按条条框框办事。

这些问题,总结起来无非是以下的原因:
1.过程本身制定就很有问题,很难按照过程执行。
2.QA缺少软件开发经验,对过程理解不深。
3.QA没有更关注问题的预防,在过程未进行之前,没有对执行过程者进行相应的教育,让过程执行者明白这个过程的道理。
4.QA没有去了解项目的背景以及相关的技术,无法对项目组成员提供有效的执行过程的指导,只能依据条条框框进行指引,项目组无法理解过程的价值。

简单的说只有两个方面,一个就是过程本身的质量,一方面就是QA的水平了。

有人可能会说,过程就算是错的,也需要执行,在执行中持续改进。这个观点在某些情况下是不对的,要看过程错的程度。如果过程错到根本无法执行,这样强硬执行的话,肯定吃力不讨好。

在刚建立过程的时候,不宜太死,可以适当宽松,另外应该鼓励项目组定义自己的做法,然后QA就按照项目组自已定义的做法来监督执行。通过不断的积累,就可以建立比较完善的过程。




请看下一文……

 

 

 

作者:张传波

创新工场创业课堂(敏捷课程)讲师

软件研发管理资深顾问

CMMI首席专家

《火球——UML大战需求分析》作者

www.umlonline.org创办人