> Readings:
Magical Number 7 - Wikipedia page
Security and Privacy Vulnerabilities of In-Car Wireless Networks: A Tire Pressure Monitoring System Case Study by Rouf, Miller, Moustafa, Taylor, Oh, Xu, Gruteser, Trappe, and Seskar
Spy Car Act of 2015 - Law
Planning for Failure in Cloud Applications by Mike Wood
Introduction to Test Driven Development (TDD) by Scott Ambler
And our trusty textbook, Software Engineering by Ian Sommerville
Chapter 4
Chapter 4 of the textbook highlighted the differences between functional requirements (what a system MUST provide to work) and non-functional requirements (external, organizational, or possibly product requirements that aren't necessary for the correct functioning of the system, but are required anyway for some other reason). Commonalities between the articles we read for today include an argument for a standardized system of reliable software practices in order to avoid overcomplicating projects and clarifying project specifications. System failure is possible no matter how much testing is done on it - there is no plausible way to test every single scenario that will be run through a system and decide with certainty that it is 100% secure.
Non-functional requirement such as security precautions were discussed at length in the articles on the Spy Car and Tire Pressures. It seems like these systems were created without taking proper precautions against hackers - had their designs been thoroughly scrutinized by experts, maybe some of the vulnerabilities wouldn't be so devastating to the security of the system. I thought the point they made about hackers having all the time in the world to penetrate systems was a good one - the engineers have a time limit due to the need to get products out on the market whereas hackers can spend months trying to break their way into “secure” systems.
With regards to Test Driven Development (TDD), at first I thought it seemed like a backwards way of approaching a problem. Usually, when I code (in my newbie way), I write little bits of code at a time to solve a problem, and I test it along the way. For TDD, requirements and tests are written even before the code is functioning in any way. After reading more about it, it actually seems like the best way to do it! Even if it seems a little bit slower, it is much harder to make mistakes with this kind of development strategy. If your program has holes in it, it is because the requirements had holes in them.
Since reading the “Magical Number 7” Wikipedia page, I have been trying to memorize things (like people’s names - because I am terrible at that, and some ridiculous Biology 112 facts about botany that I had an exam for) by repeating them seven times. And I think it is working! More on that later, I suppose (after the Biology exam is returned…).