en
de

MALM – Den Lebenszyklus von Apps steuern

31 März 2014
| |
Lesezeit: 2 Minutes

Der Begriff MALM steht nicht nur für die Schlafzimmerserie eines schwedischen Möbelhauses, sondern auch für Mobile Application Lifecycle Management. Welche Besonderheiten das mobile Umfeld ausmachen, wird hier näher beleuchtet.
Das Mobile Application Lifecycle Management lässt sich in 6+1 Phasen unterteilen. Wichtig dabei ist, dass die Phasen nicht als Bestandteile eines Wasserfallmodells verstanden werden, sondern als eine Folge von wiederkehrenden Iterationen, die sich auch gegenseitig beeinflussen.

-ZK-ALM

Der Lebenszyklus von Apps unterscheidet sich von dem der klassischen Anwendungen vor allem dadurch, dass sich das Umfeld von mobilen Applikationen deutlich schneller verändert. Fast wöchentlich erscheinen neue Hardwares, Betriebssysteme und Anwendungsfälle. Was heute noch als cool und hip gilt, kann morgen schon vom Wettbewerb adaptiert sein und übermorgen bereits als antiquiert gelten. Hinzu kommt, dass Apps immer mehr die klassischen Anwendungen verdrängen, gleichzeitig aber deren Funktionalität abdecken sollen und dabei noch intuitiv bedienbar sein müssen. Entwicklungsteams klassischer Anwendungen, mit nahezu unendlichen Ressourcen, benötigen gewöhnlich keine Kenntnisse zur Hardware, zur Optimierung der Netzwerkverbindung, dem Speicherverbrauch oder dem Deployment über App-Stores mit ihren eigenen Regeln. Die Aneignung dieser App- und plattformspezifischen Kentnisse sind unabdingbar, wenn man Apps entwickeln möchte. Ebenso haben die App Store Guidlines einen hohen Einfluss darauf, wie die Software entwickelt wird, und müssen daher gekannt und beachtet werden.

Die 6+1 Phasen charakterisieren sich vor allem durch diese Fragestellungen:

Planung

  • Wer soll die App verwenden? Richtet sich die App an ein breites Publikum oder ist sie nur für eine unternehmensweite Anwendung gedacht?
  • Welche Aufgaben sollen mit der App erledigt werden können?
  • Welche Plattform verwendet ein typischer Nutzer?

Spezifikation

  • Was sind die Anforderungen an die App und wie lassen sich diese abdecken?
  • Gibt es bereits ein Produkt, welches man kaufen, anpassen und integrieren kann, oder ist es notwendig, eine eigene App zu entwickeln?
  • Wie lässt sich der Erfolg einer Anpassung an der App messen?

Entwicklung

  • Wie kann beispielsweise eine Offline-Fähigkeit gewährleistet werden?
  • Wie erstellt man ein leistungsstarkes Backend mit guter Fähigkeit zur Skalierung?
  • Welche Teile der App ändern sich laufend und können auch ohne den Weg über den AppStore aktualisiert werden?

Testing

  • Wie testet man die App auf unterschiedlicher Hardware, Betriebssystemversionen und in unterschiedlichen Umgebungen?
  • Wie lassen sich Tests automatisieren und neue Softwarestände automatisch verteilen?
  • Wie kann eine Qualitätssicherung etabliert werden um kritische Fehler in Anbetracht langer App-Review-Zeiten zu vermeiden?

Verteilung

  • Wird die App über die öffentlichen Stores verteilt oder an einen eingeschränkten Nutzerkreis?
  • Ist die App konform zu den Regeln der App Stores?
  • Wie können auch updateträge Nutzer motiviert werden die App mit dem Erscheinen einer neuen Version zu aktualisieren?

Analyse

  • Welche Funktionen werden häufig verwendet, welche weniger?
  • Wer nutzt die App und wie deckt sich dies mit der Planung?
  • Welches Feedback geht zur App ein und wie soll darauf reagiert werden?

End of Life

  • Ist der wirtschaftliche Erfolg für die Zukunft absehbar, oder der Betrieb auf Dauer ein Verlustgeschäft?
  • Wirkt die App nicht mehr zeitgemäss und es fehlen die notwendigen Ressourcen?
  • Kann eine weitere Verfügbarkeit der App der eigenen Reputation sogar schaden?

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.