软件开发

业务系统定制：客户管理、项目管理、报价与合同、库存与工单等；按实际流程做，不套模板。

官网与小程序：企业官网、内容管理、微信小程序与公众号对接。

系统对接：把门禁、监控、停车、能耗等硬件系统的数据接进统一平台（按厂家开放接口或网关抓取）。

Web 常用 Node.js/TypeScript 与主流前端框架，数据库用 MySQL/PostgreSQL；小程序按微信官方技术栈。

对接优先走厂家提供的开放 API/SDK；没有开放接口时用网关或数据库只读视图，并明确数据责任边界。

交付物：需求说明、接口文档、部署说明、源代码与数据库脚本。**文档清单本身没有国标可套，按合同约定**——把清单写进合同比事后争论有用。

软件过程依据 **GB/T 8566-2022《系统与软件工程 软件生存周期过程》**（2022-10-14 发布、2023-05-01 实施，采用国际标准）。

质量模型参考 **GB/T 25000.10-2016《系统与软件工程 系统与软件质量要求和评价（SQuaRE）第 10 部分：系统与软件质量模型》**。

合规：涉及个人信息处理的，遵循《中华人民共和国个人信息保护法》与《数据安全法》；**具体条文以官方正式文本为准**。

**软件交付没有可以套用的「国家标准号」验收表**：按双方确认的需求文档与接口文档验收，这是行业通行做法。

可用性的通用定义是 **A = MTBF ÷ (MTBF + MTTR)**（平均无故障时间 ÷（平均无故障时间 + 平均修复时间））。**它的意义在于把「稳定」变成可约定的数字**：只写「系统要稳定」等于没约定。

**常见可用性目标对应的允许不可用时长（按 365 天/年、30 天/月计算）**：

需求阶段的目标是把「要什么」写成可验证的条目，而不是一段描述性文字。需求清单建议逐条包含：使用角色与权限、涉及的数据项与字段含义、主要操作流程与页面路径、异常与边界处理（数据为空、重复提交、并发修改、权限不足）、以及这一条的验收标准。凡是无法写成「输入什么、期望输出什么」的条目，都说明还没谈清楚，应继续澄清而不是先开工。

接口契约要在开发前定稿，内容包括：接口地址与调用方式、请求与响应字段及类型、必填与选填、错误码与错误语义、分页与限流约定、鉴权方式、以及超时与重试策略。对接第三方系统时，先确认对方是否提供开放接口、接口的版本与稳定性、调用频次与数据使用边界；没有开放接口而只能读数据库或抓页面时，要明确这种方式的稳定性风险与责任边界，并写进合同。

变更要走流程：任何需求或接口变更都应以书面变更单提出，写明变更内容、影响范围（是否影响已完成的开发与测试）、工期与费用影响，双方确认后再进入开发。实践中返工最集中的环节不是写代码，而是接口字段口径中途变化——口头或聊天记录里说的改动，不应直接进入开发。

上线不是把代码推上去就结束，而是一次有预案、有责任人、可回退的变更。上线前要明确四个要素：回滚点（回滚到哪个版本、回滚包或镜像放在哪里、由谁执行）、变更窗口与影响范围（哪些功能会短暂不可用）、验证清单（上线后按什么顺序验证哪些关键功能）、以及决策人（出现异常时由谁决定回滚还是继续）。

回滚不只是回退程序，还要考虑数据。数据库结构变更通常不可逆：加字段一般可回滚，改字段类型、删除字段、数据清洗则难以还原。可行的做法是先备份、再执行变更脚本，并把变更脚本与回退脚本成对准备（能回退的写回退脚本，不能回退的在方案里明确标注并提前告知）；涉及数据的操作禁止手工在正式库里直接改，必须通过脚本执行并留记录。

责任分工要落实到人：谁做备份、谁执行脚本、谁验证功能、谁有权决定回滚。上线后应保留一段观察期，重点看错误日志、关键接口成功率与业务数据是否正常。常见问题是在上线窗口内匆匆执行完数据库变更，却没有预留回滚时间——变更本身要控制在窗口能够覆盖的范围内，超出就拆成多次上线。

没有验收标准：需求只写「实现订单管理功能」，没有可执行的验收清单，交付时双方各自理解「做完了」，最后靠扯皮收尾。可行的办法是把验收标准写到条目级，并在开发过程中同步维护一份验收用例，交付前双方按用例逐条走。

权限过大：为了赶工期，账号直接给管理员权限，或者把权限判断只做在前端。正确做法是后端强制鉴权、按角色最小化授予、敏感操作二次确认并留操作日志。日志缺失：只记录异常不记录关键业务操作，出问题时无法还原「谁在什么时候改了什么」。日志要覆盖登录、权限变更、数据修改与接口调用失败等关键事件。

只写「有预案」：文档里写着「有备份、有预案」，却没写备份多久做一次、存在哪里、谁负责恢复、恢复需要多久，也没有做过一次恢复演练。这样的预案在真正故障时无法执行。同理，回滚预案要写明回滚判定条件与决策人，而不是只写「必要时回滚」。