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

(Michael S) #1
As one might imagine, version control is essential. If a new version fails a test that
a previous version passed, version control software should be able to provide a list of
changes in the new version. Automated testing tools will run tests and document results.
In either case, good unit testing should force discipline and motivate the development
team to stick to good fundamentals. A common approach to speeding up automated unit
testing is to only simulate time-consuming operations.
Unit tests will not find every problem, however. Unit testing will not uncover higher-
level integration errors, such as data flow problems. Say, for example, that when a trade
confirmation is received, unit tests may not guarantee that it will be entered into the
accounting database or the risk engine. Such data flow will require more sophisticated
integration tests.

22.4.1. Exception Handling


All trading/investment systems must be designed to handle unforeseen problems, that
is, exception handling. If COTS packages are brought in, their quality must be assessed.
Claims are regularly made concerning the benefits of using one operating system over
another. Yet users of such systems often experience unpredictable behavior, including
system hang-ups. Could this really be trusted for a real-time trading system that drives
the firm ’ s bottom line?
Where no recovery action is possible, a trading/investment system can be put into a
fail-safe mode or condition. Or, the system could keep working, but with reduced service.
This may reduce response times or permit servicing only of good elements of the system.
This offers a sort of graceful shutdown—or, fault tolerant operation—where full and safe
performance is maintained in the presence of faults.
Trading/investment systems that use real-time data and/or automate execution must
be designed with safety in mind, and be concerned with the consequences of failure. Fail-
safe systems make no effort to meet normal operational requirements. Instead they aim
to limit the danger or damage caused by fault. For high frequency systems, software may
need to discard any commands not complete within a certain timeframe.

22.5. LOOP 2: Program Interface Packages


In Loop 2, the development team programs the presentation and data interface layers
according to the designs of the previous step. Interfaces to the business layer include: the
graphical use interface; database interfaces for price, valuation, calculated, fundamental,
and economic data; real-time data interfaces for price updates and order execution; and
interfaces to external systems for accounting and risk management. Glue code is com-
puter programming code that is written to interface between disparate proprietary mod-
ules and commercial off-the-shelf applications. Objects and modules comprising these
layers must also be subjected to unit testing, but integration of the business tier with these
other tiers will require black box integration testing.
Integration testing takes unit tested objects and modules and applies tests defined
in an integration test plan. Integration testing should verify that the software ’ s quality
attributes meet requirements, including functional, performance, and reliability require-
ments. Test cases, both successes and error cases, will likely be simulated, where use of
shared data areas and interprocess communication is tested and individual subsystems are

210 CHAPTER ◆ 2 2 Build and Document the System

Free download pdf