《软件工程》课程：期末复习提纲（超详细课本内容)

题型

1.名词解析 10题

2.简答 5题

3.综合 2题

重点看标记的，了解出小题，理解出小题或者大题，掌握出大题。

结合课本：

第一章概论

1.2软件工程

1.2.1软件工程定义（了解）

写出其中一种。

1.Friitz Bauer 在NATO会议上给出的定义

软件工程是建立和使用一套合理的工程原则，以便获得经济的软件，这种软件是可靠的，可以在实际的机器上高效的运行。

2.IEEE在软件工程术语汇编中的定义

软件工程是：

1. 将系统化的、严格约束的、了量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；
2. 对在1中所述方法的研究。

3.《计算机科学技术百科全书》中的定义

软件工程是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的学科。

第二章系统工程

2.1基于计算机的系统（了解）能写出定义

所谓基于计算机的系统是指：通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。组成基于计算机系统的元素组要有：软件、硬件、人员、数据库、文档和规程。

1. 软件：软件是指计算机程序、数据结构和一些相关的工作产品，用以实现所需的逻辑方法、规程或控制。
2. 硬件：硬件是指提供计算能力的电子设备、支持数据流的互联设备（如网络交换器。电信设备）和支持外部功能的机电设备。（如传感器、马达等）
3. 人员：人员是指硬件和软件的使用者和操作者。
4. 数据库：数据库是指通过软件访问并持久存储的大型的有组织的信息集合。
5. 文档：文档是指描绘系统的使用和/或操作的描述性信息（如模型、规格说明、使用手册、联机帮助文件、web站点）。
6. 规程：规程是指定义每个系统元素或其他外部相关流程的具体使用步骤。

2.2系统工程的任务（理解）

计算机系统工程是一个问题求解的活动，其目的是分析基于计算机的系统的功能，性能等要求，并把它们分配到基于计算机系统的各个系统元素中，确定他们的约束条件和接口。

系统工程主要包括以下任务。

1.识别用户的需求

系统工程的第一部就是识别用户对基于计算机的系统的总体要求，标识系统的功能和性能范围，确定系统的功能，性能、约束和接口。

2.系统建模和模拟（重点，需要理解并写出）

一个基于计算机的系统通常可以考虑一下模型。

1. 硬件系统模型
   • 硬件系统模型描述基于计算机系统中的硬件（包括计算机。受系统控制的其他硬件设备等）配置、通信协议、拓扑结构、以及确保基于计算机系统的安全性、可靠性、性能等需要的措施。
2. 软件系统模型
   • 基于计算机系统中的软件部分（软件系统）通常可以分解成若干个子系统。软件系统模型描述各软件子系统的功能、性能等要求，各软件子系统在硬件系统中的部署情况，以及软件子系统之间的交互。
3. 人机接口模型
   • 人机接口模型描述人如何与基于计算机的系统进行交互，包括用户环境、用户的活动、人机交互的语法和语义等。
4. 数据模型
   • 数据模型主要描述基于计算机的系统使用了哪些数据库管理系统，如果使用多个数据库管理系统，还应该描述它们之间的数据转换方式，必要时 可以给出主要的数据结构。
   • 系统模型通常可用图像描述，并加以相应的文字说明，共同完成整个基于计算机的系统的全部要求。必要时，在系统建模后可构造原型，进行系统模拟，以分析所建的模型能发满足整个基于计算机系统的要求。

3.成本估计及进度安排

开发一个基于计算机的系统需要一定的资金投入和时间约束（交付日期），因此在系统工程阶段应对需开发的基于计算机的系统进行成本估算，并作出进度安排。

4.可行性分析

可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行，通常只有当解决方案可行并且有一定的经济效益和/或社会效益时，才真正开始基于计算机系统的开发。

5.生成系统规格说明

在以上各任务完成以后，应该形成一份系统规格说明，作为以后开发基于计算机的系统的依据。系统规格说明描述基于计算机的系统的功能、性能和约束条件，描述系统的输入输出和控制信息，给出各系统元素的模型，进行可行性分析，最后给出成本估算和劲速安排计划。

2.3可行性分析（了解，定义）

开发一个基于计算机的系统通常都受到资源（如人力，财力、设备等）和时间上的限制，可行性分析主要从经济、技术。法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成。

第三章需求工程

3.1需求工程概述（了解，定义）

需求工程定义为：“直到（但不包括）把软件分解为实际架构和构建之前的所有活动”。需求工程时一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。

20世纪80年代，Herb Krasner定义了需求工程的5个阶段：需求定义和分析、需求决策、形成需求规约。需求实现与验证。需求演进管理。进来，Matthias Jarke和Klaus Pohl提出了3阶段周期的说法：获取、表示和见证。Roger S。pressman将需求工程过程描述为六个清晰的步骤：需求诱导，需求分析和谈判，需求规约，系统建模、需求确认以及需求管理。Lan Sommerviller等将需求工程分为需求抽取，需求分析和需求协商、系统建模、需求确认以及需求管理。

本书将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证以及需求管理6个阶段。

3.2需求获取

3.2.2需求获取方法与策略（掌握）

在与用户交流的过程中，可能会存在误解、交流障碍、缺乏共同语言等问题，这些交流上的问题会导致得到的用户需求不稳定、缺乏完整性，甚至是错误的需求，因此在获取需求前首先要建立需求获取人员（通常被称为系统分析员）与用户的顺畅的通信途径，与用户交谈，向用户提问题，通过访谈与会议、参观用户的工作流程、观察用户操作、建立联合小组和实例分析来获取需求。

1. 建立顺畅的通信途径

   • 需求获取要成功,首先要建立需求获取所必需的通信途径,即在用户、系统分析人员、软件开发小组、管理人员之间建立良好的沟通方式,以保证能顺利地对问题进行分析。

2. 访谈与调查

   • 在获取的初期阶段,分析人员往往对问题了解很少,用户对问题的描述、对目标软件的要求也通常会很模糊,甚至出现不一致,同时,在项目的初期,分析人员通常缺乏与系统相关的领域知识,从而造成双方理解的障碍。因此在项目开始之前,分析人员要从分析已经存在的同类软件产品,或从行业标准、规则中,甚至从Internet上搜索相关资料来提取初步需求,然后以个别访谈或小组会议的形式开始与用户进行初步沟通。面谈通常分为结构化和非结构化的面谈。前者主要讨论一组事先计划好的问题,并要求按计划进行面谈;而后者对将要讨论的主题只有一个粗略的想法,依赖于需求获取者在面谈进行时的“临场发挥"。
   • 在具体的实践中,通常采用折衷的方法,即适当地计划好面谈,但不要过于详细,允许有一定的灵活性。一般按照如下原则进行准备:
   • 所提的问题应该循序渐进,从整体的方面开始提问,接下来的问题应有助于对前面问题更好的理解和细化。
   • 不要限制用户对问题的回答,这有可能会引出原先没有注意的问题。
   • 提问和回答在汇总后应能够反映用户需求的全貌。
   • 可以分析下面的简单实例。表3.1是一个“赛艇比赛成绩计算系统”的第一次面谈的准备计划。由于是第一次面谈,所以问题没有过细,只是涉及主要的问题。在面谈的过程中,用户的回答可能会引出原先没有注意的问题,可以在后续的面谈中加以解决。
   • 除与用户进行面谈外,还有一些其他的调查研究方法:可以进行市场调查,了解市场对将开发的软件有什么样的要求,了解市场上有无与待开发软件类似的系统,如果有,在功能上、性能上、价格上情况如何;可以采取多种调查方式,制定调查提纲,向不同层次的用户发调查表;可以访问用户和领域专家,把从用户那里得到的信息作为重要的原始资料进行分析,访问用户领域的专家所得到的信息将有助于对用户需求的理解。

3. 观察用户操作流程

   • 除了访谈和调查外,还可以到用户的实际工作环境中对用户的工作流程进行观察,了解用户实际的操作环境、操作过程和操作要求,对照用户提交的问题陈述,对用户需求可以有更全面、更细致的认识。不过在观察过程中需要注意的是:未来的软件系统并不是完全模拟用户现有的工作流程,分析人员要结合原有的开发经验和应用经验,分析其中哪些环节应该由软件系统完成,哪些环节应该由人来完成,并且主动剔除现有系统不合理的部分,改选现有的工作流程、寻找潜在的用户需求,这些需求的实现在将来软件应用的过程中一定会得到用户的赞同。

   4.组成联合小组（重点，与FAST会议相关，是啥，步骤，对应说明）

   ​ 为了能够有效地获取和挖掘用户需求，打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势，这种方法被称为便利的应用规约技术（FAST）。

   ​ FAST鼓励建立用户和开发者团队之间的合作，他们共同工作来表示问题、提出解决方案的要素、商议不同的方法以及刻画出初步的解决方案。他已经成为信息系统使用的主流技术，该技术为改善各种应用中的相互通信提供了潜在可能。FAST团队来自市场、软件和硬件工程以及制造方的代表组成，并选择外来人员作为协调者。该方法有以下基本原则：

   • 在中立的地点举行由开发者和用户出席的会议。
   • 建立准备和参加会议的原则。
   • 建议一个足够正式的议程以便可以自由的交流。
   • 由一个“协调者”（可以是用户、开发者或者其他外人）来控制会议。
   • 使用一种“定义规则”（可以是工作表、图标、墙上胶粘纸或者墙板）。
   • 目标是标识问题、提出解决方案的要素、商议不同的方法以及在有利于完成目标的氛围中刻画出初步的要求。

   以产品开发为例，FAST会议大体上有以下几个步骤：

   1. 当举行了开发者和用户之间的初步访谈后,确定一个FAST会议的时间和地点,并在会议召开之前将产品请求发布给所有的与会者。
   2. 要求每个FAST出席者在会议之前列出一组围绕系统环境的对象列表,对这些对象的操作列表或对象之间的交互功能列表,以及约束列表(如成本、规模大小、权重)和性能列表(如速度、精度)。这些列表可以不是穷尽的,但是,希望每套列表反映的是每个人对系统的感觉。
   3. 进行FAST会议时,当团队的每个成员提出自己的列表后,整个团队将创建一个组合的列表,该组合列表删去冗余项,并加入在表达过程中出现的新思想。在建好所有的组合列表后,开始讨论,并缩短、加长或重新组合表中的内容以更适当地反映将被开发的产品。
   4. 一旦创建了意见一致的列表,应该将团队分为更小的小组,每个小组力图为每个列表中的一个或多个项开发出小型的规约(即对包含在列表中的单词或短语的精细化)。然后每个小组将他们开发的每个小规约提交给所有的FAST出席者讨论,进行添加、删除或进一步的精化等工作。在所有讨论过程中,团队可能提出某些不能在会议过程中解决的问题,此时要保留问题列表以使这些思想在以后的活动中产生作用。
   5. 上一步骤完成后,每个FAST的出席者将讨论的结果形成列表提交给团队,团队基于此创建一组意见一致的列表。这组列表作为需求获取的结果,为需求分析和建模提供基础信息。

   FAST会议并不能解决在早期需求获取阶段遇到的所有问题,但是该方法提供了便利的条件,集中不同的观点、即时地讨论和求精以及具体地规约开发步骤,对于进行正确的需求获取是十分有益的。

5.用况

​ 用况(use case)常称为用例,当需求作为非正式会议-FAST的一部分而收集起来之后,分析员就可以创建一组标识一串待建造系统的使用场景。这些场景被称为用况的实例,用况提供了系统将会被如何使用的描述。

创建用况模型的主要步骤如下:

①确定谁会直接使用该系统,即执行者(actor)。

②选取其中一个执行者。

③定义该执行者希望系统做什么,执行者希望系统所做的每件事将成为一个用况。

④对每件事来说,何时执行者会使用系统,通常会发生什么,这就是用况的基本过程。

⑤描述该用况的基本过程。执行者和用户并不是一回事儿。

一个典型的用户可能在使用系统时扮演了一系列不同的角色,而一个执行者表示了一类外部实体,它们仅扮演一种角色。

第四章设计工程

4.1软件设计工程概述（了解、理解）定义

​ 软件设计是把软件需求变换成软件表示的过程，早期的软件设计分为概要设计和详细设计，