UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A new change propagation metric to assess software evolvability Gonzalez, Marco A. 2013

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
24-ubc_2013_fall_gonzalez_marco.pdf [ 3.09MB ]
Metadata
JSON: 24-1.0073917.json
JSON-LD: 24-1.0073917-ld.json
RDF/XML (Pretty): 24-1.0073917-rdf.xml
RDF/JSON: 24-1.0073917-rdf.json
Turtle: 24-1.0073917-turtle.txt
N-Triples: 24-1.0073917-rdf-ntriples.txt
Original Record: 24-1.0073917-source.json
Full Text
24-1.0073917-fulltext.txt
Citation
24-1.0073917.ris

Full Text

  A NEW CHANGE PROPAGATION METRIC TO ASSESS SOFTWARE EVOLVABILITY  by Marco A Gonzalez  B.A.Sc., Instituto Tecnológico y de Estudios Superiores de Monterrey, 1998.  A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF  MASTER OF APPLIED SCIENCE  in The Faculty of Graduate Studies  (Electrical and Computer Engineering)  THE UNIVERSITY OF BRITISH COLUMBIA (Vancouver) June 2013  © Marco A Gonzalez, 2013   ii Abstract The development of software-intensive systems faces many challenges; one of the most important from an economic perspective is to reduce their maintenance costs. This thesis proposes a modified change propagation metric as a tool to assist the analysis of evolvability and maintainability of a software system and to ultimately support the reduction of its maintenance cost.  The technical complexity of software systems has a great impact on their ability to make increased functionality and adaptability to the environment possible. One approach to understand and master the complexity of large software systems, varying from thousands to millions of lines of source code, is through software architecture. This study examines a sample of software systems from the dependencies of their static structural view. The dependencies and their importance are expressed as a design structure matrix (DSM) that is used as an indicator to reflect the strength of dependence and connection among the different modules.  In this thesis, we propose a “modified change propagation” metric as a set of incremental improvements over the original Propagation Cost (PC) metric proposed by MacCormack (2008). Our improved metric uses dependencies weighted with strength to convey more information about the incidence of strongly connected relationships and it discounts weak dependencies. Moreover the original propagation metrics considered that the system should be acyclical; but we found that in practice a very few real systems are exempt of cycles. Furthermore, if cyclic dependencies are heavy rather than weak then these cycles should be treated differently. Finally, our metric is normalized to minimize the effect of both change in the total depth of the dependency graph, and increases in the size of the code.  Our modified change propagation metric can help software designers assess the maintainability of a software system at design time and over a proposed release sequence by comparing change propagation measures for different designs of software architecture. For instance, after refactoring. We validated our metric both on a system developed at UBC, and on several large open-source repositories for which we were able to obtain long release histories.   iii Preface All of the work presented hereafter was conducted in the Software Engineering and Architecture Laboratory, and at the Electrical Power and Energy Systems at the University of British Columbia, Point Grey campus.  Chapter 3 and 5 were written with the work done on (Nord 2012). The system analyzed was DR-NEP provided by the author, the analysis of the rework cost was done following the methodology provided by Nord R. and Ozkaya I. Philippe Kruchten coordinated the work. The work on (González-Rojas 2011) was used to implement the DR-NEP system supervised by Dr . DR-NEP was an project funded by Canarie for the Electrical Power and Energy Systems Lab under the supervision of Jose Marti.  For Chapter 5 and 7 were written based on the work from (Kruchten 2012). Kruchten provided guidance onto reviewing the matrix operations for a cost propagation metric.  I wrote the thesis and Dr. Philippe Kruchten provided guidance and revisions for the manuscript.     iv  Table of Contents Abstract................................................................................................................................. ii Preface ................................................................................................................................ iii Table of Contents ................................................................................................................. iv Acknowledgements ............................................................................................................. xii Dedication .......................................................................................................................... xiii 1 Introduction ................................................................................................................... 1  Background............................................................................................................ 1 1.1 1.1.1 Software Architecture ......................................................................................... 1 1.1.2 Software Evolution ............................................................................................. 2 1.1.3 Iterative and Incremental Development .............................................................. 2  Value of Software Architecture ............................................................................... 3 1.2 1.2.1 Software Architecture and Evolution. .................................................................. 3  Technical Debt ....................................................................................................... 4 1.3 1.3.1 Technical Debt at the Architecture Level ............................................................ 4 1.3.2 How to Prevent Technical Debt Originated from the Software Design ................ 5  Propagation Cost ................................................................................................... 6 1.4  Limitations of Propagation Cost ............................................................................. 7 1.5  Research Method .................................................................................................. 8 1.6  Structure of the Thesis ........................................................................................... 9 1.7 2 Related Work ...............................................................................................................10  Introduction ...........................................................................................................10 2.1   v  Software Evolution ................................................................................................10 2.2 2.2.1 Environment ......................................................................................................10 2.2.2 Evolution ...........................................................................................................11  Modularity .............................................................................................................12 2.3  Metrics ..................................................................................................................14 2.4 2.4.1 Granularity .........................................................................................................17  Value and Software Development .........................................................................17 2.5  Technical Debt ......................................................................................................18 2.6  Propagation Cost ..................................................................................................19 2.7 3 Approach Taken...........................................................................................................21  Introduction ...........................................................................................................21 3.1  Internal and External Module Dependencies .........................................................21 3.2  Analysis Tool ........................................................................................................22 3.3 3.3.1 Analysis Assumptions........................................................................................22 3.3.1.1 Dependency Strength Count ......................................................................23  Validation ..............................................................................................................24 3.4 3.4.1 In-House System ...............................................................................................25 3.4.2 Open-Source Systems ......................................................................................28 3.4.2.1 Hadoop ......................................................................................................28 3.4.2.2 PDFBox ......................................................................................................29 3.4.2.3 Ant .............................................................................................................30 3.4.2.4 Checkstyle..................................................................................................36 3.4.2.5 Detailed Analysis ........................................................................................37   Normalizing by Visibility Length 1...........................................................43 3.4.2.5.1   Adjustment in the Analysis of Checkstyle ...............................................44 3.4.2.5.2   vi  Similarities with other Metrics ..................................................................44 3.4.2.5.3  Sum Variant Breadth Sensitivity ............................................................................45 3.5 4 Deriving Value for Software Architecture from User-visible Concerns ..........................52  Introduction ...........................................................................................................52 4.1  Value for Invisible Elements in the Backlog ...........................................................53 4.2 4.2.1 Benefit for Architectural Elements......................................................................55  Mapping Benefit from Features to Architectural Elements .....................................56 4.3 4.3.1 Scheduling ........................................................................................................59 4.3.2 Implementation ..................................................................................................60  Conclusion ............................................................................................................65 4.4 5 Dealing with Dependency Strength ..............................................................................66  Introduction ...........................................................................................................66 5.1  Propagation Cost ..................................................................................................66 5.2 5.2.1 Limitation of Boolean Dependencies .................................................................67 5.2.2 Modified Dot Product .........................................................................................69 5.2.3 Parallel Operator   ..........................................................................................69  Change Propagation Analysis ...............................................................................70 5.3  Change Propagation Estimation Proposed Variants ..............................................71 5.4  Validating the 7 Variants .......................................................................................74 5.5 5.5.1 Case 1: Two Parallel Paths for the Same Destination........................................75 5.5.2 Case 2: Two Parallel Paths for Two Destinations ..............................................76 5.5.3 Case 3: Layered Structure with Multiple Parallel Paths Version 1 ......................79 5.5.4 Case 4: Layered Structure with Multiple Parallel Paths Version 2 ......................81  Normalization ........................................................................................................83 5.6   vii  Refactoring with Mediators (Brokers) ....................................................................85 5.7 5.7.1 Use All Structure 5 Elements 2 Layers ..............................................................85 5.7.2 Use All Structure 13 Elements Two Layers ........................................................86 5.7.3 Use All 5 Elements 2 Layers with Three Layers .................................................87 5.7.3.1 Mediators ...................................................................................................87  5 Elements 3 Layers One Mediator Structure .........................................87 5.7.3.1.1  13 Elements 3 Layers One Mediator .......................................................88 5.7.3.1.2  Conclusions ..........................................................................................................90 5.8 6 Addressing Cycles .......................................................................................................91  Introduction ...........................................................................................................91 6.1  Transitivity and Change Propagation ....................................................................91 6.2  Change Propagation Metric and Cycled Dependencies ........................................92 6.3 6.3.1 Matrix Powers and Propagation Visibility ...........................................................93 6.3.1.1 Indirect Dependencies ................................................................................93  Systems with Cyclical Dependencies ....................................................................96 6.4 6.4.1 Tactics to Address Cycles .................................................................................98 6.4.1.1 Change Propagation with Cycles ................................................................99 6.4.1.2 Ignoring Cycling Dependencies ..................................................................99 6.4.2 Limiting the Impact of Cycles ........................................................................... 100  Cycle Detection ................................................................................................... 103 6.5  Conclusions ........................................................................................................ 104 6.6 7 Dealing with the Depth of Propagation ....................................................................... 106  Introduction ......................................................................................................... 106 7.1  Propagation and Depth Estimation ...................................................................... 106 7.2   viii  Interdependency ................................................................................................. 109 7.3  Conclusion .......................................................................................................... 110 7.4 8 Conclusions ............................................................................................................... 111  Introduction ......................................................................................................... 111 8.1  Research Goals Summary .................................................................................. 111 8.2  Contributions ....................................................................................................... 113 8.3 8.3.1 Propagation Breadth and Depth ...................................................................... 114 8.3.2 Cycles ............................................................................................................. 116  Future Work ........................................................................................................ 116 8.4 8.4.1 Level of Analysis ............................................................................................. 116 8.4.2 Propagation Decrease for Path Length Increase ............................................. 117 8.4.3 Dependency Types ......................................................................................... 117 8.4.4 Internal Dependencies ..................................................................................... 118 8.4.5 Analysis per Release ....................................................................................... 118 8.4.6 Visibility ........................................................................................................... 119  Conclusion .......................................................................................................... 119 8.5 References ....................................................................................................................... 121   ix List of Tables Table 3-1 Gross change propagation, V, and normalized change propagation, V/n2 ...........42 Table 3-2 Checkstyle 2.0 change propagation per length ....................................................46 Table 3-3 MAX change propagation per path length for checkstyle-5.0, scaled by path length ...........................................................................................................................47 Table 3-4 SUM change propagation evolution per path leength for checkstyle-5.0, scaled by  ....................................................................................................................................48 Table 3-5 Divide by Length (DIVPOW) ................................................................................50 Table 3-6 Increase of change propagation for checkstyle 5.0 MAX vs SUM ........................51 Table 4-1 Architectural Element before mapping .................................................................62 Table 4-2 Feature after mapping .........................................................................................63 Table 4-3 Development element types prioritized for scheduling .........................................64 Table 5-1. Dot Product for system with two parallel paths ...................................................76 Table 5-2 Change propagation for variants .........................................................................76 Table 5-3 Parallels change propagation ..............................................................................78 Table 5-4 Parallels eliminated change propagation .............................................................78 Table 5-5 paths of length 2 (M2) and length 3 (M3) .............................................................80 Table 5-6 Change Propagation for ......................................................................................80 Table 5-7 Change propagation for symmetric and asymmetric systems ..............................82 Table 5-8 Symmetric and Asymmetric paths of length 3 ......................................................82   x List of Figures Figure 2-1 Technical Debt by McConnell ............................................................................................. 19 Figure 3-1 DRNEP Path #1 Deliver soon design structure matrix ....................................................... 26 Figure 3-2 DRNEP Path #2 Reduce rework design structure matrix ................................................... 27 Figure 3-3 Propagation cost and modified change propagation for DRNEP Paths #1 and #2 ............ 27 Figure 3-4 Hadoop sources lines of code, PC, and MCP (v/n^2) ........................................................ 29 Figure 3-5   PDFBox source lines of code, PC, and MCP (V/N2) ........................................................ 30 Figure 3-6 Sources lines of code versions and cycles for ANT 1.4.1 to 1.9.0 ..................................... 31 Figure 3-7 Visibility for ANT versions 1.4.1 to 1.9.0 for 2 nd  level in Figure 3-1 .................................... 33 Figure 3-8  Ant 1.8.4 expanded to 2nd level and taskdefs and types modules to 3rd level expansion  ..................................................................................................................................................... .34 Figure 3-9 Ant Change Propagation version 1.4.1 to 1.9.0 .................................................................. 35 Figure 3-10 Checkstyle SLOC, PC, MCP, and SBO from Bouwers .................................................... 37 Figure 3-11 Checkstyle propagation compared to SBO, CSU, CB ...................................................... 39 Figure 3-12 10x zoom for Visibility, V ................................................................................................... 40 Figure 3-13 5x zoom for Change propagation, V/n^2 .......................................................................... 41 Figure 3-14 Zoom for Change propagation, V/n^2 ............................................................................... 42 Figure 3-15 V divided by D 1 and compared vs V divided by n 2  ............................................................ 43 Figure 4-1 value system framework ..................................................................................................... 53 Figure 4-2 Mapping of features to architectural elements .................................................................... 57 Figure 4-3 Priority(value) estimated for Architectural Elements (yellow) ............................................. 62 Figure 4-4 Tasks assigned to iterations ............................................................................................... 64 Figure 5-1 Indirect dependency from A to C ........................................................................................ 69 Figure 5-2 Parallel Operator,   .......................................................................................................... 70 Figure 5-3 System with two parallel paths (strength to be divided by 10*) .......................................... 75 Figure 5-4 Four parallel paths .............................................................................................................. 77 Figure 5-5 Dot product for system with four parallel paths .................................................................. 77   xi Figure 5-6 Parallels eliminated ............................................................................................................. 78 Figure 5-7 Layered structure with multiple paths version 1 ................................................................. 79 Figure 5-8 Multiple paths asymmetric .................................................................................................. 81 Figure 5-9 Use All 5 elements 2 levels ................................................................................................. 85 Figure 5-10 Use 13 elements 2 layers ................................................................................................. 86 Figure 5-11 Use all 3 levels .................................................................................................................. 87 Figure 5-12 5 elements 3 layers one mediator structure ..................................................................... 88 Figure 5-13 13 elements, 3 layers, one mediator................................................................................. 89 Figure 6-1     a) Directed graph             b) Design structure matrix ...................................................... 92 Figure 6-2 Expanded dependencies transitive closure ........................................................................ 92 Figure 6-3 Paths of length 2 ................................................................................................................. 95 Figure 6-4 Cycles saturate at D 2  .......................................................................................................... 97 Figure 6-5 Dependency Structure Matrix with hierarchy ...................................................................... 99 Figure 6-6 System with cycles............................................................................................................ 101 Figure 6-7 Steps of cycled path.......................................................................................................... 101 Figure 6-8  Power 2 obtains all the paths of length 2 ......................................................................... 102 Figure 6-9. Power 3 obtains all paths of length 3 ............................................................................... 102 Figure 6-10. Power 4 obtains all paths of length 4 ............................................................................. 103 Figure 7-1 Propagation Depth ............................................................................................................ 106     xii  Acknowledgements    Thanks for Dr. Philippe Kruchten for his help and support during my research, I woul also like to thank to Dr. Jose R. Marti from the Electrical and Power Energy Systems Laboratory for his support and collaboration in the Disaster-Response Network Enabled Platform. Thanks to my friends Cesar E. Lopez Castellanos, Rui Ren. William Wang, Pranab Kini, Thanks to Cameron Dale, Effron Esseiva, Danuta Jaworski, and others from IBM for their support in the DRNEP project. Thanks to Ipek Ozkaya, Robert Nord, Julien Delange at the Software Engineering Institute at CMU. I want to thank NSERC for partially funding my research.  Thanks to my friends who helped me, especially Chris Campbell. Also thanks to Larix Lee, Mandana Sotoodeh, Steve Adolph, Erin Lim, and others at the Software Engineering and Architecture Laboratory. I also like to thank Neeraj Sangal at Lattix for his support.      xiii Dedication       Dedicated with love to:    to Sergio, Fernanda, Deya, Edgard, Martha, Ignacio, and my extended family in Vancouver.           1 1 Introduction  Software systems provide tools that benefit a wide range of human activities. However, the development of software systems face several challenges; one of the most important from the economic and technical perspective is to reduce its maintenance costs. This thesis proposes a modified change propagation metric as a vehicle to assist in the analysis of evolvability and to ultimately support in the reduction of maintenance costs.  Background 1.1 1.1.1 Software Architecture One approach to understand and master the complexity of large software systems is through software architecture. Software systems are complex products varying from thousands to millions of lines of source code, embodying implicit design decisions, internal and external constraints, different technical and non-technical concerns, etc. Software systems have different concerns depending on the environment they interact with, and this presents an engineering and management challenge. Software architecture is a relatively new discipline that aims to understand the properties, elements, relationships, and environment of a software system. Software architecture provides guidelines and practices to elicit the goals and properties and to reason about the design decisions that will produce a system aimed at fulfilling these properties and the intended functionality. Software architecture also provides guidelines on how to analyze the tradeoffs among the properties of a system, and non-monetary estimation of the benefits and costs of the properties of a software system in an abstract way. The software architecture of a software system can be seen as the set of all abstract and implemented design decisions, the   2 elements that conform a system, and the relationships that determine the properties of a system (ISO/42010 2011). 1.1.2 Software Evolution A software system is subject to interactions and pressures that force it to evolve; this phenomenon is referred as software evolution. A software system is a subsystem that interacts with other subsystems in an environment that conforms a broader dynamic system that will change and force the software subsystem to be adapted. For instance, cross-domain systems that involve a social context constantly adapt to changes derived from the dynamic social component. External changes force the software system to be modified, and after a number of adaptations the initially correct designed software architecture will successively accumulate a mismatch between its structure and the present conditions in the environment. This mismatch in most of the times is solved by mappings and other modifications in the software system, which increases the size and complexity of the system. Therefore, the maintenance cost increases over time and a redesign is needed to evolve the structure to avoid increasing mismatch that provokes decay in a system. 1.1.3 Iterative and Incremental Development Software development professionals had improved delivery time and a reduced cost by developing iteratively and incrementally. The previous waterfall development model proposed to sequentially execute the requirements specification, design, construction, validation and maintenance phases. This produced a high rate of failed projects due to discrepancies and errors but mainly because of miscommunication in each of the phases of the waterfall model. Iterative development divides an entire development project in several part or iterations each with a requirement, design, construct and validation phases. This division allowed to construct   3 part of the requirements which also enabled to validate not only the design and construction, but also to receive feedback and more importantly improve the requirements specification which in some cases accounts for more than 50% of the errors and mismatches (McConnell 2006; Apache 2002). Iterative development has also allowed to incrementally deliver a system by partial releases, allowing software development organizations to increase the quality and reduce costs.  Value of Software Architecture 1.2 While software professionals agree that software design has a value it is difficult to demonstrate that the architecture design has value for a particular system. Considering value as the ratio of benefit to cost, in software development most of the cost is directly related with the effort assigned to tasks; this is similar for software architecture analysis and design. However, the benefits are difficult to make explicit since they manifest in the medium and long term or in properties that are not directly identifiable. While there are economic approaches for software architecture properties (Ozkaya 2007), there is the need to determine a value for the software architecture design. 1.2.1 Software Architecture and Evolution. Software Architecture is an important tool to elicit and reason about the evolution of a software system. And this is important since some software development professionals mention  cost of software maintenance to be around 40 to 80% of the total software development life-cycle cost (Glass 2003; McConnell 2006). In addition, because evolving a system without considering architecture design will cause the system to accumulate more mismatches. These discrepancies might not be appreciated as relevant in a given point in time but that will have an impact later. That led to the formulation of the question:   4 RQ1. Can a value be estimated for software architecture? Could a heuristic be assigned for software architecture value?  Technical Debt 1.3 Technical debt is a metaphor introduced by (Cunningham 1992) to refer to the pending and accumulating amount work that needs to be done because of a suboptimal code implementations made to deliver functionality in to fit into a tight deadline or decisions. The work that needs to be done has similar consequences to the interests in financial debt; the more time it passes without correcting the suboptimal code implementation, the more work needs to be done to correct it in the future. Technical debt also reduces the software development productivity to a point where  it can increase the cost per functional unit and increase complexity, as McConnell (2007) mentions. 1.3.1 Technical Debt at the Architecture Level Technical or design debt at the architectural level can be understood as a metaphor to refer to the pending amount of design and implementation effort to solve the mismatch between the software architecture design of a system and the evolving conditions. It is important to distinguish the technical debt, which is the product of design decisions from code implementation debt from the fact that design decisions were taken consciously. Technical debt at the design level produces larger amounts of debt that individual code debts. Additionally, debt bearing design decisions might have been taken to satisfy a restriction, to embody a strategy, or because at that point in time and context that decision was judged adequate (Nord 2012).   5 1.3.2 How to Prevent Technical Debt Originated from the Software Design Ideally one way on how to prevent a design technical debt is to analyze at which point in time a suboptimal decision should be replaced by an optimal decision. In order to do this the value for design decisions in a system should be known and this is presents challenge. Some design decisions that produce technical debt were taken because the benefits were perceived minimal when compared to the costs in a particular point in time. However, optimal design decisions have more value in the medium and long term than the suboptimal decisions. Many design decisions are based on experience and subjective judgments, since there are no quantitative measures to give decisions a value. Therefore, the resolution on whether to implement suboptimal decisions or at which point in time to change from suboptimal to optimal decisions is left to the intuition. One approach could be to assign a strength, or weight, to the expected benefits and costs to design decisions. However, benefits are difficult to quantify because these are abstract properties of the system and some of them are visible in the medium and long term. Nonetheless, some of the benefits manifest as a reduction of complexity and ultimately as a reduction of cost. Also, software development professionals have more experience estimating costs and therefore associating as product of a design decision. Design decisions can be associated with organizational strategies that result in software architecture with an evolutionary path.  Therefore, there is the possibility to associate the evolution of a software architecture and cost. This leads to the formulation of the next question:  RQ2. Can a metric be defined to compare the cost of different evolution paths for a software system?   6  Propagation Cost 1.4 MacCormack (2008) proposed propagation cost as a metric to analyze how change potentially affects the structure and also as an indicator for the effort needed to evolve a system. In order to calculate the propagation cost of a system its components relationships structure is initially expressed as a design structure matrix, D, in order to determine how closely coupled or decoupled the components in a system are. The indirect dependencies among all the components are obtained by deriving the transitive closure of a system or visibility matrix, V. The propagation cost metric is the density of the direct and indirect dependencies of the system in the visibility matrix. These dependencies are used to obtain an indicator of how a change affects the rest of the system, the higher the change spreads through the system a higher propagation cost will produce. Ideally, systems that are well design and therefore decoupled should produce a lower propagation cost. However, this study found some inconsistencies and limitations.  MacCormack (2008) proposed propagation cost obtains cost propagation as a ratio of the transitivity of dependencies to all of the possible dependencies in a system. The transitive closure of a system is the propagation of the direct dependencies by making explicit all the indirect dependencies. This transitivity is estimated and expressed in a visibility matrix, V. In a system with n modules all the possible combinations are n2, therefore propagation cost is explained as: 1 1 2 n n j i Vij PC n          (1) 1 0 n i i V D         (2)   7  where Vij, is a given direct and/or indirect dependency between module i and module i. The direct dependencies can extracted by code dependency analysis tools. Static structure or code dependencies are used because they represent a good metric when refactoring the more dependencies are in modules the more possibilities there are for modifications in the dependent modules.  Limitations of Propagation Cost 1.5 Propagation cost (MacCormack 2008) allowed the calculation derived from the software structure to be considered as an indicator of sensibility to change and necessary effort to evolve in a binary fashion. For this reason, propagation cost has the following limitations or opportunity for improvement:  D1. Propagation costs models dependencies with binary values, 1 to denote that a dependency exists and 0 to denote no dependency. This assumes that all dependencies in the system are of the same type; however in a system there will be dependencies from a subset of components to others what will exert a great influence, while in other subset will be of little or relatively no consequence.  D2. When a change affects the system it is also supposed that it will affect all of the components in the same proportion. While there are some changes that are localized in only one or a subset of components; having changes that affect all elements is less probable. Propagation cost does not capture this information. There is the need for another structure, or vector, to capture the probability of change for the elements in the system.    8 D3. Propagation cost might not give a good result when dealing when increasing the number of components in the system. Propagation cost results in a reduced estimation due to the division of the visibility by the square of the number of elements in the system. Propagation cost decreases non-linearly when more components are added.  D4. Many systems have dependency cycles, which would cause propagation cost to give an incorrect and saturated result. Propagation cost uses the visibility concept (Sharman and Yassine 2004) which is developed upon the matrix powers (Warfield 1973). If there is a cycle in the system that is all connected this will produce the final product to saturate. A different algorithm or equation that takes into account cycles is needed.  These limitations give raise to the following research question:  RQ2.1. Could propagation cost be modified to address its limitations and become an improved metric?  Research Method 1.6 The approach taken was to review relevant work done regarding software evolution, software architecture design and technical debt. Some ideas about software architecture and its value where induced. The concept of deriving value for software architecture from visible features was explored. Propagation Cost (MacCormack 2008) a metric used to indicate how susceptible a system is to change is examined. Limitations to this metric were found the following solutions are proposed:  Characterizing dependencies with a strength  Proposing depth propagation variants for the estimation   9  Analyzing and limiting the effect of cycles The solutions are tested with:  Small artificial and representative examples of systems structure   Large open-source systems for which different versions are accessible  A system developed in-house  Structure of the Thesis 1.7 The next chapters explore how the change propagation metric was derived. Chapter 2 has a review of the relevant subjects on software evolution, architecture, and technical debt and others. Secondly, the research method, the tools and representations are described in Chapter 3. In Chapter 4 an approach to derive value for architecture the benefit from user-visible features and is used to determine the value of architectural elements and its limitation is commented. In Chapter 5, characterizing dependencies with a strength rather than a binary descriptor is analyzed. Afterwards, in Chapter 6 the issue of dependency cycles is analyzed and a solution is proposed. In chapter 7 the depth of the propagation metric is analyzed and observations are made. In Chapter 8 a better metric for propagation is proposed. Finally, in Chapter 9 summarizes and concludes the research.           10 2 Related Work  Introduction 2.1 This section presents previous work regarding software context and value. The topics reviewed are software evolution, software design, software architecture, technical debt and propagation cost. These topics cover the environment of software development, its evolvable properties, how software design is a user-invisible but empowering or constraining factor in the evolution.  Software Evolution 2.2 2.2.1 Environment Manny Lehman (1980) made an important contribution by making explicit the complexity of the environment and mentioning that a software system is a part of a real-world solution. Many software systems interact with other real-world systems often of dynamic nature. In addition, software systems are the product of several abstractions from a real-world problem. First, there is an abstraction or view of a real-world problem by the human observer, then the requirements and design phases are another abstraction exercises in order to adequate the real-world abstraction into a software-development abstraction. When transforming a real-world problem and its solution into a software view. The problems-solution is modeled to different concerns software views as the views proposed by Kruchten (1995). A software system as a product is the result of several views or transformations from real-world and these tacit transformations must be considered in order to understand the nature of a software system and its maintenance and evolution.   11 2.2.2 Evolution Lehman (1980) pointed out in his influential work on software evolution that all systems are subject to “continuing change”. For instance, software systems interact in a social context, which are dynamical and continually evolve. Dynamical systems force software to change frequently and adapt to this change. This adaptation is important to separate from the addition of functionality or features, systems will be subject to change in the hypothetical case their functionality remained static. Incremental increase in complexity could eventually cause decay in a software system if organizations do not allocate effort for redesign.  Another effect is the increase in complexity, Lehman (1980) mentions that as environment changes the conditions for a software system change as well. This change requires the architecture of a system to adapt as well. However, most of the times, additional code between the architecture and the internal system compensates the discrepancies if no architecture redesign effort is done. Furthermore, additional functionalities or modifications also cause an increase in size and complexity that add on top of the architecture discrepancy compensating code. The accumulating complexity and architecture discrepancy cause a software system to decay in the long-term period.  Baldwin and Clark (2000) connected the concepts of software evolution and modularity. The software industry referred to the concept of modularity in the mid 1960’s because of the interest in reuse among others. Modularity was used to refer to independent and exchangeable modules in different families of systems while reducing the required for adaptation. The authors also refer to software structure or architecture when considering evolution, since the complex structures that comprise systems are made of simple ones and the architecture of the whole system can be referred as a fundamental structure (Garlan and Shaw 1994). In the work of Baldwin and   12 Clark (2000) software design, modularity, and software structures or architecture are highly related; software systems evolution is compared to organic evolution. The authors mention that in biological evolution the selection units are genes or the characteristics of an organism contained in its set of genes. The authors point out that the selection criteria in biology is fitness to the environment and for software systesms this criteria can be market value among others.  Modularity  2.3 Baldwin and Clark (2000) suggested that modularity received special attention in the 1960’s when the software industry intended to reduce costs and time to deliver by reusing software. In the past software development organizations faced the problem that despite delivering very similar products each product would have similar cost and required time to produce as when developing a new system. This was due in part because of understandability and changing involved modifying several parts of the system that consume significant effort.  Modularization is an organizational technique that allows dividing a system into components, while recombining and reusing these modules. In the field of software development modularization also allows to reduce system complexity, leading to development that is more efficient and a greater capacity for adaptation. This enables reducing cost and time to deliver as well. Another characteristic of modularity is the division and allocation of work and responsibilities to teams that mirrors how designers decide how a system should coordinate to perform tasks. This partitioning of a system into modules implies detail hiding, because design decisions within a module are the responsibility of the module. As such, only the inputs and outputs are visible at the modules interface: the “how” is hidden inside the module. This hiding of details also reduces the complexity and the required amount of work from collaborating modules.   13  Parnas (1972) suggested that in modularizing systems and to achieve the modularization benefits the “criteria” for modularizing needed to strongly consider detail hiding. Detail hiding allows modules to abstract tasks, to have a relative independence and can be decoupled from the system. Accordingly, Baldwin and Clark (2000) refer to modularity as a concept that involves independence outside modules and dependence inside the modules. Hiding details reduces the interaction complexity among modules as well as decreasing technical dependencies among modules, which entails that design decisions made by designers are also hidden. This is important because since modularity has been a desired characteristic some modularizations fail to produce reusable parts and even to reduce complexity; because sometimes modularization is done exchanging  technical details.  Dijkstra (1968) argues in his influential paper on the structure of software that modularization should also involve a structure composed of hierarchies organized to be sequentially more and more abstract such that all possible design considerations are mostly covered at a reasonable degree. In the same direction Parnas (1979) proposed modularizing with a hierarchical structure that will allow a system to have different reusable parts of the system that could be used by a family of similar programs that could be “extended” or “reduced” in functionality. Similarly, Baldwin and Clark (2000) point out that modularity involves a hierarchy. Parnas (1979) observed that in order to produce a “better structure” it is necessary to identify minimal subsets, and implement them in minimal steps something that hints at developing in as an incremental and iterative process. Nord (2013) states that “in order to understand complex systems that are nearly divisible hierarchical structures is a major facilitating factor enabling to understand, describe and even to visualize the system and the parts that form it. If there are important   14 systems in the world that are complex without being hierarchic, they may to a considerable extent escape our observation and understanding”.  Parnas (1979) also refers to software structural design as providing stability through the life cycle. This structural stability enables the increase, decrease, or change of functionality according to the conditions of the environment without increasing the complexity, thus reducing cost and increasing value. Koziolek (2011) identifies this concept as sustainability. Benefits can increase when a software structure, or part of it, can be reused (extended or used partially) in another systems serving as a basis for future evolution. Parnas (1979) refers to the division of the system, or modularization, and the associated “uses” hierarchy in the design as “the major milestone” in the project.  Metrics 2.4 Metrics provide traceability, meaning that the result can be corroborated if repeated at different times if the conditions have not altered the characteristic to be measured. A metric is a way to provide quantification by comparing versus a convened invariable unit of measure. This serves the purpose of comparing over time one characteristic or physical dimension. In the case of software it has metrics over the amount of code which are representations of set of tasks and information. Software development professionals had been using metrics of observable characteristics of software in order to communicate its complexity and other characteristics. A very common metric is source lines of code (SLOC).  Metrics have been developed to measure how well a system is modularized and employ techniques such as dependency graphs, extract related measures from code, object oriented metrics, etc. Koziolek (2011) provides a comprehensive classification of metrics for   15 sustainability; with a particular focus on evolution and focused to prevent system’s decay and allow expansion of its “life-time”. Lakos (1996) uses the sum of dependencies at the element level and obtains densities using the number of elements in a module. Mancoridis et al. (1999) propose a modularity quality metric in which external (inter-connectivity) is subtracted from averaged internal (i.e. intra-connectivity) binary dependency densities inside automatically clustered modules. The intra and inter connectivity are densities of the dependencies.  Intra- connectivity is the sum of binary dependencies within a given subset of modules divided by the square number of components, similar to densification in propagation cost formula (MacCormack 2008). For the inter-connectivity measures the outside coupling that divides the sum of binary dependencies among the number of possible connections among the modules in a pair of subsets defined as 2n1n2.  Sethi et al. (2009) obtained two metrics for stability and modularity called decision volatility and independence level respectively. For stability, or decision volatility, the intent of the software system and the environment are expressed in terms of design decision, i.e. dimensions, and the “environmental constraints”, respectively. This is referred to as an augmented constraint network and from these declarations, a design structure matrix is derived. From this matrix the software stability metrics are calculated based on assumptions about the coupling. This is similar to adding the binary dependencies that a module consumes in a DSM as in of fan-in and fan-out metrics from MacCormack (2004). Modularity is measured by an “independence level” metric which quantifies the extent to which modules are independent of each other. This is accomplished by an algorithm which identifies the modules that are independent. In the example from the metric is the result of the percentage of independent elements from all the modules in the system.    16 Liu et al. (2008)  report that the average propagation ratio and network diameters (or path length as referred in this thesis) reduces as the number of edges increases for direct dependencies. This may be attributed to a lack of depth in the dependencies connection or to coupling and propagation. In addition, reachable nodes Rik at distance k take into account the node itself and all of the previous “visited” nodes;  increasing the values of averaged propagation cost (PCk). In this thesis the PC does not take into account the node itself and at every PCk or Di in formula (1) it only considers the modules to which dependency propagation has not been propagated before.  Milev, Muegge, and Weiss (2009) propose a new modularity metric based by a clustering cost algorithm. The clustered algorithm “collapses” or creates a cluster of modules in an attempt to reduce the propagation. However, their conclusions do not always corroborate with the expected results. It is important to point out that they compare propagation cost (MacCormack 2008) and relative clustered cost, with some results coinciding and others differing. Relative clustered costs assign strengths to internal module dependencies which are smaller than those assigned to external dependencies. Relative clustered cost also assigns a smaller strength to the elements (classes) that provide dependencies to a large percentage of elements in the system (hubs), which the authors set as 10 percent in this case.  Agrawal (2009) proposes to use two metrics of modularity for a general product: degree and bridge modularity. It is important to note that in degree modularity the relative strength of dependencies is quantified rather than assigned a binary value. Degree modularity attempts to measure the extent to which a component is connected to the rest of the product components; both by the dependencies it consumes and by the dependencies it provides to the rest of the system. Bridge modularity claims to measure the extent to which a component stands between   17 the rest of the components in the system. In a hierarchical structure such as that of software it is unclear how useful this metric is because most components are needed in order to make a system work and the elements in the middle of the structure could be as equally important as the rest. 2.4.1 Granularity In accordance with Laval (2011), this research analyzes systems at the package level, since packages can be considered as granular units of reuse and deployment. The studies conducted by (Sosa 2008) also suggest that analyzing systems at the top levels of the hierarchy is fruitful for obtaining a measures of a system’s architectural evolution. In contrast, Lakos (1996), Milev, Muegge, and Weiss (2009) and others, use the atomic artifacts of a system like classes or files that reside within modules. Moreover, Agrawal (2009) divides dependencies as internal and external to the module. Some researchers use object-oriented metrics at the file level; Lakos (1996) is an example of using internal module metrics to indicate how coupled elements are.  Value and Software Development 2.5 In this section I present a sample of representative proponents considering value as an integral consideration for software engineering is mentioned. Boehm (2003) suggests the importance that software decisions have on the software development process and ultimately in the degree of fulfilment from objectives of the system. For this reason, the author proposes changing from the previous neutral-value into a value-based software engineering mindset. The author proposes to understand the benefits, values for an organization and from these to understand the goals of the system through a “shared vision” from the development team and the stakeholders. In order to realize the goals of a system Boehm proposes “concurrent system and software engineering” as one of the foundations of value-based software engineering.   18 Concurrent system and software engineering includes value-based architecting, in which the systems objectives (e.g. RUP(Kruchten 2003) life cycle objectives), the architecture objectives and the implemented architecture are managed. The shared vision is briefly the understanding of the customer benefits, stakeholders’ propositions which helps software professionals to understand the context and the value for a given end-use organization. Agile methods proponents cite as one of the main tenets of these methodologies to deliver value to the client, Cockburn (2001) proposes to incrementally evolve software architecture –or  “rearchitecture” as Cockburn refers to this strategy.  Denne (2004) introduces the “Incremental Method Funding” in which he also addresses the stress of dedicating some effort to designing a system vs. delivering functionality immediately without a proper or minimal design. Denne points out that while there might be time and funding constraints still a part of the infrastructure could be constructed incrementally based on iterative development and the management of the releases. In a commercial context delivering parts of the system functionality can also give the chance to implement subsets of some parts of the software architecture. Releasing incrementally can also reduce the upfront cost of implementing the entire architecture.  Technical Debt 2.6 Technical debt is mentioned first by Cunningham (1992) and compared to incurring in a financial debt with the aim to develop and deliver fast, but he emphasizes that it should be paid promptly. Technical debt is a metaphor to the increase of software development effort for a functional unit, features or maintenance as referred as equivalent to financial debt (Cunningham 1992) as a result of suboptimal implementations. The more time it passes before the debt is paid the more interests will accumulate in the form of more changes in the system that requires effort and   19 consequently a cost. McConnell (2007) classifies technical as intentional and unintentional. McConnell suggests that intentional debt is product of a strategy that considers the present development cost more expensive than the cost in the future. McConnell also notes that development organizations incur in this type of debt in what he termed “big chunks” to differentiate it from debt that is taken unconsciously, in smaller proportions. Managing architectural debt is better than several pieces of small debt that is spread through the system and that is taken unconsciously and is more visible. The most common cause for incurring in architectural technical debt are directed towards reducing time deliver, uncertainty, limited resources, etc. Architectural design decisions also cause technical debt in what McConnell classifies as “identifiable” individual shortcuts. For instance, a company might have reduce time to market as part of a strategy to be the first team to offer a given software to increase the probability of increasing its market share and creating captive users. Type I Unintentional Type II Intentional (Strategic)   A. Short-term reactive paid off, frequently   B. Long-term proactive Figure 2-1 Technical Debt by McConnell  Propagation Cost  2.7 Steward (1981) proposed to express module dependencies for a system in the form of a matrix called design structure matrix (DSM). Doing this allows to visualize how much dependencies came in and out of a system. Design structure matrices had been used in several fields of engineering to determine the criticality of given modules or subsystems, especially in the manufacturing, supply chain and other disciplines.    20 Using strengths to describe dependencies in contrast to Boolean descriptors in a design structure matrix, as proposed by MacCormack (2008), allows to capture more information that differentiates and qualifies the relationships among module. For instance, in systems there are modules with weak dependencies to some other modules; while other modules provide the majority of the dependencies. Therefore, supporting modules that provide a more significant proportion of the code dependencies play a more critical role when modifications are made to them: the dispersion of a change could potentially affect more elements than the elements providing weaker strength dependencies.  The goal of propagation cost (MacCormack 2008) is to measure the potential impact of changes, estimated by equation (2):  1 1 2 n n j i Vij PC n     (2)  1 0 i n i V D     (3)  by adding up all the directly and indirectly influenced elements  in the visibility matrix, V (3). The visibility matrix contains all of the Boolean indirect and direct dependencies and its estimation is explained in Chapter 5. Propagation cost divides the total propagation or transitive dependencies and obtains normalization by dividing the total by the number the number of all possible dependencies in a system with n elements, which is n2.   21 3 Approach Taken  Introduction 3.1 This section explains the approach we took to validate modified change propagation metric with open source software systems. In order to validate the use of strength dependencies descriptors we obtained these data from real systems to perform our estimations. Dependencies were extracted from the compiled code of software systems, we explain the tools used and how was the change propagation obtained from this dependency data. This chapter also covers which types of systems were used and other considerations in our study.  Internal and External Module Dependencies 3.2 Some authors, e.g. Lakos (1996) Milev, Muegge, and Weiss (2009), Agrawal (2009), etc., consider the internal and external module dependencies as metrics for modularity. This study considers that both types of dependencies should be analyzed separately and focuses only on the analysis of external module dependencies. While one of the aims of module design is module independence, still dependencies are needed to integrate the module with the system. External module dependencies are common in commercial software and a low coupling or low number of dependencies are convenient to support reuse and maintenance, which leads to time-to-deliver, reduction of maintenance and development costs. Some proposed modularity metrics consider internal and external module dependencies together. For instance, Agrawal (2009) considers internal and external dependencies to be the same. Other researchers such as (Mancoridis et al. 1999) work on the basis that internal cohesion is desirable while considering that external coupling should be minimized. Accordingly, they estimate modularity as a function of internal dependencies minus a function of external module dependencies. Software   22 engineering professionals, e.g. (Fowler 2001) have applied this  principle to reduce coupling while others (Mancoridis et al. 1999) consider internal dependencies to be a good characteristic. This thesis considers that internal and external dependencies as separate concerns for measuring modularity.  A high number of external dependencies between modules while allowing for reuse present constraints to software evolution that require effort and cost to overcome. It is also true that the dependencies that allow for reuse, should be the result of abstraction, information hiding, and enforcing “minimality” in interfaces (Lakos 1996). When these guidelines are not followed or when despite following them, the number of dependencies increase the complexity and cost for a given system increase as well.  Analysis Tool 3.3 Lattix LDM (Sangal et al. 2005) was used to extract the dependencies and structure of the systems analyzed. This tool identifies the hierarchy using algorithms, which is important for dealing with software systems when their hierarchies and software architecture are unknown. A useful feature of Lattix LDM is that it allows expressing the dependencies as a design structure matrix, and it provides an interface to interact with the matrix. This is useful because data does not need to be exported to other tools in order to calculate the change propagation metric. The selection of Lattix LDM was based on recommendations made by Sosa (2008). 3.3.1 Analysis Assumptions There are several ways to describe dependencies: Laval (2011) classifies dependencies by type, such as by inherits, implementing an interface, referencing values, and by the calling of methods. In this thesis all the dependencies are considered as of one type for the sake of   23 simplicity. It can be argued that the inheritance dependency should be in function of the code metrics of the inherited classes and thus being of a greater strength than other types of dependencies such as a simple reference to a value or an invocation to a simple method. However, some method invocations might allow for reuse to a considerable extent placing the dependency as of a greater strength. Therefore, it is difficult to determine which of the dependencies should weight more and analyses of the reference and its scope might be needed to determine the strength of per type of dependencies. For the previous reasons and for the sake of simplicity in this study all dependencies are considered as of the same type. 3.3.1.1 Dependency Strength Count The static analysis tool Lattix LDM determines dependency strength or in three ways, by knowledge-based, by knowledge-based subsystem and usage-based dependency strength. Dependency strength by knowledge counts n references to an outside class as one reference to determine strength, independently of how many times references are made within a class inside a module. The intent of this thesis is to get a metric for change propagation; for that matter all the times a dependency to given an external class appears inside a module are counted to determine the dependency strength, for this purpose we use the usage-based dependency strength. This is because while maintaining or refactoring a system a change in a module can cause compile or run-time errors or a change in the functionality inside and outside the modules. This study is concerned with the change outside a module mainly because the changes within a module can be done by the developer(s) assigned to a given module and the changes might be contained by the information hiding implemented in the design. However, changes in the other modules, for nontrivial projects might require the coordination with other workers or separate teams which entails effort, time and cost. For that reason, we are more concerned with determining strength by counting all the used references to external modules.   24  Validation 3.4 This section explains the steps used to validate the metric. First, this study used small test cases of structures to corroborate that change propagation metric obtained consistent results with empirical practices in software engineering. In order to validate the change propagation metric non-trivial examples were used; generally-speaking, projects with more than 6 months of lifespan and more than 3 developers. For this purpose, an in-house software system and four open source projects from the Apache Software Foundation (Apache 2002) were analyzed. Some of these open source systems have been used by several software development organizations for 10 years of and have what is referred to by software development professionals as a stable architecture (Sosa 2008), meaning that at a certain point they do not change drastically. We found that change propagation is a good indicator for analyzing increases in dependency complexity.  These small test cases were used to illustrate how the dependencies propagated along software systems, variations of layered, and mediator structures where used. For instance, a mediator resembles at a high-level the structure of service-oriented architectures, whereas the layered structure is the de facto hierarchical organization for many software systems. The results of these test cases is covered in Chapter 5 (Kruchten 2012, Nord 2013). We also used the Divide by Propagation Length variant for the change propagation metric because of the distance denominator that reflects the distance between layers in the hierarchy.  The change propagation metric at second layer of the structure produced the most significant results. A software system structure has different layers in its structure; for instance, Hadoop had up to 5 layers and Ant up to 6 layers. Considering the first layer to comprehend the entire analyzed system we obtained the most significant measures at the second layer. In some   25 cases, the second and third layers would have the same behavior, and at some points, they would have disproportionate effects due to the amplification of indirect dependencies when the number of elements in that layer increased. We considered that architectural analysis should comprehend the fundamental relationships, and for that reason we decided to limit the number of elements between 10 and 20 modules. 3.4.1 In-House System An in-house system, the Disaster Response Network Platform (DRNEP) (González-Rojas 2011; Marti et al. 2012) developed by the Electric Power  Group of UBC for disaster-response simulation management was used. DRNEP was developed in order to allow collaboration among organizations with knowledge in different simulation domain areas and knowledge on disaster response in order to provide research and preparedness services to organizations around the world. This would allow to integrate simulators of different infrastructure domains and integrate their results by an interdependencies simulator (Martí et al. 2008). For instance, one implementation (Cunha et al. 2011) included a water distribution network simulator (Rossman 2000), a human decision disaster and procedure policies simulator. The DRNEP project integrated simulators that run on diverse platforms and was developed with different programming languages.  In order to compare two different strategies or evolutionary paths for the design of DRNEP, path #1 “deliver soon” and path #2 “reduce rework” were compared. We used the t-shirt size approach to characterize the strengths of the dependencies since there were no software artifacts at design time. The t-shirt size strengths are:  1=strong       0.5= medium      0.1=weak   26 For the deliver soon strategy we consider that no integration applications frameworks are going to be used, the design decision will be that for every interaction between any two simulators an adapter for each simulator will be used and a translator will be developed. This approach is good for delivering fast results in the first iterations.  Figure 3-1 DRNEP Path #1 Deliver soon design structure matrix This design requires that when more simulators are added into the DRNEP system the more translators are going to be needed. This is a combination of n elements in groups of 2, which results in ( 1) 2 n n translator which is a problem of order О(n2). Another approach is to use the well-known mediator pattern, in this case all the models representations have to be converted into the DRNEP canonical data model for simulation collaboration (González-Rojas 2011). The design in the next figure.  PATH 1 DELIVER SOON Co nt ro lle r I2 Si m Ad ap te r M TA da pt er M T_ I2 Si m _T ra ns l EP AN et Ad ap te r Ep a_ I2 Si m _T ra ns l Ep a_ M T_ Tr an sl Br ah m sA da pt er Br ah m s_ I2 Si m _T ra ns l Br ah m s_ M T_ Tr an sl Br ah m s_ EP AN et _T ra ns l Fl oo dA da pt er Fl oo d_ I2 Si m _T ra ns l Fl oo d_ M T_ Tr an sl Fl oo d_ EP AN et _T ra ns l Fl oo d_ Br ah m s_ Tr an sl Da ta  P er sis te nc e 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Cost Controller 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 16 I2SimAdapter 2 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 MTAdapter 3 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 MT_I2Sim_Transl 4 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 8 EPANetAdapter 5 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 3 Epa_I2Sim_Transl 7 0 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 8 Epa_MT_Transl 6 0 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 8 BrahmsAdapter 8 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 3 Brahms_I2Sim_Transl 9 0 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 8 Brahms_MT_Transl 10 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 0 0 8 Brahms_EPANet_Transl 11 0 0 0 0 1 0 0 1 0 0 1 0 0 0 0 0 0 8 FloodAdapter 12 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 3 Flood_I2Sim_Transl 13 0 1 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 8 Flood_MT_Transl 14 0 0 1 0 0 0 0 0 0 0 0 1 0 1 0 0 0 8 Flood_EPANet_Transl 15 0 0 0 0 1 0 0 0 0 0 0 1 0 0 1 0 0 8 Flood_Brahms_Transl 16 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 1 0 8 Data Persistence 17 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 5 Total 116   27  Figure 3-2 DRNEP Path #2 Reduce rework design structure matrix Intuitively the Path#2 should give a smaller propagation due to the use of the mediator pattern, in order to measure the propagation metrics we run the propagation cost (MacCormack 2008) and the modified change propagation metrics. The results are shown in Figure 3-3. It can be appreciated that the propagation cost was higher for Path #2 which is counter intuitively. For the modified change propagation the result corroborates empirical practices in software design.  Figure 3-3 Propagation cost and modified change propagation for DRNEP Paths #1 and #2 I2 si m M T Ep a B ra h Fl o o d W eb W A S C o n tr o lle r Se rv ic e Se rv ic eB u si n es s Si m u la to rS er vi ce C lie n t En ti ti es C o m m o n 1 2 3 4 5 6 7 8 9 10 11 12 13 Cost I2SimService 1 1 0 0 0 0 0 0 0 0 0 0 0 0 7 MTService 2 0 1 0 0 0 0 0 0 0 0 0 0 0 9 EPAService 3 0 0 1 0 0 0 0 0 0 0 0 0 0 9 BrahmsService 4 0 0 0 1 0 0 0 0 0 0 0 0 0 9 FloodSimServ 5 0 0 0 0 1 0 0 0 0 0 0 0 0 9 DrNepWeb 6 0 0 0 0 0 1 0 0 0 0 0 0 0 3 DrNepServiceWASClient 7 0.1 0.1 0.1 0.1 0.1 1 1 0 0 0 0 0 0 8 Controller 8 0 0 0 0 0 0 0 1 0 0 0 0 0 8 DrNepService 9 0 0 0 0 0 0 0 0 1 0 0 0 0 6 DrNepServiceBusiness 10 0 0 0 0 0 0 0 0 0.1 1 0 0 0 5 SimulatorServiceClient 11 0 0 0 0 0 0 0 0 0 0.1 1 0 0 8 DrNepEntities 12 0 0 0 0 0 0 0 0 ? 0.5 0 1 0 11 DrNepCommon 13 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0 1 2 Total 94   28 3.4.2 Open-Source Systems Several versions of open-source systems were used to perform validation because of the widespread use of the software systems and especially because some of them have been used for abound 10 years. This allows examining the evolution in time of their software architecture for systems that are widely used by software development organizations as well as end-users. 3.4.2.1 Hadoop Hadoop (Borthakur 2007) is an open source project from the Apache Software Foundation (Apache 2002) for distributed processing. Hadoop is a highly fault-tolerant distributed file system for processing large data sets in a cluster computing environment. Several organizations use Hadoop, for instance Adobe, eBay, Facebook, Fox Audience network, Google, etc. (Apache 2013). Hadoop delivers high-availability by detecting and handling faults.  The results obtained in Figure 3-4 show that the propagation cost is different from change propagation estimations. In some cases propagation cost does not identify and in some other systems it has an opposite result. For instance, in Hadoop versions 0.18.0 to 0.19.0. propagation cost does not detect any difference, despite changes in the hierarchy where two modules are introduced, hdfs, http, and module dfs is removed. The configuration of versions 0.18.0 and 0.19.0 changed; however, because of the cycles the propagation cost estimates for the most part a saturated visibility matrix. Also, For versions 1.0.4 and 1.1.2 propagation cost shows similar estimation whereas the modified change propagation calculates an increase.   29  Figure 3-4 Hadoop sources lines of code, PC, and MCP (v/n^2) 3.4.2.2 PDFBox PDFBox is an open source project from the Apache Software Foundation (Apache 2002) for viewing and editing PDF documents. The propagation cost and the modified change propagation are similar; however there is a decrease in change propagation metric that   30 propagation cost does not identify in version 1.5.0. Also, change propagation detects a slight variation from versions 1.7.0 to version 1.7.1 whereas propagation cost detects a reduction.  Figure 3-5   PDFBox source lines of code, PC, and MCP (V/N2)  3.4.2.3 Ant Ant is an open source project from the Apache Software Foundation (Apache 2002) for building applications from source code into an executable and distributable application. We can see in Figure 3-6 that propagation cost (MacCormack 2008) estimates sometimes are coincident, other   31 times the differ, and sometimes opposite as those of the modified change propagation metric (V/n^2 DIV_POW) in label A, versions 1.5.4 to 1.6.0. Propagation cost estimates a decrease whereas change propagation calculates a decrease. From release 1.8.0 to 1.8.1, identified in Figure 3-6 with label B, opposite estimates from propagation cost and modified change propagation metrics can be seen.  Figure 3-6 Sources lines of code versions and cycles for ANT 1.4.1 to 1.9.0 A B   32 We found that for most of the Ant versions there is an increase for both; size of the systems, measured in source lines of code, and the modified change propagation. However, a decrease of 0.3 percent in the dependencies from version 1.8.1 to 1.8.2 also causes a reduction of 4.32 percent in the modified change propagation. The modified change propagation metric also found that there is a difference in the estimation result when done with the a) cycle elimination and b) cycle limitation calculation for ANT versions 1.8.1 to 1.9.0.  a) number of modules (at second level)    33  b) Visibility                                   c) Modified change propagation Figure 3-7 Visibility for ANT versions 1.4.1 to 1.9.0 for 2 nd  level in Figure 3-1 In Figure 3-7 the SUM and the Divide by Propagation Length variants (see section 5.4) are shown with the Ignore and the Limit cycle treatment approaches (see section 6.4.1) We also calculated the modified change propagation for some modules that contained more dependencies inside them as rest of the others. This implied to expand some modules which resulted in increasing the number of modules in the design structure matrix. We observed that the for the cycle elimination, or ignoring cycles, calculation the increase in our proposed modified change propagation is around 50 to 2100 percent. This is due to the increase of parallel and series operations, especially for the parallel which adds the result of propagated dependencies. This leads to question why do the modified change propagation result differ so much depending on the granularity of the analysis; however, it is my opinion that this is because architectural and atomically object metrics differ in their concerns. The intent of clustering atoms in layers or packages is to isolate, to hide information from other element. However, for large systems, the   34   a) 2 nd  level  3 rd  level Figure 3-8  Ant 1.8.4 expanded to 2nd level and taskdefs and types modules to 3rd level expansion The results for the change propagation metric for Ant with modules taskdefs and types to the third level are shown in Figure 3-6. Ant 1.8.4 .lis te n e r .h e lp e r .ta s k d e fs .d is p a tc h .in p u t .filte rs .p ro p e rty .lo a d e r .u til .ty p e s .* g 1 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 64 2 485 1 3 28 6098 5 6 8 35 44 4 5 7 2 5 25 36 10 6 77 541 16 69 7 16 6 30 24 8 9 16 26 995 5 47 491 266 143 10 19 5006 121 2 327 2892 158 11 82 416 4221 34 22 78 35 6 329 922 1949 12 12 7 227 79 708 .loader .util .types .* org.apache.ant.utils .listener .helper .taskdefs .dispatch .input .filters .property lis te n e r h e lp e r ta s k d e fs .c v s lib ta s k d e fs .o p tio n a l ta s k d e fs .c o m p ile rs ta s k d e fs .rm ic ta s k d e fs .* ta s k d e fs .c o n d itio n ta s k d e fs .e m a il d is p a tc h in p u t filte rs p ro p e rty lo a d e r u til ty p e s .s p i ty p e s .m a p p e rs ty p e s .o p tio n a l ty p e s .s e le c to rs ty p e s .re s o u rc e s ty p e s .* * to o ls 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 0 2 1 2 2 2 3 1 64 2 485 1 3 109 4 1796 2 5 41 12 6 75 13 7 20 519 118 86 3034 14 5 1 5 21 42 8 11 3 54 94 6 7 1 7 1 2 9 28 3 2 92 10 5 7 2 11 25 36 10 12 77 541 16 8 4 7 50 13 16 6 30 24 14 15 16 26 36 290 19 7 599 37 7 5 47 491 3 59 58 64 82 143 16 7 10 17 18 16 19 86 5 2 3 290 9 51 99 20 9 19 438 8 4 2 79 22 456 47 9 21 10 5 1811 378 73 2105 52 15 119 2 246 2 33 189 599 1165 502 n d  le v e l 22 82 416 51 1266 59 40 2523 221 61 34 22 78 35 6 329 14 11 28 116 268 485 19492 n d  le v e l 23 12 7 200 12 15 62 17 708 e x p a n d e d  3 rd  le v e l e x p a n d e d  3 rd  le v e l listener helper dispatch input filters property loader * tools ty p e s types.spi types.mappers types.optional types.selectors types.resources types.* util taskdefs.rmic taskdefs.* taskdefs.condition taskdefs.email2 n d  le v e l Ant 1.8.4 expanded to 3rd 2 n d  le v e l ta s k d e fs taskdefs.cvslib taskdefs.optional taskdefs.compilers   35   Figure 3-9 Ant Change Propagation version 1.4.1 to 1.9.0    36 3.4.2.4 Checkstyle Checkstyle is an open source tool that helps to enforce coding standards, and this tool is highly configurable to perform similar checks. Other projects use checkstyle to enforce coding styles, to find some common class design problems; and to detect duplication of code and bug or anti- patterns. By reviewing the evolution of checkstyle our study found that there is an improvement measured by the decrease in the initial change propagation of the system. This is important since in some other systems the variation of change propagation closely resembles that of the increase in source lines of code (SLOC). In early releases, identified by the releases starting in label A prior to the release 3.0 in label B as illustrated by Figure 3-10, checkstyle has the smallest source code between 10 to 20 KSLOC’s. Despite Checkstyle source code being the smallest in the early releases, we measured the greatest change propagation with a peak in version 2.4 prior to event B. At event B we find a reduction in change propagation caused by a refactoring, development organizations decide to redesign the software architecture when complexity or cost to develop functional units increases non-linearly to overcome increasing cost. Reviewing the release notes of checkstyle 3.0 we find:  “Completely new architecture based around pluggable modules. This means that users can now write their own checks without changing the source code of checkstyle itself (request 578712).  Configuration is not based on Properties any more. Instead a Configuration interface is used …”  B   37  Figure 3-10 Checkstyle SLOC, PC, MCP, and SBO from Bouwers 3.4.2.5 Detailed Analysis In Figure 3-10 it can be observed that propagation cost (PC) and the modified cost propagation (MCP) have a similar trend but noted that there are some trends that are different, as indicated by the red circles. For instance, the changes from versions: a) 2.3 to 2.4, b) 3.1 to 3.2, c) 3.2 to 3.3 and d) 4.3 to 4.4 are different.  In release 3.1, located right after event B in Figure 3-11, we found a decrease in the change propagation, V/n^2. This is more clear in the Visibility matrix, V, in Figure 3-12, where it can be appreciated that there was variation of 25 percent decrease in release 3.0 compared to version   38 2.4 in the dependency propagation regardless of the number of modules. In Table 3-1, and in Figure 3-11 it can be appreciated that there is a 217 percent increase in the number of modules, n, that together with the decrease in the dependency propagation contribute to the sharp decrease of the change propagation, V/n^2. This is important because there is an increase of approximately 33 percent in the number of source lines of code, SLOC, from version 2.4 to 3.0. However, the change propagation decreases as does visibility, V, which does not take into account the number of classes or elements, n, as illustrated in Table 3-1, this is also more visible in Figure 3-12. We include the change propagation variants to show their behavior.    39  Figure 3-11 Checkstyle propagation compared to SBO, CSU, CB In release 3.1, we found an increase in the Visibility, V, which is not normalized by n2 as noted in Figure 3-12. However, since there is also a 39 percent increase in the number of modules, n, from version 3.0 to 3.1 the change propagation, V/n2, appears relatively stable for the Divide by   40 Propagation Length (DIV_LENGTH) of as illustrated by Figure 3-14. This leads us to formulate the question that if to obtain our modified change propagation metric the visibility matrix, V of length n-1 should be normalized by n2; or whether it should be normalized by the initial direct dependency matrix D. In order to clarify the estimation of change propagation we denote visibility matrix of lengths of n-1 as V(n-1) and the direct  dependency design structure matrix, D, as V(1). 1 0 1 ( 1) (1) i n i V n D V D         Figure 3-12 10x zoom for Visibility, V Normalizing V(n-1) by V(1) (see section 3.4.2.5.1) results in the ratio of dependency propagation growths in reference to its initial state, which is the matrix with the direct dependencies. A similar behaviour is observed in Figure 3-15 as in Figure 3-11, but with a different scale when compared to V/n^2. However, an increase is detected from version 3.3 to 3.4 similar to V in Figure 3-11.  Another increase in change propagation, V/n^2, is found with release 3. (label C in Figure 3-11). Repeating the data for version 3.4 allows us to compare our results with those from Bouwers (2011), since we were not able to find data for the release 3.5 of checkstyle. Checkstyle change propagation stabilizes from version 4.0 to 4.4, which is visible in the releases running prior to   41 label E. These versions have small variations on their size measured in SLOC’s, number of modules, n, visibility, V, and change propagation, V/n^2.  In checkstyle release 5.0, marked with label E, there is an increase in visibility of around 30 percent for Max, Aver, MaxPlus change propagation variants, which amounts to an increase of 169 percent for the Divide by Propagation Length. For the SUM and MAX change propagation variants, an increase of approximately 400 percent was measured because these respond more sensibly to the increase of parallel paths as will be explained in the next sections.  For versions 5.0 to 5.6 we can see in Figure 3-11 some other minor variations that do not affect the overall trend. From analysis of version 1.1 the earliest version accessible in the Checkstyle repository (label A) we observe that the initial change propagation V/n2, reduces consecutively up to version 1.3. In version 1.4 it starts to grow again until version 2.2. In version 2.3 a minimal decrease is detected. In version 2.4 the highest change propagation is detected and a sharp decline is observed at version 3.0, in label B in Figure 3-11.   Figure 3-13 5x zoom for Change propagation, V/n^2    42  Figure 3-14 Zoom for Change propagation, V/n^2    Table 3-1 Gross change propagation, V, and normalized change propagation, V/n 2  1.0 1.1 1.2 1.3             1.4 2.0 2.1 2.2 2.3 2.4 3.0 3.1            3.2             3.3             3.4             3.4 SLOC 11,827    12,283     13,390      10,919       11,575    12,541    21,174    21,858     22,106     29,823      38,121     45,087      45,747      50,579      50,579 D noDiagonal 776          845           960            1,316         1,456       1,640       2,697       2,802        3,132        3,189         4,186        4,775         3,105         3,498         3,498 Cycles -           -            -            -              -           -           -           -            -            -             12              1                 1                 -             - n 18             19              26              25               25             27             31             34              36              114            159           80               82               82               82 SLOC/n 657          646           515            437             463          464          683          643           614           262            240           564            558            617            617 V 1.0 1.1 1.2 1.3             1.4 2.0 2.1 2.2 2.3 2.4 3.0 3.1            3.2             3.3             3.4             3.4 SUM 1,679       1,767        1,975        3,501         3,641       4,975       8,565       9,603        12,003     6,857         16,594     8,529         7,018         17,061      17,061 MAX 1,160       1,246        1,437        2,558         2,698       3,386       5,545       6,119        7,354        6,048         11,344     7,116         5,579         12,111      12,111 AVER 1,086       1,171        1,350        2,356         2,496       3,068       4,885       5,329        6,528        5,873         10,532     6,747         5,209         10,344      10,344 MAX+ 1,216       1,303        1,499        2,715         2,856       3,605       5,789       6,391        7,725        6,264         12,269     7,396         5,870         13,067      13,067 DIVN 826          894           999            1,403         1,543       1,764       2,886       3,002        3,378        3,221         4,276        4,823         3,153         3,661         3,661 DIV1.1 1,597       1,683        1,883        3,302         3,442       4,671       8,031       8,985        11,196     6,523         15,467     8,197         6,662         15,828      15,828 DIVPOW 1,069       1,146        1,305        2,061         2,201       2,740       4,635       5,047        6,042        4,513         7,589        6,146         4,522         8,128         8,128 V/n^2 1.1 1.2 1.2 1.4 2.0 2.1 2.2 2.3 2.4 3.0 3.1            3.2             3.3             3.4             3.4 SUM 5.2           4.9            2.9             5.6              5.8           6.8           8.9           8.3            9.3            0.5             0.7            1.3             1.0             2.5             2.5 MAX 3.6           3.5            2.1             4.1              4.3           4.6           5.8           5.3            5.7            0.5             0.4            1.1             0.8             1.8             1.8 AVER 3.4           3.2            2.0             3.8              4.0           4.2           5.1           4.6            5.0            0.5             0.4            1.1             0.8             1.5             1.5 MAX+ 3.8           3.6            2.2             4.3              4.6           4.9           6.0           5.5            6.0            0.5             0.5            1.2             0.9             1.9             1.9 DIVN 2.5           2.5            1.5             2.2              2.5           2.4           3.0           2.6            2.6            0.2             0.2            0.8             0.5             0.5             0.5 DIV1.1 4.9           4.7            2.8             5.3              5.5           6.4           8.4           7.8            8.6            0.5             0.6            1.3             1.0             2.4             2.4 DIVPOW 3.3           3.2            1.9             3.3              3.5           3.8           4.8           4.4            4.7            0.3             0.3            1.0             0.7             1.2             1.2 4.0 4.1             4.2             4.3             4.4             5.0 5.1               5.2               5.3               5.4               5.5               5.6 SLOC 52,296     52,278      52,974      53,696      53,822      55,302        55,522        56,989        56,593        56,989        58,493        58,808 D noDiagonal 4,833        4,824         4,893         4,957         4,969         5,635           5,638           5,822           4,403           5,895           5,911           5,916 Cycles -            -             -             -             -             -               -               96                 -               -               -               - n 249           249            250            255            256            270              270              276              276              279              279              279 SLOC/n 210           210            212            211            210            205              206              206              205              204              210              211 V 4.0 4.1             4.2             4.3             4.4             5.0 5.1               5.2               5.3               5.4               5.5               5.6 SUM 28,340     28,326      28,459      28,619      28,639      144,439      144,448      153,242      152,916      153,242      153,282      153,259 MAX 18,411     18,397      18,525      18,665      18,682      24,673        24,683        27,123        26,878        27,123        27,163        27,139 AVER 17,087     17,073      17,196      17,331      17,349      22,308        22,320        24,551        24,366        24,552        24,583        24,555 MAX+ 20,027     20,014      20,144      20,289      20,307      28,083        28,092        30,740        30,469        30,740        30,780        30,574 DIVN 4,927        4,918         4,987         5,049         5,061         4,149           6,152           6,423           6,355           6,423           6,439           6,444 DIV1.1 26,203     26,189      26,316      26,467      26,487      131,820      131,829      139,846      139,544      139,846      139,884      139,864 DIVPOW 11,091     11,080      11,172      11,273      11,288      30,352        30,356        31,990        31,830        31,990        32,016        32,014 V/n^2 4.0 4.1             4.2             4.3             4.4             5.0 5.1               5.2               5.3               5.4               5.5               5.6 SUM 0.5            0.5             0.5             0.4             0.4             2.0               2.0               2.0               2.0               2.0               2.0               2.0 MAX 0.3            0.3             0.3             0.3             0.3             0.3               0.3               0.4               0.4               0.3               0.3               0.3 AVER 0.3            0.3             0.3             0.3             0.3             0.3               0.3               0.3               0.3               0.3               0.3               0.3 MAX+ 0.3            0.3             0.3             0.3             0.3             0.4               0.4               0.4               0.4               0.4               0.4               0.4 DIVN 0.1            0.1             0.1             0.1             0.1             0.1               0.1               0.1               0.1               0.1               0.1               0.1 DIV1.1 0.4            0.4             0.4             0.4             0.4             1.8               1.8               1.8               1.8               1.8               1.8               1.8 DIVPOW 0.2            0.2             0.2             0.2             0.2             0.4               0.4               0.4               0.4               0.4               0.4               0.4 A B C D E   43  Normalizing by Visibility Length 1 3.4.2.5.1 Taking a closer look at the sum of dependencies for V, and V/n2 in Figure 3-11 we found some cases where the tendency of V is opposite to the tendency observed when normalizing by n2. This leads us to the following question: Could the increase of dependency propagation normalized by the dependencies be a better indicator of propagation cost than normalizing by n2? We found that normalizing by V(1) did not produce a good result when compared with system breakdown optimality approach from Bouwers (2011). Normalizing by n2 provides a result that is coincides more with the system breakdown optimality.  Figure 3-15 V divided by D 1 and compared vs V divided by n 2    44  Adjustment in the Analysis of Checkstyle 3.4.2.5.2  In order to graphically compare the metrics of this study with that of Bouwers (2011), we repeated the data from Checkstyle version 3.4 for version 3.5 to compare the change propagation metric with that of Bouwers’ study. We also performed the analysis at the class level for Checkstyle, since some versions only had one package containing all of the classes, e.g. versions 1.1 to 2.4. Previous analyses were done at the first, second and sometimes at the third level since the other systems analyzed did had a complex hierarchy, with up to seven hierarchical levels as in the case of Hadoop. As in some analysis, (Sosa 2008); (Bouwers 2011), the hierarchical levels of analysis were determined by the analyst. In some cases, at the second level the dependencies among modules will represent less than 10% of total dependencies. In this case the modules that concentrate most of the dependencies are expanded whenever the number of modules, n, are less than 15. The researcher initially wanted to analyze the software architecture of a system as the fundamental relationships among them. For this reason, a threshold of 10 modules was set heuristically since it is a manageable number for an analyst. However, practically this number did not reflected the systems hierarchical structure and was stretched at some points to 22 modules.   Similarities with other Metrics 3.4.2.5.3 Some measurements in this study and those of Bouwers, (2011) coincide in terms of measuring the architecture. The most visible similarity is that system breakdown optimality (SBO) increased from version 2.4 to 3.0 and the change propagation detects improvement from versions 2.4 to 3.0. The same applies to component balance (CB), which was used in Bouwers (2011),  to measure the organization and decomposition of the system. Component breakdown increase also coincides with the decrease in propagation. There are other differences as well:   45 the small increase of propagation from version 2.3 to 2.4 is not detected. One possible cause of this is that the metrics from (Bouwers 2011) might be saturated or that our metric is more sensible. The change propagation stabilization from version 4.0 to 4.4 coincides as well with the component size uniformity (CSU) and measurements from Bowers’, but the increase from version 4.4 to 5.0 appears in (Bouwers 2011)  as continuous.  Sum Variant Breadth Sensitivity 3.5 The SUM variant is sensible to the change propagation caused by breadth, and this variant can be used to analyze elements that might spread dependencies in the system. We detected that some structures at some releases produce a high result in the estimation of change propagation of the SUM (Nord 2012, Nord 2013) variant while being consistent with the other change propagation variants in other versions. This is due to the sensitivity to the propagation caused by breadth of the SUM variant since SUM adds the parallel paths instead of taking the maximum or an average as the other variants. In addition, the DIVIDE BY variants use the SUM variant as their numerator but are reduced by their denominator.  In Checkstyle versions 5.0 to 5.6, illustrated by Figure 3-11, it is noted that differences of approximately an order of magnitude of one among variants SUM and DIVIDE_BY1_1 and the rest of the variants. This study considers the DIVIDE_BY1_1 as similar to SUM variant because DIVIDE_BY1_1 has the same parallel and series operator divided by a constant of 1.1. For the SUM variation, for instance, if we observe the gross change propagation , V, of Checkstyle version 5.0 with the SUM (144,439) and MAX (24,673) variants there are difference of approximate 5 times between them as illustrated in Table 3-2. It is noted that the propagation under the MAX variant diminishes after the propagation of length 2, or power 2. On the other   46 hand, the SUM variant increases consecutively until the propagation of length, or power, of 6 which has a value of approximately 5 times the initial design structure matrix, D1.  Table 3-2 Checkstyle 2.0 change propagation per length The causes of the increase for the SUM variation are the parallel operations, which sums all the parallel paths. For structures produce a high number of parallel paths in their propagation the SUM variant will be more sensible. In the case of series operation, in structures where the difference is small among x and y for the series operator, represented by min(x, y) will result in a marginal decrease in the propagation strength.  At a closer inspection, we observe that for some elements, the change propagation produces more indirect dependencies, as illustrated in Table 3-3 and Table 3-4. For instance, for element 251, CheckstyleException, propagation increases. Element CheckstyleException growth represents less than 5% (1,167/24,673) of the total growth of the MAX variant while its growth is more than 10% (14,534/144,439) for the SUM variant. It is observed that logically the SUM length MAX SUM 1 5,635 5,635 2 3,612 4,324 3 4,267 6,940 4 4,003 13,246 5 3,058 22,381 6 1,921 26,110 7 983 22,096 8 531 18,120 9 339 14,080 10 197 8,239 11 91 2,794 12 32 450 13 4 24 length ∑ 24,673 144,439   47 variant has a higher change propagation since it adds the cells with indirect dependencies, whereas MAX choses only the maximum.   Table 3-3 MAX change propagation per path length for checkstyle-5.0, scaled by path length MAX element 1 2 3 4 5 6 7 8 9 10 11 12 13 ∑ length 240 144 109 107 69 29 27 24 4 0 0 0 0 0 513 241 16 6 1 0 0 0 0 0 0 0 0 0 0 23 242 28 5 1 0 0 0 0 0 0 0 0 0 0 34 243 17 34 3 1 0 0 0 0 0 0 0 0 0 55 244 14 32 17 4 1 0 0 0 0 0 0 0 0 68 245 203 135 88 71 29 27 24 4 0 0 0 0 0 581 246 16 198 147 70 56 28 27 24 4 0 0 0 0 570 247 21 24 188 141 70 56 28 27 24 4 0 0 0 583 248 2 9 17 97 73 36 33 27 27 24 4 0 0 349 249 51 46 126 263 241 121 65 34 27 27 24 4 0 1029 250 2 9 17 97 73 36 33 27 27 24 4 0 0 349 251 154 58 40 203 238 206 110 43 33 27 27 24 4 1167 252 8 24 28 194 232 115 65 34 27 27 24 4 0 782 253 72 183 136 88 71 29 27 24 4 0 0 0 0 634 254 6 61 183 136 88 71 29 27 24 4 0 0 0 629 255 84 71 189 219 128 80 35 27 27 24 4 0 0 888 256 99 178 108 70 61 53 27 24 4 0 0 0 0 624 257 21 15 0 0 0 0 0 0 0 0 0 0 0 36 258 21 35 15 0 0 0 0 0 0 0 0 0 0 71 259 8 8 0 0 0 0 0 0 0 0 0 0 0 16 260 39 25 2 0 0 0 0 0 0 0 0 0 0 66 261 22 202 140 88 71 29 27 24 4 0 0 0 0 607 262 110 47 15 3 0 0 0 0 0 0 0 0 0 175 263 47 311 379 196 112 72 29 27 24 4 0 0 0 1201 264 47 86 313 378 196 112 72 29 27 24 4 0 0 1288 265 7 0 0 0 0 0 0 0 0 0 0 0 0 7 266 150 55 2 0 0 0 0 0 0 0 0 0 0 207 267 51 34 0 0 0 0 0 0 0 0 0 0 0 85 268 48 98 75 44 28 27 24 4 0 0 0 0 0 348 269 2851 612 477 253 143 96 29 27 24 4 0 0 0 4516 270 85 51 98 75 44 28 27 24 4 0 0 0 0 436 length ∑ 5635 3612 4267 4003 3058 1921 983 531 339 197 91 32 4 24673 path length   48  Table 3-4 SUM change propagation evolution per path leength for checkstyle-5.0, scaled by These small differences increase because the SUM variant adds the parallel paths in contrast to the calculation using the MAX variant where the calculation is based on the maximum value, as illustrated by Table 3-6. This is visible from paths of length 2 where a small increase in the SUM variant in the dependencies (e.g., element 251, CheckstyleException) results in a change propagation 17 units higher, detail in Table 3-6. For example, the difference between the SUM and the MAX variant grows 53 for paths of length 3, 174 in paths of length 4, to 310 in paths of length 5, to 336 in paths of length 6 and so on. These small differences are increased when paths of higher lengths are estimated. Therefore, we can conclude that the SUM is more sensible for a higher number of parallel paths in which the following possibility is implemented: SUM element 1 2 3 4 5 6 7 8 9 10 11 12 13 ∑ length 240 144 111 172 169 629 952 330 24 0 0 0 0 0 2531 241 16 7 2 0 0 0 0 0 0 0 0 0 0 25 242 28 5 1 0 0 0 0 0 0 0 0 0 0 34 243 17 34 3 1 0 0 0 0 0 0 0 0 0 55 244 14 32 17 4 1 0 0 0 0 0 0 0 0 68 245 203 135 153 170 629 952 330 24 0 0 0 0 0 2596 246 16 218 148 136 154 627 952 330 24 0 0 0 0 2605 247 21 32 202 142 136 154 627 952 330 24 0 0 0 2620 248 2 10 23 104 74 81 123 623 952 330 24 0 0 2346 249 51 48 147 299 327 333 858 1702 1905 1306 354 24 0 7354 250 2 10 23 104 74 81 123 623 952 330 24 0 0 2346 251 154 75 93 377 548 542 594 1700 3896 4139 1990 402 24 14534 252 8 26 40 226 246 210 235 750 1575 1282 354 24 0 4976 253 72 186 136 153 170 629 952 330 24 0 0 0 0 2652 254 6 61 186 136 153 170 629 952 330 24 0 0 0 2647 255 84 71 206 224 221 250 752 1575 1282 354 24 0 0 5043 256 99 183 202 309 955 1772 1286 354 24 0 0 0 0 5184 257 21 15 0 0 0 0 0 0 0 0 0 0 0 36 258 21 36 16 0 0 0 0 0 0 0 0 0 0 73 259 8 8 0 0 0 0 0 0 0 0 0 0 0 16 260 39 30 2 0 0 0 0 0 0 0 0 0 0 71 261 22 205 141 154 170 629 952 330 24 0 0 0 0 2627 262 110 86 38 6 0 0 0 0 0 0 0 0 0 240 263 47 324 450 351 335 800 1581 1282 354 24 0 0 0 5548 264 47 114 579 620 493 489 1427 2533 1612 378 24 0 0 8316 265 7 0 0 0 0 0 0 0 0 0 0 0 0 7 266 150 56 2 0 0 0 0 0 0 0 0 0 0 208 267 51 34 0 0 0 0 0 0 0 0 0 0 0 85 268 48 98 140 142 627 952 330 24 0 0 0 0 0 2361 269 2851 890 1064 2366 5472 6893 4830 2034 402 24 0 0 0 26826 270 85 54 100 140 142 627 952 330 24 0 0 0 0 2454 ∑ length 5635 4324 6940 13246 22381 26110 22096 18120 14080 8239 2794 450 24 144,439 path length   49 PRL01.The higher the number of parallel paths as indirect dependencies from one element to another exist a higher number in the modified dot product should result.  The increase detected in Checkstyle versions 5.0 to 5.6 could indicate that the SUM variant has a high sensitivity to the increase of the number parallel paths and that it does give a masked value of change propagation. Additionally, as the depth in the propagation increase there is less chance that the effects of the change in one element that provides dependencies can affect the rest of the elements with longer paths (Kazman 2012). In order to reflect this premise the Divide By Propagation Length variant implements in the proposition:  VAR7. The resulting indirect dependency should the sum divided by the a denominator that decreases the result when the length of the path, or i, in equation (2) changes to:  1 1 1 1 n n i jkn j k i D V i         It can be observed in Figure 3-11 that the Divide by Propagation Length variant that appears as DIVPOW reduces the gross change propagation V for Checkstyle versions 5.0 to 5.6 which maintains more similarities with the measures obtained by Bouwers (2011). For this reasons, we conclude that despite the SUM variation might estimate a high change propagation it is still useful for a sensitivity analysis as that shown in Table 3-2 and Table 3-3 were element 249, Configuration, 251, CheckstyleException, 255, TextBlock, 256, Utils, 263, LocalizedMessage, and 264, SeverityLevel are elements that record approximately 50% of the change propagation (72,805/144,439) in just 3% of the elements. Elements 249, 251, 255 and 264 have their highest partial change propagation in paths of length 8 and concentrate most of their partial change   50 propagation in the mention paths lengths, with 71, 83, 80, 64 and 55% of their total change propagation. When the Divide by Propagation Length variant diminishes the change propagation proportionally to the distance of indirect dependency dividing by the path length (modified dot product power) the gross change propagation is diminished as illustrated byTable 3-5.   Table 3-5 Divide by Length (DIVPOW) DIVPOW element 1 2 3 4 5 6 7 8 9 10 11 12 13 ∑ length 48 0 98 92 319 703 709 353 77 4 0 0 0 0 2355 240 144 56 57 42 126 159 47 3 0 0 0 0 0 634 241 16 4 1 0 0 0 0 0 0 0 0 0 0 20 242 28 3 0 0 0 0 0 0 0 0 0 0 0 31 243 17 17 1 0 0 0 0 0 0 0 0 0 0 35 244 14 16 6 1 0 0 0 0 0 0 0 0 0 37 245 203 68 51 43 126 159 47 3 0 0 0 0 0 699 246 16 109 49 34 31 105 136 41 3 0 0 0 0 524 247 21 16 67 36 27 26 90 119 37 2 0 0 0 440 248 2 5 8 26 15 14 18 78 106 33 2 0 0 305 249 51 24 49 75 65 56 123 213 212 131 32 2 0 1031 250 2 5 8 26 15 14 18 78 106 33 2 0 0 305 251 154 38 31 94 110 90 85 213 433 414 181 34 2 1877 252 8 13 13 57 49 35 34 94 175 128 32 2 0 640 253 72 93 45 38 34 105 136 41 3 0 0 0 0 567 254 6 31 62 34 31 28 90 119 37 2 0 0 0 439 255 84 36 69 56 44 42 107 197 142 35 2 0 0 814 256 99 92 67 77 191 295 184 44 3 0 0 0 0 1052 257 21 8 0 0 0 0 0 0 0 0 0 0 0 29 258 21 18 5 0 0 0 0 0 0 0 0 0 0 44 259 8 4 0 0 0 0 0 0 0 0 0 0 0 12 260 39 15 1 0 0 0 0 0 0 0 0 0 0 55 261 22 103 47 39 34 105 136 41 3 0 0 0 0 529 262 110 43 13 2 0 0 0 0 0 0 0 0 0 167 263 47 162 150 88 67 133 226 160 39 2 0 0 0 1075 264 47 57 193 155 99 82 204 317 179 38 2 0 0 1372 265 7 0 0 0 0 0 0 0 0 0 0 0 0 7 266 150 28 1 0 0 0 0 0 0 0 0 0 0 179 267 51 17 0 0 0 0 0 0 0 0 0 0 0 68 268 48 49 47 36 125 159 47 3 0 0 0 0 0 513 269 2851 445 355 592 1094 1149 690 254 45 2 0 0 0 7477 270 85 27 33 35 28 105 136 41 3 0 0 0 0 493 ∑ length 4444 2159 2313 3312 4476 4352 3157 2265 1564 824 254 38 2 29,158 path length   51  Table 3-6 Increase of change propagation for checkstyle 5.0 MAX vs SUM Variant         col row 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 … ∑ SUM 251 0 0 0 0 0 1 14 0 0 0 0 0 0 0 0 0 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 154 MAX 251 0 0 0 0 0 1 14 0 0 0 0 0 0 0 0 0 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 154 Variant         col row 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 … ∑ SUM 251 0 0 2 2 2 3 0 0 0 0 0 0 0 0 2 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 75 MAX 251 0 0 2 2 2 2 0 0 0 0 0 0 0 0 2 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 58 SUM-MAX 0 0 0 1 0 0 0 17 Variant         col row 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 … ∑ SUM 251 0 0 3 3 3 3 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 93 MAX 251 0 0 1 1 1 1 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 40 SUM-MAX 2 2 2 2 53 Variant         col row 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 … ∑ SUM 251 0 0 1 1 1 1 0 0 0 0 0 0 5 0 0 0 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 377 MAX 251 0 0 1 1 1 1 0 0 0 0 0 0 2 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 203 SUM-MAX 81 0 0 0 0 3 3 174 Variant         col row 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 … ∑ SUM 251 0 0 0 2 2 0 0 0 0 0 0 0 4 0 5 5 4 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 548 MAX 251 0 0 0 1 1 0 0 0 0 0 0 0 1 0 2 2 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 238 SUM-MAX 1 1 3 3 3 3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 310 Variant         col row 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 … ∑ SUM 251 0 0 0 3 3 0 0 0 0 0 0 0 1 0 4 4 1 6 57 9 9 11 11 9 6 6 6 6 9 6 9 9 13 9 9 9 9 11 6 9 6 9 6 5 542 MAX 251 0 0 0 1 1 0 0 0 0 0 0 0 1 0 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 206 SUM-MAX 2 2 0 3 3 0 4 55 7 7 9 9 7 4 4 4 4 7 4 7 7 11 7 7 7 7 9 4 7 4 7 4 4 336 Length 1 Length 6 Length 5 Length 4 Length 3 Length 2   52  4 Deriving Value for Software Architecture from User-visible Concerns  Introduction 4.1 In this chapter we report our attempt to define a metric for software architecture value, metric that we could not fully validate, and that we abandoned in favor of an improved propagation cost approach. This chapter describes the approach to estimate the value of systems’ software architectural design by mapping value from user-visible concerns.  One of the challenges in the software development industry is that the development new functionality and maintenance cost and effort increase because the complexity has grown. Design or redesign of software architecture helps to reduce the complexity allows for efficient and scalable development. Despite common knowledge of resource allocation to architectural design tasks is widespread in organizations benefits are not visible and quantifiable, and the cost of rearchitecting is seem as a deterrent. This deters from a proactive and frequent scheduling for software architectural effort allocation. Most software architectural effort allocation occurs reactively when the increase in cost per functional unit is noticeably high and when technical debt has accumulated into the software system. In order to estimate software architecture value it would be useful to have estimation techniques that can help organizations to quantify their value to support effort allocation decision-making process.  For this purpose we tried another approach that departs from computing a cost propagation. This alternative proposal is based on directly mapping value from user-visible concerns, such  53 as features into user-invisible but organizational and technical value concerns such as architectural elements and their development tasks. However, this approach proved difficult for us to validate due to the difficulty to produce a proper validation strategy and because of the time and resources that would have been needed.  Value for Invisible Elements in the Backlog 4.2 Kruchten (2010) proposes a value system framework in order to classify and prioritize the different elements in a backlog. Kruchten suggests that software development activities can be classified in four categories, within two dimensions: visibility and value as shown in Figure 4-1. In the visibility dimension, there are user-visible and user-invisible development activity types. Features are visible to the client or end-user whereas invisible architectural elements are hidden to the end-user.   Figure 4-1 value system framework  To use an analogy, architectural elements are concealed in the same way as the engine, chassis and other structural elements are hidden to the driver. All that the driver is concerned with are the features realized in the parts of the car that the driver has contact with or the car  54 interface. The car designers and manufacturers have a knowledge and perception of the car infrastructure and can better visualize tasks and the infrastructure involved in the production of future car models. The infrastructure knowledge supports their design decision-making, time, cost and effort estimation in the long-term.  In the same way, in software development infrastructure, design tasks which include the rationales for design decisions, architectural designs support the technical and organizational decision-making progress. This design and planning provide with modularization, layers, standardization, abstraction, reuse and a reduction of code dependencies. A software architectural design provide with standards, interfaces and a framework to implement features and following these guidelines dependency is abstracted and minimized (Lakos 1996) and thus reducing code dependencies and the probability of change in the rest of the module components.  The value dimension distinguishes development tasks that involve a positive or negative value to the system. In the previous paragraph the functional and architectural tasks are used as visible and invisible examples correspondingly, both adding positive value to the system. On the other hand, there are potentially code implementations with side effect aspects in a software system which, if not corrected, will continue to or could have a negative impact on the system. Defect correction tasks do not add value per se, but including these types of tasks in the schedule will avoid unexpected effects, such as involuntary behavior, that decrease the value of the system. For instance, the negative value of a defect that causes incorrect results might require additional effort from the user. Technical debt is a metaphor that refers to elements that cause an increase in effort and that are perceived as a consequence of suboptimal implementation. Technical debt are code side-effects that result in a negative quality in the system in the present. Furthermore, this technical debt will cause  55 stronger long-term negative effects on future development effort. Software that is built on top of suboptimal, technical debt ridden structures will incur in costs for removal and reworking (Nord 2012).  In this sense, the risk that technical debt poses on the system is high.  Kruchten (2010) argues that including all categories of tasks inside the backlog and giving them a value allows for their direct and active prioritization and management. Wiegers (1999) proposes that scheduling priorities based on feature value and implicitly most scheduling approaches have in their backlog formed by functional requirements. In the same sense, agile methods advocate for the delivery of value to the client as one of their main tenets (Beck et al. 2001). Kruchten suggests that including all the types of tasks in the backlog and estimating their value can help them to be scheduled quantitatively rather than qualitatively. This gives more clarity and substance to aspects that subtract value and that are hard to perceive by end-users and stakeholders and organizational managers who make decisions on software development resource allocation. 4.2.1 Benefit for Architectural Elements We attempted to derive value for user-invisible architectural elements and its tasks from the visible activity types it supports. We use the value formula from Wiegers (1999) which is similar to a benefit-cost ratio, and other considerations, and we assume that the cost for invisible elements can be estimated by the software development team. In a similar way Ojala (2008) proposes that benefits can be assessed on the basis that the business and/or operational side of organizations have a better perspective on the benefits that a given architectural element might bestow on a system based on the quality attributes it supports. The approach in this chapter estimates the benefit as a relationship of the features and non- functional requirements.   56 The challenge for estimating value for invisible development types is that their benefit is intangible or abstract. Denne (2004) proposes to incrementally implement the architectural structure by incrementally including and refactoring architectural elements in the release plan. The approach in this chapter aims to estimate a value for software architectural elements in order to prioritize them by mapping, inferring and making explicit its cost and benefits. By doing so, development teams will have a better visibility and control of the benefits and costs and organizations can adapt their strategies accordingly considering other concerns such as revenue in time and net present value principles as Denne suggests.  An architectural element’s benefits are difficult to estimate or intangible for an organization; however, the architectural elements approximate cost can be estimated to some degree. Software development team with experience and knowledge can make educated guesses about the effort needed to implement architectural elements.  Bachmann, Bass, and Nord (2007) cost-benefit analysis method (CBAM) estimates the architectural elements value based on the judgments of stakeholders and technical staff. CBAM is a complete and extensive method that requires an intensive effort from experienced software architects and requires commitment from business stakeholders. Hence, cost- benefit analysis method requires an extensive effort. The approach proposed in this thesis is an attempt to provide a lighter method for estimating the value of architectural elements.  Mapping Benefit from Features to Architectural 4.3 Elements Since architectural elements provide benefits to features, this study models these relationships as constraints used to estimate value. The purpose of the mapping is to  57 estimate a value for architectural elements based on the features it supports as illustrated by Figure 4-2. It is important to assign a value for scheduling, reducing technical debt, to reduce cost, to be able to react more quickly to changes in the commercial, technical and social environment.  Figure 4-2 Mapping of features to architectural elements  For simplicity we consider that a system is composed of a set of features:   (4) and supported by a set of architectural elements: (5) Whether a feature, sub-feature, or code artifact is implemented irrelevant since these elements are considered visible elements that have benefits, costs and consequently a value. For simplicity all features, sub-features, and tasks are considered features in this approach. The value of an architectural element is derived from the features it supports by bestowing infrastructure services such as the implementation of common technical tasks inside the  Visible feat A Benefit: 10 Cost: 2 Visible feat B Benefit: 7 Cost: 1 Visible feat D Benefit: 3 Cost: 1 Visible feat E Benefit: 16 Cost: 2 Invisible ArchEl C Benefit: ? Cost: 2 Invisible ArchEl F Benefit: ? Cost: 2 S {f1,  f2,  fn}   1 2 nAE  AE ,  AE ,  ,  AE   58 system. The visible value of a system is understood by the stakeholders in an organization. The invisible value of architectural elements can be understood and consequently assessed if there is an explicit mapping to the architectural elements and quality attributes they support. The architectural element derived value, DV(AEi), is calculated in two parts; a) the maximum value of the features it supports b) the portion of visible value the system architectural elements realize. where ( )i F F  is the subset of features are supported by AEi , for this reason the derived value for AEi, DV(AEi) is expressed by:      i ( )  DV(AE ) max ( ) ( ) i i V F V F V F       (6) The maximum value from the supported features is to give a value that will be slightly higher than any of the supported elements. Value of an architectural element is also a function of the portion of the value it supports to the total visible value in the system.  In order to determine the value of an architectural element, this study departs from the notion that its value should ideally reflect the provided invisible sub-functionality, standards, interfaces, patterns and other technical infrastructure aspects provided by the architectural elements. However, during the initial design phase there are no implemented code artifacts, and a notion of its ratio is lacking. Since the goal is to provide a light-weight metric, the following ideas for determining the architectural element value were considered:  a) A heuristic percentage of the value of each feature supported, e.g. 10%  However, this would imply that if the total value of an architectural element was less than the value of any of its supported features, the feature(s) with value greater than the architectural  59 element would be implemented first. If this rationale is compared to building construction, then if wall decorations in a bathroom have greater value than the plumbing inside it. Then the decorations would be scheduled before plumbing. Implementing tasks that depend on hidden infrastructures result in greater costs at the end of the project life cycle. Part of the decoration would have to be removed to reinstall the plumbing followed by a wall reconstruction  and finishing (Nord 2012). Accordingly, the benefit for a given architectural element should be greater than any of the elements it supports:  b) The value of an architectural element is greater than any of the elements it supports.  the maximum value from the supported elements plus this calculation of  value based on the ratio of the sum of the supported elements’ value and the sum of the visible elements value in the system an architectural value is expressed in equation (6). 4.3.1 Scheduling The value obtained is used for scheduling in which all of the features, sub-features and architectural elements are part of the backlog B (7)   1 2 nR R ,  R ,  ,  R  (8)   1 2 nI I ,  I ,  ,  I  (9)  i i j i j i jI F , ...,F , ,  SF , ...SF ,  AE ,.., AE (10) Iteration task value is used to prioritize and allocate tasks into a project schedule. The iteration length is set in terms of the time a development team is available. For instance, if a one week iteration is desired with a team of 5 members, and each week is 40 hours, then 1 1_1 1 2{ , , 2,..., , , ,..., }N NB F SF F F AE AE AE  60 each iteration should have a value of 400 hours. Given that the cost of the elements is known, and that the cost is considered as the required time or effort, cost is used as a capacity factor and can be quantified to determine how many tasks assigned to an iteration. 4.3.2 Implementation This study used the Agile Planner for Digital Tabletop (Wang, Ghanam, and Maurer 2009) developed by the Agile Surface Engineering laboratory from University of Calgary. This software was developed for surface tabletops supporting agile project planning. This software was used to be used by distributed teams in an agile project planning. This thesis intended to use the agile planner for digital tabletop to express the code artifacts and the architectural elements supporting them in order to map the value from them. An infrared sensor and an infrared pen were added to the software in order to allow the digital tabletop features to be available when the tool was projected on a screen.  One of the challenges of implementation was to create an algorithm capable of determining the “levels” within the hierarchical structure of dependencies. For this reason, a searching algorithm based on the depth-first search algorithm (Tarjan 1972) was used to create all of the possible paths and thus to obtain the longest sequence of chained dependencies. This sequence was used to determine how many levels a software hierarchical structure has. One a hierarchical structure was obtained.  The value-deriving approach in this chapter used the value estimation proposed by Wiegers (1999), which expands benefit to cost into four elements, benefit plus penalty divided by the sum of cost plus risk as:  ( * * ) (cos * * ) benefit BW penalty PW value t CW risk RW      (11)  61 This definition is used to reflect aspects not considered as value directly to the client but as environmental conditions that encourage or hinder the implementation features or architectural elements in the backlog. Also, Wiegers (1999) definition includes different weighing factors that can be used to indicate that in certain conditions benefits are preferred than others. For instance, if benefits are more important than penalties then a greater weight can be given to benefit (BW). Or for instance in a highly regulated environment such as software for medical devices penalties of not implementing a regulation could have a greater weight than implementing a new feature. For simplicity in this study all the weights have been set to 1. The value of an element (feature or architectural element) is used to prioritize tasks in scheduling. For this reason, the result is referred as priority rather than value in the estimation application shown in the next page. Also, because in other literature such as () it is The estimated derived or mapped value or priority is referred as constrained priority since its used as a priority that is constrained to be implemented first by the dependencies The derived value is referred as constrained priority since its used as a priority that is constrained to be implemented first by the dependencies modeled as constraints (Ruhe 2005; Greer 2004). Since the values are used for prioritizing and to display them as integers priority and constrained priority are multiplied by a factor of 10,000 to obtain an integer from the smallest possible value according equation (11).  After the longest paths are calculated, levels are assigned to each element. The lowest level l is assigned to elements that do not provide any dependencies or that can be considered as the visible elements. The value assigning algorithm starts scanning the elements assigned at level l+1, l+2 and assigns them with another value term# # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 154140672 bytes for committing reserved memory. # An error report file with more information is saved as: # /usr/local/web-apis/harvester/bin/hs_err_pid61348.log

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.24.1-0073917/manifest

Comment

Related Items