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

Agile Development Methods for Mobile Applications Andrei Cristian Spataru Master of Science Computer Science School of Informatics University of Edinburgh 2010 Abstract This thesis is aimed at evaluating the suitability of agile methods for mobile application development projects, bringing a set of improvements to an established agile method called Mobile-D, and providing tool support to enable these improvements, facilitating performance testing and usage logging in the lifecycle The motivation for this work is to better understand mobile development, and to improve related activities through research in the field and development of a support tool After establishing agile methods as a good approach towards mobile application development, a number of improvements to the Mobile-D method are presented, including a study in mobile application categories, related paradigms, end-user inclusion in the lifecycle, as well as performance testing of components and adoption of software product line principles The support tool enabling some of these improvements is then presented, with functionalities including performance testing for Android components, usage logging and automatic test case generation These contributions intend to bring Mobile-D closer to an ideal mobile application development methodology, while providing useful features that can be outside the process, either in the form of practices or tools i Acknowledgements I would like to thank my supervisor, Mr Stuart Anderson, for all the insightful ideas, suggestions and feedback I’ve received throughout my work I would also like to thank the “Dinu Patriciu” Foundation for funding my studies; I am grateful for the opportunity they have given me Special thanks to Panos Tsogas and to Marinos Argyrou who kindly provided his Android application for me to experiment with Finally, I would like to thank my parents for their full support during my studies ii Declaration I declare that this thesis was composed by myself, that the work contained herein is my own except where explicitly stated otherwise in the text, and that this work has not been submitted for any other degree or professional qualification except as specified (Andrei Cristian Spataru) iii Table of Contents Introduction 1.1 Mobile application development 1.2 Agile development for mobile applications 1.3 Mobile-D overview 1.4 Improvement approaches Improvements to Mobile-D 2.1 Categories of mobile applications 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 Android Resource Management 32 3.1 System description 32 3.1.1 Evaluate method performance 35 3.1.2 Evaluate method sequence performance 37 3.1.3 Evaluate test performance 39 3.1.4 Log user actions 41 3.1.5 Analyze usage logs 45 3.1.6 Generate tests from logs 46 3.1.7 System utilization 50 3.2 Impact on Mobile-D 50 iv 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 Bibliography 56 v List of Figures Figure Mobile-D phases and stages; Source: (VTT Electronics, 2006) Figure Proposed categories of mobile applications, based on (Oinas-Kukkonen & Kurkela, 2003), (Unhelkar & Murugesan, 2010) and (Kunz & Black, 1999) 11 Figure Scope definition stage, adapted from (VTT Electronics, 2006) 12 Figure Mobile development method proposed in (Rahimian & Ramsin, 2008) 15 Figure Main elements of stakeholder identification; Source: (Sharp, Finkelstein, & Galal, 1999) 19 Figure Stakeholder establishment stage, adapted from (VTT Electronics, 2006) 20 Figure End-user establishment steps 21 Figure Initial requirements collection steps; Source: (VTT Electronics, 2006) 21 Figure 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 runs of the MultiRes application 44 Figure 25 Log file statistics view 45 Figure 26 Logs and serialized objects 46 Figure 27 Test case generation wizard 47 vi Figure 28 Code created by test case generation wizard 48 Figure 29 Test result interpretation for generated test cases 49 vii List of Tables Table Methods for performance evaluation 37 Table Methods available for test performance evaluation 41 viii Chapter 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 reference to the actual object, serialized and saved to storage medium) When uploading usage logs these object files are also sent to enable test case generation 3.1.5 Analyze usage logs The support tool includes an Eclipse view to facilitate log analysis The user may select multiple logs and run a counter to obtain event numbers for each type of event; for errors, an option is available to show errors details such as parameters in the method that caused them Figure 25 displays the Eclipse view responsible for this task Figure 25 Log file statistics view This functionality is useful both when analyzing component utilization and for viewing contents of parameter objects generated by errors and received from users As can be seen in the above image, the showPhoto method caused an error when being called with parameter equal to The set of statistics can be extended to include more complex ones, such as time and error distribution statistics 45 3.1.6 Generate tests from logs The final functionality of the support tool described here is test case generation, the purpose of which being to recreate an error encountered by the end-user In order to accomplish this, the support tool takes a usage log and associated serialized objects and uses the Java Reflection API to attempt to bring the application under test to the same execution point that was logged as an error When considering the usage logging lifecycle shown in Figure 22, one can see that most activities are covered by the support tool The ones that are not covered are either too high-level to be automated (fix defects found by test cases, re-design components), or organization-specific (the upload procedure for logs and associated files) This section describes the use of logs and serialized objects uploaded to the development team from end-users’ devices As shown in Figure 23, when an error is logged, the logger requires parameters of the method in which the error occurred These parameters are then serialized and saved to the device’s external medium, to be then sent along with the log file, when the maximum number of runs has been reached When developers receive the logs and serialized object files, they can generate test cases that aim to obtain the same behaviour and then move on to correct it Figure 26 Logs and serialized objects The approach is able to generate a test case that brings the application to the same execution point described in the log, when the error itself is caused by a parameter in the method call Of course, an error can come from other sources, such as class variables or external input However, by using this approach, if the generated test case 46 cannot cause the application to reach the logged execution point, the cause can be narrowed down to other factors Also, the logger can only use serializable objects to log as parameters; fortunately, most Java classes are serializable The downside is that a significant number of Android classes are not, this functionality being replaced by the Android Parcelable interface If parameters are not serializable, developers have the option to log an error with no parameters; this will still provide some information about error occurrence, even though test case generation will no longer be possible The final option available to developers in order to get an idea of an error that occurred is to log the exception instead of the parameters, using the same logging mechanism As all exceptions are serializable and contain stack traces, instead of logging and serializing parameter objects, an exception object can be serialized and sent to developers, to be analyzed at a later time In order to facilitate test case generation from log files, a wizard is provided as part of the support tool, presented in Figure 27 Figure 27 Test case generation wizard 47 The wizard requires a log file to generate a test case The resulted test case is shown in the next figure A test case was generated for each error in the log Figure 28 Code created by test case generation wizard To successfully run a generated test case on the Android device or emulator, the necessary files have to be uploaded to its’ external storage mediums’ root directory, an action facilitated by the wizard (Figure 27) When a log file is loaded, users can specify the name of the external medium their current device is using, and the wizard will upload the log file and all necessary serialized object files to the root directory of that medium In point A (Figure 28) the log file is loaded from the root directory Then, in point B, method traces are obtained for those methods that caused errors This step 48 also includes loading the required serialized objects Then, a test method is generated for each error in the loaded log file (point G), and attributed a method trace (point C) Using the Java Reflection API the method that caused the respective error is reflected and invoked using the obtained method trace (points D and E) The test case fails if method reflection or invocation fails or if the method throws an exception when invoked, and passes if the method has been successfully invoked with the retrieved parameters After successfully reaching the execution point that was logged as an error, it is up to developers to analyze the causes of this behaviour If the test passes and the logged execution point is not reached, it is an indication that method parameters were not the cause of the behaviour, and other sources must be investigated Figure 29 shows an interpretation of test results Figure 29 Test result interpretation for generated test cases In the current example, running the generated test case results in an Android log entry (see Figure 23, point H), meaning the behaviour encountered by the user was successfully recreated by the test case (the method was driven to throw an exception by calling it with parameter “3”) 49 3.1.7 System utilization The support tool is distributed as three JAR files, available for download from the project’s website1 One is the Eclipse plug-in; the second contains the necessary libraries, while the third comprises only the logger library, to be distributed alongside Android applications Physical resource testing tasks are available for Activity classes (for methods and method sequences); timed test cases can be performed on any type of Android test case (including service and content provider test cases); logging tasks can be performed on any type of class In fact, the logger, analyzer and test case generator can be used for any Java application, after minor modifications to the logger The support tool was designed for Eclipse 3.5 (Galileo), Android 1.6, and requires JUnit libraries, as well as the Android Development Tools (ADT) plug-in for Eclipse The support tool was also tested on an Android application that was part of a student’s Masters Project The behaviour was as expected; selected methods were tested for performance, while an Android device was used to create logs, which were then pulled off the device and analyzed Test cases were successfully generated from these logs 3.2 Impact on Mobile-D The support tool influences two aspects of the Mobile-D methodology More specifically, it enables performance testing activities and the introduction of end-users into the development lifecycle, both aspects being discussed in previous chapters For performance testing, the support tool can be used in Working days, as shown in Figure 12 An established performance evaluation tool for Android is Trace View, a profiler provided with the standard distribution By using Trace View combined with Android Resource Management performance evaluation, a complete set-up is obtained; a typical sequence of events for effective testing would include the following steps: Ensure tested component passes functional tests Use the Trace View profiler to identify performance bottlenecks Use the support tool to evaluate the performance in those problem areas Refactor problem areas to improve performance; improvements are verified using the support tool http://armeclipse.webs.com/ 50 The logging functionality of the support tool is a perfect fit with end-user integration at post-release time, as shown in Figure The new Evolve phase in the process is centred on the usage log lifecycle presented in Figure 22 Thus, in the Data analysis and System test stages attached to this phase, usage logs received from users are analyzed, and then test cases are generated to identify and fix these errors in the later Planning and Working days Finally, a new release is created (Release day stage) 51 Chapter Conclusions and further work This section provides a discussion of overall project goals and the extent to which these goals have been fulfilled We will first examine the contributions this work has brought, and then discuss how these contributions improve mobile application development; finally, directions for further work will be described 4.1 Overview of improvements The current project has attempted to improve mobile development best practice by considering a popular and mature development methodology, Mobile-D, and improving it using ideas based on relevant literature This was done after analyzing the soundness of the fundamental principles of the methodology, and the way these principles fit with mobile development projects The final major improvement approach was the development of a support tool for mobile developers, which tries to fill a gap in current tool support, as well as sustain the proposed improvements to the methodology The first chapter, along with the results of the questionnaire presented in Chapter 2, have consolidated the belief that agile methods are usually the best alternative for mobile developers Chapter focuses on improvements to Mobile-D, in an attempt to bring the methodology closer to the list of ideal traits adapted from (Rahimian & Ramsin, 2008) and presented in Section 1.4 The first improvement was the addition of a classification task to the lifecycle (Section 2.1), and a classification tree was introduced to be used as is, or extended according to organization specifics By performing this new classification task, developers can expect to benefit from a set of guidelines tailored to the specific application type they are currently developing, as well as using previous experiences from projects in the same category In Section 2.2, alternative approaches for mobile development were explored, in an attempt to integrate new concepts with Mobile-D However, approaches from literature were generally too high-level to integrate with the detailed methodology; for enterprise 52 mobile applications a useful approach would be considering the framework described in (Unhelkar & Murugesan, 2010) Section 2.3 discusses bringing end-users into the development lifecycle, a major improvement to the Mobile-D process This is to be done in two different points: at design time, and after the first product release For the first integration point, a new task, End-user establishment, has been described, including user group identification and requirement source identification activities For postrelease integration, Mobile-D has been extended to include a new phase called Evolve This phase is concerned with improving the product through constant end-user feedback, an operation enabled by component usage reporting and error logging The second major improvement is introducing performance testing in the lifecycle, as described in Section 2.4 First, performance tests are designed using Test-first performance (TFP) (Johnson, Ho, Maximilien, & Williams, 2007), and the Performance requirements evolution model (PREM) (Ho, Johnson, Williams, & Maximilien, 2006) Then, in order to integrate running these tests, a new task (Performance testing) was described and integrated into the process The final section of the chapter deals with software product line principles and their applicability to the methodology (Section 2.5) The section provides an argument towards using the product line principle of “developing with reuse in mind” in mobile development Chapter describes Android Resource Management, a support tool developed as an Eclipse plug-in The main functionalities of the tool are performance testing of Android activity methods, timing Android tests, and supporting a usage logging lifecycle The support tool fulfils two goals: filling a gap in currently available support tools for performance testing and logging, and enabling major improvements to Mobile-D, such as post-release end-user feedback integration (Section 2.3) and the running of performance tests (Section 2.4) The support tool functionalities include: method performance testing, method sequence performance testing, code segment performance testing, usage logging, usage log analysis and automatic test case generation from usage logs 4.2 Discussion An important goal of the project was to obtain a methodology that is as close as possible to the ideal trait list presented in Section 1.4 Indeed, by introducing end-user 53 feedback support, application categories and software product lines principles, MobileD now presents more of the ideal characteristics Furthermore, the methodology was improved in other aspects not mentioned in the list, such as the inclusion of performance testing in the lifecycle Another important contribution was the support tool, that not only enables corresponding features of Mobile-D, but decreases overall development effort Some characteristics of the tool may even be used outside mobile development; features such as usage logging, log analysis and test case generation can be used in any development scenario, with only minor adjustments to the support tool 4.3 Further work 4.3.1 Mobile-D The methodology would further benefit from an investigation into introducing market study practices in the lifecycle, as this aspect is not specifically addressed by Mobile-D; this is the only item on the ideal trait list not expressly treated by the approach Instead, the methodology relies on team members’ experience in the field when making decisions regarding project planning By improving market consciousness, planning decisions such as setting the project timeline and development rhythm can be adjusted to better meet market requirements As with all methodologies, the improvements brought to Mobile-D should undergo experimental validation in a real organization Unfortunately, such an experiment would require extensive work to be performed in collaboration with development teams working with different methodologies, and analyzing if the envisaged benefits of the improvements described here are met when applied on real projects 4.3.2 Support tool Further work on the support tool includes evaluating if it would be useful to include performance testing for other Android components (services, content providers and broadcast receivers) and to eventually extend the tool with these functionalities Also, the wizards used to generate performance test cases can be extended so that almost no 54 more coding is necessary after code generation For example, the wizard could allow developers to select the type of metric for each test, and the target measurement in the assertion, leaving only parameter initialization to be done after the code has been generated The most interesting direction for future work, however, is related to automatic test suite generation from usage logs Currently, test cases are generated using parameters of the method in which the error was logged The mechanism cannot recreate errors that are caused by other factors such as class variables or external input, or if the method parameters are not serializable The approach can be extended by including more entities from the environment that caused the error, such as logging any class variable that was accessed or modified within the method A study can be performed, evaluating possible causes for errors, and the correct way to log these causes Another approach would be to generate test cases from serialized exception objects generated by errors, using the information contained in these objects, such as a stack trace dump Finally, the wizard used for test case generation can be improved to use multiple log files as input 55 Chapter Bibliography Abrahamsson, P (2007) Agile Software Development of Mobile Information Systems In Advanced Information Systems (pp 1-4) Berlin: Springer Abrahamsson, P (2005) Mobile software development - the business opportunity of today Proceedings of the International Conference on Software Development, (pp 2023) Reykjavik Abrahamsson, P., Hanhineva, A., Hulkko, H., Ihme, T., Jäälinoja, J., Korkala, M., et al (2004) Mobile-D: an agile approach for mobile application development Conference on Object Oriented Programming Systems Languages and Application; Companion to the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications (pp 174-175) Vancouver: ACM Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J (2002) Agile Software Development Metods: Review and Analysis VTT Electronics Agile Alliance (2001) Agile Software Development Manifesto Retrieved from Manifesto for Agile Software Development: http://agilemanifesto.org/ Amanquah, N., & Eporwei, O T (2009) Rapid Application Development for Mobile Terminals 2nd International Conference on Adaptive Science & Technology, ICAST, (pp 410-417) Android (2010) Retrieved http://developer.android.com/index.html from Android Developers: Balagtas-Fernandez, F., & Hussmann, H (2008) Model-Driven Development of Mobile Applications 23rd IEEE/ACM International Conference on Automated Software Engineering, (pp 509-512) L'Aquila Beck, K., & Andres, C (2004) Extreme Programming Explained: Embrace Change (2nd Edition) Addison-Wesley Professional Beydeda, S., Book, M., & Gruhn, V (2005) Model-driven software development Birkhauser Boehm, B (2002) Get Ready for Agile Methods, with Care Computer , 35 (1), 64-69 Boehm, B., & Turner, R (2003) Balancing Agility and Discipline: A Guide for the Perplexed Addison-Wesley Braun, P., & Eckhaus, R (2008) Experiences on Model-Driven Software Development for Mobile Applications Proceedings of the 15th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems, (pp 490-493) 56 Carton, A., Clarke, S., Senart, A., & Cahill, V (2007) Aspect-Oriented Model-Driven Development for Mobile Context-Aware Computing Proceedings of the First International Workshop on Software Engineering for Pervasive Computing Applications, Systems, and Environments, (pp 5-8) Clements, P., & Northrop, L (2002) Software Product Lines : Practices and Patterns Boston, MA: Addison-Wesley Cockburn, A (2004) Crystal Clear: A Human-Powered Methodology for Small Teams Addison-Wesley Professional Dyba, T., & Dingsoyr, T (2009) What Do We Know about Agile Software Development? IEEE Software , 26, 6-9 Eclipse (2010) Retrieved from http://www.eclipse.org/ Hayes, I S (2003) Just enough wireless computing Prentice Hall Ho, C.-W., Johnson, M J., Williams, L., & Maximilien, E M (2006) On Agile Performance Requirements Specification and Testing Proceedings of the conference on AGILE, (pp 47-52) Hofmann, H F., & Lehner, F (2001) Requirements Engineering as a Success Factor in Software Projects IEEE Software , 18 (4), 58-66 Hulkko, H., & Abrahamsson, P (2005) A Multiple Case Study on the Impact of Pair Programming on Product Quality Proceedings of the 27th international conference on Software engineering, (pp 495-504) St Louis Ihme, T., & Abrahamsson, P (2005) The Use of Architectural Patterns in the Agile Software Development of Mobile Applications International Conference on Agility, ICAM, (pp 155-162) Helsinki Johnson, M J., Ho, C.-W., Maximilien, E M., & Williams, L (2007) Incorporating Performance Testing in Test-Driven Development IEEE Software , 24 (3), 67-73 Jones, L G., & Northrop, L M (2010) Clearing the Way for Software Product Line Success IEEE Software , 27 (3), 22-28 Khambati, A., Grundy, J., Warren, J., & Hosking, J (2008) Model-driven Development of Mobile Personal Health Care Applications Proceedings of the 23rd IEEE/ACM International Conference on Automated Software Engineering, (pp 467-470) Kim, H., Choi, B., & Wong, W E (2009) Performance Testing of Mobile Applications at the Unit Test Level Proceedings of the 2009 Third IEEE International Conference on Secure Software Integration and Reliability Improvement, (pp 171-180) Kroll, P., & Kruchten, P (2003) The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP Addison-Wesley Professional Kunz, T., & Black, J (1999) An Architecture For Adaptive Mobile Applications Proceedings of Wireless 99, the 11th International Conference on Wireless Communications, (pp 27-38) 57 Mahmood, M A., Burn, J M., Gemoets, L A., & Jacquez, C (2000) Variables affecting information technology end-user satisfaction: a meta-analysis of the empirical literature International Journal of Human-Computer Studies , 52 (4), 751-771 McGee-Lennon, M R (2008) Requirements Engineering for Home Care Technology Proceeding of the twenty-sixth annual SIGCHI conference on Human factors in computing systems, (pp 1439-1442 ) Florence Mobile Apps (2010) Mobile Apps Group Retrieved from http://www.informaticsventures.com/connect/mobile-apps-group Nascimento, L M., de Almeida, E S., & de Lemos Meira, S R (2008) A Case Study in Software Product Lines - The Case of the Mobile Game 34th Euromicro Conference on Software Engineering and Advanced Applications, (pp 43-50) Parma Northrop, L (2004, September) Software Product Line Adoption Roadmap Retrieved August 10, 2010, from http://www.sei.cmu.edu/library/abstracts/reports/04tr022.cfm Oinas-Kukkonen, H., & Kurkela, V (2003) Developing Successful Mobile Applications Proceedings of the International Conference on Computer Science and Technology, (pp 50-54) Cancun, Mexico Pikkarainen, M., Salo, O., & Still, J (2005) Deploying Agile Practices in Organizations: A Case Study Springer Berlin / Heidelberg Rahimian, V., & Ramsin, R (2008) Designing an Agile Methodology for Mobile Software Development: A Hybrid Method Engineering Approach Second International Conference on Research Challenges in Information Science, 2008 RCIS 2008 , (pp 337-342) Marrakech Salo, O (2006) Enabling Software Process Improvement in Agile Software Development Teams and Organisations Helsinki: VTT Sharp, H., Finkelstein, A., & Galal, G (1999) Stakeholder Identification in the Requirements Engineering Process Proceedings of 10th International Workshop on Database & Expert Systems Applications (DEXA) (pp 387-391) IEEE Computer Society Press Staples, M., & Hill, D (2004) Experiences Adopting Software Product Line Development without a Product Line Architecture Proceedings of the 11th Asia-Pacific Software Engineering Conference (pp 176-183) IEEE Computer Society Techmeetup (2010) Retrieved from Techmeetup: http://techmeetup.co.uk/ Unhelkar, B., & Murugesan, S (2010) The Enterprise Mobile Applications Development Framework IT Professional , 12 (3), 33-39 Varshney, U., & Vetter, R (2001) A Framework for the Emerging Mobile Commerce Applications Proceedings of the 34th Annual Hawaii International Conference in System Sciences, 9, pp 9014-9023 VisionMobile (2010) Mobile http://www.visionmobile.com Developer 58 Economics 2010 and Beyond VTT Electronics (2006) Portal of Agile Software Development Methodologies Retrieved from Mobile-D Method: http://virtual.vtt.fi/virtual/agile/mobiled.html Zhang, W (2005) Architecturally Reconfigurable Development of Mobile Games Second International Conference on Embedded Software and Systems (ICESS'05), (pp 6672) Xian Zhang, W., & Hansen, K M (2007) Synergy between Software Product Line and Intelligent Mobile Middleware International Conference on Intelligent Pervasive Computing, (pp 515-520) 59 [...]... 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... 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... especially in the case of mobile applications, the customer identification problem is much more complex, as will be detailed in a later section of this work 3 A new development methodology, specifically tailored for mobile application development, called Mobile- D, is presented in (Abrahamsson, et al., 2004) The method is based on agile practices, drawing elements from well established agile methods such as... 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... 2001) the authors identify twelve classes of mobile commerce applications Example classes include Mobile financial applications (banking and micropayments), Product location and shopping (locating and ordering items), and Mobile entertainment services (video-on-demand and similar services) However, these classes only apply to mobile commerce applications (mobile applications that involve transactions... richness and complexity) is represented by Mobile broadcast (M-broadcast) applications, that are aimed at providing large-scale broadcast of information to mobile platforms Higher-level applications are Mobile information (Minformation) applications, which provide information required by mobile users, such as weather conditions The third level of applications is Mobile transactions (Mtransaction) facilitating... 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... 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,... when discussing the suitability of agile methods for mobile development The conclusion was that, for mobile products, customers were harder to identify due to the multitude of software distribution channels, resulting in a 16 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... 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 ... members of the Mobile Apps (Mobile Apps, 2010) and Techmeetup (Techmeetup, 2010) groups The questionnaire comprises three sections: agile methods for mobile applications, Mobile- D, and mobile development... 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... 1.1 Mobile application development 1.2 Agile development for mobile applications 1.3 Mobile- D overview 1.4 Improvement approaches Improvements to Mobile- D