Module 5

Software Estimation
Modeling IT Systems
Topics in Estimation
 Software Estimation
 Size Estimation
 Effort Estimation
 Schedule Estimation
 Agile Size Estimation
Software and Construction
Challenges with Estimation
 Most projects overshoot
their estimated schedules
by 25 to 100 percent
 Estimates are prepared at
beginning and left static
 Changed to manage
business needs
 Uncertainty about the
nature of the product
contributes to uncertainty
in the estimates
Sources of Uncertainty
 Will the customer want Feature X?
 Will the customer want the cheap or
expensive version of Feature X?
 If you implement the cheap version
of Feature X, will the customer later
want the expensive version after all?
 How will Feature X be designed?
 What will be the quality level of
Feature X?
 How long will it take to debug and
correct the mistakes made in the
implementation of Feature X?
 How long will it take to integrate
Feature X with all the other features?
Estimate Convergence Graph
Estimation process overview
 Estimate the size of the product (number of
lines of code or function points)
− Use an algorithmic approach – e.g. function
points, that estimates size from program features
− Use size-estimation software
− If you have worked on a previous project that is
similar you can estimate from that
 Estimate the effort (person-months)
 Estimate the schedule (calendar months)
 A more general step (a meta-step)
− Provide estimates in ranges and periodically
refine the ranges to provide increasing precision
as the project progresses
Size Estimation
 Algorithmic approach
− such as function points, that estimates program
size from program features
 Use size-estimation software that estimates
program size from your description of
program features
− screens, dialogs, files, database tables, etc.
 If you have already worked on a similar
project and know its size
− Estimate each major piece of the new system as a
% of the size of a similar piece of the old system.
− Add up all the estimated sizes of the pieces
Function-Point Estimation
 This kind of size estimation is often used in
a project’s early stages
 Based on counting
−Inputs – screens, forms, dialog boxes,
controls etc.
−Outputs – screens, reports, graphs etc.
−Inquiries – input/output combinations
−Logical internal files – files controlled by
the program
−External interface files – files controlled by
other programs
Function-Point Multipliers
Function Points

Program Low Medium High

Characteristics Complexit Complexit Complexit
y y
y
Number of inputs
x4 x6
x3
Number of outputs
x5 x7
x4
Inquiries
x4 x6
x3
Logical internal
x 10 x 15
files x7
x7 x 10
Logical interface x5
files
Estimation Tips
 Avoid off-the-cuff estimates
 Allow time for the estimate, and plan it
 Use data from previous projects
 Use developer-based estimates
 Estimate by walkthrough
 Estimate by categories – e.g. easy, medium,
hard
 Estimate at a low level of detail
 Don’t omit common tasks
 Use software estimation tools
 Use several different estimation techniques,
and compare the results
 Change estimation practices as the project
progresses
Estimate Presentation Styles
 Plus-or-minus qualifiers
 Ranges
 Risk quantification
 Cases
− Best case, planned case, current case, worst
case
 Coarse dates and time periods
 Confidence factors
− E.g. delivery date – April 1, probability of
delivering on time – 5%
− May 1, probability of delivering on time – 50%
− June 1, probability of delivering on time – 95%
Effort Estimation
 Once you have the size
estimate you derive the
effort estimate
− Use estimation software to
create an effort estimate
directly from the size
estimate
− Use your organization’s
historical data to determine
how much effort previous
projects of the estimated
size took
− Use an algorithmic
approach to convert a lines-
of-code estimate into an
effort estimate
Schedule Estimation
 The third step (the first is estimating size
and the second is estimating effort) in
estimating a software project is to
compute the schedule estimate
 Software Schedule Equation
− Schedule in months = 3.0 * Person-months1/3
 Once you’ve estimated that it will take 65
man-months to build the project, the
equation says that the optimal schedule is
12 months (3.0 * 65 1/3 )
 If you end up with an optimal schedule of
12 months to do a project that requires
65-man-months you will need 5-6 team
members (65 man months divided by 12
months)
Agile Size Estimates
Story Points
 The “huge-ness” of a
task
 Relative deduction,
factors are
– Complexity
– Scope
 Relative values are
what is important:
– A login screen is a 2
– A search feature is an 8
 Points are unit-less
 Scale of 1-10 ideally
 Average task 5
Ideal Days
 Time taken if
– it’s all you worked on
– you had no
interruptions
– and everything you
need is available
 The ideal time of a
football game is 90
minutes
– Two 45-minute halves
 The elapsed time is
much longer (3
hours?)
Elapsed Time Vs Ideal Days
Ideally… Actually…
 Developer A  Developer A
– Monday has 8 hrs/day – has 3 hrs of meeting
– 40 hrs week – 1 hrs mail
– 4 hrs left for a
project

So developer B actually does 4 hrs of progress each

day. So takes 2 calendar days of work for 1 ideal day
of work.
Comparing Approaches
 Story points help drive cross-functional behavior
 Story point estimates do not decay
 Story points are a pure measure of size
 Estimating in story points is typically faster
 “My” ideal days cannot be added to “your” ideal days
 Ideal days are easier to explain outside the team
 Ideal days are easier to estimate at first
 Ideal days can force companies to confront time
wasting activities
How ‘huge’ are these?
 Read a high-level, 10 page overview of agile
software development in a business magazine
 Read a densely written 5 page research paper
about agile software development in a
academic journal
 Write the product backlog for a simple
eCommerce site that sells only beer
 Recruit, interview, and hire a new member for
your team
 Create a 60 minute presentation about agile
estimating and planning for your co-workers
 Read a 150-page book on agile software
development
 Write a 8-page summary of this session for your
boss
Agile Estimation Methods
Triangulation
 Comparing a user
story to others
– “This story is like that
story, so its estimate is
what that story’s
estimate was.”
 Don’t use a single
gold standard
 Triangulate instead
– Confirm estimates by
comparing the story to
multiple other stories.
– Group like-sized stories
on table or whiteboard
Planning Poker
 An iterative approach to
estimating
 Steps
– Each estimator is given a
deck of cards, each card has
a valid estimate written on it
– Product owner reads a story
and it’s discussed briefly
– Each estimator selects a card
that’s his or her estimate
– Cards are turned over so all
can see them
– Discuss differences
(especially outliners)
– Re-estimate until estimates
converge
IT Systems Modeling
Statement on IT System Modeling
 A picture is worth thousand words
IT System Modeling
Modeling Functions
 Use Case Modeling
 Structured System
Analysis and Design
IT System Modeling
Use Case Modeling Project Control
System
 Actor Set up Project

– User Role <<include>>

Identify
Assign Resources Projects
– Another system >
e>
– Time Project Manager
Track Progress l ud
i nc
<<
 Use Case

<<extend>>

>
e>
 System Boundary

lud

>
e>
inc
 Association

lud
<<actor>>

<<
Print Progress

inc
Finance Report

<<
– Include system

– Extend Provide Invoice Programme

Manager
Data

 Pls. draw fig 10.2 Print Personal Summarize

on P.162 Team Member
Schedule Projects
IT System Modeling
Modeling Data
 Data attributes that the
organization (system)
needs to maintain
 Grouping of data
attributes (Entities)
 Relationships between
the entities
 Entities can be
– Physical
– Conceptual
 Entity Type Vs. Entity
Occurrence
IT System Modeling
Entity Relations
 One to One
– May not require additional
entity
 One to Many
– Office to Employees
– Mandatory
– Optional
 Many to Many
– Books and Publishers
IT System Modeling
Object Modeling
 Objects
– Items for which system
maintains data
 Class
– Object Type
– Attributes
– Methods
– Optional
 Inheritance and
generalization
Case Study on Data
Modeling
Information Resource
Management
IT System Modeling
Data Modeling
 Also known as Data
Management
 Data vs. Context
 Data context is also
known as Meta Data
 Data management is
associated with
managing raw data as
well as meta data
Effect of Poor Data Management
 People maintain and collect data that is not
needed any more;
 The organisation has historic information that is
no longer used;
 The organisation holds a lot of data that is
inaccessible to potential users;
 Information is disseminated to more people
than it should be;
 The organisation uses inefficient and out-of-
date methods to collect, analyze, store and
retrieve the data;
 The organisation fails to collect data that it
needs.
Challenges of Data Quality
Management
 Lack of proper validation
 Multiple non-integrated
data storage
 Incomplete data
 Proliferation of local PCs
 Not considering non-
electronic forms of data
 Non-structured data such
as images, audio and video
 No central agency for data
management
Valuing and Classifying Data
 Valuing data
– by availability
– Valuing lost data
– Data life cycle
 Classifying data
– Operational or
transactional data
– Tactical data (MIS, BI)
– Strategic data
Data Warehousing
 Primarily used for what-
if analysis
 Contains historical data
 Data de-normalized for
quicker data analysis
Data Administration
 Setting up data standards
 Determining data
ownership
 Setting up data dictionary
 Data migration
 Change control of meta
data
 Setting up data
architecture
 Data security
 Data governance
 End of Module

Any Questions?

Any Suggestions for

Improvement?
 Any Questions?

Thanks for your participation and

co-operation.

Hoping to meet you again some

time soon!!

My mail id: lnmishra@gmail.com

Keep in touch.