Software

S ft r Project
Pr j t
Manage ent
Management

R. Akerkar
TMRF Kolhapur,
TMRF, K lh India
I di

R. Akerkar - SPM 1
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
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
Responsibility of project managers

 Project proposal writing

writing,
 Project cost estimation,
 Scheduling,
g,
 Project staffing,
 Project monitoring and control,
 Software configuration management,
 Risk management,
 M
Managerial
i l reportt writing
iti and
d presentations,
t ti etc.
t

R. Akerkar - SPM 4
Introduction
A project manager’s
manager s activities
are varied.
 can be broadly classified into:
 project planning
planning,
 project monitoring and control
activities.

R. Akerkar - SPM 5
Project
j Planning
g
 Once a project is found to be
feasible,
 project managers undertake project
p
planning.
g

R. Akerkar - SPM 6
Project
j Planningg Activities

 Estimation:
 Effort, cost, resource, and project duration
 Project
j scheduling:
g
 Staff organization:
 staffing plans
 Ri k handling:
Risk h dli
 identification, analysis, and abatement procedures
 Miscellaneous plans:
 quality assurance plan, configuration management
plan, etc.

R. Akerkar - SPM 7
Project
j p planningg
 Requires utmost care and attention ---
commitments to unrealistic time and resource
estimates result in:
 irritating delays.
 customer
cus o e d dissatisfaction
ssa s ac o
 adverse affect on team morale
 poor quality work
 project failure.

R. Akerkar - SPM 8
Slidingg Window Planningg

 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
SPMP Document
 After planning is complete:
 Document the plans:
p
 in a Software Project

Management Plan(SPMP)
document.

R. Akerkar - SPM 10
Organization
g of SPMP Document

 Introduction (Objectives,Major
(Objectives Major Functions,Performance
Functions Performance Issues,Management
Issues Management and
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
Tailoring,Quality
Quality Assurance)

R. Akerkar - SPM 11
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
Software Cost Estimation

Effort Cost
Estimation Estimation

Size Staffing
Estimation Estimation

Duration
Estimation Scheduling

R. Akerkar - SPM 13
Organization
g Structure
 Functional Organization:
 Engineers are organized into functional
groups e
groups, e.g.
g
 specification, design, coding, testing,
maintenance etc
maintenance, etc.
 Engineers from functional groups get
assigned to different projects

R. Akerkar - SPM 14
Advantages of Functional
Organization
 Specialization
 Ease of staffing
 Good documentation is produced
 d ee tp
different phases
ases a
are
e ca
carried
ed out by d
different
ee t
teams of engineers.
 Helps identify errors earlier
earlier.

R. Akerkar - SPM 15
Project
j Organization
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
Team Structure
 Problems of different complexities
and sizes require different team
structures:
 Chief programmer team
Chief-programmer
 Democratic team

 Mixed
Mi d organization
i ti

R. Akerkar - SPM 17
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
group
g p pprovide technical leadership.
p
R. Akerkar - SPM 18
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
Democratic Teams

 Disadvantage:
Di d t
 team members may waste a lot
time arguing about trivial points:
 absence
b off any authority
th it iin th
the
team.

R. Akerkar - SPM 20
Chief Programmer
g Team

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
Chief Programmer
g Team

 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
Chief Programmer
g Team

 Chief programmer team is subject to

single point failure:
 ttoo much
h responsibility
ibilit and
d authority
th it isi
assigned to the chief programmer.

R. Akerkar - SPM 23
Team Organization
g

Democratic Team
Chief Programmer team

R. Akerkar - SPM 24
Mixed team organization
g

R. Akerkar - SPM 25
Staffing
 Project Managers usually
take responsibility for
choosing
h i their
th i team:
t
 need to identify
y and select
good software engineers for
the success of the project
project.

R. Akerkar - SPM 26
Staffing
 A common misconception:
p
 one software engineer is as productive as
another:
 E
Experiments
i t reveal:
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
Who is a Good Software Engineer?

 Good programming abilities

 G d knowledge
Good k l d off theh project
j areas (Domain)
(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
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
Who is a Good Software Engineer? (cont.)

 A programmer having thorough

knowledge of database
applications (e.g
(e g MIS):
 may turn out to be a poor data
communication engineer
engineer.

R. Akerkar - SPM 30
Scheduling
 Scheduling
g is an important activity
y for the
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
t k
tasks.

R. Akerkar - SPM 31
Work Breakdown Structure
 Work Breakdown Structure (WBS) provides a notation
f representing
for i task k structure:
 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
Work Breakdown Structure

Compiler
p Project
j

Requirements Design Code Test Write Manual

Lexer Parser Code Generator

R. Akerkar - SPM 33
Activity Networks
 WBS structure can be refined into an
activity network representation:
 Network of boxes and arrows
 shows
h different
diff t tasks
t k making
ki up a project,
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
Activity Network

Code Lexer

Design Code Parser

Requirements Code Code Generator Test

Write Manual

R. Akerkar - SPM 35
Risk Management
 A risk is any unfavourable event or
circumstance:
 which might hamper successful or timely
p
completion of a project.
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
i k containment.
t i t

R. Akerkar - SPM 36
Risk identification

 To be able to identify
y various risks:
 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
Project
j Risks
 Project risks associated with:
 budget,
 schedule,

 personnel,
p ,
 resource, and

 customer
t problems.
bl

R. Akerkar - SPM 38
Technical Risks

 Technical risks concern:

 requirements specification
 (e.g ambiguous, incomplete, changing specifications)
 design problems,
problems
 implementation problems,
 interfacing
g problems,
p ,
 testing, and maintenance problems.
 technical uncertainty, and technical obsolescence
are technical risk factors too
too.

R. Akerkar - SPM 39
Business Risks

 Business Risks include:

 building an excellent product that no one wants,
 losing budgetary or personnel commitments, etc.
 IIt is
i a good
d idea
id to have
h a “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
it
items th
their
i project
j t is
i vulnerable
l bl to.
t

R. Akerkar - SPM 40
Risk assessment

 Objective
j of risk assessment is to
prioritize the risks:
 Likelihood of a risk being real.
 Consequence
C off th
the problems
bl associated
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
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