Denna kandidatrapport beskriver ett projekt som gjordes under kursen “TDDD96-Kandidatprojekt i programvaruutveckling” vid Linköpings universitet. Rapporten beskriverhur gruppen arbetat med projektet samt hur arbetsmetodiken förändrats under projektetsgång. Rapporten presenterar också resultat av utvecklingsarbetet av robotplattformenAIDA. Roboten AIDA består av ett flertal hårdvarukomponenter samt en Androidsurfplatta.Surfplattan är programmerad med ett grafiskt gränssnitt för de tre huvudsakligafunktionerna som projektgruppen utvecklat. Dessa är: presentation av taligenkänning,gestigenkänning, och visning av LiDAR-data.Projektgruppen kom fram till att för att skapa värde för kunden med AIDA och dessapplikation krävs en tydlig förståelse för kundens behov och en klar kravspecifikation.Det är viktigt att ha en kontinuerlig dialog med kunden för att säkerställa att produktutvecklingenmotsvarar kundens förväntningar. Genom att använda den iterativa metodenScrum kunde gruppen effektivt hantera problem och nå uppsatta mål.Erfarenheterna från projektet visar på vikten av att dokumentera och reflektera överarbetet kontinuerligt. Användningen av Scrum var överlag positiv, men utmaningar uppstod.Dokumentation och välstrukturerad kod var avgörande, särskilt för ostruktureradeprojekt, för att underlätta för framtida utveckling och förståelse av systemet.Att skapa och följa en systemanatomi bidrog till en tydlig plan för systemets uppbyggnadoch utveckling av nya funktioner. Utmaningar kring vidareutvecklingen av ett ostruktureratsystem inkluderar svårigheten att förstå dess struktur och att hantera eventuelltföråldrad mjukvara. Att utveckla ett modulärt system kräver tid och resurser, med fokuspå att identifiera ramverk som är enkla att vidareutveckla och som uppfyller kravet påmodularitet. Stor vikt lades också på att utveckla ett modulärt API för att underlätta kommunikationenmellan olika moduler

Today stereotactic neurosurgery is a demanding and time-consuming procedure. To help the surgeons different tools are used. Elekta has developed a frame called the Leksell Vantage Stereotactic System (LVSS). The problem with the frame that Elekta has created is that for some inputs the system is blocking trajectories. Elekta tasked the author with producing a prototype app that evaluates pre-planned trajectories for possible collisions.  The prototype app is written in Rust using the Bevy game engine, the software simulates stereotactic coordinates and angles for evaluating neurosurgery trajectories. Testing reveals accurate X, Y, and Z scale movements, with some collision detection inconsistencies and alignment issues. Hardware requirements emphasize moderate specifications for RAM, CPU, and GPU utilization. The LVSS Simulator prototype app, facilitates coordinate manipulation, collision detection, and visual feedback. While patient-specific planning tools exist, the LVSS Simulator serves as a general application for trajectory planning based on equipment specifications.  The developed software shows strengths and weaknesses, with improvements suggested for collision handling and alignment. The software's reliability metrics are of small size, 794 lines of code (LOC) and moderate complexity because of McCabe's Cyclomatic Complexity (MCC).

No description available.

Dokumentet är en rapport om skrubbning i livevideo från drönare. Beställare av produkten är Fredrik Falkman på Remote Aero. Utförandet gjordes av åtta studenter från Linköpings universitet i kursen Kandidatprojekt i programvaruutveckling-TDDD96 år 2024.Målet med projektet var att skapa ett användargränssnitt för en drönare. I användargräns-snittet skulle det vara möjligt att ta ut bilder från drönarens livevideo. Detta i syfte attunderlätta Svenska Sjöräddningssällskapets livräddningar genom att kringgå risken attbesättningen blint ser på liveströmmen istället för att ha ögonen ute på vattnet. Gruppen utvecklade en webbapplikation som gjorde det möjligt att ta emot en live-ström från en server, plocka ut stillbilder och skicka dem vidare. I texten beskrivs också hur gruppen arbetat med det agila ramverket Scrum, vilka för- och nackdelar det haft, hur sprintar planerades och hur en systemanatomi var till hjälp.

Följande dokument är en rapport gällande projektet Webbapplikation för terminering avdrönarflygning. Projektet beställdes av OutSmart AB samt Sjöräddningssällskapet och utfördesav åtta studenter vid Linköpings universitet som kandidatprojekt i programvaruutvecklingunder våren 2024. Rapporten redogör för hur värde skapades för kunden, vilkaerfarenheter som gruppen tar med sig, samt hur en systemanatomi användes för att få stödunder utvecklingen. Projektets mål var att skapa en användarvänlig webbapplikation somnyttjade OutSmarts befintliga system, som kommunicerar mellan drönaren och systemetsom utvecklas. Syftet med webbapplikationen var att kommunicera med GPS-enheter föratt terminera en drönares flygning. Projektet skapade värde för kunden genom applikationensom projektet resulterade i, samt förslag för hur det redan befintliga systemet kanförbättras. Flera erfarenheter dokumenterades, exempelvis hur nyttjandet av kontinuerligintegration leder till färre merge-konflikter. Systemanatomin användes både under planeringsfasenför att strukturera arbetsflödet och kontinuerligt under utvecklingen för attskapa en fördjupad förståelse av den aktuella statusen.

Denna rapport beskriver ett kandidatprojekt som utfördes våren 2024 i kursen TDDD96 Kandidatprojekt i programvaruutveckling på Linköpings universitet [1]. En projektgrupp bestående av åtta kursdeltagare fick i uppdrag av företaget SUND att utveckla en prototyp för en digital hälsotvilling i Flutter. Applikationen utvecklades i språket Dart, utifrån kundens tillhandahållna Framer-prototyp. Syftet med slutprodukten är att den ska användas som hjälpmedel för förbättrad hälsa hos en äldre målgrupp. Rapporten lyfter viktiga metoder som använts vid utveckling, samt teorin bakom. De valda metoderna spelade en avgörande roll i slutproduktens kvalitet, och motiveras med diskussioner. För att säkerställa kvalitet, konstruerades en systemanatomi som underlättade identifiering av beroenden inom applikationen. Under utvecklingsprocessen dokumenterade projektgruppen många erfarenheter som ansågs vara användbara för framtida projekt, särskilt att kontinuerliga utvärderingar är viktiga för att uppnå en effektiv arbetsprocess. Till sist, skapade slutprodukten värde för kunden genom att förverkliga deras önskemål om en applikation som kan vara till hjälpmedel för en äldre målgrupp. Det är dock svårt att avgöra hur användarvänlig produkten är för målgruppen, eftersom sekretessbeläggning förhindrar utomstående från att testa produkten. För att kringgå detta problem kan olika metoder användas för att ge en fingervisning om produktens användarvänlighet

Detta arbete undersöker hur SIARD-metodik kan användas för arkivering av relationsdatabaser. SIARD är en förkortning av Software Independent Archiving of Relational Databases. SIARD är ett fil-format som är baserad på äldre etablerade standarder som SQL:2008, XML, ZIP64 och UNICODE. SIARD är utvecklat med syfte att kunna hantera långtidsbevarande av relationsdatabaser. Arbetet önskar svara på ifall det finns några datatekniska problem med att använda SIARD-metodik för att transformera en databas till ett SIARD-filformat. Datatekniska mål som undersökts är ifall data och metadata kan gå förlorad eller förändras under databasexportering. Arbetet undersöker också ifall olika normaliseringsgrader påverkar basrelationer eller databasintegritet under exportering eller återskapande av en databas. För att besvara denna frågeställning så har en inledande studie gjorts på arkiverings- och databasverktyg som har stöd för SIARD-metodik. Kravfångst har använts för att finna arbetets begränsningar och sätta upp nåbara delmål för arbetet. I arbetet skapades en testmiljö med en relationsdatabas och testdata som text, heltal, datatyper och standardvärden som kan påverka exporteringsprocessen. Först skapades en testdatabas som sedan arkiverades med SIARD-arkiveringsverktyg. Testdatabasen undersöktes och återskapades sedan för att jämföra de olika databastillstånden och finna skillnader. Resultatet från detta arbete har visat att det är mycket möjligt att data, datatyper, standardvärden och referensintegritet förändras av exporteringsprocessen. Detta kan bero på problemdata eller att SIARD saknar stöd för vissa unika implementationer i databashanterare och frågespråk. I arbetet så analyseras och förklaras de resultat som är framtagna. Några resultat som delas av relaterade studier diskuteras mer ingående. Arbetet sammanfattar att det krävs goda insikter i SIARD-metodik och datakunskap för att inte riskera datatekniska problem som kan uppstå vid databasarkivering. / This work explores how SIARD-methodology can be used for archiving relational databases. SIARD is short for Software Independent Archiving of Relational Databases. SIARD is a file format that is based on older established standards like SQL:2008, XML, ZIP64 and UNICODE. The purpose of SIARD is to handle archiving of relational databases. This work wants to examine if there are some computer technological problems that can arise when using SIARD-methodology to transform a database to a SIARD-format. Computer technological goals that have been examined are if data and metadata loss can occur or be altered during the export process. This work also examines if different normal forms can affect database tables or database integrity during an export or recreation of a database. To answer these questions an initial study was made on the archiving tools and database tools that had support for SIARD-methodology. Requirement capturing has been a key part in finding the limitations of this work and creating reachable milestones for this work. In this work a test environment was created containing a relational database with test data like tupels, datatypes and default values that can affect the export process. The test database was first created then archived with SIARD-tools. The database was examined and then recreated for results comparison between the different database conditions. The result has shown that it is highly possible for data, datatypes, default values and reference integrity to change because of the export process. This can be a result of problematic data or that SIARD lack support for some implementation details that are unique for a database management system or a query language. In this work the results are analyzed and explained. Some results that are shared by related studies are discussed. This work then concludes that sufficient knowledge in computer science and SIARD-methodology is needed to prevent computer technological problems that may arise during database archiving.

Today, software has become deeply woven into the fabric of our lives. The quality of the software we depend on needs to be ensured at every phase of the Software Development Life Cycle (SDLC). An analyst uses the requirements engineering process to gather and analyze system requirements in the early stages of the SDLC. An undetected problem at the beginning of the project can carry all the way through to the deployed product. The Requirements Traceability Matrix (RTM) serves as a tool to demonstrate how requirements are addressed by the design and implementation elements throughout the entire software development lifecycle. Creating an RTM matrix by hand is an arduous task. Manual generation of an RTM can be an error prone process as well. As the size of the requirements and design document collection grows, it becomes more challenging to ensure proper coverage of the requirements by the design elements, i.e., assure that every requirement is addressed by at least one design element. The techniques used by the existing requirements tracing tools take into account only the content of the documents to establish possible links. We expect that if we take into account the relative order of the text around the common terms within the inspected documents, we may discover candidate links with a higher accuracy. The aim of this research is to demonstrate how we can apply machine learning algorithms to software requirements engineering problems. This work addresses the problem of requirements tracing by viewing it in light of the Ant Colony Optimization (ACO) algorithm and a reinforcement learning algorithm. By treating the documents as the starting (nest) and ending points (sugar piles) of a path and the terms used in the documents as connecting nodes, a possible link can be established and strengthened by attracting more agents (ants) onto a path between the two documents by using pheromone deposits. The results of the work show that ACO and RL can successfully establish links between two sets of documents.

This study investigated, in the context of a field-based case study, possibilities for formation of a synergistic union between CSCW and CASE tools. A major dimension of today's software challenge is in gearing up for large-scale system development necessitating large teams of systems engineers. The principal goal of this research was to advance the body of knowledge regarding the nature of collaborative technological support in the software development process. Specifically, the study was designed to evaluate the potential for using a CSCW tool as an effective front-end to a CASE tool in the furtherance of SDLC goals.

Software reuse via component libraries suffers from the twin problems of code location and comprehension. The Intelligent Code Object Planner (ICOP) is a cognitively motivated system that facilitates code reuse by answering queries about how to produce an effect with the library. It can plan for effects which are not primitive with respect to the library by building a plan that incorporates multiple components. The primary subsystems of ICOP are a knowledge base which describes the ontology of the library, a natural language interface which translates user queries into a formal effect language (predicates), a planner which accepts the effect and produces a plan utilizing the library components, and an explanation generator which accepts the plan and produces example code illustrating the plan. ICOP is currently implemented in Prolog and supports a subset of the Windows 3.0 APL