软件项目主要阶段及各个阶段主要工作

用户探讨是否将来能有个二期的项目； 另外如果用户要求的时间比较紧， 可是经分析很难按
标书时间完成， 那么也可以和用户同共探讨是否可以在正式签定合同时延长系统交付时间等。
当然这些与用户的探讨工作一般是需要公司高层领导出面协调的，
有时单独靠项目组是没有
能力达成理想的结果的。
另外在此阶段最好对项目的成本和需要的资源进行一下估算。
七、维护
争取把用户的提过的所有修改都进行记录，并争取所有修改都请用户签字（不一定提一
个修改就签字一次， 可以统一记录然后定期把一段时间内的修改进行签字确认）
，如果做不
到所有修改都签字也尽量做到对于重大修改请用户签字。
签字的好处很多： 让用户看到项目
组所做的工作； 如果修改的内容比较多可以通过双方高层领导的沟通再新进行系统二期或三
八、总结 在此不对项目验收进行单独的说明。只是说一下项目结束（有些项目可能要持续进行维 护，在此主要指系统已经上线并稳定运行）后要进行的总结工作。 建议每个项目结束后都召开一个项目总结会。项目总结会建议与项目相关的所有人都参加。 由项目经理进行主要总结， 但每个参与人员最好也都进行总结。 可以从管理和技术两大方面 对项目中的每个阶段的成功与失败进行总结， 目的是总结经验教训， 提高每个人的项目经验， 提高项目组的成熟度， 使以后的项目更加成功。 在此要强调一下， 一般项目总结时大家都喜 欢只说成功的， 而很少提到失败的或所走的一些弯路， 而往往对这些失败的总结更能使大家 收获更多， 当然这也要看组织的文化， 我建议如果可能尽量鼓励大家多总结一些失败的经验 教训。 另外项目结束后如果有时间最好是把项目中的一些有重用价值的文档放到公司的组织过 程资产库中。 如果项目的框架比较合理也可以剔除项目中的业务相关功能的代码，整理出项目框架并 加以简要说明文档供本项目组其他项目或其他项目组使用。
系统网络情况。 系统安全策略及备份策略。
系统相关软硬件环境说明。
与其他系统的关系。
主要库表及关键字段说明。
系统中关键数据关联关系说明。
关键字段校验规则。
项目中技术的论证及名种技术的结合方法。
系统关键技术说明。
一些技术使用过程中的注意点。
异常处理机制。
事物处理机制。
日志记录方法及原则。
框架中相关命名说明。
期的开发；有了签字有时用户对需求变更会相对少一些等等。
另外对于所有修改除了签字留档外争取定期把所有修改的内容再整理到需求文档中，保
持需求文档与正式环境功能的一致性。 这个工作很有必要， 可能带来以下一些好处： 方便测 试人员在回归测试时理解系统功能； 如果维护人员的调离其他接手人员比较方便理解系统功 能等。
能不是很全面）：可行性分析、需求、设计、开发、测试、实施、维护、总结。
下面我针对每个阶段谈一下自己的体会。
一、可行些公司在应标的时候对项目就要有
个取舍。如果在特殊时期为了生存可能只要不是太赔的项目都会尽量承接。
但是一般项目在承接前最好在经济、技术等方面进行可行性分析，而且这种可行性分析
最好是管理者、市场、技术等人员都参与，因为市场人员一般不懂（或不通）技术，技术不
懂（或不通）市场，因此只有大家在一起共同分析讨论才能够得出比较可行的结果。
可行性
分析的结果一方面可以作为是否承接项目的依据， 另一方面也可以作为承接项目方式或与客
户谈判的依据。 比如经分析项目工作量很大， 如果按标书金额开发有可能会赔， 那么可以与
三、设计
对于大部分中小型项目因为时间和人力的问题加上需求变更比较频繁，所以有时很难书
写一个比较详细的设计文档。但是如果没有设计文档一是为后期维护可能会带来一些问题，
尤其是当原来开发人员或主力开发人员离职或调离到其他项目组时；
另外没有经过详细设计
的项目可能也会存在一些风险。
因此建议不必为了文档而文档，除了项目验收的要求外，建议设计文档根据项目特点有 选择地包括以下一些内容的说明：
最后是关于本文的几点说明：
本文主要从宏观上对软件项目生命期的每个阶段可能遇到的问题及相关解决的想法进行
探讨。 因此本文写的有点杂，而且对许多内容只是点到，
并未展开，如果可行可能在后续的
文章中单独对某些阶段（如：需求、开发）或某些工作（项目团队建设、技术交流、员工职
业生涯规划等）再进行展开论述。
本文主要针对中小型企业的项目生命期管理的想法。我相信对于很多大企业的管理方式 远比我所提到的正规得多。
要想改变要付出很大的代价。
所以建议如果条件允许可以在开发的过程中 （甚至搭建项目框架时） 使用一些轻量级的开源
性能测试工具由开发人员对可能影响性能的功能进行测试。
对于测试部门的测试人员要尽早地参与到项目中来，建议在需求阶段就介入。早介入的
好处一是可以对需求理解的比较深入， 知道原始需求是怎么来的， 中间经过哪些变化， 这样
读性；发现一些 bug ；借鉴别人好的编码思路或技术等。
五、测试
有些公司有独立的测试或质量保证部门，有的公司只是由开发人员自己完成测试工作。 在此假设公司有一个独立的测试部门进行系统的测试工作。
首先开发人员一定要养成单元测试的习惯。对自己开发模块的功能进行单元测试过之后
再提交测试组进行结合测试、 系统测试甚至性能测试。 单元测试很重要， 在进行单元测试的
然
后大家再一起 （或者由技术负责人） 看一下每个人对于框架的使用是否合理， 规范理解的是
否有误，编码习惯是否需要改正等等。在讨论并达成共识后再进行具体功能的开发。
另在具体的开发过程中尽量在关键算法处加一些注释进行说明。 建议定期进行一些代码走查的工作。尽量由技术负责人负责这份工作，当然也可以进行 互相检查等。 代码走查的好处很多， 如可发现一些不好的编码习惯； 提高整个系统代码的可
因本人写作水平有限，写的比较粗糙，也希望大家共同探讨，多提宝贵意见。
二、需求 需求实际要细分为需求调研、需求分析、需求确认、需求管理等。 因为对于需求要想说清楚可能需要较长的篇幅，所以在此不进行展开。 在此只是先强调一下需要相当重要， 如果早期需求做的不够仔细会给项目的后期工作带来很 多的隐患。 而且我建议每个项目无论多大也无论项目时间要求多紧急一定要有一个比较详细的需求文 档。 在需求比较确定之后建议再对项目成本进行估算。同时对需要的资源及相关里程碑进行说 明。
文档的一致性， 如果项目忙忘记了修改就会导致文档和数据库的不一致，
有时这种不一致的
文档可能还不如没有，因为它可能会误导其他人员的理解。
另外也可以通过开发过程的规范来减少设计文档的内容。这个将在下面的开发环节进行
详细的说明。
四、开发
整个项目有一个合理的框架是很重要的。框架具体包括哪些内容在此很难解释清楚，但
软件项目主要分为哪些阶段？各个阶段主要做哪些工作？
本人在两个中小型软件开发企业工作过几年， 也做过几年的项目管理工作。 走过一些弯路也
得出一些项目管理方面的体会， 在此进行总结， 希望能够与其他一些项目管理人员或对项目
管理有兴趣的同事共同探讨一些中小型项目管理的问题及方法。 大部分中小型软件开发企业的软件项目经常遇到的一些问题可能包括：
我理解项目管理有两个大的划分方法一是通用的项目管理体系，
也就是 PMP 中所说的 5 个
项目管理过程组 9 个知识领域 44 个项目管理过程； 二是具体业务领域的按项目生命期划分
的各阶段的管理。本文主要从项目生命期各阶段的管理方面进行总结。
我个人分析一个软件项目生命期大体需要经过的流程（这只是我个人的一个划分，有可
是我想最起码整个框架应该把项目所采用的各种技术（如
java 中的 Hibernate 、Struts 、Sp
ring 的结合） 比较合理地组织起来， 并为具体模块的开发提供一些工具类等， 同时整个框架 应该具有较好的可扩展性、 可维护性和较好的性能。 框架最好由项目组中技术最强的人 （在
此称他为技术负责人）进行搭建及维护。
另外对于整个项目有一个统一的命名规范（类和方法按什么方式命名，所有文档都加上 时间作者等）并进行遵守是很必要的，这样一个人开发的代码其他人很容易就能够读懂。
在整个项目进行全面开发前最好先向项目组全体成员讲解需求及项目框架的机制、使用
方式及注意事项， 再说明相关规范。 然后每一个开发人员按照理解开发一个简单的功能。
会比在开发结束后一次性地讲解能够更好地把握需求，
更好地书写测试用例及测试计划。 另
外有些人也比较推荐在需求的时候就开始书写测试计划和测试用例，
因为我之前项目的特点
我没有这样试过。
项目组设计人员一定要把一些关键测试点、数据及功能的关联关系对测试人员说清楚。
测试过程中有一个 bug 管理系统并对 bug 进行跟踪是很必要的，在此就不展开说明了。
共通功能描述及调用方法。
核心算法。
系统性能解决方案。
并发的考虑及处理。
系统用户及角色权限设计说明。
系统的关键配置说明（如数据库服务器，应用服务器等等，如有必要可另加附件进行说
明）。
个人认为对于中小型项目如果不是用户要求有时不必在设计文档中对所有数据库表及字
段都进行说明， 可以只说明比较重要的一些数据库表及字段以及相关数据库的关联关系就可。
时候如果条件允许可以使用 junit 等一些工具，或其他一些代码覆盖率工具帮助分析测试用
例的覆盖程度。 另外在此再提一点， 一般项目可能是整体开发完之后才进行性能测试，
可是
这时测试出性能问题了却因为临近上线或试运行时期，
不一定有充足的时间进行修改， 另外
也可能因为整个项目已经都使用了某种影响性能的技术或方法，
因为在用数据库建模软件 （如 Powerdesigner ）进行数据库设计的时候可以对每个表及每个
字段加注释进行说明，在使用开发工具（如： pl/sql ）进行开发的时候自然可以看到每个数