2,221 research outputs found
Experiences from Software Engineering of Large Scale AMR Multiphysics Code Frameworks
Among the present generation of multiphysics HPC simulation codes there are
many that are built upon general infrastructural frameworks. This is especially
true of the codes that make use of structured adaptive mesh refinement (SAMR)
because of unique demands placed on the housekeeping aspects of the code. They
have varying degrees of abstractions between the infrastructure such as mesh
management and IO and the numerics of the physics solvers. In this experience
report we summarize the experiences and lessons learned from two of such major
software efforts, FLASH and Chombo.Comment: Experience Repor
Technical Debt Prioritization: State of the Art. A Systematic Literature Review
Background. Software companies need to manage and refactor Technical Debt
issues. Therefore, it is necessary to understand if and when refactoring
Technical Debt should be prioritized with respect to developing features or
fixing bugs. Objective. The goal of this study is to investigate the existing
body of knowledge in software engineering to understand what Technical Debt
prioritization approaches have been proposed in research and industry. Method.
We conducted a Systematic Literature Review among 384 unique papers published
until 2018, following a consolidated methodology applied in Software
Engineering. We included 38 primary studies. Results. Different approaches have
been proposed for Technical Debt prioritization, all having different goals and
optimizing on different criteria. The proposed measures capture only a small
part of the plethora of factors used to prioritize Technical Debt qualitatively
in practice. We report an impact map of such factors. However, there is a lack
of empirical and validated set of tools. Conclusion. We observed that technical
Debt prioritization research is preliminary and there is no consensus on what
are the important factors and how to measure them. Consequently, we cannot
consider current research conclusive and in this paper, we outline different
directions for necessary future investigations
Human-Centric Program Synthesis
Program synthesis techniques offer significant new capabilities in searching for programs that satisfy high-level specifications. While synthesis has been thoroughly explored for input/output pair specifications (programming-by-example), this paper asks: what does program synthesis look like beyond examples? What actual issues in day-to-day development would stand to benefit the most from synthesis? How can a human-centric perspective inform the exploration of alternative specification languages for synthesis? I sketch a human-centric vision for program synthesis where programmers explore and learn languages and APIs aided by a synthesis tool
Analysis of Software Binaries for Reengineering-Driven Product Line Architecture\^aAn Industrial Case Study
This paper describes a method for the recovering of software architectures
from a set of similar (but unrelated) software products in binary form. One
intention is to drive refactoring into software product lines and combine
architecture recovery with run time binary analysis and existing clustering
methods. Using our runtime binary analysis, we create graphs that capture the
dependencies between different software parts. These are clustered into smaller
component graphs, that group software parts with high interactions into larger
entities. The component graphs serve as a basis for further software product
line work. In this paper, we concentrate on the analysis part of the method and
the graph clustering. We apply the graph clustering method to a real
application in the context of automation / robot configuration software tools.Comment: In Proceedings FMSPLE 2015, arXiv:1504.0301
Microservice Transition and its Granularity Problem: A Systematic Mapping Study
Microservices have gained wide recognition and acceptance in software
industries as an emerging architectural style for autonomic, scalable, and more
reliable computing. The transition to microservices has been highly motivated
by the need for better alignment of technical design decisions with improving
value potentials of architectures. Despite microservices' popularity, research
still lacks disciplined understanding of transition and consensus on the
principles and activities underlying "micro-ing" architectures. In this paper,
we report on a systematic mapping study that consolidates various views,
approaches and activities that commonly assist in the transition to
microservices. The study aims to provide a better understanding of the
transition; it also contributes a working definition of the transition and
technical activities underlying it. We term the transition and technical
activities leading to microservice architectures as microservitization. We then
shed light on a fundamental problem of microservitization: microservice
granularity and reasoning about its adaptation as first-class entities. This
study reviews state-of-the-art and -practice related to reasoning about
microservice granularity; it reviews modelling approaches, aspects considered,
guidelines and processes used to reason about microservice granularity. This
study identifies opportunities for future research and development related to
reasoning about microservice granularity.Comment: 36 pages including references, 6 figures, and 3 table
A Longitudinal Study of Identifying and Paying Down Architectural Debt
Architectural debt is a form of technical debt that derives from the gap
between the architectural design of the system as it "should be" compared to
"as it is". We measured architecture debt in two ways: 1) in terms of
system-wide coupling measures, and 2) in terms of the number and severity of
architectural flaws. In recent work it was shown that the amount of
architectural debt has a huge impact on software maintainability and evolution.
Consequently, detecting and reducing the debt is expected to make software more
amenable to change. This paper reports on a longitudinal study of a healthcare
communications product created by Brightsquid Secure Communications Corp. This
start-up company is facing the typical trade-off problem of desiring
responsiveness to change requests, but wanting to avoid the ever-increasing
effort that the accumulation of quick-and-dirty changes eventually incurs. In
the first stage of the study, we analyzed the status of the "before" system,
which indicated the impacts of change requests. This initial study motivated a
more in-depth analysis of architectural debt. The results of this analysis were
used to motivate a comprehensive refactoring of the software system. The third
phase of the study was a follow-on architectural debt analysis which quantified
the improvements made. Using this quantitative evidence, augmented by
qualitative evidence gathered from in-depth interviews with Brightsquid's
architects, we present lessons learned about the costs and benefits of paying
down architecture debt in practice.Comment: Submitted to ICSE-SEIP 201
Software Engineering for Millennials, by Millennials
Software engineers need to manage both technical and professional skills in
order to be successful. Our university offers a 5.5 year program that mixes
computer science, software and computer engineering, where the first two years
are mostly math and physics courses. As such, our students' first real teamwork
experience is during the introductory SE course, where they modify open source
projects in groups of 6-8. However, students have problems working in such
large teams, and feel that the course material and project are "disconnected".
We decided to redesign this course in 2017, trying to achieve a balance between
theory and practice, and technical and professional skills, with a maximum
course workload of 150 hrs per semester. We share our experience in this paper,
discussing the strategies we used to improve teamwork and help students learn
new technologies in a more autonomous manner. We also discuss what we learned
from the two times we taught the new course.Comment: 8 pages, 9 tables, 4 figures, Second International Workshop on
Software Engineering Education for Millennial
Analyzing the concept of technical debt in the context of agile software development: A systematic literature review
Technical debt (TD) is a metaphor that is used to communicate the
consequences of poor software development practices to non-technical
stakeholders. In recent years, it has gained significant attention in agile
software development (ASD). The purpose of this study is to analyze and
synthesize the state of the art of TD, and its causes, consequences, and
management strategies in the context of ASD. Using a systematic literature
review (SLR), 38 primary studies, out of 346 studies, were identified and
analyzed. We found five research areas of interest related to the literature of
TD in ASD. Among those areas, managing TD in ASD received the highest
attention, followed by architecture in ASD and its relationship with TD. In
addition, eight categories regarding the causes and five categories regarding
the consequences of incurring TD in ASD were identified. Focus on quick
delivery and architectural and design issues were the most popular causes of
incurring TD in ASD. Reduced productivity, system degradation and increased
maintenance cost were identified as significant consequences of incurring TD in
ASD. Additionally, we found 12 strategies for managing TD in the context of
ASD, out of which refactoring and enhancing the visibility of TD were the most
significant. The results of this study provide a structured synthesis of TD and
its management in the context of ASD as well as potential research areas for
further investigation
- …