第一章 绪论
1.1 软件工程概念的提出与发展
软件工程概念的提出以解决出现的“软件危机”。
软件工程的定义:软件工程是应用计算机科学理论和技术以及工程管理原则和方法,按预算和进度实现满足用户需求的软件产品的工程,或以此为研究对象的学科。
软件工程的发展分为两个时期:
20世纪60年代末到80年代初,围绕软件项目开展了有关开发模型、开发方法和支持工具的研究。(瀑布模型、过程式语言、结构化方法、调试工具、测试工具)
20世纪80年代以来,开展大量软件工程实践,围绕对软件工程过程的支持,开展了一系列有关软件的生产技术,特别是软件复用技术和软件生产管理的研究和实践。(《软件生存周期过程》)
1.2 软件开发的本质
计算机软件是计算机系统中程序及其文档。
软件开发的目标:将问题域中的概念映射为运行平台上的概念
软件开发的本质:实现问题空间的概念与处理逻辑到解空间的概念与处理逻辑之间的映射。
实现这一映射的基本途径,即系统建模。
系统建模:运用所掌握的知识,通过抽象,给出系统的一个结构——系统模型。
系统模型分为两大类:概念模型(描述了系统是什么),软件模型(描述了实现概念模型的软件解决方案)
软件模型又可以分为设计模型、实现模型、部署模型
第二章 软件需求与软件需求规约
2.1 需求与需求的获取
2.1.1 需求的定义
需求是有关一个“要予构造”的陈述,描述了待开发产品/系统功能上的能力、性能参数或其他性质。
5个基本性质:
-
必要的
-
无歧义的
-
可测的
-
可跟踪的
-
可测量的
2.1.2 需求的分类
功能需求:
非功能需求:
1.性能需求
2.外部接口需求
- 用户接口
- 硬件接口
- 软件接口
- 通信接口
- 内存约束
- 运行
- 地点需求
3.设计约束
- 法规政策
- 硬件限制
- 与其它应用的接口
- 并发操作
- 审计能力
- 控制功能
- 高级语言要求
- 握手协议
- 应用的关键程度
- 安全和保密
4.质量属性需求
- 可靠性
- 存活性
- 可维护性
- 用户友好性
2.1.3 需求发现的技术
1.自悟:需求分析人员把自己作为系统的最终用户
存在风险:无法验证发现的需求是否满足用户的需求,无法验证发现的需求是不是正确的。
2.交谈:需求人员通过提出问题/用户回答,直接询问客户需要一个怎样的系统
存在风险:交谈期间所获得的需求可能不断增长,导致超出项目成本和进度的限制。
3.观察:观察用户执行其现行的任务和过程
存在风险:客户可能抵触这一观察,打扰了他们的正常业务。
4.小组会:客户与开发人员的联合会议
存在风险:会议组织不到位。
5.提炼:复审技术文档,提取相关信息
存在风险:与自悟一致。
2.2 需求规约
2.2.1 需求规约的定义
需求规约是一个软件产品/系统所有陈述的正式文档,表达了一个软件产品/系统的概念模型。
4个基本性质:
- 重要性和稳定性程度
- 可修改的
- 完整的
- 一致的
2.2.2 需求规约的格式
2.2.3 需求规约(规格说明书)的表达
- 非形式化的需求规约:以一种自然语言来表达需求规约的
主要问题是容易产生歧义、矛盾和不可测的问题。
- 半形式化的需求规约:以半形式化符号体系来表达需求规约
- 形式化的需求规约:以一种基于数学概念的符号化体系来表达需求规约
2.2.4 需求规约的作用
- 需求规约是软件开发组织和用户之间一份事实上的技术合同,是产品功能及其环境的体系。
- 对于系统的其余大多数工作,需求规约是一个管理控制点。
- 对于产品/系统的设计,需求规约是一个正式的、受控的起始点。
- 需求规约是创建产品验收测试计划和用户指南的基础。
第三章 结构化方法
结构化方法作为一种“思想“工具,可用于定义需求,建立待系统的功能模型;可用于定义满足需求的结构,给出一种特定的软件解决方案。
3.1 结构化需求分析
在进行软件系统/产品的需求工作中,面临三大挑战:
(1)问题空间理解
(2)人与人之间的通信
(3)需求的变化性
为了应对以上三大挑战,一种好的需求技术应具有以下基本特征:
(1)提供方便通信的机制
(2)鼓励需求分析人员使用问题空间的术语思考问题,编写文档
(3)提供定义系统边界的方法
(4)提供支持抽象的多种机制
(5)为需求分析人员提供多种可供选择的方案
(6)提供特定的技术,适应需求的变化
软件开发方法:结构化方法、面向数据结构的软件开发方法以及面向对象方法
结构化方法(系统必须做什么)是一种系统化的软件开发方法,包括结构化分析方法、结构化设计方法、结构化程序设计方法
实现结构化分析方法需用到的基本术语、表达系统模型的工具、建模过程
基本术语:数据流、加工、数据存储、数据源和数据潭;
表达系统功能模型的工具:数据流图(DFD图) 需求分析的首要任务是建立系统功能模型
建模过程:
(1)建立系统的功能模型——使用工具为数据流图DFD
首先,建立系统环境图(顶层数据流图),确定系统边界;继之,自顶向下,逐步求精,建立系统的层次结构图
(2)建立数据字典——使用工具为结构符:定义=、顺序+、选择|、循环{ } 、子界m..n
- 数据流条目:给出DFD图中所有数据流的结构定义
- 数据存储:给出DFD图中所有数据存储的结构定义
- 数据项:给出DFD图中所有数据项的类型定义
(3)描述加工——使用工具为判定表、判定树
集中描述一个加工“做什么”,即加工逻辑,也包括其他一些与加工有关的信息,如执行条件、执行频率、出错处理等。
- 结构化自然语言:如果一个输入数据和输出数据之间的逻辑关系比较简单,可以使用结构化自然语言予以描述。
- 判定表:如果一个输入数据和输出数据之间的逻辑关系比较复杂,可以采用的一种工具。
- 判定树
应用中注意的问题:
(1)模型平衡问题
- 系统DFD中每个数据流和数据存储都要在数据字典中予以定义,并且数据名一致。
- 系统DFD中最底层的加工必须在小说明中予以描述,并且与加工名一致。
- 父图中某加工的输入/输出(数据流)和分解这个加工的子图的输入/输出(数据流)保持一致。
- 在加工小说明中,所使用的数据流必须是在数据字典中定义的。
(2)信息复杂性控制问题
- 上层数据流可以打包
- 下层模块的个数控制在7±2以内
- 每个加工的数据流不能太多
- 分析数据内容,确定是否所有的输入信息都用于产生输出信息
3.1.5 需求验证
- 验证每一个需求满足5个基本性质:必要的、无歧义的、可测的、可跟踪的、可测量的
- 验证需求规格说明书满足4个基本性质:重要性和稳定性程度、可修改性、完整性、一致性