Schedule & effort
http://www.flickr.com/photos/28481088@N00/315671189/sizes/o/
Problem
• Our ability to realistically plan and schedule
projects depends on our ability to estimate
project costs and development efforts
• In order to come up with a reliable cost estimate,
we need to have a firm grasp on the
requirements, as well as our approach to meeting
them
• Typically costs need to be estimated before these
are fully understood
Planning big projects
1. Figure out what the project entails
– Requirements, architecture, design
2. Figure out dependencies & priorities
– What has to be done in what order?
3. Figure out how much effort it will take
4. Plan, refine, plan, refine, …
What are project costs?
• For most software projects, costs are:
– Hardware Costs
– Travel & Training costs
– Effort costs
Aggravating & mitigating factors
•
•
•
•
•
•
Market opportunity
Uncertainty/risks
Contractual terms
Requirements volatility
Financial health
Opportunity costs
Cost drivers
•
•
•
•
•
Software reliability
Size of application database
Complexity
Analyst capability
Software engineering
capability
• Applications experience
• Programming language
expertise
•
•
•
•
•
•
Performance requirements
Memory constraints
Volatility of virtual machine
Environment
Use of software tools
Application of software
engineering methods
• Required development
schedule
What are effort costs?
• Effort costs typically largest of the 3 types of costs
(hardware, training and effort), and the most difficult
to estimate.
• Effort costs include:
–
–
–
–
–
–
Developer hours
Heating, power, space
Support staff; accountants, administrators, cleaners, management
Networking and communication infrastructure
Central facilities such as rec room & library
Social security and employee benefits
Software cost estimation –
(1981)
• Algorithmic cost modeling
– Base estimate on project size (lines of code)
• Expert judgment
– Ask others
• Estimation by analogy
– Cost based on experience with similar projects
• Parkinson’s Law
– Project time will expand to fill time available
• Pricing to win
– Cost will be whatever customer is willing to pay
• Top-down estimation
– Estimation based on function/object points
• Bottom-up estimation
– Estimation based on components
Boehm
Productivity metrics
• Lines of code
– Simple, but not very meaningful metric
– Easy to pad, affected by prog language
– How to count revisions/debugging etc?
• Function points
– Amount of useful code produced
(goals/requirements met)
– Less volatile, more meaningful, not perfect
Function points
Function points are computed by first calculating an unadjusted
function point count (UFC). Counts are made for the
following categories (Fenton, 1997):
– External inputs – those items provided by the user that describe
distinct application-oriented data (such as file names and menu
selections)
– External outputs – those items provided to the user that generate
distinct application-oriented data (such as reports and messages,
rather than the individual components of these)
– External inquiries – interactive inputs requiring a response
– External files – machine-readable interfaces to other systems
– Internal files – logical master files in the system
Each of these is then assessed for complexity and given a
weighting from 3 (for simple external inputs) to 15 (for
complex internal files).
Unadjusted Function Point Count
(UFC)
Weighting Factor
Item
Simple
Average
Complex
External inputs
3
4
6
External outputs
4
5
7
External inquiries 3
4
6
External files
7
10
15
Internal files
5
7
10
Each count is multiplied by its corresponding complexity
weight and the results are summed to provide the UFC
Object points
Similar to function points (used to estimate
projects based heavily on reuse, scripting and
adaptation of existing tools)
• Number of screens (simple x1, complex x2, difficult x3)
• Number of reports (simple x2, complex x5, difficult x8)
• Number of custom modules written in languages like Java/C
x10
COCOMO II Model
• Supports spiral model of development
• Supports component composition, reuse, customization
• 4 sub-models:
– Application composition model – assumes system written with
components, used for prototypes, development using scripts, db’s etc
(object points)
– Early design model – After requirements, used during early stages
of design (function points)
– Reuse model – Integrating and adapting reusable components (LOC)
– Post architecture model – More accurate method, once architecture
has been designed (LOC)
Intermediate COCOMO
• Computes software development effort as
function of program size and a set of "cost
drivers”.
• Product attributes
– Required software reliability
– Size of application database
– Complexity of the product
• Hardware attributes
– Run-time performance constraints
– Memory constraints
Intermediate COCOMO
• Personnel attributes
– Analyst capability
– Software engineering capability
– Applications experience
– Virtual machine experience
– Programming language experience
• Project attributes
– Use of software tools
– Application of software engineering methods
– Required development schedule
Intermediate COCOMO
• Each of the 15 attributes receives a rating on
a six-point scale that ranges from "very low"
to "extra high" (in importance or value). An
effort multiplier from the table below applies
to the rating. The product of all effort
multipliers results in an effort adjustment
factor (EAF). Typical values for EAF range
from 0.9 to 1.4.
Example: Twitter repression report
UC#1: Report repression
UC#2: Clarify tweet
Repressed citizen
UC#3: View reports
Concerned public
UC#3a: View on map
UC#3b: View as RSS feed
One possible architecture
Twitter
Façade
Tweet
processor
Geocoder
Façade
Database
Mapping
Web site
Google maps
RSS
Web service
Apache+PHP
Twitter
Geocoder
MySQL
Activity graph: shows dependencies of
a project’s activities
Do Twitter facade
1a
Do tweet processor
Do geocode facade
2
1c
Test & debug components
Design db
1b
3
Do map output
Milestone 2: DB contains real data
Milestone 3: DB contains real, reliable data
Milestone 4: Ready for public use
Do RSS output
3a
Test & debug map
3b
Advertise
4
Test & debug RSS
Activity graph: shows dependencies of
a project’s activities
• Filled circles for start and finish
• One circle for each milestone
• Labeled arrows indicate activities
– What activity must be performed to get to a
milestone?
– Dashed arrows indicate “null” activities
Effort
• Ways to figure out effort for activities
– Expert judgment
– Records of similar tasks
– Effort-estimation models
– Any combination of the above
Effort: expert judgment
• Not a terrible way to make estimates, but…
– Often vary widely
– Often wrong
– Can be improved through iteration & discussion
• How long to do the following tasks:
– Read tweets from Twitter via API?
– Send tweets to Twitter via API?
– Generate reports with Google maps?
Effort: records of similar tasks
• Personal software process (PSP)
– Record the size of a component (lines of code)
• Breakdown # of lines added, reused, modified, deleted
– Record time taken
• Breakdown planning, design, implement, test, …
– Refer to this data when making future predictions
• Can also be done at the team level
Effort: estimation models
• Algorithmic (e.g.: COCOMO: constructive cost
model)
– Inputs = description of project + team
– Outputs = estimate of effort required
• Machine learning (e.g.: CBR)
– Gather descriptions of old projects + time taken
– Run a program that creates a model
 You now have a custom algorithmic method
• Same inputs/outputs as algorithmic estimation method
Using COCOMO-like models
1.
2.
3.
4.
Assess the system’s complexity
Compute the # of application points
Assess the team’s productivity
Compute the effort
Assessing complexity
e.g.: A screen for editing the database involves 6 database tables, and it has 4 views.
This would be a “medium complexity screen”.
This assessment calls for lots of judgment.
Pfleeger & Atlee
Computing application points (a.p.)
e.g.: A medium complexity screen costs 2 application points.
3GL component = reusable programmatic component that you create
Pfleeger & Atlee
Assessing team capabilities
e.g.: Productivity with low experience + nominal CASE… productivity = (7+13)/2 = 10
application points per person-month (assuming NO vacation or weekends!!!!!)
Pfleeger & Atlee
CASE (comp aided SE) TOOLS
• It offer many benefits for developers building
large-scale systems.
• As spiraling user requirements continue to
drive system complexity to new levels, CASE
tools enable engineers to abstract away from
the entanglement of source code, to a level
where architecture & design become apparent
and easier to understand and modify.
• The larger a project, the more important it is
to use a CASE tool in software development.
CASE TOOLS
• As developers interact with portions of a
system designed by their colleagues, they
must quickly seek a subset of classes and
methods and assimilate an understanding of
how to interface with them.
• In a similar sense, management must be able,
in a timely fashion and from a high level, to
look at a representation of a design and
understand what's going on. Hence case tools
are used
Identify screens, reports, components
3GL components
- Tweet processor
- Twitter façade
- Geocoder façade
Twitter
Façade
Tweet
processor
Geocoder
Façade
Database
Reports
- Mapping web site
- RSS web service
Mapping
Web site
Google maps
RSS
Web service
Apache+PHP
Twitter
Geocoder
MySQL
Use complexity to compute
application points
3GL components
- Tweet processor
- Twitter façade
- Geocoder façade
Simple model assumes that
all 3GL components are 10
application points.
Reports
- Mapping web site
- RSS web service
Displays data from only a
few database tables (3? 4?)
Neither has multiple sections.
Each is probably a “simple”
report, 2 application points.
3*10 = 30 a.p.
2*2 = 4 a.p.
30 + 4 = 34 a.p.
Assess the team’s productivity
& compute effort
• Assume at your company the team has…
– Extensive experience with websites, XML
– But no experience with Twitter or geocoders
– Since 30 of the 34 a.p. are on this new stuff,
assume very low experience
– Virtually no CASE support… very low
•  therefore calculate the productivity as
application points in the “person-months”.
• Note: this assumes no vacation or weekends
Distribute the person-months over the
activity graph
Do Twitter façade (1.25)
1a
Do geocode façade (1.25)
Do tweet processor (1.00)
1c
2
Test & debug components (3.75)
Design db (0.25)
1b
3
Do map output (0.25)
Do RSS output (0.25)
3a
Test & debug map (0.25)
3b
Advertise (1.0?)
4
Test & debug RSS (0.25)
The magic behind
distributing person-months
• Divide person-months between
implementation and other activities
(design, testing, debugging)
– Oops, forgot to include an activity for testing and
debugging the components… revise activity graph
• Notice that some activities aren’t covered
– E.g.: advertising; either remove from diagram or
use other methods of estimation
Do you believe those numbers?
• Ways to get more accurate numbers:
– Revise numbers based on expert judgment or
other methods mentioned.
– Perform a “spike”… try something out and actually
see how long it takes
– Use more sophisticated models to analyze how
long components will really take
– Use several models and compare
• Expect to revise estimates as project proceeds
Further analysis may give
revised estimates…
Do Twitter façade (1.50)
1a
Do geocode façade (0.75)
Do tweet processor (0.50)
1c
2
Test & debug components (4.25)
Design db (0.25)
1b
3
Do map output (0.50)
Do RSS output (0.25)
3a
Test & debug map (0.25)
3b
Test & debug RSS (0.25)
Critical path: longest route through the
activity graph
• Sort all the milestones in “topological order”
– i.e.: sort milestones in terms of dependencies
• For each milestone (in order), compute the
earliest that the milestone can be reached
from its immediate dependencies
Example: computing critical path
Do Twitter façade (1.50)
1a
1.50
2.00
Do geocode façade (0.75)
Do tweet processor (0.50)
1c
2
1.50
Design db (0.25)
Test & debug components (4.25)
1b
3
0.25
Do map output (0.50)
6.75
7.00
6.25
Do RSS output (0.25)
3a
Test & debug map (0.25)
3b
Test & debug RSS (0.25)
6.50
Example: tightening the critical path
Do Twitter façade (1.50)
1a
1.50
2.00
Do geocode façade (0.75)
Do tweet processor (0.50)
1c
2
1.50
Design db (0.25)
2.00
1b
0.25
3
Test & debug components (4.25)
What if we get started
on the reports as soon
as we have a (buggy)
version of the database
and components?
2.50
6.25
Do map output (0.50)
Do RSS output (0.25)
3a
Test & debug map (0.25)
3b
Test & debug RSS (0.25)
2.25
Gantt Chart
• Shows activities on a calendar
– Useful for visualizing ordering of tasks & slack
– Useful for deciding how many people to hire
• One bar per activity
• Arrows show dependencies between activities
• Milestones appear as diamonds
Example Gantt chart
Gantt chart quickly reveals that we only need to hire two people (blue & green)
Two ways of scheduling
• Scheduling with a set of requirements and an
architecture?
• In contrast, assume that you are scheduling
before you have requirements and an
architecture. How much different would that
be?
• What are the pros and cons of each approach?
What’s next for you?
• Updated vision statement
– Your chance for extra credit!!
– Thursday presentation: Each team is given 15
minutes to present how their vision has been
more clear through this time (power-point
presentation)
– You can include your requirements gathering,
constraints and other details of your work until
now.
– What are your future plans?
– You will receive your midterms back tomorrow.