Configuration management (CM) is the processes of controlling, coordinate, and tracking the Standards and procedures for managing changes in an evolving software product. Configuration Testing is the process of checking the operation of the software being tested on various types of hardware.
Configuration management involves the development and application of procedures and standards to manage an evolving software product. This can be seen as part of a more general quality management process. When released to CM, software systems are sometimes called baselines, as they are a starting point for further development.
The best bet in this situation is for the testers to go through the process of reporting whatever bugs or blocking-type problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules, and indicates deeper problems in the software development process (such as insufficient unit testing or insufficient integration testing, poor design, improper build or release procedures, etc.) managers should be notified, and provided with some documentation as evidence of the problem. Configuration management can be managed through.
- Version control.
- Changes made in the project.
Version Control and Release management
Version is an instance of system, which is functionally distinct in some way from other system instances. It is nothing but the updated or added features of the previous versions of software. It has to be planned as to when the new system version is to be produced and it has to be ensured that version management procedures and tools are properly applied.
Release is the means of distributing the software outside the development team. Releases must incorporate changes forced on the system by errors discovered by users and by hardware changes. They must also incorporate new system functionality.
Changes made in the project
This is one of most useful way of configuring the system. All changes will have to be maintained that were made to the previous versions of the software. This is more important when the system fails or not meeting the requirements. By making note of it one can get the original functionality. This can include documents, data, or simulation.
This starts at the early phases of the project and must define the documents or document classes, which are to be managed. Documents, which might be required for future system maintenance, should be identified and included as managed documents. It defines
- The types of documents to be managed
- Document-naming scheme
- Who takes responsibility for the CM procedures and creation of baselines
- Polices for change control and version management.
This contains three important documents are as follows:
- Change management items.
- Change request documents.
- Change control board. (CCB)
Change management: Software systems are subject to continual change requests from users, from developers, from market forces. Change management is concerned with keeping, managing of changes and ensuring that they are implemented in the most cost-effective way.
Change request form: Definition of change request form is part of CM planning process. It records changes required, reason "why change -was suggested and urgency of change ( from requestor of the change). It also records change evaluation, impact analysis, change cost and recommendations (System maintenance staff), A major problem in change management is tracking change status. Change tracking tools keep track the status of each change request and automatically ensure that change requests are sent to the right people at the right time. Integrated with Email systems allowing electronic change request distribution.
Change control board: A group, who decide, whether or not they are cost-effective from a strategic, organizational and technical viewpoint, should review the changes. This group is sometimes called a change control board and includes members from project team.