Niels Brock

Datamatikeruddannelsen

Forår 2001

Programmering af store systemer

Hold 462211

Trouble tickets

Denne opgave er stillet på hold 462211 på datamatikeruddannelsen ved Niels Brock åben uddannelse forår 2001. Opgaven udleveres mandag den 2. april 2001 og besvarelsen af opgaven skal afleveres på papir i tre eksemplarer senest mandag den 21. maj 2001 til læreren. Sammen med hver kopi af besvarelsen skal der afleveres en diskette med jeres implementation. Opgaven skal besvares i grupper på 2–3 personer. Opgaven kan eventuelt besvares individuelt efter aftale med lærererne.

Opgaven er at konstruere et system til at håndtere logistikken bag fejlmeldinger og reparationer i et teleselskab. Denne opgave er løst baseret på de anbefalinger og standarder, der anvendes internationalt inden for telekommunikation. Formålet med jeres system er dels at sikre, at medarbejderne kan få adgang til alle oplysninger de skal bruge til at finde og rette fejl, dels at sikre, at alle procedurer for fejlhåndtering overholdes, så man er sikker på at alle fejl bliver rettet korrekt.

Beskrivelse af arbejdsgangen omkring fejlmeldinger

Dette afsnit beskriver, hvad der sker, når der indløber en fejlmelding til teleselskabet. Fejlmeldinger kan i denne opgave modtages på to måder:

1. Kunder ringer og rapporterer et problem. Disse fejlmeldinger modtages af en medarbejder, der noterer en beskrivelse af kundens problem sammen med oplysninger om hvilken kunde, der har indrapporteret problemet og hvilken medarbejder, der har modtaget fejlmeldingen
2. Teknikere kan indrapportere, når de finder et problem under deres arbejde. I dette tilfælde noteres hvilket stykke udstyr der har problemer, en beskrivelse af problemet og hvilken medarbejder, der har indrapporteret problemet.

Hver fejlmelding vurderes af en tekniker og giver anledning til at der åbnes en eller flere trouble tickets, der indeholder en beskrivelse af et stykke arbejde, der skal udføres for at afhjælpe fejlen. Hver trouble ticket tildeles en tekniker, som har ansvaret for trouble ticketen, og hvis job det er løse en af de opgaver, som er nødvendige for at finde og reparere fejlen.

Når en tekniker modtager en trouble ticket, er han ansvarlig for den, indtil den kan lukkes eller overdrages til en anden. En trouble ticket kan kun lukkes, når det arbejde, der er beskrevet i trouble ticketen er udført, eller der er åbnet en anden trouble ticket til erstatning for den. Det sidste sker normalt, fordi en tekniker opdager, at fejlen ligger et andet sted end oprindelig antaget.

Hvis en tekniker reparerer et stykke udstyr for at lukke en trouble ticket, noteres reparationen i en reparationslog hørende til udstyret og man noterer hvilken trouble ticket, der gav anledning til reparationen, og hvad der blev repareret.

Beskrivelse af de centrale objekter i systemet

I det følgende gennemgås de centrale objekter i systemet, hvilke krav der er til deres opførsel, og hvilke oplysninger der skal registreres for hvert objekt.

Kunder

For hver kunde skal man registrere navn, adresse og telefonnummer. Man skal kunne oprette og nedlægge kunder i systemet, og man skal kunne ændre kundeoplysningerne. Der er intet krav om, at man skal kunne spore ændringer af data for kunder

Medarbejdere

For hver medarbejder skal man registrere navn og initialer. Man skal kunne oprette og nedlægge medarbejdere i systemet, og man skal kunne ændre stamoplysningerne. Der er intet krav om, at man skal kunne spore ændringer af data for medarbejdere.

Fejlmeldinger

For fejlmeldinger skal man kunne registrere følgende data: Hvem der indgav fejlmeldingen, hvilken medarbejder der modtog den, en beskrivelse af fejlen, hvilket tidspunkt fejlmeldingen er indkommet, hvor alvorlig fejlen er, evt. hvilket stykke udstyr der er problemer med og om fejlen er rettet eller under udbedring. Alvorligheden af en fejlmelding angives som en af tre muligheder: Kritisk, større eller mindre. Man kan ikke markere, at en fejl er rettet, hvis fejlmeldingen stadig er knyttet til trouble tickets, som ikke er lukket.

Man skal kunne oprette nye fejlmeldinger i systemet, og man skulle kunne rette oplysningerne om en fejlmelding med korrekt logning af ændringer og check af, at ændringerne ikke er ugyldige. Systemet skal altid kunne præsentere en liste af alle fejlmeldinger, det skal være muligt at filtrere rettede fejl fra, og det skal være muligt at sortere listen efter fejlmeldingens alvorlighed eller det tidspunkt, den er indrapporteret på.

Alle fejlmeldinger skal gemmes i mindst fem år, eftersom de skal bruges i regnskabsøjemed. Derfor skal alle ændringer til en fejlmelding logges, så der bliver registreret hvem, der har ændret fejlmeldingen, hvornår den er rettet, præcis hvad der er rettet, og hvordan fejlmeldingen så ud før rettelsen.

Trouble tickets

En trouble ticket er knyttet til netop en fejlmelding. For en trouble ticket registreres desuden, hvornår trouble ticketen er oprettet, hvilken medarbejder der har ansvaret for den og trouble ticketens tilstand. Hvis en trouble ticket er oprettet til erstatning for en anden trouble ticket, skal den oprindelige trouble ticket registreres.

En trouble tickets tilstand kan være enten åben, tildelt eller lukket. Når trouble ticketen oprettes er den åben. Derefter er den eneste gyldige rettelse, der derefter kan foretages, at der knyttes en tekniker til trouble ticketen, hvorefter trouble ticketens tilstand ændres til tildelt. En tildelt trouble ticket kan ændre tilstand ved at blive tildelt til en anden tekniker, ved at trouble ticketen lukkes sammen med den tilhørende fejlmelding eller ved at der oprettes en ny trouble ticket som erstatning for den aktuelle trouble ticket. Alle ændringer til en trouble ticket skal logges, så der bliver registreret hvem, der har ændret trouble ticketen, hvornår den er ændret, præcis hvad der er ændret, og hvordan trouble ticketen så ud før ændringen. Alle trouble tickets gemmes i mindst fem år, inden de slettes.

Man skal kunne oprette nye trouble tickets i systemet, og man skulle kunne rette oplysningerne om en trouble ticket med korrekt logning af ændringer og check af, at ændringerne ikke er ugyldige. Systemet skal altid kunne præsentere en liste af alle trouble tickets, og det skal være muligt at filtrere lukkede trouble tickets fra. Det skal desuden være muligt at sortere listen efter den tilhørende fejlmeldings alvorlighed eller det tidspunkt, trouble ticketen er oprettet på. For hver fejlmelding skal det desuden være muligt at se alle de tilknyttede trouble tickets sammen oplysningerne om den.

Udstyr og reparationslogge

I denne opgave skal der registreres to ting om hvert stykke udstyr: Et udstyrsnummer og en linies beskrivelse af udstyret. Til hvert stykke udstyr skal der knyttes en reparationslog. Reparationsloggen skal indeholde en oplysning for hver reparation: Tidspunktet for reparationen, hvilken medarbejder der stod for reparationen og en beskrivelse af, hvad der er blevet repareret. Ingen af disse oplysninger slettes, sålænge udstyret er i drift. Systemet skal kunne oprette og nedlægge udstyr og oprette nye oplysninger i reparationsloggen, og det skal kunne vise alle oplysninger sorteret efter alder med de ældste først. Når et stykke udstyr nedlægges skal alle oplysninger i den tilhørende reparationslog slettes.

Krav til besvarelsen

Jeres besvarelse af opgaven skal bestå af en rapport der indeholder en afklaring af de semantiske unøjagtigheder, der måtte være i opgaveteksten sammen med en beskrivelse af designet for jeres implementation. Desuden skal jeres besvarelse indeholde en implementation af det beskrevne system. Denne implementation skal foretages i C++ ved hjælp af Borland Builder og databasekomponenterne i Builder. Beskrivelsen skal indeholde en gennemgang af hvilke klasser, der indgår i implementationen og hvordan instanser af disse arbejder sammen. I kan eventuelt udforme dette som et UML-diagram. Derudover skal opgaven inkludere følgende

1. En beskrivelse af hver klasses design. Denne del skal beskrive de vigtigste attri­butter for hver klasse, hvad deres anvendelse er, samt metoderne i klasserne og deres forud­sæt­­ninger og resultater. Hvis I foretrækker det, kan I indsætte beskrivelser af metoder og attributter som kommentarer i programmet.
2. Brugergrænsefladen skal indeholde nogle velvalgte komponenter, der understøtter de informationer der behandles i systemet og der skal kort argumenteres for valget.
3. Et database-diagram (ER-diagram), der viser felter i, og relationerne mellem, de enkelte tabeller i systemet.
4. En afprøvning. Denne del skal fremtræde overbevisende og systema­tisk, så den kan sand­syn­liggøre, at Jeres implementation virker efter hensigten. Hvis afprøv­ningen af­slører proble­mer, bedes deres årsag diskuteret her.
5. En kort evaluering af opgaven, inklusive et estimat for Jeres tidsforbrug til løsningen af opgaven.