Post on 30-Mar-2021
transcript
ISBSG 2021 WEBINAR
SERIESSoftware Sizing As An Essential Measure: Past,
Present, and Future
ISBSG MISSION
“To improve the management of IT resources by both business and government through the provision and exploitation of
public repositories of software engineering knowledge that are
standardized, verified, recent and representative of current technologies.
3
Software Size is the Most Critical Parameter
• What is the first question a painting contractor will ask when a
customer calls for a quote?
HOW BIG IS THE HOUSE?
• Software is the same - All things being equal, the larger the size,
the greater the effort and cost and the longer the schedule
Many Viable Sizing Approaches
4
1.Physical size: Source Lines of Code (SLOC
International Function Point Users Group
(IFPUG) Function Points (ISO/IEC 20926) **
Nesma Function Points (ISO/IEC Standard
ISO/IEC 24750)
Common Software Measurement
International Consortium (COSMIC) Function
Points (ISO/IEC Standard ) **
Simple Function points Object Points
Use Case PointsRequirements (Software
Engineering Institute)Others
Size Estimation & Measurement Helps Successful Projects
Forecasting / Simulation
Benchmarking
Goal Setting Estimation
SLOC is Not The Villain: Functional Size Not Always The Hero
6
• SLOC can be useful
• SLOC can be verified
• Special care required for reused, generated, etc.
• Simple standard & counting tools exist
• Bias against SLOC
• Functional size can be useful
• Several ISO standards available
• People often count without using the standards
SLOC Functional Size
Size Has Always Been Needed: Short History of Software Sizing
Memory Words
Assembly Lines of Code
Assembly derived
from source
Source Lines of Code
Effective Size
COTS Cognition
Functional Sizes
Relative sizing
Effective functional
size
Historical Sizing Memory Size Illustration
• 64k bytes
• 20% reserve
• 52k bytes of code used
• Bytes per instruction (Machine dependent)
• Least, Likely Most
• Likely 6 bytes per instruction ~ 8700 SLOC
8
Source to Object Or Object To Source
9
• You could see the assembly code mapping in the original PDP 11 C Language
10
Size By Comparison
Galorath Multi-Method Size Study Methodology
New Size
Functional
Analysis Sizing Databases
Multiple
Comparisons
Existing
Size
(rework)
Generated
CodeCOTS/GOTS
Integrated Code
Evaluate All Sources of Software Size…
Expert Judgment
Glue Code
Analogies…Using Multiple Methods
Expert Judgement 12000 15500 17000
Relevant Range by Analogy 19850 24750 32540
Sizing Database 8000 32000 46000
Functional Analysis 19680 27540 35400
SEER-Estimate by Comparison 15450 22650 29850
Delphi Analysis 16788 19750 22713
Composite 12000 22650 46000
Counts for existing
12
Software Size Effective Effort Units
• Functional Size
• SLOC
• Story Points
• Object Points
• Etc… New
Pre-Existing
Effective Effort Units
• Turns the gross size into the effective
effort required to use
• Amount of effort rather than total size
Redesign
Reimplementation
Retesting
NEW
Life cycle activities will be performed at
100%
EXISTING
Effective size” based on user-provided rework
percentages.
Results in a “reuse benefit” that reduces the
overall effort and schedule estimates
Effective Size To Normalize New
and Pre-Existing
Most Popular Languages Have Standard Line Terminator: Matches the Detailed Ruled
14
15 Carriage returns but only 7 logical lines
Simple counting… difficult estimating unless you have
size database
15
Developmental Software:
Functionality developed
specifically for the project at
hand
May include customization of
COTS
“Glue” Code:
Code written to bind COTS to
developmental software
Development effort must be
captured
Key Components Of A Software Project That Uses
Commercial Off the Shelf Software )COTS)
COTS Software:
Purchased functionality
Direct Cost component of COTS integration
COTS Cognition:
Required functionality within the COTS software that
must be understood
Effort component of COTS integration
Cots Cognition
• Features
• Quick Size
• Objects
COTS Cognition
16
Features
• Unique Functions (Inputs, Outputs, Queries, Etc.)
• Tables referenced
• Tables configured
Quick Size
• Application type
• Percentage required
Object Sizing
• Input services, output services
• Inquiry services
• External classes
• Internal classes
Measurement and Quality of Open Source
17
• Coverity free size & quality service for open source
• Coverity Scan Open Source Report Shows Commercial Code Is More Compliant to Security Standards than Open Source Code
741 projects2.5M LOC
44,641 defects are fixed(Only 10.2% of identified defects are false positives in 2013)
Coverity Scan
18
Comparison Sizing Can Be Very Quick and Effective
Conclusions
19
There are MANY viable ways to count or estimate size
Standards are key (ISO or not)
Functional size is helpful, if standard are used, whether counted or estimated
Don’t dismiss lines of code, counted with standards when appropriate
Keep seeking better and better approaches
Scoping COTS Cognition Using Features and Objects
21
Sizing with Features is
closely related to the traditional function point
method
Measures have been translated so that they are
closely related to features found in
COTS components
Unique Functions (Inputs, Outputs,
Queries, etc.)
Data Tables Referenced
Data Tables Configured
Use Objects if COTS
components are implemented as
objects
Object sizing metric is
completely compatible with IFPUG-standard function points
and object counting
guidelines
Input Services
Output Services
Inquiry Services
External Classes
Internal Classes
Application Type
Commercial application or
application type being integrated
If specific application is not listed, choose one that is similar in size/functionality to
the application being integrated
Percentage Required
Portion of COTS component
functionality that the integrating
developers are required to learn
Reflects effort to acquire a working knowledge of this functional portion