软件项目管理的质量管理

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

2、是不能按时完成？为何开发不能像硬件开发那样可以控制？开发是完全依靠人的大脑思维产生出产品，而每个人的大脑思维是不一样的，因此在住这些变化开发过程中有太多不确定、可变化的。那么呢？怎样把握项目管理质量先行，如果能够控制生命周期每一个阶段的质量，就能很好地控制了开发的整个过程。产品的质量是个很大的概念，因为产品完全是人们大脑思维的产物，是将大脑里无形的思维变成可以解决实际问题的一组界面或者组件。在这样一个复杂的过程中，应该如何保证质量呢？有人想到了 ISO9000、CMM，也有人提出意见，认为应该用敏捷开发。其实，不管用什么样的开发过程，关键是找到这些过程的本质。有人说，ISO 和 CMM 到中国

3、来怎么就变了味了？其实，只学到了怎样去做，但是不知道为什么要这样做。大家都知道在产品立项之前要写市场分析，但不了解为什么要写，市场分析的重要性有多高？不是资深开发很难理解其重要性，如果是简单地去写一篇形式上的文档，那么，除了负担之外就没有了。有些人又想到了测试，觉得是测试的力度不够，所以产品质量不过关。 其实，开发的质量保证从最初就应该开始了，如果到了测试阶段才重视就已经晚了。产品开发过程，不管采用瀑布式模型还是迭代式模型，都离不开需求、设计、编码、测试这几个阶段。在迭代式开发中，这几个阶段也是周期性出现的。怎样把握好每个阶段的质量，确实不是一件容易的事。对于产品的测试，不管是单元测试还是集成

4、、系统测试，这方面的介绍已经很多了，因此笔者重点介绍一下需求、设计和编码阶段的质量保证。让开始一次质量之旅吧，第一站就是需求分析。在需求分析过程中，如何进行质量保证呢？平时可能地关注需求本身，却忽视了一个很重要的，那就是市场。因为开发出来的产品是直接面向市场的，如果费了很多的人力物力开发出来一个没有市场前景，缺乏竞争力的产品，那么所有的努力都是白费。如何充分考虑市场个方面进行。，具体可以从以下几首先，判断需求是否符合愿景目标，所谓愿景目标就是开发出来的产品能够给的用户带来什么样的好处？如果有些需求没有被包含在愿景目标里，那么这样的需求其实就背离了开发产品的初衷。其次，判断产品需求能够给企业带来

5、多大的利润，如果某个需求只是代表个别用户的需求，并不能给企业带来较大的利润，但又花费甚高，就可以考虑删除。最后，与竞争对手相比竞争力有哪些？如果竞争力不够，就应该考虑重新进行需求分析，因为如果没有核心竞争力，开发出来的产品就没有市场。在排除了市场产生的风险之后，应该保证需求描述的质量。人与人的交流总会存在一些误会，同样一句话，心情不好与心情好的时候听起来可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上就应该注意尽量避免歧义的产生。如果对 UML 比较熟悉的话，需求分析可以利用 UML工具进行，这样可以减少一些自然语言引起的歧义，但是并不是所有的用户都了解 UML 各种图形

6、的意思，与用户沟通起来存在以下几个方面来保证需求描述的质量。，除了工具之外，可以从首先，看句子和段落是否简短。长句子看起来会非常，很难弄懂真正的需求：另外，过长的句子和段落容易让人忽视一些需求。所以，如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。其次，句子是否有语法错误，还要注意标点符号，有时，标点符号点错了就完全成了另外一个意思。再次，是否存在模糊不清的需求，出现“可能，大概，或者”等词汇表述。最后，注意是否存在形容词及比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、的、界面友好的、减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范

7、围。另外，保证需求质量的一个很重要的就是需求是否细化，如果需求不细化就很容易造成代码的返工，出现程序员尽管加班加点却总是不能如期完成任务的情景。怎样才能判断需求细化的程度呢？需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢？是：是否可以将需求写出相应的测试用例，如果写不出来，就说明需求还不是很细，还需要进一步进行细化。把握住了需求分析这一关，下一站就可以进行设计了。架构设计在产品开发周期中占有很重要的位置开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色。例如：用户、项目管理、程序员、测试员、等等。不同的角色对架构设计的要求也不相同。对于程序员来说更关注模块

8、是否清晰，类的功能是否单一等等，对于测试系统的扩展性、可一个高质量的来说，关注的是系统的可测试性。对于性如何？来讲，架构，应该最大限度的考虑并满足不同角色的不同要求。因此在进行设计的时候，应该进行全面的考虑。一般用来衡量设计质量的标准可以从以下几个方面来考虑：功能性效率包括完全性、正确性、安全性、兼容性、互用性。产品运行的时间效率和利用的硬件资源两方面。包括架构的可改正性，可扩充性以及可测试性。如果用户的一性个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性就比较差。可移植性包括硬件的独立性、独立性、可安装性、可重用性。软件设计是否模块化、可复用性都是应该考虑的。

9、可靠性使用性包括无缺陷性、容错性、可用性。包括可理解性、易学习性、可操作性、易沟通性。的最终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对软件的接纳程度。因此的可用性也是非常重要的。完成了设计之后，接下来就要进行编码了。在编码阶段，应该怎样保证的编码质量呢？两个比较有效的方法就是代码走查和单元测试。代码走查可以以组为进行，代码走查可以发现代码是否符合代码规范，是否存在拼写错误，是否具有可读性，类和方法是否过于冗长，类之间是否存在高耦合性。 代码质量的一个很重要的标准就是代码的可读性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和出错的几率也会更高。

10、，同时如果一个方法的代码很长，而且使用了很多令人难以理解的数据集，就，因为很少有人能够有效地分析它们，因此也就最容易出会带来代码的现缺陷和错误。类之间的耦合度会造成类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，或者该类的 public 方法太多都会导致类之间的高耦合性增加。单元测试是一个模块的功能及常规错误测试，单元测试是由程序员进行的，一般单元测试能够捕获 80%的 bug。因此单元测试对保证代码质量方面占有很重要的地位，由于这方面内容比较多，好了，经过了这样一次质量旅行，这里就不做具体阐述了。对开发是否增

11、加了很多信心呢？当然项目管理还有很多其他的，但是如果每个阶段都能够很好的控制质量，就会在产品开发初期减少很多风险，从而使的开发在一个可以控制的范围内进行，这样才能够避免过多的没有必要的人力物力的浪费，从而使的产品更快更好的投入市场。测试认识的几个误区随着规模的不断扩大，设计的复杂程度不断提高，开发中出现错误或缺陷的机会越来越多。同时，市场对质量重要性的认识逐渐增强。所以，测试在项目实施过程中的重要性日益突出。但是，现实情况是，与测试的地位和作用，还没有真正受到重视，对于很多人（甚编程比较，至是项目组的技术）还存在对测试的认识误区，这进一步影响了软件测试活动的开展和真正提高测试质量。误区之一：开

12、发完成后进行测试人们一般认为，项目要经过以下几个阶段：需求分析，概要设计，详细设计，编码，测试，发布。据此，认为测试只是编码后的一个过程。这是不了解测试周期的错误认识测试是一个系列过程活动，包括测试需求分析，测试计划设计，测试用例设计，执试。因此，测试贯穿于项目的整个生命过程。在项目的每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正确性。测试的对象不仅仅是测试应该是交互进行的，代码，还包括需求文档和设计文档开发与例如，单元编码需要单元测试，模块组合阶段需要集成测试。如果等到编码结束后才进试，那么，测试的时间将会很短，测试的覆盖面将很不全面，测试的效果也将大打折扣。更严重的是如果此

13、时发现了需求阶段或概要设计阶段的错误，如果要修复该类错误，将会耗费大量的时间和人力。误区之二：发布后如果发现质量问题，那是测试的错这种认识很打击测试的积极性中的错误可能来自项目中的各个过程，测试只能确认存在错误，不能保证没有错误，因为从根本上讲，测试不可能发现全部的错误。从开发的角度看，的高质量不是测试测出来的，是靠生命周期的各个过程中设计出来的。出现错误，不能简单地归结为某一个人的责任，有些错误的产生可能不是技术原因，可能来自于的项目管理。应该项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。误区之三： 很多人都认为这是由于不了解测试要求不高，随便找个人多都行测试就是安装和运行程

14、序，点点鼠标，按按键盘的工作。测试的具体技术和方法造成的。随之工程学的发展和软件项目管理经验的提高，测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。测试技术不断更新和完善，新工具，新流程，新测试设计方法都在不断更新，需要掌握和学习很多测试知识。所以，具有编程经验的程序员不一定是一名优秀的测试工程师测试包括测试技术和管理两个方面，完全掌握这两个方面的内容，需要很多测试实践经验和不断学习精神。误区之四：测试是测试的事情，与程序员无关开发和测试是相辅相成的过程，需要测试、程序员和系统分析师等保持密切的联系，需要的交流和协调，以便提高测试效率。另外，对于单元测试主要应该由程序员完成，必要时测试可以帮助设计测试样例。对于测试中发现的错误，很多需要程序员通过修改编码才能修复。程序员可以通过有目的的错误的类型、数量，找出产生错误的位置和原因，以便在今后的编程中避免同样的错误，积累编程经验，提高编程能力。误区之五：项目进度吃紧时少做