ISAD357SL
Software Development and
Project Management
Craig Banyard
Centre for Security Communications and Network Research
craig.banyard@plymouth.ac.uk
Outline
1 Collect Feedback
2 Background to Estimation
Estimation Methods
3 • Delphi Technique
• Story points
• Function Points
Estimation Questions
o How much effort in person months (PM), time (in months), resource
(e.g. people, cost) is required for our project?
o 3 people for 4 months = 12 PM
o 4 people for 3 months = 12 PM
o 6 people for 2 months = 12 PM
Cost Estimation
o When will we need staff and how many?
o What factors affect staff productivity?
o What properties of the product (e.g. size, constraints, type) and
process need to be understood or estimated in order to answer the
above questions?
o And how do these properties relate to these questions?
o How much should we charge the customer?
Project costs
o Hardware and software costs
o Travel and training costs
o Effort costs: salaries, insurance, pension, overheads (buildings,
lighting, heating, ect…)
o Dominant factor
o Effort cost is typically twice the gross salary
o £30,000 per annum ~ £40 per hour
Factors affecting cost
o Reuse of code – write less of it
o Avoid reworking – get it right first time
o Good Quality Assurance processes
o Prototyping
o Good programming practices
o Use tools – they save work, make work more efficient
o Get best people – better value for money
Project staffing
o A critical issue
o May not be possible to appoint the ideal people to work on a
project
o Secondment of staff to your project
o Development of existing staff
o Budget
o Availability
o You will have to work within these constraints
Software pricing factors
o Broader organisational, economic, political and business
considerations influence the price charged
o Market opportunity lower
o Cost estimation uncertainty increase
o Contractual terms lower
o Requirements volatility lower
o Financial health lower
Estimation Techniques
o Applying Delphi Techniques
o Extrapolation based on how similar this project is to previous
projects
o Study historical data
o Seeking expert’s advice
o Pricing to win
o Top level or Bottom up estimation
Delphi Technique
• Group technique that
extracts and
summarises the
knowledge of the group
to arrive at an estimate
• Three passes are made
Activity – Exercise 1
o Estimate how much rain you think will fall in November
Extrapolation
o AKA: estimation by analogy
o Cost computed by comparison with similar project in the same
application domain
o Accurate if project data is available and good records have
been kept
o Impossible if no comparable project has been tackled
o Impossible if data has not been systematically and carefully
recorded
o Does not factor in organisational learning – many do not learn!
Historical Data
o Feasible if robust project tools in use
o Github / Visual Studio Team Foundation Server
o Trello
o Atlassian
o Requires data about the context, people, characteristics of the
task, skillsets required
o Measures require standardisation – make sure you are
measuring the same thing
Expert Judgement
o One or more experts in the application domain predict how
much it will cost
o Cheap if you have the experts
o Can be accurate if they have direct experience of similar
systems
o They are likely to be using an analogy
o Inaccurate if you have no real experts
o New methods, techniques, people, situations may invalidate the
prior experience
Pricing to win
o Costs are not really estimated but a figure is created in order to
win the contract
o Advantage is that you get the contract
o Disadvantage is that the customer is unlikely to get what they
wanted, costs do not accurately reflect the work required
Top Level Estimation
o Assesses the overall system functionality
o Remember your Product Roadmap?
o Can be used without knowing the system architecture or
components
o So can be used early
o Disadvantage is that you can underestimate the cost of solving
difficult low-level technical problems
Bottom up
o Used when you know the system architecture and components
have been identified
o Estimate the cost/size for each component (and sum)
o Cannot be used early
o Accurate if a detailed system design is available
o May underestimate the system level costs
o E.g. Integrating
Story points
• Story points are used in the agile world
• They give relative values in a Fibonacci-like
format
• Teams get together to discuss their estimates
• Generating discussion about what needs
to be done
• Planning poker
• Team takes an item from the backlog
• Discusses it
• Each team member thinks of an estimate
• Everybody holds up a card with their
estimate
• Further discussion takes place
Activity – Exercise 2
o Consider the user story
o ”As a host I need to make a cup of tea for my guest”
o Each of you write a number on a menti.com that estimates the
length of time in minutes
o Discuss
o Why did you decide that number?
o Who takes the longest? Why?
o Who is the quickest? Why?
Size and Productivity
o Size of system, size of team, productivity of team all affect the
cost, effort and schedule
o Productivity (PROD) = rate of production of:
o Software and associated documentation
o Useful functionality
!"# !"#
o PROD = so PM =
$% $&'(
o Metrics based on volume/unit time do not take quality into account
o Productivity could be increased but at the cost of quality
Productivity measures
o Lines of code (LOC) – number of object code instructions
o Difficult to determine what counts as a line of code
o Productivity could vary by language
o Assembly vs Java!
o Refers to source code
!"#
o PROD = $%
o Real time embedded systems 40 – 160
o Systems programs 150 – 400
o Commercial applications 200 – 800
Functions points
o Measures of software functionality overcome the issues around
measuring lines of code
o Function points
o Object points
o Use case points
o An established method for estimating size of programs independently of
their programming languages
o Uses set of system characteristics to give weightings
o Now used in agile when looking at Story points
https://www.softwarevalue.com/insights/blog/posts/2016/January/is-
function-point-analysis-valuable-in-agile-environment/
Unadjusted Function point Count
(UFC)
Simple Average Complex
Input transactions 3 4 6
Output transactions 4 5 7
User inquiries 3 4 6
Internal Files 7 10 15
External interfaces to other 5 7 10
systems
Object Points
o NOP (Number Object Points) is a weighted estimate of the
following:
o Number of separate screens displayed
o simple = 1; moderately complex = 2; v.complex = 3
o Number of reports produced
o simple = 2; moderately complex = 5; v.complex/difficult = 8
o Number of modules developed
o each module = 10
Early cost estimation
o Function points allow costs to be estimated early on in the
development process
o Object points are easier to estimate from a specification than
function points
o Easier to decompose the user stories
Algorithmic cost modelling
o Effort is estimated using a numerical formula or model
o Formula typically uses an assessment of size and other
product/process cost factors
o Models need tuning to the environment / project
o Underlying assumptions made in the development of the model
are important
o E.g. Type of system
o E.g. Standards of measurement
COCOMO2
o Boehm’s Constructive Cost Model
o Created in late 1970’s
&"$ )**% ,-./-
o PM = $'"( 𝑥 ( )** )
o PM = effort in person months
o NOP = number of object points
o PROD = the productivity
o As object points per person-month
o Based on standard estimates of PROD
https://www.ibm.com/developerworks/library/d-estimation-agile-or-
conventional-trs/index.html
COCOMO2
o Used after the requirements have been agreed
o Estimates based on UFC
o Project/process cost drivers are applied to the measures
o Cost drivers reflect development environment and non-functional
requirement
o Cost drivers can alter PM by up to a factor of 10
Cost Drivers
o Personnel capability
o Product reliability and complexity
o Reuse required
o Platform difficulty
o Personnel experience
o Team support facilities
o Required schedule
Cost models
o Cost models help project planning
o Allow strategies to be compared
o For each strategy the alternative scenarios can be evaluated
along with associated probabilities
o For each strategy and scenario the estimated cost can be
computed using the cost model
o For each strategy the expected cost can be computed thus aiding
decision making
Summary
o Each method has strengths and weaknesses
o Estimation should try several methods
o If results diverge, there is probably insufficient information
o As a sanity check, global estimates should be broken down by
process and compared with typical breakdown costs
o Pricing to win is sometimes the only one suitable
Thank you
Do you have any questions?
