01
业务简报
目标与验收
10+ 年
体验客户网站的全周期维护，从上线到后续变更。
ISO/IEC 29110
指导项目管理和软件实施，包含可审查的工作内容和交付成果。
构建 → 运行 → 改进
从一开始就规划交接和维护工作，确保系统有明确的所有者和持续发展路径。
围绕您的业务构建
契合需求的软件
组织运作方式
从最需要改进的工作入手。围绕用户、数据以及将负责运营的团队，确定范围和技术方案。
01
业务应用
打通碎片化的流程
内部工具、审批工作流和共享的业务数据，减少重复工作，实现基于角色的访问控制。
02
客户平台
服务客户与合作伙伴
客户门户、业务网站和服务应用与后台数据连接，并针对用户实际使用的设备进行设计。
03
集成与现代化
有意识地演进现有系统
连接各系统间的API和数据，评估遗留代码，并将改进措施拆分为可测试、可交付的增量。
交付体系
每个阶段都有明确目的。
每一次交接都有证据支持。
Ruk-Com的六阶段服务框架使工作、职责和决策变得清晰可见。可根据项目情况调整交付节奏，并按需迭代。
SDLC流程 · 说明性流程
请选择一个阶段以查看其负责人和交付物。
交付反馈与返工审批步骤
01
发现与规划
首先明确问题
02
架构与设计
为具体工作和现有系统进行设计
03
构建与评审
分阶段构建并保持清晰的记录
04
质量保证（QA）与用户验收测试（UAT）
验证质量和业务接受标准
05
发布与移交
按计划发布，并提供可操作的移交方案
06
运行与优化
从实际运营需求出发进行优化
正常流程：确认需求 → 设计 → 开发 → 测试 → 手交 → 运营。生产发布需经过约定审批。
01
发现与规划
理解用户、工作流和限制条件。将简报转化为需求和待办事项清单（包含接受标准），然后确定范围、风险和交付计划。
- 所有者
- 业务所有者 + 项目经理 / 需求分析师
- 交付成果
- 需求 · 范围 · 接受标准
- 审查节点
- 客户确认优先级、需求和初始范围
02
架构与设计
设计用户流程、用户体验/界面（UX/UI）、数据模型和API合约。在实施前审查集成、访问控制和架构决策。
- 所有者
- 产品经理 + 设计师 / 架构师
- 交付成果
- 用户流程 · 数据模型 · API 合约
- 审查节点
- 共同审查设计和集成约束条件
03
构建与评审
使用分支、同行评审的拉取请求、单元测试和变更记录来实施优先级排序的待办事项，并将其工作与原始需求关联起来。
- 所有者
- 工程师 + 代码审查员
- 交付成果
- 源代码 · 拉取请求 · 单元测试
- 审查节点
- 在合并前审查代码和测试结果
04
质量保证（QA）与用户验收测试（UAT）
执行基于风险的集成和回归测试。业务用户根据约定标准执行用户验收测试（UAT）。记录缺陷，将其返回给开发人员修复，并在修复后重新测试直至通过。
- 所有者
- 质量保证团队 + 业务用户
- 交付成果
- 测试结果 · 缺陷日志 · UAT记录
- 审查节点
- 可问责的负责人审查UAT结果及待处理问题
05
发布与移交
为系统准备发布检查清单、数据迁移和回滚计划，并移交代码库、文档和知识。生产环境变更需经已同意的审批人批准。
- 所有者
- 发布负责人 + 客户审批人
- 交付成果
- 发布说明 · 运行手册 · 手动交接记录
- 审查节点
- 批准发布、验证及回滚计划
06
运行与优化
在支持范围内监控并收集反馈，区分事件、缺陷和变更请求。变更范围需返回需求、影响评估和审批流程，方可进入新迭代。
- 所有者
- 服务负责人 + 支持/工程团队
- 交付成果
- 服务日志 · 维护计划 · 变更请求
- 审查节点
- 在推进前确认改进措施并批准其影响
根据项目实际情况调整敏捷或迭代交付方式，同时确保需求和交付成果在整个过程中可追溯。
过程需有问责制
ISO/IEC 29110
从指导到实际操作。
使用基础配置指导将项目管理与软件实施连接起来，确保业务决策与工程工作保持一致。
PM
项目管理
明确当前在做什么、谁负责以及哪些决策需要关注。
- 确定范围、计划和责任分工。
- 审查进度、风险及待决事项。
- 在批准前评估变更的影响。
- 审查交付成果并记录验收情况。
项目计划 · 进展记录 · 变更日志
SI
软件实施
将需求转化为可验证并可交付的软件。
- 分析需求并设计系统组件。
- 构建、审查代码并控制版本。
- 依据标准进行测试并系统性管理缺陷。
- 准备软件配置和交付包。
需求 · 设计 · 代码 · 测试 · 部署
工作过程的可追溯路径
示例证据链，非客户项目数据。
- 需求
- 设计
- 拉取请求
- 测试结果
- 发布
探索官方文档 ISO/IEC 29110 系列指南.
质量是工作的一部分
质量和安全
已融入流程中。
商定符合风险水平的审查标准，并保留业务和技术团队共同评估的证据。
明确验收标准
在开发前明确预期行为、数据边界和错误情况，以便UAT使用统一标准进行评估。
需求 → 测试用例已审查变更
使用版本控制和代码审查，分离环境，并对关键系统行为应用自动化测试。
拉取请求 → 审查 → 测试按范围实施安全措施
需考虑访问控制、机密信息管理、依赖关系和数据流。针对更深入的安全评估，应明确独立的范围和授权。
访问权限 · 机密信息 · 依赖关系发布就绪
审查发布清单、备份和回滚方案，由审批人和发布后验证计划共同确认。
审批 → 部署 → 验证设计为易于维护
发布是开始
长期维护的体现。
凭借超过 10 年的客户网站维护经验，我们在开发的同时规划交接与维护，从访问权限到问题发生时的责任归属均作出安排。
持续维护 · 说明性流程
01
监控
信号与请求
02
事件分类处理
影响与责任归属
03
修复
已确认范围变更
04
验证
测试并评估影响
05
审批部署
审批 → 部署 → 验证
↳ 部署完成后，返回监控环节以验证并持续维护。
定义常规维护工作
以及变更工作明确说明。
选择适合您系统的维护方案。在服务开始前，明确环境、覆盖时段、联系渠道及责任分工。
- 监控和请求接收，按影响程度优先级排序。
- 更新、备份与恢复均按既定、可测试的计划执行。
- 运行手册、访问清单及清晰的交接责任人。
- 将缺陷保修与维护及新功能开发分开。
人员与Ruk-Com代理协同工作
Ruk-Com Agent 代理辅助功能可帮助监控和收集信息供团队审查。访问和修复操作遵循既定权限、范围和审批流程；生产环境变更不会自动执行。
一套可直接使用的交接方案
交付的不仅是功能。
为您的团队提供明确的发展路径。
在协议中明确交付成果、源代码权利及使用条款，包括开源和第三方许可证限制。
代码与配置
代码库、交付版本及依赖关系，附带构建和配置说明，确保机密信息与代码分离。
文档与证据
架构、API和用户文档在范围内，包含测试及UAT结果、发布说明及待办事项。
知识与连续性
转移知识、运行手册和访问记录至责任方。在关闭前明确保修条款及后续维护安排。
从现状出发
无论您有新想法、需要交付能力的项目，还是现有系统需要维护，我们都会在提出工作前先明确问题所在。
- 了解需求共享目标、现有系统及限制条件
- 达成约定明确范围、关键节点、预算和验收标准
- 交付定期审查，交接并支持计划执行
开始之前
在工作开始前
在您开始构建之前。
清晰的约定有助于业务和技术团队基于相同信息做出决策。
ISO/IEC 29110 对我们的项目意味着什么？
我们使用项目管理与软件实施指导，将范围、需求、评审和交付物连接起来，并根据项目规模和交付方式调整SDLC流程。
是否需要在讨论前有完整的需求？
不。应从您的目标、用户、现有系统以及希望解决的问题出发。通过发现阶段可识别优先级、约束条件和验收标准，再进行范围估算。
交付过程中如何处理变更？
提交变更请求，并共同评估其对设计、时间、预算和测试的影响。经批准后，更新待办事项和计划。新增功能并非自动属于原范围。
源代码归谁所有？交付哪些文档？
在工作开始前，合同中需明确代码权利、仓库访问权限和交付物，包括开源、库和第三方相关条款。文档和知识转移内容将围绕接收团队进行规划。
如果UAT未通过会怎样？
根据约定的接受标准记录缺陷，对其进行优先级排序，并返回给工程团队。在可问责负责人考虑接受前，需重新测试。新需求需遵循变更请求流程。
能否接手由其他团队构建的系统？
首先审查源代码、技术栈、依赖关系、访问权限和文档，以评估风险和准备情况，再接受范围。该合作可从评估或分阶段改进开始。
保修和持续维护包含哪些内容？
明确缺陷保修的期限、条件和范围。监控、更新、备份、支持以及新功能在相关服务计划中已约定；并非所有内容都会在整个系统生命周期内提供。
让我们共同书写下一章
告诉我们您需要什么。
让我们规划未来的方向。
分享你的系统、目标和时间线。我们可以评估出符合你组织需求的开发与维护方案