软考高级之软件工程

软件工程

软件工程概述

软件危机

进度失控：开发延期、成本超支（常超预算 50%-100%）

质量低下：功能不达标、Bug 多、可靠性差

维护困难：无规范文档、代码可读性差、修改牵一发而动全身

供需失衡：软件生产率远低于硬件发展速度

软件工程三要素

软件工程由方法、工具、过程三大核心要素构成，缺一不可：

软件工程核心定义

IEEE：将系统化、规范化、可度量的方法应用于软件的开发、运行、维护，并对这些方法进行研究的学科。

Fritz Bauer：应用工程化原则，以低成本获得高质量、可靠的软件。

核心目标：在规定时间、预算内，交付满足需求、高质量、可维护的软件产品

软件生命周期

软件定义

软件开发

软件运行和维护

软件工程过程模型

瀑布模型

特点：阶段严格顺序、文档驱动、无反馈，前一阶段输出是后一阶段输入

适用：需求明确、稳定的中小型项目（如嵌入式、政务系统）

缺点：灵活性差，后期发现问题修改成本极高

原型模型

特点：快速构建原型→用户反馈→迭代优化，降低需求模糊风险

适用：需求不明确、用户参与度高的项目（如互联网产品、创新系统）

增量模型

特点：分批次交付功能模块，每增量一次验证一次，降低整体风险

适用：大型项目、需快速上线核心功能的场景

螺旋模型

特点：风险驱动，每轮循环含 "目标设定→风险分析→开发验证→评审"

适用：超大型、高风险、复杂的软件项目（如航天、金融核心系统）

风险驱动

喷泉模型

定位：面向对象的软件过程模型

核心特点：迭代、无间隙、阶段可重叠、可回溯

优点：灵活支持需求变更，适合面向对象开发，效率高

缺点：管理难度大，文档易混乱

适用：需求不固定、采用面向对象方法的项目

基于构建的模型

定位：复用驱动的软件开发模型，核心是 "购买 / 复用，而非从零建造"

核心：用标准化、可独立部署的构件，通过接口组装构建系统

优点：效率高、成本低、质量稳、易扩展

缺点：需构件库 + 标准化，存在匹配 / 兼容风险

适用：需求明确、有成熟构件的企业级 / 通用系统（OA、电商后台等）

形式化方法模型

建立在严格的数学基础上的一种软件开发方法

敏捷模型

核心思想：个体交互 > 流程工具，可用软件 > 文档，客户协作 > 合同谈判，响应变化 > 遵循计划

特点：迭代、增量、快速交付、拥抱变化

典型方法：Scrum、XP（极限编程）

优点：灵活、风险低、用户参与度高、交付快

缺点：文档弱、对团队要求高、不易管控

适用：需求多变、互联网产品、快速迭代项目

主要的敏捷方法
Scrum迭代开发（Sprint 2～4 周），角色：产品负责人、Scrum Master、开发团队，强调站会、评审、回顾。
XP（极限编程）注重工程实践：TDD 测试驱动、结对编程、持续集成、简单设计、频繁发布。
FDD（特征驱动开发）以 "功能特征" 为单位迭代，短小周期，强调设计和代码质量。
Crystal（水晶方法）按项目规模 /criticality 分不同敏捷流派，轻量、以人为本。

统一过程模型

全称：Rational Unified Process，重量级、用例驱动、架构中心、迭代增量。

二维结构：

时间（4 阶段）：初始 → 细化 → 构建 → 移交

核心工作流：需求、分析、设计、实现、测试

特点：文档规范、阶段清晰、适合大型复杂项目

缺点：过程重、不够灵活，不太适合小型快速项目

RUP 9 个核心工作流（软考必背）

业务建模

需求

分析与设计

实现

测试

部署

配置与变更管理

项目管理

环境

软件能力成熟度

初始级（Level 1 - Initial）
特征：过程无规范、混乱、临时拼凑；成功依**赖个人能力，**结果不可预测。
典型问题：项目超期、超预算、质量不稳定。
可重复级（Level 2 - Managed）
特征：建立项目级基本管理过程（计划、跟踪、需求管理、配置管理、质量保证）；过程可重复、项目可控。
关键实践：项目计划、需求管理、配置管理、质量保证、测量与分析。
已定义级（Level 3 - Defined）
特征：建立组织级标准过程并文档化；项目可裁剪组织标准过程；过程标准化、可复用、质量稳定。
关键区别：从 "项目级管理" 升级为 "组织级管理"。
量化管理级（Level 4 - Quantitatively Managed）
特征：对过程与产品质量量化管理；建立量化目标，用统计技术控制关键过程，过程可预测。
关键实践：量化项目管理、组织过程性能、原因分析与解决。
优化级（Level 5 - Optimizing）
特征：持续过程改进；主动缺陷预防、引入新技术、基于数据驱动优化，追求卓越。
关键实践：组织创新与部署、持续过程改进、缺陷预防。

逆向工程

定义：从现有程序 / 代码反向推导出设计文档、需求、架构的过程。

目的：理解系统、恢复文档、维护改造、复用设计。

层次（从低到高）：

实现级：程序的抽象语法树、符号表、过程的设计表示

结构级：核心内容：反映程序分量之间相互依赖关系的信息，如调用图、结构图、程序和数据结构

功能级：反映程序段功能及程序段之间关系的信息，如数据和控制流模型

领域级：：反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，如 E-R 模型

常配套概念：

重构：在不改变功能前提下优化代码结构

再工程：逆向工程 + 重构 + 正向开发，对旧系统全面升级改造

需求工程

需求工程：把用户意图转化为规范需求的全过程，贯穿软件生命周期前期。

核心任务：获取→分析→定义→验证→管理需求。

需求层次

业务需求：高层目标，为什么做（组织视角）

用户需求：用户要做什么（用户视角）

系统需求：系统必须提供的功能 / 性能 / 约束

功能需求：做什么

非功能需求：性能、安全、可靠性、易用性、可维护性、可移植性

设计约束：技术栈、平台、标准、合规等

需求工程需求获取

需求获取

方法：访谈、问卷、会议、观察、原型、用例
需求分析

结构化分析、面向对象分析

去歧义、完整性、一致性检查
需求定义（规格说明）

输出：需求规格说明书 SRS
需求验证

评审、测试用例、原型验证
需求管理

基线、变更控制、版本可控制、需求追踪，需求状态跟踪

需求获取

需求变更

变更申请 相关方提交书面变更请求，说明原因、内容、范围。
变更评估 评估对进度、成本、质量、范围、风险、资源的影响。
CCB 审批 变更控制委员会评审，决定批准 / 否决 / 暂缓。
变更实施 批准后，修改需求、设计、计划等相关文档与产品。
变更验证与确认 测试、评审，确认变更正确实现且无副作用。
基线更新 更新配置项基线、版本、需求追踪矩阵。
变更通知将结果同步给所有相关干系人。

需求跟踪

正向跟踪
从需求出发：这个需求 → 写到设计里没？→ 代码实现没？→ 写测试用例没？→ 最终上线没？
反向跟踪
从结果往回查：这个功能 → 对应哪个设计？→ 对应哪个需求？

系统分析与设计

主要任务
业务流程梳理
需求获取与分析
提出新系统逻辑方案
可行性分析（技术、经济、操作、法律）

结构化开发方法

就是传统、经典、一步一步来的软件开发方法，也叫结构化分析与设计（SA+SD）。