软件工程详细讲解

一：可行性研究

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、 需求分析的任务

回答：“系统必须做什么?”

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

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

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

2.2、需求获取的常用方法

1、访谈:

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

2、问卷调查:

通常与用户访谈组合使用

3、观察用户工作流程:

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

4、建立联合分析小组:

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

5、快速原型法:

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

2.3、需求分析的图形工具

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

也称为ER(Ehtity-Relationship Diagram)图

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

➢实体

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

➢属性

实体或联系所具有的性质

➢联系

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

实体联系图：符号

举例：

学生每学期按照事先安排的课程计划开始学习。
每门课程由多名教师讲授，一个教师可讲授多门课程； 每名学生可以选修多门课程;学期结束后通过考试， 教师登记每门课程、每名学生的成绩，并得到确认后 存档;要求可以按照教师、学生、课程查询和统计成绩，了解课程授课的质量;能给出统计分析报表，供院主管部门参考。

分析：
1、教师与课程的联系：
2、学生与课程的联系：
结果：

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)扇入:

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

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

例题：

结构图的深度为：5
宽度为：8
模块M的扇出为：3
模块T的扇入为：4

四：详细设计

4.1、 根本目标:

应该"怎样具体地实现"系统?

详细设计是软件设计的重要阶段，主要确定每个模块的具体执行过程，也称为“过程设计”

4.2、 详细设计的任务

4.2. 1、处理方式的设计

(1)数据结构的设计。

对于需求分析、总体设计确定的概念性的数据类型进行确切地定义。

(2)算法设计。

用某种图形、表格、语言等工具将模块处理过程的详细算法描述出来，并为实现软件系统的功能需求确定所必须的算法，评估算法的性能。

(3)性能设计。

为满足软件系统的性能需求确定所必须的算法和模块间的控制方式。包括:周转时间、响应时间、吞吐量、精度。

(4)确定外部信号的接收/发送形式。

4.2.2、为数据库进行物理设计

为数据库进行物理设计，确定数据库的物理结构。

4.2. 3、其它设计

(1)输入/输出格式设计:
针对各个功能，根据界面设计风 格，设计各类界面的样式。
(2)人机对话设计:
对于一个实时系统，用户与计算机频繁对话，因此要进行对话方式、内容及格式的具体设计。
(3)编写详细设计说明书。

4.3、详细设计工具（重点）

1、程序流程图

程序流程图的三种结构：a:顺序结构 b:选择结构 c:当型循环结构和直到型循环结构

例题：（D）

2、盒图(N-S图)

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

N-S盒图：例题（IF选择型）

N-S盒图：（循环型）

3、PAD图（以选择结构为主要）

使用二维树形结构的图来表示程序的控制流。将这种图翻译成程序代码比较容易。

例题

4、PDL语言(伪码)

PDL是一种用于描述功能模块的算法设计和加工细节的语言，称为设计程序用语言，它是一种伪码。

例题：

If 登录成功 then
跳转到管理页
else
出错

5、判定表

判定表绘制的步骤如下:

(1) 分析决策问题涉及几个条件;
(2)分析每个条件有几个取值;
(3)画出条件取值分析表，分析条件的各种可能组合;
(4)分析决策问题涉及几个决策方案;
(5)画出有条件组合的决策表;
(6)决定各种条件组合的决策方案，填写决策规则;
(7)合并化简决策表。

例题

例如，某公司为本科以上学历的人重新分配工作，分配 原则如下:
●如果年龄不满18岁，学历是本科，男性要求报考研究生；女性则担任行政工作;学历是硕士不分男女，任课题 组组长;
●如果年龄满18岁不满50岁， 学历本科，不分男女，任中层领导职务，学历是硕士不分男女，任课题组组长;
● 如果年龄满50岁，学历本科，男性任科研人员，女性则担任资料员，学历是硕士不分男女，任课题组组长

分析：
（1）、判定条件可能取值表：

计算组合数：性别：2种；年龄：3种；文化程度：2种，一共12种组合
!在这里插入图片描述](https://img-blog.csdnimg.cn/20201125144035178.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzM3MjA1Mg==,size_16,color_FFFFFF,t_70#pic_center)

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

例题

五：软件测试

5.1、件测试目标

为了发现错误而执行程序的过程

重要观点:
●测试是保证软件质量的关键;
●测试是为了证明程序有错，而不是证明程序无错误;
●测试一般不可能发现程序的所有错误，而是尽可能多的发现错误;

5.2 软件测试方法

(1)测试时是否需要执行被测软件?

●静态测试

●定义:

对被测程序进行特性分析的方法的总称，这些 方法的主要特性是==无须执行被测代码，==而是借助专 用的软件测试工具评审软件文档或程序，度量程序静态复杂度，检查软件是否符合编程标准，借以发 现编写的程序的不足之处，减少错误出现的概率。

●动态测试

●定义:

实际运行被测程序，通过输入相应的测试用 例，判定执行结果(输入/输出的对应关系)是否 符合要求，从而检验程序的正确性、可靠性和有 效性。

●黑盒测试(Black-box testing)

又称功能测试、数据驱动测试或基于规格说明的测试。它 是一种从用户观点出发的测试。用这种方法进行测试时，把被测程序当作一个黑盒，不考虑程序内部结构和特性，测试者只 考虑程序输入输出和程序功，根据需求规格说明书来设则 试用例，推断测试结果的正确性。

●白盒测试( White-box testing )

又称结构测试、逻辑驱动测试或基于程序的测试。它依赖于对程序内部细节的严密检验，针对特定条件设计测试用例， 对软件的逻辑路径进行测试。因此采用白盒测试技术时，必须有设计规约及程序清单。

(2)测试是否针对内部结构和具体算法?

●黑盒测试(Black-box testing)

●白盒测试( White-box testing )

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、预防性维护（占比最少）

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