从需求开始(新建)
只需交出需求文档、访谈记录和业务资料。AI 会整理成需求定义书,之后设计、实现、测试、迁移、运维都由同一个对应单推进。
从需求出发,或从遗留源码出发——需求定义、设计、实现、四级测试、迁移上线,直到运维保守。日式大型项目该交的文档,一件不少,由 AI 作为工序产出。一键完成部署。工程进度按对应单(针对一个课题的一次执行)呈现,如图所示。
从需求出发,或从遗留资产出发。
只需交出需求文档、访谈记录和业务资料。AI 会整理成需求定义书,之后设计、实现、测试、迁移、运维都由同一个对应单推进。
读解 COBOL・Java・VB・PL/SQL 的实际源码,反推现行规格。哪怕是设计书早已散失的 30 年老资产,也能从下一步开始。
↓ 两条路都汇入同样的 7 道工程 ↓
对应单前进,文档齐备,系统运行。
每道工程的完成由检查印确定——盖印的是人,书写的是 AI。退回时附带理由返回前一道工程,由 AI 重做。05 测试分为单体、集成、总合、验收四段。
一件不少。
不只是最终文档。中间文档——各级测试的计划书与成绩书、评审记录、迁移演练记录、周次进度报告,都会按日式大型项目的交付规程齐备。带「自动」印的表单甚至不需要写——它们从对应单的实绩里出来。
标准的型(標準納品規程 v3)共 100 份文书。明细请看产品页的「交付物目录」。也可以换成贵司的交付规程。 查看交付物目录 ▸
先看一眼真实的对应单。
反着来、正着来、混着来都行。
逆向读解 41 万行 COBOL,先复原现行规格书再刷新。验收测试按客户既有的验收样式一次通过。
正向生成。从需求定义到验收测试,全部文书按规程交付,审计部门的文书检查一次通过。
刷新(入口 B)与新建(入口 A)的对应单在同一项目里并行。共通基础由一侧的成果供另一侧引用。
※ 所载案例为匿名化的 PoC 阶段内容。取得客户许可后,将以真实公司名、标识与确定数值替换本区块。我们绝不擅自刊载客户标识。
按项目报价。
按资产规模、交付规程与团队构成来定。标准是从 PoC(1 个模块・4 周)开始签约。
Makit 不是项目管理工具。
没有录入进度的画面,也没有写报告的功能——执行工程的是 AI,人只负责盖检查印。
可以查看工程进度,以及等待您批准的交付物。