NuzzleBug: Debugging Block-Based Programs in Scratch

While professional integrated programming environments support developers with advanced debugging functionality, block-based programming environments for young learners often provide no support for debugging at all, thus inhibiting debugging and preventing debugging education. In this paper we introduce NuzzleBug, an extension of the popular block-based programming environment Scratch that provides the missing debugging support. NuzzleBug allows controlling the executions of Scratch programs with classical debugging functionality such as stepping and breakpoints, and it is an omniscient debugger that also allows reverse stepping. To support learners in deriving hypotheses that guide debugging, NuzzleBug is an interrogative debugger that enables to ask questions about executions and provides answers explaining the behavior in question. In order to evaluate NuzzleBug, we survey the opinions of teachers, and study the effects on learners in terms of debugging effectiveness and efficiency. We find that teachers consider NuzzleBug to be useful, and children can use it to debug faulty programs effectively. However, systematic debugging requires dedicated training, and even when NuzzleBug can provide correct answers learners may require further help to comprehend faults and necessary fixes, thus calling for further research on improving debugging techniques and the information they provide.Comment: To appear at the 2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE '24), April 14--20, 2024, Lisbon, Portuga

Experimenting with Realism in Software Engineering Team Projects: An Experience Report

Over Several years, we observed that our students were sceptical of Software Engineering practices, because we did not convey the experience and demands of production quality software development. Assessment focused on features delivered, rather than imposing responsibility for longer term `technical debt'. Academics acting as 'uncertain' customers were rejected as malevolent and implausible. Student teams composed of novices lacked the benefits of leadership provided by more experienced engineers. To address these shortcomings, real customers were introduced, exposing students to real requirements uncertainty. Flipped classroom teaching was adopted, giving teams one day each week to work on their project in a redesigned laboratory. Software process and quality were emphasised in the course assessment, imposing technical debt. Finally, we introduced a leadership course for senior students, who acted as mentors to the project team students. This paper reports on the experience of these changes, from the perspective of different stakeholders

Learning Human Aspects of Collaborative Software Development

Collaboration has become increasingly widespread in the software industry as systems have become larger and more complex, adding human complexity to the technological complexity already involved in developing software systems. To deal with this complexity, human-centric software development methods, such as Extreme Programming and other agile methods, have been developed and implemented. Aiming to prepare future software developers for today\u27s software industry, this paper presents a framework for developing collaborative learning tools and activities, and examples that were developed for the course Human Aspects of Software Engineering in order to assist students in learning collaborative software development. The learning processes and knowledge construction undergone by the students in the study were examined empirically, both in general and with respect to collaboration in particular. Results indicate that, based on their individual and group in-class experiences and reflections, students developed skills and constructed both practical and theoretical knowledge relating to successful collaborative software development

Assisting software architects in architectural decision-making using Quark

Non-Functional Requirements (NFRs) and constraints are among the principal drivers of architectural decision-making. NFRs are improved or damaged by architectural decisions (ADs), while constraints directly include or exclude parts of the architecture (e.g., logical components or technologies). We may determine the impact of an AD, or which parts of the architecture are affected by a constraint, but at the end it is hard to know if we are respecting the NFRs and the imposed constraints with all the ADs made. In the usual approach, architects use their own experience to produce software architectures that comply with the NFRs and imposed constraints, but at the end, especially for crucial decisions, the architect has to deal with complex trade-offs between NFRs and juggle with possible incompatibilities raised by the imposed constraints. In this paper we present Quark, a method to assist software architects in architectural decision-making, and the conceptualization of the relationship between NFRs and ADs defined in Arteon, an ontology to represent and manage architectural knowledge. Finally, we provide an overview of the Quark and Arteon implementation, the ArchiTech tool.Peer ReviewedPostprint (published version

Reusable framework for web application development

Web application (WA) is among the mainstream enterprise-level software solutions. One of the reasons for this trend was due to the presence of Web application framework (WAF) that in many ways has helped web developer to implement WA as an enterprise system. However, there are complexity issues faced by the developers when using existing WAFs as reported by the developers themselves. This study is proposed to find a solution to this particular issue by investigating generic issues that arise when developers utilize Web as a platform to deliver enterprise-level application. The investigation involves the identification of problems and challenges imposed by the architecture and technology of the Web itself, study of software engineering (SE) knowledge adaptation for WA development, determination of factors that contribute to the complexity of WAF implementation, and study of existing solutions for WA development proposed by previous works. To better understand the real issues faced by the developers, handson experiment was conducted through development testing performed on selected WAFs. A new highly reusable WAF is proposed, which is derived from the experience of developing several WAs case studies guided by the theoretical and technical knowledge previously established in the study. The proposed WAF was quantitatively and statistically evaluated in terms of its reusability and usability to gain insight into the complexity of the development approach proposed by the WAF. Reuse analysis results demonstrated that the proposed WAF has exceeded the minimum target of 75% reuse at both the component and system levels while the usability study results showed that almost all (15 out of 16) of the questionnaire items used to measure users’ attitudes towards the WAF were rated at least moderately by the respondents

Experiential learning approach for requirements engineering education

The use of requirements engineering (RE) in industry is hampered by a poor understanding of its practices and their benefits. Teaching RE at the university level is therefore an important endeavor. Shortly before students become engineers and enter the workforce, this education could ideally be provided as an integrated part of developing the requisite business skills for understanding RE. Because much social wisdom is packed into RE methods, it is unrealistic to expect students with little organizational experience to understand and appreciate this body of knowledge; hence, the necessity of an experiential approach. The course described in this paper uses an active, affective, experiential pedagogy giving students the opportunity to experience a simulated work environment that demonstrates the social/design-problem complexities and richness of a development organization in the throes of creating a new product. Emotional and technical debriefing is conducted after each meaningful experience so that students and faculty, alike can better understand the professional relevancies of what they have just experienced. This includes an examination of the many forces encountered in industrial settings but not normally discussed in academic settings. The course uses a low-tech social simulation, rather than software simulation, so that students learn through interaction with real people, and are therefore confronted with the complexity of true social relationship