程序员第四期： 《软件工程大趋势：全程建模》.docVIP

《程序员》杂志第四期 软件工程大趋势：全程建模 高 展 摘要：本文在论述了有关软件危机种种问题之后，提出了一个兼收并蓄的系统分析设计的全面解决方案——全程镜像一体化建模方法，完全覆盖软件开发的中上游阶段：业务分析、需求定义、总体设计、详细设计，彻底解决了开发文档衔接的“两层皮”问题，充分满足了软件开发商要求统一各个阶段建模方式的呼声，为实现软件开发流水线化提供全的技术支持。 一 软件危机 1 错误积累 人非完人，软件开发者也难逃例外。在需求分析、设计、编程等开发过程中，每个阶段都不可避免地产生一些错误带到下一阶段中，贻害无穷。 在需求分析阶段，用户往往会首先叙述自己的业务以及对软件的要求，这些内容常常会不系统、不完善，再加上开发商理解的偏差，在形成“需求分析报告”的就会包含错误的需求，这种错误包括误解与遗漏，随之展开的设计、编程肯定会错上加错。 在软件设计阶段，因为对需求理解的偏差，加上设计本身考虑不周，“设计报告”中往往也会有错误的设计，根据这种设计展开的编程同样会错上加错。 在软件编程阶段，因为对设计理解的偏差，加上编程本身的疏忽，“程序代码”中往往会有错误百出。 在测试阶段，总会有一些“潜伏的错误”没能发现，而能够发现的错误在交付期迫近的情况下不能修改： 某一模块修改工作量大，没有时间修改； 某一模块修改工作量虽小，但牵扯范围广，没人敢改，唯恐摁倒葫芦起了瓢，越改越乱。 这样一来很多错误眼睁睁残留在正式交付的软件中，因而软件“带病工作”的情况屡见不鲜。 2 错误放大 编程者都有这种体会，费了好几天的功夫，往往会发现祸首是一条语句、一个变量，错误早就埋伏下来，具体原因常常令人啼笑皆非。 我们都有这样的开发经验，每一个阶段都会把上一个阶段文档的要求，成倍或成数量级放大成当前阶段的文档： 1个“需求”需要10句“设计”才能展开，1句“设计”需要10条“程序”才能实现，1条“程序”需要10种“测试”组合才能让人放心。不幸的是错误同样也放大了，所以早期的低级错误，在软件开发后期往往铸成大错，对用户的危害更无从计算。 3 软件危机是开发商的生存危机 知错就改是开发商的工作原则，但修改工作给开发者带来的沉重的代价，因为前面所述的错误放大效应，越在开发后期，修改代价越大。这种代价分为三个因素，成本、质量、效率。 在成本方面，无论从总开发时间上还是从单位开发时间来看，修改代价都体现为增加人、财、物的投入，软件公司的利润日益摊薄，甚至亏本。 在质量方面，修改软件很少会推倒重来，而往往会像对待破损的衣物一样来打补丁，经常是由于好心的修改而引入了令人憎恶的新错误，摁倒葫芦起了瓢，软件一片狼籍。 在效率方面，如果不增加开发人员，势必导致绝对开发时间的增加，这样实际开发效率比预期的要降低；如果增加开发人员，一方面新人要熟悉相关工作，另一方面，开发小组超过5个人时，人与人之间交流的时间要大大增加，单位时间的开发效率往往会降低。 在上述原因决定下，软件开发特别是管理软件的开发常常成为“胡子工程”，实际工期一拖再拖，所谓成熟的用户总结出一条规律：开发拖延50%的是优秀开发商，而超过预定工期1倍的是合格的开发商。 就本质而论，软件危机是开发商的全面危机：信誉危机、竞争危机、生存危机。 二 传统软件工程问题重重 软件危机的严重性呼唤软件开发应当按工程化方式组织管理，“软件工程”应运而生，它提供了软件开发的技术手段（包括分析方法、设计方法、编程方法、测试方法）和管理手段（包括项目式管理、专业式管理、矩阵式管理）。技术手段体现了对模块化的追求，管理手段体现了工业社会的分工协作原则。形象地来说，管理手段体现为文章的标题大纲，技术手段体现为文章的段落内容。 传统的软件工程远远没有达到人们的期望值。究其原因，传统的系统分析设计方法（或称建模方法）首当其中，这与软件工程学者推崇的错误观念密切相关，而听命于软件工程大师的开发者是无辜的。 1 错误观念之一：软件是创造出来的 软件不是凭空臆造出来的，以管理软件为例，其运行模式必须100%吻合用户的管理模式，具体表现为软件的流程要符合用户的业务流程，软件接收、产生的数据要100%符合相应的业务单据与报表，软件的运行结构要100%符合企业的组织结构，否则任何所谓先进的管理软件都难有用武之地。 同样，对于系统软件（如操作系统、网络协议）来说，软件的结构体现了有关原理组成部分的包容关系，软件的流程体现了这些组成部分的交互过程，而软件的数据体现了进行这些交互过程产生的具体信息。 建模(Modeling)这个词用来表达软件系统分析十分形象，也很容易操作：在软件世界中建立现实世界的模型。这是一个建立镜像的过程。 完全应该给软件下一个极端的定义：软件是赝品，软件是某种原理的赝品，也可以说是e化的原理。开发软件就是照葫芦画