(How to Program) Paul Deitel, Harvey Deitel-Java How to Program, Early Object...
Software project management
1. Software Pr j t
S ft r Project
Manage ent
Management
R. Akerkar
TMRF, K lh
TMRF Kolhapur, India
I di
R. Akerkar - SPM 1
2. Introduction
Many software projects fail:
due to faulty project
management practices:
It is important to learn different
aspects of software project
management.
management
R. Akerkar - SPM 2
3. Introduction
Goal
of software project
management:
g
enable a group of engineers to work
efficiently towards successful
completion of a software project.
R. Akerkar - SPM 3
4. Responsibility of project managers
Project proposal writing
writing,
Project cost estimation,
Scheduling,
g,
Project staffing,
Project monitoring and control,
Software configuration management,
Risk management,
Managerial report writing and presentations, etc.
M i l t iti d t ti t
R. Akerkar - SPM 4
5. Introduction
A project manager’s activities
manager s
are varied.
can be broadly classified into:
project planning
planning,
project monitoring and control
activities.
R. Akerkar - SPM 5
6. Project Planning
j g
Once a project is found to be
feasible,
project managers undertake project
p
planning.
g
R. Akerkar - SPM 6
7. Project Planning Activities
j g
Estimation:
Effort, cost, resource, and project duration
Project scheduling:
j g
Staff organization:
staffing plans
Risk handling:
Ri k h dli
identification, analysis, and abatement procedures
Miscellaneous plans:
quality assurance plan, configuration management
plan, etc.
R. Akerkar - SPM 7
8. Project p
j planning
g
Requires utmost care and attention ---
commitments to unrealistic time and resource
estimates result in:
irritating delays.
cus o e dissatisfaction
customer d ssa s ac o
adverse affect on team morale
poor quality work
project failure.
R. Akerkar - SPM 8
9. Sliding Window Planning
g g
Involves project planning over
several stages:
protects managers from making big
commitments too early. y
More information becomes available
as project progresses
progresses.
Facilitates accurate planning
R. Akerkar - SPM 9
10. SPMP Document
After planning is complete:
Document the plans:
p
in a Software Project
Management Plan(SPMP)
document.
R. Akerkar - SPM 10
11. Organization of SPMP Document
g
Introduction (Objectives Major Functions,Performance Issues,Management and
(Objectives,Major Functions Performance Issues Management
Technical Constraints)
Project Estimates (Historical Data,Estimation Techniques,Effort, Cost, and Project
Duration Estimates)
)
Project Resources Plan (People,Hardware and Software,Special
Resources)
Schedules (Work Breakdown Structure,Task Network, Gantt Chart Representation,PERT
Chart Representation)
Risk Management Plan (Risk Analysis,Risk Identification,Risk Estimation,
Abatement Procedures)
Project Tracking and Control Plan
Miscellaneous Plans(Process Tailoring Quality Assurance)
Tailoring,Quality
R. Akerkar - SPM 11
12. Software Cost Estimation
Determine size of the product
product.
From the size estimate,
determine the effort needed
needed.
From the effort estimate,
determine project duration, and cost.
R. Akerkar - SPM 12
14. Organization Structure
g
Functional Organization:
Engineers are organized into functional
groups, e.g.
groups e g
specification, design, coding, testing,
maintenance, etc.
maintenance etc
Engineers from functional groups get
assigned to different projects
R. Akerkar - SPM 14
15. Advantages of Functional
Organization
Specialization
Ease of staffing
Good documentation is produced
d e e t phases are carried
different p ases a e ca ed out by d e e t
different
teams of engineers.
Helps identify errors earlier
earlier.
R. Akerkar - SPM 15
16. Project Organization
j g
Engineers get assigned to a project for
the entire duration of the project
Same set of engineers carry out all the
phases
Advantages:
Engineers save time on learning details of
every project
project.
Leads to job rotation
R. Akerkar - SPM 16
17. Team Structure
Problems of different complexities
and sizes require different team
structures:
Chief programmer
Chief-programmer team
Democratic team
Mi
Mixed organization
d i ti
R. Akerkar - SPM 17
18. Democratic Teams
Suitable for:
small projects requiring less than five or six
engineers
i
research-oriented projects
A manager provides administrative
p
leadership:
at different times different members of the
g p provide technical leadership.
group p p
R. Akerkar - SPM 18
19. Democratic Teams
Democratic organization provides
higher morale and job satisfaction to the engineers
therefore leads to less employee turnover
turnover.
Suitable for less understood problems,
a group of engineers can invent better solutions
than a single individual.
R. Akerkar - SPM 19
20. Democratic Teams
Di
Disadvantage:
d t
team members may waste a lot
time arguing about trivial points:
absence of any authority i th
b f th it in the
team.
R. Akerkar - SPM 20
21. Chief Programmer Team
g
A senior engineer provides
technical leadership:
partitions the task among the team
members.
verifies and integrates the products
developed by the members.
R. Akerkar - SPM 21
22. Chief Programmer Team
g
Works well when
the task is well understood
also within the intellectual grasp of a single
individual,
importance of early completion outweighs
other factors
team morale, personal development, etc.
R. Akerkar - SPM 22
23. Chief Programmer Team
g
Chief programmer team is subject to
single point failure:
too
t much responsibility and authority is
h ibilit d th it i
assigned to the chief programmer.
R. Akerkar - SPM 23
24. Team Organization
g
Democratic Team
Chief Programmer team
R. Akerkar - SPM 24
26. Staffing
Project Managers usually
take responsibility for
choosing their team:
h i th i t
need to identify and select
y
good software engineers for
the success of the project
project.
R. Akerkar - SPM 26
27. Staffing
A common misconception:
p
one software engineer is as productive as
another:
Experiments reveal:
E i t l
a large variation in productivity between
the worst and best in a scale of 1 to 10.
10
Worst engineers even help reduce the
overall productivity of the team
in effect exhibit negative productivity.
R. Akerkar - SPM 27
28. Who is a Good Software Engineer?
Good programming abilities
Good knowledge of the project areas (Domain)
G dk l d f h j (D i )
Exposure to Systematic Techniques
Fundamental Knowledge of Computer Science
Ability to work in a team
Intelligence
Good communication skills:
Oral
Written
Interpersonal
High Motivation
R. Akerkar - SPM 28
29. Who is a Good Software Engineer? (cont.)
Studies show:
these attributes vary as much as
1:30 for poor and bright candidates.
Technical knowledge in the area of the
project (domain knowledge) is an
important factor, determines:
productivity of an individual
quality of the product he develops.
R. Akerkar - SPM 29
30. Who is a Good Software Engineer? (cont.)
A programmer having thorough
knowledge of database
applications (e.g MIS):
(e g
may turn out to be a poor data
communication engineer
engineer.
R. Akerkar - SPM 30
31. Scheduling
Scheduling is an important activity for the
g y
project managers.
To determine project schedule:
Identify tasks needed to complete the project.
Determine the dependency among different tasks.
Determine the most likely estimates for the duration
of the identified tasks.
Plan the starting and ending dates for various
tasks.
t k
R. Akerkar - SPM 31
32. Work Breakdown Structure
Work Breakdown Structure (WBS) provides a notation
for
f representing task structure:
i k
Activities are represented as nodes of a tree.
The root of the tree is labelled by the problem name.
Each task is broken down into smaller tasks and
represented as children nodes.
It is not useful to subdivide tasks into units which take
less than a week or two to execute.
Finer subdivisions mean that a large amount of time
must be spent on estimating and chart revision.
R. Akerkar - SPM 32
33. Work Breakdown Structure
Compiler Project
p j
Requirements Design Code Test Write Manual
Lexer Parser Code Generator
R. Akerkar - SPM 33
34. Activity Networks
WBS structure can be refined into an
activity network representation:
Network of boxes and arrows
shows different tasks making up a project,
h diff tt k ki j t
represents the ordering among the tasks.
It is important to realize that developing
WBS and activity network
requires a thorough understanding of the
tasks involved.
R. Akerkar - SPM 34
35. Activity Network
Code Lexer
Design Code Parser
Requirements Code Code Generator Test
Write Manual
R. Akerkar - SPM 35
36. Risk Management
A risk is any unfavourable event or
circumstance:
which might hamper successful or timely
completion of a project.
p p j
Risk management:
concerned with the reduction of the impact of risks.
Risk management consists of three activities:
risk identification,
risk assessment, and
risk containment.
i k t i t
R. Akerkar - SPM 36
37. Risk identification
To be able to identify various risks:
y
we must categorize risks into different
classes.
Three main categories of risks can
affect a software project:
project risks
technical risks
business risks
R. Akerkar - SPM 37
38. Project Risks
j
Project risks associated with:
budget,
schedule,
personnel,
p ,
resource, and
customer problems.
t bl
R. Akerkar - SPM 38
39. Technical Risks
Technical risks concern:
requirements specification
(e.g ambiguous, incomplete, changing specifications)
design problems,
problems
implementation problems,
interfacing problems,
gp ,
testing, and maintenance problems.
technical uncertainty, and technical obsolescence
are technical risk factors too
too.
R. Akerkar - SPM 39
40. Business Risks
Business Risks include:
building an excellent product that no one wants,
losing budgetary or personnel commitments, etc.
It i
I is a good idea to have a “
d id h “company di
disaster
list”,
a list of all bad things that have happened in the
past
project managers can jog their mind to see which
items th i project is vulnerable to.
it their j ti l bl t
R. Akerkar - SPM 40
41. Risk assessment
Objective of risk assessment is to
j
prioritize the risks:
Likelihood of a risk being real.
C
Consequence of th problems associated
f the bl i t d
with that risk.
Prioritization helps in handling the most
damaging risks first.
Priority of a risk is the product of the likelihood of
the risk and the consequences of the problems
associated with that risk.
R. Akerkar - SPM 41
42. Risk Handling
g
Three main strategies for risk handling:
Avoid the risk: e.g. change the requirements for
performance or functionality.
Transfer the risk: allocate risks to third party
or buy insurance to cover any financial loss should
the risk become a reality.
Contingency planning: Prepare contingency pans
to minimize the impact of the risk.
R. Akerkar - SPM 42