Empirical studies in reverse engineering: state of the art and future trends

Tonella, Paolo; Torchiano, Marco; Bois, Bart Du; Systä, Tarja

doi:10.1007/s10664-007-9037-5

Cited by 76 publications

(35 citation statements)

References 36 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…There are studies arguing the necessity to evaluate new researches in real systems [20,34]. Therefore, we chose to verify the applicability of DCL 2.0 by using a real system and their development team.…”

Section: System Selectionmentioning

confidence: 99%

DCL 2.0: modular and reusable specification of architectural constraints

et al. 2017

View full text Add to dashboard Cite

Background: Due to the abstract nature of software architecture concepts, ensuring the correct implementation of architectural decisions is not a trivial task. Divergences between the planned architecture and source code may occur in the early stages of the software development, which denotes a phenomenon known as software architecture erosion. Architectural conformance checking techniques have been proposed to tackle the problem of divergences between the planned architecture and source code. Among such techniques, we can note the DCL (dependency constraint language), which is a domain-specific language that has interesting results in architectural conformance contexts. However, the current version of DCL has some limitations, such as lack of modularity and low degree of reuse, which may prevent its adoption in real software development scenarios. In this article, we extend DCL with a reusable, modular, and hierarchical specification. Method: We propose and evaluate DCL 2.0-an extension of the original DCL-and its tool in a real-world development scenario of a large system used by a government branch of Minas Gerais, Brazil. Result: We were able to detect 771 architectural violations where 74% of them could only be detected due to the new violation types proposed in DCL 2.0. Conclusion: By using DCL 2.0 herein presented, it was possible to conclude the following: (i) DCL 2.0 proved importance in helping the development team consistently address violations, and (ii) after using DCL 2.0 for months, the number of architectural violations being committed into the system branches was reduced to zero. Therefore, we argue that DCL 2.0 can have a positive impact on the architectural conformance of systems.

show abstract

Section: System Selectionmentioning

confidence: 99%

DCL 2.0: modular and reusable specification of architectural constraints

et al. 2017

View full text Add to dashboard Cite

show abstract

“…), (x) research question type (based on the classification presented by Shaw [11]: method or means of development; method for analysis or evaluation; design, evaluation, or analysis of a particular instance; generalization or characterization; or feasibility study or exploration. ), (xi) empirical research type (based on the classification presented by Tonella et al [13]: experiment, observational study, experience report, case study or systematic review. ), (xii) research validation (based on the classification presented by Shaw [11]: analysis, evaluation, experience, example, persuasion or blatant assertion.…”

Section: E Data Extractionmentioning

confidence: 99%

Ordering the Product Backlog in Agile Software Development Projects: A Systematic Literature Review

Silva¹,

Araújo²,

Barbosa³

et al. 2017

International Conferences on Software Engineering and Knowledge Engineering

View full text Add to dashboard Cite

Abstract-Recently, agile software development methods have attracted the attention of academic and industrial domains. Unlike traditional approaches, agile methods focus on rapid delivery of business value to customers through fast delivery of working code. Therefore, requirement prioritization is considered a crucial process in this context, since there is the need to identify which requirements must be developed first, based on stakeholders preferences and taking into account business and technical challenges such as dependencies of tasks, developers skills, limitation of budget, etc. In Scrum, the most popular agile method, requirement management is done by maintaining the product backlog, which contains the list of functionalities that must be developed. Although some works conducted systematic reviews on the topic of agile requirement engineering, to the best of our knowledge, there is no study that reviewed the specific subject of ordering the product backlog in agile projects. Therefore, in this work, we conducted a Systematic Literature Review of studies on this topic published up to (and including) 2016 through a database search, to identify and analyze factors and techniques used to accomplish the task of ordering the product backlog in agile projects. In total, we evaluated 1556 papers, of which 13 reported on the subject of study.

show abstract

“…When designing and conducting an empirical study in software testing, its positioning in the field should be easily and clearly determined in order to be able to unify and combine results into families of experiments [20] or aggregate the results in secondary studies [1]. This approach demands for the usage of a taxonomy (as [21] calls it) or a hierarchy (as [20] calls it) or a characterisation schema (as [22] calls it) of the techniques, methods and tools under investigation. Given such taxonomy, it becomes possible to interpret the narrow results of a single study in the wider context.…”

Section: B Cases or Treatments -What Is Studied?mentioning

confidence: 99%

A Methodological Framework for Evaluating Software Testing Techniques and Tools

Vos

Marín

Cuaresma

et al. 2012

2012 12th International Conference on Quality Software

View full text Add to dashboard Cite

Such guidelines could be obtained by doing secondary studies on a body of evidence consisting of case studies evaluating and comparing testing techniques and tools. However, such a body of evidence is also lacking. In this paper, we will make a first step towards creating such body of evidence by defining a general methodological evaluation framework that can simplify the design of case studies for comparing software testing tools, and make the results more precise, reliable, and easy to compare. Using this framework, (1) software testing practitioners can more easily define case studies through an instantiation of the framework, (2) results can be better compared since they are all executed according to a similar design, (3) the gap in existing work on methodological evaluation frameworks will be narrowed, and (4) a body of evidence will be initiated. By means of validating the framework, we will present successful applications of this methodological framework to various case studies for evaluating testing tools in an industrial environment with real objects and real subjects.

show abstract

Empirical studies in reverse engineering: state of the art and future trends

Cited by 76 publications

References 36 publications

DCL 2.0: modular and reusable specification of architectural constraints

DCL 2.0: modular and reusable specification of architectural constraints

Ordering the Product Backlog in Agile Software Development Projects: A Systematic Literature Review

A Methodological Framework for Evaluating Software Testing Techniques and Tools

Contact Info

Product

Resources

About