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