软件工程(第4版)(txt+pdf+epub+mobi电子书下载)

作者：张海藩 吕云翔 编著

出版社：人民邮电出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

软件工程(第4版)试读：

目录

扉页

出版者的话

第4版前言

第1篇 软件工程与软件过程

第1章 软件工程概述

1.1 软件危机与软件工程的起源

1.1.1 计算机系统的发展历程

1.1.2 软件危机介绍

1.1.3 产生软件危机的原因

1.1.4 消除软件危机的途径

1.2 软件工程

1.2.1 什么是软件工程

1.2.2 软件工程的基本原理

1.3 软件工程包含的领域

小结

习题

第2章 软件过程

2.1 软件生命周期的基本任务

2.2 瀑布模型

2.3 快速原型模型

2.4 增量模型

2.5 螺旋模型

2.6 喷泉模型

2.7 Rational统一过程

2.7.1 最佳实践

2.7.2 RUP的十大要素

2.7.3 RUP生命周期

2.8 敏捷过程与极限编程

2.8.1 敏捷过程概述

2.8.2 极限编程

2.9 能力成熟度模型

2.9.1 能力成熟度模型的结构

2.9.2 能力成熟度等级

2.9.3 关键过程域

2.9.4 应用CMM

小结

第2篇 传统方法学

第3章 结构化分析

3.1 概述

3.2 与用户沟通的方法

3.2.1 访谈

3.2.2 简易的应用规格说明技术

3.2.3 软件原型

3.3 分析建模与规格说明

3.3.1 分析建模

3.3.2 软件需求规格说明

计算机科学与技术日新月异的发展，对我国高校计算机人才的培养提出了更高的要求。许多高校主动研究和调整学科内部结构、人才培养目标，提高学科水平和教学质量，精炼教学内容，拓宽专业基础，优化课程结构，改进教学方法，逐步形成了“基础课程精深，专业课程宽新”的良性格局。作为大学计算机教材建设的生力军，人民邮电出版社始终坚持服务高校教学、致力教育资源建设的出版理念，在总结前期教材建设的成功经验的同时，深入调研和分析课程体系，并充分结合我国高校计算机教育现状和改革成果，推出“推介名师好书，共享教育资源”的教材建设项目，出版了“21世纪高等学校计算机规划教材”。

本套教材的突出特点如下。（1）作者权威 本套教材的作者均为国内计算机学科中的学术泰斗或高校教学一线的教学名师，他们有着深厚的科研功底和丰富的教学经验。可以说，这套教材汇聚了众师之精华，充分显示了这套教材的格调和品位。无论是刚入杏坛的年轻教师，还是象牙塔内的莘莘学子，细细品读其中的章节文字，定会收益匪浅。（2）定位准确 本套教材是为普通高等院校的学生量身定做的精品教材。具体体现在：一是本套教材的作者长期从事一线科研和教学工作，对高校教学有着深刻而独到的见解；二是本套教材在选题策划阶段便多次召开调研会，对普通高校的教学需求和教材建设情况进行充分摸底，从而保证教材在内容组织和结构安排更加贴近实际教学；三是组织有关作者到较为典型的普通高等院校讲授课程教学方法，深入了解教师的教学需求，充分把握学生的理解能力，以教材内容引导授课教师严格按照科学方法实施教学。（3）教材内容与时俱进 本套教材在充分吸收国内外最新计算机教学理念和教育体系的同时，更加注重基础理论、基本知识和基本技能的培养，集思想性、科学性、启发性、先进性和适应性于一身。（4）一纲多本，合理配套 根据不同的教学方法，同一门课程可以有多本不同的教材，教材内容各具特色，实现教材系列资源配套。

总之，本套教材中的每一本精品教材都切实体现了各位教学名师的教学水平，充分折射出名师的教学思想，淋漓尽致地表达着名师的教学风格。我们相信，这套教材的出版发行一定能够启发年轻教师们真正领悟教学精髓，教会学生科学地掌握计算机专业的基本理论和知识，并通过实践深化对理论的理解，学以致用。

我们相信，这套教材的策划和出版，无论在形式上还是在内容上都能够显著地提高我国高校计算机专业教材的整体水平，为培养符合时代发展要求的具有较强国际竞争力的高素质创新型计算机人才，为我国的普通高等教育的计算机教材建设工作做出新的贡献。欢迎各位老师和读者给我们的工作提出宝贵意见。第4版前言

20世纪60年代，为了解决当时出现的“软件危机”，人们提出了软件工程的概念，并将其定义为“为了经济地获得可靠的和能在实际机器上高效运行的软件，而建立和使用的健全的工程规则”。随着40多年的发展，人们对软件工程逐渐有了更全面、更科学的认识，软件工程已经成为一门包括理论、方法、过程等内容的独立学科，并出现了相应的软件工程支撑工具。

然而即使在21世纪的今天，软件危机的种种表现依然没有彻底地得到解决，实现中很多项目依然挣扎在无法完成或无法按照规定的时间、成本，完成预期的质量的泥潭中，面临着失败的危险。究其原因，依然是软件工程的思想和方法并未深入到计算机科学技术、特别是软件开发领域中，并指导人们的开发行为。

为了振兴中国的计算机和软件产业，培养具备软件工程思想和技术，并具有相应开发经验的人才，国家近年来一直十分重视软件工程相关课程的建设和人才培养。除了开设专门的软件工程专业，也倡导在计算机科学技术相关专业开设软件工程课程，使得软件工程思想和技术在中国的IT人才中得到普及。

本书讲述了软件工程与软件过程，涉及传统方法学、面向对象方法学，以及软件项目管理，并且讲述了软件工程高级课题，如形式化方法（包括Petri网等）和软件复用。

本书第4版在保持原书结构和篇幅基本不变的前提下，将第14章“国际标准”改为“软件维护与软件文档”；每一章后的习题，也按照当前教学的需要，进行了全面的更新。

在与本书配套的教材《软件工程（第4版）辅导与习题解析》中，有对本书每章末的习题解析，有对软件工程各种类型的应用题的详解，以及软件工程课程设计指导，以帮助读者更好地理解和巩固所学的知识。

本书的教学安排建议如下。续表

建议先修课程：计算机导论、面向对象程序设计、数据结构、数据库原理等。

建议理论教学时数：48～64学时。

建议实践教学时数：32～48学时。

教师可以根据教学需要适当地删除一些章节，也可根据教学目标，灵活地调整章节的顺序，增减各章的学时数。

本书作者一直在北京信息科技大学和北京航空航天大学软件学院担任软件工程课程的教学工作，进行了大量的教学探索和研究。在成书过程中，大量借鉴了笔者和同事在教学中的相关经验。在此感谢他们为此做出的贡献，也感谢其在成书过程中提供的各种宝贵资料和建议。

由于软件工程作为工程学科正处在发展与变化之中，我们力求使本书做到完美；但由于编者学习能力和水平有限，书中难免有疏漏之处，恳请各位同仁和广大读者给予批评指正，也希望各位能将使用此教材过程中的经验和心得与我们交流（yunxianglu@hotmail.com）。编者2013年6月第1篇 软件工程与软件过程第1章 软件工程概述

人类社会已经跨入了21世纪，计算机系统已经渗入人类生活的各个领域，同时计算机软件已经发展成为当今世界最重要的技术领域。研究软件本身则产生了一门重要的学科就是软件工程。软件工程的研究领域包括软件的开发方法、软件的生命周期以及软件的工程实践等。1.1 软件危机与软件工程的起源1.1.1 计算机系统的发展历程

20世纪60年代中期以前，是计算机系统发展的早期。在这个时期通用硬件已经相当普遍，软件却是为每个具体应用而专门编写的，大多数人认为软件开发是无须预先计划的事情。这时的软件实际上就是规模较小的程序，程序的编写者和使用者往往是同一个（或同一组）人。由于规模小，程序编写起来相当容易，也没有什么系统化的方法，对软件开发工作更没有进行任何管理。这种个体化的软件环境，使得软件设计往往只是在人们头脑中隐含进行的一个模糊过程，除了程序清单之外，根本没有其他文档资料保存下来。

从20世纪60年代中期到70年代中期，是计算机系统发展的第二代。在这10年中计算机技术有了很大进步。多道程序、多用户系统引入了人—机交互的新概念，开创了计算机应用的新境界，使硬件和软件的配合上了一个新的层次。实时系统能够从多个信息源收集、分析和转换数据，从而使得进程控制能以毫秒而不是分钟来进行。在线存储技术的进步导致了第一代数据库管理系统的出现。

计算机系统发展的第二代的一个重要特征是出现了“软件作坊”，广泛使用产品软件。但是，“软件作坊”基本上仍然沿用早期形成的个体化软件开发方法。随着计算机应用的日益普及，软件数量急剧膨胀。在程序运行时发现的错误必须设法改正；用户有了新的需求时必须相应地修改程序；硬件或操作系统更新时，通常需要修改程序以适应新的环境。上述种种软件维护工作，以令人吃惊的比例耗费资源。更严重的是，许多程序的个体化特性使得它们最终成为不可维护的。“软件危机”就这样开始出现了。1968年北大西洋公约组织的计算机科学家在联邦德国召开国际会议，讨论软件危机问题。在这次会议上正式提出并使用了“软件工程”这个名词，一门新兴的工程学科就此诞生了。1.1.2 软件危机介绍

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能正常运行的软件才具有的。实际上，几乎所有软件都不同程度地存在这些问题。概括地说，软件危机包含下述两方面的问题：如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。鉴于软件危机的长期性和症状不明显的特征，近年来有人建议把软件危机更名为“软件萧条（depression）”或“软件困扰（affliction）”。不过“软件危机”这个词强调了问题的严重性，而且也已为绝大多数软件工作者所熟悉，所以本书仍将沿用它。

具体来说，软件危机主要有以下一些典型表现。

① 对软件开发成本和进度的估计常常很不准确。实际成本比估计成本有可能高出一个数量级，实际进度比预期进度拖延几个月甚至几年的现象并不罕见。这种现象降低了软件开发组织的信誉。而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量，从而不可避免地会引起用户的不满。

② 用户对“已完成的”软件系统不满意的现象经常发生。软件开发人员常常在对用户要求只有模糊的了解，甚至对所要解决的问题还没有确切认识的情况下，就仓促上阵匆忙着手编写程序。软件开发人员和用户之间的信息交流往往很不充分，“闭门造车”必然导致最终的产品不符合用户的实际需要。

③ 软件产品的质量往往靠不住。软件可靠性和质量保证的确切定量概念刚刚出现不久，软件质量保证技术还没有坚持不懈地应用到软件开发的全过程中，这些都导致软件产品发生质量问题。

④ 软件常常是不可维护的。很多程序中的错误是非常难改正的，实际上不可能使这些程序适应新的硬件环境，也不能根据用户的需要在原有程序中增加一些新的功能。“可重用的软件”还是一个没有完全做到的、正在努力追求的目标，人们仍然在重复开发类似的或基本类似的软件。

⑤ 软件通常没有适当的文档资料。计算机软件不仅仅是程序，还应该有一整套文档资料。这些文档资料应该是在软件开发过程中产生出来的，而且应该是“最新式的”（即和程序代码完全一致的）。软件开发组织的管理人员可以使用这些文档资料作为里程碑（milestone），来管理和评价软件开发工程的进展状况；软件开发人员可以利用它们作为通信工具，在软件开发过程中准确地交流信息；对于软件维护人员而言，这些文档资料更是至关重要、必不可少的。缺乏必要的文档资料或者文档资料不合格，必然给软件开发和维护带来许多严重的困难和问题。

⑥ 软件成本在计算机系统总成本中所占的比例逐年上升。由于微电子学技术的进步和生产自动化程度不断提高，硬件成本逐年下降，然而软件开发需要大量人力，软件成本随着通货膨胀以及软件规模和数量的不断扩大而持续上升。美国在1985年软件成本大约已占计算机系统总成本的90%。

⑦ 软件开发生产率提高的速度，既跟不上硬件的发展速度，也远远跟不上计算机应用迅速普及深入的趋势。软件产品“供不应求”的现象，使人类不能充分利用现代计算机硬件提供的巨大潜力。

以上列举的仅仅是软件危机的一些明显的表现，与软件开发和维护有关的问题远远不止这些。1.1.3 产生软件危机的原因

在软件开发和维护的过程中存在这么多严重问题，一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。

软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。由于软件缺乏“可见性”，在写出程序代码并在计算机上试运行之前，软件开发过程的进展情况较难衡量，软件的质量也较难评价，因此，管理和控制软件开发过程相当困难。此外，软件在运行过程中不会因为使用时间过长而被“用坏”，如果运行中发现错误，很可能是遇到了一个在开发时期引入的在测试阶段没能检测出来的错误，因此，软件维护通常意味着改正或修改原来的设计，这就在客观上使得软件较难维护。

软件不同于一般程序，它的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。为了在预定时间内开发出规模庞大的软件，必须由许多人分工合作。然而，如何保证每个人完成的工作合在一起确实能构成一个高质量的大型软件系统，更是一个极端复杂困难的问题，不仅涉及许多技术问题，诸如分析方法、设计方法、形式说明方法、版本控制等，更重要的是必须有严格而科学的管理。

软件本身独有的特点确实给开发和维护带来一些客观困难，但是人们在开发和使用计算机系统的长期实践中，也确实积累和总结出了许多成功的经验。如果坚持不懈地使用经过实践考验证明是正确的方法，许多困难是完全可以克服的，过去也确实有一些成功的范例。但是，目前相当多的软件专业人员对软件开发和维护还有不少糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这可能是使软件问题发展成软件危机的主要原因。

与软件开发和维护有关的许多错误认识和做法的形成，可以归于在计算机系统发展的早期阶段软件开发的个体化特点。错误的认识和做法主要表现为忽视软件需求分析的重要性，认为软件开发就是编写程序并设法使之运行，轻视软件维护等。

事实上，对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。只有用户才真正了解他们自己的需要，但是许多用户在开始时并不能准确具体地叙述他们的需要，软件开发人员需要做大量深入细致的调查研究工作，反复多次地和用户交流信息，才能真正全面、准确、具体地了解用户的要求。对问题和目标的正确认识是解决任何问题的前提和出发点，软件开发同样也不例外。急于求成，仓促上阵，对用户要求没有正确认识就匆忙着手编写程序，这就如同不打好地基就盖高楼一样，最终必然垮台。事实上，越早开始编写程序，完成它所需要用的时间往往越长。

一个软件从定义、开发、使用和维护，直到最终被废弃，要经历一个漫长的时期，这就如同一个人要经过胎儿、儿童、青年、中年和老年，直到最终死亡的漫长时期一样。通常把软件经历的这个漫长的时期称为生命周期。软件开发最初的工作应是问题定义，也就是确定要求解决的问题是什么；然后要进行可行性研究，决定该问题是否存在一个可行的解决办法；接下来应该进行需求分析，也就是深入具体地了解用户的要求，在所要开发的系统（不妨称之为目标系统）必须做什么这个问题上和用户取得完全一致的看法。经过上述软件定义时期的准备工作才能进入开发时期，而在开发时期首先需要对软件进行设计（通常又分为概要设计和详细设计两个阶段），然后才能进入编写程序的阶段，程序编写完之后还必须经过大量的测试工作（需要的工作量通常占软件开发全部工作量的40%～50%）才能最终交付使用。所以，编写程序只是软件开发过程中的一个阶段，而且在典型的软件开发工程中，编写程序所需的工作量只占软件开发全部工作量的10%～20%。

另一方面还必须认识到程序只是完整的软件产品的一个组成部分，在上述软件生命周期的每个阶段都要得出最终产品的一个或几个组成部分（这些组成部分通常以文档资料的形式存在）。也就是说，一个软件产品必须由一个完整的配置组成，软件配置主要包括程序、文档、数据等成分。必须清除只重视程序而忽视软件配置其余成分的糊涂观念。

做好软件定义时期的工作，是降低软件成本提高软件质量的关键。如果软件开发人员在定义时期没有正确全面地理解用户需求，直到测试阶段或软件交付使用后才发现“已完成的”软件不完全符合用户的需要，这时再修改就为时晚矣。

严重的问题是，在软件开发的不同阶段进行修改需要付出的代价是很不相同的。在早期引入变动，涉及的面较少，因而代价也比较低；在开发的中期，软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改，不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；在软件“已经完成”时再引入变动，当然需要付出更高的代价。根据美国一些软件公司的统计资料，在后期引入一个变动比在早期引入相同变动所需付出的代价高2～3个数量级。图1.1所示为在不同时期引入同一个变动需要付出的代价随时间变化的趋势。图1.1 引入同一个变动付出的代价随时间变化的趋势

通过上面的论述不难认识到，轻视维护是一个最大的错误。许多软件产品的使用寿命长达10年甚至20年，在这样漫长的时期中不仅必须改正使用过程中发现的每一个潜伏的错误，而且当环境变化时（如硬件或系统软件更新换代）还必须相应地修改软件以适应新的环境，特别是必须经常改进或扩充原来的软件以满足用户不断变化的需要。所有这些改动都属于维护工作，而且是在软件已经完成之后进行的，因此，维护是极端艰巨复杂的工作，需要花费很大代价。统计数据表明，实际上用于软件维护的费用占软件总费用的55%～70%。软件工程学的一个重要目标就是提高软件的可维护性，减少软件维护的代价。

了解产生软件危机的原因，澄清错误认识，建立起关于软件开发和维护的正确概念，还仅仅是解决软件危机的开始，全面解决软件危机需要一系列综合措施。1.1.4 消除软件危机的途径

为了消除软件危机，首先应该对计算机软件有一个正确的认识。正如1.1.3小节中讲过的，应该彻底清除在计算机系统早期发展阶段形成的“软件就是程序”的错误观念。一个软件必须由一个完整的配置组成。事实上，软件是程序、数据及相关文档的完整集合。其中，程序是能够完成预定功能和性能的可执行的指令序列；数据是使程序能够适当地处理信息的数据结构；文档是开发、使用和维护程序所需要的图文资料。1983 年 IEEE（电气和电子工程师协会）为软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。虽然表面上看来在这个定义中列出了软件的5个配置成分，但是，方法和规则通常是在文档中说明并在程序中实现的。

更重要的是，必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。必须充分吸取和借鉴人类长期以来从事各种工程项目所积累的行之有效的原理、概念、技术和方法，特别要吸取几十年来人类从事计算机硬件研究和开发的经验教训。

应该推广和使用在实践中总结出来的开发软件成功的技术和方法，并且研究探索更好、更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。

应该开发和使用更好的软件工具。正如机械工具可以“放大”人类的体力一样，软件工具可以“放大”人类的智力。在软件开发的每个阶段都有许多烦琐重复的工作需要做，在适当的软件工具辅助下，开发人员可以把这类工作做得既快又好。如果把各个阶段使用的软件工具有机地集合成一个整体，支持软件开发的全过程，则称为软件工程支撑环境。

总之，为了消除软件危机，既要有技术措施（方法和工具），又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。1.2 软件工程1.2.1 什么是软件工程

概括地说，软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，经济地开发出高质量的软件并有效地维护它，这就是软件工程。

下面给出软件工程的几个定义。

1983年IEEE给软件工程下的定义是：“软件工程是开发、运行、维护和修复软件的系统方法。”这个定义相当概括，它主要强调软件工程是系统方法而不是某种神秘的个人技巧。

Fairly认为：“软件工程学是为了在成本限额以内按时完成开发和修改软件产品所需要的系统生产和维护技术及管理学科。”这个定义明确指出了软件工程的目标是在成本限额内按时完成开发和修改软件的工作，同时也指出了软件工程包含技术和管理两方面的内容。

Fritz Bauer给出了下述定义：“软件工程是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用的完善的工程化原则。”这个定义不仅指出软件工程的目标是经济地开发出高质量的软件，而且强调了软件工程是一门工程学科，它应该建立并使用完善的工程化原则。

1993年IEEE进一步给出了一个更全面的定义。

软件工程是：①把系统化的、规范的、可度量的途径应用于软件开发、运行和维护的过程，也就是把工程化应用于软件中；②研究①中提到的途径。

认真研究上述这些关于软件工程的定义，有助于我们建立起对软件工程这门工程学科的全面的整体性认识。1.2.2 软件工程的基本原理

自从1968年在联邦德国召开的国际会议上正式提出并使用了“软件工程”这个术语以来，研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或“信条”。著名的软件工程专家Barry W. Boehm综合这些学者们的意见并总结了TRW 公司多年开发软件的经验，于1983年在一篇论文中提出了软件工程的7条基本原理。他认为这7条原理是确保软件产品质量和开发效率原理的最小集合。这7条原理是互相独立的，其中任意6条原理的组合都不能代替另一条原理，因此，它们是缺一不可的最小集合。然而这7条原理又是相当完备的，人们虽然不能用数学方法严格证明它们是一个完备的集合，但是可以证明在此之前已经提出的100多条软件工程原理都可以由这7条原理的任意组合蕴含或派生。

下面简要介绍软件工程的7条基本原理。

1．用分阶段的生命周期计划严格管理

有人经统计发现，在不成功的软件项目中有一半左右是由于计划不周造成的，可见把建立完善的计划作为第1条基本原理是吸取了前人的教训而提出来的。

在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条基本原理意味着，应该把软件生命周期划分成若干个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。Boehm认为，在软件的整个生命周期中应该制定并严格执行6类计划，它们是项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划和运行维护计划。

不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受客户或上级人员的影响而擅自背离预定计划。

2．坚持进行阶段评审

当时已经认识到，软件的质量保证工作不能等到编码阶段结束之后再进行。这样说至少有两个理由：第一，大部分错误是在编码之前造成的，如根据Boehm等人的统计，设计错误占软件错误的63%，编码错误仅占37%；第二，错误发现与改正得越晚，所需付出的代价也越高（参见图1.1）。因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误，是一条必须遵循的重要原则。

3．实行严格的产品控制

在软件开发过程中不应随意改变需求，因为改变一项需求往往需要付出较高的代价。但是，在软件开发过程中改变需求又是难免的。由于外部环境的变化，相应地改变用户需求是一种客观需要，显然不能硬性禁止客户提出改变需求的要求，而只能依靠科学的产品控制技术来顺应这种要求。也就是说，当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。所谓基准配置又称为基线配置，它们是经过阶段评审后的软件配置成分（各个阶段产生的文档或程序代码）。基准配置管理也称为变动控制：一切有关修改软件的建议，特别是涉及对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。绝对不能谁想修改软件（包括尚在开发过程中的软件），就随意进行修改。

4．采用现代程序设计技术

从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术。20世纪60年代末提出的结构程序设计技术，已经成为绝大多数人公认的先进的程序设计技术。以后又进一步发展出各种结构分析（structured analysis，SA）与结构设计（structured design，SD）技术。近年来，面向对象技术已经在许多领域中迅速地取代了传统的结构化开发方法。实践表明，采用先进的技术不仅可以提高软件开发和维护的效率，而且可以提高软件产品的质量。

5．结果应能清楚地审查

软件产品不同于一般的物理产品，它是看不见摸不着的逻辑产品。软件开发人员（或开发小组）的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难于评价和管理。为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。

6．开发小组的人员应该少而精

这条基本原理的含义是，软件开发小组的组成人员的素质应该好，而人数则不宜过多。开发小组人员的素质和数量，是影响软件产品质量和开发效率的重要因素。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件中的错误。此外，随着开发小组人员数目的增加，因为交流情况讨论问题而造成的通信开销也急剧增加。当开发小组人员数为N时，可能的通信路径有N(N−1)/2条，可见随着人数N的增大，通信开销将急剧增加。因此，组成少而精的开发小组是软件工程的一条基本原理。

7．承认不断改进软件工程实践的必要性

遵循上述6条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产。但是，仅有上述6条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐，不能跟上技术的不断进步，因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第7条基本原理。按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验，如收集进度和资源耗费数据，收集出错类型和问题报告数据等。这些数据不仅可以用来评价新的软件技术的效果，而且可以用来指明必须着重开发的软件工具和应该优先研究的技术。1.3 软件工程包含的领域

IEEE在2004年发布的《软件工程知识体系指南》中将软件工程知识体系划分为以下10个知识领域。

◇ 软件需求（software requirements）。

◇ 软件设计（software design）。

◇ 软件构建（software construction）。

◇ 软件测试（software testing）。

◇ 软件维护（software maintenance）。

◇ 软件配置管理（software configuration management）。

◇ 软件工程管理（software engineering management）。

◇ 软件工程过程（software engineering process）。

◇ 软件工程工具和方法（software engineering tools and methods）。

◇ 软件质量（software quality）。

以下分别简要介绍一下这10个领域。

1．软件需求

软件需求表达了为解决某些真实世界问题而施加在软件产品上的要求和约束。软件需求的主要类型包括：产品与过程，功能性与非功能性，突出的属性。软件需求知识领域涉及软件需求的抽取、分析、规格说明和确认。软件工业界一致认同的就是如果这些工作完成得不好，软件工程项目就很容易失败。

2．软件设计

软件设计是一个过程和这个过程的结果，此过程对一个系统或组件定义架构（architecture，也叫体系结构）、组件、接口以及其他特征。

软件设计作为过程看待时是一项软件工程生命周期的活动。在这项活动中分析软件需求以产生一个软件内部结构的描述，此描述将成为软件构建的基础。更精确地说，软件设计的结果必须描述软件架构（即软件如何分解成组件并组织起来）以及这些组件之间的接口，它必须详细地描述每个组件以便能构建这些组件。

软件设计在软件开发中起着重要作用：软件工程师为了实现一个解决方案要设计出各种的模型形成蓝图。我们可以分析和评估这些模型，以确定据此能否实现各种不同的需求；也可以检查和评估候选方案，并进行权衡取舍。最后，我们可以使用作为设计结果的模型来规划后续的开发活动，并且作为构造与测试的输入和起始点。

软件设计由两个处于软件需求和软件构建之间的活动组成。

◇ 软件架构设计（有时称做顶层设计）：描述软件的顶层结构和组织，并且标识各种不同的组件。

◇ 软件详细设计：详细地描述各个组件，使之能被构建。

3．软件构建

软件构建指的是如何创建产生软件的详细步骤，这其中包括编码、验证、单元测试、集成测试和调试。

4．软件测试

测试是一个标识产品的缺陷和问题的活动。测试的目的是为了评估和改进产品质量。

软件测试通过使用有限的测试用例来动态地验证程序是否能达到预期的行为。有限的测试用例是从通常情况下有无限可能性的执行领域中适当地选取出来的。

5．软件维护

软件开发工作的结果就是交付一个满足用户需求的软件产品。软件产品一旦投入运行，产品的缺陷就会被逐渐地暴露出来，运行的环境会逐渐发生变化，新的用户需求也会不断地浮出水面。软件维护就是要针对这些问题而对软件产品进行相应地修改或演化，从而修正错误，改善性能或其他特征，以及使软件适应变化的环境。

6．软件配置管理

软件配置管理（Software Configuration Management，SCM）是一项跟踪和控制软件变更的活动。

7．软件工程管理

软件工程管理是软件的开发和维护的管理活动，为了达到系统的、遵循规程的和可量化的目标，它包括计划、协调、度量、监控、控制和报表。

8．软件工程过程

可以在两个层次上分析软件工程过程领域。第1个层次包括软件生命周期过程中技术的和管理的活动，它们是在软件获取、开发、维护和退出运行中完成的。第2个层次是元层次，涉及软件生命周期过程本身的定义、实现、评估、管理、变更和改进。

9．软件工程工具和方法

软件开发工具是用于辅助软件生命周期过程的基于计算机的工具，工具可以将重复并明确定义的动作自动化，减少了软件工程师的认知负担，使软件工程师可以集中在开发过程的创造性方面。另外，还可以通过工具来支持特定的软件工程方法，减少手工应用软件工程方法时相应的管理负担。工具的范围覆盖支持单个任务到囊括整个生命周期。

软件工程方法的目标是使软件工程活动系统化并最终更可能成功。方法通常提供一种符号和词汇表，为完成一组明确的任务提供流程，为检查过程和产品提供指南。方法的覆盖范围从单个生命周期阶段到整个生命周期。

尽管对于特定的工具有详尽的手册，对于新型工具有大量的论文，但是，关于软件工程工具的一般性技术读物却很少。一个困难是软件工具的高变化率，特定的细节有规则地变化着，使得难以提供具体的、最新的实例。

10．软件质量

什么是软件质量？多年以来，许多作者和组织对术语“质量”有着不同的定义。对于 Phil Crosby，质量就是“遵从用户需求”。Watts Humphrey认为质量就是“达到适合使用的卓越层次”。IBM 发明了术语“市场驱动的质量”，它基于达到全面的客户满意，关于组织质量的 Baldrige 准则使用了一个类似的短语“客户驱动的质量”，将客户满意作为主要的考虑。在ISO9001-00中，质量被定义为“一组内在特征满足需求的程度”。小结

本章对计算机软件工程学作了一个简短的概述。首先通过回顾计算机系统发展简史，说明开发软件的一些错误方法和观念是怎样形成的；然后列举了这些错误方法带来的严重弊病（软件危机），澄清了一些糊涂观念。为了计算机系统的进一步发展，需要认真研究开发和维护软件的科学技术。应总结开发计算机软件的历史经验教训，借鉴其他工程领域的管理技术，逐步使软件工程这门新学科发展和完善起来。习题

一、判断题

1．软件就是程序，编写软件就是编写程序。　　　　（　　）

2．软件危机的主要表现是软件需求增加，软件价格上升。　　　（　　）

3．软件工程学科出现的主要原因是软件危机的出现。　　　（　　）

4．与计算机科学的理论研究不同，软件工程是一门原理性学科。　　（　　）

二、选择题

1．在下列选项中，（　　）不是软件的特征。

A．系统性与复制性

B．可靠性与一致性

C．抽象性与智能性

D．有形性与可控性

2．软件危机的主要原因是（　　）。

A．软件工具落后

B．软件生产能力不足

C．对软件的认识不够

D．软件本身的特点及开发方法

3．下列说法中正确的是（　　）。

A．20世纪50年代提出了软件工程的概念

B．20世纪60年代提出了软件工程的概念

C．20世纪70年代出现了客户机/服务器技术

D．20世纪80年代软件工程学科达到成熟

4．（　　）是将系统化的、规范的、可定量的方法应用于软件的开发、运行和维护的过程，它包括方法、工具和过程三个要素。

A．软件生命周期

B．软件测试

C．软件工程

D．软件过程

5．在下列选项中，（　　）不属于软件工程学科所要研究的基本内容。

A．软件工程材料

B．软件工程目标

C．软件工程原理

D．软件工程过程

6．软件工程的三要素是（　　）。

A．技术、方法和工具

B．方法、对象和类

C．方法、工具和过程

D．过程、模型和方法

7．用来辅助软件开发、运行、维护、管理、支持等过程中的活动的软件称为软件开发工具,通常也称为（　　）工具。

A．CAD

B．CAI

C．CAM

D．CASE

三、简答题

1．与计算机硬件相比，计算机软件有哪些特点？

2．软件就是程序吗？如何定义软件？

3．什么是软件危机？什么原因导致了软件危机？

4．为什么说软件工程的发展可以在一定程度上解决软件危机的各种弊端？

5．请简述软件工程研究的内容。

6．请简述软件工程的三要素。

7．请简述软件工程的目标、过程和原则。

8．请简述软件工程的基本原则。

9．请简述现代软件工程与传统软件工程显著的区别和改进。第2章 软件过程

软件工程过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

在完成开发任务时必须进行一些开发活动，并且使用适当的资源（人员、时间、计算机硬件、软件工具等），在过程结束时将输入（如软件需求）转化为输出（如软件产品），因此，ISO9000把过程定义为“把输入转化为输出的一组彼此相关的资源和活动”。过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。为获得高质量的软件产品，软件工程过程必须科学、合理。

本章讲述在软件生命周期全过程中应该完成的基本任务，并介绍各种常用的过程模型。2.1 软件生命周期的基本任务

概括地说，软件生命周期由软件定义、软件开发和运行维护3个时期组成，每个时期又可进一步划分成若干个阶段。

软件定义时期的任务是确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制订工程进度表。这个时期的工作通常又称为系统分析，由系统分析员负责完成。软件定义时期通常进一步划分为3个阶段，即问题定义、可行性研究和需求分析。

软件开发时期具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：概要设计、详细设计、编码和单元测试、综合测试。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。

运行维护时期的主要任务是使软件持久地满足用户的需要。具体地说，当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件以满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。

下面简要介绍上述各个阶段应该完成的基本任务。

1．问题定义

问题定义阶段必须回答的关键问题是：“要解决的问题是什么”。如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。

通过调研，系统分析员应该提出关于问题性质、工程目标和工程规模的书面报告，并且需要得到客户对这份报告的确认。

2．可行性研究

这个阶段要回答的关键问题是：“上一个阶段所确定的问题是否有行得通的解决办法”。并非所有问题都有切实可行的解决办法，事实上，许多问题不可能在预定的系统规模或时间期限之内解决。如果问题没有可行的解，那么花费在这项工程上的任何时间、资源和经费都是无谓的浪费。

可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。必须记住，可行性研究的目的不是解决问题，而是确定问题是否值得去解。要达到这个目的，不能靠主观猜想而只能靠客观分析。系统分析员必须进一步概括地了解用户的需求，并在此基础上提出若干种可能的系统实现方案，对每种方案都从技术、经济、社会因素（如法律）等方面分析可行性，从而最终确定这项工程的可行性。

3．需求分析

这个阶段的任务仍然不是具体地解决客户的问题，而是准确地回答“目标系统必须做什么”这个问题。

虽然在可行性研究阶段已经粗略了解了用户的需求，甚至还提出了一些可行的方案，但是，可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的解法，因此许多细节被忽略了。然而在最终的系统中却不能遗漏任何一个微小的细节，所以可行性研究并不能代替需求分析，它实际上并没有准确地回答“系统必须做什么”这个问题。

需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰和具体的要求。

用户了解他们所面对的问题，知道必须做什么，但是通常不能完整准确地表达出他们的要求，更不知道怎样利用计算机解决他们的问题；软件开发人员知道怎样用软件实现人们的要求，但是对特定用户的具体要求并不完全清楚。因此，系统分析员在需求分析阶段必须与用户密切配合，充分交流信息，以得出经过用户确认的系统需求。

这个阶段的另外一项重要任务，是用正式文档准确地记录对目标系统的需求，该文档通常称为规格说明（specification）。

4．概要设计

这个阶段的基本任务是：概括地回答“怎样实现目标系统？”概要设计又称为初步设计、逻辑设计、高层设计或总体设计。

首先，应该设计出实现目标系统的几种可能的方案。软件工程师应该用适当的表达工具描述每种可能的方案，分析每种方案的优缺点，并在充分权衡各种方案利弊的基础上，推荐一个最佳方案。此外，还应该制定出实现所推荐方案的详细计划。如果客户接受所推荐的系统方案，则应该进一步完成本阶段的另一项主要任务。

上述设计工作确定了解决问题的策略及目标系统中应包含的程序。但是，对于怎样设计这些程序，软件设计的一条基本原理指出，程序应该模块化，也就是说，一个程序应该由若干个规模适中的模块按合理的层次结构组织而成。因此，概要设计的另一项主要任务就是设计程序的体系结构，也就是确定程序由哪些模块组成以及模块间的关系。

5．详细设计

概要设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化，也就是回答“应该怎样具体地实现这个系统”这个关键问题。

这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。

详细设计也称为模块设计、物理设计或低层设计。在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。

6．编码和单元测试

这个阶段的关键任务是写出正确的，容易理解、容易维护的程序模块。

程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时用汇编语言），把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。

7．综合测试

这个阶段的关键任务是通过各种类型的测试（及相应的调试）使软件达到预定的要求。最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。所谓验收测试则是按照规格说明书的规定（通常在需求分析阶段确定），由用户（或在用户积极参加下）对目标系统进行验收。必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。为了使用户能够积极参加验收测试，并且在系统投入生产性运行以后能够正确有效地使用这个系统，通常需要以正式的或非正式的方式对用户进行培训。通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求，也可以决定测试和调试过程什么时候可以结束。应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，作为软件配置的一个组成部分。

8．软件维护

维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。通常有 4类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。

虽然没有把维护阶段进一步划分成更小的阶段，但是实际上每一项维护活动都应该经过提出维护要求（或报告问题），分析维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此，实质上是经历了一次压缩和简化了的软件定义和开发的全过程。

每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。我国国家标准《计算机软件开发规范》（GB8566——88）也把软件生命周期划分成8个阶段，这些阶段是：可行性研究与计划，需求分析，概要设计，详细设计，实现，组装测试，确认测试，使用和维护。其中，实现阶段即是编码与单元测试阶段，组装测试即是集成测试，确认测试即是验收测试。可见，国家标准中划分阶段的方法与前面介绍的阶段划分方法基本相同，差别仅仅是：因为问题定义的工作量很小而没有把它作为一个独立的阶段列出来；由于综合测试的工作量过大而把它分解成了两个阶段。

在实际从事软件开发工作时，软件规模、种类、开发环境及开发时使用的技术方法等因素，都影响阶段的划分。事实上，承担的软件项目不同，应该完成的任务也有差异，没有一个适用于所有软件项目的任务集合。适用于大型复杂项目的任务集合，对于小型且较简单的项目而言往往就过于复杂了。因此，一个科学、有效的软件工程过程应该定义一组适合于所承担的项目特点的任务集合。一个任务集合通常包括一组软件工程工作任务、里程碑和应该交付的产品（软件配置成分）。

生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。

试读结束[说明：试读内容隐藏了图片]

下载完整电子书