TRANSITION TO OBJECT-ORIENTED
Mohamed Fayad, Mauri Laitinen
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
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
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.
- Why is moving to object-oriented
- What makes
the transition to object-oriented software development difficult?
- What are the
essential transition issues and how can the costs and schedule impacts
- How should
we plan and manage object-oriented software development projects and
Minor Book Themes
By fully discussing the
major themes, we also cover the following minor themes.
- The necessity of moving
to object-oriented software development.
- Planning for
- The software
development plan as the most essential and useful technical document.
- Changing to
a software engineering culture.
- Selecting an
object-oriented method and appropriate CASE tools.
- New staffing
positions in an object-oriented development team.
- Practical strategies
for interfacing to legacy systems.
and modeling in object-oriented development.
- Tracking and
controlling projects with work packages.
documenting, and using software development processes, and practical
collecting, and analyzing metrics effectively.
- Making inspections
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
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.
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
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
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
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
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
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
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
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.]