MODULE-2

Step wise approach and Project evaluation

Software Project Management
4th Edition Chapter 2

Step Wise: An
approach to planning
software projects
 Step 1 establish project scope and
objectives

• 1.1 Identify objectives and measures of effectiveness

– ‘how do we know if we have succeeded?’

• 1.2 Establish a project authority

– ‘who is the boss?’

• 1.3 Identify all stakeholders in the project and their

interests
– ‘who will be affected/involved in the project?’
 Step 1 continued
• 1.4 Modify objectives in the light of
stakeholder analysis
– ‘do we need to do things to win over
stakeholders?’

• 1.5 Establish methods of communication

with all parties
– ‘how do we keep in contact?’
 Step 2 Identify project infrastructure
• 2.1 Identify relationship between project and any
strategic planning
– ‘why did they want the project?’
– Organization needs to give priorities to the projects to
be carried out.

• 2.2 Identify installation standards and procedures

– ‘what standards do we have to follow?’
– Define their development procedure.
– Change control and configuration management
standards should be in place to ensure that changes to
requirements are implemented in a safe and orderly
way.
• 2.3. Identify project team organization
– ‘where do I fit in?’
• Project leaders, especially in the case of large projects, might
have some control over the way that their project team is to be
organized.
 Step 3 Analysis of project characteristics

• 3.1 Distinguish the project as either objective or

product-based.
– Is there more than one way of achieving success?

• 3.2 Analyse other project characteristics

(including quality based ones)
– what is different about this project?
 Step 3 continued
Step 3.3 :Identify high level project risks
– ‘what could go wrong?’
– ‘what can we do to stop it?’
– Risks that threaten the successful outcome of the project.
Step 3.4:Take into account user requirements
concerning implementation
 Step 3.5 : Select development methodology and life cycle

approach
» waterfall? Increments? Prototypes

Step 3.6 : Review overall resource estimates

– Major risk have been identified and broad project approach has been
decided.
– Re-estimate the effort and other resources required to implement the
project.
Step 4 Identify project products and activities

4.1 Identify and describe project products - ‘what

do we have to produce?’
Project A product breakdown structure
product (PBS)

System Module Management

product products products

Module
Design Module
documents code
Progress
report
Tested
Overall Integration
Integrated
specification Test cases
software
 Products description

• The name/identity of the product

• The purpose of the product
• The derivation of the product
• The composition of the product
• The form of the product
• The relevant standards
• The quality criteria that should apply to it
 Product breakdown structures
• At IOE, Amanda finds that there is a standard PBS that she
can use as a check list for her own project

Selection
products

Invitation
Volume Office User List of potential
To tender
figures layouts requirements suppliers

Existing Users
Test
System Modified
examples
description requirements

A Product breakdown structure[ PBS] for the products needed to produce an invitation to tender [ITT]
 Step 4.2 :Document generic product flows

• Some products will need one or more other products to exist

first before they can be created.

• Program design must be created before the program can be

written and program specification must exist before the design
can be commenced.

• Ex product flow diagram [ PFD]

A fragment of a PDF for a software development task

User requirements

Overall system
specification

Module
Design
Integration
System test cases

Module code

Integrated/
tested software
 Step 4.3 Recognize product instances

• The PBS and PFD will probably have identified generic

products e.g. ‘software modules’

• It might be possible to identify specific instances e.g. ‘module

A’, ‘module B’ …

• But in many cases this will have to be left to later, more

detailed, planning
 4.4. Produce ideal activity network

• Identify the activities needed to create each product in the PFD

• More than one activity might be needed to create a single
product
• Draw up activity network
Activity network for the product flow diagram

Design
Integration
Test cases

Specify
Overall Design Code Test integrated
system Module A Module A software

Code
Design Module B
Module B
Step 4.5 modify the ideal to take into account need for stages
and checkpoints

• The approach to sequencing activities described above

encourages the formulation of a plan which will minimize the
overall duration, or ‘elapsed time’ for the project.

• Key activities or milestones,

which represents the completion of important stages of the
project of which they would want to take particular note.

• Checkpoint activities are often useful milestones.

 Step 5:Estimate effort for each activity

• 5.1 Carry out bottom-up estimates

– distinguish carefully between effort and elapsed time.
– Effort is the amount of work that needs to be done.
– Elapsed time is the time between the start and end of a
task.
• 5.2. Revise plan to create controllable activities
– break up very long activities into a series of smaller
ones
– bundle up very short activities (create check lists?)
 Step 6: Identify activity risks
• 6.1.Identify and quantify risks for activities
– damage if risk occurs (measure in time lost or money)
– likelihood if risk occurring

6.2. Plan risk reduction and contingency measures

– risk reduction: activity to stop risk occurring
– contingency: action if risk does occur.

• 6.3 Adjust overall plans and estimates to take account of

risks
– e.g. add new activities which reduce risks associated with other activities
e.g. training, pilot trials, information gathering
 Step 7: Allocate resources

• 7.1 Identify and allocate resources to activities

• 7.2 Revise plans and estimates to take into account

resource constraints
– e.g. staff not being available until a later date
– non-project activities
 Step 8: Review/publicize plan

8.1 Review quality aspects of project plan

• -activity was not properly completed and needs to be reworked
• Each task have quality criteria.

8.2 Document plan and obtain agreement

• plan be carefully documented
• Project understand and agree to the commitment required of them in the
plan

Step 9 and 10:

Execute plan and create lower level plans
Software Project Management
4th Edition Chapter 3

project evaluation
 Project Evaluation

• Strategic Assessment
• Used to assess whether a project fits in the long-term goal of
the organization
• Usually carried out by senior management
• Needs a strategic plan that clearly defines the objectives of the
organization
• Evaluates individual projects against the strategic plan or the
overall business objectives Programme management
• suitable for projects developed for use in the organization
Portfolio management
• suitable for project developed for other companies by software
houses
 Project Evaluation

• Strategic Assessment- ISSUE

• Objectives
• IS plan
• Organization structure
• MIS
• Personnel
• Image
 Project Evaluation

The evaluation of potential projects:

• Technical feasibility
• The balance of costs
• Benefits
• Finally the degree of risk associated with the project.
Technical assessment
Technical assessment of a proposed system consists of evaluating the
required functionality against the hardware and software available
 Cost benefit analysis (CBA)

Identifying and estimating all of the costs and benefits of

carrying out the projects and operating the delivered
application.
• Development costs: salaries and other employment cost.
• Setup costs: costs of putting the system into place.
new hardware, costs file conversion,
recruitment and staff training
• Operating costs: costs of operating the system once it has

been installed
Expressing these costs and benefits in common units
Difference between the total benefit and total cost of creating and operating
the system.
 Cash flow forecasting
• Estimating the overall costs and benefits of a project is the
forecasting of the cash flows that will place and their timing.
• A cash flow forecast will indicate when expenditure and
income will take place.
– Expenditure
– Income
– Time
 Cost-benefit evaluation techniques

Net profit
Difference between the total costs and the total
income over the life of the project.
 Cost-benefit evaluation techniques

Year Cash-flow Net profit

Difference between the total costs
0 -100,000
and the total income over the life
1 10,000 of the project.

2 10,000 ‘Year 0’ represents all the costs

before system is operation
3 10,000
‘Cash-flow’ is value of income less
4 20,000 outgoing
Net profit value of all the cash-flows
for the lifetime of the application
Net profit 50,000
 Payback period
• The payback period is the time taken to break even or pay
back the initial investment.
• The project with the shortest payback period will be chosen on
the basis that on organization will wish to minimize the time
that a project is ‘ in debit’
 Pay back period
This is the time it takes to start generating a surplus
of income over outgoings (or) payback the initial
investment. What would it be below?
Year Cash-flow Accumulated
0 -100,000 -100,000
1 10,000 -90,000
2 10,000 -80,000
3 10,000 -70,000
4 20,000 -50,000
 Return on investment

• ROI also known as accounting rate of return [ARR],

provides a way of comparing the net profitability to
the investment required.
 Return on investment (ROI)

ROI = Average annual profit X 100

Total investment

In the previous example

• average annual profit
= 50,000/5 A
= 10,000
• ROI = 10,000/100,000 X 100 =
10%
 Net present value
Would you rather I gave you £100 today or in 12 months time?

If I gave you £100 now you could put it in savings account and get
interest on it.

If the interest rate was 10% how much would I have to invest now to
get £100 in a year’s time?
This figure is the net present value of £100 in one year’s time

Value in year t
Present value =
(1+r)t
 Discount factor
Discount factor = 1/(1+r)t
r is the interest rate (e.g. 10% is 0.10)
t is the number of years

In the case of 10% rate and one year

Discount factor = 1/(1+0.10) = 0.9091
In the case of 10% rate and two years
Discount factor = 1/(1.10 x 1.10) =0.8294
Calculate the net present value for each
of the projects
 Internal rate of return

• Internal rate of return (IRR) is the discount

rate that would produce an NPV of 0 for the
project
• Can be used to compare different
investment opportunities
• There is a Microsoft Excel function which
can be used to calculate
Dealing with uncertainty: Risk evaluation

• project A might appear to give a better return

than B but could be riskier
• Could draw up draw a project risk matrix for
each project to assess risks – see next
overhead
• For riskier projects could use higher discount
rates
Example of a project risk matrix
 Risk profile analysis
• An approach which attempts to overcome some of the
objections to cost-benefit averaging is the construction of risk
profiles using sensitivity analysis.

• Various parameters leads to affect the cost and benefit

• Sensitivity analysis demands that we vary each factor one at a

time
Decision trees
Software Project Management
4th Edition Chapter 5

Software effort
estimation
 What makes a successful project?
Delivering: Stages:
 agreed functionality 1. set targets
 on time 2. Attempt to achieve
 at the agreed cost targets
 with the required
quality

BUT what if the targets are not achievable?

• Difficulties
1. Novel applications of software
2. Changing technology
3. Lack of homogeneity of project experience
Where are estimates done?
 Where are estimates done?
• Strategic planning: the costs of computerizing potential application and
benefits of doing, estimated to help decide what priority to give to each
project.
• Feasibility study: the benefits of the potential system will justify the costs.
• System specification: estimates at the design stage will also confirm that
the feasibility study is still valid.
• Evaluation of suppliers proposals: IOE maintenance group accounts
subsystem, actual system building out to tender.
• Project planning: planning and implementation of the project progress to
greater levels of detail, more detailed estimates of smaller work
components will be made.
 Problems with Over and under-
estimating
Parkinson’s Law:
‘Work expands to fill the time available’ that is given an
easy target staff will work less hard
Brooks’ Law:
“putting more people on a late job makes it later”
• An over-estimate is likely to cause project to take longer
than it would otherwise.
 The basis for software estimating
The need of historical data
• Estimating methods need information about how projects have been
implemented in the past.
• Programming languages used, software tools available, the standards
enforced and experience of the staff.
Measure of work
• It is not possible to calculate directly the actual cost or time required to
implement a project.
• Measures such as source lines of code [SLOC] or KLOC
Complexity
• Two software components with the same KLOC will not necessarily take
the same time to write, even if done by the same programmer in same
environment.
• Find objective measures of complexity .
 A software effort estimating techniques

Barry Boehm, his classic work on software effort models,

• Algorithmic models: which use ‘effort drivers’ representing
characteristics of the target system and the implementation
environment to predict effort.
• Expert judgment: where the advice of knowledgeable staff is
solicited.
• Analogy: where a similar, completed, project is identified and
its actual effort is used as the basis of the estimate for the new
project.
• Parkinson : which identifies the staff effort available to do a
project and uses that as the estimate.
• Price to win : where the ‘estimate’ is a figure that appears to
be sufficiently low to win a contract.
• Top-down: where an overall estimate is formulated for the
whole project which is then broken down into the effort
required for component tasks.
• Bottom-up: where component tasks are identified and sized
and these individual estimates are aggregated.
 Bottom-up versus top-down
• Bottom-up
– use when no past project data
– identify all tasks that have to be done – so quite time-
consuming
– use when you have no data about similar past projects

• Top-down
– produce overall estimate based on project cost drivers
– based on past project data
– divide overall estimate between jobs to be done
 Bottom-up estimating
1. Break project into smaller and smaller
components
2. Stop when you get to what one person can
do in one/two weeks]
3. Estimate costs for the lowest level activities
4. At each higher level calculate estimate by
adding estimates for lower levels
Top-down approach and parametric models

Estimate
100 days • Produce overall
overall
project estimate using effort
driver (s)

design code test

• distribute proportions
of overall estimate to
30% 30% 40%
i.e. i.e. i.e. 40 days components
30 days 30 days
• The top-down approach is normally associated with
parametric [or algorithmic] models.
• Practical concern – house-owner who needs sufficient
insurance cover to rebuild their property if destroyed.
• How many bricklayer hours , carpenter hours,
electrician-hours.
house owner can find an estimate of rebuilding costs based on
such parameters.
 Estimating by analogy
• It is called case based reasoning
1.Source cases – projects that have been completed
2.Target case – similar characteristics to the new project
3. Base estimate – effort recorded for the matching source case
4. Estimator job – identify the difference between source and target – make
adjustments to the base estimate for the new project.
5. What variables might make good size parameters
5. ANGEL software package – Euclidean distance between

distance = square-root of ( target _parameter – source _ parameter) pow 2

+ (target _parameter n – Source_ parameter n) pow 2)
 Function points Mark II

• The Mark II label implies an improvement and replacement of

the Albrecht method.
• Information processing size is initially measured in unadjusted
function points [UFPs] to which technical complexity
adjustment can then be applied [TCA].
Data store

input
process output
From Return to
user user

Model of transaction
 Function points Mk II continued
For each
transaction, count
#entities – data items input
accessed (Ni)
– data items output
(No)
– entity types
#input #output accessed (Ne)
items items

FP count = Ni * 0.58 + Ne * 1.66 + No * 0.26

 COSMIC full function points
• To use function point approach effectively an org needs to have access to
historical information about past projects.

• In particular the number of function points for each project and the actual
effort that it needed.

• The original work of FFPs has been taken forward by the formation of
common software measurement consortium [COSMIC].
 Layered software

Higher layers

Receives request Supplies service

Data reads/ Peer to peer

writes communication
Persistent peer
storage Software component
component

Makes a request
Receives service
for a service
Lower layers
 COSMIC FPs
The following are counted:
• Entries: movement of data into software component
from a higher layer or a peer component
• Exits: movements of data out
• Reads: data movement from persistent storage
• Writes: data movement to persistent storage
Each counts as 1 ‘COSMIC functional size unit’ (Cfsu)
 COCOMO81
• Based on industry productivity standards -
database is constantly updated
• Allows an organization to benchmark its
software development productivity
• Basic model
effort = c x sizek
• C and k depend on the type of system:
organic, semi-detached, embedded
• Size is measured in ‘kloc’ ie. Thousands of
lines of code
 The COCOMO constants
System type c k
Organic (broadly, 2.4 1.05
information systems)
Small team devp s/w
Semi-detached 3.0 1.12

Embedded (broadly, 3.6 1.20

real-time) product
develop in very cost

k exponentiation – ‘to the power of…’

adds disproportionately more effort to the larger projects
takes account of bigger management overheads
Development effort multipliers (dem)
According to COCOMO, the major productivity drivers
include:
Product attributes: required reliability, database size,
product complexity
Computer attributes: execution time constraints, storage
constraints, virtual machine (VM) volatility
Personnel attributes: analyst capability, application
experience, VM experience, programming language
experience
Project attributes: modern programming practices,
software tools, schedule constraints
• Boehm found intermediate version of COCOMO which took
into account 15 cost drivers. Nominal effort estimate [pm nom] is
derived in a similar way for the basic model.
• The nominal estimate is adjusted by development effort
multiplier [dem].

• [pm est] = [pm nom] X [dem]

• Dem is calculated by taking into account multipliers based on the effort

drivers.