EXAMENSARBETE. Prioritering av användningsfall för arkitekturfokuserade, användningsfallsdrivna, iterativa och inkrementella processer.

Transkript

1 2000:092 EXAMENSARBETE Prioritering av användningsfall för arkitekturfokuserade, användningsfallsdrivna, iterativa och inkrementella processer Kenneth Boman Civilingenjörsprogrammet Institutionen för Systemteknik Avdelningen för Programvaruteknik 2000:092 ISSN: ISRN: LTU-EX--00/092--SE

2 Prioritization of use cases for architecture-centric, use-case driven, iterative and incremental processes Kenneth Boman

3 Prioritering av användningsfall för arkitekturfokuserade, användningsfallsdrivna, iterativa och inkrementella processer Kenneth Boman Luleå, mars 2000 Handledare: Tomas Hedenström, Frontec Norr AB Examinator: Jan-Åke Lehto, Luleå Tekniska Universitet Examensarbete för civilingenjörsprogrammet vid Luleå Tekniska Universitet, institutionen för Systemteknik, avdelningen för Programvaruteknik. Utfört vid Frontec Norr AB. Alla företags och produktnamn används endast i identifikationssyfte och är varumärken eller registrerade varumärken för respektive företag.

4 Abstract This master thesis is about use-case prioritization for architecture centric, use-case driven, iterative and incremental processes such as Rational Unified Process. On several occasions, it is necessary to decide which use-cases are most important to implement. If you are using an iterative and incremental development process, you always have to choose use-cases for the next iteration and if there is a lack of resources, you may have to skip some of the least important use-cases. The purpose of this work is to investigate what prioritization methods are currently available, what factors influence the prioritization, how these should be weighed against one another and how a usable prioritization method could look like. My scientific approach, for this work, is relatively hermeneutic. I have weighed my own experiences, based on a case study, against knowledge from literature in the field. I have mainly used a qualitative and inductive method and the realization is based on a combination of explorative, descriptive and normative studies. During my work I have examined what factors influence prioritization, and from my point of view you have to consider how urgent the use-cases are, what value they represent, what cost and risk they result in, what influence they have on the architecture and if there are dependencies among use-cases. I have developed a method including these factors to simplify the prioritization. Obviously, all projects are more or less different so it is important to identify what type of project you are working on. To accomplish this, it is useful estimating criteria such as resource limitations, complexity, risk and instability. With this information, it is possible to decide which weight should be given to different factors. The most important conclusion drawn in this report is that there is a difference between how to prioritize use-cases worth implementing and in which order they should be implemented. iii

5 Sammandrag Denna rapport handlar om prioritering av användningsfall för användningsfallsdrivna, arkitekturfokuserade, iterativa och inkrementella processer som exempelvis Rational Unified Process. I många situationer måste man göra en avvägning av vilka användningsfall som är viktigast att implementera. Vid iterativ och inkrementell utveckling måste man alltid välja användningsfall till nästföljande iteration och vid resursbrist kan man tvingas välja bort något användningsfall. Syftet med detta arbete är att utreda vilka prioriteringsmetoder som finns tillgängliga, vilka faktorer som påverkar prioriteringen och hur dessa skall vägas mot varandra, samt föreslå eller utarbeta en praktiskt användbar prioriteringsmetod. Mitt vetenskapliga synsätt, för ett arbete av den här karaktären, är relativt hermeneutiskt. Jag har vägt samman egna erfarenheter med litteraturstudier. Metoden har till stor del varit kvalitativ och induktiv och genomförandet är baserat på en kombination av explorativa, deskriptiva och normativa studier. Jag har undersökt vilka faktorer som påverkar prioritering och kommit fram till att man bör ta hänsyn till hur brådskande olika användningsfall är, vilket värde de tillför, vilken kostnad och risk de medför, vilken inverkan på arkitekturen de har samt vilka beroenden gentemot andra användningsfall som förekommer. För att underlätta prioriteringen har jag utvecklat en metod där dessa faktorer ingår. Det är dock viktigt att komma ihåg att inget projekt är det andra likt så man bör identifiera vilken typ av projekt det är frågan om, genom att bedöma kriterier såsom resursbegränsningar, komplexitet, risk och ändringsfrekvens, för att därefter kunna avgöra vilken hänsyn som skall tas till olika faktorer. Den viktigaste slutsatsen jag dragit är att man bör skilja på prioritering av vad som är värt att implementera jämfört med i vilken ordning det skall implementeras. iv

6 Förord Detta projekt har utförts vid Frontec Norr AB under tidsperioden november 1999 till mars 2000 och utgör mitt examensarbete från civilingenjörsutbildningen i datateknik vid Luleå Tekniska Universitet. Min intressesfär ligger runt utvecklingsprocesser, utvecklingsmiljö och utvecklingsverktyg. Rent praktiskt kan man säga att jag är intresserad av alltifrån projektstyrning till kompilatorteknik och jag hoppas och tror att vi snart får se en komplett utvecklingsmiljö där både process och verktyg är integrerade. Utifrån ovanstående är det inte särskilt förvånande att jag valde detta examensarbete. Jag har studerat hur man kan förbättra och komplettera en utvecklingsprocess och jag har utvecklat ett verktyg som understödjer den del av processen som utgörs av prioritering av användningsfall. Det finns dock ytterligare en anledning till att jag valde just detta examensarbete och det är att det har både en akademisk karaktär och ger ett resultat som är praktiskt användbart långt fram i tiden. För datateknikutbildningen är utbudet av examensarbeten visserligen stort, men många av dessa, särskilt de som erbjuds av datakonsultföretag, har enbart eller till stor del praktisk karaktär och behandlar relativt kortlivade tekniker och därför vill jag tacka Frontec Norr AB som erbjuder examensarbeten som är allmänna och har både akademiskt och praktiskt intresse. Vidare vill jag även tacka min examinator, Jan-Åke Lehto, och min handledare, Tomas Hedenström. "Set priorities for your goals. A major part of successful living lies in the ability to put first things first. Indeed, the reason most major goals are not achieved is that we spend our time doing second things first." Robert J. McKain Luleå, mars 2000, Kenneth Boman v

7 Innehållsförteckning Abstract iii Sammandrag iv Förord v 1 Inledning Bakgrund Problembeskrivning Syfte Avgränsningar Läsanvisningar 4 2 Metoddiskussion Vetenskaplig utgångspunkt Modeller Praktiskt genomförande Källkritik 7 3 Rational Unified Process Introduktion till Rational Unified Process Prioritering i Rational Unified Process 10 4 Varför behöver man prioritera? 11 5 Att ta hänsyn till vid prioritering av användningsfall? Vem skall utföra prioriteringen? Vilka faktorer bör man ta hänsyn till? Inverkan på arkitektur Värde för kunden Kostnad Hur bråttom? Angelägenhet Risk Beroenden mellan användningsfall Projektkategorisering Resursbegränsningar Komplexitet Ändringsfrekvens Risknivå Modell för vägning av faktorer med avseende på projekttyp 19 6 Existerande prioriteringsmetoder Sorteringsalgoritmer 21 vi

8 6.2 Poängmetoden Procentmetoden Röstning Analytic Hierarchy Process 23 7 Val av prioriteringsmetod Krav på prioriteringsmetoden Utvärdering av prioriteringsmetoder Slutsats från utvärdering av prioriteringsmetoder Möjliga förbättringar av poängmetoden Förslag till beskrivning av poängnivåer för poängmetoden 32 8 Heltäckande metod för användningsfallsprioritering Hänsyn till skillnader i målsättning med prioritering Översikt av prioriteringsmetoden Val av användningsfall värda att implementera Val av ordning för implementation av användningsfall Konfigurering av prioriteringsmetoden 37 9 Datorstödd prioritering Behöver vi datorstödd prioritering? Fallstudie - applikation för datorstödd prioritering Diskussion och slutsatser Diskussion Slutsatser Rekommendationer till fortsatt arbete Referenser 43 Bilaga A - Ordlista 45 Bilaga B - Exempel på datorstödd prioritering 46 vii

9 1 Inledning I detta kapitel försöker jag sätta in prioritering av användningsfall i ett större sammanhang. Jag beskriver bakgrunden till denna rapport, vilka problem som finns med prioritering och vad syftet är med detta arbete. Jag behandlar även vilka avgränsningar jag gjort och hur detta arbete är avsett att läsas. 1.1 Bakgrund Vi ser idag en trend att komplexiteten hos modern programvara ökar i snabb takt. Detta övertygar allt fler systemutvecklare om behovet av att använda genomarbetade processer för att kunna leverera system av hög kvalitet, inom utsatt tid och inom fastställd budget. Inget projekt är det andra likt så dessa processer kan givetvis inte erbjuda en universell standardlösning på alla problem. Faktum är dock att många beslutssituationer upprepas i varje nytt projekt och ibland till och med flera gånger i ett projekt. För dessa situationer kan bra processer vägleda oss mot rationella beslut. Ett exempel är att vi i varje systemutvecklingsprojekt måste prioritera i vilken ordning vi skall utveckla olika delar av systemet. Det är viktigt att notera att vi faktiskt gör en prioritering oavsett om vi är medvetna om det eller inte. Det kan vara lämpligt att först och främst klarlägga vad en systemutvecklingsprocess egentligen är. Det handlar om att utföra visa aktiviteter för att skapa eller förbättra ett system. När man inleder processen har man viss indata, exempelvis en kravspecifikation, och när man avslutar processen har de aktiviteter man utfört tillsammans med given indata förhoppningsvis resulterat i ett väl fungerande system. En bättre och mer formell beskrivning ges av Kruchten (1998:35), som menar att en process är något som definierar vem som gör vad när och hur. Ytterligare en annan definition ges av Booch (1998), som beskriver en process som ett antal delvis ordnade steg för att uppnå ett mål. För en systemutvecklingsprocess utgörs detta mål av att på ett effektivt och förutsägbart sätt utveckla ett system som uppfyller organisationens behov. När man diskuterar systemutveckling använder man ofta begrepp såsom iterativ, inkrementell, användningsfallsdriven och arkitekturfokuserad. Många av de processer som har utvecklats under senare år har ett eller flera av dessa begrepp gemensamt. Iterativ innebär att man går igenom utvecklingsprocessen flera gånger. Varje varv i processen kallas iteration och iterativ utveckling består således av flera iterationer. Om man dessutom efter varje iteration producerar ett nytt delresultat, inkrement, så bedriver man inkrementell utveckling. Inkrementell betyder alltså att man sätter ihop systemet av små bitar istället för att försöka göra allting i ett stort steg. Liksom byggnadsarkitektens arbete handlar om att ta fram ritningar för att byggnadsarbetarna skall kunna konstruera en byggnad handlar systemarkitektens arbete om att utarbeta en beskrivning av hur ett system skall byggas upp. I detta ingår att beskriva hur olika delsystem hänger ihop och interagerar, hur komponenter är uppbyggda av mindre komponenter osv. Att en process är arkitekturfokuserad innebär att man hela tiden utgår 1

10 från systemets arkitektur för att begripa, konstruera, organisera och vidareutveckla systemet man arbetar med (Jacobson et al., 1999:6). Ett användningsfall är en beskrivning av hur en aktör utför någonting i ett system. Att en process är användningsfallsdriven innebär således att man utgår från användningsfall under alla faser av projektet, oavsett om det rör sig om att utveckla arkitekturen eller att testa systemet. Fördelen med att använda användningsfall under hela processen är att kundens önskemål aldrig glöms bort och det är enkelt att kommunicera mellan utvecklare och kund eftersom det oftast inte krävs någon speciell kompetens för att förstå ett användningsfall. Användningsfallsdriven utveckling försäkrar oss alltså om att vi utvecklar något som kunden behöver och fokuseringen på arkitekturen leder förhoppningsvis till ett stabilt och effektivt system som dessutom är enkelt att bygga vidare på. Den iterativa och inkrementella utvecklingen gör det enkelt att på ett tidigt stadium upptäcka eventuella problem eller felaktigheter. Den här rapporten kommer att behandla vad man måste ta hänsyn till och hur man bör gå till väga vid prioritering av användningsfall för processer som är arkitekturfokuserade, användningsfallsdrivna, iterativa och inkrementella. 1.2 Problembeskrivning Inom systemutveckling finns ofta ett behov av prioritering. Om tidsplanen inte håller måste man sänka ambitionsnivån och prioritera bort någonting, om det finns motsägelsefulla krav måste man prioritera och om man använder en inkrementell process måste man alltid prioritera vilka användningsfall som skall implementeras i ett visst inkrement. Trots att en stor del av utvecklingen idag sker med hjälp av inkrementella processer så är det ovanligt att använda formella metoder för prioritering. Ofta tänker man inte ens på att man gör en prioritering. Det är inte ovanligt att man börjar med att implementera de användningsfall som för stunden verkar mest intressanta istället för att implementera de som är viktigast. Jag har själv gjort mig skyldig till detta vid ett par tillfällen. I vissa fall används formella metoder för prioritering först när man upptäcker att tidsplanen inte håller, men då är det oftast redan för sent. Sannolikheten är stor att man har ägnat tid åt att implementera en del av de användningsfall som är mindre betydelsefulla och annars kunde ha prioriterats bort och endast har att välja på att prioritera bort något av flera mycket viktiga användningsfall. I den situationen har man mycket dåliga förutsättningar att producera en produkt kunden blir nöjd med. "When possible make the decisions now, even if action is in the future. A reviewed decision usually is better than one reached at the last moment." William B. Given, Jr. 2

11 Problemen med att hitta en metod för prioritering av användningsfall är många. I nästan alla projekt finns flera olika intressenter, alla med sin egen syn på vad som är viktigt. Kunden har en uppfattning, projektledaren en annan och systemutvecklaren en tredje. Beroende på vilken typ av projekt det handlar om måste man ta olika mycket hän syn till intressenternas önskemål. Vidare är prioritering ingenting man gör en gång i början av projektet utan något som måste utföras fortlöpande. Det kan tillkomma användningsfall eller uppfattningen om vad som är viktigast kan ändras i takt med att kunskapen om projektet ökar. I och med att prioriteringen skall utföras löpande måste den vara enkel att utföra. Med matematiska modeller, enkäter och intervjuer kan man visserligen få fram en väldigt bra bild av hur man skall prioritera men det tar alltför mycket tid från projektet och är därför kanske ingen bra lösning. 1.3 Syfte Huvudsyftet med detta arbete består i att hitta en metod, för att utföra prioritering av användningsfall, som är enkel att använda och som tar hänsyn till sådana faktorer att alla intressenters åsikter tillgodoses i nivå med vad som är rimligt för en viss typ av projekt. Metoden skall vara applicerbar på arkitekturfokuserade, användningsfallsdrivna, iterativa och inkrementella processer. Syftet kan sedan delas in i tre mindre delar. Först avser jag titta på vilka faktorer som påverkar prioritering av användningsfall och hur dessa skall vägas mot varandra i olika situationer. Därefter kommer jag att studera olika befintliga prioriteringsmetoder för att undersöka vilken som är mest lämpad för prioritering av användningsfall. Slutligen avser jag väva samman de två ovanstående delarna och föreslå eller utarbeta en praktiskt användbar metod för prioritering av användningsfall. 1.4 Avgränsningar Arbetet är, som jag tidigare varit inne på, begränsat till att täcka prioritering av användningsfall för processer som är arkitekturfokuserade, användningsfallsdrivna, iterativa och inkrementella. En process som har tagit fasta på dessa fyra begrepp är Rational Unified Process (RUP), som håller på att utvecklas till någon form av standard. Den här rapporten kommer därför i mångt och mycket utgå från RUP och dess terminologi. Det innebär inte nödvändigtvis att RUP är den bästa processen. En nyligen genomförd undersökning av de tre stora processerna, RUP, Object-oriented Process Environment and Notation (OPEN) och Object-Oriented Software Process (OOSP), rekommenderade programvaruindustrin att välja den marknadsledande RUP (om än med vissa kompletteringar från OPEN och OOSP) trots att RUP i många delar visade sig vara den sämsta av de tre processerna (Ambler, 1999). Skillnader mot andra processer kommer alltså inte att behandlas eftersom detta förmodligen bara skulle vara förvirrande utan att tillföra mervärde. Det är dock ändå min förhoppning att resultatet skall vara applicerbart på alla arkitekturfokuserade, användningsfallsdrivna, iterativa och inkrementella processer. 3

12 1.5 Läsanvisningar Nya ord förklaras när det introduceras men det finns även en ordlista längst bak i rapporten (Bilaga A) som förklarar de mest centrala begreppen. Efter önskemål från ansvariga på Frontec Norr AB är den här rapporten skriven på svenska och eftersom många fackuttryck används där det inte finns riktigt bra översättningar till svenska har det hela tiden varit en avvägning huruvida ord skall lånas in eller översättas. I de fall översättningar använts som inte känns riktigt uppenbara har jag första gången ordet använts placerat den engelska motsvarigheten inom parentes. Som referensteknik använder jag Harvardsystemet (Strömquist, 1998:40-42), vilket innebär att jag i texten anger referenser med författarnamn, årtal och eventuellt sidnummer inom parentes, för att sedan längst bak i rapporten redovisa en fullständig, alfabetisk, referensförteckning. I de fall författarens namn är angivet i texten skrivs enbart årtal och eventuellt sidnummer inom parenteserna. Fotnoter används för muntliga källor och för kommentarer till texten. På vissa ställen i rapporten har jag fristående klassiska citat. Dessa bygger inte upp rapporten utan finns bara med för att de i sammanhanget är tänkvärda att reflektera över och därför anges bara vem som har sagt eller skrivit citatet och ingen ytterligare referens. I denna rapport använder jag ofta begreppen informella respektive formella prioriteringsmetoder. Dessa begrepp är något luddiga och deras betydelse kan därför variera en aning mellan olika texter. Jag skall därför förklara min tolkning av dessa begrepp. Med informella metoder menar jag att man inte använder någon väl definierad prioriteringsprocess, man kanske kommer överens om hur man skall prioritera genom en diskussion eller så är man inte ens medveten om att man har utfört en prioritering. Med formella prioriteringsmetoder åsyftar jag istället strukturerade metoder där det går att se vad som legat till grund för ett visst resultat och där man utför bedömningar efter i förväg fastställda kriterier. "When I use a word, Humpty Dumpty said in a scornful tone, It means just what I choose it to mean neither more nor less." Lewis Carroll 4

13 2 Metoddiskussion I detta kapitel redogör jag för den vetenskapliga utgångspunkt jag har haft under detta arbete, så att ni som läsare själva kan avgöra vilken relevans mina resultat har. Jag behandlar även hur jag rent praktiskt har gått till väga och vilka problem som finns med de källor jag har använt mig av. 2.1 Vetenskaplig utgångspunkt Två vanliga vetenskapliga ideal är hermeneutik och positivism. Det hermeneutiska idealet kännetecknas av att man tolkar texter och annan information i utifrån sitt sammanhang och utifrån de erfarenheter man för tillfället besitter. Helheten växer fram allteftersom studiet av delarna ger kunskaper om hur allt hänger samman (Wallén, 1993:31). Positivism bygger på att kunskap endast är värdefull om den kan verifieras. Vetenskap skall baseras på mätningar och inte bedömningar (Wallén, 1993:24). Min uppfattning är att valet av synsätt måste variera beroende på vilket ämne man studerar och det blir aldrig helt en fråga om antingen eller utan snarare en kombination. För detta ämne fann jag det dock lämpligt att lägga tyngdpunkten på hermeneutiken. Jag har främst ägnat mig åt litteraturstudier och utifrån egen erfarenhet reflekterat kring redan kända fakta. Jag har dessutom utfört en fallstudie som har gett mig mer erfarenhet och hjälpt mig att bättre förstå helheten. Studier kan antingen vara kvantitativa eller kvalitativa. Kvantitativ innebär att man mäter egenskaper efter en skala och kvalitativ innebär att man enbart utreder huruvida en egenskap är relevant. Jag har mestadels utfört kvalitativa studier och då främst en speciell typ av kvalitativa studier som kallas kvalitativ kategorisering, vilket bl.a. innebär att man utreder vilka faktorer som är betydelsefulla och vad som kännetecknar dessa (Wallén, 1993:69). Ett visst mått av kvantitativt arbete var dock oundvikligt eftersom den metod, för prioritering av användningsfall, jag har utarbetat är avsedd att ge kvantitativa resultat. Man skiljer även på explorativa, deskriptiva, förklarande och normativa studier. Explorativa studier innebär att man studerar vad som ingår i problemet och vad som inte ingår, deskriptiva studier innebär att man kategoriserar fakta och beskriver samband, förklarande studier innebär att man utreder varför någonting inträffar och i normativa studier ingår att man bedömer hur någonting skall utföras (Wallén, 1993:43-44). Mitt arbete har bestått av en kombination av explorativa, deskriptiva och normativa studier. Jag har undersökt vilka faktorer som påverkar prioritering och vad man måste ta hänsyn till, jag har beskrivit samband mellan olika faktorer och projekttyper och jag har utvecklat en metod över hur man kan gå till väga för att prioritera användningsfall. Vidare brukar man skilja på deduktiva och induktiva metoder. En deduktiv metod innebär att man tar fram en hypotes och studerar huruvida den håller eller inte medan 5

14 man med en induktiv metod samlar in data och försöker dra slutsatser och utarbeta teorier (Wallén 1993:44-45). Mina resonemang är till mycket stor del induktiva, jag har samlat in och analyserat information och utifrån detta utarbetat modeller. 2.2 Modeller I detta arbete tar jag fram ett antal modeller och det är då viktigt att komma ihåg att modeller alltid är en förenkling av verkligheten, de är inte på något sätt korrekta eller kompletta. Wallén (1993:55-56) ställer upp ett antal krav som modeller bör uppfylla, de skall vara systematiska, effektiva och generaliserbara, alla relevanta faktorer skall vara med, modellvillkor skall vara angivna och modellerna skall överensstämma med övergripande teorier. De modeller jag utarbetat är grundade på teori, men i vissa fall har jag stött på motsägelser inom teorin. I dessa fall har jag inte valt det ena eller det andra alternativet utan försökt låta modellen spegla båda sidorna på bästa sätt. Jag har lagt stor vikt vid att modellerna skall vara lätthanterliga, detta är dock en svår avvägning eftersom ju mer man förenklar desto mer avviker modellen från verkligheten. Det är även svårt att försäkra sig om att kravet på validitet är uppfyllt, det vill säga att alla relevanta faktorer ingår i modellen. Hur vet man att inga relevanta faktorer saknas vid en studie av den här typen. Det kan man givetvis inte veta, men jag har försökt lista så många faktorer som möjligt och sedan delat in dem i lämpliga kategorier och det är därför min förhoppning att faktorer jag har missat att ta hänsyn till ändå skall falla inom någon av dessa kategorier. Giltighetsområdet för de modeller jag har behandlat är strikt prioritering av användningsfall vid arkitekturfokuserade, användningsfallsdrivna, iterativa och inkrementella processer. Jag skulle kunna tänka mig att modellerna är generaliserbara även till prioritering av krav om man bortser från det faktum att antalet krav för ett projekt kan vara mycket större än antalet användningsfall, vilket skulle kunna leda till skalbarhetsproblem. 2.3 Praktiskt genomförande Det stora problemet inom programvaruteknikområdet är inte bristen på forskning om metoder och processer utan att den kunskap som finns inte används. Det är bara att konstatera att formell prioritering av användningsfall inte är särskilt utbredd och därför är det förmodligen ingen större mening att använda sig av enkäter eller intervjuer. Däremot finns en hel del tvärvetenskaplig forskning om prioritering i största allmänhet och därför fann jag det lämpligt att först och främst basera detta arbete på litteraturstudier. Det är dock viktigt att ha i åtanke att resultaten måste vara praktiskt applicerbara och därför valde jag att, med hjälp av Rational Unified Process utveckla en applikation, vars uppgift är att understödja prioritering av användningsfall. Genom att direkt testa de teoretiska idéerna är det enklare att säkerställa ett praktiskt användbart resultat samtidigt som jag gör resultaten av min undersökning mer tillgängliga. Inom den teoretiska delen började jag med att göra en ämnesöversikt för att få en överblick av vilka närliggande ämnesområden som kunde innehålla relevant information. Därefter sökte jag och sammanställde information från artiklar och böcker för att sedan analysera relevans och utarbeta en lämplig metod för prioritering av användningsfall. 6

15 Det praktiska arbetet utfördes enligt en delmängd av Rational Unified Process kompletterat med den formella prioriteringsmetod jag har utarbetat. Både den teoretiska och den praktiska delen bedrevs i två iterationer för att kunna garantera hög kvalitet till låg risk. 2.4 Källkritik Det finns en myt inom datateknikområdet att kunskap snabbt blir omodern. I viss mån kanske den myten är sann vad gäller kunskap om speciella tekniker, men vad gäller de bakomliggande teorierna om exempelvis utvecklingsprocesser så kan man nog anse att den existerande kunskapen börjar bli ganska stabil. Dels har det visat sig ta år innan nya idéer kommer till praktisk användning och dels beräknas halveringstiden för värdet av kunskap inom detta område under de senaste decennierna ha ökat från omkring tio till trettio år (McConnell, 1999:83,145). De flesta källor jag har använt är från 1998 eller 1999 och bör därför vara högst relevanta. Flera av källorna utgörs också av några av de största namnen inom respektive område, såsom Booch, Jacobson, McConnell, Rumbaugh, Saaty och Wiegers, vilket ytterligare borde öka tillförlitligheten. Det förekommer vissa motstridigheter i litteraturen, och då framförallt på grund av att olika författare ser på saker från olika synvinklar. När så är fallet har jag redovisat det och själv försökt se på saken från båda synvinklarna. Produkten Rational Unified Process utgör givetvis en stor källa till information, men eftersom den är kommersiell har jag undvikit att referera till den och har istället refererat till artiklar, avhandlingar och böcker som är tillgängliga på bibliotek eller som webbsidor på nätet. Många av de texter jag har använt mig av finns både i elektronisk form och som artiklar publicerade på konferenser. I de fall jag hämtar information från Internet beror det givetvis på att jag bedömer att det tar för lång tid att beställa materialet från biblioteket. Tillförlitligheten kan dock vara lägre för webbsidor än för tryckt material och därför är dessa referenser i minoritet och ofta använda i mindre centrala sammanhang. 7

16 3 Rational Unified Process Jag har valt att basera detta arbete på Rational Unified Process (RUP) och dess terminologi eftersom denna process håller på att bli någon slags standard. Detta kapitel är avsett att fungera som en kort introduktion till de fundamentala begreppen i RUP och till när man prioriterar i RUP. För den som är intresserad av en bättre beskrivning hänvisar jag till "The Unified Software Development Process" av Jacobson et al. (1999), vilken trots drygt 460 sidor också är att betrakta som en introduktion till RUP i jämförelse med den kompletta dokumentationen på ungefär 2000 sidor. 3.1 Introduktion till Rational Unified Process RUP är utvecklad av framförallt Grady Booch, Ivar Jacobson och Jim Rumbaugh. Dessa tre herrar hade ursprungligen utvecklat sina egna processer. Jacobson skapade Objectory metoden, Booch skapade Booch-metoden och Rumbaugh skapade Object Modelling Technique (OMT). Därefter gick de samman och tog de bästa delarna från de olika metoderna och skapade RUP (Jacobson et al., 1999:xxiii-xxv). RUP är alltså inte baserad på någon nyvunnen kunskap utan utgör mer en sammanställning av goda erfarenheter från ledande delar av mjukvaruindustrin. Framförallt utgår RUP från sex grundläggande principer, som har visat sig fungera bra (Kruchten, 1998:5-15): 1. Iterativ utveckling - ger lägre risk och förenklar hantering av ändrade krav. 2. Kravhantering - försäkrar oss om att vi bygger det system kunden vill ha. 3. Komponentbaserad arkitektur - förenklar återanvändning och ger överblickbara system. 4. Visuell modellering - underlättar kommunikation mellan olika intressenter. 5. Kvalitetsuppföljning - hjälper oss att hitta fel så tidigt som möjligt, vilket minskar den totala kostnaden. 6. Hantering av ändringar - underlättar felsökning och minskar komplexitet. Som jag tidigare nämnt är RUP användningsfallsdriven, arkitekturfokuserad, iterativ och inkrementell. Användningsfallsdriven och arkitekturfokuserad hänger väldigt intimt samman. I början ligger de första användningsfallen till grund för arkitekturen, men i fortsättningen kommer arkitekturen att utgöra en begränsning för vilka användningsfall som på ett enkelt sätt går att implementera och det är därför av största vikt att tidigt hitta så många för arkitekturen relevanta användningsfall som möjligt samt skapa en sund arkitektur som enkelt går att bygga vidare på (Jacobson et al., 1999:65-69). Om arkitekturen tidigt skall spegla de viktigaste användningsfallen kräver det givetvis att vi vet vilka användningsfall som är viktigast och det handlar om prioritering, oavsett om man använder informella eller formella prioriteringsmetoder. Iterativitet och inkrementalitet uppnås bland annat genom att RUP består av ett antal cykler. Efter varje cykel skall en ny version av systemet vara färdigt. Varje cykel består av fyra faser, inledningsfas (inception), upphöjningsfas (elaboration), konstruktionsfas (construction) och överlämningsfas (transition), och en eller flera iterationer över var och en av dessa. Varje fas avslutas med en milstolpe där man avgör om målen för fasen 8

17 uppnåtts och huruvida man skall fortsätta utvecklingen. I varje fas utförs sex processarbetsflöden, verksamhetsmodellering (business modeling), kravinsamling, analys och design, implementation, test och införande (deployment) samt tre stödjande arbetsflöden, hantering av ändringar, projektstyrning och konfigurering av utvecklingsmiljö (Kruchten, 1998:22-23). Alla arbetsflöden ingår i alla faser, men i olika stor omfattning. I figur 1 visas en översikt av hur man går igenom alla processarbetsflödena för varje fas i RUP. Figur 1. Översikt av faser och arbetsflöden i RUP De olika arbetsflödena består i sin tur av ett antal aktiviteter. Arbetsflödena specificerar vem som skall göra vad och i vilken ordning samt vilka resultat, artefakter, som skall produceras i varje aktivitet. RUP definierar ungefär 30 olika roller såsom exempelvis projektledare, användare, arkitekt, och testare. Varje projektmedlem kan anta en eller flera roller och flera projektmedlemmar kan även dela på en roll. RUP definierar vilken roll som är ansvarig för olika artefakter och vilka roller som skall utföra vilka aktiviteter (Kruchten, 1998:36-37). Vidare är RUP också riskdriven, vilket innebär att man skall försöka att så tidigt som möjligt i processen undanröja eller hantera alla risker. Detta är förenligt med de fyra begreppen arkitekturfokuserad, användningsfallsdriven, iterativ och inkrementell. Man undanröjer risker att arkitekturen inte blir tillräckligt stabil och flexibel, man undanröjer risken att man bygger ett system som inte uppfyller användarens behov, osv. (Jacobson, et al., 1999:94-96). 9

18 RUP är långt mer omfattande än alla välkända klassiska processer såsom vattenfallsmodellen eller spiralmodellen, vilket gör det i princip omöjligt att direkt börja använda processen fullt ut. Processen är dock konfigurerbar, man väljer att använda de delar som passar organisationen och det aktuella projektet och utelämna resten. Om projektmedlemmarna exempelvis inte är bekanta med RUP sedan tidigare kan man välja att endast använda en delmängd av RUP för att sedan utöka användningen i nästföljande projekt. 3.2 Prioritering i Rational Unified Process Eftersom RUP är en iterativ process måste man prioritera vilka användningsfall som man skall arbeta med i varje iteration. Om man inte hinner med alla användningsfall kan man bli tvungen att skjuta på dem till nästa iteration eller helt utesluta dem och det kan därför även vara bra att rangordna användningsfallen inom en iteration så att man arbetar med de viktigaste först. Prioriteringsaktiviteten, som utförs av arkitekten, bestämmer vilka användningsfall som skall analyseras, designas, implementeras, osv. och utförs under arbetsflödet kravinsamling. Vikten på kravinsamling ligger främst i upphöjningsfasen och inledningsfasen, men också i viss mån i konstruktionsfasen. Innan man prioriterar utför man en aktivitet som går ut på att lista möjliga användningsfall och aktörer, men man gör dock inte någon detaljerad beskrivning av användningsfallen förrän efter prioriteringen eftersom man inte vill spendera mer resurser än nödvändigt på mindre viktiga användningsfall (Jacobson et al., 1999:118,143, ). I ett projekt där alla fakta och användningsfall är kända från början och där inga ändringar inträffar behöver prioriteringen förstås bara utföras en enda gång, tyvärr är sådana projekt sällsynta om de ens existerar och därför krävs det att prioriteringen upprepas för varje iteration när nya användningsfall tillkommit eller kunskaper om risker och kundbehov har ökat. "All our final decisions are made in a state of mind that is not going to last." Marcel Proust RUP ger förslag på och mallar till dokument som skall vara indata till respektive utdata från prioriteringen. Exakt vilka dokument det rör sig om är i sammanhanget irrelevant, men givetvis behöver man veta vilka användningsfall som finns och vad som är det övergripande målet med projektet. Som utdata får man information som underlättar schemaläggningen av nästa iteration. 10

19 4 Varför behöver man prioritera? Som jag tidigare varit inne på uppstår tillfällen då man måste prioritera. Det här kapitlet kommer att kortfattat beskriva några sådana situationer. Det är vanligt att tids- eller resursplanen inte håller, vilket leder till att ambitionsnivån måste sänkas och då är det viktigt att man åtminstone hunnit klara av de viktigaste användningsfallen. Om man är inriktad mot försäljning på en massmarknad med många konkurrenter finns det exempelvis ett värde i att vara först ut med en produkt och då kan det vara nödvändigt att utelämna vissa användningsfall. Vid inkrementella processer behövs dessutom alltid en prioritering av vad som skall utvecklas i nästa inkrement. Ibland står olika krav eller användningsfall i konflikt med varandra, eller så är det åtminstone tekniskt omöjligt att med tillräcklig prestanda implementera alla användningsfallen. Då behövs en prioritering av vilket av dessa användningsfall som är viktigast. "It does not take much strength to do things, but it requires great strength to decide on what to do." Elbert Hubbard Redan på 1800-talet upptäckte Vilfredo Pareto det statistiska sambandet som kallas Pareto-principen eller regeln (Karlsson & Ryan, 1996), vilken kan tillämpas på många områden inom systemutveckling. 80% av kostnaden beror på 20% av användningsfallen och omvänt för 20% av kostnaden nås 80% av användningsfallen. Det grundläggande målet vid systemutveckling är givetvis att utveckla bästa möjliga system till lägsta möjliga pris och det kan därför vara bra att ha denna princip i åtanke. Man brukar även tala om "golden-plate" fenomenet (Wiegers, 1999:13-14), vilket handlar om att utvecklaren skapar en, enligt eget tycke, bra funktion som användaren inte alls tycker om, begriper eller kommer att använda. Många ingenjörer känner stolthet över sitt yrke och vill konstruera det perfekta systemet, men det finns sällan 1 anledning att lägga ner resurser på att utveckla funktioner som användaren aldrig kommer att utnyttja. Om alla projektmedlemmar jobbar med en liten del av ett projekt är det lätt att de uppslukas av denna och inte ser vad som är viktigt för helheten. Genom att utföra en prioritering där alla är överens om resultatet kan man etablera en gemensam vision om vad man först och främst vill åstadkomma. Det är då enklare för en projektledare att omfördela folk utan att någon tappar motivationen för att de inte får fortsätta med vad de höll på med. Det är viktigt för självförtroendet att veta att det man gör är viktigt och en prioritering hjälper folk att se vad som är viktigt och uppmuntrar dem att jobba med dessa bitar. 1 Vissa undantag förekommer, exempelvis när man på grund av marknadsföringsskäl måste utveckla en produkt som klarar allt vad konkurrenterna klarar och lite till. 11

20 5 Att ta hänsyn till vid prioritering av användningsfall? Syftet med det här kapitlet är att visa vilka faktorer och intressenter vi bör ta hänsyn till vid prioritering av användningsfall och hur man skall väga olika faktorer mot varandra i olika situationer och vid olika typer av projekt. 5.1 Vem skall utföra prioriteringen? Vem som skall utföra prioriteringen beror givetvis till stor del på vilken typ av projekt det är frågan om. Vid ett litet projekt kan det kanske räcka att en person utför prioriteringen och vid större projekt kan fler personer delta. I Rational Unified Process finns, som jag har nämnt tidigare, olika roller. En roll kan besättas av en eller flera personer och en person kan ha flera roller. Prioriteringen i Rational Unified Process utförs av rollen arkitekt (Jacobson, et al., 1999:143). Givetvis besitter denne oftast viktig teknisk kompetens, som behövs för att utföra prioriteringen, men enligt min uppfattning är arkitekten inte alltid tillräckligt insatt i övriga intressenters önskemål. Det system som utvecklas skall lösa en uppgift och kunden eller användaren vet bäst vad uppgiften i fråga rör sig om. Kunden vet dock ofta inte vad han/hon vill ha och kan inte bedöma vilken kostnad det medför eller vad som är tekniskt möjligt att realisera. Projektledaren i sin tur känner till vilka resurser som finns tillgängliga och kan bedöma kostnaden för olika användningsfall, men behöver förmodligen hjälp från arkitekten för att identifiera tekniska svårigheter. Det hela handlar om ett samspel mellan olika intressenter och därför anser jag att tre roller tillsammans bör utföra prioriteringen, kund, arkitekt och projektledare. Kundrollen kan exempelvis bestå av den som betalar för systemet, en användare av systemet, någon från marknadsavdelningen eller i värsta fall någon utvecklare som sätter sig in i kundens situation. Jag vill återigen betona att en roll kan besättas av en eller flera personer och en person kan ha flera roller. 5.2 Vilka faktorer bör man ta hänsyn till? Vid valet av faktorer som skall användas vid prioriteringen är det viktigt att ta hänsyn till de fundamentala begreppen, användningsfallsdriven arkitekturfokuserad, iterativ och inkrementell, som utgör grunden för Rational Unified Process. Användningsfallsdriven leder oss att tro att vi bör ta hänsyn till värdet för kunden av de olika användningsfallen. Man bör dock tänka på att värdet för kunden är relaterat till utvecklingskostnaden. Kunden vill ha bästa möjliga system till lägsta möjliga pris. Att processen är arkitekturfokuserad antyder att även arkitekturen har stor betydelse vid prioriteringen. Iterativ och inkrementell speglar att man bör prioritera de användningsfall som hela tiden ger exekverbara versioner med de funktioner som kunden är i mest akut behov av att använda och för vilka det inte finns alternativa system. Som bekant är ju RUP också riskdriven och det är därför naturligt att ta hänsyn till hur riskfyllda olika användningsfall är. 12