O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
Measure the functional size of a mobile app 
Using the COSMIC functional size measurement method 
Harold van Heeringen 
Si...
- There are usually important non-functional 
requirements to which an app should comply, e.g. 
security, performance, min...
screen is the only way to fill the corresponding field, 
than the usage of the screen is mandatory and therefore 
part of ...
This functional process displays a transaction overview. When tilting 
the mobile device, more data attributes are shown. ...
If using a pick list like the one above is considered as a separate 
functional process or as part of the data manipulatio...
described in the functional documentation of the app 
and when it was or needs to be developed especially for 
the app. 
A...
Próximos SlideShares
Carregando em…5
×

Van Heeringen and van Gorp - Measure the functional size of a mobile app using the COSMIC FSMM

300 visualizações

Publicada em

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

Publicada em: Negócios
  • Seja o primeiro a comentar

Van Heeringen and van Gorp - Measure the functional size of a mobile app using the COSMIC FSMM

  1. 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. 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. 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. 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. 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. 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

×