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.
No comments:
Post a Comment