Software Size Evaluation Using Object Points

Thandar Zaw, Khine Khine Oo

University of Computer Studies, Yangon, Myanmar
[email protected]

Abstract engineering requires that the promise of large-scale

software reuse be realized in a practical way. [7].
Object-oriented technologies have emerged as a Reuse efforts date back to 1994 when some divisions
dominant software engineering practice. The growth began to develop reusable components in Instrument
of Object Oriented practices has required software Basic, Objective-C, and C++.
developers and they have been estimating the size of For the effective management of the resources
their development projects. Several attempts have in a project, it is necessary to estimate the function
been made to categorize the complexities of software points of a system in the requirements, analysis and
systems, and the complexity of software architectures design phases. At the requirements phase the
is a subject of ongoing research. Software reuse measurement is completely from users’ perspective.
limits the amount of new software that needs to be Analysis phase is not only from an analyzers’
produced. Most method for estimation effort requires perspective, but also includes users’ perspective and
an estimate of the size of the software. The size of at the design phase the measurement is completely
software is estimated by using complexity weight of from a designer’s perspective.
object points. Object-oriented software is the process In recent years, Object Oriented technology
of systematically building the software systems using has emerged as a dominant software engineering
objects, types and classes. This paper presented the practice. As it happens with many new technologies,
calculation of reuse object points in the modified the growth of Object Oriented practices has forced
software application by using object point estimation software developers and their managers to rethink the
model. This size of the software code is estimated by way they have been estimating the size of their
using COCOMO-II object point analysis model. The development projects [5]. To measure OO software,
normal size estimated after object point analysis is the main components to be considered are raw
finalized to calculate the adjusted object points in functionality of the software, communication among
reusing modified software application. objects and inheritance.
In this paper, a well defined estimation model
Keywords: Effort estimation, Object point in COCOMO-II is proposed which can be used to
analysis, COCOMO-II estimate the reuse object size required for developing
the next software application. This paper provides the
adjusted object point by estimating the sub-program
(client) to refer the reference program (server).The
1. Introduction model calculation is designed to help project manager
to estimate effort at the very early stage of
Software cost estimation is an important requirement analysis. For the size estimation of the
activity during its development. Cost has to be program, the different techniques such as function
estimated continually during all the software point analysis, object point analysis and use case
development phases. Software cost estimation analysis are used.
depends on the nature and characteristics of a project The rest of the paper is organized as follows.
[9]. At any phase, the accuracy of the estimate In Section 2, we reviews related work. We show the
depends on the amount of information known about general architecture of the proposed system in
the final product. Section 3. Section 4 gives determine object points
Software size estimation is mainly dependent and a description of estimation of size. Section 5
on its size. Boehm [2] has developed Constructive describes experimental results of this system and
Cost Model (COCOMO) to establish a relationship section 6 draws some conclusion and future work.
between the cost and size of software. The main
disadvantages of using Lines of Code (LOC) as a unit
of measure of software size are the lack of a 2. Related Work and Background
universally accepted definition and language
dependency. As software grew in size and importance, it
For most companies trying to improve their also grew in its complexity, making it very difficult
software development performance, objects and to accurately predict the cost of the software
software reuse must become key parts of their development. The better accuracy in estimation can
software engineering strategy. Succeeding with be achieved by developing the domain based useful
industrial-strength object-oriented software models that constructively explain the development
life cycle and accurately predict the effort of tables. Figure1 represent the proposed system
developing the software. [8]. architecture.
Over the years, different approaches have been
suggested for the estimation of different types of
Start
projects. These projects are categorized as
development projects, maintenance projects and
support services by keeping in mind that these Source
activities never occurred simultaneously. Most of Program
these approaches estimate the effort based on the size
of the development project and same approach is also
Read Program
used in estimating the effort of projects.
Teologlou [5] has proposed Predictive Object
Points (POPs) based on the class hierarchy and Extract Module
weighted methods per class. From the class hierarchy,
the counts of number of top level classes, average Identification Object
Point
depth of inheritance tree and average number of
children per base class are considered. Methods are
weighted according to five types (Constructors, User Interface User Interface 3GL component
Destructors, Selectors, Modifiers and Iterators). At screen report (object oriented function)
the design phase, the information about the data,
aggregation and polymorphism is available but, this Reference source
Module Generator
information is not considered by the POPs measure. code program
IFPUG [1] considered classes as logical files
and methods as transactional functions from user’s
Define type of classes
perspective during the analysis as well as design based on object point
phases. This counting procedure lacks the ability to
measure the inheritance and communication among
objects. Server class Client class
Baresi et al. [3] investigated whether estimated 3GL component
(reuse direct (within reference
effort provided by inexperienced developers can be (object oriented function)
reference program) program)
used to estimate actual effort. It was quite clear that it
is possible to use the estimated values as predictors
for the actual ones; however other variables, such as Calculate Complexity level
size, also need to be incorporated to the model to
make it more realistic and meaningful. Calculate Number of Object
Reifer et al [10] proposed an extension to the Point
COCOMO-II model by introducing WEBMO model.
Reifer proposed different cost drivers by keeping in Calculate Adjusted Object
Point
mind the demands of web projects. In WEBMO, size
is measured by using analytical Halstead’s formula
for volume. End

3. Proposed System Architecture Figure.1. Proposed System Architecture

Different reuse attributes are visible when

reuse is examined from different perspectives. In our
system, we consider a system where individual
4. Estimation of Size
modules access some set of existing software entities.
A program unit (header File) reused is considered as For Size calculation, we have opted for the
a server and the unit accessing that program unit Object point analysis. Object points are a measure of
(Program File) is considered as client. Reuse can be the size of computer application and the projects that
observed from the perspectives of the server and the build them. The size is measured from a components
client. Each of these perspectives is relevant for the point of view. It is independent of the computer
analysis and measurement of reuse in a system. A set language, development methodology, technology or
of potentially measurable attributes can be derived capability of the project team used to develop the
for Object Oriented Programming Language based on application.
profiles of reuse from each perspective. As a result,
we can define measurement of object points that can
be derived; they are presented in a set of complexity

2
4.1 Identify System Boundaries 4.4 Complexity of Each Object

Identification of system boundary means All the objects are characterized by the
limiting the scope of development. We can define attributes they posses and their behavior in different
what application is to be developed and what is environments. The complexity if each object also
outside the scope of development. This will help to depends upon how it is interlinked with other objects
find the application objects to be included in the and number of instances it uses. Objects include
system to count the total Object Points (OP).For each screens, reports and modules in third generation
features of the system, we can easily determine the programming languages. Object Points are not
corresponding object points and their scope in the necessarily related to objects in Object Oriented
system. Programming. The numbers of raw objects are
estimated, the complexity of each object is estimated,
and the weighted total (Object-Point count) is
4.2 Determine Object Points computed. The percentage of reuse and anticipated
productivity are also estimated.
The Object Points (OP) reflects the
countable objectivity provided to the user by the Table 1: Object Point Analysis-Screen
application file/tool. Each tool has certain defined
ways using which we can quantify these object points.
The defined specific Objects should be evaluated in
terms of what is being delivered. This means count
only user defined and requested Objects. Do not
include any of the existing objects and trivial objects.
Object Point is the total of object points for all the
objects delivered in any file. Identify the different
objects from the business user’s point of view. In
each application, there are two types of objects, one
which are directly visible through user interface and
others which are not directly visible. The following
different categories of object have been identified: Table 2: Object Point Analysis-Reports

 User Interface Screens

o Data Forms
o Message Boxes
o Error Messages
o Interactions with Databases
o No. of Java Script functions/
operations/Validations
o No. of style classes uses
 User Interface Reports
o Printed reports
o Graphics Analysis Reports

4.3 Object Points in Object Oriented Table 1 and 2 represent the Object Points analysis for
Design Screen and Reports respectively. In each table, the
server means the number of data using in conjunction
In Object Points procedure, methods and with the SCREEN or REPORT in header file and the
data are separated while calculating the functionality client means the number of data using in conjunction
of software. But a class encapsulates both data and with the SCREEN or REPORT in program files
methods. So, complexity of object oriented implies
that both data and methods should be considered as a 4.5 Complexity Weight
single entity. The functionality of the object oriented
software is decided according to the data processed As Table 1 and 2 in this section, design of
by the functions and communication among objects. the problem should be considered to estimate the
From the user’s perspective, we calculate class complexity of each object. Then each object is
hierarchies, inherited data, and aggregation and classified into simple, medium and difficult
method signatures. complexity levels depending on values of

3
characteristic dimensions defined on the following
table 3: %reuse= (used components/total components)/100
…(1)
Table 3: Object Point Analysis-Complexity Weight The inputs are the NOP (Number of Object
Points) of reference file. The following formula is
used to estimate adjusted object points in our
subprogram.

Adjusted OP=NOP* (1-reuse%/100) …(2)

5. Experimental Result

In this experiment, data is collected from the

two different types of file. Reference file contains all
screen , report and 3GL components function , is
called reference file(header file). Client files contain
some function reuse the reference file, is called class
4.6 Calculate Object Points file. This paper tested 3class file refer to the same
referenc file. Different class files have vary in the
To the total object points in a particular complexity weight in their implementation. To
feature or an application, we add up all the objects demonstrate the measurement, we designed and
multiplied by their complexities in it. This gives us implemented the prototype C++ language. Firstly, we
the total number of object points in the application. estimate the number of screens, reports and 3Gl
Each application involves certain redundant features. components from the header file that will comprise in
Further, object oriented development methodology this program file.Second, we classify each object
inherently promotes code reuse. We consider code instance into simple, medium and difficult
reuse as an important parameter while calculating complexity levels depending on vales of
total project points. Although Code reuse parameter characteristic dimensions using Table 1 and 2. Third,
vary from application to application and also depends we weight the number in each cell using the Table 3.
upon the design of an application but still following The weights reflect the relative effort required to
factors may help us to determine this parameter: implement an instance of that complexity level.
 Number of views Screen Fouth, we determine object points that add all the
 Number of printed reports weighted object instances to get one number, the
 Number of function enhanced object-point count.Fifth, we estimate the percentage
 Amount of code used from previous application of resue you expect to be achieved in next program
having same features file, and then we will compute the adjusted object
According to table 1, for example, we point to be developed in each program file.
calculate one of program files has number of views
screen (screen objects) is less than three if this object Client 1:
is less than four the total of header file and program 2 screens: 1 Simple+2 Difficult
file and less than two in these two files, is called as 60 3GL components: 60 functions
“Simple” type. Others type of objects is calculated in
this same way. According to table 2, for example, we 1 Simple screen *1 =1
calculate one of program files has number of sections 2 Difficult screen *3 =6
(report functions) is less than two if this object is less 60 3GL component *10 =600
than four the total of header file and program file and NOP(number of Object Point)=607
less than two in these two files, is called as “Simple” %reuse= 2.970
type. Others type of objects is calculated in this same Adjusted Object Point(AOP)=588.97
way.
To evaluate complexity weight, if the type Client 2:
of screen objects is “Simple” type, we multiply one 1 screens: 1 Simple
with these objects. If the type of report objects is 22 3GL components: 22 functions
“Simple” type, we also multiply two with these
objects. Especially, the type of 3GL components has 1 Simple screen *1 =1
only “Difficult” type; we multiply ten with these 3GL 22 3GL component *10=220
objects. NOP(number of Object Point)=221
Finally, the effect of reuse% is taken the %reuse= 10
percentage of screens, reports, and 3GL components Adjusted Object Point(AOP)=198.9
reused from header file.

4
 [7] I.Jacobson, M.Griss and P. Jonsson,”Software
Client 3: reuse: Architecture, process and organization for
1 screens: 1 Simple business success”,1997.
2 report: 2 Simple [8] N. Aggarwal, N. Prakash and S. Sofat, “Content
31 3GL components: 31 functions Management System Effort Estimation Model
based on Object Point Analysis”, International
1 Simple screen *1 =1 Journal of Computer Science and Engineering,
2 Simple report *2 =4 2008.
31 3GL component *10=310 [9] P. Jalote. “An Integrated Approach to Software
NOP(number of Object Point)=315 Engineering”. Narosa Publishing House, New
%reuse= 6.0606 Delhi, India, 1998.
Adjusted Object Point(AOP)=295.909 [10]Reifer, D.J., “Web development: Estimating
quick-to-market software”, IEEE Software, Nov-
Dec 2000.
6. Conclusion [11] S.Axwl, “Position Paper: Towards Complexity
An organization can also use the reuse Levels of Object Systems Used in Software
measures to monitor the success of a reuse program Engineering Education”,
in promoting reuse in development. The measures
can quantify precisely how much percentage of reuse
is taking place. Developers can use the reuse data and
representations to produce customized project to
satisfy specific goals. In this paper, object points
defined screens, reports and 3GL components in
testing program files. This paper calculates the
number of object points by analyzing the complexity
of weights for all objects. The percentage of reuse
estimated in header file and program files you expect
to be achieved in next program file, and then we
computed the adjusted object point to be developed
in each program file. Reuse measurement will also
help users to develop new software that is easily
reused. This system will use object point estimating
technique for cost effort approach. Currently, this
paper developed for measuring reuse components in
programs implemented in C#.

References
[1] B. W. Boehm. “Software Engineering
Economics”,PrenticeHall, Inc., Englewood Cliffs,
New Jersey, USA, 1981.
[3] Baresi, Li, Morasa, S., & Paolini, P., “An
empirical study in the design effort for web
applications”, Proceedings of Web Information
System Engineering, 2002.
[4] D. Janaka Ram and S.V.G.K. Raju, “Object
Oriented Design Function Point”, Distributed
and Object Systems Lab, Indian Institute of
Technology Madras, IEEE, 2000.
[5] G. Teologlou, “Measuring object oriented
software with predictive object points”, In 10th
Conference on European Software Confrol and
Metrics, May 1999. Available at
http://www.escom.co.uk/publications.
[6] IFPUG. Function Point Counting Practices: Case
Studies Release 1.0 - Case Study 3 - Object
Oriented Analysis, Object Oriented Design.
International Function Point Users Group,
Westerville, OH, 1996.