High-level Best Practice Six(6) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first five areas and there practices are already discussed.

Process

- Track change packages. Even though each file in a codeline has its revision
history, each revision in its history is only useful in the context of a set of related files. Change packages, not individual file changes, are the visible manifestation of software development. Some SCM systems track change packages for you; if yours doesn’t, write an interface that does.
- In order to make propagating logical changes from one codeline branch to another easy, tracking change packages has a benefit. However, it’s not enough to simply propagate change packages across branches; you must keep track of which change packages have been propagated, which propagations are pending, and which codeline branches are likely donors or recipients of propagations.
- SCM process should be able to distinguish between "What to do" and "What was done".
- Every process, policy, document, product, component, codeline, branch, and task in your SCM system should have an owner. Owners give life to these entities by representing them; an entity with an owner can grow and mature.
- The policies and procedures you implement should be described in living documents; that is, your process documentation should be as readily available and as subject to update as your managed source code.

High-level Best Practice Five(5) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first, second, third and fourth area and there practices are already discussed.

Builds

Builds are necessary to construct software from source files. The high level practices involved with this workspace are :
- In a build, the only inputs that are needed are the source files and the tools that are used. There is no place for procedures or yellow sticks. If setup procedures are there, automate them in scripts. If manual setup is there, document them in build instructions.
- There are chances that the input list is incomplete if the software cannot be build from the same inputs. So, the input list needs to be checked.
- When you are organizing original source files in a directory, you need to ensure that already built objects are kept away and do not contaminate the source files. Built objects (those files that get created during the building process) should be located in a different directory, away from the original source files (which are the files that have been created through a tool such as a code editor, or through notepad, or through code generation tools).
- Developers, test engineers, and release engineers should all use the same and easily available build tools.
- Build should be done often as end-to-end builds with regression testing (“sanity” builds) reveal integration problems introduced by check-ins and they produce link libraries and other built objects that can be used by developers.
- Build outputs and logs, including source file versions, tools and OS version info, compiler outputs, intermediate files, built objects, and test results should be kept for future reference.

High-level Best Practice Four(4) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first, second and third area and there practices are already discussed.

Change Propagation

Propagating file changes across branches needs to be managed. The practices involved with this work space are :
- Do not delay to propagate a change. When it’s feasible to propagate a change from one
branch to another (that is, if the change wouldn’t violate the target branch’s
policy), do it sooner rather than later.
- It is much easier to merge a change from a file that is close to the common
ancestor than it is to merge a change from a file that has diverged considerably.
This is because the change in the file that has diverged may be built upon
changes that are not being propagated, and those unwanted changes can
confound the merge process.
- Changes can be propagated by the owner of the target files, the person who make the original changes, or someone else.

High-level Best Practice Three(3) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first and second areas and there practices are already discussed.

Branching
In Software Configuration Management (SCM) systems, branching allows development to proceed simultaneously along more than one path while maintaining the relationships between the different paths. A branching strategy consists of the guidelines within an environment for the creation and application of codeline policies. There are different tools that support branching Creating a branching strategy consists of :
- identifying the categories of development that can be easily characterized,
- defining the differences and similarities between them,
- defining how they relate to each other, and
- expressing all of this information as codeline policies and branches.

High Level Practices associated with branching workspace are :
- Branch only when necessary.
- Don’t copy when you mean to branch.
- Branch on incompatible policy.
- To minimize the number of changes that need to be propagated from one branch to another, put off creating a branch as long as possible.
- Branch instead of freeze.

High-level Best Practice Two(2) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first area and its practices are already discussed.

The Codeline
It is a set of source programs or files required to develop a software. Codelines are branched, and the branches evolve into variant codelines embodying different releases.
The best practices are :
- Give each codeline a policy : It is the essential user’s manual for codeline SCM. The policy of the development codeline should state that it is not for release or the policy of the release codeline should state that it is not for testing or bug fixing. It specifies the check-ins for the codeline.
- Give each codeline an owner : After the policy is defined for a codeline, there would be situations where the policy is inapplicable or ambiguous. When the developers face these ambiguities, they will turn to the person who is in charge of the codeline. There has to be a owner of the codeline because if there would be no owner, the developer will create their own workarounds without documenting them.
- Have a mainline : A mainline is the branch of a codeline that evolves forever. A mainline provides an ultimate destination for almost all changes – both maintenance fixes and new features – and represents the primary, linear evolution of a software product.

High-level Best Practice One(1) in Software Configuration Management

Software configuration management (SCM) is a set of activities that are designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling changes that are imposed, and auditing and reporting on the changes that are made.
Software Configuration Management Best Practices are the techniques, policies and procedures for ensuring the integrity, reliability and reproducibility of developing software products.
When implementing SCM tools and processes, you must define what practices and policies to employ to avoid common configuration problems and maximize team productivity. There are six areas of SCM deployment, and some coarse-grained
best practices within each of those areas.
- Workspaces: It is the area where the engineers edit source files, build the software components they’re working on, and test and debug what they have built. The best practices for workspaces include:
. Don’t share workspaces.
· Don’t work outside of managed workspaces.
· Don’t use jello views: A file in your workspace should not change unless you
explicitly cause the change. A “jello view” is a workspace where file changes are
caused by external events beyond your control.
· Stay in sync with the code line.
· Check in often: Integrating your development work with other peoples’ work also
requires you to check in your changes as soon as they are ready.

Software Configuration Management Process

The SCM repository is the set of mechanisms and data structures that allow a software team to manage change in an effective manner. It provides the obvious functions of a DBMS but in addition, the repository performs or precipitates functions such as :
- data integrity.
- information sharing.
- tool integration.
- data integration.
- methodology.
- document standardization.
To achieve these functions, the repository is defined in terms of a meta-model.

Software Configuration Management Process :
A process defines the steps by which you perform a specific task or set of tasks. An SCM process is the way SCM is performed on your project—specifically, how an SCM tool is applied to accomplish a set of tasks.
- Identification of Artefacts
Early identification and change control of artefacts and work products is integral to the project. The configuration manager needs to fully identify and control changes to all the elements that are required to recreate and maintain the software product.
- Version Control
The primary goal of version control is to identify and manage project elements as they change over time. The Configuration Manager should establish a version control library to maintain all lifecycle entities. This library will ensure that changes (deltas) are controlled at their lowest atomic level eg documents, source files, scripts and kits etc.
- Change Request Management
Change Request management can be described as management of change/enhancement requests. Typically the Configuration Manger should set up a repository to manage these requests and support activities like status tracking, assignment etc.
- Configuration audit
Identification, version control, and change control help the software developer to maintain order in what would otherwise be a chaotic and fluid situation. But how can we ensure that the change has been properly implemented?
A software configuration audit complements the formal technical review by addressing the following questions :
- Has the change specified in the ECO been made? Have any additional modifications been incorporated.
- Has a formal technical review been conducted to assess technical correctness.
- Has the software process been followed?
- Has the change been highlighted in SCI?
- Have SCM procedures for noting the change, recording it, and reporting it been followed?
- Have all related SCIs been properly updated?

Software Configuration Management - Baselines

Change is a fact of life in software development. A baseline is a software configuration management concept that helps us to control change without seriously impeding justifiable change. Before a software configuration item becomes a baseline, change may be made quickly and formally. However once a baseline is established, we figuratively pass through a swinging one door. Changes can be made but a specific formal procedure must be applied to evaluate and verify each change.

In terms of software engineering, a baseline is a milestone in the development of software. A baseline is marked by the delivery of one or more software configuration items that have been approved as a consequence of a formal technical review. Software engineering tasks produce one or more software configuration items (SCIs). After SCIs are reviewed and approved, they are placed in a project database. When a member of a software team wants to make a modification to a baselined SCI, it is copied from the project database into the engineer's private
workspace. However, this extracted SCI can be modified only if SCM controls are followed.

The Software Configuration Management process applied to this project identifies many types of baselines;each of them has specific identification rule and minimum verification characteristics.
All the development artifacts (source code, makefile, documentation) are identified and managed under configuration.

- Working baseline:
* Description: this is a development baseline in the private working area of a developer. This baseline is not identified since it is a private one.
* Identification: none
* Minimum characteristics: none
- Unstable baseline:
* Description: this is a development baseline in the public area of CVS.
* Identification: this baseline is not identified. It is only accessible as the 'latest' one.
* Minimum characteristics: none
- Stable baseline:
* Description: this is a development baseline in the public area of CVS. This baseline identifies a consistent set of modifications or an important step during the implementation of a modification.
* Identification: a stable baseline is identified according to the involved GHOSTS component and the current date.
* Minimum characteristics: a stable baseline shall be at least compilable / linkable.
- Official baseline:
* Description: this is a user baseline in the public area of CVS. This baseline identifies a consistent set of modifications; those modifications are well implemented, verified and tested.
* Identification: an official baseline is identified according to the part of the involved GHOSTS component and the release identification.
* Minimum characteristics: an official baseline shall be fully implemented, verified and tested.

Software Configuration Management (SCM)

Configuration management(CM)is the discipline of controlling the evolution of complex systems; software configuration management (SCM) is its specialization for computer programs and associated documents. SCM differs from general CM in the following two ways. First, software is easier to change than hardware, and it therefore changes faster. Even relatively small software systems, developed by a single team, can experience a significant rate of change, and in large systems, such as telecommunications systems, the update activities can totally overwhelm manual configuration management procedures. Second, SCM is potentially more automatable
because all components of a software system are easily stored on-line.

The goals of SCM are :
* Configuration identification - Identifying configurations, configuration items and baselines.
* Configuration control - Implementing a controlled change process. This is usually achieved by setting up a change control board whose primary function is to approve or reject all change requests that are sent against any baseline.
* Configuration status accounting - Recording and reporting all the necessary information on the status of the development process.
* Configuration auditing - Ensuring that configurations contain all their intended parts and are sound with respect to their specifying documents, including requirements, architectural specifications and user manuals.
* Build management - Managing the process and tools used for builds.
* Process management - Ensuring adherence to the organization's development process.
* Environment management - Managing the software and hardware that host our system.
* Teamwork - Facilitate team interactions related to the process.
* Defect tracking - Making sure every defect has traceability back to the source.

Basic SCM Concepts :
defines the basic elements of a data base for software configuration management. The data base stores all software objects produced during the life-cycle of a project.
- Creation of Software Objects : A source object is a software object that is composed manually, for instance with an interactive editor. Creating a source object requires human action; it cannot be produced automatically.A derived object is generated fully automatically by a program, usually from other software objects. A program that produces derived objects is called a deriver. Examples of derivers are compilers, linkers, document formatters, pretty printers, cross referencers, and call graph generators.
- Structure of Software Objects : The body of a software object is either atomic or structured. An atomic object, or atom, has a body that is not decomposable for SCM; its body is an opaque data structure with a set of generic operations such as copying, deletion, renaming, and editing. A configuration has a body that consists of sub-objects, which may themselves have sub-objects, and so on. Configurations have two subclasses: composites and sequences. A composite object, or simply composite, is a record structure comprised of fields. Each field consists of a field identifier and s field value. A field value is either an object identifier or a version group identifier. A sequence is a list of object and version group identifiers. Sequences represent ordered multi-sets of objects.

Overview of Change Management - Software configuration management

Software configuration management is an umbrella activity that is applied throughout the software process. SCM identifies, controls, audits, and reports modifications that invariably occur while software is being developed and after it has been released to a customer. All information produced as part of software engineering becomes part of a software configuration. The configuration is organized in a manner that enables orderly management of change.

The software configuration is composed of a set of interrelated objects, also called software configuration items, that are produced as a result of some software engineering activity. In addition to documents, programs, and data, the development environment that is used to create software can also be placed under configuration control. All SCIs are stored within a repository that implements mechanisms and data structures to ensure data integrity, provides integration support for other software tools, supports information sharing among all members of the software team, and implements functions in support of version and change control.

Once a configuration object has been developed and reviewed, it becomes a baseline. Changes to a baselined object result in the creation of a new version of that object. The evolution of a program can be tracked by examining the revision history of all configuration objects. Basic and composite objects form an object pool from which versions are created. Version control is the set of procedures and tools for managing the use of these objects.

Change control is a procedural activity that ensures quality and consistency as changes are made to a configuration object. The change control process begins with a change request, leads to a decision to make or reject the request for change, and culminates with a controlled update of the SCI that is to be changed.

The configuration audit is a SQA activity that helps to ensure that quality is maintained as changes are made. Status reporting provides information about each change to those with a need to know. Configuration management for Web engineering is similar in most respects to SCM for conventional software. However, each of the core SCM tasks should be streamlined to make it as lean as possible, and special provisions for content management must be implemented.