• Like
  • Save
Team Situational Awareness and Architectural Decision Making with the Software Architecture Warehouse
Upcoming SlideShare
Loading in...5
×
 

Team Situational Awareness and Architectural Decision Making with the Software Architecture Warehouse

on

  • 565 views

European Conference on Software Architecture (ECSA 2013) presentation on 4 July 2013 by Marcin Nowak

European Conference on Software Architecture (ECSA 2013) presentation on 4 July 2013 by Marcin Nowak

Statistics

Views

Total Views
565
Views on SlideShare
549
Embed Views
16

Actions

Likes
2
Downloads
2
Comments
0

3 Embeds 16

http://design.inf.unisi.ch 9
http://design.inf.usi.ch 4
https://twitter.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • having SA
  • distinguishstatus, properties, features of the environmentinterpret relations, interpreting valuesstate based on the current conditions and known dynamics
  • for the purpose of this talk
  • hence
  • stakeholders
  • shifting
  • ----- Meeting Notes (24.06.2013 11:58) -----state machine of the choice over the design issue
  • ----- Meeting Notes (24.06.2013 11:58) -----dual color colliding alternative
  • relate to the TA levels
  • put stress on problems and first then arrive to the solutions

Team Situational Awareness and Architectural Decision Making with the Software Architecture Warehouse Team Situational Awareness and Architectural Decision Making with the Software Architecture Warehouse Presentation Transcript

  • Team Situational Awareness and Architectural Decision Making with the Software Architecture Warehouse Marcin Nowak and Cesare Pautasso marcin.nowak@usi.ch, c.pautasso@ieee.org Faculty of Informatics, University of Lugano, Switzerland
  • Team Situational Awareness and Architectural Decision Making with the Software Architecture Warehouse Marcin Nowak and Cesare Pautasso marcin.nowak@usi.ch, c.pautasso@ieee.org Faculty of Informatics, University of Lugano, Switzerland
  • “The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark”* 3 Philippe Kruchten
  • Good decisions Informed Smart 4 Panel discussion on Architecture Decisions, SATURN 2013 Mineapollis, Minesota
  • Good decisions Informed Smart 5
  • Situational Awareness “The perception of elements in the environment within a volume of time and space, the comprehension of their meaning, and the projection of their status in the near future”* 6 * Endsley, M.R. (1995b). Toward a theory of situation awareness in dynamic systems. Human Factors 37(1), 32–64
  • Situational Awareness “The perception of elements in the environment within a volume of time and space, the comprehension of their meaning, and the projection of their status in the near future”* 7 * Endsley, M.R. (1995b). Toward a theory of situation awareness in dynamic systems. Human Factors 37(1), 32–64
  • Situational Awareness 8 Perception recognize monitor Comprehension make sense Projection predict future * Endsley, M.R. (1995b). Toward a theory of situation awareness in dynamic systems. Human Factors 37(1), 32–64
  • Assumption #1 Situational Awareness => good decisions 9
  • “*…+ 86% of architectural decisions are group decisions.” 10 * Difficulty of Architectural Decisions – A Survey with Professional Architects Dan Tofan, Matthias Galster, Paris Avgeriou, ECSA 2013
  • Assumption #2 No single architect has complete SA 11
  • Good decisions Informed Smart Consensual 12
  • Good decisions Informed Smart Consensual 13
  • Team Situational Awareness “The degree to which every team member possesses the SA required for his or her responsibilities”* 14 * Endsley, M.R. (1995b). Toward a theory of situation awareness in dynamic systems. Human Factors 37(1), 32–64
  • Team Situational Awareness “The degree to which every team member possesses the SA required for his or her responsibilities”* 15 * Endsley, M.R. (1995b). Toward a theory of situation awareness in dynamic systems. Human Factors 37(1), 32–64
  • Motivation Team Situational Awareness => good collaborative decisions 16
  • Team Situational Awareness for Architecture Decisions 17 distributed decision space decision metrics decision process guidance Perception Comprehension Projection
  • Reactive design document 18 Decision Space Architect Architect Architect Architect Other stakeholders Real-time sharing, collaborative decision making
  • Decision Space Comprehension 19
  • Decision Space Comprehension 20 Questionable Complex Obsolete Promising Positive Risky Negative
  • ISO 42010 decision meta-model 21 Architecture Element affectsArchitecture Decision RationaleConcern depends upon pertains raises justifies
  • ISO 42010 decision meta-model 22 Issue addresses Alternative addresses solvesArchitecture Decision RationaleConcern depends upon pertains raises justifies
  • Argumentation viewpoint meta-model 23 Issue addresses Alternative addresses solvesArchitecture Decision RationaleConcern depends upon pertains raises justifies Position Action Stakeholder Decision Force recommends pertains states
  • Argumentation view example 24 Account Access Security Web Services Security Mechanism Design Issue WS-Security HTTPS Plain text Architecture Decision Design Alternatives Compatibility issues Heavyweight Unsecure! Simple Practice proven Stakeholder Positions
  • WS-Security Argumentation view example 25 WS-Security Design Issue Architecture Decision Design Alternatives Compatibility issues Heavyweight Stakeholder Positions Account Access Security Web Services Security Mechanism HTTPS Plain text Unsecure! Simple Practice provenHTTPS
  • Argumentation view example 26 Design Issue Architecture Decision Design Alternatives HTTPS WS-Security Compatibility issues Heavyweight Account Access Security Web Services Security Mechanism Plain text Unsecure! Simple Practice proven Stakeholder Positions HTTPS
  • Argumentation view example 27 Design Issue Architecture Decision Design Alternatives Plain text Unsecure! Simple Stakeholder Positions HTTPS WS-Security Compatibility issues Heavyweight Account Access Security Web Services Security Mechanism Practice proven Plain text
  • Position and alternative life cycle 28 No positions
  • Position and alternative life cycle 29 No positions Aligned Positions
  • Position and alternative life cycle 30 No positions Aligned Positions Colliding Positions
  • Position and alternative life cycle 31 No positions Sealed Aligned Positions Colliding Positions
  • Position and alternative life cycle 32 No positions Sealed Inconclusive positions Conclusive positions Aligned Positions Colliding Positions
  • Design Issue life-cycle 33 No Alternatives Inconclusive Choice Incomplete Choice Conclusive Choice Warring Choice No Decisions
  • Design Issue life-cycle 34 No Alternatives Inconclusive Choice Complete choice Incomplete Choice Conclusive Choice Warring Choice No Decisions
  • Design Issue life-cycle 35 No Alternatives Inconclusive Choice Complete choice Incomplete Choice Conclusive Choice Warring Choice No Decisions Plain text HTTPS WS-Security Account Access Security Web Services Security Mechanism HTTPS
  • Design Issue life-cycle Plain text HTTPS WS-Security Account Access Security Web Services Security Mechanism HTTPS No Alternatives Inconclusive Choice Complete choice Incomplete Choice Conclusive Choice Warring Choice No Decisions 36
  • Design Issue life-cycle Plain text HTTPS WS-Security Account Access Security Web Services Security Mechanism HTTPS No Alternatives Inconclusive Choice Complete choice Incomplete Choice Conclusive Choice Warring Choice No Decisions 37
  • Design Issue life-cycle 38 Plain text HTTPS WS-Security Account Access Security Web Services Security Mechanism HTTPS No Alternatives Inconclusive Choice Complete choice Incomplete Choice Conclusive Choice Warring Choice No Decisions 38
  • Design Issue life-cycle Plain text HTTPS WS-Security Account Access Security Web Services Security Mechanism HTTPS No Alternatives Inconclusive Choice Complete choice Incomplete Choice Conclusive Choice Warring Choice No Decisions 39
  • Software Architecture Warehouse 40
  • Formative Evaluation 41 • User-centric design • 2 yearly iterations (with students of “Software Architecture and Design” master course) • 50+ co-located design workshops • 5-10 participants • 146 issues • 401 alternatives • 694 positions 41
  • Formative Evaluation Findings 42 • Connectivity • Position volatility • Decision space dynamics vary greatly • Need for decision process framing (sealing, time-boxing) • Lack of collective attention focus • Multimodality of the decision discussion 42
  • Position revoking 43 43
  • Team re-focusing 44 44
  • Team re-focusing 45 45
  • Constraining decision-process 46 46
  • Constraining decision-process 47 47
  • Summary 48 • Documenting decision making process is as important as documenting decisions itself • There is a lot to learn about how software architects make decisions (as a group) 48
  • Road ahead 49 • Decision metrics (in particular complex, graph metrics) • Detection strategies (patterns and anti-patterns) • Decision guidance models 49 Perception Comprehension Projection
  • Team Situational Awareness and Architectural Decision Making with the Software Architecture Warehouse Marcin Nowak and Cesare Pautasso marcin.nowak@usi.ch, c.pautasso@ieee.org Faculty of Informatics, University of Lugano, Switzerland Public software architecture warehouse demo: http://demo.saw.sonyx.net http://saw.inf.unisi.ch