During software development, the design, code and requirements are often changed and the changes occur at any time during the development. This easily changeable nature of software and the fact that changes often take place require that changes be done in a controlled manner. Software Configuration Management is the discipline for systematically controlling the changes that take place during development. The IEEE defines SCM as "SCM is the process of identifying and defining the items in the system, controlling the change of these items throughout their life cycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items".
The basic reason for having SCM, as with any other activities for a project, is that it has beneficial effects on cost, schedule, and quality of the product being developed. Project cost, schedule, and quality are the fundamental concerns that drive a software project. Changes, and rework required for the changes, can have an enormous adverse effect on the cost and quality of the product being developed. The fundamental reason for having SCM process is to control the changes so that they have minimal effect on cost, schedule, and quality. Software configuration management is a process independent of the development process largely because most development models cannot accommodate changes at any time during development. However, most cannot properly handle changes like requirements changes while coding is being done, code changes during system acceptance testing, etc. As such changes are a fact of life, they are handled by the software configuration management activities. The changes themselves are still performed by the development team, but approving the change, evaluating the impact of the change, decide what needs to be done to accommodate a change request, etc. are issues that are handled by SCM. In the way the development process is brought under the configuration control process, so that changes are allowed in a controlled manner for a waterfall type development process model. Note that SCM directly controls only the products of a process(most products of phases are called baselines) and only indirectly influences the activities producing the product.
Though configuration management is more general than change management, managing changes is its primary task, and it is theis aspect of it that we will focus on here.
SCM can be considered as having three major components:
- Software configuration identification
- Change Control
- Status accounting and auditing
These three components of SCM are directly derived from the IEEE definition of SCM.
Configuration Identification
The first requirement for any change management is to have a clearly agreed-on basis for change. This is, when a change is done, it should be clear to what the change has been applied. This requires baselines to be established. A baseline, once established, forms the basis of change. A baseline change is the changing of the established baseline, which is controlled by SCM.
A baseline also forms a reference point in the development of a system and is generally formally defined after the major phases in development. At the time it is established, a software baseline represents the software in the most recent state. After baseline changes(made through SCM), the state of the software is defined by the most recent baseline and the changes that were made. Some of he common baselines are functional or requirements baseline, design baseline, and product or system baseline. Functional or requirements baseline is generally the requirements document that specifies the functional requirements for the software. Design baseline consists of the different components in the software and their designs. Product or system baseline represents the developed system. I should be clear that a baseline is established only after the product is relatively stable. For example, there is no point establishing the first rough draft of SRS as the baseline, as it is still a "working" document. Only when the requirements are "frozon" is the baseline established.
Though the goal of SCM is to control the establishment and changes to these baselines, treating each baseline as a single unit for the purposes of change is undesirable, as the change may be limited to a very small portion of the baseline. For example, supporse only one module in a large system is changed. If we do not consider the product baseline for the system as consisting of many modules (or module hierarchies), then this change will be viewed as changing the product baseline, and a finer, module-level control cannot be established on the change.
For this reason, a baseline can consist of many software configuration items (SCIs) or items. An SCI is a document or an artifact that is explicitly placed under configuration control and that can be regarded as a basic unit for modification. A baseline essentially is an arrangement of a set of SCIs. That is, a baseline is a set of SCIs and the relationship between them. For example, a requirements baseline may consist of many requirement SCIs (i.e. each requirement is an SCI) and how these SCIs are related in the requirements baseline (e.g. in which order they appear). With a baseline consisting of many SCIs, a new issue arises for SCM: how to "build " a baseline from the SCIs. The basic problem of system building is how to get a consistent system from the SCIs. The basic problem of system building is how to get a consistent system from the SCIs, particularly when the SCIs might be getting changed and multiple versions of an SCI may exist. In other words, the system building procedure has to be such that it rebuilds the system if an SCI changes to make sure that the changes are reflected in the system and selects the proper version of SCIs. The first part of this problem is sometimes handled by tools like the Makefile. Makefile requires a definition of the system in terms of its components, dependencies between components, and how the system is to be constructed from the components. When a system build is done has changed since the last time the system was built. More advanced tools are needed to solve the issue of incorporating versions in a flexible manner.
Because of baseline consists of the SCIs and SCI is the basic unit for change control, the SCM process starts with identification of configuration items. There are no hard and fast rules for SCI selection, except that SCI should be a part of some baseline, and once identified, it is given an identifiable name and become the unit of change control. Frequently, the requirements or functional baseline has just one SCI – the requirements document.
At the code level, that is for the product baseline, generally multiple SCIs exist. Other approaches are also possible. Multiple SCIs are used at the code level because usually the change volume is the largest at the code level(almost any change requires some changes in the code). Furthermore, frequently a large number of developers are involved during the code activity, with different developers responsible for different parts. By having a finer granularity for SCI, assigning responsibility for change becomes easier, making it easier to control and tract changes. For defining SCIs, one practice is to have each separately compilable module as an SCI, with the name of the module being the name of the SCI. Another approach is to have each file(consisting of some modules or definitions) treated as an SCI, with the name of the filebeing the name of the SCI.
It should be clear that the SCIs being managed by SCM are not independent of one another ad there are dependencies between various SCIs. An SCI X is said to depend on another SCI Y, if change to Y might require a change to be made to X for X to remain correct or for the baselines to remain consistent.
A change request, though, might require changes be made to some SCIs; the dependency of other SCIs on the ones being changed might require that other SCIs also need to be changed. Clearly, the dependency between the SCIs needs to be properly understood when changes are being made. However, though it is possible to specify the dependencies, they are frequently not explicitly documented but are derived from the nature of the SCIs. For example, the SCI representing the design document depends on the SCI representing the requirements document. Frequently, in design documents, each design item specifies which requirements it implements. If a design baseline is considered as composed of many SCIs, this information can be used to understand the dependencies between different items in requirements and in design. In code, an SCI representing a module might depend on another module SCI, depending on the relationship between them. This dependency can generally be obtained from the design specifications. While doing change control, these dependencies are used to decide what needs to be changed for a change request.
Change Control
Once the SCIs are identified and their dependencies understood, the change control procedure of SCM can be applied. Most of the decisions regarding the change are generally taken by the configuration control board (CCB), which is a group of people responsible for configuration management, headed by the configuration manager(CM). For smaller project, the CCB might consist of just one (full-time or part-time) person (CM). Typically, for a project, the constitution of the CCB and the procedures it will follow are specified in the software configuration management plan. We will generally use CM to refer to the CCB.
Let us come back to the issue of what exactly is under the control of SCM. Typically, while an SCI is under development and is not visible to other SCIs, it is considered being in the working state. An SCI is the working state is not under SCM and can be changed freely. Once the developer is satisfied that the SCI is stable enough for it to be used by others, the SCI is given to the CM for review, and the item enters the state "under review". Once an item is in this state, it is considered as "frozen", and changes made to a private copy that the developer may have made are not recognized. The CM reviews the SCI (or get it reviewed), and if it is approved, enters it into a library, aft which the item is formally under SCM. The basic purpose of this review is to make sure that the item is of satisfactory quality and is needed by others, though the exact nature of review will depend on the nature of the SCI and the actual practice of SCM. For example, the review might entail checking if the item meets its specifications or if it has been properly unit tested. If the item is not approved, the developer may be given the item back and the SCI enters the working state again.
Once an SCI is in the library, it cannot be modified, even by the author/developer without the permission of the CM. An SCI under SCM can be changed only if he change has been approved by the CM.
Tidak ada komentar:
Posting Komentar