Software project management

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

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,
 Managerial report writing and presentations, etc.
M i l t iti d t ti t

R. Akerkar - SPM 4

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

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

R. Akerkar - SPM 6

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

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

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

SPMP Document
 After planning is complete:
 Document the plans:
p
 in a Software Project

Management Plan(SPMP)
document.

R. Akerkar - SPM 10

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

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 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

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

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

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

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

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

 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

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

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

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

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 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

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

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

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 MIS):
(e g
 may turn out to be a poor data
communication engineer
engineer.

R. Akerkar - SPM 30

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

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

Work Breakdown Structure

Compiler Project
p 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 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

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
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

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

Project Risks
j
 Project risks associated with:
 budget,
 schedule,

 personnel,
p ,
 resource, and

 customer problems.
t bl

R. Akerkar - SPM 38

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

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

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

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

Software project management

More Related Content

What's hot

Viewers also liked

Similar to Software project management

More from R A Akerkar

Recently uploaded

Software project management