AIR Tracker Team Lab 5
1
LAB 5 – LESSONS LEARNED
Upon completion of the CS410 / CS411 combination classes, there have been many
lessons learned about not only the AIR Tracker product development, but also about the product
development process in general. There were some risks involved that were either mitigated or
not visited in the prototype stage. There were also budget and scheduling concerns to be
examined in hindsight.
One of the most important aspects to review regarding the product development process
are the risks involved. The risks that were presented were:
1) Wireless communication complications
2) Not enough airports being attracted to the product
3) Unintentional personal information leak
4) Incompatible database format
5) Customers unable to install the software / hardware
Some of these risks were not categorized as being able to be mitigated in the prototype stage due
to time and cost constraints. The wireless communication issue was one that was driven more by
the environment in which the Real World Product (RWP) would be installed. Time constraints
and airport security measures hindered the proper testing of that facet of the project. The risk
involving not enough airports being attracted to the RWP was more a problem for the marketing
phase which is not included in the prototype stage of the development process. The last three
issues could be visited and mitigated.
Firstly, a large concern when dealing with personal information is the protection of that
information. Travelers probably do not want their travel plans made known to the entire world.
This risk was mitigated by placing a database that served as an intermediary between the airport
database and the AIR Tracker application. What this creates is a method to hide data from the
system that it does not need to properly function. All that the prototype needs is the bag
identification number and the destination gate. One thing to note, however, is that in the RWP
where changing itineraries is an actuality, more information may need to be passed, but no
personally identifying information should need to be included.
Secondly, the concern of an incompatible database format is of concern when trying to
integrate a product into an existing system. The AIR Tracker database provides the functionality
to translate the data taken from the airport database into whatever is needed by the application.
The AIR Tracker database serves as the customizable interface that mitigates the risk of
incompatible data.
AIR Tracker Team Lab 5
2
Thirdly, a much smaller concern was the ability of the customer to install the software or
hardware. This is mitigated (slightly in the prototype stage, but more so in the later development
stages) by having the AIR Tracker team manage the installation of the software and / or the
hardware. Once installed, there should be limited need to alter the software or hardware
architecture without notifying an employee of AIR Tracker Inc. to assist with the change.
Even though there was some changes in the mitigations of the prototype stage to the later
development stages, the risk probability and the severity remained pretty steady throughout.
This is due to good foresight by the team to efficiently predict the likelihood of an occurrence of
a problem within the scope of the project. As later stages are reached, it may be found that there
are some additional risks that may not have been considered, but that would be the case in almost
any scenario.
Another item of review for this stage in the process is that of the budget. Some initial
estimations were made early in the process regarding what the development of this product
would cost. A change to the initial price point may need to be increased based on the amount of
work that was needed simply for the prototype to reach completion. There are a lot of factors
involved in the algorithm and the routing of the bags that need to be considered. Also, the
hardware installation and the systems testing prior to final delivery may need to be extended
beyond the initial claims. Also, more money may need to be assigned to the programmers and
the hardware installation team. After monitoring the amount of time that was invested in the
prototype, a larger install team may need to be created in order to maintain the timelines as put
forth in the SBIR presentation.
Scheduling also is a factor that deems review. Money can be printed, people can be
trained, but time is a commodity that cannot be redeemed. There were very few problems
regarding scheduling. The team worked well to reach project completion in a timely fashion.
There were a few deliverable obstacles along the way, but in the end, those were overcome with
steadfast determination. All dependent tasks were mapped out and completed in a timely manner
that allowed for the total time of completion to meet that of the stated deadline. There are,
however, some changes that should be made to the phase two schedule. The AIR Tracker
software testing should have more than the two weeks that were initially assigned. Also, the
wireless communications testing should be completed before the application testing even begins,
to reduce the number of possible trouble variants down as much as possible.
After all the work put into this project, the greatest success that was realized was the
completion of the project as a whole. The project signifies the culmination of all of the
outstanding work at the unit level and the collaboration efforts at the system level. Getting the
application to work seamlessly with the database was one of the biggest and most rewarding
accomplishments and truly shows the capabilities of the system that can extend into the RWP
stage of the product development.
AIR Tracker Team Lab 5
3
During the process of reaching the end of the project, there were some complications that
were noticed in building the system. One of the more severe problems was that of the changing
itinerary. Since there was no personal identifying information exchanged, once the traveler
checked in and the bag information was stored, there was no communication of any changes in
the itinerary, which would cause the bags to need to be alt routed. Also, there was a concern
regarding the need for a cart to service more than one airplane. Both of these were discussed and
it was decided that, due to time constraints, these two issues would be taken out of the equation.
It was assumed that the itinerary would not change after check-in and also that each cart only
serviced one gate.
The initial specifications of the RWP should hold true, even after the obstacles
experienced in building the prototype. The general principles and data flow should still work as
they were designed. One item to mention that may need to be altered is that of the wireless
communications. This is only due to the fact that the airport is a unique environment that has
very busy airwaves. Based on the results of the wireless communications testing, there may have
to be some workarounds that are put into effect based on each airport. This should only
minimally hinder the overall data flow as it would be a change in the method that the wireless
communications are handled vice not having them at all.
In conclusion, there were many facets to the product development process that were
learned. The process is not a simple one and it has many inner workings that must operate
together in order to be successful. Many lessons were learned, but even greater success was
found.