一、软件质量定义

ISO9000:2000《质量管理体系－基础和术语》中把产品定义为：“过程的结果”，而且这种结果是非自然性的，也就是说实际上这种结果是人们所预期的，而不像的打雷下雨那样具有自然性。

二、 国内软件质量管理发展概况

在国内软件业开始诞生和起步的时候，软件企业在质量管理方面比较落后，大部分的软件企业没有设置专门的测试组织和招聘专职的测试人员。软件产品的质量完全依赖于程序设计和编写者的技术水平和工作效果。这种依赖使得软件产品的质量水平低下。

虽然国内一些软件企业在2000年左右开始建立内部的测试小组，但仍然只起到了“事后检验”（即在已集成的版本上进行的一些基于用户操作层面上的测试和检验）的功能，大部分产品质量缺陷仍然无法及时和较全面的被发现和解决，更不用说“预防缺陷”。

即使这种具有“事后检验”功能的测试小组被建立，但由于没有必要的支持 ，以及人力资源投入严重不足，导致测试小组在软件质量上的贡献和业绩表现并不佳。同时由于对产品质量的认识缺乏全面的理解，仅仅建立一个测试小组对产品质量的提升很有限。

随着中国WTO的发展步伐，国内涌现出了越来越多的软件企业，其中以外包企业为主，外包软件开发公司一般都需要取得一定的资质认证才能够接到来自国外的委托项目，其中以CMMI认证为主。国内软件行业即将迎来一个新的发展时期――规范与规模化。

三、 面向软件开发过程的质量识别与控制

对是质量管理来说，结果很重要，过程也很重要。

我们的产品质量低下时，通常只讨论责任问题。

为什么、是什么原因导致产品质量低下？我们真正花在解决质量问题的时间非常之少。

（一）获取过程质量

有过程就必然有过程质量。

软件产品是需要经过一系列的过程才得以形成的

根据软件工程理论，在瀑布式软件开发过程中定义了软件产品的基本开发过程：需求分析-->系统设计和详细设计-->代码编写/单元测试-->集成测试-->系统测试。

以瀑布式软件开发过程为例：

（1） 在软件需求定义阶段会产生“需求质量”；

（2） 在软件设计阶段会产生“设计质量”；

（3） 在软件实现阶段会产生“实现质量”（如程序代码质量、图像素材质量、音乐质量、版本制作质量等等）。

（二）过程质量控制

过程质量控制＝规范+输入/输出标准+反馈（控制点或检查点）

从整个研发过程看，我们需要制定一些规章制度和项目研发规范来使工序部门之间的工作能够协调开展，比如设置工序部门的工件输入、输出标准，让质量低下的工件不会流入下一个工序环节，起到“缺陷预防”的作用。

如果我们单独看某一个工序部门（如负责需求分析的产品组，为了确保需求描述文档的准确性与易读性，可以制定一种“需求设计规范”或“需求文档编写规范”来使需求设计工作实现内部理解一致，即让需求分析人员编写出格式统一，表述统一的需求文档。这样的文档才能便于程序员去理解和实现，同时测试人员也可以从这样的高质量需求文档中获益，提高测试工作质量。同样的在程序设计方面，可以制定“程序设计规范”、“代码编写规范”来实现程序设计质量的提升。

假设我们将软件最终质量分解到过程中，为：“需求质量”、“设计质量”、“实现质量”、“发布和维护质量”。质量控制点一般设置在工序节点处，这样比较经济一些。如下图所示：

控制点一般采用“评审 ”或“审查 ”为主，当然技术手段也很重要。

1、 需求管理与质量

目前，迭代式开发方式已基本替代了瀑布式开发方式而被越来越多的企业所采用。

迭代式开发方式主要解决了风险与需求变更问题，那么需求管理在迭代式开发方式中也显得极为重要，需求管理好了，项目开发过程将会事半功倍，开发将会有节奏，项目可视化程度 将会得到提高；需求管理不好，项目将面临频繁返工、功能混乱、重构代码工程次数高、测试用例维护成本太高和工作低效率、低质量的境地。

无论是哪种软件产品（即使是游戏产品），软件需求必须首先规划好、组织好，比如采用FPA（Function Point Analysis）或者Mk II（ISO 14143/1）。当前也有相当多的游戏开发人认为游戏是一种比较特殊的软件产品，游戏的内容基本上属于“创意”，传统的软件需求管理方法不适用于游戏项目。其实事实上并非如些,因为游戏也是软件，只是该软件的质量特性增加了“游戏性”，传统软件的功能性、性能性、安全性、稳定性等质量特性同样具备。

需求文档作为软件特征的描述的主要载体，它是软件开发过程的起点。

需求质量特性一般可以有：

审查类别 审查内容

需求完整性 需求优先级

外部硬件，软件接口，通讯接口

计算部分，是否有必要的算法

正确性 需求是否有相互矛盾的地方

需求是否超出项目范围

需求是否明确无二义性的描述

质量 性能目标是否给出

安全特性是否给出

其他 其他方面

注：表格中列出的内容仅作为示例，根据企业和项目的实际情况，可以补充完善。

2、 设计质量与实现质量

设计质量侧重于系统架构和接口，以可实现性、可扩展性、可维护性为主要衡量指标。设计质量的检验时机一般比较滞后，因为它需要由“系统或模块需要进行重构”、“某个需求无法在现有系统上被实现”表现出来。所以设计质量控制多数采用“评审”和“审查”的方式，由几个经验丰富的系统设计师来主持完成。

实现质量一般为程序代码，也有图形图像、音乐、版本制作等。以程序代码质量为例：

代码的质量一般采用代码规范约束、单元测试以及“Code Reivew”的方法进行控制，关于“Code Review”与单元测试的解释在此不再敷述。

我们可以将程序代码的质量整理为：

编号 重要性 审查项

7.1 ★ 避免将正常值和错误标志混在一起返回，返回值尽量用做成功失败检查

7.2 ★ 在函数体的“入口处”，对参数的有效性进行检查

7.3 ★ 避免滥用assert

7.4 ★ 避免return语句返回指向“栈内存”的“指针”或“引用”

7.5 如果参数是指针，且仅作输入用，则应在类型前加const

7.6 尽量采用“const &”方式来传递对象

7.7 参数的书写完整，禁止只写参数的类型而省略参数名字

7.11 避免省略函数返回值的类型

7.12 函数名字与返回值类型在语义上一致

7.13 使用const提高函数的健壮性

7.14 函数的功能要单一，不要设计多用途的函数

7.15 避免函数带有“记忆”功能。相同的输入应当产生相同的输出

注：表格中列出的内容仅作为示例，根据企业和项目的实际情况，可以补充完善。

四、 循序渐进的质量提升

（一） 质量提升的基础

产品的质量是最容易被识别的，产品的开发过程的质量却不容易被识别和发现。

由于质量分布于具体的过程，过程需要良好地衔接起来才能够协调工作。工件的管理作为软件开发工作中的基础性工作，起到了关键性作用。而这方面在传统制造业已经积累丰富经验（全面质量管理（TQM）是比较经典的一个！）

一般情况下，软件开发组织至少具备三个职能组：产品组（或需求组）、程序组、测试组，而配置管理组往往被忽略。在很长的一段时间里（有的企业至今仍未建立配置管理组织），大多数小型软件开发企业对资产管理的理解不够全面，认为只要管理好当前已编译好的产品就足够了，用户使用说明书、设计文档、程序代码、第三方组件（产品）几乎都是只储存于个人计算机硬盘上，企业没有专门的储存空间的相应的完善的管理机制，值得一提的是，开发流程（工序流程）也需要纳入资产里面。

开发团队的工件得不到好的管理，使得团队工作经常性地遇到：找不到文档、死文档越来越多、版本错误的问题。而这些问题是造成了开发团队的工作效率和质量大降重要原因之一。工件的管理在较大规模的团队中更为重要。工件是团队协作的主要依据，也可以作为沟通的桥梁！

我们总是强调沟通的重要性，却在沟通上出了最多的问题和浪费了最多的时间！

所以，提升软件产品的质量，首先应当做好配置管理工作，识别软件资产内容、对软件资产进行有效的管理，提供必要的开发环境支持，减少不必要的文档检索时间，快速地获取到正确的文档（或代码），加快项目的迭代过程，提高迭代频率。

（二） 全员参与的质量提升

软件产品的质量是全面的。

正因为它需要经历若干个开发过程和若干个专业人员，其质量特性之间也可能存在较大的差异，需要不同的控制方法和具备相关技能的检验人员。如需求质量和程序代码的质量，前者需要非常了解用户需求，与用户接触密切，以及具有对市场的把握能力。后者则需要掌握程序编写技术、调试技术、设计能力和项目开发经验。在实际项目实践中，当然不可以按照“需求分析”分配“需求测试人员”，“系统设计”分配“系统测试人员”这样的形式去投入和安排资源，但是我们可以针对项目自身的特点（比如哪个环节的工作质量比较差，容易出错）来加强人员培训和投入人力资源。我们更加趋向于提升各生产环节的人员自身的工作质量，因为这样更及时发现问题和解决问题，更加符合经济性原则。

（三） 建立专职质量提升组织

组织是工作有序进行的基本保障。

项目管理团队热衷于制定制度和规范，规范和制度的执行效果却很少关注。

建立一个过程改进小组，有利于制度的规范的实施，这个小组可以定期向项目管理团队提供项目状态报告（如评审会议情况、需求变更情况、每周产品缺陷趋势图、任务完成状态图、工作质量状态报告）。这样可以做到项目管理团队在第一时间获悉存在的问题和及时地解决问题。过程改进小组的工作职能并不一定要与CMMI描述的那样，我们可以根据实际情况定义它的工作职能，而且这个定义也是一个动态、持续改进的过程。