LECTURE -9

SOFTWARE ENGINEERING
SOFTWARE PROJECT MANAGEMENT

1
SOFTWARE PROJECT MANAGEMENT

Project Planning
Software Cost Estimation
 Cost Estimation Models
 Software Size Metrics
 Empirical Estimation
 Heuristic Estimation
 COCOMO
Staffing Level Estimation
Effect of Schedule Compression on Cost

2
INTRODUCTION
Many software projects fail:
 due to faulty project management practices:
 It is important to learn different aspects of software project management.
Goal of software project management:
 enable a group of engineers to work efficiently towards successful completion
of a software project
A project manager’s activities are varied.
 can be broadly classified into:
 project planning,
 project monitoring and control activities.
Once a project is found to be feasible,
 project managers undertake project planning.

3
RESPONSIBILITY OF PROJECT MANAGERS

o Project proposal writing,

o Project cost estimation,
o Scheduling,
o Project staffing,
o Project monitoring and control,
o Software configuration management,
o Risk management,
o Managerial report writing and presentations, etc.

4
PROJECT PLANNING ACTIVITIES

o Estimation:
o Effort, cost, resource, and project duration
o Project scheduling:
o Staff organization:
o staffing plans
o Risk handling:
o identification, analysis, and abatement procedures
o Miscellaneous plans:
o quality assurance plan, configuration management plan, etc.

Requires utmost care and attention --- commitments to unrealistic time and resource
estimates result in:
o irritating delays.
o customer dissatisfaction
o adverse affect on team morale
o poor quality work
o project failure. 5
SLIDING WINDOW PLANNING

Involves project planning over several stages:

 protects managers from making big commitments too early.
 More information becomes available as project progresses.
 Facilitates accurate planning
After planning is complete:
 Document the plans:
 in a Software Project Management Plan(SPMP) document

6
ORGANIZATION OF SPMP DOCUMENT

Introduction
o (Objectives,Major Functions,Performance Issues,Management and Technical
Constraints)
Project Estimates
o (Historical Data,Estimation Techniques,Effort, Cost, and Project Duration Estimates)
Project Resources Plan
o (People,Hardware and Software,Special Resources)
Schedules
o (Work Breakdown Structure,Task Network, Gantt Chart Representation,PERT Chart
Representation)
Risk Management Plan
o (Risk Analysis,Risk Identification,Risk Estimation, Abatement Procedures)
Project Tracking and Control Plan
o Miscellaneous Plans(Process Tailoring,Quality Assurance)

7
SOFTWARE COST ESTIMATION
o Determine size of the product.
o From the size estimate,
o determine the effort needed.
o From the effort estimate,
o determine project duration, and cost.

8
Software Cost Estimation

Effort Cost
Estimation Estimation

Size Staffing
Estimation Estimation

Duration
Estimation Scheduling

9
SOFTWARE COST ESTIMATION
Three main approaches to estimation:
 Empirical
 Heuristic
 Analytical

10
SOFTWARE COST ESTIMATION TECHNIQUES
Empirical techniques:
 an educated guess based on past experience.
Heuristic techniques:
 assume that the characteristics to be estimated can be expressed in terms of
some mathematical expression.
Analytical techniques:
 derive the required results starting from certain simple assumptions.

Software Size Metrics

1. LOC (Lines of Code):

Simplest and most widely used metric.
Comments and blank lines should not be counted.

11
DISADVANTAGES OF USING LOC
o Size can vary with coding style.
o Focuses on coding activity alone.
o Correlates poorly with quality and efficiency of code.
o Penalizes higher level programming languages, code reuse, etc.
o Measures lexical/textual complexity only.
o does not address the issues of structural or logical complexity.
o Difficult to estimate LOC from problem description.
o So not useful for project planning

12
FUNCTION POINT METRIC
o Overcomes some of the shortcomings of the LOC metric
o Proposed by Albrecht in early 80's:
 FP=4 #inputs + 5 #Outputs + 4 #inquiries + 10 #files + 10 #interfaces
1. Input:
 A set of related inputs is counted as one input.
2. Output:
 A set of related outputs is counted as one output.
3. Inquiries:
 Each user query type is counted.
4. Files:
 Files are logically related data and thus can be data structures or physical files.
5. Interface:
 Data transfer to other systems.

13
FUNCTION POINT METRIC
Suffers from a major drawback:
 the size of a function is considered to be independent of its complexity.
Extend function point metric:
 Feature Point metric:
 considers an extra parameter:
 Algorithm Complexity
Proponents claim:
 FP is language independent.
 Size can be easily derived from problem description
Opponents claim:
 it is subjective --- Different people can come up with different estimates for the
same problem.

14
EMPIRICAL SIZE ESTIMATION TECHNIQUES
Expert Judgement:
 An euphemism for guess made by an expert.
 Suffers from individual bias.
Delphi Estimation:
 overcomes some of the problems of expert judgement.
Expert Judgement
Experts divide a software product into component units:
e.g. GUI, database module, data communication module, billing module,
etc.
Add up the guesses for each of the components.

Delphi Estimation
Team of Experts and a coordinator.
Experts carry out estimation independently:
mention the rationale behind their estimation.
coordinator notes down any extraordinary rationale:
circulates among experts
15
DELPHI ESTIMATION:

Experts re-estimate.
Experts never meet each other

 to discuss their viewpoints .

Heuristic Estimation Techniques
Single Variable Model:
 Parameter to be Estimated=C1(Estimated Characteristic) x ed1
Multivariable Model:
 Assumes that the parameter to be estimated depends on more than one
characteristic.
 Parameter to be Estimated=C1(Estimated Characteristic) x ep1 d1+
C2(Estimated Characteristic) x ep2 d2+…
 Usually more accurate than single variable models

16
17