reinforcement learning

A Simultaneous, Multidisciplinary Development and Design Journey - Reflections on Prototyping

This paper proposes a wayfaring approach for the early concept creation stage of development projects that have a very high degree of intended innovation and thus uncertainty. The method is supported by a concrete game design example involving the development of a tangible programming interface for virtual car racing games. We focus onto projects that not only have high degrees of freedom, for example in terms of reframing the problem or iterating the final project vision, but are also complex in nature. For example, these can be projects that allow for the exploration and exploitation of unknown unknowns and serendipity findings. Process wise we are primarily focusing onto the early stage that precedes the requirement fixation, which we see as more dynamic and evolutionary in nature. The core conceptual elements that we have derived from the development experiences are: simultaneous prototyping in multiple disciplines (such as computer science, electronics and mechanics and engineering in general, abductive learning based on the outcome of rapid cycles of designing, building and testing prototypes (probing), and the importance of includingall the involved disciplines (knowledge domains) from the beginning of the project on.

What leads developers towards the choice of a JavaScript framework?

Context: The increasing popularity of JavaScript (JS) has lead to a variety of frameworks that aim to help developers to address programming tasks. However, the number of JS Frameworks (JSF) has risen rapidly to thousands and more. It is difficult for practitioners to identify the frameworks that best fit to their needs and to develop new frameworks that fit such needs. Existing research has focused in proposing software metrics for the frameworks, which do not carry a high value to practitioners. While benchmarks, technical reports, and experts' opinions are available, they suffer the same issue that they do not carry much value. In particular, there is a lack of knowledge regarding the processes and reasons that drive developers towards the choice. Objective: This paper explores the human aspects of software development behind the decision-making process that leads to a choice of a JSF. Method: We conducted a qualitative interpretive study, following the grounded theory data analysis methodology. We interviewed 18 participants who are decision makers in their companies or entrepreneurs, or are able to motivate the JSF decision-making process. Results: We offer a model of factors that are desirable to be found in a JSF and a representation of the decision makers involved in the frameworks selection. The factors are usability (attractiveness, learnability, understandability), cost, efficiency (performance, size), and functionality (automatisation, extensibility, flexibility, isolation, modularity, suitability, updated). These factors are evaluated by a combination of four possible decision makers, which are customer, developer, team, and team leader. Conclusion: Our model contributes to the body of knowledge related to the decision-making process when selecting a JSF. As a practical implication, we believe that our model is useful for (1) Web developers and (2) JSF developers.

Time for AI (Ethics) Maturity Model Is Now

There appears to be a common agreement that ethical concerns are of high importance when it comes to systems equipped with some sort of Artificial Intelligence (AI). Demands for ethical AI are declared from all directions. As a response, in recent years, public bodies, governments, and universities have rushed in to provide a set of principles to be considered when AI based systems are designed and used. We have learned, however, that high-level principles do not turn easily into actionable advice for practitioners. Hence, also companies are publishing their own ethical guidelines to guide their AI development. This paper argues that AI software is still software and needs to be approached from the software development perspective. The software engineering paradigm has introduced maturity model thinking, which provides a roadmap for companies to improve their performance from the selected viewpoints known as the key capabilities. We want to voice out a call for action for the development of a maturity model for AI software. We wish to discuss whether the focus should be on AI ethics or, more broadly, the quality of an AI system, called a maturity model for the development of AI systems.

Implementing AI Ethics in a Software Engineering Project-Based Learning Environment - The Case of WIMMA Lab

Key Challenges in Software Startups Across Life Cycle Stages

Software startups are challenging endeavours, with various road blocks on their path to success. The current understanding of the challenges that software startups may encounter is very limited. In this paper, we use the research framework of learning and product development stages to analyse the key challenges that software startups have to deal with at different life cycle stages, from problem definition to solution validation and from concept to mature product. Based on an analysis of the empirical data collected by a large survey of 4100 startups, we find out that what perceived as biggest challenges by software startups do vary across different life cycle stages. Building product is the biggest obstacle for software startups, even though its significance decreases when the learning focuses of the startups move from problem to solution and their products mature. Business related challenges such as customer acquisition and scaling are more noticeable at the later stages. Our study raises the awareness of these challenges and suggests to tackle right challenges at the right time.

Minimum Viable Product or Multiple Facet Product? The Role of MVP in Software Startups

Minimum viable product (MVP) is the main focus of both business and product development activities in software startups. We empirically explored five early stage software startups to understand how MVP are used in early stages. Data was collected from interviews, observation and documents. We looked at the MVP usage from two angles, software prototyping and boundary spanning theory. We found that roles of MVPs in startups were not fully aware by entrepreneurs. Besides supporting validated learning, MVPs are used to facilitate product design, to bridge communication gaps and to facilitate cost-effective product development activities. Entrepreneurs should consider a systematic approach to fully explore the value of MVP, as a multiple facet product (MFP). The work also implies several research directions about prototyping practices and patterns in software startups.

“Failures” to be celebrated: an analysis of major pivots of software startups

In the context of software startups, project failure is embraced actively and considered crucial to obtain validated learning that can lead to pivots. A pivot is the strategic change of a business concept, product or the different elements of a business model. A better understanding is needed on different types of pivots and different factors that lead to failures and trigger pivots, for software entrepreneurial teams to make better decisions under chaotic and unpredictable environment. Due to the nascent nature of the topic, the existing research and knowledge on the pivots of software startups are very limited. In this study, we aimed at identifying the major types of pivots that software startups make during their startup processes, and highlighting the factors that fail software projects and trigger pivots. To achieve this, we conducted a case survey study based on the secondary data of the major pivots happened in 49 software startups. 10 pivot types and 14 triggering factors were identified. The findings show that customer need pivot is the most common among all pivot types. Together with customer segment pivot, they are common market related pivots. The major product related pivots are zoom-in and technology pivots. Several new pivot types were identified, including market zoom-in, complete and side project pivots. Our study also demonstrates that negative customer reaction and flawed business model are the most common factors that trigger pivots in software startups. Our study extends the research knowledge on software startup pivot types and pivot triggering factors. Meanwhile it provides practical knowledge to software startups, which they can utilize to guide their effective decisions on pivoting.

What Influences the Speed of Prototyping? An Empirical Investigation of Twenty Software Startups

It is essential for startups to quickly experiment business ideas by building tangible prototypes and collecting user feedback on them. As prototyping is an inevitable part of learning for early stage software startups, how fast startups can learn depends on how fast they can prototype. Despite of the importance, there is a lack of research about prototyping in software startups. In this study, we aimed at understanding what are factors influencing different types of prototyping activities. We conducted a multiple case study on twenty European software startups. The results are two folds; firstly we propose a prototype-centric learning model in early stage software startups. Secondly, we identify factors occur as barriers but also facilitators for prototyping in early stage software startups. The factors are grouped into (1) artifacts, (2) team competence, (3) collaboration, (4) customer and (5) process dimensions. To speed up a startup’s progress at the early stage, it is important to incorporate the learning objective into a well-defined collaborative approach of prototyping.

An Empirical Study on Female Participation in Software Project Courses

Gender issues in software engineering education are gaining research attention due to the desire to promote female participation in the field. The objective of this work is to enhance the understanding of female students' participation in software engineering projects to support gender-aware course optimization. Since 2015, we have investigated the participation of female students in terms of software engineering activities and team dynamics in a software project course that involves a real customer. We found that female students are more active with project management and requirement engineering, while they remain under-represented in highly complex or specific tasks, i.e. architecture work, and user experience design. We found no statistically significant difference in perceived team dynamics between male and female students. Insights on female project activities would facilitate the arrangement of project teams so that learning can be distributed equally across genders

StartCards - A method for early-stage software startups

course of 4 AR cycles. During the AR process, the method was used by 44 student startup teams in a practical course setting. Data from the use of the method was collected through self-reporting in the form of modified learning diaries, mentoring meetings with the startup teams, and a qualitative survey. Results: We consider the current version of StartCards useful for early-stage startups based on the data we have collected. The method can also be used as a pedagogical tool in startup education. Conclusions: The paper presents the first published version of the method. While work on the method continues, the method is deemed ready for use.

VAPU: System for Autonomous Legacy Code Modernization

In this study, we present a solution for the modernization of legacy applications, an area of code generation where LLM-based multi-agent systems are proving essential for complex multi-phased tasks. Legacy applications often contain deprecated components that create compatibility, security, and reliability risks, but high resource costs make companies hesitate to update. We take a step forward to integrate an LLM-based multi-agent system as part of a legacy web application update to provide a cost-effective solution to update legacy applications autonomously. We propose a multi-agent system named a Verifying Agent Pipeline Updater (VAPU), which is designed to update code files in phases while simulating different roles in a software development team. In our previous study, we evaluated the system for legacy version updates by using six legacy web application view files by resulting errors and accomplished requirements. This study extends the previous evaluation of a multi-agent pipeline system by extending the evaluation of VAPU from a single LLM to five LLMs and using the temperature parameter in both 0 to 1 settings. Additionally, we tested the system with 20 open-source Python GitHub projects. The results of the evaluation were compared to Zero-Shot Learning (ZSL) and One-Shot Learning (OSL) prompts. The extended evaluation of VAPU showed that particularly in a low-temperature VAPU can get similar level of error count compared to the ZSL/OSL prompts but with a higher level of fulfilled requirements, depending on the LLM. VAPU showed up to 22.5% increase in the succeeding Python file update requirements compared to ZSL/OSL prompts. The study indicates that an LLM-based multi-agent system is a capable solution to update components of a legacy application autonomously.

Autonomous Legacy Web Application Upgrades Using a Multi-Agent System

The use of Large Language Models (LLMs) for autonomous code generation is gaining attention in emerging technologies. As LLM capabilities expand, they offer new possibilities such as code refactoring, security enhancements, and legacy application upgrades. Many outdated web applications pose security and reliability challenges, yet companies continue using them due to the complexity and cost of upgrades. To address this, we propose an LLM-based multi-agent system that autonomously upgrades legacy web applications to the latest versions. The system distributes tasks across multiple phases, updating all relevant files. To evaluate its effectiveness, we employed Zero-Shot Learning (ZSL) and One-Shot Learning (OSL) prompts, applying identical instructions in both cases. The evaluation involved updating view files and measuring the number and types of errors in the output. For complex tasks, we counted the successfully met requirements. The experiments compared the proposed system with standalone LLM execution, repeated multiple times to account for stochastic behavior. Results indicate that our system maintains context across tasks and agents, improving solution quality over the base model in some cases. This study provides a foundation for future model implementations in legacy code updates. Additionally, findings highlight LLMs' ability to update small outdated files with high precision, even with basic prompts. The source code is publicly available on GitHub: https://github.com/alasalm1/Multi-agent-pipeline.