Anne Mette Jonassen Hass, "Configuration Management Principles and Practice"
Addison-Wesley Professional | ISBN 0321117662 | 2002 Year | CHM | 2,8 Mb | 432 Pages
Addison-Wesley Professional | ISBN 0321117662 | 2002 Year | CHM | 2,8 Mb | 432 Pages
| “ | My Life as a Software Professional I have two-;well, three really-;passions in my professional life: test, configuration management, and process improvement. I started my career as an all-around developer-;a little requirements elicitation, a little analysis, a lot of coding and recoding, and some test-;more than 20 years ago. During these first professional years, I always loved testing most-;making my work run on the computer and enjoying the satisfaction of being told, in a factual and precise way, that something was wrong. This 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 I had produced what I was supposed to and that I had tested everything. And sometimes an error would recur! I got a job in which I was responsible for system and acceptance test in a company making software for the European Space Agency. For the first time in my then 12-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. For the first time, I was able to trace my test cases to the requirements. I was able to tell, at any point, how many requirements I had covered in my test specification and how many were outstanding. I didn't have to encounter the frustration of having made test cases for requirements that weren't going to be implemented. 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! The last seven years, I've worked as a consultant, spending a good deal of my time on testing assignments of many types in many companies. One of the things I've 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 (what you want to give him), and what you're able to give him. Test 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 nonexistent to brilliantly documented, with a pronounced bias toward the former. If requirements are present, they are most often not up to date. This is partly a requirement specification problem and partly a configuration management problem. Testing 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 not only of 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's tempting for a consultant to try to deliver what the customer really needs. However, this approach has some limitations and drawbacks. The art is to strike the right balance between what's needed and what's 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 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 40 assessments, I have time and again seen the blank look in people's eyes when I ask how they perform configuration management. The eyes are rarely 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 problems they've 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. Although configuration management is one of the basic disciplines for sound development (in CMM it is a key process area at level 2), many people go through a considerable part of their careers without any idea of what it is and how it can ease their everyday tasks, just as I did. So I keep emphasizing its importance and very often recommend it as one of the first disciplines a company should work on when embarking on structured process improvement. Creation of This Book In 1999, the Danish organization Datateknisk Forum , an association of about 70 software-producing companies, asked me to write a book on configuration management. This was the result of a survey among 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 multisite development? How do you handle configuration management in relation to object-oriented development-;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've conveyed some of the understanding, knowledge, and appreciation I've gained during my work on this book. If readers try at least some of the detailed disciplines, I hope they will experience the same enthusiasm about its usefulness that I did. The book is based on literature as well as experience-;and also on attitudes and opinions. It contains a lot of examples, advice, and recommendations that are not to be regarded as The Truth but primarily as the sum of a lot of experience-;negative as well as positive. 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 that I had practiced it in parts for years. Agile 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's better to discard some formality and detailed activities deliberately, knowing what one hasn't performed, than to just not perform it out of ignorance. So, agilists and others, read and choose! Purpose of the Book This book is not supposed to be a primer in configuration management. It does, however, start with an introduction to fundamental principles, to establish a basic understanding of the concepts used. The main part of the book discusses more advanced issues encountered when configuration management has to be implemented. 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 you think it is, you'll be unable to solve its tasks in a professional way. To assuage the fear of those who are engaging in configuration management! The book will provide a fundamental understanding of the principles of the discipline, their interrelations and usage. Configuration management is not difficult! All you have to do is do it. If you understand it, it's much easier to specify and plan so it fulfills its purpose and becomes manageable. It's assumed that the reader has some knowledge of other disciplines within software development, such as planning, design, test, and quality assurance. | ” |