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

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

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

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

结构化分析实质上是一种创建模型的活动。

通过需求分析而建立的模型必须达到下述的三个基本目标。

·描述用户的需求。

·为软件设计工作奠定基础。

·定义一组需求，一旦开发出软件产品之后，就可以用这组需求为标准来验收该产品。

为了达到上述这些目标，在结构化分析过程中导出的分析模型的形式，如图3.1所示。

分析模型的核心是“数据字典”，它描述软件使用或产生的所有数据对象。

围绕着这个核心有三种不同的图：“实体一关系图”描绘数据对象之间的关系，它是用来进行数据建模活动的图形，图中出现的每个数据对象的属性可以在“数据对象描述”中描述。

创建“数据流图”有两个目的：①指出当数据在软件系统中移动时怎样被变换；②描绘变换数据流的功能和子功能。

数据流图是功能建模的基础。

在“处理规格说明”中给出了对出现在数据流图中的每个功能的描述。

“状态转换图”指明了作为外部事件结果的系统行为。

为此，状态转换图描绘了系统的各种行为模式（称为“状态”）和在不同状态间转换的方式。

状态转换图是行为建模的基础。

在“控制规格说明”中包含了有关软件控制的附加信息。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如图所示。

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

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

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

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

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

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

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

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

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

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

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

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

软件工程与能力成熟度模型CMM是怎样的？

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

当时美国国防部曾立题专门研究软件项目做不好的原因，发现70%的失败项目是因为管理不善而引起的，而不是因为技术实力不够。

他们进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。

这个结论非常重要。

软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件开发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常注意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制等等。

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

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

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

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

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

例如，宇宙飞船的软件系统源程序代码多达2000万行，如果按过去的生产效率一个人一年只能写1万行代码的话，将需要2000人年的工作量，这是非常惊人的。

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

CMM，逐步的成熟 美国Canegie Mellon大学软件工程研究所（CMUSEI）主持研究与开发的CMMPSPTSP技术，为软件工程管理开辟了一条新的途经。

CMM是英文“Capaility Matuity Model”的简称，意为能力成熟度模型。

CMM的本质是软件管理工程的一个部分。

根据软件生产的历史与现状，CMM框架可用5个不断进化的层次来表达：其中初始层是混沌的过程，可重复层是经过训练的软件过程，定义层是标准一致的软件过程，管理层是可预测的软件过程，优化层是能持续改善的软件过程。

任何单位所实施的软件过程，都可能在某一方面比较成熟，在另一方面不够成熟，但总体上必然属于这5个层次中的某一个层次。

在某个层次内部，也有成熟程度的区别。

在一个较低层次的上沿，很可能与一个较高层次的下沿非常接近，此时由这个较低层次向该较高层次进化也就比较容易。

反之，在一个较低层次的下沿向较高层次进化，就比较困难。

在CMM框架的不同层次中，需要解决带有不同层次特征的软件过程问题。

因此，一个软件开发单位首先需要了解自己处于哪一个层次，然后才能够对症下药地针对该层次的特殊要求解决相关问题，这样才能收到事半功倍的软件过程改善效果。

任何软件开发单位在致力于软件过程改善时，只能由所处的层次向紧邻的上一层次进化，即软件过程的进化是渐进的，而不能是跳跃的。

而且在由某一成熟层次向上一更成熟层次进化时，在原有层次中的那些已经具备的能力还应该得到保持与发扬。

CMM家族包括CMM集成产品集、SACMM（软件获取能力成熟度模型）、SECMM（系统工程能力成熟度模型）和IDEAL模型。

其中CMM集成产品集为工业界和政府部门提供了一系列集成产品，以支持软件过程和产品的改善；SACMM用于单位获取和采购基于软件的应用系统的软件过程，美国国防部、陆军、海军和一些商用单位都已采用SACMM对他们的获取能力进行评估；SECMM是描述一个单位为保证实现一个好的系统工程的主要元素；而IDEAL模型则是一个单位用于启动、规划和实现过程改善措施蓝图的模型，概括了建立一个成功的过程改善项目的必要步骤，其中I代表Initiating（启动）、D代表Diagnosing（诊断）、E代表Estalishing（建造）、A代表Acting（措施）、L代表Leaning（学习）。

美国曾在1995年做过软件产业成熟程度的调查，发现在美国的软件产业中，CMM成熟度等级为初始级的竟占70%，其特征是软件开发过程不能预测，风险度高；为可重复级的占15%，其特征是软件开发过程需小心谨慎方能避免失败；为定义级的所占比例小于10%，其特征是软件开发过程相当稳定，进展顺利且可以预测；为管理级的所占比例小于5%，其特征是软件过程预测准确、值得信赖；为优化级的所占比例小于1%，其特征是软件过程能持续改善。

CMM还需绿叶配 需要注意的是，并不是实施了CMM，软件项目的质量就能有所保障。

CMM不是万能的，它的成功与否，与一个组织内部有关人员的积极参与和创造性活动是密不可分的，而且CMM并未提供实现有关子过程域所需要的具体知识和技能。

因此，个体软件过程PSP(Pesonal Softwae Pocess)也就应运而生。

PSP为基于个体和小型群组软件过程的优化提供了具体而有效的途径，例如如何制订计划，如何控制质量，如何与其他人相互协作等等。

在软件设计阶段，PSP的着眼点在于软件缺陷的预防，其具体办法是强化设计结束准则，而不是设计方法的选择。

根据对参加培训的104位软件人员的统计数据表明，在应用了PSP后，软件中总的缺陷减少了58.0%，在测试阶段发现的缺陷减少了71.9%，生产效率提高了20.8%.PSP的研究结果还表明，绝大多数软件缺陷是由于对问题的错误理解或简单的失误所造成的，只有很少一部分是由于技术问题而产生的。

而且根据多年来的软件工程统计数据表明，如果在设...

软件工程 原型模型

原型法适用于用户没有确定其需求的明确内容的时候。

他先是根据已给的和分析的需求，建立一个原始模型，这是一个可以修改的模型（在声明周期法中，需求分析一般不再多修改）。

在软件开发的各个阶段都把有关信息相互反馈，直至模型的修改，使模型趋于完善。

在各个过程中，用户的参与和决策加强了，最终的结果更适合用户的要求。

这种原型技术有分为三类：抛弃式、演化式和递增式。

原型法成败的关键及效率的高低关键在于模型的建立和建模的速度。

原型法的优点是：可以解决在产品开发早期需求不确定的问题（不确定性、二义性、不完整性、含糊性等），可以明确并完善需求、探索设计选择方案、发展为最终产品。

原型法的缺点也是显而易见的，需要在正式的代码开发之前进行必要的原型开发，在某种程度上增加了工作量，尤其采用抛弃型原型，更是如此。

正确的有 1 2 3 5 6 7 9 10

软件工程 用来描述系统的是什么模型

软件工程必须是真正意义上的工程化。

从软件开发三条线索（开发，其中涉及如何保证软件产品的质量和可靠性，也能应用于其他的很多领域，这门课结束了、可维护性问题涉及了软件生存周期的所有阶段。

6、软件生存周期：系统开发前期需求分析很重要、瀑布模型、演化模型、运行的整个开销满足用户要求的程度。

这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题、设计、编程和测试4个核心阶段和需求调研：了解了什么是“软件危机”，透过软件工程于解决“软件危机”的重要性、软件工程三条重要线索：程序设计阶段（1946-1956年）、软件开发阶段（1956-1968年），它是为了有效解决用户问题的需要进行的一项工程活动，所需要考虑的需求问题是功能需求、数据需求，通常把软件经历的这个漫长的时期称为生存周期，保证软件工程开发的成功完成，但这些方面学习我还将继续的：业务树图、用例图、活动图。

分别用于结构化需求建模、系统业务举例和反映系统工作流程。

③进行需求验证，要验证的主要内容有：有效性验证、一致性验证、完整性验证、现实性验证和可检验性验证。

3，需求规约可表达用户的软件价值。

②建立需求模型，它是用户需求的图解，一些常用的模型有、软件开发效率、软件的可靠性，软件开发流程的规范化在软件项目中有着重要的作用、计算机辅助软件工程阶段4、常见的软件过程模型：边改边做模型、MVC模型。

其步骤有三个：①获取客户需求，客户泛指某个人或机构部门等，一般方法是调查，包括访谈，我对软件项目开发的流程有了更深的理解，例如通过需求规格说明书、可行性研究说明书，如何提高软件开发效率和拥护满意度等，开发者承担分析任务。

可用性指软件基本结构、实现及文档为用户可用的程度。

开销合宜是指软件开发、性能需求和接口需求、visio的强大绘图建模功能、这些知识不仅能应用于软件工程；⑤详细设计、数据库设计说明书、需求分析说明书、总体设计说明书、详细设计说明书等六份作业的完成虽然很不完善，但仍让我对需求分析建模和设计中用到的方法有了更好的理解并熟悉了六份文档的格式1、软件工程是一门指导软件开发和维护的工程学科，主要研究软件开发和维护的工程技术和软件项目管理等内容，核心是用户。

软件的生存周期可分为八个阶段：①问题定义；②可行性研究、软件工程目标：生产具有正确性、可用性以及开销合宜的产品、软件工程知识体系函括内容及软件工程各类生存期模型，我对软件工程思想及“工程化”软件开发的流程有了较系统的了解，透过软件工程的起源，认识到：实现软件工业的产业化。

从需求分析到维护，透过软件的开发流程具体实施的学习。

。

。

学了这门课才知道软件开发中每一阶段都有文档的产生，其管理与应用也是一门大学问……此外，这门课程里讲授了很多我以前从未接触过的方法和软件如UML模型；软件项目管理的核心是项目规划和项目跟踪控制，它们形成了对过程、过程模型及工程方法选取的约束；⑥编码与单元测试；⑦综合测试；⑧软件维护。

7、需求分析、增量迭代模型、喷泉模型5、软件过程的研究，标志着人们为解决软件危机问题、管理、改进）来看，软件开发的过程必须规范化（各阶段都必须形成相应文档；编码必须依照通用可读性严格遵照编程规范……）；④总体（概要）设计。

。

感悟、运行与维护两个延伸阶段说明软件质量，把关注的焦点由编程转移到了软件开发的整个过程，包括分析、跟班和收集资料、软件生产历经4大阶段分别为、座谈、问卷；③需求分析，通过不断地优化和规范过程，企业可以提高软件生产能力、软件工程阶段（1968年以后）。

正确性指软件产品达到预期功能的程度。

2：一个软件从定义到开发、使用和维护，直到最终被弃用，要经历一个漫长的时期

信息工程与软件工程的区别

软件工程一直以来都缺乏一个统一的定义，很多学者、组织机构都分别给出了自己的定义： Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。

IEEE：软件工程是开发、运行、维护和修复软件的系统方法。

Fritz Bauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

软件工程（SoftWare Engineering）的框架可概括为：目标、过程和原则。

（1）软件工程目标：生产具有正确性、可用性以及开销合宜的产品。

正确性指软件产品达到预期功能的程度。

可用性指软件基本结构、实现及文档为用户可用的程度。

开销合宜是指软件开发、运行的整个开销满足用户要求的程度。

这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。

（2）软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。

软件工程过程主要包括开发过程、运作过程、维护过程。

它们覆盖了需求、设计、实现、确认以及维护等活动。

需求活动包括问题分析和需求分析。

问题分析获取需求定义，又称软件需求规约。

需求分析生成功能规约。

设计活动一般包括概要设计和详细设计。

概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。

详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。

实现活动把设计结果转换为可执行的程序代码。

确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。

维护活动包括使用过程中的扩充、修改与完善。

伴随以上过程，还有管理过程、支持过程、培训过程等。

（3）软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。

软件工程必须遵循什么原则 围绕工程设计、工程支持以及工程管理已提出了以下四条基本原则： （1）选取适宜的开发模型 该原则与系统设计有关。

在系统设计中，软件需求、硬件需求以及其它因素间是相互制约和影响的，经常需要权衡。

因此，必需认识需求定义的易变性，采用适当的开发模型，保证软件产品满足用户的要求。

（2）采用合适的设计方法 在软件设计中，通常需要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。

合适的设计方法有助于这些特征的实现，以达到软件工程的目标。

（3）提供高质量的工程支撑 工欲善其事，必先利其器。

在软件工程中，软件工具与环境对软件过程的支持颇为重要。

软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。

（4）重视软件工程的管理 软件工程的管理直接影响可用资源的有效利用，生产满足目标的软件产品以及提高软件组织的生产能力等问题。

因此，仅当软件过程予以有效管理时，才能实现有效的软件工程。

软件工程是指导计算机软件开发和维护的工程学科。

采用工程的概念、原理、 技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够 得到的最好的技术方法结合起来，这就是软件工程。

软件工程强调使用生存周期方法学和各种结构分析及结构设计技术。

它们是 在七十年代为了对付应用软件日益增长的复杂程度、漫长的开发周期以及用户对 软件产品经常不满意的状况而发展起来的。

人类解决复杂问题时普遍采用的一个策 略就是“各个击破”，也就是对问题进行分解然后再分别解决各个子问题的策略 。

软件工程采用的生存周期方法学就是从时间角度对软件开发和维护的复杂问题 进行分解，把软件生存的漫长周期依次划分为若干个阶段，每个阶段有相对独立 的任务，然后逐步完成每个阶段的任务。

采用软件工程方法论开发软件的时候， 从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发。

前一个阶段任务 的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是 使前一阶段提出的解法更进一步具体化，加进了更多的物理细节。

每一个阶段的开 始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就 是后一阶段的开始标准。

在每一个阶段结束之前都必须进行正式严格的技术审查 和管理复审，从技术和管理两方面对这个阶段的开发成果进行检查，通过之后这 个阶段才算结束；如果检查通不过，则必须进行必要的返工，并且返工后还要再 经过审查。

审查的一条主要标准就是每个阶段都应该交出“最新式的”（即和所 开发的软件完全一致的）高质量的文档资料，从而保证在软件开发工程结束时有 一个完整准确的软件配置交付使用。

文档是通信的工具，它们清楚准确地说明了 到这个时候为止，关于该项工程已经知道了什么，同时确立了下一步工作的基础 。

此外，文档也起备忘录的作用，如果文档不完整，那么一定是某些工作忘记做 了，在进入生存周期的下一阶段之前，必须补足这些遗漏的细节。

在完成生存周 期每个阶段的任务时，应该采用适合该阶段任务特点的系统化的技术方法——结 构分析或结构设计技术。

把软件生存周期划分成若干个...