嵌入式系统工程师必须更聪明地工作.doc

《嵌入式系统工程师必须更聪明地工作.doc》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、嵌入式系统工程师必须更聪明地工作编译自Embedded.com  作者 Jack Ganssle　　就在不久以前，我房地产界的好朋友Kirk阅读了Tracy Kidder的《新机器的灵魂》。这本书讲述了Data General公司的工程师们如何在创纪录的时间里生产出Eclipse计算机。Kirk认为这是一本有趣的书，写得很好；但是对其中高压力的生产计划和精疲力竭的人们感到难过。他说了一句让我十分意外的话：“我无法相信Kidder所描述的这种高强度的日程安排是真的，没有人能长久地像那样工作。”　　我该怎样向一个与高科技领域没有任何联系的人解释，日程安排一直都是我们最头痛的事；在我

2、的以及几乎所有我认识的工程师的职业生涯中，我们做的每一个项目的最后期限都是反复无常并且不可能完成的？最近几年，时间线收缩得更多，以今天的标准来看，Kidder的叙述甚至可以说是过于温和的。　　我由此想到，不是身在技术行业的人对于我们如何被不可能完成的最后期限逼得发疯也许真的一无所知。我们的行业很独特吗？还有多少其他行业也有这样长期、无情的压力以使事情做得更快？经常性的、没有报酬的加班是否也是其他经济部门的主题？　　较完善的项目管理软件于20世纪80年代出现。任何人都可以输入复杂的PERT（计划评审法）和甘特（Gantt）图。谁能成功地运用这些？我见过无数的开发人员试图围绕由市场

3、设定的最后期限去建立时间表，他们希望这个时间安排具有可信度，但心里完全清楚是不可能的。我上中学的时候，耶稣会的教士们总在周五下午寄来成绩单，我们会从邮箱抽出成绩单，等到周一再重新塞回去，这样周末就不会被毁掉。这只是个孩子气的小花招，来推迟不可避免的事情；而这正是工程师们所做的。　　项目进度规划软件被宣传为原始手工工具的进步。现在，我们能更快速地制造错误数据。这就是计算机的美妙之处：以前需要几秒钟，甚至几分钟去犯一个错误，现在一秒钟内就可以产生几千个错误。　　人们写软件已超过50年之久，开发嵌入式系统也有30年了。这段时间里不变的是：日程计划紧缩下的性能提升。　　我们尝试处理3件

4、相互冲突的事：不可能完成的日程、过多的预期功能、质量。如果去掉3条腿中的1条，这个项目就会失去价值。我们能够在出货时还存留很多bug吗？如果答案是“是”，那么按时交付将会非常容易。我们能忽视出货时间吗？如果拥有无限的时间，我们就能完善每项功能。　　这纠结的3者从一开始就成为隐患，而开发人员和管理人员却无法认识到矛盾所掩盖的事实。老板无一例外地想要所有的3条腿：按时交付、完美的质量、无穷的功能。但他不可能得到所有。　　合乎逻辑的想法是，我们必须强调功能，因为日程计划和质量问题总是没有商量余地的。利用需求淘汰法来识别并去除那些实际上并不需要的功能。用条理化的方式建立系统，这样即使落

5、后于计划，仍然可以拿出能良好完成大多数重要功能的产品。　　当然，还有其他因素影响开发环境：资源。合用的工具、足够多的优秀开发人员、开明的管理团队，这些构成了我们要完成项目所需的基础架构。　　20世纪里我们学习如何建立嵌入式系统，但管理上却一直没有搞清楚资源在所开发项目中的恰当位置。工程项目通常被看作如同是在生产线上制造小玩意。需要更多产品吗？那就加入更多的人和更多的机器。但是这在软件工程领域根本行不通。　　Fred Books在他的《人月神化》（注：“人月”指一月人工）一书中展示了一个现象：给一个已经滞后的软件项目增加人员，这总会致使其更加滞后。两个开发人员之间只有单一的通信渠

6、道，但当增加工程师时，备忘/会议/电子邮件的链接数量将随人数的平方增长。　　IBM发现，当项目的规模扩大，软件生产率由于同样的原因会明显下降。他们的调查显示代码产量（行/天）随着项目的扩大以数量级降低。　　Barry Boehm的建设性成本模型是最著名的软件规划预测模型，它也显示时间线比固件大小增长得快得多。将代码行数乘以2，则交付时间的增加将远远超过一倍。有时会更多。　　然而，当一个项目出现麻烦时，“再雇些人回来”似乎是普遍应用的管理格言。但就是不起作用。　　难道没有希望了么？我们的项目注定要失败？这种在《新机器的灵魂》中贴切描述的压力是否就是我们的命运？　　随着项目复杂度迅

7、速增长，很明显，除非我们投身一种全新的开发模式，否则在过去的半个世纪里学到的关于软件工程的一切会让我们停滞不前、退化并最终失败。接受新思维模式（以及已被验证的旧模式）的那些公司将会获得成功。特别有两方面对新的理解十分关键，就是本文将要谈到的重用和工具。工具　　20世纪40年代，所有的软件用机器码写成。50年代见证了首个编译语言：Fortran，几乎是在一夜之间提高了编程效率。使用Fortran的代价是更大、更慢的代码，这在当时被过多的工程师认为是不可接受的。但是那些接受了Fortran的人则