| ||||||||||||
Early adopters of object-oriented technology took it on faith that object orientation was A Good Thing, offering hope for improving some ugly aspect of software development. Some of these primordial efforts truly flourished, some failed, but overall, a number of such projects quietly began to experience the anticipated benefits of objects: better time to market, improved quality, greater resilience to change, and increased levels of reuse. Of course, any new technology is fun to play with for a short while. Indeed, there is a part of our industry that thrives on embracing the latest fad in software development. However, the real business case for any mature technology is that it delivers measurable and sustainable benefits for real projects.Object-oriented technology has demonstrated its value in a multitude of applications around the world. I have seen object-oriented languages and methods used successfully in such diverse problem domains as securities trading, medical electronics, enterprise-wide information management, air traffic control, semiconductor manufacturing, interactive video gaming, telecommunications network management, and astronomical research. Indeed, I can honestly say that in every industrialized country and in every conceivable application area, I have come across some use of object-oriented technology. Object-oriented stuff is indisputably a part of the mainstream of computing.
There exists an ample and growing body of experience from projects that have applied object-oriented technology. This experience - both good and bad - is useful in guiding new projects. One important conclusion that I draw from all such projects is that object-orientation can have a very positive impact upon software development, but that a project requires much more than just an object-oriented veneer to be successful. Programmers must not abandon sound development principles all in the name of objects. Similarly, managers must understand the subtle impact that objects have upon traditional practices.Scope
In almost every project I have come across, be it a modest two- or three-person effort, to undertakings of epic proportions wherein geopolitical issues dominate, a common set of questions always appears: How do I transition my organization to object-oriented practices? What artifacts should I manage to retain control? How should I organize my staff? How do I measure the quality of the software being produced? How can I reconcile the creative needs of my individual programmers with management's needs for stability and predictability? Can object-orientation help me help my customers better articulate what they really want? These are all reasonable questions, and their answers strike at the heart of what is different and special about object-oriented technology.
This book serves to answer these and many other related questions, by offering pragmatic advice on the recommended practices and rules of thumb used by successful projects.
This is not a theoretical book, nor is its purpose to explain all the dark corners of object-oriented analysis, design, and programming. My previous work, Object-Oriented Analysis and Design with Applications, serves those purposes: it examines the theoretical underpinnings of all things object-oriented, and offers a comprehensive reference to a unified method of object-oriented analysis and design.
Object Solutions provides a direct and balanced treatment on all the important issues of managing object-oriented projects. I have been engaged in hundreds of projects; this book draws upon that broad experience. My intent is to explain what has worked, what has not, and how to distinguish between the two.Audience
My intended audience includes project managers and senior programmers who want to apply object-oriented technology successfully to their projects, while avoiding the common mistakes that can befall the unwary. Professional programmers will find this book useful as well, giving them insight into the larger issues of turning cool looking object-oriented code into real products; this book will also help to explain why their managers do what they do. Students on their way to becoming professional programmers will come to understand why software development is often not very tidy in the real world, and how industrial-strength projects cope with this disorder.Organization
I have organized this book according to the various functional aspects of managing an object-oriented project. As such, it can either be read from cover to cover or selectively by topic. To make this material more accessible, my general style is to present an issue, discuss its implications, and then offer some recommended practices and rules of thumb. To distinguish these elements in the text, I use the following typographic conventions:
This is an issue, usually stated in the form of a question followed by its answer, regarding some functional area of project management.This is a recommended practice, which represents a generally acceptable way of addressing a given issue.This is a rule of thumb, which represents some quantifiable measure about a particular practice.I've numbered these practices and rules sequentially, so that specific ones can be referred to easily.To reinforce certain lessons, I offer examples drawn from a variety of production object-oriented projects, whose details have been changed to protect the guilty. I highlight these examples in the following manner:
This is an example, drawn from some production object-oriented project.Acknowledgments
As a compendium of object-oriented wisdom, Object Solutions owes an enormous debt to the many professional managers and programmers whose contributions have advanced the state of the practice in object-oriented technology.
The following individuals deserve a special mention for reviewing my work in progress, and providing me with many useful comments and suggestions: Gregory Adams, Glen Andert, Andrew Baer, Dave Bernstein, Mike Dalpee, Rob Daly, Mike Devlin, Richard DuE, Jim Gillespie, Jim Hamilton, Larry Hartweg, Philippe Kruchten, Brian Lyons, Joe Marasco, Sue Mickel, Frank Pappas, Jim Purtilo, Rich Reitman, Walker Royce, Dave Tropeano, Mike Weeks, and Dr. William Wright.
A special thanks goes to my wife, Jan, for keeping me sane during the development of yet another book, and who always gently shows me that there is a rich life beyond all things object-oriented. 0805305947P04062001
Object Solutions: Managing the Object-Oriented Project, by Grady Booch, gives developers and managers practical suggestions for applying object technology to their projects. This book is a valuable resource not only for those who are embarking on their first object-oriented project, but also for seasoned OO veterans. Drawing on his world-wide experience in object-oriented software engineering, Booch explains how to apply the sound principles of OO technology in order to make systems development more timely and effective. Booch presents the reader with pragmatic advice, including the recommended practices and rules of thumb that are the hallmarks of successful projects. Object Solutions is an exceptional resource that offers concise, practical advice from a noted OO practitioner.
Product Details
Would you like to update product info or give feedback on images?
|
|
Share your thoughts with other customers:
|
||||||||||||||||||||||
|
Most Helpful Customer Reviews
19 of 19 people found the following review helpful:
5.0 out of 5 stars
Fly On The Wall,
By
This review is from: Object Solutions: Managing the Object-Oriented Project (Paperback)
I swear that Booch was spying on several of the so called "projects" that I was a developer on. It is simply amazing to me how many times the so-called "Harvard School of Business" techniques are used to manage an OO project! I have learned through the school of hard knocks what Booch has written about in this book (wish I had discovered it sooner, a couple of pointy haired bosses could have used it!). Anyway, Booch breaks OO management into seven chapters: First Principles, Products and Process, The Macro Process, The Micro Process, The Development Team, Management and Planning, and Special Topics. I especially found interesting his descriptions on how NOT to run an OO project (oh, and he gives plenty of examples on HOW to run one too!). Booch covers OOA, artifacts, OOD, methodolgies (a biggy with me even on a one person project), evolution (gosh! who would have thought you could have cyclical development???). Identification of classes, objects, symantecs, relationships, etc. He then tackles the team environment: roles and responsibilities (especially the manager's responsibilities!), resource allocation, and tools (this book is not a plug for Rational Rose BTW). Finally: managing risk, planning and scheduling, staffing, costing (a tough one), Quality Assurance (this is not testing!), and he talks some about projects in crisis and what to do. The last chapter is kind of a catch-all containing: User-centric, Data-centric, and Computation-centric systems discussions, along with Distributed, Legacy, Information Management, and Real Time Systems. The appendicies contain: a summary of recommended practices (for those wanting to create a methodology), and rules of thumb. There is a great index, bibliography and glossary to tie up the package nicely. Booch has a terrific writing style presenting what would normally be a dry subject! Definitely for the computer Project Manager's shelf!
32 of 35 people found the following review helpful:
5.0 out of 5 stars
Booch takes no prisoners -- insightful, humerous, brilliant,
By Lou Agosta (lagosta@21stcentury.net) (Chicago, IL) - See all my reviews
This review is from: Object Solutions: Managing the Object-Oriented Project (Paperback)
A strong claim: this book is to be compared to Frederick Brook's The Mythical Man Month [1]. It is that important. Regardless of the fate of object-oriented technology, and the prospects are bright, this text will is already a classic in the making. One insight readers will enjoy is that object-oriented projects benefit from the same good management and technical skills as all other projects. The reverse is also true. It is an example of what Booch previously described as the total "round trip" gestalt (structure) [2]. Booch delivers an account of what these are with the insight and humor likely to make this text a classic. The first chapter, entitled First Principles, explores "When Bad Things Happen to Good Projects". He associates project failure with lack of risk management; building the wrong thing (solving the wrong problem); and being blind-sided by technology. One solution? Be proactive. The "five habits of successful object-oriented projects" can be applied to any project: a ruthless focus on satisfying a well-understood collection of essential minimal features; a culture focused on results, communication, and yet not afraid to fail; the use of (object--oriented) modeling; a strong architectural vision; the application of an iterative and incremental life cycle (p. 25). Booch distinguishes calendar driven, quality driven; documentation driven, requirements driven, architecture driven. Suffice to say focus on one does not mean throwing the others away. To be sure, no project survives for long without making its dates. Yet a chronic obsession with unrealistic, short term dates is a sign of a purely calendar driven project. Yet at crunch time what is the dominant decision making criteria? He considers the strengths and weaknesses of each. Calendar driven will work in the short run. But . . . "For all projects, overtime as a common practice is not only unsustainable, it is an indication of severe management malpractice" (p. 236). This is hard hitting, tell-it-like-it-is stuff. Requirements is the model of commercial applications. The dilemma? Requirements keep changing. Booch claims that architecture-driven projects have all the advantages of requirements-driven with the additional benefit of "encouraging the reaction of resilient frameworks that can withstand shifting requirements and technological calamity" (pp. 20 -21). The second chapter on Products and Processes sets up the mainline of development. The Macro Process (Chapter 3) is closely related to the traditional waterfall life cycle. It is the domain of the software management team. It provides the framework for the Micro Process (Chapter 4), which is closely related to the spiral (iterative) model of development, in which prototyping plays such a central role. Throughout the discussion, Booch emphasizes the benefits or producing "tangible artifacts" (prototypes(user interface), architecture documents, style guides, working software). These "help reduce risk by forcing strategic and tactical decisions out in the open" (p. 60). The Macro Process begins with a section on "The One Minute Methodology". The Micro Process starts out with a section on "I'm OK, My Program's OK". That's what the micro process is about -- programming. Here the focus is on building "cool stuff" with the available technology. The sixth chapter on management and planning beings with a section on "Everything I Need to Know I'll Learn in My Next Project" (p. 229). The point is that good project management is simply "a call for adult supervision" (p. 230). This includes steps to "aggressively seek out risks and question all assumptions" (p. 230). These must be judged against the project's "essential minimal characteristics" (p. 230). The number of times the expression "managing risk" occurs in this text is significant. Duly noted. The final chapter of Special Topics is a nice overview of special problems with different kinds of systems: user centric (extra effort on the end-user interface), data centric (extra effort on the database model), distributed (extra effort on the network), computation centric (extra effort on the algorithms), legacy systems (extra effort on the system interface), real time systems (extra effort on performance). Throughout this discussion Booch provides a wealth of concise, amusing, and insightful sayings. For example, "...The very act of building a system raises questions of behavior that no reasonable amount of analysis can uncover efficiently (p. 87)". "JAD is a high-ceremony approach whose basic principles can be reduced to the one sound bite: "Hey . . let's talk to real users about what they want!" (p. 101). In summary, this text provides the reader with the Zen of project management. An obvious audience for this book is the project manager. She or he will be rescued from having to "suck wind" because a robust, flexible architecture is able to accommodate the last minute changes in requirements. Apparent contradictions are mediated. The actual contradictions are addressed by simulating, providing for the method "as if" system development were a rational process. Building software is an engineering process; and, as such, entails real world compromises implementable and usable by human beings. All roles in software development, from top management to code pusher, will benefit from Booch's experience and insights into the process. References [1] Brooks, F. The mythical man-month. Addison-Wesley, Reading, MA, 1975. [2] Booch, G. Object-oriented analysis and design with applications. Benjamin/Cummings, Redwood City, CA, 1994. --this review was originally submitted to Computing Reviews, but since they had someone else review the book, they did not want it -- so here
12 of 13 people found the following review helpful:
5.0 out of 5 stars
A gold mine of pragmatic OO software development wisdom.,
This review is from: Object Solutions: Managing the Object-Oriented Project (Paperback)
This book represents a gold mine of pragmatic object-oriented software development wisdom and knowledge that offers a competitive advantage to any organization that can apply what is presented. This book is certainly useful for its intended audience - management, but it is essential for those tasked with building complex systems - software engineers. The author guides the reader through an iterative and incremental software development process that places the emphases on architectural design and a risk-driven approach to managing object-oriented projects. At appropriate times the discussion is interjected with recommended practices, rules of thumb, and examples drawn from the authors vast experience in real-world projects. The only place where I can find fault with this book is in the formatting of the text. Important concepts tend to appear unannounced and therefore, I'd recommend that you keep a colored marker handy or make some notes in the margins if you want to locate a given point at some later time.
Share your thoughts with other customers: Create your own review
|
|
Suggested Tags from Similar Products(What's this?)Be the first one to add a relevant tag (keyword that's strongly related to this product).
|
|
This product's forum
Active discussions in related forums
Search Customer Discussions
|
Related forums
|