To access the contents, click the chapter and section titles Object-Oriented Project Management with UML Go! Keyword Brief Full Advanced Search Search Tips (Publisher: John Wiley & Sons, Inc.) Author(s): Murray Cantor ISBN: 0471253030 Publication Date: 08/01/98 Search this book: Go! Introduction - About the Author Part One—Principles for Object-Oriented Program Management Chapter 1—Object-Oriented Development as a Management Tool Meet the Enemies Inadequate and Unstable Requirements Inadequate Customer Communications Poor Team Communications Unnecessary Complexity Ineffective Team Behavior Conquering Enemies with Object Technology Attacking Complexity Collaboration Development as Collaborative Problem Solving Team Communications Common Vocabulary, Common Language The Right Amount of Communication Team Dynamics Team Formation From Here Chapter 2—The Unified Modeling Language as a Management Tool Using Abstraction Unified Modeling Language Documenting Requirements Use Cases Use-Case Diagrams Documenting Package Requirements Documenting Software Design Software Objects and Classes Attributes of a Good Design Components and Subsystems Levels of Testing Traceability From Here Chapter 3—Choosing a Development Lifecycle Model Lifecycle Model Principles Software Development as Team Problem Solving Four Lifecycle Models Waterfall Spiral Model Rapid Application Development: Time Box Model Controlled Iteration Incremental Builds Recommendation From Here Chapter 4—Planning Object-Oriented Projects Developing the SDP Scoping the Plan Practical Advice Designing the SDP Deliverables Development Environment Size and Effort Estimates Risk Planning Lifecycle Model Work Breakdown Structure (WBS) Schedules Staffing and Organization Product Teams Time-Phased Budget Metrics Plan From Here Part Two—Managing Through the Lifecycle Chapter 5—Managing the Inception Phase Management Overview Team Issues Development Activities The Use-Case Database Use-Case Diagrams Prototyped User Interface Top-Level Class Diagrams System Test Plan Process Tasks Assigning Responsibility Phase Exit Criteria Coordinating Activities Microschedules Program Meetings Customer Communications Managing Deliverables Holding the Requirements Review Meeting Phase Completion From Here Chapter 6—Managing the Elaboration Phase Management Overview Team Issues Leadership Development Activities Use-Case Elaboration Class Design System Design Specification Subsystem Integration and Unit Test Plans Updated Artifacts Process Tasks Coordination of Activities Internal Design Reviews Program Meetings Customer and Manager Communication Holding the System Design Review Meeting Phase Completion From Here Chapter 7—Managing the Construction Phase Management Overview Resetting the Baseline Team Issues Leadership Development Tasks Integration Strategy Class Development Horizontal and Vertical Development User Interface Development Incremental Subsystem Integration and Testing Incremental System Integration The Final Integration User Documentation Updated Artifacts Construction Process Tasks Assigning Responsibility Coordination and Tracking Activities Risk Management Setting the Microschedule Change Control Transition Preparations Team Meetings Operational Test Readiness Review Construction Phase Exit Criteria From Here Chapter 8—Managing the Transition Phase Management Overview Leadership Issues Transition Development Activities The Problem Report Process Addressing Defects Design, Code, and Test Transition Process Tasks Assigning Responsibility Coordination of Activities Build Meetings Program Meetings Customer Communication Transition Phase Exit Criteria From Here Part Three—Measuring Progress and Success Chapter 9—Tracking and Oversight Budget Tracking Understanding the Variances Development Metrics Monthly Status Report From Here: Principles for Success Bibliography Appendix A Index Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc All rights reserved Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited Read EarthWeb's privacy statement To access the contents, click the chapter and section titles Object-Oriented Project Management with UML Go! Keyword Brief Full Advanced Search Search Tips (Publisher: John Wiley & Sons, Inc.) Author(s): Murray Cantor ISBN: 0471253030 Publication Date: 08/01/98 Search this book: Go! Table of Contents - Introduction This book is a practical guide to modern software development It grew out of a course I regularly teach at TASC, which itself began as happenstance I had been asked to appraise an online course on managing object-oriented development I hated it It was a rehash of the old, discredited waterfall methods of software development They replaced the design and code steps plus some object jargon When I expressed this opinion, TASC management threw down the gauntlet, essentially saying, “If you are so smart, then you teach the course.” While preparing the course, I realized a few things: The first is that we in the industry really know how to manage software development There is no reason for software development to be a risky, high-stress business On the other hand, most programs not seem to benefit from what we have learned over the last few years Second, a lot of material must be covered when teaching software management, most of which is not commonly taught in universities And because developers are still the best source of software managers, it is important that a book be available to teach the trade As of this writing, I know of no other book that covers the material that I feel is essential for any project manager The third realization is that the use of objects and object design languages such as the Unified Modeling Language (UML) can improve not only the technical quality of the development: It can also facilitate the task of the project managers I believe that all new software development projects should adopt object methodology and be managed according to the techniques in this book Goals Based on my experience, the available literature, and conversations with my colleagues, staff, and students, this text describes the effective management of software development projects using object-oriented methodology I describe not only what the project manager should through all phases of the project, but explain why the techniques work To that end, the book covers the planning, staffing, organization, development, and delivery of object-based software The day-to-day activities of the project manager are covered in depth, providing leadership and management to your team I include enough theoretical background so that you come to understand the why as well as the how The theory will help you apply the techniques to your particular situation As a project manager, you should have a library of books, because no one can cover all you need to know as you broaden your skill base Although this book covers a lot of ground, I leave such topics as maturing the organization and quality management to other books, and only peripherally cover others I provide references for those who want to learn more about the topics of secondary importance to this book Who Should Read This Book The book’s primary target is software project and program managers, neophytes, and experts, as well as those developers who have an interest in how their roles fit into the overall development process, or even better, who aspire to project management So, too, the managers of project managers should read the book, to develop an appreciation of what your project manager is doing and thereby have a basis for providing oversight The same goes for those who contract software I have strived to make the book applicable to developers of small programs, as well as to development teams working on large programs The techniques described can be applied to research and development projects, internal tool development, contracted software, and shrink-wrapped products To a great degree, this book is self-contained I assume the reader has some experience with software development and some notion of software objects I also assume the reader has at least participated in a software development project and can read a Gantt chart How This Book Is Organized The book has three parts The first lays the foundation for the rest of the book In order to succeed at software project management, you need to understand some important principles These underlying principles are introduced in Chapter This is followed by an introduction to the Unified Modeling Language (UML) and its use in software development in Chapter Chapter also provides an overview of object-oriented design and the UML for the project manager Anyone familiar with the UML can skim this chapter However, there is some managerial advice on managing complexity that even the UML expert may find of use Chapter completes the foundation with a discussion of software development lifecycle models The second part of the book discusses the application of the concepts inherent in the software development phases All the phases and activities of UML software development are covered in detail Chapter details how to plan and organize your project Chapters through describe the software development lifecycle in detail, how to manage throughout the phases: activities, exit criteria, and special managerial and communication issues The third part consists only of Chapter 9; it tells you how to assess and report your project’s status, and it provides the means, budget, and development metrics to verify whether your project is on track Chapter also outlines a format for the program manager to use to succinctly report status and project health to upper management and/or the customer In addition to the body of the book, an ongoing example of a software development project—a manned cockpit simulator for a stealth fighter—is presented in sidebar format throughout The example, while detailed, is fictional and is not based any real project It was written to be sufficiently complicated to show how the book’s methods work The example is intended to help you to understand how plans are set, teams are organized, risks are managed, and code is developed and delivered, not how to actually build a simulator I reviewed the simulator architecture with some developers who tell me it is reasonable, however, I’m not sure I would actually use it in a real program On the Web Site Because one of the goals of this book is to help you in your day-to-day program management, the publisher, John Wiley & Sons, Inc., has established a Web site, www.wiley.com/compbooks/cantor, where you can download material that you might find useful as you apply some the techniques in the book Among the site’s features are: • A sample project file for the simulator example, including a work breakdown structure (WBS) for a software development program described in Chapter • A database template for managing use cases described in Chapter • A Svedlow diagram for tracking development during the construction phase found in Chapter • A development artifact status template from Chapter In addition, the site contains links to other useful Web sites You can also use the site to write me to comment on the ideas in the book and to share your experience In keeping with the nature of all Web sites, the content will change from time to time From Here The value of the book lies in the application of the ideas and technique, so read it and make use of the Web page Try out the ideas They work for me; I think they will for you Thank you for reading the book I hope you enjoy it Table of Contents Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc All rights reserved Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited Read EarthWeb's privacy statement encapsulation, 15 inheritance, 15 packages, 15 static descriptions and design, 15 static descriptions of requirements, 14 planning See SDP what object technology attacks, 5–14 inadequate customer communications, 9–11 inadequate requirements, 5, 7–8 ineffective team behavior, 13–14 poor team communications, 11–12 unnecessary complexity, 12–13 unstable requirements, 5, Object-Oriented Software Engineering (OOSE), 46 objects, 58–59 See also software design achieving modularization, 64 attributes, 58–59 scope of, 59 black boxes, 46 enabling encapsulation, 64 as instances of classes, 59 lowest level of abstraction, 64 methods, 59 properties, 58 object technology, 14–15 OMG (Object Management Group), 46 OMT (Object Modeling Technique), 46 OOSE (Object-Oriented Software Engineering), 46 operational test readiness review, 280–281 output of software process See artifacts P package diagrams, 47, 70–71 captures abstract view of system, 23–24 language and vocabulary, 27 top-level package diagram, 66–70, 116 package-level analogy, 122–123, 125–126 See also Pert estimation packages, 15, 64–70 description, 15 and division of effort, 69–70 documenting, 54–57 modularity support, 73–74 top-level package diagram, 66–70, 116 Parametric Cost-Estimating Handbook, 131 parametric models, 127, 130–131 Parkinson, C Northcote, 121 Parkinson effect, 121 Parkinson’s Law, 121 PC (percent complete), 304, 307 Penker, Marcus, 46, 98 percent complete (PC), 304, 307 performance CPI, 304, 308–310 performance budget, 216–217 and user satisfaction, 290 performing stage (team formation), 38, 40–41 personal attacks, 39 person months, 116 Pert estimation, 123, 127, 128–129, 131 phase exit criterion, 166 phases, 81, 86–89 See also construction phase; elaboration phase; inception phase; transition phase phase exit criterion, 166 when to use UML, 47 planned cost, 305 See also BCWS planning object-oriented projects See SDP PMI (Project Management Institute) Web site, 84 Polya, George, 86 problem solving, 84–89 activities, 85–86, 87 designing, 85 implementing, 86 scoping, 85 verifying, 86 collaborative problem solving, 20–21 defining the problem, 113–115 80–20 rule, 88 how people solve problems, 87 and incremental builds, 103–104 phase-activity relationship problem report process, 286, 288–289 problem-solving paradigm, 85 problem-solving phases, 86–89 construction See construction phase elaboration See elaboration phase inception See inception phase transition See transition phase process artifacts, 133 See also artifacts product development, 81 See also lifecycle model product instability and design tools, 137 productivity, 118 measuring by lines of code, 119 product lifecycle model See lifecycle model product team communications model, 34–37 product teams, 153, 155 communications model, 34–37 examples of product teams, 157–158 IPTs, 34, 36, 85 programming teams See team program organization, 152–155 chart, 154 program roles, 155, 156 program time-phased budget, 110 projected costs, 304 Project Management, 141, 305 Project Management Institute (PMI) Web site, 84 project size See estimating project’s size/effort Q QFD (Quality Functional Deployment) movement, 34 Quality Functional Deployment (QFD) movement, 34 R RAD (rapid application development) lifecycle model, 96–98 project management, 97 recommendation, 97–98 rapid application development lifecycle model See RAD reconfigurable cockpit simulator See Stealth Simulator reference help, 265 regression test, 294 release, 89 reliability, 289–290, 291 report See monthly status report requirements, analysis, 115 and change control, 273–276 must-fix test, 290 documenting requirements, 48–57 package requirements, 54–56 use-case diagrams, 51–53 use cases, 48–51 dynamic requirements, inadequate requirements, 5, 7–8 static requirements, and traceability, 79 unstable requirements, 5, requirements review meeting, 191–192 resetting baseline, 239–243 resource leveling, 151 resources and SDP, 109 reverse engineering, 253, 254 reviews artifacts, 223–224, 265–266 code reviews, 256–257 internal design reviews, 226–228 monthly review format, 303, 312–319 operational test readiness review, 280–281 requirements review meeting, 191–192 review of action items, 319 system design review meeting, 230–232 risk and design tools, 136–137 management, 268–269 planning, 110, 138 risk assessment and status, 315–316 risk identification/mitigation table, 139 Roetzheim, William, 122 ROM (rough order of magnitude), 117 rough order of magnitude (ROM), 117 S scaffolding programs, 220–222 scenario, 49–50 schedules, 109, 146–151 design tools and risk, 136–137 Gantt charts, 147–149 and incremental builds, 103 macroschedule, 146–147, 149 master schedule, 146, 149–151 critical functionality, 151 resource leveling, 151 technical uncertainty, 149, 151 visible content, 149 microschedules, 146, 147 construction phase, 269–273 elaboration phase, 227–228 inception phase, 187–188 transition phase, 295–296 risk identification/mitigation table, 139 schedule planning, 149, 151 schedule variance (SV), 304, 306–309 schedule variance index (SVI), 304, 307, 309 scoping, 85 relationship to phases, 87 scoping the project, 166 and the SDP, 113 SDP (Software Development Plan), 109–162 choose a lifecycle model, 109, 138–139 define the problem, 113–115 deliverables, 109, 133–134 designing the SDP, 132–162 development environment, 134–138 developing the SDP, 111–132 estimating project’s size/effort, 116–121 estimation methods, 122 package-level analogy, 122–123, 125–126 parametric models, 127, 130–131 Pert estimation, 123, 127, 128–129, 131 practical advice, 131–132 system analogy, 122 importance of SDPs, 110 metrics plan, 162 overview, 109–111 required resources, 109, 116–132, 138 requirements analysis, 115 risk planning, 110, 138 schedule, 109, 146–151 Gantt charts, 147–149 schedule planning, 149–151 scoping the plan, 113 size/effort estimates, 116–132, 138 staffing/organization, 109, 151–159 product teams, 155, 157–158 program organization, 152–155 program roles, 155, 156 time-phased budget, 110, 160–162 top-level package diagram, 116 work breakdown structure, 109, 139–145 SEI (Software Engineering Institute), 110 sequence diagrams, 71–73, 79 elaboration phase, 217 UML artifact, 47 services, 133–134 shadow system, 284 Showstopper, 34 Siegel, Stanley, 185 Simone, Susan S., 58, 213, 214 size See estimating project’s size/effort software See software design; software projects development See also lifecycle model; SDP collaborative approach, 21–22 as problem solving, 20–21, 84–89 top down approach, 21 software design, 57–73 attributes of a good design, 73–74 class and package diagrams, 70–71 class packages, 64–70 class relationships, 60–64 components and subsystems, 75–77 object’s methods, 59 object’s properties, 58 sequence diagrams, 71–72 signs of a poor design, 74–75 traceability, 79 what it consists of, 57 Software Development Plan See SDP Software Engineering Economics, 90, 95 Software Engineering Institute (SEI), 110 Software Project Cost & Schedule Estimating Best Practice, 122 software projects collaboration, 19–22 create a project glossary, 27 enemies of software projects, 5–14 inadequate customer communications, 9–11 inadequate requirements, 5, 7–8 ineffective team behavior, 13–14 poor team communications, 11–12 unnecessary complexity, 12–13 unstable requirements, 5, getting help from object technology, 14–19 team functions, list of, 28 SOMATIK process, 97 spaghetti code, spiral lifecycle model, 93–95 phases, 93 project management, 95 recommendation, 95 terminology, 98 staffing/organization, 109, 151–159 product teams, 155, 157–158 program organization, 152–155 program roles, 155, 156 standard modeling language, 27 See also UML state of an object, 58–59 state of a software system, 16–17 description, 16 state space, 16 state transitions, 16–18 and code paths, 16 description, 16 static descriptions and design, 15 static descriptions of requirements, 14 status report See monthly status report Stealth Simulator, 6–8 abstract view of, 24–25 architecture, 68–69 the assignment, 6–8 budget, 160, 161, 162 budget tracking, 312 communication issues, 36 complexity, 19 construction phase completing the phase, 282 entering the phase, 238 interface development, 258 planning transition, 266 resetting baseline, 242, 243 team conflict, 247 customer acceptance, 298 development lifecycle model, 107 delivery date, elaboration phase activity coordination, 230–231 class design, 216 completing the phase, 234 entering the phase, 198–200 system design review meeting, 233 team issues, 204–206 test planning, 223 use-case elaboration, 212 inception phase completing the phase, 194 entering the phase, 168–169 prototype user interface, 177 requirements review meeting, 193 use-case analysis, 175 managing the complexity, 19 master schedule, 150–151 package-level estimate, 124–126 Pert estimation, 128–129 planning the simulator, 111 prototype user interface, 177 requirements for, 10 requirements review meeting, 193 risks, 140 staffing, 158–159 subsystem teams, 159 team makeup, 41 top-level class diagram, 67, 68 transition phase customer acceptance of simulator, 298 use cases, 50, 51 creating a training scenario, 52–53 elaboration, 212 package-level use cases, 56 use-case analysis, 175 use-case diagram, 53 variance report, 309 WBS, 145 storming stage (team formation), 37, 39–40 subsystems, 75–77 integration test plan, 219–222 incremental, 259–262 subsystem tests, 77, 103, 252 success, principles for, 320 Sun Tzu, Surviving Object-Oriented Projects, A Manager’s Guide, 115 SV (schedule variance), 304, 306–309 Svedlow, Martin, 214 SVI (schedule variance index), 304, 307, 309 system a hierarchy of abstractions, 23 shadow system, 284 system analogy, 122 system design document, 218 system design review meeting, 230–232 agenda example, 232 system test, 77, 103, 178–183, 252 and multiple paths, 183 required resources, 182 requirements, 179–181 test list, 181 traceability matrix, 182–183 examples, 184, 185 T team See also team, during phases collaboration, 19–20 communications, 28 functional communications, 28–32 modularity and encapsulation, 155 poor communications, 11–12 product team model, 34–37 recommendation, 36–37 too little (functional), 31 too much (unstructured), 32–34 vocabulary/language, 26–27 dividing the effort, 69–70 the experts, 293 forming stage, 37, 38–39, 167–168 functional communications model, 28–32 ineffective behavior, 13–14 leadership construction phase, 239, 244–246 elaboration phase, 196, 201–204 molding individuals, 114 transition phase, 285 list of functions, 28 norming stage, 38, 40 performing stage, 38, 40–41 positive effect of interim integrations, 252 problem solving, 84–89 productivity and complexity, 18–19 product teams, 153, 155 communications model, 34–37 examples of product teams, 157–158 IPTs, 34, 36, 85 program organization, 152–155 program roles, 155, 156 setting ground rules, 39 storming stage, 37, 39–40 subsystem teams, 153 team dynamics, 37–42 Tiger Team, 293 us-against-them attitude, 41 team, during phases construction phase, 244 leadership, 239, 244–246 team meetings, 277–280 elaboration phase, 201 leadership, 196, 201–204 program meetings, 228–229 system design review meeting, 230–232 inception phase, 167–169 requirements review meeting, 191–192 team meetings, 188 transition phase leadership, 285 program meetings, 296 Tiger Team, 293 technical uncertainty, 149, 151 Tepfenhart, William, 58, 62, 64 test fixtures, 220 testing multilevel testing, 75 operational test readiness review, 280–281 regression test, 294 scaffolding programs, 220–222 subsystem tests, 77, 103, 252 incremental, 259–262 integration test plan, 219–222 system test, 77, 103, 178–183, 252 and multiple paths, 183 unit test, 77, 102–103 construction phase, 252, 253, 254, 255 elaboration phase, 219, 222 Texel, Putnam, 56 Tiger Team, 293 time box model See RAD time loss and design tools, 137 time-phased budget, 110, 160–162, 305 tools See also design tools; UML assigning responsibility, 184 program development tools, 186 top-down class design, 213, 215–216 top-level architecture, 66–70 top-level class diagrams, 177–178 top-level package diagram, 66–70, 116 Total Quality Development, 31, 84 traceability, 79 traceability matrix, 182–183, 222 examples, 184, 185 tracking and oversight, 303–319 budget tracking, 303, 304–310 development metrics, 303, 310–312 monthly review format, 303, 312–319 transition phase, 86, 99, 283–299 and activities, 87 addressing defects, 289–293 build meetings, 295–296 code changes, 293–294 coordination of activities, 295–296 customer communication, 296–297 development activities, 285–294 formal acceptance, 285 goal of, 283 leadership issues, 285 maintain focus and momentum, 320 management overview, 284–285 overview, 89 phase exit criteria, 297, 299 problem report process, 286–289 process tasks, 294–295 program meetings, 296 transition preparations, 276–277 Tuckmann, B., 37 Turing, Alan, 16 U UML (Unified Modeling Language), 43 artifacts, 47–48 attributes of a good design, 73–74 class and package diagrams, 47, 70–71 class packages, 64–70 class relationships, 60–64 components and subsystems, 75–77 component diagrams, 47, 76 design tools and UML support, 135 documenting requirements, 48–57 package requirements, 54–56 documenting software design, 57–73 class and package diagrams, 70–71 class packages, 64–70 class relationships, 60–64 evaluating a design, 73–75 overview, 46–48 primary focus, 47 sequence diagrams, 47, 71–72 signs of a bad design, 74 standard modeling language, 27 traceability, 79 use cases, 48–51 developer level, 54–55 package level, 55–57 user level, 54 use-case diagrams, 47, 51–53 UML and C++ A Practical Guide to Object-Oriented Development, 58, 62 UML Primer, 46 The UML Toolkit, 46 Unified Modeling Language See UML unit level of detail, 213 unit test, 77, 102–103 construction phase, 252, 253, 254, 255 elaboration phase, 219, 222 unstructured communications, 32–34 us-against-them attitude, 41 use cases, 48–51 actors, 51–53 developer-level use cases, 49, 54–55 development-level use cases, 207–209 elaboration, 207–211 examples draw a line-developer level, 54–55 draw a line-user level, 49 draw a line with endtypes, 50 extend a use case, 50, 52 overview, 8, 48–50 package-level use cases, 55–57, 207–210 role of use case in system development, 57 scenario, 49–50 and traceability, 79 use a use case, 50, 52 use-case database, 171–173 development, 209–210 package-level, 209–210 use-case diagrams, 47, 51–53 inception phase, 173–174 user-level use cases, 49, 54 use-case diagrams, 47, 51–53 developer level, 47 elements of, 52 user level, 47 at inception phase, 173–174 Use Cases Combined with Booch/Omt/Uml: Process and Products, 56 user interface development, 259 prototyped user interface, 175–177 user satisfaction, 289–290 See also customer accuracy, 289 performance, 290 reliability, 289–290 uses, 52 Using CRC Cards: An Informal Approach to Object-Oriented Development, 214 V VAC (variance at complete), 304, 305, 309–310 variance at complete See VAC variances, 304, 307–310 verifying, 86 relationship to phases, 87 vertical and horizontal development, 257–259 visible content, 149 Vlissides, John, 70, 216 vocabulary, 26–27 W waterfall lifecycle model, 90–93 incremental builds, 104, 106 phases, 90 project management, 91–93 recommendation, 93 WBS (work breakdown structure), 109, 139–145 and the budget, 160–161 and Gantt charts, 147 hierarchies, 141, 142, 143 and packages, 116 Westland, Chris, 131 Wilkinson, Nancy, 214 Williams, Charles B., 56 Winston, Morton, 64 Witten, Neal, 204, 274 work breakdown structure See WBS Y Yourdon, Ed, 43 Z Zachery, Pascal, 34 Table of Contents Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc All rights reserved Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited Read EarthWeb's privacy statement ... Language (UML) and its use in software development in Chapter Chapter also provides an overview of object- oriented design and the UML for the project manager Anyone familiar with the UML can skim... conversations with my colleagues, staff, and students, this text describes the effective management of software development projects using object- oriented methodology I describe not only what the project. .. Previous Table of Contents Next - Part One Principles for Object- Oriented Program Management Chapter Object- Oriented Development as a Management Tool If you know the enemy and know yourself, you