199
The overhead of developing, supporting, and enhancing an in-house system needs to
be assessed against the cost, functionality, technology, flexibility, and the level of support
available from third-party vendors. An important consideration as trading and money man-
agement firms seek to gain a competitive advantage through technological innovation is
that in-house systems are proprietary and the firm will be able to differentiate its strategies
and technologies from competitors. Where a firm chooses to outsource any process that
affects conformity with specification requirements, the development team must demon-
strate control over such processes.
The development team should not limit its reuse considerations to source code; they
should also consider how to reuse data, detailed designs, test cases, plans, documentation,
and even design processes.21.3. Software Architecture Document
The SAD is the project blueprint. A SAD contains all of the items that a software engi-
neer will need to design and build a product. The main benefit of producing a SAD is that
it forces the prototype and the software engineer to formally address key items such as
calculations, GUI, and reports prior to starting the development and implementation of
the trading system software. Since many of the key items of a project get revised regu-
larly as the details get flushed out with prototypes, it is important that the research and
backtesting done in earlier stages be fully documented in light of the SAD to come.
SADs can get large and unwieldy. Because of their potentially large size and com-
plexity, SADs are best decomposed into smaller and simpler documents, subvolumes
documenting the architecture at different tiers. Every architecture decision should be doc-
umented with an associated rationale. The contents of a SAD should be:I. Introduction
A. Purpose
B. Scope
C. Definitions, acronyms, and abbreviations
D. References
E. Overview
II. Architectural representation
III. Architectural goals and constraints
IV. Use-case view
A. Use-case realizations
V. Logical view
A. Architecturally significant design packages
VI. Process view
VII. Deployment view
VIII. Implementation, or tier views
IX. Data view
X. Size and performance
XI. Quality attribute requirements21.3. SOFTWARE ARCHITECTURE DOCUMENT