KOMPETENSSYSTEM - Örebro universitet
KOMPETENSSYSTEM - Örebro universitet
KOMPETENSSYSTEM - Örebro universitet
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Examinator: Lars Karlsson<br />
COMPETENCE SYSTEM<br />
Examensarbete 20 poäng D-nivå<br />
<strong>KOMPETENSSYSTEM</strong><br />
Reg.kod: Oru-Te-EXA089-D108/04<br />
Peter Lorenz<br />
Magisterprogrammet i Datateknik 160 p<br />
<strong>Örebro</strong> vårterminen 2004<br />
<strong>Örebro</strong> <strong>universitet</strong> <strong>Örebro</strong> University<br />
Institutionen för teknik Department of technology<br />
701 82 <strong>Örebro</strong> SE-701 82 <strong>Örebro</strong>, Sweden
Sammanfattning<br />
Denna rapport beskriver utvecklingen av ett kompetenssystem i ASP.NET och<br />
programmeringsspråket C# för publikation på ett intranät. Projektstyrningsmodellen PMM<br />
(Project Management Model) och utvecklingsmetoden RUP (Rational Unified Process) har<br />
använts vid projektets genomförande.<br />
De kunskaper om RUP som projektet gav har tillsammans med litteraturstudier om TPFDmetoden<br />
(TestPlan Före Design) och XP (Extreme Programming) resulterat i en jämförelse<br />
mellan dessa metoder.<br />
Abstract<br />
This report describes the development of an online competence management system in<br />
ASP.NET and the programming language C#. The project management model PMM and<br />
RUP (Rational Unified Process) have been used in the project.<br />
The report also includes a comparison between RUP, TPBD (TestPlan Before Design) and XP<br />
(Extreme Programming).
Förord<br />
Till grund för denna rapport ligger det examensarbete som utförts på uppdrag av Meteorit AB<br />
under våren 2004. Examensarbetet avslutar magisterprogrammet i Datateknik vid <strong>Örebro</strong><br />
Universitet, Institutionen för Teknik.<br />
Jag vill speciellt tacka följande personer:<br />
Peter Moström, min handledare på Meteorit, för att han gett mig förtroendet att utveckla det<br />
nya kompetenssystemet.<br />
Projektets referensgrupp som kommit med många bra förslag på systemets funktionalitet.<br />
Håkan Lindegren, min handledare vid <strong>Örebro</strong> Universitet som granskat och gett goda råd om<br />
rapportens utseende.<br />
<strong>Örebro</strong> den 31 maj 2004<br />
Peter Lorenz
Kompetenssystem<br />
INNEHÅLLSFÖRTECKNING<br />
1 INLEDNING................................................................................................................................................ 5<br />
1.1 BAKGRUND........................................................................................................................................... 5<br />
1.2 SYFTE ................................................................................................................................................... 5<br />
2 METOD OCH KÄLLOR............................................................................................................................ 6<br />
2.1 BEFINTLIGT <strong>KOMPETENSSYSTEM</strong> .......................................................................................................... 6<br />
2.2 GENERELLA <strong>KOMPETENSSYSTEM</strong>.......................................................................................................... 6<br />
2.3 REFERENSGRUPPSMÖTEN...................................................................................................................... 6<br />
2.4 PPH-KURSEN ....................................................................................................................................... 6<br />
2.5 LITTERATURSTUDIER............................................................................................................................ 7<br />
3 PROJEKTBESKRIVNING........................................................................................................................ 8<br />
3.1 ÖVERGRIPANDE KRAV PÅ UTFORMNING AV SYSTEMET......................................................................... 8<br />
3.2 METODIK .............................................................................................................................................. 8<br />
3.2.1 PMM................................................................................................................................................ 8<br />
3.2.2 Vattenfallsmodellen....................................................................................................................... 10<br />
3.2.3 RUP............................................................................................................................................... 10<br />
3.3 MICROSOFT.NET................................................................................................................................17<br />
3.4 ASP.NET ........................................................................................................................................... 18<br />
3.5 ADO.NET.......................................................................................................................................... 19<br />
3.5.1 DataSet.......................................................................................................................................... 19<br />
3.5.2 DataReader ................................................................................................................................... 20<br />
3.6 ANVÄNDARAUTENTISERING I ASP.NET............................................................................................. 20<br />
3.7 SESSIONSOBJEKTET............................................................................................................................. 23<br />
3.8 HOGIA................................................................................................................................................. 23<br />
3.9 KOMPETENSUTVECKLING ................................................................................................................... 23<br />
4 RESULTAT ............................................................................................................................................... 25<br />
4.1 ANVÄNDARGRÄNSSNITT..................................................................................................................... 25<br />
4.2 SYSTEMDESIGN................................................................................................................................... 36<br />
4.2.1 Utvecklings- och målmiljöer ......................................................................................................... 36<br />
4.2.2 Logik.............................................................................................................................................. 37<br />
4.2.3 Databaskonstruktion ..................................................................................................................... 38<br />
4.2.4 Inloggning och autentisering av användare.................................................................................. 40<br />
5 JÄMFÖRELSE AV RUP, EXTREME PROGRAMMING OCH TPFD ............................................. 41<br />
5.1 XP ...................................................................................................................................................... 41<br />
5.2 TPFD.................................................................................................................................................. 42<br />
5.3 RUP.................................................................................................................................................... 44<br />
5.4 ARTEFAKTMÄNGD .............................................................................................................................. 44<br />
5.5 SAMMANFATTNING............................................................................................................................. 44<br />
6 DISKUSSION ............................................................................................................................................ 46<br />
7 REFERENSER .......................................................................................................................................... 47<br />
Peter Lorenz 4(47)
Kompetenssystem<br />
1 Inledning<br />
1.1 Bakgrund<br />
Meteorit är ett konsultbolag inom systemutveckling och nätverk som grundades i <strong>Örebro</strong><br />
1997. Deras affärsidé är att vara en stark och långsiktig IT-partner för större företag och<br />
organisationer.<br />
Meteorit har ett behov av att beskriva och kontinuerligt uppdatera vilken kompetens<br />
respektive medarbetare har. I anslutning till offerter, planering av uppdrag eller att man helt<br />
enkelt behöver hjälp av en viss karaktär är det viktigt att snabbt och enkelt kunna ta reda på<br />
vem som kan vad om en bransch, produkt eller teknologi.<br />
Det finns också ett behov av att kunna se hur den gemensamma kompetensen är fördelad per<br />
organisatorisk enhet för att man skall få en bild av vilken kompetens som finns var. Det är<br />
också viktigt i den strategiska kompetensplaneringen.<br />
Meteorit har sedan tidigare tagit fram ett system för att hantera kompetens men detta system<br />
kom aldrig i drift och har därmed inte använts. Nu är systemet något föråldrat och behöver<br />
byggas om.<br />
1.2 Syfte<br />
Syftet med examensarbetet är att genom systemering och programmering ta fram ett nytt<br />
kompetenssystem. Detta skall sedan publiceras på intranätet och vara tillgängligt för alla<br />
Meteorits anställda. PMM (Project Management Model) och RUP (Rational Unified Process)<br />
kommer att användas som styrmetoder vid projekt –och utvecklingsarbetet.<br />
De erfarenheter om RUP som arbetet ger, kommer tillsammans med litteraturstudier om<br />
TPFD-metoden (TestPlan Före Design) och XP (Extreme Programming) att ligga till grund<br />
för en jämförelse av olika programutvecklingsmetoder.<br />
Peter Lorenz 5(47)
Kompetenssystem<br />
2 Metod och källor<br />
Detta avsnitt beskriver de metoder och källor som ligger till grund för kravspecifikation och<br />
utveckling av det nya kompetenssystemet.<br />
2.1 Befintligt kompetenssystem<br />
Meteorit utvecklade redan år 2001 ett kompetenssystem i Java, se figur 2.1. Systemet blev<br />
dock aldrig helt färdigställt och togs ej i bruk på grund av dess många buggar och brist på<br />
funktionalitet. Grundtanken i systemet var att den anställde skulle gå igenom alla inlagda<br />
kompetenser och ange nivå noll på de kompetenser man saknade. Övriga delar av systemet<br />
fungerade ej.<br />
Figur 2.1: Gammalt kompetenssystem<br />
2.2 Generella kompetenssystem<br />
Skärmdumpar på kommersiella system hämtade från (LCube AB, 2004) och (P&L Nordic<br />
AB, 2004) har studerats för att inspirera och ge idéer om vilken funktionalitet som bör ingå i<br />
ett kompetenssystem.<br />
2.3 Referensgruppsmöten<br />
Tre möten med referensgrupp bestående av kompetensansvariga vid företaget har hållits.<br />
Första mötet hölls i samband med förberedelsefasen och resulterade i ett stort antal krav på<br />
systemet. Andra mötet ägde rum innan konstruktion för att diskutera programmets design.<br />
Tredje mötet hölls för att fastställa testrutiner innan test-och-felrättning av systemet<br />
påbörjades.<br />
2.4 PPH-Kursen<br />
Hösten 2004 gick jag kursen PPH (Programvaruutveckling och projekthantering) vid <strong>Örebro</strong><br />
Universitet, Institutionen för Teknik. Kursen har utarbetats av Håkan Lindegren och går på<br />
halvfart en hel termin. Studenterna lottas in i grupper om fyra personer och skall sedan<br />
bedriva ett utvecklingsprojekt med hjälp av TPFD-metoden, dvs kravspecificering, testplan,<br />
design och implementation. För att bli godkänd krävs att en produkt levereras och fungerar<br />
enligt uppställda krav. Det är främst via kursen jag har kännedom om TPFD-metoden, som<br />
jämförs med RUP och XP i den här rapporten.<br />
Peter Lorenz 6(47)
Kompetenssystem<br />
I min grupp beslöt vi oss för att ta fram ett Windowsprogram i vilket man enkelt skulle kunna<br />
budgetera sin vardagliga ekonomin. Resultatet vid kursens slut var programmet HemBudget<br />
(2003). Det inkluderar funktioner som till exempel fleranvändarstöd och grafisk statistik.<br />
2.5 Litteraturstudier<br />
Lunell (2003), Beck (1999) och Lindegren (2003) har studerats för att ge underlag för en<br />
jämförelse mellan utvecklingsmetoderna RUP, XP och TPFD.<br />
Kriterier för jämförelsen sattes långt in i projektet. Erfarenheterna från TPFD och RUP blev<br />
där styrande. Kriterierna ser ut så här:<br />
• Vilka är skillnaderna i kravhantering?<br />
• Vad är skillnaden i dokumentmängd?<br />
• Hur väl lämpar sig metoderna i utbildningssyfte?<br />
Peter Lorenz 7(47)
Kompetenssystem<br />
3 Projektbeskrivning<br />
Detta avsnitt beskriver övergripande krav på systemet samt de projektstyrnings- och<br />
utvecklingsverktyg som använts under projektets gång. Sist i avsnittet presenteras den<br />
kompetensutvecklingsmodell som legat till grund för systemet.<br />
3.1 Övergripande krav på utformning av systemet<br />
• Systemet skall utvecklas i form av en webbapplikation för publicering på intranätet.<br />
• Ingen extra inloggning skall vara nödvändig för användaren. Autentisering skall ske<br />
via företagets Active Directory. Detta kallas för single sign-on.<br />
• Två typer av användare skall finnas i systemet, administratör och anställd.<br />
Administratörerna skall ha tillgång till analyser, utvecklingshistorik samt<br />
systemadministration.<br />
• För att klassas som administratör av systemet skall det räcka med att användaren är<br />
medlem i gruppen KompetensAdmin i Active Directory.<br />
• Applikationen skall utvecklas i ASP.NET och C#.<br />
• Programmet skall spara information i en Microsoft SQL-databas.<br />
• Systemet skall integreras med Hogia för att kunna sortera anställda och visa<br />
information utifrån företagets organisatoriska enheter.<br />
(Hogia är ett moduluppbyggt affärssystem. Moduler finns för till exempel fakturering,<br />
kundreskontra; projektredovisning; tidsredovisning etc.)<br />
• PMM skall användas som styrmetod under projektets gång.<br />
• RUP skall användas som utvecklingsmetod.<br />
• Systemet skall döpas till Kompetensia v1.0 – Meteorit Professional Edition.<br />
3.2 Metodik<br />
För att kunna se hur olika aktiviteter är relaterade till varandra samt kunna följa ett projekts<br />
livscykel används ofta en projektstyrnings- och utvecklingsmetod. Här följer en genomgång<br />
av PMM och RUP. På grund av sitt historiska värde beskrivs även Vattenfallsmodellen.<br />
3.2.1 PMM<br />
Figur 3.1: Faser i PMM<br />
Peter Lorenz 8(47)
Kompetenssystem<br />
PMM (Project Management Model) är en projektstyrningsmodell som Meteorit tillämpar.<br />
figur 3.1 visar en överblick av de aktiviteter som ett projekt passerar under sin livscykel.<br />
PMM används för att säkerställa att:<br />
• En metodisk modell finns som stöd vid projektarbetet.<br />
• Krav, mål och omfattning är klargjorda och motsvarar leveransobjekt.<br />
• Nivån på kontroll är tillräcklig för att uppfylla uppdragsgivarens direktiv.<br />
• Kvalitetssäkring kan genomföras på ett och samma sätt för alla projekt.<br />
• Kunden får en positiv bild och upplever en genomgående hög kvalitet i Meteorits<br />
arbetssätt i projektet.<br />
Initieringsfas (Initiate)<br />
Uppdragsbeskrivningen (benämnd REM i figur 3.2) fungerar<br />
som indata till initieringsfasen. Dokumentet klargör vad som<br />
förväntas av projektet, tidpunkt för leverans samt till vilken<br />
kostnad projektet kan genomföras. Den är en hörnsten i<br />
projektinitieringen och ligger som grund till beslut om<br />
projektet kan genomföras eller ej. Projektets sponsor måste<br />
signera uppdragsbeskrivningen för att säkerställa att dess<br />
innehåll överensstämmer med förväntat resultat.<br />
Projektspecifikationen (PS) är utdata från initieringsfasen.<br />
Den beskriver resultatet av fasen och fungerar som<br />
kontrolldokument för den efterföljande styrningen av projektet.<br />
Dokumentet måste godkännas av projektstyrningsgruppen eller<br />
sponsorn innan projektets genomförandefas kan påbörjas.<br />
Figur 3.2: Initieringsfasen<br />
Genomförandefas (Manage)<br />
Under genomförandefasen bedrivs parallellt alla de aktiviteter som finns specificerade i<br />
projektspecifikationen. Arbetet är händelsedrivet vilket betyder att oplanerade händelser är<br />
förväntade. För att hantera detta hålls löpande möten, övervakning, förändringshantering,<br />
verifikation samt acceptanstest och projektets sponsor hålls informerad om projektets<br />
framskridande genom leveransdokument (DEL). Denne måste sedan returnera ett signerat<br />
acceptansprotokoll (ACC) för att bekräfta att resultatet överensstämmer med kraven på<br />
projektet.<br />
Project Working Model<br />
I denna aktivitet, som drivs parallellt med Manage, tillämpas någon utvecklingsmetod för<br />
programvara, till exempel RUP.<br />
Avslutningsfas (Terminate)<br />
I avlutningsfasen lämnas leveransobjektet över till ägaren tillsammans med dokumentation till<br />
dess supportorganisation. Projektgruppen sammanställer erfarenheterna från projektet och<br />
resurser frigörs.<br />
Peter Lorenz 9(47)
Kompetenssystem<br />
3.2.2 Vattenfallsmodellen<br />
Vattenfallsmodellen är en utvecklingsmodell för programvara. Den togs fram på 70-talet då<br />
man såg behov av ett strukturerat arbetssätt. Den bygger på illusionen att det är möjligt att i<br />
ett tidigt skede av projektet fastställa och frysa systemets samtliga krav. Faserna i tabell 3.1<br />
passeras och en ny fas kan inte påbörjas förrän den gamla är helt färdig. Eventuella problem<br />
som dyker upp skjuts på framtiden eller ”kodas runt” och om kravändringar hotar arbetets<br />
gång håller man sig till det som bestämts från början.<br />
Kravanalys<br />
Design<br />
Implementation och<br />
deltest<br />
Systemtest<br />
Tabell 3.1:<br />
Vattenfallsmodellens faser<br />
I dag finns stor enighet om att vattenfallsmodellen inte<br />
lämpar sig för mjukvaruutveckling. Det har visat sig att ett<br />
parallellt och iterativt arbetssätt, som exempelvis RUP<br />
förespråkar lämpar sig mycket bättre än vattenfallsmodellens<br />
linjära och sekventiella metodik (Tallung, 2003).<br />
3.2.3 RUP<br />
RUP är en generell process för programvaruutveckling. Det är en kommersiell produkt som<br />
marknadsförs och utvecklas av Rational Software Corporation (IBM Rational, 2004) och nya<br />
utgåvor kommer regelbundet.<br />
I RUP har man försökt samla mycket av dagens bästa praxis inom programvaruutveckling och<br />
den är avsedd att fungera i så väl små som stora projekt. Detta betyder att RUP innehåller en<br />
stor mängd dokumentation och mallar, många av mycket abstrakt karaktär. Det finns ofta ett<br />
behov av att anpassa RUP efter projektets storlek, konkretisera beskrivningar och komplettera<br />
anvisningar med mera, därför brukar RUP även kallas för en konfigurerbar process.<br />
Bästa praxis betyder att man i RUP inkluderat ett antal väl beprövade metoder från tidigare<br />
programvaruutvecklingsmodeller. Dessa kan användas vid utveckling utan att för den skull<br />
tillämpa RUP. I dokumentationen återfinns följande sex beprövade metoder.<br />
Iterativ utveckling<br />
Utvecklingen delas upp i fyra större faser enligt figur 3.3 inom vilka ett antal iterationer sker.<br />
På svenska skulle dessa faser kunna kallas Föreberedelse, Etablering, Konstruktion och<br />
Överlämning (Lunell, 2003). Antalet iterationer i varje fas är beroende av projektets storlek<br />
och behov.<br />
Peter Lorenz 10(47)
Kompetenssystem<br />
Figur 3.3: Faser och iterationer i RUP (Källa: IBM Rational, 2004)<br />
Varför iterativt?<br />
Alla projekt innehåller alltid ett visst antal risker. Det kan vara risker som direkt påverkar<br />
utvecklingen, som t.ex. brist på hårdvara eller otillräckliga utvecklingsverktyg men även<br />
affärsrisker som att konkurrenter hinner före. Desto tidigare i projektets livscykel en risk<br />
identifieras ju tidigare kan den elimineras. Om man inte driver utvecklingen iterativt, utan<br />
tillämpar vattenfallsmodellen, kan det vara mycket svårt att tidigt identifiera risker (Wilson-<br />
Welsh, 2003). Dessa brukar då inte uppenbara sig förrän man närmar sig slutet på livscykeln,<br />
se figur 3.4.<br />
Förutom riskidentifiering kan man även hantera de kravändringar som kommer in under<br />
projektets gång på ett effektivare sätt om man utvecklar iterativt.<br />
Figur 3.4: Vattenfallsmodellen och RUP<br />
Peter Lorenz 11(47)
Kompetenssystem<br />
Kravhantering<br />
Kravhantering är att samla in, dokumentera, organisera, prioritera och följa upp de krav som<br />
ställs på ett system. I tabell 3.2 isas ett antal olika kravtyper.<br />
Funktionalitet<br />
Användarvänlighet<br />
Stabilitet<br />
Prestanda<br />
Drift/Vidareutv.<br />
Tabell 3.2: Kravtyper<br />
Resultatet av kravhanteringen i RUP är användningsfallsmodellen.<br />
Denna fungerar sedan som indata till Analys och<br />
Design, Implementation och Test.<br />
Arkitekturcentrerad utveckling<br />
En byggfirma skulle aldrig komma på tanken att börja bygga ett hus utan att först ha tillgång<br />
till en ritning. Det har dock inte varit lika självklart vid mjukvaruutveckling. I RUP tillämpas<br />
därför det som kallas arkitekturcentrerad utveckling dvs. en ritning av hur systemet ska<br />
byggas upp och olika komponenters samverkan.<br />
För att beskriva ett systems arkitektur används ”4+1”-vymodellen. Fem olika vyer beskriver<br />
designen av systemet sett från fem olika perspektiv, se figur 3.5.<br />
De olika vyerna är:<br />
Logisk vy Implementationsvy<br />
Användningsfallsvy<br />
Processvy Driftsättningsvy<br />
Figur 3.5: ”4+1”-vy över arkitektur<br />
• Användningsfallsvyn<br />
Så uppfattas systemet utifrån av dess användare.<br />
• Logisk vy<br />
Implementationsoberoende beskrivning av systemets delar, beteende och samverkan.<br />
• Implementationsvy<br />
Visar hur källkoden är organiserad och hur den logiska vyn skall implementeras.<br />
• Processvy<br />
Systemet beskrivs som ett antal samverkande exekverbara delar. Används mest för<br />
större sammanhängande system.<br />
• Driftsättningsvy<br />
Fysisk arkitektur för driftsättning av systemet.<br />
Peter Lorenz 12(47)
Kompetenssystem<br />
Visuell modellering<br />
Vid visuell modellering beskrivs systemets uppbyggnad med hjälp av standardiserade grafiska<br />
element. Modellen blir helt implementationsoberoende och verktyg finns för att utifrån<br />
modellen generera färdig källkod. I RUP kopplas den visuella modelleringen till UML<br />
(Unified Modelling Language).<br />
Upprepad kvalitetsverifiering<br />
Kvalitet är inget som kommer gratis bara för att man bygger ett datorprogram. Alla som är<br />
delaktiga i projektet är också ansvariga för produktens kvalitet. Det går inte att i efterhand<br />
omvandla ett system med låg kvalitet genom test-och-felrättning. Kvalitetskontroll måste<br />
föras aktivt genom hela livscykeln. Detta sker genom kontinuerliga granskningar och<br />
uppföljningar. Vid kravanalys kontrolleras kravens konsekvens och dess detaljrikedom, både<br />
inom projektet och för kommunikation med kunden. Vid analys och design kontrolleras om<br />
designmodellen överensstämmer med ursprungliga krav. I samband med implementation<br />
utförs tester för att garantera att implementerad kod överensstämmer med designmodellerna.<br />
Kvalitetsverifiering är alltså en aktivitet som hela tiden pågår parallellt med projektet.<br />
Konfigurations- och ändringshantering<br />
I ett projekt som bedrivs iterativt kommer flera versioner av dokument och programprototyper<br />
att tas fram. Ett konfigurations- och ändringssystem har till uppgift att hålla ordning på allt<br />
som projektet genererar. Detta inkluderar bl a versionshantering av källkod,<br />
konfigurationskontroll (vilka delar systemet utgörs av och hur de hänger ihop) samt<br />
ändringskontroll (hur hanteras ändringsbegäran och hur följs de upp).<br />
Ovanstående aktiviteter kan sägas vara giltiga för alla projekt, oavsett man tillämpar RUP<br />
eller inte. Nedan beskrivs ett antal aktiviteter som är mer specifika för RUP.<br />
Användningsfallsdriven utveckling<br />
Användningsfall utgör kärnan i RUP och kan ses som det nav omkring vilket övriga<br />
aktiviteter cirklar. Ett användningsfall beskriver ett händelseförlopp i systemet utifrån en<br />
aktörs synvinkel. En aktör kan vara en individ eller apparat som integrerar med systemet.<br />
Då man beskriver förloppet utgår man från handling och konsekvensregeln. Exempel på ett<br />
användningsfallsscenario för ett uttag från en bankomat skulle då se ut som följer:<br />
1. Aktören (bankkunden) stoppar in kortet i automaten (handling)<br />
2. Systemet svarar med att fråga efter kod (konsekvens)<br />
3. Aktören anger pin-kod (handling)<br />
4. Systemet verifierar kod mot databas och frågar efter belopp för uttag (konsekvens)<br />
5. Aktören anger belopp(handling)<br />
6. osv..<br />
Användningsfallet ovan beskriver vad som kallas för ett huvudflöde. Utöver detta kan<br />
användningsfallet ha ett antal alternativflöden. Exempel på detta kan vara vad som sker om<br />
pin-koden i exemplet ovan inte godkänns. Alla användningsfall beskrivs också med ett<br />
diagram som tillsammans med närliggande fall bygger upp en användningsfallsmodell<br />
liknande den i figur 3.6.<br />
Peter Lorenz 13(47)
Kompetenssystem<br />
Figur 3.6: Exempel på användningsfallsdiagram<br />
Roller<br />
I RUP ingår även att definiera roller, dvs vem som gör något. Rollbegreppet beskriver vilken<br />
slags person som behövs för olika uppgifter inom en disciplin av RUP. En roll behöver inte<br />
betyda en person, utan kan mycket väl fyllas av flera individer. En person kan även ha flera<br />
olika roller.<br />
Meteorits RUP-konfiguration<br />
Figur 3.7 visar den konfiguration som Meteorit tillämpar och även PMMs roll i RUP.<br />
Peter Lorenz 14(47)
Kompetenssystem<br />
Figur 3.7: Meteorits RUP-konfiguration (Källa: Victorin, 2003)<br />
Peter Lorenz 15(47)
Kompetensia<br />
Kravhantering<br />
Tre iterationer är ett minimum vid kravhantering för att ta fram användningsfallsmodellen.<br />
Arbetet kan se ut som följer:<br />
1. Identifiera och beskriv aktörer<br />
2. Identifiera och beskriv användningsfall<br />
3. Prioritera. Vilka är mer eller mindre viktiga?<br />
4. Skriv en ”outline” för samtliga användningsfall, dvs en översiktlig beskrivning av<br />
huvudflödet.<br />
5. Prioritera bland användningsfallen.<br />
6. Detaljera användningsfallen, identifiera alternativflöden<br />
7. Prioritera bland användningsfallen.<br />
(Källa: Victorin, 2003)<br />
I samråd med styrgrupp godkänner projektledaren kraven innan arbetet med design och<br />
arkitektur påbörjas. Även designmodell och testplan skall godkännas innan implementation.<br />
Peter Lorenz 16(47)
Kompetensia<br />
3.3 Microsoft.NET<br />
År 2000 lanserades Microsoft .NET. Det uttalas ”dotnet” och har på svenska översatts till<br />
”plattformen.NET” (Pagina Förlags AB, 2004). Huvudmålet med .NET är att underlätta<br />
mjukvaruutveckling där fokus ligger på utbyte av information via Internet. Genom så kallade<br />
”Web Services” kopplas olika typer av system samman, vilket kan ge användaren möjlighet<br />
att ta del av sina data och program oavsett plats och plattform, se figur 3.8.<br />
Figur 3.8: Kommunikation via XML Web Services<br />
Tidigare har program som utvecklats för Windowsmiljö använt sig av anrop till Win32biblioteken<br />
bestående av hundratals Windowsspecifika funktioner. Dessa bibliotek har i sin<br />
tur hanterat kommunikationen med Windows och hårdvaran. Källkoden har kompilerats<br />
direkt till maskinkod och ett körbart program.<br />
Detta har bidragit till följande problem:<br />
• Plattformsberoende<br />
Ett program som är utvecklat i exempelvis Visual Basic kan bara köras i Microsoft<br />
Windows.<br />
• Det finns inga garantier att samma exekverbara program, utvecklat i olika<br />
programmeringsspråk, genererar liknande maskinkod vilket gör det omöjligt att dela<br />
funktioner och bibliotek mellan olika språk.<br />
• Win32 API är inget annat än en uppsjö av funktioner. Dessa funktioner innehåller ofta<br />
mycket kryptiska förklaringar och anropsparametrar vilket gör det svårt för en<br />
utvecklare.<br />
På Microsoft har man väl känt till dessa brister och har därför i plattformen.NET vidtagit<br />
åtgärder för att eliminera dessa.<br />
Peter Lorenz 17(47)
Kompetensia<br />
De två första problemen har man löst på det sätt som illustreras i figur 3.9. Källkoden<br />
översätts först till vad som kallas Microsoft Intermediate Language (MSIL). Denna IL-kod<br />
körs sedan i exekveringsmotorn, Common Language Runtime (CLR). CLR hanterar<br />
översättningen till maskinspecifika instruktioner och kontrollerar även minnet,<br />
undantagshantering och skräpsamling.<br />
Figur 3.9: Virtuell exekveringsmotor kör programmets kod<br />
Problemet med det svårhanterliga Win32 API har man löst genom att införa det som kallas för<br />
klassramverket. Det är en stor samling klasser som innehåller all funktionalitet som en<br />
utvecklare kan tänkas behöva. Till skillnad från Win32 API är klasserna välorganiserade i så<br />
kallade namnutrymmen (eng. namespace). Till exempel innehåller namnutrymmet System<br />
klasser för att hantera de primitiva datatyperna: System.Int32, System.Array, System.String<br />
osv. (MSDN, 2004)<br />
3.4 ASP.NET<br />
ASP.NET är en ny teknik för att kunna ta del av de ovan nämnda fördelarna även vid<br />
webbutveckling. Detta betyder att ASP.NET-sidor utvecklas i något av de<br />
programmeringsspråk som stöds av plattformen .NET.<br />
Då en klient begär en webbsida kontrollerar webbservern om aktuell IL-kod finns tillgänglig<br />
och i så fall genereras HTML som skickas till klienten. Om IL-kod saknas eller om<br />
ASP.NET-sidans kod uppdaterats, kompileras sidan om på nytt. Den nya IL-koden sparas<br />
sedan på disk så att framtida kompileringar ej behövs.<br />
En annan nyhet i ASP.NET är code-behind vilket gör det möjligt att separera logik från<br />
presentation och lägga all kod i separata klassfiler.<br />
Peter Lorenz 18(47)
Kompetensia<br />
Kontroller<br />
I ASP.NET finns ett antal olika kontroller till hjälp när man bygger användargränssnitt.<br />
De anges i koden på följande sätt, vilket betyder att de kommer att hanteras av servern:<br />
<br />
Förutom HTML Controls, som består av vanliga HTML-kontroller, finns följande att tillgå:<br />
• Server Controls<br />
Färdigpaketerad programkod för att utföra dynamiska funktioner. Detta kan vara till<br />
exempel , som representerar en knapp och dess funktionalitet eller<br />
, vilket ger en etikett.<br />
• Validation Controls<br />
Används för att enkelt kunna validera en användares inmatade data i exempelvis fält.<br />
• List Controls<br />
Tillhandahåller paketerad kod för att enkelt hantera listor från exempelvis en databas.<br />
• Rich Control<br />
Avancerade komponenter som exempelvis kalender.<br />
• User Control<br />
Kontroll som användaren själv kan skapa. Filändelsen blir .ascx och kontrollen kan<br />
sedan inkluderas i ASP.NET-sidorna. Det är lämpligt att skapa en användarkontroll<br />
om det är någon funktion som kommer att användas på flera sidor, som exempelvis en<br />
dropdown-lista över kompetensområden.<br />
3.5 ADO.NET<br />
ADO.NET är en samling klasser för dataåtkomst som ingår i klassramverket. Det är möjligt<br />
att ansluta till Microsoft SQL Server men även andra databaser och XML-datakällor.<br />
Två nyheter i ADO.NET är DataSet och DataReader. Dessa förklaras närmare i nästa avsnitt.<br />
Många utvecklare misstar sig och tror att DataSet är bättre än DataReader eller tvärtom. Båda<br />
teknikerna har sina för- och nackdelar (Goodyear, 2004) och användningsområdet bör avgöra<br />
vilken teknik man väljer.<br />
3.5.1 DataSet<br />
DataSet utgör kärnan i ADO.NETs så kallade frånkopplade arkitektur. Detta innebär att<br />
information hämtas från datakällan, lagras i minnet i form av ett DataSet och databaskopplingen<br />
stängs. När man är klar med databehandlingen överförs alla ändringar till<br />
databasen igen.<br />
Peter Lorenz 19(47)
Kompetensia<br />
Exempel på när ett DataSet är bra att använda:<br />
• Vid avancerade beräkningar på resultaten från en databasfråga innan dessa skrivs ut på<br />
skärmen.<br />
• Då man behöver kunna navigera fritt, filtrera, sortera och söka bland informationen<br />
som returnerats.<br />
• Då samma information skall användas på flera olika ställen eller senare i programmet.<br />
• Då informationen som hämtas ligger till grund för nya databasanrop.<br />
• Om datakällan är ett XML-dokument istället för en databas. DataSet klarar av att läsa<br />
in XML-dokument direkt och kan även skriva till fil.<br />
3.5.2 DataReader<br />
DataReader läser en rad i taget till minnet från databasen och kräver därför att databaskopplingen<br />
hålls öppen. DataReader kan bara navigera framåt en rad i taget.<br />
DataReader är bra att använda:<br />
• Om det finns behov av att informationen som visas alltid är aktuell och därför måste<br />
hämtas från databasen varje gång den skall bearbetas.<br />
• Om man bara behöver läsa informationen en gång, rad för rad, som till exempel vid<br />
databindning av Webbkontroller som listboxar, datagrid m.m.<br />
• Då en liten mängd data skall hämtas från databasen ett upprepat antal gånger.<br />
3.6 Användarautentisering i ASP.NET<br />
För att uppfylla kravet på single sign-on, se Avsnitt 3.1, måste användaren som besöker sidan<br />
identifieras av ASP.NET-applikationen. Denna information kan sedan användas för uppslag i<br />
företagets Active Directory för att hämta fler uppgifter, såsom till exempel namn och adress<br />
men även för att kontrollera användarens åtkomstgrad till applikationen utifrån grupptillhörighet<br />
i AD.<br />
Det finns tre olika säkerhetsinställningar som ligger till grund för vilken användare som<br />
ASP.NET-applikationen kommer att exekveras under (Brown, 2002). I det här kapitlet<br />
beskrivs dessa genom att följa ett inkommande anrop från en klient. I figur 3.10 visas den väg<br />
genom vilken en förfråga färdas innan ASP.NET-applikationen startar.<br />
Peter Lorenz 20(47)
Kompetensia<br />
Figur 3.10: ASP.NET-förfrågan<br />
[1] Inkommande förfrågan anländer till webbservern och slussas via operativsystemet vidare<br />
till INETINFO.EXE som är den process i Microsoft Internet Information Services (IIS) som<br />
hanterar webbservertjänster. Notera att denna process körs under användaren SYSTEM, den<br />
användare med flest rättigheter i operativsystemet.<br />
[2] Tråden inne i processen INETINFO som hanterar förfrågan kommer alltid att personifiera<br />
ett annat användarkonto, beroende på de aktuella autentiseringsinställningar i IIS som visas i<br />
figur 3.11.<br />
Figur 3.11: Autentiseringsmetoder i IIS<br />
Peter Lorenz 21(47)
Kompetensia<br />
Om anonym åtkomst är påslagen kommer tråden att köras som användaren IUSR_MACHINE<br />
om inga andra inställningar gjorts.<br />
Integrerad Windows Autentisering lämpar sig mycket bra som autentiseringsmetod för<br />
intranät där användare och webbservrar ingår i samma domän. Uppgifter om den aktuella<br />
Windowsanvändaren på anropande klient används för åtkomstkontroll på servern. Om detta<br />
misslyckas kommer webbläsaren att be användaren om användarnamn och lösenord. Utbyte<br />
av uppgifter sker krypterat mellan klient och server. Integrerad Windows Autentisering<br />
används i kompetenssystemet för att uppfylla kravet på single sign-on-funktionalitet.<br />
[3] Om förfrågan gäller en ASP.NET-sida, vidarebefordras denna till aspnet_isapi.dll. Denna<br />
DLL fungerar som en brygga till den separata processen ASPNET_WP (arbetarprocessen).<br />
[4] Arbetarprocessen körs inte som SYSTEM utan under ett lokalt användarkonto som heter<br />
ASPNET. Detta konto installeras automatiskt vid installation av .NET-ramverket. Till<br />
skillnad från SYSTEM-kontot har denna användare mycket få rättigheter till systemet.<br />
[5] Tråden som hanterar förfrågan i arbetarprocessen personifierar i sin tur en användare eller<br />
ej utifrån de inställningar som finns i filen web.config, som följer med webbapplikationen.<br />
<br />
Om identity impersonate sätts till true kommer användaren som identifierades av tråden i<br />
INETINFO att ärvas till aktuell tråd i ASPNET_WP, annars kommer denna att köras under<br />
samma användare som processen, dvs. ASPNET.<br />
[6] Här slussas förfrågan genom en serie moduler som kan liknas vid en uppsättning filter.<br />
Var och en av dessa moduler måste implementera gränssnittet IHttpModule. I tabell 3.12<br />
visas de klasser som redan finns tillgängliga i .NET-ramverket.<br />
Eftersom dessa filter hanterar förfrågningar innan de når en applikation, kan de till exempel<br />
omdirigera anonyma användare till en loginsida (vid formulärautentisering) eller neka<br />
användare åtkomst till applikationen. En genomgång av samtliga dessa ligger utanför denna<br />
framställning och lämnas därför därhän.<br />
Class Description<br />
DefaultAuthenticationModule Insures that an Authentication object is present in the context.<br />
This class cannot be inherited.<br />
FileAuthorizationModule Verifies that the remote user has NT permissions to access<br />
the file requested. This class cannot be inherited.<br />
FormsAuthenticationModule Enables ASP.NET applications to use forms authentication.<br />
This class cannot be inherited.<br />
PassportAuthenticationModule Provides a wrapper around PassportAuthentication services.<br />
This class cannot be inherited.<br />
SessionStateModule Provides session-state services for an application.<br />
UrlAuthorizationModule Provides URL-based authorization services for allowing or<br />
denying access to specified resources. This class cannot be<br />
inherited.<br />
Tabell 3.12: Klasser som implementerar IHttpModule. (Källa: MSDN Class Library, 2004)<br />
Peter Lorenz 22(47)
Kompetensia<br />
Vilken modul som kommer att användas baseras även det på inställningar i web.config:<br />
<br />
Eftersom kompetenssystemet använder sig av Windowsautentisering kommer modulen<br />
WindowsAuthenticationModule att användas. Dess uppgift är att hantera den autentiseringsinformation<br />
som IIS skickar med förfrågan. Detta sker genom att ett WindowsPrincipalobjekt<br />
skapas som i sin tur innehåller ett WindowsIdentity-objekt via egenskapen Identity.<br />
Dessa två klasser implementerar gränssnitten IPrincipal respektive IIdentity.<br />
WindowsPrincipal-objektet kommer man sedan åt via egenskapen HttpContext.User.<br />
Aktuell användare hämtas från HttpContext.Current.User.Identity.Name.<br />
[7] Slutligen når förfrågan sin slutdestination, en så kallad HttpHandler. En aspx-sida ärver<br />
från System.Web.UI.Page som implementerar IHttpHandler-gränssnittet, så en vanlig aspxsida<br />
är en typ av HttpHandler.<br />
3.7 Sessionsobjektet<br />
För att hålla reda på en användare över flera sidor i applikationen används i ASP.NET ett så<br />
kallat sessionsobjekt. Varje gång en ny användare besöker sidan instansieras ett objekt som är<br />
specifikt bundet till användarens webbläsare. Objektet är sedan åtkomligt från applikationens<br />
alla sidor. I kompetenssystemet används detta för att spara aktuellt användarid och om<br />
användaren är administratör eller ej.<br />
Information läggs in på följande sätt:<br />
Session["isAdmin"] = true;<br />
Och hämtas på motsvarande sätt:<br />
int usrID = (int) Session["UserID"];<br />
3.8 Hogia<br />
På Meteorit finns ett antal resultatenheter, exempelvis konsultgrupp 1, drift och stab.<br />
Samtliga anställda är medlemmar i någon av dessa enheter och information om detta återfinns<br />
i en SQL-databas som är kopplad till affärssystemet Hogia.<br />
Ett krav på Kompetensia är att kunna visa statistik fördelad per resultatenhet. Meteorit<br />
tillhandahåller en lagrad procedur för att hämta nödvändig information från Hogiadatabasen.<br />
3.9 Kompetensutveckling<br />
”Kompetens är varje människas teoretiska och praktiska kunskaper, arbetslivserfarenheter,<br />
sociala färdigheter, samt viljan och förmågan att omsätta dessa i handling”<br />
Källa: www.sif.se<br />
Att utveckla kompetens är något som tar tid. Det är en process där ansvaret ligger på samtliga<br />
inblandade i företaget. Utan ordentliga verktyg är det svårt att styra utvecklingen och aktivt<br />
utvärdera dess resultat.<br />
Peter Lorenz 23(47)
Kompetensia<br />
En kompetensutvecklingsprocess bör bestå av fyra återkommande moment som visas i figur<br />
3.13 (Advantum, 2004).<br />
Figur 3.13: Kompetensutvecklingens fyra faser<br />
Kompetensanalys<br />
Korta och långsiktiga mål identifieras och ställs upp.<br />
Kompetensinventering<br />
Nuvarande och önskad kompetens kartläggs och dokumenteras. Detta kan ske löpande och<br />
vid 2-3 större inventeringar per år i samband med utvecklingssamtal eller dylikt.<br />
Kompetensförsörjning<br />
Individerna tilldelas rätt medel för att kunna uppnå mål och kompetensnivåer satta i de två<br />
första stegen. Detta kan vara kurser, kvalitetsgrupper, diskussioner, mässbesök eller att en ny<br />
person anställs för att fylla ett visst kompetensbehov.<br />
Utvärdering<br />
Här analyseras kompetensläget för att se om målen uppnåtts och kompetensen ökat inom<br />
önskade områden. Resultaten från utvärderingen blir indata till en ny kompetensanalys.<br />
Peter Lorenz 24(47)
Kompetensia<br />
4 Resultat<br />
Detta avsnitt beskriver det färdiga kompetenssystemet utifrån användarperspektiv samt<br />
systemdesign och databaskonstruktion.<br />
4.1 Användargränssnitt<br />
En översikt av användargränssnittet visas i figur 4.1. Applikationens indexsida innehåller två<br />
ramar. Vid start laddas menyn i den vänstra ramen och blir på så sätt alltid synlig. I den högra<br />
ramen laddas startsidan. Menyval visas därefter alltid i den högra ramen.<br />
Figur 4.1: Startsida - Kompetensia<br />
Genomgången av sidorna i detta avsnitt följer den ordning en ny användare rekommenderas<br />
följa.<br />
Personlig info<br />
Här anges namn, telefon och övriga personliga uppgifter tillsammans med bakgrund, tjänster<br />
och utbildning. Det finns även möjlighet att ladda upp en bild.<br />
Kompetensaktiviteter<br />
Användaren skall här lägga in sin projekthistorik, dvs. uppgifter om tidigare projekt och de<br />
arbetsuppgifter som dessa inkluderat. Även aktiviteter som till exempel avslutade kurser eller<br />
litteraturstudier kan läggas in, se figur 4.2 och figur 4.3.<br />
Peter Lorenz 25(47)
Kompetensia<br />
Figur 4.2: Kompetensaktiviteter<br />
Figur 4.3: Lägg till ny aktivitet<br />
Peter Lorenz 26(47)
Kompetensia<br />
Certifiering<br />
Användaren lägger in de certifieringar som han/hon har tagit.<br />
Kompetensinventering<br />
Här skall användaren inventera sin kompetens. Detta sker genom att ange nuvarande- och<br />
önskad nivå inom ett kompetensområde, se figur 4.4. För att styrka angivna nivåer ges<br />
möjlighet att referera varje kompetensinställning till tidigare inlagda kompetensaktiviteter och<br />
certifieringar. Genom att klicka på ”Lägg till referens” visas fönstret i figur 4.6.<br />
Figur 4.4: Kompetensinventering<br />
Längst ner på sidan visas de kompetenser man tidigare inventerat med möjlighet att ta bort<br />
eller uppdatera dessa, se figur 4.5.<br />
Figur 4.5: Kompetenslista vid kompetensinventering<br />
Peter Lorenz 27(47)
Kompetensia<br />
Figur 4.6: Lägg till referens<br />
Figur 4.7: Kompetensmål<br />
Peter Lorenz 28(47)
Kompetensia<br />
Kompetensmål<br />
Här skall individuella kompetensmål ställas upp utifrån egna önskemål och de krav som finns<br />
samlade i företagets gemensamma målpool, se nedan. Användaren anger då målet är uppnått<br />
och detta markeras i översikten med en stjärna, se figur 4.7.<br />
Målpool<br />
Mål identifieras av företagsledningen och läggs ut i målpoolen. Härifrån kan de anställda<br />
sedan flytta mål till sina personliga kompetensmål.<br />
Kompetensgrupper<br />
Här listas de kompetensgrupper och dess medlemmar som finns på företaget.<br />
Möjlighet finns att gå med och gå ur kompetensgrupp.<br />
Min Profil<br />
All information som användaren angett i systemet, förutom kompetensmål, sammanställs<br />
under ”Min Profil”. Denna kommer sedan att fungera som konsultprofil och möjlighet finns<br />
att skriva ut profilen och att spara denna som ett Worddokument, se figur 4.8.<br />
Bild Bild Bild<br />
Figur 4.8: Min Profil<br />
Längst ner på sidan ”Min Profil” visas användarens kompetenslista. Det är en översikt av de<br />
kompetenser som användaren har angett vid sin kompetensinventering, se figur 4.9.<br />
Peter Lorenz 29(47)
Kompetensia<br />
Figur 4.9: Kompetenslista<br />
Genom att klicka på en kompetens i listan visas information om dess referenser och<br />
nivåhistorik, se figur 4.10.<br />
Figur 4.10: Information om kompetensen MS SQL Server Admin<br />
Peter Lorenz 30(47)
Kompetensia<br />
Sök kompetens<br />
Följande sökfunktioner finns i Kompetensia, se figur 4.11:<br />
• Visa profil<br />
Gå direkt till en anställds profil<br />
• Fritextsökning<br />
Ange valfria kommaseparerade söktermer och systemet visar de personer som matchar<br />
sökningen och deras kompetensnivåer inom området.<br />
• Kompetensaktiviteter<br />
Listar systemets alla inlagda kompetensaktiviteter.<br />
• Certifieringar<br />
Listar systemets alla inlagda certifieringar.<br />
• Projektsökning<br />
Möjlighet att markera flera av de kompetenser som finns inlagda i systemet och visa<br />
personer som bäst passar in på sökningen samt matchningsgrad.<br />
Möjlighet att filtrera sökresultat med en lägsta nivå på returnerade resultat.<br />
Figur 4.11: Sök kompetens<br />
Peter Lorenz 31(47)
Kompetensia<br />
För åtkomst till följande sidor krävs administratörsrättigheter.<br />
Utvecklingshistorik<br />
Ger möjlighet att analysera kompetensutvecklingen över tiden, dvs ändring i summan av<br />
nuvarande- och önskade nivåer. Resultat kan visas för en eller flera resultatenheter samt en<br />
kompetenskategori eller specifik kompetens, se figur 4.12 och figur 4.13.<br />
Förutom nivåhistorik returneras även antalet anställda enligt sökkriterierna, se figur 4.14.<br />
Figur 4.12: Sökkriterier för utvecklingshistorik<br />
Figur 4.13: Utvecklingshistorik Branschkunskap 2002<br />
Peter Lorenz 32(47)
Kompetensia<br />
Figur 4.14: Antalet anställda som matchar sökningen<br />
Kompetenscirkel<br />
Visar hur kompetensen är fördelad procentuellt ett angivet år och grupperat efter valbar<br />
resultatenhet, se figur 4.15.<br />
Figur 4.15: Kompetenscirkel<br />
Peter Lorenz 33(47)
Kompetensia<br />
Administrera målpool<br />
Här läggs nya mål in i företagets målpool. Här visas också vilka anställda som överfört ett<br />
visst mål till sina personliga kompetensmål.<br />
Systemadministration<br />
Möjlighet att administrera systemet, dvs ta bort användare, lägga till kompetenser och<br />
kategorier, kompetensgrupper, kompetensaktivitetstyper, administrera hjälpavsnitt och övrigt<br />
som har med systemets funktionalitet att göra.<br />
En översikt av ASP.NET-sidorna och användarkontrollernas struktur visas i figur 4.16.<br />
Peter Lorenz 34(47)
Kompetensia<br />
Figur 4.16: Applikationens användargränssnitt<br />
Peter Lorenz 35(47)
Kompetenssystem<br />
4.2 Systemdesign<br />
4.2.1 Utvecklings- och målmiljöer<br />
Utvecklingsmiljö<br />
Följande utrustning och mjukvara har använts vid utveckling av Kompetensia:<br />
• Server med Microsoft SQL Server 2000<br />
• Internet Information Server 5.0 med .NET-ramverket installerat som webbserver<br />
• En klientdator med Windows XP som operativsystem.<br />
• Microsoft Visual Studio.NET som utvecklingsverktyg.<br />
• Microsoft Word 2003 som ordbehandlare<br />
• Microsoft Internet Explorer 6.0 som webbläsare<br />
• Visual Paradigm för att generera UML-diagram från kod<br />
• Rational Rose för design av systemet<br />
Målmiljö<br />
Följande hård- och mjukvara utgör systemets målmiljö:<br />
• Server med Microsoft Server 2003<br />
• Internet Information Server 5 med .NET-ramverket<br />
installerat.<br />
Systemet är uppbyggt som en treskiktsarkitektur där grundpelarna i systemet utgörs av de åtta<br />
klasser som illustreras i figur 4.17. Deras uppgift är att dölja programmets logik för aspxsidorna<br />
samt erbjuda omvärlden ett väldefinierat gränssnitt. Valet av denna design gör det<br />
enkelt att integrera dessa komponenter i andra system.<br />
Kompetens<br />
(CCompetence)<br />
Användare<br />
(CUser)<br />
Kompetensmål Kompetensaktiviteter Certifiering<br />
(CTarget) (CMilestone) ( CCertificate)<br />
Kompetensgrupper<br />
(CCompGroup)<br />
Sökning<br />
(CSearch)<br />
Analys<br />
(CAnalysis)<br />
Figur 4.17: De åtta klasserna utgör logiklagret, systemets grundpelare<br />
Varje klass tillhandahåller metoder och egenskaper för den funktionalitet som klassen<br />
representerar. Kommunikation mellan logiklagret och andra system, såsom Active Directory<br />
och Hogiadatabasen, sker via tre databasklasser som visas i figur 4.18.<br />
Peter Lorenz 36(47)
Kompetenssystem<br />
Figur 4.18: Kommunikation mellan logik och datakällor<br />
För att till exempel komma åt metoder i klassen CUser från en code-behind sida (se avsnitt<br />
3.4) instansieras ett objekt av klassen på följande sätt:<br />
CUser usr = new CUser();<br />
4.2.2 Logik<br />
Här följer en genomgång av de åtta grundklasserna med exempel på funktionalitet.<br />
Kompetensklassen (CCompetence)<br />
Tillhandahåller metoder för kompetensspecifika uppgifter såsom:<br />
• Hantera systemets inlagda kompetenser och dess kategorier.<br />
• Metoder för kompetensinventering, dvs. hantera en anställds kompetenser och<br />
kompetensnivåer.<br />
• Historik över ändringar i kompetensnivåer.<br />
• Hantera den anställdes kompetenslista.<br />
Kompetensmål (CTarget)<br />
Här finns samtliga metoder samlade för att hantera en anställds personliga mål samt mål i<br />
målpoolen. Bland annat:<br />
• Visa, lägg till, ta bort och uppdatera mål.<br />
• Flytta mål från målpoolen.<br />
• Markera mål som uppnåtts.<br />
• Hämta mål där deadline passerats.<br />
Peter Lorenz 37(47)
Kompetenssystem<br />
Kompetensaktiviteter (CMilestone)<br />
Hanterar all funktionalitet för kompetensaktiviteter. Här finns metoder för att:<br />
• Visa, lägga till, ta bort och uppdatera aktiviteter.<br />
• Hantera aktivitetstyper. (Standardtyper: Projekt, Litteratur, Kurs och Övrigt)<br />
Certifiering (CCertificate)<br />
Här finns metoder för att hantera en anställds certifieringar.<br />
• Visa, lägga till, ta bort och uppdatera certifieringar.<br />
• Hämta titel och företagsnamn på samtliga certifieringar i databasen.<br />
Användare (CUser)<br />
Tillhandahåller metoder för att hantera användare. Detta inkluderar:<br />
• Visa, lägg till, uppdatera, ta bort en användare.<br />
• Hantera inloggning av en användare.<br />
• Hämta alla användare.<br />
• Uppdatera senaste logindatum.<br />
Kompetensgrupper (CCompGroup)<br />
Hanterar kompetensgrupper såsom:<br />
• Visa kompetensgrupp och dess medlemmar.<br />
• Lägg till och ta bort medlemmar från en grupp.<br />
Sökning (CSearch)<br />
Här finns alla de metoder som behövs för att kunna söka i systemet såsom:<br />
• Kommaseparerad fritextsökning på kompetensnamn. Namn och nivåer returneras på<br />
de som matchar sökningen.<br />
• Projektspecifik sökning. Ett antal av systemets inlagda kompetenser kryssas i och<br />
resultatet visar de personer som bäst matchar sökningen med matchningsgrad i<br />
procent.<br />
Analys (CAnalysis)<br />
Innehåller metoder som behövs för kompetensanalys, dvs. utvecklingshistorik och<br />
kompetenscirkel såsom:<br />
• Summa önskad- och nuvarande nivå per kategori och specificerad kompetens<br />
• Summa önskad- och nuvarande nivå per angiven resultatenhet<br />
• Summa kompetensnivå för ett givet år<br />
• Summa kompetensnivå för en viss kategori<br />
samt kompetens ett givet år<br />
4.2.3 Databaskonstruktion<br />
Arbetet med databasmodellen i figur 4.19 har pågått parallellt med logikdesignen och<br />
reviderats under projektets gång. Alla SQL-frågor hanteras av lagrade procedurer i databasen.<br />
Peter Lorenz 38(47)
Kompetenssystem<br />
Figur 4.19: Databasmodellen<br />
Peter Lorenz 39(47)
Kompetenssystem<br />
4.2.4 Inloggning och autentisering av användare<br />
Ett viktigt krav på systemet är det som kallas single sign-on, se avsnitt 3.1. Detta betyder att<br />
användaren av systemet inte skall behöva gå igenom mer än ett inloggningsförfarande.<br />
Autentisering av användaren påbörjas i filen Start.aspx. De olika momenten visas i figur 4.20.<br />
Användarens windowsinloggningsid hämtas från User.Identity.Name (se avsnitt 3.6).<br />
Hos Meteorit består detta ID av första bokstaven i förnamnet följt av de två första i<br />
efternamnet.<br />
Från Active Directory hämtas med hjälp av detta ID personens fullständiga namn samt<br />
information om personen tillhör administrationsgruppen eller ej. Om användaren inte finns i<br />
AD avslutas körningen med ett felmeddelande.<br />
Namnet används sedan för uppslag i Kompetensiadatabasen där det kontrolleras om<br />
användaren har ett konto eller ej. Finns inget konto skapas ett nytt och applikationen startar.<br />
Finns i Kompetensias<br />
databas<br />
Kompetensia<br />
Start<br />
HttpContext.Current.User.Identity.Name<br />
Active<br />
Directory<br />
Finns i AD Finns ej i AD<br />
Kompetensia<br />
Databas<br />
Finns ej i Kompetensias databas<br />
Lägg till ny användare<br />
Figur 4.20: Inloggningsförfarande<br />
Peter Lorenz 40(47)
Kompetenssystem<br />
5 Jämförelse av RUP, Extreme Programming och TPFD<br />
Avsnittet ger en översikt av två andra utvecklingsmetoder som hade kunnat tillämpats under<br />
projektets gång istället för RUP.<br />
Till grund för jämförelsen av metoderna i kapitlets sammanfattning ligger de erfarenheter av<br />
RUP som examensarbetet givit, tillsammans med litteraturstudier om TPFD-metoden<br />
(TestPlan Före Design) och XP (Extreme Programming).<br />
5.1 XP<br />
XP är uppbyggt av ett antal regler. Jämfört med RUP, där man kan konfigurera och använda<br />
de delar man har behov av, måste man i XP tillämpa samtliga regler för att metoden skall<br />
fungera. Varje regel utgör en kedjelänk, se figur 5.1. Tas en länk bort havererar hela idén med<br />
XP.<br />
Figur 5.1: XP-kedjans regler<br />
Regel 1 – User stories<br />
Projektet drar igång utan att specificera några detaljerade krav på produkten, förutom några<br />
kortfattade så kallade user stories, författade på enkla berättarkort. De är skrivna av kunden<br />
och beskriver vad systemet skall göra. Det som skiljer dessa från RUPs användningsfall och<br />
TPFDs användarkrav är detaljrikedommen. I XP är denna endast tillräcklig för att grovt<br />
bestämma implementationstiden. När det är dags att implementera en user story träffas<br />
utvecklarna och kunden för en muntlig detaljerad beskrivning av funktionerna.<br />
Regel 2 – Konstant omstrukturering<br />
Eftersom det inte finns någon detaljspecifikation av kraven, finns inte heller möjlighet att ta<br />
fram någon design- och systemspecifikation innan implementation påbörjas. Det betyder att<br />
systemdesignen kommer att ändras flera gånger under projektets gång. Detta tillåts dock och<br />
anses säkert så länge koden ständigt omstruktureras. Även i RUP och TPFD är<br />
omstrukturering ett välkommet inslag men då endast för att kontrollera och förbättra en redan<br />
framtagen design och inte alls lika omfattande som i XP.<br />
Regel 3 – Automatiserade enhets- och integrationstester<br />
Det är känt att omstrukturering av kod kan medföra att fler fel byggs in i koden, då viktiga<br />
data kanske flyttas eller tas bort. Detta förebyggs i XP av ständiga och utförliga enhetstester.<br />
Dock kommer dessa tester enbart att avslöja fel i koden och inte fel man infört som påverkar<br />
Peter Lorenz 41(47)
Kompetenssystem<br />
systemets övergripande design. Kom ihåg att någon designspecifikation inte finns att tillgå,<br />
därför förespråkar XP att integrationstester utföras dagligen.<br />
Regel 4 – Parprogrammering<br />
För att ytterligare förhindra fel i systemdesignen tillämpas i XP parprogrammering. Den som<br />
för tillfället inte programmerar kan då kontrollera så att de omstruktureringar som görs inte<br />
påverkar integrationen med systemets övriga delar.<br />
Regel 5 – Användare<br />
Eftersom det inte finns någon utförlig dokumenterad specifikation av projektet används en<br />
”riktig användare” som programmerarnas bollplank. Denne kundrepresentant får fungera som<br />
”detaljkrav” under hela projektets gång och därför behövs inga detaljerade och<br />
dokumenterade krav.<br />
I den ursprungliga handledningen (Beck, 1999) hävdar Kent Beck, en av XPs tre grundare, att<br />
en kundrepresentant skall finnas tillgänglig för utvecklingsteamet 40 timmar i veckan. Det<br />
bästa är att helt enkelt knyta henne/honom till projektgruppen.<br />
Kritikerna hävdar att det är alltför kostsamt för kunden att avvara en anställd till projektet så<br />
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<br />
en anställd för att bidra till utvecklingen av ett väl fungerande system, då kanske systemet inte<br />
ska införskaffas alls (Beck, 1999).<br />
Sedan 1999 har denna kundroll förändrats och idag är det inte längre en person utan snarare<br />
ett team av kundrepresentanter som håller ständig kontakt med utvecklingsteamet, utan att för<br />
den skull behöva sitta i samma rum som programmerarna.<br />
5.2 TPFD<br />
TPFD är en utvecklingsmetod som lärs ut i kursen Programvaruutveckling och<br />
Projekthantering vid <strong>Örebro</strong> Universitet, Institutionen för Teknik. Den är framtagen av Håkan<br />
Lindegren och är lämplig att användas till små- eller delar av ett större projekt.<br />
TPFD står för TestPlan Före Design och tanken är att lära sig så mycket som möjligt om det<br />
system som skall byggas innan implementationsfasen påbörjas, dvs raka motsatsen till vad XP<br />
förespråkar.<br />
TPFD är en inkrementell metod där ett inkrement består av fyra delprocesser, se figur 5.2.<br />
Egentligen är det en omskrivning av vattenfallsmodellen, som beskrevs i avsnitt 3.2.2.<br />
Lindegren (2003, s. 369) hävdar att modellen fungerar; bara inkrementen hålls korta.<br />
Rekommenderad maxlängd på ett inkrement är 26 veckor.<br />
Figur 5.2: RGKU-modellen<br />
Peter Lorenz 42(47)
Kompetenssystem<br />
Varje delprocess innehåller ett antal aktiviteter som skall utföras, se figur 5.3.<br />
Under R-processen dokumenteras grundligt systemets funktionalitet genom dokumenten<br />
användarkrav och detaljkrav. En testplan utvecklas redan i denna process utifrån det som står<br />
i detaljkraven och ett konfigurationsdokument tas fram.<br />
I G-processen utvecklas en designspecifikation som skall ligga till grund för systemets<br />
implementation. Indata blir detaljkrav och testplan och vid processens slut skall en färdig<br />
produkt finnas för test- och felrättning. Dokument med en sammanställning av återstående<br />
problem samt ändringslogg skall också vara ett resultat av G-processen. I ändringsloggen<br />
läggs de förslag till ändringar som kommer in efter det att ett dokument stängts, dvs. godkänts<br />
av granskaren.<br />
Figur 5.3: Aktiviteter i TPFD-metoden<br />
K-processen syftar till att uppdatera dokument och verifiera produkten. Test- och felrättning<br />
påbörjas och resultatet från processen skall vara en väl fungerande produkt och en ordnad<br />
dokumentation.<br />
U-processen tillhandahåller aktiviteter för att hantera utgåvor, dvs. paketera produkt och<br />
utvecklingsmiljö. I denna process spelar konfigurationsdokumentet en betydande roll.<br />
Peter Lorenz 43(47)
Kompetenssystem<br />
5.3 RUP<br />
Se Avsnitt 3.2.3<br />
5.4 Artefaktmängd<br />
Meningen med tabell 5.1 är att belysa skillnaden i mängden dokument och artefakter. I RUP<br />
används ordet artefakt eftersom det inte bara rör sig om dokument, utan även modeller av<br />
olika slag. En del RUP-artefakter har medvetet utelämnats.<br />
TPFD RUP XP<br />
Användarkrav Vision<br />
Stakeholder Requests<br />
Requirements Management Plan<br />
Use case<br />
Use case model<br />
User stories<br />
Detaljkrav Detailed use case Referensgrupp<br />
Designspecifikation Software requirements<br />
Software Architecture Document<br />
Design models<br />
User-Interface Prototype<br />
Spike 1<br />
Testplan Testplan<br />
Test Case<br />
Test Model<br />
Workload Analysis Document<br />
Automatiserat testsystem.<br />
Test och felrättning Test Evaluation Summary<br />
Test Results<br />
Hantera utgåvor Deployment Plan<br />
Installation Artifacts<br />
Training Materials<br />
End-User Support Material<br />
Konfigurationsdokument Development Infrastructure Mjukvarubaserat<br />
Configuration Management Plan<br />
Configuration Audit Findings<br />
versionshanteringssystem<br />
Terminologi Glossary<br />
1<br />
Spike är en prototyp. För att räta ut frågetecken kring en viss teknisk design, avsätter man en eller två personer<br />
för att prototypa en lösning som sedan kastas bort.<br />
Tabell 5.1: Översikt dokument/artefaktmängd<br />
Beck och Lindegren har bland många insett betydelsen med att ”skala ner” RUP på ett sätt<br />
som gör metodiken enklare att praktisera. TPFD-metoden skalar emellertid inte ner lika<br />
radikalt som vad XP gör.<br />
5.5 Sammanfattning<br />
Extreme programming har vunnit mycket mark på senare år. Samtidigt som dess popularitet<br />
ökar, hoppar fler och fler företag på XP-tåget utan att egentligen ha grepp om vad XP innebär.<br />
Detta har bidragit till att göra XP till den mest missförstådda filosofin bland utvecklingsfolket.<br />
Peter Lorenz 44(47)
Kompetenssystem<br />
Det som bidrar till att många företag tar till sig XP är att de tror sig kunna spara tid och<br />
pengar genom att inte behöva faser av kravanalys och systemdesign, utan direkt starta med<br />
implementation. Att sedan omstrukturera kod är inte heller nödvändigt; det som är skrivet<br />
fungerar ju! Självklart är inte detta rätt sätt att driva ett XP projekt.<br />
XP har även fått utstå mycket kritik för att vara för ytlig utan tillräckligt tydliga riktlinjer. Det<br />
påståendet är felaktigt, då det i XP väl framgår vilka aktiviteter som måste finnas med. Det är<br />
minst lika enkelt för de anställda vid ett företag att förvirra sig i RUPs alla artefakter.<br />
XP bygger egentligen också bara på sunt förnuft såsom kommunikation, enkelhet, feedback<br />
och ett visst mod, saker som borde vara självklara i alla typer av projekt.<br />
Styrkan hos TPFD är att den egentligen innehåller allt som RUP gör, fast i en skepnad som<br />
gör det möjligt att direkt tillämpa den på små projekt med 2-6 projektmedlemmar. Den är<br />
också utmärkt att använda i studiesyfte för utvecklare som aldrig tidigare varit i kontakt med<br />
någon annan metod<br />
Peter Lorenz 45(47)
Kompetenssystem<br />
6 Diskussion<br />
Allt fler företag har kommit till insikt om att medarbetarnas kompetens är en färskvara som<br />
ständigt måste underhållas. Detta gäller inte minst inom IT-branschen där det ständigt<br />
lanseras nya produkter och versioner.<br />
Ett datoriserat verktyg är ett utmärkt hjälpmedel för att effektivt strukturera och följa upp<br />
kompetensutvecklingen på företaget. Kompetensia innehåller alla de delar som krävs för<br />
detta, allt enligt den utvecklingsprocess som beskrevs i avsnitt 3.9. Varje enskild individ<br />
måste dock ta sitt ansvar för sin egen utveckling på samma sätt som företagsledningen måste<br />
tillhandahålla de medel som krävs för detta.<br />
Arbetet med Kompetensia påbörjades i januari 2004 och har pågått i 18 veckor. Resterande<br />
två veckor har använts till rapportskrivning och dokumentation av systemet. RUP har visat sig<br />
fungera utmärkt som stöd även för enmansprojekt som detta.<br />
Microsofts ASP.NET utgör tillsammans med utvecklingsmiljön Visual Studio.NET ett<br />
mycket kraftfullt verktyg för webbutveckling. Ett alternativ till Microsofts produkter hade<br />
varit att utveckla systemet i PHP och använt sig av open source-databasen MySQL.<br />
Utvecklingstiden hade då kortats något, eftersom erfarenhet av PHP/MySQL redan fanns, till<br />
skillnad från ASP.NET.<br />
Det som kan förbättras till nästa version av Kompetensia är stöd för att koppla kompetensmål<br />
till kompetensinventeringen. I denna version 1.0 krävs det att man manuellt går in och<br />
inventerar sin kompetens, dvs höjer nuvarande nivån i samband med att man uppnått ett<br />
kompetensmål.<br />
Även stödet för kompetensgrupper kan förbättras. Idag finns redan utförlig information om<br />
gruppernas medlemmar och aktiviteter på Meteorits intranät. I version 2.0 av Kompetensia<br />
skulle denna information kunna integreras med systemet.<br />
Peter Lorenz 46(47)
Kompetenssystem<br />
7 Referenser<br />
Advantum (2004). Strategisk kompetensutveckling. [Elektroniskt]<br />
Tillgänglig: http://www.advantum.se/pdf/Strategisk_kompetensutveckling.pdf [2004-05-10]<br />
Beck, Kent (1999). Extreme Programming Explained: Embrace change. Addison Wesley Professional,<br />
ISBN 02-016-164-16<br />
Brown, Keith (2003). a .net developer's guide to Windows security. [Elektroniskt]<br />
Tillgänglig: http://www.develop.com/kbrown/book/ [2004-05-15, 12:51]<br />
Brown, Keith (2002). A Tale of Three Security Contexts in ASP.NET. [Elektroniskt]<br />
Tillgänglig: http://www.devx.com/SummitDays/Article/6666/0/page/1 [2004-05-15, 12:51]<br />
Goodyear, Jonathan (2004). Use a DataReader or a DataSet?. [Elektroniskt]<br />
Tillgänglig:<br />
http://www.sdgn.nl/Default.asp?A1PID=57PDGUH&A1SID=510423200447&URL=97083PSXX<br />
[2004-05-05, 13:50]<br />
HemBudget (2003). HemBudget. [Elektroniskt]<br />
Tillgänglig: http://www.hembudget.com [2004-05-14, 14:42]<br />
IBM Rational (2004). RUP Resources. [Elektroniskt]<br />
Tillgänglig: http://www-136.ibm.com/developerworks/rational/products/rup/ [2004-05-04, 12:11]<br />
LCube AB (2002). Kompetensanalys. [Elektroniskt]<br />
Tillgänglig: http://www.lcube.se/ca.html [2004-02-02, 13:55]<br />
Lindegren, Håkan (2003). Programvaruprojekt. Studentlitteratur AB, ISBN 91-4403-110-6<br />
Lunell, Hans (2003). Fyra rundor med RUP. Studentlitteratur AB, ISBN 91-44-04210-8<br />
MSDN (2004). Microsoft.NET Framework Developer. [Elektroniskt]<br />
Tillgänglig: http://msdn.microsoft.com/netframework/technologyinfo/overview/default.aspx<br />
[2004-05-18: 10:51]<br />
MSDN Class Library (2004) .NET Framework Class Library IHttpModule Interface. [Elektroniskt]<br />
Tillgänglig:<br />
http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemWebIHttpModuleClassTopic.asp<br />
Pagina Förlags AB (2004). Paginas IT-ordbok. [Elektroniskt]<br />
Tillgänglig: http://www.pagina.se/itord/ (Snabbsökning: .net) [2004-05-10, 10:10]<br />
P&L Nordic AB (2004). CompetenceTool TM . [Elektroniskt]<br />
Tillgänglig: http://www.pol.se/competencetool/ [2004-02-10, 11:40]<br />
Riordan, Rebecca M. (2002). ADO.NET Steg för steg. Microsoft Press, ISBN 91-636-0719-0<br />
Tallung, Peter (2003). Hög tid att överge vattenfallstänkandet. [Elektroniskt]<br />
Tillgänglig: http://www.kentor.se/sv/press_2002/tallungs/030904_hogtid.asp [2004-05-05, 17:32]<br />
Victorin, Joakim (2004). Utbildning RUP, PMM, Kravhantering. [Elektroniskt] Meteorit AB<br />
Tillgänglig: Meteorit AB [2004-05-10]<br />
Wilson-Welsh, Patrick (2003). The Waterfall Approach: Deadly and Dying. [Elektroniskt]<br />
Tillgänglig: http://www.adaptionsoft.com/adios_waterfall.html [2004-05-18, 19:47]<br />
Peter Lorenz 47(47)