本文共 1215 字，大约阅读时间需要 4 分钟。

在一个项目开发过程中，有

1、项目开发前的项目估算；

2、需求获取与分析阶段（相关人员理解需求）；

3、设计阶段（包括概要设计，详细设计）；

4、编码阶段（开发阶段）；

5、测试阶段；

项目开发过程中，一般工作量的划分是 需求分析和设计阶段占了 1/3

                                                                       编码阶段占了 1/3

                                                                       测试阶段 1/3

项目开发过程中的一些心得：

开发人员在按照软件开发流程的执行过程当中，在编码前一定要在设计阶段，尽量将设计的工作考虑的完整点，不要进行了局部设计后，就自我感觉没什么问题了开始编码，这样做的话，开发人员在后期系统重构中会增加自己的麻烦。

需求阶段过程中，将每个需求分配到相应的开发人员，相应的开发人员再根据各自的需求编写需求文档，该文档不仅体现出开发人员该做什么，更应该体现出测试的相关功能点，即测试人员看了后能够知道他们该测什么。

相关开发人员编写完自己的需求文档后，先在线交叉评审下，将有疑问的地方打上批注，之后就有疑问的地方进行一次会议。

会议后，让相关人员进行一次修改，都修改完后，再进行一次会议，看需求是否还有哪不太明确或有疑问，注意，整个需求分析过程中，测试人员也应该参与其中，以便测试人员可以根据他们以后测试方面提出相应的疑问。

概要设计阶段，在概要设计时，开发人员也应该考虑到测试的测试入口，即应该站在测试的角度想，他们到时应该怎么测，给他们预留测试口。

在需求分析过程中，开发和测试在需求分析上都统一后，即每个人都觉得在需求这一块都理解，没有什么疑问了。架构师应提供整个系统的架构，然后让相关人员参与开一次会议，让相关人员进行理解，看是否有什么疑问（若是没有架构师，就项目经理带着大家一起对已经确定的需求进行一个系统的架构，架构过程中首先要考虑一下相关需求的一些技术选型的问题。）若是整个系统的架构大家都觉得没什么问题，开发人员就可以进行相关的设计以及编码开发工作了。

而一般小公司，由于给的项目时间仅，可能就不是按照上面的流程来了，如给开发人员一个其实很粗糙的需求文档，开发人员按他理解确认后，就直接进行编码开发了，开发完自测后，就转测，这样转测，经常会出现这种事情，测试还问开发人员该怎么测。这其实挺无语的，按理说测试应该比开发人员更了解业务啊，可测试人员还问开发人员该怎么测，那不是按照开发人员的思路来了吗，QA这样测的意义就不大了。

所以这样的开发流程，真的很不好。而且出现问题的概率还很大，导致问题回溯周期拉长了，成本自然也就高了。

编码阶段，可以每周的周一开个例会，有必要的话，也可以每日晨会，目的是为了了解整个项目中相关负责人的开发进度以及询问了解下他们开发过程中是否遇到问题（技术问题？需求问题？约定问题等？） 

 按照定好的项目进度进行开发，开发到某个阶段时若是觉得项目时间上有点紧，可以让大家加下班，赶下进度，尽量让项目往前赶，不要往后延，以便项目能按预期完成。

软件工程各阶段会产生的软件文档，请移步：

转载地址：http://lgoxi.baihongyu.com/