Vad s¨ ager den kantianska pliktetiken om utvecklande a

Det som vi har att utg˚a fr˚an ¨ar Kants formuleringar. F¨orsta formuleringen kunde kokas ner till att du inte ska g¨ora n˚agot som du inte skulle till˚ata andra att g¨ora. Eftersom ingen i gruppen inte skulle till˚ata oss utf¨ora detta projekt s˚a mots¨atter sig inte denna etiska skola v˚art projekt enligt f¨orsta formuleringen.

andra f¨or sina egna ¨andam˚al. Detta ¨ar ingenting som har h¨ant under projektets g˚ang. Arbetet har skett under schyssta f¨orh˚allanden utan n˚agon form av ma- nipulation eller utnyttjande av andra. Allts˚a kan man p˚ast˚a att inte heller den kantianska pliktetiken mots¨atter sig projektarbetet som utf¨orts.

G.9

Slutsatser

Slutsatserna som kan dras fr˚an studien ¨ar att enligt utilitarismen skulle ett pro- jekt som g¨or mer nytta kunna utf¨orts. Detta f¨or att maximera lyckan som konse- kvenserna som uppst˚ar efter projektet. Dock kan man argumentera att projektet i framtiden skulle kunna vidareutvecklas till att hj¨alpa m˚anga m¨anniskor. Till exempel skulle systemet kunna anv¨andas f¨or att fj¨arrstyra en robot i situationer som ¨ar farliga f¨or m¨anniskor.

Dygdetiken l¨agger sitt fokus p˚a karakt¨ar. Det ¨ar sv˚art att utreda varje individs karakt¨ar i gruppen. Sj¨alva projektet i sig bidrar ju inte med en s¨amre karakt¨ar. D¨arf¨or har dygdetiken ingenting emot projektet som utf¨orts

Ingenting som har med projektet att g¨ora g˚ar emot Kants formuleringar och d¨arf¨or mots¨atter sig inte den kantianska pliktetiken v˚art projekt.

Som det ser ut nu s˚a kan v˚art system inte g¨ora mycket nytta, men med lite vidareutveckling och mer avancerad robot skulle den kunna anv¨andas vid farliga situationer.

H

Kravhantering och kundrelationer i rollen som

analysansvarig av David Wajngot

Denna del av rapporten behandlar den analysansvariges roll i ett mjukvarupro- jekt, kundrelationer och kravhantering vid arbete med agil utveckling. Den ¨ar skriven av David Wajngot som agerade analysansvarig under projektet.

H.1

Inledning

F¨or att ett mjukvaruprojekt ska initieras kr¨avs att en person eller ett f¨oretag ¨

onskar en produkt, men saknar de tekniska kunskaperna eller tiden f¨or att utveckla den. Den som ¨onskat produkten g¨or en best¨allning och blir d¨armed best¨allare, och en projektgrupp bildas. M˚alet med projektet blir att skapa v¨arde f¨or best¨allaren, och att se till att denne blir n¨ojd med slutprodukten. D¨arf¨or ¨ar kravhantering oerh¨ort viktig i mjukvaruprojekt, f¨or att underl¨atta f¨or projekt- gruppen att f¨orst˚a vad som f¨orv¨antas av best¨allaren, och f¨or att se till att pro- jektgruppen och best¨allaren har en liknande uppfattning om hur slutprodukten ska se ut.

H.1.1 Syfte

Denna individuella rapport avser att behandla hur kundrelationer och kravhan- tering hanteras i relation till varandra i ett agilt mjukvaruprojekt. Rapporten ¨

amnar att besvara huruvida detta skiljer sig fr˚an icke-agila projekt och hur det ska hanteras av analysansvarig. F¨or att underl¨atta unders¨okningen av dessa ¨

amnen har tv˚a fr˚agest¨allningar tagits fram.

H.1.2 Fr˚agest¨allningar

1. Hur f¨orh˚aller sig kundrelationer till kravhantering i agila mjukvaruprojekt, och hur involveras analysansvarig i detta?

2. Vad ¨ar skillnaderna p˚a analysansvariges roll mellan agil och icke-agil ut- vecklingsmetodik?

H.2

Bakgrund

Denna rapport ¨ar en bilaga till en st¨orre kandidatrapport. Kandidatrappor- ten ¨ar skriven i samband med ett projekt som har utf¨orts i kursen TDDD96 Kandidatprojekt i programvaruutveckling som ges p˚a Link¨opings universitet f¨or studenter som l¨aser datateknik och mjukvaruteknik. Projektets slutm˚al var att utveckla ett VR-gr¨anssnitt till en humanoid robot, f¨or att l˚ata en anv¨andare styra roboten och se ur dess perspektiv.

H.3

Teori

Detta kapitel behandlar den relevanta teori som kr¨avs f¨or att besvara fr˚age- st¨allningarna.

H.3.1 Utvecklingsmetodik i mjukvaruprojekt

Detta kapitel beskriver traditionell och agil utvecklingsmetodik. Traditionell utveckling

Inom traditionell utveckling utf¨ors ett projekt utefter ett f¨orutbest¨amt antal steg som f¨oljer sekventiellt efter varandra. Dessa steg ¨ar vanligtvis initiering av projektgrupp, utformning av krav, planering, utveckling, testning och leverans. I en tydlig kronologisk struktur dokumenteras best¨allarens krav, det beslutas om mjukvarans arkitektur, arkitekturen visualiseras, utvecklingen utf¨ors, testning, etc. Den detaljerade bilden av hur produkten ska se ut och fungera f¨ardigst¨alls i b¨orjan av projektet innan utvecklingen b¨orjar. Projektet utf¨ors sekventiellt fr˚an fas till fas. Testning utf¨ors n¨ar utvecklingen ¨ar f¨ardig. [103]

Agil utveckling

Agil utveckling skiljer sig fr˚an icke-agil, traditionell utveckling, p˚a m˚anga punk- ter. Det inneb¨ar mer eller mindre att ett sj¨alvorganiserade team (om ca 6-8 personer) f˚ar i uppdrag att utf¨ora ett projekt d¨ar en slutprodukt ska levere- ras. Projektet delas in i iterationer, d¨ar delresultat kan levereras i omg˚angar innan projekttiden ¨ar slut. Efter varje iteration ska arbetet utv¨arderas f¨or att f¨orb¨attra gruppens effektivitet. Fokus ligger p˚a frekventa leveranser och demon- strationer av de hittills f¨ardiga funktionerna, som ocks˚a dessa kan utv¨arderas f¨or att underl¨atta beslut ang˚aende n¨asta steg. Dessa demonstrationer brukar h˚allas i slutet av varje iteration f¨or att h˚alla alla parter uppdaterade. Viktigt ¨

ar att best¨allaren f˚ar chansen att ge feedback f¨or att kunna kommunicera si- na ˚asikter. P˚a detta s¨att kan best¨allaren vara mer involverad under projektets g˚ang, vilket ger mer frekvent och n¨ara kundkontakt. Produkten byggs p˚a detta s¨att upp inkrementellt och best¨allaren f˚ar m¨ojligheten att uppdatera sina krav under projektets g˚ang. [104]

H.3.2 Analysansvarig

Analysansvarig ¨ar en av de typiska rollerna i en projektgrupp. Analysansvari- ges roll i ett projekt ¨ar att ha hand om kontakten med kunden och allt som ¨

ar kopplat till detta. Det ¨ar viktigt med goda kundrelationer, och d¨arf¨or ska analysansvarig st¨andigt vara kontaktbar, visa respekt f¨or kunden och vara pro- fessionell. Analysansvarig ska ¨aven ha god insikt i vad projektgruppen har f¨or ˚asikter om projektet, och vad gruppen anser ¨ar rimligt att utf¨ora inom projek- tets tidsramar med den h˚ard- och mjukvara som kan tillgodoses. Detta m˚aste givetvis framf¨oras till kunden, och det ¨ar analysansvariges uppgift att f¨orhandla med kunden om kraven. [105]

H.3.3 Kravhantering

Det ¨ar best¨allaren som st¨aller krav p˚a slutprodukten, och d¨armed ¨ar analysan- svarig ¨aven involverad i kravhanteringen f¨or projektet. Det ¨ar analysansvariges uppgift att ta reda p˚a best¨allarens verkliga behov och f¨ormedla dessa och alla best¨allarens tankar och ˚asikter till ¨ovriga projektgruppen. [105]

Kravhantering ¨ar den st¨orre och mer generella processen som p˚ag˚ar under hela projektets g˚ang och behandlar all verksamhet som r¨or kraven. Den generella metod som beskrivs i detta kapitel kan appliceras p˚a b˚ade agila och traditionella projekt. Den kan delas in i fyra steg: genomf¨orbarhetsstudie, kravinsamling, kravspecifikation och kravvalidering. [106]

Genomf¨orbarhetsstudie

Genomf¨orbarhetsstudien ¨ar det f¨orsta steget i kravhanteringsprocessen. I b¨orjan av projektet ges ofta av best¨allaren en odetaljerad bild av slutprodukten. Utifr˚an denna ska en utv¨ardering g¨oras om huruvida den funktionalitet som best¨allaren ¨

onskat ¨ar genomf¨orbart. Studien ska analysera huruvida den slutliga mjukva- ruprodukten i praktiken kan implementeras s˚a att m˚alen uppn˚as efter de be- gr¨ansningar som finns och enligt organisationens v¨arderingar. Slutresultatet av studien ska vara en rapport som inneh˚aller kommentarer och rekommendationer till ledningen som anger ifall projektet borde initieras eller inte. [106]

Kravinsamling

Efter att genomf¨orbarhetsstudien ¨ar f¨ardig och projektet har godk¨ants ¨ar det dags att utf¨ora det andra steget i kravhanteringsprocessen, kravinsamling, eller elicitering.

Kravinsamling ¨ar en process med m˚alet att samla in de n¨odv¨andiga kraven f¨or projektets slutprodukt. P˚a n˚agot s¨att m˚aste all denna information samlas ihop f¨or att kunna sammanst¨allas i ett tydligt och genomg˚aende dokument kallat kravspecifikation. Processen f¨or insamlingen av kraven beh¨over oftast f¨orberedas ordentligt, och kan utf¨oras med hj¨alp av ett flertal olika tekniker. N˚agra av de vanligaste teknikerna ¨ar brainstorming, dokumentanalys, fokusgrupper, inter- vjuer, workshops och kvantitativa studier [107].

Kravspecifikation

N¨ar kraven ¨ar insamlade fr˚an de olika intressenterna ska de dokumenteras tyd- ligt och strukturerat i en kravspecifikation [106]. Kravspecifikationen skiljer sig ˚at mellan agila och icke-agila projekt p˚a olika punkter. B˚ada inneh˚aller n˚agon form av numrerade krav, ofta prioriterade efter vad som ¨ar viktigast f¨or slutpro- dukten. I ett agilt projekt ¨ar kraven emellertid ofta formulerade som use-cases och user-stories, med syftet att tydligg¨ora och konkretisera varf¨or kraven ¨ar ¨

onskv¨arda. En user-story kan beskrivas som en funktion som anv¨ands utifr˚an en intressents perspektiv (vanligtvis en anv¨andare) f¨or att uppfylla ett visst syfte. N˚agra av f¨ordelarna med att anv¨anda user-stories ist¨allet f¨or krav p˚a for- men f¨or IEEE-830 ¨ar att de ¨ar sv˚ara att misstolka, passar bra f¨or iterativ och inkrementell utveckling och fokuserar inte f¨or mycket p˚a detaljer (s˚a att man i b¨orjan av projektet l¨att kan b¨orja arbeta). Ytterligare en stor f¨ordel ¨ar att man l¨attare kan se helhetsbilden av en produkt, vilket kan vara v¨aldigt sv˚art i en

kravspecifikation med hundratals krav listade p˚a IEEE-830-form. [108][109] Kravvalidering

Till sist kr¨avs ¨aven validering av kraven i kravspecifikationen. N˚agra villkor som kraven kan valideras mot ¨ar:

• Om de kan bli implementerade i praktiken • Om det finns n˚agra tvetydigheter

• Om de ¨ar kompletta

• Om de kan bli demonstrerade

Utan validering kan problem uppst˚a d˚a det alltid finns utrymme f¨or missf¨orst˚and och olika tolkningar av samma text. [106]

H.4

Metod

En litteraturstudie har anv¨ants som metod f¨or att finna svaren p˚a fr˚agest¨allning- arna. Information samlades fr˚an olika relevanta k¨allor f¨or att sedan unders¨okas och j¨amf¨oras. Till slut kunde den genomarbetade teorin sammanst¨allas till ett resultat.

H.5

Resultat

I detta kapitel ges resultatet av litteraturstudien.

H.5.1 Agil kravhantering

Kvalitetskonsultf¨oretaget AddQ menar att det finns sex principer att efterf¨olja f¨or att g¨ora kravhantering agil. [110]

1. Good enough : hitta r¨att kvalitetsniv˚a baserat p˚a mottagarens krav F¨orst och fr¨amst identifieras vilka mottagarna f¨or produkten ¨ar. Mottagarna ¨ar inte bara best¨allaren, utan alla intressenter som kan komma i kontakt med den f¨ardiga produkten. F¨or att kraven ska vara tillr¨ackliga kr¨avs det att de duger (“Good Enough”) f¨or alla mottagare. Det inneb¨ar ocks˚a att kvaliteten p˚a pro- dukten ¨ar tillr¨ackligt h¨og f¨or att ˚atminstone ers¨atta kostnaden f¨or att utveckla den och att produkten ¨ar framtagen p˚a effektivast m¨ojliga s¨att. Kontinuerlig kommunikation med samtliga mottagare kr¨avs. [110]

2. Fokusera p˚a de v¨ardeskapande aktiviteterna och Just in Time De v¨ardeskapande aktiviteterna prioriteras och icke v¨ardeskapande arbete (som till exempel specificering av l˚agprioriterade krav som aldrig implementeras)

utel¨amnas. Genom att g¨ora detta och att b¨orja med att fokusera p˚a verksam- hetskrav ges tillr¨ackligt med information f¨or att kunna utf¨ora en uppskattning av utvecklingskostnader och en planering av aktiviteter. Det ¨ar av yttersta vikt att de v¨ardeskapande aktiviteterna utf¨ors precis n¨ar det ¨ar planerat (“Just in Ti- me”), enligt en ¨overenskommen tidplan. P˚a detta s¨att kan de icke v¨ardeskapande aktiviteterna undvikas helt och h˚allet. Ju mer tid som ist¨allet l¨aggs p˚a faktisk utveckling desto b¨attre. Projektgruppen f˚ar d˚a b¨attre insikt i produkten och kan st¨alle b¨attre och mer konkreta fr˚agor till mottagarna. [110]

3. Definiera gemensamma begrepp och definitioner

Inom organisationen och mellan alla intressenter beh¨ovs begrepp och definitioner som f¨orst˚as och anv¨ands av alla. Dessa tas fram gemensamt f¨or att alla ska ha samma uppfattning av uttryckens betydelse. Med hj¨alp av detta kan den kontinuerliga kommunikationen mellan de olika delarna av verksamheten kunna fortl¨opa. Behov, m˚al, verksamhetskrav och systemkrav ¨ar begrepp som m˚aste tas fram p˚a detta s¨att. [110]

4. B¨orja med verksamhetskrav

Det ¨ar viktigt att f¨orst prioritera verksamhetskraven, d˚a det oftast kr¨avs att olika delar av verksamheten m˚aste samarbeta f¨or att slutf¨ora en uppgift. Till- sammans kan verksamhets- och systemkraven koppla samman systemet med verksamhetens behov och m˚al. [110]

5. Samla in behoven fr˚an verksamheten och s¨att m¨atbara m˚al

Samtliga delar av verksamheten kan bidra vid insamlingen av information kring kraven p˚a produkten, inte endast analysansvarig, ¨aven om denne b¨or initiera n˚agon metod f¨or detta i b¨orjan av projektet. Kraven ska endast definieras utifr˚an m˚al och behov, och aldrig utifr˚an l¨osning. [110]

6. St¨andig f¨orb¨attring och utveckling

Under hela projektets g˚ang b¨or verksamheten str¨ava efter att f¨orb¨attras [110]. Genom att utv¨ardera och analysera arbetet kan f¨orb¨attring och utveckling ske.

H.5.2 Agil analysansvarig

Enligt Mike Cohn skiljer sig analysansvariges roll stort mellan traditionell och agil utveckling (i synnerhet Scrum) [111]. Medan analysansvarig i ett tradi- tionellt projekt med sekventiell utveckling mestadels kommunicerar kundens krav till utvecklarna, kan denne ¨aven ha ytterligare ansvarsuppgifter i ett agilt projekt. Den kan ¨aven agera handledare f¨or att organisera m¨oten mellan pro- jektgruppen och best¨allaren (eller product owner i Scrum). Analysansvarige f˚ar i och med detta st¨orre ansvar f¨or att styra diskussionen mot viktigare ¨amnen och mer br˚adskande ¨arenden, s˚asom krav med mer ¨overh¨angande risker. Innan m¨otet kan analysansvarige ocks˚a f˚a eller ta p˚a sig ansvaret att f¨orst˚a en ny funktion p˚a djupet och att framf¨ora detta till projektgruppen, s˚a att detaljerna kan diskuteras genomg˚aende p˚a m¨otet. Den st¨orsta och viktigaste skillnaden, s¨ager han, kan vara att analysansvariges viktigaste egenskap i agila projekt ¨ar kommunikation, n¨ar det i icke-agila projekt snarare ¨ar att s˚alla information ur dokument. [111]

H.6

Diskussion

I detta kapitel ges en diskussion kring den valda metoden och resultatet.

H.6.1 Metod

Den metod som anv¨ants f¨or att n˚a resultatet har varit informationsinsam- ling fr˚an olika litter¨ara k¨allor. I och med fr˚agest¨allningarna och de ¨amnen som rapporten behandlar finns inte m˚anga andra rimliga alternativ att utnytt- ja. Metoden tar information fr˚an m˚anga olika k¨allor och perspektiv och ger d¨armed m¨ojlighet att utforma ett nyanserat resultat som kan ge generella svar p˚a fr˚agest¨allningarna. Det kan emellertid ocks˚a leda till tvetydigheter till f¨oljd av mots¨agelser k¨allorna emellan.

H.6.2 Resultat

N¨ar det kommer till kravinsamling beh¨over analysansvariges roll inte skiljas s˚a mycket ˚at mellan agila och icke-agila projekt. Denne b¨or i b˚ada fall initiera kravhanteringsprocessen och best¨amma metod f¨or kravinsamlingen. AddQ:s sex principer f¨or agil kravhantering kompletterar snarare den generella metoden f¨or kravhantering ¨an att substituera den, och fokuserar mycket p˚a att arbetet inom verksamheten ska fungera innan utvecklingen kan utf¨oras tillfredsst¨allande. Principerna klarg¨or emellertid tydligt att det inte endast ¨ar best¨allaren som ska ge grunderna till kraven, utan alla intressenter som kan t¨ankas komma i kontakt med produkten (som grupperas ihop i ordet mottagare). [110]

I principerna n¨amns knappt analysansvarig alls, det diskuteras snarare hur he- la verksamheten ska agera f¨or att utf¨ora lyckad kravhantering. Analysansvarig utesluts inte explicit heller, vilket kan leda till slutsatsen att analysansvarig ar- betar som vanligt men f˚ar st¨od i sitt arbete fr˚an hela verksamheten. Det ligger p˚a alla projektmedlemmar att hitta information att basera kraven p˚a, genom att under hela projektets g˚ang ha kontakt med olika mottagare. [110]

En av de stora skillnaderna mellan agil och icke-agil utvecklingsmetodik ¨ar det iterativa arbetet som utf¨ors i agil utveckling [104]. I och med att b˚ade projekt- gruppens och best¨allarens syn p˚a slutprodukten kan komma att ¨andras (vilket ¨

ar mycket troligt) kommer det att kr¨avas mycket kommunikation mellan dessa. D¨armed kan analysansvariges roll komma att bli st¨orre, d˚a denne frekvent m˚aste diskutera med best¨allaren om f¨orfr˚agningar om uppdaterade krav och framf¨ora projektgruppens ˚asikter om dessa f¨orfr˚agningar. Kravspecifikationen kan beh¨ova uppdateras upprepade g˚anger under projektets g˚ang vilket ofta ¨ar analysansva- riges ansvar att g¨ora om det best¨amts inom projektgruppen. Inom ett icke-agilt projekt fastst¨alls ist¨allet kraven och kravspecifikationen i b¨orjan av projektet, och ska d¨arefter inte ¨andras [103]. Analysansvariges roll kan d˚a bli mer inriktad p˚a att h˚alla kontakt med best¨allaren under projektet och uppdatera om hur l˚angt utvecklingen av produkten kommit.

Analysansvarig f˚ar ¨aven st¨orre ansvarsomr˚ade i allm¨anhet i agila projekt [111]. D˚a mer kommunikation kr¨avs kan det vara rimligt att l¨agga mer ansvar p˚a analysansvarig, d˚a denne ocks˚a ska ha b¨ast inblick i best¨allarens v¨arderingar gentemot projektgruppens. Ansvar som handledning och organisation av m¨oten, st¨orre roll och inflytande vid diskussioner och att vara insatt i produkt och ¨

onskem˚al p˚a detaljniv˚a k¨anns naturligt och rimligt att ge analysansvarig i agila projekt.

H.7

Slutsats

Det finns m˚anga olika teorier och f¨orh˚allningss¨att till agilt arbete, och ¨annu fler tolkningar. Inget projekt, agilt eller icke- agilt kommer n˚agonsin att vara identiskt med ett annat. Olika strategier och metoder kan anv¨andas p˚a det s¨att som passar specifika projektgrupper, medan vissa delar av dessa verktyg kan uteslutas. Enligt teorier som unders¨okts inf¨or denna rapport kan vissa slutsatser dras.

H.7.1 Hur f¨orh˚aller sig kundrelationer till kravhantering i agila mjuk-