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

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 ca

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

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

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)

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

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

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

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

List of Tables

Table 1 Methods for performance evaluation 37 Table 2 Methods available for test performance evaluation 41

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

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

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

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

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

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

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

Post-iteration 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, end-user 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

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

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 payments), Product location and shopping (locating and ordering items), and Mobile

micro-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

entertainment-focused 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

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

(M-information) applications, which provide information required by mobile users, such as

weather conditions The third level of applications is Mobile transactions

(M-transaction) 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, M-

collaboration, 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

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

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)

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 platform-independent 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 User-Centred 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

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, platform-dependent 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 platform-specific 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

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)

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

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

clash with agile principles that require close customer contact In this section, we will examine the role of the end-user (consumer) in the mobile development lifecycle, and how their requirements are addressed and balanced against those of other stakeholders In general terms, end-users could be consulted during two stages of product development: during requirements gathering, and after releasing the product,

to measure acceptance and obtain feedback This section studies both cases, and

suggests a way of integrating end-user contact in Mobile-D

The recent trend in mobile software distribution is towards App Stores (such as Apple App Store or Android Market), and significantly less towards operator portals and on-device preloading through Original Equipment Manufacturer (OEM) deals These findings are presented in a recent comprehensive study on mobile development economics (VisionMobile, 2010) According to the study, app stores are regarded as direct developer-to-consumer channels, drastically reducing the time-to-shelf (time taken by application to become available for purchase) and time-to-payment (time elapsed from the moment the application was sold, to the developer receiving the proceeds) App stores have also eliminated serious obstacles from the route to market

of a mobile product, such as complex submission and certification procedures and low revenue shares However, even though App stores bridge the gap to end-users from a marketing perspective, the extremely high number of applications available to the user

in such a store means exposure for a small development firm will be quite low One developer described the situation as “going to a record store with 200,000 CDs; you’ll only look at the top-10” This means developers find it hard to reach representative users to perform beta testing and obtain valuable feedback on the product The authors

of the study suggest creating a testing and feedback channel between developers and end-users, provided by network operators, as well as crowd-sourced testing through the few existing platforms

In order to ensure the success of a software product, requirements of stakeholders must be carefully identified, prioritized and balanced In some cases with mobile applications, a 3-way balance must be struck between the customer, end-user and possibly platform vendor or network operator requirements Conflicting requirements could have serious negative effects on the project outcome, as described in (McGee-Lennon, 2008) The effects are envisaged for home care software systems, but apply to any system that is expected to have a high level of usability, such as mobile applications System failure may occur if the product fails to deliver desired benefits;

poor usability can result if the end-user is not properly considered in the design process, and finally reluctance to accept and use the system may result from an incorrect approach towards the user, or an incorrect identification of user categories

To address conflicting requirements, developers may turn to the field of Requirements engineering (RE) and its’ associated activities According to (Hofmann & Lehner, 2001), requirements engineering is concerned with specifying requirements according to the stakeholders’ needs, as well as analyzing and refining those specifications Four interconnected activities have to be performed in order to obtain a useful set of requirements: elicitation, modelling, validation and verification The team must first elicit requirements using available sources, such as users, experts or documents, and then model them The resulting model must then undergo a normalization process, the result of which being validated and verified Requirements elicitation methods include user interviews, group sessions using focus groups, or even the knowledge of experts employed solely to obtain requirements for a given system The end-user can participate in most RE activities: elicitation, validation and verification, using interviews, peer reviews, and walk-throughs The authors also provide a grouping of stakeholders, differentiating between customer and user groups The groups are separated by their motivation and expertise areas; customers would want to introduce change with maximum benefit, while users want to introduce change with minimum disruption

The issue of stakeholder identification is presented in detail in (Sharp, Finkelstein, & Galal, 1999) The analysis starts by identifying “baseline” stakeholders of two types:

“supplier” and “client” Suppliers contribute information and tasks, while clients inspect the products Then, “satellite” stakeholders are recognized This is a broader category

of stakeholders, which cooperate with the baseline in multiple ways The approach focuses on the interaction between these stakeholder categories, presented in Figure 5 There are four groups of baseline stakeholders: users, developers, legislators and decision-makers The identification process is done in a number of steps, for each baseline group, in order to explore the entire web of stakeholders The group relevant

to the current discussion is the users, which have to be split into different roles, according to their expertise, expected goals, and position in the organization

The authors describe a detailed procedure to identify all relevant stakeholders, with the added benefit of starting from a known core of “baseline” stakeholder groups, and

exploring onwards Still, the process might become too time-consuming for small projects The important aspect that should be considered by lightweight methodologies

such as Mobile-D is that the “user” stakeholder group should be carefully examined in

terms of roles, and, according to (Hofmann & Lehner, 2001), should be regarded separately from the “customer” group having different objectives

Figure 5 Main elements of stakeholder identification; Source: (Sharp, Finkelstein, &

Galal, 1999)

The next step after identifying end-users is including them in the development process

In (Oinas-Kukkonen & Kurkela, 2003), the authors argue that real users must be taken into design and development work in order to ensure the success of a mobile product Furthermore, the developers must perform usability studies, to ensure their product is usable enough (Mahmood, Burn, Gemoets, & Jacquez, 2000) also support the principle

of user involvement in the lifecycle They suggest end-user satisfaction will increase with increased involvement of users in system development, and so the finished system will be viewed as more useful by consumers

End-users can be involved in two different points of the product’s lifecycle: design and post-release At design time, user feedback is enabled through the fore mentioned requirements engineering activities of identifying and involving them in development,

through user beta testing, and focus groups Other activities such as reviews and questionnaires might be used to obtain feedback after the product’s release However, for small development companies these solutions might prove too expensive As for their agile, short-iteration, short time-to-market products, the time required for these activities could prove too long Therefore, for a successful integration of these activities

with Mobile-D, we must consider the scale of the projects Mobile-D is suitable for

The Explore phase of the methodology includes a stage pattern that deals with

stakeholder establishment The most important stakeholders that must be identified during this stage are steering group, project team, customer group, support group and exploration group The customer group is established using a dedicated task pattern

within the Stakeholder establishment stage, and has three main goals: identifying

participative customers, gaining their commitment to the project, and defining their tasks, roles and responsibilities, as well as their location (on-site or off-site) According

to the specification, the representation of the customer changes according to the project type: if the team is developing a product for a specific customer organization, identification is straightforward, and the customer is treated as in other agile methods However, if the product in-development is a component for an in-house product, or is a commercial item, specifications recommend the customer be represented by members

of the same organization This decision limits the input from real users and might cause

a misrepresentation of their expectations By including end-users in the lifecycle in the

previously mentioned points, Mobile-D should become more useful for developing

commercial products, to be released directly to end-users Figure 6 shows the

integration of the new End-user establishment task in the Stakeholder establishment

stage

Figure 6 Stakeholder establishment stage, adapted from (VTT Electronics, 2006)

The new task pattern is concerned with identifying end-user groups and defining the

sources of requirements generated by end-users Depending on project parameters

(especially time devoted to this stage), identification may be more or less in-depth If

enough resources are available, focus groups or questionnaires might be used as a

source of requirements Otherwise, the team might generate requirements from

existing guidelines and own experience Figure 7 shows the sequence of steps needed

to perform End-user establishment

Figure 7 End-user establishment steps

This task is in close connection with the Initial Requirements Collection task in the next

stage (Scope definition), as shown in Figure 1 After stakeholder establishment, the

team proceeds to perform initial project planning and requirements collection Figure 8

shows the steps necessary to conduct Initial Requirements Collection When gathering

requirements, end-user requirements are also collected from the previously

established sources During requirements discussion, the relevance and reliability of

end-user requirements is agreed upon, and balanced with existing requirements from

all other stakeholders, such as the customer, vendor and operator End-user

requirements must be taken into consideration whenever requirements analysis

activities are performed, such as in Planning days

Figure 8 Initial requirements collection steps; Source: (VTT Electronics, 2006)

The next point in the lifecycle suitable for end-user participation is post-release

Unfortunately, Mobile-D does not provide guidelines on this phase of a product’s lifecycle, as the final documented phase is System Test & Fix, ending with a final release

To address this issue, the methodology can be extended in terms of lifecycle coverage,

as shown in Figure 9

Figure 9 Mobile-D with added Evolve phase Adapted from (VTT Electronics, 2006)

The new Evolve phase deals with continuously integrating end-user feedback on the

delivered product into future releases Feedback can come from multiple sources, such

as consumer and peer reviews, or data generated by the application itself (usage

statistics and crash reports) The first task, Data analysis, requires the team to obtain

and analyze feedback data By analyzing usage statistics, conclusions can be drawn on whether a particular component of the software is used enough to justify further maintenance and updates, while error and crash reports trigger a sequence of stages,

similar to those in the System Test & Fix phase When a defect is reported, the team locates and documents it Then, a Fix iteration comprising a Planning day, Working day and Release day is performed In the Planning day, the developers attempt to reproduce

reported defects, in order to fix them and create a new release of the product A support tool responsible for all activities associated to logging defects and usage

information, as well as interpreting these logs, is presented in a later section of this work

2.4 Performance testing in Mobile-D

Mobile platforms are usually limited in terms of physical resources compared to desktop environments, and the utilization of these resources has to be carefully taken

into consideration However, the well-known practices adopted by the Mobile-D

process do not account for the performance of components under development, either

at design time or during coding To address the issue, this section suggests the integration of performance testing activities in the lifecycle, more specifically extending the Test-Driven Development practice with performance aspects

A good starting point for this task is (Johnson, Ho, Maximilien, & Williams, 2007) The

authors describe the implementation of a new technique called Test-first performance

(TFP), to be used in conjunction with TDD There are some notable differences between classic TDD and TFP First of all, in TFP, performance scenarios are generated as unit test cases and, instead of using assertions like in regular JUnit test cases, measurements are taken in different parts of the test case to create performance statistics Another different feature of TFP is the designer of the test cases Here, a performance specialist with a clear understanding of user expectations and possible performance bottlenecks designs the test cases The authors’ approach to performance testing comprises three phases: test design, critical test suite execution and master test suite execution

The test design process includes three main activities: identifying performance areas, specifying performance objectives and specifying test cases Performance areas are discovered by analyzing the utilization of different resources in specific points in the software; for example, in the case of a layered architecture, a performance area worthy

of investigation is the elapsed time in a certain layer Of course, these areas are highly application-specific, their identification being a task reserved for domain specialists The next step in the test design process is specifying performance objectives, which may be sourced from architecture and performance experts, or from customer requirements and expectations on performance in certain areas Finally, test cases are specified according to these objectives

One key requirement for a project developed using TDD is to obtain rapid feedback on test results If, however, performance test designers decide stress testing (testing under heavy workload) is required, this means TDD principles are no longer respected, as stress testing requires a significant time to perform This is why, in TFP, test cases are split in two categories: critical test suite and master test suite The critical test suite represents a subset of all test cases generated during test design, while the master test suite is the entire set of performance test cases

In the practical application presented in (Johnson, Ho, Maximilien, & Williams, 2007), developers execute the critical test suite along with other (functional) tests, but only after the latter have passed The issue here is a pass/fail result for a performance test case is not indicated Instead, developers have to analyze the generated logs and find points of performance degradation (compared to previous runs) or other issues The successful outcome of this activity depends on the developers’ expertise For the master test suite, the authors define performance test cases for multiple runs, heavy workloads, multiple devices and multiple platforms, testing the application’s scalability and behaviour under different environments Due to the long running times associated

to these types of tests, they are run by the performance architect in parallel with developers and as soon as the required functionality is implemented Any performance issues found by the performance architect are communicated to the developers

The use of TFP during development has some notable benefits, most of them stemming from the early identification and increased visibility of performance-critical areas and code paths in the system This raises the awareness on performance issues and prevents premature optimization Continuous performance tracking leads to an overall increase of performance over time, while early discovery of performance “leaks” leads

to a more efficient use of design and coding resources

The authors of TFP have also experimented with an evolutionary model for performance requirements, described in (Ho, Johnson, Williams, & Maximilien, 2006) The approach is a good fit with agile methodologies, requiring no complex performance analysis upfront, but rather allowing for an incremental specification of performance

requirements and test cases The Performance requirements evolution model (PREM)

uses levels to specify the amount of detail for performance requirements, as well as the form of validation required to satisfy performance requirements on a given level of detail In order to move the performance requirements to a higher level, more

influencing factors must be found It is also not recommended to jump to a certain level based on assumptions, as this might lead to a misuse of resources (over-engineering) Instead, the process of refining requirements should stop when the appropriate level for the project has been reached The evolution model is presented in Figure 10

Figure 10 Performance requirements evolution model; Source: (Ho, Johnson, Williams, &

multi-Using Test-first performance together with the Performance requirements evolution

model in the Mobile-D process should prove sufficient to successfully integrate

performance testing concepts in the methodology However, the previously presented activities cannot be included at a single point in the lifecycle, but rather in multiple

points located in different phases and stages First, a performance expert or

performance architect must be nominated within the development team This is to be

done in the first phase (Explore), during the Project establishment stage According to

specifications, this stage is concerned, in part, with defining and allocating technical and human resources needed for the project Figure 11 shows the sequence of tasks

during Project establishment, including the Personnel Allocation task used to nominate

the performance architect