I.

Document Overview

The creation of the two major components of Niner Parking, the sensory system for
detecting parking deck and lot space availability and the data distribution system for providing
users of UNC Charlotte parking services with such data, are a means of accomplishing our
project objective: to provide the user with realtime information on parking space availability at
UNC Charlotte. To create a functional system that serves the intended objectives of our solution,
however, we developed our solution using a series of prototypes and a systematic assessment of
such prototypes. In this document, we discuss the development of the User Interface (UI) and
sensory system prototype components that obtain and distribute parking space availability data.
Our prototype development in turn warrants careful documentation of the incremental testing
that parallels our actual construction of our parking solutions, both digitally and physically.

We started by developing virtual solution mockups, which manifest in the form of

potential UIs that address the element of Human-Computer Interaction (HCI) with our UNC
Charlotte parking solution. We then created sensory system mockups that we felt would most
effectively integrate with our choice of potential UIs, as discussed in Element D. Our last key
prototype mockup was with the creation of our back-end code, created using the Python
programming language, that would allow our sensory system to properly integrate with our UI,
the part of our project most tangible and easily observable to the user. With each of our
prototypes, of which there are 7, we documented a description and analysis of our incremental
testing that communicate our preliminary design criteria for the development of our prototypes.
We then recorded the results of our incremental testing to show that each of our prototypes are
functional models of our parking solution, which can then be further tested for their viability to
become a part of our final project solution, as discussed in Element H. Accordingly, we also
described the general build procedures for each of our prototypes and accompanied them with
photographic documentation. We concluded our overview of each of our prototypes with a
review of our prototype costs and our prototype modifications made during our build process to
satisfy our preliminary design criteria.

II. Prototype Design & Organization

The first three prototypes of our Niner Parking solution development focus on the
potential user interface models of our program. The second three prototypes of our software
solution serve as small-scale implementations of our best potential parking space sensory
systems with suitable, VEX Robotics-implemented, parking lot constructions for small-scale cars
(e.g. Matchbox Cars and Die-Cast Cars) that could later be implemented on the lifesize scale of
UNC Charlotte parking lots and decks. Our final prototype consists of the final rendition of our
software that processes parking lot image data to determine specific space availability and count.
Our series of prototypes is labelled and chronologically organized as follows:

Prototype 1 (P1): User Interface Model 1

Prototype 2 (P2): User Interface Model 2
Prototype 3 (P3): User Interface Model 3
Prototype 4 (P4): Light-Sensory Parking Detection System
Prototype 5 (P5): Pressure Plate Parking Detection System
Prototype 6 (P6): Ultrasonic-Sensory Gate & Photographic Parking Detection System
Prototype 7 (P7): Photographic Parking Space Interpretation Software v9

III. Design Materials & Cost

Prototypes 1 - 3:

- NOTE:
- The term, “Part,” is used in this context to generically refer to specific devices,
components, technologies, or physical items utilized in the development of our
prototypes. Likewise, not all listed parts are physical entities.
- All recurring costs that are not explicitly stated are one-time purchase costs.
- Waived costs are costs that are not included in prototype cost of development
because they were either supplied as grant materials or already possessed by the
Niner Parking development team.
- Our school, the Charlotte Engineering Early College (CEEC), provided
our group with a VEX Robotics kit for the development of Prototypes 4 -
6 under the supervision of one of our engineering teachers, Ms. Marlowe.
For that, we thank her for taking the time to help us obtain the robotics
hardware that we needed. We also thank Mr. Weghurst, one of our Digital
Electronics teachers at CEEC, for providing us with VEX hardware
storage space and work space in his engineering room.
- We also appreciate the donation of our Adobe software licenses by the
Teachers Insurance and Annuity Association - College Retirement
Equities Fund (TIAA-CREF) organization. They invested in our project by
donating an Adobe® Creative Suite® 6 Design & Web Premium software
package for the development of our Niner Parking application user
interface.
- Our group members already own the computer hardware that is listed in
the “Initial Development Materials & Costs” listings for each of our
prototypes.
- All prototypes possess associated costs, incremental tests, and material usage.
 a. Prototype 1

Initial Development Materials & Costs:

Part Part Identification Cost Per Count
Count (Including Sales Tax)

1 Proto.io prototype development and build software $32.27 Monthly

1 Adobe® Creative Suite® 6 Design & Web Premium $799.54 (Waived)

1 jQuery Mobile + Backbone.js Framework Construction $0.00

1 Apple & Android Mobile Drivers $0.00

1 Apple & Android Operating System Program Simulations $0.00

2 Windows PC with sufficient graphic rendering performance $907.71 (Waived)

and software support
Total Initial Cost of Development: $32.27

b. Prototype 2

Initial Development Materials & Costs:

Part Part Identification Cost Per Count
Count (Including Sales Tax)

1 Proto.io prototype development and build software $32.27 Monthly

(Waived; Repeated
Cost)

1 Adobe® Creative Suite® 6 Design & Web Premium $799.54 (Waived)

1 jQuery Mobile + Backbone.js Framework Construction $0.00

1 Apple & Android Mobile Drivers $0.00

1 Apple & Android Operating System Program Simulations $0.00

2 Windows PC with sufficient graphic rendering performance $907.71 (Waived)

and software support
Total Initial Cost of Development: $0.00
 c. Prototype 3

Initial Development Materials & Costs:

Part Part Identification Cost Per Count
Count (Including Sales Tax)

1 Proto.io prototype development and build software $32.27 Monthly

(Waived; Repeated
Cost)

1 Microsoft Office Home & Student 2016 for PC $160.86 (Waived)

1 Adobe® Creative Suite® 6 Design & Web Premium $799.54 (Waived)

1 jQuery Mobile + Backbone.js Framework Construction $0.00

1 Apple & Android Mobile Drivers $0.00

1 Apple & Android Operating System Program Simulations $0.00

2 Windows PC with sufficient graphic rendering performance $907.71 (Waived)

and software support
Total Initial Cost of Development: $0.00

Future Implementation Materials & Costs: (For Prototypes 1 - 3)

Part Part Identification Cost Per Count
Count (Including Sales Tax)

1 iOS/Xcode Distribution Certificate (App Store) $99.00

1 Apple & Android Mobile Driver Update Package $0.00

1 Apple & Android Operating System Alpha Releases $0.00

Total Future Cost of Development: $99.00
Prototypes 4 - 6:

a. Prototype 4

Initial Development Materials and Costs:

Part Part Identification Cost Per Count
Count (Including Sales Tax)

1 VEX EDR Classroom and Competition Super Kit $1,049.99 (Waived)

3 24” x 36” Gridded Paper $2.51

1 Carton Sealing Tape - 2.6 Mil, 2" x 55 yds, Clear $3.56

2 2’ x 6’ x ¼” Cardboard Panel $6.05

1 ROBOTC for VEX Robotics 4.X $160.86 (Waived)

2 VEX IQ SnapCAD Modeling Software $0.00

1 Windows PC with sufficient computational performance and $359.81 (Waived)

software support
Total Initial Cost of Development: $23.19

Click ​here​ to view the general part listing utilized from our VEX EDR Classroom and
Competition Super Kit for developing Prototypes 4 - 6.

b. Prototype 5

Initial Development Materials and Costs:

Part Part Identification Cost Per Count
Count (Including Sales Tax)

1 VEX EDR Classroom and Competition Super Kit $1,049.99 (Waived)

3 24” x 36” Gridded Paper $2.51 (Waived;

Repeated Cost)

1 Carton Sealing Tape - 2.6 Mil, 2" x 55 yds, Clear $3.56 (Waived;
Repeated Cost)

2 2’ x 6’ x ¼” Cardboard Panel $6.05 (Waived;

Repeated Cost)
 1 ROBOTC for VEX Robotics 4.X $160.86 (Waived)

2 VEX IQ SnapCAD Modeling Software $0.00

1 Windows PC with sufficient computational performance and $359.81 (Waived)

software support
Total Initial Cost of Development: $0.00

Click ​here​ to view the general part listing utilized from our VEX EDR Classroom and
Competition Super Kit for developing Prototypes 4 - 6.

c. Prototype 6

Initial Development Materials and Costs:

Part Part Identification Cost Per Count
Count (Including Sales Tax)

1 VEX EDR Classroom and Competition Super Kit $1,049.99 (Waived)

3 24” x 36” Gridded Paper $2.51 (Waived;

Repeated Cost)

1 Carton Sealing Tape - 2.6 Mil, 2" x 55 yds, Clear $3.56 (Waived;
Repeated Cost)

2 2’ x 6’ x ¼” Cardboard Panel $6.05 (Waived;

Repeated Cost)

1 GoPro HERO3+ Black Edition Action Camcorder & GoPro $536.24 (Waived)
HERO3 Mount Kit

1 ROBOTC for VEX Robotics 4.X $160.86 (Waived)

2 VEX IQ SnapCAD Modeling Software $0.00

1 Windows PC with sufficient computational performance and $359.81 (Waived)

software support
Total Initial Cost of Development: $0.00

Click ​here ​to view the list of parts utilized from our VEX EDR Classroom and Competition
Super Kit for developing Prototype 6.
Future Implementation Materials & Costs: (For Prototypes 4 - 6)
Part Part Identification Cost Per Count
Count (Including Sales Tax)

94 Infrared HD Digital Surveillance Camera $14.80

94 Universal Surveillance Camera Mount $9.30

73 RV16AF-20-15K-A2K-3LA Potentiometer $1.72

16 Maintenance & Installation Personnel (Including Supplied $16.95 Per Hour (Per
Work Materials) Worker)
Total Future Cost of Development: $2390.96 + ($271.20 Per Hour of Work)

Prototype 7:

Initial Development Materials and Costs:

Part Part Identification Cost Per Count
Count (Including Sales Tax)

1 ATOM Python Integrated Development Environment (IDE) $0.00

1 Windows PC with sufficient computational performance and $359.81 (Waived)

software support
Total Initial Cost of Development: $0.00

Future Implementation Materials & Costs:

Part Part Identification Cost Per Count
Count (Including Sales Tax)

1 PowerEdge T330 Tower Server & Server-Integrated Software $679.00

Maintenance Package
Total Future Cost of Development: $679.00

IV. Virtual Solutions

When we were building our prototypes, we put most of our focus on the structural design
and sensor mounting components for our physical builds (Prototypes 4 - 6). For our software
builds (Prototypes 1 - 3 and 7), we focused on usage flow and optimization. We wanted to create
an effective light-sensory, pressure-sensory, and ultrasonic-sensory parking space detection
system that did not misread any sort of placement of a car on top a parking space. Because
sensors can sometimes be knocked out of place and therefore not properly calibrate, we knew
that proper mounting of our sensors would be a difficult task. The other specifications for our
physical builds would be easier and take less time to resolve through incremental testing (see
Section VI for details on our incremental testing). Regarding our software builds, we understood
that our data output would need to be structured in a way that was easily readable by the user and
therefore realized that creating a parallel between our data output array and our Graphic User
Interface (GUI) would also be difficult. First and foremost, we wanted to be sure that our sensor
systems could properly interpret specific parking space availability. Our most important criteria
was to avoid any possible misinterpretations of parking data by the user.

The prototypes were constructed with various tools. First, we made three initial sketches
of our mounting systems for the sensors associated with each of the sensory technologies in
Prototypes 4 - 6 using SnapCAD. We made sure our dimensions for the physical prototypes of
our sensor systems were correct and would meet our specifications as we proceeded to analyze
our part availability and build implementation. We planned the designs for each of our potential
UIs using flow charts starting with Prototype 1 and consecutively working up to Prototype 3. We
also created a simplistic input/output visualization to show how parking lot images would
theoretically be processed and described the programming operations needed to do so using
pseudocode. These visualizations are pictured below:
Prototypes 1 - 3

a. User Interface Model 1:

UI Flow Chart:
 b. User Interface Model 2:

UI Flow Chart:
 c. User Interface Model 3:

UI Flow Chart:
Prototypes 4 - 6

a. Light-Sensory Parking Detection System:

Light Sensor Mount Model: (SnapCAD 3D Model)

b. Pressure Plate Parking Detection System:

Pressure Plate Mounting Model: (SnapCAD 3D Model)

 c. Ultrasonic-Sensory Gate & Photographic Parking Detection System:

Parking Gate Model: (SnapCAD 3D Model)

Prototype 7:
Photographic Parking Space Interpretation Software v9:

Pseudocode:

# 1) The program reads a normal image of a parking lot.

# 2) A parking lot sized patch of blank pavement is scanned.
# 3) Regions of interest are defined, 1 for each row, where a match of the template
# will be searched for.
# 4) A correlation between the template is searched for across each region of
# interest and rated on a scale from 0.00-1.00 (No correlation to high
# correlation) and graphed.
# 5) Due to things such as black cars still causing problems, the regions are
# re-scanned this time looking for variance between it and the template. Things
# such as windows and mirrors would be determined as variance to the template.
# The variance was then graphed from 0.00-1.00 (High variance to no variance).
# 6) These two factors were then averaged together into one probability graph
# scaled from 0.00-1.00. A threshold of 0.975 was set, and if a particular area
# on the region went over this threshold it was determined an empty spot.
# 7) If an area was determined an empty spot a green dot was placed on it, and the
# coordinate of the spot in terms of row and column in the parking lot was
# documented.
Input: (Image of parking lot) Output: (Marked image of parking lot)

V. Prototype Mockups

As we built our prototypes, we made some revisions. For example, we made the UI more
aesthetically pleasing by making it have the colors of the UNC Charlotte Forty-Niners football
team. We eliminated our defaulted and simplistic color scheme that is evident with Prototype 1
as we moved to design Prototypes 2 and 3. We also introduced a simple map interface for
Prototype and then expanded upon with Prototype 3 by creating a parking space availability
infographic that updates in real time for every parking lot or deck at UNC Charlotte. We
modeled this infographic generation system using Lot 4A at UNCC. We also encountered issues
with our light sensor calibrations in Prototype 4 and had to appropriately evaluate which
threshold is best suited for differentiating between car presence and car absence in each parking
space. Our initial calibrations did not work or yield any sort of useful output.

We had planned for our UI graphics to be rendered as Scalable Vector Graphics and
simulated using the Proto.io development platform. We also planned to have our sensor system
implementations built primarily using VEX EDR Robotics hardware, which is mostly composed
of Aluminum, and have our back end development for a parking lot detection processor
(Prototype 7) programmed using the Python programming language.

Below are build procedures with pictorials of the processes described above:
Prototypes 1 - 3
- Candidate UIs Designed Using Adobe Graphic Design Software & Proto.io

a. User Interface Model 1:

Build Procedure:

1. We first created a program flow chart schematic, similar to the one pictured in our virtual
solutions for Prototype 1, and sketched out a simple idea of how we wanted our user
interface to look.
2. We designed our first version of the Niner Parking application UI screens using Adobe
Photoshop. By far, this was our most time-consuming stage in the creation of Prototype
1.

3. We used Proto.io, an application prototyping interface, to embed these UI screens into an

application flow to create an application menu. This was accompanied by creating an
application navigation system using buttons and screen animations.
Modification During Build:

While developing our first UI prototype for the Niner Parking app, we found that our app UI
looked graphically displaced when placed alongside the suite of other UNC Charlotte student
applications. Under the advisory of Douglas Lape, the UNC Charlotte Transportation Services
Director, we therefore decided to implement UNC Charlotte theme colors into our application
launch screen to address this. We also felt that including a list on the launch screen that shows
the number of spaces available in a given parking lot or deck was necessary to improve the
readability of our UI. Likewise, we implemented the idea for all data access points available in
Prototype 1 accompanied with a listing of all possible parking lots and decks at UNCC.

Prototype Model:

Click ​here​ to view our first version of the Niner Parking UI.
[CURRENTLY ACTIVE LINK]

- NOTE: To view the simulation of our first model for the Niner Parking UI, you must log
in with the following login credentials:

Email: macsrfunp@gmail.com
Password: 83672135
 b. User Interface Model 2:

Build Procedure:

1) We created a program flow chart schematic and identified the developmental points for
which we would need to account in order to make our Prototype 2 application UI look
more like a real app.
2) We used Adobe Photoshop and Adobe Illustrator to create the graphics for our second
version of the Niner Parking UI. We individually developed each of the application
screens and incorporated a splash screen with our first version of our group’s logo while
further implementing the UNC Charlotte theme colors in our UI.

3) We stitched together a high-resolution (32 Megapixel) map image of the UNC Charlotte
campus using Google Maps and highlighted four sample UNCC parking lots and decks
for more detailed map depiction in our second and third UI versions.
4) We embedded our screens into Proto.io for programming and UI implementation and, in
the process, added the necessary clocks, buttons, and animations needed to make
Prototype 2 functional as a UI.
Modification During Build:

While developing our second UI prototype, we decided to create a map UI that would allow the
user to have a more graphically-appealing means for evaluating the locations of available
parking spaces at UNCC. We further implemented the UNCC theme colors as part of our
continued modifications from Prototype 1 and likewise created an app splash screen with our
group project logo, which uses the UNCC theme colors.

Prototype Model:

Click ​here​ to view our second version of the Niner Parking UI.
[CURRENTLY ACTIVE LINK]

- NOTE: To view the simulation of our second model for the Niner Parking UI, you must
log in with the following login credentials:

Email: suraj.pendyala@gmail.com
Password: ninerParking
 c. User Interface Model 3:

Build Procedure:

1) We created a simple program flow chart which resembles that of Prototype 2.

2) We conducted research on how to create web applets so that we could develop Prototype
3 (our final version of the Niner Parking UI) as an application that could be displayed and
operated through our group website, ​http://unccparking.weebly.com/​.

3) We created and rendered all of our graphics for our third version of the Niner Parking UI.
During this stage, we redesigned our group’s project logo and reimplemented it into our
application splash screen, which is set to display for 2 seconds upon launch. We also
created thumbnail graphics that display parking space availability for individual lots and
decks displayed on our UNCC Campus map, a scrollable interface that we initially
developed with Prototype 2.
 4) We used Adobe Dreamweaver to embed our application screens and program our third
version of the Niner Parking UI. In the process, we implemented buttons, animations,
save preferences, and a user license agreement.

Modification During Build:

While developing our third UI prototype, we decided that our user interface would work best by
having a default screen launch option for one of the two independent Niner Parking view
screens, which can be used interchangeably to find UNCC parking availability. To implement
this functionality, we then decided to create a preference panel for our app. We also created a
user license agreement, which is headed as “Terms and Conditions,” displayed on first-time
application launch, and requires the user to agree in order to use the Niner Parking app. This
agreement can also be accessed and reviewed through our application preference panel. We
revised our splash screen from Prototype 2 to include our updated group logo.

Prototype Model:

Click ​here​ to view our third version of the Niner Parking UI.

We also created a listing of our terms and conditions, which can be viewed ​here​.

- NOTE: This is our best version of the Niner Parking user interface and is therefore
publicly available through our project website and does not require a login.
Prototypes 4 - 6
- VEX Robotics Models & ROBOTC Programming

a. Light-Sensory Parking Detection System:

This is the VEX EDR Cortex system available through our school, the Charlotte Engineering
Early College. The VEX Cortex is pictured on the left and the LEGO® MINDSTORMS® NXT
is pictured on the right. We used the VEX Cortex system because it integrates best with our
available hardware and is more reliable than the NXT robotics system, which was our other
configuration alternative for Prototypes 4 - 6.

Build Procedure:

1) We built a partial test chamber using box tape, gridded paper, and several large sheets of
cardboard that we would eventually use to photograph and demonstrate Prototype 4
through 6.
2) During the times in which our group organized to meet for the development of our
physical sensor system builds, we started by mounting a base plate to our VEX Cortex,
the device by which we implemented our programmable logic.
3) We organized 4 light sensors for detecting cars in parking spaces, which work by
detecting the quantified absence of light caused by a car blocking sunlight or streetlight to
determine whether a car is occupying a parking space.

4) We organized all of the structural components needed to mount our light sensors.
 5) We mounted our sensor system according to our Prototype 4 virtual sensor-mounting
solution using our provided VEX wrench and screwdriver tools (see Prototype 4 under
Section III for details on parts list).
6) We used white electrical tape to grid out a 4-space parking lot on our VEX prototype that
is suitable for use with matchbox cars.

7) We wired all of our sensors into their appropriate ports on our VEX Cortex.
8) We wrote our ROBOTC build code for Prototype 4.
9) As we built our light sensor array, we used our incremental testing procedures (defined in
Section VI) to evaluate our implemented design and adjust our design accordingly until
our prototype was able to fulfill its general functionality.

Modification During Build:

We had to change the placement of our VEX Cortex several times to allow it to properly connect
with all of our light sensors. We also had to discard our first light sensor array because it did not
fit on our base plate. Therefore, we used a tray-style mounting system that allowed us to wire our
sensors and LEDs underneath.
Prototype Model:

- Orthogonal View:

Click ​here​ to view our video-graphic demonstration of Prototype 4.

Click ​here​ to view our ROBOTC source code for Prototype 4.
 b. Pressure Plate Parking Detection System:

Build Procedure:

1) We mounted a base plate to our VEX Cortex.

2) We organized two bump switches, or pressure sensors, which work by reading a logic
high when enough force is applied due to car weight over a parking space.

3) We organized all of the structural components needed to mount our pressure sensors.
4) We mounted our sensor system according to our Prototype 5 virtual sensor-mount
solution using our supplied VEX tools.

5) We used white electrical tape to grid out a 2-space parking lot on our VEX prototype that
is suitable for use with miniature die-cast model cars.
 6) We wired all of our sensors into their appropriate ports on our VEX Cortex.
7) We wrote our ROBOTC build code for Prototype 5.
8) As we built our pressure sensor array, we used our incremental testing procedures to
evaluate our implemented design and adjust our design accordingly until our prototype
was able to fulfill its general functionality.

Modification During Build:

During the process of our development for Prototype 5, we changed our pressure plate
mechanics twice since the first two variations of our pressure sensor were to small to work with
our weighted die-cast cars.
Prototype Model:

- Orthogonal View:

Click ​here​ to view our video-graphic demonstration of Prototype 5.

Click ​here​ to view our ROBOTC source code for Prototype 5.
 c. Ultrasonic-Sensory Gate & Photographic Parking Detection System:

Build Procedure:

1) We mounted a base plate to two beams where one was used to support our VEX Cortex.

2) We organized a GoPro, two ultrasonic sensors, and a light sensor. The GoPro works by
analyzing pixel permutation and displacement that indicates specific parking space
availability. The ultrasonic sensors work by counting the number spaces available in the
parking lot according to the number of times that a car comes in sufficient proximity to
enter or exit the lot. The purpose of the light sensor is simply to provide light for the
GoPro if the given lighting environment is too dim.
3) We organized all of the structural components needed to mount our GoPro, light sensor,
and ultrasonic sensors.
4) We mounted our sensor system according to our Prototype 6 virtual sensor-mount
solution using our supplied VEX tools.
5) We used white electrical tape to grid out a 6-space parking lot on our VEX prototype that
is suitable for use with matchbox cars.
6) We wired all of our sensors into their appropriate ports on our VEX Cortex.

7) We wrote our ROBOTC build code for Prototype 6.

 8) As we built our ultrasonic and light sensor array, we used our incremental testing
procedures to evaluate our implemented design and adjust our design accordingly until
our prototype was able to fulfill its general functionality.

Modification During Build:

While developing Prototype 7, we had to move our VEX Cortex from the its initial placement
opposite to our parking gate in order for it to properly connect to all of our sensors. We also
needed to frequently adjust and calibrate our ultrasonic sensors to correctly read car entry and
exit. We found that our exit ultrasonic sensor read best at a proximity of 5 cm while our entry
ultrasonic sensor read best at 7 cm.
Prototype Model:

- Orthogonal View:

Click ​here​ to view our video-graphic demonstration of Prototype 6.

Click ​here​ to view our ROBOTC source code for Prototype 6.
Prototype 7:
Photographic Parking Space Interpretation Software v9:

Build Procedure:

1) We used our pseudocode virtual solution to create a flowchart by which we programmed

the graphic output and variable initialization within our program.

2) We then programmed and implemented the calculation models discussed in Element D

into our program such that they would be automatically executed upon graphic input.

3) As we developed our photographic parking space interpretation software, we used our

incremental testing procedures to evaluate our implemented design and adjust our design
accordingly until our prototype was able to fulfill its general functionality. Our parking
space interpretation software, the back-end development for our Niner Parking app,
underwent 9 versions before we generated a fully-functional software build.
Modification During Build:

While developing Prototype 7, we created multiple versions of the software (9 total) where we
encountered a series of build errors that impeded the functionality of our program. We had to
modify our software 8 times before it properly compiled and ran.

Prototype Model:

The Python source code for our Parking Space Interpretation software can be viewed as a ​Screen
Shot​ from our ATOM IDE.
- NOTE: Comments in Python are depicted using the pound symbol (#).

Click ​here​ to view our video-graphic demonstration of Prototype 7.

VI. Incremental Testing & Respective Test Parameters

- NOTE:
- The following testing procedures and test parameters are applicable to all 7
Prototypes and were used to complete all 7 Prototypes.
- The intended functionalities by which we evaluated the completeness of each of
our prototype developments are discussed in Element D for all 7 Prototypes.

Testable Parameters:

In order for a given prototype to be considered viable for comparative testing, which is addressed
in Element H, the given Prototype must be:
- Able to detect parking space availability and have outputs that convey relevant parking
space availability data.
- Able to run autonomously upon startup.
- Able to observe and record whether an appropriately sized car enters or exits a parking
space.
- Satisfactory of all applicable technical requirements defined in Element D.
- Operationally and/or structurally sound.
Incremental Testing Procedure:

1) Launch parking space availability output device and, if applicable, start respective
sensory system.
a) If build is not successful or responsive to any form of input, hypothesize
reasoning for build failure and revise design accordingly.
2) If build is successful and/or responsive to applicable input, operate build by producing
sample inputs and note system output.
3) If system is intended to compute parking space availability, execute conceptual operation
for the number of spaces available or unavailable and note respective theoretical
information on parking space availability.
a) Check system output information against user-derived theoretical information
such that system provides accurate outputs if said outputs conform to
user-anticipated calculations and/or outputs.
4) If system is intended to demonstrate processing of parking space availability, note and
check program data and/or graphical outputs for abnormal data or graphic output
permutations against theoretical output using flowchart or pseudocode virtual solutions.
5) If system output does not conform to user-anticipated output, hypothesize reasoning for
functional error and revise design accordingly.
6) If system output has substantial degree of conformity to user-anticipated output with only
minor errors (e.g. buffered loading screen) or complete conformity to user-anticipated
output, conclude developmental work with given prototype according to stage of product
design (e.g. if a given prototype is intended to be final prototype model for certain aspect
of product like Prototype 1 - 3, you can spend more time developing prototype if it is
advisable by developer’s discretion).
Citations

1. 1200TVL 36 LED Night Vision Waterproof 6mm Outdoor Waterproof CCTV Camera
Infrared HD Digital Security Surveillance Camera,,. (n.d.). Retrieved February 16, 2018,
from
https://www.walmart.com/ip/1200TVL-36-LED-Night-Vision-Waterproof-6mm-Outdoor
-Waterproof-CCTV-Camera-Infrared-HD-Digital-Security-Surveillance-Camera/901314
435?wmlspartner=wlpa&selectedSellerId=15564&adid=22222222227127797933&wl0=
&wl1=g&wl2=c&wl3=235540845548&wl4=pla-386996972639&wl5=9009991&wl6=&
wl7=&wl8=&wl9=pla&wl10=118770990&wl11=online&wl12=901314435&wl13=&ve
h=sem
2. Camera Mount, Universal, Black. (n.d.). Retrieved February 16, 2018, from
https://www.grainger.com/product/SPECO-TECHNOLOGIES-Camera-Mount-49AY93?
cm_sp=Product_Details-_-Products_Based_on_Your_Search-_-IDPPLARECS&cm_vc=
IDPPLARECS
3. RV16AF-20-15K-A2K-3LA Alpha (Taiwan) | Mouser. (n.d.). Retrieved February 16,
2018, from
https://www.mouser.com/ProductDetail/Alpha-Taiwan/RV16AF-20-15K-A2K-3LA/?qs=
8%252br4Hz5Xir9JsS2%252bm5drIA%3D%3D&gclid=Cj0KCQiA_JTUBRD4ARIsAL
7_VeUiWDl_kS5wW88_N1_6Ck-yOYyRsGWSFvifSmtqEQOnZ0jEEIjP0S8aAkc3EAL
w_wcB
4. Zakharov, V. (n.d.). Overhead view of busy, accurate car park in central Tokyo.
Retrieved February 16, 2018, from
https://www.gettyimages.com/detail/photo/tokyo-birds-eye-view-of-car-park-royalty-free
-image/184813292?esource=SEO_GIS_CDN_Redirect