思步网

标题: 浅谈如何提高项目软件品质 [打印本页]

作者: sungubbi 时间: 2008-4-11 21:04
标题: 浅谈如何提高项目软件品质

浅谈如何提高项目软件品质

作者：清水至真

一提起软件质量管理，人们的第一反应就会想起CMMI和ISO 9001。然而经过多年的探索，这些曾经被奉为软件质量管理的圣经并未普渡众生，其对提高软件的品质似乎没有奏效，现实和理想差距很远。

本文不对CMM和ISO 9001做过多的评论。只是个人对如何提高项目软件品质谈谈自己浅薄的认识，起到抛砖引玉之效。

企业的根本目的是获取最大利润。因此一切企业活动都围绕这个目的展开。谈项目软件品质也不能离开这个商业目标，而单纯设想如何构造一个完美品质的项目。

品质管理的现状分析：
1、
企业的资源不够，忽略质量保障工作，以牺牲部分品质来获取时间、降低成本。对于项目而言时间、资源、品质总是不可得兼，项目管理者的目标也是参考项目各干系人均衡这三者。对于一个企业来讲，当一个项目合同签订下来，截至时间就确定。因此针对项目而言时间是一个常量。剩下的就是资源和品质，要提高品质就意味要投入资源。假如在无须提高品质的条件能拿下项目，多投入资源就等于利润减少（这是比较短见的认识）。因此可怜的品质总是在最低水平线处徘徊。
2、
没有一个明显的软件品质度量，投入资源不能立竿见影。软件质量属性包含很多，健壮性、可靠性、性能、安全性、可扩张性、易用性等，而影响这些因素的内在原因却是深厚的技术积累和良好的管理流程，甚至可涉及到企业文化层面，不是一朝一夕可见效。针对不同的客户对软件要求不一样，比如有些要求易用性，要求将所有的操作都可以在键盘完成，不要使用鼠标；有些要求系统的性能良好，具备良好的优化功能，承载大用户量。而这些都没有一个统一的标准来衡量，以主观为主，因此资源的投入具有风险。
3、
企业对质量管理的关注程度不高。因为单个项目的质量高低不能直接给企业到来利润来源，企业的出发点更多从功能上满足客户的需求即可，将注意力转移到销售部、项目部、研发部。没有站在长远的角度和建立良好品牌效应上分析。软件质量保障，需要投入人力资源和时间资源，加大项目短期的成本。
4、
软件质量人员缺少发展的土壤。由于社会环境和企业的认识如此，就缺少了质量人员成长的土壤。如果项目取得成功，主要功劳都归功项目经理和开发人员，质量人员被边缘化。一旦项目出现了问题，质量人员却负有不可推卸得责任。而且质量人员是对软件来“挑刺”，里外不讨好。因此有“志气”的人都不愿意干这活。企业一般也就是用测试人员来承担质量管理工作。
5、
能真正做好软件质量保证的能力要求高，合格的质量管理人员稀缺。能控制一个项目的产品质量，至少要求具备以下的基本能力：能顺利从需求规格说明书中提取软件质量的关键点；能站在客户的角度分析软件产品；能对项目管理有较好的把握，在项目流程和项目进度上进行监督；有必要的技术背景，对存在的问题给出建议；能展开测试工作和测试汇报。
如何正视品质问题分析
然而客户总是挑剔的，没有谁会因为企业质量保证不容易做好而接受一个质量恶劣的软件产品。相反，在这个一切从客户需求出发的时代，服务不好客户就意味着被淘汰。因此在软件质量方面上进行解套，对于企业发展壮大有着重要意义。中小企业软件质量保障环境如上分析，依据这个环境企业如何正确对待提高软件质量这个问题呢？
1、针对中小企业的具体发展阶段来正确看待软件质量。
中小企业在不同的发展阶段有不同的战略目标，在前期，市场业务的拓展和技术能力的积累首当其冲。正如马斯洛的需求理论一样，当企业处于温饱边缘时，它的目标就是拓展业务以及通过技术积累来更好的拓展业务。在这个阶段企业对软件的质量需求自然就是以满足功能的要求为标准。在该阶段由开发人员和测试人员共同来控制软件的产品质量。
然而当企业处于发展阶段，它所面对的竞争对手就不在是“小米加步枪”，应该是行业中有一定声誉的企业，为了建立一个良好的企业形象，加入“正规军”行列，软件的品质就不仅仅是体现在功能的层面，更多的体现在产品质量的稳定性、可靠性。可以通过采用软件设计技术，加强软件过程管理，实施软件测试等方法改进软件质量。但更重要的是对软件质量和测试的思想观念正确树立。只有把提高软件质量上升到企业战略发展的高度，才能从根本上解决问题。
2、不要盲目追求有关软件质量标准，建立适合自己企业环境的质量保证规范。“质量保证（标准）并不能保证质量，它是一个美丽的谎言”。软件质量保证的目标是为管理者提供当前软件项目进行过程与最终产品的可视性。即使过程达到既定的规范，未必就能使产品质量达到要求。重要的是人按照适合自己的可执行规范来跟踪和度量生产过程和产品。规范只有形成良好的执行效果，才是质量保障的出路，否则就是一纸空文。
3、提高软件质量要循序渐进，会涉及到流程再造，不是短期行为，不可一蹴而就。影响软件产品的质量因素众多，有客户需求，过程控制，文档规范，组织结构以及对质量控制的态度等多种因素。通过企业的实践与相关的软件质量标准结合，规范软件人员的行为。只有在各种规范都融合到人的行为中，规范才有作用。而要让人的行为发生变化，有两种途径：改变人的思想，让思想来指引行为；多次重复相同的行为。这个过程是一个系统而复杂的过程，会涉及到企业的流程改造，甚至企业文化调整，需要仿佛的磨练和重复。因此要提高软件质量不只是质量人员和测试人员的事情。与项目相关的人员，从高层到基层都要对软件质量负责。
4、软件质量不良，会给项目带来巨大的风险和潜在客户流失。
不成熟的软件产品是把测试成本交给了用户：企业往往是出于项目周期安排不当，项目周期紧，缩减专门测试的时间，或者匆匆完成编码设计就将产品交付使用了。不要因为时间紧而放弃软件质量保障工作，否则后果自然是用户觉得产品漏洞百出，项目执行过程也遥遥无期，最后，项目双方都筋疲力尽，用户觉得受骗，而企业则毁了声誉，流失潜在客户，失去竞争力，追加大量项目实施费用，可谓是“赔了夫人又折兵”。
纵上所述，软件质量的提高是一个系统而复杂的过程，需要企业根据自身的能力作出不同的软件质量策略，质量的提高需要付出代价但会给企业带来巨大的隐性价值。软件质量提高了一点面对的风险就会降低一点，这是一个不变的真理。
如何提高软件品质分析
前面从意识形态的角度分析了如何提高软件质量。下面将结合上文的分析，从行为准则、执行控制这两个层面继续阐述如何在资源不充足而又急需提高软件质量的矛盾中进行解套。
一、行为准则
1、
做好需求调研分析和分析设计（如何做好需求分析设计是另外一个主题，在此不深入）。需求分析和设计是后继工作展开的基础，没有好的基础软件质量保障就会形同虚设。从测试的角度来看，设计文档比需求规格说明书更重要。测试用例与需求规格说明书用例对应，但是用例的具体描述，逻辑处理，输入和输出在设计文档中描述的更加详细。测试的依据更多来源于设计文档。在人力不足的情况下，如果测试人员熟悉设计文档，设计文档可以直接替代测试文档使用。测试人员如果直接使用需求规格说明书或者没有测试文档进行测试，将费力不讨好，只能找出一些低级的错误，一旦系统上线再发现系统的漏洞百出，那就专门分派技术专家（一般人是不行的）给客户调整数据吧，这就是一个最简单的因果关系。
2、
为了能让测试人员减少熟悉系统需求的时间，在调研后的需求评审会议强烈要求有测试人员参加。测试人员通过评审会议应该要了解到系统的核心模块是哪些，并给项目经理提出测试时间和测试方面的建议。从整理需求规格说明书至开发工作结束之际，测试人员必须根据项目经理制定出来的整体项目计划提出《系统测试计划》，与项目成员一起编写测试用例。
3、
对在开发过程中需求变更或者设计调整，项目经理要及时将变更情况告知测试人员，或者让测试人员参加变更评审。保证测试人员头脑中的系统模型是最新、最完整的。如果测试人员拥有良好的系统信息，就可以主动测试，对质量保证非常有帮助。如果发现软件少了功能，或者多了功能，都要报告项目经理，并在测试报告中做好记录。
4、
相关人员要重视文档的书写，这是软件质量提高的前提。项目经理和开发工程师在系统设计阶段完成系统设计文档，最迟在实现阶段开始之初，给测试提交测试用例，最好让测试人员参与测试用例的编写。如果项目时间紧，至少要通过设计文档使测试人员知道用例的详细情况，目的只有一个，让测试人员充分了解系统。
5、
尽早测试，连续测试。在整个项目过程中合理安排时间，在此给出一个参考指标：需求调研、分析设计40％，开发实现20％，系统测试30％，实施10％。测试应该循序渐进，不要企图一次性干完，因此尽量将测试时间提早。
二、执行控制
1、
规划测试汇报对象，提高质量保障（测试）地位。质量人员、测试人员要对软件质量负责，当然就要有相应的权利，对软件质量的评估要有绝对的话语权。如果质量人员（或者测试人员）在前期对项目软件有一个整体而细致的了解，就可以对项目过程进行监督，或者提出建议。一旦发现项目与预期有差异情况，如进度落后，软件实现与设计有出入等，就要将情况汇报给项目部和项目经理。项目部除听取项目经理汇报之外，还应听取质量人员（第三方人员的角度）的汇报，以尽量客观的项目进展对项目作出决策。汇报流程对于质量控制起着关键性的作用。
2、
建议项目部主管人员应该在项目在现场实施之前的一个星期，听取项目经理和质量人员的项目进展汇报，如果有必要，还可以开项目进度评估会议。如果评估项目软件不合格，则要采取紧急预案，做一些补救。
3、
一个项目至少要有一个质量人员（或者测试人员），从开始需求分析至项目测试完成，全程跟踪。只有这样对项目的进度监督，质量控制才会有效。要达到这个要求，质量人员要提高自身的素质。在质量人员力量薄弱的情况下，需要项目部带领或者指派第三方人员来控制。
4、
项目经理对整个项目是最清楚的，要划分好各个阶段的工作任务和花费时间，充分考虑软件质量问题可能给项目实施带来的困难，对软件质量负有全面的责任（有关项目经理职能在此不深入探讨）。
总结
本文分析了软件企业在产品质量上的现状和应对措施。针对项目管理中的质量管理，本文涉及到只是冰山一角。企业如果要真正做好质量保证，一是改变软件质量观念；二是制定适合自己质量规范；三是执行好规范，在执行中完善规范。

参考文献：软件工程与项目管理解析，作者：林锐

prof.ji@163.com 于杭州

作者: sungubbi 时间: 2008-4-11 21:06
steplv

软件产品的质量是多方面作用的效果，某一些方面的优势并不能弥补整体的能动性。

只有全方位的协调发展，才能促发并输出高质量的产品。至于如何去做，业界有很多成熟的经验可以参考，但一定要裁剪成适合于自己穿的“衣服”！

本文作者拥有多年大型项目的管理经验，值得各位同业借鉴。支持原创！

still
一点愚见：

1.企业主追求的永远是利益，工期是短的好，这也导致了项目大多都是“赶”出来的，想要真正的走全过程，难！我想steplv也提到过满足老总的愿望，我觉得其目的之一就是要拿到更多的时间去走过程！

2.测试人员从头跟进！但现有企业有多少能做到，至少在我现在的公司，测试永远是项目收尾过程中的一个步骤，在这个时候，老板在催，同事在催，各个部门在催，测试了了草草也就那么地了！质量？质量！质量？！！！

清水至真
保持自我改变的心态，努力探索所追求的目标

对于我们大多数人改变环境是一件很难的事情，但是我们却可以不断调整自我，更好的适应这个环境，或者选择一个适合自己的环境。适应环境本人把它归纳为两种：一种积极适应，另外一种是被动适应。积极适应者会努力思考自己所处环境的问题，分析问题所在，并试图着手去解决问题。至于是否能解决好这些问题，需要涉及到很多外界因素的影响，而有些因素是不能被个人所左右的，所以我不喜欢用是否达到结果来简单衡量自己当前的所得，也不会因为自己目前达不到理想的环境状况而放弃自己所认为的事务，我更喜欢的是那些对自己所从事的、或者将要从事就是他的所追求的目标，并为此而热血沸腾的人。如果当下的环境不能满足自己的要求，阻碍了个人的追求，那我们可以选择环境。

被动适应者就是另外的情况了。被动适应者，也会发现一些问题，但是这些问题是零散的，因为缺少自己统一的思想，自然就失去了看问题的准则，也就很难知道问题的根本原因所在。虽然他们也会努力解决问题，想改变现状但终究难有所获。由此也会引发选择新环境的念头。但是要注意前面所描述的选择和这里的选择是截然不同的。另外被动者还经常表现出另外一个现状就是不时抱怨当下的环境，把自己放在问题域的最中心，一切从我出发，不会换位思考。这是很不利于自我提高的。

为什么先在此说上面这些话。原因如下：

1、当前整体软件环境还没有达到我们所期待的理想状态，“革命尚未成功，同志还需努力”。

2、感觉软件规范中的各种标准很好，就是使不上劲。因为这些标准是老外的，或者更准确的说别人的经验总结。我们在没有任何积累的情况下很难用上的。就如我们拿着哲学大师的书籍，来过生活一样。但是它给了我们希望，指引着我们如何去总结，去提高。所以面包总会有的，只要我们努力去争取。

以此来鼓励那些正在思考自己方向，为自己所追求的目标孜孜不倦的人。

以下就still上述的见解，谈谈个人的看法，相互学习

追求企业的利润最大化这是企业的根本目的，这是不可动摇的宗旨。但是如何追求最大化是有很大学问的，可以肯定的一点是并非简单将企业各个项目都利润最大化。因为利润、时间、质量三者必须要做平衡。企业为了赢得良好的口碑和增加客户的忠诚度，必须要在质量（好的质量其实可以减少很大的维护费用）上下功夫，这也是可以肯定的一点，否则眼光就太短浅了（当然除了那些排他性很强的领域）。由此可以肯定质量之路是我们正在走或者即将要走的路，根据每个人所在的企业的不同有所不同。当企业意识到质量的重要性之后，从上而下改进过程，加以控制质量。质量控制人员就会有个良好的发展土壤了。（测试人员与质量保障人员此处没有做明确的区分）

测试人员是否能从头跟尾，根据企业的操作和项目管理者的做事风格而定。这个问题我们可以这样来分析一下，首先测试人员如果能从开始就跟当然是最好，可以对业务模式、需求规格，系统设计有个很好的了解，一直到测试可以和项目成员一样熟悉即将诞生的系统。如果没有专职的人来跟，那我们目前的很多项目经理就充当这个角色。质量保障工作任务就自然落到项目经理的头上。其次，我们的测试人员可以不需要全程跟踪，在开发即将结束时，由项目经理（最熟悉项目情况的人）对测试人员详细介绍项目的各个测试用例。这样测试人员的工作就是质量保障工作的延续。根据项目类型，项目要求的不一致项目成员是很不一样的，大项目（项目复杂度高）有个质量负责人从头开始跟踪是很必要的，因为大项目的软件质量，是否到位，项目经理是难以做到有效控制的。大项目的项目经理，就工作回报，客户沟通，软件需求分析，团队工作协调基本就饱和了。根据企业的环境，此时的质量保障人员，可以是项目经理的副手，可以是与项目经理平起平坐的质量保障负责人。小项目可以由项目经理一手抓，测试人员只要按照项目经理的意思测试，软件质量即可控制，这时的测试人员从项目软件质量控制的角度来看其实是项目经理的手。所以企业不一样、项目不一样，会直接影响到测试人员地位、职能不一样。
项目型的软件，项目经理承担主要的责任，但项目经理不是具体实施质量工作的人员。项目经理肯定要亲手抓软件质量。注：这里项目经理的工作职责中包含需求分析工作和系统设计。

作者: 思步 时间: 2008-5-25 22:58
有没有那位PM对作者提到的见解有疑问的？可以探讨一下！:lol

作者: 春陶社 时间: 2013-3-11 12:00
不错支持一个了

作者: 夏有森光若流苏 时间: 2015-7-13 18:45
有空一起交流一下。

作者: 橙子女 时间: 2016-4-7 11:36
顶不错支持下

欢迎光临思步网 (http://www.step365.com/)