软件工程

开发模型

软件工程有哪些开发模型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
1. 瀑布模型【*】
- 严格区分阶段,每个阶段因果关系紧密相连
- 只适合需求明确的项目
2. 原型模型【*】
- 原型模型两个阶段:原型开发阶段和目标软件开发阶段
- 适合需求不明确的项目
- 分为抛弃型原型(快速原型)和演化性原型
3. V模型
- 测试贯穿于始终
- 需求分析对应验收测试与系统测试;概要设计对应集成测试,详细设计对应单元测试。
4. 迭代与增量
5. 螺旋模型【*】
- 以快速原型为基础 + 瀑布模型
- 考虑了风险问题
6. 基于构件的开发模型(CBSD)
- 易拓展、易重用、降低成本、安排任务更灵活
- 要求架构师能力高
7. 基于构件的软件工程(CBSE)
- 体现了购买而不是重新构造的哲学
8. 快速应用开发(RAD)
- SDLC(瀑布) + CBSD(基于构件)
9. 软件统一过程(UP/RUP)【*】
10. 敏捷模型【*】

软件工程有哪些过程模型(新版)

1
2
3
4
1. 瀑布模型
2. 原型模型
3. 软件统一过程(UP/RUP)
4. 敏捷模型

CBSE构件所应该具备的特征

1
2
3
4
5
1. 可组装性:所有外部交互必须通过公开定义的接口进行
2. 可部署性:构件总是二进制形式的,能作为一个独立的实体在平台上运行
3. 文档化:用户根据文档来判断构件是否满足需求
4. 独立性:可以在无其他特殊构件的情况下进行组装和部署
5. 标准化:符合某种标准化的构件模型

CBSE构件的组装顺序

1
2
3
1. 顺序组装:按顺序调用已存在的构件,可以用两个已经存在的构件来创造一个新的构件
2. 层次组装:被调用构件“提供”的接口必须和调用构件的“请求”接口兼容
3. 叠加组装:多个构件合并形成新的构件,新构件整合原构件的功能,对外提供新的接口

RUP模型的几个阶段

1
初始->细化->构造->移交

image-20241008201333612

RUP的4+1视图模型

1
2
逻辑、实现、用例、进程、部署
P50

净室软件工程(CSE)的技术手段

1
2
3
4
1. 统计过程控制下的增量式开发:控制迭代
2. 基于函数的规范和设计:盒子结构
3. 正确性验证:净室软件工程的核心
4. 统计测试和软件认证:使用统计学原理,总体太大时采用抽样

净室软件工程(CSE)的缺点

1
2
3
1. 太过理论化,正确性验证的步骤困难且耗时
2. 不进行传统的模块测试
3. 带有传统软件工程的弊端

需求工程

需求工程有几个阶段

1
2
3
4
5
6
7
1. 需求获取
2. 需求分析
3. 形成需求规格(需求文档化)【SRS】
4. 需求的确认与验证【形成需求基线】
5. 需求管理【变更控制、版本控制、需求跟踪、需求状态跟踪】

注:1-4 也叫需求开发。5需求管理是对需求基线进行管理

需求的分类

1
2
3
4
5
6
7
8
分层维度:
1. 业务需求
2. 用户需求
3. 功能需求
QFD(项目管理维度):
1. 基本需求
2. 期望需求
3. 兴奋需求

需求获取方法

1
2
3
4
5
6
用户面谈:成本高,有领域知识
联合需求计划(JRP):交互好,各方参与
问卷调查:用户多,成本低
现场观察:针对复杂流程
原型化方法:解决早期需求不明确
头脑风暴:新业务,发散思维

需求分析(系统分析/设计)的方法

1
2
3
4
1. 结构化方法
2. 面向对象方法
3. 其他方法(软件重用)
4. 逆向工程

结构化分析方法使用的手段

1
2
3
数据流图DFD
状态转换图
ER图

image-20241008203421467

image-20241008203428644

image-20241008203438039

面向对象方法使用的手段

1
UML

UML的4+1视图

image-20241008203907964

需求定义(需求文档化所用到的方法)

1
2
3
4
5
6
7
8
9
1. 严格定义法
- 所有需求都能被预先定义
- 开发人员和用户之间能够准确而清晰地交流
- 采用文字/图形充分体现最终系统
2. 原型法
- 开发前需求不明确
- 交流困难
- 需要实际的、可供用户参与的系统模型
- 有合适的系统开发环境

软件设计

软件设计分为哪几类

1
2
3
4
1. 软件系统建模
2. 结构化设计
3. 面向对象设计
4. 界面设计

有哪几种软件系统建模方法

image-20241008204917703

结构化设计的分类和原则

1
2
3
4
5
6
7
8
9
分类:
1. 概要设计【外部设计】:功能需求分配给软件模块,确定每个模块的功能和调用关系,形成模块结构图
2. 详细设计【内部设计】:为每个具体任务选择适当的技术手段和处理方法

原则:
1. 模块独立性原则(高内聚,低耦合)
2. 保持模块大小适中
3. 多扇入,少扇出
4. 深度和宽度均不宜过高

结构化设计中模块的四个要素

1
2
3
4
1. 输入和输出
2. 处理功能
3. 内部数据
4. 程序代码

结构化设计中内聚、耦合的类型

image-20241008205344398

image-20241008205351767

面向对象设计的基本过程

image-20241008205448865

面向对象设计中类的分类

1
2
3
1. 边界类:API接口;用户界面;显示屏;二维码;购物车;
2. 控制类:排除法
3. 实体类:学员;课程

界面设计的法则

1
2
3
1. 置于用户控制之下
2. 减少用户的记忆负担
3. 保持界面的一致性

测试

测试的分类(类型)

1
2
3
4
5
6
7
8
动态测试【计算机运行】
- 白盒
- 黑盒
- 灰盒
静态测试【人工监测和计算机辅助分析】
- 桌前检查
- 代码审查
- 代码走查

测试的方法

1
2
3
4
5
6
7
8
9
10
白盒测试【结构测试】:主要用于单元测试
- 控制流测试(语句覆盖最弱,路径测试覆盖最强)
- 数据流测试
- 程序变异测试
黑盒测试【功能测试】:主要用于集成、确认、系统测试
- 等价类划分
- 边界值分析
- 错误推测
- 判定表
- 因果图

测试有哪些阶段

1
V模型

image-20241008210305238

维护

遗留系统演化策略是什么

1
2
3
4
5
6
7
8
9
10
11
12
13
高水平低价值【信息孤岛】:集成
- 遗留系统的技术含量较高,但其业务价值较低,可能只完成某个部门(或子公司)的业务管理。这种系统在各自的局部领域里工作良好,但对于整个企业来说,存在多个这样的系统,不同的系统基于不同的平台、不同的数据模型,形成了一个个信息孤岛,对这种遗留系统的演化策略为集成。

高水平高价值:改造(包括系统功能增强和数据模型改造)
- 遗留系统具有较高的业务价值,基本上能够满足企业业务运作和决策支持的需要。这种系统可能建成的时间还很短,对这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求,对遗留系统本身不做改变;数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。

低水平低价值:淘汰
- 遗留系统的技术含量较低,且具有较低的业务价值。对遗留系统的完全淘汰是企业资源的根本浪费,系统分析师应该善于“变废为宝”,通过对遗留系统功能的理解和借鉴,可以帮助新系统的设计,降低新系统开发的风险。

低水平高价值:继承
- 遗留系统的技术含量较低,已经满足企业运作的功能或性能要求,但具有较高的商业价值,目前企业的业务尚紧密依赖该系统。对这种遗留系统的演化策略为继承。在开发新系统时,需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性,新老系统必须并行运行一段时间,再逐渐切换到新系统上运行。

开发新系统时,需要完全兼容遗留系统的功能模型和数据模型

软件维护有哪些类型

1
2
3
4
1. 正确性维护【修BUG】:识别和纠正软件的错误/缺陷
2. 适应性维护【应变】:应用软件适应环境变化而进行的修改
3. 完善性维护【新需求】:扩充功能和改善性能而进行的修改
4. 预防性维护【针对未来】:为了适应未来的软硬件环境的变化

影响可维护性的因素有哪些

1
2
3
4
5
1. 可理解性
2. 可修改性
3. 可测试性
4. 可靠性
5. 可移植性