Udvikling af Resource Request løsning

Transkript

1 1 Udvikling af Resource Request løsning Christian Holse Fanning (s063497) Kongens Lyngby 2009 IMM-B.Eng

2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax

3 3 Summary This report deals with the development of a system that helps a resourcemanager to allocate its resources to as projectssupervisor suggested it. It will be explained why we need this system and what benefits the user will have when using this program. As systems development method has been used, extreme Programming and will throughout the report be examined how this approach has worked. All charts are made according to UML standart and will be explained why I have chosen to use UML on extreme Programming. The project has been implemented in Project Web Access and SharePoint. Elements such as JavaScript has been used to make the system dynamically. On the server side ASP.Net is used to retrieve, update and present data. There is also done automated testing of some components in the system and V-model is used to structure the rest of the tests.

4 4 Resumé Denne rapport handler om udviklingen af et system der skal hjælpe en ressourceleder med at tildele sine ressourcer til projekter som projektlederen har foreslået det. Det vil blive forklaret hvorfor der er brug for dette system, og hvilke fordele brugeren vil have ved at bruge dette program. Som systemudviklingsmetode er der brugt extreme Programming og det vil gennem hele rapporten blive gennemgået hvordan denne metode har fungerede. Alle diagrammer er lavet efter UML standarten, og det vil blive beskrevet hvorfor jeg har valgt at bruge UML på extreme Programming. Projektet er blevet implementeret i Project Web Access og Sharepoint. Elementer som Javascript er blevet brugt til at gøre systemet dynamisk. Og på serversiden er ASP.Net brugt til at hente, opdatere og præsentere data. Der er også lavet automatiserede test af dele af systemet og V-modellen er brugt til at strukturere resten af testene.

5 5 Forord For at kunne forstå hele indholdet i denne rapport er det vigtigt at læseren har et godt kendskab til programmeringssproget C# og.net platformen generelt. ASP.Net vil også blive brugt i rapporten, men det er ikke et krav at læseren har kendskab til dette for at kunne forstå rapporten. Et kendskab til et projekt værktøj som MS Project kan være en fordel, rapporten omhandler avanceret projekt styring så læseren skal også have en nogenlunde forståelse af hvordan projekt styring fungere. Systemet er implementeret i Sharepoint, men det er ikke mange elementer i Sharepoint der er brugt, så det er ingen forhindring hvis læseren ikke kender til Sharepoint. Alle referencer til objekter i PWA bliver lavet ud fra en PWA siden er på dansk, de engelske udtryk er ikke taget med. Ligeså vil objekter internt i Project Server blive refereret på dansk, dette drejer sig specielt om termerne task, ressource og project, som vil blive kaldt opgave, ressource, og project. Programmet der er blevet udviklet i forbindelse med denne rapport er vedlagt som en CD, hvis læseren ønsker at kører programmet henvises der til afsnittet Opsætning og Debugging.

6 6 Indholdsfortegnelse Contents Resumé... 8 Hvorfor er der brug for programmet... 8 Teknologier... 9 Funktionalitet... 9 Risikoanalyse Valg af systemudviklings metode & model Udviklings modeller Processen Delkonklusion Resumé Design MVP PRM moduler PRM design Problemer med det nuværende design Bag Project Server Kommunikation med databaserne Project Server Objekt Model Konklusion Resumé Interface Opsætning og debugging Hente projekt information fra PS Ændring af data i PWA Sletning af projekt medlemmer Vise ressource belastning Klint script Vente skærm Grafisk design... 39

7 7 Kø håndtering Postback Rettigheder Language Delkonklusion Resumé Test Automatiserede test V-Modellen Acceptance test Stress test Delkonklusion Resumé Mangler og fremtid Installation Optimering Stress test Delkonklusion Konklusion Forkortelser & Definitioner... 49

8 8 Kapitel 1 Resumé Dette kapitel handler om hvilke problemer det er programmet, Project Resource Manager (PRM), skal automatisere. Det bliver også beskrevet hvorfor der er brug for netop dette program og hvilke fordele brugeren vil have af at benytte sig af det. De teknologier PRM arbejder med vil kort blive gennemgået, og det vil blive forklaret hvordan de arbejder sammen med PRM. For at være opmærksom på hvilke risici der er for at systemet ikke bliver færdig til tiden, og hvilke risici der er for at systemet kan ende i en situation hvor det ikke kan implementeres, vil det blive gennemgået hvilke teknologier og designmæssige udfordringer der kan forhindre projektet i at blive implementeret. Endeligt vil det blive beskrevet hvilke systemudviklingsmetoder det er muligt at gennemfører projektet med og hvad deres fordele og ulemper er. Det vil også blive undersøgt hvilken systemudviklingsmodel der passer bedst til dette system. Og der vil blive truffet et valg af systemudviklings metode og model. Hvorfor er der brug for programmet Når en afdelingsleder (ressource maneger) skal ind i PWA og se hvilke projekter der er foreslået skal han ind hos hver enkelt projektdeltager og se hvad han har foreslået for at godkende eller afvise hans forslag. Dette kan godt være ret trivielt og i nogle virksomheder tillader man at alle medarbejder må oprette forslag til nye projekter så det kan medfører at projektlederen skal ind og tjekke rigtig mange profiler for at se om der er sket noget nyt. Dette er der i øjeblikket mange projektleder der bruger rigtig meget tid på og på denne baggrund er der også en del virksomheder der efterspørger et stykke software der kan hjælpe dem med dette. På denne baggrund har Projectum bedt om at få lavet et sådant stykke software som de kan sælge videre og vedligeholde. Når en kunde skal købe et stykke software er det første han ser programmets bruger grænseflade, det næste han kigger efter er hvor let det er at bruge programmet og derefter ser han om funktionaliteten er i orden. Det er klart at hvis der opstår fejl mens bruger foretager sig dette, vil det forringe hans købelyst. Derfor er det først og fremmest vigtigt at programmet har en brugergrænseflade der passer ind i kundens igangværende system, det er også vigtigt at programmet er intuitivt at bruge. Og hos de fleste kunder er det en selvfølge at programmet gør det de beder det om.

9 9 Teknologier Dette afsnit omhandler de teknologier og produkter der har været involveret i projektet, dette drejer sig blandt andet om Sharepoint, PWA, MS Project og PSI. Teknologier som C# og.net vil ikke blive nævnt da det forventes at læseren har kendskab til disse. Formålet med afsnittet er at give læseren en ide om hvad der bliver talt om igennem resten af rapporten, det er på ingen måde en introduktion til teknologierne. ASP.Net ASP.Net er et server script der kan udfører funktionalitet på forespørgsler fra en webside. ASP.Net bliver som regel brugt til at lave dynamiske web sider, afhængig af hvad brugeren ønsker af information. ASP.Net kan ikke lave dynamisk HTML kode hos klienten ligesom Javascript kan. Javascript Javascript er et script der kan eksekveres hos klienten, det bliver typisk brugt til at lave web sider animeret, men man kan også lave kommunikation med databaser og gemme ting på filsystemet. I denne repport vil det kun blive brugt til at lave animationer. Sharepoint Sharepoint eller Windows Sharepoint Services (WSS) er en række services der hjælper til at bygge et intranet op, der er ikke direkte nogle begrænsninger til hvad intranettet kan indeholde, men begrænsningen i services der følger med Sharepoint kan gøre det svært at lave alle former for intranet. Sharepoint bygger oven på Windows Server, IIS og ASP.Net. Det er derfor en god ide at kende ASP.Net og IIS før man går i gang med at udvikle eller opsætte en Sharepoint server. PWA PWA står for Project Web Access og er et web program der håndtere projekt styring, PWA arbejder sammen med MS Project og står primært for at publicere informationen til projektdeltagerne. Webparten PRM der bliver beskrevet i denne rapport er udviklet til at kunne kommunikere med PWA gennem Project Server Interfaces (PSI). PWA bygger på Sharepoint. Microsoft Project MS Project er også et projekt styrings værktøj. Denne har bare en del flere funktioner en PWA. PWA og MS Project kommunikerer med den samme database, så det der bliver gemt i MS Project kan ses i PWA. Funktionalitet Programmet der skal udvikles skal automatisere en proces som allerede eksistere i forvejen, problemet er som det ser ud nu at det er meget besværligt at udfører denne proces. For at få et bedre overblik vil jeg først beskrive hvad det er processen skal udfører og hvilke aktører der er involveret. På figur 1 ses en afbildning af hvordan ressource flowet fungere i PWA, det første der sker når et nyt projekt bliver defineret er at en Project Maneger foreslå et nyt projekt.

10 10 Figur 1 Project Manageren definerer her en række Generic Ressourcer som skal bruges i projektet, projektet kan ikke startes før alle de generiske ressourcer er skriftet ud med faktiske ressourcer (Ressource Comitted). Det er Ressourcer Managerens job at tildele de faktiske ressourcer hvis han kan finde nogen, ellers må han fortælle Projekt Manageren at det ikke kan lade sig gøre. Ressource Manager kaldes ofte også for afdelings leder. Hver ressource er knyttet til en bestemt afdelingsleder og først når alle afdelingsledere der er knyttet til projektet har været inde og godkende kan projektet afsluttes. Selvfølgelig vil projektet godt kunne startes før alle ressourcer er comitted, men man skal selvfølgelig sikre sig at det kan lade sig gøre at afslutte projektet. Et eksempel på dette kunne være at en projektleder vil oprette et projekt der skal lave et stykke software der kan hjælpe virksomheden internt, dermed foreslå han et projekt hvor han skal bruge en person der kan skrive Java programmer og en person der kan designe programmet. Det er nu afdelingsledernes job at finde en person der kan kode Java og en der kan designe programmet, hvis han ikke mener der er tid nok i overskud kan han vælge at afvise projektet og lade være med at tildele nogle ressourcer. Risikoanalyse For at være opmærksom på hvilke risici der er for at projektet ikke bliver færdig til tiden, og hvilke risici der er for at projektet ikke kan gennemføres. Vil jeg i dette afsnit gennemgå ukendte teknologier og elementer der kan forvolde problemer. Når der er teknologier som man ikke før har stiftet bekendtskab med, kan man støde ind i indlærings vanskeligheder og design problemer man ikke har kunnet forudsige. Hvis man f.eks. tror at programmerings sproget C er objekt orienteret, og begynder at lave klasse diagrammer for sit system. Vil man under implementeringen støde ind i nogle problemer. Jeg har ikke tidligere arbejdet særlig meget med ASP.Net, så min erfaring med denne er begrænset. Jeg ved godt hvordan man kan opbygge sider i ASP.Net, men når det kommer til eventhåndtering af mange events og opbygning af større GUI elementer har jeg ingen erfaring. Derfor vil der være en risiko ved at jeg får designet et system som ikke kan implementeres.

11 11 Før jeg hørte om dette projekt havde jeg heller ikke hørt om Sharepoint. Jeg ved på nuværende tidspunkt ikke hvad Sharepoint kan og hvad det ikke kan, umiddelbart er det bare en applikation der skal holde min webpart. Men det kan være Sharepoint stiller nogle krav til min webpart som jeg ikke kender til endnu. Når jeg skal teste mit program på serveren, så skal jeg enten oploade det kompilerede program til serveren eller udvikle programmet på serveren. Kommunikationen med serveren foregår gennem remote desktop, og jeg ved ikke om remote desktop over en internet forbindelse kører hurtigt nok til at jeg kan udvikle på serveren. Jeg ved heller ikke om det er muligt at sende programmet til serveren og hvor lang tid dette vil tage. Så hvorvidt jeg kan anvende den ene eller anden metode, eller en helt tredje metode ved jeg ikke. Jeg kan også støde ind i det problem at det tager meget lang tid at sende programmet til serveren, og jeg bliver nød til at planlægge mine test meget omhyggeligt. Projekt styring har jeg kun stiftet bekendtskab med i forbindelse med skole projekter, mere avanceret projekt styring med mange forskellige typer ressourcer kender jeg ikke til. Derfor vil der også gå noget tid med at sætte mig ind i dette. Undervejs i projektet er der også en risiko for at jeg kan misforstå nogle begreber og jeg bliver nød til at lave dele af projektet om. Jeg har ikke tidligere arbejdet med MS Project eller PWA, derfor skal der også sættes noget tid af til at jeg kan komme ind i disse systemer og forstå hvordan de fungere. PSI er et interface til Project Server og jeg har lade mig fortælle at det er meget dårligt dokumenteret. Dette kan medføre at jeg ikke kan forstå hvordan teknologien skal bruges, og måske skal bruge noget tid på at få PSI dokumenteret. Dette projekt indeholder en del risici, og jeg kan hurtigt støde ind i problemer hvor det kan være svært at komme videre. Dette skal tages med ind i overvejelsen om hvilken system udviklings metode der skal bruges til at udvikle systemet med. Det ville være en fordel hvis det var en metode hvor jeg kunne skære ned på omfanget at projektet undervejs. Valg af systemudviklings metode & model Det system der skal udvikles har mange ukendte faktorer. Der er blandt andet en del ukendte teknologier som ASP.Net, PSI, PWA, Sharepoint og IIS. Alle disse teknologier skal der være en del kendskab til før udviklingen af det egentlige produkt kan påbegyndes. Hvorvidt systemet skal udvikles med ASP.Net controllers eller om der eksisterer nogle Sharepoint controllers hvides ikke på nuværende tidspunkt. Men da jeg ikke har nogen erfaring med at udvikle større programmer i hverken ASP.Net eller Sharepoint kan der opstå design problemer i og med teknologien kan forhindre et givent design. Dette vides på nuværende tidspunkt ikke, men der må tages hensyn til at systemet skal omdesignes under implementeringen hvis en teknologi ikke opfylder forventningerne. I begyndelsen af projektet skal der laves en del test af teknologierne for at finde ud af hvordan systemet kan designes. Der skal også bruges noget tid på at forstå de forskellige elementer i PWA og hvad projekt styring generelt består af.

12 12 Vandfalds metoden er baserede på at man først laver en analyse af hvad systemet skal kunne, derefter laver et design for hele implementerings fasen, implementere designet, og til sidst test og integration af systemet. Afbillede på figur 2. Figur 2 Problemet med denne metode er at hvis man finder fejl i analysen eller implementeringen bliver det meget dyrt at rette op på. Hvis man bliver enig med kunden om hvad det er der skal laves under analysen, og først finder ud af at man ikke forstod hinanden efter systemet er implementeret kan det komme til at koste mellem 50 og 200 (1) gange mere end hvis man havde fundet fejlen i analysen. Hvis man udviklede efter Vandfalds metoden vil man hurtigt støde ind i det problem at teknologierne forhindrer det design man har udviklet. Dermed vil man så blive nød til at omdesigne systemet og dette vil i de fleste tilfælde medfører at man skal skrive dele af koden om. Da jeg heller ikke kender til projekt styring som sådan, vil det også være svært at få lavet en brugergrænseflade der er intuitiv og enkel fra starten af. Undervejs i udviklingsprocessen vil jeg finde nye begreber og elementer som vil ændre på hvordan brugergrænsefladen vil komme til at se ud. Unified Process arbejder ud fra en iterativ proces hvor der ikke er noget up front design, men hvor man i hver fase af udviklingen gennemgår analyse, krav, design, implementering og test. Der er fire faser i UP, Inception, Elaboration, Construction og Transition. Som det ses på figur 3 vil der i de første faser blive brugt mest tid på analyse, indsamling af krav og design. Figur 3 I de senere faser vil tiden blive brugt til at implementere og teste. Dette afhjælper problemet med at finde fejl i de tidligere faser, da man allerede i Elaboration fasen vil begynde at implementere programmet.

13 13 Allerede i Inception fasen laver man en prototype så kunden kan være med inde over hvordan produktet skal se ud, men som regel revidere man ikke denne prototype før systemet er færdigt. Dette er en lang proces hvor kunden ikke får meget respons på hvordan projektet udformer sig. For at definere kravene i UP benytter man sig som regel af use cases, det beskriver hvilke opgaver det er der skal udføres. Use cases består som regel af følgende Navn Mål for hvad der skal ske Hvilke personer der udfører handlingen (både før og efter systemet er implementeret) Forudsætninger for at handlingen kan udføres (Preconditions) Overblik over selve handlingen Hvordan miljøet ser ud efter handlingen er blevet udført (Postconditions) Noter til yderligere information. Her er ikke taget information med som altid gør sig gældende, f.eks. version, forfatter, dato osv. En ulempe ved use cases er at de stiller nogen skærpede krav for hvad der skal være i dem, dette kan godt være lidt en ulempe hvis man har rigtig mange use cases da man så skal lave rigtig meget dokumentation. Dermed er denne metode god til projekter, hvor man ikke præcis ved hvad resultatet bliver, men stadig har en god forståelse for hvad det er der skal laves, og hvordan det kan blive lavet. extreme Programming er en videreudvikling der primært er baseret på UP. XP tager udgangspunkt i at man har fire elementer i projektet, nemlig omfang, pris, tid, kvalitet. Hver af disse kan man justerer på ind til kunden er tilfreds med løsningen, hvis man skruer op for omfanget af løsningen og holder tiden på det samme bliver man selvfølgelig nød til også at skrue op for prisen. Dog kan det være en rigtig dårlig ide at begynde at skrue ned for kvaliteten da det kan være svært for kunden at overskue hvilke konsekvenser det vil få. Det projekt jeg skal lave er et eksamensprojekt jeg laver for DTU, og der er dermed ikke nogen økonomi at ændre på. Der er en fast afleverings dato, så tiden kan der heller ikke ændres ved. Omfanget kan jeg derimod ændre en del på da der ikke på nuværende tidspunkt er nogen direkte kunde til løsningen. Og selv om systemet ikke skulle være fuldt implementeret på afleverings dagen, vil produktet kunne give en del værdi internt i Projectum og det vil også være muligt at færdig implementere produktet efterfølgende. Faserne i XP er en del anderledes end vandfaldsmetoden og UP, i stedet for at have en række fast defineret faser har man kun en fase som man gentager flere gange til systemet ikke længere skal anvendes, se figur 4.

14 14 Figur 4 Her starter man ud fra en user storie som beskriver et givent problem brugeren har, fra denne udvikler man så nogle krav og acceptance test til systemet som man derefter kan planlægge ud fra. Hvis det er for svært at planlægge næste udgivelse af projektet, kan man eventuelt lave nogle spikes. Spikes er små programmer eller opgaver der undersøger en given teknologi, f.eks. et API eller et eksisterende system der skal bygges videre på. Når planlægningen af næste iteration er færdiggjort starter man på selve iterationen som ligner iterationerne i UP. Efter itarationen skal de user stories der er blevet færdig igennem en acceptance test. Hvis der er user stories der ikke er blevet færdige, skal det vurderes hvor lang tid det vil tage at gøre dem færdige, derefter er det op til kunden at tage stilling til om der skal arbejdes videre på dem. Når kun en delmænge af de planlagte opgaver bliver udført tages dette i betragtning gennem loadfactoren der bliver overført til næste fase. Processen for en fase i XP tager ca. 1 til 4 uger. Load factoren er et tal der beskriver hvor god man er til at planlægge og hvor hurtigt man arbejder. Eks. Hvis man vurdere at en opgave tager 1 uge at udføre og man først er færdig med opgaven efter 2 uger, så har man en Load factor på 2. Næste gang man så skal estimere en opgave skal man gange sin estimering med 2. På denne måde får kunden efter kunden hurtigt implementeret de første dele af løsningen, og man kan hurtigt får respons på om der er noget der skal laves anderledes, eller noget der er misforstået. En user storie er en lille forklaring der fortæller hvilken funktionalitet der skal udføres. Der er ikke nogle nedskrevne regler, for hvordan den skal se ud og hvad der skal være i den, hvilket gør at man selv kan bestemme omfanget af den. Dette kan både være en fordel og en ulempe, fordelen ligger i at der, i modsætning til use cases, ikke er særligt meget arbejde i at dokumentere. Ulempen er at man ikke får gjort det helt klart hvad det er der skal laves, og begynder at designe på et forkert grundlag. I det projekt jeg skal lave, har jeg flere ukendte teknologier, dette betyder at det kan være meget svært at estimere hvor lang tid det tager at lave en opgave. Dette vil kunne afhjælpes med spikes og med en load factor som jeg til at starte med kunne sætte højt.

15 15 Udviklings modeller Når man vælger en udviklings metode, vælger man som regel også en udviklings model der passer til. F.eks. hvis man vælger at bruge UP bruger man i de fleste tilfælde UML da dens måde at dokumentere designet på passer godt til UP der ønsker et up front design. Bruger man XP kan det godt være problematisk udelukkende at bruge UML fordi man rigtig ofte ændre på designet, i stedet kan man bruge CSC cards eller en tavle som XP også foreslå (2). Dette gælder specielt i større teams, hvor der er mange der sidder og ændre på designet ofte. XP s har en række redskaber til at udvikle med, men er ikke en egentlig udviklings model og man bliver som regel også nød til at låne en del fra UML, da CSC cards og userstories ikke er nok til dokumentation. Processen Processen med at bruge XP Delkonklusion Dette projekt har en del store risici, blandt andet med en række teknologier der endnu ikke kendes. Derfor vil det ikke være ansvarligt at bruge vandfalds metoden til dette projekt da det vil være svært at estimere opgaverne, men næsten umuligt at designe de dele af systemet hvor jeg endnu ikke kender til teknologierne. Hvis man brugte UP til at udvikle efter vil man blive nød til at får styr på alle teknologierne før projektets start for at kunne estimere hvor meget man vil have med ind i projektet. Hvorimod man med XP vil kunne lave spikes i starten af alle faserne, og på den måde vil man kunne få styr på dele af teknologierne samtidig med man får implementeret noget funktionalitet. Med XP vil man måske ikke få implementeret alt funktionaliteten til tiden, men man vil have en del af funktionaliteten implementeret. Med UP metoden kan man nemt risikere at der er styr på teknologierne og designet er færdigt til tiden, men at der ikke er implementeret eller testet særlig meget. Dette vil ikke have særlig stor interesse for kunden, eller Projektum i det her tilfælde, hvis han for af vide der skal bruges 2 uger ekstra før han overhoved kan se første udkast til programmet. XP er den metode der bedst kan garantere at der er et kørende og fungerende program på afleveringsdagen. Det er også den metode der bedst kommer rundt om teknologierne, og holder øje med hvor hurtigt projektet skrider frem. På denne baggrund vælger jeg at bruge XP metoden. Selvfølgelig får jeg det problem at jeg ikke kan release programmet til slutbrugeren efter hver fase, men dette kan delvist afhjælpes ved at jeg selv revidere programmet og vender det med medarbejdere i Projectum. Da user stories og CSC cards er for løst defineret og der kun er en projekt deltager vil det være forsvarligt at bruge use cases og klasse diagrammer i stedet for. Der vil selvfølgelig også være en nogle andre diagrammer hvor jeg har tænkt mig primært at bruge UML til at dokumentere.

16 16 Kapitel 2 Resumé Dette afsnit vil omhandle hvilke designmæssige udfordringer der har været i projektet, jeg vil komme ind på hvordan UML og XP er blevet brugt. Model View Presenter design mønsteret vil blive præsenteret og det vil blive forklaret hvordan dette design mønster er blevet implementeret i PRM. De forskellige moduler i PRM og deres indbyrdes referencer vil blive forklaret, og det vil blive vist hvilke moduler de enkelte klasser hører til. Hvert modul og hver klasse har et ansvarsområde, og dette ansvarsområde vil blive defineret. Endeligt vil designets ulemper gennemgås, samtidig med at det vil blive forklaret hvordan et bedre design kunne implementeres. Til sidst vil Project Servers objekt model gennemgås, da denne er nødvendig for at man forstår hvorfor systemet er blevet implementeret som det er. Design Som tidligere nævnt har jeg tænkt mig at bruge UML til at designe og dokumentere med. UML har en syntaks som de fleste system udviklere og designer kender til. Jeg har brugt den syntaks der er beskrevet i [UML & UP], men der kan komme enkelte afvigelser fra denne for at forbedre forståelsen. I dette afsnit vil jeg beskrive hvordan PRM er blevet designet, hvordan MVP (Model View Presenter) er brugt i denne sammenhæng, og give et forslag til hvordan man kunne forbedre og optimere designet med henblik på eksekverings tid og vedligeholdelse. MVP MVP design mønster er et udbredt UI design mønster, der opdeler programmet i tre lag. Model, View og Presenter. Modellen er datalaget, der håndterer at hente, opbevare og lagre data. Datalagring og datahentning kan håndteres med en XML serializer eller en databaseforbindelse. Jeg har valgt at benytte en dataforbindelese da det er den eneste mulighed i PSI. View er den visuelle del af programmet også kaldet den grafiske brugergrænseflade og forkortes med GUI. GUI omfatter vinduet og de komponenter det er opbygget af. Presenter er logikken og funktionaliteten, der binder model og view sammen. En model over MVP strukturen skal ses i figur 5. MVP Struktur

17 17. Figur 5 Jeg vil så vidt muligt prøve at leve op til MVP under implementeringen af mit projekt, men det vil aldrig kunne undgår at der bliver skabt forbindelser mellem model og view. Det der er mest vigtigt i MVP er at holde model laget for sig, men det er som regel heller ikke særlig svært. Det er til gengæld mere svært at holde presenter og view adskilt fordi det er meget hurtigere at lave implementeringen i view end i presenter. PRM moduler For at give et bedre overblik over systemet har jeg valgt at gruppere klasserne i nogle moduler der har hver deres ansvarsområde. På figur 6 er et billede af modulerne, og jeg vil i det følgende gennemgå hvad de forskellige modulers ansvarsområde er. PRM moduler Figur 6 Helpers er en samling af klasser der hjælper resten af systemet med at udfører deres handlinger. GUI er, som navnet antyder, det sted hvor hele bruger grænsefladen bliver sat op. Det er også her model laget bliver renderet til HTML kode, hvilket strider lidt imod MVP strukturen. Men pga. Postback vil det blive meget kompliceret hvis der skulle være et, presenter lag til dette. Problemet med postback vender jeg tilbage til i Postback afsnittet. Javascript GUI renderer også modellaget, her bliver der bare primært lavet Javascript kode. Model indeholder klasser der beskriver datatyperne i PRM. PSI Update Data og PSI Retrieve

18 18 Data henter og opdatere data på Project Server. Event handler står for at logge hvad der bliver sendt til klienten og vælge hvilke data der skal opdateres når brugeren udføre en handling. MVP i PRM Umiddelbart kan det være svært at se hvordan MVP spiller sammen med PRM. Derfor har jeg lavet en figur der viser hvilket MVP elementer der dækker over PRM modulerne. Denne figur kan ses på figur 7. Helpers Hører ikke til nogen steder da der her kun er generelle klasser der hjælper PRM med at fungere. MVP & PRM Figur 7 Modulerne PSI Update Data, PSI Retrieve Data, og Model hører alle til model i MVP, disse står for at holde, opdatere, og hente data fra PSI. Når data skal opdateres og tjekkes foregår alt logikken i Event Handler som dermed hører til Presenter. Men når data bliver hentet ligger logikken lidt spredt mellem GUI og PSI Retrieve Data. Årsagen til dette er at når man henter data fra Project Server sker det i flere trin, og hvis jeg i et tidligt trin ved at jeg ikke har brug for de pågældende data vil jeg ikke hente resten. GUI og Javascript GUI er de moduler der renderer brugergrænsefladen, dermed hører disse til View. PRM er blevet designet så det delvist overholder MVP design mønstrede, der hvor det ikke overholder MVP skyldes det primært måden PSI er designet på. Hvis PRM skulle overholde MVP til alle tider, ville det have store konsekvenser for eksekverings tid. PRM design Jeg vil her give en beskrivelse af hvilke klasser de forskellige moduler indeholder, og hvad de bruges til. Jeg vil også komme ind på hvordan det kunne have været mere fordelagtigt at designe PRM. Jeg vil gennemgå de 7 moduler hver for sig og hvordan de enkelte klasser spiller sammen med de andre moduler. Jeg vil her kun vise udsnit af det endelige klassediagram, men læseren kan finde det komplette klassediagram i bilag 3. Dette diagram indeholder ikke alle metoder som implementeringen, da meningen med det kun er at beskrive klassernes rolle i systemet. Helpers Helpers modulet er en række klasser der hjælper resten af PRM med at udfører en række handlinger, indholdet af Helpers og dens klasser kan ses på figur 8.

19 19 Helpers modulet Figur 8 Style klassen har en række styles som ProjectResourceManeger klassen bruger når den opretter nye GUI elementer, på denne måde får jeg samlede alle tekststørrelser og tekst farver et sted. Langauge klassen holder alle tekststrenge der bliver vist i PRM, på denne måde er det muligt at implementere flere sprog. LocalException bruges når der opstår fejl i programmet. Det er klart at når der opstår fejl i programmet ønsker jeg ikke at fejlen skal sendes ned gennem alle klasserne indtil den kommer til GUI klassen for at blive håndteret. Derfor har jeg LocalException klassen som kastets når der opstår en kendt fejl og gribes af GUI klassen som giver brugeren besked. WebServiceHandler sørger for at initialisere alle webservices og delegere dem ud til de klasser der skal forbinde til PSI, på denne måde får jeg kun initialiseret hver webservice en gang. Model Model er som navnet antyder det modul der holder de egentlige data når de sendes rundt i systemet, denne er en delmængde af Project Server databasen. Klasserne i model kan ses i figur 9. Model modulet Figur 9 Her er der tre klasser som, repræsentere det projekter, opgaver og ressourcer. Disse indeholder alt den information, der bliver vist i PRM. Alle klasserne har en UID attribut der fortæller hvordan de hænger sammen.

20 20 PSI Retrieve Data Dette modul står for at indhente data fra PSI, dette gør den med tre klasser som det ses på figur 10. RBSProperties henter alle RBS værdier omkring en ressource. Da der er mange ressourcer med de samme RBS værdier er denne klasse lavet som en singleton der cacher de data den henter, på denne måde bliver alle RBS værdier kun hentet en gang fra Project Server. PSI Retrieve Data modulet Figur 10 SiteProperties henter information om projekterne og hvilke ressourcer der er knyttet til dem, navnet kommer af at den henter egenskaber der omhandler hele webparten. ProjectProperties henter information om opgaver og hvilke ressourcer der er knyttet til opgaverne. DataParser samler disse tre klasser i en liste af mproject objekter og returnere dem til ProjectResourceManeger. PSI Update Data Her bliver data oploadet til serveren, og modulet indeholder to klasser der hver især kan oploade forskellig information. Disse har begge kendskab til QueueHandler, se figur 11, så de kan vente på deres data bliver opdateret. PSI Update Data modulet Figur 11 ProjectTeamHandler kan opdatere, slette, og tilføje information omkring teamet på projektet, dette inkludere også de ressourcer der er knyttet til teamet. ProjectHandler kan ændre tilstanden et projekt er i.

21 21 Event Handler Event Handler modulet er direkte knyttet til ProjectResourceManeger og holder styr på hvad brugeren har lavet når siden returnere fra klienten. Klasserne heri sørger også for at udfører de handlinger brugeren har bedt om. Event Handler modulet Figur 12 Alle klasserne som ses på figur 12 repræsentere hver deres handling. Alle disse handlinger, på nær en, bliver igangsat af brugeren. Undtagelsen drejer sig om CheckPermissions som bliver igangsat hvis brugeren ikke har nok rettigheder. Javascript GUI Dette modul sørger for at oprette Javascript kode og tilhørende HTML kode der kan fungere i webparten. Klasserne på figur 13 repræsenterer hver deres Javascript funktion, og de bliver begge brugt af ProjectResourceManeger klassen. Javascript GUI modulet Figur 13 SubmitWaitScrn klassen genererer kode til en vente skærm der bliver vist når siden genloades. JScriptResAttrBuilder klassen genererer kode til den tekst der står ude foran de ressourcer der er tildelt en opgave. Det er dette script der sørger for at teksten skifter når man vælger en anden opgave.

22 22 GUI GUI modulet sørger for at alting bliver renderet. Som det ses af figur 14 indeholder dette modul to klasser. NoNoPermissionsGUI er en skærm der bliver vist hvis brugeren ikke har de fornødne rettigheder. Denne viser en skærm der fortæller han ikke har rettigheder til at se siden, og hvilke rettigheder han mangler. GUI modulet Figur 14 ProjectResourceManeger klassen står for at rendere resten af skærmen, denne har en række metoder til at vise forskellige elementer på skærmen, og tre andre metoder til at håndtere klik fra brugeren. ProjectResourceManeger klassen er indgangs punktet til webparten, og den står for at kalde PSI modulerne, Javascript GUI modulet, og den opfanger også events og videregiver dem til Event Handler modulet. Designet af PRM fungerer i stor udstrækning rimeligt. MVP er rimeligt opfyldt, og der er et meget afgrænset model lag. Afgrænsningen mellem view og presenter er til gengæld lidt mere flydende, men dette har ikke den store betydning for vedligeholdelsen af programmet. De enkelte moduler og klasser overholder hver deres ansvarsområde, og der er ikke rigtig nogle steder hvor en klasse overtager en anden klasses funktionalitet. Problemer med det nuværende design Som designet er nu fungerer PRM godt og stabilt, men desværre tager det en del tid når nogle ændringer skal gemmes på serveren. Årsagen til dette er at Event Handler modulet opdatere Project Server hver gang de finder en ændring, se figur 15(A). Nuværende håndtering af events Fordelagtig håndtering af events

23 23 Figur 15(A) Figur 15(B) Når brugeren klikker på en knap beder GUI modulet Event Handler modulet om at finde alle de ændringer brugeren har foretaget. Hver gang Event Handler modulet har fundet en ændring, sender den dem videre til opdatering. Dette er ikke særlig fordelagtigt fordi det skaber en masse netværkstrafik, og der rigtig ofte skal ventes på Project Server køen. En anden løsning kunne være at man gemte alle ændringerne i PSI modulet og først eksekveret dem når man har været alle elementerne igennem. Dette er illustreret på figur 15(B). Hermed slipper man for at oprette forbindelse til serveren flere gange, men mere vigtigt er at man ikke skal vente på at køen får afsluttet mere end en gang. På denne måde kan man spare en del tid når brugeren laver ændringer. Især hvis brugeren laver mange ændringer af gangen, er der meget tid at spare. Grunden til PRM er blevet designet på denne måde er at, de enkelte event handlers er opbygget i forskellige faser som XP foreslår man gør. Hvis der havde været en fase til i dette projekt ville det nok være oplagt at lave PSI modulet om. Ellers må jeg konkludere at XP fejler lidt på dette område, men man kan argumentere med at der ikke er nogen grund til at optimere systemet medmindre det er et problem. Dermed vil der ikke være nogen grund til at omdesigne PSI modulerne før brugerne egentlig mener det kører for langsomt. Bag Project Server For at kunne forstå og udvikle programmer til Project Server bliver man nød til at forstå hvordan objekt modellen er bygget op og hvad der foregår i databasen. I dette afsnit vil jeg forklare hvordan Microsoft Office Project og Project Web Access kommunikere med databaserne, og hvad de forskellige databaser bliver brugt til. Jeg vil også forklare hvordan tabellerne i databasen hænger sammen, og hvordan man ændre rækkerne i disse tabeller. Kommunikation med databaserne Microsoft Office Project og Project Web Access kommunikere med databaserne på næsten samme måde, den eneste forskel er at Microsoft Office Project cacher data før den sender dem til serveren. Project Server indeholder fire databaser der har hver deres formål. En figur der illustrerer hvordan kommunikationen med. Denne figur er taget fra et møde med Carsten Nilsson fra Projectum og den originale skitse som den blev fremlagt kan ses i bilag 4.

24 24 Kommunikation med Project Servers databaser Figur 16 PWA gemmer alle sine data i Draft databasen hver gang brugeren vælger at gemme. Vælger brugeren at publicere sine projekter bliver de kopieret fra Draft til Published databasen. PWA får aldrig direkte adgang til at skrive i Published databasen, heller ikke selv om projektet ikke har været gemt tidligere. Reporting databasen holder sig løbende synkroniseret med Published databasen, denne database er hurtigere at hente data fra til gengæld kan man ikke regne med at data er opdateret. Man kan ikke skrive til Reporting databasen. Hver gang der bliver opdateret noget i Draft, Published, eller Reporting databaserne bliver der lavet en backup af ændringerne i Archive. Archive bliver dermed den største database, og man skal passe på med hvor mange versioner man sætter Project Server op til at gemme. Information om de fire databaser er hentet fra [MS Project Server]. PRM projektet læser og gemmer kun fra Published databasen, fordi alle projekter der skal tjekkes af ressource manageren bliver nød til at være publiceret af en anden bruger. I fremtiden kunne det være en mulighed at ressource manageren kunne gemme sine ændringer før han valgte at publicere dem. Project Server Objekt Model Når man henter data fra Project Server få man det tilbage i samme form som det ligger i databasen. Derfor bliver man nød til at kende sammenhængen mellem tabellerne for at kunne vide hvilke tabeller man får tilbage. Project Server består af rigtig mange tabeller, jeg vil her kun gennemgå de tabeller der direkte eller indirekte har noget med PRM at gøre. Den første tabel man skal kende til i Project Server, er Project tabellen. Denne tabel indeholder alt information om projektet. Dette gælder alt den information der er direkte knyttet til projektet, information som hvilke opgaver der er på projektet skal findes i Task tabellen. Task tabellen indeholder information der er direkte knyttet til en opgave. Task tabellen beskriver selv hvilket projekt den hører til gennem et UID. På figur 17 er alle tabellerne og deres referencer illustreret.

25 25 Project Server Tabeller Figur 17 På opgaverne er der også nogle ressourcer, ressourcerne er samtidig knyttet til andre ting som f.eks. projekt teamet. Så for at undgå redundans eksisterer der en Assignment klasse der linker Task og Resource tabellerne sammen. Project Team tabellen fortæller hvilke ressourcer der er i project teamet, denne fungere dermed som et link mellem Resource tabellerne og Project tabellerne. Projektet har også et bruger defineret felt der kaldes Tilstand, da dette er et brugerdefineret felt ligger det ikke i Project tabellen, men i CustomFields tabellen. Tilstand feltet kan tage en af tre værdier, derfor er der også en tabel til at holde disse værdier. Denne tabel hedder LookupTable. BaseCalenders tabellen indeholder information om hvornår en bruger er ledig, denne bliver ikke brugt direkte i PRM. Det skal nævnes at disse navne på tabellerne er nogle navne jeg har tildelt dem. De fysiske navne på tabellerne er lange og indeholder blandt andet versions nummer og UID. Konklusion PRM overholder MVP så godt som teknologierne kan understøtte det, der hvor MVP ikke bliver overholdt har det ingen fatale konsekvenser. Model laget er meget afgrænset, mens view og presenter ikke er nær så godt opdelt. Der er en skarp afgrænsning af klassernes ansvarsområde, dette afhjælper forståelsen og vedligeholdelsen af PRM. Når man kigger på data flowet i PRM, kan man finde en design fejl der medfører relativt meget netværkstrafik. Dette kan forholdsvis nemt udbedres, men problemet var nok slet ikke opstået hvis jeg havde valgt en anden system udviklings metode.

26 26 Kapitel 3 Resumé Implementeringen af PRM er som nævnt udført i faser, hvor der i hver fase er udført en række spikes for at få teknologierne på plads. I det følgende vil jeg gennemgå den fulde implementering som den ser ud på nuværende tidspunkt og ikke skille de enkelte faser for sig. Jeg vil kun gennemgå elementer der er specifikke for PRM, elementer der har været kompliceret at implementere, og elementer hvor der har forvoldt problemer pga. fejl i andre programmer. Opbygningen og brugen af de forskellige elementer er gennemgået i design afsnittet, og hvis læseren er i tvivl om hvor elementerne hører til må han vende tilbage til design afsnittet. Interface Når man skal have adgang til Project Server eller Sharepoint elementer fra et program skal det altid udføres gennem PSI eller Sharepoint interfacet ([Inside WSS] s. 5). Ofte vil det være hurtigere og lettere at oprette en direkte forbindelse til databasen. Men da Project Server og Sharepoint har deres egne cache af databasen, og nogle køer der synkronisere opdateringer fra forskellige klienter, vil en direkte forbindelse til databasen resultere i synkroniserings fejl. I enkelte tilfælde kan man godt oprette forbindelse til databasen. Hvis man kun læser fra databasen og er opmærksom på at de data man får, ikke er opdateret kan man godt oprette forbindelse alligevel. Når man læser direkte fra databasen får man alle resultater tilbage, hvis man bruger PSI får man kun de resultater tilbage som den pågældende bruger er tiltænkt. Det er aldrig nogen god ide at begynde at skrive til databasen, da der kan ligge ting i køen der vil overskrive ens data. I PRM er der på intet tidspunkt oprettet direkte forbindelse til databasen, alligevel vil jeg gerne give et eksempel på hvornår det kan være en fordel. Hvis man f.eks. ønsker at se hvor meget en ressource er belastet i en given periode, bliver man nød til at få fat i alle projekter for at se om ressourcen har nogle opgaver liggende. Dermed skal man også have fat i de projekter, brugeren normalt ikke må kunne se. Dette kan man gøre ved at imitere en anden bruger (Impersonation), og hente dataset med denne bruger. En lettere måde at gøre dette på er, ved at oprette en forbindelse til databasen og hente alle opgave hvor den pågældende ressource indgår. Hvis man imitere en bruger bliver man nød til at få fat i alle projekter og opgaver, hvis man læser direkte fra databasen kan man lave en SQL-forespørgsel, der kun trækker de opgaver ud der er knyttet til ressourcen. Dette kunne være en mulighed, hvis man skulle lave en ressource belastnings side som den er beskrevet i afsnittet Ressource belastning. Debug i Sharepoint Under udviklingen af PRM havde jeg brug for nogle metoder til at debugge med. En af dem fandt jeg ret smart, og vil derfor gerne vise den her. Når man opretter sin webpart klasse har man muligheden, for at overloade nogle metoder og en af dem er RenderWebPart som bliver kørt når webparten bliver renderet. Her skriver jeg så min debug kode ud til skærmen fra en statisk variabel, denne variable er synlig for alle, så

27 27 jeg på et hvilket som helts tidspunkt kan skrive til denne variabel. Dermed vil jeg så få vist alt debug informationen på skærmen, når programmet bliver kørt. Implementeringen af metoden kan ses i filen ProjectRessurceManeger.cs og et eksempel er givet i figur 18. private static string _debugtxt = ""; public static string debugtxt get return _debugtxt; set _debugtxt += value + " <br /> "; protected override void RenderWebPart(System.Web.UI.HtmlTextWriter output) this.renderchildren(output); output.write("<div><h4>debug::<br />" + debugtxt + "</h4></div>"); Figur 18 Opsætning og debugging I dette afsnit vil jeg beskrive hvordan det er mest fordelagtigt at udvikle og debugge en Sharepoint/PSI applikation. Jeg vil også beskrive hvad der skal til for at sætte applikationen op i PWA. Udviklingen af PRM er lavet på en virtuel server, dette har været både været billigst og mest praktisk. Det praktiske ligger i at, hvis man laver uoprettelige fejl på serveren, kan man altid server installationen og starte forfra på sin backup. Der er dog nogle ulemper ved at udvikle på en virtuel server, den største ulempe er, at den server der kører ens virtuelle server også skal køre mange andre virtuelle servere, dermed bliver ens server meget langsom. Når serven kører langsomt, kan det være svært at udvikle på den. Derfor har jeg valgt at lave selve udviklingen på en klient PC som gennem Remote desktop forbinder til serveren. Denne metode skaber det problem at overfører programmet til serveren, for man kan ikke bare sende data ved at trække dem ind i skærmbillede som man kan med en virtuel PC. PRM er som nævnt udviklede i Microsoft Visual Studio, og det er muligt at sætte dette miljø op til at gemme programmet på et netværksdrev efter kompilering. Hvis serveren også kan få fat i dette netværksdrev, kan man overføre data på denne måde. For at få programmet til at eksekvere i PWA er der et par ting, der skal sættes op på serveren og i miljøet hvor programmet bliver udviklet. Følgende metode beskriver, hvad der skal sættes op i Microsoft Visual Studio for at applikationen kan eksekvere på serveren. 1. Lav et nyt Dynamic Link Library (DLL) projekt. 2. Kopier filen Microsoft.SharePoint.dll fra server mappen %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\12\isapi til PC en hvor applikationen skal udvikles, og lav en reference fra Microsoft Visual Studio til den. 3. Det samme skal gøres for filerne Microsoft.Office.Project.Server.PWA.dll og Microsoft.Office.Project.Server.Library.dll. a. Disse findes ved at man kører scriptet regsvr32 /u [Windows]\Microsoft.NET\Framework\v \shfusion.dll fra en consol. b. Herefter vil filerne blive placeret i mappen [Windows]\assembly\GAC_MSIL\Microsoft.Office.Project.Server.PWA\ e9b ce111e9429c.

28 28 c. Husk at gendanne den DLL fil der lige er blevet af registreret ved at kører scriptet regsvr32 [Windows]\Microsoft.NET\Framework\v /shfusion.dll. 4. Projektet signeres digitalt (Digital Sign). 5. Der skal laves reference til mindst en af seks web services. Dette gøres fra Microsoft Visual Studio og URL erne er som følgende. a. /PWA/_vti_bin/psi/project.asmx?WSDL, webservice til at håndtere projekter og opgaver. b. /PWA/_vti_bin/psi/resource.asmx?WSDL, webservice til at håndtere ressourcer. c. /PWA/_vti_bin/psi/customfields.asmx?WSDL, webservice til at bruger defineret felter. d. /PWA/_vti_bin/psi/LookupTable.asmx?WSDL, webservice til at opslags tabeller (i forbindelse med de bruger defineret tabeller). e. /PWA/_vti_bin/psi/queuesystem.asmx?WSDL, webservice til at håndtere kø systemet. f. /PWA/_vti_bin/psi/security.asmx?WSDL, webservice til at håndtere brugers rettigheder. 6. Tilføj linjen [assembly: System.Security.AllowPartiallyTrustedCallers] til assembly filen. 7. Sidste trin er at tilføje noget brugbart kode, nedenstående kode (figur 19) er kun til at teste man har fået sat alting rigtigt op.

29 29 using System; using System.Collections.Generic; using System.Text; using Microsoft.SharePoint; using Microsoft.Office.Project.PWA; using Microsoft.Office.Project.Server.Library; namespace PSI_Test public class Class1 : Microsoft.SharePoint.WebPartPages.WebPart protected override void CreateChildControls() WSProject.Project project = new WSProject.Project(); WSProject.ProjectDataSet projectds = project.readprojectlist(); Label l = new Label(); l.text = "First project in PWA is :" + projectds.project[0].proj_name; Figur Det sidste der skal bruges for at kunne eksekvere DLL filen på serveren er en XML fil der beskriver og godkender DLL filen. Et eksempel på denne kan ses på figur 20 (den XML fil der er brugt til PRM kan ses i bilag #3). %PublicKeyToken% skal udskiftes med den key som DLL filen får tildelt når den bliver lagt i Global Assembly Cache (GAC), dette vender jeg tilbage til under opsætningen på serveren. <?xml version="1.0"?> <WebPart xmlns=" <Assembly>PSI_Test, Version= , Culture=Neutral, PublicKeyToken=%PublicKeyToken%</Assembly> <TypeName>PSI_Test.Class1</TypeName> <Title>My Simple Web Part</Title> <Description>Only for test</description> </WebPart> Figur 20 Nu har vi en DLL fil der kan blive eksekveret på en Sharepoint server, men før Sharepoint vil godkende filen er der et par ting der skal sættes op. 1. Kopier DLL filen til Global Assembly Cache (GAC) som ligger i mappen C:\WINDOWS\assembly, her får filen tildelt en nøgle som skal skrives ind i XML filen fra før. 2. XML filen fra figur 20 skal uploades til sharepoint af en administrator, dette gør man på URL en 3. Åben web.config filen som findes på %Drev%:\Inetpub\wwwroot\wss\VirtualDirectories\1001 og tilføj følgende linje <SafeControl Assembly="PSI_test, Version= , Culture=neutral, PublicKeyToken=%PublicKeyToken%" Namespace="PSI_test" TypeName="*" Safe="True" />. Denne linje beskriver at DLL filen PSI_test.dll er en godkendt og sicker fil. Læg mærke til at der er forskel på Assembly og Namespace, den første beskriver navnet på filen uden.dll og den anden beskriver namespacet. 4. Genstart IIS.

30 30 Nu kan man indsætte webparten et hvilket som helst sted på gruppen af Sharepoint websteder, alle de Sharepoint sider der ligger på port Dette er en lang og besværlig proces, men når man skal teste webparten skal man ikke igennem alle trinene. For at man ikke skal gøre en masse ting hver gang man skal teste webparten har jeg lavet en batch fil der udfører tingene for en. Batch filen skal ligge samme sted som DLL filen og køreres fra serveren. echo off echo...copying Webpart to GAC... gacutil.exe -if "Z:\Transport_CHF\ProjectRessurceManager_Webpart.dll" echo...resetting IIS... echo IISRESET cscript.exe c:\windows\system32\iisapp.vbs /a "SharePoint " /r Figur 21 Batch filen udfører to ting (kan ses på figur 21), den registrere DLL filen i GAC og genstarter dele af IIS. Programmet gacutil.exe skal også ligge i samme mappe og kan downloades fra Visual Basic scriptet iisapp.vbs er en standart del af Windows Server Det er relativt kompliceret at opsætte en webpart i Sharepoint, og der er mange ting der kan gå galt undervejs. Derfor skal, man have tålmodighed og i første omgang kun gå efter at få skrevet noget tekst til skærmen. Hente projekt information fra PS Når data skal hentes og oploades til Project Server sker det altid gennem en nedarving af klassen Dataset, jeg vil i dette afsnit beskrive hvordan man henter et Dataset, hvad man kan forvente at få hentet, og hvordan man bruger datasettet. Jeg vil kun gennemgå en type dataset, da alle andre dataset fungere på samme måde bare med nogle andre data. Jeg vil tage udgangspunkt i et ProjectDataSet der beskriver en række projekter og hvad der hører til som opgaver, bruger defineret felter, osv. På figur 22 er et eksempel på hvordan man henter et projekts navn og alle opgaver på projektet. WSProject.ProjectDataSet projectdslist = null; projectdslist = project.readprojectlist(); foreach (WSProject.ProjectDataSet.ProjectRow projectitem in projectdslist.project) WSProject.ProjectDataSet projectdsenti = _project.readprojectentities( projectitem.proj_uid, (Int32)(ProjectEntityType.Project ProjectEntityType.Task), WSProject.DataStoreEnum.PublishedStore); WSProject.ProjectDataSet.ProjectRow prow = projectdsenti.project[0]; Label l = new Label(); l.text = "Project : " + prow.proj_name; this.controls.add(l); foreach (WSProject.ProjectDataSet.TaskRow trow in projectdsenti.task) Label l = new Label(); l.text = "Task : " + trow.task_name; this.controls.add(l);

31 31 Figur 22 Det første der sker, er at jeg henter en liste over alle projekter, her får vi udfyldt datasettet med UID på projekter, opgaver, brugerdefineret felter osv. Det skal gøres klart her at datasettet, ikke bliver udfyldt med andet end information om hvordan datasettet hænger sammen med resten af Project Server, selv om datasettet indeholder attributter til navne, datoer osv. Vil disse ikke blive udfyldt når vi kalder ReadProjectList. Derfor er det første jeg gør når jeg løber projekterne igennem at læse alle de attributter ind jeg skal bruge. I dette tilfælde drejer det sig om projekter og opgaver, og dette bliver angivet i metoden ReadProjectEntities. Her bliver også angivet at man benytter sig af published databasen. Nu kan jeg skrive projektets navn ud sammen med alle de opgaver der hører til. Når man henter datasettet, skal man altid sikre sig man får alt den information med, man skal bruge. Som sagt tilbyder ReadProjectList kun en minimal mængde information, og man støder rigtig ofte på den fejl at informationen man troede man havde hentet ikke er der. Ændring af data i PWA Når data på Project Server skal ændres, fjernes, eller tilføjes skal man igennem fire til fem trin for at serveren godkender opdateringen. De tre trin er som følgende. 1. Hent projektet der skal redigeres. 2. Rediger data. 3. Tjek projektet ud. 4. Send projektet til serveren. 5. Tjek projektet ind. 2, 3, 4, og 5 skal altid udføres når man redigere data på serveren. 1 skal kun udføres i de tilfælde hvor skal kunne se hvilke data der er redigeret i projektet. F.eks. hvis man vil tilføje en ny opgave til projektet, behøves man ikke udfører 1 da serveren godt kan finde ud af at der er kommet en ny opgave. Hvis man skal fjerne en opgave fra projektet bliver man nød til at hente alle opgaver på projektet ned, fjerne den der skal væk, og oploade opgaverne igen. Hermed kan serveren se at der er blevet fjernet en opgave. Når man i 3 tjekker projektet ud, kan man risikere at få en fejl, der fortæller at projektet allerede er tjekket ud. Hermed kan man ikke opdatere, og må vente til projektet bliver tjekket ind igen. Når man sender projektet til serveren, skal man være sikker på man har redigeret i det, og ikke har udfyldt det forkert. Hvis man prøver at oploade de samme data, eller referere til en ressource der ikke eksistere får man en fejl. Man skal altid huske at tjekke projektet ind, også når ens program går ned. Hvis man ikke husker dette vil projektet være tjekket ud, ind til der er en system administrator, der går ind og gennemtvinger en indtjekning af projektet. Når man opdatere projektet skal man i nogle tilfælde tage stilling til om der er tilføjet noget til projektet, fjernet noget, eller om projektet bare er blevet ændret. Afhængig af hvad man har lavet på projektet skal der i nogen tilfælde bruges forskellige metoder for at opdatere det, der er ingen regler for hvor når man bruger den ene eller den anden metode så for at finde ud af dette må man kigge i PSI dokumentationen 10.

32 32 Kode eks. Jeg vil her give en kort introduktion til hvordan man bruger PSI til at opdatere Project Server, det vil primært være med fokus på opdatering af et projekt, men metoden kan sagtens genbruges til opdatering af andre typer data. Introduktionen vil være med kode eksempler og disse er taget fra PRM systemet. Når data sendes mellem PRM og Project Server foregår det altid gennem klassen Dataset, eller en nedarving af denne. I det kode eksempel på figur 23 bruger man nedarvingen ProjectDataSet. Det skal nævnes at de fleste try-catch blokke, kommentarer, og debug udskrifter er fjernet for at gøre koden lettere at læse. Guid sessionid = Guid.NewGuid(), jobid = Guid.Empty; QueueHandler queue = null; bool ExeCheckOut = true; try queue = QueueHandler.GetInstance(); try project.checkoutproject(projectuid, sessionid, "Update project"); catch (System.Web.Services.Protocols.SoapException ex) if (ex.message.contains("cicocheckedoutinothersession")) ExeCheckOut = false; return "Project is checked out"; else throw ex; jobid = Guid.NewGuid(); if (update == 1) WSProject.ProjectDataSet changes = (WSProject.ProjectDataSet)projectDS.GetChanges(); project.queueaddtoproject(jobid, sessionid, changes, false); else if (update == 0) project.queueupdateproject(jobid, sessionid, projectds, false); else if (update == -1) project.queuedeletefromproject(jobid, sessionid, ProjectUID, entities); queue.waitforqueue(jobid); finally if (ExeCheckOut) ProjectRessurceManeger.debugTxt = " Checkin in project, task resource updated (State)."; jobid = Guid.NewGuid(); project.queuecheckinproject(jobid, ProjectUID, true, sessionid, "UpdateCodevalueSessionDesc"); queue.waitforqueue(jobid); ProjectRessurceManeger.debugTxt = " Project checked in."; Figur 23 Som det ses i koden starter jeg med at hente et kø objekt, dette bliver beskrevet nærmere i afsnittet Kø håndtering. Herefter prøver jeg at tjekke projektet ud, her bliver givet tre argumenter. 1. UID et på det projekt der skal tjekkes ud. 2. Sessionen projektet bliver tjekkede ud i, denne skal senere bruges til at tjekke projektet ind igen.

33 33 3. En beskrivelse af sessionen, til at gemme i loggen og så andre kan se hvad der bliver lavet på projektet. Denne kan en, brugere bruge til at bestemme hvor lang tid der går før projektet bliver tjekkede ind igen. Hvis der bliver kastet en Exception under udtjekeningen, kan man undersøge meddelelsen for om den indeholder en tekst streng der beskriver om projektet allerede er tjekket ud. Man kan også bruge metoden ReadProjectStatus, men her får man alle projekters status og hvilke rettigheder man har på dem. Det er klart at dette vil give en del mere data der skal hentes og dermed tage længere tid, derfor mener jeg det er bedre at prøve at tjekke data ud og håndtere resultatet. En ulempe ved denne metode er at beskeden der bliver kastet når projektet er tjekkede ud kan ændre sig i fremtidige opdateringer af Project Server. Herefter bruger jeg en af tre metoder til enten at opdatere, tilføje, eller slette elementer i projektet. Disse tre metoder fungerer næsten på samme måde og jeg vil kun gennemgå QueueUpdateProject. Denne tager tre parameter der beskriver følgende: 1. Job ID er et ID man kan bruge til at tjekke om opdateringen er kommet igennem køen, evt. kunne programmet foretage sig noget andet mens køen opdatere Project Server. 2. Sessions ID et så Project Server kan give en fejl hvis man prøver at opdatere et projekt der er tjekket ud i en anden session. 3. Datasettet med de data der skal opdateres. 4. Angiver om data kun skal valideres til opdatering eller om de realt skal opdateres. QueueAddToProject fungere på samme måde her skal man bare kun udfylde datasettet med de elementer der skal tilføjes. På samme måde skal man med QueueDeleteFromProject kun give UID er på de ting der skal fjernes. Her efter skal man vente på at køen får kørt færdig, og til sidst kalder jeg QueueCheckInProject med sessions UID et for at frigive projektet så andre kan arbejde på det. Hvis de data man har opdateret skal over i Publiched databasen, skal man også kalde QueuePublish med projekt UID et. Hvis man ikke gør dette vil data blive liggende i Draft databasen og det vil kun være den bruger der er logget ind at se ændringerne. Som det er nu tjekker jeg et projekt ud og ind hver gang noget skal opdateres, det vil sige at hvis man udskifter status på to forskellige projekter fra brugergrænsefladen vil projektet blive tjekkede ind og ud to gange. Desværre har PSI ikke nogle direkte regler om hvornår man skal kalde Update, AddTo, og Delete metoderne. Hvis den havde dette ville det være oplagt kun at tjekke projektet ind og ud når websiden genloades. Dette kan stadig opnås, men man skal holde godt styr på hvornår man gør hvad ved projekterne, og da PSI i forvejen har meget dårlige fejl beskeder kan det blive meget svært at se hvor en fejl opstår hvis man kun opdatere projektet et sted. Fordelen ved denne metode vil helt klart være at opdateringerne vil komme til at kører meget hurtigere, primært fordi man ikke skal vente på køerne, men også fordi man ikke skal oprette forbindelse til serveren flere gange. Denne metode at opdatere projekter på er hurtigst at implementere, og er helt sikkert den metode der er mest sikker da det er meget let at se hvor fejlene opstår henne. Det er derimod også den metoder der tager

34 34 længst tid at eksekvere. Hvis jeg havde haft længere tid og havde brug for at optimere systemet ville dette helt klart være det bedste sted at starte. Sletning af projekt medlemmer Det er beskrevet i afsnittet hvordan man oploader et dataset til Project Server gennem PSI, umiddelbart vil det altid være simpelt at ændre i datasettet, men når man skal fjerne en ressource fra et projekt er der en lille fejl i PSI. Når man skal fjerne en ressource i et projekt trækker man først projekt teamet ud af Project Server og gennemløber alle ressourcerne, når man finder den ressource man vil fjerne, så kalder man projectteamds.projectteam.removeprojectteamrow(rowtoremove); og sender datasettet tilbage til serveren. Problemet er her at metoden RemoveProjectTeamRow ikke fungerer, beskrivelsen af denne metode kan findes på og her er der ikke meget dokumentation af metoden at komme efter. Dette har været et stort problem at løse, for selv om man fjernede rækken på mange andre måder, så fungerede det stadig ikke. Desværre var det ret esientcielt for opgaven, så jeg kunne ikke komme uden om problemet. Til sidst fik jeg den ide at decompile de DLL filer der bliver brugt til at håndtere Dataset klassen (decompileringen blev udført med programmet Dis# [Dis#] ). Inde i Dataset klassen blev der fjernet en masse referencer når en række bliver fjernet og det var meget svært at finde ud af hvor disse referencer hørte til henne. Men på rækkerne findes der også en Delete metode som fjernede rækken på en helt anden måde. Dermed fandt jeg frem til at jeg kunne fjerne en række ved at køre den kode der ses på figur 24. #region deletefromdataset for (int i = 0; i < projectteamds.projectteam.rows.count; i++) Guid resrowid = (Guid)projectTeamDS.ProjectTeam.Rows[i].ItemArray[1]; if (resuid == resrowid) projectteamds.projectteam.rows[i].delete(); #endregion Figur 24 Heraf ses det at jeg løber alle rækkerne igennem, og når jeg finder det ressource UID jeg skal bruge kalder jeg Delete metoden. At decompile.net for at finde frem til årsagen til ens fejl kan være en meget tidskrævende og langsommelig proces, derfor skal denne metode kun vælges hvis man ikke har andet valg. Jeg havde også en anden mulighed, for gennem Projectum kunne jeg oprette en sag hos Microsoft som så ville løse problemet for mig, problemet var bare at hvis det var mig der tog fejl så skulle Projectum betale for tiden. Derfor valgte jeg selv og prøve at løse problemet, da jeg ikke ville være skyld i at Projectum tabte penge. Vise ressource belastning Som det er beskrevet i use casen Vise ressource belastning, kan ses i bilag 1, skal det være muligt at komme fra PRM siden til en side hvor man kan se hvor belastet en given ressource er. Ideen er at man skal kunne klikke på den pågældende ressource og denne så skulle linke til siden

35 35 /PWA/_layouts/PWA/RM/ResAvailability.aspx som også kan ses på figur 25 (fremover kaldet ressource belastnings siden). Ressource belastnings siden Figur 25 Ressource belastnings siden fremkommer normalt ved at man går fra PWA s startside til ressource siden, vælger de ressourcer man vil se og klikker Vis tilgængelighed herefter bliver man navigeret til ressource belastnings siden (på figur 25 er der kun valgt en ressource). Det var oprindelig tanken at PRM siden skulle linke direkte til ressource belastnings siden, men dette kunne af tekniske årsager der er beskrevet senere i dette afsnit ikke lade sig gøre. Hvis man kalder URL en til ressource belastnings siden i en browser, får man kun siden vist med den ressource der logget ind. Når man vælger sine ressourcer på ressource siden, så videregiver denne side de indtastede data til serveren. Der er to måder at sende data fra en webside til serveren, den ene kaldes Get og fungere ved at data bliver lagt i adressen til den side der skal hentes. Dette ses blandt andet på Google 3 hvor de søge ord man har brugt efter en søgning står oppe i adresse linjen. Den anden metode at sende data på kaldes Post, her bliver data sendt i headeren af http forespørgslen og det er dermed ikke muligt for brugeren at se de data. For at man kan loade ressource belastnings siden med andre ressourcer end den man er logget ind som, bliver man nød til at poste samme type data som ressource siden gør, men dette er i midlertidig ikke lige så nemt som når man bruger Get. De data der bliver postet kan man ikke se fra klientens side, derfor bliver man nød til at benytte sig af et program der kan opsnappe de data der bliver sendt, et program der kan gøre dette er Komodia 4. Med dette program fandt jeg frem til at ressource siden poster en stor mængde data til forskellige sider sandsynligt for at autorisere sig selv over for serveren. Det sidste den sender før den får ressource belastnings siden returneret kan ses på figur 26.

36 36 Content-Length: 89 Post data fra Rexource.aspx returnlocation=1&resource_uids=23c1f2d3-330a d- 0edcfc502c37&sender=resource.aspxHTTP/ OK Cache-Control: no-cache Figur 26 Heraf ses det at ressource UID et bliver angivet, en variable returnlocation bliver sat, og den fortæller hvilken side der laver forespørgslen. Variablen returnlocation har jeg ikke kunne finde frem til hvad betød, om det er tilladt at have andre værdier i sender variablen eller om ressource belastnings siden kun tillader ressource.aspx vides heller ikke. For at poste disse data til serveren ville man normalt bruge en HTML-form, men i dette tilfælde skal det ske automatisk så her må vi anvende Javascript. På figur 27 ses et Javascript som laver samme forespørgsel som det der ses i figur #33. Dette Javascript opretter en form, sætter siden der skal loades, og angiver metoden til post. Nu sættes de tre variable op som ressource siden sendte og til sidst bliver formen sendt af sted. Post Javascript <script type= text/javascript > function post() var myform = document.createelement("form"); myform.method = "POST"; myform.action = " var myinput = document.createelement("input"); myinput.setattribute("returnlocation", "1"); myform.appendchild(myinput); myinput = document.createelement("input"); myinput.setattribute("resource_uids", "23c1f2d3-330a d-0edcfc502c37"); myform.appendchild(myinput); myinput = document.createelement("input"); myinput.setattribute("sender", "resource.aspx"); myform.appendchild(myinput); document.body.appendchild(myform); myform.submit(); document.body.removechild(myform); </script> Figur 27 Dette virker i midlertidig ikke, når formen bliver sendt af sted kan man gennem Komodia 4 se at de værdier der bliver sendt er rigtige. Siden bliver også loadet, bare ikke med den ressource man har angivet, men med standart ressourcen. Grunden til at scriptet ikke fungere som forventet kendes ikke, det kan være det skyldes nogle af de data ressource siden sender tidligere ikke bliver sendt gennem Javascriptet. Eller at siden ikke er autoriseret hos PWA ligesom ressource siden er. Det er også muligt at ressource belastnings siden tjekker hvilken side det er der laver forespørgslen evt. med et UID på siden. For at finde svaret er den eneste umiddelbart løsning at decompile de DLL filer der hører til ressource siden og ressource belastnings siden, dette er en

37 37 større proces og der er ingen garanti for at man kan finde en løsning. Dermed stoppede jeg udviklingen på denne opgave her, da jeg mente sandsynligheden for at den førte til et resultat var for lille. Opgavens omfang Denne opgave var estimeret til 3 timer, hvilket jeg på daværende tidspunkt mente, var relativt højt sat. Det skulle vise sig at tage 9 timer at finde ud af det ikke kunne lade sig gøre. Funktionaliteten var oprindeligt tilføjet til opgaven fordi det umiddelbart linede en let og hurtig måde at få noget brugbart funktionalitet på. På denne baggrund har jeg valgt ikke at inkludere denne funktionalitet på dette tidspunkt, i afsnittet Alternativ løsning kan ses hvordan det kan lade sig gøre at implementere en ligne løsning og et estimat på hvor lang tid det vil komme til at tage. Alternativ løsning For at få funktionaliteten med kan man altså decompile ressource siden og håbe på man kan finde en løsning i dens kode. En anden løsning kunne være selv at oprette en ASP.Net eller Sharepoint sider der forbinder til PSI og henter de samme oplysninger. For at finde disse oplysninger skal man have en administrator konto der har rettigheder til at se alle opgaver. Med denne kan man så hente alle opgaver og se om ressourcen er på en eller flere af dem. Afhængig af antallet af opgaver i Project Server kan dette komme til at tage ret lang tid da alle opgaver skal hentes hver gang. Der skal også laves en spike i ASP.Net til at få tegnet de grafiske elementer der er brug for, som en kurve over tid der beskriver hvor meget ressourcen er belastet. For at lave PSI kaldene til at få ressourcens belastning vil jeg vurdere det vil tage ca. 12 timer. For at lave spiken og få resultaterne fra PSI kaldene afbillede vil jeg vurdere det vil tage henholdsvis 6 og 4 timer. Så alt i alt for at få lavet denne side vil det ca. tage 22 timer og her er load factoren ikke regnet ind i. Som sagt vil dette ikke blive implementeret, men dette er det nuværende omfang af opgaven hvis den skal implementeres på et senere tidspunkt. Klint script Jeg vil her kort gennemgå hvordan et klient script kan blive inkluderet i en webpart, og hvordan man finder ASP.Net kontroller fra klient scriptet. Da jeg kun har brugt Javascript i PRM vil jeg også kun gennemgå Javascript. Visual Basic script vil ikke blive gennemgået, men metoderne er de samme. Fra websiden kan man normalt gøre to ting for at bruge Javascript på en webside, den ene er ved at oprette en funktion i hoved af siden og den anden er ved at skrive scriptet der hvor det skal udføres. Selvfølgelig kan man også inkludere Javascript fra en anden fil, men dette giver en masse rettigheds problemer da klienten skal kunne tilgå den mappe scriptet ligger i. <html xmlns=" <head> <title></title> <script type="text/javascript"> function ViewTxt() document.getelementbyid('txt').style.display = 'inline'; <html xmlns=" <head> <title></title> </head> <body> <input type="button" value="view text" onclick="document.getelementbyid('txt').style.display = 'inline';"/> <br />

38 38 </script> </head> <body> <input type="button" value="view text" onclick="viewtxt();"/> <br /> <div id="txt" style="display:none;"> Here are some text. </div> </body> </html> Figur 28(A) <div id="txt" style="display:none;"> Here are some text. </div> </body> </html> Figur 28(B) På figur 28(A) er et eksempel på en HTML side hvor Javascriptet er lagt i en funktion, og på figur 28(B) er et eksempel på at javascriptet er lagt ind i det element der udfører det. Det er klart at når man skriver og skal læse web side koden, så er det lettest at have Javascriptet lagt som funktioner. Men når vi skal lave javascriptet i webparten, så skal vi have adgang til den side det ligger i og registrere det. Dette kan gøres med metoden RegisterClientScriptBlock som findes i objektet WebPart.Page.ClientScript, dette giver desværre nogle gange nogle problemer fordi Sharepoint ikke altid vil tillade at man registrere nye scripts på siden. Derfor har jeg flere steder i PRM valgt at lade Javascriptene stå i HTML elementerne, det skal nævnes at dette ikke kommer til at betyde noget for måden hvorpå scriptet opfører sig på. For at kunne få fat i ASP.Net kontrollerne fra Javascript skal man have ID et på dem, dette er et stort problem i ASP.Net fordi ID et i de fleste tilfælde først bliver genereret når ASP.Net genererer siden. I enkelte tilfælde kan man få klient ID et fra ASP.Net tidligere, men ellers er der ingen måde at løse dette problem på. Der er dog en måde hvorpå man kan komme rundt om problemet, i ASP.Net kan man skrive HTML kode direkte på siden med klassen LiteralControl. Med denne klasse kan man så oprette de HTMLelementer Javascript skal have fat i og tildele dem sine egne ID er.f.eks. skriver jeg en HTML-Div rundt om hele webparten så jeg kan skjule siden når jeg skal have vente skærmen frem. Det er dermed lidt besværligt at bruge Javascript sammen med ASP.Net og Sharepoint, men desværre er det en nødvendighed for at brugeren ikke hele tiden skal vente på at siden genloader. En anden mulighed til Javascript er AJAX som giver mulighed for at eksekvere.net kode hos klienten. Desværre har jeg ikke nogen erfaring med AJAX og har heller ikke haft tid til at sætte mig ind i det. Vente skærm Som nævnt i Analyse afsnittet skal brugeren have hurtigt svar når han klikker på knapper i webparten. Dette kan ikke altid lade sig gøre fordi der er ting på serveren der tager meget langt tid at udføre, derfor har jeg valgt at implementere en vente skærm, så hver gang brugeren klikker på en knap kommer der en skærm der fortæller at webparten arbejder. Denne skærm forhindrer også en utålmodig bruger i at klikke på de samme knapper flere gange. Jeg vil i dette afsnit gennemgå hvordan denne skærm er implementeret. Det første jeg sætter ind på siden er HTML koden til skærmen (kan ses i SubmitWaitScrn.cs på CD en), dette er en HTML-div der ligger skjult på siden ind til den skal bruges. Inde i denne har jeg en tekst og et billede, billede er taget fra PWA s layout. Herefter kalder jeg metoden Page.ClientScript.RegisterOnSubmitStatement som registrere det Javascript der skjuler hoved skærmen og viser vænte skærmen. Dette script kan ses på figur 29. document.getelementbyid('loadingimg').src='/_layouts/pwa/images/progress.gif?' + (new Date()).getTime();

39 39 document.getelementbyid('loadingscrn').style.display = 'inline'; document.getelementbyid('loadingscrn').style.visibility = 'visible'; document.getelementbyid('loadingscrn').style.height = '400px'; document.getelementbyid('" + globalcontrolname + "').style.height = '1px'; document.getelementbyid('" + globalcontrolname + "').style.display = 'none'; window.scroll(0,0); Figur 29 Som det ses af figuren bliver der foretaget en del ændringer for at scriptet fungere. Dette skyldes en lille fejl i Microsoft Internet Explorer 7 og 8 (IE), denne fejl består i at når et link bliver klikket vil alle gifanimationer blive stoppet. Derfor genloader jeg gif-billede med et tids stempel så IE tror at billede har ændrede sig og genstarter afspilningen. Dette problem findes ikke i Mozilla Firefox eller Google Chrome, men resten af PWA understøtter heller ikke disse. På denne måde får vi vist en skærm med en animation mens siden genloades, det skal dog nævnes at selv om det ser ud som om det er serveren der fortæller brugeren at den arbejder, så er serveren ikke forbundet til siden og hvis serveren bryder sammen under denne proces vil animationen kører ind til IE laver timeout. Grafisk design For at få et grafisk design der er ens hele vejen igennem og ligner det øvrige PWA design har jeg brugt to teknikker. Den første er at jeg har lavet en klasse ved navn styles som indeholder nogle ASP.Net style klasser, disse kan man så sætte på en hvilken som helst nedarving af Control klassen når denne bliver oprettet. Stort set alle ASP.Net s grafiske elementer nedarver fra Control klassen. Dermed har man et samlede sted hvor alle tekst typer, tykkelse af forskellige streger, farver, osv. bliver defineret. Dette gør det også utrolig nemt at ændre farver og tekst fonte på alle elementer samtidig. Nogle grafiske elementer i PWA var meget svære at efterligne, blandt andet overskriften som ligger på alle af PWA s webparts. Derfor har jeg valgt at sætte CSS klasserne til det samme som PWA sætter dem til, dermed kommer PRM s grafiske elementer til at ligne det øvrige PWA også selv om PWA skulle ændre udseende efter en opdatering. Normalt skal man i HTML inkludere sine CSS filer, men uanset hvilken side man loader i PWA er der altid en række CSS filer som PWA inkluderer, så derfor man behøves ikke selv inkludere dem i webparten. Der er kun en måde at finde ud af hvilken CSS klasse et HTML element bruger, og det er ved at åbne den side hvor HTML elementet bruges og vise HTML koden. Vær opmærksom på at forskellige HTML elementer godt kan være i samme CSS klasse, men få tildelt forskelligt layout i CSS filen. F.eks. kan et HTML-table og et HTML-div begge hører til CSS klassen NotesControl, men i CSS filen hvor klassen er defineret bliver de udskilt som det ses på figur 30. Så hvis man tildeler en HTML-div CSS klassen NotesControl kommer den bestemt ikke til at ligne et HTML-table med samme CSS klasse. CSS klasse TABLE.NotesControl width: 100%; DIV.NotesControl background-color: #FFFFCC; border: 1px solid #7D8189; height: 200px; overflow-y: auto;

40 40 padding: 5px; scrollbar-arrow-color: #0760A2; scrollbar-darkshadow-color: #EFEF6B; scrollbar-face-color: #EFEF6B; scrollbar-highlight-color: #FFFFE7; scrollbar-shadow-color: #EFEF6B; scrollbar-track-color: #FFFFCE; width: 100%; Figur 30 Disse to metoder fungerer rigtig godt, specielt den med at bruge CSS klasserne. Flere kommende bruger har set PRM systemet og har givet det ros for at det falder meget naturligt ind i resten af PWA. Kø håndtering Som det er nævnt i afsnittet Ændring af data i PWA skal man vente på at køen i Project Server bliver kørt færdig efter hver gang man har opdateret noget på serveren. Jeg vil i dette afsnit beskrive hvordan PRM håndtere køen med kode eksempler der er taget fra klassen QueueHandler, hvorfor og hvornår det er vigtigt at vente på at data bliver kørt gennem køen. Det vil i de fleste tilfælde altid være meget vigtigt at vente på at ens data bliver kørt gennem køen. Hvis man ikke venter, risikerer man at ens opdateringer ligger i køen mens man forespørger data. Her kommer to eksempler, et på det er nødvendigt at opdatere og et på det ikke er nødvendigt. I første eksempel har vi en webpart hvor vi viser projekter, og giver brugeren mulighed for at slette dem. I figur 31 kan der ses, et sekvens diagram der viser hvad der sker i webparten, køen og på projekt server. Slet projekt uden kø håndtering Figur 31 Først kalder brugeren webparten og får vist alle projekter i Project Server, herefter vælger han at slette et projekt og får vist samme webside igen. Det der sker, er at når han vælger at slette projektet vil forespørgslen blive lagt i køen og på det tidspunkt hvor Project Server sender projekterne til webparten vil køen ikke have slettet projektet fra databasen. Dermed vil brugeren stadig kunne se det projekt han lige har slettet, skulle han derimod prøve at slette projektet igen vil han få en fejl. I dette eksempel er det meget tydeligt at det er ekstremt vigtigt at vente på at Project Server udfører det man beder den om. Af dette kan man konkludere at det er meget vigtigt at vide hvornår man skal vente på køen, man kan i nogle specielle tilfælde lade være med at vente på køen og der er også en del eksekverings tid at spare her.

41 41 Af den erfaring jeg har fået gennem udviklingen af PRM, mener jeg at man i langt de fleste tilfælde nød til at vente på at køen får udført handlingerne. I andet eksempel har vi en webpart der viser opgaver med deres tildelte ressourcer, det er muligt for brugeren at fjerne den tildelte ressource fra opgaven. Som beskrevet i Project Server afsnittet består en ressource tildeling til en opgave af at opgaven kender til en tildelings klasse og der eksisterer en tildelings klasse til netop denne opgave. Dermed skal opgaven redigeres og tildelings klassen skal slettes for at fjerne tildelingen. På figur 32 er denne sekvensen hvor en bruger forespørger webparten og fjerner en ressource beskrevet. Slet projekt uden kø håndtering Figur 32 Heraf ses det, som i det andet eksempel, at brugeren forespørger webparten og får alle opgaver og ressourcer tilbage. Nu fjerner han en ressource fra en opgave, og denne handling bliver sat i kø, men tildelings klassen slettes ikke brugeren har fået vist alle opgaverne fra webparten. Dette kan man gøre fordi efter man har fjernet opgavens reference til tildelings objektet vil ressourcen ikke længere være tildelt. Man skal dog huske at slette tildelings objekterne, ellers vil disse hobe sig op i databasen. Postback I dette afsnit vil jeg beskrive hvordan ASP.Net håndtere events på serveren, hvordan man finder ud af hvad brugeren har ændret, og hvilke komplikationer genloadning af siden medfører. Når ASP.Net beder om en webside på serveren fortæller den samtidig om forespørgslen kommer på baggrund af en event eller om det er en ny side der skal loades. Når brugeren aktivere en event og siden genloades kaldes det et postback. Postback fungerer på den måde at når siden genloades bliver initialisereingen af siden kørt igen. Her ved siden selvfølgelig at den loades på baggrund af en event, men den ved på nuværende tidspunkt ikke hvilken event der har, forudsagde forespørgslen. Dette finder man først ud af når initialiseringen af siden er kørt og event handleren bliver kaldt. Hvis eventhandleren vil ændre nogle af de GUI elementer der er på siden får man et problem, for GUI elementerne er allerede tilføjet på siden. Hvis man ønsker at ændre et GUI element på siden, skal man gemme en reference til den så man i eventhandleren kan ændre på denne reference.

42 42 Som det er beskrevet i MVP afsnittet prøver jeg at adskille presenter laget fra view laget. Dette bliver desværre lidt kompliceret at gøre her fordi eventhandleren skal kende til de GUI elementer der ligger i presenter laget, presenter laget skal samtidig gemme de GUI elementer den har sendt til view laget. Hermed vil presenter laget blive centrum for alt kommunikation mellem klasserne, og det vil blive meget svært holde styr på om alle GUI elementerne bliver tildelt en instans. Derfor valgte jeg at overskride MVP s regler en lille smule ved at holde referencerne til de GUI elementer der skulle genloades i view laget. Dette har ikke den store betydning for programmet, ud over at ProjectResourceManeger klassen bliver lidt stor. Rettigheder For at være sikker på der ikke opstår fejl når brugeren loader websiden, bliver jeg nød til at tjekke om han har de fornødne rettigheder PRM skal bruge til at kontakte Project Server. Egentlig burde jeg også tjekke om han har de fornødne Sharepoint rettigheder, men hvis han ikke har disse vil han slet ikke kunne tilgå PWA og finde linket til siden. Jeg tjekker hans rettigheder i et PSI kald til Project Server, dette sker ikke gennem nogle af PSI modulerne, men bliver håndteret som en event i Event Handler modulet. Grunden til dette er at jeg ikke ønsker at oprette klasserne i PSI modulerne hvis brugeren ikke har rettigheder til at bruge dem alligevel. På figur 34 er et eksempel på hvordan man laver et PSI kald til at tjekke om en rettighed eksistere. Her tjekker jeg om han har rettigheder til at tildele en ny ressource til en opgave. bool ReassignTaskPermission = security.checkuserglobalpermission(pssecurityglobalpermission.reassigntask); if (!ReassignTaskPermission ) missing.add((string)langauge.txt["reassigntask"]); Figur 34 Hvis han ikke har rettigheder til dette tilføjer jeg denne rettighed til manglende rettigheder. Denne kode bliver gentaget for alle de rettigheder PRM skal bruge for at hente og opdatere de relevante data. Det er altid vigtigt at lave disse tjek, da det kan være meget svært for en system administrator at finde ud af hvorfor webparten ikke fungere. Language Da det i fremtiden kan blive en fordel at systemet understøtter flere sprog, er der blevet implementeret 2 sprog i systemet, Engelsk og Dansk. Dette er rimelig simpelt at implementere når man udvikler systemet, men kan være en større udfordring hvis det skal implementeres på et senere tidspunkt. Muligheden for at udvide med et eller flere ekstra sprog er lavet utroligt dynamisk og det kraver stort set kun at der er en der oversætter systemet. Det er kun tekst som brugeren kan se der bliver udgivet i to sprog, tekst der bliver skrevet ud til fejlfinding eller tekst der bliver sendt i adresse linjen vil være på engelsk.

43 43 For at implementere to sprog har jeg lavet en klasse til at håndtere sproget, kan ses på figur 35(A). Her har vi to tabeller der har en nøgle og et indeks. Nøglen bruges til at referere den tekst man vil have fat i og teksten får man returneret. Et eksempel på brug af klassen kan ses i figur 35(B). Langauge klassen Eksempel på brug ((string)langauge.txt["noresassn"]) Figur 35(A) Figur 35(B) Her hentes en tekst med nøglen noresassn, fordelen ved at lave nøglerne som tekst frem for tal er at det er lettere at læse koden. LanguageID beskriver et ID i sharepoint der identificerer sproget, så hvis en klasse eller metoders funktionalitet afhænger af sproget kan man give dette ID med. Sprog funktionaliteten har ikke givet de store problemer at implementere, og det er let at rette stave fejl og tilføje nye sprog til systemet. Delkonklusion Der har været en del elementer i dette projekt som har forvoldt problemer under implementeringen. Den samlede oplevelse af brugen af XP systemudviklingsmetoden har været god i denne sammenhæng, den har specielt levet op til forudsætningen om at man kan variere omfanget af projektet i forholdt til hvor hurtigt projektet skrider frem. Der hvor der har været komplikationer er det primært på grund af de teknologier PRM er udviklede til. Designet af systemet har ikke givet større komplikationer, på nær optimering, så på denne front må man også sige at XP lever op til forventningerne. Der har også været overskud til at få implementeret elementer som forskellige sprog og vente skærm, hvilket vil give en god helheds fornemmelsen for brugeren.

44 44 Kapitel 4 Resumé I dette afsnit vil jeg beskrive hvordan test af systemet er blevet udført, herunder vil jeg komme ind på hvordan V-modellen og XP test er brugt. Da der ikke har været mulighed for at udfører alle typer test, vil jeg også beskrive hvilke test der ikke er blevet udført og hvilke konsekvenser det har for systemet. Jeg vil komme ind på hvordan jeg har lavet automatiserede test på dele af systemet. Da jeg bruger XP har jeg også lavet acceptance test, og det vil kort blive gennemgået hvordan disse er udført. Test Ifølge XP skal alle test helts være automatiseret så det er let at gentage dem 21. Dette skulle medføre at det bliver lettere at omdesigne programmet fordi man hurtigt kan afprøve nye design og se om systemet består testen. XP er også fortaler for at man skriver testene før man begynder at udvikle komponenterne, på denne måde får man et bedre overblik over hvad det er for en komponent man skal udvikle før man går i gang med at udvikle den. Automatiserede test Reglen om at test skal automatiseres har jeg kun overholdt delvist. Årsagen til dette er at det hurtigt bliver meget besværligt at automatisere test af en grafisk webside. Der for har jeg kun brugt automatiserede test på nogle bestemte moduler, dette drejer sig om modulerne PSI Retrieve Data og PSI Update Data. Som nævnt tidligere står disse moduler for at hente og opdatere data fra Project Server. Dermed var det ikke alt for besværligt at automatisere disse moduler, dog skal man være opmærksom på at for at testene virker så skal der være projekter, ressourcer og opgaver i Project Server databaserne. Udover dette skal der også minimum være et projekt som ikke er publiceret endnu for at publiceringsmetoden fungere. Alle de automatiserede test kan ses i bilag 5, jeg vil her give et eksempel på hvordan en af dem fungere. Denne automatiserede test kan ses i figur 36. Som tester en metode der skal ændre en ressource på en opgave. For ikke at have for meget kode i figuren, har jeg udladet selve metoden og andre hjælpe metoder til testen. static void Main(string[] args) Program p = new Program(); p.initwebsvc(); WSProject.ProjectDataSet.ProjectRow pr = p.project.readprojectlist().project[0]; WSProject.ProjectDataSet.TaskRow task = null ; Task = p.project.readproject(pr.proj_uid, WSProject.DataStoreEnum.PublishedStore).Task[1]; WSProject.ProjectTeamDataSet.ProjectTeamRow teamrow = null; teamrow = p.project.readprojectteam(pr.proj_uid).projectteam[1]; Console.WriteLine("Proj name: " + pr.proj_name); Console.WriteLine("Task name: " + task.task_name); Console.WriteLine("Res name: " + teamrow.res_name); p.testupdatetaskresource(pr.proj_uid, task.task_uid, teamrow.res_uid); WSProject.ProjectDataSet projectds = p.project.readproject(pr.proj_uid, WSProject.DataStoreEnum.PublishedStore); WSProject.ProjectDataSet.AssignmentRow[] assignments = null; assignments = (WSProject.ProjectDataSet.AssignmentRow[])projectDS.Assignment.Select( "TASK_UID='"+task.TASK_UID+"'"); if (assignments[0].res_uid == teamrow.res_uid) Console.WriteLine("Success, task ressource changed"); else

45 45 Console.WriteLine("Faild, task ressource not changed"); public void TestUpdateTaskResource(Guid projectuid, Guid taskuid, Guid newresuid) Figur 36 Først henter jeg et projekt fra serveren og finder den første opgave frem så vi kan opdatere den. Derefter kigger jeg i projekt teamet, for at finde en ressource jeg kan sætte på opgaven. Nu kører jeg metoden der skal testes, og derefter finder jeg tildelingerne frem og filtrere dem efter opgaven. Hvis tildelingen har et, ressource UID der stemmer overens med det jeg havde sat den til, så har metoden bestået. Hvis ressource UID et ikke stemmer over ens, så har metoden fejlede. Denne test har nogle forudsætninger, den mest åbenlyse forudsætning er at der skal være ressourcer, opgaver og projekter i databaserne. Men en anden forudsætning er at der ikke må ligge ubrugte tildelinger i databaserne, da jeg så kan risikere at få fat i en tildeling der peger på opgaven, men ikke har nogen ressource. Dette er også en forudsætning som Project Server stiller, men det betyder ikke at andre 3 parts programmer ikke kan have glemt og slette nogle tildelinger. V-Modellen Når man begynder at udvikle et program, starter man som regel med at lave en analyse af systemet, og på et tidspunkt begynder man at implementere det. Det er så samtidig her man først begynder at teste sin kode, på et tidspunkt har man en række komponenter, der kan sættes sammen og det færdige system begynder at udforme sig. Her er det så at man ofte glemmer at teste i alle de mellemliggende lag. For at undgå dette har jeg valgt at bruge V-modellen til at få mine test strukturerede. V-modellen går ud på at man laver test efter alle de niveauer systemet udvikles efter. I dette tilfælde drejer det sig om analyse, design, modul og kode niveau. På figur 37 ses V-modellen som den er brugt under udviklingen af PRM. V-modellen Figur 37 På det øverste niveau fortager man analysen, og dette bliver direkte omformet til acceptance test, acceptance test er de eneste black box test i V-modellen. Når systemet bliver designet skal der også laves test efter om designet fungere efter hensigten, hvis der er nogle designmæssige komplikationer skal der også testes for disse. Samspillet mellem modulerne skal testes, og til sidst skal der også laves løbende test af koden. Alt disse typer test har jeg udført, og det har hjulpet til med at finde mange fejl tidligt i udviklingen. V-modellen er rigtig god at teste efter da den sikre at man får testet systemet på alle niveauer, og den afhjælper dermed de meget kompliceret fejl man finder til sidst, fordi de allerede er fundet tidligere i systemet.

46 46 Acceptance test Acceptance test er test som brugeren har skrevet, og indeholder de test som brugeren forventer systemet skal kunne. Som nævnt tidligere har jeg ikke haft nogen direkte bruger knyttet til dette system, derfor har jeg selv agerede bruger og skrevet acceptance testene. Acceptance testene er udformet ud fra use casene (kan ses i bilag 1) og der er en acceptance test for hver use case. Jeg vil her give et eksempel på hvordan en acceptance test ser ud, alle acceptance testene kan ses i bilag 6. En acceptance test indeholder hvad brugeren trygger på og hvad han forventer der skal bliver udført efterfølgende. Eksemplet kan ses i figur 38. Handling Resultat Bestået Brugeren vælger en ny Der fremkommer et billede der fortæller at systemet er i gang Ja tilstand for et givent projekt og trygger gem. med at opdatere. Når siden genloades vil projektet være forsvundet for listen, og projektet vil være publiceret til alle andre brugere Figur 38 Handlingen er en kort beskrivelse af hvad brugeren foretager sig og resultat er hvad der sker når brugeren udfører handlingen. Bestået beskriver selvfølgelig om systemet har bestået testen. Alle acceptance test er bestået på nær to, og dette skyldes at der ikke har været tid til at implementere dem. Stress test På nuværende tidspunkt er der udført acceptance test, automatiseret test og test efter V-modellen på PRM. Da PRM er et web system, har det nogle egenskaber andre programmer ikke har. PRM kan nemlig tilgås af mange brugere på samme tid og når dette sker, kan der opstå fejl, som ikke før havde været synlige. For at lave nogle test som stresser systemet, kræver det enten man har et stort antal brugere der kan arbejde på systemet, eller at man har et værktøj der kan lave stress test af systemet. Da jeg ikke har 30 bruger til rådighed der kan teste mit system af, bliver jeg nød til at bruge et værktøj til at teste med. Det var oprindelig planen at jeg kunne bruge et miljø der har programmer til at stress teste Sharepoint applikationer, som Projectum har stående til rådighed. Men da et andet projekt i firmaet har brugt dette værktøj, har det ikke været muligt for mig at få adgang til det endnu. Dette vil jeg selvfølgelig få på et senere tidspunkt, men på nuværende tidspunkt er PRM ikke blevet stress testet. Delkonklusion Test af systemet er primært blevet udført efter V-modellen, denne har været god til at opfange fejl tidligt i udviklingen, men den har manglede nogle elementer til at automatisere test. Det har af ikke været muligt at lave stress test på systemet, hvilket betyder at man ikke kan sige hvordan systemet vil opføre sig når mange brugere begynder at bruge systemet. Der er lavet automatiserede test for dele af systemet, og disse har fungerede godt når det har været svært at gennemskue PSI.

47 47 Kapitel 5 Resumé I dette afsnit vil jeg gennemgå hvad der ikke har været tid til at implementere, og vigtigheden af disse elementer. Jeg vil komme ind på hvorfor jeg har valgt at gemme disse til sidst i projektet, og hvor meget det kraver at implementere disse elementer. Mangler og fremtid Selvom jeg har fået implementeret de fleste use cases, er der stadig et par ting som ikke er kommet med. Hovedårsagen til dette er at der ikke har været tid til at implementere dem, hvis jeg havde haft mere tid var det også disse mangler jeg var gået i gang med. Der mangler stadig at blive implementeret to use cases, så det første der skal laves på systemet er disse to use cases. Dette drejer sig om use case Udskift ressource og Installation. Udskift ressource skulle være rimelig hurtig at implementere, da jeg allerede har lavet funktioner til at indsætte og fjerne ressourcer. Installation I det færdige system skal der være en installationspakke så det er nemt at installere og opsætte programmet, i forbindelse med dette skal der også oprettes et brugerdefineret felt ved navn tilstand på PWA. Der skal også oprettes en side i PWA hvor selve webparten skal ligge på. Når der bliver lavet en installation, skal det også være muligt for system administratoren at ændrer indstillingerne i programmet. Dermed skal indstillingerne kunne loades fra en fil det ligger et sted hvor alle brugere har ret til at se den. Dette er nødvendigt fordi man ikke kan vide om den bruger der kalder webparten har ret til at se serverens filsystem. Der er ikke lavet nogen installations pakke til programmet endnu, da systemet ikke er helt færdigudviklet og det er lettest at lave installationspakken når man kender alle de elementer der skal installeres. Optimering Når systemet køer er der enkelte funktioner der tager lang tid, systemet er kun blevet testet på en vituel server. Dette betyder at jeg ikke ved hvor lang tid det tager at udfører disse handlinger på en rigtig server, og derfor ikke har kunne tage stilling til om systemet kører kritisk langsomt. En del af optimeringen kunne klares ved at cache data som det er beskrevet i implementerings afsnittet. Stress test Som det er nævnt i Test afsnittet er systemet heller ikke blevet stress testet endnu, dette er en kritisk ting da der hurtigt kan være nogle fejl der ikke før har været synlige. Stress test kan først udføres når værktøjerne bliver ledige, og jeg regner med at kunne udfører stress test af systemet inden for et par uger. Delkonklusion I det hele er der stadig et par småting som stadig mangler at blive implementeret. Disse ting er ikke kritisk for udviklingen af systemet, men de skal være med før PRM kan udgives til slutbrugeren. Det jeg finder

48 48 mest kritisk er nok stress test. Hvis programmet viser sig at kører for langsomt på en hardware server, så er det også meget kritisk at få optimeret systemet. Umiddelbart vil det ikke tage særlig lang tid at implementere de sidste elementer da meget af funktionaliteten allerede eksistere. For installationen har jeg allerede en metode til at sætte programmet op på serveren, jeg mangler bare at automatisere denne. Konklusion Jeg har fået udviklet størstedelen af et system til at håndtere ressource styring af projekter, og de mangler der er, kan forholdsvis hurtigt udbedres. Implementeringen har skabt en del problemer på grund af de mange teknologier der er brugt i projektet, men dette var der også fokus på fra begyndelsen. Systemudviklingsmetoden extreme Programming skulle afhjælpe problemerne med de mange ukendte teknologier og der har kun været meget få steder hvor den har fejlet. UML er gennem hele udviklingsperioden blevet brugt til at dokumentere udviklingen, og denne har fungerede godt sammen med extreme Programming udviklingsmetoden. Det har også taget en del tid at forstå den interne opbygning af Project Server og PSI, fordi der var meget lidt eller manglende dokumentation. Den manglende dokumentation er nu dokumenteret i denne rapport.

49 49 Forkortelser & Definitioner Projectum - Virksomheden jeg skriver eksamensprojekt i. PRM - Project Resource Maneger, det system der er blevet udviklet i forbindelse med denne repport. WSS - Windows Sharepoint Services MOSS - Microsoft Office Sharepoint Services PWA - Project Web Access PSI - Project Server Interface. (Interface til at lave 3 parts programmer til Project Server). MS - MicroSoft Sharepoint - ASP.Net program der indbygger funktionalitet til at håndtere intranet, og kendte Microsoft standarter som f.eks. MS Word og MS Excel. IIS - Internet Information Services. Samling af internet services. Webpart - En ASP.Net program der kører I Sharepoint. Ressource - En person, en maskine, eller et materiale der er kan bruges på et projekt. Project Manageren - Den person der opretter og foreslår projekter. Generic Resources - Ressourcer der beskriver et arbejdsområde og ikke en egentlig ressource. Ressource Maneger - Den Person der håndtere ressourcerne. Project Server - integrationen af PWA og MS Project. UP - Unified Process. XP - extreme Programming, system udviklings metode. UML - Unified Modeling Langauge. Load Factoren - Et tal der beskriver afvigelser fra estimeringen af en opgave. WSS & PWA server - Når en URL til PWA angives, bliver den skrevet på formen default.aspxx, her skal det forestås at SERVER er navnet på severen (eller host hedderen) og PWA er navnet på PWA siden. På min test server var dette angivet som hvor navnet på test serveren var s-training-ps2, min sharepoint side kørte på port Og PWA siden hed PWA2. Ressource siden - Den side hvor man administrere ressourcer, ( CSS - Cascading Style Sheets. HTML - HyperText Markup Language Ressource siden - Den side der fremkommer når man klikker på Ressourcer fra PWA s startside. Ressource belastnings siden Side der viser hvor meget en given ressource er balastet i en tidsperiode. UID - Unique IDentifier URL - Uniform Resource Locator. XML fil - Fil der indeholder data efter W3 s XML standarter. Batch fil - Batch Script fil til Windows.

50 .Net - Microsofts virtuelle maskine, som C# og ASP kører på. IE - Referere til Microsoft Internet Explorer 7 og 8. UI - User Interface, brugergrænseflade. MVP - Model View Presenter design mønster. RBS - Resource Breakdown Structure. 50

51 51 Literature [McConnell] McConnell, Steve Rapid Development: Taming Wild Software Schedules. Microsoft Press. (1996) ISBN: [XP web] [wikipedia use case] [Google] [Komodia] [PSI Doc] [Inside WSS] Larson, Daniel & Pattison, Ted Inside Microsoft Windows Sharepoint Services 3.0. Microsoft Press. (2007) ISBN: [Dis#] [MS Project Server] Gochberg, Dave & Stewart, Rob The Complete Reference - Microsoft Office Project Server 2007: McGraw-Hill. (2007) ISBN: [XP] Steinberg, Daniel & Palmer, Daniel Extreme Software Engineering - A hands on approach: Person Prentice Hall. (2004) ISBN: [UML & UP] Neustadt, Arlow UML and the Unified Process: Addison Wesley. (2002)

52 ISBN:

53 53 Bilag

54 54 Bilag 1 Use Cases Navn Indsætte Tilstand Version 1.0 Mål Indsætte et costum field med navnet Tilstand. Trigger Systemet bliver installeret. Aktorer System administrator Preconditions Sharepoint services og PWA er installeret. Hændelses Tilføj costum field med navnet Tilstand forløb Alternative Adgang nægtet forløb Postconditions Costum field Tilstand er blevet indsat. Noter Forfatter CHF Navn Projekt tilstand Version 1.0 Mål Udskifte projektets tilstand felt. Trigger Projektets tilstand har fysisk ændrede sig. Aktorer Ressource maneger Preconditions Der eksisterer minimum et projekt i systemet. Projektets status er ikke afvist Hændelses forløb Vælger den nye tilstand på projektet. Klikker på Gem knappen. Projektets tilstand bliver ændret til det valgte. Alternative Brugeren får besked om at projektets tilstand ikke kan ændres forløb Postconditions Projektets tilstand er blevet ændret. Noter Forfatter CHF Navn Tilføje ressource Version 1.0 Mål Tilføje en ressource fra enterprise ressourcerne til et givent projekt. Trigger En ressource der ikke er i projektet skal tilføjes til en opgave Aktorer Ressource maneger Preconditions Der eksisterer minimum et projekt i systemet. Hændelses forløb Vælger den ressource der skal tilføjes. Klikker på Tilføj ressource knappen ud for det projekt ressourcen skal tilføjes til. Ressourcen bliver tilføjet til projektet. Alternative

55 55 forløb Postconditions Noter Forfatter En ressource fra enterprise ressourcerne er blevet tilføjet til projektet. CHF Navn Fjerne ressourcer Version 1.0 Mål Fjerne en ressource et givent projekt. Trigger Der er overskydende ressourcer på projektet Aktorer Ressource maneger Preconditions Der eksisterer minimum et projekt i systemet. Der er minimum en ressource på dette projekt. Hændelses forløb Alternative forløb Postconditions Noter Forfatter Vælger den ressource der skal fjernes. Klikker på Fjern ressource knappen ud for det projekt ressourcen skal fjernes fra. Ressourcen bliver fjernet fra projektet. En ressource fra enterprise ressourcerne er blevet tilføjet til projektet. CHF Navn Udskifte ressourcer Version 1.0 Mål Udskifte en ressource på et givent projekt til en anden ressource fra enterprise resource. Trigger Forkerte ressourcer er tildelt en opgave. Aktorer Ressource maneger Preconditions Der eksisterer minimum et projekt i systemet. Der er minimum en ressource på dette projekt. Minimum en opgave er tildelt den ressource der skal udskiftes. Hændelses forløb Alternative forløb Postconditions Noter Forfatter Vælger den ressource der skal udskiftes på projektet. Vælger den ressource der skal udskiftes i enterprise ressourcer. Klikker på Udskift ressource knappen ud for det projekt ressourcen skal udskiftes fra. Ressourcen bliver udskiftet med den nye resource. En ny ressource fra enterprise ressourcerne er blevet tilføjet til projektet. En ressource er blevet fjernet fra projektet. Ressourcen der bliver udskiftet til må godt ligge i projektet i forvejen. CHF

56 56 Navn Ændre valgte ressource Version 1.0 Mål Ændre hvilken ressource der er tildelt til en given opgave. Trigger Forkerte ressourcer er tildelt en opgave. Aktorer Ressource maneger Preconditions Der eksisterer minimum et projekt i systemet. Der er minimum to ressourcer på dette projekt. Minimum en opgave er tildelt en ressource. Hændelses forløb Alternative forløb Postconditions Noter Forfatter Fra drop down liste vælges den ressource der skal tildeles til opgaven. Klikker på Gem knappen. Opgavens ressource tildeling bliver udskriftet med den nye ressourcen. En mail sendes til projektlederen om at udskiftningen er sket. Opgavens ressource tildeling er blevet udskriftet med en anden ressource. CHF Navn Ressource status Version 1.0 Mål Udskifte en ressources status Trigger Ressource manageren har gennemgået projektet og her undersøgt at han godt kan undvære ressourcen i den pågældende periode. Aktorer Ressource manager Preconditions Der eksisterer minimum et projekt i systemet. Der er minimum en ressource på dette projekt. Minimum en opgave er tildelt en ressource. Ressourcens status er i øjeblikket Proposed Hændelses Fra drop down liste vælges den status ressourcen forløb skal have. Klikker på Gem knappen. Den nye status bliver gemt på opgaven i systemet. En mail sendes til projekt lederen om at ændringen Alternative forløb er fundet sted.6 Adgang nægtet Ressourcens status er allerede Committed Brugeren får en besked om at man ikke kan ændre en ressources status fra Commited til Proposed. Postconditions Costum field Tilstand er blevet indsat.

57 57 Noter Forfatter Der skal ikke sendes mail til ressourcen. CHF Navn Vise projekter Version 1.0 Mål Vis en html side i Sharepoint med projekter, opgaver, ressourcer og enterprise ressourcer. Trigger Brugeren har brug for at se tildelinger mellem opgaver og ressourcer. Aktorer Ressource maneger Preconditions Der eksisterer minimum et projekt i systemet. Ikke et direkte krav, men ellers har webparten ikke noget at vise. (Webparten skal ikke vise fejl hvis der ikke er nogen projekter). Hændelses Fra Sharepoint klikkes der på linket til siden og siden loades. forløb Alternative forløb Postconditions Der vises en side hvor projekter, opgaver på projekter og deres tilhørende ressourcer er stillet op så man kan se hvilke opgaver, ressourcer og projekter der hører sammen. En liste med enterprise ressourcer vises. Noter Både ressourcerne og enterprise ressourcerne skal have vist deres RBS værdier. Forfatter CHF Navn Vise ressource belastning Version 1.0 Mål Når der klikkes på en ressource skal der linkes til en side der viser belastningen af ressourcen grafisk. Trigger Brugeren har brug for at se belastningen af ressourcen. Aktorer Ressource maneger Preconditions Der eksisterer minimum et projekt i systemet. Der eksistere minimum en enterprise ressource. Hændelses Fra PRM klikkes der på ressourcen og siden loades. forløb Alternative forløb Postconditions Ændringer i PRM bibeholdes, dette kan enten opnås ved hjælp af ASP.Net Viewstate eller ved at linket åbnes i et nyt vindue. Noter Det er tiltænkt at man udnytter den allerede eksisterende visning af ressourcerne som kan findes på PWA siden: /PWA/_layouts/PWA/RM/ResAvailability.aspx

58 58 Se evt. Figur b1. Forfatter CHF Figur b1

59 59 Bilag 2 Projekt oplæg Følgende er den officielle projekt beskrivelse der er udleveret af Carsten Nilsson fra Projectum, dette er et udkast til systemet som de havde tænkt sig det skulle se ud. Dette oplæg er lavet før projektets start og er ikke blevet revideret løbende, derfor ser det egentlige system noget anderledes end det er beskrevet her. Ressource Request Beskrivelse I Project Server findes navngivne og generiske ressourcer, der hver især tjener deres formål. Generiske ressourcer anvendes til at forecaste opgaver i fremtiden men også til at en projektleder kan foreslå nye opgaver i relation til et projekt, men hvor afdelingslederen kan ind i et forløb, hvor ressource trækket dels godkendes og hvor der dels gives forslag til den navngivne ressource der må anvendes. Navngivne ressourcer er medarbejdere, der kan udføre opgaven i praksis. Projektlederen allokerer fra Project Professional en generisk ressource, der angives med status proposed. Projektet omhandler afdelingslederens godkendelse, hvor denne fra en web part i oprettet i Windows Sharepoint Services, som vi kalder Ressource Request. På siden skal denne kunne opnå overblik over ressource anmodningerne (i hans afdeling) og dels kan agere på disse ved at opnå overblik over andre bookinger på sine ressourcer og dels kan erstatte den generiske ressource med en passende navngiven ressource. Omdrejningspunktet er en liste der viser projekt, projektejer, ressource anmodning, belastning og tidsinterval på generiske ressourcer, der er angivet som proposed. Ressource anmodningen skal kunne skiftes til Committed og den navngivne ressource skal kunne udskiftes. Overblikket over eksisterende opgavetildelinger og belastninger eksistere allerede og fra ressource anmodnings linien skal det være muligt at komme videre til disse visninger. Systemet skal ved ændring/godkendelse af ressourceanmodningen sende en mail til projektlederen (project owner) om at godkendelse/erstatning er sket. Det kræver en undersøgelse om det vil være muligt, at indstille Ressource Center visningerne med oplysninger om den efterspurgte ressource. Når en ressource anmodning er udført skal listen kunne opdateres, så ressource anmodningen forsvinder fra visningen. Det ses ikke som et behov, at der kan ske udskiftninger af navngivne ressource i Ressource Request siden, da man med en lille indsats i Project Professional kan erstatte allokeringer på navngivne ressourcer til generiske med mærkatet Proposed og derved aktivere visningen. Men projektet skal beskrive, hvorledes dette kan etableres til senere udvidelse.

60 60 Projektbindinger: Dannes som web part, der kommunikerer med PSI Listen skal virke ud fra matchning af ressourcer via RBS Layout skal ligne det øvrige PWA interface i standard opsætning Der skal tages højde for at projekter kan være checket ud, at de kan være dannet som proposals, at ressource kan være checket ud.

61 Bilag 3 Klasse Diagram 61