SQA分析和总结分析和总结.pdf

软件质量保证 软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定 出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目 的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审 和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立 计划、标准和过程。这些将使软件项目满足机构方针的要求。 基本目标 目标 1: 软件质量保证工作是有计划进行的。 目标 2: 客观地验证软件项目产品和工作是否遵循恰当的标准、步骤 和需求。 目标 3: 将软件质量保证工作及结果通知给相关组别和个人。 目标 4: 高级管理层接触到在项目内部不能解决的不符合类问题。 QA 的由来 我们知道，国外很多的大公司，QA 的职责就是测试 （主要是系统测试）， 比如 IBM、CA、PeopleSoft 等。其实在最初，几乎所有的公司都是这样的。 后来，由于缺乏有效的项目计划和 软件质量保证 项目管理，留给系统测试的时间很少（注：我以前做的一个项目，项目经 理就明确告诉我系统测试就 1 天，没得商量）。另外，需求变化太快，没 有完整的需求文档，测试人员就只能根据自己的想象来测试。这样一来， 测试就很难保障产品的质量，事先预防的 QA 职能就应运而生。 事先预防其实是借鉴了 TQM 的思想，而且也符合软件工程“缺陷越早 发现越早修改越经济”的原则。这些思想的渊源还可以追溯到中国古代的 典故中，比如曲突徙薪、扁鹊论医术等。 QA 的现在 目前，实施 CMM 的企业越来越多了。 CMM 模型就要求建立 QA 角色。这 里的 QA 类似于过程警察，主要职责是，检查开发和管理活动是否与已定的 过程策略、标准和流程一致，检查工作产品是否遵循模板规定的内容和格 式。在这些企业中，一般还要求 QA 独立于项目组，以保障评价的客观性。 从国内来看，多数的 QA 没有技术背景，检查出的偏差多为鸡毛蒜皮，再加 上自己没有令人信服的背景，领导也不支持，当然做起来就很困难了。 缺乏信任和支持只是一个方面， QA 工作本身就很具挑战性。它要求 QA 具有软件工程的知识、 软件开发 的知识、行业背景的知识、数理统计的知 识、项目管理的知识、质量管理的知识等等。 我们常常遇到这样的问题，改进到一定程度就很难突破，感觉心有余 而力不足了，就开始郁闷了。后来通过学习、培训、交流，思想和技能得 到升华，又发现了木桶中最短的那块，然后又开始改进，然后又遇到了玻 璃天花板，然后„„就这样处于郁闷的循环中。 假使我们掌握了所有的知识，能突破所有的玻璃天花板，那是不是 QA 就可以一帆风顺了。答案是否定的。 QA 角色定义本身就有很大的局限性。 QA 充当的是过程警察的角色，无论是否有意义，都专横地强制过程的执行， 容易在项目组中造成敌对的关系，受到排挤，而且这种警察的姿态也破坏 了团队精神。如此一来， QA 工作还需要的是人际关系技能，就如我以前写 的《质量平衡》和《 QA 应该独立于项目组吗？》一样，艺术化地处理这种 关系。 QA 的未来 从某种程度上说，独立的 QA 审查机制是瀑布模型的产物。随着现代软 件开发技术的演变，螺旋模型和迭代模型的兴起， QA 机制正在悄然发生变 化。这种变化就是从独立专职的 QA 向贯穿过程的兼职 QA 演变。在 CMMI 模 型中，这种兼职的 QA 也是被允许的。为什么会发生这种改变呢？无论是 XP、 RUP 还是其它先进的方法论， 都是先产生架构，然后再增量开发，直到完成。 这种模式中，需求和设计缺陷在各个迭代周期被所尽早发现和修复，质量 也内建于架构和过程中，项目的成本和进度也得到保障。 到那时，是不是独立的 QA 就不复存在了呢？有些成熟度较低的企业还 是需要的，主要是保证过程执行的有效性和评价的客观性。 SQA 的理论探索 1、过程的认识 我们都知道一个项目的主要内容是：成本、进度、质量；良好的项目 管理就是综合三方面的因素，平衡三方面的目标，最终依照目标完成任务。 项目的这三个方面是相互制约和影响的，有时对这三方面的平衡策略甚至 成为一个企业级的要求，决定了企业的行为，我们知道 IBM 的软件是以质 量为最重要目标的，而微软的“足够好的软件”策略