No abstract

One of the main issues of an agile software project is how to accurately estimate development effort. In 2014, a Systematic Literature Review (SLR) regarding this subject was published. The authors concluded that there were several gaps in the literature, such as the low level of accuracy of the techniques and little consensus on appropriate cost drivers. The goal of our work is to provide an updated review of the state of the art based on this reference SLR work. We applied a Forward Snowballing approach, in which our seed set included the former SLR and its selected papers. We identified a strong indication of solutions based on Artificial Intelligence and Machine Learning methods for effort estimation in Agile Software Development (ASD). We also identified that there is a gap in terms of agreement on suitable cost drivers. Thus, we applied Thematic Analysis in the selected papers and identified a representative set of 10 cost drivers for effort estimation. This updated review of the state of the art resulted in 24 new relevant papers selected.

No abstract

Context-Agile Software Development (ASD) and Reuse-Driven Software Engineering (RDSE) are wellaccepted strategies to improve the efficiency of software processes. A challenge to integrate both approaches is that ASD relies mostly on tacit knowledge, hampering the reuse of software development assets. An opportunity to enable RDSE for ASD is by improving the traceability between user stories (USs), the most used notation to register product requirements in ASD. Having enough link semantics between USs could enable defining similarity between them and, consequently, promote RDSE for ASD. However, this is an open challenge. Objective-To propose a taxonomy for adding link semantics between USs, focusing on easing the task of identifying similar ones. Such links, with support of traceability tools, enable the reuse of USs and their related assets. Method: We constructed a taxonomy for types of US focusing on Web Information Systems. The taxonomy is used to classify the US, given two facets: module and operation. Such information is used to infer the similarity between USs using link rules. We developed the taxonomy based on an empirical analysis of five product backlogs, containing a total of 118 USs. Afterward, we validated the taxonomy in terms of its potential to enable the reuse of US-related assets. First, we executed an offline validation by applying it to classify 530 USs from 26 already ended projects. Finally, we applied the taxonomy in a case study with two ongoing projects (59 USs). Results: The proposed taxonomy for USs is composed of two sub-facets, namely, module and operation, which have, respectively, three and 18 terms. In terms of coverage, for the offline study and case study, we classified 90.17% of the USs with the proposed taxonomy. For the case study, we classified all the USs analyzed. Conclusion: We concluded that it is possible to use our approach to compare USs and, consequently, retrieve their related assets. Our results regarding its practical utility have shown that users considered the taxonomy a useful approach to ease the process of assessing the similarity between user stories.

Context: Software team formation is an important project management activity. However, forming appropriate teams is a challenge for most of the companies. Objective: To analyze and synthesize the state of the art on the software team formation research. Additionally, we aim to organize the identified body of knowledge in software team formation as a taxonomy. Method: Using a Snowballing-based systematic mapping study, 51 primary studies, out of 2516, were identified and analyzed. We classified the studies considering the research methods used, their overall quality, and the characteristics of the formed teams and the proposed solutions. Results: The majority of the studies use search and optimization techniques in their approaches. Also, technical attributes are the most frequent type considered to build individuals' profiles during the team formation process. Furthermore, we proposed a taxonomy on software team formation. Conclusion: There is a predominant use of search-based approaches that combine search and optimization techniques with technical attributes. However, the adoption of non-technical attributes as complementary information is a tendency. Regarding the research gaps, we highlight the level of subjectivity in software team formation and the lack of scalability of the proposed solutions.

No abstract

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.

Estimating API size is a very complex work since no approaches address particularly this development unit. Existing approaches are concentrated in estimating the software as a whole. Since many projects need to estimate API size, analyzing previous development is extremely necessary in order to identify which variables lead the API size and this can bring managers to derive cost and effort from it. This paper presents a case study from a OMA protocol client project where those variables were identified and the correlation and multiple regression techniques were used to find a equation that can predict the size of development of API modules for this specific project in Lines Of Code (LOC) unit size.