Vikar og lønsystem for ITemp

Transkript

1 Tietgenskolen 12. november Datamatiker: Hovedopgaven. Gruppe 7 5. semester Hovedopgaven: Vikar og lønsystem for ITemp Rapporten er udarbejdet af: Virksomhed: Daniel Damkjær ITemp vikarbureau Kasper Sørensen Peter Skov-Madsen Vejleder: Ulla Juul Christensen

2 F ORORD Dette er hovedopgaven for gruppe 7 på datamatiker uddannelse på TietgenSkolen i året Vi har været 3 personer, der i tre måneder har arbejdet på projektet. Rapporten er den skriftlige del af opgavebesvarelsen, men der er også CD med kode, dokumentation samt website på unoeuro, vil blive opdateret efter rapporten er afleveret. Vi vil gerne vores vejleder Ulla for den opbakning og hjælp vi har modtaget fra hende i løbet af projektperioden Vi vil ligeledes rette stor tak til tak til både Jan og Alex fra ITemp for at hjælpe os med et projekt. Vi vil også gerne sige tak for den tid de har kunnet sætte af til os og den hjælp de har ydet undervejs. ITemp har skrevet en udtalelse, som vi har medtaget i rapporten. I forbindelse med vejledermøder er der skrevet referat af møderne, som er underskrevet af gruppemedlemmer samt vejleder. Referaterne kan ses på ii

3 I NDHOLDSFORTEGNELSE Forord...ii Indholdsfortegnelse...iii Læsevejledning... 1 Abstract... 2 Projektetablering 12/8 31/8...3 Fælles beslutninger og samarbejdskontrakt... 3 Projektets læringsmål og tidsramme... 4 Om ITemp vikarbureau... 4 Interessentanalyse... 8 Interessekonflikter Risikoanalyse SWOT Konklusion vedrørende projekt og projektsituation Metodeovervejelse: Extreme Programming (XP) Faser i systemudviklingen Udviklingsværktøjer Projektstyring Turbomodel Problemformulering iteration: 31/08 24/ TortoiseSVN Navigation Database Indsættelse af postnumre i databasen Kvalitetsegenskaber og brugervenlighed Brugervenlighed Sikkerhed Sikkerhedsmodellen i ASP.NET Deployment Vedrørende deployment Membership data store Active record LINQ Implementering af linq to sql Test Testfaser kap Iteration 2 24/9 8/ Test: iteration iii

4 CSS Model View Controller (MVC) iteration: 8/10 21/ Test til iteration iteration: 21/10 4/ Elektronisk lønseddel i PDF-format Test til iteration Alternative metodemuligheder Anvendelsen af XP...55 XP Extreme programming Vores XP: Delkonklussion: Teknikker der hjælper med overblik: værdier Første iteration: Forløb, problemer og mulige beslutninger: Afslutning af iteration 1: Anden iteration: Afslutning af iteration 2: Tredje iteration Afslutning af iteration 3: Fjerde iteration: Delkonklusion: Fremtidsvisioner for systemet FURPS Konklusion...80 Bilag...81 Referat bilag Forslag til GUI Litteraturliste...87 Bøger: Artikler: Websites: iv

5 Læsevejledning Følgende begreber bruges i projektet og kræver en nærmere forklaring. XP: Extreme Programming. On-site customer: medarbejderne hos ITemp. Kunde: senior managers hos ITemp Jan Jacobsen og Alex Wilde. Centrale begreber i ASP.NET og Extreme Programming er skrevet på engelsk. En oversættelse af begreberne ville udvande betydningen. Installationsvejledning Den nyeste version af ITempSys kan ses på siden: Nedenstående skema viser, login-info til brug på websitet. Rolle Brugernavn Kodeord Administrator admin admin1234 Bruger bruger bruger1234 Anonym Der er vedlagt en cd. På denne er vores solution, rapport og bilag. Nogle af funktionerne kan kun køres direkte på webhotellet pga. unoeuro s rettigheder/indstillinger. Det er muligt at køre ITempSys Solutionen, åbne siderne og indtaste data og se validering, men det er ikke muligt at oprette vikarer, vikariater osv., da databasen på ikke tillader dette Det er muligt at åbne ITemp solution ved at åbne ITempSys mappen på cd en og åbne denne som website. 1

6 Abstract The following text describes the content of the report, for the final project, for Data mathematician at TietgenSkolen Odense, which ran from 12/8 12/ The report contains documentation for our development of the ITempSys system, developed for ITemp Vicar Bureau, which is a web based application, created with the use of ASP.NET,.NET 3.5, SQL Server manager 2008, AJAX, LINQ, ItextSharp. The main purpose of this project has been to create a system, which can be used for administrative work at ITemp, and can be used by its employees, also called substitutes, via the web to check things like salary and so. The substitutes must be able to print their pay slip in a PDF file from the webpage. There also have to be a function for generating SMS messages, to be sent to the substitutes, with information like when they have to work and so on. Our application uses MS SQL database with a technology called LINQ, which maps tables to an object and returns one row in a table as a DTO object. Much like the pattern Active Record also described later in the report. We had no knowledge of LINQ before the start of the project, and it is described later in the report. The application uses various different technologies for increasing end user experience, like for example AJAX, java script and form styling. These all help us improve the experience of the GUI, where we can customize templates and controls to customize them the way we want them. These have been documented in the report. In development of this system, we have used a development method called Extreme programming. We had not used this method before and documentation of its use is described in the report. During our project, we have used various new tools, like Tortoise and TeamViewer, to complement our development method. These are described in the report. Our conclusion to this project is that we are very happy with the result of the system so far. There however is still a lot of work to be done before we can consider this fully completed, and we look forward to working on this even after our project ends. We have learned a lot from this project, with many new features and tools. We would like to thank ITemp for giving us the chance for helping them make this system, and we will look forward to our continued work with the project. 2

7 P ROJEKTETABLERING 12/8 31/8 Gruppemedlemmerne har ikke tidligere arbejdet sammen. I løbet af studiet har vi alle gjort erfaringer med problemstillingerne vedrørende samarbejde. For bedst muligt at kunne imødegå problemstillingerne besluttede vi at oprette en projektetablering. Projektetableringen har til formål at skabe en følelse af fællesskab og fælles forpligtelse overfor projektet. I praksis blev dette gjort ved diskussioner og samtaler. Emnerne, der blev diskuteret var bl.a.: Projektdeltagernes forventninger, forudsætninger og målsætninger Hvordan projektet bliver bedre samt giver større udbytte end tidligere projekter Forslag til metoder og teknikker Opgavetyper, opgaveinteresser og opgavemuligheder For at komme videre foretog projektgruppen en række fælles beslutninger og formulerede en samarbejdskontrakt. Fælles beslutninger og samarbejdskontrakt Gruppen besluttede den 12/ følgende: At oprette en projekthåndbog At udfærdige en overordnet tidsplan At benytte sig af muligheden for projektvejledning Kasper står for projektetableringen, undersøger mulighederne for den praktiske udførsel af metoden, sætter sig ind i ASP.NET. og skriver referater af vejledermøderne Peter fungerer som projektleder. Han formulerer projektstrategien, udfører en TURBO-analyse. Holder styr på tid, estimeringer, opgaver og beskriver den valgte metode. Peter skriver referater af kundemøder Daniel undersøger mulige løsninger på programmeringstekniske problemstillinger Samarbejdskontrakt Gruppen har ikke tidligere arbejdet sammen. At formulere en samarbejdskontrakt vil kunne afklare uklarheder og misforståelser internt i gruppen. Reglerne for projektet er: Med hensyn til projektdagbog er der valgfrihed Der anvendes en opgavetavle med tre tabeller. En til aktuelle, en til igangværende samt en tabel til ting, der skal gennemgås i fællesskab Der arbejdes på projektet i alle ugedage og holder fri i weekenderne. Opstår der problemer i en weekend kan dette først tages op om mandagen. I slutfasen kan det blive nødvendigt eventuelt også at arbejde i weekenden Personen, der har nøglen til lokalet skal møde til tiden eller oplyse de andre om forsinkelse Dagen før et vejledermøde mailes en dagsorden til vejleder indeholdende kode og materiale Under vejledningsmøde skrives mødereferat. Mødereferatet underskrives af gruppens medlemmer samt vejleder 3

8 Undervejs i projektet skal der være mulighed for at bytte roller/områder, hvis dette ønskes Projektets læringsmål og tidsramme Efter at have truffet fælles beslutninger og udfærdiget en samarbejdskontrakt formulerede projektgruppen de fælles læringsmål. Læringsmålene blev senere en del af kontrakten, der blev indgået mellem projektgruppen, TietgenSkolen og ITemp. Den godkendte kontrakt omfatter følgende læringsmål: Gå i dybden med ASP.NET Få mere kodeerfaring Anvendelse af ASP.NET membership databasen Undersøge LINQ med henblik på vurdering, og kort beskrivelse af denne Anvende AJAX Inddrage testning og brugervenlighed Projektets tidsramme Begivenhed Tidselement Projektstart 12/ Dage Tid i projektperioden Timer 92 Lørdage 13 Søndage 13 Aktivitetsdage 4 Total tid til rådighed 1 udvikler Total tid til rådighed 3 udviklere Aflevering 12/ Eksamen 26/ Tabel 1: Tidsrammen for hovedopgaven Tabel 1 udfærdiges med henblik på at give overblik over projektets overordnede tidsramme og milepæle. Senere kan den eventuelt danne basis for diverse estimeringer. Ifølge planen arbejdes der kun på hverdage. En arbejdsdag sættes til 5 timer. Dette gøres for at have lidt at give af. En arbejdsdag kan forlænges ydermere kan lørdage og søndage tages i brug i projektets slutfase, hvis der skulle opstå tidsmangel eller større problemer. O M IT EMP VIKARBUREAU Vikarbureauet ITemp blev grundlagt for 8 år siden af Jan Jacobsen og hans forretningspartner. Jan Jacobsen er i dag indehaveren, og har yderligere en ansat Alex Wilde. 4

9 Bureauet har kontorer i Fredericia og Odense. På nuværende tidspunkt har ITemp 100 aktive vikarer, der arbejder indenfor industri, produktion, gartneri, kontor og kantine. I Odense omfatter kunderne bl.a. Alex Andersen, Flora Deco, Kuehne + Nagel. Den største er Bøg Madsen, der dagligt bruger flere vikarer. Den geografiske spredning giver mulighed for at dække hele trekantsområdet. I Fredericia er der på nuværende tidspunkt stort set ingen aktivitet. På trods af den manglende aktivitet i Fredericia har beholdes afdelingen af følgende grunde: Det kan ikke svare sig at nedlægge afdelingen rent økonomisk På grund af opsvinget opstod en masse vikarbureauer, der konkurrerede på prisen. Krisen har fået de fleste vikarbureauer til igen at dreje nøglen om, mens andre har negativ egenkapital. Planen på lang sigt er at starte op for alvor i Fredericia, hvor hovedområderne vil være kontor og administration. Forretningssituationen Beskrivelsen af forretningsituationen laves med henblik for at opnå større forståelse for ITemp. Fokus er derfor på ITemp og ikke projektgruppen. Missionen beskriver, hvad ITemp gør her hvilke behov ITemp dækker. Visionen beskriver, hvad der ønskes opnået. Mål og strategier beskriver, hvordan målene forsøges opnået hvad ITemp er villige til at gøre. Mission Levere vikarløsninger, hvor den enkelte vikar selv har mulighed for at bestemme, hvor, hvornår og hvor mange vikariater der skal tages Efterlevelse af try and hire princippet: virksomhed og vikar kan lære hinanden at kende samt se hinanden an inden en eventuel fastansættelse Være fleksible. Kunne tilbyde vikarløsninger både når der er tale om et enkelt vikariat, flere vikariater eller vikariater, der strækker sig over en længere tid. Tilbyde ordnede forhold. Virksomhederne overholder gældende overenskomster, så vikarerne arbejder under samme vilkår som de fastansatte Vision Være kvalitetsbevidste. Der tages løbende imod tilbagemeldinger fra kunder og vikarer med henblik på at forbedre kvaliteten og tilfredsheden hos begge parter At være professionelle. Efter telefonisk interview inviteres alle til en personlig samtale med personalekonsulenten. Her klarlægges vikarens ønsker og erfaringer med henblik på vurdering af om arbejdsopgaverne matcher disse At levere hurtig og ærlig tilbagemelding til alle parter At være relationsskabende. Der bruges ressourcer på vedligeholdelse af tæt kontakt til vikarer samt kunder gennem telefoniske samtale og møder Mål og strategi Udnytte krisen i branchen og de mange lukninger ved at starte afdelingen i Fredericia op. Dette er muligt, da ITemp, hverken har negativ egenkapital eller store udgifter til leasing af IT, biler osv. Tilbyde franchise 5

10 Figur 1: Det nuværende "system" PROMARK Hos Bøg Madsen logger vikaren ind og angiver mødetidspunktet. Ved endt vikariat angives sluttidspunkt, og der udfyldes en timeseddel, som underskrives. Dataløn Multidata a/s Når der skal udbetales løn sendes en csv-fil til Jan Jacobsen, som kører denne igennem en Access database. Er der blanke felter i csv-filen anvendes den føromtalte lønseddel, som kontrol. Værdierne fra csv-filen læses ind i et lønmodul, som sørger for beregning af løn og udbetaling. Vikar databasen ITemp har en intern vikardatabase. Firmaet, der har udviklet denne er gået konkurs flere gange. Ifølge Jan er programmet ikke færdigt. Der er flere steder, hvor knapperne ikke virker, og funktionaliteten helt mangler eller mangelfuld. C5 lønmodul I Temp råder også over et C5 lønmodul. Dette tager ifølge Jan for lang tid, og kan kun betale sig, hvis ITemp vokser yderligere. Modulet bruges på nuværende tidspunkt ikke. Brugerkarakteristikker At starte et projekt med brugerkarakteristikker kan være en dårlig ide, da ikke alle er motiverede for emnet, andre tror fejlagtigt de kender målgruppen uden egentlig at gøre det. 6

11 Gruppen er motiverede for at fokusere på brugervenlighed, hvilket eliminerer problemet. Senere i rapporten beskrives, hvad brugervenlighed er. Hvorfor brugervenlighed er en god ide samt fordel. For nu anvendes brugerkarakteristikkerne som led i forståelse af ITemp, og hvordan systemet skal virke. Rolf Molich angiver i bogen Brugervenligt webdesign det han kalder De fem gyldne regler. Ved efterlevelse af punkterne bliver resultatet et brugervenligt system. Reglerne er: Kend dine brugere Inddrag dine brugere Test og ret designet Lær af andre Reglerne 1 og 2 særligt interessante. Reglerne siger man skal observere brugerne, lave interviews med henblik på forudsætninger, holdninger og forventninger. De skal desuden inddrages i udviklingen. Projektgruppen begyndte på dette allerede under første kundemøde, og har løbende opdateret brugerkarakteristikkerne. De følgende brugerkarakteristikker Beskrivelsen af, hvem der skal bruge systemet giver overblik, ideer og forståelse alt sammen ting der giver et bedre og mere brugervenligt system. Brugerbeskrivelserne for systemet består af fire brugerkarakteristikker. Brugerkarakteristikkerne beskriver tilsammen alle personerne, der skal anvende systemet. På grund af prioriteringer har vi overladt til Jan Jacobsen og Alex at beskrive brugerkarakteristikkerne for vikar og anonym. Dette harmonerer fint med XP s on-site customer. On-site customer er den person, som udviklerne henvender sig til for at få info om funktionelle og ikke funktionelle krav. Jan Jacobsen indehaveren af ITemp Jan Jacobsen er 36 år og indehaver af ITemp. Han startede det for 8 år siden med en kammerat, som nu har forladt projektet til fordel for arbejde hos Multidata a/s. Jan står for kontakt til kunderne angående det rent forretningsmæssige. Han tager sig af IT og selve strategien og ledelsen af vikarbureauet. I de perioder, hvor Alex ikke er til stede udfører han også Alex s opgaver. Jan er oprindelig uddannet som svagstrømsingeniør. I forbindelse med studiet har han stiftet bekendtskab med IT, hvilket hurtigt blev hans store interesse. Han kan lide at gøre tingene selv, og eksperimentere med tingene. Han kender til begreber som CSS, php og database. Han hoster selv sit site, har selv sat server op, og eksperimenterer med diverse konfigurationer. Han foretrækker Linux, og går ikke så meget op i brugergrænsefladen det der tæller er mere at det er gratis. Jan har aldrig forstået Microsofts filosofi eller måde at udvikle på, og mener det er et problem at alting altid skal koste noget. Alex Wilde afdelingsleder i Odense Alex Wilde er 35 år, uddannet psykolog og oprindelig fra England. Han bor i Danmark på grund af dansk kæreste. Han har arbejdet for ITemp i omkring to et halvt år inden Jan ansatte ham som personalekonsulent. Som personalekonsulent står han bl.a. for interview af nye vikarer og kontakt med kunderne vedrørende vikarer og de daglige vikariater. Alex ved hvad Google er, han ved hvad Yahoo er, men står af når der tales om flash, JavaScript eller CSS. Han omtaler Jan Jacobsen som den der står for IT, og går ikke så meget op i det. Spørger man ham om de har trådløs forbindelse er han ikke den, der kan svare på det. 7

12 Vikar En vikar er typisk mellem år, men kan i få tilfælde være lidt ældre. Vikaren har været til personlig samtale, og vurderet som egnet til ITemps arbejdsopgaver. En vikar har fået demonstreret, hvordan en timeseddel udfyldes, og er blevet oprettet i vikardatabasen af Jan eller Alex. Ved oprettelse tildeles vikaren et brugernavn, og instrueres i hvordan han logger på. Anonym En anonym bruger er en person, der har fundet ITemp via nettet eller som opsøger hjemmesiden efter at have hørt om ITemp via en anden part. Det er sjældent en vikar opsøger ITemp på baggrund af en søgning på nettet. Som regel er det fordi han har hørt om det via en vikar, eller en som kender en, der arbejder for ITemp. Interessentanalyse Et udviklingsprojekt har altid flere interessenter. For at sikre gennemførelse at et projekt er det en god ide at foretage en interessentanalyse i den indledende fase. Om interessenter skriver Poul StaalVinje i bogen Projektledelse af systemudvikling, at de. : påvirkes af projektet, enten af projektets produkter når de tages i brug, eller af projektforløbet der leder frem til det 1 Interessentanalysen er et internt papir der udfærdiges af projektlederen. Interessentanalyse vurderer om projektet er muligt at gennemføre. Den bruges desuden til at spotte potentielle konflikter imellem interessenterne, og angiver hvordan disse afhjælpes. Projektsituationen i forbindelse med hovedopgaven indeholder følgende elementer: Kunde: ITemp vikarbureau. Virksomhed: medlemmerne af projektgruppe 7 (Daniel, Kasper og Peter). Ydelserne: analyse, basal styling, softwaredesign og softwarekonstruktion med udgangspunkt i ITemps ønsker. 8 1 Projektledelse af systemudvikling s. 73.

13 Interessent Jan ITemp Succeskriterier Få indblik i C# og ASP.Net. Forståelse for Microsofts produkter. Får tilfredsstillet sin nysgerrighed. Inspiration. Alex ITemp Krav til systemegenskaber Krav til projektegenskaber Indsigt i processen. Brugervenligt. Inspiration. Mulighed for Interesse i software. udvidelse. Basal styling af vikar- Bidrag Tid til test og interview. Virkeligt problem. Viden om delen. virksomheden og Gratis platform php, kunderne. Linux og mysql. Aflastning. Tid til test og Mere tid. interview. Viden om vikarer og vikarsituationen. Vejleder - Ulla Evaluering. Niveausikring. Rykker. Ny funktionalitet. Nye områder og Overholdelse af deadline. Gruppen lærer at løsninger. samarbejde. Læringsprocessen. Ideer, input og feedback. Overblik og erfaring. Konsulentbistand vedr. kodning. TietgenSkolen Procesdokumentation. Produktdokumentation Evaluering. Niveausikring. God proces og løsninger. Anvendelse af Dokumentation og kode. Overholdelse af deadline. Demonstration af System. Demonstration af Stiller faciliteterne til rådighed på skolen. samarbejde. Indsigt i Demonstration af udviklingsprocessen. færdigheder. færdigheder. Lære nye færdigheder. NØGLEINTERESSENTER: Daniel LINQ. Model View Controller. Genbrugbarhed. Systemdesign. og brugervenlighed. Nye emner og områder Fællesskab og mht. kodning. Dokumentation. Projektmodel. Kodning. Kode frem for design Transaction Scripting. Peter Design patterns samarbejde. Brugervenlighed. Fællesskab og Kundens ønsker. samarbejde. SUM. Projektstyring. Strategi og projektstyring. Kasper Styling: CSS og HTML. Model View Controller. Dokumentation. Systemudvikling. Brugervenlighed. Test og brugertest. Basal funktionalitet. Procesorienteret. Grundighed. Fællesskab og samarbejde. Procesorienteret: fremdrift og helheden. SUM. Styling. 9

14 En sidegevinst ved interessentanalysen i den aktuelle projektsituation er, at den giver overblik over hvilke områder, der er kompetencer indenfor og dermed også hvilke områder hovedopgaven kan omfatte samt ideer til fordeling af roller og ansvarsområder. Interessekonflikter Interessentanalysen angiver, hvordan interessekonflikter skal undgås. Ved at fokusere på disse punkter sikrer man gennemførslen af projektet, og undgår situationer, hvor projektet er vanskeligt eller måske helt umuligt at gennemføre. ITemp og projektgruppen Indehaveren af ITemp kan godt lide at arbejde med tingene selv, og har udtrykt han ikke altid forstår Microsofts løsninger, samt at de altid koster mange penge. Indehaveren foretrækker Linux, php og mysql, men samtidig med dette er indehaveren nysgerrig og synes projektet virker spændende. Han kan lide muligheden for at få indblik i Microsofts teknologi samt inspiration. At kunden på den ene side ønsker et færdigt system med specifik funktionalitet, og på den anden side danner grundlag for en projektopgave kan give konflikter. Ikke alle ønsker kan opfyldes enten på grund af tidsmangel eller manglende færdigheder. Ved emnet gøres opmærksom på følgende muligheder: At problemstillingen er blevet analyseret og eventuelt kan videregives til et andet firma At systemet kan færdiggøres i fritiden, eller udbygges ved et senere projekt Projektet kan inddrage nogle af kundens foretrukne teknologier eller f.eks. en SMS Gateway ITemp og TietgenSkolen ITemp vil selvfølgelig gerne have lavet et færdigt og fuldt funktionelt system, og ser helst projektgruppen fokuserer på software frem for dokumentation. Inden projektstart har kunden underskrevet en kontrakt, og er derfor klar over omstændighederne at målet med projektet er et produkt samt dokumentation. TietgenSkolen betragtes som hovedinteressant, da denne har den ultimative sanktionsmulighed. Opstår en konflikt med kunden sent i projektforløbet kan samarbejdet eventuelt opsiges. Der vil være materiale nok til at færdiggøre projektet. Ved konflikter diskuteres problemstillingen med vejleder og TietgenSkolen. Af dokumentet Rammer om hovedopgaveforløbet på DMU på TietgenSkolen fremgår det, som anført i interessantanalysen, at der både kræves proces- og produktdokumentation. Dette kan ved en metode som XP gøre det vanskeligt at følge metoden helt. XP fokuserer på at levere kode, der virker og som er gennemtestet. Dette sker på bekostning af dokumentation. Projektgruppen og TietgenSkolen/vejleder Projektgruppen kan have ønske om at fokusere kun på kode, men da der er valgt et proces-projekt frem for et produkt-projekt er beskrivelse af processen specielt vigtigt. Som ovenover har det første prioritet at overholde opgavebeskrivelsen, og få godkendt alle afvigelser fra denne. 10

15 Risikoanalyse Følgende risikoanalysen forsøge at identificere, hvilke risici projektet udføres under. S = Sandsynlighed 1 = Der vil sandsynligvis ikke ske, men det er dog muligt. 2 = Der 50/50 for der sker noget. 3 = De vil sandsynlig ske. K = Konsekvens 1 = Konsekvensen kan opsuges med planens nuværende aktiviteter. 3 = Der skal gøres noget for at bøde for konsekvensen. 10 = Planen skrider, hvis dette sker. P = Sandsynlighed x Konsekvens = S x K Resultatbehandling Risici på 9 eller mere antyder behov for handling og resten vurderes. Når der er ressourcer skal forebygning ske. En høj S og K giver anledning til præventive aktiviteter. En lav sandsynlighed peger på behov for beredskab. Høj sandsynlighed, men lav konsekvens = beredskab. Risici S K P Mulige foranstaltninger Kunden trækker sig (konkurs, travlhed osv.) Vi gør projekter færdig som om, at kontaktpersonen har været med fra starten Defekt bærbar Vi finder en ertatningspc i stedet for den manglende bærbar eller låner en stationær af TietgenSkolen Kort sygdomsperiode projektgruppen Der omprioriteres eller arbejdes over. Længevarende sygdom projektgruppen De andre i gruppen overtager byrden. Kort sygdomsperiode - vejleder Vi finder et andet tidspunkt eller spørger en anden lærer. Længevarende sygdom vejleder Snakker med skolen og finder en anden vejleder og omprioritering. Dårlig motivation Lave faste start og sluttidspunkter på dagen. Minimere mulighederne for undskyldninger. Lave noget nemt og samarbejde med et andet gruppemedlem. Problemer med hosting Venter til fejlen er rettet eller finder nyt firma. Manglende ressourcer til test Teste de vigtige dele i kravspecifikationen først Ventetid ifb. test Arbejde på dokumentation, rapport eller finpudse. Ændringer i dialogstandard Skrive fejlrapport og få indført standard. Projektforløb Minimumsmodellen 11

16 Sygdom er forhold man ikke kan gardere sig imod uanset projekt. Den store risiko er at kunden trækker sig. Foranstaltningerne, der skal tages i denne situation er beskrevet i interessentanalysen. SWOT SWOT er et akronym og står for strengths, weaknesses, opportunities og threats. En SWOT udvikles på baggrund af en risikoanalyse og udvider denne. Den identificerer flere trusler, men angiver ligeledes handlinger, der skal minimere eller helt eliminere disse. Analysen laves her med henblik på at afdække projektgruppens situation. Den tager udgangspunkt i situationen som den er for projektgruppen i det øjeblik SWOT-analysen udføres. Strengths og weaknesses går på de interne forhold i projektgruppen. Opportunities og threats beskæftiger sig med ydre faktorer. Strengths Motiverede. Samme ambitionsniveau. Både SUM og programmerings interesse. Opportunities Lære nye færdigheder. Weaknesses Manglende erfaring. Ukendt metode. Ukendt opgave. Ingen estimeringserfaring. Threats Krav til tid og formalia. Indsigt I virkelig problemstilling. Svar på spørgsmål. Afprøve teorier. Efter analysen vurderes projektsituationen ved at holde svaghederne og truslerne op imod styrker og muligheder. Styrkerne angiver muligheder til at tackle svaghederne. Mulighederne skal opveje truslerne mulighederne skal give lyst til at tackle truslerne. K ONKLUSION VEDRØRENDE PROJEKT OG PROJEKTSITUATION Der er nu udført interessentanalyse, risikoanalyse samt SWOT-analyse. Alle tre belyser hver deres område vedrørende projektet. Det nu muligt at vurdere, hvorvidt det er realistisk at fortsætte projektet på nuværende grundlag. Interessentanalysen viser der er interessekonflikter mellem ITemp, der vil have funktionelt software og TietgenSkolen, der kræver proces- og produktdokumentation. Ligeledes påviser den en konflikt mellem XP og TietgenSkolen. XP fokuserer på at levere kode, og bortprioriterer dokumentation, mens TietgenSkolens rammer for opgaveforløbet kræver både procesdokumentation og produktdokumentation. På trods af konflikterne, som altid vil være i en eller anden form konkluderer vi på baggrund interessenantalysen, risikoanalysen og SWOT-analysen følgende: Sandsynligheden for interessekonflikterne vil kunne forhindre projektet er begrænset Skulle interessekonflikterne udbryde, er der tiltag der enten helt vil kunne forhindre de opstår eller kompensere derfor 12

17 Det bemærkes at risikoanalysen ligeledes angiver tiltag, der løser eventuelle problemer. Risikoen for at de omstændigheder, der kan sabotere projektet opstår, er i alle tilfælde lav. Risikoanalysen, angiver hvilke scenearier projektgruppen skal være på vagt overfor at farerne er identificeret begrænser i sig selv risikoen. SWOT-analysen stiller styrker og muligheder op imod svagheder og trusler. Opstillingen viser en vis ligevægt imellem disse. Det kan konkluderes, at der er baggrund for at fortsætte med projektet. Rammerne for projektet kræver der anvendes en metode, og at denne er ny. Metodeovervejelse: Extreme Programming (XP) Med henvisning til projektgruppens læringsmål ses det at XP passer fint med disse. Gruppen ønsker at gå i dybden med XP og få mere kodeerfaring, hvilket XP netop gør: sætter fokus på kodning, samarbejde og at man har fingrene, der hvor der sker noget. En anden iterativ metode er Larman. Efter vores mening sker det ved Larman følgende: Man bruger megen tid på dokumentation Der er mange roller flere roller end der er personer i gruppen. Resultatet er at hver person skal have flere roller Man laver diagrammer efter kodningen i stedet for først at lave diagrammer og derefter kode efter dem. Samtidig er der risiko for man bruger for megen tid på diagrammer og dokumentation læringsmålene er at blive bedre til at kode En kunde, der ikke forstår UML og andre af Larmans artefakter kan ikke bruge disse til meget. En udvikler kan ikke bruge diverse diagrammer til noget, hvis han ikke forstår dem Den megen dokumentation stemmer ikke overens med gruppens ønsker og læringsmål. Kunden ønsker dokumentation, men ikke den slags dokumentation Larman leverer. Larmans dokumentation er god til videreudvikling og vedligeholdelse, men ingen af disse punkter er relevante i projektsituationen. Ovenstående er nogle af de mere overfladiske og fornuftige argumenter for at anvende XP frem for Larman. Senere diskuteres og overvejs også Scrum og igen Larman. Projektgruppen har et fælles ønske om at anvende XP, da det er den bedste måde at vurdere og lære den på ved at bruge den i praksis. XP harmonerer også fint med læringsmålene. Vedrørende XP er det værd at bemærke følgende: Remember that XP is not an all-or-nothing proposition. You can easily adapt parts of it to match your company s culture and style.2 Selvom projektet tager udgangspunkt i XP s 12 core principles, og forsøger at følge disse åbner ovenstående citat for at man kan tilføje sine egne elementer eller også enten nedtone eller helt fjerne andre. Det samme lægger Poul Staal Vinje: XP er et resultat vi er endt op med det er ikke et koncept vi er startet med og derefter prøver at få til at virke i praksis. Det står enhver frit at prøve det samme: skriv en liste over det du, fra praksis oplever som det helt rigtige at gøre. Gør det derefter fuldt og helt, så har du din egen, private XP 3 2 IT Pro May June 2002 p

18 Det er således lovligt at bruge elementer af XP til udviklingen. Selvom gruppen forsøger at anvende så mange af XP core principles kan det være nødvendigt at fravælge nogle. Hvis dette sker skal der dog være argumenter derfor. Faser i systemudviklingen Projektgruppen har tre måneder til hovedopgaven. Groft sagt inddeles systemudvikling i følgende 7 faser: 1. Foranalyse 2. Analyse 3. Design 4. Realisering 5. Implementering 6. Forvaltning 7. Drift Hovedopgaven kommer til at dække punkterne 1 4. Udviklingsværktøjer TeamViewer 4 Figur 2: Screenshot af TeamViewer 14 3 Projektledelse af systemudvikling p. 299

19 Gruppens læringsmål og metodevalg gør gruppen har brug for at kunne hjælpe hinanden på kryds og tværs. Vi har derfor besluttet at benytte fjernskrivebordsprogrammet Teamviewer. Teamviewer fungerer lidt ligesom Windows Remote Desktop, men ved TeamViewer logges værten ikke af systemet når en gæst opretter forbindelse. Når der i TeamViewer anvendes fjernstøtte er det muligt for to udviklere at sidde med hver sin bærbare. Den ene logger på og ser den andens skærm begge parter kan skrive og slette kode i Visual Studio. TeamViewer gør det muligt at lave pair programming, men alligevel sidde foran sin egen skærm og se det fulde billede man skal ikke se fra siden af. Udover at kunne bruges som fjernstyring af en maskine, kan teamviewer også bruges som fjernpræsentation. Man streamer sit skrivebord til en anden maskine uden brugeren af denne ikke kan foretage ændringer. Teamviewer kan også bruges til at overføre filer og starte en VPN-session. De sidste to funktioner har vi ikke haft brug for, bl.a. fordi vi bruger subversion til fildeling. Bruger man TeamViewer til personlig brug er den gratis. Skype Skype er brugt til at kommunikere sammen når man sidder hjemme og arbejder. Skype er meget anvendelig når man anvender den sammen med TeamViewer. Det er muligt at kode sammen, men kombinationen er mest blevet brugt til at rette fejl, diskutere problemstillinger samt debugging. Mindjet MindManager 8 Mindjet MindManager 8 er et program til at lave brainstorm og mindmaps med. Man kan se et mindmap i bilagene. Rich pictures Rich pictures er en teknik til danne sig et visuelt overblik over en situation. Vi har brugt MS Paint til at lave rich pictures med. Microsoft Visual Studio 2008 Team Edition Microsoft SQL Server Express 2008 TortoiseSVN Gruppen har eksperimenteret med Windows Live Messenger Grupper og Windows Live Office Beta, men ingen af disse har kunne løse hverken de krav som XP stiller til continous integration, eller de generelle ønsker om backup og versionsstyring, som gruppen har. Projektstyring Elementerne, der indgår i projektstyring ses på Figur 3. I enhver projektsituation er der en afsat en mængde tid, der er ressourcer og der er kvalitet, der skal leveres. Kvaliteten kan leveres i form af dokumentation, funktionalitet eller begge dele. Kvaliteten (produktet) i hovedopgaven er kode, dokumentation af proces og produkt herunder beskrivelse af anvendelsesmuligheder med hensyn udvalgte komponenter i ASP.NET teknologien. 15

20 Funktionalitet Funktionalitet XP Vandfald Tid Ressourcer Ressourcer Tid Figur 3: Elementerne i projektstyring. Boksene angiver et fixed element. Et projekt kan leveres til tiden, det kan leveres til den aftalte pris eller det kan leveres med den aftalte funktionalitet. Alle tre ting er mulige, men ikke på en gang. Kunden skal vælge en af dem. Ved traditionel er funktionaliteten fastlagt. Man kan eventuel udskyde en deadline eller man kan skaffe flere ressourcer i form af flere udviklere. I XP variablen funktionaliteten. Er et projekt for dyrt eller forsinket er det funktionaliteten, som man vil bruge til at justere med. Dette gøres i forbindelse med the planning game. Valget af XP passer fint med projektsituationen. Vi er tre udviklere (ressourcer), har tre måneder (tid). I projektsituationen er dette elementerne, der på ingen måde kan justeres på. Som det kan ses på Figur 3 er dette også elementerne, der er fixed i XP. T URBOMODEL Formålet med at få udarbejdet en turbo model, er at finde frem til hvilken model man skal arbejde efter, og ud fra det vælge hvilken metode man vil benytte. Mål og vilkår Særlige styrker Særlige svagheder Mulige beslutninger Teknikken: Der arbejdes med.net platform, som er en godt kendt teknik, med masser af muligheder for at finde løsninger på tekniske problemer. I forhold til smart design af brugergrænseflade er VS ikke det bedste redskab. Såfremt der opstår problemer i forbindelse med teknikken, kan der søges konsulent hjælp, eller evt. findes hjælp andre steder fra, eksempelvis nettet. Lav simpelt design af brugergrænsefladen. Brugerne: Nogle brugere der har været tilknyttet virksomheden længe, kan måske være til hjælp med forslag til forskellige løsninger, eller give forslag til mangler ved det nuværende system. Virksomhedens brugere, dvs. deres vikarer, er for de flestes vedkommende meget lidt indsigt i forhold til IT. Tal med brugerne for at få overblik over de problemer de har med det nuværende system. Lav bruger tests og brug de input vi får til at lave designet endnu bedre, eller evt. tilføje funktionaliteter der kan forbedre arbejdsgangen. Udviklere: Udviklerne har gennem de sidste 2 år arbejdet med denne teknik, og har derfor et udmærket kendskab til mange af dens funktioner. Ud over det har flere af udviklerne et indgående kendskab til virksomheden og dens behov. Udviklerne vil undervejs støde på problemer de ikke har mødt før, såsom oprettelse af en SMS gateway, der kan sende beskeder til brugerne. Udviklerne har ikke meget praktisk erfaring med at arbejde ud fra visse projektmodeller, såsom agile Søg bistand hos lærere, i bøger og på nettet for at finde ud af de ting vi kunne være i tvivl om. Sørg for at planlægge godt, for at eliminere udviklernes usikkerhed. 16

21 udviklingsmetoder. Desuden er udviklerne ikke vant til at arbejde med projekter af denne størrelse. Omgivelserne Udviklerne kan koncentrere sig fuldt ud om dette projekt, da de ikke har andre opgaver i øjeblikket. Det vil ikke altid være muligt for udviklerne at komme i kontakt med virksomheden, da managers ofte har travlt. Dette kan resultere i forsinkelser, såfremt det ikke er muligt at få et møde i stand på det tidspunkt hvor udviklerne havde tænkt sig det. Sørg for at planlægge i god tid i forvejen, så det er muligt at kontakte virksomheden i så god tid at et møde kan komme i stand. Resultatet: Selve grundstenene i projektet er lige til og klart defineret. Virksomheden vil gerne have et nyt vikar/løn system, men kan ikke i alle tilfælde definere, hvordan de løsninger de ønsker, skal se ud. De ønsker at vi selv finder på løsninger ud fra de oplysninger de giver os Eksperimenter med forskellige løsninger, for at finde frem til den der bedst opfylder kundens ønsker. Visse dele af projektet kan planlægges i forvejen. Senior Manager Senior manageren har et rigtigt godt kendskab til IT. Han har selv arbejdet med at sætte alt deres IT-udstyr op selv, og har et indgående kendskab til hele opsætningen og de programmer de bruger. Han er også villigt til at investere penge i nye løsninger der kan forbedre deres arbejdsgang. Eksempelvis opsætning af en SMS gateway. Vil gerne lære noget undervejs i projektet Selvom manageren har et godt kendskab til IT, har han ikke kunne komme med input til hvordan de forskellige løsninger skal laves og har heller ikke kunne give os noget input omkring hvordan brugergrænsefladen skal udformes. Der behøver ikke eksperimenteres med forskellige teknikker, og der vil være god adgang til at få oplysninger om hvordan den tekniske opbygning skal laves. Hold tæt kontakt. Projekt strategi Begrundet i projektets særlige mål og vilkår Sammenfatning: Søg bistand hos lærere, bøger, internet og evt. eksterne konsulenter i tvivlsspørgsmål. Sørg for at lave løbende tests, som både testes af brugere og internt i virksomheden. I starten af projektet kan de ting der ikke er tvivl om laves, derefter kan der eksperimenteres med løsninger. Sørg for at holde en ordentlig planlægning, både omkring møder og omkring selve projektet. Hold konstant og tæt kontakt med kunden. 17

22 Ud fra vores sammenfatning, vil vi nu prøve at finde ud af hvilken model, der vil være den bedste at arbejde efter i dette projekt. Vi vælger at følge Andreas Munk Madsens henvisninger. Disse beskriver følgende begreber: Kompleksitet, usikkerhed, tidspres og geografisk placering. Ifølge vores sammenfatning vil vi have en vis grad af usikkerhed i projektet. Usikkerheden består i, at udviklerne er meget lidt erfarne i projekter af denne størrelse, samt i brugen af visse metoder. Vi er ikke helt sikre på, hvordan vi bedst muligt planlægger, for at sikre at tidsplanerne overholdes, og hvordan vi samtidig får leveret et tilfredsstillende resultat. Ud over det indeholder projektet en vis mængde kompleksitet. Vi skal lave nogle løsninger, som vi ikke har arbejdet med før, eksempelvis SMS gatewayen. Da vi kan finde løsninger forskellige steder på problemer som dette, vil det give sig udtryk som kompleksitet og ikke usikkerhed. Vi har hverken tidspres eller geografiske forhindringer i dette projekt. Altså har vi i projektet både en vis mængde usikkerhed og en vis mængde kompleksitet. Ud fra Andreas Munk Madsens skema4 vil det være fordelagtigt for os at arbejde ud fra en trinvis model. Nu skal vi prøve at tilpasse vores model, så den passer netop til vores projekt. Indtil videre har vi fundet frem til, at en trinvis model vil være det bedste at arbejde ud fra. Hvis vi ser på sammenfatningen, vil der være nogle forskellige dele i projektet, der vil gøre, at vi bliver nødt til at arbejde eksperimentelt. Dette drejer sig især om udarbejdelse af brugergrænsefladen. I andre dele af projektet vil det være en fordel for os, at planlægge fra start, så vores model vil altså være trinvis, med en grad af eksperimentelt. Næste opgave er at finde frem til hvilken metode eller metoder, vi vil arbejde med. Vores valg er faldet på Extreme programming (XP). XP er meget fokuseret på, at levere resultater til brugeren og man vil stort set fra starten gå i gang med at kode. XP giver os desuden mulighed for, at arbejde både eksperimentelt og trinvist, hvilket jo passer perfekt til vores opgave. Da vi ikke tidligere har prøvet at arbejde med XP, kan det vise sig at vi bliver nødt til at tilpasse metoden til de behov vi har i dette projekt Andreas Munk Madsen, Strategisk projektledelse, Kapitel 6

23 P ROBLEMFORMULERING Gruppen har fået til opgave at lave et vikar og lønsystem til ITemp Vikar bureau. I systemet skal der kunne oprettes vikarer, og disse skal kunne tilknyttes flere forskellige vikariater, som igen kan knyttes til en arbejdsgiver. Systemet skal kunne registrere det antal timer en vikar arbejder, og det skal være muligt for vikaren at udskrive sin lønseddel direkte fra nettet i PDF format. Der skal være 3 forskellige roller i systemet, som er: Administrator, almindelig bruger og gæst. Disse tilgås ved hjælp af et login system. Der skal laves en funktion til generering af s, når en vikar tilmelder sig et vikariat, eller når man opretter sig som bruger. Det skal også være muligt at få sine login informationer tilsendt, såfremt disse bliver smidt væk eller glemt. Gruppen vil bruge en ny systemudviklingsmetode, og skal ved hjælp af denne planlægge og dokumentere processen, der fører frem til udarbejdelsen af det endelige system. Det er et lærings mål for gruppen at arbejde sammen i en kollektiv lærings proces, således at alle er med under hele udviklingen af systemet. Der vil løbende blive holdt reviews, der sikrer at alle i gruppen er ajourført. Et andet lærings mål for gruppen vil være brugen af nye samt ukendte teknologier til.net platformen, heriblandt LINQ og BulkInsert. Gruppen ønsker desuden at supplere deres viden indenfor emner som: Css Html Ajax Gruppen skal til slut udarbejde en rapport, der beskriver og dokumentere de metoder, teknikker og teknologier de har brugt, samt lave en grundig analyse af virksomheden og de problemstillinger de står overfor. Projektgruppen har i projektperioden brugt følgende bøger indgående: Rolf Molich Brugervenligt webdesign Andreas Munk-Madsen Strategisk projektledelse Poul Staal Vinje Projektledelse af systemudvikling og Softwaretest. 19

24 1. ITERATION : 31/08 24/09 TortoiseSVN En af de centrale principper i XP er continuous integration. Skal man arbejde sammen om koden i stedet for at dele opgaven i to dele, kan continuous integration skabe mange praktiske problemer. Når tre udviklere sidder ved hver deres maskine med hver deres solution og koder vil der opstå samtidighedsproblemer. Bruger man et netværksdrev vil man overskrive hinandens filer. I stedet for at bruge lang tid på at beskrive udfordringer tager vi i stedet udgangspunkt i løsningen. Løsningen på problemerne er TortoiseSVN. Anvendelsen af TortoiseSVN er skitseret på Figur 4. File repository Server Commit Update Daniel Lokal kopi Kasper Lokal kopi Server Lokal kopi Figur 4: Projektgruppens brug af TortoiseSVN TortoiseSVN er en subversion klient, og sørger for korrekt versionering af filer. Programmet opretter et centralt beliggende file repository, som holder styr på versionerne af filerne. Hver bruger opretter ved hjælp af funktionen checkout en lokal version af filen på sin pc. En checkout laves kun én gang (når man henter fra serveren første gang) Når brugeren har ændret i filen committer han ændringerne. Skal han hente opdateringer updater han. Filen i repository synkroniseres med den lokale fil uden at slette den lokale fil. I repository gemmes ændringerne i filerne. Dette gør det muligt at gendanne tidligere versioner af dokumentet. Ændringerne er som regel mindre end selve filen. Det bør tilføjes at TortoiseSVN er gratis. Google code og webhotel Alle adresser med 10.x.x.x er lokale adresser. Lokale er ikke offentligt tilgængeligt. Man kan ikke tilgå dem andre steder fra end fra skolens netværk. Skolen har lukket for offentlig IP tilgang. Disse IP-adresser kan man kun få adgang til på skolen. Når man så kommer hjem kan man ikke finde dem. Gruppen har webhotel hos 20

25 TortoiseSVN benyttes i kombination med Google code på Continuous integration integrationstest hver dag og nogle gange op til flere gange dagligt. Finder man flere af de simple fejl, der vil opstå når kode med en anden kode. Continuous integration gør også af nogle af de funktionelle fejl, der først ville afsløres ved accepttesten. Fejl tvinger udviklerne til at kontakte og snakke med hinanden om de fejl, der vil optså. Collective ownership. Alle kender til koden og føler ansvar. Ved commit sendes kun de filer, der er ændret. Ydermere er det kun ændringerne i filerne der sendes. Man kan bede om at få en revision. Man kan se detaljer om hvem, og hvornår Update problematikken, kun med sidste nye version besked på at hente den nye version TortoiseSVN er et utroligt stærkt værktøj, der passer perfekt til XP s krav om continuous integration. TortoiseSVN løser følgende problemstillinger: Der er backup af projektets filer (rapport, kode, billeder osv.). Man kan vende tilbage til kode, der virkede ved versionshistorikken Man kan arbejde hjemmefra og offline Navigation Til navigation på vores website har vi valgt at anvende en af ASP.NET navigation controls. Overordnet oprette en MasterPage og SiteMap-fil (Figur 6). På MasterPagen placeres en SiteMapDataSource og en TreeView control. SiteMapDataSource forbinder sig automatisk til SiteMap-filen. For at forbinde det hele til sidst vælger man i TreeView kontrollen vælger man SiteMapDataSource som datasource. SiteMapDataSource Control En SiteMapDataSource er en ikke-visuel komponent, og vises derfor ikke på siden når denne er blevet renderet. 21 Figur 5: SiteMap: Beginning ASP.NET side 446, fig En SiteMapDataSource læser XML-data fra Web.SiteMap-filen, og gør denne tilgængelig for navigationskontrollerne. I ASP.NET er der tre navigation controls:

26 TreeView control SiteMapPath control Menu control SiteMapDataSource skal tilføjes siden før man kan bruge navigation controls. Når denne er tilføjet kan man derefter tilføje GUI-komponenter, der grafisk viser dissse data. TreeView Control TreeView Control viser navigations information. Man trækker TreeView Control fra Toolbox i Visual Studio 2008 ind på Masterpage og vælger sin SiteMap-fil som data source. SiteMap Et SiteMap er en XML-fil, hvori det er muligt at arrangere websiderne i hierarkisk struktur, der skabes af relationen mellem parent- og child pages. Ved at kigge på Sitemap-filen i kan man aflæse sidestrukturen i webapplikationen. En SiteMap har altid én root node. En root node indeholder en XML-declaration, så filen genkendes som værende en XML-fil. I Figur 6 ses root node i linje 2. Hver node beliggende under root niveau repræsenterer en unik side i webapplikationen. Man ser derudover, at SiteMap-filen indeholder nesting. Nesting er når en <sitemapnode> indeholder en eller flere <sitemapnode>-elementer. Login.aspx er root node. Administration i linje 4 er en parent node. En parent node har children. Administration er parent node for GodkendTimeregistreringer.aspx og OpretVikar.aspx. Begge disse kaldes for leaf nodes, da ingen af dem har children. Den føromtalte nesting en måde at tackle kompleksitet i størrere webapplikationer. For hver parentnode opretter man en mappe i sin solution, så mappestrukturen i ens solution afspejler XMLstrukturen i ens SiteMap-fil. Der oprettes en parent node uden en URL. På denne måde grupperes siderne i kategorier. Vi har kategorierne Administration og ForVikarer. I forbindelse med nesting og parent nodes er det vigtigt at vide at en SiteMap-fil ikke tillader dulikat URL s. 22

27 Figur 6: SiteMap-filen i ITempSys Master og contentpages En MasterPage anvendes med henblik på at skabe et fælles layout for alle sider. Vi har i websitet en header, footer samt et navigationsområde (kan ses på webhotellet). Content pages er som navnet antyder indholdet på siden. MasterPage danne en ramme, hvori content indlæses. Indholdet indlæses i MasterPage, hvorved alle sider får samme layout. D ATABASE Direct Data Access Ved Direct Data Acces arbejder man ikke med en kopi af data i hukommelsen, men man arbejder gennem en database connection, der i en kort periode er åben. ASP.NET har ikke behov for kopier af data i en længere periode, og er dermed en kandidat til Direct Data Access. Når der forespørgsel på en side i ASP.NET lukkes ligeså snart en side er hentet. Dette betyder en side har en levetid på ganske få sekunder. Der findes dog en teknik til optimering af performance kaldet caching. Ved caching holdes en kopi af af data i live på serveren. Hvis en administrator i ITempSys henter alle vikariater for en vikar kan disse gemmes som en kopi på webserveren. Når samme side efterspørges af en anden administrator kan kopien gennembruges og resultere i performanceforbedringer. Eksemplet forklarer caching, men er lidt søgt, da situationen næppe vil forekomme i ITempSys, hvilket også er grunden til vi ikke eksperimenterer med eller anvender caching. 23

28 Disconnected Data Access Ved brug af et DataSet lagres en kopi af data i hukommelsen. Der forbindes længe nok til at hente data fra databasen ind og så lukkes forbindelsen. Efter forbindelsen er lukket kan der arbejdes med data. Teknikken bruges til desktop applikationer, der kører i lang tid. Disconnected Data Access bruges når man vil navigere frem eller tilbage mellem tabeller alt imens man bearbejder dem. Dette kan kun gøres af et DataSet, men er ikke muligt med DataReader, der kun kan læsse fremad (Direct Data Access). Ved webpages skal ændringerne tilføjes i det øjeblik de sker. En typisk ASP.NET web applikation Ved en ASP.NET side skal ændringerne foretages i det øjeblik de sker. Desuden er det tidspunkt en side efterspørges og det tidspunkt der ændres i forbindelse med et postback forskelligt, hvilket gør det svært at anvende det samme DataSet. Konsekvensen er DataSet anvendes til lagring af selve siderne mens opdateringer foretages ved hjælp af direct commands. I NDSÆTTELSE AF POSTNUMRE I DATABASEN Ud fra første kundemøde formulerede kunden en user story for oprettelse af en vikar. Vi tog user storien ud af munden på ham. Kunden formulerede ønsker omkring postnumrene, da dette var en en information, som skulle bruges meget og flere steder. Fredericia har postnumrene Fredericia 7000, Fredericia 7007 og Fredericia Der er ikke noget problem ved at denne information ligger i databasen. Problemet opstår, hvis postnummeret skal indtastes manuelt i databasen af kunden. Han kan ved indtastningen komme til at indtaste 7001 som værende postnummeret for Fredericia. Der opstår redundans i databasen. Når der er redundans skader dette dataintegriteten (man er sikker på indtastede data er korrekt). En dataintegritet på 100% er aldrig mulig. Oprettes en vikar til at have postnummeret 5000 Odense C, kan man ikke garantere at det er 5000 C han kunne f.eks. lyve. Løsningen på postnummer problemet Det vil skabe problemer, være vanskeligere samt mindske dataintegriteten, hvis postnumrene skal indtastes manuelt. En oplagt løsning er derfor, at postnumrene skal være indsat i databasen. Når kunden indtaster et postnummer finder websitet byen af sig selv. Indtastes et forkert postnummer kommer en fejlmeddelelse,og tekstboksen skraveres. Algortimen for løsningen af problemet består af følgende to trin: Vi hentede en Excel-fil kaldt postnummerfil.xls fra Post Danmark5. Filen åbnes med Excel og konverteres fra.xls til.csv-format I SQL Server 2008 køres kommandoen i Figur 7, hvorefter postnumrene indsættes i databasen med primary keys og identity increment (nummererer automatisk postnumrene)

29 Figur 7: Bulk insert SQL-command fra SQL Server Express 2008 Løsningen vil i kombination med brugervenlighed kunne bidrage væsentlig til sikring af dataintegriteten. I forbindelse med deployment Bulk insert blev foretaget på en lokal database. Da vi i 1. Iteration havde deployet websitet hos løb vi ind i de typiske problemer man oplever i forbindelse med deployment. Hos unoeuro har man ikke rettigheder til at køre bulk insert. Vi kodede derfor et program, der indsætter csv-filen i databasen på webhotellet. Figur 8: Insert Postnumre i Db Solution. Klasse: Program.cs Figur 8 dokumenterer, hvordan postnumre og bynavne fra csv-filen indsættes i databasen på vores webhotel ( Linje 29 viser, hvordan hver række i csv-filen indlæses i et stringarray, og derefter splittes op i to variabler en til bynavn (postnr[1]) og en til postnummeret (postnr[0]). 25

30 Figur 9: Ved hjælp af indtastede postnummer findes det korresponderende distrikt. Klasse: OpretVikar.aspx.cs En administrator indtaster postnummer. Metoden FindDistriktMedPostNr() finder distriktobjektet, der matcher det indtastede postnummer. Er der indtastet et gyldigt postnr ryger man ned i ifkonstruktionen i linje 148. Sessionvariablen distrikt sættes lig det gyldige distriktobjekt Fortryder man og sletter det gyldige postnummer, og derefter indtaster et andet (ugyldigt postnr) er det nødvendigt, der i if-konstruktionen (linje 137, Figur 9 ), som det første sætter sessionvariablen distrikt = null. Dette er nødvendigt, da systemet ellers stadig har det tidligere gyldige postnummer i sessionvariablen. Figur 10: Klasse: OpretVikar.aspx.cs Når der indtastes et postnummer i GUI en og feltet forlades sker der postback. Dette medfører vi ryger i if-sætning på linje 27 (Figur 10). Indtastes ugyldigt postnummer vil sessionvariablen distrikt sættes lig null. Valideringskontrollerne på siden aktiveres. Har man derimod indtastet gyldigt postnummer er sessionvariablen ikke lig null. Værdien i sessionvariablen lagres i variablen d. 26

31 Refactoring i forbindelse med postnummer De mange ændringer i kodningen i forbindelse med user input vedrørende postnummer er et eksempel på refactoring. Et andet eksempel på refactoring er når der skal kommunikeres med databasen. I stedet for flere connectionstrings, hvor informationerne skal indtastest manuelt benytter vis os af én connectionstring beliggende i web.config. denne tilgåes ved hjælp af ConfigurationManager(). I web.config har connectionstringen et navn. Skal man bruge connectionstringen kalder man den via navnet. Dermed skal man ikke indtaste informationer igen og eventuelt lave fejl. Ved brug af ConfigurationManager har man sin connectionstring ét sted. Da man kun skal ændre info et sted mindskes risikoen for fejl dramatisk. K VALITETSEGENSKABER OG BRUGERVENLIGHED Følgende gennemgang af kvalitetsegenskaber og brugervenlighed er stærkt inspireret af Rolf Molich s bog Brugervenligt webdesigen. Er man ikke den store designer kan ved en kombination af denne og bogen The non-designer s web book opnå ganske fornuftige resultater med hensyn til design og basal styling af sites. Molich definerer brugervenlighed på følgenede måde: Brugervenlighed = nytteværdi + nemhed6 Fokus er på brugervenlighed, men inden vi kommer nærmere ind på begrebet er det nødvendigt først at undersøge kvalitetsegenskaberne nærmere og prioritere disse. For at sikre kvaliteten for et website, og kunne måle dem, skal der opstilles kriterier for disse. Prioritet Kvalitetsegenskab Korrekthed Høj Mellem Lav x Pålidelighed x Sikkerhed x Effektivitet x Tilgængelighed x Nytteværdi x Nemhed x Fejlretning x Fleksibilitet Test x x Flytbarhed x Genbrug x Tilpasning x 6 Rolf Molich: Brugervenligt Webdesign, p

32 Korrekthed. Websitet gør som det får besked på. Når en administrator opretter en vikar oprettes denne. Pålidelighed: programmet skal oprette en vikar hver gang de rette informationer indtastes. Pålidelighden vedrørende vikaroprettelse testes med Unit Test og brugertests. Sikkerhed. Data skal beskyttes imod manipulation, sletning og afluring. Effektivitet. Det skal være muligt hurtigt at oprette en vikar. Tilgængelighed. Det skal muligt at tilgå sitet, når dette ønskes. Der kan være problemer med hosting, hvilket er udenfor projektgruppens scope. Opgaven består i sikringen af manglende tilgængelighed ikke er et resultat af fejlagtig kode. Nytteværdi. Websitet har nytteværdi, når det er i stand til at løse opgaverne. En administrator skal kunne oprette en vikar samt se sin lønseddel? Nemhed. Nemhed er når sitet ikke kræver ikke de store forudsætninger eller viden. Fejlretning. Er et punkt der vedrører vedligeholdelse. For kunden er dette ikke så vigtig et kriterie, men de kunne være særdeles vigtigt for udviklerne. Vi skal ikke realisere (implementere) systemet, med deraf følgende rettelse af fejl. Dette gør punktet har lav prioritet. Anvendelsen af MVC gør retning af fejl mindre problematisk. Fleksibelt. Er det muligt at ændre ting i systemet. Testbarhed. Er det muligt at teste websitet? Vi bruger XP så for projektgruppen er testbarhed vigtigt. Kunden er også interesseret i testbarhed uden at være klar over det, hvis et site skal implementeres. Dette punkt er interessant for kunden uden han ved det, da øget testbarhed samt fejlsikkerheden. De næste tre punkter omhandler omlægningen af systmet. Videreudvikling. Ikke færdigt og funktionsdygtigt system. Flytbarhed. Kan systemet bruges på andre platforme. Websitet skal ikke implementeres, og skal køres fra webhotel. Flytbarhed har derfor ikke høj prioritet. Genbrugbarhed. Kan dele af systemet bruges andre steder. Til ITemp og skal ikke bruges til andre kunder. Klasser kan genbruges og evt. styling og javascript. Tilpasning: er det muligt at tilpasse systemet til andre systemer. Det kunne være kunden havde et lønsystem, som ITempSys skulle integreres med. ITempSys har til formål at demonstrere ASP.NET og skitsere en løsning på problemstillingen. Kravet om tilpasning har derfor lav prioritet. Vi har nu gennemgået de forskellige designkriterier, der kan være i forbindelse med et website, og det er nu muligt at gå videre til brugervenlighed. Brugervenlighed Brugervenlighed hvornår og hvorfor? Brugervenlighed er aktuelt når der er konkurrence med andre websteder. I tilfælde, hvor man ligger inde med ny og banebrydende viden er brugervenlighed ikke så vigtigt. Her gærlder det bare om at være først. Det er en udbredet misforståelse at brugervenlighed er det samme som funktionalitet. Detter er ikke tilfældet. Ifølge Molich er % af funktionaliteten på et website nødvendigt, og det der ønskes. Resten er tit overflødigt. Vores mange kundemøder og tests sikrer, at der ikke udvikles funktionalitet, der ikke er brugbart. Dette reducerer udviklingstiden samt prisen. 28

33 Lønsomhed Om lønsomhed gælder følgende: Lønsomhed = gevinst omkostninger Er sitet brugervenligt kan brugeren selv udfører opgaverne i stedet for medarbejderne og support. Er kun de nødvendige funktioner i websitet aflaster dette hotline. Når sitet er sat i drift reduceres omkostningerne, kunderne bliver tilfredse og der er ikke så megen bøvl. Forudsætninger for brugervenlighed For brugervenlighed kan blive interessant og diskuteres er følgende tre punkter nødvendige forudsætninger: Pålidelighed. Websitet skal være stabilt. Brugeren skal på intet tidspunkt gøre noget om, og der må ikke forekomme funktionfejl eller tab af data. Sikkerhed. Data skal beskyttes, og må ikke ikke læses eller kunne ændres af uvedkommende. Tilgængelighed. Når brugeren har brug for det. Måling af brugervenlighed Designer og udviklere tænker tit forskelligt. Begge er tit inhabile på grund af deres faglige viden. For at kunne vurdere brugervenlighed og fremgang er det nødvendigt med præcise og objekt mål samt måleteknikker. Tager udgangspunkt i nemhed er et brugervenligt websted kendetegnet ved følgende: Let at lære: kan der oprettes en vikar, hvor f.eks 80% af 20 brugerne vil kunne fuldføre dette uden problemer. Let at huske: hvor lang tid tager det at løse en opgave? Kan en bruger huske, hvordan en opgave udføres når han ikke sidder foran computeren?. Dette er aktuelt, hvis det er et site, han vender tilbage til. Effektivt at bruge. Brugeren skal kunne udføre en opgave på et fastsat antal minutter eller sekunder. Forståeligt: kan bruger svare på spørgsmål om, og forklare websitets funktioner og arbejdsmåde når han er færdig med brug. Tilfredsstillende at bruge. Dette punkt er udelukkende subjektivt, men selvom dette er tilfældet er det vigtigt. Spørgsmålet kan afklares ved hjælp af spørgeskemaer, hvor man kan svare på spørgsmål som: det er let af finde rundt på dette site eller jeg vil gerne besøge websitet igen. Svarmulighederne kunne enig, meget enig, uenig og meget uenig. Man kunne sætte 10 personer gennemsnittet enig. Vores test af brugervenlighed Vi har lidt fulgt XP. Vi har brugt Jan og Alex som on-site customers og antaget de er inde i brugerens ønske. Dette er XP s måde at løse problemet på. Vi ville gerne have testet mere, men har måtte bortprioritere dette. Vi har dog i form af brugertests og interview testet brugervenligheden. Der er også udformet skitser til GUI en, hvorudfra der er lavet tænke højt tests og blevet diskuteret. 29

34 S IKKERHED Sikkerhed er et stort område, som uden problemer kunne fylde en hel opgave i sig selv. Der er stor forskel i, hvor store sikkerhedskravene til et website kan være. Det er derfor oplagt at undersøge, hvor stor sikkerhedskravene til vores website er. En administrator skal have mulighed for at se vikarer, oprette vikarer, vikariater og godkende timeregisteringer og genere pdf-lønsedler. Vikarer skal kunne logge på og se sine lønsedler og rette vikarinfo, men ikke have mulighed for at oprette vikarer eller vikariater. Skal kunne se, hvilke vikariter denne er tilknyttet. Anonyme brugere skal efter at have hørt om ITemp mundtligt eller fundet det på nettet logge på siden og se info, der siger man skal kontakte en personalekonsulent. Anonyme brugere skal selvfølgelig ikke kunne oprette vikarer, rette vikarinfo eller se lønsedler, da dette er personfølsomme oplysninger. Anonyme brugere kan være mange slags personer, men det centrale er at ingen skal have adgang ved uheld, eller hvis de har onde hensigter. Det kan være nødvendigt at kryptere data i tifælde hvor en tidligere medarbejder kan slippe forbi authentication, eller en hacker slipper forbi. Det kan også være fordi en harddisk indeholdende data bliver kasseret. Sikkerhedskravene Sikkerhedskravene til systemet er, at informationerne om vikarer, vikariater og personfølsomme oplysninger skjules og beskyttes fra udefrakommende. Databasen beskyttes ved anvendelse af authentication og authorization. Dette sikrer at de rette får adgang og kan bestemme hvilke sider og funktionaliteter, der er tilgængelig for hvem. Sikkerhed er et stort emne, som man kunne skrive en hel opgave om i sig selv. Ved implementering skal siden hostes, og sikkerhed omkring harddiske uddelegeres til hostingfirmaet. Vi beskæftiger os med den basale del af sikkerheden, da dette i projektet ikke har så høj Parameterized commands For at undgå SQL-injection attacks, hvor der kan gives administrator rettigheder til databasen eller køres stored procedures, der starter programmer har vi brugt parameterized command. De hardcodede værdier erstattes med en placeholders, som tilføjes separat. En placeholder starter med 30 Figur 11: Metode, der laver paramterized commands. Klasse: VikarAR.cs

35 En SQL-command som: Insert into vikar where vikarcpr = vikarcpr erstattes med Insert into vikar where vikarcpr Værdierne er flyttet ud fra en SQL-command og ind i en collection af parametre. Sikkerhedsmodellen i ASP.NET Authentication og authorization Ved authentication fastslåes brugerens identitet ved at kræve bevise at de er den de udgiver sig for at være typisk ved at spørge efter credentials, som typisk er brugernavn og password. De indtastede oplysninger sammenlignes derefter med en liste af brugere, database eller en Windows account. Når brugeren er authenticated er næste trin authorization. Authorization afgører om brugeren har rettigheder til at udføre en handling såsom se en side med vikarer eller oprette et vikariat dvs. hente data fra en database. Forms og Windows authentication er de muligheder man har for authentication til sikring af et website i ASP.NET Windows authentication Ved Windows authentication tvinges alle brugere til at logge ind som Windows bruger. Forudsætningen er her at alle har en Windows account på serveren. Løsningen egner sig til intranet scenarier, hvor man har et mindre netværk med en gruppe af kendte brugere. Ved Windows authentication står IIS (web serveren) for authentication processen. Brugerne tvinges til at logge på IIS før de får adgang, som før nævnt via en lokal Windows account. Disse info leveres fra Internet Explorer til ISS. Dette sker også ved Visual Studio s web server, så der kræves at en bruger er logget ind på en computer med Windows eller domæne på samme netværk. Ved IIS tvinges brugeren til at logge på ved at man ikke tillader anonymous tilgang. Ændrer i linje 60 Figur 13 til authentication mode Windows i stedet for Forms. Ved deployment til web server kræves, at man disabler anonnymous access i IIS Manageren, og at man konfigurerer sine Windows på web serveren. Windows authentication methods Når en webapplikation, der anvender Windows authentication er blevet deployet til en webserver skal IIS konfigureres. Der er følgende konfigurerings muligheder: Anonymous authentication: bruger skal her ikke indtaste kodeord eller brugernavn. Brugeren gives adgang til websitet gennem IUSR, som er en speciel user account. Anonymous authentication er default. Basic: bruger skal indtaste brugernavn og password, som begge overføres til IIS, hvor de sammenlignes med en local Windows konto. Integrated Windows authentication: bruges til intranet. Internet Explorer kan sende information ved at bruge den Windows account, som man er logget ind via. Forms authentication Ved Forms authentication er IIS konfigureret til at anonyme brugere samtidig med at ASP.NET kan bruges til sikring af ens website. Man kan kode funktionalitet, der opretter brugere samt en login side, hvor brugernavn og password holdes op imod allerede eksisterende credentials i en database. 31

36 ASP.NET laver security cookie for en, og har validerings algoritmer, der ikke gør det muligt at spoofe sin egen cookie. Hvis det er første gang man logger på oprettes en forms authentication cookie. Har man sådan en lukkes man ind og får siden. Næste gang checkes der om en sådanne eksisterer, og har brugeren authorization til at vise en side sendes siden Request fra clienten møder først IIS, der undersøger filtypen. Er denne registreret til ASP.NET gives forespørgslen videre til ASP.NET Figur 12: Indstillinger inden brug af membership IIS har en liste over over tilladte brugere. En bruger forhindres ikke i at logge ind. For at kunne nægte en bruger adgang skal man anvende authorization. En bruger, der ikke er authenticated får ikke adgang. Ligeledes får ingen anonym bruger adgang til sitet. Authorization Figur 13 Forms authorization Rækkefølgen er vigtig. Når en regel, der matcher findes gælder denne. Anonyme brugere får ikke adgang. Skal man have adgang skal kodeord og brugernavn indtastes. Alle andre brugere end Kasper nægtes adgang. 32 Figur 14: Authorization fejl

37 Authorization-checket i Figur 14 er ikke hensigtsmæssig. I linje 74 får alle brugere adgang, og reglen i linje 75 evalueres aldrig. Det er ikke muligt at nægte brugere adgang. Roles og SiteMap Figur 15: Fra Administration mappen Vi bruger de oprettede roller i fobindelse med menbership databasen. D EPLOYMENT Ved deployment publisher man websitet. Dette giver et compilet site, der kan overføres til serveren. Dette bevirker at source code ikke er tilgængelig på serveren. Visual Studio 2008 Web Server Visual Studio fungere som IIS, men adskiller sig fra denne ved ikke at tillade anonymous brug. Man bliver logget ind på serveren via sin Windows account. Man skal her ikke bekymre sig om deployment. Den accepterer kun request fra brugerens lokale pc andre kan ikke maskiner kan ikke få adgang til websitet Står ikke tændt hele tiden som en normal server døgnet rundt og venter på requests En maksine til server og en til udvikling ellers er hastigheden for lav og klienterne bliver frustrerede Når man anvender testserveren, der er indbygget i Visual Studio 2008 er IIS ikke involveret. Den virker på samme måde som IIS i det den behandler de forskellige request efter forskellige filtyper f.eks. HTML-sider eller ASP.NET sider, og sender videre til ASP.NET når dette kræves. Forskellen er at sikkerhedsmodellen i den indbyggede server er mere simpel. Testserveren kan kun bruges af en person af gangen Anonymous access er ikke muligt Hver gang testserveren køres logger man ind med sin Windows account. Dette bevirker koden kører med de tilladelser man har. Rettighederne er større end dem man har ved en website der er blevet deployed. Man kører med account og har permissions. Man løber ikke ind i permissions problemer, som kan opstå når man deployer sit site. End useren der kører sitet fra sin egen pc, har ikke en Windows konto på serveren. Indstillinger er lavet med henblik på at undgå angreb på serveren. Grant additional permissions til kontoerne. 33

38 Vedrørende deployment Vi har valgt at deployment af vores website af følgende grunde: Ved brug af lokal Visual Studio 2008 Ved brug af Visual Studio 2008 har man kun lokal adgang. Kun personen, der sidder ved den lokale pc kan se og teste koden. Når IIS kører på en lokal maskine er ulemeperne: Pc en skal være tændt hele tiden Ved en lokal IIS er der kun muligt at have 10 brugere af gangen Når maskinen slukke skifter IP-adressen. For at en anden udvikler skal kunne teste sitet kræver dette at denne har den nye IP der skal tales sammen over telefon eller Skype. Ved anvendelse af en IIS på TietgenSkolen Anvendelse vil kræve installation og opæstning Alle adresser med 10.x.x.x er lokale adresser. Lokale er ikke offentligt tilgængeligt Når man komme hjem kan man ikke logge på. Kunden kan heller ikke. Man kan ikke tilgå dem andre steder fra end fra skolens netværk. Skolen har lukket for offentlig IP tilgang. De IP-adresser kan man kun få adgang til på skolen. Når man så kommer hjem kan man ikke finde dem. Deployment vælges fordi: Vi har valgt at bruge eget webhotel og Tortoise via Google Code, da dette giver følgende fordele: Kundne og vi kan tilgå hjemmefra via samme adresse Vi kan teste, der hvor det skal ske. Med rette sikkerhedsindstillinger Kunden kan når som helst logge på websitet og teste funktionaliteten M EMBERSHIP DATA STORE Membership er et lag på Microsoft forms authentication framework. Membership har user management, hvor man kan holde styr på brugerne og brugerinformation. Security controls, der tilbyder en login control, create users, PasswordRecoveryoprette brugere, skiftes password. Sikerhed baseret på roller. Forskellige brugere skal have forskellige roller. Ordner i grupper, der har forskellige permissions. Grupperne kaldes roles. Membership Data Store ASP membership Data Store mindsker kodemænngden og er gennemtestet og sikker sammenlignet med hvad man selv ville komme frem med, hvis man skulle kode det Grunde til ikke at bruge membership: Har ikke brugerliste i en database eller ønsker i en anden relationen database 34

39 o SQL Server og Active Directory Har en database med en anden struktur, hvilket gør det svært at skifte. Med andre felter og datatyper og mængden kan være for stor. Ønsker at have userinfo i en non-asp.net applikation. Hvis en andne applikation skal oprette, ændre og slette brugere forstå membership tabel strukturen. Det kan være nemmere at skrive sin egen SQL-statements og tabeller. Active record Vi har til vores database valgt at bruge active record mønstret, som er beskrevet af Martin Fowler 7. Active record er ganske praktisk at bruge i forbindelse med objekt orienteret programmering. Hovedprincippet bag active record er, at man mapper ethvert objekt ned som en ny række i databasen. Når et objekt hentes ud af databasen igen vil det ligeledes være en række i en table, der bliver hevet ud som et objekt. Vi har kun lavet en enkelt Active record klasse, da vi har valgt at bruge LinQ til resten af databasen. LinQ bruger i øvrigt nogenlunde samme princip som active record, med at enhver række der bliver hentet fra databasen, bliver hentet som et objekt, og omvendt når man igen putter noget ned i databasen. Vi har som sagt kun benyttet os af en enkelt AR klasse. I princippet kunne vi have valgt at lægge alle metoderne til denne i selve vikarklassen, men vi har valgt for vores egen overskueligheds skyld at lægge alt hvad der har med databasen at gøre i en partial klasse til vikar. I selve klassen arbejder vi med statiske metoder når vi arbejder på tabel niveau, mens vi når vi arbejder på rækkeniveau benytter instansmetoder og egenskaber. Her et eksempel på dette fra vores vikarar: Metoder på tabel niveau Metoder på rækkeniveau Her fortæller vi til at starte med, at den tabel, den skal lede i er vikar tabellen, da det er denne vi vil arbejde med her. Herefter følger de metoder der har med databasen at gøre, dette er insert, delete og update, samt nogle metoder der bruges i disse. Ingen af disse har nogen parametre, da det er et objekt du sætter ind og derfor er programmet klar over hvilke parametre der følger med til hvert objekt. Her ses et udsnit fra vores Insert metode: 7 Martin Fowler, Patterns of Enterprise Application Architecture, part 2, kapitel 10 35

40 Hele teksten kan desværre ikke være med i screenshotet, men her ses hovedprincippet i active record mønstret, nemlig at vi indsætter objektet direkte i en tabel og hver property vil blive indsat i en kolonne, således at objektet, der netop er indsat, vil udgøre en fuldstændig række i database tabellen. Dette mønster er relativt nemt at benytte, og vores fejlhåndtering her vil generelt gå på, om det lykkedes at få indsat objektet i databasen: 36

41 Som beskrevet tidligere vi kun benyttet dette mønster til en enkelt klasse, da vi fandt linq og valgte at prøve dette i stedet. En beskrivelse af linq kommer senere i rapporten. LINQ Linq står for Language Integrated Query, og er en del af.net 3.5 frameworket. Linq kan bedst beskrives som et værktøj der forbinder datalageret og modellen med hinanden. Linq understøtter følgende former for datalager. LINQ understøtter følgende datalager typer 37 Linq to aql Linq to xml Linq to ADO.NET

42 Linq to dataset I vores projekt benytter vi os af linq to sql, da vi har valgt at vores datalager skal være en MS database. Linq to sql er en funktionalitet, der integrer datalageret i ens applikation ved at skabe et tilhørende objekt til hver enkelt tabel i databasen. Det betyder at man via linq kan lave en forespørgsel, der returnere et DTO objekt, som indeholder properties svarende til en rækkes felter i den givne tabel. Udover at linq to sql kan omdanne data fra en tabel til et objekt, tilbyder det en masse andre funktionaliteter her i blandt, at returnere en collection / liste af en tabels indhold, sortere disse efter bestemte kriterier, og meget mere. Fordele ved LINQ frem for alm sql Fordelene ved at benytte linq til at håndtere kommunikationen mellem modellen og datalageret er, at linq er en del af.net frameworket, hvilket vil sige at visual studio intellisense understøtter linq, det betyder at compileren vil fange hvis der er fejl i en linq forespørgsel allerede på compilertidspunktet. Hvorimod man med en alm. Sql forespørgsel først ville opdage hvis man havde lavet en fejl på selve runtime tidspunktet. Queries i LINQ Når man skal skrive queries i linq foregår det i en god blanding af programmeringssprogets syntaks og alm. sql syntaks, i vores tilfælde er det.net C# og sql. Her følger et par eksempler. Indsætter en række i tabellen Arbejdsgiver public void OpretArbejdsgiver(string string tlfnr, string ) { firmanavn, db.arbejdsgivers.insertonsubmit(new distriktid, tlfnr, )); string adr, int distriktid, Arbejdsgiver(firmanavn, adr, } Henter alle rækker fra tabellen Arbejdsgiver public IQueryable<Arbejdsgiver> HentAlleArbejdsgivere() {return db.arbejdsgivers;} Returner en liste af vikariater med et specifikt vikarcpr public List<Vikariat> FindVikariatTilknitningerTilVikar(string cpr) {var query = from v in db.vikariats where v.vikarcpr==cpr select v; return query.tolist(); } Eksempel på join med linq public id) IQueryable<Vikar> HentAlleVikariaterDerErTilknyttetTilVikariatOrdre(int {var query = from v1 in db.vikars join v2 in db.vikariats on new { v1.vikarcpr } equals new { v2.vikarcpr } where v2.vikariatordreid==id select v1; return query; } 38

43 Finder et vikariatordre objekt med et bestemt id public VikariatOrdre FindVikariatOrdreMedID(int id) { return db.vikariatordres.singleordefault(vikariatordre VikariatOrdre.VikariatOrdreID == id); => } Implementering af linq to sql Implementeringen af LINQ to SQL kan ske helt automatisk ved at benytte visual studio og oprette en LINQ to SQL klasse her ved genereres der bl.a. en dbml klasse hvor man via drag and drop kan trække alle de tabeller fra ens datadase som man ønsker at bruge ind i dbml klassen ved at oprette forbindelses til databasen via server explorer. Når dette er gjort generere viual studio selv den kode der skal til for at der bliver skabt et objekt af hver tabel, og man via disse kan hente og gemme data fra ens databese. 39

44 T EST Lærebogsmaterialet om test er baseret til større systemer end dem vi laver. I Softwaretest kom godt i gang står der: Om ambitionen med testen er nået, kan først vurderes 90 dage efter ibrugtagning. Så er de fleste fejl fundet, og tallene kan gøres op8. Det er tydeligt teoribøgern arbejder med større systemer og langt længere tidshorisonter end vi gør i vores projekt. Omstændighederne i teoribogen vedrørende test er grundlæggende helt anderledes end de omstændigheder vi arbejder under. Vi har ikke tid eller ressourcer til, at have en selvstændig testorganisation. Vi har ikke tid at lave Walk-through test, hvor personen, der skal anvende produktet i næste trin af udviklingen fortolker specifikationen. Der er heller ikke tid til fortolkende reviews og inspektion med roller (inspektionsleder, oplæser og inspektør). Dette kræver planlægning, hvilket ikke er gruppens stærkeste side. Når dette er sagt er test dog ikke til at komme udenom. Testen sikrer: Et godt produkt, der er klar til brug uden at indeholde fejl. Et program uden fejl. Det er billigere at teste end at skulle skulle rette fejl og modtage henvendelser omkring support. Teststrategi Der er ikke nogen ideel, sand eller bedste strategi 9 Et skema giver overblik over strategimulighederne der er vedrørende test. Tager udgangspunkt i de tre grundtyper af test, der findes Model Planlægning Egnet til/styrke Svag ved/svaghed Testtidspunkt Traditionelle Model Planlægning først Korte forløb med kendt indhold. Ukendte ting. Test til sidst i projektet. Estimering af tid og ressourcer er muligt. Kræver tidlig planlægning. Den først planlagte test udføres til sidst (omvendt rækkefølge). Systemet skal testes før det er færdigt. Der testes samtidig med udviklingen. V-Modellen Testen af en udviklingsfase planlægges i selve udviklingsfasen. Den Radikale Model Testen planlægges samtidig med udviklingen. 8 Softwaretest kom godt i gang, p Softwaretest kom godt i gang, p. 20. Komplekse ting. Accepttest på baggrund af kravspecifikation. 40

45 Vores testrategi er planlagt fra starten af. Der testes allerede i iteration 1. Når der ikke gøres noget med henblik på testning og der bare testes til sidst er der tale om den traditionelle model. Alene det at vi tester med Tortoise og har testet fra dag et, gør vi ikke bruger den traditionelle model til test. Vores testrategi er en hybrid mellem V-modellen og den radikale model testrategien for ITempSys hælder dog en anelse til den radikale models side. Hvordan og hvadvi har testet fremgår af afsnittene omhandlende test. Testfaser kap 3 Deles op i faser. Den foregående fase har indflydelse på den efterfølgende. Som en si. Flere typer, da der er behov for at finde forskellige former for fejl. Komponenttesten En komponenttest finder fejl i de enkelte programmer, websider og øvrige komponenter. En komponttest udføres parallelt med konstruktionen. Et eksempel er Unit Test. Komponenttesten skal være på plads før en system- og brugertest kan udføres. Komponenttesten laves enten parallelt med udviklingen eller bagefter. Den finder fejlen i den enkelte komponent. Et eksempel på en komponenttest er Unit Testen. Komponenttesten er overfladisk, men nødvendig for system-/brugertesten. Testområde: KOMPONENTTEST OG FEJLRAPPORT FOR KOMPONENTTEST Projektnavn: Hovedopgave ITempSys Prioritet: Omgående = O, Høj = H, Mellem = M, Lav = L. Fejlstatus: Godkendt = G, Mangler = M, Fejl = F Fejlstatus Prioritet Navigation via TreeView virker ikke på alle sider G O, Rettet Du er logget ind som: står der inden man er logget ind G L, Rettet Muligt at indtaste CPR-nr på under 2 cifre i tbxvikarcpr G O, Rettet Muligt at indtaste CPR-nr på over 10 cifre i tbxvikarcpr G O, Rettet Validerings * kommer først frem efter postback, og ikke alle * dukker op igen G O, Rettet Textbox til noter er både tilgængelig ved administrator og brugere G O, Rettet Når posnr indtastes indsættes bynavn ikke automatisk. Det er muligt at indtaste ugyldigt postnr G M, Rettet Range validator til postnr vises ikke G L Integrationstest Integrationstesten tester de enkelte komponenter i samspil med hinanden, og finder fejl i grænsefladerne mellem komponenterne. I ITempSys er det specielt grænsefladen mellem GUI og modellen/databasen. Indtaste et navn indeholdende cifre, CPR-nr indeholdende bogstaver eller et telefonnummer indeholdende bogstaver skal dette ikke tillades. I controller laget har vi anvendt en CustomValidator. Denne checker om tbxtlf indeholder 8 cifre. JavaScriptet til validering ligger på client-siden. Der ligger ligeledes kode på serversiden. 41

46 Systemtesten = funktionstest Systemtesten dokumenterer at al funktionaliteten er til stede. Ved en systemtest undersøges, hvorvidt e enkelte funktioner fungerer isoleret hver for sig. Kan programmet oprette en vikar, en note osv. Findes der fejl er det en god ide at dokumentere de trin, der kan genskabe fejlen. Testområde: SYSTEMTEST OG FEJLRAPPORT FOR SYSTEMTEST Projektnavn: Hovedopgave - ITempSys Prioritet: Omgående = O, Høj = H, Mellem = M, Lav = L. Fejlstatus: Godkendt = G, Mangler = M, Fejl = F, Rettet = R. Fejlstatus Priorite t En Administrator opretter en vikar og tilføjer en note til denne. Der oprettes en vikar med binde-streg i navnet Der logges på som bruger og som administrator Problemet med Du er logget ind som er nu løst Oprette en vikar og ændre oplysningerne efter oprettelse Det er først muligt at ændre vikarinfo efter opretteslsen, men de skal være muligt at ændre inden de gemmes i databasen. Der skal laves en bekræftelsesside Oprette to vikarer med samme CPR Er ikke muligt, men der kommer fejlmeddelelse, der siger at brugeren eksisterer. Det er muligt at oprette to vikarer med samme navn Oprette to vikarer med samme allerede eksisterende Er ikke muligt, da binder modellen sammen med membership skal være unik. En administrator ændrer vikarinfo Funktionaliteten virker, men der er problemer med placeringen af knapper, og siden er rodet Brugertesten Brugertesten tester, hvordan systemet opfører sig når systemet bruges i forhold til et virkeligt forløb. Ved en brugertest anvendes programmet under et virkeligt hændelsesforløb af kunden. System og brugertest kan minde om hinanden. Ved systemtesten testen man om notefunktionen nu også kan skrive en note, om funktionen til nyhedsbreve nu også kan oprette et nyhedsbrev. Ved brugertesten testes funktionerne i kombination. Kan der oprettes en kunde og tilføjes en note til denne. Systemtesten tager udgangspunkt i systemet, men brugertesten tager udgangspunkt i brugeren. Ved brugertesten skal man være opmærksom på, at det som kunden nævnen som fejl eller mangler kan være ændringsønsker. Man kan checke i kravspecifikationen (her Furps +) om der er tale om en fejl eller et ændringsønske. 42

47 Testområde: BRUGERTEST OG FEEDBACK FRA ITEMP Projektnavn: Hovedopgave ITempSys Prioritet: Omgående = O, høj = H, mellem = M, lav = L. Fejlstatus: Godkendt = G, Mangler = M, Fejl = F, Rettet = R. Fejlstatus Prioritet Administrator logger på og opretter vikar, tilføjer en vikarnote og ændrer informationer undervejs. G O, Rettet Vikaren l åbner sin og læser indholdende kontoplysninger (brugernavn og password), og logger derefter på ITempSys G Administrator logger på finder vikaren i gridview og ændrer vikarens telefonnummer Jan bruger ikke en søgefunktion G O, Rettet Indehaver logger på som vikar, undersøger TreeView og sidestrukturen og logger af igen Brugeren kunne kun logge på og se siderne G O, Rettet Gik igennem sitets opbygning og navigation G O, Rettet Alfatesten og Accepttesten Ved alfatasten tester kunden systemet med et indhold som denne selv definerer i et miljø som leverandøren selv leverer. Kunden afprøver systemet i et stabilt driftsmiljø (systemet går ikke ned ved forkerte handlinger) hos udviklerne. Udviklerne får mulighed for at afprøve brugerens forventninger. Nogen større planlægning er ikke nødvendig ved en alfatest. Betatesten Viser, hvordan systemet opfører sig under virkelig brug. Systemet bruges i det daglige arbejde i en længere periode. Under en betatest testes systemet i op til flere uger eller måneder på udvalgte steder, og under virkelige forhold (kunden bruger den i hverdagen). Forberedelsen til betatesten er en alfatest, samt sikring af at alt virker. Accepttesten Accept af hele systemet. Dokumentation. Skal være fejlfrit. Accepttesten er hvor kunden skal teste systemet og afgøre om systemet opfylder kundens krav. Under testen må der ikke opstå fejl. Testen kan tage fra et par timer op til flere dage. Der er meget på spil En kontrakt/furps+, der angiver hvad der kræves af systemet, er derfor en god ting. Der er ikke udført beta- eller accepttest under projektet. Systemet skal evt. udbygges senere, der eksisterer ikke et færdigt system og der er ikke tid til det. Brugervenlighed Brugervenligheden blev testet via medbragte GUI forslag. Der blev ligeledes interviewet samt observeret mens kunden udførste user stories. 43

48 I TERATION 2 24/9 8/10 T EST : ITERATION 2 Opret vikariatordre opret arbejdsgiver + opret vikariatordre Testområde: KOMPONENTEST OG FEJLRAPPORT, ITERATION 2 Projektnavn: Hovedopgave ITempSys Prioritet: Omgående = O, Høj = H, Mellem = M, Lav = L. Fejlstatus: Godkendt = G, Mangler = M, Fejl = F Fejlstatus Prioritet G O, Rettet OpretArbejdsgiver: validering på firmanavn, tlf, adresse, post nr, by, skal undersøges og testes G O, Rettet Kun bogstav er mulig i OpretArbejdsgiver.aspx tbxfirmanavn. Lange tekster i teksboksene G H, Rettet Det er muligt at indstaste postnumre. Skal være ReadOnly G O, Rettet Radiobutton bruger kommer vikarnote ikke frem igen G O, Rettet [Skriv noter om vikaren her] indsættes i databasen G O, Rettet Prioritet Ved indsættelse af arbejdsgiver: Violation of UNIQUE KEY constraint UQ ARBEJDSG A9D C69FAC. Cannot insert duplicate key in object DBO.ARBEJDSGIVER. The statement has been terminated. Integrationstest Testområde: SYSTEMTEST OG FEJLRAPPORT FOR SYSTEMTEST Projektnavn: Hovedopgave - ITempSys Prioritet: Omgående = O, Høj = H, Mellem = M, Lav = L. Fejlstatus: Godkendt = G, Mangler = M, Fejl = F, Rettet = R. Fejlstatus Oprette arbejdsgiver rediger, slet Problemet med Du er logget ind som er nu løst G Oprette vikariatordre, og redigere den og slettes G Tilføj/fjern vikar til vikariatordren vikariat opstår G 44

49 Testområde: BRUGERTEST OG FEEDBACK FRA ITEMP Projektnavn: Hovedopgave ITempSys Prioritet: Omgående = O, høj = H, mellem = M, lav = L. Fejlstatus: Godkendt = G, Mangler = M, Fejl = F, Rettet = R. Fejlstatus Prioritet Oprette arbejdsgiver og tilknytte arbejdsgiveren til en vikariatordre G O, Rettet Åbne vikariatordren og ændre denne ved at fjerne en vikar og tilføje en anden vikar Skal deles op i to sider G O, Rettet Fejlstatus Prioritet Testområde: BRUGERVENLIGHED Projektnavn: Hovedopgave ITempSys Prioritet: Omgående = O, høj = H, mellem = M, lav = L. Fejlstatus: Godkendt = G, Mangler = M, Fejl = F, Rettet = R. Han kunne godt lide farverne, men det var ikke vigtigt CSS CSS er baseret på HTML og forstår derfor ikke ASP.NET koncepter som properties. Til dette har Microsoft udviklet themes, som virker efter samme regler som CSS, men virker på server controls. CSS implementeres af browseren, men Themes er noget ASP.NET tilfører når siden renderes Typer af styles Inline style Inline style skrives direkte inde i selv HTML tagget Figur 16: Inline Style til en paragraph Stylingen i Figur 16 vises som en sort baggrund med hvid tekst i fed format. Inline styling er upraktisk, hvis man elementer, der skal formattering. Ved inline styling skal man ændre formatteringen i hvert element manuelt. Inline styling kan bruges, hvis man har en paragraph eller en control, som kun forekommer én gang. 45

50 Internal Style Sheet Internal Styles laves i head sektionen, hvor man mellem <style> tags skriver sine regler på selve siden. Med internal style sheet sepererer man formatteringen fra selve indholdet på siden. External style Sheet Ved external style sheet placeres stylingen i en separat css-fil. I vores projekt har vi anvendt external style Sheet (filen hedder StyleSheet.css). Teknikken giver mulighed for at tiløre de samme styles til flere sider. Retter man i style sheetet slår ændringen igennem på alle sider. Figur 17: CSS-filen linkes til Master Page Style sheetet i ITempSys indsættes i Figur 17 som link i <head> sektionen i Master Page. Dette gør det muligt at anvende de definerede rules som StyleSheet.css indeholder Model View Controller (MVC) I ITempSys har vi en en database, og en model. Vi ved der skal en GUI på. Der skal testes og foretages ændringer i GUI en. Model View Controller er et mønster, der diskuteres meget. Bl.a. Microsoft og folk på nettet har forskellige måder at gengive MVC på10. Nedenstående gennemgang tager udgangspunkt i Martin Fowlers måde at forstå og implementere MVC på (i bogen Patterns Of Enterprise Application Architevhture ). Fowler vælges af flere grunde. Fowler er en pensumbog, og måden den beskrives på i bogen giver mest mening og passer bedst til ITempSys projektsituationen. View Controller Model 46 Figur 18: Model View Controller, side 329, Patterns Of Enterprise Application Architevhture 10

51 Model er et objekt. Var vores metode Larman ville man sige objektet indeholder informationer, der er relevante for Domain Model (Domænemodellen). Objektet indeholder de metoder samt data der ikke bruges i viewet. I ITempSys kunne dette være vikarklassens metoder til oprettelse af vikar og ændring af vikarinfo. View er det visuelle display af modellen. Viewet viser de informationer vi har om vikaren fra modellen i form af en html renderet ASP.NET. Controlleren tager sig af de ændringer der foretages i viewet. Controlleren tager imod al input fra brugerens tastatur input og museklik samt opdaterer modellen. Controlleren sørger ligeså for opdateringen af viewet. Med udgangspunkt i Visual Studio er alle.aspx-filer view, aspx.cs er controller og cs-filer er model (inklusive filer i App_Code). MVC anvendes fordi: Det er nemmer at teste objekter end visuelle ting presentation adskilt fra view. View er afhængig af modellen. Dem, der koder modellen behøver ikke tænke på GUI og omvendt. Det er muligt at lave ændringer af GUI løbende. Faktisk kan GUI en helt skiftes ud med en anden. Der kan foretages ændringer på de tre lag uafhængigt af hinanden MVC øger testbarheden. Det er vanskeligere at lave automatiserede tests af et user interfaces end en model. Modellens afhængighed af interfacet begrænses. Der er kodet en Unit Test. Selv viewet testes manuelt ved systemtest og brugertests. 3. ITERATION : 8/10 21/10 Test til iteration 3 Komponenttest Som i iteration 1 og 2 er der løbende lavet komponenttest under selve kodningen. Integrationstest Der er anvendt TortoiseSVN, og der er derfor som i iteration 1 og 2 lavet daglige integrationstests. Systemtest For at kunne lave en timeregistrering forudsættes der, at arbejdsgiver, vikariatordre og vikar er oprettet. En timeregistrering kan godkendes eller slettes. Slettes en vikariatordre slettes timeregistreringen ligeså. En timeregistrering kan slettes for en person. Registreringer foregår automatisk. Vikaren logger ind og systemet finder vikariatordren, som vikaren er tilknyttet på den pågældende dato og tidspunkt. Systemet registrer automatisk mødetid ved login og gemmer registreringen i databasen. Samme procedure foregår ved RegistrerFyraften. 47

52 Testområde: SYSTEMTEST OG FEJLRAPPORT FOR SYSTEMTEST Projektnavn: Hovedopgave - ITempSys Prioritet: Omgående = O, Høj = H, Mellem = M, Lav = L. Fejlstatus: Godkendt = G, Mangler = M, Fejl = F, Rettet = R. Fejlstatus Prioritet Vikar logger på og registrerer mødetid. Logger af og registrerer fyraften G O, Rettet Administrator ser timeregistreringer og godkender disse, som kommer med på en lønseddel. Godkendes den ikke kommer den ikke med på lønsedlen Problemet med Du er logget ind som er nu løst G O, Rettet En administrator skal kunne slette en vikar. Testområde: BRUGERTEST OG FEEDBACK FRA ITEMP Projektnavn: Hovedopgave ITempSys Prioritet: Omgående = O, høj = H, mellem = M, lav = L. Fejlstatus: Godkendt = G, Mangler = M, Fejl = F, Rettet = R. Fejlstatus Prioritet Administrator logger på kigge på timeregistreringer og godkender nogle og lader andre være G O, Rettet Kigger på timeregistreringer og sletter en vikar. Sletter Vikariatordre og sletter timeregistreringer dertil og alle dertil knyttede vikarer Skal deles op i to sider G O, Rettet Sletter timeregistrering for én vikar G O, Rettet Fejlstatus Prioritet G O, Rettet Testområde: BRUGERVENLIGHED Projektnavn: Hovedopgave ITempSys Prioritet: Omgående = O, høj = H, mellem = M, lav = L. Fejlstatus: Godkendt = G, Mangler = M, Fejl = F, Rettet = R. Han kunne godt lide farverne, men det var ikke vigtigt 48

53 4. ITERATION : 21/10 4/11 Dette er projektets sidste iteration. Der er planlagt et møde med kunden efter rapporten er afleveret. SMS Gateway Kunden ønsker at kunne sende SMS til vikarerne i systemet. For at kunne løse denne forespørgsel har vi skulle sætte os ind i hvilke muligheder, der er for at sende sms via computeren. Efter research har vi fundet frem til at de 2 mest udbredte måder, at implementere en sms gateway på er Metode 1 Direct To Mobile Gateway Appliance En løsning hvor systemet har et integreret GSM modem, og kan sende og modtage sms beskeder via dette. Et GSM modem har et sim kort installeret fra en teleudbyder, via dette kan GSM modemmet få lov, at oprette forbindelse til telenettet, og levere eller modtage sine sms beskeder fra teleudbyderens besked Central. En så kaldt SMSC. 49

54 Metode 2 Direct To SMSC Gateway Direkte til Short Message Service Center er en metode, hvor systemet ikke behøver at have forbindelse til telenettet, men i stedet hat forbindelse direkte til en teleudbyders SMSC (Besked central) via internettet. En besked central er en enhed, der modtager SMS beskeder og sørger for, at de bliver leveret videre til den rette modtager. Hvis modtageren ikke er tilgængelig, opbevarer besked centralen beskeden indtil modtageren er tilgængelig. Hvis man vælger at benytte denne løsning opretter man sig som bruger hos udbyderen, og får en destinationsadresse og login oplysninger til udbyderens beskedcentral, som man så kan integrere i sit program sammen med en tredje eller fjerde parameter, der selvfølgelig er selve beskeden og modtagerens adresse. Fordelen ved denne løsning frem for den første er, at man her har mulighed for, at skjule sin afsender identitet, hvilket betyder at modtageren ikke kan svare tilbage. I den første løsning, kan man ikke skjule sin afsender identitet, da man identificer sig via det tfl. nr. der er indkodet i simkortet, og det er ikke muligt at skjule. Da vi præsenterede disse to løsningsforslag for ITemp ønskede de løsningsforslag nr. 1 med GSM modemmet, da han er teknisk interesseret og ønsker at drive alt sit IT selv. Herefter gik vi i gang med, at undersøge hvordan, man kommunikerede med et GSM modem så vi via computeren kunne give modemmet besked på at sende en SMS besked. For at kommunikere med et GSM modem via en computer, bruger man såkaldte AT kommandoer. Her følger et udsnit af nogle af disse. 50

55 AT kommando Funktion +CMGS Send besked +CMSS Send besked fra lager +CMGR Læs besked +CMGL List beskeder +CMGW Skriv besked til hukommelse +CMGC Send kommando Disse kommandoer kan anvendes i følgende 2 modes. SMS Text mode SMS text mode er en måde at kommunikere med et GSM modem på, hvor man starter med AT kommandoen efterfulgt at modtagerens mobil og til sidst selve beskeden. Eksempel: AT+CMGS= Her skal beskeden skrives SMS PDU mode PDU mode er en måde at kommuniker med GSM modemmet på, hvor man starter med AT kommandoen, og derefter følger en hexadecimal streng, der indeholder en masse informationer, her i blandt nummeret til SMSC, nummeret til modtageren samt selve beskeden. I PDU mode bruges tal værdier, der gør det ud for de At kommandoer, man bruger i SMS text mode her følger nogle af disse. Message stats Defined value in text mode Defined value in PDU mode Received unread REC UNREAD 0 Received read REC READ 1 Stored unread STO UNSENT 2 Stored read STO SENT 3 All messages ALL 4 Eksempel: Her følger et eksempel der indeholder samme besked som SMS Text mode eksemplet AT+CMGS= F001000A C8B21C345F87D BE2E93CB6ED07C2D4FDB CB73 Selvom det lige umiddelbart virker noget mere omstændigt, at anvende PDU mode, bliver den tit anvendt, da man i PDU mode har kommandoer tilgængelige som man ikke har i SMS Text mode. F.eks. kan man i PDU moderedigere i headeren på beskeden, og det kan men ikke i SMS Text mode. Det er også PDU mode vi har valgt at anvende i vores løsnings forslag, da vi på nettet fandt en dll. der var skrevet i c#.net man kunne hente gratis, og den gav mulighed for man via få metodekald kunne kommunikere med et GSM modem, og sende SMS beskeder via PDU metoden. 51

56 E LEKTRONISK LØNSEDDEL I PDF- FORMAT Til at generere pdf lønseddeler har vi benyttet et frit tilgængeligt class library til c# ved navn Itextsharp. Selve genereringen af lønseddelen består af følgende trin. Brugeren indtaster en periode der skal genereres lønseddeler for Når perioden er indtastet henter systemet alle de godkendte timeregistreringer for denne periode. Og gemmer disse i list Systemet løber listen af timeregistreringer igennem og laver en liste der indeholder alle de vikariater, samt en liste der indeholder alle de vikarer der er lavet timeregistreringer i perioden. Nu er alle de oplysninger der skal bruges til at generere lønsedlen blevet hentet, og oprettelsen af selve lønsedlen begynder først tilføjes stamdata på løn modtageren samt vikar bureauets oplysninger og logo, og herefter følger en liste for hvert enkelt vikariat der udspecificeres i hvilke datoer vikaren har været på arbejde på det pågældende vikariat, og hvor mange timer samt hvad der udbetales i løn for dette vikariat. Til sidst følger en sum over hvad der bliver udbetalt i alt for alle vikariater. Punkt 3 er et loop der gennemløbes for alle vikarer der har arbejdet i perioden. Selve opsætningen af pdf dokumentet forgår ved at tilføje såkaldte paragraphs til dokumentet. Paragraphs er kasser hvori man kan tilføjer billeder, tekst og andre grafiske elementer, tekst tilføjes dog ikke direkte til en paragraph men til en såkaldt chunk som er en klynge af tekst. Når man har lavet en chunk af tekst kan denne så tilføjes til en paragraph. En paragraph kan tilføjes til dokumentet lige på den position man ønsker enten ved at specificere f.eks left, center, eller right. Men kan også placere en paragraph på det mere specifik punkt i dokumentet ved at angive x og y koordinater. Her følger at udsnit af vores pfd generering og formatering. Image logo = Image.GetInstance(Path.GetFullPath("ITempLogoSmall.png") logo.alignment = Element.ALIGN_RIGHT; pdfdokument.add(logo); Paragraph firmap = new Paragraph(); Chunk firmaadr = new Chunk("Lønperiode: "+d.date.tostring("dd-mm-yyyy")+" "+d1.date.tostring("dd-mm-yyyy")+"\ni Temp Odense\nVestergade 50, 1. sal\n5000 Odense C", FontFactory.GetFont("Arial", 12)); firmap.add(firmaadr); PdfPTable header = new PdfPTable(2); header.defaultcell.border = 1; header.widthpercentage = 100; Paragraph p = new Paragraph(); Chunk overskriftloenmodtager = new Chunk("Lønmodtager\n\n", FontFactory.GetFont("Arial", 14, Font.BOLD)); p.add(overskriftloenmodtager); p.add(vikarinfo); header.addcell(p); header.addcell(firmap); pdfdokument.add(header); 52

57 T EST TIL ITERATION 4 Komponenttest Som i iteration 1, 2 og 3 er der løbende lavet komponenttest under selve kodningen. Integrationstest Der er anvendt TortoiseSVN, og der er derfor som i iteration 1, 2 og 3 lavet daglige integrationstests. Systemtest Testområde: SYSTEMTEST OG FEJLRAPPORT FOR SYSTEMTEST Projektnavn: Hovedopgave - ITempSys Prioritet: Omgående = O, Høj = H, Mellem = M, Lav = L. Fejlstatus: Godkendt = G, Mangler = M, Fejl = F, Rettet = R. Fejlstatus Prioritet En vikar logger på og retter sine vikarinfo f.eks telefonnummer G O, Rettet En vikar logger på og ændrer sit kodeord. G O, Rettet En vikar får tilsendt sit kodeord G O, Rettet Admin logger ind, tilknytter vikar til eksisterende vikariatordrer, i det der trykke få tilføj knappen, med info om vikariatet. Trykker på sms knappen. G O, Rettet En vikar logger på og finder pdf for vikarer. Se lønseddel G O, Rettet A LTERNATIVE METODEMULIGHEDER XP er iterativ og inkrementel uden at være ekstremt eksperimenterende. Der laves architechtural spikes. En kunde kan forkaste en løsning, men XP er ikke Rapid Application Prototyping (RAP). Der skal vises noget frem for kunden hyppigt og hurtigt. RAP lægger vægt på prototyper et eksempel er DSDM, som er RAP og en viderudvikling fra RAD, hvor det er som at skyde en kanon af mod målet fokus mod et mål ud fra møder med de korrekte personer. XP bygger på værdier eller som XP selv kalder det principles. Kommunikation og fællesskab, som vises ved pair programming. Til at undersøge, hvilke metoderne der kunne være interessant, at tage udgangspunkt i det Det Agile Manifest, der siger: menneskelige interaktioner frem for processer og værktøjer software, der kan fremvises frem for et gennemdokumenteret system kundesamarbejde frem for kontrakter og forhandlinger imødegåelse af forandringer frem for slavisk at følge en plan 53

58 UP Craig Larman UP antager et projekt kan planlægges på forhånd. Indeholder mange navngivne aktiviteter. Metoden er trinvis og ikke eksperimentel. Den kan bruges til ny- eller videreudvikling af et OOsystem, og kan ikke bruges til et system, der ikke er objektorienteret. Output er et kørende IT-system, der giver forretningsværdi og dokumentation i form af sammenhængende dokumentationsmodeller. UP hælder mere til gennemdokumenterede systemer. De funktionelle krav fastlægges via use cases. Alle use cases udgør kravspecifikationen. UP egner sig ikke til projektet. Det er en stor og indviklet metode. Den er svær at sætte sig ind i. Det er ikke realistisk at udviklerne sætter sig ind i alle rollerne, eller de færdigheder metoden kræver. At skrive use cases er for omstændigt, tager for lang tid og kræver en grundig foranalyse af end brugerens behov. UP ligges vægt på komplet dokumentation af hele udviklingsforløbet og produktet. Metoden er en stor metode, og man vil kunne finde løsninger på ens problemstillinger. Metoden indeholder standarder udviklere kan søge vejledning i. Problemet med UP i forhold til vores projektsituation er den fokuserer på dokumentation på bekostning af kode. DSDM DSDM lægger vægt på menneskelige interaktioner, færdig software, kundesamarbejde og imødegåelse af forandringer, men på samme tid er der mange processer, megen dokumentation og forhandlinger. Dette gør metoden kompatibel med større organisationer. Den er beregnet til at tilpasse sig et corporate environment. Tid og ressourcer er i DSDM fastlåste. Det der kan varieres er funktionaliteten. Der laves feasibility studies. DSDM tager udgangspunkt i samarbejde mellem udviklerne og interessenterne. Den indeholder et hav af artefakter og roller. DSDM er en stor metode. Den kræver licens. Har mange roller og artefakter. Der kommunikeres med ledelsen via status rapporter. Dette kræver for megen tid og papirarbejde, og er spild af tid og ressourcer. Scrum Scrum og DSDM har mange lighedspunkter. De er begge agile, inkrementelle og fokuserer på styringen af software projekter. Begge kan samarbejde med XP. Scrum er en metode til styringen af udvikling, mens XP er en metode, der indeholder teknikker og practices til selve konstruktionen. 54

59 A NVENDELSEN AF XP På de følgende sider projektlederdelen af projektet. XP beskrives som metode, og den praktiske anvendelse af XP beskrives. XP Extreme programming XP er en agil udviklingsmetode, hvilket vil sige at den lægger vægt på, at systemudviklingen er en uforudsigelig process, hvor der undervejs kan opstå problemer eller for den sags skyld løsninger, der vil gøre at den plan der på forhånd er lagt, skal ændres. I det følgende vil vi prøve at give en kort beskrivelse af, hvordan XP bliver udført i praksis, samt hvilke elementer af XP vi vil bruge i vores projekt. Beskrivelse af XP: XP er en iterativ metode hvor fokus i høj grad er på, at få gang i kodningen så hurtigt som muligt, således at man allerede tidligt i projektet vil kunne fremvise resultater for brugeren. Brugeren vil under hele forløbet være i fokus, og det er denne der bestemmer i hvilken rækkefølge tingene prioriteres. XP bygger på 5 hovedprincipper11: Kommunikation Udviklere og brugere skal være i konstant dialog omkring systemet Simpelhed Start med den nemmeste løsning, resten kan komme senere Feedback Her har tests en afgørende betydning Mod Det kræver mod at bryde med de traditionelle systemudviklingsmetoder Respekt Ved gensidig respekt vil arbejdsmoral og motivation øges Det er en afgørende faktor i XP, at der er et vist tillidsforhold mellem kunden og udviklerne. Da man ikke fra starten vil kunne sige, om alle funktionaliteter vil kunne implementeres indenfor tidsgrænsen. Netop det faktum, at man ikke fra starten vil kunne love kunden alt for meget, gør at kunden bliver nødt til at have tiltro til, at udviklerne kan deres ting og nok skal nå det der skal nås. Tilliden opretholdes netop ved hjælp af kommunikation, altså sørge for kunden bliver taget med i hele processen. Når man benytter XP i praksis, vil der være 12 core practices der lægges vægt på. Disse er: Planlægning, eller planning game som det beskrives i bogen. Små udgivelser med korte mellemrum, iterativ udvikling Systemmetafor Simpelt design Test Refactoring 55 Parprogrammering 11 Kent Beck, Extreme programming explained, kapitel 7

60 Fælles ejerskab af koden Kontinuerlig integration Overkommeligt arbejdstempo Samlet udviklingshold Fælles kodestandard I det følgende vil vi prøve at beskrive de 12 core practices, og hvad de går ud på hver især. Vi vil starte med at give en beskrivelse af XP s planning game, og herfra tage punkterne én for én. Planning game: Planning game vil typisk foregå indenfor hver iteration. Der holdes et møde, hvor de i det følgende beskrevne aktiviteter, vil foregå. Planning game består af to faser, som hver især har flere faser tilknyttet. Første fase af planning game er udgivelsesfasen. I denne fase arbejder både udviklere og brugere sammen om at få aftalt hvilke dele af systemet, der skal udgives og hvornår. Denne fase har 3 underfaser tilknyttet: Exploration fasen Commitment fasen Steering fasen Exploration fasen(udgivelses): I denne fase vil man bede brugeren komme med funktionaliteter til systemet. Disse nedskrives som user stories. Udviklerne vil så for hver user story komme med et bud på hvor længe det vil tage at udvikle denne funktionalitet. Hvis udviklerne ikke kan komme med et ordentligt tids estimat, kan de bede brugere om enten at uddybe eller bryde user storien ned i mindre dele. Commitment fasen(udgivelses): Hovedformålet i denne fase er at få brugeren til at foreslå dato for næste release, samt for udviklerne at forpligte sig til at levere det aftalte produkt. Her vil brugere opdele user stories i 3 kategorier: De funktionaliteter der er essentielle for at systemet kan fungere, dem der er mindre vigtige, men som stadig har vigtige funktioner, og til sidst dem som bare ville være rare at have. Ligeledes til udviklerne inddele i 3 kategorier: Dem som man nemt kan estimere på hvor længe de vil tage, dem man kan give et nogenlunde bud på, og dem som man slet ikke kan sige noget om. Udviklerne vil så i samarbejde med brugeren vælge hvilke user stories skal implementeres først, samt sætte dato for udgivelser. Hertil skal siges at det er brugeren der altid vil have det sidste ord. Steering fasen(udgivelses): Formålet med denne fase er at følge op på de planer man har lagt i de tidligere faser. Her vil man kunne rette hvis de estimater man har lagt ikke holder, eller man f.eks. har brug for en ny user story for at kunne udføre en given funktionalitet. Næste aktivitet i planning game er iteration planning. Til forskel fra udgivelsesfase, vil det her kun være udviklerne der er i centrum. Iteration fasen består ligeledes af 3 forskellige faser: Exploration fasen(iteration): Her laver udviklerne Task cards. Disse vil beskrive de opgaver der skal laves indenfor den givne iteration. Typisk vil der være knyttet flere task stories til hver user story, men såfremt et tast card viser sig at være for omfangsrig, kan dette nedbrydes til mindre task stories. Commitment fasen(iteration): Her vil programmørerne påtage sig ansvaret for en given task. Herefter vil vedkommende komme med et estimat over, hvor lang tid tasken ideelt set vil tage at implementere. Hvis en task tager for længe, skal denne splittes ned i mindre dele. Herefter vil hver programmør komme med et estimat omkring hvor stor en procent af tiden de rent faktisk vil bruge på udvikling indenfor iterationen, og til slut vil man kunne se om nogle programmører har for meget arbejde. 56

61 Steering fasen(iteration): Udviklerne udvælger hver især task cards. Derpå udvælges en partner til hver udvikler, og der påbegyndes programmering og tests. I denne fase vil man også med nogle dages mellemrum se på om folk har for mange arbejdsopgaver, og tilrette hvis dette er tilfældet. Små udgivelser med korte mellemrum, iterativ udvikling: Fokus skal være på brugeren, og man skal konstant holde denne opdateret og fremvise resultater. Systemmetafor: Fælles forståelse for begreber og standarter Simpelt design: Sørg for at holde fokus på enkelt design, evt. modernisme Test: Løbende tests, test ofte og grundigt. Refactoring: Optimer koden Parprogrammering: Programmering foregår i par bestående af to personer. Kun en programmerer af gangen, mens den anden holder øje med, og kommer med input eller rettelser. Fælles ejerskab af koden: Fælles begreber, standarter og ejerskab sikrer kontinuitet og forståelse. Kontinuerlig integration: Holder processen i gang og gør, at kunden hurtigt får en fornemmelse af at der sker noget. Overkommeligt arbejdstempo: Man kan nå det man kan nå, folk skal helst ikke arbejde mere end 40 timer om ugen. Samlet udviklingshold: Ingen kører sololøb, alle er konstant med i processen. Fælles kodestandard: Som tidligere beskrevet. Vores XP: Da vi ikke tidligere har arbejdet med XP, har vi på forhånd måtte finde ud af hvilke dele af denne metode, der ville passe til vores projekt, samt om der var punkter, hvor vi måtte afvige fra normen. Vi vil så vidt det er muligt prøve at holde fokus på de 12 core practices. Vi har dog på fornemmelsen af bl.a. kontakt til kunden vil være skubbet lidt i baggrunden, da ITemp simpelthen ikke kan sætte tid nok af til os. Vores planning game vil også være en noget modereret udgave i forhold til det som Kent Beck beskriver. Da funktionaliteterne i vores system mest kan beskrives som værende essentielle for at systemet kan fungere, vil prioriteringen af user stories, afhænge mere af hvad der kan lade sig gøre at lave hvornår, end en egentlig prioritering. Vi bliver også nødt til at lave mere eller mindre samtlige user stories på en gang, da vi ikke kan være sikrer på at ITemp har tid når vi har brug for det. Derfor vil vi køre planning game igennem én gang, når vi starter første iteration. Vi vil prøve at lægge en plan for hele iterations forløbet, altså hvilke user stories der hører til i hvilke iterationer. Indenfor hver iteration skal vi have minimum et møde med ITemp, hvor vi fremlægger de ting der er planlagt til den givne iteration. 57

62 Da vi har en rapport der skal laves også, vil der være punkter, som vi vil gå mindre i dybden med end normalt foreskrives i XP. Her tænker vi især på refactoring og til en vis grad tests. Vi vil selv internt lave både unit tests samt grey box tests, men ITemp har gjort det klart for os, at de ikke har tid til at foretage brugertests, som ellers er en stor del af XP. Refactoring omhandler omskrivning af koden, så denne bliver mere effektiv. Vi vil gøre det i det omfang, at det foregår mens vi parprogrammere. Altså mens den ene programmør sidder og programmere, vil den anden følge med og komme med forslag til forbedringer af koden. Vi vil ikke decideret bruge tid på at lave refactoring, når koden først er skrevet, med mindre at visse svar tider osv. er alt for lange. De andre punkter i XP, er mere i retning af guidelines for hvordan man rent praktisk arbejder, og disse vil vi så vidt det er muligt prøve at holde os til. Delkonklussion: XP er en metode der er god at bruge i mange forskellige situationer. Metoden kræver dog et godt tillidsforhold mellem brugeren og udviklerne, da planlægningen er meget løs og det vil umiddelbart være svært fra starten af projektet at sige om alle funktionaliteter vil kunne nås, indenfor det angivne tidsrum, eller for den sags skyld indenfor det økonomiske råderum. XP lægger op til tæt samarbejde både internt, samt med den virksomhed man laver projektet for. T EKNIKKER DER HJÆLPER MED OVERBLIK : Inden at vi skal i gang med at programmere, mener vi det er vigtigt, at vi får dannet os et overblik over flere ting. Heriblandt skal vi gerne have en nogenlunde ide om, hvad vi kan nå i løbet af de 3 måneder vi har, og også gerne kunne lægge en nogenlunde realistisk tidsplan. Vi har allerede på nuværende tidspunkt lavet vores risiko, interessent samt turbo analyse, men vi føler lidt at vi mangler noget visuelt, til at give os et overblik over situationen. I denne forbindelse har vi valgt at gøre 2 ting. Vi vil benytte os af 2 teknikker, som vi mener, kan hjælpe os i denne situation. Den første teknik er Rich pictures. På trods af at vi har lavet en interessent analyse, og dermed fået analyseret de forskelliges interesser i systemet, vil vi lave noget tilsvarende, men trods alt mere visuelt, for at vi hurtigt og nemt kan få et overblik over de forskelliges interesser. Den anden teknik vi vil benytte er et klassediagram. Rich pictures: Rich Pictures bruges i mange tilfælde, hvor man ønsker at danne sig et overblik over en given situation. Ofte vil det være i tilfælde, hvor man har en kompleks opsætning. Når man bruger denne teknik er det vigtigt at gøre klart for sig selv, at dette ikke er en beskrivelse af systemet og dets funktioner, men er et billede af de menneskelige faktorer og deres interesser, samt samspillet mellem disse, og at meningen er at skaffe et overblik over firmaet og dets interesser samt de personer der er knyttet dertil. Vi har valgt til at starte med at lave 3 forskellige Rich Pictures. Første RP omhandler selve firmaet og folkene omkring det. Dette svarer til Picture 1 På bilag: Rich pictures. Picture 2 beskriver hvordan samspillet mellem de forskellige interessenter foregår, f.eks. hvordan en vikar kommer i kontakt med firmaet. Dette laver vi for at få en bedre forståelse af hvilke interessenter der kunne være og hvordan samspillet mellem disse vil være. Gennem dette vil vi få et bredere overblik over hvordan firmaet fungerer i praksis. På det næste RP ses en vikar, og hvilke interesser denne kunne have i forhold til ITemp. Sidste RP, som kan ses på picture 3 beskriver en medarbejder hos ITemp og hvad dennes interesser kunne være i forbindelse med deres arbejde. 58

63 Disse rige billeder giver os generelt et godt overblik over hvilke interesser de forskellige aktører har i forhold til ITemp. Vi vil derfor forhåbentligt have nemmere ved at finde frem til forskellige løsninger når vi kender de forskellige aktører, samt deres interesser. Det giver os desuden et udmærket overblik over nogle af de klasser vi evt. skal have oprettet for at få systemet til at fungere. Klassediagram: Et klassediagram viser klasserne i systemet samt sammenhængen mellem disse. Det klassediagram vi laver her i starten er meget simplificeret. Dens eneste formål er at give os et overblik over de mest essentielle klasser, og sammenhængen mellem disse. Der ligger meget mere arbejde i hver klasse end dette klassediagram umiddelbart giver udtryk for, f.eks. såsom arbejde med GUI osv. Vi vil dog have et nogenlunde overblik over hvilke klasser der kan laves hvornår og dermed kan vi planlægge i hvilken iteration vi laver dem. Her et billede af vores klassediagram: 4 værdier For bedre at kunne få kunden til at forstå de dilemmaer, man som udvikler står overfor, har Kent Beck beskrevet en lille leg. 12 I denne indgår 4 værdier. Disse er penge, tid, kvalitet og scope. Udgangspunktet for denne leg er at brugeren må vælge 3 af disse ting, som denne vil have indflydelse på. Udvikleren må så få den sidste, og ud fra de ting som brugeren siger, vil udvikleren så kunne sige om det er realistisk eller ej. For at give et kort eksempel: Brugeren vælger, at vi skal have et system færdigt indenfor 3 måneder. Penge er ikke noget problem og kvaliteten skal være i top. Nu er det så udviklerens tur til at fortælle brugeren hvad de indenfor de givne rammer kan få. Desværre vil det kun være muligt at have et scope der ca. kan få halvdelen af funktionaliteterne implementeret pga. tidsrammen Kent Beck, Extreme programming explained, kapitel 7

64 Brugeren vil højst sandsynligt ikke være tilfreds med dette, og vi kan derfor sige til ham, at han kan ændre eller vælge en anden af de 4 værdier at have indflydelse på. Han kunne nu vælge f.eks. tidsrammen fra og i stedet sige at han vil have hele scopet implementeret. Som udviklere ville vi så sige, ja intet problem, men det vil tage 6 mdr. Nu kan brugeren så igen vælge om denne vil acceptere dette. Formålet her vil være at give brugeren en forståelse for hvilke kriterier påvirker hinanden. Man kan ikke få det hele, med mindre man er villig til at ofre tid og penge, hvilket ofte vil være i konflikt med en interessent, der helst vil have så meget som muligt, så hurtigt som muligt, og i så god kvalitet som muligt. Da vi allerede på forhånd har givet en tidsramme for, hvornår vi skal være færdige med vores projekt, bliver vi nødt til at moderere legen en smule. Ellers ville brugeren ikke have mulighed for at vælge tre værdier selv, da tiden allerede på forhånd ville være givet. Vi vælger derfor at bruge denne leg inden første iteration. Ved første møde beder vi derfor brugeren tage stilling til hvilke 3 af disse kriterier han vil bestemme over. Han vælger penge, kvalitet og scope. Han er villig til at betale hvad det koster såfremt han får en ordentlig kvalitet. Kvaliteten skal være i orden, da han ikke kan bruge et fejlbehæftet system til noget. Som Scope ønsker han alle funktionaliteter implementeret, dvs. samtlige user stories skal laves. Vi har altså nu et scenarie, hvor vores bruger ønsker et mere eller mindre perfekt system. Han vil have at vi skal implementere alle de funktionaliteter han har ønsket, men til gengæld er han også villig til at betale for det. Vores kriterium i denne sammenhæng vil så være tiden. Da vi har en deadline for hvornår vi skal aflevere vores projekt, vil vi ikke have uendelig tid til at lave alle funktionaliteter. Dette betyder at vi kan blive nødt til at slække lidt på nogle af de kriterier, som kunden har. I den forbindelse må vi sige til Itemp at vi nok godt vil kunne nå at implementere samtlige funktionaliteter, men da vi er under tidspres vil det ikke være sikkert, at vi kan nå, at teste så intensivt at kvaliteten vil være i top. Der vil i dette tilfælde være 2 muligheder for os. Enten kan vi skrotte noget funktionalitet for så at teste de ting vi får lavet mere grundigt, eller også kan vi lave al funktionalitet, men formentlig i en dårligere kvalitet. Vi opstiller dette dilemma for ITemp, og de vælger, at de ønsker funktionalitet over kvalitet. Her skal det lige siges, at dette ikke vil være ensbetydende med, at systemet bliver af en dårlig kvalitet, men blot at det vil være her, at man hvis noget skal skæres væk, tager fra. Hvis vi skulle give et eksempel på, hvordan vi kunne forestille os, at vi kunne slække på kvaliteten for i stedet at få mere funktionalitet, kunne vi tænke os en funktion hvor noget skal indtastes i GUi en. Her kan laves flere funktioner for at sikre at brugeren indtaster noget der er korrekt. Op til flere fejlmeddelelser og exceptions kunne laves i denne forbindelse. Hvis vi slækker på kvaliteten her kunne vi lave en simpel metode der f.eks. tjekker at det er bogstaver der indtastes, uden at give nogle videre fejlmeddelelser såfremt der indtaste forkert, andet end at input ikke er korrekt. Hvis vi havde mere tid til metoder, som denne kunne vi som sagt putte en masse exceptions osv. på. Dette ville ikke betyde noget for funktionaliteten af systemet, men vil have stor indflydelse på det indtryk brugeren får, samt kan være medvirkende til at skabe forvirring, da folk ikke nødvendigvis er klar over hvad der skal indtastes pga. manglede fejlbeskrivelse. En anden ting vi kunne slække på i forhold til kvaliteten, men hvor vi beholder funktionaliteten, kunne være rediger funktioner. Det er muligt at kunne redigere f.eks. en vikar uden en egentlig rediger metode. Så snart vi har lavet opret og slet metode, kan vi såfremt der skal redigeres på en vikar, bare slette denne og oprette den igen. Rent programmeringsmæssigt ville dette naturligvis være dyrere end hvis vi lavede en decideret rediger funktion, og netop derfor vil der være slækket på kvaliteten uden at have rørt ved funktionaliteten. I vores tilfælde vil det netop være ting som disse, vi må slække på såfremt vi kan se at vi kommer i tidspres, hvilket vi nok næppe kan undgå. Der vil naturligvis være steder, hvor vi ikke vil kunne slække på kvaliteten, men vi må undervejs vurdere, hvor vi kan slække på kvaliteten uden at det påvirker den endelige udgave af systemet for meget. Meningen med denne leg er som sagt at give ITemp et indblik i den problematik vi står overfor, og nogle af de valg vi kan blive nødsaget til at tage undervejs. Det er essentielt i XP at kunden har en forståelse for de problemer man som udvikler står med, ellers kan et tillidsforhold hurtigt briste. Det er bl.a. det at denne leg skal hjælpe med til med at skabe. 60

65 User stories: User stories laves i samarbejde med brugeren, og skal beskrive forskellige funktionaliteter i systemet. Vi har rent praktisk sat os ned med senior manageren fra ITemp og interviewet denne. User stories nedskrives på små kort, og gives i samarbejde med brugeren en prioritet, i forhold til hvornår brugeren ønsker denne funktionalitet implementeret. Her ses et udsnit af vores user stories, med forskellige prioriteter(alle user stories kan ses på Bilag: User Stories ): Som administrativ bruger kan jeg søge efter vikarer på cpr-nr, navn, adresse, postnr og bynavn, , mobilnr, køn, har børn?, tidligere straffet, afleveret strafattest, fagforening, a-kasse, andre vikarbureauer, har bil?, ryger?, aktiv/inaktiv, vikarnote.. Prioritet:(1) Som administrativ bruger skal jeg kunne redigere og slette en arbejdsgiver. Prioritet:(2) Som administrativ bruger skal jeg kunne oprette en ny vikariatordre med beskrivelse, timeløn, antal timer, antal vikarer og arbejdsgiver og periode. Prioritet:(3) Som non-administrativ bruger kan jeg logge ind og registrere hvornår jeg kommer og går på et vikariat. Prioritet: (4) Som administrativ bruger skal jeg have besked om at backupen er foretaget og om der har været problemer. Prioritet:(5) Under normale omstændigheder, vil prioriteringen af user stories være helt og aldeles op til brugeren, men vi er blevet nødt til at tage nogle forbehold. Da det f.eks. vil være upraktisk at gå i gang med en SMS-gateway inden vi har lavet andet overhovedet, bærer vores prioritering i høj grad præg af, at tingene bliver lavet i den rækkefølge det er muligt. Den er dog stadig lavet i samarbejde med brugeren, men med udviklerne som guide for hvad der var muligt, og hvad der ikke var muligt. Det skal hertil siges at brugeren til enhver tid kan komme med flere user stories, eller ændre i prioriteringen af disse, men denne må også være indstillet på, at dette kan medføre, at andre funktionaliteter ikke vil blive nået. Da vi har fået nedskrevet alle user stories, skal vi som sagt i gang med prioritering af disse. Umiddelbart vil vi mene, at vi skal have oprettet en database først, så vi kan begynde at teste så snart vi får lavet nogle klasser. Udover det vil vi gerne have oprettet forskellige brugergrupper med det samme også. Altså skal vi i første omgang finde frem til de user stories der har med databasen og membership at gøre. Det skal lige siges at vi har allerede efter første møde med ITemp, gik i gang med at lave analyse for design af databasen, så når vi skal i gang her, ville skabelonen for denne allerede være klar. Derefter må vi se på hvilke klasser, det vil give mest mening at oprette først. Vi kommer ret hurtigt frem til at vi bliver nødt til at kunne oprette en vikar, og en arbejdsgiver før, at vi vil kunne oprette f.eks. vikariat, da denne skal have disse knyttet til sig. Vi vil derfor prioritere disse som 1 og 2. Vores tredje prioritering vil mest af alt omhandle oprettelse af et vikariat, og tilknytning af vikarer. 4 prioritering kommer til at dreje sig om timeregistrering, samt udskrivning af lønsedler osv. Her vil mest blive lavet funktionalitet omkring GUi en. Det samme vil være gældende for 5 prioritet. Her vil vi dog fokusere mere på de ekstra funktionaliteter såsom SMS gatewayen. Disse prioriteringer bliver som tidligere beskrevet ikke helt som XP foreskriver. Prioriteringerne skal laves efter Itemps ønsker. Eksempelvis var det meget vigtigt for ITemp, at få lavet SMS gatewayen. Derfor ville han egentlig gerne have prioriteret denne som en etter, men da det simpelthen ikke er muligt for os at lave denne før det meste af de andre ting er klar, har vi måtte prioritere den som en femmer i stedet. I et større projekt hvor der skal mere funktionalitet på, vil det nok være nemmere at prioritere om ikke helt, så i hvert fald mere efter kundens ønsker end vi har kunnet gøre. 61

66 Task cards: Når prioriteringen af user stories er lavet, er det tid til at planlægge, hvad der skal laves indenfor første iteration. Vi vælger at køre med iterationer med 2 ugers varighed, hvilket giver os 4 iterationer at arbejde med, før vi skal aflevere vores opgave. Da vi bruger XP vil vi ikke planlægge for meget fra starten, men holde fokus på den aktuelle iteration. Dette betyder ikke at vi ikke kan lægge en overordnet tidsplan, for at danne os et overblik over hvad vi ca. kan nå, men vi skal ikke spilde for meget tid på denne. Rent praktisk gør vi dette ved at lave task cards. Task cards kan bestå af en eller flere user stories. Disse bruges udelukkende af udviklerne. For hver task vil der være en beskrivelse af opgaven, samt en estimering af hvor lang tid det vil tage at udføre denne. Såfremt en task viser sig at være meget omfattende, dvs. altså at denne vil tage meget lang tid, skal man så vidt som muligt prøve at bryde denne ned i mindre dele. Herunder ses et af de task cards vi har lavet. Task cards skrives i hånden, og dette er eneste eksempel, som vi har renskrevet på computer. Vi har indsat et billede af resten disse, som vi har benyttet dem i Bilag: Task Cards. Dette task card er taget fra første iteration: Task card Dato:8/9 og Daniel vikarer. Udvikler: Kasper Task navn: Vikar oprettelse Tidsestimat: 1-2 dage Task beskrivelse: Prioritering: Høj Oprettelse af en vikar, opret, søg og rediger funktion. Kun admins kan oprette Noter: Attributter: crp nr, adresse, postnr og bynavn, , køn, har børn?, tidligere straffet?, fagforening?, andre vikar bureauer?, aktiv/inaktiv, bil?, ryger?, afleveret strafattest?, mobil nr. Når vi udvælger en task, vil det rent praktisk foregå på den måde at en af vores programmører vælger en task ud, som skal laves indenfor den givne iteration. Denne vælger derpå en makker, og disse to programmører går nu i gang med, at programmere denne task. Programmeringen vil foregå som parprogrammering. Der vil løbende blive holdt møder undervejs, hvor der vil blive fulgt op på, hvordan det går med de forskellige tasks. Der kan være mange forskellige tilfælde, hvor man bliver nødt til at ændre på nogle ting. Det kan være at programmørerne ikke arbejder ret intensivt, her ville man måske spørge sig selv, om det vil være en fordel at sætte nogle andre på opgaven. Det kan også være at opgaven simpelthen er for omfattende, og man må enten splitte opgaven op i mindre dele, og så sætte flere folk til at løse dele af opgaven. Her skal vi igen huske, at hvis man blot sætter flere folk på opgaven, vil man bryde med XP s princip om parprogrammering, og det er derfor vigtigt, at få delt opgaven op, og så derpå give de nye tasks videre til andre, der så kan køre parprogrammering i et parallelt forløb. 62

67 Hvert task card er udformet sådan, at der er plads til at skrive forskellige ting. Først kan man registrere den dato, som man har taget tasken. På hver task er allerede skrevet et navn på tasken, samt en beskrivelse af hvad den går ud på. Der er nederst på hvert task card plads til forskellige noter. Her noterer vi f.eks. de attributter, der skal være på en klasse. Når programmøren tager en task er der som sagt allerede noteret en beskrivelse samt evt. noter. Programmøren kan evt. selv tilføje hvis der mangler noget. Ud over dette er der en prioritering. Denne beskriver hvor højt funktionen bliver prioritet, altså er det en livsnødvendig funktion for systemet, eller kan den undværes. Prioriteterne kan være, høj, mellem og lav. Til slut er der til hver task knyttet et sæt udviklere. Programmøren der har valgt task skriver sit eget navn, samt navnet på den person vedkommende skal parprogrammere med. De giver nu et tidsestimat som også bliver påført task cardet. Disse task cards vil være frit tilgængelige for alle, så alle kan se hvad der arbejdes med,og hvor længe disse ting ca. tager. Vi vælger selv at hænge vores tasks op på vores tavle, så de altid er tilgængelige for alle. Det besluttes ud fra vores user stories, hvilke tasks der skal udføres i hvilke iterationer. System metaforer System metaforer er en teknik, der bruges til at beskrive systemet på et sprog, så alle kan forstå det. Disse bruges i forbindelse med flere ting. For det første, er det vigtigt for projektet, at alle har en fælles forståelse hvad de forskellige termer betyder. For det andet kan disse give klarhed over visse problemstillinger, og til sidst skal de angive nogle standarter, som kan bruges både i og udenfor programmeringen. Den største opgave i forbindelse med dette ligger nok i at finde frem til, hvor det lige specifikt er, at der kan opstå misforståelser, og få sat ord på disse så alle kan forstå dem. Da vores projekt ikke umiddelbart er så stort, at det kan være svært at overskue, mener vi også umiddelbart efter samtale med Itemp, at der ikke er mange områder vi behøver belyst på denne måde. Nogle af de ting vi dog har i tankerne er at få forskellige termer på plads. Her gælder f.eks. forskellige definitioner, af de roller der vil være fordelt i systemet: En administrator er en person der arbejder hos ITemp og har rettigheder til at ændre i dele af systemet, hvor der kun er adgang for en administrator. En administrator har adgang til mere end en almindelig bruger Her beskrives en administrator og hvilken funktion denne vil have i forhold systemet. Som det beskrives i starten, er en administrator en person der arbejder hos ITemp. Her understreger vi at der ikke vil være nogen udefrakommende, der kan være administrator. Man vil straks være klar over at for at blive administrator skal man være medarbejder hos ITemp. I næste del beskrives så hvilke rettigheder denne har. Da vi ikke kan specificere præcis hvad det er, at denne administrator har adgang til, må vi i stedet kort beskrive, at der er visse dele af systemet som administratoren har adgang til, som ingen andre har adgang til. Dette skulle gerne føre til, at der aldrig vil være tvivl om hvad en administrator er og hvad dennes funktion er i forbindelse med systemet. Ligeledes har vi her dannet nogle standarter, som vi vil bruge hele vejen gennem projektet. F.eks. en administrator. Dette er en rolle som nu er defineret, og uanset om den bliver brugt af programmører, systemudviklerne og kunderne, vil alle have samme opfattelse af hvad denne er. En anden rolle som ses ud fra denne system metafor er bruger. Dennes rolle er dog endnu ikke blevet beskrevet, men det gør vi i næste metafor: 63

68 En bruger er en person der har en forbindelse til ITemp og dermed har fået oprettet en profil i systemet. Brugeren har ikke adgang til administrative dele af systemet, men har adgang til at ændre personlige data og funktioner der er tilladt folk der får tildelt status som bruger. Igen bliver der her beskrevet en rolle i systemet. Dette betyder at vi indtil videre har 2 roller der skal oprettes, med forskellige rettigheder. Det fremgår tydeligt af disse to metaforer, at det er administratoren der vil have de fleste rettigheder. Brugerens adgang er ikke beskrevet ned i detaljer, men det fremgår at der er visse ting i systemet som de vil have tilladelse til at ændre, mens der er andre dele de ikke vil have nogen indflydelse på. Det bliver også klart at for at være bruger, skal man på den ene eller anden måde være tilknyttet ITemp. Så man kan altså ikke få bruger rettigheder med mindre man registrere sig hos ITemp. Den sidste rolle, der er i forbindelse med systemet, har vi også beskrevet med en metafor: En gæst er en bruger af systemet, som ikke har nogen tilknytning til ITemp. Denne vil hverken kunne se ting, som administratorer eller brugere har adgang til, men vil udelukkende kunne se ting på siden som er offentligt tilgængelige. En hvilken som helst person, der bruger hjemmesiden uden at være oprettet eller logget ind i systemet, vil få status som gæst. Den sidste rolle er, som det ses her en gæst. En gæst vil være en person, som ikke er oprettet som bruger/administrator eller som ikke er logget ind i systemet. Denne vil ikke have adgang til andet end, at se de ting der ligger på den offentlige hjemmeside. Med disse 3 metaforer beskriver vi de rollefordelinger, der vil være i forbindelse med systemet. Det skulle nu gerne være klart for alle hvad disse er og hvilken funktion de har. Det næste vi vil se på i forbindelse med vores metaforer, er de forskellige roller, der er udenfor systemets grænser. Vi starter med at definere hvad en vikar er, derefter fortsætter vi med, medarbejder, senior manager og arbejdsgiver: En vikar er en person, som er tilknyttet ITemp i form af en ansættelse. Denne ansættelse medfører, at Itemp sender personen ud til andre virksomheder for at arbejde. En vikar er ansat af ITemp, som tilbyder dennes arbejdskraft ud til andre virksomheder. En vikar vil få status som bruger når denne oprettes in systemet En medarbejder er en person, som er ansat ved ITemp, til at hjælpe med at rekruttere og uddanne vikarer. En medarbejder kan have flere andre opgaver indenfor ITemp, men vil aldrig blive brugt som vikar. Medarbejdere oprettes i systemet som administrator. 64 En senior manager er den person hos ITemp, som står med de endelige beslutninger, både omkring ITemp, men også omkring systemet og dets udformning. En senior manager oprettes i systemet som administrator.

69 En arbejdsgiver er en person eller et firma, som tager kontakt til ITemp med den hensigt, at få vikarer ansat for en periode. En arbejdsgiver vil ikke blive tildelt nogen rolle i systemet, og vil derfor have status som gæst. Nu har vi fået på plads hvilke roller, der skal tildeles i systemet, og hvilke personer der skal have de forskellige roller, og dette på en måde så det vil være logisk for enhver, at se dem og forstå dem. En anden ting vi gerne vil have styr på er definitionen omkring selve systemet. Altså hvad taler vi om når vi siger systemet. Taler vi om hele informationssystemet, eller snakker vi kun om det system der nu skal udvikles. Med en system metafor kan dette beskrives: Systemet beskrives som værende det it-program, som ITemp ønsker udviklet af de 3 studerende, Peter, Daniel og Kasper. Beskrivelsen system dækker kun over det it-program, der skal udvikles og ikke over omgivelserne eller dets mennesker. I det følgende beskriver vi definitionen af et informationssystem, en betegnelse vi ofte bruger i forbindelse med kundemøder. Dette er et typisk fagudtryk, som almindelige folk ikke vil have en ret stor forståelse for. Der er derfor brug for klarhed, både for brugere og udviklernes skyld, da der kan opstå misforståelser såfremt folk snakker forbi hinanden. Informationssystemet beskrives som værende det, der får hverdagen til at fungere hos ITemp. Både mennesker og computere er en del af en større helhed som er informationssystemet. Der er dog også andre ting det ville være praktisk at have en fælles definition omkring. Disse er ting som kvalitet, sikkerhed m.fl. så der ikke opstår misforståelser der kan føre til et brud på det tillidsforhold, der er så vigtigt i XP. Her mener vi, at en af de vigtigste ting at få sat på plads, er kvalitet. Vi må derfor diskutere med ITemp hvad deres kriterier for kvalitet er, og hvordan det vil passe ind i de ting vi allerede har talt om. Ud fra de ting vi diskutere vil vi komme frem til en definition af kvalitet for systemet. Her vil vi gennemgå nogle af de overvejelser vi havde i forbindelse med dette: En af de første overvejelser som vi bad ITemp tage stilling til var, at prøve at definere hvad kvalitet i forhold til dette system vil betyde for dem. Altså hvordan vil de definere, at det nye system de får, er en af en sådan kvalitet, at det kan leve op til deres krav. I forhold til ITemp vil vores system være af god kvalitet såfremt at: Det kan spare ITemp tid i forhold til det gamle system. Kan spare besvær for både vikarer og ITemp i forbindelse med tidsregistrering. Kan slå flere systemer sammen til et. Mange vikarer er nybegyndere indenfor IT, derfor skal der fokus på brugervenlighed. 65

70 Systemet laver backup for at sikre at data ikke går tabt, alt andet vil være katastrofalt. Mængden af fejl i systemet holdes til et minimum, helst ingen fejl. Løn oplysninger SKAL være korrekte. Disse punkter fremkom ved interview med ITemp. Det som de lægger mest vægt på er sikkerheden omkring systemet. Det går ikke, at de mister noget data, derfor vil de lægge mest vægt på sådan noget som backup, men naturligvis skal de også kunne se et resultat af vores arbejde. De skal altså kunne spare noget ved at få et nyt system, det hjælper ikke at skifte det gamle ud for, at få noget nyt der virker akkurat lige så dårligt. Det er også vigtigt at de oplysninger der videregives i systemet er korrekte. Her tænker de især på timeregistrering og lønoplysninger. Da vi umiddelbart også har fokus et andet sted, nemlig på den rapport vi skal have udarbejdet, vil vi måske have en lidt anderledes definition af kvalitet i dette projekt, i forhold til ITemp. For os vil følgende kriterier være vigtige: En god rapport, der kan dokumentere vores process, enkelte fejl og mangler i systemet kan tolereres så længe disse er dokumenteret. Systemet kører med et minimum af fejl, så tæt på ingen fejl som muligt. Systemets funktionalitet opfylder så vidt det er muligt kundens ønsker. Systemet er en hjælp for ITemp og dennes ansatte i forhold til deres gamle system. Visse dele af systemet SKAL køre uden fejl, løn og timeregistrering. Data må ikke gå tabt, backup. Brugervenlighed, enkelt design, nemt at navigere rundt, let genkendelige navne. Som det ses heraf er der flere steder hvor vores definition er mere eller mindre den samme, men der er også punkter hvor vi har en meget anderledes holdning. Her tænker vi især på det faktum, at vi har en rapport der skal laves, og denne vil uden tvivl gøre at der vil opstå konflikter imellem de kvalitets kriterier vi normalt ville have fokus på, og dem vi nu bliver nødt til at have med. Derfor er det også vigtigt, at vi gør ITemp opmærksom på denne interesse konflikt, så vi sammen kan finde en definition der gør alle parter tilfredse. Vi bliver derfor nødt til at se på hvilke kriterier vi kan fokusere på, samtidig med at vi får lavet en ordentlig rapport. Vores definition af begrebet kvalitet skal derfor være en sammenfatning, af både de kriterier, som vi har opstillet, samt de kriterier som ITemp har opstillet (Det skal lige siges at vi under et normalt XP projekt, ville kunne fokusere langt mere på kundens ønsker, men de særlige omstændigheder i dette projekt gør at vi må prioritere en smule anderledes). Vores første forsøg på at beskrive kvalitet lyder som følger: 66

71 Kvalitet: Ordet beskriver de forventninger, der er til det system der udvikles. For at kvalitetskravene er opfyldt, skal systemet indeholde alle essentielle funktionaliteter, som defineres af ITemp. Systemet skal opfylde de sikkerhedskrav, der er opstillet, og skal være så enkelt designet, at det et muligt for nye PC brugere at benytte. Dele af systemet, f.eks. løn og timeregistreringsdelen, skal køre fejlfrit, og der skal tages backup af kritiske oplysninger flere gange om dagen. Skulle der opstå fejl i andre dele af systemet, skal disse rettes hurtigst muligt. Visse funktionaliteter kan tilsidesættes såfremt der opstår tidsmangel i forhold til den deadline der er sat. For at lave en sammenfatning af dette, kan vi se at de ting vi fokusere på er brugervenlighed, funktionalitet og sikkerhed. Vi kan også se at dele af systemet kræver mere gennemgående tests, da disse simpelthen ikke må indeholde fejl. Det er også til sidst beskrevet hvilke ting vi kan tilsidesætte hvis der opstår tidsmangel. Såfremt vi skulle komme i tidsmangel vil vi nu have en ide om, hvor det er vi kan hente noget ind igen, og hvor vi absolut ikke må pille. Hvis vi skulle tale med Itemp om en forringet kvalitet af produktet, vil vi også skulle forklare hvilken del vi taler om, men generelt skulle ordet kvalitet gerne være dækket ind, så alle er klar over hvad kvalitet betyder for netop dette projekt. Et andet udtryk som vi synes vil være godt at få på plads, er sikkerhedsbegrebet, og hvordan det bruges i vores sammenhæng. Sikkerhed kan generelt dække over mange forskellige ting, og da vi bruger dette ord mange gange både internt og i forhold til ITemp, vil det være en god ide at få på plads hvad det dækker over. Igen har vi gennem interview med ITemp fået dette begreb på plads: Sikkerhed: Ordet sikkerhed dækker over sikkerheden for den data der opbevares i systemet. Sikkerhed dækker ikke over ting som antivirus programmer, spyware osv. For at have et sikkert systemet skal det sikres, at data ikke går tabt ved et evt. angreb eller andre problemer der kunne forsage at systemet ikke længere fungerer korrekt. Det sidste begreb vi gerne vil have på plads, er brugervenlighed, og hvad det egentlig i denne sammenhæng dækker over. Brugervenlighed kan være mange forskellige ting, alt efter hvilket publikum man skal nå ud til. Er det f.eks. nogle avancerede IT brugere, vil de måske være meget fokuseret på funktionalitet og smarte features, hvor nyere PC brugere mest vil være fokuserede på enkelt design, og at de rent faktisk kan finde de ting de skal bruge. Vores betegnelse for brugervenlighed kommer her: Brugervenlighed: Brugervenlighed for dette system, vil være at der fokuseres på enkelt design så selv folk, med meget lidt eller ingen forstand på IT, stadig kan benytte systemet uden at skulle søge assistance udefra. 67