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

198 CHAPTER ◆ 2 1 Design System Architecture

Evaluation allows the development team to argue benefits and problems with designs

while they are cheap and easy to address. A design evaluation should answer two ques-

tions: is the proposed design suitable and which of the competing designs is the best?

The Software Engineering Institute has developed methods for evaluating software

architectures. Most appropriate for the purposes of trading/investment system develop-

ment is the Architecture Tradeoff Analysis Method (ATAM). The ATAM for architecture

evaluation should reveal the ability of a particular architecture to meet quality attribute

requirements. A full-blown ATAM meeting consists of nine steps:

1. Present the ATAM. The leader describes the ATAM steps.

2. Present the business drivers. A reiteration and discussion of the business goals

defined in the Money Document and software quality attributes. We believe that

everyone should come to the ATAM meeting having read the Money Document

and the Stage 2/Gate 2 documents.

3. Present the architecture. A review of any business logic and data objects that were

created for Stage 2. These objects may or may not be used in the final architecture. If

the objects are unusable or unscalable, the development team will create new objects.

4. Identify the architectural approaches.

5. Generate the quality attribute utility tree. Using high priority scenarios, or use

cases, the software quality attributes are ranked.

6. Analyze the architectural approaches. During this step, risks and trade-offs are

discussed.

7. Brainstorm and prioritize scenarios. Create a large set of use cases and prioritize

them in a Delphi framework.

8. Analyze architectural approaches. Retest to confirm results from Step 7.

9. Present the results. 1

Now, regular, full scale evaluations of this type can be burdensome. For speed, we rec-

ommend “ quicker and dirtier ” evaluations of architectural decisions made during the

most recent iteration. Once a fixed architecture is proposed, a full-blown ATAM meeting

should take place. Once the architecture is complete, the team must document it and be

sure to update the documentation as designs evolve. The product team should check the

progress of documentation at iteration meetings. Developers must have all documentation

updated before providing demonstrations at the completion of each iteration.

21.2.4.1. Benchmarking COTS

One key component of the architecture is the identification of which components will be

purchased commercially, which will be reused from internal sources, and which will be

created from scratch. The project ’ s approach to reuse affects the rest of the software ’ s

design, and so it should be defined at architecture time. If the development team prefers

to base an application on a COTS package, for example, the rest of the software will need

to be designed around that framework. Reuse of existing, benchmarked components saves

time and money. Buying components saves time, but platform compatibility and integra-

tion issues may be significant.^2 Run-off tests will verify that a vendor ’ s software package

can produce the appropriate data or calculations within tolerances. One problem, though,

is that a vendor may change some assumptions or models without our knowledge in later

versions or updates.