Dokument- og Sagsstyringssystem

Transkript

1 Dokument- og Sagsstyringssystem Mads Nissen Kongens Lyngby 2010 IMM-B.Eng

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

3 Abstract / Resumé Dette projekt er udført fordi IMM ønsker et Dokument- og Sagsstyringssystem der kan lette administration af studerendes praktikophold og eksamensprojekter. Den nuværende administration af praktik og eksamensprojekter foregår ved brug af Campusnet, der ikke er beregnet til denne administration. Dette resulterer i at administrationen ofte er langt mere besværlig end den ville være i et målrettet system. Projektet er udført efter en Unified Process model, hvor der har været fokus på use cases og iterativ udvikling. Der er anvendt udvalgte UML artefakter til at modellere systemet. Det udviklede system er implementeret som en Java webapplikation baseret på Apache Wicket. Det anvender en relationel model der er implementeret i en MySQL database og ORM frameworket Hibernate anvendes for at lette datatilgang til databasen fra webapplikationen. Det udviklede system opfylder de funktionelle krav for kerne-områderne i det ønskede system. Ikke alle use cases er integreret inden for projektets rammer, men systemets opbygning og dokumentation gør det nemt at fortsætte arbejdet. 3

4 Bilag Alle bilag er placeret på den vedlagte CD. CD en indeholder følgende bilag: Denne rapport som pdf-fil (Rapport.pdf) Applikationens kildekode m.v. (DSS mappe) Fil med MySQL kommandoer til oprettelse af relationel database (dbscripts.sql) Pakke til lokal afvikling af webapplikationen (dss.zip) Vejledning til lokal afvikling af webapplikationen (Vejledning.pdf) Program der unzipper dss.zip væsentligt hurtigere end windows std. (7-ZipPortable mappe) 4

5 Indhold 1 Indledning Afgrænsning Sprogbrug / ordvalg Inception Indledning Vision Use cases Use case diagram Aktører Oversigt over use cases Use case beskrivelser FURPS Risikoanalyse Analyse-dokument Detaljerede use cases Fælles for alle Studerende Praktikassistent Praktikkoordinator DTU Vejleder Fælles for Praktikassistent og Praktikkoordinator Fælles for Praktikassistent, Praktikkoordinator og DTU Vejleder Test cases Løsningsstrategi Domænemodel Design-dokument Package-diagram Designovervejelser Fildeling Status Standard dokumenter / Bruger dokumenter Find studerende Datamodellering

6 6.1 Designovervejelser Fildeling Forms Standard dokumenter Bruger dokumenter Registrering Tilknyt vejleder Status Begrebsmæssigt databasedesign Logisk databasedesign Mapping Normalisering Relationel model Constraints Systemarkitektur Design Patterns Lag-deling Implementering Generelt Apache Wicket Hibernate Test Strategi for test Udførelse af test Resultat af test Evaluering og konklusion Evaluering af proces Konklusion på system Integration af resterende use cases Mulige forbedringer Konklusion på projekt

7 Figurer Figur 1: Use case diagram, del Figur 2: Use case diagram, del Figur 3: Iterationsplan Figur 4: Domænemodel Figur 5: Package-diagram Figur 6: Entity Relation Diagram Figur 7: Lag-deling Figur 8: Eksempel - ModalWindow Tabeller Tabel 1: Use case - Registrer studerende Tabel 2: Use case - Behandl registrering Tabel 3: Use case - Opdater form data Tabel 4: Use case - Godkendelse af praktikplads Tabel 5: Use case - Godkend praktikvirksomhed Tabel 6: Use case - Upload standard dokument Tabel 7: Risici ved projektet Tabel 8: Detaljeret use case - Registrer studerende Tabel 9: Detaljeret use case - Opdater form data Tabel 10: Detaljeret use case - Behandl registrering Tabel 11: Detaljeret use case - Godkend praktikvirksomhed Tabel 12: Test case - Registrer studerende Tabel 13: Test case - Behandl registrering Tabel 14: Test case - Opdater form data Tabel 15: Test case - Godkend praktikvirksomhed

8 1 Indledning Dette projekt omhandler udviklingen af et Dokument- og Sagsstyringssystem til IMM, der ønsker en webportal til administration af studerendes praktikophold og eksamensprojekter. Til at styre udviklingsprocessen anvendes Unified Process, hvor projektarbejdet inddeles i iterationer og use cases er et centralt element. Ud over at anvende use cases til at beskrive systemets funktionelle krav, benyttes udvalgte UML artefakter til at modellere systemet. I projektet lægges størst vægt på analyse og design af systemets funktioner samt på datamodellering. Det ønskede system implementeres som en Java Webapplikation baseret på Apache Wicket. Denne rapport beskriver systemets overordnede rammer og krav, analyserer de funktionelle krav, indeholder en domænemodel for systemet, viser implementeringens overordnede struktur i et package-diagram og datamodel i et ER diagram. Desuden gøres der rede for de overvejelser der ligger bag designet, lige som der gennemgås relevante detaljer omkring implentationen. Endelig beskriver rapporten også hvordan de funktionelle krav til systemet er testet. 2 Afgrænsning Det system der udvikles er tænkt at skulle integreres med DTU s SSO, så authentication af brugere kan håndteres af SSO. Denne integration er dog uden for projektets scope, hvorfor det ikke vil være nogen egentlig authentication i applikationen - kun en dummy-udgave. I inceptionsdokumentet bestemmes krav til systemet i form af use cases. Det er dog ikke alle disse use cases der bliver arbejdet med inden for projektets tidsgrænse. Der vil i projektet ikke blive brugt mange resourcer på de æstetiske dele af webapplikationen. 2.1 Sprogbrug / ordvalg Her er listet en række sammenhænge der er væsentlige at huske for forståelsen af resten af rapporten: DSS Forkortelse af Dokument- og SagsstyringsSystem. Navnet på projektet og systemet. Registrering / ansøgning Er de oplysninger de studerende angiver for at blive optaget i systemet. Begge ord anvendes med samme betydning. SSO Forkortelse af Single-Sign-On. Std. dok. Forkortelse af Standard dokument. Dækker over filer der ofte benyttes i forbindelse med en studerendes sag, men hvis indhold ikke administreres af systemet. Sag Én sag hører til én studerende og omhandler administration, meddelelser og aktiviteter i forbindelse med praktik og eksamensprojekt. 8

9 3 Inception Dette afsnit beskriver det system der udvikles samt de krav der stilles. Systemet beskrives blandt andet ved et use case diagram og en gennemgang af de vigtigste use cases. 3.1 Indledning Formål Formålet med Inceptions-dokumentet er at indføre målgruppen i systemets omfang og de funktionelle krav der er opstillet for systemet. Derudover er det meningen at fremstille use cases der benyttes ved udviklingen af systemet. Målgruppe Målgruppen for dette dokument er IMM s praktikkoordinatorer, der har bestilt systemet beskrevet i afsnit 3.3. Projektmedlemmer Projektet er udarbejdet af: Mads Nissen, s Referencer Inceptionsdokumentet har ingen eksterne referencer. 3.2 Vision Institut for Matematisk Modellering på DTU har hvert semester studerende der er i ingeniørpraktik eller skriver eksamensprojekt. Til administration af de studerende, deres praktikpladser og deres eksamensprojekter, anvendes Campusnet, delte filer og andre systemer på DTU. Denne administration er beskrevet i en række business cases. De personer der står for denne administration ønsker at optimere processen 1 med en ny webapplikation. En målrettet applikation vil både betyde mindre manuelt arbejde og simplere business cases. Det er tanken at man med den nye applikation helt skal slippe for at anvende flere af de systemer og metoder der anvendes i dag, samt at der kan automatiseres en masse opgaver. Applikationens hovedpunkter ud fra kundens synspunkt: System der er simplere at anvende - både for studerende og ansatte Reducering af manuelt arbejde Simplere business cases Mindre risiko for fejl Mindre tidskrævende administration Det er bestemt at systemet opbygges som en web-applikation baseret på Java. 1 Med processen menes der det samlede arbejde for både ansatte og studerende, fra den studerende søger om optagelse i praktik-systemet til eksamensprojekt afsluttes. 9

10 System der er simplere at anvende Som processen er nu, skal både studerende og ansatte huske en del retningslinier for hvordan administration og kommunikation skal foregå. Desuden anvendes flere forskellige systemer til forskellige dele af processen. Et målrettet system vil kunne gøre denne proces enklere ved at reducere og forsimple retningslinier. Input-validering, fejlmeddelelser og bedre muligheder for at beskrive hvordan systemet skal anvendes vil hjælpe med til at give et system der er simplere at lære og simplere at anvende for både ansatte og studerende. Desuden kan flere af de opgaver der udføres i andre systemer nu, kombineres i det nye system, så processen kan udføres ved færre systemer totalt. Reducering af manuelt arbejde Da der til processen anvendes systemer der ikke er beregnet hertil, indebærer administrationen af praktik og eksamensprojekter en masse manuelt arbejde for alle parter. En stor del af dette manuelle arbejde kan sagtens undgås med et målrettet system. Simplere business cases De business cases der anvendes nu er temmelig volumiøse. Det er derfor tidskrævende både at udføre dem samt at vedligeholde dem. Et målrettet system vil betyde at business cases kan forsimples flere steder. Mindre risiko for fejl Et målrettet system kan foretage input-validering, samt have bedre mulighed for at beskrive hvordan systemet skal anvendes. Dette vil hjælpe med til at minimere risikoen for fejl i processen. Mindre tidskrævende administration De ovenstående punkter vil betyde at hele processen bliver mindre tidskrævende for alle parter. 3.3 Use cases Use cases bruges i stedet for en kravspecifikation og beskriver de handlinger der skal være mulige i systemet. De er ofte meget mere brugbare til at få afdækket brugernes reelle behov, frem for en stor liste af krav. Desuden kan de give en udvikler indsigt i hvilke funktionaliteter der er nødvendige og give denne mulighed at foreslå alternative løsninger som dækker samme behov. 10

11 3.3.1 Use case diagram Figur 1: Use case diagram, del 1 11

12 Figur 2: Use case diagram, del 2 12

13 3.3.2 Aktører Studerende Benytter systemet til at give relevante oplysninger om sig selv, praktikvirksomhed og eksamensprojekt til de øvrige aktører. Anvender desuden systemet til at kommunikere med de øvrige aktører. Der er mange af disse aktører. Praktikassistent Benytter systemet til at hente oplysninger om de studerende og til at administrere deres sager. Anvender desuden systemet til at kommunikere med studerende. Der er typisk én af disse aktører. Praktikkoordinator Benytter systemet til at hente oplysninger om de studerende samt til at administrere sager og godkendelser. Anvender desuden systemet til at kommunikere med studerende. Der er typisk to at disse aktører. DTU Vejleder Benytter systemet til at kommunikere med studerende om deres eksamensprojekt, samt til at hente informationer herom. Antallet af disse aktører kan variere Oversigt over use cases Fælles for alle aktører o (Login) Alle aktører foretager login med DTU s SSO. o (Udsend meddelelse) Udsend meddelelse tilknyttet en sag. o (Se mine meddelelser) Se alle meddelelser for sager brugeren er tilknyttet. o (Se vejledningsdokumenter) Se dokumentation om hvordan systemet skal bruges. o (Udskriv) Få udskrevet informationer og dokumenter. Studerende o (Registrer studerende) Studerende kan udfylde registreringsformular for at søge om optagelse i systemet. o (Opdater form) Der er mulighed for at udfylde og opdatere formularer i systemet. o (Upload std. dok.) Standard dokumenter der ikke kan laves med formularer kan uploades. o (Upload fil) Ikke-standard dokumenter kan uploades til fildeling. o (Godkendelse af praktikplads) Tilkendegiv at praktikplads er fundet og indtastet i systemet. o (Godkendelse af foreløbigt abstract) Tilkendegiv at foreløbigt abstract er udfyldt. o (Godkendelse af praktik) Anmod om godkendelse af praktik på baggrund af informationer i systemet. o (Godkendelse af abstract) Anmod om endelig godkendelse af abstract til eksamensprojekt. Praktikassistent o (Behandl registrering) Godkend indkomne anmodninger om optagelse i systemet. o (Behandl færdigt abstract) Tilknyt projektets løbenummer til sag. Praktikkoordinator o (Godkend praktikvirksomhed) Godkend praktikvirksomhed på baggrund af informationer i systemet. 13

14 o (Godkend foreløbigt abstract) Godkend foreløbigt abstract på baggrund af informationer i systemet. o (Godkend praktik) Godkend praktik på baggrund af informationer i systemet. DTU Vejleder o (Se mine studerende) En vejleder kan få listet alle studerende vedkommende er vejleder for. o (Søg mine studerende) En vejleder kan foretage søgninger efter studerende vedkommende er vejleder for. Fælles for Praktikassistent og Praktikkoordinator o (Se alle studerende) Få listet alle studerende i systemet. o (Søg alle studerende) Søg efter alle studerende i systemet. o (Tilknyt DTU Vejleder) Tilknyt en DTU Vejleder til den studerendes sag. o (Fjern DTU Vejleder) Fjern en tilknyttet DTU Vejleder fra en sag. o (Ændr status for studerende) Skift en studerendes status i systemet. o (Opret / rediger ansat) Opret eller rediger data på en ansat og tildel rolle(r). o (Slet ansat) Slet en ansat fra systemet. o (Opret / rediger form) Opret og bestem indholdet af de forms studerende anvender. o (Slet form) Fjern en form der ikke længere bruges. o (Skjul / vis form for studerende) Skjul en form for studerende uden at slette den. o (Opret / rediger std. dok.) Opret og bestem indholdet af de std. dok. studerende benytter. o (Slet std. dok.) Fjern std. doks. der ikke længere bruges. Fælles for Praktikassistent, Praktikkoordinator og DTU Vejleder o (Se studerendes forms) Se data de studerende har udfyldt forms med. o (Se studerendes std. doks.) Se filer studerende har uploadet under std. doks. o (Se studerendes fildeling) Se de filer studerende har uploadet under fildeling. o (Se studerendes meddelelser) Se meddelelser der er tilknyttet en studerendes sag Use case beskrivelser Følgende er beskrivelser af de use cases der vurderes at være kritiske for systemet. Det er disse use cases der vil blive arbejdet med først for at sikre at de ikke giver problemer der kan have betydning for projektes succes. Design og implementering af disse vil samtidig betyde at størsteparten af systemarkitekturen vil blive konstrueret. 14

15 Use case Registrer studerende. Aktør Studerende. Formål At registrere relevante oplysninger om studerende der ønsker optagelse i systemet. Oversigt Når en studerende skal i praktik næste semester indtastes relevante oplysninger i systemet. Når oplysningerne er gemt i systemet gives der besked til praktikassistenten om dette. Prækondition Den studerende har logget ind med SSO og er ikke registreret i systemet. Postkondition Systemet har godkendt og gemt oplysninger og har underrettet praktikassistenten herom. Frekvens Der registreres op til 50 studerende om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Ansøgning. 2) Systemet viser en formular til indtastning af oplysninger. 3) Der indtastes relevant data. 4) Der klikkes på Send. 5) Systemet validerer og gemmer data. 6) Systemet sender besked til praktikassistenten om ansøgningen. Tabel 1: Use case - Registrer studerende 15

16 Use case Behandl registrering. Aktør Praktikassistent. Formål At godkende en registrering og give en studerende adgang til systemet. Oversigt Når praktikassistenten modtager en besked om en ny registrering skal den behandles og godkendes, hvis alt er i orden. Prækondition Praktikassistenten har logget ind med SSO og der er en ny registrering. Postkondition Systemet har accepteret godkendelsen og underrettet den studerende herom. Frekvens Der godkendes op til 50 registreringer om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Anmodninger. 2) Systemet viser en liste over alle anmodninger. 3) Der klikkes på den studerende hvis registrering skal behandles. 5) Der klikkes på Ansøgning. 7) Der klikkes på Tilbage. 9) Der klikkes på Godkend. 4) Systemet viser en liste med muligheder for den studerendes sag. 6) Systemet viser den studerendes ansøgning. 8) Systemet viser igen listen med muligheder for den studerendes sag. 10) Systemet registrerer at ansøgningen er godkendt. 11) Systemet sender besked til den studerende om godkendelsen. Tabel 2: Use case - Behandl registrering 16

17 Use case Opdater form data. Aktør Studerende. Formål At udfylde / opdatere en formular i systemet med relevant data. Oversigt Den studerende er selv ansvarlig for at udfylde formularer med påkrævet data. Formularens felter udfyldes hvorefter data gemmes i systemet. Prækondition Den studerende er logget ind med SSO. Postkondition Systemet har godkendt og gemt oplysninger. Frekvens Der opdateres op til 50 formularer om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Forms. 2) Systemet viser tilgængelige forms. 3) Der klikkes på den form der skal udfyldes. 4) Systemet viser formularen. 5) Der indtastes relevant data. 6) Der klikkes på Gem. 7) Systemet validerer og gemmer data. Tabel 3: Use case - Opdater form data Use case Godkendelse af praktikplads. Aktør Studerende. Formål At registrere at informationerne om den studerendes praktikplads er klar til at blive godkendt. Oversigt Når en studerende har fundet en praktikplads skal denne godkendes. Den studerende tilkendegiver dette i systemet der sørger for at give besked til praktikkoordinator. Prækondition Den studerende har logget ind med SSO og har opdateret påkrævet data om praktik. Postkondition Systemet har accepteret meldingen og underrettet praktikkoordinator herom. Frekvens Der meldes op til 50 fundne praktikpladser om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Meld: Praktikplads fundet. 2) Systemet registrerer dette. 3) Systemet sender besked til praktikkoordinator om ny praktikvirksomhed. Tabel 4: Use case - Godkendelse af praktikplads 17

18 Use case Godkend praktikvirksomhed. Aktør Praktikkoordinator. Formål At godkende oplysninger om en studerendes praktik. Oversigt Når praktikkoordinatoren modtager en besked om en ny praktikvirksomhed, skal denne virksomhed godkendes. Prækondition Praktikkoordinatoren har logget ind med SSO og der findes en ny praktikvirksomhed. Postkondition Systemet har registreret at virksomheden er accepteret og underrettet den studerende herom. Frekvens Der godkendes op til 50 virksomheder om dagen i peaks, men eller under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Anmodninger. 2) Systemet viser en liste over alle anmodninger. 3) Der klikkes på den studerende hvis praktikvirksomhed skal behandles. 5) Der navigeres til de data der beskriver praktikvirksomheden. 7) Der klikkes på Tilbage. 9) Der klikkes på Godkend. 4) Systemet viser en liste med muligheder for den studerendes sag. 6) Systemet viser den studerendes data. 8) Systemet viser igen listen med muligheder for den studerendes sag. 10) Systemet registrerer at praktikvirksomheden er godkendt. 11) Systemet sender besked til den studerende om godkendelsen. Tabel 5: Use case - Godkend praktikvirksomhed 18

19 Use case Upload standard dokument. Aktør Studerende. Formål At uploade et standard dokument i systemet. Oversigt Nogle data kan ikke holdes i formularer i systemet, men uploades i stedet som filer. Prækondition Den studerende har logget ind med SSO. Postkondition Systemet har gemt filen. Frekvens Der uploades op til 50 standard dokumenter om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Dokumenter. 2) Systemet viser tilgængelige standard dokumenter. 3) Der klikkes på det standard dokument der skal uploades en ny fil til. 5) Der klikkes på Upload ny fil. 4) Systemet viser muligheder for anvendelse af standard dokumentet. 6) Systemet viser form til fil-upload. 7) Den fil der skal uploades vælges i formularen. 8) Der klikkes på Gem. 9) Systemet gemmer filen. Tabel 6: Use case - Upload standard dokument 3.4 FURPS+ FURPS+ modellen benyttes til at beskrive de krav der stilles til systemet, som ikke fremgår af use cases. Functional Systemet skal tilgåes via et web-interface. Alle brugere af systemet skal identificere sig ved login inden systemet kan anvendes. Systemet skal kunne give en grafisk repræsentation af studerendes forløb. Systemet skal kunne udsende s ved forskellige hændelser. Usability Web-interfacet skal opbygges så systemet bliver simpelt og intuitivt at anvende. Det skal være nemt at få oplysninger om hvordan systemet kan/skal bruges. Det skal være muligt at benytte de fleste af systemets funktioner med få muse-klik og tastetryk. Reliability Da systemet ikke vil være i brug alle 24 timer i døgnet kan mindre nedetider tolereres, så længe det ikke er noget der sker for ofte. Hvis kun en enkelt web-server og database-server 19

20 anvendes er single-point-of-failure et problem. Ved nedbrud på en af serverne vil systemet være helt utilgængeligt. Længerevarende nedbrud kan ikke tolereres, så for at undgå dette skal en backupløsning findes. Det kan være en spejlet server der kan overtage automatisk, eller manuelt kan startes når det er nødvendigt. Performance Da systemet aldrig vil være tungt belastet af mange samtidige opgaver, er det rimeligt at kræve en hurtig respons-tid når systemet anvendes. Når en bruger sender en anmodning til systemet, skal denne behandles og et svar sendes tilbage, så brugeren har kortest mulig ventetid. For at opnå dette vil web-interfacet ikke indeholde en masse tung grafik. Brugen af database i systemet skal også foregå på en effektiv måde. Ved tidskrævende operationer kan Ajax anvendes for at mindske generne for brugeren. Supportability Administration af brugere og rettigheder kan udføres af praktikassistent og praktikkordinator. Det er også disse brugere der vedligeholder sager og opbygning af formularer. Systemet kan sættes op til automatisk at slette data der findes irrelevant efter en årrække. Yderligere vedligeholdelse og konfigurering foretages af en udvikler. Implementation Systemet opbygges som en Java web-applikation, og implementeringen vil bygge på et framework der hedder Apache Wicket. Databasen vil blive implementeret som en relationel database på en MySQL-server. Til at lette implementeringen af applikationens datatilgang anvendes desuden et ORM framework der hedder Hibernate. Interface Login via DTU s SSO foretages og er begrænset af et eksternt system. Packaging Der vil være en web-server til afvikling af web-applikationen, samt en database-server til håndtering af data. Legal Systemet udvikles til DTU. Alle rettigheder indehaves af DTU. 20

21 3.5 Risikoanalyse Her er beskrevet en række risici der kan få indflydelse på projektplanen. For hver problemstilling er risikoen beskrevet efter følgende skema: Sandsynlighed Konsekvens Faktor 10. Høj sandsynlighed 10. Stor konsekvens Sandsynlighed * Konsekvens 6. Mellem sandsynlighed 3. Mellem konsekvens 3. Lav sandsynlighed 1. Lille konsekvens 1. Meget lav sandsynlighed Ændring af kravspecifikation Sandsynligheden for at denne problemstilling bliver aktuel vurderes til 3, og konsekvensen også til 3. Problemet er altså en faktor 9. Konsekvens: Afhængig af ændringens størrelse kan det blive nødvendigt at gå tilbage i projektet for at tage højde for ændringerne. Kommer ændringerne på et sent tidspunkt kan det gå ud over kvaliteten. Forholdsregler: Det forsøges at sikre at alle krav er kendt, beskrevet og godkendt. Hvis det sker: Vurder hvilket omfang ændringen vil have på projektet. Tilpas tidsplan og revider ressourcefordeling. Deadline kan ikke overholdes Sandsynligheden for at denne problemstilling bliver aktuel vurderes til 3, og konsekvensen også til 3. Problemet er altså en faktor 9. Konsekvens: Overskridelse af deadlines / lavere kvalitet. Forholdsregler: Det tilstræbes at lave realistiske deadlines. Hvis det sker: Øg arbejdsindsatsen eller gå på kompromis med kvaliteten / omfanget. Problemer med udstyr Sandsynligheden for at denne problemstilling bliver aktuel vurderes til 1, og konsekvensen til 3. Problemet er altså en faktor 3. Konsekvens: Problemer med udstyr kan gøre det meget svært at arbejde på projektet. Forholdsregler: Der vil blive foretaget hyppige backups så udstyr kan erstattes uden for meget besvær. Hvis det sker: Hvis problemet ikke kan løses kan der arbejdes videre med andet udstyr. Problemer med SVN på DTU. Sandsynligheden for at denne problemstilling bliver aktuel vurderes til 1, og konsekvensen også til 1. Problemet er altså en faktor 1. Konsekvens: Foretrukken backup-facilitet er ikke tilgængelig. Backup og versionering bliver besværliggjort. Forholdsregler: Ingen. Hvis det sker: Foretag backup på ekstern disk manuelt. 21

22 Oversigt over risici Problem Sandsynlighed Konsekvens Faktor Ændring af kravspecifikation Deadline kan ikke overholdes Problemer med udstyr Problemer med SVN på DTU Tabel 7: Risici ved projektet 4 Analyse-dokument Dette afsnit går i dybden med de use cases der er opstillet i inceptions-dokumentet. De use cases der skal implementeres beskrives i detaljer og der opstilles test cases for enkelte use cases. Derudover beskrives løsningsstrategien for projektet og der udarbejdes en domænemodel. 4.1 Detaljerede use cases De use cases der implementeres i systemet beskrives i detaljer her. Der opstilles tabeller for nogle af de detaljerede use cases, men da de fleste use cases for systemet er temmelig simple, vil der ikke blive opstillet tabeller for dem alle. De vil i stedet blive beskrevet i tekst Fælles for alle Login Når en bruger forsøger at tilgå systemet skal der først logges ind. Systemet viser en form til indtastning af DTU id og password. Brugeren indtaster sine oplysninger og klikker OK, og hvis oplysningerne er korrekte, bliver brugeren logget ind. Hvis oplysningerne ikke er korrekte får brugeren vist en fejlmeddelelse og bliver ikke logget ind. Udsend meddelelse Når en bruger får vist meddelelser for en sag er det muligt at udsende en ny meddelelse til sagen. Ved at klikke på Udsend ny meddelelse -linket åbnes en dialog der lader brugeren indtaste en ny meddelelse. Felterne udfyldes og der klikkes på Send. Den nye meddelelse vises nu i oversigten. Hvis der er fejl bliver meddelelsen ikke gemt, og der vises en fejl-meddelelse. Hvis brugeren fortryder inden der klikkes Send, er det muligt at fortryde ved at klikke på krydset i øverste højre hjørne af dialog-boksen. Se mine meddelelser En bruger kan få vist alle meddelelser for alle sager brugeren har adgang til. Det gøres ved at klikke på linket Meddelelser. Se vejledningsdokumenter Alle brugere kan få vist det vejledningsdokument der beskriver hvordan praktik og eksamensprojekt skal forløbe. Det gøres ved at klikke på linket Information. 22

23 4.1.2 Studerende Registrer studerende Use case Registrer studerende. Aktør Studerende. Formål At registrere relevante oplysninger om studerende der ønsker optagelse i systemet. Oversigt Når en studerende skal i praktik næste semester indtastes relevante oplysninger i systemet. Når oplysningerne er gemt i systemet gives der besked til praktikassistenten om dette. Prækondition Den studerende har logget ind med SSO og er ikke registreret i systemet. Postkondition Systemet har godkendt og gemt oplysninger og har underrettet praktikassistenten herom. Frekvens Der registreres op til 50 studerende om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Ansøgning. 2) Systemet viser en formular til indtastning af oplysninger. 3) Der indtastes relevant data. 4) Der klikkes på Send. Alternativt: Fortsæt fra 3. Tabel 8: Detaljeret use case - Registrer studerende 5) Systemet validerer og gemmer data. 6) Systemet sender besked til praktikassistenten om ansøgningen. 5a) Systemet finder fejl ved validering. 5a1) Systemet viser fejlmeddelelser sammen med formularen. 23

24 Opdater form Use case Opdater form data. Aktør Studerende. Formål At udfylde / opdatere en formular i systemet med relevant data. Oversigt Den studerende er selv ansvarlig for at udfylde formularer med påkrævet data. Formularens felter udfyldes hvorefter data gemmes i systemet. Prækondition Den studerende er logget ind med SSO. Postkondition Systemet har godkendt og gemt oplysninger. Frekvens Der opdateres op til 50 formularer om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Forms. 2) Systemet viser tilgængelige forms. 3) Der klikkes på den form der skal udfyldes. 4) Systemet viser formularen. 5) Der indtastes relevant data. 6) Der klikkes på Gem. 7) Systemet validerer og gemmer data. Alternativt: 6a) Der klikkes på Reset. 6a1) Systemet viser oprindelig data. Fortsæt fra 5. 6b) Der klikkes på Fortryd. 6b1) Systemet går tilbage til forrige tilstand uden at gemme. 7a) Systemet finder fejl ved validering. 7a1) Systemet viser fejlmeddelelser sammen med formularen. Fortsæt fra 5. Tabel 9: Detaljeret use case - Opdater form data Upload std. dok. En studerende kan uploade en fil til et standard dokument der tillader dette. For at gøre dette klikkes først på linket Dokumenter. Derefter vælges det standard dokument der skal uploades en fil til. Systemet viser de muligheder man har for at anvende dokumentet, og der klikkes på Upload fil. En dialog åbner der lader den studerende vælge hvilken fil der skal uploades. Når en fil er valgt klikkes på Upload og files gemmes i systemet. Upload fil En studerende kan uploade en fil under fildeling. Først klikkes på linket Fildeling. Nu vises en oversigt over filer allerede i fildeling med flere valgmuligheder. En ny fil kan enten uploades selvstændigt eller som en ny version af en eksisterende fil. Klik på Upload ny fil eller Ny version. En dialog åbner der lader den studerende vælge hvilken fil der skal uploades. Når en fil er valgt klikkes på Upload og files gemmes i systemet. 24

25 Godkendelse af praktikplads Når en studerende vil have sin praktikplads godkendt og de påkrævede oplysninger findes i systemet, klikkes blot på knappen til dette der findes på startsiden. Godkendelse af foreløbigt abstract Når en studerende vil have sit foreløbige abstract godkendt og de påkrævede oplysninger findes i systemet, klikkes blot på knappen til dette der findes på startsiden. Godkendelse af praktik Når en studerende vil have sin praktik godkendt og de påkrævede oplysninger findes i systemet, klikkes blot på knappen til dette der findes på startsiden. Godkendelse af abstract Når en studerende vil have sit endelige abstract godkendt og de påkrævede oplysninger findes i systemet, klikkes blot på knappen til dette der findes på startsiden. 25

26 4.1.3 Praktikassistent Behandl registrering Use case Behandl registrering. Aktør Praktikassistent. Formål At godkende en registrering og give en studerende adgang til systemet. Oversigt Når praktikassistenten modtager en besked om en ny registrering skal den behandles og godkendes, hvis alt er i orden. Prækondition Praktikassistenten har logget ind med SSO og der er en ny registrering. Postkondition Systemet har accepteret godkendelsen og underrettet den studerende herom. Frekvens Der godkendes op til 50 registreringer om dagen i peaks, men ellers under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Anmodninger. 2) Systemet viser en liste over alle anmodninger. 3) Der klikkes på den studerende hvis registrering skal behandles. 5) Der klikkes på Ansøgning. 7) Der klikkes på Tilbage. 9) Der klikkes på Godkend. Alternativt: 9a) Ansøgningen er mangelfuld så der indtastes en besked til den studerende. 9a1) Der klikkes på Afvis. 4) Systemet viser en liste med muligheder for den studerendes sag. 6) Systemet viser den studerendes ansøgning. 8) Systemet viser igen listen med muligheder for den studerendes sag. 10) Systemet registrerer at ansøgningen er godkendt. 11) Systemet sender besked til den studerende om godkendelsen. 9a2) Systemet gemmer data. 9a3) Systemet sender besked til den studerende om afvisningen. Tabel 10: Detaljeret use case - Behandl registrering 26

27 4.1.4 Praktikkoordinator Godkend praktikvirksomhed Use case Godkend praktikvirksomhed. Aktør Praktikkoordinator. Formål At godkende oplysninger om en studerendes praktik. Oversigt Når praktikkoordinatoren modtager en besked om en ny praktikvirksomhed, skal denne virksomhed godkendes. Prækondition Praktikkoordinatoren har logget ind med SSO og der findes en ny praktikvirksomhed. Postkondition Systemet har registreret at virksomheden er accepteret og underrettet den studerende herom. Frekvens Der godkendes op til 50 virksomheder om dagen i peaks, men eller under 1 om dagen. Typisk hændelsesforløb: Aktør System 1) Der klikkes på Anmodninger. 2) Systemet viser en liste over alle anmodninger. 3) Der klikkes på den studerende hvis praktikvirksomhed skal behandles. 5) Der navigeres til de data der beskriver praktikvirksomheden. 7) Der klikkes på Tilbage. 9) Der klikkes på Godkend. Alternativt: 9a) Oplysninger om praktikophold er mangelfuld så der indtastes en besked til den studerende. 9a1) Der klikkes på Afvis. 4) Systemet viser en liste med muligheder for den studerendes sag. 6) Systemet viser den studerendes data. 8) Systemet viser igen listen med muligheder for den studerendes sag. 10) Systemet registrerer at praktikvirksomheden er godkendt. 11) Systemet sender besked til den studerende om godkendelsen. 9a2) Systemet gemmer data. 9a3) Systemet sender besked til den studerende om afvisningen. Tabel 11: Detaljeret use case - Godkend praktikvirksomhed 27

28 Godkend foreløbigt abstract Når et foreløbigt abstract skal godkendes klikkes først på linket Anmodninger. Derefter vises en liste over anmodninger fra studerende, og den studerende hvis foreløbige abstract skal godkendes vælges fra listen. Nu vises en liste med muligheder for den studerendes sag. Herfra er det muligt at se den studerendes udfyldte forms, uploadede standard dokumenter og fildeling. Hvis alt er i orden klikkes på Godkend knappen. Hvis alt ikke er i orden indtastes eventuelt en meddelelse til den studerende og der klikkes på Afvis. Godkend praktik Når en afsluttet praktik skal godkendes klikkes først på linket Anmodninger. Derefter vises en liste over anmodninger fra studerende, og den studerende hvis praktik skal godkendes vælges fra listen. Nu vises en liste med muligheder for den studerendes sag. Herfra er det muligt at se den studerendes udfyldte forms, uploadede standard dokumenter og fildeling. Hvis alt er i orden klikkes på Godkend knappen. Hvis alt ikke er i orden indtastes eventuelt en meddelelse til den studerende og der klikkes på Afvis DTU Vejleder Se mine studerende En DTU Vejleder kan få vist en liste over de studerende denne er vejleder for. Dette gøres ved at klikke på linket Studerende. Søg mine studerende I listen over studerende er det også muligt at søge efter studerende. Siden indeholder en form der tillader søgning baseret på studerendes navn, studie-nummer samt status for praktik og eksamensprojekt. En DTU Vejleder kan kun fremsøge egne studerende Fælles for Praktikassistent og Praktikkoordinator Se alle studerende En liste over alle aktive studerende i systemet kan fås ved at klikke på linket Studerende. Søg alle studerende I listen over studerende er det også muligt at søge efter studerende. Siden indeholder en form der tillader søgning baseret på studerendes navn, studie-nummer samt status for praktik og eksamensprojekt. Tilknyt DTU Vejleder En studerende skal have tilknyttet en DTU Vejleder før der skrives eksamensprojekt. Fra listen over muligheder for den studerendes sag klikkes på Administrer. Systemet viser nu en række muligheder for at administrere sagen. Et tekstfelt tillader at der indtastes DTU id på den vejleder der skal tilknyttes og et tryk på Tilknyt -knappen gemmer data i systemet. Fjern DTU Vejleder Fra samme side som man tilføjer en DTU Vejleder til en sag, er det også muligt at fjerne en. Siden indeholder en liste af de DTU id er der er tilknyttet den studerendes sag, og et lille kryds gør det muligt at fjerne et tilknyttet DTU id igen. Ændr status for studerende Det er muligt manuelt at ændre en studerendes status i systemet. På samme side som nævnes i de forrige to use cases er to dropdowns der gør det muligt at ændre status for en studerendes praktik og eksamensprojekt. Når begge dropdowns er indstillet som ønsket klikkes på Gem. 28

29 Opret / rediger ansat Det er muligt manuelt at oprette og redigere DTU ansattes brugere, deres oplysninger og roller. Dette gøres ved at klikke på linket Administrer og derefter på Administrer ansatte. Systemet viser nu en liste over de ansatte der findes i systemet. Et link, Opret ny ansat, gør det muligt at oprette en ny bruger, indtaste oplysninger og tildele roller. Ved at klikke på en ansat i listen er det muligt at ændre en eksisterende bruger. Slet ansat Hvis det ikke længere er nødvendigt at have en ansat i systemet er det muligt at fjerne denne. Fra listen nævnt i forrige use case er det muligt at fjerne en ansat ved at klikke på et lille kryds ud for den ansattes navn. Opret / rediger form De forms der er tilgængelige for studerende, kan oprettes og redigeres via systemet. Først klikkes på Administrer og derefter på Administrer forms. Nu vises to lister der tilsammen viser alle forms i systemet. Den første liste er de forms der vises for studerende, den anden er de forms der er deaktiverede og ikke vises for studerende. Der kan klikkes på Opret ny form eller vælges en eksisterende form og klikkes på Rediger for denne. Systemet viser en ny side der gør det muligt at opbygge en form. En række knapper kan bruges til at tilføje elementer til formularen. Det er muligt at angive en titel til formularen, navne til hvert input element, samt at ændre rækkefølgen på de elementer der er tilføjet formularen. En Tilbage -knap kan bruges til at gå tilbage uden at gemme ændringer, og en Gem -knap til at gemme ændringerne. Slet form Forms der ikke længere skal bruges kan fjernes fra systemet. På Administrer forms siden vælges den form der skal fjernes og der klikkes på Slet. Skjul / vis form for studerende Hvis en form ikke skal være tilgængelig for studerende, men man ikke ønsker at slette den, kan den skjules for studerende. På Administrer forms siden vælges den form der skal fjernes og der klikkes på Deaktiver. En form der allerede er skjult for studerende vil have et Aktiver -link i stedet for. Opret / rediger std. dok. Det er muligt at oprette og redigere standard dokumenter og bestemme hvordan de kan bruges af studerende. Først klikkes på Administrer og så på Administrer standard dokumenter. Nu vises en liste over de standard dokumenter der er definerede i systemet. De eksisterende dokumenter kan redigeres ved at klikke på deres navn i listen, og et nyt dokument kan defineres ved at klikke på Opret nyt. Fra Opret / rediger dialogen er det muligt at vælge en skabelon for dokumentet som studerende kan downloade, og det er muligt at angive et navn for dokumentet samt at angive om studerende skal kunne uploade egne filer under dette dokument. Slet std. dok. Standard dokumenter der ikke længere skal bruges kan fjernes igen. Fra listen af dokumenter på siden Administrer standard dokumenter, er det muligt at fjerne et dokument ved at klikke på krydstet ud for navnet. 29

30 4.1.7 Fælles for Praktikassistent, Praktikkoordinator og DTU Vejleder Se studerendes forms Det er muligt at se alle de forms en studerende har udfyldt. Fra siden til visning af en studerendes sag klikkes på Forms. Dette giver en liste over de forms den studerende har anvendt. Vælg en form og systemet vil vise den. Se studerendes std. doks. Det er muligt at se alle de std. doks en studerende har anvendt. Fra siden til visning af en studerendes sag klikkes på Standard dokumenter. Dette giver en liste over standard dokumenter. Vælg et og systemet vil vise indholdet. Se studerendes fildeling Det er muligt at se en studerendes fildeling. Fra siden til visning af en studerendes sag klikkes på Fildeling. Systemet viser nu de filer den studerende har lagt under fildeling. Se studerendes meddelelser Det er muligt at se de meddelelser der er tilknyttet til en studerendes sag. Fra siden til visning af en studerendes sag klikkes på Meddelelser. Systemet viser nu de meddelelser der er udsendt under sagen. 4.2 Test cases For at kunne teste hvorvidt de funktionelle krav er opfyldt, er der udarbejdet nogle test cases. Der er kun opstillet test cases for de detaljerede use cases der er beskrevet i tabeller i forrige afsnit. Hvordan de øvrige use cases skal testes er beskrevet i afsnit 9. Test case Aktør Formål Prækondition Postkondition Testforløb: Aktør 2) Klik på Ansøgning. 4) Udfyld felter. 5) Klik på Send. Alternativt: Fortsæt fra 4. Registrer studerende. Studerende. At teste om det er muligt at registrere sig i systemet. Den studerende er logget ind med DTU SSO og er ikke registreret i forvejen. Relevant data er gemt og praktikassistenten er blevet underrettet. System 1) System viser en startside. Tabel 12: Test case - Registrer studerende 3) Systemet viser en formular til angivelse af oplysninger. 6) Systemet gemmer data uden valideringsfejl. 6a) Systemet viser fejlmeddelelser samt formularen. 30

31 Test case Aktør Formål Prækondition Postkondition Testforløb: Aktør 2) Klik på anmodninger. 4) Klik på den studerende hvis anmodning skal behandles. 6) Klik på Ansøgning. Behandl registrering. Praktikassistent. At teste om det er muligt at behandle en ny registrering. Praktikassistenten er logget ind med SSO og der er en ny registrering. Den studerende er optaget i systemet og har fået besked om det. System 1) Systemet viser en startside. 3) Systemet viser liste over brugere med ventende anmodninger. 5) Systemet viser en liste med muligheder for den studerendes sag. 7) Systemet viser den studerendes ansøgning. 8) Klik på Tilbage. 9) Systemet viser igen en liste med muligheder for den studerendes sag. 10) Klik på Godkend. Alternativt: 10a) Indtast besked til den studerende om hvorfor anmodningen afvises. 10a1) Klik på Afvis. Tabel 13: Test case - Behandl registrering 31

32 Test case Aktør Formål Prækondition Postkondition Testforløb: Aktør 2) Klik på Forms 4) Klik på den form der skal opdateres. 6) Rediger ønskede felter. 7) Klik på Gem. Alternativt: 7a) Klik på Reset. Fortsæt fra 6. 7b) Klik på Fortryd. Fortsæt fra 6. Opdater form data. Studerende. At teste om det er muligt at opdatere form data i systemet. Den studerende er logget ind med DTU SSO. Opdateret data er gemt. Tabel 14: Test case - Opdater form data System 1) Systemet viser en startside. 3) Systemet viser tilgængelige forms. 5) Systemet viser side til redigering af formularen. 8) Systemet gemmer data uden valideringsfejl. 7a1) Systemet viser oprindelig data. 7b1) Systemet går tilbage til forrige tilstand uden at gemme. 8a) Systemet viser fejlmeddelelser samt formular. 32

33 Test case Aktør Formål Prækondition Postkondition Testforløb: Aktør 2) Klik på anmodninger. 4) Klik på den studerende hvis anmodning skal behandles. 6) Naviger til de oplysninger den studerende har angivet om praktikopholdet. Godkend praktikvirksomhed. Praktikkoordinator. At teste om det er muligt at godkende en ny praktikvirksomhed. Praktikkoordinatoren er logget ind med SSO og der er en ny praktikvirksomhed. Den studerendes praktikvirksomhed er godkendt og den studerende har fået besked om dette. System 1) Systemet viser en startside. 3) Systemet viser liste over brugere med ventende anmodninger. 5) Systemet viser en liste med muligheder for den studerendes sag. 7) Systemet viser data. 8) Naviger tilbage til listen med muligheder. 9) Systemet viser igen en liste med muligheder for den studerendes sag. 10) Klik på Godkend. Alternativt: 10a) Indtast besked til den studerende om hvorfor anmodningen afvises. 10a1) Klik på Afvis. Tabel 15: Test case - Godkend praktikvirksomhed 4.3 Løsningsstrategi Udviklingen af dokument- og sagsstyringssystemet vil foregå efter Unified Process metoden. Denne model er iterativ og inkrementel og medfører blandt andet at der tidligt i forløbet findes et funktionelt system, der løser nogle use cases, og som projektet skrider frem løser flere og flere. Projektarbejdet vil tage udgangspunkt i use cases med fokus på at behandle risikoområder så tidligt i projektet som muligt. Projektet er indelt i timeboxes. Indelingen kan ses på Figur 3. Inceptionsfasen bliver brugt til at få overblik over projektet, samt til at skabe en plan for arbejdet ud fra kundens ønsker og behov. I denne fase arbejdes der med use cases af forretningsmæssig betydning for at opnå forståelse for kundens forretning og vision. Elaborationsfasen benyttes til at analysere forretningsmæssige og systemmæssige problemstillinger og til at designe systemet. I hver iteration af elaborationen vil der blive arbejdet med alle seks UP discipliner for nogle få use cases. Der arbejdes med use cases af betydning for både forretning og system og der fokuseres på høj-værdi- og høj-risiko-problemstillinger. I tidlige 33

34 iterationer vil der være mest arbejde med analyse og arkitektur, men som tiden går vil design fylde mere. I constructionfasen skal hovedparten af analyse og design være på plads, ligesom systemarkitekturen også gerne skal være nogenlunde fast. Derfor kan der i denne fase fokuseres på implementering af de resterende use cases. Transition er den sidste fase i UP. I denne fase arbejdes med at gøre systemet klar til produktion. Systemet vil blive modelleret ved hjælp af udvalgte UML artefakter. Figur 3: Iterationsplan 34

35 4.4 Domænemodel For at vise konceptet for det system der produceres er der udarbejdet en domænemodel. Domænemodellen kan ses på Figur 4. Figur 4: Domænemodel 35

36 5 Design-dokument Dette afsnit omhandler systemets design. Det indeholder package-diagram og en gennemgang af de overvejelser der er gjort i forbindelse med design af systemet. 5.1 Package-diagram Den overordnede struktur af systemets implementation modelleres med et package-diagram. Package-diagrammet kan ses på Figur 5. Figur 5: Package-diagram 36

37 5.2 Designovervejelser Mange af funktionerne i webapplikationen kan implementeres på flere forskellige måder. Beslutninger om hvilke løsningsmodeller der implementeres er taget ud fra en vurdering af metodernes muligheder og begrænsninger sammenholdt med brugernes behov. Dette afsnit beskriver de overvejelser og valg der er gjort i forbindelse med udvikling af webapplikationen. De overvejelser der er gjort i forbindelse med databasen er ikke medtaget her, men kan i stedet læses i afsnit Fildeling Det skal være muligt for brugere af applikationen at dele filer. Der er flere metoder at implementere denne fildeling på, og fordele og ulemper ved hver metode. Den første mulighed er at benytte filsystemet på den webserver applikationen deployes på. Denne metode virker ret oplagt at benytte da filsystemet jo er beregnet til at håndtere filer. Problemet ved denne løsning er at applikationens data nu er delt mellem databasen og webserveren. Dette vil gøre backup af data mere besværlig. Samtidig vil det kræve lidt mere arbejde at holde styr på hvilke filer der tilhører hvilke brugere, samt at understøtte versionering af filerne. En anden mulighed er at benytte databasen til at gemme filerne. På den måde vil alt data være samlet et sted, hvorved backup bliver nemmere. Ulempen her er at databasen ikke er beregnet til at håndtere filer, så det er lidt omstændigt at bruge den til dette. Til gengæld er det nemt at administrere ejerne af filerne samt versionering. Det er også muligt at benytte en blanding af filsystem og database ved for eksempel at gemme filerne på webserveren og holde stierne til filerne i databasen. På den måde får man effektiv håndtering af filerne med filsystemet, samtidig med at det er nemt at holde styr på versionering samt hvem der ejer filerne med databasen. Dette løser dog ikke problemet med backup da data stadig er delt mellem webserver og database. Endelig er det også en mulighed at købe en file-storing service hos en virksomhed der specialiserer i håndtering af filer Til denne applikation er det valgt at fildeling implementeres som en ren databaseløsning. Denne løsning er valgt da det forventes at der kun bliver uploadet rimelig små filer (på et par MB), at der ikke skal håndteres ekstremt mange filer samt at det vil være rart med en løsning der giver nem backup og versionering. Det er ikke kun fildelings-funktionen der får behov for at gemme filer - beslutningen om at anvende en database-løsning er taget på baggrund af systemets samlede behov for filhåndtering. Noget andet der skal tages stilling til er hvilke funktioner der skal være mulige under fildeling, samt hvilke rettigheder studerende skal have. Hvis det blot skal være en meget simpel fildeling, hvor brugere kan uploade filer til deres egen fildeling, vil implementeringen også blive meget simpel. Hvis systemet skal understøtte versionering, så der kan uploades nye versioner af eksisterende filer, bliver det lidt mere avanceret at implementere. Hvis der så også skal være mulighed for at organisere filerne yderligere (f.eks. ved at oprette mapper i fildeling), bliver systemet igen mere avanceret. Da fildeling vurderes at være en funktion der kun vil blive anvendt af få brugere, vil den helt avancerede løsning med mappe-strukturer ikke blive implementeret. I stedet vil der blive implementeret en flad fildeling med versioneringsmuligheder. Hvor vidt en bruger skal have lov til at fjerne filer fra fildeling afhænger af hvor sikker man vil være på ikke at miste vigtig data. Hvis brugere får lov at fjerne filer, kan de også fjerne filer man gerne vil beholde. 37