187
coverage, so that all major parts of the system are touched on in early loops. The goal is to
discover and stabilize the major components and their interactions. Task ranking is neces-
sarily based on experience and qualitative factors, and again we recommend using a scor-
ing method, where each team member ranks the tasks. On completion, the leader can sort
and discuss priorities in a Delphi framework.
As we have said, iterations should be timeboxed. Because size is the basis for a discus-
sion of effort, the team should estimate size, that is, thousands of lines of code, using their
experience, and more importantly function point estimates based on completed prototypes.
(Evolutionary prototypes or code developed in Stage 2 speeds things up. Throwaway proto-
types provide a basis for discussion of function points.) Also included in estimates should
be time allocated to daily scrum meetings. Team members should also be able to budget,
or at least eyeball, their own total work hours or uninterrupted development time for each
task, say five hours a day. Between task size estimates, meeting times, and time budgets,
the team should be able to arrive at a reasonable timebox estimate and/or put together a
meaningful Gantt chart. With a flow of new trading/investment systems and a little experi-
ence, estimates as to effort, staffing, and cost will naturally become more precise.
During iteration meetings, the team should also make estimates for computer capacity,
server and database use, and network capacity, which should all be documented as they impact
departments and personnel external to the development team. The team should also be cogni-
zant of risks to external dependencies, such as delays caused by other departments or vendors.
Lastly, the development team should also plan for intraloop code reviews, both for-
mal and informal. During an informal code review, programmers look at and criticize each
other ’ s code. During a formal review, programmers make notes regarding design decisions
and their rationale. Later, the rationale can be criticized, changes recommended and
recorded, and version numbers updated. Through code reviews, development teams quickly
confront design risks, overcoming them, scaling back, trying other paths, or even in extreme
cases canceling the project where risks are insurmountable. A development team can pro-
vide immediate, factual feedback, not shallow assurances before they miss deadlines or the
project fails. At the end of each iteration there must be a demonstration of progress to the
product team, so that the finished features will be ready for quality assurance testing.20.3. Buy versus Build
The quickest way to shorten a software development schedule is to buy components or reuse
existing software. The development team makes recommendations as to which components
to buy, which to reuse from internal libraries or past projects, and which to build from the
ground up. Because this decision will affect the rest of the project, iteration plans should
also address the process for selecting a solution to the buy versus build problem. If the team
intends to base a trading/investment system on a COTS application, they will need to incor-
porate aspects of that software into the design of glue code or middleware that is developed
in-house. Of course, reuse has dramatic implications for costs and schedules as well.
We recommend the product team establish controls over vendor-supplied components.
That is, the development team should evaluate third-party components through a pro cess,
basing their selection on a vendor ’ s ability to meet requirements. Furthermore, the
development team should maintain a record of vendor and vendor component evaluation
results. Such a process should consider:● Accurate identification of needs and specifications of vendor products.
● Evaluation of the total cost, including licenses, scalability, delivery, and perfor mance
implications on trading/investment system results.20.3. B U Y VERSUS BUILD