质量是指项目满足明确或隐含需求的程度。前面讨论过，质量一般通过定义交付物标准来明确定义，这些标准包括各种特性及这些特性需要满足的要求。另外，质量还包含对项目的过程的要求，比如规定执行过程应该遵循的规范和标准，并要求提供过程被有效执行的证据。因此，质量管理主要就是监控项目的交付物和执行过程，以确保它们符合相关标准，同时确保不合格项能够按照正确方法排除。
质量管理的实质通俗地讲就是“把要做的写下来”，“把写的做出来”，“把做的过程记下来”，大家可能注意到一点：其中主要说的就是两个字“做”和“写”，与我们一般做事方法不同之处在于多了个“写”的动作，因此用“文档”管理“过程”成为质量管理的一个重要特点。我们举一个简单例子说明如何通过各种文档控制一个过程，一般这需要三种文档：
1）记录：记录活动的过程和结果，最常见的记录就是表格。一个过程可能涉及A、B、C和D四个活动，并由不同的人员执行。每个人完成各自活动后就记录处理过程和结果，并签字确认。因此这个表格留下了所有人相关人员处理的“痕迹”，一旦出了问题就可以回溯，确定是哪一步出了什么问题。
2）规程：光有一个表格还不行，还需要一个文件规定活动的执行顺序和要求，这样的文件就是规程。规程表示按A-B-C-D顺序执行，复杂的规程还可能包括条件分支，每一步骤的具体操作和要求也应该在规程中描述。
3）状态：有了记录和规程还会发生问题。比如，记录丢失了而不知道谁负责（甚至根本不知道丢失了）。这是因为不知道记录的状态当前在谁手里，处理的结果如何。因此还需要状态文档。
这确实多了一些“额外”的工作，不光需要员工额外的“文字”工作，还可能增加专职的管理人员，所以质量管理需要一定的“代价”。IT企业中，几乎所有开发人员都知道“质量”的重要性，但却不能正确看待质量的“代价”。一旦需要他们填写表格或者严格遵照流程工作时，多数都会说“太麻烦了”“效率太低了”。的确，如果没有文档工作一定程度上可以提高效率、节约成本，但长期看因管理混乱和质量低劣带来的损失可能远远大于短期的利益。还有一种常见的错误看法是“质量就是凑齐文档”，表现为在进度压力下违规操作，待完成项目后匆匆补文档。坦率地说，如果补的是中间文档（例如部分详细设计）还情有可原，如果补“过程记录”则实在不甘恭维。例如，笔者就见过在项目完成后补《测试错误记录》的情况，其实这时补这些文档对测试过程的管理已经根本没有意义，花时间精力仅仅是让项目看起来规范一些，可以算是一种“粉饰太平”的行为。个人认为，如果你真的认为一个过程不需要文档也可以控制，则可以进行适当的裁剪。其实项目并非越规范越好，应该根据具体的质量要求平衡质量和进度、成本三者的关系。
质量管理活动基本包括质量保证和质量控制两类。质量保证是在项目过程中实施的有计划、有系统的活动，确保项目满足相关的标准，典型的例子是评审和审计。质量控制指采取适当的方法监控项目结果，确保结果符合质量标准，还包括跟踪缺陷的排除情况，典型的例子就是测试。对于软件开发来说，重要的质量活动包括：
1）评审：检查项目中间产品，早期发现缺陷以减少后期修改和返工的工作量。
2）测试：直接检查软件产品中的缺陷，确保产品符合要求。一般通过单元测试、功能测试、集成测试、压力测试实现。
3）缺陷追踪：记录和追踪缺陷从发现到解决的整个过程，确保所有的问题都有结论（注意，并非一定都能解决，解决不了的要进行评价）。这是与评审和测试配合使用的一个重要管理过程。
4）审计：对项目的工作过程进行检查，确保所有活动遵循规程进行。
5）变更控制：在前面的章节中谈过，这也是一个重要的质量活动。
6）配置管理：记录这些中间和最终产品（配置项）变化的历史，确保他们的正确性和一致性。
质量管理不是一堆文档就可以解决问题的，要想确实作好有三点很重要：一是培训，要确保员工知道为什么要这样做？能解决什么问题？具体如何做？没有这种培训，员工很容易把质量管理理解为填写各种表格的繁文缛节。二是与客户交流，笔者发现很多时候因厂商没有与客户进行必要的交流，客户总觉得“什么事都要填表”是在故意刁难；通过解释客户往往非常理解，觉得这正是厂商做事规范的表现，因此会变得很配合。三是慎重选用SQA。SQA在软件质量管理中责任重大，最好有一定的开发经验，并愿意从事质量管理活动。SQA典型职责如下：
1）根据项目特点对过程进行裁剪，并审定最终的质量标准；
2）帮助项目经理制定计划并最终审批，过程中对变更进行审批；
3）进行日常的项目审计，确保项目按规程工作；
4）在阶段点对项目的基线进行审计，配置管理情况；
5）收集和分析各种度量数据，并向高层报告项目情况；
6）对项目组成员进行培训。
总之，质量管理主要通过“文档”控制“过程”。质量管理需要一定代价，要平衡与进度和成本的关系。质量保证是确保最终产品质量的一系列活动；质量控制是确保最终产品满足要求一系列活动。软件项目中的质量管理的重要角色是SQA。