软件工程导论第5版

1、 软件工程导论（第5版） 全国普通高等高校工科电子类专业优秀教材张海藩 编著1本书提纲第1章 软件工程学概述 第8章 维护第2章 可行性研究 第9章 面向对象方法学引论第3章 需求分析 第10章 面向对象分析第4章 形式化说明技术 第11章 面向对象设计第5章 总体设计 第12章 面向对象实现第6章 详细设计 第13章 软件项目管理第7章 实现注: 授课进度安排2第1章 软件工程学概述计算机与信息工程学院3本章主要内容1.1 软件危机1.2 软件工程1.3 软件生命周期1.4 软件过程1.5 本章小结4软件的经典定义：软件=“完成特定功能的程序+数据结构+文档”特征：1、软件是开发的，而不是制

2、造的；2、软件不磨损，但退化；(故障率的浴缸线 VS 锯齿线) 3、自定义。1.1 软件危机5计算机系统发展的四个阶段： 计算机系统发展的早期阶段（20世纪60年代中期以前） 大多数人把软件看成是不需预先计划的事情 计算机系统发展的第二阶段（从60年代中期到70年代中期） 主要特点是软件产品的使用和“软件作坊”的出现 计算机系统发展的第三阶段（从70年代中期到80年代中期） 主要特点是微处理器的出现和应用，计算机应用大众化 计算机系统发展的第四个阶段（至今） 不再是着重于单台计算机和计算机程序，而是面向计算机和软件的综合影响。注：计算机体系结构+软件产业经济1.1 软件危机6 一系列软件相关的

3、问题在计算机系统的整个发展过程中一直存在着，而且这些问题还会继续恶化： 硬件的发展超过软件，建造的软件难以发挥硬件的潜能； 现有软件与用户的要求矛盾； 软件失败导致“灾难性后果”； 需要高质量、高可靠性的软件； 设计的问题使得升级和维护十分困难；1.1 软件危机7 为了更有效地开发与维护软件，软件工作者在20世纪60年代后期开始认真研究消除软件危机的途径，从而逐渐形成了一门新兴的工程学科计算机软件工程学(通常简称为软件工程)。 注：1968年北大西洋公约组织的计算机科学家在联邦德国召开国际会议，讨论软件危机问题，在这次会议上正式提出并使用了“软件工程”这个名词，一门新兴的工程学科就此诞生了。1

4、.1 软件危机81.1 软件危机1.1.1 软件危机的介绍 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 这些问题绝不仅仅是不能正常运行的软件才具有的，实际上，几乎所有软件都不同程度地存在这些问题。 具体地说，软件危机主要有以下一些典型表现：9 (1) 对软件开发成本和进度的估计常常很不准确。 (2) 用户对“已完成的”软件系统不满意的现象经常发生。 (3) 软件产品的质量往往靠不住。 (4) 软件常常是不可维护的。 (5) 软件通常没有适当的文档资料。 (6) 软件成本在计算机系统总成本中所占的比例逐年上升。 (7) 软件产品“供不应求”。1.1 软件危机101.1 软

5、件危机1.1.2 产生软件危机的原因 在软件开发和维护的过程中存在这么多严重问题，一方面与软件本身的特点有关，另一方面也和软件开发与维护方法不正确有关。 11 软件缺乏“可见性”，管理和控制软件开发过程相当困难 软件规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升 开发时期引入错误，导致软件维护通常意味着改正或修改原来的设计，客观上使得软件较难维护 软件专业人员对软件开发和维护中或多或少地采用了错误的方法和技术1.1 软件危机12 1983年IEEE为软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。虽然表面上看来在这个定义中列出了软件的5个配

6、置成分，但是方法和规则通常是在文档中说明并在程序中实现的。1.1.3 消除软件危机的途径 （1）首先应对“计算机软件”有一个正确的认识。应该彻底消除在计算机系统早期发展阶段形成的“软件就是程序”的错误观念。一个软件必须由一个完整的配置组成，事实上，软件是程序、数据及相关文档的完整集合。 1.1 软件危机处理信息的数据结构完成预定功能和性能的可执行的指令序列开发、使用和维护程序所需要的图文资料13 （2）应该推广使用在实践中总结出来的开发软件的成功的技术和方法。研究探索更好更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。 （3）应该开发和使用更好的软件工具。在适当的

7、软件工具辅助下，开发人员可以把这类工作做得既快又好。如果把各个阶段使用的软件工具有机地集合成一个整体，支持软件开发的全过程，则称为软件工程支撑环境。1.1 软件危机14 综上，为了解决软件危机，既要有技术措施(方法和工具)，又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。1.1 软件危机15本章主要内容1.1 软件危机1.2 软件工程1.3 软件生命周期1.4 软件过程1.5 本章小结161.2 软件工程1.2.1 软件工程的介绍 软件工程是指导软件开发与维护的工程性学科，采用工程的概念、原理、技术和方法来开发与维护软件。 人们曾经给软

8、件工程下过许多定义，下面给出两个典型的定义：17 1968年在第一届NATO会议上曾经给出了软件工程的一个早期定义：“软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。”这个定义不仅指出了软件工程的目标是经济地开发出高质量的软件，而且强调了软件工程是一门工程学科，它应该建立并使用完善的工程原理。 1993年IEEE进一步给出了一个更全面更具体的定义：“软件工程是： 把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件； 研究中提到的途径。”1.2 软件工程18 虽然软件工程的不同定义使用了不同词句，强调的重点也有差异，

9、但是，人们普遍认为软件工程具有下述的本质特性。 1. 软件工程关注于大型程序的构造 “大”与“小”的分界线并不十分清晰。通常把一个人在较短时间内写出的程序称为小型程序，而把多人合作用时半年以上才写出的程序称为大型程序。传统的程序设计技术和工具是支持小型程序设计的，不能简单地把这些技术和工具用于开发大型程序。1.2 软件工程19 2. 软件工程的中心课题是控制复杂性 将问题分解，使得分解出的每个部分是可理解的，而且各部分之间保持简单的通信关系。用这种方法并不能降低问题的整体复杂性，但是却可使它变成可以管理的。1.2 软件工程201.2 软件工程3. 软件经常变化 绝大多数软件都模拟了现实世界的某

10、一部分。现实世界在不断变化，软件为了不被很快淘汰，必须随着所模拟的现实世界一起变化。因此，在软件系统交付使用后仍然需要耗费成本，而且在开发过程中必须考虑软件将来可能的变化。4. 开发软件的效率非常重要 目前，社会对新应用系统的需求超过了人力资源所能提供的限度，软件供不应求的现象日益严重。因此，软件工程的一个重要课题就是，寻求开发与维护软件的更好更有效的方法和工具。21 5. 和谐地合作是开发软件的关键 软件处理的问题十分庞大，必须多人协同工作才能解决这类问题。为了有效地合作，必须明确地规定每个人的责任和相互通信的方法。事实上仅有上述规定还不够，每个人还必须严格地按规定行事。为了迫使大家遵守规定

11、，应该运用标准和规程。纪律是成功地完成软件开发项目的一个关键。1.2 软件工程22 6. 软件必须有效地支持它的用户 开发软件的目的是支持用户的工作。软件提供的功能应该能有效地协助用户完成他们的工作。如果用户对软件系统不满意，可以弃用该系统，至少也会立即提出新的需求。因此，仅仅用正确的方法构造系统还不够，还必须构造出正确的系统。 1.2 软件工程23 7. 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品 软件工程师不仅缺乏应用领域的实际知识，他们还缺乏该领域的文化知识。例如，软件开发者通过访谈、阅读书面文件等方法了解到用户组织的“正式”工作流程，然后用软件实现了这个工

12、作流程。但是，决定软件系统成功与否的关键问题是，用户组织是否真正遵守这个工作流程。对于局外人来说，这个问题更难回答。1.2 软件工程241.2.2 软件工程的基本原理 自从1968年在联邦德国召开的国际会议上正式提出并使用了“软件工程”这个术语以来，研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或“信条”。著名的软件工程专家B.W.Boehm综合这些学者们的意见并总结了TRW公司多年开发软件的经验，于1983年在一篇论文中提出了软件工程的7条基本原理。他认为这7条原理是确保软件产品质量和开发效率的最小集合。1.2 软件工程25 这7条原理是互相独立，缺一不可的。然而这7条原理又

13、是相当完备的，在此之前已经提出的100多条软件工程原理都可以由这7条原理的任意组合蕴含或派生。 下面简要介绍软件工程的7条基本原理。 1. 用分阶段的生命周期计划严格管理 有人经统计发现，在不成功的软件项目中有一半左右是由于计划不周造成的，可见把建立完善的计划作为第一条基本原理是吸取了前人的教训而提出来的。1.2 软件工程26 2. 坚持进行阶段评审：错误有放大效应 当时已经认识到，软件的质量保证工作不能等到编码阶段结束之后再进行。因为：第一，大部分错误是在编码之前造成的，据统计，设计错误占软件错误的63%，编码错误仅占37%；第二，错误发现与改正得越晚，所需付出的代价也越高。因此，在每个阶段

14、都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误是一条必须遵循的重要原则。1.2 软件工程27 3. 实行严格的产品控制：不随意改变需求 当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理，也称为变动控制：一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。绝对不能谁想修改软件，就随意进行修改。1.2 软件工程28 4. 采用现代程序设计技术 从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术，并进一步研究各种先进的软件开发与维护技术。实践表明，采用先进的

15、技术不仅可以提高软件开发和维护的效率，而且可以提高软件产品的质量。 5. 结果可以清楚地审查 软件产品不同于一般的物理产品，它是看不见摸不着的逻辑产品。软件开发人员(或开发小组)的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难于评价和管理。为了提高软件开发过程的可见性，应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。1.2 软件工程29 6. 开发小组的人员应该少而精：减少通讯开销 软件开发小组的组成人员的素质应该好，人数不宜过多。开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。素

16、质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件中的错误。此外，随着开发小组人员数目的增加，因为交流情况讨论问题而造成的通信开销也急剧增加。因此，组成少而精的开发小组是软件工程的一条基本原理。1.2 软件工程30 7. 承认不断改进软件工程实践的必要性 Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第7条基本原理。要求：不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。1.2 软件工程311.2.3 软件工程方法学 软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学

17、科。 通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学(methodology)，也称为范型(paradigm)。在软件工程领域中，这两个术语的含义基本相同。1.2 软件工程32 软件工程方法学包含3个要素：方法、工具和过程。 方法：是完成软件开发的各项任务的技术方法，回答“怎样做”的问题； 工具：是为运用方法而提供的自动的或半自动的软件工程支撑环境； 过程：是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 目前使用得最广泛的软件工程方法学，分别是传统方法学和面向对象方法学。1.2 软件工程33 1. 传统方法学 传统方法学也称为生命周期方法

18、学或结构化范型。 这种方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务。采用这种方法学开发软件的时候，从对问题的抽象逻辑分析开始，一个阶段一个阶段地进行开发。1.2 软件工程34 前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的实现细节。 每一个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和管理两方面对这个阶段的开发成果进行检查，通过之后这个阶段才算结束；反之则

19、必须进行必要的返工，之后还要再经过审查。审查的一条主要标准就是每个阶段都应该交出最新的高质量的文档资料。1.2 软件工程35 2. 面向对象方法学 当软件规模庞大，或者对软件的需求是模糊的或会随时间而变化的时候，使用传统方法学开发软件往往不成功，此外使用传统方法学开发出的软件，维护起来仍然很困难。1.2 软件工程36 概括地说，面向对象方法学具有下述4个要点。 (1) 把对象(object)作为融合了数据及在数据上的操作行为的统一的软件构件。用对象分解取代了传统方法的功能分解。 (2) 把所有对象都划分成类(class)。每个类都定义了一组数据和操作，类是对具有相同数据和相同操作的一组相似对象

20、的定义。 (3) 按照父类与子类的关系，把若干个相关类组成一个层次结构的系统。类等级中，下层派生类自动拥有上层基类中定义的数据和操作，即为继承。 (4) 对象彼此间通过发送消息互相联系。1.2 软件工程37 面向对象方法学的出发点和基本原则，是尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程，从而使描述问题的问题空间(也称为问题域)与实现解法的解空间(也称为求解域)在结构上尽可能一致。1.2 软件工程38 传统方法学强调自顶向下顺序地完成软件开发的各阶段任务。事实上，人类认识客观世界解决现实问题的过程，是一个渐进的过程。人的认识需要在继承已有的有关知

21、识的基础上，经过多次反复才能逐步深化。 用面向对象方法学开发软件的过程，是一个主动地多次反复迭代的演化过程。面向对象方法在概念和表示方法上的一致性，保证了在各项开发活动之间的平滑(即无缝)过渡。1.2 软件工程39本章主要内容1.1 软件危机1.2 软件工程1.3 软件生命周期1.4 软件过程1.5 本章小结401.3 软件生命周期 软件生命周期由软件定义、软件开发和运行维护3个时期组成，每个时期又进一步划分成若干个阶段。 （1）软件定义时期的任务是确定软件开发工程必须完成的总目标、工程的可行性、应采用的策略及系统必须完成的功能；估计需要的资源和成本，并且制定工程进度表。这个时期的工作通常又称

22、为系统分析，由系统分析员负责完成。该时期可划分为3个阶段，即问题定义、可行性研究和需求分析。41 （2）开发时期具体设计和实现前一个时期定义的软件，通常由4个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。 （3）维护时期的主要任务是使软件持久地满足用户的需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。1.3 软件生命周期421. 问题定义“需要解决的问题是什么？” 对问题正确理解 澄清含糊的地方1.3 软件生命周期43 2. 可行性研究“寻求可行的解决方案？” 高层次的分析

23、+ 估算系统的成本和效益 =可研报告1.3 软件生命周期44 3. 需求分析“解决这些问题需要系统做什么？” 与用户的交流 生成系统的逻辑模型 系统规格说明书1.3 软件生命周期45 4. 总体设计（概要设计）“应该怎样实现目标系统？” 给出几种可能的方案： 低成本方案 只做必需的功能 中成本方案 必需 + 附加功能 高成本方案 完美方案 设计程序的体系结构，确定组成模块及其 之间的关系 1.3 软件生命周期46 5. 详细设计（模块设计） “如何具体地实现这个系统？” 设计详细的规格说明（工程蓝图）1.3 软件生命周期47 6. 编码和单元测试“写代码，测试每个模块！” 选取程序设计语言 编

24、写单元测试文档1.3 软件生命周期48 7. 综合测试“通过各类测试和调试来完善软件” 集成测试 + 验收测试(用户参加) 正式或非正式的用户培训 测试的计划和方案1.3 软件生命周期49 8. 软件维护“通过各种必须的维护活动使系统持久地满足用户的需要！” 改正性维护 适应性维护 完善性维护 预防性维护1.3 软件生命周期50本章主要内容1.1 软件危机1.2 软件工程1.3 软件生命周期1.4 软件过程1.5 本章小结51 软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 通常使用生命周期模型简洁地描述软件过程。生命周期模型规定了把生命周期划分成哪

25、些阶段及各个阶段的执行顺序，因此，生命周期模型也称为过程模型。 1.4 软件过程521.4.1 瀑布模型线性模型之一 在20世纪80年代之前，瀑布模型一直是惟一被广泛采用的生命周期模型。传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。 1.4 软件过程531.4 软件过程图1.2 传统的瀑布模型单向箭头54瀑布模型的特点： （1）阶段间具有顺序性和依赖性（2）推迟实现的观点 典型特点（3）质量保证的观点瀑布模型的问题：（1）实际的项目很少顺序严格混乱（2）用户往往难以给出具体、正确、完整的要求（3）用户必须有耐心产品出现晚+大错误灾难（4）开发人员“阻塞状态”严重1.4 软件过程55

26、1.4 软件过程图1.3 实际的瀑布模型反馈环56 理解软件错误的累积和放大效应 审查的一般方法 坚持阶段审查 审查小组：成员构成 审查步骤： 准备介绍读文档开会返工复查技术审查与管理复审571.4.2 快速原型模型 1.4 软件过程需求收集（听取用户）建造/修改模型（快速设计）用户测试（运行原型）581.4 软件过程图1.4 快速原型模型59快速原型模型的特点： (1) 出品速度快；(2) 逐步求精；(3) 开发阶段迭代。快速原型模型的问题： (1) 第一个系统很少可用；(2) 原型中拼凑的问题：缺乏长期考虑；(3) 实现过程中不应有的折衷方案。1.4 软件过程601.4.3 增量模型 增量

27、模型也称为渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。1.4 软件过程611.4 软件过程图1.5 增量模型62增量模型的特点： (1) 结合了线性模型和原型模型的特点；(2) 每个增量可以结合原型法；(3) 系统的问世提前“增量1”增量模型的问题： 开放的软件体系结构 中心思想：“渐进开发，逐步完善”1.4 软件过程631.4 软件过程图1.6 风险更大的增量模型641.4.4 螺旋模型风险驱动1.4 软件过程 实际开发成本超过预算 项目进度落后 关键开发人员“跳槽” 相似产品投入市场 用户对产品不满意 螺旋模型可看作是在每个阶段之前都增加了风险

28、分析过程的快速原型模型。651.4 软件过程图1.7 简化的螺旋模型适合规模庞大、复杂且高风险的项目661.4 软件过程图1.8 完整的螺旋模型快速原型规格说明设 计编码与综合测试67螺旋模型的特点：（1）有利于已有软件的重用；（2）软件质量成为软件开发的一个重要目标；（3）减少了软件测试带来的风险；（4）维护成为模型的一个周期，与开发无本质区别。螺旋模型的问题：（1）主要适用于内部开发的大规模软件项目；（2）要求软件开发人员具有丰富的风险评估经验和知识1.4 软件过程681.4.5 喷泉模型 喷泉模型是典型的面向对象的软件过程模型之一，“喷泉”较好地体现了面向对象软件开发过程迭代和无缝的特性

29、。如图1.9所示。1.4 软件过程691.4 软件过程图1.9 喷泉模型701.4.6 典型的软件过程 Rational统一过程：RUP 极限编程：XP 微软过程 1.4 软件过程71Rational统一过程最佳实践（6条经验） 迭代式开发； 管理需求； 使用基于构件的体系结构； 可视化建模； 验证软件质量； 控制软件变更。1.4 软件过程721.4 软件过程RUP软件开发生命周期73敏捷过程敏捷软件开发宣言： 个体和交互胜过过程和工具； 可以工作的软件胜过面面俱到的文档； 客户合作胜过合同谈判； 相应变化胜过遵循计划。1.4 软件过程 根据上述价值观提出的软件过程称为敏捷过程。74极限编程(

30、eXtreme Programming)有效实践客户作为开发团队的成员； 使用用户素材；短交付周期； 验收测试；结对编程； 测试驱动开发；集体所有； 持续集成；可持续的开发速度； 开放的工作空间；及时调整计划； 简单的设计；重构； 使用隐喻。1.4 软件过程75XP项目的整体开发过程76XP迭代开发过程77极限编程(eXtreme Programming) 以极限编程为杰出代表的敏捷过程，具有对变化和不确定性的更快速、更敏捷的反应特性，而且在快速的同时仍然能够保持可持续的开发速度。 敏捷过程能够较好地适应商业竞争环境下小型项目提出的有限资源和有限开发时间的约束。1.4 软件过程78微软过程微软

31、过程准则 项目计划应该兼顾未来的不确定因素； 用有效的风险管理来减少不确定因素的影响； 经常生成并快速地检测软件的过渡版本，提高产品稳定性和可预见性； 采用快速循环、递进的开发过程； 用创造性的工作来平衡产品特性和产品成本； 项目进度表应该具有较高稳定性和权威性； 使用小型项目组并发地完成开发工作； 在项目早期把软件配置项基线化，项目后期则冻结产品； 使用原型验证概念，对项目进行早期论证； 把零缺陷作为追求的目标； 里程碑评审会的目的是改进工作，切忌互相指责。1.4 软件过程79微软过程1.4 软件过程微软软件生命周期阶段划分和主要里程碑 80微软过程1.4 软件过程微软过程的生命周期模型81

32、本章问题讨论 (1)宇宙飞船软件问题：“有4000万行代码，设每人每年写10000行；问是否集中4000人写一年就可以完成？” (2) “我们已有专业书籍和软件制作规范(标准)，是否可以回答我们在开发过程中的所有问题呢？”82(3) “如果我们落后于计划，就增加程序员来赶上进度？”(4)用户：“有了对问题的一般描述就可以写程序了，至于细节以后再慢慢讨论！”(5) “项目需求总在变化，但这些变化是容易满足的，因为软件是灵活的！”本章问题讨论83(6) 程序员：“只要我们写出程序并使其正确运行，那我们的任务就over了！”(7) “在程序真正运行之前，没有方法评估其质量！”(8) “成功项目提交的就是正确的程序”本章问题讨论84本章主要内容1.1 软件危机1.2 软件工程1.3 软件生命周期1.4 软件过程1.5 本章小结851.5 小结 首先通过回顾计算机系统发展简史，说明开发软件的一些错误方法和观念是怎样形成的；然后列举了这些错误方法带来的严重弊病(软件危机)，澄