wiley-logo-sm.gif
> wiley.com

TRANSITION TO OBJECT-ORIENTED SOFTWARE DEVELOPMENT

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.

Major Book Themes

This book covers transition issues by answering the following questions.

  1. Why is moving to object-oriented development essential?
  2. What makes the transition to object-oriented software development difficult?
  3. What are the essential transition issues and how can the costs and schedule impacts be minimized?
  4. How should we plan and manage object-oriented software development projects and large-scale applications?

Minor Book Themes

By fully discussing the major themes, we also cover the following minor themes.

  1. The necessity of moving to object-oriented software development.
  2. Planning for the transition.
  3. The software development plan as the most essential and useful technical document.
  4. Changing to a software engineering culture.
  5. Selecting an object-oriented method and appropriate CASE tools.
  6. New staffing positions in an object-oriented development team.
  7. Coordinated, purposeful training.
  8. Practical strategies for interfacing to legacy systems.
  9. Real-world reuse.
  10. Prototyping and modeling in object-oriented development.
  11. Tracking and controlling projects with work packages.
  12. Creating, documenting, and using software development processes, and practical process improvement.
  13. Creating, collecting, and analyzing metrics effectively.
  14. Making inspections work.
  15. Practical technical documentation.

Who Should Read This Book

This book is intended for a broad community of computer and software professionals, in both industry and academia, involved in the management and development of software projects and in software engineering research. Software engineers, programmers, managers, system engineers, and application program developers will greatly benefit from the book. People in software process groups, contract administrators, customers, technologists, and software methodologists will also benefit.

Project managers will benefit by learning proven object-oriented transition approaches to software development and applied object-oriented techniques, such as design patterns, application frameworks, and object request brokers to various problem domains. The results described here should save project managers many weeks of experimentation using object-oriented approaches.

Software process groups can use the transition framework to gain a better perspective on what object-oriented processes will work best for their particular problem domain and what false starts and pitfalls to avoid. They can also learn how to document processes using the notation and templates provided here.

Customers and end users are the most important part of any software development. The belief that the insights of the customers or users are not the most important information used on a development project will doom developers to fail. Customers must understand the benefits and challenges of transitioning to object-oriented development.

Software methodologists will derive a benefit from using this book to learn what has worked and what has not worked when applying object-oriented technology in various situations This will allow software methodologists to focus on improving problem areas in existing techniques and help them avoid these problems when developing new techniques.

Graduate courses on software engineering, object-oriented software engineering, or object-oriented technology can use this book as a supplemental text for students. Courses on system engineering, advanced courses on software management, or software maintenance can also use this book as a supplemental text. Prerequisites include a basic knowledge of computing terms and concepts, and a basic knowledge of software engineering concepts and techniques.

Book Organization

This book consists of four parts. Part One has two chapters and describes the transition to the object-oriented software development framework. The two chapters of Part Two describe planning and preproject activities. Part Three has six chapters and describes object-oriented insertion activities. In Part Four, six chapters describe project management activities. Most chapters conclude with tips and practical advice and selected references.

Part One: A Transition Framework

Chapter 1 is an introductory chapter discussing the promise and pitfalls of object-oriented technology as well as the reality of object-oriented technology. It provides definitions for several object-oriented and software engineering concepts.

Chapter 2 explains the compelling reasons to move to object-oriented development. It describes the transition framework stages, the changes for management and personnel and the challenges of transition.

Part Two: Planning and Preproject Activities

Chapter 3 covers Software Development Planning. It describes the minimum planning activities required and recommends a new planning policy that can be adopted by any company.

Chapter 4 covers the cultural changes needed to move to object technology. It describes the conditions needed to change, organizational subcultures, the challenges inherent in changing not only the development team but the whole organization, and methods for dealing with resistance to change.

Part Three: Object-Oriented Insertion Activities

Chapter 5 discusses the process of selecting an object-oriented software development technique that is appropriate for the project.

Chapter 6 describes a process for selecting the right CASE tool for your project. Selection criteria, matching tools to methods, and avoiding CASE tool problems are all discussed.

Chapter 7 covers project staffing and the new organizational positions required for object orientation. New positions, their roles in the organization, and experience requirements are all described. It discusses strategies for dealing with shortages of experienced object technology developers and the use of consultants during the transition.

Chapter 8 describes a concerted approach to training that maximizes the speed with which the staff can master object-oriented development. It covers both formal and on-the-job training, the fundamental issues in training and recommends a process for matching the training to the appropriate project phase.

Chapter 9 covers how to deal with legacy systems. A preexisting, non-object-oriented software system is called a legacy system, and upgrading and interfacing object-oriented systems with legacy systems is often necessary. We describe how to work with legacy code by creating an object-oriented shell around the module. The shell approach provides cleaner interfaces and the object-oriented software will interact with these modules as existing objects or classes.

Chapter 10 covers reuse in general and explains how to budget for reuse. Since truly reusable software costs extra time and money to develop, determining how much to spend on reuse is a strategic decision. This chapter also describes various reuse strategies and methods.

Part Four: Object-Oriented Project Management Activities

Chapter 11 covers analysis, modeling, and prototyping and proposes several development approaches. Object-oriented models and prototypes are a cost-effective way to study software designs and evaluate alternatives. It discusses when to use prototypes and when to discard them. It describes key factors for building and scheduling object-oriented prototypes.

Chapter 12 describes effective project tracking. Large software projects require accurate and detailed tracking systems to help development teams ascertain the current performance against schedule and to provide access to project data. This chapter describes object-oriented estimation and tracking systems and describes processes for controlling the project.

Chapter 13 describes how to define and document software development processes. It covers where and how to start with software processes, how to use process as a baseline for improvement, and provides guidance on documenting software development processes.

Chapter 14 covers how to create, collect, and analyze appropriate software project metrics. It describes appropriate and inappropriate collection and use of measurement and the tradeoffs between gathering information and impacting the team's performance.

Chapter 15 discusses inspection of object-oriented software. Software inspections substantially improve product quality and help to keep new OO development on track by reducing defects and decreasing overall cost. In addition to the mechanics of inspection, the chapter discusses the use of new technology such as intranets to dramatically improve inspection efficiency.

Chapter 16 describes how to deal with technical documentation. Good documentation is one of the most valuable assets of a development project, but poor or out-of-date documentation is a major detriment. This chapter discusses how to write quality software documents, how to manage them, and how to keep documentation useful.

The book concludes with three appendixes: A sample process for software inspections that graphically illustrates the process using a generic process template; a summary of tips and practical advice; and annotated references.

[Click here to read the Dedications and Acknowledgments for this book.]

 
Cover

 ISBN 0-471-24529-1
368 pages
August 1998

Wiley Computer Publishing
Timely. Practical. Reliable.