软件开发各阶段的质量管理

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

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

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

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

5、如对uml比较熟识的话，需求分析可以利用uml工具进行，这样可以削减一些自然语言引起的歧义，但是uml可能与用户沟通起来有一些障碍，因为并不是全部的用户都了解 uml各种图形的意思。除了工具之外，我们可以从以下几个方面来保证需求描述的质量。 1、看句子和段落是否简短，一个很长的句子，看起来会特别困难，因此无法弄懂真正的需求，另外过长的句子和段落简单让人忽视一些需求，所以假如一个句子不能完全描述清晰需求，应当将其拆分成多个小句子。2、句子是否有语法错误，还要留意标点符号，有时，标点符号点错了，就完全成了另外一个意思了。 3、是否存在模糊不清的需求，出现类似于可能，也许，或者等词汇表述的需求。4、

6、另外留意引用的术语和词汇是否前后全都。5、是否存在一些形容词、比较性词语，比如：简单的、快速的、便利的、有效的、很多、很少、简洁、复杂、最新的，界面友好的，削减、扩大，不小于等等，需要将描述性词语进行量化，并且给出详细值或者范围，要不然不同的人依据不同的理解就会得出不同的结果，最终可能跟用户最初的要求有偏差，那“炒回锅肉”的事情就不可避免地会发生。 另外保证需求质量的一个很重要的因素就是需求是否细化，假如需求不细化也会很简单造成代码的返工，于是就出现了我们的程序员尽管总是加班加点却总是不能如期的完成任务的情景。那么我们怎样才能推断需求细化的程度呢?需求细化程度的确很难把握，什么样的需求可以算是

7、比较细了，不用再进行细化了呢?哪些需求又太粗了呢?答案是需求是否可以写出相应的测试用例，假如写不出来，就说明需求还不是很细，还需要再进行细化。 2、设计 软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色，例如：用户、项目管理人员、程序员、测试员、维护人员等等。不同的角色对架构设计的要求也不相同。例如用户关心的是需求，因此我们的设计对需求的掩盖率是多少?对于程序员来说模块是否清楚，类的功能是否单一等等，对于测试人员来说系统的是系统的可测试性。对于维护人员来讲系统的扩展性、可维护性如何?一个高质量的软件架构，应当最大限度的考虑并满意

8、不同角色的不同要求。正是因为有这些要求，我们在进行软件设计的时候，应当进行全面的考虑。一般用来衡量软件设计质量的标准可以从以下几个方面来考虑： 1)、功能性：包括完全性、正确性、安全性、兼容性、互用性。完全性包括功能点掩盖率，重点功能点掩盖率，优先功能掩盖率。正确性包括需求全都度。安全性依据软件需求的不同有不同的安全性要求。 2)、效率：包括产品运行的时间效率和利用的硬件资源两方面来考虑。 3)、维护性：包括架构的可改正性，可扩充性以及可测试性。假如用户的一个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性就比较差。 4)、可移植性：包括硬件的独立性、软件独立性、

9、可安装性、可重用性。软件设计是否模块化、每个模块的可复用性如何都是应当考虑的因素。 5)、牢靠性：包括缺陷数量、容错性、可用性。 6)、使用性：包括可理解性、易学习性、可操作性、易沟通性。我们软件的最终目的是让用户来使用的，假如易用性不好，可操作性不好都会影响用户对软件的接纳程度。因此在软件的可使用性也是特别重要的。 3、编码 代码质量的一个很重要的标准就是代码的可读性及规范性，可读性不一定是简洁的代码，而是简单理解的代码，因为过于复杂的代码难以测试和维护，同时出错的几率也会更高。假如一个方法内部的代码很长，而且使用了许多令人难以理解的数据集，这样就会带来代码维护的困难，因为很少有人能够有效地

10、分析它们，因此也就是最简单出现缺陷和错误的地方。类之间的耦合度会造成类与类之间的相互关联，当一个类发生转变时会使其他的类发生意想不到的变化，一般从导入类的个数推断类之间的耦合度，假如导入类的个数许多，每一个导入类发生变化都会影响到该类本身，另外假如该类的public方法太多也会导致类之间的高耦合性增加。项目经理圈子 或许有的程序员会认为写出可读、规范的代码会影响工作进度。的确，对于程序员个体短时间来说为代码写上注释是要花费些时间，但如今软件开发是多人协作 周期很长的过程，写过程序的人都知道，假如自己写了不规范的代码，随着自己所写的代码越来越多，到后来需要修改某个前期写的模块时都不知道自己当时是怎么想的了，读自己的代码也需要花很长时间才读懂。况且假如随着人员的调动等其他原因，往往维护代码的程序员已不是当时写代码的人，许多状况就是读懂了一段糟糕的代码还比重新写出一段代码花费的