产品类型实践 · 软件生命周期 · 2026-08-20

软件生命周期实践
我们的研发流程现状与经验教训

小八弟 · 网站/应用类软件产品 · 分类实践篇(参照 ISO/IEC/IEEE 12207)

← 返回 软件生命周期板块
一句话导读
本工作区(Claw)实际上已经跑完一条完整的软件生命周期链——春哥需求 → G0 前置文件 → 开发/生成 → 五连门禁 → 部署 → 线上核验 → 运维迭代。对照 ISO/IEC/IEEE 12207 的过程地图,我们发现:过程都在,只是以前没给它们挂标准名号。这篇梳理现状、找差距、记经验教训。

一、现状:我们的实际流程(🟢 本机实测)

阶段我们的实际动作12207 对应过程
需求春哥口头/文字需求 → 需求规格(G0,含 P1/P2/P3 平台引用确认)业务分析 / 需求分析
架构架构设计(G0)→ 目录/数据流/生成器方案架构设计
实现手写页面 + 脚本生成(gen_site/gen_vocab 等)+ 数据文件实现
验证五连门禁(check_spec_versions / tag_zones / check_zones / test_links / check_dualsync)验证
确认春哥验收 + 线上核验(HTTP 200 + 内容比对)确认
交付/运维deploy_site.py 部署(打包→备份→上传→孤儿清理→全量验证)→ 线上巡检交付 / 运行 / 维护
配置管理版本记录 + 快照 + CHANGELOG(铁律8 登记纪律)配置管理
风险管理信号灯(🟢/🟡/🔴)+ 部署护栏 + CVE 跟踪风险管理
度量门禁记录留档(record_gates.py → docs/门禁记录.md)度量

二、经验教训(踩过的坑)

教训 1:验证 ≠ 确认,两个都要做
12207 明确把「验证(做对了没)」和「确认(做的是不是用户要的)」分成两个过程。我们曾只重验证(门禁全绿就以为完事),结果出现过:门禁过了但内容不是春哥要的(如对比页卡片重复、导航描述过时)。现在的做法:门禁=验证,春哥验收+线上内容核验=确认,缺一不可。
教训 2:配置管理的「版本受控」是底裤
曾出现规范文件多版本并存、引用版本号不一致的混乱(v1.6.1 全库清理)。12207 的配置管理三件套——版本标识、基线、变更记录——正是解药:versions.json 注册表 + 单一来源(md 派生 html)+ 变更记录,现在引用错误会被 check_spec_versions 直接拦下。
教训 3:部署也是生命周期的一部分,不是「发完就完」
本周两次部署验证误报(缺凭据)和一次服务器备份堆积 5.1G,都是「交付/运维」环节欠账。12207 的运行/维护过程提醒我们:部署脚本、备份策略、凭据管理、磁盘水位都属于系统生命周期,要有命名、有检查。

三、行业现状对照

行业里常见的生命周期实践形态(🟡 基于公开资料归纳):

我们的位置:介于「轻量敏捷」与「DevOps」之间——已有部署流水线(deploy_site.py)和门禁(CI 精神),但缺可观测性(运行监控、日志聚合)与度量闭环(门禁趋势刚起步)。

四、下一步改进(按性价比)

  1. 给流程显式命名:把「G0→门禁→部署→核验」映射到 12207 术语,形成一页流程卡(沟通成本骤降);
  2. 部署运维制度化:deploy_site.py 加自动清理旧备份(保留 5 个)+ 部署前强制凭据检查;
  3. 度量闭环:门禁记录跑满 4 周形成趋势,向 CMMI L4 靠(量化管理);
  4. 退役过程:给「下线/归档」定规则(如 filebrowser CVE 归档倒计时这类事件,要有处置流程)。
⚠️ 实践篇(🟢 现状为本机实测 / 行业现状为 🟡 公开资料归纳),标准对照以官方文本为准。