Surviving Object-Oriented Projects
Addison Wesley (Verlag)
978-0-201-49834-9 (ISBN)
- Titel ist leider vergriffen;
keine Neuauflage - Artikel merken
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. 0201498340B06012001
Alistair Cockburn is a recognized expert on use cases. He is consulting fellow at Humans and Technology, where he is responsible for helping clients succeed with object-oriented projects. He has more than twenty years of experience leading projects in hardware and software development in insurance, retail, and e-commerce companies and in large organizations such as the Central Bank of Norway and IBM. 0201498340AB07302002
Preface.
Acknowledgements.
1. Success and Failure.
Basic Concepts.
Object Technology.
Class.
Object.
Inheritance.
Encapsulation.
Polymorphism.
Framework.
Incremental and Iterative Development.
2. Project Expectations.
Project Histories.
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.
Time-to-Market.
Communication Between Developers, Users, and Executives.
Maintainability.
Reuse.
Productivity.
Window-Based User Interfaces.
Morale.
Automated Code Generation.
Software Process.
OO Design, Encapsulation, and System Evolution (Tom Morgan).
Costs.
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.
Probable Costs.
Nonobject Issues Checklists.
3. Selecting and Setting Up an OO Project.
Project Suitability.
Variations on a Theme.
Simplified Program Structure.
Memory Management Features.
What Is Not Suited.
Project Purpose.
SWAT.
Investigative.
Production.
Full-Commit.
Other Project Categories.
People.
Executive Sponsor.
Project Manager.
Technical Lead.
Technical Staff.
Users.
Personality Types.
Technology.
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.
Programming Languages.
Managing Smalltalk.
Managing C++.
Disciplined Use of C++ (Jeremy Raw).
Managing OO COBOL.
Managing Java.
Tools.
Upper-CASE Tools.
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.
Getting Advice.
Legacy Issues.
Mainframes.
Relational Databases.
Project Setup (C.D.).
Review.
4. Getting Started.
Methodology.
Big-M Methodology.
A Base Methodology to Tailor.
Discussion of the Methodology.
Roles, Skills, Techniques.
Tools.
Teams.
Ownership.
Deliverables.
Standards.
Activities.
Building Consumer Understanding of the Design (Ward Cunningham).
Estimates.
Two Weeks per Noncommercial Class.
Domain Classes.
Screen Classes.
Utility Classes.
Frameworks.
Plans.
An Estimation and Planning Session (Alistair Cockburn).
Milestones.
Measurements.
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.
Iterations.
Combining Increments and Iterations.
Burn Some Pancakes (Luke Hohmann).
Project Increments.
Increment 1.
The Architecture Team.
The Training Team.
The Intentions.
Two Stories.
Increment 2.
Pause and Learn.
Move On.
Increment N.
User Involvement.
Watching Users (K.L.).
Project Teams.
Ownership.
Involve the Users (Jon Marshall).
Total-Ownership Teams.
Matrixed Teams.
Domain Modeling and Reuse.
The Domain Model.
Hazardous Situations.
The Common Domain Model.
Why Are There Multiple Valid Domain Models.
PolyBloodyHardReuse.
Conflicting Reward Systems.
Lack of Trust.
I Can Write It Faster Myself.
Further Reading.
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.
Iterate Prototypes.
Classes.
Reuse is Easy.
More on Iterations.
Self-Test.
Two Increments Delivered.
Thirty People.
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.
Project Charter.
Communication.
Staffing, Skill Dilution, and Project Teams.
Methodology.
Increments and Iterations.
The Cutting Edge.
Domain Modeling.
Risk Reduction.
PolyBloodyHarderReuse.
Class Duplication.
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.
Rotate People.
Productivity.
Size.
Staff Skill Mix.
Team Structure.
Even Mix.
Progress Team/Training Team.
Productivity Changes Over Time.
Lines of Code Per Month.
Frameworks.
Productivity Revisited.
Migrating the organization.
8. Rechecking a Case Study.
Winifred Revisited.
Summary.
History.
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.
Analysis.
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
| Erscheint lt. Verlag | 6.2.1998 |
|---|---|
| Verlagsort | Boston |
| Sprache | englisch |
| Maße | 100 x 100 mm |
| Gewicht | 100 g |
| Themenwelt | Informatik ► Software Entwicklung ► Objektorientierung |
| ISBN-10 | 0-201-49834-0 / 0201498340 |
| ISBN-13 | 978-0-201-49834-9 / 9780201498349 |
| Zustand | Neuware |
| Haben Sie eine Frage zum Produkt? |
aus dem Bereich
