软件工程导论—软件与软件工程的基本概念

1. 软件与软件危机

1.1. 软件的概念和特点

软件一词是在1960年代出现的，目前还没有公认的定义。但一般来说，通常意义上的软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。

其中，程序是按事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操纵信息的数据结构；文档是与程序开发，维护和使用有关的图文材料。

与之相似的是，在1983年IEEE组织对软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。

比软件定义更重要的是，必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。

软件的特点：

1. 软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性；
2. 软件的生产与硬件不同，它没有明显的制造过程；
3. 在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。但就目前的软件工程环境应用而言，在不更新升级的情况下软件的平均寿命大约为5年；
4. 软件的开发和运行常常受到计算机系统的限制，对计算机系统有着不同程度的依赖性；
5. 软件的开发至今尚未完全摆脱手工艺的开发方式；
6. 软件本身是复杂的，软件成本相当昂贵
7. 相当多的软件工作涉及到社会因素。

1.2. 软件规模的分类与发展阶段

软件的分类并没有一个绝对的标准，但一般情况下都会用软件规模来对软件进行分类，如下表：

类别	参加人员数	研制期限	产品规模(源程序行数)
微型	1	1~4周	0.5K
小型	1	1~6月	1K~2K
中型	2~5	1~ 2年	5K~50K
大型	5~20	2~3年	50K~ 100K
甚大型	100~1000	4~5年	1M
极大型	2000~5000	5~10年	1M~10M

软件发展的三个时期及其特点

特点\时期	程序设计	程序系统	软件工程
软件所指	程序	程序及说明书	程序、文档、数据
主要程序设计语言	汇编及机器语言	高级语言	软件语言
软件工作范围	程序编写	设计、编码和测试	软件周期
软件使用者	程序设计者本人	少数用户	市场用户
软件开发组织	个人	开发小组	开发小组及大中型软件开发机构
软件规模	小型	中小型	大中小型
决定质量的因素	个人编程技术	小组技术水平	技术水平及管理水平
开发技术和手段	子程序和程序库	结构化程序设计	数据库，开发工具，开发环境， 工程化开发方法，标准和规范， 网络及分布式开发面向对象技术及软件复用
维护责任者	程序设计者	开发小组	专职维护人员
硬件特征	价格高、存储容量小、工作可靠性差	速度、容量及工作可靠性有明显提高	向超高速，大容量，微型化及网络化方向发展
软件特征	完全不受重视	软件技术的发展不能清足需要，出现软件危机	开发技术有进步，但未获突破性进展，价格高未完全摆脱软件危机

1.3. 软件危机

1968年在西德Garmish召开的国际软件工程会议上正式提出软件危机的概念：计算机软件的开发和维护过程所遇到的一系列严重问题。

1.3.1. 软件危机的表现

软件危机一般表现在以下五个大方面：

1. 对软件开发成本和进度的估算很不准确。 实际成本比估计成本有可能高出一个数量级，实际进度比预期进度拖延几个月甚至几年的现象并不罕见。软件开发人员常常在对用户要求只有模糊的了解，甚至对所要解决的问题还没有确切认识的情况下，就匆忙着手编写程序；另外软件成本在计算机系统总成本中所占的比例逐年上升。由于微电子学技术的进步和生产自动化程度不断提高，硬件成本逐年下降，然而软件开发需要大量人力，软件成本随着通货膨胀以及软件规模和数量的不断扩大而持续土升。美国在1985年软件成本大约已占计算机系统总成本的90%。
2. 难以准确获取用户需求，用户不满意； 通常情况下用户也不知道自己想要什么，导致开发时常常出现产品与预期不匹配的现象，实际上当前的软件技术已经十分发达，搞明白了需求基本上都能通过技术实现，如下图是软件技术与需求之前的增长关系：
   
3. 质量很不可靠，没有适当的文档。 软件可靠性和质量保证的确切的定量概念刚刚出现不久，软件质量保证技术(审查、复审和测试)还没有坚持不懈地应用到软件开发的全过程中，这些都导致软件产品发生质量问题;计算机软件不仅仅是程序，还应该有三整套文档资料。这些文档资料应该是在软件开发过程中产生出来的，而且应该是"最新式的"(即和程序代码完全一致的)。软件开发组织的管理人员可以使用这些文档资料作为“里程碑”，来管理和评价软件开发工程的进展状况:软件开发人员可以利用它们作为通信工具，在软件开发过程中准确地交流信息;对于软件维护人员而言，这些文档:资料更是必不可少的。
4. 缺乏方法指导和工具支持，导致大型软件系统经常失败。 很多程序中的错误是非常难改正的，实际上不可能使这些程序适应新的硬件环境，也不能根据用户的需要在原有程序中增加一些新的功能。"可重用的软件"还是一个没有完全做到的、正在努力追求的目标，人们仍然在重复开发类似的或基本类似的软件
5. 供不应求，软件开发生产率跟不上计算机应用的迅速发展。 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。软件产品"供不应求"的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。

1.3.2. 软件危机产生的原因

客观原因：软件本身特点，例如逻辑部件复杂、规模庞大等等。

在软件开发和维护的过程中存在这么多严重问题，一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件，在运行过程中不会因为使用时间过长而被"用坏"，如果运行中发现了错误很可能是遇到了一个在开发时期引入的，在测试阶段没能检测出来的错误。

软件不同于一般程序，它的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。

主观原因：程序员不正确的开发方法，忽视需求分析，并且错误地认为软件开发等于程序编写，轻视软件维护。

主观上的错误认识和作法主要表现为忽视软件需求分析的重要性，认为软件开发就是写程序并设法使之运行，轻视软件维护等。目前相当多的软件专业人员对软件开发和维护还有不少其他的糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这可能是使软件问题发展成软件危机的主要原因。

对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。另一方面还必须认识到程序只是完整的软件产品的一个组成部分，一个软件产品必须由一个完整的配置组成，主要包括程序、文档和数据等成分，他们缺一不可。

软件问题要尽早解决
作好软件定义时期的工作，是降低软件，成本提高软件质量的关键。在实际的软件开发中，在软件开发的不同阶段进行修改需要付出的代价是很不相同的，大约如下图所示，它表示了错误发现的越晚，付出的代价越高。

因此可以说，轻视维护是一个巨大的错误。统计数据表明，实际上用于软件维护的费用占软件总费用的55%~70%。软件工程学的一个重要目标就是提高软件的可维护性，减少软件维护的代价。

1.3.3. 软件危机如何解决

实际上就目前的手段而言，软件工程只能解决主观上造成软件危机的原因，对于软件本身特点，例如逻辑部件复杂、规模庞大等客观原因，软件工程是无能为力的。

主观危机的解决途径主要有两条：1、组织管理。2、技术措施

在组织管理可以采用工程项目管理方法；

在技术措施上提升软件开发技术与方法，灵活运用软件工具。应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。并且应该开发和使用更好的软件工具，在软件开发的每个阶段都有许多繁琐重复的工作需要做，在适当的软件工具辅助下，开发人员可以把这类工作做得既快又好。

为了消除软件危机，首先应该对计算机软件有一个正确的认识，首当其冲的就是彻底消除"软件就是程序"的错误 观念，要明确一个软件必须由一个完整的配置组成，是程序、数据及相关文档的完整集合。

2. 软件工程学

2.1. 软件工程学的概念

软件工程学是在1968年，北约计算机科学会议上由Fritz Bauer提出的，他给出的软件工程学的定义为：用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术及管理方法。其中包含了三个要素：方法、工具、过程。

因此可以说，软件工程学是一门指导计算机软件开发和维护的工程学科，它包含了开发技术和工程管理两方面。
软件开发技术

1. 软件开发方法学
2. 软件工具
3. 软件工程环境

软件工程管理

1. 软件管理学
2. 软件经济学
3. 软件度量学

2.2. 软件工程项目的基本目标

组织实施软件工程项目，从技术上和管理上采取了多项措施以后，最终希望得到项目的成功。所谓成功指的是达到以下几个主要的目标：

1. 付出较低的开发成本；
2. 达到要求的软件功能；
3. 取得较好的软件性能；
4. 开发的软件易于移植；
5. 需要较低的维护费用；
6. 能按时完成开发工作，及时交付使用。

但是软件工程的各个目标是不可能全部满足的，下图表示了软件工程目标之间的关系，可见，软件工程的最终目标只能是实现一个均衡的系统。

2.3. 软件工程的八项原则

1. 抽象
   抽取事物最基本的特性和行为，忽略非基本的细节。采用分层次抽象，自顶向下、逐层分解的办法控制软件开发过程的复杂性。例如，软件瀑布模型、结构化分析方法、结构化设计方法，以及面向对象建模技术等都体现了抽象的原则。
2. 封装(信息隐蔽)
   将模块设计成“黑箱”，实现的细节隐藏在模块内部，不让模块的使用者直接访问。这就是信息封装，使用与实现分离的原则。使用者只能通过模块接口访问模块中封装的数据。
3. 模块化
   模块是程序中逻辑上相对独立的成分，是独立的编程单位，应有良好的接口定义。如C语言程序中的函数过程，C++语言程序中的类。模块化有助于信息隐蔽和抽象，有助于表示复杂的系统。
4. 局部化
   要求在一个物理模块内集中逻辑上相互关联的计算机资源，保证模块之间具有松散的耦合，模块内部具有较强的内聚。这有助于加强模块的独立性，控制解的复杂性。
5. 确定性
   软件开发过程中所有概念的表达应是确定的、无歧义性的、规范的。这有助于人们之间在交流时不会产生误解、
   遗漏，保证整个开发工作协调致。
6. 一致性
   整个软件系统(包括程序、文档和数据)的各个模块应使用一致的概念、符号和术语。程序内部接口应保持一致。软件和硬件、操作系统的接口应保持一致。系统规格说明与系统行为应保持一致。用于形式化规格说明的公理系统应保持一致。
7. 完备性
   软件系统不丢失任何重要成分，可以完全实现系统所要求功能的程度。为了保证系统的完备性，在软件开发和运行过程中需要严格的技术评审。
8. 可验证性
   开发大型的软件系统需要对系统自顶向下逐层分解。系统分解应遵循系统易于检查、测试、评审的原则，以确保系统的正确性。

2.4. 软件工程的本质特征

软件工程关注于大型程序的构造
"大"与"小"的分界线并不十分清晰。通常把一个人在较短时间内写出的程序称为小型程序，而把多人合作用时半年以上才写出的程序称为大型程序。

软件工程的中心课题是控制复杂性
软件所解决的问题十分复杂，通常不得不把问题分解，使得分解出的每个部分是可理解的，而且各部分之间保持简单的通信关系。用这种方法并不能降低问题的整体复杂性，但是却可使它变成可以管理的。

软件经常变化
绝大多数软件都模拟了现实世界的某一部分。现实世界在不断变化，软件为了不被很快淘汰，必须随着所模拟的现实世界一起变化。因此，在软件系统交付使用后仍然需要耗费成本，而且在开发过程中必须考虑软件将来可能的变化。

开发软件的效率非常重要
目前，社会对新应用系统的需求超过了人力资源所能提供的限度，软件供不应求的现象日益严重。因此，软件工程的一个重要课题就是，寻求开发与维护软件的更好更有效的方法和工具。

和谐地合作是开发软件的关键
软件处理的问题十分庞大，必须多人协同工作才能解决这类问题。为了有效地合作，必须明确地规定每个人的责任和相互通信的方法。纪律是成功地完成软件开发项目的一个关键。

软件必须有效地支持它的用户
开发软件的目的是支持用户的工作。软件提供的功能应该能有效地协助用户完成他们的工作。

有效地支持用户意味着必须仔细地研究用户，以确定适当的功能需求、可用性要求及其他质量要求(例如，可靠
性、响应时间等)。有效地支持用户还意味着，软件开发不仅应该提交软件产品，而且应该写出用户手册和培训材料。

在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人
软件工程师是诸如Java程序设计、软件体系结构、测试或统一建模语言(UML)等方面的专家，他们通常并不是图书馆管理、航空控制或银行事务等领域的专家，但是他们却不得不为这些领域开发应用系统。缺乏应用领域的相关知识，是软件开发项目出现问题的常见原因。

有时候，软件开发者通过访谈、阅读书面文件等方法了解到用户组织的“正式”工作流程，然后用软件实现这个工作流程。但是，决定软件系统成功与否的关键问题是，用户组织是否真正遵守这个工作流程

2.5. 软件工程的七条基本原理

著名的软件工程专家B.W.Boehm综合学者们的意见，于1983年在一篇论文中提出了软件工程的七条基本原理。这七条原理是确保软件产品质量和开发效率的原理的最小集合。

这七条原理是互相独立的，其中任意6条原理的组合都不能代替另一条原理。同时这七条原理又是相当完备的，虽然不能用数学方法严格证明它们是一个完备的集合，但是可以证明在此之前已经提出的一百多条软件工程原理都可以由这七条原理的任意组合蕴含或派生。

七条基本原理：

1. 用分阶段的生命周期计划严格管理
   经统计发现，在不成功的软件项目中有一半左右是由于计划不周造成的。因此应该把软件生命周期划分成若千个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受客户或上级人员的影响而擅自背离预定计划；一般来说软件的生命周期分为定义阶段、可行性研究阶段、需求分析阶段、程序设计阶段、编码阶段、测试阶段、运行维护阶段。
2. 坚持进行阶段评审
   软件的质量保证工作不能等到编码阶段结束之后再进行，这样说至少有两个理由：
   第一，大部分错误是在编码之前造成的，根据统计，设计错误占软件错误的63%，编码错误仅占37%；
   第二，错误发现与改正得越晚，所需付出的代价也越高；
   因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误，是一条必须遵循的重要原则。
3. 实行严格的产品控制
   在软件开发过程中改变需求是难免的，只能依靠科学的产品控制技术来顺应这种要求。也就是说，当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。
   所谓基准配置又称为基线配置，它们是经过阶段评审后的软件配置成分。基准配置管理也称为变动控制，指的是一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。绝对不能谁想修改软件，就随意进行修改。
4. 采用现代程序设计技术
   从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术，并进一步研究各种先进的软件开发与维护技术。实践表明，采用先进的技术不仅可以提高软件开发和维护的效率，而且可以提高软件产品的质量。
5. 结果应能清楚地审查
   软件产品不同于一般的物理产品，它是看不见摸不着的逻辑产品。软件开发人员的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难于评价和管理。为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限来规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。
6. 开发小组的人员应该少而精
   软件开发小组的组成人员的素质应该好，而人数则不宜过多。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件中的错误。
   此外，随着开发小组人员数目的增加，因为交流情况讨论问题而造成的通信开销也急剧增加。当开发小组人员数为N时，可能的通信路径有N(N-1)/2条，可见随着大数N的增大，通信开销将急剧增加。
7. 承认不断改进软件工程实践的必要性
   遵循上述六条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产，但是，仅有上述6条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐。因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第7条基本原理。按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。

3. 软件工程方法学

3.1. 软件工程方法学的概念

软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。通常把在软件生命周期全过程中使用的整套技术方法的集合称为方法学(Methodology)，也称为范型(Paradigm)。

软件工程方法学包含3个要素:

1. 方法，是完成软件开发的各项任务的技术方法，回答"怎样做"的问题；
2. 工具，是为运用方法而提供的自动的或半自动的软件工程支撑环境；
3. 过程，是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

3.2. 传统软件工程与面向对象软件工程

3.2.1. 传统软件工程与面向对象软件工程的对比

目前使用得最广泛的软件工程方法学有传统方法学（面向数据流/结构化方法学） 和 面向对象方法学。他们分别代表了两种程序设计方法：即结构化程序设计(程序=数据结构+算法) 和 面向对象程序设计(程序=对象+请求消息)

两种方法学的软件开发流程如下所示：
传统软件工程：软件分析→总体设计→详细设计→面向过程的编码→测试。会有一个清楚的流程体系。
面向对象软件工程：软件分析与对象抽取→对象详细设计→面向对象的编码→测试。

3.2.2. 传统软件工程的生命周期的三个阶段

1. 计划时期。问题定义、可行性分析
   问题定义阶段必须回答的关键问题是"要解决的问题是什么?"如果不知道问题是什么就试图解决这个问题，显然是盲目的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。通过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告，经过讨论和必要的修改之后这份报告应该得到客户的确认。
   可行性研究阶段要回答的关键问题是"对于上一个阶段所确定的问题有行得通的解决办法吗?"系统分析员需要进行一次大大压缩和简化了的系统分析和设计过程，也就是在较抽象的高层次上进行的分析和设计过程。可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。可行性研究的结果是使用部门负责人作出是否继续进行这项工程的决定的重要依据。可行性研究以后的那些阶段将需要投入更多的人力物力。及时终止不值得投资的工程项目，可以避免更大的浪费。
2. 开发时期。需求分析、软件设计(总体设计、详细设计)、编码、测试(调试和综合测试)
   需求分析阶段的任务仍然不是具体解决问题，而是确定"为了解决这个问题，目标系统必须做什么?"，主要是确定目标系统必须具备哪些功能。系统分析员必须和用户密切配合，充分交流信息以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法表示在需求分析阶段确定的系统逻辑模型是以后设计和实现系统的基础。这个阶段的一项重要任务，是用正式文档准确地记录对目标系统的需求，这份文档通常称为规格说明书(specification)。
   总体设计阶段必须回答的关键问题是"概括地说，应该怎样实现目标系统?"总体设计又称为概要设计。首先，应该设计出实现目标系统的几种可能的方案。通常至少应该设计出低成本、中等成本和高成本等3种方案。软件工程师在充分权衡各种方案的利弊的基础上，推荐一个最佳方案。制定出实现最佳方案的详细计划。一个程序应该由若干个规模适中的模块按合理的层次结构组织而成。总体设计的另一项主要任务就是设计程序的体系结构，也就是确定程序由哪些模块组成以及模块间的关系。
   详细设计阶段的任务就是把解法具体化，也就是回答这个关键问题"应该怎样具体地实现这个系统呢?"这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明应该包含必要的细节，程序员可以根据它们写出实际的程序代码详细设计也称为模块设计，在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。
   编码和调试阶段的关键任务是写出正确的、容易理解、容易维护的程序模块。程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言(必要时用汇编语言)，把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试(调试)编写出的每一个模块。
   综合测试阶段的关键任务是通过各种类型的测试(及相立的调试)使软件达到预定的要求。最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试；所谓验收测试则是按照规格说明书的规定，由用户对目标系统进行验收。必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。
3. 运行时期。软件维护
   软件维护阶段的关键任务是"通过各种必要的维护活动使系统持久地满足用户的需要"。通常有四类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。每一项维护活动都实质上是经历了一次压缩和简化了的软件定义和开发的全过程。

4. 软件开发模型

软件开发模型实际上是软件工程三要素中"过程"要素的展开，下面介绍几种经典的软件开发模型

4.1. 传统开发模型

4.1.1. 瀑布模型(waterfall model)

瀑布模型一直是唯一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的文档驱动的过程模型。如下图所示为传统的瀑布模型

瀑布模型区别与其他模型最大的特点有三个：

1. 阶段间具有顺序性和依赖性
   (1)必须等前一阶段的工作完成之后，才能开始后一阶段的工作；
   (2)前一阶段的输出文档就是后一阶段的输入文档。因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
2. 推迟实现
   对于规模较大的软件项目来说，往往实现(编码和测试)开始得越早最终完成开发工作所需要的时间反而越长。这是因为，前面阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往带来灾难性后果瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，清楚地区分逻辑设计与物!理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想
3. 质量保证
   软件工程的基本目标是优质、高产。为了保证所开发的软件的质量，在瀑布模型的每个阶段都应坚持两个重要做法:
   (1)每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务；
   (2)每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

传统的瀑布模型过于理想化了，事实.上，人在工作过程中不可能不犯错误。实际的瀑布模型是带"反馈环"的，如下图所示。

实际的瀑布模型当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。

4.1.2. 快速原型模型(rapid prototype model)

快速原型模型是低成本的，进行循环需求分析的一个快速开发模型。它的基本结构如图所示。

原型是值快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集，然后在用户的不断使用中探明用户需求，不断对原型进行改进，最终完成需求分析。

因此它的两个最大的优点就是：

1. 原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
2. 开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。

4.2. 演化开发模型

4.2.1. 增量模型(incremental model)

增量模型也称为渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和
测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。开发流程如下图所示

下图是每一个增量构建的实现过程图：

增量模型能在较短时间内向用户提交可完成部分工作的产品。逐步增加产品功能可以使用户有较充裕的时间学
习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。

但是它也是有缺陷的，增量模型面临的最大困难就是必须保证在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。

4.2.2. 螺旋模型(spiral model)

螺旋模型的基本思想是，使用原型及其他方法来尽量隆低风险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。从本质上来讲，螺旋模型就是一个加入了风险分析的快速原型模型。

螺旋模型的主要优势在于，它是风险驱动的。它的开发过程如图所示：

一个螺旋式周期包括下面4个完整步骤：

1. 确定目标，选择方案，选定完成目标的策略
2. 从风险角度分析该策略
3. 启动一个开发阶段
4. 评价前一步的结果，并计划下一轮的工作

4.3. 面向对象开发模型

4.3.1. 构件集成模型(component integration model)

构建集成模型是一个典型的面向对象开发模型，它的一个典例就是各种开发IDE，例如Visual Studio，可以查找加载各种构建。

构建集成模型有着以下五个特点：面向对象、基于构件库、融合螺旋模型特征、支持软件开发的迭代方法、软件重用