Software Engineering

Activity#4 &5

Software Project Planning
• Cost estimation
• Project Scheduling
• Risk Analysis & Management
• Software Quality Assurance Planning
• Project Monitoring Plans
• Project Management Plan

Set by Dawit A. WLDU

Software Project Planning Slide 1
Objectives

To introduce the fundamentals of software project
planning

To explain why different techniques should be used for
software cost estimation

To describe the COCOMO algorithmic cost estimation
model

Set by Dawit A. WLDU Software Project Planning Slide 2

Introduction

Software projects are different from projects of other
engineering discipline. How?

Software engineering projects may be:
• Evolutionary or maintenance projects
» Most projects are of this type
» Can be several different types
– Corrective projects
– Adaptive projects
– Enhancement projects
– Perfective projects / Reengineering
• Projects that involve building on a framework or a set of
existing components.
• A framework is a software system especially designed to be reused
in different projects, or in the various products of a product line.
Set by Dawit A. WLDU Software Project Planning Slide 3
 Software project management
l 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
l
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

Set by Dawit A. WLDU Software Project Planning Slide 4

 Management activities
l Proposal writing
l Project planning and scheduling
l Project costing
l Project monitoring and reviews
l Personnel selection and evaluation
l Report writing and presentations

Set by Dawit A. WLDU Software Project Planning Slide 5

Cont‟d
• Green field projects
» The minority of projects
» Developers often enjoy such brand new, or green field projects – they have a
wider freedom to be creative about design decision.

The goal of any software project is to produce a software system
that meet commitments on cost, schedule, quality.

Worldwide - many projects fail
• one-third are runaways with cost or schedule overrun of more than
125%

Major reasons for project runaways
• unclear objectives, bad planning, no project management
methodology,
new technology, insufficient staff

Set by Dawit A. WLDU Software Project Planning Slide 6

 Cont‟d

Project planning is crucial to the success of the Project:
• careful planning right from the beginning of the project can help to
avoid costly mistakes.

Reluctance to Planning
• Takes too much time and cost
» Preventive action
» Long-term payoff is greater
than short-term cost
• Too tedious (mental activity)
» “Thinker” and “doer”
• Ego (shoot from the hip)
» Not realistic
“If you fail to plan, you plan to fail.”
Set by Dawit A. WLDU Software Project Planning Slide 7
Project planning

Before the project can begin, the manager and the
software team must estimate
• the work to be done,
• the resources that will be required, and
• the time that will elapse from start to finish.

The objective of project planning is to create a plan to meet
the commitments of the project, i.e. create a path that, if
followed, will lead to a successful project.

Project Planning helps in:-
• Facilitating communication
• Monitoring / measuring the project progress
• Provides overall documentation of planning decisions

Set by Dawit A. WLDU Software Project Planning Slide 8

Cont‟d

Project Planning is an ongoing effort throughout
the Project Lifecycle.

The major issues the project plan addresses are:
• Cost estimation
• Schedule and staffing
• Risk Analysis & Management
• Software Quality Assurance Planning
• Project Monitoring Plans
• Configuration Management Plan

Set by Dawit A. WLDU Software Project Planning Slide 9

 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.

Set by Dawit A. WLDU Software Project Planning Slide 10

Software Cost Estimation
First step in project planning

• i.e. estimate resources, cost and schedule for software development project

Predicting the resources required for a software

• How much effort is required to complete an activity?
• How much calendar time is needed to complete an activity?
• What is the total cost of an activity?

development process.

Highly subjective and depends on experience

Some of the questions that would be addressed in cost estimation are:

Estimate made at the beginning of s/w project

Set by Dawit A. WLDU Software Project Planning Slide 11

Software cost components


Hardware and software costs

Travel and training costs

Effort costs (the dominant factor in most
projects)
• salaries of engineers involved in the project
• Social and insurance costs

Effort costs must take overheads into account
• costs of building, heating, lighting
• costs of networking and communications
• costs of shared facilities (e.g library, staff restaurant, etc.)

Set by Dawit A. WLDU Software Project Planning Slide 12

Cost Estimation Techniques

Cost estimations techniques are :
» Expert judgement
» Estimation by analogy
» Parkinson's Law
» Pricing to win
» Algorithmic cost modelling

Each method has strengths and weaknesses

Estimation should be based on several methods

If these do not return approximately the same result, there is
insufficient information available

Some action should be taken to find out more in order to make
more accurate estimates

Set by Dawit A. WLDU Software Project Planning Slide 13

Expert Judgment


One or more experts in both software development and the
application domain use their experience to predict
software costs. Process iterates until some consensus is
reached.

Advantages: Relatively cheap estimation method.
Can be accurate if experts have direct experience of
similar systems

Disadvantages: Very inaccurate if there are no
experts!

Set by Dawit A. WLDU Software Project Planning Slide 14

Estimation by Analogy


The cost of a project is computed by comparing the project to
a similar project in the same application domain

Advantages: Accurate if project data available

Disadvantages:
• Impossible if no comparable project has been
tackled.
• Needs systematically maintained cost database

Set by Dawit A. WLDU Software Project Planning Slide 15

Parkinson‟s Law

The project costs whatever resources are available.

work expands to fill the time available.
• The cost is determined by available resources rather
than by objective assessment.
• If the software has to be delivered in 12 months and 5
people are available, the effort required is estimated to be
60 person-months.


Advantages: No overspend

Disadvantages: System is usually unfinished

Set by Dawit A. WLDU Software Project Planning Slide 16

Pricing to Win

The project costs whatever the customer has to spend on
it. i.e. the estimated effort depends on the customer‟s budget
and not on the software functionality

Advantages: You get the contract

Disadvantages: The probability that the
customer gets the system he or she wants is small. Costs do
not accurately reflect the work required

Set by Dawit A. WLDU Software Project Planning Slide 17

Top-down and bottom-up estimation

Any of these approaches may be used top-down or
bottom-up

Top-down
• Start at the system level and assess the overall
system functionality and how this is delivered
through sub- systems

Bottom-up
• Start at the component level and estimate the effort
required for each component. Add these efforts to
reach a final estimate

Set by Dawit A. WLDU Software Project Planning Slide 18

Top-down estimation

Usable without knowledge of the system architecture and the
components that might be part of the system

Takes into account costs such as integration, configuration
management and documentation

Can underestimate the cost of solving difficult low-level
technical problems
Bottom-up estimation

Usable when the architecture of the system is known and
components identified

Accurate method if the system has been designed in detail

May underestimate costs of system level activities such as
integration and documentation
Set by Dawit A. WLDU Software Project Planning Slide 19
Algorithmic cost modeling

A formulaic approach based on historical cost information and
which is generally based on the size of the software

Some formula based on empirical studies are derived and
adjusted according to the type of project (Organic,
semidetached, embedded ).

This estimation is generally based on the size of the
software
• Line of Code (LOC)
• Function point (FP)
• Object point effort estimation
• Use case based (object oriented approach)

COCOMO (constructive cost model) is one of algorithmic cost
Set bymodels
Dawit A. WLDU Software Project Planning Slide 20
Size Estimation- Line of Code(LOC)

“A line of code is any line of program text that is not a
comment or blank line, regardless of the
number of statements or fragments of
statements on the line.

This specifically includes all lines containing program
header, declaration, and executable and non-
executable

statements”.

Set by Dawit A. WLDU Software Project Planning Slide 21

 Cont‟d

The above program has 17 LOC

Set by Dawit A. WLDU Software Project Planning Slide 22
FP Estimation

Function points can be estimated from
requirement specificationor design specification,
thus making it possible to estimate
development efforts in early phases of development.

Function points are directly linked to the statement of
requirements; any change of requirements can easily
be followed by a re-estimate.

Function points are based on the system user‟s
external view of the system, non-technical
users of the software system have a better
understanding of what function points are measuring.

Set by Dawit A. WLDU Software Project Planning Slide 23


The principle of Albrecht‟s function point analysis(FPA) is
that a system is decomposed into functional units.
• Inputs : information entering the system
• Outputs : information leaving the system
• Enquiries : requests for instant access to information
• Internal logical files : information held within the system
• External interface files : information held by other system that is
used by the system being analyzed.

Set by Dawit A. WLDU Software Project Planning Slide 24

The Constructive Cost Model (COCOMO)

Constructive Cost Model (COCOMO), which is created by
Boehm in 1981, is an empirical model based on project
experience.

Well-documented, „independent‟ model which is not tied to a
specific software vendor.

COCOMO predicts the effort and schedule for a software
product development based on inputs relating to the size
of the software and a number of cost drivers that affect
productivity

COCOMO has three different models that reflect the
complexity:
• the Basic Model
• the Intermediate Model
• and the Detailed Model

Set by Dawit A. WLDU Software Project Planning Slide 25

Cont‟d

Set by Dawit A. WLDU Software Project Planning Slide 26

Project Scheduling

Software project scheduling is creating a network of
software engineering tasks enabling you to get the job
done on time.

It reflects the start date and end dates for each activity in
the project.

Responsibility is assigned for each task, progress is tracked,
and the network is updated to changes in the process as
they occur.

A project Schedule is at two levels - overall schedule and
detailed schedule

Overall schedule comprises of major milestones and
final
date

Detailed schedule is the assignment of lowest level tasks to
resources
Set by Dawit A. WLDU Software Project Planning Slide 27
Need for software scheduling
• Software project has a tendency to get out of control because of
the multiple activities that need to be monitored, tracked and
controlled
Milestone vs deliverables
• Milestone is end-point of software process activity or is a point
at which progress on the project may be assessed
• Deliverable is a project result that is delivered to the customer
usually at the end of some major project phase such as
specification, design, etc. (i.e. output (report), code )
• Deliverables are usually milestones but milestones need not be
deliverables.

Set by Dawit A. WLDU Software Project Planning Slide 28

Project scheduling techniques

Project scheduling involves identification of:
 The tasks
 dependencies among the tasks
 Duration of each task
 Start and finish date for each task

Techniques:
a) Gantt Chart
b) Network based scheduling (Precedence Networks ) -> helps
to calculate project duration
» Program Evaluation and Review Technique (PERT):
Event-based
» Critical Path Method (CPM): Activity-based

Set by Dawit A. WLDU Software Project Planning Slide 29

Gantt chart

GANTT chart is a type of bar chart that illustrates a
project schedule. used more frequently than others

Suitable for projects with less than 25 activities

Graphical display of start/end times

Shows overlapping activities easily
• CPM or PERT are translated to Gantt sometimes

For estimation of resource and budget vs. time

Developed in 1917 by Henry L. Gantt

Set by Dawit A. WLDU Software Project Planning Slide 30

Example: Gantt chart – Project Development

•A Gantt chart or project schedule includes a list of tasks on the left and
horizontal bars on the right showing when the tasks begin and end.
•We can draw charts with one hour, day, week, or month being the
smallest incremental value.

Set by Dawit A. WLDU Software Project Planning Slide 31

PERT

Based on graph theory (nodes and links)-acyclic
directed graph

Shows dependencies among tasks

PERT shows critical path ( a path which indicates the
minimum time required to finish the project or the
longest path).

All activities which don‟t lay on the critical path can
be delayed for some time (slack time) with out having
any effect on overall project schedule.

Set by Dawit A. WLDU Software Project Planning Slide 32

 Activities example

Set by Dawit A. WLDU Software Project Planning Slide 33

Critical path

PERT is a network approach that helps to calculate project
duration
• A “path” is a sequence of activities that begins at the start of the project and goes
to the end of the project
» 1,2,3,5,6,7,8
» 1,2,4,6,7,8
• The “critical path” is the path that takes the longest to complete
» and thus determines the minimum duration of the project

3 5
1 2 6 7 8
4

Set by Dawit A. WLDU Software Project Planning Slide 34

Cont‟d

Critical Path
• The path that
takes the
longest to
complete

Set by Dawit A. WLDU Software Project Planning Slide 35

 Exercise: Develop PERT and Identify the critical path for
the
following activities

Activity duration Intermediate/predecessor

A 8 -
B 7 A
C 7 B
D 10 A
E 12 A
F 8 C
G 9 C, E
H 5 F, G

Set by Dawit A. WLDU Software Project Planning Slide 36

Risk Analysis and Management

Any project can fail - reasons
• Managerial (e.g. schedule and budget overrun)
• Technical (doesn‟t deliver what is expected)

A project may fail due to unforeseen events - risk management
aims to tackle this.

Risk: any condition or event whose occurrence is not certain
but which can cause the project to fail
• Cost risk
• Performance risk
• Schedule risk

Set by Dawit A. WLDU Software Project Planning Slide 37

 Risks and risk types
Risk type Possible The database used in the system cannot process as many
Technology risks transactions per second as expected.
Software components which should be reused contain defects
which limit their functionality.

People It is impossible to recruit staff with the skills required.

Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational The organisation is restructured so that different management
are responsible for the project.
Organisational financial problems force reductions in the project budget.
The code generated by CASE tools is
Tools inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements which require major design rework are
proposed.
Customers fail to understand the impact of requirements
changes.
Estimation The time required to develop the software is
underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.

Set by Dawit A. WLDU Software Project Planning Slide 38

Cont‟d
Risk Management Tasks

RISK IDENTIFICATION

RISK ASSESSMENT RISK ANALY SIS

RISK PRIORITIZATION
RISK
MANAGEMENT RISK MANAGEMENT
PLANNING

RISK CONTROL RISK RESOLUTION

RISK MONITORING

Set by Dawit A. WLDU Software Project Planning Slide 39

 …Risk Identification

To identify possible risks to a project, i.e. to those events that
might occur and which might cause the project to fail

No “algorithm” possible, done by “what ifs”, checklists,
past experience, etc

Top Risk Examples
» Shortage of technically trained manpower
» Too many requirement changes
» Unclear requirements
» Not meeting performance requirements
» Unrealistic schedules
» Insufficient business knowledge
» Working on new technology

Set by Dawit A. WLDU Software Project Planning Slide 40

Risk Prioritization

The number of risks might be large

Must prioritize them to focus attention on the “high risk”
areas

For prioritization, impact of each risk must be understood

In addition, probability of the risk occurring should also
be understood

Risk exposure (RE) = probability of risk occurring *
risk impact

RE is the expected value of loss for a risk

Prioritization can be done based on risk exposure value

Plans can be made to handle high RE risks

Set by Dawit A. WLDU Software Project Planning Slide 41

Cont‟d


A Simple approach to Risk Prioritization
• Classify risk occurrence probabilities as: Low, Medium,
High
• Classify risk impact as: Low, Medium, High
• Identify those that are HH, or HM/MH
• Focus on these for risk mitigation
• Will work for most small and medium sized projects

Set by Dawit A. WLDU Software Project Planning Slide 42

Risk Control

Can the risk be avoided?
• E.g. if new hardware is a risk, it can be avoided by working
with proven hardware

For others, risk mitigation steps need to be planned and
executed
• Actions taken in the project such that if the risk materializes,
its
impact is minimal
• Involves extra cost

Set by Dawit A. WLDU Software Project Planning Slide 43

Risk Mitigation Example

Too many requirement changes
• Convince client that changes in requirements will have an impact on
the schedule
• Define a procedure for requirement changes
• Maintain cumulative impact of changes and make it visible to client
• Negotiate payment on actual effort.

Unrealistic schedules
• Negotiate for better schedule
• Identify parallel tasks
• Have resources ready early
• Identify areas that can be automated
• If the critical path is not within the schedule, negotiate with the
client
• Negotiate payment on actual effort
Set by Dawit A. WLDU Software Project Planning Slide 44
Cont‟d

Manpower attrition
• Ensure that multiple resources are assigned on key project areas
• Have team building sessions
• Rotate jobs among team members
• Keep backup resources in the project
• Maintain documentation of individual‟s work
• Follow the CM process and guidelines strictly

Set by Dawit A. WLDU Software Project Planning Slide 45

Risk Mitigation Plan

Risk mitigation involves steps that are to be performed
(hence has extra cost)

It is not a paper plan - these steps should be scheduled
and executed

These are different from the steps one would take if the risk
materializes - they are performed only if needed

Risks must be revisited periodically

Set by Dawit A. WLDU Software Project Planning Slide 46

Software Quality Assurance Plan

Software Quality is conformance to
• Explicitly stated functional and performance requirements
• Explicitly stated development standards
• Implicit characteristics of all professional developed
software
Quality can be defined in many ways

Current industry standard - delivered defect density (e.g.
#defects/KLOC)

Defect - something that causes software to behave in an
inconsistent manner

Set by Dawit A. WLDU Software Project Planning Slide 47

Cont‟d

Defect Injection and Removal


Software development is labor intensive

Defects are injected at any stage

As quality goal is low delivered defect density, these
defects have to be removed

Done primarily by quality control (QC) activities of
reviews and testing

Set by Dawit A. WLDU Software Project Planning Slide 48

Cont‟d
Quality Plan


The quality plan drives the quality activities in the project

Level of plan depends on models available

Must define QC tasks that have to be performed in the
project

Can specify defect levels for each QC tasks (if models and
data available)

Set by Dawit A. WLDU Software Project Planning Slide 49

Project Monitoring Plans

Project monitoring includes Progress/status, Cost /
effort, Personnel, resources

A plan is a mere document that can guide - It must
be executed

To ensure execution goes as per plan, it must be monitored
and controlled

Monitoring requires measurements

And methods for interpreting them

Monitoring plan has to plan for all the tasks related
to monitoring

Set by Dawit A. WLDU Software Project Planning Slide 50

Cont‟d

Measurements


Must plan for measurements in a project

Without planning, measurements will not be done

Main measurements – effort, size, schedule, and defects
• Effort – as this is the main resource; often tracked through
effort reporting tools
• Defects – as they determine quality; often defect logging
and tracking systems used

During planning – what will be measured, how, tool
support, and data management

Set by Dawit A. WLDU Software Project Planning Slide 51

Cont‟d
Project Tracking

Goal: To get visibility in project execution so corrective
actions can be taken when needed to ensure project
succeeds

Different types of monitoring done at projects;
measurements provide data for it

Activity-level monitoring
• Each activity in detailed schedule is getting done
• Often done daily by managers
• A task done marked 100%; tools can determine status of higher
level tasks

Set by Dawit A. WLDU Software Project Planning Slide 52

Cont‟d

…Tracking

Status reports
• Generally done weekly to take stock
• Summary of activities completed, pending
• Issues to be resolved

Milestone analysis
• A bigger review at milestones
• Actual vs estimated for effort and schedule is done
• Risks are revisited
• Changes to product and their impact may be analyzed

Cost-schedule milestone graph is another way of doing
this

Set by Dawit A. WLDU Software Project Planning Slide 53

Cont‟d
Cost-schedule milestone graph

Set by Dawit A. WLDU Software Project Planning Slide 54

Project Management Plan

The project management plan (PMP) document is the
culmination of all planning activities undertaken by
project managers.

It should not be confused with the detailed project
schedule.

Detailed project schedule represents only the schedule and
assignment of activities.

PMP shows what activities get done in the project

Set by Dawit A. WLDU Software Project Planning Slide 55

Cont‟d
PMP Structure - Example


Project overview - customer, start and end date, overall
effort, overall value, main contact persons, project
milestones, development environment..

Project planning - process and tailoring, requirements
change mgmt, effort estimation, quality goals and plan, risk
management plan, ..

Project tracking - data collection, analysis frequency,
escalation procedures, status reporting, customer
complaints, …

Project team, its organization, roles and
responsibility, …
Set by Dawit A. WLDU Software Project Planning Slide 56
Format for Format for Project Plan

•Title page 1- Overview

•Signature page * Summary
•Change history  Purpose, scope,
•Preface  Objectives
 Assumptions and constraints
•Table of contents
 Deliverables
•List of figures  Schedule and budget summary
•List of tables
*Evolution of
plan 2- References
3- Definitions

Set by Dawit A. WLDU Software Project Planning Slide 57

Cont‟d

4 Project organization 6 Technical process plans

•External interface •Process model
•Internal structure •Methods, tools
•Roles and responsibilities •Acceptance plan
5 Managerial process plans 7 Supporting process plans
 Estimation (cost, schedule) •Configuration management
 Work (activities, resource and •Verification/validation
•Quality assurance (reviews,
budget allocation) audits, …)
 Control (quality, metrics, …) •Subcontract
 Risk management •Process improvement plan
Annexes
Index

Set by Dawit A. WLDU Software Project Planning Slide 58

Summary

Project planning forms the foundation of project
management

Key aspects: effort and schedule estimation, quality
planning, risk management., …

Outputs of all project planning can be documented in a PMP,
which carries all relevant info about project

Besides PMP, a detailed project schedule maintains tasks to
be done in the project

Set by Dawit A. WLDU Software Project Planning Slide 59