【期末复习】软件工程

#主打一个速成

#一天敲了两句话 我真能拖延 给自己点个赞

提纲

软件危机 软件工程 软件生存周期

能力成熟度模型 cmm

能力成熟度模型集成

【概要设计 数据类的设计 流的设计 接口的设计】数据流图映射成初始的结构图（先分类：事务性或者变换性），依据启发式原则，对初始的图进行修正，（高扇入低扇入 形状 管道的结果），修正技巧

【详细设计】（设计部分 分值高）对核心关键的模块，要说清动态进行的过程，黑盒子内部，采用的是什么样的算法 什么数据结构 什么数据库 要在详细设计阶段确定每一块的...

描述过程工具：对软件的内部进行描述

程序流程图：非结构化 箭头乱指 

盒图：结构化 没有箭头 从上到下/左到右 次选

pad图：结构化 首选

ljh:【这里没有考题】...具备把第一个转化成后俩的能力

判定表 考：特殊的工具 静态逻辑  整个的执行过程 从模块的输入到输出 不能描述  只能描述一系列变量的特定的组合状态 非通用的程序设计工具 不能做模式（循环结构）  是对复杂的程序流程图盒图pad图的进一步说明

设计完成之后 产出文档 设计说明书（现在不怎么区分概要和详细）

编码阶段（非重点）：开发风范 编程习惯 违反了规则 并不能说一定开发失败 但是在很大程度上降低工作效率甚至会导致失败

拿到了计算机可执行的程序

软件：程序和文档 （程序：特定任务的集合，文档：）

逻辑模型对于设计方案是抽象的

最具体的是 具体的软件 可直接执行

编码完成之后 会有错误 需要在测试阶段调试修正

测试目的：尽可能少的测试用例，找出尽可能多的错误（不是找出所有错误）（也不是验证某功能是否实现）

测试方法：（概念及方法）黑盒 白盒 具体方法

V模型：（测试步骤）

单元测试（编码） 

集成测试（软件的连接）

确认测试（验证修去规格说明书）

系统测试（用户的平台、工作环境）

正式提交给用户

维护和再工程

维护的特点：周期长、成本高

软件维护的时间可能是开发的n倍

是对程序的修改 要跑到需求工程阶段（看 需求规格说明书 设计文档 代码 三者是否一致）回归测试 

维护种类：纠错性（发现错误  20%）、改善性（给一段话 问你是什么样的维护 工作量大时间长占比高）、适应性（20%）、预防性（5%）

在软件的使用过程中，用户往往会提出增加新功能或修改已有功能的建议，还有可能出一些改进的意见，为了满足这些要求，需要进行改善性的维护（50%）

软件项目管理：和软件开发并列 贯穿始终 进行跟踪干预 先于软件开发

依据目标范围

螺旋形上升

需求（最困难）

设计阶段（最重要）

对软件质量进行评估：在设计方案确定之后就可以评估

编码（最简单）翻译 20%

测试 （工作量最大）占整个的40%

维护 （成本最高 时间最长）

软件质量评测模型

工作量规模的度量模型

IBM 变量静态模型

构造性成本模型 cocomo

普特南 putnam

可靠性估算（错误植入法 分别测试法 软件平均故障间隔时间估算）

详细知识点

绪论

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

规模越来越大 成本越来越高 维护越来越困难

（1）如何开发软件，以满足对软件日益增长的需求

（2）如何维护数量不断膨胀的已有软件

表现：

1 对软件开发成本和进度的估计常常很不准确

2 用户对“已完成的”软件系统不满意

3 软件产品的质量往往靠不住

4 软件常常是不可维护的

5 软件通常没有适当的文档资料

6 软件成本在计算机系统总成本中所占的比例逐年上升

7 软件开发生产率提高的速度 远远跟不上计算机应用迅速普及深入的趋势

从而有了软件工程：

软件生存周期

三要素：工具 过程 方法

可行性：经济法律技术

软件计划  每一个任务的工作量人数 顺序 进度 做提前估计

开发软件

首先选取模型：

瀑布模型：

特点 一环扣一环 顺次而下 但客户在中间无法参与

原型模型

增量模型：先开发核心功能，然后再逐步增加功能（每一次增加1都是瀑布模型）

演化模型

面向对象的喷泉模型

需求阶段

需求工程阶段的最终产品是需求规格说明书

（重要的应用：如在设计阶段、编码阶段、测试阶段、维护阶段）

工具：数据流图 用来对软件进行功能建模：源和宿 数据流 加工 （分层 对上一层功能的分解）文件  

如何划分层的数据流图 步骤

给一个问题 使用符号去画数据流图 对其的完整性 一致性 进行验证 父图子图的平衡 数据守恒 局部文件

验证数据流图的过程就是验证需求信息的过程

逻辑模型的重要组成部分：还有数据字典、实体关系图、状态机图

设计阶段（软件怎么做）

概要设计和详细设计

【概要设计 数据类的设计 流的设计 接口的设计】

结构图的要素：模块 模块之间的调用 调用之中传递的数据 

数据流图转化/映射成结构图

先判断类型  事务性 变换性 各用什么方法

对初始的图进行精修 依照启发式的原则、修正技巧进行优化

立起来的椭圆是好的 金字塔...那些是不好的

启发设计策略

1、改造程序结构图，降低耦合度，提高内聚度

2、避免高扇出，并随着深度的增加，力求高扇入

3、模块的影响范围应限制在模块的控制范围之内

4、降低模块接口的复杂程度和冗余程度，提高一致性

5、模块的功能应是可预测的，避免对模块施加过多的限制

6、尽可能设计单入口和单出口的模块

结构图的改进技巧

1、减少模块间的耦合度

2、消除重复功能

3、消除”管道“模块

4、模块的大小适中

5、避免高扇出

6、考虑全局

结构化设计指的是结构化设计（structured design,SD）是将结构化分析得到的数据流图映射成软件体系结构的一种设计方法，SD 强调模块化、自顶向下逐步求精、信息隐蔽、高内聚低耦合等设计准则，并最早在 Myers 以及 Yourdon 和 Constantine 的著作中给出。

【详细设计 模块内部的算法以及采用的数据结构 数据库】

编程阶段

略 见提纲

测试阶段

1、两个错误观点：目的

2、测试方法

白盒测试（又称为结构测试）把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作。

白盒测试主要用于对模块的测试，包括：

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

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

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

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

白盒测试的主要方法有：逻辑覆盖测试、基本路径测试、数据流测试、循环测试

黑盒测试（又称行为测试）把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需求。

黑盒测试可用于各种测试，它试图发现以下类型的错误：

①不正确或遗漏的功能

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

③数据结构错误或外部信息(如外部数据库)访问错误

④性能错误

⑤初始化和中止错误

黑盒测试的主要方法有：等价类划分（选取少量有代表性的输入数据）、边界值分析、比较测试、错误猜测、因果图

3、V模型

4、测试的基本原则 6+6

维护阶段

给定义 判断类型

比重

维护的特点：周期长、成本高

软件维护的时间可能是开发的n倍

是对程序的修改 要跑到需求工程阶段（看 需求规格说明书 设计文档 代码 三者是否一致）回归测试 

维护种类：纠错性（发现错误  20%）、改善性（给一段话 问你是什么样的维护 工作量大时间长占比高）、适应性（20%）、预防性（5%）

在软件的使用过程中，用户往往会提出增加新功能或修改已有功能的建议，还有可能出一些改进的意见，为了满足这些要求，需要进行改善性的维护（50%）

工作量包括生产性的和非生产性的

软件项目管理

贯穿软件开发的始终

概念：

内容：

估算成本模型：

软件质量评估模型：

在软件开发中表现出的特点：

软件开发的各个阶段总是交叉递增和反复的

软件开发的各个阶段在结束的阶段总要有验证和审核的步骤

需求工程是软件开发最困难的，设计工程是最重要的问题（就可以对软件质量进行评估），编码阶段最简单，测试 工作量最大，维护时周期最长成本最高的问题

软件工程的框架：目标活动和原则

原则：

1 选取适宜的开发风范

2 采用合适的设计方法

3 提供高质量的工程支持

4 有效的软件工程管理