软件工程导论期末复习总结

第一章、软件工程学概述

软件危机

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

软件危机包含下述两个方面的问题：

如何开发软件，以满足对软件日益增长的需求。
如何维护数量不断膨胀的已有软件。

软件工程学

软件工程：指导计算机软件开发和维护的一门工程学科。
软件工程：包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。
软件工程学的一个重要的目标：就是提高软件的可维护性，减少软件维护的代价。

通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称为泛型。
软件工程方法学（包括传统方法学、面向对象方法学）包含三个要素：方法、工具和过程。

方法：是完成软件开发的各项任务的技术方法，回答“怎样做”的问题。
工具：是为运用方法而提供的自动的或半自动的软件工程支撑环境。
过程：是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

面向对象方法学具有下述四个要点：

把对象作为融合了数据及在数据上的操作的软件构件。
把所有对象都划分成类。
按照父类与子类的关系，把若干个相关类组成一个层次结构的系统。
对象彼此间仅能通过发送消息互相联系。

面向对象方法学的优点：降低了软件产品的复杂性，提高了软件的可理解性，简化了软件的开发和维护工作。

软件生命周期：软件生命周期由软件定义、软件开发和运行维护三个时期组成。
软件定义：问题定义、可行性研究和需求分析。
软件开发：总体设计，详细设计，编码和单元测试，综合测试。

问题定义：问题定义阶段必须回答的关键问题是：“要解决的问题是什么”。
可行性研究：这个阶段回答的关键问题是：“对于上一个阶段所确定的问题有行得通的解决办法吗
需求分析：确定软件必须“做什么”，即软件必须具备哪些功能。
总体设计：把任务分成不同模块。总体设计又称为概要设计。
详细设计：设计实现每个模块所需要的数据结构和算法
编码和单元测试：这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。
综合测试：这个阶段的关键任务是通过各种类型的测试使软件达到预定的要求。
软件维护：关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。

软件的组成：程序、数据和文档。

软件：是程序、数据及相关文档的集合。
程序：是能够完成预定功能和性能的可执行的指令序列。
数据：是使程序能够适当地处理信息的数据结构。
文档：是开发、使用和维护程序所需要的图文资料。

生命周期模型包括：瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型

瀑布模型：
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
缺点：
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
快速原型：是快速建立起来的、可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成功能的一个子集。
优点：有助于所开发出的软件产品满足用户的真实需求。
增量模型：它分批地逐步向用户提交产品，整个软件产品被分解成许多个增量构件，开发人员一个构件一个构件地向用户提交产品。
螺旋模型：基本思想是使用原型及其他方法来尽量降低风险。理解这种模型的一个简单方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。（使用于内部开发的大规模软件项目）
喷泉模型：是典型的面向对象的软件过程模型之一。充分体现了面对对象软件开发过程迭代和平滑过渡的特征。

第二章、可行性研究

可行性研究概述

可行性研究的目的：是用最小的代价在尽可能短的时间内研究并确定客户提出的问题是否有行得通的解决办法。
可行性研究的目的不是解决问题，而是确定问题是否值得去解决。

对每种解法都应该仔细研究它的可行性，一般说来，至少应该从下述 3 个方面研究每种解法的可行性：
1）技术可行性 2）经济可行性 3）操作可行性

可行性研究分析过程：
首先，进一步分析和澄清问题定义
然后，分析员应该导出系统的逻辑模型
最后，探索若干种可供选择的主要解法

可行性研究方法

系统流程图

系统流程图：实质上是物理流程图，它描绘组成系统的主要物理元素以及信息在这些元素间流动和处理的情况。
系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程，因此尽管系统流程图的某些符和程序流程图的符形式相同，但是它却是物理数据流图而不是程序流程图。

数据流图

数据流图：是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
通常用数据流图建立软件系统的功能模型。

数据字典

数据字典：是关于数据信息的集合，也就是对数据流图中包含的所有元素的定义的集合。
数据字典的作用：在软件分析和设计的过程中给人提供关于数据的描述信息。
系统的逻辑模型：由数据流图和数据字典共同构成，没有数据字典，数据流图就不严格，然而没有数据流图，数据字典也难于发挥作用。
数据字典最主要的用途：就是作为分析阶段的工具。

成本效益分析

第三章、需求分析

需求分析的任务是：准确地回答“系统必须做什么”这个问题。

通常对软件系统有以下几方面的综合要求：

功能需求
性能需求
可靠性和可用性需求
出错处理需求
接口需求
约束
逆向需求
将来可能提出的要求

可以概括为功能需求和非功能需求。

结构化分析方法

结构化分析方法就是面向数据流，自顶向下逐步求精进行需求分析的方法。
通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据
存储定义到元素级。

快速建立软件原型是最准确、最有效、最强大的需求分析技术。
快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。
快速原型应该具备的特性： 1.快速 2.容易修改

需求分析阶段的成果一：系统详细的逻辑模型

系统详细的逻辑模型，通常用数据流图、实体联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。

需求分析过程应该建立三种模型：数据模型（实体 -联系图）、功能模型（数据流图）和行为模型（状态转换图）。
实体联系图，描绘数据对象及数据对象之间的关系，是用于建立数据模型的图形。
数据流图是建立功能模型的基础。
状态转换图描绘了系统的各种行为模式和在不同状态间转换的方式。

需求分析阶段的成果二：软件需求规格说明书

软件需求规格说明是需求分析阶段得出的最主要的文档。
通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。

第四章、形式化说明技术

按照形式化的程度，可以把软件工程使用的方法划分成：非形式化、半形式化和形式化 3 类
形式化方法：是描述系统性质的基于数学的技术，也就是说，如果一种方法有坚实的数学基础，那么它就是形式化的。
矛盾：指一组相互冲突的陈述。
二义性：是指读者可以用不同方式理解的陈述。
不完整性：可能是在系统规格说明中最常遇到的问题之一。
形式化规格说明技术的优点：形式化的规格说明技术可以用数学方法研究、验证。此外，形式化的规格说明消除了二义性，而且它鼓励软件开发工程过程的早期阶段使用更严格的方法，从而可以减少差错。

第五章、总体设计

总体设计过程通常由两个主要阶段组成：

方案设计，确定系统的具体实现方案；
体系结构设计，确定软件系统中每个程序是由哪些模块组成的，以及这些模块之间的相互关系。

【什么是模块化
就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来够成一个整体，可以完成指定的功能满足用户的需求。
【模块独立】
开发具有独立功能而且和其他模块之间没有过多的相互作用的模块，就可以做到模块独立。
模块的独立程度可以由两个定性标准度量，这两个标准分别称为内聚和耦合。耦合衡量不同模块彼此间相互依赖（连接）的紧密程度；内聚衡量一个模块内部各个元素彼此结合的紧密程度。
【耦合】
耦合是对一个软件结构内不同模块之间互连程度的度量。耦合的强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。
模块间典型的耦合关系：

数据耦合
如果两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据，那么这种耦合称为数据耦合。
控制耦合
如果传递的信息中有控制信息，则这种耦合称为控制耦合。
数据耦合是低耦合。控制耦合是中等程度的耦合，它增加了系统的复杂程度。
特征耦合
当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素时，就出现了特征耦合。
公共环境耦合
当两个或多个模块通过一个公共数据环境相互作用时，它们之间的耦合称为公共环境耦合。
公共环境可以是全程变量、共享的通信区、内存的公共覆盖区、任何存储介质上的文件、物理设备等。
公共环境耦合的复杂程度随耦合的模块个数而变化，当耦合的模块个数增加时复杂程度显著增加。
内容耦合。耦合程度最高的耦合关系。
（1）一个模块访问另一个模块的内部数据
（2）一个模块不通过正常入口而转到另一个模块的内部。
（3）两个模块有一部分代码重叠。
（4）一个模块有多个入口。

在软件设计中应该追求尽可能松散耦合的系统。模块间耦合松散，有助于提高系统的可理解性、可测试性、可靠性和可维护性。
设计原则：尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合。
【内聚】
内聚：标志着一个模块内各个元素彼此结合的紧密程度，它是信息隐藏和局部化概念的自然扩展。
低内聚有如下三类：

偶然内聚：如果一个模块完成一组任务，这些任务彼此间即使有关系，关系也是很松散的，就叫做偶然内聚。
逻辑内聚：如果一个模块完成的任务在逻辑上属于相同或相似的一类，则称为逻辑内聚。
时间内聚：如果一个模块包含的任务必须在同一段时间内执行，就叫时间内聚。

中内聚主要有以下两类：

过程内聚：如果一个模块内的处理元素时相关的，而且必须以特定次序执行，则称为过程内聚。
通信内聚：如果模块中所有元素都使用同一个输入数据和产生同一个输出数据，则称为通信内聚。

高内聚也有两类：

顺序内聚：如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行，则称为顺序内聚。
功能内聚：如果模块内所有处理元素属于一个整体，完成一个单一的功能，则称为功能内聚。功能内聚是最高程度的内聚。

设计软件时应力求做到高内聚（功能类聚和顺序内聚），内聚和耦合是密切相关的，模块内的高内聚往往意味着模块间的松耦合。

描绘软件结构的图形工具：

层次图
结构图

面向数据流的设计方法的目标：是给出设计软件结构的一个系统化的途径。
信息流有下述两种类型：变换流和事务流。

第六章、详细设计

详细设计的根本目标：是确定应该怎样具体地实现所要求的系统，也就是说，经过这个阶段的设计工作，应该得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。

详细设计阶段的任务还不是具体地编写程序，而是要设计出程序的“蓝图”，以后程序员将根据这个“蓝图”写出实际的程序代码。

程序的三种基本控制结构：顺序、选择和循环。

结构程序设计的经典定义如下所述： “如果一个程序的代码块仅仅通过顺序、选择和循环这三种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。”

【人机交互页面】
在设计人机界面的过程中，几乎总会遇到下述 4 个问题：系统响应时间、用户帮助设施、出错信息处理和命令交互。
系统响应时间是指：从用户完成某个控制动作，到软件给出预期响应之间的这段时间。
系统响应时间有两个重要属性：长度和易变。
3 类人际界面设计指南：一般交互指南、信息显示指南和数据输入指南。

描绘程序处理过程的工具称为过程设计的工具，它们可以分为图形、表格和语言 3 类。
图形：程序流程图、盒图、 PAD 图。
表格：判定表、判定树。
语言：过程设计语言PDL。

程序流程图。又称程序框图。
盒图。结构程序设计。
PAD图。问题分析图，它用二维树形结构的图来表示程序的控制流，将这种图翻译成代码很容易。
判定表。
判定树。
过程设计语言（PDL）。伪码。

面向数据结构的设计方法的最终目标是：得出对程序处理过程的描述。
最著名的两个面向数据结构的设计方法： Jockson 和 Warnier 方法。
Jockson方法的逻辑关系包括：顺序、选择和重复。
程序复杂度的定量度量： McCabe 方法和 Halstead 方法
McCabe 方法：根据程序控制流的复杂程度定量度量程序的复杂程度，这样度量出的结果称为程序的环形复杂度。
Halstead 方法：是一个著名的方法，它根据程序中运算符和操作数的总数来度量程序的复杂程度。

第七章、实现

通常把编码和测试统称为实现。

7.1 编码

源程序代码的逻辑简明清晰，易读易懂是好程序的一个重要标准。

7.2 软件测试与调试

测试阶段的根本目的是尽可能多地发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户。

7.2.1 测试

【测试的定义】
测试为了发现程序中的错误而执行程序的过程。
【测试的目标】
测试的目标是发现软件中迄今为止尚未发现的错误。

7.2.2 调试

【调试的定义】
调试是在测试发现错误之后排除错误的过程。

7.3 黑盒测试与白盒测试

【黑盒测试】
黑盒测试（又称功能测试）把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。黑盒测试是在程序接口进行的测试，只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能接收输入数据并输出正确的信息，程序运行过程中能否保持外部信息（例如数据库或文件）的完整性。黑盒测试又称为功能测试。
【白盒测试】
白盒测试（又称结构测试）是把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。这种方法按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工
作。白盒测试又称为结构测试。
【设计黑盒测试方案的三种技术】

等价划分
边界值分析
错误推断
【设计白盒测试方案两种技术】
逻辑覆盖
（1）语句覆盖
（2）判定覆盖
（3）条件覆盖
（4）判定/条件覆盖
（5）条件组合覆盖
（6）点覆盖
（7）边覆盖和路径覆盖
控制结构测试
（1）基本路径测试
（2）条件测试
（3）循环测试

7.4 软件可靠性与软件可用性

【软件的可靠性】
程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。
【软件可用性】
程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。

7.5 测试步骤

大型软件系统的测试过程基本上由下述几个步骤组成：

模块测试：模块测试的目的是保证每个模块作为一个单元能正确运行，所以模块测试通常又称为单元测试。
子系统测试：子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。模块相互间的协调和通信是这个测试过程中的主要问题，因此，这个步骤着重测试模块的接口。
系统测试：是把经过测试的子系统装配成一个完整的系统来测试。
验收测试：把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是用户积极参与下进行的，而且可能主要使用实际数据进行测试。验收测试的目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书的错误。验收测试也称为确认测试。
平行运行：就是同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果。

7.6 测试准则

软件测试的准则：
1）所有测试都应该能追溯到用户需求。
2）应该远在测试开始之前就制定出测试计划。
3）把 Pareto 原理应用到软件测试中。
4）应该从“小规模”测试开始，并逐步进行“大规模”测试。
5）穷举测试是不可能的。
6）为了达到最佳的测试效果，应该由独立的第三方从事测试工作。

7.7 其他

单元测试集中检测软件设计的最小单元—— 模块。
可以应用人工测试和计算机测试这样两种不同类型的测试方法，完成单元测试工作。
通常，单元测试主要使用白盒测试技术，而且对多个模块的测试可以并行地进行。
在单元测试期间着重从下述 5 个方面对模块进行测试：
1）模块接口 2）局部数据结构 3）重要的执行通路 4）出错处理通路 5）边界条件
集成测试：是测试和组装软件的系统化技术，主要目标是发现与接口有关的问题。
由模块组装成程序时有两种方法：
1）非渐增式测试方法：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序。
2）渐增式测试：把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。
当使用渐增方式把模块结合到程序中去时，有自顶向下和自底向上两种集成策略。

回归测试：是指重新执行已经做过的测试的某个子集，以保证上述这些变化没有带来非预期的副作用。
回归测试就是用于保证由于调试或其他原因引起的变化，不会导致非预期的软件行为或额外错误的测试活动。

确认测试也称为验收测试，它的目标是验证软件的有效性。
通常，验证指的是保证软件正确地实现了某个特定要求的一系列活动，而确认指的是为了保证软件确实满足了用户需求而进行的一系列活动。
软件有效性的一个简单定义是：如果软件的功能和性能如同用户所合理期待的那样，软件就是有效的。
需求分析阶段产生的软件需求规格说明书，准确地描述了用户对软件的合理期望，因此是软件有效性的标准，也是进行确认测试的基础。
确认测试通常使用黑盒测试法。

复查的目的是：保证软件配置的所有成分都齐全，质量符合要求，文档与程序完全一致，具有完成软件维护所必须的细节，而且已经编好目录。
测试用例：把测试数据和预期的输出结果称为测试用例。
一般说来，有下列 3 种调试途径可以采用： 1.蛮干法 2.回溯法 3.原因排除法

第八章、维护

8.1 软件维护的定义

软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
其基本任务是保证软件在一个相当长的时期内能够正常运行。

【软件维护的4项活动】

改正性维护：为了纠正在使用过程中暴露出来的错误。
适应性维护：为了适应外部环境的变化。
完善性维护：为了改进原有的软件。完善性维护占整个维护过程的50%以上。
预防性维护：为了改进将来的可维护性和可靠性。它实质上是软件再工程。

8.2 软件维护的特点

维护代价高昂，大型软件的维护成本高达开发成本的四倍左右。
维护是软件生命周期的最后一个阶段，也是持续时间最长、代价最大的一个阶段。

8.4 软件的可维护性

【软件可维护性的定义】
维护人员理解、改正、改动或改进这个软件的难易程度。

8.4.1 决定软件可维护性的因素

可理解性
模块化(高内聚、低耦合)、详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言
可测试性
维护人员应该能够得到开发阶段的测试方案，以便进行回归测试。
可修改性
耦合、内聚、信息隐藏、局部化、控制域和作用域的关系
可移植性
把程序从一种计算环境（硬件配置和操作系统）移植到另一种计算环境的难易程度。
可重用性
不做修改或稍加改动就能在不同环境中多次使用

下述 3 类活动有可能成为预防性维护的对象：

预定将使用多年的程序
当前正在成功地使用着的程序
在最近的将来可能要做重大修改或增强的程序。
典型的软件再工程过程模型定义了库存目录分析、文档重构、逆向工程、代码重构、数据重构和正向工程 6 类活动。

第十三章、软件项目管理

13.1 估算软件规模

13.1.1 代码行技术（LOC）

13.1.2 功能点技术（FP）

输入项数: 用户向软件输入的项数，这些输入给软件提供面向应用的数据。
输出项数: 软件向用户输出的项数，它们向用户提供面向应用的信息，
查询数: 查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。
主文件数：逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。
外部接口数：机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。

13.2 估算工作量

根据软件规模可以估算出完成该项目所需的工作量，常用的估算模型为静态单变量模型、动态多变量模型和 COCOMO2模型。

13.6 软件配置管理

13.6.1 软件配置管理的定义

软件配置管理是在软件的整个生命期内管理变化的一组活动，是应用于整个软件过程中的保护性活动

13.6.2 基线的定义

基线是已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。

13.6.2 软件配置管理的任务

标识软件配置中的对象
版本控制
变化控制
配置审计
状态告

13.7 能力成熟度模型

能力成熟度模型CMM：用以测量软件机构的软件过程成熟度和评价其软件过程能力的模型。
能力成熟度模型的5个等级从低到高依次是：

初始级
可重复级
已定义级
已管理级
优化级

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！