Project Planning and Estimation

Chapters 23, 24
Software Engineering: A Practitioner’s Approach
Manasvi Mehta
BCA 16 UPTEC Allahabad
+917275142550
 Project Planning
 When: need for software has already been
established; stakeholders are on-board;
coding is ready to begin
 What: project planning spans five major
activities- estimation, scheduling, risk
analysis, quality management planning, and
change management planning
 Who: software project managers, with
information from stakeholders and engineers
 Estimation
 Planning requires estimation early-on, even
though it is likely this “commitment” will
be proven wrong
 Some degree of uncertainty is unavoidable
when predicting into the future
 Solid techniques and concrete procedures
help reduce the inaccuracy of estimates
 Process-based estimation
 Most commonly-used technique for project
estimation
 Project is broken down into a relatively
small set of tasks and the effort required to
accomplish each task is estimated
 Begins with a delineation of software
functions obtained from the project scope
 Process-based estimation
 A series of framework activities must be
performed for each function
 Representative framework activities:
 Customer communication
 Planning / risk analysis
 Engineering
 Construction / release
 Functions and activities may be shown
together as a table:
 Process-based estimation table
Risk
Activity CC Planning Engineering Release CE Totals
analysis
Function Anal. Design Code Test

UICF 0.75 2.50 0.40 5.00 n/a 8.65

3DGA 0.50 4.00 0.60 2.00 n/a 7.10

GCDF 0.50 4.00 1.00 3.00 n/a 8.50

DBM 0.50 3.00 1.00 1.50 n/a 6.00

PCF 0.25 2.00 0.75 1.50 n/a 4.50

DAM 0.50 2.00 0.50 2.00 n/a 5.00

Totals .25 .25 .25 3.00 17.50 4.25 15.00 34.80

% effort 1% 1% 1% 7% 45% 12% 40%

 Process-based estimation
 Once functions and activities are melded,
the planner estimates the effort (person-
months) required to accomplish each
activity per function
 Average labor rates are then applied to the
estimated efforts (may vary per task)
 Cost and effort for each function and
activity (row and column totals) are
computed as the last step
 Estimation with use-cases
 Use-cases provide insight into software scope and
requirements
 However, developing an estimation approach with
use-cases is problematic:
 There is no standard form for use-cases
 They represent an external view (the user’s view) of the
software, and vary in levels of abstraction
 Use-cases do not address the complexity of a feature
 Use-cases do not describe complex interactions
between many functions and features
 Estimation with use-cases
 One person’s “use-case” could require
months of effort, another just a day or two
 Estimation using use-cases has been
investigated, but no proven method has
emerged to date.
 Smith suggests a method for using use-
cases, but in a strict, hierarchical manner
 Use-case estimation
 A structural hierarchy is described for the
project
 Any level of the hierarchy can be described
by no more than 10 use-cases
 Each of the use-cases would encompass no
more than 30 distinct scenarios
 Use-case estimation
 Use-cases for a large system are described at a
much higher level of abstraction then use-cases for
individual sub-systems
 Before use-cases can be used:
 The level within the structural hierarchy is established
 Average length (in pages) of each use-case is
determined
 The type of software (business, scientific, etc) is
defined
 Rough architecture for the system is considered
 Use-case estimation
 Once those characteristics are established,
empirical data can be used to determine
estimated LOC or FP per each use-case for
each level of the hierarchy
 Historical data are then used to calculate the
effort required to develop the system
 Sample use-case estimation
LOC = N × LOC avg + [(Sa/Sh - 1) + (P a/P h - 1)] × LOC adjust

N = actual number of use-cases

LOCavg = historical average LOC per use-case for this type of system
Sa = actual scenarios per use-case
Sh = average scenarios per use-case for this type of system
P a = actual pages per use-case
P h = average pages per use-case for this type of system
LOCadjust= represents an adjustment based on n percent of LOC where
n is defined locally and represents the difference between this project
and “average” projects
 Reconciling estimates
 The various estimation methods encountered
result in multiple estimates which must be
reconciled
 The goal of a reconciliation process is to produce
a single estimate of effort, project duration, or cost
 “Complicated methods might not yield a more
accurate estimate, particularly when developers
can incorporate their own intuition into the
estimate.” -- Philip Johnson, et al.
 Reconciling estimates
 Widely divergent estimates can often be
traced to one of two causes:
 The scope of the project is not adequately
understood or has been misinterpreted by the
planner
 Productivity data used for problem-based
estimation is inappropriate for the application,
obsolete, or has been misapplied.
 The planner must determine the cause of the
divergence to reconcile the estimates
 Estimation for Agile projects
 Requirements for an agile project are
defined as a set of user scenarios (e.g.,
“stories” in Extreme Programming)
 It is possible to develop an estimation
approach that is informal, but reasonable
disciplined for each software increment
 This approach uses a decomposition method
with the following steps:
 Estimation for Agile projects
1. Each user scenario is considered
separately for estimation purposes
2. The scenario is decomposed into the set of
functions and engineering tasks required
to develop them
3. Each task is estimated separately, based
on historical data, an empirical model, or
“experience”
4. Estimates for each task are summed to
obtain an estimate for the scenario
 Estimation for Agile projects
5. The effort estimates for all scenarios are
summed for a given increment to obtain the
increment estimate
 Because the project duration of an
increment is short (3-6 weeks), the
estimation approach serves two purposes:
 Ensure that the number of scenarios conforms
to available resources
 Establish a basis for allocating effort as the
increment is developed
Estimation for web engineering projects

 Web engineering projects often adopt the

Agile process model
 Along with the Agile estimation approach, a
modified function point (FP) measure can
be used to develop an estimate for a web
application
 Roetzheim suggests the following
information domain values when adopting
function points:
 Web application domain values
 Inputs are each input screen or form, each
maintenance screen, and each tab (if that
design metaphor is used anywhere)
 Outputs are each static web page, each
dynamic page (script), and each report
(whether web-based or administrative)
 Tables are each logical table in the
database, or each XML object or collection
of XML attributes (if XML is used for
storage)
 Web application domain values
 Interfaces retain their definition as logical
files (for example, unique record formats)
into our out-of-the-system boundaries
 Queries are each externally published or
use a message-oriented interface. A typical
example is DCOM or COM external
references
 Function points computed with these values
are a reasonable indicator of volume for a
web application
 Web application estimation
 Mendes suggests that the volume of a web
application is best determined by collecting
measures associated with the application called
“predictor variables”
 These include:
 Application level: page, media, and function count
 Page level: page, linking, and graphic complexity
 Media level: media size, duration
 Functional characteristics: code length, reused code
length
 Software project scheduling
 Creating a network of software engineering
tasks enabling you to get the job dome on
time
 Responsibility is assigned for each task,
progress is tracked, and the network is
adapted to changes in the process as they
occur
 Software project scheduling

“I love deadlines. I like the whooshing sound

they make as they fly by.”

-- Manasvi Mehta
 Relationship between people and
effort
 For small software projects, one person can
analyze requirements, perform design,
generate code, and conduct tests
 As the projects grow in size, more people
most become involved
 As this happens, more and more time is
spent managing the interaction and
communication among the people involved
 Relationship between people and
effort
 Common myth still believed by many
software managers:
“If we fall behind schedule we can always
add more programmers to catch up.”

 Smith’s law: Adding more people to a late

software project always makes it later.
 Relationship between people and
effort
 People added to the project must learn the
system, and the people who can teach them
are the people currently producing code
 In addition to learning time, more people
means more communication paths and
increasing the complexity of
communication throughout the project
 Elasticity of project schedules
 Empirical data and analysis has
demonstrated that project schedules are
elastic
 It is possible to compress a desired project
completion date to some degree by adding
resources
 Conversely, removing resources can extend
a completion date
Putnum-Norden-Rayleigh Curve
 The PNR Curve provides an indication of
the relationship between effort applied and
delivery time for a software project
 There is a highly non-linear relationship
between chronological time to complete a
project and human effort applied
Putnum-Norden-Rayleigh Curve
 The number of delivered lines of code L is
related to effort and development time by
the equation:
L = P × E1/3t4/3
E is development effort in person-months
P is a productivity parameter that reflects that
result in high quality (typically 2,000-12,000)
t is the project duration in calendar months
Putnum-Norden-Rayleigh Curve
 Rearranged to solve for development effort:
E = L3/(P3t3)

E is effort expended (in person-years) over the

entire project life-cycle
L is lines of code (source statements)
P is a productivity parameter that reflects that
result in high quality (typically 2,000-12,000)
t is the development time in years
 Find Me
 FACEBOOK-
www.facebook.com/manasvirajmehta
 TWITTER-
www.twitter.com/manasvirajmehta
 YOUTUBE-
www.youtube.com/manasvirajmehta
 YOUTUBE-
www.youtube.com/manasvirajmehta2
 Mail me- gwaliorhunk@gmail.com
 Call me @ +917275142550