Software Sizing Units
Software Sizing Units
Software Sizing Units
Murali Chemuturi
My major concern about all the software size measures described in Chapter 6, is that
they use “Points” to signify software size. A “point” is something that does not occupy
space in geometry. “Points” are used in games – points are “scored” or counted. A
“point” where they are used (in games) – complexity does not affect them. A point never
becomes more than one point whatever be the complex maneuvers that have to be
achieved in scoring it. No factor, like wind factor, sun factor, humidity factor affect the
points.
Only in software industry do we have points being affected by complexity and other
factors.
Where there are no universally accepted units of measure, the un-written convention has
been to use “Units” as the unit of measure.
For example, the unit of measure for heat was BTU (British Thermal unit).
Software size has come to be measured in “Points” – from the time that Function Points
are introduced for software size estimation, all others have followed this. Perhaps, it is
that “Points are scored” – so functions are counted (scored).
In enzymes that are measured in units, they catalyze some action. In heat too, BTU
catalyzes some action (raise the temperature).
Hence I propose Software Size Units (SSU) for measuring software size – taking
inspiration from the above!
Definition of SSU (Software Size Unit)
What does a software system comprise of? It basically consist of two types of elements,
namely,
a. Data Elements – the data that enters the system, is processed upon and is
either stored or given out as outputs
b. Process Elements – the software routines that process data elements and
achieve the desired functionality
Data Element – it is an input to the system. It may enter the system thru user input; or
read from a master data file/table; or received from another system. It could be a
constant (used as parameters for the software system) or a variable. It is classified into
three types, namely, Numeric, Alphanumeric and Control.
c. Control Data Element - Control Data Element triggers some process within
the system. Links on a web site, command buttons on a screen etc. are
examples of Control Data Elements.
Process Elements – Process Elements act on the Data elements and transform input to
desired outputs. Process Elements are classified into three types, namely, Input
Process, Output Process, Associate Process,
a. Input Process Elements (IPE) get Data Elements from external environment
into the system – may be thru keyboard, or from a file/table, or from a device
like scanner, or from a network.
b. Output Process Element (OPE) sends Data Elements from the system to
the external environment – may be to a screen, or a report, or to a device like
printer or to a network.
System – is a software that fulfils some need and performs a set of defined functions
Enters the system – it is a necessary input given either from the key board by the user,
or is retrieved from a master file/table which was prepared thru some other system, or is
received over network from another system.
The size of a software system is derived from the data elements and process
elements that comprise the system. A SSU (Software Size Unit) is a Process
Element that has five Numeric Data Elements.
Delivered Software Size (DSS) – this is measured in Software Size Units (SSU) and is
used for agreement between the customer and the vendor. This would be used for
estimating the effort required for developing the software. The effort required for
delivering the software would be the sum of effort required for Requirements Analysis,
Software Design, Construction and Testing.
a. Enumerate the process elements that comprise the system along with its
nature – that is – Input / Output / Associated
b. Against each process element count data elements, namely, NDE, ADE
and CDE
c. Against each process element compute equivalent Total Data Elements
(TDE) for the Process Element using the formula –
i. TDE = NDE + (ADE * 0.35) + (CDE * 0.75)
d. Compute the Software Size Units for each process element using the
formula
i. SSU = (TDE / 5) * Process Element Weight
e. Sum up the SSUs of each Process Element to obtain SSUs for the project
before contingency allowance
f. Add a contingency allowance of 10% towards possible requirement
changes to the Total SSU to obtain size estimate for the project
The below table would illustrate the procedure for a Warehouse Management System
software development project.
Now, we may round up the software size to the next higher multiple of 5 units and say
the estimated size of the software project for development of software for Warehouse
Management System is 65 SSUs.
Now once having estimated the size of the software to be developed, we have to
estimate the software development effort.
As the work carried out at various stages requiring persons of different and varying skill
sets in software development life cycle, it is necessary to have different productivity
figures for each of the skill sets, namely
a. Requirements Analysis Effort – We use SSUs for estimating the effort required
for carrying out Requirements Analysis, which includes eliciting user
requirements, developing software requirements, preparation of necessary
documentation to capture requirements and peer review of the documentation
and fixing defects, if any. To convert SSUs into effort, we use productivity of
Requirements Analysis (say 6 hours per SSU rounded off to the next higher
multiple of 8)
b. Software Design Effort – We use SSUs for estimating the effort required for
carrying out software design including database design, architecture design, user
interface design, report design and program design, preparation of necessary
documentation, and peer review of design and fixing defects, if any. To convert
SSUs into effort, we use productivity of Software Design (say 8 hours per SSU
rounded off to the next higher multiple of 8)
c. Construction Effort – We use SSUs for estimating the effort required for
construction activity that includes coding, independent verification, independent
unit testing and fixing defects, if any. To convert SSUs into effort, we use
productivity of Construction (say 10 hours per SSU rounded off to the next higher
multiple of 8)
d. Testing Effort – We use SSUs for estimating the effort required to carry out
independent software testing. Software testing includes integration testing,
system testing and acceptance testing. To convert SSUs into effort, we use
productivity of Testing (say 4 hours per SSU rounded off to the next higher
multiple of 8)
The rounding off to the next higher multiple of 8 is to ensure that we arrive at a round
figure of person days. We may estimate in fragment of a person day, but in reality, any
fragment of a day would be wasted during execution.
Thus for the above project, let us arrive at the effort required for software development,
using the below table
Thus the effort in person days is 1,832. Now add the person days required for
administrative activities like Project Initiation, Project Planning, and Project Closure and
Project Management overhead, if necessary.
Now we may use this value to schedule the project and arrive at the final effort for
computing the cost of the project.
Q: Then does it mean, that one screen can have multiple Input Output Process and
Associated Elements?
A: Yes
Q: Are the weights for data elements and process elements to be used as they are or
can we customize them?
A: If one thing that characterizes software development, it is diversity. If you feel that
different weights are justified in view of the unique nature of your projects, you may
certainly do so.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Your feedback is gratefully solicited – please send it to murali@chemuturi.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>