一

1. 原型化方法是一种动态定义需求的方法，提供完整定义的需求不是原型化方法的特征，其特征包括尽快建立初步需求、简化项目管理以及加强用户参与和决策。

1. 软件危机的表现包括用户对已完成的软件系统不满意的现象经常发生、软件产品的质量往往靠不住、软件通常没有适当的文档资料以及对软件开发成本和进度的估计常常很不准确。
2. 软件是一种逻辑产品。
3. 软件开发通常是为另一种文化背景的人创造产品。
4. 软件工程7条基本原理分别是用分阶段的生命周期计划严格管理、坚持进行阶段评审、实现严格的产品控制、采用现代程序设计技术、结果应能清楚地审查、开发小组的人员应少而精以及承认不断改进软件工程实践的必要性。
5. 喷泉模型是面向对象的过程模型。
6. 关于软件生命周期：软件生命周期由软件定义、软件开发以及运行维护（软件维护）三个时期组成；其中软件定义时期通常由问题定义、需求分析和可行性研究三个阶段组成。软件开发时期通常由总体设计、详细设计、编码和单元测试以及综合测试四个阶段组成，前两个阶段又被称为系统设计，后两个阶段又被称为系统实现。软件维护时期则不再进行进一步的阶段划分。
7. 在信息系统集成项目开发的开始阶段，如果项目存在很多不确定因素，且项目的参与人员还不能完全理解项目开发的范围和需求，那么采用增量迭代模型或螺旋模型作为此项目的开发模型更符合项目的实际情况。
8. 瀑布模型的缺点是缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题，其特点是将开发过程严格地划分为一系列有序地活动，适用于需求明确或很少变更的项目。
9. 螺旋模型可以看做在每个阶段之前都增加了风险分析过程的快速原型模型。也可以看做将瀑布模型和增量模型相结合，并增加了风险分析。
10. 螺旋模型建立在快速原型的基础上，沿着螺线自内向外每旋转一圈，就得到原型的一个版本。
11. 原型化方法是动态确定软件需求的方法之一，该方法适用于需求不确定性高的系统。
12. 通常把软件生命周期全过程中使用的一整套技术方法的集合称为方法学，其包含三个要素分别是过程、工具和方法。
13. RUP（Rational Unified Process，统一软件开发过程）的4个工作阶段分别是初始、细化、构造和移交；六大最佳实践是迭代式开发、管理需求、基于构件的体系结构、可视化建模、验证软件质量以及控制软件变更。
14. RUP软件开发生命周期是一个二维的生命周期模型。
15. 快速原型模型可以有效地适应用户需求的动态变化。
16. 喷泉模型描述了面向对象的开发模型，它体现了这种开发方法创建软件的过程所固有的迭代和无缝的特征。
17. 在软件开发项目中强调“个体和交互胜过过程和工具，可以工作的软件胜过全面的文档，客户合作胜过合同谈判，响应变化胜过遵循计划”，是敏捷方法的基本思想，即适应性和以人为本。
18. 信息系统的开发方法有很多种，开发人员可以根据项目的需要选择一种合适的开发方法，其中把整个系统的开发过程分成若干阶段，然后一步一步地依次进行开发的方法称为结构化方法。
19. 计算机辅助软件工程，简称CASE。
20. 软件工程学科出现的主要原因是软件危机的出现。
21. 软件工程诞生于1968年的NATO会议。
22. 极限编程的有效实践有客户作为开发团队的成员、使用用户素材、短交付周期、验收测试、结对编程、测试驱动开发、集体所有、持续集成、可持续的开发速度、开放的工作空间、及时调整计划、简单的设计、代码重构以及使用隐喻。

二

1. 软件需求说明书，又称为软件规格说明书，是分析员在需求分析阶段需要完成的文档，是软件需求分析的最终结果。
2. 需求规格说明书（SRS）在软件开发中具有重要的作用，其可以作为软件设计的依据，是用户和开发人员对软件要“做什么”的共同理解，也是软件验收的依据，但它不能作为软件可行性分析的依据。
3. 可行性研究分析报告包括社会因素可行性分析、经济可行性分析、操作可行性分析以及技术可行性分析。
4. 在软件开发过程中常用图作为描述工具，DFD就是面向数据流分析方法的描述工具。在一套分层DFD中，如果某一张图中有N个加工，则这张图允许有0~N张子图。在一张DFD图中，任意两个加工之间可以有0条或多条名字互不相同的数据流。在画分层DFD时，应注意保持父图与其子图之间的平衡。DFD中从系统的输入流到系统的输出流的一连串连续交换形成一种信息流，这种信息流可以分为变换流和事务流两类。
5. 需求获取技术有原型评估、场景分析、现场考察和会议研讨。
6. 数据流图是用于表示软件模型的一种图示方法，自顶向下、分层绘制和逐步求精是最常采用的。
7. 数据流程图上的数据流必须封闭在外部实体之间。
8. 可行性研究实质上是进行了一次大大压缩简化了的系统分析和设计的过程。
9. 系统流程图是描绘系统物理模型的传统工具。
10. 数据流图的符号由基本符号和附加符号两种组成。
11. 软件需求分析所要做的工作是清晰描述软件的功能和非功能需求。
12. 状态转换图是表示系统行为的重要模型之一。
13. DFD基本符号包括数据的源点/终点、数据存储、数据流和数据处理。
14. 可行性分析就是回答“是否值得做”的问题。
15. E-R图中，包含实体、属性、关系等基本成分。
16. 功能模型、行为模型和数据模型都属于结构化分析模型。
17. 非功能需求必须依附于功能需求而存在。
18. 进行需求分析可使用多种工具，但PAD图是不适用的。
19. 与软件工程不同，最优化是系统工程所追求的目标。
20. 需求分析是软件开发工作的基础。
21. 软件需求分析的任务不应该包括结构化程序设计。

三

1. 按照模块独立性，耦合程度由强至弱的正确顺序是内容耦合、公共耦合、控制耦合、数据耦合；要尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不使用内容耦合。
2. 模块内部聚合程度由强至弱的正确顺序是高内聚：功能内聚、顺序内聚；中内聚：通信内聚、过程内聚；低内聚：时间内聚、逻辑内聚、偶然内聚；为了提高模块的独立性，模块内部最好是功能内聚。
3. 软件设计的任务是在需求的基础上，给出被建系统的软件设计方案，一般来说，软件设计包括总体设计和详细设计。
4. 面向数据流的设计方法将DFD映射成为软件结构。
5. 模块化、信息隐藏、抽象和逐步求精的软件设计原理有助于得到高内聚、低耦合度的软件产品。
6. 设在一个模块内有两个判定，若其中一个判定影响到的模块集合为A，而受另一个判定影响到的模块集合为B，则该模块的作用域范围是A+B。
7. 设计模块时，模块的作用域应该在控制域之内，模块的作用域是受该模块内一个判定影响的所有模块的集合。模块的控制域是这个模块本身以及所有直接或间接从属于它的模块的集合。
8. 在SD（结构化设计）方法中全面指导模块划分的最重要的原则是模块独立性。
9. 软件设计中的接口设计指定各个组件之间的通信方式以及各组件之间如何相互作用。
10. 程序的质量主要取决于软件设计的质量。
11. 局部化是指把一些关系密切的软件元素物理地放得彼此靠近。
12. 软件总体结构设计，顶层扇出的上限是5-9个。
13. 面向数据流的设计方法根据数据流的不同所采取的映射策略也不同。
14. 以变换为中心的分析首先应确定输入和输出边界。
15. 深度表示软件结构中控制的层数，宽度是软件结构内同一层次上模块总数的最大值，扇出是一个模块直接控制（调用）的模块数目，扇入表明有多少个上级模块直接调用它。

四

1. 详细设计阶段用到的工具有程序流程图、盒图（N-S）、问题分析图（PAD）、判定表、判定树以及过程设计语言（伪码）（PDL）。
2. PAD图的主要优点有：（1）使用表示结构化控制结构的PAD符号所设计出来的程序必然是结构化程序、（2）PAD图所描述的程序结构十分清晰、（3）用PAD图表现程序逻辑，易读、易懂、易记、（4）容易将PAD图转换成高级语言源程序、（5）既可用于表示程序逻辑，也可用于描绘数据结构、（6）PAD图的符号支持自顶向下、逐步求精方法的使用。
3. 环形复杂度为10是模块规模大小的一个更为科学的上限。
4. 判定树和判定表可以表示复杂的条件组合与应做的动作之间的对应关系。
5. PAD的控制执行流程为自上而下、从左到右。
6. 结构化程序设计的三种基本控制结构不包括多分支。
7. 程序流程图不易表示数据结构和调用关系。
8. 常见的帮助设施主要有集成式和附加式两种。
9. 用户界面设计是一个迭代的过程。
10. 程序流程图的主要缺点如下：（1）程序流程图本质上不是逐步求精的好工具，它诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构。（2）程序流程图中用箭头代表控制流，因此程序员不受任何约束，可以完全不顾结构程序设计的精神，随意转移控制。（3）程序流程图不易表示数据结构。
11. 详细设计的结果基本决定了最终程序的质量。
12. PDL（伪码）作为一种设计工具具有如下一些优点：（1）可以作为注释直接插在源程序中间。（2）可以使用普通的正文编辑程序或文字处理系统，很方便的完成PDL的书写和编辑工作。（3）已经有自动处理PDL的程序存在，而且可以自动由PDL生成程序代码。
13. 盒图（N-S）的特点有：（1）功能域（即一个特定控制结构的作用域）明确，可以从盒图上一眼就看出来。（2）不可能任意转移控制。（3）很容易确定局部和全程数据的作用域。（4）很容易表现嵌套关系，也可以表示模块的层次结构。
14. PDL描述处理过程怎么做。
15. 环形复杂度计算方式：

五

1. 使用白盒测试方法时，应根据程序的内部逻辑和指定的覆盖标准来确定测试数据。
2. 程序员在编程时将程序划分为若干个关联的模块。第一个模块在单元测试中没有发现缺陷，程序员接着开发第二个模块。第二个模块在单元测试中有若干个缺陷被确认。对第二个模块实施了缺陷修复后，再测试模块一和模块二，用更多的测试用例测试模块二符合软件测试的基本原则。
3. 测试覆盖中语句覆盖的覆盖能力最弱，条件组合覆盖的覆盖能力最强。通常来说语句覆盖<判定覆盖（分支覆盖）<条件覆盖<判定/条件覆盖<条件组合覆盖。但是判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖。
4. 编码就是把软件设计结果翻译成某种程序设计语言书写的程序。
5. 软件测试的步骤包括模块测试、子系统测试、系统测试、验收测试和平行运行。
6. 一般来说与设计测试数据无关的文档是项目开发计划。
7. 设计测试用例是测试阶段的关键技术问题，基本目标是选用最少量的高效测试数据，做到尽可能完善的测试，从而尽可能多地发现软件中的问题。
8. 成功的测试是指运行测试用例后发现了程序错误。
9. 穷举测试是不可能的。
10. 在集成测试时，通常可采用自顶向下和自底向上两种渐增式集成。在自底向上集成时，一般要设计驱动模块，但不必设计桩模块。在自顶向下集成时，可以采取深度优先的方法也可以采取宽度优先的方法。
11. 验证软件需求的方法主要靠人工审查的方法。
12. 除了测试程序之外，黑盒测试还适用于测试软件需求分析阶段的软件文档。
13. Alpha测试是指最终用户在开发环境下，开发人员在场的情况下所进行的测试。Beta测试是指最终用户在真实应用场景下，开发人员不在场的情况下所进行的测试。
14. 程序设计风格除了要考虑程序内部文档，还需要考虑效率、输入输出、数据说明和语句构造。
15. 黑盒测试是从用户观点出发的测试。

六

1. 软件生命周期中最长的阶段是维护阶段。
2. 对象是类的实例，类是创建对象的模板，类是一组具有共同特征的对象集合。
3. 封装是一种信息隐藏技术，目的是使对象的生成者和使用者分离，使对象的定义和实现分开。
4. 类之间共享属性与服务的机制称为继承。
5. 面向对象的类层次结构中，聚集关系是一种“整体-部分”关系。
6. 各类软件维护活动中，完善性维护占整个维护工作的比重最大。
7. 面向对象分析和设计涉及到三个方面的内容：一套完善的建模符号、一系列有效的分析步骤和一个方便易用的建模工具。
8. 对象图是描述系统中在某一时刻，一组对象以及它们之间关系的图形，其可以看作是类图在系统某一时刻的实例。
9. 正向工程是把模型转换为代码，逆向工程是把代码转换为模型。
10. 用例图是从用户的观点描述系统功能，它由一组用例、参与者以及它们之间关系所组成。
11. 软件文档是软件工程实施中的重要部分,它不仅是软件开发各阶段的重要依据,而且是影响软件可维护性的重要因素。
12. 确定角色一般是用例模型的任务。

七

1. 在状态图中，事件表示两个状态之间的关系。
2. 在UML中，泳道把活动图中的活动划分为若干组，并将划分的组指定给对象，这些对象必须履行该组所包括的活动，它能够明确地表示哪些活动是由哪些对象完成的。
3. 类图是表达系统类及其相互联系的图示，它是面向对象设计的核心，建立状态图、协作图和其他图的基础。
4. 状态图描述一个对象在不同事件的驱动下发生的状态迁移。
5. 面向对象的分析过程主要包括三项内容：理解、表达和验证。
6. 构成对象的两个主要因素是属性和服务。
7. 在确定类时，所有名词是候选类。
8. UML提供了一系列的图支持面向对象的分析与设计，其中类图给出系统的静态设计视图；状态图对系统的行为进行组织和建模是非常重要的；顺序图和活动图都是描述系统的动态视图，其中顺序图描述了以时间顺序组织的对象之间的交互活动；用例图从用户的角度来描述系统的功能。
9. 一般从用例图中可以分析得到的类有边界类、实体类和控制类。
10. 面向对象的动态模型中，每张状态图表示某一个类的动态行为。
11. 面向对象的分析方法主要是建立三类模型，即对象模型、动态模型以及功能模型。
12. 状态图中不能表示类的概念。
13. 顺序图中每个对象向下方向伸展的虚线是对象的生命线。
14. 一般在建立动态模型和功能模型之后，最终确定对象类中应有的服务。
15. 表示对象的相互行为的模型是动态模型。

八

1. 设计阶段的任务是及时把分析阶段得到的需求转变成符合各项要求的系统实现方案。
2. 面向对象的设计准则有信息隐藏、模块化、可重用、抽象。
3. 相同的操作名在同一个类中可以被定义多次，按参数的个数，种类或次序等的不同对它们进行区分，这种现象在面向对象方法中被称为重载。