Browsing by Subject "software engineering"

This master's thesis describes the development and validation of a uniform control interface for drawing robots with ROS2. The robot control software was tasked with taking SVG images as input and producing them as drawings with three different robots. These robots are the Evil Mad Scientist AxiDraw V3/A3, UFACTORY xArm Lite6, and virtual xArm Lite6. The intended use case for the robots and companion control software is experiments studying human perception of the creativity of the drawing robots. The control software was implemented over the course of a little over six months and used a combination of C++ and Python. The design of the software utilizes ROS2 abstractions such as nodes and topics to combine different components of the software. The control software is validated against the given requirements and found to fulfil the main objectives of the project. The most important of these are that the robots successfully draw SVG images, that they do so in a similar time frame, and that these images look very similar. Drawing similarity was tested by scanning images, aligning them using using minimal error, and then comparing them visually after overlaying the images. Comparing aligned images was useful in detecting subtle differences in the drawing similarity of the robots and was used to discover issues with the robot control software. MSE and SSIM were also calculated for a set of these aligned images, allowing for the effect of future changes made to the robot control software to be quantitatively evaluated. Drawing time for the robots was evaluated by measuring the time taken for drawing a set of images. This testing showed that the Axidraw's velocity and acceleration needed to be reduced by 56% so that the xArm Lite6 could draw in similar time.

Tertiary education aims to prepare computer science students for the working life. While much of the technical principles are covered in lower-level courses, team-based capstone projects are a common way to provide students hands-on experience and teach soft skills. Although such courses help students to gain some of the relevant skills, it is difficult to simulate in a course context what work in a professional software engineering team really is about. Our goal is to understand ways tertiary education institutions prepare students for the working life in software engineering. Firstly, we do this by focusing on the mechanisms that software engineering capstones use to simulate work-life. A literature review of 85 primary studies was conducted for this overview. Secondly, we present a more novel way of teaching industry-relevant skills in an university-lead internal software startup. A case study of such a startup, Software Development Academy (SDA), is presented, along with the experiences of both students and faculty involved in it. Finally, we look into how these approaches might differ. Results indicate that capstone courses differ greatly in ways they are organized. Most often students are divided in teams of 4–6 and get assigned with software projects that the teams then develop from an idea to a robust proof-of-concept. In contrast, students employed in the SDA develop production-level software in exchange for a salary for university clients. Students regarded SDA as a highly relevant and fairly irreplaceable educational experience. Working with production-quality software and having a wide range of responsibilities was perceived integral in giving a thorough skill set for the future. In conclusion, capstones and the internal startup both aim to prepare students for the work-life in software engineering. Capstones do it by simulating professional software engineering in a one-semester experience in a course environment. The internal startup adds a touch of realism to this by being actual work in a relatively safe university context.

Re-engineering can be described as a process for updating an existing system in order to meet new requirements. Restructuring and refactoring are activities that can be performed as a part of the re-engineering process. Supporting new requirements like migrating to new frameworks, new environments and architectural styles is essential for preservation of quality attributes like maintainability and evolvability. Many larger legacy systems slowly deteriorate over time in quality and adding new functionality becomes increasingly difficult and costly as technical debt accumulates. To modernize a legacy system and improve the cost effectiveness of implementing new features a re-engineering process is often needed. The alternative is to develop a completely new system but this can often lead to loss of years of accumulated functionality and be too expensive. Re-engineering strategies can be specialized and solve specific needs like cloud migration or be more generic in nature supporting several kinds of needs. Different approaches are suitable for different kinds of source and target systems. The choice of a re-engineering strategy is also influenced by organisational and business factors. The re-engineering of a highly tailored legacy system in a small organisation is different from re-engineering a scalable system in a large organisation. Generic and flexible solutions are well suited for especially smaller organisations with complex systems. The re-engineering strategy Renaissance was applied in a case study at Roima Intelligence Oy in order to find out if such a strategy is realistically usable, useful and valuable for a smaller organization. The results show that a re-engineering strategy is possible to be used with low overhead in order to prioritize different parts of the system and determining a suitable modernization plan. Renaissance was also shown to add value especially in the form of deeper understanding of the system and a structured way to evaluate different options for modernization. This is achieved through assessing the system from different views taking into account especially business and technical aspects. A lesson learned about Renaissance is that determining an optimal scope for the system assessment is challenging. The results are applicable for other organisations dealing with complex legacy systems with constrained resources. Limitations of the study are that the number of different kinds of re-engineering strategies discussed is small and more suitable strategies than Renaissance could be discovered with a systematic mapping study. The amount of experts participating in the process itself as well as the evaluation was also low, introducing some uncertainty to the validity of the results. Further research is needed in order to determine how specialized and generic re-engineering strategies compare in terms of needed resources and added value.