软件生命周期管理

1、软件生命周期（SDLCSystemsDevelopmentLifeCycle,SDLC）是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面_向对象的设计方法和技术的成熟,软件生命周期设计方法的指导意义正在逐步减少。七个阶段同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生存周期（软件生命周期）。软件生命周期把

2、整个软使规模大，结软件生存周期详细设计）、配到不同的阶件生存周期划分为若干阶段，使构复杂和管理复杂的软件开发变包括可行性分析、项目启动、需编码、测试、维护等活动，可以段去完成。得每个阶段有明确的任务，的容易控制和管理。通常，求分析、设计（概要设计和将这些活动以适当的方式分可行性分析此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。主要交付物有项目规划书、立项报告、可行性研究报告项目启动项目启动会、人员到位，初步分工、搭建开发环境、准备项目管理工具。项目管理工具：可采用Project和JIRA结合管理。MicrosoftProject（或MSP）是一个国际上享有盛誉的通用的项

3、目管理工具软件，凝集了许多成熟的项目管理现代理论和方法，可以帮助项目管理者实现时间、资源、成本的计划、控制。仕克力恤_L朋皿艇划回JnnftJulyS-165-Z35-50|6-6|6-136-ED6-27710需求知折型理1工作日?仙晦5月4日£01口聒月4日9II需求说明书得招2工作日T20W年5月5日仙05&刖日1012需求正娜（ft为台同用件）评审1工作日T前1阐月T日201痛5月T日11曲第二次消明拚充5工柚加阐月出201用朋日6T6-T14二项目设计鼾段10工作日？Z（H（年5月m日20105J9Z1Q15概要设计3工作日T即1。年写月10日胃110年亏月12日1

4、2-126详加设计7工作日T加1稣月13日2010筋月度日15-5-217-理目蜜傅开庭鼾性T&工作日？2010450126201姆月25日0详翱的油5工隹分解士工作日T201啤5月线日30】。年5月25日165-24115-215?*杂文祺转部分«ifta?ZUHJ年5月3B日W0UJ年T月30口102B讦信息发布松目鼻分47.93工作日？20U1年5月LW日201碑T月16日求帮变系推40工作日？展01。弼月24日201口年T月16日36件公文收黄IETftH?仙碑及目汨如。年B月当日1913R合球甘理2&r作日？201。年T月16日之。1。年6月23日旬任值班曾

5、理Z5工作日？2UUI年T月1目日WUUJ年8月用日52E普查督办1B工体口？2口10年8月Z日2010=8J3251956E系统整合1B工作日？2010年0月2日201口年8月西日1059力哒系鞋页5工附仙（译日用日201悔耻日60闻片新闻3工作日T20W年3月g日加10的月11日596L数解离2ltt0?201姆月航日20】。年8月”日3062集撷属5工作&?201懈月30日201懈朋日氧63数据迁移1工作日？即1碑M刖日则口料刖日盟G4禽害1工作日T2口1晦咽7日阿口年0月7日8365屈II5工作日T仙廨Q朋日2010年8月14日6621工作日T加1。年9月15日201。年1。月

6、19日6567交待10工作日201喇耳M日201班9朋日38正赴明运行10工作日?201年10月20日2010年11月2日6669验收1工作日？201诲11月3日201年U月3月88J-JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。YJIRADashboard，浏览项目，问题：，Agile*+制理同接RoadMap:Mil却Dsiunuzdiiu1»11：52ftCWT|f81143(11介貂感谢您对JRA的支持.米颐用1即它用招财的邸更加容易地跟晾问;g.作为前期发人员引蜘人员落户驼沟通的府梁牺了品蚓目开泥流程更0曲谑从事里开始？里嬖7岁里£关于1网

7、的使用.请参考出衽霰用户询雨.CBD2月之日，1*曲固/立startedprogressan.,.G：-1君求工档)之且丝日moo田对华2朝华crtslec-'JDFID-5三若推送消息队列creafleflJDR.L.；克船由总推送机制国受寸半rsofwiedANDROID，克舌Li?我俺：周军付毕changEittieffS七邮5明即.挎野.他仃乘唤Showmore分配皓我曲门笑强百友现匹口时问敷处理中的自然役有发现匹!J西同转.建模工具：设计建立UML模型图，基于UML的可视化建模工具采用的是RationalRose或MyEclise提恢客户鼓盘版本控制工具：版本控制是程序开发、

8、管理必不可少的工具，特别是在多人协作的团队中，适宜的版本控制工具可以提高开发效率，消除很多有代码版本带来的问题。主要有CVS、SVN、VSS,见下SVN截图需求分析domainGanalexpertdomainknowlege、_MultiMediadomainhDVEiauthonngdomainSQyseotherdomains:。generalanalysetech好anaya/LJlystanalysetechBusinessModeling软件设计软件生命周期之软件设计此阶段主要根据需求分析的结果，对整个软件设计，数据库设计等等。软件设计一般分为总件设计将为软件程序编写打下良好的基础

9、。在此阶段可根据需求分析规格说明书和设作分解），根据分解的的任务制定详细的开发程序编码此阶段是将软件设计的结果转换成计算机编码中必须要制定务符合标准的编与规范维护性，提高程序的运行效率。系统进行设计，如系统框架体设计和详细设计。好的软计文档做详细的WBS（工计划。可运行的程序代码。在程序。以保证程序的可读性，易软件测试non-funcreqtestfuncreqtest"rformancetearotutine*;5;lostusmbililytnst软件生命周期之软件测试在软件设计完的问题并加以个阶段进行。需要建立详细意性。主要交付物有测试计划，测试报告成后要经过严密的测试，以发现

10、纠正。整个测试过程分单元测试测试的方法主要有白盒测试和黑的测试计划并严格按照测试计划软件在整个设计过程中存在、组装测试以及系统测试三盒测试两种。在测试过程中进行测试，以减少测试的随运行维护的阶段。在软件开发完成并续适应用户的要求。要延续件的维护包括纠错性维护和软件维护是软件生命周期中持续时间最长投入使用后，由于多方面的原因，软件不能继软件的使用寿命，就必须对软件进行维护。软改进性维护两个方面。周期模型就进入了软件生命周期。在将被使用并进入维护阶段，从概念提出的那一刻开始，软件产品经历需求、分析、设计、实现、部署后，软件直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为“生命周期模型&qu

11、ot;(LifeCycleModel)。典型的几种生命周期模型包括瀑布模型、快谏原型模型、迭代模型瀑布模型（WaterfallModel）首先由Royce提出。该模型由于酷似瀑布闻名。在该模型中，格说明，同样要的一点是只以进入下一个保每个阶段都模型几乎都是的。想象一下规格说明，你鉴，但是在过首先确定需求，并接受客户和SQA小组的验证。然后拟定规通过验证后，进入计划阶段，可有当一个阶段的文档已经编制好阶段。这样，瀑布模型通过强制能很好的完成任务。但是实际上以文档驱动的，这对于非专业的,你去买衣服的时候，售货员给会有什么样的感触。虽然瀑布模程能力上有天生的缺陷。以看出，瀑布模型中至关重并获得SQA

12、、组的认可才可性的要求提供规约文档来确往往难以办到，因为整个的用户来说是难以阅读和理解你出示的是一本厚厚的服装型有很多很好的思想可以借迭代式模型需求迭代式模型是是RUP（RationalUnifiedProcess,统一软件开发过程，统一软件过程）推茬的周期模型，也是我们在这个系列文章讨论的基础。在RUP中，迭代被定的全部开发活程度上，开发需求工作流程义为：迭代包括产生产品发布（动和要使用该发布必需的所有其迭代是一次完整地经过所有工作、分析设计工作流程、实施工作稳定、可执行的产品版本）他外围元素。所以，在某种流程的过程：（至少包括）流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUPU为

13、，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代的思想如图所示。迭代和瀑布的区别问上。“任何项目都会涉及避免了风险，那么您的计划系统时才被发现。不管开发多的问题在最后才会暴露出迭代和瀑布的最大的差别就在于风险的暴露时到一定的风险。如果能在生命周期中尽早确保自然会更趋精确。有许多风险直到已准备集成团队经验如何，都绝不可能预知所有的风险。由于瀑布模型的特点（文档是主体），很来，为了解决这些问题的风险是巨大的。"在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试

14、的可执行文件、这样就可以核实是否已经降低了目标风险。"快速原型模型快速原型（RapidPrototype）模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）。它最重要的目的是为了确定用户的真正需求。在我的经验中，这种方法非常的有效，原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。至于保留原型方面，也是有一种叫做增量模型是这么做的，但这种模型并不为大家所接受，不在我们的讨论之内。上述的模型中都有自己独特的思想，其实现在的软件组织中很少说标准的采用那一种模型的区别的。软件生命周期模型的发展实际上是体现了早的时候，软件的生命周期处于无序、混乱的软件的开发过程