第7章SEI软件工程环境
合集下载
软件工程第7章 软件维护与再工程
在测试结束时进行最正式的可维护性复审，这个复审 称为配置复审。配置复审的目的是保证软件配置的所 有成分是完整的、一致的和可理解的，而且为了便于 修改和管理已经编目归档了。
3. 软件维护实施
开发组可承担软件初期维护，但当软件转入正 常使用以后，其维护工作则一般由专门的维护 机构承担。软件维护机构人员组成有：维护负 责人、系统监督员、配置管理员、维护工程师。 其中，维护负责人全权负责维护任务，包括技 术与管理两个方面的工作。
4. 软件再工程
软件再工程是指对已存在软件系统的重构与扩 充。
再工程主要用于一些老系统改造，所涉及活动 有：逆向工程、重构工程、正向工程。
典型的软件再工程过程模型如下图所示。在某些情况下这 些活动以线性顺序发生，但也并非总是这样。例如，为了理 解某个程序的内部工作原理，可能在文档重构开始之前必须 先进行逆向工程。
在维护活动开始之前就明确维护 责任是十分必要的，这样做可以大大 减少维护过程中可能出现的混乱。
维护管理员
转交维护要求
系统管理员
评价后上交， 促成决定活动
指定维护人员
程序技术人员
变化授权人
2. 维护报告
应该用标准化的格式表达所有软件维护要求。 软件维护人员通常给用户提供空白的维护要求表—— 有时称为软件问题报告表，这个表格由要求一项维护活动 的用户填写。如果遇到了一个错误，那么必须完整描述导 致出现错误的环境(包括输入数据、全部输出数据以及其他 有关信息)。 对于适应性或完善性的维护要求，应该提出一个简短 的需求说明书。如前所述，由维护管理员和系统管理员评 价用户提交的维护要求表。
哪些维护资源是应该有而事实上却没有的? 对于这项维护工作什么是主要的(以及次要的)障碍? 要求的维护类型中有预防性维护吗? 处境复查对将来维护工作的进行有重要影响，而且所提供 的反馈信息对有效地管理软件组织十分重要。
3. 软件维护实施
开发组可承担软件初期维护，但当软件转入正 常使用以后，其维护工作则一般由专门的维护 机构承担。软件维护机构人员组成有：维护负 责人、系统监督员、配置管理员、维护工程师。 其中，维护负责人全权负责维护任务，包括技 术与管理两个方面的工作。
4. 软件再工程
软件再工程是指对已存在软件系统的重构与扩 充。
再工程主要用于一些老系统改造，所涉及活动 有：逆向工程、重构工程、正向工程。
典型的软件再工程过程模型如下图所示。在某些情况下这 些活动以线性顺序发生，但也并非总是这样。例如，为了理 解某个程序的内部工作原理，可能在文档重构开始之前必须 先进行逆向工程。
在维护活动开始之前就明确维护 责任是十分必要的，这样做可以大大 减少维护过程中可能出现的混乱。
维护管理员
转交维护要求
系统管理员
评价后上交， 促成决定活动
指定维护人员
程序技术人员
变化授权人
2. 维护报告
应该用标准化的格式表达所有软件维护要求。 软件维护人员通常给用户提供空白的维护要求表—— 有时称为软件问题报告表，这个表格由要求一项维护活动 的用户填写。如果遇到了一个错误，那么必须完整描述导 致出现错误的环境(包括输入数据、全部输出数据以及其他 有关信息)。 对于适应性或完善性的维护要求，应该提出一个简短 的需求说明书。如前所述，由维护管理员和系统管理员评 价用户提交的维护要求表。
哪些维护资源是应该有而事实上却没有的? 对于这项维护工作什么是主要的(以及次要的)障碍? 要求的维护类型中有预防性维护吗? 处境复查对将来维护工作的进行有重要影响，而且所提供 的反馈信息对有效地管理软件组织十分重要。
软件工程-第7章第1节
7.1.2 瀑布模型的特点
在这种严格定义的模型中，开发人员试图在每一活 动过程结束后，通过严格的阶段性复审与确认，得 到该阶段的一致、完整、准确和无二义性的良好文 档，以“冻结”这些文档为该阶段结束的标志，保 持不变，作为下一阶段活动的唯一基础，从而形成 一个理想的线性开发序列，以每一步的正确性和完 整性来保证最终系统的质量。
要求定义 确认
需求说明书
设计 确认
设计说明书
编码 确认
源程序清单
测试 确认
测试报告
维护 确认软件维护报告源自7.1.2 瀑布模型的特点
瀑布模型严格按照生存周期各个阶段的目标、任务、文档和要求来进行 开发。它强调了每一阶段的严格性，尤其是开发前期的良好需求说明， 这样，就能解决在开发阶段后期修正不完善的需求说明将花费巨大的费 用的问题。于是人们需付出很大的努力来加强各阶段活动的严格性，特 别是要求定义阶段，希望得到完整、准确、无二义性的需求说明，以减 少后面各阶段不易估量的浪费。在传统的观念中，人们认为只要认真努 力，总可以通过详尽分析来确定完整、准确的需求说明，从而明确系统 的各种需求，只要采用一套严格规定的术语及表达方式，就一定可以准 确清楚地表达和通讯，以便在严格的开发管理下得到完美的结果。
7.1.2 瀑布模型的特点
瀑布模型是以文档形式驱动的，为合同双方最终确认的产品规定了蓝本，为管 理者进行项目开发管理提供了基础，为开发过程施加了“政策”或纪律限制， 约束了开发过程中的活动。 瀑布模型以里程碑开发原则为基础，提供各阶段的检查点，确保用户需求，满 足预算和时间限制。 瀑布模型是一种整体开发模型，在开发过程中，用户看不见系统是什么样，只 有开发完成，向用户提交整个系统时，用户就能看到一个完整的系统。 瀑布模型适合于功能和性能明确、完整、无重大变化的软件开发。大部分的系 统软件就具有这些特征，例如编译系统、数据库管理系统和操作系统等。在开 发前均可完整、准确、一致和无二义性地定义其目标、功能和性能等。
软件工程环境
软件工程环境软件工程环境是软件工程学的组成部分,也是实现软件生产工程化的重要基础。
“工欲善其事,必先利其器”,在软件开发中,无论技术活动与管理活动,都离不开环境(包括工具）的支持。
近20多年来,各技术先进国家大力开展软件环境的研究,计算机辅助软件工程( computer-aided software engineering,简称CASE)、集成化项目支持环境(Integrated Project Support Environment，简称IPSE)等课题,始终都受到人们的关注,一大批实用的环境应运而生。
这些环境建立在现代软件开发的基础上,反过来又促进了现代方法的推广与流行,不仅提高了软件的生产率,而且逐渐影响和改变着软件的生产方式。
本章将简要叙述软件工程环境的变迁、现状和发展趋势,使读者进一步了解学习和研究软件工程环境的意义。
13.1什么是软件工程环境“环境”一词,对不同的用户往往具有不同的含义。
对于不从事软件开发的最终用户( end-user)来说,环境就是他运行程序所使用的计算机—由硬件和操作系统所组成的虚拟机。
这类用户对环境的要求,主要是运行可靠、操作容易,便于掌握和使用。
对于开发者来说,环境是他们进行开发活动的重要舞台。
在软件工程时代,开发者要求环境支持他们按照软件工程的方法,全面完成生存周期中的各项任务。
通常把这种开发环境称为软件工程环境,而把前一类环境称为运行环境或工作环境。
具体而言,软件工程环境是指支持软件产品开发、维护和管理的软件系统,它在统一的集成机制下由一系列软件工具组成。
这些工具对与软件开发相关的过程、活动和任务提供全面的支持,从而大大提高软件产品的生产效率和软件产品的质量,降低软件开发、维护和管理的成本。
这类环境通常都有一套包括数据集成、控制集成和界面集成的集成机制,让各个工具使用统一的、规范存取的环境信息仓库,采用统一的用户界面,同时为各个工具或开发活动之间的通信、切换、调度和协同工作提供支持。
第7章计算机软件开发软件工程
计算机科学与技术系
计算机科学与技术总论
二、软件工程的基本原则
6、软件测试
计算机科学与技术系
计算机科学与技术总论
6.1 程序测试的基本概念
测试是软件开发的最后一个阶段，是保 证软件质量的重要环节，它是对需求分 析、设计和编码的最后复审，通过测试 可以发现和纠正软件中的错误，以保证 软件的可靠性。
计算机科学与技术系
计算机科学与技术系
计算机科学与技术总论
一、软件工程概念
❖ Boehm：运用现代科学技术知识来设计并构造 计算机程序及为开发、运行和维护这些程序 所必需的相关文件资料。
❖ IEEE：软件工程是开发、运行、维护和修复 软件的系统方法。
❖ Fritz Bauer：建立并使用完善的工程化原则， 以较经济的手段获得能在实际机器上有效运 行的可靠软件的一系列方法。
计算机科学与技术系
计算机科学与技术总论
6.2 测试的种类
❖ 在程序测试期，通常进行两类测试：人工测 试和机器测试。 ① 人工测试（静态测试） 对程序首先进行的不是机器测试，而是通过 人工集体协同的方式来对被测程序进行静态 审查，以发现代码中的错误。
计算机科学与技术系
计算机科学与技术总论
6.2 测试的种类
计算机科学与技术系
计算机科学与技术总论
1、瀑布模型 瀑布模型有什么缺 点？如何改进？
计算机科学与技术系
计算机科学与技术总论
❖ 从上一阶段接受本阶段工作的对象作为输入。 ❖ 本阶段的工作成果作为输出传入下一阶段。 ❖ 评估各阶段，若本阶段工作得到确认，继续，
否则返回前一阶段。 ❖ 可以增加反馈线来表示具有反馈回路的瀑布
计算机科学与技术系
计算机科学与技术总论
计算机科学与技术总论
二、软件工程的基本原则
6、软件测试
计算机科学与技术系
计算机科学与技术总论
6.1 程序测试的基本概念
测试是软件开发的最后一个阶段，是保 证软件质量的重要环节，它是对需求分 析、设计和编码的最后复审，通过测试 可以发现和纠正软件中的错误，以保证 软件的可靠性。
计算机科学与技术系
计算机科学与技术系
计算机科学与技术总论
一、软件工程概念
❖ Boehm：运用现代科学技术知识来设计并构造 计算机程序及为开发、运行和维护这些程序 所必需的相关文件资料。
❖ IEEE：软件工程是开发、运行、维护和修复 软件的系统方法。
❖ Fritz Bauer：建立并使用完善的工程化原则， 以较经济的手段获得能在实际机器上有效运 行的可靠软件的一系列方法。
计算机科学与技术系
计算机科学与技术总论
6.2 测试的种类
❖ 在程序测试期，通常进行两类测试：人工测 试和机器测试。 ① 人工测试（静态测试） 对程序首先进行的不是机器测试，而是通过 人工集体协同的方式来对被测程序进行静态 审查，以发现代码中的错误。
计算机科学与技术系
计算机科学与技术总论
6.2 测试的种类
计算机科学与技术系
计算机科学与技术总论
1、瀑布模型 瀑布模型有什么缺 点？如何改进？
计算机科学与技术系
计算机科学与技术总论
❖ 从上一阶段接受本阶段工作的对象作为输入。 ❖ 本阶段的工作成果作为输出传入下一阶段。 ❖ 评估各阶段，若本阶段工作得到确认，继续，
否则返回前一阶段。 ❖ 可以增加反馈线来表示具有反馈回路的瀑布
计算机科学与技术系
计算机科学与技术总论
软件工第7章
《软件工程(第3版)》陆惠恩主编
3
7.2 软件的可维护性
软件可维护性指软件被理解、改正、调整和改进的难易程度。
7.2.1 决定可维护性的因素
是否拥有一组训练有素的软件人员； 系统结构是否可理解、是否合理； 文档结构是否标准化； 测试用例是否合适； 是否已有嵌入系统的调试工具； 所选的程序设计语言是否合适； 所选的操作系统等是否合适。 其他，数据库技术、应用的类型、开发人员是否参加维护等。
《软件工程(第3版)》陆惠恩主编
5
7.2.2 可维护性的度量 7.2.3 提高软件的可维护性
1．明确软件工程的质量目标 2．利用先进的软件技术和工具 3．选择便于维护的程序设计语言 4．采取有效的质量保证措施 5．完善软件文档
《软件工程(第3版)》陆惠恩主编 4
第7章小结
软件维护（software maintenance） 就是在软件产品交付之后对其进行修改，以纠正错误，或改进性能和 其它属性，或使产品适应改变了的环境。 四种软件维护： 改正性维护、适应性维护、完善性维护和预防性维护。 软件可维护性就是维护人员对该软件进行维护的难易程度，具体包括 理解、改正、改动和改进该软件的难易程度。 提高软件的可维护性是软件工程各阶段追求的目标之一。 在开发时明确质量目标、考虑软件的维护问题是必须的、重要的。 在软件开发阶段提供完整、一致的文档，采用先进的软件开发方法和 软件开发工具是提高软件可维护性的关键。
第7章软件维护
本章内容：软件维护过程 软件的可维护性 本章重点：软件的可维护性。
7.1 软件维护
软件维护（software maintenance）就是在软件产品交付之后 为了延长使用寿命，对其进行修改以改正错误，或改进性能和其 它属性，或使产品适应改变了的环境。
软件工程 第7章--面向对象设计
8
§1. OOD准则
5、Cohesion：模块内各个元素彼此结合的紧密程度。 服务内聚(service cohesion)：一个服务只完成一个功能。
类内聚(class cohesion)：一个类只有一个用途，否则分 解之。
一般-特殊内聚（general-particular cohesion):
17
类构件
类构件：面向对象技术中的“类” 。类构件有3种 重用方式：
–实例重用 –继承重用 –多态重用 1. 可重用类构件应具备的特点 (1) 模块独立性强。具有单一、完整的功能，且经 过反复测试被确认是正确的。是一个不受或很少受 外界干扰的封装体，其内部实现在外面是不可见的。
18
(2) 具有高度可塑性。软构件的应用环境比集成电 路更广阔、更复杂。显然，要求一个软构件能满足 任何一个系统的设计需求是不现实的。因此，可重 用的软构件必须具有高度可裁剪性，必须提供为适 应特定需求而扩充或修改已有构件的机制，而且所 提供的机制必须使用起来非常简单方便。
对象 设计
面向对 象分析
人机界 面设计
任务管 理设计
数据管 理设计
4
§1. OOD准则
§1. OOD准则：优秀软件设计的一个重要特点是 容易维护
回顾：SD准则包括
Modularization Information hiding
Abstraction
Module independence
对于 OOD有类似的准则： 1、Module = Object
• Inheritance —— 无须改动原有代码
13
② 设计重用 —— 当移植系统时
§3. 软件重用
③ 分析重用 —— 当需求未变，而系统结构改变 时（例如将HDIS改为OO实现）
§1. OOD准则
5、Cohesion：模块内各个元素彼此结合的紧密程度。 服务内聚(service cohesion)：一个服务只完成一个功能。
类内聚(class cohesion)：一个类只有一个用途，否则分 解之。
一般-特殊内聚（general-particular cohesion):
17
类构件
类构件：面向对象技术中的“类” 。类构件有3种 重用方式：
–实例重用 –继承重用 –多态重用 1. 可重用类构件应具备的特点 (1) 模块独立性强。具有单一、完整的功能，且经 过反复测试被确认是正确的。是一个不受或很少受 外界干扰的封装体，其内部实现在外面是不可见的。
18
(2) 具有高度可塑性。软构件的应用环境比集成电 路更广阔、更复杂。显然，要求一个软构件能满足 任何一个系统的设计需求是不现实的。因此，可重 用的软构件必须具有高度可裁剪性，必须提供为适 应特定需求而扩充或修改已有构件的机制，而且所 提供的机制必须使用起来非常简单方便。
对象 设计
面向对 象分析
人机界 面设计
任务管 理设计
数据管 理设计
4
§1. OOD准则
§1. OOD准则：优秀软件设计的一个重要特点是 容易维护
回顾：SD准则包括
Modularization Information hiding
Abstraction
Module independence
对于 OOD有类似的准则： 1、Module = Object
• Inheritance —— 无须改动原有代码
13
② 设计重用 —— 当移植系统时
§3. 软件重用
③ 分析重用 —— 当需求未变，而系统结构改变 时（例如将HDIS改为OO实现）
软件工程-第7章修改
也可以用数据库系统等实现
源或宿
存在于软件系统之外的人员或组织，表示软件系统 输入数据的来源和输出数据的去向，因此也称为源 点和终点
例如，对一个考务处理系统而言 考生向系统提供报名单(输入数据流)，所以考生是考试系统(软件) 的一个源 考务处理系统要将考试成绩的统计分析表(输出数据流)传递给考 试中心，所以考试中心是该系统的一个宿
(5) 对需求说明进行复审，直到确认文档齐全， 并且符合用户的全部需求为止。
需求获取的常用方法 1.需求获取的目的
清楚地理解所要解决的问题
完整地获取用户需求
2.需求获取面临的挑战
问题的复杂性和对问题空间理解的不完备性
与不一致性
交流障碍
需求易变性
3.需求获取的常用方法
• 建立联合分析小组
源或宿用相同的图形符号表示
当数据流从该符号流出时表示是源 当数据流流向该符号时表示是宿 当两者皆有时表示既是源又是宿
（b）导出数据流图的过程
① ② ③
第0层的数据流图应将软件/系统描述为一个泡泡 主要的输入和输出应被仔细的标记 通过把下一层表示的候补处理过程、数据对象和数 据存储分离，开始求精过程
脉冲发生器 PC机 声波采集器 软件
软件数据建模 软件行为建模 软件功能建模
输入功能构件 输出功能构件 控制功能构件 操作界面构件
采集声波功能构件 控制脉冲输出构件 延时计算功能构件 操作界面构件
7.2 需求分析
为什么要需求分析？
需求分析就是要彻底理解要解决的问题，真正 明确用户需求。在解决问题之前要理解问题， 只有真正的理解问题才能更好的解决问题。 需求分析就是软件人员和用户之间进行交流， 以理解问题。需求分析是软件开发工程中的一 个重要阶段，在这个阶段中，软件系统分析人 员研究用户在需要解决问题上的意愿，分析出 软件系统应该达到的目标，以及有哪些功能要 求、性能要求等等。
第七章_软件工程(实现)
23
动态测试方法——黑盒和白盒测试 黑盒测试(black-box , or closed-box testing): 又称为功能测试或数据驱动测试，其测试用例完 全是根据程序的功能说明来设计的，测试者完全不考 虑程序内部结构和内部特征，把程序看成一个黑盒。 测试时只考虑如何找出使程序不按要求运行的情况， 因而测试是在程序接口处进行的。 黑盒测试主要能发现的错误 P180 白盒测试(white-box , clear-box testing): 白盒法又称为结构测试或逻辑驱动测试，其测试 用例根据程序内部的逻辑结构来设计的。以检测程序 内部的每条通路是否按预定要求正确工作。 24
主要问题：穷尽测试(complete test)通常是不可能的。
例：(Black-box) 程序要求输入3个整形数据。若字长 16位（即一个整形数据由16位二进制数组成）， 则各种可能输入的排列组合共有：
216 216 216 3 1014 （种）
若程序执行一次需10-3 秒，则对于所有合法输 入的测试大约需用一万年，而且还应测试输入非 法数据的情况。
一、定义
测试: 根据软件开发各阶段的规格说明和程序内部结 构而精心设计一批测试用例（即输入数据及预 期的输出结果），并利用这些测试用例去运行 程序，以发现程序中的错误的过程。p176 调试(纠错): 诊断程序的错误性质、出错的位臵并加 以改正的过程。通常由编码人员承担。 失败：当一个程序不能运行时称失败。失败是系统执 行中出现的情况，失败源于代码缺陷。 错误：程序中的缺陷所产生的不正确的结果称错误。
2、数据说明 P162
数据说明是在写程序时确定的，为了使 数据更容易理解和维护，需遵循以下原则：
数据说明的次序应该标准化；
动态测试方法——黑盒和白盒测试 黑盒测试(black-box , or closed-box testing): 又称为功能测试或数据驱动测试，其测试用例完 全是根据程序的功能说明来设计的，测试者完全不考 虑程序内部结构和内部特征，把程序看成一个黑盒。 测试时只考虑如何找出使程序不按要求运行的情况， 因而测试是在程序接口处进行的。 黑盒测试主要能发现的错误 P180 白盒测试(white-box , clear-box testing): 白盒法又称为结构测试或逻辑驱动测试，其测试 用例根据程序内部的逻辑结构来设计的。以检测程序 内部的每条通路是否按预定要求正确工作。 24
主要问题：穷尽测试(complete test)通常是不可能的。
例：(Black-box) 程序要求输入3个整形数据。若字长 16位（即一个整形数据由16位二进制数组成）， 则各种可能输入的排列组合共有：
216 216 216 3 1014 （种）
若程序执行一次需10-3 秒，则对于所有合法输 入的测试大约需用一万年，而且还应测试输入非 法数据的情况。
一、定义
测试: 根据软件开发各阶段的规格说明和程序内部结 构而精心设计一批测试用例（即输入数据及预 期的输出结果），并利用这些测试用例去运行 程序，以发现程序中的错误的过程。p176 调试(纠错): 诊断程序的错误性质、出错的位臵并加 以改正的过程。通常由编码人员承担。 失败：当一个程序不能运行时称失败。失败是系统执 行中出现的情况，失败源于代码缺陷。 错误：程序中的缺陷所产生的不正确的结果称错误。
2、数据说明 P162
数据说明是在写程序时确定的，为了使 数据更容易理解和维护，需遵循以下原则：
数据说明的次序应该标准化；