TRANSITION TO OBJECT-ORIENTED SOFTWARE DEVELOPMENT

Editors
Mohamed Fayad, Mauri Laitinen

 

Preface

The popularity and sophistication of object-oriented (OO) technology has grown dramatically over the last few years. Several organizations sponsored early attempts to use OO technology that demonstrated its potential for delivering high-quality software. Then, full-scale projects were developed that proved the promise. Now, as an established technology, companies are using object-oriented methods to implement a variety of projects, and many more companies have decided they will also adopt object orientation. While information abounds on software development methods and object-oriented programming, there is still little guidance for organizations that already develop software to make the transition to object orientation. This book is designed to fill that gap. We present a guide that takes object orientation out of the textbooks and makes it available for software teams to its power in the real world, on real projects having real people, budgets, and budget deadlines.

The central claim of this book is that OO technology has become not just practical, it has become the only effective way to deal with the complexity and reliability demanded of current software. But formidable obstacles stand in the way of moving to object technology. Transitioning to object technology is considerably more complex than just moving to a new design technique or to a new programming language. The move requires a radically different model for software development from the ones organizations currently use, and it further requires a simultaneous adoption of software engineering techniques. This transition requires, in turn, a change of culture throughout the organization and the allocation of significant resources. Because the change is so widespread, the risks associated with the transition are equally large. By providing a transition framework for existing organizations, we intend to help organizations minimize the risks, costs, and schedule impacts.

We maintain a relentlessly practical viewpoint about software development. We avoid the common ploy of presenting ideal situations in which project goals are clearly understood at the project's outset and remain constant throughout the development, where time, money, and tools are unstintingly available, and where staffing is never a problem. Moreover, common presentations usually ignore some of the other challenges of transition, such as supporting the existing system, integrating with legacy systems, and encountering resistance to change. In our experience, the real-world project lacks almost all the attributes the ideal project assumes. Our approach, then, is to identify challenges in product development, especially those encountered in a transition to object technology, and to recommend ways to minimize the impacts of these challenges. In some cases, minimizing long-term costs implies significant up-front costs. In these cases, we describe how to assure that the costs aren't wasted. One of the results of our approach is that we make some radical claims.

First, software is difficult to develop. Reading and following the advice in this or any other book will not make software development easy or entirely predictable. As Fred Brooks puts it, there is "no silver bullet" to kill the monster of software development. But looking at software today, it is more capable and reliable than the software of even five years ago. It shows that making increasingly good software is possible even if it isn't easy. What we describe is how to make software development tractable and the output of development, as well as the development team, more adaptable.

Second, making the transition to object-oriented software engineering will take time, money, tools, and training. There is no shortcut to transform an organization overnight, and there is no way to make it inexpensive. There are, however, quite a few ways to make the transition slower, more expensive, and less successful. Our intent is to identify those ways and to avoid them.

Third, there is no ultimate development method. Every project has different needs, and development methodologies must be tailored to those needs. A corollary to this assertion is that there is no ultimate object-oriented technique. Every object-oriented technique has shortcomings and hidden costs that make it a poor match for some projects. By identifying the basic parameters of your project and by using our recommendations, you should be able to choose an object-oriented development method that will suit your needs without wasting time and money on an inappropriate technique.

The transition framework this book describes is based on real-world experience and discusses the areas of culture change, object-oriented method selection, development environments, staffing, training, tracking and controlling object technology projects, and process documentation. We also cover planning, cost estimation, object-oriented software metrics, and documentation. Within this framework, we explain why moving to object technology is vital and why it is a challenging transition. For each section, we detail how to recognize the challenges and how to deal with them in the most effective way. Each chapter also gives a set of tips and practical advice for making the change.

This is not a how-to book about object-oriented programming. It is a book about the technical, social, and management issues involved in running large software projects, and it is specifically designed to help organizations effectively apply object-oriented technology in the real world. We present guidelines for such management issues as project and personnel selection, cost estimation, and project tracking. Although much of the information we provide is applicable to any software organization, we pay special attention to the way object technology affects these areas and the special needs of an organization in transition. We analyze technical issues such as process documentation, reuse criteria, inspection methods, and the integration of legacy systems. We give tips on avoiding hidden costs, technical blind alleys, and time sinks. We augment these warnings with positive advice on best practices and effective approaches.