• No results found

Hur kan GTFS-data presenteras för att tillåta analys och identifiering av pro-

Genom att använda bussars position, fart och riktning som GTFS-data tillhandahåller kan man som denna rapport beskriver visa trafikdata på en karta, exempelvis med Leaflet. Den- na presentation kan då användas för att identifiera vägars medel, minimi, maximi och me- dianfarter. Med färgskalor kan skillnader i dessa statistiker mellan olika platser identifieras.

7.5. Hur kan GTFS-data presenteras för att tillåta analys och identifiering av problem i trafikflöden? Exempelvis kan vägar som har en låg medelfart identifieras. Alternativt kan denna statistik visas med hjälp av grafer.

8

Översikt över individuella delar

Samtliga gruppmedlemmar har gjort fördjupande individuella bidrag till rapporten. Dessa bidrag presenteras nedan med korta sammanfattningar.

A Juan Basaez - Konsekvenserna av det vi utvecklar

I denna studie utfördes en variant av metoden SUS-analys, den vi fick testa under hållbar- hetsseminariet, för att identifiera konsekvenserna som utvecklingen av systemet har haft och kan ha vid dess användning inom den sociala, individuella, miljömässiga, ekonomiska och tekniska dimensionen. I rapporten diskuteras även vilka effekter projektgruppen ignorerade och varför.

B Joakim Bergström - Möjligheter för maskininlärning med GTFS

trafikdata i Chronos

Östgötatrafiken vill analysera trafikdata med hjälp av maskininlärning. Denna rapport un- dersöker utökningsmöjligheter hos Chronos inom maskininlärning. Tidigare lösningar inom analys av trafikdata med artificiella neruonnät undersöks, och relateras till GTFS-data och Chronos.

C Johan Fisch - Git vs. SVN som versionshanteringssystem för Chronos

Under projektet hade projektgruppen en del problem med att sammanfoga grenar och merge- konflikter. I den här rapporten undersöks om ett byte till SVN hade gjort det smidigare.

D Viktor Ivarsson - En jämförelse mellan utforskande testning och

skriptad testning

För att testa programvaran använde gruppen två olika tillvägagångssätt. Denna rapport tittar på för- och nackdelar med att använda de båda. Den diskuterar också vilket tillvägagångssätt som gav bäst resultat.

E Oskar Magnusson - En jämförelse mellan D3 och Google Charts för

visualisering av statistik i ett mindre projekt

Projektgruppen tänkte först visa grafer över busstrafiken i produkten men det var något som prioriterades bort. I denna rapport jämförs två JavaScript-bibliotek som kan användas i pro- dukten, och sedan diskuteras vilken som hade passat bäst.

F Anna Montelius - Maskininlärning ur ett normkritiskt perspektiv

Denna rapport utreder hur användande av maskininlärning kan få problematiska konse- kvenser ur ett socialt hållbarhetsperspektiv. Metoden består av en litteraturstudie och resulta- tet är en samling exempel på hur maskininlärning under de senaste åren lett till bland annat diskriminering.

G Felix Nodelijk - React som verktyg för webbutveckling

React har på senare tid blivit ett mycket populärt verktyg bland webbutvecklare, men varför är det så? Rapporten lyfter för- och nackdelar med React och kopplar dessa till vad som är viktigt ur en webbutvecklares perspektiv, samt gör en jämförelse mellan React och traditio- nella tillvägagångssätt. Detta svarar i sin tur på frågan varför React är ett populärt val bland webbutvecklare.

A

Juan Basaez - Konsekvenserna av

det vi utvecklar

A.1

Introduktion

Som en del av kursen TDDD96 Kandidatarbete i programvaruutveckling vid Linköpings universitet deltog kandidatgrupperna i olika seminarier där studenterna kunde få stöd för utförandet av kandidatarbetet. Under ett av seminarierna, som hade relation till hållbar utveckling, fick studenterna använda sig av metoden SusAD-analys (beskriven senare i rapporten) för att analysera effekterna av IT-system ur ett hållbarhetsperspektiv. SusAD-analysens syfte är att identifiera konsekvenserna, som utvecklingen av ett system kan ha, för att ta hänsyn till dem vid design av projektet. Utifrån analysen ska man kunna planera så att de negativa effekterna kan minskas eller motverkas samtidigt som de positiva kan maximeras.

Under det nämnda seminariet genomförde gruppen en del av analysen och identifiera- de några av de möjliga konsekvenserna av systemet som skulle utvecklas, men ingen analys eller diskussion skedde kring effekterna och resultatet användes varken vid planering eller utveckling av systemet. Men en av gruppmedlemmarna blev intresserade av att använda me- toden efter utvecklingen av systemet och försöka genomföra en fullständig analys som skulle redovisa alla hypotetiska konsekvenser av systemet som utvecklades under kandidatarbetet. I den här rapporten beskrivs analysen och redovisas dess resultat. Att ha gjort analysen ef- ter utvecklingen tillåter också en diskussion kring systemets effekter som gruppen ignorerade under planering samt utförande av projektet.

A.1.1

Syfte och frågeställningar

Syftet med den här rapporten är att presentera och diskutera resultatet av en analys vars syfte var att kunna identifiera systemets konsekvenser; vilka effekter utvecklingen har haft, samt vilka hypotetiska effekter användningen av systemet kan ha. Identifiering av konsekvenserna tillåter diskussion kring följande frågeställningar:

1. Vilka konsekvenser, ur ett hållbarhetsperspektiv, kan utvecklande av systemet ha? 2. Hur kunde gruppen ha påverkat hypotetiska negativa effekter vid utvecklandet av sy-

stemet?

A.2. Teori

A.1.2

Begränsningar

Studien begränsades till användande av en variant av SusAD-analysen, vilken beskrivs se- nare i rapporten. Studenten som utförde studien följde SusAD-analysens instruktioner och använde sig av två exempel där det visas hur analysen utförs, men varken den använda varianten eller dess resultat har godkänts av någon med erfarenhet i utförande av SusAD- analysen.

A.2

Teori

Under den här punkten beskrivs den teoretiska backgrunden för studien som redovisas i rapporten.

A.2.1

Hållabar utveckling

I rapporten Our common future, från United Nations World Commission on Environment and Development [78], definieras hållbar utveckling som ”development that meets the needs of the present without compromising the ability of future generations to meet their own needs. It contains within it two key concepts:

• the concept of ’needs’, in particular the essential needs of the world’s poor, to which overriding priority should be given; and

• the idea of limitations imposed by the state of technology and social organization on the environ- ment’s ability to meet present and future needs." [78]

Trots begreppet har definierats på olika sätt, anses den här definitionen som officiell och stan- dard på grund av dess utbredda användning.

Till skillnad från begreppet hållbarhet, som endast relateras till ett systems funktionella livstid, omfattar begreppet hållbar utveckling en balans mellan tre olika dimensioner: miljö- mässig, social och ekonomisk. Den balansen representeras med ett venndiagram som består av tre överlappande cirklar, där varje cirkel representerar en dimension. Som visas i figur A.1 nedan, är området där alla tre cirklar överlappar varandra, det som betraktas som hållbart; balansen mellan de tre olika dimensionerna.

A.2. Teori

A.2.2

Hållbar programmvaruutveckling

Utifrån definitionen av hållbar utveckling (A.2.1) kan man förstå vad hållbar programvaru- utveckling kan innebära, vad man bör ha som mål vid utvecklingen. Men problemet med definitionen av hållbar utveckling, specifikt med rapporten där begreppet definieras [78], är att det saknas ett tillvägagångssätt som guidar en till målet. Därför har det blivit svårt att överensstämma och standardisera vad hållbar programvaruutveckling innebär som helhet samt vad och hur man ska göra för att utföra en hållbar programvaruutveckling.

En av forskarna som bidrog till att skapa SusAD-analysen är Birgit Penzenstadler som i sin artikel Towards a Definition of Sustainability in and for Software Engineering [79] erbjuder en preliminär guide till hur hållbar utveckling kan anslutas till utveckling av programvaror. I artikeln definierar Birgit hållbarhetsaspekter i-och för programvaruutveckling som hur man förbättrar hållbarheten av det som utvecklas respektive hur man gör programmvaruutveckling mer hållbart.

Ett år senare publicerade Birgit Penzenstadler, tillsammans med Henning Femmer, ar- tikeln A Generic Model for Sustainability with Process- and Product-specific Instances där de presenterar en modell för hållbarhet. I modellen delas begreppet i fem olika dimensioner: social, individuell, miljömässig, ekonomisk och teknisk [80]. Avsikten bakom uppdelningen av begreppet hållbarhet i olika dimensioner är att kunna analysera hållbarhet med fokus på ”which system to sustain, for whom, over which time frame, and at what cost" [81]. Modellen erbjöds som stöd för analys av projekt utifrån fem dimensioners perspektiv. Hur dimensio- nerna definieras i artikeln, i förhållande till programvaruutveckling, visas nedan:

• Social: Vilka effekter en programvara har på samhället.

• Individuell: Hur en programvara kan utvecklas och underhållas så att utvecklaren är nöjd med resultat under en lång tidsperiod.

• Miljömässig: Hur en programvara påverkar miljön under dess utveckling och under- håll.

• Ekonomisk: Hur en programvara kan utvecklas så att långsiktiga investeringar är säkra från ekonomiska risker.

• Teknisk: Hur en programvara kan utvecklas så att den enkelt kan anpassas till ändring- ar.

A.2.3

SusAD-analys

SusAD-analysen är en metod som en grupp forskare har tagit fram för att identifiera, klas- sa och underlätta funderingen över effekterna som utveckling av ett IT-system kan ha. Ef- fekterna analyseras utifrån dimensionerna som tidigare nämndes i punkten A.2.2 Hållbar programmvaruutveckling.

A.2.3.1 Sus-analys utförande

Inom varje dimension finns ett antal olika frågor som ska svaras med hjälp av en expert in- om dimensionen (som intervjuas) så att konsekvenserna av att utveckla ett specifikt system kan identifieras. Instruktioner och rekommendationer angående intervjuerna kan hittas i ett Google Drive dokument som delas av forskarna som skapade metoden [82]. Dokumentet in- nehåller också alla frågor som ska ställas i den sociala [83], individuella [84], miljömässiga [85], ekonomiska [86] och tekniska dimensionen [87].

A.3. Metod

Efter att ha intervjuat, sammanfattas informationen och klassificeras i subdimensioner inom varje dimension, som visas i två exempel där metoden applicerades på ett hållbart upp- handlingssystem [88] och Airbnb [89] (en plattform för uthyrning och bokning av privat bo- ende). Resultatet av studien som redovisas i den här rapporten följer samma struktur (A.4 Resultat.

Vid nästa steg ska ett diagram byggas upp. Ett diagram vilket gav upphov till namnet SusAD som står för Sustainability Analysis Diagram. De identifierade effekterna ska placeras i diagrammet i respektive dimension, men också enligt respektive kategori av effekt, som visas i figur A.2. Systemets effekter delas upp i tre olika typer: omedelbara (eng. direct impact) som är livscykels påverkan av utvecklingen, möjliggörande (eng. enabling effects) som är vad systemet möjliggör, och strukturella (eng. structural) som är effekterna som orsakas om många personer använder systemet under en lång period.

Figur A.2: SusAD diagram

A.3

Metod

I det här kapitlet beskrivs metoden som användes för att genomföra analysen, ta fram syste- mets konsekvenser och utifrån det kunna besvara studiens frågeställningar.

A.3.1

En variant av SusAD-analys

Metoden som användes för att ta fram systemets konsekvenser är en variant (en egen vari- ant av studenten som utförde studien) av SusAD-analysen. Här beskrivs hur den använda varianten skiljer sig from originalet.

A.3.1.1 Inget stöd från experter

Som beskrevs i A.2.3 SusAD-analys, etablerar instruktionerna till utförandet av analysen att man ska intervjua experter, inom de olika dimensioner, för att få svar på frågorna och ta fram systemets konsekvenser. Vid studien, som presenteras i rapporten, besvarades dock SusAD-analys frågor utifrån egen erfarenhet från utförandet av projektet samt empiriskt stöd för hypotetiska möjliga effekter. Resultatet som ska presenteras är utifrån ett student- utvecklarperspektiv. Projektmedlemmanrna har inte gått igenom resultatet så de har inte fått möjligheten att diskutera kring effekterna som har tagits fram i studien. Det är viktigt att signalera att resultatet som redovisas, inte behöver representera gruppens åsikter och per- spektiv.

A.3. Metod

A.3.1.2 Utförande efter utveckling

Ett annat kännetecken som den genomförda varianten har, jämfört med den originella versio- nen av SusAD-analysen A.2.3.1 Sus-analys utförande, är att studien utfördes efter utvecklingen av systemet.

A.3.1.3 Inget SusAD-analys diagram

Som visades i punkten A.2.3.1 Sus-analys utförande, ska, efter sammanfattning och klassifice- ring av effekterna, ett diagram byggas upp. Byggandet av diagrammet ansågs onödigt för utförandet av studien. Analysen och diskussionen av systemets konsekvenser skedde direkt efter att ha fått svar på alla frågor i varje dimension.

A.3.1.4 Eget sätt att redovisa resultat under varje dimension

Med tanke på att underlätta läsarens förståelse, samt anpassa analysen både till det specifika systemet och till det faktum att det redan är utvecklat, presenteras resultaten på ett annorlun- da sätt än det som rekommenderas på de exemplen som tidigare nämndes i A.3 Metod. Den sociala-och individuella dimensionen analyserades utifrån tre olika perspektiv: utvecklare, användare och bussåkare. Det ansågs viktigt att dela analysen och identifiera alla effekter som systemet kunde ha för de som utvecklade det, för de som ska använda det och för de som kan uppleva konsekvenser av arbetet till vilket systemet kan bidra.

Utvecklare är gruppen av studenter som utförde projektet. Som Användare betraktas Öst- götatrafiken, men analysen genomfördes med tanke på att produkten kan vidareutvecklas, samt implementeras i fler städer. Det tredje perspektivet som användes för analysen var bussåkare.

En beställarens representant beskrev systemet som ett interaktivt system för visualisering av trafikdata vars syfte är att ”underlätta övergripande analys och förankring av kollektivtrafikens framkomlighet med externa parter”. Om användande av systemet bidrar till att lösa trafikpro- blem som till exempel trafikflöde eller bussarnas förseningar, kan man då påstå att systemet kan ha effekter på servicen för kollektivtrafiken. Därför har det valts att också identifiera konsekvenser ur ett bussåkare perspektiv.

A.3.2

Formulär

Efter resultatet av SusAD-analysen fick projektmedlemmarna besvara följande frågor: 1. Hur skulle du definiera hållbar utveckling?

2. Tycker du att det utvecklade systemet är hållbart? Varför?

3. Varför tog gruppen ingen hänsyn till hur utvecklingen och användningen av systemet kunde påverka miljön?

4. Varför påverkades projektplaneringen och design av produkten bara av beställarens krav och budget som gruppen hade?

Frågorna var konkreta, specifika, och har direkta relation till viktiga aspekter av resultatet av studien. Projektmeddlemars svar användes som stöd till funderingar samt diskussionen kring resultatet. Deras svar kan också motivera orsakerna till effekterna som ignorerades under projektet.

A.4. Resultat

A.4

Resultat

Resultatet som presenteras i den här rapporten är alla hypotetiska effekter som identifierades genom att genomföra en variant av SusAD-analysen. Som tidigare förklarats, genomfördes analysen utan stöd från experter. Alla frågor från SusAD besvarades utifrån en egen analys av möjliga och hypotetiska effekter med hjälp av empiriskt stöd. Nedan presenteras resultatet av analysen, det vill säga vilken inverkan som det utvecklade systemet kunde ha haft under utveckling och kan ha som konsekvens av dess användning.

Som beskrevs i A.3 Metod, har varje dimension av analysen ett antal frågor att besvara. Alla frågor har besvarats för att komma fram till resultatet som visas i den här punkten. In- formationen nedan följer inte en fråga-svar struktur, utan effekterna, svar till frågorna, listas under respektive dimension och subdimension.

A.4.1

Social

Här presenteras systemets effekter inom den sociala dimensionen. A.4.1.1 Känsla av gemenskap

• Utvecklare

A.4.1.1.1. Utvecklingsgruppen består av sju studenter som inte hade träffats tidigare. Utveckling av systemet erbjöd möjligheten att lära känna varandra och sam- arbeta under projektets gång.

A.4.1.1.2. Utvecklingen av systemet krävde ingenting som kunde få en utvecklare att känna sig oviktig eller utanför gruppen.

• Användare

A.4.1.1.1. Systemet kan möjliggöra bättre kontakt mellan östgötatrafiken och myndig- heter vid diskussion av trafikproblem samt presentation av lösningar till identifierade och analyserade problem.

A.4.1.1.2. Implementationen av det nya systemet kan orsaka problem inom företaget om bara en specifik grupp av arbetare får jobba med det. De som inte får möjligheten kan ifrågasätta deras betydelse inom företaget.

• Bussåkare

A.4.1.1.1. Att åka buss innebär att träffa folk som man inte skulle träffa om man åker bil. Systemet kan bidra då till att öka möjligheten att träffa folk.

A.4.1.2 Förtroende • Utvecklare

A.4.1.2.1. Projektet krävde att gruppen delade arbetet, vilket i sin tur krävde högt för- troende mellan gruppsmedlemmarna.

A.4.1.2.2. Under utvecklingen av systemet kunde förtroendenivå påverkas beroende av individuella insatser och aktiviteters resultat.

• Användare

A.4.1.2.1. Alla system inom ett företag kan påverka förtroendet mellan de inblandade. Faktorer som systemets prestanda och resultat kan påverka förtroendet inom samarbetet.

A.4. Resultat

A.4.1.2.2. Det nya systemet kan bidra till resultat som kan påverka förtroendet mellan myndigheter och användaren (bra resultat med lyckande implementation av åtgärder kan till exempel öka hur mycket myndigheterna litar på använda- ren av systemet).

A.4.1.2.3. Resultatet av projektet kan påverka beställarens (användare i analysen) in- tryck av att samarbeta med Linköpings universitet (utvecklingsgruppen, till vis del, representerar universitetet under projektet).

• Bussåkare

A.4.1.2.1. Om servicen för kollektivtrafik förbättras är det rimligt att tänka sig att sam- hället, framför allt bussåkarna, ska ha ett bättre intryck av servicen. Systemet kan då bidra till att öka hur mycket folk litar på servicen för kollektivtrafiken.

A.4.1.3 Delaktighet och mångfald • Utvecklare

A.4.1.3.1. Utförande av projektet kan ha påverkat intrycket som gruppmedlemmarna hade av varandra

• Användare

A.4.1.3.1. Att, till exempel, trafikflödet representeras med olika färger beroende av dess nivå (lågt-medium-högt) kan innebära att en färgblind person inte får använ- da systemet. Beställaren av systemet krävde ingenting angående det, men bestämda färger (utan möjlighet att ändra inställningar) för att representera något i visualiseringen kan vara en begränsning för nya användare.

A.4.1.3.2. För dess användning, kräver systemet inte mer än en låg datorvananivå. Där- emot kan användaren bestämma vad som krävs för att både utnyttja infor- mationen och genomföra analyser.

A.4.1.3.3. Systemet kräver inte specifikt kön, ålder, bakgrund eller utbildning för dess bruk.

• Bussåkare

A.4.1.3.1. Det kan finnas en skillnad mellan vilka som åker bil och vilka som använder kollektivtrafik. En förbättring av kollektivtrafikens service kan bidra till att minska skillnaden i någon grad.

A.4.1.3.2. Att folk som brukade köra bil nu väljer använda kollektivtrafiken kan påver- ka intrycket som folk, som är tvungna att åka buss, har av de som åker bil, och viceversa.

A.4.1.4 Jämlikhet och jämställdhet • Utvecklare

A.4.1.4.1. Projektet krävde att varje medlem ska ha spenderat 400 timmar.

A.4.1.4.2. Gruppen bildades utan hänsyn till varken kunskap-eller ambitionsnivåer el- ler tidigare erfarenhet. En faktor som till exempel skillnader i kunskapnivåer kunde ha påverkat hur en medlem upplevde sin betydelse i projektet. A.4.1.4.3. Varken projektet eller systemets egenskaper krävde att någon aktivitet eller

A.4. Resultat

• Användare

A.4.1.4.1. Se A.4.1.3.2. och A.4.1.3.3.. • Bussåkare

A.4.1.4.1. Förbättring av servicen för kollektivtrafik kan bidra till att reducera luckan som idag kan finnas mellan de som måste åka bus och de som får välja att åka bil.

A.4.1.5 Deltagande och kommunikation • Utvecklare

A.4.1.5.1. Projektet kunde ha påverkat hur studenterna upplever att arbeta i grupp. A.4.1.5.2. Projektet kunde möjliggöra studenterna att skapa eller förstora deras sociala

nätverk med tanke på framtida jobb eller projekt.

A.4.1.5.3. Projektet krävde kommunikation med kunden (ny erfarenhet, framför allt, för gruppens analysansvarig).

A.4.1.5.4. Projektet utfördes parallellt med åtminstone en annan kurs. Det kunde ha påverkat studenternas engagemang under projektet.

• Användare

A.4.1.5.1. Systemet kan bidra då till kontinuerlig kommunikation mellan de som an- vänder systemet och alla inblandade i presentation och diskussion av möjli- ga lösningar (som till exempel kommunala trafikplanerare).

A.4.1.5.2. Det nya systemet, vilket erbjuder ett nytt verktyg för analys av trafikdata, kan påverka engagemanget inom användares grupp och dessutom påverka externa parters intresse kring problemet. Det kan också leda till nytt samar- bete.

• Bussåkare

A.4.1.5.1. Förbättrating av servicen för kollektivtrafik kan öka möjligheten att kommu- nicera med andra. Det ska variera från person till person, men chansen att kommunicera kan ökas.

A.4.1.5.2. Att flera åker buss kan tolkas som ex-bilåkares samtycke till de utförda åt- gärderna i servicen eftersom de väljer att åka buss istället för bil. Man kan anta att de som tidigare inte kunde välja mellan buss och bil ska fortfarande åka buss oberoende vad de tycker om servicen.

Related documents