133
strategy and will ensure that tool changes and additions do not alter the algorithms.
Furthermore, regression testing will control project time lines, budget overruns, and software
errors that may affect the performance of the system. The absence of a well-defined and
implemented regression testing policy for tool conversion can doom a development project.
Regression testing against prototypes developed in Stage 1 can identify when codi-
fied implementations of benchmarked and prototyped algorithms fail, allowing product
teams to catch errors as soon as they arise. Tool changes can have unexpected side effects
that might break previously tested functionalities. Regression testing will detect hard-to-
spot errors, especially those that occur because a programmer did not fully understand the
mathematical or logical constructs or the internal connections between algorithms of the
trading/investment system. Every time code is converted from one implementation (say,
an Excel cell formulas prototype) to a new one (say, a C .dll add-in), or is modified,
regression testing should be used to check the code ’ s integrity. Ideally, the product team
will perform regression testing regularly to ensure that errors are detected and fixed as
soon as they arise.
Given that the product team converts prototype models into code, our methodology
assumes that regression testing is built from the successful white, gray, and black box
test cases used during testing of prototypes (K|V 1.4). These test cases, which in the past
verified components of the trading/investment system and its overall functionality, can
be rerun regularly as regression tests against coded implementations developed in this
stage. During regression testing, known inputs generate outcomes that can be compared
to known, correct outcomes from Stage 1.
Lastly, the product team will document the architecture of the final working software
that implements the trading/investment strategy. While this documentation is normally an
output of K|V Stage 3, to the extent that conversion to code occurs in this stage, the team
should begin preparing the relevant content for the architecture document at this point.13.2. Information Management and Database Design
The backtest stage also addresses the information management task. Information manage-
ment consists of gathering, processing, structuring, and distributing data. This includes the
design and management of data and databases for working trading/investment systems.
As its name implies, a database design document should present the design of all data
sources that will be part of a trading/investment system. The typical objective of a
database design document is to formally document the logical and physical design of all
databases to ensure that:● Persistent data is correctly and efficiently stored.
● Data is identified consistently in documents, objects, and data sources.
● Installation, configuration, and maintenance of the databases is as simple and
consistent as possible.
● Developers can easily integrate code with databases.The typical contents of a database design document according to the OPEN Process
Framework^3 are:- Database Overview:
(a) Name
(b) Objectives in terms of contents and usage
13.2. INFORMATION MANAGEMENT, DATABASE DESIGN