第一章 软件工程概述
一、软件的定义和特性 (P2—P3)
定义：软件=程序+数据+文档
程序：按照事先设计的功能和性能要求执行的指令或语句序列
数据：程序能正常操纵信息的数据结构
文档：描述程序操作和使用的文档
特性：
（1） 软件是一种逻辑实体，具有抽象性，不是一般的物理实体；
（2） 软件的成产与硬件存在某些相同点，但有根本上的不同，软件开发是人的智力的高度发挥，而不是传统意
义上的制造，它更依赖于开发人员的素质，智力，人员和组合，合作和管理；
（3） 软件维护与硬件维修有着本质的差别，软件维护没有硬件维护那样有可替换的标准零件；
（4） 软件在运行和使用期间没有硬件那样的机械磨损，老化问题，但存在退化问题；
（5） 基于构件的开发方法由于其自身的特点越来越受到人们的重视，这些技术可以减少开发时间、提高质量，
并提高复用水平。
* 掌握P4图1-2（b）软件失效率曲线
二、计算机软件的发展经历了几个阶段？各有何特征？（P1—P2）
共经历了四个阶段
特征：第一阶段——程序规模小且主要采用个体工作方式，开发的系统大多采用批处理技术
第二阶段——引入人机交互的概念，实时系统出现，产生了第一代数据库管理系统，程序编制采用了合作
的工作方式，出现了早期的软件危机
第三阶段——分布式系统出现，嵌入式系统得到广泛应用，低成本硬件
第四阶段——强大的桌面系统和计算机网络迅速发展时期，面向对象技术得到广泛应用，人工智能技术和
专家系统开始应用于软件。
三、什么是软件危机？其产生的原因是什么？
定义：软件危机是指由于落后的软件生产方式无法满足迅速增长的计算机软件应用需求，从而导致软件开发与维
护过程中出现一系列严重问题的现象。（P4）
原因：（P5）
（1） 用户对软件需求的描述不准确、不全面，甚至有错误，以及在开发过程中，不断提出或者修改需求；
（2） 用户和开发人员对软件需求的理解存在差异，导致所开发的软件产品和用户需求不一致；
（3） 大型软件项目需要组织一定的人力共同完成，各类人员的信息交流不及时、不准确，有时还可能产生误解，
软件开发人员对大型软件缺少开发经验，管理人员缺少相应的管理经验；
（4） 软件开发人员不能有、独立自主的处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误；
（5） 开发技术落后，缺乏有效的方法学和工具方面的支持，过分依赖程序设计人员在软件开发过程中的技巧和
创造性，加剧软件产品的个性化
（6） 软件产品的特殊性和人类智力的局限性，导致人们无法处理“复杂问题”，因为软件是逻辑产品，软件开发
进展情况较难衡量、软件开发质量难以评价、管理和控制软件开发过程相当困难。
四、什么是软件工程？它的目标和内容是什么？
定义：将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中，
并对方法的研究。（P6）
目标：在给定的成本和进度前提下，开发出具有可修改性、可理解性、可维护性、有效性、可靠性、可适用性、
可重用性、可移植性、可跟踪性和互操作性并且满足用户需求的软件产品。（P7）
内容：主要内容包括软件开发技术和软件工程管理两方面。（P6）
要素：方法，工具，过程
五、什么是软件生存周期？它有哪几个活动？
定义：（software life cycle）把软件产品从形成概念开始，经过定义、开发、使用和维护直到最后退役的全过程。 活动：软件定义、软件开发、软件使用维护和退役（P9）
六、什么是软件生存周期模型？它有哪些主要模型？
定义：又称为软件开发模型，软件过程模型，它清晰直观地反映了软件开发的全部过程、所涉及的活动和任务结
构框架，并指出了开发了开发各阶段的关系、开发活动的衔接情况。
主要模型：瀑布模型（waterfall model），原型（prototype）模型，螺旋（the spiral）模型，增量（incremental）模
型，喷泉（fountain）模型，迭代（iterative）模型
七、简述有哪些主要的软件开发方法？（P22）
结构化方法：也称为生命周期方法或传统方法，由结构化分析（structured analysis）、结构化设计（SD）、结构化编
程（SP）三部分有机组合而成。其基本思想是自顶向下，逐步求精，基本原则是抽象和分解。
面向对象方法（Object—Oriented Method）：把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，
简称OO。包括面相对象分析（OOA）、面向对象设计（OOD）、面向对象的程序设计（OOP）等过程。
八、软件生命期各阶段的任务是什么？（P10）
软件定义：问题定义，系统的可行性研究，需求分析
软件开发：概要设计，详细设计，编码实践，软件测试
软件使用维护和退役：软件发布与实施，软件维护，版本更新或退役
九、简述瀑布模型（P12）、原型模型特点。
瀑布模型：软件开发的各项活动严格按照线性方式进行，各阶段之间具有顺序性和依赖性，且为了保证软件的开
发质量进行阶段性评审。缺点是逆转性差，若在评审中发现缺陷或错误往回追溯修正时要付出一定的代价。适合在软件需求明确且很少发生变化、开发技术比较成熟、工程管理比较严格地场合使用。
原型模型：有助于用户和软件分析员双方相互学习对方领域知识，使得用户和开发人员统一对软件需求的认识，
理解，有助于需求的定义评审，从而有助于提高开发速度。缺点是用户对原型没有正确认识，会催促开发
人员尽早交付软件，同时也在一定程度上限制了软件开发人员的创新。（P14）
第二章 软件需求基础
一、试述软件需求、需求分析、需求建模概念的含义及区别。
软件需求：指用户对目标软件系统在功能、性能、行为、涉及约束等方面的期望，这种期望可能是原始的、笼统
的，也可能是抽象的太细节化的。（P26）
需求分析：通过对应用问题及其环境的分析与理解，采用一系列的分析方法和技术，将用户的需求逐步精确化、
完全化、一致化，最终形成需求规格说明文档的过程。（P26）
需求建模：需求建模是为了更好的理解用户所描述的需求所作出的一种抽象，是用符号语言对事务无歧义的书面
描述。模型主要包括数据模型，功能模型和行为模型。（P38）
二、可行性研究的任务是什么？（P31）
用最小的代价在尽可能短的时间内确定该软件项目是否能够开发，是否值得去开发。
三、成本—效益分析可用哪些指标进行度量？（P32）
成本效益分析是衡量经济可行性的。 指标：（1）货币的时间价值。（2）投资回收期（3）纯收入
四、需求分析阶段的基本任务是什么？（P27）
任务：深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有
效性需求。
五、简述需求分析阶段的过程。（P36）
1．问题识别 2．分析与综合 3．编制需求分析阶段的文档 4．需求验证
六、常用的初步软件需求获取的方法有哪些？为什么要用这些方法来进行需求获取？（P33）
方法： 1．访谈与会议 2．观察用户工作流程 3．建立联合小组
4．其他获取方法：快速原型法，基于本体的需求获取方法
原因：分析人员和用户的共同知识领域可能不多，致使分析人员对问题往往知之不多，而用户对目标软件的要求
及对要求的描述常常是零乱而模糊地，从而会造成相互交流和互相理解上的困难。
七、在软件需求分析时，应首先建立当前系统的物理模型，在根据物理模型尽力当前系统的逻辑模型。试问：什么是
当前系统？当前系统的物理模型与逻辑模型有什么差别？（P28）
当前系统：可能是需要改进的某个已在计算机运行的数据处理系统，也可能是一个人工的数据处理过程。
物理模型是确定待开发软件系统的系统元素，并将功能和数据结构分配到这些系统元素中，它是软件实现的基础。
逻辑模型忽视实现机制与细节，只描述系统要完成的功能和要处理的数据。
逻辑模型是在物理模型的基础上去掉一些非本质因素形成的，它反应的是系统的本质。
第三章 软件设计基础
一、什么是软件概要设计？该阶段的基本任务是什么？
定义：设计人员依据软件需求规格说明文档，确定软件的体系结构，建立软件模块间的关系，定义个功能模块的
接口，设计全局数据库或数据结构，规定设计约束，指定组装测试计划。
任务：将软件需求转化为软件的系统结构和数据结构（P49）
*力争做到功能模块之间有比较低的耦合度而功能模块内部有较高的内聚度。
二、详细设计的基本任务是什么？有哪几种描述方法？
任务：通过对软件结构细化，得到软件的详细的算法和数据结构。（P49）
描述方法：（过程设计）程序流程图 盒图（N-S图） 问题分析图（PAD图） 判定表和判定树
过程设计语言（PDL）（P77）
三、软件设计的基本原理包括哪些内容？（P51）
抽象与逐步求精、模块化、信息隐蔽、模块独立
四、衡量模块独立性的两个标准时什么？各表示什么含义？
标准：内聚和耦合
含义：内聚（cohesion）——衡量一个模块内部各个元素彼此结合的紧密程度
耦合（coupling）——衡量不同模块之间的相对独立性（互相连接的紧密程度）
五、模块的耦合性有哪几种？各表示什么含义？
种类：非直接耦合——两个模块之间没有直接关系，他们中任何一个都不依赖于另一个而能独立工作
数据耦合——一模块访问另一模块，相互传递的信息已参数形式给出，并且传递的参数完全是简单数据元
素，而不是控制元素、公共数据结构和外部变量。
标记耦合——两模块之间都要使用同一数据结构的一部分，不是采用全程公共数据区共享，而是通过模块
接口界面传递数据结构的一部分。
控制耦合——一模块传递给另一模块的参数中包含了控制信息（开关，标记，名字等），该控制信息勇于控
制接收模块中的执行逻辑。
外部耦合——一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全
局变量信息。
公共耦合——一组模块都访问同一个公共数据环境
内容耦合——一模块直接访问另一模块的内部数据；一个模块不通过正常入口转到另一模块内部；两个模
块有一部分程序代码重迭（只出现在汇编程序中）；一个模块有多个入口。
*从上到下耦合性从低到高，独立性从高到底
六、模块的内聚有哪几种？各表示什么含义？
种类：巧合内聚（偶然内聚）——将几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立的模块 逻辑内聚——完成一组在逻辑上相关的任务的模块间具有逻辑内聚
时间内聚（经典内聚）——完成几个必须在同一时间内进行的任务的模块间具有时间内聚
过程内聚——一个模块完成多个任务，这些任务必须按指定的过程执行。把流程图中的某一部分划出组成
模块就得到过程内聚模块
通信内聚——一个模块内所有成分都使用同一输入数据或产生同一输出数据，即一个模块内所有处理元素
都集中在某个数据结构的一块区域中的模块具有通信内聚
信息内聚——一个模块内完成多个功能，各个功能都在同一数据结构上操作，每一项功能有一个唯一的入口点
七、结构化程序设计的基本要点是什么？
结构化程序设计是尽可能少用GOTO语句的程序设计方法。最好仅在检测出错误时才使用GOTO语句，而且应该
总是使用前句GOTO语句。
第四章 结构化分析与设计
一、什么是结构化分析方法？该方法使用什么描述工具？（P85—P86）
定义：结构化分析方法是一种利用自顶向下逐层分解、由粗到细、由复杂到简单技术的求解方法。
工具：数据流图（DFD 实体—关系图（E-R） 数据字典（DD） 描述基本加工小说明（Process SPECification）
二、什么是数据流图？其作用是什么？其中的基本符号各表示什么含义？（P87）
定义：数据流图是描述数据加工处理过程的有效工具。它标识了一个系统的逻辑输入和逻辑输出，以及把逻辑输
入转换逻辑输出所需的加工处理。
作用：主要描述系统的功能，即当前系统主要完成哪些功能。
基本符号：箭头——数据流 圆或椭圆——加工（变换） 双杠或单杠——数据 矩形框——外部实体
三、什么是数据字典？其作用是什么？共有哪些条目？（P94）
定义：数据字典是对所有与系统相关的数据元素的一个有组织的列表，以及精确地、严格地定义了每一个与系统
相关的数据元素，并以字典式顺序将它们组织起来，使得用户和分析员对所有的输入、输出、存储成分和
中间计算有共同的理解。
作用：对系统所有的数据进行描述和解释并进行管理。
条目：数据项条目、数据流条目、数据库文件条目（P96）
四、简述如何画分层数据流图，对分层数据流图的审查由哪些审查要点？（P88 P92）
画法：首先，把整个系统看成一个加工作为顶层数据流图（0层）；然后，逐层对大的加工进行分解，分解为更小
的自加工；最后，直到所有的加工都成为基本加工（不需要再分解，足够简单可以直接解决的加工）为止。 审查：1、数据流图和程序流程图的混淆 2、父图和子图的平衡问题 3、局部文件问题 4、分解的深度与层次
五、什么样是“事物流”？什么事“变换流”？试将相应形式的数据流图转换为软件结构图。（P104）
事物流——数据沿传入路径到系统，由外部形式变换为内部形式后到达事务中心（完成分派任务），事务中心根据
数据项计值结果从若干动作路径中选定一条继续执行。（事务中心）
变换流——信息以“外部世界”所具有的形式进入系统，经处理后又以这种形式离开系统。包括传入路径，变换
中心，传出路径三部分。（变换中心）
步骤：（1）对结构化分析阶段产生的DFD图进行复审；
（2）确定数据流图的类型
（3）按照SD方法所规定的一组映射规则，把DFD图转换为初始SC图
六、试述“变换分析”、“事务分析”设计步骤。（P106—P108）
变换分析：第一步——划分DFD图的边界，也就是将DFD图划分为三个基本的组成部分，不同的设计人员可能
产生不同的划分结果；
第二步——完成第一级分解，建立初始SC图的框架；
第三步——完成第二级分解，细化SC图的每个分支，得到初始SC图。
事务分析：首先确定事务中心，即几条动作路径的公共源头；其次划定接收路径和发送路径；然后分解和细化每
个接收分支和发送分支，完成初始的SC图。
七、简述有哪些启发式设计策略可以帮助软件设计人员改善软件质量，优化软件结构。（P108—P110）
（1）模块的高独立性和规模适中 （2）保持高扇入和低扇出
（3）模块的作用域应在控制域之内 （4）降低模块接口的复杂度
第五章 面向对象的分析与设计
一、说明对象、类、类结构、消息的基本概念（P113）
对象：是封装了数据结构及可以施加在这些数据结构上的操作的封装体。
类：对具有相同属性和操作的一组对象的抽象性描述，它描述了属于该对象类型的所有对象的性质，包括外部特
性和内部实现两个方面。
类结构：（实例）
消息：是用来请求对象执行某一处理或回答某一要求的信息。
二、试述面向对象方法学的优点。（P112）
1、开发的软件比较容易理解 2、稳定性好 3、可重用性好 4、较易开发大型软件产品 5、可维护性好
三、什么是UML？为什么使用UML？（P118）
定义：UML（Unified Modeling Language）是一个通用的、可视化标准建模语言。
使用原因：统一的标准 面向对象 可视化、表示能力强 独立于过程 易掌握、易用
四、在UML中用例图的作用是什么？其包括哪些符号？简述各符号的含义。（P122）
作用：捕获系统中用户的需求
符号：人形（stickman）——活动者 椭圆——用例 实线——关系
五、简述用例建模的步骤。
步骤：识别参与者——识别用例——识别关系——建模——用例规约
六、什么是用例规约？其包括哪些基本内容？什么是基本流和备选流？
定义：用例的补充说明，包括简要说明，事件流，用例场景，特殊需求，前置条件，后置条件
基本流：
备选流：
七、在UML中的状态图，活动图，时序图在系统分析中各起到了什么作用？
状态图——描述对象在生命周期内处于哪些状态，每一种状态的行为以及什么样的事件引起对象状态发生改变，
展示了系统的动态视图。P144
活动图——描述动作及对象状态改变的结果，描述采取何种动作似的对象的状态改变，动作的序列是什么及在何
处发生。P148
时序图——详细表示对象之间以及对象与系统外部的参与者之间动态联系的图形文档，它详细而直观地表现了一
组相互协作的对象在执行一个（或少量几个）用例时的行为依赖关系，以及操作和消息的时序关系。P139
八、简述类图中关联和依赖关系的区别。
关联表示两个类的对象之间存在某种语义上的联系。（组合/聚合关联）如：学生选课，学生与课程间
依赖是类与类之间最弱的关系，它是两个模型元素（类、用例等）之间的语义连接关系，其中一个模型元素是独立，另一模型元素依赖于独立的模型元素，如果独立的模型元素改变了，将影响依赖于它的模型元素。如教师与粉笔。
九、类图中类与类之间的关系有哪几种？
类与类之间的静态关系：关联，泛化，依赖，细化
第六章 人机界面设计
一、简述人机界面的设计过程。（P168）
1、确定任务的目标和含义；
2、将每个目标或含义映射为一系列特定的动作；
3、说明这些动作将来在界面上执行的顺序；
4、指明系统状态，及上述各动作序列中每个动作在界面上执行时界面呈现的形式；
5、定义控制机制，即用户可用的改变系统状态的设备和动作；
6、说明控制机制怎样作用于系统状态；
7、指明用户如何根据界面上反映出的信息，解释系统的状态。
二、简述人机界面设计过程中应考虑哪些一般问题？（P168）
系统响应时间 用户帮助设施 出错信息处理 命令交互
三、如何理解界面设计中“人的因素”（P162）
人对感知过程的认识 用户的技能和用户间的差异
第八章 软件测试
一、什么是白盒测试法？有哪些覆盖标准？P205
定义：（结构测试或逻辑驱动测试）测试时，把程序看做一个打开的盒子，它是知道产品内部工作过程，而不顾他
的功能。
覆盖标准：语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 条件组合覆盖 路径覆盖
二、什么是黑盒测试法？采用黑盒技术测试用例有哪几种方法？（P199）
定义：（功能测试或数据驱动测试）它是在已知产品所应具有功能的基础上，通过测试来检测每个功能是否都能正
常使用。
方法：等价类划分 边界值分析 错误推测 因果图 比较测试
三、软件测试要经过哪些步骤？这些测试与软件开发各阶段之间有什么关系？
步骤：单元测试——集成测试——确认测试——系统测试
关系：单元测试（模块测试）——是最小单位的测试，其依据是详细设计说明书。测试者（程序员）根据详细设
计说明书和源程序清单了解模块的I/O条件和模块的逻辑结构。
集成测试（组装测试、联合测试、子系统测试、部件测试）——是在单元测试的基础上，将所有模块按照
概要设计要求组装成为子系统或系统进行测试。
确认测试（有效性测试）——检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标
准（用户参与）。
系统测试——针对整个产品系统进行的测试，验证系统是否满足了需求规格的定义，找出与需求规格不相
复合或与之矛盾的地方。
四、单元测试有哪些内容？
模块接口 局部数据结构测试 路径测试 错误处理测试 边界测试
五、什么是集成测试？非渐增式测试与渐增式测试有什么区别？渐增式测试如何组装模块？
定义：集成测试（组装测试、联合测试、子系统测试、部件测试）是在单元测试的基础上，将所有模块按照概要
设计要求组装成为子系统或系统进行测试。
区别：P216自己看
组装：
六、什么是回归测试？（P218）
发生修改之后重新测试先前的测试以保证修改的正确性。目的在于检验以前出现过的但已修复好的缺陷不再出现。
七、什么是测试用例？（P194）
测试用例由测试输入数据和预期输出结果组成。
八、软件测试和软件调试有何区别？
第九章 软件维护
一、软件维护有哪些内容？（P229）
改正性维护 适应性维护 完善性维护 预防性维护
二、何为非结构化维护和结构化维护？（P231）
结构化维护——采用软件工程的方法进行软件的开发，则每一个阶段都有相应的文档，且文档与程序代码互相匹
配，因此维护容易进行。
非结构化维护——没有采用软件工程的方法进行软件的开发，开发出的软件只有程序没有文档，或者仅有一些片
段的说明性文档。给维护工作带来很大的困难，耗时耗力且代价高。
三、软件维护的流程是什么？（P233）
提交维护申请报告——生成软件修改报告——软件修改——主要流程
四、软件维护的副作用有哪些？（P240）
修改编码的副作用
修改数据结构的副作用
修改文档的副作用