《软件工程的产生》

1.1软件工程的产生

1.2软件工程过程和软件生存周期

1.3软件生存周期模型

1.4软件开发方法

1.5软件开发工具第1章绪论返回主目录第1章绪论1.1软件工程的产生

1.1.1软件的特点“软件”一词是20世纪60年代才出现的，其定义为计算机程序及其说明程序的各种文档。在该定义中，“程序”是计算任务的处理对象和处理规则的描述；“文档”是有关计算机程序功能、设计、编制、使用的文字或图形资料。软件与硬件一起构成完整的计算机系统，它们是相互依存的，缺一不可的。软件是一种特殊的产品，它具有下列一些特性：(1)软件是一种逻辑产品，它与物质产品有很大的区别。软件产品是看不见摸不着的，因而具有无形性。第1章绪论它是脑力劳动的结晶，综以程序和文档的形式出现，保存在计算机存储器的磁盘和光盘介质上，通过计算机的运行才能体现它的功能和作用。(2)软件产品的生产主要是研制。其成本主要体现在软件的开发和研制上，软件开发研究完成后，通过复制就产生了大量软件产品。(3)软件产品不会用坏，不存在磨损、消耗问题。(4)软件产品的生产主要是脑力劳动，还未完全摆脱手工开发方式，大部分产品是“定做”的。(5)软件费用不断增加，软件成本相当昂贵。软件的研制工作需要投放大量的、复杂的、高强度的脑力劳动，它的成本非常高。

1.1.2软件生产的发展自从第一台计算机诞生以来，就开了软件的生产，到目前为止，已经过了程序设计、程序系统和软件工程三个时代。

1.程序设计时代(1946~1956年)程序设计时代的生产方式是个体手工劳动，使用的工具是机器语言、汇编语言；开发方法是追求编程技巧，追求程序运行效率，使得程序难读、难懂、难修改；硬件特征是价格贵、存储容量小、运行可靠性差；软件特征是保有程序、程序设计概念，不重视程序设计方法。

2.程序系统时代(1956~1968年)程序系统时代的生产方式是作坊式的小集团合作生产，生产工具是高级语言；开发方法仍旧靠个人技巧，但开始提出了结构化方法；硬件特征是速度、容量及工作可靠性有明显提高，价格降低，销售有爆炸性增长；软件特征是程序员数量猛增，其他行业人员大量进入这个行业，由于缺乏训练，开发人员素质差。这时已意识到软件开发的重要性，大量软件开发的需求已提出，但开发技术没有新的突破，开发人员的素质和落后的开发技术不适应规模大、结构复杂的软件的开发，因此产生了头锐的矛盾，导致软件危机的产生。

3.软件工程时代(1968年至今)软件工程时代的生产方式是工程化的生产，使用数库、开发工具、开发环境、网络、分布式、面向对象技术来开发软件；硬件特征是向超高速、大容量、微型化以及网络化方向发展；软件特征是开发技术有很大进步，但是未能获得突破性进展，软件价格不断上升，没有完全摆脱软件危机。

1.1.3软件危机

1.软件危机的产生软件发展第二阶段的末期，由于计算机硬件技术的进步，计算机运行速度、容量和可靠性有显著的提高，生产成本有显著下降，为计算机的广泛应用创造了条件。一些复杂的、大型的软件开发项目提出来了，但是，软件开发技术一直未能满足发展的要求。软件开发中遇到的问题因找不到解决的办法，使问题积累起来，形成了尖锐的矛盾，导致了软件危机。

2.软件危机的表现软件危机表现在以下几方面：、(1)经费预算经常突破，完成时间一再拖延。由于缺乏软件开发的经验和软件开发数据的积累，使得开发工作的计算很难制定。主观盲目制定的计算，执行起来和实际情况有很大差距，使得开发经费一再突破。由于对工作量和开发难度估计不足，进度计划无法按时完成，开发时间一再拖延。(2)开发的软件不能满足用户要求。开发初期对用户的要求了解不够明确，未能得到明确表达。开发工作开始后，软件人员和用户又未能及进交换意见，使得一些问题不能及时解决，导致开发的软件不能满足用户的要求，使开发失败。(3)开发的软件可维护性差。开发过程没有统一的、公认的规范，软件开发人员按各自的风格工作，各行其事。开发过程无完整、规范的文档，发现问题后进行杂乱无章的修改。程序结构不好，运行进发现错误也很难修改，导致维护性差。(4)开发的软件可靠性差。由于在开发过程中，没有确保软件质量的体系和措施，在软件测试时，又没有严格的、充分的、完全的测试，提交给用户的软件质量差，在运行中暴露出大量的问题。这种不可靠的软件，轻者会影响系统正常工作，重者会发生事故，造成生命财产的重大损失。

3.软件危机的原因造成上述软件危机的原因概括起来有以下几方面。(1)软件的规模越来越大，结构越来越复杂。随着计算机应用的日益广泛，需要开发的软件规模日益庞大，软件结构也日益复杂。1968年美国航空公司订票系统达到30万条指令；IBM360OS第16版达到100万条指令，花了5000个人年；1973年美国阿波罗计划达到1千万条指令。这些庞大软件的功能非常复杂，体现在处理功能的多样性和运行环境的多样性。有人曾估计，软件设计与硬件设计相比，其逻辑量要多达10~100倍。对于这种庞大规模的软件，其调用关系、接口信息复杂，数据结构也复杂，这种复杂程度超过了人所能接受的程度。(2)软件开发的管理困难。由于软件规模大，结构复杂，又具有无形性，导致管理困难，进芳控制困难，质量控制困难，可靠性无法保证。(3)软件开发费用不断增加。软件生产是一种智力劳动，它是资金密集、人力密集的产业，大型软件投入人力多，周期长，费用上升很快。(4)软件开发技术落后。20世纪在60年代，人们注重一些计算机理论问题的研究，如编译原理、操作系统原理、数据库原理、人工智能原理、形式语言理论等，不注重软件开发技术的研究，用户要求的软件复杂性与软件技术解决复杂性的能力不相适应，它们之间的差距越来越大。(5)生产方式落后。软件仍然采用个体手工方式开发，根据个人习惯爱好工作，无章可循，无规范可依据，靠言传身教方式工作。(6)开发工具落后，生产率提高缓慢。软件开发工具过于原始，没有出现高效率的开发工具，因而软件生产率低下。在1960~1980年期间，计算机硬件的生产由于采用计算机辅助设计、自动生产线等先进工具，使硬件生产纺提高了100万倍，而软件生产率只提高了2倍，相差十分悬殊。

1.1.4软件工程为了克服软件危机，人们从其他产业的工程化生产得到启示，于是在1968年北大西洋公约组织的工作会议上首先提出“软件工程”的概念，提出要用工程化的思想来开发软件。从此，软件生产进入了软件工程时代。

1.软件工程的定义软件工程是用科学知识和技术原理来定义、开发、维护软件的一门学科。该定义说明了软件工程是计算机科学中的一个分支，其主要思想是在软件生产中用工程化的方法代替传统手工方法。工程化的方法借用了传统的工程设计原理的基本思想，采用了若干科学的、现代化的方法技术来开发软件。这种工程化的思想贯穿到需求分析、设计、实现，直到维护的整个过程。

2.软件工程的性质软件工程是涉及计算机科学、工程科学、管理科学、数学等领域的一门综合性的交叉学科。计算机科学中的研究成果均可用于软件工程，但计算机科学着重于原理和理论，而软件工程着重于如何建造一个软件系统。软件工程要用工程科学中的观点来进行费用估算、制定进度、制定计划和方案；要用管理科学中的方法和原理进行软件生产的管理；要用数学的方法建立软件开发中的各种模型和各种算法，如可靠性模型，明用户需求的形式化模型等。3.软件工程的目标软件工程是一门工程性学科，目的是成功地建造一个大型软件系统。所谓成功，是要达到以下几个目标：付出较低的开发成本；达到要求的软件功能；取得较好的软件性能；开发的软件易于移植；需要较低的维护费用；能按进完成开发任务，及进交付使用；开发的软件可靠性高。

4.软件工程的内容软件工程研究的主要内容是指软件开发技术和软件开发管理两个方面。在软件开发技术中，它主要研究软件开发方法、软件开发过程、软件开发工具和环境。在软件开发管理中，它主要是研究软件管理学、软件经济学和软件心理学等。

5.软件工程面临的问题软件工程有许多需要解决的棘手问题，如软件费用、件可靠性、软件可维护性、软件生产率和软件重用等。1)软件费用由于软件生产基本上仍处于手工状态，软件是知识高度密集的技术的综合产物，人力资源远远不能适应这种迅速增长的软件社会要求，所以软件费用上升的势头必然还将继续下去。2)软件可靠性软件可靠性是指软件系统能否在既定的环境条件下运行燕实现所期望的结果。在软件开发中，通常要花费40%的代价进行测试和排错，即使这样还不能保证以后不再发生错误，为了提高软件可靠性，就要付出足够的代价。3)软件可维护性统计数据表明，软件的维护费用占整个软件系统费用的2/3，而软件开发费用只占1/3。软件维护之所以有如此大的花费，是因为已经运行的软件还需排除隐含的错误，新增加的功能要加入进去，维护工作又是非常困难的，效率又是非常低下的。因此，如何提高软件的可维护性，减少软件维护的工作量，也是软件工程面临的主要问题之一。4)软件生产率计算机的广泛应用使得软件的需求量大幅度上升，而软件的生产又处于手工开发的状态，软件生产率低下，使得各国都感到软件开发人员不足。这种趋势将仍旧继续下去。所以，如何提高软件生产率，是软件工程又一重要问题。5)软件重用提高软件的重用性，对于提高软件生产率、降低软件成本有着重要意义。当前的软件开发存在着大量的、重复的劳动，耗费了不少的人力资源。软件的重用有各种级别，软件规格说明、软件模块、软件代软件文档等都可以是软件重用的单位。软件重用是软件工程中的一个重要研究课题，软件重用的理论和技术至今尚未彻底解决。1.2软件工程过程和软件生存周期

1.2.1软件工程过程软件工程过程规定了获取、供应、开发、操作和维护软件时，要实施的过程、活动和任务。其目的是为各种人员提供一个公共的框架，以便用相同的语言进行交流。这个框架由几个重要过程组成，这些主要过程含有用来获取、供应、开发、操作和维护软件所用的基本的、一致的要求。该框架还用来控制和管理软件的过程。各种组织和开发机构可以根据具体情况进行选择和剪裁，可在一个机构的内部或外部实施。软件工程过程没有规定一个特定的生存周期模型或软件开发方法，各软件开发机构可为其开发项目选择一种生存周期模型，并将软件工程过程所含的过程、活动和任务映射到该模型中。也可以选择和使用软件开发方法来执行适合于其软件项目的活动和任务。软件工程过程包含如下7个过程。

1.获取过程获取过程为需方按合同获取一个系统、软件产品或服务的活动。

2.供应过程供应过程为供方向需方提供合同中的系统、软件产品或服务所需的活动。

3.开发过程开发过程为开发者和机构为了定义和开发软件或服务所需的活动。引过程包括需求分析、设计、编码、集成、测试、软件安装和验收等活动。

4.操作过程操作过程为操作者和机构为了在规定的运行环境中为其用户运行一个计算机系统所需要的活动。

5.维护过程维护过程为维护者和机构为了管理软件的修改，使它处于良好运行状态所需要的活动。

6.管理过程管理过程为软件工程过程中各项管理活动，包括项目开始和范围定义；项目管理计划；实施和控制，评审和评价；项目完成。

7.支持过程支持过程对项目的生存周期过程给予支持。它有助于项目的成功并能提高项目的质量。1.2.2软件生存周期软件生存周期是借用工程中产品生存周期的概念而得来的。引入软件生存周期概念，对于软件生产的管理、进度控制有着非常重要的意义，可使软件生产有相应的模式、相应的流程、相应的工序和步骤。软件生存周期是指一个软件从提出开发要求开始直到该软件报废为止的整个时期。把整个生存周期划分为若干阶段，使得每个阶段有明确的任务，把规模大、结构复杂和管理复杂的软件开发变得容易控制和管理。软件生存周期的各阶段有不同的划分。软件规模、种类、开发方式、开发环境以及开发使用的方法都影响软件生存周期的划分。在划分软件生存周期的阶段时，应遵循的基本原则是各阶段的任务应尽可能相对独立，同一阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂程度，简化不同阶段之间的联系，有利于软件项目开发的组织管理。通常，软件生存周期包括可行性分析和项目开发计划、需求分析、概要设计、详细设计、编码、测试、维护等活动，可以将这些活动以适当方式分配到不同阶段去完成。

1.可行性分析和项目开发计划可行性分析和项目开发计划阶段必须要回答的问题是“要解决的问题是什么”。该问题有行得通的解决办法码?若有解决问题的办法，则需要多少费用?需要多少资源?需要多少时间?要回答这些问题，就要进行问题定义、可行性分析，制定项目开发计划。用户提出一个软件开发要求后，系统分析员首先要解决该软件项目的性质是什么，它是数据处理问题还是实时控制问题，它是科学计算问题还是人工智能问题等。还要明确该项目的目标是什么，该项目的规模如何等。通过系统分析员对用户和使用部门负责人的访问和调查、开会讨论，就可解决这些问题。在清楚了问题的性质、目标、规模后，还要确定该问题有没有行得通的解决办法。系统分析员要进行压缩和简化的需求分析和设计，也就是在高层次上进行分析和设计，探索这个问题是否值得去解决，是否有可行的解决办法。最后要提交可行性研究报告。经过可行性分析后，确定该问题值得去解决，然后制定项目开发计划。根据开发项目的目标、功能、性能及规模，估计项目需要的资源，即需要的计算机硬件资源，需要的软件开发工具和应用软件包，需要的开发人员数目及层次。还要对软件开发费用作出仨算，对开发进芳作出估计，制定完成开发任务的实施计划。最后，将项目开发计算和可行笥分析报告一起提交管理部门审查。2.需求分析需求分析阶段的任务不是具体地解决问题，而是准确地确定“软件系统必须做什么?，确定软件系统必须具备哪些功能。用户了解他们所面对的问题，知道必须做什么，但是通常不能完整、准确地表达出来，也不知道怎样用计算机解决他们的问题。而软件开发人员虽然知道怎样用软件完成人们提出的各种功能要求，但是，对用户的具体业务和需求不完全清楚，这是需求分析阶段的困难所在。系统分析员要和用户密切配合，充分交流各自的理解，充分理解用户的业务流程，完整、全面地收集、分析用户业务中的信息和处理，从中分析出用户要求的功能和性能，完整、准确地表达出来。这一阶段要给出软件需求说明书。

3.概要设计在概要设计阶段，开发人员要把确定的各项功能需求转换成需要的体系结构，在该体系结构中，每个成分都是意义明确的模块，即每个模块都和某些功能需求相对应。因此，概要设计就是设计软件的结构，该结构由哪些模块组成，这些模块的层次结构是怎样的，这些模块的调用关系是怎样的，每个模块的功能是什么。同时还要设计该项目的应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系等。

4.详细设计详细设计阶段就是为每个模块完整的功能进行具体描述，要把功能描述转变为精确的、结构化的过程描述。即该模块的控制结构是怎样的，先做什么，后做什么，有什么样的条件判定，有些什么重复处理等，并用相应的表示工具把这些控制结构表示出来。

5.编码编码编码阶段就是把每个模块的控制结构转换成计算机可接受的程序代码，即写成以某特定程序设计语言表示的“源程序清单”。当然，写出的程序应是结构好，清晰易读，并且与设计相一致。

6.测试则试是保证软件质理的重要手段，其主要方式是在设计测试用例的基础上检验软件的各个组成部分。测试分为模块测试、组装测试、确认测试。模块测试是查找各模块在功能和结构上存在的问题。组装测试是将各模块按一定顺序组装起来进行的测试，主要是查找各模块之间接口上存在的问题。确认测试是按说明书上的功能逐项进行的，发现不满足用户需求的问题，决定开发的软件是否合格、能否交付用户使用等。

7.维护软件维护是软件生存周期中时间最长的阶段。已交付的软件投入正式使用后，便进入软件维护阶段，它可以持续几年甚至几十年。软件运行过程中可能由于各方面的原因，需要对它进行修改。其原因可能是运行中发现了软件隐含的错误而需要修改；也可能是为了适应变化了的软件工作环境而需要做行之有效当变更；也可能是因为用户业务发生变化而需要扩充和增强软件的功能等。以上划分的7个阶段是在GB8567中规定的。在大部分文献中将生存周期划分为5个阶段，即要求定义、设计、编码、测试及维护。其中，要求定义阶段包括可行性研究和项目开发计划、需求分析，设计阶段包括概要设计和详细设计。1.3软件生存周期模型1.3.1软件生存周期模型的概念模型是为了理解事物而对事物作出的一种抽象，它忽略了不必要的细节，是事物的一种抽象形式、一个规划、一个程式软件生存周期模型是描述软件开发过程中各种活动如何执行的模型。一个强有力的软件生存周期模型对软件开发提供了强有力的支持，为软件开发过程中所有活动提供了统一的政策保证，为参与软件开发的所有成员提供帮助和指导。它揭示了如何演绎软件过程的思想，软件生存周期模型化技术的基础，也是建立软件开发环境的核心。软件生存周期模型确立了软件开发和演绎中各阶段的次序限制以及各阶段活动的准则，确立开发过程所遵守的规定和限制，便于各种活动的协调以及各种人员的有效通信，有利于活动重用和活动管理。软件生存周期模型能表示各种活动的实际工作方式，各种活动间的同步和制约关系，以及活动的动态特性。生存周期模型应该容易为软件开发过程中的各类人员所理解，它应该适应不同的软件项目，具有较强的灵活性，以及支持软件开发环境的建立。目前有若干种软件生存周期模型，如瀑布模型、增量模型、螺施模型、喷泉模型、变换模型和基于知识的模型等。

1.3.2瀑布模型瀑布模型是将近软件生存周期各活动规定为依线性顺序联接的若干阶段的模型。它包括可行性分析、项目开发计划、需求分析、概要设计、详细设计、编码、测试和维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水，逐级下落。瀑布模型为软件开发提供了一种有效的管理模型。根据这一模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段的效地对整个开发过程进行指导。因此它是以文档作为驱动、适合于需求很明确的软件项目开发的模型。

1.模型表示瀑布模型如图1.1所示。该模型说明整个软件开发过程是按图中5个阶段进行的。每个阶段的任务完成之后，产生右边相应的文档(图中只列出该阶段最主要的文档)，这些文档经过确认，表明该阶段工作完成，并进入下一阶段的工作。每个阶段均以上一阶段的文档作为开发的基础，如果某一文档出现问题，则要返回到上一阶段去重新进行工作。

2.瀑布模型的特点瀑布模型严格按照生存周期各个阶段的目标、任务、文档和要求来进行开发。它强调了每一阶段的严格性，尤其是开发前期的良好需求说明，这样，就能解决在开发阶段后期修正不完善的需求说明将花费巨大的费用的问题。图1.1瀑布模型于是人们需付出极大的努力来加强各阶段活动的严格性，特别是要求定义阶段，希望得到完整、准确、无二义性的需求说明，以减少后面各阶段不易估量的浪费。在传统的观念中，人们认为只要认真努力，总可以通过详尽分析来确定完整、准确的需求说明，从而明确系统的各种需求，只要采用一套严格规定的术语及表达方式，就一定可以准确清楚地表达和通讯，以便在严格的开发管理下得到完美的结果。在这种严格定义的模型中，开发人员试图在每一活动过程结束后，通过严格的阶段性复审与确认，得到该阶段的一致、完整、准确和无二义性的良好文档，以“冻结”这些文档为该阶段结束的标志，保持不变，作为下一阶段活动的唯一基础，从而形成一个理想的线性开发序列，以每一步的正确性和完整性来保证最终系统的质量。瀑布模型是以文档形式驱动的，为合同双方最终确认产品规定了蓝本，为管理者进行项目开发管理提供了基础，为开发过程施加了“政策”或纪律限制，约束了开发过程中的活动。瀑布模型以里程碑开发原则为基础，提供各阶段的检查点，确保用户需求，满足预算和时间限制。瀑布模型是一种整体开发模型，在开发过程中，用户看不见系统是什么样，只有开发完成向用户提交整个系统时，用户就能看到一个完整的系统。瀑布模型适合于功能和性能明确、完整、无重大变化的软件开发。大部分的系统软件就具有这些特征，例如编译系统、数据库管理系统和操作系统等。在开发前均可完整、准确、一致和无二义性地定义其目标、功能和性能等。

3.瀑布模型的局限性对于当前的大型软件项目，特别是应用软件项目，在开发前期用户常常对系统只有一个模糊的想法，很难明确确定和表达对系统的全面要求。经过详细的要求定义，尽管可得到一份较好的需求说明，但却很难期望该需求说明能将系统的一切都描述得完整、准确、一致并与实际环境相符，很难通过它在逻辑上推断出系统的运行效果，并以此达到各类人员对系统的共同理解。因此，要保证每个阶段特别是定义阶段是正确的、完整的。这是属于理想情况，实际上是做不到或很难做到的。由于知识背景的不同，工作中的疏漏和通讯媒介的局限性，使通讯中的误解无法避免；随着项目向胶推进，用户会产生新的要求，或因环境变化希望系统也能随之变化。开发者也可能在设计中遇到某些未曾预料的实际困难，希望在需求中有所权衡。这些都成为进行严格线笥开发的重大障碍，尽管通过加强复审与确认、全面测试和设立维护阶段来缓解上述困难，但均未在根本上解决这些问题。作为整体开发的瀑布模型，由于不支持软件产品的演化，对开发过程中的一些很难发现的错误只有在最终产品运行时才能发现。瀑布模型缺乏对付变化的机制，所以最终产品将难以维护。20多年来瀑布模型得到了广泛的应用。它在消除非结构化软件、软件软件的复杂性、促进软件开发工程化方面起了很大作用。但是，瀑布模型在大量的软件开发实践中也逐渐暴露出它的严重缺点。它是一种理想的线性开发模式，缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。这些缺点对软件开发带来了严重影响，最终可能导致开发出的软件并不是用户真正需要的软件，并且这一点在开发过程完成后才能发现，已为时太晚。针对这些情况，无疑需要进行返工，或者在运行中进行大理修改。不管是返工或进行大量修改都必须付出巨大的代价，给软件开发带来不必要的损失。同时，随着软件开发项目的规模日益扩大，瀑布模型缺乏灵活性的缺点引发的问题更为严重。为克服瀑布模型的不足，现在已提出若干其他模型瀑布模型各阶段的任务、内容、方法、技术和文档见第2~6章。

1.3.3增量模型瀑布模型是一种整体开发模型。在开发过程中，用户看不到软件是什么样子，只有开发完成后，整个软件才全部展现现在用户面前。这时如果用户发现有不满意的地方，为时已晚。增量模型是一种非整体开发的模型。软件在该模型中是“逐渐”开发出来的，开发出一部分，向用户展示一部分，可让用户及早看到部分软件，及早发现问题。或者先开发一个“原型”软件，完成部分主要功能，展示给用户并征求意见，然后逐步完善，最终获得满意的软件产品。该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。增量模型的详细介绍见第7章。

1.3.4螺旋模型对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型与增量模型结合起来，加入了两种模型均忽略了的风险分析，弥补了这两种模型的不足。螺旋模型是一种风险驱动的模型。在软件开发中，有各种各样的风险。对于不同的软件项目，其开发风险有大有小。在制定项目开发计划时，分析员要明确项目的需求是什么，需要多少资源，如何安排开发进度等一系列问题。但是，要给出准确无误的回答是不容易的。分析员通常可凭借经验的估计而给出初步的设想，这难免会带来一定的风险。同样，在设计阶段，给出的设计方案是否能实现用户的功能，也会具有一定风险。实践表明，项目越复杂，设计方案、资源、成本和进芳等因素的不确定性越大，项目开发的风险也越大。因此，应及进对风险进行识别、分析和采取对策，从而消除或关系少风险的危害。螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。每个螺旋周期可分为4个工作步骤。第一，制定计划，即确定目标，选定实施方案，明确开发限制条件；第二，风险分析，即分析所选方案，识别风险，通过原型消除风险；第三，开发实施，即实施软件开发；第四，用户评估，即评价开发工作，提出修改意见，建立下一个周期的计划。螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。每个螺旋周期可分为4个工作步骤。第一，制定计划，即确定目标，选定实施方案，明确开发限制条件；第二，风险分析，即分析所选方案，识别风险，通过原型消除风险；第三，开发实施，即实施软件开发；第四，用户评估，即评价开发工作，提出修改意见，建立下一个周期的计划。螺旋模型适合于大型软件的开发，它吸收了软件工程“演化”的概念，使得开发人员和用户对每个螺旋周期出现的风险有所了解，从而作出相应的反应。但是，使用该模型需要有相录丰富的风险评估经验和专门知识，这使该模型的应用受到一定限制。螺旋模型的表示如图1.2所示。图1.2螺旋模在图1.2中，半径的大小代表了完成现在步骤所需的费用累加。螺旋角度的大小代表了完成螺旋的每次循环需做的工作，模型反映了一个重要的概念，即每一次循包含一次进展，该进展对产品的每一部分及每一级改进指出了从用户需求文档至每一单独程序的编程步骤的相同次序。

1.螺旋周期1)用户概念这一周期是用户概念级的需求，也是粗线条的、概要的需求和未经开发者进行分析的需求。2)软件需求这一周期定义不确定因素。这些不确定因素是项目风险的重要来源。若是如此，则要制定风险的费用效率策略。这可能涉及快速原型及其他方法的结合，一旦涉及不确定因素风险被评估，下一步工作将由遗留的有关风险来确定。3)软件设计这一周期以性能和用户接口风险为主，采用演化开发技术，即采用原型化模型来解决风险。若这个原型是可运行的、健壮的，则可作为下一步产品演化的基础，那么紧接着的风险驱动就是一系列的原型演化，这就使得项目只完成螺旋模型所有可能步骤的一个子集。4)软件实现这一周期以程序开发或接口控制风险占主导地位，下面将遵循基本的瀑布模型进行开发。

2.螺旋周期的步骤1)确定目标、方案和限制条件确定软件产品各部分的目标，如性能、功能和适应变化的能力等；确定软件产品各部分实现的各种方案，选择如A设计、B设计、软件重用和购买等；确定不同方案的限制条件，如成本、规模、接口调度、资源分析和时间表安排等。2)评估方案、标识风险和解决风险对各个不同实现方案进行评估，对出现的不确定因素进行风险分析，提出解决风险的策略，建立相应的原型。若原型是可运行的、健壮的，则可作为下一步产品演化的基础。螺旋模型的风险驱动中，解决风险可采用面向说明书、面向原型、面向模拟法和面向自动转换的方法。在这种情况下，通过相庆的程序风险大小及不同方法效率的分析来选择合适的配合策略。类似地，风险管理分析能决定投入其余工程活动的时间和工作量，如计划、轮廓管理、质量保证、正式确认和测试等。3)开发确认产品若以前的原型已解决了所有性能和用户接口风险，而且占主要位置的是程序开发和接口控制风险，那么接下来的应是采用瀑布模型的方法，进行用户需求、软件需求、软件设计和软件实现等。同时要对其作适当修改，以适庆增量开发。也可选择原型，模拟原型，导致了步骤的不同子集的使用。4)计划下一周期工作对下一周期的软件需求、软件设计和软件实现进行计划；对部分产品进行增量开发；或者是由部分组织和个人开发软件的各个组成部分。可设想有一系列平行的螺旋循环，每一个螺旋循环对应一个组成部分，好像在图中加入第三维，即加若干重叠的螺旋平面，不同的螺旋平面对应于不同的软件组成部分，以有分别演化。与其他模型相似，在螺旋模型中每次循环都以评审结束，评审涉及产品的原来人员或组织，评审覆盖前次循环中开发的全部产品，包括下一次循环的计划以及实现它们的资源。评审的主要任务是确保所有有关部分以共同提交给下一阶段。

1.3.5喷泉模型喷泉模型是一种以用户需求为动力，以对象作为驱动的模型。它适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。系统某些部分常常重复工作多次，相关功能在每镒迭代中随之加入演化的系统。无间隙是指在分析、设计和实现等开发活动之间不存在明显的边界。喷泉模型的图形如图1.3所示。它以面向对象的软件开发方法学为基础，以用读书需求作为喷泉模型的源泉。其特点如下：(1)喷泉模型规定软件开发过程有4个阶段，即分析、系统设计、软件设计和实现。图1.3喷泉模型(2)喷泉模型的各阶段相互重叠，它反映了软件过程并行性的特点。(3)喷泉模型以分析为基础，资源消耗呈塔型，在分析阶段消耗的资源最多。(4)喷泉模型反映了软件过程迭代的自然特性，从高层返回低层无资源消耗。(5)喷泉模型强调增量开发，它依据分析一点，设计一点的原则，并不要求一个阶段的彻底完成，整个过程是一个迭代的逐步提炼的过程。(6)喷泉模型是对象驱动的过程，对象是所有活动作用的实体，也是项目管理的基本内容。

1.3.6基于知识的模型基于知识的模型又称智能模型，它把瀑布模型和专家系统结合在一起。该模型在开发的各个阶段上都利用了相应的专家系统来帮助软件人员完成开发工作，使维护在系统需求说明一级上进行。为此，建立了各阶段所需要的知识库，将模型、相应领域知识和软件工程知识分别存入数据库，以软件工程知识为基础的生成规则构成的专家系统与含有应用领域知识规则的其他专家系统相结合，构成了该应用领域的开发系统。

1.模型表示基于知识模型的表示如图1.4所示。该模型基于瀑布模型，在各阶段都有相应的专家系统支持。图1.4基于知识的模型1)支持需求活动的专家系统支持需求活动的专家系统用来帮助关系少需求活动中的二义性、不精确性和冲突易变的需求，这种专爱系统要使用应用领域的知识，要用到应用系统中的规则，建立应用领域的专家系统来支持需求活动。2)支持设计活动的专家系统支持设计活动的专家系统用于支持设计功能的CASE中的工具和文档的选择，这种专家系统要使用软件开发的知识。3)支持测试活动的专家系统支持测试活动的专家系统用于支持测试自动化，利用基于知识的系统选择测试工具，生成测试数据，跟踪测试过程，分析测试结果。4)支持维护活动的专家系统支持维护活动的专家系统将维护变成新的应用开发过程的重复，运行可利用的基于知识的系统来进行维护。

3.特点知识模型以瀑布模型与专爱系统的综合应用为基础。该模型通过应用系统的知识和规则帮助设计者认识一个特定的软件的需求和设计，这些专家系统已成为开发过程的伙伴，并指导开发过程。将软件工程知识人特定领域分离出来，这些知识随着过程范例收入知识库，产生规则，在接受软件工程技术的基础上被编码成专家系统，用来辅助软件工程的开发。在使用过程中，软件工程专家系统与其他领域的应用知识的专家系统连接起来，形成了特定软件系统，为开发一个软件产品所应用。

4.优点知识模型的优点如下：(1)通过领域的专爱系统，可使需求说明更完整、准确和无二义性。(2)通过软件工程专爱系统，提供一个设计库支持，在开发过程中成为设计者的助手。(3)通过软件工程知识和特定应用领域的知识和规则的应用来提供开发的帮助。

5.缺点知识模型的缺点如下：(1)建立适合于软件设计的专家系统是非常困难的，超出了目前的能力，是今后软件工程的发展方向，要经过相当长的时间才能取得进展。(2)建立一个既适合软件工程又适合应用领域的知识库也是非常困难的。(3)目前的状况是在软件开发中正在应用AI技术，在CASE工具系统中使用专家系统，用专家系统来实现测试自动化，在软件开发的局部阶段有所进展。

1.3.7变换模型变换模型是一种适合于形式化开发方法的模型。从软件需求形式化说明开始，经过一系列变换，最终得到系统的目标程序。变换模型主要用于软件的形式化开发方法，一个形式化的软件开发方法要提供一套思维方法和描述开发手段，如规范描述的原则、程序开发的一般过程、描述语言等，使开发者能利用数学概念和表示方法恰当合理地构造形式规范，根据开发过程的框架及设计原则进行规范描述和系统化的设计，并对规范的性质和设计的步骤进行分析的验证。

1.模型表示变换模型的表示如图1.5所示。用于软件形式化开发方法的变换模型分为模型规范的建立和规范到实现开发的一系列变换过程。

2.开发过程10建立软件系统的模型规范将对实现环境和系统的功能需求进行分析，提象出与系统有磁的基本概念和固有属性，并以此为基础建立问题求解的抽象模型，称为模型抽象。它由相互联联的两部分组成，即表示抽象和运算抽象。2)表示抽象表示抽象是模型规范构造者在分析求解问题及其实现环境的基础上，对形成系统可观察属性的对象域及其组成元素的形式描述。图1.5变换模型3)运算抽象运算抽象是定义若干运算来模拟系统中可能发生的事件，即围绕表示抽象给出若干运算的规范描述。这种描述规定了运算所模拟的事件发生前后系统可观察属性的变化关系，即状态转换关系。4)变换过程当软件系统模型规范的构造完成之后，进一步开发满足规范的实现系统。程序开发过程应是设计和验证并行的多步精化过程，对开发的每一步，均要慎重考虑该步开发是否正确，发现问题及时解决。只有这样才能大大关不管开发费用，保证最终产品的质量和开发效率。从抽象模型规范(M0)开始的理想多步开发过程可表示为M0→M1→M2→…→Mn的变换，其中，Mi+1是Mi的实现模型，变换中的每一步的“强度”都影响到整个变换的强度，还要论证每个Mi+1是Mi的正确实现。这种开发过程中的证明推理是以诸模型的形式化为前提的，也是保证最终的实现系统(Mn)正确实现模型规范的必要阶段。5)变换的独立性这种多步变换过程的一个重要性质是每步变换对相关模型描述为“封闭的”，即每步变换的正确性仅与该步变换所依据的规范Mi以及对变换后的假设(如Mi+1)有关，变换步骤在这种意义下独立于其他变换步骤。假若没有这种独立性，就无法控制错误的恶性蔓延，而变换步骤的经验也就是一句空话。6)变换的设计变换的设计过程是一种“发明”的过程。在模型具体化的变换过程中，具体实现模型的设计是开发者的职责。目前还没有相当高级的规范能自动翻译成高效程序代码的工具，这种设计“发明”，是以开发者自己对正在设计中的系统的功能和使用环境的理解，是对实现效率及进一步开发的预测等程序设计经验以及对软件开发基本原则的理解为基础的。形式化开发方法仅提供给开发者一种严格有效的思维工具和描述工具，而不能代替开发者进行变换的“发明”。

3.特点变换模型的特点如下：(1)该模型只适合于软件的形式化开发方法。(2)必须有严格的数学理论和形式化技术支持。(3)缺乏相庆的支持工具，处于手工处理方式。(4)尚处于研究和实验阶段，离使用前景尚有一段距离。(5)对软件开发人员要求较高。1.4软件开发方法软件开发方法是一种使用早已定义好的技术集及符号表示习惯来组织软件生产过程的方法。其方法一般表述成一系列的步骤，每一步骤都与相应的技术和符号相关。软件开发的目标是在规定的投资和时间内，开发出符合用户需求的高质量的软件。为了达到此目的，需要有成功的开发方法。软件开发方法是克服软件危机的重要方面之一。在60年代，由于对软件开发方法重视不够，解决软件复杂性的能力不够，因而软件开发方法成为软件危机的原因之一。因此，自软件工程诞生以来，人们重视软件开发方法的研究，已经提出了多种软件开发方法和技术，对软件工程及软件产业的发展起到了不可估量的作用。

1.4.1结构化方法结构化方法由结构化分析、结构化设计和结构化程序设计构成。它是一种面向数据流的开发方法。该方法简单实用，应用较广，技术成熟。所谓结构化分析，就是根据分解与抽象的原则，按照系统中数据处理的流程，用数据流图来建立系统的功能模型，从而完成需求分析。所谓结构化设计，就是根据模块独立性准则、软件结构准则，将数据流图转换为软件的体系结构，用软件结构图来建立系统的物理模型，实现系统的概要设计的。所谓结构化程序设计，就是根据结构程序设计原理，将每个模块的功能用相应的标准控制结构表示出来，从而实现详细设计。结构化方法总的指导思想是自顶向下、逐步求精。它的基本原则是功能的分析与抽象。它是软件工程中最早出现的开发方法，特别适合于数据处理领域的问题。相庆的支持工具较多，发展较为成熟。结构化方法对于规模大的项目及特别复杂的项目不太适应，该方法难于解决软件重用问题，难于适应需求变化的问题，难于彻底解决维护问题。结构化方法的详细介绍见第8章。

1.4.2Jackson方法这是一种面向数据结构的开发方法。因为一个问题的数据结构与处理该问题数据结构的控制结构有着惊人的相似之处，该方法就是根据这一思想形成了最初的JSP(JacksonStructureProgramming)方法。该方法首先描述问题的输入、输出数据结构，分析其对应性，然后推出相应的程序结构，从而给出问题的软件过程描述。JSP方法是以数据结构为驱动的，适合于小规模的项目。当输入数据结构与输出数据结构无对应关系时，难于应用该方法。基于JSP方法的局限性，又发展了JSD(JacksonSystemDevelopment)方法，它是JSP方法的扩充。JSD方法是一个完整的系统开发方法。该方法首先建立现实世界的模型，再确定系统的功能需求，对需求的描述特别强调了操作之间的时序性，它以事件作为驱动，是一种基于进程的开发方法，应用于进序特点较强的系统，包括数据处理系统和一些实时控制系统。JSD方法对客观世界及其同软件之间的关系认识不完整，所确立的软件系统实现结构过于复杂，软件结构说明的描述采用第三代语言，这不利于软件开发才坚系统的理解及开发者之间的通信交流，这些缺陷在很大程度上限制了人们实际运用JSD方法的热情。Jackson方法的详细介绍见第9章。

1.4.3维也纳开发方法(VDM)维也纳开发方法(即VDM)，自70年代初提出以来，已形成一种对大型系统软件形式化开发的较有潜力的方法，在欧洲及北美有相当大的影响，到80年代已将它应用到工程开发上。VDM是在1969年为开发PL/1语言时，由IBM公司维也纳实验室的研究小组提出的，当时成员有HansBekic,PeterLucas,DinesBjφrner,CliffB.Jones和W.Henhapl等。当时遇到的问题是如何对大型高级语言尽快用形式化说明来开发编译系统，使语法、语义的定义更严密、更系统化。从软件系统最高一级抽象到最终目标代码生成，每一步都给出形式化说明。VDM是一种形式化的开发方法，软件的需求用严格的形式语言描述，把描述模型逐步变换成目标系统。VDM方法是从VDL的基础上扩充而来的，VDL是在牛津大学的指称语义概念基础上应用于编译而形成的操作语义方法。而VDM是在这基础上考虑更面向工程而形成的指称语义方法，当时用它来形式定义PL/1的一个真子集。VDM是一个基于模型的方法，它的主要思想是：将软件系统当作模型来给予描述，具体说就是把软件的输入/输出看作模型对象，而这些对象在计算机仙的状态可看作为该模型在对象上的操作。VDM从抽象说明开始，对软件系统功能条件给出定义，对其输入/输出用不同的数学域进行分灰定义，这称为语法域说明。具体说明对象的真正含义，称为语言域说明。对系统在计算机内状态进行描述，称为加工函数(或语义函数)。前面的语义域和语法域都是用数学的域方程表