Figure 1: Acquisition Milestones and Phases
| Intro | Context | Processes | Planning | Tool Mgmt | Activities | Projects | Risks | Procurement | Metrics |
The framework in which the different phases occur is called the “Acquisition life cycle”. The generic model for this process is illustrated in Figure 1.
The life cycle process consists of decision points, or milestones, and periods of time, or phases. The project will approve passage from one phase to the next by officially accepting the phase upon completion of a successful milestone review.
The concept exploration phase, Phase 0, is the first phase of a product’s life cycle. If it occurs at all, it typically consists of competitive, parallel short-term concept studies performed to investigate alternative operations and design concepts. The purpose is to identify, define, and evaluate the advantages/disadvantages, risks, costs, etc. of promising operational concepts and product design alternatives. The studies result in project characteristics and costs of total systems as reflected by their conceptual designs. The results are reviewed at the Milestone I decision point where promising candidates may be selected for further definition and development. The design characteristics of the selected alternatives generally provide a functional baseline of the system.
This phase is also considered as the Inception phase or Business Opportunity Feasibility Study and Business plan phase.
Phase I is used to further define and refine the operational concept or concepts and those alternative design approaches determined by the Milestone I decision process to be the most promising. The functional baselines are further decomposed into their lower-tiered subsystems. The performance requirements of the product are then allocated down to the lower level functions (allocated baseline).
Phase II of the acquisition process is used to complete a stable design for a product which meets the performance requirements and is producible, supportable, and affordable. Product capabilities are demonstrated through testing to validate design assumptions, and deployment planning is initiated. Low rate initial production is begun during this phase to provide the minimum quantities required to support operational testing and other design validation activities and to establish an initial production base for the product. The allocated baseline of a product is transitioned into a full product baseline during this phase.
This phase is also known as the Design phase and is defined as the Elaboration phase with the Analysis phase.
Support activities respond to changes resulting from correction of noted deficiencies and other product baseline changes made to enhance producibility or otherwise improve the product. Additionally, they prepare for transition of the product to operations. Phase III is used to achieve and sustain an operational capability that satisfies mission needs.
This phase consist of the Construction and Transition phases together or Implementation and test phases.
Each stage has a definite completion point, a Milestone, at which the current stage is considered finished and the next stage is entered. If the integrated testing stage fails, it may be necessary to back up into one of the earlier stages, or the project may have to be abandoned.
This type of project is expected to span years, and, according to sources such as Archwise Architectural Consulting and AntiPatterns author William J. Brown:
In contrast, the competitiveness of the various industries may demand a turn-around time measured in weeks, not years, and even firmware-based hardware projects may expect to have revisions to ship before End-Of-Life. These demands cannot be satisfied by a Waterfall model; instead they require a continuous development model comprised of Stages with Transitions. Traditional projects can be mapped onto this model, but it also allows for incremental development, quick release schedules, and it demands tight integration with Configuration Management at every Stage and Transition. A diagram of such a model is given in Figure 2. {Edited to make more generic
In the incremental model, different increments of the overall project can be at different stages in the Life Cycle, and transitions take place according to the defined Configuration Management process.
{Configurable Items also include any compilers, applications, tools used to create the nightly/regular builds, as well as any third party components linked into or packaged with the build output.
Where Stage 3 had a "dev" sandbox, this Stage has a "QA" or "test" sandbox. Any components not previously integrated will be integrated here. Unit tests will be regressed, system tests (integration tests) will be performed, and the system will be both verified and validated. That is, it will be proven to perform correctly and according to specifications. Performance testing, destruction testing, non-functional requirement testing (such as security) belong to this stage. The team members will be QA, and the Configurable Items will be any tests not already configured, and all relevant test results.
Deployment results in an actual release version; there must be a Release Description that enumerates all Configurable Items from the previous stages, as well as the versions of any tools used to create the deployed product, where applicable. Team members for deployment will vary according to the actual product.
Traditional development models can be emulated by only recognizing the forward moving arrows in Figure 2 (those pointing downward), and inserting a "Milestone" event next to each arrow. Any time an upward-pointing path is followed, the whole development effort is brought back to that stage, and a serious project problem is likely.
Upward-pointing arrows in Figure 2 represent an action by some team member at the Stage where the arrow originates. The project manager or some part of the project team will determine the transitions from Stage 1 to Stage 3, but thereafter, forward-moving transitions (3 to 4 and 4 to 5) are managed by the CM team.
The defect report will be reviewed, assigned a status (accepted, rejected, deferred), and other characteristics such as severity, criticality, impact, and possible assignment, by the CM CCBN.
A media librarian, manages items which pertain to, but do not precisely belong to, the configuration effort. This could be training material, including reference books on tools used, standards manuals, even the media (CDs) containing the version(s) of the tools used for development and/or deployment.
The responsibility for the automation of build processes and other CM processes falls first to the CM Manager, but it could be delegated to the Tools Technician to facilitate, and then to the Build manager to use them in accordance with procedures that would be developed.
The Release Manager has the responsibility to assure that there is a deployment plan, a complete Release Description, and that the deployment/release is done accordingly for each Release.
Some of these things in the list have a fairly obvious cause and effect. For instance, it is obvious that if the project is underfunded, the Configuration Management team may be the third group reduced or eventually eliminated to save costs (after the process improvement and documentation teams). Also, like new businesses that are undercapitalized - they don't last long - and CM efforts don't either.
When it comes to Training, one can look at the training of the Configuration Management team just as easily as the entire project team. Without proper training in processes, procedures, tool usage, etc, there will be problems, albeit not as catastrophic as a lack of funding, but troublesome at best.
Scheduling is listed because all too often, projects are ruled and governed by schedules, and CM is rarely in a position to alter them. Therefore CM efforts and CM personnel are hard pressed to comply. Working too quickly and cutting corners, while not advised, is often required and encouraged of CM Professionals. CM Professionals must be ready for these demands and address them in a way that minimizes the negative impact on the Configured Item(s).
The lack of Management Savvy is another road block all too frequently encountered. If upper management has not been convinced of the role of CM in correct and timely delivery, it will not be supportive of CM, and the CM team's efforts will be difficult. The role of the CM Professional in this case is to educate, sell, and persuade key members of the management team in an effort to gain their support. Another problem with management when they are not very CM savvy is that management tends to make choices and decisions without consulting CM. As CM Professionals, we must be aware that this can happen and to be prepared for those times.
Poor Customer Service Attitude, apart from the funding concern, is perhaps one of the worst things that can happen to a CM team. It used to be called the "Total Quality Concept": the notion that everyone on your CM Team must treat everyone with whom they work (bosses and peers alike) as customers. A bad attitude can drive a team and a project down faster than a bad rumor.
Lastly, territoriality is the sense that some people have that their job is theirs and their work is theirs and no one shall interfere. It is also known as a strong sense of 'ownership'. The problem with this is that when members of your CM team have this isolationist attitude, the team relationships will be strained and will eventually break down. For efficiency, CM teams cannot abide this personality/practice/style in team members.
The aforementioned hindering influences all have opposites that apply here, and there are some specific favorable influences that can be mentioned. These would be good planning, common practices, and knowledgeable team members.
Good Planning from the beginning that includes Configuration Management will help ensure that a Configuration Management effort will succeed.
Having common practices between configuration efforts within an organization has great benefit not just from a cost savings perspective, but from an employee portability perspective, too. Those involved in development also enjoy unparalleled benefit from standard methods across projects.
Having team members aware of Configuration Management concerns makes the job of CM easier in that fewer problems will arise. Also, having CM team members aware of the development arena, the nature of the project, etc., makes for better communication and keeps favorable things happening.
The traditional hierarchical organization chart would put a Director of CM at the top. Then each Configuration Manager reporting to the Director would be on the second level followed by each Team member reporting to the configuration manager on the third.
There are smaller firms that have only one Configuration Manager and there isn't any true CM organization within which he/she fits.
The third is a matrixed organization where a Director of CM is responsible for the assignment of Configuration Managers (and associated teams) to projects out of a "pool" of Configuration Managers. A single CM may be responsible for multiple projects.
There is a fourth organization structure. It consists of one manager of a CM group with team members reporting directly to him. This team handles all projects. The responsibility is distributed by functionality instead of projects.
| Previous: Introduction | Next: CM Processes |