成为一个正式的嵌入式主板开发工程师，是一个艰辛的过程，需要开发人员维护和管理系统的每个比特和字节。从规范完善的开发周期到严格执行和系统检查，开发高可靠性嵌入式系统的技术有许多种。

今天给大家介绍7个易操作且可以长久使用的技巧，它们对于确保系统更加可靠地运行并捕获异常行为大有帮助。

技巧1——用已知值填充ROM

软件开发人员往往都是非常乐观的一群人，只要让他们的代码忠实地长时间地运行就可以了，仅此而已。微控制器跳出应用程序空间并在非预想的代码空间中执行这种情况似乎是相当少有的。然而，这种情况发生的机会并不比缓存溢出或错误指针失去引用少。它确实会发生！发生这种情况后的系统行为将是不确定的，因为默认情况下内存空间都是0xFF，或者由于内存区通常没有写过，其中的值可能只有上帝才知道。

不过有相当完备的linker或IDE技巧可以用来帮助识别这样的事件并从中恢复系统。技巧就是使用FILL命令对未用ROM填充已知的位模式。要填充未使用的内存，有很多不同的可能组合可以使用，但如果是想建立更加可靠的系统，最明显的选择是在这些位置放置ISR fault handler。如果系统出了某些差错，处理器开始执行程序空间以外的代码，就会触发ISR，并在决定校正行动之前提供储存处理器、寄存器和系统状态的机会

技巧2——检查应用程序的CRC

对嵌入式工程师来说一个很大的好处是，我们的IDE和工具链可以自动产生应用程序或内存空间校验和（Checksum），从而根据这个校验和验证应用程序是否完好。有趣的是，在许多这些案例中，只有在将程序代码加载到设备时，才会用到校验和。

然而，如果CRC或校验和保持在内存中，那么验证应用程序在启动时（或甚至对长时间运行的系统定期验证）是否仍然完好是确保意外之事不会发生的极好途径。现在一个编程过的应用程序发生改变的概率是很小的，但考虑每年交付的数十亿个微控制器以及可能恶劣的工作环境，医疗仪器应用程序崩溃的机会并不是零。更有可能的是，系统中的一个缺陷可能导致某一扇区发生闪存写入或闪存擦除，从而破坏应用程序的完整性。

技巧3——在启动时执行RAM检查

为了建立一个更加可靠和扎实的系统，确保系统硬件正常工作非常重要。毕竟硬件会发生故障。（幸运的是软件永远不会发生故障，软件只会做代码要它做的事，不管是正确的还是错误的）。在启动时验证RAM的内部或外部没有问题，是确保硬件可以如预期般运作的一个好方法。

有许多不同的方法可用于执行RAM检查，但常用的方法是写入一个已知的模式，然后等上一小段时间再回读。结果应该是所读就是所写。真相是，在大多数情况下 RAM检查是通过的，这也是我们想要的结果。但也有极小的可能性检查不通过，这时就为系统标示出硬件问题提供了极好的机会。

技巧4——使用堆栈监视器

对许多的嵌入式开发者而言，堆栈似乎是一股相当神秘的力量。当奇怪的事情开始发生，工程师终于被难倒了，他们开始思考，也许堆栈中发生了什么事。结果是盲目地调整堆栈的大小和位置等等。但该错误往往是与堆栈无关的，但怎能如此确定？毕竟，有多少工程师真的实际执行过最坏情况下的堆栈大小分析？

堆栈大小是在编译时就静态分配好的，但堆栈是以动态的方式使用的。随着代码的执行，应用程序需要的变量、返回的地址和其它信息被不断存储在堆栈中。这种机制导致堆栈在其分配的内存中不断增长。然而，这种增长有时会超出编译时确定的容量极限，导致堆栈破坏相邻内存区域的数据。

绝对确保堆栈正常工作的一种方法是实现堆栈监视器，将它作为系统“保健”代码的一部分（有多少工程师会这样做？）。堆栈监视器会在堆栈和“其它”内存区域之间创建一个缓冲区域，并填充已知的位模式。然后监视器会不断的监视图案是否有任何变化。如果该位模式发生了改变，那就意味着堆栈增长得太大了，即将要把系统推向黑暗地狱！此时监视器可以记录事件的发生、系统状态以及任何其它有用的数据，供日后用于问题的诊断。
　　大多数实时操作系统（RTOS）或实现了内存保护单元（MPU）的微控制器系统中都提供有堆栈监视器。可怕的是，这些功能默认都是关闭状态，或者经常被开发人员有意关闭。在网络上快速搜寻一下可以发现，很多人建议关闭实时操作系统中的堆栈监视器以节省56字节的闪存空间等等，这可是得不偿失的做法！

技巧5 - 使用MPU

在过去，是很难在一个小而廉价的微控制器中找到内存保护单元（MPU）的，但这种情况已经开始改变。现在从高端到低端的微控制器都已经有MPU，而这些 MPU为嵌入式软件开发人员提供了一个可以大幅提高其固件（firmware）鲁棒性（robustness）的机会。

MPU 已逐渐与操作系统耦合，以便建立内存空间，其中的处理都分开，或任务可执行其代码，而不用担心被stomped on。倘若真有事情发生，不受控制的处理会被取消，也会执行其他的保护措施。请留意带有这种组件的微控制器，如果有，请多加利用它的这种特性。

技巧6 - 建立一个强大的看门狗系统

你经常会发现的一种总是最受喜爱的看门狗（watchdog）实现是，在看门狗被启用之处（这是一个很好的开始），但也是可以用周期性定时器将该看门狗清零之处；定时器的启用是完全与程序中出现的任何情况隔离的。使用看门狗的目的是协助确保如果出现错误，看门狗不会被清零，即当工作暂停，系统会被迫去执行硬件重设定（hardware reset），以便恢复。使用与系统活动独立的定时器可以让看门狗保持清零，即使系统已失效。

对应用任务如何整合到看门狗系统中，嵌入式主板开发人员需要仔细考虑和设计。例如，有种技术可能可以让每个在一定时期内运行的任务标示它们可以成功地完成其任 务。在此事件中，看门狗不被清零，强制被复位。还有一些比较先进的技术，像是使用外部看门狗处理器，它可用来监视主处理器如何表现，反之亦然。对一个可靠的系统而言，建立一个强大的看门狗系统是很重要的。

技巧7 - 避免易失存储器分配

不习惯在资源有限环境下工作的工程师，可能会试图使用其编程语言的特性，这种语言让他们可以使用易失存储器分配。毕竟，这是一种常在计算器系统中使用的技术，在计算器系统中，只有在有必要时，内存才会被分配。例如，以C开发时，工程师可能倾向于使用malloc来分配在堆（heap）上的空间。有一个操 作会执行，一旦完成，可以使用free将被分配的内存返回，以便堆的使用。

在资源受限的系统，这可 能是一场灾难！使用易失存储器分配的其中一个问题是，错误或不当的技术可能会导致内存泄漏或内存碎片。更多资料企鹅爱吧物久零要奇伞武奇，如果出现这些问题时，大多数的嵌入式系统并没有 资源或知识来监视堆或妥善地处理它。而当它们发生时，如果应用程序提出对空间的要求，但却没有所请求的空间可以使用，会发生什么事呢？

使用易失存储器分配所产生的问题是很复杂的，要妥善处理这些问题，可以说是一个噩梦！一种替代的方法是，直接以静态的方式，简化内存的分配。例如，只要在 程序中简单地建立一个大小为256字节长的缓冲区，而不是经由malloc请求这样大小的内存缓冲区。此一分配的内存可在整个应用程序的生命周期期间保持，且不会有堆或内存碎片问题方面的顾虑。

以上嵌入式开发的教程可以让开发技术的人员获取更好嵌入式系统的办法。所有这些技术都是让设计者可以开发出可靠性更高嵌入式系统的秘诀。

来源：网络

嵌入式设备网络化、u盘化、功能复杂化的趋势，使越来越多的、过去可以用裸奔实现的嵌入式产品，产生了应用操作系统的需求。

而人力成本的持续上升、芯片成本的连续下降，以及cpu性能的迅速提高，又为大面积应用操作系统提供了物质基础。

本文和大家一起讨论一下，从裸奔到操作系统，我们将面对什么挑战。

1、速度

我们首先面对的，将是cpu运行速度的问题，毋庸置疑，操作系统调度需要cpu开销，需要cpu有更高的速度来弥补；再者，嵌入式系统经常用于实时控制，需要较高的定时精度，缩短tick时间间隔有利于提高控制精度，嵌入式系统中经常使用1mS甚至更短的tick间隔。然而，tick间隔越短，调度开销就越高，同样需要更高的cpu速度来弥补。当前日益提高的嵌入式cpu的性能，甚至单片机都32位了，很好地回答了这个问题。

2、内存容量

先讨论一个问题，一个原先需要50K内存的裸奔程序，如果移植到自身开销1K内存的RTOS下面，需要增加多少内存？是51K吗？

有许多嵌入式操作系统，都把运行操作系统的内存开销作为主要性能指标，有些甚至声称不到1K内存就可以运行。但我们千万不要被误导，以为用操作系统需要的内存与裸机差不多，只要比裸奔程序多那么1K、2K就行了。操作系统会使应用程序所需要的内存暴增，使用操作系统所增加的内存需求，主要来自以下方面：

1) 运行操作系统本身需要的内存。
2) 创建线程控制块、消息控制块等操作系统组件需要的内存。
3) 每个线程配置独立的栈所增加的内存需求。

其中第一项很好理解，几乎所有操作系统都会给出这个指标。第二项也容易理解，不用操作系统的情况下，我们常常定义标志位或全局变量来在不同模块之间传递信息，需要的内存就很少。而操作系统模式下，需要用到同步、互斥、线程间交换数据等，这就需要使用信号量、邮箱等操作系统组件，信号量需要分配信号量控制块，邮箱需要分配邮箱控制块……，这些，都需要消耗可观的内存。许多操作系统标明的，仅仅是OS本身运行需要的内存，并不包括信号量控制块拉、邮箱控制块拉等等这些操作系统组件需要的内存。我们知道，一个仅运行OS的系统，是毫无意义的，真正实现产品功能的，是应用程序。而djyos的si版本，大约需要的10K内存，则包含了一定数量的事件控制块、信号量控制块等操作系统组件所需内存的条件下的，完全满足一个小型系统所需。

说了半天，其实也只讲了操作系统对内存需求的冰山一角，OS下编程，对内存需求的影响最大的，当属OS的多线程并发特性，这使得我们要为每一个线程分配独立的栈。下面我们定性分析一下栈独立化带来的内存需求变化。栈是用来保存函数参数和局部变量的，可以说，有函数调用，就有局部变量。在单线程环境下，应用程序需要的栈，几乎就是main函数需要的栈，而在多线程环境下，每个线程的栈是独立的，分别等于该线程的线程执行函数所需要的栈，而系统总的栈需求，就是所有线程的栈需求之和。

假设有一不使用OS的应用程序，main函数如下：

void main(void)
{
while(1)
{
func1(); //本函数需要10K栈
func2(); //本函数需要5K栈
func3(); //本函数需要9K栈
func4(); //本函数需要8K栈
func5(); //本函数需要9K栈
}
}

在超级循环中，分别调用了func1~func5这5个函数，他们的栈需求分别是10K、5K、9K、8K、9K。调用func1时，系统分配10K的ram作为栈，func1函数返回，这10K空间将被释放，并且再次分配给func2使用，所以，整个程序的栈需求，就是这5个函数中需要栈最多的那个函数需要的栈空间：10K。

如果要把这个程序移植到OS下，最简单的方法就是创建5个线程来调用func1~5这5个函数，这5个线程需要的栈分别是10K、5K、9K、8K、9K，而这5个栈是独立的，不能共用，程序总共需要的栈空间是（10+5+9+8+9）=41K，线程栈一般是从堆中动态分配的，考虑到动态分配本身的开销，硬件须准备50K以上的内存用于程序的运行栈。一下子增长到5倍，没想到吧。

可见，上操作系统，虽然操作系统本身不需要很大内存，但会极度增加应用程序的内存需求。做项目时，一是不要盲目上OS，要根据需求综合考虑，二是设计硬件系统时，应该充分考虑到内存方面的需求，配置充足的内存。

3、人

任何产品都是由人开发的，所以，讨论嵌入式产品开发的任何话题，都不能离开人的因素，科技以人为本嘛！从裸奔到操作系统，那么程序员，也将由编写裸奔程序转为在操作系统下编程。这些迅速、大量增加的程序员，他们可能习惯了在裸奔环境下编程，他们可能是化工、建筑、地质等不同行业的专家，他们也许已经上了年纪，没有太多的精力学习多线程编程等知识。然而，涉及到专业的程序，仍然离不开他们，如何从技术上降低他们的入门门槛，是一个亟需考虑的问题。但是，普通的操作系统下，你不掌握线程控制技术，就无法编写正确的程序。djyos允许你按事件编程，没有任何跟线程相关的api函数，无需程序员掌握线程技术，客观上降低了裸奔到OS编程的转换技术门槛。

嵌入式产品，与普通电子产品一样，开发过程都需要遵循一些基本的流程，都是一个从需求分析到总体设计，详细设计到最后产品完成的过程。但是，与普通电子产品相比，嵌入式产品的开发流程又有其特殊之处。它包含嵌入式软件和嵌入式硬件两大部分，针对嵌入式硬件和软件的开发，在普通的电子产品开发过程中，是不需要涉及的。嵌入式产品的研发流程具体如下图：

下面，针对嵌入式产品的开发过程中的各个阶段，我们进行详细探讨。

阶段1：产品需求

在这一个阶段，我们需要弄清楚的是产品的需求从何而来，一个成功的产品，我们需要满足哪些需求。只有需求明确了，我们的产品开发目标才能明确。在产品需求分析阶段，我们可以通过以下这些途径获取产品需求：

1、市场分析与调研，主要是看市场有什么需求,还有就是前沿的技术是什么（站在做一款产品的角度）；

2、客户调研和用户定位，从市场广大客户那获取最准确的产品需求（要注意分析市场，产品生命周期，升级是否方便）；

3、利润导向(成本预算)；

4、如果是外包项目，则需要我们的客户提供产品的需求（直接从客户那获取，让客户签协议）。

当一个项目做完的时候，如果客户突然又增加需求，增加功能，将导致你的项目周期严重拖延，成本剧烈上升，并且测试好的产品可能要全部重新测试，原本的设计可能将不会满足当前的要求，所以做项目之前，最好要跟客户把需求确定下来，并且签定一份协议，否则，你辛苦多少个日日夜夜，得到的将是一个无法收拾的烂摊子！

阶段2：产品规格说明

在前一个阶段，我们搜集了产品的所有需求。那么在产品规格说明阶段，我们的任务是将所有的需求，细化成产品的具体的规格，就比如一个简单的USB转串口线，我们需要确定产品的规格，包括：

1、产品的外观；

2、产品支持的操作系统；

3、产品的接口形式和支持的规范；

等等诸如此类，切记，在形成了产品的规格说明后，在后续的开发过程中，我们必须严格的遵守，没有200%的理由，不能随意更改产品的需求。否则，产品的开发过程必将是一个反复无期的过程。

《产品规格说明》主要从以下方面进行考虑：

1、考虑该产品需要哪些硬件接口；

2、产品用在哪些环境下，要做多大，耗电量如何。如果是消费类产品，还跟设计美观，产品是否便于携带，以确定板子大小的需求，是否防水；

3、产品成本要求；

4、产品性能参数的说明（例如交换机，如果是百兆的速率，用于家庭和一般公司；如果是用于整个省的交换，那设计的速率肯定数十万兆以上了）所以说，产品性能参数的不同，就会影响到我们设计考虑的不同，那么产品的规格自然就不同了；

5、需要适应和符合的国家标准，国际标准，或行业标准。

阶段3：产品总体设计方案

在完成了产品规格说明以后，我们需要针对这一产品，了解当前有哪些可行的方案，通过几个方案进行对比，包括从成本、性能、开发周期、开发难度等多方面进行考虑，最终选择一个最适合自己的产品总体设计方案。

在这一阶段，我们除了确定具体实现的方案外，我们还需要综合考虑，产品开发周期，多少人月的工作量，需要哪些资源或者外部协助，以及开发过程中可能遇到的风险及应对措施，形成整个项目的项目计划，指导我们的整个开发过程。

阶段4：产品概要设计

产品概要设计主要是在总体设计方案的基础上进一步的细化，具体从硬件和软件两方面入手：

硬件模块概要设计

硬件模块概要设计，主要从硬件的角度出发，确认整个系统的架构，并按功能来划分各个模块，确定各个模块的的大概实现。首先要依据我们到底要哪些外围功能以及产品要完成的工作，来进行CPU 选型（注意：CPU一旦确定，那么你的周围硬件电路，就要参考该CPU 厂家提供的方案电路来设计）。然后再根据产品的功能需求选芯片，比如是外接AD还是用片内AD，采用什么样的通讯方式，有什么外部接口，还有最重要的是要考虑电磁兼容。

一般一款CPU 的生存周期是5-8年，你考虑选型的时候要注意，不要选用快停产的CPU，以免出现这样的结局：产品辛辛苦苦开发了1到2 年，刚开发出来，还没赚钱，CPU又停产了，又得要重新开发。很多公司就死在这个上面。

软件模块概要设计

软件模块概要设计阶段，主要是依据系统的要求，将整个系统按功能进行模块划分，定义好各个功能模块之间的接口，以及模块内主要的数据结构等。

阶段5：产品详细设计

硬件模块详细设计

主要是具体的电路图和一些具体要求，包括 PCB和外壳相互设计，尺寸这些参数。接下来，我们就需要依据硬件模块详细设计文档的指导，完成整个硬件的设计。包括原理图、PCB 的绘制。

软件模块详细设计

功能函数接口定义，该函数功能接口完成功能，数据结构，全局变量，完成任务时各个功能函数接口调用流程。在完成了软件模块详细设计以后，就进入具体的编码阶段，在软件模块详细设计的指导下，完成整个系统的软件编码。

一定要注意需要先完成模块详细设计文档以后，软件才进入实际的编码阶段，硬件进入具体的原理图、PCB实现阶段，这样才能尽量在设计之初就考虑周全，避免在设计过程中反复修改。提高开发效率，不要为了图一时之快，没有完成详细设计，就开始实际的设计步骤。

阶段7：产品调试与验证

该阶段主要是调整硬件或代码，修正其中存在的问题和BUG，使之能正常运行，并尽量使产品的功能达到产品需求规格说明要求。

硬件部分：

1、目测加工会得PCB 板是否存在短路，器件是否焊错，或漏焊接；

2、测试各电源对地电阻是否正常；

3、上电，测试电源是否正常；

4、分模块调试硬件模块，可借助示波器、逻辑分析仪等根据。

软件部分：

验证软件单个功能是否实现，验证软件整个产品功能是否实现。

阶段8：测试

功能测试（测试不通过，可能是有 BUG）；

压力测试（测试不通过，可能是有BUG 或哪里参数设计不合理）；

性能测试（产品性能参数要提炼出来，供将来客户参考，这个就是你的产品特征的一部分）；

其他专业测试：包括工业级的测试，例如含抗干扰测试，产品寿命测试，防潮湿测试，高温和低温测试（有的产品有很高的温度或很低的温度工作不正常，甚至停止工作）。

有的设备电子元器件在特殊温度下，参数就会异常，导致整个产品出现故障或失灵现象的出现；有的设备，零下几十度的情况下，根本就启动不了，开不了机；有的设备在高温下，电容或电阻值就会产生物理的变化，这些都会影响到产品的质量。这里要引出一个话题，工业级产品与消费类产品有什么区别呢？工业级的产品就要避免这些异常和特殊问题，有的产品是在很深的海里工作，或者在严寒的山洞工作，或者火热沙漠工作，或者颠簸的设备上，比如汽车；或者是需要防止雷击；所以这就是工业级产品跟消费类产品的区别，消费类的产品就不需要做这么多的测试。

阶段9：产品

通过上一阶段完整测试验证，在此阶段，即得到我们开发成功的产品。在此阶段，可以比较实际的产品和最初的形成的产品规格说明，看经过一个完整的开发过程，是否产品完全符合最初的产品规格说明，又或者，中途发现产品规格说明存在问题，对它进行了多少修改呢？

下面说说嵌入式硬件开发流程，一般分为8个阶段：

嵌入式产品的硬件形态各异，CPU 从简单的4 位/8 位单片机到32 位的ARM处理器，以及其他专用IC。另外，依据产品的不同需求，外围电路也各不相同。每一次硬件开发过程，都需要依据实际的需求，考虑多方面的因素，选择最合适的方案来。

硬件阶段1：硬件产品需求

和普通的嵌入式产品需求一样。阶段1：产品需求。

硬件阶段2：硬件总体设计方案

一个硬件开发项目，它的需求可能来自很多方面，比如市场产品的需要或性能提升的要求等，因此，作为一个硬件设计人员，我们需要主动去了解各个方面的需求并分析，根据系统所要完成的功能，选择最合适的硬件方案。

在这一阶段，我们需要分析整个系统设计的可行性，包括方案中主要器件的可采购性，产品开发投入，项目开发周期预计，开发风险评估等，并针对开发过程中可能遇到的问题，提前选择应对方案，保证硬件的顺利完成。

硬件阶段3：硬件电路原理图设计

在系统方案确定后，我们即可以开展相关的设计工作，原理设计主要包括系统总体设计和详细设计，最终产生详细的设计文档和硬件原理图。

原理设计和PCB

设计是设计人员最主要的两个工作之一，在原理设计过程中，我们需要规划硬件内部资源，如系统存储空间，以及各个外围电路模块的实现。另外，对系统主要的外围电路，如电源、复位等也需要仔细的考虑，在一些高速设计或特殊应用场合，还需要考虑EMC/EMI等。

电源是保证硬件系统正常工作的基础，设计中要详细的分析：系统能够提供的电源输入；单板需要产生的电源输出；各个电源需要提供的电流大小；电源电路效率；各个电源能够允许的波动范围；整个电源系统需要的上电顺序等等。

为了系统稳定可靠的工作，复位电路的设计也非常重要，如何保证系统不会在外界干扰的情况下异常复位，如何保证在系统运行异常的时候能够及时复位，以及如何合理的复位，才能保证系统完整的复位后，这些也都是我们在原理设计的时候需要考虑的。

同样的，时钟电路的设计也是非常重要的一个方面，一个不好的时钟电路设计，可能会引起通信产品的数据丢包，产生大的EMI，甚至导致系统不稳定。

原理图设计中要有“拿来主义”！现在的芯片厂家一般都可以提供参考设计的原理图，所以要尽量的借助这些资源，在充分理解参考设计的基础上，做一些自己的发挥。

硬件阶段4：PCB图设计

PCB 设计阶段，即是将原理图设计转化为实际的可加工的PCB 线路板，目前主流的PCB设计软件有PADS、Candence 和Protel 几种。

PCB 设计，尤其是高速PCB，需要考虑EMC/EMI，阻抗控制，信号质量等，对PCB设计人员的要求比较高。为了验证设计的PCB 是否符合要求，有的还需要进行PCB 仿真。并依据仿真结果调整PCB的布局布线，完成整个的设计。

硬件阶段5：PCB加工文件制作与PCB打样

PCB 绘制完成以后，在这一阶段，我们需要生成加工厂可识别的加工文件，即常说的光绘文件，将其交给加工厂打样PCB空板。一般1~4 层板可以在一周内完成打样。

硬件阶段6：硬件产品的焊接与调试

在拿到加工厂打样会的 PCB 空板以后，接下来我们，需要检查PCB空板是否和我们设计预期一样，是否存在明显的短路或断痕，检查通过后，则需要将前期采购的元器件和PCB 空板交由生产厂家进行焊接（如果PCB电路不复杂，为了加快速度，也可以直接手工焊接元器件）。

当PCB 已经焊接完成后，在调试PCB之前，一定要先认真检查是否有可见的短路和管脚搭锡等故障，检查是否有元器件型号放置错误，第一脚放置错误，漏装配等问题，然后用万用表测量各个电源到地的电阻，以检查是否有短路，这样可以避免贸然上电后损坏单板。调试的过程中要有平和的心态，遇见问题是非常正常的，要做的就是多做比较和分析，逐步的排除可能的原因，直致最终调试成功。

在硬件调试过程中，需要经常使用到的调试工具有万用表和示波器，逻辑分析仪等，用于测试和观察板内信号电压和信号质量，信号时序是否满足要求。

硬件阶段7：硬件产品测试

当硬件产品调试通过以后，我们需要对照产品产品的需求说明，一项一项进行测试，确认是否符合预期的要求，如果达不到要求，则需要对硬件产品进行调试和修改，直到符合产品需求文明（一般都以需求说明文档作为评判的一句，当然明显的需求说明错误除外）。

硬件阶段8：硬件产品

我们最终开发的硬件成功。一个完整的，完成符合产品需求的硬件产品还不能说明一个成功的产品开发过程，我们还需要按照预定计划，准时高质量的完成，才是一个成功的产品开发过程。

来源：互联网（版权归原著作者所有）