软件工程导论

ObjectKaz Lv4

概述

软件

  1. 硬件:计算机系统中由电子、机械或光电元件等组成的各种物理装置的总称。
  2. 软件:计算机系统中 程序数据和 相关文档 的总称。
  3. 程序:能完成确定任务,用计算机语言描述的,并能在计算机系统上执行的语句序列。
  4. 数据:描述软件的处理对象。
  5. 文档:与程序开发、维护和使用有关的图文资料。

软件的发展(了解)

  1. 程序设计:20 世纪 50 年代初期-60 年代中期,人们不重视程序的作用
  2. 程序系统:20 世纪 60 年代中期-70 年代末期,出现了软件危机
  3. 软件工程:20 世纪 70 年代末期,出现了软件工程
  4. 第四阶段:社会信息化、软件产业化

软件危机

表现

  1. 软件产品不符合用户需求
  2. 软件开发生产效率远远低于硬件生产效率和计算机应用的增长速度,人们无法利用硬件提供的巨大潜力
  3. 软件产品的质量差
  4. 成本和进度估计不准确
  5. 软件难以维护
  6. 软件文档不完整不合格
  7. 软件价格昂贵

原因

  1. 软件规模越来越大,结构越来越复杂
  2. 软件开发管理困难
  3. 软件开发费用不断增加
  4. 软件开发技术落后
  5. 生产方式落后
  6. 开发工具落后

软件工程

  1. 软件工程是一门综合性交叉学科,它涉及计算机科学、工程科学、管理科学、数学等领域。
  2. 使用工程科学的观点来估算费用、制定进度、计划和方案
  3. 使用管理科学中的方法和原理进行软件生产的管理
  4. 使用数学的方法建立软件开发中的各种模型和各种算法

软件周期

软件开发的八个阶段

  1. 问题定义
  2. 可行性研究
  3. 需求分析
  4. 总体设计
  5. 详细设计
  6. 编码和单元测试
  7. 综合测试
  8. 软件维护

其中 1-3 为软件定义时期,4-7 为软件开发时期,8 为软件维护时期

瀑布模型

  1. 将上面的八个阶段按照顺序依次进行,由前置后,相互衔接,向瀑布一样,逐级下落。
  2. 缺点:(不可重复性)对软件开发要求过于苛刻、不符合人们认识问题的一般规律(逐步深化)

软件过程

概念

  1. 定义:软件生存周期中一系列相关活动按照次序的演进变化的进程
  2. 软件过程规定了获取、供应、开发、操作和维护软件时,要实施的过程、活动和任务。
  3. 目的:提供一个公共的框架,以便用相同的语言进行交流。

八个过程

  1. 获取过程:需方获得一个系统或软件产品的一系列相关活动。
  2. 供应过程:供方按照合同向需方提供系统、软件产品或服务的活动。
  3. 管理过程:管理人员对自己过程中的人物和活动所实施的管理活动。
  4. 开发过程:开发者根据合同开发服务的一系列活动。
  5. 运作过程:用户和在用户的业务环境中为使软件产品投入运行所进行的一系列活动。
  6. 维护过程:软件产品投入运行之后,为了保证软件产品的性能
  7. 支持过程:文档过程、配置管理过程、质量保证过程等
  8. 裁剪过程:根据需要配置软件过程

可行性分析

介绍

  1. 在项目正式开始之前,先投入一定的精力,通过一套准则,从经济、技术、社会等方面对项目的必要性、可能性、合理性以及面临的重大风险进行评价,得出是否可行的结论。

三大可行性

  1. 经济可行性:对软件开发所需的花费和项目开发成功之后所能带来的经济效益进行分析。

  2. 技术可行性:在特定条件下,技术资源的可用性和这些技术资源用于解决软件问题的可能性和现实性。

    • 全面考虑技术问题
    • 尽可能采用成熟技术
    • 着眼于具体的开发环境和开发人员
  3. 社会可行性:从政策、法律、制度、管理等社会因素论证开发的可能性和现实性。

分析工具

  • 系统流程图
  • 成本-效益分析

系统流程图

系统流程图是描绘物理系统的传统工具,使用图形符号描绘各个元素。

基本符号:

拓展符号:

成本-效益分析

  1. 从经济效益角度评价一个项目是否可行
  2. 有形效益:货币的时间价值(利率)、投资回收周期(什么时候回本)、纯收入
  3. 无形效益:性质、心理等方面,难以量化衡量

开发计划(了解)

  1. 总述
  2. 开发的总体问题
  3. 工作任务
  4. 资源需求:人力资源(技术人员、管理人员、工作人员)、环境资源

需求分析

概念

  1. 定义:解决现实问题中,软件应该有的功能和特性,是软件开发和验收的基础和依据
  2. 分类:功能需求、性能需求、其他需求
  3. 功能需求:软件提供的功能和服务
  4. 性能需求:保证软件功能的实现和正确运行,对软件所规定的效率、可靠性、安全性等规约

任务

  1. 问题识别
  2. 分析和综合,导出逻辑模型
  3. 编写文档:需求规格说明书、用户使用手册、测试计划、开发计划

过程

需求获取

  1. 概念:开发人员从功能、性能、界面、运行环境等多方面识别目标系统要解决什么问题的,要满足哪些限制条件的过程。
  2. 常用方法:收集资料、调查会、访谈、书面调查、业务实践、电邮等

需求分析建模

  1. 获得当前系统的物理模型
  2. 抽象出当前系统的逻辑模型
  3. 建立目标系统的逻辑模型
  4. 转换为目标系统的物理模型

需求规格说明书

  1. 描述需求的文档
  2. 清晰性、无二义性和准确性

需求评审

  1. 对功能的正确性、完整性和清晰性,以及其他需求进行评审

分析工具

  • 实体联系图
  • 数据流图
  • 状态转换图

数据流图 DFD

描述数据流和数据转换的图形工具

  • 实体:矩形方框
  • 加工:用圆圈表示
  • 数据流:带数据流名称的箭头 +数据存储:双实线

状态转换图

圆圈表示状态,里面写状态,箭头写状态间的转移

数据字典(了解)

  1. 概念:描述数据流图中的数据存储、加工和流。

  2. 常用符号

符号说明
A=B定义为
A+B表示与关系
X=[A | B]表示或关系
X=(A)表示可选
X={A}表示重复 0-多次
X=a{A}b表示重复 a-b 次
X="A"表示基本数据元素,不可再分
A..B连接符
*A*注释

总体设计

软件设计过程

  1. 管理角度:
    • 总体设计:将软件需求转化为数据结构和软件的系统结构
    • 详细设计:对软件结构进行细化,得到软件详细的数据结构和算法
  2. 技术体系:
    • 数据设计:将实体关系图、数据字典转换成数据结构的定义
    • 体系结构设计:将系统划分为模块,及其关系
    • 接口设计:根据数据流图定义软件内部或与其他系统之间的交互机制
    • 过程设计:把结构转换成软件的过程性描述
技术体系分析工具
数据设计数据字典、实体关系图
体系结构设计数据流图
接口设计数据流图
过程设计状态转换图

任务

将数据流图转换成软件结构和数据结构。具体任务:

  • 定义设计规范
  • 体系结构设计
  • 处理方式设计
  • 数据结构设计
  • 可靠性设计
  • 编写概要设计说明书
  • 概要设计评审

模块化

  1. 分类:逻辑模块、物理模块
  2. 具备的要素:输入和输出、处理功能、内部数据、程序代码
  3. 设计标准:可分解性、可组装性、可理解性、连续性(小改动不必大变化)
  4. 独立性:每个模块只设计软件要求的具体子功能,而和软件系统中其他模块的接口是易于实现的。
    • 度量准则:耦合、内聚
  5. 耦合:模块间相互联系的紧密程度的度量
  6. 内聚:模块内各元素彼此结合的紧密程度
  7. 高内聚,低耦合

模块耦合

参考:https://zhuanlan.zhihu.com/p/22281389

类型(由低到高)说明
非直接耦合没有直接联系
数据耦合
尽量
两个模块只传递数据信息(非控制信息、复杂的数据结构)
标记耦合两个模块传递记录信息(引用类型,通常是复杂的数据结构)
控制耦合
少用
两个模块传递控制信息
外部耦合两个模块使用全局的简单变量
公共耦合
限制
两个模块使用一个公共数据区(复杂数据结构)
松散公共耦合:一个发送、一个接收
紧密公共耦合:既发送又接收
内容耦合
完全不用
一个模块之间访问另一个模块的内部数据
一个模块不正常跳转到另一个模块内部
两个模块有一部分代码重叠
一个模块有多个入口模块

耦合速记:

模块内聚

参考:https://blog.csdn.net/xyisv/article/details/80644985

类型(由高到低)说明
功能内聚模块所有成分只完成一个功能
信息内聚同一数据结构上完成多个功能
通信内聚模块包含的任务具有相同的输入或输出
过程内聚模块包含的任务按照次序执行
时间内聚模块包含的任务在同一时间执行(如初始化、销毁)
逻辑内聚把相关的功能组合在一起,根据参数决定执行的功能
偶然内聚模块内部各元素之间没有联系

内聚速记:

设计工具

  • 结构图
  • HIPO 图

结构图

  1. 方框:模块名称
  2. 直线:调用关系
  3. 信息传递:带箭头尾部用空心圆传数据,实心圆传控制信息
  4. 方框下面的菱形:选择调用
  5. 方框下面的圆弧:循环调用

面向数据流的设计方法

数据流图的类型

  1. 变换型(绝大多数):输入、变换中心、输出

    • 画法:输入、变换、输出至少三个模块;由变换中心往外扩散(结构的层级逐渐增加)
  2. 事务型:将输入流分离成多个加工路径,选择一条路径执行

    • 画法:左输入,右调度,调度下面分路径

设计过程

  1. 精化数据流图:检查修改错误等
  2. 确定类型
  3. 分解模块
  4. 对软件结构求精
  5. 描述模块功能、接口和全局数据结构
  6. 复查

详细设计

基本概念

任务

为每一个模块确定算法和内部的数据结构,并选择工具进行表达。

  1. 为每一个模块确定详细的算法设计
  2. 为模块内的数据结构进行设计
  3. 对数据结构进行物理设计
  4. 其他设计:代码设计、输入输出、人机对话设计
  5. 编写详细设计说明书

设计工具

  • 程序流程图
  • 盒(N-S)图
  • PAD 图
  • 判定表
  • 判定树

程序流程图

盒图

PAD 图

判定表和判定树(了解)

  1. 判定表

左上:条件
左下:操作
右:各种情况的条件和操作

  1. 判定树(同决策树)

Jackson 图

Jackson 图样式

顺序结构的数据由一个或多个数据元素组成,每个元素按确定次序出现一次。

选择结构的数据包含两个或多个数据元素,每次使用这个数据时按一定条件从这些数据元素中选择一个:

重复结构的数据,根据使用时的条件由一个数据元素出现零次或多次构成:

改进的 Jackson 图

改进的 Jackson 图:

Jackson 伪码

顺序结构:

1
2
3
4
5
A seq
B
C
D
A end

选择结构:

1
2
3
4
5
6
7
A select 条件1
B
A or 条件2
C
A or 条件3
D
A end

循环结构:

1
2
3
A iter while 条件
B
A end

Jackson 方法设计步骤

  1. 画出输入数据和输出数据的 Jackson 图

  2. 找出输入数据和输出数据的对应关系

  3. 对有对应关系的数据结构,在相应(层次不一样时用较低层次)画一个处理框
    对于输入和输出数据,在相应画一个处理框。输入:处理、输出:产生

  4. 列出分配操作和条件

  5. 用伪代码写程序

编码

程序设计语言(了解)

程序复杂性的度量

代码行度量法

多个工程师进行估计,估算最小值aˉ\bar{a}、最大值bˉ\bar{b}、最可能的值mˉ\bar{m},求平均值:

L=aˉ+4mˉ+bˉ6L=\frac{\bar{a}+4\bar{m}+\bar{b} }{6}

对于复杂的项目,可以分成多个功能,分别估计,再求和。

McCabe 度量法

  1. 将程序流程图所有处理退化成圆,折线转换成弧线

  1. 计算方法
    • 由有向弧数和节点数计算:V(G)=弧数节点数+2V(G)=弧数-节点数+2
    • 由判定点计算:V(G)=P+1V(G)=P+1,P 为判定点个数(看箭头方向,分叉或者合并)

测试

基本概念

  1. 单元测试:对程序的基本组成单元进行测试
  2. 集成测试:在单元测试的基础上将所有模块联合起来的测试
  3. 系统测试:将各个模块作为一个整体与其他因素一起进行测试
  4. 测试工作的内容:理解软件产品的功能需求设计内容,并对其测试,检查软件是否需用户需求一致、是否与设计一致,写出相应的测试报告。

测试过程

测试内容审查内容对应生命周期
----代码审查编码
单元测试详细设计审查详细设计
集成测试总体设计审查总体设计
系统测试需求分析审查需求分析
  1. 设计阶段的测试:静态审查、设计测试用例和测试数据
  2. 测试阶段的测试:动态测试
  3. 确认测试和回归测试:
    • 确认测试:确定修改是否正确
    • 回归测试:保证修改不会出现新的错误
  4. 验收测试:用户接收软件之前进行的测试

单元测试(了解)

  1. 驱动程序:调用被测试单元的主程序

  2. 桩程序:调用的没有完成的函数的替代程序

  3. 步骤:编写测试用例->构造测试环境、设置测试数据->实施测试->修改和回归测试->编写测试报告

  4. 策略:

    • 自顶向下:省去驱动模块的设计,并行性较差
    • 自底向上:省去桩模块的设计,并行性较差
    • 独立单元测试:不需要考虑各个单元的联系,并行性较强,需要设计驱动模块和桩模块

集成测试(了解)

  1. 一次性:一次性测所有模块
  2. 渐增式:先一个个单元测试,再逐渐组装成较大的系统进行测试

系统测试(了解)

  1. 功能测试:最基本的测试
  2. 性能测试:响应时间、系统资源等
  3. 兼容性测试
  4. 压力测试:高负荷条件下的测试

维护

  1. 定义:软件交付使用之后,因软件中存在的缺陷,以及需求和环境的变化,对软件进行修正的过程。

  2. 影响因素:系统大小、程序设计语言、系统年限、软件开发技术、其他

  3. 种类:纠错性维护(改 BUG)、适应性维护(适应系统和硬件)、完善性维护(增加需求)、预防性维护(改进未来的可维护性)

  • 标题: 软件工程导论
  • 作者: ObjectKaz
  • 创建于: 2021-06-22 10:34:56
  • 更新于: 2023-05-25 17:18:13
  • 链接: https://www.objectkaz.cn/d8840a5c164e.html
  • 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。