Phương pháp thiết kế Agile cho ứng dụng mobile

Agile Development Methods
for Mobile Applications

Andrei Cristian Spataru

Master of Science
Computer Science
School of Informatics
University of Edinburgh
2010


Abstract
This thesis is aimed at evaluating the suitability of agile methods for mobile application
development projects, bringing a set of improvements to an established agile method
called Mobile-D, and providing tool support to enable these improvements, facilitating
performance testing and usage logging in the lifecycle. The motivation for this work is
to better understand mobile development, and to improve related activities through
research in the field and development of a support tool. After establishing agile
methods as a good approach towards mobile application development, a number of
improvements to the Mobile-D method are presented, including a study in mobile
application categories, related paradigms, end-user inclusion in the lifecycle, as well as
performance testing of components and adoption of software product line principles.
The support tool enabling some of these improvements is then presented, with
functionalities including performance testing for Android components, usage logging
and automatic test case generation. These contributions intend to bring Mobile-D closer
to an ideal mobile application development methodology, while providing useful
features that can be outside the process, either in the form of practices or tools.

i

Acknowledgements
I would like to thank my supervisor, Mr. Stuart Anderson, for all the insightful ideas,
suggestions and feedback I’ve received throughout my work. I would also like to thank
the “Dinu Patriciu” Foundation for funding my studies; I am grateful for the opportunity
they have given me. Special thanks to Panos Tsogas and to Marinos Argyrou who kindly
provided his Android application for me to experiment with.
Finally, I would like to thank my parents for their full support during my studies.

ii


Declaration
I declare that this thesis was composed by myself, that the work contained herein is my
own except where explicitly stated otherwise in the text, and that this work has not
been submitted for any other degree or professional qualification except as specified.

(Andrei Cristian Spataru)

iii


Table of Contents
1 Introduction .................................................................................................................................. 1
1.1

Mobile application development ...........................................................................................1

1.2

Agile development for mobile applications ......................................................................2

1.3

Mobile-D overview ......................................................................................................................4

1.4

Improvement approaches ........................................................................................................6

2 Improvements to Mobile-D ...................................................................................................... 9
2.1

Categories of mobile applications .........................................................................................9

2.2

Alternatives approaches to mobile development ........................................................ 13

2.3

Bringing end-users into the lifecycle ................................................................................ 16

2.4

Performance testing in Mobile-D ........................................................................................ 23

2.5

Software product line principles ........................................................................................ 28

2.6

Questionnaire results .............................................................................................................. 30

3 Android Resource Management .......................................................................................... 32
3.1

System description ................................................................................................................... 32

3.1.1

Evaluate method performance .................................................................................. 35

3.1.2

Evaluate method sequence performance .............................................................. 37

3.1.3

Evaluate test performance........................................................................................... 39

3.1.4

Log user actions ............................................................................................................... 41

3.1.5

Analyze usage logs .......................................................................................................... 45

3.1.6

Generate tests from logs ............................................................................................... 46

3.1.7

System utilization ............................................................................................................ 50

3.2

Impact on Mobile-D .................................................................................................................. 50

iv


4 Conclusions and further work ............................................................................................. 52
4.1

Overview of improvements .................................................................................................. 52

4.2

Discussion .................................................................................................................................... 53

4.3

Further work............................................................................................................................... 54

4.3.1

Mobile-D .............................................................................................................................. 54

4.3.2

Support tool ....................................................................................................................... 54

5 Bibliography ............................................................................................................................... 56

v


List of Figures
Figure 1. Mobile-D phases and stages; Source: (VTT Electronics, 2006)................................6
Figure 2. Proposed categories of mobile applications, based on (Oinas-Kukkonen &
Kurkela, 2003), (Unhelkar & Murugesan, 2010) and (Kunz & Black, 1999) ................. 11
Figure 3. Scope definition stage, adapted from (VTT Electronics, 2006) ............................ 12
Figure 4. Mobile development method proposed in (Rahimian & Ramsin, 2008) .......... 15
Figure 5. Main elements of stakeholder identification; Source: (Sharp, Finkelstein, &
Galal, 1999) ............................................................................................................................................... 19
Figure 6. Stakeholder establishment stage, adapted from (VTT Electronics, 2006)....... 20
Figure 7. End-user establishment steps............................................................................................. 21
Figure 8. Initial requirements collection steps; Source: (VTT Electronics, 2006) ........... 21
Figure 9. Mobile-D with added Evolve phase. Adapted from (VTT Electronics, 2006) ... 22
Figure 10. Performance requirements evolution model; Source: (Ho, Johnson, Williams,
& Maximilien, 2006).............................................................................................................................. 25
Figure 11. Tasks for Project establishment stage; Source: (VTT Electronics, 2006) ...... 26
Figure 12. Working day including the performance testing task; Adapted from: (VTT
Electronics, 2006) .................................................................................................................................. 27
Figure 13. Adoption Factory pattern, high-level view; Source: (Jones & Northrop, 2010)
........................................................................................................................................................................ 29

Figure 14. Use Case Diagram for the system ................................................................................... 33
Figure 15. Spinner (left) and MultiRes (right) applications ...................................................... 34
Figure 16. Wizard used to generate a performance test case for methods ........................ 35
Figure 17. Code generated by method performance wizard .................................................... 36
Figure 18. Code generated by method sequence performance wizard ................................ 38
Figure 19. Method queue performance test log ............................................................................. 39
Figure 20. Wizard used to generate a timed test for existing Android test cases ............ 39
Figure 21. Code generated by timed test wizard ........................................................................... 40
Figure 22. Usage log lifecycle ................................................................................................................. 42
Figure 23. Logging instructions ............................................................................................................ 43
Figure 24. Log generated for 5 runs of the MultiRes application ............................................ 44
Figure 25. Log file statistics view ......................................................................................................... 45
Figure 26. Logs and serialized objects ............................................................................................... 46
Figure 27. Test case generation wizard ............................................................................................. 47

vi


Figure 28. Code created by test case generation wizard ............................................................ 48
Figure 29. Test result interpretation for generated test cases................................................. 49

vii


List of Tables
Table 1. Methods for performance evaluation ................................................................................ 37
Table 2. Methods available for test performance evaluation.................................................... 41

viii

Chapter 1
Introduction

1.1 Mobile application development
The mobile applications market is currently undergoing rapid expansion, as mobile
platforms continue to improve in performance, and as the users’ need for a wide
variety of mobile applications increases. The latest mobile platforms allow for
extensive utilization of network resources, and thus offer a strong alternative to
workstations and associated software.
Software development for mobile platforms comes with unique features and
constraints that apply to most of the lifecycle stages. The development environment
and the technologies that support the software are different compared to “traditional”
settings. The most important distinguishing characteristics are identified in
(Abrahamsson, et al., 2004). Environment particularities include: a high level of
competitiveness; necessarily short time-to-delivery; and added difficulty in identifying
stakeholders and their requirements. Development teams must face the challenge of a
dynamic environment, with frequent modifications in customer needs and
expectations. (Abrahamsson, 2007) Technological constraints apply to mobile
platforms in the form of limited physical resources and rapidly changing specifications.
There is also a great variety of devices, each with particular hardware characteristics,
firmware and operating systems. Another view of the constraints associated with
mobile applications is presented in (Hayes, 2003). The author mentions two types of
constraints, evolving and inherent. Evolving constraints, such as bandwidth, coverage
and security, currently apply to the mobile technology, but are likely to be addressed
and possibly resolved in the near future. On the other hand, inherent constraints such
as limited screen real estate, reduced data entry capability (due to a limited keypad for
example), memory capacity, processing power and limited power reserve, are
permanent, at least relative to desktop environments. Various approaches must be
used in order to lower the impact of inherent constraints.

1


Due to significant differences in the environment and in platform specifications, mobile
application development requires a suitable development methodology. By taking into
account the main features of a mobile application development scenario, a matching
development paradigm can be identified. These features are presented in
(Abrahamsson, 2005): the software is released in an uncertain and dynamic
environment with high levels of competition. Teams that develop mobile applications
are usually small to medium-sized, co-located, and generally use object-oriented tools
and practices. The applications themselves are small-sized, are not safety-critical, and
do not have to satisfy interoperability or reliability constraints. They are delivered in
rapid releases in order to meet market demands, and are targeted at a large number of
end-users. The author suggests agile methods as a suitable approach to development,
by comparing the above features to agile “home ground” characteristics: small-scale,
application-level software, developed in a highly dynamic environment by a small to
medium-sized team using object-oriented approaches, in relatively short development
cycles.
The following section provides a short overview of agile methods, focusing on their
suitability for mobile application development.

1.2 Agile development for mobile applications
Agile methods represent a relatively new approach to software development, becoming
wide-spread in the last decade. The ideas behind these methods originate from the
principles of Lean Manufacturing (in the 1940s) and Agile Manufacturing (1990s),
which emphasized the adaptability of enterprises to a dynamic environment (Salo,
2006). The unique features of agile methods derive from the list of principles found in
the “Agile Manifesto”: individuals and interactions are more important than processes
and tools, working software is more valuable than comprehensive documentation,

customer collaboration is preferred over contract negotiation, and adaptability is
valued higher than creating and following a plan (Agile Alliance, 2001).
In (Boehm & Turner, 2003), the authors identify fundamental concepts to agile
development: simple design principles, a large number of releases in a short time
frame, extensive use of refactoring, pair programming, test-driven development, and

2


seeing change as an advantage. Another definition of agile methods is provided in
(Abrahamsson, et al., 2002): an agile development method is incremental (multiple
releases), cooperative (a strong cooperation between developer and client),
straightforward (easy to understand and modify) and adaptive (allowing for frequent
changes).
The use of agile methods in software development has received both supporting and
opposing arguments. The main argument against agile methods is the asserted lack of
scientific validation for associated activities and practices, as well as the difficulty of
integrating plan-based practices with agile ones. Indeed, some projects present a mix of
plan-based and agile home ground characteristics, in which case a balance must be
achieved in the use of both types of methods (Boehm, 2002). There is also some
amount of uncertainty in distinguishing agile methods from ad-hoc programming.
However, as stated in (Salo, 2006), agile methods do provide an organized
development approach.
When trying to compare mobile application characteristics to those of an agile method,
difficulty comes partly from the fact that boundaries of agile methodologies are not
clearly established. A comprehensive overview of research in the field is presented in
(Dyba & Dingsoyr, 2009). The authors partition studies into four categories:
introduction and adaptation, human and social factors, perception of agile methods,
and comparative studies. Findings indicate that the introduction of agile methods to
software projects yields benefits, especially if agile practices do not completely replace

traditional ones, but work in conjunction with them. However, according to the
authors, studies in the field are mostly focused on Extreme Programming (XP), are
limited in number and are of doubtful quality.
In (Abrahamsson, 2005), the author performs a direct comparison between agile
method characteristics and mobile application features, focusing on environment
volatility, amount of documentation produced, amount of planning involved, size of the
development team, scale of the application in-development, customer identification,
and object orientation. Except customer identification, all other agile characteristics
render the methods suitable for mobile application development. The customer may be
identified as the software distributor. However, especially in the case of mobile
applications, the customer identification problem is much more complex, as will be
detailed in a later section of this work.

3


A new development methodology, specifically tailored for mobile application
development, called Mobile-D, is presented in (Abrahamsson, et al., 2004). The method
is based on agile practices, drawing elements from well established agile methods such
as Extreme Programming and Crystal Methodologies, but also from the “heavier”
Rational Unified Process. Additional information on XP is available in (Beck & Andres,
2004), while Crystal Methodologies are thoroughly described in (Cockburn, 2004). The
Rational Unified Process is explained from a practical point of view in (Kroll &
Kruchten, 2003). Practices associated to Mobile-D include test-driven development,
pair programming, continuous integration, refactoring, as well as software process
improvement tasks. The methodology serves as a basis for this work, and will be
further detailed in the following section.

1.3 Mobile-D overview
According to (Abrahamsson, et al., 2004), the Mobile-D process should be used by a

team of at most ten co-located developers, working towards a product delivery within
ten weeks. There are nine main elements involved in the different practices throughout
the development cycle:
1. Phasing and Placing
2. Architecture Line
3. Mobile Test-Driven Development
4. Continuous Integration
5. Pair Programming
6. Metrics
7. Agile Software Process Improvement
8. Off-Site Customer
9. User-Centred Focus
The Architecture Line in the methodology is a new addition to the already established
agile practices. An architecture line is used to capture an organization’s knowledge of
architectural solutions, from both internal and external sources, and to use these
solutions when needed.

4


Mobile-D comprises five phases: Explore, Initialize, Productionize, Stabilize, and System
Test & Fix. Each of these phases has a number of associated stages, tasks and practices.
The complete specifications of the method are available in (VTT Electronics, 2006).
In the first phase, Explore, the development team must generate a plan and establish
project characteristics. This is done in three stages: stakeholder establishment, scope
definition and project establishment. Tasks associated to this phase include customer
establishment (those customers that take active part in the development process),
initial project planning and requirements collection, and process establishment.
In the next phase, Initialize, the development team and all active stakeholders
understand the product in development and prepare the key resources necessary for

production activities, such as physical, technological, and communications resources.
This phase is divided into three stages: project set-up, initial planning and trial day.
The Productionize phase mainly comprises implementation activities. At the end of this
phase, most of the implementation should be complete. This phase is divided into
planning days, working days, and release days. Planning days are aimed at enhancing the
development process, prioritizing and analyzing requirements, planning the iteration
contents, and creating acceptance tests that will be run later in release days. In working
days, the Test-Driven Development (TDD) practice is used to implement functionalities,
according to the pre-established plan for the current iteration. Using TDD along with
Continuous Integration, developers create unit tests, write code that passes the tests,
and integrate new code with the existing version of the product, addressing any errors
that may arise in the integration process. Finally, in release days a working version of
the system is produced and validated through acceptance testing.
The final two phases, Stabilize and System Test & Fix, are used for product finalization
and testing respectively. They comprise stages similar to the Productionize phase, with
some modifications to accommodate documentation building and system testing.

5


Figure 1. Mobile-D phases and stages; Source: (VTT Electronics, 2006)

Mobile-D has already been applied in development projects, and some advantages have
been observed, such as increased progress visibility, earlier discovery and repair of
technical issues, low defect density in the final product, and a constant progress in
development (Abrahamsson, et al., 2004). Other applications of the method are
presented in (Pikkarainen, Salo, & Still, 2005) and (Hulkko & Abrahamsson, 2005).

1.4 Improvement approaches
In order to obtain a set of improvements to a given development methodology, one

must first analyze the key method characteristics that have yielded successful results in
previous projects. For mobile application development methods, key success
characteristics are identified in (Rahimian & Ramsin, 2008). These are agility of the
approach, market consciousness, software product line support, architecture-based
development, support for reusability, inclusion of review and learning sessions, and
early specification of physical architecture. Some of these key features can already be
found in the Mobile-D method (agility, early specification of physical architecture,
architecture-based development, and review and learning sessions); however, the
method could be improved if more of these key success features could be integrated.

6


Possible additions to Mobile-D include better market awareness, software product line
support and reusability support. The last two features could be implemented with the
final goal of cost minimization, but may be infeasible to micro-companies, or companies
with low experience in mobile application development, as these companies may not
have established libraries of components in order to successfully apply software reuse
principles. Review and learning sessions can be found in the methodology as Postiteration Workshops and Wrap-ups, designed to improve the development process by
identifying its’ strengths and weaknesses, and to communicate progress and problems
within the team.
The list of ideal traits found in (Rahimian & Ramsin, 2008) can be further extended. In
the case of mobile applications, end-user identification is not straightforward. This has
also been pointed out in (Abrahamsson, 2005), when comparing agile home ground
characteristics to mobile application development requirements. For agile methods, the
customer has to be easily identifiable, which is not always the case for mobile
applications. In order to address this issue, the list of key characteristics of a mobile
development methodology can be extended to include balancing customer, end-user,
and sometimes platform vendor requirements. These three entities rarely coincide
when dealing with mobile applications. In cases where the entity requesting the

software product differs from the end-user, the contracting entity should be made
aware of the possibly different set of end-user requirements. For the development
team, this means a balance must be established between customer, requirements, enduser expectations and platform vendor constraints. We can assume that identifying and
including end-users in the development process will prove beneficial by ensuring their
requirements and expectations are met, and for finding possible defects. The approach
to integrating end-user requirements in the development process is detailed in a later
section. The issue has been addressed by organizations through user testing sessions in
special labs, observing the way users interact with the system. The following list
represents an adapted prioritization of traits for successful mobile application
development methodologies.
1. Agility
2. Market consciousness
3. Early specification of physical architecture
4. End-user feedback support
5. Software product line support

7


6. Reusability support
7. Architecture-based development
8. Review and learning sessions
This work focuses on improvements to the mobile application development methods in
general, and to the Mobile-D method in particular. Using the above list as a guideline,
the project investigates possible improvements in particular sub-areas.
By examining categories of successful mobile applications, the product-in-development
may be aligned to one category, and specific measures can be taken to improve quality
and minimize risk for the current application. The alignment procedure can be included
as a task in a certain stage of Mobile-D. Principles from other development
methodologies can be integrated into Mobile-D, when the scenario would favour their

use. The entire method could import concepts from other approaches, and become
adaptable to the project at hand.
The end-users’ contribution to the development process must be identified, in order to
ensure the success of a product. More precisely, the timing, extent and potential
benefits of end-user participation must be established. Obtaining a balance between the
three sets of requirements, customer, end-user and platform vendor, is important
especially in those cases where the requirements are not convergent.
Mobile platforms suffer from performance constraints. Mobile-D makes extensive use of
the Test-Driven Development practice; however, the test cases do not take into account
resource utilization, partly because the tool support for this task is poor. In order to
improve the methodology, TDD must be adapted to take into account resource testing,
especially for limited-resource situations. This modification also affects related tasks in
different stages of the Mobile-D methodology. When potential resource bottlenecks are
identified, they can be eliminated by writing better code, or later through refactoring
and the use of patterns.
Finally, the methodology can be improved by examining the benefits of software
product line principles and by establishing their correct integration with Mobile-D.

8


Chapter 2
Improvements to Mobile-D

2.1 Categories of mobile applications
There are many ways in which mobile applications can be categorised. Nevertheless,
any plausible partition can lead to better results in the development process, due to a
higher focus on issues that are specific to the respective application type. Depending on
the experience of the development team, different measures can be taken. For a
seasoned team, identifying the application type means experiences from developing

similar applications in the past can be used. Teams with less development experience
can also benefit from categorisation, by obtaining and implementing a specific set of
guidelines and principles for the specific type of application.
In (Varshney & Vetter, 2001) the authors identify twelve classes of mobile commerce
applications. Example classes include Mobile financial applications (banking and micropayments), Product location and shopping (locating and ordering items), and Mobile
entertainment services (video-on-demand and similar services). However, these classes
only apply to mobile commerce applications (mobile applications that involve
transactions of goods and services) and do not help to provide guidelines to developing
new applications. To this purpose, the findings in (Oinas-Kukkonen & Kurkela, 2003)
prove more useful. Citing a report by Ramsay and Nielsen on WAP usability, the authors
divide mobile applications into two groups: highly goal-driven and entertainmentfocused. The definition of each group is quite simple: highly goal-driven applications
aim to provide fast responses to inquiries, while entertainment-focused applications
help users pass the time. The authors move on to provide seven guiding principles for
the development of highly goal-driven mobile services: mobility (provide information
while on the move), usefulness, relevance (include only relevant information), ease of
use, fluency of navigation (most important information should be easiest to locate),
user-centred (adapt to the users’ way of interaction and way of thinking), and
personalization (adapt to users’ needs and capabilities). Providing guidelines for the

9


entertainment-focused category of applications can be quite difficult and outside the
scope of the current discussion.
A taxonomy of mobile applications from an enterprise point of view is established in
(Unhelkar & Murugesan, 2010). The authors state that this organization and
representation of mobile applications will make the demands placed on the
applications more visible, and will help developers focus on the most important aspects
of design and implementation for each project. The lowest level in the taxonomy
(organized by application richness and complexity) is represented by Mobile broadcast

(M-broadcast) applications, that are aimed at providing large-scale broadcast of
information to mobile platforms. Higher-level applications are Mobile information (Minformation) applications, which provide information required by mobile users, such as
weather conditions. The third level of applications is Mobile transactions (Mtransaction) facilitating e-transactions and customer relationship management. The
fourth level, Mobile operation or M-operation deals with operational aspects of the
business such as inventory management or supply-chain management. Finally, the top
level of the taxonomy is represented by Mobile collaboration (M-collaboration), a class
of applications that support collaboration within and outside the enterprise.
Even though the authors exclusively analyze mobile applications in an enterprise
context, recommendations are provided for each type of application; these can be
applied in most similar projects. In M-broadcast applications, content is broadcast to a
large number of unregistered users, while in M-information users request and receive
information in an individual fashion. Issues associated to this category of applications
include usability and privacy, security not being of high relevance. M-transaction
applications enable mobile transactions, such as placing and tracking orders and
making electronic payments. This category of applications has higher requirements in
terms of security, responsiveness and reliability, and requires communication between
three parties: user, service provider and financial mediator (such as an online payment
gateway). M-operation applications are required to provide real-time information and
also integrate back-end systems and databases. The final group of applications, Mcollaboration, have associated coding and data-management challenges due to the
required support for the interaction between different software modules.
Six different categories of mobile applications are identified in (Kunz & Black, 1999):
standalone applications (games or utilities), personal productivity software (word

10


processors and office applications), Internet applications (e-mail clients, browsers),
vertically integrated business applications (security), location-aware applications (tour
planners and interactive guides) and ad-hoc network and groupware application (a
group of users establish an ad-hoc network to exchange documents). The authors point

out some important requirements associated to the identified groups of mobile
applications. For personal productivity software, synchronization between the mobile
and desktop versions of the software is indicated as an important requirement. For the
third category, Internet applications, the issue of client application performance and
resource requirements is emphasized. The authors state that a mobile client
application cannot “borrow” from non-mobile client applications, as these have
completely different underlying assumptions in terms of performance requirements
and availability of resources. These issues also apply to vertically integrated business
applications, as the servers should remain unaware of the type of client they are
communicating with (mobile or non-mobile), in order to ease the deployment of mobile
applications.
The works described above serve as a basis for establishing a way to categorize mobile
applications, and to integrate the categorization task with the Mobile-D methodology.
The new proposed taxonomy in presented in Figure 2.

Figure 2. Proposed categories of mobile applications, based on (Oinas-Kukkonen &
Kurkela, 2003), (Unhelkar & Murugesan, 2010) and (Kunz & Black, 1999)

The categories are not exhaustive or exclusive. Each team or company can expand a
category, according to their own experience and past projects. For example, the

11


Entertainment category does not have sub-categories due to the high diversity of this
type of applications. A company specializing in mobile games can further expand this
category by taking into account different types of games they have developed in the
past.
To sum up, the benefits of application categorization in the lifecycle are twofold:
obtaining a set of guidelines customized to the specific application type, and using

previous experiences to develop a new application of the same type. These experiences
can be used to estimate effort for example, similar to using the Standard Component
Estimation technique in software estimation tasks.
The optimal location of the categorization task within the Mobile-D method is in the
Explore phase, which contains the Scope definition stage (Figure 1). According to the
Mobile-D specifications (VTT Electronics, 2006), the Scope definition stage defines goals
and sets the timeline for the project. If the team identifies the category of application
they are developing, they can establish project goals that respect the specific guidelines,
and can shape the initial schedule according to data gathered from previous similar
projects.
The Scope definition stage comprises two essential tasks: Initial project planning and
Initial requirements collection. By performing the Initial project planning task, the
development team sets the project timeline, rhythm of development and estimates the
required investments for the project, in terms of effort, finances, etc. The outcome of
this task can be positively influenced if it is preceded by the new task concerned with
project category establishment, so that estimates within the stage will be more
accurate. The new flow of tasks within the Scope definition stage is presented in Figure
3.

Figure 3. Scope definition stage, adapted from (VTT Electronics, 2006)

12


When a project is completed, the experiences in terms of recommended practices, tools,
and estimates should be recorded under the specific category for later reference.

2.2 Alternatives approaches to mobile development
Even though agile methodologies offer a good solution for mobile application
development, different approaches exist in literature. Mobile-D is clearly the most

detailed methodology for the purpose, having a comprehensive specification for each
phase and stage, and for the associated tasks. However, other promising approaches
might improve Mobile-D in some aspects, and also increase the flexibility of the method.
A recurring theme in related research is the use of Model-Driven Engineering (MDE),
more specifically Model-Driven Development (MDD), for mobile application
development. According to (Beydeda, Book, & Gruhn, 2005), Model-Driven
Development involves using models not only to document code, but to serve as a basis
for application development. In (Balagtas-Fernandez & Hussmann, 2008) the authors
propose a development approach that combines principles from both MDD and
Human-Computer Interaction (HCI), more precisely from the field of User Centred
Design. The purpose of the approach is to obtain a system that lets novice users with no
programming experience create their own mobile applications. The main argument for
MDD in mobile application development is the possibility to create a platformindependent model of the application, which will be automatically transformed into
platform-specific code. This is an important advantage for MDD, as the number of
platforms for the software is large and constantly increasing. By allowing end-users to
create their own applications, and by making the process user-friendly through UserCentred Design principles, the need for external developers would disappear,
decreasing costs and development time.
Aside from the large number of platforms the software has to run on, there is another
issue associated with mobile applications, namely factors that affect every element of
an application, such as resource limitations. In order to address both of these issues,
(Carton, et al., 2007) propose a development approach that combines Aspect-Oriented
Software Development (AOSD) techniques with Model-Driven Development ones. The
authors talk about “crosscutting factors”, such as device limitations or user
connectivity, as being influences that cannot be easily handled by traditional

13


programming approaches such as Object-Oriented Programming or Procedural
Programming, and that affect the entire application. These factors lead to a number of

problems. Firstly, software engineers cannot easily separate application semantics
from technical specifics, and secondly, developers have to implement these
crosscutting concerns throughout the application. This in turn leads to lower software
maintainability, extensibility and comprehensibility. Crosscutting concerns represent
the basis for aspects in Aspect-Oriented Design, so by using this approach in
development, the concerns can be modularized, thus increasing the maintainability,
extensibility and comprehensibility of the code. In this approach MDD is used, as
before, to translate a high level platform-independent design into multiple, platformdependent implementations. In Model-Driven Architecture (MDA), which is MDD
standardized by the Object Management Group (OMG), a number of Platform-Specific
Models (PSMs) are generated from a Platform-Independent Model (PIM) using
transformations. In general terms, the combination of AOSD and MDA yields benefits
from both approaches, by minimizing the effects of crosscutting concerns and platformspecific issues. An important part of MDD is transforming models into code (code
generation). This issue has not been detailed in the considered papers; however an
approach to code generation in mobile application development is available in
(Amanquah & Eporwei, 2009).
Even though the subject of MDD for mobile applications is still largely unexplored,
there are some initial impressions of usage. In (Braun & Eckhaus, 2008), MDD is used to
develop an architecture that supports the provision of a mobile service both as a Web
service and Mobile application. The goal was to allow the provided services to be
accessed both via built-in XHTML browser and pre-installed Java application. The
outcome of the approach was successful, as MDD proved flexible enough for the task.
Another MDD approach has been documented in (Khambati, et al., 2008), for the
development of mobile personal healthcare applications. In this case, MDD helps
healthcare providers create personalized applications modelled from a health plan
specific to each patient. Unfortunately, there are no comprehensive studies on the effect
of MDD in mobile applications in literature, and no empirical data provided in the
considered papers. This leaves MDD as an experimental approach that may be
integrated in Mobile-D only if the development team has experience in using the
associated practices, and considers that noticeable benefits may be gained through the
use of MDD.

14


A different approach is presented in (Rahimian & Ramsin, 2008). The authors use a
Methodology Engineering approach, called Hybrid Method Engineering, to generate a
method suitable for mobile application development. Methodology Engineering is a
discipline concerned with creating methodologies suitable for different development
scenarios, motivated by the belief that no single process fits all situations. Hybrid
Methodology Design uses pre-established key requirements and conclusions as input, to
iteratively generate the desired methodology. In the present case, the authors use as
input a list of key methodology traits, similar to the ones previously described on page
7, as well as conclusions from related work in the field. Each iteration of the method
comprises the following tasks: prioritization of requirements, selection of the design
approaches to be used in the current iteration, application of the selected design
approaches, revision, refinement and restructuring of the methodology built so far,
defining the abstraction level for the next iteration, and finally the revision and
refinement of the requirements, prioritizing them for the next iteration.
The proposed mobile development methodology is created in four iterations, starting
from a generic software development lifecycle (Analysis, Design, Implementation, Test,
and Transition). In the first iteration, the methodology is detailed by adding practices
commonly found in agile methods. Taking into account market considerations, the
second iteration includes activities from New Product Development, a process
concerned with introducing a new product or service to the market. In the third
iteration, Adaptive Software Development (ASD) ideas were integrated into the
methodology, while in the final iteration prototyping was added to mitigate likely
technology-related risks. The final methodology phases proposed by the authors are
presented in Figure 4.

Figure 4. Mobile development method proposed in (Rahimian & Ramsin, 2008)

15


The proposed development framework takes into account most of the issues identified
in related work in the field. However, the methodology is still at a high-level, and no
specific tasks for the identified stages have been provided. According to the authors,
future work includes performing further iterations to obtain lower-level tasks in the
process. In its’ current state, the methodology is too high-level to integrate with MobileD.
In (Unhelkar & Murugesan, 2010), the authors describe a framework for enterprise
mobile application development. Their approach uses a layered architecture, composed
of Communications (network with protocols), Information (database), Middleware and
binding (service frameworks), Application (business applications like bookings and
payments) and Presentation layers (user interface), with the Security layer orthogonal
to the previous five. The presented framework has been successfully applied in three
enterprise projects, with more attention being paid to certain layers, according to the
organization’s profile.
If categorization is used in the Mobile-D methodology as previously explained, and the
project in question is found to be an enterprise project, the framework presented in
(Unhelkar & Murugesan, 2010) could provide a useful architectural model for the
development team. The information could be taken into consideration in the Explore
phase, Project establishment stage (see Figure 1), when performing the task called
Architecture Line Definition. According to Mobile-D specifications, the aim of the task is
to gain confidence in the architectural approach, in order for the project to be
successfully carried out. More precisely, the goal of the task is to define an architecture
line for the project. Further details on the architecture line in Mobile-D are available in
(Ihme & Abrahamsson, 2005).

2.3 Bringing end-users into the lifecycle
In certain mobile development scenarios stakeholder establishment is not

straightforward, especially in terms of end-user identification. This issue has been
pointed out in (Abrahamsson, 2005) when discussing the suitability of agile methods
for mobile development. The conclusion was that, for mobile products, customers were
harder to identify due to the multitude of software distribution channels, resulting in a

16