应用生命周期流程图把一款应用从需求提出、立项评审、设计开发、测试验证、发布上线、运行维护到退役下线的全过程，按阶段、角色、交付物和决策关口串成一条可读的链路。下面给出一份演示情景下的完整示例，采用泳道式画法：横向按阶段推进，纵向按角色分工，每个阶段标注输入、输出和进入下一阶段的条件，关键节点设置评审或放行关口，并说明如何按自己组织的情况改造使用。
要点总览（TL;DR）
- 应用生命周期流程图按七个阶段展开：需求提出、立项评审、设计开发、测试验证、发布上线、运行维护、退役下线，横向排阶段、纵向排角色，每个阶段标注输入、动作、交付物和进入下一阶段的条件。
- 三个决策关口分别设在立项评审、发布上线和退役下线之前，分别对应投入决策、交付决策和退出决策；关口不通过时写明退回哪个阶段、补充什么材料。
- 测试验证与发布上线分开设置，测试结论作为发布评审的输入，发布受阻时能区分质量问题与部署问题。
- 改造时阶段可按应用类型增删，角色泳道按实际组织映射，交付物保留名称、产出角色、接收角色、完成标志四个最小字段，三个关口建议保留。
- 示例面向内部应用，对外商用产品的商业阶段、强监管行业的专项合规评审需另行补充；流程图不能替代实际的评审记录与测试报告。
示例目标：这张流程图要回答什么问题
这份示例面向需要梳理应用全生命周期协作方式的团队，包括产品负责人、研发负责人、测试与运维人员，以及负责流程建设的项目管理角色。示例设定为一款内部应用从立项到退役的完整过程，属于演示情景，不对应任何真实客户或项目，其中的角色名称、阶段划分和交付物均为示意，读者可据此对照自身情况调整。
一张合格的应用生命周期流程图，首先要回答三个核心问题：谁在什么阶段做什么、每个阶段产出什么、满足什么条件才能进入下一阶段。围绕这三个问题，流程图把分散在各角色手中的动作组织成一条可追踪的链路，让参与者在动手之前就知道自己的输入从哪来、输出交给谁、卡在哪个关口。
判断流程图是否可用，可以参考以下三条标准：
- 阶段完整且边界清晰：从需求提出到退役下线的主要阶段都有位置，每个阶段的起止条件明确，不出现两个阶段职责重叠或中间断档。
- 角色与交付物可对应：每条泳道上的角色都能找到自己负责的动作和交付物，交付物有明确的接收方，避免出现无人认领的环节。
- 关口有判断依据：每个评审或放行关口都写清了检查什么、由谁决定、不通过时回到哪里，流程图因此具备可执行性，而不只是一张阶段示意图。
完整示例：一款内部应用从立项到退役的流程图
示例按七个阶段展开：需求提出、立项评审、设计开发、测试验证、发布上线、运行维护、退役下线。泳道角色设定为业务提出方、产品负责人、研发、测试、运维、评审委员会六类。下面先用表格呈现阶段、角色、输入输出与关口，再给出可直接转成图形的文字化流程结构。
| 阶段 | 主要负责角色 | 输入 | 主要动作 | 输出交付物 | 进入下一阶段的条件 |
|---|---|---|---|---|---|
| 需求提出 | 业务提出方、产品负责人 | 业务问题描述、使用场景 | 收集诉求、初步澄清范围、判断是否值得立项 | 需求意向说明、初步价值判断 | 产品负责人确认诉求成立并提交立项申请 |
| 立项评审 | 评审委员会、产品负责人 | 需求意向说明、初步方案与资源估算 | 评审目标、范围、投入与风险，决定是否启动 | 立项决议、项目范围基线 | 评审委员会通过，或退回补充材料 |
| 设计开发 | 产品负责人、研发 | 立项决议、范围基线 | 需求细化、方案设计、编码实现、单元自测 | 需求说明、设计文档、可运行版本 | 开发完成并通过代码评审与自测 |
| 测试验证 | 测试、研发 | 可运行版本、需求说明与设计文档 | 编写测试用例、执行功能与回归测试、跟踪缺陷 | 测试报告、缺陷清单、验证结论 | 关键缺陷关闭，测试结论为通过 |
| 发布上线 | 运维、研发、产品负责人 | 测试报告、发布方案与回滚预案 | 发布评审、部署上线、上线验证 | 发布记录、上线确认单 | 发布评审通过且上线验证无阻断问题 |
| 运行维护 | 运维、研发、产品负责人 | 上线确认单、监控与反馈渠道 | 监控运行状态、处理故障与变更、收集使用反馈 | 运维记录、变更记录、迭代需求 | 应用持续可用，或触发退役评估 |
| 退役下线 | 产品负责人、运维、评审委员会 | 退役申请、替代方案与数据处置说明 | 退役评审、数据迁移或归档、下线操作 | 退役决议、下线记录、归档清单 | 评审通过并完成下线与归档 |
将上表转成泳道图时，横向从左到右排列七个阶段，纵向自上而下排列六条角色泳道。文字化流程结构如下，可直接照着画：
- 业务提出方泳道：需求提出（提交需求意向）→ 在立项评审中说明业务价值 → 在运行维护阶段反馈使用问题。
- 产品负责人泳道：需求提出（整理并提交立项申请）→ 立项评审（答辩与补充材料）→ 设计开发（细化需求、评审设计）→ 测试验证（确认验收标准）→ 发布上线（确认发布范围）→ 运行维护（收集反馈、提出迭代或退役）→ 退役下线（发起退役申请）。
- 研发泳道：设计开发（方案设计、编码、自测）→ 测试验证（修复缺陷）→ 发布上线（配合部署与验证）→ 运行维护（处理故障与变更）。
- 测试泳道：测试验证（编写用例、执行测试、出具报告）→ 发布上线（参与发布评审）。
- 运维泳道：发布上线（部署与上线验证）→ 运行维护（监控、故障响应、变更执行）→ 退役下线（执行下线与数据归档）。
- 评审委员会泳道：立项评审（决策关口一）→ 发布上线（决策关口二）→ 退役下线（决策关口三）。
三个决策关口分别设在立项评审、发布上线和退役下线之前。关口一不通过时，退回需求提出阶段补充材料或终止诉求；关口二不通过时，退回测试验证阶段修复问题后重新提交；关口三不通过时，退回运行维护阶段继续运行或补充退役方案。测试验证中发现的问题回流至设计开发，形成开发与测试之间的迭代回路；运行维护中出现的重大缺陷同样回流至设计开发，按变更流程处理。
逐项解释：每个阶段和关口为什么这样设
在立项和发布前设关口，原因在于这两个节点是投入和风险变化最大的位置。立项评审决定是否投入人力与时间，把评审放在开发之前，可以让范围、目标和资源在动手前达成一致，避免方向偏差后返工。发布上线前的关口则把测试结论、发布方案和回滚预案放在一起检查，确保上线动作有依据、有退路。两个关口一个管“要不要做”，一个管“能不能上”，职责不同，不能合并。
测试验证与发布上线分成两个阶段，是因为两者的目标和责任角色不同。测试验证关注“做出来的东西是否符合需求”，由测试主导、研发配合；发布上线关注“能否安全地交付到使用环境”，由运维主导、研发与产品负责人配合。分开设置后，测试结论成为发布的输入，发布评审可以独立判断风险，也便于在发布受阻时清楚地区分是质量问题还是部署问题。
运行维护阶段需要持续跟踪的对象包括：应用可用性与故障记录、变更与配置调整、用户反馈与使用数据、待处理的迭代需求。这些对象既是日常运维的依据，也是触发退役评估的信号。把它们纳入流程图，可以让运行维护阶段有明确的产出，而不是停留在“上线后有人管”的模糊状态。
退役下线作为独立阶段，是因为下线同样涉及评审、数据处置和多方确认。应用停止使用后，数据需要迁移或归档，依赖它的其他系统需要解绑，账号与资源需要回收。把这些动作放进一个独立阶段并设置关口，可以避免应用被悄悄停用而留下数据和安全遗留问题。
异常回退路径的设计考虑在于让流程图具备纠错能力。评审不通过、测试发现缺陷、上线后出现阻断问题，都需要有明确的回流目标，否则参与者只能自行判断下一步，流程就会失去约束力。回退路径同时要写明回流后需要补充什么材料、由谁重新确认，保证每一次回流都能推动问题收敛。
可迁移规律：换成自己的应用怎么改
阶段可以按应用类型增删。例如以数据服务为主的应用，可以在设计开发与测试验证之间增加数据准备与校验环节；以外部集成为主的应用，可以增加接口联调阶段。阶段名称和数量可以调整，立项、发布、退役三个关口建议保留，它们分别对应投入决策、交付决策和退出决策，是生命周期中风险最集中的位置。
角色泳道按实际组织映射。小团队中一人兼任多个角色时，不必为每个角色单独画一条泳道，可以把兼任关系写在泳道名称中，例如“产品负责人（兼测试）”，并在动作标注中区分该角色在不同阶段承担的不同职责。关键是每个动作都能落到具体的人或岗位，避免出现“大家都负责、实际无人负责”的泳道。
交付物字段保留最小集合即可支撑流程图运转：交付物名称、产出角色、接收角色、完成标志。需要追溯时再补充版本号、关联需求编号和评审结论。字段过多会让流程图变成表格负担，字段过少则无法判断阶段是否真正完成。
流程图落到日常协作时，需要与工作项状态和文档状态对应起来。下面的对照表给出一种常见的映射方式，可按团队实际使用的工具调整：
| 流程阶段 | 工作项状态示例 | 文档状态示例 | 关口记录 |
|---|---|---|---|
| 需求提出 | 待评估 | 草稿 | 无 |
| 立项评审 | 评审中 | 待评审 | 立项评审结论 |
| 设计开发 | 进行中 | 已发布 | 设计评审记录 |
| 测试验证 | 测试中 | 测试报告已归档 | 测试结论 |
| 发布上线 | 待发布 / 已发布 | 发布方案已确认 | 发布评审结论 |
| 运行维护 | 运维中 | 变更记录持续更新 | 变更审批记录 |
| 退役下线 | 已关闭 | 归档完成 | 退役评审结论 |
从流程图到日常协作的衔接，可以从三件事入手：把每个阶段的交付物建成可追踪的工作项或文档，把关口结论作为状态流转的必要条件，把回退路径写成明确的退回状态而不是口头约定。这样流程图就不只是墙上的一张图，而是团队每天在用的协作规则。ONES 的方案覆盖需求、基线、版本、变更、测试与发布，并通过关联关系把需求变化与受影响的任务、测试和交付内容连接起来，适合承载这类阶段与关口的落地；标准流程、评审节点和交付物模板也可以沉淀为可复用资产，减少每个项目重复搭建的成本。
适用边界：哪些情况不适合直接套用
这份示例面向内部应用，覆盖的是从立项到退役的研发与运维协作过程。对外商用产品还涉及市场推广、定价、营收等商业阶段，这些内容不在本文范围内，需要另行补充商业侧流程。如果应用同时服务内部与外部用户，建议在发布上线和运行维护阶段增加面向外部用户的服务承诺与支持流程。
强监管行业的应用，例如涉及金融、医疗、个人信息处理的场景，通常有额外的合规评审、安全评估和审计要求。示例中的三个关口可以作为基础框架，但不能替代这些专项评审，需要在对应阶段插入合规检查点，并明确检查依据和责任人。
小团队可以简化流程，例如合并设计开发与测试验证的部分动作、减少评审参与人，但立项、发布、退役三个关口不建议取消。关口的作用是让关键决策有记录、有责任人，简化应体现在评审形式和材料篇幅上，而不是跳过决策本身。
流程图是协作工具，用来对齐阶段、角色和交付物，不能替代实际的评审记录、测试报告和变更审批。评审是否通过、缺陷是否关闭、数据是否归档，都需要在具体的工作项和文档中留下记录。流程图给出的是“应该怎样流转”，记录证明的是“实际怎样流转”，两者配合使用，流程才具备可追溯性。
常见问题
小团队人手少，能不能把立项评审和发布评审合并成一个关口？
可以合并评审会议，但建议保留两次判断。立项评审回答的是“要不要投入”，发布评审回答的是“能不能上线”，两者依据的材料和风险点不同。人手紧张时，可以让同一批人参与两次评审，材料篇幅压缩到一页，判断结论仍分别记录。合并成一次判断，容易出现立项时没想清楚范围、上线时又缺少测试结论支撑的情况。
流程图里的阶段和团队现有工作项状态对不上，应该改图还是改状态？
先看差异出在哪里。如果只是状态名称不同，调整映射表即可，不必改动流程图；如果某个阶段在现有工具里找不到对应的状态，说明流程缺少承载位置，需要补充状态或调整阶段划分。建议以流程图为准梳理状态，把每个关口的结论设为状态流转的必要条件，避免状态名称很多但关键决策没有记录。
应用退役后数据怎么处理，流程图里要写到什么程度？
流程图层面写清三件事即可：退役申请由谁发起、评审看哪些材料、下线后数据迁移或归档到哪里。具体的数据保留期限、销毁方式和合规要求，属于数据管理制度的范围，可以在退役阶段的交付物中引用相应制度文件，不必在流程图里展开。涉及个人信息或受监管数据时，建议在退役评审中增加数据处置的确认环节。
流程图画好之后，怎么让团队真正按它执行？
可以从三处衔接：把每个阶段的交付物建成可追踪的工作项或文档，把关口结论作为状态流转的必要条件，把回退路径写成明确的退回状态。ONES 的方案覆盖需求、基线、版本、变更、测试与发布，并通过关联关系把需求变化与受影响的任务、测试和交付内容连接起来，适合承载阶段与关口的落地；标准流程、评审节点和交付物模板也可以沉淀为可复用资产，减少每个项目重复搭建的成本。
对外交付的商用应用，这张图要补哪些内容？
本文示例覆盖研发与运维协作过程，商用应用还需要补充商业侧流程，例如市场推广、定价与营收相关的阶段，这些不在本文范围内。此外，面向外部用户时，建议在发布上线和运行维护阶段增加服务承诺、用户支持与问题响应流程，并明确对外沟通的责任人。
