naveed-kamran-software-architecture-agile
0 likes655 views
This document summarizes a research paper that combines software structure analysis and revision history analysis to measure architecture quality and identify risks. The researchers conducted a case study on an agile project with 300,000 lines of code. They measured attributes of individual files and file pairs like size, dependencies, and change frequency. Exploration of the data revealed outlier files and distant change pairs that indicated architecture problems. Validation showed the measures could accurately predict faulty files. Investigating outliers uncovered key interface files with many faults violating intended encapsulation. The visual models and metrics helped prioritize restructuring tasks and justify architecture renovations.
naveed-kamran-software-architecture-agile
- 1. Measuring Architecture Quality by Structure Plus History Analysis Presented by Naveed Kamran naveed@datenc.com
- 2. About Authors • Robert Schwanke • Siemens Corporation, Corporate Technology • Princeton, New Jersey, USA • robert.schwanke@siemens.com • Lu Xiao, Yuanfang Cai • Computer Science Department, Drexel University • Philadelphia, Pennsylvania, USA • {lx52,yc349}@drexel.edu 2
- 3. Agenda • Terms used in Research Paper • Research Paper Details I. Motivation and Background II. Related Work III. Case Study Questions IV. Case Study Procedure V. Case Study and Results VI. Discussion of Results VII. Conclusion • Problems 3
- 4. Terms used in paper Fan-in • The number of modules that depend on a given module Fan Out • The number of modules that the given module depends on Correlation • A mutual relationship or connection between two or more things (for example modules/functions etc.). Outlier • A module or function situated away or detached from the main body or system. 4
- 5. Abstract • A case study paper • Combines • Known software structure analysis techniques • Known revision history analysis techniques • To predict bug-related change frequency, and uncover architecture- related risks in an agile industrial software development project. 5
- 6. (I). Motivation and Background • Architecture often receives inadequate attention, especially in agile software development • Only a few principles kept in the heads of developers • As small projects grow up, they tend to postpone both architecture specification and necessary restructuring • The experience of restructuring is hard to justify until there is a crisis. • Architectural concerns are debts • These debts tends to hurt future project sustainability much more than it does current functionality or quality • Development team needs ways to prioritize the backlog of restructuring tasks, selecting which ones to include in the architecture renovation plan • This is a case study of measuring architecture quality and identifying architecture issues by combining analyses of dependency structure and revision history 6
- 7. Is your business ready to scale changes in rapid manner? 7
- 8. (II). Related Work • Size Measures • Number of lines of code (LOC) • Number of non-commented lines of code (NCLOC) • Number of executable lines of code (ELOC) • Kilo-SLOC (Thousand Source/Software Lines of Code) (KSLOC) • Complexity Measures • Fan-In • Fan-Out • Change Measures • LOC added/deleted and number of sub systems affected • Effort and Impact Measures • Counting tasks, bug reports, file versions, change sets, or staff hours 8
- 9. Related Work (2) • Types of Changes • Bug/Task • Software Fault Prediction and Project Repositories • Which files will have faults in future • Prediction Performance • Correlation, accuracy, precision and recall • Correlation and Regression Analysis of Count Data • Architecture Violation Detection • Find dependencies that violate the architecture structure 9
- 10. (III). Case Study Questions 1. Does this combined structure/history measurement reveal critical architecture issues that are worth fixing? 2. Are there any structure-based measures that can be used to predict quality variation in the absence of adequate revision history data? 3. What measurements could help the developers make important architectural decisions, and how? 10
- 11. Developer Concerns • “What can I do with this information? There will always be some modules with high complexity, coupling, fanout, or size. What will I gain by reorganizing them? Why do I care if the code violates the architecture, as long as it works?” 11
- 12. (IV). Case study procedure • Data collection • Structure and history measurement • Validation • Prediction • Uncovering architecture problems • Presenting findings • Investigating developer concerns 12
- 13. (v). Case Study and Results (a) The project and its data • About Team • Team of 20 developers • About Project • Project name System J (code name) • Service oriented structure • 300 KSLOC in 900 files and 165 java packages • Development Methodology • Agile project development • Project manager is also the customer proxy • Sprints are usually two weeks long • Rebuild and automatically tested at least nightly • VCS • Mercurial • Bug and Tracking system • JIRA 13
- 15. Project Support Tool (BunnyCRM) 15
- 16. Case Study and Results (b) Measure of structure and history • Single-file measures 1. File size 2. Fan-in 3. Fan-out 4. Change frequency 5. Ticket Frequency 6. Bug Change Frequency • File pair measure 1. Pair Change Frequency 16
- 17. Case Study and Results (b) Measure of structure and history 17
- 18. Case Study and Results (b) Measure of structure and history 18
- 19. Case Study and Results (c) Exploratory data analysis • Distribution of each measure’s values • Scatter plots of relationships between measure • Comparing Releases 19
- 20. Case Study and Results (c) Exploratory data analysis - Distribution of each measure’s values 20
- 21. Case Study and Results (c) Exploratory data analysis - Scatter plots of relationships between measure 21
- 22. Case Study and Results (c) Exploratory data analysis - Comparing Releases 22
- 23. Case Study and Results (d) Validation on project data • Faulty file recall. An ‘instance’ is a file that is changed (in the future) at least once due to any bug ticket, but additional bug tickets and additional changes don’t count extra. • Fault recall. An ‘instance’ is a pair <file, bug ticket>,where the file is changed at least once due to that bug ticket. Additional changes due to the same ticket don’t count extra. • Fault impact recall. An ‘instance’ is a triple <file, change set, bug ticket>, where the file is a member of the change set and the change set is associated with the bug ticket. If a file is checked in several times due to the same bug ticket, each time is a separate instance. 23
- 24. Case Study and Results (d) Validation on project data 24
- 25. Case Study and Results (e) Uncovering architecture problems • Outlier Analysis – Individual Files • Lists the predicted fault-prone files “worst first”, sorting them according to the median of their ranks by fan-out, size, and change frequency. • Structure Browsing with Understand™ • A static code analysis tool called Understand™. It creates a database of code structure and crossreference information, processes queries on this information, and renders the results using Graphviz, a popular, free graph drawing engine • Using this tool, we would analyze a file by creating a diagram that included the file itself and all of its immediate neighbors in the cross-reference model, including the packages in which these files are located. Showing the enclosing packages provides guidance for analysts who are unfamiliar with some of the files. • Outlier Analysis – Pairs and Clusters • In addition to measuring individual files, we investigated the structure and history of pairs and clusters of files. • According to Parnas, the decomposition of a system should be based on mature, stable design decisions and should encapsulate known future variabilities, so that the impact of each kind of future change is as limited as practical. 25
- 26. Case Study and Results (f) Investigating a Developer Concern • A senior developer noticed that most of the fault-prone files belong to the same entry point package. • Authors used the layered dependency model to investigate and illustrate the problem. • The root cause was inadequate architecture awareness by junior developers. • The senior developer wrote a small renovation proposal, using this data and diagrams to justify the work of architecture changes. 26
- 27. (VI) Discussion of Results a) Answering the case study questions 1. Does this combined structure/history measurement reveal critical architecture issues that are worth fixing? • There are key interface files that are supposed to be stable and correct, but actually have faults and change frequently. • Frequent, distant change pairs often correspond to important architecture weaknesses or violations. • Structure gives us a visual context for analyzing change associations found in the history, discovering important, but undocumented shared assumptions that should be made explicit. 27
- 28. (VI) Discussion of Results a) Answering the case study questions • 2. Are there any structure-based measures that can be used, without history, to predict quality variation? • High fan-out, it should be examined for accidental complexity and architecture violations. Fan-in was not a good predictor of quality • High fan-in files did tend to be architecturally- significant infrastructure classes. 28
- 29. (VI) Discussion of Results a) Answering the case study questions • 3. What measurements could help the developers make important architectural decisions, and how? • Outlier Investigation was a good way to find low-hanging, bad smelling fruit. • Predicting fault-proneness helped to prioritize architecture risks. • Clustering distant change pairs seemed to bring together locality violations with the same root cause. 29
- 30. (VI) Discussion of Results • b) Visualizing structural concerns • Interactive, visual architecture models are essential for analyzing and communicating architecture issues. • C) Overcoming dirty data • Check correlations between change types, developer habits, and other measurable attributes, then tailor the prediction functions to account for them • d). Novelty and effectiveness • Approach is repeatable and on other projects using similar tools • e). Assumption and limitations • we only studied one project, and we cannot claim that the result can be generalized to other projects with different domains or using different tools or languages. 30
- 31. Conclusion • This case study reported measuring code structure and history to identify architecture problems in an industrial project. • It demonstrated the effectiveness of the combination by enabling developers to visualize the architectural roles and impact scope of files with high fault and change frequency, which justified and supported a successful renovation task. 31
- 32. Problems • They have not considered following types of changes: • Incident (A non producible defect) • Lead 32
- 33. Problems - Why release 1.05 and 1.0 skipped? 33
- 34. Problems (3) • The author of this paper self explained that • They considered only one project and a single business domain. Its not enough to be applied on all kinds of projects and business domains. • They have not use bug severity. A change in a file can be because of label change or a very minor cosmetic change in the user interface of application. But all kinds of bugs are treated with single severity 34
- 35. Thank you 35