Detta arbete är en jämförande studie mellan mätningar inom användbarhet. Studien jämför en heuristisk utvärdering med ett användartest, med inriktning på ekonomi och resultat. Syftet är att belysa den ekonomiska aspekten mellan de två metoderna. Samtidigt undersöker studien om heuristisk utvärdering är en metod som lämpar sig som beslutsunderlag. Studien är genomförd på ett tryckeri där tryckeriets IT-system har testats och utvärderats utifrån de två metoderna. Studien baseras på kvalitativa och kvantitativa metoder så som strukturerade och ostrukturerade intervjuer, observationer och enkäter.Arbetet behandlar användbarhet som begrepp och metoder för hur användbarhet mäts. Relevant teori presenteras i teoridelen och behandlas i diskussionen. De båda metoderna var relativt lika varandra. Den stora skillnaden ligger i att användartestet gav mätbara resultat medan den heuristiska utvärderingen resulterade i en givande diskussion. Ur ett ekonomiskt perspektiv var den heuristiska utvärderingen betydligt billigare att genomföra. Undersökningen visar att den heuristiska utvärderingen fungerar bra. Dock bör metoden undersökas ytterligare för att styrka påståendet. / Resource-saving methods in usability This essay is a comparative study of measuring usability. The study compares a heuristic evaluation with a usability test, with focus on economy and performance. The aim is to highlight the economic aspect between the two methods, also if the study of heuristic evaluation is a method suitable for decision-making. The study is conducted on a printing company where the company’s IT systems have been tested and evaluated on the basis of the two methods. The study is based on qualitative and quantitative methods such as structured and unstructured interviews, observation and questionnaires.The study deals with usability as a concept and different methods for measuring usability. Relevant theory is presented in the theoretical part and is discussed and addressed in the discussion.Both methods were relatively similar. The major difference is that the user test yielded measurable results, while the heuristic evaluation resulted in a fruitful discussion. From a financial perspective, the heuristic evaluation is significantly cheaper to implement. The study shows that the heuristic evaluation works well. However, the method should be further investigated to prove the claim.

Since the internet breakthrough in the nineties, the importance of digital technology has increased for organizations, and industries in Sweden. Digital technology allows for more efficient ways of learning. This means that practitioners must change the way they work to be able to integrate technology to exploit the advantages of the new tools. But sometimes the problem occurs that the technology gets developed without the input of the to-be users. This can harm the potential efficiency of the technology being implemented in an organization, or company. This study looks at digital technology in schools and tries to find out which features teachers wants to see in a program developed to create value in their practice. From interviews with teachers that teach math in grades 1-3 have I created a list of recommendations that a company or organization should consider when developing software for this target audience. These recommendations will consider aspects of organizational limitations and opportunities of schools; the aspects from what functionality should be in said services, and how to develop services around current practice of teachers.

<p>Kunskapsöverföring är en nödvändig förutsättning för att säkerställa organisationers existens och framåtskridande. Utgångspunkt för denna uppsats är förstudiens roll i mjukvaruprojekt och dess betydelse för den fortsatta systemutvecklingsprocessen. Fokus liggerpå kunskap som genereras under förstudien, samt hur och i vilken omfattning kunskapen förs vidare till analysfasen i systemutvecklingsprocessen. </p><p>Resultatet visar att förstudien utgör ett viktigt beslutsunderlag och är en nödvändig förutsättning för att gå vidare i systemutvecklingsprocessen. Kunskapsöverföring genom dokumentation och via muntliga föredragningar är otillräcklig, eftersom det finns ett ”filter” som innebär att erfarenhetsbaserad kunskap inte överförs mellan förstudie och analys via dokument eller via muntliga föredragningar. Därför måste personer som deltar i förstudien finnas med senare i utvecklingsprocessen, för att artikulera den ”tysta” erfarenhetsbaserade kunskapen till explicita former. </p><p>Vi drar slutsatserna att kunskapsöverföring via dokument är bra, men räcker inte enligt vår mening. Då det mesta av kunskapen är implicit, det vill säga tyst och/eller ordlös, kommer den inte med i en skriftlig rapport. Kompletteras rapporten med muntliga föredragningar, kommer man ytterligare ett steg närmare en optimal kunskapsöverföring, men det räcker fortfarande inte, då den tysta kunskapen alltjämt utgör ett hinder. Kunskapsöverföring måste ske genom personer, som finns med både i förstudie- och analysfasen, men det måste tillskapas arenor för kunskapsomvandling och kommunikation. Genom en arena för kunskapsomvandling kan den tysta kunskapen göras kommunicerbar. En arena för kommunikation utgör sen den sista byggstenen på väg mot en effektiv kunskapsöverföring. Kunskapsöverföring måste "organiseras". Vi lämnar därför ett förslag till en kunskapsöverföringsmodell. </p> / <p>Knowledge transfer is necessary condition to guarantee the existence and progress of organisations. The starting-point for this paper is the role of the feasibility study in a software project and it’s significance for the subsequent system development process. The focus is on knowledge, which is generated under the feasibility study, and how and in which dimension knowledge is bringing on to the analysis in the system development process. </p><p>The result shows that the feasibility study is an important base of decision and a necessary condition of the future system development process. Knowledge transfer by documentation and by oral presentation of reports is insufficient, because there is a"filter"which means that knowledge of experience not will be transferred between feasibility study and analysis by documentation and by oral presentation. Furthermore must persons who are involved in the feasibility study occur even later in the development process, to articulate the "silence" knowledge of experience into explicit forms. </p><p>We draw the conclusions that knowledge transfer by documents is good, but not enough in our opinion. Because most of the knowledge is implicit, which means silent and/or without words, it will not been in the report. If the report will be completed with oral presentations, you will came further one step near an optimal knowledge transfer, but it’s still not enough, because the silent knowledge still is an obstruction. Knowledge transfer must be done by persons, who’s in both the feasibility study and analysis, but there must be an arena for knowledge transformation and communication. Through an arena for knowledge transformation the silent knowledge can be communicative. An arena for communication is then the last stone of building an effective knowledge transfer. Knowledge transfer must be "organised". We therefore present a proposal to a model of knowledge transfer.</p>

<p>The aim of this study is to get a deeper understanding about user tests as well as answer the question about if testing for users is necessary at all times. I've done a comparison between what the literature says, and what a company says, about testing. The tests that's been in focus in this study is prototyping and card sorting tests. Prototyping aims to give the developer feedback about the design and check if there are any obvious problems with the design. A card sorting test can be used to get input about how information architecture should be constructed. Information architecture is how the links are related in a navigation system. The company doesn't think that testing is as important as the literature. The company doesn't usually test but for the current situation they did it since the interface is crucial for their clients business. The conclusion of this study is that testing is rather important. For a designer who hasn’t got that much experience, user testing can be a way to get feedback about his designs. A more experienced designer might not need to test as much but he should be aware of testing as a possible design tool.</p>

Syfte - Syftet med den här uppsatsen var att via befintlig litteratur undersöka vilka modeller som finns för att välja systemutvecklingsmetod. Vidare syftade uppsatsen till att testa modellerna på några av de vanligast förekommande utvecklingsmetoderna. Detta skedde med hjälp av ett förenklat exempelprojekt. Metod – Metoden till den här uppsatsen var en litteraturstudie. En litteraturstudie sammanställer tidigare forskning kring ett ämne för att skapa nya perspektiv. Litteraturen till den här uppsatsen inhämtades från journalartiklar, konferenser och böcker. Analys och slutsatser – Omfånget av den här uppsatsen sträckte sig till att se på tre modeller för att välja systemutvecklingsmetod. Dessa var SDM-ES, Big-M och CUQuP. SDM-ES är ett automatiserat expertsystem som drar slutsatser utifrån uppskattningar av användaren. Big-M består i sin enklaste form av en matris. Användaren plottar in det aktuella projektet i matrisen. CUQuP väger ihop tre olika faktorer för varje utvecklingsfas som anses viktig i ett projekt. Dessa faktorer matas sedan in i en formel som genererar en poängsumma. Den utvecklingsmetod som får högst poäng är bäst lämpad för projektet. Gemensamt för modellerna är att de baserar sina val av utvecklingsmetod på ett antal faktorer. Några av dessa faktorer är gemensamma för modellerna medan andra skiljer sig åt. För att testa modellerna applicerades de på utvecklingsmetoderna: Extreme Programming (XP), Rapid Application Development (RAD) och vattenfallsmodellen. För att appliceringen skulle bli meningsfull var det nödvändigt att skapa ett exempelprojekt. Resultatet visade att samtliga utvecklingsmetoder valde RAD som den mest lämpliga utvecklingsmetoden för exempelprojektet. Två av tre valde vattenfallsmodellen som näst mest lämplig. Med andra ord fanns det en relativt hög grad av samstämmighet mellan modellerna. De skulle emellertid krävas en mer omfattande studie för att klarlägga om detta stämmer. / Purpose – The purpose of this paper was to identify and describe models that help developers choosing a system development methodology. Furthermore the purpose was to test the models on some common system development methodologies. In order to do so a simple example project was created. Methodology - This paper was conducted through a literature review. A literature review collects and compiles research on a subject to create new perspectives.  The literature for this paper was collected from science journals, conference papers and books. Analysis and conclusions – This paper delimited itself to only examine three models for choosing a development methodology. The models were: SDM-ES, Big-M and CUQuP. SDM-ES is a rule based expert system that draws conclusions bases on user input. In its simplest form, Big-M uses a matrix in order to decide which development methodology that should be used. Based on estimations of system criticality and project size the user can decide were in the matrix the project belongs. With the help of a formula CUQuP calculates a score for each considered development method. The methodology that receives the highest score is generally considered to be most suitable for the project. All models have a common characteristic. In one way or another they all use factors, such as system criticality and project size, to decide which development method that should be used. In order to test the models three development methodologies were used. Those were Extreme Programming (XP), Rapid Application Development (RAD) and the waterfall model. To make the test meaningful it was necessary to create an example project. The result showed that all three models chose RAD as the best development methodology for the example project. Furthermore two out of three models considered the waterfall model to be the second best option. In other words it seems to be a high degree of coherence between the models. However the scope of this paper is too narrow to decide if that’s true.

<p>Användbarhet är en term som används för att bedöma kvaliteten hos ett gränssnitt. God användbarhet är viktig då den ger en ökad produktivitet och andra affärsfördelar i form av färre misstag och bättre kvalitet på slutprodukten. Användbarhet är en viktig designprincip men är en svår egenskap att uppfylla hos applikationer. </p><p>Studien behandlar användbarhet ur olika perspektiv, dels det teoretiska genom litteraturgenomgång, dels det praktiska genom intervjuer och observationer. Syftet var att förklara vad användbarhet är, hur det bedöms och vad man kan göra för att bygga in egenskapen i applikationer man utvecklar. För att exemplifiera och finna verklig förankring har jag valt att observera hur användare interagerar med ett existerande gränssnitt för bibliotek, Horizon. </p><p>Slutsatser kring studien är att Horizon inte används till allt den var tänkt att användas till, vilket i princip är ett dåligt betyg för en applikation. Samtidigt är detta inget större problem då den negativa verkan på verksamheten kan i det här fallet vara en definitionsfråga: är studenternas produktivitet när det gäller att söka och beställa litteratur kritisk? </p><p>När det gäller användbarhet i utvecklingsskedet kan man konstatera att även om intentionerna varit goda så har användbarhetsarbetet kring Horizon inte infriat förväntningarna. Vad som gått fel är varken sensationellt eller ovanligt; det har handlat om avsaknaden av slutanvändarens perspektiv, organisatoriska problem och möjligen också bristande kunskap om användbarhet i en eller annan form. En betydelsefull insikt som inte nämns i litteraturen men som togs upp är att beakta leverantörens marknadsställning när man ska köpa ett system. Trots bristerna, som ofta relaterar till brott mot designkonventioner, upplevs Horizon som ett bra och ändamålsenligt verktyg av sina användare. </p> / <p>Usability denotes the quality of a user interface. Even though usability is an important design principle, efforts to incorporate this quality in applications often fail. In this paper I study usability from a theoretical and a practical perspective. The goal is to explain usability and how to incorporate usability in applications. In order to exemplify, I study usability within the context of the library application Horizon. </p><p>This study shows that Horizon is only partially utilized by its users which in principle is a bad grade for an application. Partial use is however in this case, not a serious problem since the negative effects partial use imply could very well be a matter of definition: is the productivity of students, when it comes to searching and ordering library material, critical for the organization? </p><p>When it comes to usability in the development phases of a project, once again one can conclude that good intentions exist but efforts fail all the same and Horizon is no exception. This time we can attribute failure to the lack of the end users’ perspective, organizational problems and perhaps also unsufficient knowledge of usability in one form or another. An important conclusion, which has not been mentioned in the literature, is the importance of considering the market position of a presumptive vendor when buying a generic system. Despite the flaws (often related to violations of well established design principles) presented in this paper, Horizon is considered a good, effective and efficient application by its users.</p>

Agila metoder och modeller ses ofta som nytänkande och används idag flitigt av företag och organisationer runt om i värden. I realiteten är grunden till det agila metoderna idag 13 år och mycket har hänt, både teknisk och kring sättet vi arbetar, sedan 2001. Den agila metodiken baseras på två dokument, det agila manifestet och de agila principerna, där principerna är till för att konkretisera manifestet. Eftersom principerna är konkreta anser vi att de har en stark koppling till hur agil utveckling de facto bedrivs. Vi har därför valt att undersöka hur principerna står sig bland utvecklarna över ett decennium efter att de skrevs samt om utvecklarna ser ett behov av revidering och vilka delar de i så fall skulle vilja förändra. För att ta reda på detta genomförde vi fyra intervjuer med utvecklare som alla hade olika erfarenhet av agilt arbete samt utgick från en tidigare kvantitativ undersökning i ämnet. Slutsatsen av undersökning är att de agila principerna fortfarande står sig bra bland utvecklarna men att det finns ett behov av revidering. Original utformningen är dock så pass väl fungerande att behovet inte är omedelbart. Det finns flera ämnen som våra respondenter tagit upp som är viktiga att ta hänsyn till där kvalitet och dokumentation är de ämnen som står ut i mängden. I mångt och mycket överensstämmer vårt resultat med den undersökning vi utgått från vilket tyder på att den bild som förmedlas av de båda undersökningarna har en god förankring hos utvecklarna, även om det finns områden där våra resultat skiljer sig från varandra. / Agile methodology and models has a wide group of supporters among organizations and companies and is often seen as innovative. The agile methods are now 13 years and a lot has happened since then, both in our ways of working and in the technology we use. The agile methodology is based on two documents, the agile manifesto and the agile principles. The principles embodies the manifesto and in our view creates a strong connection with reality and by that a strong connection with how software is developed. To find out if the principles still are viable and used among developers and if a revision of them is needed we performed a survey based on four interviews and a previously conducted quantitative study. The conclusion of this survey is that the principles are used and works well in development projects and are well thought of by the developers but there is still a need for a revision. How this revision would look and when it should be done is hard to say, the need for it aren’t urgent because of the general support of the original principles are still strong. There are a couple of different areas that our respondents point out as important where quality and documentation stands out as the most important that organizations working agile have to focus on in their daily work. Our survey and the study we used as an inspiration ends up in mostly the same conclusions with only few differences, which we see as a confirmation that our study reflects the developers’ view.

Inom en stor del av all systemutveckling sker testerna av systemet som sista punkt innan systemet sjösätts. Testdriven utveckling är en systemutvecklingsmetod där testerna istället skrivs först och också är det som driver utvecklingen framåt. Metoden höjs till skyarna av vissa och avfärdas omedelbart som onödigt omständig av andra. Vi vill med denna uppsats undersöka hur det ser ut i verkligheten och vilka faktorer som påverkar användandet, inlärningen och inställningen till testdriven utveckling. Vi genomförde intervjuer på tre stycken Örebrobaserade organisationer och tittade utifrån ramverket method-in-action på vilka faktorer som påverkade användningen och varför. Vi fann att utvecklarna närmade sig testdriven utveckling på väldigt olika sätt och grundade sin inställning mycket beroende på tidigare erfarenhet och inlärning – oavsett hur lång eller kort den varit. Utvecklarna förväntas ofta bedriva självstudier utanför arbetstid – något som inte alltid funkar som kunskaputvecklingsform då tiden utanför jobbet ser olika ut beroende på var i livet man är. Det finns inte heller något klart program eller best-practices att följa för att lära sig metoden i någon av organisationerna. Vi såg också att det finns tekniker utanför själva metoden som utvecklare ganska omgående behöver bli bekanta med för att kunna utveckla testdrivet: dependency injection och mock.

Systemet som förenklar hantering och information av tidrapportering, projekt, kunder, lager och anställda. Syftet är att företaget skall få en mera överblick över deras verksamhet, då all information samlas på samma ställe. De anställda kan via webben snabbt och enkelt rapportera in deras arbetstider under den gångna veckan. Systemet innefattar: SMS-tjänst, automatiskt utskick, hanteringen för lager, projekt, kunder och semester, kontinuerlig statistik med grafiska diagram samt utskriftsfunktioner. Allt är utvecklat i PHP och MySQL. / The system simplifies the management and information, about time reports, projects, customers, storage and employees. The main purpose for this system is that the company shall have a more structured overview about their company, and where all the information is gathered, at the same spot. The employees are able to report in their working progress during the week, in a simple easy way trough the internet. The system contains a SMS service, automatically circular messages, management of storage, projects, clients and employees vacations. The system also contains continuous dynamic statistics, with graphical layout and also print functionality. Everything is developed in PHP with MySQL as database. / Detta är en reflektionsdel till en digital medieproduktion. mange@mdw.se www.mdw.se

Kravhantering inom systemutveckling utgör basen för vad som ska utvecklas. Agila systemutvecklingsmetoder blir vanligare för varje dag som går. Det har dock ofta visat sig finnas utmaningar med hur man anpassar just kravhanteringen till de agila metoderna. Verksamheter har olika förutsättningar för att arbeta agilt. Lantmäteriet i Gävle uttryckte ett behov att undersöka varför den agila praxis man hade inte följdes av alla utvecklingsteam i samband med kravhanteringen. Syftet med denna uppsats var därför att undersöka varför vissa utvecklingteam i en verksamhet arbetade agilt med sin kravhantering medan vissa inte gjorde det. För att undersöka detta utförde jag en fallstudie där jag med hjälp av enkäter och intervjuer samlade in data från både utvecklare och personer på verksamhetssidan som var inblandade i kravhanteringen. Resultaten visade att orsakerna till att en agil kravhantering fungerade så olika var flera. Genom att använda en tematisk analys kunde jag urskilja några framträdande orsaker. Kommunikation och flexibilitet samt kunskap och förståelse för olika perspektiv var teman som utgjorde positiva faktorer. De teman som istället utgjorde negativa faktorer var bland andra otydliga roller, brist på direktiv, en övertro till metoder och processer, osynk mellan verksamhet och IT, prioriteringsproblem, förvaltningsplaner, attityder och IT-arkitektur. / Requirements engineering within software development is the foundation of what needs to be developed. Agile methods in software development become more common every day. It has however often been shown that there are certain challenges with how to adopt the requirements engineering to the agile methodology. Businesses have different preconditions for agile methods. Lantmäteriet in Gävle had a need to examine why not all the developing teams followed agile methods within the requirements engineering process. The purpose with this thesis was thus to examine why some developing teams in an organization worked in an agile manner with the requirements engineering, and some did not. To do this I performed a case study where I collected data through questionnaires and interviews from both developers and people from the business side. The results showed that the reasons for these differences were multiple. Communication and flexibility, and knowledge and understanding for different perspectives were the positive factors. The themes that hindered an agile way of working were, among others, unclear roles, lack of direction, too much reliance on methods and processes, discrepancy between business and IT, prioritizing issues, management plans, attitudes and IT architecture.