Software configuration change request management

For the sake of process efficiency it is important to ensure that the bureaucratic overhead associated with the Change Request Management process is consistent with the maturity of the product. In the later phases of the development lifecycle, the CRM process can be made more strict to ensure that necessary test and documentation resources can handle changes as well as assessing the potential instability that a change may introduce.

A project which is unable to tailor the level of control during the development process will not be running as efficiently as possible. As per approval of the change request the application will develop and the request will be closed on status.

The software-related documents and software release notes are the inputs to provide a working version of the software application. In this process to verify the developed software product as per the baselines or not.

Here we go for function requirement audit and physical audit of the software application. It is a technical review on the application workflow, process, configuration items, and change requests, etc to generate the status report in every phase of the software development life cycle process.

In this article we briefly discuss the software configuration management process which helps to track, managing and controlling the changes on the configuration items during the software development life cycle.

But most of the IT industry uses open-source software configuration management tool GIT as version control. This is a guide to Software Configuration Management. The software quality assurance authority, as part of a compliance auditing activity, might also perform this surveillance.

The use of integrated SCM tools with process control capability can make the surveillance task easier. Some tools facilitate process compliance while providing flexibility for the software engineer to adapt procedures. Other tools enforce process, leaving the software engineer with less flexibility. Surveillance requirements and the level of flexibility to be provided to the software engineer are important considerations in tool selection.

SCM measures can be designed to provide specific information on the evolving product or to provide insight into the functioning of the SCM process.

A related goal of monitoring the SCM process is to discover opportunities for process improvement. Measurements of SCM processes provide a good means for monitoring the effectiveness of SCM activities on an ongoing basis. These measurements are useful in characterizing the current state of the process as well as in providing a basis for making comparisons over time. Analysis of the measurements may produce insights leading to process changes and corresponding updates to the SCMP.

Software libraries and the various SCM tool capabilities provide sources for extracting information about the characteristics of the SCM process as well as providing project and management information. For example, information about the time required to accomplish various types of changes would be useful in an evaluation of the criteria for determining what levels of authority are optimal for authorizing certain types of changes and for estimating future changes.

Care must be taken to keep the focus of the surveillance on the insights that can be gained from the measurements, not on the measurements themselves. Discussion of software process and product measurement is presented in the Software Engineering Process KA.

Audits can be carried out during the software engineering process to investigate the current status of specific elements of the configuration or to assess the implementation of the SCM process. In-process auditing of SCM provides a more formal mechanism for monitoring selected aspects of the process and may be coordinated with the SQA function see topic 5, Software Configuration Auditing.

Software configuration identification identifies items to be controlled, establishes identification schemes for the items and their versions, and establishes the tools and techniques to be used in acquiring and managing controlled items. These activities provide the basis for the other SCM activities. One of the first steps in controlling change is identifying the software items to be controlled. Software configuration is the functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in a product.

It can be viewed as part of an overall system configuration. A configuration item CI is an item or aggregation of hardware or software or both that is designed to be managed as a single entity.

A software configuration item SCI is a software entity that has been established as a configuration item [1]. The SCM typically controls a variety of items in addition to the code itself. Software items with potential to become SCIs include plans, specifications and design documentation, testing materials, software tools, source and executable code, code libraries, data and data dictionaries, and documentation for installation, maintenance, operations, and software use.

Selecting SCIs is an important process in which a balance must be achieved between providing adequate visibility for project control purposes and providing a manageable number of controlled items.

Structural relationships among the selected SCIs, and their constituent parts, affect other SCM activities or tasks, such as software building or analyzing the impact of proposed changes. Proper tracking of these relationships is also important for supporting traceability. The design of the identification scheme for SCIs should consider the need to map identified items to the software structure, as well as the need to support the evolution of the software items and their relationships.

Software items evolve as a software project proceeds. A version of a software item is an identified instance of an item.

It can be thought of as a state of an evolving item. A variant is a version of a program resulting from the application of software diversity. The term is also used to refer to a particular version of a software configuration item that has been agreed on.

In either case, the baseline can only be changed through formal change control procedures. A baseline, together with all approved changes to the baseline, represents the current approved configuration. Commonly used baselines include functional, allocated, developmental, and product baselines.

The functional baseline corresponds to the reviewed system requirements. The allocated baseline corresponds to the reviewed software requirements specification and software interface requirements specification.

The developmental baseline represents the evolving software configuration at selected times during the software life cycle. Change authority for this baseline typically rests primarily with the development organization but may be shared with other organizations for example, SCM or Test. The product baseline corresponds to the completed software product delivered for system integration. The baselines to be used for a given project, along with the associated levels of authority needed for change approval, are typically identified in the SCMP.

Software configuration items are placed under SCM control at different times; that is, they are incorporated into a particular baseline at a particular point in the software life cycle.

The triggering event is the completion of some form of formal acceptance task, such as a formal review. Figure 6. This figure is based on the waterfall model for purposes of illustration only; the subscripts used in the figure indicate versions of the evolving items. The software change request SCR is described in section 3. In acquiring an SCI, its origin and initial integrity must be established.

Following approval, the item is incorporated into the software baseline according to the appropriate procedure. A software library is a controlled collection of software and related documentation designed to aid in software development, use, or maintenance [1]. It is also instrumental in software release management and delivery activities. For example, a working library could support coding and a project support library could support testing, while a master library could be used for finished products.

An appropriate level of SCM control associated baseline and level of authority for change is associated with each library. Security, in terms of access control and the backup facilities, is a key aspect of library management. The tool s used for each library must support the SCM control needs for that library — both in terms of controlling SCIs and controlling access to the library.

At the working library level, this is a code management capability serving developers, maintainers, and SCM. It is focused on managing the versions of software items while supporting the activities of multiple developers. At higher levels of control, access is more restricted and SCM is the primary user. These libraries are also an important source of information for measurements of work and progress. Software configuration control is concerned with managing changes during the software life cycle.

It covers the process for determining what changes to make, the authority for approving certain changes, support for the implementation of those changes, and the concept of formal deviations from project requirements as well as waivers of them. Information derived from these activities is useful in measuring change traffic and breakage as well as aspects of rework. This will prevent several steps of the review process and therefore save a lot of time.

Submitters of duplicate Change Requests should be added to the notification list of the original Change Request for future notifications regarding resolution. Admin Project Manager. Development Reject ed A Change Request in this state is determined by in the CCB Review Meeting or by the assigned team member to be an invalid request or more information is needed from the submitter.

If already assigned Open , the Change Request is removed from the resolution queue and will be reviewed again. A designated authority of the CCB is assigned to confirm. No action is required from the submitter unless deemed necessary, in which case the Change Request state will be changed to More Info. The owner automatically gets changed to the submitter who is notified to provide more data. Admin Opened A Change Request in this state has been determined to be "in scope" for the current release and is awaiting resolution.

It has been slated for resolution before an upcoming target milestone. It is defined as being in the "assignment queue". The meeting members are the sole authority for opening a Change Request into the resolution queue. If a Change Request of priority two or higher is found, it should be brought to the immediate attention of the QE or Development Manager. At that point they may decide to convene an emergency CCB Review Meeting or simply open the Change Request into the resolution queue instantly.

Project Manager Resolved Signifies that the resolution of this Change Request is complete and is now ready for verification. If the submitter was a member of the QE Department, the owner automatically gets changed to the submitting QE member; otherwise, it changes to the QE Manager for manual re-assignment. Development Department Test Failed A Change Request that fails testing in either a test build or a release build will be placed in this state.