Blog Reflections #18

   Tonight my team went over the topics everyone is going to talk about during the presentation:

      Chris: Introduction
      Albert: Failed open source projects
      Me: Deliverable 2, major issues with deliverables
      Hannah: Toy project
      Matt: Fault injections

     We decided to have our presentation cover mostly our experience, since our document went very in depth on our testing framework I liked this layout because it gave everyone a chance to speak. I enjoyed working with this group during the semester. Everyone put forth an effort and tried to help towards the finished project. I learned many things during the course of this project. I hope I get put in as good of a group next semester in 462.

Blog Reflections #17: Almost done...

The semester is almost over, and we are in the final stretch of our project. I started the powerpoint for our presentation and will finish it tonight. We are mostly going to talk about our experience with completely our project. Albert and Chris will be finishing the final touches on the poster, and Hannah will be adding the faults to our script and writing about it in our document. I learned alot during the course of this project. I hope our presentation goes well!

Blog Reflections #16: Deliverable #4, Testing, Website(side work)

 I accidentally made two #9's so I will just skip 15 to get on track. We have been working on changing our write up for the fourth deliverable. This experience has been pretty smooth for the most part. We added more test cases to our project without many issues. This is mainly because we have worked specifically to make our script as flexible as possible. This is why it was rather easy to add testcases or different methods.

  I am starting to think about some faults we can add in our testcases or methods to get some failures. Right now, I do not think we are getting any failures with our current methods. From what we have been learning in 362, I know that this is not a good thing. If we do not find a way to get a failure, it will be hard for us to know of our script can even handle such a case. This will be our next task after we receive feedback and make changes to chapter 4 of our write up. 

  In other news, I have finished making the website for Women in Computing and it went live on Tuesday. I am very excited that everyone gets to see my work. I hope this actually draws interest in the club. 

Link to site: wic.clubs.cofc.edu 

Blog Reflections #14: Side Work

    I always like to work on coding outside of class. Recently, I have been doing many freelance website project under the guidance of Christine Moore. I have made a site for two non-profit organizations, the women in computing club here at the college, and a small start up in Charleston. I am learning alot doing this. I would like to learn way more though. I checked out books from the library on Javascript and PHP. I want to learn these languages to make my websites more interactive. I am using what I learned on the project for this course as well.
   Another aspect of computers I would like to branch out to is developing apps. I have an idea on a particular app that I would need in my daily life. When developing apps, I heard it was a good idea to develop one that you personally would like to use. I do not have a car, so sometimes I depend on local transportation to get where I'm going. I have to wait a long time for the bus when it is late. I would like to make an app that tells bus riders how far away their bus is. I've seen this system already on Washington D.C.'s Metro. However, their system was by the tracks. It was not on the rider's handheld. CARTA also had this system online. But yet again it was not available on a phone where it would be the most convenient.The system would involve sensors on each bus. The system would then calculate how far the bus is from the person's location. This would all be shown on a map on Charleston.

Blog Reflections #13: Hover, banner, final!

    After a few tries, Hannah and I got a hover to work in our html report that contains the requirement being tested for a specified testcase. I thought this was a cool way to show the requirements without taking up too much room on our table. Albert also created a banner for our poster. It is very fire-y!
   We also had a little problem with our framework. It was only taking float types for our max and min methods. Our next task will be expanding our testing framework to use more than just the max and min methods. I like this idea better. I feel like coming up with many test cases for one method will become redundant and pointless. In the max function for example: if we test two positive integers for a test case and then for the next test case we also test two positive integers there wouldn't really be a need for that.
    We will finish deliverable #4 this weekend. We have also planned on seeing Dr. Bowring early next week to see if we are on the right track with the changes we made in deliverable #3.
      I have also started studying for the final. I am starting by reading through all the chapters we have gone over in class. I hope I do well! :)

Blog Reflections #12: More Deliverable #3 Feedback

    We got the feedback on our write up for deliverable #3 to be more specific with what our script does exactly. Also, we needed to be more fluid and narrator like in our writing. When we looked at the project from the previous year, they listed what all the methods did in their script. We do not have methods in our script, but we are going to model ours after that write and write all what our script does.

     This weekend, we started to add those changes to our write up. We also started to add Method names and requirements to our table. I am trying to figure how to add a hover to the html/css code so we do not have to add an extra column for the requirements. This idea was suggested to us, and I liked it.

    We also found all the test cases we will be using for the whole project.

Blog Reflections #11: Deliverable #3 Feedback

   I feel like our presentation for deliverable #3 went well. Our script ran as planned. We have to make a few changes that I feel we already knew about coming into the presentation. We need to:

• Not hard code our methods into their specified drivers
• Add a method and id column to our html reports

  These are easy fixes. We will change these two things this weekend. Once we change this we still need to find 1 to 2 more methods to test. If we finish this, we will be way ahead of our schedule and can start working on our poster. 

Blog Reflections #9: Successes and Searches...

   My team and I now have our whole framework working with our simple methods. We are still in the process of finding methods that actually relate to the Firefox desktop software. This is the only thing keeping us off our schedule.
   In addition to still trying to find workable methods, we have started on re-working our test plan based on the feedback we received during our last presentation. We also will add our experience report for deliverable #3 in this document. I have many things to report on for this deliverable. It was the most challenging to date.

Blog Reflections #9: Slowly Putting it all together

    We now have a script that iterates through all our testcase files, one that compares two files (and outputs whether they are the same or different in an html document), and one that extracts the input part of the testcase file in order for us to use this for parameters of the method we will test. We are now in the process of putting all of these scripts together in one coherent script that will become our runAllTests.

   After we get done with this, we will try our script on the actual method we want to use from the Mozilla Firefox code. I hope all goes well and our Toy code is flexible enough for this big change.

Blog Reflection #8: Toy project

   For a while I have been trying to isolate a floor mod method I found within the Firefox code, to test in our project. Instead of spending more time on this, I decided to make up a simple add method, get it to compile, and work with that. I planned on getting it to do all the requirements of deliverable 3.

  I worked with Hannah on most of this. We were able to figure how to print the result of the add method to a text file. We then worked on a script to compare this text file to another text file (toy oracle) that just had an example outcome in it. We then were able to get the results of this compare to print in an html document in a browser. This process was very rewarding!

   We now are trying to see how we can add all of the other requirements to our test case file (information such as testcase #, requirement tested, inputs, and outcome), and have our driver read this and grab our inputs from this text.While we are working on this, Matt will stay working on isolating the "real" method we need to work with.

   I am particularly proud of the work of Hannah, Matt, and myself. Unlike the groups who have already finished deliverable 3, we did not have anybody in our group with prior experience with Linux scripting OR c++. At first, I was doubting whether we could overcome this learning curve in time to turn in this deliverable. NOW I think we can if we stay at it. I am learning ALOT while working on this project! :)

Blog Reflections #7: Scripts, scripts, and more scripts!

   In preparation for deliverable #3, I have been going over the scripting tutorials on this site again. This site went over many scripting functions. I went over test script programs that:

• Displayed the date
• Displayed the current user
• Stated the operating system
• Utilized the read statement to get input from a user
• State the current working directory
• Searched for a specific file within the directory
• Writing functions in scripting 

Here is a screen grab of one of the scripts:

    I started to write deliverable 3, but ran into some trouble. I hope these tutorials will help me write the testing framework for our project. I am learning alot, but I still want to complete the project.

Blog Reflections #6 - Digging Deeper (Team Update)

    In the last class, we went over our test plans for our projects. During our presentation, we noticed that we may not have the time to do all the tests we previously wanted to do (for example testing how Firefox handles the stress of operating with many tabs open). We are now in the process of specifying our test plan. 

    We are going to dig deeper into Firefox's source code to find just a few methods. We are then going to come up with different inputs and expected outputs for these specific methods. I think this actually makes things easier for us. I liked the feedback we received. I would rather be told we were being too ambiguous than not having enough to work with. This was encouraging. I hope we are able to understand, and effectively test the method we choose. I also hope we are able to get alot of work done during the upcoming break. 

Blog Reflection #6 - Group...Team/IEEE Test Plan

    My group has progressed. When we first started working together we sat separately on our computers and searched anything we could about our project. Now, we are more comfortable with our knowledge of Mozilla Firefox. We are working better together and we finished our test plan very efficiently. One of the main things I like about working with my particular group is the distribution of work. We ALL helped work on our test plan, and we are trusting each other's ideas more. I feel we are more than a group now, we are becoming a team. 

   For our test plan we followed the IEEE standard test plan. Although this was a more difficult approach, Iwefelt like we would need to learn this for when we help make a test plan in the future. We would have to follow IEEE standards, so it would be good to get a head start on following these protocols early. 

    Here is the IEEE test plan example we followed. I felt this was a very clear example to follow: 

http://www.computing.dcu.ie/~davids/courses/CA267/ieee829mtp.pdf 

    

Blog Reflections #5: Testing, Testing...

On Tuesday, we had our first test on everything we learned so far in Software Engineering. I have learned many things from this course. Some of the key things I learned include:

The difference between software engineering and computer science:

• Computer Science focuses on theory and fundamentals, while software engineering is the actual process of developing software.

Sociotechnical Systems:

• Sociotechnical system are the non-technical elements(such as people, processes, and regualtions, etc.), as well as technical components such as computers, software, and other equipment. 

Wicked Problems

• A problem that is so complex and involves so many related entities that there is no definitive problem specification. 

Fan-out

• When a method calls many other methods. 

Re-factoring

• Continuous improvement; combats the degregation of changes. 

Enthnography

• An observational technique where the software engineer put his or herself in the shoes of the user. 

Code & Fix

• I learned this is the worst technique when coding. 

None of these concepts were included on the test. They just stood out to me, and I feel like I should know them if I want a career in software engineering. 

~Team Update~

   My team and I are finishing up the tests we have been running. Firefox has 16 different types of tests so we split this up among the 5 of us. The testing for Firefox is very thorough, so I think it is a good idea for us to see every kind of test in order to fully understand the system. We are starting deliverable #2 today. 

Blog Reflections #4 - Project Update

   We have to change our project again because of lack of testing documentation with Express js. Another problem with Express is that it is written in Javascript. We would not be able to run executable tests with any open source project written in Javascript. Express also did not have much documentation on the tests. Whenever we ran the tests it showed the amount that failed, and the amount that passed. It did not say

specifically what was going on in this test. I wanted to choose an open source program with more documentation.

    So I started to look at Firefox. Firefox is a well-known web browser for Windows, Mac, and Linux operating systems. It was created by the Mozilla Corporation. The Mozilla Corporation's site had many resources for developers. This was something I definitely wanted when looking for a new project. Because I have never worked on an open source project before, I wanted a wide range of support in case I had an issue. On the site, they had very clear instructions on how to build and run Firefox. It also had links to websites that explain how to run tests.

Running Tests

   I know that Firefox has many tests associated with it, but I am having troubles finding out how to run these particular tests. I am having issues loading Marionette (an Python test runner for Marionette tests) to my system. I need this in order to run the Python tests on the Firefox system. 

 I am currently reading any online source I can find to build Marionette and have these tests up and running. This is becoming very time consuming, but I feel like I am close to a result. I am excited to see what components of Firefox these built-ins tests test. 

Reading Response, Blog Reflections #3 -Team experience update

Chapter 8

  Chapter 8 of the textbook talks about Development Testing. I learned alot about the benefits of test-driven development. These included:

Code Coverage - every code has one associated test.

Regression testing - a test suite is developed incrementally as a program is developed.

Simplified debugging - the problem should be obvious when a test fails.

System documentation - tests act as a form of documentation of what the code should do.

I never did test-driven development so it was good to see what the benefits of this type of testing is.

Team Update
My team and I decided to choose the Express open source project for our semester project.
Express is a web application framework. It utilizes node.js for execution. node.js is software platform used to build network applications. Express can be used to to design single and multi-page web applications. We had many building issues with our first choices. Express was our third choice.

Our first choice was Evergreen, an integrated library system. However, the instructions for building it were unclear. I think this should have been an aspect we looked at before making a choice on a project.The second choice we had was Amara. Amara is a system that improves videos for people who have disabilities. We also had building problems with this project. It utilized another system called Vagrant. Only one of us were able to load this onto our systems. I did not want anyone to not fully have the project on their computer. We then decided to change our project once more. I tried to look for projects that were written in languages that I know very well so I can help more.

What's Next for our project...
Test planning is a new concept to me. In CSCI 360, we did a project but we not come up with a test plan for it. **Test planning involves scheduling and estimating the system testing process, establishing process standards and describing the tests that should be carried out. My team and I are going to work on our schedule for our project this week. We are also going to start Deliverable #2.

Blog Reflection #2 (Reading Response)

    My group and I decided on working with  The Evergreen Project. This particular project involves an integrated library system. Libraries use this system to "provide their public catalog interface as well as to manage back-of-house operations such as circulation (checkouts and checkins), acquisition of library materials, and (particularly in the case of Evergreen) sharing resources among groups of libraries". I liked this choice. I am very interested to see how we can optimize this system. I like that the work we're doing will have an educational benefit, not only for us but for the libraries as well.

   This week, I also read "Intro to Testing" chapter put on the class site. While reading this, I learned I had many misconceptions regarding testing in software engineering. One of the main things I learned was: the differences between testing and debugging. Testing is the process that finds bugs, while debugging is the actual fixing of these bugs. I also learned a better order for software design while reading this chapter. Dave Gelperin and Bill Hetzel advocate: test, then code. At first, I did not understand this concept, but when they went more in depth on the subject, I got it. The author stated that this is a good model for the phases of software engineering: "design, test design, code, test code, program inspection, test inspection, test debugging, test execution, programming debugging, testing”. Testing is after almost every stage of the development here. Before reading this I did not think testing should be in every stage. 

  I also learned the difference between functional and structural testing:

·         Functional testing

o   Black box

o   Subject to input and outputs. 

·         Structural testing

o   White box

o   Looks at implementation details:

§  Programming style

§  Source language

§  Database design

Blog Reflection #1

Last week we were put into our groups for optimizing H/FOSS projects. My group members are Hannah, Chris,Albert, and Matt (click their name to see their blogs on our progress as well). I'm really excited to pick a project, and see how we can make it better. This project is especially important to me, because I do not have a job that relates to computer science at the moment, but doing this will give me insight on how things will work when I graduate and get a job that does. 

    When picking a project I tried to look for something that was not very mature in terms of coding and function. That way, my team and I could have a big impact on it. I also wanted to pick a project I had a personal connection with.

    I liked the Poet Image Description project. It is a project that wants to add image descriptions to e-books, digital textbooks, and websites so they are more accessible to people with disabilities. I make websites sometimes, and I have always wanted to learn how I could make my sites more accessible to people with disabilities. I think working with this particular project would be a good learning experience. I also liked the FOSSology project. It deals with licencing of the projects we are looking at. I think this directly connects with what we are studying this semester. 

Reading Response #4

This week I read the first 4 chapter of The Mythical Man-Month. This books is an in-depth analysis of software engineering. The first chapter of The Mythical Man-Month deals with an extensive metaphor for large software engineering projects. Fred Brooks relates large programming projects to “beasts in tar”. The more the large and powerful beast tries to break free from the encompassing tar, the more they are engulfed in it. This relates to programming projects, because the more we try to compact the issue with the programming the bigger the problem becomes. Brooks states that the reasons for this are: we do not fully understand the issues before we try to solve them. We think too much of the program itself, and not enough of the surrounding aspects that come with coding.

            I thought this analogy was very accurate. In programming II, we had to create a user interface for an educational grading system. I felt as though I spent much of my time trying to make sure my code compiled fast, without errors, instead of trying to make a structure that was user-friendly (a topic that Brooks tackles in Chapter 4). I needed to understand, as Brooks stated, that programs are just ONE part of the programming system (a collection of interacting programs) and that it leads to a programming product. I did not see the bigger picture. However, I think I have matured since then.

            I also found the third chapter in the book particularity interesting. In it, Brooks goes over a model of software engineering roles that he thinks would work best when trying to conquer large projects. He calls it the surgical model, because he modeled it after the design of surgeons. These roles included: a chief programmer, a copilot, an administrator, 2 secretaries (for the editor and the administrator), a program clerk, a toolsmith, a tester, and language lawyer. The chief programmer’s job is to design the program, code it, and write it, and provide documentation. The other roles job is to support the chief programmer’s job. For example, language lawyer provides advice on how the chief programmer can produce more optimal code. I completely agree with Brooks model for positions. When I first read the chapter, I thought that having a chief programmer do most of the coding would put too much pressure on that one person. However, as I read on and saw how much the other position can help, I thought this was a good model. I feel when you have many programmers focusing on one issue communication can become convoluted. I feel nothing can get completed is communicate is halted.

            The fourth chapter also caught my attention. Brooks goes over the value of conceptual integrity. As a consumer of technical products, I feel as though this is an issue that needs to be addressed more in software engineering. I have used many software products I have felt were not very user-friendly (ie. Instagram). Whenever I search for something or someone of Instagram, it never finishes what I am typing. I feel if they worked more conceptual integrity this product would be way better. Brooks states this problem can be solved by separating architecture and implementation. I concurred. If most software products did this, users would not have as many problems with the interface.

            Overall, I thoroughly enjoyed reading the Mythical Man-Month. I hope we can have the opportunity to red more of it in the future, or maybe even finish the whole book.

Video Response #1: The Future of Programming

    The Future of Programming video went in depth on a new programming IDE, called Cloud 9, that utilizes program development technology within a cloud. I like how Cloud 9 used successful components of other popular software (Netbeans, Word, Google Doc, iCloud), and put it all together in one place. However, I am not sure how Cloud 9 will do in terms of becoming the next big IDE in terms of wide use by programmers.

There were many aspects to Cloud 9 that I found interesting and useful. Here are some:

• Collaboration support - When I worked on a project for CSCI 360 I found Google Doc's collaborating support very useful. An IDE with this capability is a great idea. 
• "Fully available workspace" on cloud/Safer - because my work would not be on a local drive, it would make me feel safer about my work. As hackers get more sophisticated in their approach this would be a better way to save work instead of on an actual computer. This would also be useful in the unfortunate event that I lose my computer or it crashes. 
• Supports Javascript, CSS3 - I use Javascript  with CSS components quite a bit, so the fact that it supports this is really helpful. 
• Scalability - It was able to process 27,000 files without slowing down. This was impressive. Whenever I work on projects from school they involve many files so an IDE that can handle this would also be convenient. 
• Auto-completion - This is something I found useful in Netbeans. It allowed me to finish code faster. 
• "Ability to work offline" - I thought it was handy that Cloud 9 is able to work both through the cloud, and offline. It has the best of both worlds. 

    Even though Cloud 9 has many useful components, I am not sure it can be considered the "future of programming".  It takes several years (maybe decades) for people to accept new technology. An example of this can be seen in the history of programming itself. In the beginning, programmers only used binary to execute whatever they needed. When abstract, higher level programming was introduced it was not widely accepted for years. 

   I read a few comments under the video as well, and it seemed that some of the  programmers thought the software they use now already does what they need. They named similar programs such as: Vim, Emacs, or Sublime Text. I think they felt Cloud 9 had many features that were unnecessary. The notion that: technology changes fast, yet people change slowly was apparent in these comments. I feel Cloud 9 will be widely used in due time. 

Reading Response #3

Security and Privacy Vulnerabilities of In-Car Wireless Networks

While reading this article, I learned many things about tire pressure management systems. I did not know that tire pressure devices utilize wireless devices and that these devices could be used to track where the driver goes. I also never thought that someone could/would use a tire pressure device to misinform the driver that their tire is low in order to rob the driver. These were both very frightening facts. I like how this article first mentioned the benefits of using more wire in cars, but also went in depth about the vulnerabilities of using this technology.

The Magical Number Seven, Plus or Minus Two

The magical number 7 states that the most the human brain can remember is around 7 items at a time. This is helpful information for any student. I tend to get frustrated with myself if I cannot remember many things all at once. Now I know that there is a natural reason for this. I liked this article. I found it interesting to read about the limits of the human brain. I'm also interested to see how this will relate to software engineering. 

Planning for Failure in Cloud Applications

            In this article, Mike Wood talks of a notion mentioned in Chapter 11 of the textbook: survivability. Wood goes in depth on how to keep systems running even when they fail. I learned about many preventive techniques to combat software failure in this article. Automation was something I did not know about before reading this article. I did not know that if you tried to recover a system manually that the recovery time would increase. I feel the idea of automation would be very useful. It is almost as if you are coding the system to treat itself. I also did not know scripts can be utilized in this. I thought scripts were just for managing directories not for restoring  full systems. I did not know they were this powerful. I also learned how to deal with transient errors by using re-try code. I never thought to add a re-try to my code before. This article was very insightful. 

Book Exercises #3

    Chapter 4 is about requirements specification.

4.5 (these are examples of one function that these systems are expected to perform)

• Petrol gas pump with card reader. 
• The user expects the system to cease pumping the fuel whenever the amount specified is reached. 
• The cash-dispensing function in a bank ATM. 
• When a user touches the button containing the specified amount of money they need, the ATM's cash-dispenser should give out that amount of money.
• The spelling-check function in a word processor. 
• When a user spells a word wrong within the context of their sentence, the system should recognize this error and alert the user. This alert can be done by making underlining the word, or automatically changing the word to the correct one. 

4.6 

    To keep track of the relationships between functional and non-functional requirements, a software engineer can create a requirements document. In the system requirements specification section, they can specify the both the functional and non-functional requirements. Defining both in the same section will also define their relationship. The software engineer could also draw a simple diagram linking non-functional requirements with their corresponding functional requirement. 

4.7 

    Withdraw allows account holder to get money from their personal accounts at any location an ATM is present. The user initiates this transaction by inserting their debit card into the ATM . Then, they verify their credentials on the system by entering their pin. The user then species which account they would like to take the money from. The user then specifies the amount of money they would like to take out. The system then dispenses this amount. The last thing the system does in this particular transaction is asks if the user wants a receipt to keep track of the transaction.

   Actors:

• Account Holder
• Bank

   Other possible use cases:

• Transfer money between accounts
• Deposit money into account
• Inquire about an account

Experience Report (Subversion/VMware Player)

    This week I also learned how to use subversion and VMware Player. This marked the second time I have used the Linux terminal. The first was this summer. I found that writing out the commands and what they do helped me finish this assignment a little bit faster. I feel as though the command shell in Linux just looks like it is more challenging than it is in actual execution. 

   Using VMware Player was challenging at first. I could not get it to work. I kept getting a boot error. To get this to work, I just needed to boot from the iso file. I like using VMware Player because it is allowing me to explore an operating system I rarely use (Linux). Even though all of this took some time, I learned a wide range of things.

Reading Response #2

The theme of this week's reading is software failures. There were many aspects of the failures that we read about that surprised me. The main things that caught my attention were: the apathy after the software failure occurred the costs of the software, and the lack of proper testing.

One of these things was the reactions to the software failure by the people who played an important role in the function of the software. When the New York Times’ article about radiation overdoses stated that Alabama officials said that there was "no such thing as overdoses", I was astonished. I always thought that when the lives of others were on the line that the people that could help would react in a more urgent matter. I thought that they would try to fix the problem as fast as they could instead of avoiding the problem by stating there wasn't one. Some even denied their responsibly. An example of this was when the GE spokesman stated that the scanners were "programmed by the user not the manufacturer." I feel even if the user does make a mistake some of the responsibility falls in the software engineer’s lap. This is because in good software there are hazard avoidance attributes that can prevent human error from happening.

Another common characteristic I saw in these articles that surprised me was the amount of money used in the construction of these software projects. The Mars Climate Orbiter cost $193 million dollars, and the duration of the project was about 280 days because of a software failure. The FBI’s Sentinel project has a $451 million dollar budget. This shocked me. I tend to associate large amounts of money with good quality. However, while reading these articles proved to me that this is not the case.

The last re-occurring problem that I saw in all the articles was the lack of in depth testing before putting the finished product out to the public. This can be seen in the Therac-25 incidents. There was a disconnection between the operator interface of the program and the setup of the program. This problem could have easily been avoided if proper testing was practiced.  Another assumption I made was about software that involved medical devices was that they were almost full-proof and well-tested. This was another association that was proven to be incorrect.

Because software engineering has such a wide appeal and is integrated in so many facets of life it is more likely that there can be failures. Nevertheless, I think this face should empower software engineers to make better software because they already know its effect will have a huge impact. I liked reading these articles so I can see what issues may occur when I am creating software in the near future, and I can avoid these problems. Even though a lot of the things I read surprised me, it was interesting to see how anyone can make mistakes at any level of software engineering. This was a scary, yet reassuring detail. 

Book Exercises #2 (Chapter 11)

    Chapter 11 describes Dependability and Security attributes that are prevalent in successful software engineering.

11.4 For An Internet server provided by an ISP with thousands of customers, security would be be the most critical because internet services are networked. This can provide a gate way for intrusions.

For A computer-controlled scalpel used in keyhole surgery, safety would be critical because the scalpel will be used for medical treatment and could possibility hurt someone. However, you would want the probability of someone getting injured from the scalpel to very low or non-existent. Making safety the most important dependability attribute in this situation.

For A directional control system used in a satellite launch vehicle, maintainability would be very important. Because the device has to help with direction changing it will have new requirements emerging at any moment so the system should be able to cope with these changes.

For An internet-based personal finance management system, survivability is the most important. The system can be under many attacks. So it is important for the system to still be able to run under these attacks.

11.7 One hazard that can arise from a radiation system is over-dosage. A software feature that can be added to avoid (hazard avoidance) this problem is having the system shut off whenever it reaches a lethal dosage of radiation.

11.9 

Threat to confidentiality - Someone can find out a login for a staff member and get information on patients and their treatment.
 To avoid this, staff members can have stronger passwords, but not so restrictive that they write it down. A happy medium needs to be executed.
Threat to integrity - Someone can accidentally delete a patient's profile completely.A log of deleted can be kept everyday just in case data is deleted on accident.
Threat to availability - A criminal gets access to the system and shuts it down for a particular amount of time.The system need good maintainability. It needs to be able to come back on after this type of attack. There needs to be a way to distinguish that this was not an authorized user who shut down the system.

Reading Response

In addition to answering the text book exercises, I will also be responding to many software engineering related articles. This week I read No Silver Bullet by Frederick P. Brooks Jr., Kode Vicious by George V. Neville-Neil, and Software Analytics: So What? by Thomas Zimmermann.

Here is my response to the articles:

No Silver Bullet by Frederick P. Brooks Jr.

   In this article, software engineer Frederick P. Brooks goes over the many issues with software engineering. Brooks relates the complexes of creating software to the terrors of werewolves. The first aspect of this piece that surprised me was the year (1986) in which it was written. This shocked me because many of the problems that Brooks mentioned are still prevalent in today's software engineering world. Problems dealing with changeability and invisibility. He also states that there are many breakthroughs to combat these problems. Breakthroughs such as: Higher-level programming, time-sharing, and unified programming languages.

  I liked how blunt Brooks was about the issues within software engineering. However, I feel that his views about the solutions to the problems were a bit pessimistic. I feel the many breakthroughs with software engineering do in fact help. For example, higher-level programming deal with the issue of changeability by making it rather easy for programmers to change their code to meet the requirements of there clients.

Kode Vicious by George V. Neville-Neil

   Kode Vicious was my favorite article to read this week. I enjoyed the question and answer format. In this article, Neville-Neil answers his readers' questions about the notion of "cherry-picking", and ways to approach problems in software engineering scientifically.

  I really liked his answer to the second question. He gave the advice of using the scientific method to keep track of one's answer to a computer programming related issue. I liked this because, even though we are Computer Science majors we do not really approach CS like we would any other science and I think this is the wrong approach. I think alot of the headaches I have gotten as a result of a programming related issue could have been avoided if I used Neville's approach of systematically conquering the issue the way I would if I was conducting a chemistry-related experiment. I like the idea of writing "testable ideas" on note cards, then seeing if what you wrote worked or did not work. I will definitely try this approach in my future programming endeavors.

Software Analytics: So What? by Thomas Zimmermann

    I find the study of Software Analytics rather interesting, so I enjoyed reading this article. I think this subject will be a big field of study in the future and I am excited to see what software engineering brings to the world of data.

Textbook Excercises

Textbook exercises

Chapter 10 of the text goes in depth on sociotechnical systems. Here are my answers to the  exercise questions:

10.6 
  The organizational difficulties that arise will learning the new software that will be in place. The museum employees who know how to work this new system will have a new deal of political power in the organization because of this knowledge.
   Another problem that may arise is job changes. For example, if the museum had live artist renditions of ancient Greece or if they had live actors re-enacting battles that occurred in ancient Greece then they will not need to use these actors or artists anymore because of the new system. The system has de-skilled the current employees.
   The last change will deal with process changes. Current employees might not like that they have to learn how to use a new 3D software, and will reject the system.

10.10 
   I do not feel that it is your responsibilities to finish the work you have start since you do not have access to it anymore. I think it would be a good idea however, to communicate to the new person contracted to this project of the issue you encountered while you were working on it.

First Blog Post :)

     My name is Lisa Smith. I am a senior Computer Science major at the College of Charleston, and this is my first blog post for CSCI 362 (Software Engingering) course. In this post, I will be answering exercise questions posed in the ninth edition Software Engineering text book by Ian Somerville.

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

All professional software should:

• Deliver the required functionality
• Be maintainable
• Be dependable
• Be usable

4 other useful attributes of software:

• Be trustworthy - the software should do its function 
• Be secure for the users involved
• Be consistent - the software should work each time it is in use
• Be comprehensible - the user should understand how to use the program

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

    Because of the extent of software engineering in everyday activity, I believe software engineers should go through certification. A higher level of skill and training should be required in order to have a part in the everyday lives of people. However, I do not think the certification should be as long as a doctor's training. Software engineering can involve the lives of people in its hands, but it is not always that way like it is in the medical field. 

1.9 Suggest an example that illustrates each clause in the ACM/IEEE Code of Ethics.

1. PUBLIC

• A software engineer thinks of an app to help people get to work faster by finding the quickest route. 

2. CLIENT AND EMPLOYER

• A software engineer does not use their position and customer access to invade on the privacy of the customers of a company. 

3. PRODUCT

• A coder tests their work many times until they know it can be useful to a specified customer. 

4. JUDGEMENT

• 
  

5. MANAGEMENT

• The managers of software engineering projects lead by example by following all of the following clauses themselves. 

6. PROFESSION

• A coder uses a piece of their colleagues code, and cites this use in the comment section of their program. 

7. COLLEAGUES

• A software engineer at encourages ways to advance their co-worker's project. 

8. SELF

• A recent Computer Science graduate, continues to code, and learn new practices in their free time. They do this by reading text book, working with other coders, and using products and thinking of ways to improve them.

1.10 

   This specific example goes against the Code of Ethics proposed by IEEE and ACM. If one takes part in this they will specifically be going against the PUBLIC clause. To modify this and make the project fall in line the code of ethics, the software engineer would have to ask for consent from the public.