Software Configuration Management for the Web

Michael K. Jones, Director of Quality Assurance, TransactPlus,Inc.
Assistant Professor, Western International University, Phoenix, Arizona, USA

Abstract

Software configuration management must be practiced for any software system from the moment any work on the software system begins to when support ceases for that system. In the E-World, which is an expression used to describe the environment in which web applications are developed and utilized, effective and time-efficient software configuration management must be practiced such that baselines are identified and changes are tracked to those baselines. However, this software configuration management effort must not impede development and must be clearly understood from a functional basis. The overwhelming time to market requirement for E-World development efforts can not tolerate any impediments to development time and responding to client needs. This high emphasis on time efficient processes has not been true for many software development projects in other environments in the past as a rule, and pragmatism has surely not governed many efforts that had to observe numerous government regulations.

The theoretical model that is most commonly used in reference to software configuration management is one that has a typology of configuration identification, change control, status accounting, and configuration audit. This typology is not functionally oriented and is consequently either misapplied with gaps in coverage or impedes the development of the software system by being oppressive and bureaucratic. This model was developed with hardware in mind as its primary target and consequently must be interpreted for software projects.

A better model for software configuration management that is clearly understood and is scaleable is the subject of this paper. Software configuration management can be functionally broken out into the areas of 1) version control, 2) document control, 3) change management 4) build management, and 5) release control.

By discussing each of these functional areas of software configuration management at length, a realistic and doable model of software configuration management will be seen from the explanations and examples supplied in the paper. The reader of this paper will then, hopefully, leave with a better appreciation of what to expect in software configuration management efforts in the future, both as a developer and as a client.

Introduction

Software configuration management is a crucial activity for any software development effort. The software configuration management activity, however, must not delay or impede the rapid software development schedule necessary to meet the harsh time to market needs of the E-World.

Consequently, effective and time-efficient software configuration must be practiced with all efforts having a justification in functional value. The software configuration management theoretical model that is most commonly referred to in literature does not easily correspond to the functions that must be accomplished through software configuration management activities. A better model that is functional in derivation, and that will be clearly understood and will be easily scaleable is the subject of this paper.

A functional model of software configuration management is organized into the areas of 1) version control, 2) document control, 3) change management, 4) build management, and 5) release control. This typology corresponds directly to the functional tasks that must be performed for a project and also agrees with the typology of the major software configuration management tool vendors. Each area will be defined and the practices or techniques that must be implemented for web applications will be discussed.

The Theoretical Model

The theoretical model of software configuration management arose out of post World War II efforts in the aerospace industry for the United States Defense Department and was a spin-off of previous successful efforts for hardware configuration management according to Berlack (1992). This model has continued to be referred to by textbooks on configuration management, Buckley (1996), and by textbooks on software engineering, Peters (2000). The model consists of four elements: configuration identification, change control, status accounting, and configuration audit. Although this model still stands head and shoulders above the Microsoft model of the "daily build" as discussed by Pfleeger (1998), the traditional model still remains encumbered by a focus on bureaucracy instead of project functionality.

The Microsoft daily build technique, for those who are unfamiliar with it, consists of declaring the baseline by whatever was "thrown over the fence" to the build manager at either the beginning of the day or the end of the day, depending on the project. Why this technique is not held in high regard by at least some in the software engineering community, is that builds are not a result of conscious decisions about what functionality should be included in a baseline, but only a result of frenetic programmer activity that is personality dependent.

Definitions for the traditional model as provided by Buckley (1996) provide some insight into this conclusion:

Configuration Identification - "Configuration Identification includes the selection of configuration items; the determination of the types of configuration documentation required for each configuration item; the issuance of numbers and other identifiers affixed to the configuration items and to the technical documentation that defines the configuration items configuration, including internal and external interfaces; the release of configuration items and their associated configuration documentation; and the establishment of configuration baselines for configuration items" (p.259).

Change Control - "The systematic proposal, justification, evaluation, coordination, approval or disapproval of proposed changes and the implementation of all approved changes in the configuration of a configuration item after formal establishment of a baseline"(p.259).

Status Accounting - "The recording and reporting of information needed to manage configuration items effectively, including:

a) A record of the approved configuration documentation and identification numbers.

b) The status of proposed changes, deviations, and waivers to the configuration.

c) The implementation status of approved changes.

d) The configuration of all units of the configuration item in the operational inventory (p.260).

Configuration Audit - "The verification of a configuration item's conformance to specifications, drawings, and other contract requirements (p.258).

From these definitions, there is a strong inference, substantiated by the author's personal experiences on past projects that used the traditional model (dictated by DOD or NASA standards), that extraneous paper documentation becomes the overriding "end" as opposed to the "means". Along with this paper, came a bloated personnel count with "checkers" of the "checkers". Hence, large amounts of extraneous paper documentation and superfluous personnel equate to needless bureaucracy.

The Functional Model

In contrast, the functional model that this paper advocates is strictly based upon the correspondence of software configuration tasks to the tasks found in the basic software development model. The basic software development model, according to Sommerville (1996), who is the author of one of the most commonly used textbooks on software engineering and consequently one that most people might be familiar with, consists of four fundamental activities which are common to all software development processes: software specification, software development, software validation, and software evolution. The functional model of configuration management maps the functions of version control, documentation control, change management, build management, and release control to the development model.

The model is called a "functional" model because the typology is based on tasks that are commonly called out on a WBS (Work Breakdown Structure) and there is no need for interpretation of task versus configuration management area type. A functional emphasis is important for the E-World, i.e. web applications, because all actions must be as time-efficient as possible to meet deadlines and yet control of baselines and changes must still occur. There is not the luxury of pondering over what configuration management means according to some abstract model, but rather a driving concern with getting tangible tasks performed quickly. A "functional" model is focused on getting those tasks done, not with generating paper.

Mapping the functional software configuration model to the development model, version control takes place at the conclusion of development with formal software baselines prior to validation. Documentation control takes place at the conclusion of specification and then continues throughout with traceability of documents to software baselines. Change management is initiated immediately following the first instance of the use of version control or document control. Build management occurs with the initial repeatable documentation of how to construct the first formal baseline with updates then being a constant necessity. And release control is performed at the conclusion of validation such that all versions of the system that are released to outside parties are approved, recorded, and tracked against requests for defect resolution and enhancements. A description of typical tasks and activities for each functional area follows and is organized on the basis of "What", "Why, "When", "Where", "Who", and "How" for the purposes of clarity and definition. In addition, the special needs and consideration of web applications will be discussed.

Version Control

What: Version control combines procedures and tools to manage different versions of configuration objects that are created in the software development process, according to Pressman (1997). Configuration objects are identified, for Internet applications, by completing a physical architecture diagram during the design process. It is only at that point that objects may be discerned in a configurable form. The physical architecture diagram had to be preceded by the creation of the domain model and the object model for successful design derivation.

Why: Version control provides for visibility, control, traceability, and monitoring of software components and systems, and of documentation. It is a necessary function for successful project management and the implementation of a "planned" system architecture.

When: Version control is instituted for software systems after development is complete, so that baselined units can be employed in system integration and validation testing. Version control is then repeated with new versions for those items as changes are introduced to those baselined items.

Where: Version control is performed through version control utility software located on a system that is accessible by all participants on project team (i.e. developers, testers, project managers, and quality assurance.

Who: Version control is performed by multiple parties with different roles. Unit developers check units in and out for their work. System developers construct and identify specified groups of units as configured systems. Testers check systems out for testing. Project managers approve these configurations at project milestones. All of these activities are performed by project personnel with the appropriate privileges granted in the version control system. The administrator of the system, however, should be a configuration management analyst who is responsible for the administration of version control throughout the organization, in addition to other areas of responsibility such as change management and release control.

How: Version control is accomplished mainly by software tools with some set of the following capabilities:
Version any type of file
Forward/reverse deltas
File compression
Branching
Automatic branch creation in certain situations
Version labels
Visual differences
Visual merging
Parallel development
Support projects as well as files
Support sub-projects
Unlimited directory hierarchy
Recursive commands through hierarchy
Track changes to project structure
Project/file sharing between multiple applications

In the preceding nomenclature, a definitive description of version control for the functional model was presented. This description provides the foundation for a discussion of special E-World needs and considerations.

For web applications, tools are a necessity as they greatly increase efficiency over manual methods with hard media and much personnel. The drawback to using automated tools is the cost of sufficient licenses to support all the users of the configuration management process.

Other considerations for web applications are the necessity to baseline not just source code, but also executable code, graphic images (GIF and JPEG files), data files, and any type of digital article necessary to create the finished system. In many cases today, content management is simply a new name for version control of web applications in production, but the tool utilized has been optimized for control and delivery of controlled items from the repository to the production server.

One special concern, due to web applications, is the need to check for the legal right to use and archive the images received for version control. With very creative and eccentric designers, copyright authorization may have been neglected. It is recommended that metadata of copyright permissions be captured with any images at the same time that they are accepted into version control. Additionally, all HTML code should have a copyright protection statement inserted so any unauthorized use can be prohibited if Internet users cut and paste the code.

Document Control

What: Documentation control combines procedures and tools to manage and preserve versions of all identified documents in the development process model.

Why: Documentation control provides a means to preserve and retrieve documents used in the development model so that traceability to software baselines for decision-making is maintained and a basis for litigation and negotiation is available.

When: Documentation control is performed whenever a document in the development model is approved by the required parties. The master of the document is archived in a controlled area and a copy is used in daily work.

Where: Documentation control is performed through documentation control utility software located on a system that is accessible by all participants. Signed hard-copy masters are kept in a controlled area.

Who: Documentation control is performed by all individuals who create documents throughout the development process. After the designated approval of their documents, they are responsible for seeing that those documents are placed in documentation control. The administration of the documentation control function should be the responsibility of the project configuration management analyst.

How: Documentation control is accomplished mainly by software tools with the following capabilities:
Forward/reverse deltas
File compression
Version any type of file
Branching
Automatic branch creation in certain situations
Version labels
Visual differences
Visual merging
Parallel development
Support projects as well as files
Support multiple threading
Unlimited directory hierarchy
Recursive commands through hierarchy
Track changes through business cycle
File sharing between multiple applications

Documentation control is broken out separately in the functional model, due to tool and organization issues. In the realm of tools, it is certainly possible to use most of the version control tools on the market for document control, if they will accept the file type that the document was written in. However, some document control utilities are sold with server licenses strictly and not by user licenses, so that they may make more sense in providing a larger group of users access and/or supporting in a cost-efficient manner access to a corporate knowledge management repository. Version control tools, in contrast, are usually sold by user licenses and may be tied to other tools that the document users may not need.

One special consideration for E-World applications is that the prospective document control system must have the capability to keep hyperlinks embedded in the documents. Other issues may be globalization concerns that revolve around the use of non-Western alphabets in web pages and documents, and the consequent need to have the ability to utilize Unicode, a new font mapping standard.

Change Management

What: Change management is the systematic proposal, justification, evaluation, coordination, approval or disapproval, and implementation of all approved changes to the configuration of a system after the initial baseline of that system.

Why: As uncontrolled change leads to chaos, controlled change enables changes to the system to be accommodated efficiently and effectively both in time and cost, and permits a planned resolution of reported defects and requested enhancements for that system.

When: Change management may be initiated at any point in the project life cycle after the first baseline, through the creation of some form of a change management request that is submitted to a configuration control board for resolution. Changes are always targeted against specific baselines, whether those baselines are versions of code, versions of design, or versions of requirements. It is very possible that a requested change to a code version will have a backward effect on both design and requirements. Changes include both reported defects and requested enhancements.

Where: Change management is accomplished usually through the use of two configuration management tools: 1) a change control tracking system, and 2) a version control system. The change control system must be linked to the version control system. The change control system registers the initial appearance of the change request and routes the request to analysis review, after which the request awaits the decision of the configuration control board as to disposition. The system then routes the request to the designated implementer, records a description of the implementation, and routes the request back to the board for approval of implementation and incorporation into a release baseline. All changes must have links to specific items in the configurations captured in the version control system.

Who: Change management involves the entire project team and clients. A change management request may be created by any member of the team or by any client. The configuration control board is usually made up of the project manager, a technical lead, a configuration management analyst for support and administration, and quality assurance. The board determines the resolution of all requests and defines all releases.

How: A successful change management system is attained through cost-effective and time-efficient processes, trained and professional personnel, and well-chosen configuration management tools. A configuration management system should not result in a burdensome bureaucracy, but in a documentation of decision paths that show that when changes were made to the system, the changes were analyzed before implementation and the implementation itself was reviewed prior to incorporation in the client load. All changes link directly to items in a controlled version system, and conversely all ensuing versions after the initial version have links to change management requests. Those links to the version control system are both links to the previous version where the defect was found or the enhancement needed, and to the new version where the change was implemented.

For web applications, with time always of the essence, a time-intensive change management system based on paper and numerous meetings is not probable and in many cases possible. Successful change management in the E-World hinges around two things. The first factor for successful change management is automating the change process using a tool with automatic notifications and forwarding once system approved decision-makers have made a choice of actions. The second factor is empowering the Project Manager (or Product Manager depending on whether the project is a custom application or a product) to act as a one-person change control board. It is up to the Project Manager to solicit and obtain the views of others towards the Project Manager's approval of changes.

Build Management

What: Build Management is the function that either performs or verifies the build of all configured baselines through controlled documentation.

Why: Build management provides for traceability and repeatability for all configured baselines such that deliverables to clients are traceable to source articles.

When: Build management is performed when any configured baseline is produced.

Where: Build management is performed at any location whenever an original configured baseline is produced.

Who: Build management may be performed by any designated project personnel, but the record of how that build was accomplished, as well as a documented process that details the technical steps to perform the build, must be reviewed and archived by the configuration management analyst.

How: Build management may be accomplished by either through an automated utility that interacts with a version control tool, or through a recorded script that captures the commands and references necessary to repeat the build with no differences found in the products of builds performed separately. The script, upon version control of the baseline, would also be placed in an archive and linked to that baseline.

Build management for traditional software configuration management individuals is an unfamiliar subject, but it is a major challenge to be dealt with for web applications. The reason for this is the complexity of web applications due to the interdependencies of varied software technologies and the hardware environments they operate within. For the theoretical model a simple version description document was sufficient for a later configuration audit.

For web applications, not only must all software and hardware be listed in sufficient detail to be clearly identified, but also even the sequence of how that hardware and software is set up and installed must be recorded if the successful building of a production server is to take place. For web applications that the author has been responsible for, a document defined as a "Configuration Specification" was created that records the identification of all hardware items, the identification of all software items, the setting of any switches and breakers, all commands entered into the system, and the proper sequence of the preceding actions. This documentation is far beyond what is usually found in a Version Description Document. Furthermore, this document is validated by being utilized to create from scratch the test servers and then finally the production servers.

Release Control

What: Release control is the function that collects, documents, and transmits all deliverables to points external to the company. A configuration audit of all deliverables must be performed to ensure an accurate record of configurations and validated traceability to build procedures and system documentation. (It must be noted here that the term configuration audit is misunderstood by many new to software configuration management as a process audit. It is not a process audit, such as would be performed by Quality Assurance auditors, but a product audit against the software to be prospectively delivered to outside parties.) For web applications, the configuration audit must be conducted against the "Configuration Specification." The audit is the validation of the "Configuration Specification," and is the build of a production server from scratch. This is conducted in a controlled environment, usually a staging or test lab.

Why: Release control ensures that traceability as to configuration, authorization, and destination for all deliverables is kept and auditable. Release control records are a starting point when answering client questions as to what configuration the client currently has when changes are discussed.

When: Release control is performed in the life cycle of custom code and product code as the delivery interface to the client. When changes to deliverables have to be implemented during installation, those changes must be reported to Release Control so that a true and accurate record of client configurations is kept.

Where: Release control is performed at the company, prior to delivery to clients. When changes occur at the client site during installation, those changes are required to be reported back to Release Control for accurate record keeping. From release control, all changes are then incorporated into the version control and change management system. Approval is implicit due to the involvement of the project management team during client installation. An important point to make is that these five functions all support and interact with each other.

Who: Release control is performed by a configuration management analyst who supports multiple projects for their release of deliverables to customers. The analyst performs this function, in addition to also providing administration of version control and change management systems. In the case of emergency transmissions due to the immediate needs of the client, when Release Control is unavailable, project managers are always empowered to deliver the appropriate fix to the clients. The next working day, however, copies of that transmission and the proper records must be given to Release Control so that the organization has records of that delivery.

How: Release control is accomplished through the use of the version control utility by keeping a record of the configuration of all external deliverables. The configuration management analyst should also check for agreement of appropriate personnel as to whether the deliverables should be transmitted to the outside parties. Also, the analyst should perform a configuration audit, if one has not been performed prior to this point, to validate the agreement of software to the system documentation. This would be the "Configuration Specification" for Internet applications. The audit will assure that all items of the delivery are in agreement and the traceability of the software and hardware is to the correct build procedure, i.e. the "Configuration Specification" for Internet applications. Finally, hard copies of all release approval signatures and dates should be kept for audits and possible future litigation.

Release control is identified as a specific activity under the functional model due to its critical nature in the E-World. All changes to a production web application must be tracked and have traceability to controlled items in a repository, so that effective content management can occur. Due to the need to expedite defect removal and in some cases accelerate enhancements to site functionality, the project manager (or product manager) is always empowered to make decisions for releases without involving others.

Migration Structure

For any software configuration management model and to optimize the functional configuration model, a compartmentalized physical facilities structure for the controlled migration and implementation of software systems has been found to be effective, particularly so for the E-World. This migration structure for web applications consists of a defined development environment with control of the project configuration decided by the project manager, a staging environment for the testing of the developed systems with formal controls in place for changes to the system under test, and a production environment where no changes are permitted as the system operates in the critical 24 by 7 by 52 time frame of reliability and non-down time mode. As a software system moves from development to staging, entrance criteria must be met as to the completion of required documentation, a defined baseline, and the preparation of test procedures. Similarly, as a software system moves from staging to production, entrance criteria must be met as to complete system documentation, and completed test documentation that provides a basis for risk management as the reliability of the software system in the production environment.

With the total revenue stream of pure play (all business taking place on the web) e-commerce businesses dependent on their web sites, a comprehensive risk reduction strategy for downtime of the web site is a prime necessity. Consequently, web hosting operators are now usually contractually liable for downtime as a result. All of this is driving more web application development organizations to a controlled migration structure for their projects.

System Automation

For the successful utilization of the functional model of software configuration management, most especially in the E-World, automation of the software configuration processes is essential. Providentially, numerous software tool vendors have met this need with suites of software configuration management tools. These tools are organized along the functional model and not the theoretical model, with specific tools in each suite focused respectively on version control, documentation control (in some cases the same tool as the version control tool), change management, build management, and release control. There is no suite or individual tool that corresponds to the typology found in the theoretical model. In fact, the functional typology is what the vendors address in their specifications not the theoretical model.

Automation of the software configuration management functions provides, among other things, for the automatic requirement of approved change requests for every baseline once the initial software baseline has been achieved, the mapping of baselines to change requests at release control reviews, the linking of build procedures to every baseline, and the automatic traceability of system documentation to software baselines.

For web applications, automated software configuration management accelerates process decisions. If the decision was between a time expensive manual system and not doing configuration management, it is possible that the latter choice might be taken, even with a consequent loss of control and the lack of change records. The use of automation makes sure that the possible decision to not do configuration management is never considered.

System Interfaces

Having discussed system automation above, it is necessary to discuss the need for several required system interfaces for a software configuration management system in an E-World environment. All of these interfaces must be either integral with the system or an API must be written for back and forth transmission of information. First, by linking the change management utility with the organization's e-mail system, automatic notification of required actions or decision can be made and recorded, with the change request then being forwarded on to the next decision point for further action. Second, due to the need for the smooth and expeditious reception and response to client or customer requests for defect resolution or enhancement, an API is necessary between the customer support automated software and the software configuration management tools. By this means, a customer request may be received and then transferred to the software configuration management system, with real-time status available to the customer support representative at any time for the decisions or progress made on requests. Third, the content management delivery software system must be linked to the software configuration management system with an API for the necessary adjustments of the site software in the E-World that are necessary to support new data and image needs that must be displayed and manipulated. Fourth, the system site software must be controlled through the software configuration system to avoid conflicts between operating systems and third party software that have been purchased to operate with the web sites.

Conclusion

This paper has tried to discuss the recognition of a new standard model for software configuration management and how that model makes possible pragmatic software configuration management in the E-World. The paper has described the old theoretical model of software configuration management and defined the new functional model as version control, documentation control, change management, build management, and release control. Individual considerations for web applications have been reviewed for each area of the functional model. The paper has discussed each of these areas in detail through using a "What", "Why", "When", "Where", "Who", and "How" typology to provide clarity and definition. Ramifications of the functional model of software configuration management have been discussed as regards to migration structure, system automation, and system interfaces that are necessary for success in the E-World. In particular, it has been noted that the functional model of software configuration management matches the organization of the software configuration management tool suites currently available for software development.

In conclusion, the paramount principle for the guidance of performing software configuration management in the E-World should be one of pragmatism. In the past, pragmatism has not been the paramount principle in software configuration management for many projects as exhibited by their paper and personnel bloat. Definition and communication should be the ultimate goals for any software configuration management activity and not barricades and forms. Through taking a functional view of the tasks of software configuration management, efficiency can be improved by seeing rational reasons related to functions for the tasks to be performed. Furthermore, scalability can be matched to that of the development model more congruently. The E-World will tolerate no paper for paper's sake, and so consequently a functional view of software configuration management will better ensure that the work of software configuration management always brings value.

References

• Berlack, H. (1992) Software Configuration Management. New York: John Wiley & Sons, Inc.
• Buckley, F. (1996) Implementing Configuration Management: Hardware, Software, and Firmware. Los Alamitos, California: EEE Computer Society Press.
• Peters, J. & Pedrycz, W. Software Engineering: An Engineering Approach. New York: John Wiley & Sons, Inc.
• Pfleeger, S. (1998) Software Engineering: Theory and Practice. Upper Saddle River, New Jersey: Prentice Hall, Inc.
• Pressman, R. (1997) Software Engineering: A Practitioner's Approach. New York: McGraw-Hill.
• Sommerville, I. (1996) Software Engineering. Harlow, England: Addison-Wesley Longman Limited.

---

Software Configuration Management Articles

Use Cases and Implementing Application Lifecycle Management Systems

Lean Configuration Management

Related Software Configuration Management and Software Quality Knowledge

Open Source Software Configuration Management Tools

Software Testing Tutorials and Videos

Software Testing & Devops Magazine

---

This article was originally published in the Winter 2000 issue of Methods & Tools

Click here to view the complete list of archived articles