整个开发流程分为：需求分析、需求评审、设计、设计评审、编码、代码评审、自测方案、自测方案评审、自测、功能测试、集成测试。

　　1. 需求分析

　　输入：系统规格说明书、RFC(如果有)和其他厂家的相关文档。

　　输出：等待评审的需求说明书

　　需求分析阶段是整个开发过程中最重要的阶段，可以说他几乎决定了整个项目开发成败。一个在项目开发后期进行频繁需求变更的项目注定不会成功的(我们为此交了很多学费)。值得庆幸的是，我们的路由器和交换机的模块开发的需求比较固定，变化较小。这就为我们细致规范地定义需求提供了最大的保证。

　　在需求阶段，整个开发团队的组成包括：模块负责人，1-3开发人员，1个测试人员。测试人员在需求开发阶段的紧密介入保证了功能测试方案的编写和需求文档的严格一致性。在需求分析阶段，模块负责人召集大家一起进行需求的研究，包括系统规格说明书，RFC和别的厂家(Cisco、华为等)路由交换设备的功能实现的研究。在阅读文档和研究阶段，应该经常进行碰头讨论，最好1-2天进行一次会议进行交流大家阅读的心得，除了大家可以取长补短外，还可以更好的把握整个需求开发的进度。随着大家的学习交流讨论，需求分析文档应该严格按照需求分析模板成文。注意除了RFC文档和其他的厂商的标准研究外，还可能包括性能需求，可移植性需求、整个模块和其他系统之间的接口分析。需求分析文档完成后，应该达到如下标准：

　　1. 完整包含了将要实现的RFC文档的所有要点，不需要再阅读RFC文档

　　2. 根据需求分析文档能够完成设计文档

　　okay，经过大家的艰苦努力，终于提交了经过开发团队内部讨论的需求分析文档

　　2. 需求评审

　　输入：等待评审的需求说明书

　　输出：进入受控库的需求说明书，评审会议纪要

　　为了保证评审效果，需求分析文档将提前若干天(根据需求分析文档的难度确定)发送到各个评审人员的手中，评审人员包括：

　　1. 开发团队成员

　　2. 其他相关模块开发人员

　　3. 总体组相关成员

　　4. 测试组相关成员

　　5. 其他相关成员

　　为了提交评审人员的积极性，对参加评审的人员实行打分制。根据参加评审人员发现的问题的种类进行打分量化考核，分为致命、严重和一般三档。致命3分，严重2分，一般1分。

　　评审的结论分为三类：通过，修改后通过和修改后再次评审。通过表示这份文档通过，可以进行受控库;修改后通过表示有一些小问题，修改后在网上进行评审后没有问题进行受控库;修改后再次评审表示文档存在重大问题，它是一票否决制，只要参加评审人员中一个人提出就按照这个意见进行，开发团队进行修改后重新进行需求评审。

　　艰难的需求分析评审过程终于过去了，这个阶段将产生如下文档：

　　1. 进入受控库的需求分析文档

　　2. 相关评审会议纪要

　　这些评审的会议纪要记录着我们需求分析过程中发现的各种问题，在整个项目结束后，在项目总结将对各个模块的需求分析评审产生的会议纪要进行分析和归类，对有共性的问题加入到需求分析的checklist。

　　在需求分析完成后，将对整个模块的开发计划进行一次重新评估，进行必要的调整，调整后的计划将作为KPI考核的依据。

　　需求分析文档进入受控库后，对它的任何修改都必须向需求变更委员会提交需求变更申请。否则需求分析文档规定的内容必须不打折扣地完成。

　　3. 设计

　　输入：进入受控库的需求说明书

　　输出：等待评审的设计说明书

　　这个阶段，测试组人员将推出开发团队，进行功能测试方案编写。模块负责人根据具体情况决定是否退出，但是不允许开发团队由一个开发人员构成。模块负责人即使退出，仍然对这个开发团队的进度负责，应该参加这个开发团队的设计讨论会议，提出自己的设计意见。模块负责人退出后，必须指定一个模块主负责人。设计文档的一级数据流图和接口关系应该由开发团队(包括模块负责人)进行讨论完成，在进行更细致的设计过程中，最好在小的阶段点(2-3天)进行一次会议进行交流大家各自的设计思路，在这个过程中，有可能对一级数据流和接口关系进行修改。如果有需求变更，必须向需求变更委员会提交需求变更申请。

　　我们离成功又进了一步，精心完成地设计文档提交评审了。

　　4. 设计评审

　　输入：等待评审的设计文档

　　输出：进入受控库的设计文档，设计文档评审会议纪要

　　为了保证评审效果，需求分析文档将提前若干天(根据设计文档的难度确定)发送到各个评审人员的手中，评审人员包括：

　　1. 开发团队成员

　　2. 其他相关模块开发人员

　　3. 总体组相关成员

　　4. 测试组相关成员

　　5. 其他相关成员

　　设计评审人员必须仔细关注设计文档是否满足了所有的需求定义。

　　其他措施和需求评审一样。

　　终于到了编码环节。

　　5. 编码

　　输入：进入受控库的设计文档

　　输出：等待代码评审的代码

　　开发团队根据设计文档和编程规范进行编码。终于不用经常开会了，专心致志!!

　　看见了产品的雏形了。

　　6. 代码评审

　　输入：等待代码评审的代码，这些代码应该是被编译通过，消除了所有的warning

　　输出： 完成评审的代码和代码评审记录

　　为了保证评审效果，代码将提前若干天发送到各个评审人员的手中。参加代码评审的人员包括开发团队的所有成员，模块负责人应该尽可能参加。代码评审对我们现阶段的开发过程是十分必要的，代码评审的目的：

　　1. 验证代码是否和设计文档吻合;

　　2. 验证编程规范是否得到了执行;

　　3. 根据代码评审checklist检查代码;

　　4. 开发团队成员可以各自熟悉相互的代码，为以后bug修改阶段相互评审修改的代码打下基础;

　　5. 在代码评审的过程中，开发团队成员可以相互交流编程心得体会，共同提高编程能力。

　　代码评审可以采用横向或者纵向的方式进行，横向就是在一个单位时间内评审一个开发人员完成的代码;纵向是以数据流为导向，评审代码。评审中发现的具有共性的问题应该记录下来，可以用来扩充我们的代码评审checklist。

　　我们已经看到了成功的彼岸，但是我们能够到达吗?

　　7. 自测方案

　　输入：进入受控库的设计文档，经过代码评审的代码

　　输出：等待评审的自测方案

　　自测方案的编写是我们以前的开发流程中被忽视的流程，开发人员往往凭经验进行模块的自测，模块的自测力度往往不够大，太多的bug被带入到了测试组的功能测试中，在bug越在后期发现修改花费的代价越高，所以在现阶段自测环节应该重点加强。自测方案应该根据设计文档和代码情况来设计测试用例。好的测试用例的设计和开发人员的经验有关，刚开始要完成一个好的自测方案可能有些困难，有一些bug会从我们的自测方案漏过，但是它们有可能会被测试部发现。对于测试部报告的bug除了进行分析修改外，还应该根据它们总结经验教训，修改我们的测试方案。另外我们在设计用例时应该尽可能考虑到测试的自动化，测试的自动化是测试发展的潮流。可以使我们的回归测试节约大量的时间。在写测试方案的过程中，开发团队成员应该多多进行一些非正式的交流，多多的讨论交流总是没有坏处的。

　　8. 自测方案评审

　　输入：等待评审的自测方案

　　输出： 进入受控库的自测方案和评审记录

　　为了保证评审效果，自测方案文档将提前若干天发送到各个评审人员的手中，评审人员包括：

　　1. 开发团队成员

　　2. 测试组相关成员

　　3. 其他相关成员

　　大家对于自测方案的评审应该抱着一种从“鸡蛋里挑骨头”的心态，应可能的发现自测方案没有覆盖到的漏洞。在我们现阶段的自测方案的评审环节中，测试部成员应该发挥重要的作用。

　　其他措施和需求评审一样。

　　我们离成功的彼岸越来越近了，但是有可能是我们的错觉?

　　9. 自测

　　输入：进入受控库的自测方案，经过代码评审的代码

　　输出：自测报告和经过测试的代码

　　在自测环节中，开发团队成员按照自测方案的测试用例进行测试。首先进行各个模块的自测，各个模块自测完成后，所有的模块连在一起再进行测试。在自测过程中，如果开发团队较大(3人)，在模块集成测试阶段，可以考虑引入日集成机制进行测试(后面有详细的描述)。为了更好地反映进度情况，可以把所有的测试用例做成小图表，当某一个测试用例通过后，打上记号，这样开发团队甚至团队外的人员也可以清楚地知道各个模块的测试进度。

　　如果我们前面的每一个环节都到位地执行了，现在我们应该对我们的模块充满信心，等着测试部的好评。

　　10. 功能测试

　　目前工作就交给测试部了，如果我们前面的工作做的很好，现在就比较轻松了，可以等着零bug的奖励(整个模块测试没有bug或者没有严重致命bug)，这一段时间整个开发团队可以开始进行总结或者下一个阶段工作的调研。根据我们的实际经验，在这一阶段，整个开发团队会有1/3 - 1/2的时间花在bug修改上及其相关工作上。

　　测试部总会有一些bug报告的，而且会有一些致命严重bug，这时候，开发团队按照以下的bug修改流程工作：

　　1. 修改bug

　　功能测试阶段，测试部发现的bug都在butterfly进行流转，通常关于这个模块的bug都会首先指定给模块负责人。模块负责人判断了情况后，将它转发给相关的开发人员。相关的开发人员应该对这个bug进行判断，修改。如果这个bug比较难，模块负责人应该召集大家一起攻关，必要的时候可以向整个项目的技术负责人寻求支持。

　　2. 修改代码评审

　　bug修改完毕后，由开发团队的另一个人对bug修改进行审核，这样作的好处是防止bug修改引入另外的bug。这个环节在butterfly上有定义。

　　3. 根据bug修改情况修改自测方案

　　这个bug从我们的自测方案的筛子漏过，说明了我们的自测方案还有缺陷，这时候应该根据bug情况修改自测方案，使之能够覆盖这个bug。

　　4. 重新自测(可选)

　　这个环节有开发团队负责人掌握，如果功能测试出现的问题较多，应该重新按照自测方案进行自测。如果我们自测方案的自动化程度较高，可以考虑对每次修改都进行自测。

　　整个模块的开发到这个时间点，应该算是基本成功，下面我们将迎接最后一个挑战，集成测试。

　　11. 集成测试

　　集成测试也是由测试部进行的，它重点关注系统整体特性和功能，当几个模块功能测试完成后，所有的模块合在一起进行集成测试。由于经过了各个模块功能测试的筛子，在这个阶段出现的bug都是比较难以解决的，而且各个bug之间也许会有一些关联。

　　在这个阶段发现的bug将被首先指定给项目的技术负责人(如果这个问题比较确定，也可以直接发送给模块负责人)，技术负责人经过评估判断后，分发给各个模块负责人，然后各个模块负责人再分发给各个开发人员。

　　在集成测试bug修改阶段阶段，整个项目组的开发人员采用日集成方法。开发人员每天修改+评审+测试自己的代码，完成后上载到vss(clearcase)上，项目技术负责人(或者版本编译人)每天编译新的.o文件提供给大家进行新的修改测试。如果模块A的修改影响了模块B，在第二天的模块B修改测试中应该可以反映出来，模块A很容易知道是那个修改导致了模块B的错误。当集成测试bug修改到了一定程度(比如修改了一周)，系统中所有的模块(不管有没有改动)都应该重新进行一次完整的自测，这时候就能看出各个模块自动测试的好处了。在集成测试bug修改的过程中，修改代码评审和修改自测方案的环节依然应该保持。