In class we were asked to look into the survival rates of new businesses. I was able to find a a lot of information on this, but found it most interesting to see some of the international aspects of this data. Here is a brief summary:
US: The US Census Bureau has a huge amount of data, pretty much on any statistic you might want. It also provides some very interesting ways to display this. I found a colored map of the United States where the states to change color based on a given business data as you moved a scroll bar to change the year. It allowed you to see the business trends for all states at once over a wide range of years. I found an artical based on the US Census Bureau data that summrised the survival rates of small busniess from 1992 to 2002 as follows:
1992 - 100 Buisness
1993 - only 75 survived
1996 - only 50 were still in business
2002 - only 29 business remained
I thought that was not bad, only loosing 25% in the first year. I guess that is partly because this data includes all small business types, not just high-tech. I would expect high-tech survival to be much lower.
Canada: Not a good place to start a new business according to the article I read.
First year: only 10% survive (ouch!)
only 25% of those survived another year
36% of those survive past the 5 year point
20% of those make it to the ripe old age of 10 years.
It seems that a start-up business in Canada is not a good deal. Maybe the data is skewed by the article writer, or it was just bad data, but I have not seen any new business out of Canada in quite a while, so maybe its correct.
Internationally: An interesting article from an international business meeting held in Bahrain this last January (must have been before all the political unrest). It stated that internationally about 60% of business survive to 5 years. That seems to jive with the US statics, but indicates that maybe international business have a slightly better survival rate. May be this is because US businessmen might be more willing to take risk and that a lot of that is in high-tech areas that are prone to failure when compared to more traditional businesses (my conjecture, not backed by facts).
Also interesting from the international article is that business are 3 times more likely to merge into a larger corporation than to expand on their own.
Incubated: Lastly I found an article on "Business Incubators". This seems to be in line with what the professor was talking about when he described the concept of "angels" in class. The idea was to provide a safe place for a small business to grow during its first few years. This move the 5 year survival rate from a normal 44% to 87%. It seemed that the "incubating" provider company did well in many cases also. It seems to have a bit of similarity to the old way of doing business with the use of apprenticeships. Maybe what is old is new again, again!
Tuesday, March 8, 2011
Sunday, March 6, 2011
SST Process
The Salmon Spawning Technique (SST) process is a newly emerging software development process. It is gaining popularity amongst collage student who study in the field computer science. Its major features are its short time from start to completion and its realistic approach to life.
Much like the salmon, the young programmer suffers from urges. The desire to procreate (write code) takes full charge of their life in an uncontrollable and unexplainable way. The salmon (programmer) heads upstream against rushes or water, rapids and WATERFALLS. Along the way the salmon faces many other challenges as it manages to escape the claws of hungry bears who would steal the salmons idea of procreation and turn it into sushi.
Eventually the battered salmon, tire from it long journey, reaches the end of its travels. It passes its genes (software release package) off to the next generation......and dies!
I thought I'd put this in my blog just to see if anyone is really reading them.
Much like the salmon, the young programmer suffers from urges. The desire to procreate (write code) takes full charge of their life in an uncontrollable and unexplainable way. The salmon (programmer) heads upstream against rushes or water, rapids and WATERFALLS. Along the way the salmon faces many other challenges as it manages to escape the claws of hungry bears who would steal the salmons idea of procreation and turn it into sushi.
Eventually the battered salmon, tire from it long journey, reaches the end of its travels. It passes its genes (software release package) off to the next generation......and dies!
I thought I'd put this in my blog just to see if anyone is really reading them.
Agile Process
I came to CS-460 to learn about new techniques for software development, particularly in the area of multi-person programming. With that in mind, I am trying to keep an open mind to new techniques, but it is a bit of a stretch for me in some cases.
Perhaps I have been an engineer too many years to have a lot of faith in the agile process. I'm use to engineers providing a very definite path, in the form of drawings and specification, to a construction crew who completes the project. Careful upfront planning can reduce the cost of a project significantly, whereas poor planning is just asking for a disaster. I also recognize that software development is quite a bit different than constructing a building, so maybe other techniques might work better.
In reviewing different software development techniques I ran across an article by Martin Fowler on the general concepts of agile programming. I took a few quotes I found interesting and included them in my blog with my comments below:
I had posted a blog on this issue previous to this post. I find the idea of estimating program development a constant mystery. I've talked with may estimators in other fields and have been a project estimator on hundreds of projects. It seems there is no other technique in other fields of estimating that crosses well into software estimating. Moreover software estimating seems to always come down to guessing the size (time and cost) of black boxes. Maybe because software is almost always a "new creation" unlike construction where a door is a door and a wall is a wall. I guess I'm still looking for that magic software estimating algorithm.
"A consequence of self-adaptivity is that you should never expect to find a single corporate methodology. Instead each team should not just choose their own process, but should also actively tune their process as they proceed with the project."
I can actually see some relevance to this statement. I have rarely found that the "cut and dry" engineering procedures that have been placed on me over the years worked very well. I have always found that I need to modify them, either to suit my needs or the specific needs of the project. I have also found that engineering process are seldom ever self correcting and rarely support the idea of "active tuning". I actually like this concept of the agile process.
"With common guidelines that state that the role of testing is to ensure conformance of software to up-front written specifications, the role of testers in an agile world is far from clear."
The world I live in....So much of the current philosophy of "Quality Assurance" is captured in this quote. Write a specification, develop the product, test to the specification....wait that sounds like Waterfall technique. A major compliant I have had with the current stare of quality assurance is that it prevents (or at least stifles) creative solutions to issues that appear mid-stream. It seems that the agile process actually embraces this concept. The idea that test development flows in parallel with an iterating design seems to make this possible.As will all new ideas, there is almost always a bit of truth in there somewhere (of course that is true of cults also).
Perhaps I have been an engineer too many years to have a lot of faith in the agile process. I'm use to engineers providing a very definite path, in the form of drawings and specification, to a construction crew who completes the project. Careful upfront planning can reduce the cost of a project significantly, whereas poor planning is just asking for a disaster. I also recognize that software development is quite a bit different than constructing a building, so maybe other techniques might work better.
In reviewing different software development techniques I ran across an article by Martin Fowler on the general concepts of agile programming. I took a few quotes I found interesting and included them in my blog with my comments below:
"Estimation is hard for many reasons. Part of it is that software development is a design activity, and thus hard to plan and cost. Part of it is that the basic materials keep changing rapidly. Part of it is that so much depends on which individual people are involved, and individuals are hard to predict and quantify."
I had posted a blog on this issue previous to this post. I find the idea of estimating program development a constant mystery. I've talked with may estimators in other fields and have been a project estimator on hundreds of projects. It seems there is no other technique in other fields of estimating that crosses well into software estimating. Moreover software estimating seems to always come down to guessing the size (time and cost) of black boxes. Maybe because software is almost always a "new creation" unlike construction where a door is a door and a wall is a wall. I guess I'm still looking for that magic software estimating algorithm.
"This doesn't mean that you can't fix a budget for software up-front. What it does mean is that you cannot fix time, price and scope. The usual agile approach is to fix time and price, and to allow the scope to vary in a controlled manner."
Sorry, I just can't buy it, "controlled manner" or not. I have never been on a project where a change in scope did not result in a change in ether time or price. Granted, software is kind of "soft" so it might give a bit on this issue. I'd really have to see this in action to believe it works.
"A consequence of self-adaptivity is that you should never expect to find a single corporate methodology. Instead each team should not just choose their own process, but should also actively tune their process as they proceed with the project."
I can actually see some relevance to this statement. I have rarely found that the "cut and dry" engineering procedures that have been placed on me over the years worked very well. I have always found that I need to modify them, either to suit my needs or the specific needs of the project. I have also found that engineering process are seldom ever self correcting and rarely support the idea of "active tuning". I actually like this concept of the agile process.
"With common guidelines that state that the role of testing is to ensure conformance of software to up-front written specifications, the role of testers in an agile world is far from clear."
The world I live in....So much of the current philosophy of "Quality Assurance" is captured in this quote. Write a specification, develop the product, test to the specification....wait that sounds like Waterfall technique. A major compliant I have had with the current stare of quality assurance is that it prevents (or at least stifles) creative solutions to issues that appear mid-stream. It seems that the agile process actually embraces this concept. The idea that test development flows in parallel with an iterating design seems to make this possible.As will all new ideas, there is almost always a bit of truth in there somewhere (of course that is true of cults also).
Tuesday, March 1, 2011
Class notes for 2-28-2011
Today the professor talked about chain of command. Making sure we have exhausted all resources at a give level before moving up a level.
We also talked about the concept of confessional debugging. I like this new phase. I have done this so many times in my life, but never had a name to put on it.
Rational for the decisions we make in our project should be able to withstand the Define, Defend and Attack scenarios to make them good rational.
We need to start thinking about our self evaluation for our midterm grade.
- Be objective
- Summarize your activities
- Think about the quality of your work
- Consider a matrix of success - quantitative evaluation
- What is your next step and how do I improve
- Probably die the day before spring break
I spent time this evening updating the HAP1 protocol page on the wiki with some UML diagrams of how communications between the HW and WP should flow. I am also getting a new laptop up and running for use on this project. It is truly unbelievable how many updates it takes to upgrade an XP SP1 computer to a current system. Its kind of like how many licks does it get to the center of a tootsie pop...the world may never know! Oh wait, I need to restart it again........
We also talked about the concept of confessional debugging. I like this new phase. I have done this so many times in my life, but never had a name to put on it.
Rational for the decisions we make in our project should be able to withstand the Define, Defend and Attack scenarios to make them good rational.
We need to start thinking about our self evaluation for our midterm grade.
- Be objective
- Summarize your activities
- Think about the quality of your work
- Consider a matrix of success - quantitative evaluation
- What is your next step and how do I improve
- Probably die the day before spring break
I spent time this evening updating the HAP1 protocol page on the wiki with some UML diagrams of how communications between the HW and WP should flow. I am also getting a new laptop up and running for use on this project. It is truly unbelievable how many updates it takes to upgrade an XP SP1 computer to a current system. Its kind of like how many licks does it get to the center of a tootsie pop...the world may never know! Oh wait, I need to restart it again........
Monday, February 28, 2011
Wiki up and running
Not to many blog posts right now. Most of my time has been spent on the team Wiki rather than here.
We had our first team meeting last Saturday with Katherine conferenced in via cell phone. We were going to use google video, but the sound would not work. We used it for video, but the sound would not work so we used a cell phone for the audio. It worked somewhat but it was not ideal. We need to work on a better way to do this. As the professor said today, failure is not an option.
I was bale to share my original thouhts on how the system would go together based on my proposal. We talked about changes to the proposal, but the only real change that was accepted was the idea of moving the trending from the HW to the WP part of the project.
We got a fair distance on defining the HAP level 1 protocol. Unfortunately we are still refining it as we had to break up the meeting after several hours. The wiki has a good start on the HAP1 definition.
We had our first team meeting last Saturday with Katherine conferenced in via cell phone. We were going to use google video, but the sound would not work. We used it for video, but the sound would not work so we used a cell phone for the audio. It worked somewhat but it was not ideal. We need to work on a better way to do this. As the professor said today, failure is not an option.
I was bale to share my original thouhts on how the system would go together based on my proposal. We talked about changes to the proposal, but the only real change that was accepted was the idea of moving the trending from the HW to the WP part of the project.
We got a fair distance on defining the HAP level 1 protocol. Unfortunately we are still refining it as we had to break up the meeting after several hours. The wiki has a good start on the HAP1 definition.
Friday, February 25, 2011
Class notes from 2-25-11
Today in class we talked about setting up software revision control. Apparently SVN has been used on previous projects in other classes so it has a large appeal to the rest of the students. I'll have to get caught up on this part as I have never used this software before. I've used other revision control products, just not this one.
We also talked about how to run a meeting, specifically Roberts Rules of Order. Although this works, it will probably be a bit formal for most of our meetings. I expect that we can water it down a bit and get a working set of rules for our meetings. This will need to be worked out when we meet on Saturday.
An agenda has been set for our first meeting, thanks to Ekaterina. She was also helpful in pulling together team members contact info and availability as well as establishing the SVN account on the CS servers. Thanks for the team support!
In class we were also told to establish a wiki for our class, Katherine has agreed to take this on because she has had experience doing this.
All in all it seems the team is already starting to work together!
One last requirement is that we prepare, as a team, a 10 minute pitch for out project that will need to be presented to the "venture capital hat" starting next week. We'll need to refine the proposal in preparation for this presentation to incorporate input from team members.
We also talked about how to run a meeting, specifically Roberts Rules of Order. Although this works, it will probably be a bit formal for most of our meetings. I expect that we can water it down a bit and get a working set of rules for our meetings. This will need to be worked out when we meet on Saturday.
An agenda has been set for our first meeting, thanks to Ekaterina. She was also helpful in pulling together team members contact info and availability as well as establishing the SVN account on the CS servers. Thanks for the team support!
In class we were also told to establish a wiki for our class, Katherine has agreed to take this on because she has had experience doing this.
All in all it seems the team is already starting to work together!
One last requirement is that we prepare, as a team, a 10 minute pitch for out project that will need to be presented to the "venture capital hat" starting next week. We'll need to refine the proposal in preparation for this presentation to incorporate input from team members.
Proposal Accepted
My proposal was accepted as one of the five that will be further developed in this class. I'm thankful to Katherine for sticking up for my proposal while I was away on business travel. Teams were formed on Wednesday and we have two members from Abq, John Donahue and April Suknot joining the rest of the Los Alamos group on the project. The telecommuting part of this should add some challenges, but I welcome the opportunity to learn some new tricks on how best to do this.
We have established working schedules and shared some of our skill sets with each other via e-mail over the past few days. The plan is to meet face to face on campus on Saturday and start looking at the proposal more critically.
We have established working schedules and shared some of our skill sets with each other via e-mail over the past few days. The plan is to meet face to face on campus on Saturday and start looking at the proposal more critically.
Monday, February 21, 2011
Addendum to Proposal
I have posted an addendum to my proposal at Addendum Link. It is pretty much the same as my blog post from earlier today, but is available in pdf and has a few tweaks.
My Votes for the Class Project
We were asked to post our votes for our preferred class project. I'm quite excited about the opportunities my project presents to both myself, but also my fellow classmates.
With that I place all 5 of my votes for my proposal "AH". Sorry no more chivalry, no more obtaining from voting!
I will be on travel for business on Wednesday, so hopefully there will be other classmates who can stand up for my proposal.
With that I place all 5 of my votes for my proposal "AH". Sorry no more chivalry, no more obtaining from voting!
I will be on travel for business on Wednesday, so hopefully there will be other classmates who can stand up for my proposal.
Proposal Selection Continued
Today in class we worked on the proposal selection. I was please to see my proposal in the top 10 and with the addition of my vote and a few other classmates stepping up it made in into the top 5 where it remained for the next few iterations of selection.
I really see this project as having a lot of learning potential. So much of the software developed today is in embedded applications (I meet a guy once at a show who was developing software for a toothbrush! No really!). Any CS student with this ability would be well suited to enter the marketplace with a unique and high demand skill.
In addition to this, the project spans three separate and distinct hardware platforms, each with its own set of programming skills needed. This allows a unique need for multiple programming skills that must all come together to form a complete system. Real world projects almost always end up this way.
One other added benefit to this project is that it does involve some hardware development. Not all software runs on a PC, and the idea of having to work in a different environment brings new challenges. Having a hardware designer on the development team also gives a unique experience to the project. I think it is an excellent opportunity for leaning that many of the other proposals would not include.
The concept mentioned by the professor in class of using a Arduino for the hardware development platform at first did not seem very practical. I had never worked with this product before, but have seen many similar products that "dumbed down" the hardware interfaces. I reviewed the Arduino site and it seems that it remains close enough to the hardware roots to be practical for development, at least from the aspects of this class project. I really believe a real world implementation of this project would require custom hardware to implement. Embedding an Arduino in a production run thermostat is not practical or cost effective.
If the professor allows my original proposal to go through unchanged I think I can work with the other classmates to make sure the implementation on "real world" hardware would not be taxing to the project. The proposal includes two complete hardware platforms each could be used for software development. I would assemble each, outside of my software development duties, so they do not impact the overall software development process, which is the main point of the class. The required hardware parts are in hand and the hardware design is complete, at least on paper. Once accepted it will only take a day or two to go to working hardware.
The software development can be done on MPLAB which is a free software development and debugging platform available from MicroChip (MPLAB link). The chip I have selected (PIC16F877 Datasheet Link) has a built in debugging interface that allows programming in-situ and allows full access to all memory and register locations as well as such features as single stepping the CPU or run to breakpoints.
All that being said there are a few obstacles to using the custom hardware platform:
I really see this project as having a lot of learning potential. So much of the software developed today is in embedded applications (I meet a guy once at a show who was developing software for a toothbrush! No really!). Any CS student with this ability would be well suited to enter the marketplace with a unique and high demand skill.
In addition to this, the project spans three separate and distinct hardware platforms, each with its own set of programming skills needed. This allows a unique need for multiple programming skills that must all come together to form a complete system. Real world projects almost always end up this way.
One other added benefit to this project is that it does involve some hardware development. Not all software runs on a PC, and the idea of having to work in a different environment brings new challenges. Having a hardware designer on the development team also gives a unique experience to the project. I think it is an excellent opportunity for leaning that many of the other proposals would not include.
The concept mentioned by the professor in class of using a Arduino for the hardware development platform at first did not seem very practical. I had never worked with this product before, but have seen many similar products that "dumbed down" the hardware interfaces. I reviewed the Arduino site and it seems that it remains close enough to the hardware roots to be practical for development, at least from the aspects of this class project. I really believe a real world implementation of this project would require custom hardware to implement. Embedding an Arduino in a production run thermostat is not practical or cost effective.
If the professor allows my original proposal to go through unchanged I think I can work with the other classmates to make sure the implementation on "real world" hardware would not be taxing to the project. The proposal includes two complete hardware platforms each could be used for software development. I would assemble each, outside of my software development duties, so they do not impact the overall software development process, which is the main point of the class. The required hardware parts are in hand and the hardware design is complete, at least on paper. Once accepted it will only take a day or two to go to working hardware.
The software development can be done on MPLAB which is a free software development and debugging platform available from MicroChip (MPLAB link). The chip I have selected (PIC16F877 Datasheet Link) has a built in debugging interface that allows programming in-situ and allows full access to all memory and register locations as well as such features as single stepping the CPU or run to breakpoints.
All that being said there are a few obstacles to using the custom hardware platform:
- To connect the chip to the computers USB an ICD3 (ICD3 Link) interface is needed. This is easy to obtain but cost $200 each (not bad compared to many of the other options in this market). I currently only have one, so another would need to be located. If this really became a show stopper, I'd find a way to fund this.
- MPLAB is programmed in Assembly. On a PIC16F chip there are only about 32 different opcodes, so its not too hard to pick up, but there is no question Assembly is not for the weak hearted. MPLAB does have plug-ins for C and Basic, but these cost at least $100 and up, The use of these higher level languages can also lead to other issues when doing true embedded programming where having full control of the CPU at all times is needed for critical timing issues.
- Bringing a fellow student up to speed on this new environment could be a challenge. I have been writing code in this environment for years, I would take it upon myself to tutor any other student that is up to the challenge and wants to learn this new skill. I really see this as part of what I want to learn from this class. In the past I have worked most of my software development in a bubble, with me being the only programmer. I really need to learn how to work with other programmers, particularly with those of different skill levels. If along the way I can pass some of my skills to a fellow programmer, then great! I hope there is at least one other student who has the desire to learn this new skill in the class.
Selection Process for Proposals
I believe the best way to select these proposals is as follows:
1. Take the top 10 proposals from the class scoring
2. Allow some class discussion about the pros and cons of each allowing proposal owners time to rebuttle
3. Go through each proposal and take vote asking "if this proposal was selected would you want to be a team member". Keep track of the number of votes for each proposal.
4. Use the top five proposals as the final selection.
I think this is a fair way to determine the selection and it ensures the best chance that there will be team members who would want to be on the project teams.
1. Take the top 10 proposals from the class scoring
2. Allow some class discussion about the pros and cons of each allowing proposal owners time to rebuttle
3. Go through each proposal and take vote asking "if this proposal was selected would you want to be a team member". Keep track of the number of votes for each proposal.
4. Use the top five proposals as the final selection.
I think this is a fair way to determine the selection and it ensures the best chance that there will be team members who would want to be on the project teams.
Thursday, February 17, 2011
Class Notes from 2-16-11
We got through a little over half of the 2 min class presentations today. We'll complete the remainder on Friday. Everyone is given just 2 minutes for their presentation. It's tough getting everything in you would like to say in that time frame. I put together a few power point slides to add to my presentation. I figured that if a picture is worth a thousand words, then the slides gave me the equivalent of about 10 to 15 minutes more speaking time. So far I have not seen anything that makes me change my mind about the placing of the proposals. I only got time for one question about how I would implement the hardware platform for the t-stat. I've not addressed this issue much to this date as I realize this is not a electrical engineering class. I plan on keeping the hardware practical, useful but minimal in nature.I'd also not expect any of the other student to be heavily involved in that part of the project unless they want to. I thought I'd lay out the requirements for the hardware here so that it could be used for input into the software requirements later:
The t-stat will be based o a Microchip PIC16F877a chip which has on board the following:
Other requirements of the t-stat are
The t-stat will be based o a Microchip PIC16F877a chip which has on board the following:
- Multi-channel, 10 bit analog to digital converter
- A USART for serial communications
- 8K of Program memory
- 382 Bytes of RAM
- 256 Bytes of EEPROM
- Multiple on board timers with interrupt capability
- Up to 33 general purpose IO lines
Other requirements of the t-stat are
- LED 7 segement, 4 digit LED display for time and temperature
- Pushbuttons for user input
- Other LEDs to indicate mode
- Two temperature inputs (will be simulated by pots for now)
- An RS-485 com port
- A relay output for heat control
- A 5V power supply to power the unit
- Crystal oscillator for precision timing for RTC (Real time clock)
- An ICD connection port for debugging/programming
- A dip switch to set the units network address (4 place for 16 possible addresses)
Tuesday, February 15, 2011
Final Proposal Review
I used the scoring system outlined in my previous blog posting and evaluated all of the proposals. The order from best to worst least desirable and the respective scores are listed below. For ties in scores the proposals are just listed in the order that they were posted (no attempt to tie break). I left my score out of the listing as I had suggested in my previous post (but I did score myself high on the list, self-reflection can be good for the soul)
AR - 23
BFR - 22
JD - 22
DH - 22
JD1 - 21
E - 20
ALH - 20
RH - 20
KN - 19
NS - 17
SM - 17
GIA - 17
JD2 - 17
VS - 17
IG - 17
LAG - 16
EA - 16
ANS - 16
ED - 16
CJA - 15
TDG - 14
DWS - 13
MM - 12
WC - 11
AS - 11
K - 8
After I ranked all the proposals I want back to see which once came out on top. I was surprised with the results, but I think they are valid.
AR - 23
BFR - 22
JD - 22
DH - 22
JD1 - 21
E - 20
ALH - 20
RH - 20
KN - 19
NS - 17
SM - 17
GIA - 17
JD2 - 17
VS - 17
IG - 17
LAG - 16
EA - 16
ANS - 16
ED - 16
CJA - 15
TDG - 14
DWS - 13
MM - 12
WC - 11
AS - 11
K - 8
After I ranked all the proposals I want back to see which once came out on top. I was surprised with the results, but I think they are valid.
Monday, February 14, 2011
A Quick Proposal Review - Setting the Ranking Standards
I took the time this evening to scan through the other students proposals. I wasn't looking for detail this time through, I mostly wanted to get a general sense of what was being proposed. Once I got through the herd of zombies I found some real original ideas. Something I had not counted on was that as I was reading the proposals, the idea of who I would want on my team, and who I wouldn't want, was paramount in my mind.
I think I am going to base my rating on the following scores:
I really think that every student should abstain from ranking their own proposal, at least from the standpoint of establishing the rank in the class. We should all give ourselves a score as to how we compared to other students as part of the leaning process; self-reflection is always a learning experience.
PS: Sorry about the zombie comment at the beginning of this blog entry. The older I get , I guess the less influence pop culture has on me (something about old dogs and newzombie bones).
I think I am going to base my rating on the following scores:
- Is this project possible - Is it well defined enough, will it fit in the time line, do I believe the writer of the proposal knows enough to actually lead a team through this project.
- Presentation - A good presentation score could be considered "judging a book by its cover", but in this case I think it reflects on the writers ability to be a potential leader. A poor proposal could mean a poor final product. Not something I want to be involved in.
- Is it needed - Is there a good justification for this product even existing?
- Completeness - Did the writer actually follow the requested general format or did they just "wing it". Is there a time line and a budget that made sense.
- Excitement - Did I get excited about this project, would it be a fun project or just a coding exercise. Might as well enjoy the ride!
I really think that every student should abstain from ranking their own proposal, at least from the standpoint of establishing the rank in the class. We should all give ourselves a score as to how we compared to other students as part of the leaning process; self-reflection is always a learning experience.
PS: Sorry about the zombie comment at the beginning of this blog entry. The older I get , I guess the less influence pop culture has on me (something about old dogs and new
Preliminary Requirements Document
Due to the fact that my proposal describes a total system made up of three distinct software modules that all have to integrate together, there are some unique requirements for each sub piece.The three parts to the project are the embedded thermostat (t-stat), the web portal and the smart phone application.
General System Requirements:
Functional:
General System Requirements:
Functional:
- User Interface
-Out of the box interface (Default smart phone displays)
-DIY interface (Smart phone expansion capability)
-Hardware Platform interface (t-stat display and buttons) - Internal Security
-Web portal protection of server
-User log on - Reliability
-High Reliability handshake mode
-Embedded Watchdog - Hardware Platform, Programming Languages
-Microchip MPU Selection
-Web portal PC with Static IP
-Assembly (T-stat)
-Java (Web portal)
-Java for Android (Smart Phone) - Communication Protocol
-Custom t-stat to web portal
-HTTP with embedded data transfer protocol.
- Future Expandability
- Prototype to final product considerations - Coding Standards
- Bounding Conditions for Prototype
-Limiting factors used in project for prototype development - Documentation
-Protocols used
-DIY interface details
-Hardware schematics
-Web portal details needed to convert to future embedded web portal
Saturday, February 12, 2011
Final Proposal Posting
My final proposal is available at the following web site: Final Proposal Posting Site. All comments by the reviewers have been incorporated.
Tuesday, February 8, 2011
Class notes from 2-8-11
On Monday we talked about development of software requirements. We broke the start of this process down into a tree that looked like this:
A. Functional
1. User Interface
2. Time
3. Concurancy
4. Hardware/Platform
B. Non-functional
1. Documentation
2. Trademark/Legal
3. Aesthetics
4. Coding Standards
C. Testing
D. Security
My understanding was we are to add to this list or to expand on one or more issues listed. Being primarily an embedded programmer I'll give my take on a few of the issues listed:
Functional - Time: In reviewing information on the Android programming web site I watched a video on the do's and don'ts of android programming. One of the items that stood out to me was the need to have a "snappy" user interface. One of the things that drives me crazy with some of the new applications is the hesitancy in response to an operator action. Even if I can't expect an complete response immediately, at lest let me know something is happening. In the early days of web browsing the slow download speeds meant it took 10s of seconds for an image to download. The images came in as a blur that refined itself as data came in. Although annoying, at least you knew there was something going on (and that it was not time to reboot your Win 3.1 system again!). The video indicated that about 2 seconds was that maximum wait time, but in reality if something did not happen in about 200mS the operator would feel like the system was dragging.
Timing can become not only a user response issue but a critical issue in embedded controls for many other reasons. In the case of a communicating device the maximum and minimum response time can make or break an interface. Respond too quickly and the receiver may not be ready to listen. Respond to slow and the receiver may think that the responder is offline and retry or go on to the next transmission. This can be one of the most tricky things to test and validate. I have often resorted to an old fashion O-scope to diagnose this type of problem.
Functional - Hardware/Platform: Again in the embedded world this is a major issue. Even your "standard" programming languages like C undergo strange mutations in order to adapt to the special "features" of a given MPU. Finding a balance between a low cost chip and a chip with enough memory for the program can be an "Extreme Programming" problem ;). Pick too low, run into a memory overflow, and you may find that the entire project has to be slid into a whole new product line with a completely different hardware configuration. Things in the embedded world are getting bit better in the area, but still not a smooth transition. Maybe I should take the same attitude as Microsoft...memory is free, use as much as you want! Unfortunately the chip manufactures still think memory has a real cost associated with it.
I put a bit more in my blog posting on "Extreme Programming?" about tying requirements to testing so I won't go into that here.
I did not see a location to post our proposals on the main class blog yet. I'll just hold onto my final proposal until I see more info
A. Functional
1. User Interface
2. Time
3. Concurancy
4. Hardware/Platform
B. Non-functional
1. Documentation
2. Trademark/Legal
3. Aesthetics
4. Coding Standards
C. Testing
D. Security
My understanding was we are to add to this list or to expand on one or more issues listed. Being primarily an embedded programmer I'll give my take on a few of the issues listed:
Functional - Time: In reviewing information on the Android programming web site I watched a video on the do's and don'ts of android programming. One of the items that stood out to me was the need to have a "snappy" user interface. One of the things that drives me crazy with some of the new applications is the hesitancy in response to an operator action. Even if I can't expect an complete response immediately, at lest let me know something is happening. In the early days of web browsing the slow download speeds meant it took 10s of seconds for an image to download. The images came in as a blur that refined itself as data came in. Although annoying, at least you knew there was something going on (and that it was not time to reboot your Win 3.1 system again!). The video indicated that about 2 seconds was that maximum wait time, but in reality if something did not happen in about 200mS the operator would feel like the system was dragging.
Timing can become not only a user response issue but a critical issue in embedded controls for many other reasons. In the case of a communicating device the maximum and minimum response time can make or break an interface. Respond too quickly and the receiver may not be ready to listen. Respond to slow and the receiver may think that the responder is offline and retry or go on to the next transmission. This can be one of the most tricky things to test and validate. I have often resorted to an old fashion O-scope to diagnose this type of problem.
Functional - Hardware/Platform: Again in the embedded world this is a major issue. Even your "standard" programming languages like C undergo strange mutations in order to adapt to the special "features" of a given MPU. Finding a balance between a low cost chip and a chip with enough memory for the program can be an "Extreme Programming" problem ;). Pick too low, run into a memory overflow, and you may find that the entire project has to be slid into a whole new product line with a completely different hardware configuration. Things in the embedded world are getting bit better in the area, but still not a smooth transition. Maybe I should take the same attitude as Microsoft...memory is free, use as much as you want! Unfortunately the chip manufactures still think memory has a real cost associated with it.
I put a bit more in my blog posting on "Extreme Programming?" about tying requirements to testing so I won't go into that here.
I did not see a location to post our proposals on the main class blog yet. I'll just hold onto my final proposal until I see more info
Extreme Programming?
I took some time tonight to read through the Extreme Programming links from the class blog. It had some interesting ideas, but quite frankly sounded like standard engineering practices wrapped in some computer jargon. Maybe I missed the point or maybe I'm getting to old to be taught new tricks. That being said, I did glean a few ideas from the process; spike programs and the idea of writing test code before the real code. I guess I have used the idea of spike programs since my early days in programming, but never really gave them much thought, and certainly never a name. I remember writing my first for-loop as a stand alone program just so I could see how it worked before I integrated into my program. For our class proposal I did a simple spike program on my computer to assure myself that a custom web application was possible and not out of the scope of the class. The idea of writing a unit test program first is novel. I'm not sure I buy it yet, but it might be interesting to try sometime.I do agree with the concept that the general requirements for test programs should be an up front development process. When you define a requirement, I think it is a real good idea to at least rough out the test plan that will validate the requirement. If no test plan can be developed with a go/no go result, then the requirement was probably not a real requirement (or at least it might belong in the non-functional category). I did like the idea of making the test process an automated function. Most of my life I have manually tested my software through a test harness, sometime repeating the same manual test hundreds of times before completing a section of programming. An automated test program might have save me hundreds of hours of tedious work. I could see some application for this in my proposed class project by providing a simulation and test results of each of the project sections without the need to integrate for each test. If my project is selected I will talk to the team about this option.
Friday, February 4, 2011
Class Canceled - but life goes on!
Classes were canceled this Wednesday and Friday due to the gas shortage in the state of New Mexico. Unfortunately real life continued with my real job dragging me all around the Los Alamos Labs trying to keep buildings from freezing and server rooms from roasting. Sorry fellow student for the delay in getting your reviews out. What pays the bills takes the priority.
Review of Ekaterina Davydenko’s Proposal
Allen Hayward’s Review of Ekaterina Davydenko’s Proposal for CS-460
Summary: The proposal is to develop an automated dynamic traffic control system that would provide improvement in traffic flow under varying conditions. The system would include interfaces for future development of emergency vehicle override capability and historical data collection interfaces used for tuning of the system. The system would use road sensors and remotely automated displays to tune road speeds and redirection of drivers to maximize throughput of existing road systems.
Scores based on a 1 to 5 rating with a 5 being the best
Syntax = 4: Technical information is well presented. Some sentences lack smooth reading flow. Has a nice content, figures list and general format.
1. Page Numbering – The use of roman numerals for the cover pages should not flow into the Arabic numbering used on the body of the proposal. Restart the Arabic numbering at page 1 where you have page 4 now.
2. General – Proposal guidelines from professor specified 12pt text and double spacing.
3. Page 5 – First paragraph, second sentence – “number” should be “numbers”
4. Page 5 – Third paragraph – After traffic add the word “conditions”, After commutes add “have become”. Change “conjunction” to “junction”. Delete “certain” from last sentence
5. Page 6 – Change the word “harmonization” to “harmonized” is several locations. Last paragraph, change “initiative” to “innovation”. Change “fully” to “full, ”.
6. Page 9 – First paragraph, change “The system that we design will…” to The system design will…”
7. Page 11 – the second paragraph indicates three weeks for implementation but the gnat chart seems to show 4 weeks.
Disclaimer – Being an engineer my proof reading skills are not the best. Consider having someone with real writing skills look at this proposal for grammar, spelling and punctuation.
Plausibility = 3: I believe with the right team and some work on better definition of scope this is a very viable project. The biggest problem is not having the full scope defined. This will impact the size of the project greatly. See Scope below for more details
Support = 4: The proposal was adequately supported by citing other examples of similar systems already implemented or in the process of implementation. The system does not push the limits of current technologies too far and thus is relatively safe. The challenge is more an issue of scope. The writer provided adequate programming experience background information to make it clear she is qualified for the job.
Novelty = 2: Based on the fact that other systems are already in place this is not a very novel project. If more details on how AI might be implemented to solve the problem this might make the system more unique. Traffic light coordination is commonplace in big cities already. Tacoma, WA had traffic light coordination implemented back in the 80s.
Stakeholders = 3: It seems a system of this type would have many regulations from the DOT thus probably gaining it’s funding from the DOT. I could easily see this being a government-funded project. This project has a definite interface with the public, as such the public is a big part of the stakeholder group and will want to be part of the design of this type of project. No mention of public feedback was included.
Scope = 2 : Being such a large project it is necessary to ensure that the scope is clearly defined. Certainly the entire implementation of such a system is far from the scope of this class. Consider redefining the project as a small-scale prototype based on a specific implementation (i.e. a set of 10 traffic lights or a 10 mile stretch of highway with a fixed number of on/off ramps or maybe a selected actual part of an existing cities roadway (Trinity Drive?)). Clearly define the number and type of feedback/output devices. Also indicate what will be used to test the system. Are you really going to setup a functional system or simply provide simulated data to the system to prove it works? What will be the proof that your system does what it says it will (10% improvement in traffic flow)?
Profit = 5: If such a system was constructed and proved to be viable I could see a significant profit for such a system. I could see ongoing improvements and maintenance of systems of this type turning into a potential new market place with significant growth possibility.
Legality = 1: Although not to be a big issue in this class, the reality is this system has the potential for significant legal issues. Automated signs going dark or miss informing drivers could result in traffic accidents and possible fatalities. This should at least be mentioned in the challenges section of the report. All systems fail eventually, what is the risk and how will the risk be mitigated? You can push a lot of this out of this project by indicating that it is a prototype and will not be used in actual traffic control at this time. (low score due to not mentioning it, easy to fix)
Security = 1: Another big issue for this system is how secure is it. Hacking a system of this type could result in brining traffic to a halt in a big city with major impact to the city’s reputation and its ability to conduct commerce. Being known as the “most hacked city” is not a good thing. At least mention the need for security to assure your customer that you understand the potential issues that must be addressed. (low score due to not mentioning it, easy to fix)
Expense Budget:
A budget number is provided but it does not have a breakdown of how it was developed. As an investor I’d like to see how a large number of $120K was developed. That would give me some assurance that this was a real number and not just a wild guess.
Time Line: Correct format and reasonable but could use some more detail.
Other considerations: You did not mention that fact that by improving traffic flow the need for road upgrades could be deferred or eliminated by making the existing infrastructure capable of carrying traffic more effectively. Also have you considered the need to tie the system into the road construction department? A busted water main (i.e. main hill road last week) needs to be inputted into the system quickly so it can reroute traffic. Also, planned road construction should be easy to input in to the system so that it can compensate for it.
Review of Katherine Nystrom's Proposal
Allen Hayward’s Review of Katherine Nystrom’s Proposal for CS-460
Summary: The proposal is to develop a recipe organization program with unique features directed at the food blogger community. The program will either work as a home computer based system or a web-based service. Based on Katherine’s experience I believe she would be capable of directing a team for this project. Her insight into the food blogger world would be of utmost importance to ensuring the success of the project.
Scores based on a 1 to 5 rating with a 5 being the best
Syntax = 5: Well written with very few typos or recommended enhancements.
1. Page 1 – change the word would to will in the first sentence. Make the reader feel like this is something that will happen. A proposal is a sales pitch – “I can see you driving home in this fine car today…”
2. Page 1 – add comma after the word however in the second paragraph or consider rewriting this sentence. I had to read it a few times to get the meaning.
3. Page 2 – Change dash between $80 and free to the word “to”. It makes the sentence more readable.
4. Appendix 1 – No reference in main body of text or header describing what the appendix is for. Add a title and make a reference from the main body of text.
Disclaimer – Being an engineer my proof reading skills are not the best. Consider having someone with real writing skills look at this proposal for grammar, spelling and punctuation.
Plausibility = 4: I believe with the right team this is a very viable project. It might need to be paired down to either the home-based computer version OR the web based implementation to fit within the time line. My lack of web-based design may be showing in my recommendations.
Support = 4: Supporting details were provided in terms of why this is a viable product in the body of the text as well as indications of detailed background investigation were provided in appendix. The writer’s qualifications are spelled out as part of the proposal.
Novelty = 2: I’m not sure that I could completely identify what made this project novel. I recognize that it is intended to be directed towards the food blogger community, but I had a hard time identifying the difference in needs between the “home cook” and the “food blogger”. This may be because of my lack of knowledge in this field (even though I do watch the food channel almost every night). The proposal should provide the details the reader needs to fully understand what makes it novel with the assumption that I am neither a “home cook” nor a “food blogger”.
Stakeholders = 4: Stake holders in terms of end users is well defined, Stake holders in terms of business arrangements could use some additions. How will this be funded – the venture capitalist should identified as the funding source (at least in this class room scenario). When I finished reading the proposal I didn’t feel like I had been asked to contribute to the project as an investor. Would this software be the basis of a new company or a one shot development and placed on a vending web site? Maybe just a bit more roll playing is needed.
Scope = 2 : After reading the proposal twice through I still not feel like I had a good picture of the scope. I recognize that the proposal indicates that the team would have a lot of input into how this application would be “fleshed out”. In my past experience the proposal either becomes the contract or is a major input into the contract. If it is not very clear, both sides have a bad time identifying when the agreement has been fulfilled. You stated many things that the current products do; will these be part of your project? Identify exactly what new features will be added or at least provided some concrete examples of where you will be guiding the team in trying to make the product “food blogger friendly”.
Profit = 3: I believe the statement that there is a large market for this improved product does exists. The fact that cable television has an ever-growing number of shows dealing with cooking is a good sign of this growing niche market. You provided a list of current product and prices, but never stated what you though the target price might be for this product. As an investor this is a detail that I would be interested in. I think this is targeted towards a mid to upper cost bracket, but you never stated this.
Legality = 5: Probably not a big issue for this project. Only issue might be security of personal recipes. Maybe a small mention of providing a protection for this might be in order, but not a big deal (unless KFC decides to use it to store their secret recipe of 11 herbs and spices in your program).
Security = 5: See legality above
Expense Budget:
I’d recommend that the software developers’ budget indicate the anticipated number of hours and at what rate. Also several of the line items are $0, which is probably unrealistic. Taxes will always be a cost but you can defer that part of the cost to the customer (i.e. investor) by stating that it is as an additional cost not included in the budget. Office supplies, like paper, blank CDs for backups, pencils (which your employees will take home in their pockets), ect is a real expense. Web server space is also a real expense that should be accounted for.
Time Line: Well laid out. Getting it into a more readable format would be helpful.
Sunday, January 30, 2011
Requirements Homework
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.
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.
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)