软件项目管理-质量先行

 

软件项目管理-质量先行

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

怎样摆脱这样的困境呢？为何软件开发项目管理这么困难呢？为何我们做的计划总是不能按时完成呢？为何软件开发不能像硬件开发那样可以控制呢？原因在于软件开发完全靠人的大脑思维产生出产品，而每个人的大脑思维是不一样的，因此在软件开发过程中有太多不确定的、可以变化的因素，我们怎样把握住这些变化因素呢？就像我们题目所说的一样，软件项目管理-质量先行，如果我们能够很好的控制软件生命周期每一个阶段的质量，也就很好的控制了整个软件开发的整个过程。

    软件产品的质量是个很大的概念，因为软件产品完全是人们大脑思维的产物，就是将大脑里无形的看不见摸不着的思维变成一个可以看到的，可以解决实际问题的一组界面或者组件。这样的一个复杂的过程，质量应该如何保证呢？有人想到了ISO9000,CMM,也有人很反对，说应该用敏捷开发。其实，不管用什么样的开发过程，关键是找到这些过程的真谛，有些人说，ISO和CMM到中国来就变了味了，为什么变味儿了呢？其实我们只学到了怎样去做，但是不知道为什么要这样做？大家都知道在产品立项之前要写市场分析报告，为什么要写，市场分析报告的重要性有多高？没有资深开发经验的人员可能很难理解其重要性，如果只是简单的形式上去写一篇这样的文档，那么除了负担之外就没有其他用途了。很多人又想到了测试，觉得是我们测试的力度不够，所以我们产品质量不过关，其实，软件开发的质量保证从开发最初就应该开始了，如果到了测试阶段才重视就已经晚了。软件产品开发过程，不管采用瀑布式还是迭代式，都离不开需求、设计、编码、测试这几个阶段，在迭代式开发中，这几个阶段也是周期性出现的。怎样把握好每个阶段的质量，确实不是一件容易的事，对于软件产品的测试，不管是单元测试还是集成、系统测试，这方面的介绍已经很多了，因此我们重点介绍一下需求、设计和编码阶段的质量保证。好了，就让我们开始一次质量之旅吧，我们的第一站就是需求分析。

在需求分析过程中，如何进行质量保证呢？我们平时可能更多的关注于需求本身，却忽视了一个很重要的因素，那就是市场。因为我们开发出来的产品是直接面向市场的，如果我们费了很多的人力物力开发出来一个没有市场前景，缺乏竞争力的产品，那么我们所有的努力都是白费。如何充分考虑市场因素，具体可以从以下几个方面进行。1、判断需求是否符合愿景目标，所谓愿景目标就是我们开发出来的产品能够给我们的用户带来什么样的好处？如果有些需求没有被包含在愿景目标里，那么这样的需求其实就背离了我们开发产品的初衷。2、判断产品需求能够给企业带来多大的利润，如果某个需求只是代表个别用户的需求，并不能给企业带来较大的利润，但是又花费我们很多的人力物力，那么这样的需求就可以考虑进行删除。3、核心需求与竞争对手相比核心竞争力有哪些？如果核心竞争力不够或者没有就应该考虑重新进行需求分析，因为如果没有核心竞争力开发出来的产品就不会有市场。

在排除了市场因素产生的风险之后，我们应该保证需求描述的质量。我们知道人与人的交流总是会存在一些误会，同样一句话，心情不好与心情好的时候听起来的感觉可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上就应该注意尽量避免歧义的产生。如果对UML比较熟悉的话，需求分析可以利用UML工具进行，这样可以减少一些自然语言引起的歧义，但是UML可能与用户沟通起来有一些障碍，因为并不是所有的用户都了解UML各种图形的意思。除了工具之外，我们可以从以下几个方面来保证需求描述的质量。1、看句子和段落是否简短，一个很长的句子，看起来会非常困难，因此无法弄懂真正的需求，另外过长的句子和段落容易让人忽视一些需求，所以如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。2、句子是否有语法错误，还要注意标点符号，有时，标点符号点错了，就完全成了另外一个意思了。3、是否存在模糊不清的需求，出现类似于可能，大概，或者等词汇表述的需求。4、另外注意引用的术语和词汇是否前后一致。5、是否存在一些形容词、比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的，界面友好的，减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围。

另外保证需求质量的一个很重要的因素就是需求是否细化，如果需求不细化很容易造成代码的返工，于是就出现了我们的程序员尽管总是加班加点却总是不能如期的完成任务的情景。那么我们怎样才能判断需求细化的程度呢？需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢？哪些需求又太粗了呢？答案是需求是否可以写出相应的测试用例，如果写不出来，就说明需求还不是很细，还需要再进行细化。

把握住了需求分析这一关，下一站我们就可以进行设计了。软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色，例如：用户、项目管理人员、程序员、测试员、维护人员等等。不同的角色对架构设计的要求也不相同。例如用户关心的是需求，因此我们的设计对需求的覆盖率是多少？对于程序员来说模块是否清晰，类的功能是否单一等等，对于测试人员来说系统的是系统的可测试性。对于维护人员来讲系统的扩展性、可维护性如何？一个高质量的软件架构，应该最大限度的考虑并满足不同角色的不同要求。正是因为有这些要求，我们在进行软件设计的时候，应该进行全面的考虑。一般用来衡量软件设计质量的标准可以从以下几个方面来考虑：

1、        功能性：包括完全性、正确性、安全性、兼容性、互用性。完全性包括功能点覆盖率，重点功能点覆盖率，优先功能覆盖率。正确性包括需求一致度。安全性根据软件需求的不同有不同的安全性要求。

2、        效率：包括产品运行的时间效率和利用的硬件资源两方面来考虑。

3、        维护性：包括架构的可改正性，可扩充性以及可测试性。如果用户的一个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性就比较差。

4、        可移植性：包括硬件的独立性、软件独立性、可安装性、可重用性。软件设计是否模块化、每个模块的可复用性如何都是应该考虑的因素。

5、        可靠性：包括无缺陷性、容错性、可用性。

6、        使用性：包括可理解性、易学习性、可操作性、易沟通性。我们软件的最终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对软件的接纳程度。因此在软件的可使用性也是非常重要的。

完成了设计之后，接下来就要进行编码了。在编码阶段，我们应该怎样保证我们的编码质量呢？两个比较有效的方法就是代码走查和单元测试。

代码走查可以以组为单位进行，代码走查可以发现例如是否符合代码规范，是否存在拼写错误，代码是否具有可读性，类和方法是否过于冗长，类之间是否存在高耦合性。代码质量的一个很重要的标准就是代码的可读性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和维护，同时出错的几率也会更高。如果一个方法内部的代码很长，而且使用了很多令人难以理解的数据集，这样就会带来代码维护的困难，因为很少有人能够有效地分析它们，因此也就是最容易出现缺陷和错误的地方。类之间的耦合度会造成类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，每一个导入类发生变化都会影响到该类本身，另外如果该类的public方法太多也会导致类之间的高耦合性增加。

编码阶段另一个非常重要的手段就是单元测试。单元测试是一个模块的功能及常规错误测试，单元测试是由程序员进行的，一般单元测试能够捕获80%的bug。  因此单元测试对保证代码质量方面占有很重要的地位，由于这方面内容比较多，我们这里就不做具体阐述了。

好了，经过了这样一次质量履行，我们对软件开发是否增加了很多信心呢？当然软件项目管理还有很多其他的因素，但是如果每个阶段都能够很好的控制质量，就会在产品开发初期减少很多风险，从而使我们的软件开发在一个可以控制的范围内进行，这样我们才能够避免我们太多的没有必要的人力物力的浪费，从而使我们的产品更快更好的投入市场。