软件开发各阶段的质量管理
提到软件开发，我们的脑海里总是浮现出这样的情景：开发组的每一位成员都在辛苦的工作，有的加班加点，甚至通宵达旦是常有的事，虽然项目经理修改了一次又一次的进度计划，而实际的开发情况却总是很令人担忧，以至于每次向领导汇报工作的时候总是觉得以前制定的计划没有很好的完成，总是觉得人力资源不够，总是觉得我们没有太多的时间。等到代码终于开发完成了，测试进度却又非常令人担忧，每一个小BUG都要花很长的时间去查找，改了某一个小错误却又引起了很多错误，结果产品发布无期，而项目组里的每一位成员已经筋疲力尽。
怎样摆脱这样的困境呢?为何软件开发项目管理这么困难呢?为何我们做的计划总是不能按时完成呢?为何软件开发不能像硬件开发那样可以控制呢?原因在于软件开发完全靠人的大脑思维产生出产品，而每个人的大脑思维是不一样的，因此在软件开发过程中有太多不确定的、可以变化的因素，我们怎样把握住这些变化因素呢?像我们题目所说的一样，软件开各阶段的成果质量管理，如果我们能够很好的控制软件生命周期每一个阶段的质量，也很好的控制了整个软件开发的整个过程。
软件产品的质量是个很大的概念，因为软件产品完全是人们大脑思维的产物，是将大脑里无形的看不见摸不着的思维变成一个可以看到的，可以解决实际问题的一组界面或者组件。这样的一个复杂的过程，质量应该如何保证呢?有人想到了ISO9000、CMM，也有人很反对，说应该用敏捷开发。其实，不管用什么样的开发过程，关键是找到这些过程的真谛，有些人说，ISO和CMM到中国来变了味了，为什么变味儿了呢?其实我们只学到了该做什么，却不知道怎样去做，为什么要这样做?大家都知道做软件开发需要写需求规格说明书和设计文档，为什么要写，文档的重要性有多高?没有开发和管理经验的人员可能很难理解其重要性，如果只是简单的形式上去写一篇这样的文档，对后面的编码和测试没有实际的指导作用，甚至起了“ 误导”作用，同样会引起大量返工，那么这些文档除了负担之外没有其他用途了，要知道写这些文档是需要消耗项目组资源的(进度、成本...)。
很多人又想到了测试，觉得是我们测试的力度不够，所以我们产品质量不过关，其实，软件开发的质量保证从开发初应该开始了，如果到了测试阶段才重视已经晚了。软件产品开发过程，不管采用瀑布式还是迭代式，都离不开需求、设计、编码、测试这几个阶段，在迭代式开发中，这几个阶段也是周期性出现的。怎样把握好每个阶段的质量，确实不是一件容易的事，本期重点介绍一下需求、设计和编码阶段的成果质量，当然以后会共享一些过程质量方面的知识。
1、需求
我们知道人与人的交流总是会存在一些误会，同样一句话，心情不好与心情好的时候听起来的感觉可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上应该注意尽量避免歧义的产生。如果对UML比较熟悉的话，需求分析可以利用UML工具进行，这样可以减少一些自然语言引起的歧义，但是UML可能与用户沟通起来有一些障碍，因为并不是所有的用户都了解 UML各种图形的意思。除了工具之外，我们可以从以下几个方面来保证需求描述的质量。
1、看句子和段落是否简短，一个很长的句子，看起来会非常困难，因此无法弄懂真正的需求，另外过长的句子和段落容易让人忽视一些需求，所以如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。2、句子是否有语法错误，还要注意标点符号，有时，标点符号点错了，完全成了另外一个意思了。 3、是否存在模糊不清的需求，出现类似于可能，大概，或者等词汇表述的需求。4、另外注意引用的术语和词汇是否前后一致。5、是否存在一些形容词、比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、新的，界面友好的，减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围，要不然不同的人根据不同的理解会得出不同的结果，终可能跟用户初的要求有偏差，那“炒回锅肉”的事情不可避免地会发生。
另外保证需求质量的一个很重要的因素是需求是否细化，如果需求不细化也会很容易造成代码的返工，于是出现了我们的程序员尽管总是加班加点却总是不能如期的完成任务的情景。那么我们怎样才能判断需求细化的程度呢?需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢?哪些需求又太粗了呢?答案是需求是否可以写出相应的测试用例，如果写不出来，说明需求还不是很细，还需要再进行细化。
