045_赣中某省级汽车维修电子健康档案系统信息系统项目开发方法与生命周期绩效域

ONEPSOFT | 软考学习知识库

---

摘要

本文以赣中某省级汽车维修电子健康档案系统信息系统项目为例，按规划、执行、监控的过程主线论述开发方法与生命周期绩效域。该项目由该地区交通运输主管部门发起，合同额 720.46 万元，2024 年 5 月启动，建设周期 8 个月，团队高峰期 22 人，采用低代码平台、微服务网关、OceanBase 与 RocketMQ 构建，前端 Vue3 与 TypeScript、后端 Java 17 与 Spring Boot 开发，我担任项目经理。针对存量老系统接口文档缺失、第三方厂商交付质量参差、建设期政策调整三个难点，我以检查表、分层抽样与因果图为支撑，确定了多次交付的节奏与增量为主、局部迭代的混合开发方法。项目于 2025 年 1 月通过终验，预警事件平均处置时长缩短 55%，资金结算差错连续 12 个月零发生，系统可用率稳定在 99.9% 以上，全年重大故障 0 起。

一、项目概况与我承担的工作

该省汽车保有量逾千万辆，维修企业数以万计，但车辆维修记录长期散落在各家门店的本地台账里，二手车交易时买家无从核验真实维修历史，监管部门也难以掌握配件溯源与竣工质检情况。为建立覆盖全省的汽车维修电子健康档案，该地区交通运输主管部门作为建设单位发起本项目，我方经公开招标中标承建，我被任命为项目经理。

系统建设内容包括维修企业备案、维修工单归集、配件溯源、竣工质检与档案查询五个模块。技术实现上，采用低代码平台承载备案表单与监管报表的快速构建；后端服务经微服务网关统一接入、鉴权与限流；海量工单数据持久化于 OceanBase 分布式数据库；工单归集与预警通知由 RocketMQ 异步驱动；前端采用 Vue3 与 TypeScript 开发，后端基于 Java 17 与 Spring Boot 框架。系统部署于省级政务云信创环境，服务器与操作系统均为国产化产品，应用中间件采用东方通 TongWeb。

交付成果包括系统源代码与部署包；需求规格、概要与详细设计、数据库与接口规范等文档；测试方案与测试报告；存量维修数据迁移与比对记录；上线与回退预案；面向监管人员、维修企业、检测机构三类角色共 8 场培训；以及 12 个月免费运维支持。

项目采用项目型组织，高峰期 22 人、常态 18 人，下设需求组、开发组、集成实施组、测试组与实施推广组，另配专职配置管理员 1 名负责配置项标识与版本基线，质量保证人员 1 名。我作为项目经理全面负责开发方法的选择、生命周期的划分与各阶段交付节奏的把控。下面按规划、执行、监控三个层面展开论述。

二、规划阶段：确定生命周期、交付节奏与开发方法

规划开发方法与生命周期是根据项目特征选择合适的开发方法、划分生命周期阶段并确定交付节奏的过程，其作用在于为后续全部管理动作确立基本节拍。

关于交付节奏。交付节奏描述的是可交付成果在何时、以何种频率交付给客户，常见形式有单次交付、多次交付、周期交付与持续交付四种；需要特别区分的是，增量型与迭代型属于开发方法的分类，并不是交付节奏的分类，二者常被混为一谈。本项目工期仅 8 个月，而业务政策在建设期内存在调整可能：若采用单次交付，一旦政策变化就会全盘返工；若采用持续交付，又与政务系统等保测评和上线审批的固定周期不匹配。经与建设单位共同评估，我们最终选择多次交付，把 8 个月切分为三次：第一次在第 3 个月末交付企业备案与工单归集，第二次在第 6 个月末交付配件溯源与竣工质检，第三次在第 8 个月末交付档案查询、监管报表与全量数据迁移。每一次交付都是可独立投产的完整业务闭环，政策若在中途调整，影响面被限制在尚未开工的后续批次。

关于开发方法。本项目的监管报表与档案查询类需求相对明确，适合预测型推进；而配件溯源规则与政策强相关、需要反复打磨，更适合迭代收敛。因此我确定以增量型为主、在配件溯源模块局部采用迭代型的混合开发方法：增量保证每次交付都有可用成果，迭代保证不确定的部分能在若干轮次内稳定下来。生命周期据此划分为立项、需求与设计、三轮增量开发与测试、试运行、验收五个阶段，详见表 1。节拍既已确定，接下来就是如何在执行中把它兑现。

三、执行阶段：开发方法与生命周期的落地

执行是按既定开发方法与交付节奏产出可交付成果的过程，其作用在于把纸面上的节拍变成现实的交付物。

第一个障碍是存量老系统接口文档缺失、改造边界难以厘清，边界不清则第一次交付无从谈起。我采用检查表逐项清点：把与存量系统相关的事项拆成数据表、接口、定时任务、报表、权限、外部依赖 6 类共 54 项，逐项标注 " 有无文档、能否联通、由谁负责、本期是否改造 "，组织原厂运维与我方开发共同确认并签字。清点结果显示，54 项中有 19 项无任何文档、7 项实际已停用。据此我把 19 项无文档接口中的 12 项排除出本期范围、改为通过数据库视图旁路取数，只保留 7 项必须改造的接口，第一次交付的边界因此在两周内锁定。

第二个障碍是第三方厂商交付质量参差、集成测试反复返工。第二次交付前，来自三家厂商的模块连续三轮未通过集成测试。我采用分层抽样开展交付物核查：按厂商分层，每家随机抽取 10% 的接口用例与代码提交进行走查，结果显示 A 厂商用例通过率 91%、B 厂商 86%、C 厂商仅 62%。数据摆明之后，我要求 C 厂商增派人员并接受我方每日走查，同时对其提交物实行抽检不合格即整批退回。

为找出返工反复的根因，我绘制因果图，从人、机、料、法、环五个方面展开：人——厂商开发人员对监管业务不熟；机——各厂商本地环境与集成环境版本不一致；料——接口规范存在多个流传版本；法——缺少提交前的自检门槛；环——集成窗口集中在交付前两周，问题集中堆积。根因判定为 " 机 " 与 " 法 "。对策是统一提供容器化的标准集成环境镜像，并设置提交前必须通过的自检清单，未通过者不得进入集成排期。整改后集成测试一次通过率由 62% 提升至 94%，第二次交付如期完成。

四、监控阶段：绩效度量与偏差纠正

监控开发方法与生命周期绩效域是持续评估既定节奏与方法是否依然适用并及时调整的过程，其作用在于避免计划定了之后就不再回头检视。

我为本绩效域设定三项度量指标：交付批次按期率、增量交付物一次验收通过率、需求变更对已交付批次的影响件数，每两周在项目看板上展示。第 5 个月，上级出台新的竣工质检抽查比例要求，属于典型的建设期政策调整。度量数据显示，该变更仅影响第二次交付中尚未开工的 2 个工作包，对已交付的第一批次零影响——这正是多次交付带来的隔离效果。我随即在第二次交付内部增加一轮迭代吸收政策变化，交付时点保持不变。全程三次交付均按期完成，未发生批次顺延。

五、项目经理需要重点关注的内容

结合本项目实践，我认为要有效执行开发方法与生命周期绩效域，项目经理应重点关注五个方面，详见表 2。

其一，关注项目与产品特征的匹配。需求确定性高的部分用预测型推进，不确定性高的部分预留迭代轮次，不能一刀切。其二，关注交付节奏与组织审批节奏的匹配。政务类项目的等保测评、上线审批本身有固定周期，交付批次必须与之对齐，否则做完了也上不了线。其三，关注每个批次的可独立投产性。多次交付如果切出来的批次不能独立使用，就退化成了单纯的阶段划分，失去了隔离政策风险的意义。其四，关注干系人对节奏的认知一致。我在每次交付前 3 周就发布交付内容清单与验收要点，避免建设单位误以为本次会交付全部功能。其五，关注度量与回顾。每批次交付后组织一次回顾会，把暴露的问题转化为下一批次的改进项，本项目三次回顾共形成 17 条改进措施，标准集成环境镜像正是来自第一次回顾。

六、结项成效与心得体会

本项目 2024 年 5 月启动，7 月末完成第一次交付，10 月末完成第二次交付，12 月末完成第三次交付并进入试运行，2025 年 1 月通过终验，全程 8 个月，与合同工期一致。核心成效为：预警事件平均处置时长缩短 55%；资金结算差错连续 12 个月零发生；系统可用率稳定在 99.9% 以上，全年重大故障 0 起。

回顾全程，我有三点体会。第一，交付节奏的选择本质上是风险切分，把 8 个月切成三次交付，政策调整的冲击被限制在单个批次之内，这比事后再做变更控制主动得多。第二，边界不清时不要急着开工，检查表 54 项逐条签字看似耗时，却把无文档接口的隐性工作量在开工前就暴露并剥离了出去。第三，对外部交付质量的管理必须用数据说话，分层抽样把 62% 这个数字摆到台面上，因果图再把根因指向环境不一致与自检门槛缺失，整改才有抓手；这套 " 抽样定位—因果溯源—机制固化 " 的组合，同样适用于质量管理与采购管理领域。只有把开发方法、生命周期与交付节奏三者协调一致，全省维修档案的数据链条才能在紧张工期内如期贯通。

表 1 生命周期阶段与交付节奏安排

交付批次	时点	交付内容	开发方法	独立投产能力
第一次交付	第 3 个月末	维修企业备案、维修工单归集	增量型	可独立支撑企业备案与工单上报
第二次交付	第 6 个月末	配件溯源、竣工质检	增量型为主，溯源规则局部迭代	可独立支撑配件与质检监管
第三次交付	第 8 个月末	档案查询、监管报表、全量数据迁移	增量型	可独立支撑公众查询与监管分析

表 2 项目经理在本绩效域的关注要点

关注方面	本项目具体做法
特征与方法匹配	报表查询类用预测型推进，配件溯源预留迭代轮次
节奏与审批对齐	三个交付批次对齐等保测评与上线审批周期
批次可独立投产	每批次均构成完整业务闭环，可单独投入使用
干系人认知一致	交付前 3 周发布交付内容清单与验收要点
度量与回顾	三项指标双周看板展示，三次回顾会共产出 17 条改进措施