Mojtaba Shahin

Architectural design decision: Existing models and tools

In the field of software architecture, there has been a paradigm shift from describing the outcome of architecting process mostly described by component and connector (know-what) to documenting architectural design decisions and their rationale (know-how) which leads to the production of an architecture. This paradigm shift results in emergence of various models and related tools for capturing, managing and sharing architectural design decisions and their rationale explicitly. This paper analyzes existing architectural design decisions models and provides a criteria-based comparison on tools that support these models. The major contribution of this paper is twofold: to show that all of these models have a consensus on capturing the essence of an architectural design decision; and to clarify the major difference among the tools and show what desired features are missing in these tools.

Improving understandability of architecture design through visualization of architectural design decision

Concentrating on components and connectors in traditional approaches to document software architecture causes the problems, such as high costs for architecture change and erode during architecture evolution. These problems result in a tendency to record architectural design decisions and their rationale made throughout architecting process. This tendency encourages practitioners and researchers to develop various models and related tools to model, capture, manage, share, and (re)use architectural design decisions. But there still remains a need to visualize and explore architectural design decisions due to the huge number of decisions and relationships among them in large and complex systems development. In this paper, we first make a survey on tools that support visualization of architectural design decisions, their features and deficiencies. Second we investigate how Compendium tool can be employed as a general tool to visualize architectural design decisions and their rationale. Last we present how the visualization by Compendium can improve the understandability and support the communication of architectural design in architecting process.

A systematic review of knowledge sharing challenges and practices in global software development

We present systematic literature review of 61 primary studies (2000September 2014) that empirically reported knowledge sharing challenges and practices in Global Software Development (GSD).We found knowledge sharing challenges and practices in GSD could be classified in 6 main themes: management, team structure, work processes/practices, team cognition, social attributes and technology.Regarding contextual settings, we found empirical studies were mainly conducted in offshore outsourcing collaboration model distributed between two sites. Most of the studied organizations were large enterprises. ContextGlobal Software Development (GSD) presents significant challenges to share and understand knowledge required for developing software. Organizations are expected to implement appropriate practices to address knowledge-sharing challenges in GSD. With the growing literature on GSD and its widespread adoption, it is important to build a body of knowledge to support future research and effective knowledge sharing practices. ObjectiveWe aimed at systematically identifying and synthesizing knowledge sharing challenges and practices. We also intended to classify the recurrent challenges and most frequently reported practices in different contextual settings. MethodWe used Systematic Literature Review (SLR) for reviewing 61 primary studies that were selected after searching the GSD literature published over the last 14 years (2000September 2014). We applied thematic analysis method for analysing the data extracted from the reviewed primary studies. ResultsOur findings revealed that knowledge sharing challenges and practices in GSD could be classified in 6 main themes: management, team structure, work processes/practices, team cognition, social attributes and technology. In regard to contextual settings, we found empirical studies were mainly conducted in an offshore outsourcing collaboration model distributed between two sites. Most of the studied organizations were large enterprises. Many of the studies did not report any information for several contextual attributes that made it difficult to analyse the reported challenges and practices with respect to their respective contexts. ConclusionWe can conclude: (a) there is a higher tendency among researchers to report practices than challenges of knowledge sharing in GSD. (b) Given our analysis, most of the reported knowledge sharing challenges and practices fall under the theme of work practices. (c) The technology related knowledge-sharing challenges are the least reported; we discussed the available technologies for supporting knowledge sharing needs in GSD. (d) The organizational contextual information is missing from a large number of studies; hence, it was not possible to investigate the potential relations between knowledge sharing challenges/practices and the contextual attributes of GSD teams. We assert the need of exploring knowledge sharing in the context of small/medium sized organizations to avoid the risk of findings being biased by specific empirical setting (e.g., large enterprises distributed between US and India).

A systematic review of software architecture visualization techniques

Abstract Context Given the increased interest in using visualization techniques (VTs) to help communicate and understand software architecture (SA) of large scale complex systems, several VTs and tools have been reported to represent architectural elements (such as architecture design, architectural patterns, and architectural design decisions). However, there is no attempt to systematically review and classify the VTs and associated tools reported for SA, and how they have been assessed and applied. Objective This work aimed at systematically reviewing the literature on software architecture visualization to develop a classification of VTs in SA, analyze the level of reported evidence and the use of different VTs for representing SA in different application domains, and identify the gaps for future research in the area. Method We used systematic literature review (SLR) method of the evidence-based software engineering (EBSE) for reviewing the literature on VTs for SA. We used both manual and automatic search strategies for searching the relevant papers published between 1 February 1999 and 1 July 2011. Results We selected 53 papers from the initially retrieved 23,056 articles for data extraction, analysis, and synthesis based on pre-defined inclusion and exclusion criteria. The results from the data analysis enabled us to classify the identified VTs into four types based on the usage popularity: graph-based, notation-based, matrix-based, and metaphor-based VTs. The VTs in SA are mostly used for architecture recovery and architectural evolution activities. We have also identified ten purposes of using VTs in SA. Our results also revealed that VTs in SA have been applied to a wide range of application domains, among which “graphics software” and “distributed system” have received the most attention. Conclusion SA visualization has gained significant importance in understanding and evolving software-intensive systems. However, only a few VTs have been employed in industrial practice. This review has enabled us to identify the following areas for further research and improvement: (i) it is necessary to perform more research on applying visualization techniques in architectural analysis, architectural synthesis, architectural implementation, and architecture reuse activities; (ii) it is essential to pay more attention to use more objective evaluation methods (e.g., controlled experiment) for providing more convincing evidence to support the promised benefits of using VTs in SA; (iii) it is important to conduct industrial surveys for investigating how software architecture practitioners actually employ VTs in architecting process and what are the issues that hinder and prevent them from adopting VTs in SA.

Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices

Continuous practices, i.e., continuous integration, delivery, and deployment, are the software development industry practices that enable organizations to frequently and reliably release new features and products. With the increasing interest in the literature on continuous practices, it is important to systematically review and synthesize the approaches, tools, challenges, and practices reported for adopting and implementing continuous practices. This paper aimed at systematically reviewing the state of the art of continuous practices to classify approaches and tools, identify challenges and practices in this regard, and identify the gaps for future research. We used the systematic literature review method for reviewing the peer-reviewed papers on continuous practices published between 2004 and June 1, 2016. We applied the thematic analysis method for analyzing the data extracted from reviewing 69 papers selected using predefined criteria. We have identified 30 approaches and associated tools, which facilitate the implementation of continuous practices in the following ways: 1) reducing build and test time in continuous integration (CI); 2) increasing visibility and awareness on build and test results in CI; 3) supporting (semi-) automated continuous testing; 4) detecting violations, flaws, and faults in CI; 5) addressing security and scalability issues in deployment pipeline; and 6) improving dependability and reliability of deployment process. We have also determined a list of critical factors, such as testing (effort and time), team awareness and transparency, good design principles, customer, highly skilled and motivated team, application domain, and appropriate infrastructure that should be carefully considered when introducing continuous practices in a given organization. The majority of the reviewed papers were validation (34.7%) and evaluation (36.2%) research types. This paper also reveals that continuous practices have been successfully applied to both greenfield and maintenance projects. Continuous practices have become an important area of software engineering research and practice. While the reported approaches, tools, and practices are addressing a wide range of challenges, there are several challenges and gaps, which require future research work for improving the capturing and reporting of contextual information in the studies reporting different aspects of continuous practices; gaining a deep understanding of how software-intensive systems should be (re-) architected to support continuous practices; and addressing the lack of knowledge and tools for engineering processes of designing and running secure deployment pipelines.

Architectural design decision visualization for architecture design: preliminary results of a controlled experiment

Visualization of architectural design decision (ADD) and its rationale, as a kind of traceability information, is supposed to facilitate the understanding of architecture design and the reasoning behind the design rationale, which is supposed to improve the architecting process and gets better architecture design results. But the lack of empirical evaluation that supports this statement prevents industrial practitioners from using ADD visualization in their daily architecting activities. In this paper, we conducted a controlled experiment to investigate how visualization of ADD can improve the understanding of architecture design by using Compendium, an open source tool for rationale visualization. The preliminary results show that visualization of ADD and its rationale does not increase the total time for reading architecture document (including visualization diagrams of ADDs) plus designing task, and it improves the understanding of architects on existing architecture design with better new design results.

Rationale visualization of software architectural design decision using compendium

The justification for software architectural design decisions made throughout the architecting process is necessary for understanding, (re)using, communicating, and modifying an architecture design. Although there are many existing tools to capture, store, manage, and share the architectural design decisions explicitly, there still remains a need to visualize and explore architectural design decisions and their underlying rationale. This paper investigates how Compendium tool can be employed to visualize architectural design decisions and their rationale, in order to improve the understandability and promote the communication of architectural design decisions.

The Intersection of Continuous Deployment and Architecting Process: Practitioners' Perspectives

Context: Development and Operations (DevOps) is an emerging software industry movement to bridge the gap between software development and operations teams. DevOps supports frequently and reliably releasing new features and products-- thus subsuming Continuous Deployment (CD) practice. Goal: This research aims at empirically exploring the potential impact of CD practice on architecting process. Method: We carried out a case study involving interviews with 16 software practitioners. Results: We have identified (1) a range of recurring architectural challenges (i.e., highly coupled monolithic architecture, team dependencies, and ever-changing operational environments and tools) and (2) five main architectural principles (i.e., small and independent deployment units, not too much focus on reusability, aggregating logs, isolating changes, and testability inside the architecture) that should be considered when an application is (re-) architected for CD practice. This study also supports that software architecture can better support operations if an operations team is engaged at an early stage of software development for taking operational aspects into considerations. Conclusion: These findings provide evidence that software architecture plays a significant role in successfully and efficiently adopting continuous deployment. The findings contribute to establish an evidential body of knowledge about the state of the art of architecting for CD practice

Architecting for DevOps and Continuous Deployment

Development and Operations (DevOps) in the context of Continuous Deployment (CD) have emerged as an attractive software development movement, which tries to establish a strong connection between development and operations teams. CD is defined as the ability to quickly put new releases into production. We believe that DevOps/CD brings new challenges for architects, which considerably impacts both on their (architectural) design decisions and their organizational responsibilities. We assert that there is an important and urgent need of sufficient research work to gain a deep understanding of how DevOps/CD adoption can influence architecting, architectural decision-making processes and their outcomes in an organization. This PhD research is aimed at understanding and addressing new challenges for designing architectures for supporting DevOps in the context of CD.

Do architectural design decisions improve the understanding of software architecture? two controlled experiments

Architectural design decision (ADD) and its design rationale, as a paradigm shift on documenting and enriching architecture design description, is supposed to facilitate the understanding of architecture and the reasoning behind the design rationale, which consequently improves the architecting process and gets better architecture design results. But the lack of empirical evaluation that supports this statement is one of the major reasons that prevent industrial practitioners from using ADDs in their daily architecting activities. In this paper, we conducted two controlled experiments, as a family of experiments, to investigate how presence of ADDs can improve the understanding of architecture. The main results of our experiments are: (i) using ADDs and their rationale in architecture documentation does not affect the time needed for completing architecture design tasks; (ii) one experiment and the family of experiments achieved a significantly better understanding of architecture design when using ADDs; and (iii) with regard to the correctness of architecture understanding, more experienced participants benefited more from ADDs in comparison with less experienced ones.Welcome to the 25th International Conference on Program Comprehension! This silver jubilee has seen several first times for ICPC. It is for the very first time that ICPC has been organised in South America, in Argentina, in Buenos Aires. Moreover, it is also for the first time that the main track of ICPC crossed the line of 80 submissions. This year the program committee has received 83 submissions originating from 97 abstracts and co-authored by researchers from 26 countries from Africa, Asia, Europe, North and South America and Oceania. This is more than double of the 39 submissions received back in 2000.1 Finally, for the very first time in the history of ICPC we have implemented the triple-blind reviewing process: the authors do not know who is reviewing their work (single), the reviewers do not know whose work they review (double), and the reviewers do not know who the other reviewers are (triple).