In the last class we were asked to provide a list of requirements for an ordinary object. In class the example of an alarm clock was given. I have chosen to defined the requirements for a bowling ball. It seemed trivial at first, but as I got into it there seemed to be more and more requirements.
Bowling Ball Requirement:
1. Must roll - Square bowling balls rarely produce strikes
2. Must have a way for the bowler to hold and throw the ball - finger holes are typical
3. Must weigh enough to knock pins down but light enough for the bowler to throw
4. Must be made of a durable material - balls made of glass are hard to clean up after
5. Cannot mar, mark or damage wooden bowling lanes
6. Must be compatible with current bowing lane auto-return ball systems - no one likes to pry their mangled bowling ball out of the pin setting machine.
7. If used for professional competition it must meet bowling rules and regulation requirments
8. Must be smooth enough to slide on the lane, but have enough traction to allow bowlers to control trajectory by placing a spin on the ball.
9. Must be made of a uniform material so that the ball does not wobble when thrown
Optional Features
1. A GPS guidance system to guide the ball to the bowling pins
2. A remote control joy-stick interface that allows the bowler to correct the trajectory of the ball once the ball is released - Although many bowlers have tried to do this with strange contortions of their body after they throw a bad ball, the results are less than desirable.
3. A built-in smoke removal system - This would allow the cigarette smoke in the general area of the ball and bowler to be cleared so that the bowler can get a clear view of the pins.
Sunday, January 30, 2011
Proposal Posted
My project proposal has been posted at the following link http://www.mediafire.com/?okdk5db9jsocup2 . It is also available via e-mail upon request.
Thursday, January 27, 2011
A Final Thought On Software Budget Estimation
Consider this, several years back I was having a problem with a building automation system. I spent several days in the field trying this or that to solve the problem. I finally stumbled on the solution, very simple one at that; modify one line of code and just like that the problem was solved. Upon returning to the office my boss asked if I had fixed the problem, to which I replied, "Yes, I just had to change one line of code". This of course we met with a very disgruntled response, "But you've been gone for two days!" Looking back at situations like this really begs the question, how do you apply an accurate estimating system to this type of problem? A two minute fix, with 15 hours and 58 minutes of contingency? Good luck using that estimating technique and actually winning a competitive bid! Bottom line, you can't win them all, just hope you win more than you loose.
Class notes from 1-26-11
Class discussion centered mostly around creating budgets for the project. The idea of a buffer within the budget was suggested. I've always been told to call it a contingency. Buffer sounds like you just but money into the budget just because, contingency implies you recognized the unknown, evaluated it, and are prepared for it. I don't believe this part of the project will be a difficult one for me with my passed work in estimating of real world jobs. I do remember my first estimate being a daunting task, but with the help of mentors and the knowledge gained by mistakes this skill has come a long way. Unfortunately even with all my experience in estimating, when it come to software estimates, to many times in the past it has had to be a swag. I hope by the end of this class that my software estimating skills will be more refined and less "swaggish".
I spent a fair amount of time over the last few days in both mental design and in doing background research on my project. The concept of a web portal and designing apps for smart phones is probably my biggest concern right now. The lower end (embedded) portion of the project is well understood and can easily be estimated. Web searches into the android SDK, including viewing a few videos on the topic has helped with my understanding of this part of the project. The android SDK seems to use a standard version of Java with special extensions that allow access to the phone specific interfaces. I was also able to located some sample code that allows simple, customizable web browser interfaces using Java. On the web portal side, some examples of how this could be done were also found. None of these sample codes do exactly what I want, but they do give me the knowledge that what I have proposed for a project is probably within the scope of the class.
Additional research into the project proposal for a remote control thermostat revealed that this is not as original an idea as I had hoped. With a lot of mental design (walking the halls, waking at 3 in the morning, ect) this week I think I have a good handle on how to make my project unique and sell-able. I've learned over the years that sometimes it is not the super sophisticated products that sell, but rather the ones that fill an unfulfilled need in a niche marked.Although the preliminary proposal paragraph will still hold true, I will need to add these new ideas into the final proposal to make a truly unique product.
I spent a fair amount of time over the last few days in both mental design and in doing background research on my project. The concept of a web portal and designing apps for smart phones is probably my biggest concern right now. The lower end (embedded) portion of the project is well understood and can easily be estimated. Web searches into the android SDK, including viewing a few videos on the topic has helped with my understanding of this part of the project. The android SDK seems to use a standard version of Java with special extensions that allow access to the phone specific interfaces. I was also able to located some sample code that allows simple, customizable web browser interfaces using Java. On the web portal side, some examples of how this could be done were also found. None of these sample codes do exactly what I want, but they do give me the knowledge that what I have proposed for a project is probably within the scope of the class.
Additional research into the project proposal for a remote control thermostat revealed that this is not as original an idea as I had hoped. With a lot of mental design (walking the halls, waking at 3 in the morning, ect) this week I think I have a good handle on how to make my project unique and sell-able. I've learned over the years that sometimes it is not the super sophisticated products that sell, but rather the ones that fill an unfulfilled need in a niche marked.Although the preliminary proposal paragraph will still hold true, I will need to add these new ideas into the final proposal to make a truly unique product.
Monday, January 24, 2011
Class notes from 1-24-11
Today's class discussion was about the project proposal. A general review of the expectations was given with some pointers on dos and don'ts.
I began doing background research on my proposed project today. I have a good handle on the embedded portion of the project but needed to understand the web and phone app part of the project. It appears the Android SDK is available at no cost and uses Java via Eclipse as its basic development system. The i phone SDK had a fee and used a C type programming language. I suppose either would work for this project, but I am leaning towards the Android, partly because my family has Android based phones allowing for a low cost development platform without having to buy an i phone.
The general idea of a remote control thermostat is already out in the market place as web based systems. I did not find anything that had historical trending available and all phone apps were either in development or used a web based (HTTP) interface customized for the smaller phone screen. It seem this may still be a viable project, although not as cutting edge as I had hoped.
The possibility of using a serial to Ethernet bridge was also considered in place of a PC computer with a web interface. Unfortunately I have not found anything that allows the Android to access this type of interface (driver). I'll keep looking, but I believe it may not exist. This would not be the end of the project, but it does make the overall project less desirable in terms of an actual consumer product. The idea of an embedded web portal on the thermostat is still the most desirable, but probably out of the scope of this project.
I began doing background research on my proposed project today. I have a good handle on the embedded portion of the project but needed to understand the web and phone app part of the project. It appears the Android SDK is available at no cost and uses Java via Eclipse as its basic development system. The i phone SDK had a fee and used a C type programming language. I suppose either would work for this project, but I am leaning towards the Android, partly because my family has Android based phones allowing for a low cost development platform without having to buy an i phone.
The general idea of a remote control thermostat is already out in the market place as web based systems. I did not find anything that had historical trending available and all phone apps were either in development or used a web based (HTTP) interface customized for the smaller phone screen. It seem this may still be a viable project, although not as cutting edge as I had hoped.
The possibility of using a serial to Ethernet bridge was also considered in place of a PC computer with a web interface. Unfortunately I have not found anything that allows the Android to access this type of interface (driver). I'll keep looking, but I believe it may not exist. This would not be the end of the project, but it does make the overall project less desirable in terms of an actual consumer product. The idea of an embedded web portal on the thermostat is still the most desirable, but probably out of the scope of this project.
Sunday, January 23, 2011
Preliminary Proposal Paragraph:
Recent media events regarding the damage done to the Albuquerque Public Schools due to frozen water pipes emphasizes the potential damage extreme cold weather can do to a building. Although not a media event, many homeowners returned after a long holiday vacation to find their homes flooded as well. A small broken pipe can cause tens of thousands of dollars in damage to not only a building, but it’s contents.
With the advent of i-phones people are able to remotely interface with their possessions on a much different level. Recent car commercials showing people starting and unlocking their car from an i-phone is an example of this.
When people leave for a vacation it is common for them to turn down their home thermostat to save energy. Unfortunately if extreme cold weather hits while gone, these lower thermostat settings may not keep all parts of the house above freezing. A failure of a heating system while gone can also spell disaster. If a homeowner could be alerted in case of a problem and make adjustments as needed, a flooded home could possibly be avoided.
The proposed solution for this issue is to design an i-phone accessible thermostat that could remotely alarm, be monitored (including a simple temperature history log), and be adjusted remotely. This initial project would consist of a simple heating only thermostat with a rudimentary user display for local access, an outside air temperature sensor and an RS-485 serial network connection, all run from embedded software. The serial port will connect to a PC computer that will act as a bridge to the Internet from which the i-phone can receive alerts, access data and manipulate settings. Future revisions might include embedding a wireless web server directly into the thermostat, but that is a bit too ambitious for the scope of this project.
The design team will need to be comprised of all levels of software engineers dealing with low level embedded software, serial driver development, web interface and finally i-phone application development.
This design may have possible patent opportunities. Real venture capital funds and hardware design support are available for hardware development portion of this project. The project will probably need to be supported by a 6-person team, two for embedded software, two for the PC web portal and two for the i-phone app.
Friday, January 21, 2011
Class notes from 1-21-11
The class syllabus is posted at www.cs.unm.edu/~jmk and the professors e-mail is jmk@cd.unm.edu.
No mandatory book is required for this class but and optional book will be posted on the class syllabus.
Due next Monday is a proposal paragraph describing a possible software design project. The project should be small enough to be completed during the semester with a team of 5 or less students. These paragraphs will be converted into a larger proposal at a future date. The paragraph should provide a brief description of the project and include things like why this development is needed. It is to be submitted via a blog posting and be about a half a page long.
The professor emphasized the need to keep all work backed up during project development. "my hard drive crashed" would not be accepted as a legitimate excuse for failure to complete the project.
Class discussion about possible projects included an i-phone game application, a stamp collection database, and technical service project management program. The use of some sort of database will probably be expected to be included as part of the project.
After class discussion amongst the Los Alamos students included a cooking recipe database and a remotely accessible thermostat. It seems the Los Alamos student programming skills include everything from web page design to assembly level programming. We were not sure how the teams were to be broken out leaving us a bit up in the air as to how to select our proposals. If the Los Alamos students are to work as a team (due to our remote location) that might sway our proposal decisions.
No mandatory book is required for this class but and optional book will be posted on the class syllabus.
Due next Monday is a proposal paragraph describing a possible software design project. The project should be small enough to be completed during the semester with a team of 5 or less students. These paragraphs will be converted into a larger proposal at a future date. The paragraph should provide a brief description of the project and include things like why this development is needed. It is to be submitted via a blog posting and be about a half a page long.
The professor emphasized the need to keep all work backed up during project development. "my hard drive crashed" would not be accepted as a legitimate excuse for failure to complete the project.
Class discussion about possible projects included an i-phone game application, a stamp collection database, and technical service project management program. The use of some sort of database will probably be expected to be included as part of the project.
After class discussion amongst the Los Alamos students included a cooking recipe database and a remotely accessible thermostat. It seems the Los Alamos student programming skills include everything from web page design to assembly level programming. We were not sure how the teams were to be broken out leaving us a bit up in the air as to how to select our proposals. If the Los Alamos students are to work as a team (due to our remote location) that might sway our proposal decisions.
Subscribe to:
Posts (Atom)