软件工程设计师企图让软件设计文档像建筑物的设计图纸和说明一样，可以清晰描述软件的每一个具体的细节规格。其实这是一个可笑的悖论。如果文档有能力描述每个功能的最细节业务逻辑的需求的话，其实就是源代码（因为自然语言存在二义性，因此不存在描述严密逻辑的可能。而唯一能精确描述业务逻辑需求的就是源代码，所以描述精确的业务需求的过程其实就是写代码）。
而建筑设计师的源代码就是 标准设计严密的图纸，这个图纸是逻辑精确严密的，可以交给任何一个正规施工队来正确执行的，设计师和施工队可以不需要任何交流。同样， 程序员写的代码也是逻辑精确严密的，可以交给任何一台电脑来正确执行的，程序员和电脑也不需要开会谈话。
你能想象一个不会画标准建筑设计图纸的建筑设计师吗？同样，我也完全无法想象一个不会写代码的 软件设计师。
所以，建筑设计师在软件开发中就是程序员，而建筑施工队在软件开发中就是计算机。
企图将程序员当做施工队来进行管理是不适合的，传统行业中对设计师的管理可能更加值得软件企业的学习。
话说回来，软件工程学也发展了好多年，难道完全是错误的吗？没有一点应用价值吗？我的经验告诉我，存在必然是合理的。软件工程也有他的适用范围，但是我们要加以分析才能利用，首先要看对我们自己是否合适。
我认为软件工程的确对某些项目是适合的，但是项目要满足以下四个特点：
◆ 软件的规格目标是非常清晰确定的，开发过程中几乎不会发生更改的。
◆ 实施过程中采用的所有技术都是非常熟悉的。
◆ 对稳定性的需求大大超过开发效率的。
◆ 可以不考虑成本的。
有没有这样的项目？有，航天飞机的自动控制系统软件就是满足这样要求的工程。事实上，软件工程诞生的背景也正是美国军方的一些大型项目。写软件工程的一些大师级人物也正是这些项目的领导人。
我们是不考虑事物的变化，采用刻舟求剑的方式来蒙蔽自己的双眼？还是仔细考察自己的特点，变通的选择真正适合自己的东西？
文章来源于领测软件测试网 https://www.ltesting.net/
