Sunday, March 6, 2016

Release Management of Mobile Apps

Associate Editor: Federica Sarro, @f_sarro

Among all the stories reflected by news agencies and social networks on Syrian refugees, the impact of mobile apps on their journey, in particular WhatsApp and Telegram, was echoed all over. During the tough journey they had, refugees connected to each other, shared their experience, reported the border’s traffic and updated their family about their health using VOIP apps …: “Without a cell phone [and internet] you are lost on the road” [2].

Ranging from Sukey, built to save British student protesters in 2011, to Angry Birds, which brings entertainment, mobile apps have a major impact on business, economy, health, politics, education … in short, on our whole life. Individual software engineers and their products have never been that close to the day to day life of regular people as they are today. This impact has been expected to also change the decision process for software development and evolution [3].

In a recently published study [1], we wanted to better understand the release decision process in mobile apps and their impact on users. Unfortunately, despite a recent surge of research interest in release engineering [6], the release engineering decisions and activities for mobile apps are still not well understood. To answer questions such as "how are release decisions for mobile apps made?", "how do users think about new releases?", we reached out to 36 developers and 674 users and found that release management of mobile apps is different from that of proprietary software.

First of all, the majority of mobile app developers, especially those with a large experience, has a clear rationale for deciding when to release a new version of their mobile app. We identified six release strategies, i.e., a time-based strategy (release schedule) to release at a specific point in time, marketing strategies to get more visibility, quality (test) driven strategies to test with parts of the customer base or achieve a specific test coverage, a feature-based strategy to release hot features ASAP, a size-based strategy to keep the size of the update fixed, and/or an occasional strategy to release an app concurrently with the launch of well-known mobile devices.



Second, as shown in the diagram above, we made a range of observations about how app developers perceive new releases. Developers believe that apps with frequent updates do not necessarily require more development effort, or introduce substantial changes to an app. Indeed, the majority (61.1%) of developers believe that apps with frequent updates (more than once per 3 weeks) deliver less functionality and changes in each version. However, there was no consensus if frequent releases affect customer feedback, i.e., whether they increase or decrease an app’s rating or download volume.



Third, our study on 674 users showed that mobile app users are not only aware of app updates but they also observed the presence of regularity in the release cycle of their apps. Users stated mixed feelings toward frequent app releases. They like apps with frequent updates but at the same time, frequent updates may be discouraging and could provoke them to uninstall apps. This might be why only half of the users turn on automatic updates. The summary of our findings from studying app users is presented in the diagram below.


Also, as part of the study, we identified a range of problems that users faced after updating their apps, as shown in the following picture. Finding solutions for these real problems is definitely of value.

The findings of this study pose several challenges that could be addressed by the research community:
Challenge 1. The impact of release frequency on mobile app users’ needs further study and analysis.
Challenge 2. The relation between release frequency and app quality is unclear.
Challenge 3. While the developers believe that release strategy and frequency do not affect development practices and total effort, empirical analysis needs to go beyond app stores to compare with traditional apps (desktop, server, web, etc.).

To sum up, app release practices are different from non-app software that researchers used to study. App developers have different strategies and considerations compared to non-app software and in some cases those strategies were not known before (such as size-based strategies). Moreover, only half of the users allow automatic updates of apps, hence each app release needs to earn people’s attention. Given that the release strategy is a success factor for mobile apps, the effect of release practices such as frequency of releases needs further elaboration.

You can find more details of this study in our paper [3]. You may also consider attending the paper presentation at the SANER 2016 conference.


References

[1] M. Nayebi, B. Adams, and G. Ruhe. “Release Practices for Mobile Apps – What do Users and Developers Think?”, Proceedings of the 23rd IEEE International Conference on Software Analysis, Evolution, and Re-engineering, SANER 2016.

[2] WhatsApp offers lifeline for Syrian refugees on journey across Europe, http://mashable.com/2015/07/03/syrians-europe-whatsapp-refugees/#jkIaUCHhtsqS, last access February 2016.

[3] W. Maalej, M. Nayebi, T. Johann, and G. Ruhe. "Towards Data-Driven Requirements Engineering", IEEE Software, Jan 2016.

[4] S. McIlroy, N. Ali, and A. E. Hassan. "Fresh apps: An empirical study of frequently-updated mobile apps in the Google play store", Empirical Software Engineering, pp. 1-25, 2015.

[5] M. William, G. Sarro, and M. Harman. "Causal Impact Analysis Applied to App M. in Google Play and Windows Phone Store", RN 15/07, (2015).

[6] B. Adams, and S. McIntosh. "Modern Release Engineering in a Nutshell - Why Researchers Should Care" in Leaders of Tomorrow: Future of Software Engineering, Proceedings of the 23rd IEEE International Conference on Software Analysis, Evolution, and Re-engineering, SANER 2016.

2 comments:

  1. One of the thumbrules we used to have in WBS is break tasks to 8 Hrs so that we know EOD what is done or not done. Comparing this with Microtasks in Crowdsourcing and relating to Software development, having a atomic unit for crowdsourcing of software development could ease the process of crowdsourcing software development.

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete