功能点驱动的贯穿整个软件开发生命周期的软件质量保证和控制方法.doc

功能点驱动的贯穿整个软件开发生命周期的软件质量保证和控制方法1、目的软件的质量根植根植于开发过程中，为了保证软件开发过程和提交物的质量，需要在整个生命周期实施质量保证和控制活动。主要的质量保证活动有评审和走查，主要的质量控制活动是测试。如何确认在开发各个阶段该做的质量保证和控制活动（以下简称为质量活动）是否已做、做的是否充分、做的效果是否好等，并通过质量活动得到的数据分析已发生和出现的问题和缺陷来进行缺陷预防和持续改进，达到保证和控制开发过程的质量。一般传统的质量方案、质量计划和检查表三层质量管理法具有指导意义，但缺乏一定的可操作性、实效性和可视性，对此，根据项目质量保证工作实践经验，提出了功能点驱动的贯穿整个生命周期的质量保证和控制方法。2、方法 这个方法很类似制造业的产品作业中的流程，正向记录每个环节的制造和检验活动，反向检验上道工序：1）正向跟踪：沿瀑布生命周期，从需求-设计编码-测试-上线试运行-运维从前到后不断补充和确认各阶段上主要质量活动的具体执行情况，具体包括五个要素：1. 活动名：各个阶段所实施的工程活动名（如需求、设计、编码等），以及主要的质量活动名（评审或测试等）；2. 人：实施工程活动和质量活动的人，如编码人员、代码走查人员、测试人员等；3. 规模：工程活动或质量活动提交物或成果的大小，文档是文档页数，代码是代码行数或功能点数，测试案例是测试案例个数等；4. 工作量：实施工程活动或质量活动的工作量，如编码工作量、代码走查工作量和测试工作量等；5. 问题或缺陷数：质量活动所发现的问题或缺陷数，如评审问题数，测试发现缺陷数等；随着项目推进，在各个开发阶段通过逐步建立正向跟踪矩阵，将不断检查和确认各个阶段相关的工程、质量保证和控制活动是否做了（工程名、质量名），是由谁做了（人），是否做的充分（工作量）、做的结果（规模、问题和缺陷数）等。通过正向跟踪，可以及时了解和发现没有做的（没有活动名称）、做的不够充分的（工作量不足）和做的效果不好的（问题或缺陷密度高）的，以便采取相关加强和纠正措施。同时，通过相关的数据，可以自动统计出一些派生的数据指标，如生产率、缺陷密度、评审效率等，利用这些指标，也可以较进一步了解人员的开发和质量活动情况。2）逆向回溯：在项目建立好正向跟踪矩阵后，可以事后，沿瀑布生命周期的相反方向，从需求-设计编码-测试/-上线试从后向前分析和验证上一阶段上主要质量保证和控制活动的执行效果。如，如果系统测试阶段发现的此功能点的缺陷密度较高，则说明上一个阶段的编码的自查、单元测试和代码走查的力度和效果不好，以致将缺陷遗漏至系统测试阶段等。通过事后的逆向回溯，则可以判断这个阶段以前的质量情况，据此，可以进行缺陷和问题产生原因、质量活动不利等根本原因分析，以便在下一阶段有的放矢地补充和加强质量活动措施。通过上述的正向跟踪，可以检查和确认开发和质量活动的覆盖和执行情况，通过逆向回溯，可以进行问题根本原因分析和持续改进。结合正向跟踪和逆向回溯，可以形成软件开发过程的系统地、完整的质量保证和控制方法。3、具体实施 在开发各个阶段补充和填写开发活动和质量活动的上面5个要素的基本信息：1）需求阶段：建立需求功能点列表，分别列出对应需求功能点对应的需求提出人员、需求分析人员、需求评审人员、规模、评审发现问题数、评审工作量。2）设计阶段：建立系统功能点列表，并建立系统功能点与需求功能点对应的列表，列出对应系统功能点对应的设计人员、设计工作量、规模、设计评审人员、评审发现问题数、评审工作量等。3）编码和单元测试阶段：列出系统功能点对应的编码人员、编码工作量、编码行数、单元测试案例数、单元测试结果、代码走查人员、走查发现问题数、走查工作量等。4）内部测试阶段：列出系统功能点对应的内部测试人员、测试工作量、内部测试案例数、内部测试缺陷数等。5）系统测试阶段：列出系统功能点对应的系统测试人员、系统测试工作量、系统测试案例数、系统测试缺陷数等。6）用户UAT测试阶段：列出系统功能点对应的UAT测试人员、UAT测试工作量、UAT测试案例数、UAT测试缺陷数等。7) 试运行和维护阶段：列出系统上线后对应功能点所发现的缺陷数、修复工作量、测试工作量、修复人员等信息。 通过以上在各个开发阶段建立起以子系统/模块/功能点为粒度，对应的开发活动和质量活动基本信息的跟踪矩阵，实质上就是将质量活动落地的过程、是质量活动检查和确认的过程、也是开发活动和质量活动分析和持续改进的过程。4、实现方式有两种实现方式：表格和工具。1）表格: 可以使用excel表格记录和对应各个阶段的开发和质量活动信息。2）工具：可以利用需求管理工具（如Doors）或缺陷管理工具（如QC）等进行记录和管理，可以将需求管理工具的需求跟踪矩阵进行扩展，增加质量活动信息。5、相关数据源获取和管理对主要的几个要素的数据源的记录、获取和管理的现状和建议说明如下：1）工作量：目前公司的工作量统一记录在日志管理系统，相关工作量数据也从此平台获取进行统计和分析。建议：项目经理可以根据项目的需要，细化项目计划到子系统、模块、功能点，项目人员可以据此填写日志，就可以获取此功能点、模块、子系统的开发和质量活动工作量数据；2）问题和缺陷数据：目前的重要提交物的评审问题记录在工作管理平台上，一般的可能记录在excel、word文件中；缺陷则统一记录在QC中。建议：建议今后评审的问题可以统一记录在QC中，同缺陷共用QC，一同进行记录、管理等，可以在缺陷类型和发现阶段相关字段上，填上需求阶段、设计阶段等。3）规模：文档的规模，目前没有明确记录方法；代码的规模大粒度（子系统、大模块）的配置管理人员可以统计，小粒度的（模块、功能点）则需要开发人员提供。建议：在文档和代码入CVS库的同时，统计和记录文档和代码的规模，一同随文档和代码记录在CVS中。6、适用项目这个方法很类似制造业的产品作业中的流程，正向记录每个环节的制造和检验活动，反向检验上道工序，此方法是很自然、不言而喻使用在制造业，但在软件开发业，受企业能力成熟度的制约，并不是很多项目能做到这样的质量管理。建议下面类型的项目可先行：1）对质量要求高的项目；2）独立外包和合作开发项目；3）关注特定子系统/模块/功能点质量的项目；4) 其他想要这样做的项目等。7、试用建议1）裁剪使用：根据项目特征和需要，可以将质量保证和控制的粒度定义在功能点级或模块级或子系统级、工作量可以选择在关注的活动上而不是所有活动上、质量活动可以选择关注的质量活动上而不是所有质量活动上、规模只收集关注的提交物上而不是所有提交物上，等等，可取下面表格的子集；2）实施方式：先采用excel表进行记录和管理；3）组织实施人员：在项目经理领导和支持下，可以由项目QA来组织开发、测试等方建立和实施，并进行定期或不定期的统计分析，提出发现问题和解决建议等。8、基础