谈软件质量属性——软件性能的可伸缩性

软件或多或少的承载着人们这样那样的需求，如何去衡量软件的质量属性应该是软件人员一直都在思考的内容。McCall质量属性模型将软件的质量属性划分为产品修正、产品运行、产品转移三个部分，其实更简单的划分，可以将其分为 开发态质量属性 与 运行态质量属性。

 

1、正确性是软件质量的基础，但仅能够满足正确的代码，不过是程序世界中的一堆垃圾

 

克劳士比说过：“质量是一组特性满足要求的程度”，满足“客户要求”、即正确性是所有软件质量的基础。但是，往往并不是所有的要求都是明确的。没有客户有耐心详细的提出有哪些质量要求，往往只是提出“需要什么样的功能”，至于怎么实现，用什么实现从来是不关心的。所以，一个仅能满足正确性的软件/代码只不过是计算机世界中的一堆垃圾。

 

2、开发态质量属性

 

开发态质量属性狭义上可以理解为“代码的质量”，如可读性，代码不仅是写给计算机运行的，更多的时候是写给人看的。写一份不需要说明文档的代码，让所有维护的人能够轻松的看懂就是成功。此外如可扩展性，随需求的变更代码的改动情况，这里面设计模式的东西可以派上一些用场，Design For Change的思想也由此而来。再如可移植性，写了一份代码，32位机器上可以跑，到64位机器上就出问题，或者在Linux上可以执行，到Unix上就需要大刀阔斧的改动，这样或多或少都是有些问题的。其它如可测性，这里不写了。

 

3、运行态质量属性

 

运行态质量属性指在程序运行期间的“满足要求”的表现，常见的如：

性能：12306的购票系统就是典型的反面教材，在需要的时候顶不上，影响性能的如IO、数据库、内存操作使用是否恰当；

可靠性：程序是否容易出问题，出问题能否及时恢复；

兼容性：这个对于做平台或中间件层的软硬件要求尤为突出，没有用户愿意为底层的升级买单。不兼容的直接恶果是客户不愿意升级，最终导致版本无法收编，产生巨大的维护成本；

可维护性：出了问题能否快速定位，快速分析，还是人海战术，全部成为救火队员。

 

4、软件性能的可伸缩性

 

运行态的质量属性除了这些还有很多，如易用性、易升级等。这里再提到的两点质量属性：一个是软件性能的可伸缩性，其中一层含义可以理解为软件随外部压力增大所表现的性能表现，如100W用户在线时，系统的响应时长是1秒钟，1000W用户在线的时候，系统的响应时长是否是简单的1*10秒钟？另外一层含义，可以理解成软件性能随硬件的扩充所产生的性能变化情况。举例而言：在CPU是1G Hz的机器上，系统每秒钟可以处理1000个请求，如果CPU升级到2G Hz的处理速度，是否每秒钟就可以处理2*1000=2000个请求？现实情况下，这个伸缩性一定不是线性关系的，在前一层含义里面，可能还会出现拐点，也就是所谓的“雪崩”。

 

另外一个值得一提的应该是软件的开放与易集成，当前像微信、微博，都在构筑自己的软件平台，生态系统，如何能够打造一个开放的平台，当前也是一个思考和尝试的途径。

上面这些更多的是一些通用的质量属性，质量属性之间可能相互有矛盾的地方，产品实现时更多的是方方面面的平衡。也可以理解为：产品的质量属性决定了软件的架构。

另外，对于不同的产品而言，其关注的质量属性可能是不一样的，如电信产品更关注的可能是可靠性，而互联网产品可能更侧重于体验和快速响应。对于同一产品而言，不同时期关注的质量属性也可能随需求的变更发生或多或少的变化。