《软件工程与开发技术》课件第1章

第1章软件工程引论1.1软件产品的概念与特征1.2软件危机1.3软件工程的产生及其发展1.4软件工程的技术基础1.5软件工程过程的概念1.6几种软件过程模型1.7过程技术1.8软件重用技术1.9计算机辅助软件工程工具1.10小结1.1软件产品的概念与特征1.1.1软件产品的概念与分类就本质而言，软件就是一个信息转换器，它的功能不外是产生、管理、获取、修改、显示或转换信息。它担任着双重角色，首先，它是一种产品，表达了由计算机硬件体现的计算潜能；其次，它又是开发和运行产品的载体，是计算机控制(操作系统)、信息通信(网络)的基础，也是创建和控制其他软件(软件工具和开发环境)的基础。

对于软件的一种公认的解释是：软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合。其中，程序是为实现设计的功能和性能要求而编写的指令序列；数据是使指令能够正常操纵信息的数据结构；文档是与程序开发、维护和使用有关的图文资料。根据用途划分，软件可以大致划分成如下类别：(1)系统软件：就一般情况来说，系统软件是为其他软件服务的软件。系统软件与计算机硬件交互频繁，处理大量的确定或不确定的复杂数据，往往需要具有多用户支持、资源精细调度、并发操作管理、多种外部设备接口支持等项功能。

(2)实时软件：管理、分析、控制现实世界中所发生的事件的软件称为实时软件。它一般有数据采集、数据分析、输出控制等三方面的功能。实时软件需要保持一个现实任务可以接受的响应时间，即必须保证能够在严格限定的时间范围内对输入做出响应。(3)商业管理软件：商业信息处理是最大的软件应用领域，包括常规的数据处理软件和一些交互式的计算处理(如POS软件)软件。它的基本功能是将已有的数据重新构造，变换成一种可以辅助商业操作和管理决策的形式。在这个过程中，几乎都要涉及到对于大型数据库的访问。各类管理信息系统(MIS)、企业资源计划(ERP)、客户关系管理(CRM)等都是典型的商业管理软件。(4)工程与科学计算软件：此类软件的特征是要实现特定的“数值分析”算法。例如离散傅立叶变换、有限元分析、演化计算等等。CAD/CAM软件一般也可以归属到这一类型中来。

(5)嵌入式软件：驻留在专用智能产品的内存中，用于控制这些产品进行正常工作，完成很有限、很专业的功能的软件。例如各类智能检测仪表、数码相机、移动电话、微波炉等智能产品都必须在嵌入式软件的支持下才能正常工作。(6)人工智能软件：利用非数值算法去解决复杂问题的软件。各类专家系统、模式识别软件、人工神经网络软件都属于人工智能软件。

(7)个人计算机软件：文字处理系统、电子表格、游戏娱乐软件等等。此外，还可以根据软件的规模(代码行及开发工作量，如表1.1)、软件的工作方式、使用频度、失效后造成的影响等对软件产品进行分类。表1.1根据规模进行软件分类软件规模类别参加人员数开发期限产品规模(源代码行数)微型11～4周0.5 k小型11～6月1～2 k中型2～51～2年5～50 k大型5～202～3年50～100 k甚大型100～10004～5年1 M极大型2000～50005～10年1～10 M1.1.2软件产品的特征在制造硬件时，人的创造性的劳动过程(分析、设计、建造、测试)能够完全转换成物理的形式，但软件是逻辑的而不是物理的产品，因此软件具有和硬件完全不同的特征：

(1)软件是一种逻辑实体，具有抽象性。我们可以把软件保存在媒体介质上，但却无法直接看到软件的形态，因而必须通过运行、观察、分析、思考、判断才能够了解软件的功能、性能及其他特性。换句话说，软件产品具有明显的非可视特征。(2)软件的生产与硬件不同。软件是由开发或工程化而形成的，不是由传统意义上的制造过程生产的。虽然软件开发和硬件制造之间有一些相似之处，可是两者在本质上是不同的。这两者都能够通过良好的设计获得高质量的产品，但即使有了良好的设计和优秀的样品，硬件在批量制造过程中仍然可能引入质量问题，这种情况对于软件而言几乎不存在。软件在开发完毕，形成为产品之后，其批量制造过程只是简单的拷贝/复制；软件的开发和硬件的制造都依赖于人，但参与者和他们完成的工作之间的关系不同；两者的终极目的都是建造产品，但方法不同；软件的成本集中在开发过程上，而硬件生产的成本更多地表现在原材料消耗上。因此，软件项目开发过程不能完全像硬件制造过程那样来管理。(3)软件产品不会“磨损”。和硬件产品类似，软件产品也会出现故障。所不同的是，硬件产品的故障多来自外在条件导致的“磨损”或“老化”，而软件产品如果发生故障，无一例外的是在设计开发过程中留有隐患。因此，硬件的故障可以通过简单的更换部件解决，而软件的故障必须通过全面的软件维护活动才有望克服。同时，不完善的维护活动又可能在软件中注入新的故障，导致软件质量的“退化”。也就是说，软件故障的修复要比硬件故障的修复复杂得多。因此，衡量软件产品质量的一个重要指标就是它的“可维护性”。图1.1是软、硬件产品的失效率曲线。图1.1软件/硬件产品失效率曲线1.1.3软件发展的阶段划分自从20世纪40年代第一台计算机问世以来，就有了“程序”的概念，可以认为它是软件的前身。经过了几十年的发展，人们对软件有了更为深刻的认识，在这几十年中，软件开发经历了三个发展阶段：20世纪50～60年代属于程序设计阶段；20世纪60～70年代为程序系统阶段；20世纪70年代之后进入软件工程阶段。各阶段的特点与区别见表1.2。表1.2计算机软件发展的三个阶段及其特点

阶段特点程序设计程序系统软件工程软件所指程序程序及说明书程序、文档、数据主要程序设计语言汇编及机器语言高级语言软件语言*软件工作范围程序编写设计和测试整个软件生命周期需求者程序设计者本人少数用户市场用户开发软件的组织个人开发小组开发小组及大、中型开发机构软件规模小型中、小型大、中、小型

阶段特点程序设计程序系统软件工程决定质量的因素个人技术小组技术水平技术与管理水平开发技术和手段子程序、程序库结构化程序设计数据库、开发工具、集成开发环境、工程化开发方法、标准和规范、网络及分布式开发、面向对象技术、计算机辅助软件工程维护责任者程序设计者开发小组专职维护人员硬件的特征高价、存储量小、可靠性差降价，速度、容量和可靠性明显提高向超高速、大容量、网络化、微型化方向发展软件的特征完全不受重视软件的技术发展不能满足需求，出现软件危机开发技术有进步，但仍未完全摆脱软件危机表1.2计算机软件发展的三个阶段及其特点1.2软件危机1.2.1软件危机及其表现现代计算机应用系统中，软件的地位日益重要和突出。如何满足日益增长的软件需求，如何维护应用中的大量已有软件，已经成为了计算机应用系统进一步发展的瓶颈。1968年，北大西洋公约组织的计算机科学家们在联邦德国召开的国际会议上讨论了软件危机问题，同时也是在这个会议上提出了“软件工程”这个名词，导致了一门新的工程学科的正式诞生。简单地说，所谓软件危机，就是指在软件开发和软件维护过程中所存在的一系列严重问题。具体地说，软件危机具有如下一些表现：(1)软件开发没有真正的计划性，对软件开发进度和软件开发成本的估计常常很不准确，计划的制定带有很大的盲目因素，因此工期超出、成本失控的现象经常困扰着软件开发者。

(2)对于软件需求信息的获取常常不充分，软件产品往往不能真正地满足用户的实际需求。

(3)缺乏良好的软件质量评测手段，从而导致软件产品的质量常常得不到保证。(4)对于软件的可理解性、可维护性认识不够；软件的可复用性、可维护性不如人意。有些软件因为过于“个性化”，甚至是难以理解的，更谈不上进行维护。缺乏可复用性引起的大量重复性劳动极大地降低了软件的开发效率。

(5)软件开发过程没有实现“规范化”，缺乏必要的文档资料或者文档资料不合格、不准确，难以进行专业维护。(6)软件开发的人力成本持续上升，如美国在1995年的软件开发成本已经占到了计算机系统成本的90%(如图1.2所示)。

(7)缺乏自动化的软件开发技术，软件开发的生产率依然低下，远远满足不了急剧增长的软件需求(如图1.3所示)。图1.2计算机系统硬件、软件成本比例变化图1.3软件技术的发展落后于需求

软件危机曾经是历史上的阴影，目前软件工程界也仍然在一定程度上受到它的影响。软件工程概念的提出，正是为了克服软件危机。自1968年以来，随着软件工程学的不断发展，软件危机得到了一定程度的遏制，但还远远没有被彻底解决。《TheStandishGroup.Chaos.1995.》一文报告了20世纪90年代中期美国商用软件产业的情况：1995年美国公司取消了810亿美元的软件项目；在所考察的软件项目中，在完成前就取消了其中的31%；53%的软件项目进度拖延，通常拖延的时间超过预定工期50%以上；只有9%的大型软件项目能够及时交付且费用不超支(对中型和小型软件公司来说这一数据为16%)。1.2.2产生软件危机的原因软件危机的存在是不争的事实。产生软件危机的原因可以归纳为主、客观两个方面。从客观上来看，软件不同于硬件，它的生产过程和产品都具有明显的“不可视”特征，这就导致在完成编码并且上机运行之前，对于软件开发过程的进展情况较难衡量，软件产品的质量也较难进行先期评价，因此，对于开发软件的过程进行管理和控制比较困难。在软件工程的早期，制定详细的开发计划并且进行全程跟踪调控，对于所有的阶段产品和阶段工作进展进行技术审查和管理复审，可望在一定程度上克服“开发过程不可视”造成的消极影响。

此外，软件运行过程中如果发现了错误，那么必然是遇到了在开发时期(分析、设计、编码过程)引入的，在检测过程中没有能够检查出来的故障。对于此类故障的维护，通常意味着要修改早期的分析结果、设计结果并调整编码。由于软件产品的不可视特征，维护过程不像硬件产品维护时只要简单的更换损坏部件那样容易，这在客观上造成了软件难以维护的结果。利用足够的文档资料使不可视的产品可视化，有助于提升软件产品的可理解性和可维护性。

从主观上分析，导致软件危机发生的另一大原因，可以归于在计算机系统发展的早期，软件开发的“个体化”特点，主要表现为忽视软件需求分析的重要性、忽视软件的可理解性、文档不完备、轻视软件的可维护性、过分强调编码技巧等等方面。只有软件的用户才真正了解他们自己的需求。而且应当承认，用户一开始并不见得能够清晰、准确、无二意地表达自己的需求。软件开发人员需要做大量的、深入细致的调研工作，引导用户逐步准确、具体地描述软件的需求，才能够得到对问题、目标的正确认识，从而获得解决问题的恰当出发点，有望开发出真正能够满足用户需求的软件产品。在对用户的需求没有清楚的认识时就仓促进行程序编写，最终必然会导致开发工作的失败。

一般来说，软件产品从策划、定义、开发、使用与维护直到最后废弃，要经过一个漫长的时期，通常把这个时期称为软件的“生命周期”。可以将生命周期分作“软件定义”、“软件开发”和“运行与维护”三个阶段。在软件定义阶段中，主要进行软件目标的策划、可行性研究和软件的需求分析工作，通过和用户多次交流，在所要开发的软件必须“作什么”方面和用户达成一致(当然在开发过程中也允许在严格的控制下进行需求变更)。

软件被定义之后，进入开发阶段，主要对软件的体系架构、数据结构和主要算法进行设计和编码实现。对于编码结果，还要按照规范进行测试后，才能最终交付使用。如前所述，在开发阶段也可能对于此前不够准确的软件定义结果进行调整。统计数据表明，在典型的软件工程过程中，编码工作量大约只占软件开发全部工作量的15%～20%。

软件的运行与维护阶段在软件生命周期中占据的比例最大。在软件运行过程中，分析和设计阶段的一些遗留缺陷可能会逐步暴露；运行环境的演变也会对运行中的软件提出变更要求；用户新需求的提出则常常要求扩充现有软件的功能或者改进其性能，所有这些要求与问题都必须通过“软件维护”工作去解决。在维护过程中，必须注意保持所有软件工作产品之间的一致性。针对不同的需求，维护工作一般可以分为纠错性维护、适应性维护、扩充性维护和预防性维护等不同类型。

作为软件，应当有一个完整的配置。Boehm(美国著名的软件工程专家，加州州立大学教授)指出，“软件是程序以及开发、使用、维护程序所需要的所有文档”。所以，软件产品除包括程序之外，应当包括完整、准确、翔实的文档资料。主要的文档应当包括“需求规格说明书”、“体系结构设计说明书”、“详细设计说明书”、“安装手册”、“操作手册”、“系统管理员手册”等。缺乏必要的配置文档，将严重影响软件的可理解性，从而给软件的维护造成严重障碍。做好包括项目策划、可行性研究、需求分析三项内容的软件定义工作，是提高软件质量、降低软件成本、保证开发进度的关键环节。

值得注意的严重问题是，在软件开发的不同阶段进行修改所付出的代价是极其不同的。在早期引入变动，涉及的面比较小，因而代价也比较低；在开发的中期，因为许多配置项(被标识的工作产品)已经完成，所以引入一个变动，就要对它所涉及的所有已经完成的配置项进行变更，不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；如果在软件“已经完成”时再引入变更，更是要付出高得多的代价。根据美国一些软件公司的统计资料，软件开发后期引入一个变动比在早期引入相同变动所需付出的代价高2～3个数量级。图1.4定性地描绘了在不同时期引入一个变动需要付出的代价的变动趋势。图1.5是美国贝尔实验室统计得出的定量结果。图1.4变更代价随时间变化的趋势示意图1.5改正一个问题需要付出的代价1.2.3解决软件危机的途径可以借鉴其他工程领域的成功经验，基于软件危机产生的主、客观原因，从软件工程技术和软件工程管理两方面来采取措施，防范软件危机的发生。软件开发不是某种个体劳动的神秘技巧，而应当是一种组织良好、管理严密，分析、设计、编码、测试、品保等各类人员协同配合、共同完成的工程项目。在软件开发过程中，必须充分吸收和借鉴人类长期以来从事各种工程项目所积累的行之有效的原理、概念、技术和方法，特别要注意吸收几十年来在计算机硬件研究和开发中积累的经验、教训。

从管理层面上考虑，应当注意推广和使用在实践中总结出来的开发软件的成功的技术和方法，并且探索更好的、更有效的技术和方法，注意积累软件开发过程中的经验数据财富，逐步消除在计算机系统早期发展阶段形成的一些错误概念和做法。建立适合于本组织的软件工程规范；制定软件开发中各个工作环节的流程文件、工作指南和阶段工作产品模板；实施针对软件开发全过程的计划跟踪和品质管理活动；为每一项工程开发活动建立配置管理库；实施严格的产品基线管理并建立组织的软件过程数据库和软件财富库；为各类员工及时提供必要的培训等等都是加强软件开发活动管理工作的有效手段。

从技术角度考虑，应当开发和使用更好的软件开发工具，提高软件开发效率和开发工作过程的规范化程度。在计算机软件开发的各个阶段，都有大量的繁琐重复的工作要做，在适当的软件工具的辅助下，开发人员可以把这类工作做的既快又好。目前广为使用的统一建模语言(UML)、各种配置管理工具、缺陷管理工具和自动测试工具都在软件工程活动中发挥了很好的作用。计算机辅助软件工程(CASE)更是目前备受重视的一个旨在实现软件开发自动化的新的领域。1.3软件工程的产生及其发展1968年，北大西洋公约组织的计算机科学家们在原联邦德国召开的国际会议上，针对软件危机的严峻形势，提出了把在其他工程领域中行之有效的一些工程学知识运用到软件开发过程中来，从管理和技术两个方面研究如何更好地开发和维护计算机软件的设想。这也就是软件工程的基本思路。在这次会议上首次提出并使用了“软件工程”这一术语。简单地说，软件工程是指导软件开发和维护的工程学科。它的核心思想是采用工程的概念、原理、技术和方法来开发和维护软件，把经过实践考验而证明是正确的管理技术和当前能够得到的最好的技术方法结合起来，从而大大提高软件开发的成功率和生产率。许多计算机专家都曾经描述过“软件工程”的定义。Boehm曾为软件工程下过定义：“运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料”。

1983年，IEEE(电气和电子工程师协会)给出的软件工程定义为：“软件工程是开发、运行、维护和修复软件的系统方法”。

FritzBauer(美国著名的软件工程专家)则给出了另一个关于软件工程学的定义：“建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法”。

后来又有一些从事软件工程方法学研究的人陆续提出了许多更为完善的软件工程的定义，但主要思想都是强调软件开发过程中需要应用工程化原则的重要性。

IEEE给出了关于软件工程的一个更加综合的定义：

(1)将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护过程。即将工程化方法应用于软件开发与维护过程中。

(2)对上述方法的研究。

就内容来看，软件工程应当包括三个要素：方法、工具和过程。软件工程方法为软件开发提供了“如何做某项工作”的技术指南。它包括了多方面的任务。例如项目策划和估算方法、软件需求分析方法、体系结构的设计方法、详细设计方法、软件测试方法等等。使得整个开发过程的每一种阶段任务都能够“有章可循”。软件工程工具为软件工程方法提供了自动的或半自动的软件支撑环境。目前这样的工具已经有许多种，而且已经有人把诸多软件工程工具集成起来，使得一种工具产生的信息可以为其他工具所使用，形成了一种称之为计算机辅助软件工程(CASE)的软件开发支撑环境。CASE把各种软件工具、开发机器和一个存放开发过程信息的工程数据库组合起来，形成了一个完整的软件工程环境。

软件工程中的“过程”是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。可以将软件工程过程理解为软件工程的工艺路线。过程定义了各种方法使用的顺序、各阶段要求交付的文档资料、为保证质量和控制软件变更所需要的管理环节和在软件开发各个阶段完成的里程碑。针对软件工程的基本要件，有许多计算机科学家进行了诠释，先后提出了100多条有关软件工程的相关原则。著名软件工程专家B.W.Boehm集众家所长，并总结了TRW公司多年开发软件的经验，在1983年提出了软件工程的七项基本原则，作为保证软件产品质量和开发效率的最小集合。具体包括：(1)用分阶段的生命周期计划严格管理软件工程过程。(2)坚持在软件工程过程中进行阶段评审。(3)实行严格的产品控制。(4)采用现代的开发技术进行软件的设计与开发。(5)工作结果应当是能够清楚地审查的。(6)开发小组的人员应该“少而精”。(7)承认不断改进软件工程实践的必要性。

这七条原则是互相独立的、缺一不可的最小集合，同时又是相当完备的。可以证明，其他已经提出的100多条软件工程原理都可以由这七条原则的任意组合蕴含或派生。从首次提出“软件工程”的概念开始，迄今已经经过了近半个世纪，在此期间，计算机硬件、软件技术领域都有了长足的发展，各种新产品、新技术、新方法、新工具不断问世。伴随着计算机科学与技术的进步，软件工程作为一门新兴学科也同样有了很大的发展。从传统的软件工程到面向对象的软件工程，从一般的软件工程到净室软件工程，从软件工程到软件再工程，从人工软件工程到计算机辅助软件工程，整个软件工程学正在日趋走向成熟，并在计算机应用领域中发挥着越来越大的作用。1.4软件工程的技术基础图1.6软件工程过程层次图

正如其他工程方法一样，软件工程必须以有组织的软件质量保证为基础。因此说，对质量的关注构成了软件工程的根基。软件工程过程是将技术层(包括工程技术与管理技术)结合在一起的凝聚力。过程层是软件工程的基层。软件工程过程定义了一组关键过程域(KPAs)，这对于软件工程技术的有效应用是必需的。这些关键过程区域是对软件工程项目进行管理与控制的基础，并且确定了上、下各区域之间的关系。其中，对于技术方法的采用、阶段产品的产生、工程里程碑的建立、质量监控与保证、变更控制等方面都进行了规定。除各个开发组织可以定义自己的软件工程过程之外，目前流行比较广泛的软件工程过程包括有RUP过程、极限(XP)过程、敏捷软件过程(AgileS.P)等等。

软件工程方法涵盖了需求分析、设计、编程、测试、维护等各个环节，它给出了完成这些任务在技术上应当“如何做”的方法。它依赖于一组基本原则，这些原则控制了每一个技术区域，涉及到建模活动和其他描述技术。工具层对过程和方法提供支持，使得工程活动、管理活动得以自动、半自动的进行。例如，目前广为使用的数据库建模工具Erwin、面向对象的建模工具RationnalRose、配置管理工具等等。如果把一系列的工具集成起来使用，使得一个工具产生的信息可以被另一个工具使用时，就形成了一个支持软件开发的系统。这种集成了软件、硬件和一个软件工程数据库的软件工程环境，称为计算机辅助软件工程(CASE)。1.5软件工程过程的概念软件工程过程是过去十年中人们关注的焦点。软件工程和软件工程过程之间是强相关的。软件工程过程通常包括四种基本的过程活动：

(1)软件规格说明：规定软件的功能、性能及其运行限制。

(2)软件开发：产生满足规格说明的软件，包括设计与编码等工作。

(3)软件确认：确认软件能够满足客户提出的要求，对应于软件测试。

(4)软件演进：为满足客户的变更要求，软件必须在使用的过程中演进，以求尽量延长软件的生命周期。

在一个良好的软件过程中，还应当包括一些“保护性”的活动，包括软件项目的跟踪监控、正式的技术审核、软件配置管理活动、软件质量保证活动、文档的准备和产生、软件测试、风险管理等等。这些保护性活动贯穿于整个工程过程之中。在具体的工程过程中，可以根据实际需要，采用不同的过程模型来实现上述的基本活动和保护活动。事实上，软件工程过程是一个软件开发组织针对某一类软件产品为自己规定的工作步骤，它应当是科学的、合理的，否则必将影响到软件产品的质量。一个良好的软件工程过程应当具备如下特点：(1)易理解性。

(2)可见性：每个过程活动都以得到明确的结果而告终，保证过程的进展对外可见。

(3)可支持性：容易得到CASE工具的支持。

(4)可接受性：比较容易被软件工程师接受和使用。

(5)可靠性：不会出现过程错误，或者出现的过程错误能够在产品出错之前被发现。

(6)健壮性：不受意外发生问题的干扰。

(7)可维护性：过程可以根据开发组织的需求的改变而改进。

(8)高效率：从给出软件规格说明起，就能够较快地完成开发而交付使用。

一个软件过程可以表示成如图1.7所示的形式。其中，公共过程框架是通过定义若干适合于所有软件项目的框架活动而建立的；若干任务集合中，每一个集合都由软件工程工作任务、软件项目里程碑、软件工作产品和交付物以及质量保证点组成；保护性活动独立于任何一个框架，贯穿于整个过程。图1.7软件工程过程1.6几种软件过程模型

在一个具体的实际工程活动中，软件工程师必须设计、提炼出一个工程开发策略，用以覆盖软件过程中的基本阶段，确定所涉及的过程、方法、工具。这种策略常被称为“软件工程过程模型”。这一模型的选择应当是根据组织定义的标准软件过程，参考具体工程项目的特点和资源状况进行裁剪来进行的。

从宏观上来看，所有的软件开发过程都可以看成是一个循环解决问题的过程。其中包括四个截然不同的阶段：状态描述、问题定义、技术开发和方案综述，如图1.8所示。状态描述表示了事物的当前状态；问题定义标识了要解决的特定问题；技术开发通过应用某些技术来解决问题；方案综述提交解决结果(如文档、程序、数据、新的商业功能、新产品)给那些从一开始就需要方案的人。前面定义的软件工程的一般阶段和步骤很容易映射到这些阶段上。

图1.8问题循环解决的各个阶段

上述的问题循环解决过程可以应用于软件工程的多个不同开发级别(阶段)上，包括考虑整个系统开发的宏观阶段，开发程序构件的中间阶段，甚至是代码编制阶段，因此可以采用分级集合表示。可以定义一个模式，然后在连续的、更小的规模上递归地应用它，这样来提供一个关于过程的理想化的视图。问题循环解决过程的每一个阶段又包含一个相同的问题循环解决过程，如图1.9所示。可以认为，软件开发是从用户到开发者再到技术的一个连续的过程。随着向一个完整系统的逐步进展，上述的阶段递归地应用于用户的需求和开发者的软件技术说明中。

图1.9问题循环解决阶段中的阶段

要想像图1.9那样清楚地划分阶段活动是很困难的，因为阶段内部和阶段之间的活动往往是交叉的。但是对于任何一个软件项目而言，不管选择了什么样的具体的软件工程过程模型，所有四个活动阶段在某个细节的级别上都是同时存在的。图2.4描述了实际过程的递归性质。在后面的讨论中，我们将会看到，每一种具体的软件工程过程模型实际上都代表了一种将本质上无序的活动有序化的企图。每一种模型都具有能够帮助实际软件项目的控制及协调的特征，但在它们的核心中，这些模型又表现了无序模型的特点。

在软件工程实践中，有许多专家治力于过程模型的研究。像瀑布模型、原型模型、快速应用开发模型、增量模型、螺旋模型、形式化方法模型、RUP模型、敏捷过程模型、构件组装模型、并发开发模型等等都先后得到了有效的应用。图1.10表示了软件工程的线性顺序模型，有时也称为“瀑布模型”。 它表示了软件开发系统的、顺序的方法。虽然瀑布模型支持带反馈的循环，但大多数使用者均把它视为是严格线性的。从系统级开始，随后是分析、设计、编码、测试和维护。图1.10线性顺序模型线性顺序模型是最早，也曾经是应用最广泛的软件工程过程模型，但是这种模型不适应需求经常发生变更的环境。实际的项目很少能够严格地按照该模型给出的顺序进行。需求的变更、设计的变更、编码的变更几乎是不可避免的。虽然线性顺序模型能够允许迭代，但却是间接的迭代。在项目的开发过程中，变更可能会引起混乱。所以，有人形象地把采用线性模型进行商业软件工程称之为“在沙滩上盖楼房”。考虑到用户对于需求的理解有一个渐进渐深的过程，一开始用户往往难以明确地提出所有的需求，这样，线性顺序模型的第一步输入就得不到满足。

同时，线性顺序模型也经常不能接受项目开始阶段自然存在的不确定性。在采用线性顺序模型的时候，用户只有到项目的开发晚期才能够得到程序的可运行版本。大的错误如果到这时才被发现，那么造成的后果往往是灾难性的。同时，因为线性顺序模型每一步的工作都必须以前一阶段的输出为输入，这种特征会导致工作中发生“阻塞”状态。某些项目组成员不得不等待组内其他成员先完成前驱任务才可能展开自己的工作。有时这种等待时间可能会超过实际花在工作上的时间。这种阻塞状态在线性顺序过程的开始和结束时经常会发生。1.6.2原型模型大型建筑在施工之前，常常按照图纸制造一个缩小的模型来验证工程完成后可能的效果；新的工业设计在充分证明其正确性之前，也往往利用在缩小规模的前提下制造少量成品进行检验的方法来验证设计正确与否。同样地，如果在开发一项软件工程的时候，用户不能准确、全面地描述其需求，或者开发者还不能确定所选用算法的有效性或人机交互界面的形式时，同样也可以建立一个简化了的样品程序并使之运行，引导用户通过对样品运行情况的观察，进一步明确需求或验证算法的正确性。这种开发模式就称之为“原型模型”，如图1.11所示。图1.11原型模型图1.12RAD模型原型模型从需求收集开始，开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。然后进行快速设计并进行编码实现，进行原型的建造。这种快速设计和建造通常集中在那些对用户可见的部分(如输入方式、输出界面)。原型建造好之后，运行原型程序，由用户和开发者进行评估、验证。接着进一步精化待开发软件的需求，逐步调整原型以使其逐渐满足用户的真正需求，同时也使开发者对将要完成的开发任务有更深入的理解。这一过程是多次迭代进行的。使用原型模型必须有两个前提。其一是用户必须积极参与原型的建造，同时开发者和用户必须有共识：建造原型仅仅是为了定义需求，之后就必须被全部抛弃(至少是部分抛弃)，实际的软件必须在充分考虑到软件质量和可维护性之后才被开发。从这个意义上说，原型模型又往往被称为“抛弃原型模型”。其二是必须有快速开发工具可供使用。1.6.3快速应用开发模型快速应用开发(RAD)模型是线性顺序模型的一个“高速”变种，强调极端的开发周期。RAD模型通过使用基于构件的建造方法达到快速开发的效果。在需求得到很好理解、项目的范围约束明晰的前提下(通常不容易保证这样的条件)，采用RAD过程能够使项目组在很短的时间内(如60～90天)创建出功能完善的系统。 RAD过程主要用于信息应用软件的开发，如图1.12所示，它包含如下几个开发阶段：

(1)业务建模：业务活动中的信息流被模型化。此阶段说明什么信息驱动业务流程、生成什么信息、谁负责生成该信息、该信息流向何处、谁处理它等。

(2)数据建模：业务建模阶段定义的一部分信息流被精化，形成一组支持该业务所需的数据对象。此阶段标识出每个数据对象的特征属性，定义这些对象之间的关系。

(3)处理建模：数据建模阶段定义的数据对象变换成为要完成一项业务功能所需的信息流。此阶段创建处理描述以便增加、修改、删除或获取某个数据对象。

(4)应用生成：RAD过程不是采用传统的第三代程序设计语言来创建软件，而主要是复用已有的程序构件或是创建可复用的构件。在所有情况下，均使用自动化工具辅助软件建造。

(5)测试及反复：RAD过程强调复用，许多构件是已经测试过的，减少了测试工作量。但是所有的新创建构件、所有的接口都必须测试。图1.12RAD模型1.6.4演化软件过程模型

1.增量模型增量模型融合了线性顺序模型的基本成分(重复的应用这些成分)和原型模型的迭代特征，如图1.13所示。增量模型实际上是一个随着日程/时间的进展而交错的线性序列集合。每一个线性序列产生一个软件的可发布的“增量”，所有的增量都能够结合到原型模型中去。图1.13增量模型当使用增量模型时，第一个增量模型往往是核心部分的产品，它实现了软件的基本需求，但很多已经明晰或者尚不明晰的补充特性还没有发布。核心产品交由用户使用或进行详细复审。使用或复审评估的结果是制定下一个增量开发计划。该计划包括对核心产品的修改及增加一些新的功能与特性。这个过程在每一个增量发布后迭代地进行，直到产生最终的完善产品。和原型模型不一样的是，增量模型虽然也具有“迭代”特征，但是每一个增量都发布一个可操作的产品，不妨称之为“产品扩充迭代”。它的早期产品是最终产品的可拆卸版本，每一个版本都能够提供给用户实际使用。

2.螺旋模型螺旋模型也属于演化软件过程模型。它将原型的迭代特征与线性顺序模型中控制的和系统化的方面结合起来，使得能够快速开发软件的增量版本。在螺旋模型中，软件开发是一系列的增量发布。和增量模型不同，它并不要求每一个增量都是可以运行的程序。在早期的迭代中，发布的增量可以是一个纸上的模型或原型；在以后的迭代中产生更加完善的版本。螺旋模型被划分为若干个框架活动，如图1.14所示。活动也称为任务区域，一般包括：

(1)用户通信：建立开发者和用户之间有效通信所需要的任务。

(2)计划：定义资源、进度和其他项目相关信息所需要的任务。

(3)风险分析：评估技术的及管理的风险所需要的任务。

(4)工程：建立应用的一个或多个表示所需要的任务。

(5)建造及发布：建造、测试、安装和提供用户支持所需要的任务。

(6)用户评估：基于在工程阶段产生的或在安装阶段实现的软件表示的评估，是获得用户反馈所必需的任务。图1.14一个典型的螺旋模型每一个框架活动(任务区域)均含有一系列的适应待开发项目特点的工作任务(活动)。在所有的情况下，都需要应用诸如软件配置管理、软件品质保证等保护性活动。随着演化过程的开始，软件工程项目组按照顺时针方向沿螺旋移动。从核心开始，第一圈可能产生软件规格说明书，第二圈可能开发出一个原型，随后可能是软件更完善的版本。经过计划区域的每一圈都会对计划进行调整，基于从用户处得到的反馈，调整进度和费用以及版本的内容。项目管理者可以根据项目的具体情况调整所需要的迭代次数。和传统的过程模型不同，螺旋模型能够适应于计算机软件产品的整个生命周期，而不是当软件交付后就结束过程。对于大型系统及软件的开发工作来说，螺旋模型是一种很好的模型方法。采用这种模型，随着过程的发展演化，开发者和用户能够更好地理解和对待每一个演化级别上的风险。它使开发者在产品演化的任何阶段上都能够使用原型方法，保持了传统生命周期模型中的阶段化的工作方式，但同时又引入了迭代的框架，更加真实地反映了现实世界。同时也有利于防范技术风险。螺旋模型的应用同样有赖于用户的充分理解和积极参与。同时，它需要使用专门的风险评估技术以便识别风险、防范风险。 1.7过程技术前面讨论的过程模型必须适合于软件项目组的使用。为满足这一要求，先后开发出了许多过程管理工具以帮助软件组织分析他们当前的过程，协调组织工作任务，控制和监管进度以及管理技术质量。例如，利用配置管理工具来进行配置管理和缺陷管理；利用自动测试工具进行测试；利用统一建模语言UML来进行对象建模、分析与设计；利用Project制订和监测项目计划及其进展；利用第四代技术，通过开发者在较高的层次上说明软件的某些特征，之后工具就能够自动地根据说明生成源代码等。采用合适的过程技术工具，使得软件开发组织能够建造一个自动模型，该模型包括通用的过程框架、任务集合及保护性活动。该模型一般表示成一个网络，对其加以分析，就能够确定典型的工作流程，考察可能导致降低开发时间和成本的可供选择的过程结构。一旦创建了一个可接受的过程，就可以使用其他过程工具来分配、监管，甚至控制过程模型中所定义的所有软件工程任务。软件项目组的每一个成员均能够使用这些工具产生一个清单，包括要完成的任务、要开发的工作产品以及要实现的质量控制活动等等。

1.8软件重用技术“重用”是提升软件财富价值的有效途径。一般来说，这里所指的重用可以包括知识重用、方法重用、软件成分重用三个层次。例如，软件工程知识的重用使我们能够高效率地开发、维护一个又一个的软件项目；行之有效的软件工程方法的重用帮助我们有章可循地解决各类工程问题；软件成分的重用则使我们在需求分析、系统设计和编码实现的过程中能够事半功倍。对于软件工程师来说，软件成分的重用是我们最为关注的问题。介绍RAD模型时，我们已经了解了构件重用的重要作用。没有构件重用，RAD模型就只能是纸上谈兵。再具体一点地说，软件成分重用又可以分为分析结果重用、设计结果重用和代码重用三个层次。需求分析在软件工程中的地位举足轻重。一个完善的需求分析将指导我们走上成功之路，反之，错误的分析必将导致项目的彻底失败。在大部或局部雷同的项目中重复地使用已经被前驱项目证明是正确的部分分析结果，是提高分析工作效率、保证分析成功的一种有效方法。设计重用在开发类同项目的软件，尤其是在软件移植过程中能够极大地减少工作量，提高工作效率。设计结果重用包括体系结构设计重用和详细设计重用两重内涵。代码重用是最直接的重用。包括基于“宏”的重用、基于函数库的重用和基于继承的重用三种不同的方法。目前，基于函数库的重用(例如C语言)和基于继承(VB、JAVA等)的重用代表着代码重用的主流。尤其是基于继承的代码重用，随着面向对象方法的成熟，越来越受到重视。基于软件重用思想的框架(Framework)开发模式近年来备受关注。业界认为，软件构件化是21世纪软件工业发展的大趋势。工业化的软件复用已经从通用类库进化到了面向领域的应用框架。框架的重用已成为软件生产中最有效的重用方式之一。框架是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法。另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上下文(Context)关系。因此，构件库的大规模重用也需要框架。框架的最大好处就是重用。面向对象系统获得的最大的复用方式就是框架，一个大的应用系统往往可能由多层互相协作的框架组成。由于框架能重用代码，因此从一已有构件库中建立应用变得非常容易，因为构件都采用框架统一定义的接口，所以使构件间的通信趋于简单。框架能够重用设计。它提供可重用的抽象算法及高层设计，并能将大系统分解成更小的构件，而且能描述构件间的内部接口。这些标准接口使在已有的构件基础上通过组装建立各种各样的系统成为可能。只要符合接口定义，新的构件就能插入框架中，构件设计者就能重用构件的设计。框架还能重用分析。所有的人员若都按照框架的思想来分析事务，那么就能将它划分为同样的构件。采用相似的解决方法，从而使采用同一框架的分析人员之间能进行沟通。采用框架技术进行软件开发的主要特点包括：

(1)领域内的软件结构一致性好。

(2)建立了更加开放的系统。

(3)重用代码大大增加，软件生产效率和质量也得到了提高。

(4)软件设计人员要专注于对领域的了解，使需求分析更充分。

(5)存储了经验，可以让那些经验丰富的人员去设计框架和领域构件，而不必限于低层编程。

(6)允许采用快速原型技术。

(7)有利于在一个项目内多人协同工作。

(8)大粒度的重用使得平均开发费用降低，开发速度加快，开发人员减少，维护费用降低，而参数化框架使得适应性、灵活性增强。

1.9计算机辅助软件工程工具

1．按使用功能的CASE工具分类

(1)信息工程工具。这类CASE工具不是关注于特定应用的需求，而是对业务信息在公司内各个组织实体间的流动进行建模，其主要目标是表示业务数据对象、它们的关系以及这些数据对象如何在公司内部的不同业务区域间流动。通过对某一组织的战略性信息需求的建模，信息工程工具提供了一个可从中导出特定信息系统的“元模型”。

(2)项目计划/管理工具。主要包括：项目计划工具：这类工具主要关注软件项目工作量、项目工期、成本估算和项目进度安排，使得项目管理者能够定义所有项目任务，创建任务网以表示任务间的依赖性和可能的并行度。项目度量工具：这类工具通过捕获项目特定的度量(如每人月的LOC、每个功能点的缺陷数等)，改善项目管理者控制和协调软件过程的能力，从而提高软件开发的质量。风险分析工具：这类工具通过提供对风险标识和分析的详细指南，使得项目管理者能够建立风险表，并制定一个计划减轻、监控和管理风险。质