Unit 3 Estimation and Scheduling PDF
Unit 3 Estimation and Scheduling PDF
Unit 3 Estimation and Scheduling PDF
SOFTWARE ENGINEERING
• Project planning
• Project resources
• Decomposition techniques
• Empirical estimation models
❑ Development environment
❑ A statement of availability
People
o Number required
o Skills required
o Geographical location
Development Environment
o Software tools
o Computer hardware
o Network resources
Reusable Software Components
o Off-the-shelf components
o Full-experience components
o Partial-experience components
o New components
Human Resources
❑ Planners need to select the number and the kind of people skills needed to
complete the project
❑ They need to specify the organizational position and job specialty for each
person
❑ Small projects of a few person-months may only need one individual
❑ Large projects spanning many person-months or years require the location
of the person to be specified also
❑ The number of people required can be determined only after an estimate of
the development effort
Development Environment Resources
• Off-the-shelf components
• Components are from a third party or were developed for a previous project
• Ready to use; fully validated and documented; virtually no risk
• Full-experience components
• Components are similar to the software that needs to be built
• Software team has full experience in the application area of these components
• Modification of components will incur relatively low risk
• Partial-experience components
• Components are related somehow to the software that needs to be built but
will require substantial modification
• Modifications that are required have a fair degree of risk
• New components
• Components must be built from scratch by the software team specifically for the
needs of the current project
• Software team has no practical experience in the application area
• Software development of components has a high degree of risk
Factors Affecting Project Estimation
and money
❑ The degree to which the project plan reflects the abilities of the software
team
❑ The stability of both the product requirements and the environment that
❑ Decomposition techniques
❑ These take a "divide and conquer" approach
❑ Identify the set of functions that the software needs to perform as obtained
from the project scope
❑ Identify the series of framework activities that need to be performed for each
function
❑ Estimate the effort (in person months) that will be required to accomplish
each software process activity for each function
❑ Apply average labor rates (i.e., cost/unit effort) to the effort estimated for
each process activity
❑ Compute the total cost and effort for each function and each framework
activity
❑ Compare the resulting values to those obtained by way of the LOC and FP
estimates
❑ If both sets of estimates agree, then your numbers are highly reliable
❑ Otherwise, conduct further investigation and analysis concerning the function
and activity breakdown
Functional Point (FP) Analysis
• Allan J. Albrecht initially developed function Point Analysis in 1979 at
IBM
• FPA is used to make estimate of the software project, including its
testing in terms of functionality or function size of the software
product.
• However, functional point analysis may be used for the test
estimation of the product
• Objectives of FPA:
• The basic and primary purpose of the functional point analysis is to
measure and provide the software application functional size to the
client, customer, and the stakeholder on their request.
• Further, it is used to measure the software project development
along with its maintenance, consistently throughout the project
irrespective of the tools and the technologies.
Measurements Parameters Examples
The functional complexities are multiplied with the corresponding weights against each
function, and the values are added up to determine the UFP (Unadjusted Function Point) of
the subsystem.
Here that weighing factor will be simple, average, or complex for a measurement
parameter type.
The Function Point (FP) is thus calculated with the following formula.
• FP = Count-total * [0.65 + 0.01 * ∑(fi)]
= Count-total * CAF
• where Count-total is obtained from the above Table.
• CAF = [0.65 + 0.01 *∑(fi)]
F = 14 * 3 = 42
CAF = 0.65 + ( 0.01 * 42 ) = 1.07
COCOMO Model
• Boehm proposed COCOMO (Constructive Cost Estimation Model) in
1981
• COCOMO predicts the efforts and schedule of a software product
based on the size of the software.
• The necessary steps in this model are:
• Get an initial estimate of the development effort from evaluation of
thousands of delivered lines of source code (KDLOC).
• Determine a set of 15 multiplying factors from various attributes of
the project.
• Calculate the effort estimate by multiplying the initial estimate with
all the multiplying factors i.e., multiply the values in step1 and step2.
• To determine the initial effort Ei in person-months the
equation used is of the type is shown below
Ei=a*(KDLOC)b
• In COCOMO, projects are categorized into three types:
• Organic
• Semidetached
• Embedded
• 1.Organic: A development project can be treated of the organic type, if the
project deals with developing a well-understood application program, the
size of the development team is reasonably small, and the team members
are experienced in developing similar methods of projects. Examples of
this type of projects are simple business systems, simple inventory
management systems, and data processing systems.
• 2. Semidetached: A development project can be treated with
semidetached type if the development consists of a mixture of
experienced and inexperienced staff.
• Team members may have finite experience in related systems but may be
unfamiliar with some aspects of the order being developed. Example of
Semidetached system includes developing a new operating system (OS), a
Database Management System (DBMS), and complex inventory
management system.
• 3. Embedded: A development project is treated to be of an embedded
type, if the software being developed is strongly coupled to complex
hardware, or if the stringent regulations on the operational method
exist. For Example: ATM, Air Traffic control.
• For three product categories, Bohem provides a different set of
expression to predict effort (in a unit of person month)and
development time from the size of estimation in KLOC(Kilo Line
of code) efforts estimation takes into account the productivity
loss due to holidays, weekly off, coffee breaks, etc.
• According to Boehm, software cost estimation should be done
through three stages:
• Basic Model
• Intermediate Model
• Detailed Model
Basic COCOMO Model:
• The basic COCOMO model provide an accurate size of the project parameters. The
following expressions give the basic COCOMO estimation model:
• Effort is the total effort required to develop the software product, expressed in person
months (PMs).
• Estimation of development effort
• For the three classes of software products, the formulas for estimating the effort based
on the code size are shown below:
• Organic: Effort = 2.4(KLOC) 1.05 PM
• Semi-detached: Effort = 3.0(KLOC) 1.12 PM
• Embedded: Effort = 3.6(KLOC) 1.20 PM
• Estimation of development time
• For the three classes of software products, the formulas for estimating the
development time based on the effort are given below:
• Organic: Tdev = 2.5(Effort) 0.38 Months
• Semi-detached: Tdev = 2.5(Effort) 0.35 Months
• Embedded: Tdev = 2.5(Effort) 0.32 Months
• Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and
development time for each of the three model i.e., organic, semi-detached &
embedded.
• Solution: The basic COCOMO equation takes the form:
• Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC
• (i)Organic Mode
• E = 2.4 * (400)1.05 = 1295.31 PM
D = 2.5 * (1295.31)0.38=38.07 PM
• (ii)Semidetached Mode
• E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM
• (iii) Embedded Mode
• E = 3.6 * (400)1.20 = 4772.81 PM
D = 2.5 * (4772.8)0.32 = 38 PM
2. Intermediate Model:
• The basic Cocomo model considers that the effort is only a function of the
number of lines of code and some constants calculated according to the
various software systems.
• The intermediate COCOMO model recognizes these facts and refines the
initial estimates obtained through the basic COCOMO model by using a set
of 15 cost drivers based on various attributes of software engineering.
• Classification of Cost Drivers and their attributes:
• (i) Product attributes -
• Required software reliability extent
• Size of the application database
• The complexity of the product
• Hardware attributes -
• Run-time performance constraints
• Memory constraints
• The volatility of the virtual machine environment
• Required turnabout time
• 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
The cost drivers are divided into four categories:
• Intermediate COCOMO equation:
• E=ai (KLOC) bi*EAF
D=ci (E)di
• Coefficients for intermediate COCOMO
Project ai bi ci di
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
important
❑ Prototyping of user interfaces
❑ Consideration of software and system interaction
❑ Assessment of performance
❑ Evaluation of technology maturity
Early design stage model
❑ Used once requirements have been stabilized and basic software