软件质量是什么

众所周知软件质量是软件产品之本，但软件质量到底是什么？我们真正地理解了软件质量吗？一说到软件质量，在头脑中很容易想到它应当满足用户的需求、用起来方便以及含有尽可能少的缺陷（bug或defect），等等。如果一个产品已经开发出来了，那缺陷尽可能的少这一指标就显得尤为突出，因此，潜移默化地，缺陷少成为了高质量软件的代名词。

缺陷少真的就意味着是高质量软件吗？笔者认为不然！这是因为软件质量的高低从不同的层面去考察，其评估标准是不一样的。站在软件用户的角度来看，缺陷越是少说明质量越是高，这应当是合理的，后面我们称这种高质量标准为用户级的高质量。但是，站在开发团队的角度，高质量的软件应当不仅仅只意味着缺陷少，而是还有其它内容。试想，如果一个软件的缺陷的确少，但是开发团队为了实现这一目标却要花费并不相称的超额努力，这种软件能称之为高质量吗？

什么又是超额努力呢？从项目团队不同职能人员的角度来看，其结果可能大为不同。或许，有的项目相关人员认为只要在计划时间内完成了开发工作就不存在超额努力，至于是否存在大量的加班加点那也无所谓。软件开发是否存在超额努力，参与其中的一线开发工程师最了解！如果开发人员为了在计划时间内加班加点，或者开发工作做得心力憔悴，或者感觉工作再继续进行下去产品质量在未来也不乐观，那这些可能都表明开发团队正在付出超额努力。由此看来，软件的质量不能片面的从软件用户的角度去看，而应当深入到从开发团队的角度去理解，这种高质量标准称之为开发团队级的高质量。真正高质量的软件不能只满足缺陷少这样单一的条件，更应当包含开发团队能保持良好士气且从容地从事软件开发工作以及维持团队个体正常的生活质量。显然开发团队级的高质量涵盖了用户级的高质量，且提出了更高的要求。开发团队级的高质量更可能从长远的角度保证用户级的高质量，否则，用户级的高质量有可能只是昙花一现。我们的风险管理是否考虑过如何从长远保证用户级的高质量呢？如果要考虑，必须考虑做到开发团队级的高质量，否则只能是空谈。

由此看来，在软件行业可能存在一种误解，即将缺陷少是高质量软件的必要条件当成了是高质量软件的充分必要条件。另外，业内的不少质量管理体系是从缺陷数量这个角度出发的，而从这里的分析来看，其存在一定的片面性。因为，这种管理方式并没有切中“高质量”的要害，没有将开发团队的健康成长作为其考察质量的因素之一。那要做到开发团队级的高质量，技术方面的关键又是什么？软件设计质量！（什么是软件设计请参见《什么是软件设计》一文）

那如何保证设计质量呢？这很容易让人想到开发流程和认证，比如敏捷软件开发、CMMI认证等等，其实认证的本质还是流程。但是，设计质量是不能简单地通过流程而获得的，因为流程所控制的是看得见的东西，而软件设计过程很多是发生在人的大脑当中的。要保证设计质量人是关键，这种人明白什么是软件设计以及拥有自己的设计思想并付之于项目实践。还有，掌握软件设计比理解业务需求更加的难，开发团队很少因为理解不了业务需求而无法开发产品，可是因为不理解软件设计从而身受其苦却并不少见。

软件设计能力很抽象，但不能因为抽象就不重视它，软件开发团队应当以培养和打造自己的核心设计骨干作为自己的重要内容之一。由于具备软件设计能力的工程师是稀缺资源，不能指望项目组中的每一个人都是真正的设计者，也就是说软件开发工程师并不等同于软件设计师（或者说软件开发不等同于软件设计），这一点我们必须清楚地认识到。软件开发团队的组织结构形式应当如《人月神话》中所提出的，采用与“外科手术式队伍”相类似的组织形式。在外科手术中，操刀的人只能是主刀医生一个人，而不是手术室中的每个人，其它的人都是主刀医生的助手。采用类似于外科手术式的队伍组织软件开发，有助于保持软件的一致性，更加容易体现思想性。另一个例子是，假如十个人在一起吃饭，如果每个人都点一个菜，则更难达到荤素搭配这一要求，要做到也需要花费更多的沟通成本。相反，如果是由一个人点菜，则更容易做到这一点，当然这里的假设是这个点菜的人具备点菜应当荤素搭配这一思想。在外科手术式的开发队伍中，“主刀医生”可以征求他人的意见，但是最终还是由“主刀医生”决定如何“下刀”。另外，与真正的外科手术不同的是，在软件项目中“主刀医生”并不是真正地只能有一个，而可能是由二、三个人组成的“主刀医生”小组。