The goal of the elaboration phase is to baseline the architecture of the system to provide a stable basis for the bulk of the design and implementation effort in the construction phase. The architecture evolves out of a consideration of the most significant requirements (those that have a great impact on the architecture of the system) and an assessment of risk. The stability of the architecture is evaluated through one or more architectural prototypes.

The primary objectives of the elaboration phase include:

• To ensure that the architecture, requirements and plans are stable enough, and the risks sufficiently mitigated to be able to predictably determine the cost and schedule for the completion of the development. For most projects, passing this milestone also corresponds to the transition from a light-and-fast, low-risk operation to a high cost, high risk operation with substantial organizational inertia.

• To address all architecturally significant risks of the project

• To establish a base-lined architecture derived from addressing the architecturally significant scenarios, which typically expose the top technical risks of the project.

• To produce an evolutionary prototype of production-quality components, as well as possibly one or more exploratory, throw-away prototypes to mitigate specific risks such as:

• design/requirements trade-offs

• component reuse

• product feasibility or demonstrations to investors, customers, and end-users.

• To demonstrate that the baselined architecture will support the requirements of the system at a reasonable cost and in a reasonable time.

• To establish a supporting environment.

In order to achieve this primary objectives, it is equally important to set up the supporting environment for the project. This includes creating a development case, create templates, guidelines, and setting up tools.

• Refining the Vision, based on new information obtained during the phase, establishing a solid understanding of the most critical use cases that drive the architectural and planning decisions.

• Creating and baselining detailed iteration plans for the construction phase.

• Refining the development case and putting in place the development environment, including the process, tools and automation support required to support the construction team.

• Refining the architecture and selecting components. Potential components are evaluated and the make/buy/reuse decisions sufficiently understood to determine the construction phase cost and schedule with confidence. The selected architectural components are integrated and assessed against the primary scenarios. Lessons learned from these activities may well result in a redesign of the architecture, taking into consideration alternative designs or reconsideration of the requirements.

At the end of the elaboration phase is the second important project milestone, the Lifecycle Architecture Milestone. At this point, you examine the detailed system objectives and scope, the choice of architecture, and the resolution of the major risks.

• The architecture is stable.

• Executable prototypes have demonstrated that the major risk elements have been addressed and have been credibly resolved.

• The iteration plans for the construction phase are of sufficient detail and fidelity to allow the work to proceed.

• The iteration plans for the construction phase are supported by credible estimates.

• All stakeholders agree that the current vision can be met if the current plan is executed to develop the complete system, in the context of the current architecture.

• Actual resource expenditure versus planned expenditure are acceptable.

The project may be aborted or considerably re-thought if it fails to reach this milestone.

Prototypes are used in a directed way to reduce risk. Prototypes can reduce uncertainty surrounding:

• The business viability of a product being developed

• The stability or performance of key technology

• Project commitment or funding: building a small proof-of-concept prototype

• The understanding of requirements

• The look and feel of the product, its usability.

A prototype can help to build support for the product by showing something concrete and executable to users, customers and managers.

The nature and goal of the prototype must remain clear, however, throughout its lifetime. If you don't intend to evolve the prototype into the real product, don't suddenly assume that because the prototype works it should become the final product. An exploratory, behavioral prototype, intended to very rapidly try out some user-interface, rarely evolves into a strong, resilient product.

You can view prototypes in two ways: what they explore; and how they evolve or what is their outcome.

In the context of the first view - what they explore - there are two main kinds of prototypes:

• A behavioral prototype, which focuses on exploring specific behavior of the system.

• A structural prototype, which explores some architectural or technological concerns.

In the context of the second view - their outcome - there are also two kinds of prototypes:

• An exploratory prototype, which is thrown away when done, also called a throw-away prototype.

An exploratory prototype is designed to be like a small "experiment" to test some key assumption about the project, either functionality or technology or both. It might be something as small as a few hundred lines of code, created to test the performance of a key software or hardware component. Or it may be a way of clarifying requirements, a small prototype developed to see if the developer understands a particular behavioral or technical requirement.

Exploratory prototypes tend to be intentionally "throw-away", and testing of them tends to be informal. The design of exploratory prototypes tends to be very informal, and also tends to be the work of one or two developers at most.

Evolutionary prototypes, as their name implies, evolve from one iteration to the next. While not initially production quality, their code tends to be reworked as the product evolves. In order to keep rework manageable, they tend to be more formally designed and somewhat formally tested even in the early stages. As the product evolves, testing becomes formalized, as usually does design.

Behavioral prototypes tend to be exploratory prototypes; they do not try to reproduce the architecture of the system to be developed but instead focus on what the system will do as seen by the users (the "skin"). Frequently, this kind of prototype is "quick and dirty," not built to project standards. For example, Visual Basic may be used as the prototyping language, while C++ is intended for the development project. Exploratory prototypes are temporary, are done with minimal effort, and are thrown away once they have served their purpose.

Structural prototypes tend to be evolutionary prototypes; they are more likely to use the infrastructure of the ultimate system, (the "bones"), and are more likely to evolve into becoming the real system. If the prototype is done using the "production" language and tool set, there is the added advantage of being able to test the development environment and let some of the personnel get familiar with new tools and procedures.

Updated and reviewed. New risks are likely to be architectural in nature, primarily relating to the handling of non-functional requirements

Refined based on early project experience. The development environment, including the process, tools and automation support required to support the construction team will have been put in place.

Software Architecture Document

Created and baselined, including detailed descriptions for the architecturally significant use cases (use-case view), identification of key mechanisms and design elements (logical view), plus definition of the process view and the deployment view (of the Deployment Model) if the system is distributed or must deal with concurrency issues.

The design model is an object model describing the realization of use cases, and serves as an abstraction of the implementation model and its source code. The design model is used as essential input to activities in implementation and test.

Defined and baselined. Use-case realizations for architecturally significant scenarios have been defined and required behavior has been allocated to appropriate design elements. Components have been identified and the make/buy/reuse decisions sufficiently understood to determine the construction phase cost and schedule with confidence. The selected architectural components are integrated and assessed against the primary scenarios. Lessons learned from these activities may well result in a redesign of the architecture, taking into consideration alternative designs or reconsideration of the requirements.

The data model is a subset of the implementation model which describes the logical and physical representation of persistent data in the system. It also includes any behavior defined in the database, such as stored procedures, triggers, constraints, etc.

The implementation model is a collection of components, and the implementation subsystems that contain them. Components include both deliverable components, such as executables, and components from which the deliverables are produced, such as source code files.

Refined, based on new information obtained during the phase, establishing a solid understanding of the most critical use cases that drive the architectural and planning decisions

The Software Development Plan is a comprehensive, composite artifact which gathers all information required to manage the project. It encloses a number of artifacts developed during the Inception phase and is maintained throughout the project.

The guidelines used to support the work.

Iteration plan for the construction phase completed and reviewed

The use-case model is a model of the system's intended functions and its environment, and serves as a contract between the customer and the developers. The use-case model is used as an essential input to activities in analysis, design, and test.

A use-case model (approximately 80% complete)—all use cases having been identified in the use-case model survey, all actors having been identified, and most use-case descriptions (requirements capture) have been developed.

The Supplementary Specifications capture the system requirements that are not readily captured in the use cases of the use-case model. Such requirements include:

• Legal and regulatory requirements and application standards.

• Quality attributes of the system to be built, including usability, reliability, performance and supportability requirements.

• Other requirements such as operating systems and environments, compatibility requirements, and design constraints.