Requirements validation is an important aspect for ensuring high quality software. Commonly used are requirements inspections, where the specification is read from different persons assuming different roles or applying different reading techniques, partly accompanied by checklists. Actual defect detection with requirements inspection is costly, and defect detection rates must be considered low. Therefore, repeated validation is used or validation with multiple inspection groups - known as N-fold inspections. However, this does not only yield more defects found, but also more false positives. In this paper, we investigate how defect aggregation can be used to improve the overall quality of validation. Therefore, we conducted an experiment with 22 N-fold inspection groups consisting of four to five reviewers each. Results show that simple aggregation of all results leads to a number of false positives that can actually negatively impact the validation task, while the use of more tailored aggregation strategies can considerably improve the validation of requirements with N-fold inspections.
{"title":"Aggregating N-fold Requirements Inspection Results","authors":"Marian Daun, Jennifer Brings","doi":"10.1145/3593434.3593465","DOIUrl":"https://doi.org/10.1145/3593434.3593465","url":null,"abstract":"Requirements validation is an important aspect for ensuring high quality software. Commonly used are requirements inspections, where the specification is read from different persons assuming different roles or applying different reading techniques, partly accompanied by checklists. Actual defect detection with requirements inspection is costly, and defect detection rates must be considered low. Therefore, repeated validation is used or validation with multiple inspection groups - known as N-fold inspections. However, this does not only yield more defects found, but also more false positives. In this paper, we investigate how defect aggregation can be used to improve the overall quality of validation. Therefore, we conducted an experiment with 22 N-fold inspection groups consisting of four to five reviewers each. Results show that simple aggregation of all results leads to a number of false positives that can actually negatively impact the validation task, while the use of more tailored aggregation strategies can considerably improve the validation of requirements with N-fold inspections.","PeriodicalId":178596,"journal":{"name":"Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering","volume":"6 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2023-06-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125458867","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Muhammad Waqas Qaisar, H. Mujtaba, M. Riaz, Muhammad Shahid, Ahmad Abdul Ghani, M. A. Khan, Kashif Hussain
DC-DC converters are often used in electrical systems to keep the output voltage constant. Boost converters are utilized for a variety of purposes, including regenerative braking of direct current motors, portable device applications, and regulated power supplies. Buck converters, on the other hand, are used in sophisticated communications, data communication, and self-regulating power supplies. One of the most crucial elements in the power conversion process is managing the DC-DC converters. This study aims to find out which nonlinear controller, fuzzy or neural network, works best when the output load or boost converter characteristics change. So, in this, we create a boost converter controller using a fuzzy and neural network. The fuzzy controller for this study's converter employs a standard set of rules, whereas the neural network controller employs two hidden layer networks. MATLAB software is then used to reconstruct both controllers. The simulation results show that the fuzzy logic controller has a very long transient and settling period with no steady-state error in both transient and steady-state situations. On the other hand, the neural network controller has a short transient and settling period with a steady-state error.
{"title":"Comparative Analysis of Fuzzy and Neural Controller for a Boost Converter","authors":"Muhammad Waqas Qaisar, H. Mujtaba, M. Riaz, Muhammad Shahid, Ahmad Abdul Ghani, M. A. Khan, Kashif Hussain","doi":"10.1145/3593434.3594238","DOIUrl":"https://doi.org/10.1145/3593434.3594238","url":null,"abstract":"DC-DC converters are often used in electrical systems to keep the output voltage constant. Boost converters are utilized for a variety of purposes, including regenerative braking of direct current motors, portable device applications, and regulated power supplies. Buck converters, on the other hand, are used in sophisticated communications, data communication, and self-regulating power supplies. One of the most crucial elements in the power conversion process is managing the DC-DC converters. This study aims to find out which nonlinear controller, fuzzy or neural network, works best when the output load or boost converter characteristics change. So, in this, we create a boost converter controller using a fuzzy and neural network. The fuzzy controller for this study's converter employs a standard set of rules, whereas the neural network controller employs two hidden layer networks. MATLAB software is then used to reconstruct both controllers. The simulation results show that the fuzzy logic controller has a very long transient and settling period with no steady-state error in both transient and steady-state situations. On the other hand, the neural network controller has a short transient and settling period with a steady-state error.","PeriodicalId":178596,"journal":{"name":"Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering","volume":"23 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2023-06-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125727854","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
The complexity of delivering enterprise-grade software, especially as-a-service, keeps getting more sophisticated even with the large set of open-source and commercial helper tools. Every single commit by the developers must go through a large group of checks to ensure that it will not break or regress reliability, resiliency, security, compliance, privacy, performance, accessibility, operability, etc. Being a developer or a software architect in such an environment is not a fulfilling role at all. Full stack, as a notion, is not applicable to large-scale systems and enterprise software. We are introducing a new, horizontal, approach called "full-spec software," where each layer of the system is architected, designed, and built with the long list of enterprise readiness attributes listed above. Making full-spec software a reality requires a new organizational construct called "platform engineering."
{"title":"Full Spec Software via Platform Engineering: Transition from Bolting-on to Building-in","authors":"Huseyin Dursun","doi":"10.1145/3593434.3593440","DOIUrl":"https://doi.org/10.1145/3593434.3593440","url":null,"abstract":"The complexity of delivering enterprise-grade software, especially as-a-service, keeps getting more sophisticated even with the large set of open-source and commercial helper tools. Every single commit by the developers must go through a large group of checks to ensure that it will not break or regress reliability, resiliency, security, compliance, privacy, performance, accessibility, operability, etc. Being a developer or a software architect in such an environment is not a fulfilling role at all. Full stack, as a notion, is not applicable to large-scale systems and enterprise software. We are introducing a new, horizontal, approach called \"full-spec software,\" where each layer of the system is architected, designed, and built with the long list of enterprise readiness attributes listed above. Making full-spec software a reality requires a new organizational construct called \"platform engineering.\"","PeriodicalId":178596,"journal":{"name":"Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering","volume":"59 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2023-06-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125105946","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
This paper discusses the challenges in evaluating the quality of conceptual models in educational settings. While automated grading techniques may work for simplistic modeling tasks, realistic modeling tasks that allow for a wide variety of solutions cannot be evaluated using automated techniques. However, the traditional approach of having instructors grade the exercises may not be feasible in larger courses. To address this issue, alternative approaches, such as educating students to assess the quality of their own solutions or using calibrated peer reviews, can be used. Therefore, it is crucial to identify the quality of feedback a student can deliver on their own. As a first step, this paper reports on the results of controlled experiments with 368 participants to investigate factors that influence students’ model comprehension and to identify ways to distinguish good student assessments from bad ones.
{"title":"Investigating Factors Influencing Students’ Assessment of Conceptual Models","authors":"Marian Daun, Jennifer Brings","doi":"10.1145/3593434.3593960","DOIUrl":"https://doi.org/10.1145/3593434.3593960","url":null,"abstract":"This paper discusses the challenges in evaluating the quality of conceptual models in educational settings. While automated grading techniques may work for simplistic modeling tasks, realistic modeling tasks that allow for a wide variety of solutions cannot be evaluated using automated techniques. However, the traditional approach of having instructors grade the exercises may not be feasible in larger courses. To address this issue, alternative approaches, such as educating students to assess the quality of their own solutions or using calibrated peer reviews, can be used. Therefore, it is crucial to identify the quality of feedback a student can deliver on their own. As a first step, this paper reports on the results of controlled experiments with 368 participants to investigate factors that influence students’ model comprehension and to identify ways to distinguish good student assessments from bad ones.","PeriodicalId":178596,"journal":{"name":"Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2023-06-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130461569","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
D. Ribeiro, R. Lima, C. França, A. Souza, I. Silva, Gustavo Pinto
CONTEXT: Self-efficacy is a concept researched in various areas of knowledge that impacts various factors such as performance, satisfaction, and motivation. In Software Engineering, it has mainly been studied in the academic context, presenting results similar to other areas of knowledge. However, it is also important to understand its impact in the industrial context. OBJECTIVE: Therefore, this study aims to understand the impact on the software development context with a focus on understanding the behavioral signs of self-efficacy in software engineers and how self-efficacy can impact the work-day of software engineers. METHOD: A qualitative research was conducted using semi-structured questionnaires with 31 interviewees from a software development company located in Brazil. The interviewees participated in a Bootcamp and were later assigned to software development teams. Thematic analysis was used to analyze the data. RESULTS: In the perception of the interviewees, 21 signs were found that are related to people with high and low self-efficacy. These signs were divided into two dimensions: social and cognitive. Also, 18 situations were found that can lead to an increase or decrease of self-efficacy of software engineers. Finally, 12 factors were mentioned that can impact software development teams. CONCLUSION: This work evidences a set of behavioral signs that can help team leaders to better perceive the self-efficacy of their members. It also presents a set of situations that both leaders and individuals can use to improve their self-efficacy in the development context, and finally, factors that can be impacted by self-efficacy in the software development context are also presented. Finally, this work emphasizes the importance of understanding self-efficacy in the industrial context.
{"title":"Understanding Self-Efficacy in Software Engineering Industry: An Interview study","authors":"D. Ribeiro, R. Lima, C. França, A. Souza, I. Silva, Gustavo Pinto","doi":"10.1145/3593434.3593467","DOIUrl":"https://doi.org/10.1145/3593434.3593467","url":null,"abstract":"CONTEXT: Self-efficacy is a concept researched in various areas of knowledge that impacts various factors such as performance, satisfaction, and motivation. In Software Engineering, it has mainly been studied in the academic context, presenting results similar to other areas of knowledge. However, it is also important to understand its impact in the industrial context. OBJECTIVE: Therefore, this study aims to understand the impact on the software development context with a focus on understanding the behavioral signs of self-efficacy in software engineers and how self-efficacy can impact the work-day of software engineers. METHOD: A qualitative research was conducted using semi-structured questionnaires with 31 interviewees from a software development company located in Brazil. The interviewees participated in a Bootcamp and were later assigned to software development teams. Thematic analysis was used to analyze the data. RESULTS: In the perception of the interviewees, 21 signs were found that are related to people with high and low self-efficacy. These signs were divided into two dimensions: social and cognitive. Also, 18 situations were found that can lead to an increase or decrease of self-efficacy of software engineers. Finally, 12 factors were mentioned that can impact software development teams. CONCLUSION: This work evidences a set of behavioral signs that can help team leaders to better perceive the self-efficacy of their members. It also presents a set of situations that both leaders and individuals can use to improve their self-efficacy in the development context, and finally, factors that can be impacted by self-efficacy in the software development context are also presented. Finally, this work emphasizes the importance of understanding self-efficacy in the industrial context.","PeriodicalId":178596,"journal":{"name":"Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering","volume":"115 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2023-06-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116593124","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
In this study, we assess bug life cycles to identify bottlenecks in the bug tracking processes, and examine the effectiveness of bug tracking system usage practices linked to bug states and state transitions. To achieve this, we examined the bug life cycles of three open-source software projects which use Bugzilla as their bug tracking system. In total, we have analyzed 106.196 bugs gathered from these projects. We started by looking at the temporal and quantitative aspects of these projects’ bug life cycles. After that, we collected data about how bug life cycles differ over time. Finally, we inspected the frequency of reopened and state-looping bugs in these projects. After our analysis, we have deduced that the presented temporal and quantitative analysis of bug life cycles is useful for finding bottlenecks and undesired behaviors in the bug tracking processes. We also inferred that examining the changes in bug life cycles over time can provide insights into how bug tracking practices changed throughout the project’s lifetime, and it can be used as a parameter to assess whether the bug tracking system usage has improved. Lastly, we deducted that analyzing undesired state trails’ frequency provides insights into the performance of bug tracking processes. Based on the insights gained from analyzing bug life cycles with the presented methods, we believe that decision makers can improve their workflow by introducing or removing new states to the bug life cycle and adding new rules and restrictions to their bug tracking process.
{"title":"Analyzing Bug Life Cycles to Derive Practical Insights","authors":"Çağrı Eren, Kerem Şahin, Eray Tüzün","doi":"10.1145/3593434.3593504","DOIUrl":"https://doi.org/10.1145/3593434.3593504","url":null,"abstract":"In this study, we assess bug life cycles to identify bottlenecks in the bug tracking processes, and examine the effectiveness of bug tracking system usage practices linked to bug states and state transitions. To achieve this, we examined the bug life cycles of three open-source software projects which use Bugzilla as their bug tracking system. In total, we have analyzed 106.196 bugs gathered from these projects. We started by looking at the temporal and quantitative aspects of these projects’ bug life cycles. After that, we collected data about how bug life cycles differ over time. Finally, we inspected the frequency of reopened and state-looping bugs in these projects. After our analysis, we have deduced that the presented temporal and quantitative analysis of bug life cycles is useful for finding bottlenecks and undesired behaviors in the bug tracking processes. We also inferred that examining the changes in bug life cycles over time can provide insights into how bug tracking practices changed throughout the project’s lifetime, and it can be used as a parameter to assess whether the bug tracking system usage has improved. Lastly, we deducted that analyzing undesired state trails’ frequency provides insights into the performance of bug tracking processes. Based on the insights gained from analyzing bug life cycles with the presented methods, we believe that decision makers can improve their workflow by introducing or removing new states to the bug life cycle and adding new rules and restrictions to their bug tracking process.","PeriodicalId":178596,"journal":{"name":"Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering","volume":"6 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2023-06-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132910531","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Since internet applications have reached a satisfactory level of maturity, large information systems have been developed to manage and facilitate access to documents. Simultaneously, there was an enormous international effort to digitise documents, enabling access via the internet. This endeavour facilitated the access of researchers to extensive document repositories and libraries, while also aiding companies in organising their documents. Two decades later, these vast databases are reasonably clean and well-organised, although the software used to manage and feed them is gradually becoming obsolete. Therefore, it is imperative to continuously reengineer the software to maintain optimal functionality. Furthermore, after the initial effort to digitise documents and create the initial metadata, it is reasonable to augment the metadata information pertaining to the documents. As such, two necessities are apparent: improving support for reengineering legacy document information systems and enabling data model updates and schema evolution to accommodate new information. Our goal is to automate the reengineering process as a whole.
{"title":"Reengineering legacy document information systems: Challenges and solutions","authors":"Delfina Ramos-Vidal","doi":"10.1145/3593434.3593436","DOIUrl":"https://doi.org/10.1145/3593434.3593436","url":null,"abstract":"Since internet applications have reached a satisfactory level of maturity, large information systems have been developed to manage and facilitate access to documents. Simultaneously, there was an enormous international effort to digitise documents, enabling access via the internet. This endeavour facilitated the access of researchers to extensive document repositories and libraries, while also aiding companies in organising their documents. Two decades later, these vast databases are reasonably clean and well-organised, although the software used to manage and feed them is gradually becoming obsolete. Therefore, it is imperative to continuously reengineer the software to maintain optimal functionality. Furthermore, after the initial effort to digitise documents and create the initial metadata, it is reasonable to augment the metadata information pertaining to the documents. As such, two necessities are apparent: improving support for reengineering legacy document information systems and enabling data model updates and schema evolution to accommodate new information. Our goal is to automate the reengineering process as a whole.","PeriodicalId":178596,"journal":{"name":"Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering","volume":"233 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2023-06-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132050445","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Explainability is an emerging quality aspect of software systems. Explanations offer a solution approach for achieving a variety of quality goals, such as transparency and user satisfaction. Therefore, explainability should be considered a means to an end. The evaluation of quality aspects is essential for successful software development. Evaluating explainability allows an assessment of the quality of explanations and enables the comparison of different explanation variants. As the evaluation depends on what quality goals the explanations are supposed to achieve, evaluating explainability is non-trivial. To address this problem, we combine the already well-established method of expert evaluation with goal-oriented heuristics. Goal-oriented heuristics are heuristics that are grouped with respect to the goals that the explanations are meant to achieve. By establishing appropriate goal-oriented heuristics, software engineers are enabled to evaluate explanations and identify problems with affordable resources. To show that this way of evaluating explainability is suitable, we conducted an interactive user study, using a high-fidelity software prototype. The results suggest that the alignment of heuristics with specific goals can enable an effective assessment of explainability.
{"title":"A Means to what End? Evaluating the Explainability of Software Systems using Goal-Oriented Heuristics","authors":"Hannah Deters, Jakob Droste, K. Schneider","doi":"10.1145/3593434.3593444","DOIUrl":"https://doi.org/10.1145/3593434.3593444","url":null,"abstract":"Explainability is an emerging quality aspect of software systems. Explanations offer a solution approach for achieving a variety of quality goals, such as transparency and user satisfaction. Therefore, explainability should be considered a means to an end. The evaluation of quality aspects is essential for successful software development. Evaluating explainability allows an assessment of the quality of explanations and enables the comparison of different explanation variants. As the evaluation depends on what quality goals the explanations are supposed to achieve, evaluating explainability is non-trivial. To address this problem, we combine the already well-established method of expert evaluation with goal-oriented heuristics. Goal-oriented heuristics are heuristics that are grouped with respect to the goals that the explanations are meant to achieve. By establishing appropriate goal-oriented heuristics, software engineers are enabled to evaluate explanations and identify problems with affordable resources. To show that this way of evaluating explainability is suitable, we conducted an interactive user study, using a high-fidelity software prototype. The results suggest that the alignment of heuristics with specific goals can enable an effective assessment of explainability.","PeriodicalId":178596,"journal":{"name":"Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering","volume":"23 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2023-06-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132518131","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Requirements Engineering (RE) and Software Testing (ST) phases are essential to software development. Acknowledging the emergence of cognitive biases, systematic divergences from optimum decision-making, is crucial in software development because of the extensive human participation in various roles. How information is presented can impact decision-making, known as the framing effect—a cognitive bias. The framing effect hinders creativity in software design during the requirements phase. This cognitive effect may further lead to another bias —confirmation bias— in ST. Confirmation bias in ST is testing requirements-consistent behaviors instead of requirements-inconsistent ones. This research explores the effects of framing software requirements on the manifestation of confirmation bias during testing. Additionally, the work aims to propose mitigation strategies, referred to as debiasing, for framing and confirmation bias in the context of ST. This work employs both quantitative and qualitative empirical methods to address its aims. Hence, this research will explore the relation between the framing of requirements and the confirmation bias during ST. Furthermore, this research will also develop debiasing techniques to mitigate the negative effects of these biases to improve software quality.
{"title":"Investigating the Relation between Requirements Framing and Confirmation Bias in Testing","authors":"Afsarah Jahin","doi":"10.1145/3593434.3593447","DOIUrl":"https://doi.org/10.1145/3593434.3593447","url":null,"abstract":"Requirements Engineering (RE) and Software Testing (ST) phases are essential to software development. Acknowledging the emergence of cognitive biases, systematic divergences from optimum decision-making, is crucial in software development because of the extensive human participation in various roles. How information is presented can impact decision-making, known as the framing effect—a cognitive bias. The framing effect hinders creativity in software design during the requirements phase. This cognitive effect may further lead to another bias —confirmation bias— in ST. Confirmation bias in ST is testing requirements-consistent behaviors instead of requirements-inconsistent ones. This research explores the effects of framing software requirements on the manifestation of confirmation bias during testing. Additionally, the work aims to propose mitigation strategies, referred to as debiasing, for framing and confirmation bias in the context of ST. This work employs both quantitative and qualitative empirical methods to address its aims. Hence, this research will explore the relation between the framing of requirements and the confirmation bias during ST. Furthermore, this research will also develop debiasing techniques to mitigate the negative effects of these biases to improve software quality.","PeriodicalId":178596,"journal":{"name":"Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering","volume":"92 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2023-06-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133909990","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Agile teams measure their velocity for performance, based on Story Points. However, such velocity does not allow predicting when the product will be finished. Story points measure effort only. They do not discriminate between creating functionality and other tasks. Non-functional requirements, such as agreeing with stakeholders, designing, testing, or documenting, consume effort but do not add functionality. Thus, it remains unclear whether the product makes any progress, or the team is just looping around technical debt and unclear requirements. Euro Project Office has therefore developed a method how to complement a product backlog by functional size, indicating progress and completeness in unambiguous terms. The method is based on the international standard ISO/IEC 14143 [1] and ISO/IEC 19761 [2]. Tools are available as open source and can be used by development teams with minimum investment into training. Aim of This Tutorial: This tutorial teaches participants how to set up a model of the software under development according to ISO/IEC 19761, using an open-source Excel-based tool, and how to measure function size during several sprints. Participants are expected to have experience with agile software development but need no previous knowledge of the standards mentioned above.
{"title":"Functional Size Measurement in Agile Development: Velocity in Agile Sprints","authors":"Thomas Fehlmann, Andrea Gelli","doi":"10.1145/3593434.3593479","DOIUrl":"https://doi.org/10.1145/3593434.3593479","url":null,"abstract":"Agile teams measure their velocity for performance, based on Story Points. However, such velocity does not allow predicting when the product will be finished. Story points measure effort only. They do not discriminate between creating functionality and other tasks. Non-functional requirements, such as agreeing with stakeholders, designing, testing, or documenting, consume effort but do not add functionality. Thus, it remains unclear whether the product makes any progress, or the team is just looping around technical debt and unclear requirements. Euro Project Office has therefore developed a method how to complement a product backlog by functional size, indicating progress and completeness in unambiguous terms. The method is based on the international standard ISO/IEC 14143 [1] and ISO/IEC 19761 [2]. Tools are available as open source and can be used by development teams with minimum investment into training. Aim of This Tutorial: This tutorial teaches participants how to set up a model of the software under development according to ISO/IEC 19761, using an open-source Excel-based tool, and how to measure function size during several sprints. Participants are expected to have experience with agile software development but need no previous knowledge of the standards mentioned above.","PeriodicalId":178596,"journal":{"name":"Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering","volume":"22 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2023-06-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125482171","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：