软件过程工程元模型

《计算机科学技术名词 》第三版。 2100433B

由对象管理组织（OMG）制定的软件过程的元模型规范。

软件流程工程元模型（Software Process Engineering Metamodel，SPEM）是正式描述软件开发流程的的标准规范。作为 Object Management Group (OMG) 标准，SPEM 是独立于供应商、方法和框架的。1.1 版于 2005 年 1 月正式发布，而包含重大更新的 2.0 版目前正在制订中。2100433B

有限元分析软件目前最流行的有：ANSYS、ADINA、ABAQUS、MSC四个比较知名比较大的公司，其中ADINA、ABAQUS在非线性分析方面有较强的能力目前是业内最认可的两款有限元分析软件，ANSYS、MSC进入中国比较早所以在国内知名度高应用广泛。目前在多物理场耦合方面几大公司都可以做到结构、流体、热的耦合分析，但是除ADINA以外其它三个必须与别的软件搭配进行迭代分析，唯一能做到真正流固耦合的软件只有ADINA。

软件工程模型线性顺序模型

软件工程的“线性顺序模型”也称“传统生命周期模型”，或称“瀑布模型”，是一种最早的、应用最广的、支持直线型开发的过程模型。图1是关于软件开发阶段的线性顺序模型。

线性顺序模型从系统分析开始，逐步经过各个开发阶段到软件开发完毕、交付使用止。每个阶段的变换结果是下一个阶段的变换的输入，相邻的两个阶段具有极其密切的因果关系。该模型以软件的需求能够完全被确定为前提，这种模型的特点是“一泻千里”、易“下”而几乎不可能“上”，因此又得名“瀑布模型”。

这种模型在分析和设计阶段需要建立整个系统的视图，即在初期就建立所有系统组成部分的需求，因为软件必须与系统的其他组成部分——硬件、数据库、人或其他系统进行交互，然后把这些需求的相关部分分配给软件。

这种模型具有以下几个缺点：

1、在开发过程中的每个变化会引起不小的混乱。

2、不能接收在项目开始阶段中存在的不确定性，即在需求分析阶段必须明确软件系统的全部需

求，实际上这是较难做到的。

3、需求确定后，进行一连串的设计、实现、测试过程，才能制定出软件的初始版本，软件的运行

版本只能到项目开发晚期得到。如果在这时才发现错误，则错误的后果极有可能是灾难性的，纠正错误

的代价将是非常昂贵的。

4、有些开发者往往要等待其他人员完成任务后才能进行开发工作。

5、用户如果提出修改，则代价往往很大。

软件工程模型原型模型

原型是一种原始模型，是原始的类型、形式、形状或例证的描述，是作为后期阶段的基础模型。软件工程的“原型模型”的基本思想是从用户处收集到的需求出发，初步定义软件的总体目标，然后根据总体目标进行快速设计，建造一个能够反映用户主要需求并且能够运行的软件系统原型。通过运行原型，使得用户快速了解未来软件系统的概貌，便于快速判断需求的正确性、操作的实用性，以及功能是否遗漏、是否需要改进或增强等意见，然后再设计、修改原型，再运行原型、征求用户意见，如此重复直至双方认可。原型模型的整个构造过程是一个迭代的过程，图2描述了原型模型。

原型模型可以帮助用户和开发者较快速地获取双方理解一致的需求，但不是最终交付的软件产品。原型作为参考，实际的软件开发必须在充分考虑质量和可维护性等因素以后才进行。

这种模型的优点是：

1、用户能够很早就感觉到实际系统的“模式”，开发者可以很快地建造出一些供以后实际开发的“模型”；

2、如果理想的话，原型可以作为标识软件需求的一种机制。

这种模型的缺点是：

1、用户往往把看到的原型作为软件的最初“版本”，不理解或难以理解，原型实际上是没有考虑软件的总体质量、性能、可维护性等一系列保证软件质量的因素而快速“拼凑”起来的“演示软件”，以致误解软件开发的艰难性；

2、由于很早就得到用户“认可”，开发人员往往就放松对软件开发的管理，开发者也常常进行“折中”，把“演示”功能中的不合理部分处理成软件的实际功能。

软件工程模型增量模型

在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试。与构建大厦类似，先设计一个总体规划图，然后一层层地构造搭建整个建筑。增量模型是把整个软件系统分解为若干个软件构件，开发过程中，逐个实现每个构件，实现一个构件，展示一个构件。如果发现问题可以及早进行修正，逐步进行完善，最终获得满意的软件产品。

在使用增量模型时，第一个增量往往是实现基本需求的核心构件。该核心构件交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心构件的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。

软件工程模型螺旋模型

1988年，Barry Boehm发表了“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调其他模型所忽视的风险分析，特别适合于大型复杂的系统。该模型将开发分为4个环节（见图3）：制订计划、风险分析、开发实施和用户评估。开发活动围绕这4个环节螺旋式地重复执行，直到最终得到用户认可的产品。

软件工程模型形式化方法模型

形式化方法模型包含了一组导致计算机软件的数学规约的活动，使得软件工程师能够通过使用严格的、数学的符号体系来规约、开发和验证基于计算机的软件系统。用形式化方法开发软件时，提供一种通过数学分析来消除二义性、不完整性、不一致性问题的机制。这种方法能够作为程序验证的基础，能够发现和纠正在其他情况下发现不了的问题，可以生产高正确性的软件。因此，这种方法往往用于开发航空、医疗等安全性能要求很高的软件系统，但是在商业环境中不可能成为主流开发方法。

这种模型的软件开发的特点是开发费时且费用昂贵，对开发人员的要求很高，需要具有形式化方法所必要的知识背景。 2100433B