摘要：【常见的软件过程模型】软件工程模型软件工程的模型都有哪几种？ 我理解你的问题是软件生命周期模型有几种？软件行业中常见的有： 瀑布模型 V过程模型 原型实现模型 快速应用开发（RAD） 增量模型 螺...

【常见的软件过程模型】软件工程模型软件工程的模型都有哪几种？...

我理解你的问题是软件生命周期模型有几种？软件行业中常见的有： 瀑布模型 V过程模型 原型实现模型 快速应用开发（RAD） 增量模型 螺旋模型 极限编程（XP） 选择适当的生命周期模型，并可利用混合方式进行。

具体参见《软件生命周期模型及其选择》，地址： RUP参见《软件生命周期》，地址：

软件测试中---v模型和w模型的区别？

软件工程学会SEI的CMM模型的五个梯级如下，如图4所示： （1） 初始的（Initial）：在这一成熟水平的组织，其软件开发过程是临时的、有时甚至是混乱的。

没有几个过程是被定义的，常常靠个人的能力来取得成功。

（2） 可重复的（Repeatale）：在这一成熟水平的组织建立了基本的项目管理过程来跟踪软件项目的成本、进度和功能。

这些管理过程和方法可供重复使用，把过去成功的经验用于当前和今后类似的项目。

（3） 被定义的（Defined）：在这个水平，管理活动和软件工程活动的软件过程被文档化、标准化，并被集成到组织的标准软件过程之中。

在该组织中，所有项目都使用一个经批准的、特制的标准过程版本。

（4） 被管理的（Managed）：在这一水平，组织收集软件过程和产品质量的详细措施。

软件过程和产品都被置于定量的掌控之中。

（5） 优化的（Optimizing）：处于这一成熟度模型的最高水平，组织能够运用从过程、创意和技术中得到的定量反馈，来对软件开发过程进行持续改进。

寻找软件工程模型资料有关瀑布模型/螺旋模型/演化模型（原型）/喷

1.瀑布模型（watefall model） 2.演化模型（evolutionay model） 3.螺旋模型（spial model） 每个模型都有自己的优缺点 我想就这个讨论一下 1、瀑布模型 瀑布模型将软件生命周期的各项活动规定为依固定顺序联接的若干阶段工作，形如瀑布流水，最终得到软件产品 瀑布模型的特点是首先是仔细的需求分析，开发组有步骤的制定一份功能（结构）说明，接着是概要设计，详细设计，然后才着手编码。

编码结束后进行测试，然后才能发布软件。

这看上去是很有逻辑的；只在理解后才开始构造。

以这样严格的方式构造软件，工程师很明确每一步应该做什么。

许多人提出了基本是基于这一模型的多种方法论；也有相当多的商业工具可以使这些步骤更机械化且不易出错。

瀑布模型各阶段的工作自顶向下从抽象到具体顺序进行。

瀑布模型意味着在生命周期各阶段间存在着严格的顺序且相互依存。

瀑布模型是早期软件设计的主要手段 瀑布模型依靠早期的需求分析，并且要求需求很明确 对于需求未定或是不断变化的软件不适合 现在这种模型一般用于做一些需求已明确的并很少变化的软件，不适于需求 不明确或是容易变化的软件（如你正在开发一个陌生的领域的软件，这时就不应该使用瀑布模型，但是如果你正在开发自己很熟悉领域的软件，就可以使用瀑布模型来加快开发速度） 2、演化模型 该模型主要针对事先不能完整定义需求的软件开发。

用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。

软件开发人员根据用户的需求，首先开发核心系统。

当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。

软件开发人员根据用户的反馈，实施开发的迭代过程。

第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。

如图所示。

3、螺旋模型 瀑布模型与演化模型相结合，并加入两者所忽略的风险分析所建立的一种软件开发模型。

该模型于1998年由美国TRW公司（B.W.Boehm）提出。

软件项目风险的大小作为指引软件过程的一个重要因素，引入这一概念有可能使得软件开发被看作一种元模型，因为它能包容任何一个开发过程模型。

螺旋模型基本的做法是在“瀑布模型”的每一个开发阶段之前，引入非常严格的风险识别、风险分析和风险控制。

直到采取了消除风险的措施之后，才开始计划下一阶段的开发工作。

否则，项目就很可能被取消。

另外，如果有充足的把握判断遗留的风险已降低到一定的程度，项目管理人员可作出决定让余下的开发工作采用另外的生命周期模型，如“演化模型”，“瀑布模型”，或自定的混合模型。

优点： a.强调严格的全过程风险管理。

.强调各开发阶段的质量。

c.提供机会检讨项目是否有价值继续下去。

缺点： a.引入非常严格的风险识别，风险分析，和风险控制，这对风险管理的技能水平提出了很高的要求。

这需要人员，资金，和时间的投入。

在软件工程一体化中,有哪些面向对象模型？有哪些建模工具？

面向对象与结构化方法的比较研究 xxx (xxxxxxxxxx) 摘要：随着计算机的硬件及通讯技术的发展，计算环境发生了深刻的变化。

计算环境的变迁和不断增长的软件需求对程序设计方法学提出了一个又一个的挑战，程序设计方 法学也在挑战中前进。

首先回顾软件工程程序设计方法的发展历史，指出结构化和面向对象是软件工程程序设计方法中的2个核心思想，分析、探讨了结构化程序设 计方法与面向对象的方法的区别，并就如何在实践中正确应用给出了一些建议。

关键字：程序设计方法； 面向对象； 结构化1引言：随着计算机硬件及通讯技术的发展，计算机环境发生了深刻的变化，计算机环境的变迁和不断增长的软件需求对程序设计方法提出了一个有一个挑战，程序设计方法也在挑战中前进。

计算机发展经历了3个主要阶段：大型主机，客户/服务器以及网络计算。

与此相对应，软件工程的设计方法的发展可分为4代。

1.1第一代面向过程的程序设计方法 面向软件系统的信息流程图，采用面向过程的程序设计语言或面向进程的程序设计语言，实现软件设计流程图所描述的信息处理过程的功能，称为面向过程的程序设计方法或面向进程的程序设计方法。

这种方法适用于设计小规模专业软件包，软件的通用性、重用性和扩展性差。

1.2 第二代面向模块的程序设计方法 结构上将软件系统划分为若干功能模块或实体，分别采用模块化程序设计语言，如：pascal 编程实现，再由各模块联结，组合成相应结构的软件系统，称为面向模块的程序设计方法或模块化程序设计方法，也称为面向实体的程序设计方法。

这种方法适用于设计模块化、结构化程序，可提高软件系统的模块化和结构化水平，设计和组装较大规模的软件系统，有助于提高软件的通用性、重用性和扩展性。

1.3 第三代面向对象的程序设计方法 所谓对象是指具有一定结构、属性和功能的实体，采用对象和对象类，以及对象之间的相互通信的消息，描述客观世界中的各种事物及其相互关系，建立面向对象和消息的具有层次结构的世界模型。

面向对象的程序设计方法基于上述面向对象世界模型。

采用面向对象的程序设计语言，如c++、smalltalk 等编程实现。

这种方法具有通用性，适用于广泛应用领域的大规模软件系统设计。

有助于提高软件的重用性、扩展性和移植性，提高编程效率和程序自动化水平。

1.4 第四代面向智体的程序设计方法 面向智体的程序设计方法是面向对象的程序设计方法的发展。

在程序设计方法的发展演变历程中，结构化和面向对象思想是最核心的思想方法。

结构思想体现了人们抽象思维和复杂问题分解的基本原则与要求，而面向对象则反映了客观世界由对象组成这一本质特点。

2 软件工程程序设计方法的出发点 从程序结构来看，每个子问题形成整个程序结构的一个构件，这个构件称为一个模块。

程序的算法结构，就是一个由模块连接成的层次结构。

在软件工程中，把这种设计方法归结为软件工程设计方法学。

该方法学的基本表述为：自顶向下，逐步求精，模块化层次结构设计。

程序设计方法的本质是问题的抽象与分解，各种程序设计方法的区别在于其分解的因子不一样，处理数据对象及相关操作的方法不一样，也就是出发点不一样。

3 结构化程序设计方法 结构化程序设计方法包含以下内容。

3.1 结构化技术 结构化技术包括结构化分析（S A ）、结构化设计（SD ）、结构化程序设计（SP ）3 方面内容，对应于软件开发时期的分析、设计和编码阶段。

3.2 结构化分析 结构化分析是70 年代中期由DeMarco 和Yourdon等倡导的一种基于功能分解的分析方法，即使用数据流程图、决策表、决策树等工具，来建立一种符合用户需求的结构化说明书。

3.3 结构化设计 结构化设计是一种面向数据流的设计方法，也就是采用最佳的可能方法设计系统的各个组成部分以及各成分之间的内部联系的技术，目的在于提出满足系统需求的最佳软件的结构，完成软件层次图或软件结构图。

4 面向对象的方法 面向对象技术：面向对象技术包括面向对象分析（O O A ）、面向对象设计（O O D ）及面向对象程序设计（O O P ）3 部分内容。

O O P 是在结构化程序设计的基础上，于8 0 年代初涌现的一种程序设计方法，但其真正显示力量和被产业界所重视还是最近几年的事。

封装是整个O O P 方法的基础，主要用于在数据段外围构造保护层，以限制外界变化的影响，所有的数据访问都由保护层内的过程间接处理。

应用程序员不必再按照将程序设计语言逐句拼装的方式来构造整个软件，只需组合、重用由系统程序员开发、可供他人用来装配的软件集成块即可。

例如，Visual Basic(VB)是一种面向对象的程序设计语言，与传统DOS 下的Basic 或Quick Basic 最大的差别在于它运用了面向对象的概念。

V B 建立了一个事件驱动的环境，供用户直接调用。

程序设计人员只要专心数据的运算处理，其余诸如W i n d o w s 应用程序下所见的滚动条、按钮、下拉式菜单和对话框等，都已经有对象供用户进行调用，而且每个对象又都有许多事件、属性和方法，供用户填入适当值或程序码，从而形成一个应用程序。

5 结构化程序设计方法与面向对象的程序...

软件测试V模型、W模型的特点

V模型只是将瀑布模型中的测试部分做了细化，其最大特点（可能也是最大的缺点）就是“线性执行”，测试的工作在编码完成后才开始进行，显然不符合软件测试的“3早”原则.而双V模型，也就是W模型，并不是在V模型上又搞出一个来，而是开发阶段与测试设计阶段同步进行，比如在进行需求分析，SRS评审，SRS基线化后，系统测试计划，方案，用例也设计完毕，接着是概要设计与集成测试设计，详细设计与单元测试设计，直到编码完成后，进行代码审查，继续执行UT,IT,ST...

软件工程中的cmm是什么,有哪五个层次

CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。

它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。

CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。

CMM是是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。

CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。

CMM是由美国卡内基梅隆大学软件工程研究所1987年研制成功的，是目前国际上最流行最实用的软件生产过程标准和软件企业成熟度等级认证标准。

目前，我国已有软件企业通过了CMM标准认证 。

SW-CMM(Capability Maturity Model For Software 软件生产能力成熟度模型，以下简称＂CMM＂)，是87年由美国卡内基梅隆大学软件工程研究所（CMU SEI）研究出的一种一种用于评价软件承包商能力并帮助改善软件质量的方法，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。

其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件生产中的困难。

CMM它是目前国际上最流行、最实用的一种软件生产过程标准，已经得到了众多国家以及国际软件产业界的认可，成为当今企业从事规模软件生产不可缺少的一项内容。

CMM目前通用流行的版本是1.1(Version1.1)。

《按照软件工程研究所（SEI）的原来计划，CMM的改进版版本2.0(V2.0)是要在1997年的11月完成的。

但是，美国国防部办公室要求软件工程研究所（SEI）延迟发放公布CMM版本2.0，直至他们完成另一个更为紧迫的项目-CMMI。

CMMI(Capability Maturity Model Integration能力成熟度模型集成)，是美国国防部的一个设想。

他们希望把所有现存的与将被发展出来的各种能力成熟度模型，集成到一个框架中去。

这个框架用于解决两个问题：第一，软件获取办法的改革；第二，从集成产品与过程发展的角度出发，建立一种包含健全的系统开发原则的过程改进。

CMM为软件企业的过程能力提供了一个阶梯式的改进框架，它基于过去所有软件工程过程改进的成果，吸取了以往软件工程的经验教训，提供了一个基于过程改进的框架；它指明了一个软件组织在软件开发方面需要管理哪些主要工作、这些工作之间的关系、以及以怎样的先后次序，一步一步的做好这些工作而使软件组织走向成熟。

一、CMM的诞生 信息时代，软件质量的重要性越来越为人们所认识。

软件是产品、是装备、是工具，其质量使得顾客满意，是产品市场开拓、事业得以发展的关键。

而软件工程领域在1992年至1997年取得了前所未有的进展，其成果超过软件工程领域过去15年来的成就总和。

软件管理工程引起广泛注意源于20世纪70年代中期。

当时美国国防部曾立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善而引起，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。

到了20世纪90年代中期，软件管理工程不善的问题仍然存在，大约只有10%的项目能够在预定的费用和进度下交付。

软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件开发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常注意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制；软件升级暴露了硬件的缺点；关心创新而不关心费用和风险；军用标准太少且不够完善等等。

在关系到软件项目成功与否的众多因素中，软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因素。

由此可见，软件管理工程的意义至关重要。

软件管理工程和其它工程管理相比有其特殊性。

首先，软件是知识产品，进度和质量都难以度量，生产效率也难以保证。

其次，软件系统复杂程度也是超乎想象的。

因为软件复杂和难以度量，软件管理工程的发展还很不成熟。

软件管理工程的发展，在经历了从70年代开始以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征的结构化生产时代，到90年代中期，以CMM模型的成熟模型和日益为市场接受为标志，已经进入以过程成熟模型CMM、个体软件过程PSP和群组软件过程TSP为标志的以过程为中心的时代，而软件发展第三个时代，及软件工业化生产时代，从90年代中期软件过程技术的成熟和面向对象技术、构件技术的发展为基础，已经渐露端倪，估计到2005年，可以实现真正的软件工业化生产，这个趋势应该引起软件企业界和有关部门的高度重视，及早采取措施，跟上世界软件发展的脚步。

软件生产转向以改善软件过程为中心，是世界各国软件产业或迟或早都要走的道路。

软件过程改善是当前软件管...

什么是瀑布模型？

软件开发模型（Software Development Model）是指软件开发全部过程、活动和任务的结构框架。

软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。

软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。

最早出现的软件开发模型是1970年W·Royce提出的瀑布模型。

该模型给出了固定的顺序，将生存期活动从上一个阶段向下一个阶段逐级过渡，如同流水下泻，最终得到所开发的软件产品，投入使用。

但计算拓广到统计分析、商业事务等领域时，大多数程序采用高级语言（如FORTRAN、COBOL等）编写。

瀑布模式模型也存在着缺乏灵活性、无法通过并发活动澄清本来不够确切的需求等缺点。

典型的开发模型有：①瀑布模型（waterfall model）；②渐增模型/演化/迭代（inCRemental model）；③原型模型（prototype model）；④螺旋模型（SPIral model）；⑤喷泉模型（fountAIn model）；⑥智能模型（intelligent model） ; 7. 混合模型（hybrid model）1. 边做边改模型（Build-and-Fix Model） 遗憾的是，许多产品都是使用＂边做边改＂模型来开发的。

在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改.在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。

在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。

这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于： （1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改； （2） 忽略需求环节，给软件开发带来很大的风险； （3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

2. 瀑布模型（Waterfall Model）1970年WinSTon Royce提出了著名的＂瀑布模型＂，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。

当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。

但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： （1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； （2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险； （3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

我们应该认识到，＂线性＂是人们最容易掌握并能熟练应用的思想方法。

当人们碰到一个复杂的＂非线性＂问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。

一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。

线性是一种简洁，简洁就是美。

当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。

例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子。

3. 快速原型模型（RAPId Prototype Model） 快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。

通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。

快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。

因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

4. 增量模型（Incremental Model） 与建造大厦相同，软件也是一步一步建造起来的。

在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。

整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。

但是，增量模型也存在以下缺陷： （1） 由于各个构件是逐渐并入已有的软件体系结构...