Archive for October, 2009

h1

What is Software Configuration Management?

October 14, 2009

A while ago I wrote a post ‘What is Configuration Management?’ in which I outlined the four principles of configuration management. This prompted several readers to ask, ‘what about software configuration management?’.

Software configuration management differs from the core configuration management discipline in detail only. It is common for organisations to include disciplines like build management (the discipline of transforming source into product) under the job description configuration management and it is common to see people discuss build management as if it were part of software configuration management but this is an error. Build management is closely associated with configuration management, but is most certainly not a part of configuration management.

Build management uses configuration management. Configuration management supplies the input to build management (a source baseline). Build management then creates product from these sources and delivers these products to configuration management. Configuration management places those products into a product baseline, often alongside the source baseline. The important point is that build management can operate without configuration management (not a good idea, but it is perfectly possible). Similarly, configuration management in no way depends upon build management. Attempting to integrate them leads to confusion and gains us nothing but creating an artificial dependency.

A discipline more closely, and correctly, included under the title software configuration management is version control. Version control is a crossover discipline, part asset management and part configuration management.

Asset management is primarily concerned with recording and securing things of value. Configuration management is concerned with more than simple recording and custody, it also needs too maintain information about the relationships between the items it holds. Importantly version control maintains the history of each asset, its ancestry. Of course all configuration management is concerned with this version control issue, but software configuration management requires that the version control system not only records these relastionships but also holds all of the actual files. It is this particular that software configuration management differs from configuration management.

In addition to the normal configuration management skills, a software configuration manager should also be adept at conceiving and managing version control of systems and the files that constitute them.

h1

The importance of release identities

October 13, 2009

Having carefully avoided ‘release numbers’ in the title of this post, I shall now proceed to describe a release numbering scheme. The specifics of release numbering schemes are endlessly discussed. Each proponent of a specific scheme believing that their scheme is the best. I shall be no different. Read the rest of this entry ?

h1

IT Leaders must be business people?

October 9, 2009

Over recent years there has been an increasing emphasis placed on IT leaders being business oriented. While I wholeheartedly agree that IT leaders need to be business aware I believe the emphasis on business capabilities is being emphasised to the detriment of the IT skills required. We are ending up with pure business people making IT decisions, which means many bad decisions are made.

The problem is this. Read the rest of this entry ?

h1

Streams versus Branches

October 2, 2009

The configuration management community have no universally  accepted definition of either Stream or Branch; here are my working definitions of these two terms.

A branch refers to how version histories appear when two versions share a common ancestor.

A stream is a management notion. Streams define work flow, usually within projects. A stream may be supported by zero or more branches. (Zero when no development work is involved in the stream.)

Think of the relationship between branches and streams like this: branches are like workbenches in a workshop, streams are like the schedule of work assigned to each bench.

h1

Software Configuration Management: An Investement in Product Integrity

October 1, 2009

For me, this book holds a special significance. This is the very first book I ever read that dealt exclusively with software configuration management. For me, this book started a career and lifelong passion for software product integrity and software configuration management in particular.

Title: Software Configuration Management: An Investment in Product Integrity
Authors: Bersoff, Edward A.; Henderson, Vilas D.; Siegel, Stanley G.
Publication Date: 1980
Publisher: Prentice Hall
Pages: 351 (main body only); 11 (bibliography)
ISBN: 0-13-821769-6
Availability: Out-of-print but available from specialist dealers
Amazon: UK US
Price guide: Varies widely. Reasonable condition copies can be obtained for ~£15 / ~$20

Review in a Nutshell

I maintain that this is still one of the best books written on the subject.

Review in Detail

As I said in the opening remark, this book was, for me, quite literally life changing. I read this book while working as a software engineer in the mid-80’s. Why? Partly from curiosity, but also because the team I was working on were looking to improve control on the product as we migrated from an old PDP-11 to a new MicroVAX.

That was my motivation, so should you seek out a copy and read it?

Who is it aimed at?

The book is aimed at a non-technical audience unfamiliar with software configuration management (SCM). This does not mean there is no value in reading the book if you are technically inclined or already familiar with configuration management. Far from it. I enjoyed rereading it recently and, even though it has been over twenty years since I first stumbled across this book in the underused library where I worked, I enjoyed being reminded of the fundamentals (with a twinge of nostalgia admittedly).

The book’s aim is to lay out the core principles of SCM and places them in the context of system development. This it does effectively. If you are looking for a step-by-step implementation guide then this is not the book for you.

Is it well written?

Bersoff, Henderson and Siegel write in a relaxed, semi-formal style that is easy to read. On occasion the walked through examples become a little laboured, but this may be a consequence of my familiarity with the subject. People reading the book early in their configuration management careers will find the detail helpful.

Does it cover the subject matter?

The book is divided into eight chapters:

  • Chapter 1: The Problem of Software

    Where we are introduced to the nature of software and the problem to be solved.

  • Chapter 2: Managing the System Development

    Configuration management is put into context within the system development lifecycle.

  • Chapter 3: Attaining and Maintaining Product Integrity

    Lays the foundation for implementing configuration management.

  • Chapter 4: Configuration Identification

    Explains the identification problem and lays out it solution within the SCM framework.

  • Chapter 5: Configuration Control

    Explains the problem of change control and then proceeds to explain its implementation in the context of the configuration management plan.

  • Chapter 6: Configuration Auditing

    Explains the problem that auditing addresses. Expands on the auditing principles and demonstrates them with a case study.

  • Chapter 7: Configuration Status Accounting

    Explains the problem that status accounting addresses and the principles on which it is founded.

  • Chapter 8: Epilogue

    Ties up loose ends and discusses the consequences of implementing configuration management.

These eight chapters cover all that matters in configuration management and places it into the wider system development context well.

The material discusses at length the documentation used in configuration management and some of this is a little dated. There is, for example, much emphasis on manual processing and little on automation. This is entirely forgivable given the paucity of supporting applications at the time the book was written.

The development methodology described in the book is, as one might expect of a book written some thirty years ago, based on a more traditional waterfall model. This should not, however, deter you from reading this book. The core principles remain sound and are easily adapted to any development methodology.

Despite the lack of coverage for support applications (such as change control systems or even version control systems) the principles are described well and almost all of the manual processes described are relevant to modern implementations of SCM even though we tend to rely more on databases, rather than manual paper records, to hold and process information.

What is missing?

Automation and the use of modern applications to control the SCM process are not covered for the obvious reason that they were less common in the late 70’s and early 80’s when this book was written.

This book, quite rightly in my opinion, is ‘bare metal’ SCM. There is no discussion of other lifecycle disciplines beyond that required to place SCM in the context of the system development processes.

While the book discusses some implementation issues it is not a guide to implementation. As such there is no implementation plan beyond a brief discussion of the configuration management plan.

Standards are not discussed, but any standards extant in the early 80’s would be superseded by now so this is no great loss.

Would I but it now?

So, would I buy this book now, knowing what I do?

Yes! Absolutely and without reservation. (In fact I did. The copy I recently re-read was obtained only six months ago from a second hand book seller on Amazon for the princely sum of fifteen of your English pounds sterling.)