Zugl.: Erlangen, Nürnberg, Univ., Diss., 2006 / Hergestellt on demand

Detta examensarbete har inspirerats av det inkonsekventa tillämpandet av olika kännetecken vid definiering av Big Data och hur det vidsträckta arbetet som expertrollen för konceptet går att förhålla till just dessa kännetecken. Studiens syfte är således att ge en klarare bild över vad den diffusa rollen Data Scientist går ut på och lyfta fram vad de grundläggande uppgifterna i rollen innebär med dessa kännetecken som riktlinjer. Information om rollen har samlats in genom semi-strukturerade intervjuer med Data Scientists i verksamheter av varierande typer och storlekar. Studiens analys ger målande beskrivningar över hur arbetet för deltagande respondenter ser ut, och fastslår hur deras arbetsuppgifter förhåller sig till olika kännetecken för Big Data. Studiens resultat skildrar hur arbetet för de olika respondenterna förhåller sig till definitionen för Big Data, och hur arbetet skiljer sig beroende på vilken typ och storlek av verksamhet som Data Scientists är verksam i. Resultatet belyser också att arbetet för Data Scientists går att gemensamt förhålla till kännetecknen Value, Visualization och Validity vilket besvarar studiens grundläggande frågeställningen. Resultatet och undersökningen i sig reflekteras över i uppsatsens diskussionsdel där upptäckter som gjorts under arbetets gång skildras, både om Big Data som koncept och om rollen Data Scientist, vilket bland annat ger förslag på vidare studier som kan leda till kategoriseringar av rollen.

Werden Softwaresysteme auf Basis eines komponentenorientierten Architekturparadigmas entwickelt, stellt sich die Frage, welches Vorgehensmodell zur Projektabwicklung herangezogen werden kann. In der Literatur werden unterschiedliche Vorgehensmodelle zur komponentenorientierten Softwareentwicklung vorgeschlagen. Aus diesen werden in der vorliegenden Untersuchung vier Modelle ausgewählt: Catalysis, Perspective, Rational Unified Process 2002 und V-Modell ’97. Die ausgewählten Vorgehensmodelle werden auf Basis eines allgemeinen Rahmens beschrieben und verglichen. Dabei werden die Aspekte Terminologie, Klassifizierung, Komponentenbegriff, Abdeckung des Lebenszyklus einer Komponente, Abdeckung der Tätigkeitsbereiche, Prozessarchitektur, Prozesssteuerung, Rollenabdeckung und Adaption untersucht. Komponentenorientierte Vorgehensmodelle sind sowohl Weiterentwicklungen bekannter konventioneller Vorgehensmodelle als auch ausschließlich auf die komponentenorientierte Entwicklung ausgerichtet. Obwohl die ausgewählten Vorgehensmodelle speziell auf eine komponentenorientierte Entwicklung ausgerichtet sind, zeigt sich, dass wesentliche Lebenszyklen einer Komponente nur rudimentär behandelt werden. Eine Ausnahme bildet hier Catalysis.

This paper presents conora, a robust trajectory optimization software utilizing orthogonal collocation methods for ascending rocket stages, targeting applications in early phases of mission design. The proposed methodology leverages orthogonal collocation techniques, preferred over the multitude of available options for their robustness to inaccuracies in the initial guess. This, together with low amount of available data about the ascent profile, often makes preliminary optimization considerably complex, extremely case-specific and, consequently, very time consuming. The software here implemented addresses the problem of maximizing the payload mass of a rocket by providing the required flexibility to adapt to any mission scenario disregarding of the celestial body, launch site, vehicle design and target orbit. Proper functionality is demonstrated by replicating existing missions, simplifying and reducing to the bare minimum the number of inputs. Ariane V ascending to GTO, Electron launch to SSO, ALTO mission to LEO, Apollo XI Lunar Module ascent and Starship take-off to LMO are the multifaceted mission scenarios selected to demonstrate the capabilities of conora, resulting in accurate injection into orbit and relatively close estimation of optimized payload masses. The obtained outcomes grow more valuable when considering the small amount of inputs provided, the simplicity of the utilized physical model and the strong assumptions considered. The whole software development process followed a V-model, from requirement definition, passing by the actual implementation, to thorough code testing of each conora’s module. 64 are the number of identified top level requirements, for a verification process elaborated via more than 270 tests, from unit to system level. The entire work was performed in the context of an internship at DLR, at the Institute of Space Systems in Bremen, Germany. / Denna uppsats presenterar conora, en robust mjukvara för optimeringen av flygbanor, via användningen av ortogonala kollokationsmetoder för stigande raketsteg, med fokus på applikationer inom de tidiga faserna av uppdragets utformning. Den förslagna metodiken använder ortogonala kollokationsmetoder, som föredras över konkurrerande metoder för dess robusthet mot fel och osäkerheter i initial gissningen. Detta, tillsammans med lite tillgängliga data kring stigningsprofilen gör att preliminära optimeringar blir komplexa, extremt fallspecifika och därmed också väldigt tidskrävande. Mjukvaran har implementerats för att hantera maximering av nyttolastsmassan på en raket genom att bidra med den krävda flexibiliteten att anpassas till olika uppdragsscenarier, oavsett himlakropp, uppskjutningsplats, farkostsdesign eller given omloppsbana. Korrekt funktionalitet demonstreras genom att replikera nutida uppdrag, genom att förenkla och reducera till den lägsta mängd inmatningsvariabler. Ariane Vs uppstigning till GTO, Elektrons uppskjutning till SSO, ALTO uppdrag till LEO, Apollo XI Lunar Modules uppskjutning och Starships uppskjutning till LMO är de mångfasetterade uppdragsscenarion valda för att demonstrera conoras kapacitet. Resultatet visar på träffsäkra injektioner till omloppsbana och relativt bra uppskattning av optimerad nyttolastsmassa. Resultatet blir mer värdefullt när man tar hänsyn den lilla mängden inmatningsvariabler, enkelheten av de använda fysiska modellerna och de starka antaganden som gjorts. Hela mjukvarans utvecklingsprocess följde en V-modell, från kravskrivning, genom implementationen, till genomgående kodtestning av varje modul i conora. 64 krav på högsta nivå identifierades, för en verifikationsprocess utvecklad via mer än 270 tester, från enhets- till systemnivå. Hela arbetet utfördes inom ett praktikantarbete vid DLR, vid avdelningen för rymdsystem i Bremen, Tyskland.

Werden Softwaresysteme auf Basis eines komponentenorientierten Architekturparadigmas entwickelt, stellt sich die Frage, welches Vorgehensmodell zur Projektabwicklung herangezogen werden kann. In der Literatur werden unterschiedliche Vorgehensmodelle zur komponentenorientierten Softwareentwicklung vorgeschlagen. Aus diesen werden in der vorliegenden Untersuchung vier Modelle ausgewählt: Catalysis, Perspective, Rational Unified Process 2002 und V-Modell ’97. Die ausgewählten Vorgehensmodelle werden auf Basis eines allgemeinen Rahmens beschrieben und verglichen. Dabei werden die Aspekte Terminologie, Klassifizierung, Komponentenbegriff, Abdeckung des Lebenszyklus einer Komponente, Abdeckung der Tätigkeitsbereiche, Prozessarchitektur, Prozesssteuerung, Rollenabdeckung und Adaption untersucht. Komponentenorientierte Vorgehensmodelle sind sowohl Weiterentwicklungen bekannter konventioneller Vorgehensmodelle als auch ausschließlich auf die komponentenorientierte Entwicklung ausgerichtet. Obwohl die ausgewählten Vorgehensmodelle speziell auf eine komponentenorientierte Entwicklung ausgerichtet sind, zeigt sich, dass wesentliche Lebenszyklen einer Komponente nur rudimentär behandelt werden. Eine Ausnahme bildet hier Catalysis.

Storleken och komplexiteten på dagens system och applikationer ökar. Detta leder till att kraven på system och applikationer ökar också eftersom kunderna kräver av dagens system full funktionalitet inom olika typer av distribuerade miljöer. Kunder är inte bara intresserade av funktionerna i systemen och applikationerna, de förväntar sig också att systemet skall vara av god kvalitet. Av dessa skäl är det mycket viktigt att testa system och applikationer för att säkerställa att de uppfyller kundernas förväntningar. Däremot är det inte bara själva mjukvarans kvalitets frågor som organisationer behöver ha i åtanke, en lika viktig del är själva testprocessens kvalitet. För att öka testprocessens kvalitet  krävs det en utvärdering av processen. Utvärderingen identifierar processens styrkor, svagheter och möjligheter. I detta examensarbete har vi utvärderat tesprocessen på ett utvecklingsföretag. Utvärderingen har baserats på anvisningar och rekommendationer från TMMi-modellen, Test Maturity Model Integrated. Vi hade som mål att lyfta fram förbättringsförslag till företagets testprocess. Efter utvärderingen kom vi fram till vilken mognadsnivå verksamheten utifrån TMMi-modellen samt en mängd förbättringsförslag för att höja mognadsnivån på testprocessen.