Context Aware Software: Apps die "mitdenken"

In der Natur ist ständiges Wahrnehmen der Umwelt und entsprechend angepasstes Verhalten überlebenswichtig. Das gilt in Zukunft auch für Software. Die Grundlagen dazu wurden bereits vor über 20 Jahren erarbeitet:

"Such context-aware software adapts according to the location of use, the collection of nearby people, hosts, and accessible devices, as well as to changes to such things over time. A system with these capabilities can examine the computing environment and react to changes to the environment. "

- Schilit et al 1994

Ziel ist es, dass Apps sich automatisch so verhalten wie der Benutzer es in seinem aktuellen Kontext erwartet. Dadurch wird der Umgang und die Interaktion mit Software stark vereinfacht und das "Frustpotential" im Berufsalltag verringert.

Warum jetzt?

Unsere Umgebung und insbesondere unsere Arbeitsplätze werden immer "intelligenter". Kaum ein Gerät ohne einen eingebauten "kleinen Computer" und einer Verbindung zum Internet. Schon die Smartphones in unseren Hosentaschen verfügen über enorme Rechenkapazitäten und eine ganze Reihe von Sensoren. Entsprechend arbeiten Benutzer längst nicht mehr nur auf Desktops oder Notebooks. Vielmehr sollen sie unterstützt werden wo sie sich gerade befinden. Im Wald als Förster, beim Patienten als Arzt oder auf der Baustelle als Architekt.

Damit entstehen neue Anforderungen: Apps müssen "verstehen" was der Benutzer gerade macht und ihn entsprechend unterstützen. Je mobiler und kleiner die Geräte, desto wichtiger ist es den Kontext der Benutzer zu kennen und zu berücksichtigen da so Benutzereingaben auf ein Minimum beschränkt werden können. 

Beispiel Healthcare

Konkret erkennt eine Context Aware App welchen Patienten ein Arzt gerade behandelt, oder ob der Arzt "auf Visite", beim "Rapport" oder beim Mittagessen ist. Es ist bekannt welche Personen und Geräte in der Nähe sind und der Kontext kann mit weiteren Personen, Applikationen und Geräten geteilt werden. Es wäre auch denkbar, dass kritische Situationen wie "Notfall" anhand des Bewegungsmusters und des Stresslevels des Arztes erkannt werden und er dann spezifisch für diese Situation unterstützt wird.

Wie funktioniert das?

Grundsätzlich ist es ganz einfach: Position, Aktivität und Sensordaten der Benutzer stehen zur Verfügung und können über einen Service "gesammelt" werden. Die Schwierigkeit liegt beim Interpretieren der Daten. Insbesondere können sich Kontext-Rohdaten widersprechen und es gibt individuelle Unterschiede bei der Interpretation pro Benutzer. Hier kommen Ansätze basierend auf Machine Learning ins Spiel, so dass der Prozess des "Kontext Ableitens" lernfähig ist und sich automatisch und individuell anpasst. Wir bei afca arbeiten im Rahmen unseres Weiterbildungsprogramms an entsprechenden Ansätzen. 

Risiken und Nebenwirkungen

"Big Brother": Context Aware Systeme müssen viel "wissen" über Benutzer. Diese Informationen können grundsätzlich auch missbraucht werden. Es ist wichtig, dass hier eine Vertrauensbasis geschaffen und Versprechen bezüglich Datenschutz auch gehalten werden.
Nicht 100%: Die Erkennungsrate wird nie 100% sein. Erkennt das System einen falschen Kontext ist dies für den Benutzer ärgerlich. Der Kontext muss deshalb unaufdringlich und für den Benutzer anpassbar sein.  
Nicht transparent: Es ist für Benutzer schwer nachvollziehbar wie ein bestimmter Kontext zustande kommt. Dies ist besonders störend, wenn der Kontext falsch ist.
Offene Software Architektur nicht vorhanden: Damit sind die Voraussetzungen für Context Aware Systeme nicht gegeben. Weitere Informationen dazu im Beitrag "Kohärenz in Software-Ökosystemen".

Zusammenfassung

Menschen werden in Zukunft nicht mehr an Computern arbeiten, sie werden einfach arbeiten und dabei von Computern und Applikation unterstützt - jederzeit und überall. Um dies leisten zu können, müssen Softwaresysteme den Kontext der Benutzer kennen und berücksichtigen. Durch die Vielzahl der mobilen Geräte ist dies heute beides: Möglich und notwendig. 

Entwicklungsteam oder Gruppe von Entwicklern?

Man ist sich einig: Gute Software entsteht in Teams von 4-6 Personen. Häufig wird aber davon ausgegangen, dass die Umkehrung davon auch gilt: Ein Team von 4-6 Personen entwickelt gute Software. Ist das richtig?  

Zunächst müssen wir definieren, was wir hier unter "Team" verstehen und wodurch sich Teams von Gruppen unterscheiden. Eine gute Beschreibung findet man unter www.arozumenko.com:  

Team – a small number of members with shared leadership who perform interdependent jobs with individual and groupaccountability, evaluation, and rewards. 

Group – two or more members with a clear leader who perform independent jobs with individual accountability, evaluation, and rewards. 

Team	Group
You need complicated, complex tasks to be solved	You need a lot of routine tasks to be done
You need to have variety of opinions/brainstorm activities	The way of doing things is clear or you want  to drive things by yourself
You haven’t clear specification and want to have high  self dedication within the team	You want to accomplish specified task(s)
When you need various approaches	When you need a simple solution
When you need to implement changes or develop standards,  approaches, technologies, processes	When you need implementation  of defined standards, technologies, processes
When you need outstanding results or meeting  the goal with limited resources	When you need average result

Team is better to design a car and to build a prototype, but Group is required to build thousands of such cars and deliver them to market 

Quelle: Do you really need the Team? 

Kurz zusammengefasst: Teams sind gut in der Entwicklung von Neuem während die Stärke der Gruppen in der "Massenproduktion" bzw. im Wiederholen von Bestehendem liegt. 

Do you really need the Team? Zum Entwickeln von Software unbedingt!  Moderne agile Vorgehensweisen wie Scrum funktionieren nur mit "echten" Teams. Ausserdem gibt es keine "Massenproduktion" bei Software: Ist das System mal entwickelt, kann es beliebig kopiert werden. Bei der Entwicklung von Software wird also immer Neues geschaffen.  

Und doch, wenn es zu "Personalmanagement" kommt, tun wir so als ob Entwicklerteams einfache Gruppen wären die man je nach Bedarf neu "zusammenwürfeln" kann und behandeln Entwickler wie "Ameisen" die beliebig austauschbar sind.  Eingespielte, erfolgreiche Teams werden immer wieder auseinander gerissen um neue Teams zu bilden. Oft haben die Entwickler keinen Einfluss darauf, mit wem sie im Team sind. Dies führt zu enormen Verlusten bei der Produktivität. Neue Teams brauchen oft Wochen um als Team erfolgreich arbeiten zu können.  

Um dieser Problematik entgegen zu wirken, haben wir bei afca das Angebot "Rent-a-Scrum-Team" lanciert. Unsere eingespielten Teams arbeiten produktiv ab dem ersten Tag. Teamfindung und interne Abstimmung haben längst stattgefunden. Wir sind davon überzeugt, dass wir unseren Kunden als Team sehr viel mehr Nutzen bieten können als durch individuelle "Body Leasing" Mandate. 

Kommen wir zur Frage im ersten Absatz zurück: Stimmt die Umkehr der Aussage "Gute Software entsteht in Teams von 4-6 Personen."?  

Die Antwort lautet: Ja, wenn es sich um ein "echtes" Team handelt und nicht "nur" um eine Gruppe von Entwicklern.    

Weitere Information: www.afca.ch