原型可以作为“第一个系统”，就是 Brooks 建议我们抛弃的那一个。但 这可能是一种理想化的看法。用户和开发者确实都喜欢原型范型，用户能够 感受到实际的系统，开发者能够很快地建造出一些东西。但由于如下的原因 原型仍存在问题：
　　1.用户似乎看到的是软件的工作版本，他们不知道原型只是“用口香糖 和打包绳”拼凑起来的；不知道为了使原型很快能够工作，我们没有考虑软 件的总体质量和长期的可维护性。当被告知该产品必须重建，才能使其达到 高质量时，用户叫苦连天，会要求做“一些修改”，使原型成为最终的工作 产品。如此，软件开发管理常常就放松了。
　　2.开发者常常需要实现上的折衷，以使原型能够尽快工作。一个不合适 的操作系统或程序设计语言可能被采用，仅仅因为它是通用的和有名的；一 个效率低的算法可能被使用，仅仅为了演示功能。经过一段时间之后，开发 者可能对这些选择已经习惯了，忘记了它们不合适的所有原因。于是这些不 理想的选择就成为了系统的组成部分。
　　虽然会出现问题，原型仍是软件工程的一个有效范型。关键是如何定义 一开始的游戏规则，即用户和开发者两方面必须达成一致：原型被建造仅是 为了定义需求，之后就该被抛弃(或至少部分抛弃)，实际的软件在充分考虑 了质量和可维护性之后才被开发。

2.6 RAD 模型


　　快速应用开发(RAD)是一个线性顺序的软件开发模型，强调极短的开发周 期。RAD 模型是线性顺序模型的一个“高速”变种，通过使用基于构件的建 造方法获得了快速开发。如果需求理解得很好，且约束了项目范围①， RAD 过程使得一个开发组能够在很短时间内(如 60 到 90 天)创建出“功能完善的 系统”［MAR91］。RAD 方法主要用于信息系统应用软件的开发，它包含如下 几个开发阶段［KER94］：
业务建模：业务活动中的信息流被模型化，以回答如下问题：什么信息
驱动业务流程？生成什么信息？谁生成该信息？该信息流往何处？谁处理 它？业务建模将在第 10 章详细描述。
数据建模：业务建模阶段定义的一部分信息流被精化，形成一组支持该
业务所需的数据对象。标识出每个对象的特征(称为属性)，并定义这些对象 间的关系。数据建模将在第 12 章讨论。
　　处理建模：数据建模阶段定义的数据对象变换成为要完成一个业务功能 所需的信息流。创建处理描述以便增加、修改、删除或获取某个数据对象。 应用生成：RAD 假设使用第四代技术(见 2.9 节)。RAD 过程不是采用传 统的第三代程序设计语言来创建软件，而是复用已有的程序构件(如果可能的 话)或是创建可复用的构件(如果需要的话)。在所有情况下，均使用自动化工
具辅助软件建造。
测试及反复：因为 RAD 过程强调复用，许多程序构件已经是测试过的， 这减少了测试时间。但新构件必须测试，所有接口也必须测到。



① 这些条件很难保证。事实上，许多软件项目在开始时需求定义得很不充分的。在这种情况下，原型（见
2.5 节）或演化方法（见 2.7 节）是更好的选择。（见参考文献［REI95］）

　　RAD 过程模型如图 2-6 所示。很显然，加之于一个 RAD 项目上的时间约 束需要有“一个可伸缩的范围”［KER94］。如果一个商业应用能够被模块化， 使得其中每一个主要功能均可以在不到三个月时间内完成(使用上述的方 法)，它就是 RAD 的一个候选件。每一个主要功能可由一个单独的 RAD 组来实 现，最后再集成起来形成一个整体。
■
像所有其他过程模型一样，RAD 方法也有其缺陷：
　　·对于大型的、但可伸缩的项目，RAD 需要足够的人力资源以创建足够 的 RAD 组。
　　·RAD 要求承担必要的快速活动的开发者和用户在一个很短的时间框架 下完成一个系统。如果两方中的任何一方没有完成约定，都会导致 RAD 项目 失败。
　　并非所有应用软件都适合使用 RAD。如果一个系统难以被适当地模块 化，那么建造 RAD 所需的构件就会有问题；如果高性能是一个指标，且该指 标必须通过调整接口使其适应系统构件才能赢得，RAD 方法就有可能失败 了；RAD 不适合技术风险很高的情况，当一个新应用要采用很多新技术，或 当新软件要求与已有计算机程序有高可互操作性时，这种情况就会发生。
RAD 强调可复用程序构件的开发。可复用性(见第 26 章)是对象技术的基
础(本书的第四部分)，在 2.7.3 节讨论的构件组装过程模型中还会提到。

2.7 演化软件过程模型


　　人们已经越来越认识到软件就象所有复杂系统一样要经过一段时间的演 化(参见文献［GIL88］)。业务和产品需求随着开发的发展常常发生改变，想 找到最终产品的一条直线路径是不可能的；紧迫的市场期限使得难于完成一 个完善的软件产品，但可以先提交一个有限的版本以对付竞争的或商业的压 力；只要核心产品或系统需求能够被很好地理解，而产品或系统的细节部分 可以进一步定义。在这些情况及其他类似情况下，软件工程师需要一个过程 模型，以便能明确设计，同时又能适应随时间演化的产品的开发。
线性顺序模型(见 2.4 节)是支持直线开发，本质上，瀑布方法是假设当
线性序列完成之后就能够交付一个完善的系统。原型模型(见 2.5 节)目的是 帮助用户(或开发者)理解需求，总体上讲，它并不是交付一个最终产品系统。 而软件的变化特征在这些传统的软件工程范型中都没有加以考虑。
　　演化模型是利用一种迭代的思想方法。它的特征是使软件工程师渐进地 开发，逐步完善的软件版本。

2.7.1 增量模型


　　增量模型融合了线性顺序模型的基本成分(重复地应用)和原型的迭代特 征。如图 2-7 所示，增量模型采用随着日程时间的进展而交错的线性序列。 每一个线性序列产生软件的一个可发布的“增量”(参见文献［McDE93］)。 例如，使用增量范型开发的字处理软件，可能在第一个增量中发布基本的文 件管理、编辑和文档生成功能；在第二个增量中发布更加完善的编辑和文档 生成能力；第三个增量实现拼写和文法检查功能；第四个增量完成高级的页
　　
面布局功能。应该注意：任何增量的处理流程均可以结合进原型范型。 当使用增量模型时，第一个增量往往是核心的产品，即实现了基本的需
求，但很多补充的特性(其中一些是已知的，另外一些是未知的)还没有发布。 核心产品交用户使用(或进行更详细的复审)，使用和/或评估的结果是下一个 增量的开发计划。该计划包括对核心产品的修改，使其能更好地满足用户的 需要，并发布一些新增的特点和功能。这个过程在每一个增量发布后不断重 复，直到产生最终的完善产品。
　　增量过程模型，像原型(见 2.5 节)和其他演化方法一样，具有迭代的特 征。但与原型不一样，增量模型强调每一个增量均发布一个可操作产品。早 期的增量是最终产品的“可拆卸”版本，但它们确实提供了给用户服务的功 能，并且提供了给用户评估的平台。
　　增量开发是很有用的，尤其是当配备的人员不能在为该项目设定的市场 期限之前实现一个完全的版本时。早期的增量可以由较少的人员实现。如果 核心产品很受欢迎，可以增加新的人手(如果需要的话)实现下一个增量。此 外，增量能够有计划地管理技术风险，例如，系统的一个重要部分需要使用 正在开发的且发布时间尚未确定的新硬件，有可能计划在早期的增量中避免 使用该硬件，这样，就可以先发布部分功能给用户，以免过分地延迟系统的 问世时间。
■

2.7.2 螺旋模型


　　螺旋模型，最早是由 Boehm［BOE88］提出来的，是一个演化软件过程模 型，它将原型的迭代特征与线性顺序模型中控制的和系统化的方面结合起 来，使得软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是 一系列的增量发布。在早期的迭代中，发布的增量可能是一个纸上的模型或 原型；在以后的迭代中，被开发系统的更加完善的版本逐步产生。
螺旋模型被划分为若干框架活动，也称任务区域(本节描述的螺旋模型是
Boehm 提出的模型的变种。最初的螺旋模型的相关信息参见［BOE88］。一般 情况下，有三到六个任务区域，图 2-8 刻划了包含六个任务区域的螺旋模型：
·用户通信——建立开发者和用户之间有效通信所需要的任务。
·计划——定义资源、进度及其他相关项目信息所需要的任务。
·风险分析——评估技术的及管理的风险所需要的任务。
·工程——建立应用的一个或多个表示所需要的任务。
　　·建造及发布——建造、测试、安装和提供用户支持(如文档及培训)所 需要的任务。
　　·用户评估——基于在工程阶段产生的或在安装阶段实现的软件表示的 评估，获得用户反馈所需要的任务。
■
　　每一个区域均含有一系列适应待开发项目的特点的工作任务。对于较小 的项目，工作任务的数目及其形式化程度均较低。对于较大的、关键的项目， 每一个任务区域包含较多的工作任务，以得到较高级别的形式。在所有情况 下，均需应用 2.2 节提到的保护性活动(如软件配置管理和软件质量保证)。 随着演化过程的开始，软件工程项目组按顺时针方向沿螺旋移动，从核
　　
心开始。螺旋的第一圈可能产生产品的规格说明；再下面的螺旋可能用于开 发一个原型；随后可能是软件的更完善的版本。经过计划区域的每一圈是为 了对项目计划进行调整，基于从用户评估得到的反馈，调整费用和进度。此 外，项目管理者可以调整完成软件所需的计划的迭代次数。
　　与传统的过程模型不同，它不是当软件交付时就结束了，螺旋模型能够 适用于计算机软件的整个生命周期。图 2-9 中定义了项目入口点的轴线。沿 轴线放置的每一个小方块都代表了一个不同类型项目的开始点。一个“概念 开发项目”从螺旋的核心开始一直持续到概念开发结束(沿着中心阴影区域限 定的螺旋线进行多次迭代)。如果概念被开发成真正的产品，过程从第二个小 方块(“新产品开发项目”入口点)开始，一个新的开发项目启动了。新产品 的演化是沿着比中心区域略浅的阴影区域所限定的螺旋线进行若干次迭代。 其他类型的项目也遵循类似的过程。
　　本质上，具有上述特征的螺旋是一直运转的直到软件退役。有时这个过 程处于睡眠状态，但任何时候出现了改变，过程都会从合适的入口点开始(如 产品增强)。
　　对于大型系统及软件的开发来说，螺旋模型是一个很现实的方法。因为 软件随着过程的进展演化，开发者和用户能够更好地理解和对待每一个演化 级别上的风险。螺旋模型使用原型作为降低风险的机制，但更重要的是，它 使开发者在产品演化的任一阶段均可应用原型方法。它保持了传统生命周期 模型中系统的、阶段性的方法，但将其并进了迭代框架，更加真实地反映了 现实世界。螺旋模型要求在项目的所有阶段直接考虑技术风险，如果应用得 当，能够在风险变成问题之前降低它的危害。
但像其他范型一样，螺旋模型也不是包治百病的灵丹妙药。它可能难以
使用户(尤其在合同情况下)相信演化方法是可控的；它需要相当的风险评估 的专门技术，且其成功依赖于这种专门技术。如果一个大的风险未被发现和 管理，毫无疑问会出现问题；最后，该模型本身相对比较新，不像线性顺序 范型或原型范型那样被广泛应用。在这个重要的新范型的功效能够被完全确 定之前，还需要经历若干年的时间。
■

2.7.3 构件组装模型


　　对象技术(第 19 章)为软件工程的基于构件的过程模型提供了技术框 架。面向对象范型强调了类的创建，类封装了数据和用于操纵该数据的算法。 如果经过合适的设计和实现，面向对象的类可以在不同的应用及基于计算机 的系统结构中复用。
　　构件组装模型(如图 2-10 所示)融合了螺旋模型的许多特征。它本质上是 演化的(参见文献［NIE92］)，支持软件开发的迭代方法。但是，构件组装模 型是利用预先包装好的软件构件(有时称为“类”)来构造应用程序的。
　　开发活动从候选类的标识开始。这一步通过检查将被应用程序操纵的数 据及用于实现该操纵的算法来完成(这是对类定义的一个简单的描述，更详细 的讨论见第 19 章)。相关的数据和算法封装成一个类。
■
以前的软件工程项目中创建的类(在图 2-10 中称为构件)被存储在一个

类库或仓库中(第 29 章)。一旦标识出候选类，就可以搜索该类库，确认这些 类是否已经存在。如果已经存在，就从库中提取出来复用。如果一个候选类 在库中并不存在，就采用面向对象方法(第 20～22 章)开发它。之后就可以利 用从库中提取出来的类以及为了满足应用程序的特定要求而建造的新类，来 构造待开发应用程序的第一个迭代。过程流程而后又回到螺旋，并通过随后 的工程活动最终再进入构件组装迭代。
　　构件组装模型导致软件复用，而可复用性给软件工程师提供了大量的可 见的益处。基于可复用性的研究，QSM 联合公司的报告称：构件组装降低了
70％的开发周期时间；84％的项目成本；相对于产业平均指数 16.9，其生产 率指数为 26.2。虽然这些结果依赖于构件库的健壮性，但毫无疑问构件组装 模型给软件工程师提供了意义深远的好处。

2.7.4 并发开发模型


　　并发开发模型，有时也称并发工程，David 和 Sitaram［DAV94］是这样 描述它的：
　　试图根据传统生命周期的主要阶段来追踪项目的状态的项目管理者是根 本不可能了解其项目的状态的。这就是使用过于简单的模型追踪非常复杂的 活动的示例。注意，虽然一个项目正处在编码阶段，但同时可能有一些项目 组人员在参与涉及开发的多个阶段的活动，例如，??项目组人员在写需求、 在设计、在编码、在测试和集成测试，所有这些活动可能在同时进行。Humphrey
和 Kellner［HUM89，KEL89］提出的软件工程过程模型表达了这种任一阶段
的活动之间存在的并发性。 Kellner 最近的工作中［KEL91］使用了状态图 (一个加工的状态的表示法，见第 15 章)来表示与一个特定事件(如，在开发 后期需求的一个修改)相关的活动之间存在的并发关系，但它不能捕获到贯穿 于一个项目中所有软件开发和管理活动的大量并发??。大多数软件开发过 程模型均为时间驱动的；越到模型的后端，就越到开发过程的后一阶段。而 一个并发过程模型是由用户要求、管理决策和结果复审驱动的。
并发过程模型可以被大致表示为一系列的主要技术活动、任务及它们的
相关状态。例如，螺旋模型(见 2.7.2 节)定义的工程活动(任务区域)是通过 执行下列任务来完成的：原型和/或分析建模，需求说明，以及设计(应该注 意到：分析和设计是非常复杂的任务，需要更进一步的讨论。本书的第三部 分和第四部分给出了关于它们的更详细的探讨)。图 2-11 给出了并发过程模 型中一个活动的图形表示。该活动(分析)在任一给定时间可能处于任一状态 (状态是行为的某个外部可见的模式)。同样的，其他活动(如设计或用户通信) 也能够用类似方式来表示。所有活动并发存在，但处于不同的状态。例如， 在项目开发早期，用户通信活动(图中并未显示)已经完成它的第一次迭代， 并处于“等待修改”状态。而分析活动(当最初的用户通信活动完成时，它正 处于“开始”状态)现在则转移到“开发”状态。如果用户表示必须做某些需 求上的修改，那么分析活动就从“开发”状态转移到“等待修改”状态。
■
　　并发过程模型定义了一系列事件，对于每一个软件工程活动，它们触发 从一个状态到另一个状态的转移。例如，在设计的早期阶段，发现了分析模 型中的一个不一致，这产生了事件“分析模型修改”，该事件触发了分析活
　　
动从“开始”状态转移到“等待修改”状态。 并发过程模型常常被用于作为客户机/服务器①应用(第 28 章)的开发范
型。一个客户机/服务器系统由一组功能构件组成。当应用于客户机/服务器 系统时，并发过程模型在两维上定义活动［SHE94］：一个系统维和一个构件 维。系统维包含三个活动：设计、组装和使用。构件维包含两个活动：设计 和实现。并发提供两种方式得到：(1)系统维和构件维活动同时发生，并能使 用上述的面向状态方法建模；(2)一个典型的客户机/服务器应用系统是通过 多个构件实现的，其中每个构件均可以并发地设计和实现。
　　实际上，并发过程模型可用于所有类型的软件开发，并能够提供关于一 个项目的当前状态的准确视图。该模型不是将软件工程活动限定为一个顺序 的事件序列，而是定义了一个活动网络。网络上的每一个活动均可与其他活 动同时发生。在一个给定的活动中或活动网络中其他活动中产生的事件将触 发一个活动中的状态的转移。

2.8 形式化方法模型


　　形式化方法模型包含了一组活动，它们带来了计算机软件用数学说明描 述的方法。形式化方法使得软件工程师能够通过采用一个严格的、数学的表 示体系来说明、开发和验证基于计算机的系统。这种方法的一个变种，称为 净室软件工程［MIL87，DYE92］，目前已被一些软件开发组织采用。
当在开发中使用形式化方法时(第 24 章和 25 章)，它们提供了一种机制，
能够消除使用其他软件工程范型难以克服的问题。二义性、不完整性和不一 致性能被更容易地发现和纠正——不是通过专门的复审，而是通过数学分 析。当在设计中使用形式化方法时，它们能作为程序验证的基础，从而使得 软件工程师能够发现和纠正在其他情况下发现不了的错误。
形式化方法模型虽然不是主流的方法，但可以产生正确的软件。不过，
它在商业环境中的可用性还需要考虑：
1.形式化模型的开发目前还很费时和昂贵。
　　2.因为很少有软件开发者具有使用形式化方法所需的背景知识，所以尚 需多方面的进行培训。
3.难以使用该模型作为与对其一无所知的用户进行通信的机制。
　　尽管存在这些顾虑，但形式化方法可能会赢得一批拥护者，例如那些必 须建造安全的关键软件(如航空电子及医疗设备的开发者)的软件开发者，以 及那些如果发生软件错误会遭受严重的经济损失的开发者。

2.9 第四代技术


术语“第四代技术”(4GT)包含了一系列的软件工具，它们都有一个共同 点：能使软件工程师在较高级别上说明软件的某些特征。之后工具根据开发 者的说明自动生成源代码。毫无疑问软件在越高的级别上被说明，就能越快 地建造出程序。软件工程的 4GT 范型的应用关键在于说明软件的能力——它



① 在客户机/服务器应用软件中，软件功能被划分成两部分客户机端（通常是 PC 机）和服务器（通常是更
强大的计算机）端功能，服务器典型任务是维护一个中心数据库。

用一种特定的语言来完成或者以一种用户可以理解的问题描述方法来描述待 解决问题的图形来表示。
　　目前，一个支持 4GT 范型的软件开发环境包含如下部分或所有工具：数 据库查询的非过程语言，报告生成器，数据操纵，屏幕交互及定义，以及代 码生成；高级图形功能；电子表格功能。最初，上述的许多工具仅能用于特 定应用领域，但今天，4GT 环境已经扩展，能够满足大多数软件应用领域的 需要。
　　像其他范型一样，4GT 也是从需求收集这一步开始。理想情况下，用户 能够描述出需求，而这些需求能被直接转换成可操作原型。但这是不现实的， 用户可能不能确定需要什么；在说明已知的事实时，可能出现二义性；可能 不能够或是不愿意采用一个 4GT 工具可以理解的形式来说明信息。因此，其 他范型中所描述的用户——开发者对话方式在 4GT 方法中仍是一个必要的组 成部分。
　　对于较小的应用软件，使用一个非过程的第四代语言(4GL)有可能直接从 需求收集过渡到实现。但对于较大的应用软件，就有必要制订一个系统的设 计策略，即使是使用 4GL。对于较大项目，如果没有很好地设计，即使使用
4GT 也会产生不用任何方法来开发软件所遇到的同样的问题(低的质量、差的 可维护性、难以被用户接受)。
应用 4GL 的生成功能使得软件开发者能够以一种方式表示期望的输出，
这种方式使得可以自动生成产生该输出的代码。很显然，相关信息的数据结 构必须已经存，在且能够被 4GL 访问。
要将一个 4GT 生成的功能变成最终产品，开发者还必须进行测试，写出
有意义的文档，并完成其他软件工程范型中同样要求的所有集成活动。此外， 采用 4GT 开发的软件还必须考虑维护是否能够迅速实现。
像其他所有软件工程范型一样，4GT 模型也有优点和缺点。支持者认为
它极大地降低了软件的开发时间，并显著提高了建造软件的生产率。反对者 则认为目前的 4GT 工具并不比程序设计语言更容易使用，这类工具生成的结 果源代码是“低效的”，并且使用 4GT 开发的大型软件系统的可维护性是令 人怀疑的。
两方的说法中都有某些对的地方，这里我们对 4GT 方法的目前状态进行
一个总结：
　　1.在过去十余年中，4GT 的使用发展得很快，且目前已成为适用于多个 不同的应用领域的方法。与计算机辅助软件工程(CASE)工具和代码生成器结 合起来，4GT 为许多软件问题提供了可靠的解决方案。
　　2.从使用 4GT 的公司收集来的数据表明：在小型和中型的应用软件开发 中，它使软件的生产所需的时间大大降低，且使小型应用软件的分析和设计 所需的时间也降低了。
　　3.不过，在大型软件项目中使用 4GT，需要同样的甚至更多的分析、设 计和测试(软件工程活动)才能获得实际的时间节省，这主要是通过编码量的 减少赢得的。
　　总结一下，第四代技术已经成为软件开发的一个重要方法。当与构件组 装方法(见 2.7.3 节)结合起来时，4GT 范型可能成为软件开发的主流方法。

2.10 过程技术


前面几节讨论的过程模型必须适合于软件项目组的使用。为了满足这
点，开发了过程技术工具以帮助软件组织分析它们当前的过程，组织工作任 务，控制和监管进度，以及管理技术质量(参见文献［BAN95］)。
　　过程技术工具使得软件组织能够建造一个自动模型，该模型包含 2.2 节 讨论的通用过程框架、任务集合及保护性活动。该模型一般表示成一个网络， 对其加以分析，就能够确定典型的工作流程，考查可能导致降低开发时间和 成本的可选的过程结构。
　　一旦创建了一个可接受的过程，就可以使用其他过程技术工具来分配、 监管、甚至控制过程模型中定义的所有软件工程任务。软件项目组的每一个 成员均能使用这些工具产生一个清单，包括：要完成的工作任务，要开发的 工作产品，以及要实现的质量保证活动。过程技术工具还能用于协调适合某 一特定工作任务的其他计算机辅助软件工程工具(第 29 章)的使用。

2.11 产品和过程


　　如果过程很弱，最终产品不可避免会出问题。但过分依赖过程也是很危 险的。在一篇短文中，Margaret Davis［DAV95］评论了产品和过程的二元性： 大约每隔 5 至 10 年，软件界就会重定义“问题”，将其焦点从产品转移 到过程。这样，我们在结构化程序设计语言(产品)之后有了结构化分析方法 (过程)，之后又有了数据封装(产品)，再后是目前的重点——软件工程研究
所的软件开发能力成熟度模型(过程)。
　　正如钟摆的自然倾向是停在两个极端之间的中间点，软件界的焦点也是 在不断转移，因为当上一次摆动停止后，就要加新的力。这些摆动是有害的， 因为它们彻底改变了完成工作的方法，使普通的软件开发人员迷失方向，更 不用说要很好地使用它了。这些摆动也不能解决“问题”，因为它们注定是 要失败的，只要产品和过程变成是二分的而不再是二元的。
当观察到的矛盾无法用一个权威的理论或另一种方式完全解释时。科学
界率先提出了二元性的概念，光的二元特性——似乎同时是粒子和波，从本 世纪 20 年代 Louis de Brogile 提出时起就已经被广泛接受了。我相信软件 及其开发表现出了产品和过程之间的一个基本的二元性。当你仅仅从过程或 是仅仅从产品角度来看，你永远也不可能得到或理解整个软件，如它的范围、
使用、含义和价值。
　　所有人类的活动可能都是一个过程，但我们每一个人从其中得到了自我 价值的体现，这些 活动产生的一个表示或示例，或可被很多人反复使用，或 可用于某些其他未考虑到的背景上。即，我们的产品能被自己或他人复用， 从其中我们得到了一种满足感。
　　因此，在软件开发中迅速普及复用的目标，可能会提高软件开发者从他 们的工作中得到的满足感，也增加了接受产品和过程的二元性的紧迫感。仅 从产品或仅从过程考虑一个可复用的事物，或者会模糊了它的使用范围和方 式，或者会隐藏了某个事实：每一次使用它均会产生新的产品，该产品反过 来又可用作某个其他的软件开发活动的输入。仅考虑其中一方面，会急剧降 低复用的机会，也就失去了提高工作满足感的机会。
人们从创造的过程中得到了从最终的产品中同样的甚至更多的满足感。

一个艺术家从挥笔的过程和完成的画中会得到同样的享受。一个作家从冥思 苦想一个合适的比喻和写完的书中会得到同样的享受。一个有创造性的软件 专业人员也会从过程和最终的产品中得到同样的满足感。
　　软件人员的工作随着时间的推移会发生改变。产品和过程的二元性是一 个重要的因素，使得当从程序设计最终转移到软件工程的过程中，能够一直 保持人的创造力。

2.12 小结


　　软件工程在计算机软件的开发中集成了过程、方法和工具。本章给出了 若干不同的软件工程过程模型，每一个都有其优点和弱点，但它们均具有一 系列共同的一般阶段。使得我们能够实现在本书的其余部分将要一一探讨的 过程的原则、概念和方法。



思考题


　　2.1 图 2-1 中将三个软件工程层次置于一个名为“质量焦点”的层次之 上，该焦点是指一个质量程序，如全面质量管理。做一些研究并给出一个全 面质量管理程序的主要原则的概要。
2.2 是否存在一种情况，软件工程过程的一般阶段不适用？如果有，描
述出来。
　　2.3 SEI 的能力成熟度模型是一个演化的文档。做一些研究，并确定 在本书出版之后是否有新的 KPAs 增加？
2.4 “无序模型”认为一个问题循环解决过程能被用于开发的任何级别
上。讨论在下列情况下你如何应用这个循环过程：(1)理解一个新的字处理产 品的需求；(2)为字处理器开发一个高级拼写/文法检查构件；(3)产生一个程 序模块的源代码，该模块用于确定英语语句中的主语、谓语和宾语。
2.5 你认为本章给出的哪一个软件工程范型最有效？为什么？
　　2.6 给出 5 个可以采用原型方法的软件开发项目的实例。举出两或三个 难以使用原型的应用。
2.7 RAD 模型一般与 CASE 工具结合使用。研究一些文献，并总结出一
个典型的支持 RAD 的 CASE 工具。
　　2.8 举出一个可以采用增量模型的特定的软件项目。并给出在软件中应 用该模型的某个场景。
　　2.9 当沿着螺旋模型的过程流路径向外移时，你认为正在开发或维护的 软件发生了什么变化？
　　2.10 许多人相信极大地提高软件质量和生产率的唯一途径是运用构件 组装。找出 3 或 4 篇关于该题目的最新文章，并给出总结。可在班里进行讨 论。
2.11 用自己的话描述并发开发模型。
2.12 举出第四代技术的三个实例。
2.13 哪一个更重要——产品还是过程？

推荐阅读文献及其他信息源


　　软件工程的最新进展能够从一些月刊中得到，诸如 IEEE Software(IEEE 软件 ) ， Computer( 计算机 ) ，和 IEEE Transactions on Software Engineering(IEEE 软件工程学报)。产业界的一些期刊如 Application Development Trends(应用开发趋势)和 Software Development(软件开发)， 它们常常刊登软件工程方面的文章。每年 Proceedings of the International Conference onSoftware Engineering(国际软件工程会议论文集)中都会有一 个有关该专题的“摘要”(该会议由 IEEE 和 ACM 赞助)，并且在一些杂志上也 对此专题进行深入的讨论，如 ACM Transactions onSoftware Engineering
and Methodology(ACM 软件工程和方法学学报)，ACM SoftwareEngineering Notes(ACM 软件工程评论)有 Annals of Software Engineering(软件工程年 报)。
　　近年来很多软件工程方面的书籍出版了。其中一些给出了关于整个过程 的综述，而另外一些则深入研究了前者未探讨的若干重要的专题。下面三个 文集包含了范围很广的软件工程专题：
　　Keyes，J.(ed.)，Software Engineering Productivity Handbook， McGraw-Hill，1993.
Marchiniak，J.J.(ed.)，Encyclopedia of Software Engineering，
Wiley，1994.
McDermid，J.(ed.)，Software Engineer's Reference Book，CRC Press，
1993.
　　Gautier(Distributed Engineering of Software，Prentice-Hall，1996) 给那些必须跨地域开发软件的组织提出了一些建议和指南。
Robert Glass 的书(Software Conflict，Yourdon Press，1991)给出了
关于软件和软件工程的有趣的和引起争议的问题论述。 Pressman 和 Herron(Software Shock，Dorset House，1991)描述了软件及其对个人、商 业和政府的影响。
软件工程研究所(SEI 位于 Carnegie-Mellon 大学内)被授权负责发起一
组软件工程专刊系列的创刊。来自产业界、政府和学术界的实践者都为此做 出了重要的新贡献。另外，SoftwareProductivity Consortium(软件生产力 协会)会定期发表关于软件工程方面的出版物。
在过去十余年中，发布了很多软件工程的标准和规范。 IEEE Software
EngineeringStandards(IEEE 软件工程标准)中包含了几乎覆盖了所有重要 技术层面的多个不同的标准。ISO9000-3 指南为那些申请 ISO 9001 质量标准 认证的组织提供了指导。国防部、 FAA 及其他政府和非营利机构也发布了若 干软件工程标准。Fairclough(Software Engineering Guides，Prentice- Hall，1996)给出了关于欧洲太空署(European Space Agency， ESA)发布的 软件工程标准的详细参考。
　　在 Internet(因特网)上有大量关于软件工程和软件过程的资源。从一些 技术协会和组织还可以得到更多软件工程的信息：
ACM http://www.acm.org/：//www.acm.org
European SPI Initiative http ： //www.sea.uni- linz.ac.at/espiti/home.html

IEEE http://www.computer.org/：//www.computer.org
NASA Software Engineering Lab http：//fdd.gsfc.nasa.gov/seltext.html Research Access Clearing House http：//www.rai.com/Home Page.html Software Engineering Institute http://www.sei.cmu.edu/：//www.sei.cmu.edu/
Software Engineering Lab，EPFL http://www.epfl.ch/：//lglWWW.epfl.ch/
Software Engineering Web Sites http：//wwwsel.iit.nrc.ca/favourites.html
Software Productivity Center，Canada http：//www·spc·ca/spc/
Software Productivity Consortium http://software.software.org/vcoe：//software.software.org/vcoe /Home.html
　　关于软件工程的另一个有用的信息来源是一个时事通讯季刊，可在下面 的网址中找到它：
http：// www.tcse.org
　　软件工程研究中心(SERC)有一个技术报告系列给出最新的研究成果。可 以在下面的网址上找到：
http：//www.cs.purdue.edu/tech-reports/sere-orders.html
关于经常提出的问题(FAQ)的一个概要已经放在 Internet 新闻组
comp.software-eng 上，其网址为：
http：//www.qucis.queensu.ca/Software-Engineering/reading.html
　　一个最新的与软件过程相关的 WWW 参考文献目录可在下面的网址中找 到：http：//www.rspa.com.
　　
第二部分 软件项目的管理


　　在本书的这一部分中我们主要考虑计划、组织、监管和控制软件项目所 需要的管理技术。在下面的章节中，我们主要解决下列问题：
·在一个软件项目中如何管理人员、问题和过程？
·什么是软件度量？如何使用它们管理软件过程和过程指导下的项目？
　　·什么度量能够辅助管理者评估开发的产品的质量以及使用的过程的有 效性？
·一个软件项目组如何对工作量、成本和项目时间进行可靠的评估？
　　·一个组织何时应该建造软件？何时应该获取软件？何时应该请求外 援？
·采用什么技术评估来影响项目成功的风险？
　　·一个软件项目管理者如何为特定项目选择合适的软件工程工作任务 集？
·如何创建一个项目进度计划？
·如何定义质量使得软件项目组能够控制它？
·什么是软件质量保证？如何使用它作为项目控制机制？
·为什么正式的技术复审那么重要？
·在计算机软件开发之中以及它被交付给用户之后如何进行变化管理？ 认真回答这些问题使你能够以一种更好的方式管理软件，以便按时交付
高质量的产品。

第 3 章 项目管理的概念


　　在关于软件项目管理的论著的序言中， Meiler Page-Jones［PAG85］ 给出了一段引起许多软件工程顾问共鸣的陈述：
　　我拜访了很多商业公司(好的和不好的)，我也观察了很多数据处理的管 理者(好的和不好的)。我常常恐惧地看到这些管理者徒劳地与恶梦般的项目 斗争着，在根本不可能完成的最后期限下苦苦挣扎，或是在交付了使其用户 极为不满的系统之后，又继续花费大量的时间去维护该系统。
　　Page-Jones 所描述的正是源于一系列管理和技术问题而产生的症状。不 过，如果事后再剖析一下每一个项目，很有可能发现一个共同的问题：项目 管理太弱。
　　在本章和之后的六章中，我们将探讨进行有效的软件项目管理的关键性 概念。本章主要给出基本软件项目管理的概念和原则。第 4 章将阐述过程和 项目度量，这是进行有效的管理决策的基础。第 5 章将讨论用于评估成本和 资源需求，并建立有效的项目计划的技术。第 6 章会给出进行有效的风险监 控、缓解和管理的管理活动。第 7 章会讨论定义项目任务，并建立一个可操 作的项目进度计划所需的活动。最后，第 8 章和第 9 章将探讨在项目开发过 程中保证质量及在应用的整个生命期中控制变化所需的技术。

3.1 管理的范围


　　有效的项目管理集中于三个 P 上：人员(people)、问题(problem)和过程 (process)。其顺序不是任意的。任何管理者如果忘记了软件工程是人的智力 密集的劳动，他就永远不可能在项目管理上得到成功；任何管理者如果在项 目开发早期没有支持有效的用户通信，他有可能为错误的问题建造一个不错 的解决方案。最后，对过程不在意的管理者可能冒把有效的技术方法和工具 插入到真空中的风险。

3.1.1 人员


　　培养有创造力的、技术水平高的软件人员是从 60 年代起就开始讨论的话 题(如［COU80，DeM87，WIT94］)。事实上，“人因素”非常重要，以致于软 件工程研究所专门开发了一个人员管理能力成熟度模型(PM—CMM)，旨在“通 过吸引、培养、鼓励和留住改善其软件开发能力所需的人才增强软件组织承 担日益复杂的应用程序开发的能力，”(参见文献［CUR94］)。
　　人员管理成熟度模型为软件人员定义了以下的关键实践区域：招募，选 择，业绩管理，培训，报酬，专业发展，组织和工作计划，以及团队精神/ 企业文化培养。在人员管理上达到较高成熟度的组织，更有可能实现有效的 软件工程开发。
　　PM－CMM 与软件能力成熟度模型(第 2 章)相配合，后者指导组织完成一 个成熟的软件过程的创建。与软件项目的人员管理及结构相关的问题将在本 章后面的几小节中详细论述。

3.1.2 问题


在进行项目计划之前，应该首先明确该项目的目的和范围，考虑可选的
解决方案，定义技术和管理的约束。没有这些信息，就不可能进行合理的(准 确的)成本估算；有效的风险评估；适当的项目任务划分；或是给出了意义明 确的项目进度的标志的项目管理计划。
　　软件开发者和用户必须一起定义项目的目的和范围。在很多情况下，这 项活动是作为系统工程的一部分开始的(第 10 章)，持续到作为软件需求分析 的第一步(第 11 章)。目的说明该项目的总体目标，而不考虑这些目标如何实 现。范围说明给出与问题相关的主要数据、功能和行为，更为重要的是，它 以量化的方式约束了这些特性。
　　一旦了解了项目的目的和范围，就要开始考虑可选的解决方案了。虽然 这一步并不讨论细节，但它使得管理者和开发者可以选择一条“最好的”途 径，并根据产品交付的期限、预算的限制、可用的人员、技术接口及各种其 他因素，给出项目的约束。

3.1.3 过程


　　软件过程(第 2 章)提供了一个框架，在该框架下可以建立一个软件开发 的综合计划。若干框架活动适用于所有软件项目，而不在乎其规模和复杂性。 若干不同的任务集合——每一个集合都由任务、里程碑、交付物以及质量保 证点组成——使得框架活动适应于不同软件项目的特征和项目组的需求。最 后是保护性活动——如软件质量保证，软件配置管理，和测度——它们贯穿 于整个过程模型之中。保护性活动独立于任何一个框架活动，且贯穿于整个 过程之中。

3.2 人员


　　在 IEEE 发表的一项研究中［CUR88］，三个大型的技术公司的主管工程 的副总裁被问到一个成功软件项目中最重要的因素是什么。他们的回答如 下：
第一位：我想如果必须在我们的环境中挑出一项最重要的因素，我必须
承认它不是我们所用的工具，而是人。 第二位：一个项目成功的最重要的因素是有聪明的人??我想不出其他
的因素??你为一个项目所做的最重要的事情是选择人员??软件开发组织 的成功与其招募优秀人才的能力密切相关。
　　第三位：我在管理上唯一的准则是保证我有优秀的人员——真正优秀的 人员，同时我也培养优秀的人员——我提供培养优秀人员的良好环境。
　　事实上，这是对软件工程过程中人的重要性的强有力的证明。不过，我 们所有的人，从高级工程副总裁到低级的开发人员，常常认为人员是不成问 题的。管理者表态说(就象上面给出的)人员是主要的，但他们的行为有时与 说话不符。本节我们讨论参加软件过程的人员，以及如何组织他们实现有效 的软件工程的方式。

3.2.1 项目参与者


参与软件过程(及每一个软件项目)的人员可以分为以下五类：
1.高级管理者：负责确定商业问题，这些问题往往对项目产生很大影响。
2.项目(技术)管理者：必须计划、刺激、组织和控制软件开发人员。
3.开发人员：负责开发一个产品或应用软件所需的专门技术人员。
4.客户：负责说明待开发软件的需求的人员。
　　5.最终用户：一旦软件发布成为产品，最终用户是直接与软件进行交互 的人。
　　每一个软件项目都有上述的人员参与。为了获得很高的效率，项目组的 组织必须最大限度地发挥每个人的技术和能力。这是项目负责人的任务。

3.2.2 项目负责人


　　项目管理是集中于人的活动，因此，能胜任开发的人员常常有可能是拙 劣的项目负责人。他们完全没有管理人的技能。如 Edgemon 所说：“很不幸 而且是很经常地，似乎人们碰巧落在项目管理者的位置上，也就意外地成为 了项目管理者”［EDG95］。
当我们要选择某个人来领导一个软件项目时，我们应该考虑什么呢？在
一本优秀的关于领导能力的论著中，Jerry Weinberg［WEI86］给出了一个答 案，他提出领导能力的 MOI 模型：
刺激(Motivate)：鼓励(通过“推或拉”)技术人员发挥其最大能力的一
种能力。
　　组织(Organization)：融合已有的过程(或创造新的过程)的一种能力， 使得最初的概念能够转换成最终的产品。
想法(Ideas)或创新(Innovation)：鼓励人们去创造，并感到有创造性
的一种能力，即使他们其实必须工作在为特定软件产品或应用软件建立的约 束下。
Weinberg 提出：成功的项目负责人应采用一种解决问题的管理风格。
即，软件项目经理应该集中于理解待解决的问题，管理新想法的交流，同时， 让项目组的每一个人知道(通过言语，更重要的是通过行为)质量很重要，不 能妥协。
关于一个有效的项目经理应该具有什么特点的另一个观点［EDG95］则强
调了以下四种关键品质：
　　解决问题：一个有效的软件项目经理应该能够准确地诊断出技术的和管 理的问题；系统地计划解决方案；适当地刺激其他开发人员实现解决方案； 把从以前的项目中学到的经验应用到新的环境下；如果最初的解决方案没有 结果，能够灵活地改变方向。
　　管理者的身份：一个好的项目经理必须掌管整个项目。他在必要时必须 有信心进行控制，必须保证让优秀的技术人员能够按照他们的本性行事。
　　成就：为了提高项目组的生产率，项目经理必须奖励具有主动性和做出 成绩的人。并通过自己的行为表明约束下的冒险不会受到惩罚。
　　影响和队伍建设：一个有效的项目经理必须能够“读懂”人；他必须能 够理解语言的和非语言的信号，并对发出这些信号的人的要求做出反应。项 目经理必须在高压力的环境下保持良好的控制能力。
　　

3.2.3 软件项目组


　　软件开发的组织结构几乎与开发软件的组织一样多。不管怎么说，组织 结构不能轻易改变。关心组织改变所产生的实际的及政策上的影响，并不是 软件项目管理者的责任范围。但是，在一个新的软件项目中直接涉及到的人 员的组织，则是项目管理者的职责。
　　下面给出为一个项目分配人力资源的若干可选方案，该项目需要 n 个人 工作 k 年：
　　1.n 个人被分配来完成 m 个不同的功能任务，相对而言几乎没有合作的 情况发生；协调是软件管理者的责任，而他可能同时还有六个其他项目要管。
　　2.n 个人被分配来完成 m 个不同的功能任务(m＜n)，建立非正式的“小 组”；指定一个专门的小组负责人；小组之间的协调由软件管理者负责。
　　3.n 个人被分成 t 个小组；每一个小组完成一个或多个功能任务；每一 个小组有一个特定的结构，该结构是为同一个项目的所有小组定义的；协调 工作由小组和软件项目管理者共同控制。
　　虽然对于上述的每一种方法都可以找到其优点和缺点，但越来越多的证 据表明正式的组织小组(策 3 种方法)是生产率最高的。
“最好的”小组结构取决于组织的管理风格、组里的人员数目及他们的
技术水平和整个问题的难易程度。Mantei［MAN81］提出了三种一般的小组组 织方式：
民主分权式(Democratic Decentralized，DD)：这种软件工程小组没有
固定的负责人。“任务协调者是短期指定的，之后就由其他协调不同任务的 人取代”。问题和解决方法的确定是由小组讨论决策的。小组成员间的通信 是平行的。
控制分权式(Controlled Decentralized，CD)：这种软件工程小组有
一个固定的负责人，他协调特定的任务及负责子任务的二级负责人关系。问 题解决仍是一个群体活动，但解决方案的实现是由小组负责人在子组之间进 行划分的。子组和个人间的通信是平行的，但也会发生沿着控制层产生的上 下级的通信。
控制集权式(Controlled Centralized，CC)：顶层的问题解决和内部小
组协调是由小组负责人管理的。负责人和小组成员之间的通信是上下级式 的。
　　Mantei 还给出了计划软件工程小组的结构时应该考虑的七个项目因 素：
·待解决问题的困难程度。
·要产生的程序的规模，以代码行或者功能点来衡量。
·小组成员需要待在一起的时间(小组生命期)。
·问题能够被模块化的程度。
·待建造系统所要求的质量和可靠性。
·交付日期的严格程度。
·项目所需要的社交性(通信)的程度。
　　表 3－1［MAN81］总结了项目特性对小组组织的影响。因为集中式的结 构能够更快地完成任务，因此最适合处理简单问题。而分散式的小组比起个
　　
人而言能够产生更多更好的解决方案，因此，这种小组在处理复杂问题时成 功的可能性更大。因为 CD 小组是集中式地解决问题，所以 CD 或 CC 小组结构 能够成功地用来解决简单的问题。而 DD 结构则适于解决难度较大的问题。 因为小组的性能与必须进行的通信量成反比，所以很大的项目最好采用
CC 或 CD 结构的小组组织方式，如果子组能够很容易地协调的话。


表 3 － 1 项目特性对小组结构的影响 ［ MAN81 ］
小组类型： DD CD CC
难易程度
高 ×
低 × × 规模
大 × × 小 ×
小组生命期
短 × × 长 ×
模块化程度
高 × × 低 ×
可靠性
高 × ×
低 × 交付日期
紧 × 松 × ×
社交性
高 ×
低 × ×




小组“在一起”的时间的长短影响小组的士气。我们发现 DD 小组结构能
够产生较高的士气和工作满意度，因此适合生命期较长的小组。
　　DD 小组结构最适于解决模块化程度较低的问题，因为它需要更多的通 信。如果有可能要较高的模块化程度(这时人们自己做自己的事情)，则 CC
或 CD 结构更加合适。
　　CC 和 CD 小组已被发现能够产生比 DD 小组更少的缺陷，但这与小组所采 用的质量保证活动密切相关。分散式结构通常需要比集中式结构更多的时间 来完成一个项目，但如果要求高社交性，它是最适合的。
Constantine［CON93］提出了软件工程小组的四种“组织范型”：
　　1.封闭式范型：按照传统的权利层次来组织小组(类似 CC 小组)。这种小 组在开发与过去已经做过的产品类似的软件时十分有效，但在这种封闭式范 型下难以进行创新式的工作。
　　
　　2.随机式范型：松散地组织小组，并依赖于小组成员个人的主动性。当 需要创新或技术上的突破时，按照这种随机式范型组织的小组很有优势。但 当需要“有次序的执行”才能完成工作时，这种小组组织范型就会陷入困境。
　　3.开放式范型：试图以一种，既具有封闭式范型的控制性，又包含随机 式范型的创新性的方式来组织小组。工作的执行结合了大量的通信和基于小 组一致意见的决策。开放式范型小组结构特别适于解决复杂问题，但可能不 象其他类型小组那么效率高。
　　4.同步式范型：依赖于问题的自然划分，组织小组成员各自解决问题的 片断，他们之间没有什么主动的通信需要。
　　从历史角度看，最早的软件小组是控制集权式(CC)结构，原来称为主程 序员小组。这种结构由 Harlan Mills 首先提出，并由 Baker［BAK72］描述 出来。小组的核心是由以下人员组成的：一个高级工程师(“主程序员”)， 负责计划、协调和复审小组的所有技术活动；技术人员(一般 2 到 5 个人)， 执行分析和开发活动；以及一个后备工程师，支持高级工程师的活动，并能 在项目进行过程中，以最小的代价取代高级工程师的工作。
　　主程序员可以由一个或多个专家(如电讯专家，数据库设计者)、支持人 员(如技术文档写作者，行政人员)和软件资料员来担当。资料员为多个小组 服务，执行以下功能：维护和控制所有软件配置(如文档，源程序，数据和磁 介质)；帮助收集和格式化软件生产数据；分类和索引可复用软件模块；辅助 小组进行研究、评估及文档准备。资料员的重要性不能过分强调。资料员充 当了软件配置的控制者、协调者及潜在的评估者。
不考虑小组的组织，每一个项目管理者的目标都是帮助建立一个有凝聚
力的小组。在“人”的论著中，DeMarco 和 Lister［DeM87］讨论了这个问题： 我们在商业中随便使用小组这个词，把任何被分配在一起工作的一组人 都称为一个“小组”。但很多这样的组并不象小组，它没有统一的对于成功 的定义，没有任何可标识的团队精神，它们所缺少的是一种很珍贵的东西，
我们称之为凝聚力。
　　一个有凝聚力的小组是一组团结紧密的人，他们的整体力量大于个体力 量的总和??
一旦一个小组具有凝聚力，成功的可能性就大大提高。这个小组不可阻
挡，成为成功的象征??他们不需要按照传统的方式进行管理，也不需要去 激励。他们已经有了动力。
DeMarco 和 Lister 认为有凝聚力小组的成员比起一般的小组而言，具有
更高的生产率和更大的动力。他们共享一个共同的目标、共同的文化，而且 在很多情况下，“精英的感觉”使得他们独一无二。

3.2.4 协调和通信问题


　　有很多原因会使软件项目陷入困境。许多开发项目规模宏大，以致于使 小组成员间的关系复杂性高、混乱、难以协调。不确定性是经常存在的，它 会引起困扰项目组的一连串的改变。互操作性已成为许多系统的关键特性。 新的软件必须与已有的软件通信，并遵从系统或产品所加诸的预定义约束。 现代软件的这些特性——规模、不确定性和互操作性——都是现实的问 题。为了有效地处理它们，软件工程小组必须建立有效的方法，以协调参与
　　
工作的人员之间的关系。要完成这项任务，必须建立小组成员之间及多个小 组之间的正式的和非正式的通信机制。正式的通信是通过“文字、会议及其 他相对而言非交互的和非个人的通信渠道”来实现［KRA95］。非正式的通信 则更加个人化。软件工程小组的成员在一个特别的基础上共享想法，出现问 题时相互帮助，且每天互相交流。
　　Kraul 和 Streeter［KRA95］调查了一系列的项目协调技术，并将其分为 以下几类：
　　正式的、非个人的方法：包括软件工程文档和交付物(如源程序)、技术 备忘录、项目里程碑、进度和项目控制工具(第 7 章)、修改请求及相关文档(第
9 章)、错误跟踪报告、和中心库数据(第 29 章)。 正式的、个人间的规程：集中表现于软件工程工作中产品的质量保证活
动中(第 8 章)。包括状态复审会议及设计和代码检查。 非正式的、个人间的规程：包括信息传播、问题解决及“需求和开发人
员配置”的小组会议。
　　电子通信：包括电子邮件、电子公告栏、Web 站点以及基于视频的会议 系统。
　　个人间的网络：与项目组之外的人进行的非正式的讨论，这些人可能有 足够的经验或见解，能够帮助项目组成员。
为了评估这些项目协调技术的功效，Kraul 和 Streeter 调研了 65 个软
件项目，其中包括上百个技术人员。图 3－1［KRA95］中描述的变种)表明了 上述协调技术的价值及使用。在图中给出了不同的协调和通信技术的认知价 值(总分为 7)及它们在项目中的使用频率之间的关系。落在回归线之上的技 术“被判定为相对而言价值较高，已给出了它们被使用的总量”［KRA95］。 落在线之下的技术被认为价值较低(相对于使用频率而言)。有趣的是，个人 间网络(对等讨论)被评为具有最高的协调和通信价值的技术。还有一点很重 要的是，早期的质量保证机制(需求和设计复审)被认为比起后期的源代码评 估(代码检查)更具价值。
■

3.3 问题


　　软件项目管理者从软件工程项目一开始就面临着进退两难的局面。需要 定量的估算成本和有组织的计划项目的进展，但却没有可靠的信息可以使 用。对软件需求的详细分析可以提供必要的估算信息，但分析常常要花数周 甚至数月的时间才能完成。更糟糕的是，随着项目的进展经常发生改变，需 求可能是不固定的。不过，无论如何计划仍是“现在”就需要的！

3.3.1 软件范围


　　软件项目管理的第一个活动是软件范围的确定。范围是通过回答下列问 题来定义的：
　　背景：待建造的软件如何适应于大型的系统、产品或商业的背景，在该 背景下要加什么约束？
信息目标：软件要产生什么样的客户可见的数据对象(第 11 章)来作为输

出使用？需要什么样的数据对象作为输入？ 功能和性能：软件要执行什么样的功能使得输入数据才能变换成为输出
数据？需要满足什么特殊的性能特征吗？ 软件项目范围在管理层和技术层都必须是无二义性的和可理解的。对软
件范围的描述必须是界定的。即，明确给出定量的数据(如并发用户数目、邮 件列表的大小、允许的最大响应时间)；说明约束和/或限制(如产品成本、内 存大小)；描述其他的特殊因素(如要用的算法能够很好地理解，并写成 C++ 程序)。

3.3.2 问题分解


　　问题分解，有时称为划分，是一个软件需求分析(第 11 章)的核心活动。 在确定软件范围的活动中并没有完全分解问题。分解一般用于两个主要领 域：(1)必须交付的功能；(2)交付所用的过程。
　　面对复杂的问题人类常常采用分而治之的策略。简单讲，就是将一个复 杂的问题划分成若干较易处理的小问题。这是项目计划开始时所采用的策 略。在估算开始之前，范围中所描述的软件功能必须被评估和精化，以提供 更多的细节。因为成本和进度估算都是面向功能的，所以某种程度的分解是 很有用的。
例如，考虑我们要建造一个新的字处理产品的项目。该产品的特殊功能
包括：连续的语音输入和键盘输入；高级的“自动拷贝编辑”功能；页面布 局功能；自动建立索引和目录；以及其他功能。项目管理者必须首先建立软 件范围描述，规定这些功能(以及其他的通用功能，如编辑、文件管理、文档 生成等等)。例如，连续语音输入功能是否需要对用户进行专门的产品“培 训”？拷贝编辑功能提供了哪些能力？页面布局功能要到什么程度？
随着范围描述的进展，自然产生了第一级划分。项目组研究市场部与潜
在用户的交谈资料，并找出自动拷贝编辑应该具有下列功能：
·拼写检查。
·语句文法检查。
　　·大型文档的参考书目关联检查(如对一本参考书的引用是否能在参考书 目列表中找到？)。
·大型文档中章节的参考书目关联的验证。
　　其中每一项都是软件要实现的子功能。同时，如果分解可以使计划更简 单，则每一项又可以进一步精化。

3.4 过程


　　软件过程的一般阶段(定义、开发和维护)适用于所有软件项目。问题在 于如何选择一个适合项目组要开发的软件的过程模型。在第 2 章中，讨论了 多种软件工程范型：·线性顺序模型。
·原型模型。
·RAD 模型。
·增量模型。
·螺旋模型。

·构件组装模型。
·并发开发模型。
·形式化方法模型。
·第四代技术模型。 项目管理者必须决定哪一个过程模型最适合待开发项目，然后基于公共
过程框架活动集合，定义一个初步的计划。一旦建立了初步的计划，便可以 开始进行过程分解，即必须建立一个完整的计划，以反映框架活动中所需要 的工作任务。我们在下面的小节中简要讨论了这些活动，在第 7 章中将给出 更详细的信息。

3.4.1 合并问题和过程


　　项目计划开始于问题和过程的合并。软件项目组要开发的每一个功能都 必须通过为软件组织定义的框架活动集合来完成。假设组织采用了如下的框 架活动集合(第 2 章)：
■ 一般过程框架活动\用户通信\计划\风险分析\工程\ 软件工程任务\\\\\
产品功能\\\\\ 正文输入\\\\\ 编辑及格式设计\\\\\ 自动拷贝编辑\\\\\ 页面布局\\\\\ 自动建立索引及目录\\\\\ 文件管理\\\\\ 文档生成\\\\\
图 3－2 合并问题和过程
·用户通信——建立开发者和用户之间有效通信所需要的任务。
·计划——定义资源、进度及其他相关项目信息所需要的任务。
·风险分析——评估技术的及管理的风险所需要的任务。
·工程——建立应用的一个或多个表示所需要的任务。
　　·建造及发布——建造、测试、安装和提供用户支持(如文档及培训)所 需要的任务。
　　·用户评估——基于在工程阶段产生的或在安装阶段实现的软件表示的 评估，获得用户反馈所需要的任务。
　　开发每一个功能的项目组成员都要将每一个框架活动应用于该功能的实 现上。实质上，产生了一个类似图 3－2 所示的矩阵。每一个主要的问题功能 (图中列出了前述的字处理软件的功能)被列在左手边的一列中。框架活动则 列在顶端的一行中。软件工程工作任务(对于每一个框架活动)列在紧接着的 行中(应该注意到工作任务必须适应于项目的特定需要。框架活动总是一样 的，但工作任务则要根据一系列的适应性标准来选择)。项目管理者(和其他 组员)的工作是估算每一个矩阵单元的资源需求、与每一个单元相关的任务的 开始和结束日期、及每一个单元所产生的工作产品。这些问题将在第 5 和第
7 章探讨。


3.4.2 过程分解


　　软件项目组在选择最适合项目的软件工程范型、以及选定的过程模型中 所包含的软件工程任务时，应该有很大的灵活度。一个相对较小的项目如果 与以前已开发过的项目相似，可以采用线性顺序模型。如果时间要求很紧， 且问题能够被很好地划分，RAD 模型可能是正确的选择。如果时间太紧，不 可能完成所有功能时，增量模型可能是最合适的。同样地，具有其他特性(如 不确定的需求、突破性的技术、困难的用户、明显的复用潜力等)的项目将导 致选择其他过程模型(回忆一下项目的特性，对开发该项目的小组的结构也有 巨大影响，见 3.2.3 节)。
　　一旦选定了过程模型，公共过程框架(Common Process Framework， CPF) 应该适于它。本章较早讨论的 CPF——用户通信，计划，风险分析，工程， 建造及发布，用户评估——能够适用于范型。它可以用于线性模型，还可用 于迭代和增量模型、演化模型、甚至是并发或构件组装模型。CPF 是不变的， 充当一个软件组织所执行的所有软件工作的基础。
　　但实际的工作任务却是可变的。当项目管理者问到下面的问题时过程分 解就开始了：“我们如何完成这个 CPF 活动？”。例如，一个小型的、相对 简单的项目在用户通信活动中可能需要下列工作任务来完成：
1.列出需澄清问题的清单。
2.与用户见面说明需澄清的问题。
3.共同给出范围描述。
4.就所关心的问题复审范围描述。
5.根据需求修改范围描述。
　　这些事件可能在不到 48 小时的时间内发生。它们代表了适于小型的、相 对简单的项目的一种过程分解。
现在，我们考虑一个复杂些的项目，它具有更广的范围和更重要的商业
影响。这样一个项目在用户通信活动中可能需要下列工作任务来完成：
1.复审用户要求。
2.计划和安排与用户进行正式的、卓有成效的会议。
3.研究如何定义推荐的解决方案和已有的方法。
4.为正式的会议准备一份“工作文档”和议程。
5.召开会议。
6.共同制订能够反映软件的数据、功能和行为特性的小的规格说明书。
7.复审每一份小的规格说明书，确认其正确性、一致性和无二义性。
8.把这些小的规格说明书组装起来形成一份范围文档。
9.就所关心的问题复审范围文档。
10.根据需求修改范围文档。 两个项目都执行了我们称之为用户通信的框架活动，但第一个项目组只
执行了第二个项目组一半的软件工程工作任务。

3.5 项目

疲惫不堪的产业专家们在讨论特别困难的软件项目时，常常提及 90—90

规则：一个系统的第一个 90％花费了所分配工作量和时间的 90％。系统最后
的 10％也会花费所分配工作量和时间的 90％［ZAH94］。这段陈述告诉了我 们很多关于一个项目陷入困境的情况：
　　·评估进度所采用的方法是有缺陷的。(很显然，如果 90—90 规则是真 的，90％的完成度就不是一个准确的指标！)
·没有办法测定进度，因为没有可用的量化的度量。
·项目计划在项目结束时没有考虑协调所需要的资源。
·没有明确地考虑风险，没有建立缓解、监控和管理风险的计划。
·进度计划是(1)不现实的，或(2)有缺陷的。 为了克服这些问题，在项目开始时必须花时间建立一个现实的计划，在
项目进行中监控该计划，并在项目整个过程中控制质量和变化。花费这些时 间的活动将在下一章中详细讨论。

3.6 小结


　　软件项目管理是软件工程的保护性活动。它先于任何技术活动之前开 始，且持续贯穿于整个计算机软件的定义、开发和维护之中。
三个 P 对软件项目管理具有本质的影响——人员、问题和过程。人员必
须被组织成有效率的小组，激发他们进行高质量的软件工作，并协调他们实 现高效的通信。问题必须由用户与开发者交流，划分(分解)成较小的组成部 分，并分配给软件小组。过程必须适应于人员和问题。选择一个公共过程框 架，采用一个合适的软件工程范型，并挑选一个工作任务集合来完成项目的 开发。
所有软件项目中最关键的因素是人员。软件工程师可以按照不同的小组
结构来组织，从传统的控制层到“开放式范型”的小组。可以采用多种协调 和通信技术来支持项目组的工作。一般而言，正式的复审和非正式的个人间 通信对开发者最有价值。
项目管理活动包含测度和度量、估算、风险分析、进度安排、跟踪和控
制。这些题目在下面的章节中将进一步探讨。



思考题


　　3.1 基于本章给出的信息和自己的经验，列举能够增强软件工程师能力 的“十条戒律”。即，列出 10 条指导原则，使得软件人员能够在工作中发挥 其全部潜力。
　　3.2 软件工程研究所的人员管理能力成熟度模型(PM—CMM)定义了培养 优秀软件人员的“关键实践区域”。你的老师将为你指派一个关键实践区域， 请你分析和总结该区域。
　　3.3 描述三种现实生活中的实际情况，其中客户和最终用户是相同的 人。也描述三种他们是不同的人的情况。
　　3.4 高级管理者所做的决策会对软件工程项目组的效率产生重大的影 响。请列举五个实例来说明这是真的。
3.5 复习一下 Weinberg 的书［WEI86］，并写出一份二三页的总结，说

明在使用 MOI 模型时 应该考虑的问题。
　　3.6 在一个信息系统组织中，你被指派为项目管理者。你的工作是建造 一个应用程序，类似于你的小组以前已经做过的项目，虽然这一个规模更大 且更复杂一些。需求已经由用户写成文档。你会选择哪种小组结构？为什么？ 你会选择哪(些)种软件过程模型？为什么？
　　3.7 你被指派为一个小型软件产品公司的项目管理者。你的工作是建造 一个具有突破性的产品，该产品结合了虚拟现实的硬件和高超的软件。因为 家庭娱乐市场的竞争非常激烈，完成这项工作的压力很大。你会选择哪种小 组结构？为什么？你会选择哪(些)种软件过程模型？为什么？
　　3.8 你被指派为一个大型软件产品公司的项目管理者。你的工作是管理 该公司已被广泛使用的字处理软件的新版本的开发。因为竞争激烈，已经规 定了严格的期限，并对外公布。你会选择哪种小组结构？为什么？你会选择 哪(些)种软件过程模型？为什么？
　　3.9 在一个为遗传工程领域服务的公司中，你被指派为项目管理者。你 的工作是管理一个新软件产品的开发，该产品能够加速基因分类的速度。这 项工作是面向研究及开发(R＆D)的，但其目标是在下一年内生成产品。你会 选择哪种小组结构？为什么？你会选择哪(些)种软件过程模型？为什么？
3.10 基于图 3－1 中给出的研究结果，文档被认为其价值远比实用性要
差。你认为为什么会出现这种情况？如何做才能使“文档”的数据点移到图 中回归线之上？即，如何做才能改进文档的认知价值。
3.11 你被要求开发一个小型应用软件，它的作用是分析一所大学提供的
每一门课程，并输出这门课的平均成绩(对于一个给定的学期)。写出该问题 的范围描述。
3.12 给出 3.3.2 节讨论的页面布局功能的第一级分解。

推荐阅读文献及其他信息源


　　由 Weinberg 所著的 3 册一套的系列丛书 (Quality Software Management，高质量软件管理，Dorset，1992，1993，1994)介绍了基本的系 统思想和管理概念，解释了如何有效地使用测度，并说明了“一致的行为”， 即建立管理者的需要、技术人员的需要及商业的需要之间的配合能力。它给 新的及有经验的管理者都提供了有用的信息。Brooks(The Mythical Man－ Month，神话般的人月，Anniversary Edition，Addison－Wesley，1995)更 新了他的杰作，给出了关于软件项目及管理问题的新见解。Purba 和 Shah(How
to Manage a Successful Software Project，如何管理一个成功的软件项目， Wiley，1995)提出了很多案例研究，指出为什么一些项目能成功，而另外一 些则失败。Bennatan(Software Project Management in a Client/Server Environment，客户机/服务器环境中的软件项目管理，Wiley，1995)讨论了 与客户机/服务器系统的开发相关的特殊的管理问题。
　　Weinberg 的另外一本优秀的论著［WEI86］是每一个项目管理者和每一 个小组负责人必读的书籍。它能指导你更加有效地进行工作。House(The Human Side of Project Management ， Addison － Wesley ， 1988) 和 Crosby(Running Things：The Art of Making Things Happen，McGraw－Hill，
1989)为必须处理人员及技术问题的管理者提供了实用的建议。DeMarco 和

Lister［DeM87］及 Weinberg(Understanding the Professional Programmer， Dorset House，1988)的论著中对软件人员及其管理方法提供了有用的建议。 以下一些书中也给出了关于项目管理的实用指南： Wysocki et al.(Effective ProjectManagement ， Wiley ， 1996) ， Metzger 和 Boddie(Managing a Programming Project ： Processes andPeople ， 3rd edition，Prentice－Hall，1995)，以及 O'Connell(How To Run Successful Projects ， Prentice － Hall ， 1994) 。 Constantine(Constantine on Peopleware，Prentice－Hall，1995)也论述了软件领域中的项目管理。 McCarthy(Dynamics of Software Development，Microsoft Press，1995)
写了一本有见解的书，探讨了按照进度计划交付“大型软件”的规则。 一个很好的关于项目管理的资源——其中包括有有用的信息及丰富的书
籍、工具和培训参考——可在下面的网址上找到：
　　http://www.cis.ohio-state.edu/hypertext/faq/usenet/proj- planfaq/faq.html
　　Project 2000(PS 2000)是欧洲的一个研究及开发关于项目管理的程序。 大量有用的信息和指南可在如下网址上找到：
http：//www.ntnu.no/ps2000/welcome.html
　　项目管理研究所的站点上包含了关于项目管理教育计划、出版物、特殊 兴趣小组及工具的信息：
http://www.pmi.org/
一个最新的关于软件项目管理的参考文献目录可在下面的网址上找到：
http://www.rspa.com