3 resultados para beslutsstöd.
Resumo:
Dagens programvaruindustri står inför alltmer komplicerade utmaningar i en värld där programvara är nästan allstädes närvarande i våra dagliga liv. Konsumenten vill ha produkter som är pålitliga, innovativa och rika i funktionalitet, men samtidigt också förmånliga. Utmaningen för oss inom IT-industrin är att skapa mer komplexa, innovativa lösningar till en lägre kostnad. Detta är en av orsakerna till att processförbättring som forskningsområde inte har minskat i betydelse. IT-proffs ställer sig frågan: “Hur håller vi våra löften till våra kunder, samtidigt som vi minimerar vår risk och ökar vår kvalitet och produktivitet?” Inom processförbättringsområdet finns det olika tillvägagångssätt. Traditionella processförbättringsmetoder för programvara som CMMI och SPICE fokuserar på kvalitets- och riskaspekten hos förbättringsprocessen. Mer lättviktiga metoder som t.ex. lättrörliga metoder (agile methods) och Lean-metoder fokuserar på att hålla löften och förbättra produktiviteten genom att minimera slöseri inom utvecklingsprocessen. Forskningen som presenteras i denna avhandling utfördes med ett specifikt mål framför ögonen: att förbättra kostnadseffektiviteten i arbetsmetoderna utan att kompromissa med kvaliteten. Den utmaningen attackerades från tre olika vinklar. För det första förbättras arbetsmetoderna genom att man introducerar lättrörliga metoder. För det andra bibehålls kvaliteten genom att man använder mätmetoder på produktnivå. För det tredje förbättras kunskapsspridningen inom stora företag genom metoder som sätter samarbete i centrum. Rörelsen bakom lättrörliga arbetsmetoder växte fram under 90-talet som en reaktion på de orealistiska krav som den tidigare förhärskande vattenfallsmetoden ställde på IT-branschen. Programutveckling är en kreativ process och skiljer sig från annan industri i det att den största delen av det dagliga arbetet går ut på att skapa något nytt som inte har funnits tidigare. Varje programutvecklare måste vara expert på sitt område och använder en stor del av sin arbetsdag till att skapa lösningar på problem som hon aldrig tidigare har löst. Trots att detta har varit ett välkänt faktum redan i många decennier, styrs ändå många programvaruprojekt som om de vore produktionslinjer i fabriker. Ett av målen för rörelsen bakom lättrörliga metoder är att lyfta fram just denna diskrepans mellan programutvecklingens innersta natur och sättet på vilket programvaruprojekt styrs. Lättrörliga arbetsmetoder har visat sig fungera väl i de sammanhang de skapades för, dvs. små, samlokaliserade team som jobbar i nära samarbete med en engagerad kund. I andra sammanhang, och speciellt i stora, geografiskt utspridda företag, är det mera utmanande att införa lättrörliga metoder. Vi har nalkats utmaningen genom att införa lättrörliga metoder med hjälp av pilotprojekt. Detta har två klara fördelar. För det första kan man inkrementellt samla kunskap om metoderna och deras samverkan med sammanhanget i fråga. På så sätt kan man lättare utveckla och anpassa metoderna till de specifika krav som sammanhanget ställer. För det andra kan man lättare överbrygga motstånd mot förändring genom att introducera kulturella förändringar varsamt och genom att målgruppen får direkt förstahandskontakt med de nya metoderna. Relevanta mätmetoder för produkter kan hjälpa programvaruutvecklingsteam att förbättra sina arbetsmetoder. När det gäller team som jobbar med lättrörliga och Lean-metoder kan en bra uppsättning mätmetoder vara avgörande för beslutsfattandet när man prioriterar listan över uppgifter som ska göras. Vårt fokus har legat på att stöda lättrörliga och Lean-team med interna produktmätmetoder för beslutsstöd gällande så kallad omfaktorering, dvs. kontinuerlig kvalitetsförbättring av programmets kod och design. Det kan vara svårt att ta ett beslut att omfaktorera, speciellt för lättrörliga och Lean-team, eftersom de förväntas kunna rättfärdiga sina prioriteter i termer av affärsvärde. Vi föreslår ett sätt att mäta designkvaliteten hos system som har utvecklats med hjälp av det så kallade modelldrivna paradigmet. Vi konstruerar även ett sätt att integrera denna mätmetod i lättrörliga och Lean-arbetsmetoder. En viktig del av alla processförbättringsinitiativ är att sprida kunskap om den nya programvaruprocessen. Detta gäller oavsett hurdan process man försöker introducera – vare sig processen är plandriven eller lättrörlig. Vi föreslår att metoder som baserar sig på samarbete när processen skapas och vidareutvecklas är ett bra sätt att stöda kunskapsspridning på. Vi ger en översikt över författarverktyg för processer på marknaden med det förslaget i åtanke.
Resumo:
Denna rapport behandlar vilka egenskaper som är viktiga att ta hänsyn till vid val av rapportverktyg inom området Business Intelligence. Begreppet BI är relativt omfattande och syftar till färdigheter, teknologier, applikationer och metoder av systematisk och vetenskaplig art som en organisation använder för att bättre förstå sin verksamhet, sin omgivning och omvärld. Rapportverktyg utgör således en mindre del i en större kedja av processer för att stödja beslutstagande.Landstinget Dalarna har anlitat Sogeti, som har varit vår uppdragsgivare för detta examensarbete, för att implementera BI i sin verksamhet och vår studie har sitt ursprung i att Landstinget Dalarna idag har ett stort behov av olika typer av rapporter i många olika delar av organisationen. Rapportbehovet har visat sig vara omfattande och för att lätta på arbetsbördan för de systemutvecklare som skapar rapporter har funderingar framkommit att det skulle kunna vara en bra lösning att låta användarna inom Landstinget Dalarna själva skapa en del av sina egna rapporter. Målet med arbetet är att ge de systemutvecklare som arbetar i projektet riktlinjer kring vilka egenskaper olika rapportverktyg innehar för att de enklare skall kunna avgöra vilket som är lämpligast att använda. De verktyg som i denna studie jämförs med varandra är Report Builder 3.0, PowerPivot samt Dashboard Designer 2010, samtliga från Microsoft.För att göra denna jämförelse mellan olika rapportverktyg krävs bra underlag för att kunna förstå vilka egenskaper som är relevanta att fokusera på samt om några egenskaper väger tyngre än andra.Efter att ha utfört intervjuer med systemutvecklare som arbetar med BI har vi kunnat skapa oss en tydligare bild av detta område. Egenskaperna har sammanställts för att användas i vår jämförelse mellan de olika rapportverktygen. Att dessa egenskaper är av vikt bekräftas till viss del av den teori som finns på området. De egenskaper som främst visar sig vara viktiga i valet är vilken befintlig plattform som används, verktygets möjlighet att skapa interaktiva rapporter samt vilken typ av användare verktyget riktar sig till. Även andra egenskaper visar sig vara viktiga att ta hänsyn till, men då främst beroende på vilka krav som ställs. Resultatet av den praktiska jämförelsen mellan de olika rapportverktygen visar att verktygen till viss del överlappar varandra i funktionalitet samtidigt som de är anpassade för olika typer av användare och plattformar. De utgör allihop delar i Microsofts BI-pussel som på olika sätt skall bidra till att alltid kunna täcka upp de krav som kan finnas beroende på behov och förutsättningar. Samtidigt visar det sig att jämförda rapportverktyg besitter vissa generella egenskaper som gör att verktygen i stora drag klarar, om än på olika sätt, att skapa snarlika rapporter.
Resumo:
Syftet med denna studie är att undersöka fördröjningsskillnader inom användargränssnitt mellan nativeutvecklade appar (utveckling till varje plattform) och appar av typen generated apps. Eftersom arbetet syftar till att bidra med information om prestanda ansågs en experimentell metod vara det bästa valet. Mätning av laddningstider gjordes med hjälp av en videokamera som filmade utförandet av experimenten vilket gjorde metoden simpel och liknar det som en användare kommer att uppleva. Avgränsning till plattformarna Android och iOS gjordes där Xamarin valdes som ramverk inom tekniker som skapar generated apps. Mätdata från experiment som undersökte laddningstider, experiment med användare som hanterade listors respons samt undersökning av CPU och minnesanvändning tyder på ett återkommande mönster. Xamarin Forms med XAML är den teknik som presterat sämst under experimenten som sedan följs av Xamarin Forms. Xamarin Android/iOS hade inte lika stora prestandaförluster jämfört med nativeutvecklade delar. Generellt hanterar Xamarin Forms telefonens resurser sämre än vad Xamarin Android/iOS och native gör. Resultat från studien kan användas som beslutsstöd vid val av teknik. Studien bidrar även med data som kan användas vid vidare forskning inom området.