HW4: Chapters 11 & 12

11.4 > What is the common characteristic of all architectural styles that are geared to supporting software fault tolerance?

A system that provides fault tolerance will include redundant and diverse hardware and software.

11.7 > It has been suggested that the control software for a radiation therapy machine, used to treat patients with cancer, should be implemented using N-version programming. Comment on whether or not you think this is a good suggestion.

Implementing multiversion programming to check a process as important as radiation therapy seems like a very good practice. If there are multiple systems all running on diverse hardware, yet all configured to the same settings, then if more than two systems come up with the same output, the output should be correct. I am not sure how many would be required to produce the same output, but based on probability, the more machines required to produce the same output, the safer the program and therefore, the safer the human receiving treatment.

11.9 > Explain why you should explicitly handle all exceptions in a system that is intended to have a high level of availability.

Because a system will shut down execution if an exception has not been handled, software developers must provide exception handlers for all detected and possible exceptions that may arise. If the software fails and the system shuts down, it is not highly available as it was intended to be.

12.5 > A train protection system automatically applies the brakes of a train if the speed limit for a segment of track is exceeded, or if the train enters a track segment that is currently signaled with a red light (i.e. the segment should not be entered). There are two critical safety requirements for this train protection system:

The train shall not enter a segment of track that is signaled with a red light.

The train shall not exceed the specified speed limit for a section of track.

Assuming that the signal status and the speed limit for the track segment are transmitted to on-board software on the train before it enters the track segment, propose five possible functional system requirements for the onboard software that may be generated from the system safety requirements.

1. Check whether the signal status is green for the upcoming section of a track (a)
2. Check whether train is going faster or slower than the intended speed limit for that section of track (b)
3. If (b) calculates that the train is going faster, apply brakes gently
4. If (b) calculates that the train is going slower, speed up gently
5. If (a) is red, search for another option of track segment that has a green signal status
6. If either (a) or (b) are not within the critical safety requirements, alert the human conductor

HW3: Chapter 10

10.6 > Explain why it is reasonable to assume that the use of dependable processes will lead to the creation of dependable software.

By using known working solutions to a problem, software gains dependability and therefore validates the software field and reduces distrust in the community against it. Dependable processes that promote availability, reliability, safety, security, and resilience in software are essential to maintaining the industry and the practice of software development. If, for example, the automobile industry had lost user support due to faulty processes, crashing, easily being stolen, breaking too easily, and being hard to find, then it would not have been such a successful industry. Software engineering's future relies on being dependable and wanted by the community.

10.10 > It has been suggested that the need for regulation inhibits innovation and that regulators force the use of older methods of systems development that have been used on other systems. Discuss whether you think this is true and the desirability of regulators imposing their views on what methods should be used.

Being from a design background, I would like to say that restrictions on innovation and regulation of methods inhibit an industry's ability to progress. However, I agree that some regulations are necessary - understanding the history of proven methods of system development is crucial for progress. Under the ACM's SE Code of Ethics's Principle 6 with regards to obligations in one's Profession, a software engineer who is not using proven, dependable solutions would be violating this code. It states:

6.07. Be accurate in stating the characteristics of software on which they work, avoiding not only false claims but also claims that might reasonably be supposed to be speculative, vacuous, deceptive, misleading, or doubtful.

Anyone practicing software development of engineering who uses methods that are not dependable risks the wrath of the public against the industry in general. This builds a lack of faith in the ability of software engineers and it is obvious why the ACM wishes to regulate these practices, regardless of opinions about inhibiting innovation. It would be nice if it was a free world of no consequences, but when mistakes are made to the detriment of many engineers' careers (including possibly my own one day!), it seems like having regulations in place is not too horrible of a precaution. 

HW2: Response

Linked to: Steven Fraser, Dennis Mancl, "No Silver Bullet: Software Engineering Reloaded", IEEE Software, vol.25, no. 1, pp. 91-94, January/February 2008, doi:10.1109/MS.2008.14

Article written 20 years after Brooks's - IEEE panel discussing the advancement in software development since the time of the original "No Silver Bullet".

A common theme between Brooks’s “No Silver Bullet”, Neville-Neil’s “Kode Vicious”, and Potvin and Levenberg’s “Why Google Stores Billions of Lines of Code in a Single Repository” is that they argue for the benefits of starting small and growing incrementally over time with regards to software and its development. All authors also advocate the importance of having a history of previous versions of the software, where, by making small commits at a time, the software’s integrity is maintained and, if something were to go wrong, it is easy to recover older versions. Neville-Neil claims that all code versions should be stored, “backed up, in some version-controlled way” (Neville-Neil, 33). His argument is corroborated by the “Google Repo” article where the authors explain at length the many advantages to vigilantly maintaining a monolithic repository such as Google, which stores a history of code versions and also makes it possible for a worldwide team of developers to collectively work on a single code source. 

Brooks’s insight adds to this by praising the concept of growing, not building, software - he advises that developers start small and first have a working base, then add to this to avoid problems of over-complication and possibly missing the entire point of a software’s purpose. He, like Neville-Neil, believes in the merits of science, and argues that software developers should look for inspiration amongst nature’s complexities. One such construct to admire is the brain:

“The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and self-renewing. The secret is that it is grown, not built” (Brooks, 18).

He advocates “top-down design, for it is a top-down growing of the software” (Brooks, 18). In saying this, his argument aligns with Google’s approach to developing and improving their code-base. All authors are in agreement that well-designed, maintainable code that adapts to the user or client’s needs is grown from a single base source, edited in small batches, tested, and merged to the master source.

These readings share the theme of “standing on the shoulders of Giants” (Isaac Newton) where they encourage not only growing software out of one main construct and merging any changes to the “head”, but also using a highly collaborative methodology for software development. In the “Google Repo” article, the authors argue that “The monolithic model of source code management is not for everyone. It is best suited for organizations like Google, with an open and collaborative culture” (Potvin and Levenberg, 87). Code sharing and reuse is widely encouraged in such an atmosphere, enabling developers to learn from each other and saving redundancies in problem-solving across the Google development environment. Similarly, Brooks’s argument calls for cultivation of great designers of software and advises that a step in the right direction would be to “provide opportunities for designers to interact with and stimulate each other” (Brooks, 18). He argues for the collaboration of creative minds in order to design software that serves as a step in the direction of finding the “Silver Bullet” for hideously gnarled software architecture. The authors collectively make an argument for not just implementing unstable quick fixes for software that has already gone monstrously wrong, but systematically address the problems that lurk below badly designed software architecture.

HW1: Chapter 1

Ah! I am a little late posting this homework - curse the postal system and its late textbooks. Anyway, our textbook is the 10th Edition of Ian Sommerville's Software Engineering publication.

Here are answers to our homework exercises on page 26:

1.3 > What are the four important attributes that all professional software should possess? Suggest four other attributes that may sometimes be significant?

The four most important characteristics of professional software are Acceptability, Dependability and Security, Efficiency, and Maintainability. Other examples of quality attributes are the software's Performance, Scalability, Reuseability, Testability, Reliability, and Availability.

1.8 > Discuss whether professional engineers should be licensed in the same way as doctors or lawyers.

I do not believe professional engineers should be licensed in the way that doctors and lawyers are. The years that doctors and lawyers spend being educated have a greater importance in their ability to practice because they build their knowledge gradually. In order to be a doctor or a lawyer, one has to make decisions quickly in tough situations and be able to call on those years of experience working towards their license. For professional engineers, software is a time consuming, designed process that is not released to the public unless it is completed, tested, and tested again. And it is available to update as time goes on, unlike the practices of lawyers and doctors. Requiring engineers to be licensed would ensure less professional software engineers in the world and we do not have that leisure - software is in demand now.

1.9 > For each of the clauses in the ACM / IEEE Code of Ethics shown in Figure 1.4, propose an appropriate example that illustrates that clause.

• Public > An example of acting in the public's interest is not to share any private information that the software engineer is privy to while working on a project.
• Client and Employer > A good software engineer will not let the needs of the client or the wants of the employer harm the public.
• Product > A good software engineer would not allow software to be released that they know is faulty and will crash.
• Judgement > An example of using good judgement is, if a software engineer is approached by a client that wants them to build software that causes airplanes to crash, the software engineer knows that they must decline since although that may be in the client's interest, it is not in the public's.
• Management > For example, Software engineering managers and leaders will not encourage employees to slack off when they are aware there is a deadline coming up.
• Profession > For example, software engineers will not accept payment for inadequate software that they have admitted will not work as intended. This would reflect badly on other software engineers.
• Colleagues > An example of following this clause would be a software engineer not stealing their coworkers code without permission.
• Self > For example, a good software engineer will keep up with changes in technology and encourage others to do the same.

View fullsize

Figure 1.1 > Helpful table with some commonly asked questions about software engineering.

 1.10 > To help counter terrorism, many countries are planning or have developed computer systems that track large numbers of their citizens and their actions. Clearly, this has privacy implications. Discuss the ethics of working on the development of this type of system.

Let's say you are a software engineer that has been assigned to work on this kind of system - you have been told that although it may seem like it's not in the public's interest because it invades the public's privacy, it actually is in their interest because it will keep them safe. 

If you are wholeheartedly against implementing software that invades the privacy of others, then hopefully you can opt out of the project without losing your job. Maybe your employer can convince you that the pros outweigh the cons for this type of system and show you why they are acting in the public's best interest and are not violating the Code of Ethics. Because of extreme variations in opinion, it is hard to engineer software that everyone is going to agree with. For a doctor, the ethics are a little simpler: do whatever you can to make a patient healthy. For software engineers, there is a little more debate when it comes to ethics.

HW0: Introduction

Instagram Post from CSCI230 Data Structures and Algorithms  - we created a program to solve a puzzle from any given starting point! Toy programs like this are only the beginning, I'm sure... I just love the puzzle-solving aspect of it.

Welcome to my blog! As a side note, I never really wanted to keep a blog - sometimes I believe everyone in the world talks too much and listens too little... But here we are! Thank you, Dr. Bowring for forcing all of us CSCI 362 students out of our shells and letting us loose on the internet. Let us hope someone out there enjoys our musings over Software Engineering.

My name is Megan Landau - I was born in Johannesburg, South Africa to two incredibly intelligent, yet computer illiterate doctors. This is perhaps why I did not find out how much I enjoyed programming until about two years ago when I looked up a YouTube video on how to make the Flappy Bird app game and got lost in the coding.

I have always obsessed over puzzles and games - I learned how to solve a Rubik's Cube when I was 12 during an 18-hour flight home to South Africa. Programming was not offered in my tiny high school in Jackson, Wyoming, and so, when I went to college, I decided to try Pre-Medicine first at Boston University and then pursued my passion for design at Parsons the New School for Design in New York City. Feeling something amiss, I left college for a few years, travelled, became a PADI Rescue Diver and then a certified Emergency Medical Technician, and found myself in Charleston, SC, wanting to go back to school again. 

A combination of the persuasive Flappy Bird video, many intriguing CodeCademy tutorials, and a few dubious yet encouraging conversations with my parents led me to the College of Charleston.

Since starting last fall, I have worked as a Student Programmer at the Medical University of South Carolina, worked on a team to develop a virtual reality game, and am now working developing apps to control drone flight by voice commands. Some of my work is here if you want to take a look. The more I learn, the more I think I would like to go into the Machine Learning, Artificial Intelligence, or Software Engineering fields of Computer Science. 

But that's enough for now! Sorry for the long introduction.