This paper describes a way the COSMIC measurement method could be applied to measure the functional size of mobile apps.

1. Measure the functional size of a mobile app
Using the COSMIC functional size measurement method
Harold van Heeringen
Sizing Estimating and Control
Sogeti Nederland B.V.
Vianen, the Netherlands
harold.van.heeringen@sogeti.nl
Edwin van Gorp
Sizing Estimating and Control
Sogeti Nederland B.V.
Vianen, the Netherlands
edwin.van.gorp@sogeti.nl
Abstract— this paper describes a way the COSMIC [1]
measurement method could be applied to measure the functional
size of mobile apps. Mobile apps are a fairly new type of software
applications that are installed on mobile devices, usually a
smartphone or a tablet. There are some important differences
between traditional software applications and mobile apps, and
these differences are the reason that a measurer has to make a
number of assumptions and choices when doing the
measurement. In this paper, these assumptions and choices are
explained and the authors propose a way future COSMIC
measurements of mobile apps could be carried out. In addition,
an ‘approximate’ method is proposed that can be used to size
mobile apps in a fast and accurate way.
Keywords; Mobile apps; COSMIC; Functional size;
Approximate Method; Measurement.
I. INTRODUCTION
The IT industry changes rapidly and new types of
hardware, software architectures and applications emerge in a
rapid pace. Software development companies face the fact that
they need to adapt, in order to be able to deliver new types of
software development projects. They need to have the right
people (knowledge and skills) in their organization to adapt to
the new world, but also they need to stay competitive and try to
limit their risk when it comes to quoting for projects. Software
estimation, based on functional size, remains an important
activity, also in the ‘new world’ of software development.
This paper is about measuring the functional size of one of
these rather new types of software applications, the mobile app
[2]. Probably everybody in the modern world knows what a
mobile app is nowadays, but for those who have no clue, a
short explanation is given in the next section.
II. MOBILE APPS
Mobile apps are applications that can be installed on a
mobile device, like a tablet or a smartphone, and usually these
apps are connected to the internet through Wi-Fi, Bluetooth or
a cellular mobile data connection. Apps can be downloaded
and installed from an app store. There are two main app stores
available, the iOS app store for Apple devices [3], like the
iPhone and iPad, and the Google Play android app store [4].
Both app stores have more than 800,000 apps available for
download. A lot of these apps can be downloaded for free,
others can be bought for a (usually small) fee. There are many
different kind of mobile apps available, e.g. games, mobile
banking apps, weather apps, traffic apps, social media apps, et
cetera. Most apps connect the user real-time with the outside
world, where the user can find up-to-date information about
almost everything.
Apps integrate software with the use of hardware, like the
GPS sensor that enables the mobile device to exactly pinpoint
the location of the device on the globe. Another characteristic
of mobile apps is that they are usually controlled through a
‘touch screen’ user interface, where the user controls the
functionality of the app through touching the screen, tapping
visible controls and pinching text to make it larger or smaller.
The newest trend is the one of company proprietary apps
that can be downloaded from a company internal app store,
only by employees of that company. An example could be an
app that shows new messages on the intranet in an app on a
mobile device, or an app that shows the daily specials of the
company restaurant to the employees.
III. WHY ARE MOBILE APPS DIFFERENT?
Although Mobile apps could be regarded as a modern type
of a client-server architecture, they seem to be different from
traditional applications, because of a number of reasons, a few
of them being:
- The user can interact with the apps in more ways than in
traditional applications. For instance, the app can react
to changing the position (toggling) of the mobile device,
to shaking the mobile device and some apps can accept
voice messages (e.g. Siri [5]);
- Some apps behave to real-time events as well, like
moving of the mobile device, switching from Wi-Fi to
cellular and back or when the network is out of reach.
- Some of the data the app is using is stored on the mobile
device, and some may be in the cloud or on a back-end
system. The exact architecture may be very different for
each app;
- Apps must have functionality that handle interruptions,
like an incoming call.;

2. - There are usually important non-functional
requirements to which an app should comply, e.g.
security, performance, minimum data traffic, space
occupied on the device and consumption of battery
power.
There is a publication available that covers the functional
size measurement of mobile apps using the IFPUG [6] method,
published in the IFPUG guide to IT and Software Measurement
[7]. This paper focuses on the way a functional size
measurement can be carried out using the COSMIC method
and proposes an approximate method of sizing mobile apps in a
fast and accurate way.
IV. APPROXIMATE METHOD
Sogeti has developed an approximate COSMIC method to
determine the functional size of a mobile app quickly yet
accurately. This method is described in this section.
Basic assumptions
The approximate method to measure the functional size of
mobile apps is based on the COSMIC method. The following
additional and/or explicit basic assumptions also apply to this
method:
- A mobile app is considered to be an application layer
that is developed on top of one or more data layers (see
document [1], section 2.2.4). Whether such a data layer
is physically stored on the mobile device or on a central
server (or in a combination thereof) has no relevance to
the measurement;
- Logically, no persistent data is stored in the application
layer. Storing data on the mobile device to reduce data
traffic or to make it possible to work with the app when
no network connection is available is considered to be a
technical solution. As a result of this only Entry and
Exit data movements are identified when applying this
method;
- Within a mobile app, functional processes can use
certain process data that is spontaneously present, e.g.
system date and -time, the current GPS location, etc.
(see document [1], section 4.1.2, Entry rule C);
- Mobile apps are considered to be business applications.
Therefore one Exit data movement should be identified
for all application error messages in any one functional
process (see document [8], section 4.4.7);
- Because application error message can come from the
data layer, one Entry data movement should be
identified for all application error messages in any one
functional process as well (see document [9], section
3.2).
A. Measurement Strategy
The measurement strategy phase for this approximate
method does not differ, in principle, from the ‘standard’
measurement strategy phase of the COSMIC functional size
measurement method. For this approximate method, it is also
necessary to consider the purpose and scope of the
measurement and to identify the functional users and the level
of granularity that should be measured, as described in chapter
2 of document [1]. It is important however to carry out this
phase with the basic assumptions as described above in mind.
B. Mapping phase
The mapping phase for this approximate method does not
differ, in principle, from the ‘standard’ mapping phase of the
COSMIC functional size measurement method. For this
approximate method, it is also necessary to identify the set of
functional processes of the piece of software to be measured
and the objects of interest and the data groups referenced by the
piece of software to be measured, as described in chapter 3 of
document [1]. It is important however to carry out this phase
with the basic assumptions as described above in mind.
C. Measurement phase
The measurement phase of this approximate method
consists of two steps:
1. Identifying the type of each functional process;
2. Quantifying the parameters involved for the identified
type of functional process.
Step 1: Identifying the type of each functional process
This step is carried out by looking at the primary intent of
the functional processes that are identified in the mapping
phase. Each functional process can be characterized by its
primary intent to be of one of the following types:
- View functionality: the primary intent of this type of
functional process is to present data to at least one of the
functional users;
- Data manipulation: the primary intent of this type of
functional process is to add information to, change
information in or delete information from the persistent
data storage;
- Enquiry functionality: in section 4.1.5 of document [8]
it is explained that a FUR to update or delete persistent
data requires two separate functional processes. One for
the actual update/deletion (a functional process for data
manipulation as described above) and one which reads
and displays the data that needs to be updated/deleted.
This second functional process is characterized as an
enquiry functional process;
- User supporting functionality: this type of functional
process can be described as a function showing a list
from which a user can make a selection (e.g., a selection
screen, pick function, pick list, list box, or pop-up
function). When this type of functionality is available
on a screen but the user is not obliged to use it (in other
words: the user can fill all fields on the screen without
using this functionality), than this type of functionality
should be regarded as a separate functional process.
When the user chooses to use the non-mandatory
selection screen, he actually triggers a new functional
process. And this functional process is characterized as
user supporting functionality. Note: if the selection

3. screen is the only way to fill the corresponding field,
than the usage of the screen is mandatory and therefore
part of the data manipulation functional process in
which it is offered;
- Special functionality: there are some special types of
functionality in addition to the abovementioned generic
types that need to be distinguished for this approximate
method. These types are:
o Dynamically generated menus
o Log in and log out functionality
o Help functionality
o Invoking external functionality
Step 2: Quantifying the parameters involved for the identified
type of functional process
When all functional processes are characterized, the
parameters involved for each functional process need to be
quantified in order to find the (approximate) functional size of
the mobile app.
2a: View functionality
A basic view functional process has a value of 6 CFP:
E Start entry
X Question for information to the data layer
E Receiving data
E Receiving application error messages
X Show data
X Show application error messages
- The basic process includes the viewing of data attributes
that belong to a data group of one object of interest.
They are obtained en received from the data layer and
displayed to the functional user.
- The ability to change the view of the displayed data
(e.g. by filtering or sorting the data) does not lead to the
identification of additional data movements. This
merely involves the so-called control commands (see
section 4.1.10 of document [1]).
A basic view functional process displays data to the user.
For each additional data group that is displayed, the size of
the functional process is increased with 2 CFPs:
E Receiving data
X Show data
- For each additional data group that can be viewed
within the same functional process, 2 additional data
movements are identified. One data movement for
receiving the data from the data layer and one data
movement for presenting the data to the functional user.
A separate data movement for the question for
information to the data layer is not necessary, the
question for information has the same data attributes no
matter how many data groups are eventually involved.
- An additional data group is displayed when:
o A different object of interest is queried or
o The same object of interest is queried but for a
different set of data attributes. This occurs for
example when view functionality is used, by
persons with different authorization profiles,
wherein dependent on the profile different data
attributes are shown.
- No additional data group is identified when a functional
process offers several display options to present
different sets of data attributes of the same object of
interest to one and the same user, where this user can
switch between the display options by pressing (scroll)
buttons, selecting different tabs or tilting the mobile
device.
Example: when a functional process shows transactional
data in a list (in portrait mode) and offers the user the
possibility to view more attributes of the same object of
interest by tilting the mobile device, this still concerns
viewing the same data group.

4. This functional process displays a transaction overview. When tilting
the mobile device, more data attributes are shown. This is considered
as displaying a single data group as tilting the device is considered as
a control command.
For each data group that shows calculated or derived data,
the size of the functional process is increased with 1 CFP:
X Show data
- If a data group is shown that comprises of calculated
and/or determined data, one additional data movement
is identified. A (sub)total under a list of retrieved data is
a good example here.
Summary: for each functional process with the primary
intent to present data to at least one of the functional users, the
functional size is found using this formula:
4 + (2 * number of data groups derived from the data layer)
+ (1 * number of data groups with calculated and/or
determined data)
2b: Data manipulation functionality
A basic data manipulation functional process has a value of
4 CFP:
E Start entry
X Providing information to the data layer
E Receiving application error messages
X Show application error messages
- The basic process includes adding data attributes to,
changing data attributes in of deleting data attributes
belonging to a data group of one object of interest. The
data attributes involved are provided to the data layer,
which takes care of processing them.
For each additional data group that is manipulated, the size
of the functional process is increased with 2 CFPs:
E Entering data
X Providing information to the data layer
- For each additional group of data attributes that can be
manipulated within the same functional process, two
additional data movements are identified. One data
movement for entering the data by the user and one data
movement for providing the data to the data layer;
- An additional data group is manipulated when:
o A different object of interest is manipulated or
o The same object of interest is manipulated but
the set of data attributes which is manipulated
differs from another set of data attributes from
the same object of interest that is manipulated
within the same functional process. This
occurs for example when data manipulation
functionality is used, by persons with different
authorization profiles, wherein dependent on
the profile different data attributes can be
manipulated.
- It is recognized that it is not a regularity that for every
manipulated data group both an Entry and an Exit data
movement will always exist. For this approximate
method it is however assumed that this is the case;
- It goes without saying that for functionality to delete
data, it is impossible to identify two data groups of the
same object of interest within one functional process.
For each data group that is shown to the user within the
manipulation process, the size of the functional process is
increased with 3 CFPs:
X Question for information to the data layer
E Receiving data
X Show data
-
- If additional data is displayed during the data
manipulation process, based on the data that is entered,
than additional data movements need to be identified for
asking for, receiving and displaying the data.
Example: during the addition of an address, the name of
the street and the town are shown, based on the postal
code and house number that are entered, this concerns
viewing the object of interest postal code data within the
process of adding the address.
- If mandatory user supporting functionality (a selection
screen, pick function, pick list, list box, or pop-up
function) is offered to the user within the data
manipulation process, this should also be considered as
displaying additional data. For non-mandatory user
supporting functionality, a different type of functional
process is distinguished.

5. If using a pick list like the one above is considered as a separate
functional process or as part of the data manipulation functional
process in which the pick list is invoked, depends on whether the usage
of the pick list is mandatory or not.
For each validation for which referential data is needed, the
size of the functional process is increased with 2 CFPs:
X Question for information to the data layer
E Receiving data
-
- If a particular data validation is explicitly described in
the functional documentation of the mobile app and for
that validation referential data is needed from the data
layer (i.e. the referential data consists of data attributes
of an identified object of interest), two additional data
movements need to be identified (one for the question
for information and one for receiving the data);
- If the validation is executed by the data layer, the same
functional size is applicable. In that case, there is one
data movement for asking for a validation and one data
movement is for receiving the result.
Summary: for each functional process with the primary
intent to manipulate data, the functional size is found using this
formula:
2 + (2 * number of data groups that are manipulated) + (3 *
number of displayed data groups) + (2 * number of validation
with referential data)
2c: Enquiry functionality
Enquiry functionality is identical to view functionality.
Everything that is described in section 2a also applies to
enquiry functionality.
2d: User supporting functionality (non-mandatory)
User supporting functionality, which the user is not
required to use, is identical to view functionality. Everything
that is described in section 2a also applies to non-mandatory
user supporting functionality.
2f: Special functionality - Dynamically generated menus
Main and/or sub menus that are generated dynamically
(based on authorizations (login status and/or user roles) or
based on data attributes associated with an object of interest)
are identical to view functionality. Everything that is described
in section 2a also applies to dynamically generated menus.
A menu is not dynamically generated when it looks exactly
the same under every conceivable circumstance. In this case,
all the menu items are always displayed in the same way, and
any authorization limitations are checked only after a menu
option is selected by the user. If a menu can be displayed
differently based on authorizations or data attributes associated
with an object of interest, than the menu should be considered
as view functionality that displays the authorization options to
the user.
A dynamically generated menu. The 5 options can be either shown in
colour or greyscale, depending on the authorization level of the user.
2g: Special functionality - Log in and log out functionality
A log in functional process always has a value of 5 CFP:
E Start entry
X Providing credentials to the data layer
E Receiving log status
E Receiving application error messages
X Show application error messages
- When a user logs in, log in credentials (usually
username and password) are entered to be verified. This
verification is done by or against data from the data
layer, so the credentials are provided to the data layer.
The data layer passes the log status (logged in or not
logged in, a possible role etc.) back to the app. This
status is not explicitly shown to the user, it is or can be
part of the application error messages data movements.
- The log status is considered to be process data that is
spontaneously present in all other functional processes
of the app.
- A log in functional process is only included in the
functional size measurement when it is explicitly

6. described in the functional documentation of the app
and when it was or needs to be developed especially for
the app.
A basic log out functional process has a value of 2 CFP:
E Start entry
X Show application error messages
- When a user logs out, only the process item log status is
changed. Therefore, no data moves across the boundary
of the mobile app layer, except for the start entry
(representing the triggering event for logging out) and
possible application error messages.
- A log out functional process is only included in the
functional size measurement when it is explicitly
described in the functional documentation of the app
and when it was or needs to be developed especially for
the app.
When logging out is recorded in the data layer 2 additional
CFPs need to be identified:
X Providing credentials to the data layer
E Receiving application error messages
- If an explicit functional reason is described why logging
out must be recorded in the data layer (e.g. when there
is a FUR (in the app or in a back office application) for
an overview of users that used the app), 2 additional
CFPs need to be identified.
2h: Special functionality - Help functionality
According to section 4.4.6 of document [8], a functional
process needs to be identified for any type of help functionality
that is present in the app. Such a functional process is identical
to view functionality. Everything that is described in section 2a
also applies to help functionality.
Help functionalities are of the same type if they can be
regarded as different occurrences of the same output-type.
This help function has four occurrences of the same output-type. One
help function should be identified for the functional size measurement.
Given the above, the appearance of a help function is
irrelevant for the measurement. This also means that if a help
function is implemented differently, still everything that is
described in section 2a applies for this functionality (e.g. help
texts can be stored as documents and opened in an application
associated with the document type once the user wants to read
the help text from within the app. This is much alike invoking
external functionality (see 2i) but because it ultimately is an
implementation of help functionality, it needs to be measured
as being such. Only when (help) text, which is implemented in
such a way, can be used from within more than one app or
application, this should be considered as invoking external
functionality. As long as the text exclusively belongs to the app
being measured, it must be identified as help functionality.
2i: Special functionality - Invoking external functionality
It is not unusual that external functionality is invoked from
within a mobile app. This external functionality may be another
app, a web page in a browser or a document in an external
application (other than in the sense of help functionality, see
2h) or otherwise. Also, when an app on a smartphone calls a
certain telephone number as a result of clicking an option
within an app, this is considered as invoking external
functionality.
Invoking such functionality is considered as the start entry
(triggering event) of a functional process that is outside the
scope of the app being measured. And therefore, no CFPs are
awarded for such functionality.
D. Epilogue
The approximate method, as described above, is based on
the COSMIC Functional size measurement method. It, above
all, is intended as guidelines on how to apply the ‘standard’
COSMIC method quickly yet correctly when measuring mobile
apps. In case of doubt and uncertainty all that is written about
the application of the method by the Common Software
Measurement International Consortium is a directive.
V. REFERENCES
[1] Common Software International Measurement Consortium, The
COSMIC Functional Size Measurement Method, version 3.0.1,
Measurement Manual (The COSMIC Implementation Guide for
ISO/IEC 19761: 2003), May 2009, http://www.cosmicon.com
[2] Mobile apps, http://en.wikipedia.org/wiki/Mobile_app
[3] iOS app store (Apple), http://en.wikipedia.org/wiki/App_Store_(iOS)
[4] Google Play (formerly known as the Android app market)
http://en.wikipedia.org/wiki/Google_Play
[5] Siri personal assistant app, http://en.wikipedia.org/wiki/Siri_(software)
[6] IFPUG, International Function Point User Group. Function Point
Counting Practises Manual. 4.3. 2009. http://www.ifpug.org
[7] The IFPUG Guide to IT and Software Measurement, CRC press, 2012,
ISBN 978-1-4398-6930-7
[8] Common Software International Measurement Consortium, The
COSMIC Functional Size Measurement Method, version 3.0, Guideline
for Sizing Business Application Software, version 1.1, May 2009,
http://www.cosmicon.com
[9] Common Software International Measurement Consortium, The
COSMIC Functional Size Measurement Method, version 3.0.1,
Guideline for Sizing Service-Oriented Architecture Software, version
1.0, April 2010, http://www.cosmicon.com