详情
本书专为嵌入式系统开发人员撰写，全书共分3个部分，包括嵌入式系统概论与开发流程；项目管理与软件工程；嵌入式系统开发技术。
谢亮 谢晖 改编
北京
市面上电子产品琳琅满目，业界正在使用的CPU、IC与嵌入式操作系统多如繁星，嵌入式系统开发的技巧数不胜数，书店里嵌入式系统的图书繁杂多如过江之鲫，更不要提在Google搜寻“Embedded System”会出现多少相关网页！由于嵌入式系统是计算机产业中非常特殊的一个领域，几乎没有一项电子产品或嵌入式系统开发项目是完全相同的，身为这个产业链中的一员，面对排山倒海的信息，你该如何制定自己的学习目标？
所谓“一法通，万法通”，嵌入式系统开发也是如此。如果只专注于研究某颗CPU的功能或某个产品的特性，实质意义并不大，重点应放在如何从繁杂的信息中萃取出放诸四海而皆准的思想，因为下个产品开发项目可能是完全不同领域的应用。例如，前一个项目开发的是多功能打印机，下一个项目可能是DVD播放器；前一个产品使用Android，下个产品则根本不需要OS。再加上不同项目可能使用完全不同的CPU或主控IC，这都增加了嵌入式系统开发人员对自身学习经历是否足以应付未来任务的质疑。笔者希望能将自身的经验与见闻整理成真正有用的思想，通过轻松的行文风格，传达给想加入嵌入式系统这一行业的你，希望本书可以让对嵌入式系统开发有兴趣的你少走一些冤枉路。
本书上一版自2007年6月上市至今已有三年多的时间了，期间收到很多反馈、鼓励、建议与指教。最令人开心的，则是能够对想进入嵌入式系统开发领域的朋友提供咨询，他们通过这本书找到了笔者，让笔者有机会分享自己在这个领域的经历与体验，让迷惘的朋友得到指引。
短短几年间，消费性电子产品市场发生了不小的质变：2008年金融海啸对电子业的冲击、iPhone及APP Store红透半边天、E-Book卷土重来、平板电脑死而复生（iPad带动电子阅读器的新风潮）、Google亲自下海搞了个Embedded OS（Android）、Intel收购WindRiver、ARM几乎囊括了高端处理器的市场、MP3产业盛极而衰、全世界各国陆续切换为数字电视（引发STB爆炸式需求）。以消费性电子产品类别来说，目前最热门的是：智能手机、电子书、微投影机、高画质播放器、3D电视等。当今市场气氛和两年前已有极大的改变。
虽说本书强调的是嵌入式系统开发与项目管理的思想，不会因产品不同而有太大的差异，但笔者仍认为本书必须与时俱进，有许多初版未放入的主题现在变得相对重要，而且部分既有的主题值得更深入探讨，更重要的是，必须修正初版中疏漏与错误的部分。
本书除了内容更丰富、完整之外，还加入了笔者这些年来对产业观察与实际执行电子产品开发项目的心得，并延请更专业的出版团队进行设计，使这本书的质量更加精良。
邱毅凌
两年前我为此书第一版作序时，即被作者无私地经验分享精神所感动，并期许其可在写作上多花时间。本书第一版销售成绩极佳，相信大部分的读者应该会从书中得到启发，更加深了我对作者其他新著作的期待。结果两年多来杳无音信，后来得知作者到某IC设计公司上班，他原本只答应去帮忙一阵子，为其系统应用（SA）团队导入正确的嵌入式系统开发思想与流程，但以其负责任的本性，对所有任务总是全力以赴，最后这家公司占用了他两年又两个月的时间。就我看来，相当可惜，作者把他可能的影响力只局限在一家公司、单一领域了！
2010年初，作者终于重拾写作，其广泛的出版计划令我相当吃惊，可见其分享的热情仍在，且依然不停地对产业界进行观察、思考与学习，在此我给予其深深的祝福！
自从苹果计算机推出的iPod、iPhone、iPad蔚为风潮，意味着MP3 播放器、智能手机、游戏机等消费性电子产品已逐渐取代PC，而成为主流数字产业，对于台湾地区信息产业的升级，扮演了关键性的角色，而其幕后的核心技术正是多媒体嵌入式系统。好的嵌入式系统，可以让硬梆梆的硬件更有价值。为摆脱代工的低毛利率，台湾地区业界对相关人才需求紧迫，遗憾的是，目前学校信息系的教育显然与现状有所落差。
本书以电子产品开发项目的生命周期为经，嵌入式系统技术与思维为纬，是一本行文轻松流畅却不失严谨的技术书籍。嵌入式系统技术的开发瓶颈，往往在于如何把嵌入式系统设计的重要思想与电子产品的硬件平台做创意性的结合。通过书中项目经理与菜鸟工程师的问答，嵌入式系统开发与项目管理的精神跃然于字里行间，传达重要思维与技巧于无形之中。这种风格在市面众多信息参考书籍中极为少见，对初学者当可趋缓其学习曲线，更快抓住重要的思想与学习的重点；对想迈入项目管理领域的技术人员，可更了解电子产品开发的生命周期与项目管理的技巧；对已有丰富经验的项目经理，他山之石，可以攻玉，本书绝对会带给你许多改进项目运行的灵感。
本书较前版增加了许多近年来开发消费性电子产品一定会碰到的主题（例如NAND Flash），并对项目管理理论、实际执行项目时必备的思维与技巧，以及fabless公司中的嵌入式系统开发团队等做了不少着墨。相信这都是作者亲身体验所凝聚而成的智慧，即便你已经读过本书第一版，还是可以从本书中得到不少的收获。
读完此书，你会发现作者欲将多年执行嵌入式系统开发项目的经验一吐为快，我觉得这是身为工程师、项目经理、技术团队主管等不可不读的好书，在此推荐给你！
吴锦城
思科（CISCO）前副总裁
美国Acopia Networks董事长
仔细想想，我靠嵌入式系统（Embedded System）吃饭有五六年了。念书时醉心于C++、图形学、影像处理等技术，立志成为游戏制作人的我，大概怎么也想不到今天得在2KB的内存限制内，写8位处理器的程序吧？
虽然很少有信息系的学生会立志当个嵌入式系统的程序员，但事实上，在台湾地区从事这方面工作的程序员不在少数。因为我们在生活中会遇到太多嵌入式系统：空调、洗衣机、电冰箱、电磁炉等，只要冠上“微电脑”的几乎都有嵌入式系统。电视机有一个嵌入式系统，电视机遥控器里也有一个嵌入式系统，DVD 播放器、游戏机也算是嵌入式系统，电子表、手机、PDA、电子字典等，所有你想得到的电子产品几乎都属于嵌入式系统的范畴。
正因为人才需求高，市面上和嵌入式系统程序设计相关的书籍、补习班课程等亦多如牛毛。这些书大多是学院派的，从理论出发。偶有书名冠上“实作”的，也仅限于列出程序的范例。很少有书籍从现实出发，告诉你在职场上会遇到什么样的问题，该用什么样的方法解决。很幸运的是，本书就是一本这样的书，而且更幸运的是，本书是台湾地区土生土长的中文原创书。
本书最大的特点，就是从目前台湾地区业界的现实面出发，点出项目团队人力缺乏、内部各小组互有摩擦、老板客户常有各种要求等真相。这要归功于作者拥有的数十年项目开发经验（而非数十篇学术论文）。书中提到的要点及案例，字字珠玑，只要曾在业界有些经验的人，读这本书应会不时露出会心的微笑（或是苦笑）。
也许是想要突显出“实务”的特性，也许是希望你能更轻松地消化书中的思想，本书采用技术书籍少见的“剧情对话式”文体，描述一位刚从学校毕业的信息系硕士从无到有学习嵌入式系统开发流程的经过。全文的主要内容，就是这位“菜鸟”和“项目经理”及各小组“老鸟”之间的对话。菜鸟所代表的是学院派、主流计算机系统的思维（动辄上GHz 的32/64-bit CPU、数百MB甚至上GB的内存、还有“用不完”的硬盘空间）；而老鸟们则代表了业界和嵌入式系统的现实（微处理只有数十MHz、数据存储器只有几KB、读写NAND ROM 还要考虑效率问题）。通过菜鸟和老鸟之间的对话，我们可以清楚地看到“学院VS.实际”以及“PCVS.嵌入式系统”的不同之处。再加上诙谐的文笔，让读者可以快速而专注地了解嵌入式系统的特性。
书中这位“菜鸟”以成为全才为目标，因此，随着书中项目的进行，被派到各个不同的部门了解学习。作者通过这个方法带领你了解项目团队中每个小组的工作内容，也大略地介绍了项目开发的流程。书中提到一个重要的思路：学硬件的人不要怕软件，学软件的人也不要怕硬件。在项目人数普遍不足的情况下，软件人员遇到简单的硬件问题需要解决时，最快的方法就是靠自己做简单的实验，不要全指着别人来帮忙。相同的，其他小组人员的工作，我们也不是永远不会碰到。所以了解每个项目人员负责扮演的角色，不仅是项目经理的工作，了解这些知识对每个项目成员都有好处。
而本书最重要的一个思想，就是作者不断强调的：一法通，万法通。嵌入式系统使用的处理器种类繁多，再加上不同的系统级芯片（SoC）实作，是永远学不完的。因此，一位嵌入式系统工程师的学习目标，并不是把手中的芯片研究透彻（那是卖你芯片厂商的工作），而是要了解嵌入式系统有什么特性。等到真的把芯片和data sheet拿到手之后，再把思想套上去。作者在书中举出案例时，也不忘提醒你什么是重要的，什么是旁枝末节，大概看懂就好。
本书着重概念思想，细节方面则提供不少经典书籍供参考。这本书可以当成进入嵌入式系统开发的敲门砖，看完之后再看书目上的书，应该更有感觉。
总而言之，这本书是中文计算机领域难得一见的原创好书！强力推荐给正在这个业界中努力求生存，以及将要进入这个业界的勇士们。此外，我也要推荐给信息系的学弟学妹们，书中描述的情景可能就是你们未来工作上会遇到的问题。即使将来不走这条路，书中的内容也可以和课本上的微电脑组织架构互相比较验证。而且这本书写得那么轻松，就算是当故事书看也不错！
──Closer |酒精浓度百分之五
这本书可以说是项目经理笔记，通过对白式的小说形式，呈现一个菜鸟软/固件工程师成长的经历，文笔不脱工程师风格；又或者说与一般技术性书籍相同，到处都有流程图、表格，还有程序代码。每一段故事后都有作者的经验之谈，并以黑体字表现，在轻松地演出后，留下重点。
本书前1/4的内容着重于项目管理，主要探讨嵌入式系统项目的特性、复杂性与先天限制，也包含了公司人事管理、跨部门沟通的思维。这部分是全面性的考虑，你可以一窥整个项目所牵涉到的各种问题、各部门的特性与考虑。其中与我现在公司的所见有相当多可以借鉴之处，对眼界的开阔极有帮助。
而书后约 3/4 的内容则是属于研发的部分，描述菜鸟工程师如何由一个新人，在资深同事的带领下，应用学校所学，通过比较与现实工作的异同，打破单纯软件归软件、硬件归硬件的刻板印象。从CPU的启动程序到基本的驱动程序的编写，以及最后调试与测试工作，再回归到项目的本质，完整的一个成长过程，予我有莫大裨益。
整体而言，本书可看得出笔者经过相当多的工程设计实践，文笔颇为流畅，所分享的经验也相当恳切，非常适合作为相关单位新人培训使用，资深人员则是看着自己的故事类似地上演，是值得一读的好书。
——小麦|小麦的心得笔记
本书用“老鸟”与“菜鸟”之间的互动，将嵌入式系统开发及项目管理所需注意到的事项都详细地描述出来。如果我在毕业专题及论文实作时先看这本书，那可能就不用走这么多冤枉路了。
这本书不仅适用于嵌入式系统，也适用于FPGA、DSP开发。我在开发FPGA、DSP的时候，很多时候都是去翻spec.；要不然就是耗费在解决移植到板子上的问题，像是内存配置、处理速度不够快诸如此类的问题，有时候还用猜测的方式来解决，不过，这些在本书中都解释得非常清楚。
这本书对于刚入门嵌入式系统的菜鸟来说，真的很值得一看！
──kewang|杂七杂八的kewang博客
自研究所毕业后，我就一直在嵌入式系统的设计领域，本书以一位职场“菜鸟”为串场主角，述说“菜鸟”参与开发项目的经历，通过与共事的项目经理和一些“老鸟”的对话，带入相关主题，让我回想起以前参与的许多项目经历。要培养这个领域的专家并不容易，因为现代科技与时俱进，必须一直保持学习，不过，踏入这个圈子后，就没有失业的问题，因为永远缺人。本书非常值得想进入或已经在这个领域的朋友阅读。
──Bridan |研发培训机构（Bridan’sBlog - 4rdp,For R&D Person）
菜鸟：一位刚毕业的信息系本科硕士，这是他第一份被录取的工作，刚成为职场新人。
项目经理：拥有十年以上消费性电子产品丰富开发经验，职位为 PM，目前带领该公司的研发团队负责某日本国际大厂委托的电子辞典开发项目，同时也是“菜鸟”职业生涯中遇到的第一位启蒙老师。
软件部门经理：比项目经理还要有经验的软件人，是目前公司中软件开发团队的主管，对软件开发流程与质量要求，始终保持着几近固执的坚持。
固件老鸟：项目团队中固件小组的组长，虽然工作时间不长（约三年多），但控制过的 IC不少，对驱动程序开发相当有心得。
系统老鸟：项目团队中系统小组的组长，在团队中的地位与影响力如同项目的副主管。技术能力相当全面且扎实，“年轻”时曾独力开发过RTOS，深知系统架构与开发流程对项目成败的影响。
硬件老鸟：负责过许多国际大厂的产品设计与生产，对硬件设计的性能与成本总是斤斤计较。
测试老鸟：曾是优秀的软件工程师，因配合度高，授命组建测试团队。对软件开发流程相当熟练，能使用最有效的方式进行测试，与 RD团队关系良好，但测试团队人员流动率高是其最烦恼的事。
本书主要目的是希望你不论身处于哪个职位，都能了解嵌入式系统开发是怎么一回事。项目管理者需要知道一个电子产品从无到有，包含哪些开发工作及困难；工程人员必须知道项目管理的精神，才能与其他领域同仁顺利合作；老板则必须了解项目成员们的职责，必要时才能适时给予协助及资源等。但每家公司的组织结构与企业文化不尽相同，很难在一本书中说完所有组织架构可能碰到的问题，因此，本书采用最常见的组织架构，如下图所示。其实一般公司就算职称不同，运作一个电子产品开发项目时，也不外乎就是这些角色，书中提到的思想与工具自然仍可一体适用。
项目的执行时间有长有短，与项目困难度或组织所投入的资源有关，但无论成功或失败，项目总有结束的一天。项目成员从项目启动后陆续加入，并在项目任务完成后逐一离开，回到其原有组织。也就是说，项目组织是临时性的，但公司的组织则必须持续发展。举例来说，软件团队已经具有RTOS的技术，所以，公司在接了相关的项目后，随即会指派一名项目经理，并从软件团队中挑选成员加入此项目。在此同时，软件团队可能正在导入 Embedded Linux技术，这是该团队的长期发展计划，和目前正在执行的所有项目没有直接的关系。因为这种组织架构（称为强矩阵组织），可兼顾组织的日常运作及临时性项目的执行，目前已被广为采用。
在强矩阵组织中最可能发生冲突的来源有两个：第一，负责某项目成败的项目经理，与负责组织中人力调配、新技术研发的部门经理（为与Project Manager 区别，通常称之为Functional Manager）两者的职责、所必须具备的能力和对组织发展的看法并不相同；第二，当工程人员加入某项目后，在项目执行期间会有两位直属老板，如果这两个老板之间沟通不好，则项目成员可能无所适从。
为避免过多角色导致笔者想表达的主题失焦，书中会淡化“Functional Manager”的角色。例如，工程师的招聘通常由Functional Manager 面试并决定是否录用，而Project Manager会在项目启动时，在目前组织中挑选成员加入项目[1]，本书会将此关系简化为直接由Project Manager来招聘项目成员。本书两位主角就是 Project Manager 以及一名新项目招聘的菜鸟工程师，但Project Manager 与Functional Manager 间沟通渠道是否畅通、权责能否区分清楚等，也是项目成功与否的重要因素之一，所以书中新增一个专门讨论Functional Manager 在嵌入式系统开发项目中角色界限的章节[2]。
注 释
[1]. 除非组织中无合适人选，才会由Project Manager负责招聘，但此新进人员还是会被挂在某位Functional Manager的团队之下。
本书相较于上一版，改动极大，绝非修正错别字、增加一些无关痛痒的章节而已。虽然主要架构不变，但笔者对全书进行了全面的检查，力求去芜存菁，新增笔者认为读者必须知道的主题多达50种以上。此外，根据笔者这两年讲授嵌入式系统项目管理课程，以及实际运作电子产品开发项目的经验，归纳出许多业界普遍存在的问题，并在本书中提出实际可行的解决方案。
业界有太多一直抓不到嵌入式系统开发本质、把时间用错地方的热血工程师；有太多仍以“土法炼钢”，不知如何使用所掌握的技能，只好无效率地不断加班，靠工程师的生命与运气执行项目的疲劳团队。更不幸的是，许多团队都会有个好打官腔、不知民间疾苦、要求项目按照教科书规范执行，却又不愿提供足够资源的老板！本书即便无法对整个产业起到震聋发聩之效，也希望能让所有读者，无论是工程师、团队主管，还是高层老板，都能用有效的方式执行嵌入式系统项目，并进行电子产品开发。
需知唯有软件才能赋予硬件灵魂！只有通过培养更多的嵌入式系统开发人才，建立具有国际竞争力的电子产品开发团队，经产业政策鼓励可在全球竞争的信息/电子公司，才是产业升级的不二法门。
至此笔者仍一秉初衷，若本书出版能对此产业有所帮助，能让你本人以及所属团队和公司用正确的方法，发挥最大的创造力，则甚幸！
笔者专为本书设立了一个专属的Blog，可作为与读者之间的沟通平台。内容除了本书中既有主题的延伸与讨论之外，还会陆陆续续加上未收录在本书中的实例，以及嵌入式系统开发的相关新知识等。网址为：
http://tw.myblog.yahoo.com/embedded_system_book
若你有任何问题或指教，可以直接寄到以下Email Address，或在笔者的微博中留言，我当竭尽所能为你服务。
Email address：ealin.chiu@gmail.com
Facebook：ealin.chiu@gmail.com
Plurk：Big_Blackdog
Twitter：Big_Blackdog
致谢
笔者工作至今十多年，帮助和教导过我的人不知凡几，否则怎能累积经验以成本书？所有在我生活与工作中出现过的朋友，谢谢你们，是你们督促我学习与成长！还有目前 KME 工作室的伙伴们，谢谢你们，别忘了我们要共同实现的美好目标，美好的旅程才刚刚开始！
我还要感谢的是我亲爱的老婆——俞娜。在我埋首于工作与写作时，她无怨无悔地照顾好我的一家老小，与一只狗、一只猫，让我毫无后顾之忧地写完这本书。当然，还要谢谢出版团队后期制作的细心与努力，你们的专业让这本书除了专业，更添质感！
最后感谢翻阅或购买这本书的你，希望本书的内容真的对你有所帮助。
Ealin Chiu于台北
2010年8月20日
让我们从一个面试的场景开始。
项目经理：“我觉得你的学习经历及专业技能都符合这个缺失职位的需求，工作内容是消费性电子产品开发工程师。简单地说，就是现在最热门的‘嵌入式系统’，我们团队目前正承接某日本大厂的电子辞典开发项目。”
菜鸟：“其实我有点担心我的能力是否真能符合贵公司的职务需求。虽然我在学校修过微处理器实习，但对所谓的‘嵌入式系统’仅有粗略的概念，不仅汇编语言没写过几行，驱动程序也没碰过，电子学还被挂过一次，更不要说什么实际的经验了。还有，嵌入式系统的程序要怎么写？是现在热门的Google Android还是Windows Mobile平台？API手册可不可以先让我回家恶补啊？”
项目经理：“放轻松，别告诉我现在学校不教 C 语言了！操作系统、数据结构、算法及计算机组织都是必修的吧？希望你上这些课时不是在鬼混，其他实战必备的技能，等你进来后我们会慢慢教你。此外，我们有自己的软硬件架构，所有的API都是自己写的，要用到Windows或Linux那套的机会恐怕不多。”
菜鸟：“是喔！其实我对Java和网页程序比较熟，公司的开发项目会用到Java吗？”
项目经理：“恐怕不行，我们用的CPU执行时序只有24MHz，而且客户对产品性能要求相当严格，我想都没想过要跑Java。之前我们还用8051做产品，你要8 bit MCU跑Java VM是有点过分了！”
菜鸟：“什么？24 MHz？我的计算机都飙到 3.2 GHz 了，还双核心耶！这样的 CPU 能做什么？”
项目经理：“放轻松嘛，除了跑Windows 7外，可做的事情多了，我还没跟你说我们系统只有8 MB的SDRAM，至于那个8051项目用到多少内存，以后有空我再慢慢让你知道，现在不宜给你太大的惊吓。”
菜鸟：“冒昧问一句，像电子字典这样的产品有什么技术可言？好像蛮low-end的，我刚刚毕业，希望能在第一份工作中多学点东西。”
项目经理：“在 PC 上开发执行的电子辞典系统也许很简单，但在 24MHz 的 CPU、8 MB的SDRAM上，需要的技术可远超出你的想象！此外，日本厂商对高质量的严格要求，我想你也略有耳闻，不但要机器稳定、耗电量低，死机绝对是不可饶恕的罪过，在这样的前提下，需要的技术恐怕真的比你想象的还多。
在开发电子产品的过程中，你可以学到嵌入式系统的思想、产品化的流程以及项目管理的技巧。此外，我们还会教你使用示波器、逻辑分析仪等信号测量仪器，当然还必须要会看原理图，会测量硬件的信号。”
菜鸟：“哇！我是学软件的耶……”
项目经理：“就如同大部分学硬件的人也同样会害怕写程序一样，真的不需要有这种莫名奇妙的排斥与担心，只要逻辑思维清楚就可以了。试想，当你要把程序放上某个硬件板子上执行，机器通电后，执行的第一行指令就是你的程序，而你是写程序的人，怎么可以不清楚这个CPU的运行方式与这块硬件板子的电路配置？”
菜鸟：“好像有点懂了，似乎还蛮好玩的。请教一个私人的问题，现在智能手机好像很红，我对智能手机的开发还蛮有兴趣的，在贵公司有机会开发手机吗？”
项目经理：“我刚和你说的工作内容是‘消费性电子产品’或‘嵌入式系统’的开发，在较高的层面上，我觉得开发电子辞典或手机所需要的基本知识是一样的。等做了几个产品之后，有天你就会突然顿悟的。”
菜鸟：“好像有点玄……”
项目经理：“如果你愿意加入我们，我会让你在一件件任务中学习。”
这些年来，“嵌入式系统”一直是个被喊得震天价响的名词，但真正了解其内涵的人并不多。因为离开学校已久，笔者曾试着从面试或培训新人时做些简单的调查，却惊讶地发现，几乎所有信息本科毕业生（包含研究生）或有两三年软件开发工作经验者，他们可以把“嵌入式系统”的定义说得头头是道，但却只有少部分人具备如何实现的概念，更甭提一些产品化的细节与注意事项了。
许多知识学校不会教、也无法教，因为那需要实际经验。就如同操作系统的教科书不会教你 Boot-Loader、Context-Switch 等实作一样，或软件工程的老师绝对不会讲授在人力缺乏的状况之下，如何去执行教科书中的那一套质量系统！
笔者在业界多年，深知台湾地区硬件厂商被客户压榨或同行削价的竞争之苦，而台湾地区商用软件开发公司的规模也远不及欧美，甚至印度，唯有通过软件及创意来增加硬件的价值才是信息业的出路。因此，培训信息系本科学生具备嵌入式系统开发的相关职能确实刻不容缓。
现在的新人都需要一到两年的培训，通常是必须参与某个产品的开发工作之后，才能真正了解嵌入式系统开发的本质，但笔者认为这个时间应该缩至就业前。市面上有关嵌入式系统的书籍很多，但通常只能讲述一些基本思想，对实际操作则点到为止。其他则在某个特定平台上深入钻研，这些对嵌入式系统开发的帮助微乎其微。从这些书中，你可以学到如何在 ARM 的评估板上写程序、如何架构Embedded Linux系统、如何移植Java VM到嵌入式系统等，如果工程师遇到的项目是：使用日商SEIKO EPSON特制化的CPU开发手持式电子装置，或者使用8 bit 8051这颗CPU加上凌阳的DSP，开发类似电子狗的玩具宠物，这些书能帮上什么忙？
其实，这行的高手可说是卧虎藏龙，也许大家都忙于工作，愿意（或有空）分享者少之又少。笔者愿将多年嵌入式系统开发的经验聚集成册，基于电子产品的多样性，阐述真正对你有益的思想，再加上实际发生的案例及其解决方案，读者可从中学到与其他教科书不同的“嵌入式系统”。
希望此书可起到抛砖引玉之效，让嵌入式系统培养教育更为扎实，并且让信息业更上一层楼。总之，这不是一本全都在讲述何谓嵌入式系统的书，更不是只教你在某个特定平台写程序的Programming Guide，笔者希望通过实例让你从本书中学到嵌入式系统项目管理的思维及真正实作的技巧。
笔者才疏学浅，虽竭尽心血并经多次校正以成本书，其中难免错误之处，希望高手前辈不吝指教，万分感谢。
本书风格稍异于一般技术书籍，以一个完整的嵌入式系统开发项目为支架，通过菜鸟与项目经理及资深技术人员的对话，推导出实际上正确的思想。通过这种方式，你会对这些思想与知识留下深刻的印象，而且是透彻的了解，学习效果当然比教条式的宣读要好。
对第一次阅读本书的你，建议遵循以下提示，当可收到事半功倍之效。
■ 项目经理的回答与菜鸟对讨论的总结往往是重要的思想所在，为避免你忽略重点，书中会以粗体字表示（请注意，本书中使用PM缩写时都是代表“Project Manager，项目经理”的意思）。
■ 较重要的概念，在章节的结尾处会加以深入探讨。
■ 对于篇幅较长的章节，在结尾处条列出该章节的重点回顾。
■ 本书旨在传达嵌入式系统项目的思想，并不局限于特定平台。至于书中程序部分，你应该先看粗体字的注释，了解程序目的之后，再看程序的细节。
■ 如果对C语言不是那么熟悉，可以先略过书中的程序部份，你还是可以学到嵌入式系统开发项目的重要思想。
书中各个章节尽可能保持独立，基本上是以嵌入式系统项目生命周期的各个阶段作为区分。全书主轴为：一个在电子产品开发领域中经验丰富的项目经理，与其团队中的研发主管们，带着刚毕业的菜鸟进行嵌入式系统开发的成长历程。嵌入式系统开发的思想与经验都融入在项目经理与菜鸟的问答中，再加上在许多实际工作上发生的案例，可对嵌入式系统开发有更透彻的认识。
本书共分19章，基本上，是按照嵌入式系统开发项目的生命周期排序。除了第3、4章之外，其他章基本上保持独立，你可选择有兴趣的章节先阅读，在必须参考到其他章节的地方都会详加注明。但笔者仍建议第一次还是从头读起为佳，就如同嵌入式系统开发项目必须按部就班一样，总不能设计阶段还没做完，就开始忙着实作吧！
全书分为3个领域，分别如下。
嵌入式系统概论与开发流程
■ 第1章：系统·嵌入·硬件
■ 第3章：嵌入式系统开发项目生命周期：项目启动与规划
■ 第4章：嵌入式系统开发项目生命周期：设计、执行与结项
■ 第17章：系统整合
■ 第18章：Testing、Debugging与Tuning
■ 第19章：结项前的煎熬
■ 附录D：电子产品设计的最终依据：用户体验
项目管理与软件工程
■ 第2章：嵌入式项目管理
■ 第15章：项目进度追踪实务
■ 第16章：SoC设计公司中嵌入式系统团队的管理
■ 附录A：未执行项目管理的项目
对项目管理较没兴趣者可先跳过这些章节，或先快速读过，待全书读完之后，再回头来看一次，应当会有更多的体会与收获。笔者在此要强调的是，千万不要认为自己只是个工程师就不必学习项目管理的思维，以台湾地区业界的环境来说，很难有人可以做一辈子的工程师，如果想在职业生涯更上一层楼，除了弄清楚产品的开发流程，具备项目经理的视野与职能也是相当重要的一件事。
嵌入式系统开发技术
■ 第5章：实作你的第一个嵌入式系统
■ 第6章：实作嵌入式系统平台
■ 第7章：构建良好的嵌入式系统开发环境
■ 第8章：上电之后：Boot Loader
■ 第9章：驱动程序
■ 第10章：设计硬件抽象层
■ 第11章：菜鸟当自强：软件工程师硬起来
■ 第12章：做好存储器管理
■ 第13章：存储器管理（II）：NAND Flash 概论
■ 第14章：模拟器
■ 附录B：Callback Function
■ 附录C：用C来实作面向对象的概念
以下是各章节的简介。
■ 第1章：系统·嵌入·硬件
主题为嵌入式系统概论，内容包含嵌入式系统的定义与特性，还介绍了几本值得一读的参考书籍，最后说明一位优秀的嵌入式系统从业人员应具备的基本职能是什么。
■ 第2章：嵌入式项目管理
本章是一个完整的项目管理概论课程，利用讲解投影片教材的方式，阐述项目管理的重要思想，并逐一说明项目管理知识体系（PMP）中的流程与工具。
■ 第3章：嵌入式系统开发项目生命周期：项目启动与规划
第1、2章介绍嵌入式系统开发项目的生命周期，你将发现业界的实际情况与软件工程、项目管理教科书中确实存在着差异。每项产品开发项目都应该视作一个项目，并使用项目管理的思维与工具来管理。偏偏大部分项目经理都是由工程师升上来的，并未受过正式的项目管理培训，本章会花一些篇幅说明项目管理的重要思维。此外，本章内容还包含嵌入式系统开发项目简介、项目开始之前的规划评估以及项目初期的规划工作，其中包括进度、规格、人力及成本规划等。
■ 第4章：嵌入式系统开发项目生命周期：设计、执行与结项
描述嵌入式系统开发项目中的设计阶段、执行阶段与最后的结项阶段，其中对设计阶段有较深入的描述，包括产品规格、硬件设计、系统设计、测试计划设计及风险评估等。
■ 第5章：实作你的第一个嵌入式系统
实际描述一个嵌入式系统的开发流程。虽然目的只是让硬件板子上的一个LED闪烁，但却已是一个具体入微的嵌入式系统。本章包含开发嵌入式系统程序的步骤与注意事项，除此之外，还对计算机系统的运行原理有深入的探讨。
■ 第6章：实作嵌入式系统平台
所谓的嵌入式系统平台就是让电子产品的应用程序得以顺利开发的环境，它不仅是软件或硬件的概念，还是一个稳定的环境。在这个环境下，负责应用程序开发的工程师，可以将心力放在产品功能的实现，以及改善其质量与性能上。本章内容包含嵌入式系统平台的定义、系统架构设计、API与程序风格设计、嵌入式操作系统简介、Source Tree设计以及程序风格典范等。此外，为了让你对系统架构有更深层的认识，本章还加入了SDK与Turn-Key Solution 概论，以及许多系统架构的案例分析。
■ 第7章：构建良好的嵌入式系统开发环境
描述何谓嵌入式系统开发环境，以及为什么要构建嵌入式系统开发环境，内容包含嵌入式系统开发工具（Cross-Tools）简介、Makefile 与Link Script 的思维与写法、何谓ROM Maker、如何将程序下载到机器上并执行，以及版本控制server 的重要性。最后，举一个实际发生过的案例，说明构建所谓嵌入式系统开发环境的重要性。
■ 第8章：上电之后：Boot Loader
描述机器上电后，如何让CPU可以正确执行我们的程序，以及开机后系统该做的初始化动作。本章内容包括第一行程序如何被执行、基本硬件测试，以及如何加载程序段与初始化数据段等细节。最后介绍目前最热门的 NAND Flash，描述 NAND Flash Booting的工作原理以及注意事项。
■ 第9章：驱动程序
有些人会认为嵌入式系统开发几乎就是在做驱动程序开发，这当然是错误的观念。驱动程序仅是嵌入式系统中的一个环节而已，但一般软件工程师总会对驱动程序开发怀着莫名的恐惧。本章首先陈述驱动程序开发并没有想象中困难，接着描述驱动程序开发之前的准备工作，其他内容包括如何控制CPU、如何控制内存与其他IC、编写中断处理程序的注意事项，以及如何为驱动程序调试。
■ 第10章：设计硬件抽象层
业界通常认为硬件抽象层是个复杂且不容易实现的概念，其实这是一个谬误的说法。因为唯有系统架构中包含硬件抽象层，才可能满足嵌入式系统对可移植性的需求。本章将说明硬件抽象层的重要性、设计原则，以及实作时的注意事项。
■ 第11章：菜鸟当自强：软件工程师硬起来
负责嵌入式系统的软件工程师，必须对硬件的知识与技能有相当程度的了解。本章从软件工程师的需求出发，说明硬件设计流程、烙铁与测量仪器的使用原则。
■ 第12章：做好存储器管理
存储器管理是嵌入式系统开发中相当重要的一环，本章内容包括存储器空间配臵，以及Stack与Heap在嵌入式系统中的应用，最后提到可将程序或数据写入EEPROM或Flash的烧录器。
■ 第13章：存储器管理（Ⅱ）：NAND Flash 概论
目前NAND Flash应用越来越普及，但NAND Flash却有着让系统设计者头大的特性——Bad Block。本章从系统开发的角度说明NAND Flash 特性、NAND Flash 控制Bad Block、ECC与平均写入机制（Wear-Leveling）。
■ 第14章：模拟器
嵌入式系统的开发环境通常十分昂贵，不可能给每位工程师都配上一套，再加上项目初期可能没有足够的硬件平台可供应用程序开发之用，由此可知，在嵌入式系统中模拟器的功能是很强大的。本章首先介绍何谓模拟器，接着说明 Emulator 与 Simulator的差别，以及模拟器对嵌入式系统开发项目的贡献。最后列举许多如何在 PC 上模拟实际机器装臵的实例。
■ 第15章：项目进度追踪实务
系统是否能如期完成，除了技术问题之外，最重要的，当然是项目能否被“妥善且正确”地管理。本章说明如何执行项目进度的追踪，以及介绍一组容易使用的项目管理，以及进度追踪的工具套件。
■ 第16章：SoC设计公司中嵌入式系统团队的管理
SoC设计公司中的SA（System Application）团队也是一个嵌入式系统开发团队，但却有着更为“艰苦”的处境。本章除了介绍 SA 团队的工作流程与管理方式之外，也花了不少篇幅说明Turnkey Solution 的特性。
■ 第17章：系统整合
大部分的应用程序会先在仿真器上开发，而驱动程序与部分系统功能则必须在真实机器上才能验证。当底层平台已趋稳定，就可逐一将应用程序移植到实际机器上执行。本章内容包含进行第一次整合的最佳时间点、导致整合失败的原因、开发进度重新检讨，以及程序移植时的注意事项。整合完毕后就可以发行正式版本，本章最后则会提到bug管理系统。
■ 第18章：Testing、Debugging与Tuning
当程序交付测试后，项目就进入了测试、调试与调整时期。本章以测试、调试与调整3大主题，详细内容包括嵌入式系统的测试概论、静态测试原理与工具、bug的管理原则、debug基本技巧，以及如何进行系统性能、power与footprint的最佳化。
■ 第19章：结项前的煎熬
介绍结项之前的工作项目，包含版本发行、介绍生产线专用的自动测试程序、如何决定量产版本、出货不等于结项的怪现象，以及结项相关事宜等。最后对本书作一个简单的结语。
附录则共分为4大主题。
■ 附录A：没有执行项目管理程序的开发项目会有什么状况。
■ 附录B：解释何谓Callback Function。
■ 附录C：如何用C语言实现面向对象的思想。
■ 附录D：电子产品设计导论。说明电子产品设计不只是软硬件技术，唯有以用户体验为出发点，才可能设计出可被使用者接受的产品。
本书主角及背景
这是一个信息本科毕业生，从对嵌入式系统一知半解，蜕变为电子产品开发领域高手的故事，文中简称为菜鸟。
刚从学校毕业的他，幸运地碰到一个不藏私且爱说教的项目经理，在一个个项目的磨练下，除了写程序和调试外，他做了许多之前认为软件工程师不该做的事情，包括焊接电路板、看原理图、使用仪器测信号、测试和客户或厂商用E-mail沟通等，甚至还帮忙编写产品规格书，也会三更半夜进工厂去处理一些并不像是软件bug的问题。
他自诩写程序的功力不差，逻辑能力强，专业课成绩也都很好；但在项目的进行中，才发现嵌入式系统或消费性电子产品的开发有太多未知的学问与技巧，更发现学校里教的东西居然大部分都派不上用场。
故事从他被一家约一百多人的信息电子公司以“研发工程师”的职务录取开始，在此之前，他只知道他的工作内容是“消费性电子产品”与“嵌入式系统”的开发[1]。
这天是菜鸟工程师报到的第一天，他怀着忐忑不安的心情踏入公司。
时间：01月10日
地点：大会议室
登场人物：菜鸟、项目经理（PM）
PM：“Welcome on Board！欢迎加入我们团队，我希望你在正式报到之前，能先了解一下工作性质。如果可以的话，我想先帮你做岗前培训。”
菜鸟：“嗯，我会努力学习的。”
PM：“你不用紧张，我先带你参观一下工作环境，介绍一下各个部门的成员。对了，本项目团队目前负责一个日本大客户交付的电子产品开发，我是这个项目的PM，也就是项目经理，我需要一个助手，以后我就是你的主管，我会让你尽快上轨道的。”
我们姑且称这个主管为项目经理（Project Manager，以下简称PM[2]），手下约有30 名工程师，他总是在喊缺人，而老板认为他已经是公司中最大项目团队的主管。公司提供的资源已经够多了，但工程师每月加班工时居高不下却也是不争的事实。
他总想起第二次世界大战时德军的某个连队，在莫斯科前线，掩护其他部队撤退的故事。这个连长只剩下15个人，在零下二三十度的冬天，缺乏弹药的情况下，负责防守一公里的战线，如图1-1所示。他们面对前苏军营级部队一次又一次的冲锋，他们因为部署得宜，节制弹药的使用，再加上士兵训练精良，居然守了3天，让友军得以成功撤退。
PM：“你知道这个连队最后怎样了吗？”他老是喜欢讲这个故事给新来员工听。
菜鸟：“我很想知道！”看来菜鸟工程师对军事也很有兴趣。
PM：“全军覆没！能守住3天简直是奇迹了。但是你知道我为什么说这个故事给你听吗？”
菜鸟：“不知道，这和我以后的工作有关吗？”
PM：“当然有关！和国际大厂比起来，像我们这样中小型的开发公司，电子产品或嵌入式系统开发就是这样严酷的战场，研发团队没有足够的资源，却要承接越来越复杂的开发项目。我就是那个连长，而你是其中一个小兵，每个人都要负责过长的战线。如果有必要，我也得拿起步枪和你们一起冲锋。”
菜鸟：“有这么可怕吗？”
PM苦笑：“别担心，那位连长只有15个人，至少我还有30人……”
成功的以寡击众只是偶然的奇迹，绝对不会是常事，然而电子业这一行，在第一线人员严重熬夜操劳以及用聪明才智的努力下，却不乏奇迹的故事。
菜鸟：“你的意思是说，我们的团队也是编制不全的啰？如果是这样，我们怎么还敢承接那个日本国际大厂的开发项目？”
PM：“刚刚谈的是人力与资源[3]的匮乏，我可没说我们团队编制不全。一般研发单位都有很严谨漂亮的组织架构，但这不代表每个小组都会有合适且足够的人力配置。先不管团队中现有人力的多寡与素质，就以功能面来看，一个开发嵌入式系统的研发团队，至少应该有以下的小组。
■ Project Management：项目管理组
■ Hardware：硬件组
■ ID design & Mechanisms：产品外观与结构设计组
■ Embedded Software：软件组
□ Firmware：固件组
□ System：系统组
□ Application：应用程序组
■ Testing & QC/QA：测试与质量小组
■ Supporting：支持组（生产联系、美工、法务、行政事务等）”
菜鸟：“除了硬件与结构小组之外，基本上，好像和课本写的软件开发团队也相差无几吧？”
PM：“但课本恐怕没跟你说有些组员的工作是跨组的吧！应该这样说，我们团队的状况是，几乎没有人只会或只需要做某个小组的工作。举例来说，项目刚开始时，项目管理组会比较忙，此时，几乎所有人都要帮忙评估规格、进度以及技术可行性，至于设计阶段则几乎是全员参与。当硬件工程师开始找零件、规划硬件架构，固件工程师必须和硬件工程师密切合作。同理，在项目的不同阶段，各有不同的人力瓶颈。前期阶段，上层的人要帮底层的人；中期阶段，固件的人要帮系统的人，系统的人要帮AP的人；后期阶段则所有的人都要帮忙测试与debug等。”
菜鸟：“一个人负责多件事情不是很容易造成混乱吗？这样工作效率会高吗？”
PM：“这也是没有办法的事，我们只能尽量做好时间与人力的配置。在团队的组织表中，每个重要的工作项目都有其对应的小组及负责人，这些小主管必须对项目状态、风险管理及人力调配付出相当多的精力。我就只有这些人力，为了调配他们去追赶几乎无法达成的出货日期，只好把每个人都当成全能在用，这并非我们公司与项目独有的现象，我想多才多艺[4]是业界对‘优秀嵌入式系统工程师’的基本要求。
但请注意，我可不是说时间与人力吃紧时就允许草率地执行设计工作，人力短缺就可以不写文件！人少有人少的办法，无视设计与文件工作，不但不能节省时间，反而导致项目失控或失败，但教科书上往往无视这个普遍存在的现实。”
菜鸟：“你是说，软件工程那套对嵌入式系统开发不适用啰？”
PM：“你还是没搞懂。第一，我从来没有贬低软件工程或对象导向开发模式的意思，它们也都是经验和天才的累积。我的重点是软件工程教科书中无法完全考虑所有的现实状况，偏偏这个状况又是业界普遍的现象。第二，上述的现象并不只发生于嵌入式系统或电子产品开发，我想，一般的软件公司或游戏开发公司也有这种看似漂亮的组织表，但人力永远捉襟见肘的状况吧！”
菜鸟：“我大概懂了，但我还是不知道嵌入式系统开发和一般软件开发有何不同，我的工作内容到底是什么？还有，您会把我分配到哪一组啊？”
PM：“别急！工作内容我会慢慢告诉你。在此之前，你先说说对嵌入式系统的了解，何谓嵌入式系统？”
菜鸟：“按照书上的定义，嵌入式系统是一种用于特定用途的计算机系统。例如，汽车里的ABS 刹车系统就是一个小型的计算机系统，有一个 CPU 执行着内存里的程序，不断地接收外界的输入，计算后输出结果。在ABS这个例子里，输入是轮子的状况与驾驶员踩下刹车的急促程度，输出则是对刹车器的控制。”
PM：“不错嘛！你的概念还蛮清楚的！有一本教科书是这么说的：
嵌入式系统是计算机软件与硬件的综合体，也包括机器或其他的附属装置，而这个综合体设计的目的，在于满足某种特殊功能。
还有另一个定义也颇传神：
以应用为中心、以计算机技术为基础，软硬件可裁剪，系统对功能、可靠性、成本、体积、耗电量和应用环境，有特殊要求的专用计算机系统。是将应用程序、操作系统和计算机硬件集成在一起的系统。
IEEE定义为：嵌入式系统是‘用于控制、监视或者辅助操作的机器、设备或装置’（原文为devices used to control、monitor or assist the operation of equipment,machinery or plants），其特性为：
■ 通常执行特定功能
■ 内含嵌入式微处理器
■ 严格的时序和稳定性要求
■ 全自动操作循环
而维基百科的定义则是：嵌入式系统是一种完全嵌入受控器件内部，为特定应用设计的专用计算机系统。与个人计算机这样的通用计算机系统不同，嵌入式系统通常执行的是带有特定要求预先定义的任务。由于嵌入式系统只针对一项特殊的任务，设计人员能够对它进行优化，减小尺寸降低成本。由于嵌入式系统通常进行大量生产，所以单一个的成本节约，能够随着产能进行成千上万的放大[5]。
我觉得这些定义都太绕舌。简单地说，就是那句我们常听到的口号：软件加值硬件（通过软件，为硬件提高价值）。图1-2所示为一个CPU，加上不同的设备，再配合不同的系统与应用程序，就可以开发出完全不同用途的电子产品——这就是嵌入式系统。”
笔者比较喜欢的定义如下，嵌入式系统的特性都表现在粗体字上。
Embedded System use general or specialized[6] purpose CPUs running custom software along with specialized hardware to perform applica-tion-specific functions.
基本上，这些定义大同小异，主要是范围的差别，最大的范围可以包含硬件设计，甚至时下最流行的SoC（System On Chip）都可以纳入嵌入式系统的范畴。但万变不离其宗，说穿了，嵌入式系统的本质就是以下两点而已。
■ 计算机系统
■ 特定应用
1-3-1 嵌入式系统本质（Ⅰ）：计算机系统
首先，嵌入式系统必然是一个计算机系统，计算机系统的定义如图1-3所示，由 4 个主要部分组成。
■ CPU
■ 内存
■ 输入设备
■ 输出设备
无论个人计算机、超级计算机或者任一嵌入式系统，至少有一个或一个以上的 CPU；而CPU 的计算能力根据其应用领域相差何止千万里远，在一般 PC 的 CPU 运行速度已达 3 GHz大关的今日，诸如8051、Z80、80186等历史悠久的CPU仍隐身在许多你我身边的产品内，如图1-47所示；更别提一些在特定的领域中大放异彩的CPU，恐怕你连听都没听过。
除了CPU之外，计算机系统的程序必须存储于内存之中。同样的，根据产品的特性，所使用内存大小与种类都大不相同，而嵌入式系统内的内存使用更是一门学问。说穿了，无非就是成本与性能的抉择。在许多应用中，成本的重要性出乎意外的占了上风[7]，本书会于专门的章节讨论内存。
计算机系统必定是为了解决某种特殊的问题而设计，复杂的 PC 是如此，嵌入式系统更是如此。解决问题的过程包含数据的输入与结果的输出，在嵌入式系统的领域中，除了处理数据的算法随产品应用领域而不同之外，输入与输出的种类更是无奇不有，其中大部分直接牵涉了硬件的操作。举例来说，冷气恒温控制器的输入是来自检测温度的芯片，输出则是对冷气强弱的控制；Wii 的无线游戏杆，输入是来自使用者操作导致的方位变化或被按下的按钮，输出则是通过红外线将这些处理信息打包后送回Wii主机。这样的例子不胜枚举，有些产品可能没有明显的输入，但肯定要有某种形式的输出，否则就失去制作这个产品的意义了。
附带一提，随着 IC 代工业的兴起，IC 设计公司也如雨后春笋般一家家成立，上述所谓的计算机系统几乎已可做到一个IC里面，如图1-5虚线框起来的部分所示（没被完全框起来的方块表示内存、输入/输出设备可以整合到 CPU内部，也可外挂在CPU外部）。对电子产品开发者而言，硬件设计的复杂度与出问题的机会当然都会大幅度降低，但对软件系统来说，所开发系统的基本原理与可能要面对的挑战则是完全一致的。
举例来说，图1-6所示的 IC 功能是将输入的字符串转为音频流并输出，这样的功能称为TTS（Text To Speech），可以看到这个IC的内部有CPU与内存（用以存储与执行TTS转换程序），并且有明确的输入（字符串）与输出（声音），根本就是一个不折不扣的嵌入式系统。
1-3-2 嵌入式系统本质（Ⅱ）：特殊应用
再来谈到嵌入式系统的第二个本质——特殊应用，这一点可引申出嵌入式系统更多的特质。嵌入式系统应用范围何其广大，从家里的微波炉、男厕的自动冲水系统、现在流行的游戏机、学生用的电子辞典、汽车里的行车控制系统（如图1-7和图1-8所示），到宇宙飞船的燃料控制、核电厂的监控系统等。在一个大系统中，往往包含很多小型的嵌入式系统，以个人计算机为例，键盘、光驱和显示器里都包含着一个计算机系统，CPU执行内存里的程序，处理着不同性质的输入，并输出不同性质的结果。
因为电子产品性质的各有不同，嵌入式系统的开发很难有一套统一的标准，没有一个国际标准组织或学术单位，规定嵌入式系统一定要用什么CPU、一定要使用什么程序语言开发、一定要用什么操作系统（有时候要不要用“操作系统”都还是个问题）、一定要用哪套开发工具，实际上，开发者并不需要因此而感觉无所适从，因为无论开发什么电子产品，基本的开发技巧与思想是一致的。
用一个比较传神的说法，嵌入式系统的开发很像太极拳，需要的是思想、基本功及实战经验，拘泥于招式与规定只会做出一个四不像的产品。简单的说，在开始设计某个系统时，弄清楚产品的应用范围与详细规格是最重要的事情，因为产品规格必然会影响以下项目的设计。
■ 开发进度规划
■ 预算与成本规划
■ 资源调配
■ CPU的选择
■ 硬件的设计
■ 软件的架构
■ 测试计划
■ 生产流程
举例来说，汽车的ABS刹车控制器，可能使用运算能力一般的CPU就可以了，但因为牵涉到人身安全，系统必须稳定且要求有严谨的测试计划，如太阳能电子计算机，除了计算结果的正确性之外，成本及省电却是更重要的考虑。每个产品都可以说出它和其他产品的不同处。在此不妨做个简单的练习，找一个你随手可得的电子产品，如MP3随身听或智能型洗衣机，如果是你来设计这个产品，最重要的考虑是什么？
实际上，许多项目都是在规格尚未确定的状态下就开工，这就如同只知道客户要你做一辆车，但却不知要做牛车、马车还是汽车；或者即使知道要做汽车，却又不知道客户要你做双B跑车、国产房车、还是火柴盒小汽车等。听起来很荒谬，但这种闹剧却在业界不时上演。
PM：“我希望你能对嵌入式系统开发有正确的概念，试着训练自己对产品设计的敏锐度，我要你选出10个身边的电子产品，分别列出它们的输入与输出是什么？并且以设计者的角度，列出设计这个产品时的重要考虑。以下是一些在产品设计阶段必须考虑的事情，你也可以试着思考还有哪些不在清单内的影响因素。”
■ 成本
■ 外观
■ 预计销售市场与消费群体
■ CPU计算能力
■ 内存大小
■ 省电需求
■ 稳定度
■ 反应实时性（Real-Time）
■ 软件复杂度
■ 测试复杂度
PM：“等正式报到当天交给我，这是你第一个任务，也是很好的岗前培训。”
菜鸟：“是。”
1-3-3 何谓嵌入式系统？
PM：“谈了那么多嵌入式系统的概念，考你一个问题，个人计算机算不算是嵌入式系统？”
菜鸟：“PC是个开放式系统，以Windows或Linux操作系统来说，它并不是专用于某种特定用途，使用者可以在上面执行任何程序。在某些时候，它可能是一台多媒体影音播放器；在另一个时候，它又像是一台上网机、打字机、游戏机，甚至是电子计算机。因为个人计算机的通用特性，所以它应该不是嵌入式系统。”
PM：“其实我这个问题是有陷阱的。刚刚说过， PC 里的键盘、显示卡等就是一个个嵌入式系统，如果我们只看主机板，当主机板上电后，CPU 执行的第一行程序是什么？存储在哪里？”
菜鸟：“这我知道，在操作系统启动之前，BIOS会先被执行，BIOS会去做self-test的动作，检测硬件有没有问题，如果使用者有按下特殊键（如F2键）的话，就会进入BIOS的设定功能，否则就会到硬盘、光驱或USB设备的特定地址加载操作系统。至于BIOS存储在哪里我就不清楚了，但应该不在硬盘里才对。”
PM：“不错！很有概念，以前的BIOS是存在Mask ROM里面，后来为了让使用者可以自己更新BIOS，现在的BIOS都是存在可擦写的Flash里面。看一下如图1-9所示的主机板，除了零件多一点外，它和一般电子产品的电路板有什么不同？主机板加上CPU以及内存后，即使没有硬盘，BIOS也会被执行，而BIOS是有特定用途的程序，它负责检测硬件以及加载硬盘里的操作系统。所以我说PC的主机板就是一个嵌入式系统。”
PM：“举个简单的例子你会更了解。假设我能改写 BIOS 程序，我可以更改它的用途为当使用者按下某个键，就会从 PC 喇叭播放生日快乐歌，那么，同样这块主机板就变成了特定用途的嵌入式系统。当然实际上不会有人设计那么贵、计算能力那么强的硬件平台，只为了播放一首歌！”
菜鸟点头：“的确是蛮无聊的应用。”
PM：“如果我稍微改变一下应用你可能就不会觉得无聊了，你知道大部分的测量仪器，如示波器，就是一片 PC 主机板加上精确的测量设备，以及分析信号的程序所组成的吗？你可以看一下这台逻辑分析仪，开机时你甚至可以看到 Windows 的执行画面如图1-10所示；因为它具有特定用途，我们也可以说它是嵌入式系统。此外，你不妨研究一下工业用PC，这类的产品除了特定用途，必须能在恶劣环境运行、对稳定性要求甚高之外，就是一台PC。当然，它是一种嵌入式系统，而且是很贵的嵌入式系统。再看如图1-11所示的这台公用电话，虽然里面执行的是Windows XP，但它也是一种嵌入式系统。”
菜鸟：“没错！我曾看过银行自动提款机死机后重启的画面，就是我们熟悉的 Windows 画面。我懂了，一个产品是否为嵌入式系统，和价格、大小、CPU计算能力与使用地点都无关，必须视其是否为了特定用途量身定做。”
PM：“没错！你要记住其实某项产品是否符合嵌入式系统的定义并不重要，重要的是开发者必须完全了解嵌入式系统的本质，以避免在设计开发阶段做出错误的判断与决定。”
1-3-4 电子产品的核心：CPU、MCU、DSP、SoC、ASIC
菜鸟：“计算机系统里一定会有个主控IC，刚才的图里都称其为CPU，但我们常看到一些不同的名字，最常见的是MCU或SoC，此外，我记得还有专长于运算与信号处理的DSP，以前报章杂志也经常看到 ASIC 产业相关新闻，这些名词我常常搞混，但它们在计算机系统里的地位有差异吗？”
PM：“其实这也没什么大不了，只是在说明嵌入式系统的多样性罢了！举例来说，如果要选个Power IC，你会考虑什么？”
菜鸟：“这个问题对我来说似乎太难了！细节我无法讲清楚，但我觉得市面上可选择的Power IC一定很多，因为每个产品需要的电源状况都不相同，可能有的只需要一组3V的电源，有的需要两组1.8/3.3V的电源，有的产品对电源的误差要求很高，有的则要求转换效率等，再加上成本因素，看来要考虑的事情还真不少。”
PM：“既然Power IC都必须根据产品特性而有不同的选择，更何况对电子产品最重要的主控IC？所以市面上有general purpose 的 CPU、有计算能力没那么强的 MCU、有整合了许多装置的SoC、有强于计算的DSP、有专为客户设计的ASIC，这么说你应该可以理解了吧？至于各个名词的定义你去问Google或查维基百科就会知道了。”
我们经常会混用这些名词，笔者认为这不伤大雅，只要在产品设计时，能正确地选择真正适合此产品的主控IC即可，在此仍节录这些名词的定义如下。
■ CPU：中央处理器（Central Processing Unit，CPU）是计算机系统的主要设备之一。其功能主要是解释内存中的指令，并处理内存中的数据，所谓 CPU 就是遵循冯• 诺依曼架构（Von Neumann Architecture）设计的装置。CPU的运行原理可分为4个阶段：取指（Fetch）、译码（Decode）、执行（Execute）和写回（Write-Back）。简单地说，CPU是一个概念性的名词，但用CPU称呼任何种类的主控IC都算妥当。
■ MCU：微控制器（目前在中国仍多沿用“单片机”的称呼），是把中央处理器、内存、定时/计数器、输入/输出接口等都整合在一块集成电路芯片上的微型计算机。与应用在个人计算机中的通用型微处理器相比，它更强调自供应（不用外接硬件）和节约成本。其最大优点是体积小、整合性高，但存储量小，输入/输出接口简单，功能较低。图1-6所示就是MCU的典型架构，IC内整合了一个CPU core，以及其他的装置或I/O接口。
■ SoC：是将一个完整的计算机系统，加上部分的电路，放入一个芯片内。这个芯片可能会包含数字电路、模拟电路、混合信号及射频电路等在内。SoC通常也会整合一块非挥发性内存（如ROM或One Time Programming Memory，OTP）在内，包含在其中的程序也会被称为嵌入式系统。
■ ASIC：特殊应用集成电路（Application-Specific Integrated Circuit，ASIC），是指根据特定用途而设计的特殊规格逻辑 IC。品种多、批量少，要求设计和生产周期短，作为集成电路技术与特定用户的整机或系统技术紧密结合的产物。与通用集成电路相比，具有体积更小、重量更轻、功耗更低、可靠性提高、性能提高、保密性增强、成本降低等优点。
■ FPGA：主控IC的另一个选择是直接在产品上使用“具有可程序化（Programmable）特性的FPGA”出货，相较于专门客制化的ASIC，FPGA在性价比上越来越具竞争力，且已致力于最为人所非议的耗电量的改进，对ASIC产业是不小的打击[8]。
■ DSP：数字信号处理器（Digital Signal Processor），简单的说，DSP就是一种专用于数字信号处理的微处理器。相较于一般微处理器，DSP具有特殊硬件及指令设计，以及分开的程序和数据存储器（Harvard Architecture，哈佛结构），可使其更有效率地存取数据。一般我们说CPU擅于控制，而DSP则擅于运算。DSP的应用领域如表1-1所示。
此外，MCU和DSP在应用上不一定是互斥的。图1-12所示是一个MP3 IC，IC里包含了一个8 bit MCU 以及一个 DSP。MCU 负责 NAND 管理与流程控制，而 DSP 则负责处理 MP3数据，MCU与DSP都只执行其最擅长的事情，所以，当然可以用最低的成本以最有效率的方式完成工作。
1-3-5 案例研究（Ⅰ）：使用与PC同等级CPU的嵌入式系统
菜鸟：“既然谈到CPU，就不能不让人想起PC上的X86系列CPU。X86应该是个十分稳定的平台，相关的研发资源也相当丰富，想到可以执行Windows、Linux以及无数的应用程序，相信就让无数开发商垂涎三尺了。虽然X86 CPU比较贵、耗电也较高，难道就真的只能用来做工业计算机或测量仪器之类的产品吗？”
PM：“X86背负着CISC架构的原罪，而一般研发人员早就被灌输CISC不适合用来当作电子产品CPU的观念，然而，这个观念并不一定在每个情况都适用。对了，你应该知道CISC和RISC的分别吧？”
菜鸟：“以前在学校学过，CISC与RISC主要是指令集长度上的差异。CISC的指令较具多样性，而为了支持更多特殊功能的指令，指令长度就无法一致。所以CISC需大量晶体管支持各种指令，并且需要高频率才能拥有不错的性能，但相对大量晶体管与高频率，却会带来高耗电。”
PM：“没错！耗电就是 CISC 最大的致命伤，但厂商仍不断的设法改善架构（例如，为提高性能，会把x86架构下的CISC指令先译码成类似RISC指令，再利用各种方式同步处理、加速执行），使CISC与RISC理论上的差距不再那么遥不可及。此外，通过对X86进行SoC化（即将x86所需的所有外部功能，与处理器运算核心（Core）封装在同一IC内），如图1-13所示，使得用这些SoC进行产品设计不像做PC主机板那么复杂，目前已有相当多SoC化x86处理器，应用在诸如健保 IC 卡片阅读机、停车管理系统、电子式水电表、超市查价机、心电图设备、CNC控制、PLC、网通设备、终端机、交通号志控制系统等领域。
而且换个角度想，在部分应用领域中，主控IC的单价与耗电量不见得是其最重要的考虑因素，而且如你所说，Windows与Linux上开发环境的便利性与现成的资源，对某些领域的产品开发商有着极大的诱惑力，所以采用X86核心的SoC目前也在某些领域被广为使用。”
菜鸟：“这又符合了您刚刚说的思想，进行嵌入式系统或电子产品开发，一定要先彻底分析最终产品的特性，在主控IC或零件的选择上，千万不可固步自封。”
1-3-6 案例研究（Ⅱ）：“藏”在IC内部的嵌入式系统
菜鸟：“讲到这里，嵌入式系统真的是无处不在，除了我们日常会碰到的3C商品、家电、玩具、手持式装置等小玩意外，还有逻辑分析仪等测量仪器这种价值不斐的大东西。此外，我们刚刚说到那个可以做TTS（Text To Speech）的IC也是一个具体而微的嵌入式系统，如图1-6所示。我比较好奇的是，这种被‘封印’在IC里的嵌入式系统是怎么开发出来的？它不像一般嵌入式系统有个开发板，可以外接一些debug装置，而且在开发阶段，程序怎么‘烧’到IC里的ROM？ROM应该是只读的啊！”
PM：“其实开发的流程与原理是一样的，但在这个开发流程中，软硬件工程师必须和 IC designer一起co-work。嵌入式系统开发团队的开发环境当然不会是一个IC，而是一个以FPGA为主控的板子，你可以从图1-14所示看到，FPGA的板子和一般硬件板子没什么太大的不同，但FPGA中电路是可程序化的。”
PM：“IC designer 以硬件描述语言（Verilog或VHDL）所完成的电路设计，可以经过简单的综合与布局，快速地烧录至FPGA上进行测试，就好像一个电路试验板被放在了一个芯片里，对软件工程师而言，这个FPGA的功能应该与最终要开发的IC完全相同，只是在IC设计阶段， FPGA 的行为难免会有些 bug，而软/硬件工程师也必须负责从系统应用的观点，帮这个开发中的IC找出潜在的问题[9]。
言归正传，以图1-6所示这个TTS IC为例，利用FPGA平台进行IC内嵌入式系统开发的流程如下。
Step01:如同一般电子产品项目，硬件工程师进行硬件板子设计，主控IC为 FPGA，除了这个IC在应用时需要的外部装置之外（如喇叭、ICE接口、UART传输接口等），还必须包含用以更新FPGA内部电路（程序）的接口。
Step02:IC team必须先提供一个功能与实际IC几乎完全相同，但ROM（in FPGA）中没有数据的FPGA版本，并协同硬件工程师确认FPGA与板子共同运行无误。
Step03:软件工程师将编译好程序，使用ICE下载程序到SRAM（in FPGA）执行与调试。开发中碰到任何问题时，必须考虑可能是FPGA内电路设计有误，并与IC designer密集讨论。
Step04:当软/硬件工程师在 FPGA 板子上完成系统开发后，将程序复位后交付 IC designers（在开发阶段，程序是在SRAM上执行，但实际IC在运行时，程序必须在 ROM 里执行），IC designer 会再提供一版 FPGA，待软/硬件工程师验证无误后，才可进入IC制造流程。
Step05:IC 里的 ROM 不是用烧的，而是在 IC 设计阶段，将程序或数据写入 ROM的电路。”
PM：“这个组就是我们的固件组。你可以看到每个人桌上除了个人计算机外，有着各式各样的板子、仪器、文件和一堆不知名的线。前阵子大老板要我要求所有工程师保持桌子的整齐，我马上向他报告此事窒碍难行，不同领域的员工自有其工作模式，身为管理者必须为其创造最能发挥工作力的环境，不应该妄加限制。”
菜鸟：“好像负责固件的人数不是很多，面试时您曾提过除了正在开发的产品外，我们已经开始设计下一代的硬件平台。我以为开发阶段应该会有许多问题等待解决，而新的硬件平台设计应该需要更多的人力，但我们就这四五个人，够吗？”
PM：“确实不够，但这是我目前仅能挤出的人力，况且也不是每个人都适合做固件开发的。这样说吧，若非不得已，不会有任何一个军队指挥官，会把一条一公里的战线交给只剩15人的连队防守，基本上，只有15人的连队根本就是不合理的存在，然而，这是不得不的现实。”
菜鸟：“老板知道这样的事吗？”
PM：“当然，其实老板正是始作俑者之一！哪一位老板不希望用最少的资源创造最大的价值？公司存在的主要目的是什么？不就是营利吗？这就是我这个专业项目经理存在的原因之一。嵌入式系统开发本来就是限制重重的，人力缺乏只是其中之一而已，而我的责任就是妥善统筹资源、人力与时间分配。”
在1-3节中说明了嵌入式系统的多样性，接下来，我们从以下5个方面来说明嵌入式系统的另一个特性——限制。
■ 产品规格设计
■ 人力分配
■ 进度管理
■ 硬件设计
■ 系统设计
1-4-1 产品规格的限制
嵌入式系统和一般软件项目有个显著的不同点，嵌入式系统完全应用于电子产品，而电子产品的开发必然牵涉硬件、结构、外观设计及其制造成本，也就是说，软件并不是某件电子产品是否热销的唯一原因[10]。
任何电子产品的开发计划都始于需求或创意，而创意的实现却往往被制造成本所限制，也就是说，制定电子产品规格时必须有所节制，不能天马行空的无限想象。举例来说，要用国产车的造价，设计出奔驰同等级的车款，无异是缘木求鱼。成本会影响规格，而规格则会影响所有与开发有关的工作。生产电子产品必须在成本与规格上取得微妙的平衡，如果规格及制造成本都不愿让步，那就只能考验开发团队的能力了[11]。
偏偏现实世界是大部分的客户或制定产品规格的人员都高估工程师的能力了。确切地说，应该是高估了目前计算机与管理科学的水平。在PC上某些很简单的事情，要在8位CPU，或少得可怜的内存（可以想象整个系统的内存容量居然是以KB或byte为单位来计算的吗？）的平台上实作时，需要的算法有时都可用来写论文了。
结论是：因为制造成本的考虑，电子产品在制定规格时便限制重重，而产品规格更是直接影响了运行其中的嵌入式系统的开发。
1-4-2 人力分配的限制
嵌入式系统开发并不一定都是复杂的项目，例如“电子宠物机”就是一个技术简单、成本低廉的产品，但其所牵涉的人力或技术种类却肯定比一般软件项目要多。以下简单列出嵌入式系统开发流程不可或缺，但一般软件项目可能不需要的人力资源。
■ 硬件设计工程师
■ PCB Layout工程师
■ PCB制作协助厂商
■ 结构工程师
■ 模具制造协助厂商
■ 提供硬件零件的厂商（如CPU、设备IC、内存、LCD模块、电阻电容等）
■ 固件工程师
■ 硬件测试协助厂商
■ 硬件品管及验货人员
■ 工厂
即便只负责软件开发，也无可避免地要和其他单位协调与合作，如果软件工程师能稍具其他领域的知识与技能，对嵌入式系统的开发绝对大有裨益。但现实情况是要找到具备与其他领域人员沟通的热诚、管理协助厂商的能力，并兼具程序设计之外技能的软件工程师确实不多，只能让工程师从工作中学习，等工程师好不容易渐入佳境，却又要担心被其他公司挖角，这是每一位管理嵌入式系统项目的项目经理心中无法抹灭的痛！
嵌入式系统开发在人力资源上的限制不仅仅是项目人数的问题，主要是牵涉单位太多，而各单位各有自己的文化及语言，管理的复杂度自然大增，若想把所有相关单位都纳于同一公司或团队之内，或要求每位员工都必须多才多艺且可同时执行不同领域的工作，却也显得不切实际且成本过高。
嵌入式系统不一定比一般软件项目复杂（其实有些电子产品的软件简单的出奇），也不一定需要更多或更高素质的人力，但“人”的管理，绝对是嵌入式系统项目能否顺利结项最重要的因素之一。
1-4-3 进度管理的限制：测不准原理
嵌入式系统的进度计划（Schedule）管理与人力管理面对同样的问题与限制，即参与开发的单位通常很多。项目主管一方面要花时间精力协调各单位，以便精准控制进度；另一方面，某项任务的延误，往往会影响其他单位的开发，尤其当这个单位隶属于别家公司，甚至这家公司不在国内时，不理性的争执、责任的推诿以及语言与文化的隔阂，必然让进度延误的状况雪上加霜。
图1-15所示是个典型的嵌入式系统的进度计划表，你可以发现很多任务是有前后关系的，而这些任务之间又往往属于不同领域、牵涉到不同公司。实际上，因为不确定性因素太多，进度计划表几乎都是边做边修正的。
项目中的任务之间必然会有一些相依性。举例来说，硬件的延误会影响软件的开发，而驱动程序的开发延误也可能影响硬件设计的验证，产品规格迟迟无法确定，则会打乱其他开发单位的步调，零件供货商供货出问题，则会直接影响生产，若到开发中后期，某零件无法供应，则直接受冲击的将是硬件设计以及固件工程师，整体项目进度势必推迟。
以图1-15所示为例，最常发生的悲剧是所有时间表都是由预计量产时间点往前推导得来。举例来说，营销部门希望12月底产品可以上架贩卖，所以往前推12月5日必须开始量产，再往前推一个月必须做小量试产，也就是说，在11月5日前硬件所有问题都要解决并完成备料。再继续推演。假设公司规定试产后软硬件设计就不该再更动，那么，既然11月5日要小量试产，软件应该要在半个月前就绪，而根据经验，软件要经过3轮QC测试才能将所有问题解决完，所以推导出软件整合必须在10月初就完成，于是管理人员拍拍脑袋就把进度计划画出来了。
注意到了吗？上述推演是以销售时间推导量产时间，用量产时间推导硬件开发时间，再用硬件开发时间推导软件开发时间，其中完全没考虑到人力与规格复杂度，主事者的说法必然是：“如果软件没办法照我的计划完成，这个产品就无法如期上架销售，则项目视同失败，所以请大家尽量配合加班……”其中逻辑看似合理，其实相当荒谬，一个摆明无法执行的进度规划行同废纸一张。
而且嵌入式系统是软硬件整合，调试较为困难，测试负载量也较大。在产品应用日渐复杂的情况下，偏偏电子产品的生命周期越来越短，为求尽快将产品推到市场，开发时间往往被迫压缩。然而产品质量和上市时机（Time to Market）孰重孰轻没有一定的答案，要视情况而定，所以嵌入式系统开发的进度管理需要考虑的事情非常多，要订出合理且可满足质量与上市时间的开发进度，几乎是件不可能的任务。
身为项目经理，制定进度计划时只能秉持经验、知识与职业道德勉力为之。原则上，项目进入执行阶段就不该大幅度修改进度计划，但实际上，频繁的更改进度计划却是业界的常事。其实项目进度并不是测不准，主要是嵌入式系统项目牵涉的变量太多，偏偏预定上市时间又太赶，往往没做好完整的风险评估就贸然进入执行阶段，任何一件小事若发生推迟的状况，就可能对整个项目进度造成出乎意料的影响。
1-4-4 硬件设计的限制
嵌入式系统的硬件设计也是限制重重，成本考虑是造成这些限制的主因，其他会影响硬件设计的原因还包括：
■ 产品规格与客户要求：产品规格当然会直接影响硬件设计，而负责制定产品规格的客户常常有些特殊的要求。例如，指定使用该集团子公司生产的零件，或要求硬件设计必须符合其旧有产品的结构。尤其是某些传统的国际大厂自有一堆内部标准，从键盘的反应时间、系统的耗电流、音频输出的质量、必须通过环境测试的种类，一直到零件采购公司的限制等。举例来说，通常这些大公司内部都有一份可采购零件的厂商清单，如果硬件设计者忽略了这个限制，到后期才发现可就麻烦了。若一开始不弄清楚客户的要求，等到产品试产之后才发现问题一堆，除了影响进度，势必影响工程师的士气以及公司之间的合作气氛。
■ CPU 特性：CPU是电子产品的心脏，当CPU选定后，硬件设计才可随之展开，嵌入式系统使用的CPU往往不为人所熟知。举例来说，EPSON可不是只作打印机而已，他们的半导体部门根据特定的应用领域设计了一系列的嵌入式 CPU。该 CPU 内部集成了许多外围芯片，如 SDRAM、LCD Controller 等，广泛地应用在诸如电子辞典或电子书等产品上。除此之外，许多硬件产商为特定应用自行设计的ASIC或SoC更是不胜枚举。
CPU的特性与功能直接影响其他部分的硬件设计，举例来说，若CPU的 GPI/O（General Purpose I/O；CPU中可用于一般用途的输出或输入脚位）不够，则势必要外加扩展I/O 电路或芯片，假若CPU有提供诸如I2C或I2S等通信接口，硬件设计者就可以选用支持此接口的外围芯片，因为这些接口可以把多个芯片串在同一个bus上，不但控制简单，还可节省I/O脚位。此外，嵌入式系统领域里的 CPU 通常集成了许多其他外围 IC，如此可减轻硬件设计的复杂度与工作量。
CPU 的选择对产品开发有着决定性影响，选择 CPU 时必须在性能、单价以及可用资源上取得平衡。基本上，工程师不必奢望会有性能远超过产品应用需求的CPU可用，这是嵌入式系统工程师的宿命！
■ 耗电流：开发 PC 或Web 应用程序时几乎不需考虑系统耗电的问题，但在许多产品应用上，尽量延长使用时间却是重要的规格或功能之一，手机是最容易明了的例子。要延长产品的使用时间，软硬件都要配合，硬件设计上除了使用更长效的充电电池之外，还必须花时间选用较省电的零件。为了在待机时可以尽可能的把没在动作的零件电源关闭，硬件设计时必须考虑到软件的需求，如选用CPU某根I/O脚来当作某个零件的电源开关。
■ 产品 Size 大小及外观：结构设计也可能影响硬件设计。同样功能的硬件零件要“摆”在开发初期用的大板子（Target Board）与最终产品的小板子（Real Size Board），在硬件设计的困难度并不是在同一个等级上的！其中牵涉到 Layout 走线以及为了抗干扰所增加的硬件设计。
图1-16所示有两张比较图，其机器具有完全相同的电路设计，但因为最终产品外观结构不同，其中一台机器必须分为两块板子，就硬件设计而言，其复杂度自然较高。
■ 销售国家或地区：每个国家或区域对电子产品上市前要通过的检查标准都不同，简单地说，同样类型的产品，销售某些非洲国家和销售美国、欧洲、日本等已开发国家就可能采用不同的硬件设计（这样说并没有任何轻视非洲国家的意思）。往往硬件设计为了提升一点性能必须付出极大的代价，例如，CA认证标准要求产品的抗静电能力必须达到某个等级，但有些廉价的芯片抗静电能力就很差，要解决这个问题，要不就得加抗静电电路、修改结构或加铜箔保护，否则就只能更换主控芯片，除了成本增加外，也可能影响其他部分的硬件设计。
■ 工厂制造与备料能力：这是一个常被项目经理或工程师忽略的因素，硬件工程师设计出来的东西，最终当然希望顺利大量生产，但选中的工厂却不见得有生产这些产品的能力。工厂并不是只有组装而已，同样以手机的例子来说，要验证生产在线手机半成品的通信功能需要昂贵的仪器，并非每间工厂都负担得起。此外，有时选择零件还必须考虑工厂的库存与备料的能力，所以硬件设计初期，最好就能和工厂人员确认设计是否可行。例如，这个产品要用到某个型号的 Flash Memory（闪存），在设计定案之前，应该先了解工厂是否有烧录该 Flash 的能力（如支持该 Flash 的烧录器）。
1-4-5 软件系统设计的限制
嵌入式系统开发在软件上的限制显而易见，许多工作项目在一般软件开发项目上都是没有的，而本书大半的篇幅便是试图说明面对这个现实的因应之道，在此我们先列举如下。
■ 不熟悉的CPU与硬件平台
■ 不熟悉的开发环境
■ 不易调试
■ CPU计算能力限制
■ 内存容量限制
■ 在不稳定的硬件平台上进行驱动程序开发
■ 电源管理程序
■ 工厂验证专用软件开发
■ 嵌入式操作系统开发
■ 仿真器开发
■ 软硬件整合测试
■ 稳定度与性能调整
■ CodeSize调整
细节会在之后的章节陆续提到，本节仅用一个例子来说明嵌入式系统软件开发的“艰苦卓绝”。
在个人计算机CPU已迈入64 位的时代，工作频率超过3 GHz，还可以多核心，内存容量从GB等级起跳，请想想，你可以用8 bit、2 MHz的CPU来做什么？
答案是任天堂电视游戏机（红白机），虽然这已是老古董了，且效果当然比不上 PS2[12]、PS3、Wii、Xbox 360 等，但当你知道它的CPU是8 bit、1.77 MHz 时，是否也对开发这个系统以及许多爱不释手游戏的软件工程师怀有钦佩之意？这是个20多年前的产品，当时许多软件技术都不如今日发达，他们是怎么做到的？即便其下一代主机“超级任天堂”的CPU也仅仅是16 Bit、3.68 MHz！
千万不要以为8 bit CPU的时代已经过去了，据统计，微控制器厂商（MCU）在产品布局是以8位微控制器为主力，其次为16位，主要锁定消费性应用市场。目前仍以8位微控制器的市场最大，就最典型的8位8051架构微控制器而言，全球一年的出货量就高达33亿个。这个数量已经明显大过个人计算机CPU的需求！
2001年嵌入式系统国际会议年会Jim Turley的报告中提到：根据统计报告，PC的数量只占CPU总销售量的0.1%，而且直到可预见的未来，这个悬殊的比例都不会有太大的改变。这就是嵌入式系统开发的业界生态——绝大部分的电子产品制造商，正使用着不为人所熟知的CPU，开发围绕你我生活的各种电子产品。
这也是嵌入式系统软件工程师的宿命之一，他们的价值不在于用过许多CPU，写过很多驱动程序，或开发过很多产品，而在于处处限制的情况下把产品开发出来，这意味着清晰的计算机系统概念、高效能的算法、良好的程序写作习惯以及有效率的资源管理。
PM：“请进！这是我们的实验室，该有的设备一应俱全，以后你应该会常常待在这里，这是示波器，如图1-17所示，在学校用过吗？那边拉了一堆线到板子上的是逻辑分析仪。”
菜鸟：“上实习课时曾经看过，但好像和你们的不一样，学校的仪器都很旧。哇！你们的还是彩色的！”
PM：“就是没用过啰！无妨，这很简单，以后我们会教你使用的。还有，你看一下，这是我们目前产品的电路图[13]，如图1-18所示。”
菜鸟：“好像很复杂，我一看这个东西就头大，密密麻麻的谁看得懂？我除了要用这些测量仪器外，也需要会看原理图？”
PM：“是啊！不然你怎么写驱动程序？”
菜鸟：“不懂！我之前用过微软的DDK写过一个USB设备的驱动程序，也没用过这些东西啊。”
PM：“应该这么说，驱动程序也是分种类与层次的。我来谈谈你在Microsoft DDK 上做的驱动程序，首先已经确认硬件是OK的，再来基于微软已经成熟的驱动程序平台来开发。而嵌入式系统工程师在开发驱动程序的状况通常是从无到有的，更不好的消息是，开发初期硬件设计还没确定，我们的固件工程师通常还要协同硬件工程师一起帮硬件板子调试。在这样的状况下，你不测量信号，怎么知道LCD的Framerate（如图1-19所示）是否符合日本市场的70Hz要求？怎么知道键盘的反应Timing是对的？怎么知道某个芯片的电源开关已经打开，并已开始运行？除此之外，有时还必须同时测量多个信号间的关系，特别是在调试的时候，如图1-20所示。
测量信号可以让固件工程师知道目前硬件的状况，写一堆驱动程序的目的不就是为了驱动并控制硬件吗？不会有人这么优秀或运气那么好，程序写完，一执行就OK了，如果你要调试，怎么可能自己不去测量信号？总不可能要我派个硬件工程师给你当助手吧！”
菜鸟：“嗯，我可以理解用示波器测量信号确实是固件工程师必备的技能之一，那原理图呢？”
PM：“你不看原理图，怎么知道要测哪里，而且我是说固件工程师必须会‘看’原理图，我可不放心让你来‘设计’原理图，电路设计是硬件工程师的工作。嵌入式系统开发工程师必须“多才多艺”的另一个原因，是为了提升自己的工作效率，项目中其他人都很忙，我们不希望软件工程师遇到了简单的硬件问题就停下来等待硬件工程师的帮忙。而且你看，那位在改驱动程序的是位硬件工程师，而那位软件工程师居然也学会了拆换芯片。
年轻人多学一点有好无坏，久而久之，你会更了解这个业界的生态，而不是只懂软件或写程序的事情，懂吗？”
菜鸟：“我很有兴趣学习新的知识，也愿意接受挑战，但还是有点怕……”
PM：“我已经说过很多次了，别担心，我们会培训你的。以下是我认为要成为一个优秀的嵌入式系统软件开发者所必须具备的基本职业技能。”
■ 要会写程序，尤其是C语言，而且程序必须精简有效率
■ 数据结构与算法
■ 完全了解计算机系统的运行方式
■ 操作系统的概念
■ 懂得系统的整个架构，包含电源管理等
■ 必须了解硬件设计的精神与架构，要能看得懂原理图
■ 基本测量仪器（电表、示波器等）
笔者遇到过许多博学多闻，看起来什么都懂的高手，其中有位高手令人印象深刻。他主要的工作是设计 CPU，当该 CPU准备推广上市前，他会帮忙设计评估板（或实验板）的原理图[14]，如果有空的话，他也会自己布局评估板线路，当评估板洗回来后，他会亲自验证，焊零件也都自己来，接下来还要写程序验证。他们公司提供给客户的评估板和示例代码都出自他一人之手，而他居然还是 CPU 的设计者！等到实际深交之后，才讶然发现他并非信息电机本科毕业生，本身是数学系毕业，在当了一段时间的中学老师后，才“转战”到信息界。
笔者提这个例子并非鼓励你要做一个通才，其实就在某个领域内出类拔萃也很好，毕竟这是一个精细分工的世界。笔者要点出的是，知识工作者必须放开心胸，只要是对工作或者对达成任务有帮助的，软件工程师不要排斥去学硬件的知识或技能，硬件设计者亦然。笔者常常听到这样的对话。
硬件工程师：“我觉得你们会写程序好厉害，想要什么功能改一下就好，那么复杂的程序是怎么写出来的？”
软件工程师：“我觉得你们可以做出一台实体的机器才厉害，什么电阻、电容的，我一个都搞不懂，那个原理图密密麻麻比我们程序复杂多了！”
笔者会给这两位嵌入式系统开发工程师一人一句建议：
软件工程师硬起来！
硬件工程师软下去！
菜鸟：“谢谢您今天的介绍，让我对嵌入式系统有了更深一层的了解，并对这份工作可习得的技能以及将面对的挑战有了更深的期待，但我还是不清楚自己的工作内容是什么，可以请您说得更具体一点吗？”
PM：“有两份工作让你选，一个是AP（应用程序）组那里缺人，另一个是我需要一个助手。前者的工作性质是根据制定好的设计规格，在仿真器上开发应用程序，如果没出大问题的话，基本上都是在 PC 上写程序与调试。后者以军事术语来说的话就是预备队与传令兵，哪里需要帮忙就补上，此外，可能要常常听我啰嗦几句。
你要选哪个？”
对一个初出社会的本科毕业生而言，职业生涯规划不外乎3种选项：
■ 技术深耕
■ 纵观全局
■ 缺乏规划
除了第三个选项外，笔者以为要往“技术超人”或“项目管理”方向努力迈进并没有绝对的对错，但最好先审视个人的专长和个性。重点是项目管理者最好是经历过一定程度的技术训练，而工程师也不可以永远只停留在自己熟悉的领域里闭门造车，对产品的开发流程必须要有概念。
特别是嵌入式系统的开发工作，专业领域之广、开发限制之多、牵涉单位之复杂是其他软件项目比不上的，而且要求上至项目经理，下至基层工程师都要对全局有所了解。想要加入这行的你，务必先做好心理建设，敞开心胸接受各式各样的任务，例如，以固件开发人员的身份参与硬件设计审查会议，拿起烙铁、焊锡、电表以及示波器探棒检修板子，参与测试项目（Testing Case）的制定，解决仿真器正常但机器不正常的 bug，甚至进工厂分析生产线出现的错误等。
当然，不见得任何嵌入式系统研发单位都可以让每位工程师触碰到所有的技术，特别是在人力充足、建臵完整的单位，每个人的定位都是固定的。笔者曾经面试一位在手机制造大厂工作的应征者，他已是一位小主管，想要换工作的原因是：三年来他的工作内容只有一个——“手机窗口应用程序开发”，做了不知多少机种，随着时间流逝，他已然是这个小领域里的专家，但他对自己的能力越来越感到心虚，他觉得他和外界的发展脱节了，甚至他经手的机种从何而来、客户是谁、什么时候量产，以及最后销售成绩如何似乎都不关他的事。
笔者对新加入者的建议是：切记要做一位工程师（Engineer or Program Designer），而不仅是一位程序工人（Code Typist）。工程师除了具有创新、设计与整合的能力外，还必须具备纵观全局的视野，以及具有独立解决问题的能力与担当，而所谓的程序工人则仅需听命行事，照着设计规格写程序，虽然工作性质包装着“高科技”的外衣，但实质工作内容与一般付出劳力的工人没有两样。
而且工人的工作较不具发展性且容易被取代，工程师则不然！
注 释
[1]. 请注意，文中提到的是“信息电子公司”而非“软件公司”，至于职务则是“研发工程师”而非“软件工程师”，如果可以的话，称之为“电子产品设计公司”的“嵌入式系统开发工程师”应该更能表达其工作性质。
[2]. 一般企业往往弄不清项目经理与部门经理（例如软件研发团队经理）的职责界限（本书在项目管理相关章节会对此详细说明）
[3]. 除了人力之外，所谓研发资源泛指时间、能力、预算与老板的支持等。
[4]. “多才多艺”其实是来自于以下两种人格特质：吸收新知识的求知欲与速度，以及解决问题的能力与态度。
[5]. 可上中文维基百科（http://zh.wikipedia.org/）搜寻“嵌入式系统”，笔者认为其中有许多有用的信息。
[6]. 原始定义中并没有“Specialized”这个形容词，但随着 IC 设计与半导体制造的进步，市面上已有无数的特定用途CPU可供选择。若有必要，你也很容易找到帮您量身定做主控IC的厂商。
[9]. 可参考《第16章：SoC 设计公司中嵌入式系统团队的管理》。
[10]. 除了技术问题外，更重要的是产品设计的出发点是否真的是以满足客户需求为主？《附录 D：电子产品设计的最终依据：用户体验》对此有深入的阐述。
[11]. 制定规格的人应重视制造成本给嵌入式系统开发带来的限制，否则，不但会为该项目带来灾难，而且对第一线的开发人员也是不道德的。
[12]. PS2 与任天堂64 这两台游戏主机都是使用MIPSRISC 架构，运算能力当然比任天堂红白机好得多，但性能与PC 上的CPU还是有一大段差距。
[13]. 这里只是 show一下原理图，你无须花时间了解这张图的实际内容与应用。
[14]. 硬件电路设计和CPU 设计是完全不同领域的两回事。
时间：02月01日
地点：培训教室
登场人物：菜鸟、系统老鸟、项目经理（PM）
菜鸟：“这将是我参加的第一个嵌入式系统开发项目，‘项目’这名词常听到，但‘项目’到底是什么？我现在有两个老板，一位是研发部的软件部门经理，另一位就是您——项目经理了，同样是经理，你们的职责有什么不同？说白一点，研发部经理和项目经理哪位比较大啊？如果你们同时下命令给我，我到底应该听谁的？”
PM：“对工作资历不深的工程师，几乎没有人觉得他应该要了解项目管理的知识，更不要说你这刚进社会的菜鸟了。一来是他们认为学习‘专业’知识都来不及了，哪有空再去学项目管理？再则就是一般工程人员普遍认为项目管理没有什么难的，再难也不会比TCP/IP协议复杂吧！等需要时再学就是了。
个人认为这种观念影响企业界很深，所以每当项目中有新人参与，我都会开一堂叫做‘嵌入式项目管理入门’的课，不管你是主管还是菜鸟，只要参与我的项目，我就会要求你们必须符合项目管理的精神来做事。看来这个项目还是不能偷懒，我就专门为你这菜鸟再讲授一次这个课程吧！”
菜鸟：“不是说这是专为‘本菜鸟’开设的项目管理课程吗？怎么其他项目人员也都来了？特别是学长，你都贵为老鸟了，怎么还来上这个课程？”
系统老鸟：“公司的教育培训就是这样，明明是专为某些人开设的课，真正有需求的人反而不来上。项目管理是很有意义的课啊！以我们PM老大的丰富经历，经常会信手拈来许多实例，我每次听这堂课都会有不同的收获。
公司的技术主管还算支持PM老大的想法，知道他要开课，就要求其他项目人员也来了。不管他们现在是抱着什么样的心态来听这堂课，当有一天他们真正碰到问题时，能够想起好像曾经听过有个概念或工具可以解决当前困境，那么，这堂课就值得了。”
菜鸟：“我的确没想那么多，老板叫我来上我就来了。我，小小工程师一个，真的需要现在就了解项目管理的思想吗？管理耶～等我爬到主管位置都不知道是猴年马月的事了！”
系统老鸟：“你的想法其实是错的！首先，项目管理的思想可以应用到所有公司或私人的大小工作上，项目管理教导我们：任何工作都应该先评估可行性，接着作计划，然后有效率地利用时间、成本与资源，并在可接受的范围内管控成果的质量。没有人不希望高效率的完成各项工作吧？
而且项目管理不仅仅只是项目经理的工作，一个电子产品开发项目牵涉到那么多单位，相关技术或执行细节如此繁杂，项目经理怎么有办法全盘管控？所以管理与开发工作必须层层把关，就算你只是个工程师，在此项目中只负责某一个模块的开发，当你接到这个任务时，也要把它当作一个小型项目来执行，同样要有计划、要做管控。而你就是这个小型项目的项目经理，必须要用有效的办法来完成这个模块开发。
因此，整个项目在执行时将会是一个‘递归’的概念，一个项目其实是由许多中/小型的项目所组成，所有项目成员必须以共同的理念做事，使用相同的语言沟通，自然项目的成功率就会高很多。
此外，身为一位工程师要随时为提高自己的管理能力作准备。信息电子业人员的流动率高，千万不要当你突然晋升为管理数人的小组长时才手忙脚乱。事实上，大部分的技术团队主管都还是由技术人员提上来的，出来工作打拼千万不要妄自菲薄。年轻人！要立大志！”
菜鸟：“你说的我会好好思考，上完这堂课，知道项目管理到底是什么之后，或许会对你的话有更深一层的理解吧！老板来了，准备上课啰！”
课程名称：嵌入式项目管理入门——所有参与项目成员都必须知道的项目管理知识
课程时数3小时
PM：“首先感谢大家抽空来上这堂课。项目管理目的在于建立一套知识体系，提供高效完成项目的流程指导。任何性质的工作都可以是一个项目，所以，学习项目管理最重要的还是思想！这门课当然无法在短时间内解说所有项目管理的细节，但今天的教材是基于我多年的项目管理经验，体现个人认为所有项目成员都必须知道的项目管理思想、流程与工具，并适时提示嵌入式系统开发项目应该注意的地方。
这门课的副标题为‘所有参与项目成员都必须知道的项目管理知识’，也就是说，我所设定的目标对象并不仅仅只是项目管理者。如果你被指派加入某个项目，我希望你能认真地从这个简报里学到一些正确的思想，以后就能用更有效率的方式工作，相信对你日后的职业生涯也会有很大的帮助。
首先，我们来看关于项目一些‘不能说的秘密’。
2-2-1 何谓项目
当企业想要培养具备某种技术专长，且可为公司所用的人才时，必须经过长时间、计划性的培训。例如，当公司给你一个之前从未做过的开发任务时，一定会给你时间自我学习，或采用师徒制（找个师父带着你在工作中学习），甚至是直接送你去外部的教育培训中心上相关课程（培训）等。
然而，电子产业的项目经理通常都由技术人员直接晋升，大部分的项目经理在就任之前，多半是位兢兢业业、优秀且精干的工程师！通常直到被升任为负责某项目的项目经理之前，都未受过完整的‘项目管理’培训。
照理说，不胜任的项目经理对项目的‘危害’，远远超过一位工程师的影响，而企业花了这么多的时间与金钱，将工程师培养为技术专家之后，居然是为了指派他去做不熟悉的‘管理’工作？这真的是十分奇怪的现象！正因为大部分的项目经理都是这么产生的，因此，管理不善往往成为大部分项目延误、超支，甚至失败的主要原因。
领导与管理是截然不同的概念，领导或许需要天份，也需要实际的战绩来服人，但管理的技巧与思想绝对是可以学到的，而项目管理更是一门成熟且已有无数实践实例的知识体系，项目的思想也已广为电子产品开发行业所接受，无论你将来是要开发手机、网络设备、玩具、家电等，你都曾是某项嵌入式系统开发项目中的成员。
现在，你还会觉得项目管理的思想与工具对你来说不重要吗？
大部分的人身处于项目之中，却不见得真的了解‘项目’到底是什么。以下我们就来了解项目的定义。
项目的特性如同幻灯片所述，有明确的开始与结束时间，且每个项目都是独一无二的。例如：工厂生产线上完成每项成品组装的过程并不算是项目，但设计组装流程，并尽可能精简步骤的过程，则可以使用项目的思想来执行。
在嵌入式系统项目中，软件开发所占比重很大，相对于其他种类的项目，软件项目有其特殊性。举例来说，建筑业有很明确的工序与材料选择规范，只要按照规范来做，项目质量就得以确保，则失败的可能较小。但软件开发只有软件工程这套开发‘原则’，且软件质量水平很难加以量化，使得软件项目管理难度大增。
嵌入式系统开发还牵涉到硬件及诸多限制，就算同所有软件项目的种类相比，说嵌入式系统是最复杂的都不为过。稍后我们会提到软件估价与复杂度评估，在所有评估方法中，都把嵌入式系统的复杂度设为最高。简而言之，嵌入式系统里一行程序的‘价格’，往往高于其他种类的软件项目。
在座各位都是从事嵌入式系统开发的，对嵌入式系统项目的特性，以及开发时可能会遇到的限制等，应该都有深刻的体会，在此我就不再赘述了[1]。
项目管理试图规范‘任何符合项目定义工作’的执行流程，以增加项目成功的机率，而软件开发也是一种项目，自然可以运用项目管理的知识加以管理，项目管理与软件工程是两套独立的知识体系，我们在开发软件时也必须按照软件工程的精神来执行，但实际上，两者的规范是否有所冲突呢？
答案是否定的。两者的基本思想其实是完全相同，都是将项目的执行流程定义为‘规划→执行→控制’的循环，只是软件工程会针对软件开发的特性，而发展出特有的思想与工具[2]。
美国PMI（Project Management Institute，项目管理协会）收集来自世界许多项目运行的实例，并分析与归纳出一套目前广为接受的项目管理知识体系。我们现在的课程内容基本上都是以这套知识体系为出发点。但刚刚说过，每件项目都有其独特性，不可能有完美的流程可完全套用在所有的项目上，所以在讲解项目管理的知识体系时，首重思想与应用，而非其中的条文。
一般人对嵌入式系统项目有两个最大的误解：
■ 项目经理必须是位软硬件全才，只会出张嘴的项目经理无法带领项目成功。嵌入式系统项目牵涉的领域非常广泛，项目经理居中协调、review都已经没时间了，怎么还会有空去写code？如果你项目中的PM每天埋头写code，他其实是想要掩饰自己在管理与沟通上的无力感。项目中的每位成员都有其重要使命，有的人是写程序、有的人是硬件设计，而项目经理的任务之一就是按照计划进行沟通协调，每个人都应该先把自己分内的工作做好，才能去帮助其他人，这个道理我想大家应该都知道吧！话说回来，身为嵌入式系统的项目经理，想要做好沟通协调，自然不能什么技术都不懂，否则，很容易就会被项目成员所蒙蔽。
■ 只要经过不断的测试，就能够保证产品的质量。这已经是上世纪中叶的旧观念了，认为只要先把东西做出来，然后不断测试与debug，只要测试人员够精干，迟早可以把所有问题都找出来并解决。但现代产品的复杂度远比当时高出不知多少，且软件复杂度更是指数级的倍增，只靠事后测试是无法保证产品质量的。
现代的思想是：质量是规划出来的。特别是软件系统，若项目前期的设计工作做得扎实，执行时期不断监控，自然测试时期的bug就会较少，且修改bug的投入也较小！
2-2-2 何谓项目经理
在了解项目的定义之后，接下来，我将和各位介绍项目经理的职责。
目前的企业普遍采用矩阵型组织，在座的工程师们，你们在组织中会有一位直属老板（Functional Manager）。例如：软件部门课长、硬件部门经理等，当工程师被指派参与某个项目时，在项目运行期间，项目经理则是你另一位老板。在组织中，项目经理的角色其实有点尴尬，他并非项目成员的直属上司，但却要带领所有项目成员完成项目，而这正是幻灯片中‘责任大于权力’的意思。
因此，项目经理必须具备极佳的沟通技巧，让工程师的直属上司愿意支持此项目，使得项目成员可以更专注在此项目上。
项目和一般研发团队的运行有着本质上的差异，前者是要在限期内完成指定目标，而后者则是根据既定的长期发展计划前进。因此，主事者需要的管理风格与人格特质也不尽相同。一般而言，项目运行的节奏较快，项目经理必须强迫自己，从老板到客户的诸多信息中去挖掘并定义出项目的目标，在项目执行阶段，必须能心平气和应付所有突发事件的袭击[3]。
项目在不同阶段会有不同的特性，因此，项目经理在项目的不同阶段，必须适时做角色变换。
■ 项目初期：目标尚未确定，项目团队也刚组成，成员彼此间默契不足。此时，项目经理必须主动明快的制订决策，并积极地指派工作。越是混沌不明的状况，领导者越是需要花更多的精力带领所有人找出正确的方向。
■ 项目目标已确认：紧接着就是拟定计划。项目计划为项目的蓝图，对项目成败影响甚大，由于项目经理是最了解项目目标的人，因此，项目经理一定要全程参与计划拟定，必要时指引方向并协调纷争。
■ 项目计划已定案：项目经理的主要工作转变为监督项目执行，随时检验查看实际的项目进度是否与计划有落差，执行风险管控与变更管理，并主动提供工程人员需要的协助与资源。
■ 项目后期：项目团队的技术能力已成长到能够完成计划，且团队成员间的默契也已形成，此阶段项目经理只需管控进度，放手让项目成员发挥。
2-2-3 项目管理的基本概念
某项目会被启动的背景并不一定，有的是经过长期的评估，有的只是两家公司老板在酒酣耳热下随口敲定。经常项目经理在被指派新项目时，连具体目标是什么都不清楚。例如，客户可能说：‘开发一台像iPod Nano 的MP3 随身听，最好可以支持所有的音乐格式，希望圣诞节或农历春节前可以上市’。此时项目经理的老板会说：‘去告诉每个研发团队的经理，全力支持这个项目，请他们提供所有你需要的资源——好好干！这个项目别再delay了。’
客户的规格说得不清不楚，老板的指令下得模模糊糊，项目经理在设法理清项目规格的同时，还要协调各单位，以取得项目运行所需的资源（人与钱）。除此之外，项目经理还必须将所有与此项目有关的人连接起来，否则，这些关系人是不会主动投注心力在这个新项目上的。
在执行项目时，最常听到的一句话是：‘计划赶不上变化，变化赶不上老板的一句话’。所谓计划是对未来事物的规划，确实没有人能够完美地预知未来，因此，执行计划本来就是一个不断对计划进行微调，使之与实际状况吻合的过程，而且在拟定计划的过程中，能让项目成员对项目的目标与可能发生的问题有更深入的思考与分析，也就是说，即使无法制定出完美的计划，我们仍必须认真地将项目计划做出来。
在项目管理知识体系中，有许多工具与方法可以在执行阶段缩小计划与实际状况误差，稍后我们会陆续谈到。
相信大家对PDCA（Plan→Do→Check→Act）应该都不陌生吧！老板们总是将PDCA挂在嘴边，但请大家不要因此而认为PDCA只是个打官腔、不实用的论调。相反地，我希望各位在执行项目、开发软件，甚至进行任何工作时，都要切记这4个英文字母。
即便是天纵英明的神人，面对没做过或不熟练的工作时，也很难一次就把事情做对，都是一边做、一边检查、一边改善，直到做对为止。项目管理与软件工程的基本思想都是 PDCA，整个项目要 PDCA，某个模块的开发要 PDCA，系统的测试工作也要 PDCA。放大来看，项目从大到小的所有事情，都需要PDCA！
PDCA 是一种做事的方法与态度，我希望在座各位都能掌握其精髓，这对各位在职场与私人生活中都会有很大的帮助。
幻灯片里的图称为项目管理的铁三角，但我比较喜欢‘质能守恒’这个说法——意即人力、时间及其他资源不可能被无限制地压榨出来。
举例来说，某件项目计划表明需要5个人、花费10万元、限期两个月、通过日系大厂的质量检验，当项目运行到一半时，在其他条件都不变更的前提下，客户希望项目能够提前一个月完成。
根据项目铁三角的原理，当你要缩短三角形的某一边，又要保持三角形的面积不变，则势必有另一个边或另两个边的边长必须加长。也就是说，根据拟定好的计划，如果必须缩短执行时间，要不增加成本或人力，要不减少或简化产品功能，不然，就只能降低质量的要求。否则只有一种可能－之前所拟定的计划肯定大有问题，要不是灌水灌得太严重，就是太过低估工程人员的能力。
在项目管理理论中有谈到为项目计划‘灌水’的原则[4]，以降低项目失败的风险，但等到执行时期才来大幅修改某些项目属性，却要不更动其他属性是完全不可能的。此时必须启动变更管制系统，否则计划表只会变成废纸一张，之后该项目的执行将完全失去准则、进度完全无法追踪。
因此，做好变更管理将是PM非常重要的工作，变更是一定会发生的，如何有效地管理变更是很重要的一门学问。
根据统计，85%的项目是在超过时间、未达质量标准、耗用过多资源的状况下完成，这也说明要让一个项目顺利结项并非易事，而要成功完成一个项目更显困难。根据我个人的经验，若三角形的三边（质量/规格、成本、进度）在一开始时没有构想清楚，过程中也没有做好变更管理的话，通常最后都会让项目成员之间弄得很不愉快，为了赶付交期，而牺牲质量，可能要求员工加班，进而垫高成本。
在进入项目管理知识的细节之前，我必须先强调一项重点——项目管理知识体系并未要求所有项目必须全盘导入它所提供的工具，重点还是放在思想的传达上。
但以我管理项目多年的经验，仍然认为有许多工具应该是必备的，例如：
■ 一件项目是否能为公司赚到钱？是否会让团队陷入无法结项的泥沼？该不该启动一个项目必须经过严谨的评估，有个方法叫做SWOT[5]。
■ 要解决项目经理‘责多于权’所导致的问题，老板在项目启动时千万别忘了颁发‘项目的圣旨’——项目授权书。
■ 弄清楚项目的规格后，接着要细分工作，并为细部工作进行排序与设定进度……这一系列工作是拟定项目计划时的重要流程。项目管理知识体系提供了许多实用的工具与方法，其中的WBS可说是项目计划的基石，关键路径则是控制项目进度时最重要的信息。
■ 我们刚刚在‘无意间’已经讲了不少关于变更管理的重要性，但它偏偏是常被项目经理忽略的一项工具。
在座的各位应该都曾经参加过一项或一项以上的项目，请问你们的项目里有这些东西吗？如果没有，我可以直接地说，这些项目并非用最佳的方式在执行，一定还有改善的空间！接下来的课程内容都会提到这些重要的工具及思想，麻烦你们带回各自的项目中。
项目管理知识体系统合了不少在管理学里已证明有效的工具，例如：幻灯片中提到的‘挣值管理’或激励理论，并非所有项目都必须导入这些工具才能成功，但他山之石，可以攻玉，既然已经有一套完整的项目管理知识体系摆在那里，我们这些靠执行电子产品开发项目过日子的人，就算无法应用它所有的工具，至少也要学得正确的思想。
项目管理不像软件工程有那么多不同的学派，不同体系间的差距并不大。我们接下来讲的内容是基于美国项目管理协会（PMI）制定的知识体系，是目前全世界最多人学习的项目管理知识，权威性与可执行性毋庸置疑。
我们前面讲过项目的定义，特别谈到每件项目都是独一无二的，都有各自的目标、可应用的资源、必须面对的限制与风险等。但所谓的知识体系就是要设法异中求同，通过分析与比较足够数量且不同种类的案例，试图归纳出适用于所有项目的思想与方法。
这么做并不牵强，因为不同项目间确实具有共同的特性，可以使用相同的思想与方法论来执行，就如同我们的本行——嵌入式系统与电子产品开发，如果不能在不同的项目间秉持共通的概念，工程人员免不了要多走很多冤枉路，其职业生涯将会非常辛苦！
2-3-1 项目管理知识体系
PMI制定的项目管理体系称为PMBOK（Project Management Body of Knowledge），其举办的全球性项目管理知识认证考试则称为PMP。市面上有许多相关参考书籍，建议各位可以花时间找一本来研读。在此，我并非建议各位一定要取得PMP认证，但PMP考试以实际题居多，在做模拟试题的过程中，可以让你进入一项又一项不同项目的实境里。如果你是一位项目成员，如何在各个阶段协助项目成功？如果你是一位项目经理，碰到各式各样的状况时该如何处理？
建议只要买本PMP模拟试题与讲解的书籍即可，我个人认为这真的是很难得的管理培训，自我研读也未尝不可，因为管理的事本来就没有绝对的对错，只要能引发思考都是有益的。在座的各位总不会希望当自己到四五十岁时还在做工程师吧？就算你们想当一辈子的工程师，也要考虑现实环境，毕竟在中国，很少有企业愿意花高薪聘请一个资深的工程师。
所以，我亲爱的同事们，务必要抽空研读一些管理书籍，相信对各位的职业生涯会有很大的帮助！
任何一件项目都必须经过以下5个阶段。
■ 启动阶段
■ 规划阶段
■ 执行阶段
■ 监控阶段
■ 结项阶段
一般人都会直觉地将项目切分为这5项步骤，各位会发现，其实软件开发也是按照这样的流程，重点在于每一个阶段要做好哪些工作，才能保证下一个阶段可顺利的运行？幻灯片中的这张流程图乃归纳自 PMBOK 的各个章节，各位可以从这张图看出项目生命周期间。除了Implementation外，到底还有哪些必要的管理工作？而这些工作存在目的只有一个，即为了增加项目成功的几率。
请各位先对幻灯片中的每项Item稍具概念即可，我们稍后会陆续提到。
2-3-2 项目生命周期
同样重要的，还有项目生命周期的5个步骤。
■ 启动阶段必须保证执行这个项目确实是有意义的，并赋予项目经理足够的资源与权力。
■ 规划阶段的成果是‘项目执行计划’，过程中必须对项目的诸多特性（包含规格、进度、成本、质量需求、资源调配、沟通管理、风险管控及配置配置）做深入的分析。
■ 执行阶段必须保持严谨，工程人员根据项目执行计划按章行事。当计划与实际状况出现落差，或因不可抗拒的因素必须修改项目规格时，则必须启动变更管控流程，更新项目执行计划——使得工程人员始终按照最新的计划来执行即可。
■ 监控阶段则是在执行阶段，随时检查项目执行状况与既定计划是否即将或已出现落差，最好能够提前发出警示，以实时启动变更或风险管控流程。
■ 结项的目的是为了累积企业资产，以供以后项目参考，照理来说，这是相当有意义的工作，但实际上却往往最常被忽略（到项目后期，许多项目成员已功成身退，剩下的势必也正在另觅新项目。因此，必须在项目执行阶段即通过许多自动化工具，不断地收集与整理项目资料，使结项时期的投入越小越好）。
若要我说项目生命周期中5个步骤最重要的是哪一个？工程师可能就想着执行阶段，但我会认为是规划阶段。整个PMP知识体系里，大部分的篇幅都在说明如何造出合理的计划，而我今天也会花最多时间在规划阶段上。这个道理非常简单，事前想得越清楚，执行的变量也越少，成功的机会自然而然便可提高。
等哪一天我有机会当上企业的老板，也许我会转而认为结项才是最重要的阶段。
项目在不同阶段会有不同的特性，因此，必须视项目所属阶段，采取不同的态度，并在不同之处投入不同的人力及关注，这点相当重要！虽然项目的5个阶段并没有明显的界线，但项目经理有责任让所有项目成员随时都知道目前项目正处于什么阶段。千万不要在规划阶段忙着写code，在执行阶段又不按照计划来执行；又或者监督阶段太晚启动，review活动不够积极，等到问题爆发时已无可挽回！
2-3-3 项目启动阶段
接下来我将遵循着项目生命周期的5个阶段，逐一说明各阶段的思想以及可使用的工具。一天的课程当然无法将细节全都说清楚，希望各位在今天的课程能够尽量将PMP的思想纳为己用，知道有工具可实际应用，等日后有需要时再去查询即可。
企业以营利为目的，除非有其他Business上的考虑（例如，为了与重要伙伴建立关系，即使赔钱都要做），否则，不赚钱的项目不应该接。此外，小虾米团队也不该妄想吃下大鲸鱼的项目。如此看来，某个项目到底该不该做确实是跟企业的利益息息相关，所以项目不应该说启动就可以启动的，必须经过严密的可行性分析。
可惜的是，大部分项目都过于忽视这个步骤，通常会直接跳过量化的分析，由高层或资深工程人员使用直觉与经验来决定是否启动。但我们说过，每件项目的特性都不同，即便是规格完全相同的产品，但面对不同的客户，可能会有截然不同的执行结果。
就算是老板和客户已决定要做的项目，当我被assign来执行这个项目，还是会找必要的工程人员执行可行性分析。分析工作的深入程度，根据项目复杂度与规格是否明确而定，规格越不明确的项目，越是需要做更深入的分析，在分析过程中顺势尽可能逼客户提供明确的规格。一旦分析结果风险极大，必须及早警示老板，即便老板还是执意要做，也能尽可能在项目启动前取得更多的资源，或设法让客户在规格上让步。
在项目启动阶段还有两件重要的事：
■ 理清项目关系人。要分清楚只是纯粹感兴趣的人，以及实际具有影响力的人。
■ 老板颁布项目授权书，并正式kick-off。
通常项目经理在没执行项目的空档时，麾下是没有团队可供调度的，所以当公司决定启动某项目时，老板必须正式授权给项目经理，让他可以申请经费与调动人力，最佳的方式就是老板‘颁布圣旨’——即项目授权书，白纸黑字说明项目目标，以及项目经理可以调动哪些公司资源。
通常在公司的组织章程中，并不会根据不同项目特性，明确各单位对项目的支持程度。因此，项目授权书就如同公司内部的行政命令，职位与法律相同，使得项目经理能够在授权书的范围内，‘合法’地取得资源。
我们公司就是一直碍于没有正式的项目授权书，搞得所有项目经理常常为了抢资源而搞得不愉快，部门主管也很难判断各个项目的优先级，使得本来可以‘依法行事’的，却因为缺少了老板这个举手之劳，项目经理最终还是得拉下自己的老脸到处要资源。
项目启动前后必然是混沌不清，充满了各种不确定。不确定的事情拖得越久，对项目影响越大，所以项目经理必须尽可能在项目前期就设法理清大部分的事情。以嵌入式系统项目来说，产品规格与成本限制是最重要的。同样是手机，智能型手机和一般手机所需的研发资源就大相迳庭！如果只知道‘大概’要做什么，前面谈到可行性分析的可信度，自然就会大打折扣。
再强调一次，越前期的决策错误，对项目成败的影响越大！项目启动阶段参与人员不需太多，最好是较有经验的人员，此时，项目经理要带头用谨慎的态度尽可能挖掘出该项目可能的变量与风险。
一旦确定要执行这个项目之后，接下来就是规划、执行及监控阶段，稍后我们会详细解说这3个阶段所需要的流程与思想。事实上，PMP大部分的重心都着重在这3个阶段。即便如此，我在此仍然要再次强调项目的启动与结项两者缺一不可，前者是确认此项目是否有执行的价值，并正式赋予项目经理应有的权力去执行此项目，而结项则是对此项目进行检讨，项目执行中的所有成果都应该转换成有用的组织资产。
在此我们先跳到项目结项阶段。
2-3-4 项目结项阶段
结项有两种，一种是对外部的合约结项，另一种是内部的项目结项。
一般项目都只知道要做合约结项，不是公司急着跟客户收尾款，就是我们的厂商要跟公司讨钱，因为这会牵涉到营利或是否违约的法律问题，所以到项目后期，无论团队再怎么疲惫，都一定会设法尽快将相关合约close掉。
我们前面已经谈过项目结项的重要性，但大部分的项目通常都没有正式的项目结项过程。状况好的，可能所有项目成员一起吃个饭就算结项；状况不好的，项目执行时团队间弄得不愉快，项目后期，大部分人（或明或暗）早就投入另一个新项目的怀抱了，更不可能有余力进行项目结项。
项目后期的普遍状况是：人员就算尚未作鸟兽散，但对此即将结束的项目也渐无心力，项目经理的影响力也急速缩减。这是业界的常事，甚至老板可能就是将人力提早抽到新项目的‘凶手’。在这个状况下，项目经理只能从两方面完成项目结项的工作：
■ 在项目执行期间，制定流程，并使用自动化工具，将项目开发的轨迹（包含程序、文件、bug管理、issue管理、变更管理等）记录下来，并定期备份。
■ 明确规定执行项目结项流程的起讫时间，最好不超过一周，并与项目成员的部门主管以及现任的项目经理沟通与协调，请这些同事们在某段时间内帮这个项目最后的忙，只要项目结项流程的时间明确，大部分主管与员工应该都会乐意帮忙。
项目结项除了整理项目执行期间的所有资料之外，最好还能聚集重要的项目相关人员，在轻松的气氛下，对此项目从头至尾进行检查，并留下宝贵记录。
2-3-5 项目管理九大知识体系
我们已经谈了项目生命周期的启动与结项阶段，接下来，将正式进入与工程人员有直接关系的规划、执行及监督阶段。这些阶段的工作可以画分为9大类，称为PMP的9大知识体系，其中与工程人员较有关系的则有7项：范围（Scope）、时间/进度（Time/Schedule）、成本（Cost）、质量（Quality）、人力资源（Human Resource）、沟通（Communication）和风险（Risk），这也是以下课程的重点。
刚刚我们已经强调了，必须尽量在项目初期排除不确定性，否则，越在项目前期犯的错误，对项目成败的影响就越大。在此我们看到了一个惊人的数据——68倍！前期的分析与规划工作做得越仔细，后期出现‘惊喜’的机会就越低。虽然所有人都了解这个道理，但往往都过份低估了项目独特性可能带来的影响。
有相关经验的工程人员，常会认为同质性高的项目没什么了不起，没必要做太多规划工作，做就对了！等到项目后期才发现，新项目和以前做过的项目还是有些差异，此时已完成的系统架构已经无法容纳这个差异，最后只能投入更多的时间或人力，进行架构性的改变。
这就是68倍的由来。过度轻视项目的困难度、走一步算一步的工作方式，最严重的往往是：根本不知道项目的真正目标（通常是自以为知道，但其实对细节完全不清楚），就直接往错误方向硬干，做越久，偏差越大，最后想要拉回来更是难上加难！
所以PMP知识体系告诉我们，当项目启动后，首先就是要花时间做好项目的范围管理，唯有定义出正确的范围（Scope），之后做的进度、成本和人力计划才是有意义的。
所谓项目范围除了包含该做的项目，也要弄清楚不该做的工作，两者同样重要。项目团队的人力、时间与预算都是有限的，没有理由对项目范围不加限制，任由工程师天马行空的按照自己的想法去做。在项目管理的思想中，这绝对是缺乏纪律的行为，称为镀金（Gold Plating）或范围蔓延（Scope Creep），这都是应该要尽力防止的事情。
从幻灯片的流程图中可以看出，需求分析也是个循序渐进、不断修正的工作，甚至经常发生已经到了项目执行阶段，客户才要求更动规格的事。此时，项目计划既已完成，就应该执行变更管理流程，在新计划中适时反应项目范围变化所带来的影响。
范围管理有两项重要的工具，一项是我们现在要谈的工作分解结构（Work Breakdown Structure，WBS），另一项则是变更管理。
在评估工作量时，有个人人皆知的简单概念：事情越大越复杂，越不容易估计准确。因为这样很容易就会忽略一些重要的细节，所以人们早就知道由繁化简的道理，并将其应用到项目范围管理中。简单来说，就是将一件复杂的工作，切割成许多较容易执行的小工作，假使这些小工作还是太复杂，就继续切割，并反复递归地执行这项分割工作，直到我们有把握评估每件小工作的特性为止。
举例来说，最初的项目范围可能只是一句话：开发一台多媒体播放器。谁也没办法由此精确估计出Schedule、Cost等项目特性，所以必须继续将开发工作切分为软件、硬件、结构、生产，然后再为每个项目继续分割，可能会得到：选择 MP3 译码 IC、系统架构设计、实现电源管理模块、准备备料计划等较可掌握的小型工作。
工作分割最终会长成一个树状结构，根（Root）为项目目标，树叶（Leaf）则为许多小工作，这个树状结构即称之为WBS。至于工作要切割到多细才合理呢？如果切割太细，则项目范围分析时难免会触碰到太多技术细节，一旦工作项目太多，会使得项目计划过于复杂，而且容易扼杀工程人员的创意空间；如果切割太粗，则项目计划就会有评估不准的风险。
对此 PMP给出了建议：WBS 最底层的工作（Leaf）要非常具体，不容模棱两可，而且至少必须切割到约一周或40个工作小时的工作量——这是一项经验值，这种工作量的工作，用于评估不至于产生太大的误差，且工程人员仍保有足够的发挥空间。
制定 WBS 是项目规划阶段最重要的工作，除了将项目目标切割为项目计划中的基本单位外，更重要的是，在制定 WBS 的过程中，我们可以过滤出所有规格、管理与技术上的盲点，并在项目初期尽快理清所有不明确之处。
就算从没听过PMP或WBS，一般人在解决问题时也都会自然地将其切割为许多小问题，然后逐一寻求解决方案。WBS的思想很靠直觉，大部分项目都知道要按此思想做事，但并未真正把WBS画出来。所谓没图没真相，我们就无法对WBS的合理性做严谨的review，而且在拟定计划时，很容易就会忽略某些工作项目。
记录WBS的方法有很多种，我会建议使用Microsoft Project来做（要用Excel来记录也无妨，但在制定项目计划时，还是得复制到项目管理工具上）。
WBS 有两种描述方式，一个是图表法（如幻灯片的左半部），优点是一目了然，但当项目工作较为复杂时，这样的图难免显得杂乱，且较难以工具进行处理。所以通常我们会用另外一描述方法——在纸上画出树状结构草稿，然后使用如幻灯片右半部的列表来做管理。
在进行任务分解时，由上至下的标准必须一致，否则，当项目较复杂时，很容易因为任务分割标准不一，导致任务重复。一般使用的任务分解方法如下。
■ 按照子功能分割
■ 按照系统架构
■ 按照项目生命周期
■ 参考以往类似性质的项目
初版WBS 完成后，一定要经过相当严谨的检查与公开review。再强调一次，如果 WBS有问题，之后进行的 Schedule、成本（Cost）、人力资源（Human Resource）等评估都会跟着出问题。
WBS其实就是项目的Scope Baseline（基线或基准），它除了描述本项目中所有必须执行的工作之外，同时也说明不在 WBS 中的工作，都是没必要执行的！有时候，后者反而是容易被忽略的思想，项目主管放任工程人员执行了半天似乎与本项目有关却不属于项目目标范围内的工作，这样的行为对项目来说都是非常不利的！
项目有一个重要的特性——必须先做‘对’，行有余力才做‘好’。嵌入式系统产品开发项目更是如此，客户要你做低价位的MP3播放器，你却做了一个可以播MP3的智能型手机给它，你说客户该哭还是该笑？
总之，WBS绝对是项目计划的基础，如果连要做什么都不知道，项目运行宛如瞎子摸象，要顺利结项只能靠老天保佑了。
接下来，我们将谈谈项目范围管理的第二项重点——变更管理[6]。
变更管理是在项目谈行阶段用来处理项目计划与实际状况有落差的情况。如幻灯片中的流程图所示，项目在执行时，追踪与监控工作必须同步运行，一旦发现计划与实际状况不符，或客户提出规格更改要求时，就必须提出变更需求。
在变更处理流程中，相关人会评估接受此变更的影响。还记得我们前面说的项目铁三角吗？某一边的更动，势必要影响其他的两个边。如果这个变更真的轻微到不会对项目其他的面造成影响，那我们也没必要为此担心。一旦某项变更会严重影响进度或需要增加成本，则必须所有关系人（例如：PM、公司高层、客户代表等）讨论同意后才能接受此变更，并将所造成的影响全部照实Update到计划书中。假使项目关系人无法接受变更带来的负面效果，就只能放弃此变更，或请工程人员另觅他法。
无论如何，我们不能放任一个已知的问题在项目中，而不去处理！
对项目来说，变更宛如万恶根源，是很负面的字眼，也是项目经理的梦魇。变更可能会对项目的正常进展带来无尽的麻烦，但奇怪的是，几乎没有项目不会碰到变更。特别是电子产品开发项目，电子产品的生命周期短、开发复杂度高，有时真的就是计划赶不上变化，当客户说出‘若不改规格就不用卖了’时，身为伙伴的我们不配合也不行。
面对这种状况，流着眼泪、带着微笑地接受绝对不是最好的处理之道，这只是让冲突点延迟爆发而已。最好的方法应该是如上所述，召集所有关系人，大家一起审视原先拟妥的计划书，共同面对问题，以寻求解决的方法，让 RD 加班只是方法之一，缩减规格、增加预算或时间，甚至放弃变更都可以拿出来讨论。
面对变更需求绝对不能慌乱，务必使变更在受控制的前提下对项目产生影响，千万不可任其随意变化。项目经理一定要把持一个铁的原则——因为变更会影响项目进行，因此，所有的变更一定要经过CCB（Change Control Board，变更管理委员会，即与此变更有关的关系人参与决策的会谈）的同意，并造出新的计划书，而工程人员只需随时按照最新版本的计划执行即可，严格禁止接受客户私下变更规格的请托。
实际上，我们会把变更处理流程制定的越简单越好，并鼓励员工一旦发现任何计划与实际状况有落差时，马上向主管报告，若连主管也无法处理时，则提出变更需求。项目经理会视状况召集需要参加 CCB 的项目关系人，变更审查时必须谨慎，必要时，一定要深入进行技术的review。
项目团队存在的目的只有一个，就是让该项目顺利结项，假使发现某项变更请求可能会使项目出现大问题，也应将此突发事件视为当前最高优先级的工作，项目经理必须尽力协调，务必要将其处理妥当，直到造出新计划为止。否则，放任项目继续执行下去并无任何意义！
接下来我们要讲项目管理9大知识体系中的时间管理。衡量一个项目是否成功的最简单方法就是是否在约定时间内，按照规格完成所有工作。而工程人员也常被问到：‘某某模块能不能on time完成？’、‘你预估要delay多久？’等与时间有关的问题。
时间是一种特殊的资源，也是项目计划中灵活度最小的因子。当项目缺人、缺钱、缺器材、缺技术时，都还有办法可想，但时间一旦过了就要不回来了！因此，实际上都是采用‘用金钱换取时间’、‘用RD肝功能换取时间’等策略，但若为企业长远发展着想，这都不该视为常事，不如在计划阶段就把时间规划好。
PMI强调项目成功的三要素为：计划、计划、计划。项目计划是通往项目成功的路线图，而进度计划则是项目计划中最重要的部分，是项目计划的核心。进度计划是基于 WBS 分解出来的所有Task（任务，即WBS树状结构的最末端——Leaf），确认Task之间的关系，然后估算出每项Task需要的资源与时间，进而编制出项目的进度计划。
同一件事由不同人执行，可能需要不同的时间，所以最好先确定资源，再估算时间，但实际上常有资源不足的状况，有时顺序必须颠倒过来——先预估每件工作的时间，等进度计划完成后再来分配资源。
拟定进度计划之前，必须先理清工作之间的关系。一般来说，工作间的关系有4种（请参考幻灯片中的图）。
■ FS（Finish to Start）：任务A结束后，才可启动任务B。
■ FF（Finish to Finish）：任务A结束后，任务B才可结束。
■ SF（Start to Finish）：任务A启动后，任务B才可结束。
■ SS（Start to Start）：任务A启动后，任务B才可以启动。
实际上用到最多的是FS，例如：设计完才能开始Implement，Implement完才能开始测试等，这都是 FS 的概念。工作间的关系相当重要，会直接影响整个项目的执行时间与关键路径的计算。举例来说，完成任务A要5天，完成任务B要10天，若它们的关系是FS，则完成任务A、B最短也需要15天；若它们的关系是SS，则可能需要10天就可以完成任务A与B（因为任务A、B可以同时启动）。
当 WBS 里任务较多时，人工排序并非是件容易的事，幸好有工具可以帮我们做这件事，我们只要输入每个任务所需的工时，以及任务间的关系即可。
在此我们看到Microsoft Project 这个专门用于项目管理的工具，只要输入任务信息，就会自动产生甘特图（Gantt）。在甘特图里，每项任务会有一根时间bar，代表其起讫时间。除了时间外，甘特图也能包含里程碑（执行时间为0的任务）与人力资源的信息。更重要的，我们还可以拿甘特图来执行进度追踪。因为甘特图具有简单易用与容易理解的特性，所以被广泛地应用在项目管理中。
一般来说，所谓的项目计划至少要包含以下信息，使用Microsoft Project 这种轻量级的项目管理软件已经绰绰有余。
■ 工作内容描述
■ 工作起讫时间
■ 工作间的关系
■ 工作所需的资源（或负责执行工作的员工）
■ 工作所需的费用或人力成本
当进度计划制定出来后，我们必须找出关键路径（下一张投影片会讲到），此时仅使用甘特图是不够的，还必须导入‘网络图’的概念。网络图描述了项目中所有工作的特性，以及工作之间的关系。投影片中就是一个简单的网络图范例。
以嵌入式系统项目的复杂程度而言，用人工去画网络图是不切实际的，而项目管理工具可以协助我们画出网络图，并找出关键路径。
网络图有好几种形式，幻灯片中的网络图是最简单普遍的一种，节点代表工作，连接节点间的箭头指示线则代表完成工作所需的时间。所谓的关键路径，就是网络图里从‘开始（S）’到‘结束（E）’之间最长的路径，表示想要完成此项目，最快也需要这些时间。
以投影片中的网络图为例，关键路径是：S→Task3→Task4→E，路径长度为10。从这个项目计划来看，就算缩短Task1的执行时间，甚至让Task2不需执行，都无法缩短完成此项目的时间。
许多项目经理完全不知道项目的关键路径与关键工作是什么，导致项目团队可能花太多精力在整体Schedule缺乏帮助的工作上，却任由关键的工作延迟，导致整个项目一同延迟。若能从项目的进度计划中找出关键路径，可使项目主管更有效率地调配资源，让所有项目相关人员都能知道不同工作项目间的重要性等级。更重要的，所有人都会特别关注关键路径上的工作，因为不管任何关键工作delay一天，项目的Schedule就必须跟着延迟一天！
知道了关键路径，项目经理会倾向尽可能提早每项关键工作的启动时间，或设法缩短其执行时间。必须注意的是，当我们加派资源在关键路径上，可能会导致项目路径改变，此时，项目经理就必须检验查看并设法缩短新的关键路径。项目经理通过不断改善关键路径上工作的执行计划，从而完成项目计划的最优化。
我们说过，没有人能够一次就做出完美、零误差的计划，要估计准确每一项任务的工作时间绝非易事，且任务的执行时间显然与负责执行的工程人员有绝对的关系。当项目里的任务为数众多时，每项任务预估时间的累积误差将非常大。
PMI应该观察到一个普遍性的状况。无论何种领域的项目，估计工时的误差总是很难做到准确。所以PMI建议进度计划拟定好后，项目经理最好再多灌一点水，把整个项目的预定执行时间拉长一些。至于要拉长多久，应视项目计划中还有多少未知的事情，以及风险评估的结果。如果要拉长50%，则表示项目计划准确度相当低。个人认为，与其拉长项目执行时间，不如利用这个时间把规划与分析做得更扎实些。
要注意的是，我们是为整个项目预留时间，这个时间是放在项目经理的口袋里，非到必要时不会轻易拿出来用。这意味着项目经理仍必须强烈要求各项目成员把预计工作时间估计准确，如果员工反应有太多未知，实在不知如何估起，这通常表示 WBS 切割得还不够细，必须把规划工作退回项目范围分析，或者采用滚动式规划（Rolling Wave Planning）这项方法。
举例来说，面对一个团队完全没做过的项目，同事们普遍反应未知的东西太多，无法在初期就identify出明确的工作项目与时间，但我们至少知道项目的目的与预定的deadline。假设6个月内要完成这个项目，那么，我们至少可以精确做出前一、两个月的计划，其中的工作项目可能是评估、分析、研究、买入 solution 等，而后面几个月的计划则保持模糊。例如：工作项目：implementation；执行时间：3个月。待分析工作完成后，对后期的工作性质应该就比较有把握了，此时，再来更新并细化计划的后半部。
至于幻灯片中的 Parkinson’s Law（帕金森定律）就不用提了，我本身也由工程师起家，深知大家是如何利用时间的。但我现在是项目经理，得把项目里时间的 buffer 收回我的口袋。
这张幻灯片将对项目进度管理做个总结。
虽然我们会为项目进度留些 buffer，但对于项目进度的安排应该要有适度的压力，让项目成员有适度的紧迫感。但这不表示项目主管必须不断地在进度上压迫工程人员，只会问‘还要多久可以搞定？’、‘会不会delay？’这些话，严格来说，都不能算是合格的项目主管，过度强调进度，很容易会伤害项目人员的士气。
当进度计划已经公布，同事们也知道关键路径与关键工作是什么，工程人员只要按章行事即可。此时，项目主管应该专注在任务的完成质量上。也就是说，基于任务的 schedule，通过不定时对任务成果的review，自然能够得知该任务的进度，也能实时挽救即将delay的任务。
企业组成项目团队来执行项目绝对是为了公司利益，所以在规划阶段必须仔细估算项目成本，除非有更大的利益，否则，执行没利润的项目是毫无意义的。
嵌入式系统开发有很大部分是软件工作，而软件开发大部分是脑力工作，所以很难预估软件系统的开发成本及其真正价值。举例来说，当我们对客户报价时可能会说：‘我们会指派 5位工程师，3 个月 full time 做这个项目，根据业界软件开发项目的行情，台湾地区工程师一个人月是4000～5000美金，所以我们的软件报价是……’。
这个算法看似有道理，但5位资深工程师与5位菜鸟工程师创造的价值完全不会在同一个水平，即便是同样薪资水平或工作年资的工程师，其单位时间产出的差异可能达数倍之多。就算只看个人表现，对这个领域的熟悉程度也会影响其产出，甚至工程师当时的情绪或生活状况，都可能会使其产出不一致。
所以业界用人月来计算软件的成本或‘售价’，其实是无计可施之下的办法。也许你会问，那我们不要用工时来计算软件开发成本，直接计算最后交付给客户的‘软件价值’，然后乘上一个该赚的比例不就好了？
然而软件价值估算是一件更麻烦的事情！一个方法是用程序的行数来计价，同一个模块，工程师A用100行完成，但工程师B只用50行完成，且性能更好。请问，这个模块到底该如何计价？嵌入式系统里的一行程序和网络程序里的一行程序，价格又该如何区分？
软件价值估算是一个专门的学科，其中有许多复杂的数学模型。幻灯片中有个表格，说明了在某项评估软件开发成本的模型中，它包含一项公式，你会发现嵌入式系统的乘数与指数因子都高过其他种类的软件开发项目。这只说明嵌入式系统里的某个模块，应该比其他软件系统中功能类似的模块要来得贵，但软件系统种类这么多，怎么可能就这么简单区分为 3种价格？
这个世界上没有多少人搞得懂教科书里的软件价值模型，所以软件报价与软件开发成本估算，一直是项目经理心中的痛。在嵌入式系统中，硬件与生产部分的成本较容易估算，而软件的成本估算还是只能基于 WBS 与资深软件人员的经验，毕竟分别对多个小任务进行估价，总是比直接评估整个项目要容易。
看吧！我们又碰到WBS了，WBS真的很重要！
从幻灯片中的表格可以看出，工作被切割的越细致，所估算出来的成本就越准确。但实际上，根本等不到项目团队把项目需求弄清楚、把 WBS做出来后才对客户报价，通常就是用这张幻灯片所提到的人月估价法（实际运行时，根本就是心里已经预算了一个总价，换算成人月后，再设法做个表格说明各个工作项目、需要多少人做多少个月，因此，这个项目总共需要多少人月，基本上就是一个凑答案的做法）。表格里显示出这种报价法的误差可达 25%～75%，现在你们应该知道这个 75%是怎么来的了。有一本很有名的项目管理书籍叫做《人月神话：软件项目管理之道》，极力推荐所有从事软件开发的同事们细读此书。
也就是说，嵌入式系统开发项目的合约价格通常和实际价格有段差距，所以这个价格拿来参考就可以了，千万不可以当作项目运行期间成本管控的基础。项目经理还是应该根据 WBS重新评估开发成本，并在项目执行期间，监督预算的使用状况。
台湾地区信息界其实是明显的硬大软小，许多系统厂家还是有‘买硬件送软件’的business model——意即客户只要最后将产品交由该公司生产，则该公司只会收取一些软件开发费，甚至真的是软件免费，只要能在大批量生产时赚回来就可以了。
就算对客户的报价中不包含软件的金额，真正项目在运行时，软件开发不可能毫无花费，因此，项目经理还是要把‘实际’的预估成本算清楚，以确保项目不会超支。
成本管理的主要目的就是避免超支，通常一般工程人员不需操心预算的问题，但如同进度落后会导致项目失败一样，预算控制不当，也可能导致项目断炊，一样会使得项目失败。而项目经理存在的目的就是尽所有的努力，使项目往成功之路迈进。因此，项目经理除了要监控进度外，也要控制项目‘烧钱’的速度。
换句话说，只用进度来描述项目目前的状况是不够的，还必须同时考虑成本的使用状况。项目管理知识体系提供一个已广为采用的方法——挣值管理。挣值管理主要用于项目成本和进度的监控，它将目前为止所完成的工作，与项目计划里的估计值进行比较，这会提供一个关于‘项目距完成还有多远’的估量。通过从已经完成的工作量推算，项目经理可以得到距离项目完成还需要花费多少资源的估计。
挣值管理是一个很有用的工具，除了可以告诉你目前项目的进度、成本花费以及与项目计划间的差异之外，更重要的是从曲线图中可以看出项目的趋势。虽然趋势表明项目可能会delay或超支，但不代表项目就真的会 fail，但趋势向下无疑是个警告，此时项目经理必须提早 do something，以阻止状况恶化。
挣值管理并不复杂，实际上我们也不需要自己按计算器，项目管理软件会帮忙计算出所有的进度与成本指标。对挣值管理有兴趣的朋友可以翻阅PMP的书，直接找个案例来看，今天我就不详述了。
把项目在预算内准时完成，并不代表就可以顺利结项。如果质量不符合要求，在改善之前，客户是不会愿意当冤大头验收的。
嵌入式系统包含软件与硬件，硬件的质量比较容易理解，例如：结构接缝是否密合、各零件的功能是否正确运行。但软件是逻辑实体，不容易描述其质量等级，软件问题基本上是由人为差错所引起，且问题隐藏在千变万化的逻辑组合中，若等到开发告一段落后才想要去一一找出所有问题，困难度会非常高。软件质量管理的关键是预防重于治疗，尽可能在规划阶段就要做好‘质量计划’，不能全靠事后检查。
一般以研发为主的公司，虽然都知道质量对产品的重要性，但在实际运行时，往往又无视质量单位应发挥的作用。PMI注意到了这件事情，因而在项目管理知识体系中特别提到：在项目运行的过程中，质量单位应该全程参与，不只具有发言权，面对攸关项目的决策，甚至应该具有否决权。
在软件开发项目里更是如此。道理很简单，研发单位根据流程执行产品开发，但最终产品的质量（甚至可上推到项目的成败）却应该是质量单位的责任[7]。唯有如此，才能避免研发单位陷入‘球员兼裁判’的盲点。
投影片中列举了不少项目质量的思想，无论你是项目经理、工程师或测试人员，只要身为项目的一员，都请务必了解质量的精髓。质量管理必须贯穿整个项目，没有质量观念的团队，将会在项目后期付出沉重的代价。
质量系统是门大学问，市面上有不少体系复杂的质量系统，但我一向认为只需要弄清质量系统的基本概念即可，实际上则必须根据项目的实际状况来制定该项目的质量策略[8]。
一般公司或项目团队总是弄不清楚 QA、QC、Testing-Team 这些名词的定义，所以老是会把团队冠上名不副实的名字。最常见的就是称呼只负责测试的团队为 QA，但实际上，公司内部根本没有任何单位负责执行真正QA该做的事。
质量保证（QA）主要目的就是确保产品在既定进度与预算下，能圆满达成预期质量水平与可靠度目标。QA单位的工具就是稽核（Audit），任何项目流程中的工作，从计划拟定、模块设计、Code Review、测试计划、测试涵盖率、生产流程、备料计划等，QA单位都可以进行稽核。特别是项目团队完成了某个里程碑、提出了某项变更请求，或是项目即将进入下一个阶段时， QA单位都应该主动介入稽核，避免问题被拖延到项目后期，将会变得更棘手。
我们知道工程师都是很爱面子的，所以QA单位在执行稽核时一定要注意态度，不能自以为是RD的上级单位，造成团队彼此的冲突。PM更必须注意RD与QA间的关系，并尽可能参加所有Audit Meeting。
很可惜，本公司中并没有‘真正’的QA，但项目里不能没有QA，所以我的项目就只能由PM及其他主管包办代替。因为由主管来执行Audit（请注意，Audit和Review是不同的概念，前者主要关注的是流程与结果，而Review则较为技术性，关注的是detail），工程人员也较容易配合。本公司因人力资源不足，项目执行者也只能从权。
PMP提到了许多QA的工具，基本上和软件工程提到的SQA概念一致，各位有兴趣可以找来看一看。
QC和QA的职责完全不同，QA是专注在流程的正确性，而QC则必须确定项目结果与质量标准是否相符，同时确定消除不符的原因和方法。以软件开发来说，QC就是根据质量标准，设法找出某软件版本的所有bug，并持续追踪每个bug被处理的状态。
软件测试有其方法论，QC 必须有系统、有方法、有计划地执行测试工作，绝对不是乱枪打鸟。当找到bug后，必须利用bug管理工具妥善管理，每个bug的处理流程都必须记录下来。此外，bug管理软件也能自动产生报表，让项目经理可以判断各个版本间质量水平的趋势。
最后再强调一次，项目团队不能过度依赖QC的测试，如同RD无法写出没有bug的程序，测试团队也无法找出所有的 bug。质量工作一定要在项目前面执行，如果等到后期才来做，势必得付出相当可观的成本。
并非所有公司都能言行一致，虽然口头上说质量第一，但组织中却无法落实质量系统。我们在业界工作，还是要让自己的项目尽量可以站在质量的保护伞下，以下是我的经验和建议。
■ 质量活动必须经过规划，同时符合项目需求，并明文公布
■ 推广‘提高质量，就是尊重客户’的理念
■ 质量活动必须尽早启动
■ 质量小组尽量可以独立存在
■ 质量人员必须经过培训
■ 工程人员必须能够理解，质量人员也是为了项目成功而努力着，并非存心挑剔或找麻烦
项目团队是由于项目而成立的临时性组织，项目经理可能对成员并不熟悉，且成员之间的默契也不足，所以反而更加重了项目中团队管理的困难。
项目依附于企业而存在，因此，企业的组织架构当然会影响项目团队的管理。对项目来说，职能型组织与项目型组织是两种极端组合，前者并没有‘明显’的项目经理的职位，项目决策由参与该项目的所有部门主管共同决定；后者则是以项目来区分部门，部门主管就是项目经理，其最大缺点就是资源可能重复。
嵌入式系统项目并不适合在这两种组织架构中运行。以职能型组织来说，嵌入式系统牵涉的领域较广，若缺乏一位可掌控全局的项目经理，重要的事情需要由软件、硬件、结构、测试、生产等部门经理共同决定，不但效率差，而且每项决定可能都得经过妥协，对项目来说极为不利。对嵌入式系统来说，项目型组织的缺点更为明显，每个部门（项目团队）都必须有软件、硬件等各项专长的工程师。公司的技术能力分散，不但无法累积，对未来的技术发展也难有长远规划。
因此，对嵌入式系统开发项目来说，若能在职能型组织中增加一个平行单位——项目经理办公室（PMO），这种矩阵型组织相比较之下较为有利。
许多企业只知道追赶潮流，不明就里地成立了PMO，却仍是以职能型组织的方式做事，使得PMO变成企业中的闲人办公室或冷宫，这实在是辱没了PMO的设计原意。
我们公司就是采取矩阵型组织，项目成员来自各个团队。在项目运行期间，每个项目成员会有两位老板。至于项目成员究竟应该分配多少时间与心力在项目上，则视公司对该项目的重视程度，以及项目经理与部门经理的沟通而定。在对项目的支持上，部门经理与项目经理的认知往往是对立的，部门经理除了要在不同的项目配置人力之外，还要负责执行该部门的未来计划；但项目经理的目标只有一个，就是让当前的项目成功！
项目成员难免会被卷入两个经理之间的纷争，而这也是项目经理必须尽全力避免的事！身为项目经理，就是要尽力与部门经理沟通，设法让项目成员可以full time支持项目，若有必要，可以延请高层介入协调。
项目经理对于处理‘人’的问题务必谨慎，目的就是让来自各部门的成员可以专注于自己的项目，尽量不要与部门经理或高层正面冲突，毕竟，这对目前的项目与往后的项目是没有帮助的。
项目团队管理除了人力取得之外，最重要的就是团队激励，让团队成员始终保持旺盛进取的士气。团队管理是否得当，往往是影响软件项目质量的关键性因素，必须特别注意下列重点。
■ 创建有实际存在感的项目团队
■ 建立奖励机制
■ 确立良好的人际关系
■ 设定工作授权系统
嵌入式系统开发项目经常涵盖许多不同领域、不同文化的成员，所以管理方式也要相对有弹性。例如：软件工程师需要较轻松自由的工作气氛，不能像工厂采取军事化管理。面对不同的项目成员，也要观察其真正的需求，设法让其安心做事。
PMP里提到了许多激励理论，幻灯片中的金字塔——马斯洛的需求层次理论，就是其中之一。各位若有兴趣可以去询问Google大神，简单来说就是8字箴言——因材适所、投其所好。项目里的工作不胜枚举，有苦工型、技术型、规划型、管理型等工作，项目经理必须让适合的人执行适当的工作。举例来说，若让自负型的成员去做苦工型的工作，其难免心生不满；若把技术型的员工硬塞去做管理性的工作，对项目及个人都不好。这个道理简单易懂，重点是项目经理必须把识别每位员工的特性与需求，当成最重要的事情之一。
嵌入式系统需要的软件工程人员数量不少，且软件开发是智力的活动，工程师一旦不愉快就不会有创造力！项目经理要尽可能与工程师‘博感情’，富有弹性的工作环境加上适度的压力，并按照计划与流程按部就班执行。
据研究指出，IT项目成功的4项因素分别为：
■ 管理层的大力支持
■ 终端使用者的积极参与
■ 有经验的项目管理者
■ 明确的需求表达
而这四项要素全都依赖良好的沟通技巧。奇怪的是，IT产业里的技术人员通常只受过严格的专业培训，往往不知如何与外界沟通、协调及谈判等。试想，如果项目经理无法由客户了解真正需求、项目经理无法传递项目目标给项目成员、项目成员在技术讨论上各持己见，主管却无法协调等，则此项目成功的机会将微乎其微。
PMP要求项目中必须具备项目沟通计划，内容应包含以下重点。
■ 沟通需求：哪些人、哪些时候、需要哪些需求？
■ 沟通内容：沟通的格式、内容、详细程度等。
■ 沟通方法：明定沟通方式与沟通管道。例如：会议记录的管理方式、bug管理软件就是RD与测试人员间的沟通方法、工作报告就是工程师与主管之间的沟通方法等。
■ 沟通职责：谁发送信息，谁接受信息？
■ 沟通时间安排：在项目计划中必须包含重要沟通事件的Schedule，例如：每周的review meeting、与客户的定时会议等。
实际上，过度正式化的沟通会议会让工程人员产生莫大的压力，项目主管必须尽量做到沟通于无形之中，而且在制定沟通计划时，必须尽量地简化，人多不会好办事，正如幻灯片中所说的，某件事参与的人越多，沟通管道会呈倍数增加，这只会让事情更加复杂。
一般项目时常会无视风险管理，但以嵌入式系统开发项目来看，重要工程人员离职、存储器size过小、预算超支、规格变更、零件涨价或缺料等状况都可能发生。如果项目计划中完全没有考虑到防治风险发生的可能性，当执行时期‘恶梦成真’时，难免令人措手不及。
风险管理的思想是：并非每个可能的风险都需要处理（毕竟风险不一定真的会发生），但一定要在项目初期就将其辨识出来，并评估其发生的几率，以及可能产生的影响力。
举例来说，某个产品开发项目会采用Embedded Linux作为系统核心，但项目成员里只有一位工程师熟悉此领域，且最近有倦勤的倾向。当项目经理识别出这个风险后，他判断该工程师离职的几率很高，若一旦离职，对项目将是严重的打击。于是他决定先试着沟通，再度确认该工程师执行完此项目的几率，同时，他也延请另一位工程师进入项目团队，从项目一开始就熟悉Embedded Linux。
再举另一个例子。NAND Flash 的价格变动很大，而且随时都有可能缺货，当项目团队识别到这个风险，就应该直接建议生管单位提前备料。
从这些例子看来，大部分的风险处理其实并不困难，而且可以在项目初期就排除或减缓。但如果未将风险识别出来，想要事后处理将难如登天，使得这些风险宛如项目中的不定时炸弹，让项目经理不得安眠。
PMP提供了许多风险定性与定量分析的实用工具，首要任务就是找出项目运行时可能发生的风险。风险识别需要具备一定经验的人来执行，通常就是根据项目目标与WBS，把项目在脑袋里‘跑’一遍，然后列出可能发生的意外事件，或是请所有项目成员，在轻松的气氛下举行‘头脑风暴法’，并记录下所有与会者对本项目风险的想法。
风险是未来才会发生的事，所以没有人可以列出完全正确无误的风险列表，但无论如何，有做风险识别绝对比没做的好，至少我们已经预先排除了项目的某些不确定性。
有了风险列表后，我们要为每个风险打两项分数——发生几率及严重性。同样的，这在项目初期是估不准的，但至少可以比较出高低，例如：客户临时修改规格的严重性比某零件缺料的严重性要高，而工厂发生火灾的机率比某重要工程师离职的机率要低。风险列表里的每项 Item 都会有两个分数，将其相乘并排序，名列前茅的项目就是我们非得 do something的风险。
项目因为有着独特性与前期不确定性，因此，项目执行本身就是一件高风险的活动。项目管理不可能消除所有的风险，但通过一定的风险规划，并采取必要的风险控制策略，通常可以消除或减少某些风险的影响程度。
当‘风险排行榜’完成后，我们就该针对这些风险，拟定项目风险应对计划，以确定某个风险该不该处理？何时处理？怎样的处理方式？以下有4项规划降低风险的主要策略。
■ 回避风险：主动放弃或拒绝使用导致风险的方案，试着寻找替代方案。
■ 转移风险：将风险转移给外包公司。
■ 损失控制：减缓风险发生时的危害程度。
■ 承担风险：对影响力小或发生机率低的风险，可选择先不予理会。
再次强调，风险识别往往只能借助资深员工与顾问的宝贵经验，或许并非科学，但绝不能因此就不做风险分析。项目中可能发生各种意外事件，事先不可能全部料到，但能事先料想到的风险，却又不加处理，都只是平白错失提高项目成功的机会罢了！
幻灯片列出了嵌入式系统可能发生的风险种类，以下再补充一些软件开发项目常见的风险与预防措施。
■ 合约风险：主要就是合约条款有漏洞，项目经理必须会同法务人员详细检验查看合约内容。
■ 需求变更风险：提前以书面方式，和客户约定好变更处理流程。
■ 沟通不良风险：不可忽略‘项目沟通计划’的制定与公布。
■ 缺乏高层支持风险：只能不断的沟通再沟通，或对高层诱之以利，说明此项目可以为公司带来的利益。
■ 进度风险：有些项目的进度要求相当‘苛刻’，项目 delay 可能意味着市场机会变小。假使Schedule无法调整，只能尽量多取得资源与预算，此时，分阶段交付项目成果也是方法之一。
■ 质量风险：谨慎制定项目质量策略，成立质量小组等。
■ 系统性能风险：增加执行设计阶段的力度、制作原型（Prototype）等。
■ 技术风险：可考虑外包，或变更执行人员等。
■ 团队成员能力风险：提早开始教育培训或变更团队成员。
■ 团队合作风险：目标要明确，绩效制度要公开、公正、公平。
■ 人员流动风险：尽可能将核心工作分派给多个人执行。
■ 协助厂商风险：合作前即制定审核稽核（Audit）与验收流程。
在嵌入式系统开发项目中，可能的外包项目：买入新技术、委托开发项目、硬件制作、代工生产等。一般人总以为将某些开发工作外包，会让项目团队更轻松一些，并增加项目成功的机会，其实这是个很大的困惑！我们在前面沟通管理中谈过，需要沟通的点越多，沟通管道就越复杂。公司内部成员沟通有时都难免会出现误会，更何况还要管理其他公司的开发进度。
所以在决定是否外包之前，一定要做Make-or-Buy Decision，考虑的因素必须包含：
■ 技术难度
■ 沟通复杂度
■ 外包金额
PMP中谈到许多不同形式合约的性质，但通常公司都会有专门的法务部门帮忙处理这些事情（即使我身为老板，也不会放心让工程师或技术出身的项目经理来处理合约），所以在此就不多着墨了。
项目配置（Project Configuration）这个名词听起来有点玄，简单的说，就是项目资产的管理。以嵌入式系统开发项目来说，当一件项目结束后，有哪些资料可以变成有用的组织资产呢？所谓组织资产就是有利于以后项目的资料，最直觉联想到的就是‘程序代码与技术文件’，除此之外，更重要的应该是‘开发轨迹’。例如：
■ 项目的全貌，包含产品规格与设计规格。
■ 项目原始的计划（第一版计划书），以及项目运行期间所有曾经做过的变更。
■ 设计阶段的任何重大转折点、与项目运行期间技术上的重大突破。
■ 软件开发期间曾经遇到哪些问题（如bug），解决的方式是什么？对应的程序代码是哪些？
■ 重要软件版本或项目里程碑（项目进度表时间检查点）所代表的意义，以及该时间点项目状况的快照（Snapshot：以软件系统来说，所谓的Snapshot就是当时的版本）。
■ 硬件设计与生产阶段的问题履历及解决方式。
在嵌入式系统项目中，所谓的‘开发轨迹’其实就已经包含了计划书、规格、设计文件、程序代码和问题清单（可能是bug管理server的database备份），为了将这些宝贵的资料保留下来，必须在项目运行期间做好配置管理。其实配置管理并没有想象中复杂，各位在项目中都有使用版本控制server、bug管理server，以及定时的统一备份文件等，这就是在做配置管理，只是在我管理的项目中，会更明确地指派相关工作，通常我会请系统团队的小组长帮忙，而且我个人也会随时监督。
关于配置管理最容易被忽略的就是配置管理可以在项目运行期间发挥极大的功效，可让项目成员了解自己在做什么，也能随时追溯到任意一个时间的状态，但配置管理更大的目的却是让项目技术与管理资产可以不断累积，特别是在项目结项阶段人员鸟兽散时，就有待项目主管们能够定下心来将这些信息整理与归档。
各位是否经常在从事开发工作时碰到以下问题？‘这个模块以前好像做过，但程序代码不知道在哪里’、‘这是一个REOPEN的bug，之前在某个版本是OK的，但现在怎么也调不出那个版本’、‘实在搞不懂当初为什么要这样设计，看code也看不懂，但目前仅存的设计文件居然是旧的’。如果这是你们项目运行的常事，应该不难想象这样的‘常事’到底浪费了多少企业宝贵的研发资源。
最后不能不提一点，就算我们拥有很棒的项目团队，技术能力与管理流程也都没问题，也不见得能够保证项目成功。因为电子产品开发项目依附企业或组织而存在，每家公司都有自己特殊的企业文化及财务状况，而且组织有更高层的老板与技术资产，都可能影响到项目执行，这是项目经理必须面对的层层考验。
所以在PMP中，除了今天说明的5大流程与9大知识领域之外，还有两项在项目运行中不可忽略的因子。
■ Enterprise Environmental Factors（企业环境因子，简称EEF）：大部分PMP的流程都必须参考EEF，EEF泛指会影响到项目成败的企业内、外部环境因素。例如，组织文化、组织架构、企业运行流程、政府或产业标准、市场状况、项目关系人的风险忍受度、政治气候和研发团队专长等。
■ Organization Process Assets（组织流程资产，简称OPA）：基本上，OPA 应该也是一种EEF，包含企业中所有与项目相关的流程规范，主要区分为两大类。
□ 流程与程序：例如，工作授权程序、组织标准流程、各类文件模板、绩效衡量准则、issue与bug管理、变更控制程序、财务控制程序等。
□ 公司知识库：例如项目文件、以前项目的程序代码、issue 与 bug 数据库、历史信息与经验学习知识库等。
为何要在最后才来谈EEF和OPA呢？因为我想再次强调PMP绝对没有强制规定项目一定要如何执行，它仅是一组思想，加上许多流程及工具而已。每件项目都是独一无二的，死背PMP的规范及工具一点意义也没有！因此，项目团队还是必须因地制宜，根据项目的特性，以及企业环境的状况，选择合适的方法与工具来执行项目。
希望今天的课程可以让各位对项目管理有正确的理解，也希望今后本公司的所有项目都能采用更有效率的方法来执行。谢谢大家的参与，下课啰！”
注 释
[1]. 关于这部分，可参见《第1章：浅谈系统·嵌入·硬件》。
[2]. 在《第4章：嵌入式系统开发项目生命周期：设计、执行与结项》，将会对此流程图有更深入的阐述。
[3]. 意外或风险事件这些计划外的事情，对进度吃紧的项目来说，真的可以说是袭击。
[5]. 通过评估新项目的优势（Strengths）、劣势（Weaknesses）、竞争市场上的机会（Opportunities）和威胁（Threats），以决定启动这个新项目是否具有意义。
[6]. 关于变更管理，请参考《第15-1节：进度追踪与变更控制流程》，其中有更深入的说明。
[7]. 项目最终的成败，当然是项目经理的责任。这里只是说明一般老板通常认为质量问题完全是 RD 的责任，其实这是错误的观念。
图书在版编目（CIP）数据
嵌入式系统开发之道：菜鸟成长日志与项目经理的私房菜/邱毅凌著.--北京：人民邮电出版社，2011.12
ISBN 978-7-115-26603-3
Ⅰ.①嵌… Ⅱ.①邱… Ⅲ.①微型计算机—系统开发 Ⅳ.①TP360.21
中国版本图书馆CIP数据核字（2011）第208713号
版权声明
本书为台湾精诚资讯股份有限公司悦知文化授权人民邮电出版社出版。此中文简体字版本仅限在中华人民共和国境内（不包括香港、澳门特别行政区及台湾地区）印刷、发行及经销。
本书原版权属精诚资讯股份有限公司悦知文化。
版权所有，侵权必究。
内容提要
本书用平易朴实的语言，以一个完整的嵌入式系统的开发流程为架构，通过一位“菜鸟”工程师与项目经理的诙谐对话，故事性地带出嵌入式系统概念及开发要素，并点出要成为一名称职的嵌入式系统工程师，在实际工作中所必须具备的各项知识及技能。
全书可以分为三大部分：第1、3、4、17、18、19章和附录D为嵌入式系统概论与开发流程；第2、15、16章和附录A介绍了嵌入式系统项目管理与软件工程方面的知识；第5～14章，以及附录B、附录C介绍了嵌入式系统的开发技术。
本书不仅可以作为致力于嵌入式系统开发初学者的入门教程，也可以作为从事嵌入式系统开发的项目经理、技术团队主管等不可不读的参考书。
嵌入式系统开发之道——菜鸟成长日志与项目经理的私房菜
◆著 邱毅凌
改编 谢亮 谢晖
责任编辑 俞彬
◆人民邮电出版社出版发行 北京市崇文区夕照寺街14号
邮编 100061 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
北京铭成印刷有限公司印刷
◆开本：787×1092 1/16
印张：36.25
字数：992千字 2011年12月第1版
印数：1-3500册 2011年12月北京第1次印刷
著作权合同登记号 图字：01-2011-4975
ISBN 978-7-115-26603-3
定价：69.00元
读者服务热线：(010)67132692 印装质量热线：(010)67129223
反盗版热线：(010)67171154
广告经营许可证：京崇工商广字第0021号
