Homework #6

Chapter #4 

Requirements engineering

4.5 Using the technique 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 that includes 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.
1. The system shall ask the user to swipe their credit card
2. The system shall ask user to enter the five digit zip code associated with said credit card.  (Zip code is required as a security check.)
3. The system shall ask the user to enter the amount of fuel required
4. The system shall ask the user to place pump nozzle in tank hole.  (There shall be an option for pushing "full tank" that relies on a sensor in the nozzle gas pump.  The tank shall not be over filled if customer over estimates fuel needs.  A sensor alert shall go off if this occurs, alerting the gas pump, and effectively stopping the gas.)
5. The system shall display the amount the account will be debited and then ask if a receipt is desired for transaction.
6. The system shall tell the user to have a "nice day".
• The cash-dispensing function in a bank ATM.
1. The system shall ask the user to insert a debit card 
2. The system shall ask user to insert PIN number. (PIN number is required as a security check.)
3. The system shall ask the amount desired of the machine to dispense.
4. The system shall check against the user's balance and check to see if this withdrawal is an overdraft.  
5. If there is an overdraft, the system should alert the user and ask if user would like to proceed.
6. The system dispenses the desired amount of cash.
• The spell-checking and correcting function in a word processor.
1. The system shall identify words (with a red underline) that are not in system's dictionary.
2. The system shall offer user options regarding word:
1. Offer to replace word. (There shall be a list of five similar words to choose from).
2. Offer to ignore word and all instances of word. (So as not to pester user with redundant alerts).
3. Offer to add to dictionary. (So in the future, user will not be pestered with redundant alerts).
3. The red underline shall disappear once user has chosen desired option.

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

Functional requirements:  describe what the system should do.  Cover general requirements to very specific requirements
Examples:  the system's inputs and outputs, exceptions, etc.

Non-functional requirements:  requirements that are not directly concerned with the specific services delivered by the system to its users.  More critical than individual functional requirements.
Examples:  performance, security, availability

For more of a visual approach, I suggest making a table with two columns, one for functional and one for non-functional.  For each functional requirement, make a list of non-functional requirements that need to be kept in mind while implementing the functional requirement.  You will have a lot of redundancy in these lists, but that's ok, just make the association so it's in the back of the programmers' mind.

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.

Use cases:  a requirements discovery technique that were first introduced in the Objectory method.  It identifies the actors involved in an interaction and names the type of interaction.

I'll be covering the 2 ways in which I use an ATM which are to withdraw money and cash a check

Use Case for ATM:
Interaction between ATM and user allows user to withdraw money, cash a check, and/or view balance.  The user interacts with the ATM machine via touch screen and keyboard.  There is also a slot to insert cash/checks and a slot to insert debit card.  User initiates the ATM transaction by pushing desired language from display screen offering an "English" button and an "Other" button.  The "Other"  option leads to another screen displaying a drop down menu offering a list of other languages.  Once language has been established, the display asks user to insert debit card.  The display should have a moving image of the correct way to insert debit card.  Once debit card is inserted, the user has the option of pushing a button for "Money withdrawal" or "Cash a check".

If the user pushes the "Money withdrawal" button, the display shows the user balance and various dollar amounts displayed in buttons that the user can choose from or the user can physically input the amount desired via keyboard.  The ATM then follows through with the transaction and outputs the money.  The ATM then asks if user would like to have a receipt.  The receipt has the option to be printed from the ATM machine or sent via e-mail.  These options are displayed on buttons.

If the user pushes the "Cash a check" button, the display asks user to input the number of checks to be cashed using the keyboard.  Then a moving image shows user how to insert checks.  Once checks have been inserted, the amount on the checks are totaled.  The total is displayed and the user can confirm that the amount is correct.  Once confirmed, user balance is adjusted and displayed. The user can then withdraw or end session.

When the "end session" button is pushed, the machine beeps to remind the user to take debit card and then outputs the debit card.

Homework #5

Nancy Leveson

Nancy Leveson currently researches topics of system safety, software safety, software and system engineering, and human-computer interaction.  She is also a Professor of Aeronautics and Astronautics at MIT and does consult work with industries on how to prevent accidents.







Faulty Software Articles:

"An Investigation of the Therac-25 Accidents" by Nancy Leveson and Clark Turner is about the well known Therac-25 accidents where many serious injuries and deaths occurred due to massive overdoses of radiation.  This was in large part due to the operator interface that lead the user to believe no dose was given when in fact it had been.  The user would then press the proceed command which resulted in a radiation overdose.

"After Stroke Scans, Patients Face Serious Health Risks" by Walt Bogdanich was also about radiation overdose, but in this case, depending on how the user programmed the machine, an increased dosage would be given when the user intended to lower the dosage.

"FDA: Software Failures Responsible for 24% of all Medical Device Recalls" by Paul Roberts this article was more about the potential for wireless medical devices to be hacked.  I was obsessed with the show "Homeland" last year and in one of the most nail-biting episodes...SPOILER ALERT...the VP's pacemaker is hacked and results in him dying from a heart attack.  The article even mentions that two U.S. Congressmen had their wireless medical devices reviewed due to a presentation on medical device hacking.

"The Role of Software in Spacecraft Accidents" by Nancy G. Leveson talks in depth about the flaws in the safety culture of software this includes:  complacency and discounting of software risk, diffusion of responsibility and authority, limited communication channels and poor information flow, inadequate system and software engineering, inadequate review activities, ineffective system safety engineering, flawed test and simulation environments, and inadequate human factors engineering.  Back to the diffusion of responsibility and authority:  in the article they mention that roles were not clearly allocated and that is where some of the responsibilities/ tasks fall through the cracks. I know I always somehow relate something I read back to nursing, so here I go again: In the healthcare world, during an emergency for example, roles are assigned, responsibilities are dolled out and everyone tries to work together to stabilize the patient.  Your role is clearly understood and you know what your responsibilities are.  Somehow this needs to be more clear when working as a team on software.

"Who Killed the Virtual Case File?" by Harry Goldstein is about the costly VCF debacle in 2005.  The number of communication breakdowns involved in this fiasco amazed me.  

"IG:  FBI's Sentinel program still of track, over budget" by Gautham Nagesh is looking at VCF's predecessor- Sentinel.  This article was written in October of 2010 and at this time, the Sentinel was only in phase two of four and struggling to meet deadlines.  A piece of good advice:  "The IG recommends the Bureau prioritize the development of applications and function that would be most beneficial for agents managing their casework." According to Wikipedia the Sentinel program was showcased in March 2012.

There was one quote that really stood out for me and it comes from the 2010 Radiation Follies article.  Mr. Heuser, one of the affected people mentioned in the article, says "When you are in a car and it backs up, it goes beep, beep, beep...if you fill the washing machine up too much, it won't work.  There is no red light that says you are over radiating."  Good point.  Why is this the case?  When I have finally graduated with my degree in Computer Science from the College of Charleston I will be much more proficient and knowledgable about coding and the concepts that go behind it, but I don't know anything about radiation machines and spacecrafts.  I don't use a spacecraft to get to work daily and I definitely have never performed a CT scan on myself.  I do however wash laundry in the washing machine quite frequently and drive my car almost daily.  I think this might be one of the big problems when it comes to faulty software.  The software engineers do not have enough knowledge on how the software needs to be used and how the user will potentially use it.  One way to fix this problem is better communication and collaboration between the engineers and potential users of the product.  Nancy Leveson mentions that "the first and most important step in solving any problem is understanding the problem well enough to create effective solutions."  In the FBI fiasco of 2005, Higgins explains, "The customer should be saying, 'This is what we need.' And the contractor should be saying, 'Here's how we're going to deliver it.' And those lines were never clear (Referring to the VCF debacle)."  There also needs to be better training of the users: in the article by Bogdanich, it says that "GE trainers never fully explained the automatic feature" (that caused the increase in radiation dosage).

Better communication between all involved is essential to get a project done, done safely, and done right.  By better communication I mean:  everyone has a role and knows the responsibilities of that role in regards to writing software, software engineers should have many meeting with the consumer to make sure they are meeting their needs, and when the product software is completed the training that users go through should be thorough.

Experience Report

Joining the playground

Setting up my environment:

1. Installed a virtual machine
2. Downloaded Ubuntu iso 
3. Installed sublime text 2 as text editor 
4. Installed subversion via command line
• Step-by-Step Instructions:  https://help.ubuntu.com/10.04/serverguide/subversion.html

Exercise: Create test directory [lastName] in SVN repository "playground"

• $ svn co https://svn.cs.cofc.edu/repos/CSCI362201302/playground
• signed in with username and password
• $ cd playground
• $ mkdir WIEL
• $ svn status
• $ svn add WIEL
• $ svn commit
• enter in commit statement:  “Johanna has joined the playground!”

Done!

Homework #4

Chapter 11

Dependability and Security

11.4  Giving reasons for your answer, suggest which dependability attributes are likely to be most critical for the following systems:
An internet server provided by an ISP with thousands of customers
*Availability would be the critical attribute needed here.  With thousands of customers relying on this internet server, the services need to be accessible all day everyday or the customers will leave their provider...attention Comcast.

A computer-controlled scalpel used in keyhole surgery
*Safety is the critical attribute in this situation.  This scalpel needs to ensure safety to keep patients safe throughout the procedure.  Since we are dealing with a persons life/body- safety is important here.

A directional control system used in a satellite launch vehicle
*I think reliability is most important during a satellite launch.  I'm assuming that a satellite launch is very expensive- so you want to use a system that will successfully launch the satellite vehicle into orbit the first time.  

An internet-based personal finance management system
*Security is the number one attribute needed in this system.  If this financial system is hacked, it can be very costly since it contains a lot of personal financial information.

11.7 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.

This medical system might deliver too much radiation to the patient, not only endangering/potentially killing the patient, but also healthcare workers.  In this case, I'm considering human error- the wrong amount of radiation was entered into the machine.

One way nurses try to prevent human error is having another nurse check medications/dosages/etc with them before administering.  There could be a check in the software where nurses would show the amount of radiation to be administered to another nurse and check that against the doctor's orders, and have that nurse sign off on the radiation machine (enter their Id number/ scan their badge)- that way two sets of eyes have reviewed and confirmed that this is the right dosage.

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

#1  Threats to the confidentiality of the system and its data- so an unauthorized person has gained access to the system by guessing the username and password and now plans to find personal information on a well paid sports star and potentially expose it to the media.  
Control:  The unauthorized user tries to find personal information on patient, but it is detected and put to a stop.  Also if you have a celebrity in the hospital, you can have extra security measures...an alias name, another password to get into patients file, etc.

#2  Threats to the integrity of the system and its data.  The unauthorized user has gained access to sports stars' personal file, but there isn't enough "juicy" material.  So the unauthorized user adds/deletes/ changes this data, positive that this will make a much better story for the gossip columns.
Control:  Software that detects data modification and stops further access while alerting the proper people.

#3  Threats to the availability of the system and its data.  Access to patient files is essential when working in a hospital setting.  Not being able to access these is a major issue and could potentially harm the patient.
Control:  There needs to be a way for the authorized user to get into the system another way...a Plan B...a back-up plan (I'm not sure how realistic that is).  

Homework #3

Chapter #10

Sociotechnical Systems

10.6  A multimedia virtual museum system offering virtual experience 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?

This is a system, not for one museum, but for many.  All the museums may not have the same supplier for equipment, which would affect the review and assessment phase of the spiral model in the textbook.   The book mentions that the user environments may be different from what the developers anticipated- adapting the system to cope with diverse user environments can be difficult.  When problems arise with the new system, who is responsible for technical support?  The museum staff?

When introducing a new system like this, there obviously has to be training of staff so they can demonstrate to users how to use the new system.  This sounds uncomplicated enough, but people don't usually like change and there might be some resistance towards this new system at first from staff members.  I worked on a NICU floor for almost 4 years and change was ALWAYS met with resistance...but who can really blame them, new changes usually meant more responsibility/work on top of already long and difficult shift work.

10.10  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?

This is a frustrating position to be in.  Obviously you can not complete your work without proper information, but you can't abandon the work all together.  Communication is key here.  Let human resources or whoever you are dealing with know what is happening on your end.  Call and email.  Postpone the work on this contract until you have the necessary information.  You can't do your job until they do theirs.

Homework #2

George V. Neville-Neil

Interesting tidbits on the authors:


George V. Neville-Neil is the author of Cherry-Picking and the Scientific Method.

A little about him:  he is on the editorial board of ACM's Queue magazine and developed the column Kode Vicious- this is where our article comes from.  He is the coauthor of the book entitled The Design and Implementation of The FreeBSD Operating System (It got 5 stars on amazon.com).  He is a software engineer who currently builds systems for the global financial market.

"TomZ"

Thomas Zimmerman is the coauthor of Software Analytics:  So What?

Thomas Zimmerman is a researcher at Microsoft Research.  He is also a Professor at the University of Calgary.  His research revolves around programmer productivity by creating techniques and tools that focus on learning from past mistakes or successes.

Tim Menzies

Tim Menzies is the coauthor of Software Analytics:  So What?

Tim Menzies is a professor at WVU for various Computer Science courses.  (He's actually on ratemyprofessor.com with an overall rating of 3.6).  He was a former research chair for NASA before becoming a professor.

Frederick P. Brooks, Jr

Frederick P. Brooks, Jr is the author of Essence and Accidents of Software Engineering.

Frederick P. Brooks, Jr became the manager for the development of the System/360 family of computers and the OS/360 software package for IBM.  Apparently he coined the term "computer architecture".  He also founded the Department of Computer Science at UNC Chapel Hill.

Article summaries/personal thoughts:

Cherry-Picking and the Scientific Method
Summary/Thoughts:
In this column, readers write in and get their questions answered.

The first questions is about when to give up cherry-picking and merge.  I wasn't really sure what cherry-picking meant (related to computer science) so after a quick google search, this gave a nice description:  http://technosophos.com/content/git-cherry-picking-move-small-code-patches-across-branches.  Because of my lack of experience, I'm not really clear on what the issue here is, but I'm assuming when you are moving commits piece by piece, there might be a few loose ends and it would be better to merge everything together as one cohesive piece.  I'm sure I'll have a better grasp of this after hands on experience.

The second question is about fixing bugs and how to prove the corrections are correct.  The author recommends approaching a problem by using the scientific method:  write down your theory and develop hypothesis about problem.  The key advice the author gives is to write this information down- he gives an example of his note taking system.  This way in the future, it is easy to see what was tried, what worked, what didn't, etc.  I liked his idea of keeping notes, something I will consider doing in the future.

Software Analytics:  So What?
Summary/Thoughts:
This is one of two volumes on the subject of software analytics.  The article first covers what software analytics is defined as.  It specifies that analytics must be real time and actionable.  It also talks about how software analytics today is focusing on sharing general methods to enable the discovery of local lessons.  It has been realized that there is no global model, instead the focus is now on local models.  This article also talks about general principles for analytics:  how it's not about the hardware or software, but about the skilled data scientists.  The last part of the article is dedicated to discussing the different and distinct kinds of analytics.

The distinction I found most interesting was internal vs external analytics and how privacy is a major issue, since altering data can damage the signal in that data, thus skewing results.  My sister graduated from College of Charleston with a Data Science degree, so it was really fun reading and keeping her in mind.  It will be interesting to see where software analytics take us in the future.

Essence and Accidents of Software Engineering
Summary/Thoughts:
This article goes through proposed bullet after proposed bullet to ultimately prove that there is no silver bullet that will improve productivity, reliability, or simplicity of technology or management technique in software engineering.  But by proposing these bullets, there have been advances (some small/some large).

The idea of graphical programming is really interesting to me since I am a very visual person.  Unfortunately no strides have been made in this subject and the author believes that no strides will ever be made for these reasons:  the flowchart is useless as a design tool, the current screens are too small (the programmer would only be able to view a few things at once), and the author believes that software is very difficult to visualize.  This article is about 26 years old, based on an advertisement on the last page, so I wanted to google and see if anything new has happened with graphical programming, but it doesn't look like anything has.  I did find this blog:  http://www.realsoftwareblog.com/2011/08/can-programming-language-be-completely.html.  It did a great job of running through a list of visual programs that the author was familiar with that failed and why- really interesting and worth reading.  This was a lengthy article, I got lost a few times, but stuck with it- really in depth and interesting read.

Homework #1

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

#1  Maintainability:  software is written in a way that can evolve with new needs of the customer
#2  Dependability and security:  If a system fails, there is no physical or economic damage left in it's wake- also hackers and death eaters are not able to access or damage the system
#3  Efficiency:  Waste not, want not.  Software should not waste system resources.  Efficiency refers to responsiveness, processing time, memory utilization, etc.
#4  Acceptability:  Users must accept the software to the point that they understand and are able to use the software and that it is compatible with other systems that said user...uses and does not create ugly side effects.

So here goes my input:

#1  Fixability:  I'm fully aware that this is not a real word.  It's not even defined on urbandictionary.com - I checked.  So what I mean by "fixability" is the ability to fix - How easy is it to understand what went wrong - does the software handle errors well and how do we find the problem.  In short- fixability.
#2  User Friendliness:  I guess this can technically go under Acceptability up above, but I think it is extremely important that the user not only understand how to use the software and is able to, but that they enjoy it.  As a user, I'm not likely to use software that annoys me or I simply do not like.  After all, the customer is always right.
#3  Affordability:  Again- I'm going back to the user- ultimately it's important and if you follow the four important attributes of professional software, the cost should be kept down since the maintaining software is the costliest.
#4  Flexibility:  I have just entered the computer science world, so I do have have a lot of real life working knowledge, but I keep hearing my friends (who are in the real world working) complain about how inflexible their companies existing software is.  So therefore, I'm going to go with them on this one and say flexibility- meaning that changing/adjusting the software is relatively easy.

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

I see a lot of gray areas when thinking about this.  Ultimately I think the general certifications we have in place now are good enough, but when you get into software that affects someone's life/health- that's when I feel we need more certifications in place.

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.

#1 PUBLIC:  software engineers shall act consistently with the public interest.

Sophie the software engineer volunteers her time and skills to good causes, ideally education related.

#2  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.

Sophie the software engineer does not gossip about confidential information, that she has learned at work, out in public.

#3  PRODUCT:  Software engineers shall ensure that their products and related modifications meet the highest professional standards possible

Sophie the software engineer properly tests, debugs, and reviews projects that she works on.

#4  JUDGMENT:  Software engineers shall maintain integrity and independence in their professional judgment

Sophie the software engineer does not bribe, double bill, or do anything else that is financially distasteful.

#5  MANAGEMENT:  Software engineering managers and leaders shall maintain integrity and independence in their professional judgment

Sophie the software engineer's boss will not punish her if she raises ethical questions about a project.

#6  PROFESSION:  Software engineers shall advance the integrity and reputation of the profession consistent with the public interest

Sophie the software engineer gets involved by participating in professional organizations and always supports others in her field.

#7  COLLEAGUES:  Software engineers shall be fair to and supportive of their colleagues

Sophie the software engineer takes a new coworker "under her wing" and aids this coworker in his/her professional development.

#8  SELF:  Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of he profession.

Sophie the software engineer would never violate this Software Engineering Code of Ethics and Professional Practice- "uphold the code" she chants.

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.

This is invasion of privacy.  This system goes against some of the Software Engineering Code of Ethics, especially the first one- PUBLIC.  I would report to the appropriate authorities...but...wait.