Chapter 1 Review of Literature

Transcription

1 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

2 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 1 Mobile Requirements Potential interaction with other applications 2 Sensor handling 3 Native and hybrid applications 4 Families of hardware and software platforms 5 Security 6 User interfaces 7 Complexity of testing Description Pre-installed mobile software vs. other applications downloaded from various sources. 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. Applications installed directly on the mobile device vs. applications that invoke services over internet through a web browser. Mobile applications should be developed for various devices supporting different operating system versions. Mobile devices are 'open' allowing installation of malware application which may further lead potential attacks and threats. Mobile application development should follow user interface guidelines. It is challenging and complex to test mobile web applications due to additional problems related with transmission during gateways and the telephone network.

3 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 fastpaced 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).

4 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

5 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

6 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).

7 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

8 Small development teams Identifiable customer Object-oriented development environment Non-safety critical software Application level software front design and planning, need for incremental and iterative development approach. Small teams are able to react more rapidly, share information, less is documentation needed, etc. To avoid business misunderstanding. Most tools that support Agile mode of development exist for object oriented development platforms. Failures do not cause loss of lives. More agility can be pursued. Large embedded systems require extensive communication and verification mechanisms. 7 Small systems Less upfront design needed. 8 Short development cycles For the purposes of rapid feedback. each year. Majority of mobile software is developed in micro or SME companies, or development teams. Potentially unlimited number of end-users. Business customer easier to identify, e.g. distributor. E.g., Java and C++ used. Some problems in proper tooling e.g. for refactoring and test-first approach. Majority of existing mobile software is for entertainment purposes. Mobile terminals are not reliable. While mobile systems are complex and highly dependent, mobile applications can be stand-alone applications. Size of mobile applications varies, but generally they are less than lines of code. 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.

9 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 nonsequential 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.

10 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 1 Mobile D 2 RaPiD 7 3 Hybrid: ME 4 MASAM 5 Scrum 6 SLeSS Mobile Development Process Description An Agile Approach for Mobile Application Development Rapid Production of Documentation - 7 steps Designing an Agile Methodology for Mobile Software Development - A Hybrid Method Engineering Approach Development Process of Mobile Application SW Based on Agile Methodology Scrum to support mobile application development projects in just-in-time learning context A Scrum and Lean Six Sigma Integration Approach for the Development of Software Customization for Mobile Phones Authors Year Agile Non Agile Abrahamsson et al XP, Crystal Dooms et al AM - RUP Rahimian et al ASD NPD Jeong et al XP RUP, SPEM Scharff et al Scrum - Cunha et al 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

11 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). Explore Initialize Productionize Stabilize System Test and Fix 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).

12 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 postrelease 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

13 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 1 Project Layer 2 Case Layer 3 Workshop Layer Description Describes how human interaction and joint decisionmaking is planned for software projects. Describes how the selected cases such as documents are to be created in consecutive workshops. 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: Preparation Phase Kick Off Phase Idea Gathering Phase Analyzing Idea Phase Detailed Design Phase Decision Making Phase Closing Phase 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 timeframe. RaPiD7 approach

14 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 Design Implementation (Development Engine) Test Commercialization Detailed Analysis Creation of Functional Prototype Architectural Design Detailed Design Adaptive Cycle Planning Concurrent Component Engineering Updates to Component Library Quality Review Market Testing The ideal mobile software development characteristics that the hybrid engineering methodology is based on are: agility, market consciousness, software product line support, architecture-based

15 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, iterativeincremental 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

16 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 Task Work Product It defines a set of related skills, competencies and responsibilities of an individuals 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 It is a general term for task inputs and outputs. There are three types of work product Planner, Manager, UI designer, Developer, Development team, Initial development team, Tester, User Product Summary, Initial Planning, User Definition, Initial Analysis, Select Resource, Select Process, Establish Environment, Write Story Card, UI Design, Define Architecture, Planning, Iteration plan, Faceto-face Meeting, Incremental Design, TDD, Refactoring, Release Plan, Feedback, Pattern Manage, Pair Programming, Integration, Acceptance Test, User Test Figure 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 Concept Sharing Product summary Pre-planning User Definition Initial product analysis

17 Embodiment Phase Development Phase Commercialization Phase Project Set-up User Need Understanding Architecting Implementation and Preparation Release Cycle System Test Product Selling Development process coordination Project resource coordination Pre study Story card workshop UI design Non-functional requirement analysis Architecture definition Pattern management Environment setup Development Planning Release Planning Iteration Cycle Release Acceptance Test User Test 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.

18 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:

19 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

20 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.