软件工程（下）

需求工程

概述

需求获取

分层

获取方法

项目管理维度

需求开发---需求分析

UML（统一建模语言）：平台无关、语言无关

UML 4+1视图

需求的定义、验证、跟踪、变更

需求定义

需求验证

需求跟踪

需求变更管理

软件系统建模

软件界面设计（黄金三法则）

结构化设计

内聚

耦合

模块四要素

面向对象设计

基本过程

类的分类

设计原则

软件测试

测试类型

白盒黑盒

白盒测试【结构测试】：主要用于单元测试阶段

黑盒测试【功能测试】：主要用来集成测试、确认测试盒系统测试阶段

软件测试阶段

软件系统测试

需求工程

概述

软件需求就是指用户对系统在功能、行为、性能、设计约束等方面的期望。

需求工程的主要活动的阶段可以划分为：

需求获取:从用户的业务场景来获取到需求是什么
需求分析：获取到的需求进行整合、判断、分析、建模
形成需求规格【形成SRS】:这个就是形成文档形式的需求
需求确认与验证【形成需求基线】（经过评审的SRS）:也就是我们常用的需求评审
需求管理【变更控制、版本控制、需求跟踪、需求状态跟踪】

需求工程主要分为这五个，前四个我们可以看做是需求开发，最后一个可以单独看成事对需求的一个管理，也就是对需求基线进行管理

需求获取

这个就是从用户或者其他端口来获取到最原始的需求。

分层

需求获取的时候，不同层级的需求、获取的方式也不一样，目标也不太一样

大致分为三层：

业务需求（整体全局的）
用户需求（用户视角）
系统需求（计算机化）这一层级还可以继续细分：1：功能需求 2：性能需求 3：设计约束

获取方法

用户面谈

1-1、有代表性的用户、了解主观想法、交互很好、但是成本很高、要有领域只是支撑

需求专题研讨会

高度组织的群体会议、各方参与、了解想法、清楚分歧、交互好、成本高

问卷调查

用户多、无法一一访谈、这个成本低

现场观察

针对较为复杂的流程和操作

原型化方法

通过简易系统方式解决早期需求不确定的问题

头脑风暴法

一群人围绕新的业务、发散思维、不断的产生新的观点

项目管理维度

基本需求（明确的、常规需求）
期望需求(不明确的、隐含的)
兴奋需求（多余的）

需求开发---需求分析

如图所示就是结构化开发，在初期会建立三种模型，这里最注重功能模型和数据模型，功能模型最常见的工具就是数据流图。数据流程用于对功能建模。

在数据流里，我们能看到哪些人使用角色，哪些角色传递数据给系统，哪些角色从系统中获取到某些关键的数据。

UML（统一建模语言）：平台无关、语言无关

统一建模语言，其实是之前面向对象的多种建模工具整合形成的，他可以用在多个场景和环境工具集。就好比我们有一个工具箱，我需要用什么工具就拿什么，未必要在所有的项目中，把所有的工具都用上

UML大概有三块

构造块分为三部分

事物

结构事物：这是最静态的部分，包括：类、接口、协作、用例、活动类、构件和节点

行为事物：代表时间和空间上的动作。包括：消息、动作次序、连接

分组事物：看成是个盒子，如：包、构件

注释事物：UML模型的解释部分，描述、说明和标注模型的元素。

关系（泛化、扩展、依赖等等）
图（用例图、类图、对象图等）

规则：这个描述的uml体系运行的基本原则

范围：给一个名字以特定含义的语境

可见性：怎样使用或看见名字

完整性：事物如何正确、一致的相互联系

执行：运行或模拟动态模型的含义是什么

公共机制：所有的元素要达成的共识。

规则说明：事物语义的细节描述、他是模型真正的核心

修饰：通过修饰来表达更多的信息

公共分类：类与对象、接口和实现

扩展机制：允许添加新的规则

UML 4+1视图

需求的定义、验证、跟踪、变更

需求定义

严格定义法：

所有需求都能被预先定义
开发人员和用户之间能准确的清晰的交流
采用图形、文字可以充分体现最终系统

原型法：

并不是所有的需求都能在开发前被准确的定义和说明
项目参加者之间通常都存在交流上的苦难
需要实际的、可供用户参与的系统模型
有合适的系统开发环境
反复是完全需要和值的提倡的，需求一旦确定，就应遵从严格的方法

需求验证

是我们已经完成了需求规格说明书，已经吧需求落地成了文档，这个文档是有开发方主导完成的，当我们的甲方认不认呢？结果人家一看你的不行，这个时候我们应该提前验证、看看是不是需求和客户当时提的是不是一样的。

需求跟踪

需求变更管理

需求的变更是每一个开发都绕不开的，我们没办法避免。唯一不变的就是变化。无法杜绝的时候，我们就只能在变更的时候做好管理。

软件系统建模

从现有的系统到新的系统往往要经历多步的流程，现有的系统对应的其实就是我们的物理系统，我们把现有的系统模型化、就会得到物理模型，我们再将物理模型抽象化得到逻辑模型，逻辑模型我们进行调整和优化以后实例化他们得到物理模型。我们再将物理模型具体化那就是物理系统了，也就是我们的新系统。

软件界面设计（黄金三法则）

置于用户控制之下

不强迫用户进入不必要的或者不希望的动作方式来定义交互方式

提供灵活的交互方式

允许用户交互可以被中断和撤销

减少用户的记忆负担

减少对短期记忆的要求

建立有意义的缺省

定义直觉性的捷径

界面的视觉布局应该基于真实世界的隐喻

不断进展的方式揭示信息

保持界面的一致性

允许用户将当前任务放入有意义的语境

在应用系列内保持一致性

过去的交互模型已经建立了用户的期望，如果不是迫不得已，不要去改变它

结构化设计

结构化开发方法中的设计阶段就是结构化设计，在这个阶段，首先要明确两个点，一个叫概要设计、一个叫详细设计

概要设计（外部设计）：功能需求分配给软件模块、确定每个模块的功能和调用的关系，形成模块结构图

详细设计（内部设计）：为每个具体任务选择适当的技术手段和处理的方法

结构化设计原则：

模块独立性原则

保持模块的大小适中

多扇入，少扇出

深度和宽度均不要过高

内聚

耦合

模块四要素

输入和输出：模块的输入来源和输出去向都是同一个调用者，即同一个模块
处理功能：指模块把输入转换成输出所做的工作
内部数据：该模块本身引用的数据
程序代码：用来实现模块功能的程序

面向对象设计

基本过程

在面向对象的开发过程中，先有分析，再由设计师设计方案、界面、技术支撑、再实现设计模型

分析阶段：一般会构造两大模型：用例模型（用例图）和分析模型（类图、顺序图、等等）

设计师：设计用户界面、细化设计模型

设计模型：架构图、示例图、类图、状态图、活动图等等

类的分类

边界类

机器接口（API）、人机交互（用户界面）这个类主要对外界打交道、比如说显示屏、打印机接口、对话框、菜单、报表

控制类

应用逻辑、业务逻辑、数据访问逻辑；比如说身份验证器

实体类

对接数据库，对标数据源，一个学生表对应一个学生类

设计原则

七大设计设计原则可以看我的分类专栏，该专栏详细的记载了七大原则（编程思想_可有道？的博客-CSDN博客）

软件测试

测试类型

动态测试（计算机运行）：白盒、黑盒、灰盒

静态测试（人工检测盒计算机辅助分析）：桌前检查、代码审查、代码走查

白盒黑盒

白盒测试【结构测试】：主要用于单元测试阶段

控制流测试【逻辑覆盖测试（语句覆盖最弱、路径测试覆盖最强）】
数据流测试
程序变异测试【错误驱动测试】

黑盒测试【功能测试】：主要用来集成测试、确认测试盒系统测试阶段

等价类划分：不同的等价类揭示的问题也不一样
边界值分析：1<=x<=10,可以取x的值为0,1,10和11作为测试数据
错误推测：依靠测试人员的直觉和经验

软件测试阶段

软件系统测试

功能测试
性能测试

负载测试：各种工作负载下的系统性能

压力测试：测上限，系统的瓶颈或者不能接受的性能点

强度测试：测下限，系统资源很低、很匮乏的情况下运行

容量测试：并发测试：同时在线的最大用户数

可靠性测试：MTTF之类的参数

健壮性测试
用户界面测试
安全性测试
安装与反安装测试