SCAU 软件工程期末复习

软件发展阶段

程序设计阶段——50至60年代

程序系统阶段——60至70年代

软件工程阶段——70年代以后

软件工程的生命周期

1.需求分析（RequirementsCapture）

2.系统分析与设计（SystemAnalysis and Design）

3.系统实现（Implementation）

4.测试（Testing）

5.维护（Maintenance）

需求分析: 需求分析就是确定要计算机“做什么”。用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。通过对应用问题及其环境的理解与分析，建立系统模型，将用户的需求精确化、完全化，最终形成需求规格说明。

系统分析与设计：就是系统分析与设计。

系统实现：通常所说的编码阶段。

测试阶段：对软件需求分析、设计和编码各阶段的产品进行检查。

维护：在软件产品交付之后进行的修改工件。

原型

软件原型(software prototype)是软件的最初版本，以最少的费用、最短的时间开发出的、以反映最后软件的主要特征的系统。

它具有以下特征

1、它是一个可实际运行的系统

2、它没有固定的生存期。一种极端是扔掉原型（以最简便方式大量借用已有软件，做出最后产品的模型，证实产品设想是成功的，但产品中并不使用）；

另一种极端是最终产品的一部分即增量原型（先做出最终产品的核心部分，逐步增加补充模块），演进原型居于其中（每一版本扔掉一点，增加一点，逐步完善至最终产品）。

3、从需求分析到最终产品都可作原型，即可为不同目标作原型。

4、它必须快速、廉价。

5、它是迭代过程的集成部分，即每次经用户评价后修改、运行，不断重复双方认可。

软件危机的表现

对软件开发成本和进度的估计常常很不正确
用户对“已完成的”软件系统不满意的现象经常发生
软件产品的质量往往靠不住
软件常常是不可维护的
软件通常没有适当的文档资料
软件成本在计算机系统总成本中所占的比例逐渐上升
软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的趋势

软件的特点

软件是一种逻辑实体，而不是具体的物理实体，开发人员智力的体现
软件的生产与硬件不同，在它的开发过程中没有明显的制造过程
在软件的运行和使用期间，没有硬件那样的机械磨损、老化问题

其他特点：
软件的开发和运行常受到计算机系统的限制，对计算机系统有着不同程度的依赖性
软件的开发至今尚未摆脱手工艺的开发方式
软件本身是复杂的（实际问题的复杂性、程序逻辑结构的复杂性）
软件成本相当昂贵
相当多的软件工作涉及到社会因素

软件工程——瀑布模型、快速原型模型、增量模型、螺旋模型

瀑布模型

核心思想

系统开发是逐步求精的过程
各步骤相对独立，便于管理
存在的问题

忽略了需求的动态性
需求完成后，用户对项目的参与即停止
需求描述与设计分开
不支持原型的使用和软件重用
快速原型模型

目的

1明确并完善需求
2探索设计选择方案
3可发展为最终产品
适用范围

用于获取关于系统用户界面的需求
用于检验设计方案的可行性，或探讨系统性能问题
存在的问题

用户将原型误认为最终系统
原型所反映的系统是不全面的

增量模型

1、每版只增加新功能，需求是固定的
2、每版可能增加新需求，以延长软件周期

螺旋模型

螺旋模型主要用于风险分析，可以减少需求变更带来的风险

每一轮开发活动具体包括:

制定下一轮计划
决定设计目标和限制条件
评估候选方案, 风险降解
产品开发
存在的问题：

无法应付不可预见的需求变化

补充：https://my.oschina.net/u/4317177/blog/3433367

需求工程在软件开发中的地位

需求工程对软件开发的影响

需求是制定项目计划的基础
需求工程所产生的最终产物是软件设计和软件实现的基础
需求规格说明是测试工作和用户验收软件系统的依据
需求规格说明是软件维护工作的依据

需求工程面临的困难

需求获取和分析的困难性
需求描述语言和规范化的困难性
需求验证的困难性
需求管理的困难性

软件需求的开发和管理过程

需求工程的领域划分

需求开发
问题获取
分析
编写规格说明
验证

需求管理
建立并维护在软件工程中同客户达成的契约，根据需求的变化对规格说明的内容和版本进行管理

需求工程活动的主要任务

需求获取：确定和收集与软件系统相关的、来自不同来源和对象的用户需求信息。
需求分析：对获得的用户需求信息进行分析和综合，即提炼、分析和仔细审查已收集到的用户需求信息，并找出其中的错误、遗漏或其他不足的地方，以获得用户对软件系统的真正需求，建立软件系统的需求模型。
需求定义：使用适当的描述语言，按标准的格式描述软件系统的需求，并产生需求规格说明及其相应文档。
需求验证：审查和验证需求规格说明是否正确和完整地表达了用户对软件系统的需求。
需求管理：有效地管理软件系统的需求规格说明及其文档，评估需求变更带来的潜在影响及可能的成本费用，跟踪软件需求的状态，管理需求规格说明的版本等。

模块

模块就是从逻辑上将系统分解为更细微的部分，分而治之，复杂问题拆解为若干简单问题，逐个解决。

耦合主要描述模块之间的关系，内聚主要描述模块内部。模块的粒度可大可小，可以是函数，类，功能块等等。

耦合

模块之间存在依赖，导致改动可能会互相影响，关系越紧密，耦合越强，模块独立性越差。

比如模块A直接操作了模块B中数据，则视为强耦合，若A只是通过数据与模块B交互，则视为弱耦合。

独立的模块便于扩展，维护，写单元测试，如果模块之间重重依赖，会极大降低开发效率。

内聚

模块内部的元素，关联性越强，则内聚越高，模块单一性更强。一个模块应当尽可能独立完成某个功能，

如果有各种场景需要被引入到当前模块，代码质量将变得非常脆弱，这种情况建议拆分为多个模块。

低内聚的模块代码，不管是维护，扩展还是重构都相当麻烦，难以下手。

DFD 数据流图

详细看这个：https://blog.csdn.net/lipeijie163/article/details/109468861
一. 基本图形符号

数据流图有4中基本符号元素：数据流、数据处理、数据存储、外部实体。
“→”箭头，表示数据流；
〇：圆或椭圆，表示加工；
=：双杠(带一边开口,一边闭合)，表示数据存储；
□：方框，表示数据的源点或终点。

1.数据流

数据流用箭头来表示，箭头方向即数据流动方向，数据流名标在数据流线上面，数据流命名时应尽量准确。
PS：除了与数据存储之间的数据流不用命名外，数据流应该用名词或名词短语命名。

2.加工

加工也称为数据处理，是对数据进行处理的单元。数据处理名称写在烦那方框内。在分层的数据流图中，加工还应编号。

3.数据存储

数据存储为数据处理提供数据处理所需要的输入流或为数据处理的输出数据流提供存储仓库。具体指暂时保存的数据，它可以是数据库文件或任何形式的数据组织。
流向数据存储的数据流可以理解为写入或查询文件，流出的数据流可理解为从文件读数据或查询结果。

4.数据源点和终点

数据源点和终点是软件系统外部环境中的实体（包括人、组织或其他软件系统），统称外部实体。一般只出现在数据流图的顶层图中，表示了系统中数据的来源和去处。

数据字典

数据字典是所有与系统相关的数据元素的有组织的列表，并且包含了对这些数据元素的精确、严格的定义，从而使得用户和系统分析员双方对输入、输出、存储的成分甚至中间计算结果有共同的理解。简而言之，数据字典是描述数据的信息的集合，是对系统中使用的所有数据元素的定义的集合。是为了描述在结构化分析过程中定义对象的内容时，使用的一种半形式化的工具。

1.1数据字典包含的列信息

名字：数据、控制项、数据存储或外部实体的主要名称。
别名：第1项中所列诸对象的其他名字。
使用地点与方式：使用数据或控制项的处理的列表，以及使用这些对象的方式（如作为处理的输入，从处理输出，作为数据存储，作为外部实体）
内容描述：描述数据或控制项内容的符号。补充信息：关于数据类型、预置值、限制等的其他信息。

一旦把数据对象或控制项的名字和别名输入数据字典，就可以保持命名的一致性。也就是说，支持数据字典的CASET具能够发现重名现象并发出警告信息，这提高了分析模型的一致性，有助于减少错误。

“使用地点与方式”信息是从数据流图中自动提取的。

定义就是自顶向下的分解，所以数据字典中的定义，就是对数据自顶向下的分解。

一般说来，当分解到不需要进一步定义每个和工程有关的人也都清楚其含义的元素时，这种分解过程就完成了。

1.2组成数据的基本类型

顺序：以确定次序连接两个或多个分量。
选择：从两个或多个可能的元素中选取一个。
重复：把指定的分量重复零次或多次。
可选：即一个分量是可有可无的（重复零次或一次）。

用户界面设计黄金三原则

置于用户于控制之下
减少用户的记忆负担
保持界面一致

白盒测试

用于单元测试。
白盒，就是要了解程序的内部结构进行的测试。相对黑盒来说，要求测试人员的水平较高。
首先看一下白盒逻辑覆盖标准：
1、语句覆盖
2、判定覆盖
3、条件覆盖
4、判定-条件覆盖
5、条件组合覆盖
6、路径覆盖
覆盖程度依次增强。

补充