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.