California State University, Monterey Bay

KeepTrack

Capstone

Adam Irby

Lawrence Shea

Ryan Tashiro-Evans

Francois Tcha

October 13, 2019

 1

Executive Summary

KeepTrack is an Android application that gives users the ability to keep records of their

belongings in “the cloud” in place of keeping physical records of ownership. The goal is to

provide a tool for people to easily prove ownership in the unfortunate event that they get robbed

and have to file an insurance claim. The application’s back-end is web based in order to keep

persistent records across devices. Cloud storage brings some security concerns with it, but

usually smaller applications like to outsource their authentication since there’s significant

overhead involved in having truly secure authentication. That being said, security is not going to

be a primary concern given the time limit that we have for this project.

We started with a rough idea of what we would like to do and the technologies to use in

order to achieve our goals. There was really just over five weeks available for groups to develop

their applications since testing was to occur during week six. During week one, we began

creating mockups of the UI and design the database (the core piece of backend infrastructure). In

week 2 we finished all of our mockups and began work on actual software development. We

were not sure whether or not two weeks was enough time to learn and implement a new-to-us

technology, but we were able to develop quickly after learning the technology we chose.

Due to our time restraints, our group used a mixture of agile and plan and document

development methods. As mentioned earlier, we started by creating a rough plan of what needed

to be done and divvied up responsibilities based on what we come up with. As we developed

pieces, we met up to discuss the next steps and any issues that we faced. As we achieved our
 2

short term goals, we conducted thorough in-house testing before moving to the next . When we

had what we believed to be an acceptable end-product, handed it off to our testers to get outside

feedback and new perspectives.

The main goal of KeepTrack is to allow users to easily store and sort their possessions for

insurance reporting purposes. However, by the nature of the data that KeepTrack stores, it could

be very useful for organization and keeping track of the locations of specific items. For now,

digital proof of ownership is sufficient for an insurance claim. One of our concerns is people

making false insurance claims using our application as proof that they own something (that

they’ve never owned). We think that having a concise user agreement could alleviate many of

our legal and ethical concerns.

The group was excited at the opportunity to create a useful application for the general

public. In the process, we learned new technologies, but kept our focus on releasing a functional,

easy-to-use application-- not using fancy new libraries. We looked forward to the challenge of

integrating an Android front end with a web back-end since it’s something that none of us had

done before and learned a lot while accomplishing our goal.

 3

Table of Contents

Executive Summary 1

Table of Contents 3

Introduction 5

Goals and Objectives 6

Community and Stakeholders 8

Feasibility Discussion 9

Functional Decomposition 11

Selection of Design Criterion 13

Final Deliverables 14

Approach/Methodology 14

Legal Considerations 14

Ethical Considerations 15

Timeline 17

Budget 19

Usability Testing and Evaluation 19

Final Implementation 21

Discussion 26

Design Phase 26

Implementation Phase 27

Post Phase 28
 4

Conclusion 28

References 31

Appendix A 32

Appendix B 33

Survey Form 33

Survey Responses 34

Appendix C 35

Appendix D 37
 5

Introduction

KeepTrack is a home inventory application that allows for homeowners and

renters to catalog their belongings to “the cloud” using their Android phone. KeepTrack’s

backend infrastructure consists of a DigitalOcean “Droplet” in the interest of scalability and

accessibility on the part of users. The Droplet runs an Express server which leverages a restful

API to operate on mongoDB collections. The main goal of KeepTrack is to store user data and

generate reports for both private use as well as to simplify the process of proving ownership in

the case that a user must file an insurance claim.

Without digitization, keeping detailed records of all of your belongings in a way

that satisfies insurance company requirements for proof of ownership as well as the value of the

items requires a significant amount of space and time. The way that people currently keep track

of their belongings is by keeping receipts in a filing cabinet. This method requires one to have

both the physical space for a filing cabinet as well as the mental acuity and patience to do this for

all of their large purchases as well as to keep everything organized. In addition to the extra effort

that physical records require over digital ones, they can be compromised in the event of a break

in or a disaster like a fire or flood.

KeepTrack eliminates the need to keep physical records by providing a

convenient interface to both create digital records, and add them to a database with relevant

information including name, cost, quantity, date of purchase, location of purchase, as well as

images of the item itself and the receipt. The application will also provide a comprehensive
 6

tagging system to provide granular reporting by adding keywords to items so that they can easily

be sorted. Additionally, the tagging system allows for built in queries to provide users with

different types of home inventory information like total value of home inventory, as well as

various subsets of total home inventory like movie collection, tools, or electronics depending on

how detailed or complete a user would like to make their tags.

Nobody in our group, or people that we know keeps any sort of record of ownership. We

hope to solve this by removing the tedium of keeping physical records organized as well as the

need for physical space to store documents by digitizing them which also simultaneously

provides the benefits of reporting and accessibility since the information is stored on the cloud.

Goals and Objectives

Goal 1:​ Create an inventory application with an intuitive and elegant user interface to

display items, generate, reports and allow integration with insurance companies.

● Requirement gathering and analysis

● Design - Whiteboarding individual menus, pages and overall UI

● Implementation/Coding

● Testing - Test code against requirements to ensure the product function as

designed.
 7

● Deployment - verify that our back-end is highly available and everything

runs smoothly in production.

● Maintenance - Resolve issues that comes up after deployment.

Goal 2:​ Create back-end infrastructure that stores user information and allows users to

interact with their data from a mobile device.

● Determine our infrastructure needs such as database and web application

framework

● Research cloud web hosting offerings such as AWS, A2Hosting, and

Kamatera.

● Decide on a cloud web hosting solution

● Purchase cloud web hosting solution

● Determine web application framework for server side execution

● Design and implement a front-end for users to access and interact with the

infrastructure and their data from their personal Android Device.

Goal 3:​ Use a mixture of waterfall and agile (WaterScrum) development methodologies

in order to maximize efficiency (Malik, 2007).

 8

● Start with analysis of requirements, trying to be as exhaustive as possible,

include parts of behavior driven development for this planning stage, like

user stories.

● Sprints for design, implementation, and verification for each requirement,

checking back on our list of requirements after each sprint is complete.

Community and Stakeholders

KeepTrack is for anyone either paranoid, or that has been robbed/knows someone who’s

been robbed or experienced a disaster like a fire or flood; it is for anyone really. Dealing with

insurance immediately after getting robbed is not only frustrating, it’s the last thing that you want

to deal with after reporting to the police and getting your house back in order. Many people don’t

want to keep unnecessary paper around (receipts, owners manuals, credit card statements), and

with the extra reporting features that will be included, the application will be useful even if

someone is fortunate enough to not have to use it for insurance reporting.

Even if they do have documentation, the idea of making a comprehensive list of

belongings, finding either receipts or their retail prices is a huge task which is next to impossible

for the average person. Having an application that kept track of all of this would allow for a

streamlined process of proving ownership, and give the user peace of mind that if something as

unthinkable as a home break in happens they have the tools to deal with it while they focus on

what matters most, getting their home life back in order.

 9

Insurance companies are another stakeholder in the use of KeepTrack. A user with a

detailed home inventory who can provide an accurate report to their insurance of all that is

missing after a burglary or disaster has mitigated their risk as well as the amount of effort

required to file a claim. From the perspective of the insurance provider, this means larger

payouts would need to be granted, which is the opposite of what they want.

Feasibility Discussion

Another product similar to KeepTrack is Sortly. Sortly is a home inventory system that is

focused on organization as opposed to the insurance claim reporting. According to Sortly’s

website, “Sortly was born in 2012 as a passion project by our founder Dhanush, to empower

people to live a more organized life.” (About Us) Sortly has some neat features that wouldn’t be

so interesting for our projected user base, but are still worth mentioning. The free version of

Sortly includes up to 100 entries, one user license, one custom field, the ability to look up items

by barcode, in-application scanner, up to eight photos per item and custom notes and tags. On

top of the free version, Sortly offers two additional plans that includes more features at a cost,

ranging from $400 dollars to $1,200 dollars annually. The advanced and ultra plans are geared

towards multi-users and large companies. For example, some features included with the ultra

plans includes unlimited entries, 5 free user licenses, unlimited custom fields, attach files and

custom barcode labels.

The different subscription plans offered by Sortly with limited features and costly annual

fees could possibly turn away users. In our experience, paid applications are commonly shunned
 10

by regular private users. More often, they are used by businesses. It’s not because paid

applications are expensive. It seems to us that the reason consumers refuse to pay for phone

applications is due to an odd sense of entitlement that people have when it comes to phone

applications. Between the four of us (totaling over 40 combined years of cell phone ownership)

we purchased less than ten phone applications.

KeepTrack is taking a different approach by offering one plan with all features at zero

cost. The application to be accessible to anyone who has an Android device, allowing the

application to grow and spread while additional features and improvements are developed. The

decision to make this a zero cost application is to increase the success of the application.

According to LiquidState, offering the application for free is a key ingredient for success.

LiguidState states in an article that, “To increase the odds of consumers downloading your app,

make it free. Everyone likes to download apps for free; it gives them a chance to test out what

you have to offer without any risk. Nearly all apps allow users to download for free at first.

While simply making your app free won’t guarantee success, it can certainly increase the number

of people who will give your app a try. Thus, increasing the chances for your app to become

successful.” (Liquid-State, 2019)

While KeepTrack will offer the majority of features found on Sortly, the design approach

will be focused around home users and insurance claim reporting integration. This will remove

the need for different tiers and any corporate design overhead. It will limit KeepTrack user base

to one type of user, allowing for simpler design, implementation, management and support of the

application. All features will support the main feature which is insurance claim reporting. The
 11

insurance claim reporting feature will allow users to link their insurance policies to KeepTrack.

This feature will allow the application to build reports according to the insurance specifications

and requirements. According to TechTimes, “A successful app provides a single service. And it

provides it at the optimum level. When developing an app, develop one with a single feature

without multiple unnecessary interfaces. If the app must have other features, it must be

supporting the main goal of the app.” (Tech Times, 2019)

KeepTrack will use a mixture of waterfall and agile software engineering. Agile has been

proven to be successful in software development. ArtPlusMarketing stated that “Some of the

most well-known companies in the world use an Agile approach to improve their processes.

IBM, Cisco, Microsoft, AT&T — they all use an Agile approach (Matarelli, 2017).”

Functional Decomposition

In order to achieve our goal of creating an application in which data is not stored locally,

we decided on a client-server architecture with principles of model-view-controller architecture

mixed in. Part of the controller and the entire model is housed on “the cloud”. The front-end is an

Android application that serves as the other half of the controller and the view. The Android

application’s controller duties consist of making http requests to which our Express server

processes and interacts with a local instance of mongoDB. The results of operations performed

on the back-end are then displayed to the user by the Android application.
 12

Above is a rough diagram of how KeepTrack functions. Below is a small snippet of our API

documentation:
 13

Selection of Design Criterion

Since the goal of KeepTrack is to host user data inexpensively in “the cloud”, we knew

that we wanted to purchase computing resources since it removes tons of overhead. We started

by designing and building the back end since that is where the application’s critical functionality

lies. In order to build the back-end, we needed infrastructure to put it on. The obvious choice was

to purchase hosting since running a server out of a private residence is a pain and requires tons of

planning and energy.

Initially, we investigated the possibility of using Amazon Web Services, but decided that

AWS provided much more power and control that we needed for a proof of concept that we

could later deploy on something substantial rather than a single minimalist Linux server. Digital

Ocean provides excellent service and is relatively straightforward and inexpensive. We ended up

purchasing a “Droplet” that we installed and configured CentOS on.

This way, if and when we want to continuously deploy, all we need to do is automate the

configuration of our OS including all dependencies, and copy the application to other

deployments. The application is very light at only 22 megabytes including all Node

dependencies.

[​root@centos opt​]​# du -hd1 | grep Keep

22M ./​KeepTrack
 14

Final Deliverables

Our deliverables upon completion will be an application that allows a user to store data

(including images) about the items that they own, remotely, using their Android phone. All of

our source code and dependencies will be available on Github.

Approach/Methodology

For the remainder of the project, we will continue development and approaching tasks as

we have over the last several weeks, but with the addition of more extensive testing. On Monday

evenings, we compile the feedback from weekend testing. Most feedback comes in the form of a

simple questionnaire, but we urge our testers (unlucky coworkers...) to just email us if they come

across anything abnormal. On Wednesday nights we meet to discuss the results of last week’s

deliverables scheduled for early Saturday afternoon when we send out some directions and set

our testers loose again.

Legal Considerations

One of the primary concerns that we have with creating this application is the possibility

of lawsuits being filed against us for “not getting people their money back”. There’s a high

probability that even with a user agreement, people would try to sue us if their insurance
 15

company didn’t pay out an amount that they deem appropriate. Most likely, this sort of case

would be thrown out in court due to the user agreement but it could be a possible expense.

Another concern is a bit tin-foil-hat. If the application is successful in getting users larger

insurance payouts, it’s possible that insurance companies would lobby to change laws around

what constitutes proof of ownership to require physical documentation like an owners manual or

receipt. Even assuming there are no laws regarding what constitutes proof of ownership, it would

be up to individual insurance companies to determine what is valid proof, making it even easier

for them to not accept digital proof. This would render our app useless since it would force

people to go back to exactly the sort of record keeping that we are trying to eliminate.

The last legal (and ethical) concern we have is about user data security. In the case that

we had a data breach, we would be liable for any damages incurred. Stolen information could

assist thieves by providing detailed inventory at specific residence. Thieves will then be able to

determine and plan which houses to burglarize. For this reason, security is very important for this

application, considering the large amount of personal information it will be storing for each user.

To ensure we protect our data with the high level of security, we believe it’s wise to use cloud

storage such as Amazon or Google because they have very strong, reliable, and encrypted

security already established.

Ethical Considerations

In terms of ethical consideration on our part, we think that there is very little ethically

wrong with creating an application that allows people to easily document their belongings.
 16

Ideally, our application will help them out in the event that they need it. As far as we can tell, the

only group that would be negatively impacted by KeepTrack are home and renters insurance

companies. The reality is that being able to file a claim if you are burglarized is the whole reason

to have the insurance.

Insurance companies are essentially gambling that most people won’t have anything go

wrong, thereby collecting a check every month without having to render any sort of service. Like

most casino games, this bet is stacked in the houses favor-- in order to get compensated for a lost

item, you must prove ownership. As was previously mentioned, many people don’t keep any sort

of records for various reasons. KeepTrack stores all of your documentation digitally, giving

people better tools against “the house”. With proper records, in the somewhat rare case that an

insurance company process a claim, provided that it isn’t fraudulent it is their duty to pay out.

With KeepTrack, because the end users input their own information there is the

possibility of the users falsifying their own records. There is nothing we could really do as

developers to prevent this from happening. This would not be an issue as long as the user does

not use falsified information to file a false insurance claim. We would inform the user and

include what the application can and cannot be used for in the user agreement. If the user does

use falsified information to file a fraudulent insurance claim, the use will be violating the terms

of use of the product. This ethical consideration hugs the line between an ethical and legal issue

depending on how the application is used.

Finally, an ethical concern with anything that stores user data is the security of that data

and what that data can be used for. Not just security in the sense that the data cannot be stolen,

also the peace of mind that data won’t be sold or otherwise used for nefarious purposes. A
 17

comprehensive list of all the items that a household owns would be highly valuable to marketing

companies at the price of user privacy. Since we aren’t trying to monetize this application,

revenue streams aren’t something that we are particularly concerned about.

Timeline

As a whole, we did very well sticking to the schedule that we submitted in the beginning

of the course. Below is the schedule submitted.

Tasks
Gather user stories and requirements
Analysis user stories and requirements
Requirement Specification document
System and software design
Begin design database schema
Begin UI design of front end mobile application
Acquire cloud hosting environment and design development pipeline (git
environment etc)
Setup system and software on cloud hosting environment
Setup system and software environment on local hosts for coding and testing
Week 1
Complete UI design of front end mobile application
Complete database schema
Finalize system and software on cloud hosting environment
Finalize system and software environment on local hosts for coding and testing
Week 2
Implementation / Coding sprint
Week 3 Debugging
 18

Implementation / Coding sprint

Debugging/Testing
Week 4
Implementation / Coding sprint
Debugging/Testing
Week 5
Implementation / Coding sprint
Debugging/Testing
Week 6 Beta testing with focus group
Deployment software
Final Bug fixes
Final change requests
Final deployment
Week 7
Prep for presentation
Presentation

Week 8

While we met our minimum viable product, 3 weeks of coding wasn’t enough to

implement all of the features that we had planned. We believe that our two weeks of planning

was worth it in that we created an easy to deploy and scalable application, with using new

technologies both to us and in general. In our case, we found that the architecture that we used

required us to have the back-end almost completely done before even starting on the front-end
 19

Android application. Now that the core application is built and has been tested, we could

continue the software development lifecycle and add additional features in future updates.

Budget

We knew that the only budgetary requirement for our project was going to be for

whatever cloud hosting service we decide to implement, but we had no idea how much it would

cost. Our original budget was 100 dollars that we had agreed to split four ways if necessary.

After researching Amazon Web Services (AWS), we decided to go with DigitalOcean.

DigitalOcean only costs ten dollars per month, so we only ended up having to spend twenty

dollars for our cloud hosting.

Usability Testing and Evaluation

Our usability testing was done in house during the development phase. We concluded

that it would be best to start with the back-end since we could easily validate API functions using

tools like Compass and Postman. Once we were sure that the back end worked, we started adding

functionality to the activities in the Android application. We debugged the front-end by

monitoring Android Studio build log and reviewing the back-end service log. We then adjust the

front-end code to resolve any issues reported by the back-end and Android Studio. In this way,

we were able to provide our testers with an application that had already been tested extensively

during development.
 20

Our back-end consists of a restAPI written using the Express framework that performs

CRUD operations on a MongoDB database. Postman is an API client that allows users to send

requests and see responses. Compass is the official graphical user interface for MongoDB. As we

made changes to our code, we sent test requests using Postman and were able to verify that we

were getting the correct responses and make changes to the code if we weren’t. Having access to

testing tools like these made testing feature implementation quick and easy compared to what it

would have been if we were creating something totally custom rather than leveraging existing

technologies.

When our minimum viable product was complete, we got together some of our

significant others, friends, and coworkers (with Android phones) to test our application. We

provided each tester with a copy of the APK and provided them with a set of tasks to perform

over the course of a weekend. We also asked that each user participate in a survey after testing.

See ​Appendix B​ for a sample of our survey and some of the results. Below is a list of the tasks

and ​Appendix A​ includes an example of using spreadsheet to track the user’s comments.

1. Create a new user account and log in.

2. Add an item to your collection.

a. Take photos for the item and the receipt.

3. Add 50 items and fill out all fields

4. Verify details on a few items.

5. Delete an item

6. Run reports on your total inventory

 21

Our testers ended up pointing out a few points that we could improve on. The value in

having dedicated testers, not just the developers who know what they are building and how it’s

supposed to work, is that they have a totally different mindset about using the application. We

were just testing features as they were built, whereas they were taking a holistic approach. The

most important feedback that we got was regarding features that we as developers didn’t think

about since we were focused on just whether features that we had already made worked.

One of these features is the ability to edit an item with a typo. Our variety of testing

involved just sending JSON and making sure that the object showed up correctly on the

back-end. We weren’t carefully making actual entries about objects in our homes, so we didn’t

care if there were typos. The workaround for now is to delete the item and re-create it. The other

feature that we hadn’t implemented that is clearly very important for actual users is the ability to

view the “full sized” image of previously created items. We were so thrilled to get all of the

“mechanics” of taking pictures on the phone, sending those pictures to the server using an HTTP

post and getting it back, that we moved on without thinking about the rest of the interactions that

a user would need.

Final Implementation

Our final implementation consists of an Android application that uses the Volley library

to send HTTP requests and receive HTTP responses from the API that we created on the

back-end infrastructure. In this way, all user data is kept securely in the cloud where it can be

accessed from any Android phone. In order to realize the goal of storing information remotely,
 22

we decided on a client-server architecture. Rather than reinvent the wheel, we leveraged existing

frameworks to work together.

When describing the structure of the now functional application, it makes the most sense

to follow the order of operations that we used when creating the infrastructure and code. Before

we were able to start building our API, we needed to have infrastructure on which to build.

Initially, the plan was to use AWS as our cloud provider, but upon delving in, we learned that

Amazon Web Services was much more feature rich than our requirements. In the interest of

simplicity, we started researching other hosting services and ended up purchasing a “Droplet”

from DigitalOcean.

Our Droplet is running CentOS for stability purposes as well as the wealth of

documentation available due to CentOS’s relationship with Red Hat Enterprise Linux. The server

is the second lowest tier that DigitalOcean offers. This offer includes 50G of storage, 2G of

RAM, a single 2.3GHz processor and a public IP address. These resources are more than enough

for a proof of concept and to provide service to many concurrent users.

Configuration of the OS was fairly limited, but still time consuming. During our initial

research period, we selected MongoDB as our database since it’s “document oriented”, has good

integration with Node, and it was a technology that was interesting and new to us. In its current

iteration, we have a single database containing 3 collections: items, tags, and users. The items

and users tables are related by user name so that a user can only see their items. Below is the

item model used by our Express application:

 23

const​ mongoose ​=​ ​require​(​'mongoose'​);

const​ itemSchema ​=​ mongoose​.​Schema​({

userName​:​ ​String,

itemName​:​ ​String,

location​:​ ​{​type​:​ ​String​,​ ​default​:​ ​''​},

serial​:​ ​{​type​:​ ​String​,​ ​default​:​ ​''​},

price​:​ ​{​type​:​ ​Number​,​ ​default​:​ ​0.00​},

tags​:​ ​{​type​:​ ​[​String​],​ ​default​:​ ​[]},

img​:​ ​{​type​:​ ​String​,​ ​default​:​ ​null​},

receipt​:​ ​{​type​:​ ​String​,​ ​default​:​ ​null}

},​ ​{​ versionKey ​:​ ​false​});

module​.​exports ​=​ mongoose​.​model​(​'Items'​ ​,​ itemSchema​);

Mongoose is a Node package installed to allow interaction between Node and our

MongDB instances. The code above defines how an item’s JSON objects are formatted and what

information an item has. In order to utilize the model defined above, we had to create Express

“routes” to perform CRUD operations on our database. The item route describes all the actions

that can be performed on items including adding, removing, and displaying items. Each action

has defined HTTP responses for both a successful and a failed request. These responses are used

by the front-end.

//Remove an item by itemId

router​.​delete​(​'/items/id'​,​ ​(​req​,​ res​)​ ​=>​ {

if​(!​req​.​headers​.​hasOwnProperty​(​'id'​))

res​.​status​(​418​).​json​({​error​:​ ​"ID not specified"​});​ ​//Teapot :

Malformed Request

Item​.​findByIdAndDelete​(​req​.​headers​.​id)
 24

.​then​(​ doc ​=>​ {

updateTags​(​doc​.​userName​);

res​.​status​(​200​).​json​(​doc​);​ ​//Successfully Deleted

​})

​.​catch​(​ err ​=>​ {

res​.​status​(​500​).​json​({​error​:​ err​});​ ​//Internal Service Error

​});

});

Above is a straightforward example of a route defined for the item model. The logic

breaks down as follows:

1. Check whether or not the request contains an ID field

a. If it does, continue

b. If it does not, send a 418 response code and the error “ID not specified”

2. Call Item’s findByIdAndDelete function (provided by Mongoose) providing the selected

item’s ID as a parameter.

3. After removing the item, remove any other artifacts left behind by the item (updateTags)

and send HTTP response 200.

a. Otherwise, send HTTP response 500 (Internal Service Error)

These routes are called by the front end Android application, which serves as both a GUI and a

place to send HTTP requests from.

HTTP requests are handled on the front end using the Volley library that was developed

and introduced by Google in 2013 and it was part of the Android Open Source Project, but
 25

became a standalone library in 2017 (vartika02, 2019). Volley saved us from having to write the

logic for caching and processing network requests, which is a ton of intellectual overhead. Our

attitude with the development of KeepTrack, as previously mentioned was to practice learning

new tech, and leveraging existing tools to serve our needs. We believe that these will be

important skills during our future employment.

Since we knew that our API was functional based upon our tests and evaluation during

development, we knew that any issues we run into during front end development were isolated to

the Android application. What this means is that, we were able to write code based on

pre-existing guidelines. We were able to see the results of our GET and POSTs using Compass,

then once we had the expected response, make sure the output is displayed properly to the user.

Perhaps the most difficult thing to implement over the course development was dealing

with images. The ability to attach pictures to an item, display both of the items and as well as the

receipt, was a critical component of the application. There are several steps to the solution that

we came up with:

1. User takes an image during the creation of a new item record.

2. Bitmap image is converted to a base64 String so that it can be sent as part of a JSON

object and stored in the KeepTrack database on the server.

3. When the user views the details of an item, we need to do the reverse.

a. Get the JSON object from the server

b. Convert from a base64 string to a bitmap image

 26

In summary, KeepTrack consists of a back end Linux server running a Node Express

server and an instance of MongoDB. The Express application performs CRUD operations on the

MongoDB collection. Users interact with the Express server from the front-end Android

application. From their end, they can create an account, log in to an existing account, add items

to their collection, remove items from their collection, view existing items, and generate a report

based on all of their items.

Discussion

For the most part, the development of KeepTrack turned out better than we thought,

however it was not without hurdles. As a team we experienced problems throughout the design,

implementation and post phases. The majority of these problems were minor and we resolved

them quickly as a team or individually. There are a couple problems worth mentioning.

Design Phase

Our biggest challenge during the design phase was deciding which cloud service provider

to go with and implement. This requires researching pricing, features and compatibility with our

required software. Our original plan was to use Amazon Web Services but we quickly found out

that Amazon Web Services is quite complex to spec out pricing and too feature rich. After some

consideration of other cheaper and simpler cloud services such as DigitalOcean, Dreamhost and

Bluehost, we opted to go DigitalOcean. DigitalOcean made it easy for us to deploy a server from

their predefined templates.

 27

Implementation Phase

Our first major issue came up during the implementation phase when we started

configuring our server. After deploying the base CentOS image from DigitalOcean, we installed

all dependencies on the server and all was well, until a few days later when our user accounts

stopped working entirely. The original access method that we set up still worked for some

reason. This access still working made the issue with our personal accounts not working more

perplexing. Upon deploying the base CentOS image from DigitalOcean there were two options

for authentication: get a root password sent to you via email, or generate a key-pair and provide

the public key to DigitalOcean through the management console. The latter is much more secure

than using regular password authentication, so we opted for that.

Upon gaining access as root, we proceeded to set up personal user accounts and

associated key pairs for our personal accounts. We verified that everything worked and began to

focus on developing the API. About three days went by before our personal accounts stopped

working.

We logged in as root, and began to investigate. Fortunately we have plenty of Linux

experience and knew where to begin troubleshooting. All of our keys were still in place and no

configuration changes had been made, so we elected to view /var/log/secure to see if our

authentication attempts were even making it to the server. We ended up finding out that they

were, but more importantly, we found that our Droplet was being inundated with authentication
 28

attempts presumably by a botnet since the usernames were all common service accounts (admin,

Minecraft, arma3server).

Armed with this knowledge, we set out to remedy the absurd amount of login attempts.

We installed and configured a utility called Fail2Ban which automatically blacklists accounts

and IP addresses with too many login attempts within a given period. Fail2Ban fixed that issue,

but we were still unable to log in using our accounts. The eventual fix was to just remove our

accounts and reprovision them. We never figured out what happened or what the problem was,

but it was more important to patch the absurd amount of bad login attempts and to have personal

account access to the server.

Post Phase

As we continue to develop KeepTrack, we become more familiar with the programming

language and software it uses. In addition we understand more of the infrastructure it is running

on and the whole software development process; however, we are limited on time. While we met

our minimum viable product, it took every ounce of us to get this working for our testers and as a

finished product.

Conclusion

There are roughly more than 1.5 million home break ins every year in the United States

(Burglary crime statistics and facts). That might not seem like a big number but it happens more

often than we think and people tend to lose personal belongings. KeepTrack and other inventory
 29

application such as Sortly and Nestegg were designed to track personal belongings in the event

of theft.

We used a combination of waterfall and agile software engineering to develop

KeepTrack. The software development process went smoothly as it is a repetitive and easy

process to implement. The issues were within programming and the infrastructure itself. Not

having prior experience with developing an application from scratch and knowledge to required

software, makes developing an application challenging at the beginning. It takes quite a bit of

time to setup the environment, learn new syntax, methodology and available features and

options. We resolve these issues by building our infrastructure and back-end services first. Once

the environment is configured and running, everything starts to fall in place. Developing the

back-end service was key to developing a successful front-end, allowing software engineers to

develop and test against a solid foundation.

As we wrap up and deploy KeepTrack as a finished minimum viable product. We have

learned so much through it’s software development process such as project management,

developing a product from scratch, collaborating as a team and learning new technologies within

weeks. It was fun, challenging, exciting and exhausting at the same time but rewarding as we

reflect.

Our biggest take away was the required dreaded proposal document that was more than

20 pages long at the beginning. The document included everything needed for a project to be

approved by both internal and external stakeholders. It became a reference that helped the team

through the design and implementation phases. Without it we would have wasted time that we
 30

did not have. That dreaded proposal ended up being the project’s holy grail, guiding us as we

develop KeepTrack from scratch.

Collaboration within the team was easy and pleasant because of the relationship built

throughout the course of one plus year. We have developed a relationship amongst each other.

We also understand and know each other's weaknesses and strengths, allowing us to delegate

work ahead of schedule.

The thought of building an application such as Facebook crosses every Computer Science

major in this decade. When we first started this project we had no idea how our application will

look and how it will behave. With the limited amount of time, we developed a minimum viable

product for our testers to try out. There are endless possibilities with KeepTrack. Unfortunately,

we did not get a chance to build KeepTrack integration with insurance companies. This will

display insurance information, available insurance actions and one tap claim processing on one

screen. This integration will bridge our application with millions of users, inching closer to

Facebook status.
 31

References

15 Key Ingredients for a Successful Mobile App. (2019, July 19). Retrieved from

https://liquid-state.com/ingredients-successful-mobile-app/

About Us. (n.d.). Retrieved from https://www.sortly.com/about/

Burglary crime statistics and facts. (n.d.). Retrieved from

https://www.alarms.org/burglary-statistics/.

Matarelli, M. (2017, November 21). This Is Why Fortune 500 Companies Use An Agile

Approach To Process Improvement. Retrieved from

https://artplusmarketing.com/this-is-why-fortune-500-companies-use-an-agile-approach-t

o-process-improvement-d4095d410a61#targetText=Some of the most well,all use an

Agile approach.

Tech Times. (2019, May 3). What Makes An APP Successful? Retrieved from

https://www.techtimes.com/brandspin/242584/20190503/what-makes-an-app-successful.

htm

vartika02. (2019, August 8). Volley Library in Android. Retrieved from

https://www.geeksforgeeks.org/volley-library-in-android/.
 32

Appendix A

KeepTrack Evaluation Tasks

Name:

Task Comment
Create a new user account and
log in.
Add an item to your collection.
Take photos for the item and the
receipt.
Add 50 items and fill out all fields.
Verify details on a few items.
Delete an item
Run reports on your total
inventory
 33

Appendix B

Survey Form
 34

Survey Responses

The
Please The The instructions
provide application application Did you given to me Do you have any
your full is well is easy to complete the was easy to comments you
Timestamp name. designed. navigate. tasks? follow. would like to add?
I would liked to have
more instruction
regarding how to
2019-10-04 Melissa A. 2 4 Yes 5 run reports.
2019-10-04 Jesse L. 4 4 Yes 5
I wasn't able to edit
items after
mistyping the name.
This should be an
2019-10-05 Fidel T. 2 2 Yes 5 added feature.
 35

Appendix C

Role Matrix

Name Role Description Tasks

As Lead Database Engineer, Adam assisted in
designing, developing, building, analyzing,
evaluating and installing the database management
system, including database modeling and design,
database architecture, metadata and repository
creation and configuration management. Adam
evaluated size and selected technology
components, such as software, hardware, and
Lead Database networking capabilities for database management
Engineer systems and application databases.
As a Software Developer, Adam designed,
developed, implemented and tested software. He
used GitHub to access the project source code and
team collaboration on features such as bug Backend design and
tracking, feature requests and task management. implementation
Software He was involved in weekly team collaborations and Frontend design and
Adam Irby Developer peer code reviews throughout the project. implementation
As Project Manager, Lawrence defined the project’s
scope and determined available resources. He
planed realistic project deadlines by creating a clear
and concise plan to both carry out the project and
monitor the progress. He ensured project deadlines
were met on time by organizing and motivating the
team, using Scrum for effective team collaboration,
elaborate spreadsheets, virtual whiteboards.
Project Lawrence oversaw the DigitalOcean account in the
Manager early stages of development.
As a Software Developer, Lawrence closely worked
with the other developers. He used GitHub to
access the project source code and team
collaboration on features such as bug tracking, Project
feature requests and task management. He was documentations
Lawrence Software involved in weekly team collaborations and peer Backend
Shea Developer code reviews throughout the project. implementation
 36

As Lead Software Developer, Ryan acted as the

direct supervisor by managing and analyzing all
software developers’ workload, performance and
goals. He documented all software design and
implementation requirements. Ryan configured and
managed the project GitHub account, granting
access to software developers and setting up
repositories. He designed, implemented and
deployed a testing suite for the application and
worked closely with the Project Manager to create
and prioritize tasks for his team. He reviewed all
Ryan major milestone deadlines and verified all
Tashiro-Ev Lead Software milestones were completed as planned and Frontend design and
ans Developer, designed. implementation
As a Software Developer, Francois closely worked
under the direct supervision of the Lead Software
Developer. He developed, implemented and tested
software that he was assigned weekly. He used Project
GitHub to access the project source code and team documentations
collaboration on features such as bug tracking, Backend
feature requests and task management. He was implementation
Francois Software involved in weekly team collaborations and peer Frontend
Tcha Developer code reviews throughout the project. implementation
 37

Appendix D