软件生命周期的七个阶段
 
　　1、问题的定义及规划
 
　　此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
 
　　2、需求分析
 
　　在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。"唯一不变的是变化本身。"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
 
 
　　3、软件设计
 
　　此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。
 
 
　　4、程序编码
 
　　此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
 
　　5、软件测试
 
　　在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程主要分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
 
 
　　6、系統轉換
 
　　將作業由舊系統轉換新系統，也就是說運行系統的方法，轉換方法有平行、分批、分發、立即、試驗五種轉換方法。
 
　　7、运行维护
 
　　软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面

 
软件生命周期漫谈

 
自1946年第一台计算机发明以来，对人类的生产活动和社会活动产生了极其重要的影响，并以强大的生命力飞速发展。计算机硬件、软件、操作系统等纷纷应运而生，并发展壮大，时至今日，计算机已经成为人类社会不可或缺的，无可替代的强大工具之一，被看做是20世纪以来最伟大的发明之一。其中，计算机软件在现代社会和经济生活中占有极其重要的地位，在各个领域中发挥着越来越重要的作用。
 谈到软件，就绕不开软件生命周期这个永恒的话题，作为软件工程专业的学生，我个人认为，软件工程就是按照工程学的管理方式，有组织、有计划的，在一定的质量基础、时间限度和成本范围内，实现功能明确，符合用户主观要求的软件。开发软件，就必须去熟悉一整套的开发流程（也就是软件的生命周期），以此来更好，更合理，更专业地开发软件。
 
 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，也就是软件的生命周期。概括来讲，软件的生命周期大体上分为3个主要阶段：软件定义时期，软件开发时期和软件运行和维护时期。这三个时期紧密联系，缺一不可，可以说牵一发而动全身。在软件定义时期，主要任务包含：问题定义，可行性分析和需求分析。软件开发时期包含系统设计和系统实现，系统设计主要是指概要设计和详细设计，系统实现主要包括编码和单元测试与综合测试。软件运行维护时期的主要任务是使软件持久地满足用户的需要。
 软件不同于硬件，软件作为一种逻辑产品，看不见，也摸不着，由于软件缺乏“可见性”，在写出程序代码并在计算机上试运行之前，软件开发过程的进展情况往往较难衡量，软件的质量的较难评价，因此，管理和控制软件开发过程相当地困难。此外，软件在运行过程中不会因为使用时间过长而被“用坏”，如果运行过程中发现错误，很可能是遇到了一个正在开发时期引入的在测试阶段没能检测出来的错误，因此，软件维护通常意味着改正或修改原来的设计甚至整个架构，这就在客观上使得软件在一定程度上较难维护。
 同时，软件作为一种知识产品，它并不像是工业加工产品那样可以实现规模量产，软件的这种特性使得它很容易被复制粘贴，知识产权较难得以保护。另外,软件是一种团队行为，尤其是那种规模较大的软件，为了在有效时间内开发出来，必须要求开发团队之间有一个很好地合作，并且紧密贴合软件生命周期，使用合适的生命周期模型，尽可能用最短的时间，最低的成本，最优的人员配置高效率地进行开发。
 在实际的软件开发过程中，软件规模，种类，开发环境及开发时间和开发时所用的技术方法等等，都会在不同程度影响阶段的划分。在软件的生命周期里，每一个步骤可以说都是至关重要，尤其是在开发前期，设计上错误或缺陷如果到了后期才慢慢发现的话，对整个开发过程来说将是一个毁灭性的代价。据统计，大约百分之六十以上的软件失败的原因都归结于前期的需求分析阶段和设计阶段的失误。可以说是一步错，步步错。软件开发过程的种种问题，不论是人员配置不合理，需求分析不全面，还是系统架构不合理，开发经费利用不当等等，都会直接导致软件危机的产生。
 那么究竟怎么样开发软件，才能够尽最大可能降低开发的错误和风险呢？
 首先，既要有技术措施（方法和工具），又要有必要的组织管理措施。在技术层面，技术水平的高低往往体现在开发团队中个人的技术水平和专业修养。因为软件的开发工作，说到底，还是看人。例如，你组建一个5人的小型团队，团队里全是技术大牛，甚至是高级架构师，顶级黑客那种，可想而知，他们之间通过密切合作，很可能会在最短时间内高质量完成一个中型项目。这得益于他们每个人的技术涵养。当然，对他们而言，因为每个人掌握的知识都比较全面且有深度，因此大大降低了他们之间的沟通成本，实现了效率最大化。相反，一群刚入职的新人，他们项目经验很少，技术涵养不够，同时也不能够做到知识全面，你学的前端，他学的后端，所谈论的内容风马牛不相及，沟通成本巨大，开发效率低，可想而知，必然做不出一款出色的软件。这就要求公司的面试官提高门槛，提高对面试者的要求，积极为公司引进高技术人才。另外，公司自己的开发工具也应该规范化，一致化，降低版本冲突，必要的时候开发出一整套属于公司自己内部使用的工具和框架，方便工作小组的开发，减轻软件协调的负担，使成员们更多地把注意力放到算法和架构设计上，避免被开源软件的繁琐设计而焦头烂额。接下来就是组织管理措施方面了，不论什么行业，最最难管的就是人了。尤其在软件开发方面，参与开发的成员过少，会严重影响到软件的整体进度，开发人员过多，又会大大增加各个成员之间的沟通成本，我们知道，点越多，两点之间的连线个数会呈指数方式增长，开发小组之间的沟通亦是如此。因此开发组的管理者务必要做到：让最合适的人去干最合适的活，要学会识人、用人、管人。开发小组的成员必须做到：各司其职，做好本职工作，拥有集体意识，不拖后腿，不搞独立。
 接下来我们对软件生命周期的各个步骤进行详细的讨论。在问题定义阶段，需要详尽的了解需要解决的问题是什么，也就是说，作为软件的开发者，在这个阶段系统分析员必须弄清用户“需要计算机解决什么问题”。如果在问题尚未明确的情况下就试图解决这个问题，那么就会白白浪费时间和精力，结果也毫无意义。因此，该阶段的基本任务就是分析要解决的问题，撰写并提交问题定义报告。一般情况下，我们做完问题定义，需要再进一步跟客户确认，如果客户觉得满意，那么该问题定义报告即可作为下一步工作，可行性研究的依据。同时我们也应该认识到，客户对于问题定义的过程往往是模糊的，这就要求系统分析员通过深刻了解客户需求，搞清楚用户的实际需求，对用户的目标了如指掌。在撰写问题定义的书面报告时，要确保一针见血，条理清楚，确保开发人员，客户都能够看懂并拥有一致的看法。该阶段是软件生命周期中最简短的阶段，一般建议1天甚至更短时间内完成。
 然后进入可行性分析阶段，按照定义，可行性分析是通过对项目的主要内容和配套条件，如市场需求、资源供应、建设规模、工艺路线、设备选型、环境影响、资金筹措、盈利能力等，从技术、经济、工程等方面进行调查研究和分析比较，并对项目建成以后可能取得的财务、经济效益及社会环境影响进行预测，从而提出该项目是否值得投资和如何进行建设的咨询意见，为项目决策提供依据的一种综合性的系统分析方法。必须记住，可行性研究的目的不是解决问题，而是确定问题是否值得去解。要达到这个目的，不能靠主观猜想而只能靠客观分析。可行性研究的最终要提交可研报告。
 软件定义阶段的重点是需求分析，需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，这个阶段的任务仍然不是具体地解决客户的问题，而是准确地回答“目标系统必须做什么”这个问题。我个人认为这个阶段最难的是准确了解用户的实际需求，但用户并不具备我们的专业素养，很多情况下，与用户沟通是一件非常困难的事情，因为我们说人类的自然语言虽然容易理解，但同时也存在着许多二义性，用户想要表达的内容和我们所理解的很可能不在一个层面，这就要求我们尽可能多的与用户交流，了解用户的实际需求，确定软件的目标和方向。有时，因为每个人的表达能力有限，客户甚至都不能够准确表达自己的实际想法。这就更要求我们的系统分析员切身的从用户的角度和利益出发，但不是绝对的服从用户，因为有时连用户也不明确自己的实际需求，这一点上就需要加上我们的主观判断，最好是使用一些开发周期模型比如快速原型模型，它可以及早提供有用产品，及早发现问题，及时改错。通过快速原型模型，我们花费较少的时间成本做出产品的原型，然后采集客户的满意度，这样一来就降低了风险，减少了开发的时间，提高了开发的效率。同时呢，用户也可以实时参与进来，增加了沟通，明确了需求，降低了风险，提高了效率。这一阶段的会形成一个需求规格说明书，它是一个十分重要的文档，对于后期的开发，运行与维护起着举足轻重的作用。
 然后就到了软件开发阶段，它包括系统设计和系统实现两大部分。设计阶段是架构师和设计师的主要任务，而系统实现是开发师的主要任务。如果要设计出一个软件，工作量庞大而且复杂，而且我们很难找到一个切入点去下手。这时我们可以先做出概要设计，我们的设计师应该设计出目标系统的几种可能方案，然后再综合经济成本，软件可能的规模与复杂度进行优胜劣汰。最终我们再根据方案制定出详细的设计方案。在设计程序时，应该遵循高内聚，低耦合和面向对象、面向抽象的原则，充分采用的模块化的编程思想，将程序的健壮性，可扩展性和可维护性都体现到位。蓝图绘制好了，接下来我们就开始盖大楼。在编码与测试阶段，程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时采用汇编语言），把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。综合测试阶段的关键任务是通过各种类型的测试使软件达到预定的要求，最基本的测试是集成测试和验收测试。
 最终到了软件的运维阶段。为了使软件的功能持久地满足用户的需要，必须进行各种维护活动，包括改正性维护、适应性维护、完善性维护和预防性维护。软件的维护往往繁琐且枯燥，作为一个长期性的工作，它通常占据了整个软件开发费用的一半以上。从结构层次来看，软件维护其实可以看做前面生命周期的小循环，他对于软件的维护人员提出了更高的要求，并且会特别依赖前期设计好的架构和文档。
 以上就是我对于软件生命周期的粗浅认识，直至今日，软件危机依然没能够得到有效解决，几乎所有的软件都不同程度地存在软件危机，究其原因，是因为软件开发的工程方法学和软件生命周期模型没有利用好，我相信在不久的将来，软件开发的过程将进一步完善和发展，软件危机将会进一步的削弱。技术是不断进步的，谁也无法阻止科技前进的步伐，在人工智能和大数据、物联网的冲击下，未来的软件，路在何方，答案托付在了我们这代年轻，富有朝气的年轻程序员们，我们，将不辱使命！

软件声明周期
 
软件声明周期由软件定义、软件开发和运行维护 3个时期组成，每个时期又进一步划分成若干个阶段。
 
软件定义时期
 
软件定义时期的任务：
 
确定软件开发工程必须完成的总目标
确定工程的可行性
导出实现工程目标应该采用的策略及系统必须完成的的功能
估计完成该项目工程需要的资源和成本，并且制定工程进度表。这个时期又称为系统分析，由系统分析员负责完成
 
软件定义时期通常进一步划分为3个阶段，即问题定义、可行性研究和需求分析。
 
 
开发时期
 
开发时期具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：
 
总体设计
详细设计
编码和单元测试
综合测试
 
其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。
 
 
维护时期
 
维护时期的主要任务是使软件持久地满足用户的需要。
 
当软件在使用过程中发现错误时应该加以改正
当环境改变时应该修改软件以适应新的环境
当用户有新要求时应该及时改进软件以满足用户的新需要
 
通常对维护时期不再进一步划分阶段，但是每一次维护活动本质都是一次压缩和简化了的定义和开发过程。
 
 
问题定义
 
问题定义阶段必须回答的关键问题是：“要解决的问题是什么？” 如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。
 
通过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告，经过讨论和必要的修改之后这份报告应该得到客户的确认。
 
可行性研究
 
这个阶段要回答的关键问题是：“对于上一个阶段所确定的问题有行得通的解决办法吗？” 为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析员和设计过程，也就是在较抽象的高层次上进行的分析和设计过程。可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。
 
可行性研究的结果是客户作出是否继续进行这项工程的决定的重要依据，一般说来，只有投资可能取得较大效益的那些工程项目才值得继续进行下去。可行性研究以后的那些阶段将需要投入更多的人力物力。及时终止不值得投资的工程项目，可以避免更大的浪费。
 
需求分析
 
这个阶段的任务仍然不是具体地解决问题，而是准确地确定**“为了解决这个问题，目标系统必须做什么”**，主要是确定目标系统必须具备哪些功能。
 
用户了解它们所面对的问题，知道必须做什么，但是通常不能完整准确地表达出他们的要求，更不知道怎样利用计算机解决他们的问题；软件开发人员知道怎样用软件实现人们的要求，但是对特定用户的具体要求并不完全清楚。因此，系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法表示系统的逻辑模型。
 
在需求分析阶段确定的系统模型是以后设计和实现目标系统的基础，因此必须准确完整地体现用户的要求。这个阶段的一项重要任务，是用正式文档准确地记录对目标系统的需求，这份文档通常称为规格说明书（specification）。
 
总体设计
 
这个阶段必须回答的关键问题是：“概括地说，应该怎么实现目标系统？” 总体设计又称为概要设计。
 
首先，应该设计出实现目标系统的几种可能的方案。通常至少应该设计出低成本、中成本和高成本3种方案。软件工程师应该用适当的表达工具描述每种方案，分析每种方案的优缺点，并在充分权衡各种方案的利弊的基础上，推荐一个最佳方案。此外，还应该制定出实现最佳方案的详细计划。如果客户接受所推荐的方案，则应该进一步完成下述的另一项主要任务。
 
上述设计工作确定了解决问题的策略及目标系统中应该包含的程序，但是，怎样设计这些程序呢？软件设计的一条基本原理就是，程序应该规模化，也就是说，一个程序应该由若干个规模适中的模块按合理的层次结构组织而成。因此，总体设计的另一项主要任务就是设计程序的体系结构，也就是确定程序由哪些模块组成以及模块间的关系。
 
详细设计
 
总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解决办法具体化，也就是回答下面这个关键问题："应该怎样具体地实现这个系统呢？"
 
这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。
 
详细设计也称为模块设计，在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。
 
编码和单元测试
 
这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。
 
程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时使用汇编语言），把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。
 
综合测试
 
这个阶段的关键任务是通过各种类型的测试（及相应的调试）使软件达到预订的要求。
 
最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测验的模块按照某种选定的策略装配起来，在装配的过程中对程序进行必要的测试。所谓验收测试则是按照规格说明书的规定（通常在需求分析阶段确定），由用户（或在用户积极参加下）对目标系统进行验收。
 
必要时还可以再通过现场测试或平行等方法对目标系统进一步测试检验。
 
为了使用户能够积极参加验收测试，并且在系统投入生产性运行以后能够正确有效地使用这个系统，通常需要以正式的或非正式的方式对用户进行培训。
 
通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求，也可以决定测试和调试过程什么时候结束。
 
应该用正式文档资料把测试计划、详细测试方案以及实际测试结果保存下来，作为软件配置的一个组成部分。
 
软件维护
 
维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。
 
通常有4类维护活动：
 
改正性维护，也就是诊断和改正正在使用过程中发现的软件错误；
适应性维护，即修改软件以适应环境的变化；
完善性维护，即根据用户的要求改进或扩充软件使它更完善；
预防性维护，即修改软件，为将来的维护活动预先做准备。
 
虽然没有把维护阶段进一步分成更小的阶段，但是实际上每一项维护活动都应该经过提出维护要求（或报告问题），分析维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化的软件定义和开发的全过程。
 
每一项维护活动都应该准确地记录下来，作为正式文档资料加以保存。
 
 
总结
 
以上根据应该完成的任务的性质，把软件生命周期划分成8个阶段。在实际从事软件开发工作时，软件开发工作时，软件规模、种类、开发环境及开发时使用的技术方法等因素，都影响阶段的划分。事实上，承担的软件项目不同，应该完成的任务也有差异，没有一个适用于所有软件项目的任务集合。适用于大型复杂项目的任务集合，对于小型简单项目而言往往就过于复杂了。

一、瀑布模型
 
瀑布模型各个阶段为：计划，需求分析，设计，程序编码，软件测试，运行维护。
 
 
瀑布模型将软件生命周期的各项活动自上而下如瀑布流水依次连接，上一阶段的输出作为下一阶段的输入，同时，在每一个阶段如果发现问题，都可以逆流而上，向上一阶段进行反馈，然后做适当的修改，但是只能逐层反馈，不能跨级反馈。
 
通过瀑布模型归纳得出：如果每一阶段都能保证有效性，那么最终产生的结果也能保证其有效性。
 
通过各个阶段，会依次输出（即下一阶段的输入）以下产品：软件需求规约，设计文档，实际代码，测试用例，最终产品等等。
 
瀑布模型的优点：
 
有良好的需求确认入口，为后续的开发奠定良好的基础。
强调设计过程。软件是“创造”出来的，不是“制造”出来的，所以设计显得格外重要。
每一阶段结束后要进行复审，允许获取方/用户的参与，有效的控制了系统的质量问题。
当前一阶段完成时，只需要关注后续阶段即可。（已经确保了前一阶段的有效性）
瀑布模型的缺点：
 
客户必须能完整、正确和清晰的表达出需求，同时开发人员一开始就必须理解需求。（实际上在很多项目中，客户都很难在一开始就表达出明确的需求，开发人员也很难在一开始就理解所有需求）
缺乏灵活性。如果一开始的需求出现了偏差，那么很大可能会导致最终产品出现偏差。
各阶段可能会产生过多文档，造成不易管理。
在瀑布模型结束之前都不能演示系统的功能，增加了项目的风险。
 
 
二、增量模型
 
增量模型将需求进行分段，分成一系列增量产品，每一增量可以分别开发，即：将软件模块化，每一模块为一增量组件，然后分别进行开发，所有增量叠加在一起就形成了最终的软件产品。
 
 
另外，每一个增量分别开发时，都是一个瀑布模型，所以可以把增量模型看成是瀑布模型的升级版，瀑布模型的变体。
 
增量模型的优点：
 
由于增量模型作为瀑布模型的变体，所以增量模型具有瀑布模型的所有优点，除此之外还有：
 
第一个可交付版本所需成本和时间相比于瀑布模型来说是很少的，比如说第一个增量只有软件的核心功能。
能很快的看到一些成果，增加开发人员的信心。
开发风险相对不大。（大事化小，小事化了，分而治之）
由于可以很快的发布第一格版本，因此可以减少用户需求的变更，对用户形成了制约。
增量模型的缺点：
 
由于初始增量是后续增量的基础，所以如果要对初始增量的需求进行修改，可能会影响后续的增量。
增量模型要求必须有一部分的需求是可以确定的（即：不用把所有需求都确定下来，但是必须要先确定一部分），因为每一个增量都相当于是一个瀑布模型，这样就不难理解了。
增量过多会造成管理成本超支，影响进度。
 
 
三、演化模型
 
演化模型能在需求不明确的情况下，通过不断迭代，逐步让需求明确。经过多次迭代，每次迭代都会历经需求分析，设计，编码，测试，运行这些过程。每次迭代产生一个增量，迭代后所产生的结果都会向用户进行反馈，然后根据用户的要求再对需求进行修改，然后进行下一次迭代，这样不断迭代，最终产生用户满意的产品。
 
 
其中每一个迭代过程都相当于一个小的瀑布模型，只是在需求分析阶段不太一样。
 
注：不能弱化需求分析阶段的工作！
 
演化模型的优点：
 
在需求不明确的情况下，可以使用该模型。
用户可以通过运行系统来对需求进行改进。
需要更多用户/获取方的参与，增加了对软件质量的控制。
演化模型的缺点：
 
每个迭代都会有管理成本，较多的迭代使得管理成本较大。
容易让开发团队有不进行需求分析的借口。
用户不易理解该模型不断迭代演化的特点，因此当某次迭代后的反馈不理想时，用户容易产生抱怨情绪。（实际上，这一缺点也是帮助了开发团队能从用户那儿获取到更明确的需求，因为用户抱怨，不满意，所以会提出改进意见，使得需求更加明确，促进了下一次的迭代）
注：其实很多用户都有一个特点：说不清楚自己想要什么，但是当东西放在他面前的时候，他却能挑出一堆的毛病来。
 
 
 
四、喷泉模型
 
喷泉模型主要用于描述面向对象的软件的开发过程，该模型自下而上，各阶段无缝连接，可多次迭代。
 
迭代：目的是求精。系统某部分被重复工作多次，相关的功能在迭代中逐渐接近完善。
 
无缝：即各个阶段之间不存在明显的边界。
 
 
喷泉模型的优点：
 
由于各阶段是无缝连接的，所以各阶段可以同步开发，提高开发效率。
喷泉模型的缺点：
 
由于多次迭代，会产生大量的文档，会导致文档管理困难。
 
 
五、螺旋模型
 
螺旋模型是在瀑布模型和演化模型的基础上加入了风险分析。一个迭代过程为：制定计划，风险分析，开发，评估。这四个活动分布在笛卡尔坐标的四个象限中，一个象限表示一个活动。
 
 
从制定计划开始，然后风险分析，如果通过了风险分析，则进入开发阶段，开发完成后再进行评估。评估后又进入外一层螺旋进行下一次循环迭代，制定计划，风险分析。。。直到项目开发完成或者没有通过风险分析为止。
 
螺旋模型其实和演化模型有些类似，都是通过不断迭代去完善需求，完善系统。但是，螺旋模型有一个最大的特点就是：风险分析。
 
螺旋模型的优点：
 
对大型的项目有较好的风险控制能力。
螺旋模型的缺点：
 
需要分析人员有风险分析的经验，因为分析失误会造成很大的损失。
螺旋模型周期相对较长，所以不适用于大部分软件开发项目。
 
 
六、快速原型模型
 
快速原型是快速建立起来的程序，它只是最终产品的子集（或雏形），建立快速原型的作用是帮助用户确定需求以及可以用于确定项目的可行性。
 
 
快速原型模型主要部分可以分为：
 
原型快速分析：分析者和用户相互配合，快速确定软件系统的基本需求。
原型构造：在原型快速分析的基础上，只考虑主要特性，快速构造一个可运行的系统。
原型运行与评价：开发人员与用户频繁沟通，发现问题，消除误解，目的是发现新需求并修改原有需求。
原型修正：根据新需求对原型系统进行修正。
判定原型完成：若原型修改后获得了参与者的一致认可，那么原型开发的迭代就可以结束了。
快速原型模型的优点：
 
主要针对于小型的、快捷的，并且需求不明确的项目.
有的软件原型可以作为最终产品的一部分。
快速原型模型的缺点：
 
快速建立的系统结构加上连续修改可能导致产品质量低下，原型系统的内部结构可能不好。