第13章软件维护与再工程
软件维护

—— 亦称 Software Evolution
1.软件维护的概念 2.维护的特点 3.维护的过程 4.可维护性 5.软件再工程过程
2018年7月2日星期一
计算机科学与工程学院
1
6.8.软件系统维护的基本概念
1.软件维护定义:
是指在软件系统已经交付使用之后,软件使用人员为了 适应新的要求、满足新的需要或为了改正软件中存在的错误 而对软件系统进行修改的过程。
2018年7月2日星期一 计算机科学与工程学院
8
维护工作量的经验模型:
M=P+K×exp(c-d) 其中: M是维护用的总工作量; P是生产性工作量; K是经验常数; c是复杂程度(非结构化设计和缺少文档都会增加软件 的复杂程度); d是维护人员对软件的熟悉程度。
上面的模型表明,如果软件的开发途径不好(即,没 有使用软件工程方法学),而且原来的开发人员不能参加 维护工作,那么维护工作量(和费用)将指数地增加。
2018年7月2日星期一 计算机科学与工程学院 17
⑴ 可理解性(Understandability) 指由文档代码理解功能运行的容易程度。对外又称 user friendliness. 好程序的特征:模块化、结构化、代码与设计风格一致, 高级语言实现。 度量方法:90 - 10 Test ——读源程序10分钟,能否默写 出90%? ⑵可测试性(Testability) 是指论证程序正确性的容易程度。 好程序的特征:可理解、可靠、简单。 度量方法:程序复杂度(第五章中已讨论)
文档:开发文档 和测试文档
缺乏文档 不能进行回归测试
原因:没有使用良好定义的方法学开发出来。 回归测试:为了保证所做的修改没有在以前可以正常使用的软件 功能中引入错误而重复过去做过的测试。
软件工程导论复习重点总结很全第六版

第1章软件工程学概述1.1 软件危机1.1.1 软件危机旳简介软件危机(软件萧条、软件困扰): 是指在计算机软件旳开发和维护过程中所碰到旳一系列严重问题。
软件危机包括下述两方面旳问题:怎样开发软件, 满足对软件日益增长旳需求;怎样维护数量不停膨胀旳已经有软件。
软件危机旳经典体现:(1)对软件开发成本和进度旳估计常常很不精确;(2)顾客对“已完毕旳”软件系统不满意旳现象常常发生;(3)软件产品旳质量往往靠不住;(4)软件常常是不可维护旳;(5)软件一般没有合适旳文档资料;(6)软件成本在计算机系统总成本中所占旳比例逐年上升;(7)软件开发生产率提高旳速度, 远远跟不上计算机应用迅速普及深入旳趋势。
1.1.2 产生软件危机旳原因(1)与软件自身旳特点有关(2)与软件开发与维护旳措施不对旳有关1.1.3 消除软件危机旳途径对计算机软件有对旳旳认识。
认识到软件开发是一种组织良好、管理严密、各类人员协同配合、共同完毕旳工程项目。
应当推广使用在实践中总结出来旳开发软件旳成功技术和措施, 并继续研究探索。
应当开发和使用更好旳软件工具。
总之, 为了处理软件危机, 既要有技术措施(措施和工具), 又要有必要旳组织管理措施。
1.21.2.1 软件工程旳简介软件工程: 是指导计算机软件开发和维护旳一门工程学科。
采用工程旳概念、原理、技术和措施来开发与维护软件, 把通过时间考验而证明对旳旳管理技术和目前可以得到旳最佳旳技术措施结合起来, 以经济地开发出高质量旳软件并有效地维护它, 这就是软件工程。
(期中考)软件工程旳本质特性:软件工程关注于大型程序旳构造软件工程旳中心课题是控制复杂性软件常常变化开发软件旳效率非常重要友好地合作是开发软件旳关键软件必须有效地支持它旳顾客在软件工程领域中是由具有一种文化背景旳人替具有另一种文化背景旳人发明产品1.2.2 软件工程旳基本原理用分阶段旳生命周期计划严格管理坚持进行阶段评审实行严格旳产品控制采用现代程序设计技术成果应能清晰地审查开发小组旳人员应当少而精承认不停改善软件工程实践旳必要性1.2.3 软件工程措施学软件工程包括技术和管理两方面旳内容。
软件维护与软件工程管理

14
1. 逆向工程
软件的逆向工程通过对程序的分析,导出更高抽象层次的 表示,如从现存的程序中抽取数据、体系结构、过程的设计信息 等,是一个设计恢复过程。
逆向工程过程所抽取的信息,一方面可以提供给软件工程 师以便在维护活动中使用这些信息;另一方面可以用来重构原来 的系统,使新系统更易维护。
15
2. 重构
因此,进行维护工作要相当谨慎。
5
13.1 软件维护
• 13.1.1 软件维护的过程 • 典型的软件维护的过程可以概括为:
• 建立维护机构 • 用户提出维护申请并提交维护申请报告 • 维护人员确认维护类型并实施相应的维护工作 • 整理维护记录并对维护工作进行评审 • 对维护工作进行评价
6
13.1 软件维护
基于经验模型
• IBM 模型、普特南模型、COCOMO模型
21
13.3 软件开发进度计划
• 项目管理者的目标是定义全部项目任务,识别出关键任 务,规定完成各项任务的起、止日期,跟踪关键任务的进 展状况,以保证能及时发现拖延进度的情况。为了做到这 一点,管理者必须制订一个足够详细的进度表,以便监督 项目进度,并控制整个项目。
软件维护与软件工程管理
本章概述
本章首先介绍软件维护的概念,包括软件部署与软件交付、软件维护的过程和分类、软件的可维护
性、软件维护的副作用、自动化运维以及软件再工程技术;然后阐述软件估算软件开发进度计划、软件
开发人员组织、软件开发风险管理、软件质量保证、软件配置管理.软件工程标准与软件文档、软件过
程能力成熟度模型和软件项目管理等相关概念。 本章目标:
• 人类通过编程语言与计算机进行交流,每种编程语言都有严格的语义和语法结构。编程
软件工程各章名词解释

名词解释一个三分 五个十五分第一章 绪论1. 软件2. 文档3. 软件工程4. 软件工程过程5. 软件生存周期6. 软件生存周期模型第二章 软件可行性研究与项目开发计划1. 投资回收2. 纯收人第三章 软件需求分析1. 需求分析2. 数据流3. 数据字典4. 加工5. 数据流图第四章 软件概要设计1. 模块2. 模块化3. 抽象4. 信息隐蔽5. 模块独立性6. 耦合性7. 无直接耦合8. 数据耦合9. 标记耦合10. 控制耦合11. 公共耦合12. 内容耦合13. 内聚性14. 偶然内聚15. 逻辑内聚16. 时间内聚17. 通信内聚18. 顺序内聚19. 功能内聚第五章 软件详细设计1. PAD2. 过程设计语言(PDL)第六章 软件编码1. 程序设计风格2. 程序可移植性第七章 软件测试1. 语句覆盖2. 判定覆盖3. 条件覆盖4. 判定/条件覆盖5. 条件组合覆盖6. 路径覆盖7. 环路复杂性8. 黑盒测试9. 白盒测试10. 驱动模块11. 桩模块12. 单元测试13. 集成测试14. 确认测试15. 调试第八章 软件维护1. 维护2. 校正性维护3. 适应性维护4. 完善性维护5. 预防性维护6. 软件可维护性第九章 软件开发的增量模型1. 原型第十章 面向对象的方法1. 对象2. 类3. 消息4. 方法5. 继承性6. 单重继承7. 多重继承8. 多态性9. 抽象10. 信息隐藏11. 链12. 关联第十一章 软件质量与质量保证1. 软件可靠性2. 效率3. 可维护性4. 可移植性5. 可互操作性6. 适应性7. 可重用性8. 软件设计质量9. 软件程序质量10. 冗余第十二章 软件工程管理1. 软件配置管理2. 软件配置项3. 基线4. 文档第十三章 软件开发环境1. 软件开发环境2. 软件工具3. CASE4. CASE生存期5. CASE工作台软件工程自考名词解释答案第一章 绪论1. 计算机程序及其说明程序的各种文档.2. 文档是有关计算机程序功能,设计,编制,使用的方案或图形资料.3. 用科学知识和技术原理来定义,开发,维护软件的一门学科.4. 软件工程过程规定了获取,供应,开发,操作和维护软件时,要实施的过程,活动和任务.5. 软件生存周期是指一个软件从得出开发要求开始直到该软件报废为止的整个时期.6. 软件生存周期模型是描述软件开发过程中各种活动如何执行的模型.第二章 软件可行性研究与项目开发计划1. 投资回收期就是使累计的经济效益等于最初的投资费用所需的时间.2. 在整个生存周期之内的累计经济效益(折合成现在值)与投资之差.第三章 软件需求分析1. 需求分析是指开发人员要准确理解用户的要求,进行细致的调查分析,将用户非不甘落后将用户非不甘落后 需求陈述转化为完整的需求定义,再由需求定义转换到相应的形式功能规约(需求规格说明)的过程.2. 数据流是数据在系统内传播的路径,因此由一组成分固定的数据项组成.3. 数据字典(Data Dic onary, 简称DD)就是用来定义数据流图中的各个成分的具体含义的,它以一种准确的,无二义性的说明方式为系统的分析,设计及维护提供了有关元素的一致的定义和详细的描述.4. 加工又称为数据处理,是对数据流进行某些操作或变换.5. 数据流图,简称DFD,是SA方法中用于表示系统逻辑模型的一种工具,它以图形的方式描绘数据在系统中流动和处理的过程.第四章 软件概要设计1. 模块在程序中是数据说明,可执行语句等程序对象的集合,或者是单独命名和编址的元素,在软件的体系结构中,模块是可组合,分解和更换的单元.2. 模块化是指解决一个复杂问题自顶向下逐层把软件系统划分成若干模块的过程.每个模块完成一个特定的子功能,所有的模块按某种方法组装起来,成为一个整体,完成整个要求的功能.3. 抽象是认识复杂现象过程中使用的思维工具,即抽出事物本质的共同的特性而暂不考虑它的细节,不考虑其他因素.4. 信息隐蔽指在设计和确定模块时,使得一个模块内包含信息(过程或数据),对于不需要这些信息的其他模块来说,是不能访问的.5. 模块独立性指每个模块只完成系统要求的独立的子功能,并且与其他模块的联系最少且接口简单.6. 耦合性也称块间联系.指软件系统结构中各模块间相互联系紧密程序的一种度量.7. 无直接耦合指两个模块之间没有直接的关系,它们分别从属于不同模块的控制与调用,它们之间不传递任何信息.8. 数据耦合指两个模块之间有调用关系,传递的是简单的数据值,相当于高级语言的值传递.9. 标记耦合指两个模块之间传递的是数据结构,如高级语言的数组名,记录名,文件名等这些名字即为标记,其实传递的是这个数据结构的地址.10. 控制耦合指一个模块调用另一个模块时,传递的是控制变量(如开关,标志等),被调模块通过该控制变量的值有选择地执行块内某一功能.11. 公共耦合指通过一个公共数据环境相互作用的那些模块间的耦合.公共数据环境可是是全程变量或数据结构,共享的通信,内存的公共覆盖区及任何存储介质上的文件,物理设备等(也有将共享外部设备分类为外部耦合).12. 当一个模块直接使用另一个模块的内部数据,或通过非正常口转入另一个模块内部,这种模块之间的耦合为内容耦合.13. 内聚块又称块内联系指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量.14. 偶然内聚指一个模块内的各处理元素之间没有任何联系.15. 逻辑内聚指模块内执行个逻辑上相似的功能,通过参数确定该模块完成哪一个功能.16. 把需要同时执行的动作组合在一起形成的模块为时间内聚模块.17. 通信内聚指模块内所有处理元素都在同一个数据结构上操作(有时称之为信息内聚),或者指各处理使用相同的输入数据或者产生相同的输出数据.18. 顺序内聚指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行,前一功能元素的输出就是下一功能元素的输入.19. 功能内聚指模块内所有元素共同完成一个功能,缺一不可.因此模块不能再分割.第五章 软件详细设计1. PAD图指问题分析图(Problem Analysis Diagram),是一咱算法描述工具,它是一种由左往右展开的二维树型结构.PAD图的控制流程为自上而下,从左到右地执行.2. 过程设计语言(Process Design Language,简称PDL),也称程序描述语言(Program Descrip on Language),又称为伪码.它是一种用于描述模块自法设计和处理细节的语言.第六章 软件编码1. 程序设计风格指一个人编制程序时所表现出来的特点,习惯逻辑思路等.2. 指程序从一个计算机环境移值到另一个计算机环境的容易程序.第七章 软件测试1. 语句覆盖是指设计足够的测试用例,使被测程序中每个语句至少执行一次.2. 判定覆盖指设计足够的测试用例,使得被测程序中每个判定表达式至少获得一次”真”和”假”值,从而使程序的每一个分支至少都通过一次.3. 条件覆盖指设计足够的测试用例,使得判定表达工中每个条件的各种可能的值出现一次.4. 判定/条件覆盖标准指设计足够的测试用例,使得判定表达式中的每个条件的所有可能取值至少出现一次,并使每个判定表达式所有可能的结果也至少出现一次.5. 条件组合覆盖是比较强的覆盖标准,它是指设计足够的测试用例,使得每个判定表达式中条件的各种可能的值的组合都至少出现一次.6. 路径覆盖是指设计足够的测试用例,覆盖被测程序中所有可能的路径.7. McCabe定义程序图的环路为程序图中区域的个数.区域个数为边和结点圈定的封闭区域数加上图形外的区域数1.8. 黑盒测试是功能测试又称为功能测试或数据驱动测试.9. 白盒测试是对程序中尽可能多和逻辑路径进行测试,检验内部控制结构和数据结构是否有错,实际的运行状态与预期的状态是否一致.10. 驱动模块是用来模拟被测模块的上级调用模块的模块,功能要比真正的上级模块简单得多,它只完成接受测试数据,以上级模块调用被测模块的格式驱动被模块,接收被测模块的测试结果并输出.11. 桩模块用来代替被测试模块所调用的模块它的作用是返回被测模块所需的信息.12. 单元测试指对源程序中每一个程序单元进行测试,检查各个模块是否正确实现规定的功能,从而发现模块在编码中或算法中的错误.13. 集成测试是指在单元测试的基础上,将所有模块按照设计要求组装成一个完整的系统进行测试,故也称组装测试或联合测试.14. 确认测试又称有效性测试.是为了检查软件的功能与性能是否与需求规格说明书中确定的指标相符合所进行的测试.15. 调试是为了确定错误的原因和位置,并改正错误所进行的工作,因此调试也称为纠错.第八章 软件维护1. 在软件运行/维护阶段对软件产品所进行的修改就是维护.2. 为了识别和纠正错误,修改软件性能上的缺陷,应进行确定和修改错误的过程,这个过程就称为校正性维护.3. 随着计算机的飞速发展,计算机硬件,软件及数据环境在不断发生变化,为了使应用软件适应这种变化而修改软件的过程称为适应性维护.4. 在犯罪分子件运行时期中,用户往往会对软件提出新的功能要求与性能要求.这种增加软件功能,增强软件性能,提高软件运行效率而进行的维护活动称为完善性维护.5. 为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护.6. 软件可维护性是指软件能够被理解,校正,适应及增强功能的容易程度.第九章 软件开发的增量模型1. 软件开发中的原型是软件的一个早期可运行的版本,它反映了最终系统的重要特性.第十章 面向对象的方法1. 对象是人们要进行研究的任何事物,从最简单的整数到复杂的飞机等均可看作对象,它不仅能表示具体的事物,还能表示抽象的规则,计划或事件.2. 具有相同或相似性质的对象的抽象就是类具有相同或相似性质的对象的抽象就是类3. 对象之间进行通信的构造叫做消息.4. 类中操作的实现过程叫做方法,一个方法有方法名,参数,方法体.5. 继承性是子类自动共享父类数据结构和方法的机制这是类之间的一种关系.6. 在类层次中,子类只继承一个父类的数据结构和方法,称为单重继承.7. 在类层次中,子类继承了多个父亲的数据结构和方法,称为多重继承.8. 多态性是指相同的操作或函数,过程可作用于多用户种类型的对象上并获得不同结果.不同的对象收到同一消息可以产生不同的结果,这种现象称为多态性.9. 抽象是指强调实体的本质,内在的属性,忽略一些无关紧要的属性.10. 信息隐蔽是指所有软件部件内部都有明确的范围以及清楚的外部边界每个软件部件都有友好的界面接口,软件部件的内部实现与外部可访问性分离.11. 链表示对象间的物理与概念联结.12. 关联表示类之间的一种关系,就是一些可能的链的集合.第十一章 软件质量与质量保证1. 软件按照设计要求,在规定时间和条件下不出故障,持续运行的程度.2. 为了完成预定功能,软件系统所需的计算机资源和程序代码数量的程度.3. 找到并改正程序中的一个错误所需代价的程度.4. 将一个软件系统从一个计算机系统或环境移植到另一个计算机系统或环境中运行时所需的工作量.5. 将一个系统耦合到另一个系统所需的工作量.6. 修改或改进一个已投入运行的软件所需工作量的程度.7. 一个软件能再次用于其他相关应用的程度.8. 设计的规格说明书要符合用户的要求.9. 程序要按照设计规格说明所规定的情况正确执行.10. 冗余是指实现系统规定功能是多余的那部分资源,包括硬件,软件,信息和时间.第十二章 软件工程管理1. 软件配置管理,简称SCM,是一组管理整个软件生存期各阶段中变更的活动是一组管理整个软件生存期各阶段中变更的活动2. 软件配置项是软件工程中产生的信息项,它是配置管理的基本单位.3. 基线是软件生存期中各开发阶段的一个特定点,它的作用是把开发各阶段工作的划分更加明确化,使本来连续的工作在这些点上断开,以便于检查与肯定阶段成果.4. 文档是指某种数据媒体和其中所记录的数据.在软件工程中,文档用来表示对需求,工程或结果进行描述,定义,规定,报告或认证的任何书面或图示的信息.它们描述和规定了软件设计和实现的细节,说明使用软件的操作命令.第十三章 软件开发环境1. 软件开发环境是相关的一组软件工具集合,它支持一定的软件开发方法或按照一定的软件开发模型组织而成.2. 软件工具是指为支持计算机软件的开发,维护,模拟,移植或管理而研制的程序系统.3. CASE是一组工具和方法的集合,可以辅助软件开发生命周期各阶段进行软件开发.4. 一个组织中的CASE系统从被始需求到完全废弃这一生存期.5. 一个CASE工作台是一组工具集,支持像设计,实现或测试等特定的软件开发阶段.。
软件工程期末复习资料 华南农业大学版

第二章 系统工程
1.基于计算机的系统是指:通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。 组成基于计算机系统的元素主要有:软件、硬件、人员、数据库、文档和规程 2.系统工程的任务: (1)识别用户的要求(2)系统建模和模拟:包括硬件系统模型、软件系统模型、 人机接口模型、数据模型; (3)成本估算及进度安排(4)可行性分析(5)生成系统规格说明 3.可行性分析考虑:成本、效益、货币的时间价值、投资回收期析
第四章 设计工程
1.软件设计开始于软件需求的分析和规约之后,位于软件工程过程中的技术核心位置,是把需求转化 为软件系统的最重要环节 2.软件设计是把软件需求变换成软件表示的过程,它主要包含两个阶段:软件体系结构设计阶段和部 件级设计,前者也被称为概要设计,后者被称为详细设计。软件体系结构设计将软件需求转化为数据结构 和软件的系统结构。部件级设计将软件体系结构性元素转化为软件部件的过程性描述,得到软件详细的数 据结构和算法。 3.软件设计原则:抽象、逐步求精、模块化、信息隐藏 4.模块的独立性可以由两项指标来衡量:内聚度与耦合度。内聚度衡量一个模块内部各个元素彼此结 合的紧密程度,耦合度衡量不同模块之间相互依赖的紧密程度 5.内聚:是一个模块内部各个元素彼此结合的紧密程度的度量。内聚可以分为以下 7 中类型: 1)巧合内聚(偶然内聚) :将几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立的 模块称为巧合内聚模块 2)逻辑内聚 :指完成一组逻辑相关任务的模块,调用该模块时,由传送给模块的控制型参数来确定 该模块应执行哪一种功能 3)时间内聚:指一个模块中的所有任务必须在同一时间段内执行。例如初始化模块和终止模块 4)过程内聚 :指一个模块完成多个任务,这些任务必须按指定的过程(procedural)执行 5)通信内聚 :指一个模块内所有处理元素都集中在某个数据结构的一块区域中 6)顺序内聚:指一个模块完成多个功能,这些功能又必须顺序执行 7)功能内聚 :指一个模块中各个部分都是为完成一项具体功能而协同工作,紧密联系,不可分割的 6.耦合:是模块之间的相对独立性的度量。耦合取决于各个模块之间接口的复杂程度、调用模块的方 式以及通过接口的信息类型。耦合方式有其中类型: 1)内容耦合 :如果一个模块直接访问另一个模块的内部数据;或者一个模块不通过正常入口转到另
软件工程_张海蕃

应该推广使用在实践中总结出来的开发软件的成功 的技术和方法,并且研究探索更好更有效的技术和 方法,尽快消除在计算机系统早期发展阶段形成的 一些错误概念和做法。 应该开发和使用更好的软件工具。正如机械工具可 以“放大”人类的体力一样,软件工具可以“放大” 人类的智力。在软件开发的每个阶段都有许多繁琐 重复的工作需要做,在适当的软件工具辅助下,开 发人员可以把这类工作做得既快又好。如果把各个 阶段使用的软件工具有机地集合成一个整体,支持 软件开发的全过程,则称为软件工程支撑环境。
与软件开发和维护有关的许多错误认识和作法的形 成,可以归因于在计算机系统发展的早期阶段软件 开发的个体化特点。错误的认识和作法主要表现为 忽视软件需求分析的重要性,认为软件开发就是写 程序并设法使之运行,轻视软件维护等。
事实上,对用户要求没有完整准确的认识就匆忙着 手编写程序是许多软件开发工程失败的主要原因之 一。只有用户才真正了解他们自己的需要,但是许 多用户在开始时并不能准确具体地叙述他们的需要, 软件开发人员需要做大量深入细致的调查研究工作, 反复多次地和用户交流信息,才能真正全面、准确、 具体地了解用户的要求。对问题和目标的正确认识 是解决任何问题的前提和出发点,软件开发同样也 不例外。急于求成,仓促上阵,对用户要求没有正 确认识就匆忙着手编写程序,这就如同不打好地基 就盖高楼一样,最终必然垮台。事实上,越早开始 写程序,完成它所需要用的时间往往越长。
另一方面还必须认识到程序只是完整的软件产品的 一个组成部分,在上述软件生命周期的每个阶段都 要得出最终产品的一个或几个组成部分(这些组成 部分通常以文档资料的形式存在)。也就是说,一 个软件产品必须由一个完整的配置组成,软件配置 主要包括程序、文档和数据等成分。必须清除只重 视程序而忽视软件配置其余成分的糊涂观念。 作好软件定义时期的工作,是降低软件成本提高软 件质量的关键。如果软件开发人员在定义时期没有 正确全面地理解用户需求,直到测试阶段或软件交 付使用后才发现“已完成的”软件不完全符合用户 的需要,这时再修改就为时已晚了。
软件使用与维护管理制度

软件使用与维护管理制度第一章总则第一条目的和意义为规范企业内部软件的使用与维护,保障软件系统的正常运行,提高工作效率,保护企业信息安全,订立本规章制度。
第二条适用范围本规章制度适用于本企业全部员工,包含全职员工、兼职员工、临时员工、实习员工等。
第三条定义1.软件:指企业所使用的以电子形式存在的程序,包含但不限于操作系统、应用软件、商业软件等。
2.软件使用者:指企业员工在工作中使用软件的人员。
3.软件维护人员:指由企业指定的负责软件安装、升级、修复等工作的人员。
4.软件维护:指对软件进行安装、升级、修复等操作的过程。
第二章软件使用管理第四条软件申请与取得1.员工若需使用新的软件,应向本部门的IT管理员提出申请。
2.IT管理员将依据申请情况,进行软件的评估,并决议是否进行采购或安装。
3.员工在获得批准后,由IT管理员进行软件安装并供应相应的操作引导。
第五条软件许可证管理1.全部软件的购买和使用应符合相关法律法规,并确保拥有合法的软件许可证。
2.IT管理员负责统一管理软件的许可证,包含购买、更新、备份等工作。
3.软件使用者不得私自安装或使用未获得许可的软件,一经发现将追究相应责任。
第六条软件更新与升级1.IT管理员将定期对企业内部软件进行更新与升级,确保软件系统的安全性和稳定性。
2.对于紧要的软件更新与升级,将提前通知全部软件使用者,并布置合适的时间进行操作。
3.软件使用者应乐观搭配软件更新与升级的工作,并按要求进行必需的操作。
第七条软件备份与恢复1.IT管理员负责对企业内部紧要软件的数据进行备份工作,确保数据的安全性和可恢复性。
2.软件使用者应定期将紧要数据进行备份,并保管好备份数据,以防止数据丢失或损坏。
3.在意外情况下造成软件数据丢失或损坏时,软件使用者应立刻向IT管理员报告,寻求恢复措施。
第三章软件维护管理第八条软件故障报修1.软件使用者在使用过程中,如发现软件故障或异常情况,应立刻向IT管理员报修。
“软件工程导论”重点、难点

“软件工程导论”的授课内容重点、难点--供期末考试(教考分离)命题参考一、教材:软件工程—原理、方法与应用(第3版),史济民等编著,高等教育出版社二、任课教师: 陈征、于海雯三、授课内容及重点、难点第1章绪论重点:软件的基本概念,软件危机,软件工程学的范畴,传统软件工程和面向对象软件工程的比较。
第2章软件生存周期与软件过程重点:软件生存周期的基本概念,传统软件开发模型(瀑布模型、快速原型模型、增量模型、螺旋模型)的特点,可行性研究的内容,风险分析的3项活动。
第3章结构化分析与设计重点:结构化分析的任务和步骤,数据流图的组成符号,画分层的数据流图,数据字典的条目,加工逻辑的描述工具(判定表和判定树等),结构化设计的任务和步骤,面向数据流的设计方法(变换映射和事务映射),模块划分的原则,详细设计的目的与任务,常用的详细设计工具(程序流程图和N-S图等)。
难点:画分层的数据流图,画判定表和判定树,变换映射和事务映射。
第4章面向对象与UML重点:面向对象的基本概念,UML中的9种图(4种静态图、5种动态图)的基本结构,类与类之间的4种关系(关联、聚集、泛化、依赖)的含义,类图的画法。
难点:类图的画法。
第7章7.1 软件设计概述重点:软件设计的基本概念(模块化、抽象与细化、信息隐藏、模块独立性),内聚性(7种类型)和耦合性(7种类型)的含义。
第8章编码与测试重点:编码的风格,编码语言的选择,测试的目的,黑盒测试和白盒测试的测试用例设计方法,多模块程序的测试策略(单元测试、集成测试、确认测试和系统测试)。
难点:黑盒测试和白盒测试的测试用例设计。
第9章软件维护重点:软件维护的种类,维护的副作用,软件配置管理的含义。
第11章软件工程管理重点:软件估算模型、软件成本估计、人员的分配与组织、项目进度安排(计划评审技术图和Gantt 图)。
第12章软件质量管理重点:质量保证和质量认证的基本概念,软件可靠性的概念,软件容错技术,CMM软件能力成熟度模型。
软件工程教学大纲(正式版)

《软件工程导论》课程教学大纲一、课程基本信息课程编号:英文名称名:Software Engineering总学时:54学时学分:3课程类别:专业必修课适用专业:全校本(专)计算机科学与技术先修课程:数据结构,大学数学,离散数学,计算机算法设计。
二、课程性质与目的、要求《软件工程》是计算机专业的一门工程性基础课程,在软件工程学科人才培养体系中占有重要的地位。
软件开发是建立计算机应用系统的重要环节,人们通过软件工程学把软件开发纳入工程化的轨道,而软件工程学是用以指导软件人员进行软件的开发、维护和管理的科学。
《软件工程》已成为高等学校计算机软件教学体系中的一门核心课程,本课程以IEEE最新发布的软件工程知识体系为基础构建内容框架,注重贯穿软件开发整个过程的系统性认识和实践性应用,以当前流行的统一开发过程、面向对象技术和UML 语言作为核心,密切结合软件开发的先进技术、最佳实践和企业案例,力求从“可实践”软件工程的角度描述需求分析、软件设计、软件测试以及软件开发管理,使学生在理解和实践的基础上掌握当前软件工程的方法、技术和工具。
通过本课程的学习,要求学生能掌握软件工程的基本概念、基本原理、开发软件项目的工程化的方法和技术及在开发过程中应遵循的流程、准则、标准和规范等;学生应能掌握开发高质量软件的方法,以及有效地策划和管理软件开发活动,为学生参加大型软件开发项目打下坚实的理论基础。
本课程注重培养学生理论应用于实践的能力,课堂上教师向学生讲述软件工程中的相关原理和概念,并通过课程设计,培养学生对整个软件开发过程的能力,让学生能切实体会到软件工程在实践中的指导作用,并按软件工程的要求完成规范的各项软件开发文档。
本课程对提高学生的软件开发能力和项目管理能力有重要的现实意义。
三、教学内容及学时分配本课程的教学内容共分十三章。
第1章软件工程学概述(2课时)学习目的与要求:通过本章的学习,了解和掌握软件工程的基本概念(如软件和软件工程的定义、等),软件危机的表现形式、产生的原因及消除的途径,软件工程的基本原理、方法学,软件的生存期,几种主要的软件开发模型等。
软件维护实施计划

软件维护实施计划通常包括以下几个步骤:
1. 分析问题:对软件进行故障排查,明确软件需要维护的原因,例如修复错误、增加新功能等。
2. 维护计划制定:根据问题的性质和需要,制定相应的维护计划,例如修复性维护或适应性维护。
3. 资源准备:准备必要的资源,如人员、时间、预算、工具等。
4. 执行维护:按照计划执行维护工作,包括修改代码、测试软件、回归测试等。
5. 维护文档:在维护过程中,要保留必要的文档,包括变更请求、测试结果等。
6. 用户通知:如果软件维护会影响到用户的使用,应该提前通知用户。
7. 后期评估:维护工作完成后,要对维护效果进行评估,看是否达到了预期的效果,是否需要进一步改进。
具体实施计划可能因软件项目的具体情况而异,但以上步骤是一般软件维护的常见流程。
请注意,在实施维护计划时,务必确保遵守公司的安全政策和程序,以避免任何安全风险。
软件工程复习资料

第一章概论1.软件工程的主要内容:为了有限的资金、资源和时间条件下开发满足客户要求的高质量软件,就需要研究与软件开发和管理相关的模型、方法、技术、过程、工具和环境等。
2.计算机软件:指的是计算机系统中的程序及其文档,3.程序:指的是计算任务的处理对象和处理规则的描述.4.计算任务:任何以计算机为处理工具的任务都是计算任务。
5.处理对象:是数据(如数字、文字、图形、图像、声音等,它们只是表示,而无含义)或信息(数据及相关的含义)。
6.处理规则:一般指处理的动作和步骤.7.文档:是为了便于了解程序所需的阐述性资料.8.软件工程:是应用计算机科学,数学及管理科学等原理,开发软件的工程。
软件工程借鉴传统工程的原则、方法、以提高质量、降低成本为目的。
其中,计算机科学、数学用于构造模型与算法,工程科学用于制定规范、设计范型、评估成本及确定权衡,管理科学用于计划、资源、质量、成本等管理。
9.杨芙清院士指出软件工程的框架可概括为:目标、过程和原则。
10.软件工程目标:只生产具有正确性、可用性和开销合宜的产品。
正确性:指软件产品达到预期功能的程度。
可用性:只软件基本结构、实现及文档为用户可用的程度。
开销合宜:只软件开发,运行的整个开销满足用户要求的程度。
11.软件工程原则包括围绕工程设计、工程支持和工程管理所提出的4条基本原则:(1)选取适宜的开发模型(2)采用合适的设计方法(3)提供高质量的工程支撑(4)重视软件工程的管理。
12.软件的生存周期:软件孕育、诞生、成长、衰亡的生存过程。
软件生存周期是指软件产品或软件系统从产生、投入使用到被淘汰的全过程。
软件生存周期大致可以分为6个阶段:计算机系统工程、需求分析、设计、编码、测试、运行和维护。
13.软件过程:是生产一个最终满足需求且达到工程目标的软件产品所需的步骤。
过程是活动的集合,活动是任务的集合。
14.软件过程有3层含义:(1)、个体含义:指软件产品或系统存在生存周期中的某一类活动的集合,如软件开发过程、软件管理过程等。
自学考试软件工程第13章软件开发环境

❖ 2.程序设计工作台 程序设计工作台由支持程序开发过程的一组工具组成。将编译
器、编辑器和调试器这样的软件工具一起放在一个宿主机上,该 机器是专门为程序开发设计的。组成程序设计工作台的工具可能 有:
(1)语言编译器:将源代码程序转换成目标码。 (2)结构化编辑器:结合嵌入的程序设计语言知识。 (3)连接器。 (4)加载器。 (5)交叉引用。 (6)按格式打印。 (7)静态分析器。 (8)动态分析器。 (9)交互式调试器。 3.分析和设计工作台 分析和设计工作台支持软件过程的分析和设计阶段,在这一阶 段,系统模型已建立(例如,一个数据库模型,一个实体关系模 型等)。这些工作台通常支持结构化方法中所用的图形符号。支 持分析和设计的工作台有时称为上游 CASE工具。它们支持软件 开发的早期过程。程序设计工作台则成为下游CASE工具。 4.测试工作台 测试是软件开发过程较为昂贵和费力的阶段。测试工作台永远 应为开放系统,可以不断演化以适应被测试系统的需要。
13.3.1 CASE定义
❖ CASE是一组工具和方法集合,可以辅助软 件开发生命周期个阶段进行软件开发。
13.3.2 CASE分类
❖ 1.CSAE技术种类 CASE系统所涉及到的技术有两大类:一类是支
持软件开发过程的本身的技术,如支持规约、设计、 实现、测试等等。
还有一种特殊的CASE技术,即元-CASE技术。
❖ 1.平台集成 “平台”或是一个单一的计算机或操作系统或是一个网络系统。 2.数据集成 数据集成是指不同软件工程能相互交换数据。 (1)共享文件。 (2)共享数据结构。 (3)共享仓库。 最简单的数据集成形式是基于一个共享文件的集成,UNIX系统就是这
样。UNIX有一个简单的文件模型,即非结构化字符流。任何工具都能把 信息写入文件中,也能读其他工具生成的文件。UNIX还提供管道。
《软件工程》各章课后习题答案

第一章课后参考答案1.什么是软件危机?它们有哪些典型表现?为什么会出现软件危机?“软件危机”是指计算机软件的“开发”和“维护”过程中所遇到的一系列“严重问题”。
这些问题决不仅仅是不能正常运行的软件才具有的,实际上,几乎“所有软件”都不同程度地存在这些问题。
它们有以下表现:(1)对软件开发成本和进度的估计常常很不准确;(2)用户对“已完成的”软件系统不满意的现象经常发生;(3)软件产品的质量往往靠不住;(4)软件常常是不可维护的;(5)软件通常没有适当的文档资料;(6)软件成本在计算机系统总成本中所占的比例逐年上升;(7)软件开发生产率提高的速度,远远跟不上计算机应用普及深入的趋势。
出现软件危机的主要原因(1)与软件本身的特点有关(2)与软件开发和维护过程中使用的方法不正确有关2.假设自己是一家软件公司的总工程师,当把图1.1给手下的软件工程师们观看,告诉他们及时发现并改正错误的重要性时,有人不同意这个观点,认为要求在错误进入软件之前就清楚它们是不现实的,并举例说:“如果一个故障是编码错误造成的,那么,一个人怎么能在设计阶段清除它呢?”应该怎么反驳他?答:在软件开发的不同阶段进行修改付出的代价是很不相同的,在早期引入变动,涉及的面较少,因而代价也比较低;在开发的中期,软件配置的许多成分已经完成,引入一个变动要对所有已完成的配置成分都做相应的修改,不仅工作量大,而且逻辑上也更复杂,因此付出的代价剧增;在软件“已经完成”时在引入变动,当然付出的代价更高。
一个故障是代码错误造成的,有时这种错误是不可避免的,但要修改的成本是很小的,因为这不是整体构架的错误。
3.什么是软件工程?它有哪些本质特征?怎么用软件工程消除软件危机?软件工程是指导知道计算机软件开发和维护的一门工程学科。
采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好技术方法结合起来,以经济地开发出高质量的软件并有效地维护它,这就是软件工程。
软件工程导论(第六版)张海藩课后习题部分答案

软件⼯程导论(第六版)张海藩课后习题部分答案第⼀章1-1 什么是软件危机 ? 是指在计算机软件的开发和维护过程中所遇到的⼀系列严重问题。
1-3 什么是软件⼯程 ? 是指导计算机软件开发和维护的⼀门⼯程学科。
1-4 简述结构化范型和⾯向对象范型的要点,并分析它们的优缺点。
⽬前使⽤得最⼴泛的软件⼯程⽅法学( 2 种):1. 传统⽅法学:也称为⽣命周期⽅法学或结构化范型。
优点:把软件⽣命周期划分成基⼲个阶段,每个阶段的任务相对独⽴,⽽且⽐较简单,便于不同⼈员分⼯协作,从⽽降低了整个软件开发过程的困难程度。
缺点:当软件规模庞⼤时,或者对软件的需求是模糊的或会承受时间⽽变化的时候,开发出的软件往往不成功;⽽且维护起来仍然很困难。
2. ⾯向对象⽅法学:优点:降低了软件产品的复杂性;提⾼了软件的可理解性;简化了软件的开发和维护⼯作;促进了软件重⽤。
1-6 什么是软件过程 ?它与软件⼯程⽅法学有何关系 ?z 软件过程:是为了获得⾼质量软件所需要完成的⼀系列任务的框架,它规定了完成各项任务的⼯作步骤 z 软件⼯程⽅法学:通常把在软件⽣命周期全过程中使⽤的⼀整套技术⽅法的集合称为⽅法学,也称范型1-7 什么是软件⽣命周期模型,试⽐较瀑布模型,快速原型模型,增量模型,和螺旋模型的优缺点,说明每种模型的适⽤范围。
软件⽣命周期由软件定义、软件开发和运⾏维护 3 个时期组成,每个时期⼜进⼀步划分成若⼲个阶段。
⽣命周期模型规定了把⽣命周期划分成哪些阶段及各个阶段的执⾏顺序,因此,也称为过程模型。
瀑布模型的优点: 1. 可强迫开发⼈员采⽤规范的⽅法; 2. 严格规定了每个阶段必须提交的⽂档;3. 要求每个阶段交出的所有产品都必须经过质量保证⼩组的仔细验证。
瀑布模型的缺点: 1.在软件开发初期,指明⽤户全部需求是困难的; 2.需求确定后,经过⼀段时间才得到软件最初版本; 3. 完全依赖规格说明,导致不能满⾜⽤户需求。
适⽤中⼩型项⽬。
13章软件维护与再工程

则。 • 一个可修改的软件应当是可理解的、通用的、灵活的、
简单的。其中: 通用性:指软件适用于各种功能变化而无需修改。 灵活性: 是指能够容易的对软件进行修改。
25
软件可维护性-主要影响因素
. 可移植性:指程序转移到一个新的计算环境的 难易程度。
11
软件维护的概念-维护成本
数据库技术的应用:使用数据库,可以简单而有效 地管理和存储用户程序中的数据,还可以减少生成 用户报表应用软件的维护工作量 先进的软件开发技术:在软件开发过程中,如果采 用先进的分析设计技术和程序设计技术,如面向对 象技术、复用技术等,可减少大量的维护工作量 其它一些因素:如应用的类型、数学模型、任务的 难度、 IF嵌套深度、索引或下标数等,对维护工作 量也有影响
. 可维护性(maintainability)
– 指理解、改正、调整和改进软件的难易程度。 – 对软件可维护性影响的主要因素有:
. 可理解性(understandability)、 . 可测试性( testability)、 . 可修改性、 modifiability) . 和可移植性(portability)
. 在进行代码评审时,要强调编程风格和内部文档。 . 在进行测试时应指出软件正式交付前应进行的预防性维
护。在维护活动完成后也要进行评审。
28
软件可维护性-提高可维护性的方法
. 通常采用的方法有
– 确定质量管理目标和优先级 – 使用提高软件质量的技术与工具 – 选择可维护性高的程序设计语言 – 改进程序文档 – 进行质量保证审查
8
软件维护的概念-维护成本
软件工程软件维护技术概述

维护的问题
与软件维护有关的绝大多数问题,都可归结于软
维 件定义和开发的方法有缺点。下面是和软件维护有关 的部分问题:
护 * 理解别人写的程序通常比较困难,而且困难
的 程度随着 软件配置成分的减少而迅速增加。
特
如果仅有程序代码没有说明文档,则问题 会现严重。
点 * 需要维护的软件往往没有合格的文档,或
软件可维护性可以定性地定义为: 维护人员理解、改正、改动和改进这 个软件的难易程度。
20前2一1页/1/12
22
可维护性
主
▪ 决定软件可维护性的因素
要 内
▪ 文档
容
▪ 可维护性复审
20前2一1页/1/12
23
决定软件可维护性的因素
可 1. 可理解性:软件可理解性表现为外来读者理解软件 的结构、接口、功能和内部过程的难易程度。
20前2一1页/1/12
5
维护的特点
主 要 内
▪ 结构化与非结构化维护 ▪ 维护的代价
容 ▪ 维护的问题
20前2一1页/1/12
6
结构化与非结构化维护
维 如果软件配置的唯一成分是程序代码,那么维护 活动从艰苦地评价程序代码开始,而且常常由于程序
护 内部文档不足而使评价更困难。这种维护方式是没有 使用良好定义的方法论开发出来的软件的必然结果。
护 成本大约是每条指令4000美元,也就是说,生产率下 降了50倍以上。 下述表达式给出维护工作量的一个模
的 型:
特
M = P + K × exp ( c - d )
点 其中: M是维护用的总工作量 P:生产性工作量
K:是经验常数
c:是复杂程度
d:是维护人员对软件的熟悉程度
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
工作安排队列中的任务,由修改负责人依次从 队列中取出任务,按照软件工程方法学规划、 组织、实施工程。
软件维护的过程-维护过程
维护请求
适应性维护
类型
其他 改善性维护
软件维护的概念-维护成本
维护的工作可划分成
1. 生产性活动 如,分析评价、修改设计、编写程序代码等 2. 非生产性活动 如,程序代码功能理解、数据结构解释、接
口特点和性能界限分析等
维护工作量的模型
M p Kecd
M:维护的总工作量 ;P:生产性工作量;K:经验常数;c:复杂程 度;d:维护人员对软件影响维护工作量的因素主要有以下六种
1. 系统的规模:系统规模越大,其功能就越复杂,软件维护的工作量也随之增大
2. 程序设计语言:使用强功能的程序设计语言可以控制程序的规模。语言的功能 越强,生成程序的模块化和结构化程度越高,所需的指令数就越少,程序的可 读性也越好
3. 系统年龄:老系统比新系统需要更多的维护工作量。
软件维护的概念-软件维护分类
1. 纠错性维护:为了改正软件系统中的错误,使软件能够 满足预期的正常运行状态的要求而进行的维护
2. 适应性维护:为了使软件适应内部或外部环境变化,而 去修改软件的过程
3. 改善性维护:满足使用过程中用户提出增加新功能或修 改已有功能的建议维护
4. 预防性维护:为了提高软件的可维护性、可靠性等,为 以后进一步改进软件打下良好基础而修改软件的活动
4. 绝大多数软件在设计时没有考虑到将来的修改问题
5. 软件维护这项工作毫无吸引力。一方面是因为软件维护,看不到什么 “成果”,但工作量很大,更重要的是维护工作难度大,软件维护人员 经常遭受挫折。
软件维护的概念-维护成本
软件维护除费用外的无形代价包括
1. 维护活动占用了其他软件开发可用的资源,使资源的利用率降低 2. 一些修复或修改请求得不到及时安排,使得客户满意率下降 3. 维护的结果把一些新的潜在的错误引入软件,降低了软件质量 4. 将软件人员抽调到维护工作中,使得其它软件开发过程受到干扰
1. 理解别人的代码通常是非常困难的,而且难度随着软件配置成分的缺失 而迅速增加
2. 需要维护的软件往往没有文档、或文档资料严重不足、或软件的变化未 在相应的文档中反映出来
3. 当软件要求维护时,不能指望由原来的开发人员来完成或提供软件的解 释。由于维护持续时间很长,因此当需要解释软件时候,往往开发人员 已经不在附近了
4. 数据库技术的应用:使用数据库,可以简单而有效地管理和存储用户程序中的 数据,还可以减少生成用户报表应用软件的维护工作量
5. 先进的软件开发技术:在软件开发过程中,如果采用先进的分析设计技术和程 序设计技术,如面向对象技术、复用技术等,可减少大量的维护工作量
6. 其它一些因素:如应用的类型、数学模型、任务的难度、IF嵌套深度、索引或 下标数等,对维护工作量也有影响
软件维护的概念-维护问题
维护时:
维护人员从分析需求规格说明开始, 明白软件功能和性能上的改变, 对设计说明文档进行修改和复查, 再根据设计修改进行程序变动, 并用测试文档中的测试用例进行回归测试, 最后将修改后的软件再次交付使用。
软件维护的概念-维护问题
和软件维护有关的部分问题 :
4. 再工程的主要目的是为遗留系统转化为可演化系统提供一 条现实可行的途径,是在软件生命周期终止后开始的一个 新的阶段。
内容摘要
软件维护 再工程技术
内容摘要
软件维护 再工程技术
软件维护的概念
什么是软件维护
是指软件系统交付使用以后,为了改正错误或满足新的需 要而修改软件的过程
国标GB/T 11457-95给出如下定义
维护团队根据时间的不同,可以分为短期团队和长期团队
短期团队一般是当需要执行相关具体任务时,临时组织 起来解决手头的问题
长期团队则更正式,能够专业化创建沟通渠道,可以管 理软件系统整个生存期的成功演化
无论是短期团队还是长期团队,都要把有经验的员工和 新员工混合起来。
软件维护的过程-维护过程
非纠错性维护,则首先判断维护类型,对适应 性维护,按照评估后得到的优先级放入队列
软件工程
第13章 软件维护与再工程
软件维护与再工程
1. 软件演化是指软件在交付以后,对软件进行的一系列活动 的总称。
2. 软件演化:软件的维护、软件再工程。
3. 软件维护阶段覆盖了从软件交付使用,到软件被淘汰为止 的整个时期。软件的开发时间可能需要一、二年,甚至更 短,但它的使用时间可能要经历几年或几十年。
软件维护的过程-维护组织
维护组织结构图 维护管理员、系统监督员、 修改控制决策机构等,均代表 维护工作的某个职责范围 。 系统监督员一般都是对程 序(某一部分)特别熟悉的技 术人员。 在维护人员对程序进行修 改的过程中,由配置管理 员严格把关,控制修改的 范围,对软件配置进行审 计。
软件维护的过程-维护组织
类型
纠错性维护
非常严重
严重性
评估后按优先 级在队列排队
拒绝
评估后分类 采取的行动
接受
救火行动,当 排在队列之首
通知请求者 并说明原因
按优先级在 队列中排队
并不严重
评估后按优先 级在队列排队
维护过程图
从维护请求队列之首取出一任务
按SE方法学规划、组织、实施工程
y 队列中还有维护请求吗?
n 资源用于开发新的软件。
软件维护的过程-维护过程
维护工作最后一步是复审 1. 依照当前状态,在设计、编码和测试的哪些 方面还能用其他方法进行?
➢ 在软件产品交付使用后对其进行修改,以纠正故障;
➢ 在软件产品交付使用后对其进行修改,以纠正故障、改进 其性能和其它属性,或使产品适应改变了的环境
软件维护的概念-软件维护分类
两种错误认识 – 软件维护是一次新的开发活动 – 软件维护就是改错
新开发活动强调要在一定的约束条件下从头开始实施
软件维护强调必须在现有系统的限定和约束条件下实施 ;根 据起因不同,软件维护可以分为纠错性维护、适应性维护、 改善性维护和预防性维护四类