软件工程详细讲解

软件工程

• • 一：可行性研究
  • • 1.1、目标
    • 1.2、实质
    • 1. 3、主要任务
    • 1.4、 可行性研究的任务
    • 1. 5、可行性的研究工具
    • • 系统流程图
      • 数据流图
    • 1.6、 成本/效益分析
    • • 1.6.1、成本估计
      • • 1、代码行技术
        • 2、任务分解技术
        • 3、自动估计成本技术
      • 1.6.2、 效益分析
  • 二： 需求分析
  • • 2.1、 需求分析的任务
    • 2.2、需求获取的常用方法
    • • 1、_访谈_:
      • 2、问卷调查:
      • 3、观察用户工作流程:
      • 4、建立联合分析小组:
      • 5、快速原型法:
    • 2.3、需求分析的图形工具
    • • 1、实体-联系图(E-R图)
      • • ?实体
        • ?属性
        • ?联系
        • 实体联系图：符
        • 举例：
      • 2、数据流图(DFD)
      • 3、数据字典(DD)
      • 4、层次方框图
  • 三：总体设计
  • • • 3.1、总体设计的基本目的：
      • 3.2、总体设计的基本任务:
      • 3.3、软件结构设计原理
      • • 3.3.1、软件结构设计方法(结构化方法) :
        • 3.3.2、模块独立性
        • • ●耦合:
          • ●内聚:
          • 设计原则:
      • 3.4、软件结构设计工具
      • • 3.4.1层次图
        • 3.4.2、 HIPO图
        • 3.4.3、软件结构图（重点）
        • • (1)深度:
          • (2)宽度:
          • (3)扇出:
          • (4)扇入:
          • 例题：
  • 四：详细设计
  • • 4.1、 根本目标:
    • 4.2、 详细设计的任务
    • • 4.2. 1、处理方式的设计
      • • (1)数据结构的设计。
        • (2)算法设计。
        • (3)性能设计。
        • (4)确定外部信 的接收/发送形式。
      • 4.2.2、为数据库进行物理设计
      • 4.2. 3、其它设计
    • 4.3、详细设计工具（重点）
    • • 1、程序流程图
      • • 例题：（D）
      • 2、盒图(N-S图)
      • • N-S盒图：例题（IF选择型）
        • N-S盒图：（循环型）
      • 3、PAD图（以选择结构为主要）
      • • 例题
      • 4、PDL语言(伪码)
      • • 例题：
      • 5、判定表
      • • 判定表绘制的步骤如下:
        • • 例题
      • 6、判定树（直接上手例题）
      • • 例题
  • 五：软件测试
  • • 5.1、件测试目标
    • 5.2 软件测试方法
    • • (1)测试时是否需要执行被测软件li>
      • • ●静态测试
        • • ●定义:
        • ●动态测试
        • • ●定义:
          • ●黑盒测试(Black-box testing)
          • ●白盒测试( White-box testing )
      • (2)测试是否针对内部结构和具体算法li>
      • • ●黑盒测试(Black-box testing)
        • ●白盒测试( White-box testing )
    • 5.3、软件的测试过程
    • • 5.3.1、单元测试：
      • 5.3.2、集成测试：
      • • 集成测试的模式
      • 5.3.3、系统测试
      • 5.3.4、确认测试
      • • 分类
        • • 1、 Alpha测试(开发者+用户)
          • 2、Beta测试(用户+用户)
      • 5.3.5、 回归测试
    • 5.4、测试用例的设计
  • 六：维护：
  • • 6.1、软件维护的定义
    • 6.2、进行软件维护的原因:
    • 6.3、软件维护的分类
    • • 6.3.1、 改正性维护
      • 6.3.2、完善性维护（占比最多）
      • 6.3.3、适应性维护
      • 6.3.4、预防性维护（占比最少）

一：可行性研究

1.1、目标

用最小的代价和尽可能短的时间判断问题是否值得去解

1.2、实质

简化的系统分析和设计

1. 3、主要任务

1、分析和澄清问题定义
2、简要的需求分析，建立逻辑模型
3、探索若干解决方案并分析可行性
4、指定粗略的进度

1.4、 可行性研究的任务

1、技术可行性
2、经济可行性
3、操作可行性：在这个应用范围内，是否行得通
4、 会可行性： 会可行性主要研究开发的项目是否存在任何侵犯、妨碍等责任问题，要开发项目的运行方式在用户组织内是否行得通，现有管理制度、人员素质和操作方式是否可行

1. 5、可行性的研究工具

系统流程图

用来描述物理系统概貌
系统流程图表达的是数据在系统各部件之间流动的情况， 而不是对数据进行加工处理的控制过程(程序流程图)。

数据流图

用来描述系统逻辑功能
数据流图(DFD)是一种图形化技术，它描绘信息流和数据从 输入移动到输出的过程中所经受的变换，即数据流图描绘数据在软件中流动和被处理的逻辑过程。

1.6、 成本/效益分析

成本/效益分析的目的是从经济角度评价开发一个新的软件工程项目是否可行。成本效益分析首先是估算待开发软件系统的成本，然后与可能取得的效益进行比较。

1.6.1、成本估计

1、代码行技术

软件的成本=每行代码的平均成本（取决于软件的复杂程度和工资水平）*源代码的行数

2、任务分解技术

将软件开发工程分解为肉感相对独立的任务，最常用的方法是按开发阶段划分任务
软件开发成本=任务1的成本+任务2的城呢+…

3、自动估计成本技术

在有长期收集的历史数据和良好的数据库系统的支持下，可以采用自动估计成本软件工具以减轻劳动强度，得到相对客观的估计结果。

1.6.2、 效益分析

效益包括有形效益和无形效益。
1、有形效益可 以用货币的时间价值、投资回收期、纯收入等指 标进行度量。
2、无形效益主要是从性质.上、心理 上进行衡量，很难直接进行量化。

二： 需求分析

2.1、 需求分析的任务

回答：“系统必须做什么/p>

任务:完整、准确、清晰、具体地确定系统所 要完成的工作。

出发点:《可行性研究 告》

结果:《软件需求规格说明书》( SRS)

2.2、需求获取的常用方法

1、访谈:

直接与用户交流，最原始的获取用户需求的技术

2、问卷调查:

通常与用户访谈组合使用

3、观察用户工作流程:

需要对复杂流程加深了解 或对关键人物理解不清楚时使用

4、建立联合分析小组:

由软件开发方和客户方共同组成

5、快速原型法:

先快速建立-一个原型系统，用来 演示系统功能，根据用户要求进行修改

2.3、需求分析的图形工具

1、实体-联系图(E-R图)

也称为ER(Ehtity-Relationship Diagram)图

是一种面向问题的数据模型，是按照用户观点对数据建立的模型。
数据模型中包含3种互相关联的信息:实体、属性和联系。

?实体

对软件必须理解的复合信息的抽象
复合信息： 是具有一系列不同性质或属性的事物, 仅有单个值的事物不是数据对象。

?属性

实体或联系所具有的性质

?联系

实体之间的联系
.一对一联系(1:1) .
一对多联系(1:N)
-多对多联系(M: N)

实体联系图：符

2、数据流图(DFD)

3、数据字典(DD)

4、层次方框图

三：总体设计

3.1、总体设计的基本目的：

回答“概括的说，系统应该如何实现”的问题

3.2、总体设计的基本任务:

设计软件的总体结构，即确定系统中每个程序由哪些模块组成，每个模块的功能，模块之间的调用关系。

3.3、软件结构设计原理

3.3.1、软件结构设计方法(结构化方法) :

解决一个复杂问题时自顶向下逐层把软件系统划 分成若干模块的过程。每个模块完成一个特定的子功能，所有的模块按某种方法组装起来，成为-一个整体，完成 整个系统所要求的功能。

3.3.2、模块独立性

所谓模块独立性是指：
每个模块完成一个相对独立的功能，并且和其他模块之间的联系最少且接口很简单。衡量模块独立性的标准:耦合和内聚。（高内聚、低耦合）

●耦合:

定义：软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。

●耦合类型

无直接耦合一数据耦合一特征耦合一控制耦合一公共耦合一内容耦合
低-→________________________________________________-→高

●内聚:

一个模块内部各个元素彼此结合的紧密程度的度量。内聚性越高，模块独立性越高。

●内聚类型

偶然内聚一逻辑内聚一时间内聚一过程内聚一 通信内聚一顺序内聚一功能内聚
低-→________________________________________________-→高

设计原则:

为争做到低耦合高内聚，提高模块的独立

3.4、软件结构设计工具

3.4.1层次图

适于在自顶向下设计软件的过程中使用。

3.4.2、 HIPO图

3.4.3、软件结构图（重点）

(1)深度:

指软件结构中模块的层次数，它表示控制的层次数，一定意义上能粗略地反映系统的规模和复杂程度。

(2)宽度:

指同一层次中最大的模块个数。

(3)扇出:

指一个模块直接调用(下级)的模块数目。经验证明，良好的系统结构平均扇出数一般是 3-4，不能超过5-9。

(4)扇入:

指有多少个上级模块直接调用它。

一般较好的软件结构:
顶层高扇出，中层低扇出，底层高扇入。

例题：

2、盒图(N-S图)

a:顺序型 b:IF选择型（重） c:case型多分支 d:循环型 e:调用子程序

N-S盒图：（循环型）

例题

6、判定树（直接上手例题）

例题

5.3、软件的测试过程

一软件测试过程与开发过程是一个相反的过程。
-开发过程经历需求分析、概要设计、详细设计到 编码等一系列逐步细化的过程
那么测试的单元 测试、集成测试到系统测试是一个逆向的求证过 程。

测试过程主要是指代码调试之后的动态测试过程 测试的过程-一般分为单元测试、集成测试、系 统测试，有时还要增加用户的验收测试，在每次 测试的过程中可能伴随着回归测试。

5.3.1、单元测试：

将每个模块作为-一个独立的实体来测试。 用详细设计描述作指南，对重要的程序执行通 路进行测试，以便发现模块内部的错误。发现 编码和详细设计的错误。

5.3.2、集成测试：

按照概要设计的要求组装独立模块成为系统, 同时经过测试来发现接口错误的一种系统化的技术。

集成测试的模式

(1)非渐增式测试方法
(2)渐增式测试方法(集成测试中较多使用)

5.3.3、系统测试

系统测试是指将经过集成测试的软件作为整个基于 计算机系统的一个元素，与计算机硬件、外设、支持软件、数据和人员等元素结合在一-起，对计算机系统进行 一系列的组装测试和确认测试。系统测试的依据是软件需求规格说明书，测试的内容主要包括功能测试和性能 测试两方面。

5.3.4、确认测试

确认测试又称“验收测试”、“有效性测试”，其任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
需求分析阶段产生的软件需求规格说明书，是软件有效性的标准，是进行确认测试的基础。

分类

1、 Alpha测试(开发者+用户)

由用户在开发者的场所进行，并且在开发者对用户的 ‘指导”下进行测试。开发者负责记录发现的错误和使用 中遇到的问题。AIpha测试是在受控的环境中进行的。

2、Beta测试(用户+用户)

由软件的最终用户们在一一个或多个客户场所进行。开发者通常不在Beta测试的现场。Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户记录在Beta测试 过程中遇到的一切问题，并把这些问题 告给开发者。

5.3.5、 回归测试

重新执行已经做过的测试

5.4、测试用例的设计

测试用例设计的基本目的是确定一组最有可能 发现某个错误或某类错误的测试数据，好的测试用 例可以在测试过程中重复使用，但不可能测试程序 的每一条路径，也不可能把所有的输入数据都试一 遍。

测试用例的设计人员必须努力以最少量的测试用例来发现最大量的可能错误。

六：维护：

6.1、软件维护的定义

在交付使用后，为改正错误或满足新需要而修改软件的过程

6.2、进行软件维护的原因:

(1)在运行中发现测试阶段未发现的潜在软件错误和设计缺陷;（改正）
(2)需要改进软件设计以增强软件的功能，提高软件的性能;（完善）
(3)要求已运行软件适应特定的硬件、软件、外部设备和通信设备等新的工作环境，或适应已变动的数据或文件;（更新）
(4)为预防软件系统的失效而对软件系统实施修改。（预防）

6.3、软件维护的分类

6.3.1、 改正性维护

对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错，以及验证、修改的回归测试过程， 称为改正性维护。

6.3.2、完善性维护（占比最多）

为了满足用户在使用过程中对软件提出的新的功能与性能要求， 需要对原来的软件的功能进行修改或扩充。

6.3.3、适应性维护

使软件适应外部新的软硬件环境或者数据环境发生的变化， 而进行修改软件的过程。

6.3.4、预防性维护（占比最少）

为了提高软件未来的可维护性、可靠性等，或为了给未 的改进奠定更好的基础而修改软件的过程。