software configuration management
introduction
As discussed in Chapters 1 and 2, a software project starts with planning and objectives to be achieved for the project. During the planning stage, a lot of assumptions are made and accordingly a project management plan is prepared. However, during the course of project execution, these assumptions may change. For example, often scope as defined, recorded, and accepted by both customer and vendor organization may change. The scope is used as input for estimating size, effort, and schedule for delivery. Hence, any change in the scope adversely affects planned effort and schedule.
This scope creep" results in variations and the project manager is forced to re-plan the entire
project. As we know, a software project can have a number of work products during project execution. Some of them are programs, specifications and design documents, data, and user and training manuals. Unlike non-IT projects, the output from software projects can be changed. This is a unique advantage of software projects that provides flexibility to the project process. But this can be used by the
100 Software Project Management customers to
demand and change anything and everything at any point during project
execution. This adds to the complexity in project management and needs to be
well monitored through effective process management. In order to manage the
scope changes, there should be a well-defined process that will control and
manage these changes. This process is known as the configuration management (CM) process,
which helps in systematically controlling any changes in the project.
The software CM process is a systematic process
of controlling and organizing different procedures and activities so that work
products can accommodate the changes and be in sync with the scope and
objectives of the project. This helps in delivering good quality end products
as planned during the project planning stage. These end products are
specification documents, source codes, a library of all executables, and any
related document. These end products would have undergone many changes and
revisions during the course of project execution. In fact, there will be more
than one version of each document at the final stage. For maintaining the quality
and consistency of these deliverables, all these versions should be tracked
properly so that the correct version of each document should be delivered. As
we know, a project is broken into smaller modules and work progresses in
parallel with many teams working together. As the project progresses, changes
to the scope and requirements happen, these changes are done because of many
reasons. One of the reasons would be the business needs of the end-users of the
application, who would like to use certain modules of the software at the
earliest; this changes the priority of delivery schedule and leads to changes
in the work products. This implies that the project team has to ensure that the correct
version of the end products containing the prioritized delivery schedule is
delivered. This process of delivering the correct version of the end products is
ensured by the CM process.
The need for the CM process comes from the fact that
the development models in software engineering cannot accommodate any changes
to the scope during the execution cycle. Models such as iterative and spiral
have provisions to go back to their previous lifecycle stages and compare work
products with respect to the requirements, but they do not have provisions for
allowing any changes to the scope. In reality, changes to the scope happen as
the customer changes his/her mind, and not acceding to these changes will not
be prudent from the business point of view. The software has to be produced while
accommodating these changes and still objectives of the project should be met.
This definitely requires a proper and effective process and the CM process
helps in achieving proper version control of different software units.
No comments:
Post a Comment