在软件产品的研发过程中，软件质量一直处于最为核心的地位。软件企业能否顺利发展需要多方面的努力，其中软件质量保障在其发展过程中占有非常重要的位置。对于一个软件项目而言，由于所呈现的大多是脑力劳动成果的形式，很大程度上取决于项目组成员的集体聪明、编码水平和群体贡献。所以从软件项目的开始到结束（发布）过程中的动态不确定因素很多，这必然极大地增加了项目质量控制的难度，使得在按时提交软件产品的前提下有效保障软件质量成为了一个比较棘手的问题。
不同的项目组对质量保障问题的解决方法肯定不尽相同，下面我将我们安全小组的一些项目质量治理经验整理出来，其中一定有片面和不足之处，还请大家批评指正。
第一点：重视项目启动前的规模估计
为了按时提交软件产品，必然需要有一个切实可行的项目进度计划，在这个计划里还要能考虑到保障软件质量的工作量。而产生这个计划的基础就是对整个项目工作的规模估计。在我们组的软件规模估计中，是小组成员共同参加的。每个人都对即将开始的工作做出工作量估计，然后对大家的估计结果进行加权和平均，形成项目组的共同规模估计结果。这有助于小组对项目工作量和工作难度有共同的熟悉，并对维护软件质量的工作量也有相应的预备。一定程度上避免了由于项目进度计划不合理而可能造成的对软件产品质量上的影响。
第二点：项目确定共同的编码基本要求
软件的质量也就是代码的质量，对于提高代码的整体质量而言，开发人员遵循共同的基本编码规范是很有好处和必要的。我们安全组在平时的编码经验积累和参考了网上的技术文档基础上，提出了《安全组编程基本要求》。这个要求并不是面面俱到，但一定要对提高编码质量有实际的推动。为了增加灵活性，《要求》中还区别出了“必须遵守”和“推荐遵守”两种级别，供小组成员选择。
这里列举几条编程要求如下：
1.尽可能在定义变量的同时初始化该变量，指针必须在定义时初始化；
2.使用显式数据类型转换，避免让编译器进行隐式数据类型转换；
3.在函数体的“入口”处，必须对参数的有效性进行检查；
4.指针定义时初始化为NULL；在使用内存之前检查指针是否为NULL；在释放内存前检查指针是否为NULL；释放完内存后，将指针赋值为NULL；
5.使用“匈牙利“命名规则，模拟IBM代码的编程风格和注释风格；
第三点：严格遵循公司的CMM过程治理
这一点不用多说，引入CMM的过程治理经验是公司为各个项目组提供的极大帮助，为项目组及时预见和规避风险提供了有效的途径。通过CMM的各个里程碑检查，SQA人员的参与和监督，SCM人员的配置项统一治理，小组每周的周例会等等方法，为项目的顺利进行奠定了基础。而且在CMM严格的过程控制之下，通过对需求的明确定义，相应设计、测试阶段对需求的对应跟踪，对软件BUG的统一受控治理和跟踪等等，这些都为项目组软件产品的质量提供了有力的保障。
第四点：重视测试活动并引入工具以提高测试能力
大家都知道，测试活动是软件产品质量保障的最直接和最有效环节，按照测试所处研发层次的不同，又可以细分为：单元测试、集成测试和系统（总体）测试。另外在这种分法之外，还可根据测试的偏重点分为异常测试、压力测试、性能测试等。单从这么细致的测试划分就可以看出测试工作在软件生产过程中的无比重要性了。可以说测试能力的高低直接决定了最终软件产品质量的高低。
在提高测试能力方面，我们组首先是做到让测试都处于方案和计划的控制之中，包括集成测试方案/计划、系统测试方案/计划等。测试过程的BUG也都纳入了CMM的BUG治理过程，进行了跟踪和监督，确保发现的BUG都得到有效的改进和治理。
其次我们还引入了专门的测试工具来提高测试环节的能力和效率，比如：我们采用ParaSoft公司的C++ Test工具来进行严格的单元测试，自动对参数和指针进行有效性检查，并对设定的编码风格进行静态检查；采用Bounds Checker来进行内存泄漏检查；采用Iris来对网络上传递的数据包进行截获和分析，以检验程序数据传递的正确性等等。通过对这些测试工具的使用，很大程度上提高了我们组整体的测试能力，使测试中的深度和广度都有了定量的保障。
以上所列的四点经验被广泛应用于我们安全组的项目治理过程中。通过对一些中小规模项目应用的实践表明，这些经验用于软件项目质量保障是比较切实可行的，能够提高项目质量的可控性。
当然以上这些经验也只是我们组在平时工作中的一些总结，并不完全适合公司其它项目组的实际情况。在此整理出来，也只是希望能起到抛砖引玉的作用，希望在公司中形成对软件项目质量保障方法的一些讨论，以达到共同提高项目治理经验，推动公司健康发展的目的。
