串联信息系统规划、分析、设计、实施与运行维护阶段，梳理各阶段目标、关键产出物和常用分析设计方法。

# 总览：系统生命周期主线

# 生命周期阶段定位

1
2
3
4
5
6

flowchart LR
    A[系统规划<br/>是否值得做] --> B[系统分析<br/>系统要做什么]
    B --> C[系统设计<br/>系统怎么做]
    C --> D[系统编码<br/>如何用代码实现]
    D --> E[系统测试<br/>是否满足需求]
    E --> F[运行维护<br/>如何长期稳定运行]

# 系统规划

系统规划是软件工程过程的起始阶段，用来定义项目范围、进度、预算和团队。它的关键任务是用较低成本判断项目是否值得继续。

# 核心目标

• 明确业务问题、机会或上级指示。
• 划定系统边界，避免范围蔓延。
• 通过可行性分析回答 “是否值得做”。
• 制定项目计划、预算、进度和团队安排。
• 向指导委员会汇报并获得正式授权。

# 项目启动的三类理由

# 系统规划五大任务

1
2
3
4
5

flowchart LR
    A[列出触发项目的问题] --> B[协商初步范围]
    B --> C[评估项目价值]
    C --> D[计划进度、预算和成员]
    D --> E[汇报项目计划]

# 甘特图与 WBS

• WBS：把项目分解成可管理的工作包。
• 甘特图：用条状图表示任务、时间跨度和进度。
• PERT/CPM：分析任务依赖和关键路径。

# 可行性分析

可行性分析是系统规划阶段的核心决策点，通常形成《可行性研究报告》。

决策结果通常有三种：

• 全部通过：立项。
• 有条件通过：调整范围、资源或计划后继续。
• 否决：终止或重新规划。

# 项目成功与失败因素

常见失败原因：

• 系统需求不完整或频繁变化。
• 用户参与不足。
• 缺少管理层支持。
• 计划不充分，目标不清楚。
• 缺少必要资源。

成功关键因素：

• 清晰的需求定义。
• 大量且有效的用户参与。
• 上层管理支持。
• 完整详细的项目计划。
• 符合实际的进度和里程碑。

# 系统分析

系统分析是软件生命周期第二阶段，核心任务是理解业务需求并转化为详细的系统需求规格。它承接系统规划，为系统设计提供需求基线。

# 系统需求分类

# 好需求的准则

• 一致：不相互冲突。
• 完整：覆盖所有必要输入、输出和响应。
• 可行：在资源和约束下能实现。
• 需要：确实支持系统目标。
• 正确：准确表达用户真实需求。
• 可追踪：能映射到设计、代码和测试。
• 可验证：能通过测试或评审证明是否满足。

# 需求获取过程

需求获取不是一次性访谈，而是结构化过程。

1
2
3
4

flowchart LR
    A[发现和分析问题] --> B[获取需求]
    B --> C[归档和分析需求]
    C --> D[需求管理]

# 阶段一：发现和分析问题

核心是区分表面症状和根本问题，明确范围、目标和利益相关者。

输出：

• 问题陈述草案。
• 利益相关者清单。
• 初步系统改进目标。

# 阶段二：获取需求

系统分析员通常需要收集三类信息：

# 阶段三：归档和分析需求

常用工具：

• 用例：描述参与者与系统交互。
• 决策表：描述复杂业务规则。
• 需求表：结构化管理需求属性。
• SRS：正式记录功能需求、非功能需求、接口、约束。

常见问题：

• 遗漏、矛盾、不可行、重叠、二义性。

# 阶段四：需求管理

需求管理用于控制需求变化。项目中 50% 以上需求在上线前发生变化并不罕见。

重点：

• 建立正式变更流程。
• 每项变更评估影响并获得批准。
• 维护需求基线。
• 建立需求追溯矩阵。

# 七种调查研究技术

推荐策略：

1. 先看现有文档、表格、报告。
2. 合适时观察现有系统。
3. 用问卷澄清大范围问题。
4. 再做面谈或 JRP。
5. 对难以理解的功能构造获取原型。
6. 对不确定信息追查到底。

# 系统分析阶段的 UML 使用

# 系统设计

系统设计基于系统分析输出的 SRS，制定技术解决方案。它把业务语言转化为开发人员可实现的架构、组件、接口、数据模型和部署方案。

# 系统分析与系统设计对比

# 系统设计的两级活动

# 架构设计 / 概要设计

主要任务：

• 确定分层架构、微服务、事件驱动等总体结构。
• 选择编程语言、框架、中间件和数据库。
• 划分模块、包、子系统和构件。
• 定义构件提供接口和需求接口。
• 规划部署节点和网络通信。
• 落实安全、性能、可扩展性等非功能需求。

常见架构模式：

# 详细设计

主要任务：

• 类设计：属性、方法、类型、可见性。
• 交互设计：用序列图描述关键用例实现。
• 状态设计：为复杂对象设计状态机。
• 数据库物理设计：表结构、字段、索引、约束。
• 界面设计：导航、布局、校验规则。
• 算法设计：复杂逻辑用活动图或伪代码表达。

# 设计原则与常见反模式

# SOLID 原则

# 高内聚、低耦合

• 内聚：模块内部元素相关程度，越高越好。
• 耦合：模块之间相互依赖程度，越低越好。

# 常见反模式

• 上帝类：一个类承担过多职责。
• 瑞士军刀接口：接口过大，客户被迫依赖不需要的方法。
• 循环依赖：模块互相依赖，难以维护和测试。
• 功能依恋：一个类过度使用另一个类的数据。
• 过度设计：为不存在的未来需求设计复杂结构。

# 设计阶段工作流与输出

1
2
3
4
5
6

flowchart LR
    A[审查需求模型] --> B[确定设计策略]
    B --> C[架构设计]
    C --> D[详细设计]
    D --> E[应用设计原则与模式]
    E --> F[评审与基线化]

# 分析到设计的转化

# 设计阶段输出物

• 系统设计说明书（SDD）。
• 系统架构图：包图、构件图。
• 设计类图。
• 数据库设计文档：ER 图、表结构。
• 接口协议文档：API 定义。
• 非功能需求实现策略。
• 详细设计文档：序列图、状态图、算法活动图、界面原型。
• 部署架构图。
• 设计评审记录。

# 系统编码

系统编码又称实现阶段，依据详细设计文档编写、调试并集成程序代码，把设计模型转化为可运行的软件系统。

# 编码阶段核心目标

• 忠实实现设计：把设计类图、序列图、状态图等模型落实为代码。
• 保证代码质量：通过编码规范、代码审查、单元测试提升正确性、可读性和可维护性。
• 持续集成验证：逐步集成模块，尽早发现接口和依赖问题。
• 落实非功能需求：在实现中处理性能、安全、并发、异常和资源约束。
• 产出可部署制品：形成可执行文件、库、镜像或发布包。

# 编码阶段核心活动

# 现代实现方式

# 系统测试

系统测试是验证与确认的核心活动，用执行程序的方式发现缺陷，验证系统是否符合需求规格，并评估性能、安全、可靠性等质量属性。

# 测试基本原则

• 测试只能显示缺陷存在，不能证明系统没有缺陷。
• 穷尽测试不现实，应按风险和优先级选择测试重点。
• 测试越早开始，缺陷修复成本越低。
• 缺陷有群集效应，少数模块常包含多数缺陷。
• 测试用例需要持续更新，避免 “杀虫剂悖论”。
• 测试策略依赖项目上下文，安全关键系统和普通业务系统的侧重点不同。

# 测试层次

集成测试常见策略：

• 自顶向下集成：先测上层控制逻辑，再逐步加入底层模块，需要桩程序。
• 自底向上集成：先测底层模块，再逐步组装上层逻辑，需要驱动程序。
• 三明治集成：结合自顶向下和自底向上。
• 持续集成增量测试：每次提交后自动运行相关测试。

# 测试类型

# 重要测试概念

• Alpha 测试：开发组织内部，由最终用户或模拟用户在受控环境中进行。
• Beta 测试：真实用户环境中由最终用户进行，开发组织通常不在现场。
• UAT：用户验收测试，按验收标准和业务场景正式确认系统是否可接收。
• 冒烟测试：正式测试前快速验证核心功能，判断版本是否 “可测”。
• 健全性测试：局部修复或小改动后，快速验证相关功能是否正常。
• 探索性测试：测试人员凭经验自由探索系统，发现预设脚本外的问题。
• 黑盒测试：基于规格说明设计输入输出，不关心内部结构。
• 白盒测试：基于程序内部逻辑结构设计用例，关注路径和覆盖。

# 系统运行维护

系统运行维护是系统交付并投入使用后的持续保障活动，目标是让系统稳定运行，并在业务、法规、技术环境变化时不断修正和演化。

# 运行维护的核心目标

• 保障可用性：按 SLA 提供稳定服务。
• 快速响应故障：发现、诊断、恢复异常，降低业务中断时间。
• 适应业务变化：持续修改功能和规则。
• 优化性能：通过监控和调优提升响应速度、吞吐量和资源利用率。
• 管理技术债务：重构老旧代码、升级平台，避免系统腐化。
• 保障安全合规：修补漏洞，满足安全标准和法规要求。

# 系统运行活动

# 软件维护四种类型

# 考点提炼与快速自测

# 本专题考点提炼

1. 系统规划回答 “是否值得做”，系统分析回答 “做什么”，系统设计回答 “怎么做”。
2. 系统规划五大任务：列问题、协商范围、评估价值、制定计划、汇报计划。
3. 可行性分析至少包括技术、经济、操作、法律 / 合规、进度、资源等维度。
4. 功能需求描述系统做什么，非功能需求描述质量属性和约束。
5. 好需求应一致、完整、可行、必要、正确、可追踪、可验证。
6. 七种调查研究技术要组合使用，不要只靠面谈或个人假设。
7. 系统设计分为架构设计和详细设计。
8. 分析模型偏业务，设计模型偏技术实现。
9. 高内聚、低耦合和 SOLID 是设计阶段的核心质量原则。
10. 系统编码阶段要同时关注代码实现、规范、审查、单元测试、持续集成和版本管理。
11. AI 辅助编程和低代码能提高实现效率，但不能替代质量控制和技术边界判断。
12. 测试层次包括单元、集成、系统、验收和回归测试。
13. 黑盒测试看规格和输入输出，白盒测试看内部结构和路径覆盖。
14. 测试只能发现缺陷存在，不能证明系统绝对无缺陷。
15. 系统运行侧重稳定服务，系统维护侧重修改和演化。
16. 四类维护：纠错性、适应性、完善性、预防性，其中完善性维护通常工作量最大。

# 快速自测

• 系统规划阶段为什么通常不大量引入普通用户？
• 项目范围陈述为什么重要？
• 可行性分析中经济可行性和操作可行性分别关注什么？
• 面谈、问卷、JRP、观察分别适合什么场景？
• SRS 应解决哪些问题？
• 架构设计和详细设计的区别是什么？
• 为什么设计类图不能简单照搬分析类图？
• 编码阶段为什么必须配合代码审查、单元测试和持续集成？
• 低代码平台适合哪些场景？为什么不适合高并发核心系统？
• 单元测试、集成测试、系统测试和验收测试的对象分别是什么？
• 黑盒测试和白盒测试的主要区别是什么？
• 回归测试为什么适合自动化？
• 纠错性、适应性、完善性、预防性维护分别解决什么问题？