1、简述软件工程过程的含义、目的以及包含的子过程。

2、数据字典的作用是什么，它有哪些条目/p>

3、简述结构化程序设计方法的基本要点。

4、简述原型的开发步骤。

5、什么是需求规约述需求规约的基本性质。

答：需求规约是一个软件项 / 产品/ 系统所有需求陈述的正式文档，它表达了一
个软件产品 / 系统的概念模型。需求规约一般需要满足一下 4 个基本性质：

1. 重要性和稳定性程度：按需求的重要性和稳定性，对需求进行分级；
2. 可修改性：在不影响其他需求的前提下可容易修改一个单一需求；
3. 完整性：设备被遗漏的需求；
4. 一致性：不存在互斥的需求。

6、什么是模块耦合述常用的模块耦合类型及其设计原则。

答：模块耦合：是指不同模块之间相互依赖程度的度量；
几中常见模块耦合类型为：内容耦合、公共耦合、控制耦合、标记耦合、数据
耦合等；
设计原则：如果模块间必须存在耦合，就尽量使用数据耦合，少用控制耦合，
限制公共耦合，避免内容耦合。

7、UML给出了那些表达关系的术语述它们的概念。

答：1. 为了表达各类事物之间的关系， UML给出了表达关系的术语：关联、泛
化、细化、依赖；
2. 关联是类目之间的一种结构关系，是对一组具有相同结构、相同链的描述；
3. 泛化是一般性类目和它的较为特殊类目之间的一种关系；
4. 细化是类目之间的语义关系，其中一个类目规约了保证另一个类目执行的契
约；
5. 依赖是一种使用关系，用于描述一个类目使用另一类目的信息和服务。

8、 简述 RUP的定义和特点。

答：RUP是基于一种过程框架，为软件开发，即为进行不同抽象层之间映射安
排其开发活动的次序，制定任务和需求开发的制品，提供了指导；并为对项目
中的制品和活动进行监督与度量，提供了相应的准则；
RUP特点是：以用况为驱动，以体系结构为中心，迭代、增量式开发。

9、简述软件测试步骤及关注的内容。

答：软件测试步骤及关注的内容有以下几点：

1. 由于软件错误的复杂性，在软件工程测试中应综合运用测试技术，实施合理
   的测试步骤：单元测试、集成测试、有效性测试和系统测试；
2. 单元测试关注每个独立的模块；
3. 集成测试关注模块的组装；
4. 有效性测试福按住检验是否符合用户所见的文档；
5. 系统测试关注检验系统中所有元素之间的协作是否合适，整个系统的性能。
   功能是否达到。

10、简述瀑布模型以及可适应的情况。

答：1. 瀑布模型将软件生存周期的各项活动规定为按固定顺序而连接的若干阶
段工作，形如瀑布流水，最终得到软件产品； 2. 瀑布模型在支持结构化软件开
发的复杂性、促进软件开发工程化等方面起着很大作用； 3. 该模型适应的情况、
需求已被很好的理解，切开发组织非常熟悉为实现这一模型所需要的过程。

11、简述软件需求的分类及其关系。 (P23-24)

答：软件需求可以分为功能需求和非功能需求 2 大类；功能需求规定了系统及
构件必须执行的功能；非功能需求又可以分为性能需求、外部接口需求、设计
约束和质量属性需求。功能需求是整个软件需求的主体，没有工鞥需求就没有
性能、外部接口、设计约束和质量的需求；一个非功能需求可以用于 1 个功能
需求。

12、 什 么是模 块什么 是模 块内 聚 列 出 从 低 到高 的常 见 内 聚 类型 。

答：模块是执行一个特殊任务的过程以及相关的数据结构。内聚是指一个模块
内部各个成分之间相互关联程度的度量。从低到高的内聚类型：偶然内聚；逻
辑内聚；时间内聚；过程内聚；通信内聚；顺序内聚；功能内聚。

13、 什 么是状 态什么 是状 态图 简述实 际 应 用 中只 用状 态 图 的 作用 。

答：状态是类目的一个实例在其生存中的一种条件或情况；期间该实例满足这
一条件，就执行某一活动或等待一个消息。状态图是现实状态机的图，强调从
一个状态到另一个状态的控制流。从实际使用中状态图的作用：创建一个系统
的动态图和创建一个场景的模型。

14、简述 RUP中需求获取的基本步骤和相关制品。

答：需求获取的步骤和相关制品：

1. 列出候选的特征，相关制品是特征表；
2. 理解系统语境，相关制品是领域模型或业务模型；
3. 捕获系统功能需求，相关制品是用况模型；
4. 捕获非功能需求，相关制品是补充的需求过针对特殊需求的用况。

15、 简述黑盒测试技术的要点。

答：黑盒测试技术的要点：

1. 支持测试工程模型的中间部分；
2. 事务流测试技术是将路径测试技术用于功能测试的产物， 是一种实用的功能
   测试技术，通过事务的操作逻辑发现软件中的错误；
3. 事务流测试技术是基于软件规约的， 对错误的假定是软件通过了与预想不同
   的事务路径；
4. 基于事务的基本操作； 事务流测试技术的最大问题和最大代价是获取事务流
   程图及用例设计；
5. 事务处理流程测试要达到基本的测试覆盖。

16、 简述增量模型以及可适应的情况。

答：增量模型意指需求可以机构化分组，形成一个个增量，并形成一个结构，
之后对每一个增量进行瀑布开发。用增量模型开发的前提是需求的节后花，模
型适合“技术驱动”的软件产品开发。

17、简述需求的基本性质。

答：需求的基本性质：

1. 必要性，该需求是用户所要求的；
2. 无歧义性，该需求只能用一种方式解释；
3. 可测性，该需求是可进行测试的；
4. 可跟踪性，该需求可从一个开发阶段跟踪到另一个阶段；
5. 可测量性，该需求是可测量的；

18、简述在进行软件系统 / 产品的需求工作中所面临的挑战和应对方法。

答：面临的挑战：

1. 问题空间解释；
2. 人与人之间的通信；
3. 需求的变化性；
   应对方法：为了应对三大挑战， 提出了系列软件开发方法， 面向数据结构方法，
   面向对象方法等。

19、什么是类么是对象么是类的构成成分/h1>

答：类：类是一组具有相同属性、操作、关系和语义的对象的描述；
对象：对象是类的一个实例；
类的构成成分：类名、属性、操作。

20、什么是 RUP有什么特点/h1>

答：RUP：即统一软件开发过程，它是基于 UML的一种过程框架，为软件开发，
即为进行不同抽象层之间映射安排其开发活动的次序，制定任务和需要开发的
制品，提供了指导； 并为对项目； 并为对项目中的制品和活动进行监控与度量，
提供了相应的准则；
RUP的特点是： 1. 以用况为驱动； 2. 以体系结构为中心； 3. 迭代、增量式开发。

21、 简述人们关于软件测试目的的认识所经历的几个阶段。

答：软件测试的几个阶段：

1. 第一阶段认为软件测试和软件调试没有什么区别；
2. 第二阶段认为测试是为了表明软件能正常工作；
3. 第三阶段认为测试是为了表明不能正常工作；
4. 第四阶段认为测试仅是为了将已察觉的错误风险减少到一个可接受的程度；
5. 第五阶段认为测试不仅仅是一种行为，而是一种理念，即测试是产生低风险

22、36. 简述喷泉模型以及可适应的情况。

答：喷泉模型以及可适应的情况有以下几点：

1. 喷泉模型体现了软件创建所固有的迭代和无间隙的特征；
2. 喷泉模型说明了软件活动需要多次重复；
3. 喷泉模型还说明活动之间没有明显的间隙；
4. 该模型主要适应于面向对象技术的软件开发。

23、 通过长期的软件开发实践，人们总结出了哪些模块设计的启发式规则/h1>

答：通过长期的软件开发实践，总结出了实现模块“高内聚低耦合”的启发式
规则：

1. 改进软件结构，提高模块独立性；
2. 力求模块规模适中；
3. 力求深度、宽度、扇出和扇入适中；
4. 尽力使模块的作用域在其控制域之内；
5. 尽力降低模块接口的复杂度；
6. 力求模块功能可以预测

24、 什么是类么是对象述类在建模中的主要用途。

答：类是一组具有相同属性、操作、关系和语义的对象的描述。对象是类的一
个实例。类在建模中的主要用途：

1. 模型化问题域中的概念。使抽象模型中的概念模型转化为系统模型中的类；
2. 建立系统职责分布模型；
3. 模型化建模中使用的基本类型。

25、简述软件测试和软件调试之间的区别。

答：软件测试和软件调试之间的区别有如下几点：

1. 测试从一个侧面证明程序员的“失败” ，调试是为了说明程序员的正确；
2. 测试已知条件开始，使用预先定义的程序且有预知的结果，不可预见的仅是
   程序是否通过。调试是以不可知的内部条件开始，除统计性调试外、结果不
   可预见的；
3. 测试是有计划的，并要进行测试设计。调试不受时间约束的；
4. 测试是一个发现错误、改正错误、重新测试的过程，调试是一个推理过程；
5. 测试执行时是有规程的。调试的执行往往要求程序员进行必要的推理；
6. 测试经常是独立测试组在不了解软件设计的条件下完成的。 调试必须有了解
   详细设计的程序员完成；
7. 大多数测试的执行和设计可有工具支持。调试时，程序员能利用的工具主要
   是调试器。

26、 简述演化模型以及可适应的情况。

答：演化模型表达了一种弹性的过程模式，由一些小的开发步组成的，每一步
经历需求分析、 设计、实现和验证， 产生软件产品的一个增量。 通过这些迭代，
最终完成软件产品的开发。可适应的情况：只要针对事先不能完整定义的软件
开发的。

27、简述初始需求发现的常用技术。

答：初始需求发现的常用技术有以下几点：

1. 自悟：需求人员把自己作为系统的最终用户，审视该系统并提出问题；
2. 交谈：为了确定系统应该提供的功能，需求人员通过问答方式，直接询问用
   户需求的是一个什么样的系统；
3. 观察：通过观察用户执行其现行的任务和过程，了解系统运行的环境，特别
   是了解要建立的新系统与现存系统、过程及工作方法间必须进行的交互；
4. 小组会：举行客户和开发人员的联席会议，与客户代表共同开发需求；
5. 提炼：复审技术文档，并提取相关的信息。

28、 什么是用况 （Use Case）么是用况图个用况图通常包含哪些模型元

素br> 答：用况（ Use Case）：从外延上说它表达了参与者使用系统的一种方式，从内
涵上说它规约了系统可以执行的一个动作序列， 并对特定的参与者产生可见的、
有值的结果；
用况图：是一种表达系统功能模型的图形化工具；
一个用况图通常包含的模型元素是： 主题、用况、参与者、 关联、泛化、依赖。

29、简述白盒测试技术的要点。

答：白盒测试技术，又称为结构化测试技术，它依据程序的逻辑结构，以控制
流程图作为被测对象建模工具；
典型的是路径测试技术，路径测试大致有语句覆盖、分支覆盖、条件组合覆盖
和路径覆盖等测试策略；
这几种不同的测试策略之间具有偏序关系，即路径覆盖的测试度量最强，而语
句覆盖最低。

30、简述螺旋模型以及可适应的情况。

答：螺旋模型以及可适应的情况分为以下几点：

1. 螺旋模型是在瀑布模型和演化模型的基础上， 加入两者所忽略的风险分析所
   建立的一种软件开发模型；
2. 螺旋模型沿着螺旋线，经历制定计划，风险分析，实施工程，客户评估等 4
   个方面的活动，自内向外每旋转一圈便产生一个更为完整的新版本；
3. 该模型适应的情况：项目的开发风险很大或客户不能确定系统需求。

31、简述需求的概念和基本性质。

答：软件需求以一种技术形成， 描述了一个产品 / 系统应该具有的功能、 性能和
其它性质。
需求的基本性质有以下 5 点：

1. 必须的，该需求是用户所要求的；
2. 无歧义的，该需求只能用一种方式解释；
3. 可测的，该需求是可进行测试的；
4. 可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段；
5. 可测量的，该需求是可测量的。

32、简述以结构化分析方法建立系统功能模型的建模工具和建模过程。

答：工具：DFD，数据流图是一种描述数据变换的图形化工具， 其中包含的元素
可以是数据流，数据存储，加工，数据源和数据潭。
过程有以下 4 点：

1. 建立系统环境图，确定系统语境；
2. 自顶向下，逐步求精，建立系统的层次数据流图；
3. 定义数据字典；
4. 描述加工。

33、简述顺序图的概念、构成和主要作用。

答：顺序图的概念：用来描述为了完成确定事务、对象之间按照时间消息交互
的顺序关系；
欢迎阅读
页脚内容
顺序图的构成：顺序图是一种交互图，即由一组对象以及按时序组织的对象之
间的关系组成，其中还包括哲学对象之间所发送的消息。
顺序图的主要作用：顺序图作为一种描述在给定语境中消息是如何在对象间传
递的图形化方式，在使用起进行建模时。

34、简述增量模型的优缺点。

答：优点有以下 3 点：

1. 第一个可交付版本所需要的成本和时间是较少的， 从而可减少开发由增量表
   示的小系统承担的风险；
2. 由于很快分布的第一个版本，因此可以减少用户需求的变更；
3. 允许增量投资，即在项目开始时可以仅对一个或两个增量投资；
   缺点有以下 3 点：
4. 如果没有对用户的变更要求进行规划， 那么产生的初始增量可能会造成够来
   增量的不稳定；
5. 如果需求不像早期思考的那样稳定和完整， 那么一些增量就可能需要重新开
   发，重新发布；
6. 由于进度和配置的复杂性，可能会增大管理成本，超出组织的能力。

35、简述 CMMI模型支持的两种过程改善路径。

答：能力等级是一个过程改善路径，该路径可是组织针对单一过程域不断改善
该过程域、成熟度等级也是一种过程改善路径，该路径可使组通过关注一组过
程域不断改善一组相关的过程域。

36、简述需求的概念和基本性质。

答：软件需求以一种技术形成， 描述了一个产品 / 系统应该具有的功能、 性能和
其它性质。需求的基本性质：

1. 必要的，该需求是用户所要求的；
2. 无歧义的，该需求只能用一种方式解释；
3. 可测的，该需求是可进行测试的；
4. 可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段；
5. 可测量的，该需求是可测量的。

37、简述以结构化分析方法建立系统功能模型的建模工具和建模过程。

答：建模工具： DFD，数据流图是一种描述数据变换的图形化工具， 其中包含的
元素可以是数据流，数据存储，加工，数据源和数据潭。
建模过程：

1. 建立系统环境图，确定系统语境；
2. 自顶向下，逐步求精，建立系统的层次数据流图；
3. 定义数据字典；
4. 描述加工。

38、简述顺序图的概念、构成和主要作用。

答：顺序图的概念：用来描述为了完成确定事务、对象之间按照时间消息交互
的顺序关系；
顺序图的构成：顺序图是一种交互图，即由一组对象以及按时序组织的对象之
间的关系组成，其中还包括这些对象之间所发送的消息；
顺序图的作用：顺序图作为一种描述在给定语境中消息是如何在对象间传递的
图形化方式，在使用其进行建模时。

39、 简述增量模型的优缺点。

答：增量模型的优点：

1. 第一个可交付版本所需要的成本和时间是较少的， 从而可减少开发由增量表
   示的笑系统承担的风险；
2. 由于很快发布的第一个版本，因此可以减少用户需求的变更；
3. 允许增量投资，即在项目开始是可以仅对一个或两个增量投资；
   增量模型的缺点：
4. 如果没有对用户的变更妖气进行规划， 那么产生的初始增量可能会造成后来
   增量的不稳定；
5. 如果需求不像早期思考的那样稳定和完整， 那么一些增量就可能需要重新开
   发，重新发布；
6. 由于进度和配置的复杂性，可能会增大管理成本，超出组织的能力。

40、简述 CMMI模型支持的两种过程改善路径。

答：能力等级是一个过程改善路径，该路径可是组织针对单一过程域不断改善
该过程域、成熟度等级也是一种过程改善路径，该路径可使组通过关注一组过
程域不断改善一组相关的过程域。

简述 CMMI提出所基于的基本思想。 (P282)

答：该模型基于过程途径思想，通过过程把软件质量的 3 个支撑点——受训的
人员、规程和方法、工具和设备进行集成，以开发所期望的系统 / 产品。为此，
CMMI紧紧围绕开发、 维护和运行， 把经过证明的 “最佳实践” 放在一个结构中。

简述 CMMI成熟度等级的概念、划分和组成。 (考纲解析 P104-105)

答：成熟度等级是指达到预先定义的一组过程域所有目标的一种过程改善等级。
在 CMMI中，应用于一个组织过程改善的成熟度等级有 5 个：

1. 1 级：初始级；
2. 2 级：以管理级；
3. 3 级：以定义级；
4. 4 级：以定量管理级；
5. 5 级：持续优化级

41、简述何谓系统模型以及软件开发中所涉及的系统模型分类。 (P19)

答：所谓系统建模，是指运用所掌握的知识，通过抽象，给出该系统的一个结
构——系统模型。系统模型分为两大类，一类称为概念模型，描述了系统是什
么；另一类统称为软件模型，描述了实现概念模型的软件解决方案。

42、简述需求规约的定义，并写出需求规约满足的基本性质。 (P28)

答：需求规约是一个软件项 / 产品/ 系统所有需求陈述的正式文档，它表达了一
个软件产品 / 系统的概念模型。
需求规约一般需要满足一下 4 个基本性质：

1. 重要性和稳定性程度：按需求的重要性和稳定性，对需求进行分级；
2. 可修改的：在不过多地影响其他需求的前提下，可以容易地修改一个单一需
   求；
3. 完整的：没有被遗漏的需求；
4. 一致的：不存在互斥的需求。

43、简述结构化方法总体设计的任务、步骤和模式。 ( 考纲解析 P25)

答：总体设计的任务是把系统的工鞥需求分配到一个特定的软件体系结构中。
变换设计的基本步骤如下：

1. 设计准备——复审并精化系统模型；
2. 确定输入、变换、输出这三部分之间的边界；
3. 第一级分解——系统模块结构图顶层和第一层的设计；
4. 第二级分解——自顶向下，逐步求精；
   事务设计的基本步骤如下：
5. 设计准备——复审并精化系统模型；
6. 确定事务处理中心；
7. 第一级分解——系统模块结构图顶层和第一层的设计；
8. “第二级分解”——自顶向下，逐步求精。

44、简述软件开发的本质。 (P17/19)

答：软件开发的本质，即实现问题空间的概念和处理逻辑到解空间的概念和处
理逻辑之间的映射。

45、 简述常用的初始需求发现技术。 (P26)

答：初始发现需求的常用技术包括以下几个：

1. 自悟。需求人员把自己作为系统的最终用户，审视该系统并提出问题；
2. 交谈。为了确定系统应该提供的功能，需求人员通过提出问题 / 用户回答这
   一方式，直接询问用户需要的是一个什么样的系统；
3. 观察。通过观察用户执行其现行的任务和过程，或通过观察他们如何操作与
   所期望的新系统有关的现有系统，了解系统运行的环境，特别是了解要建立
   的新系统与现存系统、过程以及工作方法之间必须进行的交互；
4. 小组会。举行客户和开发人员的联席会议，与客户组织的一些代表共同开发
   需求。其中： 1) 通常是由开发组织的一个代表作为手洗需求工程师或软件工
   程项目经理，主持这一会议； 2) 必须自习地选择该小组的成员，不仅要考虑
   他们对目前和未来运行环境的理解程度，还要考虑他们的人品；
5. 提炼。复审技术文档，并提出相关的信息。

46、什么是需求规约述需求规约的基本性质。

答：需求规约是一个软件项 /产品 /系统所有需求陈述的正式文档，
它表达了一个软件产品 /系统的概念模型。需求规约一般需要满
足一下 4 个基本性质：

1. 重要性和稳定性程度：按需求的重要性和稳定性，对需求进
   行分级；
2. 可修改性：在不影响其他需求的前提下可容易修改一个单一
   需求；
3. 完整性：设备被遗漏的需求；
4. 一致性：不存在互斥的需求。

47、什么是模块耦合述常用的模块耦合类型及其设计原则。

答：模块耦合：是指不同模块之间相互依赖程度的度量；
几中常见模块耦合类型为：内容耦合、公共耦合、控制耦合、标
记耦合、数据耦合等；
设计原则：如果模块间必须存在耦合，就尽量使用数据耦合，少
用控制耦合，限制公共耦合，避免内容耦合。

48、UML 给出了那些表达关系的术语述它们的概念。

答：1.为了表达各类事物之间的关系， UML 给出了表达关系的术
语：关联、泛化、细化、依赖；
2.关联是类目之间的一种结构关系，是对一组具有相同结构、相
同链的描述；
3.泛化是一般性类目和它的较为特殊类目之间的一种关系；
4.细化是类目之间的语义关系，其中一个类目规约了保证另一个
类目执行的契约；
5.依赖是一种使用关系，用于描述一个类目使用另一类目的信息
和服务。

49、简述 RUP的定义和特点。

答：RUP是基于一种过程框架，为软件开发，即为进行不同抽象
层之间映射安排其开发活动的次序， 制定任务和需求开发的制品，
提供了指导； 并为对项目中的制品和活动进行监督与度量， 提供
了相应的准则；
RUP特点是：以用况为驱动，以体系结构为中心，迭代、增量式
开发。

50、简述软件测试步骤及关注的内容。

答：软件测试步骤及关注的内容有以下几点：

1. 由于软件错误的复杂性，在软件工程测试中应综合运用测试
   技术，实施合理的测试步骤：单元测试、集成测试、有效性
   测试和系统测试；
2. 单元测试关注每个独立的模块；
3. 集成测试关注模块的组装；
4. 有效性测试福按住检验是否符合用户所见的文档；
5. 系统测试关注检验系统中所有元素之间的协作是否合适，整
   个系统的性能。功能是否达到。

51、简述瀑布模型以及可适应的情况。

答：1.瀑布模型将软件生存周期的各项活动规定为按固定顺序而
连接的若干阶段工作，形如瀑布流水，最终得到软件产品； 2.瀑
布模型在支持结构化软件开发的复杂性、 促进软件开发工程化等
方面起着很大作用； 3.该模型适应的情况、 需求已被很好的理解，
切开发组织非常熟悉为实现这一模型所需要的过程。

52、简述软件需求的分类及其关系。 (P23-24)

答：软件需求可以分为功能需求和非功能需求 2 大类；功能需求
规定了系统及构件必须执行的功能； 非功能需求又可以分为性能
需求、外部接口需求、设计约束和质量属性需求。功能需求是整
个软件需求的主体，没有工鞥需求就没有性能、外部接口、设计
约束和质量的需求；一个非功能需求可以用于 1 个功能需求。

53、什么是模块么是模块内聚列出从低到高的常见内聚

类型。 (P56,57,58,59)
答：模块是执行一个特殊任务的过程以及相关的数据结构。 内聚
是指一个模块内部各个成分之间相互关联程度的度量。 从低到高
的内聚类型：偶然内聚；逻辑内聚；时间内聚；过程内聚；通信
内聚；顺序内聚；功能内聚。

54、什么是状态么是状态图述实际应用中只用状态图的

作用。 (P107-108-113)
答：状态是类目的一个实例在其生存中的一种条件或情况； 期间
该实例满足这一条件， 就执行某一活动或等待一个消息。 状态图
是现实状态机的图， 强调从一个状态到另一个状态的控制流。 从
实际使用中状态图的作用： 创建一个系统的动态图和创建一个场
景的模型。

简述需求的基本性质。

答：需求的基本性质：

1. 必要性，该需求是用户所要求的；
2. 无歧义性，该需求只能用一种方式解释；
3. 可测性，该需求是可进行测试的；
4. 可跟踪性，该需求可从一个开发阶段跟踪到另一个阶段；
5. 可测量性，该需求是可测量的；

56、简述在进行软件系统 /产品的需求工作中所面临的挑战和应对

方法。
答：面临的挑战：

1. 问题空间解释；
2. 人与人之间的通信；
3. 需求的变化性；
   应对方法：为了应对三大挑战，提出了系列软件开发方法，面向
   数据结构方法，面向对象方法等。

57、什么是类么是对象么是类的构成成分/h1>

答：类：类是一组具有相同属性、操作、关系和语义的对象的描
述；
对象：对象是类的一个实例；
类的构成成分：类名、属性、操作。

什么是类么是对象述类在建模中的主要用途。

答：类是一组具有相同属性、操作、关系和语义的对象的描述。
对象是类的一个实例。类在建模中的主要用途：

1. 模型化问题域中的概念。使抽象模型中的概念模型转化为系
   统模型中的类；
2. 建立系统职责分布模型；
3. 模型化建模中使用的基本类型

58、简述人们关于软件测试目的的认识所经历的几个阶段。

答：软件测试的几个阶段：

1. 第一阶段认为软件测试和软件调试没有什么区别；
2. 第二阶段认为测试是为了表明软件能正常工作；
3. 第三阶段认为测试是为了表明不能正常工作；
4. 第四阶段认为测试仅是为了将已察觉的错误风险减少到一个
   可接受的程度；
5. 第五阶段认为测试不仅仅是一种行为，而是一种理念，即测
   试是产生低风险软件的一种训练。

59、简述喷泉模型以及可适应的情况。

答：喷泉模型以及可适应的情况有以下几点：

1. 喷泉模型体现了软件创建所固有的迭代和无间隙的特征；
2. 喷泉模型说明了软件活动需要多次重复；
3. 喷泉模型还说明活动之间没有明显的间隙；
4. 该模型主要适应于面向对象技术的软件开发。

60、什么是需求规约述需求规约的作用。

答：需求规约是一个软件项 /产品 /系统所有需求陈述的正式文档，
它表达了一个软件产品 /系统的概念模型。
需求规约的作用：

1. 需求规约是软件开发组织和用户之间一份事实上的技术合同
   书，是产品功能及其环境的体现；
2. 对于项目的其余大多数工作，需求规约是一个管理控制点；
3. 对于产品 /系统的设计，需求规约是一个正式的、受控的起始
   点；
4. 需求毁约是创建产品验收测试计划和用户指南的基础。

61、通过长期的软件开发实践，人们总结出了哪些模块设计的启

发式规则br> 答：通过长期的软件开发实践，总结出了实现模块“高内聚低耦
合”的启发式规则：

1. 改进软件结构，提高模块独立性；
2. 力求模块规模适中；
3. 力求深度、宽度、扇出和扇入适中；
4. 尽力使模块的作用域在其控制域之内；
5. 尽力降低模块接口的复杂度；
6. 力求模块功能可以预测。

62、什么是用况 （Use Case）么是用况图个用况图通常包

含哪些模型元素br> 答：用况（Use Case）：从外延上说它表达了参与者使用系统的一
种方式， 从内涵上说它规约了系统可以执行的一个动作序列， 并
对特定的参与者产生可见的、有值的结果；
用况图：是一种表达系统功能模型的图形化工具；
一个用况图通常包含的模型元素是： 主题、用况、参与者、关联、
泛化、依赖。

63、简述螺旋模型以及可适应的情况。

答：螺旋模型以及可适应的情况分为以下几点：

1. 螺旋模型是在瀑布模型和演化模型的基础上，加入两者所忽
   略的风险分析所建立的一种软件开发模型；
2. 螺旋模型沿着螺旋线， 经历制定计划， 风险分析， 实施工程，
   客户评估等 4 个方面的活动，自内向外每旋转一圈便产生一
   个更为完整的新版本；
3. 该模型适应的情况：项目的开发风险很大或客户不能确定系
   统需求。

64、述需求的概念和基本性质。

答：软件需求以一种技术形成，描述了一个产品 /系统应该具有
的功能、性能和其它性质。
需求的基本性质有以下 5 点：

1. 必须的，该需求是用户所要求的；
2. 无歧义的，该需求只能用一种方式解释；
3. 可测的，该需求是可进行测试的；
4. 可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段；
5. 可测量的，该需求是可测量的。

65、简述增量模型的优缺点。

答：优点有以下 3 点：

1. 第一个可交付版本所需要的成本和时间是较少的，从而可减
   少开发由增量表示的小系统承担的风险；
2. 由于很快分布的第一个版本，因此可以减少用户需求的变更；
3. 允许增量投资，即在项目开始时可以仅对一个或两个增量投
   资；
   缺点有以下 3 点：
4. 如果没有对用户的变更要求进行规划，那么产生的初始增量
   可能会造成够来增量的不稳定；
5. 如果需求不像早期思考的那样稳定和完整，那么一些增量就
   可能需要重新开发，重新发布；
6. 由于进度和配置的复杂性，可能会增大管理成本，超出组织
   的能力。

66、软件维护有哪些内容/h1>

a、校正性维护 b、适应性维护 c、完善性维护 d、预防性维护

67、软件维护的特点是什么/h1>

a、非结构化维护和结构化维护
b、维护的困难性
c、软件强维护的费用

68、软件维护的流程是什么/h1>

a、制定申请维护 告 b、审查申请 告并批准 c、进行维护并作详细记录 d、覆审

69、什么是软件的可维护性维护性的度量的特性是什么/h1>

软件的可维护性：软件能够被理解、校正、适应及增强功能的容易程度。
可维护性的度量的特性是：可理解性、可测试性、可修改性、可靠性、可移植性、可使用性
和效率。

70、.提高可维护性的方法有哪些/h1>

A、建立明确的软件质量目标。 B、利用先进的软件开发技术和工具。
C、建立明确的质量保证工作。 D、选择可维护的程序设计语言。
E、改进程序文档。

71、软件生命期各阶段的任务是什么/h1>

答：软件生命期分为 7 个阶段： 1)问题定义：确定要解决的问题是什么； 2)可行性研
究：确定问题是否值得解，技术可行性、经济可行性、操作可行性； 3) 需求分析：确
定该系统必须做什么； 4)总体设计：确定系统如何实现，包括系统设计和结构设计；
5)详细设计：具体实现设计的系统； 6) 实现：编码和测试； 7)运行维护：保证软件正
常运行。

72、如何理解模块独立性什么指标来衡量模块独立性/h1>

答：模块独立的概念是模块化、抽象、信息隐蔽和局部化概念的直接结果。
模块的独立性很重要：第一，有效的模块化（即具有独立的模块）的软件比较容
易开发出来。第二，独立的模块比较容易测试和维护。 模块的独立程度可以由两个
定性标准度量，分别是内聚和耦合。内聚衡量一个模块内部各个元素彼此结合的紧密
程度；耦合衡量不同模块彼此之间互相依赖（连接）的紧密程度。

73、软件重用的效益是什么/h1>

答：1) 软件重用可以显着地改善软件的质量和可靠性； 2) 软件重用可以极大地提
高软件开发的效率； 3) 节省软件开发的成本，避免不必要的重复劳动和人力、财
力的浪费。

74、简述建模过程及步骤/h1>

答：为了支持系统地使用信息来创建系统功能模型，结构化分析方法给出了建模的基
本步骤，该过程属于“自顶向下，功能分解”形式。 1. 建立系统环境图，确定系统语
境；2. 自顶向下，逐步求精，建立系统的层次数据流图； 3. 定义数据字典； 4. 描述加
工。

75、软件重用的效益是什么/h1>

答：1) 软件重用可以显着地改善软件的质量和可靠性； 2) 软件重用可以极大地提
高软件开发的效率； 3) 节省软件开发的成本，避免不必要的重复劳动和人力、财
力的浪费。

76、需求规约的作用是什么/h1>

答：需求规约的作用可概括为以下 4 点：1）需求规约是软件开发组织和用户之间一
份事实上的技术合同书，是产品功能及其环境的体现。 2）对于项目的其余大多数工
作， 需求规约是一个管理控制点； 3）对于产品 / 系统的设计，需求规约是一个正式
的、受控的起始点； 4）需求规约是创建产品验收测试计划和用户指南的基础。

77、软件质量与软件质量保证的含义是什么/h1>

答：软件质量定义为：与所确定的功能和性能需求的一致性；与所成文的开发标准一
致性；与所有专业开发的软件所期望的隐含特性的一致性。而软件质量保证就是向用
户及 会提供满意的高质量的产品，确保软件产品从诞生到消亡为止的所有阶段的质
量的活动，即确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理
活动。

78、、一个良好的设计类需要满足四个特点，请详细描述这四个特点/h1>

答：一个良好的设计类需要满足四个特点：
1）完整性和充分性： 2 ）原始性； 3 ）高内聚性； 4 ）低耦合性。

79、、简述模块独立性的原则。

答：模块独立性是指软件系统中每个模块只涉及软件要求的具体子功能，而和软件系
统中其他的模块接口是简单的，模块独立性的概念是模块化、抽象、信息隐蔽和局部
话概念的直接结果，由耦合和内聚 2 个标准度量。

80、简述文档在软件工程中的作用。

答：文档在软件工程中的作用如下： 1、提高软件开发过程的能见度； 2、实现对软件
开发的工程管理； 3、提高开发效率； 4、作为开发人员在一定阶段的工作成果和结束
标志；5、提供软件运行、维护和培训有关资料； 6、记录开发过程中有关信息便于协
调以后的软件开发使用和维护； 7、便于用户了解软件功能、性能。

81、衡量模块独立的两个标准是什么们各表示什么含义/h1>

答：两个定性的度量标准：耦合与内聚性。
耦合性指软件系统结构中各模块间相互联系紧密程度的一种度量，模块之间联系
越紧密，其耦合性就越强，模块的独立性则越差。
内聚性指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度
的度量，模块内元素联系越紧密，内聚性越高。

82、什么是软件危机产生的原因是什么/h1>

答：当软件开发技术跟不上硬件技术的进步，不能满足开发的要求时，导致软件开发
中遇到的问题找不到解决的办法，使问题积累起来，形成了尖锐的矛盾，从而导致了
软件危机。
原因：软件的规模越来越大，结构越来越复杂；软件开发管理困难且复杂；软件
开发费

83、简述软件产品的特性。

84、简述软件开发的本质及基本途径。

1、软件开发的本质可概括为：实现问题空间的概念；
2、和处理逻辑到解空间的概念；
3、和处理逻辑之间的映射；
4、实现这一映射的基本途径是系统建模

85、简述结构化分析建模的基本步骤。

1、建立系统环境图，确定系统语境；
2、自顶向下、逐步求精，建立系统的层次数据流图
3、定义数据字典
4、描述加工

86、简述 RUP中用况模型和分析模型的区别。

1、前者使用客户端语言来描述，后者使用开发语言来描述；
2、前者给出的是系统对外的视图，后者给出的是系统对内的视图；
3、前者使用用况给予结构化，后者使用衍型类给予结构化；
4、前者可以作为客户和开发者之间的契约，后者可以作为开发者理解系统的基础；
5、前者在需求之间可能存在冗余问题，后者不存在冗余问题；
6、前者捕获的是系统功能，后者给出的是细化的系统功能；
7、前者定义了一些需要在分析模型中给予分析的用况，后者定义了用况模块中每个用况的细化；

87、35．简述泛化的概念及其约束。

1、泛化是一般性类目和它的的较为特殊性目（子类）之间的一种关系，是”is-a-kind-of” 关系，UML给出以下4个约束；
2、完整
3、不完整
4、互斥
5、重叠

88、36．简述因果图方法生成测试用例的基本步骤。

1、通过软件规格说明书的分析，找出一个模块的原因和结构，并给每个原因和结果赋予一个标识符；
2、分析原因与结果之间以及原因与原因之间对应的关系，并画出因果图。
3、在因果图上标识出一些特点的约束或限制条件；
4、把因果图转换成判定表；
5、为判定表的每一列设计测试用例；

89、简述软件生存周期过程、软件生存周期模型、软件项目过程管理之间的关系。

1、软件生存周期过程回答软件开发需要做哪些工作；
2、软件生存周期模型回答软件开发活动或任务如何组织；
3、软件项目过程管理回答软件过程如何管理；
4、软件生存周期过程是软件生存周期模型和软件项目过程管理的基础；
5、软件生存周期模型为软件项目过程管理提供支持；

90、请用白盒测试法对题 39 图所对应的程序流程图进行测试。 要求从题 39 表给出的候选答

案中分别找出满足语句覆盖、 分支覆盖、 条件覆盖、 条件组合覆盖和路径覆盖 5 种覆盖标准
所需的最少测试用例。
1、语句覆盖
2、分支覆盖
3、条件覆盖
4、条件组合覆盖
5、路径覆盖

91、简述软件工程面临的问题。

答：内容：
①软件开发技术
②软件开发管理
面临的主要问题：
①软件费用
②软件可靠性
③软件维护
④软件生产率
⑤软件重用

92、简述可行性研究 告包含的主要内容。

1 技术可行性：对要开发项目的功能、性能、限制条件进行分析，确定在现有的资源条件下，技术风险有多大，项目是否能
实现。包括：开发的风险；资源的有效性；技术；开发人员在评估技术可行性时，一旦估计错误，将会出现灾难性后果。
2 经济可行性：包括成本 ―― 效果分析、公司经营长期策略、开发所需的成本和资源、潜在的市场前景。
3 会可行性包括：合同、责任、侵权、用户组织的管理模式及规范，其他一些技术人员常常不了解的陷阱等。

93、简述快速原型的开发步骤。

答：快速原型开发步骤可划分下列阶段：
（1）快速分析：迅速确定基本需求、集中力量确定需求说明。
（2）快速构造原型：在快速分析基础上，在强有力的软件工具支持下，快速构造所需原型。
（3）运行原型：在开发者指导下，用户参与原型的运行，各类人员在共同运行原型中进一步加深对系统的了解及相互间的
理解，以发现各种问题。
（4）评价原型；在运行基础上，根据原型目标，考核原型的特性，分析原型效果是否满足用户需求，提出修改意见。
（5）修改原型：在评价基础上进行修改。若不满足需求说明，则根据明确的需求修改原型。若不满足用户需求，则先修改
并明确用户需求，再重新构造原型。

94、简述选择软件生存周期模型 （SLCM）的步骤。

(p228)
选择一个适合项目的生存周期模型的步骤可
概括为：
第一步：标识开发项目可用的 SLCM。其中应
考虑组织中可用的支持 SLCM的管理系统和工具。
第二部：在所期望的最终系统和开发环境中，
标识那些会影响 SLCM选择的属性。
第三部：标识为选择生存周期自考包过 q 模型
所需要的任何约束， 包括外部约束的或是内部的。
第四部：基于以往的经验和组织能力， 评估第
一步所选择的那几个 SLCM。

95、简述模块的控制域和作用域的概念以及她们的启发式原则。 (p61)

模块的控制域是指这个模块本身以及所有直接或间接从属于它的模块的集合。
模块的作用域是指受该模块内一个判定所影响的所有模块的集合。尽力使模块的作用域在其控制域之内。

96、简述提高软件考维护性的方法。

1、建立明确的软件质量目标
2、利用先进的软件开发技术和工具
3、建立明确的质量保证工作
4、选择可维护性的程序设计语言
5、改进程序文档

97、简述结构化程序设计的基本要点

答 ：（1）、设计软件系统结构（简称软件结构）
a、采用某种设计方法，将一个复杂的系统按功能划分成模块（划分）
b、确定模块的功能 。（功能）
c、确定模块之间的调用关系（调用）
d、确定模块之间的接口，即模块之间传递的信息。（接口）
e、评价模块结构的质量（质量）
（2）、数据结构及数据库设计
a、数据结构设计
b、数据库设计：（概念设计、逻辑设计、物理设计）
（3）、编写概要设计文档（文档主要有：概要设计说明书、数据库设计说明书、用户手册、修订测试计划）
（4）、评审

98、如何理解模块独立性什么指标来衡量模块独立性/h1>

答：模块独立的概念是模块化、抽象、信息隐蔽和局部化概念的直接结果。
模块的独立性很重要：第一，有效的模块化（即具有独立的模块）的软件比较容易开
发出来。第二，独立的模块比较容易测试和维护。 模块的独立程度可以由两个定性标准
度量，分别是内聚和耦合。内聚衡量一个模块内部各个元素彼此结合的紧密程度；耦合衡量不同模块彼此之间互相依赖（连接）的紧密程度。

99、软件重用的效益是什么/h1>

答：1) 软件重用可以显着地改善软件的质量和可靠性； 2) 软件重用可以极大地提高软
件开发的效率； 3) 节省软件开发的成本， 避免不必要的重复劳动和人力、 财力的浪费。

100、需求规约的作用是什么/h1>

答：需求规约的作用可概括为以下 4 点：
1）需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。
2）对于项目的其余大多数工作， 需求规约是一个管理控制点；
3）对于产品 / 系统的设计，需求规约是一个正式的、受控的起始点；
4）需求规约是创建产品验收测试计划和用户指南的基础。

101、简述模块独立性的原则。

答：模块独立性是指软件系统中每个模块只涉及软件要求的具体子功能，而和软件系统中其他的模块接口是简单的，模块独立性的概念是模块化、抽象、信息隐蔽和局部话概念的直接结果，由耦合和内聚 2 个标准度量。

102、简述软件开发的本质以及基本途径。

105、为什么说“UML 是一种可视化的建模语言，而不是一种特定的软件开发方法学”

107、简述控制流程图的概念、基本元素以及它与程序流程图的差异。

111、简述结构化设计中的启发式规则。

113、简述软件开发的本质。

（ 1）软件开发的目标是将问题域中的概念映射为运行平台层面上的概
念，把问题域中的处理逻辑映射为运行平台层面上的处理逻辑；
（2）软件开发就是要弥补问题域与运行平台之间的距离， 从而在两者之
间直接进行映射；
（3）软件开发的本质概括为： 不同抽象层术语之间的映射， 以及不同抽
象层处理逻辑之间的映射。

114、简述常用的初始需求发现技术。

116、简述 CMMI 成熟度等级的概念、划分和组成。

118、什么是需求规约 述需求规约的基本性质。

119、简述快速原型的开发步骤。

答：快速原型开发步骤可划分下列阶段：
（1）快速分析：迅速确定基本需求、集中力量确定需求说明。
（2）快速构造原型：在快速分析基础上，在强有力的软件工具支持下，快速构造所需原型。
（3）运行原型：在开发者指导下，用户参与原型的运行，各类人员在共同运行原型中进一步加深对系统的了解及相互间的
理解，以发现各种问题。
（4）评价原型；在运行基础上，根据原型目标，考核原型的特性，分析原型效果是否满足用户需求，提出修改意见。
（5）修改原型：在评价基础上进行修改。若不满足需求说明，则根据明确的需求修改原型。若不满足用户需求，则先修改

120、软件生存周期可以分为几个阶段，每个阶段的提交物是什么/h1>

(1)可行性研究和项目开发计划，提交项目开发计划
和可行性分析 告；
(2)需求分析，提交软件需求说明书；
(3)概要设计，提交概要设计说明书；
(4)详细设计，提交详细设计说明书；
(5)编码，提交源程序清单；
(6)测试，提交测试 告；
(7)维护，提交维护 告。

121、简述面向对象的特征。

(1)对象唯一性： 每个对象都有自身唯一的标识， 通
过这种标识，可以找到相应的对象。
（2）分类性：分类性是指将具有一致的数据结构 （属
性）和行为（操作）的对象抽象成类。
（3）继承性：继承性是子类自动共享父类数据结构
和方法的机制，这是类之间的一种关系。
（4）多态性：多态性是指相同的操作或函数、过程
作用于多种类型的对象上并获得不同的结果。不同
的对象收到同 一消息可以产生不同的结果。

122、简述黑盒测试技术的要点。 P186

答：黑盒测试技术的要点：
（1）支持测试工程模型的中间部分；
（2）事务流测试技术是将路径测试技术用于功能测试的产物，是一种实用的功能测试技术，通过事务的操
作逻辑发现软件中的错误；
（3）事务流测试技术是基于软件规约的，对错误的假定是软件通过了与预想不同的事务路径；
（4）基于事务的基本操作；事务流测试技术的最大问题和最大代价是获取事务流程图及用例设计；
（5）事务处理流程测试要达到基本的测试覆盖。

123、简述 RUP 中需求获取的基本步骤和相关制品。 P132

答：需求获取的步骤和相关制品：
第 1 步是列出候选的特征，相关制品是特征表；
第 2 步是理解系统语境，相关制品是领域模型或业务模型；
第 3 步是捕获系统功能需求，相关制品是用况模型（ use case模型）；
第 4 步是捕获非功能需求，相关制品是补充的需求或针对特殊需求的用况。

124、简述软件开发的本质。
答：软件开发的本质就是实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射。

简述实施软件开发的基本途径。
答：实施软件开发的基本途径是系统建模。 所谓系统建模， 是指运用所掌
握的知识，通过抽象，给出该系统的一个结构——系统模型。

125、简述软件开发所涉及的两大类技术。

答：软件开发所涉及的两大类技术为：一是求解软件的开发逻辑，二是求解软件的开发手段。

126、简述需求与需求规约的基本性质。

答：需求的基本性质：
1） 必要的，该需求是用户所要求的。
2）无歧义的，该需求只能用一种方式解释。
3 ）可测的，该需求是可进行测试的。
4 ）可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段。
5 ）可测量的，该需求是可测量的。

127、需求规约的基本性质：

1 ）重要性和稳定性程度：按需求的重要性和稳定性，对需求进行分级。
2 ）可修改的：在不过多地影响其他需求的前提下，可以容易地修改一个单
一需求。
3）完整的：没有被遗漏的需求。
4）一致的：不存在互斥的需求。

128、简述软件需求的分类。

答：软件需求可以分为两大类：一类是功能需求，一类是非公能需求，而非公
能需求可分为性能需求，外部接口需求、设计约束和质量属性需求。

129、有哪几种常用的初始需求发现技术br> 答：有 5 种常用的需求发现技术：自悟、交谈、观察、小组会和提炼。

130、简述需求规约的 3 种基本形式。

（1） 非形式化的需求规约。非形式化的需求规约即以一种自然语言来表达
需求规约，如同使用一种自然语言写了一篇文章。
（2） 半形式化的需求规约。 半形式化的需求规约即以半形式化符 体系 （包
括术语表、标准化的表达格式等）来表达需求规约。
（3）形式化的需求规约。 形式化的需求规约即以一种基于良构数学概念的符 体系来编制需求规约，一般往往伴有解释性注释的支持。

131、简述需求规约在项目开发中的基本作用。

答：需求规约的作用可概括为以下 4 点：
1）需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功
能及其环境的体现。
2 ）对于项目的其余大多数工作，需求规约是一个管理控制点。
3 ）对于产品 / 系统的设计，需求规约是一个正式的、受控的起始点。
4 ）需求规约是创建产品验收测试计划和用户指南的基础。

132、、简述需求规约和项目需求的不同。

答：需求规约和项目需求是两个不同的概念。 需求规约是软件开发组织和用户
之间一份事实上的技术合同书，即关注产品需求，回答“交付给客户的产品 / 系统是什么”；而项目需求是客户和开发者之间有关技术合同——产品 / 系统需求的理解，
应记录在工作陈述中或其他某一项目文档中，即关注项目工作与管理，回答“开发组要做的是什么”

133、 简述瀑布模型以及可适应的情况

瀑布模型将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到产品适应情况：需求已被很好的理解，并且开发组织非常熟悉为实现这一模型所需求的过程。

134、什么是验证和确认述它们的作用和区别

答：验证：证实一个过程或项目的每一个软件工作产品 / 服务是否正确地反映所规约的需求验证和确认是有区别的。
验证