<p>Mikael Svanberg skrev 2003 en doktorsavhandling där han beskriver en metod för att givet ett antal olika kandidatarkitekturer välja den som på bäst sätt uppfyller den blandning av kvalitativa krav som ställs på ett system. Denna rapport innehåller en fallstudie av Svanbergs metod applicerad på en webbapplikation beställd av GreenIT. Applikationen ska tillämpa en metod för mätning och relation av ansvarsfullt företagande med ett enkätformulär. Metoden bygger på principialkomponentsanalys (PCA) och är framtagen i ett examensarbete av Helen Josefsson 2009.Svanbergs metod, ”Architechture Evaluation and Selection Method”, appliceras på den beräkningstunga PCA-modulen i applikationen i syfte att utvärdera metoden med avseende på vilken kvalitet resultatet har, hur kostnadseffektiv den är samt när den lämpar sig bäst att användas.Tre stycken kandidatarkitekturer, Layers, Pipes and Filters och Blackboard, och fyra stycken kvalitetsattribut, Effektivitet, Pålitlighet, Underhållbarhet och Säkerhet, väljs ut och används som indata i metoden som bygger på Analytisk Hierarkisk Process (AHP).Metoden visar att Layers tillhandahåller den bästa blandningen av dessa kvalitetsattribut med stor säkerhet. Svanbergs metod lämpar sig väl som beslutsstöd för arkitekturval med den mängd invariabler som använts. Men eftersom beräkningarna i jämförelserna som utförs i AHP växer kvadratiskt så bör denna process automatiseras för att vara kostnadseffektiv för större mer komplexa system.</p>

Tidigare forskning indikerar att icke-funktionella krav är åsidosatta i agila utvecklingsprocesser. De involveras sent i projektet eller ad hoc. Detta är negativt då det kan leda till försenad leverans, ökade kostnader och produkter med bristande kvalitet. Inom konsumenthandeln är icke-funktionella domäner såsom användbarhet en tydlig konkurrensfördel. Syftet med denna litteraturgranskning är att undersöka hur icke- funktionella krav kan involveras i kravhanteringsprocessen för agila systemutvecklingsprojekt. Litteraturgranskningen ämnar även att kategorisera de identifierade metoderna. Via sökning i databaserna Web of Science och Scopus fann författarna 152 studier. Efter screening och kvalitetsgranskning inkluderades 19 studier i den slutgiltiga granskningen. Dessa analyserades och kategoriserades efter vilka steg i kravhanteringsprocessen de berörde. Resultatet visade att framför allt insamling av icke- funktionella krav var mer frekvent förekommande i materialet, 11 studier behandlade detta. Validering av krav var minst förekommande, enbart en studie redogjorde för denna del. Mer forskning behövs inom ämnet, framför allt kopplat till utvecklingsprojekt i praktiken.

Mikael Svanberg skrev 2003 en doktorsavhandling där han beskriver en metod för att givet ett antal olika kandidatarkitekturer välja den som på bäst sätt uppfyller den blandning av kvalitativa krav som ställs på ett system. Denna rapport innehåller en fallstudie av Svanbergs metod applicerad på en webbapplikation beställd av GreenIT. Applikationen ska tillämpa en metod för mätning och relation av ansvarsfullt företagande med ett enkätformulär. Metoden bygger på principialkomponentsanalys (PCA) och är framtagen i ett examensarbete av Helen Josefsson 2009.Svanbergs metod, ”Architechture Evaluation and Selection Method”, appliceras på den beräkningstunga PCA-modulen i applikationen i syfte att utvärdera metoden med avseende på vilken kvalitet resultatet har, hur kostnadseffektiv den är samt när den lämpar sig bäst att användas.Tre stycken kandidatarkitekturer, Layers, Pipes and Filters och Blackboard, och fyra stycken kvalitetsattribut, Effektivitet, Pålitlighet, Underhållbarhet och Säkerhet, väljs ut och används som indata i metoden som bygger på Analytisk Hierarkisk Process (AHP).Metoden visar att Layers tillhandahåller den bästa blandningen av dessa kvalitetsattribut med stor säkerhet. Svanbergs metod lämpar sig väl som beslutsstöd för arkitekturval med den mängd invariabler som använts. Men eftersom beräkningarna i jämförelserna som utförs i AHP växer kvadratiskt så bör denna process automatiseras för att vara kostnadseffektiv för större mer komplexa system.

Gränssnittsdesign är en av de viktigaste aktiviteterna vid systemutveckling, eftersom gränssnittet utgör den beståndsdel för vilket slutanvändare kommer göra sin primära helhetsbedömning av systemet utefter. Det innebär att gränssnittsdesignarbetet har en avgörande roll för hur systemet kommer att mottas och bedömas vid leverans och upphandlingar av system. Att designa tillfredställande gränssnitt handlar om att ta hänsyn till en rad olika human computer interaction (HCI)-aspekter. Dessa är användbarhet, användarupplevelse samt estetik, det vill säga hur visuellt tilltalande gränssnittet är. Följande tre aspekter kommer på olika sätt påverka hur en användare upplever ett system, vilket i sin tur kommer påverka huruvida en beställare är beredd att investera i ett system. Att utveckla gränssnitt för system innebär ofta att designers och utvecklare måste göra avvägningar kring i vilken mån en designer skall få realisera gränssnittsdesign. Detta eftersom en samansättning av för många visuella gränssnittselement kan få inverkan på systemets prestanda. Stundtals hamnar de två elementen, visuella designattribut och systemkrav, i konflikt med varandra och i de fall där de senare föregår designattribut ställs gränssnittsdesigners inför en utmaning eftersom att de bli begränsade i sitt arbete. Trots detta ställs dock samma krav på att designers skall uppnå tilltalande gränssnitt som väcker känslor av professionalism, samtidigt som systemet skall bibehålla optimal systemprestanda och funktionalitet.Syftet med denna studie var att undersöka hur ett tillfredställande gränssnitt i aspekter av estetik, användbarhet och användarupplevelse kan designas i ett standardsystem när designarbete begränsas till att enbart kunna justera placering och färg av gränssnittselement. Detta har inneburit en designforskningsansats bestående av en iterativ utvecklingsprocess där ett gränssnitt designat och realiserat baserat på av teorin förslagna riktlinjer för gränssnittsdesign som fortfarande har varit möjliga att tillämpa trots designarbetets begränsningar. Gränssnittet har därefter utvärderats genom experiment i form av användbarhetstester och expertutvärdering. Empirisk data från utvärderingarna har därefter analyserats och införlivats i gränssnittet och slutligen har en slutsats genererats och presenterats.Studiens resultat visar att genom en kombination av befintliga teoribaserade riktlinjer kommer designers en god bit på väg för att lyckas design tillfredställande gränssnitt i aspekter av estetik, användbarhet och användarupplevelse. I slutet av studien presenteras detta i form av sju nya riktlinjer. Variabeln användarupplevelse visade sig dock vara svårare att designa för i studiens begränsade kontext. Detta beror på att användarupplevelse är en svår variabel att utvärdera på grund av dess subtila natur. Slutligen presenteras förslag för framtida forskning och på vilket sätt studiens resultat vidare bör beprövas. / User-Interface design is one of the most important aspects of development of a system, as the user-interface is one of the elements that the user primarily will take in consideration when assessing a system. This means that user-interface design plays an important role in how the system will be received and assessed at procurement. A designer has to consider a couple of human computer interaction (HCI)-aspects such as usability, user experience, and aesthetics, in order to design a satisfactory user-interface. These three aspects of human computer interaction affect user experience of a system, which will influence a client’s decision on investment in the system. Designing a user-interface of a system often means that designers and developers have to consider the extent to which a designer can implement their version of the interface. A composition of many visual interface elements can have an impact on the systems performance. Sometimes the visual design attributes can conflict with the system requirements. If designers are challenged system requirements are prioritised because they will be limited in their work. Despite those limitations, the designers are still needed to design an appealing user-interface that can invoke feelings of professionalism, parallel to the system requirement of optimal performance and functionality.The purpose of this study was to explore how an appealing user-interface with regards to aesthetics, usability and user experience can be designed when the design work is limited to only be able to adjust placement and visual appearance in terms of names and colour of UI elements. This has been explored by doing an iterative development process in which an interface has been designed and developed based on guidelines from theory on user-interface design which the authors has been able to implement based on the limitations on the design work. The interface has subsequently been evaluated by experiments in terms of usability tests and an expert evaluation in the form of a heuristic evaluation. The evaluations resulted in empirical data which has been analysed and set against existing theory upon which a conclusion has been generated and presented.The result of the study show that designers are well on the way to successfully design an appealing user-interface in relation to aesthetic, usability and user experience, which the authors presents in the form of seven new guidelines. The variable user experience turned out to be more difficult to design in the study’s limited context. The authors believe that one of the reasons for this is that user experience is difficult to evaluate because of its subtle nature. Lastly we present suggestions for future research and how the results of the study should be further proved.

I det här arbetet har vi undersökt hur man kan generalisera en samling krav för att därigenom generalisera det system som kraven ligger till grund för. På det sättet kan man göra ett system tillämpbart över fler användningsområden än det ursprungligen var avsett för. Vi har utvecklat två artefakter i form av en stegmodell och en prototyp för att uppnå detta.

När en grupp utvecklare jobbar med samma kodbas kan konflikter uppstå med avseende på implementationen av moduler eller delsystem som varje utvecklare individuellt jobbar på. Dessa konflikter måste snabbt lösas för att projektet ska fortskrida och inte stagnera. Utvecklare som sällan kommunicerar framför ofta okompatibla moduler eller delsystem som kan vara svåra eller omöjliga att integrera i kodbasen, detta leder ofta till s.k. “integration hell” där det kan ta väldigt lång tid att anpassa ny kod till en befintlig kodbas.En strategi som man kan ta till är “continuous integration”, ett arbetssätt som erbjuder en rad fördelar när man jobbar i grupp på en gemensam kodbas. Continuous integration är möjligt att tillämpa utan verktyg eftersom detta är ett arbetssätt. Däremot kan processen stödjas av ett s.k. “CI-system” som är något av en teknisk implementation eller påtagligt införlivande och stöd för arbetsmetoden “continuous integration”.Denna rapport syftar till att ge en inblick i vad ett CI-system är och vad den principiellt består av. Vi undersöker vad ett CI-system absolut måste bestå av genom en litteraturundersökning och en marknadsundersökning. Vi ställer upp dessa beståndsdelar som “funktionella” och “icke-funktionella” krav för ett typiskt CI-system. Vi kan på så vis kvantifiera och kategorisera olika komponenter och funktionaliteter som bör innefattas i ett typiskt CI-system. I denna rapport finns även ett bihang som visar hur man kommer igång med att bygga en egen CI-server mha. CI-systemmjukvaran “TeamCity”.Slutsatsen av vår rapport är att CI-system är ett viktigt redskap som kan underlätta mjukvaruutveckling. Med hjälp av CI-system kan man stödja utvecklingsprocessen genom att bl.a. förhindra integrationsproblem, automatisera vissa delar av arbetsprocessen (kompilering av källkod, testning av mjukvara, notifikation om stabilitet av kodbas och distribution av färdig mjukvara) samt snabbt hitta och lösa integrationsfel. / When a group of developers work on the same code base, conflicts may arise regarding the implementation of modules or subsystems that developers individually work on. These conflicts have to be resolved quickly in order for the project to advance at a steady pace. Developers who do not communicate changes or other necessary deviations may find themselves in a situation where new or modified modules or subsystems are impossible or very difficult to integrate into the mainline code-base. This often leads to so called “integration hell” where it could take huge amounts of time to adapt new code into the current state of the code-base. One strategy, which can be deployed to counteract this trend is called “continuous integration”. This practice offers a wide range of advantages when a group of developers collaborates on writing clean and stable code. Continuous integration can be put into practice without the use of any tools as it is a “way to do things” rather than an actual tool. With that said, it is possible to support the practice with a tangible tool called a CI-system.This study aims to give insight into the makings of a CI-system and what it fundamentally consists of and has to be able to do. A study of contemporary research reports regarding the subject and a survey was performed in order to substantiate claims and conclusions. Core characteristics of CI-systems are grouped into “functional requirements” and “non-functional requirements (quality attributes)”. By doing this, it is possible to quantify and categorize various core components and functionalities of a typical CI-system. This study also contains an attachment which provides instructions of how to get started with implementing your own CI-server using the CI-system software ”TeamCity”. The conclusion of this study is that a CI-system is an important tool that enables a more efficient software development process. By making use of CI-systems developers can refine the development process by preventing integration problems, automating some parts of the work process (build, test, feedback, deployment) and quickly finding and solving integration issues.

Denna studie problematiserar icke-funktionella krav (IF krav), även benämnt kvalitetskrav, i svenska mjukvaruutvecklingsprojekt. Kravhantering anses vara den mest avgörande delen i mjukvaruutveckling för att lyckas, vilket än idag är en utmaning i majoriteten av projekten. Särskilt svårt är det att lyckas med IF krav, då tvetydigheter leder till brist på dokumentation och slutligen bortprioriteras de. För att adressera dessa problem syftade denna studie att besvara hur väl de IF kraven dokumenteras inom svenska mjukvaruutvecklingsprojekt samt vem som kan ansvara för att kvalitetssäkra de IF kraven. En mixed-method har genomförts med både en kvalitativ litteraturstudie av tidigare forskning samt en kvantitativ studie. Datainsamlingen i den kvantitativa studien har skett med webbaserad enkätundersökning med 24 frågor. Enkäten skickades ut till 72 företag i Sverige vars huvudsyssla var mjukvaruutveckling. Sammanlagt samlades 43 svar in och en univariat analys genomfördes. Enkätundersökningen indikerade att respondenterna är positivt inställda till dokumentation av IF krav. De flesta saknar dessutom gedigen kunskap om IF krav. Vidare saknas tydliga ansvarsroller för dokumentationen av IF krav. En lösnings- eller mjukvaruarkitekt är bäst lämpad för att kvalitetssäkra de IF kraven. Denna studie är skriven på svenska och kan främja studenter, forskare och yrkesverksamma då den nyanserar vikten av IF krav och hur existerande brister kan förbättras. / This study examines non-functional requirements (NFRs), also known as quality requirements, in Swedish software development projects. Requirements engineering is considered the most crucial part of software development, which is still a challenge in the majority of projects today. In particular, the NFRs are the most challenging seeing as there are ambiguities concerning their definition. This in turn leads to lack of documentation and, ultimately, their deprioritization. To address these issues, this study aimed to answer how well NFRs are documented in Swedish software development projects and who can be responsible for ensuring the quality of these NFRs. A mixed-method was conducted with both a qualitative literature review of previous research and a quantitative study. The data collection in the quantitative study was conducted using a web-based survey with 24 questions. The survey was sent to 72 software development companies in Sweden. A total of 43 responses were collected, and a univariate analysis was performed. The survey indicated that respondents have a positive attitude towards documenting. Additionally, most respondents lack comprehensive knowledge about NFRs and clear roles for the NFRs are missing. Standardization, better guidelines, and clear roles are needed to ensure the quality of NFRs, which are currently lacking. A solution or software architect is best suited to ensure the quality of NFRs. This study, written in Swedish, can benefit students, researchers, and professionals as it highlights the importance of NFRs and suggests improvements for existing deficiencies.