如文档对您有帮助，欢迎下载支持，谢谢！
1 综述
软件过程定义了软件开发中采用的方法。软件工程是集成计算机软件开发的过程、方法和工具的学科。
软件工程的一般视图：定义阶段（做什么）、开发阶段（如何做）、支持阶段（变化）。
2 线性顺序模型
有时被称为“传统生存周期或瀑布模型”。
活动包括：系统/信息工程和建模、软件需求分析、设计、代码生成、测试、支持 为什么线性模型有时候不能奏效？
建议：虽然线性模型经常被嘲笑为“旧式的”，但是，在需求被很好理解的情况下，它仍然是一种合理的方法。 缺点：
1、实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化而造成大的混乱。
2、 经常情况下客户难以表达真正的需求，而这种模型却要求如此，这种模型是不欢迎具有二义性问题存在的。 3、 客户要等到开发周期的晚期才能看到程序运行的测试版本，而在这时发现大的错误时，可能引起客户的惊慌，而后果也可能是灾难性的。
4、采用这种线性模型，会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去，有可能花在等待的时间比开发的时间要长。我们称之为“堵赛状态”。 优点：
1、它提供了一个摸板，这个摸板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导。
2、虽然有不少缺陷但比在软件开发中随意的状态要好得多。
瀑布模型将软件开发活动分为需求分析、设计、编码、测试等几个阶段，这几个阶段是对工程活动的划分，瀑布模型没有再涉及其它方面的活动，因此瀑布模型关注于工程活动。
关于选取开发模型
有时开发模型的选取不是很容易判断的，这里面有时不单是需求及开发的问题，对于开发商有开发周期、开发费用的问题，对于用户同样有内部计划、公司发展计划等因素进行影响。
一般来说对于应用开发―――为客户开发软件，客户在开发及测试完毕软件后就要实际开始使用，那么就使用瀑布模型。
当然在需求明确的情况下自然也要使用瀑布模型
对于自主开发及客户需求不明并有较长的设计时间―――可以用演化模型。
而螺旋模型适于适合于大型软件开发，吸收了\演化\概念，不过有时也用于用户需求不明的情况下。 当然还有其他开发模型，没有在本文讨论。 名词定义：
瀑布模型：规定了各项软件工程活动。包括：制定开发计划、进行需求分析和说明、软件设计、程序
1
如文档对您有帮助，欢迎下载支持，谢谢！
编码、测试及维护。
特点：自上而下，相互衔接的固定次序，如瀑布流水、逐级下落。
演化模型：第一次只是试验开发，其目标只在于探索可行性，弄清软件需求;第二次则在此基础上获得较为满意的软件产品，通常把一次得到的试验性产品称\原型\。 特点：减少由于软件需求不明确而给开发带来的风险。
螺旋模型：将瀑布模型及演化螺旋模型结合起来，并且加入被两种模型都忽略了的风险分析，弥补了两者的不足。
瀑布模型的特点：
① 瀑布模型为软件的开发和维护提供了一种有效有管理模式，对保证软件产品的质量有重要的作用；
② 可根据这一模式制定出开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段，有效地对整个开发过程进行指导； ③ 在一定程度上消除非结构化软件、降低软件的复杂度、促进软件开发工程化方面起到显著作用； ④ 瀑布模型缺乏灵活性、无法通过开发活动来澄清本来不够确切的需求，这将导致直到软件开发完成时发现所开发的软件并非是用户所需求的。
3 原型实现模型
原型实现范型定义： 需求收集 快速设计
原型实现模型是迭代的，是帮助客户或开发者理解需求的，总体上讲，并不是交付一个最终产品系统。其流程从听取客户意见开始、随后是建造/修改原型、客户测试运行原型、然后回头往复循环直到客户对原型满意为止。由于这种模型可以让客户快速的感受到实际的系统（虽然这个系统不带有任何质量的保证），所以客户和开发者都比较喜欢这种过程模型（对于那些仅仅用来演示软件功能的公司而言或从来不考虑软件质量和不害怕长期维护的公司而言）。 缺点：
1、没有考虑软件的整体质量和长期的可维护性。
2、大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工具被采用仅仅为了它的方便，还有不合适的被选择等等。
3、由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计。 优点：
1、如果客户和开发者达成一致协议：原型被建造仅为了定义需求，之后就被抛弃或者部分抛弃， 那么这种模型很合适了。
2、迷惑客户抢占市场，这是一个首选的模型。 原型实现仍然是软件工程的一个有效范型。关键是定义开始时的游戏规则，即客户和开发者达成一致：原型被建造仅是为了定义需求，之后就被抛弃了（或至少部分被抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。
建议：当你的客户有一个合理的续签，但对细节没有任务线索时，先开发一个原型。
2
如文档对您有帮助，欢迎下载支持，谢谢！
原型模型则主要是为了解决需求获取的难题而创建原型用于需求的获取和确认，再将需求转化为软件系统，其主要内容集中在软件开发本身，因此原型模型也关注于工程活动。
4 RAD模型
快速应用开发（Rapid Application Development、RAD）是一个增量型的软件开发过程模型，强调极短的开发周期。是线性顺序模型的一个“高速”变种，通过使用基于构件的建造发放赢得了快速开发。如果需求理解的好而且约束了项目的范围，利用这种模型可以很快的创建出功能完善的“信息系统”。其流程从开始，随后是、过程建模、应用生成、测试及反复。RAD过程强调的是复用，复用已有的或开发可复用的构件。实际上RAD采用第四代技术。
基于构件的软件工程（不理解） 适用范围：
如果需求理解得很并且约束了项目范围。主要适用于信息系统应用，包括以下阶段：业务建模、数据建模、过程建模、应用生成、测试及反复。
业务建模工作流程与其他工作流程的关系如下：
业务模型是需求工作流程的一种重要输入，用来了解对系统的需求。
业务实体是分析设计工作流程的一种输入，用来确定设计模型中的实体类。
缺点：
1、只能用于信息系统。
2、对于较大的项目需要足够的人力资源去建造足够的RAD组。 3、开发者和客户必须在很短的时间完成一系列的需求分析， 任何一方配合不当都会导致RAD项目失败。
4、这种模型对模块化要求比较高，如果有哪一功能不能被模块化，那么建造RAD所需要的构件就会有问题。
5、技术风险很高的情况下不适合这种模型。 优点：
1、开发速度快，质量有保证。 2、对信息系统特别有效。
5 演化软件过程模型
演化模型是迭代的。它的特征是：使软件工程师渐进地开发逐步完善的软件版本。
5.1 增量模型
增量模型融合了线性顺序模型的基本成分（重复的应用）和原型实现的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的
3
软件工程生命周期模型学习总结
