02329: Datateknisk produktudvikling - Danmarks Tekniske Universitet

Eksamensprojekt 

Titel: SAPS 

Sammenbinding Af Parknets Systemer 

Rapportnummer: IMM-B.Eng-2009-02 

Henrik Bering s032251 

Vejleder: Mads Nyborg 

Denne rapport indeholder 80 sider inklusiv denne side. 

Udtræk af rapporten: 

Denne rapport handler om udvikling af et nyt administrationssystem til en 

Internetudbyder på Nørrebro ved navn IT-lauget Parknet (herefter benævnt 

Parknet). Systemet skal styre, hvilke services som tilbydes til de specifikke 

adresser, brugere, opkrævninger og simulere styring af netværksudstyr via 

SNMP kommandoer. 

Analysen dækker Parknet i sin nuværende udformning med de eksisterende 

systemer. Designet af databasen og applikationen dækker ca. 90 % af 

Parknets tilslutninger. Der er implementeret ca. 75 % af designet. Resten 

står som forslag i afsnittet om ”forslag til forbedringer af SAPS”. 

Det er meningen, at SAPS i fuldt færdig form skal kunne erstatte Winkas 

(Winkas forklares i rapporten). 

SAPS kan ses kørende på adressen: http://saps.tiptop8.dk 

Online tilmelding kører på: http://opret.tiptop8.dk 

Testbruger til SAPS: 

Brugernummer: 11111111 

Password: password

Eksamensprojekt af Henrik Bering SAPS IMM-B.Eng-2009-02 

1 Indholdsfortegnelse 

1.1 Outline 

1 Indholdsfortegnelse ..................................................................... 2 

2 Forord ....................................................................................... 4 

3 Indledning.................................................................................. 4 

4 Domænemodel og beskrivelse af Parknet ........................................ 6 

5 Analyse.................................................................................... 17 

6 Design ..................................................................................... 26 

7 Implementering ........................................................................ 34 

8 Test......................................................................................... 50 

9 Forslag til forbedringer af SAPS ................................................... 58 

10 Procesafsnit.............................................................................. 60 

11 Konklusion ............................................................................... 61 

12 Spørgsmål og svar med Parknets chef .......................................... 62 

13 Anbefaling til Parknet ................................................................. 63 

14 Lister....................................................................................... 64 

15 Bilag........................................................................................ 65 

1.2 Index 

1 Indholdsfortegnelse ..................................................................... 2 

1.1 Outline .......................................................................................2 

1.2 Index .........................................................................................2 

2 Forord ....................................................................................... 4 

3 Indledning.................................................................................. 4 

3.1 Formål .......................................................................................4 

3.2 Succeskriterie..............................................................................4 

3.3 Målgruppe...................................................................................5 

3.4 Læsevejledning............................................................................5 

4 Domænemodel og beskrivelse af Parknet ........................................ 6 

4.1 Historien bag Parknet ...................................................................6 

4.2 Parknets services (pr. 1/1-2009)....................................................7 

4.2.1 TV ..........................................................................................7 

4.2.2 Telefon....................................................................................7 

4.2.3 Internet ..................................................................................7 

4.2.4 Generelt ..................................................................................7 

4.3 Beskrivelse af Parknets netværk.....................................................8 

4.4 Beskrivelse af tekniske anlæg i Parknet...........................................9 

4.5 Beskrivelse af Parknets administrationssystemer ............................10 

4.6 Beskrivelse af en bruger i Parknet ................................................14 

4.7 Beskrivelse af procedurer i Parknet...............................................14 

4.7.1 Oprettelse af Internet..............................................................14 

4.7.2 Oprettelse af et telefonnummer ................................................14 

4.7.3 Oprettelse af TV/ændring af TV pakke .......................................14 

4.7.4 Bookning af teknikerbesøg .......................................................15 

4.7.5 Opkrævning...........................................................................15 

4.7.6 Overdragelse af abonnement....................................................15 

4.7.7 Diagram over domænemodellen ...............................................16 

5 Analyse.................................................................................... 17 

5.1 Kravspecifikation til det nye system..............................................17 

DTU – Danmarks Tekniske Universitet Side 2 af 80


5.1.1 Funktionelle krav ....................................................................17 

5.1.2 Non funktionelle krav ..............................................................18 

5.1.3 Designvalg.............................................................................19 

5.2 Analyse af applikationen .............................................................20 

5.2.1 Use case diagram ...................................................................20 

5.2.2 Aktørbeskrivelser....................................................................21 

5.2.3 Overordnede use case beskrivelser............................................21 

5.2.4 Detaljerede use case beskrivelser .............................................23 

5.3 Analyse af databasen til Parknet...................................................25 

6 Design ..................................................................................... 26 

6.1 Databasen ................................................................................27 

6.1.1 Databasediagram ...................................................................27 

6.2 SAPS........................................................................................30 

6.3 Online tilmelding........................................................................30 

6.4 Sitemap over SAPS og online tilmelding ........................................31 

6.4.1 Designklassediagram SAPS ......................................................32 

Designklassediagram online tilmelding ....................................................33 

7 Implementering ........................................................................ 34 

7.1 Databasen ................................................................................34 

7.1.2 Stored Procedures ..................................................................38 

7.1.3 Views....................................................................................38 

7.2 Sitemap over SAPS og online tilmelding ........................................39 

7.3 SAPS........................................................................................40 

7.3.1 Beskrivelse af de forskellige JSP filer .........................................40 

7.4 Online tilmelding........................................................................44 

7.4.1 Beskrivelse af de forskellige JSP filer .........................................44 

7.4.2 State diagram ........................................................................47 

7.5 Implementeret og ikke-implementeret: .........................................48 

8 Test......................................................................................... 50 

8.1 Indledning ................................................................................50 

8.2 Demonstration...........................................................................50 

8.3 Brugertest ................................................................................50 

8.3.1 Test cases .............................................................................50 

8.4 Fejlrapportering og fejlliste..........................................................56 

8.5 Test konklusion .........................................................................57 

9 Forslag til forbedringer af SAPS ................................................... 58 

10 Procesafsnit.............................................................................. 60 

11 Konklusion ............................................................................... 61 

12 Spørgsmål og svar med Parknets chef .......................................... 62 

13 Anbefaling til Parknet ................................................................. 63 

14 Lister....................................................................................... 64 

14.1 Litteratur liste ...........................................................................64 

14.2 Forkortelser brugt i rapporten ......................................................64 

14.3 Figurliste ..................................................................................64 

15 Bilag........................................................................................ 65 

15.1 Bilag 1 – Projektoplæg................................................................65 

15.2 Bilag 2 – Billede af krydsfeltet b16x16 ..........................................68 

15.3 Bilag 3 – billeder af TV skab ........................................................69 

15.4 Bilag 4 – Indhold på CD-rom: ......................................................71 

15.5 Bilag 5 – Installationsvejledning til SAPS .......................................72 

15.6 Bilag 6 – Brugermanual til SAPS...................................................73 



2 Forord 

Dette projekt er udført i forlængelse af min ingeniørpraktik hos Parknet. Det 

tager udgangspunkt i manglende samspil mellem Parknets mange systemer 

– heraf projekttitlen: ”Sammenbinding Af Parknets Systemer (SAPS)”. Jeg 

vil gerne sige tak til Parknets medarbejdere og bestyrelse for at lade mig 

være i ingeniørpraktik og efterfølgende skrive eksamensprojekt om Parknet. 

3 Indledning 

Denne rapport handler om et bruger- og netværksadministrationssystem til 

Parknet. Systemet er skræddersyet til Parknet og vil ikke have anvendelsesmuligheder 

andre steder. 

Systemet tager udgangspunkt i en analyse af Parknets nuværende systemer 

og forretningsgange herunder: Netværket, databaser, opkrævninger, 

brugere, arbejdsgange og samspillet imellem systemerne. 

3.1 Formål 

Formålet med projektet er følgende: 

• At vise, hvordan mange systemer, udviklet i forskellige 

programmerings–sprog og kørende på forskellige styresystemer, kan 

samles i et system med en fælles brugergrænseflade. 

I forbindelse med udvikling af systemet bliver følgende udarbejdet: 

• detaljeret beskrivelse af to udvalgte use cases 

• domænemodel (analysedokumentation) 

• databasemodel 

• dokumentation af implementeret kode (på cd-rom) 

• dokumentation af implementerede databasetabeller (på cd-rom) 

• test 

• forslag til forbedringer af systemet 

3.2 Succeskriterie 

At SAPS kan bruges af Parknet i daglig drift. 



3.3 Målgruppe 

Den primære målgruppe for denne opgave med tilhørende rapport er lærer 

og censor. Sekundær er Parknet, som vil kunne bruge produktet til 

administration. 

Systemet vil også kunne bruges af andre mindre bredbåndsudbydere, men 

vil kræve nogen tilpasning til deres forretning. 

Læseren formodes at have kendskab til programmering og unified modelling 

language (UML), hvorfor der ikke kan forventes forklaringer på mindre 

problemstillinger. 

3.4 Læsevejledning 

Overordnet starter jeg med en analyse af de nuværende systemer og 

måden, de bliver anvendt på. Dernæst beskriver jeg forslag til, hvordan 

tingene kunne gribes an i stedet for. I forbindelse med dette vil jeg ofte 

referere til, hvordan tingene bliver gjort nu for at vise forskellen mellem det 

nye og det nuværende system. Det nye system skal testes, hvilket til dels 

bliver gjort undervejs i udviklingsprocessen. Den store test bliver at 

demonstrere systemet for Parknets medarbejdere og få deres 

kommentarer. Eventuelle forslag til forbedringer kommer med i kapitlet om 

forslag til forbedringer. Afrunding på rapporten bliver en konklusion, et 

kapitel med spørgsmål og svar til Parknets chef og en række anbefalinger til 

Parknet. 

Craig Larmans (1) indgangsvinkel til objekt orienteret analyse er brugt i 

rapporten. 

Jeg berører kortvarigt elementer fra bogen ”Goal directed project 

management” (5). 

Undervejs i rapporten anvendes ordene krydsfelt, intersection og x-felt i 

flæng. Der menes det samme uanset, hvilket ord som er brugt. Derudover 

bruges også ordene abonnement, ydelser og service i betydningen - 

abonnement. 

Jeg bor i andelsboligforeningen Lindegaarden og undervejs i rapporten 

refereres der til denne boligforening. Testdata i SAPS er baseret på A/B 

Lindegaardens tilslutning til Parknet. 



4 Domænemodel og beskrivelse af Parknet 

4.1 Historien bag Parknet 

Parknet er et IT-laug på Nørrebro, som leverer Internet, telefoni og TV. Der 

er fire fastansatte og en studentermedhjælper. Bogholderifunktionen er 

outsourcet og bestrides af en fultids- og en deltidsansat. 

Parknet blev formelt stiftet 1. januar 2004 som en forening uden ansatte, 

dvs. alt var baseret på ildsjæles frivillige arbejde. På dette tidspunkt var der 

ca. 1.000 tilslutninger. I løbet af 2005 blev der penge nok til at ansætte de 

første folk på fuldtid. Det medførte en øget interesse for Parknet, da visse 

boligforeninger havde været skeptiske overfor en organisation uden ansatte 

og dermed uden mulighed for at stille krav til kvaliteten af de leverede 

services. 2006 blev det hidtil største vækst år for Parknet og antallet af 

tilslutninger var pr. 31. december 2006 nået op på 7.000. 

I 2007 var fokus på konsolidering af tilslutningerne da, der var inkonsistens 

i data og manglede opdatering af dokumentation i forbindelse med alle 

tilslutningerne i 2006. Opdatering og oprydning pågår stadig og er et af 

kravene for at kunne automatisere netværket yderligere. 

I 2008 er Indre Nørrebro IT-laug med navnet Firkantnet koblet til Parknet. 

Det medførte en forøgelse på 2.000 tilslutninger og bringer det samlede 

antal tilslutninger pr. 1. januar 2009 op på ca. 10.500. Desværre skete der 

også det kedelige, at Parknet mistede den ene af sine 3 services i 2008 – 

TV. I hovedtræk var det uoverensstemmelser mellem YouSee, Viasat og 

Parknets måde at levere TV på, som gjorde at signalet blev lukket. Der blev 

dog hurtigt sammensat en løsning, som nu fortsat leverer TV til Parknets 

brugere (dog uden Viasatkanaler). 

Pr. 1. april er TV servicen tilbage i Parknets (det afsluttende arbejde med 

genimplementering pågår, mens denne rapport skrives). Derudover skal der 

ske en fortsat vækst i netværket. Mange, som er flyttet fra en adresse på 

Nørrebro med Parknet til et nyt sted uden Parknet, er store fortalere for 

Parknet på foreningernes generalforsamlinger. Det betyder en naturlig 

tilgang af nye foreninger. Parknet er i skrivende stund ved at tilkoble de 

første foreninger på Østerbro og Amager. Derudover har Parknet fået sin 

første ”Fiber to the Home (FTTH)” installation i drift i Haveforeningen 

Birkevang (Brønshøj ved Husum Torv). FTTH betyder, at der er lysleder til 

hver bruger i stedet for kobberkabler. 

Parknet, som startede med 1.000 tilslutninger i postnummer 2200 for 5 år 

siden, dækker nu over 2100, 2200, 2300, 2400, 2500 og 2700 med ca. 

10.500 tilslutninger. 



Parknets formål (jf. www.parknet.dk) 

Parknets mål er at levere bredbånd til alle, som er helt uden konkurrence 

på såvel kvalitet og ydelse som support. 

Parknets koncept 

Parknet er en non-profit, brugerejet og brugerstyret forening. Parknet 

består af mere end 100 boligforeninger, der er gået sammen om at indkøbe 

de bedst mulige bredbåndsydelser, som sælges videre til brugerne uden 

fortjeneste. 

4.2 Parknets services (pr. 1/1-2009) 

4.2.1 TV 

Parknet har fire TV pakker. Indholdet af pakkerne kan ses på Parknets 

hjemmeside. De fire pakker er: 

- Lille 

- Mellem 

- Stor 

- Super 

Da Parknet ikke længere har tilladelse til at transmittere Viasat skal 

medlemsforeningerne selv indgå en aftale med Viasat og hente signalet via 

egen parabol. Parknet sørger for den tekniske installation således, at Viasat 

kanalerne bliver lagt korrekt ind sammen med de øvrige kanaler fra 

Parknet. 

4.2.2 Telefon 

Parknet leverer analog telefoni til brugerne. I netværket køres 

telefontrafikken dog over IP. I nye foreninger monteres der altid 

Audiocodes, som er en IP telefoncentral. 

I de første Parknet foreninger sidder der analoge centraler af forskellige 

mærker (EADS, Philips og Matra). 

Abonnementet inkluderer ekstra services som: banke på, forstyr ikke, 

viderestilling, vis/skjul nummer, vækning og telefonsvarer. 

4.2.3 Internet 

Parknets ældste service er Internet. Brugerne er ikke garanteret nogen 

bestemt hastighed, men Parknet indkøber båndbredde, så brugerne i 

princippet altid har mindst 10/10 Mbit. Der er til gengæld ingen øvre 

begrænsning (andet end udstyrets nuværende begrænsning på 100 Mbit). 

Hvis der er ledig båndbredde, kan brugerne surfe og dele filer med op til 

100 Mbit. 

4.2.4 Generelt 

Visse foreninger har fælles abonnement på TV og/eller Internet, de får 

derfor servicen til en billigere pris, fordi foreningen selv står for opkrævning 

hos brugerne. Det kræver korrekt dokumentation, når brugere og 

foreninger skal opkræves rigtigt. 



4.3 Beskrivelse af Parknets netværk 

Parknets distributionsnetværk er baseret på lysleder. For det meste er der 

brugt single mode (SM), men enkelte steder (i de første foreninger) er der 

anvendt multimode (MM). 

Der er et antal hovedkrydsfelter i Parknet. Fra disse er der trukket 

blæsefiber, som enten er 7- eller 19-rørs. Dvs. at der inde i blæsefiberen er 

enten 7 eller 19 rør med en tykkelse på 5mm., hvori der med trykluft kan 

blæses fra 12 til 48 lysledere. 

Til en forening som har alle tre Parknet services bruges minimum 2 SM 

lysledere, men helst 3 for at sikre redundans. 

Den ene lysleder bruges til TV, som sendes med en bølgelængde på 1550 

nM. I foreningen sidder der en TV fibernode, der omdanner signalet i 

lyslederen til analogt TV signal, som efterfølgende fødes ind i en 

antenneforstærker og fordeles ud til brugerne. Det er mellem TV fibernoden 

og antenneforstærkeren at Viasat signalet lægges oven i Parknets jf. 

beskrivelsen i 4.2.1. 

Den anden lysleder bruges til data og telefoni. Backbonen i Parknet tilsluttes 

til den første switch i krydsfeltet via et SFP modul. Den nyeste generation 

behøver kun 1 lysleder (i stedet for 2 i gamle dage), da den kan sende data 

begge veje samtidigt. Den bruger 1310 nM til at sende på og 1550 nM til at 

modtage på. 

Den tredje lysleder (som godt kan undværes, hvis der mangler ledige fibre) 

bruges til at forbinde den sidste switch i en forening retur til Parknet. På 

den måde er netværket bedre rustet, så udfald i enkelte krydsfelter ikke går 

ud over flere brugere end højest nødvendigt. 

Når en ny forening skal tilkobles i nærheden af en eksisterende, blæses 

fiberen ofte kun imellem disse to foreninger. Forbindelsen mellem den nye 

forening og nærmeste hovedkrydsfelt skabes ved at bruge 2 af de ledige 

fibre fra den eksisterende forening til hovedkrydsfeltet. Tilkobling på denne 

måde er med til at holde udgifterne nede. 

Parknet er 100 % foreningsejet og tilsammen ejer alle foreningerne 

distributionsnettet. Til nogle af yderforeningerne i Parknet har det ikke 

kunnet betale sig at trække egen fiber. I disse tilfælde har Parknet i 

samarbejde med foreningen valgt at købe fiberen hos Global Connect. 

Kort om Global Connect (6) 

Global Connects netværk er opbygget på egen infrastruktur af rør, fiber og 

transmissionsudstyr. I dag er det Danmarks stærkeste og største åbne 

fibernet baseret på "carrier class" services for både engrosvirksomheder og 

større virksomheder. 

Signalet i Parknets backbone kan ikke bruges uden videre i en almindelig 

computer. Backbonen er inddelt i 3 VLANs: tele, management og user. På 



denne måde kan Parknet styre, hvilke porte i Parknet som kan bruges til 

andet end almindelig brugertrafik. På tele VLAN’et sidder alle Audiocodes og 

har dedikeret båndbredde til telefontrafik. På management VLAN kan man 

logge ind på alle switche og bl.a. åbne og lukke for porte. User VLAN bruges 

til almindelig Internettrafik så som surf, e-mail osv. 

4.4 Beskrivelse af tekniske anlæg i Parknet 

Der er et antal krydsfelter i hver ejendom i Parknet, hvorfra signalet 

fordeles til hver lejlighed. Internet og telefoni fordeles altid ud fra samme 

krydsfelt. I nyere foreninger er TV installationen også monteret i 

krydsfeltet, i ældre foreninger sidder der et lille skab under hver opgang. 

Parknet er inddelt i blokke fra 0 til 255 (det passer med et klasse B netværk 

til hver blok). Hvis en ejendom er større end 250 lejligheder, skal den 

inddeles i flere blokke. A/B Lindegaarden har 100 tilslutninger og er blok 16 

i Parknet. Krydsfelter navngives efter bloknummer og opgangsnummer. 

Dvs. at de to krydsfelter på hhv. Kærsangervej 16 og Tornsangervej 7 

hedder b16x16 og b16x7. 

Krydsfeltet b16x16: TV skab mellem nr. 12 og 14: 

Figur 1 - Billeder af krydsfelter 

Beskrivelse af figur 1 - b16x16 (billedet kan ses i fuld størrelse i bilag 2): 

Øverst i billedet ses patchpanelerne, hvori ledningerne til lejlighederne er tilsluttet. 

De to lilla komponenter er Extreme Summit 200 switche med 24 porte. 

De to blå komponenter er Audiocodes MP 124 VOIP gateways med 24 porte. 

Den sorte skuffe med de grønne stik er forbindelsen til Parknet via lysleder. 

I bunden af skabet ligger en UPS til ca. 2 timers drift. 

Beskrivelse af figur 1 - TV skab (billedet kan ses i fuld størrelse i bilag 3): 

De to sorte ledninger er forsyningskabler fra antenneforstærkeren (sidder centralt) 

Øverst til højre i skabet sidder TV fordeleren - i fordeleren sidder pakkefiltrene 

De hvide ledninger går ud til lejlighederne 

Et pakkefilter er et lavpasfilter. Parknet har 4 TV pakker, dvs. der er brug for 3 

typer filtre (der er ikke filter på den dyreste pakke). 

- Lille pakke er alle kanaler under 400 MHz (filteret er umalet dvs. blankt) 

- Mellem pakke er alle kanaler under 566 MHz (filteret er gult) 



- Stor pakke er alle kanaler under 750 MHz (filteret er blåt) 

- Super pakke kræver ikke filter, ledningen er monteret direkte i fordeleren. 

Hvis TV skal frakobles eller ændres, skal der en tekniker ud HVER gang… 

4.5 Beskrivelse af Parknets administrationssystemer 

Parknet er baseret på mange systemer som griber ind i hinanden. De 

vigtigste, som jeg har valgt at tage med i denne beskrivelse er Winkas, 

Miralix, @mail, Google kalender og en Parknet programmeret telefonbog. 

Winkas er brugerdatabasen. Dette system bruges til: 

• Brugeroplysninger, adresseoplysninger 

• Netværksoplysninger specifikke for adressen (fx switch port nr.) 

• Opkrævning af services samt andre ydelser (fx teknikerbesøg) 

Internet har følgende muligheder: 

• Tilmeldingsdato, Udmeldelsesdato 

• Ekstra IP, man kan købe op til 254 faste IP adresser (pt. vises kun én) 

Telefon har følgende muligheder: 

• Tilmeldingsdato, Udmeldelsesdato, Abonnementstype 

• Flere telefonnumre (med separate tilmeldingsdatoer) 

• Kontonummer i Miralix, Lokalnummer (bruges til at rute opkald og til opkrævning) 

TV har følgende muligheder: 

• Tilmeldingsdato, Udmeldelsesdato, TV-pakkevalg, Pakkeskiftdato, Ny pakke 

Fordele (+) og ulemper (-) ved Winkas: 

+: 

• Et COTS produkt 

• Mulighed for support hos programleverandøren 

• Billig 

• Betalingsservice modul 

• Hurtigt at komme i gang 

• Baseret på en free ware database platform 

• Styring af placering af felter på skærmbilledet med drag and drop 

• Mulighed for til/fravalg af felter i listevisning 

• 

-: 

• Winkas har ikke printmulighed, man bruger print screen og sætter billedet fx i Word og printer 

derfra 

• Der er kun 100 felter i tabellen i databasen 

• Winkas kan ikke eksekvere kommandoer eller tilpassede forespørgsler i andre databaser 

• Tidsforbruget med at lave de hjælpeprogrammer til Winkas, som Parknet selv har udviklet, har 

været så stort, at det havde været hurtigere at lave sit eget system 

• Ved oprettelse af nye medlemmer er det ikke sikkert, at alle felter, defineret som 

standardværdier (fx netværksdata), bliver kopieret med, dvs. man efterfølgende skal lave 

manuel copy/paste af ca. 20 felter 

• Winkas yder kun support, hvis databasen kører på en MySQL 4.0.18 server under Windows 

Følgende tekst er hentet fra MySQL.com (udviklerne af MySQL databasesystemet) 

End of Product Lifecycle. 

Active development and support for MySQL database server versions 3.23, 4.0, and 4.1 has ended. 

However, for MySQL 4.0 and 4.1, there is still extended support available. For details, see 

http://www.mysql.com/company/legal/lifecycle/#calendar. According to the MySQL Lifecycle Policy (see 

http://www.mysql.com/company/legal/lifecycle/#policy), only Security and Severity Level 1 issues will 

still be fixed for MySQL 4.0 and 4.1. Please consider upgrading to a recent version (MySQL 5.0 or 5.1). 



Screen dump af en søgeoversigt i Winkas, hvorfra man kan få vist detaljer 

om hver enkelt bruger: 

Figur 2 - Screen dump af Winkas søgeoversigt 

Screen dump fra Winkas af min konto (jeg har konto 4878): 

Figur 3 - Screen dump af Winkas konto 4878 



Miralix: 

Er telefonafregningssystemet. Opkrævning af abonnement køres fra 

Winkas, mens afregning af telefonsamtaler køres i dette system. Hver gang 

en bruger i Parknet ringer, bliver samtalen logget fra start til slut og 

afhængig af opkaldsmodtagerens placering bliver prisen beregnet. Interne 

opkald i Parknet er gratis, flat rate giver gratis opkald til fastnet i DK + 60 

udlande de første 59 minutter af en samtale. Øvrige priser opdateres hver 

måned. Fakturering sker pr. sekund. 

Brugerne kan vælge to måder at afregne samtaler på. Den ene er, at de 

selv sørger for at indsætte taletid med dankort på deres taletidskonto. Den 

anden er, at Parknet opkræver forbruget kvartalsvis og sørger for, at 

beløbet bliver opkrævet sammen med abonnementet og indsat på 

taletidskontoen. 

Figur 4 - Screen dump af Miralix velkomstbillede 



@mail: 

Er Parknets mailsystem. I dette system ligger et antal domæner, som 

brugerne får tildelt adresse ud fra eksempelvis valbymail til brugerne i 

Valby. Oprettelsen af en ny mailadresse foretages manuelt af en Parknet 

medarbejder ved at logge ind i administrationsdelen og indtaste oplysninger 

om brugeren (navn, postadresse og tlf. nr.) og herefter at tildele brugeren 

den ønskede adresse (hvis den er ledig). Der er ingen automatik i 

processen. Det eneste der kan gøres hurtigere, er oprettelse af mange 

adresser. Systemet kan læse en csv fil og på den måde oprette mange 

brugere på én gang. 

Manglende automatisering af dette system betyder, at selv om brugere er 

flyttet ud af Parknet, nedlægges deres e-mail ikke. I modstrid med, at der 

står i Parknets betingelser, at adressen nedlægges efter ½ år. 

Figur 5 - Screen dump af @-mail - tilføj ny bruger 

Parknet telefonbog: 

Systemet bruges til at holde styr på telefonnumrene i Parknet. I systemet 

kan man se ledige telefonnumre, samt tage disse og bruge dem. 

Google kalender: 

Bruges til at booke et teknikerbesøg hos en bruger, hvis vedkommendes 

problem ikke kunne løses via telefonen. P.t. er der mulighed for at bestille 

tider hver tirsdag i tidsrummet 16-20, hvor Parknets studentermedhjælper 

kører ud til brugerne. 



4.6 Beskrivelse af en bruger i Parknet 

Det hele begynder med, at boligforeningen bliver medlem af Parknet. 

Herefter kan alle beboere blive tilmeldt Parknet (dvs. abonnere på services). 

Beboeren kan enten tilmelde sig via blanket eller online. Brugeren oprettes 

herefter på adressen og betaler fremover for de services, som er bestilt. 

4.7 Beskrivelse af procedurer i Parknet 

Fælles for procedurerne er, at de er meget arbejdstunge og der er mange 

steder, hvor der er mulighed for at begå fejl. 

4.7.1 Oprettelse af Internet 

1) Slå brugeren op i Winkas og find switchen samt portnummeret 

2) Log ind på switchen via SSH 

3) Aktiver porten og gem 

4) Opdater brugeren i Winkas: 

a. Tilmeldingsdato 

b. Opkræv oprettelsesgebyr 

c. Opkræv abonnement for perioden ind til næste kvartal 

4.7.2 Oprettelse af et telefonnummer 

I beskrivelsen af proceduren herunder, vil punkt 1 kunne udelades, hvis der 

er tale om et indporteret (nummeret flyttes fra en anden udbyder) nummer. 

1) Find et ledigt nummer i Parknet telefonbogen 

2) Find et ledigt lokalnummer i Miralix 

3) Find den Audiocode og port brugeren er tilsluttet til i Winkas 

4) Log ind på Audiocoden og skriv lokalnummeret ind på den rigtige port 

5) Opret brugeren i Miralix (indtast: navn, adresse, Winkas 

kontonummer, e-mail, afregningsform, abonnementstype) 

6) Vælg lokalnummeret og indtast telefonnummeret 

7) Indsæt start taletid (så brugeren kan bruge telefonen) 

8) Opdater brugeren i Winkas: 

a. Tilmeldingsdato 

b. Abonnementstype 

c. Afregningsform 

d. Lokalnummer 

e. Telefonnummer 

f. Miralix kontonummer 

g. Opkræv oprettelsesgebyr og beløb for starttaletid 

h. Opkræv abonnement for perioden ind til næste kvartal 

4.7.3 Oprettelse af TV/ændring af TV pakke 

1) Slå brugeren op i Winkas og find adressen på krydsfeltet 

2) Kør ud til krydsfeltet og tilslut/skift til den ønskede TV pakke 

3) Kør hjem igen og opdater brugeren i Winkas: 

a. Tilmeldingsdato (ændres ej ved pakkeskift) 

b. TV pakke 

c. Opkræv gebyret for oprettelse/skift af pakke 



d. Opkræv abonnement for perioden ind til næste kvartal fordelt 

på Copydan og resten af TV pakkens pris. 

4.7.4 Bookning af teknikerbesøg 

Hvis en bruger ikke kan få afhjulpet sit problem over telefonen, kan 

brugeren få besøg af tekniker. Hvis problemet er forskyldt af Parknet, er 

besøget gratis ellers koster det 250 kr. 

Teknikerbesøg bookes via Google kalender i blokke på 4 timer. P.t. om 

tirsdagen i tidsrummet 16-20. 

4.7.5 Opkrævning 

Hver måned kører bogholderen opkrævninger. Der køres dels de ordinære, 

dvs. brugere som har været oprettet i systemet mere end 1 kvartal. Til 

opkrævninger ud over almindeligt abonnement findes et felt som hedder 

”opkræves skævt”. I dette felt skriver supporteren sine initialer og derefter 

udfyldes feltet ”tekst til skæv opkrævning” med information om, hvad det 

er, brugeren skal betale for fx ”Skift af TV pakke til super”. Der er et antal 

felter til hver service, hvor supporteren kan indtaste de beløb, som 

brugeren skal opkræves i forbindelse med den skæve opkrævning. 

Når opkrævningerne er kørt har Winkas genereret en liste, som sendes til 

PBS. Resten af forløbet sørger PBS for og pengene sættes ind på Parknets 

konto. De brugere, som ikke har betalt, får en rykker samt rykkergebyr og 

der lukkes for brugerens services. Efter tredje rykker ryger sagen til 

inkasso. 

4.7.6 Overdragelse af abonnement 

Abonnementer kan opsiges til udgangen af et kvartal. Hvis kvartalet lige er 

startet og man ønsker at opsige, kan det dreje sig om op til 1.000 kr. for 

hhv. internet, telefon og den største TV pakke. For at pengene ikke skal gå 

tabt, kan brugere vælge at overdrage sit abonnement til den nye beboer. 

De to brugere skal selv afregne differencen, men på den måde får alle 

glæde af abonnementerne plus, at den nye bruger ikke skal betale 

oprettelsesomkostninger. 

Når en service afmeldes sættes udmeldelsesdatoen, dermed betragtes 

servicen som afmeldt. Hvis brugeren senere tilmelder sig igen sættes 

tilmeldelsesdato til den nye dato og udmeldelsesdatoen slettes. Derefter 

bliver det umuligt at se, præcis i hvilken periode brugeren tidligere har 

været tilmeldt. Det er muligt at hente noget brugbar data ud af 

posteringerne, da det vil fremgå hvornår der er betalt og specifikt for hvad. 



4.7.7 Diagram over domænemodellen 

Figur 6 - Domænemodel 

Figur 6 viser, hvordan jeg forestiller mig Parknet ser ud i en domænemodel. 

Nederst til venstre er medlemsforeninger. Disse har brugere, krydsfelter, et 

antal services de kan modtage fra Parknet og har en tilslutningsaftale med 

Parknet. Parknet leverer services jf. tilslutningsaftalen med foreningen, som 

brugerne kan abonnere på hos Parknet. Via administrationssystemerne 

køres opkrævninger, som brugerne betaler til Parknet. Parknet har også 

krydsfelter og igennem disse leveres services til brugerne. 



5 Analyse 

5.1 Kravspecifikation til det nye system 

Ifølge bogen ”Goal directed project management” (5) er det vigtigt for et 

projekts succes, at alle involverede parter føler ejerskab over projektet. 

Derfor er det vigtigt, at brugerne af systemet involveres så tidligt som 

muligt i processen. Det er netop ved udarbejdelse af kravspecifikationen, at 

brugerne første gang bør få mulighed for at komme med forslag og ønsker 

til systemet. 

Kravspecifikationen er skrevet uden direkte input fra Parknets 

medarbejdere. Den er baseret på mine egne oplevelser med systemerne 

igennem 5 måneders praktik samt lige så lang tid som studentermedhjælper. 

Jeg har i den tid hørt mange ønsker og forslag til et nyt 

system, så medarbejderne har indirekte været med til at formulere 

kravene. 

Med ovenstående udgangspunkt har jeg ikke overholdt anbefalingen fra (5) 

til fulde. Jeg har afveget fra anbefalingen, da systemet et eksamensprojekt 

og ikke noget som Parknet har bestilt. 

5.1.1 Funktionelle krav 

Systemet skal samle processerne i forbindelse med styring af netværket, 

services og brugere i Parknet. Administrationen skal automatiseres så 

meget som muligt. Brugerne skal i størst muligt omfang kunne administrere 

egne services via en selvbetjeningsportal. 

Administrationsdelen skal bruges dels til den daglige telefonsupport og til 

administrative rutiner herunder: 

• opkrævning af brugere 

• indrapportering af telefonnumre og adresser til 118 

• oprettelse af services for brugerne 

• slå brugere op og se deres brugeroplysninger 

• administrator skal have adgang til alle services og priser 

I forbindelse med telefonsupport er det vigtigt, at supporteren hurtigt kan 

finde brugeren i systemet via et eller flere søgekriterier (oftest via 

adressen). 

Brugernes selvbetjeningsportal skal bestå af to dele. Den ene skal være til 

oprettelse af nye brugere. Her skal vises de services, Parknet tilbyder på 

den adresse, som brugeren ønsker at tilmelde. Den anden del skal være 

med login og er beregnet til eksisterende brugere. Når brugeren er logget 

ind, skal brugeren kunne ændre/tilvælge/fravælge services samt 

oprette/nedlægge e-mailadresser og foretage intern flytning af sit 

abonnement fra en adresse i Parknet til en anden. 

Alle ændringer/tilmeldinger skal vises i administrationsdelen og godkendes 

af en Parknet medarbejder, før de endeligt udføres. Der skal en 



administrator ind over alle ændringer for at sikre, at brugere ikke tilmelder 

sig på en adresse, hvor der allerede er en tilmeldt bruger, som ikke er 

flyttet. 

Der skal være sikkerhed i systemet, så information ikke falder i hænderne 

på de forkerte personer. 

• Systemet skal have adgang til lagring af data. 

5.1.2 Non funktionelle krav 

Functionality: 

• Separat interface til brugere i Parknet og et andet til 

administrationen. 

• Systemet skal køre på en web server. 

• Systemet skal være skalerbart, dvs. at systemet skal kunne udvides 

og tilpasses til fremtidige ændringer i services. 

• Brugerne skal have adgang til aktuelle services og priser på sin 

adresse. 

Usability: 

• En hjælpefunktion til brugere (evt. FAQ). 

• En manual til personalet. 

Reliability: 

• Afvikling af programmet sker inden for Parknets netværk og fungerer 

uafhængigt af forbindelse til Internettet, reliability er i høj grad til 

stede. 

Performance: 

• Den maksimale svartid på en forespørgsel må være 1 sekund. 

Supportability: 

• PC’en skal have en Internetbrowser. 

• PC’en skal have Internetforbindelse. 

• PC’en skærmopløsning skal være mindst 1280x1024. 

Meningen med SAPS er, at det skal afløse Winkas. Dvs. at al data, som p.t. 

er i Winkas, skal være tilgængelig i SAPS. 



5.1.3 Designvalg 

I forbindelse med udviklingen af systemet har jeg primært lagt vægten på 

programmet og ikke på det fysiske design. Parknet har eksisteret i 5 år, så 

den fysiske opstilling er allerede til stede. 

Figuren herunder viser visuelt, hvordan den fysiske opstilling ser ud. 

Figur 7 – Model af det fysiske design i Parknet 

Resten af rapporten omhandler udviklingen af SAPS. Jeg vil ikke behandle 

det fysiske design yderligere. 



5.2 Analyse af applikationen 

5.2.1 Use case diagram 

I use case diagrammet er der forbindelse fra fire use cases til use case 

”Opret ticket”, det skyldes, at disse use cases automatisk opretter en ticket 

i systemet. 

Administrator 

Supporter 

Bogholder 

Bruger i Parknet 

Anonym bruger på Internettet 

Brugerens adresse 

og services 

Log ind i SAPS 

Opret ticket 

Online tilmelding 

Redigere services 

SAPS 

Ret bruger 

oplysninger 

TV to do liste 

Frameld service 

Tilmeld service 

Figur 8 - Use case diagram 

Opret/fjern 

adresser 

Opret/fjern x-felt 

Opret tlf. nr. 

Ændre bruger 

rettigheder 

Styre services pr. 

adresse 

Styre adresser, 

x-felter og aktivt udstyr 

Ændre service 

Miralix 

Vis saldo på 

telefonkonto 



5.2.2 Aktørbeskrivelser 

Administrator 

• Flere personer kan have denne rolle 

• Skal have adgang til alle data i systemet 

• Skal kunne redigere alle data i systemet 

Supporter 



• Skal kunne redigere visse data i systemet 

Bogholder 



• Skal kunne redigere visse data i systemet 

Bruger 


• Skal have adgang til oplysninger om egne services 

• Skal kunne redigere egne services 

Anonym bruger på Internettet 


• Skal kunne oprette abonnement på sin adresse i Parknet 

5.2.3 Overordnede use case beskrivelser 

• Opret/fjern adresser 

Beskrivelse af hvad administratoren gør for at oprette og slette 

adresser i SAPS. 

• Opret/fjern x-felt 

Beskrivelse af hvad administratoren gør for at oprette og slette 

krydsfelter i SAPS. 

• Opret tlf. nr. 

Beskrivelse af hvad administratoren gør for at tilføje telefonnumre til 

SAPS. 

• Ændre bruger rettigheder 

Beskrivelse af hvad administratoren gør for at redigere brugeres 

rettigheder i SAPS. 

• Styre services pr. adresse 

Beskrivelse af hvordan administratoren til- og fravælger services til 

en forening eller adresser enkeltvist. 



• Styre adresser, x-felter og aktivt udstyr 

Beskrivelse af hvordan administratoren tilføjer og redigerer aktivt 

udstyr i SAPS samt tilknytter aktivt udstyr til x-felter og aktivt 

udstyrs porte til adresser. 

• Redigere services 

Beskrivelse af hvordan administrator eller bogholder redigerer 

eksisterende services samt tilføjer nye. 

• Ret bruger oplysninger 

Beskrivelse af hvordan administrator, bogholder eller supporter 

redigerer en brugers oplysninger (uden mulighed for at ændre 

rettigheder). 

• TV to do liste 

Beskrivelse af hvordan administrator eller supporter bruger to do 

listen og markerer et punkt som ”done”. 

• Brugerens adresse og services 

Beskrivelse af hvad administrator, bogholder eller supporter gør for 

at finde en bruger eller en adresse og ser hvilke services, som er 

tilmeldt samt, hvilke services som kan tilmeldes. 

• Log ind i SAPS 

Beskrivelse af hvordan rollerne logger ind i SAPS 

• Opret ticket 

Beskrivelse af hvordan administrator, bogholder eller supporter 

opretter en ticket i SAPS, samt hvordan visse andre use cases 

automatisk opretter tickets. 

• Online tilmelding 

Beskrivelse af hvordan online tilmeldingen virker og opretter en ny 

bruger i SAPS samt aktiverer valgte services. 

• Ændre service 

Beskrivelse af hvordan en service kan ændres fra use casen 

”Brugerens adresse og services” og samtidig skriver en ticket. 

• Tilmed service 

Beskrivelse af hvordan online tilmeldingen eller use casen 

”Brugerens adresse og services” tilmelder en service til en bruger 

og samtidig skriver en ticket. 

• Frameld service 

Beskrivelse af hvordan en bruger framelder en service og at systemet 

skriver en ticket. 

• Vis saldo på telefonkonto 

Beskrivelse af hvordan SAPS henter brugerens saldo på 

telefonkontoen. 



5.2.4 Detaljerede use case beskrivelser 

Jeg har udvalgt to use cases, som jeg har udarbejdet detaljerede 

beskrivelser for. Den ene er ”Online tilmelding”, da denne er en 

forudsætning for at få nye brugere i systemet og griber ind i mange dele af 

SAPS. Den anden er ”Styre services pr. adresse”, da det kun er 

aktiverede services, som kan vælges på adressen via SAPS og online 

tilmelding. 

5.2.4.1 Use case Online tilmelding 

USE-CASE Online tilmelding. 

Formål At oprette en ny bruger i SAPS og aktivere valgte services. 

Niveau Primær opgave 

Prækondition SAPS er online og der er ikke en aktiv bruger på den valgte 

adresse. 

Postkondition Brugeren er blevet oprettet i SAPS. 

Fejl afslutning Brugeren blev ikke oprettet eller gemt i databasen. 

Primære, 

Sekundære 

Aktører 

Primær: Anonym bruger på Internettet (i det efterfølgende 

omtalt som bruger). 

Trigger En bruger vælger at oprette sig som kunde hos Parknet. 

Hændelsesforløb: 

Trin Handling 

1 Brugeren vælger sit postnr. 

2 Brugeren vælger sin gade 

3 Brugeren vælger sin adresse 

4 Brugeren klikker på Næste 

5 Brugeren indtaster sine personlige oplysninger og vælger services 


7 Brugeren vælger at acceptere Parknets abonnementsvilkår 


9 Brugeren får besked om, at oprettelsen er sket med oplysning om 

brugernummer og password til selvbetjening. Der er desuden link til 

Betalingsservice, så brugeren med det samme kan tilmelde sig til PBS. 

Hændelsesforløb ved fejl: 

Trin Forgrenings handling 

1, 2, 3 Hvis der ikke er oprettet adresser i SAPS, vil det ikke være muligt at 

vælge hverken postnr., gade eller adresse. 

5 Ved forkert udfyldning i et eller flere felter viser SAPS feltet/felterne, 

som er udfyldt forkert, samt forklarer, hvad der er galt. 

6a Brugeren kan ikke klikke på Næste før, der er valgt mindst én service 

og angivet både for- og efternavn. 

6b Hvis brugeren ikke har angivet et telefon nr. eller en mailadresse, får 

brugeren besked om, at Parknet ikke afsender bekræftelse på 

oprettelsen. 

9 Hvis der allerede er en bruger tilmeld på adressen, får den nye bruger 

besked om, at bestillingen er lagt i kø og bliver behandlet hurtigst 

muligt. Brugeren er dog oprettet i systemet og får oplysning om sit 

brugernummer og password. Der er også link til PBS tilmelding. 



5.2.4.2 Use case Styre services pr. adresse 

USE-CASE Styre services pr. adresse. 

Formål At aktivere services på adresser, så brugerne kan vælg dem. 

Niveau Primær opgave 

Prækondition SAPS er online og en administrator er logget ind og har valgt 

siden ”Services pr. adresse”. 

Postkondition Der er oprettet adresser i SAPS. 

Fejl afslutning Den valgte adresse har ikke fået aktiveret de ønskede 

services. 

Primære, 

Primær: Administrator 

Sekundære 

Aktører 

Trigger En administrator vælger at redigere aktive services til en 

adresse. 

Hændelsesforløb: 

Trin Handling 

1 Administrator vælger en adresse i drop down menuen 

2 Administrator klikker på ”Tilføj standard services” 

3 Administrator klikker på ”Fjern service” ved alle de aktive services som 

er i kategorien TV. 

4 Administrator klikker på ”Tilføj service” ved ”Opret TV online” og ”Lille 

pakke” 

Hændelsesforløb ved fejl: 

Trin Forgrenings handling 

1 Menuen er tom, hvis der endnu ikke er tilføjet adresser til SAPS. 

2 Der bliver ikke aktiveret nogle services, hvis standard services ikke er 

defineret. 

3 Hvis der sker en fejl under kommunikation med databasen, bliver den 

valgte service ikke deaktiveret. 

4 Hvis der sker en fejl under kommunikation med databasen, bliver den 

valgte service ikke aktiveret. 



5.3 Analyse af databasen til Parknet 

Et af de større irritationsmomenter ved Winkas er adressesorteringen. Den 

sorterer adresser som strenge. Når opgangsnummeret og etagen er en del 

af strengen medfører det at, 11 og 13 kommer før 3, 5, 7, 9 og at 

stueetagen kommer efter 1., 2. sal osv. 

I Winkas er der kun 100 felter pr. række i standardtabellen for brugere. Alle 

data om adresse, brugerens services, priser, opkrævninger og 

netværkstilslutninger står i en én række. Dette er en meget dårlig løsning, 

da den resulterer i meget unødvendig ekstra data. Når der flytter en ny 

bruger ind, deaktiveres den gamle, men data beholdes af hensyn til 

historik. Dvs. at adressen og netværksdata dubleres, for hver gang der 

oprettes en ny bruger. 

Den optimale løsning er at adresser kun oprettes én gang i én tabel, 

derefter skal der refereres til dem via ID. 

Forventninger til databasens størrelse og omfang: 

• Opstarts størrelse: 

(1) Der er ca. 10.000 adresser i Parknet. 

(2) Der er ca. 9.000 brugere. 

(3) Der er 3 forskellige services. 

• Forventet vækstrate: 

(1) Ca. 2.000 nye adresser pr. år (gennemsnit siden 1/1-04). 

(2) Ca. 100 til- og frameldinger pr. måned (stigende med 

brugerantallet). 

• Sikkerhed: 

(1) Databasen skal være password beskyttet. 

(2) Det er kun webklienten, som har adgang til databasen via http. 

(3) Det er kun muligt at logge på databasen fra Parknets 

management netværk. 

• Backup: 

(1) Der skal køres backup hver dag af databasen. 



6 Design 

SAPS skal være en webapplikation. En af overvejelserne i forbindelse med 

designet har været, om det skal være muligt at udskifte webapplikationen 

med en GUI applikation. Det har ikke været meningen fra starten af og der 

bliver ikke noget lag mellem databasen og SAPS til at styre data flow. 

Derfor vil en ny GUI skulle læse og skrive data i databasen på samme 

måde, som SAPS gør. Når SAPS læser/skriver data i databasen, kommer 

det til at foregå via queries indlejret i koden. Nogle få steder, vil der blive 

kaldt en stored procedure eller et view. Dvs. der vil være meget arbejde i at 

udvikle en GUI. 

En anden stor overvejelse har været validering af input. Det er naturligvis 

vigtigt at sikre, at de input som brugeren taster, stemmer overens med 

datatypen i databasen. Jeg har valgt, at der ikke er validering i SAPS. Det 

er kun Parknets medarbejdere, som har adgang til indtastningsfelter i SAPS 

og jeg betragter dem alle som professionelle mennesker, som ved hvad de 

gør. Derfor vil exception beskeden fra Java, være tilstrækkelig information 

om, hvad der evt. er tastet forkert. I online tilmeldingen skal alle input til 

gengæld valideres og sikres mod SQL injection, script eksekvering og 

lignende. 

Hvor skal arbejdet udføres – i databasen eller i Java? I så stor udstrækning 

som muligt, bør komplekse forespørgsler, lægges i stored procedures. 

Databasen er hurtigere til at kombinere data fra mange tabeller og 

samtidigt udføre evt. beregninger. I forbindelse med online tilmeldingen 

bliver det helt essentielt, at data skrives i databasen med en stored 

procedure, for at undgå sql injection. Derved kommer der ikke fejldata i 

databasen og dermed holder modellen. 

Sikkerheden i systemet skal komme fra REALM’et. Det skal sikre at de 

rigtige brugere har adgang til de rigtige data i SAPS. Hvis et REALM 

vurderes til ikke at være sikkert nok, vil SAPS kunne adskilles i to dele og 

køre på hver sin server i Parknet. Den ene server skal være på 

management LAN (mgt LAN), så vil der kun være adgang via computere på 

mgt LAN (fx dem på Parknets kontor). Den skal køre administrator, 

bogholder og supporter rollerne. Den anden server skal køre bruger rollen 

og være tilkoblet bruger nettet, så alle har adgang til at logge ind. På den 

måde vil en evt. hacker højest kunne få adgang til én brugers oplysninger 

ad gangen. 



6.1 Databasen 

For at få adresser sorteret korrekt, skal alle dele af en adresse indsættes i 

hver sin tabel og efterfølgende knyttes sammen via ID i en anden tabel. På 

den måde kan adresserne sorteres, så fx Tornsangervej 3 står før 

Tornsangervej 11 og stueetagen står før 1. sal. Løsningen er vist på figur 9. 

For at sikre, at data kun står i én tabel, skal der laves relationer mellem 

data via ID. Dette er med til at normalisere databasen og mindske 

datamængden. 

Jeg har taget udgangspunkt i Parknets services og derfor er tabellen, ved 

navn ydelser, en kopi fra Parknets database. Den skiller sig ud fra de øvrige 

tabeller ved at bruge teksten FUnique i stedet for id og derudover være med 

dansk tekst. Anden undtagelse er tabellen med postnumre, som også er på 

dansk. 

6.1.1 Databasediagram 

Efter at have analyseret data (i kapitel 5) og hvordan de skal bruges, skal 

der udarbejdes et diagram til systemet, som er en model af Parknets data 

og indbyrdes relationer. 

Jeg har valgt at dele databasediagrammet op i 3 diagrammer, da ét stort 

ville blive for uoverskueligt. Først viser jeg hvordan adresser sammensættes 

i addressrel tabellen, dernæst hvordan netværksdata knyttes til en adresse i 

addressrel tabellen. I det sidste diagram vises resten af databasen. Fra de 

to foregående diagrammer indgår kun addressrel tabellen. 



6.1.1.1 Addressrel (adresser) og intersections (x-felter) 

Figur 9 - ER-diagram for relationen addressrel med tilhørende tabeller 

Når alle dele af en adresse har et nummer, kan systemet sortere på tal i 

stedet for på strenge. Derfor er der 1 til 1 relation mellem alle delene af en 

adresse med undtagelse af opgangsbogstav, som kan være 0. 

6.1.1.2 Netværkets tabeller er knyttet til tabellen addressrel 

addressrel 

-id {pk} : int 

-roadid {fk} : int 

-stairawyid {fk} : int 

-stairwayletterid{fk} : int 

-floornameid {fk} : int 

-sideid {fk} : int 

-zipcode : int 

* 

addressdata 


-addressrelid {fk} : int 

-datapatch : string 

-telepatch : string 

-tvpatch : string 

-showinet : int 

-addroaddr {fk} : int 

-intersectionid {fk} : int 

add_port_rel 


-add_rel_id {fk} : int 

-intersec_equip_id {fk} : int 

-port : int 

intersections 








1 1 1 1 1 * 

0..1 

intersection_equipment 


-intersection_id {fk} : int 

-equipment_id {fk} : int 

-login_name : string 

-login_password : string 

-serial_number : int 

-start_date 

-name : string 

equipmentlist 



-ports : int 

Figur 10 - ER-diagram for relationen intersections med tilhørende tabeller 

DTU – Danmarks Tekniske Universitet Side 28 af 80 

* 

1 

* 

*


6.1.1.3 Diagram over resten af databasen 

addressrel 








-realestateid {fk} : int 

-tvpack {fk} : int 

add_yd_rel 

-id {fk} : int 

-funique {fk} : int 

* 

* * * 

1 

* 

user_add_rel 

user_svc_rel 



-user_id {fk} : int 


-start_date : date 

-end_date : date 


-funique_current {fk} : int 

-funique_wanted {fk} : int 

-order_date : date 

-done_date : date 



-phone_pay_method {fk} : int 

* 

-miralix_acc_no {fk} : int 

1 

-phone_privacy {fk} : int 

-118_name : string 

-phone_num_type {fk} : string 

users_tabl 

-id {pk} : int 1 

* 

-tlf_authority : tinyint 

-phone_number : int 

-created : string 

-firstname : string 

-lastname : string 

-password : string 

-phone : int 

-cell_phone : int 

-email : string 

-role : int 

-active : tinyint 

-change_date {fk} : int 

* 

1 

user_roles 



* 

* 

wan_ip 



-ip : string 

* 

* 

* 

ydelser 

-funique {pk} : int 

-kode : string 

-navn : string 

-fakturatektst : string 

-engangs : smallint 

-engangspris : double 

-prisangives : double 

-kategori : string 

-medtageinet : smallint 

postnummer 

-postnr {pk} : int 

-bynavn : string 

phone_privacy 



phone_numbers 

-number {pk} : int 

-created_date : date 

-ok_date : datetime 


-status : int 

tickets 



-type_id {fk} : int 

-created_by_id {fk} : int 

-created_time : datetime 

-description : string 

-technician_booking_date : date 

-resolved_by_id : int 

-resolved_date : datetime 

-resolved_description : text 

phone_num_status 



ticket_types 




* 

0..1 * 

0..1 1 

0..1 1 

Figur 11 - ER-diagram for resten af tabellerne 

Adresserne står i addressrel tabellen. Denne er knyttet til brugerne i 

users_table via user_add_rel. Når en bruger flytter ind, sættes start_date 

og når brugeren flytter ud, sættes end_date. Dermed bliver adressen ledig 

til en ny abonnent og Parknet har historik på, hvornår den tidligere beboer 

var tilmeldt. Adresser er knyttet sammen med ydelser via add_yd_rel. Det 

skal sikre, at der ikke tilmeldes en service til en adresse, hvor servicen ikke 

leveres. User_svc_rel er brugerens abonnementer, der er en række i denne 

tabel for hvert abonnement. 

6.1.1.4 Databasens normalisering 

Databasen er normaliseret ud fra Connolly (2). 

For at tjekke om modellen af databasen er i 3NF, kan vi først tjekke om den 

står i 1NF. Da der ikke er nogen tabel som indeholder samme kolonne 2 

eller flere gange og alle grupper af relateret data er sat i hver sin tabel med 

en unik nøgle, kan det konkluderes, at modellen er i 1NF. Data, som kunne 

* 

1 1 

1


have stået i flere tabeller, er sat i separate tabeller og bliver henvist til via 

fremmednøgler. Et eksempel på dette er addressrel tabellen, hvor der 

henvises til adressens ID, i stedet for at have adressen som klar tekst i flere 

tabeller. 

Ud fra ovenstående kan det udledes, at modellen er i 2NF. Til sidst ses det, 

at tabellerne ikke har nogen attributter, som ikke er afhængige af 

primærnøglen. Et eksempel på dette er postnummer og by, da de er 

afhængige af hinanden og derfor ikke begge to behøves at stå i addressrel 

tabellen. Da dette er gældende, kan det konkluderes at databasemodellen 

er i 3NF. 

En positiv sideeffekt, af at modellen er i 3NF, er at ændringer i data, ikke 

har nogen stor indflydelse på databasen. Det skyldes, at der refereres 

mellem tabellerne via ID. 

6.2 SAPS 

Via SAPS er der fri adgang til data i databasen. Derfor kan der hurtigt ske 

fejl, hvis en bruger ved et uheld sletter en datapost med relation til andre 

dataposter. Jeg vælger derfor, at det er meget få steder, hvor data må 

kunne slettes. De steder, hvor det bliver muligt at slette/fjerne rækker i en 

tabel, skal systemet teste på om den pågældende række har 

relation/relationer til andre tabeller i databasen. Hvis det er tilfældet, skal 

”fjern” muligheden erstattes med en tekst om, at det ikke er muligt at 

fjerne rækken pga. at den er i drift eller har relation til andet data. 

Det er vigtigt, at de forskellige roller i systemet ikke kan tilgå hinandens 

filer indenfor REALM’et. Derfor skal hver side teste på om brugerens rolle er 

korrekt, hvis ikke skal brugeren sendes tilbage til en velkomstside, som 

bliver fælles for alle roller. 

6.3 Online tilmelding 

Designet af online tilmeldingen tager udgangspunkt i en meget primitiv 

udgave, som jeg udviklede mens jeg var i ingeniørpraktik hos Parknet. 

I online tilmeldingen er det vigtigt at programmet ikke går ned, ikke kan 

hackes og kommer med brugbare fejlmeddelelser til brugeren, hvis der er 

angivet et forkert input. Brugerne af online tilmeldingen kan ikke 

sammenlignes med brugerne af SAPS. Derfor skal den være så intuitiv som 

mulig og have så få valgmuligheder som muligt. 

Derudover er det vigtigt, at online tilmeldingen har en grafisk brugergrænseflade 

og at felter og informationer er sat overskueligt op. Billeder til 

grafik og design skal lægges i en separat folder. 

Brugerne skal hele tiden kunne se, hvor langt de er nået i oprettelsesprocessen 

via en trinindikator. Der skal være separate kasser/bokse til hver 

service for at lette overskueligheden. Som afslutning skal brugeren have 

mulighed for at tilmelde sig PBS. 



6.4 Sitemap over SAPS og online tilmelding 

Da jeg endnu ikke har det fulde overblik over behovet for filer eller 

navngivning af disse, har jeg valgt at tegne mappestrukturen i og udenfor 

REALM’et. Filen login.jsp ligger uden for REALM og ved korrekt login får 

brugeren adgang til welcome.jsp. Derfra vil adgang til de forskellige 

biblioteker være styret af REALM’et ud fra brugerens rettigheder. 

ROOT 

Authorized_users 

Inde i REALM 

Opret 

Welcome.jsp 

AccountantArea 

AdministratorArea 

SupporterArea 

UserArea 

Filer uden for REALM 

Online opret filer 

Bogholder filer 

Administrator filer 

Supporter filer 

User filer 

Figur 12 - Sitemap over designet 



6.4.1 Designklassediagram SAPS 

Designklassernes navne tager udgangspunkt i use case beskrivelserne fra 

kapitel 5.2.3. 

designklasse: opret/fjern adresser 

designklasse: opret/ændre bruger 

designklasse: opret/fjern x-felt 

designklasse: opret tlf. nr. 

designklasse: service pr. adresse 

addressrel 

-id : int 

-roadid : int 

-stairawyid : int 

-stairwayletterid : int 

-floornameid : int 

-sideid : int 


-realestateid : int 

-tvpack : int 

users_table 

-id : int 





-phone : int 



-role : int 

-inactivated_date : datetime 

-end_date : datetime 

intersections 

-id : int 

-roadid : int 




-sideid : int 


phone_numbers 

-number : int 




-status : int 

add_yd_rel 

-id : int 

-funique : int 

add_port_rel 

-id : int 

-add_rel_id : int 

-intersec_equip_id : int 

-port : int 

user_add_rel 

-id : int 

-user_id : int 




user_svc_rel 

-id : int 


-funique_current : int 

-funique_wanted : int 





-phone_pay_method : int 

-miralix_acc_no : int 

-phone_privacy : int 


-phone_num_type : string 



-change_date : int 

designklasse: TV to do liste 

Figur 13 - Designklassediagram for SAPS 

designklasse: vis telefonsaldo 

designklasse: brugerens adresse og services 

designklasse: ændre service 

designklasse: opret ticket 

tickets 

-id : int 


-type_id : int 

-created_by_id : int 


-description : string 


-resolved_by_id : int 



Jeg forestiller mig, at designklasserne til SAPS læser og skriver data i 

tabellerne jf. figur 13. Opret ticket kan kaldes af brugeren og bliver kaldt af 

to andre klasser, når systemet har brug for at oprette en ticket. 



Designklassediagram online tilmelding 

designklasse: trinindikator 

designklasse: adressevælger 

designklasse: vælg abonnementer 

designklasse: validering 

designklasse: indtast brugeroplysninger 

addressrel 

-id : int 

-roadid : int 




-sideid : int 


-realestateid : int 

-tvpack : int 

add_yd_rel 

-id : int 


ydelser 


-kode : string 

-navn : string 

-fakturatektst : string 




-kategori : string 


designklasse: opret bruger 

add_port_rel 

-id : int 


-intersec_equip_id : int 

-port : int 

user_svc_rel 

-id : int 


-funique_current : int 

-funique_wanted : int 





-envoice_name : string 

-envoice_add : string 

-envoice_zip : int 

-phone_pay_method : int 

-miralix_acc_no : int 

-phone_privacy : int 


-phone_num_type : string 



-change_date : int 

Figur 14 - Designklassediagram for online tilmelding 

designklasse: SNMP 

user_add_rel 

-id : int 





users_table 

-id : int 





-phone : int 



-role : int 



Jeg forestiller mig, at designklasserne til online tilmelding læser og skriver 

data i tabellerne jf. figur 14. Der vises adresser i adressevælgeren fra 

addressrel tabellen. Add_yd_rel sikrer, at der kun vises de services, som 

kan vælges på adressen. Når brugeren oprettes, bliver der oprettet 

abonnementer i user_svc_rel på de valgte services og brugeren bliver 

knyttet til adressen via user_add_rel. Hvis brugeren har valgt Internet 

abonnement åbnes for Internet med det samme via SNMP kommando 

(simuleres). 



7 Implementering 

Implementeringen af koden til SAPS er gjort færdig, før jeg begyndte på 

online tilmelding. I SAPS har jeg taget udgangspunkt i min viden om JSP og 

fortsat derfra. Da jeg begyndte på online tilmeldingen tog jeg udgangspunkt 

i en primitiv version 1 (udviklet i min ingeniørpraktik hos Parknet). Den 

eneste funktion som er taget med til version 2 er stripHTML(). Tankegangen 

og måden at implementere på med funktionskald, har bragt 

implementeringen af online tilmelding i en noget anden retning end SAPS. 

Koden til de to dele ligner umiddelbart ikke hinanden. Til gengæld viser de 

på hver sin måde, hvordan et design kan implementeres og komme til at 

fungere. 

Hen mod afslutningen af implementeringen, da online tilmeldingen og SAPS 

skulle forenes, har jeg dog implementeret nogle funktioner som deles af 

begge koder. Disse funktioner er i filer, som ligger i roden af webserveren. I 

forhold til sikkerhed er det ikke noget problem, at filerne er uden for 

REALM, da de ikke kan ses i browseren. Desuden skal funktionerne kaldes 

med de rigtige argumenter for at fungere. 

SAPS bruger views og stored procedures (SP) i nogen grad. I online 

tilmeldingen er det meget få steder at jeg bruger views og SP, resten køres 

med indlejrede queries i koden. Denne tilgang er valgt for, at online 

tilmeldingen hurtigt kan tilpasses til Winkas og sættes i drift i Parknet. Husk 

at Winkas kører på MySQL 4.0.18 (som hverken understøtter views eller 

SP). 

Da tabellen ved navn ydelser fra Winkas blev føjet til systemet, blev min 

konvention om kun at bruge engelske navne brudt, det gælder også for 

funktionskald (da nogle af dem henter data i ydelser fx getFakturaTekst()). 

7.1 Databasen 

Komplet datakatalog kan ses i filen /kode/db/datakatalog.doc på cd-rom’en 

I forhold til designet har det været nødvendigt at tilføje TV pakke til 

adressen, dette er gjort fordi, der kun kan være én TV pakke pr. adresse og 

fordi det er adressen som har TV pakken, brugeren betaler ”bare”. 

Derudover blev der også behov for at implementere 3 nye felter til 

user_svc_rel. Disse felter er til alternativ betaler og faktureringsadresse. På 

nuværende tidspunkt oprettes der to brugere i Winkas på den samme 

adresse. Hver af brugerne betaler så for de respektive services. Fremover 

bliver det ikke nødvendigt. 

Da brugerens ID fra tabellen users_table skal bruges som loginnavn, fandt 

jeg det ikke hensigtsmæssigt at lade den starte fra 1 og arbejde sig op. 

Derfor er startværdien sat til 11111111 og systemet autoinkrementerer 

derfra. 



7.1.1.1 Addressrel og intersections 

Figur 15 - Implementeringen af relationen addressrel med tilhørende tabeller 

Jeg har tilføjet tvpack i addressrel tabellen, da TV pakken følger adressen 

uafhængigt af brugere. 



7.1.1.2 Netværket 

Figur 16 - Implementeringen af relationen intersections med tilhørende tabeller 

Der er ikke sket ændringer til disse tabeller. 



7.1.1.3 Resten af databasen 

addressrel 








-realestateid {fk} : int 

-tvpack {fk} : int 

user_add_rel 






users_table 


-created : varchar 

-firstname : varchar 

-lastname : varchar 

-password : varchar 

-phone : int 


-email : varchar 

-role : int 



* 

1 

user_roles 


-name : varchar 

1 

* 

* 

1 

* 

* 

wan_ips 



-ip : varchar 

end_dates start_dates 

-id {pk} : int -id {pk} : int 

-navn : varchar -navn : varchar 

add_yd_rel 



-dato : int -dato 

* * * 

cutting_dates 


-navn : varchar 

-dato : int 

* 

* 

1 

* 

user_svc_rel 

-id {pk} : int = 11111111 


-funique_current {fk} : int 

-funique_wanted {fk} : int 





-envoice_name : varchar 

-envoice_add : varchar 

-envoice_zip : int 

-phone_pay_method {fk} : int 

-miralix_acc_no {fk} : int 

-phone_privacy {fk} : int 

-118_name : varchar 

-phone_num_type {fk} : varchar 



-change_date {fk} : int 

payments 


-fakturatekst : varchar 

-pris : double 


-client_name : varchar 

-client_add : varchar 

-client_zip : int 

-date_added : datetimetime 

-date_payment : date 

-date_payed : date 

-term_start_date : date 

-term_end_date : date 

* 

* 

0..1 1 

standard_services 


* 

* 

ydelser 

-funique {pk} : int 

-kode : varchar 

-navn : varchar 

-fakturatektst : varchar 




-kategori : varchar 


postnummer 

-postnr {pk} : int 

-bynavn : varchar 

phone_privacy 



phone_numbers 

-number {pk} : int 




-status : int 

tickets 



-type_id {fk} : int 

-created_by_id {fk} : int 


-description : varchar 


-resolved_by_id {fk} : int 



ydelser_farver 


-kode : varchar 

-farve : varchar 

ydelser_copydan 


-fakturatekst : varchar 


phone_num_status 



ticket_types 




* 

0..1 1 

0..1 1 

* 

1 

* 1 

1 1 

validation_patterns 




-mib : varchar 

-function : varchar 

Figur 17 - Diagram for implementeringen af resten af tabellerne 

mibs 

1 



-email_wish : varchar 

-tlf_type_id {fk} : int 

-num_type_id {fk} : int 

-tlf_pay_id {fk} : int 

-pack_id {fk} : int 

-start_id {fk} : int 

-int_adm_id {fk} : int 

-inet_price_id {fk} : int 

-tlf_adm_id {fk} : int 

-tv_adm_id {fk} : int 


-date_created : datetime 

-date_done : datetime 

1 

user_wishes 

Jeg har tilføjet de stiplede tabeller. De tre i højre side, har ikke relationer, 

men bruges af online tilmelding i forbindelse med validering, SNMP og 

tilmelding. Payments knytter sig til brugeren og brugerens services, derfor 

er den placeret imellem disse. De tre stiplede i toppen er hhv. end_dates, 

start_dates og cutting_dates. Disse er alle tre afgørende for, hvilken dato et 

abonnement kan starte fra (start_dates) og slutte til (end_dates). Imellem 

disse vil cutting_dates skulle afgøre, hvilken start eller slut dato, som er 

mulig i forhold til dags dato. 

I users_table er feltet active skiftet ud med to datofelter hhv. 

inactivated_date og end_date. Active værdien bliver sat afhængig af om 

end_date er overskredet i forhold til dags dato. Funktionaliteten er 

forberedt til, når brugere opsiger alle services for at flytte fra sin adresse i 

Parknet. Så vil inactivated_date blive sat til den dato, hvor brugeren 

opsiger, mens end_date vil blive sat til den dato, hvorfra brugeren ikke 

længere har adgang til SAPS. 

Den stiplede streg mellem add_yd_rel og user_svc_rel, skal vise, at 

brugeren kun kan abonnere på services, som leveres på adressen.


7.1.2 Stored Procedures 

Navn Argument(er) Output 

getServices (input_address) ResultSet 

insert_user 

(input_firstname, input_lastname, input_password, 

input_phoneno, input_cellphoneno, input_email) 

(input_userNumber, input_address, input_email_wish, 

input_tlfTypeId, input_numTypeId, input_tlfPayId, input_packId, 

void 

insert_user_in_temp input_startId, input_user_internet_adPriceId, 

input_user_internet_monthPriceId, input_user_tlf_admPriceId, 

input_user_tv_admPriceId) 

void 

numbers () ResultSet 

portations () ResultSet 

to_do () ResultSet 

todo_tv () ResultSet 

usersintemp () ResultSet 

Den stored procedure (SP) kaldet getServices bruges til at hente, hvilke af 

Parknets tre services, der kan vælges på det adresse id, som proceduren 

kaldes med. 

De to SP til insert, bruges primært for at sikre, at databasen ikke bliver SQL 

injected. Insert_user bruges af online tilmeldingen, når der ikke er en aktiv 

bruger på adressen, ellers bruges insert_user_in_temp. Den tager flere 

argumenter end insert_user, da alle brugerens valg skal gemmes. 

De sidste SP bruges til sammentælling af de punkter, som skal præsenteres 

på velkomstsiden i REALM. 

7.1.3 Views 

Navn Output 

address_showinet id, roadid, adresse, postnr, forening, showinet 

address_view id, roadid, stairid, adresse, postnr, forening, TVpakke 

intersection_view id, blok, vej, nr., adresse, postnr 

users id, initials, name, role, password 

Viewet address_showinet viser de adresser, som har fået sat showinet = 1. 

Det bruges i online tilmeldingens adressevælger. 

address_view bruges alle steder i SAPS, hvor der skal vises en adresse. Den 

sørger for at sammensætte adressen fra de forskellige tabeller og vise den 

som en streng. 

intersection_view viser krydsfelter i SAPS, sat sammen af blok nr. og 

opgangs nr. samt adressen og post nr. 

users er et view som bruges af REALM i forbindelse med login. Det er 

felterne initials, name, role og password som bruges. Jeg har valgt, at login 

kører via bruger id i stedet for initialer. Derfor vises det samme tal i både id 

og initials. 



7.2 Sitemap over SAPS og online tilmelding 

Jeg har valgt at indsætte sitemappet over implementeringen før jeg 

beskriver filerne, for at lette forståelsen. 

Der er kommet nogle tilføjelser siden designfasen. Der er oprettet en folder 

til billeder af krydsfelterne, for at billedefilerne ikke bliver rodet sammen 

med resten af SAPS. Desuden krævede grafikken til online oprettelse 

billeder, som også har fået sin egen folder. 

Figur 18 - Sitemap over implementerede filer 



7.3 SAPS 

Enkelte filer med basal funktionalitet bliver delt mellem SAPS og online 

tilmelding, de ligger i ROOT og bliver beskrevet i dette afsnit sammen med 

filerne til SAPS. 

7.3.1 Beskrivelse af de forskellige JSP filer 

Sti: /ROOT/ (filerne db, pay_tools og snmp er fælles med online 

opret) 

Filnavn: Beskrivelse: 

Skaber forbindelse til de to databaser hhv. localhost og Miralix (forudsætter at 

serveren har adgang gennem Parknets firewall til Miralix). Alle øvrige filer som 

bruger databaserne inkluderer denne fil. 

db 

Indeholder følgende funktioner: 

getUsername (henter et brugernavn ud fra ID) 

getColor (henter en farve ud fra en service ID) 

getDate (henter en startdato ud fra ID) 

Rummer HTML tags som skal stå i starten af alle de sider, som brugeren skal se. 

design_start 

Ved at inkludere denne i starten af alle filer, kan overskrift o.l. rettes ét sted. 

Rummer afslutnings tags til HTML og skal inkluderes i slutningen af alle de filer, 

design_end 

hvor design_start er inkluderet i starten. 

findUserRole Finder brugerens rolle. 

index Velkomst side uden for REALM. 

login Login i REALM via brugernummer og password. 

loginerror Vises hvis login mislykkedes. 

logout Invaliderer brugerens nuværende session, så nyt login bliver påkrævet. 


insertCreateFee (indsætter oprettelsesgebyr i tabellen payments) 

insertUserSvcRel (indsætter Internet service i tabellen user_svc_rel) 

pay_tools 

insertUserSvcRelTlf (indsætter telefon service i tabellen user_svc_rel) 

insertUserSvcRelTv(indsætter TV service i tabellen user_svc_rel) 

getFakturaTekst (henter servicens fakturatekst fra tabellen ydelser) 

getFakturaNavn (henter servicens navn fra tabellen ydelser) 


snmp_via_add (udfører den ønskede SNMP kommando, ud fra adresse ID) 

snmp 

snmp (udfører den SNMP kommando ud fra switch ID og port nr.) 

SNMP kommandoerne som kan vælges er: status, åben og luk. 

P.t. køres kommandoerne kun simuleret som print til server console. 

Sti: /ROOT/authorized_users 


design_start 

Samme som i ROOT, dog med den tilføjelse af denne fil 

findUserRole.jsp, således at menuen kan tilpasses brugerens rolle. 

inkluderer 

design_end Samme som i ROOT. 

Velkomstside til alle roller som har adgang til systemet. Inkluderer 

welcome 

findUserRole.jsp, så der kan præsenteres data afhængig af brugerens rolle. 

Almindelige brugere får vist deres abonnementer med mulighed for framelding. 

Alle andre får vist antal punkter på to do listerne, porteringer, tilmeldinger og 

antal telefonnumre i Parknet. 

Sti: /ROOT/authorized_users/AccountantArea 


accountant_tools 

Viser start datoer, slut datoer og skæringsdatoer og giver mulighed for 

ændringer. 

Søger på adresser i SAPS via indtastning af en del af vejnavnet, søgningen kan 

address_search indsnævres ved også at angive et opgangsnummer. Når resultatet af søgningen 

vises, kan man klikke på en adresse, hvorved user_add_svc_show bliver kaldt. 

copydan Viser priserne for copydan delen af en TV pakke og giver mulighed for at rette. 

design_start 

Desværre er denne fil nødvendig igen, for at holde stien rigtig, da brugeren nu er 

et niveau længere inde i REALM’et. 



design_end Det samme som ovenstående. 

functions 

Indeholder p.t. 37 funktioner som bruges af de øvrige JSP filer til at oprette, 

slette og redigere data i databasen. 

payments Viser data i tabellen payments. 

services 

Viser data i tabellen ydelser (dvs. Parknets services) med mulighed for at 

redigere. 

Viser oplysninger om adressen: 

- tilmeldt bruger 

user_add_svc_show 

- 

- 

tilmeldte services og deres status 

tickets 

- mulighed for ændring af TV servicen 

- mulighed for at åbne/lukke Internet port 

users_limited 

Viser alle brugere i systemet sorteret efter brugerrolle og fornavn. Der er 

mulighed for at rette navne, telefonnumre og e-mail. Det er kun administrator 

som kan rette brugerens rolle og aktivere/inaktivere brugere. 

Sti: /ROOT/authorized_users/AdministratorArea 


accountant_tools Kopi af filen fra AccountantArea. 

Når brugeren har valgt en vej fra drop down menuen vises alle adresser på den 

address_data 

vej. Ud for hver vej kan man angive x-felt data, dvs. patchpanel nr., navn på xfelt 

og om adressen skal vises i online tilmeldingen. 

Når brugeren har valgt en vej fra drop down menuen vises de adresser som har 

tilknyttet aktivt udstyr. 

address_ports Der er mulighed for at tilføje nye tilknytninger mellem adresser og aktivt udstyr 

ved at vælge adresse, udstyrets navn og portnummeret (antallet af porte er 

styret af udstyrets navn fx 8, 24 eller 48). 

address_search Kopi af filen fra AccountantArea. 

Viser hhv. foreninger, veje, etager, etagesider, opgangsbogstaver og 

address_tools opgangsnumre i SAPS. Der er mulighed for at rette og tilføje nye. Der kan ikke 

slettes. 

copydan Kopi af filen fra AccountantArea. 

Fra drop down menuen kan vælges de veje som er i systemet. Hvis der er 

adresser på vejen, kan disse fjernes – forudsat at der ikke er tilknyttet services 

til adressen. Hvis der ikke er adresser på den pågældende vej, kan der tilføjes 

nye serier ved at angive: 

Vej 

create_address 

Nr. fra og til (der oprettes kun hver anden, fx 1, 3, 5) 

Opgang fra og til (hvis der er bogstaver i opgangsnumrene ellers blank) 

Etage fra og til 

Antal sider (hvis der angives 2, bliver tv. og th. brugt, ved flere er det med nr.) 

Post nr. 

Foreningen, som adresserne hører til 

Når der klikkes på ”Tilføj” oprettes alle adresser i det ønskede interval. 

design_start Kopi af filen fra AccountantArea. 

design_end Kopi af filen fra AccountantArea. 

Fra drop down menuen vælges imellem krydsfelter i SAPS. Hvis der er aktivt 

equip_in_int 

udstyr i det valgte krydsfelt, vises det med mulighed for at rette. Der er mulighed 

for at tilføje nyt udstyr ved at angive navn, login, password, serienr, type og 

skrive en start dato. 

equipment 

Liste over aktivt udstyr. Listen kan redigeres og nyt udstyr kan tilføjes. Det er 

ikke muligt at slette. 

functions Kopi af filen fra AccountantArea. 

Viser krydsfelter i SAPS. Der kan vælges mellem veje eller blok nummer. Hvis der 

er et krydsfelt, kan man ved at klikke på adressen se et kort over krydsfeltets 

intersections 

placering. Hvis der ikke er tilknyttet aktivt udstyr til krydsfeltet, kan det fjernes. 

Der er mulighed for at tilføje nye krydsfelter til systemet. Husk at lægge en 

billedfil i /images. 

mib 

Viser de MIB strenge som bruges til SNMP kommandoerne: status, åben og luk. 

Strengene kan redigeres. 

payments Kopi af filen fra AccountantArea. 

Viser alle telefonnumre i SAPS, sorteret efter nummer. Der er mulighed for at 

phone_numbers 

rette nummerets status fx fra ”på vej ind” til ”OK”. Der er også mulighed for at 

tilføje nye numre, enten som serie eller som enkelt nummer (skriv det samme 

nummer i både ”første nummer” og ”sidste nummer”). 

Viser de statusser et telefonnummer kan have i systemet. Statussen kan rettes 

phone_tools 

og der kan tilføjes nye. Der kan desuden rettes i hemmeligt nummer 

mulighederne og tilføjes nye. 



services Kopi af filen fra AccountantArea. 

Viser alle services fra tabellen ydelser. Ud for hver ydelse kan man vælge om 

servicen kan vælges til den adresse, som man har valgt i drop down menuen. 

services_address Status er vist med rød eller grøn farve. Der er mulighed for at klikke på knappen 

”Tilføj standard services”, hvorved alle services defineret som ”standard services” 

tilføjes adressen. 

Viser farver til services. Der er mulighed for at redigere farverne. Farverne skal 

services_color 

tastes i tekst som lovlige HTML farver. 

Viser drop down menu, hvorfra man kan vælge foreninger i SAPS. Når man har 

services_realestate valgt en forening, kan man tilføje ”standard services” til alle adresser i foreningen 

ved at klikke på ”Tilføj standard services”. 

Viser alle services fra tabellen ydelser. Ud for hver ydelse kan man vælge, om 

std_services 

den skal være en del af definitionen ”standard services”. Status er vist med rød 

eller grøn farve. 

ticket_tools Rediger ticket typer i systemet og tilføj nye. 

Viser en liste over pakkeskift som skal udføres. Listen er sorteret efter dato, 

postnr., krydsfelt og adresse. På den måde vises de mest presserende først, 

sorteret efter postnr., så man kan vælge kørsler efter geografien. Dernæst er det 

todo_tv 

nemmest, når kørslerne er samlet pr. krydsfelt. 

user_add_svc_show 

Der er en done knap, som fjerner rækken fra listen. Der er INGEN undo funktion, 

så knappen skal kun bruges NÅR pakkeskiftet er udført. 

Kopi af filen fra AccountantArea. 

user_roles Viser brugerroller i systemet (kan ikke ændres). 

Den fulde udgave af filen fra AccountantArea. Der kan oprettes nye brugere. Alle 

users 

oplysninger om eksisterende brugere kan rettes og brugeren kan 

validation 

aktiveres/deaktiveres. 

Viser valideringsstrenge som bruges i online tilmeldingen til validering af hhv. 

navne, e-mailadresse og telefonnumre. 

Sti: /ROOT/authorized_users/SupporterArea 


address_search Kopi af filen fra AccountantArea. 



functions Kopi af filen fra AccountantArea. 

todo_tv Kopi af filen fra AdministratorArea. 

user_add_svc_show Kopi af filen fra AccountantArea. 

user_roles Kopi af filen fra AdministratorArea. 

users_limited Kopi af filen fra AccountantArea. 

Sti: /ROOT/authorized_users/UserArea 




functions 

Kopi af filen fra AccountantArea, hvor alle ikke-relevante funktioner er slettet. 

Dvs. der kun er funktion til opsigelse. 

Brugeren kan opsige sit abonnement ved at vælge opsigelsesdato og dernæst 

terminate 

klikke ja. Derefter vises abonnementet som værende aktivt indtil 

opsigelsesdatoen. 



Beskrivelse af udvalgte funktioner i SAPS: 

Tilføj adresseserie – mode 5 i functions.jsp 

Der køres en for-løkke for intervallet af opgangsnumre, hvor der lægges 2 

til pr. gennemløb. For hvert gennemløb inde i denne køres for-løkker til hhv. 

opgangsbogstaver og etager. Afhængigt af hvor mange sider, der skal 

tilføjes pr. etage er der tre forskellige muligheder for, hvordan data skrives i 

tabellen addressrel. 

Hvis der kun er 1 side, skrives der ikke data sideid feltet. 

Hvis der er 2 sider, skrives 1 eller 2 i sideid feltet. 

Hvis der er flere end 2 sider, skrives fra 3 og op i sideid feltet. 

På den måde passer det med, at 1 og 2 bliver læst til tv. og th. og at tal 

større end 3 bliver læst til -1, -2 osv. 

Aktiver/deaktiver en bruger – mode 26 i functions.jsp 

For administrator ser det ud som om en bruger ”bare” har et aktiv flag. 

Sådan fungerer det ikke i databasen. Her er to felter inactivated_date og 

end_date. Hvis administrator sætter active til 0, skrives NOW() i begge 

felter. Hvis administrator sætter active til 1, skrives NULL i begge felter. 

Indsæt TV service hos en bruger – mode 32 i functions.jsp 

Der indsættes den valgte TV service i user_svc_rel 

Der indsættes oprettelsesgebyr i payments 

Der oprettes en ticket 

Tilføj standard services til en forening 

Funktionen vælger alle adresse ID’er fra den pågældende forening. Dernæst 

vælges alle ID’er fra standard services. Så tjekkes om adresse ID og service 

ID står i tabellen add_yd_rel, hvis ikke indsættes den nye relation. På den 

måde sikres det, at en relation aldrig optræder to gange. Hvis den gjorde, 

ville det kunne ses i online tilmeldingen, hvor TV pakkerne fx ville stå to 

gange. 



7.4 Online tilmelding 

7.4.1 Beskrivelse af de forskellige JSP filer 

(der bruges funktioner fra filerne db, pay_tools og snmp i /ROOT) 

Sti: /ROOT/opret 


address 

Funktioner til at vise adressevælgeren til brugeren i trin 1, adressevælgeren er 3 

trins, først vises postnummervælger, når brugeren har valgt postnummer vises 

gadevælger, når der er valgt gade vises til slut adressevælgeren og ”næste” 

knappen. 

Funktioner til at vise de forskellige bokse i trin 2 samt hjælpefunktioner til at 

hente navne og priser på services, datoer, passwordgenerator og indsættelse af 

det nye medlem i databasen. 

Trin 2 - getAllServices() 

Trin 2 - getName() 

Trin 2 - getInternet() 

Trin 2 - getPhone() 

Trin 2 - getTelevision() 

Trin 3 - getConfirmChoises() 

Trin 4 - getDone() 

boxes 

Hjælpefunktioner som kaldes af de ovenstående: 

getNoService() 

writeNewMember() 

getUserCreated() 

setUserInTemp() 

getErrorWhileCreatingUser() 

getServiceName() 

getStartName() 

getPrice() 

getCityName() 

getNewMemberNumber() 

getPassword() 

Visning af de forskellige bokse med næste og tilbage knapper 

getForwardBtn() 

buttons 

getForwardBakcBtnStep3() 

getForwardBackBtn() 

Rummer HTML tags og JavaScript funktioner som bruges af opret.jsp. Det er p.t. 

kun opret.jsp, som inkluderer design_start, men for overskueligheden skyld og 

segmentering af koden, giver det god mening at have det skilt ud i en separat fil. 


doToggleService() 

design_start 

toggleService() 

toggleStep3() 

initStep2() 

init() 

charCount() 

setBtnNext() 

design_end Rummer HTML afslutnings tags. 

Funktioner til validering af brugerens input 

stripHTML() 

functions 

validateServiceId() 

validateStartId() 

getServices Bruges til at finde ud af, hvilke af Parknets 3 services, som er aktive på adressen. 

Online tilmeldingens hovedfil - bruger funktioner fra alle de andre filer. Bruges til 

opret 

at vise korrekte bokse til brugeren, validere input og gemme brugeren i 

databasen. 

stepIndicator Viser boksen med trinindikatoren. 

Generelt om alle funktionerne, der har med output til skærmen at gøre, kan 

det siges, at de returnerer en streng. Strengene er formateret pænt og alle 

linjer afsluttes med \n, som sørger for at kodens formatering er magen til i 

browseren, når nogen vælger ”vis sidens kildekode”. 



De funktioner som kører databasekald tager altid et statement som 

argument, hvis det er nødvendigt at køre flere databasekald inde i 

hinanden, skal der bruges et tilsvarende antal statements i funktionskaldet. 

Opret.jsp er inddelt i de samme 4 trin som brugeren ser ved tilmelding. 

Opret.jsp kan sætte flueben i boksene i trin 2 via JavaScript i linje 486-493. 

Beskrivelse af udvalgte funktioner: 

getAddressChooser() 

Sørger for at vise adressevælgeren til brugeren. Der køres en onchange på 

postnummer vælgeren, så siden automatisk opdateres, når brugeren har 

valgt et postnummer. Dernæst vises gadevælger, efter valg af gade vises 

adressevælger og næste knap. 

getName() 

Viser indtastningsfelter til brugerens navne, tlf. nr. og nuværende e-mail. I 

de to navnefelter køres charCount() ved keyup, dvs. funktionen køres, for 

hver gang brugeren slipper en tast. Når der står mindst 2 bogstaver i hhv. 

fornavn og efternavn forsvinder teksten om, at brugeren skal skrive for- og 

efternavn, før du kan klikke næste. 

getPhone(), getInternet() og getTelevision() 

Viser en boks til brugeren, hvori den pågældende service kan vælges. Når 

fluebenet til servicen markeres, køres JavaScript funktionen 

toggleService(). Den sørger for, at felterne til servicen aktiveres, så 

brugeren kan vælge disse. Felterne aktiveres via deres ID. Samtidigt fjernes 

teksten om at der skal vælges mindst én service, før du kan klikke næste. 

getDone() 

Opret.jsp sætter en sessionvariabel (”done”), når brugeren er oprettet. For 

hvert step bliver denne variabel testet og hvis den er sat kaldes getDone(). 

Funktionen bruges, hvis en bruger efter tilmelding har brugt tilbage 

knappen i browseren og derefter klikker på næste eller tilbage knappen i 

online tilmeldingen. 

getNoService() 

Kaldes hvis den pågældende service ikke tilbydes på den valgte adresse. 

Beskrivelse af udvalgte JavaScript funktioner i design_start: 

function doToggleService(svc, val) 

Funktionen bruges til at aktivere felterne og fluebenet i en valgboks til en 

service. De tre cases i funktionen er til hhv. Internet, telefon og TV. I hver 

case styres de felter/drop down menuer som aktiveres/deaktiveres via 

deres ID. Desuden styres teksten om, at du skal vælge en service osv. og 

funktionen setBtnNext ud fra, om der er valgt nogen service. Når en service 

vælges/fravælges bliver der lagt 1 til eller trukket 1 fra variablen 

svcsenabled. Hvis denne variabel er større end nul, køres setBtnNext med 

1, hvis den er 0 køres setBtnNext med 0 og ellers køres funktionen ikke. 



If sætningen som tester værdien af val er meget kompakt og resultatet 

bliver lagt direkte ind i svcsenabled. 

Linjen ser således ud: 

svcsenabled += val ? 1 : -1; 

Skrevet på lang form ville den se således ud: 

if (val == true) 

{ 

svcsenabled + = 1; 

} 

else 

{ 

svcsenabled += -1; 

} 

Syntaksen for den korte form af if sætningen, går igen i mange af de andre 

funktioner. 

function toggleService(svc, elm) 

Funktionen kalder doToggleService. Denne funktion bruges, når brugeren 

sætter/fjerner fluebenet ved servicen. Den er nødvendig for at kalde 

doToggleService med korrekt værdi, fluebenet laves om til 0 eller 1. 

function toggleStep3(val) 

Funktionen styrer, at knappen ”næste” i trin 3 først vises, når brugeren har 

klikket ja til at acceptere Parknets abonnementsvilkår. 

function initStep2() 

Funktionen bruges, hvis brugeren klikker tilbage i trin 3, til at aktivere de 

services som brugeren har valgt tidligere. Funktionskaldet fra opret.jsp 

rummer servicen som boolsk værdi. Funktionen kalder charCount og 

doToggleService. 

function init() 

Funktionen kaldes når opret.jsp er i trin 2. 

function charCount() 

Funktionen tæller antallet af tegn i felterne til fornavn og efternavn. Når 

antallet af tegn i begge felter er større end 1 kaldes funktionen setBtnNext 

med 1 ellers med 0. 

function setBtnNext(caller, val) 

Funktionen bruger input fra hhv. charCount og doToggleService til at 

aktivere/deaktivere knappen ”næste” i trin 2. Hvis begge funktioner har 

kaldt setBtnNext, aktiveres knappen. 



7.4.2 State diagram 

Figur 19 - Statediagram for online tilmeldingen 



7.5 Implementeret og ikke-implementeret: 

Jeg har valgt at lave en liste med implementerede funktioner samt de 

oprindelige fra mit projektoplæg (vises med + for oprindelig og – for ny 

funktion). Ud for hver funktion er der indikeret om den er implementeret. 

Efter listen begrunder jeg min prioritering af implementering. 

Nr. Felter Impl. +/- 

Netværksinstallationer: 

1a Adresser Ja + 

1b Netværksdata Ja + 

1c Services, som kan vælges til adressen Ja + 

Brugere: 

2a Navn Ja + 

2b Bruger ID/konto nr. Ja + 

2c E-mail Ja + 

2d Telefonnumre (fastnet og mobil) Ja + 

2e PBS aftalenummer Nej + 

2f Tilmeldte services Ja + 

2g Tilmeldings dato Ja + 

2h Frameldings dato Ja + 

2i Kommentarfelt Nej + 

Funktionaliteter: 

3a Adresser oprettes vha. relationer mellem husnumre, etager og sider Ja + 

3b Foreninger tilknyttes adresser Ja + 

3c Foreninger skal have tilknyttet x-felter Nej + 

3d X-felter skal have tilknyttet netværksudstyr Ja + 

3e 

Det skal være muligt at uploade et billede, som viser placeringen af 

krydsfeltet i ejendommen 

Ja + 

3f 

Man skal kunne forbinde de forskellige krydsfelter i systemet med den type 

af fiberflow/lysleder som er brugt 

Nej + 

3g 

OPTIONAL Brugeren skal kunne vælge hvilket rør i fiberflowen som er 

brugt 

Nej + 

3h OPTIONAL Brugeren skal kunne indsætte fordelerdåser på en fiberflow Nej + 

3i 

OPTIONAL Brugeren skal kunne vælge hvilken type fiber, der er blæst i 

røret 

Nej + 

3j 

OPTIONAL Brugeren skal kunne vælge hvor mange fibre som er splidset 

og hvilke som er i brug 

Nej + 

Liste over netværksudstyr: 

4a Switche Ja + 

4b Audiocodes Ja + 

4c UPS’e Ja + 

4d Fiberflow Nej + 

Liste over telefonnumre i systemet: 

5a Man skal kunne tilføje enkeltnumre og indikere om de er porteret eller ej Ja + 

5b Man skal kunne tilføje en hel nummerserie (fra nr. til nr.) Ja + 

5c 

Man skal kunne sætte et tidsrum som numre skal henligge, før de må 

bruges igen 

Nej + 

5d 

Man skal kunne nedlægge numre og indikere, om de skal udporteres eller 

må genbruges 

Delvist + 

Liste over e-mail i systemet: 

6a Brugeren skal selv kunne oprette en e-mailadresse (simuleres) Nej + 

6b 

Brugerens e-mailadresse(r) nedlægges 6. mdr. (eller en periode som kan 

ændres) efter opsigelse 

Nej + 

Søgninger: 

7a Foreningskontorer/kontaktpersoner Nej + 

7b Udstyrsspecifik Nej + 

7c Services specifik Nej + 

7d Ledig fiberflow Nej + 

Alle lister skal kunne redigeres: 



8a 

8b 

8c 

Det skal altid være muligt at tilføje noget nyt (forudsat, at det ikke findes i 

forvejen) 

Der kan kun fjernes udstyr/adresser/etc., som IKKE har relationer til 

noget/nogen 

Administrationsdelen skal logføre alle ændringer, så det altid er muligt at 

spore, hvilken admin som har foretaget ændringer i oplysninger/relationer 

i databasen. 

Ja + 

Ja + 

Delvist + 

Online tilmelding: 

9a Brugerne i Parknet skal kunne tilmelde sig online og indsættes i databasen Ja - 

9b Der skal kun kunne vælges mellem adresser i Parknet Ja - 

9c Det skal kunne styres pr. adresse, hvilke services Parknet leverer Ja - 

9d Brugerens input skal valideres Ja - 

9e Online tilmeldingen skal være nem, overskuelig og se pæn ud Ja - 

9f Brugerens password skal autogenereres Ja - 

9g Brugeren skal kunne tilmelde sig PBS Ja - 

9h Brugeren må ikke kunne oprette sig flere gange via samme browservindue Ja - 

SAPS: 

10a Brugerne i Parknet skal have adgang til selvbetjening i SAPS Ja - 

10b Brugerne skal kunne opsige services i SAPS Ja - 

10c 

Brugerne skal kunne abonnere på nye services/ændre eksisterende, 

bestille fast IP nr., oprette e-mail adresse osv. 

Nej - 

10d 

SAPS skal selv indsætte poster i opkrævninger. Fx gebyr for ændring af TV 

pakke 

Delvist - 

10e Der skal være to do lister Delvist - 

10f 

Funktioner til bogholder, så der kan køres opkrævning af brugernes 

services 

Nej - 

10g 

Brugere skal kunne oprettes via SAPS, tilknyttes en adresse og få 

abonnementer (kører i online tilmelding, men endnu ikke i SAPS) 

Nej - 

10h 

Brugere skal kunne meddele flytning via SAPS, så adressen bliver ledig 

igen. Funktionen skal også være tilgængelig for bogholderen 

Nej - 

2e) PBS nummer skal bruges i forbindelse med at køre opkrævninger, som skal sendes til PBS. Jeg 

nåede ikke så langt, at dette felt blev relevant. 

2i) I stedet for et kommentarfelt har jeg implementeret mulighed for at skrive tickets. Jeg opfatter 

tickets som en form for kommentarer. 

3c) Krydsfelterne er implementeret, så de hører til en adresse eller en blok – ikke en forening. 

3f – 3j + 4d) er ikke implementeret. Dels har Parknet allerede et system til at dokumentere 

fiberforbindelser og derudover er hovedparten af Parknets netværk baseret på Extreme switche. Disse 

har en funktion som hedder SHOW EDP port X (EDP står for Extreme Discovery Protocol), dvs. at hvis 

man kører SHOW EDP på alle backbone porte, vil swithcene kunne tegne netværkstopologien selv. 

Derfor har jeg valgt at fokusere andre steder bl.a. på online tilmelding. 

6a + b) er ikke implementeret. Jeg havde ikke MySQL adgang til @-mail serveren, hvor jeg kunne have 

oprettet mailadresserne. 

7) er ikke implementeret. Data er i databasen (dog ikke til 7d), så det er kun et spørgsmål om at få 

defineret kriterierne for søgningerne. 

8c) er delvist implementeret ved, at SAPS skriver en ticket, når en supporter eller administrator ændrer 

brugerens TV pakke. Derudover skrives der også en ticket, når TV pakken er ændret og nogen klikker 

”Done” på TV to do listen. 

10c) brugeren kan logge ind i SAPS, resten er bare programmering af funktionerne. 

10d) der indsættes gebyr for hhv. oprettelse af Internet og TV via online tilmelding og fra SAPS ved 

ændring af TV pakke. Dette skal udbygges, så alle tilmeldinger/ændringer til services skrives i 

opkrævninger. 

10e) der er implementeret TV to do liste, listerne for telefon og Internet ville ligne denne liste. 

10f) der er implementeret felter i databasen, så systemet er klar til at køre opkrævningerne. Bl.a. skal 

skæringsdato for abonnements start bruges. 



8 Test 

8.1 Indledning 

Test skal altid være en fast del af udviklingen. Jeg har for hver ny 

komponent eller feature testet, at den virkede korrekt. Disse tests er ikke 

nok til at validere et system på SAPS størrelse. Der er for mange 

afhængigheder mellem data til, at små enkeltstående test kan blive 

afgørende for en konklusion på funktionaliteten af helheden. 

Opbygningen af testafsnittet er i høj grad inspireret af opbygningen af IEEE- 

829. Jeg har erfaring med brug af denne procedure fra tidligere projekter i 

min studietid på DTU. 

8.2 Demonstration 

SAPS blev demonstreret for nogle af mine kolleger hos Parknet fredag den 

17. april 2009. I den forbindelse fremkom mange gode kommentarer og 

forslag til ændringer og forbedringer. Der blev fundet én fejl under 

demonstrationen, som blev rettet med det samme. 

8.3 Brugertest 

Brugertest er den test som ligger efter systemtesten. I denne fase testes 

systemet med brugerinput for at afprøve samtlige funktioner og sikre at 

finde eventuelle fejl, samt klarlægge den overordnede kvalitet af produktet. 

Testeren har frie hænder til at teste ud over de givne test cases, for på den 

måde at komme til bunds i yderpunkter, hvor der kan opstå fejl. Testen vil 

blive udført med nedenstående test cases, fejl rapporteres i fejllisten afsnit 

8.4. 

8.3.1 Test cases 

8.3.1.1 Opret/rediger adresser 

Prækonditioner: 

‐ Administrator er logget ind 

Test case Bruger interaktion Forventet output Svar Fejl 

nr. 

nr. 

001 Vælg ”Foreninger, veje, numre, etager og sider” fra 

menuen 

Det er muligt Pass 

002 Tilføj A/B Lindegaarden til SAPS Det er muligt Pass 

003 Tilføj Tornsangervej, Kærsangervej og Mågevej til 

SAPS 


004 Klik på tilføj ud for veje uden at taste noget input Der oprettes en tom vej Pass 

005 Ret adressen til Gransangervej Det er muligt Pass 

006 Vælg ”Tilføj/fjern adresser” fra menuen Det er muligt Pass 

007 Tilføj Tornsangervej 1 – 13, Gransangervej 1‐3, 

Mågevej 20‐22, Kærsangervej 10‐20, stuen – 2. sal, 2 

sider, 2400, A/B Lindegaarden 


008 Fjern Tornsangervej 9 2.th og 2. tv Det er muligt Pass 

009 Tilføj Tornsangervej 9 – 9, 2. sal – 2. sal, 1 side, 2400, 

A/B Lindegaarden og Tornsangervej 11 kld. 


010 Konstatér at alle adresser har en ”Fjern” knap i 

kolonnen ”Funktion” 

Ja Pass 

011 Klik på tilføj uden at vælge noget input Der oprettes ingen adresser Pass 

012 Tilføj en adresseserie, hvor ”nr. fra” > ”nr. til ”og 

”etage fra” > ”etage til” og 2 sider 

Der oprettes ingen adresser Pass 



8.3.1.2 Opret/rediger krydsfelter 




nr. 

nr. 

013 Vælg ”Vis/opret krydsfelter” fra menuen Det er muligt Pass 

014 Tilføj et krydsfelt på Tornsangervej 7 og Kærsangervej 

16, kld., blok 16, 2400 


015 Vælg blok 16 i drop down menuen Der vises to krydsfelter (b16x7 og 

b16x16) 

Pass 

016 Vælg Tornsangervej i drop down menuen Der vises et krydsfelt (b16x7) Pass 

017 Vælg Kærsangervej i drop down menuen Der vises et krydsfelt (b16x16) Pass 

018 Konstatér at krydsfelterne har en ”Fjern” knap i 

kolonnen ”Funktion” 

Ja Pass 

019 Vælg ”Aktivt udstyr” fra menuen Det er muligt Pass 

020 Klik på tilføj uden taste noget input Java exception pga. 

nummerformateringsfejl 

Pass 

021 Tilføj MP 118 ‐ 8 porte, MP 124 – 24 porte, X200‐24 – 

24 porte, X200‐48 


022 Ret en af rækkerne i tabellen Det er muligt Pass 

023 Ret et af portantallene til en IKKE‐integer Java exception pga. 


Pass 

024 Vælg ”Udstyr i x‐felt” Det er muligt Pass 

025 Vælg ”b16x7” fra drop down menuen Der vises udstyr i x‐feltet Pass 

026 Tilføj b16e21, b16e22 og b16e23 med admin, admin, 

12345, X200‐24, 2006‐10‐01 


027 Tilføj b16t21, b16t22 med admin, admin, 12345, MP 

124, 2006‐10‐01 


028 Klik på tilføj uden at taste/angive noget input Java exception pga. 

datoformateringsfejl 

Pass 

029 Klik på tilføj med kun start dato angivet Der oprettes tom linje med kun navn 

og start dato udfyldt 

Pass 

030 Ret den tomme linje til: b16t23 med admin, admin, 

12345, MP 118, 2006‐10‐01 


031 Vælg ”Adressedata i x‐felt” Det er muligt Pass 

032 Vælg Tornsangervej fra drop down menuen Der vises alle adresser på 

Tornsangervej 

Pass 

033 Klik på ret ud for nr. 1 st. tv. og tilføj datapatch: C1 15, 

telepatch: C1 16, vælg b16x7 og sæt medtaginet til: 1 


034 Vælg ”Adresser og porte” Det er muligt Pass 

035 Vælg Tornsangervej fra drop down menuen Det er muligt Pass 

036 Tilføj Tornsangervej 1 st. tv., b16e22 og port 18 

Tilføj Tornsangervej 1 st. tv., b16t22 og port 16 


037 Ret Tornsangervej 1 st. tv., b16t22, port 16 til b16t23 Port nr. drop down menuen skal Pass 

(8 ports Audiocode) 

skifte fra 16 til ‐‐‐Vælg‐‐‐, da der kun 

er 8 porte i det valgte udstyr 

038 Ret test case 037 tilbage til b16t22, port 16 Det er muligt Pass 

039 Klik på tilføj uden at angive noget input Der bliver ikke tilføjet noget til 

tabellen 

Pass 

040 Tilføj en adresse uden at vælge udstyr og port Der bliver tilføjet en adresse uden 

udstyr og port 

Pass 

041 Klik på ”Vis opret krydsfelter” og vælg blok 16 Der vises to krydsfelter (b16x7 og 

b16x16) 

Pass 

042 Konstatér at krydsfeltet b16x7 ikke længere har en 

”Fjern” knap i kolonnen ”Funktion”, da der er 

tilknyttet adresser til dette krydsfelt 

Ja Pass 



8.3.1.3 Rediger services 




nr. 

nr. 

043 Vælg ”Services og priser” fra menuen Det er muligt Pass 

044 Ret en service med lovlige input Det er muligt Pass 

045 Ret en service og indtast bogstaver i pris kolonnerne Java exception pga. 


Pass 

046 Tilføj en ny linje til tabellen med et FUnique som er i Java exception pga. dobbelt 

Pass 

brug 

oprettelse af et unikt ID 

047 Vælg ”Copydan priser” fra menuen Det er muligt Pass 

048 Ret en linje med lovlige input Det er muligt Pass 

049 Ret en pris til bogstaver Java exception pga. 


Pass 

050 Vælg ”Definer std. services” fra menuen Det er muligt Pass 

051 Klik tilføj service ud for en services, hvor statusfeltet 

er rødt 

Statusfeltet bliver grønt Pass 

052 Klik fjern service ud for en service, hvor statusfeltet er 

grønt 

Statusfeltet bliver rødt Pass 

053 Vælg ”Farver til services” fra menuen Det er muligt Pass 

054 Ret en farve ved at skrive en gyldig HTML farve i farve 

feltet 

Farven vises korrekt Pass 

055 Ret en farve ved at skrive en ugyldig farve Vist farve er hvid Pass 

056 Vælg ”Services pr. adresse” fra menuen Det er muligt Pass 

057 Vælg en adresse fra drop down menuen Det er muligt Pass 

058 Klik tilføj service ud for en services, hvor statusfeltet 

er rødt 

Statusfeltet bliver grønt Pass 

059 Klik fjern service ud for en service, hvor statusfeltet er 

grønt 

Statusfeltet bliver rødt Pass 

060 Fjern alle services og klik derefter på Tilføj standard Der bliver tilføjet de services som er Pass 

services 

defineret i ”Definer std. services” 

061 Fjern services fra Tornsangervej 1 st. tv. og st. th. Alle statusfelter bliver røde Pass 

062 Vælg ”Services pr. forening” fra menuen Det er muligt Pass 

063 Vælg A/B Lindegaarden fra drop down menuen og klik Alle adresser i A/B Lindegaarden har Pass 

på Tilføj standard services 

fået tilføjet standard services 

(kontrolleres via ”Services pr. 

adresse”) 

8.3.1.4 Databasecheck af services 


‐ Testeren er logget på MySQL serveren via GUI tools (Query Browser) 

‐ Testen udføres lige efter test case 063 


nr. 

nr. 

064 SELECT COUNT(id) FROM standard services; 15 Pass 

065 SELECT id, COUNT(FUnique)antal FROM add_yd_rel Værdien i kolonnen ”antal” er det Pass 

WHERE id IN (SELECT DISTINCT id FROM add_yd_rel) samme som resultatet fra test case 

GROUP BY id; 

064 pr. ID 

8.3.1.5 Rediger/tilføj telefonnumre og status 




nr. 

nr. 

066 Vælg ”Telefon nr. status” fra menuen Det er muligt Pass 

067 Ret en Telefon nr. status Det er muligt Pass 

068 Ret en ”Hemmeligt/skjult nummer” Det er muligt Pass 

069 Tilføj en ny linje til tabellen Det er muligt Pass 

070 Vælg ”Telefon nr. i Parknet” fra menuen Det er muligt Pass 



071 Klik på tilføj uden at angive noget input Java exception pga. 


Pass 

072 Tilføj fra nr. 82300300 til 82300302 Numrene bliver tilføjet Pass 

073 Ret et telefonnummer med gyldige input Det er muligt Pass 

074 Ret et telefonnummer med ugyldige datoer Java exception pga. 

datoformatteringsfejl 

Pass 

8.3.1.6 Rediger valideringsstrenge 




nr. 

nr. 

075 Vælg ”Valideringsstrenge til online opret” fra menuen Det er muligt Pass 

076 Ret valideringsstrengen til navn Det er muligt Fail 1 

077 Ret valideringsstrengen til telefon nr. Det er muligt Pass 

078 Ret valideringsstrengen til e‐mail Det er muligt Fail 2 

8.3.1.7 Rediger MIB’er 




nr. 

nr. 

079 Vælg ”MIB’er til SNMP” fra menuen Det er muligt Pass 

080 Ret MIB til status Det er muligt Pass 

081 Ret MIB til åben port Det er muligt Pass 

082 Ret MIB til luk port Det er muligt Pass 

8.3.1.8 Rediger ticket typer 




nr. 

nr. 

083 Vælg ”Rediger ticket typer” fra menuen Det er muligt Pass 

084 Ret navnet på en ticket Det er muligt Pass 

085 Tilføj en ny ticket type Det er muligt Pass 

8.3.1.9 Bogholder funktioner 


‐ Administrator eller bogholder er logget ind 

‐ Der er datoer i systemet 


nr. 

nr. 

086 Vælg ”Start og opsigelses datoer” fra menuen Det er muligt Pass 

087 Ret et navn og en dato med korrekt datoformat Det er muligt Pass 

088 Ret et navn og en dato med forkert datoformat Java exception pga. 

datoformateringsfejl 

Pass 

089 Vælg ”Opkrævninger” fra menuen Det er muligt Pass 

8.3.1.10 Vis/ret/tilføj bruger 




nr. 

nr. 

090 Vælg ”Vis/ret/tilføj brugere” fra menuen Det er muligt Pass 

091 Opret en ny bruger uden at udfylde felter Der bliver ikke oprettet en ny bruger Pass 

092 Opret en ny bruger med angivelse af navn, efternavn 

og administratorrolle 

Brugeren bliver oprettet Pass 



093 Opret en ny bruger med angivelse af navn, efternavn, Java exception pga. incorrect integer Pass 

rolle og fjern de to nuller i telefon og mobil 

value 

094 Deaktiver den bruger som blev oprettet i test case 

092 

Brugeren bliver deaktiveret Pass 

095 Prøv at logge ind i SAPS med brugerens som blev 

inaktiveret i test case 094 

Det er ikke muligt Pass 

096 Vælg ”Vis roller” fra menuen Det er muligt Pass 

8.3.1.11 TO DO TV 


‐ Administrator eller supporter er logget ind 

‐ Der er data i TO DO listen 


nr. 

nr. 

097 Vælg ”TO DO TV” fra menuen Det er muligt Pass 

098 Klik på et link i kolonnen x‐felt Der vises et oversigtbillede af 

krydsfeltet 

Pass 

099 Klik på Done Rækken forsvinder fra tabellen Pass 

100 Tjek at sorteringen af rækkerne følger: dato, postnr, 

intersection, adresse (stigende) 

Sortering er korrekt Pass 

8.3.1.12 Søg adresser og brugere 


‐ Administrator, bogholder eller supporter er logget ind 

‐ Der er oprettet adresser og nogle brugere har aktive services 


nr. 

nr. 

101 Vælg ”Søg adresser og brugere” fra menuen Det er muligt Pass 

102 Indtast torn og klik søg Der vises alle adresser på 

Tornsangervej. 

Pass 

103 Indtast torn og nr. 1 og klik søg Der vises alle adresser på 

Tornsangervej nr. 1 

Pass 

104 Hvis der er aktive services er feltet i kolonne aktive 

yd. grønt ellers rødt 

Ja Pass 

105 Klik på et link i kolonnen x‐felt Der vises et oversigtbillede af 

krydsfeltet 

Pass 

106 Klik på Tornsangervej 1 st. tv. Der vises alle detaljer om brugeren, 

tickets og valgte services på adressen. 

Pass 

107 Hvis servicen er tilmeldt, er feltet under kolonnen tilm 

status grønt ellers rødt 

Ja Pass 

108 Akt. status er sort, rød eller grøn (jf. de farver som er 

angivet under ”Farver til services”. På server console 

køres SNMP kommando til at finde portens status 

(forudsat at der er oplysninger om switch og port) 

Ja Pass 

109 Hvis der kan tilmeldes Internet til adressen og der er 

aktivt udstyr tilknyttet til adressen, er der to knapper 

til hhv. åben port og luk port. Ved at klikke på 

knapperne køres SNMP kommandoer på server 

console. 

Ja Pass 

110 Hvis der er tilmeldt telefon vises 

Ja (virker kun hvis LOCALHOST har Pass 

abonnementsoplysninger og telefonsaldo 

adgang gennem Parknets firewall til 

Miralix serveren!) 

111 Hvis der kan tilmeldes TV på adressen og der er 

tilmeldt en bruger er der en ret knap 

Ja Pass 

112 Ret TV, vælg pakkeskift dato og en anden TV pakke Tilmeldingsdato ændres, pakkeskift 

dato og skift TV pakke til bliver sat og 

der oprettes en ticket 

Pass 

113 Tjek i opkrævninger at der er tilføjet en opkrævning 

for skift af TV pakke 

Ja Pass 

114 Tilføj en ny ticket Det er muligt Pass 

115 Tilføj en ny ticket uden at vælge type Der bliver ikke tilføjet en ny ticket Pass 

116 Tilføj en ny ticket uden indhold Det er muligt Pass 



8.3.1.13 Vis/ret bruger 


‐ Bogholder eller supporter er logget ind 


nr. 

nr. 

117 Vælg ”Vis/ret brugere” fra menuen Det er muligt Pass 

118 Vælg at rette en bruger Det er muligt (med undtagelse af 

aktiv og rolle) 

Pass 

119 Ret en bruger med lovlig input Det er muligt Pass 

120 Ret en bruger med tekst i stedet for telefonnummer Java exception pga. incorrect integer 

value 

Pass 

8.3.1.14 Online tilmelding 


‐ Der er oprettet adresser i SAPS hvor showinet er 1 og der er tilknyttet standard 

services 

‐ Der er ikke oprettet en bruger på den valgte adresse 


nr. 

nr. 

121 Vælg postnr. 2400 Gadevælger aktiveres Pass 

122 Vælg Tornsangervej Adressevælger og ”næste” aktiveres Pass 

123 Vælg Tornsangervej 1 st. tv. Det er muligt Pass 

124 Klik næste Trin 2 aktiveres med mulighed for at 

vælge Internet, telefon og TV 

abonnement 

Pass 

125 Udfyld fornavn og efternavn Teksten “Du skal skrive for‐ og 

efternavn før du kan klikke næste” 

forsvinder 

Pass 

126 Udfyld mobil tlf., fastnet tlf. med flere tal end 8 Det er ikke muligt Pass 

127 Udfyld mobil tlf. med 112 og angiv en ugyldig e‐mail Det er muligt Pass 

128 Vælg Internet, telefon og TV abonnement Ved valg af den første service skal 

teksten ”Du skal vælge mindst én 

service før du kan klikke næste” 

forsvinde 

Pass 

129 Vælg flat rate, portering af nummer, kvartalsvis Der skal komme fejlmeddelelse om at Pass 

betaling, stor pakke, start 1. juni og klik næste mobil tlf. og e‐mail er ugyldig 

130 Ret mobil nr. til 221 og klik næste Der skal komme fejlmeddelelse om at 

mobil tlf. er for kort og e‐mail er 

ugyldig 

Pass 

131 Ret mobil nr. til lovlig input fx 22222222 og e‐mail til Der skal komme fejlmeddelelse om at Pass 

”mig” og klik næste 

e‐mail er for kort 

132 Ret e‐mail til lovligt input og klik næste Trin 3 aktiveres og valgene fra trin 2 

vises korrekt 

Pass 

133 Klik tilbage Trin 2 vises korrekt med de samme 

valg fra tidligere 

Pass 

134 Klik næste Trin 3 vises igen Pass 

135 Sæt flueben ud for ”Jeg accepterer Parknets 

abonnementsvilkår og priser” 

Teksten ”Du skal acceptere 

abonnementsvilkårene før du kan 

klikke næste” forsvinder 

136 Klik næste Trin 4 aktiveres og brugeren får vist 

sit brugernummer, password og link 

til PBS tilmelding 

137 Klik Tilmeld dig til Betalingsservice De preudfyldte felter er udfyldt 

korrekt og brugeren skal kun udfylde 

cpr. nr., reg. nr. og konto nr. 

138 Opret en bruger på en adresse, hvor der allerede er 

en aktiv bruger 

Brugeren får besked om, at der er en 

tilmeldt bruger på adressen og at 

bestillingen er lagt i kø. Brugeren får 

vist sit brugernummer, password og 

link til PBS tilmelding 

139 Klik på browserens tilbage knap i trin 4 Det er muligt – trin 3 vises Pass 

140 Klik på enten tilbage eller næste i online tilmeldingen Brugeren får besked om at 

oprettelsen er sket og at browserens 

tilbage knap ikke må bruges 

Pass 


Pass 

Pass 

Pass 

Pass


8.3.1.15 Opsig services 


‐ En bruger med aktive services er logget ind 


nr. 

nr. 

141 Vælg ”Opsig services” fra menuen Det er muligt Pass 

142 Ud for hver aktiv service står tilmeldingsdato og der 

er en Frameld knap 

Ja Pass 

143 Klik på Frameld Der vises en drop down menu med 

opsigelsesdatoer samt en ja og nej 

knap 

Pass 

144 Vælg 31. marts og klik Ja NOTE: 

Servicen er blevet opsagt til: 

Pass 

Hvis datoen er tidligere på året end d.d. vil der blive 31/3‐2010 og Frameld knappen er 

lagt et år til. Dvs. når testen køres i april 2009, vil 

opsigelsesdatoen blive 31/3‐2010. 

væk 

8.3.1.16 Test af sikkerhed 


‐ En supporter er logget ind (til test case 146), ellers ingen prækonditioner 


nr. 

nr. 

145 Indsæt følgende streng i feltet fornavn eller efternavn i Der star alert('hacket!'); og scriptet er Pass 

online tilmeldingens trin 2 og klik næste: 

alert('hacket!'); 

ikke blevet eksekveret 

146 Indsæt følgende streng i browseren 

Supporteren får vist velkomstsiden Pass 

http://localhost:8080/saps/authorized_users/AdministratorArea/users.jsp 

Hvis det virker, vil supporteren kunne ændre sine 

brugerrettigheder i SAPS 

og stien i browseren er: 

http://localhost:8080/saps/ 

authorized_users/welcome.jsp 

147 Prøv følgende brugernummer og password ved login til 

SAPS: 

User: 1' or '1' = '1 

Password: 1' or '1' = '1 

Systemet giver ikke adgang Pass 

148 Indsæt følgende streng i browseren (uden at være 

logget ind): 

http://localhost:8080/authorized_users/images/1.jpg 

Hvis systemet giver adgang, vises et billede af 

krydsfeltet 

Systemet giver ikke adgang Pass 

8.4 Fejlrapportering og fejlliste 

Hver fejl får tilknyttet sin egen fejl rapport. I dette afsnit samles alle fejl, 

som er fundet i alle test. Det giver et hurtigt overblik over det samlede 

antal fejl, der er i systemet. 

Fejl deles op i 3 kategorier, som beskriver konsekvensen af fejlen. 

Fejl kategori Beskrivelse 

Fatal Funktionsforstyrrende fejl der er af så alvorlig karakter at data mistes og/eller programmet låses. 

Alvorlig Fejl der ikke kan klassificeres i de to ydergrupper. 

Mindre alvorlig Små fejl som ikke er funktionsforstyrrende såsom Stavefejl og lign. 

Figur 20 - Opdeling af fejl efter kategorier 

Fejlene samles for at give et helhedsindtryk over hvor stabilt systemet er. 

Fejllisten bruges også som et værktøj, hvor udvikleren kan se hvilke ting 

der mangler at blive rettet, inden produktet kan godkendes og leveres til en 

evt. kunde. Nedenstående figur viser hvordan jeg har udnyttet et 

iterationsbaseret udviklingsprincip. 



Figur 21 - Livscyklus for fejl 

Fejl−ID Beskrivelse af fejl Fejl 

niveau 

1 Valideringsstrengen til navn bliver ikke vist korrekt ved klik på ret. Alt efter ” ’ ” mangler. Hvis man 

klikker ok, bliver strengen til NULL. Ved forsøg på at genoprette strengen giver databasen følgende 

fejl: 

WARNING: Parameters: Character decoding failed. Parameter skipped. 

Alvorlig 

2 Valideringsstrengen til e‐mail ser ud til at blive vist korrekt. Der mangler dog en del ”\” som escape 

tegn til andre relevante tegn. Ved forsøg på at indsætte ekstra ”\” bliver de fjernet i forbindelse med 

skrivning til databasen. Selv om valideringsstrengen ser OK ud, bliver det umuligt at få valideret en 

lovlig e‐mail korrekt i online tilmeldingen. Brugeren kan dog undlade at indtaste sin e‐mail og komme 

videre på den måde. 

Valideringsstrengene kan dog indsættes i databasen igen via Query Browseren 

Alvorlig 

Aktuelle kendte fejl i systemet: 

Fejl kategori Antal 

Fatal 0 

Alvorlig 2 

Mindre alvorlig 0 

8.5 Test konklusion 

Undervejs i udviklingen af SAPS, har jeg testet delkomponenterne i takt 

med, at de blev færdige. Det har medført, at helheden har kunnet bestå en 

kompleks test med meget få fejl. Jeg har kørt 148 test cases og har også 

testet ud over, hvad test casene har beskrevet. 

De to alvorlige fejl, som blev fundet, kan undgås ved, at administrator IKKE 

retter i valideringsstrengene for navn og e-mail via SAPS. 

Nogen vil sikkert mene, at det ikke er tilfredsstillende, at bruge Javas 

exception beskeder som fejlmeddelelse fx number format exception. Men 

som beskrevet under implementeringen var det et bevidst valg, at lægge 

fokus på brugervenlige fejlmeddelelser i online oprettelsen og acceptere 

visse mangler i administrationsdelen. 

Jeg mener at have testet så bredt og dybt, at jeg har klarlagt de fejl som 

systemet har p.t. På den baggrund er anbefalingen, at valideringsstrengene 

ikke rettes. Systemet er stabilt og fejlfrit nok til at vise hvordan et nyt 

brugeradministrationssystem med integreret online tilmelding til Parknet 

kan se ud. 



9 Forslag til forbedringer af SAPS 

- Bedre søge/sorterings funktioner, det skal være muligt for brugerne 

af SAPS at opstille deres egne kriterier for søgning/sortering. 

- Mulighed for til- og fravalg af kolonner i listevisning. 

- Hvis support telefonen blev tilkoblet SAPS, ville det blive muligt for 

systemet at søge efter brugeren via nummeret. Når supporteren så 

svarer telefonen, vil SAPS allerede have fundet brugerens oplysninger 

frem på skærmen (forudsat at nummeret er i SAPS). 

- Brugeren skal have adgang til meget mere via selvbetjening. Ændring 

af brugeroplysninger, flytte adresse fra et sted i Parknet til et andet, 

vise saldo på telefonkonto, overdrage sit abonnement til ny indflytter, 

booke teknikerbesøg, bestille et fast IP nr., se sine tickets og oprette 

en ny og meget andet. 

- Bogholderfunktioner skal implementeres fuldt, så der kan køres 

opkrævninger. SAPS skal vise, hvis en bruger er i restance. 

- SAPS skal udføre SNMP kommandoerne i praksis. 

- SAPS skal integreres med @mail, så brugerne selv kan oprette emailadresser 

og systemet kan nedlægge dem, når brugeren er flyttet. 

- SAPS skal integreres endnu mere med Miralix, så brugerne selv kan 

vælge et ledigt telefonnummer og aktivere det. 

- SAPS skal have indbygget kalender til bookning af teknikerbesøg. 

- En supporter/administrator skal kunne indføre i SAPS kalenderen, 

hvilke dage han/hun har tider til teknikerbesøg. 

- Dokumentationen af krydsfelter skal udvides til også at omfatte 

backbone forbindelse, herunder fiberflow med ledige rør, ledige fibre, 

splidsninger og hvad hver tråd er brugt til (TV eller data). 

- Sprogpakke til onlinetilmeldingen, så den kan oversættes til alle de 

sprog Parknet har lyst til. Der er mange brugere på Nørrebro med 

anden etnisk baggrund. 

- Mulighed for at en administrator kan varsle udfald på en bestemt 

netværkskomponent eller krydsfelt, hvorefter brugerne kan se i SAPS 

om de bliver berørt. 

- Der skal kunne sætte en deadline for gratis tilmelding af en ny 

forening, så online tilmelding automatisk viser, at tilmelding er gratis. 

- Tickets skal kunne løses (p.t. kan de kun oprettes). 



- Hvis en ny bruger vælger at få flyttet et telefonnummer til Parknet, 

skal brugeren præsenteres for et link til porteringsformularen i online 

tilmeldingen. 

- Det må ikke være muligt at tilknytte den samme port i en switch til 

mere end én adresse. 

- I stedet for at lægge kort ind med placering af et krydsfelt, skal 

koordinatet lægges ind, systemet skal derefter selv vise krydsfeltet 

på kort via fx krak eller Google maps. 

- Der skal være mulighed for at definere flere sæt ”Standard services”. 

- Bedre fejlmeddelelse ved fejl i login. Det ville rart med en melding 

om, hvorvidt det er brugernavn, adgangskode eller evt. 

databaseforbindelsen, der er noget galt med. 



10 Procesafsnit 

I dette kapitel vil jeg beskrive, processen omkring udviklingen af SAPS. Jeg 

har primært benyttet mig af iterationsbaseret udvikling. Det har jeg gjort 

ved at inddele projektet i overskuelige dele. For hver del har jeg testet 

resultatet og efter tilfredsstillende test fortsat til næste del. I forbindelse 

med test af næste del, har jeg flere gange oplevet, at det har været 

nødvendigt at ændre noget i den forrige del. Det har ikke været noget 

problem og har ikke forsinket projektet. Rettelserne er blevet udført som en 

del af opgaverne med den næste iteration. 

Jeg er selv meget tilfreds med denne måde at udvikle på, netop fordi der er 

stor fleksibilitet i forhold til afklaring af uhensigtsmæssigheder og rettelse af 

disse undervejs i processen. Selv om jeg har været alene om projektet, 

mener jeg stadig at udviklingsmetoden også er velegnet i store 

udviklingsmiljøer. 

Overordnet har tidsplanen været start 1. februar og aflevering 1. maj. 

Detaljeret tidsplan for projektet har været som følger: 

Punkt Deadline Status 

Start 01/02-09 OK 

Analyse klar 20/02-09 OK 

Design klar 01/03-09 Forsinket 

Påbegynd implementering af SAPS 01/09-09 OK 

Kollokvium med vejleder 18/03-09 OK 

Påbegynd implementering af online opret 20/03-09 OK 

Codefreeze 08/04-09 Forsinket 

Test 19/04-09 OK 

Retning af småfejl Løbende OK 

Rapport klar til gennemlæsning og 

kommentering 

26/04-09 

Forsinket 

til 28/04 

Aflevering af rapport (DTU har lukket 1. maj) 01/05-09 

Flyttet 

04/05 

til 

Deadlines har været sat tidligt og lidt optimistisk, men gennem erfaring fra 

5 semestre på DTU, har det vist at være en god måde at få tingene gjort 

på. Derfor er det ikke tale om store ændringer til planen, når en deadline 

ikke er overholdt. 

Jeg har ikke udarbejdet nogen risikoanalyse for dette projekt. Det skyldes, 

at jeg for at blive ingeniør, skal færdiggøre og aflevere projektet til den 

aftalte deadline. 



11 Konklusion 

Succeskriteriet i kapitel 3.2 var: ”At SAPS kan bruges af Parknet.” 

Jeg kan konkludere at succeskriteriet ikke er opfyldt. 

SAPS vil ikke kunne bruges af Parknet til at afløse Winkas endnu. Det er der 

en række årsager til: 

- der mangler funktionalitet til at køre opkrævninger 

- der mangler funktionalitet til at tilmelde/framelde services 

- der mangler funktionalitet til at tilmelde/framelde brugere 

- der findes ingen automatiseret proces til at flytte data fra Winkas til SAPS 

- SAPS har ikke felter til oplysning om Matra og Philips tlf. centraler 

Dele af SAPS vil kunne gøre Winkas bedre, hvis de blev skilt ud i 

selvstændige programmer/metoder, som skrev data i et eller flere felter i 

Winkas databasen. 

Der er dog ingen tvivl om at tiden brugt på at færdiggøre og implementere 

SAPS vil tjene sig selv hjem over tid fra det øjeblik, hvor SAPS sættes i 

drift. 

Forventet tidsbesparelse (ca. tider) pr.: 

- Telefonoprettelse: 10 min 

- Internetoprettelse: 2 min 

- Onlineoprettelse (kun brugeren): 2 min 

- TV pakkeskift: 2 min 

- Overskuelighed pga. farver: ? 

- Printoption: 1 min (sparer ”print screen” og paste) 

Det opstillede formål i kapitel 3.1 var: 

At vise, hvordan mange systemer udviklet i forskellige programmeringssprog 

og kørende på forskellige styresystemer, kan samles i et system med 

en fælles brugergrænseflade. 

Jeg kan konkludere at formålet er opfyldt. Via SAPS kan der hentes saldo på 

telefonkontoen i Miralix, der er data til stede i SAPS til, at systemet i 

fremtiden vil kunne oprette telefonnumre automatisk. Ligeledes er der data 

klar til at sende korrekte SNMP kommandoer og dermed automatisere 

åbning og lukning af brugeres Internet. 

Jf. (5) består projekter af tre dele: Mennesker, systemer og organisationen. 

SAPS er i dette tilfælde systemet, organisationen er Parknet og 

menneskerne er de ansatte. Hvis SAPS blev implementeret ville det ændre 

systemerne, da det erstatter et eksisterende og samtidigt gør tingene på en 

ny måde. Menneskerne ville blive påvirket ved ændrede arbejdsgange, da 

SAPS automatiserer meget af det manuelle arbejde. Organisationen vil blive 

styrket, da medarbejderne kan nå mere. 

Udfordringen vil blive at indfase systemet, så alle kan følge med og vænne 

sig til ændringerne det medfører. 



12 Spørgsmål og svar med Parknets chef 

Svarene er indsat ved spørgsmålet med fed skrift. 

- Hvorfor er Parknet aldrig blevet automatiseret? Herunder: 

o Nem oprettelse af et telefonnummer, ved at systemet opretter brugeren 

fra Winkas i Miralix, finder ledige telefonnumre at vælge imellem, 

indsætter telefonnummeret i Miralix og Winkas, styrer lokalnumre uden 

menneskelig indblanding og sætter opkrævninger korrekt i Winkas. 

o Et system med ét kliks åbning og lukning af porte til Internet. 

o Natlig kørsel med åbning og lukning af switch porte afhængig af 

tilmeldingsstatus. 

Samlet svar på ovenstående – det har ikke været prioriteret og 

datagrundlaget har ikke været godt nok tidligere (det nærmer sig). 

- Der er forskel på en udgift og en mistet indtægt, men er gratister OK (aktuelt de 

steder hvor porten er åben uden tilmeldt bruger)? Tjoh 

- Er Parknet med de nuværende administrationssystemer klar til øget vækst? Ja 

- Hvor god er dokumentationen af Parknets (angivet i procent): 

o Tekniske procedurer? 80 % 

o Administrative procedurer? 50 % 

o Fiberflow? 20 % 

o Ledige/brugte lysledere? 20 % 

o Udstyr i krydsfelter? 60 % 

På en skala fra 1 til 10 (hvor 10 = øjeblikkelig lukning af Parknet), hvor ville Parknet 

være på skalaen, hvis de to projektledere Anders og Simon blev ramt af hver sin bus 

eller tagsten og døde samtidigt? 3 - 4 



13 Anbefaling til Parknet 

På baggrund af denne rapport, vil jeg anbefale Parknet, at sætte et system 

á la SAPS i drift. Systemet bør udvikles af Parknet selv. For at mindske 

udviklingsomkostningerne, vil jeg foreslå, at Parknet benytter sig af 

ingeniørpraktikanter fra Diplom IT retningen på DTU. Disse unge mennesker 

skal i praktik i 5 måneder, som en del af studiet og skal have ca. 12.000 - 

15.000 kr./md. i løn. 

Der er mulighed for at indgå længerevarende samarbejde med DTU, så 

Parknet for hvert semester kan komme med et aktuelt opslag om, hvilke 

projekter der kan være af interesse for de studerende. 

Når SAPS er i drift, vil der selvfølgelig være brug for løbende opdateringer. 

Dernæst er der både praktiske og programmerings opgaver. 

Programmeringsopgaverne er bl.a. 

- Kør SNMP kommandoer via Java 

- Hent port status for alle switche i Parknet og sammenlign dem med 

tilmeldingsstatus 

- Kør automatisk åbning og lukning af porte hver midnat 

- Software dokumentering af lysledernetværk 

De praktiske opgaver dækker over at få indtastet oplysninger i SAPS om 

krydsfelter og ledig/brugt lysleder. Det vil kræve besøg i samtlige 

krydsfelter, men der kan nås meget på 5 måneder (ingeniørpraktikkens 

varighed). 



14 Lister 

14.1 Litteratur liste 

1. Larman, Craig. Applying UML and Patterns: An Introduction to Object‐Oriented Analysis and 

Design and Iterative Development. Third Edition. s.l. : Addison Wesley Professional, 2004. p. 

736. ISBN: 0‐13‐148906‐2. 

2. Connolly, Thomas M. and Begg, Carolyn E. Database Systems: A Practical Approach to 

Design, Implementation and Management. s.l. : Addison‐Wesley, May 2004. p. 1374. ISBN: 0‐ 

32‐121025‐5. 

3. Lewis, John and Loftus, William. Java software solutions foundations of program design 

Fourth edition. s.l. : Pearson Addison Wesley, 2005. p. 909 ISBN: 0‐321‐31246‐5. 

4. Graba, Jan. An Introduction to Network Programming with Java. s.l. : Springer, 2006. p. 423 

ISBN: 1‐84628‐380‐9. 

5. Andersen, Erling and Grude, Kristoffer and Haug, Tor. Goal directed project management. 

Third edition s.l. : Kogan Page, 2004. p. 247 ISBN: 0‐7494‐4186‐0. 

6. Globalconnect. http://www.globalconnect.dk 

14.2 Forkortelser brugt i rapporten 

PK Private key 

FK Foreign key 

SP Stored Procedure 

SAPS Sammenbinding af Parknets systemer 

NF Normal Form 

COTS Commercially Of The Shelf 

SNMP Simple Network Management Protocol 

14.3 Figurliste 

Figur 1 - Billeder af krydsfelter.................................................................................... 9 

Figur 2 - Screen dump af Winkas søgeoversigt .............................................................11 

Figur 3 - Screen dump af Winkas konto 4878 ...............................................................11 

Figur 4 - Screen dump af Miralix velkomstbillede ..........................................................12 

Figur 5 - Screen dump af @-mail - tilføj ny bruger ........................................................13 

Figur 6 - Domænemodel ...........................................................................................16 

Figur 7 – Model af det fysiske design i Parknet .............................................................19 

Figur 8 - Use case diagram........................................................................................20 

Figur 9 - ER-diagram for relationen addressrel med tilhørende tabeller ............................28 

Figur 10 - ER-diagram for relationen intersections med tilhørende tabeller .......................28 

Figur 11 - ER-diagram for resten af tabellerne..............................................................29 

Figur 12 - Sitemap over designet ...............................................................................31 

Figur 13 - Designklassediagram for SAPS ....................................................................32 

Figur 14 - Designklassediagram for online tilmelding.....................................................33 

Figur 15 - Implementeringen af relationen addressrel med tilhørende tabeller...................35 

Figur 16 - Implementeringen af relationen intersections med tilhørende tabeller ...............36 

Figur 17 - Diagram for implementeringen af resten af tabellerne.....................................37 

Figur 18 - Sitemap over implementerede filer ..............................................................39 

Figur 19 - Statediagram for online tilmeldingen ............................................................47 

Figur 20 - Opdeling af fejl efter kategorier ...................................................................56 



Figur 21 - Livscyklus for fejl ......................................................................................57 

15 Bilag 

15.1 Bilag 1 – Projektoplæg 

Design af et netværks- og brugeradministrationssystem. Det nuværende 

system heder Winkas Pro og er udviklet af en dansk virksomhed i 

Frederikshavn (se mere på www.winkas.dk). 

Databasen til systemet skal bestå af to dele: 

1) Netværks- og installationsdata som er statisk 

2) Brugerdata som er tilknyttet en installation og er dynamisk (brugere 

kommer og går) 

Databehandlingssystemet (user interface) skal bestå af to dele 

(programmeres som en webapplikation): 

1) Administrationsdel, hvorfra brugernes data kan hentes. Brugere kan 

inaktiveres (aldrig slettes), opdateres og oprettes. Nye foreninger kan 

tilføjes i systemet med alle netværksdata. 

2) Brugerdel, hvorfra brugere kan oprette/tilmelde sig Parknet og få vist 

priser. Brugere kan opdatere sine oplysninger, ændre abonnementer, 

opsige abonnementer og foretage intern flytning i Parknet. 

Umiddelbart består opgaven i at designe databasen og dernæst 

webapplikationen. Det lyder ikke af så meget, men det bliver det når man 

tager med i betragtningen, at systemet skal indeholder alle former for 

netværksudstyr (switche og telefoncentraler) samt at det skal være muligt 

at tilføje/fjerne samt redigere relationer på kryds og tværs. 

Vedligeholdelsen af systemet skal kunne foretages fra webapplikationen, 

det er et krav, at brugeren ikke behøver at have programmørkendskab. 

Derudover skal der tages højde for, hvornår en bruger kan inaktiveres eller 

flyttes. Der skal konfigureres et REALM til login til hhv. administratorer og 

brugere. Foreninger med services fra Parknet må ikke kunne slettes fra 

netværksdatabasen. Der er mange faktorer at tage højde for. 

Platforme til opgaven vil blive: 

- MySQL 5 database 

- Tomcat 6 webserver 

- Eclipse 3.3 eller 3.4 



Kravspecifikation til ”WINKAS version 2”: 

Databasen skal indeholde følgende data: 

Netværksinstallationer: 

- Adresse 

- Netværksdata 

- Services som kan vælges til adressen 

Brugere: 

- Navn 

- Bruger ID/konto nr. 

- E-mail 

- Mobiltelefon nummer 

- Telefon nummer 

- PBS aftale nummer 

- Tilmeldte services 

- Tilmeldings dato 

- Frameldings dato 

- Kommentarfelt 

Funktionaliteter: 

- Adresser oprettes vha. relationer mellem husnumre, etager og sider 

- Foreninger tilknyttes adresser 

- Foreninger skal have tilknyttet krydsfelter 

- Krydsfelter skal have tilknyttet netværksudstyr 

- Det skal være muligt at uploade et billede, som viser placeringen af 

krydsfeltet i ejendommen 

- Man skal kunne forbinde de forskellige krydsfelter i systemet med 

den type af fiberflow/lysleder som er brugt 

- OPTIONAL Brugeren skal kunne vælge hvilket rør i fiberflowen som 

er brugt 

- OPTIONAL Brugeren skal kunne indsætte fordelerdåser på en 

fiberflow 

- OPTIONAL Brugeren skal kunne vælge hvilken type fiber, der er 

blæst i røret 

- OPTIONAL Brugeren skal kunne vælge hvor mange fibre som er 

termineret og hvilke som er i brug 



Liste over netværksudstyr: 

- Switche 

- Audiocodes (IP telefoni centraler 8 eller 24 porte) 

- UPSe 

- Fiberflow (lyslederforbindelser hhv. multimode og singlemode samt 

hvilke der er i brug) 

Liste over telefonnumre i systemet: 

- Man skal kunne tilføje enkeltnumre og indikere om de er porteret 

eller ej 

- Man skal kunne tilføje en hel nummerserie (fra nr. til nr.) 

- Man skal kunne sætte et tidsrum som numre skal henligge, før de må 

bruges igen 

- Man skal kunne nedlægge numre og indikere om det skal udporteres 

eller må genbruges 

Liste over E-mail i systemet: 

- Brugeren skal selv kunne oprette en mail adresse (simuleres) 

- Brugerens E-mail adresse(r) nedlægges 6. mdr. (eller en periode som 

kan ændres) efter opsigelse 

Der skal kunne laves søgninger som admin selv definerer. 

Der skal være adskillige sorteringsmuligheder: 

- foreningskontorer/kontaktpersoner 

- udstyrsspecifik 

- services specifik 

- ledig fiberflow 

- osv. osv. 

Alle lister skal kunne redigeres: 

- Det skal altid være muligt at tilføje noget nyt (forudsat at det ikke 

findes i forvejen) 

- Der kan kun fjernes udstyr/adresser/etc., som IKKE har relationer til 

noget/nogen 

Administrationsdelen skal logføre alle ændringer, så det altid er muligt at 

spore, hvilken admin som har foretaget ændringer i oplysninger/relationer i 

databasen. 



15.2 Bilag 2 – Billede af krydsfeltet b16x16 

Øverst i billedet ses patchpanelerne, hvori ledningerne til lejlighederne er tilsluttet. 

De to lilla komponenter er Extreme Summit 200 switche med 24 porte 

De to blå komponenter er Audiocodes MP 124 VOIP gateways med 24 porte 

Den sorte skuffe med de grønne stik er forbindelsen til Parknet via lysleder 

I bunden af skabet ligger en UPS til ca. 2 timers drift. 



15.3 Bilag 3 – billeder af TV skab 

De to sorte ledninger er forsyningskabler fra antenneforstærkeren (sidder centralt) 

Øverst til højre i skabet sidder TV fordeleren - i fordeleren sidder pakkefiltrene 

De hvide ledninger går ud til lejlighederne 

Et pakkefilter er et lavpasfilter. Parknet har 4 TV pakker, dvs. der er brug for 3 

typer filtre (der er ikke filter på den dyreste pakke). 

- Lille pakke er alle kanaler under 400 MHz (filteret er umalet dvs. blankt) 

- Mellem pakke er alle kanaler under 566 MHz (filteret er gult) 

- Stor pakke er alle kanaler under 750 MHz (filteret er blåt) 

- Super pakke kræver ikke filter, ledningen er monteret direkte i fordeleren. 

Hvis TV skal frakobles eller ændres, skal der en tekniker ud HVER gang… 

Billede af et TV skab med mellem og stor pakke tilkoblet 



Billede af et TV skab med super, lille og stor pakke tilkoblet 



15.4 Bilag 4 – Indhold på CD-rom: 

/Code 

/DB 

/SAPS 

/Docs 

rapport.doc 

datakatalog.doc 

/Install 

/1 – Java Runtime 

/2 – MySQL server 

/3 – MySQL GUI tools 

/4 – SAPS 



15.5 Bilag 5 – Installationsvejledning til SAPS 

Jeg vil anbefale, at besøge SAPS via linket på forsiden af rapporten. Når SAPS kører 

på en PC uden adgang til Miralix, er der ventetid på 20 sekunder, ved hvert klik. 

Installationen af SAPS er en 4-trins raket bestående af: 

1) Java runtime 

2) MySQL server 

3) MySQL GUI tools 

4) Tomcat server med SAPS filer 

Alle programmer er på Cd’en i folderen /Install og skal køres i denne rækkefølge: 

/1 – Java Runtime (kør filen J2SE-RE.msi) 

/2 – MySQL server (kør filen mysql-5.1.33-win32.msi og følg nedenstående 

vejledning): 

1) Klik next 

2) Vælg typical 

3) Klik install 

4) Klik next 

5) Klik next 

6) Vælg config now 

7) Klik next 

8) Vælg standard config 

9) Klik next 

10) Vælg password til brugeren root (fx password) 

11) Klik next 

12) klik execute og derefter finish 

/3 – MySQL GUI tools (kør filen mysql-gui-tools-5.0-r17-win32.msi og vælg 

complete installation) efter installationen gør da følgende: 

1) Åben MySQL administrator og opret forbindelse til MySQL serveren 

a. Server Host: localhost 

b. Port: 3306 

c. Username: root 

d. Password: password 

2) Vælg restore fra menuen til venstre 

3) Klik ”Open backup file” nederst til højre på skærmen 

4) Vælg filen /Install/saps_init().sql 

5) Klik ”Start restore” nederst til højre på skærmen 

6) Klik ”User administration” i menuen til venstre 

7) Klik ”Add new user” nederst til højre på skærmen 

a. MySQL User: saps 

b. Password: hipshej 

c. Confirm Password: hipshej 

8) Klik ”Schema Privileges” øverst på skærmen 

9) Klik på SAPS 

10) Klik på knappen


15.6 Bilag 6 – Brugermanual til SAPS 

SAPS består af to dele: 

- onlinetilmelding (åben for alle brugere på Internettet) 

- administrationsdel med roller (lukket med login og rettigheder er rollebaseret) 

o administrator 

o bogholder (accountant) 

o supporter 

o bruger (user) 

Administrationsdelen: 

Der er fire roller til brugere i systemet: 

- Accountant (bogholder) 

- Administrator 

- Supporter 

- User (bruger) 

Via administratorrollen kan alle de øvrige brugere oprettes, systemet leveres med 

opstarts administrator, så systemet kan startes op (opret din egen administrator og 

deaktiver opstarts administratoren): 

Brugernummer: 11111111 

Password: password 

Hver rolle har adgang til følgende sider: 

På velkomstsiden for alle brugere (med undtagelse af user rollen) vises brugbar 

sammentælling af punkter på to do lister, udgående/indgående porteringer, 

telefonnumre og antal online tilmeldinger, som kræver aktion fra en Parknet 

medarbejder. 

Accountant: 

- Kan se, rette og tilføje start-, slut og skæringsdatoer for abonnementer i SAPS. 

- Kan se opkrævninger i SAPS. 

- Kan søge på adresser i SAPS med vejnavn og evt. opgangsnummer og se tilmeldte 

brugere samt tilmeldingsdetaljer. 

Administrator: 

- Kan se to do liste for TV og klikke ”Done” til evt. kørsler. 

- Kan se, rette og tilføje brugere samt ændre deres rettigheder. 

- Kan se rollerne i systemet. 



- Kan se, rette og tilføje foreninger, veje, numre, etager og sider til SAPS. 

- Kan tilføje nye adresser til SAPS samt fjerne adresser, som ikke har tilknyttet services. 

- Kan se og tilføje krydsfelter til SAPS, samt fjerne krydsfelter som ikke har tilknyttet aktivt 

udstyr. 

- Kan se, rette og tilføje aktivt udstyr med antal porte til SAPS. 

- Kan se, rette og tilføje aktivt udstyr til et krydsfelt. 

- Kan rette krydsfeltoplysninger pr. adresse i SAPS samt angive om adressen skal vises i 

onlinetilmeldingen. 

- Kan rette eller tilknytte en adresse i SAPS til et stykke aktivt udstyrs port. 

- Kan se, rette og tilføje services i SAPS. 



- Kan rette Copydan priser i SAPS. 

- Kan angive de services som er ”standard services” i SAPS. 

- Kan rette farver til TV pakker, abonnementsstatus og portstatus. 

- Kan tilføje/fjerne services pr. adresse i SAPS. 

- Kan tilføje ”standard services” til en hel forening i SAPS. 

- Kan se og rette telefonnummerstatus og hemmeligt/skjult nummer i SAPS. 

- Kan se, rette og tilføje telefonnumre til SAPS samt se og ændre deres status. 

- Kan se og rette valideringsstrenge til online tilmeldingen. 

- Kan se og rette MIB’er til SNMP kommandoer. 

- Kan se, rette og tilføje ticket typer til SAPS. 

- Kan se, rette og tilføje start-, slut og skæringsdatoer for abonnementer i SAPS. 

- Kan se opkrævninger i SAPS. 

Supporter: 

- Kan se to do liste for TV og klikke ”Done” til evt. kørsler. 



User: 

- Kan se hvilke services, der abonneres på samt servicens tilmeldingsdato. 

- Kan opsige en tilmeldt service. 



FÆLLES FUNKTION FOR ALLE ROLLER UNDTAGEN ”USER”: 

Ved at klikke på ”Søg adresser og brugere” vises to søgefelter. I det første skal hele 

eller en del af vejens navn indtastes, hvis brugeren ønsker at indsnævre sin søgning, 

er det muligt også at taste et opgangsnummer. 

Hvis der findes adresser i SAPS ud fra søgekriterierne vises de på skærmen. Pr. 

adresse vises altid adressen, postnr. og x-felt. Hvis der er en bruger tilmeldt adressen, 

vises brugerens ID, fornavn og efternavn. I kolonnen ”aktive yd.” vil feltet være grønt, 

hvis der er mindst én aktiv service og ellers rødt. Ved at klikke på krydsfeltets navn, 

vises et kortudsnit med placeringen af krydsfeltet. Ved at klikke på adressen skiftes til 

et nyt skærmbillede. 

På det nye skærmbillede præsenteres adressen med postnr., bynavn, forening og xfelt. 

Herunder står brugerens id, oprettelsesdato, fornavn, efternavn, password, telefon 

nr., mobil nr., e-mail og rettigheder i SAPS. Hvis der ikke er tilmeldt en bruger, står det i 

klar tekst. Derefter vises Parknets tre services i hver deres felt (uddybes længere 

nede). Hvis den pågældende service ikke kan tilmeldes på adressen, står det i klar 

tekst. Nederst står tickets med mulighed for at tilføje en ny ticket til systemet. Det er p.t. 

ikke muligt at rette eller på anden måde løse tickets i SAPS. 

For Internet og telefoni vises tilmeldingsdato, frameldingsdato, tilmeldingsstatus ud fra 

datoerne (grøn hvis tilmeldt eller rød), aktuel status for hhv. Internet og telefon hentes 

fra det aktive udstyr i krydsfeltet og præsenteres med den farve administratoren har 

valgt (standardfarverne er: grøn = aktiv, rød = inaktiv, sort = intet svar fra det aktive 

udstyr), x-felt, patch panel nr., switch navn og port nr. For Internet vises evt. WAN IP 

og derefter to knapper til at åbne eller lukke brugerens port i switchen. For telefoni 

vises abonnementstypen (flatrate eller almindelig), betalingsmåde (auto eller manuel), 

om nummeret er skjult/hemmeligt/udeladt, Miralix konto nr., saldo på telefonkontoen. 

Der er p.t. ingen funktioner til telefoni. 

For TV vises tilmeldingsdato, frameldingsdato, tilmeldingsstatus ud fra datoerne (hvis 

TV er tilmeldt vises TV pakkens farve lille = sølv, mellem = gul, stor = blå, super = 

grøn, hvis ikke tilmeldt = rød). Status for TV på adressen hentes fra databasen (ud fra 

hvad den var sidst). Under x-felt står der enten ”trappe” eller navnet på x-feltet, patch 

panel nr., TV pakke, pakkeskift dato (hvis pakkeskift er valgt), skift TV pakke til (hvis 

pakkeskift er valgt) og til slut funktion. Hvis der er en bruger tilmeldt på adressen, som 

ikke abonnerer på TV, kan man under funktion klikke på ”Tilmeld TV” – tilmeldingsdato 

og TV pakke SKAL vælges, før der klikkes på ”Tilmeld TV”. Hvis brugeren er tilmeldt 

TV vises knappen ”Ret”. Ved at klikke på den, bliver det muligt at vælge dato for 

pakkeskift og den nye pakke. Når der klikkes på OK, tilføjes en ticket om, at der er 

valgt ændring til TV pakken. Derudover tilføjes en opkrævning på brugerens adresse 

med gebyret fastsat i services. Ændringen vil kunne ses på TV to do listen med dato 

for udførelse (deadline dato). 



Brugervejledning til ”User”: 

Når en user er logget ind, viser systemet de services, der abonneres på samt 

tilmeldingsdatoen. 

Ved at klikke på ”Opsig services” får user mulighed for at framelde aktive services. Ved 

at klikke på ”Frameld” ud for en service, aktiveres en menu i frameld dato kolonnen. 

Her skal der vælges en frameldingsdato, hvis user derefter klikker ”Ja”, vil den valgte 

dato blive sat ind under frameld dato kolonnen og ”Frameld” knappen forsvinder. 

Derudover har systemet skrevet en ticket i SAPS, hvori der står at user via 

selvbetjening har opsagt den pågældende service. Hvis det var TV, som blev frameldt, 

vil der også stå en frakobling på TV to do listen med frameldingsdatoen. 

Brugervejledning til ”Accountant”: 

Systemet viser sammentælling fra de forskellige lister på forsiden. 

Ved at klikke på ”Start og opsigelses datoer” bliver det muligt at rette disse datoer. 

SAPS leveres med start datoer til den første i hver måned og opsigelsesdatoer til 

udgangen af et kvartal. Start datoerne bruges i onlinetilmeldingen og slut datoerne 

bruges når en user vil framelde en service. Der kan p.t. ikke fjernes linjer fra systemet. 

Derudover kan der sættes to skæringsdage i systemet. Den ene er tilmeldingsdage før 

skæring. Tilmelding før denne dato, skal betales fra den første i indeværende måned 

og tilmelding efter, skal betales fra den næste første (værdien er sat til 10). 

Opsigelsesdage før kvartal er det opsigelsesvarsel, som Parknet skal bruge (værdien 

er sat til 25). 

Ved at klikke på ”Opkrævninger” vises opkrævninger i systemet. Der er p.t. ikke 

mulighed for at foretage nogen behandling af disse opkrævninger. 

Ved at klikke på ”Services og priser” vises alle services i SAPS. FUnique er servicens 

ID nr. 100 – 199 bruges til Internet, 200 – 299 bruges til telefoni, 300 – 399 bruges til 

TV. Servicens Navn bruges i SAPS, servicens Fakturatekst bruges i online tilmeldingen 

samt på opkrævninger til brugerne. Engangs angiver om det er et gebyr. EngangsPris 

angiver gebyrprisen, men anvendes ikke p.t. PrisAngives er det beløb som vises på 

onlinetilmeldingen og bruges på opkrævninger. Kategori angiver servicens kategori. 

MedtagInet angiver om servicens bliver præsenteret i online tilmeldingen. 

Ved at klikke ”Ret” ud for en service, bliver det muligt at rette alt til den service med 

undtagelse af FUnique. 

Nederst i skærmbilledet kan en ny service tilføjes. Det FUnique, som står udfyldt, er 

autogenereret af systemet ved at lægge 1 til det nuværende højeste FUnique (p.t. står 

der 315). Alle tal, som ikke allerede er i brug, må anvendes. Hvis der vælges et tal, 

som er i brug, kommer der en lang fejlmelding. Klik på ”tilbage” i browseren og vælg et 

andet tal. 

Ved at klikke ”Copydan priser” kan priserne og fakturatekst for ophavsrettigheder på de 

forskellige TV pakker rettes. 



Brugervejledning til ”Supporter”: 


Ved at klikke på ”TO DO TV” vises en liste over adresser, hvor der skal skiftes TV 

pakke. Listen er sorteret efter dato, postnr, x-felt og dernæst efter adresse. Først vises 

rækkens ID i SAPS, adressen, postnr., x-felt (trappe eller navn), kabel nr. (hvis muligt), 

nuværende pakke, den nye pakke, deadline samt en ”Done” knap. Når der klikkes på 

”Done” forsvinder rækken fra listen og TV pakken opdateres hhv. på adressen og på 

brugerens oversigt. 

Ved at klikke på ”Vis/ret brugere” vises alle brugere i systemet sorteret efter rolle. 

Brugerens oplysninger kan rettes ved at klikke på ”Ret”, dog kan ID, rolle og aktiv ikke 

ændres. 

Brugervejledning til ”Administrator”: 


Ved at klikke på ”Vis/ret/tilføj brugere” vises alle brugere i systemet sorteret efter rolle 

og dernæst efter navn. Brugerens oplysninger kan rettes ved at klikke på ”Ret”, dog 

kan ID ikke ændres. Det er muligt at tilføje nye brugere til SAPS samt at angive deres 

rettigheder i SAPS. 

Ved at klikke på ”Vis roller” vises rollerne i SAPS. Disse kan ikke redigeres eller slettes. 

Der kan heller ikke tilføjes nye. 

Ved at klikke på ”Foreninger, veje, numre, etager og sider” kan der rettes og tilføjes 

nye til SAPS. Det er ikke muligt at slette dem igen. Oplysningerne fra denne side 

bruges til at tilføje adresser til SAPS. 

Ved at klikke på ”Tilføj/fjern adresser” vises adresser i systemet. Øverst vises en drop 

down boks med veje i SAPS. Hvis der endnu ikke er tilføjet nogen veje, er menuen 

tom. Ved at vælge en vej viser systemet alle adresser på den pågældende vej. Vejene 

vises med adresse, forening, postnr. og en funktion. Hvis adressen har tilknyttet 

services i SAPS, kan adressen ikke fjernes. Ellers vil der være en knap med teksten 

”Fjern”. 

Nederst på skærmbilledet er det muligt at tilføje en ny adresseserie. Vælg vejen, nr. fra 

og nr. til (der tilføjes hvert andet nr.), opgangsbogstav fra og til (udfyldes kun, hvis det 

er aktuelt), etage fra og til, antal sider pr. etage, postnr. og foreningens navn. Ved at 

vælge fx Tornsangervej fra 1 til 13, udelade opgang, etage fra st. til 2., 2 sider, postnr. 

2400 og A/B Lindegaarden, genereres alle opgange på den ulige side fra 1 til 13. Hvis 

der er sammenlagte lejligheder, skal disse tilføjes efterfølgende én af gangen og de 

overflødige adresser slettes. Enkeltadresser tilføjes ved at vælge de samme værdier i 

fra og til samt at angive antallet af sider til 1. 

Ved at klikke på ”Vis/opret krydsfelter” kan man søge i krydsfelterne i SAPS, ved at 

vælge enten bloknummer eller vejnavn fra drop down menuerne. Hvis der findes 

krydsfelter i blokken eller på vejen vises det/de med ID, navn, adresse, postnr. og en 

funktion. Hvis der er tilknyttet aktivt udstyr til krydsfeltet kan det ikke fjernes. Ellers vil 

der være en knap med teksten ”Fjern”. 

Det er muligt at tilføje et nyt krydsfelt til SAPS nederst i skærmbilledet. Vælg vej, nr., 

evt. bogstav, etage, blok nr., postnr. og klik ”Tilføj”. Det ID som krydsfeltet tildeles af 

SAPS bliver brugt som reference til et jpg billede af krydsfeltet. Billedet bør være et 



udsnit fra krak.dk, hvorpå krydsfeltet er vist med navn og placering. Billedet lægges i 

folderen: 

ROOT/authorized_users/images 

Med filnavnet: ”id.jpg”, hvor ID erstattes med det ID som SAPS har tildelt krydsfeltet. 

Ved at klikke på ”Aktivt udstyr” vises en liste over aktivt udstyr i SAPS. Det er muligt at 

rette eksisterende udstyrs navn og antal af porte, samt at tilføje nyt. Der kan ikke 

slettes udstyr. 

Ved at klikke på ”Udstyr i x-felt” vises en valg menu, hvorfra man skal vælge et x-felt. 

Hvis der endnu ikke er tilføjet x-felter til SAPS, er menuen tom. Når krydsfeltet er valgt, 

vises det udstyr, som er i krydsfeltet med navn, login og password (som bruges til 

SNMP kommandoer), serienr., type, start dato og funktion. Det er muligt at rette alle 

oplysninger på tilføjet udstyr, men det kan ikke slettes. Nederst på skærmbilledet er der 

mulighed for at tilføje aktivt udstyr til krydsfeltet. 

Ved at klikke på ”Adressedata i x-felt” vises oplysninger om, i hvilket krydsfelt og hvor i 

krydsfeltet de forskellige adresser er tilsluttet, samt om adressen skal vises i online 

tilmeldingen. Hvis TVPatch ikke udfyldes antager SAPS, at TV tilslutningen sidder i 

opgangen. 

Ved at klikke på ”Adresser og porte” vises en valg menu, hvor man skal vælge den vej, 

man vil se oplysninger om. Hvis der ikke er tilføjet veje til SAPS, er menuen tom. Når 

der er valgt en vej, vises adressen samt hvilket aktivt udstyr og port, adressen er 

tilsluttet til. Dette kan rettes, men ikke slettes. Nederst på skærmbilledet kan adresser 

tilknyttes yderligere aktivt udstyr. Når der er valgt en adresse og udstyrs navn henter 

SAPS det antal porte, som er angivet i ”Aktivt udstyr”. Dermed bliver det umuligt at 

vælge porte, som ikke eksisterer. Der er ikke noget tjek for, om en port allerede er 

tilknyttet en anden adresse, så vær omhyggelig med denne proces. 

”Services og priser” og ”Copydan priser” er beskrevet under bogholder. 

Ved at klikke på ”Definer std. services” er det muligt at definere de services, som kan 

tilføjes til en adresse eller forening med ”Tilføj standard services” knappen. Alle 

services i SAPS er vist og det indikeres med rød eller grønt om servicen er en del af 

standard services. Hvis servicen er valgt til, er status grøn og knappen hedder ”Fjern 

service” ellers er status rød og knappen hedder ”Tilføj service”. Ved klik på knappen 

opdateres servicen og siden. Ændringer vises med det samme. 

Ved at klikke på ”Farver til services” er det muligt at redigere de farver som vises i 

SAPS. Farven har en ID, kode (som henfører til den kode, der står i services), farve, 

vist farve og mulighed for at rette. Ved at klikke ”Ret”, kan koden og farven ændres i 

tekst. Hvis den indtastede farve ikke er en HTML farve, vises ingen farve, så det er 

muligt at rette evt. fejl med det samme. Der kan tilføjes nye farver til systemet, men de 

vil ikke kunne bruges uden ændringer i programmet. 

Ved at klikke på ”Services pr. adresse”, kan services tilføjes og fjernes fra adresser i 

SAPS. Adressen vælges fra menuen og siden viser, hvilke services, der kan vælges. 

Hvis alle services er røde (dvs. fravalgt), kan knappen ”Tilføj standard services” 

bruges. 



Ved at klikke på ”Services pr. forening” kan der tilføjes standard services til alle 

adresser i en forening. Foreningen vælges fra menuen og derefter klikkes på ”Tilføj 

standard services”, vær dog opmærksom på, at evt. specialadresser skal have fjernet 

visse services efterfølgende. Fx er der mange fyrrum, hvor der kun er Internet 

tilslutning. 

Ved at klikke på ”Telefon nr. status” vises de statusser, som et telefon nr. kan have i 

SAPS. Det er også muligt at tilføje en ny status, hvis det er nødvendigt. Status kan 

ændres via ”Telefon nr. i Parknet”. Der vises også de muligheder for hemmeligt/skjult 

nummer, som er i SAPS. Her kan også tilføjes nye. 

Ved at klikke på ”Telefon nr. i Parknet” vises alle telefonnumre i SAPS sorteret efter 

nummer. Øverst i skærmbilledet er det muligt at tilføje nye numre til SAPS. Numre som 

tilføjes på denne måde, må ikke være numre, som skal porteres. Det skal være en 

ledig nummerserie som Parknet har købt. Ud for hvert nummer vises oprettelses dato, 

dato for hvornår nummeret blev OK, hvornår nummeret ophørte i SAPS (null hvis 

nummeret er i brug), nummerets status og en funktionsknap. Ved at klikke ”Ret”, åbnes 

mulighed for at rette OK dato, slut dato og nummerets status. 

Ved at klikke på ”Valideringsstrenge til online opret” vises de tre valideringsstrenge, 

som bruges i online tilmeldingen. SAPS leveres med strenge til validering af hhv. navn, 

tlf. nr. og e-mail. Men hvis der på et tidspunkt sker ændringer i tilladte/ikke-tilladte tegn, 

kan valideringen ændres her. 

Ved at klikke på ”MIB’er til SNMP” er det muligt at rette de tre MIB som SAPS leveres 

med. Der kan rettes MIB til hhv. en ports status, åben port og luk port. 

Ved at klikke på ”Rediger ticket typer” vises de ticket typer som er i SAPS. De er 

sorteret efter navn. Det er muligt at rette navnet på tickets, men det bør ikke gøres, 

efter at SAPS er sat i drift. Det vil medføre at oprettede tickets risikere at ændre emne. 

Det er muligt at tilføje nye tickets til SAPS. 



Online tilmelding: 

Online tilmeldingen er struktureret og programmeret til at være så intuitiv som 

overhovedet muligt. Det skal med et minimum af besvær og hovedbrud, være muligt for 

alle at tilmelde sig til Parknet uanset alder, IT fagkundskab og baggrundsviden om 

Parknet. 

Tilmeldingen består af fire trin. For hvert trin vises, hvor langt brugeren er nået i 

tilmeldingsprocessen. 

Trin 1: 

Brugen vælger sin adresse, blandt de adresser i SAPS hvor ”showinet” er 1. Først 

vælges post nr. fra drop down menu. Herefter skal brugeren vælge sin gade. Derefter 

skal brugeren vælge sin adresse på gaden. Så kan brugeren klikke ”Næste”. 

Trin 2: 

Brugeren skal indtaste sit fornavn og efternavn før systemet tillader brugeren at 

fortsætte – det vises ved, at ”Næste” knappen ikke kan bruges og at der står i klar tekst 

over knappen: ”Du skal skrive for- og efternavn før du kan klikke næste”. Det er ikke 

nødvendigt at udfylde hhv. mobil tlf., fastnet tlf. eller E-mail, men hvis felterne udfyldes, 

bliver de valideret ud fra de valideringsstrenge, som er indtastet i SAPS. Under kassen 

med brugeroplysningerne vises de services, som kan vælges på adressen. Hvis 

servicen ikke kan vælges står der: ”Den valgte adresse har ikke den service fra 

Parknet”. 

Brugeren skal tilmelde mindst én service, før der kan klikkes ”Næste” (står over 

knappen). Hvis Internet vælges, får brugeren mulighed for at angive et ønske til en email 

adresse. Teksterne til menuerne for telefon og TV er fakturateksterne, som er 

angivet i SAPS under ”Services”. Ønsket start fra TV kommer dog fra startdatoer. 

Tekstfelter i trin 2 bliver strippet for HTML tegn, så det ikke er muligt fx at eksekvere 

scripts. Derudover bliver alle valgte ID’er kontrolleret, for at sikre, at brugeren ikke har 

rettet noget. 

Trin 3: 

Brugeren præsenteres for sine valg, samt pris for oprettelse og den månedlige pris 

fremover. Brugeren skal acceptere Parknets abonnementsvilkår og priser, før der kan 

klikkes ”Næste”. Der er link til vilkårene i tilknytning til fluebenet, hvor vilkårene skal 

accepteres. 

Trin 4: 

Brugeren er nu oprettet. Hvis der var en tilmeldt bruger på adressen, bliver den nye 

bruger lagt i en temp tabel og bliver oplyst om, at en Parknet medarbejder skal 

behandle tilmeldingen manuelt. Ellers vises brugerens brugernummer og password. 

Der er link til hhv. tilmelding til Betalingsservice og Parknets hjemmeside. Tilmelding til 

Betalingsservice foregår via https direkte hos PBS. Formularen er preudfyldt med de 

oplysninger, som er tilgængelige i SAPS. 

Note: 

Hvis brugeren klikker på tilbageknappen i browseren og prøver at foretage endnu en 

tilmelding, vises en fejlmeddelelse til brugeren om, at det ikke kan lade sig gøre.

02329: Datateknisk produktudvikling - Danmarks Tekniske Universitet

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?