Hamburg, 2016-02-12 Stefan Wagner Research in the Software Engineering Group 

You can copy, share and change, film and photograph, blog, live-blog and tweet this presentation given that you attribute it to its author and respect the rights and licences of its parts. based on slides by @SMEasterbrook und @ethanwhite 

Tools Requirements Engineering Safety & Security Engineering Quality Engineering Software Engineering Continuous, Agile & Lean Engineering 

Requirements Engineering 

There are mostly isolated investigations of methods in requirements engineering research. 

Research is not driven by problems from industry. 

NaPiRE: Naming the Pain in Requirements Engineering Research questions and methods 1. What is the status quo in RE? 2. What is the status quo in RE process standards? 3. What is the status quo in RE improvement? 4. What contemporary problems exist in RE and how do they manifest themselves? 5. Are there observable patterns of expectations, status quo, and problems in RE? Bi-yearly World-wide 

Countries that conducted surveys in 2014/15 D. Méndez Fernández, S. Wagner, M. Kalinowski, M. Felderer, P. Mafra, A. Vetrò et al. Naming the pain in requirements engineering: Contemporary Problems, Causes, and Effects in Practice. Submited to Empirical Software Engineering. 

Formal/semi-formal goal models are rarely used in practice. Central Europe North/Eastern Europe North America South America 5 % 18 % 1 % 2 % 5 % 4 % 7 % 7 % Semi-formal Formal 

Causes for incomplete/hidden requirements 

Effects of incomplete/hidden requirements 

Quality Engineering 

Technische Universität München 

Class A Class B 

Class A Class B 

Class A Class B 

No content

Often 20%–30% redundancy 

Inconsistencies Can you spot the difference? 

How problematic are these inconsistencies? Indicating harmfulness [Lague97]: inconsistent evolution of clones in industrial telecom. SW. [Monden02]: higher revision number for files with clones in legacy SW. [Kim05]: substantial amount of coupled changes to code clones. [Li06], [SuChiu07] and [Aversano07], [Bakota07]: discovery of bugs through search for inconsistent clones or clone evolution analysis. Doubting harmfulness [Krinke07]: inconsistent clones hardly ever become consistent later. [Geiger06]: Failure to statistically verify impact of clones on change couplings [Lozano08]: Failure to statistically verify impact of clones on changeability. [Göde11]: Most changes intentionally inconsistent [Rahman12]: no statistically significant impacts on faults 

Industrial case study • Investigating evolution of type-3 clones • Relationship with documented faults from issue tracker • Industrial systems Accepted at SANER 2016 

Research questions RQ1: Do software systems contain type-3 clones? |CT3| / |C| RQ2: Do type-3 clones contain documented faults? |CT3 F| / |CT3| RQ3: Are developers aware of type-3 clones? |IMS| / |IM|, interviews with key developers Clone Groups C (exact and incons.) Inconsistent clone groups CT3 Faulty clone Groups CT3 F 

Data collection and analysis pport ditor HTML Dash- board v1 v2 v3 Extract Analyse Query for relationships and evolution Extract 

Study objects System Size (KLOC) Age (Years) Developers A 253 4 10 B 332 5 5 C 454 4 10 Java Automotive domain 

Quantitative results System A B C Overall Share of type-3 clones 0.56 0.23 0.79 0.52 Share of faulty clone type-3 classes 0.33 0.05 0.03 0.17 Share of simultaneously modified type-3 clones 0.58 0.89 0.92 0.85 

Qualitative results System A B C General clone awareness x No general clone awareness x x No specific clone awareness x x No clone check while bug fixing x x Clone warning while developing x Common code ownership x Discussion about co-changes x 

Conclusions • About half of all clone classes are type-3 clones. • Rate of faulty type-3 clones is about 17 %. • There is a difference in awareness of clones and inconsistencies. • This awareness seems to impact how many faults are related to type-3 clones. • Further studies should take this into account. • Making developers aware of clones seems still to be worthwhile. 

Safety & Security Engineering 

Verification of safety requirements based on system-theoretic analysis Abdulkhaleq, Wagner, Leveson. A Comprehensive Safety Engineering Approach for Software-Intensive Systems Based on STPA. Procedia Engineering 128:2–11, 2015 

Continuous, Agile & Lean Engineering 

Analyse the Scrum process to explore its industrial usage with respect to its variations from the perspective of practitioners. 

Some results • Some companies work with variations in the process just because they carry legacies from their old, non-agile process. • Allowing short discussions during the Daily Scrum was considered efficient by several companies. • The proposed sprint length is adhered to by most of the companies. 

Tools Requirements Engineering Safety & Security Engineering Quality Engineering Software Engineering Continuous, Agile & Lean Engineering 

e-mail phone +49 (0) 711 685- Twitter prof_wagnerst http://orcid.org/0000-0002-5256-8429 University of Stuttgart www.iste.uni-stuttgart.de/se/ Prof. Dr. Stefan Wagner 88455 Institute of Software Technology [email protected] Slides are available at www.stefan-wagner.biz. 

Pictures used in this slide deck Jan and Ivan by Stefan Wagner Clones by Nick Royer (https://flic.kr/p/d1DFPL) bad smell by Jeremy Tarling (https://flic.kr/p/gtS8xX)