Search

Background: Coding guidelines can be contradictory despite their intention of providing a universal perspective on source code quality. For instance, five attributes (code size, semantic complexity, internal documentation, layout style, and identifier length) out of 13 presented contradictions regarding their influence (positive or negative) on the source code readability and comprehensibility. Aims: To investigate source code attributes and their influence on readability and comprehensibility. Method: A literature review was used to identify source code attributes impacting the source code reading and comprehension, and an empirical study was performed to support the assessment of four attributes that presented empirical contradictions in the technical literature. Results: Regardless participants’ experience; all participants showed more positive comprehensibility perceptions for Python snippets with more lines of code. However, their readability perceptions regarding code size were contradictory. The less experienced participants preferred more lines of code while the more experienced ones preferred fewer lines of code. Long and complete-word identifiers presented better readability and comprehensibility according to both novices and experts. Comments contribute to better comprehension. Furthermore, four indentation spaces dominated the code reading preference. Conclusions: Coding guidelines contradictions still demand further investigation to provide indications on possible confounding factors explaining some of the inconclusive results.

Cada vez es más frecuente que proyectos de investigación relacionados con software involucren diferentes organizaciones (grupos de investigación, empresas, etc.) repartidos por todo el mundo. Esta distribución geográfica implica que para el desarrollo y la gestión de estos proyectos de investigación se debe asumir un adecuado método de investigación de Ingeniería del Software que satisfaga los compromisos adquiridos, así como los desafíos adicionales que puedan surgir. En este sentido, el presente artículo analiza cómo el método de investigación cualitativo investigación-acción puede ser adecuado para gestionar y desarrollar proyectos de investigación distribuidos en el campo de ingeniería de software. Además, se propone una estrategia para orientar el uso del método de investigación-acción en el marco de proyectos de investigación realizados de manera distribuida. También se muestra en este artículo la aplicación de la estrategia propuesta en un proyecto de investigación que involucró más de 10 empresas y 27 grupos de investigación de 13 países de Iberoamérica. Se ha observado que el uso de esta estrategia proporcionó a los gestores de investigación: (i) una adecuada administración centralizada del proyecto de investigación, y (ii) una apropiada coordinación y reparto de las responsabilidades de investigación para la construcción y validación de los productos de investigación. Es importante resaltar que la estrategia propuesta es una nueva forma de aplicar el método de investigación-acción en Ingeniería de Software.

CONTEXT: Despite the possible lack of validity when compared with other science areas, Simulation-Based Studies (SBS) in Software Engineering (SE) have supported the achievement of some results in the field. However, as it happens with any other sort of experimental study, it is important to identify and deal with threats to validity aiming at increasing their strength and reinforcing results confidence. OBJECTIVE: To identify potential threats to SBS validity in SE and suggest ways to mitigate them. METHOD: To apply qualitative analysis in a dataset resulted from the aggregation of data from a quasi-systematic literature review combined with ad-hoc surveyed information regarding other science areas. RESULTS: The analysis of data extracted from 15 technical papers allowed the identification and classification of 28 different threats to validity concerned with SBS in SE according Cook and Campbell’s categories. Besides, 12 verification and validation procedures applicable to SBS were also analyzed and organized due to their ability to detect these threats to validity. These results were used to make available an improved set of guidelines regarding the planning and reporting of SBS in SE. CONCLUSIONS: Simulation based studies add different threats to validity when compared with traditional studies. They are not well observed and therefore, it is not easy to identify and mitigate all of them without explicit guidance, as the one depicted in this paper.

Context: It is believed that agility in software processes can bring benefits to software development and lead to an economy of efforts when accommodating changes is needed. Objective: Assess pertinence and relevance of agility characteristics and agile practices for software processes. Method: From 18 agility characteristics and 17 agile practices applicable to software processes revealed through systematic literature reviews performed in 2010, a survey was conducted to assess their pertinence and relevance. Results: 16 agility characteristics and 15 agile practices were considered pertinent to insert agility in software processes. Conclusion: Results should be used sparingly. It would be interesting to replicate the study in other contexts, with different subjects, and compare them, to increase the generalization of their results.

CONTEXT: Simulation-based studies have been used in different research areas in order to conduct computerized experiments with distinct purposes. However, it seems that Software Engineering simulation studies have been performed in a non-systematic way, using ad-hoc experimental design and analysis procedures, i.e., without defining a research protocol and missing information when reporting results. OBJECTIVE: To characterize simulation-based studies and identify the common simulation strategies in Software Engineering. METHOD: To undertake a quasi-Systematic Review. Three online digital libraries (Scopus, Ei Compendex, and Web of Science) are used as sources of information. Information extraction from the primary studies should be captured using a predefined form. Plotted charts and tables should be used together with quantitative/qualitative approaches when possible to support data analysis. RESULTS: From 946 papers, 108 have been included, from which it is possible to identify 19 simulation approaches, 17 domains, 28 simulation models characteristics, 22 output analysis instruments, and 9 procedures for the verification and validation of simulation models in the Software Engineering context. Most dominant approach is System Dynamics in the Software Project Management domain. Replication is not a common behaviour. CONCLUSION: The lack of information regarding most of the simulation-based studies and their models restricts replication, making the results usually specifics and generalization hard. Apart from that, it compromises validity confidence. More research and discussions should be made by the community to increase the reliability and use of simulation-based studies in Software Engineering.

Dependency cycles among components (classes) represent a practical challenge when identifying the class integration order in object-oriented software testing. Classical approaches, such as “top-down” or “bottom-up” integration (or their combination) become less useful due to their acyclic characteristics. Some OO integration testing strategies explore the principle of breaking these dependency cycles, but broken dependencies imply that the target class will have to be stubbed when integrating and testing the source class, which increases the testing effort. This paper describes an integration testing strategy that guides software engineers to identify the class integration order with the minimum number of implemented stubs. This strategy can be directly applied to high level OO design (UML class) diagrams allowing the reduction of extra construction efforts related to additional classes needed in other strategies. The results from experimental studies have indicated its feasibility and effectiveness. The use of such integration testing strategy can be supported by a case tool, also described in this paper.