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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Software project management

Similar to Software project management (20)

More from R A Akerkar

More from R A Akerkar (20)

Recently uploaded

Recently uploaded (20)

Software project management