Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 121 Software Design I Lecture 5 Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.
Informatics 121 Software Design I. Lecture 5 Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited. Today’s lecture. Design failures Design is difficult Design studio 2 (video analysis). Design failures. - PowerPoint PPT Presentation
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 1
Informatics 121Software Design I
Lecture 5
Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 2
Today’s lecture
• Design failures
• Design is difficult
• Design studio 2 (video analysis)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 3
Design failures
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 4
Design failures
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 5
Design failures
(2006)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 6
Design failures
(1988)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 7
Design failures
(1988)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 8
Design failures
(1988)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 9
Design failures
(1988)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 10
Design failures
(1979)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 11
Design failures
(1984)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 12
Design failures
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 13
Software design
software designer software
compiler runnable program
users experiences
other stakeholders
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 14
Design failures
Air-Traffic Control System in LA AirportIncident Date: 9/14/2004 Ironic Factor: ***** (IEEE Spectrum) -- It was an air traffic controller's worst nightmare. Without warning, on Tuesday, 14 September, at about 5 p.m. Pacific daylight time, air traffic controllers lost voice contact with 400 airplanes they were tracking over the southwestern United States. Planes started to head toward one another, something that occurs routinely under careful control of the air traffic controllers, who keep airplanes safely apart. But now the controllers had no way to redirect the planes' courses. ... The controllers lost contact with the planes when the main voice communications system shut down unexpectedly. To make matters worse, a backup system that was supposed to take over in such an event crashed within a minute after it was turned on. The outage disrupted about 800 flights across the country. ... Inside the control system unit is a countdown timer that ticks off time in milliseconds. The VCSU uses the timer as a pulse to send out periodic queries to the VSCS. It starts out at the highest possible number that the system's server and its software can handle—232. It's a number just over 4 billion milliseconds. When the counter reaches zero, the system runs out of ticks and can no longer time itself. So it shuts down. Counting down from 232 to zero in milliseconds takes just under 50 days. The FAA procedure of having a technician reboot the VSCS every 30 days resets the timer to 232 almost three weeks before it runs out of digits.
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 15
Design failures
NASA Mars Climate OrbiterIncident Date: 9/23/1999 Price Tag: $125 million Ironic Factor: **** WASHINGTON (AP) -- For nine months, the Mars Climate Orbiter was speeding through space and speaking to NASA in metric. But the engineers on the ground were replying in non-metric English. It was a mathematical mismatch that was not caught until after the $125-million spacecraft, a key part of NASA's Mars exploration program, was sent crashing too low and too fast into the Martian atmosphere. The craft has not been heard from since. ... Noel Henners of Lockheed Martin Astronautics, the prime contractor for the Mars craft, said at a news conference it was up to his company's engineers to assure the metric systems used in one computer program were compatible with the English system used in another program. The simple conversion check was not done, he said.
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 16
Design failures
Ariane 5 ExplosionIncident Date: 9/1997 Price Tag: $500 million Ironic Factor: **** (By James Gleick) It took the European Space Agency 10 years and $7 billion to produce Ariane 5, a giant rocket capable of hurling a pair of three-ton satellites into orbit with each launch and intended to give Europe overwhelming supremacy in the commercial space business.
All it took to explode that rocket less than a minute into its maiden voyage last June, scattering fiery rubble across the mangrove swamps of French Guiana, was a small computer program trying to stuff a 64-bit number into a 16-bit space.
...
This shutdown occurred 36.7 seconds after launch, when the guidance system's own computer tried to convert one piece of data -- the sideways velocity of the rocket -- from a 64-bit format to a 16-bit format. The number was too big, and an overflow error resulted. When the guidance system shut down, it passed control to an identical, redundant unit, which was there to provide backup in case of just such a failure. But the second unit had failed in the identical manner a few milliseconds before. And why not? It was running the same software.
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 17
Design failures
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 18
Design failures
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 19
Design failures
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 20
A caveat: not all design failures are bad
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 21
A caveat: not all design failures are bad
But we generally do not have this luxury!
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 22
Design failures
designer plan
maker change in the world
audience experiences
other stakeholders
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 23
Design failures
designer plan
maker
audience
other stakeholders
desirability
experiences
feasibility
change in the world
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 24
Software design project
software designproblem
software designsolution
software design project
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 25
Two fundamental challenges
• The nature of software
• The nature of people
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 26
Nature of software (Brooks)
• Complexity– software is among the most complex people-made artifacts
• Conformity– software has no laws of nature that simplify its existence; rather, it lives in a
world of designed artifacts to which it much conform
• Changeability– software is subject to continuous pressure to change
• Invisibility– because the reality of software is not embedded into space, it is inherently
unvisualizable
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 27
Nature of people
• Diversity– people differ in how they experience the world
• Indiscernibility– experiences are distinctly mental in nature, with tangible reactions and signs not
always matching their actual experience
• Familiarity– people tend to be risk averse, sticking to role, organizational, and societal norms and
values
• Volatility– with every new exposure, people reinterpret and modify their opinions and
expectations
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 28
Software design is a wicked problem
• The problem is not understood until after the formulation of a solution
• Wicked problems have no stopping rule• Solutions to wicked problems are not right or wrong• Every wicked problem is essentially novel and unique• Every solution to a wicked problem is a “one shot operation”• Wicked problems have no given alternative solutions
Worse, software design is a ‘hard’ wicked problem
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 29
Seven difficulties every software designer faces
• Prediction
• Tradeoffs
• Change
• Bias
• Longevity
• Quality, cost, and effort
• Source code as a design notation
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 30
Difficulty #1: predicting people’s experiences
• Software design is a predictive activity that must anticipate the experiences of people• account for differing experiences• account for shifting experiences
– Furthermore, when people share their vision for a future change in the world, they tend to be conservative
– The difficulty lies in how to balance what people perceive they need and what they actually need
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 31
Difficulty #2: tradeoffs
• Tradeoffs must be made continuously over the course of a design project– a design solution is judged relative to other possible solutions that could
have been made– it is frequently impossible to quantify the relative virtues of each
alternative
• Furthermore, any given design solution inevitably satisfies certain stakeholders more than others
• The difficulty lies in how to balance the decisions across the needs and experiences of the various stakeholders
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 32
Difficulty #3: change
• Change happens and must be accommodated– changing client demands– changing context of people, hardware, and software– changing understanding of the design problem– changing attitudes of the audience
• Furthermore, the more complete a design solution already is, the more difficult it will be to change it
• The difficulty lies in how to balance accommodating change with making sufficient progress on the design solution
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 33
Difficulty #4: bias
• Bias exists within all stakeholders, and can be a positive or negative influence– audience– designer– client– others
• Furthermore, bias is typically difficult to detect and address
• The challenge lies in how to balance benefiting from positive bias while avoiding the effects of negative bias
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 34
Difficulty #5: longevity
• Longevity is expected of most software design solutions – software does not wear out– software fulfills critical societal services
• Furthermore, it very likely will need to accommodate new needs as well as deviations from present needs
• The difficulty lies in how to balance addressing today’s design problem with accommodating future, unknown needs
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 35
Difficulty #6: quality, cost, and effort
• Quality, cost, and effort are three constraining factors in design, not all of which can be optimized at the same time– cost constraints typically set by other stakeholders– cost constraints typically set before the design project is truly
understood
• Furthermore, there is no stopping rule, since no optimal design solution exists
• The difficulty lies in how to balance a design solution that is of good enough quality with expectations on cost and effort
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 36
Difficulty #7: source code as a design notation
• Source code is a terrible design notation for expressing goals, constraints, assumptions, decisions, and ideas
• Furthermore, other software design notations typically do not map easily to source code– while they certainly help make progress, much manual effort remains
in transforming findings stemming from the use of these notations to the source code
• The difficulty lies in how to balance use of other design notations with the need to ultimately express the design solution in source code
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 37
Focus on essence
• Every design problem has an essence, the key – and often most difficult – part that must be understood and addressed ‘right’ for the design solution (plan for change in the world) to satisfy the stakeholders
• Postponing understanding and addressing the essence of a design problem incurs a significant risk of rework at a later time
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 38
Focus on the unknown
• Every design problem involves knowledge deficiencies – gaps in the understanding of the design problem and its possible solutions – that must be addressed for the design solution (plan for change in the world) to satisfy the stakeholders
• Postponing understanding and addressing the knowledge deficiency incurs a significant risk of rework at a later time
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 39
Focus on making progress
• Every design problem involves times during which the design project gets stuck; focusing effort elsewhere and continuing to make progress is often the right approach in response
• Continuing to focus on a stuck issue for extended periods of time tends to be effort that is wasted
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 41
Design studio 2
• Design an educational traffic flow simulation program
• A 2-page briefing is provided, listing the main requirements for the system
• You will produce the design over a number of weeks, through a variety of structured exercises and arguments
• This will be an individual assignment, with group exercises worked in
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 42
Design studio 2
• This exact same design prompt was given to professional software designers– 1 hour and 50 minutes at the regular whiteboard
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 43
Design studio 2
• Watch the video, carefully
• Identify…– …five key decisions that the designers made– …options (ideas) that they considered when making these decisions– …mark the time(s) when these decisions points are discussed
• Focus on essence
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 44
Design studio 2
• Hand in a document, at the beginning of class, Thursday