III.

METHODOLOGY

3.1 Framework of the Study

This chapter presents the methods and concepts used in developing the application. It

is composed of information’s gathered from different previous researchers and on how to

develop and use the particular application, the requirements that the developers met such as

deadlines and platforms where the system was used. The conceptual framework (shown in

Fig. 3.1 below) of the project is composed of Input, Process and the Output of the application

and the requirements needed in the project are also indicated.

INPUT PROCESS OUTPUT

Planning and System

Design
a. UI Design
b. Map Display

Information Application
Gathering Development
a. Programming/
Coding
Software
Requirements b. Database Smartphone Map
Application for
Android
Hardware Application
Requirements Optimization
a. Application GPS
Accuracy
b. App Startup Time
Optimization

Implementation
a. Initializing and
testing for bugs and
errors

Figure 3.1 Conceptual Frameworks

20
 The researcher used developmental and applied type of research. The study started

with information gathering of related work provided by previous different researchers. Also

in this study, the performance of the developed application was observed and the results were

recorded. This was done to determine or confirm the actual specifications and recalibrations

of the application design. The foregoing article addressed the Framework Process and the

procedural workflow diagram of creating the android application shown in Figure 3.2. The

initial step was to gather all the needed information’s to start the study, then once gathered

the data was thoroughly analyzed to make the optimum solution for the problem. Finally,

when the solution presented itself, a system was developed and was designed to meet the

needed requirements. And thus, the last process was to test and analyze the data after the

application was developed.

21
3.1.1 Input Phase

Based from the Conceptual Framework, the inputs gathered through information from

specific contributors and software and hardware requirements are met to make design project

possible. Then, a process shall take place. It shall analyze all the inputs provided and act

accordingly.

3.1.1.1 Information Gathering

The first phase for the development of Smartphone Emergency Exit Locator was

information or requirements gathering and analysis as to what features are the most essential.

The purpose of information gathering is to support the planning of the application

development to become more fully inclusive, what the various methods are, together with

their respective merits; in that scenario it is also applied into this research. Requirements

gathering are one of the most important phases of a software development life cycle. It is the

phase that tells what is the system supposed to do and drives the other phases in the life cycle.

This led to the most basic and initial draft of requirements for the application.

A brief study of the functionality of the android smartphone helped to refine and

narrow down the requirements even further. One important thing to learn on these android

smartphone was the simplicity of their design. This helped to design an effective and simple

UI design for my application. The next step for requirements understanding was to look for

existing solutions and similar applications in the Android market. A thorough evaluation of

these similar applications, adding other important features and removing unnecessary features

was done on the proposed application. A routinely submission of the research draft to the

supervising professor helps to refine the requirements and even further to provide a

functional requirements for the application.

22
 The major functional requirements for the android app are –

i. The user must see the main page of the app for every other time he/she opens

the app.

ii. The user shall be able to see their current location.

iii. The user shall be able to see clearly the drawn pathway

iv. The user shall be able to start/stop location tracking.

Other non-functional requirements for the application are –

i. Providing a simple and elegant UI for the main screen. This is necessary as the

user would usually come on to this screen in case of a panic or emergency and

hence each button should be clearly visible and easily pressed. ii.

ii. In case the option to track location is selected and there is no internet

connectivity on the device (both wireless and Cellular data), the application

should be able to store the locations offline and send them to be stored in the

database once the internet connectivity is up again.

iii. Providing a tab based view to display the different setting for the application

iv. Enabling swipe gestures for the tabbed view.

v. Displaying user friendly dialogs for notifications or other warnings.

3.1.1.2 Software Requirements

Software requirements are met to achieve and develop a fully functional proposed

android application. These requirements are separated based on whether you are developing

the app or running the app on a device.

For development:

 Operating System: Windows 10 64bit

23
  Platform: Android SDK Framework 10 or higher

 Tools: Eclipse SDK 3.5, ADT plug-in for eclipse

 Technologies used: Java, SQLite, Android, Anyplace maps API

 Debugger: Android Dalvik Debug Monitor Service (DDMS)

 Android Emulator: API level 14 or higher 10 for running on a device:

Running the app on a device:

 Device Operating System: Android 5.0 or higher

3.1.1.3 Hardware Requirements

Hardware requirements are met to integrate the software’s needed and to make

possible the development of the device. These requirements are separated based on whether

you are developing the app or running the app on a device.

For development:

 Processor: Pentium G4560 equivalent or higher

 RAM: 2GB or higher

 Hard disk space for installation of software applications: 1GB or higher

Running the app on a device:

 For test running on a device: Smartphone

 Storage space for smartphone: 1GB or higher / 256mb(minimum)

3.1.2 Process Phase

Process phase features a key step in the project: system construction. The previous

phase lays the foundation for system development; the following phases ensure that the

24
product functions as required. To complete the Process Phase successfully, two elements are

required: 1) a complete set of application design specifications and 2) Proper processes,

standards and tools.

The purpose of the Process Phase is to convert the system design prototyped into a

working android application that addresses all documented system requirements. At the very

end of this phase, the application should be tested before deployment.

3.1.2.1 Planning and System Design

Start

Information Gathering for

an Android Map Application

Meeting the Software and

Hardware Requirements

Developing the application

Testing the developed

android application

Analysis and Interpretation

End

Figure 3.2 Workflow of developing process of the Android Application

Developing the android map app for the University of Nueva Caceres it was possible

to foresee and plan for the whole application development life cycle. Shown in Fig. 3.2, an

agile software development methodology was adopted, tacking a small piece of requirement

25
implementing and testing them separately from the application and then integrate them with

the application, testing the application, evaluating the tests results and repeating this sequence

for the next feature. Developing an Android mapping application includes two main features:

displaying a map and determining the user's location.

The smartphone emergency exit locator is only developed for android smartphone;

therefore it is relatively simple and easy to operate. The user interface is made friendly and

easy to operate and use; this has the advantage of being the user not able to get confused upon

using the android application. The screen size and resolution are the two biggest design issues

as every android smartphone has different screen size and resolution. The android application

has a screen dimension of 1024 pixels in width and 640 pixels in height. This average screen

size therefore limits the number of user interface controls that can be used and displayed.

In addition, the size of the fonts, the size of the images, the number of user interface

controls all impact the usability of the application. The limited screen area available

constrained our selection of interface controls implemented in the application. As the user

interface buttons are required to be bigger than normally displayed on a conventional

smartphone applications it was imperative that the buttons be consistent and in predictable

positions. Therefore the decision was made to use a traditional menu bar displayed at the

bottom of the screen containing all button controls. As screen size and disk space required on

the android application is minimal. As the smartphone emergency exit locator is an indoor

application, design issues concerning application colors.

Various colors and font representations were informally considered until it satisfies

with the layout and the application’s representation in indoor and emergency conditions. By

its very nature the android application it must be bug-free to avoid errors upon using. Since

26
the android application is designed primarily for emergency usage, the interface must be

acknowledgeable.

3.1.2.1.1 Application Architecture Diagram

The proposed smartphone emergency exit locator consists of a cloud server provided

by the used mapping API, GPS supported android mobile smartphones with the proposed

application installed on it. Fig. 3.3 demonstrates the architecture of the proposed smartphone

emergency exit locator.

Figure 3.3 Smartphone Emergency Exit Locator Architecture

Anyplace Indoor Information Service, stores the attached building layout on street-

view of the UNC EA building accessed by the application in its database. Assigned

developers can access the database to update the building layout if there’s any changes

conducted. Through network provider or GPS provider, smartphone gets the current location

27
of its user and sends it to server. Using this current position, the system will then provide the

shortest available pathway for the user to take.

Figure 3.4 Use Case diagram of the System

In the Fig. 3.4, the USER launches the application and opted to start tracking his/her

location it has also the relation whether the user wants to stop the service tracking location.

The USER can fetch his/her history location stored on Database. It is then related with the

Anyplace Map Engine as to deploy the current OpenStreetMap and pinpoint the current

location of the USER. The System Admin has the access to make updates on the system.

3.1.2.1.2 Application UI Design

Smartphone application user interface (UI) design is very important feature and it is

another essential part in application development. The UI involves considerations of contexts,

screen and user input and output mobility. In addition, understanding the behavior of the

28
users is even more essential for developing UI for the application’s UI. The user manipulates

the application via input and then the expected results are displayed via the output. In mobile

devices environment, each architecture layer of the application must be considered and

prioritized carefully to maximize the physical capacity of the devices. Designing UI for

mobile applications is so difficult. Therefore, developing applications for mobile devices is

challenging and rewarding in its outcome

There are smartphone UI constraints such as limited screen size. Smartphone UI is

considered as front-end and they rely on backend to support access to enterprise systems.

Figure 3.5 Application UI Design

3.1.2.1.3 Application Map Display

29
 The application should display a map that is detailed enough to allow the user to find

a particular place. The map is displayed from a map server. It can be displayed directly from

the server or stored in the handset for offline use. Displaying the map directly from the server

has the disadvantage that the loading of the map tiles will be dependent on the availability

and speed of the Internet connections i.e. in some places there is no signal, and in others there

is signal but the data rate is very small.

Figure 3.5 Application UI embedded with OSM map data of UNC from Anyplace

The level of details of the map displayed by the application will depend on the quality

of the map on the server. Maps qualities vary greatly from one server to another, and even for

the same server the level of detail varies for different regions. Many map servers allow the

30
community of users to edit maps and contribute additional details, and then they review the

edits and display them in the server. After that the developers can access them by the

application or download them. To display maps from a particular server, developers’ use the

application programing interface (API) provided by the server that provides classes needed to

access the maps located in the server.

3.1.2.2 Application Development

Any mapping application involves two parts; a client-side part and a server-

side part. The client side part provides a user interface and accesses a map server. On the

server-side part developers prepare the maps in a well-defined format and provide an API to

access the map located on the server, then developers can use the API to develop applications

that access the maps and use additional features provided by the API.

Some servers publish their API for public access and use for free, others require an

API key, and some raise a fee for the use of the API. Therefore the first phase of the project

was to study the various APIs available on the Internet, their functionality, and their merits.

There are so many mapping APIs available, each of which belonging to and accessing a

particular server. Some APIs target indoor mapping, while others target outdoor mapping.

The most famous API is Google's mapping API, but there are many other mapping APIs like

Anyplace, ArcGIS, Mapsfore, OpenLayers, and Osmdroid. We studied and researched the

merits of Anyplace maps API because of indoor mapping and more suitable for the UNC EA

building.

In this paper, it will not discuss all APIs available, because there are many APIs, and

they are always changing, new APIs are introduced and the available ones are constantly

improved.

31
 The first step for anyone trying to develop a similar application is to look and

examine the available APIs, their features and license agreements. One interesting API is

Nutiteq mapping API besides supporting the basic features: showing interactive online map,

and map overlays, it also supports many base maps options OpenStreetMap, Bing, MapQuest,

MapBox, AND, CloudMade, where Google supports only Google Maps, and aerials. It also

supports online routing, geocoding, and unlike Google's API it supports offline maps and

offline routing. Google's mapping API, has the advantages of wide spread, it is well

documented, and easy to use. Google’s map API was not used because of free license that the

application must be free and publicly available, also the number of requests per day is

limited, it only access Google maps server, and also it doesn’t support indoor mapping.

Anyplace was selected because of its flexible license agreement, and its features and supports

indoor mapping: Anyplace mapping API is free, and does require a mapping API key. It

accesses Open Street Maps which is a collaborative project to create a free editable map of

the world. For these two reasons and suitable features we had chosen it.

3.1.2.2.1 Database Development

A database (DB) is a computer-based set of data, structured in a unique way, which

can be served to certified users, and is responsible for: organized structure, access,

manipulation, retrieval and presentation by use of a piece of software called Database

Management System (DBMS) (Figure 3.6).

32
 Figure 3.6 User database interaction schemas

DBMS allows specifying a structure of the database. Data sharing is an important

element of database ideology. Mainly all DBMS’s are providing data-sharing functionality by

providing different level of access to different classes of users. To keep the database healthy

the Database Management System (DBMS) is following certain requirements which are the

advantages of using database systems, and these requirements are (Worboys M. and

Duckham M., 2004):

 Security: Unauthorized users should not have access to the data.

 User views: User views should be flexible; each type of user should have

different levels of access to the data.

 Reliability: It should be prevented any loss of information in unexpected

situations like power failure.

 Integrity: The users should have guarantee that the data is accurate.

 Independence: Some users don’t care how the database works, and they should

not have a low level access.

 Metadata support and Human-database interaction: Users should have some

mechanism to see the database content and retrieve information according to their

obligations.

 Performance: The data retrieval should be as fast as possible.

33
  Concurrency: The mechanism should control the transactions which are

proceeding in the same time using the same data, for preventing unexpected data

loss.

 Distributed systems: The store of data should not necessarily be physically

centralized.

3.1.2.3 Application Optimization

To help users find a destination, or pinpoint their locations, mapping applications

include the ability to determine the user's location. The required accuracy depends on the

purpose of the application, but for most applications the degree of accuracy is sufficient if the

application can determine the location accurate enough for the user to be able to know what

street or building he is in, this degree of accuracy will be fine. At the same time the accuracy

of the location provided by the application depends on the method used to determine the

location, and the accuracy and the availability of that method in the particular region where

the user is.

Android supports determining the user's location using global position system (GPS)

that is built in the handset, or using information from a nearby transmission tower. Moreover,

if the user is connected to a Wi-Fi network or a stable data connection, it can be used to

determine the location. Application startup time is also one of the application features as the

user relies on the application on its quick response when launched or used.

3.1.2.3.1 Application GPS Accuracy

To determine the accuracy and reliability of the application, this study conducted and

investigated an accuracy test of the GPS with and without differential correction. Another

GPS capable smartphone device using Google Map application is used and compared the

34
tracking results with the developed android application. The Google Map will be used as an

actual basis as the application is capable of providing highly accurate readings of longitude

and latitude of the current position of the smartphone. One steady location will be put to

tracking tests using both applications.

Table 3.1 Two-Sample T-Test calculations from the data of App GPS vs. Google Map

GPS

TESTS Proposed Application Google Map

Longitude Latitude Longitude Latitude

TEST #1

TEST #2

TEST #3

TEST #4

TEST #30

MEAN

Standard
Deviation
Hypothesis if
μ1 = μ2 or μ1 ≠ μ2

In order to make this comparison, the mean from both Google Map longitude/latitude

and proposed application longitude/latitude various tests are calculated and taken, the study

used Two-Sample t-test for difference of the mean to see if they are significantly different.

35
 The two-sample t-test is applied to compare whether the average difference between

two groups is really significant or if it is due instead to random chance. It helps to answer

questions like whether the average success rate is higher after implementing a new sales tool

than before or whether the test results of patients who received a drug are better than test

results of those who received a placebo. A two-sample t-test is used when you want to

compare two independent groups to see if their means are different. Hence, the two-sample t-

test will be used as to calibrate the accuracy of the develop application.

The Null Hypothesis is there is no difference between the mean measurements

(longitude/latitude);

𝐻 ; 𝐺𝑜𝑜𝑔𝑙𝑒𝑀𝑎𝑝 = 𝐴𝑝𝑝𝑀𝑎𝑝

Alternative Hypothesis whether the measurements of location differs from the two

applications;

𝐻 ; 𝐺𝑜𝑜𝑔𝑙𝑒𝑀𝑎𝑝 ≠ 𝐴𝑝𝑝𝑀𝑎𝑝

Assume the Null Hypothesis.

T-Statistic;

(𝑀𝑒𝑎𝑛𝐺 − 𝑀𝑒𝑎𝑛𝐴 ) − 0
𝑡=
𝑆 𝑆
+
𝑛 𝑛

Where;

𝛼 = 0.05 (Significance Level)

𝑀𝑒𝑎𝑛𝐺 − 𝑚𝑒𝑎𝑛 𝑜𝑓 𝑡ℎ𝑒 𝑐𝑎𝑙𝑐𝑢𝑙𝑎𝑡𝑒𝑑 𝐺𝑜𝑜𝑔𝑙𝑒 𝑀𝑎𝑝 𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑠 𝑓𝑟𝑜𝑚 𝑣𝑎𝑟𝑖𝑜𝑢𝑠 𝑡𝑒𝑠𝑡𝑠

36
𝑀𝑒𝑎𝑛𝐴

− 𝑚𝑒𝑎𝑛 𝑜𝑓 𝑡ℎ𝑒 𝑐𝑎𝑙𝑐𝑢𝑙𝑎𝑡𝑒𝑑 𝐴𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 𝑀𝑎𝑝 𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑠 𝑓𝑟𝑜𝑚 𝑣𝑎𝑟𝑖𝑜𝑢𝑠 𝑡𝑒𝑠𝑡𝑠

𝑆 − 𝑆𝑡𝑎𝑛𝑑𝑎𝑟𝑑 𝐷𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛

Probability: P (|T| ≥ t) = X

 If X is >𝛼 = 0.05, accept the null hypothesis. In this case, there is no significant

difference whereas the Application GPS is similarly accurate to Google Maps.

 If X is <𝛼 = 0.05, reject the null hypothesis. In this case, there is a significant

difference whereas the Application GPS is inaccurate compared to Google Maps.

The Ho: μ1 = μ2 / Ha: μ1 ≠ μ2 row from the table determines if the result from various

computations yields no significant difference or a significant difference from the two

compared application.

37
3.1.2.4 App Startup Time Optimization

Users expect the apps to be responsive and fast to load. An app with a slow start time

doesn’t meet this expectation, and can be disappointing to users as this application heavily

relies on its quick responses when used. According to (Jeon) the creator of NimbleDroid (a an

automated, comprehensive analysis of an app's speed, memory usage, bandwidth

consumption, and more.) out of the 100 top apps, 40 start in under 2 seconds, and 60 start in

under 3 seconds.

App launch can take place in one of three states, each affecting how long it takes for

the app to become visible to the user: cold start, warm start, or hot start. In a cold start, the

app starts from scratch. In the other states, the system needs to bring the running app from the

background to the foreground. From (Android Developers, Online), recommend that it should

always optimize based on an assumption of a cold start. Doing so can improve the

performance of warm and hot starts, as well.

To optimize the app for fast startup, it’s useful to understand what’s happening at the

system and app levels, and how they interact, in each of these states.

 Cold start — a cold start refers to an app’s starting from scratch: the system’s

process has not, until this start, created the app’s process. Cold starts happen in

cases such as the app’s being launched for the first time since the device booted,

or since the system killed the app. This type of start presents the greatest

challenge in terms of minimizing startup time, because the system and app have

more work to do than in the other launch states.

 Hot start — a hot start of the application is much simpler and lower-overhead

than a cold start. In a hot start, all the system does is bringing the activity to the

38
 foreground. If all of the application’s activities are still resident in memory, then

the app can avoid having to repeat object initialization, layout inflation, and

rendering.

However, if some memory has been purged in response to memory

trimming events, such as onTrimMemory(), then those objects will need to be

recreated in response to the hot start event.

A hot start displays the same on-screen behavior as a cold start scenario:

The system process displays a blank screen until the app has finished rendering

the activity.

 Warm Start — a warm start encompasses some subset of the operations that take

place during a cold start; at the same time, it represents less overhead than a hot

start. There are many potential states that could be considered warm starts. For

instance:

 The user backs out of the app, but then re-launches it. The process may

have continued to run, but the app must recreate the activity from scratch

via a call to onCreate().

 The system evicts the app from memory, and then the user re-launches it.

The process and the activity need to be restarted, but the task can benefit

somewhat from the saved instance state bundle passed into onCreate().

To optimize startup time, the study considered the followings;

- Initialize only those objects that are immediately needed.

- Flatten the view hierarchy by reducing redundant or nested layouts.

39
 - Move all resource initialization so that the app can perform it lazily on a different

thread.

- Allow the app to load and display the views, and then later update visual properties

that are dependent on bitmaps and other resources.

The latest version Android Studio 3.2 provides tools for further optimization for

application development and this will be taken into account for better deployment of the app.

Contexts below are some of factors needed to be considered for better optimization of the

application as Android Studio provide these tools;

- Battery life — is a key concern for many phone users, and the app may

impact battery life more than you realize.

- System Trace — inspecting on how the app interacts with system

resources in fine-grained detail. Inspect exact timings and durations of the

thread states, visualize where CPU bottlenecks are across all cores, and

add custom trace events to analyze.

- Profiler Sessions — Profiler data is saved "sessions" to revisit and inspect

later while having Android Studio open. It the ability to import and export

CPU recordings and heap dumps for later analysis or inspection with other

tools.

- Automatic CPU recording —record CPU activity using the Debug API.

After the deployment of the app to a device, the profiler automatically

starts recording CPU activity when the app

calls startMethodTracing(String tracePath), and stops recording when the

app calls stopMethodTracing().

- JNI Reference Tracking — now allows you to inspect the memory

allocations of the JNI code in the Memory Profiler. As long as the app has

40
 been deployed to a device running Android OS, it can drill down into the

allocation call stack from the JNI reference. To use the feature, start a

memory profiler session, and select the JNI Heap from the Live Allocation

drop-down menu.

It is very important for the proposed application to give an impressive time for startup

as the user relies on quick response of the proposed application when used or launched.

After code and system optimization to improve the application startup time, the study

proceeds to test the startup time comparing the provided data of (Jeon). The researcher takes

the average of it which is;

The following is the formula for the average,

𝑆
𝐴𝑣𝑔. =
𝑁
2+3
𝐴𝑣𝑔. =
2
𝐴𝑣𝑔. = 2.5𝑠
Where;

𝐴𝑣𝑔. = 𝑎𝑣𝑒𝑟𝑎𝑔𝑒

𝑁 = 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑡𝑒𝑟𝑚𝑠

𝑆 = 𝑡ℎ𝑒 𝑠𝑢𝑚 𝑜𝑓 𝑡ℎ𝑒 𝑛𝑢𝑚𝑏𝑒𝑟𝑠 𝑖𝑛 𝑡ℎ𝑒 𝑠𝑒𝑡 𝑜𝑓 𝑖𝑛𝑡𝑒𝑟𝑒𝑠𝑡

41
Therefore; we take 2.5s as the optimal startup time for the application. The proceeding tests

are to determine if the proposed application meets the optimal startup time or not.

TESTS Proposed Application Optimal Startup Time

Startup Time

In 00s:00ms In 00s:00ms

TEST #1 x

TEST #2 x

TEST #3 x

TEST #4 x

… x

TEST #50 x

Average 2.5s

Standard 0.71
Deviation
Hypothesis if
μ1 - μ2 = 0 or
μ1 - μ2 < 0

In order to make a conclusion, the study used Two-Sample t-procedures: Pooled

Variances and perform the required hypothesis test using at the 5% level of significance.

The common standard deviation can be estimated by the pooled standard deviation;

(𝑛 − 1)𝑠 − (𝑛 − 1)𝑆
𝑆 =
𝑛 +𝑛 −2

The t-statistic is;

42
 𝑥 −𝑥
𝑡=
1 1
𝑠 +
𝑛 𝑛

With degrees of freedom equal to;

𝑑𝑓 = 𝑛 + 𝑛 − 2

Where;

𝑛 = 𝑠𝑎𝑚𝑝𝑙𝑒 𝑠𝑖𝑧𝑒 𝑓𝑟𝑜𝑚 𝑝𝑟𝑜𝑝𝑜𝑠𝑒𝑑 𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛

𝑛 = 𝑠𝑎𝑚𝑝𝑙𝑒 𝑠𝑖𝑧𝑒 𝑓𝑟𝑜𝑚 𝑜𝑝𝑡𝑖𝑚𝑎𝑙 𝑠𝑡𝑎𝑟𝑡𝑢𝑝 𝑡𝑖𝑚𝑒

𝑠 = 𝑠𝑡𝑎𝑛𝑑𝑎𝑟𝑑 𝑑𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛 𝑜𝑓 𝑝𝑟𝑜𝑝𝑜𝑠𝑒𝑑 𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛

𝑠 = 𝑠𝑡𝑎𝑛𝑑𝑎𝑟𝑑 𝑑𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛 𝑜𝑓 𝑜𝑝𝑡𝑖𝑚𝑎𝑙 𝑠𝑡𝑎𝑟𝑡𝑢𝑝 𝑡𝑖𝑚𝑒

To perform the test:

Hypotheses are;

Application is on par with the optimal startup time: 𝐻 : 𝜇 − 𝜇 = 0

Application launches in an impressive time rate: 𝐻 : 𝜇 − 𝜇 < 0

Let Significance level;

𝛼 = 0.05

Compute the t-statistic;

(𝑛 − 1)𝑠 − (𝑛 − 1)𝑆
𝑆 =
𝑛 +𝑛 −2

𝑥 −𝑥
𝑡=
1 1
𝑠 +
𝑛 𝑛

43
Critical value;

𝐶𝑟𝑖𝑡𝑖𝑐𝑎𝑙 𝑣𝑎𝑙𝑢𝑒 = −𝑡 = −𝑡 .

Degrees of freedom with left-tailed test;

𝑑𝑓 = 𝑛 + 𝑛 − 2 = 𝑋 − 𝑡 . = −𝑌

𝑅𝑒𝑗𝑒𝑐𝑡𝑖𝑜𝑛 𝑟𝑒𝑔𝑖𝑜𝑛 𝑡 ∗ < −𝑌

 If the value of the test statistic falls in the rejection region and decide

whether to reject 𝐻 .

44