Lessons Learned
Running head:
LAB 5 – LESSONS LEARNED
Lab 5- Lessons Learned
Jill Mostoller
CS411
Professor Gene Price
Old Dominion University
May 4th, 2011
Version One
1
Lessons Learned
2
Table of Contents
1
INTRODUCTION…………………………………………………………………… 3
2 RISK MANAGEMENT AND MITIGATION…………………….…….……………3
3 BUDGET…………………………………………..………………………………… 5
4
SCHEDULE……………………………………………………………………..….....5
5
PROTOTYPING……………………………………….………………………….…..6
6
RWP SOLUTION AND SCOPE………………………………………………….…..7
[This space intentionally left blank]
Lessons Learned
3
Lab 5 – Lessons Learned
1
INTRODUCTION
Throughout the two semesters in Professional Workforce Development, our team
worked together to identify a world problem and used our combined Computer Science
skills to develop a solution to this problem. One of the first lessons learned for our team
was how difficult it is to think of a product idea that can be realistically prototyped in
four months. Overcoming this first obstacle, our team decided to combat the issue of
roadway flood alerts. In Norfolk, Virginia, it is no secret that roadways get flooded easily
and unfortunately there is no system currently in place to alert drivers on the road and
also before they start their commute.
Our team worked diligently for two semesters to develop a prototype for the
Surface Water Detection System. This system allows local alerts in the form of a flashing
warning sign near the site of the flooding, as well as, remote alerts via a website and RSS
feeds that allow users to check roadways before they leave the home or office. The
following will outline the lessons we have learned individually and as a group during the
realization of our idea and the development of our prototype.
2
RISK MANAGEMENT AND MITIGATION
In Professional Workforce Development I, our team identified four risks
concerning our real world product. Our first identified risk were two scheduling risks
including the delay of information or equipment. If the city takes too long to inform the
SWDS team about the network system they have in place or specifically where they need
the sensors placed, it could delay installation of the product. The second scheduling risk
involves a manufacturing delay of either the mounting system for our sensors or the road
Lessons Learned
4
signs accompanying the systems. Both of these scheduling risks are not likely to cause
our project to fail. To mitigate this risk, our client would need to provide us with
information in a timely fashion to avoid any delays.
Our product, like many others, has financial risks that would be classified as
moderate and possible. Though we feel the budget for our project is accurate, there is a
potential for unforeseen expenses due to additional parts for the product or an increase in
manufacturing costs. There is also a matter of contract penalties that would be associated
with any equipment delay causing a late delivery for the project. Adding in an overhead
“cushion” to the price quote to compensate for any additional expenses can mitigate both
of these financial risks.
Another risk concerned with the Surface Water Detection System is a technical
risk dealing with the technology the client will already have available. More specifically,
our client will need to have a network available if they desire our networked system. We
anticipate that some clients will not have a network readily available for the SWDS to
piggyback. Our company will not set up a network; so to mitigate this risk, we will
outsource the networking labor to another company for our client.
The final risk associated with our product would be a marketing risk. The Surface
Water Detection System is fairly targeted toward city governments so if we are wrong in
assuming that this cliental will be interested in our product for the sole purpose of
increasing public safety, there is a risk of not being able to market our product to anyone
else. To mitigate this risk, our team has identified an alternative market in insurance
agencies. Unlike with the city, insurance companies stand to earn money from our system
by being able to deny claims of people who did not head the flood warnings. This caused
Lessons Learned
5
us to add a separate user type to our prototype website. The insurance company user type
would be able to look at historical data for each sensor.
3
BUDGET
Our original budget for the prototype totaled $228. During the development of our
prototype, Microsoft provided us with an eBox development machine at no cost. For our
initial prototype, it will not be necessary to add the eBox cost into our budget but if any
additional ones are needed in the future, we will need to add the cost. The addition of the
eBox was solely for our prototype and would not affect the real world product cost. One
major change to both our Phase 1 and Phase 2 budgets would be for staffing. Two
additional members were added to our team for the second semester. These two members
would need a salary, which would be added into the budgets for the different phases.
4
SCHEDULE
There was an obvious time crunch to complete our prototype. Each team was
given four months to build their prototype. Even with our team starting our prototype
development earlier than most, it still took the full four months allotted. Though we were
able to complete our prototype, the communication between our hardware and software
teams made it difficult to work in parallel and thus work more efficiently. Our team also
lost time because an essential team member was out of commission for nearly a month.
After all team members were present, however, we were able to make up our lost time
and produce our prototype of the SWDS. Our team was able to complete both the
hardware and software aspects of the system before the deadline. Because we were able
to finish our prototype on time, no changes to the Phase 2 schedule will be necessary.
Lessons Learned
5
6
PROTOTYPING
The Surface Water Detection System prototype was developed on schedule with
most of the original attributes we envisioned. Our prototype has an ultrasonic sensor that
is attached directly to the Propeller Professional Development Board. Originally, the
development board would be connected directly to a development PC but this was later
changed when our team received an eBox development machine from Microsoft. The
eBox serves as an intermediate between the microcontroller on the development board
and the PC. It allows us to use a higher-level language for our filtering logic, which gives
us information that is more accurate.
The software side of our prototype changed deviated slightly from our original
design, as well. Initially, we only had a city user type but later changed the administrative
web application to also include the new insurance company user type (mitigating our
marketing risk). There was also a small change of switching from the Google Maps API
to the Bing Maps API.
One problem we have identified with our prototype is that using a bucket to
demonstrate our product can sometimes be finicky. The sound waves from an empty
bucket reverberate against the walls, which create a lot of “noise” for the sensor to pick
up. This sometimes delays the accurate reading by the sensor. Our team has determined
that this is caused by the small size of the opening of the bucket and would not be a
problem in an open real world setting (applicable to our real world product). After less
than one minute, however, the sensor sorts the “noise” and an accurate reading can be
taken.
Lessons Learned
6
7
REAL WORLD PRODUCT SOLUTION AND SCOPE
After developing our prototype, I do not believe any major changes need to be
made to the design of our real world product. One problem that needs to be addressed in
our real world product that was not necessarily relevant in our prototype is the sensor
offset. For our prototype, the offset was just the height of the sensor because it was
pointed straight down. This may not be the case for our real world product. A city
engineer may determine the measuring point to be in the center of the road. In this case,
our sensor would need to be angled to determine the water level and a new formula
would need to be developed to deal with the offset.
Another problem that we did not address in our prototype is the remote access to a
Closed System Remote Device. We did not add this functionality to our prototype and
have not determined how the client would be able to access the information on the CSRD
from a remote location. Our team talked about using Bluetooth but more research needs
to be done before incorporating it into our real world product.