自考软件工程（重点）

自考，软件工程，大题，涵盖了软件工程的主要知识点，适合用于软件工程课程的学习和复习，加深对相关知识的理解和掌握。

软件工程

• 1绪论
  • 软件
    • 概念：计算机系统中的程序及其文档
  • 软件工程
    • 概念：软件工程是应用计算机科学理论和技术以及工程管理原则和方法，开发软件的工程
  • 软件危机
    • 软件生产率、软件质量远远满足不了社会发展的需求，成为社会，经济发展的制约因素，人们通常把这一现象称为“软件危机”
  • 简答题
    • 软件开发的本质
      • 不同抽象层术语之间的“映射”， 以及不同抽象层处理逻辑之间的“映射”
    • 软件开发的基本途径
      • 1、过程方向，求解软件的开发逻辑 2、过程途径，求解软件的开发手段
    • 软件开发中所涉及的模型
      • 概念模型和软件模型（设计模型、实现模型、部署模型）
    • 软件开发所涉及的两大类技术
      • 一是求解软件的开发逻辑 二是求解软件的开发手段
• 2软件需求与软件需求规约
  • 软件需求
    • 以一种技术形式，描述了一个产品应该具有的功能、性能、和其他性质。
  • 功能需求
    • 规约了系统或系统构件必须执行的功能。
  • 非功能需求
    • 指性能、外部接口、设计约束、和质量属性等需求
  • 需求规约
    • 是一个软件所有需求陈述的正式文档，它表达了一个软件产品的概念模型。
  • 简答题
    • 需求与需求规约的基本性质
      • 2.需求的基本性质: (1)必要的,该需求是用户所要求的。 (2)无歧义的，该需求只能用一种方式解释。 (3)可测的,该需求是可进行测试的。 (4)可跟踪的,该需求可从一个开发阶段跟踪到另一个阶段。 (5)可测量的,该需求是可测量的。 需求规约的基本性质: (1)重要性和稳定性程度:按需求的重要性和稳定性，对需求进行分级。 (2)可修改的:在不过多地影响其他需求的前提下,可以容易的修改一个单一需求。 (3)完整的:没有被遗漏的需求。 (4)一致的:不存在互斥的需求。
    • 软件需求的分类
      • 1功能需求 2非功能需求 其中又可以分为性能需求、外部接口需求、设计约束和质量 属性需求。功能需求是整个需求的主题，即没有功能需求就 没有派生的其他功能需求，就没有性能、外部接口、设计约 束、和质量属性等非功能需求。
    • 功能需求和非功能需求之间的基本关系
      • 功能需求是整个需求的主题，即没有功能需求 就没有派生的其他功能需求，就没有性能、 外部接口、设计约束、和质量属性等非功能需求。 但非功能需求可作用于一个或多个功能需求。
    • 常用的初始需求发现技术
      • a、自悟 b、交谈 c、观察 d、小组会 e、提炼
    • 需求规约(SRS)的3种基本形式
      • 非形式化的需求规约 半形式化的需求规约 形式化的需求规约
    • 软件需求规约的内容和作用
      • 软件需求规约的内容有：引言、总体描述、特定需求、附录、索引。 作用：1)需求规约是软件开发组织和用户之间一份事实上的技术合 同书，是产品功能及其环境的体系。 (2)对于项目的其余大多数工作,需求规约是一个管理控制点。 (3)对于产品/系统的设计，需求规约是一个正式的，受控的 起始点。 (4)需求规约是创建产品验收测试计划和用户指南的基础。
    • 软件需求规约在项目开发中的基本作用
      • 1)需求规约是软件开发组织和用户之间一份事实上的技术合 同书，是产品功能及其环境的体系。 (2)对于项目的其余大多数工作,需求规约是一个管理控制点。 (3)对于产品/系统的设计，需求规约是一个正式的，受控的 起始点。 (4)需求规约是创建产品验收测试计划和用户指南的基础。
    • 需求规约和项目需求的不同
      • (1)需求规约是软件开发组织和用户之间一份事实上的技术合同 书，即关注产品需求，回答“交付给客户的产品/系统是什么”。 (2)项目需求是客户和开发者之间有关技术合同一产品/系统需 求的理解，应记录在工作陈述中或其他某一项目文档中,即关注 项目工作和管理，回答“开发组要做的是什么”
• 3结构化方法
  • 1.概要设计规约:它是面向软件开发者的文档，主要作为项目管 理人员、系统分析人员与设计人员之间交流的媒体。
  • 2.数据流图:数据流图简称为DFD图，是一种描述数据变换的图 形化工具。其中包括的元素可以是数据流、数据存储、加工、 数据源和数据潭。
  • 3.变换型数据流图:具有较明显的输入部分和变换部分之间的界 面、变换部分和输出部分之间界面的数据流图,称为变换型数据流图
  • 4.事务型数据流图:数据到达一个加工T，该加工T根据输入数据 的值，在其后的若干动作序列中选出一个来执行,这类数据流图 称为事务型数据流图。
  • 5.模块:模块是执行一个特殊任务的一个过程以及相关的数据结构。
  • 6.模块化:把一个待开发的软件分解成若干简单的，具有高内聚低耦 合的模块，这一过程称为模块化。
  • 7.内聚:内聚是指一个模块内部各成分之间相互关联程度的度量。
  • 8.模块结构图:模块结构图是一种描述软件“宏观”结构的图形化工 具。图中每个方框代表一个模块,框内注明模块的名字或主要功能。 连接上下层模块的线段表示它们之间的调用关系。
  • 9.PAD:PAD图是采用二维树形结构图来表示程序的控制流，它是日 本日立公司于1973年首先提出的。
  • 10.结构化方法:结构化方法是在20世纪70年代中后期提出的,是一种 系统化的软件开发方法,其中包括结构化分析方法、结构化设计方法 和结构化程序设计方法。
  • 简答题
    • 1.模块耦合的类型:(1)内容耦合(2)公共耦合(3)控制耦合(4)标记耦合(5)数据耦合
    • 2.模块内聚的类型:(1)偶然内聚(2)逻辑内聚(3)时间内聚 (4)过程内聚(5)通信内聚(6)顺序内聚(7)功能内聚
    • 3.总体设计的任务是把系统的功能需求分配到一个特定的软件体系结构中。
    • 4.变换设计的基本步骤如下: (1)设计准备--复审并精化系统模型 (2)确定输入、变换、输出这三部分之间的边界。 (3)第一级分解--系统模块结构图顶层和第一层的设计。 (4)第二级分解--自顶向下,逐步求精。 事务设计的基本步骤如下: (1)设计准备--复审并精化系统模型。 (2)确定事务处理中心。 (3)第一级分解--系统模块结构图顶层和第一层的设计。 (4)“第二级分解”--自顶向下,逐步求精。
• 4面向对象的方法——UML
  • 1.类:是一组具有相同属性、操作、关系和语义的对象的描述。 类主要用于抽象客观世界中的事物，可以把类表示成3个栏 目的矩形，如图4-13所示,分别代表类名、属性和操作。
  • 2.用况:是对一组动作序列的描述，系统执行这些动作应产生对 特定参与者有值的、可观察的结果。在UML中，用况用实线椭圆表示。
  • 3.状态图:强调了从一个状态到另一个状态的控制流，是显示一个状 态机的图。状态图是一个状态机中所含元素的投影,确定了一个特定的抽象层。
  • 4.细化:是类目之间的语义关系,其中一个类目规约了另一个类目执行的契约， 用一个带空心三角形的虚线段表示。
  • 5.主题:是有一组用况所描述的一个类，通常是一个系统或子系统。
  • 6.状态:是类目中的一个实例在其生存中的一个条件或情况，期间该实例 满足这一条件，执行某一活动或等待某一信息。
  • 7.对象生命线:是用于表示一个对象在一个特定的时间段中的存在，用垂直 的虚线表示对象生命线。
  • 8.聚合:是关联的一种特殊形式。对关联进行分类，满足“一个类是另一个类 的一部分”这一性质的关联称为聚合。聚合是对象之间的结构关系,不是类之 间的结构关系,用带有空心菱形的线段表示。
  • 9.构件:是系统设计中的一种模块化部件，通过外部接口隐藏了它的内部实现。 在系统中,具有共享的、相同接口的构件是可以相互替代的,但其中要保持相同 的逻辑行为，构件可以嵌套使用。
  • 10.节点:是在运行时存在的物理元素，通常表示一种具有记忆能力和处理能力 的计算机资源,一个构件可以驻留在一个节点中，也可以从一个节点移动到另 一个节点。
  • 11.主动类:是一种至少具有一个线程或进程的类,能够启动系统的控制活动，并 且其对象的行为通常是与其他元素行为并发的。
  • 简答题
    • 1.类的属性是类的一个命名特性，该特性是由该类的所有对象所共享、 用于表达对象状态的数据。 属性的可见性是指该属性是否可以被其他类所使用，具体分为: (1)公有的:可以被其他类调用。 (2)受保护的:只有其子类才能调用。 (3)私有的:只有本类的操作才能使用。 (4)包内的:只有在同一包中声明的类才能使用。 属性名是表示属性名字的标识串。 属性的类型是对属性实现类型的规约。 属性的多重性即该类实例的这一特性可以具有的值的范围,用于说明属 性值的数量。属性的初始值是给新建的对象赋予初始值。属性的性质 串是为了说明属性的性质。 属性可分为类范围的属性和对象范围的属性。
    • 2.接口的具体表现形式有: (1)采用具有分栏和关键字的矩形符号来表示。接口名可以是简单名， 也可以是受限名。 (2)采用小圆圈和半圆圈来表示。
    • 5.在对系统进行模型化时，采用以下两种方式: (1)以数据驱动:即对所标识的每一个类，如果一个类需要导航到另一 个类的对象，那么就要在这两个类之间给出一个关联。 (2)以行为驱动:即对所标识的每一个类，如果一个类的对象需要与另 一个类的对象进行交互，那么就要在这两个类之间给出一个关联。
    • 6.创建一个类图，一般涉及以下方面: (1)模型化待建系统中的概念，形成类图中的元素。 (2)模型化待建系统中的各种关系，形成该系统的初始类图。 (3)模型化系统中的协作，给出该系统的最终类图。 (4)模型化逻辑数据库模式。
    • 7.关于系统/业务语境的模型化，应研究如下问题: (1)系统边界的设定,即确定哪些行为是系统的一部分,哪些行为 是由外部实体执行的，同时定义主题。 (2)参与者与用况的交互，即在用况图中表明参与者与系统 用况之间的关系。 (3)参与者的语义表达,在需要加深理解的地方,为每个参与者 提供一个衍型 。(4)参与者的结构化处理,即将一些相似的参与者组织为一 般/特殊结构。
    • 8.为了控制交互行为描述的复杂性，以便更清晰地表达顺序图 中的复杂控制，有以下四种常用的操作子。 (1)选择执行操作子,记为“Opr”,有两部分组成,一是监护条件， 二是控制体。监护条件是一个布尔表达式，可以引用被监控对象的属性。 (2)条件执行操作子,记为“alt”,控制体通过水平线分为一个条 件分支和一个监护条件。 (3)并发执行操作子,记作“par”,控制操作子的体通过水平线将其 分为多个部分，每一部分并行计算。 (4)迭代执行操作子,记为“loop”,其中一个监护条件出现在控制体 中一条生命线的顶端。
    • 9.关联类是一种具有关联和类特性的模型元素。一个关联类可以被 看做一个关联，但还有类的特性，或者被看做一个类,但具有关联的特性。 如果关联类只有属性而没有操作和其他关联,则名字可以显示在关联 路径上,从关联类的符号中省去，以强调其关联的性质。尽管把关联 类画成一个关联和一个类,但它仍是一个单一的元素，使用关联可以 表达一个特定关联的语义。
• 5面向对象的方法——RUP
  • 1.分析类:在RUP中,分析类是类的一种衍型,很少有操作和特征标 记，而用责任来定义其行为,并且其属性和关系也是概念性的。
  • 2.用况细化:是设计模型中的一个协作，其中使用设计类及其对 象，描述一个特定用况是如何予以细化的，是如何执行的。
  • 3.控制类:封装了与特定用况有关的控制，表达复杂的 推导和计算，用于规约基本动作和控制流的处理与协 调，涉及向其他对象委派工作。
  • 4.服务包:由服务组成的包称为服务包，服务包是一个功 能包，通常包含一组功能相关的类。
  • 5.边界类:用于规约系统与参与者之间的交互，该交互一般 涉及向用户 外部系统发出请求和从他们那里接受信息。
  • 6.设计类:是对系统中一个类或类似结构的一个无缝抽 象，主要特征是操作、属性、关系方法、实现需求和 是否为主动类。
  • 7.设计子系统:可以包含设计类、用况细化、接口以及其他子系统 ;通过操作显示其功能是一种组织设计制品的手段,可使设计制品 被组织为一些更易管理的部分。
  • 8.接口:用于规约由设计类和设计子系统提 供的操作，其重要关联是细化。
  • 9、领域模型:用于捕获系统领域中的一些重要领域对象类，一般是 以类图表达的。领域模型以三种形态出现:业务对象、实在对象和概 念和事件。
  • 简答题
    • 简述用况模型的构成 1.用况模型是一种概念模型，是对系统的抽象，是系统的 一个模型。创建用况模型是捕获系统功能需求的目的。 2.给出一个系统的用况模型,主要是给出系统的用况图,给出 其中每一个参与者的描述和每一个用况的揭述。对参与者 进行描述要给出其角色和其对环境的要求;对用况的描述一 般采用正文的事件流计数,给出用况的前置条件、开始动作、 基本路径、每一个可选路径、参与者的交至以及结束动作和 后置条件。
    • 简述设计模型的四层结构 4.RUP设计的主要结果是设计模型，它尽量保持 该系统具有分析模型的结构，并作为系统实现的 输入，包含以下四个元素: (1)设计子系统和服务子系统，以及它们的接口、 依赖和内容。其中可以依据分析包来设计上面 两层的设计子系统。 (2)设计类以及它们具有的操作、属性、关系及 其实现的需求。在设计类进行设计时，分析类 作为它们的规约,有些主动类是基于分析类考虑 并发需求而设计的。 )用况细化设计]。它们描述了用况是如何设计 的，其中使用了设计模型中的协作，在进行用 况细化[设计]时，用况细化[分析]作为它们的规约。 (4)设计模型视角下的体系结构描述，其中包括 一些在体系结构方面具有重要意义的元素。
    • 5.在用况结构化中应注意以下3个问题: (1)在建立用况的结构中,应尽可能的反映用况的实际情况， 否则，不论对用户还是客户。要理解这些用况以及它们的 意图相当困难。 (2)在用况结构化中,不论是施加什么结构,新引入的用况都 不应太小或者太大。 (3)在建立用况的结构中,尽量避免对用况模型中的用况功 能进行分解。
    • 6.构造用户界面模型的目标是建造用户界面模型，基本步骤为: (1)用户界面设计。 (2)物理用户界面设计。 (3)开发用户界面原型并演示为了执行该用况，用户怎样使用该系统
    • 服务包的主要特征： 7.(1)服务包是不可分离的，即如果客户需要这一包， 就要其中的所有类。 (2)服务包之间的依赖,通常是非常受限制的。 (3)服务包一般只涉及一个参与者或很少几个参与者。 (4)服务包可以独立执行，对于同一服务的不同方面， 可以有系统的两个不同服务包所提供。
    • 8.子系统设计的目标有以下3条: (1)确保子系统可能独立于其他子系统或它们的接口 （2）确保子系统提供正确的接口 (3)确保子系统实现了它的目标，即给出了该子系统 提供的那些接口定义点的操作细化等问题。
    • 9.RUP的突出特点如下:(1)以用况为驱动。(2)以体系结构为中心。 用(3)迭代、增量式开发。
    • 10.创建系统/产品需求获取模型的四个步骤如下: (1)列出候选需求。(2)理解系统语境。 (3)捕获系统功能需求。(4)捕获非功能需求。
• 6软件测试
  • 1.静态测试:指被测试程序不在机器上运行,而是采 用人工检测和计算机辅助静态分析的手段对程序 进行检测。
  • 2.动态测试:指通过运行程序发现错误。一般意义 上的测试大多是指动态测试。
  • 3.黑盒法:该方法把被测试对象看成一个黑盒子， 测试人员完全不考虑程序的内部结构和处理过 程，只在软件的接口处进行测试,依照需求规格 说明书，检查程序是否满足功能要求。因此， 黑盒测试又称为功能测试或数据驱动测试。
  • 4.白盒法:该方法把测试对象看做一个打开的盒 子，测试人员需了解程序的内部结构和处理过 程，以检查处理过程的细节为基础，对程序中 尽可能多的逻辑路径进行测试，检查内部结构 和数据结构是否有错，实际的运行状态与预期 的状态是否一致。白盒法也不可能进行穷举测 试。
  • 5.语句覆盖:指设计足够的测试用例,使被 测程序中每个语句至少执行一次。语句覆 盖是比较弱的覆盖标准。
  • 6.分支覆盖:指设计足够的测试用例，使 得被测程序中每个判定表达式至少获得 一次“真”值和“假”值,从而使程序的 每一个分支至少都通过一次，因此分支 覆盖也称判定覆盖。
  • 7.条件覆盖:指设计足够的测试用例, 使得判定表达式中每个条件的各种 可能的值至少出现一次。
  • 8.条件组合覆盖:指设计足够的测试用例， 使得每个判定表达式中条件的各种可能的 值的组合都至少出现一次，条件组合覆盖 是比较强的覆盖标准。
  • 简答题
    • 路径测试的基本要点 2.由于路径测试技术依据的是程序的逻辑 结构，因此该技术的基本要点是: (1)采用控制流程图来表达被测程序模型， 揭示程序中的控制结构。 (2)通过合理地选择一组穿过程序的路径， 以达到某种测试度量。 3,在路径选取中，其一般原则是: (1)选择最简单的、具有一定功能含义的入 口/出口路径。 (2)在已选取的基础上,选取无循环的路径、 选取短路径、简单路径。 (3)选取没有明显功能含义的路径，此时 要研究这样的路径为什么存在。为什么 没有通过功能上合理的路径得到覆盖。
    • 4.白盒测试法的覆盖标准有:语句覆盖、判定覆盖、 条件覆盖、分支/条件覆盖、条件组合覆盖、 路径覆盖。 (1)语句覆盖发现错误能力最弱。 (2)分支覆盖包含了语句覆盖,但它可能会使 一些条件得不到测试。 (3)条件覆盖对每一条件进行单独检查,一般 情况下它的检错能力较分支覆盖强，但有 时达不到分支覆盖的要求。 (4)分支/条件覆盖包含了分支覆盖和条件 覆盖的要求,但由于计算机系统软件实现 方式的限制，实际上不一定达到条件覆 盖的标准。 (5)条件组合覆盖发现错误能力较强,凡 满足其标准的测试用例，也必然满足前 四种覆盖标准。 (6)前五种覆盖标准把注意力集中在单个 判定或判定的各个条件上，可能会使程 序某些路径没有执行到。路径覆盖根据 各判定表达式取值的组合,使程序沿着不 同的路径执行，查错能力强。但由于它 是从各判定的整体组合出发设计测试用 例的，可能使测试用例达不到条件组合 覆盖的要求。
    • 黑盒技术设计测试用例的方法以及特点： 5.(1)等价类划分。等价类划分是将输入数据城按有效的或无效的(也称合理 的或不合理的)划分成若干个等价类，测试每个等价类的代表值就等于对该 类其他值的测试。 (2)边界值分析。该方法是将测试边界情况作为重点目标，选取正好等于、 刚刚大于或刚刚小于边界值的测试数据，对程序进行测试，发现错误的 概率较大。 (3)错误推测。错误推测法没有确定的步骤,凭经验进行。它的基本思想 是列出程序中可能发生错误的情况，根据这些情况选择测试用例。 (4)因果图。因果图能有效地检测输入条件的各种组合可能会引起的错误。 因果图的基本原理是通过面因果图，把用自然语言描迷的功能说明转换 为判定表，最后为判定表的每一设计一个测试用例。
    • 6.软件产品在交付使用之前一般要经过:单元测试、集成测试、有效性 测试和系统测试四个步骤。单元测试指对源程序中每一个程序单元进 行测试，检查各个模块是否正确实现规定的功能，从而发现模块在编 码中或算法中的错误。该阶段涉及编码和详细设计的文档。 各模块经过单元测试后。将各模块组装起来进行集成测试,以检查与设 计相关的软件体系结构的有关问题。有效性测试主要检查软件已实现功 能的是否满足需求规格说明书中确定了的各种需求。系统测试指把已确 认的软件与其他系统元素(如硬件、其他支持软件、数据、人等)结合在 一起进行测试。
    • 7.单元测试主要针对模块的以下五个基本特征进行测试: (1)模块接口。 (2)局部数据结构。(3)重要的执行路径。 (4)错误处理。(5)边界测试。 在单元测试时，由于模块不是一个独立的程序，必须 为每一个模块单元测试开发驱动模块和(或)承接模块。 驱动模块模拟“主程序”接受测试用例的数据，将这 些数据传送给要测试的块并打印有关的结果。承接模 块代替被测模块的下属模块，打印入口检查信息,并将 控制返回到它的上级模块。
    • 8.使用边界值分析在设计测试用例时，应遵循的原则: (1)如果某个输入条件规定了输入值的范围，则应选择 正好等于边界值的数据，以及刚刚超过边界值的数据 作为测试数据。 (2)如果某个输入条件规定了值的个数，则可用最大个 数、最小个数、比最大个数多 1、比最小个数少1的数 作为测试数据。 (3)根据规则说明的每个输出条件,使用原则 (4)根据规则说明的每个输出条件,使用原则 (5)如果程序的规格说明中,输入域或输出域 是有序集合,在实践中则经常选取集合的第 一个元素、最后一个元素以及典型元素作 为测试用例。 (6)如果程序中使用了内部数据结构,则应当选择这个内 部数据结构的边界上的值作为测试用例。 (7)分析规格说明，找出其他可能的边界值。
    • 9.利用因果图测试技术生成测试用例的基本步骤: (1)通过软件规格说明书的分析，找出一个模块的 原因和结果，并给每一个原因和结果赋予一个标 识符。 (2)分析原因与结果之间以及原因与原因之间的对 应关系，并画出因果图。 (3)在因果图上标识出一些特定的约束或限制条件。 (4)把因果图转换成判定表。 (5)把判定表的每一列拿出来作为依据，设计测 试用例。
    • 10.自顶向下的集成测试是一种递增组装软件的方法。 从主控模块(主程序)开始,沿控制层次向下，先深度 或先宽度地将模块逐一组合起来，形成与设计相符 的软件结构。 自底向上的集成测试从软件结构最低的一层开始,逐 层向上地组合模块并测试。 自顶向下和自底向上的集成测试均有缺点。自顶 向下的主要缺点是需要设计承接模块以及随之而带 来的困难。自底向上的主要缺点是只有在加上最后 一个模块时，程序才作为一个实体而存在。
    • 11·黑盒测试法把程序看成一个黑盒子，完全不考虑 程序的内部结构和处理过程。黑盒测试是在程序接 口进行的测试，它只检查程序功能是否能按照规格 说明书的规定正常使用,程序是否能适当地接收输入 数据产生正确的输出信息，并且保持外部信息的完 整性。黑盒测试又称为功能测试。 常用的黑盒测试方法有等价类划分、边界值划分、 错误推测、因果图。
    • 12.软件测试在软件开发阶段的地位和作用:软件测试是 保证软件质量的关键步骤，是对软件规格说明、设计和 编码的最后复审。 软件测试与软件调试的区别: (1)测试从一个侧面证明程序员的“失败”,调试 是为了说明程序员的正确。 (2)测试以已知条件开始，使用预先定义的程序且 有预知的结果，不可预见的仅是程序是否通过。调 试一般是以不可知的内部条件开始，除统计性调 试外，结果不可预见的。 (3)测试是有计划的，并要进行测试设 计。调试不受时间约束的。 (4)测试是一个发现错误、改正错误、重新测试的过 程。调试是一个推理过程。 (5)测试执行时是有规程的。调试的执行往往要求程 序员进行必要的推理。 (6)测试经常是由独立的测试组在不了解软件设计的 条件下完成的。调试必须有了解详细设计的程序员完成。 (7)大多数测试的执行和设计可由工具支持。 调试时，程序员能利用的工具主要是调试器。
• 7软件生存周期过程
  • 1.软件工程过程：软件工程过程规定了获取、供应、 开发、操作和维护软件时，要实施的过程、活动和 任务。其目的是为各种人员提供一个公共的框架， 以便用相同的语言进行交流
  • 2.软件生存周期:是指一个软件从提出开发要求开始到该软件 报废为止的整个时期。
  • 3.软件生存周期模型:是一个包括软件产品开发、运行和 维护中有关过程、活动和任务的框架,覆盖了从该系统的 需求定义到系统的使用终止。
  • 4.瀑布模型:是将软件生存周期各个活动规定为依线性 顺序连接的若干阶段的模型。这一模型规定了各开发 阶段的活动:系统需求、软件需求、需求分析、设计、 编码、测试和运行、且自上而下具有相互衔接的固定 顺序;还规定了每一阶段的输入、即工作对象以及本阶 段的成果作为输出传送到下一阶段。
  • 5.增量模型:是一种非整体开发的模型。 软件在该模型中是“逐渐”开发出来的,开发出一 部分，向用户展示一部分，可让用户及早看到部 分软件，及早发现问题。或者先开发一个“原型” 软件，完成部分主要功能，展示给用户并征求意 见，然后逐步完善,最终获得满意的软件产品。该模 型具有较大的灵活性,适合于软件需求不明确、设 计方案有一定风险的软件项目。
  • 6.演化模型:主要针对事先不能完整定义需求的软件开发的。 在用户提出待开发系统的核心需求的基础上，软件开发人 员按照这一要求，首先开发一个核心系统并投入运行，以 便用户能够有效地提出反馈,即提出精化系统、增强系统能 力的需求;接着,软件开发人员根据用户反馈，实施开发的迭 代过程;每一选代过程均由需求、设计、编码、测试、集成 等阶段组成，为整个系统增加一个可定义的、可管理的子 集;如果在一次选代中，有的需求不能满足用户的要求，可 在下一次迭代中予以修正。
  • 7.螺旋模型:将瀑布模型与增量模型结合起来，加入了两种 模型均忽略了的风险分析，弥补了这两种模型的不足。因 而它是一种风险驱动的模型。螺旋模型将开发过程分为几 个螺旋周期,每个螺旋周期大致和瀑布模型相符合。
  • 9.软件开发方法:是一种使用早已定义好的技术集及符 号表示习惯来组织软件生产的过程。
  • 10.基本过程:是指那些与软件生产直接相关的活动集。 该过程又可分为获取过程、供应过程、开发过程、运 行过程和维护过程。
  • 11.支持过程:是指有关各方按他们的目标所从事的一系 列相关支持活动集。该过程又分为文档过程、配置管理 过程、质量保证过程、验证过程、确认过程、联合评审 过程、审计过程和问题解决过程。
  • 12.组织过程:是指那些与软件生产组织有关的活动集。 该过程又可分为管理过程、基础设施过程、培训过程 和改进过程。
  • 13.管理过程:是管理人员从事的、对其他过程进行 管理的活动和任务。 管理过程包含启动与范围定义、规划、测量、执行 和控制、评审和评价、结束处理等活动。
  • 14.任务的三种形式: (1)达到相应过程结果必须执行的任务; (2)达到相应过程结果最好执行的任务; (3)达到相应过程结果允许执行的任务。
  • 简答题
    • 1.建立软件项目生存周期过程的主要步骤: (1)选择软件生存周期模型。 (2)细化所选择的生存周期模型。 (3)为每一个活动或任务标识合适的实例数目。 (4)确定活动的时序关系，并检查信息流。 (5)建立过程计划的文档。
    • 8.喷泉模型:体现了软件创建所固有的迭代和无间隙的特征。 该模型表现了软件活动需要多次重复，还表明活动之间没 有明显的间隙。喷泉模型主要用于支持面向对象技术的软 件开发。
    • 2.监控软件项目生存周期过程的要点: (1)软件生存周期过程的监控。 (2)生存周期过程改变所产生影响的评估。 (3)改变的实施。
    • 3.演化模型的主要特征是:该模型显式地把需求获取扩展 到需求阶段，即为了第二个构造增量，使用了第一个构 造增量来精化需求。演化模型在一定程度上可以减少软 件开发活动的盲目性。 演化模型的不足主要体现为:在演化模型的使用中，即使 很好地理解了需求或设计，也很容易弱化需求分析阶段 的工作。
    • 4.系统需求分析的任务有: (1)建立系统需求规格说明。 该规格说明应描述:系统的功能和能力;业务需求， 组织需求和用户需求;安全保密需求，接口需求， 运行和维护需求;设计约束以及合格性需求。 (2)对系统需求进行评估。评估应考虑下列准则， 并建立评估结果文档。 ①有关获取方面需要的可追踪性。 ②有关获取方面需要的一致性。 ③可测试性。 ④系统体系结构设计的可行性。 ⑤运行体系维护的可行性。
    • 5.对软件需求进行评估时，应考虑的准则: (1)系统需求和系统设计的可追踪性。 (2)与系统需求的外部一致性。 (3)内部一致性。 (4)可测试性。 (5)软件设计的可行性。 (6)运行和维护的可行性。
    • 6.软件体系结构设计的主要任务有: (1)把软件项的需求转换为一种体系结构，描述其 顶层结构并标识各个的软件构件 (2)对该软件项的外部接口和各构件之间的接口进 行顶层设计，并形成文档。 (3)为数据库开发顶层设计,并建立相应的文档。 (4)编制用户文档的初始版本，并形成文档。 (5)为软件集成定义初步的测试需求和进度并 形成文档。 (6)考虑以下准则，评估软件项体系结构设计、 接口设计和数 据库设计，并建立评估结果的文档: ①软件项需求的可跟踪性。 ②软件项需求的外部一致性。 ③软件构体之间的内部一致性。 ④详细设计的灵活性。 ⑤运行和维护的灵活性。
    • 7.软件实现过程的意图:软件实现过程是为了生产一 个已规约系统的元素，作为一个软件产品或服务而 实现的。 软件实现过程的任务: (1)如果合同中没有规定，开发人员应定义或选择一 个适合于项目范围、粒度、复杂性的生存周期模型。 (2)实施人员应按软件文档过程建立输出文档;把该 输出置于配置管理过程之下并按配置管理过程执 行变更控制;按软件问题解决过程，建立在软件产 品中所发现的问题和矛盾的文档并解决它;按合同 规定执行支持过程;在适当的时间，按获取方和提 供方的决定建立基线并形成相应的配置项。 (3)实施人员应选择、剪裁和使用一些由组织为执 行和支持该过程而建立的一些合适的标准、方法、 工具和计算机编程语言。
    • 8.软件需求分析过程的结果为: (1)需求已分配给系统的软件元素，并且它们的接口已定义。 (2)已分析需求的准确性和可测性。 (3)已了解软件需求对运行环境的影响。 (4)在软件需求和系统需求之间建立了一致性和可跟踪性。 (5)已定义了实现软件需求的优先级别。 (6)软件需求已得到批准并按需要进行了调整。 (7)针对软件需求的更改对成本、进度和技术影响，已进 行了相应的评估。 (8)建立了软件需求的基线，并与有关部门进行了沟通。
    • 13.瀑布模型的提出对软件工程的主要贡献为: (1)在决定系统怎样做之前存在一个需求阶段,它鼓 励对系统做什么进行规约。 (2)在系统构造之前存在一个设计阶段，它鼓励规 划系统站构。 (3)在每一阶段结束时进行评审。从而允许获取方 和用户的参与。 (4)前一步可以作为下一步被认可的、文档化的基 线，并允许基线和配置早 期接受控制。瀑布模型的主要问题是: (1)要求用户能够完整、正确和清晰的表达他们的 需求，并要求开发人员一 开始就要理解这一应用。 (2)由于需求的不稳定性，是设计、编码和测试阶 段都可以发生延期。 (3)在开始的阶段中,很难评估真正的进度状态，并 且直到项目结束之前都不 能演示系的能力。 (4)在项目的早期阶段，过分地强调了基线和里程 碑处的文档，并可能花费更多的时间用于建立一 些用处不大的文档。
    • 14.增量模型的主要优点是: (1)第一个可交付版本所需的成本和时间是较少的, 从而可减少开发由增 量表示的小系统所承担的风险。 (2)由于很快发布了第一个版本,因此可以减少用户 需求的变更。 (3)允许增量投资。 增量模型的主要缺点是: (1)如果没有对用户的变更要求进行规划，那么产生 的初始增量可能会造成后来增量的不稳定。 (2)如果需求不像早期思考的那样稳定和完整，那么 一些增量就可能需要重新开发，重新发布。 (3)由于进度和配置的复杂性，可能会增大管理成本 ，超出组织的能 力。15.在对生存周期过程改变产生的影响进行评估 时，应考虑的 方面: (1)所要求的“返工”。要考虑一个过程改变对进度 的成本的影响。 (2)资源需求。必须考虑由生存周期过程的改变所产 生的全部成本，以及为获得这些资所需要的时间。 (3)实施时间。 (4)对项目和用户的益处。 (5)员工情绪。进行一个过程改变,特别是进行一个 重要的政变，可能会对员工的情绪产生负面影响。
• 8集成化能力成熟度模型（CMMI）
  • 1.CMMI:是集成化能力成熟度模型， 是针对系统/产品开发的能 力成熟度模型,包含一些最佳实践, 覆盖了产品从概念到交付和维 护的整个生存周期，强调了构造 和维护当今产品所必要的工作。
  • 2.过程改善:是指认为设计的一个活动 程序，其目的是改进组织的过程 性能和成熟度，并改进这一程序的结果。
  • 3.过程域:是一个业务域中一束相关 的实践,当它们一起得以实现 时,就满足被认为对让过程城的改 善具有重要作用的一组条件。
  • 4.成熟度等级:是指达到预先定义 的一组过程域所有目 标的一种过程改善等级。
  • 5.过程制度化:是指过程渗透在执行工 作的方式中,执行的工作有一定的承诺 ，并且在组织范围内是一致的。
  • 简答题
    • 1.已管理过程与已执行过程的重要区别: (1)过程被管理的程度不同,即一个以管理的过程是计 划的，该过程的性能是按计划管理的。 (2)管理目的不同,即一个已管理的过程达到计划的目 的,并且为了实现一致的性能，该过程得以制度化。
    • 2.共用实践的子实践如下: (1)为执行过程,定义计划并建立相应的文档。 (2)定义过程描述,并建立相应的文档。 (3)与关联的利益方一起评审计划,并得到他们的认可。 (4)必要时修订该计划。
    • 3.已定义过程与已管理过程的主要区别: (1)过程描述、标准和规程的应用范围不 同，对于一个已管理的过程而言，过程 描述、标准和规程可用一个特定的项目 、团队或组织部门。一个组织内两个项 目的已管理过程可能是不同的。 (2)描述的程度不同,已定义的过程与已管理 的过程相比,其过程描述更加详细，其执行 更加严格。
    • 4.成熟度2级与成熟度3级的区别: (1)标准的范围、过程的描述和规程的范围的不同。 在成熟度2中，标准、过程描述和规程在每一个特 定的过程实例中可能是完全不同的;在成熟度3中, 一个项目的标准、过程描述和规程是从组织的一 组标准过程中剪裁出来的，以适应特定项目或组 织部门。 (2)过程描述的严格程度是不同的。在成熟度3级 中，过程描述要比成熟度2级更加严格。
    • 项目规划的内容有哪些？ 5.(1)估算工作产品和任务。 (2)确定需要的资源。 (3)协商承诺。 (4)生成进度。 (5)标识并分析项目风险。
    • 6.估算项目范围的子实践如下: (1)基于产品体系结构，开发WBS。 (2)以充分详细的程度标识工作包,以便规约项 目任务、责任和进度估算。 (3)标识外部获取的产品和产品构件。 (4)标识复用的产品。
    • 12.确认需求的子实践如下: (1)分析需求,以确定可导致产品在其预期使用的环 境中不能适当执行的风险。 (2)通过开发产品的表示,或通过从相关利益攸关方 获取有关产品的反馈，揭示准确、完备的需求。 (3)评估在需求确认环境的上下文中该设计的成熟 度，以标识确认问题,揭示尚未指出的需要和客户需求。
    • 13.分析需求的子实践如下: (1)为消除需求中的冲突,并把需求组织为一些相关的 主题，分析利益攸关方的要求、期望、约束和外部 接口。 (2)分析需求,以确定它们是否满足高层需求的目的。 (3)分析需求,以确保它们是一致的、易修改的、 可靠的和可验证的。 (4)标识对成本、进度、功能、风险或性能具有重 大影响的需求。 (5)标识技术上的性能度量，并在开发工作期间 予以跟踪。 (6)分析操作概念和场景,以精化客户要求、约束 和接口，并揭示需求。

软件工程

• 1绪论
  • 软件
    • 概念：计算机系统中的程序及其文档
  • 软件工程
    • 概念：软件工程是应用计算机科学理论和技术以及工程管理原则和方法，开发软件的工程
  • 软件危机
    • 软件生产率、软件质量远远满足不了社会发展的需求，成为社会，经济发展的制约因素，人们通常把这一现象称为“软件危机”
  • 简答题
    • 软件开发的本质
      • 不同抽象层术语之间的“映射”， 以及不同抽象层处理逻辑之间的“映射”
    • 软件开发的基本途径
      • 1、过程方向，求解软件的开发逻辑 2、过程途径，求解软件的开发手段
    • 软件开发中所涉及的模型
      • 概念模型和软件模型（设计模型、实现模型、部署模型）
    • 软件开发所涉及的两大类技术
      • 一是求解软件的开发逻辑 二是求解软件的开发手段
• 2软件需求与软件需求规约
  • 软件需求
    • 以一种技术形式，描述了一个产品应该具有的功能、性能、和其他性质。
  • 功能需求
    • 规约了系统或系统构件必须执行的功能。
  • 非功能需求
    • 指性能、外部接口、设计约束、和质量属性等需求
  • 需求规约
    • 是一个软件所有需求陈述的正式文档，它表达了一个软件产品的概念模型。
  • 简答题
    • 需求与需求规约的基本性质
      • 2.需求的基本性质: (1)必要的,该需求是用户所要求的。 (2)无歧义的，该需求只能用一种方式解释。 (3)可测的,该需求是可进行测试的。 (4)可跟踪的,该需求可从一个开发阶段跟踪到另一个阶段。 (5)可测量的,该需求是可测量的。 需求规约的基本性质: (1)重要性和稳定性程度:按需求的重要性和稳定性，对需求进行分级。 (2)可修改的:在不过多地影响其他需求的前提下,可以容易的修改一个单一需求。 (3)完整的:没有被遗漏的需求。 (4)一致的:不存在互斥的需求。
    • 功能需求和非功能需求之间的基本关系
      • 功能需求是整个需求的主题，即没有功能需求 就没有派生的其他功能需求，就没有性能、 外部接口、设计约束、和质量属性等非功能需求。 但非功能需求可作用于一个或多个功能需求。
    • 常用的初始需求发现技术
      • a、自悟 b、交谈 c、观察 d、小组会 e、提炼
    • 需求规约(SRS)的3种基本形式
      • 非形式化的需求规约 半形式化的需求规约 形式化的需求规约
    • 软件需求规约的内容和作用
      • 软件需求规约的内容有：引言、总体描述、特定需求、附录、索引。 作用：1)需求规约是软件开发组织和用户之间一份事实上的技术合 同书，是产品功能及其环境的体系。 (2)对于项目的其余大多数工作,需求规约是一个管理控制点。 (3)对于产品/系统的设计，需求规约是一个正式的，受控的 起始点。 (4)需求规约是创建产品验收测试计划和用户指南的基础。
    • 软件需求规约在项目开发中的基本作用
      • 1)需求规约是软件开发组织和用户之间一份事实上的技术合 同书，是产品功能及其环境的体系。 (2)对于项目的其余大多数工作,需求规约是一个管理控制点。 (3)对于产品/系统的设计，需求规约是一个正式的，受控的 起始点。 (4)需求规约是创建产品验收测试计划和用户指南的基础。
    • 需求规约和项目需求的不同
      • (1)需求规约是软件开发组织和用户之间一份事实上的技术合同 书，即关注产品需求，回答“交付给客户的产品/系统是什么”。 (2)项目需求是客户和开发者之间有关技术合同一产品/系统需 求的理解，应记录在工作陈述中或其他某一项目文档中,即关注 项目工作和管理，回答“开发组要做的是什么”
• 3结构化方法
  • 简答题
    • 1.模块耦合的类型:(1)内容耦合(2)公共耦合(3)控制耦合(4)标记耦合(5)数据耦合
    • 2.模块内聚的类型:(1)偶然内聚(2)逻辑内聚(3)时间内聚 (4)过程内聚(5)通信内聚(6)顺序内聚(7)功能内聚
    • 3.总体设计的任务是把系统的功能需求分配到一个特定的软件体系结构中。
    • 4.变换设计的基本步骤如下: (1)设计准备--复审并精化系统模型 (2)确定输入、变换、输出这三部分之间的边界。 (3)第一级分解--系统模块结构图顶层和第一层的设计。 (4)第二级分解--自顶向下,逐步求精。 事务设计的基本步骤如下: (1)设计准备--复审并精化系统模型。 (2)确定事务处理中心。 (3)第一级分解--系统模块结构图顶层和第一层的设计。 (4)“第二级分解”--自顶向下,逐步求精。
• 4面向对象的方法——UML
  • 简答题
    • 1.类的属性是类的一个命名特性，该特性是由该类的所有对象所共享、 用于表达对象状态的数据。 属性的可见性是指该属性是否可以被其他类所使用，具体分为: (1)公有的:可以被其他类调用。 (2)受保护的:只有其子类才能调用。 (3)私有的:只有本类的操作才能使用。 (4)包内的:只有在同一包中声明的类才能使用。 属性名是表示属性名字的标识串。 属性的类型是对属性实现类型的规约。 属性的多重性即该类实例的这一特性可以具有的值的范围,用于说明属 性值的数量。属性的初始值是给新建的对象赋予初始值。属性的性质 串是为了说明属性的性质。 属性可分为类范围的属性和对象范围的属性。
    • 2.接口的具体表现形式有: (1)采用具有分栏和关键字的矩形符号来表示。接口名可以是简单名， 也可以是受限名。 (2)采用小圆圈和半圆圈来表示。
    • 5.在对系统进行模型化时，采用以下两种方式: (1)以数据驱动:即对所标识的每一个类，如果一个类需要导航到另一 个类的对象，那么就要在这两个类之间给出一个关联。 (2)以行为驱动:即对所标识的每一个类，如果一个类的对象需要与另 一个类的对象进行交互，那么就要在这两个类之间给出一个关联。
    • 6.创建一个类图，一般涉及以下方面: (1)模型化待建系统中的概念，形成类图中的元素。 (2)模型化待建系统中的各种关系，形成该系统的初始类图。 (3)模型化系统中的协作，给出该系统的最终类图。 (4)模型化逻辑数据库模式。
    • 7.关于系统/业务语境的模型化，应研究如下问题: (1)系统边界的设定,即确定哪些行为是系统的一部分,哪些行为 是由外部实体执行的，同时定义主题。 (2)参与者与用况的交互，即在用况图中表明参与者与系统 用况之间的关系。 (3)参与者的语义表达,在需要加深理解的地方,为每个参与者 提供一个衍型 。(4)参与者的结构化处理,即将一些相似的参与者组织为一 般/特殊结构。
    • 8.为了控制交互行为描述的复杂性，以便更清晰地表达顺序图 中的复杂控制，有以下四种常用的操作子。 (1)选择执行操作子,记为“Opr”,有两部分组成,一是监护条件， 二是控制体。监护条件是一个布尔表达式，可以引用被监控对象的属性。 (2)条件执行操作子,记为“alt”,控制体通过水平线分为一个条 件分支和一个监护条件。 (3)并发执行操作子,记作“par”,控制操作子的体通过水平线将其 分为多个部分，每一部分并行计算。 (4)迭代执行操作子,记为“loop”,其中一个监护条件出现在控制体 中一条生命线的顶端。
    • 9.关联类是一种具有关联和类特性的模型元素。一个关联类可以被 看做一个关联，但还有类的特性，或者被看做一个类,但具有关联的特性。 如果关联类只有属性而没有操作和其他关联,则名字可以显示在关联 路径上,从关联类的符号中省去，以强调其关联的性质。尽管把关联 类画成一个关联和一个类,但它仍是一个单一的元素，使用关联可以 表达一个特定关联的语义。
• 5面向对象的方法——RUP
  • 简答题
    • 简述用况模型的构成 1.用况模型是一种概念模型，是对系统的抽象，是系统的 一个模型。创建用况模型是捕获系统功能需求的目的。 2.给出一个系统的用况模型,主要是给出系统的用况图,给出 其中每一个参与者的描述和每一个用况的揭述。对参与者 进行描述要给出其角色和其对环境的要求;对用况的描述一 般采用正文的事件流计数,给出用况的前置条件、开始动作、 基本路径、每一个可选路径、参与者的交至以及结束动作和 后置条件。
    • 简述设计模型的四层结构 4.RUP设计的主要结果是设计模型，它尽量保持 该系统具有分析模型的结构，并作为系统实现的 输入，包含以下四个元素: (1)设计子系统和服务子系统，以及它们的接口、 依赖和内容。其中可以依据分析包来设计上面 两层的设计子系统。 (2)设计类以及它们具有的操作、属性、关系及 其实现的需求。在设计类进行设计时，分析类 作为它们的规约,有些主动类是基于分析类考虑 并发需求而设计的。 )用况细化设计]。它们描述了用况是如何设计 的，其中使用了设计模型中的协作，在进行用 况细化[设计]时，用况细化[分析]作为它们的规约。 (4)设计模型视角下的体系结构描述，其中包括 一些在体系结构方面具有重要意义的元素。
    • 5.在用况结构化中应注意以下3个问题: (1)在建立用况的结构中,应尽可能的反映用况的实际情况， 否则，不论对用户还是客户。要理解这些用况以及它们的 意图相当困难。 (2)在用况结构化中,不论是施加什么结构,新引入的用况都 不应太小或者太大。 (3)在建立用况的结构中,尽量避免对用况模型中的用况功 能进行分解。
    • 6.构造用户界面模型的目标是建造用户界面模型，基本步骤为: (1)用户界面设计。 (2)物理用户界面设计。 (3)开发用户界面原型并演示为了执行该用况，用户怎样使用该系统
    • 服务包的主要特征： 7.(1)服务包是不可分离的，即如果客户需要这一包， 就要其中的所有类。 (2)服务包之间的依赖,通常是非常受限制的。 (3)服务包一般只涉及一个参与者或很少几个参与者。 (4)服务包可以独立执行，对于同一服务的不同方面， 可以有系统的两个不同服务包所提供。
    • 8.子系统设计的目标有以下3条: (1)确保子系统可能独立于其他子系统或它们的接口 （2）确保子系统提供正确的接口 (3)确保子系统实现了它的目标，即给出了该子系统 提供的那些接口定义点的操作细化等问题。
    • 9.RUP的突出特点如下:(1)以用况为驱动。(2)以体系结构为中心。 用(3)迭代、增量式开发。
    • 10.创建系统/产品需求获取模型的四个步骤如下: (1)列出候选需求。(2)理解系统语境。 (3)捕获系统功能需求。(4)捕获非功能需求。
• 6软件测试
  • 1.静态测试:指被测试程序不在机器上运行,而是采 用人工检测和计算机辅助静态分析的手段对程序 进行检测。
  • 2.动态测试:指通过运行程序发现错误。一般意义 上的测试大多是指动态测试。
  • 简答题
    • 路径测试的基本要点 2.由于路径测试技术依据的是程序的逻辑 结构，因此该技术的基本要点是: (1)采用控制流程图来表达被测程序模型， 揭示程序中的控制结构。 (2)通过合理地选择一组穿过程序的路径， 以达到某种测试度量。 3,在路径选取中，其一般原则是: (1)选择最简单的、具有一定功能含义的入 口/出口路径。 (2)在已选取的基础上,选取无循环的路径、 选取短路径、简单路径。 (3)选取没有明显功能含义的路径，此时 要研究这样的路径为什么存在。为什么 没有通过功能上合理的路径得到覆盖。
    • 子主题
    • 4.白盒测试法的覆盖标准有:语句覆盖、判定覆盖、 条件覆盖、分支/条件覆盖、条件组合覆盖、 路径覆盖。 (1)语句覆盖发现错误能力最弱。 (2)分支覆盖包含了语句覆盖,但它可能会使 一些条件得不到测试。 (3)条件覆盖对每一条件进行单独检查,一般 情况下它的检错能力较分支覆盖强，但有 时达不到分支覆盖的要求。 (4)分支/条件覆盖包含了分支覆盖和条件 覆盖的要求,但由于计算机系统软件实现 方式的限制，实际上不一定达到条件覆 盖的标准。 (5)条件组合覆盖发现错误能力较强,凡 满足其标准的测试用例，也必然满足前 四种覆盖标准。 (6)前五种覆盖标准把注意力集中在单个 判定或判定的各个条件上，可能会使程 序某些路径没有执行到。路径覆盖根据 各判定表达式取值的组合,使程序沿着不 同的路径执行，查错能力强。但由于它 是从各判定的整体组合出发设计测试用 例的，可能使测试用例达不到条件组合 覆盖的要求。
    • 黑盒技术设计测试用例的方法以及特点： 5.(1)等价类划分。等价类划分是将输入数据城按有效的或无效的(也称合理 的或不合理的)划分成若干个等价类，测试每个等价类的代表值就等于对该 类其他值的测试。 (2)边界值分析。该方法是将测试边界情况作为重点目标，选取正好等于、 刚刚大于或刚刚小于边界值的测试数据，对程序进行测试，发现错误的 概率较大。 (3)错误推测。错误推测法没有确定的步骤,凭经验进行。它的基本思想 是列出程序中可能发生错误的情况，根据这些情况选择测试用例。 (4)因果图。因果图能有效地检测输入条件的各种组合可能会引起的错误。 因果图的基本原理是通过面因果图，把用自然语言描迷的功能说明转换 为判定表，最后为判定表的每一设计一个测试用例。
    • 6.软件产品在交付使用之前一般要经过:单元测试、集成测试、有效性 测试和系统测试四个步骤。单元测试指对源程序中每一个程序单元进 行测试，检查各个模块是否正确实现规定的功能，从而发现模块在编 码中或算法中的错误。该阶段涉及编码和详细设计的文档。 各模块经过单元测试后。将各模块组装起来进行集成测试,以检查与设 计相关的软件体系结构的有关问题。有效性测试主要检查软件已实现功 能的是否满足需求规格说明书中确定了的各种需求。系统测试指把已确 认的软件与其他系统元素(如硬件、其他支持软件、数据、人等)结合在 一起进行测试。
    • 7.单元测试主要针对模块的以下五个基本特征进行测试: (1)模块接口。 (2)局部数据结构。(3)重要的执行路径。 (4)错误处理。(5)边界测试。 在单元测试时，由于模块不是一个独立的程序，必须 为每一个模块单元测试开发驱动模块和(或)承接模块。 驱动模块模拟“主程序”接受测试用例的数据，将这 些数据传送给要测试的块并打印有关的结果。承接模 块代替被测模块的下属模块，打印入口检查信息,并将 控制返回到它的上级模块。
    • 8.使用边界值分析在设计测试用例时，应遵循的原则: (1)如果某个输入条件规定了输入值的范围，则应选择 正好等于边界值的数据，以及刚刚超过边界值的数据 作为测试数据。 (2)如果某个输入条件规定了值的个数，则可用最大个 数、最小个数、比最大个数多 1、比最小个数少1的数 作为测试数据。 (3)根据规则说明的每个输出条件,使用原则 (4)根据规则说明的每个输出条件,使用原则 (5)如果程序的规格说明中,输入域或输出域 是有序集合,在实践中则经常选取集合的第 一个元素、最后一个元素以及典型元素作 为测试用例。 (6)如果程序中使用了内部数据结构,则应当选择这个内 部数据结构的边界上的值作为测试用例。 (7)分析规格说明，找出其他可能的边界值。
    • 9.利用因果图测试技术生成测试用例的基本步骤: (1)通过软件规格说明书的分析，找出一个模块的 原因和结果，并给每一个原因和结果赋予一个标 识符。 (2)分析原因与结果之间以及原因与原因之间的对 应关系，并画出因果图。 (3)在因果图上标识出一些特定的约束或限制条件。 (4)把因果图转换成判定表。 (5)把判定表的每一列拿出来作为依据，设计测 试用例。
    • 10.自顶向下的集成测试是一种递增组装软件的方法。 从主控模块(主程序)开始,沿控制层次向下，先深度 或先宽度地将模块逐一组合起来，形成与设计相符 的软件结构。 自底向上的集成测试从软件结构最低的一层开始,逐 层向上地组合模块并测试。 自顶向下和自底向上的集成测试均有缺点。自顶 向下的主要缺点是需要设计承接模块以及随之而带 来的困难。自底向上的主要缺点是只有在加上最后 一个模块时，程序才作为一个实体而存在。
    • 11·黑盒测试法把程序看成一个黑盒子，完全不考虑 程序的内部结构和处理过程。黑盒测试是在程序接 口进行的测试，它只检查程序功能是否能按照规格 说明书的规定正常使用,程序是否能适当地接收输入 数据产生正确的输出信息，并且保持外部信息的完 整性。黑盒测试又称为功能测试。 常用的黑盒测试方法有等价类划分、边界值划分、 错误推测、因果图。
    • 12.软件测试在软件开发阶段的地位和作用:软件测试是 保证软件质量的关键步骤，是对软件规格说明、设计和 编码的最后复审。 软件测试与软件调试的区别: (1)测试从一个侧面证明程序员的“失败”,调试 是为了说明程序员的正确。 (2)测试以已知条件开始，使用预先定义的程序且 有预知的结果，不可预见的仅是程序是否通过。调 试一般是以不可知的内部条件开始，除统计性调 试外，结果不可预见的。 (3)测试是有计划的，并要进行测试设 计。调试不受时间约束的。 (4)测试是一个发现错误、改正错误、重新测试的过 程。调试是一个推理过程。 (5)测试执行时是有规程的。调试的执行往往要求程 序员进行必要的推理。 (6)测试经常是由独立的测试组在不了解软件设计的 条件下完成的。调试必须有了解详细设计的程序员完成。 (7)大多数测试的执行和设计可由工具支持。 调试时，程序员能利用的工具主要是调试器。
• 7软件生存周期过程
  • 5.增量模型:是一种非整体开发的模型。 软件在该模型中是“逐渐”开发出来的,开发出一 部分，向用户展示一部分，可让用户及早看到部 分软件，及早发现问题。或者先开发一个“原型” 软件，完成部分主要功能，展示给用户并征求意 见，然后逐步完善,最终获得满意的软件产品。该模 型具有较大的灵活性,适合于软件需求不明确、设 计方案有一定风险的软件项目。
  • 6.演化模型:主要针对事先不能完整定义需求的软件开发的。 在用户提出待开发系统的核心需求的基础上，软件开发人 员按照这一要求，首先开发一个核心系统并投入运行，以 便用户能够有效地提出反馈,即提出精化系统、增强系统能 力的需求;接着,软件开发人员根据用户反馈，实施开发的迭 代过程;每一选代过程均由需求、设计、编码、测试、集成 等阶段组成，为整个系统增加一个可定义的、可管理的子 集;如果在一次选代中，有的需求不能满足用户的要求，可 在下一次迭代中予以修正。
  • 子主题
  • 简答题
    • 1.建立软件项目生存周期过程的主要步骤: (1)选择软件生存周期模型。 (2)细化所选择的生存周期模型。 (3)为每一个活动或任务标识合适的实例数目。 (4)确定活动的时序关系，并检查信息流。 (5)建立过程计划的文档。
    • 8.喷泉模型:体现了软件创建所固有的迭代和无间隙的特征。 该模型表现了软件活动需要多次重复，还表明活动之间没 有明显的间隙。喷泉模型主要用于支持面向对象技术的软 件开发。
    • 2.监控软件项目生存周期过程的要点: (1)软件生存周期过程的监控。 (2)生存周期过程改变所产生影响的评估。 (3)改变的实施。
    • 3.演化模型的主要特征是:该模型显式地把需求获取扩展 到需求阶段，即为了第二个构造增量，使用了第一个构 造增量来精化需求。演化模型在一定程度上可以减少软 件开发活动的盲目性。 演化模型的不足主要体现为:在演化模型的使用中，即使 很好地理解了需求或设计，也很容易弱化需求分析阶段 的工作。
    • 4.系统需求分析的任务有: (1)建立系统需求规格说明。 该规格说明应描述:系统的功能和能力;业务需求， 组织需求和用户需求;安全保密需求，接口需求， 运行和维护需求;设计约束以及合格性需求。 (2)对系统需求进行评估。评估应考虑下列准则， 并建立评估结果文档。 ①有关获取方面需要的可追踪性。 ②有关获取方面需要的一致性。 ③可测试性。 ④系统体系结构设计的可行性。 ⑤运行体系维护的可行性。
    • 5.对软件需求进行评估时，应考虑的准则: (1)系统需求和系统设计的可追踪性。 (2)与系统需求的外部一致性。 (3)内部一致性。 (4)可测试性。 (5)软件设计的可行性。 (6)运行和维护的可行性。
    • 6.软件体系结构设计的主要任务有: (1)把软件项的需求转换为一种体系结构，描述其 顶层结构并标识各个的软件构件 (2)对该软件项的外部接口和各构件之间的接口进 行顶层设计，并形成文档。 (3)为数据库开发顶层设计,并建立相应的文档。 (4)编制用户文档的初始版本，并形成文档。 (5)为软件集成定义初步的测试需求和进度并 形成文档。 (6)考虑以下准则，评估软件项体系结构设计、 接口设计和数 据库设计，并建立评估结果的文档: ①软件项需求的可跟踪性。 ②软件项需求的外部一致性。 ③软件构体之间的内部一致性。 ④详细设计的灵活性。 ⑤运行和维护的灵活性。
    • 7.软件实现过程的意图:软件实现过程是为了生产一 个已规约系统的元素，作为一个软件产品或服务而 实现的。 软件实现过程的任务: (1)如果合同中没有规定，开发人员应定义或选择一 个适合于项目范围、粒度、复杂性的生存周期模型。 (2)实施人员应按软件文档过程建立输出文档;把该 输出置于配置管理过程之下并按配置管理过程执 行变更控制;按软件问题解决过程，建立在软件产 品中所发现的问题和矛盾的文档并解决它;按合同 规定执行支持过程;在适当的时间，按获取方和提 供方的决定建立基线并形成相应的配置项。 (3)实施人员应选择、剪裁和使用一些由组织为执 行和支持该过程而建立的一些合适的标准、方法、 工具和计算机编程语言。
    • 8.软件需求分析过程的结果为: (1)需求已分配给系统的软件元素，并且它们的接口已定义。 (2)已分析需求的准确性和可测性。 (3)已了解软件需求对运行环境的影响。 (4)在软件需求和系统需求之间建立了一致性和可跟踪性。 (5)已定义了实现软件需求的优先级别。 (6)软件需求已得到批准并按需要进行了调整。 (7)针对软件需求的更改对成本、进度和技术影响，已进 行了相应的评估。 (8)建立了软件需求的基线，并与有关部门进行了沟通。
    • 13.瀑布模型的提出对软件工程的主要贡献为: (1)在决定系统怎样做之前存在一个需求阶段,它鼓 励对系统做什么进行规约。 (2)在系统构造之前存在一个设计阶段，它鼓励规 划系统站构。 (3)在每一阶段结束时进行评审。从而允许获取方 和用户的参与。 (4)前一步可以作为下一步被认可的、文档化的基 线，并允许基线和配置早 期接受控制。瀑布模型的主要问题是: (1)要求用户能够完整、正确和清晰的表达他们的 需求，并要求开发人员一 开始就要理解这一应用。 (2)由于需求的不稳定性，是设计、编码和测试阶 段都可以发生延期。 (3)在开始的阶段中,很难评估真正的进度状态，并 且直到项目结束之前都不 能演示系的能力。 (4)在项目的早期阶段，过分地强调了基线和里程 碑处的文档，并可能花费更多的时间用于建立一 些用处不大的文档。
    • 14.增量模型的主要优点是: (1)第一个可交付版本所需的成本和时间是较少的, 从而可减少开发由增 量表示的小系统所承担的风险。 (2)由于很快发布了第一个版本,因此可以减少用户 需求的变更。 (3)允许增量投资。 增量模型的主要缺点是: (1)如果没有对用户的变更要求进行规划，那么产生 的初始增量可能会造成后来增量的不稳定。 (2)如果需求不像早期思考的那样稳定和完整，那么 一些增量就可能需要重新开发，重新发布。 (3)由于进度和配置的复杂性，可能会增大管理成本 ，超出组织的能 力。15.在对生存周期过程改变产生的影响进行评估 时，应考虑的 方面: (1)所要求的“返工”。要考虑一个过程改变对进度 的成本的影响。 (2)资源需求。必须考虑由生存周期过程的改变所产 生的全部成本，以及为获得这些资所需要的时间。 (3)实施时间。 (4)对项目和用户的益处。 (5)员工情绪。进行一个过程改变,特别是进行一个 重要的政变，可能会对员工的情绪产生负面影响。
• 8集成化能力成熟度模型（CMMI）
  • 1.CMMI:是集成化能力成熟度模型， 是针对系统/产品开发的能 力成熟度模型,包含一些最佳实践, 覆盖了产品从概念到交付和维 护的整个生存周期，强调了构造 和维护当今产品所必要的工作。
  • 2.过程改善:是指认为设计的一个活动 程序，其目的是改进组织的过程 性能和成熟度，并改进这一程序的结果。
  • 3.过程域:是一个业务域中一束相关 的实践,当它们一起得以实现 时,就满足被认为对让过程城的改 善具有重要作用的一组条件。
  • 4.成熟度等级:是指达到预先定义 的一组过程域所有目 标的一种过程改善等级。
  • 5.过程制度化:是指过程渗透在执行工 作的方式中,执行的工作有一定的承诺 ，并且在组织范围内是一致的。
  • 子主题
  • 简答题
    • 1.已管理过程与已执行过程的重要区别: (1)过程被管理的程度不同,即一个已管理的过程是计 划的，该过程的性能是按计划管理的。 (2)管理目的不同,即一个已管理的过程达到计划的目 的,并且为了实现一致的性能，该过程得以制度化。
    • 2.共用实践的子实践如下: (1)为执行过程,定义计划并建立相应的文档。 (2)定义过程描述,并建立相应的文档。 (3)与关联的利益方一起评审计划,并得到他们的认可。 (4)必要时修订该计划。
    • 3.已定义过程与已管理过程的主要区别: (1)过程描述、标准和规程的应用范围不 同，对于一个已管理的过程而言，过程 描述、标准和规程可用一个特定的项目 、团队或组织部门。一个组织内两个项 目的已管理过程可能是不同的。 (2)描述的程度不同,已定义的过程与已管理 的过程相比,其过程描述更加详细，其执行 更加严格。
    • 4.成熟度2级与成熟度3级的区别: (1)标准的范围、过程的描述和规程的范围的不同。 在成熟度2中，标准、过程描述和规程在每一个特 定的过程实例中可能是完全不同的;在成熟度3中, 一个项目的标准、过程描述和规程是从组织的一 组标准过程中剪裁出来的，以适应特定项目或组 织部门。 (2)过程描述的严格程度是不同的。在成熟度3级 中，过程描述要比成熟度2级更加严格。
    • 项目规划的内容有哪些？ 5.(1)估算工作产品和任务。 (2)确定需要的资源。 (3)协商承诺。 (4)生成进度。 (5)标识并分析项目风险。
    • 6.估算项目范围的子实践如下: (1)基于产品体系结构，开发WBS。 (2)以充分详细的程度标识工作包,以便规约项 目任务、责任和进度估算。 (3)标识外部获取的产品和产品构件。 (4)标识复用的产品。
    • 12.确认需求的子实践如下: (1)分析需求,以确定可导致产品在其预期使用的环 境中不能适当执行的风险。 (2)通过开发产品的表示,或通过从相关利益攸关方 获取有关产品的反馈，揭示准确、完备的需求。 (3)评估在需求确认环境的上下文中该设计的成熟 度，以标识确认问题,揭示尚未指出的需要和客户需求。
    • 13.分析需求的子实践如下: (1)为消除需求中的冲突,并把需求组织为一些相关的 主题，分析利益攸关方的要求、期望、约束和外部 接口。 (2)分析需求,以确定它们是否满足高层需求的目的。 (3)分析需求,以确保它们是一致的、易修改的、 可靠的和可验证的。 (4)标识对成本、进度、功能、风险或性能具有重 大影响的需求。 (5)标识技术上的性能度量，并在开发工作期间 予以跟踪。 (6)分析操作概念和场景,以精化客户要求、约束 和接口，并揭示需求。

软件工程

• 第一章
• 第二章
• 第三章
• 第四章
• 第五章
• 第六章
• 第七章
• 第八章