软件工程导论复习提纲

复习提纲对应教材为《软件工程（第3版）》，清华大学出版社

以下考点是笔者所在大学对应课程期末考试的考点，仅涉及全书部分知识点

软件工程定义

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

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

软件危机解释

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

随着计算机在各个领域的广泛应用，软件的需求量越来越大，软件的复杂度也越来越高，导致软件的开发远远满足不了社会发展的需要，超出预算的经费、超过预期的交付时间的事情经常发生。

由于缺乏文档以及没有好的开发方法的指导，使得大量已有的软件难以维护，到20世纪60年代中期出现了人们难以控制的局面，即“软件危机”。

软件生存周期

1. 计算机系统工程

   计算机系统工程的任务是确定待开发软件的总体要求和范围，以及该软件与其他计算机系统元素之间的关系，进行成本估算，作出进度安排，并进行可行性分析。

2. 需求分析

   需求分析主要解决待开发软件要“做什么”的问题，确定软件的功能、性能、数据、界面等要求，生成软件需求规约（也称软件需求规格说明）。

3. 设计

   系统设计的任务是设计软件系统的体系结构，详细设计的任务是设计各个组成成分的实现细节，包括局部数据结构和算法。

4. 编码

   编码阶段的任务是用某种程序设计语言，将设计的结果转换为可执行的程序代码。

5. 测试

   测试阶段的任务是发现并纠正软件中的错误和缺陷。

6. 运行和维护

   软件交付使用后，在软件运行期间，当发现了软件中潜藏的错误或需要增加新的功能或使软件适应外部环境的变化等情况出现时，对软件进行修改。

典型软件工程模型

1. 瀑布模型

   上一阶段的活动完成并经过评审才能开始下一阶段的活动，接受上一阶段活动的结果作为本阶段活动的输入，依据上一阶段活动的结果实施本阶段应完成的活动，对本阶段的活动进行评审。

2. 演化模型

   从结构初始的原型出发，逐步将其演化成最终软件产品的过程。演化模型特别适用于对软件需求缺乏准确认识的情况。

3. 增量模型

   将软件的开发过程分为若干个日程时间交错的线性序列，融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征，特别适用于需求经常发生变化的软件开发。

4. 原型模型

   开发人员和用户在“原型”上达成一致，缩短了开发周期，加快了工程进度，降低成本。

5. 螺旋模型

   将原型实现的迭代特征与瀑布模型中控制的和系统化的方面结合起来，不仅体现了这两种模型的优点，而且增加了风险分析。

6. 喷泉模型

   各个阶段没有明显的界限，开发人员可以同步进行开发，可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。

计算机辅助软件工程（Computer Aided Software Engineer, CASE)定义

计算机辅助软件工程是指使用计算机及相关的软件工具辅助软件开发、维护、管理等过程中各项活动的实施，以确保这些活动能高效率、高质量进行。

软件工具分类

1. 支持软件开发过程的工具

   支持软件开发过程的工具主要有：需求分析工具、设计工具（通常还可以分为概要设计工具和详细设计工具）、编码工具、排错工具、测试工具等。

2. 支持软件维护过程的工具

   支持软软件维护过程的工具主要有：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具等。

3. 支持软件管理过程和支持过程的工具

   支持软件管理过程和支持过程的工具主要有：项目管理工具、配置管理工具、软件评价工具等。

基于计算机的系统定义

基于计算机的系统是指通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。

组成基于计算机的系统的元素

组成基于计算机系统的元素主要有：软件、硬件、人员、数据库、文档和规程。

系统工程的任务

1. 识别用户的要求

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

2. 系统建模和模拟

   一个基于计算机的系统通常可考虑建立以下模型：硬件系统模型、软件系统模型、人机接口模型、数据模型。

3. 成本估算及进度安排

   开发一个基于计算机的系统需要一定的资金投入和时间约束（交互日期），需进行成本估算，并作出进度安排。

4. 可行性分析

   主要从经济、技术、法律等方面分析所给出的解决方案是否可行。

5. 生成系统规格说明

   作为以后开发基于计算机的系统的依据。

可行性分析的任务及对应解决的问题

1. 经济可行性

   经济可行性主要进行成本效益分析，从经济角度，确定系统是否值得开发

   a) 成本

   b) 效益

   c) 货币的时间价值

   d) 投资的回收期

   e) 纯收入

2. 技术可行性

   技术可行性主要根据系统的功能、性能、约束条件等，分析在现有资源和技术条件下系统能否实现。技术可行性分析通常包括风险分析、资源分析和技术分析。

   a) 风险分析

   b) 资源分析

   c) 技术分析

3. 法律可行性

   法律可行性主要研究系统开发过程中可能涉及到的合同、侵权、责任以及各种与法律相抵触的问题。

4. 方法的选择和折衷

   依据待开发系统的功能、性能、成本、开发时间、采用的技术、设备、风险以及对开发人员的要求等进行方案评估并作出选择。

需求工程阶段及对应具体任务

1. 需求获取：系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析。

2. 需求分析与协商：分析每个需求与其他需求的关系以检查需求的一致性、重叠和遗漏的情况，并根据用户的需求对需求进行排序。

3. 系统建模：通过合适的工具和符号系统地描述需求。

4. 需求规约：给出对目标软件的各种需求。

5. 需求验证：对功能的正确性、完整性和清晰性以及其他需求给予评价。

6. 需求管理：对需求工程所有相关活动的规约和控制。

软件需求定义及分类

软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。具体分类如下。

1. 功能需求
2. 性能需求
3. 用户或人的因素
4. 环境需求
5. 界面需求
6. 文档需求
7. 数据需求
8. 资源使用需求
9. 安全保密需求
10. 可靠性需求
11. 软件成本消耗与开发进度需求
12. 其他非功能性需求

需求获取方法与策略

1. 建立顺畅的通信途径

   即在用户、系统分析人员、软件开发小组、管理人员之间建立良好的沟通方式。

2. 访谈与调查

   项目开始前，分析人员从分析已经存在的同类软件产品，或从行业标准、规则中，甚至从Internet上搜索相关资料提取初步需求，然后以个别访谈或小组会议的形式开始与用户进行初步沟通。

3. 观察用户操作流程

   到用户实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。

4. 组成联合小组

   打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自长处，共同负责项目推进。

   此方法被称为便利的应用规约技术（Facilitated Application Specification Techniques, FAST)

5. 用况

   用况常称为用例，需求作为非正式会议——FAST的一部分而收集起来之后，分析员就可以创建一组标识一串待建造系统的使用场景。

需求协商定义及解决冲突的最快方式

复杂的系统有许多项目相关人员，他们之间的需求必定会出现冲突，协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案。

通常会议是解决冲突的最快方式。

需求建模定义及常用的分析方法

创建模型时需求分析阶段重要活动。模型以一种简洁、准确、结构清晰的方式系统地描述软件需求，并成为复审的焦点，还将成为软件设计的基础。

模型着重于描述系统要做什么，而不是如何去做。目标软件的需求模型不应设计软件的实现细节。

常用的分析方法如下。

1. 面向数据流的结构化分析方法(SA)
2. 面向数据结构的分析方法
3. 面向对象的分析方法(OOA)

软件设计工程定义及基本任务

软件设计是把软件需求变换成软件表示的过程，基本任务如下。

1. 数据/类设计：将分析类模型变换成类的实现和软件实现所需要的数据结构。

2. 体系结构设计：定义了软件的整体结构，由软件部件、外部可见的属性和他们之间的关系组成。

3. 接口设计：描述了软件内部、软件和协作系统之间以及软件同人之间的通信方式。

4. 部件级设计：将软件体系结构的结构性元素变换为对软件部件的过过程性描述。

软件设计原则

1. 抽象：从特殊到一般的过程
2. 逐步求精：把问题求解过程分解成若干步骤或阶段，每一步都比上一步更精化，更接近问题解法
3. 信息隐蔽
4. 模块独立

模块化相关概念定义及关系

模块是数据说明、可执行语句等程序对象的集合，是单独命名的，并且可以通过名字来访问的。

模块化是指把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件。

模块化设计就是程序的编写不是开始就逐条录入计算机语句和指令，而是首先用主程序、子程序、子过程等框架把软件的主要结构和流程描述出来，并定义和调试好各个框架之间的输入、输出链接关系。

耦合和内聚定义及关系

1. 耦合

   耦合（coupling）是模块之间的相对独立性（互相连接的紧密程度）的度量，耦合方式如下。

   a) 内容耦合：当一个模块直接修改或操作另一个模块的数据,或者直接转入另一个模块时就发生了内容耦合。此时，被修改的模块完全依赖于修改它的模块。如果发生下列情形，两个模块之间就发生了内容耦合：

   ​ i. 一个模块直接访问另一个模块的内部数据

   ​ ii. 一个模块不通过正常入口转到另一模块内部_

   ​ iii. 两个模块有一部分程序代码重叠(只可能出现在汇编语言中)_

   ​ iv. 一个模块有多个入口。

   b) 公共耦合：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。

   c) 外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。

   d) 控制耦合：如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。

   e) 标记耦合：一组模块通过参数表传递记录信息，就是标记耦合。这个记录是某一数据结构的子结构，而不是简单变量。其实传递的是这个数据结构的地址。

   f) 数据耦合：一个模块访问另一个模块时，彼此之间是通过简单数据参数(不是控制参数、公共数据结构或外部变量) 来交换输入、输出信息的。

   g) 非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的

2. 内聚

   内聚(cohesion)是一个模块内部各个元素彼此结合的紧密程度的度量，内聚类型如下。

3. 巧合内聚：讲几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立的模块称巧合内聚模块。

4. 逻辑内聚：逻辑内聚是指完成一组逻辑相关任务的模块，调用该模块时，由传送给模块的控制性参数来确定该模块应执行哪一种功能。

5. 时间内聚：时间内聚是指一个模块中的所有任务必须在同一时间段内执行。

6. 过程内聚：过程内聚是指一个模块完成多个任务，这些任务必须指定的过程执行。

7. 通信内聚：通信内聚是指一个模块内所有处理元素都集中在某个数据结构的一块区域中。

8. 顺序内聚：顺序内聚是指一个模块完成多个功能，这些功能又必须顺序执行

9. 功能内聚：功能内聚是指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割。

结构化分析模型的描述形式

结构图的几个概念

1. 深度：结构图中控制的层数。
2. 宽度：结构图中同一层次上模块总数的最大值。
3. 扇出：模块直接调用的模块数目。
4. 扇入：直接调用该模块的模块数目。

JSP方法的分析和设计步骤

1. 分析并确定输入和输出结构的逻辑结构，并用Jackson图画出
2. 找出输入数据结构和输出数据结构中有对应关系的数据元素
3. 从描述数据结构的Jackson图导出描述程序结构的Jackson图
4. 列出所有操作和条件，并将它们分配到程序结构图的适当位置
5. 用伪码表示

软件测试的概念及目的

设计若干测试用例(test case)，一个测试用例由测试输入数据和预期结果组成，测试时通过输入数据，运行被测程序，比对输出结果和预期结果。

软件测试的目的是发现软件中的错误和缺陷，并加以纠正。

白盒测试和黑盒测试的概念

1. 白盒测试

   白盒测试又称结构测试，这种方法把测试对象看做一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作。白盒测试主要用于对程序模块的测试。包括：

   • 程序模块中的所有独立路径至少执行一次。

   • 对所有逻辑判定的取值（“真”与“假”）都至少测试一次。

   • 在上下边界及可操作范围内运行所有循环

   • 测试内部数据结构的有效性等

2. 黑盒测试

   黑盒测试又称行为测试，这种方法吧测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符和它的功能需求。黑盒测试可用于各种测试，它试图发现以下类型的错误：

   • 不正确或遗漏的功能

   • 接口错误，如输入输出参数的个数、类型等

   • 数据结构错误或外部信息（如外部数据库）访问错误

   • 性能错误

   • 初始化和终止错误

白盒测试主要方法

1. 逻辑覆盖测试
2. 逻辑表达式错误敏感的测试
3. 基本路径测试
4. 数据流测试
5. 循环测试

黑盒测试主要方法

1. 等价类划分
2. 边界值分析
3. 比较测试
4. 错误猜测
5. 因果图方法

软件维护概念及分类

软件维护是指软件系统交付使用之后。为了改正错误或满足心得需要而修改软件的过程，其分类如下。

1. 纠错性维护
2. 适应性维护
3. 改善性维护
4. 预防性维护

软件维护过程

1. 维护组织
2. 维护过程
3. 维护记录
4. 维护评价