18-06-2012, 12:50 PM
Object-Oriented Project Management with UML
[attachment=24686]
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.”
Object-Oriented Development as a
Management Tool
The days of bringing a bunch of hackers together to build a large system are
over. This method of organizing a project, although quick, results in chaos;
such development programs are often in a continual crisis and programmers
burn out quickly. For software organizations to thrive, they must be productive
over the long term. Today’s programming challenges call for large teams of
programmers to collaborate to develop large complex programs without
reeling from crises to crises.
Inadequate and Unstable Requirements
Software projects derive from a customer’s need. Someone must want you to
deliver something useful or that person would not be willing to pay for its
development. These needs are captured as requirements, or the specifics of
what the system must do. For example, despite the complexity of bridge
building, it is comparably easy to specify its requirements: a bridge needs to
connect point A to point B, withstand storms, and be able to carry a certain
volume of traffic. Barring any geological surprises, it is possible to completely
specify a bridge that fully meets requirements.
Poor Team Communications
A software system of any significant size requires a team of developers. It is
not unusual to have 10, 50, 100, or even 1,000 developers on a development
team. Each developer is responsible for a piece of code that must work in
conjunction with all of the code being generated by all of the other developers.
Clearly, communication among team members is imperative.
As the number of developers increases, each developer has that many more
people to synchronize. Accordingly, as pointed out in Fred Brooks’ The
Mythical Man-Month, the amount of communication among developers
increases almost quadratically with the size of the project.
Ineffective Team Behavior
Stereotypically, programmers do not normally form teams. They take pride in
their individual accomplishments and their ability to solve difficult problems,
and they are proud that they can bend the complicated computer platforms to
their individual will. They tend to view teams as a mechanism that stifles
creativity. Their heroes are not great team members or even team leaders but
the few individual programmers who are creative and prolific.
Neither are programmers trained to be team members. With a few exceptions,
computer science departments do not train their students to participate in the
development of large systems. It is frustrating for many young programmers
that as team members their communication, coordination, and
consensus-building skills may be more valued than their individual
programming skills. They generally equate meetings with not programming;
that is, with not working.
[attachment=24686]
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.”
Object-Oriented Development as a
Management Tool
The days of bringing a bunch of hackers together to build a large system are
over. This method of organizing a project, although quick, results in chaos;
such development programs are often in a continual crisis and programmers
burn out quickly. For software organizations to thrive, they must be productive
over the long term. Today’s programming challenges call for large teams of
programmers to collaborate to develop large complex programs without
reeling from crises to crises.
Inadequate and Unstable Requirements
Software projects derive from a customer’s need. Someone must want you to
deliver something useful or that person would not be willing to pay for its
development. These needs are captured as requirements, or the specifics of
what the system must do. For example, despite the complexity of bridge
building, it is comparably easy to specify its requirements: a bridge needs to
connect point A to point B, withstand storms, and be able to carry a certain
volume of traffic. Barring any geological surprises, it is possible to completely
specify a bridge that fully meets requirements.
Poor Team Communications
A software system of any significant size requires a team of developers. It is
not unusual to have 10, 50, 100, or even 1,000 developers on a development
team. Each developer is responsible for a piece of code that must work in
conjunction with all of the code being generated by all of the other developers.
Clearly, communication among team members is imperative.
As the number of developers increases, each developer has that many more
people to synchronize. Accordingly, as pointed out in Fred Brooks’ The
Mythical Man-Month, the amount of communication among developers
increases almost quadratically with the size of the project.
Ineffective Team Behavior
Stereotypically, programmers do not normally form teams. They take pride in
their individual accomplishments and their ability to solve difficult problems,
and they are proud that they can bend the complicated computer platforms to
their individual will. They tend to view teams as a mechanism that stifles
creativity. Their heroes are not great team members or even team leaders but
the few individual programmers who are creative and prolific.
Neither are programmers trained to be team members. With a few exceptions,
computer science departments do not train their students to participate in the
development of large systems. It is frustrating for many young programmers
that as team members their communication, coordination, and
consensus-building skills may be more valued than their individual
programming skills. They generally equate meetings with not programming;
that is, with not working.