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

180 CHAPTER ◆ 1 9 STAGE 3: Overview

19.2. Real-Time Systems

While K | V assumes that all the functional requirements, performance requirements, and

design constraints are specified prior to Stage 3, in the real world, with real-time, high

frequency systems, where technological speed is the competitive advantage, more system

planning and design will be needed.

Planning and design for such systems typically follow an evolutionary process. In

such systems, computation times have to be short, typically measured in milliseconds or

faster, and execution deadlines are critical. Late execution would defeat the whole pur-

pose of the trade selection algorithms. Larger systems of this type may also contain a

complex man/machine interface (e.g., an execution strategy control system, where fast

operator response is required but millisecond deadlines are not critical). In such a case,

user interfaces may need additional prototyping.

For systems that make use of high frequency data and arbitrage or market making

algorithms, critical response times are accomplished in one of two ways. One model runs

algorithms at regular intervals. An example is a closed-loop index-arbitrage system, having a

fixed, preset sampling rate for the index ’ s constituent instruments. This loop is a synchronous

or periodic event with a real-time clock, where response times can be easily determined. The

second model is where the software responds to external events that occur at random, asyn-

chronous, or aperiodic intervals. In this case, each market event must be serviced, that is,

received, understood, and responded to, within a specified maximum time. When the trading

system has to cope with multiple aperiodic market events, estimates of execution time are

more difficult to determine. (Trouble often arises where systems need to handle both time-

incremented and random events. Development teams are encouraged to plan and design iter-

atively and carefully in such cases.) Through iterative planning and design, the development

team can evaluate alternative implementations. In the end, the team can set estimates of best

and worst performance and test the trading system through shadow or probationary trading.

19.3. LOOP 1: Program and Test Trading/

Investment Algorithms

STEP 1: Document Software Requirements

STEP 2: Design Business Rules Packages

STEP 3: Program Business Rules Packages

STEP 4: Test System Outputs against Black Box Tests from Previous Stages and

Probationary Trade

Loop 1 takes the quantified logic, that is, the business rules of the trading/investment sys-

tem, and turns it into production, executable code. These activities come first because the

product team may have already converted some of the trading/investment strategy algo-

rithms, prototyped in Stage 1, into C   , Java, or .NET code objects in Stage 2. This

code can be used in the production system. Where this has occurred, the development

team need not spend extra time and resources reprogramming those features; regression

testing in Stage 2 should have already ensured its correctness and the product team should

have fully documented the architecture of these components for review by the develop-

ment team and inclusion in the Stage 2 deliverable documents.

Where the development team converts prototypes from one implementation, like

Excel, Resolver, or MATLAB, to code over this stage, the product team should perform