# Integrating Interactive Detection of Code Smells into Scrum: Feasibility, Benefits, and Challenges
## 6 Online Validation: Insights from a Controlled Experiment
### Conduction  
Teams of participants performed experimental tasks associated with developing a software project using the Java language. In the context of this study, each team was tasked with developing a web system to simulate a bookstore domain. This system was chosen for its simplicity and ability to be developed within the experiment's timeframe. The system allowed book registration, editing, deletion, book filtering, database integration, user registration and profile editing, authentication, and user-specific profile editing. The development process utilized the Java language and the Spring framework for guidance. The experimental tasks were divided into control and experimental groups, with control teams using the proposed approach integrating ID into Scrum, and experimental teams using Scrum. The teams were balanced regarding experience and background to avoid biases in the experimental results. Each of the eight teams consisted of three students randomly selected to perform the activities. To evaluate the results associated with the experimental activities, an \"oracle\" representing the list of code smells that truly represent maintainability issues in the system was obtained. Three activities were performed to generate the oracle: (i) the codes were analyzed using the JSpirit tool [39] to obtain software quality metrics, (ii) these metrics were used to automatically identify code smells based on predefined limits, and (iii) the identified instances were manually inspected and validated by two expert researchers in code smell detection. It is worth mentioning that eight distinct oracles were generated at the end of each experiment iteration. The execution environment for the experimental tasks, including files and tool support, was made available to the participant teams. Additionally, the experimental tasks were supervised by two researchers. The total duration of the experiment was 45 days, with two deliveries made during this period (i.e., one at the end of the second and third Sprint). For each delivery, a set of requirements and planned functionalities were defined. Moreover, the experiment was organized into three phases as described below. Phase 1: Pre-Experiment. The purpose of this phase was to prepare the participants for the subsequent experimental activities, ensuring they had the necessary knowledge about the types of smells to be identified and familiarity with the ID and NID techniques provided by the Eclipse ConCAD tool. Initially, all participant teams received material containing the definitions of 10 types of smells supported by the Eclipse ConCAD tool along with illustrative examples of each type. Participants were given a maximum of 20 min to understand these definitions. They then underwent detailed training on the code smell detection techniques provided by the Eclipse ConCAD tool, and the proposed approach that integrates ID into a Scrum (Section 4). Finally, all participants were invited to complete a questionnaire to collect relevant information, such as their software development experience, prior knowledge of code Smell detection, and familiarity with the Eclipse IDE. Phase 2: Software Development and Smell Detection. In this phase, the 24 participants were divided into eight teams to develop a web system using the Java language. In addition to implementing the system's functionalities, the participants were also required to identify and catalog 10 different types of code smells throughout the experiment. Half of the participant teams used the proposed approach integrating ID into a Scrum, while the other half used only the Scrum framework without disciplined ID support. The teamshad to develop the web system over three 15-day Sprints. At the end of the second and third Sprints, each team provided a list containing information on the total number of true positives (TP), false positives (FP), and false negatives (FN). The detection results were analyzed only after the experiment's conclusion to prevent the learning effect from introducing biases.