软件工程

第一章&第二章 软件&软件工程

软件是：指令集合、数据结构、软件描述信息

软件既是产品、也是产品交付的载体

软件与硬件的区别特征：

• 软件是设计开发的，不是生产制造的

• 软件不会磨损，但会退化

• 大多数软件是根据实际顾客定制的；软件设计中大规模复用刚刚开始

软件是与计算机操作系统有关的程序、规则、规程以及可能有的文件、文档及数据

软件工程：将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件

软件质量：

• 与明确定义的功能和性能需求的一致性
• 与明确成文的开发标准的一致性
• 与所有专业开发的软件所期望的隐含的特征的一致性(健壮性、可维护性、可移植性等)

编程占软件生命周期的：40%左右

第三章 软件过程

通用过程架构：沟通；策划；建模；构建；部署

CMMI:不完整级，已执行级，已管理级，已定义级，已定量管理级，优化级

CMM:初始级，可重复级，已定义级，已管理级，优化级

第四章 传统过程模型

名称	实质	优点	缺点	其他
瀑布模型	面向阶段、线性	1、简单 2、各阶段都验证，便于质量管理	1、缺乏灵活性 2、缺乏演化性 3、线性模型，回溯性差
增量模型	非整体开发、基于瀑布的渐增模型和原型的快速原型	1、开发顺序灵活 2、以组件为单位开发 3、可分批提交产品	1、对于需求没有完整定义 2、体系结构必须开放	与原型的区别：每个增量是一产品与瀑布区别：非整体
原型模型	事先不能定义需求，简单	1、预先不知道所需系统 2、开发人员没有信心	1、难以单独使用 2、太简单
RAD模型	增量型、使用可复用构件、瀑布模型的高速变体、并行操作	加快了开发速度	1、消耗大量人力 2、时间限制 3、需要合理模块化 4、不适合高风险和交际性强的项目	三个阶段：业务建模、数据建模、过程建模
螺旋模型	瀑布+增量+风险分析	1、适用于大型应用开发 2、任意阶段都可使用 3、反映现实生活	1、依赖于风险评估 2、模型较新	步骤：循环：制定计划->风险分析->实施工程->客户评估
UP模型	以架构/体系为中心，以用例和风险驱动，迭代且增量，由UML方法支持	适用于面向对象技术		5个阶段：初始、细化、构建、转换、生产

第五章 敏捷过程模型

敏捷模型

四大价值观：

个体与交互 > 过程和工具

可用的软件 > 完整的文档

客户合作 > 合同谈判

应对变更 > 遵循计划

特点：

1、允许团队调整合理安排任务

2、精简工作产品

3、快速向用户提供适应的产品和环境

XP极限编程

使用面向对象的方法作为模型，包含策划、设计、编码和测试4个活动

Scrum

待定项目->冲刺->例会->演示

第六章 软件工程的人员方面

第七章 理解需求

需求工程的地位和作用：

• 理解软件如何影响业务、客户想要什么、最终用户如何和软件交互
• 需求工程的产品：用户场景、功能和特征列表、分析模型或规格说明

需求工程的任务：

起始、导出、精化、协商、规格说明、确认、管理

起始：对问题方案等建立基本理解

导出：询问客户目标

精化：开发一个精确模型

协商：与用户协商处理

规格说明：需求工程完成的最终产品

确认：对结果进行评估和确保

管理：控制跟踪需求变更

需求开发属于软件定义阶段

软件需求的分类：

功能需求

非功能需求：性能需求、质量属性、对外接口、约束

第八章 需求建模—基于场景

第九章 需求建模-基于类

第十章 需求建模-行为模式和APP

结构化分析

用抽象模型，按照软件内部数据传递、变换自顶向下逐层分解

第十一章 设计概念

软件设计的目标和任务

数据设计、系统结构设计、接口设计、过程设计

软件体系的模块化

整个软件软件被划分成若干单独命名和可编址的部分。

好处：

• 更容易计划开发
• 可以定义和交付软件增量
• 更容易实施变更
• 能够更有效地开展测试和调试
• 可以开展长期维护而没有严重副作用

抽象化：再进行模块设计时，可有不同的抽象过程。包括：过程抽象和数据抽象

信息隐蔽：每个模块实现细节对其他模块是隐蔽的

功能独立

是模块化、抽象化和信息隐蔽的直接结果

通过开发专一功能和避免与其他模块有过多交互来实现功能独立

耦合：模块间相互连接的紧密程度

内聚：一个模块内部各个元素彼此结合的紧密程度

模块独立性强的模块应该是高内聚低耦合的

重构：无需改变代码设计的外部行为而是改进其内部结构

设计模式——接口设计元素

设计模式——构件级设计元素

• 为所有本地数据定义数据结构
• 为构件内发生的处理定义算法细节
• 允许访问所有构件行为接口

第十二章 体系结构设计

第十三章 构件级设计

构件级设计

构件：软件中一个模块化的构造块

OMG UML：定型化的可配置和可替换的部件，暴露了一系列的接口。

四个基本设计原则：

开闭原则：模块应该对外延具有开放性，对修改具有封闭性，

Liskov原则：子类可以替换它们的基类。

依赖倒置原则：依赖于抽象，而非具体实现

接口分离原则：多个用户专用接口比一个通用接口要好。

第十四章 用户界面设计

用户界面设计

黄金规则

• 用户操纵控制
• 减少用户的记忆负担
• 保持界面一致

模型：

用户模型

设计模型

心里模型

实现模型

第十七章 软件测试策略

软件测试的目的

从用户角度：普遍希望通过软件测试暴露软件中隐藏的错误和缺陷

软甲开发者角度：希望测试成为表明软件产品不存在错误的过程

• 测试是程序的执行过程，目的在于发现错误
• 一个好的测试用例在于能发现至今未发现的错误
• 一个成功的测试是发现至今未发现的错误

换言之：

• 用最少的人力系统的找出软件中潜在的各种错误和缺陷
• 它能够证明软件的功能和性能是否与需求说明相吻合
• 测试不能表面软件中不存在出错误，只能说明软件存在错误

软件测试的对象

• 贯穿于软件定义和开发的整个阶段
• 各阶段得到的所有文档都应该成为测试对象
• 需要进行确认和验证工作

软件测试的组织

独立测试小组（ITC）

策略问题

四个步骤：单元测试、集成测试、确认测试、系统测试

组装测试

非渐增式组装测试：

• 将单元测试和集成测试分为2个阶段测试
• 工作量大，每个模块都要驱动模块和桩模块
• 组装才能发现
• 可并行测试所有模块

渐增式组装测试：

• 组合在一起同时完成
• 工作量少，用的都是测过的模块
• 较早发现接口错误
• 有利于排错
• 比较彻底

单元测试（模块测试）

• 针对软件设计的最小单位—软件构件或模块进行测试，目的发现各模块内部可能存在的各种差错
• 从程序的内部出发，多个模块可平行地独立进行单元测试

内容

• 主要是白盒测试
• 模块接口测试
• 局部数据结构测试
• 路径测试
• 错误处理测试
• 边界测试

集成测试（联合测试）

• 在单元测试的基础上，需要将模块按照设计要求组装成系统
• 在单元测试的同时可以进行组装测试

一次性组装方法

• 非增殖式组装方法。也叫整体组装
• 对每个模块测试后一次性组装

增值式组装方式（渐进式组装）

• 首先一个个测试，然后逐步组装

• 边连接便测试，以发现问题

• 自顶向下的增值方法：

  • 按深度方向组装
  • 较早验证控制和判断点

• 自底向上的增值方法：

  • 不再需要庄模块
  • 可以直接允许子程序获得信息

• 混合增值测试：

  • 衍变的自顶向下的增值测试
    • 首先对输入输出测试
    • 自底向上组装
    • 主模块自顶向下测试
  • 自底向上—自顶向下的增值测试
    • 对读进行自底向上
    • 对写进行自顶向下

冒烟测试

时间关键性项目的步进机制，让软件团队频繁地对项目进行评估

好处：

• 降低集成风险
• 提高最终产品质量
• 简化错误的诊断和修正
• 易于评估进展状况

回归测试

重新执行以进行测试的子集，以确保变更没有传播不期望的副作用

α测试&β测试

α测试：

• 可以在编码结束时开始

• 也可以在确认测试过程中产品达到稳定可靠程度后开始

β测试：

• 多个用户在实际情况下测试
• 开发者通常不在场

第十八章 传统测试用例设计

黑盒测试

在程序接口上进行测试

等价类划分法

输入域划分成若干部分，然后从中选取少数代表性数据

边界法

等价类比的补充，选取正好、刚刚大于、刚刚小于的数据测试

白盒测试

基本路径测试：

程序环路的复杂性：

区域的数量 = 环复杂度V(G)

环复杂度V(G) = E-N+2

环复杂度V(G) = P+1 （P为判定节点数）

条件测试路径选择：

嵌套型：若有n个判定语句，需要n+1个用例

连锁型：若有n个判定语句，需要2^n个测试用例

循环测试路径选择：

1、简单循环

2、嵌套循环

第十九章 面向对象的测试技术

第二十二&二十三章 项目管理

• 范围覆盖整个软件工程过程

• 对工作规范、可能风险、需要资源、要实现的任务、经历的里程碑、花费工作量、进度安排做到有数

• 在技术工作开始前就开始了

The 4 P's

• People—成功项目的重要因素
• Product—要建造的软件
• Process—活动任务等
• Project—所需所有工作

团队泛型

• 封闭式泛型—按权利来分
• 随机泛型—依赖于个人主动性，适用于创新
• 开放式泛型—具有封闭式的控制，又有随机的创新，适用于解决复杂问题，效率低
• 同步式泛型—没有主动联系，各自解决片段

定义项目特征和项目计划的方法W5HH原则：

why：为什么系统被开发

what：做什么

when：什么时候

who：某功能由谁负责

where：机构组织位于何处

how much：每种资源需要多少

how：工作如何进行

软件度量

为了了解产品开发的技术过程和产品本身

作用：有效的定量地进行管理

目的：

• 改进过程
• 提高产品质量

度量方法：直接度量、间接度量

直接度量

代码行数、执行速度、存储量大小

面向规模的度量：列出了过去几年完成项目及其规格数据

间接度量

面向功能的度量：FP = 总计数 X (0.65 + 0.01 X SUM(Fi))

缺陷排除效率(DRE)

DRE = E/(E+D)

E是交给用户前发现的错误数

D是交给用户后发现的错误数

理想状态为DRE = 1

第二十四章 估算

• 软件项目管理开始于项目计划
• 项目计划第一项活动就是估算
• 主要为时间和工作量估算

目标：对资源成本进度进行合理规划

LOC&FP

步骤：

1、对每个分解的功能提出一个有代表性的估算值范围

2、利用历史数据和经验，对功能划分为最佳、可能、悲观三种情况，a、m、b

3、计算LOC或FP的期望值： E = (a+4m+b)

COCOMO三个阶段：

应用组装阶段：

Application：用应用点进行估算规模

Composition：用原型解决高风险问题

早期设计阶段

体系结构后阶段

决策树分析

第二十五章 进度安排

人员与工作量的关系

一个软件项目单独开发生产率最高

40-20-40原则：

编码工作占20%，编码前工作占40%，编码后工作占40%

获得值分析

BCW : 每项工作的预计工作量 BCWS : 计划按指定时间完成的每项工作任务的预计工作量和

BAC : BCW总和 EV : EV = BCWS / BAC BCWP：已经按指定时间完成的工作任务的预计工作量之和。

ACWP : 已经完成的工作任务的实际工作量之和。

EV = BCWS / BAC

SPI = BCWP / BCWS

SV = BCWP - BCWS

CPI = BCWP / ACWP

CV = BCWP - ACWP