The Development and Evaluation of a Mobile development methodology

7/30/2019 The Development and Evaluation of a Mobile development methodology

1/194

The Development and Evaluation of a Mobile

Application Development Methodology

Marnus C. Breytenbach

21706778

Heinrich du Toit

21077533

Martin L. Gouws

21776032

Mini-dissertation submitted in partial fulfilment of the requirements for the degree Honours of

Science in Information Technology at the Potchefstroom Campus of the North-West University

The financial assistance of the National Research Foundation (NRF) towards this research is

hereby acknowledged. Opinions expressed and conclusions arrived at, are those of the author

and are not necessarily to be attributed to the NRF.

Supervisor: Prof. H.M. Huisman

November 2012


2/194

ii

ABSTRACT

The current mobile application market is fed largely by individuals and businesses writing

applications using rapid development. Their main aim is to make a profit by distributing the

applications as quickly as possible on the mobile application market. This has resulted in a flood

of poor-quality applications which focus on meeting a specific user need but neglect many

important aspects of mobile application design and usability. This is because there are currently

very few methodologies for mobile application development, and it is uncertain whether or not

they address the characteristics that make mobile applications successful.

This research aimed to identify critical characteristics required for mobile application success,

and evaluate existing methodologies for mobile application development against their delivery of

these crucial characteristics. Furthermore, the research aimed to develop and test a mobileapplication development methodology according to the results of this evaluation, to address the

current shortfalls that exist within methodologies. The methodology was designed to fully

address the critical characteristics for mobile application success and provide a holistic,

efficient, and effective process for developers to follow.

A set of eleven critical characteristics for mobile application success was compiled and the

importance of each characteristic was confirmed by means of a survey. The characteristics all

proved to be valued as important by respondents, and are listed as follows: User experience,usability, cognitive support, learnability, value to the user, user interface design, availability and

accessibility, adaptability, compatibility, efficiency, and security and privacy.

The most prominent shortfalls identified in current methodologies were a lack of consideration

for learnability, adaptability, efficiency, and privacy and security within mobile applications.

Although these were the most prominent shortfalls, none of the critical characteristics for mobile

application success, which are mentioned below, are sufficiently addressed by the current

methodologies.

The critical characteristics were further used as a foundation to produce a new methodology for

mobile application development. This new methodology was tested through the development of

three different applications, namely a business application, a mobile game, and a personal utility

application. The results of the evaluation were used to refine the methodology. The final result

of the research is the completed Methodology for Mobile Application Development (MMAD).


3/194

iii

KEYWORDS

Mobile application development, MMAD, Critical characteristics for mobile application success,

System Development Methodology, SDM for MAD, Mobile application


4/194

iv

ACKNOWLEDGEMENTS

Thanks to Prof. Huisman for your support and guidance throughout the year. Your patience and

enthusiasm have made this project a great learning experience.

~ Heinrich, Marnus, Martin


5/194

v

TABLE OF CONTENT

Introduction.......................................................................................................................... 001

1. Literature Review............................................................................................................. 003

1.1. Defining MAD........................................................................................................... 003

1.1.1. Literature Definitions......................................................................................... 003

1.1.2. Interpreted Definition: Mobile Application Development................................... 004

1.2. Critical features of mobile applications..................................................................... 004

1.2.1. User Experience............................................................................................... 005

1.2.2. Usability............................................................................................................ 005

1.2.3. Cognitive Support............................................................................................. 006

1.2.4. Learnability....................................................................................................... 007

1.2.5. Value to the User.............................................................................................. 0071.2.6. User Interface Design....................................................................................... 008

1.2.7. Availability & Accessibility of a Mobile Application........................................... 009

1.2.8. Adaptability....................................................................................................... 010

1.2.9. Compatibility..................................................................................................... 010

1.2.10. Efficiency........................................................................................................ 011

1.2.11. Security & Privacy.......................................................................................... 012

1.2.12. Closing Statement.......................................................................................... 013

1.3. System Development Methodology......................................................................... 0131.3.1. Defining SDM................................................................................................... 013

1.3.2. Mobile application SDMs.................................................................................. 014

1.3.2.1. MASAM.................................................................................................. 014

1.3.2.2. Mobile-D................................................................................................. 018

1.3.2.3. GMA....................................................................................................... 019

1.3.2.4. Process Based Methodology for Designing Event-Based

Mobile Composite Applications............................................................. 021

1.3.2.5. Generic Framework for Mobile Application Development...................... 022

1.3.2.6. Dynamic Channels................................................................................. 023

1.3.2.7. DTMA..................................................................................................... 024

1.3.2.8. Rapid Application Development with DSDM Atern................................. 025

1.3.2.9. Scrum Agile Development Methodology................................................ 028

1.3.2.10 System Development Life Cycle (SDLC)............................................... 030

1.3.2.11 Summary of SDMs................................................................................ 031

1.4. Evaluation of SDMs for MAD vs. Critical Characteristics......................................... 032

1.4.1. Critical Characteristics...................................................................................... 033


6/194

vi

1.4.2. MASAM............................................................................................................ 034

1.4.3. Process-Based Methodology for designing Event-Based

Mobile Composite Applications....................................................................... 034

1.4.4. RAD with DSDM Atern..................................................................................... 034

1.4.5. Agile application methodology Scrum (2012)................................................ 035

1.4.6. Generic Framework for MAD (2011)................................................................ 035

1.4.7. Mobile-D (2004)................................................................................................ 036

1.4.8. System Development Life Cycle (SDLC).......................................................... 036

1.4.9. GMA (Generic Mobile Application)................................................................... 037

1.4.10. Dynamic channel development methodology................................................. 037

1.5. Consideration of characteristics within SDMs for MAD............................................ 038

1.5.1. User Experience............................................................................................... 038

1.5.2. Learnability....................................................................................................... 038

1.5.3. User Interface design....................................................................................... 038

1.5.4. Efficiency.......................................................................................................... 039

1.5.5. Value to user.................................................................................................... 039

1.5.6. Cognitive support.............................................................................................. 039

1.5.7. Compatibility..................................................................................................... 039

1.5.8. Usability............................................................................................................ 039

1.5.9. Availability and Accessibility............................................................................. 040

1.5.10. Adaptability..................................................................................................... 0401.5.11. Security and Privacy....................................................................................... 040

1.6. Interpretation of evaluation....................................................................................... 040

2. Research methodology.................................................................................................... 041

2.1. Interpretive............................................................................................................... 041

2.2. Positivistic................................................................................................................ 041

3. Results............................................................................................................................. 043

3.1. Survey Results......................................................................................................... 043

3.2. New SDM for MAD................................................................................................... 044

3.2.1. User Experience............................................................................................... 044

3.2.2. Learnability....................................................................................................... 045

3.2.3. User Interface design....................................................................................... 045

3.2.4. Efficiency.......................................................................................................... 046

3.2.5. Value to user.................................................................................................... 046

3.2.6. Cognitive support.............................................................................................. 047

3.2.7. Compatibility..................................................................................................... 047

3.2.8. Usability............................................................................................................ 048


7/194

vii

3.2.9. Availability and Accessibility............................................................................. 048

3.2.10. Adaptability..................................................................................................... 049

3.2.11. Security and Privacy....................................................................................... 050

3.2.12. MMAD Process............................................................................................... 050

3.3. Case studies............................................................................................................ 055

3.3.1. Case Study 1: Business Application................................................................. 055

3.3.2. Case Study 2: Mobile Game............................................................................. 055

3.3.3. Case Study 3: Personal Utility.......................................................................... 055

4. Discussion of results........................................................................................................ 056

4.1. Evaluation of MMAD................................................................................................ 056

4.1.1. Result of Case study 1: Business Application.................................................. 056

4.1.2. Result of Case study 2: Mobile Game.............................................................. 057

4.1.3. Result of Case study 3: Personal Utility........................................................... 057

4.1.3. Overall Results from Case Studies................................................................... 058

4.2. Alteration and improvement of MMAD..................................................................... 059

5. Recommendations and Implications................................................................................ 063

6. Limitations........................................................................................................................ 063

7. Future work...................................................................................................................... 063

References.......................................................................................................................... 065

Appendices.......................................................................................................................... 069

Data collected...................................................................................................................... 123Research proposals............................................................................................................. 126

Work breakdown structure................................................................................................... 183


8/194

viii

LIST OF TABLES

Table 1.3.2.11.1. Summary of SDMs................................................................................... 31

Table 1.4.1.1. Evaluation of Current SDMs for MAD........................................................... 33

Table 3.1.1. Means of Survey Results................................................................................. 43

Table 4.1.4.1. Criticisms on MMAD from Case Studies...................................................... 58

LIST OF FIGURES

Figure 1.3.2.3.1. GMA Process Model................................................................................. 20

Figure 1.3.2.6.1. Dynamic Channels Process Model .......................................................... 24

Figure 1.3.2.7.1. Atern Lifecycle Process............................................................................ 28

Figure 1.3.2.9.1. Scrum Process Model.............................................................................. 29

LIST OF ABBREVIATIONS

MAD Mobile Application Development

SDM Systems Development Methodology


9/194

INTRODUCTION

Mobile devices have become a crucial part of todays society and hold many uses for

businesses and individuals. Due to the rising demand for mobile functionality (Holzer & Ondrus,

2011), it becomes increasingly more important for mobile application developers to use a clear,

effective and efficient methodology for the design, development and distribution of mobile

applications.

However, there is no standard methodology that covers the complete development process of

mobile applications. There are some methodologies which address specific aspects of

development but ignore other important elements. For example, there are some proposed

development methodologies designed to help developers with the logical design of their

applications, such as the Process-Based Methodology for Designing Event-Based MobileComposite Applications (Fjellheim et al., 2007), and other methodologies to help with the

physical implementation of their applications, such as the Disruption-Tolerant Mobile Application

Model (Yusof et al., 2010). Still other methodologies exist for the implementation of specific

types of applications, such as client-server distributed applications. An example of this is the

Framework for Mobile Application Development and Content Integration (Mayuk, 2006).

Methodologies such as MASAM (Jeong et al., 2008), Mobile-D (Abrahamsson et al., 2004), and

GMA (Cheng et al., 2007) have been proposed for mobile application development, but none ofthese methodologies address the entirety of the mobile application development process, and

they do not address the implementation and testing of all of the critical characteristics necessary

for a mobile application to be successful.

The current mobile application market is fed largely by individuals and businesses desiring to

write applications to make a profit by distributing them on a mobile application market such as

Google Play or the Apple App store. These parties often make use of rapid development

techniques to finish their applications as quickly as possible, at the lowest cost. This has

resulted in a flood of poor-quality applications which focus on meeting a specific user need but

neglect many important aspects of mobile application design and usability.

The purpose of this research is to identify the crucial characteristics required for mobile

application success, and evaluate existing methodologies for mobile application development

against their delivery of these crucial characteristics. Furthermore, the research aims to develop

and test a mobile application development methodology to fully address these characteristics

and provide a holistic, efficient, and effective process for developers to follow.

1


10/194

The use of a methodology that fully addresses the crucial characteristics of mobile application

success will result in a healthier mobile application market. Developers will be able to address

the needs of consumers in their development process, and will benefit from their applications

success in the market. Consumers will find applications more suitable to their needs, and will

benefit from better application performance. In turn, their spending will fuel more development

endeavours, which will produce more applications, which will give rise to more application sales.

This is the lifecycle observed in a healthy market (Holzer & Ondrus, 2011).

This document is divided into 7 sections. Section 1 includes the literature review, wherein MAD

is defined, the critical characteristics for mobile application success are identified, the term SDM

is defined universally and existing SDMs for MAD are discussed and evaluated according to the

critical characteristics, and these SDMs for MADs consideration of the critical characteristics is

discussed. Section 2 describes the research methodology. Section 3 presents the results of the

research, which are in turn discussed in Section 4. Section 5 states recommendations and

implications of the research, and Section 6 discusses the limitations of the research. Finally,

Section 7 proposes future work.

2


11/194

1. LITERATURE REVIEW

This section will provide a discussion of the literature on which the research is based. It will

include a definition of MAD, a review of the critical features of mobile application success, a

definition of SDMs, and a discussion of current SDMs for MAD and their delivery of the critical

features for mobile application success.

1.1. Defining MAD

In order to properly approach the concept of mobile application development, one must first

have a solid definition for the term as a whole.

1.1.1. Literature Definitions

Definitions were gathered from existing literature to gain a foundational understanding of the

current context of MAD.

Mobile Application Development is the process by which application software is developed for

small low-power handheld devices such as personal digital assistants, enterprise digital

assistants or mobile phones. These applications are either pre-installed on phones during

manufacture, downloaded by customers from various mobile software distribution platforms or

web applications delivered over HTTP which use server-side or client-side processing to

provide an application-like experience within a Web browser (Wikipedia, 2012).

This definition is from a non-academic source. Therefore, a more thorough and academically

sound definition is required. The term mobile application development is not something to be

found in a dictionary, and other definitions from sources such as journal papers are based on

the authors own opinions. For this reason, mobile application development will be broken into

its three base words, each then defined from the online Oxford dictionary (Oxford Dictionaries,

2012) and then combined to form a sound definition.

Firstly, the Oxford dictionary defines mobile simply, in context, as relating to mobile phones,

handheld computers, and similar technologies.

Secondly, again in context, application is defined as a program or piece of software designed

to fulfil a particular purpose. Furthermore, in more general terms, it also means the action of

putting something into operation.

3


12/194

Lastly, development, more specifically develop, is defined as grow or cause to grow and

become more mature, advanced, or elaborate. Also start to exist, experience, or possess.

Taking the Oxford definitions into consideration, a definition for Mobile Application Development

can be formulated. Mobile Application Development is the action of bringing into existence a

piece of software or program with a specific purpose to be used on mobile device technologies.

According to Denman (2011), mobile application development is similar to Web application

development, but it is more deeply rooted in traditional software development. Denman (2011)

also states that there is one critical difference between mobile application development and

Web application development mobile applications are often created specifically to exploit the

unique features offered by a particular mobile device.

1.1.2. Interpreted Definition: Mobile Application Development

For the purposes of the research, taking into consideration the definitions collected from literary

sources, mobile application development is defined as the following: The development of mobile

applications is the process by which application software is created for small, handheld, low-

power mobile devices, with a specific purpose (Denman, 2011; Enck, 2009; Oxford; Wikipedia,

2012). This process includes tasks such as application design, application implementation, andtesting procedures.

1.2. Critical Characteristics for Mobile Application Success

For a methodology to be effective, it must address certain features that determine an

applications success. To set a foundation for the evaluation of existing methodologies and the

creation of a new SDM for MAD, a list of critical features for mobile application success have

been identified from literature. These characteristics are: user experience, usability, cognitive

support, learnability, value to the user, user interface design, availability and accessibility,

adaptability, compatibility, efficiency, and security and privacy.

Many of the characteristics are interdependent on one another. The researchs aim is not to

investigate the relationship between characteristics, but rather to focus on their individual roles

in MAD.

The characteristics for mobile application success are discussed below.

4


13/194

1.2.1. User Experience

User experience concerns all aspects pertaining to a users interaction with an application. This

includes their thoughts and feelings regarding the application, as well as their perceptions, all

stemming from the users interaction and experience with the application (Tullis & Albert 2008).

Therefore, other aspects such as an applications reliability, usability and value to the user all

have an impact on the way a user experiences and perceives an application.

There are many other options for a mobile user to choose from if they arent wholly satisfied by

all the aspects of an application. Therefore, among all of the features that are crucial to a mobile

applications success, the user experience is the centre. All of these factors are in some way

related to user experience, and thus branch out from its main principles.

According to Teeni et al. (2007), there are three perspectives from which human-computer

interactions can be viewed, namely physical, cognitive and affective. These three perspectives

can be used to distinguish between the types of factors which enhance the user experience,

and ultimately, the success of an application.

1.2.2. Usability

While the term user experience is often interchanged with usability, the two should not beconfused. User experience encompasses much more than simply usability (Saffer 2007). None

the less, usability is the most influential contributor to user experience when it comes to mobile

applications. It can be described as the ability of an application to be easily understood, learned

without training or extensive background, useful, and attractive to the user (Benbunan-Fich &

Benbunan 2007; ISO/IEC 9126-1 2001; Peker & Can 2011).

Another term used to refer to usability, but also to an array of other aspects of mobile

application development, is QoS (Quality of Service) (Unhelkar & Murugesan, 2010).

Because usability is a vital component for measuring the quality of software, usability testing

has become increasingly important in the mobile phone industry. It is also one of the key factors

when testing the effectiveness of mobile applications developed as a product of research

studies (Al Bar et al. 2011; Duh et al. 2006; Kangas & Kinnunen 2005; Kao et al. 2009;

Lindholm et al. 2003; Unhelkar & Murugesan 2010).

Factors that deserve some attention are general principles from HCI, or Human-Computer

Interaction (Heo et al., 2009). One of these is the concept of cognitive processing, or the ability

5


14/194

of an application to be so well designed that the human mind automatically understands how

the application works. Another is how humans respond to mobile applications, online and offline

usability, and location specific design (Benbunan-Fich & Benbunan, 2007; Kao et al. 2012;

March et al., 2011; Unhelkar & Murugesan, 2010).

These factors are very important, but HCI is not discussed at length because its factors are by

nature interwoven into the other factors.

1.2.3. Cognitive Support

Heo et al. (2009) identifies the cognitive processing steps a user applies in carrying out a task

on a mobile phone: planning, translation, execution, and assessment. These steps make up the

process wherein a users perception of an applications usability is formed. An application

should be structured in such a way that a user can logically perform a task using their intuition,

without uncertainty or excessive effort.

It is important that users be able to predict the flow of operation when planning to perform a task

on the application (Kao et al. 2012). The logical flow of design elements should support and

align with a users thought processes instead of making the user have to pause in their

operation to align themselves with the applications structure. If the cognitive flow of an

application is designed effectively, the users chance of making a mistake is greatly decreased(Benbunan-Fich & Benbunan 2007; Heo et al. 2009). When a user makes fewer mistakes while

using an application, they will begin to feel that they can achieve their desired tasks when they

need to. The users confidence in themselves is an active factor in their willingness to use an

application (Heo et al. 2009, Verkasalo et al. 2010).

According to Heo et al. (2009), a users perception of the systems state is one of the steps of

information processing. This means that it is important for an application to always inform the

user on what it is doing. If the application is performing a long process, the user should be

shown either the execution progress, or an indication that the application is still busy. This will

help the user to be patient with the application, and will help them feel in control of the

applications functioning.

Another important factor in an applications cognitive support is the amount of data and

functionalities users are presented with (Heo et al. 2009; Unhelkar & Murugesan 2010).

Because of the limited screen space on mobile devices, all information provided to the user

should be relevant and useful. Also, the functionalities provided by the application shouldnt be

overbearing or unrelated to the core function and purpose of the application.

6


15/194

1.2.4. Learnability

Learnability, also referred to as intuitiveness, is an important contributing factor to an

applications usability (Donyaee et al. 2002; Kao et al. 2012; Nilsson 2009; Peker & Can 2011;

Verkasalo et al. 2010). The use of an application should be easy to learn and should require no

training and little or no visual and textual support. If an application does, however, contain

robust functionality which requires a little experience and knowhow from the user, then thorough

support should be supplied in the form of visual or textual tutorials. These tutorials should be

easily accessible and preferably embedded within the application.

If a user is required to put in extensive effort in order to start using an application, they will be

discouraged and may postpone or even abandon learning to use the application. As mentioned

previously, user confidence is an important component of an applications usability.

1.2.5. Value to the User

An application is worthless if it doesnt add value for the user (Verkasalo 2008). There are many

other applications competing for a users attention (and their money). Applications must utilise

their mobile devices to provide functionality and value that a user cannot find in other

applications or other devices (Feijoo et al. 2012; Rice & Katz 2008). Rival devices may include

personal computers, gaming consoles, and Personal Digital Assistants.

Mobile applications must also share their users time among other activities conducted on

mobile devices, such as instant messaging, social networking, listening to music, and watching

video content (Feijoo et al. 2012). An application would benefit from incorporating some of these

activities in order to substitute them. In doing so, they can acquire a larger percentage of the

users time.

Another aspect contributing to the value of an application is its contribution to a users everyday

life. Applications that improve productivity, help users perform daily tasks more effectively, save

users time, and help users relax are considered very valuable and are greatly sought after in

todays fast-paced, pressure-controlled lifestyle (Kao et al. 2012; Verkasalo et al. 2010).

Along those lines, it is important for an application to account for the specific needs of its users

(Heo et al. 2009; Kangas & Kinnunen 2005). Developers should take into consideration the

target market of the application, and what functionalities will ultimately make the application as

effective as possible for its users.

7


16/194

A users perception of an applications value is largely effected by social factors. Applications

that have a good public image are easier for people to use around others, and also gain more

referrals from users (Feijoo et al. 2012). Also, people often prefer the use of certain applications

above others because their friends use these applications as well (Verkasalo et al. 2010).

1.2.6. User Interface Design

When MAD is initiated, the physical device should be taken into account. Mobile devices are

categorized as having three main characteristics, namely that they are a handheld device, there

are no external input devices or cables required for operation, and they support multiple

application installation.

Usability is influenced in more practical terms by various elements, one of which is the interface

of an application. The interface (User Interface UI) can be logically divided into three parts,

namely the GUI, LUI and PUI. This literature will focus on these three as the main components

of mobile application interfaces.

The LUI (Logical User Interface) includes components like the menu and navigation capabilities

that are related to information and the structure for task execution and the feat of displaying

data sensibly (Heo et al. 2009; Plaza et al., 2011; Unhelkar & Murugesan, 2010).

The PUI (Physical User Interface) includes components like the keypad and/or touch screen

and audio devices: physical interfaces that are used to carry out a task in an application (Heo et

al., 2009; Plaza et al., 2011).

Finally, the GUI (Graphic User Interface) includes components like icons (both font and colour)

and fonts associated with the visual items that are task relevant (Benbunan-Fich & Benbunan,

2007; Heo et al. 2009).

There are certain factors that need to be considered when designing interfaces in mobile

applications which coincide with the GUI, LUI and PUI. All of these are expected by users to be

rich and non-trivial (March et al., 2011). The first of these factors is screen size and resolution.

There is not enough physical space on mobile device screens to display large amounts of data

at any given moment and this can lead to information organization and navigation issues as well

as resizing issues (Heo et al., 2009; Kao et al. 2009; Lee et al., 2006; Ling et al., 2006a, b;

Omari et al., 2008) The second factor is the physical buttons and what their functionality will be

during various application modes. The final factor is the influence of memory limitations and

8


17/194

power consumption on the MAD. The latter is not really considered to be part of the UI, but it

indirectly influences how the application will function later on in its life-cycle (Heo et al. 2009).

During MAD, these factors need to be considered in order to design an application that will be

acceptable to the user. When these factors are considered and implemented in line with the

purpose of the application to be designed, the usability of the application will be satisfactory.

1.2.7. Availability & Accessibility

Mobile application development serves no purpose unless the products that it delivers can be

distributed and utilised by end users. In the past, when mobile applications were still exclusively

developed by network carriers, phone manufacturers and some third party companies, these

applications required an expert for installation on mobile devices. However, since then,

centralized application portals such as the Android Market, Apple App Store and Blackberry App

World have been created to distribute these MAD products to the public and an expert is no

longer required for installation (Holzer & Ondrus, 2011).

In previous years it was also a difficult feat to distribute updates for mobile applications,

because of the limitations of distribution. These centralized application portals have made

updates to previously installed applications readily available, helping management and support

of applications to be effortless. Users are left with the feeling that they are in control and thisadds to a positive user experience (Al Bar et al. 2011; Kim et al., 2009; Verkasalo et al. 2010).

The pricing of applications in the various marketplaces also poses a certain challenge:

applications that are too heavily priced will not be purchased because there are often similar

applications available for free. Thus it is important to consider the pricing of mobile applications

very carefully and perhaps look for alternative streams of revenue through, for example, making

use of advertising space in applications. If an application is indeed for sale, the price should be

very reasonable and the user should feel that their purchase has enriched his mobile

experience (Feijoo et al. 2012; Verkasalo et al. 2010).

The consequences that availability and accessibility have on developers are that they need to

incorporate and work towards publishing applications onto the various markets to make it

accessible to the public. These application markets, to various levels of ease, make it possible

for developers to do just this (Kao et al. 2012).

9


18/194

1.2.8. Adaptability

An important concept in the development of mobile applications is adaptability. This includes

two dimensions. Firstly, an application should be able to adapt to the context within which it is

being used. This includes making use of information such as time of day, weather, GPS

location, and internet connectivity. Secondly, an application should be able to adapt to users

preferences, including user configurations, display options, and sound and vibration. (Al Bar et

al. 2011; Ali et al. 2010; Fjellheim et al. 2007; Kangas & Kinnunen 2005; Kao et al. 2009; Kao et

al. 2012; Omari et al. 2008; Peker & Can 2011; Unhelkar & Murugesan 2010; Verkasalo et al.

2010)

1.2.9. Compatibility

In the last few years there was a great increase in the amount of different mobile operating

system platforms which created a big problem for mobile application developers. The problem

was mainly when they wanted to develop for multiple platforms and this became very time

consuming. This is where they searched for compatibility links where they could develop one

mobile application and deploy them to multiple platforms (Duarte & Afonso 2011; Viana &

Andrade 2008).

They have found techniques that allow multi-platform compatibility. By using web applicationsas the medium they are able to use a specific service on multiple devices, but connectivity to

the internet is usually required (Kao, Y. et al., 2012). An Application Programming Interface

(API) is an interface used to develop multi-platform applications (Duarte & Afonso 2011). An

example of such an interface would be the Joint Innovation Lab (JIL) API (JIL 1.2.2 API

Overview; Duarte &Afonso 2011).The downside of using these APIs are that certain features

are lost in the process because of the limitations of the API. A feature that is lost in terms of

android would be that the JIL framework has no support for connecting to the file system

(Duarte & Afonso 2011).

Mobile device screen sizes arent all the same and neither are the resources that are available

in a mobile device (Heo, J. et al., 2009; Cho, H. & Yang, J., 2008). It is important that the

adaptability of a mobile application is taken into consideration (Cho & Yang, 2008). This also

increases the reusability of an application.

Along with screen size another element that will have to be looked into is the input methods for

a mobile application. There are different methods of input such as touch screen or physical

keyboard built in to device and there are also different kinds of keyboard layouts for instance the

10


19/194

QWERTY (QWERTY - Wikipedia, the free encyclopedia. 2012) or the QWERTZ (QWERTZ -

Wikipedia, the free encyclopedia. 2012.). When a mobile application is developed, the market

which the application needs to reach has to be studied to know what input methods you will use

in the mobile application.

Web pages are a problem when they werent specifically designed for a mobile device. An

Internet browser application for mobile devices needs to be able to rescale the pages without

making the reading even harder (Kao et al. 2012; Omari et al. 2008). Web pages can contain

visual features that will not be compatible with all devices. Therefore when developing a web

page you need to make it possible for the lower end device to be able to see the necessary

data, but also the higher end devices should be able to view the content which is compatible

with the device (Omari et al. 2008).

When designing mobile games it is also important to keep compatibility in mind because two

mobile devices may be the same in terms of performance but not screen size and therefore the

game should be scalable to fit the smaller mobile and vice versa (Lukashev et al. 2006). This

scalability is achieved, when using 2D animation, by using vector editors like Adobe Illustrator

(Graphic design software | Adobe Illustrator CS5. 2012.) or Adobe - FreeHand (Adobe -

FreeHand MX. 2012). When a game is developed for a specific platform, adaptability is also a

critical factor that needs to be taken into consideration because devices of the same platform

dont always have the same phone specifications (Cho, H. & Yang, J.S., 2008).

1.2.10. Efficiency

Although the resources available in mobile devices have improved dramatically in the last few

years, they are still limited and need to be taken into consideration when developing a mobile

application (Heo, J. et al., 2009; Al Bar, A. et al., 2011.). Resource management becomes a big

factor when designing mobile games which is just another type of mobile application. Mobile

games need graphics processing which, even with todays smartphones, needs to be resource

effective, otherwise the game performance will be greatly reduced (Kao et al., 2009; Lukashev

et al., 2006).

Although the users needs must be satisfied, a developer needs to focus on a balance between

the needs of the user and the performance of the mobile application (Fjellheim et al. 2007).

Although the normal services like voice calling and sending text messages are cornerstone

services provided by mobile devices, the users of mobile devices are calling for more advanced

11


20/194

services like search services and even changing the theme of their phone (Verkasalo et al.

2010). Services like these can also improve the efficiency of a mobile application.

Mobile applications need to connect with the internet more each day and this service will have

to be as seamless as possible. When a mobile application needs the internet then a great way

to improve performance of the application is to enable caching of the data (Kao et al. 2012).

This enables a device to have an online experience even while not connected to the internet.

As previously mentioned, web page sizes are a problem on mobile devices. This also influences

the efficiency of browsing the internet because the user spends so much time scrolling to find

what he is looking for(Kao et al. 2009). To improve the browsing performance techniques like

tailoring the web page before it is sent to your mobile device is used (Kao et al. 2009).

1.2.11. Security & Privacy

Security and privacy has always been a concern for consumers and businesses. For this

reason, these factors need to be considered at length when developing mobile applications in

order to satisfy user needs. Some consider mobile security and privacy to be the first and

foremost concern for any designer in planning an application (Al Bar et al. 2011; Feijoo et al.

2012; Ren & Duan, 2012).

The need for security and privacy becomes most noticeable when applications start functioning

on the basis of cloud computing. Here the need for encrypting transferred data from a mobile

device becomes more apparent (Hung et al., 2012).

Mobile application security comprises of different factors, including information confidentiality,

integrity of information, and availability. Another important security concern for mobile devices is

password protection, but in modern times this is handled by the mobile device itself. However, it

needs to be considered, although in most cases it will be a built in feature of the device for

which the application is being designed (Unhelkar & Murugesan, 2010). These factors of

security for mobile applications correspond to normal computer security principles (Cano &

Domenech-Asensi 2011).

Many applications are becoming increasingly advanced and are starting to resemble computer

applications. Some of these applications may contain banking information or sensitive

information such as PayPal details and functionality, all the more reason to focus a great deal

on securing the information that is handled by mobile devices (Al Bar et al., 2011; Cano &

Domenech-Asensi, 2011).

12


21/194

1.2.12. Closing Statement

The eleven characteristics, as identified above, are shown through literature to be important

influencing factors in the success of mobile applications. They will be used in the evaluation of

SDMs for MAD and form a basis for the development of a new SDM for MAD.

1.3. System Development Methodologies

This section includes a discussion of existing SDMs that can be used for MAD, as well as three

traditional SDMs. These SDMs are later evaluated according to their consideration for the

critical characteristics for mobile application success.

The SDMs designed specifically for MAD that are discussed below include MASAM, Mobile-D,GMA, Process-Based Methodology for Designing Event-Based Mobile Composite Applications,

Generic Framework for Mobile Application Development, Dynamic Channels, and DTMA.

The traditional SDMs included in the discussion are RAD with DSDM Atern, Scrum, and SDLC.

These traditional SDMs were included to determine whether there is a need for the

development of SDMs specifically targeted at MAD.

In order to identify a set of SDMs, one must first understand the definition of SDM. Thereforethe term is defined below.

1.3.1. Defining SDM

According to the British Computer Society (Avison & Fitzgerald, 1995) an SDM is a set of

recommended means for all or part of the development of information systems according to an

underlying philosophy that supports, justifies, and makes coherent to a given context. It

identifies procedures, phases, tools, techniques, rules, guidelines, documentation, and tasks. It

may also provide recommendations for the organization and management of the approach, and

the identification and training of participants.

According to Huisman (2004), a SDM consists of four main components, namely a philosophical

approach, method, process model, and tools and techniques. An SDMs philosophical approach

is the perspective through which it handles information system development. Its development

method is the list of steps that must be followed during the development process. The process

model is the order in which the development steps are executed. Tools and techniques facilitate

the development process.

13


22/194

1.3.2. SDMs in the Context of Mobile Application Development

The mobile application development perspective has radically changed from its conception to

the present day. In the methodologies developed between the 1990s and the early 2000s, a

heavy emphasis was placed on overcoming the performance restrictions presented by early

mobile devices. This resulted in methodologies focusing on the physical framework of mobile

applications and a way to decentralise the applications execution.

Modern-day devices have developed considerably stronger processing power. This has given

rise to methodologies that focused on multi-platform compatibility, with less concern for

minimised resource usage.

There is definite disarray among academic literature as to what the scope of a mobile

application development methodology is. Many articles elaborate on the framework of mobile

applications and the structure required in the coding of these applications (Mayuk, 2006;

Sambasivan et al., 2011). Other articles focus on the tools that must be used for development

(March et al., 2012; Mayuk, 2006). This confusion leads to incomplete methodologies which do

not address all of the critical characteristics for mobile application success. The scope of a SDM

for MAD should thus focus on a complete process of mobile application development, taking

into consideration each of the critical characteristics.

Below, some of the existing SDMs for MAD are discussed. These SDMs were chosen on the

basis of their applicability to MAD. They include: MASAM, Mobile-D, GMA, Process Based

Methodology for Designing Event-Based Mobile Composite Applications, Generic Framework

for Mobile Application Development, Dynamic Channels, and DTMA. Three traditional SDMs

are also discussed, namely Rapid Application Development with DSDM Atern, Scrum Agile

Development Methodology, and the System Development Life Cycle.

1.3.2.1. Mobile Application Software Based on an Agile Methodology

MASAM stands for Mobile Application Software Based on an Agile Methodology, developed

by Jeong et al. (2008). This is an agile mobile application development methodology that

focuses on rapid development, with the key goal being simple development and fast

deployment of new mobile applications. Heavy emphasis is also placed on user (or client)

involvement in the development process, and the use of development teams comprising of

multiple individuals.

14


23/194

The MASAM methodology is divided into four phases, namely Development Preparation,

Embodiment, Product Development, and Commercialisation (Jeong et al., 2008). The first two

phases involve requirements gathering, concept development, design and prototyping. The

Product Development phase is repeated to allow iterative development of the application,

wherein requirements evaluation, testing, and client compliance occur for each development

cycle.

1.3.2.1.1. Development Preparation Phase

The purpose of the Development Preparation phase is to grasp what clients intend to do with

the product (Jeong et al., 2008). It is here that the client is interviewed to gather initial

requirements and big-picture ideas about the potential product.

The activities of the Development Preparation phase are as follows:

Grasping the product

o Product summary this is where the initial idea of the product is formed and general

requirements are collected.

o Pre-planning the ideas and general requirements are organised to provide an initial

vision of the potential product, and to identify the direction in which to gather further

requirements.

Product concept sharingo User definition the client is given the opportunity to present their requirements and

expectations in detail.

o Initial product analysis requirements are analysed and a formal concept for the

product is developed.

Project setup

o Development process coordination the steps needed for the development process

of the product are planned, reviewed, confirmed and organised.

o Project resource coordination the resources required to carry out the development

project are calculated and procured.

o Pre-study initial research is done to provide context for product use, and patterns

and trends in existing products of the same type.

1.3.2.1.2. Embodiment Phase

The purpose of the Embodiment phase is to represent the clients requirements in concrete form

(Jeong et al., 2008). This is done by developing a prototype or simulated user interface and

presenting it to the client. According to Jeong et al. (2008), some users dont know what they

15


24/194

want and developers must make use of Application Patterns to classify the applications type

and follow the algorithmic patterns and user interface trends found in similar applications as a

guideline for design.

Activities in this phase include:

Understanding user needs

o Storycard workshop storycards (representing the main components or

functionalities of a product) are developed using user requirements and presented to

the client, which they use to make suggestions and give critique.

o User interface design and non-functional requirements analysis from the clients

requirements and suggestions, the user interface is designed and moulded to fit their

needs.

Architecturingo Architecture definition from the requirements gathered, the product architecture is

planned and the overall product design is finalised.

o Pattern management patterns found in similar products are incorporated and

utilised.

1.3.2.1.3. Product Development Phase

During the Product Development phase, the product is constructed iteratively and released tothe client after every cycle. The number of cycles must be decided on in the beginning of this

phase, before development is started..

Using iterative development cycles means that requirements are systematically worked into the

application, adding more functionality components with each development iteration. After each

iteration, the client is consulted to ensure the application aligns with their requirements and

expectations, and to allow the client to change their mind about their requirements. This leads to

the possibility of new user requirements being presented after each release.

The activities of the Product Development phase include:

Implementation preparation

o Environment setup the development environment is set up and the required team

allocations and development tools are determined.

o Development and release planning the storycards are divided between teams and

broken down into task cards for development, and the number of iterations and

releases is determined.

Release cycle

16


25/194

o Iteration cycle

Iteration planning the storycards for the iteration are determined, and the

necessary planning for the development of these components is done.

Implementation cycle

Face-to-face meeting the teams meet to ensure coordination

between the various tasks and storycards to de developed.

Incremental design the overall design of the components is created

or modified according to user requirements

TDD performance testing is done

Refactoring

Pair programming task cards are implemented into code using a

pair programming approach where two people programme together.

Continuous integration newly developed components are integratedinto the product

Feedback teams meet again to give feedback on their development

o Release

Acceptance test the product is released to the client for their testing and

evaluation.

Feedback client feedback is gathered and changes in the product

requirements are recorded.

1.3.2.1.4. Commercialisation Phase

The purpose of the Commercialisation phase is to get the product ready and usable for the

market. This also includes conforming the product to international policies.

The activities of the Commercialisation phase are as follows:

System test

o Acceptance tests and user tests the product is tested by the client to ensure

usability and acceptance of the product.

Product sales

o Launching test the product is released to a small portion of the market to test its

success.

o Product launching the final product is released to the client.

1.3.2.1.5. MASAM as a SDM

17


26/194

The philosophical approach of MASAM focuses on the simple development and fast

deployment of mobile applications, taking an agile development perspective. The method used

consists of Phases, namely the Development Preparation Phase, Embodiment Phase, Product

Development Phase, and Commercialisation Phase. The process model is sequential,

completing one step after the other until completion of the development process. The Release

phase contains iterative steps that are to be repeated until the system is finished. Tools and

techniques used by MASAM include product summary, story cards, and pair programming.

MASAM can thus be seen as a complete methodology, containing all the necessary

components to be defined as a SDM according to the definitions used for the purposes of this

research.

1.3.2.2. Mobile-D

The Mobile-D Approach to Mobile Application development, developed by Abrahamsson et al.

(2004), is based on Extreme Programming, Crystal methodologies and Rational Unified Process

and it is considered to be an agile approach to development.

The approach requires a team of less than 10 people in a single room with the sole purpose of

rolling out a fully functional mobile application in the shortest possible time, no more than 10

weeks. The whole methodology is centred around 5 iteration phases, namely: Set-up

Core

Core2

Stabilise

Wrap-up.

Each of the previously mentioned phases then are divided into three different development

days, namely:

Planning day

Working day

Release day

There is an additional day that is added when multiple teams are working on different parts of

the application and this day is called the integration day.

Each phase also involves 9 principal elements, namely

Phasing and pacing

18


27/194

Architecture line

Mobile test-driven development

Continuous integration

Pair programming

Metrics Agile software process improvement

Off-site customer

User-centred focus.

Most of these 9 principle elements are well known agile procedures that where adapted for

mobile applications (Abrahamsson et al., 2004).

The Mobile-D approach to mobile application development is a very solid methodology in terms

of getting a team to develop an application with all the steps and structure needed, but it lacks

more specific guidelines for the physical development of the application. There is little said

about the tools to be used and it seems as though it will depend on what platform is chosen to

develop on and it assumes prior knowledge of development on this platform. The architecture,

the physical technology needed, is not mentioned either. There also seems to be very little

description for the steps that are mentioned, not really explaining exactly to the letter what every

phase entails.

1.3.2.2.1. Mobile-D as a SDM

The philosophical approach of Mobile-D is focused on agile development to produce

applications quickly. Its method consists of five phases, namely setup, core, core2, stabilise,

and wrap-up. These phases are divided into development days. The process model is iterative,

with small releases of system parts being produced. Tools and techniques used in Mobile-D

include phasing and pacing, architectural line, and pair programming.

Mobile-D therefore consists of all the elements necessary to be defined as a complete SDM.

However, the level of detail available in the literature regarding this methodology is minimal.

1.3.2.3. GMA

In 2007, a methodology called GMA (Generic Mobile Application) framework was released by

Cheng et al. As previously mentioned, this framework was also concerned and centred on

mobile device performance, and much like the development framework there is also a very strict

physical architecture that has to be adhered to. GMA architecture states that an application can

19


28/194

be executed and used in one of three ways, namely BROWSE mode equivalent to thin-client

applications where the device itself is only responsible for the rendering and management of the

user interface - , STANDALONE mode equivalent to fat-client applications where all the code,

interface, execution and processing is performed on the device itself and MASTER-SLAVE

mode equivalent to distributed computing where the end device is powerful enough to be able

to handle the entire application but it does not support all the functionalities required to execute

the application code successfully. When this happens those non-supported functionalities are

executed on the server and the rest on the device.

GMA uses a three-tier architecture in order to meet this most pressing issue of device

performance. The front-tier contains the GMAClient of which there are four types (in order to

accommodate all levels of performance in devices): built-in Browser, GMABrowser,

GMAppSlave and GMAppStandalone. The middle tier contains the application server and the

backend-tier is the internet or intranet.

Concerning the methodology for developing mobile applications around this architecture, it is to

be expected that it would be very dependent on this stringent architecture. The only difference

between this SDM and traditional SDMs is in the deployment and the slight modification of the

classes in order to support mobile devices. See Fig. 1.3.2.3.1. for GMApp Development Flow

(Cheng et al., 2007).

1.3.2.3.1. GMA as a SDM

The philosophical approach of GMA focuses on the delivery of high-performance mobile

applications. The GMA framework does not provide a method or list of steps for development.

Its process model is sequential, working through the components of a framework. No tools and

techniques are recommended within for GMA.

Figure 1.3.2.3.1. GMA Process Model

20


29/194

Because GMA does not include a set method or tools and techniques to be used, it cannot be

seen as a complete SDM according to the definitions used for the purposes of this research. It

will therefore be referred to as an incomplete SDM.

1.3.2.4. Process Based Methodology for Designing Event-Based Mobile Composite

Applications

Also from 2007, is the process-based methodology for designing event-based mobile composite

applications, presented by Fjellheim et al. The main focus here is to help developers create

more adaptive applications. In short, this methodology is about creating various processes that

either handle communication between other processes, migration of components, or distribution

of data. Processes can also be component based and furthermore event set-off the appropriate

processes during execution. The same type of idea as in GMApp development is followed in

that the application is also either thin-client based or fat-client based with the server providing

additional support if needed. (Fjellheim et al., 2007).

The methodology focuses on a few important aspects to be analysed and considered when

developing a new mobile application. The first of these is the design dependencies which

include the environmental model and the execution model. The environmental model includes a

specification of the entities in the system and their individual contexts, preferences and policies.

Changes in the environmental model prompt adaptation. The environmental model, in otherwords, is a set of variables which are referred to in the execution model in order to specify how

adaption will occur. The execution model consists of various static and dynamic (contains the

procedure for adaptation with reference to the environmental model) aspects of the application.

The execution model, in short, tells the programmers what components to create, how they

interact with other components and how data and behaviour is distributed. The execution model

has four main parts (Fjellheim et al., 2007), namely:

Component activities providing a breakdown of the features to be included within the

application.

Interactions defining how the components communicate with one another.

Deployment packaging of components and interactions with the purpose of distribution.

Data distribution distribution of deployed product to vendors and customers.

This methodology is very insistent on developers considering the above mentioned steps very

carefully as it will determine if the rest of the development goes well or not. When writing the

code for an application, great care must be taken to get the data flow right and making sure that

execution happens in the manner in which it is supposed to happen (Fjellheim et al., 2007).

21


30/194

This methodology is solid enough to ensure a quality application, but the problem with this

methodology is that it focuses on composite applications. Composite applications are

applications that are built by combining different functions previously written together to create a

new application. Furthermore, no attempt is made at creating new components that might be

better or add previously unknown functionality.

1.3.2.4.1. Process Based Methodology for Designing Event-Based Mobile Composite

Applications as a SDM

The philosophical approach focuses on event-based development of mobile applications. The

method consists of four parts, namely component activities, interactions, deployment, and data

distribution. The process model is sequential, running though the method from beginning to end

to deliver a working application. No tools and techniques were recommended within the

methodology.

The Process Based Methodology for Designing Event-Based Mobile Composite Applications

can therefore not be seen as a complete SDM according to the definitions of a SDM used for

the purposes of this research. It will be referred to as an incomplete SDM.

1.3.2.5. Generic Framework for Mobile Application Development

The generic framework for mobile application development, presented by Sambasivan et al. in

2011, is a more modern approach to mobile application development. Whereas older

methodologies were concerned with device performance and processing power, this modern

approach is concerned and focuses more on the multi-platform dilemma developers are faced

with today. The methodology focuses on the development of one application that is compatible

with devices running the Android, BlackBerry and iOS operating systems. It is considered more

important for the developer to focus on business rules than to be worried about how to

implement these business rules.

This methodology starts with a custom JavaScript API, which is a common cross-platform

engine, to build the framework of any given application. The business logic that is required by

the application is then written in HTML, JavaScript and CSS in combination with the features

provided with the framework such as User Interface, device features, storage and device

information which in turn again calls the native features of the applicable operating system. This

application is then built using the native interfaces (APIs) of Android, BlackBerry and iOS to

make the once developed application available to all three operating systems. The JavaScript

API provides an array of common phone features (graphing, accelerometer, camera, contacts,

22


31/194

location, mail, orientation, SMS, File I/O, SQLite and device information (Sambasivan et al.,

2011).

1.3.2.5.1. Generic Framework for Mobile Application Development as a SDM

The philosophical approach focuses on the definition business rules rather than methods to

implement these rules. There is no method proposed for development, and no process model is

given. Tools and techniques that are suggested are the use of a Java API, HTML, Javascript,

and CSS.

Because no method or process model are proposed, the Generic Framework for Mobile

Application Development cannot be seen as a complete SDM according to the definitions of a

SDM for the purposes of this research. The literature available on this framework is limited, and

fails to provide sufficient detail on the framework. It will be referred to as an incomplete SDM.

1.3.2.6. Dynamic Channels

According to Afonso et al. (1998), Dynamic channels can be described as follows.

Dynamic channels are based on the Object Modelling Technique (OMT) and unified modelling

language (UML). Dynamic channels start by creating a model of the application. This model isthen further developed as the design progresses. The three phases in Dynamic channels are

analysis, object design, and implementation. The phases are shown in figure 1.3.2.6.1 below.

In the analysis phase, all the system requirements are captured and used to define the

important domain classes in the system. First the functional requirements of the system is

identified and described and secondly a channel meta-model is customized to define the key

domain classes. The term meta-model is used to described a model which can represent any

particular channel.

In the object design phase elaborate on a solution to the problem stated in the analysis phase.

Dynamic channels use object-oriented design.

In the implementation phase the classes are programmed. The code is created by using the

diagrams that were entered during the analysis phase.

23


32/194

1.3.2.6.1. Dynamic Channels as a SDM

The philosophical approach of Dynamic Channels is based on object oriented design. The

method includes three phases, namely analysis, object design, and implementation. Theprocess model is sequential. Tools and techniques used are Use-Cases, Channel Modelling,

UML diagrams, and the Object Modelling Technique.

Dynamic Channels thus includes all the components of a SDM according to the definitions of a

SDM used for the purposes of this research, and can be seen as a complete SDM.

1.3.2.7. DTMA

DTMA stands for a Disruption-Tolerant Mobile Application Model. This model is proposed by

Yusof et al. (2010) for developing mobile applications that are able to use remote data access

and overcome the constraints presented by dysfunctional telecommunication connections.

However, this model is a layout for the physical design of such an application and does not

include the steps and methods required for mobile application development. Thus, it cannot be

seen as a mobile application development methodology, but rather as a design structure for

mobile applications which allows an application to tolerate telecommunication connection

disruption.

1.3.2.7.1. DTMA as a SDM

The DTMA models philosophical approach is focused on designing mobile applications that are

minimally affected by poor telecommunications connections. It does not propose a method or

process model for MAD. The tools and techniques used in the model are interviewing and

prototyping.

Figure 1.3.2.6.1. Dynamic Channels Process Model

(Afonso, A.P., Regateiro, F.S. & Silva, M.J.)

24


33/194

Because the DTMA model does not propose a method or process model, it cannot be seen as a

SDM according to the definitions of a SDM used for the purposes of this research. It with

therefore be referred to as a design structure and not be discussed further in the research.

1.3.2.8. Rapid Application Development with DSDM Atern

Rapid Application development (RAD) has been used since 1992 when it was introduced by

James Martin. The goal of RAD is to develop and deliver a high-quality system, in a short time

with low costs (Beynon-Davies, 2002).

A methodology that implements RAD is the Dynamic Systems Development Method (DSDM

Consortium, 1995). With the use of DSDM Atern, which is a framework based on the best

practices and lessons learned by DSDM Consortium members, software can be developed in

an agile environment. Because of the vendor-independent design of the Atern framework, it can

be applied not only to the development of traditional software, but also to mobile application

development.

According to Beynon-Davies (2002), DSDM Atern recognises seven key phases for software

development projects, namely pre-project, feasibility, foundations, exploration, engineering,

deployment, and post-project. The rest of the discussion will be based on these phases.

1.3.2.8.1. Pre-Project Phase

The goal of the pre-project phase is to formalise a project proposal and place it in perspective of

other projects to be executed in the organisation. The phase thus has four main activities:

Describe the business problem

Identify a business sponsor and visionary

Confirm that the project aligns with the business strategies

Scope, plan and resource the feasibility phase

1.3.2.8.2. Feasibility Phase

The feasibility phase exists to allow decisions to be made regarding the viability of a proposed

project from business and technical perspectives. This occurs via a high-level investigation of

the potential solutions, costs, and timeframes.

This phase comprises of six main activities:

25


34/194

Determine whether a feasible solution for the project exists

Determine what benefits will likely be presented by delivery of the solution

Identify the possible delivery approaches

Illustrate the projects organisational features and governance facets

Provide preliminary projections of project timelines and costs Plan and identify the resources required for the foundations phase

1.3.2.8.3. Foundations Phase

The foundations phase focuses on combining the business, solution and management

perspectives of a project to provide a clear, robust, and flexible project focus. This is where

modelling and prototyping are used to assist in requirements gathering. The main activities of

this phase are as follows: Outline the high-level project requirements, describing their priority and relevance to

business needs

Identify which business processes are supported by the project solution

Indicate which data is used, created, or changed by the proposed project solution

Describe the deployment strategies for the solution

Develop a business case

Initial design of solution architecture

Define technical implementation standards

Describe quality assurance methods

Establish project governance and organisation

Describe the development lifecycle and project management approach

Draw up an initial development and deployment schedule

Identify, asses, and manage project risk

1.3.2.8.4. Exploration Phase

The exploration phase involves investigating the business requirements and translating them

into a viable solution, in an iterative, incremental cycle. The solution developed during this

phase is an initial idea and does not yet have to be perfect or include all requirements. The

phase has five main activities:

Discuss the requirements gathered during the foundations phase

Describe the business need in detail and present a detailed list of solution requirements

Develop a functional solution that demonstrates that the business needs are met

26


35/194

Provide the organisation with an early view of the solution which will ultimately be operated,

supported, and maintained by them

Elaborate on the products of the foundations phase and produce them into models

describing how the solution works.

1.3.2.8.5. Engineering Phase

The goal of the engineering phase is to evolve the preliminary solution from the exploration

phase into full operation. Development efforts should be focused mostly on meeting non-

functional requirements such as performance and security.

The engineering phase consists of two main activities:

Refine the exploration phase solution to meet the solution requirements Expand and refine any products required for live operation and support

1.3.2.8.6. Deployment Phase

The goal of the deployment phase is to implement the solution into live operation. For mobile

applications, this may include submitting the application to application markets for sales. The

phase may be iterated if it is feasible to deploy the product in increments, each time providing

an updated version of the product.

The deployment phase consists of the following activities:

Confirm whether the performance and viability of the project are still in check

Deploy the solution into the market

Train end-users if applicable and provide supporting documentation

Train or provide documentation for support staff or operators

Assess the solution on the likelihood that it will meet the initial requirements and provide the

intended business benefits

After the final deployment

o Close the project

o Review project performance

From a business perspective

From a performance perspective

27


36/194

1.3.2.8.7. Post-Project Phase

The goal of the post-project phase is to evaluate the project performance and determine how

well the solution ended up meeting the business needs. It has one main activity:

Evaluate whether the intended business benefits have been achieved by the solution

1.3.2.8.8. DSDM with Atern as a SDM

The philosophical approach of DSDM with Atern is based on rapid application development. It

proposes a method consisting of phases, namely pre-project, feasibility, foundations,

exploration, engineering, deployment, and post-project. Its process model follows the phases

sequentially, but the deployment phase may be executed iteratively if it is deemed feasible to

release the product in increments. The tools and techniques used are a business case and

prototyping.

DSDM with Atern can be seen as a complete SDM, because it includes all components

necessary to constitute a SDM according to the definitions of a SDM used for the purposes of

this research.

1.3.2.9. Scrum Agile Development Methodology

The Scrum framework for application development, formally described by Schwaber and Beedle

in 2002, is part of the agile development methodology family, along with Extreme Programming

and Feature Driven Development. These are said to be the exact opposite of traditional

development methodologies. For instance, Scrum focuses on practical applicability and

Figure 1.3.2.8.7.1 Atern Lifecycle Process (DSDM Consortium, 2008)

28


37/194

flexibility. The vision for Scrum, from the beginning, was that it should be a management and

control tool to bypass complexity and focus on building software applications that satisfy

business requirements.

Scrum takes the initial stance that a development process cannot be planned from start to

finish, because the scope of the application or project will most likely expand and evolve over

time (Overhage & Schlauderer, 2012, Anon, 2012). Scrum starts off with the customer creating

a prioritized list of features that he/she wants in the application and this list is called the product

backlog. Scrum is divided into 3 levels of planning, namely release planning, sprint planning and

the daily scrum. Figure 1.3.2.9.1 below demonstrates the process model of Scrum.

During the release planning the project cost and general functionality of the proposed

application is discussed. Operational details are planned in an iterative fashion as the project

moves forward. These iterations are called sprints and take about a month on average to

complete. These planning sessions are known as the sprint planning session in which the

following sprint is planned. The tasks assigned during this meeting are called the Sprint

Backlog. The third and final planning takes place on a daily basis and is called the daily scrum.

This last planning phase is the most detailed and each member involved in the development of

the application reports on their progress and is assigned new tasks. These sessions should last

no longer than 15 minutes.

The cycle as explained above is repeated enough times that one of the following milestones is

reached, namely most or the entire product backlog has been completed, the budget is finished

or the deadline is reached. Which one of these determines the end of the project is entirely up

to the specific project (Overhage & Schlauderer, 2012, Anon, 2012).

Figure 1.3.2.9.1. Scrum Process Model

29


38/194

1.3.2.9.1. Scrum Agile Development Methodology as a SDM

The philosophical approach of Scrum is based on agile development, focusing on practical

applicability and flexibility to satisfy business requirements. The method consists of three levels

of planning, namely release planning, sprint planning, and daily scrum. The process model is

iterative and incremental. Two tools and techniques that are used are product backlog and

sprint backlog.

Scrum Agile Development can therefore be seen as a complete SDM according to the

definitions of a SDM used for the purposes of this research. It contains all the components of a

SDM according to these definitions.

1.3.2.10. System Development Life Cycle (SDLC)

The SDLC (Waterfall-model, 2012) is used for developing information systems and consists of

ten phases. The ten phases are initiation, System Concept Development, Planning,

Requirements Analysis, Design, Development, integration, implementation, Operations and

Maintenance and Dis

Documents

The Development and Evaluation of a Mobile development methodology