KeepTrack

CST499
Francois Tcha
Adam Irby
Lawrence Shea
Ryan Tashiro-Evans
August 25, 2019
 1

Executive Summary

KeepTrack will be an Android application that will give users the ability to keep records
of their belongings in “the cloud” in place of keeping physical records of ownership. The goal is
to create 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 will be 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.

Currently, we have a road idea of what we would like to do and the technologies to use in
order to achieve our goals. There are really just over five weeks available for groups to develop
their applications since testing is supposed to occur during week six. During week one, we will
do mockups of the UI and design the database (the core piece of backend infrastructure). In week
2 we will finish all of our mockups and begin work on actual software development. We aren’t
sure whether or not two weeks is enough time to learn and implement a new-to-us technology.

Due to our time restraints, our group plans to use a mixture of agile and plan and
document development methods. As mentioned earlier, we will start by creating a rough plan of
what needs to be done and divvy up responsibilities based on what we come up with. As we
develop pieces, we will meet up to discuss the next steps and any issues that we currently face.
As we achieve our short term goals, we plan to do thorough in-house testing before moving to
the next . When we have what we believe to be an acceptable end-product, we will hand it off to
our testers for a week 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 is excited at the opportunity to create a useful application for the general
public. In the process, we would like to learn new technologies, but will keep our focus on
releasing a functional, easy-to-use application-- not using fancy new libraries. We look forward
to the challenge of integrating an Android front end with a web back-end since it’s something
that none of us have done before.
 2

Table of Contents

Introduction 3

Goals and Objectives 4

Environmental Scan/Literature Review 5

Stakeholders and Community 6

Approach and Methodology 7

Ethical Considerations 8

Legal Considerations 10

Project Scope 11

Final Deliverables 13

Usability Testing/Evaluation 14

Team Members 15

References 18

Appendix 19
 3

Introduction

KeepTrack is a home inventory management system for homeowners and renters to

catalog their belongings to “the cloud”. KeepTrack’s backend infrastructure will be hosted on

Amazon Web Services (AWS) in the interest of accessibility and reliability. The main goal of the

application is to store user data and generate reports for private use as well as filing an insurance

claim.

Keeping detailed records of all of your purchases in a way that satisfies insurance

company requirements to prove ownership and the value of items. The old method of record

keeping used by our parents to prove ownership is to keep receipts for big purchases and keep

them in a filing cabinet. This method requires a person to have both the physical space for a

filing cabinet, and the time and responsibility required to keep records up to date and organized.

Additionally, physical records can be compromised in the event of disasters such as a fire or

flood.

KeepTrack will eliminate the need to keep physical records by allowing users to digitize

their proof of ownership by creating database records with relevant information including name,

cost, quantity, date of purchase, location of purchase, and any images of the item itself and the

proof of purchase. The application will also provide a comprehensive “tagging system” to

increase the granularity and usefulness of reports. The tagging system will allow you to add

keywords to items in your home inventory so that they can be organized easily.
 4

KeepTrack will have built in queries to provide users with different types of home

inventory information. Things like, total value of home inventory, various subsets of total home

inventory like movie collection, tools, electronics depending on how detailed the user would like

to make their inventory tags.

Nobody in our group, or that members of our group know keeps really any sort of record

of ownership. We think the primary reasons for this are the tedium of keeping everything

organized and the space required to store the required documents. Digitizing your records

eliminates the need for physical space, and adds the benefit of being able to leverage fast

reporting and the accessibility afforded by cloud hosting.

Goals and Objectives

Goal - Use a mixture of waterfall and agile (WaterScrum) development methodologies in order

to maximize efficiency (Malik, 2007).

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

Goal - 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
 5

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

● Decide on a cloud web hosting solution

● Purchase cloud web hosting solution

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

infrastructure and their data from their personal Android Device.

Goal - Create an intuitive and elegant user interface to display reports and allow interaction with

the back-end.

● Determine web application framework such as node.js, Angular, etc

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

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

smoothly in production.

● Maintenance - Resolve issues that comes up after deployment.

Environmental Scan/Literature Review

We Google’d “home inventory” and one of the top results was this list of the 7 top home

inventory apps (Irby, 2019):

Sortly is a home inventory system more focused on organization of the home as opposed

to the insurance claim function. It allows for the user to add detailed records for your things
 6

including images, sku numbers, purchase date, serial number, etc, and export data as a .csv. This

level of detail would be necessary for the purpose of insurance reporting. Sortly has some other

neat features that wouldn’t be so interesting for our projected users, but are still worth

mentioning.

On the list, it suggests that this application is great for moving, you can print a QR code

to stick on boxes and inventory their contents. In practice, inventorying every individual item

that you pack would take too long to actually save you any time. However, for long term storage

of this sort of chronicling is clever.

NestEgg is another inventory system allows a user to scan a barcode to auto populate

fields. This is a feature that we’d like to research to see if it’s feasible to implement in the given

time frame. We found a relatively affordable API that we don’t have to be a business to use. One

of the stated goals for the application is the make data-entry efficient, but this may or may not be

feasible during our development cycle.

Lemonade is an application/company created for the purpose of selling insurance. It

makes homeowners/renters insurance easy to get, but doesn’t have the comprehensive inventory

system that we would like to create. This has the same basic link between insurance and

inventory, but focuses on the insurance side as opposed to the inventory side.

Stakeholders and Community

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
 7

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.

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

detailed home inventory who can provide and 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.

Approach and Methodology

Our approach will be to have an initial sprint in which we will define requirements based

on user stories, system design, and front end design. We will then be able to create tasks from

these requirements to create the application as a whole. This will require time spent

whiteboarding and documenting the results of whiteboarding sessions in order to have a point of

reference for overall progress. We will use Trello to plan sprints, prioritize tasks, and track the

progress of our project.

 8

After creating an exhaustive list of requirements and the general order of implementation,

we will start a cycle of designing, implementing, and testing features. In order to start the actual

coding, we will need to have our infrastructure laid out. Once there’s infrastructure, we can start

implementing features one at a time. In the beginning, we will need to design the database. After

that we can start creating methods for the user to interact with the database.

One of the biggest challenges that we are likely to face is finding a balance between

learning new, efficient technologies, and leveraging knowledge that we already have so that

implementation can be done quickly. For example, during the database design phase early on in

the planning process, we would like to research our options outside of what we know (relational

databases) and explore alternatives like noSQL databases. The questions that we need to answer

through our research:

● Does a noSQL database offer advantages for intended purpose?

● If it does, is it a viable option to learn and implement given our time constraints?

● If it’s determined that learning a new database structure is viable, will it integrate

easily with the rest of our infrastructure?

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.

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.

 9

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 this falsified information to file a false insurance claim, so we would need to make sure

that we include what the application can and cannot be used for in the user agreement. That way

if the user does use falsified information to file a fraudulent insurance claim they would be in

violation of 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

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.

 10

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

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 either way, it is a hassle and possible

expense.

Another concern is a bit tin-foil-hat. If our app was 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 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.

Lastly, related to our ethical concern about user data security, in the case that we had a

data breach, we would be liable for any damages incurred. Because of the large amount of

personal information we will be keeping for each user, security is very important for this

application. Stolen information could be used by thieves that would then have a detailed

inventory of different residences that can be used to determine which houses to burglarize. For

this reason, we think it’s wise to use cloud storage such as Amazon or Google because they have

very strong and reliable security already established. We are interested in features such as data

encryption to ensure data protection after a data breach.

 11

Project Scope

Timeline:

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

Implementation / Coding sprint

Debugging/Testing

Week 4
 12

Implementation / Coding sprint

Debugging/Testing

Week 5

Implementation / Coding sprint

Final Debugging/Testing

Week 6 Beta testing

Final change requests

Final deployment

Week 7

Prep for presentation

Presentation

Week 8

Budget:

● $50/month AWS and other expenses

Resources Needed:

● Android Studio

● Android Emulator

● Amazon Web Services

● Android Mobile Devices for Testing

● QA Testers

● MongoDB

● GitHub
 13

● Google Hangouts

Milestones:

● Finalizing DBMS selection

● Finalize schema design

● Complete front end application

● Implement testing suite

● Collecting and compiling user requirements and stories

Risks and Dependencies:

● Feature creeping

● Timeline miscalculation

● Effective team communication

● Gaining efficient understanding of underlying technologies required for this project

Final Deliverables

The main final deliverable for this project will be a fully working application. This fully working

application will be comprised of the following parts:

● Fully functional front end Android application that the end user interacts with

● Cloud hosted database to store all information for the end users account

On top of the fully working application, we will also be working on the following extra

deliverables during the development process:

 14

● Technical and Design Documentation

○ Access to live source code

○ Wireframes

○ Images such as app icons, logos and etc.

○ Thorough documentation on how to use application

● Capstone presentation

○ Powerpoint presentation

○ Live application for demoing

There are no official clients for this application, because of this we will have to determine when

the application is considered complete. We will be compiling user stories from different groups

of people by asking them what features they believe they would want in an application like

KeepTrack. We will be using these user stories to determine if we believe that KeepTrack would

meet user expectations and requirements for approval.

Usability Testing/Evaluation

Usability testing, in terms of agile development, is done at every step. We will do

thorough ‘in house’ testing on the deliverable at the end of every sprint before having QA testers

begin their testing. Any issues found in the testing will be recorded as ‘bug cases’ and corrected

in a timely manner before moving on to the next sprint. For any bugs we find, we will have a

generic Google Form that will be submitted explaining where in the application the issue was

located with thorough duplication steps for us, as developers, to follow. Below is a screenshot of

the bug report all the testers will fill out:

 15

Each week we will be looking at the bug reports and testing them to make sure the issue is

duplicatable. If it is it will be added to out GitHub project at an ‘issue’. This way we will all be

able to track these issues to ensure they are corrected in a timely manner.

On top of bug case corrections, we will be meeting each week to compare the application

with the user stores collected previously to ensure we are staying on target with the intended

outcome of the project. Having a testing and evaluation meetings during every cycle will help

ensure a properly working and viable application at the end of the development period. We will

be meeting up with testers to do live testing sessions in case there are any issues that may not

otherwise be reported-- things like UI design choices or unclear workflows.

Team Members

Adam Irby
 16

As Lead Database Engineer, Adam will assist 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 will evaluate size and select technology components, such as software,

hardware, and networking capabilities for database management systems and application

databases.

As a Software Developer, Adam will design, develop, implement and test software. He will use

GitHub to access the project source code and team collaboration on features such as bug

tracking, feature requests and task management. He be involved in weekly team collaborations

and peer code reviews throughout the project.

Lawrence Shea

As Project Manager, Lawrence will define the project’s scope and determine available

resources. He will plan realistic project deadlines by creating a clear and concise plan to both

carry out the project and monitor the progress. He will ensure project deadlines are met on time

by organizing and motivating the team, using Scrum for effective team collaboration, elaborate

spreadsheets, virtual whiteboards and possibly implement Trello for task prioritization. Lawrence

will oversee the AWS account in the early stages of development.

As a Software Developer, Lawrence will closely work with the other developers. He will

use GitHub to access the project source code and team collaboration on features such as bug

tracking, feature requests and task management. He be involved in weekly team collaborations

and peer code reviews throughout the project.

 17

Ryan Tashiro-Evans

As Lead Software Developer, Ryan will act as the direct supervisor by managing and

analysing all software developers’ workload, performance and goals. He will document all

software design and implementation requirements. Ryan will configure and manage the project

GitHub account, granting access to software developers, setting up repositories and possibly

setting up Travis CI, a hosted, distributed continuous integration service used to build and test

projects hosted at GitHub. He will design, implement and deploy a testing suite for the

application and will work closely with the Project Manager to create and prioritize tasks for his

team. He will review all major milestone deadlines and verify all milestones are completed as

planned and designed.

Francois Tcha

As a Software Developer, Francois will closely work under the direct supervision of the

Lead Software Developer. He will develop, implement and test software that he is assigned

weekly. He will use GitHub to access the project source code and team collaboration on features

such as bug tracking, feature requests and task management. He be involved in weekly team

collaborations and peer code reviews throughout the project.

 18

References

Irby, L. (2019, June 25). The 7 Best Home Inventory Apps of 2019. Retrieved from

www.thebalance.com/best-home-inventory-apps-4171940.

Malik, N. (2007, June 4) Waterscrum vs. Scrummerfall. Retrieved from

blogs.msdn.microsoft.com/nickmalik/2007/06/04/waterscrum-vs-scrummerfall/.
 19

Appendix

Testing Feedback Form