项目开发流程总结

这一年来基本只在开发一下小项目，有多小呢，一个硬件工程师，一个嵌入式软件工程师，一个结构工程师，一个PC上位机开发工程师，还有市场SE，PM、OPM。项目虽小，五脏俱全，硬件工程师是一个系统性思维很强的人，从她身上我也学到，慢慢地自然而然开始思考如何去做一个产品。也可以说，我们之间互相推动着，最终把这件事给做好了。

T0：硬件工程师首先明确了系统需要获取那些信息，要设计什么硬件功能，选型，还要考虑供应商情况，备货周期，画完原理退后，出一份设计文档，描述嵌入式软件要使用哪些接口，控制什么电平达到什么效果等等，写这个文档过程她也对自己的原理图设计做了一次review,方案设计出来后，组织硬件工程师组内review。

软件工程师维度，初步设计方案功能，将主要的feature转化为详细的功能，设计协议，初步考虑软件架构，对于一些继承性较强的公司，可能会有通用平台，软件架构的设计就转化为对平台的应用，组织功能定义review。

T1: 实现基本功能，软件、硬件bring up，这个时候可能会发现一些设计缺陷，以及功能缺失，硬件进行迭代。硬件与软件配合做信号完整性分析，修复设计缺陷但未暴露出问题，软件制定开发优先级，实现了主要的功能点，满足demo需求。一个嵌入式项目有很多东西是通用的，log记录用于定位查找问题，升级是必须的，测试接口定位硬件问题，说着说着没有突出重点。

我想说的是，一个项目，从市场SE来了需求，很多是非专业的，所以有些也是不可实现的，这个时候需要对需求整理，以及讲清楚将做哪些，哪些不做，将需求转化成开发可执行的文档，SE写的是porposal，作为开发人员，要写出feature list，还有制定功能开发的优先级，以及每个节点要达到哪些目标，接下来就是书写软件设计文档，在软件开发过程中不断补全开发文档，对一些调试bug也记录下作为调试笔记，人类学习很大一部分就是总结，跟应试教育的时候做错题本类似，这些记录下的问题在空闲时候又被翻阅，就能极大地避免以后犯同样的错误。软件设计文档对于功能逻辑部分要划分成不同模块，画出流程图，以前上学时，我总觉得写个C语言还要画流程图好麻烦，确实对于简单的设计那就是麻烦，对于有一点逻辑复杂，流程图能很好地帮你梳理程序逻辑，避免做出一些错误的设计，而且当程序跟着流程图去设计，你也会发现整个程序非常清晰，也不容易出现问题。当然，在这个项目开发前，我还没有这样的觉悟，而在我后来补充软件设计流程图中，我发现了一些设计的逻辑错误，如果没有去梳理流程，那些bug将造成严重的影响，因为有些不容易被发现。

在我完成了log设计，升级，加密芯片的设计，保护程序安全，之后，我接到一个通知，需要对软件可靠性做测试，当时在我的理解维度里，硬件通过高低温做老化，可以测试硬件可靠性，软件的可靠性是怎么定义的呢？后来，我了解到是用测试用例覆盖来证明软件的可靠，所以，接下来就是写测试用例，测试用例分几个维度写，硬件测试、协议测试（参数遍历）、压力测试、异常case测试、老化测试、用户视角测试 .etc,在写这些测试用例过程中，我也对着程序做了一遍检查，是不是满足这些要求，也发现并解决了一些问题，这些还是在真正测试之前就解决的问题。之后就是执行测试用例，修复设计存在的问题，观察现象是否是满足期望，不满足时就要去解决它。

产品的功能，其实决定于一个工厂师的品味，有些东西你可能不做也行，但是你觉得那样做更好，这个时候请跟随你的品味走，因为这样你至少能输出自己的品味，结构外观也是结构工程师的品味。

做了测试后，就是准备pre-p0,要生产就要治具，所以也要着手开发治具，治具的目的就是检测电源与链路，电压对不对，链路通不通，这次治具的设计是硬件工程师主导的，她做了全功能测试检查，每个MOS的开关作用都做了检查设计，后来这个治具的开发让我基本在工厂蹲了一周（因为治具太大，需要用到气泵，只能在工厂调试）。治具的加工工差导致了有些探针下压后没有对准，造成测试失败，这个问题是板子比较大，累计公差，还有就是硬件工程师留的测试点还可以更大，有些相邻较近的电是比较小的

有了治具，可以走生产了，生产流程需要上位机开发支持，于是我们制定了每个工位要做什么，以及我写了每个工站的上位机开发需求，生产流程的梳理是一件很有意思的东西，我们讨论了一遍又一遍，来料检查之类的，MES过站要怎么做，数据要怎么上传记录，要能追溯产品的品质。

还有一点，可靠性测试，pre-p0,p0,p1,p2，每次试产的产品都需要做可靠性测试，以说明这批次的生产没有问题，有问题就要改进工艺，以期望做到下一批次没问题，可靠性测试文档一开始是SE同事参照同类产品写的，我看了之后发现很多不可执行的东西，功能正常没有定义怎么检查才算正常，后来，我又开发了测试状态输出，以及完成文档该怎么检查，可惜工厂工人的执行力太差，最终效果只能发现一些很肤浅的问题，做坏没坏的区分，后来我也与QA去参与可靠性测试，验证一些重要功能。

我前面所述的，多是站在一个嵌入式工程师的维度去看这个项目，项目的分工不一样，硬件工程师还要对接到生产相关，认证，结构工程师一直在做模具沟通，材料选择，处理工艺，结构选型，如螺丝啊之类。OPM组织开会，推动项目进展，PM协调资源，比如自动上传服务就是用到一个现有的方案，协调到资源就可以快速部署。