Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Investigating Software Engineering Artifacts in...

Investigating Software Engineering Artifacts in DevOps Through the Lens of Boundary Objects

Slides for the talk on "Investigating Software Engineering Artifacts in DevOps Through the Lens of Boundary Objects" at the International Conference on Evaluation and Assessment in Software Engineering (EASE) conference 2023.

https://conf.researchr.org/details/ease-2023/ease-2023-research/2/Investigating-Software-Engineering-Artifacts-in-DevOps-Through-the-Lens-of-Boundary-O

Christoph Matthies, Robert Heinrich, and Rebekka Wohlrab. 2023. "Investigating Software Engineering Artifacts in DevOps Through the Lens of Boundary Objects". In Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering (EASE '23). Association for Computing Machinery, New York, NY, USA, 12–21. https://doi.org/10.1145/3593434.3593441

Christoph Matthies

June 12, 2023
Tweet

More Decks by Christoph Matthies

Other Decks in Research

Transcript

  1. Hasso Plattner Institute, University of Potsdam, Germany [email protected] @chrisma0 Investigating

    Software Engineering Artifacts in DevOps Through the Lens of Boundary Objects Christoph Matthies, Robert Heinrich, Rebekka Wohlrab June 2023 Oulu https://conf.researchr.org/home/ease-2023
  2. Boundary Objects 2 A theory from sociology applied to engineering

    organizations “ [...] have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable, a means of translation [SG89] ” [SG89] S. L. Star & J. R. Griesemer. 1989. Institutional Ecology, “Translations and Boundary Objects: Amateurs and Professionals in Berkeley's Museum of Vertebrate Zoology”, 1907-39. Social Studies of Science 19, 3 (aug 1989), 387–420
  3. Methodology ▪ Exploratory multiple case study [Eas+08] □ 9 study

    sites, 12 interviews with industry practitioners □ Median 9.5 years of work experience 4 [Eas+08] S. Easterbrook, J. Singer, M.-A. Storey & D. Damian. 2008. “Selecting empirical methods for software engineering research”. In Guide to advanced empirical software engineering. 285–311. 1. Collaboration practices, coordination of dev and ops roles, significance of engineering artifacts 2. Introduction of Boundary Object concept 3. Reflection on concept in daily work ▪ Semi-Structured Interviews
  4. Research Questions RQ1 Categories of artifacts employed as Boundary Objects?

    6 Areas of inquiry within the research paper RQ2 Which stakeholders are involved? RQ3 Where do practitioners see concerns? RQ4 What attributes influence Boundary Object relevance?
  5. Research Questions RQ1 Categories of artifacts employed as Boundary Objects?

    7 Presented in this talk RQ4 What attributes influence Boundary Object relevance?
  6. DevOps Boundary Objects 9 Examples of Boundary Objects identified by

    study participants Dev. Ops. ▪ Sprint Backlog Entry ▪ Pseudo-Code ▪ Metrics Dashboard ▪ Software Log File ▪ Wiki Page ▪ Code Review Comment ▪ Checklists with steps ▪ Operations Runbooks
  7. Attributes of Boundary Objects 10 Seven attributes that influenced perceptions

    of relevance DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level of Automation Structured- ness Lifespan Number of Stakeholders
  8. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level

    of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 11 Relative to other objects in a given context, how frequent are updates? DevOps Boundary Objects Frequency of Change ▪ Notifications on updates ▪ Obtained info outdated quickly ▪ “a map might be a good Boundary Object because its speed of change is manageable” [Interview K]
  9. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level

    of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 12 How many connections to other engineering artifacts are there? DevOps Boundary Objects Connected- ness ▪ Higher degree of detail without duplication ▪ Higher effort to fully explore knowledge ▪ Maintenance of links
  10. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level

    of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 13 To what degree will the performance degrade if the object is unavailable? DevOps Boundary Objects Criticality ▪ Described by “how many people can’t work” ▪ Consequences of inadequate/missing quality (legal reqs): “They will literally send you to jail” [Interview K]
  11. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level

    of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 14 How much repeated manual effort is required to update the object? ▪ Automate as much as possible (in theory, less in practice) ▪ “If communication is ad-hoc, it is slow, get rid of it and automate” [Interview F] ▪ Monitoring and alerting of stakeholders DevOps Boundary Objects Level of Automation
  12. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level

    of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 15 To what degree does the object follow set standards? ▪ Highly dependent on context ▪ Reports via email vs. Jira task management ▪ Structure enables faster understanding DevOps Boundary Objects Structured- ness
  13. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level

    of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 16 When is the object created and for how long is it relevant? ▪ May be used only for a specific development phase ▪ Archived or set as read-only ▪ May require data only available later, e.g. metrics dashboards DevOps Boundary Objects Lifespan
  14. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level

    of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 17 How many stakeholders derive value from the object during its lifespan? ▪ Includes non-technical roles e.g. Product Management ▪ “If a microservice is to be monetized, the marketing team must interact” [Interview E] DevOps Boundary Objects Number of Stakeholders
  15. Conclusion 18 ▪ Previously identified Boundary Objects present in DevOps

    contexts □ E.g. checklists in medicine or software security [Gil+03] □ No single central coordination objects ▪ Starting points for collaboration and connecting stakeholders [Gil+03] D.P. Gilliam, T.L. Wolfe, J.S. Sherif, and M. Bishop. 2003. “Software Security Checklist for the Software Life Cycle”. In Twelfth IEEE International Workshops on Enabling Technologies (WET 2003). 243–248.
  16. Conclusion 19 ▪ Object attributes inform knowledge management □ E.g.

    Object with two stakeholders, low criticality, and lacking automation → might not be worth maintenance overhead ▪ “management of the data generated by the [DevOps] toolchain is still undervalued” [Col+21] in practice [Col+21] A. Colantoni, A. Garmendia, L. Berardinelli, M. Wimmer, and J. Brauer. 2021. “Leveraging Model-Driven Technologies for JSON Artefacts”. In 24th Int. Conference on Model Driven Engineering Languages and Systems. 250–260.
  17. Conclusion 20 “the more an agile team operates according to

    DevOps, the more it benefits from its artifacts [Fors+20] ” [Fors+20] M. Forsberg Lie, M. Sánchez-Gordón, and R. Colomo-Palacios. 2020. “DevOps in an ISO 13485 Regulated Environment”. In 14th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. 1–11. but the more it needs to consciously manage the Boundary Objects that facilitate collaboration
  18. Image Sources 22 In order of appearance ▪ area by

    Nithinan Tatah from Noun Project (CCBY3.0) ▪ Document by Liberus from Noun Project (CCBY3.0) ▪ Document by DinosoftLab from Noun Project (CCBY3.0) ▪ Definition by Eko Purnomo from Noun Project (CCBY3.0) ▪ explain by Iconographer from Noun Project (CCBY3.0) ▪ Hiking Map (hiking-map_926245) by sclance.com ▪ interview by Mutualism from Noun Project (CCBY3.0) ▪ Architectural Design software diagram by heinzhafner.de ▪ Question by Alzam from Noun Project (CCBY3.0) ▪ conclusion by WEBTECHOPS LLP from Noun Project (CCBY3.0)