软件模型能够协助开发人员了解、说明和沟通关于他们的代码和它有必要支撑的用户需求的主意。但不幸的是，嵌入式开发人员在开发软件模型方面是出了名的糟糕。以下是一些经历，每个开发人员在规划下一代嵌入式体系时都应该考虑。

　　假如方针清晰，模型能够让嵌入式软件开发人员在编写一行代码之前更好地了解体系。它们作为一种笼统，用于答复关于体系的特定问题。在开发人员开端随机填充模型之前，他们应该停下来界说模型的意图和要答复的具体问题。

　　为了协助指定意图，主张开发人员向模型增加一个任务声明来陈说其意图。一个简略的任务陈说不只能够作为一个提醒来辅导模型的开发者，还能够奉告未来的维护者模型的意图。

　　类图为嵌入式开发人员供给了一种界说软件块或类以及它们在软件体系中的交互的办法。然后，这些图表协助开发人员了解更大的图景，并看到不同的代码块将怎么相互作用。

　　一般开发人员取得或开发一个软件需求文档，然后用于开发软件的规划，那份文件很重要。开发人员能够使用UML用例图，以可视化和准确的办法建模和界说软件的需求。

　　假如一个问题有一个已知的解决方案，为什么要从头创造轮子呢?计算机科学为嵌入式开发人员供给了许多在简直每个嵌入式体系中遇到的常见问题的老练解决方案。规划形式为开发人员供给了一种使用别人经历的办法，比他们从零开端更快、更强健地开发体系。

　　嵌入式软件开发人员一般会在编写代码时检查他们的作业，但大部分测验真正是在最终进行的。一般，很多的代码被写出来，然后交给QA团队去证明没有缺点。

　　缺点发现得越早，本钱越低，因而，嵌入式体系的测验和验证应该在体系的每个阶段和迭代中进行。将体系分解成小块进行建模和测验，然后完成和测验，这是开端证明体系作业的一个很好的办法。跟着每一次迭代，能够增加更多的部分，在将更多的部分增加到体系之前，能够再次对这些部分进行测验和验证。

　　嵌入式开发人员在编写一行代码之前，需求更好地对他们的软件和体系进行建模。以上五条经历教训是开发人员开端构建更好的模型以发生更牢靠、更具本钱效益的体系的良好开端。