Teaching effective countermeasures against emerging threats and vulnerabilities in mobile applications has always been an important focus in cybersecurity curriculums. In this paper, we share our experience in developing a group project that allows students to apply techniques learned in a postgraduate cybersecurity course. The group project aims to simulate a real-world challenge in mobile cybersecurity. The project consists of three progressive stages:~Build, Fortify, and Attack. The project involves students building a chat application powered by Artificial Intelligence (AI), fortifying it against vulnerabilities, and then attempting to extract the Application Programming Interface (API) keys of other groups. We provide details of the design and outcomes, and reflect on what has worked for those who wish to adopt similar kinds of group assessments.

Student disengagement remains a persistent challenge in higher education. This paper presents Genius-Coin, an open-source, self-hostable blockchain courseware designed to promote student motivation and engagement through gamification and token-economy mechanisms. The system connects verifiable learning activities to digital rewards: classroom attendance is recorded through dynamic QR code scanning, while online participation from learning management and discussion platforms is also captured. Once participation is verified, digital tokens and achievement badges are automatically distributed through smart contracts and can later be redeemed for rewards through an online store. Designed for practical institutional use, Genius-Coin supports straightforward deployment on institutional servers and provides a dedicated wallet application that simplifies student onboarding. A pilot deployment with 65 postgraduate students suggests that the system fostered intrinsic engagement, as many students appeared more motivated to attend class and participate in course activities than to redeem tokens for external rewards; only 33.1% of distributed tokens were redeemed.

Complex software systems consist of multiple overlapping design structures, such as abstractions, features, crosscutting concerns, or patterns. This is similar to how a human body has multiple interacting subsystems, such as respiratory, digestive, or circulatory. Unlike in the medical domain, software designers do not have an effective way to distinguish, visualize, comprehend, and analyze these interleaving design structures. As a result, developers often struggle through the maze of source code. In this paper, we present anAutomated Concept Explanation(ACE) framework that automatically extracts and categorizes major concepts from source code based on the roles that files play in design structures and their topic frequencies. Based on these categorized concepts, ACE recovers four categories of high-level design models using different algorithms and generates a natural language explanation for each. To assess if and how ACE can help developers better understand design structures, we conducted an empirical study where two groups of graduate students were assigned three design comprehension tasks: identifying feature-related files, identifying dependencies among features, and identifying design patterns used, in an open-source project. The results reveal that the students who used ACE can accomplish these tasks much faster and more accurately, and they acknowledged the usefulness of the categorized concepts and structures, multi-type high-level model visualization, and natural language explanations.

Folk-wisdom in software engineering suggests that small functions that adhere to the principle of single-responsibility have several advantages over longer, monolithic functions, including improvement in code comprehension. Despite this widespread view, empirical research on the impact of functional decomposition on understanding code is sparse, yet it is central to software development practices.

Abstract Requirements Technical Debt (RTD) applies the Technical Debt (TD) metaphor to capture the consequences of sub-optimal decisions made concerning Requirements. Understanding the quantification of RTD is key to its management. To facilitate this understanding, we developed a conceptual model, the Requirements Technical Debt Quantification Model (RTDQM). Our work is grounded in the literature found via a systematic mapping study and informed by prior work modeling the quantification of software code-related TD types. The key finding is that although RTD is similar to code-related TD in many aspects, it also has its own components. RTD can be incurred regardless of the presence of code-related TD. Unlike code-related TD, RTD has a feedback loop involving the user. RTD can have a cascading impact on other development activities, such as design and implementation, apart from the extra costs and efforts incurred during requirements engineering activities; this is modeled by the RTD Interest constituents in our model. The model was used to compare and analyze existing quantification approaches. It helped identify what RTD quantification concepts are discussed in the existing approaches and what concepts are supported by metrics for their quantification. The model serves as a reference for practitioners to select existing or to develop new quantification approaches to support informed decision-making for RTD management.

To effectively manage Technical Debt (TD), we need reliable means to quantify it. We conducted a Systematic Mapping Study (SMS) where we identified 39 quantification approaches for Code, Design, and Architecture TD. We analyzed concepts and metrics discussed in these quantification approaches by classifying the quantification approaches based on a set of abstract TD Quantification (TDQ) concepts and their high-level themes, process/time, cost, benefit, probability, and priority, which we developed during our SMS. This helped identify gaps in the literature and to propose future research directions. Among the abstract TDQ concepts discussed in the different quantification approaches, TD item, TD remediation cost, TD interest, and Benefit of remediating TD were the most frequently discussed concepts. They were also supported by some form of measurement. However, some TDQ concepts were poorly examined, for example, the benefit of taking TD. It was evident that cost concepts were more frequently quantified among the approaches, while benefit concepts were not. Most of the approaches focused on remediating TD in retrospect rather than quantifying TD to strategically use it during software development. This raises the question of whether existing approaches reliably quantify TD and suggests the need to further explore TDQ.

Making sub-optimal design decisions during software development leads to the accumulation of Technical Debt (TD) in software projects. There are tools to identify TD Items in software code through static code analysis. However, quantifying TD to support decision-making on whether to keep taking on TD or if it is time to refactor TD is a difficult task, and proposed approaches for this still lack consensus. Prior work observed that TD Interest could be further decomposed into constituents ‘New Code Cost’ and ‘Rework Cost’, which gives an interesting direction of research to explore TD quantification in terms of these costs. Therefore, through our empirical study, we plan to explore the relationship between TD, New Code Cost and Rework Cost in Open-Source Software Projects. This paper reports on an initial motivating study, our plan for future work and implications for researchers.

Requirements Technical Debt (RTD) is a research area where the Technical Debt (TD) metaphor is used to capture the consequences of sub-optimal decisions made concerning Requirements. Understanding the quantification of RTD is key to its management. To facilitate this understanding, we model the quantification of RTD. Our work is grounded in the literature found via a Systematic Mapping Study (SMS) and informed by prior work modeling the quantification of TD for software code-related TD types. This paper reports on the SMS and the development of our model, the RTD Quantification Model (RTDQM). The key observation from our work is that, although RTD is similar in most aspects to TD in software code, it also has its own components. Requirement artifacts have a feedback loop involving the User to precisely capture User Needs. RTD Interest (i.e., additional costs due to sub-optimal decisions concerning Requirements) can incur during both Requirements Engineering and Implementation activities. Furthermore, RTD can incur regardless of the presence of software code-related TD. Similar to benefits accrued by refactoring software code, rectifying RTD can also accrue benefits.

The Postgraduage Certificate in Information Technology at the University of Auckland is a bootcamp-style transition programme for students without prior programming experience. The programme's part-time variant, designed for working professionals, has traditionally been offered with intensive evening classes, with extensive tutor and instructor support. Spurred on by the COVID-19 pandemic, our University has moved this part-time variant fully online. Benefits of the online offering include a wider, more inclusive audience and flexibility of student learning schedules. However, it has introduced several pedagogical challenges, including but not limited to how instructors can continue to provide meaningful support, feedback, and student engagement in an online environment. In this paper, we reflect on our experience, analyse qualitative and quantitative feedback such as student evaluations and grades, and provide recommendations for those wishing to undertake a similar transformation in the future.

Recently, there has been a strong demand for talented ICT (Information and Communication Technology) graduates in the software industry in New Zealand. To meet this demand, in 2015, the government of New Zealand provided funding for three new ICT Graduate Schools. The challenge for the schools was twofold: to provide a qualification for students transitioning into ICT and to prepare those with an ICT education for the workforce. Each of the Schools offer different programmes. We offer two postgraduate programmes for growing talent and knowledge to support the New Zealand's ICT sector. In this paper, we describe our experience with delivering one of the postgraduate programmes, the Postgraduate Certificate in Information Technology. The programme consists of two courses, Programming for Industry and Programming with Web Technologies. The courses focus on providing industry-focused education to students with non-ICT backgrounds for a career in IT. The programme has been running for 2 years and runs over one semester (12 weeks) in a "boot-camp" style, which has proved to be successful. In this paper, we provide an overview of the features of the programme, which incorporates industry-focused activities for building students' knowledge relevant to the software industry. Finally, we discuss key challenges and identify directions for improvement.

We proposed a definition of transparency in software development to improve communication among stakeholders. The notion of transparency is important, because it enables stakeholders to identify and understand the information exchanged during communication. We designed a survey to gather evidence to support or refute our beliefs about transparency in software development. We discovered a superiority bias in our respondents when answering questions regarding communication problems. In this paper, we present our survey design and preliminary results of our survey.