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.

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.