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.
Wednesday, August 28, 2013
Monday, August 26, 2013
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.
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.
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.
Wednesday, August 21, 2013
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.
Subscribe to:
Posts (Atom)