软件生命周期管理

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

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

3、ect （ 或 MSP）是一个国际上享有盛誉的通用的项目管理工具软件，凝集了许多成熟的项目管理现代理论和方法，可以帮助项目管理者实现时间、资源、成本的计划、控制。仕克力恤_L朋皿艇划回JnnftJulyS-16 5-Z3 5-50 | 6-6 | 6-13 6-ED 6-27 710需求知折型理1工作日?仙晦5月4日£01 口聒月4日9II需求说明书得招2工作日T20 W年5月5日仙05&刖日1012需求正娜（ft为台同用件）评审1工作日T前1阐月T日201痛5月T日11曲第二次消明拚充5工柚加阐月出201用朋日6T6-T14二项目设计鼾段10工作日？Z（H（年5月m日201

4、05 J9Z1Q15概要设计3工作日T即I。年写月1 0日胃11 0年亏月12日12-126详加设计7工作日T加1稣月13日2010筋月度日15-5-217-理目蜜傅开庭鼾性T&工作日？2010450126201姆月25日0详翱的油5工隹分解士工作日T201啤5月线日30】。年5月25日165-24 115-215?*杂文祺转部分«ifta?ZUHJ年5月3B日W0UJ年T 月 30 口102B讦信息发布松目鼻分47.93工作日？20U1年5月LW日201碑T月16日求帮变系推40工作日？展01。弼月24日201口年T月16日36件公文收黄IE TftH?仙碑及目汨如。年B月

5、当日1913R合球甘理2& r作日？201。年T月16日之。1。年6月23日旬任值班曾理Z5工作日？2UUI年T月1目日WUUJ年8月用日52E普查督办1B工体口F2口10年8月Z日2010=8 J3 25 1956E系统整合1B工作日？2010年0月2日201口年8月西日1059力哒系鞋页5工附仙（译日用日201悔耻日60闻片新闻3工作日T20 W年3月g日加1 0的月11日596L数解离2ltt0?201姆月航日20】。年8月”日3062集撷属5工作&?201懈月3 0日201懈朋日氧63数据迁移1工作日？即1碑M刖日则口料刖日盟G4禽害1工作日T2口1晦咽7日阿口年0月7

6、日8365屈II5工作日T仙廨Q朋日2010年8月14日6621工作日T加1。年9月15日201。年1。月19日6567交待10工作日201喇耳M日201班9朋日38正赴明运行10工作日?201 口年10月2 0日201 0年11月2日6669验收1工作日？201诲11月3日201 口年U月3月88J -JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。YJIRADashboard，浏览项目，问题：，Agile *+制理同接Road Map: Mil 却 Dsiunu zdii u 1»11：52ftCWT|f 81143(11介貂感谢您对JRA的支持.米颐用1即它

7、用招财的邸更加容易地跟晾问;g.作为前期发人 员引蜘人员落户驼沟通的府梁牺了品蚓目开泥流程更0曲谑从事里开始？里嬖7岁里£关于1网的使用.请参考出衽霰用户询雨.CBD2月之日，1*曲固 /立 started progress an .,.G： -1 君求工档)之且丝日moo田对华2朝华crtslec -'JDF ID-5三若推送消息队列creaflefl JDR. L .；克船由总推送机制国受寸半rsofwied ANDROID，克舌Li?我俺：周军付毕changEittieffS七邮5明即.挎野.他仃乘唤Show more分配皓我曲门笑强百友现匹口时问敷处理中的自然役有发现

8、匹!J西同转.建模工具：设计建立UML模型图，基于UML的可视化建模工具 采用的是Rational Rose 或 MyEclise提恢客户鼓盘版本控制工具：版本控制是程序开发、管理必不可少的工具，特别是在多人 协作的团队中，适宜的版本控制工具可以提高开发效率，消除很多有代码版本带来 的问题。主要有 CVS、SVN、VSS ,见下SVN截图需求分析domainGanalexpertdomain knowlege 、_ MultiMedia domainhDVEiauthonng domainSQyseother domains:。general analyse tech好anay a/ LJly

9、stanalyse techBusiness Modeling软件设计软件生命周期 之软件设计此阶段主要根据需求分析的结果，对整个软件 设计，数据库 设计等等。软件设计一般分为总 件设计将为软件程序编写打下良好的基础。在此阶段可根 据需求分析规格说明书和设 作分解），根 据分解的的任务制定详细的开发程序编码此阶段是将软件设计的结果转换成计算机 编码中必须要 制定务符合标准的编与规范 维护性，提高 程序的运行效率。系统进行设计，如系统框架体设计和详细设计。好的软计文档做详细的 WBS工 计划。可运行的程序代码。在程序。以保证程序的可读性，易软件测试non-func req test func r

10、eq test"rformance tearotutine*;5; lostusmbilily tnst软件生命周期 之软件测试在软件设计完 的问题并加以 个阶段进行。 需要建立详细 意性。主要交付物有测试计划，测试报告成后要经过严密的测试，以发现 纠正。整个测试过程分单元测试 测试的方法主要有白盒测试和黑 的测试计划并严格按照测试计划 软件在整个设计过程中存在 、组装测试以及系统测试三 盒测试两种。在测试过程中 进行测试，以减少测试的随运行维护的阶段。在软件开发完成并 续适应用户的要求。要延续 件的维护包括纠错性维护和软件维护是软件生命周期中持续时间最长 投入使用后，由于多方面的原

11、因，软件不能继 软件的使用寿 命，就必须对软件进行维护。软 改进性维护两个方面。周期模型就进入了软件生命周期。在 将被使用并进入维护阶段，从概念提出的那一刻开始，软件产品 经历需求、分 析、设计、实现、部署后，软件 直到最后由于 缺少维护费用而逐渐消亡。这样的一个过程，称为 “生命周期 模型"(Life Cycle Model )。典型的几 种生命周期模型包括瀑布模型、快谏原型模型、迭代模型瀑布模型（Waterfall Model ）首先由Royce提出。该模型由于酷 似瀑布闻名。在该模型中， 格说明，同样 要的一点是只 以进入下一个 保每个阶段都 模型几乎都是 的。想象一下 规格说

12、明，你 鉴，但是在过首先确定需求，并接受客户和SQA、组的验证。然后拟定规通过验证后，进入计划阶段，可 有当一个阶段的文档已经编制好 阶段。这样，瀑布模型通过强制 能很好的完成任务。但是实际上 以文档驱动的，这对于非专业的 ,你去买衣服的时候，售货员给 会有什么样的感触。虽然瀑布模 程能力上有天生的缺陷。以看出，瀑布模型中至关重 并获得SQA、组的认可才可 性的要求提供规约文档来确 往往难以办到，因为整个的 用户来说是难以阅读和理解 你出示的是一本厚厚的服装 型有很多很好的思想可以借迭代式模型需求迭代式模型是 是RUP （Rational Unified Process ,统一软件开发过程，统

13、一软件过程）推茬的周期模型，也是我们在这个系列文章讨论的基础。在RUP中，迭代被定 的全部开发活 程度上，开发 需求工作流程义为：迭代包括产生产品发布（动和要使用该发布必需的所有其迭代是一次完整地经过所有工作、分析设计工作流程、实施工作稳定、可执行的产品版本） 他外围元素。所以，在某种 流程的过程：（至少包括） 流程和测试工作流程。实质上，它类似小型 的瀑布式项目。RUFU为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一 个子集。迭代的思想如图所示。迭代和瀑布的区别问上。“任何项目都会涉及避免了风险，那么您的计划系统时才被发现。不管开

14、发多的问题在最后才会暴露出迭代和瀑布的最大的差别就在于风险的暴露时 到一定的风险。如果能在生命周期中尽早确保 自然会更趋精 确。有许多风险直到已准备集成 团队经验如何，都绝不可能预知所有的风险。由于瀑布 模型的特点（文档是主体），很来，为了解决这些问题 的风险是巨大的。"在迭代 式生命周期中，您需要根 据主要风险列 表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经 过测试的可执行文件、这样就可以核实是否已经降低了目标风险。" 快速原型模型快速原型（Rapid Prototype ）模型在功能上等价于产品 的一个子集。 注意，这里说 的是功能上。瀑布模型的缺点

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