2004计算机软件工程考研串讲之六：自考学院|希赛网|中国系统分析师/中国系统分析员

(2) 自底向上的估计法
这种方法的主要思想是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量。
它的优点是估算各个部分的准确性高。缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量.
(3) 差别估计法
这种方法综合了上述两种方法的优点，其主要思想是把待开发的软件项目与过去已完成的软件项目进行类比，从其开发的各个子任务中区分出类似的部分和不同的部分。
类似的部分按实际量进行计算，不同的部分则采用相应方法进行估算。

(4) 专家判定技术
由多位专家进行估算，取得多个估算值。再把这些估算值合成一个估算值。
一种合成方法是求各估算值的中值或平均值。其优点是简便。缺点是可能会由于受一、二个极端估算值的影响而产生严重的偏差。
另一种合成方法是召开小组会，使各位专家们统一于或至少同意某一个估算值。优点是可以摈弃蒙昧无知的估算值，缺点是一些组员可能会受权威或政治因素的影响。
(5) 标准Deiphi技术
组织者发给每位专家一份软件系统规格说明书和一张记录估算值的表格，请他们估算。
专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即：ai (最小), mi (可能), bi (最大), 无记名地填写表格。
组织者整理专家们填在表格中的答复：
计算各专家估算的期望值 Ei;
对专家的估算结果分类摘要。

在综合专家估算结果的基础上，组织专家再次无记名地填写表格。比较两次估算的结果。若差异很大，要通过查询找出差异的原因。
上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模 (源代码行数)。
最后，通过与历史资料进行类比，根据过去完成软件项目的规模和成本等信息，推算出该软件每行源代码所需要的成本。然后再乘以该软件源代码行数的估算值，就可得到该软件的成本估算值。
3) 软件开发成本估算的经验模型
软件开发成本估算是依据开发成本估算模型进行估算的。
开发成本估算模型通常采用经验公式来预测软件项目计划所需要的成本、工作量和进度数据。
用以支持大多数模型的经验数据都是从有限的一些项目样本中得到的。
(1) IBM模型 (Walston-Felix)
E ＝ 5.2×(KLOC)0.91
D ＝ 4.1×(KLOC) 0.36 ＝ 14.47×E0.35
S ＝ 0.54×E0.6
DOC ＝ 49×(KLOC) 1.01
KLOC是千源代码行数，E是工作量 (PM)，D 是项目持续时间(月)，S 是人员需要量 (人)，DOC是文档数量 (页)。
IBM模型是一种静态单变量模型.
(2) Putnam 模型
Putnam模型是一种动态多变量模型。适用于大型项目，但也可以应用在一些较小的软件项目中。
它是假定在软件开发的整个生存期中工作量有特定的分布。
大型软件项目的开发工作量分布可以用Rayleigh-Norden曲线表示。

用Rayleigh-Norden曲线可以导出一个“软件方程”

td 是开发持续时间 (年)
K 是软件开发与维护在内的整个生存期所花费的工作量 (人年)
L 是源代码行数 (LOC)
Ck 是技术状态常数，因开发环境而异。
技术状态常数Ck的取值
(3) COCOMO模型（COnstructive COst MOdel）
结构型成本估算模型是一种精确、易于使用的成本估算方法。
DSI（源指令条数）定义为代码的源程序行数。若一行有两个语句，则算做一条指令。它包括作业控制语句和格式语句，但不包括注释语句。
KDSI＝1024 DSI
MM（度量单位为人月）表示开发工作量。
TDEV（度量单位为月）表示开发进度。

软件开发项目的总体类型:
组织型不涉及硬件的开发
嵌入型完全与硬件结合的开发
半独立型介于上述两者之间
COCOMO模型按其详细程度分成三级：
基本COCOMO模型
中间COCOMO模型
详细COCOMO模型
基本COCOMO模型是静态单变量模型，用源代码行数(LOC) 为自变量的经验函数计算软件开发工作量。

中间COCOMO模型在用LOC为自变量的函数计算软件开发工作量（称为名义工作量）的基础上，用涉及产品、硬件、人员、项目等方面的影响因素调整工作量估算。
详细COCOMO模型包括中间COCO MO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（分析、设计等）的影响。
基本COCOMO模型
基本COCOMO模型的工作量和进度公式
中间COCOMO模型
进一步考虑 15 种影响软件工作量的因素，通过定下乘法因子，修正 COCOMO 工作量公式和进度公式，可以更合理地估算软件（各阶段）的工作量和进度。
此时，工作量计算公式改成

中间COCOMO模型的名义工作量与进度公式如下所示。

15种影响软件工作量的因素 fi
产品因素：软件可靠性、数据库规模、产品复杂性
硬件因素：执行时间限制、存储限制、虚拟机易变性、环境周转时间
人的因素：分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验
项目因素：现代程序设计技术、软件工具的使用、开发进度限制

例1. 一个 32 KDSI 的声音输入系统是一个输入原型，或是一个可行性表演模型。所需可靠性非常低。把此模型看做半独立型软件。则有 MM ＝ 3.0（32）1.12 ＝ 146 又查表知 f1＝0.75，其它 fi＝1.00，则最终有
MM ＝ 146×0.75 ＝ 110.

例2. 一个规模为10KDSI的商用微机远程通信的嵌入型软件，使用中间COCOMO模型进行成本估算。
程序名义工作量
MM＝2.8 (10)1.20＝44.38（MM）
程序实际工作量
MM＝44.38× ＝44.38×1.17＝51.5 (MM)
开发所用时间
TDEV ＝ 2.5 (51.5)0.32 ＝ 8.9 （月）

详细COCOMO模型
详细COCOMO模型的名义工作量公式和进度公式与中间COCOMO模型相同。
工作量因素分级表分层、分阶段给出。针对每一个影响因素，按模块层、子系统层、系统层，有三张工作量因素分级表，供不同层次的估算使用。每一张表中工作量因素又按开发各个不同阶段给出。
(4) COCOMO-2模型
COCOMO模型适用于专用的定制的软件项目。1997年Boehm等人提出来的COCOMO-2模型则适用于广泛汇集各种技术的软件项目，如商用软件、面向对象软件、通过螺旋型或演化型开发模型制作的软件。
COCOMO-2模型有三种：应用组合模型（用于早期原型）、更详细的早期设计模型和后续的后架构模型。
应用组合模型
该模型用于在软件开发早期，支持对原型开发项目所需工作量的估算，同时也支持基于已有构件进行开发的软件项目。
模型使用加权“对象点”，而不用“源代码行”进行估算。
对象点不是面向对象软件开发方法所产生的对象类。与功能点一样，是一种软件间接度量。根据(用户界面)屏幕数、报表数、建造应用可能需要的构件数来进行加权计算。

对于独立的屏幕数和报表数，可按下表判断其复杂性：

每一个屏幕或报表可以按照上表划分到三个复杂性级别（简单、中等、困难）。

复杂性根据客户机、服务器数据表的数量，屏幕或报表的视图或屏幕的数量而定。
一旦确定了复杂性，屏幕、报表和构件的计数按下表加权，以调整工作量。

将各个对象的加权计数累加，得到总的对象点计数。如果开发中使用了构件或复用了以前的软件，再估计复用的百分比 reuse。
通过以下公式得到调整后的对象点计数（称为新对象点 NOP）:
NOP = (对象点计数)×(100 - reuse) / 100
为了基于新对象点估算工作量，考虑“生产率”这一概念，它的单位是：
PROD = NOP/人月
模型开发者给出了不同生产率的水平：
基于开发者经验和开发环境成熟度的平均生产率
估算工作量 (PM：人月)
PM = NOP / PROD
早期设计模型
该模型在系统需求的初始设计实现的情形下使用，用于评价软件/系统架构和操作概念。
估算是基于功能点的。首先估算功能点，然后把这些功能点根据下表转换为源程序代码行数（LOC）。
早期设计模型的方程为：
PM = a(KLOC)b×EAF
其中，a是常数(= 2.45)。EAF是工作量调整因素。
每个功能点的编程语言级别和源代码语句范围

指数 b 可以取COCOMO 1中的三个可能值之一，具体取值与项目的复杂程度有关。
通过分析下表所示的 5 个伸缩因子来计算指数。这些因子有六个等级，从“很低”到“极高”，分别赋予 5～0 值，将这些估算值相加除以 100，再加上 1.01，就得到该指数的取值。
例如，一个机构正承担一个项目，结构对于该项目所在领域没有经验。项目客户没有定义需采用的过程，在项目进展中没有做重大风险分析，还需组织新的开发团队来完成这个系统。
计算指数的伸缩因子

（续前）该机构最近刚实行过程改善计划，并且依据CMM模型被评为 2 级机构。在进行指数计算时，上述伸缩因子取值为：
先例的援引机构的新项目，取值“低”(4)
开发灵活性无客户介入，取值“很高”(1)
体系结构/风险解决无风险分析，取值“很低”(5)
团队凝聚力新团队，取值“一般”(3)
过程成熟度有些过程控制，取值“一般” (3)
取值总和为16，计算得到的指数为1.17。

可按下表中的7个早期设计的成本驱动因素来计算工作量调整因素 EAF，就像COCOMO模型那样。
后架构模型
一旦系统体系结构设计出来，就可以作出更精确的估算。该模型用于产品实际开发和维护。
在该模型中可以使用功能点或LOC，其中的修正是为复用和软件破坏而设。
后结构模型的方程为
E = a(KLOC)b×EAF
其中，a设为2.55，b仍按下式计算：
b = 1.01 + SUM(wi) / 100
其中，Wi 仍按下表的 5 个伸缩因子设定。
COCOMO-2的伸缩因子
这 5 个伸缩因子代替了原来COCOMO模型中的项目类型（组织型、半独立型和嵌入型）

利用下面的后架构成本驱动因素 fi，计算EAF，调整工作量。

软件项目计划的制定
对于任何软件工程项目来说，其目标都是希望按期、按预算开发出满足用户需求的、高可靠的、高性能的软件产品。项目计划是实现这个目标的基础。
项目计划是为实现预定目标而作的科学预测，它确定未来的行动方针和资源分配，引导项目的实施。项目计划的质量是决定项目成败、优劣的关键因素之一。

对于任何类型的项目制定计划必须解决五个问题：项目做什么？如何做？谁来做？何时做？成本如何？为此，项目策划必须做到：
确定并描述为完成项目目标所需的各项任务（活动），包括风险；
确定负责执行各项任务（活动）的所有人员及其职责；
制定各项任务（活动）的进度表；
阐明每项任务所必需的人力、物力和财力；
确定每项任务的预算。
IEEE软件项目计划标准（1058.1）
标题页
修改历史，前言，目录，图，表
第一部分引言
项目概述，项目交付物（对外交付和对内交付），软件项目计划的进化，参考材料，定义与术语
第二部分项目组织（与顾客、管理部门、其他组的关系）

项目模型（包括组织结构，组织的边界和接口），项目职责
第三部分管理过程
管理目标和优先级，假定、依赖关系和限制，风险管理，监督和控制机制，人员配备计划
第四部分技术过程
方法、工具和技术，软件文档，项目支持功能
第五部分工作包、进度和预算
工作包/工作分解，依赖关系，资源要求，预算和资源的分配，进度

第六部分附加成分
分包合同（子合同）管理计划，保密计划，验证和确认计划，培训计划，硬件购买计划，设施计划，安装计划，数据转换计划，系统转变计划，产品维护计划，……
此外，做项目计划时，还有组织机构、进度安排、资源安排等问题。许多项目管理的技术，如 PERT/CRM 网络、甘特图等都能够使用。
与软件项目策划有关的问题
估算
预计实施的结果就是估算。估算是合理计划的基础，没有估算就不可能有有用的计划。
选择科学的估算方法
项目进程中，计划要不断修订，每次修订必须作估算。只有对项目选定能够改进的估算方法，多次估算的结果才能作比较，才能积累经验和数据，估算才能更准确。

必须积累本组织的数据
生产率分布数据以往项目每个阶段工作量的大小。
生产率数据本组织以往项目的生产率数据（如小时/功能点），它与工具、方法和过程有关。
管理成本本组织以往项目的管理工作量大小（一般认定它是开发工作量的一个百分比）。
按归档化规程进行估算

为确保估算的有效性，结果的可比性，必须描述项目进行估算的具体步骤－规程。这样可确保估算的可重复性。CMM 2级 CPP要求 4 个文档化估算规程：
估算假定要记入文档。
如有历史数据则是用历史数据。
估算要经过评审。
规模估算是多种估算的基础。
对估算的几个建议
首先下功夫使需求规格说明详细、清晰；

尽可能将工作分解得详细；
最好采用估算技术的组合，对不同的软件成分采用不同的估算技术；
对同一对象采用不同的估算技术，比较其结果，从而得出较精确的估算；
注意采集数据，比较实际值与估算值，不断修订估算值和估算模型的参数。
风险管理
从某种意义上讲，项目管理就是风险管理。
充分认识风险的动态性（随时间变化）；

评估风险的主要方法是“头脑风暴法”（开会讨论集思广益，这样易于起步）；
注意风险数据的积累。
约定
做计划时需与各方协商，将各方的承诺（约定）记入计划中。
约定有对外约定和对内约定：
对外约定是与用户、分包商有关的约定；
对内约定一是项目组与组织内部其他组的约定，一是项目组内部的约定。

对外约定（如用户需求）的变更是不可避免的，一旦更改又会影响整个开发过程，所以 CMM 提出归口由高级管理者控制对外约定。
约定必须是有关各方一致同意、认可的。如果将未经认可的约定写入计划，计划将不具备任何权威性。
工作分解
工作分解是项目策划的基本技术。在做软件项目策划时，常混用产品分解和活动分解。

在具体运用时要注意以下几点：
作业开始后应能独立于其他作业而完成；
作业的完成能被验证；
一个作业应连续做完，不要分两次做；
对当前阶段要仔细划分，对未来阶段不要仔细划分，等有更多信息时再做。
职责
项目计划是项目实施的指南，对每种人员的职责规定要详尽，既要讲技术职责，还要讲管理方面的职责。
CMM 2级 SPP KPA
软件项目策划（SPP）关键过程域的目标是为完成软件工程和管理软件项目制定合理的计划。
软件项目策划的任务是估算待完成的工作、建立必要的约定和确定进行这些工作的计划。
CMM 2级SPP关键过程域有 3 个目标和 25 关键实践。SPP 的目标是:
目标1 供策划和跟踪软件项目用的软件估算
已建立文档。

目标2 软件项目的活动和约定是有计划的并已
建立文档。
目标3 受影响的组和个人同意他们对软件项目
的约定。
只有实现了以上目标才可判断该关键过程域得到实现。
为了实现以上目标，需要执行 15 项活动：
AC1 软件工程组参加项目建议群组。
AC2 在整个项目策划的早期阶段启动软件项目策划，此两项策划平行进行。

AC3 在项目的整个生存周期内，软件工程组和其他受影响的组一起参加整个项目的策划。
AC4 高级管理者参加按归档化规程对组织外部的个人和组所作的软件项目约定的评审。
AC5 识别或确定具有可管理规模的预先规定阶段的软件生存周期。
AC6 按归档化规程制定项目的软件开发计划。
AC7 对软件项目的计划建立文档。
AC8 识别为建立和保持对软件项目的控制所必需的工作产品。

AC9 按归档化规程导出对软件工作产品规模（或对软件工作产品规模的更改）的估算。
AC10 按归档化规程导出对软件项目的工作量及成本的估算。
AC11 按归档化规程导出项目的关键计算机资源的估算。
AC12 按归档化规程导出项目的软件进度表。
AC13 对与项目的成本、资源、进度和技术方面相联系的软件风险进行鉴别、评估和建立文档。

AC14 制定项目的软件工程设施和支持工具的计划。
AC15 记录软件策划数据。
SPP过程活动与目标的关系：

其他关键实践
执行约定
指定软件经理负责协商约定和制定项目的软件开发计划。
项目遵循本组织的、书面的、用于策划软件项目的方针。
执行能力
对软件项目存在文档化的经过批准的工作陈述。
安排制定软件开发计划的职责。

为策划软件项目提供足够的资源和资金。
与软件策划有关的软件经理、软件工程师和其他个人，在适用于其职责范围的软件估算和策划方面得到培训。
测量与分析
进行测量并将测量结果用于确定软件策划活动的状态。
验证实施
高级管理者定期参与评审软件项目的策划活动。

项目经理定期地、事件驱动地参与评审软件项目的策划活动。
SQA 组评审和（或）审核软件策划的活动及工作产品，并报告结果。

第九章计算机辅助软件工程 CASE
对于一个项目而言，最好的生产环境应具有三个基本特征：
一组有用的工具：在生产产品时提供帮助；
一个很好的部署：能够快速找到和高效使用合用的工具；
一些熟练的技术人员：他们知道如何以有效的方式来使用这些工具。
这种生产环境叫做集成的项目支撑环境IPSE。
其中的工具叫做计算机辅助软件工程CASE。
CASE的层次结构

上一层构成下一层的基础。
环境体系结构由硬件平台和系统支持（包括网络软件、数据库管理、对象管理服务）构成
一组可移植服务来自于CASE工具和集成框架，允许CASE工具和集成框架跨越不同的硬件平台和操作系统。
集成框架是一组专用程序，提供工具之间相互通信的能力，能够创建项目数据库，并向终端用户展示相同风格的界面。
CASE工具与环境的作用
用来辅助软件开发、运行、维护、管理、支持等过程中的活动的软件称为CASE工具。
CASE工具与环境的作用
辅助软件工程方法和过程的实施
提高软件开发、维护和管理效率
提供检测机制，提高软件质量
CASE 是各种软件开发和系统集成的产品和工具的集合，目的是支持各种软件开发方法。
1993年Fuggertta对CASE工具作了分类。
CASE工具的分类

工具：是指支持软件开发单个活动或任务的软件工具。
工作台：是指支持某一软件过程或一个过程中一组活动的工具集。集成有若干工具。
环境：是指支持某些软件过程以及相关的大部分活动的工具集。集成了若干工作台。
集成化环境提供对数据集成、控制集成、表示集成机制的基本支持。
以过程为中心的环境通过过程模型和过程引擎提供对软件开发活动的导引。
基于支持活动的CASE工具分类
业务过程工程工具：针对组织的战略性信息需求建模，用以表示业务数据对象、数据对象之间的关系，这些数据对象如何在组织内部各个不同业务领域之间流动。
过程建模和管理工具：用于描述业务（或软件）过程，以及过程中的关键元素。它还提供到其他支持过程活动定义的工具的链接。
项目计划工具：支持软件项目成本和工作量的估算，以及项目季度的安排。

风险分析工具：通过提供针对风险标识和分析的详细指南，帮助项目经理建立风险表。
项目管理工具：通过在项目的执行过程中收集度量数据，为最终产品的质量提供指示。
需求跟踪工具：依据客户提交的需求请求和在数据库中存储的原始客户需求和需求规格说明，分析系统需求的变化。
度量和管理工具：面向管理的度量工具捕获与项目相关的数据(如每人月的源代码行数，每个功能点的缺陷数)，确定生产率和质量。面向技术的度量工具确定技术特性。

文档工具：支持文档生成和桌面出版。
质量保证工具：通过审计源代码以确定与语言标准的符合程度。依据技术度量来规划被开发软件的质量。
数据库管理工具：用于建立项目数据库。
软件配置管理工具：它位于每个CASE环境的核心。用于标识配置对象、进行版本控制、变更控制、审计和状态报告。
分析和设计工具：用于帮助建立系统的数据、功能和行为模型，建立数据设计、体系结构设计、界面设计和过程设计方案。

PRO/SIM工具：支持实时系统原型的建造和仿真，提供实时系统建造完成前预测系统行为的能力。
界面设计与开发工具：这是一个工具箱，包括菜单、按钮、窗口结构、图符、滚动机制、设备驱动器等构件，帮助在屏幕上建造符合当前软件采用的界面标准的现代用户界面。
原型实现工具：为交互式应用快速地定义屏幕的布局。一些高级CASE原型实现工具能供执行数据设计并结合到屏幕布局。许多分析与设计工具提供了建造原型的扩展功能。

编程工具：包括编辑程序、编译程序和调试器等。第四代语言、图形程序设计环境、应用生成器、数据库查询语言都属于这一类。
Web开发工具：即与Web应用开发相关的一系列WebApp工具。
集成和测试工具：包括测试数据生成工具，静态测量（分析源代码但不执行测试用例）工具，动态测量（执行源代码进行分析）工具，仿真（模拟硬件和其他外部环境功能）工具，测试管理（辅助测试计划、开发和控制）工具等。

静态分析工具：
基于代码的测试工具：分析源代码，导出测试用例；
专门的测试语言：描述详细的测试规格说明、每个测试用例及它们的执行逻辑；
基于需求的测试工具：分离特定的需求并建议针对这种需求的测试用例。
动态分析工具：执行被测程序，检查路径覆盖率，特定路径上变量的值以及程序的执行流程。一般在程序中插装用于检查的探针。

测试管理工具：用于控制和协调每一测试步骤的测试，比较实测结果和预期结果。还可以当作测试驱动器，读取测试用例并激活被测试的软件。
客户机/服务器测试工具：用于测试图形用户界面，以及客户机与服务器间的网络通信。
再工程工具：
规格说明的逆向工程工具
代码重构和分析工具
联机系统再工程工具
工作台
一个工作台是一组工具集，支持如同设计、实现、测试等特定的软件开发阶段。
将CASE工具集成为一个工作台后，工具可以协同工作，从而提供比单个工具更好的支持。
工作台工具可以通过共享文件、共享数据结构、共享数据仓库来集成。
CASE工作台有程序设计工作台、分析和设计工作台、测试工作台、交叉开发工作台、配置管理工作台、文档工作台、项目管理工作台等。
开放式工作台和封闭式工作台
CASE工作台可以支持一组相关的软件过程活动，这些活动可以应用于不同的应用领域和不同的组织。因此CASE工作台应为开放式系统。
开放式工作台既可提供控制集成机制，又可剪裁。而且其数据集成或协议是公有的，不是独立的。由于还没有被广泛接受的数据集成的标准，故大多数工作台都采用基于文件集成的策略。
开发式工作台的优点是：

可以方便地将某个工具加入到开放式工作台中，还可以用新的工具替换已有的工具。
可以用一个配置管理系统来管理各工具输出的文件。
能够不断增强工作台的功能，扩展工作台。
工作台可以不依赖某个供应商。可以从不同销售商那里购买工具再集成到工作台中。如果某个工具开发商不再提供支持，最多只影响一部分工具，其他工具仍然有效。
封闭式工作台的特点是：系统集成的约定是该工作台开发商独有的。
程序设计工作台
许多工作台都是封闭式工作台，这样允许更紧密的数据集成、表示集成和控制集成。这样出现在用户面前的工作台是一个一致的整体，不是由风格迥异的工具组成的工具箱。

语言编译器：将源代码转换为目标代码，创建抽象语法树(AST)和符号表。
结构化编辑器：结合嵌入的编程语言知识，对AST中程序的语法表示进行编辑。
连接器：将已通过编译的程序目标代码模块连接起来。
加载器：将可执行程序在执行前装入内存。
交叉引用：产生一个交叉引用表，记载所有程序名在哪里声明和使用的。
按格式打印：扫描AST，打印源文件程序。

静态分析器：分析源代码，记录未初始化变量、不能执行到的代码、未调用到的过程等。
动态分析器：产生带附注的源代码清单，注明每个语句的执行次数，生成有关分支和循环的信息，统计处理其使用情况。
交互式调试器：允许用户控制程序执行次序，显示程序执行期间的程序状态。
程序设计工作台是利用语法树和符号表作为共享数据来进行工具集成的。所有程序设计工作台都采用这一方法。
程序设计工作台
分析与设计工作台
分析与设计工作台支持软件的分析与设计阶段。通常称其为上游CASE工具。而程序设计工作台称为下游CAASE工具。
这类工作台可以支持特定的分析或设计方法，如结构化方法、JSD方法或Booch方法。
它们还可以作为通用的图表编辑系统使用，可处理大多数通用方法的图表类型。面向方法的工具还提供方法规则和指南等。
分析和设计工作台可能包括的工具有：

图表编辑器：用于创建数据流图、系统结构图、实体关系图等。它们可确认图表中出现的实体的类型等信息，并将其存储于中央信息仓库中。
设计、分析与验证工具：进行设计分析，报告错误和异常情况。
仓库查询语言：允许设计者查询中央信息仓库，寻找与设计相关的信息。
数据字典：维护系统分析与设计时所用的实体信息。

报告定义与生成工具：从中央信息仓库中取得信息，并自动生成系统文档。
移入/移出设施：允许中央信息仓库与其他软件开发工具进行信息交互。
代码生成器：从中央信息仓库获取设计信息，自动生成代码或代码框架。
在分析与设计工作台中所有工具通过一个共享的信息仓库集成。该仓库的结构是工作台开发商专有的，因此分析与设计工作台通常是封闭式环境。
分析与设计工作台

分析与设计工作台的问题：
移入/移出设施受限。所有工作台都能够支持ASCII文本形式的设计结果，大多数工作台也支持图表的Postscript的输出，但不支持其他移入/移出格式，因此在与其他工作台互换数据时会出现问题。
不能剪裁和修改一个设计方法。可能不能用于特定应用或某类应用。
工作台自带的配置管理系统可能与组织中使用的系统不兼容。这样，工作台的设计结果无法交给组织中使用的配置管理系统管理。
测试工作台
测试工作台应用于软件开发和维护阶段的测试工作，必须是开放式的系统，可以通过不断演进，以适应软件组织的需要。
测试工作台可能包括的工具有：
测试管理器：管理测试的运行并产生测试结果报告。它支持对测试数据的跟踪、对期待结果的跟踪、对被测程序的跟踪等。
测试数据生成器：根据需求自动生成被测程序的测试数据。

预测器：产生对所期待结果的预测，可以依据以前的程序版本或原型系统。背靠背的测试可以并行运行预测器和被测程序，作为对照，发现可能存在的问题。
报告生成器：支持报告的定义，提供测试结果报告的生成。
文件比较器：比较程序测试的结果和以前测试的结果，报告它们之间的差别。
动态分析器：实际运行被测程序，统计程序中每条语言的执行次数。

模拟器：有不同的模拟器。目标模拟器是脚本驱动的工具，模拟多个同时执行的用户交互。I/O模拟器检查事务次序时标是否可重复再现。主要用于检查定时错误。
因为系统的测试需求依赖于要开发的应用程序，所以测试工作台必须具有灵活性，以适应每个系统的测试计划。
测试工作台
CASE环境
信息（模型、程序、文档、数据）从一个工具到另一个工具的平滑传递，以及从一个软件工程步骤到另一个软件工程步骤的平滑过渡。
减少完成软件配置管理、质量保证和文档生成等活动所需的工作量。
通过周密的计划、监控、通信增强对项目的控制。
改善在大型项目中开发人员之间的协调。
CASE环境的任务
提供一种机制，使得包含在该环境中的所有工具之间可以共享软件工程信息；
提供跟踪机制，使得从一个信息项的变更可以跟踪到其它相关的信息项；
对所有的软件工程信息提供版本控制和整体的配置管理；
允许对包含在该环境的任一工具做直接的、非顺序性的使用；

为建立软件的需求模型，需建立软件任务的分解（网络）结构。环境将为把工具和数据集成到规范的任务分解网络中提供自动支持；
提供一致化的人机界面给不同工具的用户；
支持软件工程师之间的通信；
辅助收集可用于改善软件过程和产品的管理和技术度量信息。
集成化软件工程环境体系结构
CASE环境分类
通常，把环境看成是软件人员建立和维护软件系统所使用的硬件工具和软件工具的集合。
编程环境 – 支持开发期中的编写程序阶段的活动（即流行软件）
开发环境 – 支持软件开发期各阶段的开发和管理活动
维护环境 – 支持软件运行 / 维护期的各种更新活动，包括逆向工程和再工程活动
CASE环境另一种分类
以语言为中心的环境
这种环境围绕着某种编程语言建立，提供了一套适合于这种语言的工具；
这种环境的交互水平较高；
支持建立大型程序。
面向结构的环境
这种环境直接面对程序的结构；
以语法制导编辑程序为核心，用户交互式地操作所有结构；
支持建立小型或大型程序。

工具箱环境
这种环境集中了多个软件工具；
这些工具以用户需求为驱动，适用面广泛，且与语言无关；
支持建立大型程序。
基于方法的环境
支持开发方法 – 提供支持软件分析、设计、实现、测试、验证等的工具；
支持开发过程管理 – 提供支持项目计划、项目监控、配置管理、质量保证、软件过程改进等活动的工具。
CASE环境模型
APSE模型全称为Ada Progamming Support Environment，是1980年Buxton提出的。
他建议采用增量式开发方法来开发基于三个功能级别的环境：
一个核心APSE（KAPSE），提供环境的基础机构，对操作系统进行扩充。
一个最小的APSE（MAPSE），基本上是一个程序设计工作台。

以增量方式建立一个完整的APSE，加入可提供的支持其他过程活动的工具。
Wasserman模型
1990年Wasserman提出五级模型:
平台集成：是指工具或工作台在相同的平台上运行。“平台”可以是一个单一的计算机，也可以是一个操作系统或网络系统。
数据集成：提供统一的数据模式和数据接口规范，需要相互协同的工具通过这种统一的规范交换数据。共享级别为：
共享文件：所有工具识别单一文件格式；

共享数据结构：包含设计和编程信息的数据结构的细节为所有工具共享；
共享数据仓库：所有工具围绕一个对象管理系统来集成，该对象管理系统包含能被所有工具使用的共享的数据实体和关系，它独立于工具。
表示集成：即界面集成。采取统一的界面风格，保证各工具界面的一致性。
窗口系统集成：所有工具采用相同的基本窗口系统，窗口有相同的外观。

命令集成：对于文本界面，所有工具都使用相同的命令和参数的语法格式；对于图形界面，所有工具对菜单、按钮有相同的表示（图符）。此外所有工具以相同方式支持应用和环境的控制功能；
交互集成：所有工具提供相同的直接操纵的操作规则。
控制集成：支持各工具或各开发活动间的通信、切换、调度和协同工作，并支持软件开发过程的描述、执行和转接。通常使用消息传送方式实现控制的集成。

过程集成：在CASE系统中嵌入了关于过程活动、阶段、约束和支持这些活动的工具的知识。由CASE系统维持软件过程模型，并根据要求实例化和使用该软件过程模型。
基于服务的环境层次模型
在这个模型中，一个软件开发环境是由使用环境服务的一组集成的CASE工作台组成。
这些服务既可以由环境运行于其上的平台提供，也可以由环境框架提供。
框架服务可类比于APSE中的环境核心。

平台服务：软件开发环境所在的运行平台称为环境的宿主机系统，被开发软件则分发到目标机上。宿主机系统和目标机可能是同一个平台，也可能不是。

宿主机的平台服务通常包括有:
文件服务：文件存储于多个文件服务器上，可供网络上所有机器访问。
进程管理服务：可创建、开启、停止、挂起、调度网络计算机上运行的进程。
网络服务：可以把一台计算机上的进程和其相关数据传到另一台网络上的计算机。
通信服务：支持网络上计算机之间的通信和向目标机下载程序。
窗口管理服务：在用户显示器上操纵窗口。

打印服务：网络上进行打印。
环境平台是由异构的分布式计算机组成，可能包括不同类型的计算机、来自同一制造商的不同操作系统的工作站、不同制造商的工作站等。
框架服务：环境中的框架服务扩充了宿主机提供的服务集，他们是基于平台服务实现的。这些服务专用于支持CASE工具或工作台的集成。
软件工程环境体系结构参考模型SEE如图。
SEE参考模型

一个软件开发环境提供的服务可能为:
数据仓库服务：支持环境实体的数据存储、关系、命名、定位、数据维护、并发处理、进程操作、文档、备份等。
数据集成服务：用于支持软件开发。主要服务有版本管理、配置命名、配置查询与更新、模式定义、状态监控、数据互换等。
任务管理服务：支持环境过程的集成。主要的服务有：任务定义、任务执行、任务事务、任务历史、事件监控、查帐与记账、角色管理等。

消息服务：支持工具与框架服务通信。有两种消息服务：消息发派（支持工具到工具、服务到服务、框架到框架之间的消息传递）和工具注册（支持某种工具或服务作为某种消息的接收者登记到消息服务器上）。
用户界面服务：用于支持表示集成。
工具：工具有自己的相应的服务，也应集成到环境中。
有三种工具集成的级别：

集成工具：这些工具用框架服务来管理它们的所有数据，其数据结构统一存储于对象管理系统中。
半分离工具：这些工具自己管理自己的数据结构，但用框架服务来管理文件。对象管理系统可以管理文件之间的连接，但不能管理文件内部数据结构之间的连接。
外来工具：这些工具仅用于平台服务。它们管理自己的数据，但可以使用数据互换服务存取数据。
可移植通用工具环境PCTE
1984年欧洲计算机制造商协会(ECMA)公布了软件开发环境通用工具接口PCTE第一版，其中采用了SEE模型，成为一个标准。
美国国防部基于APSE，设立了CAIS (Common APSE Interface Set) 项目，通过研制一个Ada核心APSE，开发环境通用工具接口集CAIS。
以后欧美对PCTE和CAIS进行综合，开发出一个称之为 PCIS (Portable Common Interface Standard) 的标准，1994年发表，1995年原型化。

ECMA PCTE 主要特点：
基于ERA (实体-关系-属性) 模型，实现对象的管理。支持对象之间的连接、对象类与子对象的定义。
提供数据恢复、复原的能力。即通过控制事务中动作的执行，一旦发现出错，立即恢复数据库到一个一致的状态。
提供事务执行的管理，支持进程之间的通信、进程的启动、停止和存储。
支持进程和数据在网络上的分派。

采用一种比较复杂的安全模型，提供不同的安全级别，控制对对象管理系统中对象的存取。
ECMA PCTE 提供了一个相当完整的低层框架服务，与SEE参考模型相比的结果：
数据仓库服务：除备份服务外，PCTE提供了所有数据仓库服务。
数据集成服务：除通用查询服务外，PCTE提供了所有数据集成服务。
任务管理服务：仅提供了记账和查账服务。

消息服务：仅提供了消息分派服务，没有提供工具注册服务。
用户界面服务：建议在PCTE环境下都使用X-Wingdow实现其用户界面，没有强制采用哪些特定的库。
CASE环境的发展趋势
从软件工具开发者的角度
发展重点应在软件工具的集成上
从专家系统开发者的角度
发展应力求使软件开发过程自动化
从环境的实用者的角度
发展应满足用户多方面的需求，不同技术层次的用户，对软件工程环境的发展有不同的要求。