开发一个项目需要那几个步骤

本人在两个中小型软件开发企业工作过几年，也做过几年的项目管理工作。走过一些弯路也得出一些项目管理方面的体会，在此进行总结，希望能够与其他一些项目管理人员或对项目管理有兴趣的同事共同探讨一些中小型项目管理的问题及方法。

大部分中小型软件开发企业的软件项目经常遇到的一些问题可能包括：项目时间紧、项目组成员经常加班；项目需求变更频繁；项目进行过程中可能就有项目团队成员离职或调离到其他项目组；项目重复性建设问题严重，每个项目都需要从框架开始重新开发，难以重用已有项目的成果等等。我觉得通过较好的规划和管理能够在一定程度上提高项目的成功率或者说提高项目的质量，降低开发成本，缩短项目开发时间。

我理解项目管理有两个大的划分方法一是通用的项目管理体系，也就是PMP中所说的5个项目管理过程组9个知识领域44个项目管理过程；二是具体业务领域的按项目生命期划分的各阶段的管理。本文主要从项目生命期各阶段的管理方面进行总结。

我个人分析一个软件项目生命期大体需要经过的流程（这只是我个人的一个划分，有可能不是很全面）：可行性分析、需求、设计、开发、测试、实施、维护、总结。

下面我针对每个阶段谈一下自己的体会。

一、可行性分析

一般的项目都是通过外部招标的形式得到的。对于有些公司在应标的时候对项目就要有个取舍。如果在特殊时期为了生存可能只要不是太赔的项目都会尽量承接。

但是一般项目在承接前最好在经济、技术等方面进行可行性分析，而且这种可行性分析最好是管理者、市场、技术等人员都参与，因为市场人员一般不懂（或不通）技术，技术不懂（或不通）市场，因此只有大家在一起共同分析讨论才能够得出比较可行的结果。可行性分析的结果一方面可以作为是否承接项目的依据，另一方面也可以作为承接项目方式或与客户谈判的依据。比如经分析项目工作量很大，如果按标书金额开发有可能会赔，那么可以与用户探讨是否将来能有个二期的项目；另外如果用户要求的时间比较紧，可是经分析很难按标书时间完成，那么也可以和用户同共探讨是否可以在正式签定合同时延长系统交付时间等。当然这些与用户的探讨工作一般是需要公司高层领导出面协调的，有时单独靠项目组是没有能力达成理想的结果的。

另外在此阶段最好对项目的成本和需要的资源进行一下估算。

二、需求

需求实际要细分为需求调研、需求分析、需求确认、需求管理等。

因为对于需求要想说清楚可能需要较长的篇幅，所以在此不进行展开。

在此只是先强调一下需要相当重要，如果早期需求做的不够仔细会给项目的后期工作带来很多的隐患。

而且我建议每个项目无论多大也无论项目时间要求多紧急一定要有一个比较详细的需求文档。

在需求比较确定之后建议再对项目成本进行估算。同时对需要的资源及相关里程碑进行说明。

三、设计

对于大部分中小型项目因为时间和人力的问题加上需求变更比较频繁，所以有时很难书写一个比较详细的设计文档。但是如果没有设计文档一是为后期维护可能会带来一些问题，尤其是当原来开发人员或主力开发人员离职或调离到其他项目组时；另外没有经过详细设计

的项目可能也会存在一些风险。

因此建议不必为了文档而文档，除了项目验收的要求外，建议设计文档根据项目特点有选择地包括以下一些内容的说明：

系统网络情况。

系统安全策略及备份策略。

系统相关软硬件环境说明。

与其他系统的关系。

主要库表及关键字段说明。

系统中关键数据关联关系说明。

关键字段校验规则。

项目中技术的论证及名种技术的结合方法。

系统关键技术说明。

一些技术使用过程中的注意点。

异常处理机制。

事物处理机制。

日志记录方法及原则。

框架中相关命名说明。

共通功能描述及调用方法。

核心算法。

系统性能解决方案。

并发的考虑及处理。

系统用户及角色权限设计说明。

系统的关键配置说明（如数据库服务器，应用服务器等等，如有必要可另加附件进行说明）。

个人认为对于中小型项目如果不是用户要求有时不必在设计文档中对所有数据库表及字段都进行说明，可以只说明比较重要的一些数据库表及字段以及相关数据库的关联关系就可。因为在用数据库建模软件（如Powerdesigner）进行数据库设计的时候可以对每个表及每个字段加注释进行说明，在使用开发工具（如：pl/sql）进行开发的时候自然可以看到每个数据库表或字段的说明。而且一般中小型项目在开发的过程中可能需要经常性地修改数据库表的设计，如果还有文档描述数据库的设计那么每次修改时除了修改数据库之外还要维护设计文档的一致性，如果项目忙忘记了修改就会导致文档和数据库的不一致，有时这种不一致的文档可能还不如没有，因为它可能会误导其他人员的理解。

另外也可以通过开发过程的规范来减少设计文档的内容。这个将在下面的开发环节进行详细的说明。

四、开发

整个项目有一个合理的框架是很重要的。框架具体包括哪些内容在此很难解释清楚，但是我想最起码整个框架应该把项目所采用的各种技术（如java中的Hibernate、Struts、Spring 的结合）比较合理地组织起来，并为具体模块的开发提供一些工具类等，同时整个框架应该具有较好的可扩展性、可维护性和较好的性能。框架最好由项目组中技术最强的人（在此称他为技术负责人）进行搭建及维护。

另外对于整个项目有一个统一的命名规范（类和方法按什么方式命名，所有文档都加上时间作者等）并进行遵守是很必要的，这样一个人开发的代码其他人很容易就能够读懂。

在整个项目进行全面开发前最好先向项目组全体成员讲解需求及项目框架的机制、使用

方式及注意事项，再说明相关规范。然后每一个开发人员按照理解开发一个简单的功能。然后大家再一起（或者由技术负责人）看一下每个人对于框架的使用是否合理，规范理解的是否有误，编码习惯是否需要改正等等。在讨论并达成共识后再进行具体功能的开发。

另在具体的开发过程中尽量在关键算法处加一些注释进行说明。

建议定期进行一些代码走查的工作。尽量由技术负责人负责这份工作，当然也可以进行互相检查等。代码走查的好处很多，如可发现一些不好的编码习惯；提高整个系统代码的可读性；发现一些bug；借鉴别人好的编码思路或技术等。

五、测试

有些公司有独立的测试或质量保证部门，有的公司只是由开发人员自己完成测试工作。在此假设公司有一个独立的测试部门进行系统的测试工作。

首先开发人员一定要养成单元测试的习惯。对自己开发模块的功能进行单元测试过之后再提交测试组进行结合测试、系统测试甚至性能测试。单元测试很重要，在进行单元测试的时候如果条件允许可以使用junit等一些工具，或其他一些代码覆盖率工具帮助分析测试用例的覆盖程度。另外在此再提一点，一般项目可能是整体开发完之后才进行性能测试，可是这时测试出性能问题了却因为临近上线或试运行时期，不一定有充足的时间进行修改，另外也可能因为整个项目已经都使用了某种影响性能的技术或方法，要想改变要付出很大的代价。所以建议如果条件允许可以在开发的过程中（甚至搭建项目框架时）使用一些轻量级的开源性能测试工具由开发人员对可能影响性能的功能进行测试。

对于测试部门的测试人员要尽早地参与到项目中来，建议在需求阶段就介入。早介入的好处一是可以对需求理解的比较深入，知道原始需求是怎么来的，中间经过哪些变化，这样会比在开发结束后一次性地讲解能够更好地把握需求，更好地书写测试用例及测试计划。另外有些人也比较推荐在需求的时候就开始书写测试计划和测试用例，因为我之前项目的特点我没有这样试过。

项目组设计人员一定要把一些关键测试点、数据及功能的关联关系对测试人员说清楚。测试过程中有一个bug管理系统并对bug进行跟踪是很必要的，在此就不展开说明了。

另外在补充一点，最好是在项目结束后能对产生的所有bug进行一下分类。然后通过分析得出一些规律。通过在以后项目中采取一些措施进行项目质量的提高。

六、实施

对于涉及多个子系统的长期开发项目，在系统设计和开发过程中要优化处理关联性强的系统，同时有一个（或几个）系统成熟了就试运行或上线，不必等所有系统都好了再上线。一是因为时间长了开发人员可能调离至其它岗位，维护代价会增大；二是子系统用户可能会改变而导致需求变更；三是时间长了用户对系统需求会有陌生感，也可能会产生新的需求；四是时间长会给打消用户对使用系统的积极性；五是较早地让用户看到系统也可以减轻因双方理解偏差而导致的系统需求变更的影响。

七、维护

争取把用户的提过的所有修改都进行记录，并争取所有修改都请用户签字（不一定提一个修改就签字一次，可以统一记录然后定期把一段时间内的修改进行签字确认），如果做不到所有修改都签字也尽量做到对于重大修改请用户签字。签字的好处很多：让用户看到项目组所做的工作；如果修改的内容比较多可以通过双方高层领导的沟通再新进行系统二期或三期的开发；有了签字有时用户对需求变更会相对少一些等等。

另外对于所有修改除了签字留档外争取定期把所有修改的内容再整理到需求文档中，保