华南农业大学15年软件工程复习提纲.doc

2015《软件工程》复习提纲
一、试卷的分值分布如下：判断题10分、选择题10分、名词解释和简答题50分、测试用例设计10分、结构化分析与设计20分。大题里面，测试用例设计的白盒方法考逻辑覆盖中的某种，黑盒方法考等价类法；结构化分析与设计则重点考察数据流图、数据字典、加工规约、数据库分析设计等。
二、去年试题老师已经提供，此处不在给出。
三、主要知识点如下：
1. 软件的概念
计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合。

2. 软件发展的3个阶段（时间、标志、开发（组织）的方式）
1946-1956 计算机问世到高级程序语言出现前
1956-1968 高级程序语言出现到软件工程出现前
1968-至今 软件工程出现到现在

3. 软件的特点 vs 硬件
①软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性。
②软件是通过人们的智力活动，把知识与技术转化成信息的一种产品，是在研制、开发中被创造出来的。
③在软件的运行和使用期间，没有硬件那样的机械磨损、老化问题。
④软件的开发和运行经常受到计算机系统的限制，对计算机系统有着不同程度的依赖性。
⑤软件的开发至今尚未完全摆脱手工的开发方式。
⑥软件的开发费用越来越高，成本相当昂贵。

4. 软件的分类
（1）系统软件、支持软件、应用软件
（2）按工作方式划分：
实时处理软件，分时软件，交互式软件，批处理软件。
（3） 按软件服务对象划分：
项目软件，产品软件。
（4）按使用的频度进行划分
一次使用，频繁使用。
（5）按软件失效的影响进行划分
高可靠性软件，一般可靠性软件。

5. 软件工程的定义
是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。

6. 软件生存周期的概念及若干个阶段
一个软件从定义到开发、使用和维护，直到最终被弃用，要经历一个漫长的时期，通常把软件经历的这个漫长的时期称为生存周期。
软件生存周期一般可分为以下阶段：
·问题定义
·需求分析与可行性研究
·设计
·编码
·测试
·运行与维护

7. 瀑布模型

特征:
接受上一阶段的结果作为本阶段的输入
利用这一输入实施本阶段应完成的活动
对本阶段的工作进行评审
将本阶段的结果作为输出，传递给下一阶段。
优点：
可强迫开发人员采用规范的方法。
严格地规定了每个阶段必须提交的文档。
要求每个阶段的所有产品都必须经过质量保证小组的仔细验证。
缺点:
Ø 缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发。
Ø 开发早期存在的问题往往要到交付使用时才发现，维护代价大。

8. 演化模型
许多软件项目在开发早期对软件需求的认识是模糊的、不确定的，因此软件很难一次开发成功
可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，称之谓原型（prototype），然后根据用户在试用原型的过程中提出的意见和建议、或者增加新的需求，对原型进行改造，获得原型的新版本，重复这一过程，最终得到令客户满意的软件产品
演化模型的开发过程就是从构造初始的原型出发，逐步将其演化成最终软件产品的过程
演化模型适用于对软件需求缺乏准确认识的情况
典型的演化模型有：增量模型、原型模型、螺旋模型

9. 增量模型
增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一个版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。
增量模型融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征。
增量模型强调每一个增量都发布一个可运行的产品。
增量模型特别适用于：
Ø 1.需求经常变化的软件开发
Ø 2.市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发。
增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术。

10. 原型与原型模型
原型（prototype）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。

原型的类型：
1.探索型（exploratory prototyping）
目的是要弄清目标系统的要求，确定所希望的特性，并探讨多种方案的可行性
2.实验型（experimental prototyping）
目的是验证方案或算法的合理性，它是在大规模开发和实现前，用于考核方案是否合适，规格说明是否可靠
3.演化型（evolutionary prototyping）
目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统.

原型的使用策略：
1.废弃（throw away）策略
主要用于探索型和实验型原型的开发。这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统
Ø 2.追加（add on）策略
主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统

原型可作为单独的过程模型使用，它也可作为一种方法或实现技术应用于其它的过程模型中

11. 螺旋模型

是瀑布模型和演化模型的结合，并增加了风险分析
螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动，即：
1.制定计划：确定软件目标，选定实施方案，弄清
项目开发的限制条件
2.风险分析：评价所选的方案，识别风险，消除风
险
3.工程实施：实施软件开发，验证工作产品
4.客户评估：评价开发工作，提出修正建议

螺旋模型出现了一些变种，它可以有3到6个任务区域
螺旋模型指引的软件项目开发沿着螺线自内向外旋转，每旋转一圈，表示开发出一个更为完善的新软件版本
如果发现风险太大，开发者和客户无法承受，则项目就可能因此而终止
多数情况下沿着螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统

12. 组成基于计算机的系统由哪些元素组成
软件、硬件、人员、数据库、文档和规程

13. 系统工程的任务
定义：计算机系统工程是一个问题求解的活动，其目的是分析基于计算机的系统的功能、性能、等要求，并把它们分配到基于计算机系统的各个系统元素中，确定它们的约束条件和接口
任务：识别用户的要求
标识系统的功能和性能范围，确定系统的功能、性能、约束和接口

14. 可行性分析
开发一个基于计算机的系统通常都受到资源（人力、财力、设备等）和时间上的限制，可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成
可分为：经济可行性分析，技术可行性分析，法律可行性分析

15. 需求工程的概念
需求工程师应用已证实有效的技术与方法开展需求分析，确定客户需求，帮助分析人员理解问题，评估可行性，协商合理的解决方案，无歧义地规约方案，确认规约以及将规约转换到可运行的系统时的管理需求。

16. 需求工程的六个阶段
需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理

17. 软件需求的定义
软件需求是指用户对目标软件系统在功能，行为，性能，设计约束等方面的期望。

18. 需求获取的方法与策略
1. 建立需求获取人员（通常被称为系统分析员）与用户顺畅的通信途径
2. 与客户交谈，向用户提问题，通过访谈与会议
3. 观察用户工作流程，观察用户的操作
4. 组成联合小组
5. 实例分析

19. 常用的需求分析方法
面向数据流的结构化分析方法 (SA)
面向数据结构的分析方法
面向对象的分析方法 (OOA)

20. 软件的需求规约主要包含哪些内容
引言：陈述软件目标，在基于计算机的系统语境内 进行描述。
信息描述：给出软件必须解决问题的详细描述，记 录信息内容和关系、流和结构。
功能描述：描述解决问题所需的每个功能。其中包 括，为每个功能说明一个处理过程；叙述设计约 束；叙述性能特征；用一个或多个图形来形象地表 示软件的整体结构和软件功能与其他系统元素间的 相互影响。
行为描述：描述作为外部事件和内部产生的控制特 征的软件操作。
检验标准：描述检验系统成功的标志。即对系统进 行什么样的测试，得到什么样的结果，就表示系统 已经成功实现了。它是“确认测试”的基础。
参考书目：包含了对所有和该软件相关的文档的引 用，其中包括其他的软件工程文档、技术参考文献、 厂商文献以及标准。
附录：包含了规约的补充信息，表格数据、算法的 详细描述、图表以及其他材料。

21. 软件设计的任务（注意在回答接口设计的时候，需要讲清楚3个方面的内容）
使用一种设计方法，软件分析模型中通过数据、功能和行为模型所展示的软件需求的信息被传送给设计阶段，产生数据/类设计、体系结构设计、接口设计、部件级设计。
（接口设计主要包括三个方面：–设计软件模块间的接口–设计模块和其他非人的信息生产者和消费者(比如外部实体)之间的接口–设计人(用户)和计算机间的接口）

22. 软件设计的目标
(1)设计必须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式需求。
(2)设计必须是可读、可理解的，使得将来易于编程、易于测试、易于维护。
(3)设计应从实现角度出发，给出与数据、功能、行为相关的软件全貌。

23. 衡量软件设计的技术标准
(1) 设计出来的结构应是分层结构，从而建立软件成份之间的控制。
(2) 设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的部件。
(3) 设计应当既包含数据抽象，也包含过程抽象。
(4) 设计应当建立具有独立功能特征的模块。
(5) 设计应当建立能够降低模块与外部环境之间复杂连接的接口。
(6) 设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。

24. 软件设计的过程
(1) 制定规范
(2) 体系结构和接口设计
(3) 数据/类设计
(4) 部件级（过程）设计
(5) 编写设计文档
(6) 设计评审

25. 数据抽象与过程抽象
过程抽象（也称功能抽象）是指任何一个完成明确定义功能的操作都可被使用者当作单个实体看待，尽管这个操作实际上是由一系列更低级的操作来完成的。
数据抽象是指定义数据类型和施加于该类型对象的操作，并限定了对象的取值范围，只能通过这些操作修改和观察数据。

26. 模块
模块是数据说明、可执行语句等程序对象的集合，它是单独命名的，并且可以通过名字来访问。

27. 信息隐藏的概念
每个模块的实现细节对于其它模块来说应该是隐蔽的
块中所包含的信息（包括数据和过程）不允许其它不需要这些信息的模块使用
通过信息隐蔽，则可定义和实施对模块的过程细节和局部数据结构的存取限制

28. 内聚与耦合的概念
内聚（cohesion）是一个模块内部各个元素彼此结合的紧密程度的度量
耦合(coupling)是模块之间的相对独立性（互相连接的紧密程度）的度量

29. 功能内聚的概念
功能内聚 ：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的。

30. 数据耦合的概念
数据耦合：两个模块之间仅通过参数表传递简 单数据，则称为数据耦合。

31. 调用和返回风格的体系结构
这种风格使一个软件设计者设计出非常容易修改和扩充的体系结构。
包含：主程序/子程序风格体系结构 和 远程过程调用风格的体系结构

32. 部件级设计阶段的主要工作
⑴为每个部件确定采用的算法，选择某种适当的工具表达算法的过程，编写部件的详细过程性描述；
⑵确定每一部件内部使用的数据结构；
⑶在部件级设计结束时，应该把上述结果写入部件级设计说明书，并且通过复审形成正式文档，作为下一阶段（编码阶段）的工作依据。

33. 设计规约主要包含哪些内容
1. 工作范围
2. 体系结构设计
3. 数据设计
4. 接口设计
5. 各部件的过程设计
6. 运行设计
7. 出错处理设计
8. 安全保密设计
9. 需求/设计交叉索引
10. 测试部分
11. 特殊注解
12. 附录

34. 结构化分析与设计（一整章内容）
一种较为流行的定义是：“如果一个程序的代码块仅仅通过顺序、选择和循环这三种基本控制结构进行连结，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的”。 历史上克努特争论过这个问题
随着面向对象和软件复用等新的软件开发方法和技术的发展，更现实、更有效的开发途径可能是自顶向下和自底向上两种方法有机的结合。

35. 结构化分析模型有哪些
实体-关系图，数据流图，数据字典，状态转换图，控制规约，加工规约，数据对象描述

36. 系统响应时间的概念
系统响应时间指从用户执行某个控制动作（如按回车键或点鼠标）到软件作出响应（期望的输出或动作）的时间。系统响应时间长会使用户感到不安和沮丧。稳定的响应时间（如1秒）比不定的响应时间如0.1秒到2.5秒）要好。

37. 人机界面设计时的常见问题有哪些
系统响应时间，用户求助设施（user help facilities），错误信息处理，命令标记（command labeling）

38. 人机界面设计的黄金原则是什么
让用户拥有控制权
减少用户的记忆负担
保持界面一致

39. 可用性与可用性测试
可用性指的是产品的使用效率、易学性和舒适程度。
可用性测试：对界面进行可用性测试和评价是确保产品可用性的重要手段，通过各种可用性测试及早发现界面存在的可用性问题，不仅可以节约开发成本，提高产品的品质，还可以降低用户使用产品的心理负荷，减少操作错误，提高工作效率以及对产品的认可度和满意度。
在进行可用性测试前，设计者需要制订出具体详细的测试计划，包括任务列表、主观满意标准以及所要询问的相关问题。同时，必须确定参与测试的用户数目、类型和来源。
可用性测试可以要求用户完成一系列任务，对用户的完成过程进行记录，再对记录进行评审。这可以给设计人员很大的启发，及时发现缺陷并改正。
局限性：首先，它强调的是首次使用的情况，其次只能涉及到部分的界面。因为可用性测试不能延续太长时间，很难确定长时间使用后的情况。

40. 标识符命名需要注意的问题
1.选择含义明确的名字，使其能正确提示标识符所代表的实体
Þ 例如，表示总量的变量名用Total，表示平均值的用Average等
2.名字不要太长，太长会增加打字量，且易出错。必要时可使用缩写
3.不用相似的名字，相似的名字容易混淆，不易发现错误
Þ 如cm,cn,cmn,cnm,cnn,cmm

41. 序言性注释
通常置于每个程序模块的开头部分，
主要描述：
§ 1.模块的功能
§ 2.模块的接口：包括调用格式、参数的解释、该模块需要调用的其它子模块名
§ 3.重要的局部变量：包括用途、约束和限制条件
§ 4.开发历史：包括模块的设计者、评审者、评审日期、修改日期以及对修改的描述

42. 书写功能性注释需要主要哪些问题
1.注解要正确，错误的注解比没有注解更坏；
2.为程序段作注解，而不是为每一个语句作注解；
3.用缩进和空行，使程序与注释容易区分；
4.注解应提供一些从程序本身难以得到的信息，而不是语句的重复。

43. 编写程序时，对数据说明应该注意哪些问题
1.数据说明的次序应当规范化
2.说明语句中变量安排有序化
3.使用注解说明复杂数据结构

44. 测试用例的概念
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

45. 测试目的
发现软件中的错误和缺陷，并加以纠正。

46. 白盒测试与黑盒测试的概念
白盒测试（又称为结构测试）把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作
黑盒测试（又称行为测试）把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需求

47. 白盒测试方法及测试用例设计
逻辑覆盖测试
逻辑表达式错误敏感的测试
基本路径测试
数据流测试
循环测试

48. 黑盒测试方法及测试用例设计
等价类划分
边界值分析
比较测试
错误猜测
因果图

49. 各种逻辑覆盖准则以及它们之间的关系
语句覆盖
判定覆盖
条件覆盖
判定/条件覆盖
条件组合覆盖
路径覆盖

50. 基本路径测试
51. 独立路径的概念

52. 测试V模型中四类测试的对象、依据和任务分别是什么
系统工程————系统测试
需求分析————确认测试
设计————集成测试
编码————单元测试

53. 测试完成的标准
1.如果一个在按照概率的方法定义的环境中，1000个CPU小时内不出错运行的概率大于0．995的话，那么我们就有95%的信心说，我们已经进行了足够的测试”
2.使用指定的测试用例设计方法产生测试用例，运行这些测试用例均未发现错误（包括发现错误后已被纠正的情况），则测试可终止
3.观察测试阶段中单位时间内发现错误数目的曲线

54. 调试的目的及调试过程
调试（也称排错）的目的是确定错误的原因和准确位置，并加以纠正
过程：
1. 找到错误的原因和位置，则将其改正，并进行回归测试，以确保这一改正未影响其他正常的功能
2. 未找到错误的原因和位置，此时应假设错误的原因，并设计测试用例来验证此假设，重复这一过程直至找到错误的原因，并加以改正。

55. 软件维护的定义
是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程

56. 纠错性维护
为了改正软件系统中的错误，使软件能够满足预期的正常运行状态的要求而进行的维护

57. 适应性维护
为了使软件适应内部或外部环境变化，而去修改软件的过程

58. 改善性维护
满足使用过程中用户提出增加新功能或修改已有功能的建议维护

59. 预防性维护
为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础而修改软件的活动

60. 提高可维护性的方法
1. 确定质量管理目标和优先级
2. 使用提高软件质量的技术与工具
3. 选择可维护性高的程序设计语言
4. 完善程序文档
5. 进行质量保证审查