Evolutionary Rapid Development

From Wikipedia, the free encyclopedia

This article may require cleanup to meet Wikipedia's quality standards.
Please discuss this issue on the talk page or replace this tag with a more specific message. This article has been tagged since September 2006.

Evolutionary Rapid Development or ERD is a software engineering technique developed by the Software Productivity Consortium, a technology development and integration agent for the Information Technology Office of DARPA.

Fundamental to ERD is the concept of composing software systems based on the reuse of components, the use of software templates and on an architectural template. Continuous evolution of system capabilities in rapid response to changing user needs and technology is highlighted by the evolvable architecture, representing a class of solutions. The process focuses on the use of small artisan-based teams integrating software and systems engineering disciplines working multiple, often parallel short-duration timeboxes with frequent customer interaction.

Key to the success of the ERD-based projects is parallel exploratory analysis and development of features, infrastructures, and components with and adoption of leading edge technologies enabling the quick reaction to changes in technologies, the marketplace, or customer requirements.^[9]

1 Significant Customer/End-User Participation
2 Tools and techniques
3 The Procsess
4 References

[edit] Significant Customer/End-User Participation

The vision for the system and how it could be used must evolve along with the users' understanding of their needs. As the system gains capability, the users become aware of additional needs and set updated priorities for the features to include in the system.

To elicit customer/user input, frequent scheduled and ad hoc/impromptu meetings with the stakeholders are held. Demonstrations of system capabilities are held to solicit feedback before design/implementation decisions are solidified. Frequent releases (e.g., beta) are made available for use to provide insight into how the system could better support user and customer needs. This assures that the system evolves to satisfy existing user needs.

[edit] Tools and techniques

The ERD process is structured to use demonstrated functionality rather than paper products as a way for stakeholders to communicate their needs and expectations. Central to this goal of rapid delivery is the use of the "time box" method. Time boxes are fixed periods of time in which specific tasks (e.g., developing a set of functionality) must be performed. Rather than allowing time to expand to satisfy some vague set of goals, the time is fixed (both in terms of calendar weeks and person-hours) and a set of goals is defined that realistically can be achieved within these constraints.

The ERD process is based on an aggressive strategy that systematically identifies and uses government, industry, or academia-provided components, tools, and technology as a basis for composing the system. The COTS-based approach for incorporating reuse into the development process leverages the use of templates and frameworks whenever possible; and in some cases may require that new templates be synthesized from existing components or example software.

The ERD process invests heavily in maintaining its human resources. Highly experienced individuals are cloistered together and provided liberal amounts of computer infrastructure, tooling, and access to technical literature and knowledge bases. The process includes a set of roles defining responsibilities within the development team. The roles establish a career path whereby junior individuals can participate in highly specialized programming roles and learn from more senior members through activities such as code reviews and testing using a test buddy approach.

[edit] The Procsess

Since it is an iterative strategy, evolutionary development allows for re-specifying the need and the technology as the user, business, and technology environments change. Unproductive iteration is controlled by an overriding vision, or concept, for the product and its use. Each iteration either further refines the vision or incrementally produces versions to satisfy all or part of the vision. Feedback between increments provides for both adjusting the vision and determining the features to implement across each iteration.

Analysis and planning for change is central to the ERD process. Cusp identification deals with identifying trends in the emergence and use of technology within an industry. This practice requires tracking the publishing and acceptance of standards, identifying changes in the marketplace for price/performance, observing the number of applications using a technology, and identifying trends within industry surveys. The objective is to position the development (e.g., the architecture) to anticipate and react to beneficial changes at the right time.

The design framework for the system is based on using existing published or de facto standards. The system is organized to allow for evolving a set of capabilities that includes considerations for performance, capacities, and functionality. The architecture is defined in terms of abstract interfaces that encapsulate the services and their implementation (e.g., COTS applications). The architecture serves as a template to be used for guiding development of more than a single instance of the system. It allows for multiple application components to be used to implement the services. A core set of functionality not likely to change is also identified and established.

To keep development from degenerating into a "random walk," long-range plans are defined to guide the iterations. These plans provide a vision for the overall system and set boundaries (e.g., constraints) for the project. Each iteration within the process is conducted in the context of these long-range plans. The time period that the long-range plan covers is extended as necessary. There is a continuum from concept through composition and deployment/enhancement. Decisions about the process or product are made from a life-cycle perspective.

Once an architecture is established, software is integrated and tested on a daily basis. This allows the team to assess progress objectively and identify potential problems quickly. Since small amounts of the system are integrated at one time, diagnosing and removing the defect is rapid. User demonstrations can be held at short notice since the system is generally ready to exercise at all times.