Forschung und Lehre am Lehrstuhl Software Engineering

Vorstellung meines Lehrstuhls in der Ringvorlesung für den MSc Informatik an der Universität Stuttgart

Transcript

1. www.uni-stuttgart.de Forschung und Lehre am Lehrstuhl Software Engineering Prof. Dr. Stefan Wagner Institut für Softwaretechnologie @prof_wagnerst Wintersemester 2014/15
2. Sie dürfen diesen Vortrag kopieren, teilen und verändern, filmen und fotografieren, bloggen, live-bloggen und twittern unter der Voraussetzung, dass Sie ihn dem Autor zuordnen und die Rechte und Lizenzen der Teile respektieren. basiert auf Vorlagen von @SMEasterbrook und @ethanwhite
3. MSc Softwaretechik 1 Forschungs- methoden der Softwaretechnik Schlüsselquali- fikation Prozessanalyse Vertiefungslini e-SWT Requirements Engineering und Architektur Hauptseminar 1 2 Qualitätssicher- ung und Wartung Hauptseminar 2 Entwicklungs- projekt Vertiefungslini e-SWT Software- Recht
4. Software Engineering ist das systematische, disziplinierte und quantifizierbare Vorgehen zur Entwicklung, zum Betrieb und zur Wartung von Software, kurz: die Arbeit an Software nach Ingenieurprinzipien. IEEE-Std. 610
5. Tools Requirements Engineering Safety Engineering Quality Engineering Software Engineering Agile & Lean
6. Requirements Engineering
7. Notion of RE quality and its improvement Socio-economic context RE “Best Practice” Norm Goals,
 expectations, … 1. Solution orientation 
 (Also: “normative”, “prescriptive”) 2. Problem orientation
 (Also: “Inductive”) Paradigms (simplified) A A. Activity orientation B B. Artefact orientation Serves as Orientation Steer Assess/Benchmark RE reference model Adopt RE improvement principles
8. Quality Engineering
9. "Quality is a complex and multi-faceted concept... it is also the source of great confusion." –David A. Garvin
10. Class A Class B
11. Class A Class B
12. Class A Class B
14. Often 20%–30% redundancy
15. We need to detect and remove clones reliably and automatically.
16. Clone detection: Processing steps Storage load tokenise & normalise find duplicates extract clones visualise
17. Inconsistencies Can you spot the difference?
18. How problematic are these inconsistencies (and clones)? 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.
19. Limitations of previous studies • Indirect measures (e.g. stability of cloned vs. non-cloned code) used to determine effect of cloning are inaccurate • Analyzed systems are too small or omit industrial software Our Study • Manual inspection of inconsistent clones by system developers No indirect measures of consequences of cloning • Both industrial and open source software analyzed • Quantitative data Deissenboeck, Juergens, Hummel, Wagner, ICSE, 2009
20. Research Questions RQ1: Are clones changed inconsistently? |IC| / |C| RQ2: Are inconsistent clones created unintentionally? |UIC| / |IC| RQ3: Can inconsistent clones be indicators for faults in real systems? |F| / |IC|, |F| / |UIC| Clone Groups C (exact and incons.) Inconsistent clone groups IC Unintentionally incons. Clone Groups UIC Faulty clone Groups F
21. Study Design Tool detected clone group candidates CC Clone group candidate detection • Novel algorithm • Tailored to target program False positive removal • Manual inspection of all inconsistent and ¼ exact CCs • Performed by researchers Assessment of inconsistencies • All inconsistent clone groups inspected • Performed by developers Clone groups C (exact and incons.) Inconsistent clone groups IC Unintentionally inconsistent clone groups UIC Faulty clone groups F → CC → C, IC → UIC, F
22. Study Objects International reinsurance company, 37.000 employees Munich-based life-insurance company, 400 employees Sysiphus: Open source collaboration environment for distributed SW development. Developed at TUM. 281 8 Java TUM Sysiphus 197 17 Cobol LV 1871 D 495 2 C# Munich Re C 454 4 C# Munich Re B 317 6 C# Munich Re A Size (kLoC) Age (years) Language Organization System
23. Results Project A B C D Sys. Sum Clone groups |C| 286 160 326 352 303 1427 Inconsistent CGs |IC| 159 89 179 151 146 724 Unint. Incos. |UIC| 51 29 66 15 42 203 Faulty CGs |F| 19 18 42 5 23 107 Every second unintentional inconsistency constitutes a fault.
24. Functional Similarities • Not necessarily syntactically similar [1] Code Similarities Beyond Copy & Paste, E. Juergens, F. Deissenboeck, B. Hummel, CSMR 2010 • Type-4 clone: functionally similar code fragment regarding I/O behaviour • Cannot be found with clone detection [1]
25. General Idea • Execute candidate code fragments on random input • Compare output Type-4 Clones Source Code Libraries Detection Pipeline
26. Case Study: Study Objects System SLOC Commons Lang 17,504 Freemind 51,762 Jabref 74,586 Jetty 29,8 JHotDraw 78,902 “Info1“: Collection of 109 student implementations of an e- mail address validator (each 8..55 statements) [1] Deissenboeck, Heinemann, Hummel, Wagner, CSMR 2012
27. Discussion • Low results: no type-4 clones or flaws in detection? • Recall required; infeasible to determine manually • Main limitation: random testing approach –no input or generated input does achieve sufficient code coverage • Notion of I/O similarity may not be suitable –e.g different data types or signatures • Further research required to quantify these problems
28. Safety Engineering
29. Safety System Gefährdung
30. Systemtheorie und Sicherheit • Unfälle entstehen aus der Interaktion der Systemkomponenten untereinander und mit der Umwelt. • Sicherheit ist eine emergente Eigenschaft die in dieser Interaktion entsteht. • Sicherheit wird durch eine Menge an Einschränkungen für das Verhalten der Systemkomponenten geregelt.
31. Fallstudie: Cruise control
32. 58 1 STAMP
33. Werkzeugunterstützung
34. Agile & Lean
35. My Company Practices Agile yes no 16 84 Source: 7th Annual State of Agile Development Survey (2013) in % of respondents
36. Which Agile Methods Do You Use? Scrum Kanban Lean XP 7 11 15 40 in % of respondents Source: The State of Scrum (2013)
37. Cyber-physical systems (CPS) are physical and engineered systems whose operations are monitored, coordinated, controlled and integrated by a computing and communication core. Rajkumar et al. Picture: © Siemens
38. Agile system engineering practices have matured for software projects while hardware system engineering continues to embrace classical development techniques. Huang et a
39. So how can we use Scrum for building CPS?
40. Design Sprint Planning Design Sprint Backlog Product Backlog Hardware Sprint Planning Hardware Sprint Backlog Design Sprint Review Design Sprint Retrospective Potentially shippable software/ hardware design increment Potentially shippable product increment Hardware Sprint Review Hardware Sprint Retrospective e.g. Hardware NFA Design Sprint Execution Daily Scrum Daily Scrum Hardware Sprint Execution
41. Beispiel: Bachelorarbeit zu Variationen in Scrum in der Praxis
43. Tools Requirements Engineering Safety Engineering Quality Engineering Software Engineering Agile & Lean
44. Verwendete Bilder in diesem Foliensatz „Coding  Shots  Annual  Plan  high  res-­‐5“  by  Matthew  (WMF)  (http://commons.wikimedia.org/wiki/ File:Coding_Shots_Annual_Plan_high_res-­‐5.jpg)   „Complexity“  by  photo  fiddler  (https://flic.kr/p/aEvEx1)   „MAN  FE  360A  dump  truck  in  Munich“  (http://commons.wikimedia.org/wiki/ File:MAN_FE_360A_dump_truck.JPG)   „Simple-­‐kanban-­‐board“  by  Jeff.lasovski     (http://commons.wikimedia.org/wiki/File:Simple-­‐kanban-­‐board-­‐.jpg)