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

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

《软件项目主要阶段及各个阶段主要工作.docx》由会员分享，可在线阅读，更多相关《软件项目主要阶段及各个阶段主要工作.docx（6页珍藏版）》请在冰豆网上搜索。

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

软件项目次要分为哪些阶段？

各个阶段次要做哪些工作？

之杨若古兰创作

本人在两个中小型软件开发企业工作过几年，也做过几年的项目管理工作.走过一些弯路也得出一些项目管理方面的体会，在此进行总结，但愿能够与其他一些项目管理人员或对项目管理有爱好的同事共同探讨一些中小型项目管理的成绩及方法. 大部分中小型软件开发企业的软件项目经常碰到的一些成绩可能包含：

项目时间紧、项目构成员经常加班；项目需求变动频繁；项目进行过程中可能就有项目团队成员离职或调离到其他项目组；项目反复性建设成绩严重，每个项目都须要从框架开始从头开发，难以重用已有项目的成果等等.我觉得通过较好的规划和管理能够在必定程度上提高项目的成功率或者说提高项目的质量，降低开发成本，缩短项目开发时间. 我理解项目管理有两个大的划分方法一是通用的项目管理体系，也就是PMP中所说的5个项目管理过程组9个常识领域44个项目管理过程；二是具体营业领域的按项目生命期划分的各阶段的管理.本文次要从项目生命期各阶段的管理方面进行总结. 

   我个人分析一个软件项目生命期大体须要经过的流程（这只是我个人的一个划分，有可能不是很全面）：

可行性分析、需求、设计、开发、测试、实施、保护、总结. 

   上面我针对每个阶段谈一下本人的体会. 

   一、可行性分析 

   普通的项目都是通过内部投标的方式得到的.对于有些公司在应标的时候对项目就要有个取舍.如果在特殊时期为了生存可能只需不是太赔的项目都会尽量承接. 

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

   另内在此阶段最好对项目的成本和须要的资本进行一下估算. 

   二、需求 

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

   由于对于需求要想说清楚可能须要较长的篇幅，所以在此不进行睁开. 在此只是先强调一下须要相当次要，如果初期需求做的不敷细心会给项目的后期工作带来很多的隐患. 而且我建议每个项目不管多大也不管项目时间请求多紧急必定要有一个比较具体的需求文档. 在需求比较确定以后建议再对项目成本进行估算.同时对须要的资本及相干里程碑进行说明. 

   三、设计 

   对于大部分中小型项目由于时间和人力的成绩加上需求变动比较频繁，所以有时很难书写一个比较具体的设计文档.但是如果没有设计文档一是为后期保护可能会带来一些成绩，特别是当本来开发人员或主力开发人员离职或调离到其他项目组时；另外没有经过具体设计的项目可能也会存在一些风险. 

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

   零碎收集情况. 

   零碎平安计谋及备份计谋. 

   零碎相干软硬件环境说明. 

   与其他零碎的关系. 

   次要库表及关键字段说明. 

   零碎中关键数据关联关系说明. 

   关键字段校验规则. 

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

   零碎关键技术说明. 

   一些技术使用过程中的留意点. 

   异常处理机制. 

   事物处理机制. 

   日志记录方法及准绳. 

   框架中相干命名说明. 

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

   核默算法. 

   零碎功能解决方案. 

   并发的考虑及处理. 

   零碎用户及角色权限设计说明. 

   零碎的关键配置说明（如数据库服务器，利用服务器等等，如有须要可另加附件进行说明）. 

   个人认为对于中小型项目如果不是用户请求有时不必在设计文档中对所无数据库表及字段都进行说明，可以只说明比较次要的一些数据库表及字段和相干数据库的关联关系就可.由于在用数据库建模软件（如Powerdesigner）进行数据库设计的时候可以对每个表及每个字段加正文进行说明，在使用开发工具（如：

pl/sql）进行开发的时候天然可以看到每个数据库表或字段的说明.而且普通中小型项目在开发的过程中可能须要经常性地点窜数据库表的设计，如果还有文档描述数据库的设计那么每次点窜时除了点窜数据库以外还要保护设计文档的分歧性，如果项目忙健忘了点窜就会导致文档和数据库的纷歧致，有时这类纷歧致的文档可能还不如没有，由于它可能会误导其他人员的理解. 

   另外也能够通过开发过程的规范来减少设计文档的内容.这个将在上面的开发环节进行具体的说明. 

   四、开发 

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

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

   在全部项目进行全面开发前最好先向项目组全体成员讲解需求及项目框架的机制、使用方式及留意事项，再说明相干规范.然后每一个开发人员按照理解开发一个简单的功能.然后大家再一路（或者由技术负责人）看一下每个人对于框架的使用是否合理，规范理解的是否有误，编码习气是否须要改正等等.在讨论并达成共识后再进行具体功能的开发. 

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

   建议定期进行一些代码走查的工作.尽量由技术负责人负责这份工作，当然也能够进行互相检查等.代码走查的好处很多，如可发现一些欠好的编码习气；提高全部零碎代码的可读性；发现一些bug；借鉴他人好的编码思路或技术等. 

   五、测试 

   有些公司有独立的测试或质量包管部分，有的公司只是由开发人员本人完成测试工作.在此假设公司有一个独立的测试部分进行零碎的测试工作. 

   首先开发人员必定要养成单元测试的习气.对本人开发模块的功能进行单元测试过以后再提交测试组进行结合测试、零碎测试甚至功能测试.单元测试很次要，在进行单元测试的时候如果条件允答应以使用junit等一些工具，或其他一些代码覆盖率工具帮忙分析测试用例的覆盖程度.另内在此再提一点，普通项目可能是全体开发完以后才进行功能测试，可是这时候测试出功能成绩了却由于临近上线或试运转时期，纷歧定有充足的时间进行点窜，另外也可能由于全部项目曾经都使用了某种影响功能的技术或方法，要想改变要付出很大的代价.所以建议如果条件允答应以在开发的过程中（甚至搭建项目框架时）使用一些轻量级的开源功能测试工具由开发人员对可能影响功能的功能进行测试. 

   对于测试部分的测试人员要尽早地介入到项目中来，建议在需求阶段就介入.早介入的好处一是可以对需求理解的比较深入，晓得原始需求是怎样来的，两头经过哪些变更，如许会比在开发结束后一次性地讲解能够更好地掌控需求，更好地书写测试用例及测试计划.另外有些人也比较推荐在需求的时候就开始书写测试计划和测试用例，由于我之前项目的特点我没有如许试过. 

   项目组设计人员必定要把一些关键测试点、数据及功能的关联关系对测试人员说清楚. 测试过程中有一个bug管理零碎并对bug进行跟踪是很须要的，在此就不睁开说明了. 另内在弥补一点，最好是在项目结束后能对发生的所有bug进行一下分类.然后通过分析得出一些规律.通过在当前项目中采纳一些措施进行项目质量的提高. 

   六、实施 

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

   七、保护 

   争夺把用户的提过的所有点窜都进行记录，并争夺所有点窜都请用户签字（纷歧定提一个点窜就签字一次，可以统一记录然后定期把一段时间内的点窜进行签字确认），如果做不到所有点窜都签字也尽量做到对于严重点窜请用户签字.签字的好处很多：

让用户看到项目组所做的工作；如果点窜的内容比较多可以通过双方高层领导的沟通再新进行零碎二期或三期的开发；有了签字有时用户对需求变动会绝对少一些等等. 

   另外对于所有点窜除了签字留档外争夺定期把所有点窜的内容再清算到需求文档中，坚持需求文档与正式环境功能的分歧性.这个工作很有须要，可能带来以下一些好处：

方便测试人员在回归测试时理解零碎功能；如果保护人员的调离其他接手人员比较方便理解零碎功能等. 

   八、总结 

   在此分歧错误项目验收进行单独的说明.只是说一下项目结束（有些项目可能要持续进行保护，在此次要指零碎曾经上线并波动运转）后要进行的总结工作. 建议每个项目结束后都召开一个项目总结会.项目总结会建议与项目相干的所有人都介入.由项目经理进行次要总结，但每个介入人员最好也都进行总结.可以从管理和技术两大方面对项目中的每个阶段的成功与失败进行总结，目的是总结经验教训，提高每个人的项目经验，提高项目组的成熟度，使当前的项目更加成功.在此要强调一下，普通项目总结时大家都爱好只说成功的，而很少提到失败的或所走的一些弯路，而常常对这些失败的总结更能使大家收获更多，当然这也要看组织的文明，我建议如果可能尽量鼓励大家多总结一些失败的经验教训. 

   另外项目结束后如果有时间最好是把项目中的一些有重用价值的文档放到公司的组织过程资产库中. 

   如果项目的框架比较合理也能够剔除项目中的营业相干功能的代码，清算出项目框架并加以简要说明文档供本项目组其他项目或其他项目组使用. 

   九、项目经理职责分析 

   对于中小型规模的项目，项目经理可能既要充当管理人员的角色又要充当开发甚至实施人员的角色，基本上软件项目生命期的每个阶段都要介入. 

   但是我觉得以下一些工作（其实远不只上面所列）项目经理必定要看重：

   项目全体需求的掌控. 

   项目框架的掌控. 

   项目团队的建设. 

   与其他本能机能部分的调和工作. 

   项目例会. 

   客户关系保护. 

   定期向项目相干人员汇报进度. 

   总之项目经理要对项目的成败负责，要对项目成员的发展负责，要对客户负责，还要对公司负责，所以项目经理必定要有义务心、要有全局观. 

   最初是关于本文的几点说明：

   本文次要从宏观上对软件项目生命期的每个阶段可能碰到的成绩及相干解决的设法进行探讨.是以本文写的有点杂，而且对很多内容只是点到，并未睁开，如果可行可能在后续的文章中单独对某些阶段（如：

需求、开发）或某些工作（项目团队建设、技术交流、员工职业生涯规划等）再进行睁开论述. 

   本文次要针对中小型企业的项目生命期管理的设法.我信任对于很多大企业的管理方式远比我所提到的正轨得多. 

   因本人写作水平无限，写的比较粗糙，也但愿大家共同探讨，多提贵重定见.