如何保证软件质量 --2002年系统分析员考试下午试题二
摘要：
软件质量是软件的生命。保证软件质量除了技术上过硬以外，还需要一个良性的管理环境。软件过程作为软件开发的管理环境对软件质量起着决定性的作用，一个成功的软件过程应该具备以下几个特性：
1、 软件过程是有效的，能够确定并解决软件开发中的不确定因素
2、 软件过程中的所有资源都是可以控制的，不会出现依赖某种资源，如依赖某个开发员，或依赖某台计算机等。
3、软件过程是可预测和可跟踪的，能够知道软件开发所处于的状态以及可能存在的缺陷。
4、软件过程是可以扩展、可调整的；知道缺陷后，能够对软件过程进行修改。
5、软件过程应该是个管理的过程，每个小组的成员都是管理的主体，他们的行为直接影响到产品的质量，充分调动和激发小组成员的能量对提高软件质量有积极的作用。
本文就上述几个方面结合自己的经验谈谈如何来保证软件质量。
正文
随着计算机软件开发技术的发展和演变，软件开发经历了从简单开发到大规模的软件开发。可以肯定的是，不论软件开发如何演变，软件质量始终是软件的核心竞争力。
目前，我们国家的软件开发也正在朝大规模软件开发的模式前进，很多国外的先进经验对我们管理软件开发有很强的指导作用。下面我打算结合自己五年的开发经验从软件过程、风险管理、团队组织来谈谈我对保证软件质量的看法和做法。
软件过程。
从几年的开发经历来看，传统的瀑布开发已经不适合现在的小团队（<10人）的开发，快速开发工具RAD的出现以及辅助设计工具的使用，加上软件规模的日益扩大，我们更需要的像RUP这样的迭代式的开发过程，对各种问题的快速的应变能力成为一个软件开发组织成熟的标志。
首先我们要认识到像RUP这样完整的软件过程对一个小团队的实施是不切实际的，所以就有必要对标准的RUP开发过程进行裁减，使得其符合自身开发的特点，所以说一个开发过程是否有效就是看能不能解决实际问题。
去年，我参与了一个不是很成功的项目，项目进度严重超期，开发员信心全无，大家互相推卸责任，对问题也是机械式的反应。总结后发现，项目不成功的很大一个原因没有一个符合自身特点的开发过程，在问题出现后没有任何预先制定的制度来协调，所以定义好一个符合自身特点的软件开发过程是保证软件质量的基础。
根据RUP的经验，我们把软件开发分成和RUP一样的四个阶段：初始化、精化、构建、部署四个阶段。由于我们是初试使用RUP开发过程，同时根据我们小组的特点我们把软件开发的目标定位在基本满足CMM 2的关键过程域（KPA），达到一些CMM 3的关键过程域上。我们制定了需求分析、变更与配置管理，项目管理，分析设计、测试等几个关键过程，通过对这些关键过程的定义来控制整个软件开发的活动。
需求分析关键活动是完成收集和定义软件开发需要的资源。根据开发项目性质的不同，需求分析的重点有所不同，比如对于数据库为主的项目我们就把重点放在项目的业务逻辑上，主要分析和比较业务逻辑之间的差别和实现，如简单的进销存项目，而对于与系统结合的比较紧密的项目，就把需求分析的重点放在接口的实现上及与平台相关的特性上，如网络数据包分析项目。实践证明注意到项目之间的差别对我们开展项目计划和制定项目计划都有重要的意义。
变更和配置管理关键活动定义了当出现需求需要变更时采取的对策。我们采取的策略是：当需求出现变更的时候，所有成员都进行交流确定这个变更对项目进度的影响，然后综合考虑后确定是否要进行变更，一旦确定了对策，任何成员都必须无条件的执行，由于团队规模较小，这一活动相对容易实现。
项目管理关键活动主要是定义项目开发所需要的环境以及如何协调成员之间的进度。这个关键活动的实施我们是主要集中在版本控制上，利用现在流行的版本控制工具，如CVS，VSS都可以有效的管理和协调小团队的开发。
分析设计和测试这两个关键活动我们主要采用几个原则。第一，分析和设计适当分开。做分析的不能全去做做设计的，在设计中有不做分析的人才可能发现分析的缺陷，分析的鉴定应该由所有成员统一来执行。第二，设计和测试适当分开，开发员并不是很乐意去做繁杂的测试工作，而且开发员的测试思路都比较狭窄。第三，设计和文档编写员适当分开。设计员应该将精力放在设计上，可提供简单的样稿，具体的文档编写应该交与专人。实践证明，上述原则的应用是成功的。
除了上述的几个重要关键活动以外，RUP软件过程还定义了其他更为细的关键活动，在这里就不详细叙述了。
风险管理
风险是最容易影响软件进度的因素，在开发项目的过程中往往由于某种突发事件而影响到整个开发进度。就我所经历的项目来看，项目大概可以分为为企业定制软件和通用的商业软件两类，而为企业定制软件的项目占多数。
不难看除，为企业定制软件的风险除了技术风险以外，商业风险等其他风险几乎没有，所以对于这类项目，我们就要把精力放在技术上，主要是预先判断采用的技术方案对项目的成功是否有推动作用，比如用VB去开发与操作系统结合得很紧密的项目就不太合适。除了这样的问题以外，当突发事件到来时，我们要严格按照定义好的流程去处理，切不可随意行事或按主观意思行事，当没有流程与之定义，应该征求成员的意见然后定义出一个大家都接受的流程,这样增加开发员的主人翁意识也是有帮助的。对于通用的商业软件，除了技术上的风险以外，商业风险也是很重要的，密切注意竞争对手的状态和市场对该项目的容纳程度也是项目成功的关键，由于实践不够，体会也不是很多。
团队组织
小组的每个成员都是开发项目的主体，他们的行为直接影响到软件质量。一个成功的软件必然是有一个好的团队，所以开发项目时要充分尊重和调动团队的每个成员。
长久以来，我们都采用的是树型式管理(图1)。一个项目经理管着几个程序员，由项目经理分配任务，程序员按时完成任务，这个模式对项目经理的要求很高，项目成功的风险都由项目经理承担，成员的主动性也不够，一旦项目经理离开，整个项目就陷入瘫痪状态。这种模式比较适合于一个项目参加的都是新手，这些新手在项目经理的指导下完成任务。
比这种模式更为民主的模式是互相平等模式(图2)。在这种模式中，成员彼此之间互相平等，共同商讨问题，可以充分发挥出每个成员的主动性，但这种模式的问题在于当问题出现后容易耽误时间。要避免这种现象对成员的要求比较高，大家不要互相推卸责任，也不要互相扯皮，所以这种模式比较适合于小组成员具备较高的素质和技能。
结合这种模式就产生了第三种模式：混合管理(图3)。这种模式对于高级别的成员采用平等模式，对于新手采用树型式管理。
在几年的开发过程中，受到管理学的影响，我们采用了一种驱动式的管理模式(图4)。在这个模式中，项目经理不是直接管理其他成员的活动，而是类似于教练的角色在旁边不断的指导和纠正他们的行为，整个实际活动还是由成员自己完成。这种模式可以有效的分担项目经理的压力，可以把项目经理从以往的转注于项目实现转移到管理的角色上来，项目经理根据成员的能力和特点不同，分配他们不同的角色，明确他们的责任，指导他们的行为，而项目经理注重管理，这种模式类似于足球队管理，在足球队中，教练不会自己上场，而是在场边确定中场、前锋、后卫之间的关系，把自己的战术贯彻下去，实际的操作还是有队员自己完成。
经过实践比较，我认为对于一个刚成立的团队第一种模式是比较合适的，当成员的意识和能力提高后，就要加大他们的参与性，采用第二种模式或第三种模式，当成员成熟后，采用第四中模式能够有效的提高成员的参与意识和责任意识，所以说软件开发中的每个成员都是管理的主体，只有成员的能力提高了，软件的质量也就有保证。
综上所述，软件过程的定义，风险的处理策略，团队的组织对软件质量的影响是最大的，在处理好这些问题之后，我们的软件质量有了大幅度的提高，而且我相信这些问题的解决是大规模软件开发的基石之一，也是软件组织成熟的标志之一。
--2003-1-14 完— 图1 图2 图3图4 字数统:计：摘要：346 正文：2780 简介：
本文地址：http://com.8s8s.com/it/it35238.htm