Hours of Frustration Followed by Success!

Update:  If you can't tell by the WEKA logo up above, let me spell it out- we changed projects...again.  

Last night was spent trying to compile and run tests on Weka (something that should have been accomplished last Tuesday).  Weka aka "Waikato Environment for Knowledge Analysis" is a tool used for data analysis and predictive modeling.  Their logo is a weka bird, a bird endemic to New Zealand.  Somewhere that I would like to backpack someday, but I digress...

The first issue I ran into was committing the weka code to the team1 repository.  Apparently you can't commit the .svn files of one subversion repository into another subversion repository  it causes .svn conflicts. So the first step was to remove the .svn's I did this through the command line entering: find . -name .svn -exec rm -rf {} \.  This successfully allowed me to remove all the .svn's and I was able to commit the code to our team1 repository. 

I wasted a lot of time trying to compile the code through eclipse.  I kept getting "type" errors.  So I decided to ditch that plan and move on to another.  I wasted more time trying to google commands for the command-line   Nothing worked.  If I wasn't already frustrated, I am now.

Then I worked in terminal and used ant.  This is what I entered:

ant -f build.xml compile...SUCCESSFUL BUILD. *whew* finally getting somewhere.

Then more time was spent trying to figure out how to run the tests.  After giving the wrong command many times, finally something worked- and this is what I entered:

ant -f build.xml run_tests_core

There were 3643 tests and they all passed. It did this very quickly too- in about 1 min and 40 sec.

And now I'm stuck...AGAIN...

I tried to run "tests_all" BUT it fails...it says "hotSpot does not exist".  No idea what this means- maybe my internet was acting up- I'm not sure, but a quick google search did not shed any light on the issue and speaking of lights- mine should be off.  It's bedtime.

But before my head hits the pillow- I need to commit all this progress-

svn status

svn add copy and paste wekareports

svn add copy and paste weka/build

svn commit

.......................................................(many many many dots and 45 min later everything was committed).

We now have two new cool folders "build" and "reports". 

The ball has finally started rolling...please keep rolling!

The Back and Forth

Tor or FrontlineSMS...we keep flip flopping.  Luckily everyone else is as well- walk into the Computer Lab and that's all you'll hear.  Rampant indecision and confusion.  We are a little worried about Tor being written in C...a language none of us have worked with before, so currently we are leaning more towards working with FrontlineSMS which is written in Java.  After talking with Professor Bowring, we were lead in a clearer direction.  Since we are all novices, we don't know all the lingo associated with this project.  Professor Bowring suggested finding a resource that will walk us through how to compile a java program on the command line (something we've never done).  We are off to a sloppy start, having wasted a lot of time going around in circles.  Hopefully things get better.

Testing and Debugging

I am completely new to testing, as are all the "Loopers" (team members).  We chose to work with Tor for our project.  We have a vague idea of what is in store for us.  We are meeting this Sunday and I hope to see the "bigger picture" then.

I thought testing and debugging were synonymous, but according to this article, they are not.  The purpose of testing is to show that a program has bugs.  The purpose of debugging is to correct and find solutions to these bugs. So testing is finding the bugs and debugging is fixing the bugs.  One leads to the other.  I found it interesting that the objective of testing is to prove that the program is free of bugs- but this is an impossible objective to reach.  There will always be bugs, we just have to decided the amount of bugs that are "acceptable"- which is a judgement call.  Human error is inevitable.  At the hospital I worked it, we had protocols in place to prevent human error, but accidents/errors still happened.  We aren't perfect and neither are the programs that we will write.  

The Creation of Team Infinite Loop

Our software programming teams were chosen last week.  The class counted off one through five and that was it- we had our five teams.  I counted the number one which put me in a group with four other lovely team members- Diana, Joseph, Josh, and Alex.  We did a small team building exercise which I thought went pretty well.  It was apparent after the first thirty seconds into the team building exercise that Joseph would be the team leader.  It will take some more time to see where all the other team members fall- as far as team roles go.  Our number one goal for the first team exercise was to come up with a solid team name.  After turning down Alex's- "Team Panda" suggestion and a few others, the team opted to go with "Team Infinite Loop" with the slogan of "We'll never stop."  I think it has a nice ring to it.  I now have four new shiny Facebook friends and four new numbers in my phone.  So far this teamwork thing might actually be enjoyable...but we shall see...

Homework #9

Response to The Mythical Man-Month

Frederick Brooks is an author our class has read before- if you go to my first blog post there is a little snippet about him.  He wrote an article about the silver bullet of programming and I distinctly remember werewolves being all over his article- now there are dinosaurs all over this article and programming is being related to a sticky tar pit.  I like this man's style.

A quick Wiki search informed me that this article was written about Brooks personal experience as manager of the development of IBM OS/360.

The first chapter talks about the joy's and woe's of programming.  I could relate to most of the good and bad of programming, but the one I ended up highlighting was a paragraph talking about perfection and programming:  "If one character, one pause, of the incantation is not strictly in proper form, the magic doesn't work. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program."  Syntax.  I'll go through an emotional roller coaster at times when my code is not compiling and I'm trying to fix the problem- a half hour later, I realize there's a comma missing.  Syntax.

The second chapter introduces Brooks law:  Adding manpower to a late software project makes it later.  The first and last sentences in this chapter is the same sentence:  "More software projects have gone awry for lack of calendar time than for all other causes combined."  Adding more men, causes problems with communication.  Also managers have to consider that adding men will require training as well.  Time management and software engineering are difficult to keep in sync.  Brook suggests that "We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on." to get a better handle on project time estimates.  I found myself giggling out loud when Brooks says "The bearing of a child takes nine months, no matter how many women are assigned."  He relates this to software because of the sequential nature of debugging. 

The third chapter tries to answer this question:  "For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. Yet for large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance. How can these two needs be reconciled?"  Brooks suggests working as a surgical team would to tackle the software project.  Everyone has a role and the surgeon makes the final decisions that everyone else on the team helps support.  I have heard of employees working for large software companies who "get by" with contributing little to no work.  Since their corporations are so big, it is hard to keep track and make sure everyone is doing their part.  I think this surgical team approach would be very beneficial to companies.

The fourth chapter.  Brooks believes that  "conceptual integrity is the most important consideration in system design."  Brooks shares a costly mistake he made with the IBM project - what he learned was that more man power degraded the conceptual integrity of the project- which took more time and more money to rebuild and fix.

I enjoyed reading about Brooks personal experiences with the IBM project- the mistakes he made, his "Aha" moments, his advice.  Learning how to work the most efficiently and productively as a team while creating software is something that we need more intel on.  As a former nurse, I remember being taught how a hospital team works in the midst of an emergency- who has what role, and what is expected of you.  There were diagrams, there was research, we play-acted our roles- we knew the proper way to respond.  In time, I think software engineering teams will have a similar look.

Homework #8

500+ word essay on where you think programming and software engineering are headed; do you agree with the Future of Programming - why or why not?

After watching this video, I decided to visit the Cloud9 IDE website.  Their slogan is "Your code anywhere, anytime".  The introduction video they provide is very cute, informative, and to the point. 

I definitely do NOT have extensive experience with IDE's.  I have used two- NetBeans and ECLIPSE.  I use Sublime Text2 as my text editor and that is what Cloud9 IDE reminds me of- visually speaking.  

I think one of the most exciting features of this web browser IDE is the real time collaboration support.  This will help communication between engineers by leaps and bounds.  It's pair programming, but one programmer can be in China and the other in America.  Also if you are experiencing an error or problem, another engineer can see what the problem is in real time and the two of you do not have to fight to keep in sync- so the problem will most likely be resolved much faster.  There is even a chat button.  They say on the site's intro video that "it's like google docs, but for coding".  This real time collaboration will save so much time and frustration.  After all, time is money.

Software engineering as a profession is already decentralized, but with advances coming in (especially from a communication standpoint), you'll be able to work for companies in other countries in the comfort of your own home (not that you can't already- it might just become more common).

I also really liked the idea of accessing my code from wherever whenever...or as they put it "Your code anywhere, anytime".  Convenient.  

Another feature that I really liked was how you can zoom out of your code very easily.  I have probably mentioned before that I am a very visual person and, spatially, I get very confused/ lost in my code at times.  This feature is very slick, and I dig it.  

Three minutes into the video, the journalist interviewing mentions that Apple came out with a faster browser...yadayadayada...and the man being interviewed explained that faster browsers is what is making his work possible.  It will be exciting to see the advances that bring progressive change to different areas of software engineering.  

Like we keep mentioning in class- soon everything in our daily life will involve a computer- more so than now.  Hardware and software will keep evolving and keep improving, bringing forth lots of exciting advances. 

I agree with the video article.  Life is continually becoming more convenient- so why not coding?  Like I said, I don't have much experience with IDE's, but watching that video got me really excited.   Small things like fixing bugs always annoy me when my teacher or classmates aren't having the same problems and they can't explain why/fix the problem- now it doesn't seem like that will be a time consuming issue anymore.  These advances- thanks to the communication aspect especially- will help so much with teaching and mentoring (which is an exciting thought for us new grads).  Cloud9 IDE is something I will consider in the future...if not near future.  The only thing that makes me nervous is the security, even though they say it's "secure" in the video...is it really?

Reading Response

Today's readings:

The Magical Number Seven, Plus or Minus Two

This wikipedia entry is about an article written by George A. Miller, a cognitive psychologist.  He proposed Miller's law.  A law that states that an average human can retain 7 (plus or minus 2) objects in working memory.  Since this article, there has been further research that disagrees with the "magical number 7", suggesting maybe it's a "magical number 4", but others say this is also too high.  The wiki entry concludes by stating that further research shows that it might be the size, rather than the number of objects that make a difference in enhanced memory.

It was an interesting read, but I'm not sure how this relates to the other articles...

Security and Privacy Vulnerabilities of In-Car Wireless Networks:  

A Tire Pressure Monitoring System Case Study 

This article, as the title implies, goes through the security and privacy vulnerabilities of wireless networks within an automobile.  Specifically they do an in-depth look at the tire pressure monitoring system, or TPMS.  It's interesting that this feature was first added to automobiles for increased safety and efficiency, but as shown in the article, it can actually be a tool for wrongdoers.  It can help wrongdoers track automobiles and enable them to trick a driver to pull-over and check their tires (giving them an opportunity to attack and pillage).  This article covers the analysis of two popular TPMS systems used in many vehicles in the US mainly for security and privacy issues.  They test the systems, find flaws within the systems, and recommend changes that can make these systems more private and more secure.  

It's a bit scary to think that a tool that was intended to increase security and efficiency can actually make you more vulnerable to security and privacy issues because proper security and privacy testing was not done by the engineers.  This article was written in 2010 and it mentions that starting in 2012 the European Union is mandating that all new vehicles have TPMS.  I hope they made these more secure.

Planning for Failure in Cloud Applications

The author, Mike Wood, talks about inevitable failure and how to deal with it.  He recommends lots of failure assessment testing, finding all the faults, and deciding how to deal with them.  

I think it's important to remember that "there are a lot more possible failure points than the ones you have caught gracefully as exceptions in your code."

In the TPMS article, there is much security and privacy testing done, which lead to suggested solutions to these problems.  Also in the cloud applications article, the author recommends plenty of testing to find and resolve "holes" in the system.   Trying to tie in the magical number seven article- maybe the fact that with further research, other conclusions/ results were reached about working memory.  The magical number 7 article was not taken as fact just because one researcher reached that conclusion.  Failure/misuse of systems will happen, there needs to be thorough testing to enable engineers to find resolutions to the problems.  Using the scientific method during testing, can decrease problems within the system.

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.