完整软件工程导论第6版知识点总结复习课推荐文档.docx
- 文档编号:9579714
- 上传时间:2023-05-20
- 格式:DOCX
- 页数:32
- 大小:990.20KB
完整软件工程导论第6版知识点总结复习课推荐文档.docx
《完整软件工程导论第6版知识点总结复习课推荐文档.docx》由会员分享,可在线阅读,更多相关《完整软件工程导论第6版知识点总结复习课推荐文档.docx(32页珍藏版)》请在冰点文库上搜索。
完整软件工程导论第6版知识点总结复习课推荐文档
复习课
--------酷爱YC
第一章
1、什么是软件危机,什么是软件工程
软件危机是指在计算机软件开发、使用与维护过程中遇到的一系列严重问题和难题。
它包括两方面:
(1)如何开发软件,以满足对软件日益增长的需求;
(2)如何维护数量不断膨胀的已有软件。
软件工程:
采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来,以经济地开发出高质量的软件,并有效地维护它。
2、完整的软件配置由哪些内容组成
软件配置主要包括程序,文档和数据等成分。
3、软件生命周期分为哪3个时期和8个阶段,每个阶段的任务(工作)分别是什么,重要性如何
概括地说,软件生命周期由软件定义、软件开发和运行维护3个时期组成
1、软件定义(系统分析)。
软件定义时期的任务是:
确定软件开发工程必须完成的总目标;确定工程的可行性;导出实现工程目标应该采用的策略及系统必须完成的功能;估计完成该项工程需要的资源和成本,并且制定工程进度表。
这个时期的工作通常又称为系统分析,由系统分析员负责完成。
软件定义时期通常进一步划分成3个阶段,即问题定义、可行性研究和需求分析。
(1)问题定义,确定系统要解决的问题是什么。
成果:
关于问题性质、工程目标和工程规模的报告。
(2)可行性研究,确定问题是否有可用的、能行得通的解(包括:
技术、经济、操作、社会等方面的可行性)。
这个阶段的任务不是具体解决问题,而是研究问题的范围,探索这个问题是否值得去解,是否有可行的解决办法。
成果:
可行性研究报告。
(3)需求分析,确定软件系统的必须实现的功能、必须达到的性能、必须满足的运行环境要求。
系统分析员在需求分析阶段必须和用户密切配合,充分交流信息,以得出经过用户确认的系统逻辑模型。
通常用数据流图、数据字典和简要的算法表示系统的逻辑模型。
在需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础,因此必须准确完整地体现用户的要求。
成果:
软件需求规格说明书(SRS),内容包括:
系统的逻辑模型;系统(子系统)的名称、功能描述、接口、基本数据结构、性能、设计需求、开发标准、验收原则等。
2、软件开发。
开发时期具体设计和实现在前一个时期定义的软件,它通常由下述4个阶段组成:
总体设计,详细设计,编码和单元测试,综合测试。
其中前两个阶段又称为系统设计,后两个阶段又称为系统实现。
(1)总体设计(概要设计),回答“怎样实现目标系统”。
建立系统的总体结构,划分子系统;确定系统由哪些模块组成,各子系统间、各模块间的关系(包括定义各子系统接口界面和各功能模块的接口,设计全局数据库或数据结构,
规定设计约束,制定组装测试计划)。
成果:
概要设计说明书、数据库或数据结构说明书、系统的组装(集成)测试计划等文档。
(2)详细设计任务就是把解法具体化,也就是回答:
“应该怎样具体地实现这个系统呢?
”,设计每个程序模块的内部细节,包括数据结构、算法以及各程序模块间的接口信息,并
设计模块的单元测试计划。
成果:
详细设计规格说明和单元测试计划等详细设计文档。
以上
(1)、
(2)又合称为软件设计。
(3)编码和单元测试这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。
根据详细设计规格说明,选用某种程序设计语言把详细设计的结果转化为机器可运行的源程序模块;运行和调试每一个程序模块;每编写出一个程序模块的源程序,调试通过后,即对该模块进行单元测试。
成果:
按一定规则存在盘上的通过了单元测试的各功能模块的集合;详细的单元测试报告等文档。
(4)综合测试通过各种类型的测试(及相应的调试)使软件达到预定的要求。
最基本的测试是集成测试和验收测试。
成果:
①满足概要设计要求、可运行软件系统和源程序清单;组装测试报告等文档。
②验收测试报告、项目开发总结报告,向用户提交的源程序清单、最终用户手册、操作手册等文档资料;由专家、用户负责人、软件开发和管理人员组成软件评审小组对软件验收测试报告、测试结果和软件进行评审,最终验收软件产品。
以上(3)、(4)又合称为软件实现。
三种不同的软件测试:
单元测试、集成测试、验收测试。
3、软件运行与维护
软件技术人员通过各种维护活动使软件系统持久满足用户需要。
通常有4类维护活动:
改正性维护,也就是诊断和改正在使用过程中发现的软件错误;适应性维护,即修改软件以适应环境的变化;完善性维护,即根据用户的要求改进或扩充软件使它更完善;预防性维护,即修改软件为将来的维护活动预先做准备。
成果:
①更新后的软件产品;②准确记录维护活动的文档。
4、几种传统软件工程生命周期模型:
瀑布模型:
基本思想、主要优点
传统的瀑布模型
基本思想:
瀑布模型严格按照软件生存周期各个阶段来进行开发,上一阶段的输出即是下一阶段的输入,并强调每一阶段的严格性。
它规定了各阶段的任务和应提交的成果及文档,每一阶段的任务完成后,都必须对其阶段性产品(主要是文档)进行评审,通过后才能开始下一阶段的工作。
因此,它是一种以文档作为驱动的模型。
优点:
可强迫开发人员采用规范的方法;严格地规定了每个阶段必须提交的文档;要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
快速原型模型:
基本思想
基本思想:
软件开发人员根据用户提出的软件基本需求快速开发一个原型,以便向用户展示软件系统应有的一部分或全部功能和性能,同时使用户熟悉系统。
在征求用户对原型的初步意见后,进一步使需求全面化、精确化,并据此改进、完善原型。
如此迭代,直到软件开发人员和用户都通过原型确认软件系统的需求并达成一致的理解为止。
软件需求确定后,便可进行设计,编码、测试等以后的各个开发步骤。
增量模型:
基本思想、主要优点
基本思想:
把一个软件产品划分为一系列的增量构件来设计、编码、集成和测试,并逐个添加到软件产品中去,逐步向用户提交产品。
每个构件能够完成特定的功能
优点:
(1)软件的实现和维护阶段没有明显的分界线;
(2)用户在很短时间内就可以使用产品的部分功能
(3)用户适应新产品的时间较充裕
(4)构件的分解要易于测试、规模适中
(5)软件的体系结构是开放的,易于扩充和维护
螺旋模型:
引入的原因,与瀑布模型、快速原型模型的联系
基本思想:
软件风险是任何软件开发项目中都普遍存在的实际问题,项目越大,软件越复杂,承担该项目所冒的风险也越大。
软件风险可能在不同程度上损害软件开发过程和软件产品质量。
构建原型是一种能使某些类型的风险降至最低的方法。
螺旋模型的基本思想是,使用原型及其他方法来尽量降低风险。
联系:
简化的螺旋模型是在快速原型模型的基础上扩展而成的,把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。
完整的螺旋模型,将瀑布模型与原型模型结合起来,并且加入前两种模型均忽略了的风险分析
瀑布模型的优点:
有利于大型软件开发过程中人员的组织、管理,有利于软件开发方法和工具的研究,从而提高了大型软件项目开发的质量和效率。
瀑布模型的缺点:
(1)开发过程一般不能逆转,否则代价太大;
(2)实际的项目开发很难严格按该模型进行;(3)客户往往很难清楚地给出所有的需求,而该模型却要求如此。
(4)软件的实际情况必须到项目开发的后期客户才能看到,这要求客户有足够的耐心。
瀑布模型的使用范围:
(1)用户的需求非常清楚全面,且在开发过程中没有或很少变化;
(2)开发人员对软件的应用领域很熟悉;(3)用户的使用环境非常稳定;(4)开发工作对用户参与的要求很低。
快速原型模型的优点:
(1)可以得到比较良好的需求定义,容易适应需求的变化;
(2)有利于开发与培训的同步;(3)开发费用低、开发周期短且对用户更友好。
快速原型模型的缺点:
(1)客户与开发者对原型理解不同;
(2)准确的原型设计比较困难;(3)不利于开发人员的创新。
快速原型模型的使用范围:
(1)对所开发的领域比较熟悉而且有快速的原型开发工具;
(2)项目招投标时,可以以原型模型作为软件的开发模型;(3)进行产品移植或升级时,或对已有产品原型进行客户化工作时,原型模型是非常适合的。
增量模型的优点:
(1)采用增量模型的优点是人员分配灵活,刚开始不用投入大量人力资源;
(2)如果核心产品很受欢迎,则可增加人力实现下一个增量;(3)可先发布部分功能给客户,对客户起到镇静剂的作用。
增量模型的缺点:
(1)并行开发构件有可能遇到不能集成的风险,软件必须具备开放式的体系结构;
(2)增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。
增量模型的使用范围:
(1)进行已有产品升级或新版本开发,增量模型是非常适合的;
(2)对完成期限严格要求的产品,可以使用增量模型;(3)对所开发的领域比较熟悉而且已有原型系统,增量模型也是非常适合的。
螺旋模型的优点:
(1)设计上的灵活性,可以在项目的各个阶段进行变更;
(2)以小的分段来构建大型系统,使成本计算变得简单容易;(3)客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性;(4)随着项目推进,客户始终掌握项目的最新信息,从而他或她能够和管理层有效地交互。
螺旋模型的缺点:
(1)采用螺旋模型需要具有相当丰富的风险评估经验和专门知识,在风险较大的项目开发中,如果未能够及时标识风险,势必造成重大损失;
(2)过多的迭代次数会增加开发成本,延迟提交时间。
螺旋模型的使用范围:
螺旋模型只适合于大规模的软件项目。
第二章
什么是:
经济可行性、技术可行性、运行与操作可行性、法律可行性
(1)经济可行性:
这个系统的经济效益能超过它的开发成本吗?
估算项目的开发成本和系统投入使用后可能带来的利润,进行成本/效益分析,从经济角度判断系统开发是否“合算”。
(2)技术可行性:
使用现有的技术能实现这个系统吗?
根据客户提出的系统功能、性能要求,从开发者的技术实力、以往工作基础、问题的复杂性等出发,判断系统开发在时间、费用及其他各项约束条件限制下成功的可能性。
(3)运行、操作可行性:
系统的操作方式在这个用户组织内行得通吗?
主要研究系统的运行方式在用户单位是否可以被有效地实施,是否与原有其他系统相矛盾;系统的操作规程在用户单位内是否可行,它包括人事、科技政策、管理方法等等。
(4)法律可行性:
系统的开发使用,在当国当地当时合法吗?
利用软件工程的方法设计开发软件系统的过程
第三章
需求分析的基本任务
1.确定需求--确定对系统的综合要求
(1)功能需求
(2)性能需求(3)可靠性和可用性需求(4)出错处理需求(5)接口需求(6)约束(7)逆向需求(8)将来可能提出的要求
2.建立数据模型--利用图形工具描述系统数据结构并将数据结构规范化,建立数据模型
3.导出系统的逻辑模型--通常用数据流图、实体--联系图、状态转换图、数据字典和主要的处理算法描述整个逻辑模型
4.编写需求规格说明书
5.修正系统开发计划
本阶段结束形成的基本文档
软件需求规格说明书
结构化分析应建立哪三大模型,分别用什么工具描述
数据模型—数据流图
功能模型—实体-联系图(E-R图)行为模型—状态图
数据流图、E-R图、状态转换图的构成
数据流图--系统逻辑功能的描述工具
4种成分:
源点和终点,处理,数据存储,数据流
E-R图:
实体(即数据对象)----矩形框,关系----菱形框,属性椭圆形或圆角矩形
状态转换图:
状态,事件,状态转换
数据字典:
数据字典是关于数据的信息的集合,也就是对数据流图中包含的所有元素进行定义的集合。
它的作用正是在软件分析和设计的过程中给人提供关于数据的描述信息。
数据流图和数据字典共同构成系统可行性研究阶段的逻辑模型。
数据字典的实现
(1)用Case工具中的数据字典处理程序对数据字典进行生成和编辑;
(2)通过手工制作卡片来制作数据字典。
每张卡片上保存描述一个数据的信息,主要应该包含下述这样一些信息:
名字、别名、描述、定义、位置。
第五章
1、总体设计过程包含哪两个工作阶段,各完成什么任务
第一阶段:
系统设计阶段,确定系统的物理实现方案
(1)设想(完善)供选择的方案
(2)选取合理的方案(3)推荐最佳方案第二阶段:
结构设计阶段,确定软件的结构
(1)功能分解,从实现的角度细化逻辑模型
(2)设计软件结构
(3)设计数据库
(4)制定测试计划
(5)书写文档
(6)审查和复审
2、软件工程的中心课题是控制软件的复杂度;在总体设计阶段,软件复杂度主要体现为模块独立性(和全局数据结构复杂度);描述模块独立性的两个指标分别是耦合和内聚
3、耦合的含义,1-8级耦合的具体含义,耦合级别的排列
耦合(Coupling):
是对软件结构内不同模块之间相互关联程度的强弱的度量。
它取决于各个模块之间接口的复杂程度、进入或访问一个模块的点以及哪些信息通过接口传递。
耦合度可以分为若干级别:
(1)非直接耦合--两个模块没有直接关系(如模块1和模块2),每一个都能独立地工作而不需要另一个模块的存在。
非直接耦合两个模块间的独立性最强。
非直接耦合
(2)数据耦合--两个模块彼此间通过参数交换信息,而且交换的信息仅仅是简单的数据信息。
这属于松散耦合。
(3)标记耦合--两个模块通过传递数据结构参数加以联系(不是简单数据,而是记录、数组等),则称这两个模块间存在标记偶合。
数据耦合特征耦合(标记耦合)
(4)特征耦合--属于标记耦合,把整个数据结构作为参数传递,而被调用的模块只需要使用其中一部分数据元素。
P39
控制耦合公共环境耦合
(5)控制耦合--一个模块通过传送开关、标志、名字等控制信息,明显地控制选择另一模块的某部分功能。
控制耦合增加了理解和编程的复杂性,调用模块必须知道被调模块的内部逻辑,增加了相互依赖。
去除模块间控制耦合的方法:
a.将被调用模块内的判定上移到调用模块中进行
b.被调用模块分解成若干单一功能模块
(6)外部耦合--一组模块都访问同一全局简单变量,而且不是通过参数传递该全局变量的信息。
(7)公共环境耦合--两个或多个模块通过一个公共数据环境相互作用。
公共环境可以是全程变量、共享的通信区、内存的公共覆盖区、任何存储介质上的文件、物理设备等等。
公共环境耦合的复杂程度随耦合的模块个数而变化,当耦合的模块个数增加时复杂程度显著增加。
公共环境偶合必不可少,但耦合模块的数目应尽量少。
(8)内容耦合—P41
内容耦合
4、内聚的含义,1-7级内聚的具体含义,内聚级别的排列
内聚(Cohesion):
标志同一个模块内各个元素彼此结合的紧密程度,它是信息隐藏和局部化概念的自然扩展。
高内聚:
模块内部完成单一的处理;低内聚:
模块内部各部分关联不紧密,完成分散的多个处理任务;设计时应该力争做到高内聚。
内聚度也可以分为若干级别:
(1)偶然内聚--当模块内各部分之间没有联系,或者即使有联系,这种联也很松散,则称这种模块为偶然内聚模块,它的内聚程度最低。
(2)
逻辑内聚--把几种相关功能或逻辑上相似的功能组合在一个模块内,每次调用由传给模块的参数确定执行哪种功能。
偶然类聚逻辑类聚
(3)时间内聚--一个模块包含若干必须在同一段时间内执行的任务。
例如系统初始化模块、系统结束模块、紧急故障处理模块等均是时间性聚合模块。
(4)
过程内聚--一个模块内的处理元素是相关的且仅有控制联系,各处理元素必须以特定次序执行。
(5)通信内聚--模块中所有元素都使用同一个输入数据和(或)产生同一个输出数据。
(6)顺序内聚--一个模块内的处理元素既包含数据联系也包含控制联系,而且这些处理必须顺序执行(通常一个处理元素的输出数据作为下一个处理元素的输入数据)。
(7)
信息内聚--这种模块完成多个简单功能,各个功能都在同一数据结构上操作,每一项功能有一个唯一的入口点。
这个模块将根据不同的要求,确定该执行哪一个功能。
由于这个模块的所有功能都是基于同一个数据结构,因此,它是一个信息内聚的模块。
功能内聚--一个模块中各个部分都是完成某单一功能必不可少的组成部分,或者说该模块中所有部分都是为了完成同一项具体功能而协同工作,紧密联系,不可分割的,则称该模块为功能内聚模块。
功能内聚是最高程度的内聚。
5、如何将数据流图转换为初始的软件结构图/层次图
通过变换分析的方法
第1步复查基本系统模型。
第
2步复查并精化数据流图。
第3步确定数据流图具有变换特性还是事务特性。
第4步确定输入流和输出流的边界,从而孤立出变换中心。
第5步完成“第一级分解”。
第6步完成“第二级分解”。
第7步使用设计度量和启发式规则对第一次分割得到的软件结构进一步精化。
6、关于模块设计的启发规则
启发式规则(模块化设计的经验)
1.改进软件结构提高模块独立性
2.模块规模应该适中
3.深度、宽度、扇出和扇入都应适当
4.模块的作用域应该在控制域之内
5.力争降低模块接口的复杂程度
6.设计单入口单出口的模块
7.模块功能应该可以预测
第六章
1、详细设计的目的(主要任务)
目的:
为软件系统的H图/SC图中的每一个模块确定采用的算法(处理流程)和模块内数据结构,选定某种表达工具给出精确的描述。
任务:
用一定的工具精确描述目标系统,从而方便在编码阶段可以把这种描述直接翻译成用某种程序设计语言书写的程序。
(1)确定每一模块的算法(处理流程)
(2)确定每一模块使用的局部数据结构
(3)确定本模块的接口和用户界面
(4)为每一模块设计一组测试用例(单元测试计划)
2、结构化程序设计
1、什么是结构化程序设计
(1)如果一个程序的代码块仅仅是通过顺序、选择和循环这3种基本控制结构进行连接,并且每个代码块是单入口、单出口的,则称这个程序是结构化的。
(2)结构化程序设计是尽可能少用GOTO语句的程序设计方法。
最好仅在检测出错误时才使用GOTO语句,而且应该总是使用前向GOTO语句。
(3)如果允许使用LEAVE(或BREAK)结构,则不仅方便而且会使效率提高很多。
LEAVE
或BREAK结构实质上是受限制的GOTO语句,用于转移到循环结构外面的语句。
(4)如果只允许使用顺序、IF-THEN-ELSE型分支和DO-WHILE型循环这3种基本控制结构,则称为经典的结构程序设计;如果除了上述3种基本控制结构之外,还允许使用DO-CASE型多分支结构和DO-UNTIL型循环结构,则称为扩展的结构程序设计;如果再加上允许使用LEAVE(或BREAK)结构,则称为修正的结构化程序设计。
2、结构化程序设计中基本的控制流程
3、详细设计的描述---程序流程图、盒图、PAD图:
什么是,基本符号和含义,画法
1、程序流程图--又称为程序框图,广泛描述过程设计的方法。
基本符号(国家标准)
可表示的控制结构见前图(结构化程序设计中基本的控制流程)。
2、盒图(N-S图)
出于要有一种不允许违背结构程序设计精神的图形工具的考虑,Nassi和
Shneiderman提出了盒图,又称为N-S图。
基本符号和表示的结构
举例
3、PAD图
PAD是问题分析图(problemanalysisdiagram),用二维树形结构的图来表示程序的控制流,将这种图翻译成程序代码比较容易
(a)顺序(先执行P1后执行P2);(b)选择(IFCTHENP1ELSEP2);
(c)CASE型多分支;(d)WHILE型循环(WHILECDOP);(e)UNTIL型循环(REPEAPUNTILC);(f)语句标号;(g)g定义
使用PAD图提供的定义功能来逐步求精的例子
4、在详细设计阶段,软件复杂度主要体现为程序的复杂程度,可用程序模块的环形复杂度(McCabe方法)来度量,或用Halstead方法来度量
5、环形复杂度(McCabe方法)来度量
计算工具:
流图--退化了的程序流程图
McCabe方法根据程序控制流的复杂程度定量度量程序的复杂程度,这样度量出的结果称为程序的环形复杂度。
为了突出表示程序的控制流,人们通常使用流图(也称为程序图)。
所谓流图实质上是
“退化了的”程序流程图,它仅仅描绘程序的控制流程,完全不表现对数据的具体操作以及分支或循环的具体条件。
计算方法:
3种方法
(1)流图中的区域数等于环形复杂度
区域:
由边和结点围成的面积称为区域。
当计算区域数时应该包括图外部未被围起来的那个区域。
即流图的封闭区域数加1。
(2)流图的环形复杂度V(G)=E-N+2,其中,E是流图中边的条数,N是结点数。
(3)流图的环形复杂度V(G)=P+1,其中,P是流图中判定结点的数目。
6、Halstead方法来度量计算方法
Halstead方法是另一个著名的方法,它根据程序中运算符和操作数的总数来度量程序的复杂程度。
计算复杂度的方法:
在图形界面(或Web界面)环境下,尤其是在交互系统的中,一个模块的页面数以及每个页面上的项目数,也是模块复杂程度度量的依据。
第七章
1、编码风格涉及的一系列内容
源程序实际上也是一种供人阅读的文档,有一个文档的风格问题。
应该使程序具有良好的风格。
源程序代码的逻辑简明清晰、易读易懂是好程序的一个重要标准。
①源程序文档化(程序内部的文档)
②数据说明
③语句构造
④输入输出设计
⑤程序的效率
2、单元测试、集成测试、确认/验收测试,测试计划(包括用例)在什么时候书写形成
单元测试:
--模块测试
模块测试的目的是保证每个模块作为一个单元能正确运行,所以模块测试通常又称为单元测试。
在这个测试步骤中所发现的往往是详细设计和编码的错误。
集成测试:
子系统测试局部(模块——>子系统)
子系统测试是按软件结构把经过单元测试的若干模块放在一起形成一个子系统来测试。
模块相互间的协调和通信是这个测试过程中的主要问题,因此,这个步骤着重测试模块间的接口。
系统测试全局(子系统——>完整系统)
系统测试是,按软件结构,把经过测试的若干子系统装配成一个完整的系统来测试。
在
这个过程中不仅应该发现设计和编码的错误,还应该验证系统确实能提供需求说明书中指定的功能,而且系统的动态特性也符合预定要求。
在这个测试步骤中发现的往往是软件设计中的错误,也可能发现需求说明中的错误。
不论是子系统测试还是系统测试,都兼有检测和组装两重含义,通常合称为集成测试。
验收测试--用户参与
验收测试把软件系统作为单一的实体进行测试,测试内容与系统测试基本类似,但是它是在用户积极参与下进行的,而且可能主要使用实际数据(系统将来要处理的信息)进行测试。
验收测试的目的是验证系统确实能够满足用户的需要,在这个测试步骤中发现的往往是系统需求说明书中的错误。
验收测试也称为确认测试。
3、软件测试与调试的目的
软件测试的目的就是在软件投入生产性运行之前,尽可能多地发现软件中的错误。
测试横跨两个阶段:
(1)编写出每个模块之后就对它做必要的测试(称为单元测试)。
(2)
在上一阶段结束之后,对软件系统还应该进行各种综合测试通常由专门的测试人员承担这项工作。
调试就是通过测试发现软件的错误之后改正错误并进行再诊断。
调试是测
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 完整 软件工程 导论 知识点 总结 复习 推荐 文档