Milj¨ oaspekter

V˚art projekt ¨ar inte en skada f¨or milj¨on eftersom det endast ¨ar samling algoritmer f¨or att l¨osa och visualisera optimeringsproblem.

Om Saab skulle anv¨anda v˚art projekt i jaktflygplanet JAS 39 Gripen som projektet h¨arstammar ifr˚an, uppkommer fr˚agor kring hur pass milj¨ov¨anliga f¨oretaget Saab och Gripen ¨ar. P˚a deras hemsida (Saab AB, 2015a) kan man l¨asa om deras arbete f¨or att minska avtrycket p˚a milj¨on. De har till exempel satt upp som m˚al att reducera deras koldioxidutsl¨app fr˚an f¨ors¨aljningar med tjugo procent till ˚ar 2020. I figur 11 visas Saabs koldioxidutsl¨app och deras m˚al.

Figur 11 – Utsl¨app koldioxid Saab (Saab AB, 2015e)

F¨or att n˚a m˚alet arbetar Saab med att reducera elf¨orbrukningen p˚a deras fabriker och utsl¨app fr˚an resor vilka ¨ar de st¨orsta faktorerna f¨or deras koldioxidutsl¨app. Genom att fokusera p˚a att ¨

andra de anst¨alldas vanor, ny teknik och strategisk planering av fabrikerna har de lyckats s¨anka koldioxidutsl¨appen fr˚an fabrikerna med tjugo procent mellan ˚aren 2009 och 2014. F¨or att minska utsl¨appen fr˚an resor n¨amner Saab bland annat att de uppmuntrar resfria m¨oten och

sam˚akningar.

Deras hantering av milj¨ofarliga ¨amnen m¨oter EU’s f¨orordning REACH (Registration, Evaluation and Authorisation of Chemicals) som str¨avar efter att f¨orb¨attra skyddet av m¨anniskors h¨alsa och milj¨on fr˚an risker som kan f¨ororsakas av kemikalier (European Chemicals Agency, 2015). Saab ¨ar ¨

aven kontribut¨or till projektet Clean Sky som ¨ar det mest ambiti¨osa

luftfartsforskningsprogrammet i Europa. M˚alet med Clean Sky ¨ar att utveckla ny teknik f¨or att g¨ora luftfarten mer milj¨ov¨anlig med mindre bullriga och mer br¨ansleeffektiva flygplan. (Clean Sky, 2015)

Stridsflygplanet JAS 39 Gripen anv¨ander i dagsl¨aget en jetmotor som drivs p˚a fotogen. Fotogen ¨

ar ett fossilt br¨ansle som leder till koldioxidutsl¨app vid f¨orbr¨anning. Detta g¨or Gripen till ett system som bidrar till milj¨of¨orst¨oring.

Det verkar som att Saab har ambitioner om att sj¨alva bli milj¨ov¨anligare och att bidra till utvecklingen av milj¨ov¨anligare teknik. De g¨or dock fortfarande ett negativt avtryck p˚a milj¨on eftersom det sker utsl¨app av koldioxid och de anv¨ander milj¨ofarliga ¨amnen i deras produkter. Detta kan dock ses som en direkt f¨oljd av att det idag tyv¨arr inte ¨ar l¨onsamt att anv¨anda eller existerar effektiv milj¨ov¨anlig el och teknik.

Skulle anv¨andandet av v˚art projekt g¨ora n˚agon skillnad? Detta g˚ar tyv¨arr inte att svara p˚a d˚a kandidatgruppen saknar uppgifter p˚a hur v˚ar optimeringsl¨osare skulle bidra till milj¨ov¨anligheten hos stridsflygplanet JAS 39 Gripen.

7

Slutsatser

De slutsatser kandidatgruppen har kommit fram till ¨ar att valet av metod till

optimeringsalgoritmen inte var helt genomt¨ankt. Anledningen till detta ¨ar att kandidatgruppen saknade f¨orkunskaper inom omr˚adet och b¨or ha lagt fler timmar p˚a utbildning inom

optimeringsproblem i detta omr˚ade vilket hade lett till ¨okad f¨orst˚aelse f¨or omr˚adet p˚a ett generellt s¨att vilket hade lett till att de algoritmer som varit kandidater hade kunnat bed¨omas p˚a ett mer kvalificerat s¨att f¨or att kunna g¨ora ett mer kvalificerat val.

Kandidatgruppen ˚angrar inte valet av att ta med kravet att QuadOpt ska vara j¨amb¨ordig med Gurobi vilket inte uppn˚atts. Genom att misslyckats med detta har kandidatgruppen l¨art sig f¨orhandla krav med en kund och g¨ora sitt yttersta f¨or att matcha en kommersiell produkt vilket inte anses vara en enkel uppgift med tanke p˚a den begr¨ansade tiden kandidatgruppen haft vilket ett f¨oretag som utvecklar en produkt som Gurobi troligtvis haft st¨orre tillg˚ang av. Dock kan man dra slutsatsen att det ¨ar m¨ojligt att skapa en likv¨ardig produkt rent prestandam¨assigt om det funnits mer tid dels f¨or utveckling men framf¨or allt, som tidigare n¨amnts, utbildning.

Kandidatgruppen ˚angrar inte heller valet av att inte g˚a in i iterationerna utan en konkret utvecklingsmetod eftersom arbetet fungerade p˚a ett tillfredsst¨allande s¨att utan en s˚adan metod.

8

Fortsatt arbete

Det h¨ar projektet erbjuder m˚anga olika m¨ojligheter till fortsatt arbete f¨or alla inblandade parter. Detta inkluderar alla olika delar av projektet. Det fortsatta arbetet inneb¨ar till st¨orsta delen att vidareutveckla dessa delar f¨or att f¨orb¨attra befintliga funktioner och eventuellt l¨agga till nya funktioner till det redan befintliga programmet.

Till att b¨orja med kan det ligga i Saabs och kundens intresse att forts¨atta arbeta med produkten, framf¨or allt l¨osaren. Det mest relevanta f¨or denna part skulle till exempel vara att integrera produkten med Saabs system, ARES, vilket ligger p˚a en h¨og niv˚a i det avseendet att produkten m˚aste vara mycket p˚alitlig och effektiv f¨or att detta ska bli aktuellt. D¨arf¨or g˚ar det ¨

aven att se hur denna part skulle kunna anse att det ¨ar en bra id´e att vidareutveckla den levererade produkten f¨or att uppfylla de standarder och krav som finns. F¨or denna part finns det ¨

aven aspekten att arbeta vidare med produkten i ett rent akademiskt syfte f¨or simuleringar relaterade till Simulink och MATLAB. Detta ¨ar m¨ojligt d˚a Saab och kunden kommer ha tillg˚ang till all k¨allkod som kr¨avs f¨or dessa typer av arbete.

som finns ¨ar begr¨ansad p˚a grund av att produkten utvecklats ˚at Saab. Trots detta finns

m¨ojligheten att arbeta vidare p˚a produkten. Det som framf¨or allt skulle vara ¨onskv¨art att arbeta vidare med ¨ar att genomf¨ora omfattande tester av l¨osaren med fler typer av testdata vilket varit problematiskt p˚a grund av storleken p˚a datan. F¨or kandidatgruppen skulle fortsatt arbete ¨aven kunna inneb¨ara att den nuvarande l¨osaren skrivs om f¨or att till¨ampa en annan optimeringsmetod ¨

an den nuvarande. Den som i nul¨aget anv¨ands ¨ar Active set men det ¨ar ¨aven m¨ojligt att implementera till exempel Interior point metoden.

Unders¨oks ist¨allet enbart produkten utan att ta h¨ansyn till n˚agon av parternas perspektiv ¨ar det l¨attare att se m¨ojligheter f¨or vidareutveckling. Den del av produkten som ¨ar kopplad till

MATLAB har v¨aldigt begr¨ansad m¨ojlighet till vidareutveckling i och med att denna del i stort sett ¨ar en ¨overs¨attning av l¨osaren vilket g¨or att det ist¨allet ¨ar mer relevant att titta p˚a l¨osaren vilken har stor potential att arbetas vidare med. I l¨osaren finns det b˚ade optimeringsm¨ojligheter samt m¨ojligheten att l¨agga till eller ¨andra funktioner. N¨ar det g¨aller optimering kan man t¨anka sig att vidare arbete inneb¨ar att programmet optimeras f¨or att vara effektivare med de

tillg¨angliga resurserna f¨or att p˚a s˚a s¨att bli snabbare. De funktioner som redan finns implementerad som kan arbetas vidare med kan till exempel vara hur l¨osaren hittar sin startpunkt f¨or optimeringen.

De andra tv˚a delarna av programmet, det grafiska gr¨anssnittet och parsern, har ocks˚a potential att arbetas vidare med. Det ¨ar dock viktigt att po¨angtera att fortsatt arbete med dessa delar inte ¨ar direkt relaterade till hur l¨osaren fungerar eller prestandan hos denna vilket kan ses som att det ¨ar mindre v¨ardefullt att arbeta vidare med detta j¨amf¨ort med l¨osaren som trots allt ¨ar programmets huvudsakliga komponent.

En brist som funnits under projektet har varit viss avsaknad av testfall vilket kommer av att testfallen ¨ar stora och omst¨andiga att ta fram. Skulle det finnas tillg˚ang till fler testfall ¨ar ytterligare tester ett omr˚ade som kan arbetas vidare p˚a. Detta kan till exempel leda till att fler omr˚aden i l¨osaren kan optimeras f¨or att bli snabbare eller att eventuella brister uppdagas. Brister skulle till exempel kunna vara ovanliga specialfall som i nul¨aget inte har beaktats och som endast i enstaka fall kan leda till n˚agot problem.

Utv¨ardering av byggsystem

F¨orfattare: Alexander Yngve

Version 1.0

Status

Granskad Dennis Ljung - Godk¨and Andreas Runfalk -

1 Inledning 31 1.1 Syfte . . . 31 1.2 Fr˚agest¨allning . . . 31 1.3 Avgr¨ansningar . . . 31 2 Bakgrund 31 3 Teori 31 3.1 Make . . . 32 3.2 SCons . . . 32 4 Metod 33 5 Resultat 34 5.1 Prestanda . . . 34 5.2 Anv¨andning och vidareutveckling . . . 35 5.3 Byggsystemets p˚averkan p˚a projektet . . . 35

6 Diskussion 35

1

Inledning

Byggsystem ¨ar en viktig men ofta f¨orbisedd komponent i en utvecklares verktygsl˚ada. Byggsystemet ansvarar f¨or att automatiskt g¨ora om k¨allkoden till k¨orbara filer utan att

utvecklaren ska beh¨ova komma ih˚ag l˚anga kompilatorkommandon, s¨okv¨agar till programbibliotek och liknande. Ett bra byggsystem medf¨or en rad f¨ordelar, ¨okad produktivitet och f¨orb¨attrade m¨ojligheter till testning f¨or att n¨amna n˚agra (Clark, 2004).

I den h¨ar rapporten kommer tv˚a olika byggsystem att j¨amf¨oras med projektet

”Prediktionsreglering” som utg˚angspunkt. Projektets befintliga byggsystem implementerat i Make kommer att st¨allas mot ett nytt implementerat i SCons.

1.1

Syfte

D˚a min roll i projektet ¨ar utvecklingsledare tog jag beslutet om att anv¨anda Make som byggsystem tidigt i projektets g˚ang. Detta d˚a Make finns f¨orinstallerat p˚a b˚ade Mac och de flesta Linuxdistributioner. Syftet med den h¨ar rapporten ¨ar att utreda ett alternativ till Make och om n˚agra f¨ordelar f¨or projektet finns.

1.2

Fr˚agest¨allning

1. Vilket av de tv˚a byggsystemen har b¨ast prestanda? 2. Vilket byggsystem ¨ar l¨attast att anv¨anda och utveckla? 3. Hur hade projektet p˚averkats av ett annat val av byggsystem?

1.3

Avgr¨ansningar

Rapporten kommer ˚aterspegla resultat f¨or projektet ”Prediktionsreglering” som best˚ar av 50 k¨allkodsfiler och 159 dokumentfiler. Projektets kod ska kunna byggas och exekveras p˚a b˚ade Linux, Mac och Windows. Resultaten skulle kunna se annorlunda ut med ett projekt av annan storlek och andra krav. Byggsystemen kommer endast att j¨amf¨oras p˚a punkten att kompilera och l¨anka kod, ej k¨ora tester eller generera dokument. Detta p˚a grund av tidsbrist.

2

Bakgrund

Den h¨ar rapporten skrivs som en individuell del av kandidatgruppens gemensamma kandidatrapport i kursen TDDD77 Kandidatprojekt i programvaruutveckling f¨or civilingenj¨orsstudender i datateknik p˚a Tekniska h¨ogskolan vid Link¨opings universitet.

Kandidatgruppen best˚ar av sju studenter fr˚an ˚arskurs tre. I kursen genomf¨ors ett projekt under en termin d¨ar mjukvara utvecklas ˚at en kund fr˚an n¨aringslivet. Gruppens projekt ¨ar

”Prediktionsreglering” och utf¨ors av sju studenter d¨ar min roll ¨ar utvecklingsledare.

3

Teori

Byggsystemet tillh¨or raden av verktyg som anv¨ands v¨aldigt ofta i utvecklingsprocessen. Den vanligaste uppgiften ¨ar att kompilera och l¨anka kod, men f¨orutom det s˚a brukar byggsystemet anv¨andas till bland annat:

• Automatiska tester

• Generering av dokumentation

Byggsystemet m˚aste ¨aven h˚alla reda p˚a de beroenden som existerar mellan filerna som utg¨or ett f¨ardigt program eller dokument (Clark, 2004).

Figur 12 visar ett minimalistiskt exempel ¨over hur beroendegrafen kan se ut. I exemplet ska programmet ”program” byggas som best˚ar av k¨allkodsfilerna ”display.h”, ”display.c” och ”program.c”. Dessa k¨allkodsfiler ska kompileras till tv˚a objektfiler ”display.o” och ”program.o”. Dessutom anv¨ands ett programbibliotek fr˚an tredje part, ”lib3d.a”, som m˚aste l¨ankas med objektfilerna f¨or att ge den slutgiltiga produkten av bygget, den k¨orbara filen ”program”. De riktade b˚agarna i grafen symboliserar relationen ”beror p˚a”.

Ett v¨alkonstruerat byggsystem h˚aller reda p˚a alla beroenden mellan filerna samt bygger bara om det som beh¨over byggas om n¨ar n˚agot ¨andras (Feldman, 1978). Om till exempel filen ”display.c” skulle ¨andras skulle det medf¨ora att allting som beror p˚a den m˚aste byggas om, det vill s¨aga ”display.o” och programmet ”program”. ”program.o” beh¨over inte kompileras igen.

Figur 12 – Beroendegraf f¨or ett litet program.

3.1

Make

Make ¨ar ett gammalt verktyg som skapades av Stuart Feldman 1978. Den variant som ¨ar vanligast idag ¨ar GNU Make och det ¨ar den som kommer att behandlas i rapporten. Make anv¨ands genom att utvecklaren skapar en fil kallad Makefile som ligger i samma katalog som k¨allkoden. I filen skrivs en upps¨attning direktiv som ber¨attar f¨or Make vad och hur allt ska byggas. Spr˚aket kallas f¨or Make och ¨ar ett deklarativt programspr˚ak. Make anv¨ander sig av skalkommandon vilket medf¨or att hela skalmilj¨on ¨ar ˚atkomlig f¨or Make (Feldman, 1978). Normal praxis ¨ar att anv¨anda flera Makefiler, till exempel en f¨or varje delkomponent i programmet, och att ha en huvudfil som anropar de andra filerna. Detta kan dock bli v¨aldigt f¨orvirrande och leda till att byggsystemet m˚aste uppdateras ofta n¨ar koden ¨andras (Miller, 1998). F¨or att f˚a Make att bygga programmet i figur 12 anv¨ands Makefilen fr˚an figur 13. Kommandot

make program anv¨ands sedan f¨or att bygga programmet.

3.2

SCons

SCons ¨ar ett nyare verktyg som skapades av Steven Knight ˚ar 2000 som bidrag till t¨avlingen ”Software Carpentry SC Build competition”, en t¨avling som SCons lyckades vinna. M˚alet med SCons ¨ar att ˚atg¨arda svagheter i andra byggsystem och skapa ett l¨attanv¨ant och portabelt

program : d i s p l a y . o program . o l i b 3 d . a

g c c −l 3 d d i s p l a y . o program . o −o program d i s p l a y . o : d i s p l a y . c d i s p l a y . h

g c c −c d i s p l a y . c −o d i s p l a y . o program . o : program . c

g c c −c program . c −o program . o

Figur 13 – Makefile f¨or exemplet i figur 12.

alternativ (SCons Foundation, 2015). SCons anv¨ands p˚a liknande s¨att som Make men ist¨allet f¨or en Makefile skapas en fil kallad SConstruct. Till skillnad fr˚an Make anv¨ands Python som spr˚ak f¨or att beskriva hur och vad som ska byggas. Dessutom ¨ar skalmilj¨on normalt sett inte ˚atkomlig f¨or SCons. ¨Aven SCons-byggsystem brukar delas upp i flera filer. H¨ar kallas huvudfilen

SConstruct och underfilerna SConscript (Knight and the SCons Development Team, 2014). SCons k¨ors p˚a ett likande s¨att som Make f¨or att bygga programmet i figur 12. Figur 14 visar ett exempel p˚a en SConstruct-fil som g¨or samma sak som Makefilen i figur 13. Kommandot

scons program anv¨ands f¨or att bygga programmet med SCons. d i s p l a y = O b j e c t ( ” d i s p l a y . c ” )

program = O b j e c t ( ” program . c ” )

Program ( ” program ” , [ d i s p l a y , program ] , LIBS=[ ” 3d” ] )

Figur 14 – SConstruct f¨or exemplet i figur 12.

4

Metod

D˚a projektet redan har ett byggsystem implementerat i Make beh¨ovs ett likv¨ardigt byggsystem i SCons implementeras parallellt. P˚a grund av begr¨ansningarna n¨amnda i avsnitt 1.3 kommer endast kompilering och l¨ankning implementeras i SCons och det ¨ar endast p˚a dessa omr˚aden prestandan f¨or de tv˚a byggsystem kommer att m¨atas. D˚a det befintiliga Make-systemet innefattade extra funktionalitet f¨or att k¨ora till exempel enhetstester, skapades ¨aven ett nytt minimalistiskt Make-system baserat p˚a det befintliga som enbart kompilerade och l¨ankade kod. De nya byggsystemen implementeras p˚a en separat gren i versionshanteringssystemet f¨or att undvika eventuella konflikter.

Tiden det tar f¨or byggsystemen att bygga all kod i projektet m¨ats med hj¨alp av

UNIX-kommandot time. Det slutgiltiga resultatet tas som medelv¨ardet av fem m¨atningar och redovisas tillsammans med standardavvikelsen. Byggsystemens f¨orm˚aga att bygga parallellt kommer att testas med k¨orningar p˚a en, tv˚a, fyra, ˚atta och 16 tr˚adar.

All prestandatestning kommer att ske p˚a konfigurationen i tabell 2.

F¨or att utreda vilket byggsystem som ¨ar enklast att anv¨anda och vidareutveckla presenterades de b˚ada systemen f¨or kandidatgruppen som fick ge sina synpunkter p˚a till exempel l¨asbarhet och f¨orv¨antad underh˚allbarhet. Dessa synpunkter tillsammans med gruppens erfarenheter under projektets g˚ang kan ocks˚a ge svar p˚a hur valet av byggsystem har p˚averkat arbetet.

H˚ardvara Version MacBook Air Early 2015 Mjukvara Version OS X Yosemite 10.10 GNU Make 3.81

SCons 2.3.4 gcc 4.8.4

Tabell 2 – H˚ard- och mjukvarukonfiguration f¨or prestandatesterna.

5

Resultat

I avsnitt 1.2 framf¨ordes tre fr˚agest¨allningar om hur Make och SCons skiljer sig. Efter unders¨okningen beskriven i avsnitt 4 kan svaren p˚a dessa fr˚agor ges h¨ar.

5.1

Prestanda

Resultatet fr˚an prestandam¨atningarna syns i tabell 3, tabell 4 och i figur 15. Tr˚adar Make (s) Make σ (s)

1 2,65 0,057 2 1,56 0,018 4 1,32 0,020 8 1,32 0,016 16 1,34 0,027

Tabell 3 – Resultat fr˚an prestandatester med Make.

Tr˚adar SCons (s) SCons σ (s) 1 3,63 0,039 2 2,35 0,027 4 2,19 0,027 8 2,20 0,033 16 2,25 0,017

0

2

4

6

8

10

12

14

16

# trådar

0.0

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

tid (s)

Make

SCons

Figur 15 – Byggtid med Make och SCons.

5.2

Anv¨andning och vidareutveckling

Kandidatgruppen framf¨orde ett flertal synpunkter som sammanfattas i f¨oljande lista: • Anv¨andningen ¨ar densamma, bara olika kommandon.

• Alla k¨anner till Make, ingen visste om SCons sen innan. • SCons-filerna ¨ar mer l¨attf¨orst˚aeliga ¨an Makefilerna.

• Det var enkelt att s¨atta sig in i SCons d˚a det ¨ar vanlig Pythonkod. • Makes deklarativa stil s˚ag fr¨ammande och sp¨annande ut.

5.3

Byggsystemets p˚averkan p˚a projektet

D˚a prestandaskillnaden f¨or ett projekt av den h¨ar storleken ¨ar s˚a pass liten s˚a p˚averkar valet av byggsystem inte utvecklarens dagliga arbetsrutiner n¨amnv¨art. Det som p˚averkas ¨ar ist¨allet m¨ojligheten till underh˚all och vidareutveckling av byggsystemet i takt med att projektet v¨axer.

6

Diskussion

Resultaten fr˚an unders¨okningen ¨ar inte s¨arskilt f¨orv˚anande. Vad g¨aller prestanda s˚a ¨ar det f¨orv¨antat att Make ¨ar snabbare ¨an SCons d˚a det senare ¨ar skrivet i Python vilket inneb¨ar att en Python-tolk m˚aste startas vid k¨orning. Dessutom ¨ar Python ett spr˚ak med m˚anga fler finesser ¨an Make vilket antagligen g¨or det betydligt sv˚arare att tolka.

Vad som d¨aremot inte framg˚ar ¨ar vad den h¨ar skillnaden beror p˚a. F¨or att j¨amf¨ora det m˚aste antagligen ett st¨orre projekt anv¨andas som utg˚angspunkt. Om skillnaden skalar linj¨art med antalet filer som ska byggas tyder tyder det p˚a att SCons ¨ar l˚angsammare f¨or att Python ¨ar ett

sv˚arare spr˚ak eller helt enkelt att SCons i sig har h¨og k¨ortidskostnad. Om skillnaden ist¨allet skulle vara konstant s˚a tyder det p˚a att den extra tiden beror p˚a uppstart av Python-tolken. Kandidatgruppens synpunkter kan i stort sett sammanfattas till att SCons verkar enklare ¨an Make vad g¨aller vidareutveckling. Detta resultat verkar ocks˚a rimligt d˚a SCons-filerna har betydligt f¨arre rader kod samt ¨ar skrivna i ett v¨alk¨ant spr˚ak.

7

Slutsatser

M˚alet med denna rapport var att utv¨ardera tv˚a typer av byggsystem med projektet

Prediktionsreglering som utg˚angspunkt. Det visade sig att valet av byggsystem inte spelade s¨arksilt stor roll prestandam¨assigt f¨or just det h¨ar projektet. Vad som d¨aremot kunde ha

p˚averkats var f¨orm˚agan att utveckla byggsystemet i takt med projektets g˚ang. Kandidatgruppen tyckte utan undantag att SCons verkade l¨attare att f¨orst˚a och utveckla.

Om det enklare systemet SCons hade valts fr˚an b¨orjan hade f¨ormodligen hela kandidatgruppen kunnat vara mer delaktiga i att underh˚alla byggsystemet. Detta skulle antagligen lett till st¨orre kunskapsspridning och mindre beroende mot byggsystemsansvarige n¨ar n˚agot g˚ar fel. Det hade i sin tur frigjort mer tid f¨or den byggsystemsansvarige att bidra till projektet p˚a andra s¨att. En m¨ojlig f¨orb¨attring f¨or projektet ¨ar s˚aledes att implementera ett byggsystem i SCons f¨or ¨okad produktivitet och mer kunskapsspridning. Nackdelen med detta ¨ar f¨orst˚as att SCons inte alls har lika stor spridning som alternativet Make, som i det n¨armaste kan kallas industristandard.

Best practices

F¨orfattare: Adam Sestorp

Version 1.0

Status

Granskad Dennis Ljung - Godk¨and Andreas Runfalk -

1 Inledning 39 1.1 Syfte . . . 39 1.2 Fr˚agest¨allning . . . 39 1.3 Avgr¨ansningar . . . 39 1.4 Bakgrund . . . 39 2 Teori 40 2.1 Best practice . . . 40 2.2 Ledarskap . . . 40 3 Metod 41 4 Resultat 41 5 Diskussion 43 5.1 Resultat . . . 43 5.2 Metod . . . 43 6 Slutsatser 44

1

Inledning

I dagens samh¨alle finns det en m¨angd olika typer av grupper och n¨astan alla har n˚agon form av ledare. Det beh¨over inte r¨ora sig om en formellt utsedd ledare utan kan ¨aven vara en informell ledare som p˚a ett eller annat s¨att har hamnat i den rollen. Att en grupp med m¨anniskor har en ledare ¨ar inget nytt fenomen utan ¨ar n˚agot som ˚aterkommer genom hela v˚aran historia och dessa ledare finns i en m¨angd olika former. Tittar man bara p˚a dagens samh¨allen finns det allt ifr˚an monarker till folkvalda ledare i v¨arlden och alla har olika ledarstilar och ledaregenskaper. I denna rapport behandlas inte bara ¨amnet ledarskap och olika ledarskapstilar men ¨aven vad som kallas ’best practices’ det vill s¨aga det en ledare anv¨ander sig av f¨or att uppfylla sin roll p˚a b¨asta s¨att samt att ge projektgruppen b¨asta m¨ojliga f¨oruts¨attningar i sitt arbete.

1.1

Syfte

N¨ar man sj¨alv befinner sig i en roll som ledare, eller n¨armare best¨amt teamledare i detta fall,

In document Erfarenheter från utveckling av kvadratisk optimeringsalgoritm för prediktionsreglering (Page 33-99)