收藏 分享(赏)

2009级软件工程复习大纲new.doc

上传人:dzzj200808 文档编号:2287618 上传时间:2018-09-09 格式:DOC 页数:9 大小:108KB
下载 相关 举报
2009级软件工程复习大纲new.doc_第1页
第1页 / 共9页
2009级软件工程复习大纲new.doc_第2页
第2页 / 共9页
2009级软件工程复习大纲new.doc_第3页
第3页 / 共9页
2009级软件工程复习大纲new.doc_第4页
第4页 / 共9页
2009级软件工程复习大纲new.doc_第5页
第5页 / 共9页
点击查看更多>>
资源描述

1、2009 级软件工程学期末考试复习大纲一、 第一章软件工程介绍(1) 何为软件?(2) 软件和硬件不同的特性: 软件是设计开发的,而不是传统意义上生产制造的。 软件不会“磨损” ,但存在退化,硬件失效曲线与软件失效曲线对比 整体向着基于构建的模式发展,但多数仍是按客户需求定制的。(3) 何为软件工程?(IEEE1993 的定义):软件工程是:(1)将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护,即将工程化方法应用于软件。 (2)在(1)中所述方法的研究。二、 第二章过程综述(2) 软件工程是一种层次化技术,其包括质量关注点、过程、方法和工具。(3) 过程框架定义了若干小的框架活动

2、,为完整的软件开发过程建立了基础。 通用过程框架活动包括沟通、策划、建模、构建和部署五种。 过程框架还包含一些适用于各个软件过程的普适性活动。这样活动主要有软件项目跟踪和控制、风险管理、软件质量保证、正式的技术复审、测量、软件配置管理、可复用管理和工作产品的准备和产生。三、 第三章过程模型(1) 软件过程模型是软件开发全部过程、活动和任务的结构框架,也称软件开发模型或软件生存周期模型。 惯例过程模型(又称传统过程模型、严格过程模型) ,强调对过程活动和任务的详细定义、识别和应用。它力求实现结构化和有序。 敏捷过程模型提倡弱化软件过程中过于正式的要求,并将自我组织、协作、沟通和可适应性作为主要原

3、则。 软件过程模型主要有瀑布模型、增量过程模型、演化过程模型和统一过程模型等类型。(2) 瀑布模型 瀑布模型又被称为经典生命周期,它提出了一个系统的、顺序的软件开发方法。它从用户需求规格说明开始,通过策划、建模、构建和部署的过程,最终提供一个完整的软件并提供持续的技术支持。 瀑布模型存在的问题: 缺乏灵活性,难以适应需求不明确或需求经常变化的软件开发,实际的项目很少遵守瀑布模型提出的顺序。 客户必须要有耐心,因为只有在项日接近尾声的时候,他们才能得到可执行的程序。 开发早期存在的问题往往要到交付使用时才发现,维护代价大。(3) 增量过程模型是以增量的形式生产软件产品的过程模型。其包括增量模型和

4、 RAD(快速应用开发)模型 增量模型以迭代的方式运用瀑布模型。随着时间推移,增量模型在每个阶段运用线性序列,每个线性序列生产出一个软件的可交付增量。 增量模型融合了瀑布模型的基本成分(重复地应用)和演化模型的迭代特征。 增量模型强调每一个增量都发布一个可运行的产品。 增量模型能有计划地管理技术风险,如早期增量版本中避免采用尚未成熟的技术。 RAD 模型是一种侧重于短暂的开发周期的增量软件过程模型。RAD 是瀑布模型的高速变体,通过基于构件的构建方法实现快速开发。 RAD 过程模型的建模框架活动主要包括业务建模、数据建模和过程建模。 RAD 模型存在的问题对于大型、可伸缩的项目,RAD 需要大

5、量的人力资源来创建多个相对独立的 RAD 团队。如果开发者和客户没有为短时间内急速完成整个系统做好准备,RAD 项目将会失败。如果一个系统不能合理地模块化,RAD 构件建立会有很多问题。如果系统需求是高性能,并且需要通过调整构件接口的方式来提高性能,不能采用RAD 模型。 技术风险很高的情况下,不宜采用 RAD 模型。(4) 演化过程模型演化模型是迭代的过程模型,使得软件工程师能够逐步开发出更完整的软件版本。其主要有原型模型和螺旋模型两种。 原型模型的主要特点快速制订原型开发的计划、快速建模和快速构建原型应交付给客户试用,并收集反馈意见,改进原型 螺旋模型结合了原型的迭代性质和瀑布模型的系统性

6、和可控性特点。随着演进过程的开始,从圆心开始顺势针方向,执行螺旋上的一圈表示的活动。每次演进都要考虑风险,每个演进过程都要标记里程碑。螺旋模型应用在计算机软件的整个生命周期。是开发大型系统的理想方法,可以有效的应对风险。 螺旋模型的特点:可应用在计算机软件的整个生命周期是开发大型系统和软件的理想方法把原型开发作为降低风险的机制(5) 统一过程(UP)是一种“用例驱动、以架构为核心,迭代并却增量”的软件过程。其包括并发进行的起始、细化、构建、转化和生产 5 个阶段。 起始阶段包括沟通和策划,定义软件的需求,提出系统的大致框架,并制定开发计划,以保证开发具有迭代和增量的特性。 细化阶段包括沟通和建

7、模活动。细化阶段扩展了起始阶段定义的用例,并扩展体系结构以包括软件的 5 种视图:用例模型、分析模型、设计模型、实现模型和部署模型。 构建阶段于通用软件过程中的构建活动相同,构建采用体系结构模型作为输入,开发系统构建,使最终用户能够操作用例。 转化阶段包括通用构建活动的后期活动以及部署活动。软件被提交最终用户进行 beta测试,并发布支持信息(手册、问题解决指南及安装步骤) 。转换阶段结束时,软件增量称成为可用的发布版本。 生产阶段和通用过程的部署活动一致。在该阶段,监控软件持续使用,提供运行环境的支持,提交缺陷报告和变更请求。四、 第四章敏捷视角下的软件过程(1) 敏捷联盟的 12 条原则

8、尽早交付有价值的软件来让顾客满意。 在后期也欢迎变更,利用变更来为客户创造竞争优势。 交付的时间间隔越短越好。 业务人员和开发人员必须天天在一起。 围绕受激励的个人构建项目。 最有效的信息传递方式是面对面交谈。 可工作软件是进度的首要度量标准。 提倡可持续的开发速度。 关注优秀的技能和好的设计。 简单是必要的。 好的架构和设计出自于自组织团队。 每隔一定时间,反省工作,调整行为。(2) 建立敏捷过程的三个关键性假设 提前预测哪些需求是稳定的和哪些需求会变化非常困难。 对很多软件来说,设计和构建是交错进行的。 从制定计划的角度来看,分析、设计、构建和测试并不像我们所设想的那么容易预测。(3) 极

9、限编程(eXtreme Programming, 简称 XP)是一种常用的敏捷过程。它使用面向对象方法作为推荐的开发范型。XP 包括策划、设计、编码和测试 4 个框架活动。 策划活动开始于建立一系列描述待开发软件必要特征与功能的“故事” ,XP 团队成员评估每一个故事并给出以开发周数为度量单位的成本。 设计严格遵循 KIS 原则,适用简单而不是复杂的表述 。鼓励适用 CRC 卡来组织相关的对象和类,鼓励重构。 编码一个关键概念是结对编程。两个人面对同一台计算机共同为一个故事开发代码。实施中两个人担当的角色略有不同。 测试。在编码开始之前建立单元测试是 XP 的关键因素,所建立的单元测试应当适用

10、一个可以自动实施的框架,易于重复执行,这种方式支持代码修复后的回归测试策略。五、 第六章系统工程(1) 基于计算机的系统是组织在一起通过处理信息来实现预定目标的要素集合或排列。它由软件、硬件、人员、数据库、文档和规程六个要素组成。(2) 系统工程过程在不同应用领域有不同的表现形式 业务过程工程:集中于某业务企业 产品工程:关注产品生产的过程(3) 可以按照全局视图、领域视图、要素视图和详细视图的层次来理解系统或产品。(4) 在业务目标和目的的环境中,必须分析和设计数据架构、应用架构和基础设施三种不同的架构。六、 第七章需求工程(1) 需求工程是一个软件工程动作,始于沟通并持续到建模。(2) 需

11、求工程为以下工作提供了良好的机制:理解用户需要什么、分析要求、评估可行性、协商合理的方案、无歧义的详细说明方案、确认规格说明。(3) 需求工程过程通过执行起始、导出、精化、协商、规格说明、确认和管理七个不同的活动来完成。 在起始阶段,软件工程师会询问一些似乎与项目无直接关系的问题,以建立基本的谅解。 导出需求面临范围问题、理解问题和易变问题。导出需求的主要有协同需求收集、质量功能部署和用户场景三种方法。 精化阶段开发精确的技术模型用以说明软件的功能、特征和约束。精化的最终结果是形成一个分析模型,该模型定义了问题的信息域、功能域和行为域。 通过协商过程来调解客户/最终用户提出的过高要求和需求冲突

12、。 规格说明是需求工程师完成的最终工作产品。它将作为软件工程师后续活动的基础,它描述了一个基于计算机系统的功能和特性,以及那些将影响系统开发的约束。 在确认阶段将对需求工程的工作产品进行质量评估。确认需求时需要检查需求模型的一致性、是否有遗漏以及歧义性。正式技术评审是最主要的需求确认机制。 需求管理用于帮助项目组在项目进展中标识、控制和跟踪需求以及变更需求的一组活动。(4) 质量功能部署(QFD)是一种将客户要求转化为软件技术的技术。QFD 目的是最大限度的让客户从软件工程中感到满意。它确认三类需求:正常需求、期望需求、令人兴奋的需求。(5) 需求工程导出的工作产品包括七种:必要性和可行性陈述

13、、系统或产品范围的说明、客户/用户及共利益者的列表、系统技术环境的说明、需求列表及每个需求适用的领域限制、 、一系列适用场景和任何能够更好定义需求的原型。(6) 分析模型应为基于计算机的系统提供必要的信息、功能和行为域的说明。分析模型主要包括基于场景的元素、基于类的元素、行为元素和面向信息流的元素。七、 第八章构建分析模型(1) 分析模型使用文字和图表的综合形式以相对容易理解的方式描绘需求的数据、功能和行为。更重要的是可以更直接的评审它们的正确性、完整性和一致性。(2) 分析模型必须实现的三个主要目标:描述客户需要什么、为软件设计奠定基础、定义在软件完成后可以被确认的一组需求。分析模型在系统描

14、述和设计模型之间建立桥梁。(3) 分析建模的方法主要有面向对象分析和结构化分析两种。前者关注于定义类和影响客户需求的类之间的协作方式。而后者则考虑数据和数据处理的分析建模方法。(4) 基于场景的建模从用户的角度表现系统;面向流的建模在说明数据对象如何通过处理函数进行转换方面提供了指示;基于类的建模定义了对象、属性和关系;行为建模描述了系统状态、类和事件在这些类上的影响。 基于场景的模型从用户的角度描述软件需求。用例是主要的建模元素,还可以适用活动图说明场景,泳道图显示了处理流如何分配给不同的用户。 面向流的建模,常常使用 DFD(数据流图) 。它开始于环境图,结束于模块规格说明。 在基于类的建

15、模型中,按职责划分可将类分为实体类、控制类和边界类三种。CRC(类 -职责- 协作)提供了一个简单的方法,可以识别和组织与系统或产品需求相关的类。CRC 卡片被分为三部分,顶部写类名,下面左侧列出类的职责,右侧部分列出类的协作关系。 可以运用 UML 的状态图和顺序图进行行为建模。八、 第九章设计工程(1) 软件设计是软件工程过程的技术核心,它开始于需求分析和需求建模完成之后。设计模型提供了数据/类设计、体系结构设计、接口设计和构件设计的细节。(2) 软件设计工程中,进行数据/类设计、体系结构设计、接口设计和构件设计的目的 数据/类设计:将分析类模型转化为设计类的实现以及软件实现所要求的数据结

16、构。 体系结构设计:定义软件的主要结构元素之间的联系、可用于达到系统所定义需求的体系结构风格和设计模式以及影响体系结构实现方式的约束。 接口设计:描述软件和协作系统之间、软件和使用人员之间是如何通信的。 构件设计:将软件体系结构的结构元素变换为对软件构件的过程性描述。(3) HP 公司开发了软件质量属性 FURPS: 功能性(Functionality ):评估程序的特征集和能力、所提交功能的普遍性以及整个系统的安全性。 易用性(Usability ):通过考虑人为因素、整体美感、一致性和文档来评估。 可靠性(Reliability):通过测量故障的频率和严重性、输出结果的精确性、故障平均时间

17、、故障恢复能力和程序的可预见性来评估。 性能(Performance) :度量处理速度、响应时间、资源消耗、吞吐量和效率。 可支持性(Supportability ) :综合了可扩展性、适应性和耐用性三面的能力。(4) 抽象是人类处理复杂问题的基本方法之一,主要有数据抽象和过程抽象两种。(5) 软件体系结构是程序构件(模块)的结构或组织、这些构件交互的形式以及这些构件所使用数据的结构。体系结构设计可以使用结构模型、功能模型、动态模型、过程模型和框架模型来表示。(6) 模式(Pattern)是解决某一类问题的方法论,它将解决某类问题的方法总结归纳到理论高度。软件模式主要有分析模式、体系结构模式、

18、设计模式和编码模式(又称习惯用语)四种。(7) 模块化是将软件被划分为独立命名的、可寻址的构件(又被称为模块) ,把这些构件集成到一起可以满足问题的需求。(8) 信息隐蔽原则建议模块应该具有的特征是:每个模块对其他所有模块都隐蔽自己的设计决策。(9) 通过开发具有“专一”功能和“ 避免” 与其他模块过多交互的模块,可以实现功能独立。独立性可以使用内聚性(显示模块相关功能的强度)和耦合性(显示模块间的相互依赖性)两条定性的标准评估。(10) 求精是一个细化的过程,它和抽象是互补的概念。(11) 重构是在不改变代码(或设计) 的外部行为的前提下,改进软件系统内部结构的过程。通过重构提高模块的内聚性

19、,降低模块间的耦合性,在实施重构前,保证已有足够的测试用例,以在重构之后进行回归测试。(12) 在设计模型通常定义了用户接口类、业务域类、过程类、持久类和系统类五种不同的设计类。良定义设计类的四个特征是完整性与充分性、原始性、高内聚和低耦合。(13) 基于模式的设计可以复用那些在过去已经被证明是成功的设计元素。在针对某个特定的应用进行评估时,应将每个体系结构模式、设计模式或习惯用语分类、全面文档化和细致的考虑。框架作为模式的扩展,为某个特定领域内完整的子系统设计提供体系结构骨架。九、 第十章进行体系结构设计(1) 软件体系结构的作用是:分析设计在满足需求方面的有效性、在设计变更相对容易的阶段,

20、考虑体系结构可能的选择方案、降低与软件构造相关联的风险。(2) 体系结构风格是一种加在整个系统设计上的变换,其目的在于为系统的所有的构件建立一个结构。通常分为:以数据为中心的体系结构、数据流体系结构、调用和返回体系结构、面向对象体系结构和层次体系结构五种风格。(3) 软件的体系结构模式定义了处理系统某些行为特征的方法。体系结构模式域包括并发性、持久性、分布性。(4) 软件体系结构的设计步骤:系统的环境表示、定义原始模型、将系统结构精化为构件、描述系统实例。(5) 传统的结构化设计需要映射变换流和事务流两种数据流到软件体系结构。十、 第十一章构件级设计建模(1) 构件是系统中某一定型化的、可配置

21、的和可替换的部件,该部件封装了实现并暴露一系列接口。构件级设计定义了数据结构、算法、接口特征和分配给每个软件构件的通信机制。(2) 基于类的构件基本设计原则: 开关原则:模块对外延具有开放性,对修改具有封闭性。 LISKOV 替换原则(或里氏替换原则):子类可以替换它们的基类。 依赖倒置原则:依赖于抽象,而非具体实现。 接口分离原则:多个用户专用接口比一个通用接口要好。 发布复用等价性原则:复用的粒度就是发布的粒度。 共同封装原则:一同变更的类应该合在一块。 共同复用原则:不能一起复用的类不能被分到一组。(3) 内聚性意味着构件或者类只封装那些相互关联密切,以及与构件或类自身有密切关系的属性和

22、操作。按从强到弱排序内聚性:功能内聚、分层内聚、通信内聚、顺序内聚、过程内聚、暂时内聚、实用内聚。(4) 藕合是类之间彼此联系程度的一种定性度量。按从强到弱排序耦合性:内容藕合、共用耦合、控制耦合、印记耦合、数据耦合、例程调用耦合、类型使用耦合、包含或者导入耦合、外部耦合。(5) 模块的高内聚和低藕合是构件设计建模的重要目标。(6) 传统构件的设计常用表示方法有图形化设计表示(程序流程图、N-S 图) 、表格式设计表示(决策表:条件、动作、条件组合和处理规则)和程序设计语言(PLD)。十一、 第十三章构件测试策略(1) 软件测试策略将软件测试用例的设计方法集成到一系列经周密计划的步骤中去,从而

23、使软件构造成功地完成。任何测试策略都必须包含测试计划、测试用例设计、测试执行以及测试结果数据的收集与评估。(2) 传统软件的测试策略是将测试分为单元测试、集成测试、确认测试和系统测试。 单元测试是针对程序中的模块或构件,主要揭露编码阶段产生的错误。 集成测试针对集成的软件系统,主要揭露设计阶段产生的错误。 确认测试是根据软件需求规约对集成的软件进行确认,主要揭露不符合需求规约的错误。 系统测试是针对基于计算机系统中的软件,以揭露不符合系统工程中对软件要求的错误。(3) 单元测试的主要内容包括:模块接口、局部数据结构、边界条件、所有独立路径和所有错误处理路径。在单元测试中,每个被测模块开发一个驱

24、动(driver)程序和若干个桩(stub)模块。(4) 集成测试通常采用增量方式,其主要有自顶向下集成和自底向上集成方法。 自顶向下集成的优缺点: 优点:不需要驱动模块;能尽早对程序的主要控制和决策机制进行检验,能较早发现整体性的错误;深度优先的自顶向下集成能较早对某些完整的程序功能进行验证。 缺点:测试时低层模块用桩模块替代,不能反映真实情况;重要数据不能及时回送到上层模块。 自底向上集成的优缺点: 优点 :不需要桩模块,所以容易组织测试;将整个程序结构分解成若干个簇,对同一层次的簇可并行进行测试,可提高效率。 缺点:整体性的错误发现得较晚。(5) 回归测试是对已进行过的测试的子集的重新执

25、行,以确保对程序的改变和修改,没有传播非故意的副作用。回归测试集(已经过测试的子集)包括三种不同类型的测试用例: 能测试软件所有功能的代表性测试用例 专门针对可能会被修改影响的软件功能的附加测试 注重于修改过的软件模块的测试(6) 冒烟测试是一种常用的集成测试方法,它让软件团队频繁地对项目进行评估。冒烟测试提供了下列好处: 降低了集成风险 提高最终产品的质量 简化错误的诊断和修正(7) 测试和 测试是确认测试的两种常用方法。 测试是由用户在开发者的场所进行的,软件在开发者对用户的“指导下”进行测试。经 测试后的软件称为 版软件。 测试是由软件的最终用户在一个或多个用户场所进行的,与 测试不同,

26、开发者通常不在测试现场。(8) 系统测试是对整个基于计算机的系统进行的一系列测试。常用的系统测试主要包括:恢复测试、安全测试、压力测试和性能测试。(9) 测试的目的是发现错误,调试(也称排错)的目的是确定错误的原因和准确位置,并加以纠正。调试的方法主要有蛮力法、回溯法和原因排除法。十二、 第十四章构件测试战术(1) 软件测试是一个为了发现错误而执行程序的过程,软件测试的目标是用尽可能少的测试用例,来发现尽可能多的软件错误。(2) 软件测试方法主要有白盒测试方法和黑盒测试(又称行为测试)方法。前者主要根据程序内部的逻辑结构设计测试用例,而后者则主要根据程序完成的功能设计测试用例。(3) 白盒测试

27、的目标: 对每一个模块中的所有独立路径至少被执行一次 对所有的逻辑值均需测试真和假 在上下边界和可操作的范围内执行所有的循环 检验内部数据结构以确保其有效性(4) 黑盒测试能发现以下类型的错误 功能不正确或遗漏 接口错误 数据结构或外部数据库访问错误 行为或性能错误, 初始化和终止错误。(5) 常用的白盒测试方法有:逻辑覆盖测试、基本路径覆盖测试、数据流测试和循环测试(6) 逻辑覆盖主要考察使用测试数据运行被测程序时对程序逻辑的覆盖程度。逻辑覆盖测试主要包括语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖和路径覆盖。(7) 基本路径测试是 Tom McCabe 提出的一种白盒测试技术,

28、其设计过程为: 首先根据程序或设计图画出控制流图 计算其区域数,确定一组独立的程序执行路径(称为基本路径) 为每一条基本路径设计一个测试用例。(8) 常用的黑盒测试方法有:基于图的测试方法、等价划分、边界值分析、正交数组测试。十三、 备注(1) 考试题型:单项选择、判断、简答和应用题。(2) 简答题大致范围: 什么是软件工程? 软件工程是一种层次化技术,其包括哪些内容? 通用过程框架包括哪些活动? 通用过程框架包括哪些普适性活动? 简述 UP 的三大特点及其五个阶段。 基于计算机的系统是由哪六个要素构成的? 通常需求工程过程通过执行哪七个不同的活动来完成? 分析模型主要包括哪四大类元素?分析模

29、型应提供哪三大域的说明。 简述软件设计工程中主要进行哪四种设计,它的作用分别是什么。 HP 公司开发了哪五种软件质量属性? 设计模型通常定义了哪五种不同的设计类?良定义设计类的四个特征是什么? 列举五种常见的软件体系结构风格。 基于类的构件基本设计原则有哪些? 简述自顶向下集成方法和自底向上集成方法的优缺点? 请列举出白盒测试和黑盒测试的主要方法?(3) 应用题范围 根据需求描述,运用 UML 绘出用例图(注意角色之间、用例之间关系) 、分析类图(类之间泛化、关联。不需要确定关联的方向,但要注明关联的多重性) 基本路径测试用例的设计。 由给出的程序流程,绘出流图 由流图计算出计算程序复杂度,即区域数,也即基本路径数目。 确定基本路径的集合 设计基本路径覆盖的测试用例 黑盒测试的等价类方法

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 大学课件

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报