软件方法如何影响项目的生命周期

⑴ 如何选择软件开发的生命周期

文本Tag：软件开发 随着用户需求的多样化，软件系统开始越来越复杂了，而复杂性带来的结果是软件开发管理越来越困难。然而，许多软件开发团队却没有适时地改变其管理模式。因此，越来越多的软件开发项目呈现出管理失控和混乱的迹象，软件开发的整个生命周期已经越来越成为人们关注的焦点。 为什么软件开发项目的管理是这么困难呢？原因在于许多软件开发团队没有选择合适的管理工具。一般来说，在软件开发过程中会有许多不确定的、经常变化的因素，如果在软件开发过程中缺乏合适的管理工具，这将会导致开发人员无法统一开发行为和思路。例如，在实现项目的各阶段和各种角色（架构师、项目经理、开发人员、测试人员等）的方法和思路并不一致，不但会对设计、质量、代码管理和部署产生负面影响，而且还会导致开发成本增加。 那么，我们应该怎样管理好软件开发的各种因素呢？就像教科书上经常所说的一样，如果我们能够很好的管理软件生命周期每一个阶段的质量，也就很好的管理了整个软件开发的整个过程。因此，如何最大程度地管理好开发过程成为目前业界讨论的焦点。本文介绍了在软件开发过程中一种常用的管理工具：软件生命周期模式，以及其概念和选择方法。 软件开发工作本身是需要一个周期来完成的，而在周期的内部则包含了很多因素。一个因素的不稳定，在周期推移的过程中都很可能会造成类似生物学领域的蝴蝶效应----非洲的一只蝴蝶扇动翅膀可能会造成美洲大陆的一场龙卷风。这说明每一个事情都可能会对其它的事情产生连锁反应。因此，任何软件开发项目都必须进行适当的组织和管理，然后才能按预期计划成功地执行项目。也说是说，规划良好的软件开发生命周期将能够实现在更短的开发周期内构建软件的愿景。 同任何事物一样,一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，这一般称为软件生命周期。软件开发生命周期(SDLC)是指软件开发的全部过程、活动和任务的结构框架。许多软件开发工具厂商都提出过各种软件生命周期方法论，它们有人将SDLC解释为一组步骤或者里程标(Milestone)。但无论是谁的解释，SDLC的一般步骤包括：确定问题、可行性分析与开发计划、收集需求、分析与设计、编码开发、测试、安装、维护。 生命周期法也称结构化系统开发方法，是目前国内外较流行的软件系统开发方法。尤其在开发复杂的大系统时，显示出无比的优越性。它的基本思想是：将软件工程学和系统工程的理论和方法引入到软件系统的开发中，按照用户至上的原则，采用结构化、模块化自顶向下对系统进行分析和设计。具体的说，是通过把整个软件生命周期划分为若干阶段，使得每个阶段有明确的任务，使规模大、结构复杂和管理复杂的软件开发变的容易控制和管理。它的优点是强调系统开发过程的整体性和全局性，强调在整体优化的前提下考虑具体的分析设计问题，即自顶向下的观点。它从时间角度把软件开发和维护分解为若干阶段，每个阶段有各自相对独立的任务和目标，从而降低了系统开发的复杂性，提高了可操作性。 （2）软件生命周期模式 对于不同的软件系统，可以采用不同的开发方法、以及运用不同的管理方法和手段。实际上，软件生命周期法在开始的时候只是一个概念。因此，在应用软件开发生命周期法时，许多开发团队会把这一个概念进行工具化，这一个工具化就是软件开发生命周期模式。通过软件开发生命周期模式，我们能清晰、直观地看到软件开发的全过程。 在过去的10年中，软件生命周期模式及其许多变体获得了广泛的认可。在各种软件开发方法和过程改进模式中的技术革新也得到了承认，如Rational Unified Process(RUP)、Capability Maturity Model(CMM)、ISO 9000-3 等。典型的几种生命周期模式包括：瀑布模式、演化模式、螺旋模式、快速原型模式、喷泉模式和混合模式等。在这里只介绍其中最常用的几种模式： ①瀑布模式：它首先是由Royce提出，该模式由于酷似瀑布闻名。在该模式中首先确定需求，然后拟定规格说明，在通过验证后方可进入计划阶段。因此，瀑布模式中至关重要的一点是只有当一个阶段的文档获得认可才可以进入下一个阶段。瀑布模式通过强制性规约来确保每个阶段都能很好的完成任务，但是实际上却往往难以办到。因为整个瀑布模式几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。虽然瀑布模式有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。内容导航 ②演化模式：它主要是针对事先不能完整定义需求的软件开发。它的方法是用户先给出待开发系统的核心需求，并且在核心需求实现后，再提出反馈以支持系统的最终设计和实现。也就是说：开发人员首先会根据用户的需求开发核心系统，然后提供给用户试用；用户试用后再提出增强系统能力的需求；最后开发人员再根据用户的反馈，实施迭代开发。实际上，这个模式可看作是重复执行的多个瀑布模式。演化模式要求开发人员把项目的产品需求分解为不同组，以便分批循环开发。但这种分组并不是随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。 ③螺旋模式：它是瀑布模式与演化模式相结合，并加入两者所忽略的风险分析所建立的一种软件开发模式。螺旋模式基本的做法是在瀑布模式的每一个开发阶段之前，引入非常严格的风险识别、风险分析和风险控制。直到采取了消除风险的措施之后，才开始计划下一阶段的开发工作。否则，项目就很可能被暂停。另外，如果有充足的把握判断遗留的风险已降低到一定的程度，项目管理人员还可作出决定让余下的开发工作采用另外的生命周期模式，如演化模式，瀑布模式或自定的混合模式。 ④过程开发模式：它又叫混合模式或元模式，是指把几种不同模式组合成一种混合模式，它允许一个项目能沿着最有效的路径发展。因为上述的模式中都有自己独特的思想，现在的软件开发团队中很少说标准的采用那一种模式的，因为模式和实际应用还是有很大的区别的。实际上，许多软件开发团队都是在使用几种不同的开发方法组成他们自己的混合模式。 最后，我们来总结一下。螺旋模式是典型的迭代式生命周期模式，而RUP则是近代迭代式生命周期的代表。与螺旋模式相比，RUP将风险管理放在更重要的地位。最新的迭代式生命周期模式的代表是模式驱动架构（MDA）和敏捷（Agile）软件开发。MDA模式是基于可执行规格说明的思想，是现代转换模式的代表，其核心技术是组件技术。而敏捷开发生命周期的典型代表是XP编程，是把传统的系统设计和实现由敏捷软件开发过程中的验收测试、重构和测试驱动所取代；把传统的集成和部署由敏捷软件开发中的持续集成和短周期所取代。 其实上，无论是瀑布开发模式还是螺旋开发模式，软件生命周期模式的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱的情况。一些人为了能够管理和控制软件的开发过程，就把软件开发严格的区分为多个不同的阶段，并在阶段间加上严格的审查，这就是软件开发模式产生的起因。它们体现了人们对软件过程的一个希望：严格控制、确保质量。 （1）评估软件开发范围和需求 当软件所有参与人员都能理解软件开发的范围和需求时，就能为软件开发可能遇到的突发事情和未来变化建立一个技术基线。这个技术基线、基础规则和假设应该包含识别和评估软件的功能性。一般来说，在前期需求明确的情况下可尽量采用瀑布模式或改进型的瀑布模式。而在不确定性因素很多时或很多需求无法计划的情况下，应该尽量采用增量迭代模式或螺旋模式。 （2）确定软件开发规模和阶段划分 确定软件的开发规模是决定开发管理工具的重要一步，也是最为关键的步骤。因为确定开发规模和阶段划分是明确软件开发生命周期的驱动动力，它可用来约束在开发过程中所采用的行动和资源，以及限制可以提供的选项。例如，对于规模小的建议采用瀑布模式；而在资金和成本无法一次到位情况下可以采用增量模式；而对于完全多个独立功能的开发可以在需求阶段就分功能并行,但每个功能内可以遵循瀑布模式原则；而其他项目一般可采用迭代模式。 （3）选择合适的软件开发生命周期模式 一个定义良好的软件生命周期模式，可以很好的指导我们的开发工作，使漫长的开发工作易于控制。事实上，我们也可以任意定义自己喜欢的软件生命周期模式。但是，如果生命周期模式定义不合理，却会制约我们的开发过程。因此，选择一个软件开发模式不应当将其作为一次性的活动来考虑。因为随着开发项目的进展，未知内容会逐渐变为已知内容，并且新的和意料之外的问题和风险都会随之出现。所以，选择开发模式应该要根据实际情况来进行，然后在此基础上再加以裁减以作出适当的修改和改良。 （4）跟踪和度量开发模式的效率 在软件开发模式选定后，应该要定时跟踪和度量开发模式的效率。例如，记录那些相关的信息和得到的经验教训。通过这样做的目的是为了记录一个最佳开发模式的选择过程，以获得选择开发模式的经验性。因此，跟踪信息应当被不断的收集起来，并且同原始模式和基线进行比较。

⑵ 软件的生命周期

软件生命周期是指从软件定义、开发、使用、维护到报废为止的整个过程，一般包括问题定义、可行性分析、需求分析、总体设计、详细设计、编码、测试和维护。
问题定义就是确定开发任务到底“要解决的问题是什么”，系统分析员通过对用户的访问调查，最后得出一份双方都满意的关于问题性质、工程目标和规模的书面报告。
可行性分析就是分析上一个阶段所确定的问题到底“可行吗”，系统分析员对系统要进行更进一步的分析，更准确、更具体地确定工程规模与目标，论证在经济上和技术上是否可行，从而在理解工作范围和代价的基础上，做出软件计划。
需求分析即使对用户要求进行具体分析，明确“目标系统要做什么”，把用户对软件系统的全部要求以需求说明书的形式表达出来。
总体设计就是把软件的功能转化为所需要的体系结构，也就是决定系统的模块结构，并给出模块的相互调用关系、模块间传达的数据及每个模块的功能说明。
详细设计就是决定模块内部的算法与数据结构，也是明确“怎么样具体实现这个系统”。
编码就是选取适合的程序设计语言对每个模板进行编码，并进行模块调试。
测试就是通过各种类型的测试使软件达到预定的要求。
维护就是软件交付给用户使用后，对软件不断查错、纠错和修改，使系统持久地满足用户的需求。
软件的生命周期也可以分为3个大的阶段，分别是计划阶段、开发阶段和维护阶段。 瀑布模型
有时也称为V模型，它是一种线型顺序模型，是项目自始至终按照一定顺序的步骤从需求分析进展到系统测试直到提交用户使用，它提供了一种结构化的、自顶向下的软件开发方法，每阶段主要工作成果从一个阶段传递到下一个阶段，必须经过严格的评审或测试，以判定是否可以开始下一阶段工作，各阶段相互独立、不重叠。瀑布模型是所有软件生命周期模型的基础。
原型+瀑布模型
原型模型本身是一个迭代的模型，是为了解决在产品开发的早期阶段存在的不确定性、二义性和不完整性等问题，通过建立原型使开发者进一步确定其应开发的产品，使开发者的想象更具体化，也更易于被客户所理解。原型只是真实系统的一部分或一个模型，完全可能不完成任何有用的事情，通常包括抛弃型和进化型两种，抛弃型指原型建立、分析之后要扔掉，整个系统重新分析和设计；进化型则是对需求的定义较清楚的情形，原型建立之后要保留，作为系逐渐增加的基础，采用进化型一定要重视软件设计的系统性和完整性，并且在质量要求方面没有捷径，因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。原型建立确认需求之后采用瀑布模型的方式完成项目开发。
增量模型
与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。
一些大型系统往往需要很多年才能完成或者客户急于实现系统，各子系统往往采用增量开发的模式，先实现核心的产品，即实现基本的需求，但很多补充的特性(其中一些是已知的，另外一些是未知的)在下一期发布。增量模型强调每一个增量均发布一个可操作产品，每个增量构建仍然遵循设计-编码-测试的瀑布模型。
迭代模型
早在20世纪50年代末期，软件领域中就出现了迭代模型。最早的迭代过程可能被描述为“分段模型”。迭代，包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。
实质上，它类似小型的瀑布式项目。所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

⑶ 软件生命周期，常说是三个时期八个阶段，请问这三个时期的八个阶段分别是什么

软件计划与可行性研究阶段、需求分析阶段、软件设计阶段、软件编码阶段、软件测试阶段和软件运行与维护阶段。

1、软件计划与可行性研究阶段：此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。

2、需求分析阶段：在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，也是在整个软件开发过程中不断变化和深入的阶段，能够为整个软件开发项目的成功打下良好的基础。

软件常见周期模型：

1、瀑布模型

瀑布模型首先由Royce提出。该模型由于酷似瀑布闻名。在该模型中，首先确定需求，并接受客户和SQA小组的验证。

然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。

2、迭代式模型

迭代式模型是RUP推荐的周期模型，也是我们在这个系列文章讨论的基础。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。

⑷ 描述软件,软件项目,软件产品的生命周期以及三者的生命周期之间的关系 在线等

软件生命周期(SDLC，Systems Development Life Cycle,SDLC)是软件的产生直到报废的生命周期

软件项目的生命周期分为以下5种类型：
A: 编码修正模型：未成型的系统规范－>不断的编码修正—>发布
¨ B: 渐进模型：最初概念－>设计和实施最初原型－>不断的精化原型直到可以被接受（开发一个版本－>交付该版本－>得到用户反馈－>并入用户反馈）－>完成和交付最终版本
¨ C: 瀑布模型：软件概念<－>需求分析<－>架构设计<－>详细设计<－>编码和调试<－>系统测试
¨ D: 螺旋模型：确定目标，备选方案，约束条件－>识别和解决风险－>评价备选方案－>计划下一个迭代－>交付下一迭代解决方法－>确定目标，备选方案，约束条件
¨ E: 没有模型， 完全根据实际情况进行调整

产品生命周期（proct life cycle），简称PLC，是产品的市场寿命，即一种新产品从开始进入市场到被市场淘汰的整个过程。

软件生命周期包括软件项目的生命周期和产品生命周期，

⑸ 软件生命周期的周期模型

任何办公的流程处理；设计一种商务信函打印系统并投放市场。这个概念是不清晰的，但却是最高层的业务需求的原型。这个概念都会伴随着一个目的，例如在一个银行押汇系统 的目的是提高工作的效率。这个目的将会成为系统的核心思想，系统成败的评判标准。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） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险
一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

⑹ 从软件工程的三要素以及软件生命周期各个方面来谈谈使用面向对象的方法如何进行软件系统的开发与维护，并

摘要 软件工程方法为软件开发提供了“如何做”的技术。它包括了多方面的任务，如项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试以及维护等。

⑺ 什么是软件的生命周期软件生命周期分哪几个阶段

软件的生命周期是指软件的产生直到报废或停止使用的生命周期。

具体分为以下阶段：

一、问题定义：要求系统分析员与用户进行交流，弄清“用户需要计算机解决什么问题”然后提出关于“系统目标与范围的说明”，提交用户审查和确认。

二、可行性研究：一方面在于把待开发的系统的目标以明确的语言描述出来，另一方面从经济、技术、法律等多方面进行可行性分析。

三、需求分析：弄清用户对软件系统的全部需求，编写需求规格说明书和初步的用户手册，提交评审。

四、开发阶段：开发阶段由四个阶段组成：

1、概要设计。

2、详细设计。

3、实现：根据选定的程序设计语言完成源程序的编码。

4、测试。

五、维护：维护包括四个方面：

1、改正性维护：在软件交付使用后，由于开发测试时的不彻底、不完全、必然会有一部分隐藏的错误被带到运行阶段，这些隐藏的错误在某些特定的使用环境下就会暴露。

2、适应性维护：是为适应环境的变化而修改软件的活动。

3、完善性维护：是根据用户在使用过程中提出的一些建设性意见而进行的维护活动。

4、预防性维护：是为了进一步改善软件系统的可维护性和可靠性，并为以后的改进奠定基础。

⑻ 软件开发的生命周期

同任何事物一样,一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生存周期（软件生命周期）。把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理。通常，软件生存周期包括可行性分析与开发项计划、需求分析、设计（概要设计和详细设计）、编码、测试、维护等活动，可以将这些活动以适当的方式分配到不同的阶段去完成。
软件生命周期(SDLC，软件生存周期)是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。
软件生命周期(SDLC)的六个阶段
1、问题的定义及规划
此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
2、需求分析
在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。"唯一不变的是变化本身。"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
3、软件设计
此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。
4、程序编码
此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
5、软件测试
在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
6、运行维护
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。

⑼ 软件生命周期划分成哪些阶段

软件计划与可行性研究阶段、需求分析阶段、软件设计阶段、软件编码阶段、软件测试阶段和软件运行与维护阶段。

1、软件计划与可行性研究阶段：此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。

2、需求分析阶段：在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，也是在整个软件开发过程中不断变化和深入的阶段，能够为整个软件开发项目的成功打下良好的基础。

3、软件设计阶段（概要设计和详细设计）：主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。

4、软件编码阶段：是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。

5、软件测试阶段：在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。

6、软件运行和维护阶段：是软件生命周期中持续时间最长的阶段，包括纠错性维护和改进性维护两个方面。

(9)软件方法如何影响项目的生命周期扩展阅读

早期的软件生命周期往往是说“软件从计划、需求开始，经历分析设计、实现、部署、维护，直到最后逐渐消亡的”。

这是受到了第一个软件生命周期模型---瀑布模型影响，上述语句实质上简要的描述了瀑布型生命周期。

软件生命周期不再只考虑瀑布型生命周期，另外常见的软件生命周期模型有原型模型、螺旋模型、迭代模型。所以软件生命周期说明应当不再包括瀑布型生命周期中的典型阶段。

因此，对软件生命周期及软件生命周期模型采用如下定义：

1、软件生命周期是指软件的产生直到成熟的全部过程。

2、软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。