This presentation discusses the nuances of developing a functional size for mobile apps with components on a handset and in the cloud. Functional size is critical for estimating and portfolio management. Function point analysis is a service of David Consulting Group.
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
Experience This... Counting an Apple iPhone Application
1. ISMA 7: Experience This…
Counting an Apple iPhone Application
The David Consulting Group
Tom Cagley, CFPS
VP of Consulting
Toni Ramos, CFPS
Consultant
We will look at the Mobile App Experience Tremont and compare it to the general concepts of a client server application.
At the highest level when comparing a Mobile app to a client server application things are generally similar.Client Server - very traditional and something people are generally comfortable with. Client - Primary point of access for the everyday user Middle Tier – Business Rules, Server Layer - Data StorageMobile App – new and considered complex, may pieces, everything is scattered Device - Also the primary point of access for the everyday user May have unique rules and requirements May require unique coding for each type of device Administration - Also the Business Rules Engine where you create users, user access May be the only point of data entry Cloud – Data storage, this is also where there is access to external app, Google Maps, Websites. The cloud is always this big ambiguous thing, can be somewhat intimidating, But if you narrow your focus a bit and think of it more as a share utility (gas, water) They you only have to focus on what you use and the rest is unimportant.
Client Server – very traditional, so you get traditional documentation.Mobile App – Many of the traditional documentation is not available. It typically just doesn’t fit. A majority of the end user functionality is counted via download and useThe amount of documentation provided is directly connected to the Development Life Cycle (short), as well as the developer themselves (usually not business driven)There is also some difference in vocabulary, for example wireframe vs. screen design.Wireframes typically focuses on what is to be displayed and the associated functionality and rules. And have less focus on the look as they are typicall designed via templates.The typical create/update/delete is often not available to the end user, thus often not documented at allAlso keep in mind that vocabulary may vary from one developer to another similar to the vocabulary from one business entity to another.
Often the first instinct is to create a boundary around each piece.Some would even consider a boundary around each type of device. (Tablet, Ipad, Iphone, Droid) or based on market (Google Play/iTunes)Because of the differences between the look and feel of each, as well as the capability for some devices to store a local copy of the data.This to must be a coherent body of functionality, which encompasses all 3 layers.
Data layouts are pretty much the same regardless of the type of application / environment the difference are how the data is stored and used. The basic IFPUG Rules usually apply.Data will be held on the server, and may also be held on a client/middle tier for update and load to the server in batch/on demand/real time.In all instances the data is logical one set.
Mobile apps can also have the same complexities. Data layers are similar. Local copy stored on the mobile device for off line use. Mobile app data resides on the cloud
(Android versus IPhone design).These are the transactions that are most easily seen since they are commonly used and available to any one who downloads. Functionalities that are available to phone that may not work the same on a tablet We’ll see an example of this in the next slide. (i.e. Call Organization)First Screen is a menu screen which is not dynamically populated (hard coded) and not countable.
Displaying the organization list where the RET is the Organization and ILF DETs are the Organization Name and Category.Display Details where the RET is the Organization ILF and DETs are Organization Name, Hours, Address Line, City, State, Zip, Description, Thumbnail image, Ability to specify an action.We also have the additional transactions that send data to other applications within the device or to the web.Call the Location 1 RET Organization ILF and the DET is Phone Number sent to the Phones Call AppMap the Location 1 RET Organization ILF and Address Line, City, State, Zip, image returned. For this app the map is not counted as in the Semantys presentation as the functionality is not part of this app, but rather Google maps.We also need to consider that even though the look and feel may be different on each device that the functionality remains the same. No need for unique transactions for each. Likewise if a functionality is not available for a device (i.e. call location on a tablet) or perhaps it simply send to a different application like Skype.
Here we have some similar transaction that trigger an action I have selected a few examples, we must keep in mind what the action is logically doing.Website – not counted, this is navigation to the organizations website, nothing more than a hyper link.Events at this - Queries the Event ILF for events with appropriate organization ID and displays the results. 4 DETs Event Name, Organization, Date Held, Time HeldCheck In at this location – sends the DETs Address, City, State, Zip from the Organization ILF and send to another applicationEmail to a Friend – sends the Organization Name, Address, City ,State, Zip to the email application available on the device.
View Todays Event - 2 RETs Events ILF and Calendar EIF (from phone) 5 DETs Current Date, Event Name, Organization, Date Held, Time HeldView Upcoming Events – 1 RET Events ILF and 4 DETs Event Name, Organization, Date Held, Time HeldView Event Details – 1 RET Events ILF and 6 DETs Event Name, Organization, Date Held, Time Held, Description, Ability to specify an action.Other event at this location – Not Counted, Same logical process as View upcoming events, with location filter.
Maintaining the Cloud Data . In this case is done via a webs siteLevels of users Level 1 Purchasers of the app Create organization/user accounts Can create profiles and events Level 2 Organization Subscriptions Can create profiles and events Can create account specific to organization Level 3 App users View only access
FTR is Organization ILF DETs are Organization Name, Address, City, State, Zip, Phone, Category, Subscription Type, Description, Special Offer, Website, Map, ability to specify an action.
Event ILF - DETs are Event Name, Website, Description, Start/End Dates, Organization, action key.
Create Account User ILF – DETs User Name, Email, Password, Role, Organization, action. (create password part of the create User EP)View/ Update – User ILF – DET User Name, Role, Organization, action. (separate transaction for change password)Change Password – User ILF – DETs User Name, Old PW, New PW, action
The differences are minor most are due to development requirements, for a mobile app they tend to be a bit less stringent.For Example Installation and Operational Ease are higher for client server due to stronger user specificationsAnother place client server draws additional TDI is in End User Efficiency and Facilitate Change. In this case the mobile app does not easily have the ability for complex ad hoc qurey or things like hot keys.