Foreword:
This book gives a refreshingly interesting and different perspective on object technology for the practitioner. It has twin foci of process and metrics. This book is unique in combining these two elements, both of which are vital for the successful management of a software development. A process defines an orderliness in development, while metrics offers a tool with which to evaluate success. Software development can never attain quality without process and metrics: the topics of this book.

The type of software process used in an organization is indicative of the company's maturity. A well-defined process is needed if successes are to be understood sufficiently that they can be repeated. Increasing organizational maturity supports a process that can be managed in the sense of continual improvement --- lessons learned are incorporated into future modifications to the software development process so that eventually the process itself is fully optimized. Metrics have a key role to play in quantifying both the process as it matures and also the products that are produced. Better processes produce higher quality products.

In many ways, this book encompasses the interests of both practitioners and researchers: an interesting and most important area in which to work. Object technology is itself still a relatively new and maturing discipline in commercial applications: today's research is tomorrow's practice. Managers of object technology need to monitor and understand the results of the researchers, and in turn, the researchers need to focus their attention on areas of immediate relevance to the software industry. Here is no ``silver bullet'' gained by merely combining process and metrics: Caveats are clearly stated and exciting opportunities publicized. For success in object technology, it is in fact critical that managers be fully aware of both pros and cons. This book focuses on those knowns and unknowns such that success can be maximized. All in all, this is a thoughtful and thought-provoking book.

B. Henderson-Sellers
Director, Centre for Object Technology Applications and Research (Victoria)

Preface:
A software development organization switching to the object-oriented (OO) paradigm faces quite a challenge. All phases of the life cycle are affected: analysis, design, implementation, testing, and maintenance. An organization that has made the switch still has a long way to go to become a mature development organization - mature in the sense of CMU's SEI maturity criteria.

It is not enough to use an OO programming language and any of the OO analysis and design methods currently available. A level 3 organization as defined by the Software Engineering Institute (SEI) must routinely use a defined development process. In this book we describe a generic OO analysis and design process. The ability to monitor progress is also required. Planning, not only of the coding phases, needs estimators. Metrics for progress monitoring and the estimation of effort are developed in this book.

Object-oriented quality metrics is a novel topic. Dreaming up metrics is the easy part. Associating with numeric ranges the qualifications good and bad (and intermediate judgments) is the hard part. Going beyond measuring many artifacts in a system and identifying exceptional cases with respect to a certain metric is unrealistic at this point. Hence our presentation of quality metrics should be seen as a framework for organizations that want to collect historical data systematically. Alternatively, it is hopefully a source of inspiration for CASE tool companies that may want to automate the gathering of metrics.

This book is aimed primarily at practitioners. In particular, we want to illustrate with an example how to go from requirements through analysis and design to implementation. On the way, we show how micro processes are followed, how effort prediction can be carried out, and how quality metrics can be applied.

Execution of this agenda requires choosing an example that is not too trivial, yet not too hard, and that is easily understood by a broad range of readers. We have chosen a fancy home heating system that has been used by both Kerth [Kerth] and by Booch [Booch]. We present an analysis of this system that is unusual in that all entities such as rooms, temperature sensors, and water valves, are made into autonomous objects. This gives us ample opportunity to illustrate how to deal with the removal of paralellism during design since our target implementation is a C++ simulation program that has only a single thread of control.

Using C++ is not a happy choice. We are quite embarrassed by this language. In fact, we take the position that software development should stop after a high-level design is completed. Commercial tools are already available that can execute high-level designs, often with satisfactory performance.

The structure of this book is as follows. An introductory chapter is followed by three parts that cover analysis, design, and implementation. Each part has four chapters that cover concepts, micro process, metrics, and the running example in which these notions are applied to the home heating system. footnote{Of course, we do not suggest that software development always follows a waterfall macro process. At the same time, we do not rule out situations where a waterfall process can be applied. We discuss multiple macro processes and outline which one to use when.}

Is this book aimed at software developers or at project managers? It is aimed at both. We want developers to become more aware of development processes and metrics, which are traditionally more in the realm of management. Software engineers are often weary when their activities are planned. Unrealistic schedules in the past are typically responsible for this situation. We claim that more detailed micro processes outlined in this book will be helpful for all parties. Sometimes it is claimed that an articulated process impinges on the creativity of a developer. Divide and conquer is the most important technique in problem solving. Capturing software development experience and expressing it in the form of a micro process should be recognized by all as a contribution to the state of the art. This presumes that a micro process is used as a guideline from which one can deviate instead of as dictums that are carved in granite.

We downplay the features of our graphical notation. Everything we express can be done in any of the existing popular notations. A neutral notation was needed to avoid the impression that the key topic of this book - process and metrics - applies only to a specific method. The graphical notation has been used before in de Champeaux et al. OO System Development [OOSD]. In contrast with what was done in [OOSD], we use the same graphical notation, with extensions, for design activities.

Acknowledgments
A generous grant from Alan Apt, our editor, allowed us to obtain the equipment on which this book was produced in camera-ready form. His patience and trust were crucial for having this book ultimately produced.

Students at the Santa Clara University were the perfect ``guinea pigs'' for the analysis micro process and they provided effort metric data reported in Chapter 5.

Robert Martin wrote a report that peeked our interest. He granted us permission to use it; see Appendix A.

Numerous reviewers have given extensive feedback and have helped to beat the English into shape. Special thanks go to Brian Henderson-Sellers, Doug Lea, Simon Moser, and Darrell Parlee. We are happy to maintain full credit for all remaining errors. Feedback is welcome at: email.

DdC
San Jose, 1996 February