Configuration Management

¿Why the change?

One of the main reasons why change occurs in software management and configuration is to improve efficiency and process quality. Software configuration and management processes can be complex and unwieldy, and as businesses and organizations grow and evolve, these processes may become outdated or unsuitable for the new needs.

Another common reason for change in the management and configuration of the software is the need to maintain the security and protection of company data. As the amount of data and systems being used, so does the risk of security breaches and data breaches. Therefore, it is necessary constantly update management and configuration processes and tools of the software to ensure that data is protected and compliance with the regulatory compliance requirements.

Maintenance vs CM

Maintenance
Refers to set of activities carried out to maintain or improve the functionality and the quality of the software after it has been delivered and put in use. These activities may include bug fixes, improvement performance, adding new features, etc.

Focuses on improving functionality and quality of the software after it has been delivered

CM
Process of identify, organize, and control changes to the software and in related artifacts (documentation, scripts, settings, etc). The CM focuses on ensuring that the software is built and delivered in a consistent and controlled manner, and that any changes to the software are traceable and reversible.

It focuses on ensuring that the software is build and deliver in a consistent and controlled manner, and that changes in the software are traceable and reversible.

Version vs Release of the Software Product

Version
Is a software iteration that generally has a number of associated version, which may include new features, improvements, bug fixes, and minor changes to the user interface. New versions of software usually be released to improve and add features to the product existing.

Refers to an iteration of the product that includes changes and improvements in its functionality

Software Release
Is a version of the product that is considered sufficiently stable and functional to be delivered to customers or end users. A release is made after they have been completed Rigorous testing and critical issues fixed that have been identified during testing. a release may also include updated documentation, guides user and other resources that help the end user to use the software effectively.

Refers to a specific version that has passed the tests and is stable and functional enough to be delivered to customers or end users.

Base line

In software configuration management, a baseline is an established and fixed reference that represents a specific and controlled state of configuration items in a software project at a given time. The baseline serves as a reference point for monitoring and controlling changes made during the software life cycle.

Let's imagine a software development project for a task management mobile application. In this case, an example of a software configuration management baseline might be:

    Base line 1.0:

  • Application source code files (all modules and components).
  • Design documents for the user interface and system architecture.
  • Database configuration files and connections.
  • Third-party libraries used in the project.
  • Media resource files (images, icons, etc.).
  • Technical documentation related to version 1.0.

In this example, Baseline 1.0 represents the initial and stable version of the task management mobile app. Configuration items mentioned, such as source code files, design and configuration documents, are part of the baseline and are considered the baseline state for the project at that time.

Starting from this baseline, any change or evolution in the software will be managed by controlling changes and establishing new baselines. For example, if new functionality is required to be added to the application, changes will be made to the source code files and other relevant elements. These changes will be managed, evaluated and, once approved, a new baseline will be established (for example, Baseline 2.0) that will include the updated elements and reflect the new state of the software.

The baseline provides a clear and stable reference point for the development, monitoring, and control of software changes throughout the project life cycle. In addition, it allows the traceability and auditing of the changes made, facilitates reproducibility and guarantees the consistency and integrity of the software in each version.