130 likes | 146 Views
Assignments Week 5. Work on your paper / presentation topic papers are due 20 February (Tuesday) for both sections! Reading: Baase Chapter 5 (Intel. Property) quiz sometime this week, open Journals Do weekly journal entry this is a continuing assignment random review possible. 5th week.
E N D
Assignments Week 5 • Work on your paper / presentation topic • papers are due 20 February (Tuesday) for both sections! • Reading: Baase Chapter 5 (Intel. Property) • quiz sometime this week, open Journals • Do weekly journal entry • this is a continuing assignment • random review possible CSC 300, Winter 2001
5th week • Study Therac-25 case • get outside references for full story • Groups will advocate for particular party • on moral, ethical and/or legal grounds • produce a slide or two for 5 minute presentation • explicitly reference the SE Code of Ethics and moral or legal principles you want to use • each group member should participate • group presentation next week CSC 300, Winter 2001
Reliability and Safety • As usual, define the main terms • “reliability” • “safety” • a property of “software” itself? • what is a “system”? a “systems engineer”? • what is our relationship to it as software engineers? • what is “safety-critical” software? • what is “mission-critical” software? • examples? CSC 300, Winter 2001
Software Engineering Code • What is expected of a software “professional” (an ethical one :-) • list our duties under the code CSC 300, Winter 2001
What about Reality? • Software engineering strives for high quality and safety - • Requirements issues • preciseness: formal specifications • what profit from the abstraction? • generality: usability by domain specialists • where is the right balance? CSC 300, Winter 2001
Formal Verification • Use mathematics to “solve” the problem • start from formal specification • prove the specification is • complete • consistent • correct • prove the implementation meets the specification CSC 300, Winter 2001
Limitations of the Formal Approach • Software verification depends on other software • multiple layer trust issues • Peer review is not possible • why not? • Implementation issues may not be addressed • What about the formal specification itself? CSC 300, Winter 2001
Testing Saves the Day? • Software Testing limitations • what is possible? • what is not? • But what is expected from the Software Engineering Ethics Code? CSC 300, Winter 2001
“Standards” for Software Reliability and Safety? • Can we agree on a “negligence” standard? • based on software “design” judgment • where we have some idea what to do • process issues • Are there other safety problems to be addressed? • what about “mistakes” • good design can’t prevent such things • pure product issues CSC 300, Winter 2001
How Does the Law Classify Product Defects? • Negligence standard for design defects • not criminal law - its only about money • “reasonability” “due care” “fault based” • when would society want to place the burden on the victim for accidents? • when the social value of the design is very high • when would society rather place the burden on the developer for accidents? • when the social value of the design is low CSC 300, Winter 2001
Legal Responsibility • Strict liability standard • “no fault” “cause based” “due care irrelevant” • when would society want to impose responsibility regardless of fault? • what accident costs should never be borne by a victim • does society (state of the art) everbenefit from a “mistake”? • developers must internalize these costs as a “cost of doing business” CSC 300, Winter 2001
Does this Defect Classification Apply to Software? • What is a “design” defect for software? • What is a “construction” mistake for the software product? • Can we tell the difference between them? • Really big cost consequences! CSC 300, Winter 2001
Ethics of the Issues • What are the ethics of personal injury cases? • list SE code provisions • what do they say? CSC 300, Winter 2001