Why this work is in the frame
A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.
Bibliographic record
Abstract
Recently, there has been an interest in finding ways to combine reuse and customization as practiced in software product line engineering with concepts like iterative development and minimalism as preached by agile methods. This special issue presents cutting-edge research in the area of agile product line engineering. For the past few decades, the software community has put forward numerous efforts to lower the cost of software development, shorten the time-to-market of software products, and improve quality. Software product line engineering is one paradigm that aims to achieve these goals by means of systematic reuse and customization. In a software product line, similar software systems in a given domain are built using a library of core assets (typically developed in a phase called domain engineering). These assets can then be tailored to satisfy customer-specific needs (typically in a phase called application engineering). Another popular approach to achieve rapid delivery of software with minimal overhead is agile software development. Agile development promotes fast delivery of working software over a series of iterations, and it preaches concepts of simplicity and minimalism to cut waste (e.g. lengthy documentation, extensive modeling, and process definitions). Recently, there has been an interest in finding synergies between software product line engineering and agile software development in order to amplify production capabilities even further. This special issue presents the recent research in this direction. For this special issue, a call for papers was announced during the second XP workshop on agile product line engineering. The workshop was co-located with the 11th International Conference on Agile Software Development (XP2010) in Norway. Six submissions were received. For each submission, reviews were solicited from at least two independent reviewers. After two rounds of reviews, four articles were selected to be included in this issue. Two of the articles describe case studies conducted in software companies, while the other two are systematic reviews with different foci. The article by Jan Bosch and Petra M. Bosch-Sijtsema ‘Introducing agile customer-centered development in a legacy software product line’ discusses software product lines and agile methods in light of the issues associated with large-scale software development such as high coordination overhead, slow release cycles, and increasing error density. The authors present a case study of a Fortune 1000 company that delivers mostly finance and accounting software solutions. The company owns a product line that is the market leader in its domain in the U.S. with a market share of around 75%. In the article, the authors report on 14 semi-structured interviews that were conducted in the company to collect data on the challenges the company had faced with their original product line approach. The interviews covered discussions on the old and the new processes and the change towards the new process. The interviews along with other collected data were systematically coded, labeled and categorized over a number of iterations. The data revealed four main challenges, namely: the lack of customer feedback, heavyweight processes, inefficient utilization of resources, and low engagement of team members. The authors proposed a new approach to address these challenges. The approach used elements from design thinking, agile software development, and self-organizing teams. The results of adopting the new approach demonstrated improved customer involvement throughout the development process, reduced process overhead through the transition from component teams to feature teams, more efficient use of resources by enabling personnel to work in parallel, and increased team autonomy and motivation. Geir K. Hanssen's article ‘Agile Software Product Line Engineering: Enabling Factors’ reports the results of an extensive industrial case study to identify and understand enabling factors of a successful, agile product line engineering process. The case study is conducted with a medium-sized company that employs about 260 people, including over 60 developers, with offices across Eurasia and the U.S.A. The company's product line consists of several main modules that together support a business value chain of planning, data collection, data analysis, and reporting of results. The modularity allows many configurations; the product line can be varied in several ways: variability in task, application domain, feature richness, operations. The company adopted the agile method Evo in order to respond quickly to customers' needs. This study collects and analyzes data from semi-structured interviews of key stakeholders, planning and development documents, and customer presentations and meetings about the process and product. The data for the case study were summarized in a report containing the process components (roles, activities, and artifacts) in addition to the definitions of the concepts that emerged. Internal relationships between data, for example the role of external stakeholders in the product innovation process and relationships to previous studies were also explored. The results of the study highlight two important changes brought about in the adoption of an agile approach. The first is the overall simplification of processes and organization; the second is the close engagement of customers, in both planning and development. The limitations of the study are also systematically discussed, which include that the results are for a single case study; the data collected in interviews are subject to bias; and the data collected are from a small sample of employees working on one project at one company. The study concludes that a combined process is feasible. The simplified approach makes the organization more flexible and, as a result, more capable of serving a volatile market with fast-changing technologies. The article by Ivonei Freitas da Silva, Paulo Anselmo da Mota Silveira Neto, P'adraig O'Leary, Eduardo Santana de Almeida, and Silvio Romero de Lemos Meira ‘Agile Software Product Lines: A Systematic Mapping Study’ provides a valuable insight into the research area of combining agile software development and software product line engineering. The study aims to reach an understanding of the different research philosophies underlying the integration of the two software paradigms, and identify potential opportunities and open problems pertaining to this integration. In order to achieve this goal, researchers conducted a systematic literature review to search for relevant data (i.e. papers in the literature on agile software product lines) and filter this data according to the defined scope. Then, a systematic mapping approach was used to categorize and analyze the filtered set of 32 studies. The researchers examined the studies in light of agile principles and methods on one side and software product line practice areas on the other side. The study revealed issues in the reviewed literature such as the lack of an explicit mention of which agile principles were used to achieve a particular integration, the dominance of certain agile methods in the integration proposals such as XP and SCRUM, and the lack of experience reports on the application of an agile software product line practice. The article by Jessica Díaz, Jennifer Pérez, Pedro P. Alarcón, and Juan Garbajosa ‘Agile Product Line Engineering—A Systematic Literature Review’ is another systematic literature review in this special issue but with a different set of research questions. The researchers started with an initial set of 370 unduplicated studies and applied a number of filters (such as inclusion and exclusion criteria and a relevancy and quality assessment) to reduce this set. The 39 selected studies were then analyzed in light of the defined objectives and research questions. In their article, the authors mainly investigate the reasons driving attempts to combine agile methods and software product line engineering. The researchers look at the subject matter using two different lenses, one for domain engineering and another for application engineering. They survey research efforts that address activities in each of these stages, and list open questions and challenges that still need further investigation. Moreover, the authors also looked at integration attempts in industrial contexts to draw conclusions about the experiences reported so far. Based on the findings, the article suggests that applying agile methods in the application engineering phase seems to be feasible. On the other hand, applying agile methods in the domain engineering phase is more difficult, and the available literature does not sufficiently address this issue. The findings also highlight the importance of using business objectives to identify the right level of agility needed in a given product line. In conclusion, the guest editors of this special issue would like to thank the authors for submitting their work to this issue and for their patience and cooperation throughout the review process. They also thank the reviewers for taking the time to review the manuscripts and provide valuable feedback to the authors.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.001 | 0.067 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.000 | 0.000 |
| Science and technology studies | 0.000 | 0.000 |
| Scholarly communication | 0.000 | 0.003 |
| Open science | 0.002 | 0.001 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it