HW9: Reflections

+Readings:

>Reflections:

The article “9 Predictions for the Future of Programming” by Peter Wayner on InfoWorld.com delves into some interesting technology trends. I highly enjoyed his comment that, in the future, smart phones will do everything except make phone calls. It does seem like nowadays, with all the other ways to communicate, speaking on the phone has lost the attraction it once had. It seems rude that it took so many years of work to be able to hear someone's voice from miles away over a telephone line, but now we don't care about that and would rather not talk verbally at all. 

Prediction 1: The REST protocol will take over all of the IoT until something better comes along. Representational State Transfer (ReST) is an architectural style for designing networked applications that is able to share information over server ports. This seems like just another way we are going to be mapping our world in the future - if everything can deliver data to a larger database, then we are just working towards a more defined universe. Although I study computer science and I love the problem-solving aspect of it, I believe our species has become too dependent on technology and I worry about how much we will forget in the future. 

Prediction 3: Video killing the HTML star? I don’t know about that. HTML needed an update anyway - hyperlinks and mass amounts of text are no longer what we want as a culture. People are very lazy when it comes to retrieving information, I think. Why spend an hour reading articles on what is going on in the world when a nice 5 minute news reel from BBC News can explain it all? The popularity of videos is not a bad thing, in my opinion - anything that creates a wider need for creative jobs shouldn’t be looked at as a bad development for our culture. Televisions and especially television channels are going to be a thing of the past in 20 years, I think. I don’t watch much television, but I don’t see it lasting very long - I would much rather hop on my laptop and search for videos I want to watch rather than have to click through television channels to find something I don’t want to watch anyway.

Prediction 5: This is continuation of what I was saying about the IoT changing the way the world around us is recorded and collected into databases. In the next few years, we will gather such an incredible amount of data about absolutely everything. From the patterns of traffic in our city to reviews on our Uber drivers - it is all going to be collected. I don’t like what Wayner said with regards to the police: “the police will have more data than ever about the people walking on the streets”. It seems that privacy will be a thing of the past. We won’t need any kind of “Big Brother” scare because Big Brother will be an out in the open for all to see: we will know that whatever we are doing, seeing, writing about, texting about, tweeting about, will be logged into the system. I suppose with the lack of privacy will come a kind of openness, an honesty. At least, in theory - if some people are guaranteed more privacy than the rest of us, then I am sure we will still have problems, but one can still hope!

HW8: Chapter 2

2.1 > Suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems. Explain your answer according to the type of system being developed:

  • A system to control antilock braking in a car - the waterfall process is usually adapted for safety-critical systems because of the higher amount of analysis and documentation required before implementation. Because testing is a huge part of finalizing the software, it seems the waterfall model is the most appropriate generic software process. 
  • A virtual reality system to support software maintenance - software maintenance is best done through versions and updates over long amounts of time, which would be the incremental development process.
  • A university account system that replaces an existing system - the integration and configuration process seems like it would be the best choice for a new account system as it takes reusable components (like formulas and sums) and integrates them into a new system and setting.
  • An interactive travel planning system that helps users plan journeys with the lowest environmental impact - I think this could be more than one of the software process models, but I will say incremental development. A planning system would need to be adaptable and have multiple versions.

HW7: Reflections

> Readings:

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…).

HW6: Chapter 4

4.5 > Using the techniques suggested here, where natural language descriptions are presented in a standard format, write plausible user requirements for the following functions:

  • An unattended petrol (gas) pump system with a credit card reader. The customer swipes the card through the reader, then specifies the amount of fuel required. The fuel is delivered and the customer's account debited.

    • Function > Charge customer for amount of gas specified; dispense correct amount of gas.

    • Description > Computes the charge for the specified gas amount.

    • Inputs > Specified amount of fuel required; credit card information.

    • Source > User interface system on gas tank; credit card reader.

    • Outputs > Gas; amount to be charged to card (receipt).

    • Destination > Customer's car; customer's bank.

    • Action > Customer will input the amount of gas they require, program will calculate the charge for the amount of gas, customer will swipe credit card, gas will be put into the car, credit card will be charged, receipt printed for customer.

    • Precondition > Gas amount desired must be available in the gas tank; credit card number must be verified before transaction, before gas is dispensed.

    • PostCondition > Amount taken from gas tank must be subtracted; charge must be applied to card; specified amount of gas must be dispensed.

  • The cash-dispensing function in a bank ATM.

    • Function > Dispense correct amount of cash.
    • Description > Verifies the cardholder's pin number and dispenses the amount of cash desired.
    • Inputs > Amount of cash desired; debit card number (via debit card input); pin number.
    • Source > User interface; debit card reader; pin pad.
    • Outputs > Cash; receipt; debit card.
    • Action > User inputs debit card; user inputs pin; user selects amount of cash desired; ATM checks if user's account has enough cash to be dispensed; ATM checks if ATM has enough cash to be dispersed; ATM dispenses cash if these checks are passed; user receives debit card; user receives receipt. 
    • Precondition > User must have enough money in their account; ATM must have enough money; user's pin number must be correct.
    • PostCondition > Amount of cash in ATM must be subtracted; transaction must be recorded.

  • In an internet banking system, a facility that allows customers to transfer funds from one account held with the bank to another account with the same bank.

    • Function > Transfer specified amount of money from one bank account to another, only if accounts belong to the same bank.

    • Description > Transfers funds from one account to the other.

    • Inputs > Username; password; bank account to be transferred to; amount to transfer; submission.

    • Source > Reading of amount to be transferred; true if both accounts with the same bank.

    • Outputs > Receipt of confirmation sent to user.

    • Action > User logs onto online banking system; password is verified; user must choose to transfer funds; account to be transferred to must be declared; other account my be checked that it is with the same bank; amount to be transferred must be declared; funds must be transferred; user sent an email confirmation that the transfer went through successfully/unsuccessfully.

    • Precondition > User must log into the bank system; user must have funds to transfer; other account must belong with the same bank.

    • PostCondition > One account is subtracted from while the other is added to.

4.6 > Suggest how an engineer responsible for drawing up a system requirements specifications might keep track of the relationships between functional and non-functional requirements.

The engineer could use a table to differentiate between non-functional and functional requirements or some visual system that clearly defines the differences between the requirements. They can also keep track by using other graphical models such as a UML diagram, sequence, or state charts. Being able to visually see how different requirements affect the system as a whole will help the engineer clearly define the specifications of the project for himself, other engineers, and the client.

4.7 > Using your knowledge of how an ATM is used, develop a set of use cases that could serve as a basis for understanding the requirements for an ATM system.

  1. User inserts debit card into the ATM
  2. ATM reads card; asks for pin number.
  3. User inputs correct pin number.
  4. ATM verifies pin number; ATM asks user for what they want to use the ATM for:
    • Withdrawal OR
    • Balance check OR
    • Deposit
  5. User chooses an option.
    • User enters amount to withdraw OR
    • User asks for account balance OR
    • User inputs amount to deposit
  6. ATM
    • Checks if there are enough funds to withdraw that amount from and, if there are, releases money to user  OR
    • Prints receipt of account balance OR
    • Accepts deposit and prints receipt
  7. User receives debit card back. Transaction over.

HW5: Reflections

+Readings:

  • An Investigation of the Therac-25 Accidents by Nancy Leveson and Clark S. Turner
  • After Stroke Scans, Patients Face Serious Health Risks by Walt Bogdanich
  • Motor Vehicles Increasingly Vulnerable to Remote Exploits - FBI Public Service Announcement
  • The Role of Software in Spacecraft Accidents by Nancy G. Leveson
  • Who Killed the Virtual Case File? by Harry Goldstein
  • FBI Sentinel project is over budget and behind schedule, say IG auditors by Jeff Stein
  • Years Late and Millions Over Budget, FBI's Sentinel Finally On Line by Damon Poeter
  • FBI’s Sentinel System Still Not In Total Shape to Surveil by Robert N. Charette
  • Software Engineering (Ian Sommerville): 
    • Chapter 12: Safety Engineering
    • Chapter 13: Security Engineering  

>Reflections:

          The above readings involve investigation into a variety of software-related accidents, from spacecraft crashes to threats of potential accidents like hacking modern automobiles. The articles, although varied, share some common important viewpoints about the importance of proper safety and security techniques needed to design and implement dependable software. Chapter 12 of our textbook introduces the concept of safety-critical systems: “the system should never damage people of the system’s environment, irrespective of whether or not the system conforms to its specification” (Sommerville 327). Closely related, a dependable system is secure if it protects the confidentiality of its information, the information cannot be changed by an unauthorized person, and the system is always available for use as intended (Sommerville 360). Flaws in a system’s security can also drastically affect the safety, as the FBI’s Public Service Announcement on the cyber security threats to modern motorized vehicles announced. The above articles go into detail about how software systems were implemented incorrectly, what (sometimes devastating) accidents resulted, and what could have been done differently to avoid these accidents.

          Commonalities between articles include bad management of software design where the developers reused old code and did not stick to the golden rule of simplifying everything; lack of communication or even understanding during program testing; a general complacency and time- integrity trade offs resulting in code functioning in less-than-optimal ways. Most of all, information on these accidents is very hard to find which leads people into a false sense of safety and security.

          Leveson and Turner’s article highlighted software-related accidents that resulted in deaths or serious injuries of patients exposed to the Therac-25, a radiation therapy system released in the 1980s. They point out that the software from the earlier model, Therac-20, was reused even though Therac-25 was given more responsibility for maintaining safety than previous models. Leveson’s article on the role of software in software-related spacecraft accidents also highlights how software for the Ariane 501 (which crashed) was reused from the Ariane 4, even though the functions (although useful) were not needed in either models (Leveson 2). With regards to the FBI and SAIC’s Trilogy fiasco, they relied on connecting useless software together to get a majorly complex system to run. All of these examples illustrate the inability to develop safe and secure software if the developers rely on previously created code - the code may work reliably, but it might not reliably do what it is intended to do.

          Another thing I wanted to discuss was the lack of openness about information. Some of the Therac-25 accidents and the accidents involving radiation overdoses of the patient’s receiving stroke scans (Bogdanich’s article) show an alarming degree of hiding information from the public, professionals using the software in the field, and just a general complacency and avoidance of checking and rechecking the safety of systems. Even the one guy (Patton) who tried to say something about the FBI’s lack of ingenuity with the Trilogy project was then put under federal investigation. Or the example of the Mars Climate Orbiter, which was checked and found faulty right before take off, but since there were no set-up lines of communication, the person who found the fault was unable or did not care enough to call someone who could actually take care of the problem.

          With regards to security, the articles describing the long-term building of the FBI’s Sentinel software and the PSA about motor vehicle hacking show that the desire to develop secure software comes after the release of the software, not before. Both examples explain that, although some work went into protecting important things like confidentiality and availability, there was a time-constraint to release the software and therefore not enough penetration testing could have been done to ensure the security of the systems. As discussed in the textbook, testers must also test the system, not just the security of the system, and therefore have less time to discover vulnerabilities that are open to exploitation. A hacker, however, has all the time in the world to poke and prod at the system, testing it for weakness (Sommerville 389).

          So, although this has been a long rant about the various problems in all these projects, a few things stand out: rewriting code seems to be the better way of avoiding past problems (whether the problems were detected or not), software development teams need to be open about communicating problems and also work very closely with testers to ensure that the correct thing is being output for tests to pass, and that more time and effort need to go into developing secure systems.