Essay: Mobile data analytics

1. INTRODUCTION
This chapter describes brief introduction of this project and it also includes problem statement, objective of the study, methodology used in the project, scope and limitation of the study and it also describes hardware and software requirements for this project.
1.1 General Information
The rapidly evolving mobile landscape is compelling businesses across every industry to rethink how they connect to people across a multitude of platforms. Whether for enterprise or consumer use, mobile application development is escalating at a drastic rate. As the mobile space evolves and app stores increase in size, the importance of viable, well thought out mobile apps is only the beginning. Mobile apps that are not executed and built to proper standards increase the chance of a user quickly uninstalling the application. The existing popularity of cell phones and other mobile devices capable of connecting to the Internet, coupled with the dramatic increase in popularity of powerful smart phones like Apple’s iPhone, has led to a surge in interest among businesses throughout the world in having a presence on the ‘mobile Internet’.
Unfortunately the amount of available expertise for deploying mobile sites across diverse networks, devices, and application stacks is currently lacking. In situations like this, mobile app Analytics Demystified is a strong champion for the appropriate use of measurement to help determine the quality and efficacy of deployed sites and applications. Massive quantities of data produced by and about people, things and their interactions is changing the way businesses operate .The smartphone and its accompanying apps is a new source of digital footprints, which due to its unique characteristics is gaining increased attention from managers and decision makers.
Hence the analysis of mobile app data is a field of growing interest, although it remains to be thoroughly studied academically. Mobile App Analytics measures what matters most at all key stages: from first discovery and download to in-app purchases. You’ll get a clear view you can act on to make users happier.
1.2 Statement of the problem
Our empirical analysis identifies gaps between the value propositions of mobile app data, and the data that the case tools currently provide. This is particularly apparent when it comes to sensor input such as location awareness and the fact that the tools are only able to report data on an aggregated level. Additionally, the tools lack transparency, why trust and validity issues arise. On the other hand, the tools provide detailed records of usage, interaction and navigational patterns.
1.3 Objectives of the study
Mobile data analytics provide intuitive views of application performance by handset and include location and subscriber context. These can be provided in report format to meet the needs of multiple stakeholder organizations.
We find that there is a general lack of strategic targets for mobile app analytics, otherwise proscribed by the theory. Based on app analytics, they currently take decisions regarding app optimization, and report top-line metrics to management to ensure resources for future projects. Hence, we find that decision-making on the basis of mobile app analytics currently revolves around the app itself or the department on which it is placed. Due to lack of system integration, data complexity and validity, our case companies are currently not able to base strategic or automated decisions on the data that they can derive from their apps.
1.4 Software Development Process Model
The software development model adopted in our project is the agile model. Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.
There are many variations of agile processes:
‘ In Extreme Programming (XP), the phases are carried out in extremely small (or “continuous”) steps compared to the older, “batch” processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can’t think of any more tests that are needed. Design and architecture emerge out of refactoring, and come after coding. The same people who do the coding do design. The incomplete but functional system is deployed or demonstrated for the users. At this point, the practitioners start again on writing tests for the next most important part of the system.
‘ Scrum and Dynamic systems development method.
1.5 Scope and limitation of the study
Scope of improving quality checks for mobile application project is categorized in two ways:
‘ Project Scope – The scope that deals with the work that needs to be accomplished in developing this application for rendering service to the customer.
‘ Product Scope ‘ Product scope that deals with the features and functionalities that categorizes a product.
I. This project aims at developing a mobile app which is a utility to see statistics unique to the user device and it collects the user’s app usage behavior along with device information to enhance his mobile usage experience.
II. With this application user can see running processes storage space used and free space, user unique device identifier, OS version and other device information’s like IP address, current location. And it is useful for developers when debugging their applications.
1.6 Hardware and software requirements
‘ Software
Operating System : Windows 7
Environment : Eclipse
Language : Java
Database : MS SQL Server 2008
‘ Hardware
iPhone running iOS 6 and later, Phones with android v4.0 and above.
Processor : Intel core i7
RAM : 8GB or Higher
Hard Disk : 500 GB
1.7 Organization of the report
The main body of the report is preceded by detailed contents including lists of figures, tables, and annexes followed by units used in the report. This is followed by executive summary as stated below.
Chapter 1: explains the importance of the topic, statement of the problem, scope and methodology.
Chapter 2: Discusses about the literature review.
Chapter 3: Lists the Functional and Non-Functional Requirements of the project.
Chapter 4: Explains about the data collection and analysis of the system.
Chapter 5: Gives the flow of the system.
Chapter 6: Gives the details of the implementation of the project.
Chapter 7: Explains the types of testing done on the project and lists the test cases.
Chapter 8: Gives the screen shots of the project.
Chapter 9: Gives the conclusion and future enhancement.
Chapter 10, 11: Gives bibliography.
2 Literature Review
The purpose of this project is to examine the emerging field of mobile app analytics and thus fill a void in the academic literature by identifying value propositions for mobile app data and explore the maturity level of mobile app analytics. Here the field of mobile app analytics is explored by three perspectives ‘ the mobile app as a data source, the analytics tools needed to turn the data into insights, and the organizational aspect of using actionable insights to inform decision making.
Our analysis shows that the mobile platform is characterized by being personal, interactive, ubiquitous, location aware, and multimodal. With reference to particular app specific characteristics, this leads us to conclude that the mobile app as a data source is distinguished from other digital data sources by its ability to add a contextual layer to the data, enabled by sensor technology. We find that the ability to add a time/place dimension to other data types is a unique value proposition. The data comes in various types and structures while the digital nature of the app means that interactions can be tracked instantly as they occur.
The app as a data source thereby allow for holistic analysis and timely insights. The app data is furthermore personal and behavioral, enabling personalization and message tailoring. We thus conclude that although mobile app data presents a series of promising value propositions, the current stage of mobile app analytics tools leaves room for further development and investment.
A series of initiatives will have to be undertaken before the app data potentials can unfold: The analytics tools must improve their ability to utilize the app specific value potentials, allow for system integration and enhance the granularity levels of the data. If the overall maturity level is leveraged on both the organizational level and in the tool capabilities, mobile app analytics will be a valuable data source suitable for gaining insights into user behavior.
3 System Requirement specification
Software Requirement Specification (SRS) is the starting step for development activities. It is the medium through which the client and user needs are accurately specified by producing the requirement specification document, which describes the external behavior of the proposed software.
The basic purpose of software requirement specification is to bridge the communication gap between the client, the user and the developers as well as to identify and present the efficiency, the functionalities of the work and verification of the working criteria of the employee. SRS goes as input to the designing phase of the project, to design a project, the detailed structure of the project should be known, that is nothing but SRS, which tells about the project or task, then proceed to designing phase.
3.1 Functional requirements.
Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform. This document discusses about capturing functional requirements in such a way that they can drive architectural decisions and be used to validate the architecture. In product development, it is useful to distinguish between the baseline functionality necessary for any system to compete in that product domain, and features that differentiate the system from competitors’ products, and from variants in our company’s own product line/family. Features may be additional functionality, or differ from the basic functionality along some quality attribute (such as performance or memory utilization).
Table 3.1: Functional Requirements
Requirement id Name Description
Req1
installed apps
This field contains the installed apps on the device.
Req2
Running apps This field contains currently running apps in the device.
Req3
Location log Contains the information about the current location.
Req4
Device data Contains the device data such as device id, Bluetooth state, IMEI, etc.
The functional requirement can be well expressed in terms of use case diagrams, which shows the functionality of each group of users. Use cases have quickly become a widespread practice for capturing functional requirements. This is especially true in the object-oriented community where they originated, but their applicability is not limited to object-oriented systems. Use cases represent the different actors taking part in the building of the application.
3.2 Non-Functional requirements.
Non-Functional Requirements are the requirements that are not directly concerned with the specific functions delivered by the system. They are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors. They define how a system is supposed to be. They can be divided into two main categories:
‘ Execution qualities, such as usability and supportability, which are observable at runtime.
‘ Evolution qualities, such as reliability, performance, maintenance which are embodies in the static structure of the software system.
Non-Functional Requirements arise through user needs, due to budget constraints, the need to interoperate with other hardware and software systems or external factors such as safety regulations or privacy legislation.
Table 3.2: Non-Functional Requirements
Specification Description
Usability
The user is provided with the mandatory options to perform certain activity in the application based on his requirement. The inclusion of options depends on the functionality and user requirement.
Scalability
The system can quickly scale itself to requirement without retooling your IT infrastructure.
Supportability
The system can be able to handle different kinds of os. It will be able to perform all the identified functionalities for all kinds of os.
Maintenance
Software product modification performed after delivery to keep a software product usable in a changed or changing environment. Modification of a software product after delivery to detect and correct latent faults in the software product before them become effective faults.
Software product modification performed after delivery to keep a software product usable in a changed or changing environment. Modification of a software product after delivery to detect and correct latent faults in the software product before them become effective faults.
4 System Analysis.
System Analysis is another important phase where the analysis is done to identify the drawbacks of the system that is already developed and what exactly should be overcome in the existing system that leads to proposed system.
4.1 Existing system.
There are some traditional existing small applications but each one has a limit. As the advancement of the technology and business we require an application where we have all the advanced features the companies are looking for. With new ideas and full market survey we are designing this leading software application.
4.2 Limitation of the Existing system.
‘ The system which has been maintained manually has been complex and complicated.
‘ There are many chances for data lose and the work wouldn’t be an effective and efficient one.
‘ Security for the data maintained is compromised.
4.3 Proposed System.
‘ This project aims at developing a mobile app which is a utility to see statistics unique to the user device and it collects the user’s app usage behavior along with device information to enhance his mobile usage experience.
‘ With this application user can see running processes storage space used and free space, user unique device identifier, OS version and other device information’s like IP address, current location. And it is useful for developers when debugging their applications.
‘ Provide users an excellent UX for native application.
‘ It can show what applications are being used, how much an application is being used relative to other applications and the throughput and utilization for a given link.
5 Design.
A system is an organized approach towards solving a problem. System Analysis and Design mainly deals with the software development activities. Analysis of the new system involves a significant study of the present system, leading to requirements of a new system. Analysis is a thorough study of various operations accomplished by a system and their relationships within and outside the system.
5.1 High level design.
5.1.1 System Architecture.
5.1.2 Modules Description.
This project will have the following functionalities.
1. Installed apps
2. Running processes.
3. App usage event logs.
4. Installed app event logs.
5. Device data.
6. Location logs.
5.1.2.1 Installed apps.
This module contains the list of installed app on the device such as web apps, native apps and also the hybrid apps. Here we can also recognize the installation timestamp.
5.1.2.2 Running processes.
This module contains the currently running app list. This running app list gives whether the app is running as service, running in background or in foreground.
5.1.2.3 App usage event log.
This module contains the log of app usage. It will keep the track of
‘ Applications which are running in background.
‘ Applications which are running in foreground.
‘ Applications which are disappeared from the screen.
‘ Applications which are transferred to service from background state.
‘ Applications which are transferred from background to service state.
5.1.2.4 Installed app usage event log.
This module keeps the track of installed apps, uninstalled apps with timestamp.
5.1.2.5 Device data.
This module contains the device details such as phone model, os version, local area storage of the device, bluetoothMAC, etc.
5.1.2.6 Location logs.
This module contains the record of location logs. In location log we can see the details of current location of the user.
5.2 Detail Design.
5.2.1 Database Design.
The database design is essential for any application being developed, especially for the data store projects. Databases are normally implemented by using a package called Data Base Management System (DBMS). One of the most useful methods of analyzing the data required by the system for the data dictionary has developed from research into relational database, particularly the work of E.F. Codd. This method of analyzing data is called ‘Normalization’.
Normalization is the process of strutting relational database schema such that most ambiguity is removed. The stages of normalization are referred to as forms and progress from the least restrictive (first normal form) through the most restrictive (Fifth normal form), generally , most database designers do not attempt to implement anything higher than normal form of Boyce code Normal Form.
This section provides the information related to all the entities involved and tables identified during the process of design. It also gives information pertaining to the primary keys in a table, what are the constraints for each attribute in the table.
5.2.1.1 ER Diagram.
E-R Diagram is one of the most important elements of the design phase, which shows the relationship between the entities of the system. The relationship between entities can be maintained using the primary and foreign key concepts. This is called foreign key constraint or referential integrity.
5.2.1.2 Tables Design.
5.2.2 Class Diagram.
5.2.3 User Interface Design.
5.2.4 Activity diagrams/Flow chart/Algorithm Design.
5.2.5 Sequence/Collaboration diagrams/Data Flow diagrams.
6 Implementation.
7 Testing.
Testing is a process of executing a program with the intent of finding an error or bug. Software testing is the execution of program to find its fault. The testing process focuses on the logical internal of the software, ensuring that all statements have been tested and on the functional externals, that is conducting test or uncover error and ensure that defined inputs will produce actual results agreed with the required results.
A test is vital to the success of any system. System test makes a logical assumption that if all parts of the system are correct, then goal will be successfully achieved. The candidate system is subjected to a variety of tests online like responsiveness, its value, stress and security. A series of tests are performed before the system is ready for user acceptance testing.
7.1 Types of Testing
1. Unit Testing
Here we test each module individually and integrate the overall system. Unit testing focuses verification effort even in the smallest unit of software development in each module. This is also known as module testing. The modules of the system are tested separately. This testing is carried out in the programming style itself. In this testing, each module is focused to work satisfactorily as regard to expect output from the module.
2. Integration Testing
Data can be lost across on an interface, one module have an adverse effect on the other sub-functions, when combined may not produce the desired functions. Integrated testing is the systematic testing to uncover the error within the interface. The testing is done with simple data and the developed system can run successfully with this simple data. Here the major intention is to find the overall system performance.
3. Black box Testing
This is a software testing approach in which the tester doesn’t know the internal working of the item being tested. For example in a Black box test, on software design the tester only knows the input and the expected outputs. He doesn’t know how the program derives the output. He doesn’t even imagine as to how, the coding is done. He need know only the specifications.
4. Validation Testing
At the culmination of Black box testing the software is completely assembled as a whole package. Interfacing error has been uncovered and corrected and the final series of tests that is validation begins. The validation test can be defined by the following simple definition that validation succeeds when the software functions in a manner that can be reasonably accepted by the customer.
5. Functional Testing
Functional testing will be performed for all product features. It will cover product features that have end user impact and also the features that have end user impact and also the features that do not have any user interface dependency.
6. Smoke Testing
Smoke testing is the initial testing process exercised to check whether the software under test is ready/stable for further testing. ‘Smoke Testing’ is came from the hardware testing, in the hardware testing initial pass is done to check if it did not catch the fire or smoked in the initial switch on.
7.2 Test cases
A test case, in software engineering, is a set of conditions or variables under which a tester will determine whether an application, software system or one of its features is working as it was originally established for it to do. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test oracle. In some settings, an oracle could be a requirement or use case, while in others it could be a heuristic. It may take many test cases to determine that a software program or system is considered sufficiently scrutinized to be released.
Table 7.1: Test case for installed apps
Test case Id Test case description
Excepted Result
Result
TD1
Click on ‘Installed apps’.
Should display a spinner indicating the app loading process.
Pass
TD2 Check the native apps, web apps, hybrid apps Should show all native, web apps in the device.
Pass
TD3 install/uninstall an app and do manual sync install/uninstall an app and do manual sync
Pass
Table 7.2: Test case for installed apps
Test case Id Test case description
Excepted Result
Result
TD1 Click on ‘installed app usage Should display the list of installed/uninstalled app list with time stamp.
Pass
TD2
install a new app
Should record the newly installed app
Pass
TD3
Uninstall an app
Should record the uninstalled app
Pass
Table 7.3: Test case for running apps
Test case Id Test case description
Excepted Result
Result
TD1
Click on ‘installed app usage should display all the apps that are currently running in background, foreground, servicing and perceptible state
Pass
TD2 launch an app and make it run in background the launched app should be added in the running apps list with the timestamp and its state
Pass
Table 7.4: Test case for App usage logs
Test case Id Test case description Excepted Result Result
TD1 Click on ‘installed app usage should display log time with timestamp and log details Pass
TD2 install and launch an app should display the state of launched app as ‘app changed from none to foreground state’
Pass
TD3 again open the same app Should display the state of launched app as ‘app changed from background to foreground state.’
Pass
TD4 kill the app In log details it should be recorded as app disappeared Pass
8 Results/Screen shots.
9 Conclusion and Future Enhancements.
9.1 Conclusion
Mobile app data presents a series of promising value propositions, but the current stage of mobile app analytics tools leaves room for further development and investment. A series of initiatives will have to be undertaken before the app data potentials can unfold: The analytics tools must improve their ability to utilize the app specific value potentials, allow for system integration and enhance the granularity levels of the data. If the overall maturity level is leveraged on both the organizational level and in the tool capabilities, mobile app analytics will be a valuable data source suitable for gaining insights into user behavior.
This project is successfully developed and its performance was found to be excellent. The system was tested with sample data and was found to be much faster, reliable and user friendly than the existing system.
9. 2 Future Enhancements
The application developed is designed in such way that further enhancement can be done easily. New modules can be added to the existing system with less effort. Providing extra facilities can enhance the Processing module.
As Changes are always necessary in future it applies to software development also. But these changes should be appreciable in nature. These appreciable changes will make the software to flight for its survival in the competitive market. Hence it is necessary to think about future enhancement at present.
Future enhancements can be as follows:
‘ This project can be further extended by managing battery usage.
‘ Designing more attractively.
10 Annexure.
11 Bibliography.