What is the relationship between scm and software maintenance

Verbal Ability. Interview Questions. Company Questions. Artificial Intelligence. Cloud Computing. Data Science. Angular 7. Machine Learning. Data Structures. Operating System. Computer Network. Compiler Design. Computer Organization. Discrete Mathematics. Ethical Hacking. Computer Graphics. Web Technology. Cyber Security. C Programming. Control System. 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.

The first step in managing changes to controlled items is determining what changes to make. The software change request process see a typical flow of a change request process in Figure 6.

A change request CR is a request to expand or reduce the project scope; modify policies, processes, plans, or procedures; modify costs or budgets; or revise schedules [1]. Requests for changes to software configuration items may be originated by anyone at any point in the software life cycle and may include a suggested solution and requested priority.

One source of a CR is the initiation of corrective action in response to problem reports. Regardless of the source, the type of change for example, defect or enhancement is usually recorded on the Software CR SCR.

This provides an opportunity for tracking defects and collecting change activity measurements by change type. Once an SCR is received, a technical evaluation also known as an impact analysis is performed to determine the extent of the modifications that would be necessary should the change request be accepted. A good understanding of the relationships among software and, possibly, hardware items is important for this task.

Finally, an established authority — commensurate with the affected baseline, the SCI involved, and the nature of the change — will evaluate the technical and managerial aspects of the change request and either accept, modify, reject, or defer the proposed change. The authority for accepting or rejecting proposed changes rests with an entity typically known as a Configuration Control Board CCB. In smaller projects, this authority may actually reside with the leader or an assigned individual rather than a multiperson board.

The composition of the CCBs used for a given system varies depending on these criteria an SCM representative would always be present. All stakeholders, appropriate to the level of the CCB, are represented.

The activities of the CCB are typically subject to software quality audit or review. An effective software change request SCR process requires the use of supporting tools and procedures for originating change requests, enforcing the flow of the change process, capturing CCB decisions, and reporting change process information.

A link between this tool capability and the problem-reporting system can facilitate the tracking of solutions for reported problems. Approved SCRs are implemented using the defined software procedures in accordance with the applicable schedule requirements.

Since a number of approved SCRs might be implemented simultaneously, it is necessary to provide a means for tracking which SCRs are incorporated into particular software versions and baselines.

As part of the closure of the change process, completed changes may undergo configuration audits and software quality verification—this includes ensuring that only approved changes have been made.

The software change request process described above will typically document the SCM and other approval information for the change.

Changes may be supported by source code version control tools. These tools allow a team of software engineers, or a single software engineer, to track and document changes to the source code.

These tools provide a single repository for storing the source code, can prevent more than one software engineer from editing the same module at the same time, and record all changes made to the source code. Software engineers check modules out of the repository, make changes, document the changes, and then save the edited modules in the repository. If needed, changes can also be discarded, restoring a previous baseline. More powerful tools can support parallel development and geographically distributed environments.

These tools may be manifested as separate, specialized applications under the control of an independent SCM group. They may also appear as an integrated part of the software engineering environment.

Finally, they may be as elementary as a rudimentary change control system provided with an operating system. Next SlideShares. You are reading a preview. Create your free account to continue reading. Sign Up. Upcoming SlideShare. Embed Size px. Start on. Show related SlideShares at end. WordPress Shortcode.

Share Email. Top clipped slide. Download Now Download Download to read offline. Software maintenance and configuration management, software engineering Jan. Rupesh Vaishnav Follow. Assistant Professor.

Software Configuration Management. Software design, software engineering. Software as a service, software engineering. Requirement analysis and specification, software engineering.

Quality assurance and management, software engineering. Managing software project, software engineering.