第一章：软件工程学概述

第一章：软件工程学概述

前言

最近刷到了软件工程相关的知识，觉得有必要重新学习一下，所以会逐章总结思维导图来协助学习。
百度网盘地址
文末有思维导图图片版

一、软件危机

1.软件危机的介绍

• (1)概念
  软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能运行的软件才具有的，实际上，几乎所有的软件都不同程度地存在这些问题。软件危机包含两方面的问题：
  ①如何开发软件，以满足对软件日益增长的需求
  ②如何维护数量不断膨胀的已有软件。
• (2)典型表现
  ①对软件开发成本和进度的估计不准确。实际成本比估计成本有可能高出一个数量级，实际进度比预期进度拖延几个月甚至几年的现象并不罕见。这种现象降低了软件开发组织的信誉。而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量，从而不可避免地会引起用户的不满。
  ②用户对“已完成的”软件系统不满意的现象经常发生。软件开发人员常常在对用户要求只有模糊的了解，甚至对所要解决的问题还没有确切认识的情况下，就匆忙着手编写程序。软件开发人员和用户之间的信息交流往往很不充分，"闭门造车"必然导致最终的产品不符合用户的实际需要。
  ③软件产品的质量往往靠不住。软件可靠性和质量保证的确切的定量概念刚刚出现不久，软件质量保证技术(审查、复审、程序正确性证明和测试)还没有坚持不懈地应用到软件开发的全过程中，这些都导致软件产品发生质量问题。
  ④软件常常是不可维护的。很多程序中的错误是非常难改正的，实际上不可能使这些程序适应新的硬件环境，也不能根据用户的需要在原有程序中增加一些新的功能。“可重用的软件”还是一个没有完全做到的、正在努力追求的目标，人们仍然在重复开发类似的或基本类似的软件。
  ⑤软件通常没有适当的文档资料。计算机软件不仅仅是程序，还应该有一整套文档资料。
  ⑥软件成本在计算机系统总成本中所占的比例逐年上升。由于微电子学技术的进步和生产自动化程度的不断提高，硬件成本逐年下降，然而软件开发需要大量人力，软件成本随着通货膨胀以及软件规模和数量的不断扩大而持续上升。
  ⑦软件开发跟不上计算机应用迅速普及深入的趋势。软件产品“供不应求”的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。

2.产生软件危机的原因

• (1)客观原因
  ①软件是计算机系统中的逻辑部件而不是物理部件。
  ②软件规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
• (2)主观原因
  ①对软件开发和维护有不少糊涂观念，采用了错误的方法和技术。
  ②存在与软件开发和维护有关的许多错误认识和做法。
  ③对用户要求没有完整准确的认识就匆忙着手编写程序。
  ④一个软件从定义、开发、使用和维护，直到最终被废弃，要经历一个漫长的时期。
  ⑤一个软件产品必须由一个完整的配置组成，主要包括程序、文档和数据等成分。
  ⑥在软件开发的不同阶段进行修改需要付出的代价是很不相同的。
  ⑦轻视维护是一个最大的错误。

3.消除软件危机的途径

• (1)应该对计算机软件有一个正确的认识。应该彻底消除在计算机系统早期发展阶段形成的“软件就是程序"的错误观念。软件是程序、数据及相关文档的完整集合。其中，程序是能够完成预定功能和性能的可执行的指令序列；数据是使程序能够适当地处理信息的数据结构；文档是开发、使用和维护程序所需要的图文资料。
  (2)应该充分认识到软件开发是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。必须充分吸取和借鉴人类长期以来从事各种工程项目所积累的行之有效的原理、概念、技术和方法，特别要吸取几十年来人类从事计算机硬件研究和开发的经验教训。
  (3)应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。
  (4)应该开发和使用更好的软件工具。在软件开发的每个阶段都有许多繁琐重复的工作需要做，在适当的软件工具辅助下，开发人员可以把这类工作做得既快又好。

二、软件工程

1.软件工程的介绍

• (1)概念
  软件工程是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
• (2)产生
  为了更有效地开发与维护软件，软件工作者在20世纪60年代后期开始认真研究消除软件危机的途径，从而逐渐形成了一门新兴的工程学科—计算机软件工程学(通常简称为“软件工程”)。
• (3)本质特征
  ①软件工程关注于大型程序的构造
  把一个人在较短时间内写出的程序称为小型程序，而把多人合作用时半年以上才写出的程序称为大型程序。传统的程序设计技术和工具是支持小型程序设计的，不能简单地把这些技术和工具用于开发大型程序。
  ②软件工程的中心课题是控制复杂性
  软件所解决的问题通常十分复杂，不得不把问题分解，使得分解出的每个部分是可理解的，而且各部分之间保持简单的通信关系。用这种方法并不能降低问题的整体复杂性，但是却可使它变成可以管理的。
  注意：许多软件的复杂性主要不是由问题的内在复杂性造成的，而是由必须处理的大量细节造成的。
  ③软件经常变化
  绝大多数软件都模拟了现实世界的某一部分。现实世界在不断变化，软件为了不被很快淘汰，必须随着所模拟的现实世界一起变化。因此，在软件系统交付使用后仍然需要耗费成本，而且在开发过程中必须考虑软件将来可能发生的变化。
  ④开发软件的效率非常重要
  社会对新应用系统的需求超过了人力资源所能提供的限度，软件供不应求的现象日益严重。软件工程的一个重要课题就是，寻求开发与维护软件的更好更有效的方法和工具。
  ⑤和谐地合作是开发软件的关键
  软件处理的问题十分庞大，必须多人协同工作才能解决这类问题。为了有效地合作，必须明确地规定每个人的责任和相互通信的方法，每个人还必须严格地按规定行事，纪律是成功地完成软件开发项目的一个关键。
  ⑥软件必须有效地支持它的用户
  开发软件的目的是支持用户的工作。软件提供的功能应该能有效地协助用户完成他们的工作。有效地支持用户意味着必须仔细地研究用户，以确定适当的功能需求、可用性要求及其他质量要求。还意味着软件开发不仅应该提交软件产品，而且应该写出用户手册和培训材料。
  ⑦软件工程领域由具有一种文化背景的人替具有另一种文化背景的人创造产品软件工程师是软件设计、软件体系结构、测试或统一建模语言等方面的专家，但他们不仅缺乏应用领域和文化领域的实际知识，还缺乏该领域的文化知识，这是软件开发项目出现问题的常见原因。

2.软件工程的基本原理

• (1)七条基本原理
  ①用分阶段的生命周期计划严格管理
  在软件开发与维护的漫长的生命周期中，需要完成许多性质各异的工作。应该把软件生命周期划分成若干个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受客户或上级人员的影响而擅自背离预定计划。
  ②坚持进行阶段评审
  由于大部分错误都是在编码之前造成的，并且错误发现与改正的越晚，所需付出的代价也越高，所以软件的质量保证工作不能等到编码阶段结束之后再进行。因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误，是一条必须遵循的重要原则。
  ③实行严格的产品控制
  当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。所谓基准配置又称为基线配置，它们是经过阶段评审后的软件配置成分。
  基准配置管理也称为变动控制，主要包括以下两个方面。
  a.一切有关修改软件的建议，特别是涉及对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。
  b.绝对不能谁想修改软件(包括尚在开发过程中的软件),就随意进行修改。
  ④采用现代程序设计技术
  采用先进的技术不仅可以提高软件开发和维护的效率，而且可以提高软件产品的质量。
  ⑤结果应能清楚地审查
  软件产品不同于一般的物理产品，它是看不见摸不着的逻辑产品。软件开发人员的工作进展情况可见性差，难以准确度量。为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。
  ⑥开发小组的人员应该少而精
  软件开发小组的组成人员的素质应该好，而人数则不宜过多。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件中的错误。
  ⑦承认不断改进软件工程实践的必要性
  为了保证软件开发与维护的过程能赶上时代前进的步伐，能跟上技术的不断进步，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。例如，收集进度和资源耗费数据，收集出错类型和问题报告数据等。
• (2)意义
  这七条原理是确保软件产品质量和开发效率的原理的最小集合。这七条原理是互相独立的，而且是缺一不可的最小集合，然而这七条原理又是相当完备的。

3.软件工程方法学

• (1)概念
  软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。通常把软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称为范型。目前使用得最广泛的软件工程方法学，分别是传统方法学和面向对象方法学。
• (2)三要素
  软件工程方法学包括3个要素：方法、工具和过程。
  ①方法：是完成软件开发的各项任务的技术方法，回答“怎样做”的问题。
  ②工具：是为运用方法而提供的自动的或半自动的软件工程支撑环境。
  ③过程：是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
• (3)传统方法学(生命周期方法学或结构化范型)
  ①定义
  采用结构化技术(结构化分析、结构化设计和结构化实现)来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。
  ②开发步骤
  开发软件时，传统方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务。具体如下。
  a.从对问题的抽象逻辑分析开始，一个阶段一个阶段地顺序进行开发。
  b.前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加了更多的实现细节。
  c.每一个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。
  d.在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和管理两个方面对这个阶段的开发成果进行检查，通过之后这个阶段才算结束；如果没通过检查，则必须进行必要的返工，而且返工后还要再经过审查。审查的一条主要标准就是每个阶段都应该交出和所开发的软件完全一致的高质量的文档资料，从而保证在软件开发工程结束时有一个完整准确的软件配置交付使用。
  ③优点
  a.把软件生命周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度；
  b.在软件生命周期的每个阶段都采用科学的管理技术和良好的技术方法，且在每个阶段结束之前都进行严格的审查，使得软件开发工程的全过程以一种有条不紊的方式进行，保证了软件的质量，特别是提高了软件的可维护性；
  c.采用生命周期方法学可以大大提高软件开发的成功率，软件开发的生产率也能明显提高。
  ④缺点
  a.当软件规模庞大，或者对软件的需求是模糊的或会随时间变化而变化的时候，传统方法学开发软件往往不成功。
  b.结构化范型技术要么面向行为，要么面向数据，没有既面向数据又面向行为的结构化技术，而软件系统本质上是信息处理系统。离开了操作便无法更改数据，而脱离了数据的操作是毫无意义的。数据和对数据的处理原本是密切相关的，把数据和操作人为地分离成两个独立的部分，自然会增加软件开发与维护的难度。
• (4)面向对象方法学
  ①定义
  面向对象方法把数据和行为看成是同等重要的，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。
  ②基本原则
  面向对象方法学的出发点和基本原则，是尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界、解决问题的方法与过程，从而使描述问题的问题空间与实现解法的解空间在结构上尽可能一致。
  ③要点
  a.把对象作为融合了数据及在数据上的操作行为的统一的软件构件
  面向对象程序是由对象组成的，程序中任何元素都是对象，复杂对象由比较简单的对象组合而成，用对象分解取代了传统方法的功能分解。
  b.把所有对象都划分成类
  每个类都定义了一组数据和一组操作，类是对具有相同数据和相同操作的一组相似对象的定义。数据用于表示对象的静态属性，是对象的状态信息，而施加于数据之上的操作用于实现对象的动态行为。
  c.继承性
  按照父类与子类的关系，把若干个相关类组成一个层次结构的系统。下层派生类自动拥有上层基类中定义的数据和操作，这种现象称为继承。
  d.对象彼此间仅能通过发送消息互相联系
  对象是数据处理的主体，必须向它发消息请求它执行它的某个操作以处理它的数据，不能从外界直接对它的数据进行处理，即对象的所有私有信息都被封装在该对象内，不能从外界直接访问，这就是通常所说的封装性。
  ④与传统方法学的对比
  a.传统方法学强调自顶向下顺序地完成软件开发的各阶段任务。
  b.用面向对象方法学开发软件的过程，是一个主动地多次反复迭代的演化过程。面向对象方法在概念和表示方法上的一致性，保证了在各项开发活动之间的平滑(即无缝)过渡。
  ⑤优点
  a.降低了软件产品的复杂性；
  b.提高了软件的可理解性；
  c.简化了软件的开发和维护工作；
  d.提高了软件的可重用性。

三、软件生命周期

软件生命周期由软件定义、软件开发和运行维护(也称为软件维护)3个时期组成，每个时期又进一步划分成若干个阶段。

1.组成

• (1)软件定义
  软件定义时期通常进一步划分成3个阶段，即问题定义、可行性研究和需求分析。这个时期的总任务是：
  ①确定软件开发工程必须完成的总目标；
  ②确定工程的可行性；
  ③导出实现工程目标应该采用的策略及系统必须完成的功能；
  ④估计完成该项工程需要的资源和成本，并且制定工程进度表。
• (2)软件开发
  通常由下述4个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。
• (3)运行和维护
  软件运行和维护的主要任务是使软件持久地满足用户的需要。出现下述三种情况的时候需要进行维护：
  ①当软件在使用过程中发现错误时应该加以改正；
  ②当环境改变时应该修改软件以适应新的环境；
  ③当用户有新要求时应该及时改进软件以满足用户的新需要。

2.软件生命周期各阶段的基本任务。

• (1)问题定义
  问题定义阶段必须回答的关键问题是：“要解决的问题是什么?”。通过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告，经过讨论和必要的修改之后这份报告应该得到客户的确认。
• (2)可行性研究
  可行性研究阶段要回答的关键问题是："对于上一个阶段所确定的问题有行得通的解决办法吗?"为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计过程。可行性研究阶段的任务是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。可行性研究的结果是客户作出是否继续进行这项工程的决定的重要依据，只有投资可能取得较大效益的那些工程项目才值得继续进行下去。
• (3)需求分析
  需求分析阶段的任务是准确地确定"为了解决这个问题，目标系统必须做什么",主要是确定目标系统必须具备哪些功能。系统分析员必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。用数据流图、数据字典和简要的算法表示系统的逻辑模型。这个阶段的一项重要任务，是用正式文档准确地记录对目标系统的需求，这份文档通常称为软件需求规格说明书(SRS)。
• (4)总体设计(概要设计)
  总体设计阶段必须回答的关键问题是： “应该怎样实现目标系统?”主要是设计出实现目标系统的几种可能的方案。软件工程师应该用适当的表达工具描述每种方案，分析每种方案，推荐一个最佳方案并制定出详细计划。另一项主要任务就是设计程序的体系结构，即确定程序由哪些模块组成以及模块间的关系。
• (5)详细设计(模块设计)
  详细设计阶段的任务就是把设计方案具体化，也就是回答："应该怎样具体地实现这个系统呢?"这个阶段的任务是设计出程序的详细规格说明。在这个阶段将详细地设计每个模块，确定实现模块功能所需要的具体算法和数据结构。
• (6)编码和单元测试
  编码和单元测试阶段的关键任务是写出正确的、容易理解的、容易维护的程序模块。程序员把详细设计的结果翻译成用选定的高级编程语言书写的程序，编写出的每一个模块，并对编写好的各个模块进行测试。
• (7)综合测试
  综合测试阶段的关键任务是通过各种类型的测试使软件达到预定的要求。最基本的测试是集成测试和验收测试。
  a.集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。
  b.验收测试则是按照软件需求规格说明书的规定，由用户对目标系统进行验收。
  通过对软件测试结果的分析可以预测软件的可靠性；根据对软件可靠性的要求，也可以决定测试和调试过程什么时候可以结束。应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，作为软件配置的一个组成部分。
• (8)软件维护
  维护阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。实质上维护过程是经历了一次压缩和简化了的软件定义和开发的全过程。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。
  通常有四类维护活动：
  ①改正性维护，即诊断和改正在使用过程中发现的软件错误；
  ②适应性维护，即修改软件以适应环境的变化；
  ③完善性维护，即根据用户的要求改进或扩充软件使它更完善；
  ④预防性维护，即修改软件，为将来的维护活动预先做准备。

四、软件过程

1.概念

• (1)定义
  软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。软件过程描述为了开发出客户需要的软件，什么人(who)、在什么时候(when)、做什么事(what)以及怎样(how)做这些事以实现某一个特定的具体目标。在完成开发任务时必须进行一些开发活动，并且使用适当的资源，在过程结束时将把输入转化为输出。
• (2)构成
  科学、有效的软件过程应该定义一组适合于所承担的项目特点的任务集合。一个任务集合包括一组软件工程任务、里程碑和应该交付的产品。
• (3)表示
  使用生命周期模型简洁地描述软件过程。生命周期模型(过程模型)规定了把生命周期划分成哪些阶段及各个阶段的执行顺序。

2.典型软件过程模型

• (1)瀑布模型
  在20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。

  • ①传统的瀑布模型
    a.定义
    传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述，如图1.2所示为传统的瀑布模型。
    b.特点
    第一，阶段间具有顺序性和依赖性
    必须等前一阶段的工作完成之后，才能开始后一阶段的工作；前一阶段的输出文档是后一阶段的输入文档，即只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
    第二，推迟实现的观点
    瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。
    第三，质量保证的观点
    为了保证所开发的软件的质量，在瀑布模型的每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障改正错误所需付出的代价也越高。因此，及时审查，是保证软件质量、降低软件成本的重要措施。每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

    • 图1.2 传统的瀑布模型
      

  • ②实际的瀑布模型
    a.定义
    在设计阶段可能发现规格说明文档中的错误，而设计上的缺陷或错误可能在实现过程中显现出来，在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。因此，实际的瀑布模型是带"反馈环"的，如图1.3所示(图中实线箭头表示开发过程，虚线箭头表示维护过程)。当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。
    b.优点
    第一，可强迫开发人员采用规范的方法；
    第二，严格地规定了每个阶段必须提交的文档；
    第三，要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证；
    第四，对文档的约束，使软件维护变得容易一些，且能降低软件预算。
    c.缺点
    “瀑布模型是由文档驱动的”是它的一个主要缺点。在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。但是，仅仅通过写在纸上的静态的规格说明，很难全面正确地认识动态的软件产品。由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。

    • 图1.3实际的瀑布模型
      

• (2)快速原型模型

  • ①定义
    快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。如图1.4所示(图中实线箭头表示开发过程，虚线箭头表示维护过程)。快速原型的本质是“快速”。UNIX Shell、超文本、第四代语言(4GL)都是广泛使用的快速原型语言。

    • 图1.4 快速原型模型
      

  • ②原理
    快速原型模型的第一步是快速建立一个能反映用户主要需求的原型系统，让用户通过实践来了解目标系统的概貌。通常，用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用，一旦用户认为这个原型系统确实能做他们所需要的工作，开发人员便可据此书写规格说明文档，
    根据这份文档开发出的软件便可以满足用户的真实需求。

  • ③优点
    快速原型模型是不带反馈环的，这正是这种过程模型的主要优点，即软件产品的开发基本上是线性顺序进行的。能基本上做到线性顺序开发的主要原因如下：
    a.原型系统已经通过与用户交互而得到验证，产生的规格说明文档正确地描述了用户需求。因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
    b.开发人员通过建立原型系统已经学到了许多东西。因此，在设计和编码阶段发生错误的可能性也比较小，减少了在后续阶段需要改正前面阶段所犯错误的可能性。

• (3)增量模型

  • ①定义
    增量模型也称为渐增模型，如图1.5所示。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。把软件产品分解成增量构件时，应该使构件的规模适中。分解时唯一必须遵守的约束条件是：当把新构件集成到现有软件中时，所形成的产品必须是可测试的。

    • 图1.5 增量模型
      

  • ②原理
    增量模型分批地逐步向用户提交产品，整个软件产品被分解成许多个增量构件，开发人员一个构件接一个构件地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。

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

  • ④技术难点
    a.在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，即软件体系结构必须是开放的。
    b.增量模型本身是自相矛盾的。它一方面要求开发人员把软件看作一个整体，另一方面又要求开发人员把软件看作构件序列，每个构件本质上都独立于另一个构件。

  • ⑤风险更大的增量模型
    图1.6是一种风险更大的增量模型。用这种方式开发软件，不同的构件将并行地构建，因此有可能加快工程进度。但是，这种方法将有构件无法集成到一起的风险，除非密切地监控整个开发过程，否则整个工程可能毁于一旦。

    • 图1.6 风险更大的增量模型
      

• (4)螺旋模型

  • ③应用
    螺旋模型主要适用于内部开发的大规模软件项目。如果进行风险分析的费用接近整个项目的经费预算，则风险分析是不可行的。事实上，项目越大，风险也越大，因此，进行风险分析的必要性也越大。此外，只有内部开发的项目，才能在风险过大时方便地中止项目。

• (5)喷泉模型

  • ①面向对象方法学
    这种方法在开发的早期阶段定义了一系列面向问题的对象，并且在整个开发过程中不断充实和扩充这些对象。分析阶段得到的对象模型也适用于设计阶段和实现阶段。整个开发过程都是"无缝"连接的，这就很容易实现各个开发步骤的多次反复迭代，达到认识的逐步深化。每次反复都会增加或明确一些目标系统的性质，但不是对先前工作结果的本质性改动，减少了不一致性，降低了出错的可能性。

  • ②原理
    图1.9所示的喷泉模型，是典型的面向对象的软件过程模型之一。“喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。图中代表不同阶段的圆圈相互重叠，表示两个活动之间存在交迭；而面向对象方法在概念和表示方法上的一致性，保证了在各项开发活动之间的无缝过渡。图中在一个阶段内的向下箭头代表该阶段内的迭代(或求精)。图中较小的圆圈代表维护，圆圈较小象征着采用了面向对象范型之后维护时间缩短了。

    • 图1.9 喷泉模型
      

  • ③要求
    为避免使用喷泉模型开发软件时开发过程过分无序，应该把一个线性过程作为总目标。同时也应该记住，面向对象范型本身要求经常对开发活动进行迭代或求精。

• (6)Rational统一过程

• (7)敏捷过程

• (8)极限编程