软件工程笔记

软件工程

第一章：软件开发的本质

第二章：软件需求与软件需求规约

软件需求

1.需求的基本性质：
必要的、无歧义的、可测的、可跟踪的、可测量的
2.需求的分类：

（1）功能需求
（2）非功能需求
性能需求 ： 并发
接口需求：tcp/ip协议
设计约束：语言，并发，握手协议，硬件限制
质量属性：安全性、可扩展性

3.需求的发现
自悟
交流-用户
观察-市场
小组会、头脑风暴
提炼、素材

需求规约（SRS）

1. 需求规约定义：
   是一个 软件/产品/系统 所有需求陈述的正式文档，他表达了一个软件、产品、系统的概念模型
2. 需求规约的基本性质：
   （1）重要性和稳定性程度，对需求进行分级
   （2）可修改
   （3）完整的：没有被遗漏的需求
   （4）一致的：不存在互斥的需求（性能和安全）
3. 需求规约的格式 - ( IEEE标准 描述的需求规格 )
   （1）引言：目的、范围、定义、参考文献
   （2）总体描述：产品描述、产品功能、用户特性、约束、假设和依赖
   （3）特定需求：是文档的技术核心
   （4）附录
   （5）索引
4. 需求规约的表达
   （1）非形式化的需求规约
   （2）半形式化的需求规约
   （3）形式化的需求规约
5. 需求规约的作用
   （1）需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现
   （2）需求规约是一个管理控制点
   （3）对于产品、系统的设计而言，需求规约是一个正式的、受控的起始点
   （4）需求规约是创建产品验收计划和用户指南的基础

本章小结
1.正确定义问题，是解决问题的基础
2.需求的获取是软件开发的基础
3.需求的类型：功能性需求和非功能性需求2大类
4.非功能性需求：性能需求、接口需求、设计约束、质量需求
5.需求规约是将上述需求用标准文档表达出来
6.需求规约的作用概括4个方面

第三章：结构化方法（重要）（25%）

八字方针：自顶向下，逐步求精

结构化需求分析

1. 需求技术的基本特征
   提供方便通信机制
   鼓励需求分析人员使用问题空间的术语思考问题，编写文档
   提供定义系统边界的方法（控制成本，边界）
   提供支持抽象的基本机制（建模，应对变化）
   为需求分析人员提供多种可以选择的方案
   提供特定的技术，适用需求的变化
2. 需求分析中的基本术语
   （1）数据：客观事物的一种表示（描述）
   （2）信息：具有特定语义的数据（本质）
   （3）数据是信息的载体
   （4）数据流：数据的流动（源——目的地）
   （5）加工：数据变化单元
   （6）数据储存
   （7）数据源和数据潭
3. 表示方法
4. 数据流程图（DFD图）
   一种表示数据变化的图形化工具，其中包含的元素可以是数据流、数据储存、加工、数据源和数据潭
5. 数据流程图的元素（4要素）
   数据源/数据潭，数据流，数据加工，数据存储
   建模过程
   （1）自顶向下、逐步求精
   （2）建立系统环境图（环境和数据源、数据潭的关系）
   （3）0层图：从0层图开始对流程图中的要素编号（p1,p2）
   （4）1层图
   （5）…
6. 需要注意的问题
   黑洞：只有输入没有输出
   只有输出而没有输入
   灰洞：即输入不足产生输出，是经常不易被察觉的错误
   加工处理只用来表示数据的处理和变化，避免将计算机命令作为处理
   数据流必须起于且/或止于处理，即每一个数据流必须有一个处理与之有关，数据流不能起于数据存储且止于一个数据源/数据潭或另一个数据存储；也不能起于某个实体且止于另一个数据源/数据潭或者数据存储（必须要加工流程）
7. 数据字典(数据项+数据流)
   （1）定义数据流程图中所有数据流和数据存储的数据结构
   （2）顺序结构： +
   （3）选择结构：｜
   （4）重复结构 { }
   （5）子界： m…n
8. 加工的描述 ☆
   （1）判定表：称为 决策表，是一个二维表，它说明了每一种条件组合所产生的结果
   

（2）判定树：也称决策树，是用来描述在一组不同的条件下，决策的行动是根据不同的条件及其取值来选择的处理过程。业务规则的描述通常可以使用判定树这一过程描述工具

（3） 结构化语言
若逻辑关系比较简单，可以用结构化的自然语言描述
IF ******
a = b
ELSE ******
a = c
9. 需求验证：
必要性、无歧义性、可测性、可跟踪性、可测量性
10. 需求中的错误类型
不正确的事实，遗漏、不一致 …
11. 发现错误的方法
审查 65% 单元测试 10% 评估10% 集成测试 5% 其他

结构化程序设计

1.总体设计和详细设计

层次图+IPO图 = HIPO图 介绍

模块结构图 ☆

层次图

2.总体设计步骤
两种映射方法
（1） 变换设计（分解的模块是一个 数据凝聚的模块）
基于变换的数据路程图是一个线性的顺序结构，由输入、输出和变换中心三部分组成。

（2）事务设计（模块为逻辑凝聚的模块）
基于事务的数据流程图有一个事务处理中心，相互平行的加工路径

1. 本质：
   使程序的控制流程线性化，实现程序动态执行顺序符合静态书写的结构，提高程序的可读性
2. 顺序结构、选择结构、多分支结构、循环结构
   
   
   
3. 详细设计的工具
   （1）程序流程图
   （2）盒图（N-S图）
   （3）PAD图：问题分析图
   （4）类程序设计语言PDL：PDL也称为伪码
4. 设计规约（概要设计规约+详细设计规约）
   完整准确的描述满足需求规约所要求的所有功能模块，以及伴随功能模块而出现的非功能机制。
   （1）概要设计规约：指明高层软件体系结构
   系统环境
   软件模块的结构
   模块描述
   文件结构和全局数据文件的逻辑结构
   测试需求
   （2）详细设计规约：主要作为软件设计人员与程序员之间交流的媒体
   各处理过程的算法
   算法所涉及的全部数据结构的描述 （程序 = 算法 + 数据结构）

第四章：面向对象方法-UML

1、统一建模语言：UML是目前流行的建模语言
2、面向对象建模过程的步骤
（1）需求获取
a、建立用况建模和用况场景
（2）需求分析
a、建立活动图和状态图
b、类图（建立域模型）
c、顺序图（实现用况）
（3）编写需求规格说明书
（4）需求验证
第一节：UML术语表
1、对象（object）
属性+方法
对象与对象 通过消息 进行沟通
2、类（抽象的概念）
含义：具有相同属性、操作、关系和语义的一组对象的集合
具有超类和子类之分
组成：类名+属性+操作
UML属性的语法为： 可见性 属性名：类型 = 缺省值 {性质串}
可见性：public 公共的（+） protected 受保护的（#） private 私有的（-）、包内的（~）
4、类的操作（功能）
可见性 操作名（参数表）：返回值类型
5、接口
含义：接口是操作的一个集合，其中每个操作描述了类、构件或子系统的一个服务
（1）采用具有分栏和关键字的矩形符号来表示
（2）两端采用小圆圈和半圆圈来表示
6、协作（交互）
交互各方、交互方式、交互内容
7、用况（功能）
对一组序列的描述，系统执行这些动作应产生对特定参与者有值得、可观察的结果
8、主动类（打头类）
至少具体一个进程或线程的类。能够启动系统的控制活动，并且其对象的行为通常与其他元素行为并发的
表示方法：两条竖线
9、构件

10、制品
系统中包含物理信息的，可代替的物理部件
11、节点
节点是在运行时存在的物理元素，通常表示一种具有记忆能力和处理能力的计算机资源
12、关联
a>反映了类和类之间的静态关系、关联在模型中，特别是在永久业务对象模型中是最基本的关系
b>链是对象之间具有特定语义关系的抽象
（1）关联名
（2）导航
（3）角色
（4）可见性
（5）多重性：定义了一个对象/类相联系的对象/类出现一次，该对象/类可能出现的最小和最大的数目
（6）限定符
13、聚合：一个类是另一个类的一部分

14、组合：是聚合的一种特殊形式

15、关联类

16、约束
17、泛化/继承
继承父类的所有的属性与服务
18、多态性（封装、泛化）
19、细化
空心三角形的虚线表示
20、依赖
虚线表示
21、包
模型元素的分组

第二节：UML的模型表达格式
图像化工具
图的类别：
一、结构图
1、对象结构的建模-类图和对象图
2、应用结构建模-包图、构件图、部署图、组合结构图
二、行为图
1、对象交互建模-顺序图、协作图（通信图、交互综述图、定时图）、状态图
2、对象行为建模-用况图、活动图

1、类图
系统的静态结构信息
a、系统中有哪些需要关心的类
b、类的描述组成
c、类和类的联系

2、用况图（需求分析中用）

3、状态图（行为规则处于不同的状态）

4、顺序图（对象之间传递消息的时间顺序）

第五章：面向对象方法-RUP（10~15%）

复习建议：RUP(统一软件开发过程）
1、迭代式开发
2、管理需求
3、体系结构
4、可视化建模
5、验证软件质量
6、控制软件变更
迭代与增量

（1）迭代是重复的部分
（2）增量是增加的部分

第一节：RUP的特点
RUP的特点：
RUP最重要的它有三大特点：1）软件开发是一个迭代过程，2）软件开发是由Use Case驱动的，3）软件开发是以架构设计（Architectural Design）为中心的。
阶段：
1、初始阶段（建立商业案例确定项目边界）
2、细化阶段（分析问题领域，分析风险）
3、构造阶段
4、交付阶段
第二节：核心工作流
1、商业建模
2、需求分析
3、分析和设计
4、实现（编程）
5、测试
6、部署
7、配置和变更管理
8、项目管理
9、环境

一、需求分获取-

二、需求分析（实体类，边界类、控制类）

第六章：软件测试（25%）

第一节：软件测试目标与软件测试过程模型
1、软件测试的对象
软件=程序+文档
测试对象：各个阶段产生的源程序和文档
2、软件测试的目的
暴露软件所包含的故障和缺陷
3、软件测试的定义
（1）测试是程序执行的过程，其目的在于发现错误
（2）一个好的测试实例在于发现至今未发现的错误
（3）一个成功的测试是发现了至今未发现的错误的测试
4、错误类型
（1）功能错误
（2）系统错误
（3）过程错误
（4）数据错误
（5）编程错误
5、软件测试过程模型
（1）测试设计
（2）测试执行
（3）测试结果比较
第二节：软件测试技术

测试法分为黑盒法和白盒法
1、黑盒
也称功能测试法（检查功能）
2、白盒
白盒法也称结构测试或逻辑覆盖法（软件内部逻辑结构的分析）
常见的几个覆盖标准有：
语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖
3、路径测试技术（白盒测试）☆
依据的程序执行逻辑结构
(1)控制流程图
基本元素：过程块、节点、判定
（2）测试策略

（3）路径选取与用例设计
（4）路径选取的一般原则

5、基于事务流的测试技术
（1）事务的含义
（2）事务流
6、等价类法
（1）无法穷尽的数据，划分空间进行等价取值
例如 ： 某个实数 X 在 a<X<B
则在【a+1,b-1】之间的实数构成了有效等价类。而【-∞，a】或者【b,+∞】这间的实数构成了两个无效的等价类
7、边值分析法
是一种根据I/O边界等价类上或紧靠边界的条件，

【例题】有一个学生选课系统:程序的输入条件为:每个学生可以选修1至3门课程，试用黑盒测试法完成测试。
(1)按等价类划分法，设计测试用例(要求列出设计过程);
(2)按边界值分析法，设计测试用例。
【解析】 ：
(1)等价类法
课程门数<1
课程门数>3
课程门数1~3
(2)边界值分析法
课程门数=1
课程门数=3
8、因果图法

第三节 软件测试的步骤
1、单元测试（模块测试）
采用白盒测试技术，确定模块的逻辑和功能是否正确
（1）模块接口
（2）局部数据结构
（3）重要的执行路径
（4）错误执行路径
驱动模块和承接模块
2、集成测试
采用黑盒测试，用来测试模块直接接口的正确性，也即模块之间的数据和控制传递、集成测试是与单元测试平行进行的
（1）自顶向下的集成测试：需要设计承接模块
（2）自底向上的集成测试：需要设计驱动模块
3、有效性测试
目的：发现软件实现的功能与SRS（需求规约）不一致的错误
方法：黑盒测试
4、系统测试

第七章：软件生存周期过程及管理（10%）

过程 - 活动 - 任务
开发逻辑是获取正确软件的关键
1、软件生存周期
2、基本过程
（1）获取过程
（2）供应过程
（3）开发过程
（4）运行过程
（5）维护过程
3、开发过程
开发者所从事的一系列活动和任务、将一组需求转换为一个软件产品或系统

4、过程实现
（1）选择合适的生存周期模型
（2）选择相应的标准、方法、工具和程序设计语言
（3）制定实施开发计划
（4）可以使用一些非交付的软件项
5、系统需求分析
（1）建立系统需求规格说明
（2）对系统需求进行评估
a、有关获取方面需要的可追踪性
b、有关获取需求的一致性
c、可测试性
d、xt体系结构设计的可行性
e、运行与维护的可行性

6、系统体系结构设计
7、软件需求分析
*

8、软件体系结构设计
9、支持过程
10、支持过程-配置管理过程
11、组织过程
12、组织过程-管理过程
13、ISO/IEC系统与软件工程-软件生存周期过程 12207-2008 ☆
2个过程类、7个过程组、43个过程
系统语境的过程和软件开发的过程
（1）协议过程组
（2）项目过程组
（3）技术过程组
（4）组织上项目使能过程组

（5）软件实现过程组
（6）软件支持过程组
（7）软件复用过程组

第二节、过程描叙
1、供应过程
供方（乙方）
需方（甲方）
a、发标
b、投标

2、软件实现过程
a、意图
b、活动和任务
c、结果
3、软件需求分析过程

4、软件体系结构设计过程
意图：为软件的实现和按需求进行验证提供设计方案
5、软件验证过程
意图：证明软件产品是否满足了所规约的需求
6、软件确认过程
意图：证实所期望使用的软件产品是否满足需求

第三节 应用说明
对标准的说明
1、系统和软件
a.软件是整个系统的组成部分
b.区分系统需求分析和软件需求分析
2、1588标准
3、组织层和项目层
4、过程之间的时序关系
5、过程分解
6、生存周期模型和阶段
7、剪裁

第四节 软件生存周期模型 ☆
含义：软件产品开发、运行、维护中的过程
作用：
1、瀑布模型

原理：
a.自上而下具有相互衔接的固定顺序
b;每一阶段的输入，即工作对象以及本阶段的工作成果，作为输出传送到下一阶段
贡献：
a.在决定系统怎么做之前存在一个需求阶段，它鼓励对系统做什么有一个规约
b.在系统构造之前有一个设计阶段，它鼓励规划系统结构
c.每一阶段都有评审，允许获取方和用户的参与
d.前一步作为下一步被认可的、文档化的基线
瀑布模型有以下缺点
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
2、增量模型

增量模型的优点
　　采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。这样即可先发布部分功能给客户，对客户起到镇静剂的作用。此外，增量能够有计划地管理技术风险。
增量模型的缺点
　　增量模型存在以下缺陷：
　　1）
由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
　　2）
在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
　　3）如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
3、演化模型

演化模型的优点
1）任何功能一经开发就能进入测试以便验证是否符合产品需求。
2）帮助导引出高质量的产品要求。如果没有可能在一开始就弄清楚所有的产品需求，它们可以分批取得。而对于已提出的产品需求，则可根据对现阶段原型的试用而作出修改。
3）风险管理可以在早期就获得项目进程数据，可据此对后续的开发循环作出比较切实的估算。提供机会去采取早期预防措施，增加项目成功的机率。
4）大大有助于早期建立产品开发的配置管理，产品构建（build ），自动化测试，缺陷跟踪，文档管理。均衡整个开发过程的负荷。
5）开发中的经验教训能反馈应用于本产品的下一个循环过程，大大提高质量与效率。
6）如果风险管理发现资金或时间已超出可承受的程度，则可以决定调整后续的开发，或在一个适当的时刻结束开发，但仍然有一个具有部分功能的，可工作的产品。
7）心理上，开发人员早日见到产品的雏型，是一种鼓舞。
8）使用户可以在新的一批功能开发测试后，立即参加验证，以便提供非常有价值的反馈。
9）可使销售工作有可能提前进行，因为可以在产品开发的中后期取得包含了主要功能的产品原型去向客户作展示和试用。
演化模型的缺点
1）如果所有的产品需求在一开始并不完全弄清楚的话，会给总体设计带来困难及削弱产品设计的完整性，并因而影响产品性能的优化及产品的可维护性。
2）如果缺乏严格的过程管理的话，这个生命周期模型很可能退化为一种原始的无计划的“试－错－改”模式。
3）心理上，可能产生一种影响尽最大努力的想法，认为虽然不能完成全部功能，但还是造出了一个有部分功能的产品。
4）如果不加控制地让用户接触开发中尚未测试稳定的功能，可能对开发人员及用户都产生负面的影响。
4、螺旋模型
螺旋模型采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。使用它，项目经理在早期就能够为客户实证某些概念。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如下图所示:

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：

(1) 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。

(2) 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。

(3) 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。
　螺旋模型的优缺点

1、螺旋模型的优势包括:

1)设计上的灵活性,可以在项目的各个阶段进行变更。

2)以小的分段来构建大型系统,使成本计算变得简单容易。

3)客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。

4)随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。

5)客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。在实践中，螺旋法技术和流程变得更为简单。迭代方法体系更倾向于按照开发/设计人员的方式工作，而不是项目经理的方式。螺旋模型中存在众多变量，并且在将来会有更大幅度的增长，该方法体系正良好运作着。下表是螺旋法能够解决的各种问题：

经常遇到的问题螺旋模型的解决方案

用户需求不够充分允许并鼓励用户反馈信息

沟通不明在项目早期就消除严重的曲解

刚性的体系(Overwhelming architectures)开发首先关注重要的业务和问题

主观臆断通过测试和质量保证,作出客观的评估

潜在的不一致在项目早期就发现不一致问题

糟糕的测试和质量保证从第一次迭代就开始测试

采用瀑布法开发在早期就找出并关注风险

2、但是，螺旋模型并不是比其他模型拥有绝对优越，事实上，这种模型也有其自身的如下缺点。

1)采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。

2)过多的迭代次数会增加开发成本，延迟提交时间。
　　
5、喷泉模型

a.喷泉模型的优点：
　　喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
b.喷泉模型的缺点：
　由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
c.喷泉模型适用场所：
　适应于面向对象的软件开发过程。
第五节 过程规划与管理

第八章：集成化能力成熟模型CMMI(5%)

10分钟搞懂CMMI
软件过程的改善问题

1、定义：CMMI 软件能力成熟度模型集成
2、CMMI主要关注点

3、CMMI 核心理念 ：过程管理

4、CMMI的构成
（1）软件能力成熟模型（SW-CMM）
（2）软件工程能力模型（SECM）
（3）集成产品开发能力成熟度模型（IPD-CMM）

第二节 CMMI的模型部件

3、过程域