软件质量的原则

原则1质量第一无论如何定义质量客户都不会容忍低质量的产品。质量必须被量化并建立可落地实施的机制以促进和激励质量目标的达成。即使质量没达到要求也要按时交付产品这似乎是政治正确的行为但这是短视的。从中长期来看这样做是“自杀”。质量必须被放在首位没有可商量的余地。Edward Yourdon建议当你被要求加快测试、忽视剩余的少量bug、在设计或需求达成一致前就开始编码时要直接说“不”。原则2 质量在每个人眼中都不同软件质量没有唯一的定义。对开发者来说质量可能是优雅的设计或优雅的代码。对在紧张环境中工作的客户来说质量可能是响应时间或高吞吐量。对成本敏感的项目来说质量可能是低开发成本。对一些客户来说质量可能是满足他们所有已知和未知的需求。这里的难题是以上要求可能无法完全兼顾。当优化某人关注的质量时可能会影响其他人关注的质量这就是温伯格的“政治困境”原则。项目必须确定各因素的优先级并清晰地传达给所有相关方。原则3 开发效率和质量密不可分与质量之间存在明显的关系开发效率可以用人月完成的代码行数或功能点数来度量。对质量要求越高开发效率就越低。对质量要求越低开发效率就越高。越是强调提高开发效率最终的质量就越低。贝尔实验室发现在要求每千行代码有12个bug时人月的效率通常为150300行代码[参见FleckensteinW.Challenges in Software Development尽管我们的行业中有一些表现不佳、包含bug或者根本无法满足客户需求的软件系统的例子但仍然有一些成功的例子。大型软件系统可以以非常高的质量构建但价格昂贵每行代码高达1000美元。例如IBM为美国宇航局的航天飞机开发的机载飞行软件总共约300万行代码源于严谨的软件开发过程产品发布后每万行代码中发现的错误少于一个。 作为软件开发人员应该学习和了解已被验证、可以极大提高软件质量的方法。这些方法包括让客户参与见原则8、原型设计在全面开发之前验证需求见原则1113、 保持设计简单见原则67、审查代码见原则98和雇用最优秀的人见原则130和131。作为客户在追求卓越的同时要意识到随之而来的高额成本。