Notice bibliographique
Résumé
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
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction machine sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Le volet Gemma est une étiquette directe du modèle pour chaque travail de la base, lue sur la notice réduite au titre. Le volet Codex est un classifieur appris des 10 348 étiquettes directes de Codex et calibré sur les taux pondérés de l'échantillon; les champs sans appui suffisant ne portent aucun appel Codex. Le mode candidate est l'union des deux volets; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont pas des étiquettes humaines.
Scores du classifieur distillé par catégorie (deux têtes)
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,004 | 0,023 |
| Méta-épidémiologie (sens strict) | 0,001 | 0,000 |
| Méta-épidémiologie (sens large) | 0,001 | 0,001 |
| Bibliométrie | 0,003 | 0,002 |
| Études des sciences et des technologies | 0,002 | 0,001 |
| Communication savante | 0,008 | 0,005 |
| Science ouverte | 0,003 | 0,003 |
| Intégrité de la recherche | 0,005 | 0,007 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,252 | 0,133 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule source (Gemma direct ou Codex distillé), pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».