软件工程基础：从危机到解决方案

1. 软件工程学概述

1.1 软件危机及其解决方案

软件危机是指在计算机软件开发与维护过程中遇到的一系列严重问题。20世纪60年代，随着计算机硬件性能的快速提升，软件规模不断扩大，出现了"软件危机"现象。主要表现为：项目延期、预算超支、质量低劣、维护困难等。

产生原因主要有两方面：

1. 软件本身特性：软件是逻辑产品而非物理实体，具有不可见性、复杂性、易变性等特点
2. 开发方法不当：早期缺乏系统化的开发方法，过度依赖个人技巧，文档不完善

解决方案包括四个层面：

1. 认知层面：正确理解软件=程序+数据+文档的三元结构
2. 方法层面：采用工程化开发方法，遵循软件工程原理
3. 工具层面：使用合适的开发工具与环境
4. 管理层面：加强项目管理，实施计划、评审和变更控制

1.2 软件工程基本原理

软件工程是指导计算机软件开发和维护的工程学科，结合了管理技术和最佳技术方法。其7条基本原理构成了现代软件开发的基石：

1. 分阶段生命周期计划：将开发过程划分为可管理的阶段，每个阶段都有明确目标和交付物
2. 阶段评审：在关键节点进行严格评审，尽早发现问题
3. 产品控制：实施基准配置管理，控制变更影响
4. 现代程序设计技术：采用结构化、面向对象等先进技术
5. 结果可审查：确保工作成果可测量、可验证
6. 人员精简：开发小组规模适中，成员素质高
7. 持续改进：不断优化工程实践，提升开发能力

1.3 软件工程方法学

软件工程方法学包含方法、工具和过程三个要素，主要分为两类：

1. 传统方法学（结构化范型）：

• 采用结构化分析、设计和实现技术
• 按生命周期顺序开发
• 文档驱动，强调自顶向下分解
• 适用于需求明确、变化少的项目

2. 面向对象方法学：

• 以对象为核心，包含对象、类、继承和消息通信
• 模拟人类思维方式，更自然直观
• 支持迭代和增量开发
• 强调主动的多次反复迭代
• 适用于需求变化频繁的项目

1.4 软件生命周期

软件生命周期分为三个时期八个阶段：

1. 软件定义时期：

• 问题定义：明确要解决的问题
• 可行性研究：评估技术、经济和操作可行性
• 需求分析：确定系统必须做什么

2. 软件开发时期：

• 总体设计：确定系统如何实现
• 详细设计：确定模块具体实现
• 编码和单元测试：编写并测试单个模块
• 综合测试：集成测试和确认测试

3. 运行维护时期：

• 软件维护：改正错误、适应变化、完善功能

1.5 软件过程模型

常见软件过程模型各有特点：

1. 瀑布模型：

• 顺序执行各阶段
• 文档驱动
• 适用于需求明确、变化少的项目
• 缺点：难以适应需求变化

2. 快速原型模型：

• 快速构建可运行原型
• 获取用户真实需求
• 适用于需求模糊的项目
• 缺点：原型可能被误用为最终产品

3. 增量模型：

• 分批交付功能
• 每次交付一个增量构件
• 适用于资源有限的项目
• 优点：可快速交付核心功能

4. 螺旋模型：

• 风险驱动
• 每周期包含计划、风险分析、开发和评估
• 适用于大型复杂项目
• 缺点：成本高，需要专业风险评估

5. 敏捷过程（如XP）：

• 响应变化优于遵循计划
• 强调迭代开发、客户合作
• 适用于小型项目
• 需要高度自律的团队

2. 可行性研究

2.1 可行性研究概述

可行性研究的核心目的是确定问题是否值得解决，而非如何解决。这一阶段需要回答三个关键问题：

1. 技术可行性：现有技术能否实现系统？
2. 经济可行性：效益是否超过成本？
3. 操作可行性：用户环境能否接受系统？

可行性研究过程包含八个步骤：

1. 复查系统规模和目标
2. 研究现有系统
3. 导出新系统逻辑模型
4. 进一步定义问题
5. 导出和评价供选择的解法
6. 推荐行动方针
7. 草拟开发计划
8. 书写文档提交审查

2.2 系统流程图与数据流图

系统流程图是描绘物理系统的传统工具，展示数据在各部件间的流动情况。常用符号包括：

• 处理（矩形）
• 输入/输出（平行横线）
• 数据存储（开口矩形）
• 数据流（箭头）

数据流图(DFD)描述系统逻辑模型，关注数据处理逻辑而非物理实现。DFD包含四种核心符号：

1. 源点/终点（正方形）：数据来源或去向
2. 处理（圆角矩形）：数据变换
3. 数据存储（开口矩形）：数据保存
4. 数据流（箭头）：数据流动方向

绘制原则：

• 自顶向下逐步细化
• 每个处理应有唯一编号
• 数据流应有明确名称
• 保持图的平衡性

2.3 数据字典

数据字典是对DFD中所有元素的精确定义，与DFD共同构成完整的系统逻辑模型。其内容包含：

• 数据流
• 数据元素（数据流分量）
• 数据存储
• 处理

数据结构定义方法使用四种符号：

1. 顺序（+）：如A+B表示A后跟B
2. 选择（[]）：如[A|B|C]表示A或B或C
3. 重复（{}）：如{A}₁₅表示A重复1到5次
4. 可选（()）：如(A)表示A可有可无

2.4 成本/效益分析

成本/效益分析通过量化计算判断项目是否值得开发。主要方法包括：

1. 成本估计技术：

• 代码行技术：基于历史数据估算代码行数
• 任务分解技术：将项目分解为可估算的小任务
• 自动估计成本技术：使用工具模型估算

2. 关键概念：

• 货币时间价值：现值公式P=F/(1+i)ⁿ
• 投资回收期：累计经济效益等于初始投资所需时间
• 纯收入：生命周期累计经济效益减去初始投资
• 投资回收率：使累计现值等于初始投资的年利率

3. 需求分析

3.1 需求分析概述

需求分析的核心目的是准确确定"系统必须做什么"，导出系统的逻辑模型。其主要任务包括：

1. 确定综合要求：

• 功能需求：系统必须提供的功能
• 性能需求：响应时间、吞吐量等
• 可靠性需求：可用性、容错性等
• 接口需求：与外部系统的交互
• 约束：设计限制条件

2. 分析数据要求：建立数据模型
3. 导出逻辑模型：DFD+数据字典+ER图等
4. 修正开发计划

3.2 实体-联系图(ER图)

ER图是描述系统数据关系的图形工具，包含三个核心元素：

1. 实体（矩形）：现实世界中的对象，如"学生"、"课程"
2. 属性（椭圆形）：实体的特征，如学生的"学号"、"姓名"
3. 联系（菱形）：实体间的关系，如"选课"

联系类型包括：

• 一对一(1:1)：如学生与学生证
• 一对多(1:N)：如教师与课程
• 多对多(M:N)：如学生与课程

绘制步骤：

1. 识别系统中的主要实体
2. 确定实体间的关系
3. 为实体和关系添加属性
4. 确定主键和外键

3.3 状态转换图

状态转换图描绘系统行为，展示状态及事件触发的状态转换。其核心符号包括：

1. 初态（实心圆）：系统启动时的状态
2. 终态（双同心圆）：系统结束时的状态
3. 中间态（圆角矩形）：系统的行为模式
4. 转换（带箭头连线）：由事件触发的状态变化

绘制步骤：

1. 识别系统的主要状态
2. 确定触发状态转换的事件
3. 描述每个状态的活动
4. 定义状态间的转换关系

3.4 其他建模工具

1. 层次方框图：

• 树形结构描绘数据层次关系
• 顶层为整体数据，下层为子数据
• 直观清晰，适合展示数据组织结构

2. Warnier图：

• 树形结构+符号描述数据结构
• "+"表示选择，"()"表示重复
• 能体现数据的顺序、选择和重复关系

3. IPO图：

• 输入-处理-输出图
• 左侧列输入数据，中间列处理步骤，右侧列输出数据
• 用于描述模块的功能

3.5 需求验证

需求验证需要从四个维度评估：

1. 一致性：需求间无矛盾
2. 完整性：无遗漏重要需求
3. 现实性：现有技术可实现
4. 有效性：满足用户实际需求

验证方法包括：

1. 人工审查：专家评审需求规格说明书
2. 快速原型：构建原型让用户试用
3. 形式化验证：用工具检查逻辑一致性

4. 总体设计

4.1 总体设计概述

总体设计的核心目的是概括地确定"系统如何实现"，主要任务包括：

1. 设想供选择的方案
2. 选取合理的方案（至少3种）
3. 推荐最佳方案
4. 功能分解
5. 设计软件结构
6. 设计数据库
7. 制定测试计划
8. 书写文档
9. 审查和复审

4.2 模块独立性

模块独立性是衡量软件设计质量的核心标准，包含两个关键指标：

1. 耦合（模块间依赖程度）：

• 数据耦合（最佳）：仅通过参数传递数据
• 控制耦合：传递控制信息
• 特征耦合：传递部分数据结构
• 公共环境耦合：共享数据环境
• 内容耦合（最差）：直接访问内部数据

设计原则：尽量使用数据耦合，避免内容耦合

2. 内聚（模块内元素结合程度）：

• 功能内聚（最佳）：完成单一功能
• 顺序内聚：按顺序执行，输出为下一环节输入
• 通信内聚：共享数据
• 过程内聚：按特定过程执行
• 时间内聚：同一时间执行
• 逻辑内聚：逻辑相关功能
• 偶然内聚（最差）：无关联功能

设计原则：追求功能内聚，避免偶然内聚

4.3 层次图与HIPO图

1. 层次图：

• 描述软件模块层次结构
• 矩形代表模块，连线代表调用关系
• 顶层为总模块，下层为子模块
• 直观展示功能分解结构

2. HIPO图：

• 层次图+IPO图的组合
• 每个模块对应一张IPO图
• 标注模块编号，便于追踪功能
• 支持自顶向下逐步细化

4.4 面向数据流的设计方法

面向数据流的设计方法将信息流映射为软件结构，适用于两种信息流类型：

1. 变换流：

• 输入→变换→输出的数据流
• 变换分析步骤：
  a. 确定变换中心
  b. 设计输入、变换、输出结构
  c. 分解各结构模块
  d. 优化软件结构

2. 事务流：

• 接收→分析→处理事务的数据流
• 事务分析步骤：
  a. 确定事务中心
  b. 设计事务控制模块
  c. 为每类事务设计处理模块
  d. 设计子模块

5. 详细设计

5.1 详细设计概述

详细设计的核心目的是确定"模块如何具体实现"，为编码提供详细蓝图。其主要内容包括：

1. 设计模块的算法
2. 设计模块的数据结构
3. 设计模块的接口细节
4. 绘制过程设计图形工具
5. 编写过程设计语言(PDL)

5.2 结构程序设计

结构程序设计强调使用三种基本控制结构：

1. 顺序结构：按顺序执行语句
2. 选择结构：if-then-else条件分支
3. 循环结构：do-while/do-until重复执行

扩展结构：

• 多分支结构：case语句

设计原则：

• 每个代码块单入口、单出口
• 避免使用GOTO语句
• 保持代码清晰易读

5.3 过程设计工具

1. 程序流程图：

• 图形符号描绘控制流
• 符号：处理（矩形）、判断（菱形）、开始/结束（椭圆）
• 优点：直观易懂
• 缺点：易出现非结构化流程

2. N-S图（盒图）：

• 无箭头，强制结构化
• 用矩形框表示基本结构
• 顺序结构为矩形嵌套
• 选择结构为if-then-else框
• 循环结构为do-while框

3. PAD图（问题分析图）：

• 二维树形结构
• 支持自顶向下细化
• 可自动转换为程序代码

4. 判定表：

• 适用于复杂条件组合
• 四部分：条件桩、动作桩、条件项、动作项

5. 判定树：

• 树形结构展示条件与动作
• 适用于条件较少的场景

5.4 面向数据结构的设计方法

Jackson方法根据数据结构设计程序结构，主要步骤：

1. 分析输入/输出数据结构
2. 找出数据结构对应关系
3. 导出程序结构
4. 列出操作与条件
5. 用PDL描述程序

特点：

• 程序结构与数据结构一致
• 简化开发过程
• 适用于数据处理系统

6. 软件测试

6.1 测试基础

软件测试的目标是发现错误而非证明无错。好的测试用例能发现未发现的错误。

测试方法：

1. 白盒测试：已知内部结构，测试内部逻辑
2. 黑盒测试：未知内部结构，测试功能

测试步骤：

1. 单元测试：测试单个模块
2. 集成测试：组装模块为子系统
3. 确认测试：验证系统符合需求
4. 平行运行：新旧系统对比

6.2 白盒测试技术

逻辑覆盖（从低到高）：

1. 语句覆盖：每个语句至少执行1次
2. 判定覆盖：每个判定的真/假分支至少执行1次
3. 条件覆盖：每个条件的真/假值至少执行1次
4. 判定-条件覆盖：同时满足判定和条件覆盖
5. 条件组合覆盖：每个判定中条件的所有组合至少执行1次
6. 路径覆盖：覆盖所有可能路径

测试用例设计示例：
对于条件"(A>1) AND (B=0)"，需要：

• A=2,B=0（真分支）
• A=1,B=1（假分支）

6.3 黑盒测试技术

1. 等价划分：

• 将输入划分为有效/无效等价类
• 从每个类中选1个用例
• 减少测试用例数量

2. 边界值分析：

• 错误多发生在边界
• 测试最小值、最大值和边界附近值
• 补充等价划分的不足

测试用例设计示例：
输入1-100的整数：

• 有效等价类：50
• 无效等价类：0,101
• 边界值：1,100

6.4 调试与可靠性

调试是在测试发现错误后定位并改正的过程，常用方法：

1. 蛮干法：打印大量信息（低效）
2. 回溯法：从错误症状回溯原因（适合小程序）
3. 原因排除法：对分查找、归纳、演绎

软件可靠性指标：

• 平均无故障时间(MTTF)
• 计算公式：MTTF=1/[K(Eₜ/Iₜ-E_c/Iₜ)]
• 与剩余错误数成反比

7. 软件维护

7.1 维护类型

软件维护是交付后为改正错误或满足新需求而修改的过程，分为四类：

1. 改正性维护（17%-21%）：

• 纠正在使用中发现的错误
• 占比相对较小但必不可少

2. 适应性维护（18%-25%）：

• 使软件适应环境变化
• 如操作系统升级、硬件变更

3. 完善性维护（50%-66%）：

• 增加新功能或改进性能
• 占比最高，反映用户需求变化

4. 预防性维护（约4%）：

• 改进可维护性
• 为未来修改做准备

7.2 维护特点

软件维护具有三个显著特点：

1. 结构化与非结构化维护差异大：

• 有完整文档的维护效率高
• 无文档的维护困难重重

2. 维护代价高昂：

• 占软件总费用的55%-70%
• 远超过初期开发成本

3. 维护问题多：

• 文档不足导致理解困难
• 修改易引入新错误
• 人员流动造成知识流失

7.3 维护过程与可维护性

维护过程六个步骤：

1. 提交维护要求
2. 分析维护要求
3. 制定维护方案
4. 实施维护
5. 测试
6. 复审

可维护性决定因素：

1. 可理解性：代码和文档清晰易懂
2. 可测试性：便于设计测试用例
3. 可修改性：模块化程度高
4. 可移植性：适应不同环境
5. 可重用性：组件可重复使用
6. 可靠性：减少维护需求
7. 效率：资源利用率高

提高可维护性的关键：

• 完善的文档体系
• 清晰的代码结构
• 严格的变更管理
• 定期的维护评估