Benevol 2013: Visualizing the complexity of software module upgrades
•Download as PPTX, PDF•
1 like•726 views
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Benevol 2013: Visualizing the complexity of software module upgrades
Similar to Benevol 2013: Visualizing the complexity of software module upgrades (20)
More from Alexander Serebrenik
More from Alexander Serebrenik (20)
Recently uploaded
Recently uploaded (20)
Benevol 2013: Visualizing the complexity of software module upgrades
- 1. Visualizing the Complexity of Software Module Upgrades Bram Schoenmakers, Niels van den Broek, Istvan Nagy, Bogdan Vasilescu, Alexander Serebrenik @bram85 @b_vasilescu @aserebrenik
- 2. … …
- 3. … …
- 5. Is the software easy to upgrade? Why does upgrading one module require upgrading many other modules?
- 6. Goal: Update A to the current version
- 7. Goal: Update A to the current version Solution 1 reduced the amount of code to be shipped to the customer Solution 2 reduces the amount of shipments
- 8. Goal: Update A to the current version Solution 1 reduced the amount of code to be shipped to the customer Solution 2 reduces the amount of shipments
- 9. Color = #modules needed to upgrade when upgrading row from column to current (8). AF, AL, AS, AY are easy to upgrade, AC is difficult. Why? Cliff between 2 and 3???
- 11. • • • • • 1000 software developers 40 MLOC 327 modules 7000 interfaces 9 monthly versions of the software • 327 modules * 8 version updates = 2616 upgrade scenarios – Search space: 8327-1 ~ 2.5 * 10294 configurations • Processing time: 16 hours for all scenarios October 15, 2013 – With limitations on search space. Slide 11
- 12. Cliff between 2 and 3 Inspecting upgrade dependency graphs, we’ve found many red dependencies, caused by symbol removal.
- 13. Cliff between 2 and 3 Inspecting upgrade dependency graphs, we’ve found many red dependencies, caused by symbol removal. Indeed, 9% ≤10 upgrade dependencies 45% 55% Red dependencies included >10 upgrade dependencies 91% Red dependencies excluded
- 14. Cliff between 2 and 3 Inspecting upgrade dependency graphs, we’ve found many red dependencies, caused by symbol removal. Suggestion: symbols are removed only when they are no longer used in any supported release.
- 15. Is the software easy to upgrade? Why does upgrading one module require upgrading many other modules?
Editor's Notes
- Manufacturer of chip-making equipment.Designs, develops and integratessystems to produce semiconductors.World’s largest memory company – SamsungWorld’s largest micorprocessor company - IntelWorld's largest foundry (made-to-order chipmaker) - TSMC.
- Blocks represent software. The idea is that ASML can ship only relevant blocks to the customer (e.g., the yellow ones), instead of the entire system. This idea can reduce the effort required to establish correctness of the configuration, install it and eventually recalibrate the system.
- However, modules depend on each other: here yellow relies on red and blue. Hence, when upgrading we need to take dependencies into account.
- However, modules depend on each other: here yellow relies on red and blue. Hence, when upgrading we need to take dependencies into account.
- A partial heatmap of the system is shown in Figure 2.We observe that the colors in a row become lighter fromleft to right, i.e., the older the version, the more upgradedependencies are involved. This can be expected because thetime span to the latest version is longer, suggesting that morechanges could have occurred. Moreover, most modules showdark cells in columns 0–2, and much lighter cells in columns3–7. This means that most modules are difficult to upgradeto the most recent version 8 if they are of version 2 or older.The heat map does not reveal the cause of this “cliff” fromversion 2 to version 3: we reconsider this issue in Section IV.Finally, module AF is easy to upgrade: its row is completelyblank, indicating that there are no upgrade dependencies. Thisis typical for modules which see little to no development. Itcould still be the case that this module has changed, but thatthese changes were internal to the module.
- Vertices: all modules involved with upgrade.Edge from module n1 to n2iffthere is an upgrade dependency from n1 to n2.Green edge: upgrade dependency due tosymbol addition(s).Red edge: upgrade dependency due tosymbol removal(s).Black edge: green and red combined.Thickness: number of symbols.