软件生命周期
软件生命周期(Software Life Cycle,SLC)是软件的产生直到报废或停止使用的生命周期。旧的解释是周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。
随着新的面向对象的设计方法和技术的成熟，早期软件生命周期设计方法的指导意义正在逐步减少或需要调整。 不过从另一种意义来说，面向对象本身也是一种软件生命周期，传统的软件生命周期的概念仍是所有软件工程师非常重要的知识基础和工作指导。
软件生命周期的解释也应当调整。
以上旧的解释与下文的生命周期模型是不相容的，只与瀑布型生命周期模型及其衍生模型(比如V模型，W模型)相符合，而与迭代为基本特征的生命周期模型是不符合的。新的情况应当是把迭代加入到阶段当中，如下:软件生命周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，也有将以上阶段的活动组合在内的迭代阶段，即迭代作为生命周期的阶段。
简介 编辑本段
软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。 生命周期的每一个周期都有确定的任务，并产生一定规格的文档(资料)，提交给下一个周期作为继续工作的依据。按照软件的生命周期，软件的开发不再只单单强调"编码"，而是概括了软件开发的全过程。软件工程要求每一周期工作的开始只能必须是建立在前一个周期结果"正确"前提上的延续;因此，每一周期都是按"活动 ── 结果 ── 审核 ── 再活动 ── 直至结果正确"循环往复进展的。
阶段编辑本段
同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生存周期(软件生命周期)。把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理。通常，软件生存周期包括:
一、问题定义。要求系统分析员与用户进行交流，弄清"用户需要计算机解决什么问题"然后提出关于"系统目标与范围的说明"，提交用户审查和确认。
二、可行性研究。一方面在于把待开发的系统的目标以明确的语言描述出来，另一方面从经济、技术、法律等多方面进行可行性分析。
三、需求分析。弄清用户对软件系统的全部需求，编写需求规格说明书和初步的用户手册，提交评审。
四、开发阶段。开发阶段由四个阶段组成:
1、概要设计
2、详细设计
3、实现:根据选定的程序设计语言完成源程序的编码。
4、测试
五、维护:维护包括四个方面
1、改正性维护:在软件交付使用后，由于开发测试时的不彻底、不完全、必然会有一部分隐藏的错误被带到运行阶段，这些隐藏的错误在某些特定的使用环境下就会暴露。
2、适应性维护:是为适应环境的变化而修改软件的活动。
3、完善性维护 :是根据用户在使用过程中提出的一些建设性意见而进行的维护活动。
4、预防性维护:是为了进一步改善软件系统的可维护性和可靠性，并为以后的改进奠定基础。
问题的定义及规划
此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
需求分析
在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。"唯一不变的是变化本身。"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。软件需求定义是软件设计开发阶段的输入，为需求被翻译成为可以使软件建构功能的代码发挥作用。
软件设计
此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。软件设计的核心在于把握好那些决定"服务质量"的因素，比如软件的性能，可扩展性，安全性，怎样划分模块的组成，怎样组织和封装软件的组件，以及其他一些虽然不作为软件主要应用的方面但会对其支持方面有所影响的方方面面。软件设计的原理包括抽象，分解和模块化，耦合和内聚，封装，充分性，完整性和原始性。软件设计主要关注软件的兼容性、可扩展性、容错性、可维护性、模块化、可靠性、可重用性、健壮性、安全性、可用性和互操作性。耦合和内聚是两个用来评估软件设计质量的方法。
程序编码
此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
软件测试
在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
运行维护
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。
周期模型编辑本段
任何办公的流程处理;设计一种商务信函打印系统并投放市场。这个概念是不清晰的，但却是最高层的业务需求的原型。这个概念都会伴随着一个目的，例如在一个"银行押汇系统" 的目的是提高工作的效率。这个目的将会成为系统的核心思想，系统成败的评判标准。99年政府部门上了大量的OA系统，学过一点Lotus Notes的人都发了财(IBM更不用说了)，但是更普遍的情况是，许多的政府部门原有的处理模式并没有变化，反而又加上了自动化处理的一套流程。提高工作效率的初衷却导致了完全不同的结果。这样的软件究竟是不是成功的呢?
从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"(Life Cycle Model)。
典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。
瀑布模型
(Waterfall Model)首先由Royce提出。该模型由于酷似瀑布闻名。在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。想象一下，你去买衣服的时候，售货员给你出示的是一本厚厚的服装规格说明，你会有什么样的感触。虽然瀑布模型有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。
然而轻易抛弃瀑布模型的观点也是非常错误的，瀑布模型还是所有软件开发模型的基础，体现了软件开发的本质过程。对于一些大型 的软件项目，试图过于简化瀑布的前期的需求和设计阶段，用一个简单的原型或者迭代来模拟未来的系统，并试图帮助确认和挖掘客户的需求，是不可能的，不仅此时离客户的最终需求和隔山万千重，系统的架构也会随着过程而有很大被抛弃和大幅调整的过程，原型也就起不到原型的作用，成本和时间反而浪费，所以前期的功课还是少不了的，尤其对于复杂系统。即使对于简单如定制一件衣服，在给客户提出修改的时候，它要基本是一件衣服，而不是几块布片，否则客户无从提出进一步的需求，前期的功夫也是白费的。
迭代式模型
迭代式模型是是RUP(Rational Unified Process，统一软件开发过程，统一软件过程)推荐的周期模型，也是我们在这个系列文章讨论的基础。在RUP中，迭代被定义为:迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段(需求及其它)都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代的思想如图所示。
迭代和瀑布的最大的差别就在于风险的暴露时间上。"任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。"
由于瀑布模型的特点(文档是主体)，很多的问题在最后才会暴露出来，为了解决这些问题的风险是巨大的。"在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。"
快速原型模型
快速原型(Rapid Prototype)模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能(最重要的)。它最重要的目的是为了确定用户的真正需求。在我的经验中，这种方法非常的有效，原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。至于保留原型方面，也是有一种叫做增量模型是这么做的，但这种模型并不为大家所接受，不在我们的讨论之内。 上述的模型中都有自己独特的思想，其实现在的软件组织中很少说标准的采用那一种模型的。模型和实用还是有很大的区别的。
软件生命周期模型的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱的情况。一些人为了能够控制软件的开发过程，就把软件开发严格的区分为多个不同的阶段，并在阶段间加上严格的审查。这就是瀑布模型产生的起因。瀑布模型体现了人们对软件过程的一个希望:严格控制、确保质量。可惜的是，现实往往是残酷的。瀑布模型根本达不到这个过高的要求，因为软件的过程往往难于预测。反而导致了其它的负面影响，例如大量的文档、繁琐的审批。因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。例如把过程细分来增加过程的可预测性。
螺旋模型
1988年，Barry Boehm正式发表了软件系统开发的"螺旋模型"，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动:
(1) 制定计划:确定软件目标，选定实施方案，弄清项目开发的限制条件;
(2) 风险分析:分析评估所选方案，考虑如何识别和消除风险;
(3) 实施工程:实施软件开发和验证;
(4) 客户评估:评价开发工作，提出修正建议，制定下一步计划。
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下:
(1) 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。
(2) 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。
(3) 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险
一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。
附件列表
词条内容仅供参考，如果您需要解决具体问题
（尤其在法律、医学等领域），建议您咨询相关领域专业人士。
如果您认为本词条还有待完善，请 编辑