ISMA 7: Experience This…Counting an Apple iPhone Application                 The David Consulting Group                   ...
#DavidConsultGrpMobile Apps: Client Server or Something Else?  An example:  Count an IPhone Application and compare it to ...
#DavidConsultGrpMobile Apps: Client Server or Something Else?Mobile App                         Client Server• Multiple La...
#DavidConsultGrpDocumentationClient Server                             Mobile App• User Guides                            ...
#DavidConsultGrpBoundaries: Client Server• The application or part of the application enclosed by the  boundary must be a ...
#DavidConsultGrpBoundary: Mobile App• Does the introduction of a mobile device change the  definition of where the boundar...
#DavidConsultGrpData: Client Server  • Data can be held and maintained in multiple instantiations    in any of the layers....
#DavidConsultGrpData: Mobile App  The Cloud  • Data can also be held and maintained in multiple    instantiations  Mobile ...
#DavidConsultGrpTransactions: Client Server  Business enter the application from the client and engages  the logic and dat...
#DavidConsultGrp  Transactions: Mobile AppFront End utilizing mobile deviceThe client or app leverages the data fromthe cl...
#DavidConsultGrp  Transactions: Mobile App  Transaction Function                       FTRs                DETs     Name  ...
#DavidConsultGrp  Transactions: Mobile App  Transaction Function                       FTRs                 DETs     Name ...
#DavidConsultGrp  Transactions: Mobile App Transaction Function                      FTRs                 DETs    Name    ...
#DavidConsultGrpTransactions: Mobile App  Back End leveraging a WEB / Client Server interface  • Has several variation of ...
#DavidConsultGrp   Transactions: Mobile App    Maintain an OrganizationTransaction Function                     FTRs      ...
#DavidConsultGrp   Transactions: Mobile App    Maintain an EventTransaction Function                     FTRs             ...
#DavidConsultGrp   Transactions: Mobile App    Maintain a UserTransaction Function                     FTRs              D...
#DavidConsultGrp  GSC      Client Server                                                           Mobile AppSystem Charac...
#DavidConsultGrpConclusion and Final Comparison  • Mobile App or Client Server . . .     • No real counting difference    ...
#DavidConsultGrpQuestions . . .                               Tom Cagley, CFPS                               VP of Consult...
Upcoming SlideShare
Loading in …5
×

Experience This... Counting an Apple iPhone Application

917 views
881 views

Published on

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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
917
On SlideShare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • 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.
  • Experience This... Counting an Apple iPhone Application

    1. 1. ISMA 7: Experience This…Counting an Apple iPhone Application The David Consulting Group Tom Cagley, CFPS VP of Consulting Toni Ramos, CFPS Consultant
    2. 2. #DavidConsultGrpMobile Apps: Client Server or Something Else? An example: Count an IPhone Application and compare it to a general client server application. Potential Issues: • Documentation • Boundaries • Data • Transactions Thanks to EXP for Mobile App Experience Tremont©2012 David Consulting Group 1
    3. 3. #DavidConsultGrpMobile Apps: Client Server or Something Else?Mobile App Client Server• Multiple Layers • Multiple Layers • Device • Client Layer • Administration • Middle Tier Layer • Cloud • Server Layer©2012 David Consulting Group 2
    4. 4. #DavidConsultGrpDocumentationClient Server Mobile App• User Guides • App Download• ERD • ERD• High Level Design • Wireframes Differences in how the work is done (SDLC) and vocabulary can also result in variations of the documentation.©2012 David Consulting Group 3
    5. 5. #DavidConsultGrpBoundaries: Client Server• The application or part of the application enclosed by the boundary must be a coherent body of functionality• Persistent storage is not considered a user of the software and is therefore on the software side of the boundary©2012 David Consulting Group 4
    6. 6. #DavidConsultGrpBoundary: Mobile App• Does the introduction of a mobile device change the definition of where the boundary resides? Mobile Devices Cloud Data Administration and Data Entry©2012 David Consulting Group 5
    7. 7. #DavidConsultGrpData: Client Server • Data can be held and maintained in multiple instantiations in any of the layers.©2012 David Consulting Group 6
    8. 8. #DavidConsultGrpData: Mobile App The Cloud • Data can also be held and maintained in multiple instantiations Mobile Device • Some mobile devices hold a local copy which is refreshed once connected. • Some devices can only access when connected©2012 David Consulting Group 7
    9. 9. #DavidConsultGrpTransactions: Client Server Business enter the application from the client and engages the logic and data layers (technically cohesive).©2012 David Consulting Group 8
    10. 10. #DavidConsultGrp Transactions: Mobile AppFront End utilizing mobile deviceThe client or app leverages the data fromthe cloud or from a local copy.Different devices may have unique lookand feel, but the transactions are all stillthe same. ©2012 David Consulting Group 9
    11. 11. #DavidConsultGrp Transactions: Mobile App Transaction Function FTRs DETs Name TypeDisplay EQ 1 2Organization ListDisplayOrganization EQ 1 9DetailsCall Location EQ 1 1Map this EQ 1 5Location ©2012 David Consulting Group 10
    12. 12. #DavidConsultGrp Transactions: Mobile App Transaction Function FTRs DETs Name TypeWebsite Not CountedEvents at this EQ 1 4LocationCheck In at this EQ 1 4LocationEmail to a Friend EQ 1 5 ©2012 David Consulting Group 11
    13. 13. #DavidConsultGrp Transactions: Mobile App Transaction Function FTRs DETs Name TypeView Today’sEvents EO 2 5View Upcoming EQ 1 4EventsView Event EQ 1 6DetailsOther Events at Notthis location Counted ©2012 David Consulting Group 12
    14. 14. #DavidConsultGrpTransactions: Mobile App Back End leveraging a WEB / Client Server interface • Has several variation of user roles • For this application is the single point of data entry©2012 David Consulting Group 13
    15. 15. #DavidConsultGrp Transactions: Mobile App Maintain an OrganizationTransaction Function FTRs DETs Name TypeViewOrganization EQ 1 13Create EI 1 13OrganizationEdit EI 1 13OrganizationDelete EI 1 13Organization ©2012 David Consulting Group 14
    16. 16. #DavidConsultGrp Transactions: Mobile App Maintain an EventTransaction Function FTRs DETs Name TypeView Event EQ 1 6Create Event EI 1 6Edit Event EI 1 6Delete Event EI 1 6 ©2012 David Consulting Group 15
    17. 17. #DavidConsultGrp Transactions: Mobile App Maintain a UserTransaction Function FTRs DETs Name TypeView User EQ 1 4Create User EI 1 6Edit User EI 1 4Change EI 1 4Password ©2012 David Consulting Group 16
    18. 18. #DavidConsultGrp GSC Client Server Mobile AppSystem Characteristics Score System Characteristics Score01. Data Communications 2 01. Data Communications 402. Distributed Data Processing 1 02. Distributed Data Processing 303. Performance 1 03. Performance 204. Heavily Used Configuration 3 04. Heavily Used Configuration 005. Transaction Rate 3 05. Transaction Rate 206. On-line Data Entry 5 06. On-line Data Entry 507. End-User Efficiency 3 07. End-User Efficiency 208. On-line Update 4 08. On-line Update 309. Complex Processing 3 09. Complex Processing 110. Reusability 1 10. Reusability 111. Installation Ease 2 11. Installation Ease 012. Operational Ease 2 12. Operational Ease 113. Multiple Sites 0 13. Multiple Sites 014. Facilitate Change 4 14. Facilitate Change 0 Total Degrees of Influence (TDI): 34 Total Degrees of Influence (TDI): 24 (See ReadMe) Value Adjustment Factor (VAF): 0.99 (See ReadMe) Value Adjustment Factor (VAF): 0.89 ©2012 David Consulting Group 17
    19. 19. #DavidConsultGrpConclusion and Final Comparison • Mobile App or Client Server . . . • No real counting difference • Mobile Apps are a type of client server • Tips • Carefully draw your boundaries • Understand differences in vocabulary.©2012 David Consulting Group 18
    20. 20. #DavidConsultGrpQuestions . . . Tom Cagley, CFPS VP of Consulting The David Consulting Group t.cagley@davidconsultinggroup.com (440) 668-5717 Toni Ramos, CFPS The David Consulting Group t.ramos@davidconsultinggroup.com (719) 582-2002 @DavidConsultGrp /DavidConsultGrp /company/David-Consulting-Group©2012 David Consulting Group 19

    ×