 |
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.
|