当前位置：首页 > news >正文

软件设计师知识点总结：软件工程

news 2025/10/26 11:34:47

一. 软件工程概述

1.1 软件工程基本原理

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

1.2 软件工程的基本要素

方法：完成软件工程项目的技术手段
工具：支持软件的开发、管理、文档生成等
过程：将软件工程的方法和工具综合起来，定义了完成软件工程项目的一系列步骤

1.3 软件生存周期

软件工程的软件生存周期包含以下阶段：

可行性分析与项目开发计划
需求分析
概要设计（选择系统解决方案，规划子系统）
详细设计（设计子系统内部具体实现）
编码
测试
维护

二. 软件过程

2.1 能力成熟度模型 CMM

能力成熟度模型 CMM 是对软件组织化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过以下阶段逐步提高：

初始级：软件过程杂乱无章，几乎没有明确定义的步骤，项目成功完全依赖个人努力和英雄式核心人物的作用
可重复级：建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功
已定义级（标准）：管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件
已管理级（产品质量）：制定了软件过程和产品质量的详细度量标准
优化级（改进）：加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进

2.2 能力成熟度模型 CMMI

CMMI（能力成熟度模型集成）将已有的几个 CMM 模型结合在一起，构建成 “集成模型”，支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，提高过程的质量和工作效率。CMMI 有两种表示方法：

2.2.1 阶段式模型

类似于 CMM，关注组织的成熟度，分为五个成熟度级别：

初始的：过程不可预测且缺乏控制
已管理的：过程为项目服务
已定义的：过程为组织服务
定量管理的：过程已度量和控制
优化的：集中于过程改进

2.2.2 连续式模型

关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级

2.3 统一过程 UP

统一过程模型是一种开发过程，具有三大特点：用例和风险驱动、以架构为中心、迭代并且增量。其开发分为四个阶段：

起始阶段：进行项目的初始活动，如确认需求和风险评估等
精化阶段：开展需求分析和架构设计等工作
构建阶段：完成系统的构建，产生实现模型等
移交阶段：开展软件提交方面的工作，产生软件增量，进行 β 测试，交付系统等

UP 的每一次迭代都是一次完整的软件开发过程，涵盖整个软件开发生命周期，包含五个核心工作流：需求、分析、设计、实现、测试

其典型的代表是RUP是UP的商业扩展，更完整，更详细

三. 软件过程模型

软件过程模型（软件开发模型）是软件开发全部过程、活动和任务的结构框架，主要包括以下类型：

3.1 瀑布模型（需求明确，明确开发经验）

别称：SDLC（软件开发生命周期）模型，是结构化方法中的典型模型
核心特点：开发流程呈线性顺序，如同瀑布自上而下，一步一步推进，仅适用于需求明确或二次开发（需求稳定）的项目
局限性：当需求不明确时，最终开发的项目易出现偏差，存在较大缺陷
每个阶段结束都要写一个文档

3.2 V 模型

本质：瀑布模型的变体
核心特点：增加多轮测试，且测试贯穿软件开发的各个阶段（而非仅在开发完成后测试），大幅提高项目准确性
开发与测试对应关系：开发阶段与测试阶段一一对应，如需求分析对应验收测试、概要设计对应系统测试、详细设计对应集成测试、编码对应单元测试

3.3 演化模型（需求不明确，不断改善，快速投入使用）

演化模型针对需求不明确的项目，通过迭代逐步完善需求和产品，主要包括以下两类：

3.3.1 原型模型（捕获系统需求，规模小）

核心思想：快速构造功能模型（原型），演示给用户并根据反馈及时修改，通过反复演示与沟通，最终确定符合用户需求的项目设计
优势：避免因需求不明确导致最终产品与用户期望不符的问题，采用迭代思想

3.3.2 螺旋模型（复杂的大型软件，加入了风险分析）

核心特点：融合多种模型优势，针对需求不明确的项目，在原型模型基础上增加风险分析（其最大特点）
四步流程：制定计划→风险分析→实施工程→用户评估
优势：通过风险分析降低项目风险，适用于大型、复杂且需求不确定的项目

3.4 增量模型（第一个增量往往是核心的产品）

核心思想：先开发核心模块功能，与用户确认后，再开发次核心模块功能，每次开发一部分功能并确认需求，最终完成项目
关键特性：优先级最高的服务最先交付；每一次增量版本均可作为独立可操作的产品，与原型模型（原型仅用于演示）不同，第一个可交付的版本所需要的时间和成本很少，因此可以减少用户需求的变更
局限性：未从系统整体角度规划模块，不利于模块划分；难点在于将客户需求合理划分为多个增量

3.5 其他模型

3.5.1 喷泉模型（以对象为驱动的模型）

核心特点：以用户需求为动力，以对象为驱动，适合面向对象开发方法
优势：开发过程具有迭代性和无间隙性（各阶段无明显边界，可交叉进行）

3.5.2 基于构件的开发模型 CBSD

核心思想：利用预先包装的构件（组织内部开发或商品化成品软件构件）构造应用系统
优势：增强复用性，构建构件库供其他系统复用，提高可靠性，节省时间和成本

3.5.3 形式化方法模型

核心思想：建立在严格数学基础上，主要活动是生成计算机软件形式化的数学规格说明
优势：确保软件的正确性和可靠性，适用于对安全性、正确性要求极高的领域（如航空航天、医疗设备）

3.6 软件开发方法

3.6.1 结构化方法

核心特点：流程固定，针对需求明确的项目，自顶向下、逐层分解，面向数据流
数据流映射：将数据流映射为软件系统的模块结构，数据流类型包括变换流型和事务流型，不同类型有不同映射方法
代表模型：瀑布模型
局限性：开发完成后难以修改，不利于复用及后续版本开发，目前逐渐被面向对象方法替代
设计内容：
- 体系结构设计：宏观架构设计
- 数据设计：数据流的设计
- 接口设计：关注模块间的连接设计
- 过程设计：模块内具体实现过程的数据结构和算法设计

3.6.2 Jackson 方法

核心特点：面向数据结构的开发方法
适用场景：小规模项目

3.6.3 原型方法

核心特点：适合需求不明确的开发
代表模型：原型模型

3.6.4 面向对象方法

核心特点：强调复用性，构建全面合理的模型供不同项目使用，方便修改，节省开发时间和效率
代表模型：构件组装模型
优势：解决结构化方法难以修改、复用性低的问题，是目前主流的软件开发方法

3.7 敏捷开发

敏捷开发针对中小型项目，以 “减负” 为核心，去除不必要的会议和文档，指代一组模型（极限编程、自适应并发、水晶方法等），具有统一的原则和价值观。

3.7.1 敏捷开发宣言

个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划

3.7.2 核心模型与实践

模型 / 实践	核心特点
极限编程（XP）	核心是沟通、简明、反馈和勇气；无需前期大量文档；提倡测试先行，降低后续 bug 率
并列争球法（SCRUM）	迭代增量化过程，每 30 天为一个 “冲刺”；按需求优先级实现产品；多自组织、自治小组并行开发
自适应开发	强调开发方法的适应性；无过多具体实践，侧重从组织和管理层次阐述适应性的重要性
水晶方法	不同项目需定制专属策略、约定和方法论
特性驱动开发	针对中小型项目的模型驱动快速迭代开发过程；强调简化、实用、易被团队接受；适用于需求频繁变动的项目
敏捷统一过程	在大型上连续，在小型上连续

3.7.3 关键实践

结对编程：一名程序员开发，另一名程序员观察审查代码，实时提升代码质量，共同对代码负责
持续集成：频繁集成代码并测试，及时发现问题
自动化测试：通过工具自动执行测试用例，提高测试效率
小型版本发布：频繁交付小型增量版本，快速获取用户反馈

3.8 需求分析

3.9 系统设计

四. 系统测试

4.1 系统测试与调试

4.2 传统软件测试策略

4.2.1 单元测试

4.2.2 集成测试

4.3 测试方法

软件测试分为静态测试和动态测试

静态测试：是指被测试程序不在机器上运行，而是采用人工检测和计算机铺助静态分析的手段对程序进行检测。

人工检测。人工检测不依靠计算机而是依靠人工审查程序或评审软件，包括代码检查、静态结构分析和代码质量度量等。
计算机辅助静态分析。利用静态分析工具对被测试程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。

动态测试：是指通过运行程序发现错误。在对软件产品进行动态测试时可以采用黑盒测试法和白盒测试法。
测试用例由测试输入数据和与之对应的预期输出结果组成。在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

4.3.1 黑盒测试（内部源码不知道）

4.3.2 白盒测试（知道内部源码）

4.3.3 McCabe度量法

五.运行与维护

5.1 系统可维护性评价与指标

5.2 软件文档

5.3 软件维护内容

5.4 软件可靠性，可用性，可维护性

六. 软件项目管理

有效的软件项目管理集中在4P上：人员（People）、产品（Product）、过程（Process）、项目（Project）。

6.1 软件项目估算

6.1.1 成本估算方法

方法	核心思想
自顶向下估算（类比估算法）	先确定总金额，再向下分摊到每个功能点
自底向上估算	从底层功能点开始估算成本，逐层向上累加
差别估算法	与历史项目对比，相同点直接估算，不同点重新估算
专家估算	聘请专家凭经验对项目整体费用进行估算

6.1.2 COCOMO 估算模型

COCOMO 模型是常用的软件规模估算方法，以代码行数（LOC）为度量单位，按详细程度分为三级：

基本 COCOMO 模型：静态单变量模型，用 LOC 为自变量的经验函数计算软件开发工作量
中间 COCOMO 模型：静态多变量模型 ，在基本模型基础上，结合产品、硬件、人员、项目等影响因素调整工作量估算
详细 COCOMO 模型：将软件系统模型分为系统，子系统，模块三部分。包含中间模型所有特性，进一步考虑软件工程各步骤（如分析、设计）的影响

COCOMOⅡ 模型（COCOMO 升级版本）：以软件规模为主要成本因素，考虑多个成本驱动因子，包含三个阶段性模型：

应用组装模型（软件工程前期阶段使用）
早期设计阶段模型（需求稳定且基本软件体系结构建立时使用）
体系结构阶段模型（软件构造过程中使用）

6.1.3 Putnam 估算模型

动态多变量模型，假设软件开发整个生存周期中工作量有特定分布

6.2 进度管理

6.2.1 基本原则

划分任务
明确任务间的相互依赖关系
分配时间
确认工作量
确定责任主体
明确输出结果
确定里程碑

6.2.2 常用工具

Gantt 图（横道图）：
- 横轴表示时间，纵轴表示活动
- 优势：能反映活动间的并行关系
- 局限性：无法反映活动间的依赖关系，难以确定关键任务和关键路径
PERT 图（计划评审技术图）：
- 有向图，反映活动间的依赖关系，有向边标注活动运行时间
- 优势：能清晰体现任务依赖关系
- 局限性：无法反映活动间的并行关系

6.2.3 关键路径相关概念

最早开始时间（ES）：取所有前驱活动最早完成时间（EF）的最大值
最早完成时间（EF）：最早开始时间（ES）+ 活动本身时间（DU）
关键路径：项目中耗时最长的线路，决定项目总工期
最晚完成时间（LF）：取后续活动最晚开始时间（LS）的最小值
最晚开始时间（LS）：最晚完成时间（LF）- 活动本身时间（DU）
松弛时间：某活动的最晚开始时间 - 最早开始时间（或最晚完成时间 - 最早完成时间），即活动最多可延迟的开始时间

6.2.4 项目活动图

6.4 软件配置管理

6.4.1 核心概念

基线：软件开发过程中特定的点（里程碑），反映阶段性成果（如需求规格说明书评审通过后成为需求基线）
软件配置项：软件工程中产生的信息项，是配置管理的基本单位，包括：
1. 环境类（系统开发环境）
2. 定义类（需求分析与系统定义阶段成果）
3. 设计类（设计阶段成果）
4. 编码类（编码及单元测试阶段成果）
5. 测试类（系统测试完成后成果）
6. 维护类（维护阶段成果）

6.4.2 版本控制

配置项状态：草稿、正式、修改
版本命名规则：
1. 草稿状态：格式为0.YZ（YZ 范围 01~99，随草稿完善递增）
2. 正式状态：格式为X.Y（X 为主版本号 1~9，Y 为次版本号 1~9；首次正式发布为 1.0；小升级增 Y，大升级增 X）
3. 修改状态：格式为X.YZ（修改时仅增 Z，X.Y 不变）

6.4.3 变更控制

核心目的：防止版本混乱，需结合基线和配置数据库
配置数据库分类：
1. 开发库：专供开发人员使用，修改频繁，控制宽松
2. 受控库：存储阶段产品（如需求文档、设计文档），是配置管理的核心，控制严格
3. 产品库：存储完成系统测试的最终产品，等待交付用户

6.5 风险管理

6.5.1 软件风险的特性与分类

特性：不确定性（可能发生也可能不发生）、损失（发生会产生恶性后果）
分类：
1. 项目风险：威胁项目计划，如预算、进度、人员、资源、需求等问题；项目复杂度、规模及结构不确定性也属此类
2. 技术风险：威胁软件质量和交付时间，如设计、实现、接口、验证、维护问题；规格说明歧义、技术陈旧、“前沿” 技术也属此类
3. 商业风险：威胁软件生存能力，包括市场风险（开发无需求产品）、策略风险（产品不符公司策略）、销售风险（销售团队不会销售）、管理风险（失去高层支持）、预算风险（无预算或人员保证）

6.5.2 风险管理的过程

风险识别：回避这些风险，建立风险条目检查表，识别项目中已知和可预测的风险，确定来源、产生条件、特征，形成风险列表
风险预测（风险估计）：预测风险发生的概率和后果，风险曝光度 = 风险发生概率 × 风险损失
风险评估：定义风险参照水准，对识别的风险分类评估
风险控制：建立处理策略，包括风险避免、风险监控、RMMM 计划（风险缓解、监控和管理计划）

七. 软件质量管理

7.1 软件质量特性

7.1.1 ISO/IEC9126 软件质量模型

ISO/IEC9126 模型定义了软件的质量特性和子特性：

质量特性	质量子特性
功能性	适合性、准确性、互用性、依从性、安全性
可靠性	成熟性、容错性、易恢复性
易使用性	易理解性、易操作性、易学性
效率	时间特性、资源特性
可维护性	易分析性、易改变性、易测试性、稳定性
可移植性	适应性、易安装性、一致性、易替换性

7.1.2 McCall 质量模型

框架结构：三层框架（质量特性、评价标准、度量指标）
三大方面与 11 个质量特性：
1. 产品运行：正确性、效率、可靠性、完整性、易使用性
2. 产品修正：可维护性、灵活性、可测试性
3. 产品转移：可移植性、复用性、互用性

7.2 软件评审

7.3 软件容错技术

7.3.1 质量与容错的关系

设计质量：设计规格说明书符合用户标准
程序质量：程序按设计规格说明书正确执行
容错：软件遇到错误时的处理能力，核心手段是冗余

7.3.2 冗余技术分类

结构冗余：
- 静态冗余：通过表决和比较（少数服从多数）实现容错
- 动态冗余：多重模块待机备份，故障时切换备份机
- 混合冗余：结合静态和动态冗余
信息冗余：在数据中添加额外信息（如校验码），实现检错和纠错
时间冗余：遇到错误时重复执行（如回滚），重复仍错则转入错误处理逻辑
冗余附加技术：实现上述冗余技术所需的资源和技术（如程序、指令、数据、存储和调度通道）