The following Configuration Life Cycle is intended as a general guideline but has been specifically considered for Project Teams using an iterative life cycle. It can be used in conjunction with model driven processes such as the Rational Unified Process (RUP) or agile methodologies such as eXtreme Programming (XP).

Requirement Management

Requirements will be defined through the Project for new development and Change Management for any changes to existing systems in production and under maintenance. All requirements should be documented. The Project Management Team is responsible for management of the requirements and expectations.

Analysis and Design

All requirements must follow the selected analysis and design methodology. In Model Driven Architecture (MDA), this would involve a visual model using the Unified Modelling Language (UML). The artifacts of the design can be stored in a Meta Repository and accessed by the construction team through a knowledge portal. Prototyping should be done as part of the Analysis and Design even though it involves construction. The Business Analysts and Software Architect will lead the analysis and design phase. An important work product of this process is the Test Plan and Test Packs. With eXtreme Programming teams, this process would involve the Planning Game and XP stories.

Construction Work Flow and Process

Input into each of the processes should occur only when preceding processes are “Satisfied”. Each of the process points in the configuration life cycle can follow one of two output flows. Either the output requirements are “Satisfied” or one or more “Defects” have been discovered.

The Unit Test is conducted by individual resource team members as part of the Private Construction. Private Construction can mean the standalone construction of modules or version on individual workstations. A Unit Test involves the testing and quality assurance of private units of source code. The application architecture will determine how these units are decomposed. Integration Construction involves the assembly, code review and quality assurance of the system as a whole.

An Integration Construction area should be established whereby one or more workstations are designated as the point where one or more team members work together in integrating and reviewing the code. Refactoring of code should be reverted into private construction. If any Computer Aided Software Engineering (CASE) tools are used for code automation, it would be in the Integration Construction that these would be used to ensure consistency and conformance to standards.

A build constitutes a compiled whole system and should be associated with a snapshot or baseline of the source code, all dependencies and metadata which includes component state and configuration.

Configuration Baseline

Baseline involves configuration and version management of builds into a central environment, preferably to a Meta Repository. A baseline should include all dependencies and documentation. This can be done using a version control system with a tool set and repository. If you are using a directory structure, there should be a server directory for “construction” with the “private” and “integration”. You can baseline a version by using a date time format sub directory such “20040101120000” for CCYYMMDDHHNNSS. CCYYMMDD format should suffice if done as an end of day process.

Testing

Ideally, in Private Construction, tests should build into the units of construction. Just as Unit Testing follows Private Construction, Systems Testing would follow Integration Construction. Acceptance Testing involves user acceptance of the system build. Note that the Test Plan and Test Packs should have been refined and agreed upon through the iteration of the life cycle. The user acceptance of a build would constitute that Build as a Release. Note that a Release means that it has already undergone User Acceptance, not that it still has to be tested for User Acceptance.

Quality Assurance Points

The main Quality Assurance Point in the life cycle is Integration Construction. However, QA points exist throughout the life cycle where outputs need to be verified for “Satisfied” or “Defects” states. Quality Assurance is broader than Testing and also involves conformance to standards. A Project Team can document their standards. As part of the Team Process, it would benefit the team to establish these standards not on a set of “Policies and Procedures” but on shared “Values, Principles and Practices”. Based on these, a set of Code Review Questions could be set that team members can keep and use during the construction phases. Code Review questions need not be cumbersome and can be simplified to allow for consideration of authoring conventions and quality attributes such as Completeness, Logic, Correctness, Reliability, Consistency, Traceability and Maintainability.

Deployment, Configuration and Change Management

Change Management depends on the deployment environment and corporate policies. It is important to consider the change procedures within the organisation beforehand rather than being impacted at the crucial stage of implementation. It is also important in managing iterations with iterative releases into production.

Note that the point of Production that follows Release does not mean simply deploying the system. It may rather involve a hand over of the system to a separate operational team which would include Help Desk and Support. It is important that Project Teams prepare for the Release and ensure that operational and technical manuals are available. Even if the project team is given the task of deploying and implementing the deliverable, they would be in a better state if they prepared to do this as if they were passing on the responsibility to a separate team.

Production should be the closure of the iteration from the team perspective. The last life cycle iteration should bring closure to the project. The Release and Production should involve robust Product Readiness activities to support the system deployment. This would involve establishing a team of Toolsmiths for installation kits, diagnostic and administration tools which should form part of the product architecture.