写在前面
这一小节只是记录一下我看到的关于项目管理的重要东西（其实我也不是项目管理者，只是要大概了解一下）
1. project arch
2. 嵌入式系统概论与开发流程
一、概论
嵌入式系统的定义一般如下:Embedded System use general or specialized purpose CPUsrunning custom software along with specialized hardware to perform application-specificfunctions.
在设计一个嵌入式应用项目时，通常需要考虑以下几点：
- 成本
- 外观
- 预计销售市场与消费群体
- CPU计算能力
- 内存大小
- 省电需求
- 稳定度
- 反应实时性（Real-Time）
- 软件复杂度
- 测试复杂度
其实某项产品是否符合嵌入式系统的定义并不重要，重要的是开发者必须完全了解嵌入式系统的本质，以避免在设计开发阶段做出错误的判断与决定
二、嵌入式系统开发项目生命周期:项目启动与规划,设计、执行与结项
Schedule是用来遵守的，不是用来修改的
客户来说明嵌入式项目时，在跟开发企业说明时间预算时，总是偷偷自己预留了部分时间，说的时候总是要求时间ASAP（As soon as possible）
客户在规格方面也会自己留下缓冲空间，在刚开始谈规格时偶尔会模糊其词,如果我们可以做到客户的高标准当然最好，假使不行的话，只要没有低于客户藏在心里的底限，其实都还是会被接受的(我超，都是心机啊)
质量是规划、设计出来的，不是检查出来的。
可以一体适用的是思想，而非执行方法
根据项目特性与软件工程规范，定义最合适的工作方法，并确保项目可以按规格如期完成
软件工程师不可能写出没有bug的程序，测试工程师也不可能找出系统中所有的问题，所以测试工作一定要经过仔细的规划，则测试工作才可以被控制，测试结果才可以被量化，产品质量才可以被保证。
莫非定律（Murphy's Law）:只要能出错的地方，就一定会出错,因此在测试时，一定要假设所有的事情都会出错，这样才能找出所有的问题。
测试工程师的工作是找出所有的问题，而不是证明系统没有问题
改的越多，功能就会越强，质量就应该越好，这绝对是一个错误的思想。
不可能开发出没有bug的软件应该铭记于心，本质是要求产品质量可控
3. 项目管理与软件工程
一、嵌入式项目管理
任何工作都应该先评估可行性，接着作计划，然后有效率地利用时间、成本与资源，并在可接受的范围内管控成果的质量
有一个关键思想PDCA(plan-do-check-act),即谋定而后动，做完后要反思，争取下一次做得更好
WBS(Work Breakdown Structure) 很重要
在更改计划时，严格禁止接受客户私下变更规格的请托。
4. 项目进度追踪实务
简单地说，进度追踪的原则是：
■ 所有项目人员必须定时参加review meeting。
■ 鼓励员工及早highlight可能发生的风险。
■ 主管主动检查系统状态。
■ 特别关注进度与计划有落差的工作项目（不是等到delay才关注，假设计划工时是10天，过了5天若进度未达50%，则应将其列入特别追踪清单）。
■ 为了执行进度追踪，我们会引进一些工具（本章后半部分会说明），并将工具整合入流程中，例如，规定进度审查会议必须使用MS Project所产生的报表。”
做好项目管理的工具如下所示：
■ 规划/设计阶段
□ 计划拟定
· Microsoft Project（不算贵啦！)。
· GanttProject （Free）。
· Google日历（Free)：可将输入项目行事历与查核点，时间到之前会主动发mail通知。
□ 设计文件· Microsoft Office（公司的计算机总不可能没有Office吧！）。
· Wiki Server （Free）：架设与维基百科相同的服务器相当简单，这是一个可以让所有项目成员共同编辑文件的平台。
· Google Document （Free）。
■ 执行阶段
□ Issue Tracking Server
· 公司如果有引进Issue Tracking System，就直接使用那套，除了公司的内部流程已经建立，与其他单位的沟通也比较没问题。如果没有的话，建议就使用Free的Trac。
· Bug管理——Bugzilla。
□ Version Control Server：使用CVS、SVN或后起之秀Git皆可，都是Free的。
□ Regular report和Action Item List-Excel。
5. SoC设计公司中嵌入式系统团队的管理
5.1 SA团队简介
市面上的IC有千百种，CPU就一种，但随着IC工艺的进步与IC设计技术的成熟，现在业界比较常用SoC（System On Chip）作为主控IC来设计产品，以前必须放在CPU外的一些IC与组件，现在都可以很容易地整合到一颗IC里去。如此一来，不但节省了成本，也让电路板可以越来越小，结构设计有更大的发挥空间。
IC设计公司为了减轻客户使用自家IC的学习曲线，使客户的产品尽快量产上市，IC设计公司在销售其IC产品时，一定要提供Reference Design（硬件板子与参考程序代码）给客户。简单来说，这个Reference Design就是客户应用此IC的一个产品范例，而IC设计公司内负责提供这个产品范例的团队就称之为SA（System Application）
SA团队的工作除了demo board的电路设计与板子制作之外，若是‘设备IC’的SA，必须提供demo board上的主控IC与操作系统的driver source code给客户。举例来说，Ethernet IC必须由CPU控制才可运作，SA会先制作此IC的子板，再根据这颗IC的产品定位，选择市面上比较popular的demo board，将子板与demo board连接，接着开始编写demo board上CPU与操作系统的driver，并将其调整到具有最佳性能，即这颗新IC的Reference Design。若有必要，SA可能必须多开发几个demo board或操作系统上的driver。
若是CPU或SoC的SA，则必须提供一个简单而完整的应用系统，包含以下项目:
■ 已达量产水平的硬件平台。
■ 必要的驱动程序。
■ 嵌入式操作系统。
■ Library。
■ 可以展示IC能力的Demo Application。
除了开发demo board系统之外，通常SA还要负责IC开发时期的FPGA验证，与IC试产阶段的IC验证，有时SA还必须负责分析、解决客户在使用此IC时碰到的疑难杂症（一般嵌入式系统团队在分析问题时，到最后才会怀疑是否为IC的问题，而SA的责任之一，就是要找出IC的潜在问题）。
原本SA仅要提供客户一个可以demo的软硬件平台，当成客户使用该IC时软硬件设计的参考即可，并非用以量产。而我们都知道，即便规格相同，做demo平台与产品开发（真正可卖到end user手上），实际上是完全不同的两码事！
■ Scope与SPEC.的复杂度必然不同
■ 质量的严谨度不同
■ Demo程序通常可土法炼钢：也就是硬干，以下重点都可不考虑。
□ 系统架构。
□ 软件工程。
□ 扩展性、可移植性。
□ 客户API。
如果只是做demo platform与客户支持，那么，其实并不太需要一个组织与流程严谨的嵌入式系统开发团队，再加上IC设计公司通常还是由IC设计专业起家，管理与技术主管都是IC设计专家，对IC生产流程的细节了如指掌，但这些IC设计的业界精英不见得真的了解电子产品开发的细节，更不可能知道如何run一个嵌入式系统开发团队，所以SA团队往往只是‘高科技IC设计公司’中的一个附属团队。
在某些IC设计公司，他们对IC设计流程有很严谨的规范，流程之间定义了严格的查核点，在IC Tape Out（将IC制造所需的数据提交给晶圆厂）前，也必须经过一次又一次的模拟与review！令人无法理解的是，在这样的公司中，SA居然不知如何做source code版本控制与bug管理、软件工程与质量概念异常薄弱、系统架构与模块化只是空中楼阁、设计文件杂乱无章等，更谈不上利用项目管理的思想来管理开发项目，SA的工作项目与进度规划完全取决于IC设计团队。
IC设计出了问题，制造好的IC可能变为垃圾，所以必须在开发流程中严格管控，若提供给客户的参考平台与sample code极不稳定，code乱七八糟且没有扩展性，客户对本公司的IC也会失去信心，即便再好的IC同样也会变为垃圾。也许这些公司的高层并非不注重SA团队，只是因为他们对嵌入式软件开发这个领域真的不熟悉，却又要用IC设计的思想来管理SA。
如果IC设计公司主要是‘卖’IC，那么，将IC设计团队比喻是强干，SA是弱枝也并无不妥，但让我们好好审视目前的市场状况，SoC设计公司真的是在‘卖’IC吗？”
5.2 SoC设计公司到底葫芦里是卖什么药？
TurnKey Solution（统包解决方案）:一个完整的软硬件平台，最好这个平台上的应用程序已经整合完毕。
即前期请给我Turnkey、中期请帮忙客制化、后期请协助解决生产与客诉问题
5.3 正确的Soc执行流程
■ Marketing负责分析市场与客户需求，进而定义Application，完成产品规格并为此负责。
■ Marketing所主导的Application SPEC。或Product SPEC.，为此SOC设计项目的基准（Baseline）。
■ IC与SA团队根据Application SPEC。分别定义IC与软/硬件系统规格，并交互review。
■ 新版IC的规格，来自新的市场信息，以及IC与SA团队的反馈。
5.4 SA团队的严峻考验
■ 比一般电子产品开发团队需要更全面的硬件知识。
□ 必须执行FPGA与IC验证。
□ 可能拿到“烂”IC。必须能分析到底是IC、硬件或软件的问题。
□ 随时要能掌握IC的性能信息。
□ Workaround。尽量帮IC梳妆抹粉（通过软件或硬件手段）。
■ 比一般电子产品开发团队需要更严谨的设计与评估流程。
□ 系统在设计时，可能IC连影子都还没有，评估工作要尽量精确。
□ 系统要能完全发挥IC的能力，隐藏IC的缺陷。
□ IC验证与系统的code必须可以重复使用。为了更严谨地执行系统设计，必须从流程规范中落实design review。
■ 比一般电子产品开发团队需要更严谨的系统架构。
□ 移植性（HAL）。同一系列的SoC必须使用同一个SDK, HAL在SoC的SDK中必不可缺。
□ 可扩展性。客户可能会要求我们在SDK设计阶段根本想不到的新功能，系统必须高度模块化，并具有可扩展性。
□ 客制化。通常客户只需要修改SDK里的Application，所以SDK一定要设计标准的Customer's API，让Application的开发更为容易。
■ 比一般电子产品开发团队需要更强的硬件设计团队。
□ 具弹性的硬件平台。必须同时支持不同客户的硬件客制化需求。
□ BOM分析。demo board不是可以动就好，必须到达量产水平。除了性能外，硬件工程师必须让硬件的生产成本具有优势，所选择的组件也必须易于备料。
■ 比一般电子产品开发团队需要同时服务更多的客户。这对SDK的稳定度、硬件设计的弹性、客服技术人员的人力资源配置等都是很大的考验。
5.5 SA团队的管理
■ 流程的重要性：一个团队要执行这么多种类的工作，一定要制定流程，避免重复工作的资源浪费，举例来说。
□ FPGA与IC验证的code必须是同一套。
□ FPGA与IC验证程序里用到的driver，必须就是系统里用的那一套driver。
■ HAL的重要性：SoC设计先期的投资金额不少，所以一定会计画推出同一产品线的一系列IC，为减少将来维护工作的effort，同一系列产品最好就只有一套SDK，此时就可看出HAL的重要性。
■ 系统模块化（Configurable）：SoC的SDK和一般嵌入式系统的SDK不同，同一套系统要support的客户数量非常多，而不同客户有不同的系统配置与功能需求，未经模块化设计的系统，绝对无法快速反应客户的需求（否则，就只能用工程师的肝功能来换取客户的满意度了）。
■ SA面对的SoC可能是有bug的，系统必须设法避过（Workaround） ，这些bug可能会在下个版本的IC里被修掉，而新版的IC也可能会出新的bug，所以系统里会有不少针对不同版本IC的patch。除了SA要maintain好各代IC的Workaround List外，还要求系统必须要有很好的Configuration管控（简单地说，就是规范各个版本IC的系统，要加入哪些patch）。
■ 客制化的effort越小越好：SDK一定要有标准的Customer's API，一来客户开发AP的学习曲线较平缓，而且既有的AP，可以很容易地移植到新版的IC与SDK上。
■ SDK与demo board的质量必须达到量产标准：SA里的QC或测试工程师，其测试强度必须达到产品化的水平，而测试强度则牵涉到测试流程的规范是否严谨。此外，SA里的测试工程师除了必须执行SDK（或产品功能）的测试外，有时也要帮忙与IC特性有关的测试工作。
■ 硬件平台必须弹性：和软件系统一样，客户会以SA提供的demo board为基础，并做功能的增删，所以demo board的设计也必须考虑模块化。