Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


V5 Risk-driven design: A summary of Pew & Mavor (2007)

Discusses Pew and Mavor NRC Report

frank ritter

on 26 June 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of V5 Risk-driven design: A summary of Pew & Mavor (2007)

Pew, R. W., & Mavor, A. S. (Eds.). (2007). Human-system integration in the system development process: A new look. Washington, DC: National Academy Press. http://books.nap.edu/catalog.php?record_id=11893.
[Free with registration.]
Offers a New look at HCI/HSI - It is risk-driven process
Offers insights into HCI/HSI organising principles
- - A way of knowing
- - How to argue HCI
- - When to shut up

17% of my first sabbatical
Useful for teaching @ PSU (Stark & Kokini, 2010)
Goals of this talk
Show/Learn how to leverage the results of the report
Teach and be taught about system design
Provide you with tools to argue for better design
By reducing risk
Discuss the application of user models that it represents
Provide an organizing framework for HSI/HCI/HF:
Ways of knowing (HCIC workshop intro)
Teaching materials now on web for free
Problems with (Future) Systems of Systems Development
Lack of commitment by funders & managers to avoid HSI risks
Lack of communication between system engineers and human-system experts
Difficulties providing data about humans into the design process
Thus, the study/literature survey at beginning of book (also see: Booher & Minniger, 2003; Casey, 1998)
Pew and Mavor (2007) Charged to:
Work with a panel to
Comprehensively review issues
Evaluate state of the art in HSI (and engineering)
Develop a vision
Recommend a research plan
Boehm & Hansen (2001)
Starts with Boehm's Spiral Model
Life cycle phases
Essentials of the Spiral Model
Concurrent development of key artifacts
Each cycle does Objectives, Constraints, Alternatives, Risks, Review, and Commitment to Proceed
Level of effort driven by risk
Degree of detail driven by risk
Use anchor point milestones
Emphasis on system and life cycle activities and artifacts
Small Example1
Small Example 2
Barry Boehm
Jeremy Lothian
Dick Pew
Anne Mavor
Erika Poole
guy on plane
ONR N00014-10-C-0281 /N091-086/P10008, N00014-11-1-0275, N00014-06-1-0164
The committee
Implications for System Design
A way to view system design
Comparable to waterfall (see http://www.waterfall2006.com/)
and other approaches noted in P&M book
Risks related to humans (users) are often ignored by system engineers
People naturally work on risks, so theory is not just normative but descriptive [Ritter says]
Risks related to HF ignored by hardware engineers
[Jade JOKE]
Risks related to hardware are ignored by HF professionals
The fundamental attribution error of design [ABCS of HCI]
Can/could/should bring in experts to advise
If no HCI risks, then nothing needed from HCI
See recommendations in book
Other recommendations?
Can be used to classify HCI/HF as ways of knowing risks:
What does this mean for HCI, HF, HSI?
All HCI techniques can be seen as a way to reduce risk

For each stage, HCI techniques to reduce risk:

Define opportunities and context of use: scenarios, personas, task analysis

Define requirements and design solutions: TA, models

Evaluate: VPA, behavior loggers (e.g., RUI)

<Insert your favorite method>

Shared representations are passed between these stages
[read here: Models]
Shared Representations as Part of Design Process - Uses
Examined critically
Reduce working memory load
Make explicit what is explicit and implicit
Produce new connections
Collaboratively produce new knowledge
Transfer knowledge
Can't manufacture
Can't deliver
Performance doesn't match other stakeholder requirements
Wrong types of developers and HIS professionals
Forget how to edit prezzi

Performance does not satisfy user requirements
Mismatch of system to context (sand in tools)
See Booher and Minniger (2003), Casey (1988), etc.
Example risks
The Risk Management Process: Handling Options
Methods for Reducing HSI Risks
Three major periods of use of methods
Define context of use
Define requirements and design solutions
All fit back into spiral
All used to reduce risks using previous approaches
We have bags of these methods!
Classification to period is somewhat arbitrary
Not exhaustive, illustrative lists to follow
Why you start with KLM to look at built systems: used to be given system then
Can look for missing methods given this list
Many HCI projects are not in a small box, but cut across boxes/phases,
Many are constraints on things in the boxes, or ways to view the boxes, or ways to share results across boxes. So, learn boxes.
Can choose method based on risk if you care about risk or project, method if you care about method!
Some HCI work ignores this flow, and ends up being narrow, undefined wrt to HSI process, and further from designers
Further Insights
1. Impact from insights and usability may also come on next project
-- task size, task complexity, task interrelation
-- so results must be learned and mothball-able
-- sharable to next design and designer

2. Designers think they are already risk-driven
-- but, of course
-- good: buy-in to part
-- bad: "already know how"
-- Insight: we need to give designers counter examples

3. Education and shareable representations are more important than I thought: We are working on Herbal/EasyCog, ABCS of HCI, RUI, How to run studies, tutors with page view
Ritter's Conclusions and Final Insights
Baumer, E. P. S., & Silberman, M. S. (2011). When the implication is not to design (technology). In Proceedings of CHI, 2011, 2271-2274. ACM: New York, NY.

Boehm, B., & Hansen, W. (2001). The Spiral Model as a tool for evolutionary acquisition. Crosstalk: The Journal of Defense Software Engineering, 14(5), 4-11.

Booher, H. R., & Minninger, J. (2003). Human systems integration in Army systems acquisition. In H. R. Booher (Ed.), Handbook of human systems integration (pp. 663-698). Hoboken, NJ: John Wiley.

Casey, S. M. (1998). Set phasers on stun: And other true tales of design, technology, and human error. Santa Barbara, CA: Aegean.

Pew, R. W., & Mavor, A. S. (Eds.). (2007). Human-system integration in the system development process: A new look. Washington, DC: National Academy Press. http://books.nap.edu/catalog.php?record_id=11893.

Stark, R. F., & Kokini, C. (2010). Reducing risk in system design through human-systems integration. Ergonomics in Design, 18(2), 18-22.
Risk-Driven Design
A review of Pew & Mavor (2007)
Evaluate alternatives with risk analysis & prototype
Review [with stakeholders]
Each Phase steps
(e.g., see Baumer & Silberman, 2011)
Risk-Driven Design
NDIA Workshop, 11 Sept 12

Book Conclusions
Include HSI early, understand how to use it
-> tailor methods and interventions to risks and resources
-> tailor discussions in terms of risks
Ensure communication of shared representations
models have to be understandable to non-modellers
there may be a progression of modelers
Further development
of process itself
to implement HSI as a field
to improve models (ease to create, ease to understand,
quality, use as shared representations, creation from data,
improve and understand usability objectives
What are the menu items for Word?
Which is the penny?
Order these light/switch mappings
A Quick Psychology Quiz
A short, direct, simple Bible knowledge question
What are the menu items for Word?
Which is the penny?
Order these light/switch mappings
A Quick Psychology Quiz
A short, direct, simple Bible knowledge question
Noah took animals on the ark
A, B, (cd)
3, 2, 1
Full transcript