四十年软件工程故事

四十年软件工程故事2008年5月14~16日，在德国迷人的小镇Garmisch，举办了软件工程四十年纪念会议，PeterNaur、BrianRandell、M.DouglasMcIlroy、AlbertEndres、LuigiDadda等40年前软件工程会议的关键人物重聚旧地。40年前的1968年，正是在此地举行的NATO（北约）科技委员会会议上，“软件工程”作为正式的术语被确定下来，标志着一个新学科的开始。PeterNaur和BrianRandell主编的会议报告中这样写道：“我们特意选择‘软件工程’这个颇具争议性的词，是为了暗示这样一种意见：软件的生产有必要建立在某些理论基础和实践指导之上——在工程学的某些成效卓著的分支中，这些理论基础和实践指导早已成为了一种传统。”软件工程这个学科还很年轻，PeterNaur和BrianRandell今天依然健在。作为著名的编程语言归约BNF范式中的N，PeterNaur因设计和定义了ALGOL60而在2005年获得图灵奖。因IBMSystem360的工作于1999年获得图灵奖的FredBrooks在《人月神话》的结尾比较了化学工程和软件工程。他认为：软件系统可能是人类所创造的最错综复杂的事物，软件工程还很年轻，需要继续探索和尝试。这四十年的过程就是探索和尝试的过程，让我们来细细品味其中的科学精神之美。软件工程是什么软件工程的定义有很多版本，比较权威的是IEEE给出的定义：（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即，将工程应用于软件。（2）在（1）中所述方法的研究。所以，软件工程远没有想象中那么高大神秘，它研究的就是我们日常开发软件的工作方式。“程序员”这三个字本就属于软件工程的范围。关于软件工程和计算机科学的区别，FredBrooks说：Ascientistbuildsinordertolearn;anengineerlearnsinordertobuild.更详细的可以看看DavidParnas的“SoftwareEngineeringProgramsAreNotComputerSciencePrograms”和SteveMcConnell所著“ProfessionalSoftwareDevelopment”的第4章。或者对照一下图灵奖获得者：软件工程领域的DavidParnas、FrederickP.Brooks和计算机科学领域的DonaldE.Knuth、《程序员》上期介绍的YAO。软件是为人开发的，软件是由人开发的。正是因为人的心理难以捉摸，人的大脑处理复杂性时速度和容量的局限，我们才需要过程来规范人的行为，需要方法来帮助人脑面对复杂性，需要工具来贯彻这些过程和方法。所以，软件工程的知识体系分为以下几层。我们按照这个金字塔结构，逐层回顾四十年来的历史。过程一开始，软件团队是没有过程的，甚至没有团队概念。没有需求规格说明，没有设计，程序员在大脑中直接将代码思考出来，拼凑到一起，交给客户使用。客户如果有要求，再修改代码，如此反复。这种“编码－修改”做法对于小程序可以应付，当程序规模变得复杂时，付出的代价就很大了。瀑布“软件工程”概念的提出，促进了需求、分析、设计、实现、维护等软件生命周期概念的成熟。瀑布模型是最早的软件过程模型，从名字“瀑布”可以看出，通常人们认为瀑布模型中的各个步骤是一条线完成的。实际上在WinstonW.Royce1970年的经典论文“ManagingtheDevelopmentofLargeSoftwareSystems”中有反馈的过程（见图3），作者本人也并不提倡以顺序模型作为团队的过程模型，另外，Royce并没有在论文中把他的过程模型叫做“瀑布”，只是后来其他人这么叫了。很多团队使用时是按照线性的方式使用的，这是一种误解。这里要提一下，瀑布模型的提出者WinstonW.Royce（已于1995年去世）有时被简写为W.Royce，所以经常会引起误会，把他当成WalkerRoyce，后者是软件项目管理专家，曾任Rational软件公司副总裁，著有《SoftwareProjectManagement:AUnifiedFramework》一书。增量和迭代使用瀑布模型，可以运行的产品很迟才能看到，这就潜伏了巨大的风险：很可能，集成之日也就是爆炸之日。为了提早获得可以运行的版本，可以先实现一些功能，再实现一些功能……每个增量交付一个可以运行的版本。增量开发显著降低了风险，而且还因可运行产品的出现大大提升了士气。最有名的实践应该是Microsoft在1989年就开始使用的DailyBuild（每日构建）,被称为项目的“心跳”。当然，增量开发不一定意味着每日构建，如FredBrooks所述，BellNorthernResearch是“每周构建”。增量经常和迭代连在一起说，不过两者是有区别的。增量是逐块建造的概念，迭代是反复求精的概念。二者不一定要绑在一起使用，但很明显，结合这两种方式是一种有效的做法。现在很多过程所说的迭代开发，默认的意思就是增量&迭代。JeffPatton最近用两幅图表达了增量和迭代（）。统一过程1987年，IvarJacobson离开Eric-sson，成立了ObjectiveSystems公司。他吸纳了增量迭代的思想，开发出Objectory过程，并且把过程当软件卖，价格卖到25000美元一份，以至于IvarJacobson不想在Addison-Wesley等出版社出书公开他的方法，因为卖一本书才得到3美元。1991年，Ericsson收购了该公司，并更名为ObjectoryAB（北欧出大师，所以我们常在软件开发的书籍和文章中看到××AB等文字，AB是瑞典语Altiebolag的缩写，意思是“公司”），IvarJacobson又回到了Ericsson。1995年，Rational从Ericsson收购了Objectory，IvarJacobson开始和GradyBooch、JamesRumbaugh一起开发UML。PhilippeKruchten则负责把Objectory过程和Rational公司多年的积累RationalApproach融合在一起，开发出了“RationalUnifiedProcess”以及4+1视图模型。RUP的中心思想是：用例驱动、架构为中心、迭代和增量。虽然是一个商业产品，但详尽的内容和灵活的组织，使得RUP成为软件团队中流传最广的软件过程模型，也成为团队学习软件工程和实施过程改进的重要资料。IvarJacobson在IBM收购后离开了Rational。2005年，他发布了EssentialUnifiedProcess（EssUP）将之描述为“超轻和超敏捷的”RUP，并且提出了过程定义（PD）和过程（P）的观点，他认为统一过程是一个过程定义（PD），不是过程（P），团队不能看着别人的P好，就想着拿来就用，必须要找到自己的点。2007年，IvarJacobson的新观点是“过程够了，实践吧（EnoughofProcesses:Let'sDoPractices）”。DougRosenberg和KendallScott的ICONIX过程借鉴了IvarJacobson和统一过程的思想，而且以其小巧易懂，受到不少开发人员的欢迎。敏捷运动敏捷运动在20世纪90年代中期兴起，当时敏捷过程被称为“轻量”过程。2001年，KentBeck、AlistairCockburn、WardCunningham、MartinFowler、JimHighsmith、RonJeffries、JonKern、RobertC.Martin、SteveMellor、KenSchwaber等人聚集在犹他州的Snowbird，决定把“敏捷”作为新的过程家族的名称，并提出以下宣言：随后，敏捷联盟成立，这是一个致力于传播敏捷过程的非营利组织。敏捷联盟每年召开敏捷大会，今年已经是第6年。关于敏捷过程，比较全面的介绍文章是MartinFowler的“TheNewMethodology”。每隔一段时间，Fowler会随着形势的变化更新此文。该文2005年12月版本列出的各种流行敏捷过程包括：极限编程（XP）、Scrum、Crystal、上下文驱动测试（ContextDrivenTesting）、精益开发（LeanDevelopment）、统一过程（UnifiedProcess）。极限编程（XP）是敏捷过程的代表。1996年，KentBeck为了挽救ChryslerComprehensiveCompensation（C3）项目而创建了XP过程，虽然Chrysler最终取消了该项目，但是RonJeffries和WardCunningham等人参与到了XP的工作中。1999年，KentBeck出版了“ExtremeProgrammingExplained:EmbraceChange”一书。XP一代相当于程序员的宣言，受到了程序员的热烈欢迎。2004年，该书第2版出版，KentBeck说自己几乎完全重写了整本书，书中关于程序员是宇宙中心的内容少了很多，更多的是谈程序员和编程工作必须处于业务环境中，他们需要成为正常商业世界中的一部分。过程评估和CMM从1968年开始，WattsS.Humphrey是IBM负责软件部门的副总裁。1986年，WattsS.Humphrey离开IBM后，加入了SEI（卡内基?梅隆大学软件工程研究所），开始开发CMM（CapabilityMaturityModel，能力成熟度模型）。CMM一开始的目的是为军方制定一个好用的评估承包商的标准，因为SEI本来就是军方资助的机构。1989年，在《ManagingtheSoft-wareProcess》一书中，Humphrey描述了CMM。CMM可以看作是一个软件过程元模型，定义软件组织达到一定能力成熟度所需的关键过程域（KPA）。20世纪90年代中期，CMM开始在世界范围内流传开来，成为一些政府采纳的评估软件组织的标准，政府甚至对通过评估的软件组织加以资助。在这种激励下，想获得政府订单或者政府资助的软件组织纷纷力争通过CMM评估。目前，通过CMM/CMMI评估的组织数量前三位国家是：美国、印度和中国。方法在20世纪60年代，程序员随意地编写代码。虽然当时已经出现了FORTRAN等高级语言，但程序员把代码写在一起，代码中使用GOTO语句来跳转，使得程序的内部结构像“意大利面”，整个程序又像一块铁板，无法单独抽取其中一部分复用。功能分解1968年，EdsgerW.Dijkstra发表《GoToStatementConsideredHarmful》，认为GOTO语句是有害的，应该把程序划分成多个子单元，每个子单元只做一件事，当重复的语句集合出现时，只需要调用相应子单元(函数)。这相当于封装和复用了共同的行为。数据流当软件的规模不断变大，大到不能一下子映射到代码级别时，就需要更大颗粒的分析设计方法。20世纪70年代，数据流法出现了，有三种流行的流派：DeMarco方法（1978）、Gane/Sarsen方法（1979）以及Yourdon/Constantine方法（1979）。数据流法把系统看作数据的加工机，数据流进去，经过加工，变成新的数据流出来。从最顶层开始（因为此时系统看作是一个整体，所以表达的就是功能需求），一层一层向下求精，一直求精到泡泡所代表的加工成为可以编码的动作。实体/关系20世纪70年代末，关系数据库开始变得流行。PeterChen（陈品山）在1976提出实体关系（ER）模型，用实体和关系映射现实中的事物和概念。该模型提供了数据的图形视角，并能轻松转换为关系数据库模型。分析员很快认识到，ER模型可以用来表达大型软件的数据库设计，更宏观地把握业务，而且还有助于分析员和用户交流。数据流法结合实体关系法，曾经是比较流行的开发软件的方法。这种做