软件工程复习

复习大纲

第一章

• 软件：软件是逻辑和物理的系统，由程序、文档、数据和其他相关元素构成。软件是一个过程的抽象表示

• 软件工程：应用系统化、学科化、定量的方法，来开发、运行和维护软件，即将工程应用到软件。以及对以上过程中各种方法的研究

• 软件危机：在计算机软件的开发和维护过程中所遇到的一系列严重问题

  软件危机的表现：

  • 开发成本和进度估计不准，开发进度难以控制
  • 用户对“已完成的”软件系统不满意
  • 软件质量和可靠性差强人意
  • 软件常常是不可维护的
  • 软件通常没有适当的文档资料
  • 软件成本逐年上升
  • 软件开发生产率滞后于硬件和计算机应用普及

• 软件工程原则

  • 使用阶段性生命周期计划的管理
  • 进行连续的验证
  • 保证严格的产品控制
  • 使用现代编程工具和工程实践
  • 保持清晰的责任分配
  • 用更好更少的人
  • 保持过程改进

第二章

• 软件过程：开发和维护软件及其相关产品所涉及的一系列活动

• 过程模型： 软件过程模型是软件开发全部过程、活动和任务的结构框架

• 瀑布模型

  • 特点

    阶段间具有顺序性和依赖性。推迟实现的观点。每个阶段必须完成规定的文档; 每个阶段结束前完成文档审查,及早改正错误

  • 优点

    • 简单，过程透明性高，过程可管理性高
    • 推迟实现，软件实现前必须进行系统分析和设计工作
    • 以阶段评审和文档控制为手段进行质量控制，能够及时发现并纠正软件缺陷，能够达到预期质量要求

  • 缺点

    • 模型灵活性差，不适合需求不明确或准确的场合
    • 模型风险控制能力弱
    • 过多的文档增加了工作量，当技术具有不确定性情况下完全以文档来评估项目进度时会产生错误的结论

  • 适用场合：适用于系统需求明确、技术成熟、工程管理较严格的场合

• 演化模型-原型模型

  • 优点

    • 强调用户参与和决策，强化了用户与开发人员的沟通

    • 可加快需求的确定，能够处理需求的不确定性和风险

    • 简化了项目管理、缩短了开发时间、降低了风险和开发成本

  • 缺点

    • 不适用于开发大型系统

    • 软件可维护性差

    • 用户合作要求高，如果合作不好，反而会拖延开发进度

  • 适用情况：客户定义一个总体目标集，但是他们并不清楚系统的具体输入输出；或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式

• 增量模型

  • 特点

    • 在前面增量的基础上开发后面的增量
    • 每个增量的开发可用瀑布或快速原型模型
    • 迭代的思路

  • 优点

    • 引入增量包概念，不需要提供完整的需求
    • 在项目的初始阶段不需要投入太多的人力资源
    • 增量可以有效地管理技术风险，降低系统失败风险
    • 有利于增加客户信心，提高系统可靠性、可维护性和稳定性

  • 缺点

    • 增量粒度难以选择
    • 确定所有的基本业务比较困难

• RAD

  • 缺点

    • 对大型项目而言，RAD 需要足够的人力资源
    • 由于时间约束，开发者和客户都要实现承诺，沟通配合不当都会导致失败
    • 不适合：不能合理模块化的系统、高性能需求并且要调整构件接口的、技术风险很高的系统均不适合

  • 适用范围：管理类信息系统开发

• 螺旋模型

  • 适用范围：需求不明确、特别是大型软件系统的开发

  • 优点：

    • 支持用户需求的动态变化
    • 原型可看作可执行的需求规格说明书，易于用户和开发人员共同理解，可作为继续开发的基础，为用户参与关键决策提供了方便
    • 螺旋模型特别强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力
    • 螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险

  • 缺点

    • 如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间
    • 使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高

• 敏捷过程

  • 缺点 ： 本身不是完整的方法论，是对生命周期过程的补充

第三章

• 需求分析过程：通过对问题及环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化、最终形成需求规格说明，这一系列的活动，即为需求分析

• 需求分析步骤：需求获取，需求提炼，需求描述（需求规格书），需求验证

第四章

• 软件设计的主要技术：抽象，设计模式，模块化，信息隐藏，功能独立，细化，重构

• 主要活动：软件架构设计（概要设计），软件详细设计

• 模块化：是指解决一个复杂问题时自顶向下逐层分解成若干模块的过程。每个模块完成一个特定的子功能，所有模块按系统结构组合起来，完成整个系统所要求的功能

• 模块化设计标准

  • 模块化分解性
  • 模块化组合性
  • 模块化可理解性
  • 模块化连续性
  • 模块化保护

• 模块独立标准：耦合、内聚

第五章

• 基于代码行数的度量方法

  • 优点

    • LOC、KLOC和相关度量容易计算
    • 许多现有的软件估算模型都使用LOC和KLOC作为一项重要输入
    • 有大量的关于LOC的文献和数据

  • 缺点

    • LOC依赖于使用的语言，这对短小精悍的程序不利
    • 不太适用于非过程化语言
    • LOC是由在设计完成时候才能计算，估算需要一定程度的细节，而这些细节可能很难获得

• 基于功能点的度量方法

  代码行数和功能点之间的关系依赖于编程语言

第七章

• 软件测试的定义：1）在某种指定的条件下对操作系统或组件，观察或记录结果，对系统或组件的某些方面进行评估的过程。2）分析软件各项目以检测现有的结果和应有结果之间的差异（即软件缺陷），并评估软件各项目的特征的过程
• 软件测试目标
  • 确认系统满足其预期的使用和用户的需要。
  • 确认解决了所需解决的问题（如实现商业规则和使用合适的系统假定）。
  • 为测试的过程建立责任和可解释性。
  • 便于及早发现软件和系统的异常。
  • 及早提供软件和系统的性能评估。
  • 为管理提供真实信息，以决定在当前状态下发布产品在商业上的风险
  • 鉴别出程序在功能等方面的异常集聚之处。

第八章

• 单元测试

  • 概念： 针对软件的设计的最小单位-程序模块，进行正确性检验的测试工作
  • 主要内容：模块接口测试，局部数据结构测试，路径测试，出错处理测试，边界条件测试

• 集成测试

  • 概念：将软件集成起来后进行测试。又称为子系统测试、组装测试、部件测试

• 系统测试

  • 概念：系统测试是从用户使用的角度来进行的测试，主要工作是将完成了集成测试的系统放在真实的运行环境下进行测试，用于功能确认和验证
  • 主要内容：功能性测试、性能测试、压力测试、恢复测试、安全测试

• 验收测试
  • 概念：是软件测试部门对经过项目组内部单元测试、集成测试和系统测试后的软件所进行的测试
  • 主要内容：根据合同进行的验收测试、用户验收测试、现场测试

第九章

• 软件维护：软件维护是指由于软件产品出现问题或需要改进而对代码及相关文档的修改，其目的是对现有软件产品进行修改的同时保持其完整性
• 必要性：
  • 改正错误
  • 改善设计
  • 实现软件的改进
  • 与其他系统进行交互
  • 为使用不同的硬件、软件、系统的新性能以及通讯设备等而对软件进行改进
  • 完成遗留程序的移植
  • 软件退出使用

课程复习

斜体表示补充内容，加粗表示出过简答，着重表示会挖空，引用部分为例题

分值介绍

选择题（20道题，每题1分），判断题（10道题，每题1分），填空题（10道题，每题1分），简答题（6道题，每题5分），应用题（3道题，每题10分）

第一章

1.软件的四个层次以及各组成的定义

软件 = 程序 + 数据 + 文档

• 软件是逻辑和物理的系统，由程序、文档、数据和其他相关元素组成
• 程序是按事先设计的功能和性能要求执行的指令序列
• 数据是使程序能正确地处理信息的数据结构
• 文档是与程序开发、维护和使用有关的图文资料

2.软件的特点

• 软件是开发出来的或者说是工程化的，并不是制造出来的
• 软件开发环境对产品影响较大
• 软件开发的时间和工作量难以估算
• 用户往往不能一次性提出完整的需求，因此在经历了许多次修改后软件才能令人满意
• 几乎没有客观的标准或措施来评估软件的开发进度
• 软件的测试非常困难
• 软件不会”耗尽“
• 硬件可使用物理模型评价，而软件设计的评价取决于判断和直觉
• 硬件和软件的项目管理之间存在很大区别，传统的硬件项目控制方法应用到软件项目中可能会适得其反

3.软件的双重作用

• 一方面软件是一种产品，另一方面软件也是开发其他软件产品的工具，包括如下功能：
  • 支持或直接提供系统所需的功能
  • 控制(如操作系统)其他程序
  • 改善通信（如网络软件）
  • 帮助开发其他软件（如软件开发工具）

4.软件工程的目标

• 软件工程的目标是在给定的时间和预算内，按照用户的需求，开发易修改、高效、可靠、可维护、适应力强、可移动、可重用的软件

5.软件工程的七个原则

• 使用阶段性生命周期计划的管理
• 进行连续的验证
• 保证严格的产品控制
• 使用现代编程工具和工程实践
• 保持清晰的责任分配
• 用更好、更少的人
• 保持过程改进

6.IEEE软件工程体系的十个方面

• 需求、设计、结构、测试、维护、配置管理、工程管理、工程过程、质量、工程工具与方法

7.缺乏有力的方法学和有效的开发工具的支持，这往往是产生软件危机的原因之一

8.软件危机的表现

• 项目超出预算
• 项目超过计划完成时间
• 软件运行效率很低
• 软件质量差
• 软件通常不符合要求
• 项目难以管理并且代码难以维护
• 软件不能交付

9.对软件工程的误解（判断理解即可）

• 更多的程序员赶进度可以加快落后的项目进度
• 软件项目外包给第三方可以减轻负担
• 对目标有一般陈述就足以开始编程，可以今后再补充细节
• 一旦变成完毕并成功运行则程序员的工作就结束了
• 在程序运行之前无法评估它的质量
• 唯一可交付的工作成果是一个成功运行的项目程序
• 软件工程会创建大量不必要的文档，并且拖慢了开发进度，软件工程仅仅是文档而已

10.在软件工程中文档的作用

• 提高软件开发过程的能见度
• 记录开发过程的有关信息，便于使用与维护
• 作为开发人员阶段工作成果和结束标志
• 提高开发效率
• 提供软件运行、维护、培训的有关资料
• 便于用户了解软件功能和性能

1. 软件产品的开发主要是研制
2. 软件是一种逻辑产品
3. 软件工程出现主要是由于软件危机的出现

第二章

11.软件过程的模型的定义：

• 软件过程模型是从软件项目需求定义直至软件运行维护为止，跨越整个生命周期的系统开发、运行和维护所实施的全部过程、 活动和任务的结构框架 ，软件过程模型能直观表达软件开发总过程，明确规定软件开发要完成的主要活动任务和开发策略。

12. 瀑布模型是非迭代的，它的特点以及全部缺点

特点：

• 阶段间具有顺序性和依赖性
• 推迟实现
• 每个阶段必须完成规定的文档，没有交出合格的文
  档就是没有完成该阶段的任务
• 每个阶段结束前都要对所完成的文档进行评审，以
  便尽早发现，改正错误

缺点：

• 不够灵活。在下一阶段开始之前， 当前阶段的结果需要固定下来，这个条件非常严格
• 整体性太强。开发计划是面向单一交付日期制定的，在分析阶段出现的任何错误，都只能在软件交付给用户后才能发现。若没有正确理解用户需求，或者在设计、编码和测试阶段需求发生改变，则瀑布模型将导致软件产品的不合格（ 增加了开发的风险）
• 严格的文档驱动，比较繁琐
• 在软件开发的早期就需要投入大量的成本，使得它难以应对客户需求的变更

13.螺旋模型是风险驱动的，它的优缺点是

优点：

• 强调可选方案和限制条件，以支持现有解决方案的重用
• 维护和开发一样，是螺旋模型的一个阶段
• 评估（预算和进度）更加准确，因为重要问题能被及早发现
• 更能应对开发过程中出现的各种变化
• 软件工程师可以提前开始项目工作

缺点：

• 仅适用于内部（一个公司内部） 项目，因为开发过程中要进行风险评估，该模型不能用于合同性的软件开发
• 螺旋模型是风险驱动的，因此它适合经验丰富的员工
• 使用该模型要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识，要求开发队伍水平较高
• 只适用于大型软件的开发。如果风险分析占用了整个项目成本的主要部分，则使用该模型没有任何意义

14.增量模型的特点和优缺点,以及需要注意的问题

特点：在前面增量的基础上开发后面的增量，增量是可以运行的，在项目开发早期就可以得到程序的运行版本(常考)

优点：

• 增量包概念的引入，以及它不需要提供完整的需求。只要有一个增量包出现，开发就可以进行
• 在项目的初始阶段不需要投入太多的人力资源。如果核心产品被用户接受，才会投入更多的人力资源
• 即使开发者不能在截止日期前完成项目，项目的核心产品也能交付给用户
• 增量可以有效地管理技术风险

• 能在较短时间内向用户提交一些有用的工作产品，即从第一个增量交付之日起，用户就能做一些有用的工作
• 逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给用户带来的冲击
• 虽然在某些增量中可能遇到一些问题，但其他增量将能够成功地交付给客户
• 优先级最高的服务首先交付，然后再将其他增量逐次集成进来。因此， 最重要的系统服务将接受最多的测试，这样能够保证系统最重要的部分一般不会遭遇失败

缺点：

• 每个增量必须提供一些系统功能，这使得开发者很难
  根据客户需求给出大小适合的增量

需要注意的问题：

• 在把每个新的增量集成到现有软件体系结构中时， 必须不破坏原来已经开发出的产品

• 软件体系结构必须是开放的，即向现有产品中加入新构件的过程必须简单、方便

• 因此，采用增量模型比采用瀑布模型和快速原型模型更需要精心的设计

15.增量模型适用于软件需求不明确，设计方案有一定风险的软件项目

16.如何选择过程模型的第三点

• 软件过程决定了软件产品的质量，不同的项目需要不同的过程模型或模型的组合

17.过程和产品的关系

工具不是过程模型，软件工程以质量为中心，软件过程、工具、方法为三要素

18.软件生命周期的阶段和每个阶段的提交

• 可行性研究和项目开发计划，并提交项目开发计划和可行性研究报告
• 需求分析，提交软件需求说明书
• 概要设计以及提交概要设计说明书
• 详细设计以及提交详细设计说明书
• 编码，提交源程序清单
• 测试，提交测试报告
• 维护，提交维护报告

19.CMMI五个级别的名字和侧重点

级别	侧重点
1.初始级	有能力的人和个人英雄主义
2.可重复级	基本项目管理
3.已定义级	过程标准化
4.量化管理级	量化管理
5.优化级	持续的过程改进

20.增量模型和螺旋模型的异同

同：都是非整体的，迭代式的开发方式

不同：

• 两者迭代的层次不同，增量模型是活动级的迭代，螺旋模型是过程级的迭代
• 两者需求分析的时间不同，增量模型往往是选做整体的需求分析，再做编码和逐个的增量包开发；而螺旋模型往往是开发周期内采用瀑布模型
• 两者交付软件的时间不同，增量模型是每次增量开发都在上一次增量基础上提交新一部分软件；而螺旋模型每次迭代都提交一个新的完整的软件版本
• 两者减小风险的方式不同，增量模型避免使用未成熟的技术和经常的客户反馈降低风险；螺旋模型则直接饮用风险设计和分析

1. 大多数软件系统是不易变化的(指不易改动)的，除非它们在设计时考虑了变化
2. 目前绝大多数软件都适合快速原型技术
3. 不属于能力成熟度模型的级别:高效性(确定级≈定义级)
4. 用户和设计交互最频繁的方法：原型化方法
5. 增量构件的开发可以采用瀑布方式
6. 瀑布、演化、增量模型是常用的三种软件过程模型

第三章

21.软件需求的定义

• 软件需求表达了对解决现实世界中某类问题的产品的要求和约束

22.功能性需求和非功能性需求的定义和区别（理解例子）

设计问题和需求问题，举例非功能性需求5个

• 功能性需求：描述软件执行时的功能
• 非功能性需求：指解决问题时的约束，非功能性需求有时也称为限制或质量需求
  • 非功能性需求可进一步被分为性能要求、可维护性要求、安全需求、可靠性要求、可移植性要求、 ……

23.需求分析的4个步骤和定义

• 需求获取指的是软件需求的来源以及软件工程师收集这些软件需求的方法
• 需求分析产生操作规格参数表，指明与其他系统元件的软件接口，确定软件必须遵循的约束
• 需求定义即编写《 软件需求规格说明书》
• 需求验证即检查需求的正确性、完整性、非二义性、内部和外部的连贯性

24.需求分析的主要任务

• 准确地定义未来系统的目标，确定为了满足用户的需求系统需要做什么，并用需求规格说明书规范的形式准确地表达用户需求

25.结构化分析建立哪三种模型？核心是面向什么？分别对应什么建模？

• 核心是数据字典
• 围绕这个核心，有3种图： 数据流图（ DFD，用于功能建模）、实体-关系图（ ER图，用于数据建模）、 状态转换图（ STD，用于行为建模）

26.数据流图4种符号(只考填空)，数据流图至少有一个输入数据流和一个输出数据流

27.结构化分析方法的策略是：自顶向下逐步求精

28.UML图有：部署图、活动图、顺序或时序图、用例图、交互图、类图

29.UML动态模型的描述工具有哪三种图：顺序图、活动图、状态图

30.用例图的绘制（填空加大题），用例图有哪些元素

• 元素：用例、参与者、系统、用例之间关系

31.用例图的用途：用于需求的获取，定义和分析

32.UML中哪些是系统的参与者，可以提出哪些问题来确定？

• 谁或者什么为系统提供输入？
• 谁或者什么接收系统的输出？
• 需要与其他系统连接的接口吗？
• 是否存在在预定的时间自动触发的事件？
• 谁将维护系统中的信息？

33.顺序图的组成元素：类角色（参与者）、对象、激活期、生命线、消息

34.什么是用例图，它的作用是什么？内容是什么

• 用例图是体现一组用例、参与者和它们之间关系的图，从用户角度而不是开发者角度来描述，体现对软件开发产品的需求，分析产品所需的功能和动态行为
• 用例图对需求建模是至关重要的，其正确与否直接影响到客户对最终产品的满意度
• 内容包括了参与者、用例与拓展的泛化关系

第四章

35.软件设计包含的两类主要活动

• 软件架构设计（又称为顶层设计、概要设计）：描述软件的顶层架构和组织，划分不同的组件
• 软件详细设计：详细描述各组件以便能够编码实现

36.创新设计不是软件设计中的步骤，是需求分析中的步骤

37.模块划分不是越多越好，单个复杂度降低但接口增多，会成为一个U型曲线

38.简述模块化与软件成本间的关系

• 尽管模块分解可以简化要解决的问题，但模块分解并不是越小越好
• 当模块数目增加时，每个模块的规模将减小， 开发单个模块的成本确实减少了；但是，随着模块数目增加， 模
  块之间关系的复杂程度也会增加，设计模块间接口所需要的工作量也将增加

39.模块的扇入数大好不好？何时好何时不好？

• 模块的扇出数是指模块调用子模块的个数。 如果一个模块的扇出数过大，就意味着该模块过分复杂，需要协调和控制过多的下属模块 。
• 一个模块的扇入数越大，则共享该模块的上级模块数目越多， 但如果一个模块的扇入数太大，如超过8，而它又不是公用模块，说明该模块可能具有多个功能， 这时应当对其进一步分析并将其功能分解

40.模块独立的两个标准是什么？分别表示什么含义？

• 内聚性：模块的功能相对强度
• 耦合性：模块之间的相互依赖程度

高内聚低耦合表示独立性强的模块

41.内聚和耦合的类型，它们各自的定义和含义，顺序中最高最低是什么？

• 内聚

  • 一个模块内部各个元素之间的结合越紧密，其内聚性就越高

• 耦合

  • 耦合的强弱取决于模块间接口的复杂程度、进入或访问模块的点，以及通过接口的数据
  • 模块之间的连接越紧密，耦合性就越高，而模块的独立性就越弱

• 模块间的耦合

  

  • 非直接耦合:两个模块之间没有直接关系，即它们中的任何一个都不依赖于另一个而能独立工作
  • 数据耦合：两个模块之间仅通过模块参数交换信息，且交换的信息全部为简单数据
  • 标记耦合：两个模块之间通过参数表传递一个数据结构的一部分（如某一数据结构的子结构）
  • 控制耦合：如果一个模块传送给另一个模块的参数中包含了控制信息，该控制信息用于控制接收模块中的执行逻辑
  • 外部耦合 ：指模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）
  • 公共耦合 ：一组模块都访问同一个公共数据环境
  • 内容耦合 ：若一个模块对另一模块中的内容（包括数据和程序段）进行了直接的引用甚至修改，或通过非正常入口进入到另一模块内部，或一个模块具有多个入口，或两个模块共享一部分代码
    • 内容耦合是所有耦合关系中耦合程度最高的，会使因模块间的联系过于紧密而对后期的开发和维护工作带来很大的麻烦
    • 有两种情况：(1)进入另一模块内部 (2)模块代码重迭（只可能出现在汇编语言中）

• 模块的内聚

  

  • 巧合内聚 ：一个模块由多个完成不同任务的语句段组成，各语句段之间的联系十分松散或根本没有任何联系

  • 逻辑内聚 ：把几种功能组合在一起，每次调用时，由传递给模块的判定参数来确定该模块应执行哪一种功能

  • 时间内聚 ：一个模块包含了需要在同一时间段中执行的多个任务

  • 过程内聚 ：一个模块中的各个部分相关，并且必须按特定的次序执行

  • 通信内聚 ：一个模块中的各个部分使用同一个输入数据或产生同一个输出数据

  • 顺序内聚 ：一个模块中的各个部分都与同一个功能密切相关，并且必须按照先后顺序执行（通常前一个部分的输出数据就是后一个部分的输入数据）

    顺序内聚的例子：假设有一个按给出的生日计算雇员年龄、退休时间的子程序，如果它是利用所计算的年龄来确定雇员将要退休的时间（即：生日->年龄->退休时间），那么它就具有顺序内聚性。而如果它是分别计算年龄和退休时间的，但使用相同生日数据（即： 生日->年龄， 生日->退休时间），那它就只具有通讯内聚性

  • 功能内聚 ：一个模块中各个组成部分构成一个整体并共同完成一个单一的功能

42.设计是模块化的，换言之软件在逻辑上应划分为多个元素或子系统

结构化的设计思想是把系统设计成相对独立的，功能单一的模块组成的层次结构

43.理解模块调用的四个图（软件结构的宽度和深度，模块扇入数和扇出数）

• 模块结构最普通的形式就是树状结构和网状结构

  

  • 树状结构
    • 只有一个顶层模块，上层模块调用下层模块， 同一层模块之间互不调用
    • 在最底层可能存在一些公共模块，使得整个系统的模块结构不是严格的树状结构，这属于正常情况
  • 网状结构
    • 任意两个模块之间都可以有调用关系，因此无法分出层次。
    • 由于模块间相互关系的任意性，使得整个系统的结构十分复杂，难以处理

• 结构图

  • 模块的调用关系和接口：在结构图中，两个模块之间用单向箭头连接

  • 模块间的信息传递：当一个模块调用另一个模块时，调用模块把数据和/或控制信息传送给被调用模块，以使被调用模块能够运行

    

  • 条件调用和循环调用 ：当模块A有条件地调用另一个模块B时，在模块A的箭头尾部标以一个菱形符号；当一个模块A反复地调用模块C和模块D时，在调用箭头尾部则标以一个弧形符号

    

  • 结构图的形态特征。在图中，上级模块调用下级模块，它们之间存在主从关系

    

    • 程序结构的深度：程序结构的层次数称为结构的深度

    • 程序结构的宽度：层次结构中同一层模块的最大模块个数称为结构的宽度

    • 模块的扇入和扇出：扇出表示一个模块直接调用（或控制）的其它模块数目。扇入则定义为调用（或控制）一个给定模块的模块个数。 多扇出意味着需要控制和协调许多下属模块。而多扇入的模块通常是公用模块

44.重构的定义

• 重构是不改变代码（设计）现有功能的基础上对其内部结构进行修改的过程

45.用户界面设计由一系列分析开始

• 用户特点分析：应用从具体业务和技术资料收集而来的各种信息，定义各种最终用户的属性和配置信息
• 用户任务分析：使用结构化设计方法或面向对象方法定义用户任务和相关操作
• 应用场景分析：确定用户操作接口的呈现方式约束和布局风格约束

46.接口设计包含哪三个方面

• 内部接口：软件内部结构模块之间的接口
• 外部接口
  • 与其他软、硬件之间的接口
  • 软件与用户之间接口

外部接口设计依据环境图进行

47.信息隐藏原则

• 模块定义和设计应当保证模块内的信息（包括过程和数据）不可以被不需要这些信息的其他模块访问
• 信息隐藏原则有利于提高模块内聚性
• 有效的模块划分可以通过定义一些相对独立的模块来实现

48.架构风格和模式的简要分类

• 数据中心架构
• 数据流体系架构
• 调用和返回架构
• 面向对象架构
• 层次架构

49.结构化程序的定义

• 如果一个程序的代码块仅仅通过顺序、选择和循环这三种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的

50.程序流程图的主要缺点

• 程序流程图从本质上来说不是逐步求精的好工具，它容易使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构。
• 程序流程图中用箭头代表控制流，程序员可以不顾结构程序设计的精神，随意转移控制，而使程序结构过于混乱。
• 程序流程图在表示数据结构方面存在不足。

51.体系结构的另一种分类

• 单主机结构（集中式体系结构）
• 分布式结构
  • 多处理器体系结构
  • 客户机/服务器体系结构(C/S、B/S结构)
  • 分布式对象体系结构
  • 代理

52.概要设计包含三个层次

概要设计=体系结构设计+接口设计+数据设计

第七章

53.软件测试的基本原则

• 穷尽测试是不可能的
• 测试无法显示潜伏的软件缺陷
• 测试活动应尽早进行
• 软件缺陷具有群聚性
• 注意杀虫剂现象
• 应尽量由独立的测试团队进行测试

54.软件测试的目标

• 确认系统满足其预期的使用和用户的需要
• 确认解决了所需解决的问题
• 为测试的过程建立责任和可解释性
• 便于及早发现软件和系统的异常
• 及早提供软件和系统的性能的评估
• 为管理提供真实信息，以决定在当前状态下发布产品在商业上的风险
• 鉴别出程序在功能等方面的异常集聚之处

55.什么情况下称为发现软件缺陷

• 至少满足下列一个条件，则称发生了一个软件缺陷：
  • 软件未实现产品说明书要求的功能
  • 软件出现了产品说明书指明不能出现的错误
  • 软件实现了产品说明书未提到的功能
  • 软件未实现产品说明书虽未明确提及但应该实现的目标
  • 软件难以理解、不易使用、运行缓慢，或者测试员的角度看，最终用户会认为不好

56.测试用例的定义由哪三部分组成

• 测试用例是测试输入、 执行条件，以及预期结果的集合，是为特定的目的开发的，例如执行特定的程序路径或验证与指定的需求相符合

57.软件测试的评估准则

• 覆盖率
• 故障插入(软件缺陷)
• 变异分支

58.覆盖率的定义，100%测试率是可能的吗？为什么？

• 给定一个测试需求集合TR和一个测试集合T， 覆盖率可以定义为T满足的测试需求占TR 总数的比例
• 某些测试需求是不能满足的，例如测试需求要求每条语句都得到执行，在某些不能执行到得情况下就是不能满足的。对大多数覆盖标准，检测不可行测试在需求形式上是不可判定的。因此100%测试率在实际中是不现实的。

59.测试人员的目标是？

• 尽早找出软件缺陷，并确保缺陷得已修复

60.软件白盒、黑盒、灰盒测试的定义

• 黑盒测试：指忽略系统或组件的内部机制，仅关注于那些响应所选择的输入及相应执行条件的输出的测试形式，也称为功能性测试
• 白盒测试：指考虑系统或组件的内部机制的测试形式，也称为结构性测试。由于通常需要进行白盒测试，因此软件测试工程师也需要具有编程能力
• 灰盒测试：兼具黑盒测试和白盒测试的特性，对所有输入数据的各种可能值的排列组合都进行测试，来检查程序是否都能产生正确的输出

61.简述软件测试与调试的同与不同

• 两者都包含有处理软件缺陷和查看代码的过程
• 测试的目标是发现软件缺陷的存在， 调试的目标是定位与修复缺陷。软件测试员把问题缩减为能够演示软件缺陷的最简化测试用例（或可疑的代码行），进行调试的程序员进而判断到底是什么导致软件缺陷，并设法修复

62.软件测试的目标

• 确认系统满足其预期的使用和用户的需要
• 确认解决了所需解决的问题（如实现商业规则和使用合适的系统假定）
• 为测试的过程建立责任和可解释性
• 便于及早发现软件和系统的异常
• 及早提供软件和系统的性能的评估
• 为管理提供真实信息，以决定在当前状态下发布产品在商业上的风险
• 鉴别出程序在功能等方面的异常集聚之处

63.不同覆盖准则设计测试用例

• 语句覆盖
• 分支覆盖
• 条件覆盖
• 判定—条件覆盖
• 条件组合覆盖
• 路径覆盖

64.不同覆盖准则之间的强弱关系

• 语句覆盖是最弱的逻辑覆盖
• 分支覆盖具有比语句覆盖更强的测试能力，但仍是弱的逻辑覆盖
• 条件覆盖不一定包含分支覆盖，满足条件覆盖不一定满足分支覆盖
• 判定—条件覆盖即既满足条件覆盖，又满足判定覆盖
• 条件组合覆盖满足分支覆盖、条件覆盖准则，但可能有的路径会遗漏掉
• 路径覆盖覆盖程序中所有可能的路径

65.分支覆盖又叫判定覆盖

66.基本路径测试的控制流图与环路复杂度

• 控制流图仅描述程序内部的控制流程，完全不表现对数据的具体操作，以及分支和循环的具体条件

• 边和节点围成的封闭域叫做区域，当对区域计数时，图形外的区域也应记为一个区域

• 程序的环形复杂度 :对于一个程序的控制流图G（其中的决策节点均是基本判定），程序的环形复杂度V(G)即是控制流图中的区域数

• 也可以用以下公式计算：

  V(G)＝ e－ n＋ 2，其中 e是图G中边的数目， n是图G中节点的数目

• 可以证明：

  V(G)＝ P＋ 1,其中， P是图G中的基本判定的数目

• McCabe提出的基线方法和反转接点

67.基本路径集合不唯一但数目唯一

68.黑盒测试的3种方法和定义(补充的错误猜测法和因果图法)

• 等价类划分方法：把所有可能的输入（被测程序的输入域） 划分成若干互不相交的部分（子集），然后从每一个部分中选取少数具有代表性的数据（通常是1个） 作为测试用例
• 边界值分析方法：对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界
• 状态测试：通常，访问所有的状态是可以实现的，但除了极少数简单程序外， 不可能以走完所有分支的方式来达到每种状态，即必须选择重要的内容进行测试
• 错误猜测法：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法
• 因果图法：用图解的方法表示输入的各种组合关系，写出判定表，从而设计相应的测试用例

69.错误猜测法和因果图法

• 考虑为失效性测试设计用例，主要以已知的缺陷空间为依据设计测试用例。设计测试用例的目的是证明已知的缺陷在软件中都不存在

70.静态测试的目的和基本思想

• 静态测试的范围很广，软件开发项目中的代码、所有的文档以及项目外有价值的文档都可以通过人工方式审查。其目的是从已有的规格说明、已定义的标准以及项目的计划中发现缺陷和偏差。这些检查的结果可以用于优化开发过程
• 静态测试的基本思想是缺陷的预防，即尽可能早地在缺陷和偏差对将来开发过程产生影响之前发现并修改它们，否则会导致代价高昂的返工

71.通用评审过程的步骤

评审过程就是执行静态分析的过程:

• 计划
• 概述
• 准备
• 评审会议
• 返工
• 跟踪

72.正式评审和非正式评审的3种类型

• 同事审查(非正式)
• 走查(非正式)
• 审查 (正式)

第八章

73.V模型中四个级别的测试的主要目的或测试依据

• 单元测试的主要目的是验证软件模块是否按详细设计的规格说明正确运行
• 集成测试的主要目的是检查多个模块间是否按概要设计说明的方式协同工作
• 系统测试的主要目的是验证整个系统是否满足需求规格说明
• 验收测试从用户的角度检查系统是否满足合同中定义的需求，以及以确认产品是否能符合业务上的需要

74.系统测试的定义

• 从用户使用的角度来进行的测试，主要工作是将完成了集成测试的软件放在真实的运行环境下进行测试，用于功能确认和验证

75.验收测试中测试用例如何得到？验收测试的关注点？是否需要客户参与？

• 测试用例采用项目组的系统测试用例子集，或者由验收测试人员自行决定测试内容
• 关注点是客户的观点和判断，如果软件是为指定客户开发的，那么验收测试就更为重要。验收测试通常情况下需要客户的参与，甚至客户可以完全负责验收测试
• 验收测试在多个级别中进行

76.在改进的V模型中，测试要提前，一旦有了文档提供就可以开始测试计划，确定测试条件和编写测试用例等测试

77.回归测试

• 原因：在软件测试的各个阶段，在修正发现的软件缺陷或增加新功能时， 变化的部分必须进行再测试。此外，对软件进行修改还可能会导致引入新的软件缺陷以及其他问题。为解决这些问题，需要进行回归测试
• 回归测试是指有选择地重新测试系统或其组件，以验证对软件的修改没有导致不希望出现的影响，以及系统或组件仍然符合其指定的需求
• 回归测试可以在所有的测试级别执行，并应用于功能和非功能测试中
• 回归测试应该尽量采用自动化测试

78.4级别测试分别采用白盒测试还是黑盒测试

• 单元测试：主要采用白盒测试方法设计测试用例，但在白盒测试方法之前应该先依据详细设计说明书建立黑盒
  测试用例进行测试，使之对任何合理的输入和不合理的输入，都能鉴别和响应
• 集成测试：既有白盒测试的成分又有黑盒测试的成分，也称为灰盒测试
• 系统测试：基本上使用黑盒测试方法
• 验收测试：黑盒测试方法

79.驱动模块和桩模块的含义

• 驱动模块用来调用被测模块，使被测的模块得到执行。在绝大多数情况下， 驱动模块执行的任务是接收测试数据，把数据传送给待测模块，然后从待测模块获取返回的数据，并输出测试的结果。通常， 测试用例是在驱动模块中实现的
• 桩模块也叫做存根模块， 用以替代被测模块所调用的那些模块。桩模块的接口与其替代的模块完全一致， 但其功能非常简单，且不包含错误。桩模块的作用首先是隔离缺陷，在用桩模块替代被测模块调用的模块后，如果测试中发现问题，则问题肯定出在被测模块的内部。其次， 可以用桩模块来模拟一些被调用模块难以出现的情况（例如，数量很大的网络连接）， 降低测试的费用

80.被测模块需要驱动模块时，测试常在驱动模块中实现

81.单元测试的主要内容

• 对模块接口的测试保证在测试时进出程序单元的数据流是正确的
• 对局部数据结构的测试保证临时存储的数据在算法执行的整个过程中都能维持其完整性
• 对边界条件的测试保证模块在极限或严格的情形下仍然能够正确执行
• 控制结构中的所有独立路径（基本路径）原则上都应覆盖，以保证在一个模块中的所有语句都能至少执行一次
• 要对所有出错处理的路径进行测试

82.为什么单元测试的依据不是代码？

• 单元测试的主要依据是详细设计，而不是针对代码的测试。因为未测代码可能包含错误和缺陷，如果依照其测试，则可能无法发现一些错误

83.集成测试有哪3种集成方法？

• 自顶向下的集成方法
• 自底向上的集成方法
• Smoke方法

84.什么是自顶向下/自底向上的集成测试，它们的优缺点是什么？

• 自顶向下的集成方法：从顶层模块（主控模块）开始，沿着软件的控制层次向下移动，逐渐把各个模块结合起来，这种集成方式中，每层程序调用的下一层程序单元都要打桩，整个集成可以按深度或宽度优先进行，采用前者可以快速验证一个子系统的完整性

  • 优点：

    • 可以较早地验证主程序的功能

    • 缺陷隔离较好

    • 可以较早地验证主要的控制和判断点

  • 缺点：

    • 桩的开发量较大

• 自底向上的集成方法：是从软件结构最底层的模块开始，按照接口依赖关系逐层向上集成以进行测试。由于是从最底层开始集成，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经集成并测试完成，所以不再需要使用桩模块进行辅助测试，在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。 但需要为每个模块编写驱动模块

  • 优点：

    • 每个模块调用的各底层模块都已经测试，不需要桩模块

  • 缺点：

    • 每个模块都必须编写驱动模块
    • 缺陷隔离和定位不如自顶向下的集成方法

85.自顶向下结合的渐增式测试法在组合模块时有两种组合策略：深度优先,广度优先

86.系统测试的五种方法

• 功能性测试
• 性能测试
• 压力测试
• 恢复测试
• 安全测试

87.压力测试为比平常限度约高一个数量级输入，用来检查软件系统对异常情况的承受能力压力测试强迫系统在异常情况（如异常数量、异常频率、异常资源配置等）下运行 ，压力测试经常与性能测试一起进行

88.现场测试包含α测试和β测试，各自的定义是什么？

• α测试是用户在开发者的场所来进行的，软件在开发者对用户的指导下进行测试， 开发者负责记录错误和使用中出现的问题，α测试人员是除产品开发人员外首先见到产品的人， 他们提出的功能和修改意见是特别有价值的
• β测试是在一个开发者不能控制的真实环境中进行的软件现场应用。与α测试不同， 开发者不在测试现场。用户记录下所有在测试中遇到的问题，并定期把这些问题报告给开发者，在接到β测试的问题报告之后，开发者对系统进行最后的修改，然后就开始准备向所有的用户发布最终的软件产品

1. 单元测试主要针对模块的几个基本特例进行测试，该阶段不能完成的测试是系统功能测试
2. 接口不属于系统测试的主要内容
3. 系统测试是把软件、硬件和环境连在一起的全面测试
4. 单元测试时对所有出错处理的路径都要进行测试

89.生产力度量包括基于功能点的度量和代码行数的度量

第五章

90.FP（功能点方法）的计算

• 根据软件的每类功能的各级复杂性功能点的数量，可以计算出该软件的未调节功能点 total_counts

• 任何软件都会有其自身特性，因此前面计算出的未调节功能点（ total_counts） 还需要进行调节，即乘以一个复杂度调节因子CAF，最终得到交付功能点，教材上简称为功能点FP

  FP= total_counts× (0.65+0.01× ∑Fi)

91.LOC或FP的相关计算（记得带上单位）

• 生产率是指平均每个人月生成出多大规模的软件（生产出多少代码行数LOC或功能点FP），其单位是LOC(或KLOC)/人月、 FP/人月

• 直接测量——基于代码行数的度量即：基于代码行数（ LOC）进行度量。生产率即每人月的代码行数： 总代码行数(LOC或KLOC)/总人月, 此外， 基于LOC还可以得到其他一些度量，如：

  • 每千代码行的错误数： 总错误数/总KLOC

  • 每千代码行的缺陷数： 总缺陷数/总KLOC

  • 每千代码行的文档页数： 总文档页数/总KLO

• 间接测量——基于功能点的度量即：基于功能点（ FP）进行度量。生产率即每人月的FP数： 总FP数/总人月此外， 基于FP还可以得到其他一些度量，如：

  • 每FP的错误数： 总错误数/总FP数
  • 每FP的缺陷数： 总缺陷数/总FP数
  • 每FP的文档页数： 总文档页数/总FP数

92.LOC(代码行数)估计软件生产率的优缺点

• 优点
  • LOC、 KLOC和相关度量容易计算
  • 许多现有的软件估算模型都使用LOC和KLOC作为一项重要输入
  • 有大量的关于LOC的参考文献和数据
• 缺点
  • LOC依赖于使用的语言，这对短小精悍的程序不利
  • 不太适用于非过程化语言
  • LOC只有在设计完成时候才能计算，同时估算需要一定程度的细节，而这些细节可能很难获得。项目计划人员很难在分析和设计完成之前估算LOC

93.FP与LOC的换算

94.不应当苛刻的关注生产率度量，工程师可能会通过产生较大的LOC和FP来追求高生产率，而降低产品的质量。“低生产率的”程序员写的代码可能会更加可靠，容易理解和维护

95.COCOMO模型是成本估算模型

第九章

96.ISO-IEC 12207-2008中对软件维护的定义

• 软件维护是指由于软件产品出现问题或需要改进而对代码及相关文档的修改，其目的是对现有软件产品进行修改的同时保持其完整性

97.软件维护耗时最多的部分测试用例

98.软件维护中4种维护及每种百分比

• 纠错性维护(21%)
• 适应性维护(25%)
• 完善性维护(50%)
• 预防性维护(4%)

99.各类维护占维护工作量的比例

• 在维护阶段的最初一段时期，纠错性维护的工作量较大。随着错误发现率逐渐降低，并趋于稳定，软件进入正常使用期。然而，由于新需求的提出， 适应性维护和完善性维护的工作量逐步增加。在整个软件维护阶段花费的全部工作量中， 完善性维护占了几乎一半的工作量

100.软件维护的必要性

• 软件维护能够改正错误
• 软件维护能够改善设计
• 软件维护能够实现软件的改进
• 软件维护能够与其他系统进行交互
• 软件维护能够为使用不同的硬件、软件、系统的新性能以及通讯设备等而对软件进行改进
• 软件维护能够完成遗留程序的移植
• 软件退出使用

101.软件维护的困难性

• 配置管理工作不到位 ，软件系统的改动没有被标记，所要维护的软件无文档、文档不完整或者有些文档没有及时更新，导致维护过程中参考的是过时的文档
• 人员变动造成的影响
• 维护人员大多不是编写代码的人，所以必须先理解软件，然后才能进行维护。但是许多软件的可读性差，导致理解困难
• 往往是在任务急、时间紧的情况下处理维护请求的，这就要求维护人员必须在短时间内发现并解决问题

102.IEEE对可维护性的定义

• 是指通过一定的手段，使软件可以被维护、改进、改动或修正，以满足特定的需求的方便程度

103.估算维护工作量的模型，理解4个参数与复杂程度

维护工作量的一个模型： M=P+K·exp(c-d)

• 维护分成生产性活动（如分析评价、修改设计和编写程序代码等）和非生产性活动（如理解程序代码的功能，解释数据结构、接口特点和性能限度等）
• M是维护用的总工作量， P是生产性工作量， K是经验常数， c是复杂程度（非结构化设计和缺少文档都会增加软件的复杂程度）， d是维护人员对软件的熟悉程度

104.软件维护技术

• 程序的理解
• 软件再工程
• 软件逆向工程

105.软件再工程的定义

• 指对现有软件进行仔细审查和改造，对其进行重新构造，使之成为一个新的形式，同时包括随之产生的对新形式的实现

106.理解逆向工程的含义和主要三方面内容与过程(了解)

• 含义：分析目标系统，识别系统的构件及其交互关系，并且通过高层抽象或其他形式来展现目标系统的过程

• 主要内容：

  • ① 数据的逆向工程
  • ② 处理的逆向工程
  • ③ 用户界面的逆向工程过程：

• 过程：

  

第十章

107.P-CMM是什么？五个级别分别是？

• 人员资源管理能力成熟度模型(People Capability Maturity Model)
• 五个级别
  • 初始级
  • 管理级
  • 定义级
  • 可预测级
  • 优化级

108.软件项目管理的四要素，其中最重要的是？

• 人员(最重要)
• 产品
• 过程
• 项目

109.3种团队组织形式，名字与缩写分别是？

• 民主分权制(DD)
• 有控制的分权制(CD)
• 有控制的集中制(CC)

110.沟通是横向的还是垂直的？

• 民主分权制(DD)中对问题的解决方法都由小组达成共识，团队成员之间进行横向通信
• 有控制的分权制(CD)中小组和个人之间横向沟通，垂直控制层次的沟通都会发生
• 有控制的集中制(CC)中领导者和团队成员之间的沟通是垂直的

111.团队有没有领导者？有的话是一个还是多个？

• 民主分权制(DD)中团队没有永久的领导者，任务协调员的任期为短工期，协调不同的任务时由不同的协调员取代
• 有控制的分权制(CD)中有领导协调具体任务，也有负责子任务的次要领导人
• 有控制的集中制(CC)中团队内部问题的解决和协调是由一个团队的领导者来管理的

112.虚拟团队的定义以及优缺点?

• 定义：跨越时间、空间和组织界限，运用通信技术加强连接的队伍
• 优点：提高生产力，扩大市场机遇，进行知识转移
• 缺点：沟通不足，领导不力，团队成员不称职

113.对一个团队来说，目标是最重要的方面

114.在策划一个项目以前，应当建立产品的目标和范围，应考虑其他解决办法，以及约束技术和管理。如果没有这些信息，它无法精确地界定费用、进行有效风险评估、适当地分解项目任务、制定管理的项目进度表或提供有意义的进度估计

115.软件项目管理的第一个活动确定软件范围

116.项目估算方法

• 分解技术
• 经验模型

117.项目计划

• 软件项目计划的目的是使项目经理能够对资源、成本及时间进行合理的估算，一般是在项目开始时进行，随着项目进展定期更新。此外估算应该尝试确定最好和最坏的情况，使项目的成果是有界的
• 要注意软件项目计划不是一个静态的文件，也就是说随着项目的进行，项目组反复修正计划、更新风险估计和有关信息

118.软件开发者和客户必须一起定义产品的目标和范围。在许多情况下，这个活动开始时作为系统工程或业务过程的一部分，接下来作为软件需求分析的第一步。

119.问题分解是用来干什么的

• 将一个复杂的问题划分成更易于管理的小问题，有助于更精确地定义软件范围，从而指定更准确的项目计划

120.哪种团队组织形式会带来更高的满意度？模块化程度高或低分别对应哪一个模型？

• 民主分权制(DD)队伍结构会带来比较高的士气和工作满意度
• 民主分权制(DD)队伍结构最好应用于模块化程度相对较低的项目，因为它需要较高的通信量
• 在高度模块化的任务中，有控制的分权制(CD)和有控制的集中制(CC)队伍结构更加合适

1. 软件质量保证涵盖了整个软件开发过程
2. 问题分解不适用于对软件的详细设计

大概率出的问题

软件危机定义和表现

原因:

缺乏有力的方法学和有效的开发工具的支持，这往往是产生软件危机的原因之一

• 项目超出预算
• 项目超过计划完成时间
• 软件运行效率很低
• 软件质量差
• 软件通常不符合要求
• 项目难以管理并且代码难以维护
• 软件不能交付

软件工程的七个原则

• 使用阶段性生命周期计划的管理
• 进行连续的验证
• 保证严格的产品控制
• 使用现代编程工具和工程实践
• 保持清晰的责任分配
• 用更好、更少的人
• 保持过程改进

软件的特点

• 软件是开发出来的或者说是工程化的，并不是制造出来的
• 软件开发环境对产品影响较大
• 软件开发的时间和工作量难以估算
• 用户往往不能一次性提出完整的需求，因此在经历了许多次修改后软件才能令人满意
• 几乎没有客观的标准或措施来评估软件的开发进度
• 软件的测试非常困难
• 软件不会”耗尽“
• 硬件可使用物理模型评价，而软件设计的评价取决于判断和直觉
• 硬件和软件的项目管理之间存在很大区别，传统的硬件项目控制方法应用到软件项目中可能会适得其反

软件设计的主要技术

• 软件架构设计（又称为顶层设计、概要设计）：描述软件的顶层架构和组织，划分不同的组件
• 软件详细设计：详细描述各组件以便能够编码实现

软件过程模型的定义：

• 软件过程模型是从软件项目需求定义直至软件运行维护为止，跨越整个生命周期的系统开发、运行和维护所实施的全部过程、 活动和任务的结构框架 ，软件过程模型能直观表达软件开发总过程，明确规定软件开发要完成的主要活动任务和开发策略。

增量模型和螺旋模型的异同

• 同：都是非整体的，迭代式的开发方式
• 不同：
  • 两者迭代的层次不同，增量模型是活动级的迭代，螺旋模型是过程级的迭代
  • 两者需求分析的时间不同，增量模型往往是选做整体的需求分析，再做编码和逐个的增量包开发；而螺旋模型往往是开发周期内采用瀑布模型
  • 两者交付软件的时间不同，增量模型是每次增量开发都在上一次增量基础上提交新一部分软件；而螺旋模型每次迭代都提交一个新的完整的软件版本
  • 两者减小风险的方式不同，增量模型避免使用未成熟的技术和经常的客户反馈降低风险；螺旋模型则直接饮用风险设计和分析

需求分析过程与步骤

• 需求获取指的是软件需求的来源以及软件工程师收集这些软件需求的方法
• 需求分析产生操作规格参数表，指明与其他系统元件的软件接口，确定软件必须遵循的约束
• 需求定义即编写《 软件需求规格说明书》
• 需求验证即检查需求的正确性、完整性、非二义性、内部和外部的连贯性

结构化分析建立哪三种模型？核心是面向什么？分别对应什么建模？

• 核心是数据字典
• 围绕这个核心，有3种图： 数据流图（ DFD，用于功能建模）、实体-关系图（ ER图，用于数据建模）、 状态转换图（ STD，用于行为建模）

什么是用例图，它的作用是什么？内容是什么

• 用例图是体现一组用例、参与者和它们之间关系的图，从用户角度而不是开发者角度来描述，体现对软件开发产品的需求，分析产品所需的功能和动态行为
• 用例图对需求建模是至关重要的，其正确与否直接影响到客户对最终产品的满意度
• 内容包括了参与者、用例与拓展的泛化关系

UML中哪些是系统的参与者，可以提出哪些问题来确定？

• 谁或者什么为系统提供输入？
• 谁或者什么接收系统的输出？
• 需要与其他系统连接的接口吗？
• 是否存在在预定的时间自动触发的事件？
• 谁将维护系统中的信息？

模块的扇入数大好不好？何时好何时不好？

• 模块的扇出数是指模块调用子模块的个数。 如果一个模块的扇出数过大，就意味着该模块过分复杂，需要协调和控制过多的下属模块 。
• 一个模块的扇入数越大，则共享该模块的上级模块数目越多， 但如果一个模块的扇入数太大，如超过8，而它又不是公用模块，说明该模块可能具有多个功能， 这时应当对其进一步分析并将其功能分解

模块化模块独立的标准

• 内聚性：模块的功能相对强度
• 耦合性：模块之间的相互依赖程度

模块数量的确定

• 尽管模块分解可以简化要解决的问题，但模块分解并不是越小越好
• 当模块数目增加时，每个模块的规模将减小， 开发单个模块的成本确实减少了；但是，随着模块数目增加， 模
  块之间关系的复杂程度也会增加，设计模块间接口所需要的工作量也将增加

基于功能点和代码行数的相关指标计算，优缺点

• 优点
  • LOC、 KLOC和相关度量容易计算
  • 许多现有的软件估算模型都使用LOC和KLOC作为一项重要输入
  • 有大量的关于LOC的参考文献和数据
• 缺点
  • LOC依赖于使用的语言，这对短小精悍的程序不利
  • 不太适用于非过程化语言
  • LOC只有在设计完成时候才能计算，同时估算需要一定程度的细节，而这些细节可能很难获得。项目计划人员很难在分析和设计完成之前估算LOC

软件测试的基本原则

• 穷尽测试是不可能的
• 测试无法显示潜伏的软件缺陷
• 测试活动应尽早进行
• 软件缺陷具有群聚性
• 注意杀虫剂现象
• 应尽量由独立的测试团队进行测试

软件测试的目标

• 确认系统满足其预期的使用和用户的需要
• 确认解决了所需解决的问题
• 为测试的过程建立责任和可解释性
• 便于及早发现软件和系统的异常
• 及早提供软件和系统的性能的评估
• 为管理提供真实信息，以决定在当前状态下发布产品在商业上的风险
• 鉴别出程序在功能等方面的异常集聚之处

什么情况下称为发现软件缺陷

• 至少满足下列一个条件，则称发生了一个软件缺陷：
  • 软件未实现产品说明书要求的功能
  • 软件出现了产品说明书指明不能出现的错误
  • 软件实现了产品说明书未提到的功能
  • 软件未实现产品说明书虽未明确提及但应该实现的目标
  • 软件难以理解、不易使用、运行缓慢，或者测试员的角度看，最终用户会认为不好

白盒测试和黑盒测试的含义

• 黑盒测试：指忽略系统或组件的内部机制，仅关注于那些响应所选择的输入及相应执行条件的输出的测试形式，也称为功能性测试
• 白盒测试：指考虑系统或组件的内部机制的测试形式，也称为结构性测试。由于通常需要进行白盒测试，因此软件测试工程师也需要具有编程能力

简述软件测试与调试的同与不同

• 两者都包含有处理软件缺陷和查看代码的过程
• 测试的目标是发现软件缺陷的存在， 调试的目标是定位与修复缺陷。软件测试员把问题缩减为能够演示软件缺陷的最简化测试用例（或可疑的代码行），进行调试的程序员进而判断到底是什么导致软件缺陷，并设法修复

V模型中四个级别的测试的主要目的或测试依据

• 单元测试的主要目的是验证软件模块是否按详细设计的规格说明正确运行
• 集成测试的主要目的是检查多个模块间是否按概要设计说明的方式协同工作
• 系统测试的主要目的是验证整个系统是否满足需求规格说明
• 验收测试从用户的角度检查系统是否满足合同中定义的需求，以及以确认产品是否能符合业务上的需要

单元测试的主要内容

• 对模块接口的测试保证在测试时进出程序单元的数据流是正确的
• 对局部数据结构的测试保证临时存储的数据在算法执行的整个过程中都能维持其完整性
• 对边界条件的测试保证模块在极限或严格的情形下仍然能够正确执行
• 控制结构中的所有独立路径（基本路径）原则上都应覆盖，以保证在一个模块中的所有语句都能至少执行一次
• 要对所有出错处理的路径进行测试

集成测试有哪3种集成方法？

• 自顶向下的集成方法
• 自底向上的集成方法
• Smoke方法

4级别测试分别采用白盒测试还是黑盒测试

• 单元测试：主要采用白盒测试方法设计测试用例，但在白盒测试方法之前应该先依据详细设计说明书建立黑盒
  测试用例进行测试，使之对任何合理的输入和不合理的输入，都能鉴别和响应
• 集成测试：既有白盒测试的成分又有黑盒测试的成分，也称为灰盒测试
• 系统测试：基本上使用黑盒测试方法
• 验收测试：黑盒测试方法

软件维护的定义和必要性

• 软件维护是指由于软件产品出现问题或需要改进而对代码及相关文档的修改，其目的是对现有软件产品进行修改的同时保持其完整性
• 软件维护能够改正错误
• 软件维护能够改善设计
• 软件维护能够实现软件的改进
• 软件维护能够与其他系统进行交互
• 软件维护能够为使用不同的硬件、软件、系统的新性能以及通讯设备等而对软件进行改进
• 软件维护能够完成遗留程序的移植
• 软件退出使用

复习到此结束 希望之后有愿意看的同学 多看一下数据流图怎么画