摘要：在整个软件工程的过程中，并不全是康庄大道，也非充满崎岖，那么是什么让软件工程如此难以控制呢？那是因为软件工程中有两大鸿沟将整个软件工程过程划分为三个部分，并且目前这两大鸿沟上面似乎没有一座象样的桥梁。需求和设计之间存在着一大鸿沟，而另一条存在于设计与编码之间。本文将探讨这两条鸿沟产生的原因以及如何跨越的方法。
关键字：需求；设计；编码；软件工程
引言
软件开发到底是更像工程还是更像艺术一直是业界争论的焦点问题，不管这个问题的结论如何，它都反映了人们实现软件开发的工程化的愿望。但是在这个工程化过程中却被若干问题困扰着，以至于人们产生了软件开发本身就是一种艺术创作，无法用工程化的方法对其进行管理的想法。
软件开发真的不能工程化吗？软件工程真的不能摆脱“艺术创作”的阴影吗？首先让我们来分析软件工程和其他工程发展的差异。
软件工程与建筑工程之对比
《营造法式》可以说是中国版的建筑工程“设计模式”，而人类关于建筑工程的实践则可以追溯到数千年前。古埃及的金字塔，古巴比伦的空中花园，中国的万里长城都是古代的巨型建筑工程的代表。金字塔、空中花园、万里长城绝对是人类历史上最璀璨的结晶，但是他们都是成功的项目吗？我想这个问题谁也不能回答，因为没有一个标准来衡量这些伟大的项目是否是成功的。这些项目在建造的时候是否有投资控制，是否有进度要求，是否有质量目标，这些我们都不得而知。因此，虽然这些都是伟大的建筑，但是我们不能说他们就是建筑工程的成功实践。
有大量的数据表明能够同时满足质量、成本、进度要求的软件项目，即成功的软件项目是少之又少，那么是不是所有的成功的建筑工程项目就是完全满足了质量、成本、进度的要求呢？这个问题我们不得而知。
建筑工程相比软件工程来说，其投资预算的准确性要比软件工程高的多，而质量有标准可以衡量，并且那个标准还是相当的宽松。在进度方面，软件工程不能采用建筑工程中使用的那种增加施工人员和机械台班的方法来使进度按比例加快。种种原因足以让软件工程有充分的理由来让他的成功率低于建筑工程。但是这不是将软件工程的较低成功率归结于“软件是艺术创作”的理由。
另外建筑工程之所以能够获得广泛认可的原因关键在于两样东西：建筑模型（表现图）和施工图纸。这两样东西的存在将最终用户、设计单位和施工单位彻底的划分开来。建筑模型（表现图）联系着用户和设计院，是他们的共同语言，设计院用建筑模型（表现图）来描述并确认用户的需求。施工图纸则能够指导具体施工，虽然它没有规定施工的过程和采用的技术，但是它确定了施工的结果，施工单位根据施工图纸进行施工就能够建造出符合设计的建筑。这两种技术清晰、无二义的表达了双方的意图，这就是建筑工程成功的诀窍。
在软件工程中，软件企业目前只需要和客户打交道，设计和编码并没有分开由不同的企业来实施（软件编码外包除外）。那么这第一条鸿沟就出现在用户和软件企业中间的需求理解和如何由需求导出设计中。遗憾的是软件工程中的需求确认不能像建筑工程中那样将建筑用笔画出来，软件是无法用艺术家的笔来描绘的。
关于软件需求的获取与确认一直是软件工程中的大问题，但是随着UML中用例图的引入而使得需求获取技术得到了长足的进步，用例技术让需求分析简单并且真实，客户也比较容易接受这种图文并茂的方式，解释一堆“小人”的工作让整个需求工程充满了乐趣。
UML很好的解决了需求工程中需求获取和确认的问题，但是却没有给出如何将需求转换成设计的方法，序列图和活动图都不足以正确的将需求转换成软件模型，在这个中间我们缺少一种方法让需求转换成软件设计。
软件的设计和编码不进行分离是产生“软件开发是艺术”、“编码是艺术”的论点的根本原因。设计本来就是一种艺术创作，服装设计是艺术，建筑设计是艺术，软件设计同样也是艺术。但请不要将设计和开发混为一谈，开发描述的实现过程，即编码过程，而设计在软件工程中最具代表性的是软件架构设计。
在设计和实现存在于同一个企业的同一个项目组的时候，确实很难将设计和实现分开，所以也就无法将工程和艺术分离了。做架构设计的设计师在编码的过程中，需要不断的进行编码的指导工作，甚至参与到编码过程。在编码的过程中，回过头去修改架构设计，这样设计与实现就彻底的混杂在一起，使得管理变得困难。试想一下，谁能够对艺术创作进行工程化的管理呢？
将艺术创作性的工作剔除除去，将设计与实施分离是任何行业工程化的基础。
鸿沟存在的原因
这两条鸿沟就如同长江和黄河将我国划分为华北、华中和华南一样将软件开发划分为需求、设计与实现三个阶段。如果能够架起这三个阶段鸿沟上的桥梁，我们就完全能够真正的贯彻软件工程的思想。但是这样的两座桥梁为什么迟迟没有出现呢？[本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
您的位置：
