Upcoming Event Announcement: "Configuration Management: Which Tool Is Right for You?" to be presented December 6, 2001 through SPC Free Affiliate Seminars. http://www.spc.ca/members/free.htm

CM for Web Development Environments Series

CM Costs and Benefits

As we discussed in part one of this series, CM's goal is to IMPROVE QUALITY by improving control over various aspects of your projects, your departments, and your resources.  However, there are costs and difficulties with CM process implementations that must be accepted or overcome in order to reap the benefits.

Costs of Implementing CM

- People Costs

First, you will need a high-level/upper management champion, a person who buys into SQA in general and CM specifically.  This person will help get you the budget and resources you need to implement any process improvements.

You can then divide the CM labour amongst the team members, and accomplish quite a lot in a short period of time. As well, the greater number of voices you have repeating the same mantra will slowly but surely have an influence on the rest of the project team.

- Tool Costs

Second, you'll find you need to identify the right tools for implementing CM - a version control tool, and possibly a document control/management tool.   Whatever tool or tools you end up using may have a price tag that includes the license, associated resources and documentation, and a support contract.

- Training Costs

People need training and follow-up time, both in the use of tools and techniques, and in learning and understanding the role and importance of CM as it relates to software engineering. While spending time being trained, resources are not actively performing project work.

- Space and Equipment Costs

To implement some CM processes, you may have to make an investment in hardware and software, from adding hard drive space on common servers to replicating a complete deployment environment.

What You Get For Your Investment

CM activities give you the ability to help support certain kinds of software engineering activities.

• Building and releasing product versions to customers as well as re-creation of earlier product versions.
• Change Management to ensure that products and their elements have adequate measure to cover planning, tracking, authorizing and controlling of changes.
• Parallel Development allowing for developing/maintaining several versions of a product in parallel.
• Distributed Engineering across LANs and WANs including data replication and shadowing facilities.
• Configuration and Workspace Management, including specifying configurations, such as testing and support environments (e.g. compilers, debuggers).
• Process Management which addresses defining the process lifecycles for the product elements, setting up appropriate change controls, and authorization policies for product element modifications.

One particular example is that of distributed engineering.  Many companies will outsource some of their development, especially when a schedule is tight.  Web development projects have several components that may be outsourced, including art and design, development and coding, testing, and deployment and hosting. CM helps organizations that outsource part of their projects, track precisely what was delivered from contractors and outsourcers, when those deliverables were delivered, also storing those deliverables in an appropriate manner.

Another example that affects web development projects is the dependencies upon third party software such as plug-ins, platforms, and clients. Most web applications today make heavy use of licensing and wrapping third party functionality, such as application server software. This is usually done to reduce time to market and overall development costs. However, because of this heavy dependency on third party products, web development organizations must keep close track of product versions and defects or vulnerabilities in those product versions. CM will help organizations do this.

What You Won't Get

In general, CM will not help give you a way to change developer attitudes about testing and QA.

It is important that you make an effort to show the distinction between QA and CM because it is more likely than not that QA will be the resource doing the CM activities. Although they are very interrelated, they are distinct activities and processes. Most project staff are somewhat mystified by what QA is, and what QA resources do on a project (aside from testing), so to further muddy the waters with CM can be misleading.

Also, as there are many development project personnel who do not believe that independent QA and testing is a good thing (as opposed to simply having the development staff test their own work), simply implementing CM processes is not going to help change that kind of a mindset or the resulting quality issues.

CM will also not give you a means to hide staffing problems such as weak or under-performing resources, or the need for major amounts of rework due to poor or shoddy work.
 

Difficulties in Implementing CM in Web Development Environments

In a Web Development Environment, you can't expect to be able to implement all the CM processes you will want completely in a single iteration.

- The Iterative Nature of Web Development

Consider the "whale-dolphin" release approach common to most web projects - the whale is the initial hump of effort to release the first version of the web app and the dolphins are subsequent cycles of functionality increments. Process improvement activities that work well with the whale-dolphin model are usually small changes that can be measured over a short period of time. With small changes in each release cycle, you can evaluate the effectiveness of the process change in a short time (without having to wait for a long cycle to be completed).

- The Time-To-Market pressures.

Short schedules do not allow for implementation, training, audits and follow-up to implementation of CM initiatives. CM is seen as "stuff that slows down the development process", makes it harder for people to "go live" or meet investor deadlines.
 

Summary - What CM Should Look Like

There are four key areas of CM: Identification, Documentation, Control, and Auditing.

Because most web development environments work with little to no documentation and with even less time, the majority of effort is spent trying to gain control over the environment and the situation. However, the team often doesn't know what to try and control, or if the made attempts are going to be effective in a repeatable fashion.

You must first begin by identifying things or "artifacts", like documents, source code, bugs, anything you use on a project, in some unique manner. That is, each item will be uniquely identified from other items, perhaps with an ID number.

Once you have identified these items, you can then document their existence, referring to these items by their unique identifiers.

After having documented the items, you will have enough information about the items themselves to begin to apply basic forms of controls over the items and changes to the items.

Finally, to ensure that the items are being identified, documented, and controlled according to your standards, you can audit the items against the standards you have created.