【项目管理知识】质量管理：软件开发各阶段的质量管理

1、质量管理：软件开发各阶段的质量管理提到软件开发，我们的脑海里总是浮现出这样的情景：开发组的每一位成员都在辛苦的工作，有的加班加点，甚至通宵达旦是常有的事，虽然项目经理 修改了一次又一次的进度计划，而实际的开发情况却总是很令人担忧，以至于 每次向领导汇报工作的时候总是觉得以前制定的计划没有很好的完成，总是觉 得人力资源不够，总是觉得我们没有太多的时间。等到代码终于开发完成了， 测试进度却又非常令人担忧，每一个小 BUG都要花很长的时间去查找，改了某 一个小错误却又引起了很多错误，结果产品发布遥遥无期，而项目组里的每一 位成员已经筋疲力尽。怎样摆脱这样的困境呢？为何软件开发项目管理这么困难呢？为何

2、我们做 的计划总是不能按时完成呢？为何软件开发不能像硬件开发那样可以控制呢？ 原因在于软件开发完全靠人的大脑思维产生出产品，而每个人的大脑思维是不 一样的，因此在软件开发过程中有太多不确定的、可以变化的因素，我们怎样 把握住这些变化因素呢？就像我们题目所说的一样，软件开各阶段的成果质量 管理，如果我们能够很好的控制软件生命周期每一个阶段的质量，也就很好的 控制了整个软件开发的整个过程。软件产品的质量是个很大的概念，因为软件产品完全是人们大脑思维的产 物，就是将大脑里无形的看不见摸不着的思维变成一个可以看到的，可以解决 实际问题的一组界面或者组件。这样的一个复杂的过程，质量应该如何保证 呢？有人

3、想到了 ISO9000、CMM ，也有人很反对，说应该用敏捷开发。其实，不管用什么样的开发过程，关键是找到这些过程的真谛，有些人说，ISO和CMM 到中国来就变了味了，为什么变味儿了呢？其实我们只学到了该做什么， 却不知道怎样去做，为什么要这样做？大家都知道做软件开发需要写需求规格 说明书和设计文档，为什么要写，文档的重要性有多高？没有资深开发和管理经验的人员可能很难理解其重要性，如果只是简单的形式上去写一篇这样的文 档，对后面的编码和测试没有实际的指导作用，甚至起了 “误导 ”作用，同样会引起大量返工，那么这些文档除了负担之外就没有其他用途了，要知道写这些 文档是需要消耗项目组资源的（进度、

4、成本 .）。很多人又想到了测试，觉得是我们测试的力度不够，所以我们产品质量不 过关，其实，软件开发的质量保证从开发初就应该开始了，如果到了测试阶段 才重视就已经晚了。软件产品开发过程，不管采用瀑布式还是迭代式，都离不 开需求、设计、编码、测试这几个阶段，在迭代式开发中，这几个阶段也是周 期性出现的。怎样把握好每个阶段的质量，确实不是一件容易的事，本期重点 介绍一下需求、设计和编码阶段的成果质量，当然以后会共享一些过程质量方 面的知识。1、需求我们知道人与人的交流总是会存在一些误会，同样一句话，心情不好与心 情好的时候听起来的感觉可能会截然相反，正是因为人们之间存在着理解上的 偏差，在描述需求的

5、语言上就应该注意尽量避免歧义的产生。如果对 UML 比较 熟悉的话，需求分析可以利用 UML 工具进行，这样可以减少一些自然语言引起 的歧义，但是 UML 可能与用户沟通起来有一些障碍，因为并不是所有的用户都 了解 UML 各种图形的意思。除了工具之外，我们可以从以下几个方面来保证需 求描述的质量。1、看句子和段落是否简短，一个很长的句子，看起来会非常困难，因此无法弄懂真正的需求，另外过长的句子和段落容易让人忽视一些需求，所以如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。2、句子是否有 语法错误，还要注意标点符号，有时，标点符号点错了，就完全成了另外一个 意思了。 3、是否存在模

6、糊不清的需求，出现类似于可能，大概，或者等词汇表 述的需求。 4、另外注意引用的术语和词汇是否前后一致。 5、是否存在一些形 容词、比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、新的，界面友好的，减少、扩大，不小于等等，需要将描述性词 语进行量化，并且给出具体值或者范围，要不然不同的人根据不同的理解就会 得出不同的结果，终可能跟用户初的要求有偏差，那 “炒回锅肉 ”的事情就不可 避免地会发生。另外保证需求质量的一个很重要的因素就是需求是否细化，如果需求不细 化也会很容易造成代码的返工，于是就出现了我们的程序员尽管总是加班加点 却总是不能如期的完成任务的情景。那么我们

7、怎样才能判断需求细化的程度 呢？需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进 行细化了呢？哪些需求又太粗了呢？答案是需求是否可以写出相应的测试用 例，如果写不出来，就说明需求还不是很细，还需要再进行细化。2、设计软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的 软件产品在开发伊始到产品发布会涉及到方方面面的角色，例如：用户、项目 管理人员、程序员、测试员、维护人员等等。不同的角色对架构设计的要求也 不相同。例如用户关心的是需求，因此我们的设计对需求的覆盖率是多少？对 于程序员来说模块是否清晰，类的功能是否单一等等，对于测试人员来说系统 的是系统的可测试性。对

8、于维护人员来讲系统的扩展性、可维护性如何？一个 高质量的软件架构，应该限度的考虑并满足不同角色的不同要求。正是因为有 这些要求，我们在进行软件设计的时候，应该进行全面的考虑。一般用来衡量 软件设计质量的标准可以从以下几个方面来考虑：1）、功能性：包括完全性、正确性、安全性、兼容性、互用性。完全性包 括功能点覆盖率，重点功能点覆盖率，优先功能覆盖率。正确性包括需求一致 度。安全性根据软件需求的不同有不同的安全性要求。来源于2）、效率：包括产品运行的时间效率和利用的硬件资源两方面来考虑。3）、维护性：包括架构的可改正性，可扩充性以及可测试性。如果用户的一个很小的需求变更会引起架构设计很大的变化，那

9、么这样的架构设计的可改 正性和可扩充性就比较差。4）、可移植性：包括硬件的独立性、软件独立性、可安装性、可重用性。软件设计是否模块化、每个模块的可复用性如何都是应该考虑的因素。5）、可靠性：包括缺陷数量、容错性、可用性。6）、使用性：包括可理解性、易学习性、可操作性、易沟通性。我们软件的终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对 软件的接纳程度。因此在软件的可使用性也是非常重要的。3、编码代码质量的一个很重要的标准就是代码的可读性及规范性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和维护， 同时出错的几率也会更高。如果一个方法内部的代码很长

10、，而且使用了很多令 人难以理解的数据集，这样就会带来代码维护的困难，因为很少有人能够有效 地分析它们，因此也就是容易出现缺陷和错误的地方。类之间的耦合度会造成 类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变 化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，每一个导入类发生变化都会影响到该类本身，另外如果该类的 public 方法太多也会 导致类之间的高耦合性增加。也许有的程序员会认为写出可读、规范的代码会影响工作进度。的确，对 于程序员个体短时间来说为代码写上注释是要花费些时间，但如今软件开发是 多人协作周期很长的过程，写过程序的人都知道，如果自己写了不规范的代码，随 着自己所写的代码越来越多，到后来需要修改某个前期写的模块时都不知道自 己当初是怎么想的了，读自己的代码也