夜雨聆风引子：软件也有生老病死
大家好，我是小高。
上一期我们聊了五种生命周期模型，很多同学看完之后意犹未尽，问我："那软件到底是怎么从无到有、又从有到无的呢？中间要经历哪些阶段？"
问得好。这就是今天的主题——软件生命周期的六个核心阶段。
说起来，软件其实跟人一样，也有自己的"生命周期"：出生（需求）、成长（设计）、成熟（编码）、独立（测试）、融入社会（部署），然后工作很多年（运维），最后退休（退出）。
听起来有意思吧？那我们一个个阶段来盘它。
一、需求过程——万丈高楼平地起
需求过程是软件生命周期中最最重要的阶段，没有之一。
很多项目出问题，不是编码写得烂，而是需求就没搞清楚。需求阶段搞砸了，后面所有阶段都是在填坑。
需求过程的四个子活动
需求获取（Elicitation）：到用户那里去，了解他们真正想要什么。注意：是"真正想要"，不是"说出来想要"。很多用户说"我要一个很牛的系统"，这不叫需求，这叫愿景。你要通过访谈、观察、工作坊等方式，挖掘出具体的、可实现的需求。
需求分析（Analysis）：把获取到的需求进行整理、归类、优先级排序，找出需求之间的冲突和不一致。比如用户A说"系统要快"，用户B说"系统要安全"，这两者有时候是矛盾的，就需要权衡。
规格说明书编制（Specification）：把分析后的需求写成正式的文档——《需求规格说明书》（SRS）。这份文档是后续所有阶段的"宪法"，是判断"系统做对了没有"的标准。
需求验证与确认（Validation & Verification）：
验证（Verification）：我们做的东西符合规格吗？（Are we building the product right?） 确认（Validation）：规格本身是对的、符合用户真实需要的吗？（Are we building the right product?）
需求过程的交付物
需求规格说明书（SRS） 需求跟踪矩阵（RTM）——把每个需求和后续的设计、编码、测试对应起来，确保没有遗漏 需求模型（用例图、流程图等）
软考真题怎么考？
【2020年上半年·第35题】需求规格说明书的主要内容不包括（ ）。A. 质量功能部署 B. 功能需求 C. 非功能需求 D. 约束条件答案：A解析： 需求规格说明书主要描述功能需求、非功能需求和约束条件，质量功能部署（QFD）是质量规划阶段使用的工具。
二、架构设计——给软件建骨架
如果说需求是"这栋楼要住多少人、有什么功能"，那么架构设计就是"这栋楼的结构怎么搭、承重墙在哪儿、管道怎么走"。
架构设计要解决的核心问题
系统分解：把系统拆成哪些子系统/模块？ 技术选型：用什么语言、框架、数据库、中间件？ 接口定义：模块和模块之间怎么通信？ 数据建模：数据怎么存储、怎么流转？ 质量属性：系统要满足什么性能、安全性、可用性要求？
常见的架构风格
分层架构：表现层→业务逻辑层→数据访问层（最经典） 微服务架构：把系统拆成多个独立部署、独立运行的小服务 事件驱动架构：通过消息队列异步处理业务 面向服务的架构（SOA）：服务之间通过标准接口通信
架构设计的交付物
架构设计说明书 系统的技术架构图 数据字典 接口设计文档
三、软件实现——把蓝图变成代码
软件实现阶段，工程师们终于要"真刀真枪"地写代码了。这个阶段主要包括三件事：配置管理、编码、测试。
1. 配置管理
软件实现过程中，会产生大量的代码、文档、模型、数据……这些东西就是配置项（Configuration Item）。配置管理的核心任务是：
识别配置项：哪些东西需要纳入配置管理？ 版本控制：每次修改都有记录，可以追溯到任何一个历史版本 基线（Baseline）：在关键节点建立基线，之后的变更要走正式变更流程
2. 编码
编码不是"把设计文档翻译成代码"那么简单。好代码要：
可读性好：别人能看懂 可维护：改起来方便 经过 Code Review：别人帮你检查过 遵守编码规范：命名、注释、格式统一
3. 测试
这个阶段做的测试主要是单元测试（Unit Testing）和集成测试（Integration Testing）。
单元测试：测试最小的代码单元（通常是函数/方法）是否正确工作 集成测试：把多个单元组合在一起，测试它们之间的接口是否正常
软考真题怎么考？
【2019年上半年·第33题】在软件实现过程中，配置管理的作用不包括（ ）。A. 记录软件变更 B. 统一控制软件变更 C. 分析变更的影响 D. 满足用户新的需求答案：D解析： 配置管理的作用是记录、控制和分析变更影响，AB C都是，"满足用户新需求"是需求工程的事，不是配置管理的职责。
四、部署交付——软件走向用户
软件做好、测试通过之后，就要交给用户使用了。部署交付是软件生命周期中**从"内部产品"变成"外部商品"**的关键阶段。
部署的三个层次（Build-Ship-Run）
现代软件部署通常分为三个层次：
Build（构建）：把源代码编译、打包成可部署的产物 Ship（交付）：把产物发送到目标环境 Run（运行）：在目标环境启动和运行软件
持续交付 vs 持续部署
这是两个非常容易混淆的概念，考试经常考：
持续交付（Continuous Delivery，CD）：代码每次合并到主干后，自动完成构建、测试、打包，但不自动部署到生产环境。部署到生产需要人工确认。 持续部署（Continuous Deployment，CD）：代码每次合并到主干后，自动完成构建、测试、打包，并自动部署到生产环境，全程无人干预。
简单说：持续部署比持续交付更激进，连"人确认"这一步也省了。
部署策略
蓝绿部署（Blue-Green Deployment）：准备两套完全相同的环境，一套运行旧版本（蓝），一套部署新版本（绿）。切换时，把流量从蓝切到绿，出现问题可以秒级回滚。 金丝雀部署（Canary Deployment）：先让新版本接受少量流量（比如5%），观察没问题再逐步扩大比例。 滚动部署（Rolling Deployment）：逐批替换旧版本实例。
部署交付的交付物
部署手册 运维手册 上线报告 培训材料
五、运行维护——软件的一生都在被伺候
软件上线了，并不意味着生命周期结束了。相反，运行维护阶段往往占据软件整个生命周期70%以上的时间和成本。
运行维护的四种类型
纠正性维护（Corrective Maintenance）：修Bug——系统出错了，把它改对 适应性维护（Adaptive Maintenance）：适应环境变化——比如操作系统升级了、第三方接口变了，软件需要相应调整 完善性维护（Perfective Maintenance）：优化性能、完善功能——用户用了之后发现某些地方不好用，需要改进 预防性维护（Preventive Maintenance）：防患于未然——主动排查隐患，降低未来出问题的概率
运维的核心指标
RTO（Recovery Time Objective）：灾难发生后，系统恢复到正常运行需要多长时间？ RPO（Recovery Point Objective）：灾难发生后，允许丢失多长时间的数据？
六、退出——软件的优雅谢幕
最后一个阶段往往被忽视——软件也是有"退休"的时候的。
软件退出的触发条件
产品生命周期结束，不再有新版本 被新系统完全替换 业务停止，系统不再需要 合规要求变化，系统无法满足
退出阶段要做的事
数据迁移：把历史数据迁移到新系统或归档存储 数据归档：按照法规要求，保存必要年限的数据 资源释放：释放服务器、域名、证书、云资源等 知识转移：把运维经验、特殊处理逻辑等文档化，移交给相关团队 正式停运：关闭系统，发布停运公告
七、V模型——开发与测试的完美对应
讲完六个阶段，不得不提V模型。V模型是软件工程里描述开发阶段和测试阶段对应关系的经典模型，左边是开发，右边是测试，像个V字。
V模型各阶段对应关系
需求获取 ←→ 验收测试（用户验收）系统设计 ←→ 系统测试（整个系统是否符合需求）架构设计 ←→ 集成测试（模块间接口是否正常）模块设计 ←→ 单元测试（每个模块是否正确） ↓ 编码实现V模型的核心启示
越早引入测试，成本越低、效果越好。Bug发现得越晚，修复代价越高。单元测试在编码阶段就做，是最便宜的测试；验收测试在最后做，是最贵的测试。
软考真题怎么考？
【2022年上半年·第34题】在V模型中，需求规格说明验证对应的是（ ）。A. 单元测试 B. 集成测试 C. 系统测试 D. 验收测试答案：C解析： V模型中，需求规格说明对应验收测试，系统设计对应系统测试，架构设计对应集成测试，模块设计对应单元测试。注意验收测试对应的是最初的需求获取阶段（最上层的用户需求）。
一句话口诀
口诀二："需求获取分析规格书，验证确认不可少；架构设计定骨架，编码实现写代码；部署交付走CD/CD，运维退出别忘掉；V模型左开发右测试，需求对应验收顶呱呱。"
解析：
需求工程四个子活动（获取、分析、规格说明、验证确认）缺一不可； 持续交付（CD）和持续部署（CD）的区别：交付不自动部署生产，部署连确认这一步也省了； V模型的核心记忆方法：需求对应验收测试（顶层对顶层），设计各层对应测试依次往下，单元测试对应模块设计（底层对底层）。
正在备考软考高项？持续关注，持续更新，系统化搞定软件生命周期 🚀
