概要设计(FDDSO)和详细(FDD)是Oracle的财务产品业务设计中非常重要的地位,以至于在后来产品交付后,这些文档也会被经常作为证据,用来在PM, QA 和Dev之间划分责任。比如某某功能FDD定义好了,但是Dev实现有偏差,这是Dev的责任。或者某个功能客户需要,但是在FDD里面没有提及,这是PM的责任等等。
概要设计FDDSO
概括的叙述产品的功能,范围,和其他产品的关系。同时在high level的层面定义技术实现的基本原则,架构方向等。通常都是以PPT的形式存在,用于PM, QA, Dev三方之间确立一个相同的目标和概念。FDDSO一般包括以下几个方面:
* 基本功能Introduction, Life Cycle
*
* 从业务和财务的角度阐述功能,以及这个功能中所影响的实体。如果引入了新的实体,那么要介绍到这个实体的状态的变化,以及一个最基本的生命周期。
* Logic Model
*
* 各个实体之间的关系,新引入的实体和已经存在的实体之间的相互关系
* Data Model
*
* 从数据库表的层面对实体,以及关系的描述。Data Model的设计是非常非常重要的一个步骤,属于软件的根基,直接影响到后来的扩张性以及性能。
* 财务软件的Data Model的设计有一些比较好的实践:
*
* WHO Column
* History Table
* Distribution Table
* Header-Line结构
* Application Table
* Activity Table
* Setup
*
* 产品的基本配置,以及对现存的Setup的功能的影响
* Main UI
*
* 界面的基本的数据展示模块介绍
* 功能button的介绍
* Concurrent Program
*
* 有些批量处理的数据需要长时间运行,所以设计Concurrent Program,提交一次之后,能够在任意时间去查看状态以及结果。
* 一般用户批量数据处理和Report
* Public API
*
* 产品对外的一些Web Service的接口, 可以用来和其他模块集成
* Report
*
* 财务产品一般都要生成相应的财务数据报表
* Seeddata
*
* 通产都会依赖到的一些财务数据字典,一些必要的行业配置定义
* Accounting
*
* 业务场景的分录
详细设计FDD
财务FDD详细设计需要非常的精确,细化到每一个Label,每一个Button. 财务业务规则要在文档中进行充分地体现。
* UI Prototype
*
* 用HTML的方式,设计出UI和Report,能够有相应的跳转,包含基本的数据范例
* BPM task flow
*
* UML基本的Swim Lane的方式,描述出功能的所有Flow
* UI Page Design
*
* 用excel的方式,定义UI上所有功能,包括每个表格,每个按钮,每个输入/输出框。同时所有相关的财务/业务规则都需要在这个文档上有明确的体现。并和UI上具体的实体进行一一对应。比如某个Button,什么时候可以点击,什么时候不可以,点击后进行怎样的计算或者显示。
* Service Design
*
* 产品提供给外部的接口,输入输出参数,内部实现功能定义
* Event Solution
*
* 这部分主要是和SLA系统模块的集成,用来生成真正的Accounting,并Post to GL.
* Report Solution
*
* 报表的设计,RTF模版,以及Data Model Query的定义
* Functional Security
*
* 定义安全配置,并集成到安全管理体系里面
* Message
*
* 定义详细的Message,message内容采用财务对于用户的操作进行错误提示和引导。而开发人员可以引用Message Code,在适当的时候抛出。
* 从开发角度看,就是把Catch的Exception转换能让财务人员明白的语句。
* Seeddata
*
* 产品数据字典的详细定义
* Upgrade Considerations
*
* 产品部署,升级的考虑,潜在风险等
* Test Strategy
概要设计FDDSO
概括的叙述产品的功能,范围,和其他产品的关系。同时在high level的层面定义技术实现的基本原则,架构方向等。通常都是以PPT的形式存在,用于PM, QA, Dev三方之间确立一个相同的目标和概念。FDDSO一般包括以下几个方面:
* 基本功能Introduction, Life Cycle
*
* 从业务和财务的角度阐述功能,以及这个功能中所影响的实体。如果引入了新的实体,那么要介绍到这个实体的状态的变化,以及一个最基本的生命周期。
* Logic Model
*
* 各个实体之间的关系,新引入的实体和已经存在的实体之间的相互关系
* Data Model
*
* 从数据库表的层面对实体,以及关系的描述。Data Model的设计是非常非常重要的一个步骤,属于软件的根基,直接影响到后来的扩张性以及性能。
* 财务软件的Data Model的设计有一些比较好的实践:
*
* WHO Column
* History Table
* Distribution Table
* Header-Line结构
* Application Table
* Activity Table
* Setup
*
* 产品的基本配置,以及对现存的Setup的功能的影响
* Main UI
*
* 界面的基本的数据展示模块介绍
* 功能button的介绍
* Concurrent Program
*
* 有些批量处理的数据需要长时间运行,所以设计Concurrent Program,提交一次之后,能够在任意时间去查看状态以及结果。
* 一般用户批量数据处理和Report
* Public API
*
* 产品对外的一些Web Service的接口, 可以用来和其他模块集成
* Report
*
* 财务产品一般都要生成相应的财务数据报表
* Seeddata
*
* 通产都会依赖到的一些财务数据字典,一些必要的行业配置定义
* Accounting
*
* 业务场景的分录
详细设计FDD
财务FDD详细设计需要非常的精确,细化到每一个Label,每一个Button. 财务业务规则要在文档中进行充分地体现。
* UI Prototype
*
* 用HTML的方式,设计出UI和Report,能够有相应的跳转,包含基本的数据范例
* BPM task flow
*
* UML基本的Swim Lane的方式,描述出功能的所有Flow
* UI Page Design
*
* 用excel的方式,定义UI上所有功能,包括每个表格,每个按钮,每个输入/输出框。同时所有相关的财务/业务规则都需要在这个文档上有明确的体现。并和UI上具体的实体进行一一对应。比如某个Button,什么时候可以点击,什么时候不可以,点击后进行怎样的计算或者显示。
* Service Design
*
* 产品提供给外部的接口,输入输出参数,内部实现功能定义
* Event Solution
*
* 这部分主要是和SLA系统模块的集成,用来生成真正的Accounting,并Post to GL.
* Report Solution
*
* 报表的设计,RTF模版,以及Data Model Query的定义
* Functional Security
*
* 定义安全配置,并集成到安全管理体系里面
* Message
*
* 定义详细的Message,message内容采用财务对于用户的操作进行错误提示和引导。而开发人员可以引用Message Code,在适当的时候抛出。
* 从开发角度看,就是把Catch的Exception转换能让财务人员明白的语句。
* Seeddata
*
* 产品数据字典的详细定义
* Upgrade Considerations
*
* 产品部署,升级的考虑,潜在风险等
* Test Strategy