Configuration management is the process of tracking and controlling changes to software in terms of requirements, design, features, and product development.
The IEEE defines it as “the process of identifying and defining elements in a system, controlling changes to those elements during their lifecycle, recording and reporting the status of elements and change requests, and verifying that elements are complete and correct.”
As a general rule, after the SRS is completed, there will be less chance of changes by the user. If they occur, changes are considered only with prior approval from senior management as there is potential for cost and time overruns.
basic
An SDLC phase is considered completed if it is a baseline, i.e. the baseline is the measurement that determines the fullness of the phase. A phase is basic when all activities related to it are completed and well documented. If it was not the last phase, its output will be used in the next immediate phase.
Configuration management is the administrative discipline of an organization that takes care of the occurrence of any changes (process, requirements, technological, strategic, etc.) after a phase is defined. CM keeps track of any changes in the software.
Change control
Change control is a configuration management function that ensures that all changes made to a software system are consistent and implemented in accordance with organizational rules and regulations.
Changing the product configuration goes through the following steps −
Identification − The change request comes from an internal or external source. Once a change request has been formally identified, it is properly documented.
Validation – Checks the validity of the change request and confirms the procedure for processing it.
Analysis – The impact of the change request is analyzed in terms of schedule, cost, and effort required. The overall impact of the proposed change on the system is analyzed.
Control. If a proposed change affects too many objects in the system or is unavoidable, it is imperative to obtain approval from higher authorities before the change is incorporated into the system. Decided whether to make changes or not. If it is not, the change request is formally rejected.
Execute – If it was decided in the previous step to complete the change request, this step takes the appropriate action to implement the change, with a thorough review if necessary.
Close Request – The change is reviewed for proper implementation and merging with the rest of the system. This new software change has been properly documented and the request is officially closed.
Identification − The change request comes from an internal or external source. Once a change request has been formally identified, it is properly documented.
Validation – Checks the validity of the change request and confirms the procedure for processing it.
Analysis – The impact of the change request is analyzed in terms of schedule, cost, and effort required. The overall impact of the proposed change on the system is analyzed.
Control. If a proposed change affects too many objects in the system or is unavoidable, it is imperative to obtain approval from higher authorities before the change is incorporated into the system. Decided whether to make changes or not. If it is not, the change request is formally rejected.
Execute – If it was decided in the previous step to complete the change request, this step takes the appropriate action to implement the change, with a thorough review if necessary.
Close Request – The change is reviewed for proper implementation and merging with the rest of the system. This new software change has been properly documented and the request is officially closed.
Project Management Tools
Risk and uncertainty increase several times with the size of a project, even when the project is developed according to established methodologies.
Tools are available to help you manage projects effectively. Some are described –
Gantt Chart
Gantt charts were developed by Henry Gantt (1917). It represents the schedule of the project in terms of time periods. This is a horizontal bar chart with bars representing activities and time scheduled for project activities.
PERT Chart
The PERT (Program Evaluation & Review Technique) diagram is a tool that depicts a project as a network diagram. It is able to graphically represent major project events both in parallel and sequentially. Events that occur one after the other show the dependence of a later event on the previous one.
PERT Chart
Events are displayed as numbered nodes. They are linked by labeled arrows that represent the sequence of tasks in the project.
Resource histogram
It is a graphical tool that contains a bar chart or chart representing the amount of resources (usually skilled personnel) needed over a given time for an event (or phase) of a project. The resource histogram is an effective tool for planning and coordinating personnel.
Histogram tableHistogram chart
Critical Path Analysis
This tool is useful for recognizing interdependent tasks in a project. It also helps to find the shortest or critical path to complete the project successfully. As with the PERT chart, each event is allocated a specific period of time. This tool shows the dependency of an event, assuming that an event can only move to the next one if the previous one is completed.
Events are organized according to their earliest possible start time. The path between the start and end node is a critical path that cannot be further reduced, and all events must be executed in the same order.
Software requirements
The software requirements are a description of the features and functionality of the target system. Requirements convey user expectations of a software product. Requirements can be obvious or hidden, known or unknown, expected or unexpected from the client’s point of view.
Technique Requirement
The process of collecting software requirements from a client, analyzing them, and documenting them is known as requirements development.
The purpose of Requirements Engineering is to develop and maintain a complex and descriptive document called a System Requirements Specification.
Engineering Process Requirement
This is a four-step process that includes:
Feasibility Study
Gathering Requirements
Software requirements specification
Checking software requirements
Let’s look at the process in a nutshell −