Quality Money Management : Process Engineering and Best Practices for Systematic Trading and Investment

134 CHAPTER ◆ 1 3 STAGE 2: Overview

(c) Type (e.g., XML, object, relational, network, hierarchical, flat file)

(d) Vendor (e.g., Oracle, SQL Server, LIM, Access, Excel)

(e) Deployment (e.g., database server).

2. Characteristics:
   (a) Legacy or newly developed
   (b) Internal or external to the trading/investment system
   (c) Location
   (d) Expected size and access rate
   (e) Source of data (e.g., data entry, existing database, external data feed).


3. Logical Data Model (i.e., Logical Database Schema):
   (a) Relational Model (e.g., relationship diagrams, table definitions, stored
   procedures)
   (b) Object Model (e.g., class diagrams, class specifications).


4. Approach to maintenance, backup, and disaster recovery.

Anything that holds persistent data for the trading/investment system software should

be documented in the database design document, including databases, flat files, registry

entries, XML files, and others. The database design document will as usual require itera-

tion as the product team discovers new information and/or new technologies. Normally,

development of a database design document and architecture documents iterate in paral-

lel because database requirements impact the architecture and the architecture impacts

the capabilities of the database. Where coded components are being developed, the archi-

tecture documents should be started in this stage. The database design document should

reference the relevant documentation of any COTS database. Furthermore, the database

design document should include discussion of any changes made to COTS products to

enhance its abilities.

A data dictionary contains definitions and representations of data elements and a data

map will show the flow of data into and out of the system. Both of these will be expected

at the Gate 2 meeting as well.

The purpose of all this documentation is to provide a detailed data flow description,

proposed normalized structures for results, and to facilitate linking to accounting, risk,

and execution software. This needs to be completed now so in Stage 3 integration into the

existing technological environment will be well understood.

13.3. LOOP 1: Quality Assurance Testing

STEP 1: Survey Data Needs and Vendors

STEP 2: Identify Required Cleaning Activities and Algorithms

STEP 3: Define Testing Methodology

STEP 4: Perform Regression Test to Validate Algorithms and Benchmark

Loop 1 is a full-scale experiment design in the production environment. This is similar

to industrial process design where a product from the research laboratory is scaled up to

a prototyped production facility. The product team will build sample inputs and outputs