Multilink Systems, Inc.

Generally speaking , the Waterfall model is appropriate for projects that are well defined and posses low-moderate  technical risk . The Waterfall model is  a basic development procedure, which is  intuitive and sensible. If there are no serious questions about technological risk and the requirements are straight forward, then this procedure is a natural one to choose.

A simple Waterfall procedure consists  of the following tasks:

1. Requirements Definition
2. Design
3. Implementation
4. Integration
5. Test
6. Support

These tasks occur in serial fashion , one after the other, but there are opportunities to compress the schedule by performing tasks in parallel. This procedure is used when the requirements are well defined and the technological risks are well understood. The Waterfall diagram shows that everything depends on requirements which when defined can be used by the design team to create a system architecture , partition functions and allocate software and hardware units . The implementation task follows the design task and usually consists of parallel software and hardware build tasks. The integration task is used to assemble the software  and hardware units produced and tested in the implementation task.  Then hardware and software units are integrated and tested. This task usually uncovers errors that require rework however if the Project engineering plan is well thought out these errors should be minor.

Once the integration is complete the final system test task is performed to insure that the completed product operates in accordance with the requirements that were defined at the beginning of the project. A test plan based on the requirements is usually developed while the design, implementation and integration tasks are in progress. This is another Project management issue where proper planning prevents poor performance (5Ps). Once testing and rework is complete, the system is ready to deploy.

The "V" development model  is the Waterfall model  bent into a Vee shape to indicate the transition from Top Down Design to Bottom-Up Implementation. It is illustrated in the figure below and shows literally the transition from Top to Bottom.

The figure shows how the design task fits into the development process in terms of Top-Down/Bottom-Up tasks. The requirements definition process (upper left),  where system operation  is analyzed, is a Top Level process. System (High Level) design is a lower level process that  creates the system structure (architecture) and detailed design requirements which are used to create detailed designs defining the lower level hierarchy of sub-functions.  These sub-functions  perform tasks which decrease in complexity in accordance with their decreasing hierarchy.  Once the detailed design is complete, the  Bottom-Up implementation process  path can begin. In this path, implementation tasks such as hardware build, software design, code and unit test begins at the lowest level of functional complexity . The low level implementations are tested and integrated into progressively more complex functions from units to modules to subsystems. At each stop in implementation, tests are performed using the requirements defined in the Top Down design phases.

For very complex and technically risky projects the Spiral Development model  is an appropriate procedure to use. The Spiral Model uses the Waterfall model to build prototypes, that are refined in successive iterations, unfortunately  as the spiral gets larger with more design iterations, the development costs increase quickly. Once again project planning is crucial. The  AGILE / SCRUM / XP methodologies are variants of SPIRAL that use design iterations which produce prototypes for evaluation, test and requirements definition and refinement.

Spiral development produces a product through evolution. The system being developed  is only released from the spiral when it  operates as planned in accordance with  the accepted requirement set. When requirements are changed then more turns are required on the spiral to, evaluate , adjustment, build  and re-plan. The spiral is illustrated in the preceding figure which shows a spiral path expanding outward through four quadrants of activity:

1. Define Goals/ Requirements/Specifications
2. Identify and anticipate areas of risk and ways to mitigate the risk
3. Develop and test the system
4. Plan the next iteration with respect to the performance of the system just developed and tested.

This procedure like any other can be misused and abused, for the Spiral development procedure the main risk is "requirements creep" in quadrant four which creates more functionality and new iterations that cost more money and lengthen the development schedule.  Note that cumulative cost increases as the spiral grows, so a disciplined and resourceful Project engineer is needed to know how to control and when to stop the spiral.

Agile development has become the modern variant of the traditional methods presented above. While aimed at software systems , the principals of Agile development may be applied to the development of integrated systems composed of mechanical electronic and software components. The principals that define Agile Software development are not new, these ideas have always been held to be true by the most successful developers. These ideas are new because they have been stated and documented . When ideas are documented they solidify and can be disseminated for review and refinement. The 12 principles are  listed below:

1. The Highest  priority is to satisfy the customer through early delivery of valuable software.
2. Welcome challenging requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face to face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitly.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity --the art of maximizing the amount of work not done -- is essential.
11. The best architectures, requirements and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

• Capability Maturity Model Integration (CMMI)

• Agile Manifesto

• Agile Alliance