CS 360 Homework 4

For this post, I will be consulting the Software Engineering 9th edition textbook (by Sommerville) once again. I am going to give responses to the following scenarios:

Giving reasons for your answer, suggest which dependability attributes are likely to be most critical for the following systems:
First, the following are dependability properties/attributes:

1. Availability <- Informally, the availability of a system is the probability that it will be up and running and able to deliver useful services to users at any given time.*
2. Reliability <- Informally, the reliability of a system is the probability, over a given period of time, that the system will correctly deliver services as expected by the user.*
3. Safety <- Informally, the safety of a system is a judgment of how likely it is that the system will cause damage to people or its environment.*
4. Security <- Informally, the security of a system is a judgment of how likely it is that the system can resist accidental or deliberate intrusions.*
5. Repairability <- With the inevitability of system failures, diagnosing, accessing, and fixing the issue quickly represents good repairability. Open source software makes this easier.
6. Maintainability <- As software systems are used and live on, new requirements and features will emerge and maintaining the old usefulness of the system as well as accommodating for the new features represents good maintainability. Making changes and adding features should not break a software system.
7. Survivability <- The ability of a system to continuously deliver service whilst under attack and whilst parts of the system are disabled.*
8. Error Tolerance <- User input errors should not occur. Error handling is important (whether automatic fixing happens, or prompting for user input).

1-4 are the four principal dimensions of dependability.

5-8 are system properties that are also dependability properties.

* represents definitions straight from the textbook and a lack of * means that I inferred my own definition from their description and detailing.

• An Internet server provided by an ISP with thousands of customers

Internet services tend to have their own niche of specialization when it comes to dependability attributes. If a service is hosted on the web, then that service should always be available and have many measures taken for safety and security. I hone in on these three because the whole purpose of hosting a service over the web is lost if that website or application is not available. Those thousands of customers will have to halt whatever it is that they are doing and that is something that should just never happen. The Internet, inherently, has a need for safety and security. If any sensitive information (including simple logins) is being sent to a server, then proper safety precautions should be taken in order to secure customers' data. 

• A computer-controlled scalpel used in keyhole surgery

The attribute that cries out when reading this scenario is safety. When dealing with the health of people, safety always comes first. Especially so in this scenario because a scalpel controlled by a computer could easily knick an artery or really any tissue inside the body not meant to be hit with a scalpel during this surgery. A second attribute that falls into this same vein is error tolerance. If the user on the computer-end of the scalpel hits a wrong key or makes an odd motion, then the scalpel software should know to halt whatever it is doing and not make some rash, expedient decision.

• A directional control system used in a satellite launch vehicle

In this situation, maintainability and reliability are the most crucial dependency attributes. Because this satellite launch vehicle is going to be used in a way that launches a satellite that people will not be able to physically access any longer, the software better not fail because a bold programmer decided to add a new feature toward the end of the project. Also, if this control system were to be used for a different satellite at a later time, then the software should not produce unforeseen results and should still be able to be trusted. If an error does occur, then the software better have a good semblance of repairability so that issues do not last long enough to ruin the entire system.

• An Internet-based personal finance management system

When it comes to any kind of personal system (and especially that of a fiscal nature), then security is always going to be the most important dependency attribute. I'll just reference the first scenario here and all the security issues I brought up with it rather than recapitulate ideas I have already expounded upon. Also, because the data that is being dealt with contains financial data, then it is also vital to put a lot of focus on error tolerance. No one wants to be the victim of some financial hiccup that sub-par software caused.

In a medical system that is designed to deliver radiation to treat tumors, suggest one hazard that may arise and propose one software feature that may be used to ensure that the identified hazard does not result in an accident.

For starters, this scenario sounds eerily relevant to the Therac-25 incidents. So a hazard that can arise is that someone could accidentally deal a dosage that is magnitudes higher than needed. For example, let's say that the software is set up to work with some hardware so that you enter a dosage amount on a keypad. You would have to press down on the keypad in order to give a dosage to a patient. Well, what happens when a nurse is trying to give a dosage of 5 (let's ignore units since this is not my domain of expertise), but that 5 gets pressed twice. Well now the dosage is 11 magnitudes higher. Now there is a potential death, lawsuit, and probably some other things no one should have to deal with. A software feature that could prevent this is AI built into the program. Say the program has access to patient information (we are assuming the software has ample security measures in order to prevent people from having access to sensitive information) and it has an idea of what the dosage that the doctor/nurse would be giving to the patient is. If the program would stop the treatment if the dosage exited a certain bound of acceptance, then the doctor/nurse could double-check and make sure they are not about to kill their patient.

Using the MHC-PMS as an example, identify three threats to this system (in addition to the threat shown in Figure 11.8). Suggest controls that might be put in place to reduce the chances of a successful attack based on these threats.

1. Asset <- The records of each patient that is receiving or has received treatment will now be at risk if this hacker gets into the system. This completely breaks doctor-patient confidentiality and that is a huge problem for our medical system.
2. Vulnerability <- The weak password system allowed users to use children names as passwords as well as not enforcing any kind of heavily secure password. Without enforcing the need for capital letters, numbers, or symbols, people will be lazy and not use secure passwords. In a regular environment, like email, this is not that big of an issue, but this is dealing with medical records so passwords should be forced to be secure. 
3. Exposure <- There will be ample financial loss from an issue like this. The sports star could potentially sue the hospital, other patients could take their business elsewhere, and the hospital will have to pay for new software because obviously their current software is pretty bad

In order to fix these issues, the software engineers could enforce extremely secure passwords (ex// At least one uppercase letter, at least one lowercase letter, at least one symbol, at least one number, and no proper nouns or passwords related to your name).Additionally, they could set up a better protocol for identifying people that are related to patients before giving information out. It does not make sense that this person was able to claim that he/she was related to this sports star and, thus, was able to retrieve sensitive information about that person. 

Music listened to while blogging: None because the computer I was working on will not allow my to use headphones (extremely frustrating)

CS 360 Homework 3

This post will consist of me answering two questions from chapter 10 of Sommerville's 9th edition of Software Engineering

A multimedia virtual museum system offering virtual experiences of ancient Greece is to be developed for a consortium of European museums. The system should provide users with the facility to view 3-D models of ancient Greece through a standard web browser and should also support an immersive virtual reality experience. What political and organizational difficulties might arise when the system is installed in the museums that make up the consortium?
The creators of the system are likely to run into a number of issues with this software. The following write-up assumes that not all museums are included in the consortium. Museums themselves will be likely to lose revenue that they would normally rake in even though this is, what I would consider, revolutionizing museums. Some museums are funded by external sources (taxes, subsidies, etc.), but not all of them. Others may sell concessions to maintain themselves as well as charging a minor fee for entering the museum. Now the museums within the consortium are going to make more money, or at least not lose any money, but that is pretty impertinent when considering difficulties. Additionally, a lot of what happened in ancient Greece is not exactly G-rated. There are bound to be parent groups that would pull the severely uptight parent card and become infuriated that their elementary-student child was studying Greece and stumbled upon a 3-D model of a nude statue or a mildly gory painting depicting Alexander's armies in action. Granted this issue may arise just because of the museum itself, but I have a feeling that the people complaining about these innovations are not exactly the most rational. Also, guides within museums may lose their importance because of the existence of a virtual tour guide through the museum (and more!). This could lead to issues because when workers at your establishment are not happy, then problems can arise. The problems could be as innocuous as a complaint or as bad as a strike. Regardless, the software will be blamed as the cause and that is no good.

You are an engineer involved in the development of a financial system. During installation, you discover that this system will make a significant number of people redundant. The people in the environment deny you access to essential information to complete the system installation. To what extent should you, as a systems engineer, become involved in this situation? Is it your professional responsibility to complete the installation as contracted? Should you simply abandon the work until the procuring organization has sorted out the problem?
I am going to start this off by saying I hope I am never in a situation like this. I would say that as a systems engineer I would be extremely involved in this situation. Redundancies in a financial system could have serious legal implications as numbers may not be up to date in certain places, resulting in misinformation that could exacerbate other problems, creating a terrible spiral for the person involved and the financial company. This falls under the responsibility of the systems engineer because of the need to comply with external regulations. So not only is it the 'right' thing to do, but it is also the 'legal' action to take. It would be laughable if someone thought the best solution would be to abandon work and not help at all. You are involved in the development of this system and oftentimes you have to step outside your comfort zone. Even if you were not responsible whatsoever to be involved in this situation you would still have an obligation because you still are a part of the project. It may not be encapsulated in your job title or description, but, as a team member, it falls down on you as much as everyone else.

Music listened to while blogging: Pharell, alt-j, & Blink-182

CS 362 Homework 2

For this post, I will be reflecting on three articles that are pertinent to software engineering

No Silver Bullet (Frederick P. Brooks, Jr.)
There is no silver bullet for software. There does not exist some easy way to tackle all of the issues one faces whenever building software. You will not ever look at a piece of software and exclaim "THIS IS BRILLIANT! IT'S PERFECT!" That just doesn't happen. Even if your software was "perfect" you would still find ways to add features, speed up algorithms, add code readability, etc. On top of this, maybe you need to add a way for your software to integrate with someone else's software. Now your issue has expanded to include the issues of that other person. The bottom line is: there is always something you can add to software to make it better, but let's forget about that fantasy of perfect software and let's view this as realists. As part of a software team you have to do more than just write code. You have to meet with project managers, team members, and perhaps even developers working on a different part of the software (such as people working on the frontend to a program). This introduces all kinds of problems into the software development process. For example, the client for whom you are developing  software may not have been clear about something he/she wanted in the software, leading to software lacking features. This reaffirms the importance of the software development process of requirements elicitation. There needs to be a great degree of clarity of what you are doing. Considering all things, we will never find a silver bullet for software engineering, but we can create systematic methods for minimizing the daunting, painful nature with which software comes bundled. These methods include automatic code generation, graphical programming, artificial intelligence, object-oriented programming, and many others.

Kode Vicious (George V. Neville-Neil)
This article really hit home for me. The past two summers I have become familiar with using Github and Bitbucket in order to utilize version control for my outside projects. This past summer I was working with another person and we would sync to Bitbucket multiple times a day. You do get into entanglements sometimes, though so you may not sync your files for multiple days. I always hold my breath whenever I hit "local merge" at times like that because manually merging files is a major pain and git-merge software is not exactly the simplest thing. I resolved my issue that time by cloning the entire repository again just to avoid the disgusting nature of merging. I am at the point now where if I have not merged with someone working on the same branch as me in a short amount of time, then I make sure that I get that work merged. Aside from that headache, I would just like to put it out there that version control programs are amazing, provided you are not cherry-picking. Additionally, the article goes into documenting bug fixes and testability. It is never enough to just say, "Oh, I fixed that bug. I know it works." How did you fix it? Where is that code? What test cases did you use? These and many other questions can be posed to someone who simply says, "I know it works. I mean, I did it." By documenting all of these things you can avoid redundancy in the future and work more quickly, effectively, and efficiently. Bugs are bugs for a reason. If you swat one of them, then you better let everyone know how, when, where, and everything else about it.

Software Analytics (Tim Menzies & Thomas Zimmermann)
This article subliminally was whispering "big data" and "data science" into each of my ears before it even reached any depth. Data is the heart of analytics, though, so that makes sense. At one point this article attempted to detail everything for which analytics can be used. I thought this was hilarious because you could so much more easily make a list of what you could not do with analytics. No matter what field you are in analytics is of a dire, vital and growing importance and significance. Bioinformaticians attack their genetic data with their algorithms and analytics, through methods like dynamic programming. Some stock market analysts tackle their investing by running predictive analytics, with algorithms such as support vector machines and smoothing techniques, on relevant stock data. I will stop detailing now because, otherwise, this blog would never end. There is much more to analytics than analyzing data, though. How do you get this data? The answer is simple: share. The computer science community is probably one of the most open academic communities out there and that is part of what makes software analytics so fruitful. In addition to sharing data, the sharing of novel algorithms is crucial. Say you figured out a way to improve a classification algorithm, or maybe you just found an algorithm that predicts better in most or all respects, then you should present that to the community. Just think quid pro quo. More data, more algorithms, less problems.

Music listened to while blogging: OneRepublic & Kanye West

CS 362 Homework 1

So this is my first post to kick off this blog. For starters, this blog is being created in order to fit the requirement for my Software Engineering class (CSCI 362) with Dr. Jim Bowring at the College of Charleston (CofC), but hopefully it will be used for bigger and better reasons down the road.

My first post will be regarding exercises in the first chapter of Ian Sommerville's ninth edition of Software Engineering, a text I will be referencing often for this class. So I will jump straight into discussing the topics-at-hand:

1.3   : What are the four important attributes that all professional software should have? Suggest four other attributes that may sometimes be significant.
The four attributes all professional software should have are as follows:
1) Maintainability <- Software should be written so adding new features and fixing old(er) issues can be done; basically, when a need arises, have the capability to fix it.
2) Dependability and Security <- Being able to rely on software so a malfunction does not have dangerous or unforeseen consequences is essential. Additionally, malicious users should not have the ability to hack, view, or have any kind of access to the system or secure information.
3) Efficiency <- Software should be written in a programmatically succinct manner. Basically, do not waste memory resources, effectively making algorithms and activities slower than needed.
4) Acceptability <- The target audience for the software should be able to use the software without any major hiccups, as well as the audience being satisfied with the software (So not Cougartrail, as some CofC students may remember).

So now I will detail out four attributes that may sometimes be significant:
1) Modelability <- Now before you yell and scream that this is not word, give me a chance to define what I mean. The ability for your software to be modeled is extremely important. This is because the ability to create a model for your software means that you are able to understand it well enough to describe it in an abstracted manner. When it comes to conferences or even informal presentations, this is crucial. Not to mention that models are always fantastic to have as reference.
2) Scalability <- This is an attribute that may not always be significant. Some software, however, starts off as a small project not meant to have many users, but then that software may become popular and it needs to be scaled up to handle a larger, more variable audience. For example, I have a project that I am working with a fellow student, Jake Dierksheide, on and it is being deployed in the Data Science 101 class this semester. While we need not worry about a heavy load of users for that project, we should keep scalability in mind because this project could go on to be the next Codecadamy *fingers crossed*.
3) Platform-Independence <- This may be an idea that is encapsulated within Acceptability, but I believe it is worthy of being its own attribute. We see issues everyday when it comes to platforms. For example, my Chromebook is not supported by CofC for their wireless internet for whatever reason. As a professional community, the IT department should work in compatibility for everyone. This microcosmical example merely serves to explain my idea. Software should work whether you are a die-hard Apple fanboy, a crazed gamer with a Windows computer that has 64 GB of RAM, or even a terminal-lover that just will die without be able to run Fedora.
4) Engagement <- Software should be able to engage your target audience. If your software is about a boring topic, then find a way to make it appealing. Whether you are gamifying your software or just adding some flashy visuals that add to the meaning, it is important not to have some AWT GUI that took you 10 minutes to whip together running your software you spent months developing.

1.8   : Discuss whether professional engineers should be certified in the same way as doctors or lawyers.
It's a very interesting idea to have professional engineers be certified in the very same manner as doctors or lawyers. First, let me start off by saying that I do not think that it could ever really happen. I believe it would be difficult to regulate such a market of people. Is someone who publishes an App on the Google Play Store considered a professional engineer? If so, then would that be illegal without a certification? If not, then that would suggest that certification would only be important when it comes to dealing with certain types of software engineering. Most likely, at this point, I would believe that certification would only deal with software that involves the health or lives of people. So working on pacemakers and anything of that nature would require it. No matter how you treat this question, you are going to be running into gray areas left and right. It is much simpler to just say no to that kind of certification. Having generic certifications like we do today is definitely the way to go. A lot of my rambling on this subject could also be the result of me not knowing the entire process being a doctor or lawyer certification, but I believe my stance would remain the same.

1.9   : For each of the clauses in the ACM/IEEE Code of Ethics shown in Figure 1.3, suggest an appropriate example that illustrates that clause.
PUBLIC - Software engineers shall act consistently with the public interest.
I think the most illustrious example for this would actually be a counterexample. Take every single worker that is a part of the NSA's Prism project. They, essentially, are doing the opposite of this. The general public does not want their information to be mined for data so quickly and easily, but the NSA has pretty much said that they do not care.

CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.
The creator for the secure databases storing all of Wells Fargo's bank account information has created the database in such a way that malicious users cannot see other users' account information. This is in the client's and employer's interests for obvious reasons.

PRODUCT - Software engineers shall ensure that their products and related modification meet the highest professional standards possible.
Whenever the software for the Therac-25 incident started causing issues, the engineers released a newer version of the Therac-25 that did not cause the errors that were arising, arising in the death of some people.

JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment.
If a reviewer is going through the review process for a publication and they stumble upon someone's algorithm that would solve the problem that the reviewer has had for years, then, ACM/IEEE ethical protocol requires that, that reviewer cannot use that knowledge until the publication has gone through all the rounds and been published in the journal. Only then can the reviewer cite the publication and use the knowledge learned.

MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.
When a principal investigator works with a group of others. That leader should go above and beyond to promote the conduction of ethical conduct within their team. If the PI is not paying attention to the others and the others do some things in an ethical gray area, then the PI, the leader, is also responsible. The PI should work with the team to develop some sort of review or team development in order to stop any ethical misconduct from occurring. In the past, I worked in an Agile development environment and I would say that would be one of the better ways to go about doing this.

PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.
The principal investigator of a project should, at no point, forge any kind of result. Say someone comes up with a new classification algorithm that seems to completely debunk Neural Networks and Support Vector Machines (wouldn't that be crazy?). What if the dataset turned out to have a few manufactured datapoints that seemed to fit too perfectly. Well, even if this person had the greatest algorithm out there, the PI would not have subscribed to the code of ethics and profession that is expected.

COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
If a software engineer buddy of yours asks for your input on a small problem, then try to help. Be supportive. Do not try to mislead them, distract them, or anything that would be detrimental to their work. Also, if you do receive help from a colleague on a problem, then make sure you credit them. Give credit to where credit is due and be supportive.

SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.
Everyone is a learner. You, me, and even the people that have life figured out and are set. You should always be motivated to keep learning. This is even more important for computer scientists. The technological world is in a constant metamorphosis and keeping up with the times is the bare minimum for us. What we should strive for though, is to be the initiators of that change. The initiators of what causes other lifelong learners to, well, learn. Enact this change and enact it ethically.

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.
I touched on this issue earlier. It is one of the more relevant issues in the news right now. It is because of these 'terrorism' issues that data mining is becoming associated with this negative connotation. As a data science student, it is a bit painful to hear these accusations to my field. Big data is good data. It is not as if Joe Schmo at the NSA is going to look at you personally and know what you do each and everyday. There may be a record of it, but that does not change anything that will happen to you. Unless, well, you are involved in some kind of criminal organization and you are flagged. But, well, at that point the job is done. Now, do not get me wrong. I hate having my privacy infringed upon as much as the next guy, but I do realize that the government will do this no matter what. This will happen. It is an unfortunate reality we will all have to face. I mean, the government already has been collecting metadata from our phones for years. To be one of the programmers involved in these issues. That is an entirely different story, though. For this situation, let us suppose that the programmers know exactly what they are working on and let us assume that it is a bit voluntary. Working on the development of this type of system infringes upon the codes of ethics then. The public clearly has no interest in this type of program. The government would argue that it is in the best interest of the public to have this program in place, but it is not in the public's interest.
All in all, working on a system of this nature would really require one to put ethics aside in order to work.

I also plan on closing each of my posts with a small personal update. I doing this for myself and for you readers. I plan on adding information such as what I listened to while writing my blog post, my current work, etc. For me, it will be great to reread old posts and visit my memories and for you readers, it will be an insight into what is going on in my twisted brain.

Music listened to whilst writing: Kanye West, alt-J, Hopsin, Afroman, & A$AP Rocky
Current Projects/Work: Bioinformatics journal and Bachelor's Essay preparations.