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:

• 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.

Non-Functional

• 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

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.

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

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.  

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.