IT读书笔记软件工程软考

笔记.第2章.软件工程基础知识.信息系统项目管理师.考试辅导教程

2017-01-04  本文已影响186人  小镭Ra

本书笔记目录链接

上篇

第2章 软件工程基础知识

“软件工程”概念在1968年的“软件危机”会议中提出。

IEEE 在1983年对软件工程的定义：软件工程是开发、运行、维护和修复软件的系统方法。

电气和电子工程师协会，IEEE，Institute of Electrical and Electronics Engineers

软件工程专家 Boehm 在1983年提出了软件工程的7条基本原理：

  1. 用分阶段的生命周期计划严格管理
  2. 坚持进行阶段评审
  3. 实行严格的产品控制
  4. 采用现代程序设计技术
  5. 结果应能清楚地审查
  6. 开发小组的人员应该少而精
  7. 承认不断改进软件工程实践的必要性

软件工程方法学包含3个要素：方法、工具和过程。

本章要点：

2.1 软件需求分析与定义

根据 Standish Group 对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，有26%的项目获得成功。而在这些高达74%的不成功项目中，有60%的失败是源于需求问题。

2.1.1 软件需求与需求过程

1. 什么是软件需求

软件需求就是系统必须完成的事，以及必须具备的品质。包括：

其他相关概念：

2. 需求工程

需求工程是一个包括创建和维护系统需求文档所必需的一切活动的过程，通常包括：

2.1.2 需求调查与问题定义

想做好需求调查必须清楚了解的3个问题：

1. 要捕获的信息

从宏观的角度看，要捕获的信息包括三类：

2. 信息的来源

对涉众（风险承担人、项目干系人）进行分类，从每一类涉众中找1~2名代表。

3. 需求捕获技术

常用技术：

4. 需求捕获的策略

需求过程4阶段（需求捕获、需求分析、需求规格 、需求验证）采用迭代的方式进行。

2.1.3 可行性研究

1. 可行性研究工作的基础

问题定义的关键是清晰地界定出问题内容、性质，以及系统的目标、规模等内容，并形成完整的书面报告。

2. 可行性研究工作的任务
3. 可行性研究工作的步骤

  1. 核实问题定义与目标
    具体来说，就是仔细阅读问题定义的相关材料，对该问题所涉及的领域知识进行学习、考证，然后通过走访相关人员进行验证与核实。
    这一步骤的关键目标是：使问题定义更加清晰、明确、没有歧义性，并且对系统的目标、规模，以及相关约束与限制条件做出更加细致的定义，确保可行性研究小组的所有成员达成共识。

  2. 研究分析现有系统
    “现有系统” 不仅包括旧的软件系统，还包括旧的非计算机系统。

  3. 为新系统建模
    建模的目的是为了获得一个对新系统的框架认识、概念性认识。
    常见技术：

  1. 客户复核

  2. 提出并评价解决方案
    应该尽量列举出各种可行的解决方案，并且对这些解决方案的优点、缺点做一个综合性的评价，以便下一步决策。

  3. 确定最终推荐的解决方案
    成本效益分析：

常见概念：

  1. 草拟开发计划
  2. 以书面的形式提交《可行性分析报告》并进行审查。

2.1.4 需求分析

定义：所谓分析就是通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明。

1. 需求分析的工作任务

Karl E.Wiegers 在《软件需求》中指出需求分析工作通常包括7个方面。

  1. 绘制系统上下文范围关系图
    用于定义系统与系统外部实体间的界限和接口的简单模型，它可以为需求确定一个范围。DFD 的0层图。

  2. 创建用户接口原型

  3. 分析需求的可行性

  4. 确定需求的优先级
    需求的优先级可以采用满意度/非满意度指标进行说明（取值均为1 ~ 5）。

  5. 为需求建立模型

  6. 创建数据字典

  7. 使用质量功能配置（QFD）

质量功能配置，QFD，Quality Function Deployment

2. 需求建模

Alan Davis 主张需要把用文字表示的需求和用图形表示的需求结合起来。用图形表示的需求，就是需求建模，获得分析模型。分析模型有助于检测需求的不一致性、模糊性、错误及遗漏。

2.1.5 流行的需求分析方法论

按照分解方式不同分类：

结构化分析方法，SA，Structured Analysis

过渡性的方法论，并未真正流行过。以 Checkland 方法为代表。

面向对象分析方法，OOA，Object Oriented Analysis

面向问题域的分析，PDOA，Problem Domain Oriented Analysis
尚处在研究阶段，并未广泛应用。
小镭：今天情况怎样？

1. 结构化分析

把系统看作一个过程的集合体。

工具：

结构化系统分析方法从总体上看是一种强烈依赖数据流图的自顶向下的建模方法。

如何进行结构化分析：

  1. 研究“物质环境”
    画出当前系统的数据流图。

  2. 建立系统逻辑模型
    在第一步的基础上，画出相对真实系统的等价逻辑数据流图。

  3. 划清人机界限

2. 数据流图

数据流图，DFD，Data Flow Diagram

基本元素：

对过程0的分解，称之为 DFD 0层图。

3. 细化记录 DFD 部件
  1. 结构化语言
  2. 决策表和决策树
  3. 数据字典
    每条目包含信息：
    • 名称
    • 何处使用/如何使用
    • 内容描述
    • 补充信息

数据字典实例：
客户基本信息=客户编号+客户名称+身份证号码+手机
客户编号={0···9}8
客户名称={字}4
身份证号码=[{0···9}15|{0···9}18]
手机=[{0···9}11|{0···9}12]

4. 实体-关系图

实体-关系图，E-R 图，Entity Relationship Diagram

实体是一个概念，用来抽象地表示一组相类似的事物的所有实例。

结构化分析的不足：

小镭：或许结构化分析过于抽象，这加大了分析阶段的复杂性，使问题的描述、阅读、沟通变得困难。

5. 面向问题域的分析

面向问题域的分析更多地强调描述，而较少强调建模。

分析过程：

2.2 软件设计

2.2.1 软件设计基本原则

1. 信息隐蔽

Parnas 指出：每个模块的实现细节对于其他模块来说是隐蔽的，模块中所包含的信息（包括数据和过程）不允许其他不需要这些信息的模块使用。这提高了软件的可维护性和可靠性。

2. 模块独立性

指软件系统中每个模块只涉及软件要求的具体子功能，而和软件系统中其他的模块接口是简单的。

度量模块独立性的两个准则：

高内聚，低耦合的模块独立性较强。

高 《--- 内聚性 --- 低

功能内聚 | 信息内聚 | 通信内聚 | 过程内聚 | 时间内聚 | 逻辑内聚 | 巧合内聚

强 《--- 模块独立性 --- 弱

功能单一 ------ 功能分散

各类聚合性：

低 --- 耦合性 ---》 高

非直接耦合 | 数据耦合 | 标记耦合 | 控制耦合 | 外部耦合 | 公共耦合 | 内容耦合

强 《--- 模块独立性 --- 弱

各类耦合性：

2.2.2 结构化设计方法

实施过程：

  1. 总结出系统应有的功能，对一个功能，从功能完成的过程考虑，将各个过程列出，标志出过程转向和传递的数据。
  2. 细化数据流。
  3. 分析过程之间的耦合关系，合理地划分模块，提高内聚性。
1. 系统结构图中的模块

在系统结构图中，不能再分解的底层模块称为原子模块。

完全因子分解的系统：系统的全部实际加工都由原子模块来完成，而其他所有非原子模块仅仅执行控制协调功能。这是理想中的系统。

结构图中的常见模块：

区别系统结构图与程序流程图

结构图，SC，Structured Charts

结构图反映模块间的隶属关系（调用与层次），着眼软件系统的总体结构，并不涉及模块内部的细节。

流程图反映的是程序的执行顺序及其依赖条件，表达执行程序的具体算法。

有太多项目失败就是因为它们没有明确的目标就开始了。

2. 系统结构图中的主要成分
  1. 模块
  2. 模块间的调用关系
  3. 模块间的通信
  4. 辅助控制符号
3. 常用的系统结构图

  1. 变换型系统结构图
    从外部取得数据，处理后再传回外部。

  2. 事务型系统结构图
    数据被转换成一个事务项并加以计算，然后根据结果选择数据流。

  3. 混合型系统结构图
    现实中多为此类。

2.2.3 用户界面设计

一个好的用户界面应具有的特点：

  1. 可使用性
  2. 灵活性
  3. 复杂性和可靠性

2.2.4 设计评审

评审采用评审会议的形式进行。

角色：

  • 设计负责人

    • 承担项目的全部设计管理任务
    • 对设计质量、进度及各项设计间的组织协调等全面负责
    • 对各单项工程之间的衔接、协调和总体方案质量负主要责任
    • 负责编写总说明，汇编总概算。

  • 高级管理人员

    • 定主审员
    • 审批评审记录

  • 主审员

    • 在评审会前提出项目的书面评审意见
    • 确定评审组、确定评审结果并填写评审记录

  • 评审组

    • 专业评审组评委表决通过项目初评结论并报综合评审会议，通过设计报告。

2.3 软件测试

应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。

软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。各阶段所得到的文档以及源程序，都应成为软件测试的对象。

2.3.1 软件测试

测试用例是为特定目标开发的测试输入、执行条件和预期结果的集合。

1. 黑盒测试

又称为功能测试或数据驱动测试。把测试对象看做一个空盒子，不考虑程序的内部逻辑结构和内部特性，依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。

主要检查内容：

测试用例设计方法：

  1. 等价类划分
    步骤：
    1. 划分等价类
    2. 选取测试用例

等价类是指某个输入域的子集合。在该子集合中，各个输入数据对揭露程序中的错误是等效的。

有效等价类与无效等价类。

  1. 边界值分析
    经验表明，大量的错误是发生在输入或输出范围的边界上。

  2. 错误推测法
    靠经验和直觉推测程序中可能存在的各种错误，有针对性地编写测试用例。

  3. 因果图
    此方法最终生成的就是判定表，适于检查程序输入条件的各种组合情况。

    步骤：

    1. 分析原因（输入）与结果（输出）并标示编号因果组
    2. 分析原因与结果之间的关系，画出因果图
    3. 在因果图上标明不可能的情况并指出约束或限制条件
    4. 把因果图转换成判定表
    5. 利用判定表的每一列设计测试用例
2. 白盒测试

又称为结构测试或逻辑驱动测试。白盒测试把测试对象看做一个透明的盒子,它允许测试人员利用程序内部的逻辑结构和有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。

主要检查内容：

3. 逻辑覆盖

此技术属于白盒测试，是以程序内部的逻辑结构为基础的设计用例的技术。

包括：

2.3.2 软件测试策略

1. 单元测试

也称为模块测试，是针对每个模块进行的测试。

驱动模块是指在单元测试和集成测试中，协调输入和输出的测试程序。

桩模块指模拟被调用单元的程序。

单元测试可测试内容：

  1. 模块接口
  2. 局域数据结构
    数据类型，变量，初始值与默认值。
  3. 独立路径
    路径错误。
  4. 错误处理测试
  5. 边界条件测试
2. 集成测试

把模块组装为系统的方式有两种：

对关键模块及早进行测试。

3. 确认测试

验证软件的功能、性能及其他特性是否与用户的要求一致。

主要步骤：

  1. 有效性测试
  2. 软件配置复査
  3. 验收测试

应交付文档：

4. 系统测试

在实际运行环境下进行一系列的测试。

5. α 测试和 β 测试

α 测试

α 测试是由一个用户在开发环境或模拟实际操作环境下进行的测试。

α 测试目的：评价软件产品的 FLURPS（功能、局域化、可使用性、可靠性、性能、支持）

α 测试注重产品的界面和特色。

β 测试

β 测试是由多个用户在实际使用环境下进行的测试。

β 测试处在整个测试的最后阶段。产品的所有手册文本也应该在此阶段完全定稿。

2.3.3 软件测试类型

1. 功能测试
2. 可靠性测试

主要评价指标:

平均故障间隔时间，MTBF，Mean Time Between Failure

平均故障修复时间，MTTR，Mean Time To Repair

3. 强度测试
4. 性能测试
5. 恢复测试
6. 启动/停止测试
7. 配置测试
8. 安全性测试
9. 可使用性测试
10. 安装测试
11. 过程测试

检查由人工完成的、为了配合计算机的工作，就是过程测试。

12. 容量测试
13. 文档测试
14. 兼容性测试

2.3.4 面向对象的软件测试

面向对象的开发阶段：

  1. 面向对象分析，OOA，Object Oriented Analysis
  2. 面向对象设计，OOD，Object Oriented Design
  3. 面向对象编程，OOP，Object Oriented Programming

面向对象测试：

1. OOA Test

OOA 直接映射问题空间，全面地将问题空间中实现功能的现实抽象化。将问题空间中的实例抽象为对象，用对象的结构反映问题空间的复杂实例和复杂关系，用属性和服务表示实例的特性和行为。行为相对稳定，结构则相对不稳定。

2. OOD Test

OOD 以 OOA 为基础归纳类，并建立类结构或进一步构造成类库，实现分析结果对问题空间的抽象。

因 OOD 是 OOA 的进一步细化和更高层的抽象。所以，OOD 与 OOA 的界限通常难以区分。

3. OOP Test

考虑：

  1. 数据成员是否满足数据封装的要求
  2. 类是否实现了要求的功能
4. 面向对象的单元测试

考虑：

  1. 继承的成员函数是否都不需要测试
  2. 对父类的测试是否能照搬到子类
5. 面向对象的集成测试

基于单元测试对成员函数行为正确性的保证，集成测试只关注系统的结构和内部的相互作用。

静态测试：检测程序结构是否符合设计要求。
动态测试：优化测试用例，减少测试工作量，使测试达到一定的覆盖标准。

6. 面向对象的系统测试

2.4 软件维护

2.4.1 软件的可维护性

1. 软件具有可维护性

决定软件可维护性的三个因素：

  1. 可理解性
  2. 可测试性
  3. 可修改性
2. 采用软件工程提高软件的可维护性

软件系统的文档可分为用户文档和系统文档两大类。

用户文档主要是描述软件功能和使用方法，至少包括：

系统文档关心实现细节，描述系统需求、设计、实现和测试等各个方面。

3. 注重可维护性的开发过程

在开发过程中提高软件的可维护性：

4. 可维护性的度量

1. 外部度量

MTTR 指标度量。

可维护指标 M = 1 / (1 + MTTR)

2. 内部度量

软件复杂性相关因素：

建立经验模型的步骤：

  1. 确定影响可维护性的若干主要因素，并为其制订尺度
  2. 用大量的现有案例，计算出一个包含影响因素及其权值的多项式模型
  3. 利用这个经验模型分析新的软件，再根据实际的维护活动的感受进行校准
  4. 重复校准过程

2.4.2 软件维护的分类

从性质上分为：

注：括号中为 Lientz 和 Swanson 在1980年的调查结果。

2.4.3 软件维护的工作量

维护活动分类：

M = P + K^(c-d)

M - 维护总工作量
P - 生产类活动工作量
K - 经验常数
c - 软件复杂程度
d - 维护人员对软件的熟悉程度

影响维护工作的其他因素：

按照对真实世界的依赖程度，软件系统可以分为：抽象系统、近似系统和模拟系统。

2.4.4 软件维护作业的实施和管理

1. 建立维护组织
2. 提出维护需求
3. 实施维护作业

每次维护活动的实施都要经历如下的步骤：

4. 记录维护要素
5. 评价维护活动

2.4.5 软件再生工程

软件的再生工程通常包括以下六类活动：

  1. 筛选
  2. 文档重构
  3. 逆向工程
  4. 代码重构
  5. 数据重构
  6. 重新开发

2.5 软件开发环境

2.5.1 软件开发环境概述

软件开发环境，SDE，Software Development Environment

集成式项目支援环境，IPSE，Integrated Project Support Environment

集成型开发环境通常可由工具集和环境集成机制两部分组成。

环境集成机制：

数据集成机制提供统一的数据模式和数据接口规范，需要相互协作的工具通过这种统一的模式与规范交换数据。

控制集成机制支持各工具或各开发活动之间的通信、切换、调度和协同工作，并支持软件开发过程的描述、执行和转接。

2.5.2 软件开发环境的功能与分类

按软件开发模型及开发方法分类：

按功能及结构特点分类：

按应用范围分类：

按开发阶段分类：

2.5.3 软件开发环境的结构

开发环境组成：

  1. 工具集
  2. 集成机制
  3. 环境信息库

环境信息库是软件开发环境的核心，用以储存与系统开发有关的信息并支持信息的交流与共享。

  1. 过程控制和消息服务器
  2. 环境用户界面

开发环境的结构可分为四层：

  1. 宿主层

包括基本宿主硬件和基本宿主软件。

  1. 核心层

包括工具组、环境数据库和会话系统。

  1. 基本层

包括至少一组工具，如编译工具、调试工具等。

  1. 应用层

以基本层为基础补充某些工具，以适应应用软件的要求。

2.5.4 软件开发环境的发展

集成计算机辅助软件设计，ICASE，Integrated Computer-Aided Software Engineering

ICASE 信息中心库功能：

  1. 数据完整性
  2. 信息共享
  3. 数据-工具集成
  4. 数据-数据集成
  5. 方法学实施
  6. 文档标准化

ICASE 的最终目标是实现应用软件的全自动开发，即开发人员只要写好软件的需求规格说明书，软件开发环境就自动完成从需求分析开始的所有的软件开发工作，自动生成供用户直接使用的软件及有关文档。

上一篇下一篇

猜你喜欢

热点阅读