Software Project Planning

• Estimation begins with a description of the scope

of the product. Until the scope is “bounded” it’s
not possible to develop a meaningful estimate.
• The problem is then decomposed into a set of
smaller problems and each of these is estimated
using historical data and experience as guides.
• Problem complexity and risk are considered
before a final estimate is made.
 Estimation for Software Projects

• Project planning

• Scope and feasibility

• Project resources

• Estimation of project cost and effort

• Decomposition techniques

• Empirical estimation models

 Software Project Planning
• The objective of software project planning is
to provide a frame work that enables the
manager to make reasonable estimates of
resources, cost and schedule.
 Software Project Planning
• Software project planning encompasses five major activities
– Estimation, scheduling, risk analysis, quality management
planning, and change management planning
• Estimation determines how much money, effort, resources, and
time it will take to build a specific system or product
• The software team first estimates
– The work to be done
– The resources required
– The time that will elapse from start to finish
 Software Scope
• The first activity in software project planning is the
determination of software .
• The software scope means the actual operation that is going to
carried out by the software and its plus points and limitations.

• Software scope describes

–The functions and features that are to be delivered to end
users
–The data that are input to and output from the system
–The "content "that is presented to users as a consequence of
using the software
–The performance, constraints, interfaces, and reliability that
bound the system
 Software Scope
• Scope can be define using two techniques
–A narrative description of software scope is developed after
communication with all stakeholders
–A set of use cases is developed by end users

• After the scope has been identified, two questions are asked
– –Can we build software to meet this scope?
– –Is the project feasible?
 Obtaining Project Scope
The first set of questions focuses on the customer, the overall goals
and benefits. For example, the analyst might ask:
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution?
The next set of questions enables the analyst to gain a better understanding
of the problem and the customer to voice any perceptions about a solution:
• How would you (the customer) characterize "good" output that would be
generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the environment in which the solution will
be used?
• Will any special performance issues or constraints affect the way the
solution is approached?
The final set of questions focuses on the effectiveness
of the meeting. These are called as Meta Questions-
• Are you the right person to answer these questions?
Are your answers official?
• Are my questions relevant to the problem you have?
• Am I asking too many questions?
• Is there anyone else who will provide additional
information?
• Is there anything else that I should be asking you?
 Scoping Example- Case Study

The conveyor line sorting system (CLSS) sorts boxes

moving along a conveyor line. Each box is
identified by a bar code that contains a part
number and is sorted into one of six bins at the
end of the line.
The boxes pass by a sorting station that contains a
bar code reader and a PC. The sorting station PC
is connected to a shunting mechanism that sorts
the boxes into the bins. Boxes pass in random
order and are evenly spaced. The line is moving
at five feet per minute.
 Scoping Example- Further Requirements
• CLSS software input information from a barcode reader at time intervals
that conform to the conveyor line speed.
• Barcode data will be decoded into box identification format.
• The software will look up in part number data base containing a
maximum of 1000 entries to determine proper bin location for box
currently at the reader (sorting station).
• The proper bin location is passed to a sorting shunt that will position
boxes in appropriate bin.
• A record of the bin destination for each box will be maintained for latter
recovery and reporting.
• CLSS software will also receive input from a pulse tachometer that will
be used to synchronize the control signal to the shunting mechanism.
i.e. Based on the number of pulses that will be generated between the
sorting station and the shunt, the software will produce a control signal
to the shunt to properly position the box.
 The project planner examines the statement of scope and extracts all
important software functions. This process, called decomposition.
• Read bar code input.
• Read pulse tachometer.
• Decode part code data.
• Do database look-up.
• Determine bin location.
• Produce control signal for shunt.
• Maintain record of box destinations.
• Performance is depicted by conveyor line speed. Processing for each
box must be complete before the next box arrives at the barcode
reader.
• Constraints- The CLSS software is constrained by the hardware it must
access i.e. barcode reader, the shunt, the PC and the available
memory, the overall conveyor line configuration(evenly spaced boxes)
 Feasibility
• After the scope is resolved, feasibility is addressed

• Software feasibility has four dimensions

– Technology–Is the project technically feasible? Is it within the state of

the art? Can defects be reduced to a level

matching the application's needs?

– Finance–Is is financially feasible? Can development be completed at a
cost that the software organization, its client, or the market can afford?
– Time–Will the project's time-to-market beat the competition?

– Resources–Does the software organization have the

resources needed to succeed in doing the project?

 Resources

• The second task of software planning is the estimation of

resources required. Each resource is specified with the
following characteristic. Resource descriptions, details of
availability, when it is required, how long it is required.
 Resources

• Human Resources: Evaluate scope and select skills required (both

organizational position and specialty, e.g. database software engineer). No of
people required decided on effort requited (person-month).
• Reusable software Resources
- Off-the-shelf components (existing software acquired from 3rd party with no
modification required or has been developed internally for past project)
- Full-experience components (previous project code is similar and team members
have full experience in this application area)
- Partial-experience components (existing project code is related but requires
substantial modification and team has limited experience in the application area)
- New components (must be built from scratch for this project)
• Environmental Resources:
- The hardware and software tools required to develop the project. Planner needs
to provide a time window for booking them
 Empirical Estimation Model
The COCOMO Model

COCOMO – Constructive Cost Model.

• Model 1- The basic COCOMO model computes software

development effort as a function of program size expressed in
estimated lines of code
• Model 2- The Intermediate COCOMO model computes software
development effort as a function of program size and a set of “cost
drivers” that include subjective assessments of product, hardware,
personnel and project attributes.
• Model 3 – The advanced COCOMO model incorporates all
characteristics of the inter mediate version with an assessment of
the cost driver’s impact on each step (analysis, design etc) of the
SE process
 Empirical Estimation Models

• Estimation models for computer software use empirically

derived formulas to predict effort as a function of LOC (line of
code) or FP(function point)
• Resultant values computed for LOC or FP are entered into An
estimation model
• The empirical data for these models are derived from a
limited sample of projects
–Consequently, the models should be calibrated to reflect
local software development conditions
 COCOMO
• Stands for Constructive Cost Model
• Introduced by Barry Boehm in 1981 in his book
“Software Engineering Economics”
• Became one of the well-known and widely-used
estimation models in the industry
• It has evolved into a more comprehensive estimation
model called COCOMO II
• COCOMO II is actually a hierarchy of three estimation
models
• As with all estimation models, it requires sizing
information and accepts it in three forms: object points,
function points, and lines of source code
The COCOMO model 3 classes of software project.

• Organic mode - Relatively small, simple software projects in

which small teams with good application experience work to a
set of less than rigid requirements.
(e.g. thermal analysis program developed for a heat transfer
group).
• Semidetached mode- An intermediate (in size and complexity)
software project in which teams with mixed experience levels
must meet a mix of rigid and less than rigid requirements
• Embedded mode – A software project that must be developed
within a set of tight hardware, software, and operational
constraints. (e.g. flight control software for aircraft).
• Basic COCOMO
– E = ab(KLOC) bb
– D = cb(E)db

Software project ab bb cb db
Organic 24 1.05 2.5 0.38
Semi detached 3 1.12 2.5 0.35
Embedded 3.6 1.2 2.5 0.32
• Intermediate COCOMO
– E = ai * KLOC * bi * EAF
– D = cb(E)db
– N=E/D

Software project ai bi
Organic 3.2 1.05
Semi detached 3 1.12
Embedded 2.8 1.2
 The Software Equation
• The software equation is a dynamic multivariable model that assumes a
specific distribution of effort over the life of a software development project.

E = (LOC * B0.333 / P) 3 * (1/t4)

where,
E = effort in person-months or person-years
t = project duration in months or years
B = special skills factor

For small programs (KLOC = 5 to 15), B = 0.16.

For programs greater than 70 KLOC, B = 0.39.
P = “Productivity parameter” that reflects:
• Overall process maturity and management practices
• The extent to which good software engineering practices are used
• The level of programming languages used
• The state of the software environment
• The skills and experience of the software team
The complexity of the application
Typical values of P might be
P = 2000 Real time embedded software
P = 10,000 Telecomm. and systems software
P = 28,000 Business system application
P = 12000 Scientific software