KOMPETENSSYSTEM - Örebro universitet

Examinator: Lars Karlsson 

COMPETENCE SYSTEM 

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 

Örebro universitet Örebro University 

Institutionen för teknik Department of technology 

701 82 Örebro SE-701 82 Örebro, Sweden

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).

Förord 

Till grund för denna rapport ligger det examensarbete som utförts på uppdrag av Meteorit AB 

under våren 2004. 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

Kompetenssystem 

INNEHÅLLSFÖRTECKNING 

1 INLEDNING................................................................................................................................................ 5 

1.1 BAKGRUND........................................................................................................................................... 5 

1.2 SYFTE ................................................................................................................................................... 5 

2 METOD OCH KÄLLOR............................................................................................................................ 6 

2.1 BEFINTLIGT KOMPETENSSYSTEM .......................................................................................................... 6 

2.2 GENERELLA KOMPETENSSYSTEM.......................................................................................................... 6 

2.3 REFERENSGRUPPSMÖTEN...................................................................................................................... 6 

2.4 PPH-KURSEN ....................................................................................................................................... 6 

2.5 LITTERATURSTUDIER............................................................................................................................ 7 

3 PROJEKTBESKRIVNING........................................................................................................................ 8 

3.1 ÖVERGRIPANDE KRAV PÅ UTFORMNING AV SYSTEMET......................................................................... 8 

3.2 METODIK .............................................................................................................................................. 8 

3.2.1 PMM................................................................................................................................................ 8 

3.2.2 Vattenfallsmodellen....................................................................................................................... 10 

3.2.3 RUP............................................................................................................................................... 10 

3.3 MICROSOFT.NET................................................................................................................................17 

3.4 ASP.NET ........................................................................................................................................... 18 

3.5 ADO.NET.......................................................................................................................................... 19 

3.5.1 DataSet.......................................................................................................................................... 19 

3.5.2 DataReader ................................................................................................................................... 20 

3.6 ANVÄNDARAUTENTISERING I ASP.NET............................................................................................. 20 

3.7 SESSIONSOBJEKTET............................................................................................................................. 23 

3.8 HOGIA................................................................................................................................................. 23 

3.9 KOMPETENSUTVECKLING ................................................................................................................... 23 

4 RESULTAT ............................................................................................................................................... 25 

4.1 ANVÄNDARGRÄNSSNITT..................................................................................................................... 25 

4.2 SYSTEMDESIGN................................................................................................................................... 36 

4.2.1 Utvecklings- och målmiljöer ......................................................................................................... 36 

4.2.2 Logik.............................................................................................................................................. 37 

4.2.3 Databaskonstruktion ..................................................................................................................... 38 

4.2.4 Inloggning och autentisering av användare.................................................................................. 40 

5 JÄMFÖRELSE AV RUP, EXTREME PROGRAMMING OCH TPFD ............................................. 41 

5.1 XP ...................................................................................................................................................... 41 

5.2 TPFD.................................................................................................................................................. 42 

5.3 RUP.................................................................................................................................................... 44 

5.4 ARTEFAKTMÄNGD .............................................................................................................................. 44 

5.5 SAMMANFATTNING............................................................................................................................. 44 

6 DISKUSSION ............................................................................................................................................ 46 

7 REFERENSER .......................................................................................................................................... 47 

Peter Lorenz 4(47)


1 Inledning 

1.1 Bakgrund 

Meteorit är ett konsultbolag inom systemutveckling och nätverk som grundades i Örebro 

1997. 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)


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)


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)


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. 

3.2.1 PMM 

Figur 3.1: Faser i PMM 

Peter Lorenz 8(47)


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)


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 

Tabell 3.1: 

Vattenfallsmodellens faser 

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). 

3.2.3 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)


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)


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. 

Tabell 3.2: Kravtyper 

Resultatet av kravhanteringen i RUP är användningsfallsmodellen. 

Denna fungerar sedan som indata till Analys och 

Design, Implementation och Test. 

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. 

De olika vyerna är: 

Logisk vy Implementationsvy 

Användningsfallsvy 

Processvy Driftsättningsvy 

Figur 3.5: ”4+1”-vy över arkitektur 

• 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)


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)


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)


Figur 3.7: Meteorits RUP-konfiguration (Källa: Victorin, 2003) 

Peter Lorenz 15(47)

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)

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 Win32biblioteken 

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)

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)

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: 

 

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 , som representerar en knapp och dess funktionalitet eller 

, 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. 

3.5.1 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)

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. 

3.5.2 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)

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 3.11. 

Figur 3.11: Autentiseringsmetoder i IIS 

Peter Lorenz 21(47)

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. 

 

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 Description 

DefaultAuthenticationModule Insures that an Authentication object is present in the context. 

This class cannot be inherited. 

FileAuthorizationModule Verifies that the remote user has NT permissions to access 

the file requested. This class cannot be inherited. 

FormsAuthenticationModule Enables ASP.NET applications to use forms authentication. 


PassportAuthenticationModule Provides a wrapper around PassportAuthentication services. 


SessionStateModule Provides session-state services for an application. 

UrlAuthorizationModule 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)

Kompetensia 

Vilken modul som kommer att användas baseras även det på inställningar i web.config: 

 

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: www.sif.se 

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)

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)

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)

Kompetensia 

Figur 4.2: Kompetensaktiviteter 

Figur 4.3: Lägg till ny aktivitet 

Peter Lorenz 26(47)

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)

Kompetensia 

Figur 4.6: Lägg till referens 

Figur 4.7: Kompetensmål 

Peter Lorenz 28(47)

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)

Kompetensia 

Figur 4.9: Kompetenslista 

Genom att klicka på en kompetens i listan visas information om dess referenser och 

nivåhistorik, se figur 4.10. 

Figur 4.10: Information om kompetensen MS SQL Server Admin 

Peter Lorenz 30(47)

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)

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 4.13. 

Förutom nivåhistorik returneras även antalet anställda enligt sökkriterierna, se figur 4.14. 

Figur 4.12: Sökkriterier för utvecklingshistorik 

Figur 4.13: Utvecklingshistorik Branschkunskap 2002 

Peter Lorenz 32(47)

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 4.15. 

Figur 4.15: Kompetenscirkel 

Peter Lorenz 33(47)

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 4.16. 

Peter Lorenz 34(47)

Kompetensia 

Figur 4.16: Applikationens användargränssnitt 

Peter Lorenz 35(47)


4.2 Systemdesign 

4.2.1 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 4.17. 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) 

Användare 

(CUser) 

Kompetensmål Kompetensaktiviteter Certifiering 

(CTarget) (CMilestone) ( CCertificate) 

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 4.18. 

Peter Lorenz 36(47)


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(); 

4.2.2 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)


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 

4.2.3 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)


Figur 4.19: Databasmodellen 

Peter Lorenz 39(47)


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 4.20. 

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. 

Finns i Kompetensias 

databas 

Kompetensia 

Start 

HttpContext.Current.User.Identity.Name 

Active 

Directory 

Finns i AD Finns ej i AD 

Kompetensia 

Databas 

Finns ej i Kompetensias databas 

Lägg till ny användare 

Figur 4.20: Inloggningsförfarande 

Peter Lorenz 40(47)


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)


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 3.2.2. 

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)


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)


5.3 RUP 

Se Avsnitt 3.2.3 

5.4 Artefaktmängd 

Meningen med tabell 5.1 är att belysa skillnaden i mängden dokument och artefakter. I RUP 

används ordet artefakt eftersom det inte bara rör sig om dokument, utan även modeller av 

olika slag. En del RUP-artefakter har medvetet utelämnats. 

TPFD RUP XP 

Användarkrav Vision 

Stakeholder Requests 

Requirements Management Plan 

Use case 

Use case model 

User stories 

Detaljkrav Detailed use case Referensgrupp 

Designspecifikation Software requirements 

Software Architecture Document 

Design models 

User-Interface Prototype 

Spike 1 

Testplan Testplan 

Test Case 

Test Model 

Workload Analysis Document 

Automatiserat testsystem. 

Test och felrättning Test Evaluation Summary 

Test Results 

Hantera utgåvor Deployment Plan 

Installation Artifacts 

Training Materials 

End-User Support Material 

Konfigurationsdokument Development Infrastructure Mjukvarubaserat 

Configuration Management Plan 

Configuration Audit Findings 

versionshanteringssystem 

Terminologi Glossary 

1 

Spike är en prototyp. För att räta ut frågetecken kring en viss teknisk design, avsätter man en eller två personer 

för att prototypa en lösning som sedan kastas bort. 

Tabell 5.1: Översikt dokument/artefaktmängd 

Beck och Lindegren har bland många insett betydelsen med att ”skala ner” RUP på ett sätt 

som gör metodiken enklare att praktisera. TPFD-metoden skalar emellertid inte ner lika 

radikalt som vad XP gör. 

5.5 Sammanfattning 

Extreme programming har vunnit mycket mark på senare år. Samtidigt som dess popularitet 

ökar, hoppar fler och fler företag på XP-tåget utan att egentligen ha grepp om vad XP innebär. 

Detta har bidragit till att göra XP till den mest missförstådda filosofin bland utvecklingsfolket. 

Peter Lorenz 44(47)


Det som bidrar till att många företag tar till sig XP är att de tror sig kunna spara tid och 

pengar genom att inte behöva faser av kravanalys och systemdesign, utan direkt starta med 

implementation. Att sedan omstrukturera kod är inte heller nödvändigt; det som är skrivet 

fungerar ju! Självklart är inte detta rätt sätt att driva ett XP projekt. 

XP har även fått utstå mycket kritik för att vara för ytlig utan tillräckligt tydliga riktlinjer. Det 

påståendet är felaktigt, då det i XP väl framgår vilka aktiviteter som måste finnas med. Det är 

minst lika enkelt för de anställda vid ett företag att förvirra sig i RUPs alla artefakter. 

XP bygger egentligen också bara på sunt förnuft såsom kommunikation, enkelhet, feedback 

och ett visst mod, saker som borde vara självklara i alla typer av projekt. 

Styrkan hos TPFD är att den egentligen innehåller allt som RUP gör, fast i en skepnad som 

gör det möjligt att direkt tillämpa den på små projekt med 2-6 projektmedlemmar. Den är 

också utmärkt att använda i studiesyfte för utvecklare som aldrig tidigare varit i kontakt med 

någon annan metod 

Peter Lorenz 45(47)


6 Diskussion 

Allt fler företag har kommit till insikt om att medarbetarnas kompetens är en färskvara som 

ständigt måste underhållas. Detta gäller inte minst inom IT-branschen där det ständigt 

lanseras nya produkter och versioner. 

Ett datoriserat verktyg är ett utmärkt hjälpmedel för att effektivt strukturera och följa upp 

kompetensutvecklingen på företaget. Kompetensia innehåller alla de delar som krävs för 

detta, allt enligt den utvecklingsprocess som beskrevs i avsnitt 3.9. Varje enskild individ 

måste dock ta sitt ansvar för sin egen utveckling på samma sätt som företagsledningen måste 

tillhandahålla de medel som krävs för detta. 

Arbetet med Kompetensia påbörjades i januari 2004 och har pågått i 18 veckor. Resterande 

två veckor har använts till rapportskrivning och dokumentation av systemet. RUP har visat sig 

fungera utmärkt som stöd även för enmansprojekt som detta. 

Microsofts ASP.NET utgör tillsammans med utvecklingsmiljön Visual Studio.NET ett 

mycket kraftfullt verktyg för webbutveckling. Ett alternativ till Microsofts produkter hade 

varit att utveckla systemet i PHP och använt sig av open source-databasen MySQL. 

Utvecklingstiden hade då kortats något, eftersom erfarenhet av PHP/MySQL redan fanns, till 

skillnad från ASP.NET. 

Det som kan förbättras till nästa version av Kompetensia är stöd för att koppla kompetensmål 

till kompetensinventeringen. I denna version 1.0 krävs det att man manuellt går in och 

inventerar sin kompetens, dvs höjer nuvarande nivån i samband med att man uppnått ett 

kompetensmål. 

Även stödet för kompetensgrupper kan förbättras. Idag finns redan utförlig information om 

gruppernas medlemmar och aktiviteter på Meteorits intranät. I version 2.0 av Kompetensia 

skulle denna information kunna integreras med systemet. 

Peter Lorenz 46(47)


7 Referenser 

Advantum (2004). Strategisk kompetensutveckling. [Elektroniskt] 

Tillgänglig: http://www.advantum.se/pdf/Strategisk_kompetensutveckling.pdf [2004-05-10] 

Beck, Kent (1999). Extreme Programming Explained: Embrace change. Addison Wesley Professional, 

ISBN 02-016-164-16 

Brown, Keith (2003). a .net developer's guide to Windows security. [Elektroniskt] 

Tillgänglig: http://www.develop.com/kbrown/book/ [2004-05-15, 12:51] 

Brown, Keith (2002). A Tale of Three Security Contexts in ASP.NET. [Elektroniskt] 

Tillgänglig: http://www.devx.com/SummitDays/Article/6666/0/page/1 [2004-05-15, 12:51] 

Goodyear, Jonathan (2004). Use a DataReader or a DataSet?. [Elektroniskt] 

Tillgänglig: 

http://www.sdgn.nl/Default.asp?A1PID=57PDGUH&A1SID=510423200447&URL=97083PSXX 

[2004-05-05, 13:50] 

HemBudget (2003). HemBudget. [Elektroniskt] 

Tillgänglig: http://www.hembudget.com [2004-05-14, 14:42] 

IBM Rational (2004). RUP Resources. [Elektroniskt] 

Tillgänglig: http://www-136.ibm.com/developerworks/rational/products/rup/ [2004-05-04, 12:11] 

LCube AB (2002). Kompetensanalys. [Elektroniskt] 

Tillgänglig: http://www.lcube.se/ca.html [2004-02-02, 13:55] 

Lindegren, Håkan (2003). Programvaruprojekt. Studentlitteratur AB, ISBN 91-4403-110-6 

Lunell, Hans (2003). Fyra rundor med RUP. Studentlitteratur AB, ISBN 91-44-04210-8 

MSDN (2004). Microsoft.NET Framework Developer. [Elektroniskt] 

Tillgänglig: http://msdn.microsoft.com/netframework/technologyinfo/overview/default.aspx 

[2004-05-18: 10:51] 

MSDN Class Library (2004) .NET Framework Class Library IHttpModule Interface. [Elektroniskt] 

Tillgänglig: 

http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemWebIHttpModuleClassTopic.asp 

Pagina Förlags AB (2004). Paginas IT-ordbok. [Elektroniskt] 

Tillgänglig: http://www.pagina.se/itord/ (Snabbsökning: .net) [2004-05-10, 10:10] 

P&L Nordic AB (2004). CompetenceTool TM . [Elektroniskt] 

Tillgänglig: http://www.pol.se/competencetool/ [2004-02-10, 11:40] 

Riordan, Rebecca M. (2002). ADO.NET Steg för steg. Microsoft Press, ISBN 91-636-0719-0 

Tallung, Peter (2003). Hög tid att överge vattenfallstänkandet. [Elektroniskt] 

Tillgänglig: http://www.kentor.se/sv/press_2002/tallungs/030904_hogtid.asp [2004-05-05, 17:32] 

Victorin, Joakim (2004). Utbildning RUP, PMM, Kravhantering. [Elektroniskt] Meteorit AB 

Tillgänglig: Meteorit AB [2004-05-10] 

Wilson-Welsh, Patrick (2003). The Waterfall Approach: Deadly and Dying. [Elektroniskt] 

Tillgänglig: http://www.adaptionsoft.com/adios_waterfall.html [2004-05-18, 19:47] 

Peter Lorenz 47(47)

KOMPETENSSYSTEM - Örebro universitet

Create successful ePaper yourself

Delete template?

Save as template?