Configuration Management Principles and Practice

• Authors: Glen Hass
• Venue: Configuration Management Principles and Practice
• Year: 2003

From the Book:My Life As a Software ProfessionalI have two—well three, really—passions in my professional life: test, configuration management, and process improvement. I started my career as an all-round developer—a little requirements elicitation, a little analysis, a lot of coding and re-coding, and some test—more than 20 years ago. During these first professional years, I always loved the testing part themost—making my work run on the computer and enjoying the satisfaction of being told, in a factual and precise way, that something was wrong, which enabled me to carry out the correction and then finally enjoy the privilege of knowing that at least this error was a secret between me and the computer.My experience grew, and my working teams grew. The problems grew. I wasn't always certain that I had produced what I was supposed to and that I had tested everything. And sometimes an error would reoccur! I got a job as the person responsible for system and acceptance test in a company making software for the European Space Agency, and, for the first time in my then twelve year career, I heard the words configuration management. I had no clue as to what it was, but as I spent hours and hours trying to figure it out, discussing it with the person responsible for quality assurance, and actually using parts of it in my daily work, I came to understand what a wonderful tool I had found.For the first time I was able to trace my test cases to the requirements. I was able to tell, at any given point, how many requirements I had covered in my test specification and how many requirements were still outstanding. I didn't have to encounter thefrustration of having made test cases for requirements that were not going to be implemented anyway. In cases where I had forgotten the reason for a turn in the work, I was able to find a previous version of my test specification and see why I had changed it. I loved it!For the last seven years, I have been working as a consultant, spending a good deal of my time on testing assignments of many different types in many different companies. One of the things I have learned from these assignments is that there is often a difference between what a customer asks for and what he really wants what he needs, i.e. what you want to give him what you are able to give himTest consultants are often presented with a system to test without the right conditions for performing a professional test. The requirements may be in any state from non-existent to brilliantly documented, with a pronounced bias towards the first extreme. If requirements are present, they are most often not up-to-date. This is partly a requirement specification problem, partly a configuration management problem.Test requires resources in terms of time and people to perform the test. These resources are often all too scarce. This is a project management problem. When test consultants plan and perform a test they need to establish an overview of not only what has to be tested, but also how the test is progressing, what errors have been found, and what the state of error correction is. These are configuration management issues.It is a temptation for a consultant to try to deliver what the customer really needs. There are, however, some limitations and threats in this approach. The art is to strike the right balance between what is needed and what is feasible. One of the things to keep in mind as a consultant is to keep up the standards, but keep it light. So I try to keep up the configuration management standards as I solve the test assignment—hoping that my customer will get an idea of what configuration management is, and maybe ask for some assistance in that direction too.Another part of my time is spent assessing software producing companies using the BOOTSTRAP maturity model and method. Like the related Capability Maturity Model (CMM), this model includes configuration management. As an assessor in more than forty assessments, I have time and again seen the blank look in people's eyes when I ask how they perform configuration management. The eyes rarely get less blank if I elaborate and ask about tracing between work products, production of error reports, or other detailed configuration management disciplines.On the other hand people are more than willing to talk about the problems they have experienced due to lack of control over what is being implemented and tested, and when, and lack of control over what errors have occurred and which ones are being corrected and which are not.Despite the fact that configuration management is one of the basic disciplines for a sound development (in CMM it is a key process area at level 2) many people go through a considerable part of their career without any idea of what configuration management is and how it can ease their everyday tasks; just like I did. So I keep emphasizing the importance of configuration management and very often recommend it as one of the first disciplines a company should be working on when embarking on structured process improvement.The Creation ofThis BookIn 1999 the Danish organization Datateknisk Forum, an association of about seventy software producing companies, asked me to write a book on configuration management. The demand was the result of a survey amongst the members as to what topic they needed a book on.Some of the comments and requirements that came back from the survey were: How do you incorporate configuration management in the development process? How do you handle the fact that different kinds of work products, like documents and code, are treated differently? How do you obtain integration between different configuration management tools? How do you handle multi-site development? How do you handle configuration management in relation to OO-development, e.g. component based development?I took on the assignment because in my own experience, configuration management has been of great value, not because I felt I knew much about it theoretically. I know much more now, and I hope I shall be able to convey to the readers some of the understanding, knowledge, and appreciation of the discipline that I have gained during my work on this book. If the readers try at least some of the detailed disciplines of configuration management, it is my hope that they will experience the same enthusiasm about the usefulness of the discipline as I did. The book is written on the basis of the study of literature as well as experience—and also on the basis of attitudes and opinions. It contains a lot of examples, advice, and recommendation to be regarded as the TRUTH, but primarily as the sum of a lot of experience—positive as well as negative.When I learned that the book was to be published in the Agile series, I knew little about Agile development. But as I studied the values and principles I found out that I had practiced it in parts for years. Agile software development is a wonderful idea, and one of the cornerstones of its success is configuration management, so it was a pleasure to be able to contribute to the series with one of my favorite disciplines. The book may seem a bit heavy to some Agilists, but I think it is better to discard some formality and some detailed activities deliberately, knowing what it is that one has not performed, rather than just not performing it, out of ignorance. So, Agilists and others, read and choose!The Purpose of the BookThis book is not supposed to be a primer in configuration management. It does, however, start with an introduction to fundamental principles, in order to establish a basic understanding of the concepts used in the main part of the book, which discusses the more advanced issues encountered when configuration management has to be implemented in practice.The overall purpose of the book is twofold: To scare those who are engaging in configuration management! The book will give the reader an understanding of the complexity and comprehensiveness of the discipline. Configuration management is not easy! If this is what you think, you'll be unable to solve the configuration management task in a professional way. To take away the fear from those who are engaging in configuration management! The book will pr fundamental understanding of the principles of the discipline, their interrelations and usage. Configuration management is not difficult! All you have to do, is to do it; and if you understand the discipline, it is much easier to specify and plan the task so that it fulfils its purpose and becomes as manageable as possible. It is assumed that the reader has some knowledge of other disciplines within software development, such as planning, design, test, and quality assurance.