Scribd
Upload
11 views

Module-03.1 Software Estimation

Uploaded by

omegajoel14
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
11 views

Module-03.1 Software Estimation

Uploaded by

omegajoel14
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 32

Software

estimation
metrics
Module-03
THE MANAGEMENT SPECTRUM
 Software project management is an art and
discipline of planning and supervising software
projects.

 Software project management involves -


• planning,
• implementation,
• monitoring, and
• controlling the people, process, and events that
occur.
 Effective software project management
focuses on the four P’s: People, Product,
Process, and Project.
The People

 The people who participate in the software


process are
1) The Stakeholders -
a. Senior managers
b. Project (technical) managers
c. Practitioners (Technical Skill)
d. Customers
e. End users
2) Team Leaders
3)The Software Team
B. The Product

1. Software Scope
-Context-
-Information objectives-
-Function and performance-
2. Problem decomposition
C. The Process

A software process provides the


framework from which a comprehensive
plan for software development can be
established.
D. The Project

 Inorder to manage a successful software


project, you have to understand what
can go wrong so that problems can be
avoided.
SOFTWARE PROCESS AND
PROJECT METRICS
 Measurement can be used throughout a
software project to assist in
• estimation,
• quality control,
• productivity assessment, and
• project control.
Process Metrics and Software
Process Improvement
 Project metrics enable a software project
manager to

(1) assess the status of an ongoing project,


(2) track potential risks,
(3) uncover problem areas before they go
“critical”,
(4) adjust work flow or tasks, and
(5) evaluate the project team’s ability to control
quality of software work products.
Project Metrics
 SOFTWARE MEASUREMENT
• direct measures (e.g., the length of a bolt)
and
• indirect measures (e.g., the “quality” of
bolts produced, measured by counting
rejects).
SOFTWARE MEASUREMENT

 Direct measures –
 lines of code (LOC) produced
 execution speed
 memory size
 defects reported over some set period of
time.
SOFTWARE MEASUREMENT
 Indirect measures –
 Functionality
 Quality
 Complexity
 Efficiency
 Reliability
 maintainability
 Process, project, and product metrics are
considered as software metrics.
 Two software metrics-
1. Size-Oriented Metrics
2. Function-Oriented Metrics
1. SIZE-ORIENTED METRICS
 Direct measures of the software product.

 lines of code developed (LOC)


 efforts required in person-months (pm)
 cost of development
 pages of documentation developed (Pp. Doc.)
 errors recorded before release
 defects encountered after release to the customer
 people worked on the development of software
for project
Example in table format
 In order to develop metrics that can be
compared with similar metrics from other
projects, lines of code (LOC) is chosen as
a normalization value.
 Errors per KLOC (thousand lines of code)
 Defects per KLOC
 Rs per KLOC
 Pages of documentation per KLOC
2. FUNCTION-ORIENTED
METRICS
 The most widely used function-oriented metric
is the function point (FP).
 FP metric can be used to
1. estimate the cost or effort required to design,
code, and test the software;
2. predict the number of errors that will be
encountered during testing; and
3. forecast the number of components and/or
the number of projected source lines in the
implemented system.
Information domain values
used in function points are-
To use function point methods

• determine complexity of product,


• complexity of project can be simple,
average, or complex, and
• for each complexity level, weights
(multiplying values) have been
experimentally determined
 To compute function points (FP), the
following equation is used:

 where count total is the sum of all FP


entries obtained from table.
 The Fi (i = 1 to 14) are value adjustment
factors (VAF).
Fi is based on responses to the
14 questions
1. Does the system require reliable backup and recovery?
2. Are specialized data communications required to transfer
information to or from the application?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational
environment?
6. Does the system require online data entry?
7. Does the online data entry require the input transaction to
be built over multiple screens or operations?
8. Are the ILFs updated online?
9. Are the inputs, outputs, files, or inquiries
complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in
the design?
13. Is the system designed for multiple
installations in different organizations?
14. Is the application designed to facilitate
change and ease of use by the user?
 To calculate Fi, each of these questions is
answered using a scale that ranges from 0 to
5 as

• 0 - not important,
• 1 – incidental,
• 2 – moderate,
• 3 – average,
• 4 – significant, and
• 5 – essential.
EXAMPLE-1
Calculate function point (FP) value for an
inventory system that needs to
– ‘Add a record’
– ‘Delete a record’,
– ‘Display a record’,
– ‘Edit a record’, and
– ‘Print a record’.
A system maintains one internal data file with all
records.
Σ(Fi) is given as 23.
Solution-
 From given data, the information domain
value parameters can be determined as

• external outputs (EO) - 1


• external inquiry (EQ) - 1
• internal files (ILF) - 1
• external interfaces (EIF) - 0
• external inputs (EI) - 3
 Considering“Average” complexity for
project, Count_total can be calculated
as
 FP is calculated as
Other metrics can be
computed

• Productivity = FP/ Effort (effort is measured in


person-months)
• Errors/FP
• Cost (₹)/FP
• Defects/FP
• Pages of documentation/FP
• Errors/PM
• Cost (₹)/Page of Documentation

You might also like