Software Configuration Management

A major part in Software Development Process

coverage. In the early 80s SCM focussed in programming in the large (versioning, rebuilding, composition), in the 90s in programming in the many (process support, concurrent engineering), late 90s in programming in the wide (web remote engineering). Hence, in short software configuration management (SCM) is the task of tracking and controlling changes in the software.
II.

I.

INTRODUCTION

SCM encapsulates the practices and procedures for administering source code, producing software development builds, controlling change, and managing software configurations. More specifically, SCM ensures the integrity, reliability and reproducibility of developing software products from planning to release. Configuration management practices include revision control and the establishment of baselines. SCM concerns itself with answering the question "Somebody did something, how can one reproduce it?" Often the problem involves not reproducing "it" identically, but with controlled, incremental changes. Answering the question thus becomes a matter of comparing different results and of analysing their differences. Traditional configuration management typically focused on controlled creation of relatively simple products. SCM emerged as a discipline soon after the so called software crisis was identified, i.e. when it was understood that programming does not cover everything in Software Engineering (SE), and that other issues were hampering SE development, like architecture, building, evolution and so on. SCM emerged, during the late 70s and early 80s, as an attempt to address some of these issues; this is why there is no clear boundary to SCM topic

SHORT HISTORY

In the 80s, the first systems were built in house and focused closely on file control. Most of them were built as a set of Unix scripts over RCS (a simple version control tool) and Make (for derived object control). From this period we can mention DSEE [31], the only serious commercial product, which introduced the system model concept which was an Architecture Description Language ancestor; NSE [36] which introduced workspace and cooperative work control; Adele which introduced a specialized product model with automatic configuration building [15], and Aides de Camp (now TRUE software) which introduced the change set (see later). The first real SCM products appeared in the early 90s. These systems are much better. They often use a relational database but still rely on file control, they provide workspace support, but no or built-in process support. This generation included Clear Case [32] (DSEE successor) which introduced the virtual file system and Continuous which

introduced, with Adele, explicit process support [20]. Continuus and Clear Case are currently the market leaders. In the second half of the 90s, process support was added and most products matured. This period saw the consecration of SCM, as a mature, reliable and essential technology for successful software development; the SCM market was over $1 billion sales in 1998. Many observers consider SCM as one of the very few Software Engineering successes.
III.

crucial. Software configuration management can help. The attitude of many people I've encountered when it comes to the topic of software configuration management is a reluctance by members of an intranet team to endure another layer of perceived bureaucracy that makes it more difficult to get their job done. I already have more work than any one person can possibly do with deadlines that often seem impossible. However... Have you ever wished that you could go back to a specific version of code in an application? Have you ever needed to determine what pieces make up a particular build or release? Have you ever needed to determine the state (development, test, or production) of the life cycle of a particular file? Have you ever needed to determine who did what to what and when on a particular file? Have you ever received a visit from your friends the auditors? If so, you should consider using a software configuration management tool. As I'm sure you are aware, software development is an increasingly complex and dynamic activity. This development frequently occurs in teams, often in geographically distinct locations, which perform concurrent development on the same project. Multiply this by the numerous projects and subprojects for which one team may be responsible and the result is even more overwhelming. Reduced time to market and increasingly complex code and applications only add to these challenges. The principles of software configuration management revolve around four key components: 1. Version Control 2. Build Management 3. Release Management 4. Process Control

SOME IMPORTANT TERMINOLOGIES

Baseline: A specification or product that has been formally reviewed an agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. Version: An initial release or re-release of a computer software configuration item, associated with a complete compilation or recompilation of the computer software configuration item. Release: The formal notification and distribution of an approved version. Variant: A variant is an instance of a system which is functionally identical but non-functionally distinct from other instances of a system. Configuration: A collection of all the elements of a baseline and a description of how they fit together. Configuration Control Board: Group with the responsibility for reviewing and approving changes to baselines
IV.

WHY WE USE SOFTWARE CONFIGURATION MANAGEMENT?

Keeping track of your progress and history for applications you develop can be a daunting task, even for a small project. Many iterations of development and the rapid "Internet time" pace of the lifecycle makes audit controls even more

B.

Build Management Whether you choose to use automated tools to build your applications or still use a manual process, a software configuration management system helps you manage your process and results.

The term "build" is defined by Webopedia, as follows: (n) A version of a software program. The term is usually used in reference to a program that is still in development. A particular version of a software package typically consists of anywhere from a few files to thousands of files, depending on the application. A software configuration management tool assists you in managing builds by enabling you to:

A.

Version Control Version control is simply the automated act of tracking the changes of a particular file over time. This is typically accomplished by maintaining one copy of the file in a repository, then tracking the changes to that file (rather than maintaining multiple copies of the file itself). The concepts of check-in and check-out make this possible. Each time someone needs to edit a file, they check it out for exclusive editing and then check it back in to the repository when finished, thus creating a new version. This paradigm of check-in and check-out can be as simple as I describe above or much more complex depending on the amount of parallel development and branching you have in your process.

Find out how a build was constructed and what went into its construction for debugging or reproducibility purposes. Compare two or more builds.

C.

Version control buys you a number of benefits including the ability to:

Roll back to a previous version of a given file Compare two versions of a file, highlighting differences Provide a mechanism of locking, forcing serialized change to any given file Create branches that allow for parallel concurrent development Maintain an instant audit trail on each and every file: versions, modified date, modifier, and any additional amount of metadata your system provides for and you choose to implement.

Release Management Release management is closely tied to build management in that a specific release is essentially a production build of your application. In addition to putting the runtime software in its final form, release management includes the deployment process as well as the update of related metadata that goes into tracking a given version of a software application. The primary purpose of a release is to make the application available to its end users. Process Control Process control is like an umbrella across the three key concepts already discussed. It is the combination of the business processes defined for your team and the implementation of these processes within your configuration management tool.

D.

Your processes can be as basic or as complex as your situation warrants, as automated or as manual as you desire. The key point to remember is that the process is as important if not more important than

the tool you select. No tool can make up for process shortcomings or for people choosing not to follow the process.

for many large and medium sized businesses and can handle projects with hundreds or thousands of developers. ClearCase was developed by Atria Software and first released in 1992 on Unix and later on Windows.

V.

SOFTWARE CONFIGURATION MANAGEMENT TOOLS

Some of the Atria developers had worked on an earlier system: DSEE (Domain Software Engineering Environment) from Apollo Computer. After Hewlett-Packard bought Apollo Computer in 1989, they left to form Atria. Atria later merged with Pure Software to form PureAtria. That firm merged with Rational Software, which was purchased by IBM in 2003. IBM continues to develop and market ClearCase. CM Synergy Synergy is a task-based software development and delivery solution that brings together your global, distributed development teams on a unified change, configuration and release management platform.
D.

Borland StarTeam (Windows,Linux,Unix ) : StarTeam is a revision control, SCM Tools and SDLC software application, created by Starbase Corporation, acquired by Borland in January 2003.
A.

The application is client-server, backed by a relational database that retains all changes made to a project during its evolution as well as the project requirements, task assignments, threaded discussions and bug tracking. Microsoft SQL Server and Oracle database are supported database servers.

JediVCS(Windows ):

CVS : CVS stands for "Concurrent Version System" and is a version control system designed for software projects.
B.

The JEDI SCM Tools is a source-code-control or version control system. It is possible to work with remote repositories over the Internet. It has many advantages over first-generation Windows version control systems, but given the more powerful version control systems like Subversion, and the windows "TortoiseSVN" client, are much more popular than the JEDI VCS. It is unlikely that the JEDI VCS will see much use even among Delphi developers. The two most active JEDI projects, JCL and JVCL, do not use the JEDI VCS for their own ongoing development, rather they use SVN repositories, and most of the JEDI JCL and JVCL developers use TortoiseSVN instead of the Jedi VCS.

The CVS can have multiple users simultaneously online and working on a project, also in a file. The role of the CVS is to make the changes in the source code (including bugs) traceable to make documented. At the same time, older versions are saved and restored.

C.

ClearCase(Linux,Solaris,Windows):

Rational ClearCase's SCM Tools for revision control. It is developed by the Rational Software division of IBM. ClearCase forms the base of version control

E.

MKS( Linux,Solaris,Windows ):

MKS Integrity is an enterprise application lifecycle management platform that coordinates and manages all activities and artifacts associated with software development including Requirements Management, System Design, SCM Tools, Change Management, Test Management, Defect Management, Release Management and Portfolio Management. Managing the software development life cycle (SDLC) through its unified data framework, MKS Integrity enables collaboration among geographically dispersed teams and disciplines to deliver higher visibility, productivity and compliance. MKS Integrity offers unparalleled process flexibility and supports multiple process frameworks and methodologies such as ITIL, CMMI and Agile development. PVCS: PVCS Serena which now owns PVCS is urging it's PVCS customers to move to it's flagship tool, Dimensions.
F.

RCS automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised frequently, including source code, programs, documentation, graphics, papers, and form letters. RCS was first developed by Walter Tichy at Purdue University in the early 1980s. RCS design was an improvement from its predecessor Source Code Control System (SCCS) (see GNU CSSC). The improvements include an easier user interface and improved storage of versions for faster retrieval. RCS improves performance by storing an entire copy of the most recent version and then stores reverse differences (called "deltas"). RCS uses GNU Diffutils to find the differences between versions.

It is rumored that Serena will end-of-life PVCS in 2011. PVCS by MERANT (formed by the combination of Micro Focus and Intersolv) offers basic of support for CM, using SCCS-like commands. It may be more appropriate for small development projects than some of the more complex or more costly products. Reportedly, changes in recent revisions offer more substantial features, but user experience and comment on the newsgroup have not become prevalent yet. Problem tracking is provided via integrations with third-party products such as Control First by Repository Technology

H.

Subversion (Linux,Unix,Windows ):

Subversion is one of the fastest growing SCM Tools The goal of the SVN project was to build a source control tool that fixed many CVS limitations.

I.

Team Foundation Server (Windows ):

Microsoft's Visual Studio Team System 2008 Team Foundation Server is an integrated collaboration tool server for Visual Studio Team System. It combines software build management, software development process model, team portal, version control, work item tracking, and business intelligence into a unified server. TFS allows better team collaboration in an effort to ensure better quality software.

RCS: The Revision Control System (RCS) manages multiple revisions of files.
G.

TFS Licensing TFS licensing can be very confusing. Even though Microsoft has published much about this topic, many have unanswered

questions. This page hopes to answer some of these questions.

VI.

SCM CHALLENGES

The presentation above, as well as most work in SCM research, has a major flaw. It considers SCM in isolation; SCM tools are too often monolithic and their capability to inter-operate is limited. During the last years, things have dramatically changed; SCM tools are one among a growing number of other tools and thus are challenged in a number of dimensions. Functional Challenges The first challenge is to address the issues raised above, namely to find or to put into production advanced concepts and mechanisms for data model, with complex objects, explicit relationships, files, versioning, homogeneous for all type of objects and relationship, configuration control, with automatic selection and consistency criteria, rebuilding, multi-platform, efficient with high level formalism, work spaces, distributed, scalable, heterogeneous and autonomous, concurrent engineering with high level models and scalable solutions, process control with multiple views, hybrid approaches and high level models.
A.

to days; dynamic selection or controlling concurrent engineering slows down substantially the work and so on. Computing time is an important overhead in software development, and practitioners do not accept to be slowed down any further. The real challenge is to find novel, powerful and elegant solutions that are highly efficient, available, reliable and scalable. In any of the above bullets, these characteristics must be given top priority.

Data Management A large number of tools and environments manage a local data repository, sometimes versioned. Usual examples include a programming environment or 4GL tools. The difficulty is to find a way to make all these repositories inter-operable in order to avoid (too much) duplication and inconsistency. The real challenge is to make compatible (enough) the many different definitions, formats and versioning approaches. We have known for a long time this is a tough issue.
C.

Efficiency, Scalability, Availability. All the above issues are by themselves challenging, but it is of critical importance to understand that a (the?) major limitation today is related to efficiency. Checking out a configuration, or labeling it, takes from minutes to hours, rebuilding takes from hours
B.

Process Management A growing number of tools include a process, in an explicit formalism or not; they are called Process Sensitive Systems (PSS). Today a large number of PSSs are present in industry, like planners, mail systems, GroupWare, workflow, project managers, business tools and so on. The data and concepts on which PSSs and an SCM system operate are roughly the same (task, time, resource, and data). From change control up to marketing strategies, the company processes are forming a continuum with large overlap between the processes managed by the different PSSs. Companies will require to cover the complete process spectrum, with minimum redundancy and overhead, but sill using the specialized tools they are used to. SCM is nothing else than one of these. There is fundamental work to do to make PSSs interoperate in a clear and clean way.
D.

PDM vs. SCM The definition of SCM says the control of the evolution of complex systems. This covers many engineering disciplines, not only software engineering. Indeed other type of engineering -electrical, mechanical, 3D design and so on- have developed their own tools, with leaders like Metaphase or Sherpa. Let us call these tools Product Data Management (PDM) tools. Both domains look very similar, but have at least two fundamental differences. First, in PDM, there is a clear distinction between the design (e.g. a bicycle design) and the product itself (a given bicycle). In software the design (the program) and the product (the software product) are almost the same; the later can be derived from the former at almost no cost. Second, in PDM, the product (will) have a physical existence, which confers unquestionable (spatial , mechanical) properties and constraints. For that reason, in PDM, the main structure is always its part structure (a bicycle has 2 wheels, a frame). In software there is no such obvious real structure; parts are arbitrary abstractions with loose relationships. Perhaps for these reasons product models in DPM are more advanced than in SCM. Unification of both fields is needed because software constitutes a growing part of almost any industrial product. Unfortunately, vendors are not headed in this direction, because of deep underlying difficulties, and for efficiency and usability reasons.
E.

On the other hand, the web produced a new kind of artifact: the web pages. Web pages are released but evolving products, containing essential pieces of information, and highly related with other pages. They clearly require configuration control. But when comparing a web page with a source file, the differences are easy to notice: The number of pages is 100 times larger than the number of files, the time between changes is 10 times shorter, the number of contributors is 100 times larger, they are not computer specialists and so on.

VII.

CONCLUSION

Web Support The web had two effects on SCM: local, distributed and remote development can be made similar (see the workspace and scalability discussion). Distributed work space control will involve creating an infrastructure for the management of multiple copies of objects, with the distinctive feature that they can have different values, different formats, and can (must) be resynchronized. This kind of service is required by any application dealing with concurrent engineering and thus deserves to become a standard service on the net; for instance a CORBA service. http extensions (WebDav) are going in that direction.
F.

Despite the many limitations and expected improvements discussed in this paper SCM proved to be one of the very few successful software engineering technologies. Indeed, the market is booming, with over $1 billion sales in 1998 and has excellent perspectives since only about 25% of mainframes, 15-20% of workstations and 5-10% of development PCs currrently has today an SCM system. Forecasts are about $2.1 Billions sales by 2000 and $3.3 Billions by 2002. It may appear that most of SCM research was performed in the 80s, and only tool improvement can be expected in the future. I do not support this view; I have tried to identify the areas for further research in the usual SCM core topics. Even if few new ideas have been proposed and few serious experiments have been performed in recent years, I think that much is still to be done both to find new concepts and better implementations. Unfortunately, too often, this work requires heavy developments and experimentation, which currently dissuade most academic researchers. The future of SCM research and tools is unclear. The basic services will become understood, mature and stable enough to be standardized. They will fall into the public domain, as basic services anyone can expect from a platform, for instance versioning, rebuilding, basic work space support and so on. Vendors will lose their control on these low level services. Vendor added value will come from their ability to build, above this level, an SCM system providing

core topic advanced services, targeted toward a specific client: a specific data model and versioning capability, specific concurrent engineering facilities and so on. A major change is that that second layer will be considered as a basic SE issue will be to standardize and componentize SCM systems in a way allowing us to build easily, tailored and highly efficient solutions. Indeed, above this kernel, will be plugged a number of specific tools dedicated to a facet of SE, like process support, concurrent engineering control, project support; or dedicated toward a specific application domain like Web support, PDM control, deployment, electrical or mechanical tools and so on. SCM research and vendors are currently starting to address all these issues, but with limited scope, and not necessarily with all the requisite expertise. On this layer, for each tool, it is unclear who will take the lead, not necessarily SCM vendors. The way all these tools will cooperate, to build a fully fledged, evolutive and efficient SE environment, is an active research topic (mega programming, COTS federations etc). This last issue, interoperability control, can become another area where SCM research and tools can contribute; further, as quoted in [28] several researchers believe that Configuration Management environments are the real process-centered environments. Nevertheless, in the near future, provided the number of core topic issues yet to be solved and the efficiency, scalability and usability issues, no one of opportunity that many SCM challenges are currently under work in other SE domains, to foster a synergy between these research domains and SCM, bringing in the experience and know-how that made the strength of SCM, showing a path toward the useful and successful tools software engineering needs.these evolutions will be seriously addressed by SCM vendors. SCM tools will still grow, propose proprietary solutions and still consider SCM as an isolated domain. SCM research should take the that made the strength of SCM, showing a path toward the useful and successful tools software engineering needs.these evolutions will be seriously addressed by SCM vendors. SCM tools will still grow, propose proprietary solutions and still consider SCM as an isolated domain. SCM research should take the addressed by SCM

vendors. SCM tools will still grow, propose proprietary solutions and still consider SCM as an addressed by SCM vendors. SCM tools will still grow, propose proprietary solutions and still consider SCM as an isolated domain. SCM research should take the that made the strength of SCM, showing a path toward the useful and successful tools software engineering needs.these evolutions will be seriously addressed by SCM vendors. SCM tools will still grow, propose proprietary solutions and still consider SCM as an isolated domain. SCM research should take the isolated domain. SCM research should take the that made the strength of SCM, showing a path toward the useful and successful tools software engineering needs.these evolutions will be seriously addressed by SCM vendors. SCM tools will still grow, propose proprietary solutions and still consider SCM as an isolated domain. SCM research should take the tools software engineering needs.these evolutions will be seriously addressed by SCM vendors. SCM tools will still grow, propose proprietary solutions and still consider SCM as an isolated domain. SCM research should take the addressed by SCM vendors. SCM tools will still grow, propose proprietary solutions and still consider SCM as an isolated domain. SCM research should take the that made the strength of SCM, showing a path toward the useful and successful tools software engineering needs.these evolutions will be seriously addressed by SCM vendors. SCM tools will still grow, propose proprietary solutions and still consider SCM as an isolated domain. SCM research should take the

VIII. 1. 2. 3. 4. 5.

REFERENCES

http://www.nalanda.nitc.ac.in/misc/general/scm. pdf http://www.ecs.csun.edu/~rlingard/COMP595V AV/ConfigurationManagement.ppt http://www.sei.cmu.edu/reports/87cm004.pdf http://www.scmwise.com/scm-tools.html http://en.wikipedia.org/wiki/Software_configurat ion_management

http://www.cmpe.boun.edu.tr/courses/cmpe450/f all2002/LectureNotes/Lectures/ch10lect.ppt 7. http://www.intranetjournal.com/articles/200303/i j_03_12_03a.html

[1] [2]

IX. REFERENCES This shjkdhfskds 9. conclusion(if any) 10. referenceschnical Writer's Handbook.
University Science, 1989.

Mill Valley, CA: