Skip to end of metadata
Go to start of metadata

Background

Mobile apps are more costly to develop, test, and maintain than many think. There are many reasons for this, but the basics are:

  1. Most mobile apps require both a front-end user interface (what you see and interact with) as well as back-end services for logic, storage, and integration with other applications. Few mobile apps turn out to be stand-alone apps. Even basic content apps often require an integration with a content management system to maintain the content efficiently and effectively.
  2. Mobile app platforms are complex constantly evolving, requiring frequent testing and often rework of apps to work on new releases of mobile operating systems and devices.
  3. The mobile app development tools and developer ecosystems are constantly evolving and changing. This means that mobile app developers and deployers really need to stay on top of things.
  4. Often administrative mobile or web features are required that may not be foreseen in the functional design goals.
  5. Security is paramount for apps with a back-end exposed to the internet, and at Emory if the data is subject to compliance policies this may prescribed very specific security measures and audit requirements that must be implemented.

It is not uncommon for a simple mobile app for iOS and Android to cost $50,000 to develop and $20,000 per year to maintain and operate. A complex application can easily range in hundreds of thousands to implement and maintain annually. For this reason it is imperative to get meaningful estimates for your project from the beginning. Useful estimates help in preparing budgets for grant proposals or allocating institutional funds for the project.

One of the primary challenges for mobile apps at Emory has been funding. This challenge has three dimensions: funding meaningful estimates to start, funding development and implementation, funding on-going operations and maintenance of the app. The challenge of funding meaningful estimates lies in the fact that under 15% of the projects IT Architecture has helped estimate have been funded by either research grants or institutional resources. So in performing initial analysis and effort estimation to adequately prepare proposal budgets, the institution effectively does this work for seven projects although only one project is ever implemented.

To address this challenge LITS has developed a method to reduce the effort estimation process while still producing enough artifacts to make a meaningful estimate that can be validated by other developers. For apps from low to medium complexity this process usually involves three or four 90-minute meetings with a project team and approximately twenty hours of effort between meetings for a total of about 25 hours of effort. LITS is working with preferred mobile app development firms to duplicate this type of assessment process at a reasonable cost. The market rate for 25 hours of effort for these assessment resources is roughly $4,000. LITS has been offering these assessment free of charge, but has limited capacity to provide them. LITS produces written use cases, data structures, and in some cases user interface wireframes for novel aspects of the app.

Goals

The technical goal of the estimation process is to identify significant factors that impact the cost of all mobile apps and to gather enough information about the function and features of the app to estimate its unique costs. Specifically the process attempts to determine:

  1. The user base(s) of the app (internal, external, roles, etc.)
  2. How the app will be distributed (internal app catalog, public marketplace, etc.)
  3. Platforms of the app to reach its user base(s) (iOS, Android, Web, etc.)
  4. What other apps are available for a similar purpose, function, and user base
  5. Primary use cases for each type of role in the user base(s)
  6. Key data structures the app queries for, creates, updates, and deletes as well as the nature of that data (sensitive, non-sensitive, ePHI, etc.)
  7. Critical application and validation logic that must reside on the backend (so all clients can access it uniformly)
  8. Details of complex, unique, or unusual user interfaces suggested by the use cases (many common UIs can be easily estimated from stories, but others may sound easy and be quite complex—this step specifically attempts to draw out those complex pieces for more details and estimation)

Process

Once a request for an initial mobile app project assessment and estimate is received, LITS schedules an initial meeting to run through the basics of the app—user base, function, and data to determine the complexity and help identify the best resources to perform the assessment and the cost of the assessment. The cost of the estimation work varies depending on who performs the assessment. If a meaningful assessment can be performed by LITS staff the cost can be less than if the assessment is performed by consultants.

Once the resources have been identified to perform the assessment, two or three 90-minute meetings are scheduled to complete the effort and cost assessment using a standard template. This template has sections addressing each of the goals outlined above. For more details see the Mobile App Effort and Cost Assessment Template.

 

 

  • No labels

2 Comments

  1. I think goal number 7 is confusing. For one, validation logic must always reside on the backend no matter what the client. Second, the term "application logic" is ambiguous. If "business logic" is what is meant that that would be a less ambiguous term to use. Also, if there is a backend, then that should be estimated separately and "validation logic" would be rolled into that. An API definition would need to be created. That would be goal number 9.

  2. Other metrics to consider would be:

    • number of pages (screens), 
    • the number of forms and elements, 
    • the types of devices/clients (e.g. phone, tablet, watch, TV, VR/AR). 
    • users need authentication/authorization?
    • app generates notifications?
    • app collects usage data beyond marketplace data
    • maint schedule