Improvements of Capgemini’s Internal Staffing Process...

Improvements of Capgemini’s Internal

Staffing Process through Implementation and Evaluation of the “DreamTeam”

Android Mobile Application

K A T A R I N A L A R S S O N

Master of Science Thesis Stockholm, Sweden 2011

Improvements of Capgemini’s Internal Staffing Process through Implementation

and Evaluation of the “DreamTeam” Android Mobile Application

K A T A R I N A L A R S S O N

Master’s Thesis in Computer Science (30 ECTS credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2011 Supervisor at CSC was Anders Lansner Examiner was Jens Lagergren TRITA-CSC-E 2011:039 ISRN-KTH/CSC/E--11/039--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.kth.se/csc

Abstract

Title: Improvements of Capgemini’s internal staffing process through implementation and evaluation of the

“DreamTeam” Android mobile application.

This Master’s Thesis covers two main areas. The first one is an identification of how a mobile

application called DreamTeam shall be implemented and designed for Android to improve the

internal staffing process within Capgemini. DreamTeam is a pilot application developed for iPhone

and its purpose is to ease and make staffing of projects more effective. The main purpose of the

DreamTeam application is to allow users to assemble a team of consultants for an assignment, a bid,

or another purpose. This report describes the implementation of the Android version of the existing

iPhone DreamTeam application.

The second part is a usability evaluation and an analysis of how the Android version of DreamTeam

application is valuable for Capgemini and how it can be improved and suited for the organizations

needs. The report includes the theoretical basis and relevant use cases to grasp the underlying

infrastructure, implementation and evaluation of the Android DreamTeam application. The usability

evaluation was performed through field studies with a web-based questionnaire and the outcomes are

presented with quantitative- and qualitative results. Possible developments of DreamTeam are

presented and based on interviews with Capgemini employees.

The conclusions made are that the idea and implementation of DreamTeam is promising and its

functionality can improve the staffing of projects and reduce duplication of work, but the current

formation is still too static and need some improvements to reach its full potential.

Sammanfattning

Titel på svenska: Förbättring av Capgeminis interna bemanningsprocess genom utveckling och utvärdering av

den mobila Androidapplikationen ”DreamTeam”.

Denna rapport undersöker två huvudområden. Det första innefattar att undersöka hur en mobil

Androidapplikation vid namn ”DreamTeam” ska designas och utvecklas för att förbättra den interna

bemanningsprocessen på Capgemini. DreamTeam är en pilotapplikation utvecklad för iPhone och

dess syfte är att underlätta och effektivisera bemanningen av projekt. Genom applikationens hjälp ska

användaren ha möjlighet att söka efter konsulter med specifika kompetenser och tillsätta dessa i

aktuella uppdrag. Denna rapport beskriver implementationen av Android versionen av DreamTeam.

Det andra området innefattar en användbarhetsutvärdering och analys av nyttan med applikationen

för Capgemini samt hur den kan förbättras och anpassas till organisationens mål. Rapporten

innefattar relevanta användarfall och den teoretiska grund som erfordras för att förstå den

underliggande infrastrukturen, implementationen och utvärderingen av DreamTeam.

Användbarhetsutvärderingen utfördes i form av en fältstudie med ett online-baserat webbformulär

och resultaten är presenterade både kvantitativt och kvalitativt. Möjlig framtida utveckling av

DreamTeam presenteras och baseras på intervjuer med Capgeminianställda.

Slutsatserna kan sammanfattas med att initiativet och utvecklingen av DreamTeam är i framkant

gällande mobila effektiviseringsverktyg för företag och dess funktionalitet kan förbättra den interna

bemanningsprocessen och minska arbetsbördan för berörda parter inom företaget. Dock är den

nuvarande implementationen för statisk, både gällande teknik och process, och behöver utvecklas och

förbättras för att nå sin fulla potential.

Acknowledgements

This Master’s Thesis is part of a project managed within a part of Capgemini Sverige AB called Service

Industries and examined at the School of Computer Science and Communication (SCS) at the Royal

Institute of Technology (KTH).

First of all I want to thank all the project members in the Accelerator project and other employees at

Capgemini that have provided me with valuable knowledge, input, and feedback during the process

with this Master’s Thesis. A special thanks to the project leader and my supervisor at Capgemini,

Christian Karlsson.

I also want to thank my supervisor at KTH, Professor Anders Lansner, which has provided me with

important feedback and input regarding the report and evaluations parts.

Stockholm 2011-02-11

Katarina Larsson

Table of Content

1. Introduction .............................................................................................................................................. 1

1.1 Background................................................................................................................................................. 2

1.2 Problem ........................................................................................................................................................ 2

1.3 Purpose ........................................................................................................................................................ 3

2. Theory ......................................................................................................................................................... 4

2.1 Client-Server-Model .............................................................................................................................................. 4

2.2 Cloud based applications .................................................................................................................................... 4

2.2.1 Cloud based delivery models .................................................................................................................... 6

2.2.2 Benefits and Concerns ................................................................................................................................. 7

Benefits: ................................................................................................................................................ 7

Concerns: .............................................................................................................................................. 7

2.3 Representational State Transfer (REST) applications ............................................................................ 8

2.3.1 HyperText Transfer Protocol (HTTP) ................................................................................................... 9

2.4 Smartphone programming ............................................................................................................................. 11

2.4.1 Smartphone definition ............................................................................................................................. 11

2.4.2 Challenges of smartphone programming ......................................................................................... 12

2.5 Native Mobile Applications vs. Mobile Web Applications .................................................................. 13

2.5.1 Native Smartphone Applications ......................................................................................................... 13

2.5.2 Mobile Web Applications ........................................................................................................................ 13

2.6 Android ................................................................................................................................................................... 15

2.6.1 Dalvik and the Java Virtual Machine ................................................................................................... 16

2.6.2 XML based layout ....................................................................................................................................... 17

2.6.3 Guidelines ...................................................................................................................................................... 17

2.6.4 Android API levels...................................................................................................................................... 19

2.7 Human Computer Interaction Evaluation Techniques ....................................................................... 21

2.7.1 Usability testing .......................................................................................................................................... 21

2.7.2 Field studies .................................................................................................................................................. 21

2.7.3 Analytical evaluation ................................................................................................................................ 22

Walkthroughs: ................................................................................................................................. 22

Heuristic evaluation: ..................................................................................................................... 22

2.7.4 Planning the evaluation – The DECIDE Framework .................................................................... 23

2.7.5 Data gathering techniques ...................................................................................................................... 23

2.7.6 Analyzing Data ............................................................................................................................................. 24

3. Method ..................................................................................................................................................... 26

4. Architecture ........................................................................................................................................... 27

4.1 Mobile Service ...................................................................................................................................................... 28

4.1.1 Mobile Service Methods: ......................................................................................................................... 29

4.2 Data model ............................................................................................................................................................. 30

5. Requirements and Use Cases .......................................................................................................... 31

5.1 Users ......................................................................................................................................................................... 31

5.2 Requirements ....................................................................................................................................................... 31

5.2.1 Team ................................................................................................................................................................ 31

5.2.2 Search .............................................................................................................................................................. 32

5.2.3 Favorites ........................................................................................................................................................ 33

5.2.4 Info .................................................................................................................................................................. 33

5.3 Use Cases ................................................................................................................................................................ 34

5.3.1 Team ............................................................................................................................................................... 34

5.3.2 Search .............................................................................................................................................................. 35

5.3.3 Favorites ........................................................................................................................................................ 36

5.3.4 Info ................................................................................................................................................................... 36

6. Implementation .................................................................................................................................... 37

6.1 Activities ................................................................................................................................................................. 37

6.1.1 Main Activities ............................................................................................................................................. 37

6.2 Android specific hardware.............................................................................................................................. 39

6.3 Android specific design implementation .................................................................................................. 39

6.4 Menus and Navigation ...................................................................................................................................... 39

6.5 Navigation in DreamTeam Activities .......................................................................................................... 40

6.5.1 Search .............................................................................................................................................................. 40

6.5.2 Team ................................................................................................................................................................ 41

6.5.3 Favorites ........................................................................................................................................................ 42

6.5.4 Info ................................................................................................................................................................... 42

6. 6 Communications ................................................................................................................................................ 43

6.7 Threads ................................................................................................................................................................... 43

6.8 Database ................................................................................................................................................................. 43

6.9 Security ................................................................................................................................................................... 44

6.10 Environment ...................................................................................................................................................... 44

7. DreamTeam walk-through ............................................................................................................... 45

7.1 Start screen ............................................................................................................................................................ 45

7.2 Main Menu ............................................................................................................................................................. 45

7.3 Add Team ............................................................................................................................................................... 46

7.4 Add Team Members ........................................................................................................................................... 46

7.5 Search ...................................................................................................................................................................... 47

7.6 Long Press .............................................................................................................................................................. 47

7.7 Person View .......................................................................................................................................................... 48

7.8 Add from Person View ...................................................................................................................................... 48

7.9 Remove.................................................................................................................................................................... 49

7.10 Indicators............................................................................................................................................................. 49

8. Tests .......................................................................................................................................................... 50

8.1 Expert Testing ...................................................................................................................................................... 50

8.2 Monkey .................................................................................................................................................................... 51

9. Usability Testing- and Evaluation ................................................................................................. 52

9.1 Performing the test ............................................................................................................................................ 54

10. Usability Evaluation Results ...................................................................................................... 56

10.1 Quantitative results ......................................................................................................................................... 56

10. 1.1 Android Experience distribution ..................................................................................................... 57

10.1.2 Navigation ................................................................................................................................................... 58

10.2 Qualitative Results ........................................................................................................................................... 60

Installation ........................................................................................................................................ 60

UI........................................................................................................................................................... 60

Response time ................................................................................................................................. 60

Navigation ......................................................................................................................................... 60

11. Possible development of DreamTeam ................................................................................... 61

11.1 Sales ....................................................................................................................................................................... 61

11.2 Staffing .................................................................................................................................................................. 62

11.3 Conclusion ........................................................................................................................................................... 62

12. Discussion ......................................................................................................................................... 63

12.1 DreamTeam Usability ..................................................................................................................................... 63

12.2 DreamTeam Process ....................................................................................................................................... 64

12.3 Conclusion ........................................................................................................................................................... 66

13. References ......................................................................................................................................... 67

APPENDIX: A .................................................................................................................................................. 71

Usability Evaluation of Android version of DreamTeam (performed in Swedish) ......................... 71

Outline

This report is divided in 13 chapters and one Appendix. The Chicago Manual of Style, author – date, is

used for all references. A complete bibliography is listed in the end of the report after chapter 13 and

before the appendix. Concepts are marked with superscript and are explained in the footer at the

current page.

1

1. Introduction

“Mobile devices have fulfilled the true aim of Internet by offering full connectivity anytime

anywhere. The trend of going wireless goes beyond the walls of homes, university buildings, or

hotels and reaches the open spaces of nature or the mobile spaces of trains and buses. The

freedom of movements is used to speak everywhere without the need to log in a local wireless

network, and to extend it to other Internet services such as Web surfing, email checking,

reading news, listen to online radios, or even watching video streaming and television.”

(Oliveira, Rodrigues och Vaidya 2010)

According to Gartner, smartphone1 sales grew 96 percent from the third quarter last year (2009), and

smartphones accounted for 19.3 percent of overall mobile phone sales in the third quarter of 2010

(Tudor och Pettey 2010).

Because different types of mobile devices, especially smartphones, increase in popularity the need and

importance of suitable mobile- and web applications increase. These new developments have been

recognized in the enterprise too. As recently as a year ago, many enterprises could not have imagined

they would rely on smartphones to improve employee productivity.

Capgemini is one of the world’s largest suppliers of IT-services, management consulting and

outsourcing (Capgemini u.d.) that now adopts to the new trend. This Master’s thesis is part of a

project managed within a part of Capgemini Sverige AB called Service Industries. The project is

named The Accelerator and its focus is to rationalize and improve internal processes mainly

concerning staffing, work scheduling, resume search and time reporting realized through mobile

applications for iPhone and Android. The Accelerator project is divided in different stages and

includes five applications:

- DreamTeam

- FreeForce

- Tasks

- Educator

- DashBoard

1 Smartphone: see section 2.4.1 (page 12)

2

The first stage includes the development and implementation of DreamTeam and this Master’s thesis

covers the Android implementation of DreamTeam. The other applications are out of scope and will

not be covered in this report.

1.1 Background

DreamTeam is a pilot application developed for iPhone and its purpose is to ease and make staffing of

projects more effective. The main purpose of the DreamTeam application is to allow users to assemble

a team of consultants for an assignment, a bid, or another purpose. One possible scenario is when a

senior consultant gets a request from a client about the possibility to perform and staff a future project.

Today the consultant has to bring this question to a staffing meeting that is held every week. With the

new application it will be possible to overview all Capgemini consultants immediately in the mobile

phone. The iPhone application is a pilot application with limited functionality. The main

functionalities of DreamTeam are:

- Search for consultants resume.

- Search for consultants through core skills as e.g. “Java”, “Oracle” etc.

- Manage and create teams of consultants.

- See consultant’s availability.

- Save and view favorite consultants in a favorite list.

1.2 Problem

The scope of the thesis is divided in two parts, development and evaluation.

Development: In the first part an Android version of the iPhone DreamTeam application described

above will be developed. This includes establishing Android specific requirements and developing the

application for Android on the basis of “The developers guide for Android” (Android Developers

u.d.). It also includes taking appropriate decisions about the user interface regarding usability and

design that has to comply with to the “User Interface guidelines for Android” (Android Developers

u.d.). All requirements are described in a system requirements specification and this will serve as a

base in the work with the application. A good understanding of Android, client-server model, cloud

3

computing, and REST applications are needed and security aspects for mobile development for the

enterprise also have to be evaluated and considered.

Evaluation: When the application is finished it will be evaluated both regarding usability and its

advantages for the company. Suitable human computer interaction (HCI) models will be used for the

usability part and the second part will be evaluated through interviews and research. Research will be

performed both externally and within Capgemini.

1.3 Purpose

This master thesis has two main objevtives. The first one is to identify how mobile Android

applications shall be designed to improve the internal staffing process within Capgemini. The second

one is to evaluate the usability of the application and to investigate if and how the DreamTeam

application is valuable for Capgemini and how it can be improved and suited for the organisations

needs.

4

2. Theory

This chapter establishes the theoretical basis to grasp the implementation and evaluation of the

Android DreamTeam application. This starts with an introduction to Client-Server-Model, and REST-

and Cloud applications to comprehend the upcoming chapter 4 about the underlying infrastructure

and its components that the mobile Android DreamTeam application will be a part of.

Subsequently follows an introduction to smartphone programming, the mobile operation system

Android, and relevant human computer interaction techniques and models.

2.1 Client-Server-Model

The term client-server refers to a popular model for computer networking that utilizes client and

server devices each designed for specific purposes. In a client-server system, two separate applications

are involved. The first application runs on the server and protects and provides access to the data

located on the server. The second application is the client and it runs typically on the user’s

workstation or mobile device. The client sends requests to the server and gets appropriate results from

the server depending on the formulation of the request. One server generally supports numerous

clients, and multiple servers can be networked together in a pool to handle the increased processing

load as the number of clients grows. The client-server model can be used on the Internet as well as

local area networks (LANs). Examples of client-server systems on the Internet include e.g. Web

browsers and Web servers. (Hentzen 2007)

2.2 Cloud based applications

Cloud computing is considered by many to be the next great wave in the IT industry and is currently

one of its major buzzwords. Gartner predicts that cloud computing will surge to 150 billion US dollars

by 2010 (Gregg 2010).

Historically “the cloud” is a metaphor for Internet and is often represented by a cloud in network

diagrams shown in the figure 1 on the next page. The cloud is often referred to as something that is

“someone else’s concern” and the expression explains the basic idea of the cloud-computing concept.

In essence, cloud computing is when shared resources, software, and information resides at a location

5

other than your computer and are provided to computers, smartphones and other devices on demand

over the Internet. (Elsenpeter, Velte and Velte 2010); (Antonopoulos och Gillam 2010)

The billing model for cloud computing is typically based on a “pay as you go” structure where

organisations need to pay only as much for the computing infrastructure as they use.

The programs included in Google Apps2, such as Gmail and Google Docs, are examples of cloud

applications. They provide common business applications online that are accessed from a Web

browser. The software comes from the Web servers, and the data may be stored on the servers as well.

The figure below shows how a cloud provider hosts applications. (Elsenpeter, Velte and Velte 2010)

(Antonopoulos och Gillam 2010)2

2 Google Apps: is a service from Google providing independently customizable versions of several Google products under a custom domain name. It features several Web applications with similar functionality to traditional office suites, including: Gmail, Google Groups, Google Calendar, Talk, Docs and Sites. (Wikipedia: Google Apps u.d.)

FIGURE 2: EXAMPLE OF HOW A CLOUD PROVIDER HOSTS APPLICATION

(ELSENPETER, VELTE AND VELTE 2010)

FIGURE 1: NETWORK DIAGRAM

(ELSENPETER, VELTE AND VELTE 2010)

6

2.2.1 Cloud based delivery models

There are three cloud-based delivery models:

Software as a service (Saas): The consumer uses an application but does not control the operating

system, hardware or network infrastructure. These applications are steered over the network and

users do not need to have the application housed locally on their server or client. Saas is sometimes

referred to as “software on demand”.

Platform as a service (PaaS): The user hosts an environment for their application. The users control

the application but do not control the operating system, hardware or network infrastructure used.

Infrastructure as a Service (IaaS): The user accesses fundamental computing resources such as CPU33,

memory, middleware and storage. The consumer controls the resources but not the cloud

infrastructure beneath them. The picture below shows the three components of a cloud-computing

solution. (Elsenpeter, Velte and Velte 2010) (Antonopoulos och Gillam 2010)

3 CPU: Is a acronym for Central Processing Unit and is the portion of a computer system that carries out the instructions of a computer program, and is the primary element carrying out the computer's functions. (Wikipedia: CPU u.d.)

FIGURE 3: COMPONENTS OF A CLOUD-COMPUTING SOLUTION (ELSENPETER, VELTE AND VELTE 2010)

7

2.2.2 Benefits and Concerns

As with several things in IT, there are pros and cons and cloud computing is not an exemption. Some

benefits and concerns are listed below:

Benefits:

- Cloud computing promises to cut operational and capital costs and let IT- departments focus

on strategic projects instead of the maintenance of data centres etc. Another company hosts

applications and also pay the costs of servers and service of these.

- Applications can be accessed from everywhere which gives increased mobility. Users can

perform their job from home, work, or at client locations.

- Ability to free-up IT workers who have been occupied performing server updates, installing

patches, or providing application support etc. (Gregg 2010) (Elsenpeter, Velte and Velte 2010)

(Antonopoulos och Gillam 2010)

Concerns:

- If network connection problem occur cloud applications are unreachable. This affects several

people and implies extended costs for the company due to inefficiency. The same scenario

arise if the application site trying to be accessed having problems.

- Many companies are uncomfortable with the idea of storing their data and applications on

system infrastructures and services they do not control. Even if the data exists in the cloud it

actually has to reside at a physical location. Companies lose control over their data, the cloud

provider should agree in writing to provide the level of security required. Anyone considering

using the cloud needs to look at who is managing their data and what types of controls are

applied to these individuals.

- The connection between different applications is more complicated, e.g. if you want to move a

file from one application to another.

- The cloud provider is responsible of the level of security required and to handle possible

security risks. Cloud based services are an attractive target to hackers, what happen if a

security incident occurs and what support will the provider supply? (Gregg 2010)

8

2.3 Representational State Transfer (REST) applications

One of the key technologies that make the web so powerful today is web services. Web services allow

systems to communicate with each other using messages. Extensible Markup Language (XML) is often

used to format these messages. It is messages in text format understood of almost all systems and they

are used when communicating between applications that run on different machines. Though XML is

the most popular it is not the only message format available in the programmable web. There are a

large number of other formats offered, e.g. HTML, JSON and RSS. HTML is an abbreviation for

HyperText Markup Language and is used to markup tags to describe web pages (Wikipedia:HTML

u.d.) and RSS stands for Really Simple Syndication and is a family of web feed formats used to publish

frequently updated contents such as news feed from a web page (Samisa 2008). JSON stands for

JavaScript Object Notation and is a wide accepted format with an appealing form that is a lightweight

text-based open standard designed for human-readable data interchange. It is derived from the

JavaScript4 programming language for representing simple data structures and associative arrays,

called objects. Despite its relationship to JavaScript, it is language-independent, with parsers5 available

for virtually every programming language. (Wikipedia:JSON u.d.) Representational State Transfer or

REST has over time become the preferred technology for web services used in web applications

(Samisa 2008). REST is a software architecture style that can be followed while designing software

systems and is an ideal design to adapt for web services based software applications. REST was first

described by Roy Fielding in his PhD dissertation (Fielding 2000).

One of the key principles behind REST web services is to access resources via Uniform Resource

Indicator (URI). An URI is a unique identifier that is built up by a string of characters used to identify

a resource on the Internet; it is made of a name and a structured address indicating where to find this

resource (Wikipedia:URI u.d.). One example of how URIs are used in web services are when an URI is

typed in the address bar of a web browser and a XML document is received as response. That is

actually a web service in action. (Samisa 2008) An example of an URI could look like:

http://sv.wikipedia.org/wiki/Representational_State_Transfer.

Often, REST architectural style is referred to as the architectural style of the Web and most of today’s

web applications demonstrate. But REST is not a standard; it is just an architectural style. Despite this,

REST rely heavily on many other standards such as: HTTP, URI, XML, JON and HTML. It is has its

heart in the concept of resources (URIs) with which web services can be built. (Samisa 2008)

Conforming to the REST constraints is referred to as being “RESTful” (Wikipedia:REST u.d.).

4 JavaScript: A scripting language used in web content development, primarily to create functions that can be embedded in or included from HTML documents and that interact with the DOM (Document Object Model). 5 Parsers: In computing, a parser is one of the components in an interpreter or compiler, which checks for correct syntax and builds a data structure (often some kind of parse tree, abstract syntax tree or other hierarchical structure) implicit in the input tokens. (Wikipedia:Parsing u.d.)

9

2.3.1 HyperText Transfer Protocol (HTTP)

HyperText Transfer Protocol (HTTP) is a protocol6 for distributed, collaborative, hypermedia

information systems, led to the establishment of the World Wide Web (WWW) together with URIs,

HTML, and the first browsers. Programmable Web uses HTTP as the transportation medium and,

most of the time, XML as the message format. In other words, programmable Web could be

considered as XML over HTTP. (Samisa 2008)

The REST client-server architectural style is designed to use a stateless communication protocol,

typically HTTP. It functions as a request-response protocol in the client-server computing model. In

HTTP, a web browser, for example, acts as a client, while an application running on a computer

hosting a web site functions as a server. The client submits an HTTP request message to the server.

The server, which stores content, or provides resources, such as HTML files and images, or generates

such content as required, or performs other functions on behalf of the client, returns a response

message to the client. A response contains completion status information about the request and may

contain any content requested by the client in its message body. (Wikipedia:HTTP u.d.)

A client sends a request to a server, expecting an answer. The message exchanges are made of an

envelope and a body, also called a document or representation.

The Web consists of well-identified resources linked together and accessed through simple HTTP

requests. The main types of requests standardized in HTTP are GET, POST, PUT, and DELETE. These

are also called verbs, or methods. HTTP defines four other methods that are less frequently used:

HEAD, TRACE, OPTIONS, and CONNECT. (Goncalves 2010) The four most common used are

described on the next page:

6 A communications protocol is a formal description of digital message formats and the rules for exchanging those messages in or

between computing systems and in telecommunications. Protocols may include signaling, authentication and error detection and correction capabilities. A protocol describes the syntax, semantics, and synchronization of communication and may be implemented in hardware or software, or both (Wikipedia:Protocol u.d.).

FIGURE 4: HTTP REQUEST AND RESPONSE (GONCALVES 2010)

http://en.wikipedia.org/wiki/Request-response

http://en.wikipedia.org/wiki/Client-server

http://en.wikipedia.org/wiki/Web_browser

http://en.wikipedia.org/wiki/Host_%28network%29

http://en.wikipedia.org/wiki/Web_site

http://en.wikipedia.org/wiki/HTML

10

GET: Retrieves a resource identified by a URI.

POST: Sends a resource to the server and updates the resource in the location identified by the URI.

PUT: Sends a resource to the server, to be stored in the location identified by the URI.

DELETE: Deletes a resource identified by a URI. (Samisa 2008)

11

2.4 Smartphone programming

It is three years since Apple Inc brought the smartphone to a mass consumer market, but smartphones

have been around in one form or another since 1993. The difference between then and now is that

early smartphones were primarily used as enterprise devices and were prohibitively expensive for

most consumers. Today it is different and several phone manufactures and operating system (OS)

developers competing for market shares. The chart below shows smartphone sales by operating

system during the third quarter of 2010. (PCWorld: Brief history of smartphones 2010)

2.4.1 Smartphone definition

There is no standard definition of the term smartphone across the industry. According to Wikipedia

smartphones (Tudor och Pettey 2010) can be described as:

“A smartphone is a mobile phone that offers more advanced computing ability and connectivity

than a contemporary basic feature phone. Smartphones and feature phones may be thought of as

handheld computers integrated within a mobile telephone, but while most feature phones are able

to run applications based on platforms a smartphone allows the user to install and run more

FIGURE 5: SHARE OF 2010 Q3 SMARTPHONE SALES TO END USERS BY OPERATING

SYSTEM, ACCORDING TO GARTNER (GARTNER 2010) (WIKIPEDIA:SMARTPHONES U.D.)

http://www.networkworld.com/slideshows/2009/100709-ultimate-smartphone.html

http://www.networkworld.com/slideshows/2009/102109-smartphones.html

http://en.wikipedia.org/wiki/Mobile_phone

http://en.wikipedia.org/wiki/Feature_phone

12

advanced applications based on a specific platform. Smartphones run complete operating system

software providing a platform for application developers. Handheld devices lag behind their

desktop counterparts in memory and speed by eight to ten years.” (Wikipedia:Smartphones u.d.)

Now is an exciting time for mobile developers. Mobile phones have never been more popular, and

powerful smartphones are now a popular choice for consumers. Stylish and versatile phones packing

hardware features like GPS, accelerometers, and touch screens, combined with fixed-rate, reasonably

priced data plans provide an enticing platform upon which to create innovative mobile applications.

(Meier 2010)

2.4.2 Challenges of smartphone programming

Developing programs for a phone is a different experience than developing desktop applications, web

sites, or back-end server processes. The tools look different, the frameworks behave differently, and

there are more limitations on what you can do with your programs (Murphy 2010). Below some

programming challenges are mentioned:

- Screens are small.

- Keyboards are small. On some smartphones physical keyboards do not exists.

- CPU speed and memory are limited compared with what are available on desktops and

servers.

- Devices are limited to the OS the manufactures have selected. (Murphy 2010)

http://en.wikipedia.org/wiki/Operating_system

13

2.5 Native Mobile Applications vs. Mobile Web Applications

When talking of applications for mobile devices mainly two different techniques are considered: native

mobile applications and mobile web application. They differ from each other in e.g. development

techniques and online/offline usage. The following two sections describe the different approaches.

2.5.1 Native Smartphone Applications

A native application is software that needs to be downloaded and installed on a device. It is the native

applications users download from the Apple App Store7 or Android Market8. Native apps are

designed for specific platforms e.g. Android or iPhone’s iOS9 and can consequently take advantage of

the built in hardware and software of the mobile device like the gyroscope, camera etc. Thus, an

Android application cannot be used on e.g. an iPhone.

2.5.2 Mobile Web Applications

A mobile web application is more or less like a regular webpage but it is optimized for viewing on

mobile device web browsers. The benefit with this is that no approval from an application store is

required and it can be used on every platform. The main tools for web application development of this

kind are HTML510 and CSS311. The major setbacks are that older or less capable browsers on older

devices do not have support for these tools. (Oliveira, Rodrigues och Vaidya 2010). See comparison

table between native- and mobile web applications on the next page (Oliveira, Rodrigues och Vaidya

2010).

7 App Store: The Apple App Store is a service for iOS devices (iPhone, iPod Touch and iPad) offered by Apple Inc. which allows users to browse and download applications that were developed with the iOS SDK and published through Apple. (Wikipedia:App Store u.d.) 8 Android Market: Android Market is an online software store developed by Google for Android devices. An application program called "Market" is preinstalled on most Android devices and allows users to browse and download apps published by third-party developers, hosted on Android Market. (Wikipedia:Android market u.d.) 9 iOS: iOS (known as iPhone OS prior to June 2010) is Apple's mobile operating system. Originally developed for the iPhone, it has since been extended to support other Apple devices such as the iPod Touch, iPad and Apple TV. (Wikipedia: iOS(Apple) u.d.) 10 HTML5: is the next major revision of the HTML standard, currently under development. (Wikipedia:HTML5 u.d.) 11 CSS3: Cascading Style Sheets (CSS) is a style sheet language used to describe the presentation semantics (the look and formatting) of a document written in a markup language. CSS3 stands for CSS level 3 and is the next generation CSS. (Wikipedia:CSS u.d.)

14

Web Apps Native Apps

Technology HTML, CSS, JavaScript Cocoa, Objective-C, Android

Deployment Web Server App Store, Android Market

Installation & Updates Not required, just hit refresh Needs to be downloaded or

deployed by developer

Offline usage No Yes

Initializing Open bookmark or insert URI Click the application icon

Database No Yes

User Experience Very good but it depends on the

web browser, hardware and age

of the device.

Very good as they are developed

for specific devices.

TABLE 1: COMPARISON BETWEEN NATIVE- AND MOBILE WEB APPLICATIONS.

15

2.6 Android

Android is an open mobile phone platform that was developed by Google and, later, by the Open

Handset Alliance. Google defines Android as a "software stack" for mobile phones. The Android

platform promised openness, affordability, open source code, and a high-end development

framework.

It is made up of the operating system; the platform on which everything runs, the middleware; the

programming that allows applications to talk to a network and to one another, and the applications;

the actual programs that the phones will run. In short, the Android software stack is all the software

that will make an Android phone an Android phone.

Android is based on the Linux operating system. All of its applications will be written using the Java

programming language and includes a set of core libraries that provides most of the functionality

available in the core libraries of Java. Android relies on Linux version 2.6 for core system services such

as security, memory management, process management, network stack, and driver model. The kernel

also acts as an abstraction layer between the hardware and the rest of the software stack.

Google says Android will ship with a set of core applications including email client, SMS program,

calendar, maps, browser, contacts, and more (Android Developers u.d.).

FIGURE 7: OFFICIAL ANDROID LOGO (ANDROID

DEVELOPERS U.D.)

FIGURE 6: HIGH-LEVEL VIEW OF THE

ANDROID SOFTWARE STACK

16

Anyone can download an Android software development kit (SDK) from Google and write an

application for Android. (About.com u.d.); (Android Developers u.d.) By providing an open

development platform, Android offers developers the ability to build extremely rich and innovative

applications. Developers are free to take advantage of the device hardware, access location

information, run background services, set alarms, add notifications to the status bar, etc.

Developers have full access to the same framework Application Programming Interfaces (API)12 used

by the core applications. The application architecture is designed to simplify the reuse of components;

any application can publish its capabilities and any other application may then make use of those

capabilities. This same mechanism allows components to be replaced by the user. (Android

Developers u.d.) All necessary resources for Android development can be found at the official

Android developer site: http://developer.android.com/dalvik

2.6.1 Dalvik and the Java Virtual Machine

A Java Virtual Machine (JVM) is an application that translates platform-independent Java bytecode

into computer-specific machine code, or which interprets that bytecode during runtime. A bytecode is

a set of characters generated by a Java compiler as an output of compiling a Java program. The

conversion of bytecode into machine code for the specific computer makes it easy to run a Java

application regardless of the computer's operating system and hardware configuration. (Bakshi,

Khanna och Mishra 2003)

As part of Android, Google has spent a lot of time thinking about optimizing designs for low-powered

handheld devices. The performance requirements on handsets are severe as a result, requiring handset

designers to optimize everything. The packages in Android are full-featured and extensive. According

to Google, these system libraries might use as much as 10 to 20MB, even with their optimized JVM.

These issues led Google to revisit the standard JVM implementation. (Hashimi, MacLean och

Komatineni 2010). Dalvik is the name of the virtual machine (VM) in Google's Android operating

system. Like the rest of Android, it is open-source software. It was originally written by Dan

Bornstein, who named it after the fishing village of Dalvik in Iceland. Android applications are

converted into the compact Dalvik Executable (.dex) format, which is designed especially for Android

to run on embedded system, suitable for systems that are constrained in terms of memory and

processor speed. The .dex files can be downloaded onto the mobile handsets and run.

12 Application Programming Interface (API): is a particular set of rules and specifications that a software program can follow to access and make use of the services and resources provided by another particular software program that implements that API. It serves as an interface between different software programs and facilitates their interaction, similar to the way the user interface facilitates interaction between humans and computers. (Wikipedia:API u.d.)

17

2.6.2 XML based layout

In Android it is possible to create a user interface (UI) purely through Java code but a more common

approach is to use a so called XML-based layout file. When using XML-based layout the view for a

screen is loaded from an XML-file (these files are called layout resources). A layout resource is an

essential key resource used in Android UI programming (Hashimi, MacLean och Komatineni 2010).

The advantage to declaring the UI in XML is that it enables better separation of the presentation of the

application from the code that controls its behaviour. The UI descriptions are external to the

application code, which means that it can be modified or adapted without having to modify source

code. For example, XML layouts can be created for different screen orientations, different device

screen sizes, and different languages. Additionally, declaring the layout in XML makes it easier to

visualize the structure of the UI and it is easier to debug13 problems (Android Developers u.d.).

2.6.3 Guidelines

The Android UI team has developed guidelines for the interaction and the visual design of Android

applications. There are also some best practices regarding Android compability, supporting multiple

screens, designing for performance, designing for responsivness, and designing for seamlessness. A

more exhaustive review of the best practices can be found at the official android developer pages (next

page):

User Interface guidelines:

http://developer.android.com/guide/practices/ui_guidelines/index.html

Compatibility:

http://developer.android.com/guide/practices/compatibility.html

Supporting Multiple Screens:

http://developer.android.com/guide/practices/screens_support.html

13 Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware, thus making it behave as expected. (Wikipedia: Debugging u.d.)

18

Designing for Performance:

http://developer.android.com/guide/practices/design/performance.html

Designing for responsiveness:

http://developer.android.com/guide/practices/design/responsiveness.html

Designing for Seamlessness:

http://developer.android.com/guide/practices/design/seamlessness.html

19

2.6.4 Android API levels

When developing application on Android, it is useful to understand the platform's general approach

to API change management (Android Developers u.d.). It is important to understand the API Level

identifier and the role it plays in ensuring application's compatibility with devices on which it may be

installed. API Level is an integer value that uniquely identifies the framework API revision offered by

a version of the Android platform. (Android Developers u.d.)

TABLE 2: SOURCE:ANDROIDDEVELOPERS:HTTP://DEVELOPER.ANDROID.COM/GUIDE/APPENDIX/API-

LEVELS.HTML AND WIKIPEDIA: HTTP://EN.WIKIPEDIA.ORG/WIKI/ANDROID_(OPERATING_SYSTEM)

Platform Version API Level Name Deployed

Android 4.0 11 Ice Cream (mid 2011)

Android 3.0 10 Honeycomb (early 2011)

Android 2.3 9 Gingerbread Dec 2010

Android 2.2 8 Froyo

Android 2.1 7 Eclair Jan 2010

Android 2.0.1 6 Eclair Dec 2009

Android 2.0 5 Eclair Nov 2009

Android 1.6 4 Donut Oct 2009

Android 1.5 3 Cupcake May 2009

Android 1.1 2 - Feb 2009

Android 1.0 1 - Sep 2009

20

The following pie chart and table is based on the number of Android devices that have accessed

Android Market within a 14-day period ending on the data collection date noted below (Android

Developers u.d.).

TABLE 3: TABLE OF DATA COLLECTED DURING TWO WEEKS ENDING ON JANUARY 4, 2011. (ANDROID

DEVELOPERS U.D.)

Platform API Level Distribution

Android 1.5 3 4,7 %

Android 1.6 4 7,9%

Android 2.1 7 35,2%

Android 2.2 8 51,8%

Android 2.3 9 0,4%

FIGUR 8: PIE CHART OF DATA COLLECTED DURING TWO WEEKS ENDING ON JANUARY 4, 2011. (ANDROID

DEVELOPERS U.D.)

21

2.7 Human Computer Interaction Evaluation Techniques

Evaluation of a product includes not only why evaluation is important but also what aspects to

evaluate, where evaluation should take place, and when to evaluate. This is called “The why, what,

where and when of evaluation” and describes generally what factors to be considered when

evaluating a product.

There are three different main evaluations approaches. Each of these is based on a distinct set of

values and assumptions as to how evaluation should be done. The three approaches are usability

testing, field-testing and analytical evaluation. Each of the three approaches has several methods

associated with it. The methods used in evaluation are: observing users, asking users, asking experts,

user testing, inspections and modelling users’ performance. Some approaches use the same methods.

The different approaches are described in brief in the following sections, however, these different

approaches are often combined to get a broad understanding of the efficacy of a design (Preece,

Rogers och Sharp 2007).

2.7.1 Usability testing

Usability testing involves measuring typical users performance on tasks. The defining characteristics

of usability testing are that the evaluator controls the test environment and the format of the testing.

Users are sometimes watched and videotaped while performing tasks. Tests are generally performed

in controlled lab environments where users are isolated from their everyday life, e.g. phones are

switched off and there is no possibility of checking email. Commonly users perform tasks where the

evaluator noting the number and kinds of errors that the users make and recording the time that it

takes them to complete the task. User satisfaction questionnaires and interviews are also used to elicit

user opinions (Preece, Rogers och Sharp 2007).

2.7.2 Field studies

Unlike usability testing field tests are done in a natural environment with the aim of understanding

what users do naturally and how a product is used in that context. The basic techniques for field-

studies are data gathering through interview, observation and sometimes through questionnaires

(Preece, Rogers och Sharp 2007).

22

2.7.3 Analytical evaluation

In analytical evaluation two methods are considered; inspections and theoretically based models. The

first one includes heuristic evaluation and walkthroughs and the latter are used to predict user

performance. The two different types of inspections are described in more detail below. (Preece,

Rogers och Sharp 2007)

Walkthroughs:

An expert evaluates by walking through scenarios with prototypes of the application and users do not

need to be present. One type of walkthrough is cognitive Walkthrough. In Cognitive walkthroughs a

user problem is simulated and walked through in five different steps:

- The characteristics of a typical user are identified. A prototype is made and relevant tasks are

produced to perform the evaluation.

- A designer and one more expert come together to perform the walkthrough.

- The evaluators walkthrough the tasks and try to answer three questions; Will users know

what to do? Will they see how to do it? Will they understand from feedback whether the

action was correct or not?

- An error record is compiled including e.g. critical information about what caused the

problems and design issues.

- The design is revised to fix the problems presented. (Preece, Rogers och Sharp 2007)

Heuristic evaluation:

Heuristics evaluation is a usability inspections technique in which experts evaluates a product from

different guidelines. These guidelines are called heuristics and were originally developed by Jakob

Nielsen for screen-based products and can be used in any stage of the design process. It is important

to remember that experts and not users perform this kind of evaluation. (Preece, Rogers och Sharp

2007)

23

2.7.4 Planning the evaluation – The DECIDE Framework

While planning what type of evaluation techniques and models to be used in a project a framework

can be helpful. The DECIDE framework provides a checklist to plan evaluations. It has the following

six items (all items equally important):

Determine the goals: Identifying the high-level goals of the evaluation is the first step in planning an

evaluation.

Explore the questions: In order to make goals operational appropriate questions must be well

formulated. Consider that the answers will be used in the analyze part.

Choose the evaluation approach and methods: Depending on the goals and questions formulated in

earlier stages the evaluation approach is chosen. Often a combination of methods and approaches are

used.

Identify the practical issues: It is important to identify the practical issues before starting the

evaluation. A rule of thumb is to start with a pilot study with a small amount of users before

performing the study on several participants. Practical issues can be related to users, facilities,

equipment, and schedule and budget constraints.

Decide how to deal with the ethical issues: All data gathering requires consideration of ethical issues.

For example people privacy information should be protected. Depending on the type of evaluation

different levels of caution must be applied.

Evaluate, analyze, interpret, and present the data: As mentioned in the “Explore the question” part

these items are closely related to each other. Decisions must be made about what data is needed to

answer the questions since this is the source of the analyze part. How data will be analyzed and

presented must also be concidered. (Preece, Rogers och Sharp 2007)

2.7.5 Data gathering techniques

Choosing which data gathering techniques to use depends on a variety of factors e.g. to the focus of

the study, the participants involved, the product to be examined and the resources available. There is

no right technique but it is important to take all the mentioned factors into account and the chosen

technique must be compatible with the evaluation goal. It is common to combine different techniques

in order to get a wide basic data. This strategy is called triangulation and provides different

perspectives and evidence of findings across techniques. The most commonly used techniques for

data gathering are described below:

24

Data recording: The most common forms of data recording include taking notes, audio recording,

taking photographs, and video recording. For video- and audio recording it is valuable to have the

opportunity to observe the material several times when analyzing data. One concern is that

participants may feel uncomfortable while being recorded. Regarding taking notes sometimes it is

hard to listen and observe at the same time.

Interviews: An interview is conducted in real time, which makes it easier to assist with answers to

questions. Samples and additional products can be showed and evaluated and it is easy to control the

rate of survey completion. Some concerns can be that it is sometimes hard to find people to participate

in the interview. Participants might feel uncomfortable by answering questions they consider too

private and interviews can be relatively inefficient and time consuming compared to e.g.

questionnaires.

Questionnaires: Questionnaires is a quick and effective method. It is possible to hand out the

questionnaire to several people at the same time and a questionnaire-based survey does not have to be

conducted in real-time and can be completed anywhere anytime. Sensitive issues can be discussed

more easily. Some concerns worth mention is that the answers are static and can give rise to

misunderstandings. People must be motivated to answer and it is easy to ignore a questionnaire. If the

answers are unclear it is not possible to get it clarified.

Observation: Observation can take place in different settings, both in controlled environments and in

the field. The technique relies on the observers’ ability to gather data about actual behaviour. Some

concerns to mention is e.g. that the participant can act differently when watched. (Preece, Rogers och

Sharp 2007)

2.7.6 Analyzing Data

Quantitative data is data that is in the form of numbers, or that can easily be translated into numbers.

For example, a thing that is easily measured as the number of minutes it takes to perform a task or the

age of a participant. Qualitative data is hard to measure and is hard to express in numerical terms.

Examples of that are the comments fields on questionnaires.

To analyze data gathered from questions, two different answers are possible: answers from open

question or answers from closed questions. There are two definitions that are used to describe closed

questions. A common definition is that a closed question can be answered with either a single word or

a short phrase. A more limiting definition is that closed question can be answered with either 'yes' or

'no'. Examples of closed questions are “Are you happy?” or “How old are you?” An open question is

likely to receive a long answer. Although any question can receive a long answer, open questions

25

deliberately seek longer answers, and are the opposite of closed questions. Examples of open

questions are “Why did you do that?” or “How do you keep focused?” Closed questions are likely to

be analyzed quantitatively and open questions qualitatively. (Preece, Rogers och Sharp 2007)

26

3. Method

The Android version of DreamTeam to be implemented will

serve as one of the possible clients in a client-server model.

The client will communicate with the server through the

cloud with REST’s GET- and POST techniques over HTTP

where URIs represent different states in the system.

DreamTeam for Android will be implemented as a cloud

based native mobile application and function as a “platform

as a service” (PaaS) product. The figure to the right shows a

high level overview of the architecture, next chapter (4:

Architecture) covers the architecture in full.

The software implementation part follows Capgemini

standards and methologies used in the Accelerator project.

Evaluation techniques are compiled by means of the

DECIDE framework described in the theory part 2.7.2 and

has resulted in the conclusion to use the human computer

interaction techniques; field studies and web-based

questionnaires for the usability evaluation part.

Testing will be performed in two phases, expert testing and

monkey testing14. These two will be combined with unit

tests during the whole process.

The current situation at Capgemini regarding staffing, sales,

managing, and what DreamTeam can contribute to

Capgemini is based on interviews with the project sponsor

and employees in relevant positions at the staffing division and

account management.

14 See chapter 8.2.

FIGURE 9: HIGH LEVEL OVERVIEW OF

ARCHITECTURE

27

4. Architecture

This chapter explains the underlying architecture that the Android DreamTeam application will

communicate with. It is built on well-known technologies and standards to ease the modularization of

the system as well as link the modules. It is focused mainly on open standards, as this will help the

system evolve to meet new demands. The main goal when the architecture was developed was to

create a platform for future extension while at the same time be as simple as possible with regards to

development, run, and maintenance. The architecture is designed to make use of the functionality in

the standard products as far as possible. (Forsberg 2010). Below a

high level model describes the architecture:

User: User of the system will be Capgemini employees.

Clients: The system will support three different types of clients,

iPhone, Android and a web interface.

Facade: The facade communicates with the clients through strings

and JSON. The client sends a String and gets a JSON as response.

Service: The Service communicates with the Facade through strings

and a Data Object (DO). The Facade sends a String and gets a DO as

response.

Model: The Model communicates with the Service through a Request

and a Database Object (DBO). The Service sends a Request and gets a

DBO as response.

Back end and external systems: The system should make use of the

functionality in existing internal backend systems such as e.g. the

internal Capgemini systems “Skills DB” and “Retain”. The Skills DB

contains all consultants’ skills and CVs and the Retain system contain

all information about availability and occupation level. The two

systems are connected and share some data.

Security: Due to the sensitive and valuable information that exists in the

systems the question about if- and how to deal with connections to

external applications such as DreamTeam have been declined temporarily. Therefore, in the first

iteration, the goal is to create a stand-alone server implementation that supports the mobile

application in terms of functionality and information.

FIGUR10: HIGH LEVEL MODEL OF THE

UNDERLYING DREAMTEAM ARCHITECTURE

28

4.1 Mobile Service

The Mobile Service provides the back-end functionality for the application and takes care of the

storage and logic that DreamTeam depend on. It builds on a class: DreamTeamResource, and the class is

responsible for handling requests from clients. The client sends a request to the REST service, and the

service sends a respond back to the client. The request is a URI and the response is a string

representation of one or several JSON object(s) of the requested object/action. If any error happens

during the transaction, an error message is returned. The error message has the following syntax:

{error: message}. The client-server model is displayed in the figure below:

FIGURE 11: CLIENT-SERVER MODEL

29

4.1.1 Mobile Service Methods:

The methods in the DreamTeamResource class that are used for the Android version of DreamTeam

are described below. The methods are named with the following convention:

“MethodName (input parameters): Method description”

AddDevice(deviceID, userID): Adds a new device into the database, connected to a specific user.

AddFavorite(userID, personID): Adds a person as a favorite to a user.

AddOrUpdateUser(userID, name, deviceID): Adds or updates a user to the database.

AddTeam(userID, name): Add a team to the database for the specific user.

AddTeamMember(personID, teamID): Adds a person to a team.

AddUser(name): Adds a new user to the database.

DeleteUsers(userID): Delete users.

GetFavorites(userID): Get favorites (persons) for a specific user.

GetTeam(teamID): Get a team with a specific database id.

GetTeamMembers(teamID): Get all team members from a specific team.

GetTeams(userID): Get teams for a specific user (owner/creator).

IsFavorite(userID, personID): Check if a person is a favorite for a user.

RemoveFavorite(userID, personID): Removes a person as a favorite from a user.

RemoveTeam(teamID): Deletes a team from the database.

RemoveTeamMember(personID, teamID): Removes a person from a team.

SearchPersons(criteria): Search the database after persons with corresponding tags.

UpdateTeam(teamID, name): Updates a team's name, for the specific team with the teamID.

30

4.2 Data model

The data model shows an overview of the data that the system handles:

FIGURE 12: OVERVIEW OF THE DATA THAT THE SYSTEM HANDLES

As shown in the data model above, each user is activated in the system by adding a device, and then

the user is identified by the device, effectively doing an automated authentication. Each user has a

number of favorites and teams that include a number of people. (Forsberg 2010)

31

5. Requirements and Use Cases

The requirements and use cases for the iPhone version of DreamTeam are described in a Capgemini

project document “Software Requirements Specification”. For the Android version the requirements

and use cases derive from that document but have been modified to fit in an Android specific

environment.

5.1 Users

The future users of the Android version of DreamTeam will be employees at Capgemini that use an

Android phone as corporate phone in their daily work. Users are expected to be experienced, which

implies a extensive understanding of how to use the device e.g. knowledge of how to navigate

Android specific menus- and hardware.

5.2 Requirements

The requirements are collected in groups; each group has a matching activity in the application UI and

this structure is explained further in the next chapter (6. Implementation). Each requirement group

are named with “R” followed by its corresponding number. Some requirements are equal but exist in

different parts of the application and are therefore mentioned several times.

5.2.1 Team

R01. Teams: Allow the user to add, remove, and view teams.

R01.1 Add Team

R01.2 Remove Team

R01.3 View and scroll Team list

32

R02. Team members: Allow the user to view team as well as, add- and remove team members.

R02.1 View and scroll Team member list

R02.2 Add Team member

R02.3 Remove Team member

R03. View Consultant: Allow the user to view details about a person.

R03.1 View person resume

R03.2 Add to Team

R03.3 Add to Favorites

5.2.2 Search

R04. Search Person: Allow the user to search for a person to view, add to a team, or favorite list.

R04.1 Search for a person by competence

R04.2 Search for a person by name

R05. Search Result List: Allow the user to view search results

R05.1 View and scroll result list

R05.2 Add person to Team

R05.3 Add person to Favorites

33

5.2.3 Favorites

R06. View Favorites: Allow the user to view favorite persons.

R06.1 View and scroll Favorite list

R06.2 Add Favorites

R06.3 Remove Favorite

5.2.4 Info

R07. View Info: Allow the user to view info about the application.

R07.1 View Info

34

5.3 Use Cases

All use cases have a matching activity in the application UI and this structure is explained further in

the next chapter (6. Implementation). Each use case is named with “UC” followed by its

corresponding number.

5.3.1 Team

UC01. Manage Teams: Allow the user to view, add, edit team name, and remove teams.

Pre: User at any dialog with the main menu visible

1. User select "Teams"

2. System show a list of teams

3. User can scroll the list of teams, and select a team in the list to view its details (see UC02.

Manage Team)

4. User select "Add Team"

5. A dialog box appears

6. User enter team name and confirm by selecting "Add" button

7. System add team

8. User long press a team name

9. An “Edit Team” menu appears

10. User select “Remove Team”

11. System remove team

12. User long press a team in the list

13. An edit menu appear

14. System show keyboard and allow editing of the team name

15. User select "Ok" and system updates the new team name

16. User select a team in the list (see UC02. Manage Team)

UC02. Manage Team: Allow the user to view team as well as view, add, and remove team members.

Pre: User selected or added a new team (see UC01. Manage Teams)

1. System show a list of team members

2. User can see the team's name as well as scroll the list of its members, and select a member in

the list to view details (see UC04. View Person)

3. User long press a person in the list

4. An edit Team Member menu appear

5. User select “Remove Team Member”

6. System removes team member from team

7. User select “Add Team Member” from main menu and System allows searching for new team

members (see UC03. Search Person)

35

UC03. View Person: Allow the user to view details about a person.

Pre: User selected to see details about a person (see UC02. Manage Team, UC05. Search

Person, and UC06. View Favorites)

1. System show name, title, availability, tags, and a text description of a person

2. User select to add person to favorites or team (button with a plus sign)

3. System show confirmation that person was added to team or favorites

4. User select phone button

5. A “Choose number to call” dialog box appears

6. User chooses number and the phones call activity is started

7. User selects email button

8. A “Complete action using” dialog box appears

9. User selects preferred email program (e.g. gmail or other) and email activity is started

5.3.2 Search

UC04. Search Person: Allow the user to search for a person to add to a team.

Pre: User selected to add a new team member (see UC02. Manage Team) or pressed the Search

button in the main menu or user selected to add a new favorite.

1. System shows search box and keyboard.

2. User enters tags or name to search for and press “Go” or the magnifier symbol to perform the

search.

3. System show persons with matching tags and/or names in list

4. User select a person in the list of persons, see UC04. View Person

5. User long press a person in the list, see UC05. View search results

UC05. View Search Results: Allow the user to view search results

Pre: User has performed a search (UC03. Search Person)

1. System shows a search result list

2. User long press a person in the list

3. An “Add Consultant to”- menu appears

4. User adds person to Favorites or a Team

5. System shows confirmation that person was added and return to search result list (step 1).

6. User select a person in the list of persons

7. System shows details about a person, see UC04. View Person

36

5.3.3 Favorites

UC06. View Favorites: Allow the user to view and add favorite persons.

Pre: User at any dialog with the main menu visible

1. User select "Favorites"

2. System shows a list of favorite persons

3. User long press a person

4. A “Edit favorite” dialog box appears

5. User choose ”Remove Favorite”

6. System removes person from favorites

7. User select “Add Favorite” from the main menu

8. The Search action starts, see UC03. Search Person

5.3.4 Info

UC07. View Info: Allow the user to view info about the app.

Pre: User at any dialog with the tab bar visible

1. User select "Info"

2. System show info about the app

37

6. Implementation

The initial implementation phase included making decision about design and the general

implementation idea. An important part when developing for Android is to handle threads in an

appropriate way. This was considered as well as security, UI-design issues, and Android specific

matters.

6.1 Activities

The basic unit of an Android application is an “Activity”. An Activity displays the user interface of an

application, which may contain widgets like buttons, labels, text boxes, etc. Typically XML files are

used to define the UI. During runtime, the XML UI loads in the onCreate() event handler in the

Activity class. During compilation time, each element in the XML file is compiled into its equivalent

Android UI class, with attributes represented by methods. The Android system then creates the UI of

the Activity when it is loaded. While it is always easier and recommended to build UIs using a XML

file, there are times where the UI needs to be bulit dynamically during runtime (for example, when

writing games). Hence, it is also possible to create the UI entirely using code. (Android Developers

u.d.) In DreamTeam the XML and logic are separated as much as possible.

An Activity contains “Views” and “ViewGroups.” A View is a widget that has an appearance on

screen. One or more Views can be grouped together into a ViewGroup. A ViewGroup (which by itself

is a special type of View) provides the layout in which you can order the appearance and sequence of

views. Examples of ViewGroups are e.g. LinearLayout, and FrameLayout. In DreamTeam different

ViewGroups are used and combined in the UI to achieve the desired result (Android Developers u.d.).

6.1.1 Main Activities

Both the UI and the general implementation build upon four main activities. All main functionalities

start in these activities and the use cases and requirement groups described earlier corresponds to

these four activities:

- Team: This activity displays all teams in a list.

- Favorite: This activity displays all favorites in a list.

38

- Search: This activity handles person search.

- Info: This activity displays information about the application.

The dialog model for the application is shown in the figure below:

FIGURE 13: DIALOG MODEL DREAMTEAM

39

6.2 Android specific hardware

When designing for Android there are features that distinguishes Android devices from other devices

that has to be considered, e.g. buttons tied to the hardware. Typically an Android device has the

following buttons as a default setup:

- Back button: Navigate from the current activity to the previous activity.

- Main menu button: Shows the main menu that belongs to the current application running.

- Home button: Navigates from the current activity running to home screen

- Search button: Activates a search activity within the current application running.

In DreamTeam all these buttons have an active functionality within the application and future

DreamTeam users are expected to interact with the application through these.

6.3 Android specific design implementation

When navigating in lists an action called “long press” is used to interact with a specific list item. When

performing a “long press” a list item is pressed for 1-2 seconds until a menu appears with menu-item-

specific options. For a beginner this interaction is not obvious but since the contemplated DreamTeam

user is expected to be relatively experienced, and therefore expects to interact with their devices

unimpeded, long press will be used as a part of the implementation.

6.4 Menus and Navigation

Menus are an important part of applications that provide a familiar interface for the user to access

application functions and settings. Android offers an easy programming interface to provide

application menus in applications. Android provides three types of application menus:

- Option menu: The primary menu for an Activity, which appears when the user presses the

device MENU key.

- Context menu: A floating list of menu items that appears when the user performs a long-press

on a View

40

- Submenu: A floating list of menu items that the user opens by pressing a menu item in the

Options Menu or a context menu. A submenu item cannot support a nested submenu.

(Android Developers u.d.)

DreamTeam implements Option menu and Context menu. The option menu holds the main menu and

the context menu are used for all long press actions in lists.

Each activity can be reach from a main menu at all times in the application lifecycle. When starting the

application the main menu has four options, namely the same options as the main activities

mentioned above. When navigating through the application the main menu changes to suit the

current activity. The activity specific menu option is always placed at the top right corner of the

menu.

As mentioned, all actions on list items are made with long press, which is a recommended way of

interacting with lists according to Android developers. (Android Developers u.d.)

6.5 Navigation in DreamTeam Activities

This section describes examples of how essential requirements are implemented in each main activity.

6.5.1 Search

The search option is reached in three different ways.

- When adding a team from the Team Member List views.

- When pressing the “Search” option in the main menu.

- When pressing the hardware Search button.

The search results are displayed in a search result list and users interact with each item via long press.

Depending how the search activity is reached the list activated by long press looks different. If

entering from a current team only two options are visible: “Add to Team” and “Add to Favorites”. If

entering from any of the two other options all teams are visible in the list.

41

6.5.2 Team

Add team

To add a team the user press the “Add Team” option in the main menu and enter a desired team

name in a dialog box that appear.

Add team member

There are three different ways of adding a team member to a team:

- From the “Add Team Member” option in the main menu in the team-member-list activity.

This option starts the search activity and consultants are added via long press in the search

result list. Only the “Add to Favorite” and “Add to Team” options are available. If entering

from pure search alternatives all teams are available in the list.

- Via the “Add” button in the Person View. Depending on how the view was reached the

button shows different options. If entered from a current team only the “Add to Favorite”

option is available. If entered from pure search alternatives all teams are available in the list.

Delete team

A team is deleted by performing long press on a team in the team list and choose “Remove Team”.

Delete team member

A team member is deleted from a team by performing long press on a team member in the Team

Member List And choosing “Remove Team Member”.

42

6.5.3 Favorites

Favorites can be added in three different ways:

- Via the main menu option “Add Favorites” in the Favorite activity. This option starts the

search activity and consultants are added via long press in the search result list.

- Via the “Add” button in the Person View and chose “Favorites”.

6.5.4 Info

The info view is reached by pressing the “Info” option in the main menu.

43

6. 6 Communications

The Android DreamTeam application communicates with a database through URI:s and JSON-strings.

The request is a URI and the response is a string representation of one or several JSON object(s) of the

requested object/action. If any error happens during the transaction an error message is returned.

Whenever data is needed it is fetched from the database, the applications stores or caches no data on

the actual device. Consequently, when data is updated this data is received directly from the database.

6.7 Threads

When an application is launched, the system creates a thread called "main" for the application. The

main thread, also called the UI thread, is very important because it is in charge of dispatching the

events to the appropriate widgets, including drawing events. It is also the thread where your

application interacts with running components of the Android UI toolkit.

This single-thread model can yield poor performance unless the application is implemented properly.

Specifically, if everything is happening in a single thread, performing long operations such as network

access or database queries on the UI thread will block the whole user interface. No event can be

dispatched while the long operation is in progress. From the user's perspective, the application

appears hung. Even worse, if the UI thread is blocked for more than a few seconds (about 5 seconds

currently) the user is presented with the infamous "application not responding" (ANR) dialog.

To sum up, it is vital to the responsiveness of the application's UI to keep the UI thread unblocked.

(Android Developers u.d.) If there are long operations to perform they should always be done in extra

threads. With this in mind, DreamTeam create one new thread for every action that communicates

with the database.

6.8 Database

The initial thought was to connect DreamTeam with two external systems; the internal Capgemini

systems “Skills DB” and “Retain”. The Skills DB contains all consultants’ skills and CVs and the Retain

system contains all information about availability and occupation level. The two systems are

connected and share some data.

44

Due to the sensitive and valuable information that exists in the systems the question about if- and how

to deal with connections to external applications such as DreamTeam have been declined temporarily.

To solve the problem a pilot database was developed (Chapter 4: Architecture). The database contains

approximately 100 consultants and information about name, title, phone, email, availability,

summary, and tags (competence key words). To make data dynamic a web client is under

development where users can update all their personal information to (outside the scope of this

master thesis). Since the web client is currently developed most of the data remain static. The

availability data is imported from a excel sheet fetched and updated from the retain system every

Friday.

6.9 Security

Every mobile phone has a unique identifier, an IMEI number, received by entering *#06# into the

keypad on most phones. This identifier is used as a unique device identifier in the database and to use

DreamTeam the device ID needs to be registered in the database. Users can have more than one device

and all combinations of users with specific devices have another identifier in the database called “id”.

Since no data is stored on the device the risk of losing valuable corporate information decreases. If a

device is lost or stolen it is enough to remove that device IMEI number from the database to obtain

security and prevent unauthorized people to gain access to confidential corporate information.

6.10 Environment

The Android SDK provides the tools and APIs necessary to begin developing applications on the

Android platform using the Java programming language. Android and Eclipse provide The Android

Development Tools (ADT) plugin for Eclipse which was used in the DreamTeam code

implementation. This adds powerful extensions to the Eclipse integrated development environment

and allows creating and debugging Android applications easier and faster. It also includes Android

Virtual Device (AVD), a device configuration for the built in emulator that model real world devices.

The emulator was used to a great extent during the implementation phase and was replaced by a real

device, a Google Nexus One mobile, in the final implementation stage.

45

7. DreamTeam walk-through

This chapter includes a walk-through of the final DreamTeam application. Teams are created in

beforehand to express a realistic look of the application.

7.1 Start screen

This view is shown as start screen of the application when no buttons are

pressed.

7.2 Main Menu

This view shows the start screen when the hardware MENU button is

pressed and the main menu is active. The menu shows four options, three

main activities and one activity specific option: Add Team. The activity

specific menu option is always placed at the top right corner of the menu.

46

7.3 Add Team

The first view shows the dialog box

that appears when the “Add Team”

button is pressed on the main menu

(see previous view: Main menu). The

second view shows the updated team

list.

7.4 Add Team Members

The first view shows the newly added

team that is empty when the main menu

button is pressed. The second view

shows the search screen that appears

after the “Add Team Member” button is

pressed.

47

7.5 Search

The first view shows when text is

inserted in the search bar. The

second view shows the search

result for the tag “telecom”, 28 hits.

7.6 Long Press

The first view shows the context

menu that appears when

performing long press on a list item

in the search result list. The second

view shows the updated team

member list view when a person is

added to the team.

48

7.7 Person View

This view shows the consultants’ personal details, including name, title,

availability, summary, and tags. The two buttons in middle of the

screen enables the options to call or email the consultant. The button in

the top right corner is described next.

7.8 Add from Person View

This view shows the context menu that appears when pressing the add

button on the person view screen (see previous view: Person View).

Depending on from where the Person View is reached, different

options appear in the menu. If the person is already in a team only the

“Favorites” option appear. Otherwise, as seen in the picture, all teams

appear as options in the list.

49

7.9 Remove

The first view shows the dialog that

appears when long pressing a team

member in the team member list. The

second view shows the same scenario

but when long pressing a team in the

team list.

7.10 Indicators

These views show some of the indicators used.

50

8. Tests

The testing part was divided in two stages, expert- and Monkey testing. In addition to this unit tests

were performed throughout the whole implementation phase. During the expert testing the

application was tested by experienced mobile application developers and testers, and during the latter

testing part the application was subject to extensive monkey testing.

8.1 Expert Testing

During the expert testing phase, three experienced mobile application developers and one mobile

application tester from Capgemini tested the application. The tests were performed with focus on

finding bugs and errors and to detect all kinds of possible issues with the Android version of

DreamTeam. The expert testing was performed during the implementation phase combined with the

unit tests and, more exhaustive, immediately after. This setup was essential for the final result.

One important tool used during this phase was a “logcat”- tool application from Android Market

called “aLogCat”. The logcat is provided by the Android logging system and is a mechanism for

collecting and viewing system debug output. Logs from various applications and portions of the

system are collected in a series of circular buffers, which then can be viewed and filtered by the logcat

command. The tag of a log message is a short string indicating the system component from which the

message originates (Android Developers u.d.). The “aLogCat” application enables the logcat on the

device and error logs for specific bugs could be identified immediately and reported via email.

Some examples of errors and bugs that were identified in the expert testing phase and fixed before the

usability evaluation part:

- Problems regarding frequently switching between disabled- and enabled network connection.

- Problems regarding horizontal and vertical state.

- Problems regarding incorrect thread handling.

- Inconsequent menu structure.

- Problems regarding unhandled Exceptions.

51

8.2 Monkey

The Monkey is a program that can be run on the emulator or device and generate pseudo-random

streams of user events such as clicks, touches, or gestures, as well as a number of system-level events.

Monkey can be used to stress-test applications, in a random yet repeatable manner. The Android

version of DreamTeam was launched with 1000 - 10000 pseudo-random events to force the application

to crash.

52

9. Usability Testing- and Evaluation

To plan what type of evaluation techniques and models to be used for the usability evaluation the

DECIDE framework described in the theory part was used. The checklist of six items presented in the

theory was used to define appropriate evaluation techniques for the Android version of DreamTeam

and is applied below:

Determine the goals: The high-level goals of the usability evaluation are to identify possible usability

issues and gather valuable feedback from users regarding how they understand the application.

Explore the questions: In order to make goals operational the main part of the questions must be

formulated as open questions so users give detailed answers instead of e.g. yes or no answers. In this

context it is important to limit the amount of questions, otherwise it is possible that users do not

answer them detailed enough due to lack of interest. Closed questions will be used to identify user

profiles, Android knowledge and to rate the usability. Open questions will be used for more detailed

comments about the usability impression.

Choose the evaluation approach and methods: Since the participants will be spread across the company at

different locations and have various time frames it is preferable to select a flexible evaluation

technique regarding time and location. According to this, field studies including a web-based

questionnaire are suitable. The application will be handed out to a test group of experienced Android

users within Capgemini. The evaluation will be explained further in the next section (8.1: Performing

the Test). To ease the development and guarantee easy access to the questionnaire Google

documents15 will be used. This tool enables a web-based questionnaire to be created and accessed

from arbitrary web browsers. Besides that it gathers the answers and organise them in a perspicuous

spreadsheet.

Identify the practical issues: One major constraint is that all participants must have their own testing

device since, so far, there are no existing testing phones available through the company. As

mentioned, it is important that participants use Android phones in their daily work since the

application is to be used by experienced users. Regarding the questionnaire there will be no practical

issues with equipment since all participants have a Capgemini corporate computer. The questionnaire

will be tested by two persons before it is handed out to the whole group. One practical issue worth

mentioning is that even if participants contribute voluntarily it is always a risk that some people

would not complete the questionnaire due to lack of time or other unexpected factors.

15 Google Documents: Google Docs is free, Web-based word processor, spreadsheet, presentation, form, and data storage service offered by Google (Wikipedia: Google Docs u.d.).

53

Decide how to deal with the ethical issues: The evaluation does not contain any critical information such

as people privacy information or sensitive data, consequently the level of caution will be relatively

low.

Evaluate, analyze, interpret, and present the data: The question part and the analyze part are closely

related to each other. The information gathered from the questionnaire will be analyzed and

presented and will serve as a source for the discussion part. The results of the final application will be

presented as a walkthrough with screen shots. The usability evaluation will be presented with

quantitative- and qualitative data.

54

9.1 Performing the test

The application was sent to a test group containing 18 persons and 19 devices.

All participants in the test group had two similar attributes; they owned an Android mobile phone and

they contributed voluntarily. These two attributes where essential when forming the user group.

Android mobile owners: Since the final DreamTeam application will be used by employees in their

daily work it is likely that the target group are relatively experienced Android mobile phone users.

Therefore it was essential that the people in the user group had a phone that they used regularly.

Voluntary contribution: When choosing profile of the participants it was important that they were

motivated to perform the task completely. Several Android phones owners were asked to participate

but only those who volunteered ended up in the final test group.

It was important to test on a wide range of devices and Android versions. This was well covered with

the devices in the user group. Phones and Android versions used in the usability testing phase are

described in the table below:

Manufacturer Phone model Android version Distribution

HTC Google Nexus One 2.2 3

HTC Hero 2.0 + 2.1 4

HTC Desire 2.2 5

HTC Tattoo 1.6 2

Sony Ericsson X10 2.1 2

Sony Ericsson X10 mini pro 2.1 2

Samsung Galaxy S 2.2 1

Total: 3 Total: 7 Total: 4 Total: 19

TABLE 4: RECORD OF TEST DEVICES

55

The participants were told to imagine using DreamTeam in their daily work and evaluate it according

to that in the web-based questionnaire. The questionnaire is available (in Swedish) in Appendix A.

Users were asked to test the application by performing some specific tasks described below:

- Add 3 teams

- Add consultants to these teams

- Search for consultants by competence

- Search for consultants by name

- Add consultants to your favorites

To capture remaining bugs and errors the test group were told to report all types of issues that might

occur, not only regarding usability defects, and if finding errors report them back. As an extra

supplement interested users had the opportunity to use aLogCat as reporting tool but this was

optional since it requires extended knowledge about Android development that is not expected from

the average user.

56

10. Usability Evaluation Results

Of the 19 people who announced their interest to contribute 15 participated and finished the

evaluation entirely. The next sections display the result in two different groups, quantitative- and

qualitative results.

10.1 Quantitative results

The quantitative results are based on the closed questions in the survey. The closed questions were

used mainly to identify the equipment and users. In spite of some decrease of participant in the group

the wide range of test devices remained intact. The table below shows the resulting device- and

Android version distribution.

Manufacturer Phone model Android version Distribution

HTC Google Nexus One 2.2 2 (3)

HTC Hero 2.0 + 2.1 4 (4)

HTC Desire 2.2 3 (5)

HTC Tattoo 1.6 2 (2)

Sony Ericsson X10i 2.1 1 (2)

Sony Ericsson X10 mini pro 2.1 2 (2)

Samsung Galaxy S 2.2 1 (1)

Total: 3 Total: 7 Total: 4 Total: 15 (19)

TABLE 5: RESULTING DEVICE- AND ANDROID VERSION DISTRIBUTION

57

10. 1.1 Android Experience distribution

Of 15 participants, one was not a daily user. When investigating the answers closer this participant

turned out to be the one that tested DreamTeam on two devices. The participant was a daily user of

one of the two devices. The pie chart below show the result:

FIGURE 14: DAILY ANDROID USERS VS. NOT DAILY ANDROID USERS

Of 15 participants 13 considered themselves as experienced users.

FIGURE 15: EXPERIENCED ANDROID USERS DISTRIBUTION

7%

93%

Not daily user

Daily user

0

2

4

6

8

10

12

14

5 (Experienced)

4 3 2 1 (Beginner)

58

10.1.2 Navigation

This section displays answers on question regarding the navigation in the application. Participants

were told to perform different actions (mentioned in the previous section (8.1. Performing the Test))

and the following diagrams reflect the participants usability expression regarding these actions. The

captions explain the actions performed.

FIGURE 16: ATT TEAM

FIGURE 17: REMOVE TEAM

8

6

1

0

0

0 2 4 6 8 10

Excellent (5)

4

3

2

(Poor) 1

Add Team

7

1

5

1

1

0 2 4 6 8

Excellent (5)

4

3

2

(Poor) 1

Remove Team

59

FIGURE 18: ADD/SEARCH TEAM MEMBER

FIGURE 19: REMOVE TEAM MEMBER

FIGURE 20: VIEW PERSON

3

6

4

2

0

0 1 2 3 4 5 6 7

Excellent (5)

4

3

2

(Poor) 1

Add/Search Team Member

5

6

2

1

1

0 1 2 3 4 5 6 7

Excellent (5)

4

3

2

(Poor) 1

Remove Team Member

10

3

2

0

0

0 2 4 6 8 10 12

Excellent (5)

4

3

2

(Poor) 1

View Person

60

10.2 Qualitative Results

The qualitative results are based on the open questions in the survey. The participants were told to

add their thoughts in comment fields about how things where perceived. This part of the survey

generated several concrete ideas and valuable input. A summary of the gathered information are

presented below and potential appropriate actions will be describes in the discussion chapter (Chapter

12: Discussion).

Installation

All participants except one found it easy to install the application and had no problems during the

installation process. After further investigation it turned out that the participant that encountered the

problem had technical problems with the phone.

UI

The overall impression of the UI was mostly positive while some participants thought it was a bit too

stiff and static and could have had more features. By contrast the participants that were positive

thought the UI was clean and simple and gave a stylistically pure impression and claimed that the

absence of features was an advantage.

Response time

Two participants thought that the response time was a bit slow but did not describe this as a critical

issue. Several participants mentioned they were bothered by the fact that it is not possible to navigate

back while an indication is active, e.g. when performing a search and results are fetched form the

database it is not possible to interact and users have to wait until the task is finished.

Navigation

Some of the participant found it hard to navigate back to the list of team members. The only way back

is the physical back button and sometimes deep down in the navigation flow and the way back to the

current team is many clicks away. This could be solved with a more visible button to navigate directly

to the current team.

No participants made any comments about the long press functionality but a few mentioned that they

found it hard to find the options for deleting a team or team member. Even if most people understood

how to delete teams or team members several desired improvements on this part. As with deleting,

some participants desired improvement when adding a team. Numerous participants fancied the

placement of the “Add to” button in the header and suggested a similar layout for the “Add Team”

functionality.

61

11. Possible development of DreamTeam

By interviewing key persons from the sales- and staffing division about how they would like to use

DreamTeam in their everyday work this sections includes suggestions about how DreamTeam can be

improved and tailored to different roles within Capgemini.

The thoughts and ideas expressed in this chapter are based on interviews with the Capgemini

employees: Johan Ribbeklint, Account Management, and Anna Modigh, Staffing.

11.1 Sales

Johan thinks that the account management could make use of DreamTeam as a complement to

existing tools e.g. the Skills DB. A possible scenario could be when employees transport to and from

clients and need a quick tool to perform searches and then email relevant CV’s to speed up the work

process when arriving to the office. Mainly Johan would use DreamTeam as a tool in the sales dialog

with the client. This, he say, will likely increase confidence towards clients and demonstrate

Capgemini’s effectiveness in a liable way. While account management always communicates with

staffing when trying to find suitable consultants for new and existing projects the DreamTeam

application would decrease the workload for staffing.

To be a complete and widely used product Johan mentions these features to be included:

- It is essential that all consultants at Capgemini Sweden are searchable in the application and

that all data is accessible, otherwise current tools will be used instead.

- Enable ability to search for tags combined with availability and a time frame, e.g. “Architect”

+ “1th February” – 5th February” + “10%”.

- Be able to generate and email a complete CV in pdf-format (or similar) and also be able to

email CV’s related to a whole Team.

- Search for competences and generate a printable list of the people with these competences.

62

11.2 Staffing

Anna thinks that DreamTeam could be used both as a tool “on-the-go” and a complement tool at the

office to speed up staffing employees’ daily work. The account management could make use of the

application if they are unable to contact staffing and are located at the client site with short of time and

no available internet connection for their laptops. She emphasize the importance to include as many

features as possible from existing systems into the application.

To be a complete and widely used product Anna mentions a number of key features to be included:

- Contain a basic reflection of Skills DB and Retain data. Including all skills and all text from the

CVs. It is important to enable “free text search” as they currently use this in the Skills DB.

- Search for tags combined with availability and a time frame or just a “from” date, e.g.

“Architect” + “from 1th February” + “10%”.

- Search for consultants in different units e.g. for all Sweden’s Capgemini consultants or just for

consultants related to Service Industries or to the Stockholm office.

- It must be clear in the search results what unit the consultant belongs to.

11.3 Conclusion

The set of possible features listed above implies that staffing and the account management have

similar requirements. If DreamTeam gets the permission to communicate with Skills DB and Retain a

basic reflection could be implemented. Some of the other features mentioned are already implemented

in one of the other Accelerator applications called “FreeForce”. If integrating some of the features from

FreeForce into DreamTeam and add the reflection from Skills DB and Retain and add the possibility to

print and email CVs, DreamTeam would suit both staffing and the account management.

63

12. Discussion

The discussion is divided in two sections; the first one suggests possible usability improvements for

the Android version of DreamTeam with origin from the usability evaluation and the second part

discusses the overall implementation of DreamTeam and the processes around it.

12.1 DreamTeam Usability

The usability evaluation assembled a valuable overview about the users’ impression regarding

functionality and usability design. Most of the suggestions were related to pure usability issues and

are easily fixed while two issues relate to technical implementation changes. Firstly, several

participants mentioned they were bothered by the inability to interact with the application when

indicators were active. This is a limitation and will be put on the list of suggested adjustments.

Secondly, some participants experienced the application to be slow when the internet connection was

poor. This is because all information is fetched from the database in real-time. To adjust this the whole

procedure has to be modified and reworked. One option is to cache data on the device and make

updates to the database at specific times. This would e.g. shorten the response time when pressing the

back button or updating views.

With its origin in the usability evaluation some changes are suggested for the Android version of

DreamTeam. Several of the issues and suggested improvements gathered from the evaluation were

already discussed during the implementation phase but some suggestions were valuable insights.

After consideration the following improvements were established as possible improvement:

- Improve response time by rework the procedure of if-and-how to handle data on the device.

- Improve the design of email and phone buttons in the Person view to pertain a more “active”

look.

- Improve the behaviour of the indicators and make it possible to interact even when indicators

are active

- Add a warning before deleting a team to reduce the risk of deleting a team by mistake.

- When a new team is created, move the active view to the created team’s member list.

64

- Improve the visibility of how to add- and delete a team or a team member.

- Improve the look of the “Add-to” list in the person view to a more consequent look with all

teams displayed regardless of how the view was reached. If reached from a current team, this

team will be highlighted.

- Change how to add a favorite from a list option to a button with a star symbol.

- Add information to the list items in the team member list that now only includes the name of

the consultant. Suggested additional information can be availability and title.

12.2 DreamTeam Process

The thoughts expressed in this section have its origin in the writer’s reflections during the projects and

an interview with Jonas Winqvist that is the main sponsor of the project at Capgemini.

DreamTeam, together with the other applications in Accelerator, is indeed a step forward for

Capgemini concerning mobile applications. It is important and valuable for a large IT company to be

one of the main players on the market delivering mobile enterprise applications.

The idea and implementation of DreamTeam are promising and its functionality can improve the

staffing of projects and reduce duplication of work, but the current formation is still too static and

need some improvements to reach its full potential. The Android- and iPhone implementations of

DreamTeam need some technical and usability improvements to meet the desired requirements but

these are small fixes that are relatively easily made. A more essential concern is the processes around

DreamTeam and the data in the underlying systems. Below are three things mentioned that need

consideration:

No connection to the Capgemini internal systems; skills DB and Retain:

Since connections with the internal Capgemini systems are rejected due to security reasons for the

moment all new data must be inserted in the new system that is still under construction. Even if the

new tool was finished it takes time to implement a new work flow process for this. Consultants at

Capgemini are used to update their CV in the Skills DB and the new system implies double workload.

Due to this, data remain static in the system. See figure 21 for an illustration:

65

Make use of information from DreamTeam:

To get the most out of DreamTeam several components must work. One of the components is to make

use of the information DreamTeam generates. The figure below illustrates the desired work flow:

FIGUR 21: DREAMTEAM DATABASE CONNECTIONS

FIGURE 22: DESIRED DREAMTEAM WORKFLOW

66

Consultants insert their CV and skills in the system. Users of the application, such as a account

manager or management, make tag searches in the application. The tags searched are saved and later

used when staffing compile statistics of most popular searches each month. The statistics are then

used to recognize trends, e.g. 100 searches for “Java” indicates that there is a call for this particular

skill. Management communicates this to their consultants and asks them to emphasize this in their

CV’s if they hold the skill and if not they can educate suitable consultants with the new skill.

Consultants update their CV’s with the required skills and the circle is closed.

In the current version search-tags are not saved and no statistics can be generated and thereby no

trends can be identified. There exist no repetitive process between managers/staffing and consultants

to coordinate that they have an accurate view of the consultant’s skills and CV.

Add and remove users

One issue that must be handled is how to communicate when to add or remove consultants from the

system. Since there is no functioning work flow processes in the origination for DreamTeam and no

connections to internal systems the Accelerator developed database does not get informed when

consultants quit or are recruited. To obtain a stable system this must be improved.

Updated retain data

The update and import of retain data that is fetched repeatedly from the internal Retain system every

Friday must work properly. It has been problems with the update and test users of the system have

mentioned this as a problem. To make users trust the system it is important that data is updated and

correct.

12.3 Conclusion

In conclusion, DreamTeam is part of a really exciting project with great prospects that still has some

components that need improvement, mainly regarding surrounding work methods but also

technically. It would be valuable for the Accelerator project and Capgemini to accelerate the project

and utilise its full potential within the foreseeable future. The enterprise smartphone application

industry is growing rapidly and the Accelerator framework is an innovative concept that Capgemini

can use to help clients to implement a new and more effective way to work and cooperate.

67

13. References

About.com. http://cellphones.about.com/od/glossary/g/define_android.htm (accessed

November 11, 2010).

Android Developers. http://developer.android.com (accessed November 11, 2010).

Antonopoulos, Nick, and Lee Gillam. Cloud Computing: Principles, Systems and

Applications. Springer, 2010.

Bakshi, Meenu, Sachin Khanna, and Rani Mishra. Working with Java Virtual Machine.

SkillSoft Press, 2003.

Bertini, Enrico, Silvia Gabrielli, and Stephen Kimani. “Appropriating and Assessing

Heuristics for Mobile Computing.” AVI ’06, 23–26 May 2006: 119-126.

Billi, Marco, et al. “A unified methodology for the evaluation of accessibility and usability

of mobile applications.” Univ Access Inf Soc, September 2010: 337–356.

Capgemini. Capgemini Official Website. www.capgemini.com (accessed December 5,

2010).

DeBeasi, Paul. Best practices for enterprise mobile device and smartphone security.

http://searchmobilecomputing.techtarget.com/tip/Best-practices-for-enterprise-

mobile-device-and-smartphone-security (accessed December 28, 2010).

Distefano, Alessandro, Antonio Grillo, Alessandro Lentini, and Giuseppe F. Italiano.

“SecureMyDroid: Enforcing Security in the Moble Device Lifecycle.” CSIIRW '10

Proceedings of the Sixth Annual Workshop on Cyber Security and Information Intelligence

Research, 2010.

Elsenpeter, Robert, Anthony T. Velte, and Toby J. Velte. Cloud Computing: A Practical

Approach. McGraw-Hill/Osborne, 2010.

Fielding, Roy. Architectural Styles and the Design of Network-based Software

Architectures. Dissertation, Irvine: University of California, Irvine, 2000.

Forsberg, Christian. Software Architecture Document. Software Architecture Document,

Capgemini, 2010, 12.

Gartner. March 2010. http://www.gartner.com/it/page.jsp?id=1421013 (accessed

November 11, 2010).

68

Goncalves, Antonio. Beginning Java EE 6 with Glassfish 3: From Novice to Professional,

Second Edition. Apress, 2010.

Gregg, Michael. Security Concerns for Cloud Computing. Global Knowledge Training LLC,

2010, 7.

Hashimi, Sayed Y., Dave MacLean, and Satya Komatineni. Pro Android 2. Aspress, 2010.

Hentzen, Whil. MySQL Client-Server Application with Visual FoxPro. Hentzenwerke

Publishing, 2007.

Learn REST: A Tutorial. February 2008. http://rest.elkstein.org/2008/02/rest-

architecture-components.html (accessed November 10, 2010).

Meier, Reto. Professional Android 2 Application Development. Wrox Press, 2010.

Murphy, Mark. Beginning Android 2. Aspress, 2010.

Nielsen, Jakob, and L Robert Mack. Heuristic Evaluation: Usability Inspection Methods.

New York: John Wiley & Sons Ltd., 1994.

Norman, A. Donald. The Design of everyday things (2002 edition). New York: Basic Books,

2002.

Oliveira, Marco, Joel J.P.C. Rodrigues, and Binod Vaidya. “New Trends on

UbiquitousMobileMultimedia Applications.” EURASIP Journal onWireless

Communications and Networking, 1 July 2010: 11.

PCWorld: Brief history of smartphones. 18 June 2010.

http://www.pcworld.com/article/199243/a_brief_history_of_smartphones.html

(accessed November 11, 2010).

Preece, Jenny, Yvonne Rogers, and Helen Sharp. Interaction Design; Beyond human-

computer interaction, 2nd Edition. John Wiley & Sons Ltd, 2007.

Samisa, Abeysinghe. RESTful PHP Web Services: Learn the Basic Architectural Concepts

and Steps Through Examples of Consuming and Creating RESTful Web Services in PHP.

Packt Publishing, 2008.

Scofield, Ben. Practical REST on Rails 2 Projects. Apress, 2008.

Tudor, Ben, and Christy Pettey. Gartner Says Worldwide Mobile Phone Sales Grew 35

Percent in Third Quarter 2010; Smartphone Sales Increased 96 Percent. 10 November

2010. http://www.gartner.com/it/page.jsp?id=1466313 (accessed December 28, 2010).

Wikipedia: CPU. http://en.wikipedia.org/wiki/Central_processing_unit (accessed

January 20, 2011).

69

Wikipedia: Debugging. http://en.wikipedia.org/wiki/Debugging (accessed January 20,

2011).

Wikipedia: Google Apps. http://en.wikipedia.org/wiki/Google_Apps (accessed January

20, 2011).

Wikipedia: Google Docs. http://en.wikipedia.org/wiki/Google_Docs (accessed January

30, 2011).

Wikipedia: iOS(Apple). http://en.wikipedia.org/wiki/IOS_%28Apple%29 (accessed

January 20, 2011).

Wikipedia:Android market. http://en.wikipedia.org/wiki/Android_Market (accessed

January 20, 2011).

Wikipedia:API. http://en.wikipedia.org/wiki/Application_programming_interface


Wikipedia:API. http://en.wikipedia.org/wiki/Application_programming_interface

(accessed January 20, 2011).

Wikipedia:App Store. http://en.wikipedia.org/wiki/App_Store (accessed January 20,

2011).

Wikipedia:Communications protocol.

http://en.wikipedia.org/wiki/Protocol_%28computing%29 (accessed November 11,

2010).

Wikipedia:CSS. http://en.wikipedia.org/wiki/Cascading_Style_Sheets (accessed January

20, 2011).

Wikipedia:HTML. http://en.wikipedia.org/wiki/HTML (accessed November 10, 2010).

Wikipedia:HTML5. http://sv.wikipedia.org/wiki/HTML5 (accessed January 20, 2011).

Wikipedia:HTTP. http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol (accessed

November 11, 2010).

Wikipedia:JSON. http://en.wikipedia.org/wiki/JSON (accessed January 20, 2011).

Wikipedia:JVM. http://en.wikipedia.org/wiki/Java_Virtual_Machine.

Wikipedia:Parsing. http://en.wikipedia.org/wiki/Parsing#Parser (accessed January 20,

2011).

Wikipedia:Protocol. http://en.wikipedia.org/wiki/Communications_protocol (accessed

February 14, 2011).

70

Wikipedia:REST. http://en.wikipedia.org/wiki/Representational_State_Transfer


Wikipedia:Smartphones. http://en.wikipedia.org/wiki/Smartphones (accessed

November 11, 2010).

Wikipedia:URI. http://en.wikipedia.org/wiki/Uniform_Resource_Identifier (accessed

November 10, 2010).

71

APPENDIX: A

Usability Evaluation of Android version of DreamTeam

(performed in Swedish)

Svara på frågorna nedan efter du testat appen.Fyll gärna i fritextfälten där du har

möjlighet att beskriver mer utförligt hur du uppfattade användarupplevelsen.

* Required

Ditt namn: *

Vilken typ av telefon har du testat appen på? *

Använder du en Androidtelefon dagligen? *

Ja

Nej

Other:

Fyll i på skalan nedan hur pass erfaren Androidanvändare du är: *

1 2 3 4 5

72

Oerfaren (aldrig

använt Android innan) Erfaren (Använt en Androidtelefon

dagligen i över 2 månader)

Hur installerade du appen på din telefon? *

Hur upplevde du installationen av appen på din telefon? Beskriv om det var lätt eller om

du upplevde det som krångligt. *

Hur upplevde du navigeringen i appen? * 1 är sämst, 5 är bäst

1 2 3 4 5

Lägga till Team

Ta bort Team

Lägga till / söka

konsult

Ta bort konsult

Se

73

1 2 3 4 5

konsultinfomation

Lägg gärna till en kommentar angeånde hur du uppfattade navigeringen:

Fick du appen att krascha? Vad gjorde du då? *

Vad är ditt helhetsintryck av appen: *

74

Nämn gärna några förbättringspunkter:

Tänk att du ska använda appen i ditt arbete dagligen, är det någon funktion du saknar?

TACK FÖR DIN MEDVERKAN! Eventuella övriga kommentarer kan lämnas nedan:

Submit

TRITA-CSC-E 2011:039 ISRN-KTH/CSC/E--11/039-SE

ISSN-1653-5715

www.kth.se

Improvements of Capgemini’s Internal Staffing Process...

Documents

Transcript of Improvements of Capgemini’s Internal Staffing Process...