Software Project management

 By
 RAVINDRA PRAKASH SAXENA
 Dept. of Computer Science Engineering
Objectives
To explain the main tasks undertaken by project
managers
To introduce software project management and to
describe its distinctive characteristics
To discuss project planning and the planning process
To show how graphical schedule representations are
used by project management
To discuss the notion of risks and the risk
management process
Software project management
Concerned with activities involved in ensuring
that software is delivered on time and on
schedule and in accordance with the
requirements of the organisations developing
and procuring the software.
Project management is needed because software
development is always subject to budget and schedule
constraints that are set by the organisation
developing the software.
Topics covered
Management activities
Project planning
Project scheduling
Risk management
Management activities
Proposal writing.
Project planning and scheduling.
Project costing.
Project monitoring and reviews.
Personnel selection and evaluation.
Report writing and presentations.
Management commonalities
These activities are not peculiar to software
management.
Many techniques of engineering project
management are equally applicable to software
project management.
Technically complex engineering systems tend
to suffer from the same problems as software
systems.
Project planning
Probably the most time-consuming project
management activity.
Continuous activity from initial concept through
to system delivery. Plans must be regularly revised as
new information becomes available.
Various different types of plan may be developed to
support the main software project plan that is
concerned with schedule and budget.
Project planning process
 Establish the project constraints
 Make initial assessments of the project parameters
 Define project milestones and deliverables
 while project has not been completed or cancelled loop
 Draw up project schedule
 Initiate activities according to schedule
 Wait ( for a while )
 Review project progress
 Revise estimates of project parameters
 Update the project schedule
 Re-negotiate project constraints and deliverables
 if ( problems arise ) then
 Initiate technical review and possible revision
 end if
 end loop
The project plan
The project plan sets out:
The resources available to the project;
The work breakdown;
A schedule for the work.
Types of project plan
Plan Description
Quality plan Describes the quality procedures and
standards that will be used in a project.
Validation plan Describes the approach, resources and
schedule used for system validation.
Configuration Describes the configuration management
management plan procedures and structures to be used.
Maintenance plan Predicts the maintenance requirements of
the system, maintenance costs and effort
required.
Staff development plan. Describes how the skills and experience of
the project team members will be
developed.
Project plan structure
Introduction.
Project organisation.
Risk analysis.
Hardware and software resource requirements.
Work breakdown.
Project schedule.
Monitoring and reporting mechanisms.
Project scheduling
Split project into tasks and estimate time and
resources required to complete each task.
Organize tasks concurrently to make optimal
use of workforce.
Minimize task dependencies to avoid delays
caused by one task waiting for another to complete.
Dependent on project managers intuition and
experience.
Project life cycle
Project Lile Cycle
Initiation phase
 During the first of these phases, the initiation phase, the project
objective or need is identified; this can be a business problem or
opportunity. An appropriate response to the need is documented in a
business case with recommended solution options. A feasibility study
is conducted to investigate whether each option addresses the project
objective and a final recommended solution is determined. Issues of
feasibility (“can we do the project?”) and justification (“should we do
the project?”) are addressed.
 Once the recommended solution is approved, a project is initiated to
deliver the approved solution and a project manager is appointed.
The major deliverables and the participating work groups are
identified and the project team begins to take shape. Approval is then
sought by the project manager to move on the detailed planning
phase.


Execution Phase
The most important issue in this phase is to ensure project
activities are properly executed and controlled. During the
execution phase, the planned solution is implemented to
solve the problem specified in the project's requirements.
As the execution phase progresses, groups across the
organization become more deeply involved in planning for
the final testing, production, and support. The most
common tools or methodologies used in the execution
phase are an update of Risk Analysis and Score Cards, in
addition to Business Plan and Milestones Reviews.
Closuse Phase
In this last stage, the project manager must ensure that
the project is brought to its proper completion. The
closure phase is characterized by a written formal project
review report containing the following components: a
formal acceptance of the final product by the client,
Weighted Critical Measurements (matching the initial
requirements specified by the client with the final
delivered product), rewarding the team, a list of lessons
learned, releasing project resources, and a formal project
closure notification to higher management. No special
tool or methodology is needed during the closure phase.
Structure of a Software Project
Management Plan
1- Front Matter
2- Introduction
3- Project Organization
4. Managerial Process
5. Technical Process
6. Work Elements, Schedule, Budget
SPMP Part 1: Front Matter
Title Page
 Revision sheet (update history)
 Preface: Scope and purpose
 Tables of contents, figures, tables
SPMP Part 2: Introduction
Project Overview
Executive summary: description of project, product
summary
 Project Deliverables
All items to be delivered, including delivery dates
and location
 Evolution of the SPMP
Plans for anticipated and unanticipated change
 Reference Materials
Complete list of materials referenced in SPMP
 Definitions and Acronyms
SPMP Part 3: Project Organization
Process Model
Relationships among project elements
 Organizational Structure
Internal management, organization chart
 Organizational Interfaces
Relations with other entities
 Project Responsibilities
Major functions and activities; nature of each; who’s in
charge
Process Model
Shows relationships among
Functions, activities,
Tasks
 Milestones
 Baselines
 Reviews
 Work breakdown Structure
 Project deliverables
Sign-offs
Process Model……………….
Visualization of process model
Project Management Aids
MS Project (Microsoft)
MAC Project (Claris)
EasyTrak (Planning Control International)
SPMP Part 4: Managerial
Processes
Management Objectives and Priorities
Philosophy, goals and priorities
 Assumptions, Dependencies, Constraints
External factors
Risk Management
Identifying, assessing, tracking, contingencies for risks
Monitoring and Controlling Mechanisms
Reporting mechanisms and formats, information flows,
reviews
 Staffing Plan
Needed skills (what?, how much?, when?)
SPMP Part 5: Technical Process
Methods, Tools and Techniques
Computing system, development method, team structure,
etc.
Standards, guidelines, policies.
Software Documentation
Documentation plan, including milestones, reviews and
baselines.
Project Support Functions
Plans for functions (quality assurance, configuration
management).
SPMP Part 6: Work Elements
Work Packages (Work breakdown structure)
Project decomposed into tasks; definitions of tasks
Dependencies
 Precedence relations among functions, activities and tasks
Resource Requirements
Estimates for resources such as personnel, computer time,
special hardware, support software.
Budget and Resource Allocation
 Connect costs to functions, activities and tasks.
 Schedule
 Deadlines, accounting for dependencies, required
milestones
Project Estimation Techniques
Empirical Estimation Techniques
Heuristics Techniques
Analytical Techniques
Empirical Estimation Techniques
Empirical: derived from experiment, experience
and observation rather than theory
Using prior experience you make an educated
guess
We are going to learn two empirical estimations
techniques:
Expert judgment
Delphi estimation technique
Expert Judgment Technique
And expert makes an educated guess after analyzing
the problem thoroughly
Estimate individual modules and then sum the
estimations
Affected by human errors and bias
The expert may not be an expert in every technical
field
 Use group of experts
Group of experts decision may still be biased, and
assertive member have higher influence on the final
estimate
Delphi Cost Estimation
Tries to overcome the shortcoming of Expert
judgment method
Group of experts and a coordinator
Coordinator gives each expert a copy of the SRS
document and a form to fill the estimation
The experts estimates and gives his reasoning
Coordinator collects the forms and the summary of
reasons and redistribute them to experts to re-estimate
Several iterations/rounds may happen
The coordinator is responsible of compiling the final
results and provide the final estimate
Heuristic Estimation
Techniques
Using this techniques assumes that there is a
relationship among the different project parameters
that can be expressed using a mathematical formula
The mathematical formula to estimate the resource is
usually represented as

 where C1 , C2, D1, D2, … are constants (historical data)

 e is the characteristics of the software (historical data)
COCOMO model is a multivariate heuristic
estimation technique (vs. single variant)
Analytical Estimation techniques
These techniques have a scientific basis
 Halstead’s software science is an example
Especially useful for estimating maintenance efforts,
since it outperforms the previous methods in
calculating it
This method starts with basic assumptions about the
project to derive the required results
COCOMO (CONSTRUCTIVE COST
MODEL)
 -First published by Dr. Barry Boehm, 1981
Software development project can categorized on
their complexity
Organic
Semidetached
Embedded
Consider the characteristics of the product, of the
development team and the development
environment
COCOMO………………………
There are three main types of projects
Application
 Data processing programs, (payroll system : simple algorithm
computed for many entries)
Utility
 Compilers, linkers, IDE (Integrated Development
Environment) … etc
System programs
 Hardware, strict time constraints … etc
The complexity ratio is 1:3:9

34
COCOMO…………..
Organic
 Problem is well known and understood
 Small team size
 Experienced team members in the problem
Semidetached
 Mix of experienced and inexperienced
 May have limited experience or unfamiliar with some of the
aspect of the system
Embedded
 Strongly coupled to complex hardware
 Or stringent regulation on the system operations

35
COCOMO………………
Estimate the effort in (PM: person-month) unit,
and the development time from size estimation
given in KLOC
One instructions with n line : nLOCs
One person-month is the effort a person can put
in a month
Takes into account holidays, breaks … etc
Software cost estimation are done through three
stages: basic COCOMO, intermediate COCOMO,
and complete COCOMO

36
Basic COCOMO
Basic COCOMO is given using the following two
expressions:

Effort = a1 × (KLOC)a2 in PM
Tdev = b1 × (Effort)b2 in months
a1, b1, a2, b2 are constants

37
 Person- Month Calculation
Number of
persons in the
development
team

Time

38
 Basic COCOMO
Nominal Effort
Organic :- Effort = 2.4 × (KLOC)1.05 in PM
Semidetached :- Effort = 3.0 × (KLOC)1.12 in PM
Embedded:- Effort = 3.6 × (KLOC)1.20 in PM
Nominal Development Time
Organic:- Tdev = 2.5 × (Effort)0.38 in months
Semidetached:- Tdev = 2.5 × (Effort)0.35 in months
Embedded:- Tdev = 2.5 × (Effort)0.32 in months

39
Effort vs. Product Size

40
Development Time vs. Size

41
Basic COCOMO
Effort increases rapidly with the project size
When the size increases by two times, the time to
develop the project increases only moderately
Large product have more concurrent activities
There is more scope to parallel activities in
semidetached and embedded system
Total cost= Effort (in PM) × PM cost + project
expenses (HW+ SW+ rent + … )

42
 Example
size = 60 KLOC

Organic :- Effort = 2.4 × (KLOC)1.05 in PM

= 176.71 PM
Semidetached :- Effort = 3.0 × (KLOC)1.12 in PM
= 294.21 PM
Embedded:- Effort = 3.6 × (KLOC)1.20 in PM
= 489.87 PM
Organic:- Tdev = 2.5 × (Effort)0.38 in months
= 17.86 months
Semidetached:- Tdev = 2.5 × (Effort)0.35 in months
= 18.28 months
Embedded:- Tdev = 2.5 × (Effort)0.32 in months
= 18.15 months 43
 Example
size = 500 KLOC

Organic :- Effort = 2.4 × (KLOC)1.05 in PM

= 1637.31 PM
Semidetached :- Effort = 3.0 × (KLOC)1.12 in PM
= 3162.04 PM
Embedded:- Effort = 3.6 × (KLOC)1.20 in PM
= 6238.3 PM
Organic:- Tdev = 2.5 × (Effort)0.38 in months
= 41.62 months
Semidetached:- Tdev = 2.5 × (Effort)0.35 in months
= 41.97 months
Embedded:- Tdev = 2.5 × (Effort)0.32 in months
= 40.96 months 44
Intermediate COCOMO
 Takes basic COCOMO as starting point
 Identifies personnel, product, computer and
project attributes which affect cost and development
time.
Multiplies basic cost by attribute multipliers which
may increase or decrease costs
Attributes
Personnel attributes
Analyst capability
Virtual machine experience
Programmer capability
Programming language experience
Application experience

Product attributes
 Reliability requirement
 Database size
 Product complexity
Intermediate Model
Effort Equation (COCOMO 81)
Effort=EAF*A(size)exponent
EAF (effort adjustment factor) is the product of effort
multipliers corresponding to each cost driver rating
A is a constant based on the developmental mode
 organic = 3.2
 semi = 3.0
 embedded = 2.8

Size = 1000s Delivered Source Instruction (KDSI)

Exponent is constant given mode