软件开发为何不能像硬件开发那样可控？软件质量之旅将带给我们一些启示。
提到软件产品开发，我们的脑海里总是浮现出这样的情景：开发组的每一位成员都在辛苦地工作，加班加点，甚至通宵达旦。虽然项目经理一次又一次地修改了进度计划，而实际的开发情况却总是令人担忧，以至于每次向领导汇报工作的时候，总是觉得以前制定的计划没有很好完成，总是觉得人力资源不够，总是觉得没有太多的时间。等到代码终于开发完成了，测试进度同样非常令人担忧，每一个小BUG都要花很长的时间去查找，改了某一个小错误却又引起了很多新的错误，结果产品发布无期，而项目组里的每一位成员已经筋疲力尽。
怎样摆脱这样的困境？为何软件开发项目管理这么困难？为何我们做的计划总是不能按时完成？为何软件开发不能像硬件开发那样可以控制？
软件开发是完全依靠人的大脑思维产生出产品，而每个人的大脑思维是不一样的，因此在软件开发过程中有太多不确定、可变化的因素。那么我们怎样把握住这些变化因素呢？
软件项目管理——质量先行，如果我们能够控制软件生命周期每一个阶段的质量，能很好地控制了软件开发的整个过程。
软件产品的质量是个很大的概念，因为软件产品完全是人们大脑思维的产物，是将大脑里无形的思维变成可以解决实际问题的一组界面或者组件。在这样一个复杂的过程中，应该如何保证质量呢？有人想到了ISO9000、CMM，也有人提出反对意见，认为应该用敏捷开发。其实，不管用什么样的开发过程，关键是找到这些过程的本质。
有人说，ISO和CMM到中国来怎么变了味了？其实，我们只学到了怎样去做，但是不知道为什么要这样做。大家都知道在产品立项之前要写市场分析报告，但不了解为什么要写，市场分析报告的重要性有多高？不是开发人员很难理解其重要性，如果是简单地去写一篇形式上的文档，那么，除了负担之外没有其它用途了。
有些人又想到了测试，觉得是我们测试的力度不够，所以产品质量不过关。
其实，软件开发的质量保证从初应该开始了，如果到了测试阶段才重视已经晚了。软件产品开发过程，不管采用瀑布式模型还是迭代式模型，都离不开需求、设计、编码、测试这几个阶段。在迭代式开发中，这几个阶段也是周期性出现的。
怎样把握好每个阶段的质量，确实不是一件容易的事。对于软件产品的测试，不管是单元测试还是集成、系统测试，这方面的介绍已经很多了，因此笔者重点介绍一下需求、设计和编码阶段的质量保证。
让我们开始一次质量之旅吧，第一站是需求分析。
在需求分析过程中，如何进行质量保证呢？我们平时可能更多地关注需求本身，却忽视了一个很重要的因素，那是市场。因为我们开发出来的产品是直接面向市场的，如果费了很多的人力物力开发出来一个没有市场前景，缺乏竞争力的产品，那么所有的努力都是白费。如何充分考虑市场因素，具体可以从以下几个方面进行。
首先，判断需求是否符合愿景目标，所谓愿景目标是我们开发出来的产品能够给我们的用户带来什么样的好处？如果有些需求没有被包含在愿景目标里，那么这样的需求其实背离了我们开发产品的初衷。其次，判断产品需求能够给企业带来多大的利润，如果某个需求只是代表个别用户的需求，并不能给企业带来较大的利润，但又花费甚高，可以考虑删除。后，与竞争对手相比核心竞争力有哪些？如果核心竞争力不够，应该考虑重新进行需求分析，因为如果没有核心竞争力，开发出来的产品没有市场。
在排除了市场因素产生的风险之后，我们应该保证需求描述的质量。人与人的交流总会存在一些误会，同样一句话，心情不好与心情好的时候听起来可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上应该注意尽量避免歧义的产生。如果对UML比较熟悉的话，需求分析可以利用UML工具进行，这样可以减少一些自然语言引起的歧义，但是并不是所有的用户都了解UML各种图形的意思，与用户沟通起来存在障碍，除了工具之外，我们可以从以下几个方面来保证需求描述的质量。
首先，看句子和段落是否简短。长句子看起来会非常困难，很难弄懂真正的需求：另外，过长的句子和段落容易让人忽视一些需求。所以，如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。
其次，句子是否有语法错误，还要注意标点符号，有时，标点符号点错了完全成了另外一个意思。再次，是否存在模糊不清的需求，出现“可能，大概，或者”等词汇表述。
后，注意是否存在形容词及比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、新的、界面友好的、减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围。
另外，保证需求质量的一个很重要的因素是需求是否细化，如果需求不细化很容易造成代码的返工，出现程序员尽管加班加点却总是不能如期完成任务的情景。怎样才能判断需求细化的程度呢？需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢？
答案是：是否可以将需求写出相应的测试用例，如果写不出来，说明需求还不是很细，还需要进一步进行细化。
把握住了需求分析这一关，下一站我们可以进行设计了。
软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色。
例如：用户、项目管理人员、程序员、测试员、维护人员等等。不同的角色对架构设计的要求也不相同。对于程序员来说更关注模块是否清晰，类的功能是否单一等等，对于测试人员来说，关注的是系统的可测试性。对于维护人员来讲，系统的扩展性、可维护性如何？
一个高质量的软件架构，应该大限度的考虑并满足不同角色的不同要求。因此我们在进行软件设计的时候，应该进行全面的考虑。一般用来衡量软件设计质量的标准可以从以下几个方面来考虑：
◆功能性
包括完全性、正确性、安全性、兼容性、互用性。
◆效率
产品运行的时间效率和利用的硬件资源两方面。
◆维护性
包括架构的可改正性，可扩充性以及可测试性。如果用户的一个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性比较差。
◆可移植性
包括硬件的独立性、软件独立性、可安装性、可重用性。软件设计是否模块化、可复用性都是应该考虑的因素。
◆可靠性
包括无缺陷性、容错性、可用性。
◆使用性
包括可理解性、易学习性、可操作性、易沟通性。我们软件的终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对软件的接纳程度。因此软件的可用性也是非常重要的。
完成了设计之后，接下来要进行编码了。在编码阶段，应该怎样保证我们的编码质量呢？两个比较有效的方法是代码走查和单元测试。
代码走查可以以组为单位进行，代码走查可以发现代码是否符合代码规范，是否存在拼写错误，是否具有可读性，类和方法是否过于冗长，类之间是否存在高耦合性。
代码质量的一个很重要的标准是代码的可读性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和维护，同时出错的几率也会更高。
如果一个方法内部的代码很长，而且使用了很多令人难以理解的数据集，会带来代码维护的困难，因为很少有人能够有效地分析它们，因此也容易出现缺陷和错误。类之间的耦合度会造成类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，或者该类的public方法太多都会导致类之间的高耦合性增加。
编码阶段另一个非常重要的手段是单元测试。单元测试是一个模块的功能及常规错误测试，单元测试是由程序员进行的，一般单元测试能够捕获80%的bug。因此单元测试对保证代码质量方面占有很重要的地位，由于这方面内容比较多，我们这里不做具体阐述了。
好了，经过了这样一次质量旅行，我们对软件开发是否增加了很多信心呢？当然软件项目管理还有很多其他的因素，但是如果每个阶段都能够很好的控制质量，会在产品开发初期减少很多风险，从而使我们的软件开发在一个可以控制的范围内进行，这样我们才能够避免过多的没有必要的人力物力的浪费，从而使我们的产品更快更好的投入市场。
