18 Software Configuration Management-2

SOFTWARE CONFIGURATION MANAGEMENT-2

 

Software Configuration Management (SCM) is an umbrella activity that is applied throughout the software process because change can occur at any time. Manages the effects of change throughout the software process. According to Bersoff, no matter where we are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle.

As software engineering work progresses, a hierarchy of software configuration items (SCIs)—a named element of information that can be as small as a single UML diagram or as large as the complete design document—is created. If each SCI simply led to other SCIs, little confusion would result. Unfortunately, another variable enters the process—change. Change may occur at any time, for any reason. However, there are four fundamental sources of change:

 

  • New business or market conditions dictate changes in product requirements or business rules.
  • New stakeholder needs demand modification of data produced by information systems, functionality delivered by products, or services delivered by a computer-based system.
  • Reorganization or business growth/downsizing causes changes in project priorities or software engineering team structure.
  • Budgetary or scheduling constraints cause a redefinition of the system or product.

ITEMS THAT REQUIRE CHANGE

 

The items that need change are data, requirements documents, designed documents, code, test documents, and project plan. Changes are essential due to the changes in technical requirements, changes in business requirements and changes in user requirements software models. The output of the software process is information that may be divided into three broad categories:

  1. Computer programs (both source level and executable forms),
  1. Work products that describe the computer programs (targeted at various stakeholders), and
  1. Data or content (contained within the program or external to it). The items that comprise all information produced as part of the software process are collectively called a software configuration.

Contents of software configuration documents

 

The software configuration documents consists of a number of items. They are System Specification details, documents on Software Project Planning, Software Requirements Specification documents, Preliminary User Manual, Design Specification documents, Source Code Listing, Test Plans/Procedures, Installation/Operation/User Manuals and Executable Software.

 

Software Configuration Management activities

 

Since, software configuration management is the art of identifying, organizing, and controlling modifications to the software being built by a programming team, it helps to maximize the productivity by minimizing mistakes. It includes a number of activities for managing the changes. They are

 

(1) identify change,

(2) control change,

(3) ensure that change is being properly implemented, and

(4) report changes to others who may have an interest.

 

All these four steps are necessary to control the changes using a systematic method.

 

Baselines

 

Change is a fact of life in software development. Customers want to modify requirements. Developers want to modify the technical approach. Managers want to modify the project strategy. Why all this modification? The answer is really quite simple that changes are natural and changes must be accommodated upto a certain level without problem and after this level it must be allowed using a change control procedure. In this process, changes are allowed up to the baseline. A baseline is a software configuration management concept that helps you to control change without seriously impeding justifiable change. In other words, a baseline is a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. Once a baseline is established, changes can be made only via a formal procedure, which evaluates and verifies each change.

 

ISSUES IN SCM

 

The various issues to be handled in SCM are how to manage the change request. In this scenario, change request must be provided only by the developers. If a customer needs some changes, the request must go to the developer and the developer will prepare the change request and submit to the change control management team. It will be evaluated by the team and they must permit to carry out the changes. Moreover, the software components must be searched and their status must be checked before making any changes. It is also necessary to check the side effects to be made by the current change. If there is a conflict which occurs due to change how to resolve that conflict is another issue. It also includes the methods for version maintenance and system update operations.

 

SCM Tasks

The following are the important SCM tasks:

  • Identification of objects in the software configuration
  • Version control
  • Change control
  • Configuration auditing
  • Status reporting

SCM Task: Identification of Objects

 

To control and manage software configuration items, each should be separately named and then organized using an object-oriented approach. Two types of objects can be identified namely basic objects and aggregate objects. A basic object is a unit of information that you create during analysis, design, code, or test. For example, a basic object might be a section of a requirements specification, part of a design model, source code for a component, or a suite of test cases that are used to exercise the code. An aggregate object is a collection of basic objects and other aggregate objects. Each object has a set of distinct features that identify it uniquely including name, description, list of resources and a “realization”.

 

SCM Task: Version Control

 

Version control combines procedures and tools to manage different versions of configuration objects that are created during the software process. It can be as simple as specifying a version number or as complex as a data structure which indicates specific types of functional changes that have been applied to the system.

 

A version control system implements or is directly integrated with four major capabilities:

    (1)   a project database (repository) that stores all relevant configuration objects

 

(2)   a version management capability that stores all versions of a configuration object (or enables any version to be constructed using differences from past versions)

 

(3)   a make facility that enables you to collect all relevant configuration objects and construct a specific version of the software. In addition, version control and change control systems often implement an issues tracking (also called bug tracking) capability that enables the team to record and track the status of all outstanding issues associated with each configuration object.

 

SCM Task: Change Control

 

It combines human procedures and automated tools to provide a mechanism for the control of changes. Moreover, the reality of change control in a modern software engineering context has been summed up beautifully by James Bach, Change control is vital. But the forces that make it necessary also make it annoying. Software engineers worry about change because a tiny perturbation in the code can create a big failure in the product. But it can also fix a big failure or enable wonderful new capabilities. Moreover, a single rogue developer could sink the project; yet brilliant ideas originate in the minds of those rogues, and a burdensome change control process could effectively discourage them from doing creative work. Bach recognizes that we face a balancing act. Too much change control and we create problems. Too little, and we create other problems. For a large software project, uncontrolled change rapidly leads to chaos. For such projects, change control combines human procedures and automated tools to provide a mechanism for the control of change. The following are the steps in change control procedure:

 

1.      Need for change is recognized

 

2.      User creates Change Request (CR)

 

3.      Developer evaluates CR, and produces report

 

4.      Change Control body decides, either

 

5.      Yes: ECO is queued (see next page)

 

6.      Maybe: Report rejected – need more info.

 

7.      No: CR is denied; user is informed

 

8.      Assign staff to implement ECO

 

9.      “Check-out” source code, document source

 

10.   Make the change(s)

 

11.  Review/audit the change(s)

 

12.  Establish a “baseline” for testing

 

13.  Perform SQA and testing activities

 

14.  “Check-in” source code and document source

 

15.  Promote Change Action for inclusion in next release

 

16.  Rebuild appropriate version

 

17.  Review/audit the change

 

18.  Include all changes in the release

 

Access Control

 

Since change control requires restricted access to the configuration objects, access control is necessary. In order to take an object from the data base, an engineering change order is generated by the Change Control body and it is required for “check-out” of the object. After changes are made and have been reviewed, the changed configuration item is ready for “check-in”. Access control governs which software engineers have the authority to access and modify a particular configuration object and hence it provides security.

 

SCM Task: Configuration Audit

 

A software configuration audit complements the technical review by assessing a configuration object for characteristics that are generally not considered during review. The audit asks and answers many questions including “How do we ensure that a change authorized by an engineering change order has been properly implemented?”. It also focuses on the conduct of formal technical reviews and software configuration audit. Here, formal technical review focuses on the technical correctness of the configuration object that has been modified. On the other hand, software configuration audit assess a configuration object for other characteristics. Therefore, it checks whether the changes are properly implemented.

SCM Task: Configuration Status Reporting

 

Configuration Status Reporting (CSR) (sometimes called status accounting) is an SCM task that answers the following questions:

 

(1) What happened?

(2) Who did it?

(3) When did it happen?

(4) What else will be affected?.

Each time a software configuration item is assigned new or updated identification, a CSR entry is made. Each time a change is approved by the change control authority (i.e., an engineering change order is issued), a CSR entry is made. Each time a configuration audit is conducted, the results are reported as part of the CSR task. Output from CSR may be placed in an online database or website, so that software developers or support staff can access change information by keyword category. In addition, a CSR report is generated on a regular basis and is intended to keep management and practitioners appraised of important changes.

SUMMARY

 

SCM has the following benefits:

  • Reduces the effort required to manage and effect change — improved productivity
  • Leads to better software integrity and security — increased quality
  • Generates information about the process — enhanced management control
  • Maintains a software development database — better record keeping and tracking
  • It identifies and makes the changes effectively.