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

177

STAGE 3: Overview

CHAPTER ◆ 19

The spiral stage structure of K | V begs two perspectives—one, that of the loops; and two,

that of the steps. One can look at the four steps that comprise a single loop, or the three

loops that comprise each step. We will do both. This chapter will present an overview of

the three loops. The following four chapters will examine each of the four steps and each

pass over each step. The number of loops is not by any means fixed. (We decided that

three iterations were sufficient to cover the commonly encountered substeps.)

STEP 2:

Design

system

architecture

STEP 3:

Build and

document the

system

STEP 4:

Check

performance

and probationary

trade

STEP 1:

Plan and

document

technology

specifications

3

2

1 1

2

3

3 3

(^22)
11
FIGURE 19-1
Stage 3 accomplishes the transformation task, turning the specifications of the trad-
ing/investment system into software and hardware. The design of the trading system from
previous stages now becomes the specification requirements for the software design. By
the time a product team reaches this stage, most if not all the groundwork for success has
already been laid. The requirements have been gathered and tested in previous stages, and
after Gate 2 are fixed. Any design errors discovered or changes made to the trading/invest-
ment strategy from this point on require a return to Stage 1 for rework and then retesting.
At this point also, our methodology assumes that the task of building software and
hardware components of the trading/investment system will include a development
team in addition to the product team. The lead programmer/IT member of the product
team manages this somewhat agile development team, which will engage in test-driven
development. In this capacity, the development team leader becomes the lead software
designer. This way the development team lead understands the critical tasks, priorities
and resources necessary to complete the transformation, and represents the product team ’ s
(i.e., the customers ’ ) interests to the developers. This should ensure that knowledge is