Requirements Engineering Quality Revealed through Functional Size Measurement: An Empirical Study in an Agile Context
Pourquoi ce travail est dans la base
Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.
Notice bibliographique
Résumé
Software development organizations applying continuous process improvement, when faced with the limits of qualitative approaches, are looking into quantitative approaches to support decision making, namely for improvement of the software project estimation process. Quantitative approaches include sizing functional requirements with standards such as ISO 19761, known as the COSMIC method. But defects in the requirements may have an impact on the accuracy of the resulting functional size, as well as an impact on the project relative effort sometimes known as the 'productivity rate' and the measurement relative effort. Our research program is investigating the relationship between the attributes of requirements engineering (RE) outputs, the software process relative effort, and the measurement process relative effort. RE outputs studied are requirements and specifications documents and data models. As functional sizing is applied, thorough examination of RE outputs is done, which is likely to lead to identifying quality attributes and related findings. As a case study, this paper reports preliminary results related to the quality of requirements artefacts from a software development organization that is applying the Agile approach to its software development process. The functional size of the software developed through five projects was measured and compared with development effort and measurement effort, taking into account the quality rating of requirements. The results led to recommendations of improvement on the RE process that the organization could deploy in its current and next software projects. This paper also presents a list of functional sizing challenges that the measurer has faced, leading to proposed recommendations for planning any software measurement project.
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.
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,003 | 0,001 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,000 |
| Études des sciences et des technologies | 0,000 | 0,000 |
| Communication savante | 0,000 | 0,002 |
| Science ouverte | 0,001 | 0,000 |
| Intégrité de la recherche | 0,000 | 0,000 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
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écoule