1. Informatics 121 Software Design I
Lecture 7
Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

2. Today’s lecture
Design is difficult
Design methods

3. Software design application design interaction design
what is it to accomplish?
how does one interact with it?
application design
satisfactory experience
plan for realization
interaction design
change in the world
what is its conceptual core?
what are its implementation details?
architecture design
implementation design

4. Feasibility and desirability
designer
plan
maker
change in the world
other stakeholders
audience
experiences
desirability

5. Two fundamental challenges
The nature of software
The nature of people

6. 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 must 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

7. Nature of people Diversity Indiscernibility Familiarity Volatility
people differ in how they experience the world
Indiscernibility
experiences are distinctly mental in nature, with tangible reactions and signs not always matching the 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

8. Seven difficulties every software designer faces
Prediction
Tradeoffs
Change
Bias
Longevity
Quality, cost, and effort
Source code as a design notation

9. 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

10. 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 constituent audiences and certain stakeholders more than others
The difficulty lies in how to balance decisions across the needs and anticipated experiences of the various constituent audiences and stakeholders

11. 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 is to change it
The difficulty lies in how to balance accommodating change with making sufficient progress on the design solution

12. 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

13. 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

14. 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 are typically set by other stakeholders
cost constraints are 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

15. 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

16. Seven difficulties every software designer faces
Prediction
Tradeoffs
Change
Bias
Longevity
Quality, cost, and effort
Source code as a design notation

17. Software design failures
Air-Traffic Control System in LA Airport
Incident 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.

18. Software design failures

19. Design failures

20. 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

21. Design cycle goals constraints assumptions decisions ideas synthesize
analyze
evaluate

22. Backtracking what is it to accomplish? satisfactory experience
plan for realization
change in the world
what is it to accomplish?
how does one interact with it?
what is its conceptual core?
what are its implementation details?

23. Realistic design process
satisfactory experience
plan for realization
change in the world
what is it to accomplish?
how does one interact with it?
what is its conceptual core?
what are its implementation details?

24. Realistic design process
satisfactory experience
plan for realization
change in the world
what is it to accomplish?
how does one interact with it?
what is its conceptual core?
what are its implementation details?
What happens here?

25. Realistic design process
satisfactory experience
plan for realization
change in the world
what is it to accomplish?
how does one interact with it?
what is its conceptual core?
what are its implementation details?
Or here?

26. Design process
A design process represents a planned course of action as to how to tackle a design problem to arrive at a design solution
where to focus effort
what methods to use
whom to involve
A design process may be defined up-front in its entirety, or defined in increments as the design project unfolds

27. Design method
A self-contained, structured technique that guides a designer in advancing some aspect of the design project at hand
Serves as a bridge from the overall process of design to actual individual and collaborative design work

28. Origin

29. Today

30. Example

31. Example

32. Example

33. Example

34. Characteristics of design methods
Each design method suits a specific purpose with respect to the design cycle and overall design project
Each design method expects a certain context for it to lead to optimal results
Applying just one design method rarely suffices (but still may help)

35. Example – decision making

36. Example – unearthing assumptions

37. Example – generating ideas

38. Example – identifying goals

39. Software design methods
Application design
Interaction design
Architecture design
Implementation design
Analysis
competitive testing
contextual inquiry
feature comparison
stakeholder analysis
task analysis
critical incident technique
interaction logging
personas
scenarios
framework assessment
model-driven engineering
quality-function-deployment
reverse engineering
world modeling
release planning
summarization
test-driven design
visualization
Synthesis
affinity diagramming
concept mapping
mind mapping
morphological chart
design/making
participatory design
prototyping
storyboarding
architectural styles
generative programming
component reuse
decomposition
pair programming
refactoring
search
software patterns
Evaluation
requirements review
role playing
wizard of oz
cognitive walkthrough
evaluative research
heuristic evaluation
think-aloud protocol
formal verification
simulation
weighted objectives
correctness proofs
inspections/reviews
parallel deployment
testing