软件工程导论第八章
软件工程导论PPT课件-第8章-维护

分析评价,修改设计,编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序,缺乏必要的文档说 明,难于确定数据结构、系统接口等特性的情况下,进行 的软件维高昂
明显代价:高昂的维护费用,已上升达80%左右; 无形代价:
的工作环境,或适应已变动的数据或文件; (4)为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错,以及验证、修改的回归测试过程, 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求, 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化, 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等,或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审
软件工程导论(共65张PPT)可编辑全文

– 学生选课系统 软件
Microsoft Visio; Rational Rose
高级程序语言 作业递交方式:
来信标题注明 :班级 、学号、姓名、章节
第1章 软件工程学概述
1.1 软件危机
软件危机的出现:60年代中期到70年代中期, 许多软件最终成为不可维护的,这就是软件危 机.
不能用象硬件替换部件的方式修复软件的故障 使用增量模型的困难是,在把每个新的增量构件集成到现有软件体系结构中时,必须不破坏原来已经开发出的产品。
出现了“软件作坊”,软件作为一种产品被广泛使用;
使用个体化开发方式;
软件的发展史_2
随着软件数量的增加及软件需求的日趋复杂, 维护难度与来越大,开发成本高,质量低 导致“软件危机”
➢相同点:都将软件开发划分为分析、设计、编码、 测试等阶段 ➢不同点:思想不同,方法不同。另外,传统软件 工程更关注功能模块,面向对象软件工程更关注对 象的抽取和设计
➢ 两类软件工程方法学没有绝对的替代关系
1.3软件生命周期
生命周期方法学
从时间角度对软件开发和维护的复杂问题进行分解,把软件生命 的漫长周期依次划分为若干个阶段,每个阶段有相对独立的任务, 然后逐步完成每个阶段的任务。
关注大型程序的构造 中心问题是控制复杂性 软件经常变化 开发效率非常重要 和谐地合作是开发软件的关键 有效地支持它的用户 具有一种文化背景的人替另一种文化背景的人
创造产品
用分阶段的生命周期计划严格管理 坚持进行阶段评审 实行严格的产品控制 采用现代程序设计技术 结果应能清楚地审查 开发小组成员应少而精 承认不断改进软件工程实践地必要性
软件工作涉及到很多社会因素。 由于对象概念的引入,表达分析、设计及实现等活动只用对象类和关系,从而可以较容易地实现活动的迭代和无间隙
【信息化-精编】软件工程导论课后习题详细答案

【信息化-精编】软件工程导论课后习题详细答案软件工程导论课后习题详细答案《软件工程导论》课后习题答案第一章软件工程概论 1.什么是软件危机?软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
这些问题表现在以下几个方面:(1)用户对开发出的软件很难满意。
(2)软件产品的质量往往靠不住。
(3)一般软件很难维护。
(4)软件生产效率很低。
(5)软件开发成本越来越大。
(6)软件成本与开发进度难以估计。
(7)软件技术的发展远远满足不了计算机应用的普及与深入的需要。
2.为什么会产生软件危机?(1)开发人员方面,对软件产品缺乏正确认识,没有真正理解软件产品是一个完整的配置组成。
造成开发中制定计划盲目、编程草率,不考虑维护工作的必要性。
(2)软件本身方面,对于计算机系统来说,软件是逻辑部件,软件开发过程没有统一的、公认的方法论和规范指导,造成软件维护困难。
(3)尤其是随着软件规模越来越大,复杂程度越来越高,原有软件开发方式效率不高、质量不能保证、成本过高、研制周期不易估计、维护困难等一系列问题更为突出,技术的发展已经远远不能适应社会需求。
3.怎样克服软件危机?(1)充分吸收和借鉴人类长期以来从事各种工程项目中积累的行之有效的有效原理、概念、技术与方法,特别是吸取几十年来人类从事计算机硬件研究和开发的经验教训。
在开发软件的过程中努力作到良好的组织,严格的管理,相互友好的协作。
(2)推广在实践中总结出来的开发软件的成功的技术和方法,并研究更好、更有效的技术和方法,尽快克服在计算机系统早期发展阶段形成的一些错误概念和作法。
(3)根据不同的应用领域,开发更好的软件工具并使用这些工具。
将软件开发各个阶段使用的软件工具集合成一个整体,形成一个很好的软件开发支环环境。
总之为了解决软件危机,既要有技术措施(方法和工具),又要有必要的组织管理措施。
4.构成软件项目的最终产品:应用程序、系统程序、面向用户的文档资料和面向开发者的文档资料。
软件工程导论课件第8章

5. 数据重构 对数据体系结构差的程序很难进行适应性和 完善性维护,因此,数据体系结构比源代码对程序 的长期生存力有更大影响。 数据重构是一种全范围的再工程活动。由于 数据重构对程序体系结构及程序中的算法有很大影 响,对数据的修改必然会导致程序体系结构或代码 层的改变。
3
2.适应性维护 为适应变化了的环境界面而修改软件的活动, 称为适应性维护。包括: (1)因硬件或支撑软件改变引起的变化; (2)将软件移植到新的机种上运行; (3)因数据环境的变化而做的变更。 这类维护大约占软件维护总工作量的25%。
4
3.完善性维护 为了满足用户要求,就得对软件进行修改和 扩充,我们称这种维护为完善性维护。完善性维护 主要包括: (1)提高处理效率; (2)提高性能。 在整个维护工作中, 完善性维护大约占50% 左右,区居第一位。
3. 逆向工程 软件的逆向工程是,分析程序以便在比源代码 更高的抽象层次上创建出程序的某种描述的过程, 也就是说,逆向工程是一个恢复设计结果的过程。 4. 代码重构 某些老程序的体系结构比较合理,但是,一些 模块的编码方式却是难于理解、测试和维护的。在 这种情况下,可以重构这些模块的代码。 通常,代码重构并不修改程序的体系结构,它 只关注个体模块的设计细节以及在模块中定义的局 部数据结构。如果重构扩展到模块边界以外并涉及 软件体系结构,则重构变成了正向工程。
13
(四)软件维护过程 维护过程的实质是对软件定义和开发过程的修 改和压缩。维护过程的主要任务是:建立维护机构, 填写维护报告和评价,为每个维护要求规定一种规 范化的处理序列,建立对维护活动的登记制度及规 定评价复审的标准。 1.维护组织 机构中有一名维护管理员总负责,每项维护要 求都通过维护管理员转交给相应的系统管理员去评 价。系统管理员对维护任务做出评价之后,由变化 授权人决定应该进行的活动,最后由系统管理员去 执行维护任务。
软件工程 张海藩 课后习题答案

《软件工程导论》课后习题答案第一章软件工程概论1.什么是软件危机?软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
这些问题表现在以下几个方面:(1)用户对开发出的软件很难满意。
(2)软件产品的质量往往靠不住。
(3)一般软件很难维护。
(4)软件生产效率很低。
(5)软件开发成本越来越大。
(6)软件成本与开发进度难以估计。
(7)软件技术的发展远远满足不了计算机应用的普及与深入的需要。
2.为什么会产生软件危机?(1) 开发人员方面,对软件产品缺乏正确认识,没有真正理解软件产品是一个完整的配置组成。
造成开发中制定计划盲目、编程草率,不考虑维护工作的必要性。
(2) 软件本身方面,对于计算机系统来说,软件是逻辑部件,软件开发过程没有统一的、公认的方法论和规范指导,造成软件维护困难。
(3) 尤其是随着软件规模越来越大,复杂程度越来越高,原有软件开发方式效率不高、质量不能保证、成本过高、研制周期不易估计、维护困难等一系列问题更为突出,技术的发展已经远远不能适应社会需求。
3.怎样克服软件危机?(1) 充分吸收和借鉴人类长期以来从事各种工程项目中积累的行之有效的有效原理、概念、技术与方法,特别是吸取几十年来人类从事计算机硬件研究和开发的经验教训。
在开发软件的过程中努力作到良好的组织,严格的管理,相互友好的协作。
(2) 推广在实践中总结出来的开发软件的成功的技术和方法,并研究更好、更有效的技术和方法,尽快克服在计算机系统早期发展阶段形成的一些错误概念和作法。
(3) 根据不同的应用领域,开发更好的软件工具并使用这些工具。
将软件开发各个阶段使用的软件工具集合成一个整体,形成一个很好的软件开发支环环境。
总之为了解决软件危机,既要有技术措施(方法和工具),又要有必要的组织管理措施。
4.构成软件项目的最终产品:应用程序、系统程序、面向用户的文档资料和面向开发者的文档资料。
5.什么是软件生存周期?软件生存周期是指从软件定义、开发、使用、维护到淘汰的全过程。
软件工程导论[第六版]课后习题答案解析
![软件工程导论[第六版]课后习题答案解析](https://img.taocdn.com/s3/m/e26e9289f121dd36a32d8285.png)
第一章一、什么是软件危机?它有哪些典型表现?为什么会出现软件危机?软件危机是指在计算机软件开发、使用与维护过程中遇到的一系列严重问题和难题。
它包括两方面:如何开发软件,已满足对软件日益增长的需求;如何维护数量不断增长的已有软件。
软件危机的典型表现:(1) 对软件开发成本和进度的估计常常很不准确。
常常出现实际成本比估算成本高出一个数量级、实际进度比计划进度拖延几个月甚至几年的现象。
而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量。
这些都降低了开发商的信誉,引起用户不满。
(2) 用户对已完成的软件不满意的现象时有发生。
(3) 软件产品的质量往往是靠不住的。
(4) 软件常常是不可维护的。
(5) 软件通常没有适当的文档资料。
文档资料不全或不合格,必将给软件开发和维护工作带来许多难以想象的困难和难以解决的问题。
(6) 软件成本、软件维护费在计算机系统总成本中所占比例逐年上升。
(7) 开发生产率提高的速度远跟不上计算机应用普及的需求。
软件危机出现的原因:(1) 来自软件自身的特点:是逻辑部件,缺乏可见性;规模庞大、复杂,修改、维护困难。
(2) 软件开发与维护的方法不当:忽视需求分析;认为软件开发等于程序编写;轻视软件维护。
(3) 供求矛盾将是一个永恒的主题:面对日益增长的软件需求,人们显得力不从心。
二、假设自己是一家软件公司的总工程师,当把图1.1给手下的软件工程师们观看,告诉他们及时发现并改正错误的重要性时,有人不同意这个观点,认为要求在错误进入软件之前就清楚它们是不现实的,并举例说:“如果一个故障是编码错误造成的,那么,一个人怎么能在设计阶段清除它呢?”应该怎么反驳他?答:在软件开发的不同阶段进行修改付出的代价是很不相同的,在早期引入变动,涉及的面较少,因而代价也比较低;在开发的中期,软件配置的许多成分已经完成,引入一个变动要对所有已完成的配置成分都做相应的修改,不仅工作量大,而且逻辑上也更复杂,因此付出的代价剧增;在软件“已经完成”是在引入变动,当然付出的代价更高。
软件工程导论教学大纲-章程

《软件工程导论》教学大纲安徽大学计算机科学与技术学院2017 年 3 月《软件工程导论》教学大纲课程编号:ZJ36047课程名称:软件工程导论英文名称:Introduction to Software Engineering 学分/学时:2/34 课程性质:学科平台课程适用专业:软件工程先修课程:计算机导论开课单位:计算机科学与技术学院一、课程的教学目标与任务《软件工程导论》课程是软件工程专业高等教育的专业基础课程和学科平台课程,是“科研训练计划”教育课程。
《软件工程导论》以科学技术方法论为逻辑起点,结合部分管理方面的基本理论,讲授软件工程与方法论的联系,从而提高软件的质量和生产率。
本课程以软件工程专业本科二年级学生为讲授对象,是集理论性与应用性为一体的学科。
设置本课程的目的是:使学习者在全面了解软件工程发展历史、基本理论的基础上,系统掌握软件开发过程中的现代方法和管理手段,具备用工程化方法设计和构建规范软件的思想,从而为后续软件工程开发方法的系列课程奠定理论基础。
学习本课程的要求是:学习者应深刻认识软件危机产生的原因,纠正对软件开发的错误认识,掌握软件工程科学方法论的基本概念和基本原理,初步具备作为专业人员组织软件开发和设计工作的能力。
为检验掌握软件开发应遵循的原则和编写文档的基本方法的程度,最后的考核是通过考试进行,同时以加深对课程内容的理解。
二、课程具体内容及基本要求第一章软件工程的范畴 ( 2学时)基本内容包括:第一节历史方面一、定义软件(1)介绍软件的形式化定义。
结合经典教科书中关于软件的定义,介绍软件中所包含的三个要素:①指令的集合;②数据结构;③软件描述信息。
(2)阐述非形式化定义中软件具有的特性。
对比其他人工产品的特性,总结软件所具有的三个特性。
二、软件工程的发展历程和应用领域第二节经济方面结合例子阐述经济学原则在软件生产方面的重要性。
第三节维护性方面介绍软件生命周期模型和步骤,阐述维护工作在生命周期模型中的重要性和具体分类。
软件工程导论_第八章

• 完善性维护 利用前两类维护中列举的方法,也可以 减少这一类维护。特别是数据库管理系 统、程序生成器、应用软件包,可减少 维护工作量。 此外,建立软件系统的原型,把它在实 际系统开发之前提供给用户。用户通过 研究原型,进一步完善他们的功能要求, 就可以减少以后完善性维护的需要。
二、在不断增加 的,1970年占35%~40%;1980年上升到40%~ 60%。1990年上升到70%~80%。 由于大量软件的维护活动要使用较多的硬件、 软件、软件工程师等资源,使开发新的软件资源 不足而受到影响。由于维护时的改动,在软件中 引入了潜在的故障,从而降低了软件的质量。
(4) 在重新确认过程中,需邀请用 户参加。 • 维护后的验收──在交付新软件之 前,维护主管部门要检验: (1) 全部文档是否完备,并已更新; (2) 所有测试用例和测试结果已经 正确记载; (3) 记录软件配置所有副本的工作 已经完成; (4) 维护工序和责任已经确定。
适应性维护活动要占整个维护活动的25%。
3、 完善性维护
在软件漫长的运行时期中,用户往往会对软件 提出新的功能要求与性能要求,这是因为用户的 业务会发生变化,组织机构也会发生变化,为了 适应这些变化,应用软件原来的功能和性能需要 扩充和增强。例:原系统内没有帮助信息,使用 不方便,现在要加帮助信息,这种维护活动称为 完善性维护, 这种维护工作活动数量较大,占整个维护活动 50%。
开发与维护人员不是一个人或一个组织,由于 维护阶段持续时间很长,正在运行维护的软件可 能是五年前,十年前开发的,当时的开发工具、 方法、技术与当年的工具、方法、技术差异很大, 这又是维护困难的另一因素。
4、 软件维护不是一项吸引人的工作。
由于维护工作的困难性,维护工作经常遭受挫 折,而且很难出成果,不像软件开发工作那样吸 引人。
软件工程导论(第8章)

2. 文档重构;
(1)如果一个程序走向生命终点,不再经历变化,则保 持现状;(2)重构只针对当前正在修改的软件部分。
3. 逆向工程;
逆向工程是一个恢复设计结果的过程,从程序代码中抽
取数据结构、体系结构和处理过程的设计信息。
4. 代码重构;
分析源代码,标注出与结构化程序设计概念不符的 部分,重构它的代码,测试重构代码并更新代码。
2. 软件维护工作量模型
软件维护所花费的工作量,一部分用于生产
性活动,如分析、评价、修改设计、编写程序
等;另一部分用于非生产性活动,如理解代码
的含义、解释数据结构和接口特点等。
Belady和Lehman提出了一种维护工作量模型:
M=P+Ke(c-d)
其中: M:用于维护工作的总工作量; P:生产性工作量;
5. 数据重构;
当数据结构较差时,进行再工程。如以文件方式保存
数据变为以数据库方式存储。
活动以线性顺 序发生,但并非 总是这样。 对于任意一个 特定循环,可在 完成任意一个活 动后终止。
代码 重构
逆向 工程
该模型定义的6类活动: 1. 库存目录分析;
包含每个应用系统的信息,如:名称、构建日期、修改 次数、过去18个月报告的错误、用户数量、文档质量、预期 寿命,等。从中选出再工程的候选者。
13)软件工程师的名字; 15)维护类型; 14)维护要求表的标识; 16)维护开始和完成的日期;
17)累计用于维. 评价维护活动
可以从以下方面度量维护工作:
1)每次程序运行平均失效的次数;
2)用于每一类维护活动的总人时数; 3)平均每个程序、每种维护类型所做的程序变动数; 4)维护过程中增加或删除一个源语句平均花费的人时数; 5)维护每种语言平均花费的人时数;
计算机导论-第8章 软件工程

10
8.1.2 软件生命周期
5.软件测试
在软件分析、设计和程序编写过程中,难免有各种各样的错误,需要通过测试来查找 和修改,以保证软件的质量。其主要工作如下。
(1)单元测试 查找各模块在功能和结构上存在的问题并加以纠正。 (2)集成测试 将已测试通过的模块按照一定顺序组装起来进行测试。 (3)有效性测试 按照规定的各项需求,逐项进行测试,判断已开发的软件是否合格,能否交付用户使 用。
21
8.1.3 软件开发模型
4.螺旋模型
螺旋模型的思想是:使用原型 及其他方法来尽可能地降低风险。 它在软件开发的每个阶段,都增加 了一个风险分析过程。螺旋模型结 合了快速原型模型的迭代性质和瀑 布模型的系统性和可控性特点,适 用于大型软件的开发。螺旋模型由 4部分组成:制定计划、风险分析、 实施开发、客户评估,如图8-5所 示。在笛卡尔坐标的4个象限上分 别表达了4个方面的活动。
特别地,从经济学的意义上来说,考虑到软件庞大的维护费用远比软件开发费用要 高,因而开发软件不能只考虑开发期间的费用,而应考虑软件生命周期内的全部费用。 因此,软件生命周期的概念就变得特别重要。
6
8.1.2 软件生命周期
同任何事物一样,软件也有一个孕育、诞生、成长、成熟、衰亡的生存过程。软件生 命周期是指一个计算机软件从功能确定、设计,到开发成功投入使用,并在使用中不断地 修改、增补和完善,直到停止使用该软件的全过程。
软件工程导论张海潘(第六版)第1-13章总结 PPT课件

+
[ ]
{ }
( )
意思是等价于(或定义为);
+
意思是和(即,连接两个分量);
[ ]意思是或(即,从方括弧内列出的若干个分量中选择一 个),通常用“|”号隔开供选择的分量; { } 意思是重复(即,重复花括弧内的分量);常常使用上限 和下限进一步注释表示重复的花括弧。 ( ) 意思是可选(即,圆括弧里的分量可有可无)。
从下述3个方面研究每种解法的可行性:
1)技术可行性 2)经济可行性 3)操作可行性 其他方面:运行可行性、法律可行性
2、典型的可行性研究有下述一些步骤:
1.复查系统规模和目标。
3.导出新系统的高层逻辑模型 5.导出和评价供选择的解法 7.草拟开发计划
2.研究目前正在使用的系统
4.进一步定义问题 6.推荐行动方针 8.书写文档提交审查。
(1)建立数据模型——E-R图 (2)描绘数据结构——层次方框图和Warnier图 (3)数据结构规范化
32
第三章
4、需求分析过程建立三种模型
数据模型:实体-联系图
需求分析
功能模型:数据流图
行为模型:状态转换图
数据字典是分析模型的核心
5、实体-联系图 数据模型中包含3种相互关联的信息:数据对象、数据 对象的属性、数据对象彼此间相互连接的关系。 联系可分为以下三种类型:一对一,一对多和多对
外地号码=数字零+3位数字+8位数字 非零数字=[1|2|3|4|5|6|7|8|9]
a)拨校外电话需先拨0, 若是本市电话则再接着拨8位 数 字(第1位不是0); b)若是外地电话则拨3位区 码再拨8位电话号码(第1位不 是0)。
数字零=0
软件工程导论习题及第8章讲义

别人写的程序在没有说明文档时 理解很困难,不为人喜欢; 别人写的程序在没有说明文档时,理解很困难,不为人喜欢; 说明文档 维护持续时间都很长,开发人员一般不在现场, 维护持续时间都很长,开发人员一般不在现场,对软件没有人说 持续时间都很长 明。 绝大多数软件在设计时都没有考虑将来的修改 将来的修改。 绝大多数软件在设计时都没有考虑将来的修改。除非设计中强调 了模块的独立性,否则软件的修改既困难又易发生差错。 了模块的独立性,否则软件的修改既困难又易发生差错。
8.2 维护的特点
二.与软件维护有关的问题 与软件维护有关的问题
开发方法 开发条件 (1)模块化详细设计文档有助于理解软 软件开发及维护人员的水平 人员的水平; (1)模块化详细设计文档有助于理解软 软件开发及维护人员的水平; 件的结构 界面功能和内部流程; 结构、 影响 件的结构、界面功能和内部流程; 程序设计语言; 使用标准的程序设计语言 使用标准的程序设计语言; 维护 (2)开发过程中严格而科学的管理规划 使用标准的操作系统接口 操作系统接口; (2)开发过程中严格而科学的管理规划 使用标准的操作系统接口; 因素 及清晰可靠的文档资料对发生错误后的 使用规范化的文档资料 文档资料; 使用规范化的文档资料; 理解与纠错无疑是很重要的 无疑是很重要的。 理解与纠错无疑是很重要的。 (3)模块的独立程度对软件修改的难易 (3)模块的独立程度对软件修改的难易 模块的独立程度 程度、 程度、改进和移植影响是很大的 理解 维护 时间 困难 设计 问题 测试用例的有效性。 测试用例的有效性。
15
内容
第八章小结
一.软件维护是软件生存周期的最后一个阶段,也是持续时间 软件维护是软件生存周期的最后一个阶段,也是持续时间 最长、代价最大的一个阶段。 最长、代价最大的一个阶段。 的一个阶段 二.软件维护包括四类活动:改正性维护、适应性维护、完善 软件维护包括四类活动:改正性维护、适应性维护、 性维护和预防性维护。 性维护和预防性维护。 三.软件的可理解性、可测试性和可维修性是决定软件可维护 软件的可理解性、可测试性和可维修性是决定软件可维护 可理解性 性的基本因素。 性的基本因素。 四.软件生存周期的每个阶段和软件可维护性密切相关。 软件生存周期的每个阶段和软件可维护性密切相关。 五.文档是影响软件可维护性的决定因素。 文档是影响软件可维护性的决定因素。 是影响软件可维护性的决定因素 用户文档和系统文档, 六.文档分为用户文档和系统文档,它们都必须和程序代码同 文档分为用户文档和系统文档 时维护才有真正的价值。 时维护才有真正的价值。
软件工程导论第八章-软件质量与质量保证

8.7 结构化程序的测试 8.7.5 软件测试技术
1. 静态分析技术 (3)符号执行是一种符号化定义数据,并
为程序每条路径给出符号表达式,对 特定路径输入符号,经处理输出符号, 从而判断程序行为是否错误,达到分 析错误的目的。
8.7 结构化程序的测试
8.7.1 软件测试的目的 8.7.2 软件测试的原则 8.7.3 软件测试的对象 8.7.4 软件测试的基本过程
8.7 结构化程序的测试 8.7.1 软件测试的目的
1. 软件测试的目的 (1)软件测试是确认软件的质量,其
一方面是确认软件做了所期望的事 情,另一方面是确认软件以正确的 方式来做了这个事件。 (2)软件测试是提供信息,比如提供 给开发人员或项目经理的反馈信息, 为风险评估所准备的信息。
8.6 软件质量保证的标准
2.ISO 9001标准 (8)产品标识和可跟踪性 (9)过程控制 (10)审查和测试 (11)审查、度量和测试设备的控制 (12)审查和测试状态 (13)对不符合标准产品的控制 (14)改正和预防行动
8.6 软件质量保证的标准
2.ISO 9001标准 (15)处理、存储、包装、保存和交付 (16)质量记录的控制 (17)内部质量审计 (18)培训 (19)服务 (20)统计技术
测试过程中产生的基本文档如下: (1)测试计划: 通常包括单元测试和集成测试,
确定测试范围、方法和需要的资源等。 (2)测试过程: 详细描述和每个测试方案有关
的测试步骤和数据,包括测试数据及预期 的结果。 (3)测试结果: 把每次测试运行的结果归入文 档,如果运行出错,则应产生问题报告, 并且通过调试解决所发现的问题。
软件工程导论_08

能最终确定类中应有的服务,因为这两个模型更明 状态图中发往对象的事件也就是该对 类中定义的每个属性都是可以 象接收到的消息,因此该对象必须有 确地描述了每个类应该提供哪些服务。 利用继承机制以减少所需定义 访问的,则可在每个类中定义 由消息选择符指定的操作,这个操作 的服务数目。 读、写该类每个属性的操作。 定义服务的方法: 修改对象状态(即属性值)并启动相 数据流图中的每个处理框都
通常,事件使对象从一个状态转向另一个状态。
动态模型
通常,使用UML提供的状态图来描绘对象的状态、
触发状态转换的事件以及对象的行为(对事件的响 状态图是对类图的补充。 应)。
状态图通过建立对象的生命周期模型来描述对象随时 每个类的动态行为用一张状态图 间变化的动态行为。 来描绘,各个类的状态图通过共 享事件合并起来,从而构成系统 并不是对所有的对象都创建状态图,只有当行为的改 的动态模型。 变和状态有关时才创建状态图。 动态模型是基于事件共享而互 状态图适合于描述跨越多个用例的单个对象的行为, 相关联的一组状态图的集合。 而不适合描述多个对象之间的行为协作。 所以,与用例图和类图不同,状态图只能对单个对象 建立模型,而类图和用例图可以对一个系统或一组类 建立模型。
状态图
练习2:在温室管理系统中,有一个环境控制器类, 当没有种植作物时处于空闲状态。一旦种上了作 物,就要进行温度控制,定义气候,即在什么时 期应达到什么温度。当处于夜晚时,由于温度下 降,要调用调节温度过程,以便保持温度;太阳 出来时,进入白天状态,由于温度升高,要调用 调节温度过程,保持要求的温度。当日落时,进 入夜晚状态。当作物收获,终止气候的控制,则 进入空闲状态。建立环境控制器类的状态图。
对象的状态:是指在对象的生命周期中满足某些条
软件工程导论(第6版)

第一章、软件工程学概述软件危机:是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
软件危机包含下述两个方面的问题:1.如何开发软件,以满足对软件日益增长的需求。
2.如何维护数量不断膨胀的已有软件。
具体的说,软件危机主要有以下一些典型表现:1.对软件开发成本的进度的估计常常很不准确。
2.用户对“已完成的”软件系统不满意的现象经常发生3.软件产品的质量往往靠不住。
4.软件常常是不可维护的。
5.软件通常没有适当的文档材料。
6.软件成本在计算机系统总成本中所占的比例逐年上升。
7.软件开发生产率提高的速度,远远跟不上计算机应用迅速普及深入的趋势。
软件生命周期:一个软件从定义、开发、使用和维护,知道最终被废弃,要经历一个漫长的时期,通常把软件经历的这个漫长的时期称为生命周期。
软件配置:程序、文档和数据。
软件工程学的一个重要的目标:就是提高软件的可维护性,减少软件维护的代价。
软件:是程序、数据及相关文档的集合。
程序:是能够完成预定功能和性能的可执行的指令序列。
数据:是使程序能够适当地处理信息的数据结构。
文档:是开发、使用和维护程序所需要的图文资料。
软件工程:指导计算机软件开发和维护的一门工程学科。
软件工程具有下属的本质特性:1.软件工程关注于大型程序的构造。
2.软件工程的中心课题是控制复杂性。
3.软件经常变化。
4.开发软件的效率非常重要。
5.和谐地合作是开发软件的关键。
6.软件必须有效地支持它的用户。
7.在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产品。
软件工程的7条基本原理:1.用分阶段的生命周期计划严格管理。
2.坚持进行阶段评审。
3.实行严格的产品控制4.采用现代程序设计技术。
5.结构应能清楚的审查。
6.开发小组的人员应该少而精。
7.承认不断改进软件工程实践的必要性。
软件工程:包括技术和管理两方面的内容,是技术与管理紧密结合所形成的工程学科。
通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学,也称为泛型。
软件工程导论第8章

配臵
代码 评价代码 ? 重编程序
非结构 化维护
复查
结构化维护与非结构化维护比较示意图
5
1. 非结构化维护 如果软件配臵的惟一成分是程序代码,那么维护活动从艰苦地评价程序代码开始,而且 常常由于程序内部文档不足而使评价更困难,对于软件结构、全程数据结构、系统接口、性 能和(或)设计约束等经常会产生误解,而且对程序代码所做的改动的后果也是难于估量的: 因为没有测试方面的文档,所以不可能进行回归测试(即指为了保证所做的修改没有在以前 可以正常使用的软件功能中引入错误而重复过去做过的测试)。非结构化维护需要付出很大 代价(浪费精力并且遭受挫折的打击),这种维护方式是没有使用良好定义的方法学开发出来 的软件的必然结果。 2. 结构化维护 如果有一个完整的软件配臵存在,那么维护工作从评价设计文档开始,确定软件重要的 结构特点、性能特点以及接口特点;估量要求的改动将带来的影响,并且计划实施途径。然 后首先修改设计并且对所做的修改进行仔细复查。接下来编写相应的源程序代码;使用在测 试说明书中包含的信息进行回归测试;最后,把修改后的软件再次交付使用。
19
4. 保存维护记录 对于软件生命周期的所有阶段而言,以前记录保存都是不充分的,而 软件维护则根本没有记录保存下来。由于这个原因,往往不能估价维护技 术的有效性,不能确定一个产品程序的“优良”程度,而且很难确定维护 的实际代价是什么。 保存维护记录遇到的第一个问题就是,哪些数据是值得记录 的?Swanson提出了下述内容: ①程序标识; ②源语句数; ③机器指令条 数; ④使用的程序设计语言; ⑤程序安装的日期; ⑥自从安装以来程序 运行的次数; ⑦自从安装以来程序失效的次数; ⑧程序变动的层次和标 识; ⑨因程序变动而增加的源语句数; 因程序变动而删除的源语句数; 每个改动耗费的人时数; 程序改动的日期; 软件工程师的名字; 维护要 求表的标识; 维护类型; 维护开始和完成的日期; 累计用于维护的人时 数; 与完成的维护相联系的纯效益。 应该为每项维护工作都收集上述数据。可以利用这些数据构成一个维 护数据库的基础,并且像下面介绍的那样对它们进行评价。
软件工程导论(第六版)张海藩课后习题答案(1-8章)

第一章1-1 什么是软件危机?是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
1-3 什么是软件工程?是指导计算机软件开发和维护的一门工程学科。
1-4 简述结构化范型和面向对象范型的要点,并分析它们的优缺点。
目前使用得最广泛的软件工程方法学(2种):1. 传统方法学:也称为生命周期方法学或结构化范型。
优点:把软件生命周期划分成基干个阶段,每个阶段的任务相对独立,而且比较简单,便于不同人员分工协作,从而降低了整个软件开发过程的困难程度。
缺点:当软件规模庞大时,或者对软件的需求是模糊的或会承受时间而变化的时候,开发出的软件往往不成功;而且维护起来仍然很困难。
2. 面向对象方法学:优点:降低了软件产品的复杂性;提高了软件的可理解性;简化了软件的开发和维护工作;促进了软件重用。
1-6 什么是软件过程?它与软件工程方法学有何关系?z 软件过程:是为了获得高质量软件所需要完成的一系列任务的框架,它规定了完成各项任务的工作步骤z 软件工程方法学:通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学,也称范型1-7 什么是软件生命周期模型,试比较瀑布模型,快速原型模型,增量模型,和螺旋模型的优缺点,说明每种模型的适用范围。
软件生命周期由软件定义、软件开发和运行维护3个时期组成,每个时期又进一步划分成若干个阶段。
生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序,因此,也称为过程模型。
瀑布模型的优点:1.可强迫开发人员采用规范的方法;2.严格规定了每个阶段必须提交的文档;3.要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
瀑布模型的缺点:1.在软件开发初期,指明用户全部需求是困难的;2.需求确定后,经过一段时间才得到软件最初版本;3.完全依赖规格说明,导致不能满足用户需求。
适用中小型项目。
快速原型模型的优点:1满足用户需求程度高;2用户的参与面广;3返工现象少快速原型模型的优点:不适用大型软件的开发适用于小型项目。
(NEW)张海藩《软件工程导论》(第6版)配套题库【名校考研真题+课后习题+章节题库+模拟试题】

一、选择题
1.软件工程是采用( )的概念、原理、技术方法指导计算机 程序设计的工程学科。[中国传媒大学2014研]
A.工程 B.系统工程 C.体系结构 D.结构化设计 【答案】A 【解析】软件工程是采用工程的概念、原理、技术和方法来开发与 维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最 好的技术方法结合起来,从而经济地开发出高质量的软件,并且进行有 效地维护。 2.随着开发小组人数的( ),因交流开发进展情况和讨论遇 到的问题而造成的通信开销也急剧增加。[中国传媒大学2014研] A.增加 B.降低 C.稳定 D.不稳定 【答案】A 【解析】当开发小组变得更大时,即开发小组人数增加时,每个人 需要用更多时间与组内其他成员讨论问题、协调工作,因此,通信开销
12.为了解决软件危机,人们提出了用( )的原理来设计软 件。[中国传媒大学2013研]
A.运筹学 B.工程学 C.软件学 D.数学 【答案】B
【解析】为了解决软件危机,通过采用软件工程来指导软件的设 计。软件工程是采用工程的概念、原理、技术和方法来开发与维护软 件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技 术方法结合起来,以经济地开发出高质量的软件并有效地维护。
16.结构化维护与非结构化维护的主要区别在于( )。[中国 传媒大学2013研]
A.软件是否结构化 B.软件配置是否完整 C.程序的完整性 D.文档的完整性
【答案】B 【解析】非结构化维护需要付出很大代价,这种维护方式是没有使 用良好定义的方法学开发出来的软件的必然结果;结构化维护是在软件 开发的早期应用软件工程方法学的结果。因此,结构化维护与非结构化 维护的主要区别是软件配置的完整性,有了软件的完整配置能减少精力 的浪费并且能提高维护的总体质量。 17.下面是被测模块的流程图。测试数据为:A=1,B=0,X=3; A=2,B=1,X=1。判断符合如下哪个等级的逻辑覆盖:( )。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
8.3 软件维护过程
2.维护报告 维护申请表(Maintenance Request Form,MRF)或称软 件问题报告(Software Problem Report, SPR),由申请 维护的用户填写 用户必须完整地说明产生错误的情况,包括输入数据、错误 清单以及其它有关材料 如果申请的是适应性维护或完善性维护,用户必须提出一份 修改说明书,列出所有希望的修改 维护申请报告将由维护管理员和系统监督员来研究处理 他们应相应地做出软件修改报告,并指明: – 所需修改变动的性质 – 申请修改的优先级 – 为满足某个维护申请报告,所需的工作量 – 预计修改后的状况.软件修改报告应提交修改负责人,经 批准后才能开始进一步安排维护工作
2013-7-4
liang@
20
软件维护策略—完善性维护
利用前两类维护中列举的方法,也可以减
少这一类维护
– 特别是数据库管理系统、程序生成器、应用软 件包,可减少维护工作量
此外,建立软件系统的原型,把它在实际
系统开发之前提供给用户
– 用户通过研究原型,进一步完善他们的功能要 求,就可以减少以后完善性维护的需要
2013-7-4
liang@
8.1 软件维护的定义
维护绝不仅限于纠正使用中发现的错误。
– 完善性维护:50-66% – 改正性维护:17-21%
– 适应性维护:18-25%
– 其他维护:4%
上述4类维护活动都必须应用于整个软件配置,维 护软件文档和维护软件的可执行代码同样重要。
liang@ 25
2013-7-4
8.3 软件维护过程
3.维护的事件流
2013-7-4
liang@
26
8.3 软件维护过程
不管维护的类型如何,都需要进行同样的技术工作。这些 工作包括修改软件设计、复查、必要的代码修改、单元和 集成测试(包括回归测试)、验收测试和复审。 当恶性软件问题发生时,必须立即解决,这就是所谓的 “救火”维护要求。 在完成软件维护任务之后,进行处境复查
2013-7-4
liang@
6
适应性维护(Adaptive
Maintenance)
在使用过程中,使用坏境可能发生变化
– 外部环境(新的硬、软件配置) – 数据环境(数据库、数据格式、数据输 入/输出方式、数据存储介质) 为使软件适应这种变化,而去修改软件的 过程就叫做适应性维护
2013-7-4
liang@
3
第8章 维护(Maintenance)
8.1 软件维护的定义 8.2 软件维护的特点 8.3 软件维护过程 8.4 软件的可维护性 8.5 预防性维护 8.6 软件再工程过程 8.7 小结
2013-7-4 liang@ 4
M是维护中消耗的总工作量 p是上面描述的生产性工作量 K是一个经验常数 c是因缺乏好的设计和文档而导致复杂性的度量 d是对软件熟悉程度的度量 该模型指明,如果使用了不好的软件开发方法(未按软件工程要求 做),原来参加开发的人员或小组不能参加维护,则工作量(及成本) 将按指数级增加
liang@ 15
liang@ 17
2013-7-4
影响维护工作的因素 (2)
数据库技术的应用:使用数据库,可以简单而有 效地管理和存储用户程序中的数据,还可以减少 生成用户报表应用软件的维护工作量 先进的软件开发技术:在软件开发时,若使用能 使软件结构比较稳定的分析与设计技术,及程序 设计技术,如面向对象技术、复用技术等,可减 少大量的工作量 其它因素: – 应用的类型 – 数学模型 – 任务的难度 – 开关与标记、IF嵌套深度、索引或下标数等
– 维护费用稳步上升
1970年,35%-40% 1980年,40%-60% 1990年,70%-80%
– 必须占用可用资源 – 不能及时修改,引起用户不满
– 引入潜伏错误,降低软件质量
– 开发人员作为维护人员,使得开发过程混乱 – 生产率大幅度下降
美国空军飞行控制软件:$75(开发)$4000(维护)
软件工程导论
梁文新
办公室:综合楼108 电 话: 87571625 liang@
软件的生命周期
问题定义
可行性分析
软件 定义
What? How?
需求分析 总体设计 详细设计 编码 软件 开发
Implementation
测试 运行维护
liang@
运行 维护
2013-7-4
liang@
21
8.3 软件维护过程
维护过程本质上是修改和压缩了的软件定义和开发 过程,为了有效地进行软件维护,应事先就开始做 组织工作
– – – – 首先建立维护的机构 确定提出维护申请报告的过程及评价的过程 为每一个维护申请规定标准的处理步骤 建立维护活动的登记制度以及规定评价和评审的标准
2013-7-4 liang@ 16
影响维护工作的因素(1)
系统大小:系统越大,理解掌握起来越困难。系统越大, 所执行功能越复杂。因而需要更多的维护工作量 程序设计语言:使用强功能的程序设计语言可以控制程序 的规模。语言的功能越强,生成程序的模块化和结构化程 度越高,所需的指令数就越少,程序的可读性越好 系统年龄: – 老系统随着不断的修改,结构越来越乱 – 维护人员经常更换,程序又变得越来越难于理解 – 许多老系统在当初并未按照软件工程的要求进行开发, 因而没有文档,或文档太少 – 在长期的维护过程中文档在许多地方与程序实现变得 不一致,在维护时就会遇到很大困难
– 非结构化维护需要付出很大的代价,这种维护方 式是没有使用良好定义的方法学开发出来的软件 的必然结果
2013-7-4 liang@ 11
8.2 软件维护的特点
2.结构化维护
如果有一个完整的软件配置存在,那么维护工作从 评价软件设计文档开始 – 确定软件重要的结构特点、性能特点以及接口特 点; – 估量要求的改动将带来的影响; 然后首先修改设计并且对所做的修改进行仔细复查; 接下来修改程序源码; 然后根据测试说明书进行回归测试; 交付修改后的软件。
2013-7-4 liang@ 18
软件维护策略—改正性维护
通常要生成100%可靠的软件并不一定合算,
成本太高 但通过使用新技术,可大大减少进行改正 性维护的需要 这些技术包括
– 数据库管理系统 – 软件开发环境 – 程序自动生成系统 – 较高级(第四代)的语言 – 以及新的开发方法、软件复用、防错程序设计 及周期性维护审查等
2013-7-4
liang@
10
8.2 软件维护的特点
8.2.1 结构化维护与非结构化维护差别巨大 1.非结构化维护
– 如果软件配置的唯一成分是程序代码,那么维护 活动将因文档不足而非常艰难。
对于软件结构、全程数据结构、系统接口、性能和
(或)设计约束容易产生误解 对程序代码所做改动的后果也难于估量(无测试文档, 不能进行回归测试)
2013-7-4
liang@
8
预防性维护(Preventative
Maintenance)
预防性维护是为了提高软件将来的可
维护性、可靠性等,为将来进一步改 进软件打下良好基础 预防性维护定义为:采用先进的软件 工程方法对需要维护的软件或软件中 的某一部分(重新)进行设计、编制 和测试
2013-7-4
liang@
12
维护请求 软件 配置 理解设计 代码 理解代码功能
方案规划 理解 ?
修改设计 修改代码 测试复审 修改代码
测试复审
结构化维护
2013-7-4
交付使用
liang@
非结构化维护
13
8.2 软件维护的特点
8.2.2 维护的代价高昂
2013-7-4 liang@ 14
8.2 软件维护的特点
– 用于维护工作的劳动
生产性活动(分析评价,修改设计,编写程序代码)
非生产性活动(理解程序代码的功能,解释数据结构、接口
特点和性能限度等)
– 维护工作量模型:
– – – – – –
M p Ke
c d
2013-7-4 liang@ 24
8.3 软件维护过程
维护申请提交给维护 管理员,他把申请交 给某个系统监督员去 评价 一旦做出评价,由修 改负责人确定如何进 行修改 在修改程序的过程中, 由配置管理员严格把 关,控制修改的范围, 对软件配置进行审计 在维护之前,就把责 任明确下来,可以减 少维护过程中的混乱
2013-7-4
liang@
7
完善性维护(Perfective/Evolutive
Maintenance)
在软件的使用过程中,用户往往会对软件
提出新的功能与性能要求 为了满足这些要求,需要修改或再开发软 件,以扩充软件功能、增强软件性能、改 进加工效率、提高软件的可维护性 这种情况下进行的维护活动叫做完善性维 护
维护分类
– 改正性维护(Corrective Maintenance)
– 适应性维护(Adaptive Maintenance)
– 完善性维护(Perfective/Evolutive Maintenance) – 预防性维护(Preventative Maintenance)
2013-7-4 liang@ 5
2
2013-7-4
概述
软件产品被开发出来并交付用户使用之后,就进入了软件的运 行维护阶段。 软件生命周期的最后一个阶段,其基本任务是保证软件在一个 相当长的时期能够正常运行。 维护成本占重成本的40-90%。