The app life-cycle management process


Posted on: February 24, 2012 by Mylene Reiners

More and more companies are going mobile. Just like some 15 years ago, when everyone needed a presence on the web, now everyone needs a presence in one app store or another. In contrast to 15 years ago, however, the technology is much more mature. We can build gorgeous apps - not Angry Birds or Wordfeud, but apps that could help our customers tremendously.

In the app development world, more and more people realise that building apps is not something you can do in a minute or two... Building good apps is a craft, and (as usual) we need to deliver apps that are predictable, on time, on budget, reliable, of high quality and delivering added value. In the non-app world, software projects have a software (or application) life-cycle management process (SLMP) to reach al those goals. For the app world, I advice an app life-cycle management process (ALMP), based on the best practices of the SLMP, with some app specific additions.

Apps need to be an integral part of the company's project portfolio management process, as this process determines what projects (mobile or not) in what sequence will help an organisation to reach it overall goals, by weighing scarce resources and added value. The organisations needs to know what the project's purpose is, its desired results, and how its success will be measured.

When the time has come that an app development project starts, the first step will have to do with requirements gathering. Requirement engineers need to be aware of the similarities and the differences between apps and other software. Similarities are e.g. the need to access and store data and the need for security. Differences are e.g. the abundance of mobile devices (think of operating system: iOS, Android, Windows, ..., screen sizes, features), user interactions, interruptions, multi-tasking and user expectations. An app that looks great on a smartphone, will not always look great on a tablet, an app build for a large screen smartphone will not look great on a small(er) screen... An app built for Android 4 will not run on (at the moment of writing this post) 95% of the Android devices! In short, a requirements engineer needs to know a real lot of mobile ins-and-outs.

When the requirements gathering is (partly) finished, architects and designers come into play in a design phase. As users expect their mobile apps to work as all other apps on their device, architects and especially user interface/interaction designers need to know the guidelines. Just imagine, a great, superbly designed app, exactly what the company wants, is rejected by the Apple app store, just because it is not in line with their user interface requirements...

The design of the apps (whether it is architectural or user interface) has to be translated into code. Good developers, with a thorough understanding of their platform of choice are indispensable. But the development process for apps needs more, it should be as professional as any other development process. There is a need for development guidelines (performance, caching, code size, platform guidelines), developers should build unit tests to prove their code works, and there is need for a professional development environment (source code management, continuous integration, issue and bug tracking etc. should all be in place).

When (a part of) an app is finished, it needs thorough testing. Again, testers really need to be well aware of the problems testing apps pose (besides the "normal" testing, that still is needed). They need to test apps (preferably automated) on as much of the targeted devices as possible. But they should also test all imaginable interruptions - an app needs to handle interruptions graciously. When someone is in the middle of a certain task, and she gets a call, the app should, when the call ends, be in the exact same state as before! Does the app work when the network connection is bad, or down? What if the battery runs out? Is the security in compliance with the requirements? The performance? Once again, does the app comply to the guidelines? Does de-installation work? Re-installation?

When every phase in the development process is finished successfully, the build and release processes should be straightforward. As we live in a far from ideal world, this will not always be the case, so again, release managers with a good understanding of the mobile app world will be important. They should know the difference in e.g. the different distribution mechanisms of the Apple app store and the Android market - deploying on the market is easy. The process will last no longer than half an hour, and a few moments later, the app is available to everyone who wants to use it. For addition to the Apple app store, the initial process also is really quick and easy, but Apple wants to test all apps also, and that process will last for almost two weeks - and all that time, the app will not be available to users.

The deployment process (the time the app is live, bugs are fixed and additional features added) is kind of an ALMP in itself. New versions of the targeted platforms will arrive, and need to be tested against. If you do not enforce updates, users could be using outdated versions of your app. Updating to the newest version will therefore not always be from the last version, but possibly much older ones - and e.g. data have to be preserved between all of them! There will be a moment you app becomes obsolete. Theoretically the ALMP process ends then. But what if users still try to use the app? What if the server the app connected to at that moment contains company confidential data?

Conclusion:

The standard SLMP is not enough to deliver secure, performing, high quality apps; apps need specialized requirement engineers, developers, testers,  maintainers and so on… App development is not easier (quicker, cheaper) than standard development. Apps pose other challenges than standard applications. In our experience, a dedicate App Life-cycle Management Process that enhances the standard SLMP is crucial to avoid (most of) those pitfalls.

Share this blog article


About Mylene Reiners

Architect
I have been employed in the field of ICT since 1988, and gained experience in lots of technologies and roles. Currently I spend almost all of my time working as a software architect and as Dutch competence lead for Java EE and for Android. Besides that, my interest are centered around software quality and software security, software craftsmanship and agile, SaaS and Open Source and Open Standards. I try to keep up-to-date with all of those interests, mostly conceptual, sometimes by going hands-on. Besides my work I like to read, hike and listen to music.

Follow or contact Mylene