标签：
以上建议必须有的人员为：开发负责人、开发人员，最好有测试人员，因为这直接关系到最终产品的实现和质量。
一般该步骤需要开发团队负责人（有时也会整个团队参与）与需求提供方开会（或其他形式）沟通，来了解需求；然后，根据客户需求进行需求分析，可以出一份分析报告，比如直接出需求分析报告或需求设计文档；最后，根据分析结果或需求设计进行进一步的沟通来确定需求。
该步骤一搬能解决70-80%左右的需求，因为开发阶段或者开发后期肯定会出现新的需求或在对已有需求的进行修改，但是这已经可以开始考虑系统的设计和开发了。
在大致的需求定下来之后接下来该着手设计系统了，这个环节可以考虑和团队中一些经验较丰富，技术较好的同事一起讨论设计，但一定要注意效率，不要一味地讨论，而不定不下来设计方案。
最后对系统的设计定好后就要好好设计每一部分的具体实现了，这时一般就是写详细设计文档（也有边开放边设计、或者开发后补设计的，但我不建议这样，至少也要尽量做到设计一部分就开始进行这一部分的开发），详细设计的目的是为后面的开发进行服务和约束的。
服务体现在在开发的时候可以直接参考详细设计就很快明白如何实现，而不再需要重新考虑应该怎么实现，以此来提高开发效率。
约束体现在在开发时以免忘去最初的想法，而采用其他方式实现（很有可能实现的原来或结果都出现很大差异），最终很有可能偏离原本的初衷，从而影响系统的开发进度、质量等，导致很大不良后果。
根据设计阶段的设计指导开发团队进行系统的开发。
在系统的开发过程中和系统部分功能开发完成后以及最后全部完成后都需要进行测试，也就是测试是分布在开发过程中的各个阶段。
开发完成后，最终测试完毕就可以交付系统了，此时的系统应该以及实现主要功能、不应该存在明显BUG，基本能够保证日常使用。
最终完成后后续还需要不断升级，进行修复和增加新的功能。
在以前的开发中大多数采用的是瀑布是的流水线式的开发，这种开发方式有很多问题，经常会影响实际的开发进度、开发质量、甚至导致最终的项目失败。
现在一般不会采用这种单纯的开发方式。我认为可以考虑分步分阶段的方式进行。因为在实际开发过程中经常会遇上需求变更的问题，甚至有时会推翻前面的重新再来；或者最初设计的问题导致开发难以进行下去；人员流动带来的种种问题等等。所以，我觉得按照以下的方式进行开发会有很大好处：
首先，前期确定大致需求后先定好系统架构，各功能模块的设计，把核心的功能确定后先设计出一套可行的方案，最好能出一个简单的DEMO，可以不实现具体功能，但要能够说明对需求的实现，能够让用户看懂你的实现方式，目的是让用户再次确定需求。如果这一步没有问题，那就可以开发这部分功能了，其他系统功能类似。
（这个步骤肯能会贯穿到系统开发的中前期，一般很少有到后期还做大量的调整和修改的，如果有小的调整也需要在确定需求后再去做后面的步骤）
第二步，开发已确定部分的功能，并最好能够在开发时每开发一个实现方法测试一个（最好能做到这一点，这会对后续的测试和BUG的修改都有帮助——很多问题都会在这时就被发现，可以节省后期的工作量，一般这种测试被叫做单元测试）。在开发完一个功能或一个完整的模块后也要进行整个功能模块的测试，这可以发现一些在单元测试阶段不能发现的问题。另外，在每次提交一个测试好的功能后最好能进行代码审查，最好由经验丰富、技术较强的开发人员，或者技术负责人来审查，这个过程目的是及时的发现不规范的代码——规范代码和规范开发的目的是为了以后的代码维护和其他开发人员修改提供方便——个性的代码书写少了，理解的过程就会大大缩短。
（建议单元测试、功能测试等各种测试和代码审查要贯穿在整个的代码编写的开发阶段）
第三步，在开发进行一定的时间后，经常会出现新的需求或者需求的变更，所以，我们需要再次的了解需求和确认，以便能够及时更正系统设计时的不足或者开发产生的偏差，如果最后或者后期才去做这些，到时候系统的架构就已经无法修正，即便只是一个小模块很可能都很难修改了。所以，这个过程很重要，而且，需要在整个开发阶段中不断的重复执行，不断的修正系统的设计和开发。——需要注意的是，这里所说的修正系统设计并不是说系统的整体框架或者核心的结构可以随便修改，这些一般在定下来之后除非非常严重的问题，导致无法进行后续开发是不能调整和修改的，尤其是在中后阶段更不能调整核心设计。没有任何设计开始就说完全合理的，所有，允许一定的调整，但一般会在后面需要调整的会越来越少，最后能够达到局部的、小范围的修改代码就比较理想了。
（阶段性的需求确认、系统的重构等工作基本会不断的重复，一般需求确认是贯穿编码的大部分时间的，而且要视情况而定，不能机械的固定执行；系统重构需要慎重考虑——最好能够在前期稳定下核心架构，不随便修改。一般代码级的重构较多，而且多数在中后期考虑）
第四步，在第三步后一定会有对系统架构或代码方面的变化，此时一定要做第二步中说到的一些测试，而且，很有可能在修改了某一功能后还要进行相关功能的联合测试，以保证修改的功能测试通过的同时不会影响到其他功能、不会影响到整个系统的完整性、稳定性、高效性。
（测试很重要。一定优先保证系统的稳定性，其次考虑效率问题）
最后，在开发过程中多次重复第三、四步的工作后基本就能保证系统的顺利完成了，在系统的开发后期和完成阶段一定要进行整体的测试，这个也很重要，他会影响到最终的上线。在团队内部测试完成后，没有其他变化后，可以考虑上线测试，也就是发布一个测试版，公开到用户那里小范围的使用和测试，此时，主要需要做的是采集用户意见、收集实际运行中的问题、系统BUG（BUG基本不能消除，但是，一些无关紧要的小问题可以不必太计较），然后在根据收集的信息进行分析，根据轻重缓急在此安排版本修订，在基本满足需求和基本没问题的情况下就可以发版了。后续需要注意的就是升级，任何产品、系统都需要不断的升级来不断的完善和优化。
如果可能得话，在系统设计中最好能够融合进好的日志系统，在日志系统中要有分析模块，这个主意是用来收集系统在运行中的问题和日常使用中的一些正常或异常信息，主意是异常信息，通过分析模块来判断问题的严重性、出现频率等，来帮助对系统的使用情况分析和日后的修复、升级、优化等的工作安排。
标签：
原文地址：http://www.cnblogs.com/KeSaga/p/4390677.html
