1.3 软件过程模型

软件作为产品需要一个循序渐进的生存过程，把软件产品从计划开始，经过开发、使用和维护等活动，直到退役为止的全过程称为软件生存周期（Software Life Cycle）。根据软件所处的状态、特征以及软件开发活动的目的，软件开发任务可以划分为不同的阶段，这些阶段之间的关系用开发模型表示。软件开发模型是软件开发过程的概括，为软件工程管理提供里程碑和进度表，为软件开发过程提供原则和方法。软件开发模型给出了软件开发活动各阶段之间的关系。软件过程模型是软件开发人员经过多年的探索形成的软件开发步骤和方法，针对应用特点，对开发过程归纳为开发过程框架。

1.3.1 瀑布模型

B.W.Boehm提出了瀑布模型（Waterfall Model），将软件开发过程划分为阶段，像瀑布一样拾阶而下，模型中各个阶段的任务和软件开发活动如图1-7所示。根据软件生存周期各个阶段的任务，瀑布模型从项目计划开始，逐步进行阶段性变换，直至通过测试并得到用户确认的软件产品为止。

通过瀑布模型框架结构可以看到一般软件系统的开发步骤分为3个阶段：计划阶段、开发阶段、维护阶段。

● 在计划阶段主要完成对系统可行性的论证，描述系统的定义、范围与系统实现的意义；

● 开发阶段分为4个步骤：系统需求分析、系统设计、系统实现、测试；

● 维护阶段完成系统在运行过程中所做的修改。

瀑布模型的特点是具有阶段的顺序性和依赖性，系统的实现过程遵循了阶段排列的次序，按次序完成每一个步骤，同时，步骤之间相互依赖，前一步获得的结果作为下一个步骤的输入，前一步骤完成后下一个步骤才能开始，如图1-8所示。

瀑布模型从软件制作时间上按工序把项目分为有序的步骤，实现了流水线的生产方式，便于分工协作，推迟了物理实现。

但是，另一方面也显示了瀑布模型的缺点：系统交付晚、纠错慢、难于克服系统分析员对应用领域不熟悉、用户不了解计算机及其与分析员相互之间的沟通问题、系统需求不明确、系统质量下降、难以满足用户需求的变更。

瀑布模型拥有简单的管理模型以及设计和实现分离的特征，系统鲁棒性（Robust）强、容易修改，适合于需求明确的大型系统开发和嵌入式系统的开发。

【例1-2】通常在大型软件项目开发时采用瀑布模型，具有需求明确、开发周期长的特点，并且基本上都是基于计算机的系统工程项目。如大型操作系统、数据库系统的开发，具有明确的开发目标和应用范围，特别是航空航天的宇宙飞船所需要的系统软件，具有长期的统筹规划安排，不同部门有计划地协调开发；而像金融、电信、保险等行业的软件系统依赖于硬件和外围设备，具有行业的特殊性。

1.3.2 进化式开发

1．原型模型

原型模型（Prototype Model）方式是开发人员根据用户提出的需求快速开发出的一种样本，它向用户展示了待开发软件系统的全部或部分功能和性能，通过原型系统与用户沟通，获得进一步的修改、完善和确认软件系统的需求，并达成一致的理解。基本的开发过程如图1-9所示。

2．原型开发的快速途径

原型开发给开发者和用户之间架起一道沟通的桥梁，用户能够感受到实际的系统，开发者又能够很快地建造出满足用户需求的可运行原型系统，并在此基础上利用已有的片断来尽快生成工作程序。因此，原型的实现可以采用开发者比较熟悉的语言、开发环境来尽快构造原型，并可利用原型系统进一步形成最终系统。一般有以下两种方式：

（1）抛弃式原型。很多时候对原型的开发，只是为了更好地与用户沟通，通过可运行的原型系统直接寻求一致的理解，往往在实现原型时采用比较熟悉的语言进行开发，没有过多考虑今后系统运行环境的要求，致使原型系统很难满足实际系统的性能要求。因此，在达到一致的理解之后，抛弃原型系统，重新设计系统，并针对实际系统的性能要求采用合适的语言、开发环境，实现最终系统。

（2）进化式原型。为避免原型系统开发之后又需要一段时间的分析、设计与实现，也有的系统实现采用完善原型系统的方式，进一步扩展原型系统的功能和性能，并适应实际系统的运行环境要求。

比较以上两种系统的实现途径，可以了解到原型系统有利于满足用户需求，但同时在最终系统实现方面又会有不同的影响。采用抛弃式原型会造成时间的拖延和成本的增加，用户很难理解为什么要抛弃原型，认为原型就可以成为最终系统；而采用进化式原型方式，往往在完善原型系统时，其他部分会将就原型系统中已有的部分，造成系统结构不合理，很难进行今后的维护工作。

3．原型开发的特点与应用方面

原型开发模型有内在的特点，着重突出一个“快”字，使得用户可以很快地看到他们所期望的计算机系统，对用户来说，最终系统是可以看得见、摸得着的，并能够很好地与开发者有具体的实物作为依据进行点评，因此，原型模型一直是开发者使用的模型。在应用领域方面，主要侧重在小型系统开发方面，可以利用原型系统先开发需求不明确的部分，或者是系统的核心部分，并且可以采用进化式原型方式完善原型系统，获得最终系统。另一方面，对大型系统来说，更多地利用原型系统与用户沟通来获得系统界面的一致性，开发人员对最终系统的运行界面难以确定，而且不能根据设计者的喜好设计系统界面，应该由应用领域的约定、用户的习惯、运行环境等因素决定，所以，采用抛弃式原型方式设计系统界面，可以获得用户满意的最终系统。

【例1-3】一般原型模型应用在大型系统的用户界面开发，需要与用户沟通，通过原型的修正可以不断获取用户在系统使用方面的需求，同时也有利于用户尽快掌握和使用系统；运用原型模型，有时是分析设计人员对项目所处的领域不熟悉，为获得更多的用户需求，通过原型模型的运行，容易使用户提出更多的要求，有利于系统满足用户需求，避免今后的返工。如在石油、化工、煤炭、电力和制药等领域，有很明显的领域特殊性，可以通过原型模型不断了解行业的特点，更好地获得系统的需求。

1.3.3 过程反复

人们越来越认识到软件像所有复杂系统一样，业务和产品需求随着开发的进展常常会发生变化，用硬性的划分阶段完成的阶段成果固定下来的做法很难适应需求的变更，通常经过一段时间的分析与设计，将系统核心部分或者是需求比较明确的部分进行开发，其他部分可以进一步细化。因此，过程反复的过程模型随之而产生。以下两种模型利用迭代思想，使软件工程师渐进地开发，逐步完善最终系统。

1．增量模型

增量模型（Increment Model）融合了瀑布模型的线性特点，同时为适应软件需求变化的特征，结合了原型和迭代的形式，可以实现随着时间的推移而交错的线性序列。如图1-10所示，每一个线性序列产生软件系统的一个可发布的“增量”。例如，使用增量模型开发的文字处理软件，可以在第一个增量中发布基本的文件管理、编辑、文档生成部分；在第二个增量中发布更加完善的编辑和文档生成功能；第三个增量可以实现拼写和文法检查功能；依次划分，不断增加功能，并不断完善已经完成的功能，最终形成系统。

在使用增量模型时，第一个增量往往是核心的部分，实现了系统的基本功能，并随着核心产品交付用户使用过程，评估该部分并进行下一个增量的计划开发，包括前一个增量的修改，使其更好地满足用户需求，准备发布新增的系统功能。这个过程在每一个增量发布后不断重复，直到产生最终的完善系统。

增量模型强调每一个增量均发布一个可操作的系统部分，给用户提供了服务功能，也给用户提供了评价的平台。

软件市场竞争激烈，增量开发模型明显适应了时代的要求，并结合了瀑布模型和原型模型的优点，每一个增量的开发可以不使用同一个开发模型，如果某一增量有完善的需求描述时，可以采用瀑布模型进行开发；对需求不够明确的增量，可以使用原型模型方式开发。所以，增量模型的优点是：

（1）客户可以很快使用系统，而无须等到整个系统完成之后。

（2）早期的增量可以作为系统原型，用户通过运行早期的版本，评价以后的增量。

（3）项目总体失败的可能性较小，虽然可能某一增量存在问题，但其他一些增量已经交付给用户使用了。

增量模型开发也存在一些问题。如何划分增量、增量大小的确定是实际系统中难以确定的。一般情况下，一个增量的大小不超过2万行代码，并且，每一个增量应该包含一定的系统功能。但是，很难把客户的需求映射到适当的增量上，而且，大多数系统都会用到一组基本服务，在增量实现前，需求不能被详细定义，明确所有的增量可能用到的基本服务是比较困难的。

【例1-4】增量模型有着很明显的优势，给用户的感觉是系统完成的时间很短，首先发布的系统具有基本功能，能够为用户提供简单、实用的操作功能，并且随着用户的反馈意见和系统增量的完成，使得整个系统不断完善，增进了系统的可用性和完整性，降低了项目风险。因此，在目前软件业竞争非常激烈的状况下，很多软件项目要求开发时间短，尽快发布以占领市场，并且会不断增加需求，因此采用增量模型开发有助于中小型软件项目能够满足用户需求。比如，使用增量式开发的字处理软件，在第一个增量中发布基本的文件管理、编辑和文档生成功能；在第二个增量中发布更加完善的编辑和文档生成能力；第三个增量中实现拼写和文法检查功能；第四个增量完成高级的页面布局功能。每个增量提供系统功能的一个子集，一个增量完成并交付，部分系统功能可以提前交付使用。对增量中服务的分配取决于服务优先次序。最高优先权的服务首先被交付。第一个增量往往是核心的产品。开发者能通过经验帮助理解后面的增量需求和目前增量后续版本的需求变更。

2．螺旋模型

螺旋模型（Spiral Model）最初是由Boehm（1988年）提出的，如图1-11所示。它不是将软件过程分为阶段和阶段间的反复来表示，而是采用螺旋旋转方式，每一回路表示软件过程的一个阶段，也即是对应于瀑布模型的相应阶段，如最内层的回路是系统可行性分析阶段，下一层回路与需求分析阶段有关，再下一层回路与设计阶段有关等。另一方面，又将每一回路分为四个象限部分：目标制定、风险分析、项目实施、评估与规划。

（1）目标制定。确定软件项目的范围、系统实现的目标，选择相应的方案，获取系统的约束条件。

（2）风险分析。每一项目对预选的方案进行风险识别与分析，并采取规避风险的措施。

（3）项目实施。风险分析之后进行系统开发模型的确定，实施软件开发。

（4）评估与规划。对项目进行评审以确定是否需要进行螺旋模型中的下一个回路，如果继续进行，则对项目的下一个阶段进行计划。

螺旋模型的每一个回路开始于系统的功能和性能，列出所有可能的系统约束。对每一功能和性能所有可能的可选方案进行评估，识别出系统存在的可能风险，通过详细的分析、原型建立、仿真等活动评估风险，然后进行系统开发，并对系统开发的其他活动进行相应的规划。

1.3.4 形式化开发

形式化开发模型（Transformational Model）是结合瀑布模型的开发活动并运用数学转换的方式形成的一种开发方法，使得软件工程师能够通过采用严格的、数学的表示方法对软件的开发活动进行数学的描述，用形式化数学转换将系统描述转换成一个可执行的程序。开发过程如图1-12所示。

形式化开发模型的特点是：

（1）软件需求描述采用了精练的数学符号进行详细的描述，是一个形式化需求描述。

（2）系统的设计、实现、测试是由一系列的数学公式组成，构成数学转换的方式，将系统的形式化需求描述转换成可执行的代码。

（3）所获得的程序代码是完全符合形式化需求描述的，是一个正确的程序。

（4）转换是准确的，有严格的数学方法来保证。

目前形式化开发的规范形式是净室（Cleanroom）软件开发过程，最初由IBM公司开发。净室开发过程依赖增量开发模型，在每一阶段都采用形式化方法开发和验证该阶段的正确性。

净室开发和基于B方法的形式化开发方法都已经被成功地应用。二义性、不完整性和不一致性通过数学分析的过程可以容易地被发现和纠正，因此，在交付系统上缺陷较少，成本没有明显的增加，特别适用于安全和保密性要求较高的系统开发。但是，对于一般的应用领域还没有被广泛地应用。主要的原因有：

（1）形式化模型的开发目前很昂贵、费时。

（2）具有形式化方法所需的背景知识的软件开发人员较少，需要多方面的培训。

（3）难以使用形式化模型作为与用户沟通的途径。

尽管存在诸多问题，但是，形式化开发方法的确能够得到正确的程序，在今后也许会得到相应的认可。

1.3.5 RUP

RUP（Rational Unified Process，统一的开发过程）是一个面向对象且基于网络的程序开发方法论。根据Rational（Rational Rose和统一建模语言的开发者）的说法，它可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。RUP和类似的产品，例如面向对象的软件过程（OOSP），以及OPEN Process都是理解性的；软件工程工具把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档、模型、手册以及代码等）整合在一个统一的框架内。

1．RUP软件开发生命周期

RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织，具有过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期（Cycle）、阶段（Phase）、迭代（Iteration）和里程碑（Milestone）；纵轴以内容来组织，为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动（Activity）、产物（Artifact）、工作者（Worker）和工作流（Workflow），如图1-13所示。

RUP中的软件生命周期在时间上被分解为4个顺序的阶段，分别是：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。每个阶段结束于一个主要的里程碑（Major Milestone）；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，就可以允许项目进入下一个阶段。

（1）初始阶段。初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的，必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。初始阶段结束时是第一个重要的里程碑：生命周期目标（Lifecycle Objective）里程碑。生命周期目标里程碑评价项目基本的生存能力。

（2）细化阶段。细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构做出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。细化阶段结束时是第二个重要的里程碑：生命周期结构（Lifecycle Architecture）里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。

（3）构造阶段。在构造阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构造阶段是一个制造过程，其重点放在管理资源及控制运作，以优化成本、进度和质量。构造阶段结束时是第三个重要的里程碑：初始功能（Initial Operational）里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为beta版。

（4）交付阶段。交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，以及设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。在交付阶段的终点是第四个里程碑：产品发布（Product Release）里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

2．RUP核心工作流

RUP中有9个核心工作流，分为6个核心过程工作流（Core Process Workflows）和3个核心支持工作流（Core Supporting Workflows）。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。

（1）商业建模（Business Modeling）。商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程、角色和责任。

（2）需求（Requirements）。需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。

（3）分析和设计（Analysis&Design）。分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计，使其与实现环境相匹配，优化其性能。分析和设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包（Package）和设计子系统（Subsystem），而描述则体现了类的对象如何协同工作，实现用例的功能。设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。

（4）实现（Implementation）。实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式（源文件、二进制文件、可执行文件）实现类和对象；将开发出的组件作为单元进行测试，以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。

（5）测试（Test）。测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确地实现，识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。

（6）部署（Deployment）。部署工作流的目的是成功地生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。

（7）配置和变更管理（Configuration &Change Management）。配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发以及如何自动化创建工程，同时也阐述了对产品修改原因、时间、人员保持审计记录。

（8）项目管理（Project Management）。软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。

（9）环境（Environment）。环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。

RUP的迭代开发模式是将RUP中的每个阶段进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程，直到成为最终的系统。传统上的项目组织是顺序通过每个工作流，每个工作流只有一次，也就是我们熟悉的瀑布生命周期（如图1-14所示）。这样做的结果是到实现末期产品完成并开始测试，在分析、设计和实现阶段所遗留的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期。

一种更灵活、风险更小的方法是多次通过不同地开发工作流，这样可以更好地理解需求，构造一个健壮的体系结构，并最终交付一系列逐步完成的版本。这叫做一个迭代生命周期。在工作流中的每一次顺序的通过称为一次迭代。软件生命周期是迭代的连续，通过它，软件是增量的开发。一次迭代包括了生成一个可执行版本的开发活动，还有使用这个版本所必需的其他辅助成分，如版本描述、用户文档等。因此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过，这些工作流至少包括：需求工作流、分析和设计工作流、实现工作流、测试工作流，其本身就像一个小型的瀑布项目（如图1-15所示）。

与传统的瀑布模型相比较，迭代过程具有以下优点。

● 降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。

● 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期手忙脚乱。

● 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。

由于用户的需求并不能在一开始就做出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

RUP具有很多长处，提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。但同时它也存在一些不足，RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容；此外，它没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。可以说RUP是一个非常好的开端，但并不完美，在实际的应用中可以根据需要对其进行改进，并可以用OPEN和OOSP等其他软件过程的相关内容对RUP进行补充和完善。

1.3.6 基于组件的集成模型

软件是一种可重复利用的资源，软件复用是指重复使用“为了复用目的而设计的软件”的过程。通过复用，可以控制软件开发的复杂度，缩短开发周期，并提高软件产品的质量。由于软件开发模式多种多样，因此复用的方式也不尽相同，其中基于构件的复用是目前最有效的，也是学术界和企业界公认的主流。从软件开发技术来讲，提出了设计模式作为复用成功的系统设计经验的方案，将已有的软件成分用于构造新的软件系统，因此，基于复用来提高软件开发投入的回报率，以复用为基础的软件工程是要对现存软件的复用程度最大化。软件复用包括三个方面：

（1）应用系统复用。整个系统的复用可以不加修改地融合到其他系统当中，或是通过开发应用系列适应不同的平台或者面向特殊的用户。如相类似的信息管理系统存在很多的应用开发系列。

（2）组件复用。应用系统的组件规模从子系统到单个对象的重复使用。

（3）功能复用。实现单一功能的软件组件不断重复使用，如很多数学函数。

基于组件的开发（Component Integration Model）或基于组件的软件工程（Component-Based Software Engineering, CBSE）出现于20世纪90年代，面向复用的方法依赖可以存取的可复用软件组件以及能集成这些组件的框架。软件工程人员根据系统的需求情况，搜索可复用的组件，再将系统的设计建立在这些可复用的组件之上。从简单的功能子程序到完整的应用系统都可以定义为组件，它是一个独立的可运行实体，称为COTS（Commercial-Off-The-Shelf）商业现成产品系统，组件发布它们的接口，所有的交互都是经过接口完成的。组件集成模型的基本框架结构如图1-16所示。

（1）系统需求描述。对系统所要完成的基本要求进行概括的描述，给出系统完成的范围。

（2）搜索可复用的组件。针对系统需求描述，搜索能满足需求的组件。一般没有正好合适的组件可供使用，能得到的组件往往只提供所需要的部分功能。

（3）需求修改。在这个阶段，根据得到的组件信息来再次分析需求，修改需求以反映可得到的组件。当不允许修改需求时，搜索可复用的组件活动要重新进行，以寻找其他可能的替代方案。

（4）体系结构设计。针对目前获得的组件和系统总的需求描述，构造系统总体结构。

（5）搜索可复用的组件。依据系统体系结构设计，再次搜索可复用的组件进行确认。

（6）使用复用的系统设计。开始设计系统的框架，或者重复使用已存在的设计框架。设计者分析可重复使用的组件并设计一个框架来组织这些组件。

（7）开发和集成。整个系统包括了可复用的组件和需要自己开发的部分，继承自己开发的部分和相应的可利用的组件，使之成为一个整体。

（8）系统有效性验证。对系统所获得最终结果进行测试，并验证是否满足了系统需求。

基于组件开发的主要困难是维护和进化问题，组件在发布之后很难得到源程序代码，当需求变更时，不可能通过改变组件适应需求的变化。但是，应用组件开发模型，有利于减少需要开发的软件数量，降低软件开发成本，并且降低软件项目风险，能够实现软件快速交付。构件化应用开发必须要有开发工具的支撑，包括集成开发环境、应用运行环境、应用管理及构件库管理等。不同行业领域应用的公共业务逻辑，体现在构件库中不同的业务构件或构件组。领域构件体现了个性化需求，包含有特定领域业务构件的应用基础平台就是该领域的应用平台。基于构件的软件工程最需要解决的问题是如何建造构件模型和确立软件体系结构（即构架）。构件模型决定了软件系统构架的思维逻辑。在构件和构架模型中，有必要把构件与构件间的交互作用相分离，以提高构件的独立性和可重用性。

1.3.7 XP方法

XP（极限编程，Extreme Programming）是由Kent Beck在1996年提出的。Kent Beck在20世纪90年代初期开始就一直探索着新的软件开发方法，希望能使软件开发更加简单而有效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能性以及面临的困难。1996年3月，Kent终于在为Daimler Chrysler所做的一个项目中引入了新的软件开发观念——XP。XP是一个轻量级的、灵巧的软件开发方法，同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其他一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

XP方法是建立在开发和交付非常小的功能增量方式上的，客户参与开发过程，经常性地进行代码改进和非自我程序设计。其核心思想是交流（Communication）、简单（Simplicity）、反馈（Feedback）和进取。XP小组采用的是民主的小组结构，程序员一起编写代码，集体对开发的程序负责。这个小组不仅包括开发人员，还包括管理人员和客户，该模型强调小组成员之间要经常进行交流。其优点是：采用简单计划策略，不需要长期计划和复杂模型，开发周期短；在全过程采用迭代增量开发，反馈修正和反复测试的方法，软件质量有保证；能够适应用户经常变化的需求，提供用户满意的高质量软件。

1.3.8 基于Web的开发模型

因特网具有传播信息容量大、形态多样、迅速方便、全球覆盖、自由和交互的特点，已经发展成为新的传播媒体，所以全球几乎每个企业、机构纷纷建立自己的Web站点。随着Web站点数量的增多、规模的增大，在Web开发中遇到的问题也越来越多。传统Web开发的过程大多具有随意性，缺乏系统的方法、质量控制和保证过程，是不符合方法学的。站点的目标定义得很松散，整个开发进程依靠的是直觉，没有严格的过程定义而缺乏可预见性。以这种方法开发的站点偶尔也会成功，但更多的情况却是项目的失败。而且，随着基于Web的系统变得越来越复杂，一个项目的失败可能导致很多问题。当这种情况发生时，人们对Web和Internet的信心可能会动摇，从而引起Web危机。因此，复杂的Web站点需要认真地计划，采用适当的进程模型或方法学来指导Web的设计和开发。

随着Web系统规模的扩大和应用的增多，Web开发正变得越来越接近软件开发。Web开发的特点为：

（1）Web是一种软件。最早的Web设计是很简单的，大量的超链接、文本和图片。而现在的Web已经具备了与数据紧密连接的需要，大量B/S结构的应用，毫无疑问，Web已经成为软件的一个重要分支。

（2）Web项目是工程项目。Web项目正变得越来越复杂，如果不强调项目的工程性，则整个项目的实施将陷入混乱之中。

（3）Web开发需要人员组织管理。Web开发需要多种技术人员共同完成，例如系统分析员、程序设计员、美工人员等。这就涉及人员组织管理问题。

（4）Web开发需要测试和维护。Web开发的产品要放到网络上，要接受大量不同用户的浏览和使用，所以测试工作尤其重要。维护也是一样，没有经过及时维护的网站是没有价值的。

基于上述特点，在Web开发中采用软件开发的方法学和软件工程的思想是完全可行的。因此，对于大量的Web开发具有用户需求不明确，用户对预期的开发结果难以准确描述的特点，采用Web快速原型模型，如图1-17所示。

（1）建立Web原型。根据用户能够提出的初步需求，开发人员快速建立一个Web原型系统。在建立Web原型的过程中，主要强调快速，可以充分利用现有的Web资源和构件，利用模板技术迅速实现原型。

（2）用户试用。用户在计算机上试用Web原型系统，通过使用原型系统，用户可以发现系统功能、性能等方面的问题，特别是对系统的可用性，可以提出很好的建议。这里要特别注意，开发人员和用户的良好沟通是非常重要的，要避免用户提出不合理的要求而使Web设计偏离最终目标。

（3）修改原型。针对用户提出的修改建议，开发人员按照用户意见快速修改原型系统，然后再次请用户试用，如此循环直到用户满意为止。

（4）Web规格说明。如果用户对Web原型满意，开发人员就可以根据目前的原型确切定义Web系统的规格说明，为后面的开发工作奠定扎实的基础。

（5）Web设计。根据Web规格说明，做出Web系统的功能设计和性能设计，还要包括版面设计、后台数据库设计等。Web设计还要特别注意可用性，可采用以用户为中心的设计方法。

（6）Web编码实现。Web编码实现阶段包括数据库程序的开发、页面程序的编写和所有网页的制作，所有内容都要链接到相关的页面。在本阶段需要程序员和网页设计师协同工作，并且要随时测试网页和程序，发现问题要立刻记录并反馈，以便修改。

（7）Web测试。测试人员要检查和验证Web系统是否按照规格说明和设计要求正常运行，而且要评价Web系统在不同用户的浏览器中显示是否合适，还要从最终用户的角度进行安全性和可用性测试，以及对流量和性能方面进行测试。

（8）Web发布与维护。把经过测试的Web系统传送到网络上，供用户浏览和使用，并进行长期的维护工作。Web系统的维护是比较频繁的，包括页面内容的更新和页面结构的改变等。

Web开发是一个复杂的工程过程，采用基于软件工程思想的Web快速原型模型实施Web项目的开发，能够较好地解决Web危机问题，可以进行更加有效率、高质量的Web开发。但同时也必须看到Web系统的复杂性和成长性，没有一种Web开发模型可以适应所有的情况，在Web开发模型的研究上还需要更多的努力和完善。

1.3.9 自动化的过程支持

计算机辅助软件工程（Computer-Aided Software Engineering, CASE）是用来支持软件过程活动的软件，如项目规划、需求分析、系统设计、编码实现和系统测试等活动都拥有相应的软件辅助支持。CASE工具包括设计编辑器、数据字典、编译器、调试器、系统建设工具等。CASE技术通过自动化过程活动和提供正被开发的软件信息来支持软件过程。使用CASE可以自动化活动的例子包括：

● 需求描述或软件设计的图形化系统模型开发；

● 通过数据字典了解设计中的实体和关系的信息；

● 通过提供执行程序的信息来调试程序；

● 通过用户交互式生成的图形化界面描述产生用户界面；

● 程序的自动转换。

一般来说，依照CASE技术对软件过程支持的广度划分为以下三类，具体描述如图1-18所示。

（1）工具类。用以支持实现过程的独立工具，如编译器、编辑器、文件比较器等。这些工具可以是通用的独立工具，也可以被集成到工作平台上。

（2）工作平台。用以支持开发过程，如支持需求、设计描述等活动的集成度不同的一组集成工具。

（3）环境。用以支持整个软件生存周期过程的所有活动，以一定方式集成的几个工作平台。

使用CASE可以实现软件开发自动化活动，如：

● 规划工具中常用的有PERT工具、电子表格工具；

● 编辑工具有文本编辑器、图表编辑器和字处理器；

● 语言处理器有编译器、解释器；

● 原型建立工具中的用户界面生成器；

● 调试工具中的交互式调试系统。

通过分析CASE技术组成，可以看到CASE的工作平台是以软件工程开发过程的活动进行划分的，而CASE环境由集成环境和以过程为中心的环境组成。在实际运用过程中，这些分类并没有明显的界限。工具可以独立使用，也可以与其他工具一起使用。如计算机语言开发环境包括代码编辑器和语言编译器，以及相应的调试工具等融在一起。采用CASE工作平台，可以支持软件的整体开发过程。CASE技术为软件开发过程提供自动化的支持。