《《软件工程基础》第2章-软件开发过程课件.ppt》由会员分享，可在线阅读，更多相关《《软件工程基础》第2章-软件开发过程课件.ppt（37页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、1第2章 软件开发过程2.1 软件过程2.2 常见的软件过程模型2.3 软件过程的新发展2第2章 软件开发过程n2.1 软件过程软件过程q2.1.1 软件过程的概念与理论基础软件过程的概念与理论基础q2.1.2 软件过程讨论的主要内容软件过程讨论的主要内容n2.2 常见的软件过程模型常见的软件过程模型n2.3 软件过程的新发展软件过程的新发展32.1.1 软件过程的概念与理论基础n软件过程的概念软件过程的概念n软件过程模型的理论基础软件过程模型的理论基础4软件过程的概念n软件过程是为了获得高质量软件所需要完成的一系软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的
2、工作步骤。列任务的框架，它规定了完成各项任务的工作步骤。n在完成开发任务时必须进行一系列开发活动，并且在完成开发任务时必须进行一系列开发活动，并且使用适当的资源，在过程结束时将把输入转化为输使用适当的资源，在过程结束时将把输入转化为输出。出。n因此，因此，ISO 9000把过程定义为把过程定义为“使用资源将输入转使用资源将输入转化为输出的活动所构成的系统。化为输出的活动所构成的系统。”q过程定义了运用方法的顺序、应该交付的文档资过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管料、为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的
3、理措施，以及标志软件开发各个阶段任务完成的里程碑。里程碑。5软件过程模型及理论基础n通常使用生命周期模型简洁地描述软件过程。通常使用生命周期模型简洁地描述软件过程。q建立软件开发过程模型的理论基础是软件生命周期理论和相关的建立软件开发过程模型的理论基础是软件生命周期理论和相关的软件工程原则，因此，软件过程模型又称软件生命周期模型软件工程原则，因此，软件过程模型又称软件生命周期模型（Software Life Cycle Model）q其核心思想主张把软件过程划分成若干个阶段，每个阶段所包含其核心思想主张把软件过程划分成若干个阶段，每个阶段所包含的活动内容和性质具有的活动内容和性质具有“高内聚，
4、低藕合高内聚，低藕合”的特征，这样有助于的特征，这样有助于简化问题、有助于验证阶段性的工作成果、有助于对软件工程的简化问题、有助于验证阶段性的工作成果、有助于对软件工程的施工与管理。施工与管理。 q生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。行顺序，因此，也称为过程模型。q软件过程模型是对软件开发活动进行有效地组织、协调、管理与软件过程模型是对软件开发活动进行有效地组织、协调、管理与控制的一种策略控制的一种策略q过程模型化是为了便于理解和操作。过程模型化是为了便于理解和操作。6Software L
5、ife Cycle Model72.1.2 软件过程讨论的主要内容n软件过程讨论的主要内容包括软件过程模型、项目软件过程软件过程讨论的主要内容包括软件过程模型、项目软件过程定义、软件过程裁剪、软件过程改进及软件能力成熟度的评定义、软件过程裁剪、软件过程改进及软件能力成熟度的评价等内容。价等内容。n软件过程模型给出了适合不同软件项目的软件过程活动组织软件过程模型给出了适合不同软件项目的软件过程活动组织的参考框架。对不同的软件组织来讲，典型软件过程模型仅的参考框架。对不同的软件组织来讲，典型软件过程模型仅仅是理论参考框架。为了不断提高软件能力，软件组织（企仅是理论参考框架。为了不断提高软件能力，软
6、件组织（企业与团队）应该不断积累经验，针对不同的软件项目和软件业与团队）应该不断积累经验，针对不同的软件项目和软件组织自身的特点，在软件过程定义、软件过程裁剪、软件过组织自身的特点，在软件过程定义、软件过程裁剪、软件过程改进等方面不断努力和提高。程改进等方面不断努力和提高。n软件能力成熟度模型（软件能力成熟度模型（CMM）是对一个软件组织的软件能力）是对一个软件组织的软件能力成熟度进行评价的框架模型，它同时对软件组织不断提高软成熟度进行评价的框架模型，它同时对软件组织不断提高软件能力具有的一定的促进作用。件能力具有的一定的促进作用。82.2 常见的软件过程模型n软件过程包括软件开发过程和软件维
7、护过程。软件过程包括软件开发过程和软件维护过程。n实践中，人们基于软件工程方法论和软件项目特点总结出实践中，人们基于软件工程方法论和软件项目特点总结出了不同的软件过程模型。了不同的软件过程模型。q好的过程模型吸收了成功的软件工程经验和有效的软件好的过程模型吸收了成功的软件工程经验和有效的软件工程原则，因此参考软件过程模型框架组织软件项目有工程原则，因此参考软件过程模型框架组织软件项目有利于提高工作效率、把握开发质量，总体上可以提高软利于提高工作效率、把握开发质量，总体上可以提高软件项目的成功率。件项目的成功率。q为获得高质量的软件产品，软件过程必须科学、有效。为获得高质量的软件产品，软件过程必
8、须科学、有效。没有一个适用于所有软件项目的任务集合。因此，科学、没有一个适用于所有软件项目的任务集合。因此，科学、有效的软件过程应该定义一组适合于所承担的项目特点有效的软件过程应该定义一组适合于所承担的项目特点的任务集合。的任务集合。q通常，一个任务集合包括一组软件工程任务、里程碑和通常，一个任务集合包括一组软件工程任务、里程碑和应该交付的产品。应该交付的产品。9典型的过程模型n实际的软件开发活动中，应该项目的特点来划分阶段，但是，实际的软件开发活动中，应该项目的特点来划分阶段，但是，下面讲述典型的软件过程模型时并不是针对某个特定项目讲的，下面讲述典型的软件过程模型时并不是针对某个特定项目讲的
9、，因此只能使用因此只能使用“通用的通用的”阶段划分方法。阶段划分方法。n由于瀑布模型与快速原型模型的主要区别是获取用户需求的方由于瀑布模型与快速原型模型的主要区别是获取用户需求的方法不同，因此，下面在介绍生命周期模型时把法不同，因此，下面在介绍生命周期模型时把“规格说明规格说明”作作为一个阶段独立出来。为一个阶段独立出来。n此外，问题定义和可行性研究的主要任务都是概括地了解用户此外，问题定义和可行性研究的主要任务都是概括地了解用户的需求，为了简洁地描述软件过程，把它们都归并到需求分析的需求，为了简洁地描述软件过程，把它们都归并到需求分析中去了。中去了。n同样，为了简洁起见，把总体设计和详细设计
10、合并在一起称为同样，为了简洁起见，把总体设计和详细设计合并在一起称为“设计设计”。101.4.1 瀑布模型n在在20世纪世纪80年代之前，瀑布模型一直是惟一被广泛采用的生命周期年代之前，瀑布模型一直是惟一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。传统软件模型，现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。工程方法学的软件过程，基本上可以用瀑布模型来描述。n图图1.2所示为传统的瀑布模型。按照传统的瀑布模型开发软件，有下所示为传统的瀑布模型。按照传统的瀑布模型开发软件，有下述的几个特点。述的几个特点。11图1
11、.2 传统的瀑布模型12n1. 阶段间具有顺序性和依赖性阶段间具有顺序性和依赖性n这个特点有两重含义：这个特点有两重含义： 必须等前一阶段的工作完成之后，才能开必须等前一阶段的工作完成之后，才能开始后一阶段的工作；始后一阶段的工作； 前一阶段的输出文档就是后一阶段的输入文前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。正确的结果。n2. 推迟实现的观点推迟实现的观点n对于规模较大的软件项目来说，往往编码开始得越早最终完成开发工对于规模较大的软件项目来说，往往编码开始得越早最
12、终完成开发工作所需要的时间反而越长。这是因为，前面阶段的工作没做或做得不作所需要的时间反而越长。这是因为，前面阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题，带来灾难性后果。无法弥补的问题，带来灾难性后果。13n瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。型，不涉及软
13、件的物理实现。n清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。照瀑布模型开发软件的一条重要的指导思想。n3. 质量保证的观点质量保证的观点n软件工程的基本目标是优质、高产。为了保证所开发的软件的质量，软件工程的基本目标是优质、高产。为了保证所开发的软件的质量，在瀑布模型的每个阶段都应坚持两个重要做法：在瀑布模型的每个阶段都应坚持两个重要做法：14n（1） 每个阶段都必须完成规定的文档，没有交出合格的文档就是没每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
14、完整、准确的合格文档不仅是软件开发时期各有完成该阶段的任务。完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。据。n（2） 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。事实上，越是早期阶段犯下的错误，暴露出来的时问题，改正错误。事实上，越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障改正错误所需付出的代价也越高。因此，及时审间就越晚，排除故障改正错误所需付出的代价也越高。因此，及时审查，是保证软件
15、质量，降低软件成本的重要措施。查，是保证软件质量，降低软件成本的重要措施。15n传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯错误。在设计阶段可能发现规格说明文档中的错误，而设计上的缺陷错误。在设计阶段可能发现规格说明文档中的错误，而设计上的缺陷或错误可能在实现过程中显现出来，在综合测试阶段将发现需求分析、或错误可能在实现过程中显现出来，在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。因此，实际的瀑布模型是带设计或编码阶段的许多错误。因此，实际的瀑布模型是带“反馈环反馈环”的，如图的，如图1.3所示（图中实线箭头
16、表示开发过程，虚线箭头表示维护所示（图中实线箭头表示开发过程，虚线箭头表示维护过程）。当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反过程）。当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。阶段的任务。16图1.3 实际的瀑布模型17n瀑布模型有许多优点：可强迫开发人员采用规范的方法（例如，结构瀑布模型有许多优点：可强迫开发人员采用规范的方法（例如，结构化技术）；化技术）； 严格地规定了每个阶段必须提交的文档；要求每个阶段严格地规定了每个阶段必须提交的文档
17、；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。交出的所有产品都必须经过质量保证小组的仔细验证。n各个阶段产生的文档是维护软件产品时必不可少的，没有文档的软件各个阶段产生的文档是维护软件产品时必不可少的，没有文档的软件几乎是不可能维护的。遵守瀑布模型的文档约束，将使软件维护变得几乎是不可能维护的。遵守瀑布模型的文档约束，将使软件维护变得比较容易一些。由于绝大部分软件预算都花费在软件维护上，因此，比较容易一些。由于绝大部分软件预算都花费在软件维护上，因此，使软件变得比较容易维护就能显著降低软件预算。可以说，瀑布模型使软件变得比较容易维护就能显著降低软件预算。可以说，瀑布模型的成功在
18、很大程度上是由于它基本上是一种文档驱动的模型。的成功在很大程度上是由于它基本上是一种文档驱动的模型。18n但是，但是，“瀑布模型是由文档驱动的瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。这个事实也是它的一个主要缺点。在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。但是，仅仅通过写在纸上的静态的规格说明，很难全面是什么样的。但是，仅仅通过写在纸上的静态的规格说明，很难全面正确地认识动态的软件产品。而且事实证明，一旦一个用户开始使用正确地认识动态的软件产品。而且事实证明，一旦一个用户开始使用一个软件，在他
19、的头脑中关于该软件应该做什么的想法就会或多或少一个软件，在他的头脑中关于该软件应该做什么的想法就会或多或少地发生变化，这就使得最初提出的需求变得不完全适用了。事实上，地发生变化，这就使得最初提出的需求变得不完全适用了。事实上，要求用户不经过实践就提出完整准确的需求，在许多情况下都是不切要求用户不经过实践就提出完整准确的需求，在许多情况下都是不切实际的。总之，由于瀑布模型几乎完全依赖于书面的规格说明，很可实际的。总之，由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。能导致最终开发出的软件产品不能真正满足用户的需要。191.4.2 快速原型模型n所谓
20、快速原型是快速建立起来的可以在计算机上运行的程序，所谓快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。它所能完成的功能往往是最终产品能完成的功能的一个子集。n如图如图1.4所示（图中实线箭头表示开发过程，虚线箭头表示所示（图中实线箭头表示开发过程，虚线箭头表示维护过程），快速原型模型的第一步是快速建立一个能反映维护过程），快速原型模型的第一步是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。实践来了解目标系统的概貌。20n通常，用户试用原型
21、系统之后会提出许多修改意见，开发人员按通常，用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用照用户的意见快速地修改原型系统，然后再次请用户试用一一旦用户认为这个原型系统确实能做他们所需要的工作，开发人员旦用户认为这个原型系统确实能做他们所需要的工作，开发人员便可据此书写规格说明文档，根据这份文档开发出的软件可以满便可据此书写规格说明文档，根据这份文档开发出的软件可以满足用户的真实需求。足用户的真实需求。n从图从图1.4可以看出，快速原型模型是不带反馈环的，这正是这种可以看出，快速原型模型是不带反馈环的，这正是这种过程模型的主要优点：过程模型的
22、主要优点： 软件产品的开发基本上是线性顺序进行软件产品的开发基本上是线性顺序进行的。能做到基本上线性顺序开发的主要原因如下：的。能做到基本上线性顺序开发的主要原因如下：21图1.4 快速原型模型22n（1） 原型系统已经通过与用户交互而得到验证，据此产生的规格原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。会因为发现了规格说明文档的错误而进行较大的返工。n（2） 开发人员通过建立原型系统已经学到了许多东西（至少知道开发人员通过建
23、立原型系统已经学到了许多东西（至少知道了了“系统不应该做什么，以及怎样不去做不该做的事情系统不应该做什么，以及怎样不去做不该做的事情”），因此，），因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。续阶段需要改正前面阶段所犯错误的可能性。n软件产品一旦交付给用户使用之后，维护便开始了。根据所需完成软件产品一旦交付给用户使用之后，维护便开始了。根据所需完成的维护工作种类的不同，可能需要返回到需求分析、规格说明、设的维护工作种类的不同，可能需要返回到需求分析、规格说明、设计或编码等不同阶
24、段，如图计或编码等不同阶段，如图1.4中虚线箭头所示。中虚线箭头所示。23n快速原型的本质是快速原型的本质是“快速快速”。开发人员应该尽可能快地建造出原。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。因此，是获知用户的真正需求，一旦需求确定了，原型将被抛弃。因此，原型系统的内部结构并不重要，重要的是，必须迅速地构建原型原型系统的内部结构并不重要，重要的是，必须迅速地构建原型然后根据用户意见迅速地修改原型。然后根据用户意见迅速地修改原型。UNIX S
25、hell和超文本都是广和超文本都是广泛使用的快速原型语言，最近的趋势是，广泛地使用第四代语言泛使用的快速原型语言，最近的趋势是，广泛地使用第四代语言（4GL）构建快速原型。）构建快速原型。n当快速原型的某个部分是利用软件工具由计算机自动生成的时候，当快速原型的某个部分是利用软件工具由计算机自动生成的时候，可以把这部分用到最终的软件产品中。可以把这部分用到最终的软件产品中。241.4.3 增量模型n增量模型也称为渐增模型，如图增量模型也称为渐增模型，如图1.5所示。使用增量模型开发所示。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集软件时，把软件产品作为一系列的增量构件来
26、设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。第二个增量构件提供更完件的基本需求，提供最核心的功能。第二个增量构件提供更完善的编辑和文档生成功能；第三个增量构件实现拼写和语法检善的编辑和文档生成功能；第三个增量构件实现拼写和语法检查功能；第四个增量构件完成高级的页面排版功能。查功能；第四个增量构件完成高级的页面排版功能。25n把软件产品分解成增量构件时，应该使构件的规模适中，规把软
27、件产品分解成增量构件时，应该使构件的规模适中，规模过大或过小都不好。最佳分解方法因软件产品特点和开发模过大或过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而异。分解时惟一必须遵守的约束条件是，当把人员的习惯而异。分解时惟一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形成的产品必须是可测试的。新构件集成到现有软件中时，所形成的产品必须是可测试的。n采用瀑布模型或快速原型模型开发软件时，目标都是一次就采用瀑布模型或快速原型模型开发软件时，目标都是一次就把一个满足所有需求的产品提交给用户。增量模型则与之相把一个满足所有需求的产品提交给用户。增量模型则与之相反，它分批地逐步向用户提交
28、产品，整个软件产品被分解成反，它分批地逐步向用户提交产品，整个软件产品被分解成许多个增量构件，开发人员一个构件接一个构件地向用户提许多个增量构件，开发人员一个构件接一个构件地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的交产品。从第一个构件交付之日起，用户就能做一些有用的工作。显然，能在较短时间内向用户提交可完成部分工作的工作。显然，能在较短时间内向用户提交可完成部分工作的产品，是增量模型的一个优点。产品，是增量模型的一个优点。26图1.5 增量模型27n增量模型的另一个优点是，逐步增加产品功能可以使用户有增量模型的另一个优点是，逐步增加产品功能可以使用户有较充裕的时间学习和适应
29、新产品，从而减少一个全新的软件较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。可能给客户组织带来的冲击。n使用增量模型的困难是，在把每个新的增量构件集成到现有使用增量模型的困难是，在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。但是，从长远观
30、点看，具有开软件体系结构必须是开放的。但是，从长远观点看，具有开放结构的软件拥有真正的优势，这样的软件的可维护性明显放结构的软件拥有真正的优势，这样的软件的可维护性明显好于封闭结构的软件。好于封闭结构的软件。28n因此，尽管采用增量模型比采用瀑布模型和快速原型模因此，尽管采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。如果一个设计非常灵活而且足够开维护阶段获得回报。如果一个设计非常灵活而且足够开放，足以支持增量模型，那么，这样的设计将允许在不放，足以支持增量模型，那么，这样的设计将允许在不破
31、坏产品的情况下进行维护。事实上，使用增量模型时破坏产品的情况下进行维护。事实上，使用增量模型时开发软件和扩充软件功能（完善性维护）并没有本质区开发软件和扩充软件功能（完善性维护）并没有本质区别，都是向现有产品中加入新构件的过程。别，都是向现有产品中加入新构件的过程。29n从某种意义上说，增量模型本身是自相矛盾的。它一方面要求开从某种意义上说，增量模型本身是自相矛盾的。它一方面要求开发人员把软件看作一个整体，另一方面又要求开发人员把软件看发人员把软件看作一个整体，另一方面又要求开发人员把软件看作构件序列，每个构件本质上都独立于另一个构件。除非开发人作构件序列，每个构件本质上都独立于另一个构件。除
32、非开发人员有足够的技术能力协调好这一明显的矛盾，否则用增量模型开员有足够的技术能力协调好这一明显的矛盾，否则用增量模型开发出的产品可能并不令人满意。发出的产品可能并不令人满意。30n图图1.5所示的增量模型表明，必须在开始实现各个构件之前就全部所示的增量模型表明，必须在开始实现各个构件之前就全部完成需求分析、规格说明和概要设计的工作。由于在开始构建第完成需求分析、规格说明和概要设计的工作。由于在开始构建第一个构件之前已经有了总体设计，因此风险较小。图一个构件之前已经有了总体设计，因此风险较小。图1.6描绘了一描绘了一种风险更大的增量模型：一旦确定了用户需求之后，就着手拟定种风险更大的增量模型：
33、一旦确定了用户需求之后，就着手拟定第一个构件的规格说明文档，完成后规格说明组将转向第二个构第一个构件的规格说明文档，完成后规格说明组将转向第二个构件的规格说明，与此同时设计组开始设计第一个构件件的规格说明，与此同时设计组开始设计第一个构件用这种用这种方式开发软件，不同的构件将并行地构建，因此有可能加快工程方式开发软件，不同的构件将并行地构建，因此有可能加快工程进度。但是，使用这种方法将冒构件无法集成到一起的风险，除进度。但是，使用这种方法将冒构件无法集成到一起的风险，除非密切地监控整个开发过程，否则整个工程可能毁于一旦。非密切地监控整个开发过程，否则整个工程可能毁于一旦。31图1.6 风险更大
34、的增量模型321.4.4 螺旋模型n软件风险是任何软件开发项目中都普遍存在的实际问题，项目软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。软件风险越大，软件越复杂，承担该项目所冒的风险也越大。软件风险可能在不同程度上损害软件开发过程和软件产品质量。因此，可能在不同程度上损害软件开发过程和软件产品质量。因此，在软件开发过程中必须及时识别和分析风险，并且采取适当措在软件开发过程中必须及时识别和分析风险，并且采取适当措施以消除或减少风险的危害。施以消除或减少风险的危害。33n构建原型是一种能使某些类型的风险降至最低的方法。正如构建原型是一种能使某些
35、类型的风险降至最低的方法。正如1.4.2节所述，为了降低交付给用户的产品不能满足用户需节所述，为了降低交付给用户的产品不能满足用户需要的风险，一种行之有效的方法是在需求分析阶段快速地构要的风险，一种行之有效的方法是在需求分析阶段快速地构建一个原型。在后续的阶段中也可以通过构造适当的原型来建一个原型。在后续的阶段中也可以通过构造适当的原型来降低某些技术风险。当然，原型并不能降低某些技术风险。当然，原型并不能“包治百病包治百病”，对于，对于某些类型的风险，原型方法是无能为力的。某些类型的风险，原型方法是无能为力的。n螺旋模型的基本思想是，使用原型及其他方法来尽量降低风螺旋模型的基本思想是，使用原型
36、及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看作在每个阶段险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型，如图之前都增加了风险分析过程的快速原型模型，如图1.7所示。所示。n完整的螺旋模型如图完整的螺旋模型如图1.8所示。所示。34图1.7 简化的螺旋模型35图1.8 完整的螺旋模型36n螺旋模型有许多优点：对可选方案和约束条件的强调有利螺旋模型有许多优点：对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试（浪费资金）或测试不足
37、一个重要目标；减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险；更重要的是，在螺旋模型（产品故障多）所带来的风险；更重要的是，在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。本质区别。n螺旋模型主要适用于内部开发的大规模软件项目。如果进螺旋模型主要适用于内部开发的大规模软件项目。如果进行风险分析的费用接近整个项目的经费预算，则风险分析行风险分析的费用接近整个项目的经费预算，则风险分析是不可行的。事实上，项目越大，风险也越大，因此，进是不可行的。事实上，项目越大，风险也越大，因此，进行风险分析的必要性也越大。此外，只有内部开发的项目，行风险分析的必要性也越大。此外，只有内部开发的项目，才能在风险过大时方便地中止项目。才能在风险过大时方便地中止项目。37n螺旋模型的主要优势在于，它是风险驱动的，但是，这也可能螺旋模型的主要优势在于，它是风险驱动的，但是，这也可能是它的一个弱点。除非软件开发人员具有丰富的风险评估经验是它的一个弱点。除非软件开发人员具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还认为一切正常。正在走向灾难时，开发人员可能还认为一切正常。