Stumpf and Teague

Object-Oriented Systems Analysis and Design with UML

Chapter 14
Managing Object-Oriented
System Development

© 2005 Prentice Hall 14-1

 Learning Objectives

• Discuss some of the reasons

why information system development
projects fail.
• Describe the goals of project management.
• Name some of the risk factors associated
with users, the development team, and
the project itself.
• Explain why it is important to manage
users’ expectations for a project.
© 2005 Prentice Hall 14-2
 Learning Objectives
(continued)

• Discuss how risk, coverage, and

criticality can contribute toward
developing a project strategy.
• Read a Gantt chart and a critical path
model.
• Discuss how object-oriented software
benefits software development.
• Explain why the Unified Process
creates a detailed project plan for
the next iteration only.
© 2005 Prentice Hall 14-3
 Learning Objectives
(continued)

• Identify the disciplines in the Unified

Process which are related to project
management.
• Discuss issues related to preparing
estimates of project costs and
resources.
• Explain the use of prototyping in
object-oriented software development.
• Discuss some alternatives to custom
software development.
© 2005 Prentice Hall 14-4
 Overview
The history of software development is
full of examples of failed projects.
These failures are seldom due to lack of
technical competence. Instead, they
are related to poor management and
poor communication.
Project management seeks to identify
and mitigate risks, prepare project
plans and schedules, maintain
continuing communication, and
manage users’ expectations.
© 2005 Prentice Hall 14-5
 Overview
(continued)

A project plan and schedule are the basis

for managing a system development
project. The plan allocates tasks,
responsibilities, and resources to a
team of people.

Object-oriented technology and the

Unified Process facilitate effective
software development and a flexible,
adaptable development process.

© 2005 Prentice Hall 14-6

 Overview
(continued)

Project management requires quantitative

measurements of progress, ideally by
outsiders to the development team.

Best practices of software development

incorporate prototyping.

Not every system development project

requires custom software
development.

© 2005 Prentice Hall 14-7

 Why Software Development
Projects Fail

Projects fail because:

• Users fail to communicate requirements

completely and accurately.
• Users are not sufficiently committed
to the project.
• The project has no top management
champion.

© 2005 Prentice Hall 14-8

 Why Software Development
Projects Fail (continued)
• Project budget and schedules are
unrealistic.
• Risks are not adequately identified
and mitigated.

According to DeMarco, however, the

chief cause of failure is because:
• Users’ expectations are inflated and
unreasonable.
© 2005 Prentice Hall 14-9
Goals of Project Management

The primary goal of software project

management is a successful outcome
for the project. This means that the
project must:

• Meet users’ reasonable expectations.

• Be delivered on time.
• Be delivered within budget.

© 2005 Prentice Hall 14-10

Goals of Project Management
(continued)

Secondary goals include:

• Identify risks to the project and
avoid or mitigate them.
• Prepare project plans.
• Monitor project progress against
the plans.
• Earn and maintain users’ trust
through communication.
• Manage users’ expectations.
© 2005 Prentice Hall 14-11
 Risk Analysis

A risk is any uncertainty which has a

significant probability of preventing
the successful completion of a project
milestone.
Three major categories of risk are those
associated with:
 Users
 The development team
 The project
© 2005 Prentice Hall 14-12
Managing Users’ Expectations

Trust and credibility are key to managing

users’ expectations.
The Unified Process fosters credibility
by deferring firm commitments about
cost and delivery date until the end
of the Initiation and Elaboration
phases.
By then, the system requirements and
system architecture should be stable.
© 2005 Prentice Hall 14-13
 Project Strategy

Three important factors can be used to

organize a strategy for requirements
and iterations:
• Degree of risk – address high risk
areas early.
• Coverage – how much of the system
is included in an iteration?
• Criticality – functions with the greatest
value to the business should be
implemented early.
© 2005 Prentice Hall 14-14
 Project
Planning and Scheduling

A project plan includes:

• A breakdown of the necessary work
• The time dependencies among the
project tasks
• The assignment of personnel and
other resources to each of the tasks

© 2005 Prentice Hall 14-15

 Project
Planning and Scheduling (continued)

A project schedule is a set of project

artifacts or deliverables listed in the
sequence in which they are to be
produced.
The units of work in a project schedule
are tasks or activities.
Milestones are marked by the completion
of specified deliverables.

© 2005 Prentice Hall 14-16

 Network Planning Models

A critical path model or network shows

the sequential dependencies among
activities in a project.
It permits the calculation of:
• the earliest project completion date
and
• the activities which will delay the
project if not completed on time
(the critical path).
© 2005 Prentice Hall 14-17
 Network Planning Models
(continued)

.
FIGURE 14.1

© 2005 Prentice Hall 14-18

 Network Planning Models
(continued)

A Gantt chart presents a project

schedule as horizontal bars on a
vertical time grid.

It does not show dependencies among

the project activities.
It can help communicate the overall
features of a project schedule.

© 2005 Prentice Hall 14-19

 Network Planning Models
(continued)

.
FIGURE 14.2

© 2005 Prentice Hall 14-20

 Object Technology and
Project Management

Object-oriented software benefits

software development:
• Objects help attack complexity.
• Objects build systems resilient to
change.
• Objects allow partial systems to
work.
• Objects are natural units for re-use.
© 2005 Prentice Hall 14-21
 Project Planning
in the Unified Process

The Unified Process does not plan the

entire project in detail in advance.
• The high-level Phase Plan specifies the
major milestones and their deliverables
and estimates their completion dates.
• An Iteration Plan is a detailed plan for
the next iteration only.

© 2005 Prentice Hall 14-22

 Management-Related
Disciplines in the UP
Three core disciplines of the Unified
Process are related to project
management.
• Configuration and Change Management
manages the artifacts of the system.
• Project Management manages the
development process.
• Environment supports the process with
processes and tools.
© 2005 Prentice Hall 14-23
 Estimating, Measuring,
and Controlling

Project management requires

quantitative measurements of
progress.
Estimators are responsible for predicting
costs and for keeping project records
and measurements.
The project team is responsible for
the project plan and strategy. They
should maximize the function
delivered per dollar of lifetime cost.
© 2005 Prentice Hall 14-24
 Prototyping

A prototype is a partial or limited version

which simulates a proposed system.
• Analysis prototypes – clarify
requirements.
• Design prototypes – explore system
architecture or study system
performance.
• Vertical prototypes – implement
completely a portion of the system.
• Feasibility prototypes – study feasibility.
© 2005 Prentice Hall 14-25
 Prototyping Strategies

• Throwaway prototyping: The prototype

is discarded when the construction of
the system is complete.
These prototypes are not expected to
function in a production environment.
• Evolutionary prototyping: The prototype
evolves into the new system.
These prototypes must be constructed
with enough robustness for the
production environment.
© 2005 Prentice Hall 14-26
 Alternatives to Custom
Software Development

• Packaged software: For common

applications, if users are willing to
change their procedures to adapt to
the package
• Customizable software: Can tailor
some of the processes to users’ needs,
especially with complex systems. It can
be as expensive as custom software.

© 2005 Prentice Hall 14-27

 Summary

Failure to manage users’ expectations is

probably the most important reason for
failed software projects.
A project plan and schedule are the basis
for software project management.
Object-oriented technology can facilitate
flexible, adaptive practices in system
development, including prototyping.
Alternatives to custom development are
the use of packaged or customizable
software.
© 2005 Prentice Hall 14-28