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

软件工程主要分为哪些阶段？各个阶段主要做哪些任软件工程主要分为哪些阶段？各个阶段主要做哪些任务？之五兆芳芳创作自己在两个中小型软件开发企业任务过几年，也做过几年的工程办理任务.走过一些弯路也得出一些工程办理方面的体会，在此进展总结，期望能够与其他一些工程办理人员或对工程办理有兴趣的同事协作探讨一些中小型工程办理的问题及方法大局部中小型软件开发企业的软件工程常常遇到的一些问题可能包含：工程时间紧、工程组成员常常加班；工程需求变动频繁；工程进展进程中可能就有工程团队成员离职或调离到其他工程组；工程重复性扶植问题严峻，每个工程都需要从框架开头重开发，难以重用已有工程的成果等等.我觉得通过较好的筹划和办理能够在肯定程度上提高工程的成功率或说提高工程的质量，下降开发本钱，缩短项目开发时间我理解工程办理有两个大的划分方法一是通用5个工程办理进程组944生命期划分的各阶段的办理.本文主要从工程生命期各阶段的办理方面进展总结.〔这只是我团体的一个划分，有可能不是很全面需求、设计、开发、测试、实施、维护、总结.下面我针对每个阶段谈一下自己的体会.一、可行性阐发一般的工程都是通过外部招标的形式得到的.对于有些公司在应标的时候对工程就要有个取舍.假设在特别时期为了生存可能只要不是太赔的工程都会尽量承接.性阐发，并且这种可行性阐发最好是办理者、市场、技巧等人员都介入，由于市场人员一般不懂〔或欠亨〕技巧，技巧不懂〔或欠亨〕市场，因此只有大家在一起协作阐发争论才干够得出比较可行的结果.可行性阐发的结果一方面可以作为是否承接工程的依据，另一方面也可以作为承接工程方法或与客户谈判的依据.书金额开发有可能会赔，那么可以与用户探讨是否将来能有个二期的工程；另外假设用户要求的时间比较紧，可是经阐发很难按标书时间完成，那么也可以和用户同共探讨是否可以在正式签定合同时延长系统交付时间等.固然这些与用户的探讨任务一般是需要公司高层领导出面协调的，有时单独靠工程组是没有力量达成抱负的结果的.另外在此阶段最好对工程的本钱和需要的资源进展一下预算.二、需求需求实际要细分为需求调研、需求阐发、需求确认、需求办理等.不进展开放.在此只是先强调一下需要相当重要，假设早期需求做的不敷认真会给工程的前期任务带来良多的隐患.并且我建议每个工程无论多大也无论工程时间要求多紧急肯定要有一个比较具体的需求文档.在需求比较确定之后建议再对工程本钱进展预算.同时对需要的资源及相关里程碑进展说明.三、设计对于大局部中小型工程由于时间和人力的问题加上需求.但是假设没有设计文档一是为前期维护可能会带来一些问题，尤其是当原来开发人员或主力开发人员离职或调离到其他工程组时；另外没有经过具体设计的工程可能也会存在一些风险.因此建议不必为了文档而文档，除了工程验收的要求外，建议设计文档依据工程特点有选择地包含以下一些内容的说明：系统网络状况.系统平安战略及备份战略.系统相关软硬件状况说明.与其他系统的关系.主要库表及关头字段说明.系统中关头数据联系关系关系说明.关头字段校验法则.工程中技巧的论证及名种技巧的结合方法.系统关头技巧说明.一些技巧使用进程中的留意点.特别处理机制.事物处理机制.日志记实方法及原则.框架中相关命名说明.共通成效描述及调用方法.焦点算法.系统性能解决筹划.并发的考虑及处理.系统用户及角色权限设计说明.〔如有需要可另加附件进展说明〕.团体认为对于中小型工程假设不是用户要求有时不必在设计文档中对全部数据库表及字段都进展说明，可以只说明比较重要的一些数据库表及字段以及相关数据库的联系关系关系就可.〔如Powerdesigner〕进展数据库设计的时候可以对每个表及每个字段加注释进展说明，在使用开发东西〔如：pl/sql〕进展开发的时候自然可以看到每个数据库表或字段的说明.并且一般中小型工程在开发的进程中可能需要常常性地修改数据库表的设计，假设还有文档描述数据库的设计那么每次修改时除了修改数据库之外还要维护设计文档的全都性，假设工程忙遗忘了修改就会导致文档和数据库的不全都，有时这种不全都的文档可能还不如没有，由于它可能会误导其他人员的理解.另外也可以通过开发进程的标准来削减设计文档的内容.这个将在下面的开发环节进展具体的说明.四、开发整个工程有一个公正的框架是很重要的.框架具体包含哪些内容在此很难解释清楚，但是我想最起码整个框架应当把工程所实行的各类技巧〔如java中的Hibernate、Struts、Spring的结合〕比较公正地组织起来，并为具体模块的开发供给一些东西类等，同时整个框架应当具有较好的可扩展性、可维护性和较好的性能.框架最好由工程组中技巧最强的人〔在此称他为技巧担当人〕进展搭建及维护.〔类和方法按什么方法命名，全部文档都加上时间作者等〕并进展遵守是很需要的，这样一团体开发的代码其他人很简洁就能够读懂.在整个工程进展全面开发前最好先向工程组全体成员讲授需求及工程框架的机制、使用方法及留意事项，再说明相关标准.然后每一个开发人员依照理解开发一个简单的成效.然后大家再一起〔或由技巧担当人〕看一下每团体对于框架的使用是否公正，标准理解的是否有误，编码习惯是否需要更正等等.在争论并达成共鸣后再进展具体成效的开发.另在具体的开发进程中尽量在关头算法处加一些注释进行说明.建议定期进展一些代码走查的任务.尽量由技巧担当人担当.代码走查的利益良多，如可制造一些欠好的编码习惯；提高整个系统代码的可bug；借鉴他人好的编码思路或技巧等.五、测试开发人员自己完成测试任务.在此假定公司有一个独立的测试局部进展系统的测试任务.首先开发人员肯定要养成单元测试的习惯.对自己开发模块的成效进展单元测试过之后再提交测试组进展结合测试、系统测试甚至性能测试.时候假设条件允许可以使用junit码笼盖率东西帮助阐发测试用例的笼盖程度.另外在此再提一点，一般工程可能是整体开发完之后才进展性能测试，可是这时测试出性能问题了却由于接近上线或试运行时期，不肯定有充分的时间进展修改，另外也可能由于整个工程已经都使用了某种影响性能的技巧或方法，要想改动要支出很大的代价.〔甚至搭建工程框架时〕使用一些轻量级的开源性能测试东西由开发人员对可能影响性能的成效进展测试.在需求阶段就介入.早介入的利益一是可以对需求理解的比较深入，知道原始需求是怎么来的，中间经过哪些变更，这样会比在开发完毕后一次性地讲授能够更好地掌控需求，更好地书写测试用例及测试筹划.另外有些人也比较推举在需求的时候就开头书写测试筹划和测试用例，由于我之前工程的特点我没有这样试过.联系关系关系对测试人员说清楚.测试进程中有一个bug办理系统并对bug进展跟踪是很需要的，在此就不开放说明白.bug进展一下分类.然后通过阐发得出一些纪律.通过在以后工程中承受一些措施进展工程质量的提高.六、实施进程中要优化处理联系关系性强的系统，同时有一个〔或几个〕系统成熟了就试运行或上线，不必等全部系统都好了再上线.代价会增大；二是子系统用户可能会改动而导致需求变动；三是时间长了用户对系统需求会有生疏感，也可能会产生的需求；四是时间长会给消除用户对使用系统的乐观性；五是较早地让用户看到系统也可以加重因双方理解偏差而导致的系统需求变动的影响.七、维护改都请用户签字〔不肯定提一个修改就签字一次，可以统一记实然后定期把一段时间内的修改进展签字确认，假设做不到全部修改都签字也尽量做到对于重大修改请用户签字.签字的利益良多：让用户看到工程组所做的任务；假设修改的内容比较多可以通过双方高层领导的沟通再进展系统二期或三期的开发；有了签字有时用户对需求变动会相对少一些等等.另外对于全部修改除了签字留档外争取定期把全部修改的内容再整理到需求文档中，保持需求文档与正式状况成效的全都性.测试人员在回归测试时理解系统成效；假设维护人员的调离其他接手人员比较便利理解系统成效等.八、总结在此不合错误工程验收进展单独的说明.只是说一下工程完毕〔有些工程可能要持续进展维护，在此主要指系统已经上线并稳定运行〕后要进展的总结任务.建议每个工程完毕后都召开一个工程总结会.工程总结会建议与工程相关的全部人都介入.也都进展总结.可以从办理和技巧两大方面对工程中的每个阶段的成功与失败进展总结，目的是总结阅历教训，提高每团体的工程阅历，提高工程组的成熟度，使以后的工程加倍成功.的，而很少提到失败的或所走的一些弯路，而往往对这些失败的总结更能使大家收获更多，固然这也要看组织的文化，我建议假设可能尽量煽动鼓励大家多总结一些失败的阅历教训.另外工程完毕后假设有时间最好是把工程中的一些有重用价值的文档放到公司的组织进程资产库中.假设工程的框架比较公正也可以剔除工程中的业务相关成效的代码，整理出工程框架并加以扼要说明文档供本工程组其他工程或其他工程组使用.九、工程经理职责阐发的角色又要充当开发甚至实施人员的角色，根本上软件工程生命期的每个阶段都要介入.但是我觉得以下一些任务〔其实远不只下面所列〕工程经理肯定要重视：工程整体需求的掌控.工程框架的掌控.工程团队的扶植.与其他职能局部的协调任务.工程例会.客户关系维护.定期向工程相关人员报告请示进度.担当，要对客户担当，还要对公司担当，所以工程经理肯定要有责任心、要有全局不雅.最终是关于本文的几点说明：本文主要从宏不雅上对软件工程