1. Software systems are large and complex with many dependencies between code entities. Visualizing these dependencies can help developers better understand the system. 2. As software evolves over time, it becomes more complex and difficult to maintain due to increasing changes and dependencies. Analyzing data from a software project's history can provide insights into how the system has evolved and where problems may occur. 3. Analyzing data like source code, bugs, tasks, and emails can help identify trends like whether fragmented contributions from many developers are correlated with more post-release failures, helping prioritize testing and maintenance efforts.

1. The Knowledgeable
Software Engineer
Univ.-Prof. Dr. Martin Pinzger
Professor of Software Engineering
Software Engineering Research Group
University of Klagenfurt

2. Classical software systems
2

3. Mobile applications (apps)
3

4. The oven in your kitchen
4

5. In your car
5
Software is everywhere!

6. Software systems are large
6
How many lines of code?
10 MLOC = 4 meters

7. Software systems are complex
7

8. 1. Challenge: Understanding software systems
8
Martin
?
Andreas
?

9. Perspective of software developers
9
Perspective of the user

10. Perspective of software developers
10
Difficult to spot and comprehend
dependencies

11. A solution: software visualization
11
NbBundleTest
testExistingR.()
testNonE.()
main()
NbBundle
getMessage()

12. Software visualization challenge
12

13. DA4Java - Dependency Analysis for Java
13
Nested graph
Nodes present source code entities
Edges present dependencies between
them
Incrementally add/filter info
Add/filter dependent entities
Integrated with Eclipse IDE
Works for Java
Install from: http://serg.aau.at/bin/view/MartinPinzger/DA4Java

14. Install from: http://serg.aau.at/bin/view/MartinPinzger/DA4Java

15. Initial evaluation of DA4Java
In my reengineering course (TU Delft)
40-50 master students analyzing a Java system (150 KLOC)
Pros/cons
+ DA4Java reduces clutter/information overload
+ Good input for discussing dependencies
- Performance, graph can still get very complex
Todo
Add information about changes
User studies to evaluate the approach
Use the approach in different domains
15

16. Applying the idea to Spreadsheets
16

17. 17
50% form the basis for decisions
Spreadsheets are business critical
Errors often lead to financial loss
see: http://www.eusprig.org/horror-stories.htm

18. Interviewed 27 prof. spreadsheet users
18
What annoys you?
What makes you happy?

19. 19
Support for understanding is missing
How are the different worksheets related? (44%)
Where do formulas refer to? (38%)
What cells are meant for input? (22%)
What cells contain output? (22%)

20. Adapting DA4Java to Breviz

21. 21
1. Cell classification

22. 2. Identifying data blocks
22

23. 3. Data flow construction
23
C4 D4
E4
AVERAGE
C5 D5
E5
AVERAGE

24. 4. Name replacement
24
exam Richard Griffin lab Richard Griffin
overall Richard Griffin
AVERAGE

25. End Result
5. Grouping
25
exam Richard Griffin lab Richard Griffin
overall Richard Griffin
AVERAGE

26. Breviz - Global View
26

27. Breviz - Formula View
27

28. Evaluation with spreadsheet users
Interviews with 27 users
Case studies with 9 spreadsheets

29. Spreadsheet #Worksheets #Cells #Formulas
Shares risk management 9 29,671 221
Top and bottom 5 stock performance 5 2,781 1,601
Weekly report 16 9,555 7,215
Overview of portfolio data 42 28,222 13,096
Gain and loss of all trades for one week 10 503,050 38,188
Constructing a stock portfolio 6 16,054 16,659
Industrial spreadsheets

30. 30
Results
Does the visualization help to understand large, complex
spreadsheets?
Answers
“This really helps me to understand what [worksheet] is what.”
“The global view reveals the idea (design) behind the spreadsheet.”
“The different levels allow to show and filter details.”
Whats more ...?

31. Upload your spreadsheet at: http://app.infotron.nl

32. 32
Software systems evolve

33. Lehman’s Laws of software evolution
1. Continuing change
A program that is used in a real-world environment must change
2. Increasing complexity
As a program evolves, it becomes more complex
33

34. Growth and changes to Mozilla source code
341998

35. Lehman’s Laws in practice
Quick fixes
Lack of time, resources, money, etc.
Initial good design is not maintained
Spaghetti code, copy/paste programming, dependencies are introduced, no
tests, etc.
Documentation is not updated (if there is one)
Architecture and design documents
Original developers leave and with them their knowledge
35

36. Implications of Lehman’s Laws
36
Maintenance
75%
Initial development
25%
Maintenance costs increase
60% is spent on understanding
Number of bugs increase

37. 2. Challenge: Evolving software systems
37
Martin
?
Andreas
?

38. A solution: Business intelligence for SE
38
Source
Code
Bugs
Tasks
Emails
Knowledge
Repository
Data Mining
What is the effect of the new developer
on productivity?
What are the effects of the source code
changes on the design?
Where will bugs occur?
Where is this bug located?

39. Study with Microsoft
Released in January, 2007
> 4 years of development
Several thousand developers
Several thousand binaries (*.exe, *.dll)
Several millions of commits
39
RQ: Is fragmentation of contributions related
with the number of post-release failures?

40. Approach
40
Change
Logs
Bugs Regression
Analysis
Measuring
Contributions
Count post-release
failure reports

41. Developer contributions
41
Steve
Printer.dll
System.dll
Bill
Change Logs Build System

42. Developer contribution network
42
Alice
Bob
Dan
Eric
Fu
Go
Hin
ab
c
Windows binary (*.dll)
Developer
Which binary is failure-prone?

43. Network centrality measures
43
Alice
Bob
Dan
Eric
Fu
Go
Hin
ab
c
Freeman degree
Alice
Bob
Dan
Eric
Fu
Go
Hin
ab
c
Alice
Bob
Dan
Eric
Fu
Go
Hin
ab
c
Bonacich’s powerCloseness
Alice
Bob
Dan
Eric
Fu
Go
Hin
ab
c

44. Maxima over 4,000 binaries
44
Maximum
#Commits 48,112.000
#Authors 466.000
Power 562.093
Closeness 43.299
Reach 0.473
Betweenness 1.182

45. Research hypotheses
45
Binaries with fragmented contributions are failure-prone
Larger fragmentation correlates with more post-release failures

46. Predicting failure-prone binaries
46
Binary logistic regression of 50 random splits
4 principal components from 7 centrality measures
40200
1.00
0.90
0.80
0.70
0.60
0.50
40200
1.00
0.90
0.80
0.70
0.60
0.50
40200
1.00
0.90
0.80
0.70
0.60
0.50
Precision Recall AUC

47. Larger fragmentation - more failures
47
40200
1.00
0.90
0.80
0.70
0.60
0.50
40200
1.00
0.90
0.80
0.70
0.60
0.50
40200
1.00
0.90
0.80
0.70
0.60
0.50
R-Square Pearson Spearman
Linear regression of 50 random splits
#Failures = b0 + b1*Closeness + b2*#Authors + b3*#Commits

48. Summary of results
48
Centrality measures to predict 83% of failure-pone Vista binaries
Closeness, #Authors, and #Commits to predict the number of post-
release failures

49. What can we learn from that?
Increase testing effort for central binaries? - yes
Redesign central binaries? - maybe
Restrict contributions? - maybe
49
Alice
Bob
Dan
Eric
Fu
Go
Hin
ab
c
5
4
6
2 4
6
2
5 7
4

50. The knowledgeable software engineer
50
Martin Andreas
Knowledge
Repository
martin.pinzger@aau.at http://serg.aau.at