Development Team
Stage 3 is where the development team' s senior software engineers take control of the project to design and build clean, optimized, robust, and fast software. Of course, software development processes have been researched in depth over the last 40 years, and in this step we will not rewrite the research, but rather link our K|V methodology to agile processes and the Software Engineering Institute ' s (SEI) models for designing and building tight software. We do, however, believe in test-driven development where the development team iteratively writes test cases first, then writes only the code needed to pass each test.
The technology development team is responsible for the design, coding, testing, and implementation of the software and network components of a trading/investment system. We recommend this team follow more agile development principles, embracing change, communication, and feedback. According to the Agile Manifesto (www.agilealliance. com), an agile team:
• Focuses on customer satisfaction.
• Communicates face to face, often in daily meetings.
• Focuses on iterative and evolutionary development.
• Strives for technical excellence and simplicity.
A development team typically consists of a lead software designer (again, the product team's lead programmer/IT professional), software engineers, network engineers, and test engineers, who perform unit test-driven coding, hardware, and software integration testing, and refactoring in an iterative, incremental, timeboxed manner.
The typical responsibilities of the software engineers are to understand and evaluate the requirements specifications and alternative architectures, build and unit test the system, and create design documentation. Where possible the software engineers reuse software components from the firm's library of proprietary components. Furthermore, they will purchase, configure, and extend COTS components where appropriate. Management should not be allowed to select the programming language. This should be set at the firm level and followed by all teams. (While the firm may enact changes on the recommendation of programmers, nevertheless development must take place within management-approved technologies.) To ensure maintainability, management should also lock the framework for coding firmwide.
A development team develops software iteratively. As always, we believe in client-driven and risk-driven iterative technology development, where the elements with the highest business priority and risk are chosen first. Each iteration in Stage 3 covers design, programming, testing, integration, and delivery of a useful piece of software. We prefer shorter iterations where timeboxes are no longer than two weeks. This process is very similar to a prototype in K| V Stage 1 except that an iteration in this stage produces a working portion of the final trading/investment system.
Iterative development dramatically increases feedback versus sequential development, providing closer communication between the product team and the development team. Small portions, or batches, beget short feedback loops that enhance control. Shorter iterations, furthermore, force an option-based approach to development, allowing the technology to respond to proven and tested facts rather than estimates and forecasts. An option-based approach reduces risk by keeping options open rather than freezing the technology design. Unit testing and integration test engineers should be involved from the first iteration so that design problems will be exposed early on. Iterative development and testing forces points of communication, better use of time and resources, and, in the end, better quality.
The development team should consider the documents and prototypes from Stages 1 and 2 to be the base code used for testing. Programmers sometimes ignore specifications and designs, preferring to just start coding. This leads to design errors, including nonscalability, and produces poor design documentation. Instead of being encouraged that the software is finally being built, the product team will become discouraged. Without firm design documents in line with the initial requirements specifications, a completed system should not pass a due diligence process, be funded by investors, or allow the sale of the system and its fund.
Developers must follow plans. A construction team building a bridge would be fired immediately for changing designs away from the prototype structure. A development team programming flight controls would be fired immediately for not building to the prototype and simply coding on the fly. Top management must be firm on this concept or give up on our methodology. Deviation at this point will result in out-of-control development and failed projects.
Post a comment