How to introduce maturity in software change management $

Transcription

1 How to introduce maturity in software change management $ Lars Bendix Department of Computer Science Fredrik Bajers Vej 7E Aalborg University Denmark bendix@cs.auc.dk Abstract: In this paper we want to suggest a structure for analysing and measuring the Change Management capability of software development organisations. Although Change Management is one of the fundamental tasks of software development, it is still exercised with little discipline and rigor by both industry and academia. With the aid of the proposed model is will be possible, in a structured way, to analyse an organisation to see how well it performs on each of the specific functions of Change Management. The model can also be used to design tools or plan methods for Change Management or even to teach its concepts in a gradual and structured way. We discuss general principles for structuring the model into key areas and features and apply them to Change Management functions. Furthermore, we discuss the general guidelines for dividing the practice of the features into levels of increasing sophistication. We then go on to apply these principles and guidelines and in turn describe each of the key areas: Configuration Control, Build Management, Version Control, Group Support, Accounting Management, Management Support. Finally, we discuss alternative ways of organising our model and indicate areas where future work has to be done to further develop and perfect the model. $ This work was supported, in part, by the Danish Research Council, grants no and

2 1 Introduction We want to suggest a structure for measuring the maturity of the Change Management (CM) capability of software development organisations. The purpose of this structure is to work as a maturity framework, which will aid software developers and students in improving their abilities to handle software configuration and versioning problems. Versioning of components and composition of systems is a major problem to overcome in order to obtain quality software. Quality of the product and consistency in the process is the main focus in today s companies as reflected in the increasing interest in standards like the ISO9000. Such standards do mention software configuration management as an important component, but are rather vague as to the contents and practice of it as they give no details. This leaves both educators and companies without much help with respect to improving this specific capability. In this paper, we develop a model that will detail the software change management capability. The model is intended to be useful both in education and for practical application in companies. Software Change Management, or Configuration Management as it is often called, is one of the most important tasks which has to be mastered in software development projects. In his seminal book on the Mythical Man-Month [Brooks75], Frederick Brooks calls it an indispensable technology. In a later paper [Brooks87], which has also become a classic, it is stated that changeability is one of the essential things for which there is no silver bullet. Some of its activities used to be taken care of by a person called the project librarian. This person was central in the effort to co-ordinate and synchronise different parts of big projects and to keep them consistent. Recent models dealing with measuring the maturity of software development organisations consider Configuration Management to be a central aspect. In the Capability Maturity Model [PC*93], it is found at level 2, and mastering it is one of the prerequisites for an organisation to progress from the Initial level 1 where anarchy and disaster often reign. In the ISO9000 system, it is one of the activities that has to be implemented and documented if an organisation is to obtain certification. There exist many books on software configuration management [BHS80], [Buckley93] to mention but a few. There is also an annual international conference entirely dedicated to the subject, besides several national conferences and interest groups. So, why is there a need for a maturity model? Because people, mainly from industry, are still complaining that there is no or little help to find for them [Adams95]. Neither for finding out how to evaluate tools, nor for finding out exactly what is needed in your organisation. 2

3 Furthermore, it is a problem that most tools are not able to evolve and grow with the organisation. Therefore, we feel that there is the need for a framework, which can be used as help for analysing organisations, evaluating tools before buying one, and for constructing tools, which are more flexible and versatile. It is also our personal experience that within academia a similar need for such a framework exists. It would be very helpful for structuring the teaching of the fundamental concepts. It could be used to focus academic discussions and provide a framework for comparisons between research. Finally, it could be used to guide future research into Change Management besides being an object of research itself. The ultimate goal of this work is to promote a better understanding of the process of Change Management. Through a better understanding, we should see a better practice of the process and it should increase productivity, improve quality, facilitate reuse, and, most importantly, enhance the maintainability of products. The latter is a major gain as more than 2/3 of the total lifetime costs of a product is spent during the maintenance phase [Sommerville96]. At least in part, lack of or wrong application of Change Management, causes some of the bugs found in software. What this model can be used for is to select a set of key areas and features that are important to your specific context. And then analyse and evaluate an organisation s capability with respect to this set. 2 The context of change management Software is usually developed following a specific method that has some defined phases, which it goes through. Most methods have phases for analysis, design, implementation and test; after which the product is released and enters the final phase of maintenance. The maintenance phase can be thought of as mini cycles of the main development cycle where a new requirement (or a bug) requires a little additional analysis, a small change to the design, modifications to the implementation and updated test cases. All the products of the main cycle (specifications, designs, code, test-cases) are affected by changes in the maintenance phase and it is, therefore, important both that products are made with maintainability in mind and that Change Management is able to follow changes through all the phases. It is important that Change Management is planned before development starts and not just put on as an afterthought in the maintenance phase. This allows the Change Management method the possibility to influence the development discipline in a positive way. More importantly, it also permits us to gather information about the project right from the start. One of the major benefits of Change Management is that it serves as a central collection of all information. 3

4 This information can then be queried to obtain development histories or it can be extracted to be used as input data for various metrics. This aspect of Change Management as an information repository is very central. Programmers spend more time interacting with other people than working alone [Sommerville96], and most of this interaction is exchange of information. The use of good and powerful Change Management methods and tools can greatly reduce the need for this interaction, as the information is readily available. One of the greatest dangers in software development is that this information is not documented but remains in the heads of the programmers. There are many general texts on software development, which places Change Management as one of the activities in the development and covers it in varying degrees. However, even if some books give a more in-depth treatment of Change Management than the others do, they do not cover all the possible ways of implementing Change Management and can only serve as one example of how it can be practised. Standards and models for how to perform and manage the development process in general, like ISO9000 and the Capability Maturity Model, do specifically mention Change Management (or configuration management) as an important and basic component. They mention some concepts and principles that have to be in place in an organisation for it to be certified or to advance to the next level (but no advice on how to get there). They are, however, not very detailed and are not specific on what are the possible best practices. The most serious shortcoming in both textbooks and standards is that their approach is not levelled. Change Management is described as something that is performed in just one standard way and alternatives are seldom touched upon. It is our belief that this is not true. Both a small project-group at university developing an experimental prototype and a telecommunications project with more than thousand programmers and several MLOC of production code can benefit from exercising Change Management. It should, though, be obvious that the university project would get nowhere if it implemented the same Change Management procedures as the telecommunications project should be using. Moreover, the telecommunications project would soon end up in chaos if it used the Change Management methods that would suit the university project. Too little and too much Change Management is bad for your project s health. The objective of this work is to provide a model that is levelled and can be used to make sure that a project has the right amount and sort of Change Management. Neither more, nor less. We propose to seek this goal of improving the quality of the Change Management capability through a two- 4

5 sided strategy. First empirical data is gathered, then the model is extended to include also the industrial dimension based on this data and it is put to a careful test in practice and adjusted according to the experiences gained. In the following, we will first describe the general structure of the model and the principles that has led to this structure. Then we will go into details with the contents with the model at its present state. The current model is based on our previous experiences in an academic setting [ABC90] and [Bendix93], enhanced with information gained from interviews with a dozen companies in order to enforce the industrial aspects of the model [Bendix98]. 3 Model structure The inspiration for our model has been work on maturity models for software development in general [Humphrey87]. This work does not carry over directly as is deals with the whole software development process and we are only dealing with one capability in this process. However, the general guidelines for establishing the model can be used, as we too have to distinguish key areas and levelled features within these key areas. In working with the general concepts and methods for change management we have distinguished six different categories in which we have been able to assign these concepts. Each category is treating an orthogonal task that has to be carried out in exercising the change management capability. The traditional sub-division of tasks fits into this new categorisation which is actually larger than the previous ones, as it covers aspects that are not covered in those. The six categories are: version control, build management, configuration control, accounting management, group support and management support. The first four categories cover most of what is traditionally considered to be part of software configuration management. The group support category focuses on the co-ordination and collaboration aspects of groups when they have to work towards a common goal. This aspect is traditionally covered at a very formal level, but in recent years much new research has been carried out in collaborative work and the results from this has been included in this category. Finally, the management support category has been added as a result of interviews with companies. Through asking practitioners and managers how change management is carried out we realised that there is often a big discrepancy between reality and they way it is thought to be carried out. In order to structure each category into increasing levels of maturity we have used a series of mechanisms that have served as guidelines when features have to be placed at a specific level. They are covering aspects like: the number of people going from individual aspects to organisational matters, the methodology used in the development ranging from informal to formal 5

6 models, the size of the system supported measured in lines of code or equivalent ways, the life-time of the system supported ranging from no support prototypes to guarantees of support for an almost unlimited number of years, the complexity of the system family dealing with the number of more or less similar variants of the same system, the computer support the degree to which work is manual or has been automated. 4 Model contents We now move from the overall structure of our model to the details of the contents. Each of the key areas will be characterised, giving examples of increasing levels of maturity using the levelling mechanisms described above. Version control This key areas deals with support for the fact that more versions of artefacts exist. The change management system should be able to handle gradually more sophisticated versioning structures such that it can progress with the user s needs. It has to give overview of these structures and to provide for easy identification and retrieval of past versions. This includes aspects such at capturing various kinds of information as attributes and the use of such attributes for selection of a specific version. Build management This key area deals with support for putting artefacts together to form systems. This covers the ability to describe the structure of the system from its constituent parts. Furthermore, varying degrees of automation in the creation of the system can be useful in different occasions. Finally, there is also the need to consider ways of optimising the construction process in terms of elapsed time. Configuration Control This key areas treats the support for handling systems as artefacts and the fact that systems are not composed from a homogeneous set of artefact. This covers also the concept of advanced system models that can describe generic systems, which can then be instantiated using selection rules. However, the most important aspect of configuration control at higher maturity levels is the aspect of traceability. To be able to relate different types of artefacts to each other and the capacity to group changes in logical units. Group support This key area is dealing with the support for the collaboration between people in a group effort. Locking, merging and other mechanisms for synchronising 6

7 the work of more people are part of this key area. Likewise are aspects that support the awareness of other people s efforts and the co-ordination and assignment of tasks. Finally, a mature system should be able to handle problems that derive from the fact that groups may work in a physically distributed fashion at remote places. Accounting management This key area deals with collecting and using information to be used for various purposes. A lot of information is or could be present in all change management systems. Organisations need to use information to guide and control development and for administrative purposes. Metrics have to be produced in order to be able to estimate future projects. Time information is needed for billing purposes and in order to be able to check whether the project meets its milestones. The degree to which it is possible to represent the needed information and to state it as an integrated part of the change management system is an important aspect. Management support This key area treats the more political aspects of introducing and promoting change management into an organisation. This covers the actual commitment of top management and the involvement of developers in the decision processes. Furthermore, the allocation of proper resources for introducing and carrying out the decided change management policies is an important aspect. Who is the driving force in establishing and enforcing company policies and in finding and introducing guidelines and tools. 5 Discussion The model that we have just described is organised in two dimensions. One dimension that covers the six categories and another that covers the different levels of maturity. However, in working with the model in practice we have discovered that this simple way of organisation may not reveal the whole truth about the interrelation between the different key areas. In the simple model, they appear to be distinct and completely orthogonal. This does not reflect the reality we have encountered in companies and which has also emerged from our teaching. It seems that the mastering of some key areas are pre-requisites for being able to master other key areas. For instance it makes little sense to apply advanced mechanisms for configuration control if there is no notion of version control and build management. 7

8 Management Support Version control Configuration control Group support Build management Accounting management This seems to indicate that the model should actually be organised in three dimensions, as shown in the figure above. The first two dimensions now describe six key areas and their interrelations, and the third dimension is then the levels of maturity for each key area. This gives rise to a more complex model and a model where key areas are no longer completely independent. It is, however, also a model that is richer and closer to reality. It is not obvious from our experiences so far which model is the better one. It might even be that both views of the model are able to co-exist. The simple model is definitely easier to apply for analysing organisations, while the more complex model seems more adequate for guiding research and structuring teaching. More research into this aspect is needed and we intend to investigate this too. Related work on improving the maturity of the change management capability does exist. It is, however, more focused on teaching the basic concepts and problems to be solved [Dart98] or giving advice and best practices as guidelines to follow [CW98]. The underlying model is never made clear and this makes it difficult to structure the concepts and guidelines, and to apply them in a consistent way to a given organisation. Furthermore, no effort is made to grade the concepts and guidelines such that they can be introduced and taught in a proper and natural way. Finally, it is difficult to use them to establish the right level of capabilities that an organisation needs at any given moment. 6 Conclusions We have presented a levelled framework for establishing the maturity of the change management capability of software development organisations. The model has proved itself for teaching and guiding research in an academic setting and has obtained industrial aspects through interviews with a dozen companies. We still need some experiences and guidelines in how to progress from one level to the next. In the maturity models that have inspired this model, it is 8

9 estimated that it takes two to three years at one level before the organisation is ready to proceed to the next level. In a university setting, where students are taught the concepts and principles of change management we have been able to advance much faster than that. This might, however, be caused by the small size and informal organisation of the groups. More lengthy studies are needed to see if this carries over to an industrial setting and larger and more formal organisations. References: [Adams95]: Chris Adams: Why Can t I Buy an SCM Tool?, in Proceedings of Selected Papers from the SCM-4 and SCM-5 Workshops, Lecture Notes in Computer Science, LNCS 1005, Springer Verlag, [ABC90]: Vincenzo Ambriola, Lars Bendix, Paolo Ciancarini: The Evolution of Configuration Management and Version Control, Software Engineering Journal, Volume 5, Number 6, [Bendix93]: Lars Bendix: A Taxonomy for Software Development Environments, in Proceedings of the Second Electrotechnical and Computer Science Conference, Portoroz, Slovenia, September 27-29, [Bendix98]: Lars Bendix: A Maturity Model for Software Change Management, Internal Report, Department of Computer Science, Aalborg University, Denmark, forthcoming. [BHS80]: Edward H. Bersoff, Vilas D. Henderson, Stanley G. Siegel: Software Configuration Management: An Investment in Product Integrity, Prentice-Hall, Inc., [Brooks75]: Frederick P. Brooks, Jr.: The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley Publishing Company, [Brooks87]: Frederick P. Brooks, Jr.: No Silver Bullet - Essence and Accidents of Software Engineering, IEEE Computer, April [Buckley93]: Fletcher J. Buckley: Implementing Configuration Management: Hardware, Software, and Firmware, IEEE Computer Society Press, [Dart98]: Susan Dart: The Agony and Ecstasy of Configuration Management, tutorial held at the Eighth Inter-national Symposium on Systems Configuration Management, Brussels, Belgium, July 20-21, [WS98]: Laura Wingerd, Christopher Seiwald: High-Level Best Practices in Software Configuration Management, in Proceedings of the Eighth International Symposium on Systems Configuration Management, Brussels, Belgium, July 20-21, [Humphrey87]: W. S. Humphrey: Characterizing the Software Process: A Maturity Framework, Technical Report, CMU/SEI-87-TR-11, Software Engineering Institute, Pittsburgh, Pennsylvania,

10 [PC*93]: Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber: Capability Maturity Model, Version 1.1, IEEE Software, July [Sommerville96]: Ian Sommerville: Software Engineering (5th edition), Addison-Wesley Publishing Company,