供应链融资—供应链管理系统“7天开发实践”, Day Seven

今日任务：总结基于EAFD平台开发的SPC于传统模式下开发的区别，并对比各项参数。

 

• 项目资源投入对比:

项目阶段	传统(人/天)	EAFD(人/天)	打分理由
需求分析		3	3	需求分析所涉及类容基本一致，不过两种方法论完全不一致。传统：瀑布式，由上而下，基本对照用户的需求文档整理出流程和操作，并文字注明操作的注意点。EAFD：1）划分功能模块，展示UI结构；2)抽象业务对象，并形成配置表;3)梳理业务流程，确定需要的操作及注明操作模式。
设计		10	1	此环节对于传统环节尤其重要，事实上一个新系统在架构、技术规范、开发管理规范在此阶段都需要确定，因此传统上的设计环节环节所需时间只会在此基础之上。而EAFD在此环节的任务比较简单，因为不需要关注基础架构、开发技术规范，只需要将精力集中在“新增的业务操作模式”上，从而决定需要增加哪些种类的新的业务操作。
开发	架构开发	10	3	传统开发模式需要进行技术选型，然后构建合理的技术框架，并进行项目化，开发一些公用的组件，以程序员调用。EAFD:对于需要增加的业务操作，增加相应的操作视图、通用业务处理服务，以供业务实现时使用。
	功能开发	35	5	传统开发模式：页面、Web控制层、后台服务及组件调用调试都需要程序员完成，其中页面可能涉及到JS控制和数据展示转换等。EAFD：只需要选择平台中的视图，在系统中配置功能模块的URL服务路径，同时在服务挂载时，配置所关联的表单、查询定义。
	单元测试	17	1	传统开发模式：功能开发过程中，对于自己编写的前端视图代码、控制层代码、后台服务代码及一些视图控制设置都需要程序员进行单元测试。EAFD：基于配置，在线进行功能实现，配置完成后就可以直接通过界面进行功能验证。
集成测试		10	2	传统模式：串接各个模块，进行整体测试。在测试过程中的问题排查和解决必然出现反复，如果代码分层差点，在排查控制逻辑时可能要花费比较长的时间才能解决测试中的问题。EAFD:所有控制逻辑都是体现在操作定义中，排查比较简单，只要查看一下相关操作的JSON定义的目标状态即可。
用户测试		14	3	传统模式：用户可能要进行2-3轮的测试、修改、验收的过程，迭代验收，因为开发模式的限制，所以修复bug，回归测试和集成发布的时间周期较长。EAFD:从单元测试开始，所有的测试都是用过用户的interface进行的，而且所有的用户服务都来自平台的通用服务，稳定性得到保证。在过程中，涉及到流程的更改都是通过配置来完成，无需更改，所以2-3个用户测试循环可以在较短的时间完成.
合计	99	18	经过SPC项目，可以看出，在面向行业的企业级应用解决方案实施中，基于EAFD平台可以节省80%以上的开发成本和管理成本。
(表一)SPC项目投入对比

• 处理项目变更对比:

项目变更	传统(人/天)	EAFD(人/天)	打分理由
查询变更	0.5	0.1	EAFD平台对于查询的修改，包括字段、查询条件的增该、显示、翻译等都通过查询字段配置完成，而且在线生效，无需研发投入、测试投入
表单变更	0.5	0.1	EAFD平台对于表单的修改通过表单字段可以完成，可以完成表单字段布局、表单字段校验、字段值输入方式，字段增减的改变。在线变更，即可生效。
操作变更	0.3	0.1	EAFD通过操作配置，更改操作效果。如设置某一字段的值或者改变某个字段的状态、或者需要调用某一数据处理服务等。

(表二)SPC项目变更投入对比

 

 

 

• 处理新业务模式对比:

新增业务模块	传统(人/天)	EAFD(人/天)	打分理由
已有操作模式	4	0.4	通过操作的JSON控制定义，即可简单实现。
全新操作模式	6	2	需要开发新视图模板，集成已有的基础表单、查询和操作，满足新业务操作模式。

(表三)SPC新增模块投入对比

 

• 各项指标对比:

稳定标的	传统	EAFD	打分理由
功能稳定性	1	5	成熟的视图承载视图的实现。通过操作定义控制视图中的功能操作，不涉及代码级的调试。因此功能的稳定性较有保障。
实施快捷度	1	7	模块由查询、表单、操作等基本视图组成。对于基础视图的合理布局和搭配就完成了功能模块的实现。
变更处理	1	4	变更处理都可以通过配置完成。
人员无关性	1	5	标准的系统实施标准，从需求到交互，都按照EAFD的标准执行，在标准之下，发挥人员的智慧。
项目可控性	1	4	基于EAFD开发实施，需求确定后就可以估算各个阶段的投入情况，而且估算的较为准确。
综合评比	1	5
(表四)SPC各项指标系数对比

 

 

结论：

       基于EAFD平台，面向行业实施业务级信息系统，你的投入成本将降低80%以上。