Surviving Object-Oriented Projects: A Managers Guide (Addison-Wesley Object Technology Series)by Alistair Cockburn
Pub. Date: 12/08/1997
Today, many organizations claim competitive market advantages resulting from the application of object-oriented technology and approaches in their software development efforts. As the use of object technology has become increasingly widespread and mainstream, a growing number of project managers are faced with a daunting task: keeping the object technology… See more details below
Today, many organizations claim competitive market advantages resulting from the application of object-oriented technology and approaches in their software development efforts. As the use of object technology has become increasingly widespread and mainstream, a growing number of project managers are faced with a daunting task: keeping the object technology project on track and within budget. These project managers are burdened by the weight of knowing that the survival and ultimate success of the project hinges on their insight when planning the project and their responses to events that lie ahead. Unfortunately, hidden costs, unpleasant surprises and unrealistic expectations lie in wait for the unprepared manager.
Although much has been written about object technology and the benefits of this paradigm, there is still a shortage of compiled knowledge about what to expect and to plan for during project implementation. This book provides information that managers need to combat the unforeseen challenges that await them, allowing them to survive and ultimately succeed with an object-oriented project.
To provide practical advice and guidelines for successfully managing an object-oriented project, the author borrows from the seasoned wisdom of numerous experts and successful consultants while also drawing on his personal experience and extensive knowledge. Surviving Object-Oriented Projects: A Manageris Guide points out potential hazards and names workable solutions by addressing the important issues of scheduling, budgeting, staffing, and cost justification. Key points are supported and illustrated through short case studies taken from real object-oriented projects, and an appendix collects these workable guidelines and solutions into brief icrib sheetsio ideal for handy reference.
Table of Contents
1. Success and Failure.
Incremental and Iterative Development.
2. Project Expectations.
Alfred: Success with Changing Requirements.
@AHEADS = Brooklyn Union Gas: Success Through Attentiveness.
Ingrid: Success in Migrating to C++.
Manfred: Failure in Prototyping.
Mentor Graphics: Trouble Migrating to C++.
Object Technology International: Success in Productivity and Speed.
Reginald: Failure with Changing Rules.
Stanley: Too Much Cutting Edge.
Tracy: Failure Through Naivete.
Udall: Success by Restarting Smaller.
Winifred: Inattentive but Persistent.
Possible Benefits of Object Technology.
Responsiveness to Variations on a Theme.
Responsiveness to Change.
Communication Between Developers, Users, and Executives.
Window-Based User Interfaces.
Automated Code Generation.
OO Design, Encapsulation, and System Evolution (Tom Morgan).
Are You Underestimating.
Time to Get New Developers Productive.
Immaturity of the OO Industry.
Hazards of C++.
The Difficulty of Reuse.
Establishing a Software Process.
Business Modeling versus Software Design.
The Cost of CASE Modeling Tools.
Nonobject Issues Checklists.
3. Selecting and Setting Up an OO Project.
Variations on a Theme.
Simplified Program Structure.
Memory Management Features.
What Is Not Suited.
Other Project Categories.
The Selection Process.
One Person is Persuasive or Stubborn.
The Team Knows a Similar Technology.
The Technology is Safe, Popular, or Standard.
The Technology is the Rational Choice.
Disciplined Use of C++ (Jeremy Raw).
Managing OO COBOL.
Using Java (Sam Griffith).
The Scanner Challenge.
Minimum CASE Tool Requirements.
The Cutting Edge.
Training and Getting Advice.
What to Teach.
Developers Do Not Know How to Think in Objects.
Developers Do Not Know How to Make Design Trade-Offs.
Developers Program Poorly or Use Tools Badly.
Different Programmers Write Differently, Making The Code Hard to Learn.
Developers Create Redundant Classes Because They Do Not Know What Is in the Class Library.
No One Knows How to Document a Framework Well.
Developers Do Not Understand Their Role On The Project And Who Depends on Them.
When to Teach.
Project Setup (C.D.).
4. Getting Started.
A Base Methodology to Tailor.
Discussion of the Methodology.
Roles, Skills, Techniques.
Building Consumer Understanding of the Design (Ward Cunningham).
Two Weeks per Noncommercial Class.
An Estimation and Planning Session (Alistair Cockburn).
Take the Time to Design.
Design, and Two Smalltalk Projects (K.L.).
5. Making Corrections.
A Study Project.
Stage 0: The Usual Ignorance.
Stage 1: Disaster.
Stage 2: Rebuild.
Stage 3: Improve.
Stage 4: Functioning.
Stage 5: Overconfidence in Scaling Up.
Lessons From This Study Project.
Managing Precision, Accuracy, and Scale.
Managing Work According to Precision and Accuracy.
Increments and Iterations.
Increments and V-W Staging.
Combining Increments and Iterations.
Burn Some Pancakes (Luke Hohmann).
The Architecture Team.
The Training Team.
Pause and Learn.
Watching Users (K.L.).
Involve the Users (Jon Marshall).
Domain Modeling and Reuse.
The Domain Model.
The Common Domain Model.
Why Are There Multiple Valid Domain Models.
Conflicting Reward Systems.
Lack of Trust.
I Can Write It Faster Myself.
6. Advice From Hindsight.
Costs and Benefits Revisited.
Sentences You Hope Never to Hear.
Writing 500 Lines of Code per Day.
Model the World, Then Code.
Design the Screen, Then Code.
Reuse is Easy.
More on Iterations.
Two Increments Delivered.
Analysts, Programmers, and Tools.
Learning OO From the Compiler.
Programmers Between Projects.
On the Cutting Edge.
Designers and Programmers Separated.
Six-Month Pilot Started.
7. Expand to Larger Projects.
Your First Big Project.
Staffing, Skill Dilution, and Project Teams.
Increments and Iterations.
The Cutting Edge.
Training the Tidal Wave.
Ten Lessons the Hard Way (Glenn House).
Train Fewer People.
Train More Effectively.
Training 50 or More People.
Set up a Full-Time Classroom Program.
Set up 6 to 10 Connected Projects.
Use a Full-Time Mentor.
Maintain Tight Standards and Review Policies.
Staff Skill Mix.
Progress Team/Training Team.
Productivity Changes Over Time.
Lines of Code Per Month.
Migrating the organization.
8. Rechecking a Case Study.
Stage 1: Good Start, with Experience and Support.
Stage 2: No Architecture, Almost No First Delivery.
Stage 3: New Increment; Add Teams, Mentors, Architecture.
Stage 4: Owner per Deliverable; New Infrastructure.
Relation to Book's Topics.
Technology Is Only Part of the Story.
Organizations (Jim Coplien).
Appendix A. Collected Risk-Reduction Strategies.
Appendix B. Crib Sheet.
Index 000 0201498340T04062001
and post it to your social network
Most Helpful Customer Reviews
See all customer reviews >