Software Development Life Cycle

DRAFT
The lifecycle methodology being used for this project will be based on that proposed by Booch, et al... It has several advantages, including minimizing risk, and reducing costs associated with software development. This lifecycle consists of four phases: inception, elaboration, construction, and transition. It involves the articulation of a vision together with the functional requirement early on in the life cycle. These statements are qualified by a number of high-level scenarios, which model the system behaviours based on what is currently known and understood. It also makes recognition of the fact that this early understanding is not perfect, and will in all probability need to be revisited later on in the project. This is the inception. Once the initial requirements and vision documents are produced, a series of architectural iterations form the elaboration phase. Also based on the output of the inception phase, a business plan is drawn up which will resource the elaboration. Each architectural iteration consists of the selection of one of the documented scenarios, and detailing the design. The design is not complete until working code demonstrates that the design is workable within the context of the existing requirements. The output from each architectual iteration, is either such working design (i.e. functional protype code) and/or a document which exposes weaknesses in the existing requirements, and proposes amendments. A working design is documented using scenarios which augment the existing high-level scenarios. These may explain in greater detail the implementation plans, or may fill in missing information. All code that is written will be fully commented using standard conventions and facilities such as those available with javadoc. Design information becomes merged and formalized for those aspects considered stable. As the various groups submit the amendment proposals, the team lead determines which aspects of the proposals are indeed problematic. The master documents are amended at the end of each iteration, in some cases necessitating additional analysis. It may be determined that the nature of the amendments is such that the project should be scrapped. Usually, a subsequent architectural iterations are used to refine elements of the design which are still nebulous, and to flesh out any remaining potential problem areas. With projects of average complexity, at least two iterations are envisioned. At the end of the elaboration phase, the architectural baseline is complete. The designs are refined are in a state that most of the items representing known risk are debunked or it is demonstrated that the work arounds are available, workable and reasonable. At this point the proposal for construction is brought before customer. The construction phase consists of a number of iterations of development, which progressively integrate working code from previous architectural iterations, with new code to implement base functionality. The goal of the first iteration focusses on getting a stable baseline of core functions. The baseline releases from each iteration are typically numbered 0.x.y where x loosely reflects the iteration, and y the patches applied against the stable 0.x release. The various groups feed their modules, and changes they require in the baseine code into group whose responsibility is the sustaining of the core functionality. It is this core group which is responsible for the incremental integrations and for supplying patches. The decision whether to accept the integration or to reject it is that of the core group. If the change alters the architecture too significantly, it may be held until the end of an iteration, or else the change will be deemed important enough that it forces a new release before end of the iteration. This latter is expected to be rare. The construction phase consists of a minimum of three iterations for a small project of moderate complexity. The transition phase, consists of a minimum of two transition iterations. The first iteration delivery is essentially a beta test, whereas the final iteration is live deployment. More complex deployments will have more iterations.

DRAFT

The lifecycle methodology being used for this project will be based on that proposed by Booch, et al... It has several advantages, including minimizing risk, and reducing costs associated with software development.

This lifecycle consists of four phases: inception, elaboration, construction, and transition.

It involves the articulation of a vision together with the functional requirement early on in the life cycle. These statements are qualified by a number of high-level scenarios, which model the system behaviours based on what is currently known and understood. It also makes recognition of the fact that this early understanding is not perfect, and will in all probability need to be revisited later on in the project. This is the inception.

Once the initial requirements and vision documents are produced, a series of architectural iterations form the elaboration phase. Also based on the output of the inception phase, a business plan is drawn up which will resource the elaboration.

Each architectural iteration consists of the selection of one of the documented scenarios, and detailing the design. The design is not complete until working code demonstrates that the design is workable within the context of the existing requirements. The output from each architectual iteration, is either such working design (i.e. functional protype code) and/or a document which exposes weaknesses in the existing requirements, and proposes amendments.

A working design is documented using scenarios which augment the existing high-level scenarios. These may explain in greater detail the implementation plans, or may fill in missing information.

All code that is written will be fully commented using standard conventions and facilities such as those available with javadoc.

Design information becomes merged and formalized for those aspects considered stable.

As the various groups submit the amendment proposals, the team lead determines which aspects of the proposals are indeed problematic. The master documents are amended at the end of each iteration, in some cases necessitating additional analysis. It may be determined that the nature of the amendments is such that the project should be scrapped.

Usually, a subsequent architectural iterations are used to refine elements of the design which are still nebulous, and to flesh out any remaining potential problem areas. With projects of average complexity, at least two iterations are envisioned.

At the end of the elaboration phase, the architectural baseline is complete. The designs are refined are in a state that most of the items representing known risk are debunked or it is demonstrated that the work arounds are available, workable and reasonable. At this point the proposal for construction is brought before customer.

The construction phase consists of a number of iterations of development, which progressively integrate working code from previous architectural iterations, with new code to implement base functionality. The goal of the first iteration focusses on getting a stable baseline of core functions.

The baseline releases from each iteration are typically numbered 0.x.y where x loosely reflects the iteration, and y the patches applied against the stable 0.x release.

The various groups feed their modules, and changes they require in the baseine code into group whose responsibility is the sustaining of the core functionality. It is this core group which is responsible for the incremental integrations and for supplying patches. The decision whether to accept the integration or to reject it is that of the core group. If the change alters the architecture too significantly, it may be held until the end of an iteration, or else the change will be deemed important enough that it forces a new release before end of the iteration. This latter is expected to be rare.

The construction phase consists of a minimum of three iterations for a small project of moderate complexity.

The transition phase, consists of a minimum of two transition iterations. The first iteration delivery is essentially a beta test, whereas the final iteration is live deployment. More complex deployments will have more iterations.