



Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Project Management is the art of maximizing the probability that a project delivers its goals on Time, to Budget and at the required Quality. This lecture handout was provided by Sir Debashis Koppale. It includes: Software, configuration, Managment, Control, Version, Change, Stop, Auditing, Maintinance, Interim, Baseline, Version
Typology: Study notes
1 / 6
This page cannot be seen from the preview
Don't miss anything!




2.14 Software Configuration management
b. Controlling Versions
Version control combines procedures and tools to manage different versions of configuration objects that are created during software product development. To control versions, you can use Version Control Register. In Version Control Register, you enter the details of components, such as component identification numbers, their versions, and dates of validity. It is advisable to release a baseline after a version is released. Baseline is a specification or a product that is formally reviewed and agreed upon. This serves as the basis for further development. Baseline can be changed only through formal change control procedures. A baseline consists of a set of SCIs that are logically related to each other. Baselines are established when subsequent changes to the SCIs need to be controlled. Version control is essential so that everybody uses only the latest version. Any kind of version mismatch might result in rework.
c. Controlling Changes
Uncontrolled change can lead to chaos. Change control combines human procedures and automated tools to provide a mechanism for controlling change. The purpose of change control is to monitor and control changes in order to baseline SCIs. There are various reasons that trigger changes. A problem report might call for a change. Similarly, suggestions or ideas from brainstorming sessions and feedback from clients can result in change. Modifications or addition to functionality and changes in environment can also cause changes. The Figure 1 explains the formal change control process using a flow chart.
Figure 1: Formal Change Control Process
A request for change triggers that change control procedure. Then request is logged in the change request register. Next, the change request number is recorded in the change request evaluation plan. The request is evaluated and analyzed to check if the change is valid. Change request is also evaluated in
Start
Change request is made
Change request is logged
Change request is evaluated
Outcome is notified
Is the Request Rejected?
Change request is implemented
Stop
Yes
Yes
No
No
Is the Request Deferred?
not being communicated. At times, those who should be pointing out the serious side effects caused by a change are not aware of the implementation of the change. There are also instances of version mismatch when teams are unaware of the latest version to be followed. To avoid such hazards due to lack of communication among the project team, changes are communicated among team members. Therefore, status reporting provides information about each change to those who need to know. Software configuration management takes care of changes in a software process. SCM identifies controls, audits, and reports modifications that occur during software development. SCM helps maintain the integrity of configurable items produced during software development.
Software Configuration Management Vs Software Maintenance
SCM is an integral part of SQA. SCM involves assessing the impact of the changes made during SQA activities and making decisions based on cost and benefit analysis. SCM can be defined as the art of identifying, organizing, and controlling changes in a software project with the objective of minimizing mistakes. SCM is different from software maintenance. Software maintenance is required after the software is delivered to the client and is put into operation. As opposed to this, SCM is a set of tracking and controlling activities that begins when a software project begins and ends only when the software is taken out of operation.
Baselines vs. Interim Versions
SCM differentiates between baselines and interim versions. A baseline is a tested and certified version of a system. Baselines can be assigned version numbers such as 1.0, 2.0, 3.0, and so on. A baseline usually undergoes intensive testing. Interim versions, on the other hand, have version numbers, such as 1.1 or 1.2. The interim version is a temporary version. Interim versions have a short life and survive only during bug fixing, testing, or debugging. However, interim versions also have a unique version number or name. Baselines are more visible with the marketing team and the vendors than the interim versions. However, as part of SCM, all versions of changes are saved, clearly labeled, and archived. Archiving is the process of maintaining controlled copies of prior versions. Archiving helps in re- creating earlier versions in the event of data loss or data corruption.
Effective Configuration Control
Effective configuration control requires effective and well-defined organization. Any configuration control method must be based on the following four concepts:
A clearly defined configuration management authority must be established. Configuration control standards, procedures and guidelines must be produced and distributed to the developers.
Configuration control cannot be effective without the necessary tools and facilities. A configuration management plan must be developed at the beginning of the project.
The configuration management environment consists of the resources necessary for the implementation of the configuration control plan.
Configuration control tools, including:
Automatic version control and Change control tools Monitoring, auditing and registration support utilities Storage facilities; a safe repository for all approved configuration items, including:
Guidelines for effective configuration management
The following are some additional guidelines for effective configuration management. Some of these guidelines are equally applicable to other management support functions. Configuration management requires authority in order to be effective. This authority must be clearly delegated by the project manager to the responsible engineers. Any configuration management plan will become meaningless if the plan cannot be enforced.
Blunt enforcement of any plan policy or standard is best avoided, whenever possible. One of the qualities of a good manager is the ability to apply policy with minimal enforcement. Whenever policies and standards are readily accepted by the developers, they are more willingly followed and there are fewer rejections of submitted material. This leads to a more efficient development process.
Configuration management should be implemented from the start of a software project. Many of the formal documents issued during the initial concept phase are crucial for the requirements and design phases, and must be placed under configuration control.
The early application of configuration management is especially important in rapid prototyping, spiral models, or other iterative development methodologies. These development approaches initially produce several