第一章 软件工程的基本概念....................................................................................... 1
1.1 计算机发展简史 .................................................................................................. 1
1.2 软件危机........................................................................................................... 2
1.软件 ................................................................................................................ 2
2. 什么是软件危机............................................................................................. 3
3. 产生软件危机的原因...................................................................................... 3
4. 解决软件危机的途径...................................................................................... 5
1.3 软件生存周期 .................................................................................................. 5
1.4 软件开发模型与方法 ......................................................................................... 6
1.瀑布开发模型 .................................................................................................. 6
2.原型模型(Prototyping Model) ............................................................................ 7
3.喷泉模型(Fountain Model) ................................................................................ 8
4.螺旋模型 ......................................................................................................... 9
第一章 软件工程的基本概念
在计算机系统发展的早期阶段, 由于人们认识上的局限性, 对计算机软件产生了一些片面的、错误的认识, 使计算机软件发展几经挫折, 走了不少弯路, 遭受到了"软件危机"的困扰。为了推进计算机软件开发技术的发展, 摆脱"软件危机"的困扰, 从60年代后期迅速发展起一门旨在研究软件开发与维护的普遍管理和技术的新兴学科---软件工程学, •简称软件工程。
1.1 计算机发展简史
按照计算机硬件的演变来划分计算机系统发展的时期, 可分为电子管、晶体管、集成电路和大规模集成电路四个时期。但为了了解计算机软件的发展演变的过程, 我们按照计算机应用领域的演变而不是仅仅根据硬件特点的演变来划分计算机系统的发展时期, 在工业发达的国家中计算机系统已经历了三个不同的发展时期。
1. •从世界上出现第一台计算机到六十年代中期是计算机系统发展的早期时代。在这个时期中, 人们将主要精力集中在研究和发展计算机硬件上, 经历了从电子管到晶体管计算机的变革。为了控制硬件的成本, 管理者建立了正式的控制和工艺标准,•以在开发产品之前进行细致的分析和设计。但是人们对计算机软件的研究和发展却不够重视, 认为软件开发是事后考虑的问题。那时的软件开发就是根据应用的需要写出能够运行的程序,因此, 基本上没有系统化的软件开发方法。由于硬件价格昂贵, 运算速度低, 内存容量少, 当时的程序员非常强调"程序设计技巧", 把缩短每一微秒CPU时间和节省每一个二进制存储单元作为程序设计•(当时的软件开发)的重要目标。
在计算机系统发展的早期时期, 大多数系统采用批处理方式工作。当时通用硬件相当普遍, 软件却是为了每个具体应用而专门设计的, 而且大多数软件的开发者和使用者是同一个(或一组)人。编写程序的人要设法使程序在机器上运行起来, 并且负责使用这个程序解决预定的问题, 发生什么错误也是由这个人设法修改, 这样的软件设计通常是人们头脑中进行的一个隐含过程, 而且除了程序清单外, 一般没有其他文档资料保存下来。
2. 从六十年代中期到七十年代中期是计算机系统发展的第二代。•在这个时期中, 硬件经历了从晶体管计算机到集成电路计算机的变革。•CPU速度和内存容量都有了很大的提高, 从而为计算机在众多领域中的应用提供了潜在的可能性。为了更有效地利用硬件的能力, 计算机系统普遍采用多道程序多用户的分时工作方式。计算机与通信结合, 开辟了计算机应用的一个新领域。当时最辉煌的成就之一就是美国航空公司SABRE•订票系统的实现和成功运行。这是第一个大型事务处理系统, 分散在遥远地点的用户可通过键盘终端与中央计算机系统进行通信。
在这个时期, 计算机应用开始普及和深化, 软件与硬件分离, 作为一种商品出现, 用户广泛使用产品软件(包括操作系统)。因为当时用户需要的软件往往是相当庞大的, 单个用户已无力开发, 另外, 许多不同部门和企业往往需要相同的或类似的软件, 各自开发就会浪费人力物力。因此用户大多是购买或定做软件。但是, 软件开发的方法基本没有什么变化。 随着计算机系统的不断增加, 计算机软件库开始膨胀。但在程序运行中发现错误时必须设法改正, 当用户的要求有改变进也必须修改程序, 当买进新硬件或操作系统新版本时时通常必须改变程序以适应新的环境。这些软件的维护工作, 以令人吃惊的比例耗费资源, 更严重的是, 许多程序的个体化特性使它们最终成为不可维护的(•如人员调动或时间长而记不清当时的设计思想等)。这就出现了"软件危机"。
3. 计算机系统发展的第三代从七十年代初期开始, •这时的硬件已从集成电路计算机发展到超大规模集成电路计算机, 高性能低成本的微处理器大量涌现, 发展日新月异。
计算机应用的进一步普及和深化, 开辟了更多新的应用领域。如分布式系统使用多台计算机共同解决一个问题, 各台计算机并行工作分别完成各自的子任务, 同时各台间进行必要的通信和同步。 •而人工智能系统利用计算机硬件简单的算术运算与逻辑运算能力模拟人类复杂的思维解题过程的。这些都大大增加了计算机系统的复杂程度, 需要十分复杂的计算机软件才能实现。由于软件越来越大, 越来越复杂, 开发过程中不可避免会有差错, 而且用户要求也会不断变化, 使软件的维护工作越来越困难(•往往一点小差错就可能导致重建整个系统), •软件维护费用占了数据处理总预算的50%以上。同时, 软件开发生产率太低, •远远不能满足用户对新系统的需求。"软件危机"进一步加剧。
1.2 软件危机
1.软件
在计算机系统中，程序是不可缺少的，相对硬件而言，程序群称为软件。硬件和软件合成一体，完成系统的功能。即计算机软件的实体是硬件，而程序是使实际存在的计算机动起来的指令序列。
软件的定义形式有多种，比较公认的一种定义认为软件是由以三部分组成：憗
1) 在运行时能提供所希望的功能和性能的指令集，即程序；
2) 使得程序能够正确运行的数据结构；
3) 描述程序研制过程、方法及使用的文档。
随着计算机应用的日益普及，软件变得越来越复杂，规模也越来越大，超过100万条指令，由几百人经过几年时间才开发出来是常见的。•如何使人与人之间、人与机器之间相互了解，保证开发与维护工作的顺利进行，文档(即各种报告、说明、手册等的总称)是不可缺少的。
相对硬件来说，软件有其自身的特点：
1)它是一种逻辑实体，因而具有抽象性，虽然可记录在介质上，但无法看到软件本身的形态。
2)它是在研制、开发活动中被创造出来的，研制(开发)成本远大于生产(拷贝)成本。
3)软件在长期的运行和使用过程中没有磨损、老化等问题。
4)软件的开发和运行常常受硬件的限制
5)软件的开发至今尚未完全摆脱手工工艺的开发方式
6)软件开发费用越来越高。据统计，目前软件开销要占计算机系统费用的90%以上。 由于软件所表现的独有特性，使得60年代末出现了软件危机，而且尽管经过了30年的努力，软件危机至今还没有得到彻底克服。
2. 什么是软件危机
软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是"不能正常运行"的软件才具有的, 实际上几乎所有软件都不同程度地存在这些问题。概括地说, 软件危机包含以下两方面的问题:憗
⑴如何开发软件, 以满足对软件的日益增长需求
⑵如何维护数量不断膨胀的已有软件
具体地说, 软件危机主要有下述的一些表现:
(1) 对软件开发或进度的估计常常很不准确。由于软件发展的历史短, 人们来不及积累大量的历史数据和模型作为系统开发的指南, •而计算机软件系统却越来越庞大和复杂, 传统的软件开发方法无法准确估计软件开发成本和进度。实际的成本比估计成本高出一个数量级, 实际进度比预期进度拖延几个月甚至几年的现象并不罕见。这种现象降低了软件开发组织的信誉, 而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量。
(2) 用户对"已完成的"软件系统不满意的现象经常发生。软件开发人员常常在对用户要求只有模糊了解甚至对所要解决的问题还没有确切认识的情况下, 就仓促上阵, 匆忙着手编写程序。开发人员与用户之间的信息交流往往不很充分, "闭门造车"必然导致最终的产品不符合用户的实际需要。
(3) 软件产品的质量往往靠不住(出错率高, 可靠性差, 质量低劣)。
(4) 软件缺少必要的文档资料, 常常使软件成为不可维护。计算机软件不仅仅是程序, 还应该有一整套的文档资料。这些资料应该是在软件开发过程中产生出来的, 而且应该是"最新式的"(•即资料和程序代码完全一致)。软件开发组织的管理人员可以使用这些文档资料作为"里程碑"•来管理和评价软件开发的进展状况, 软件开发人员可以利用它们作为通信工具, 在开发过程中准确地交流信息。•对维护人员更是修改维护的重要依据。缺乏必要的文档资料或文档资料不合格, 必然给软件开发和维护带来许多严重的困难和问题, 甚至使软件非常难以改正而成为不可维护的。
(5) 软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的趋势。软件产品"供不应求"的现象使人类不能充分利用计算机硬件提供的巨大潜力。
3. 产生软件危机的原因
在软件开发和维护的过程中存在这么多的严重问题, 一方面与软件本身的特点有关, 另一方面也和软件开发人员的弱点及错误认识、方法和观念有关。
(1) 软件不同于硬件, 这是计算机系统中的逻辑部件而不是物理部件。在写出程序代码
并在计算机上运行之前, 它只是开发人员的一种思路, 软件开发过程的进展较难衡量, 开发的质量也难以评价, 因此管理和控制软件开发过程相当困难。另外, 软件在运行过程中不会因为使用时间过长而被"用坏", 如果运行中发现错误,•则很可能是遇上了一个在开发时引入而没能检测发现的故障。因此, 软件维护通常意味着要改正或修改原来的设计, 这在客观上使软件较难维护。
(2) 虽然软件本身的特点确实在客观上给开发和维护带来了一些困难, 但是人们在开发和维护软件时的模糊甚至错误认识, •使用的错误开发方法和技术, 才是使软件问题出现危机的主要原因。虽然人们在使用计算机系统的过程中, 也积累和总结出许多成功的经验, 如果能坚持不懈地使用经过实践考验证明是正确的方法, 许多困难是完全可以克服的。
在软件开发与维护的许多错误认识和做法, 可以归因于在计算机系统发展的早期时代软件开发的个体化特点。今天这些错误认识仍然迷惑不少软件人员。下面剖析几个典型的错误认识, 以树立正确的概念来指导软件开发和维护工作:
① "有一个对目标的概括描述就足以着手编写程序了, 许多细节可以在以后再补充" 事实上, 对用户要求没有完整而准确的认识就匆忙着手编写程序, 是许多软件开发失败的主要原因之一。只有用户才真正了解他们自己的需要, 但许多用户在开始时并不能准确、具体地叙述他们的需要。•软件开发人员必须要做大量的深入细致的调查研究工作,• 反复多次与用户交流信息,才能真正全面/准确、具体地了解用户的需要。•对问题和目标的正确认识是解决任何问题的前提和出发点, 软件开发也不例外。
② "所谓软件开发就是编写程序并设法使它运行"
一个软件从定义、开发、使用和维护, 直到最终被废弃, 经历了一个漫长的时期, 如同一个人要经过胎儿、儿童、青年、中年、老年到最终死亡的漫长时期一样, 通常把软件经历的这个漫长的时期称为"•软件生存周期"。软件开发最初的工作是确定解决的问题是什么, 用什么方法去解决(定义与研究), 接着要具体了解用户的要求(需求分析), •然后才开始对软件进行设计, 设计之后才进行程序的编写, 最后还要经过大量的测试和调试才能交付使用。因此, 编写程序只是软件开发过程的一个阶段。在典型的软件开发工程中, 编写程序所需要的工作量只占软件开发全部工作量的10%--20%。
另外, 程序也只是软件产品中的一个组成部分, 软件开发还要得到各个开发阶段的文档资料。
③ "用户对软件的要求不断变化, 然而软件是柔软而灵活的, 可以轻易改动"
用户对软件的要求确实是经常改变, 特别是一个大型软件开发项目持续的时间相当长时, 由于外界环境变化及人的认识不断深化, 都会或多或少地改变对软件的要求。但是, 也有许多的改动不是由于用户要求的变化所造成的,• 而是由于软件开发人员在开发初期没有完全理解用户的要求,直到设计阶段甚至交付使用时才发现"已完成的"软件不完全符合用户的需要, 必须进行修改。
然而问题在于, 在软件开发的不同阶段进行的修改所需要付出的代价是非常不同的。在早期引入变动涉及的面少, 代价也就比较低, 而在开发的中期, 软件配置的许多部分已经完成, 任何的一个变动都要对所有已完成的配置部分做相应的修改, 不仅工作量大而且逻辑上也更复杂, 因此付出的代价增加很快; 而在软件"已完成"时再进行变动, 需要付出更高的代价。所以, 应该尽量减少变动, 如果必须改动, 也尽可能在开发的早期进行。
④ "软件投入生产性运行以后需要的维护工作并不多, 而且维护是一种很容易做的简单工作"
轻视维护是软件开发最大的错误。由于这种看法, 给维护分配的预算往往比较少,配备的人员也比较弱。•许多软件产品的使用寿命长达十年甚至二十年, 在这样漫长的时期中, 不仅必须改正使用过程中发现的每一个潜伏的错误, 而且当环境变化时(如硬件或系统软件更
新换代), 还必须相应地修改原来的软件以适应新的环境, 特别是必须经常改进或扩充原来的软件以满足用户不断变化的要求。所有的这些改动都 属于维护工作, •而且是在软件已经完成之后进行的。因此,• 维护是极端艰巨而复杂的工作,需要花费很大的代价。统计数据表明, 实际上用于软件维护的费用占软件总费用的50%--70%。
4. 解决软件危机的途径
尽管计算机硬件发展到了以大规模集成电路为基础的第四代计算机,然而其体系结构仍然是冯．诺依曼提出的结构,没有根本的变革, •因此硬件基本上仍然只能做简单的运算和逻辑判断,• 主要适合于进行数值计算,但是, 人类解决的问题99%以上是非数值计算的问题。•这些复杂的问题只能借助于软件来解决, 把解题过程分解成一系列简单的逻辑判断, 使许多软件非常复杂庞大, 开发工作也就十分困难了, 为了解决这些问题, 首先应该从思想上正确认识软件开发, 坚持不懈地使用经过实践考验证明是正确的方法和技术, 并从以下几方面着手:
(1) 程序的效率主要由算法的复杂性决定, 不是靠程序技巧挣来的。一般来说, 算法的效率从数量级上决定了程序的效率, 算法一旦确定, 靠程序技巧挣来的效率已微不足道, 尤其是在计算机内存容量和运算速度已大大提高了的今天, 浪费大量人力物力去挣一点效率更是不合算了。
(2) 随着软件规模的日益庞大和复杂, 必须使用良好的程序设计风格, 提高程序的可靠性和可维护性。•早期以追求效率为主要目标的程序设计思想所生产出的程序可读性低, 可靠性差, 难以维护。为了提高程序的可靠性和可维护性, 必须在进行程序设计时, 从"效率第一"转向"清晰第一"。
(3) 从根本上摒弃以前那种随心所欲的状况和手工业方式, 使之科学化、规范化和工程化。软件开发应作为一种组织良好、管理严密、各类人员协调配合, 共同完成的工程项目。应该吸收和借鉴人类长期以来从事各种工程项目所积累的行之有效的原理、方法和技术, 特别是要吸取近几十年来从事计算机软硬件开发和研究的经验教训, 推广使用好的软件开发技术、方法及各类软件工具。
总之, 为了解决软件危机, 既要有技术措施(方法和工具), 又要有必要的组织和管理措施。软件工程就是从管理和技术两个方面研究如何更好地开发和维护计算机软件的学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过实践时间考验而证明正确的管理和当前能够得到的最好的技术方法结合起来，这就是软件工程。
1.3 软件生存周期
人类解决复杂问题时采用的一个策略就是“各个击破”，也就是对问题进行分解，然后再分别解决各个子问题的策略。软件工程采用的生存周期方法学就是从时间角度对软件开发和维护的复杂总是进行分解，把软件生存周期分成若干个阶段, 每个阶段的任务相对独立而比较简单,•以降低整个软件开发工程的困难程度。采用软件工程方法论开发软件时，从对任务的抽象逻辑开始，一个阶段一个阶段地进行开发，前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的通常是使前一阶段提出的解法更进一步具体化，加进了更多的物理细节。每一个阶段的开始和结束都有严格标准，对于任何两个相邻阶段来说，前一阶段的结束标准一一阶段的开始标准。在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和管理两方面对这一阶段的开发成果进行检查，通过之
后才算结束，否则必须进行必要的返工，返工完成后还必须再经过审查。
软件从定义、开发、使用和维护,•直到最终被废弃所经历的这段时间称为软件的生存周期。软件生存周期建立了软件工程事件的顺序表。要想使软件开发获得成功, 必须遵守软件工程原理, 准确把握软件生存周期各个阶段的任务/实施步骤、完成标志及交付的文档, •使开发以一种有条不紊的方式进行, 从而大大提高软件的质量。
目前，软件生存周期的阶段划分方法有多种，软件规模、种类、开发方式、开发环境及开发时使用的方法论等都影响生存周期阶段的划分。划分软件生存周期阶段时应遵循的一条基本原则就是，使各阶段的任务彼此间应尽可能相对独立，同一阶段的各项任务的性质应尽可能相同，从而降低每个阶段任务的复杂程度，简化不同阶段的联系，以有利于软件开发工程的组织管理。
一般来说, 一个软件从酝酿到结束其使命, 要经历定义、开发和维护三个时期, 每个时期又进一步可分为若干阶段。
软件定义时期的任务是：1)确定软件开发工程所必须完成的总目标；2)确定工程的可行性；3)开发软件系统需要的资源(人力资源和设备资源)；4)作出成本估算；5)制定工程进度表；6)明确软件需求和软件验收标准；7)在经过管理评审和技术评审后进入软件开发时期。 软件开发时期是具体设计和实现前一时期定义的软件，它通常由概要设计、详细设计、编码和测试四个阶段组成。
软件维护时期的主要任务是使软件持久地满足用户的需要，即：1)当软件在使用过程中发现错误时应该加以改正；2)当环境改变时应该修改软件；3)当用户有新要求时应该及时改时软件，以满足用户的新需要。通常对维护时期不再进一步划分阶段，但每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。
因此，软件工程强调使用生存周期方法学和各种结构分析与设计技术来开发软件。它将一套形式化过程应用于计算机软件的定义、开发和维护，软件生存周期的每一都要文档化和评审，各个过程都有先进、成熟的技术支持，软件开发要求管理和技术并重。因此，它是一门涉及软件计划、需求分析、设计、编码、测试和维护的原理、方法及工具的研究和应用学科。
1.4 软件开发模型与方法
软件工程是计算机软件走向工程化的途径。在软件开发过程中，软件工程思想具体为软件开发过程模型及其实施于过程模型中的软件开发方法和工具。经过几十年对软件开发过程的探索，人们提出了四种典型的软件开发过程模型。
1.瀑布开发模型
典型的瀑布开发模型可采用B.W.Boehm的描述，•他将软件生存周期划分为七个阶段，各阶段的任务分别为系统需求分析、软件需求分析、概要设计、详细设计、编码、测试阶段和运行维护，每一阶段工作的完成需要评审等技术的确认。
瀑布开发模型的主要特点是：阶段间的顺序性和信赖性强，开发过程是一个严格的下导式过程，即前一阶段的输出是后一阶段的输入，每一阶段工作的完成需要确认，而确认过程是严格的追溯过程，后一阶段出现了问题要通过前一阶段的重新确认来解决。因此，问题发现得越晚解决问题的代价就越高。
瀑布开发模型的主要不足是：
1)从认识论上讲，人的认识是一个多次反复的过程，实践→认识→再实践→再认识，多次认识，多次飞跃，最后才能获得对客观世界较为正确的认识。软件开发是人的一个智力认识活动，也不可能一次完成，也需要经过多次反复进行，但瀑布开发模型中划分的阶段中没有反映出这种认识过程的反复性。
2)软件开发是一个知识密集型的开发活动，需要人们合作完成，因此，人员之间的通信和软件工具之间的联系、活动之间的并行和串行等都是必需的，但在瀑布开发模型中也没有体现出这一点。
2.原型模型(Prototyping Model)
原型模型是借助程序自动生成工具或软件工程支撑环境，尽快地构造出一个实际系统简化的模型，以便供开发人员和用户进行交流，较准确地获取用户的需要。它的示意图为： ┌────┐
│需求分析├─┐
└┬┬──┘ ↓
↑↑ ┌─┴──┐
││ │快速设计├─┐
││ └─┬──┘ ↓
││ ↓ ┌─┴──┐
││ │ │建立原型├─┐
││ │ └─┬──┘ ↓
││ │ ↓ ┌─┴─────┐
│└────┴────┘ │评审和修改需求├─┐
│ └──┬─┬──┘ ↓
│ ↓ ↑ ┌─┴──┐
└────────────────┘ └──┤建立生产│
└────┘
⑴原型模型的主要特点是: 首先建立一个能够反映用户主要需求的原型, 为用户展示未来软件系统的概貌, 使用户可以比较直观地从最终软件产品的角度出发对原型提出修改意见,软件人员反复改进, •最终建立完全符合用户要求的软件系统。这实际上是一个软件人员不断向用户提供样品，而用户对其做出迅速反馈，以进一步改善样品的过程，这就大大避免了在瀑布模型冗长的开发过程中，看不见最终软件产品雏形的现象。
原型模型在各个阶段用户反馈活动基础上，突出 快速的改进过程，它改变了瀑布模型的线性结构，采用逐步求精方法使原型逐步完善，以满足用户的要求，是一种在新的高层次上不断反复推进的过程。
⑵原型模型的不足有以下两点：
1)为了使系统尽快地运行起来，系统开发人员在初期往往考虑不周，经常采取一些折衷的方案，有可能使原型不能成为最终软件产品的一部分，只是一个示例而已(称这种原型为示例型)。这样，在实际开发软件产品时，仍然有许多工作要做。
2)原型模型需要大量完备和实用的软件工具的支持才能得以实现，即原型模型对工具和环境的依赖性较高。
⑶原型模型应该昼选用适当的超高级语言作为开发工具。
APL是一种典型的超高级语言，•它提供诸如矩阵运算之类的功能很强的操作，非常简洁，用它写程序时书写和键盘需要的时间都很少。用•APL语言开发一个原型系统所需要的
时间通常只相当于实现最终的软件系统所用时间的一小部分。除了运行时开销很大外，APL•语言的语法也不容许用它写出结构良好的易读易懂的程序，因此不适于用来书写实际大型的软件系统。
开发原型系统时另一个非常有用的工具是UNIX操作系统的命令解释语言Shell，特别是第7版UNIX的Shell语言具有许多非常有用的特点。Shell既是一个交互式的命令解释程序，又量个命令级程序设计语言的解释程序。Shell程序设计语言的基本操作是UNIX系统命令，因此在一个Shell程序中可以UNIX使用操作系统的全部功能。
开发原型系统时用得最普遍的可能是PROLOG语言，它是以一阶谓词逻辑的HORN子集为语法，以消解原理为语义，以深度优先为控制策略而形成的一种交互式语言。PROLOG接近于自然语言，是一种描述性程序设计语言，具有极强的知识表达、推理和查询功能，在表达知识和快速建立软件原型两个方面都 具有明显的优势。它只有事实、规则和询问三种语句，语法比任何惯用的常规程序设计语言都要简单，而且具有人机交互功能，使用十分方便。用PROLOG语言编写程序就是用事实或规则表达对象之间的逻辑关系，然后即可向系统询问要解决的问题。系统自动搜索已知的事实和规则，根据消解原理，利用全一和回溯来求解问题。因为不必写出详细的算法来告诉计算机“怎样做”，所以PROLOG程序非常简洁，逻辑性很强。
3.喷泉模型(Fountain Model)
在面向对象(OO)方法中，提出了与瀑布模型相对应的喷泉模型，该模型认为软件生存周期的各个阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，即可以落在中间，也可以落在最底部。憘泙拝
┌─────┐
│运行 维护│
┌┼──┬──┼┐ 初始需求索集 │ •基于初始需求 ↓└──┼──┘↓ 与项目计划 │ •的风险分析 ┌──┼──┐ │ 基于用户反应 │ 测 ↑ 试 │ │ 的风险分析 ┌┼──┼──┼┐ 基于用户 │
↓└──┼──┘↓ 说明的计划 │
┌──┼──┐ │
│ 编 ↑ 码 │ │
┌┼──┼──┼┐ ──────┼───────
↓└──┼──┘↓ │
┌──┼──┐ │
│构件↑设计│ ┌┼──┼──┼┐ ↓└──┼──┘↓ 用户评价 ┌──┼──┐ │ │ │ 初始软件原型 │ •第二级原型 │系统↑设计│ │ 工程系统 ┌┼──┼──┼┐ ↓└──┼──┘↓ 螺旋模型 ┌──┼──┐ │需求↑分析│
└──┴──┘
喷泉模型
4.螺旋模型
相对瀑布模型而言，原型模型更符合人类认识真理的渐近修正的思维方式，它刺激了有良好工具和可重用成分的环境的发展。但在原型评价、改进的多次反复过程中，可能会引入其他风险，诸如计划的调整、需求的增加等。为了解决这一问题，Boehm•等人在原型模型基础上又提出多次原型反复，并增加风险评估的螺旋式开发模型。
第一章 软件工程的基本概念....................................................................................... 1
1.1 计算机发展简史 .................................................................................................. 1
1.2 软件危机........................................................................................................... 2
1.软件 ................................................................................................................ 2
2. 什么是软件危机............................................................................................. 3
3. 产生软件危机的原因...................................................................................... 3
4. 解决软件危机的途径...................................................................................... 5
1.3 软件生存周期 .................................................................................................. 5
1.4 软件开发模型与方法 ......................................................................................... 6
1.瀑布开发模型 .................................................................................................. 6
2.原型模型(Prototyping Model) ............................................................................ 7
3.喷泉模型(Fountain Model) ................................................................................ 8
4.螺旋模型 ......................................................................................................... 9
第一章 软件工程的基本概念
在计算机系统发展的早期阶段, 由于人们认识上的局限性, 对计算机软件产生了一些片面的、错误的认识, 使计算机软件发展几经挫折, 走了不少弯路, 遭受到了"软件危机"的困扰。为了推进计算机软件开发技术的发展, 摆脱"软件危机"的困扰, 从60年代后期迅速发展起一门旨在研究软件开发与维护的普遍管理和技术的新兴学科---软件工程学, •简称软件工程。
1.1 计算机发展简史
按照计算机硬件的演变来划分计算机系统发展的时期, 可分为电子管、晶体管、集成电路和大规模集成电路四个时期。但为了了解计算机软件的发展演变的过程, 我们按照计算机应用领域的演变而不是仅仅根据硬件特点的演变来划分计算机系统的发展时期, 在工业发达的国家中计算机系统已经历了三个不同的发展时期。
1. •从世界上出现第一台计算机到六十年代中期是计算机系统发展的早期时代。在这个时期中, 人们将主要精力集中在研究和发展计算机硬件上, 经历了从电子管到晶体管计算机的变革。为了控制硬件的成本, 管理者建立了正式的控制和工艺标准,•以在开发产品之前进行细致的分析和设计。但是人们对计算机软件的研究和发展却不够重视, 认为软件开发是事后考虑的问题。那时的软件开发就是根据应用的需要写出能够运行的程序,因此, 基本上没有系统化的软件开发方法。由于硬件价格昂贵, 运算速度低, 内存容量少, 当时的程序员非常强调"程序设计技巧", 把缩短每一微秒CPU时间和节省每一个二进制存储单元作为程序设计•(当时的软件开发)的重要目标。
在计算机系统发展的早期时期, 大多数系统采用批处理方式工作。当时通用硬件相当普遍, 软件却是为了每个具体应用而专门设计的, 而且大多数软件的开发者和使用者是同一个(或一组)人。编写程序的人要设法使程序在机器上运行起来, 并且负责使用这个程序解决预定的问题, 发生什么错误也是由这个人设法修改, 这样的软件设计通常是人们头脑中进行的一个隐含过程, 而且除了程序清单外, 一般没有其他文档资料保存下来。
2. 从六十年代中期到七十年代中期是计算机系统发展的第二代。•在这个时期中, 硬件经历了从晶体管计算机到集成电路计算机的变革。•CPU速度和内存容量都有了很大的提高, 从而为计算机在众多领域中的应用提供了潜在的可能性。为了更有效地利用硬件的能力, 计算机系统普遍采用多道程序多用户的分时工作方式。计算机与通信结合, 开辟了计算机应用的一个新领域。当时最辉煌的成就之一就是美国航空公司SABRE•订票系统的实现和成功运行。这是第一个大型事务处理系统, 分散在遥远地点的用户可通过键盘终端与中央计算机系统进行通信。
在这个时期, 计算机应用开始普及和深化, 软件与硬件分离, 作为一种商品出现, 用户广泛使用产品软件(包括操作系统)。因为当时用户需要的软件往往是相当庞大的, 单个用户已无力开发, 另外, 许多不同部门和企业往往需要相同的或类似的软件, 各自开发就会浪费人力物力。因此用户大多是购买或定做软件。但是, 软件开发的方法基本没有什么变化。 随着计算机系统的不断增加, 计算机软件库开始膨胀。但在程序运行中发现错误时必须设法改正, 当用户的要求有改变进也必须修改程序, 当买进新硬件或操作系统新版本时时通常必须改变程序以适应新的环境。这些软件的维护工作, 以令人吃惊的比例耗费资源, 更严重的是, 许多程序的个体化特性使它们最终成为不可维护的(•如人员调动或时间长而记不清当时的设计思想等)。这就出现了"软件危机"。
3. 计算机系统发展的第三代从七十年代初期开始, •这时的硬件已从集成电路计算机发展到超大规模集成电路计算机, 高性能低成本的微处理器大量涌现, 发展日新月异。
计算机应用的进一步普及和深化, 开辟了更多新的应用领域。如分布式系统使用多台计算机共同解决一个问题, 各台计算机并行工作分别完成各自的子任务, 同时各台间进行必要的通信和同步。 •而人工智能系统利用计算机硬件简单的算术运算与逻辑运算能力模拟人类复杂的思维解题过程的。这些都大大增加了计算机系统的复杂程度, 需要十分复杂的计算机软件才能实现。由于软件越来越大, 越来越复杂, 开发过程中不可避免会有差错, 而且用户要求也会不断变化, 使软件的维护工作越来越困难(•往往一点小差错就可能导致重建整个系统), •软件维护费用占了数据处理总预算的50%以上。同时, 软件开发生产率太低, •远远不能满足用户对新系统的需求。"软件危机"进一步加剧。
1.2 软件危机
1.软件
在计算机系统中，程序是不可缺少的，相对硬件而言，程序群称为软件。硬件和软件合成一体，完成系统的功能。即计算机软件的实体是硬件，而程序是使实际存在的计算机动起来的指令序列。
软件的定义形式有多种，比较公认的一种定义认为软件是由以三部分组成：憗
1) 在运行时能提供所希望的功能和性能的指令集，即程序；
2) 使得程序能够正确运行的数据结构；
3) 描述程序研制过程、方法及使用的文档。
随着计算机应用的日益普及，软件变得越来越复杂，规模也越来越大，超过100万条指令，由几百人经过几年时间才开发出来是常见的。•如何使人与人之间、人与机器之间相互了解，保证开发与维护工作的顺利进行，文档(即各种报告、说明、手册等的总称)是不可缺少的。
相对硬件来说，软件有其自身的特点：
1)它是一种逻辑实体，因而具有抽象性，虽然可记录在介质上，但无法看到软件本身的形态。
2)它是在研制、开发活动中被创造出来的，研制(开发)成本远大于生产(拷贝)成本。
3)软件在长期的运行和使用过程中没有磨损、老化等问题。
4)软件的开发和运行常常受硬件的限制
5)软件的开发至今尚未完全摆脱手工工艺的开发方式
6)软件开发费用越来越高。据统计，目前软件开销要占计算机系统费用的90%以上。 由于软件所表现的独有特性，使得60年代末出现了软件危机，而且尽管经过了30年的努力，软件危机至今还没有得到彻底克服。
2. 什么是软件危机
软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是"不能正常运行"的软件才具有的, 实际上几乎所有软件都不同程度地存在这些问题。概括地说, 软件危机包含以下两方面的问题:憗
⑴如何开发软件, 以满足对软件的日益增长需求
⑵如何维护数量不断膨胀的已有软件
具体地说, 软件危机主要有下述的一些表现:
(1) 对软件开发或进度的估计常常很不准确。由于软件发展的历史短, 人们来不及积累大量的历史数据和模型作为系统开发的指南, •而计算机软件系统却越来越庞大和复杂, 传统的软件开发方法无法准确估计软件开发成本和进度。实际的成本比估计成本高出一个数量级, 实际进度比预期进度拖延几个月甚至几年的现象并不罕见。这种现象降低了软件开发组织的信誉, 而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量。
(2) 用户对"已完成的"软件系统不满意的现象经常发生。软件开发人员常常在对用户要求只有模糊了解甚至对所要解决的问题还没有确切认识的情况下, 就仓促上阵, 匆忙着手编写程序。开发人员与用户之间的信息交流往往不很充分, "闭门造车"必然导致最终的产品不符合用户的实际需要。
(3) 软件产品的质量往往靠不住(出错率高, 可靠性差, 质量低劣)。
(4) 软件缺少必要的文档资料, 常常使软件成为不可维护。计算机软件不仅仅是程序, 还应该有一整套的文档资料。这些资料应该是在软件开发过程中产生出来的, 而且应该是"最新式的"(•即资料和程序代码完全一致)。软件开发组织的管理人员可以使用这些文档资料作为"里程碑"•来管理和评价软件开发的进展状况, 软件开发人员可以利用它们作为通信工具, 在开发过程中准确地交流信息。•对维护人员更是修改维护的重要依据。缺乏必要的文档资料或文档资料不合格, 必然给软件开发和维护带来许多严重的困难和问题, 甚至使软件非常难以改正而成为不可维护的。
(5) 软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的趋势。软件产品"供不应求"的现象使人类不能充分利用计算机硬件提供的巨大潜力。
3. 产生软件危机的原因
在软件开发和维护的过程中存在这么多的严重问题, 一方面与软件本身的特点有关, 另一方面也和软件开发人员的弱点及错误认识、方法和观念有关。
(1) 软件不同于硬件, 这是计算机系统中的逻辑部件而不是物理部件。在写出程序代码
并在计算机上运行之前, 它只是开发人员的一种思路, 软件开发过程的进展较难衡量, 开发的质量也难以评价, 因此管理和控制软件开发过程相当困难。另外, 软件在运行过程中不会因为使用时间过长而被"用坏", 如果运行中发现错误,•则很可能是遇上了一个在开发时引入而没能检测发现的故障。因此, 软件维护通常意味着要改正或修改原来的设计, 这在客观上使软件较难维护。
(2) 虽然软件本身的特点确实在客观上给开发和维护带来了一些困难, 但是人们在开发和维护软件时的模糊甚至错误认识, •使用的错误开发方法和技术, 才是使软件问题出现危机的主要原因。虽然人们在使用计算机系统的过程中, 也积累和总结出许多成功的经验, 如果能坚持不懈地使用经过实践考验证明是正确的方法, 许多困难是完全可以克服的。
在软件开发与维护的许多错误认识和做法, 可以归因于在计算机系统发展的早期时代软件开发的个体化特点。今天这些错误认识仍然迷惑不少软件人员。下面剖析几个典型的错误认识, 以树立正确的概念来指导软件开发和维护工作:
① "有一个对目标的概括描述就足以着手编写程序了, 许多细节可以在以后再补充" 事实上, 对用户要求没有完整而准确的认识就匆忙着手编写程序, 是许多软件开发失败的主要原因之一。只有用户才真正了解他们自己的需要, 但许多用户在开始时并不能准确、具体地叙述他们的需要。•软件开发人员必须要做大量的深入细致的调查研究工作,• 反复多次与用户交流信息,才能真正全面/准确、具体地了解用户的需要。•对问题和目标的正确认识是解决任何问题的前提和出发点, 软件开发也不例外。
② "所谓软件开发就是编写程序并设法使它运行"
一个软件从定义、开发、使用和维护, 直到最终被废弃, 经历了一个漫长的时期, 如同一个人要经过胎儿、儿童、青年、中年、老年到最终死亡的漫长时期一样, 通常把软件经历的这个漫长的时期称为"•软件生存周期"。软件开发最初的工作是确定解决的问题是什么, 用什么方法去解决(定义与研究), 接着要具体了解用户的要求(需求分析), •然后才开始对软件进行设计, 设计之后才进行程序的编写, 最后还要经过大量的测试和调试才能交付使用。因此, 编写程序只是软件开发过程的一个阶段。在典型的软件开发工程中, 编写程序所需要的工作量只占软件开发全部工作量的10%--20%。
另外, 程序也只是软件产品中的一个组成部分, 软件开发还要得到各个开发阶段的文档资料。
③ "用户对软件的要求不断变化, 然而软件是柔软而灵活的, 可以轻易改动"
用户对软件的要求确实是经常改变, 特别是一个大型软件开发项目持续的时间相当长时, 由于外界环境变化及人的认识不断深化, 都会或多或少地改变对软件的要求。但是, 也有许多的改动不是由于用户要求的变化所造成的,• 而是由于软件开发人员在开发初期没有完全理解用户的要求,直到设计阶段甚至交付使用时才发现"已完成的"软件不完全符合用户的需要, 必须进行修改。
然而问题在于, 在软件开发的不同阶段进行的修改所需要付出的代价是非常不同的。在早期引入变动涉及的面少, 代价也就比较低, 而在开发的中期, 软件配置的许多部分已经完成, 任何的一个变动都要对所有已完成的配置部分做相应的修改, 不仅工作量大而且逻辑上也更复杂, 因此付出的代价增加很快; 而在软件"已完成"时再进行变动, 需要付出更高的代价。所以, 应该尽量减少变动, 如果必须改动, 也尽可能在开发的早期进行。
④ "软件投入生产性运行以后需要的维护工作并不多, 而且维护是一种很容易做的简单工作"
轻视维护是软件开发最大的错误。由于这种看法, 给维护分配的预算往往比较少,配备的人员也比较弱。•许多软件产品的使用寿命长达十年甚至二十年, 在这样漫长的时期中, 不仅必须改正使用过程中发现的每一个潜伏的错误, 而且当环境变化时(如硬件或系统软件更
新换代), 还必须相应地修改原来的软件以适应新的环境, 特别是必须经常改进或扩充原来的软件以满足用户不断变化的要求。所有的这些改动都 属于维护工作, •而且是在软件已经完成之后进行的。因此,• 维护是极端艰巨而复杂的工作,需要花费很大的代价。统计数据表明, 实际上用于软件维护的费用占软件总费用的50%--70%。
4. 解决软件危机的途径
尽管计算机硬件发展到了以大规模集成电路为基础的第四代计算机,然而其体系结构仍然是冯．诺依曼提出的结构,没有根本的变革, •因此硬件基本上仍然只能做简单的运算和逻辑判断,• 主要适合于进行数值计算,但是, 人类解决的问题99%以上是非数值计算的问题。•这些复杂的问题只能借助于软件来解决, 把解题过程分解成一系列简单的逻辑判断, 使许多软件非常复杂庞大, 开发工作也就十分困难了, 为了解决这些问题, 首先应该从思想上正确认识软件开发, 坚持不懈地使用经过实践考验证明是正确的方法和技术, 并从以下几方面着手:
(1) 程序的效率主要由算法的复杂性决定, 不是靠程序技巧挣来的。一般来说, 算法的效率从数量级上决定了程序的效率, 算法一旦确定, 靠程序技巧挣来的效率已微不足道, 尤其是在计算机内存容量和运算速度已大大提高了的今天, 浪费大量人力物力去挣一点效率更是不合算了。
(2) 随着软件规模的日益庞大和复杂, 必须使用良好的程序设计风格, 提高程序的可靠性和可维护性。•早期以追求效率为主要目标的程序设计思想所生产出的程序可读性低, 可靠性差, 难以维护。为了提高程序的可靠性和可维护性, 必须在进行程序设计时, 从"效率第一"转向"清晰第一"。
(3) 从根本上摒弃以前那种随心所欲的状况和手工业方式, 使之科学化、规范化和工程化。软件开发应作为一种组织良好、管理严密、各类人员协调配合, 共同完成的工程项目。应该吸收和借鉴人类长期以来从事各种工程项目所积累的行之有效的原理、方法和技术, 特别是要吸取近几十年来从事计算机软硬件开发和研究的经验教训, 推广使用好的软件开发技术、方法及各类软件工具。
总之, 为了解决软件危机, 既要有技术措施(方法和工具), 又要有必要的组织和管理措施。软件工程就是从管理和技术两个方面研究如何更好地开发和维护计算机软件的学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过实践时间考验而证明正确的管理和当前能够得到的最好的技术方法结合起来，这就是软件工程。
1.3 软件生存周期
人类解决复杂问题时采用的一个策略就是“各个击破”，也就是对问题进行分解，然后再分别解决各个子问题的策略。软件工程采用的生存周期方法学就是从时间角度对软件开发和维护的复杂总是进行分解，把软件生存周期分成若干个阶段, 每个阶段的任务相对独立而比较简单,•以降低整个软件开发工程的困难程度。采用软件工程方法论开发软件时，从对任务的抽象逻辑开始，一个阶段一个阶段地进行开发，前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的通常是使前一阶段提出的解法更进一步具体化，加进了更多的物理细节。每一个阶段的开始和结束都有严格标准，对于任何两个相邻阶段来说，前一阶段的结束标准一一阶段的开始标准。在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和管理两方面对这一阶段的开发成果进行检查，通过之
后才算结束，否则必须进行必要的返工，返工完成后还必须再经过审查。
软件从定义、开发、使用和维护,•直到最终被废弃所经历的这段时间称为软件的生存周期。软件生存周期建立了软件工程事件的顺序表。要想使软件开发获得成功, 必须遵守软件工程原理, 准确把握软件生存周期各个阶段的任务/实施步骤、完成标志及交付的文档, •使开发以一种有条不紊的方式进行, 从而大大提高软件的质量。
目前，软件生存周期的阶段划分方法有多种，软件规模、种类、开发方式、开发环境及开发时使用的方法论等都影响生存周期阶段的划分。划分软件生存周期阶段时应遵循的一条基本原则就是，使各阶段的任务彼此间应尽可能相对独立，同一阶段的各项任务的性质应尽可能相同，从而降低每个阶段任务的复杂程度，简化不同阶段的联系，以有利于软件开发工程的组织管理。
一般来说, 一个软件从酝酿到结束其使命, 要经历定义、开发和维护三个时期, 每个时期又进一步可分为若干阶段。
软件定义时期的任务是：1)确定软件开发工程所必须完成的总目标；2)确定工程的可行性；3)开发软件系统需要的资源(人力资源和设备资源)；4)作出成本估算；5)制定工程进度表；6)明确软件需求和软件验收标准；7)在经过管理评审和技术评审后进入软件开发时期。 软件开发时期是具体设计和实现前一时期定义的软件，它通常由概要设计、详细设计、编码和测试四个阶段组成。
软件维护时期的主要任务是使软件持久地满足用户的需要，即：1)当软件在使用过程中发现错误时应该加以改正；2)当环境改变时应该修改软件；3)当用户有新要求时应该及时改时软件，以满足用户的新需要。通常对维护时期不再进一步划分阶段，但每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。
因此，软件工程强调使用生存周期方法学和各种结构分析与设计技术来开发软件。它将一套形式化过程应用于计算机软件的定义、开发和维护，软件生存周期的每一都要文档化和评审，各个过程都有先进、成熟的技术支持，软件开发要求管理和技术并重。因此，它是一门涉及软件计划、需求分析、设计、编码、测试和维护的原理、方法及工具的研究和应用学科。
1.4 软件开发模型与方法
软件工程是计算机软件走向工程化的途径。在软件开发过程中，软件工程思想具体为软件开发过程模型及其实施于过程模型中的软件开发方法和工具。经过几十年对软件开发过程的探索，人们提出了四种典型的软件开发过程模型。
1.瀑布开发模型
典型的瀑布开发模型可采用B.W.Boehm的描述，•他将软件生存周期划分为七个阶段，各阶段的任务分别为系统需求分析、软件需求分析、概要设计、详细设计、编码、测试阶段和运行维护，每一阶段工作的完成需要评审等技术的确认。
瀑布开发模型的主要特点是：阶段间的顺序性和信赖性强，开发过程是一个严格的下导式过程，即前一阶段的输出是后一阶段的输入，每一阶段工作的完成需要确认，而确认过程是严格的追溯过程，后一阶段出现了问题要通过前一阶段的重新确认来解决。因此，问题发现得越晚解决问题的代价就越高。
瀑布开发模型的主要不足是：
1)从认识论上讲，人的认识是一个多次反复的过程，实践→认识→再实践→再认识，多次认识，多次飞跃，最后才能获得对客观世界较为正确的认识。软件开发是人的一个智力认识活动，也不可能一次完成，也需要经过多次反复进行，但瀑布开发模型中划分的阶段中没有反映出这种认识过程的反复性。
2)软件开发是一个知识密集型的开发活动，需要人们合作完成，因此，人员之间的通信和软件工具之间的联系、活动之间的并行和串行等都是必需的，但在瀑布开发模型中也没有体现出这一点。
2.原型模型(Prototyping Model)
原型模型是借助程序自动生成工具或软件工程支撑环境，尽快地构造出一个实际系统简化的模型，以便供开发人员和用户进行交流，较准确地获取用户的需要。它的示意图为： ┌────┐
│需求分析├─┐
└┬┬──┘ ↓
↑↑ ┌─┴──┐
││ │快速设计├─┐
││ └─┬──┘ ↓
││ ↓ ┌─┴──┐
││ │ │建立原型├─┐
││ │ └─┬──┘ ↓
││ │ ↓ ┌─┴─────┐
│└────┴────┘ │评审和修改需求├─┐
│ └──┬─┬──┘ ↓
│ ↓ ↑ ┌─┴──┐
└────────────────┘ └──┤建立生产│
└────┘
⑴原型模型的主要特点是: 首先建立一个能够反映用户主要需求的原型, 为用户展示未来软件系统的概貌, 使用户可以比较直观地从最终软件产品的角度出发对原型提出修改意见,软件人员反复改进, •最终建立完全符合用户要求的软件系统。这实际上是一个软件人员不断向用户提供样品，而用户对其做出迅速反馈，以进一步改善样品的过程，这就大大避免了在瀑布模型冗长的开发过程中，看不见最终软件产品雏形的现象。
原型模型在各个阶段用户反馈活动基础上，突出 快速的改进过程，它改变了瀑布模型的线性结构，采用逐步求精方法使原型逐步完善，以满足用户的要求，是一种在新的高层次上不断反复推进的过程。
⑵原型模型的不足有以下两点：
1)为了使系统尽快地运行起来，系统开发人员在初期往往考虑不周，经常采取一些折衷的方案，有可能使原型不能成为最终软件产品的一部分，只是一个示例而已(称这种原型为示例型)。这样，在实际开发软件产品时，仍然有许多工作要做。
2)原型模型需要大量完备和实用的软件工具的支持才能得以实现，即原型模型对工具和环境的依赖性较高。
⑶原型模型应该昼选用适当的超高级语言作为开发工具。
APL是一种典型的超高级语言，•它提供诸如矩阵运算之类的功能很强的操作，非常简洁，用它写程序时书写和键盘需要的时间都很少。用•APL语言开发一个原型系统所需要的
时间通常只相当于实现最终的软件系统所用时间的一小部分。除了运行时开销很大外，APL•语言的语法也不容许用它写出结构良好的易读易懂的程序，因此不适于用来书写实际大型的软件系统。
开发原型系统时另一个非常有用的工具是UNIX操作系统的命令解释语言Shell，特别是第7版UNIX的Shell语言具有许多非常有用的特点。Shell既是一个交互式的命令解释程序，又量个命令级程序设计语言的解释程序。Shell程序设计语言的基本操作是UNIX系统命令，因此在一个Shell程序中可以UNIX使用操作系统的全部功能。
开发原型系统时用得最普遍的可能是PROLOG语言，它是以一阶谓词逻辑的HORN子集为语法，以消解原理为语义，以深度优先为控制策略而形成的一种交互式语言。PROLOG接近于自然语言，是一种描述性程序设计语言，具有极强的知识表达、推理和查询功能，在表达知识和快速建立软件原型两个方面都 具有明显的优势。它只有事实、规则和询问三种语句，语法比任何惯用的常规程序设计语言都要简单，而且具有人机交互功能，使用十分方便。用PROLOG语言编写程序就是用事实或规则表达对象之间的逻辑关系，然后即可向系统询问要解决的问题。系统自动搜索已知的事实和规则，根据消解原理，利用全一和回溯来求解问题。因为不必写出详细的算法来告诉计算机“怎样做”，所以PROLOG程序非常简洁，逻辑性很强。
3.喷泉模型(Fountain Model)
在面向对象(OO)方法中，提出了与瀑布模型相对应的喷泉模型，该模型认为软件生存周期的各个阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，即可以落在中间，也可以落在最底部。憘泙拝
┌─────┐
│运行 维护│
┌┼──┬──┼┐ 初始需求索集 │ •基于初始需求 ↓└──┼──┘↓ 与项目计划 │ •的风险分析 ┌──┼──┐ │ 基于用户反应 │ 测 ↑ 试 │ │ 的风险分析 ┌┼──┼──┼┐ 基于用户 │
↓└──┼──┘↓ 说明的计划 │
┌──┼──┐ │
│ 编 ↑ 码 │ │
┌┼──┼──┼┐ ──────┼───────
↓└──┼──┘↓ │
┌──┼──┐ │
│构件↑设计│ ┌┼──┼──┼┐ ↓└──┼──┘↓ 用户评价 ┌──┼──┐ │ │ │ 初始软件原型 │ •第二级原型 │系统↑设计│ │ 工程系统 ┌┼──┼──┼┐ ↓└──┼──┘↓ 螺旋模型 ┌──┼──┐ │需求↑分析│
└──┴──┘
喷泉模型
4.螺旋模型
相对瀑布模型而言，原型模型更符合人类认识真理的渐近修正的思维方式，它刺激了有良好工具和可重用成分的环境的发展。但在原型评价、改进的多次反复过程中，可能会引入其他风险，诸如计划的调整、需求的增加等。为了解决这一问题，Boehm•等人在原型模型基础上又提出多次原型反复，并增加风险评估的螺旋式开发模型。