软件工程的基本目标就是在给定的资源约束条件下开发生产更多更好的软件产品，具体表现如下：

1、开发尽可能多的软件产品，满足社会对软件全方位、不同应用领域的应用需求，是软件工程的首要目标。

2、提高软件的生产效率。由于软件产品的特殊性使得如何提高软件产品的生产效率成了迫切需要解决的难题。为此，人们从各个方面研究、探讨软件产品生产的内在规律，包括生产过程的管理、组织形式、开发工具、程序设计方法等，试图找出比较满意的求解方案。

3、满足应用的功能需要。这里包括几层意思：产品功能强、性能好、按期交付使用、易于用户操作和维护。

4、降低软件开发成本，包括降低软件设计成本和软件维护成本，而软件维护成本比开发成本要大得多。因此，提高软件可维护性是降低软件开发成本的有效途径。

在具体工程项目的实际开发过程中，试图让以上几个目标都达到理想的程度往往是非常困难的。例如，如果过于追求提高软件的性能，可能造成开发出的软件对硬件有较大的依赖性，从而直接影响到软件的通用性和可移植性。实际上软件工程就是要解决如何在用户要求的功能、质量、成本、进度之间取得平衡，满足应用的实际需要。

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

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

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

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

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

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

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

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

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

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

的代价将是非常昂贵的。

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

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

软件工程模型原型模型

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

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

这种模型的优点是：

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

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

这种模型的缺点是：

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

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

软件工程模型增量模型

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

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

软件工程模型螺旋模型

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

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

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

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

模型是用于表现更大、更复杂的物体、或体制、或概念的经过精确刻画的一种“直观反映”。模型通常是一个计划的初步产品或结构，依据此模型或从模型中可产生出最终的产品。各传统领域均用模型来表示实际产品、实际产品的生产加工过程及工艺标准等。例如，房产销售领域通常采用按实际比例缩小的房屋结构模型来展示他们的商品，这种模型主要从实际使用角度进行模拟，让用户能够直观地感受“使用”效果；而施工图纸也是模型，是从建造角度反映制造房屋建筑的结构、质量标准、技术和工艺标准的模型。

在软件工程领域中，我们也将采用模型来表示软件产品在各生产阶段中的进展情况和结果。例如，在软件分析阶段，可用模型来表示分析结果，在软件设计阶段用模型来反映设计方案，测试阶段有测试模型；软件实现人员根据分析、设计模型进行生产，测试人员根据测试模型进行软件测试。