Examensarbete 20 poäng D-nivå KOMPETENSSYSTEM. Reg.kod: Oru-Te-EXA089-D108/04 Peter Lorenz. Magisterprogrammet i Datateknik 160 p

Transkript

1 Examensarbete 20 poäng D-nivå KOMPETENSSYSTEM Reg.kod: Oru-Te-EXA089-D108/04 Peter Lorenz Magisterprogrammet i Datateknik 160 p Örebro vårterminen 2004 Examinator: Lars Karlsson COMPETENCE SYSTEM Örebro universitet Örebro University Institutionen för teknik Department of technology Örebro SE Örebro, Sweden

2 Sammanfattning Denna rapport beskriver utvecklingen av ett kompetenssystem i ASP.NET och programmeringsspråket C# för publikation på ett intranät. Projektstyrningsmodellen PMM (Project Management Model) och utvecklingsmetoden RUP (Rational Unified Process) har använts vid projektets genomförande. De kunskaper om RUP som projektet gav har tillsammans med litteraturstudier om TPFDmetoden (TestPlan Före Design) och XP (Extreme Programming) resulterat i en jämförelse mellan dessa metoder. Abstract This report describes the development of an online competence management system in ASP.NET and the programming language C#. The project management model PMM and RUP (Rational Unified Process) have been used in the project. The report also includes a comparison between RUP, TPBD (TestPlan Before Design) and XP (Extreme Programming).

3 Förord Till grund för denna rapport ligger det examensarbete som utförts på uppdrag av Meteorit AB under våren Examensarbetet avslutar magisterprogrammet i Datateknik vid Örebro Universitet, Institutionen för Teknik. Jag vill speciellt tacka följande personer: Peter Moström, min handledare på Meteorit, för att han gett mig förtroendet att utveckla det nya kompetenssystemet. Projektets referensgrupp som kommit med många bra förslag på systemets funktionalitet. Håkan Lindegren, min handledare vid Örebro Universitet som granskat och gett goda råd om rapportens utseende. Örebro den 31 maj 2004 Peter Lorenz

4 INNEHÅLLSFÖRTECKNING 1 INLEDNING BAKGRUND SYFTE METOD OCH KÄLLOR BEFINTLIGT KOMPETENSSYSTEM GENERELLA KOMPETENSSYSTEM REFERENSGRUPPSMÖTEN PPH-KURSEN LITTERATURSTUDIER PROJEKTBESKRIVNING ÖVERGRIPANDE KRAV PÅ UTFORMNING AV SYSTEMET METODIK PMM Vattenfallsmodellen RUP MICROSOFT.NET ASP.NET ADO.NET DataSet DataReader ANVÄNDARAUTENTISERING I ASP.NET SESSIONSOBJEKTET HOGIA KOMPETENSUTVECKLING RESULTAT ANVÄNDARGRÄNSSNITT SYSTEMDESIGN Utvecklings- och målmiljöer Logik Databaskonstruktion Inloggning och autentisering av användare JÄMFÖRELSE AV RUP, EXTREME PROGRAMMING OCH TPFD XP TPFD RUP ARTEFAKTMÄNGD SAMMANFATTNING DISKUSSION REFERENSER Peter Lorenz 4(47)

5 1 Inledning 1.1 Bakgrund Meteorit är ett konsultbolag inom systemutveckling och nätverk som grundades i Örebro Deras affärsidé är att vara en stark och långsiktig IT-partner för större företag och organisationer. Meteorit har ett behov av att beskriva och kontinuerligt uppdatera vilken kompetens respektive medarbetare har. I anslutning till offerter, planering av uppdrag eller att man helt enkelt behöver hjälp av en viss karaktär är det viktigt att snabbt och enkelt kunna ta reda på vem som kan vad om en bransch, produkt eller teknologi. Det finns också ett behov av att kunna se hur den gemensamma kompetensen är fördelad per organisatorisk enhet för att man skall få en bild av vilken kompetens som finns var. Det är också viktigt i den strategiska kompetensplaneringen. Meteorit har sedan tidigare tagit fram ett system för att hantera kompetens men detta system kom aldrig i drift och har därmed inte använts. Nu är systemet något föråldrat och behöver byggas om. 1.2 Syfte Syftet med examensarbetet är att genom systemering och programmering ta fram ett nytt kompetenssystem. Detta skall sedan publiceras på intranätet och vara tillgängligt för alla Meteorits anställda. PMM (Project Management Model) och RUP (Rational Unified Process) kommer att användas som styrmetoder vid projekt och utvecklingsarbetet. De erfarenheter om RUP som arbetet ger, kommer tillsammans med litteraturstudier om TPFD-metoden (TestPlan Före Design) och XP (Extreme Programming) att ligga till grund för en jämförelse av olika programutvecklingsmetoder. Peter Lorenz 5(47)

6 2 Metod och källor Detta avsnitt beskriver de metoder och källor som ligger till grund för kravspecifikation och utveckling av det nya kompetenssystemet. 2.1 Befintligt kompetenssystem Meteorit utvecklade redan år 2001 ett kompetenssystem i Java, se figur 2.1. Systemet blev dock aldrig helt färdigställt och togs ej i bruk på grund av dess många buggar och brist på funktionalitet. Grundtanken i systemet var att den anställde skulle gå igenom alla inlagda kompetenser och ange nivå noll på de kompetenser man saknade. Övriga delar av systemet fungerade ej. Figur 2.1: Gammalt kompetenssystem 2.2 Generella kompetenssystem Skärmdumpar på kommersiella system hämtade från (LCube AB, 2004) och (P&L Nordic AB, 2004) har studerats för att inspirera och ge idéer om vilken funktionalitet som bör ingå i ett kompetenssystem. 2.3 Referensgruppsmöten Tre möten med referensgrupp bestående av kompetensansvariga vid företaget har hållits. Första mötet hölls i samband med förberedelsefasen och resulterade i ett stort antal krav på systemet. Andra mötet ägde rum innan konstruktion för att diskutera programmets design. Tredje mötet hölls för att fastställa testrutiner innan test-och-felrättning av systemet påbörjades. 2.4 PPH-Kursen Hösten 2004 gick jag kursen PPH (Programvaruutveckling och projekthantering) vid Örebro Universitet, Institutionen för Teknik. Kursen har utarbetats av Håkan Lindegren och går på halvfart en hel termin. Studenterna lottas in i grupper om fyra personer och skall sedan bedriva ett utvecklingsprojekt med hjälp av TPFD-metoden, dvs kravspecificering, testplan, design och implementation. För att bli godkänd krävs att en produkt levereras och fungerar enligt uppställda krav. Det är främst via kursen jag har kännedom om TPFD-metoden, som jämförs med RUP och XP i den här rapporten. Peter Lorenz 6(47)

7 I min grupp beslöt vi oss för att ta fram ett Windowsprogram i vilket man enkelt skulle kunna budgetera sin vardagliga ekonomin. Resultatet vid kursens slut var programmet HemBudget (2003). Det inkluderar funktioner som till exempel fleranvändarstöd och grafisk statistik. 2.5 Litteraturstudier Lunell (2003), Beck (1999) och Lindegren (2003) har studerats för att ge underlag för en jämförelse mellan utvecklingsmetoderna RUP, XP och TPFD. Kriterier för jämförelsen sattes långt in i projektet. Erfarenheterna från TPFD och RUP blev där styrande. Kriterierna ser ut så här: Vilka är skillnaderna i kravhantering? Vad är skillnaden i dokumentmängd? Hur väl lämpar sig metoderna i utbildningssyfte? Peter Lorenz 7(47)

8 3 Projektbeskrivning Detta avsnitt beskriver övergripande krav på systemet samt de projektstyrnings- och utvecklingsverktyg som använts under projektets gång. Sist i avsnittet presenteras den kompetensutvecklingsmodell som legat till grund för systemet. 3.1 Övergripande krav på utformning av systemet Systemet skall utvecklas i form av en webbapplikation för publicering på intranätet. Ingen extra inloggning skall vara nödvändig för användaren. Autentisering skall ske via företagets Active Directory. Detta kallas för single sign-on. Två typer av användare skall finnas i systemet, administratör och anställd. Administratörerna skall ha tillgång till analyser, utvecklingshistorik samt systemadministration. För att klassas som administratör av systemet skall det räcka med att användaren är medlem i gruppen KompetensAdmin i Active Directory. Applikationen skall utvecklas i ASP.NET och C#. Programmet skall spara information i en Microsoft SQL-databas. Systemet skall integreras med Hogia för att kunna sortera anställda och visa information utifrån företagets organisatoriska enheter. (Hogia är ett moduluppbyggt affärssystem. Moduler finns för till exempel fakturering, kundreskontra; projektredovisning; tidsredovisning etc.) PMM skall användas som styrmetod under projektets gång. RUP skall användas som utvecklingsmetod. Systemet skall döpas till Kompetensia v1.0 Meteorit Professional Edition. 3.2 Metodik För att kunna se hur olika aktiviteter är relaterade till varandra samt kunna följa ett projekts livscykel används ofta en projektstyrnings- och utvecklingsmetod. Här följer en genomgång av PMM och RUP. På grund av sitt historiska värde beskrivs även Vattenfallsmodellen PMM Figur 3.1: Faser i PMM Peter Lorenz 8(47)

9 PMM (Project Management Model) är en projektstyrningsmodell som Meteorit tillämpar. figur 3.1 visar en överblick av de aktiviteter som ett projekt passerar under sin livscykel. PMM används för att säkerställa att: En metodisk modell finns som stöd vid projektarbetet. Krav, mål och omfattning är klargjorda och motsvarar leveransobjekt. Nivån på kontroll är tillräcklig för att uppfylla uppdragsgivarens direktiv. Kvalitetssäkring kan genomföras på ett och samma sätt för alla projekt. Kunden får en positiv bild och upplever en genomgående hög kvalitet i Meteorits arbetssätt i projektet. Initieringsfas (Initiate) Uppdragsbeskrivningen (benämnd REM i figur 3.2) fungerar som indata till initieringsfasen. Dokumentet klargör vad som förväntas av projektet, tidpunkt för leverans samt till vilken kostnad projektet kan genomföras. Den är en hörnsten i projektinitieringen och ligger som grund till beslut om projektet kan genomföras eller ej. Projektets sponsor måste signera uppdragsbeskrivningen för att säkerställa att dess innehåll överensstämmer med förväntat resultat. Projektspecifikationen (PS) är utdata från initieringsfasen. Den beskriver resultatet av fasen och fungerar som kontrolldokument för den efterföljande styrningen av projektet. Dokumentet måste godkännas av projektstyrningsgruppen eller sponsorn innan projektets genomförandefas kan påbörjas. Figur 3.2: Initieringsfasen Genomförandefas (Manage) Under genomförandefasen bedrivs parallellt alla de aktiviteter som finns specificerade i projektspecifikationen. Arbetet är händelsedrivet vilket betyder att oplanerade händelser är förväntade. För att hantera detta hålls löpande möten, övervakning, förändringshantering, verifikation samt acceptanstest och projektets sponsor hålls informerad om projektets framskridande genom leveransdokument (DEL). Denne måste sedan returnera ett signerat acceptansprotokoll (ACC) för att bekräfta att resultatet överensstämmer med kraven på projektet. Project Working Model I denna aktivitet, som drivs parallellt med Manage, tillämpas någon utvecklingsmetod för programvara, till exempel RUP. Avslutningsfas (Terminate) I avlutningsfasen lämnas leveransobjektet över till ägaren tillsammans med dokumentation till dess supportorganisation. Projektgruppen sammanställer erfarenheterna från projektet och resurser frigörs. Peter Lorenz 9(47)

10 3.2.2 Vattenfallsmodellen Vattenfallsmodellen är en utvecklingsmodell för programvara. Den togs fram på 70-talet då man såg behov av ett strukturerat arbetssätt. Den bygger på illusionen att det är möjligt att i ett tidigt skede av projektet fastställa och frysa systemets samtliga krav. Faserna i tabell 3.1 passeras och en ny fas kan inte påbörjas förrän den gamla är helt färdig. Eventuella problem som dyker upp skjuts på framtiden eller kodas runt och om kravändringar hotar arbetets gång håller man sig till det som bestämts från början. Kravanalys Design Implementation och deltest Systemtest I dag finns stor enighet om att vattenfallsmodellen inte lämpar sig för mjukvaruutveckling. Det har visat sig att ett parallellt och iterativt arbetssätt, som exempelvis RUP förespråkar lämpar sig mycket bättre än vattenfallsmodellens linjära och sekventiella metodik (Tallung, 2003). Tabell 3.1: Vattenfallsmodellens faser RUP RUP är en generell process för programvaruutveckling. Det är en kommersiell produkt som marknadsförs och utvecklas av Rational Software Corporation (IBM Rational, 2004) och nya utgåvor kommer regelbundet. I RUP har man försökt samla mycket av dagens bästa praxis inom programvaruutveckling och den är avsedd att fungera i så väl små som stora projekt. Detta betyder att RUP innehåller en stor mängd dokumentation och mallar, många av mycket abstrakt karaktär. Det finns ofta ett behov av att anpassa RUP efter projektets storlek, konkretisera beskrivningar och komplettera anvisningar med mera, därför brukar RUP även kallas för en konfigurerbar process. Bästa praxis betyder att man i RUP inkluderat ett antal väl beprövade metoder från tidigare programvaruutvecklingsmodeller. Dessa kan användas vid utveckling utan att för den skull tillämpa RUP. I dokumentationen återfinns följande sex beprövade metoder. Iterativ utveckling Utvecklingen delas upp i fyra större faser enligt figur 3.3 inom vilka ett antal iterationer sker. På svenska skulle dessa faser kunna kallas Föreberedelse, Etablering, Konstruktion och Överlämning (Lunell, 2003). Antalet iterationer i varje fas är beroende av projektets storlek och behov. Peter Lorenz 10(47)

11 Figur 3.3: Faser och iterationer i RUP (Källa: IBM Rational, 2004) Varför iterativt? Alla projekt innehåller alltid ett visst antal risker. Det kan vara risker som direkt påverkar utvecklingen, som t.ex. brist på hårdvara eller otillräckliga utvecklingsverktyg men även affärsrisker som att konkurrenter hinner före. Desto tidigare i projektets livscykel en risk identifieras ju tidigare kan den elimineras. Om man inte driver utvecklingen iterativt, utan tillämpar vattenfallsmodellen, kan det vara mycket svårt att tidigt identifiera risker (Wilson- Welsh, 2003). Dessa brukar då inte uppenbara sig förrän man närmar sig slutet på livscykeln, se figur 3.4. Förutom riskidentifiering kan man även hantera de kravändringar som kommer in under projektets gång på ett effektivare sätt om man utvecklar iterativt. Figur 3.4: Vattenfallsmodellen och RUP Peter Lorenz 11(47)

12 Kravhantering Kravhantering är att samla in, dokumentera, organisera, prioritera och följa upp de krav som ställs på ett system. I tabell 3.2 isas ett antal olika kravtyper. Funktionalitet Användarvänlighet Stabilitet Prestanda Drift/Vidareutv. Resultatet av kravhanteringen i RUP är användningsfallsmodellen. Denna fungerar sedan som indata till Analys och Design, Implementation och Test. Tabell 3.2: Kravtyper Arkitekturcentrerad utveckling En byggfirma skulle aldrig komma på tanken att börja bygga ett hus utan att först ha tillgång till en ritning. Det har dock inte varit lika självklart vid mjukvaruutveckling. I RUP tillämpas därför det som kallas arkitekturcentrerad utveckling dvs. en ritning av hur systemet ska byggas upp och olika komponenters samverkan. För att beskriva ett systems arkitektur används 4+1 -vymodellen. Fem olika vyer beskriver designen av systemet sett från fem olika perspektiv, se figur 3.5. Logisk vy Implementationsvy Användningsfallsvy Processvy Driftsättningsvy Figur 3.5: 4+1 -vy över arkitektur De olika vyerna är: Användningsfallsvyn Så uppfattas systemet utifrån av dess användare. Logisk vy Implementationsoberoende beskrivning av systemets delar, beteende och samverkan. Implementationsvy Visar hur källkoden är organiserad och hur den logiska vyn skall implementeras. Processvy Systemet beskrivs som ett antal samverkande exekverbara delar. Används mest för större sammanhängande system. Driftsättningsvy Fysisk arkitektur för driftsättning av systemet. Peter Lorenz 12(47)

13 Visuell modellering Vid visuell modellering beskrivs systemets uppbyggnad med hjälp av standardiserade grafiska element. Modellen blir helt implementationsoberoende och verktyg finns för att utifrån modellen generera färdig källkod. I RUP kopplas den visuella modelleringen till UML (Unified Modelling Language). Upprepad kvalitetsverifiering Kvalitet är inget som kommer gratis bara för att man bygger ett datorprogram. Alla som är delaktiga i projektet är också ansvariga för produktens kvalitet. Det går inte att i efterhand omvandla ett system med låg kvalitet genom test-och-felrättning. Kvalitetskontroll måste föras aktivt genom hela livscykeln. Detta sker genom kontinuerliga granskningar och uppföljningar. Vid kravanalys kontrolleras kravens konsekvens och dess detaljrikedom, både inom projektet och för kommunikation med kunden. Vid analys och design kontrolleras om designmodellen överensstämmer med ursprungliga krav. I samband med implementation utförs tester för att garantera att implementerad kod överensstämmer med designmodellerna. Kvalitetsverifiering är alltså en aktivitet som hela tiden pågår parallellt med projektet. Konfigurations- och ändringshantering I ett projekt som bedrivs iterativt kommer flera versioner av dokument och programprototyper att tas fram. Ett konfigurations- och ändringssystem har till uppgift att hålla ordning på allt som projektet genererar. Detta inkluderar bl a versionshantering av källkod, konfigurationskontroll (vilka delar systemet utgörs av och hur de hänger ihop) samt ändringskontroll (hur hanteras ändringsbegäran och hur följs de upp). Ovanstående aktiviteter kan sägas vara giltiga för alla projekt, oavsett man tillämpar RUP eller inte. Nedan beskrivs ett antal aktiviteter som är mer specifika för RUP. Användningsfallsdriven utveckling Användningsfall utgör kärnan i RUP och kan ses som det nav omkring vilket övriga aktiviteter cirklar. Ett användningsfall beskriver ett händelseförlopp i systemet utifrån en aktörs synvinkel. En aktör kan vara en individ eller apparat som integrerar med systemet. Då man beskriver förloppet utgår man från handling och konsekvensregeln. Exempel på ett användningsfallsscenario för ett uttag från en bankomat skulle då se ut som följer: 1. Aktören (bankkunden) stoppar in kortet i automaten (handling) 2. Systemet svarar med att fråga efter kod (konsekvens) 3. Aktören anger pin-kod (handling) 4. Systemet verifierar kod mot databas och frågar efter belopp för uttag (konsekvens) 5. Aktören anger belopp(handling) 6. osv.. Användningsfallet ovan beskriver vad som kallas för ett huvudflöde. Utöver detta kan användningsfallet ha ett antal alternativflöden. Exempel på detta kan vara vad som sker om pin-koden i exemplet ovan inte godkänns. Alla användningsfall beskrivs också med ett diagram som tillsammans med närliggande fall bygger upp en användningsfallsmodell liknande den i figur 3.6. Peter Lorenz 13(47)

14 Figur 3.6: Exempel på användningsfallsdiagram Roller I RUP ingår även att definiera roller, dvs vem som gör något. Rollbegreppet beskriver vilken slags person som behövs för olika uppgifter inom en disciplin av RUP. En roll behöver inte betyda en person, utan kan mycket väl fyllas av flera individer. En person kan även ha flera olika roller. Meteorits RUP-konfiguration Figur 3.7 visar den konfiguration som Meteorit tillämpar och även PMMs roll i RUP. Peter Lorenz 14(47)

15 Figur 3.7: Meteorits RUP-konfiguration (Källa: Victorin, 2003) Peter Lorenz 15(47)

16 Kompetensia Kravhantering Tre iterationer är ett minimum vid kravhantering för att ta fram användningsfallsmodellen. Arbetet kan se ut som följer: 1. Identifiera och beskriv aktörer 2. Identifiera och beskriv användningsfall 3. Prioritera. Vilka är mer eller mindre viktiga? 4. Skriv en outline för samtliga användningsfall, dvs en översiktlig beskrivning av huvudflödet. 5. Prioritera bland användningsfallen. 6. Detaljera användningsfallen, identifiera alternativflöden 7. Prioritera bland användningsfallen. (Källa: Victorin, 2003) I samråd med styrgrupp godkänner projektledaren kraven innan arbetet med design och arkitektur påbörjas. Även designmodell och testplan skall godkännas innan implementation. Peter Lorenz 16(47)

17 Kompetensia 3.3 Microsoft.NET År 2000 lanserades Microsoft.NET. Det uttalas dotnet och har på svenska översatts till plattformen.net (Pagina Förlags AB, 2004). Huvudmålet med.net är att underlätta mjukvaruutveckling där fokus ligger på utbyte av information via Internet. Genom så kallade Web Services kopplas olika typer av system samman, vilket kan ge användaren möjlighet att ta del av sina data och program oavsett plats och plattform, se figur 3.8. Figur 3.8: Kommunikation via XML Web Services Tidigare har program som utvecklats för Windowsmiljö använt sig av anrop till Win32- biblioteken bestående av hundratals Windowsspecifika funktioner. Dessa bibliotek har i sin tur hanterat kommunikationen med Windows och hårdvaran. Källkoden har kompilerats direkt till maskinkod och ett körbart program. Detta har bidragit till följande problem: Plattformsberoende Ett program som är utvecklat i exempelvis Visual Basic kan bara köras i Microsoft Windows. Det finns inga garantier att samma exekverbara program, utvecklat i olika programmeringsspråk, genererar liknande maskinkod vilket gör det omöjligt att dela funktioner och bibliotek mellan olika språk. Win32 API är inget annat än en uppsjö av funktioner. Dessa funktioner innehåller ofta mycket kryptiska förklaringar och anropsparametrar vilket gör det svårt för en utvecklare. På Microsoft har man väl känt till dessa brister och har därför i plattformen.net vidtagit åtgärder för att eliminera dessa. Peter Lorenz 17(47)

18 Kompetensia De två första problemen har man löst på det sätt som illustreras i figur 3.9. Källkoden översätts först till vad som kallas Microsoft Intermediate Language (MSIL). Denna IL-kod körs sedan i exekveringsmotorn, Common Language Runtime (CLR). CLR hanterar översättningen till maskinspecifika instruktioner och kontrollerar även minnet, undantagshantering och skräpsamling. Figur 3.9: Virtuell exekveringsmotor kör programmets kod Problemet med det svårhanterliga Win32 API har man löst genom att införa det som kallas för klassramverket. Det är en stor samling klasser som innehåller all funktionalitet som en utvecklare kan tänkas behöva. Till skillnad från Win32 API är klasserna välorganiserade i så kallade namnutrymmen (eng. namespace). Till exempel innehåller namnutrymmet System klasser för att hantera de primitiva datatyperna: System.Int32, System.Array, System.String osv. (MSDN, 2004) 3.4 ASP.NET ASP.NET är en ny teknik för att kunna ta del av de ovan nämnda fördelarna även vid webbutveckling. Detta betyder att ASP.NET-sidor utvecklas i något av de programmeringsspråk som stöds av plattformen.net. Då en klient begär en webbsida kontrollerar webbservern om aktuell IL-kod finns tillgänglig och i så fall genereras HTML som skickas till klienten. Om IL-kod saknas eller om ASP.NET-sidans kod uppdaterats, kompileras sidan om på nytt. Den nya IL-koden sparas sedan på disk så att framtida kompileringar ej behövs. En annan nyhet i ASP.NET är code-behind vilket gör det möjligt att separera logik från presentation och lägga all kod i separata klassfiler. Peter Lorenz 18(47)

19 Kompetensia Kontroller I ASP.NET finns ett antal olika kontroller till hjälp när man bygger användargränssnitt. De anges i koden på följande sätt, vilket betyder att de kommer att hanteras av servern: <asp:tagname runat= server > Förutom HTML Controls, som består av vanliga HTML-kontroller, finns följande att tillgå: Server Controls Färdigpaketerad programkod för att utföra dynamiska funktioner. Detta kan vara till exempel <asp:button>, som representerar en knapp och dess funktionalitet eller <asp:label>, vilket ger en etikett. Validation Controls Används för att enkelt kunna validera en användares inmatade data i exempelvis fält. List Controls Tillhandahåller paketerad kod för att enkelt hantera listor från exempelvis en databas. Rich Control Avancerade komponenter som exempelvis kalender. User Control Kontroll som användaren själv kan skapa. Filändelsen blir.ascx och kontrollen kan sedan inkluderas i ASP.NET-sidorna. Det är lämpligt att skapa en användarkontroll om det är någon funktion som kommer att användas på flera sidor, som exempelvis en dropdown-lista över kompetensområden. 3.5 ADO.NET ADO.NET är en samling klasser för dataåtkomst som ingår i klassramverket. Det är möjligt att ansluta till Microsoft SQL Server men även andra databaser och XML-datakällor. Två nyheter i ADO.NET är DataSet och DataReader. Dessa förklaras närmare i nästa avsnitt. Många utvecklare misstar sig och tror att DataSet är bättre än DataReader eller tvärtom. Båda teknikerna har sina för- och nackdelar (Goodyear, 2004) och användningsområdet bör avgöra vilken teknik man väljer DataSet DataSet utgör kärnan i ADO.NETs så kallade frånkopplade arkitektur. Detta innebär att information hämtas från datakällan, lagras i minnet i form av ett DataSet och databaskopplingen stängs. När man är klar med databehandlingen överförs alla ändringar till databasen igen. Peter Lorenz 19(47)

20 Kompetensia Exempel på när ett DataSet är bra att använda: Vid avancerade beräkningar på resultaten från en databasfråga innan dessa skrivs ut på skärmen. Då man behöver kunna navigera fritt, filtrera, sortera och söka bland informationen som returnerats. Då samma information skall användas på flera olika ställen eller senare i programmet. Då informationen som hämtas ligger till grund för nya databasanrop. Om datakällan är ett XML-dokument istället för en databas. DataSet klarar av att läsa in XML-dokument direkt och kan även skriva till fil DataReader DataReader läser en rad i taget till minnet från databasen och kräver därför att databaskopplingen hålls öppen. DataReader kan bara navigera framåt en rad i taget. DataReader är bra att använda: Om det finns behov av att informationen som visas alltid är aktuell och därför måste hämtas från databasen varje gång den skall bearbetas. Om man bara behöver läsa informationen en gång, rad för rad, som till exempel vid databindning av Webbkontroller som listboxar, datagrid m.m. Då en liten mängd data skall hämtas från databasen ett upprepat antal gånger. 3.6 Användarautentisering i ASP.NET För att uppfylla kravet på single sign-on, se Avsnitt 3.1, måste användaren som besöker sidan identifieras av ASP.NET-applikationen. Denna information kan sedan användas för uppslag i företagets Active Directory för att hämta fler uppgifter, såsom till exempel namn och adress men även för att kontrollera användarens åtkomstgrad till applikationen utifrån grupptillhörighet i AD. Det finns tre olika säkerhetsinställningar som ligger till grund för vilken användare som ASP.NET-applikationen kommer att exekveras under (Brown, 2002). I det här kapitlet beskrivs dessa genom att följa ett inkommande anrop från en klient. I figur 3.10 visas den väg genom vilken en förfråga färdas innan ASP.NET-applikationen startar. Peter Lorenz 20(47)

21 Kompetensia Figur 3.10: ASP.NET-förfrågan [1] Inkommande förfrågan anländer till webbservern och slussas via operativsystemet vidare till INETINFO.EXE som är den process i Microsoft Internet Information Services (IIS) som hanterar webbservertjänster. Notera att denna process körs under användaren SYSTEM, den användare med flest rättigheter i operativsystemet. [2] Tråden inne i processen INETINFO som hanterar förfrågan kommer alltid att personifiera ett annat användarkonto, beroende på de aktuella autentiseringsinställningar i IIS som visas i figur Figur 3.11: Autentiseringsmetoder i IIS Peter Lorenz 21(47)

22 Kompetensia Om anonym åtkomst är påslagen kommer tråden att köras som användaren IUSR_MACHINE om inga andra inställningar gjorts. Integrerad Windows Autentisering lämpar sig mycket bra som autentiseringsmetod för intranät där användare och webbservrar ingår i samma domän. Uppgifter om den aktuella Windowsanvändaren på anropande klient används för åtkomstkontroll på servern. Om detta misslyckas kommer webbläsaren att be användaren om användarnamn och lösenord. Utbyte av uppgifter sker krypterat mellan klient och server. Integrerad Windows Autentisering används i kompetenssystemet för att uppfylla kravet på single sign-on-funktionalitet. [3] Om förfrågan gäller en ASP.NET-sida, vidarebefordras denna till aspnet_isapi.dll. Denna DLL fungerar som en brygga till den separata processen ASPNET_WP (arbetarprocessen). [4] Arbetarprocessen körs inte som SYSTEM utan under ett lokalt användarkonto som heter ASPNET. Detta konto installeras automatiskt vid installation av.net-ramverket. Till skillnad från SYSTEM-kontot har denna användare mycket få rättigheter till systemet. [5] Tråden som hanterar förfrågan i arbetarprocessen personifierar i sin tur en användare eller ej utifrån de inställningar som finns i filen web.config, som följer med webbapplikationen. <identity impersonate= true false /> Om identity impersonate sätts till true kommer användaren som identifierades av tråden i INETINFO att ärvas till aktuell tråd i ASPNET_WP, annars kommer denna att köras under samma användare som processen, dvs. ASPNET. [6] Här slussas förfrågan genom en serie moduler som kan liknas vid en uppsättning filter. Var och en av dessa moduler måste implementera gränssnittet IHttpModule. I tabell 3.12 visas de klasser som redan finns tillgängliga i.net-ramverket. Eftersom dessa filter hanterar förfrågningar innan de når en applikation, kan de till exempel omdirigera anonyma användare till en loginsida (vid formulärautentisering) eller neka användare åtkomst till applikationen. En genomgång av samtliga dessa ligger utanför denna framställning och lämnas därför därhän. Class DefaultAuthenticationModule FileAuthorizationModule FormsAuthenticationModule PassportAuthenticationModule SessionStateModule UrlAuthorizationModule Description Insures that an Authentication object is present in the context. This class cannot be inherited. Verifies that the remote user has NT permissions to access the file requested. This class cannot be inherited. Enables ASP.NET applications to use forms authentication. This class cannot be inherited. Provides a wrapper around PassportAuthentication services. This class cannot be inherited. Provides session-state services for an application. Provides URL-based authorization services for allowing or denying access to specified resources. This class cannot be inherited. Tabell 3.12: Klasser som implementerar IHttpModule. (Källa: MSDN Class Library, 2004) Peter Lorenz 22(47)

23 Kompetensia Vilken modul som kommer att användas baseras även det på inställningar i web.config: <authentication mode= None Windows Forms Passport / > Eftersom kompetenssystemet använder sig av Windowsautentisering kommer modulen WindowsAuthenticationModule att användas. Dess uppgift är att hantera den autentiseringsinformation som IIS skickar med förfrågan. Detta sker genom att ett WindowsPrincipalobjekt skapas som i sin tur innehåller ett WindowsIdentity-objekt via egenskapen Identity. Dessa två klasser implementerar gränssnitten IPrincipal respektive IIdentity. WindowsPrincipal-objektet kommer man sedan åt via egenskapen HttpContext.User. Aktuell användare hämtas från HttpContext.Current.User.Identity.Name. [7] Slutligen når förfrågan sin slutdestination, en så kallad HttpHandler. En aspx-sida ärver från System.Web.UI.Page som implementerar IHttpHandler-gränssnittet, så en vanlig aspxsida är en typ av HttpHandler. 3.7 Sessionsobjektet För att hålla reda på en användare över flera sidor i applikationen används i ASP.NET ett så kallat sessionsobjekt. Varje gång en ny användare besöker sidan instansieras ett objekt som är specifikt bundet till användarens webbläsare. Objektet är sedan åtkomligt från applikationens alla sidor. I kompetenssystemet används detta för att spara aktuellt användarid och om användaren är administratör eller ej. Information läggs in på följande sätt: Session["isAdmin"] = true; Och hämtas på motsvarande sätt: int usrid = (int) Session["UserID"]; 3.8 Hogia På Meteorit finns ett antal resultatenheter, exempelvis konsultgrupp 1, drift och stab. Samtliga anställda är medlemmar i någon av dessa enheter och information om detta återfinns i en SQL-databas som är kopplad till affärssystemet Hogia. Ett krav på Kompetensia är att kunna visa statistik fördelad per resultatenhet. Meteorit tillhandahåller en lagrad procedur för att hämta nödvändig information från Hogiadatabasen. 3.9 Kompetensutveckling Kompetens är varje människas teoretiska och praktiska kunskaper, arbetslivserfarenheter, sociala färdigheter, samt viljan och förmågan att omsätta dessa i handling Källa: Att utveckla kompetens är något som tar tid. Det är en process där ansvaret ligger på samtliga inblandade i företaget. Utan ordentliga verktyg är det svårt att styra utvecklingen och aktivt utvärdera dess resultat. Peter Lorenz 23(47)

24 Kompetensia En kompetensutvecklingsprocess bör bestå av fyra återkommande moment som visas i figur 3.13 (Advantum, 2004). Figur 3.13: Kompetensutvecklingens fyra faser Kompetensanalys Korta och långsiktiga mål identifieras och ställs upp. Kompetensinventering Nuvarande och önskad kompetens kartläggs och dokumenteras. Detta kan ske löpande och vid 2-3 större inventeringar per år i samband med utvecklingssamtal eller dylikt. Kompetensförsörjning Individerna tilldelas rätt medel för att kunna uppnå mål och kompetensnivåer satta i de två första stegen. Detta kan vara kurser, kvalitetsgrupper, diskussioner, mässbesök eller att en ny person anställs för att fylla ett visst kompetensbehov. Utvärdering Här analyseras kompetensläget för att se om målen uppnåtts och kompetensen ökat inom önskade områden. Resultaten från utvärderingen blir indata till en ny kompetensanalys. Peter Lorenz 24(47)

25 Kompetensia 4 Resultat Detta avsnitt beskriver det färdiga kompetenssystemet utifrån användarperspektiv samt systemdesign och databaskonstruktion. 4.1 Användargränssnitt En översikt av användargränssnittet visas i figur 4.1. Applikationens indexsida innehåller två ramar. Vid start laddas menyn i den vänstra ramen och blir på så sätt alltid synlig. I den högra ramen laddas startsidan. Menyval visas därefter alltid i den högra ramen. Figur 4.1: Startsida - Kompetensia Genomgången av sidorna i detta avsnitt följer den ordning en ny användare rekommenderas följa. Personlig info Här anges namn, telefon och övriga personliga uppgifter tillsammans med bakgrund, tjänster och utbildning. Det finns även möjlighet att ladda upp en bild. Kompetensaktiviteter Användaren skall här lägga in sin projekthistorik, dvs. uppgifter om tidigare projekt och de arbetsuppgifter som dessa inkluderat. Även aktiviteter som till exempel avslutade kurser eller litteraturstudier kan läggas in, se figur 4.2 och figur 4.3. Peter Lorenz 25(47)

26 Kompetensia Figur 4.2: Kompetensaktiviteter Figur 4.3: Lägg till ny aktivitet Peter Lorenz 26(47)

27 Kompetensia Certifiering Användaren lägger in de certifieringar som han/hon har tagit. Kompetensinventering Här skall användaren inventera sin kompetens. Detta sker genom att ange nuvarande- och önskad nivå inom ett kompetensområde, se figur 4.4. För att styrka angivna nivåer ges möjlighet att referera varje kompetensinställning till tidigare inlagda kompetensaktiviteter och certifieringar. Genom att klicka på Lägg till referens visas fönstret i figur 4.6. Figur 4.4: Kompetensinventering Längst ner på sidan visas de kompetenser man tidigare inventerat med möjlighet att ta bort eller uppdatera dessa, se figur 4.5. Figur 4.5: Kompetenslista vid kompetensinventering Peter Lorenz 27(47)

28 Kompetensia Figur 4.6: Lägg till referens Figur 4.7: Kompetensmål Peter Lorenz 28(47)

29 Kompetensia Kompetensmål Här skall individuella kompetensmål ställas upp utifrån egna önskemål och de krav som finns samlade i företagets gemensamma målpool, se nedan. Användaren anger då målet är uppnått och detta markeras i översikten med en stjärna, se figur 4.7. Målpool Mål identifieras av företagsledningen och läggs ut i målpoolen. Härifrån kan de anställda sedan flytta mål till sina personliga kompetensmål. Kompetensgrupper Här listas de kompetensgrupper och dess medlemmar som finns på företaget. Möjlighet finns att gå med och gå ur kompetensgrupp. Min Profil All information som användaren angett i systemet, förutom kompetensmål, sammanställs under Min Profil. Denna kommer sedan att fungera som konsultprofil och möjlighet finns att skriva ut profilen och att spara denna som ett Worddokument, se figur 4.8. Bild Bild Bild Figur 4.8: Min Profil Längst ner på sidan Min Profil visas användarens kompetenslista. Det är en översikt av de kompetenser som användaren har angett vid sin kompetensinventering, se figur 4.9. Peter Lorenz 29(47)

30 Kompetensia Figur 4.9: Kompetenslista Genom att klicka på en kompetens i listan visas information om dess referenser och nivåhistorik, se figur Figur 4.10: Information om kompetensen MS SQL Server Admin Peter Lorenz 30(47)

31 Kompetensia Sök kompetens Följande sökfunktioner finns i Kompetensia, se figur 4.11: Visa profil Gå direkt till en anställds profil Fritextsökning Ange valfria kommaseparerade söktermer och systemet visar de personer som matchar sökningen och deras kompetensnivåer inom området. Kompetensaktiviteter Listar systemets alla inlagda kompetensaktiviteter. Certifieringar Listar systemets alla inlagda certifieringar. Projektsökning Möjlighet att markera flera av de kompetenser som finns inlagda i systemet och visa personer som bäst passar in på sökningen samt matchningsgrad. Möjlighet att filtrera sökresultat med en lägsta nivå på returnerade resultat. Figur 4.11: Sök kompetens Peter Lorenz 31(47)

32 Kompetensia För åtkomst till följande sidor krävs administratörsrättigheter. Utvecklingshistorik Ger möjlighet att analysera kompetensutvecklingen över tiden, dvs ändring i summan av nuvarande- och önskade nivåer. Resultat kan visas för en eller flera resultatenheter samt en kompetenskategori eller specifik kompetens, se figur 4.12 och figur Förutom nivåhistorik returneras även antalet anställda enligt sökkriterierna, se figur Figur 4.12: Sökkriterier för utvecklingshistorik Figur 4.13: Utvecklingshistorik Branschkunskap 2002 Peter Lorenz 32(47)

33 Kompetensia Figur 4.14: Antalet anställda som matchar sökningen Kompetenscirkel Visar hur kompetensen är fördelad procentuellt ett angivet år och grupperat efter valbar resultatenhet, se figur Figur 4.15: Kompetenscirkel Peter Lorenz 33(47)

34 Kompetensia Administrera målpool Här läggs nya mål in i företagets målpool. Här visas också vilka anställda som överfört ett visst mål till sina personliga kompetensmål. Systemadministration Möjlighet att administrera systemet, dvs ta bort användare, lägga till kompetenser och kategorier, kompetensgrupper, kompetensaktivitetstyper, administrera hjälpavsnitt och övrigt som har med systemets funktionalitet att göra. En översikt av ASP.NET-sidorna och användarkontrollernas struktur visas i figur Peter Lorenz 34(47)

35 Kompetensia Figur 4.16: Applikationens användargränssnitt Peter Lorenz 35(47)

36 4.2 Systemdesign Utvecklings- och målmiljöer Utvecklingsmiljö Följande utrustning och mjukvara har använts vid utveckling av Kompetensia: Server med Microsoft SQL Server 2000 Internet Information Server 5.0 med.net-ramverket installerat som webbserver En klientdator med Windows XP som operativsystem. Microsoft Visual Studio.NET som utvecklingsverktyg. Microsoft Word 2003 som ordbehandlare Microsoft Internet Explorer 6.0 som webbläsare Visual Paradigm för att generera UML-diagram från kod Rational Rose för design av systemet Målmiljö Följande hård- och mjukvara utgör systemets målmiljö: Server med Microsoft Server 2003 Internet Information Server 5 med.net-ramverket installerat. Systemet är uppbyggt som en treskiktsarkitektur där grundpelarna i systemet utgörs av de åtta klasser som illustreras i figur Deras uppgift är att dölja programmets logik för aspxsidorna samt erbjuda omvärlden ett väldefinierat gränssnitt. Valet av denna design gör det enkelt att integrera dessa komponenter i andra system. Kompetens (CCompetence) Kompetensmål Kompetensaktiviteter Certifiering (CTarget) (CMilestone) ( CCertificate) Användare (CUser) Kompetensgrupper (CCompGroup) Sökning (CSearch) Analys (CAnalysis) Figur 4.17: De åtta klasserna utgör logiklagret, systemets grundpelare Varje klass tillhandahåller metoder och egenskaper för den funktionalitet som klassen representerar. Kommunikation mellan logiklagret och andra system, såsom Active Directory och Hogiadatabasen, sker via tre databasklasser som visas i figur Peter Lorenz 36(47)

37 Figur 4.18: Kommunikation mellan logik och datakällor För att till exempel komma åt metoder i klassen CUser från en code-behind sida (se avsnitt 3.4) instansieras ett objekt av klassen på följande sätt: CUser usr = new CUser(); Logik Här följer en genomgång av de åtta grundklasserna med exempel på funktionalitet. Kompetensklassen (CCompetence) Tillhandahåller metoder för kompetensspecifika uppgifter såsom: Hantera systemets inlagda kompetenser och dess kategorier. Metoder för kompetensinventering, dvs. hantera en anställds kompetenser och kompetensnivåer. Historik över ändringar i kompetensnivåer. Hantera den anställdes kompetenslista. Kompetensmål (CTarget) Här finns samtliga metoder samlade för att hantera en anställds personliga mål samt mål i målpoolen. Bland annat: Visa, lägg till, ta bort och uppdatera mål. Flytta mål från målpoolen. Markera mål som uppnåtts. Hämta mål där deadline passerats. Peter Lorenz 37(47)

38 Kompetensaktiviteter (CMilestone) Hanterar all funktionalitet för kompetensaktiviteter. Här finns metoder för att: Visa, lägga till, ta bort och uppdatera aktiviteter. Hantera aktivitetstyper. (Standardtyper: Projekt, Litteratur, Kurs och Övrigt) Certifiering (CCertificate) Här finns metoder för att hantera en anställds certifieringar. Visa, lägga till, ta bort och uppdatera certifieringar. Hämta titel och företagsnamn på samtliga certifieringar i databasen. Användare (CUser) Tillhandahåller metoder för att hantera användare. Detta inkluderar: Visa, lägg till, uppdatera, ta bort en användare. Hantera inloggning av en användare. Hämta alla användare. Uppdatera senaste logindatum. Kompetensgrupper (CCompGroup) Hanterar kompetensgrupper såsom: Visa kompetensgrupp och dess medlemmar. Lägg till och ta bort medlemmar från en grupp. Sökning (CSearch) Här finns alla de metoder som behövs för att kunna söka i systemet såsom: Kommaseparerad fritextsökning på kompetensnamn. Namn och nivåer returneras på de som matchar sökningen. Projektspecifik sökning. Ett antal av systemets inlagda kompetenser kryssas i och resultatet visar de personer som bäst matchar sökningen med matchningsgrad i procent. Analys (CAnalysis) Innehåller metoder som behövs för kompetensanalys, dvs. utvecklingshistorik och kompetenscirkel såsom: Summa önskad- och nuvarande nivå per kategori och specificerad kompetens Summa önskad- och nuvarande nivå per angiven resultatenhet Summa kompetensnivå för ett givet år Summa kompetensnivå för en viss kategori samt kompetens ett givet år Databaskonstruktion Arbetet med databasmodellen i figur 4.19 har pågått parallellt med logikdesignen och reviderats under projektets gång. Alla SQL-frågor hanteras av lagrade procedurer i databasen. Peter Lorenz 38(47)

39 Figur 4.19: Databasmodellen Peter Lorenz 39(47)

40 4.2.4 Inloggning och autentisering av användare Ett viktigt krav på systemet är det som kallas single sign-on, se avsnitt 3.1. Detta betyder att användaren av systemet inte skall behöva gå igenom mer än ett inloggningsförfarande. Autentisering av användaren påbörjas i filen Start.aspx. De olika momenten visas i figur Användarens windowsinloggningsid hämtas från User.Identity.Name (se avsnitt 3.6). Hos Meteorit består detta ID av första bokstaven i förnamnet följt av de två första i efternamnet. Från Active Directory hämtas med hjälp av detta ID personens fullständiga namn samt information om personen tillhör administrationsgruppen eller ej. Om användaren inte finns i AD avslutas körningen med ett felmeddelande. Namnet används sedan för uppslag i Kompetensiadatabasen där det kontrolleras om användaren har ett konto eller ej. Finns inget konto skapas ett nytt och applikationen startar. HttpContext.Current.User.Identity.Name Active Directory Finns i AD Finns ej i AD Kompetensia Databas Finns i Kompetensias databas Finns ej i Kompetensias databas Kompetensia Start Lägg till ny användare Figur 4.20: Inloggningsförfarande Peter Lorenz 40(47)

41 5 Jämförelse av RUP, Extreme Programming och TPFD Avsnittet ger en översikt av två andra utvecklingsmetoder som hade kunnat tillämpats under projektets gång istället för RUP. Till grund för jämförelsen av metoderna i kapitlets sammanfattning ligger de erfarenheter av RUP som examensarbetet givit, tillsammans med litteraturstudier om TPFD-metoden (TestPlan Före Design) och XP (Extreme Programming). 5.1 XP XP är uppbyggt av ett antal regler. Jämfört med RUP, där man kan konfigurera och använda de delar man har behov av, måste man i XP tillämpa samtliga regler för att metoden skall fungera. Varje regel utgör en kedjelänk, se figur 5.1. Tas en länk bort havererar hela idén med XP. Figur 5.1: XP-kedjans regler Regel 1 User stories Projektet drar igång utan att specificera några detaljerade krav på produkten, förutom några kortfattade så kallade user stories, författade på enkla berättarkort. De är skrivna av kunden och beskriver vad systemet skall göra. Det som skiljer dessa från RUPs användningsfall och TPFDs användarkrav är detaljrikedommen. I XP är denna endast tillräcklig för att grovt bestämma implementationstiden. När det är dags att implementera en user story träffas utvecklarna och kunden för en muntlig detaljerad beskrivning av funktionerna. Regel 2 Konstant omstrukturering Eftersom det inte finns någon detaljspecifikation av kraven, finns inte heller möjlighet att ta fram någon design- och systemspecifikation innan implementation påbörjas. Det betyder att systemdesignen kommer att ändras flera gånger under projektets gång. Detta tillåts dock och anses säkert så länge koden ständigt omstruktureras. Även i RUP och TPFD är omstrukturering ett välkommet inslag men då endast för att kontrollera och förbättra en redan framtagen design och inte alls lika omfattande som i XP. Regel 3 Automatiserade enhets- och integrationstester Det är känt att omstrukturering av kod kan medföra att fler fel byggs in i koden, då viktiga data kanske flyttas eller tas bort. Detta förebyggs i XP av ständiga och utförliga enhetstester. Dock kommer dessa tester enbart att avslöja fel i koden och inte fel man infört som påverkar Peter Lorenz 41(47)

42 systemets övergripande design. Kom ihåg att någon designspecifikation inte finns att tillgå, därför förespråkar XP att integrationstester utföras dagligen. Regel 4 Parprogrammering För att ytterligare förhindra fel i systemdesignen tillämpas i XP parprogrammering. Den som för tillfället inte programmerar kan då kontrollera så att de omstruktureringar som görs inte påverkar integrationen med systemets övriga delar. Regel 5 Användare Eftersom det inte finns någon utförlig dokumenterad specifikation av projektet används en riktig användare som programmerarnas bollplank. Denne kundrepresentant får fungera som detaljkrav under hela projektets gång och därför behövs inga detaljerade och dokumenterade krav. I den ursprungliga handledningen (Beck, 1999) hävdar Kent Beck, en av XPs tre grundare, att en kundrepresentant skall finnas tillgänglig för utvecklingsteamet 40 timmar i veckan. Det bästa är att helt enkelt knyta henne/honom till projektgruppen. Kritikerna hävdar att det är alltför kostsamt för kunden att avvara en anställd till projektet så länge detta pågår. Beck menar att det är ett val som måste göras. Om det är för dyrt att avvara en anställd för att bidra till utvecklingen av ett väl fungerande system, då kanske systemet inte ska införskaffas alls (Beck, 1999). Sedan 1999 har denna kundroll förändrats och idag är det inte längre en person utan snarare ett team av kundrepresentanter som håller ständig kontakt med utvecklingsteamet, utan att för den skull behöva sitta i samma rum som programmerarna. 5.2 TPFD TPFD är en utvecklingsmetod som lärs ut i kursen Programvaruutveckling och Projekthantering vid Örebro Universitet, Institutionen för Teknik. Den är framtagen av Håkan Lindegren och är lämplig att användas till små- eller delar av ett större projekt. TPFD står för TestPlan Före Design och tanken är att lära sig så mycket som möjligt om det system som skall byggas innan implementationsfasen påbörjas, dvs raka motsatsen till vad XP förespråkar. TPFD är en inkrementell metod där ett inkrement består av fyra delprocesser, se figur 5.2. Egentligen är det en omskrivning av vattenfallsmodellen, som beskrevs i avsnitt Lindegren (2003, s. 369) hävdar att modellen fungerar; bara inkrementen hålls korta. Rekommenderad maxlängd på ett inkrement är 26 veckor. Figur 5.2: RGKU-modellen Peter Lorenz 42(47)

43 Varje delprocess innehåller ett antal aktiviteter som skall utföras, se figur 5.3. Under R-processen dokumenteras grundligt systemets funktionalitet genom dokumenten användarkrav och detaljkrav. En testplan utvecklas redan i denna process utifrån det som står i detaljkraven och ett konfigurationsdokument tas fram. I G-processen utvecklas en designspecifikation som skall ligga till grund för systemets implementation. Indata blir detaljkrav och testplan och vid processens slut skall en färdig produkt finnas för test- och felrättning. Dokument med en sammanställning av återstående problem samt ändringslogg skall också vara ett resultat av G-processen. I ändringsloggen läggs de förslag till ändringar som kommer in efter det att ett dokument stängts, dvs. godkänts av granskaren. Figur 5.3: Aktiviteter i TPFD-metoden K-processen syftar till att uppdatera dokument och verifiera produkten. Test- och felrättning påbörjas och resultatet från processen skall vara en väl fungerande produkt och en ordnad dokumentation. U-processen tillhandahåller aktiviteter för att hantera utgåvor, dvs. paketera produkt och utvecklingsmiljö. I denna process spelar konfigurationsdokumentet en betydande roll. Peter Lorenz 43(47)