Software Development and Engineering Blog


HW28: Chapter 25

Sam Word | 21 Nov 2017

HW27: Chapter 24

Sam Word | 16 Nov 2017

HW19: Team Progress II

Sam Word | 14 Nov 2017

HW25: Chapter 23

Sam Word | 09 Nov 2017

HW24: Chapter 22

Sam Word | 06 Nov 2017

HW22: Chapter 21

Sam Word | 02 Nov 2017

HW19: Team Progress I

Sam Word | 31 Oct 2017

HW21: Chapter 20

Sam Word | 26 Oct 2017

HW20: Chapter 19

Sam Word | 24 Oct 2017

HW18: Chapter 18

Sam Word | 18 Oct 2017

HW17-B: Chapter 17

Sam Word | 11 Oct 2017

HW17-A: Chapter 16

Sam Word | 08 Oct 2017

HW16: Chapter 9

Sam Word | 05 Oct 2017

HW15: Chapter 15

Sam Word | 02 Oct 2017

HW14: Testing Reflections

Sam Word | 28 Sep 2017

HW13: Chapter 8

Sam Word | 28 Sep 2017

HW12: Mythical Man Month

Sam Word | 26 Sep 2017

HW11: Chapter 6

Sam Word | 21 Sep 2017

HW10: Chapter 5

Sam Word | 13 Sep 2017

HW9: Reflections

Sam Word | 12 Sep 2017

HW8: Chapter 2

Sam Word | 12 Sep 2017

HW7: Reflections

Sam Word | 07 Sep 2017

HW6: Chapter 4

Sam Word | 07 Sep 2017

HW5: Reflections

Sam Word | 05 Sep 2017

HW4: Chapters 11 & 12

Sam Word | 30 Aug 2017

HW3: Chapter 10

Sam Word | 28 Aug 2017

HW2: Responses

Sam Word | 27 Aug 2017

HW1: Chapter 1

Sam Word | 24 Aug 2017

HW0: Introduction

Sam Word | 23 Aug 2017

HW7: Reflections


07 Sep 2017

Articles

Reflections

All of these articles, except the Wikipedia article on The Magical Number Seven, Plus or Minus Two, revolve around building safe, secure, and reliable software. In fact, the first recommendation for creating secure tire pressure monitoring systems in Security and Privacy Vulnerabilities of In-Car Wireless Networks was to follow basic reliable software design practices. They noted that impossible values were allowed to be displayed in the studied tire pressure monitoring systems. Had reliable software design practices been followed, some of the more obviously incorrect test cases could have been avoided. One possible reliable software design practices that could be used to design future tire pressure monitoring systems is test-driven development (TDD). The idea behind TDD is tests are written before development, and development is centered around tests, and tests must pass before development can continue. Ideally, the case where a valid tire pressure that also displays a tire pressure warning flag should have been caught before developing the system, and a test would have been written for that case in TDD.

Five years after Security and Privacy Vulnerabilities of In-Car Wireless Networks was published, the SPY Car Act was enacted. The SPY Car Act is essentially a federal regulation to ensure sensors and other computer systems in vehicles are secure. It even outlines a specific design principle to ensure vehicles remain safe in the event of an attack: “ISOLATION MEASURES.—The measures referred to in subparagraph (A) shall incorporate isolation measures to separate critical software systems from noncritical software systems.” This would ensure that if something like the tire pressure monitoring sensors were spoofed, the safety-critical systems in the car would retain their integrity. Ensuring a system is safe and secure also ties in with the notion of reliable systems. If a system is unsafe, or can easily be attacked, it has the potential to not function as specified, making it unreliable. Reliable systems must be able to fail gracefully, that way when the system is down for whatever reason, it causes as little trouble to its users as possible. Mike wood outlines multiple ways to handle failure in software systems in Preparing for the Future, and stresses that failure is not a matter of “if”, but “when.” After reading through each of the techniques, it became clear to me that regardless of what technique is implemented in a system to prevent or handle failure, those techniques are useless if the use case for the cause of failure was not foreseen. This is where, I believe, TDD is a useful software development practice for creating reliable software.

I also believe TDD supports the idea that humans have a hard time keeping more than seven—plus or minus two—objects in active memory at once. In TDD, you think of several test cases to develop code to pass those test cases, and repeat. This allows a developer to focus on test cases alone before worrying about the implementation of a system to pass those test cases. If we develop in a way that mirrors how much we can think about at one time, then the resulting system should be more reliable, safe, and secure.