Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e
copyright © 1996, 2001
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
This presentation, slides, or hardcopy may NOT be used for
short courses, industry seminars, or consulting purposes.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
1
Chapter 3
Project Management
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
2
Project Management
Involves planning, monitoring, and control of
the people, process, and events that occurs
as software evolves from a preliminary
concept to an operational implementation
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
3
Who does it?
Everyone…
(1) Software engineer manages day-to-day
activities, planning, monitoring, and
controlling technical tasks.
(2) Project managers plan, monitor, and
control the work of a team of software
engineers
(3) Senior managers coordinate the interface
between the business and the software
professionals
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
4
The 4 P’s
People — the most important element of a
successful project
Product — the software to be built
Process — the set of framework activities and
software engineering tasks to get the job
done
Project — all work required to make the
product a reality
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
5
Software Projects
Factors that influence the end result ...
• size
• delivery deadline
• budgets and costs
• application domain
• technology to be implemented
• system constraints
• user requirements
• available resources
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
6
Project Management Concerns
product quality?
risk assessment?
measurement?
cost estimation?
project scheduling?
customer communication?
staffing?
other resources?
project monitoring?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
7
Why Projects Fail?
• an unrealistic deadline is established
• changing customer requirements
• an honest underestimate of effort
• predictable and/or unpredictable risks
• technical difficulties
• miscommunication among project staff
• failure in project management
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
8
PEOPLE
The Players
1.
2.
3.
4.
5.
++
Senior manages
Project (technical) managers
Practitioners
Customers
End-Users
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
9
PEOPLE
MOI model of Leadership
Motivation
Organization
Ideas or Innovation
By Jerry Wienberg
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
10
PEOPLE
Characteristics that define an effective
project managers




++
Problem Solving
Managerial Identity
Achievement – eg. Reward initiatives
Influence and team building – ability to
“read” people
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
11
Software Teams
The following factors must be considered when selecting a
software project team structure ...
 the difficulty of the problem to be solved
 the size of the resultant program(s) in lines of code or
function points
 the time that the team will stay together (team lifetime)
 the degree to which the problem can be modularized
 the required quality and reliability of the system to be built
 the rigidity of the delivery date
 the degree of sociability (communication) required for the
project
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
12
Team Organizations
Democratic Decentralized (DD)
No permanent leader, decisions made by group
consensus, communication is horizontal
Controlled Decentralized (CD)
a defined leader, problem solving in group but
implementation in subgroup, communication is
horizontal and vertical
Controlled Centralized (CC)
a defined leader, problem solving by team leader,
communication vertical
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
13
Centralized vs Decentralized
 Centralized structure completes task faster  suitable
for small problems
 Decentralized teams generate better solution than
individuals  suitable for difficult problems
 Large projects are best addressed by teams with CC or
CD structures (subgrouping is easily accommodated)
 DD is good for long term project (DD results in high
morale)
 DD is best applied for low modularity problems (higher
volume of communication)
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
14
Centralized vs Decentralized
Findings:
Centralized produced fewer defects than DD
teams
Decentralized teams generally require more
time to complete
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
15
Organizational Paradigms
 closed paradigm—structures a team along a traditional
hierarchy of authority (similar to a CC team)
 random paradigm—structures a team loosely and depends
on individual initiative of the team members
 open paradigm—attempts to structure a team in a manner
that achieves some of the controls associated with the
closed paradigm but also much of the innovation that occurs
when using the random paradigm
 synchronous paradigm—relies on the natural
compartment-alization of a problem and organizes team
members to work on pieces of the problem with little active
communication among themselves
suggested by Constantine [CON93]
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
16
Potentially toxic team environment
A frenzied work atmosphere  waste energy
& lost focus
High frustration
Fragmented or poorly coordinated
procedures/process model
Unclear definition of roles
Continuous and repeated exposure to failure
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
17
Coordination & Communication
 Formal, impersonal approach
deliverables, milestones, schedules, tools, change requests,
error tracking reports, repository data
 Formal, interpersonal procedures
QA (review meeting, code inspections)
 Informal, interpersonal procedures
group meeting
 Electronic communication
email, bulletin board, video conference
 Interpersonal networking
informal discussion with team members or outside experts
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
18
PRODUCT
SOFTWARE SCOPE
Context
How it fit into the larger system, product or
business context
Information objective
What is output & input
Function and performance
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
19
PRODUCT
• Project scope must be unambiguous and
understandable
• Statement of scope must be bounded
• Quantitative data are stated explicitly (eg. Number of
simultaneous users, size of mailing lists, maximum
allowable response time)
• Constraint and/or limitation are noted (eg memory size)
• Mitigating factors are described (eg. Algorithm are well
understood and available)
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
20
PRODUCT
SOFTWARE DECOMPOSITION
The functionality
The process to deliver the software
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
21
Defining the Problem
establish scope—a narrative that bounds the
problem
decomposition—establishes functional
partitioning
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
22
PROCESS
Framework activities
Customer communication
Planning
Risk analysis
Engineering
Construction and release
Customer evaluation
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
23
Melding Problem and Process
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
24
PROJECT
Commonsense approach to software
project
1. Start on the right foot – understand the
problem, set realistic objectives
2. Maintain momentum – provide incentives,
emphasize on quality, minimum bureaucracy
3. Track progress
4. Make smart decisions – keep it simple
5. Conduct a postmortem analysis
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
25
To Get to the Essence of a Project
Why is the system being developed?
What will be done? By when?
Who is responsible for a function?
Where are they organizationally located?
How will the job be done technically and
managerially?
How much of each resource (e.g., people,
software, tools, database) will be needed?
Barry Boehm
W5HH Priciples
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
26
Critical Practices
Formal risk analysis
Empirical cost and schedule estimation
Metrics-based project management
Earned value tracking
Defect tracking against quality targets
People aware project management
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
27