Methodology

The diagram above shows an overview of the effort expended during the initial development cycle of medium and large projects. Phases of the development cycle are shown across the top with the software development disciplines listed down the left side.

Subsequent iterations of the development cycle may look substantially different. For example, requirements and business modeling may be considerably smaller. Generally, the entire inception phase and the elaboration phase require less detail the second time around.

Not shown in the diagram above is the Evolution phase that begins when the project is put into production. It essentially represents the usage data that is collected while the product is being used. In cases where multiple iterations are planned from the beginning, the Evolution phase may overlap some of the other phases.

Emphasis on Architecture

Use cases are the main driver of our process over the whole lifecycle, but the design activities are centered around the notion of software architecture. The main focus of the early iterations of the process—mostly in the elaboration phase—is to produce and validate a software architecture which takes the form of an executable architectural prototype that gradually evolves to become the final system in later iterations.

By executable architecture, we mean a partial implementation of the system built to demonstrate selected system functions and properties. The purpose of executable architecture is to mitigate risks related to performance, throughput, capacity, reliability, so that the complete functional capability of the system may be added in the construction phase on a solid foundation, without fear of breakage.

Architecture is important for several reasons:

• It lets you retain control over the project, manage its complexity and maintain system integrity. A unifying, coherent structure is needed to organize the parts of the system methodically. It provides rules on how to grow the system without having its complexity explode beyond human understanding.
• It is an effective basis for large-scale reuse. Once the architecture has been designed for the domain being examined, future projects can utilize that structure as a method of getting the project rolling quickly. Many thorny development issues can be knocked out once and the technique used from project to project
• It provides a basis for project management. Planning and staffing are organized along the lines of major components. Development is partitioned across a set of small teams, each responsible for one or several parts of the system.

Component-based development

Component-based development is a process which:

• The application is built from discrete components which are developed relatively independently of one another.
• The application may be upgraded in smaller increments by upgrading only some of the components that comprise the application.
• Assembly components may be shared between applications, creating opportunities for reuse, but with the side effect of creating inter-project dependencies.

In defining a very modular architecture, you identify, design, develop, and test well-formed components. These components can be individually tested and gradually integrated to form the whole system.

Additionally, some of these components can be developed to be reusable, especially the components that provide solutions to common problems like user authentication. These reusable components, which may be larger than just collections of utilities or class libraries, form the basis of reuse within an organization, increasing overall software productivity and quality.