Chapter 1 – Review of Literature

This chapter presents an overview of previous work on related literature and studies done by the

researchers that provide the necessary background for the purpose of this research.

The review of literature mainly emphasized on the mobile application development process,

Agile software development, existing mobile software development models using Agile

approaches and other software development products using Agile methods. It includes five

sections. First, the characteristics of mobile apps that makes it different from traditional

softwares. Second, real issues and challenges faced by developers while developing mobile apps.

Third, reasons why Agile software development practices are most suitable for the development

of mobile apps. Fourth, identifying existing models for mobile software development products

using Agile or combination of non-Agile techniques. Fifth, it also studies other software

development products using Agile methods and its combination. The standard sources used for

literature search included online journals and published literature.

2.1 CHARACTERISTICS OF MOBILE APPLICATIONS AND ITS COMPARISON TO TRADITIONAL

APPLICATIONS

As mobile platforms persist to progress in performance, users are expecting their mobile devices

to provide functionality similar to their desktop computer applications. However, the

development of mobile applications (mobile apps) is still considered to be complex and various

methodologies adopted towards the development of such technologies is inadequate.

Mobile application development is different from traditional software development. To develop a

great mobile application, it is crucial to understand the key features that define great mobile apps

and if practically applied, make them useful and valuable. The wide variety of tools and

platforms of mobile devices causes one to examine the unique characteristic of mobile

application development and evaluate the process of which new features and methods need to be

addressed while designing, coding, testing, deploying and maintaining mobile applications.

However, there is still lack of research initiatives and insufficient understanding of different

types, categories and characteristics of mobile applications. This exposes the mobile device to

prospective attacks which needs to be addressed promptly requiring newer research initiatives

and has motivated to undertake the present study.

The mobile app market is presently witnessing rapid growth, as mobile platforms continue to

proceed in performance with a rapid increase in users and demand for a wide variety of mobile

applications. The development of mobile application is the process in which the softwares are

developed for handheld portable devices, such as mobile phones and tablets. These are either

pre-installed software on mobile phones, or downloaded by the user from the app stores and

other mobile software distribution platforms. The mobile application development process is

considered to be very similar to traditional software engineering processes in many ways.

Following are few issues that are common to both traditional and mobile software development:

integration with device hardware, traditional issues of security, performance, reliability and

storage limitations. Although, mobile applications presents some additional requirements that are

less commonly found in traditional software applications (Abrahamson et al., 2002) as

summarized in Table 3.

Table 3: Additional requirements found in mobile softwares

Mobile Requirements Description

1 Potential interaction with other

applications

Pre-installed mobile software vs. other applications downloaded

from various sources.

2 Sensor handling

Smartphone's contains an accelerometer responding to device

movement, a touch screen responding to gestures, a GPS, a

microphone, voice calls, cameras, and multiple networking

protocols.

3 Native and hybrid applications

Applications installed directly on the mobile device vs.

applications that invoke services over internet through a web

browser.

4 Families of hardware and

software platforms

Mobile applications should be developed for various devices

supporting different operating system versions.

5 Security Mobile devices are 'open' allowing installation of malware

application which may further lead potential attacks and threats.

6 User interfaces Mobile application development should follow user interface

guidelines.

7 Complexity of testing

It is challenging and complex to test mobile web applications due

to additional problems related with transmission during gateways

and the telephone network.

8 Power consumption Mobile applications may unintentionally make extensive use of

battery-draining resources.

The ongoing demand and swift production of mobile devices have enforced software project

teams to adopt development practices that are suitable to the characteristics, capabilities and

requirements of mobile applications. The combination of computing power, sensor handling,

location sensor, user interface and security has made mobile devices a new computing platform

for software developers and businessmen. Therefore, the continued growth and development of

this new computing platform has demanded the need and necessity for software development

processes to be tailored to mobile application development.

As is evident from the requirements of mobile applications, the development settings and the

technologies that support mobile applications are unlike from conventional desktop environment.

As a result, the software developers face the challenge of frequent user requirement changes.

These frequent modifications and customer expectations make the systems more complex. As the

project gets complex, more effort in coordination and formalization in development process is

required. Hence, it is not desirable to simply apply and implement the traditional software

engineering practices to mobile software development projects without tailoring or

modifications. The Agile practices are considered to be appropriate with software’s for fast-

paced markets, where satisfaction of user is administered by frequent and continuous release of

working software, where the user requirements change anytime in the project, and where the

delivery cycle is short (e.g. every couple of weeks).

With the advancement of mobile computing and communication technologies, the continuous

requirement and demand of mobile applications has increased (Qing Pu, 2012). The divergent

hardware makers for mobile phone and tablet platforms have enforced mobile developers to

make a series of the same mobile app tailored and modified for each type of device and have

recommended software reuse in MAD as well. In addition, the key characteristics that define

successful mobile apps are functionality, reliability, flexibility, accessibility, portability,

efficiency, maintainability, usability and responsiveness, iterated in line with the user’s

requirements, and the quality characteristics specified in ISO 9126 (Dehlinger et al., 2011;

Gordon et al., 2013).

The ten customs through which a desktop websites differ from mobile sites on the basis of

content prioritization (includes the most crucial functions and features); vertical instead of

horizontal navigation; bars, tabs, and hypertext; text and graphics; contextual & global

navigation; footers; breadcrumbs; progress indicator; integration with phone functions; and

localized and personalized search (Shanshan Ma, 2011).

Mobile computing allows the user to create, access, process, store and communicate information

from multiple locations (Zimmerman, 1999).

Hardware: The mobile computing hardware characteristics includes Size and Form Factor,

Weight, Microprocessor, Primary Storage, Secondary Storage, Screen Size and Type, Means

of Input, Means of Output, Battery Life, Communications Capabilities, Expandability,

Durability of the device.

Software: The mobile computing software includes most common system software and

operating environments used on mobile devices such as, MSDOS, MS Windows, Windows

for Pen Computing, Windows CE, PenDOS, PenRight Palm OS, Psion EPOC32, and Unix.

Communication: The mobile computing device communicates with a fixed information

system in various ways, such as, Connected: When connection is established continuously at

a high speed to the fixed information system; Weekly Connected: When connection is

established continuously but at a slow speed (i.e. < 28 Kbps) to the fixed information system;

Batch: When connection is established randomly or periodically to the fixed information

systems; and Disconnected: When mobile device is unable to electronically interact and

exchange information, it is accomplished by manually entering into the fixed information

system.

Technologies: Common communication technologies includes, Wireless Local Area Networks

(WLANs), Satellite, Cellular Digital Packet Data (CDPD), Personal Communications Systems

(PCS), Global System for Mobile communications (GSM), RAM and ARDIS data networks,

Specialized Mobile Radio (SMR) service, one and two-way paging, plain old telephone system

(POTS), Internet, infra-red, docking (serial, parallel, LAN) and disk swapping. Table 4 depicts

the key characteristics and features that differentiates mobile version from conventional desktop

applications that can be grouped into three categories i.e. Hardware, Software and

Communication (Zimmerman, 1999).

Table 4: Characteristics of Mobile Computing

Hardware Software Communication

Size and Form Factor MSDOS Connected

Weight MS Windows Weekly Connected

Microprocessor Windows for Pen Computing Batch

Primary Storage Windows CE Disconnected

Secondary Storage PenDOS

Screen Size and Type PenRight Palm OS

Means of Input Psion EPOC32

Means of Output Unix

Battery Life

Communications Capabilities

Expandability

Durability of the device

Furthermore, the hardware, software, operating system and environment decides which

communication medium is suitable for a particular mobile application. The current advancements

in mobile applications, varied market and technological development have dramatically

benefited mobile developers. It has generated many new development opportunities and created

considerable revenues with the growing mobile application portals (Adrian Holzer, 2011).

2.2 ISSUES AND CHALLENGES FACED WHILE DEVELOPING A MOBILE APPLICATION

Traditional software engineering approach and methods used in development of desktop

applications may not be directly applicable to a mobile environment. Therefore, it is critical to

develop and implement suitable process for the development of mobile applications as there are a

number of key issues and challenges that are basically different from traditional enterprise

applications.

However, the development of mobile software’s is still unwieldy and a methodology geared

towards supporting the development of such mobile applications is still inadequate. There is still

lack in understanding of some real issues, challenges faced during the development of mobile

apps and best practices that can adopt to address those challenges. There are number of major

issues when looked at the end-to-end process of developing a mobile application, from business

discovery and development to support and marketing. Only few studies have identified and

published the fundamental challenges in mobile computing till date.

Leigh Williamson (2012), listed the unique challenges for mobile application development, such

as form factors and user input technology, usability and user interaction design, choice of

implementation technology for native, web and hybrid mobile app implementation.

Wasserman et. al. (2010) identified issues related to mobile application development based upon

development processes, tools, designing user interface, portability of applications, quality and

security.

Dehlinger et al. (2011) identified four main challenges observed in mobile software development

project particularly, when building universal user interfaces, when reusing software across

various mobile platforms, when scheming context aware mobile apps and while stabilizing

agility and ambiguity in the requirements. However, it should be noted that traditional software

development process may not be directly implemented to mobile device softwares that includes

user interface, divergent mobile platforms (platforms, hardware) and novelty of a truly mobile

computing platform.

Dye et al. (2013) discussed various security challenges due to the abundance of mobile software

applications in recent years and conversed about the potential risks that the mobile devices are

exposed to due to the lack of software development principles and best practices. Based on the

review of literature the above mentioned issues may pose following challenges:

Creating universal User Interfaces: screen size and resolution

Designing context-aware mobile applications: managing the complication of providing

applications across various mobile platforms; requirements upfront essential, fixed notion of

context where the changes are nothing, small or expected.

Enabling software reuse across mobile platforms: Designing context-aware aware

applications (OS platforms, hardware makers, delivery methods, computing platforms).

Balancing agility and uncertainty in requirements: Specifying requirements uncertainty

These issues are imperative and should be considered during early development process in order

to mitigate the impact of poor choices for the successful development of mobile applications.

However, very few reports have investigated and highlighted the best practices implicated in the

process of mobile application development projects. The large and complex software

development projects have adopted Agile development practices, such as Scrum, test driven

development and moving away from process intensive approach. (Wasserman et al., 2010;

Schwaber et al., 2004).

2.3 WHY AGILE SOFTWARE DEVELOPMENT IS MOST SUITABLE FOR MOBILE APPLICATION

DEVELOPMENT

The mobile telecom industry consists of extremely complex, competitive and uncertain

environment. The Agile software development techniques seems to be a natural fit for mobile

application development process (Morris et al., 2010; Holler et al., 2011; Kannan et al., 2011;

Murphy et al., 2011; Habermas et al., 2013).

The research studies conducted in the area suggests the necessity for software development

processes to be tailored and modified to suite the requirements of mobile softwares. The Agile

methodologies have shown to adhere for the mobile software development process successfully

as Agile innovations may offer a variety of solutions for mobile application and assist service

developers in need of high quality development processes (Abrahamsson et al., 2004; Rahimian

et al., 2007; Jeong et al., 2008; Scharff et al., 2010; Thiago et al., 2011).

Table 5 below summarizes the mapping of Agile themes to various traits seen in development of

mobile application and reasons why Agile fits mobile software development (Abrahamsson et

al., 2004):

Table 5: Mapping of Agile themes to traits observed in MAD

Ideal Agile

Characteristic Rationale Mobile Software

1 High environment

volatility

Due to high change of

requirements, less need for up-

High uncertainty, dynamic environment:

Hundreds of new mobile phones published

front design and planning, need for

incremental and iterative

development approach.

each year.

2 Small development

teams

Small teams are able to react more

rapidly, share information, less is

documentation needed, etc.

Majority of mobile software is developed

in micro or SME companies, or

development teams.

3 Identifiable

customer

To avoid business

misunderstanding.

Potentially unlimited number of end-users.

Business customer easier to identify, e.g.

distributor.

4

Object-oriented

development

environment

Most tools that support Agile mode

of development exist for object

oriented development platforms.

E.g., Java and C++ used. Some problems

in proper tooling e.g. for refactoring and

test-first approach.

5 Non-safety critical

software

Failures do not cause loss of lives.

More agility can be pursued.

Majority of existing mobile software is for

entertainment purposes. Mobile terminals

are not reliable.

6 Application level

software

Large embedded systems require

extensive communication and

verification mechanisms.

While mobile systems are complex and

highly dependent, mobile applications can

be stand-alone applications.

7 Small systems Less upfront design needed.

Size of mobile applications varies, but

generally they are less than 10000 lines of

code.

8 Short development

cycles For the purposes of rapid feedback.

Development cycles vary. Generally

mobile applications and services can be

developed within 1-6 month time frame.

These traits includes high environment volatility, small development teams, identifiable

customer, object-oriented development environment, non-safety critical software, application

level software, small systems and short development cycles.

Kannan et al. (2011) has also highlighted the suitability of Agile software development in mobile

application development because of small teams, short deadlines, importance of usability, fast

delivery and less complexity. The authors have suggested seven methods in which Agile

development practices enhance the development of mobile apps that includes experimentation

and adaption nature of mobile apps; reliability that leads to continued use of apps; extension of

Agile sprints into mobile app model, responsiveness to technology changes; rapidly

accommodating customer feedback; a more thoughtful user experience; and phased roll out of

feature sets.

Holler et al. (2011) suggested that Agile software development offers tremendous opportunities

and value, for mobile development teams working into introducing a lightweight development

process or scale back bureaucratic processes. The authors has emphasized about the progress in

mobile computer technology and the rapid escalation of wireless networks in quality and

quantity that has brought in new applications and concerns in this dynamic environment. They

also underlined the promptness with which the industry needs to adapt and change itself from

conventional systems development techniques fulfilling the special needs of this field.

In contrast, Agile methodologies have also been criticized in its ineffectiveness when used in

large organizations and certain types of projects where it has been enlisted as an area that needs

further research. It has been suggested that Agile methods seem best for developmental and non-

sequential projects and many organizations believe that the methodology is too extreme.

J.B. Barlow (2011) suggested that these organizations should prefer adopting a hybrid approach

that mixes elements of Agile and plan-driven approaches to fulfil their needs. Moreover, they

suggested that Agile methods seem more suitable for developmental and non-sequential projects

and many organizations believed that Agile methodologies were too extreme. It was suggested

that Agile development was found to be less reliable and suitable for certain types of

environment and teams that include small number of experts (Boehm et al., 2003; Beck et al.,

2002).

Agile Methodologies has also been assessed by numerous observers as being a “management

fad” and claims of a measurable business improvement via measurement of metrics defined by it,

for example, velocity. The technology has its limitations in distributed development efforts,

using an Agile Software Process with Offshore Development, and mission-critical systems where

failure is not an option at any cost, for example, software for air traffic control (Fowler, 2010).

The technology has also been criticized for various other reasons that includes lack of structure

and necessary documentation, works with senior-level developers, incorporates insufficient

software design, requires too much cultural change to adopt, can lead to more difficult

contractual negotiations, feature driven, non-functional quality attributes are hard to be placed as

user stories.

Corral et al. (2013) presented a survey depicting lack of evidence that shows a clear link between

the proposed Agile methodologies and their utilization in a real-world setting, instantiating a

trend mentioned in a previous analysis conducted by Janes et al. (2012) that reflects an identified

decline on considering Agile practices as a silver bullet.

2.4 AGILE AND NON AGILE TECHNIQUES FOR MOBILE APPLICATION DEVELOPMENT

The following approaches have been proposed by researchers for the development of mobile

applications using combination of various Agile and Non Agile techniques. These are discussed

in detail below (Table 6):

Table 6: Existing MAD processes using Agile and non-Agile approach

Mobile

Process

Mobile Development Process

Description Authors Year Agile Non Agile

1 Mobile D An Agile Approach for Mobile

Application Development

Abrahamsson

et al. 2004

XP,

Crystal RUP

2 RaPiD 7 Rapid Production of

Documentation - 7 steps Dooms et al. 2005 AM -

3 Hybrid: ME

Designing an Agile

Methodology for Mobile

Software Development - A

Hybrid Method Engineering

Approach

Rahimian et al. 2008 ASD NPD

4 MASAM

Development Process of Mobile

Application SW Based on Agile

Methodology

Jeong et al. 2008 XP RUP, SPEM

5 Scrum

Scrum to support mobile

application development projects

in just-in-time learning context

Scharff et al. 2010 Scrum -

6 SLeSS

A Scrum and Lean Six Sigma

Integration Approach for the

Development of Software

Customization for Mobile

Phones

Cunha et al. 2011 Scrum Lean Six

Sigma

1) Mobile-D

One of the pioneering studies in the area of Agile methodologies has been conducted by

Abrahamsson et al. (2004). The authors suggested that Agile development solution provides a

good fit for mobile application development environment and proposed a new approach called

Mobile D. The study provides an overview on to the mobile application development that makes

it challenging and how these special characteristics and limitations affect mobile software

development process. The study also introduced a software development approach drawn from

the field of Agile software engineering, designed to meet the specific demands of extremely

volatile mobile environment. In addition, the authors also introduced a new concept called

“Architecture Line” that aims producing an application framework, which guides the

development of future mobile applications.

Mobile-D approach is based on Rational Unified Process RUP (life-cycle coverage), extreme

Programming XP (development practices) and Crystal methodologies (scalability). Briefly the

methodology of Mobile-D comprises of five phases, each of which has a number of associated

stages, tasks and practices: Explore, Initialize, Productionize, Stabilize, System Test and Fix

(Figure 2).

Figure 2: Phases of Mobile-D Software Development Process

The software development project that follows Mobile-D approach is divided into five iterations.

These phases are set-up, core, core2, stabilize and wrap-up. Each of these phases consists of

three different types of development days: Planning, Working and Release Day. The Mobile-D is

organized into a framework that conjoins the main processes (plan, design, implement, test,

release) with the support processes (project management, software configuration management,

software process improvement).

The nine principal elements of Mobile-D are Off-Site Customer (Requirements), Phasing and

placing in Planning Day (Planning), Agile Modeling (Modeling), Architecture Line

(Architecture), Time, size and defect (Metrics), RaPiD7-method (Documentation), Agile

Software Process Improvement (Improvement), User-Centred Focus End-users), and Mobile

Test-First development (Testing).

Explore Initialize Productionize Stabilize System Test

and Fix

The Mobile-D approach has been empirically tested in development projects and has been

successfully assessed against the CMMI level II certification. It is recommended to use Mobile-

D by a small co-located team of at most ten co-located developers, working in a short

development cycle towards a product delivery within 8 to 10 weeks of calendar time. Although

this methodology being a pioneering study in the field seems very promising and plays an

important role in theory, it is important to mention that this approach is cursory and not

completely defined in order to be literally used in practice. It has also been suggested that the

model could further be improved using hybrid Agile techniques.

Spataru et al. (2010) evaluated the suitability of Agile methods for mobile application

development projects, bringing a set of improvements to an established Agile via Mobile-D

methodology, and providing tool support to enable these improvements, facilitating performance

testing, usage logging and automatic test case generation. The authors found importance of post-

release that was not provided by Mobile-D and addressed the issue by extending the

methodology in terms of lifecycle coverage, and by adding a newly evolved phase that deals with

continuously integrating end-user feedback on the delivered product into future releases.

However, the improvements brought to Mobile-D as proposed by the different authors should

undergo experimental validation in a real organization. Such an experiment would require

extensive work to be performed in collaboration with development teams working with different

methodologies, and analysing if the envisaged benefits of the improvements described are met

when applied on real projects.

2) RaPiD7

Dooms et al. (2005) has proposed a method called ‘RaPiD7’ (rapid production of

documentation, 7 steps) that improves the documentation work without scarifying the quantity

and quality of documentation. RaPiD7 describes how human interaction is planned in software

projects leading to the creation of documents in facilitated workshops.

The survey data RaPiD7 is presented to expedite the planning process, quality improvement in

results and to facilitate proficient sharing of information. It is based on Agile philosophy

whereas it’s more focused on the authoring documentation rather than in actual mobile software

development projects.

Metrics from a case study show how RaPiD7 has reduced significantly the number of fatal

findings in inspections and provides a method that amends the planning activities in software

engineering and the experiences show evidence of the improvements (Dooms et al., 2005).

RaPiD7 provides a three-level structure namely, Project Layer, Case Layer and Workshop

Layer as described in Table 7 below:

Table 7: Three layer structure of RaPiD7

Layers Description

1 Project Layer Describes how human interaction and joint decision-

making is planned for software projects.

2 Case Layer Describes how the selected cases such as documents

are to be created in consecutive workshops.

3 Workshop Layer Describes how the actual work is carried out in form

of facilitated workshop, using seven steps of method.

The workshops are planned in detail in following phase order:

Figure 3: Seven steps of RaPiD7 Workshop Layer

RaPiD7 supports all software development projects, whether related or unrelated to mobile

application development. This method has been experimentally tested at Philips Digital Systems

Laboratory and it was developed within Nokia in the 2002-2003 timeframe. RaPiD7 approach

Closing Phase

Decision Making Phase

Detailed Design Phase

Analyzing Idea Phase

Idea Gathering Phase

Kick Off Phase

Preparation Phase

embraces two very Agile practices, “Whole Team” and “Do the Simplest Thing That Will

Work”. RaPiD7 improves the traditional approach for specification work by offering a way to

plan the human interaction in the early phases of software projects and by providing means to

make decisions and to document authoring jointly with a built-in quality assurance.

3) Hybrid Methodology Design

Rahimian et al. (2007) presented a different approach to the Mobile-D methodology. The authors

proposed a hybrid Agile and risk-based methodology that generates a method suitable for mobile

application development. This process was designed from Methodology Engineering techniques

which is a discipline concerned with creating methodologies suitable for different development

scenarios, motivated by the belief that no single process fits all situations. It is based on a

combination between Agile methodologies, Adaptive Software Development (ASD) and New

Product Development (NPD).

Table 8 below describes in detail about various phases of hybrid engineering methodology.

Table 8: Phases of Hybrid Engineering Methodology

Hybrid Engineering Methodology Phases

Idea Generation

Project Initiation Preliminary Analysis

Analysis Detailed Analysis

Creation of Functional Prototype

Design Architectural Design

Detailed Design

Implementation

(Development Engine)

Adaptive Cycle Planning

Concurrent Component Engineering

Updates to Component Library

Test Quality Review

Market Testing

Commercialization

The ideal mobile software development characteristics that the hybrid engineering methodology

is based on are: agility, market consciousness, software product line support, architecture-based

development, support for reusability, inclusion of review and learning sessions, and early

specification of physical architecture.

The Hybrid Methodology Design process has been developed as a top-down, iterative-

incremental process comprised of 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. Briefly, the proposed mobile development

methodology was created in four iterations, starting from a generic software development

lifecycle.

In the first iteration, the methodology was detailed by adding practices commonly found in Agile

methods. Taking into account market considerations, the second iteration included 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 fourth and final iteration, prototyping was added to

mitigate likely technology-related risks. The hybrid method engineering 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. The published material on Hybrid Engineering Methodology does not include any case

study or shows that the methodology has been empirically tested on developing an actual mobile

software product.

4) MASAM

Jeong et al. (2008) proposed the Mobile Application Software Agile Methodology (MASAM)

that provides the process for developing the mobile applications swiftly using an Agile approach.

It is based on Extreme Programming (XP), Agile Unified Process, RUP and the Software and

Systems Process Engineering Meta-model (SPEM). It is GUI based architecture-cantered that

uses Agile approaches for rapid development and utilizes domain knowledge. MASAM shows a

strong tie with the Mobile-D methodology and introduces slight variations, such as a project

management and follow up tool coupled with Eclipse Process Framework. MASAM is described

according to Software and Systems Process Engineering Meta-model (SPEM) and defines

following three kinds of process assets: role, task and work product as explained in Table 9:

Table 9: Process Assets of MASAM

Kind Description Name

Role

It defines a set of related skills,

competencies and

responsibilities of an individuals

Planner, Manager, UI designer, Developer,

Development team, Initial development team, Tester,

User

Task

It is an assignable unit of work

assigned to a specific role. The

granularity of a task is generally

a few hours to a few days and

usually affects one or only a

small number of work product

Product Summary, Initial Planning, User Definition,

Initial Analysis, Select Resource, Select Process,

Establish Environment, Write Story Card, UI Design,

Define Architecture, Planning, Iteration plan, Face-

to-face Meeting, Incremental Design, TDD,

Refactoring, Release Plan, Feedback, Pattern

Manage, Pair Programming, Integration, Acceptance

Test, User Test Figure

Work

Product

It is a general term for task

inputs and outputs. There are

three types of work product

Product Summary, Project Planner, UI Sample, UI

Model, UI pattern, Architecture Pattern, Application

Pattern, Story Card, Task Card, Architecture Model,

Component Model, Test Case

MASAM proposes a mobile application development cycle comprised of four phases: the

Preparation Phase defines summary and first notion of the product, assigns roles and

responsibilities, the Embodiment Phase focuses on understanding user’s needs and defining the

architecture of the software product, the Product Developing Phase, that benefits from traditional

Agile principles to furnish an iterative Extreme Programming development sequence. The

implementation of the software product is carried out through TDD, Pair Programming,

Refactoring and Continuous Integration, with a close relationship with iterative testing activities,

and finally, the Commercialization Phase concentrates on product launching and product selling

activities (Table 10):

Table 10: Phases of MASAM process

Phase Activity Task

Preparation

Phase

Grasping Product Product summary

Pre-planning

Product Concept

Sharing

User Definition

Initial product analysis

Project Set-up

Development process coordination

Project resource coordination

Pre study

Embodiment

Phase

User Need

Understanding

Story card workshop

UI design

Architecting

Non-functional requirement analysis

Architecture definition

Pattern management

Development

Phase

Implementation and

Preparation

Environment setup

Development Planning

Release Cycle

Release Planning

Iteration Cycle

Release

Commercialization

Phase

System Test Acceptance Test

User Test

Product Selling Launching Test

Product Launching

It is recommended to use the MASAM methodology for small companies that are focused on the

development of mobile software applications. However the, authors have not presented a case

study of an actual implementation of this methodology in a real-world environment.

5) SLeSS

Cunha et al. (2011) proposed SLeSS; an Agile approach integrates Scrum and Lean Six Sigma

(LSS) that focuses on project management and process improvement respectively. The approach

uses two types of product backlogs, Customization Product Backlog (for customizing

development projects) and LSS Product Backlog (for process improvements).

The use of SLeSS assists in the easy adaptation to requirement changes in the later stages of the

project and with less overall impact than the traditional approach, helps in meeting deadlines,

reduces overtime hours, and delivers more rapidly versions and shortening the development

cycle. Besides this, the approach enables the achievement of performance and quality targets of

real software development project, increases productivity, improves process quality, helps in cost

reduction, progressively improves the development process, management process and the

outcome of projects with fewer defects and failures.

Scrum is an Agile methodology for project management and software development that adopts

an empirical approach rather than prescriptive one and therefore it may be used in complex

projects. On the other hand, Lean Six Sigma (LSS) is a methodology for defining and improving

products, processes and services with a focus on reduction of defects and failures, on variation

and waste elimination, prioritizing, in a planned and objective way, the achievement of quality

and financial results. A six sigma level represents a process with 3.4 defects per million

opportunities (DPMO).

a. Scrum in SLeSS

Scrum is widely used in software development, and it has been used and documented in the

scope of mobile software development (Cunha et al., 2011). The execution of SLeSS assumes an

incremental approach by first implementing the Scrum alone and once the Scrum is well settled

in the organization, LSS should be implemented as a quality framework. Initially, training team

was chosen in the Deployment phase, aiming that the customization development would not

suffer time and quality deviations which followed simulation of a real customization

development in the team that was already using Scrum. Later, Scrum was introduced to relative

experienced team, with well-defined scope, activities and known risks.

The recommendations for Scrum in SLeSS are:

a) Sprint Size: It should be one or two weeks.

b) Team Size: There should be four to nine people in a team.

c) Sprint Backlogs: It contains customized activities and process improvement. The

development team and client identify the problems or issues in Sprint which are prioritized

and resolved by the team members on regular basis.

d) Lean Six Sigma (LSS): It is important for Scrum Master and Product Owner to have proper

understanding of LSS techniques, the development and management processes.

b. Lean Six Sigma in SLeSS

Once Scrum is well settled in the organization, Lean Six Sigma (LSS) is applied as a quality

framework that complements Scrum as a development methodology. Table 11 shows that the

model is represented by the five phases:

Table 11: DMAIC 5 Phases of SLeSS approach

5 Phase (DMAIC) Following backlog items run in Sprints in each phase

1 Definition Phase Project Contract

Initial Analysis

2 Measurement Phase SIPOC Diagram (Supplier, Inputs, Process, Outputs, Customers)

Process Map

Cause and Effect Diagram

Cause and Effect Matrix

Impact Effort Matrix

Initial Capability

Measurement and Inspection Systems

3 Analysis Phase FTA (Fault Tree Analysis)

Analysis of critical inputs of the processes

4 Improvement Phase Action Plan

SIPOC (Supplier, Inputs, Process, Outputs, Customers)

Process Map

Final capability of the processes

5 Control Phase Control Plan

The SLeSS approach has been used in real embedded software customization development

projects for mobile phones. The approach was experimented in research, development and

innovation (R&D&I) laboratory, with a mobile phone manufacturer as a client with team of 7-12

developers, in duration from 4-6 months, with average size of 529 LOC (Line of Code)

developed in ANSI C programming language. The practice of SLeSS facilitates in obtaining

higher outcomes, such as better adaptation to changes requirements, the fulfilment of the

deadlines, the decrease in number of unplanned overtime, delivering more rapidly versions and

with fewer defects or failures. It demonstrated increase in productivity, improvement in process

quality and reduction in cost. Besides this, the approach has allowed the improvement in

development and management processes, initiating their statistical control and aligning them to

meeting the customer goals and expectations.

6) Scrum

Scharff et al. (2010) studied the use of Scrum in a class setting at pace University for developing

mobile apps and proposed a new model of working with Scrum that involved a product owner

and certified Scrum Master from industry. The mobile application that was developed to study

the emergent mobile market in Africa and the overall experience of implementing Scrum and its

appropriateness in mobile development in detail.

2.5 AGILE PRACTICES FOR THE DEVELOPMENT OF OTHER SOFTWARES

As per literature review, following are the Agile methods that are popularly used for the

development of other softwares by mobile industry and can be used for MAD:

Extreme Programming: Although Scrum is the most popular and largely practiced Agile method

as it uses project management framework but it has limited principles for engineering discipline

imperative to produce high quality products. XP provides twelve practices and other values that

can reenergize team and help guarantee high quality software. It is interesting to note mixing

practices from Scrum and XP hybrid has shown significant results in software development

projects, specifically for mobile devices and embedded systems (Abrahamsson et al., 2004;

Mushtaq et al., 2012; Qureshi et al., 2012).

Scrum: Scrum is focused on project management and this methodology has natural advantages in

development of mobile applications based on having a disciplined and limited scope, high end

user interaction, and a condensed time-to-market. Mobile companies and independent developers

are adopting a Scrum-like process for mobile application development (Wasserman et al., 2010;

Alyani et al., 2011; Su et al., 2011).

Lean Software Development: Development governance is a part of the overall IT and systems

engineering governance picture and has an important role. By streamlining the flow of work

performed by the team, a Lean approach to governance can significantly help in improving the

value provided by development projects. Lean contributes to the identification of flaws and their

causes and to increasing team participation in the project improvements (Six Sigma), regardless

of whether the members of this team are experts on statistical analysis. Scrum, combined with

Lean Six Sigma, may be extremely powerful for application development, mainly because Scrum

has a strong alignment to Lean principles (Poppendieck et al., 2005). It is noteworthy that no

studies are published till date addressing Scrum, XP and Lean integration at on software

development for mobile phones.