2,085 research outputs found
Data Management in Microservices: State of the Practice, Challenges, and Research Directions
We are recently witnessing an increased adoption of microservice
architectures by the industry for achieving scalability by functional
decomposition, fault-tolerance by deployment of small and independent services,
and polyglot persistence by the adoption of different database technologies
specific to the needs of each service. Despite the accelerating industrial
adoption and the extensive research on microservices, there is a lack of
thorough investigation on the state of the practice and the major challenges
faced by practitioners with regard to data management. To bridge this gap, this
paper presents a detailed investigation of data management in microservices.
Our exploratory study is based on the following methodology: we conducted a
systematic literature review of articles reporting the adoption of
microservices in industry, where more than 300 articles were filtered down to
11 representative studies; we analyzed a set of 9 popular open-source
microservice-based applications, selected out of more than 20 open-source
projects; furthermore, to strengthen our evidence, we conducted an online
survey that we then used to cross-validate the findings of the previous steps
with the perceptions and experiences of over 120 practitioners and researchers.
Through this process, we were able to categorize the state of practice and
reveal several principled challenges that cannot be solved by software
engineering practices, but rather need system-level support to alleviate the
burden of practitioners. Based on the observations we also identified a series
of research directions to achieve this goal. Fundamentally, novel database
systems and data management tools that support isolation for microservices,
which include fault isolation, performance isolation, data ownership, and
independent schema evolution across microservices must be built to address the
needs of this growing architectural style
Assessing the Use of AutoML for Data-Driven Software Engineering
Background. Due to the widespread adoption of Artificial Intelligence (AI)
and Machine Learning (ML) for building software applications, companies are
struggling to recruit employees with a deep understanding of such technologies.
In this scenario, AutoML is soaring as a promising solution to fill the AI/ML
skills gap since it promises to automate the building of end-to-end AI/ML
pipelines that would normally be engineered by specialized team members. Aims.
Despite the growing interest and high expectations, there is a dearth of
information about the extent to which AutoML is currently adopted by teams
developing AI/ML-enabled systems and how it is perceived by practitioners and
researchers. Method. To fill these gaps, in this paper, we present a
mixed-method study comprising a benchmark of 12 end-to-end AutoML tools on two
SE datasets and a user survey with follow-up interviews to further our
understanding of AutoML adoption and perception. Results. We found that AutoML
solutions can generate models that outperform those trained and optimized by
researchers to perform classification tasks in the SE domain. Also, our
findings show that the currently available AutoML solutions do not live up to
their names as they do not equally support automation across the stages of the
ML development workflow and for all the team members. Conclusions. We derive
insights to inform the SE research community on how AutoML can facilitate their
activities and tool builders on how to design the next generation of AutoML
technologies
Supporting Defect Causal Analysis in Practice with Cross-Company Data on Causes of Requirements Engineering Problems
[Context] Defect Causal Analysis (DCA) represents an efficient practice to
improve software processes. While knowledge on cause-effect relations is
helpful to support DCA, collecting cause-effect data may require significant
effort and time. [Goal] We propose and evaluate a new DCA approach that uses
cross-company data to support the practical application of DCA. [Method] We
collected cross-company data on causes of requirements engineering problems
from 74 Brazilian organizations and built a Bayesian network. Our DCA approach
uses the diagnostic inference of the Bayesian network to support DCA sessions.
We evaluated our approach by applying a model for technology transfer to
industry and conducted three consecutive evaluations: (i) in academia, (ii)
with industry representatives of the Fraunhofer Project Center at UFBA, and
(iii) in an industrial case study at the Brazilian National Development Bank
(BNDES). [Results] We received positive feedback in all three evaluations and
the cross-company data was considered helpful for determining main causes.
[Conclusions] Our results strengthen our confidence in that supporting DCA with
cross-company data is promising and should be further investigated.Comment: 10 pages, 8 figures, accepted for the 39th International Conference
on Software Engineering (ICSE'17
An Efficient Approach for Reviewing Security-Related Aspects in Agile Requirements Specifications of Web Applications
Defects in requirements specifications can have severe consequences during
the software development lifecycle. Some of them may result in poor product
quality and/or time and budget overruns due to incorrect or missing quality
characteristics, such as security. This characteristic requires special
attention in web applications because they have become a target for
manipulating sensible data. Several concerns make security difficult to deal
with. For instance, security requirements are often misunderstood and
improperly specified due to lack of security expertise and emphasis on security
during early stages of software development. This often leads to unspecified or
ill-defined security-related aspects. These concerns become even more
challenging in agile contexts, where lightweight documentation is typically
produced. To tackle this problem, we designed an approach for reviewing
security-related aspects in agile requirements specifications of web
applications. Our proposal considers user stories and security specifications
as inputs and relates those user stories to security properties via Natural
Language Processing. Based on the related security properties, our approach
identifies high-level security requirements from the Open Web Application
Security Project (OWASP) to be verified, and generates a reading technique to
support reviewers in detecting defects. We evaluate our approach via three
experiment trials conducted with 56 novice software engineers, measuring
effectiveness, efficiency, usefulness, and ease of use. We compare our approach
against using: (1) the OWASP high-level security requirements, and (2) a
perspective-based approach as proposed in contemporary state of the art. The
results strengthen our confidence that using our approach has a positive impact
(with large effect size) on the performance of inspectors in terms of
effectiveness and efficiency.Comment: Preprint accepted for publication at the Requirements Engineering
journal. arXiv admin note: text overlap with arXiv:1906.1143
Guidelines for the Search Strategy to Update Systematic Literature Reviews in Software Engineering
Context: Systematic Literature Reviews (SLRs) have been adopted within
Software Engineering (SE) for more than a decade to provide meaningful
summaries of evidence on several topics. Many of these SLRs are now potentially
not fully up-to-date, and there are no standard proposals on how to update SLRs
in SE. Objective: The objective of this paper is to propose guidelines on how
to best search for evidence when updating SLRs in SE, and to evaluate these
guidelines using an SLR that was not employed during the formulation of the
guidelines. Method: To propose our guidelines, we compare and discuss outcomes
from applying different search strategies to identify primary studies in a
published SLR, an SLR update, and two replications in the area of effort
estimation. These guidelines are then evaluated using an SLR in the area of
software ecosystems, its update and a replication. Results: The use of a single
iteration forward snowballing with Google Scholar, and employing as a seed set
the original SLR and its primary studies is the most cost-effective way to
search for new evidence when updating SLRs. Furthermore, the importance of
having more than one researcher involved in the selection of papers when
applying the inclusion and exclusion criteria is highlighted through the
results. Conclusions: Our proposed guidelines formulated based upon an effort
estimation SLR, its update and two replications, were supported when using an
SLR in the area of software ecosystems, its update and a replication.
Therefore, we put forward that our guidelines ought to be adopted for updating
SLRs in SE.Comment: Author version of manuscript accepted for publication at the
Information and Software Technology Journa
Lessons Learned to Improve the UX Practices in Agile Projects Involving Data Science and Process Automation
Context: User-Centered Design and Agile methodologies focus on human issues.
Nevertheless, agile methodologies focus on contact with contracting customers
and generating value for them. Usually, the communication between end users and
the agile team is mediated by customers. However, they do not know the problems
end users face in their routines. Hence, UX issues are typically identified
only after the implementation, during user testing and validation. Objective:
Aiming to improve the understanding and definition of the problem in agile
projects, this research investigates the practices and difficulties experienced
by agile teams during the development of data science and process automation
projects. Also, we analyze the benefits and the teams' perceptions regarding
user participation in these projects. Method: We collected data from four agile
teams in an academia-industry collaboration focusing on delivering data science
and process automation solutions. Therefore, we applied a carefully designed
questionnaire answered by developers, scrum masters, and UX designers. In
total, 18 subjects answered the questionnaire. Results: From the results, we
identify practices used by the teams to define and understand the problem and
to represent the solution. The practices most often used are prototypes and
meetings with stakeholders. Another practice that helped the team to understand
the problem was using Lean Inceptions. Also, our results present some specific
issues regarding data science projects. Conclusion: We observed that end-user
participation can be critical to understanding and defining the problem. They
help to define elements of the domain and barriers in the implementation. We
identified a need for approaches that facilitate user-team communication in
data science projects and the need for more detailed requirements
representations to support data science solutions
Impostor Phenomenon in Software Engineers
The Impostor Phenomenon (IP) is widely discussed in Science, Technology,
Engineering, and Mathematics (STEM) and has been evaluated in Computer Science
students. However, formal research on IP in software engineers has yet to be
conducted, although its impacts may lead to mental disorders such as depression
and burnout. This study describes a survey that investigates the extent of
impostor feelings in software engineers, considering aspects such as gender,
race/ethnicity, and roles. Furthermore, we investigate the influence of IP on
their perceived productivity. The survey instrument was designed using a
theory-driven approach and included demographic questions, an internationally
validated IP scale, and questions for measuring perceived productivity based on
the SPACE framework constructs. The survey was sent to companies operating in
various business sectors. Data analysis used bootstrapping with resampling to
calculate confidence intervals and Mann-Whitney statistical significance
testing for assessing the hypotheses. We received responses from 624 software
engineers from 26 countries. The bootstrapping results reveal that a proportion
of 52.7% of software engineers experience frequent to intense levels of IP and
that women suffer at a significantly higher proportion (60.6%) than men
(48.8%). Regarding race/ethnicity, we observed more frequent impostor feelings
in Asian (67.9%) and Black (65.1%) than in White (50.0%) software engineers. We
also observed that the presence of IP is less common among individuals who are
married and have children. Moreover, the prevalence of IP showed a
statistically significant negative effect on the perceived productivity for all
SPACE framework constructs. The evidence relating IP to software engineers
provides a starting point to help organizations find ways to raise awareness of
the problem and improve the emotional skills of software professionals.Comment: Preprint with the original submission accepted for publication at
ICSE-SEIS 202
- …