对硬件开发流程的一些朴素的认识

 转自：http://bbs.ednchina.com/BLOG_ARTICLE_3025509.HTM

第一次接触流程，是在毕业后进入第一家公司，听到同事在提A版、归档之类的名词，感觉非常的陌生。随着项目的进行，自己开始走各种不同的流程，一段时间非常的反感，甚至抵触，觉得天天都要关注并去催流程，严重影响了工作效率。再到后来，经历了一次内审和外审后，自己才开始真正的去思考流程，认识到流程其实是一种重要的管理手段，一个好的流程可以提高工作效率和输出质量。流程在于对过程的控制，而受控的过程必然能够保证产品的质量可靠。

        自己对于硬件开发的流程的理解如图1和图2所示：

图1 硬件开发流程框图1

图2 硬件开发流程框图2

        基本思想是使每一步流程具有严密的逻辑；每一步流程可操作；每一步流程的输入、操作及输出受控。

        1、硬件系统需求

        硬件系统需求直接来源于对产品需求的分解。个人觉得产品需求下尽量不要存在产品系统方案或总体方案等文档，再由系统方案分解出硬件、电源、软件、机械等需求。原因在于：

       (1) 个人觉得，这样的文档体系过于复杂，维护成本过高；

       (2) 另一点是在实际工作中的体会，一般这样的文档是需要多个专业组共同维护的，这种公共文档存在极高的出错可能。一方面，在变更管理中，各个专业组的受影响文档往往仅会到专业组需求级，而“惯性”地遗忘系统方案这一上层文档，造成公共文档处于无人维护状态；另一方面，即使某一专业组在变更管理中对公共文档进行了维护，但由于这份文档牵涉到其它专业组，存在误更改的风险。最后，系统方案等上层文档往往是由系统工程师完成的，由于其所处的层次，往往在文档撰写中具有随意性，会将某个专业组的需求放大或加入不相关的需求，从而造成测试的困难。比如，系统方案对硬件的描述为“具有报警音功能，且音量符合XX标准。”音量符合XX标准，往往应该是整机需要验证的内容，但现在却加入到了硬件需求中，而硬件可能并不具备相关的标准知识和测试手段去验证它，这就造成了无法封闭的可能性。

         在硬件系统需求阶段时，除了归档《硬件系统需求》文档外，还应当归档《硬件系统测试方案》。这样做的原因在于：在归档技术文件进行测试前，研发人员会对硬件各个版本进行自测，而此时测试方案未归档受控，这就存在“作假”的可能性，比如按照某一条判断标准，某项测试是不能通过的，如果分析认为此项FAIL不会带来影响，便不会从根本上去查找原因并进行更改，反而可能通过修改判断标准让此项测试得以PASS。另一方面，在需求提出时，测试方案也就应该提出了，测试项与需求项是一一对应的。

        在撰写需求和测试需求时，个人认为需要注意以下几点：

        (1) 对应性。硬件需求应与产品需求对应，不可多也不可少。少了则意味着需求没有被完全分解，有遗漏项；多了则意味着有错误的需求或不相关的需求。同理，测试方案应与需求对应，同样是不可多也不可少。

        (2) 准确性。需求是可验证的。所谓可验证，最简单的方法就是让很多个从未从事过此项测试工作的人，按照撰写的测试需求，可以进行测试操作并且得出的结论一致。下面这个例子便属于需求不准确所造成的不可验证：某项测试标准为“LED灯发出明亮的红光。”粗略一看，似乎没有什么问题，但如果实际去测试，就会发现“明亮的”无法验证，或者说不同的人去测试很有可能会得出不同的结论。

        2、硬件系统方案

        根据硬件系统需求，得到硬件系统方案，为硬件单元划分、互连的重要参考文档，关系硬件系统的架构。

        方案文档体现的是设计指导，是一种过程文档。虽然在一些审查中，不会被关注，因为审查一般的思维是“我需要实现什么需求？”和“这个需求最终有没有被验证实现”，因此其关注的重点更多在于需求类文档和测试类文档。但不能由此就轻视了方案文档。不同的设计虽然可以实现同样的功能，但一个好的稳定的方案，可以减少后续因不满足需求而导致的方案更改，同时还可使产品获得更高的性能、更低的成本。

        3、硬件单元需求

        硬件单元为最小可验证功能单元，不一定是指某一个单板，可能是实现某一个功能的所有单板组合。硬件单元需求来源于硬件系统需求，需与其对应。在归档硬件单元需求时，同样也需要归档硬件单元测试需求。

        4、硬件单元方案

       根据硬件单元需求，得到硬件单元方案，为硬件板卡原理图和PCB设计的重要参考文档。

        5、硬件单元测试

        硬件单元测试是对硬件单元需求的验证，其是在硬件单元测试方案的指导下进行的。

        如前所述，硬件单元测试需在板卡技术文件生效后进行。除此之外，还需要将测试用到的软件和工装生效，如果借用以前的工装，需要保证工装在校准有效期内；测试设备也同样需在校准有效期内。这样，测试所需的输入便全部受控。

        测试过程中，需要严格按照测试需求执行操作，并准确记录结果，每一项测试都应记录测试人和测试时间。

        测试完成后，需要输出并归档测试报告。如果测试发现问题，个人理解有两种封闭方法，有时考虑到更改成本，可以进行风险分析，按照严重程度和发生概率，如果在ACC内，便可通过出风险分析报告进行封闭；另一种方法则是启动变更管理对设计进行更改，升版DHF和DMR，并重新进行测试。

        6、硬件系统测试

        硬件系统测试是对硬件系统需求的验证，其是在硬件系统测试方案的指导下进行的。

        同样，在测试前，需将所有的输入归档受控；测试过程中，严格执行和记录；测试完成后，进行报告归档及问题处理。