Project Plan
Team 7: Construction Inventory Management
Mark Anderson, Andrew Chrapko, Robb Glasser, Javid Habibi, Lydia Hlebasko*, Chris Nuland,
Ethan Tyink
*Team Leader
Purpose
Project Purpose:
On construction sites, there is a large quantity of inventory items coming onto the premises.
Each item must be thoroughly logged and then sent to a location within the construction site
for workers to access and use. Currently this is a tedious and cumbersome process as
construction managers must lug around bulky laptops and massive amounts of paperwork on
the construction site. Our mobile application is designed to solve this problem by maintaining
an inventory database and creating a front-end client for accessing this database.
Document Purpose:
The purpose of this document is to sort the functional requirements (found in our Design
Document) into three different build stages as well as determining how long each task will take.
The document is structured into the following sections: Background Information, Team
Structure, Subsystems, Planned Releases and Tasks, Cost Estimates, Schedule and Milestones.
The background information section will detail the current status of the project. The section
will also describe the previous stages this project has gone through; including the
brainstorming, design requirements, and the design document. If you would like more
information about the previous stages this project has gone through, please see the
Requirements Document and the Design Document.
The next section provides a description and graphic of the team structure. The team is divided
into three smaller groups that will focus on different aspects of the application. This is
necessary as our team is so large and will facilitate the development process.
The remaining sections deal with the components of the system and the estimated costs to
complete the project. The 'Subsystem' section will detail the different components required for
the three subgroups: Front-End, Map, and Back-End. Following the 'Subsystem' section is the
'Risks and Challenges' sections which details risks and challenges that we foresee might be an
issue. For each issue, there is a solution listed. Granted, we cannot foresee every issue that will
befall us during the development of this application; but by compiling a list of issues that we
can see, this will hopefully lead to a quick resolution of the issues as we will be able to
anticipate those issues, as opposed to being caught off guard.
The next section, Planned Releases and Tasks, is divided up into three build cycles detailing
what will be completed for each cycle. Each cycle is divided up into the three subgroups (FrontEnd, Map, and Back-End), and each subgroup is divided up into components and the tasks to
complete for each section. Each task has an estimated time cost structured as follows
(optimistic, average, and pessimistic). This is our estimation of how long each task will take. A
note between 'Build 1' and 'Build 2'; there are some components that are listed for each build;
however, different functionality will be provided for each build (i.e. the user interface is
completed for the first build, and the database in then linked for the second build).
Though there is a cost estimate listed next to each of the tasks in the 'Planned Releases and
Tasks' section; this format does not lend well to a big picture understanding of how long it will
take to develop the application. The section, 'Cost Estimates', will solve this issue by displaying
the tasks and their cost estimates in a table format. The cost estimates will then be summed up
for Builds 1, 2, and 3 and then for the entire project. The section following is the 'Schedule and
Milestones' which includes a Gantt Chart to visually display how long tasks will take to complete
and when they need to be completed by.
Background Information
The project has already completed several phases of the design and development process.
These completed phases include: several iterations of brainstorming, Problem Statement
document, Design Requirements Document, and the Design Document. The problem
statement that we created is essentially the same as the 'Project Purpose' above.
In the design requirements document, we determined all of the different features that our
project partner is looking for in the application. The design requirements include, but are not
limited to, barcode scanning, locating an inventory item, and adding an inventory item to a
database. For the exact design requirements please see either the 'Design Requirements'
document or look at the 'Planned Releases and Task' section below.
The Design Document gives a high-level overview of the specification of our system. The
document outlines the design of the system, the relational database models, the class models,
the activity diagrams, and some user interface mockups. For more information about the
design of this application please refer to the 'Design Document'.
The application will not be publically available to the Android Market; rather instead it will be
included in an enterprise package targeted towards construction management. Currently
inventory items are logged on a bulky laptop or paper methods; both of these methods are
awkward and inefficient on a busy construction site. This application will provide portability
and real time inventory database for site managers to use and access.
Team Structure
We will be following the Chief Programmer structure for our team. There will be three smaller
subgroups that will be focusing on their parts of the application, and then they will report to
the team leader and demonstrate what they have completed. This is the best way to break
down a large group, as it is much easier to coordinate the schedule of two to three people than
coordinate meeting times for seven people. The hierarchy of the team is not strict as team
members are encouraged to ask questions of each other (regardless of subgroup assignment).
Lydia Hlebasko
Team Leader
Ethan Tyink
Subgroup Leader
Robb Glasser
Subgroup Leader
Chris Nuland
Subgroup Leader
Map Subgroup
Lydia Hlebasko
Group Member
Mark Anderson
Group Member
Andrew Chrapko
Group Member
Javid Habibi
Group Member
Front-End Subgroup
Andrew Chrapko
Group Member
Back-End Subgroup
Will be assisting both groups
Subsystems
List of Subsystems
Front-End Components:
1. Inventory
1.1. Add Inventory Item

There will be a form presented where a user can add an inventory item to the
system.
1.2. Delete Inventory Item

There will be a confirmation box that pops up for the user to confirm the deletion
of the item.
1.3. Lookup Inventory Item

This is where a user can look up the specification sheet for an item, this is different
than the "Locate Inventory Item" below.
1.4. Locate Inventory Item

This tells the user where the item is located on the construction site. It includes a
map with a "You are here" icon as well as "Item is here" icon. Also included is a
compass arrow always pointing where the item is located; an image of the
inventory item; and a description of the item.
2. Display
2.1. Feeds for Maintenance and Lost Inventory Items

There will be two RSS feeds; one displaying active maintenance requests, and the
other displaying lost inventory reports. These feeds will be displayed on the main
screen of the application.
2.2. Preferences

This is like a settings page where the user can come in and change basic setting for
the application. The primary setting that they can change is the worksite. They
will be able to select from a dropdown list the worksite they would like to view.
2.3. Tablet's Current GPS

There will be a small area on the main screen that displays the current GPS location
of the Tablet. If the user is on the construction site, a pin will be shown on the
overview map on the main screen denoting where the user is located on the site.
Otherwise, if the user is not on the construction site, his/her location pin will not
show up on the overview map.
3. Export to Excel
3.1. The inventory database will be exported using Comma Separated Values that can later
be imported into a Spreadsheet application (like Excel).
4. Barcode Scanning
4.1. This is where the user has the option of scanning the barcode to obtain information
about an item. The information can either be used to populate the fields on the "Add
Item" page, or the information can be used to look up the specification sheet for an
item.
5. Calendars
5.1. This is detailed view of the maintenance request and lost forms. The user will be able
to select a calendar grid display, or a list display that will order the maintenance
requests by date so that the user has a visual idea of when things are due in relation to
other items.
6. Maintenance Request and Lost Forms
6.1. This is a form that a user can fill out for either a maintenance request or to submit a
lost report. There is one form that is used for both of these as there is a checkbox to
denote if it is a lost report or a maintenance request. If the "Item is Lost" box is
checked, the other fields used for the maintenance request will be dimmed.
Map Functionality:
1. Display map using Google APIs
1.1. The map of the site will be displayed. Using the predefined GPS location of the site, the
map will be centered on the site. An appropriate zoom level will also have been
predetermined for the site so that things fit together.
1.2. A marker showing the tablet’s location will be displayed on the map as well as a circle
detailing the current level of accuracy of the GPS.
2. Display an arrow pointing to the location of an item
2.1. An arrow will be displayed in the corner of the screen pointing to the location of an
item the user has selected. It will rotate as necessary as the user walks around the job
site.
3. Ability to search for an item
3.1. User will be able to search for items using a search box located on the screen. Items
found will be displayed on the map.
4. Ability to filter the list of items displayed
4.1. There will be an option that allows a user to select filters of different item types. This
way, when a search is done, certain item types can be ignored.
5. Map Overlay of job site schematic (maybe)
5.1. If time allows, allow for an image of the site schematic to be layered on top of the map.
6. Drop pins on the map displaying item locations
6.1. When items have been searched for, pins will be dropped on the map detailing where
an item actually is.
6.2. Selecting a pin will bring up a speech bubble type thing detailing some information
about the item.
7. Navigation to job site.
7.1. If a user has the tablet, but does not know how to get to the job site, Google’s
navigation will be launched detailing how to get from the user’s current position to the
job site.
Back-End Functionality:
1. Server
1.1. 64 bit Intel Xeon x5570 2.93gHz 2 core processor
2.
3.
4.
5.
6.
7.
8.
1.2. 4 GB ram
1.3. DNS Domain: rebar.ecn.purdue.edu
1.4. Schema: inventory
1.5. UserName: cnuland
1.6. Password: Contact admin for password
Server Software
2.1. Windows Server 2008
2.2. MySQL Database
2.3. Apache server handler
2.4. MySQL Administrator
Client Application Initiation
3.1. JDBC Library (Java Database Connectivity)
3.2. MySQL Driver for JDBC
3.3. Check credentials for server
3.4. TCP/IP connection with server
3.5. Initialize Database connection
3.6. Error Handling for database
3.7. Connection Check (If in online mode or offline mode)
3.8. Check inventory cache
3.9. Create/Check History for offline mode
3.10. First instance of Update/Sync database inventory
3.11. Check database for conflicts update/syncing
3.12. Prompt user with conflicts & errors
3.13. Initialize the cache structure for Inventory and Maintenance
Client Application Background Process
4.1. Loop back end process every 2 minutes
4.2. Check for connection
4.3. Sync database with current list of inventory
4.4. If connection reestablished, update inventory list
4.5. If online mode, check for new items in cache and upload to database
4.6. Cache Optimization
Client Application Inventory List
5.1. Upload inventory list from DB and load it in the cache (if in online mode)
5.2. Load items from queue (if in offline mode)
5.3. Load items from history (if in offline mode)
Client Add/Remove/Edit
6.1. Add new item to the cache
6.2. Add remove call to cache
Maintenance Request
7.1. Add maintenance to an individual inventory object
7.2. Remove maintenance from inventory
7.3. Edit maintenance from inventory
Maintenance Thread
8.1. Check maintenance requests every minute from cache and inventory history
8.2. Add to maintenance notification feed list if relevant
8.3. Clear irrelevant maintenance
9. Application Closure
9.1. Save cache
9.2. Save history of DB.
9.3. Close Connection (if open)
Risks and Challenges
General Functionality:
1. Barcode Scanner
1.1. Issue: Returns wrong item after scan.

Solution: Present the user with the details returned from the scan and options to
use or discard the information.

If the user discards the information, they can either rescan or just go straight to the
form to fill in the information.
1.2. Issue: Google Goggles may not integrate with our application.

Solution: Instead of using Google Goggles, even though it is more reliable, use
another (maybe slightly less reliable) barcode scanning application that will work
with our application.
2. Preferences
2.1. Issue: Saving the user's preferences to the phone in the correct format.

Solution: Look up on reliable forums, such as Stackoverflow, as well as the Android
Developer resources to figure out how others have resolved the issue.
3. Export to Excel
3.1. Issue: Packaging the data in the correct format using CSV.

Solution: Run a couple of smaller sets of data until the format is correct. Then test
on a large amount of data. Double check the CSV documentation.
4. Interacting with the Database
4.1. Issue: There is an unhandled error from the backend code that surfaces to the front
end methods

Solution: Surround each call to the back end code with a try/catch block that will
let the user know that error occurred and to retry the action at a later time. A
buffer will also be used so that unsaved data does not get lost.
5. Calendar
5.1. Issue: Since there is no preset calendar layout for Android, we will have to design our
own. This could lead to some issues with getting the layout to work correctly in
different orientations.

Solution: A simple solution would be to lock the screen orientation. This reduces
the chances that the layout will break if the screen is rotated. Though this may
provide an inconvenience to the user; it is more important that the layout does not
break.
Map Functionality:
1. GPS
1.1. Issue: GPS Location may not be very precise when placing an item

Solution: Add a radius of error to the GPS location. Also allow a text description
telling where the item is located.
2. Loss of Service:
2.1. Issue: Tablet may lose internet access and connection to Google maps

Solution: Add a radius of error to the GPS location. Also allow a text description
telling where the item is located.
Back-End Functionality:
1. Server
1.1. Issue: More than one server will need to be deployed to handle application.

Solution: Keep good documentation on server specs and keep a copy of the
database schema.
2. Database Conflicts
2.1. Issues:
a)
Conflict arises when one user removes an inventory from his local copy, then
another user edits that same inventory on his local copy. When both try to
upload their changes to the server a conflict in the database will arise.
b)
Conflict arises when a user is trying to add an item that already exists. This
can happen when two users are in offline mode and both add an item that
neither knew the other did.
c)
Conflict arises when two users edit an item from their local copy offline and
both try to make changes to the server.

Solution: Check for conflicts when you upload each local inventory item. When the
conflict is detected, prompt the user with a few options. The user can override (his
entry takes the spot in the server), ignore (his entry is not uploaded), or wait. If the
user waits, then this item is flagged on his local copy in the inventory list. Allowing
the user to know there is a conflict with this item and it needs to be resolved. Also,
the conflict will be logged in the maintenance log.
2.2. Issue: Conflict arises when a user tries to remove an inventory that has already been
removed.

Solution: Ignore the remove, as the item no longer exists.
3. Local Copy of Database
3.1. If the inventory data on the database is incomplete or NULL.

Solution: Ignore the item
4. Communicating with the Server
4.1. Issue: Server not found (in online mode)

Solution: Notify the user that the database connection was not found and to
contact the server administrator
4.2. Issue: Server not found (in offline mode)

Solution: Store everything in a local copy of the database and also have a cache of
items that have been worked on during offline mode. Then when online mode
detected, upload results to database (see conflict handling above)
5. Initiation
5.1. Issue: If in offline mode, how do you handle user login.

Solution: Ask the user for credentials when they are uploading when they go back
to online mode.
5.2. Issue: If the user password and user name do not match (online mode)

Solution: Prompt user then allow them to retry
Planned Releases and Tasks
Time Costs are in units of 1 hour structured as (optimistic, average, pessimistic).
There will be a table following the tasks displaying the time estimates for optimistic, average,
and pessimistic.
Build 1:
General Functionality:
1. Add Inventory Item (UI no db) ( .5 / .75 / 1 )
1.1. Button press for "Add Item".
1.2. Request displays multiple fields for "Item Name", "Item Description", "Item Location".
1.3. Text fields open keyboard when highlighted.
1.4. "Click to take picture" and opens camera to take a photo of the item.
1.5. There is a barcode scanner button in the corner that will attempt an autofill in the
form.
1.6. The save and cancel buttons are located at bottom of entry window.
1.7. Upon saving, the user is presented with a notification telling them if the submission
was a success or failure according to database.
2. Delete Inventory Item (UI no db) ( .5 / .75 / 1 )
2.1. Button press for "remove item".
2.2. Request displays text "Enter item name".
2.3. Text entry opens a keyboard when selected.
2.4. Similar button for barcode scanning as in the "Add item".
2.5. Search and Cancel buttons at the bottom of the window.
2.6. Search displays all similar results or "No results found" type message.
2.7. Upon selection the user is prompted to finalize the removal.
3. Lookup Inventory Item (UI no db) ( 1 / 1.75 / 2.5 )
3.1. Called from search, or removal of item type requests.
3.2. If one there is only one item searched, a window opens to a thumbnail of the item on
the left, and Name, Description, Location etc... to the right.
3.3. If multiple items are returned, a list of all results opens, and selection of 1 opens an
individual display. ‘Back’ and ‘Select’ type buttons at the bottom of the window for an
individual result. The content will be handled by a list of inventory items handled by the
back end database.
4. Barcode Scanner ( 2 / 5 / 8 )
4.1. Use Google Goggles ( 1 / 1.5 / 2 )

If this does not work then use a normal barcode scanner.
4.2. Barcode scanner able to be called during add, remove, and lookup. Calls implemented
barcode scanner app and possibly displays result from the scan. Confirm and Reject
buttons at bottom of the window for user to decide.
5. Preferences ( 1 / 2 / 4)
5.1. Preferences opens window with drop down selector for work sites.
6. Calendar (UI Layout, no database) ( 1.5 / 2.75 / 4 )
6.1. Layout with selectable days, viewed as 31 day month. Indicates current date by
highlighting it. Arrows at the top allow scrolling between months.
7. Maintenance Request and Lost Item Form ( .5 / 1 / 1.5 )
7.1. Fill in and package data.
8. Display tablet’s current GPS location ( .5 / .75 / 1 )
8.1. In home screen, GPS coordinates displayed in top corner
9. Develop Test Cases ( .5/ .75 / 1 )
9.1. Test adding, removing, and searching for items and the results returned when
presented with success and failures.
Map Functionality:
1. Display map ( 1 / 2 / 3 )
1.1. Displays the base map of the location on the screen centered at the job site.
1.2. This will also involve writing a custom map view to be able to later support additional
map functionality as described in later sections.
2. Display arrow ( 1 / 2 / 4 )
2.1. Displays an arrow pointing you to the location of an item you have selected. The arrow
dynamically rotates like a compass as you walk around the job site. For this build, the
arrow will be a solid line.
3. Search for an item ( 2 / 3 / 4 )
3.1. Have a search box that allows a user to search for a particular item.
3.2. Items found are displayed on the map marked with pins (Goes along with #4 dropping
pins).
4. Dropping pins ( 1 / 2 / 3 )
4.1. Drop pins on the map based on the GPS coordinates of the items.
4.2. As items are searched for, the pins appearing on the map will be updated.
5. Adding info to pin selection ( 1 / 1.5 / 2 )
5.1. Selecting a pin will bring up item information in a speech bubble type format. This will
allow to show item information.
Back-End Functionality:
1. Setup WAMP (Windows/Apache/MySQL/PHP5) ( .5 / 1 / 1.5 )
1.1. Proper setup of third-party dependencies on the server machine and documentation
for future users about how to do the same.
2. Make the database and tables using MySQL administrator ( 1 / 2 / 3 )
2.1. Configure the database on the server machine and write the necessary code to
replicate the database on another, similarly-setup machine.
3. Add JDBC library to program ( .25 / .5 / 1 )
3.1. Configure the development environment of the client to properly communicate with
SQL.
4. Configure code to connect to our server ( .5 / 1 / 1.5 )
4.1. Write client code to initialize a connection to our database.
5. Query inventory based on credentials ( 1 / 2 / 3 )
5.1. Write client code to check credentials from the database.
6. Error Handling ( 2 / 4 / 6 )
6.1. Basic checks to see if connection is established, to be used anywhere else in code.
6.2. Basic checks to see if tables exist and are well formed.
6.3. When uploading, basic check for existence of inventory.
6.4. When uploading, basic check for successful upload.
7. Add function to pull from DB for inventory list ( 1 / 2 / 3 )
7.1. Code to pull inventory item from DB
8. Transform the query into an object usable by the front end group
9. Add function to pull from DB for maintenance (.5 / 1 / 1.5 )
9.1. Code to pull maintenance schedule item from DB
9.2. Transform the query into an object usable by the front end group(for the maintenance
feed, etc.)
10. Add function to send inventory to DB ( 1 / 2 / 4 )
10.1. Send an item to the server-side database
11. Add function to send maintenance to DB ( .5 / 1 / 2 )
11.1. Send a maintenance request item to the server-side database
Build 2:
General Functionality:
1. Add item (with database) ( 1 / 1.75 / 2 )
1.1. This will actually add the item to the database. Previously, the screen just collected the
new item's data. Now it will actually be submitted to the database.
2. Inventory Item Display (with database ) ( .5 / .75 / 1 )
2.1. Display of inventory item, pulled from the database. It will display name, description,
location and an image of the particular item.
3. Calendar (with database) ( 1 / 2 / 3 )
3.1. Display of maintenance requests by day that are pulled from the database and placed
in their corresponding time slot.
4. Export to Excel ( 2 / 3 / 5 )
4.1. A button at the main screen for a site, when clicked, it will export the database to an
excel document for printing or reviewing on a terminal. The user will be prompted with
a box requesting an email address for where to send the excel spreadsheet.
5. Maintenance and Lost Request Feeds ( .5 / .75 / 1 )
5.1. On the main display, a box of upcoming maintenance requests or new notifications of
lost items will be displayed for ease of use. When each of these is clicked, a window will
come up displaying more information on the request or lost item.
6. Maintenance Request ( ship data off) ( .5 / 1 / 1.5 )
6.1. The final touches for submitting a maintenance request, a submit button will be added
to the bottom of the window which will push the data to the database for later
querying.
7. Locate inventory item (plugin map fragments) ( 4 / 4.25 / 4.5 )
7.1. Queries the database for relevant information on an item and displays it for the user to
see, with all the following components.
7.2. Mini Map ( .5 / .75 / 1 )
7.2.1. A scaled down model of the map showing the location of the specific item.
7.3. Compass Arrow ( .5 / .75 / 1)
7.3.1. A directional compass that points to the item queried and will guide the user to
the correct position.
7.4. Item Image ( .5 / 1 / 1.5 )
7.4.1. An image of the inventory item that can be used for reference by the user.
7.5. Item Description ( .5 / .75 / 1 )
7.5.1. A brief description of the item pulled from the database.
8. Develop Test Cases ( 2 / 3.5 / 5 )
8.1. Different scenarios with different data to use for testing of the excel export feature,
making sure the database is being queried and posted to correctly and in an efficient
manner. Also simply tampering with the different aspects of the UI to see if any input
will cause bad output, testing the boundary cases.
Map Functionality:
1. Display arrow ( 1 / 2 / 4 )
1.1. Replace the line with an actual, graphical arrow.
2. Search for an item ( 2 / 3 / 4 )
2.1. Improve search algorithm.
2.2. Dynamically update a list of items as the user types.
3. Filtering item search ( 1 / 2.5 / 5 )
3.1. Allow a user to filter different types of items from the search via a selection of check
boxes.
3.2. The check boxes will dynamically appear/disappear depending on what item types are
available.
4. Adding info to pin selection ( 1 / 2 / 4 )
4.1. When a pin is selected, a speech bubble will appear with information about the
selected item.
4.2. Information will include picture (if available) and other available info.
5. Navigation ( 1 / 2 / 3 )
5.1. When a user is off site, they will be able to use the navigation tool (built into Google
maps) to direct them to the job site.
5.2. An option will be available to launch the navigation tool built into the device, which
takes the tablet’s current location and the location of the job site, and then spits out
navigation directions.
Back-End Functionality:
1. Create local copy of data base (for offline mode) ( 4 / 6 / 8 )
1.1. Pulls only inventory from the server when online. Only copies information relevant to
the current site that the client tablet is on.
1.2. This allows application functionality while offline - instead of reading from the server,
information is now read from the local copy.
2. Change the inventory list so it pulls from local copy ( 1 / 2 / 3 )
2.1. Inventory List was pulling straight from database. Now it will pull from the local copy.
This is done to prevent data loss in case the server connection is dropped.
3. Create cache structure ( 4 / 6 / 8 )
3.1. Holds items that have been changed, removed, or added so that sync can be made
once online. The cache structure prevents checking the entire local copy against the
database.
4. Back Threads ( 2 / 4 / 6 )
4.1. Run every two minutes, or as performance permits, to update content or check for new
material.
4.2. Check for connection to server.
4.3. Sync information of local copy when connected to the server.
4.4. Push any information from the cache to the server when connected.
4.5. Update the maintenance feed of the homepage based on the contents of the local copy
(if offline) or server database (if online).
5. Conflict Handling ( 5 / 10 / 20 )
5.1. When pushing the cache to database, check to make sure that the data is consistent.
Prompt the user if for whatever reason there is a conflict that cannot be resolved
automatically.
5.2. Program the different scenarios of non-automatic conflict resolution into the
application. These situation are not resolved on the database level and have to be
resolved by the application itself.

Editing an item that has been removed.

Adding an item that already exists.

Removing an item that no longer exists.

Editing an item that has already been edited that day if the fields match.
5.3. Give the user the option of overriding, ignore, and wait.
5.4. Give the user the option of overriding the database’s information, dropping the client’s
information, and waiting to solve the conflict until later.
5.5. If waiting, flag the item in the inventory list with the conflict so the user knows that
they waited and need to resolve the conflict still.
5.6. If waiting, add a conflict notification to the maintenance feed.
Build 3:
General Functionality:
1. Minor Tweaks ( 1 / 3.5 / 6 )
1.1. If the test cases have shown any issues with the database or pulling information,
solving those or adding extra functionality.
2. Cosmetic changes ( 1 / 3.5 / 6 )
2.1. Different additions/moves to the UI in order to make the most user friendly experience.
3. Run test cases ( 3 / 5.5 / 8)
3.1. Develop new test cases relating to normal use of the application and running them
against the polished application.
Map Functionality:
1. Testing ( 5 / 10 / 20 )
1.1. Rigorously test the maps section of the application and fix issues
Back-End Functionality:
1. Conflict testing ( 2 / 5 / 8 )
1.1. Thorough testing of the various conflict scenarios and their resolutions.
2. Connection testing( 1 / 2 / 3 )
2.1. Testing to ensure that the program handles connection gain and loss as expected.
3. General query testing( 2 / 4 / 6 )
3.1. Testing that all queries and API functions handle appropriately with the other pieces of
the application.
4. Sync testing ( 2 / 4 / 6 )
4.1. Testing the application's ability to maintain its local caches and to properly sync with
the database on the server.
Cost Estimates
Build 1
Front End
Task Description
Add Item
Delete Item
Lookup Inventory Item
Barcode Scanner
Preferences
Calendar(UI)
Maintenance Request and Lost Form
Display Tablet's GPS
Develop Test Cases
Summary of Cost Estimate:
Optimistic
0.5
0.5
1
2
1
1.5
0.5
0.5
0.5
8
Average
0.75
0.75
1.75
5
2
2.75
1
0.75
0.75
15.5
Pessimistic
1
1
1
8
4
4
1.5
1
1
22.5
Optimistic
1
1
2
1
1
1
7
Average
2
2
3
2
2
1.5
12.5
Pessimistic
3
4
4
3
3
2
19
Optimistic
0.5
1
0.25
0.25
0.5
1
2
1
0.5
1
0.5
8.5
Average
1
2
0.5
0.5
1
2
4
2
1
2
1
17
Pessimistic
1.5
3
1
1
1.5
3
6
3
1.5
4
2
27.5
Map
Task Description
Display Map
Display Arrow
Search for an Item
Filtering Item Search
Dropping Pins
Adding info to pin selection
Summary of Cost Estimate:
Back-End
Task Description
Setup WAMP
Make DB and tables
Configure server
Add JDBC library
Configure code to connect to server
Query Inventory based on credentials
Error Handling
Pull from DB for inventory list
Pull from DB for maintenance
Send inventory data to DB
Send maintenance to DB
Summary of Cost Estimate:
Build 2
Front End
Task Description
Add Item (DB)
Display inventory item (DB)
Calendar (DB)
Export to Excel
Maintenance and Lost Request Feeds
Maintenance and Lost Form (to DB)
Locate inventory item
Develop test cases
Summary of Cost Estimate:
Optimistic
1
0.5
1
2
0.5
0.5
4
2
11.5
Average
1.75
0.75
2
3
0.75
1
4.25
3.5
17
Pessimistic
2
1
3
5
1
1.5
4.5
5
23
Optimistic
1
2
1
1
1
6
Average
2
3
2.5
2
2
11.5
Pessimistic
4
4
5
4
3
20
Optimistic
4
1
4
2
5
16
Average
6
2
6
4
10
28
Pessimistic
8
3
8
6
20
45
Optimistic
1
1
5
7
Average
1.35
1.35
8
10.7
Pessimistic
6
6
15
27
Map
Task Description
Display Arrow
Search for an item
Filtering item search
Adding info to pin selection
Navigation
Summary of Cost Estimate:
Back End
Task Description
Create local copy of DB
Inventory list pull from DB
Create Cache Structure
Back Threads
Conflict Handling
Summary of Cost Estimate:
Build 3
Front End
Task Description
Minor Tweaks
Cosmetic Changes
Run Test Cases
Summary of Cost Estimate:
Map
Task Description
Testing
Summary of Cost Estimate:
Optimistic
5
5
Average
10
10
Pessimistic
20
20
Optimistic
2
1
2
2
7
Average
5
2
4
4
15
Pessimistic
8
3
6
6
23
Optimistic
8
7
8.25
23.25
Average
15.5
12.5
16.5
44.5
Pessimistic
22.5
19
26.5
68
Optimistic
11.5
6
16
33.5
Average
17
11.5
28
56.5
Pessimistic
23
20
45
88
Optimistic
7
5
7
19
Average
10.7
10
15
35.7
Pessimistic
27
20
23
70
Back-End
Task Description
Conflict Testing
Connection Testing
General Query Testing
Sync Testing
Summary of Cost Estimate:
Summary
Build 1
Subgroup
Front End
Map
Back End
Total for Build
Build 2
Subgroup
Front End
Map
Back End
Total for Build
Build 3
Subgroup
Front End
Map
Back End
Total for Build
Total for Team
Subgroup
Front End
Map
Back End
Total for Team
Optimistic
26.5
18
31.25
75.75
Average
43.2
34
59.5
136.7
Pessimistic
72.5
59
94.5
226
Schedule and Milestones