Software Architecture Risk Containers

Our motivation is to determine whether risks such as im- plementation error-proneness can be isolated into three types of con- tainers at design time. This paper identifies several container candidates in other research that fit the risk container concept. Two industrial case studies were used to determine which of three container types tested is most effective at isolating and predicting at design time the risk of im- plementation error-proneness. We found that Design Rule Containers were more effective than Use Case and Resource Containers

Risk Containers – A Help or Hindrance to Practitioners?

Finding problems at the design stage reduces the cost to resolve them. Previous studies have indicated that error-proneness risks can be isolated into risk containers created from architectural designs, to help mitigate such risks early on. Here we describe an ongoing experiment to establish whether presenting designs as a collection of such containers helps practitioners manage the isolated risks. Participants must identify cyclic dependencies that could result in error-proneness and assess the impact of design changes. The emerging results suggest it takes participants longer to locate cyclic dependencies in collections of container diagrams than it does in a single diagram representing the whole design. Participants who reviewed collections of container diagrams tended to identify more cyclic dependencies correctly than those using a single diagram. Although, the results suggest that presenting a design as a collection of containers has no overall bearing on a participant’s ability to correctly identify impacts of design changes, in cases where changes span multiple container diagrams no errors in change impact detection were observed. Errors were observed when assessing the same change using a single diagram representing the whole design

An analysis of techniques and methods for technical debt management: a reflection from the architecture perspective

Technical debt is a metaphor referring to the consequences of weak software development. Managing technical debt is necessary in order to keep it under control, and several techniques have been developed with the goal of accomplishing this. However, available techniques have grown disperse and managers lack guidance. This paper covers this gap by providing a systematic mapping of available techniques and methods for technical debt management, covering architectural debt, and identifying existing gaps that prevent to manage technical debt efficiently

Using Peer Comparison Approaches to Measure Software Stability

Software systems must change to adapt to new functional requirements and new nonfunctional requirements. This is called software revision. However, not all the modules within the system need to be changed during each revision. In this paper, we study how frequently each module is modified. Our study is performed through comparing the stability of peer software modules. The study is performed on six open-source Java projects: Ant, Flow4j, Jena, Lucence, Struct, and Xalan, in which classes are identified as basic software modules. Our study shows (1) about half of the total classes never changed; (2) frequent changes occur to small number of classes; and (3) the number of changed classes between current release and next release has no significant relations with the time duration between current release and next release. Keywords: software evolution; software revision; software stability; class stability; open-source project; Java clas

Towards a Reference Architecture with Modular Design for Large-scale Genotyping and Phenotyping Data Analysis: A Case Study with Image Data

With the rapid advancement of computing technologies, various scientific research communities have been extensively using cloud-based software tools or applications. Cloud-based applications allow users to access software applications from web browsers while relieving them from the installation of any software applications in their desktop environment. For example, Galaxy, GenAP, and iPlant Colaborative are popular cloud-based systems for scientific workflow analysis in the domain of plant Genotyping and Phenotyping. These systems are being used for conducting research, devising new techniques, and sharing the computer assisted analysis results among collaborators. Researchers need to integrate their new workflows/pipelines, tools or techniques with the base system over time. Moreover, large scale data need to be processed within the time-line for more effective analysis. Recently, Big Data technologies are emerging for facilitating large scale data processing with commodity hardware. Among the above-mentioned systems, GenAp is utilizing the Big Data technologies for specific cases only. The structure of such a cloud-based system is highly variable and complex in nature. Software architects and developers need to consider totally different properties and challenges during the development and maintenance phases compared to the traditional business/service oriented systems. Recent studies report that software engineers and data engineers confront challenges to develop analytic tools for supporting large scale and heterogeneous data analysis. Unfortunately, less focus has been given by the software researchers to devise a well-defined methodology and frameworks for flexible design of a cloud system for the Genotyping and Phenotyping domain. To that end, more effective design methodologies and frameworks are an urgent need for cloud based Genotyping and Phenotyping analysis system development that also supports large scale data processing. In our thesis, we conduct a few studies in order to devise a stable reference architecture and modularity model for the software developers and data engineers in the domain of Genotyping and Phenotyping. In the first study, we analyze the architectural changes of existing candidate systems to find out the stability issues. Then, we extract architectural patterns of the candidate systems and propose a conceptual reference architectural model. Finally, we present a case study on the modularity of computation-intensive tasks as an extension of the data-centric development. We show that the data-centric modularity model is at the core of the flexible development of a Genotyping and Phenotyping analysis system. Our proposed model and case study with thousands of images provide a useful knowledge-base for software researchers, developers, and data engineers for cloud based Genotyping and Phenotyping analysis system development