Rapport

Gruppe 5:	Niels Brock
Lars Finne-Larsson	Åben uddannelse
Niels Grove-Rasmussen	Datamatiker
Mikkel Munksgaard	Videregående systemudvikling (vsu)
Michala Møller	Hold 442122

Forord

Begrundelse for valg

I forbindelse med datamatikermodulet videregående systemedvikling (vsu) stod vi og skulle finde en virksonhed og et projekt. Det viste sig hurtigt at atp allerede havde lagt an til et inventory-projekt med eksterne resurser.

Da vi fandt projektet interessant og atp var klar til at tilpasse projektet til vores tidsplan og behov, var det hurtig at lave en aftale mellem os og atp-husets projektledelse.

Rapport

Opsætningen er som krævet af Niels Brock til rapporten under modulet grundlæggende systemudvikling (gsu). Det vil sige venstre- og højremargin på 2 cm med 1 cm indbindingsmargin, top- og bundmargin på 2,5 cm.

Linjeafstanden er sat til 1½ - som angivet af Niels Brock.

Teksten er skrevet med proportional skrifttype. Vi har valgt TrueType^© skrifttypefamilierne Garamond til brødtekst og Futura Md Bt til overskrifter.

Alle skrifttypefamilierne benyttes som udgangspunkt i en punktstørrelse på 12 typografiske punkter, hvilket er efter Niels Brocks anvisninger. Skalering sker efter WordPerfects standard.

Problemformulering og projektbeskrivelse

Problemformulering

atp-huset ønsker sig et system, der kan lagre vigtige informationer om husets client/server inventory⁽¹⁾.

Der findes allerede et system, men det virker ikke optimalt, da det er besværligt i brug og kræver for meget arbejde i hverdagen.

Systemet skal blandt andet omhandle systemenheder, forsikringsoplysninger og brugertilknytning.

I samarbejde med atp-huset vil vi lave et system, der baseres på eksisterende systemer i IT-installationen; databaser og software. Nye oplysninger vil dels blive indsat, dels dannet af ny datastruktur.

Afgrænsning

Validering af eksisterende data, også efter konvertering, foretages af atp-huset.

Systemkonventering af tabelstruktur fra Access til DB/2 foretages af atp-huset.

Systemet skal ikke kunne registrere software, for eksempel operativsystem, applikationer eller drivere.

Endelig installation på atp-husets systemer foretages hovedsagligt af atp-huset.

Arbejdet med af udarbejde og iværksætte passende forretningsgange og procedurer til Inventory-systemet er atp-husets.

Metoder og plan

Gruppemøder cirka hver anden søndag. Der er i atp-huset en projektledelse vi løbende holder kontakt med, da dette projekt afløser et planlagt.

Plan ifølge læseplan... Vi udveksler løbende idéer, tanker og resultater med projektledelsen i atp-huset.

Internt i gruppen har vi ingen gruppeleder på grund af erfaringer fra gsu, hvor vi også var i samme gruppe. Det fælles ansvar for projektet støttes løbende af dagbog og rapporten.

Foranalyse

Virksomheden atp

atp (Arbejdsmarkedets Tillægspension) er en selvstændig og selvejende institution, som ledes af arbejdsmarkedets parter.

atp-huset har som hovedaktivitet atp, men har gennem tiden fået overdraget en række andre opgaver, som for eksempel LG (Lønmodtagernes Garantifond), AER (Arbejdsgivernes Elevrefusion) og FerieKonto. De fleste opgaver er som atp-ordningen fastlagt ved lov. Gennem datterselskabet atp PensionService A/S sælger atp-huset persionskasseadministration på et rent forretningsmæssigt grundlag.

atp-husets hovedaktivitet er administration af store ordninger som pensionsordninger med en meget stadardiseret karakter, hvilket giver mulighed for effektiv og billig masseadministration. Derfor har atp-huset en del resurser sat af til IT-området, der er en hjørnesten i det daglige arbejde. For eksempel er al dokumentbehandling for en del år siden gjort elektronisk.

Figur 1. Overordnet organisationsdiagram for atp-huset. Datterselskaberne ATP Ejendomme A/S og ATP PensionService A/S er ikke tegnet med.

atp-huset er som udgangspunkt organiseret efter linje-stabsprincippet, hvor staben bestående af JURS (Juridisk Sekretariat), AKTU (Aktuarisk Sekretariat), ANLY (Analytisk Sekretariat) og INFO (Informationssekretariatet) tilsammen benævnes LES (ledelelsessekretariatet).

Virksomheden er organiseret i sekretariater ("staben") og områderne ("linjen") IT og SERV (Informationsteknologi og Service), ØA (Økonomisk Afdeling), FONDS (Fondsområdet), PERS (Personaleområdet), ATP (Arbejdsmarkedets Tillægspension) og LG, PensionService samt AER, FerieKonto og AES, hvis ledere sammen med direktøren er ledelelsesgruppen.

Det enkelte område består af nogle afdelinger sammensat af sektioner indeholdende nogle grupper. Grupperne er organisatorisk selvstyrende enheder.

Da en stor del af atp-husets daglige arbejde og udvikling er lagt ud som projekter, deltager alle medarbejdere i et eller flere projekter. Sammensætningen af projektgrupper går gerne på tværs af områder/afdelinger/sektioner/grupper. Nogle medarbejdere ('atpister') er direkte ansat til projektledelse.

Da dette projekts system hovedsagligt skal benyttes af IT-installationens driftsfolk, har vi valgt kun at detail-beskrive organisationen for området IT og SERV (Informationsteknologi og Service).

Figur 2. Organisation af IT- og Serviceområde med detaljering på sektionsniveau, bortset fra DRAF der er detaljeret på gruppeniveau.

Området er indelt i tre afdelinger, hvor den for os interessante er Driftafdingen. Denne afdeling består af fire sektioner, hvor vi koncentrer os om DRAF (Driftafviklingen). De øvrige sektioner DRPL (Driftplanlægningen), DRTU (Drift, teknisk udvikling) og DRTK (Driftteknik) mere er sekundære brugere af dette projekts system.

Tre af de fire grupper i DRAF er fysisk placeret i samme rum, og har i hverdagen et tæt samarbejde. Blandt andet fordi IT-installationen er temmelig kompleks. Den fjerde gruppe (Print) er placeret et helt andet sted i bygningen, men har daglig kontakt til resten af sektionen. Hele sektionen samles på bedste atp-vis en gang om ugen til sektionsmøde, hvor en dagsorden sørger for en kontinuitet og der også er plads til mere ustrukturede indlæg.

De to grupper Installationsgruppen og BrugerService er de direkte brugere af dette projekts system. For det meste er det Installationsgruppen der arbejder med opsætning og konfiguration af arbejdspladser, mens BrugerService foruden almindeligt supportarbejde deltager i konfiguration af enkeltkomponenter samt fejlfinding og detailopsætninger.

MVS- og Print-gruppen er mest orienteret mod atp-husets mainframesystem, og er derfor ikke så ofte involveret i PC-miljøets drift eller enheder.

Virksomhedsanalyse

Dette projekts resultat skal primært bruges af de to gruppen Installationsgruppen og BrugerService, hver med cirka fire fuldtidsresurser tilknyttet.

Installationsgruppen tager sig af løbende opgraderinger af IT-grej, småreparationer og udskiftninger samt nyinstallationer af maskiner og software.

BrugerService er atp-husets support funktion primært for atp-husets egne ansatte, men andre brugere af atps systemer, som for eksempel IP (Industriens Pension) i København, kontakter BrugerService som det første i tilfælde af problemer eller fejl.

Ud over den daglige brug af inventory-systemet til at holde styr på atp-husets hardware, skal systemet bruges til administrative opgaver som forsikringsoversigter, styring af serviceaftaler og overvågning af garantier. Disse fuktioner vil oftest blive brugt af ledere som for eksempel lederen af DRAF.

Nuværende arbejdsgang

Hardware bliver registreret manuelt i hardwaresystemet (se opså appendix B) enten ved modtagelse eller ved opsætning. Registreringen er efter alles mening mangelfuld og besværlig. Blandt andet fordi flere felter ikke er opdateret i deres beskrivelse.

Dette gør også at oversigt over serviceaftaler og forsikringsaftale lægges uden for systemet i dokumenter, som enten opdateres eller oprettes på ny.

Figur 3. Skematisk fremstilling af nuværende og kommende systemer i projektet.

Figur 3 viser de nuværende systemer som er Tivioli IT Director 2.11, der er koblet op med Microsoft SQL Server 6.5, Sagsbehandlersystemer og Hardwaresystemet, der er implementeret i IBM DB/2 samt andre systemer, der oftest er regneark i Microsoft Excel97. Disse andre systemer er oversigter over IP-adresser, terminalnumre, distancearbejdspladser etcetera. De andre systemer er både permanente som midlertidige. Inventory-systemet skal ikke kunne kommunikere med de andre systemer.

"Dataflow"

Figur 4. Diagrammet viser nogle af de ting der kan ske med en enhed.

Når en enhed ankommer til atp huset indtastes diverse oplysninger i systemet, blandt andet serienummer, kategori og produktionsdato. Produktionsdato fordi det i nogle serviceaftaler er fra den dato en service træder i kraft.

Enheden er nu registreret og den skal enten på lager eller ud til en bruger, her skal henholdsvis plads på lager og brugers kontor nummer indtastes.

Enheden kan som illustreret ligeledes gå i stykker, så skal der i systemet læses oplysninger om eventuel serviceaftale, faktura, garanti og eventuel historik over tidligere reparationer for at vurdere om det overhoved kan svarer sig.

Sendes enheden nu til reparation skal dato for dette indtastes, sammen med eventuel beskrivelse om reparationen.

Efter nogle dage vil systemet automatisk komme med en meddelelse (for eksempel i form af en pop-up besked) om at nu har enheden været væk i så og så mange dage. Der kan så tages stilling til om reparatøren skal rykkes eller ej.

Når enheden så vender tilbage skal slutdato, beløb og eventuel beskrivelse indtastes.

Brugertyper

Både det nuværende hardwaresystem og det kommende inventory-system har to generelle brugertyper: De tekniske brugere i Installationsgruppen og BrugerService, og de læser-brugere som for eksempel projektledere og -ansvarlige i Driftafdelingen.

De fleste data genereres og indtastes af de tekniske brugere, mens de data, der generes af administrative brugere oftest indtastes af de tekniske brugere i hardwaresystemet eller seperate dokumenter. De tekniske brugere står for oprettelse af baggrundsdata samt indtastning af detaildata, hvorfor vi skelner mellem disse opgavetyper.

Analyse

Opgave

Formål

Systemet skal koncentreres om registrering af hardware og dens placering i virksomheden.

Der findes et system, men det er for besværligt i brug, og opfylder ikke behovet for rapportering og nye typer hardware.

Systemdefinition

Som baggrund for systemdefinitionen er der udarbejdet et BATOFF-kriterie:

Betingelser Systemet bygger på og skal fungere sammen med eksisterende systemer som Hardwaresystemet, Sagsbehandlertabellen og IT-director.

Anvendelsesområde Skal bruges af atp-husets drifsafviklingssektion (DRAF), hvor primært installationsgruppen står for vedligeholdelse af databasens indhold.

Teknologi Systemet henter data fra et eksisterende system: atp-husets sagsbehandlersystem der ligger på IBM DB/2. Det nye system bygges i Microsoft Access97, hvor selve databasedelen sandsynligvis senere lægges over i IBM DB/2-2 i en klient/server løsning.

Objektsystem Et system der holder styr på atp-husets hardware.

Funktionalitet Systemet skal kunne præsenterer oplysninger om enkelte enheder og deres sammenhæng på en overskuelig måde. Desuden skal systemet kunne udskrive oversigter til administrativt brug.

Filosofi Et effektivt og pålideligt system til dagligt overblik over atp-husets hardware.

Omgivelser

Problemområde

Inventorybasen skal meget overordnet bruges til at registrere al form for hardware, som ejes af atp-huset. Systemet skal administrere de forskellige enheders indbyrdes forhold, deres fysiske placering, samt hvem der bruger hvilke enheder. Desuden skal systemet knytte serviceaftale, garanti og reparationsoplysninger til den enkelte enhed.

Når en enhed modtages, skal den oprettes i systemet, der skal registreres hvilken type hardware vi har med at gøre, hvilken model, hvem der har produceret enheden, og hvilket serienummer enheden har. Hvis enheden har tilknyttet ekstra oplysninger der kan være relevante, såsom MAC-adresse, firmware version, og lignende oplysninger, skal disse naturligvis også registreres. Hertil kommer leverandør, hvem der er kontaktperson, garantiperiode, eventuelle serviceaftaler, samt hvor i huset enheden befinder sig og hvem enheden er tilknyttet.

Eksempel: En enhed kan være et netkort (kategori). Netkortet er af modellen EtherLink og typen XL, og det er 3COM der har produceret kortet. Processoren er en 3C509b hvilket i dette tilfælde betragtes som en batchoplysning. Desuden indeholder kortet MACadressen 00-A0-24-BD-C9-B3, og har serienummeret: 73D48H82F7F3.

note: Oplysninger om at det er et Ethernetkort kontra et TokenRingkort fremgår ikke direkte, kun et det er et LAN-kort

Leverandøren er Merkantil Data, og der er knyttet 1 års garanti til kortet. Kortet tages i brug 31. marts 2000. Det er Michala Møller der står som er bruger af kortet, og hun befinder sig i kontornummer A38.

Hvis en enhed under brug bliver defekt skal der også registreres en masse data, så man har styr på hvor henne en given enhed befinder sig. Der skal registreres hvad der er galt med enheden, hvor den bliver sendt hen, og hvornår den blev sendt afsted.

Eksempel: Michala Møller er desværre kommet til at brænde sit netkort af. Der registreres at kortet er brændt af efter nærkontakt med Michalas hårspænde. Dette er heldigvis sket inden det første år, så kortet bliver sendt retur til 3COM den 1. april 2000.

For at Michala ikke skal undvære Internetopkobling og servertilgang i venteperioden, bliver hun tildelt et nyt kort. Dette registreres naturligvis.

Efter 14 dage slår man enheden op, og finder ud af at man skal rykke 3COM for kortet. Kortet modtages og bliver sat på lager til senere brug og garantien opdateres.

Når der er ændringer om en enhed skal der medfølge en kaskadevis opdatering af basen, så alle oplysninger der er tilknyttet enheden bliver slettet.

Eksempel: Efter to år kasseres Michalas gamle arbejdsstation, og hun får en ny. Ved sletning af den gamle arbejdsstation skal netkortet, som er en del af arbejdsstationen også slettes, samt alle de data der er afhængige af netkortets eksistens, for eksempel reparationsoplysninger.

Kort om de enkelte enheders forhold til hinanden

En enhed kan eksempelvis være en computer, men en computer består i virkeligheden flere dele, som også betragtes som enheder. Det betyder også at system selv skal kunne finde ud af, at når en bruger skifter en computer ud, med en anden, så skal brugerens navn ikke længere sættes i forbindelse med den gamle MACadresse, eller serienummeret på det RAM, som den gamle computer indeholdte.

Systemet skal også have en smule sikkerhed indbygget, så en skærm eksempelvis ikke kan indeholde RAM, og en mus ikke får tildelt en MACadresse.

Eksempel: En computer kan bestå af harddisk, netkort, RAM, grafikkort og så videre. Alle disse enheder skal betragtes som enkelte enheder, men de skal samtidig være en del af en større enhed. Man skal i virkeligheden, udfra eksempelvis en MACadresse, skal kunne finde frem til en bestemt bruger, samt alle relevante oplysninger om vedkommendes udleverede hardware. Det betyder også at system selv skal kunne finde ud af, at når en bruger skifter en computer ud, med en anden, så skal brugerens navn ikke længere sættes i forbindelse med den gamle MACadresse, eller serienummeret på det RAM, som den gamle computer indeholdte.

Vi har ikke indbygget sikkerhed for at en skærm, eksempelvis, ikke kan indeholde RAM, og en mus, ikke får tildelt en MAC-adresse. Ligesom der ikke er sikkerhed for flere enslydene MAC-adresser. Dette er undgået, da det kræver stort administrativt arbejde i hverdagen.

Anvendelsesområde

Når en enhed ankommer til atp-huset skal den registres. Hvis enheden indeholder andre enheder (for eksempel består en PC af motherboard, RAM, CPU, Harddisk etcetera.), skal disse også registreres, alle garantiforhold, leverandørforhold, serviceaftaler skal også registreres, dog skal detaljeringsgraden være skalérbar, da en registrering hurtigt kan blive alt for omfattende, og derfor ødelægge grundlaget for Inventorysystemet.

Efter endt registrering af enheden kan den enten komme på lager eller blive taget i brug med det samme. I begge tilfælde skal der registreres en bruger af enheden samt en lokation.

Hvis en enhed bliver fejlmeldt skal der oprettes en note på enheden, der beskriver fejlen. Det skal registreres hvor enheden bliver sendt hen, og hvornår den blev sendt afsted. Der skal altid følge en reparationshistorik til de enkelte enheder.

Det skal naturligvis være muligt at skifte værdier for de enkelte enheder, hvis en computer eksempelvis skifter ejerforhold.

Problemområde

Vi startede med diskussion af en samling af kandidater til klasser:

Sagsbehandler	Værdi
Forsikringsoversigt	Reperation
Serviceaftale	Faktura
Systemenhed	Leverandør
Komponenter	Konsulent (Leverandør, serviceaftale)
Lokale	Kopimaskine
Funktion (Hvad bruges enheden til)	Host ⁽²⁾ systemet (Grænseflade mellem host og LAN)
Distancearbejdsplads	Firmware
Netværk	Domæne
Garanti	Nedskrivning

Tabel 2. Kandidater til klasser.

En registreret bruger af atp-husets systemer er en sagsbehandler, og oplysninger om disse henter Inventory-systemet i sagsbehandlersystemet (appendix B).

En forsikringsoversigt er en aflæsning, og hører derfor ikke hjemme i problemområdet.

Klassen enhed omfatter blandt andet systemenhed, komponenter, distancearbejdsplads, kopimaskine(-printer) og oplysninger om firmware.

Enhedens placering kan indeholde henvisning til et lokale. Hvis en enhed ikke har et kontornummer, kan det være en distancearbejdsplads. Denne oplysning betragtes også som enhedens placering

Da vi ikke registrerer oplysninger om installeret software, er det heller ikke relevant at registrere enhedens funktion.

Vi har i modellen oprettet klassen netværk, som også beskriver enhedens tilhørsforhold til domæne

Den enkelte enheds værdi er mest interessant i forsikrings- og servicesammenhæng, hvorfor værdi lægges i modellen som en attribut.

Det er meget skiftende hvem der kontaktes som konsulent, så da vedligeholdesesarbejdet bliver for stort, har vi udeladt registrering af konsulent i modellen.

Da systemet hovedsageligt skal behandle enheder i PC-miljøet, har vi ikke oprettet speciel registrering af enheder i mainframemiljøet (hostsystemet). De printere, der er SNA-koblet, kan blive registreret tilfredsstillende i klassen netværk, der også registrere oplysninger om domæne-tildeling.

Systemet er ikke et økonomisystem, så oplysninger om for eksempel nedskrivning er ikke indeholdt.

Efter nogle overvejelser over kandidaterne til klasser, ser modellens struktur ud som vist i figur 5.

Klynger

Da modellen indeholder et overskueligt antal klasser samt udtrykker en begrænset problematik, har vi ikke fundet grund til at opdele strukturen i klynger [Mathiassen et al].

Struktur

Figur 5. Klassediagram for Inventory-systemet.

Det endelige klassediagram er resultatet af mange overvejelser spredt ud over hele forløbet, men for overskuelighedens skyld bringer vi det allerede nu - hvilket også er i overensstemmelse med metoden [Mathiassen et al].

Klasser

Den netop nævnte struktur er resultat af mange og lange overvejelser.

I det følgende er en beskrivelse af modellens klasser (klasserne er opstillet alfabetisk).

Klassen 'Bruger'

Ansvar og formål

Registring af ansatte i atp-huset, der har fået tildelt hardware-enhed. Klassen er associeret til Enhed, hvor én (1) bruger er associeret til nul-til-mange (0..*) enheder.

Attributter

'Initialer', 'Navn', 'Lokale', Lokaltelefonnr', 'Adresse' og 'Hjemmetelefonnr' hentes i det eksisterende sagsbehandlersystem

Operationer

Vedligeholdelse af objekterne varetages af atp-husets personaleadministration ved sagsbehandlersystemet som Invetory-systemet læser fra. Derfor bliver der ikke implementeret operationer for denne klasse i Inventory-systemet.

Adfærdsmønster

Varetages af sagsbehandlersystemet

Klassen 'Enhed'

Ansvar og formål

Registrering af forskellige hardware-enheder. Alle komponenter er en 'enhed'. En enhed kan indeholde flere enheder, og alle enheder kan identificeres i Inventory-systemet. For eksempel kan en printer indeholde to netkort og to RAM-kredse, hvor alle fem enheder kan identificeres i Inventory-systemet. Desværre er det ikke muligt at overholde UML og beskrive dette grafisk.

Klassen er associeret til Bruger, Leverandør, Placering, Reparation og Serviceaftale. Associeringer er nærmere beskrevet i de nævnte klasser.

Enhed er superklasse i en aggregeringsstruktur af Faktura, Garanti og Netværk, så Enhed dekomponeres i subklasserne. Aggregeringerne er beskrevet nærmere i subklasserne.

Desuden er Enhed subklasse i en aggregeringsstruktur op mod Kategori og Type. Ét (1) Kategori- og ét (1) Typeobjekt af kan hver indeholde et-til-mange (1..*) Enhedobjekter. Det vil sige at hvis der ikke er Enhedobjekter, er der heller ikke Kategori- og Typeobjekter.

Attributter

'Serienummer' er enhedens fulde serienummer. Der er ingen garanti for at et serienummer er unikt, men hvis det fulde serienummer lagres vil det være nærmere entydigt.

'Produktionsdato' er den dato enheden tages i brug. For servere er det den dag de frigives i produktionsmiljøet, mens det for arbejdsstationer eller printere kan være den dag enheden modtages eller dens installation påbegyndes. Som regel første ibrugtagning.

'Værdi' er et beløb, der vedligeholdes manuelt efter moden overvejelse. Det er ikke tanken at beløbet automatisk skal udveksles med andre systemer.

Operationer

'Opret enhed' indbefatter ikke nødvendigvis alle tilknytninger, der kan kommer til ved 'Ændre enhed', som også omfatter reperationer.

'Slet enhed' vil medføre at en række objekter i andre klasser også skal slettes, for de vil ikke være anvendelige uden tilknytning til en klasse. Dette gælder Type, Reperation og Serviceaftale med tilknyttede klasser samt klasserne Netværk, Faktura og Garanti. Så hvis et objekt af klassen Enhed er det sidste med tilknytning til et objekt af disse klasser, skal de tilknyttede objekter findes og slettes.

Adfærdsmønster

Figur 6. Tilstandsdiagram for klassen Enhed.

Tilstanden Reparation med tilhørende hændelser er fælles med klassen Reparation, hvor hændelserne fremgår tydeligere og med attributter.

Hændelserne Enhed tilføjes og Enhed fjernes har ikke tilknyttet tilstande, da det ikke ønskes at registre selve hændelsen

Klassen 'Faktura'

Ansvar og formål

Registrering af relevant faktura til brug ved garantireparationer.

Faktura er subklasse i en aggregering op mod Enhed, hvor der er nul-til-en (0..1) Fakturaobjekt til en Enhedobjekt og en-til-mange (1..*) Enhedobjekter til et Fakturaobjekt. Det vil sige at der kan være Enhedobjekter uden Fakturaobjekt, men ikke omvendt.

Attributter

'Fakturanummer' og 'Fakturadato'

Operationer

'Opret faktura'. 'Redigér faktura' vil der sjældent være behov for og 'Slet faktura' vil oftest være afledt af en sletning af et objekt i klassen Enhed eller klassen Garanti. Vi tager ikke hensyn til gældende lovgivning for regnskab om sletning af fakturaer, da Inventory-systemet ikke er et økonomisystem.

Adfærdsmønster

Figur 7. Tilstandsdiagram for klassen Faktura.

Iterationen 'Faktura redigeres' medfører ingen tilstand eller klasse, da der ikke er ønske om at registrere selv hændelsen.

Klassen 'Garanti'

Ansvar og formål

Registrering af garantiperiode for den enkelte enhed.

Garanti er subklasse i en aggregering op mod Enhed, hvor ét (1) Garantiobjekt er tilknyttet et-til-mange (1..*) Enhedobjekter, da den samme garantiperiode kan gælde for flere forskellige enheder.

Attributter

'Periode' med en entydig enhed. Dette overdrages til brugergrænsefladen.

Operationer

'Opret garanti, 'Redigér garanti' og 'Slet garanti'.

Adfærdsmønster

Figur 8. Tilstandsdiagram for klassen Garanti.

Hændelsen 'Garanti redigeres' er en iteration, som ikke giver grund til at oprette selvstændig tilstand endsige klasse, da der ikke er grund til at registrere selve hændelsen.

Klassen 'Kategori'

Ansvar og formål

Kategorisering af enheder, for eksempel server, mus, firmware eller printer. Klassen er sat på Enhed, da fysisk ens enheder kan have forskellige opgaver. For eksempel kan to ens computere have opgaven (kategorien) "Server" og "Arbejdsstation".

Kategori er superklasse i en aggregering fra Enhed. Strukturen er nærmere beskrevet i Enhedbeskrivelsen

Attributter

'Kategoribeskrivelse' med værdien "Server", "Mus", "Firmware", "Printer" og så videre.

Oprettes efter for-godt-befindende af de tekniske brugere, da der ikke er entydige værdier fra producenternes side.

Operationer

'Opret kategori', 'Redigér kategori' og 'Slet kategori' der oftest vil hænge sammen med en sletning af en model.

Adfærdsmønster

Figur 9. Tilstandsdiagram for klassen Kategori.

Iterationen 'Kategori redigeres' medfører ikke oprettelse af tilstand eller klasse.

Klassen 'Kontakt'

Ansvar og formål

At gemme samtlige kontaktmuligheder som leverandører og kontaktpersoner/konsulenter kan have.

Kontakt er subklasse i en aggregeringsstruktur op mod Kontaktperson og Leverandør. Objekter af både Kontaktperson og Leverandør kan have nul-til-mange (0..*) Kontaktobjekter tilknyttet, mens et Kontaktobjekt kun kan være tilknyttet ét (1) superobjekt.

Attributter

'Kontaktform' indeholder en beskrivelse af den enkelte kontaktform, for eksempel "telefon", "mail" eller "fax".

'Kontaktværdi' gemmer kontaktformens værdi for den overordnede klasse, for eksempel "bill.gates@sun.com" eller "48204995".

Operationer

'Opret kontakt', 'Redigér kontakt' og 'Slet kontakt' vil oftest hænge sammen med en sletning i klassen Virksomhed, direkte som indirekte.

Adfærdsmønster

Figur 10. Tilstandsdiagram for klassen Kontakt.

Den iterative hændelse 'Kontakt redigeres' betyder ikke at der oprettes tilstand eller klasse i systemet.

Klassen 'Kontaktperson'

Ansvar og formål

Registrere den daglige kontaktperson for en leverandør.

Kontaktperson er som tidligere beskrevet superklasse i en aggregeringsstruktur til Kontakt. Endvidere er klassen associeret til Leverandør, så en (1) leverandør kan have en kontaktperson, det vil sige er associeret nul-til-en (0..1) til Kontaktperson. Det er altså ikke muligt at den samme leverandør har flere kontaktpersoner. Dette er efter ønske fra atp-husets projektledelse.

Attributter

'Navn'.

Operationer

'Opret kontaktperson', 'Redigér kontaktperson' og 'Slet kontaktperson'. Hvis et objekt af klassen Virksomhed slettes, skal de tilknyttede objekter i denne klasse også slettes.

Adfærdsmønster

Figur 11. Tilstandsdiagram for klassen Kontaktperson.

Hændelsen 'Kontaktperson redigeres' er iterativ, men det giver ikke en separat tilstand eller klasse.

Klassen 'Leverandør'

Ansvar og formål

Registrering af atp-husets leverandører af produkter eller serviceydelser til den decentrale platform.

Ud over at være aggregeret til Kontakt og associeret til Kontaktperson som tidligere beskrevet, er Leverandør associeret til Enhed, Reparation og Serviceaftale. Alle tre associeringer har mangfoldigheder så ét (1) Leverandørobjekt er associeret nul-til-mange (0..*) til de tre andre klasser.

Attributter

'Virksomhed', 'Adresse', 'Postdistrikt'

Operationer

'Opret leverandør' og 'Redigér leverandør'. 'Slet leverandør' vil oftest være en følge af en sletning af et objekt af klassen Enhed, Reparation eller Serviceaftale, samt medføre en sletning af tilknyttede objekt(-er) af klassen Kontaktform.

Adfærdsmønster

Figur 12. Tilstandsdiagram for klassen Leverandør.

Selv om hændelsen 'Leverandør redigeres' er iterativ, oprettes der ikke en tilstand eller klasse i systemet til at registrere hændelsen.

Klassen 'Model'

Ansvar og formål

At registrere samtlige modeller for atp-husets hardware og deres beskrivelse.

Klassen er aggregeret superklasse til Type og subklasse til Producent. Aggregeringen til Type er så ét (1) Modelobjekt er tilknyttet en-til-mange (1..*) Typeobjekter, mens aggregeringen til Producent er at ét Producentobjekt er tilknyttet en-til-mange (1..*) Modelobjekter.

Kæden Enhed-Type-Model-Producent er lavet for at automatisere valg, så valget af for eksempel Typeobjekt giver automatisk Modelobjekt og Producentobjekt. Dette håber vi kan lette det daglige arbejde. Eneste ulempe er at der kan optræde ens objekter i forskellige kæder, hvilket giver dubletter. Vi skønner at det vil være så sjældent, at fordele til fulde opvejer ulemper.

Attributter

'Modelbeskrivelse' indeholder som regel en for producenten entydig værdi, for eksempel 8215-032.

Operationer

'Opret model' til at oprette nye modeller i Inventory-systemet, første gang de optræder i atp-huset.

'Redigér model' vil der sjældent være behov for og 'Slet model' vil ofte være affødt af en sletning af et objekt fra klassen Enhed.

Adfærdsmønster

Figur 13. Tilstandsdiagram for klassen Model.

Der oprettes ikke tilstand eller klasse til registrering af den iterative hændelse 'Model redigeres'.

Klassen 'Netværk'

Ansvar og formål

Registrering af netværkskomponenter. Der kan være flere netkort i printer; LAN (oftest TCP/IP over TokenRing) og SNA.

Netværk er subklasse i en aggregering op mod Enhed, hvor Inventory-systemet kun arbejder med ét (0..1) Netværkobjekt for hvert (1..*) Enhedobjekt. Dette hænger sammen med atp-husets single-domain design af det decentrale miljø, og er efter aftale med atp-husets projektledelse.

Attributter

'Fysisk adresse' som oftest MAC-adresse, som opdateres manuelt i Inventory-systemet.

'Stiknummer' er nummeret på vægudtaget for det anvendte lobe samt udtag i patchpanel i krydsfelt, 'Logisk adresse' for eksempel fast IP-adresse, 'Domæne' er det aktuelle domænenavn, 'Subnet' er IP-værdien for subnet, 'Primær navneserver' og 'Sekundær navneserver' er selvforklarende attributter, 'Gateway' er oftest en firewall mod ekstern forbindelse som internettet, 'Forwarding' er et spørgsmål om etableret eller ej og 'Dynamisk adresse' er ligeledes ja eller nej, hvor funktionen i et IP-netværk varetages af en defineret DHCP-server.

Operationer

'Opret netværk', 'Redigér netværk' og 'Slet netværk'.

Adfærdsmønster

Figur 14. Tilstandsdiagram for klassen Netværk.

Selv om der er mange attributter, oprettes der ikke hverken tilstand eller klasse for den iterative hændelse 'Netværk redigeres'.

Klassen 'Placering'

Ansvar og formål

Registrere enhedens placering

Attributter

'Lokalitet': Enheden kan være på et kontor med et nummer fra sagsbehandlersystemet (appendix B), 'hjemme' eller i rack med nummer i maskinstuen.

Operationer

Default er placeringen et lokale i atp-huset ved 'Opret placering'. Lokalenummeret verificeres i sagsbehandlersystemet ud fra brugereren, ellers indsættes data direkte i objektet.

'Ændre placering' og 'Slet placering' påvirker ikke sagsbehandlersystemet.

Adfærdsmønster

Figur 15. Tilstandsdiagram for klassen Placering.

Der oprettes ikke tilstand eller klasse til den iterative hændelse 'Placering redigeres'.

Klassen 'Producent'

Ansvar og formål

Lagre informationer om producenter af enheder i det decentrale miljø.

Attributter

'Producentbeskrivelse' er som regel navnet på producentens virksomhed, for eksempel (og ofte, da atp-huset er meget "blåt") "IBM".

Operationer

'Opret producent'. 'Redigér producent' vil sjældent blive benyttet på grund af atp-husets entydighed i indkøbte enheder og 'Slet producent', der oftest vil være en følge af en sletning af et Modelobjekt.

Adfærdsmønster

Figur 16. Tilstandsdiagram for klassen Producent.

På trods af at hændelsen 'Producent redigeres' er iterativ, oprettes der hverken tilstand eller klasse til registrering af hændelsen.

Klassen 'Reparation'

Ansvar og formål

Holder øje med enheder, der er til reparation samt den enkelte enheds historik for reparationer.

Attributter

'Startdato' og 'Slutdato' er faste værdier, der som regel ikke vil være behov for at ændre efter indlæsning.

'Anslået slutdato' er hvad teknikeren anslår eller leverandøren angiver, og kan derfor ændres flere gange inden enheden kommer retur fra reparation. Ændringen bliver ikke registreret i systemet historisk, da det ikke er nødvendigt for systemets anvendelighed.

'Beløb' er de samlede omkostninger for den enkelte reparation. De enkelte poster er ikke specificeret. Beløbet skal blandt andet bruges til at holde rede på de samlede reparationsudgifter for en enhed hele enhedens tid i Inventory-systemet.

'Beskrivelse' indeholder en fritekstbeskrivelse af reparationen. Beskrivelsen er individuel for objektet.

Operationer

'Opret reparation', Ændre reparation' og 'Slet reparation'. Som forsøgt angivet i tilstandsdiagrammet bliver reparationen slettet sammen med den tilknyttede enhed, da der er historik på en enheds reparationen.

Adfærdsmønster

Figur 17. Tilstandsdiagram for klassen Reperation.

Klassen 'Serviceaftale'

Ansvar og formål

Registre indgåede serviceaftaler for enheder.

Attributter

'Aftalenummer', 'Aftaletype', 'Startdato', 'Slutdato'

Operationer

'Opret serviceaftale', 'Redigér serviceaftale' og 'Slet serviceaftale' kan affødes af en sletning af et objekt i klassen Enhed og medføre en sletning af et objekt i klassen Virksomhed og tilknyttede klasser.

Adfærdsmønster

Figur 18. Tilstandsdiagram for klassen Serviceaftale.

Der oprettes ikke tilstand eller klasse til den iterative hændelse 'Serviceaftale redigeres'.

Klassen 'Type'

Ansvar og formål

Registrering af typebetegnelser for enheder i Inventory-systemet.

Attributter

'Typebeskrivelse' er som regel hvad producenten opgiver.

'Versionsnr' indeholder typens versionsnummer, i praksis mest firmwareversion.

'Batchnummer' indeholder nødvendig angivelse af gældende batch af typen. I de fleste tilfælde vil den samme type have mindre men til tider betydelige forskelle i priduktionsserierne, hvilket har betydning ved automatiseret installation og opfølgende indkøb. Derfor denne attribut til oplysning om produktionsserie eller batch. IBM har taget konsekvensen og indført begrebet FRU-nummer, der er entydigt for en batch.

Operationer

'Tilføj type', Redigér type' og 'Slet type' der hovedsagligt vil være affødt af en sletning af et objekt af klassen Enhed.

Adfærdsmønster

Figur 19. Tilstandsdiagram for klassen Type.

På trods af at hændelsen 'Type redigeres' er iterativ, oprettes der ikke tilstand eller klasse i systemet til registrering af hændelsen.

Hændelser

Der er nogle fælles hændelser som for eksempel 'Enhed til reparation'. Hvorledes disse hændelser behandles og om det har betydning for modellen er beskrevet i beskrivelsen af den enkelte klasse.

En mere omfattende beskrivelse at systemets hændelser findes i beskrivelserne af klassernes adfærdsmønstre.

Anvendelsesområde

Brug

Oversigt

Aktør Brugsmønster	Tekniker	Læser
Læse / udskrive enhed	X	X
Læse / udskrive defineret rapport / oversigt	X	X
Oprette enhed	X
Tilføje data	X
Slette data	X
Slette enhed	X
Oprette kæde	X
Ændre kæde	X
Slette kæde	X

Tabel 3. Aktørtabel for systemet

Aktører

Vi har delt systemets aktører ind i to brugertyper som beskrevet tidligere i virksomhedsanalysen. Driftlaget tager sig af indlæsning og sletning af data i systemet, mens Læser tænkes at primært være ansatte med administrative opgaver internt i atp-huset.

Tekniker

Formål: En person der står for registrering, installation, udskiftning, og bytning af hardware.

Karakteristik: Arbejdet udføres af personer der har høj ekspertise indenfor brug af IT-udstyr

Eksempel: En lokal medarbejder, med Hardware som ansvarsområde. Bruger Windowsbaseret systemer dagligt. Rutineret. Man skal være opmærksom på at det let kan være 50-100 pc'ere der skal registreres på en gang, så brugen af systemet skal være meget nemt og ligetil, med så få påtvungne klik eller indtastninger som overhovedet muligt. Vant til at benytte sig af Notes.

Brugergrænseflade: Fanebladssystem giver en hurtig og overskuelig tilgang til data. Ved oprettelse af mange ens enheder, skal der være mulighed for at beholde de felters værdi, der forbliver uændret, så eksempelvis kun serienummer skal indtastes. Mulighed for at springe felter over, der så bliver automatisk udfyldt (Eksempel: Udfyld FRU-værdi, og resten af enheden er kendt af systemet, og kan derfor udfyldes automatisk). Det skal være nemt at overskue mange enheder på en gang.

Læser

Formål: Person der har interesse i at vide hvor noget bestemt hardware befinder sig, og hvilke brugere der eventuelt er tilknyttet til dette.

Karakteristik: Arbejdet udføres af personer der er rutinerede i brug af Windowsbaserede systemer.

Eksempel: En lokalansat regnskabsmedarbejder der skal have oplysninger om hvor mange nyere pc-platforme der befinder sig i atp-huset på det pågældende tidspunkt.

Brugergrænseflade: Hurtige og lette foruddefineret forespørgsler skal være mulige. Nemt at overskue (fanebladssystem). Det skal være nemt at overskue mange enheder på en gang.

Der skal helst være en smule sikkerhed indbygget i systemet. Sikkerheden skal være på verifikation af de enkelte enheders indbyrdes forhold til hinanden, så man undgår at eksempelvis en skærm kommer til at indeholder RAM, og en mus ikke får tilknyttet en MAC-adresse.

Brugsmønstre

Som en følge af overvejelserne over eksisterende arbejdsgange og dataflow samt aktører kan brugsmønstrene beskrives som følgende.

Læse / Udskrive enhed.

Mønster: Da inventory systemmet primært skal bruges til registrering af enheder i forsikrings øjemed er det vigtigt at ATP kan trække enheds lister så en forsikrings status kan fastslås. Desuden skal disse lister også kunne ses fra skærmen. Dette skal kunne klares ved at trykke på en knap som så kører den nødvendige forespørgelse.

Læse / Udskrive defineret rapport / oversigt.

Mønster: Hvis nødvendigt skal aktøren kunne trække en liste på enheder der måtte være til reparation, og ligeledes kunne se hvornår disse kan forventes i huset. Dette skal også kunne klares ved et tryk på en knap.

Oprette enhed.

Mønster: Ved modtagelse af en eller flere maskiner skal Teknikker gruppen oprette alle maskinerne i databasen. Dette skal kunne ske fra et vindue som kan kopiere standard informationer fra formular side til formular side, så kan man rette de få informationer, som der er forskellige, i en serie (evt. serie nummer). Dette vil spare aktøren for en masse taste arbejde. Aktøren skal starte med at vælge producenten efterfulgt af model og type. Derefter skal der intastes fru værdig og serienr.

Tilføje data.

Mønster: Skulle en enhed skifte sagsbehandler eller plads, skal aktøren kunne rette disse informationer. Dette foregår ved at vælge en anden person i sagsbehandler boksen i den dertil indrettede fane.

Slette data.

Mønster: Når en enhed for tilkoblet en ny mus så skal der selvfølgelig kunne slettes den gamle. Dette gælder også ved ny sagsbehandler og plads. Dette skal også kunne ske fra de underliggende faner.

Slette enhed.

Mønster: Af og til sker det at en enhed helt udgår, og derfor skal denne enhed kunne slettes, dette skal kunne ske ved at markere de enheder som øskes slettet og derefter trykke delete.

Oprette kæde.

Mønster: Når en enhed skal indtastes i systemet er der lavet en kæde mellem enhed, type, model og producent, for at gøre arbejdet mere automatisk for brugeren. Så hvis der f.eks. vælges en type, giver kæden automatisk model og producent.

Ændre kæde.

Mønster: Hvornår der er behov for det?

Slette kæde.

Mønster: Ligesom at en enhed kan udgår, kan en kæde ligeledes skulle slettes, dette gøres ved at denne markeres og der trykkes delete.

Funktioner

Access97 stiller indbyggede funktioner til rådighed, blandt andet via SQL og Visual Basic for Applications (VBA), som vi benytter til systemets samlede funktionalitet.

Funktionsliste

Systemet skal understøtte nogle funktioner, som er vist nedenfor.

Funktion	Type	Kompleksitet
BeregnSlutGaranti	Tidsberegning	Kompleks
Kopiér data til ny enhed	Datakopiering	Middel
Opret enhed	Opdatering	Middel
Nedlæg enhed	Opdatering	Middel
Opret leverandør	Opdatering	Middel
Nedlæg leverandør	Opdatering	Middel
Opret reparation	Opdatering	Middel
Nedlæg reparation	Opdatering	Middel

Tabel 4. Oversigt over systemets funktioner.

Specifikation af funktioner

De fleste af funktioner er selvforklarende, så derfor har vi kun lavet en selvstændig beskrivelse for enkelte funktioner.

Kopier data til ny enhed

En ny enhed oprettes og udvalgte data fra en i systemet eksisterende enhed kopieres over i den oprettede enhed.

Beregn slut garanti

Via Enhed findes sammenhæng mellem en enhed, den tilhørende fakturadato og den gældende garantiperiode, så slutdatoen for garantien kan beregnes ved
slutdato = fakturadato + garantiperiode

Brugergrænseflade

Da brugerne er rutinerede i IT-systemer, er det vigtigste en entydig brugergrænseflade.

Fagtermer kan anvendes, mens forkortelser skal overvejes i det enkelte tilfælde.

Den grafiske fremtræden vil i høj grad være bestemt af Access 97, hvor vi tilstræber entydighed og øjenvenlighed. Se også implementeringen.

Da vi har to meget forskellige aktører i systemet, er der et temmelig stort krav vedrørende udformningen af brugergrænsefladen. Installationsgruppen som sandsynligvis vil blive meget hurtigt fortrolig med vinduerne vil sikkert sætte meget stor pris på genveje (eks.: Ctrl+T = Tilføj enhed ).

Hvorimod at BrugerService nok ikke vil bruge systemet nær så tit, så her vil et krav til brugergrænsefladen være "control tip texter", som forklare brugeren hvad alt bruges til, med nemme og forklarende tekster.

Vores hensigt er også at lave grænsefladen overskuelig med et faneblads system, som indeholder informationer eller indtastningsfelter, som ikke bliver brugt så tit. Så bliver brugeren kun præsenteret for de vigtigste felter, og kan hvis det er nødvendigt, klikke sig ind på det faneblad som der er brug for. Og her vil brugen ligeledes, kun se de felter som der er nødvendige. Desuden vil vi bestræbe os på, mest muligt at få grænsefladen til at ligne Windows NT (farver og logisk opstilling), da dette styresystem arbejder de fleste med i atp-huset. Og det vil få mulige bruger, straks til at føle sig "hjemme".

Dialogform

Menuvalg med tastaturgenveje, da det er hurtigt for rutinerede brugere og bedst for den enkelte brugers arbejdsmiljø. Data vil blive grupperet blandt andet ved brug af faneblade.

Teknisk platform

Systemet skal kunne køre på atp-husets eksisterende platform, der primært er et klient/server-miljø (Microsoft Windows NT) koblet sammen med et mainframemiljø (IBM S/390). Systemet er lavet i databaseapplikationen Microsoft Access97 med anvendelse af SQL og ODBC for at få adgang til data på databasesystemet IBM DB/2-2.

Selve systemet i dette projekt installeres på client/server, men indeholder i begrænset også data om enheder i mainframemiljøet, som for eksempel SNA-netkort.

Anbefalinger

Systemets nytte og realisérbarhed

Vi mener systemet har et passende ambitionsniveau i forhold til projektets økonomi og tekniske stade. Det er desuden vores opfattelse at den endelige implementering i atp-husets klient/server miljø kan ske uden problemer.

Strategi

Det har under hele projektet været alles parters hensigt at Inventory-systemet skal udvikles og iværksættes. Dog har analysearbejdet specielt om IT Director åbnet for overvejelser om et nyt projekt i atp-huset, hvor IT Director undersøges meget dybere og eventuelt sættes i forbindelse med Inventory-systemet - sådan som det var dette projekts intentioner i begyndelsen.

Udviklingsøkonomi

vsu-gruppen arbejder uden aflønning og benytter egne installationer. atp-huset afsætter resurser internt uden om vsu-gruppen. Det er kun service og tid der udveksles mellem vsu-gruppen og atp-huset - selv om to af gruppens medlemmer er ansat i atp-huset.

Design

Opgave

Formål

Systemet skal kunne registrerer alt hardware i atp huset, og på senere tidspunkt muligvis også software, på en let og tilgængelig måde.!

Der skal indtastes hver gang der kommer nyt hardware til huset, men det skal ikke være den enkelte bruger der skal indtaste, det job ligger hos en bestemt gruppe i atp huset's installationsgruppe.

Det er vigtigt at systemet er præcist, nemt at bruge og pålideligt da det bl.a. skal kunne bruges i form af udtræk af hardware enheder til forsikrings brug.

Rettelser til analyse

Overvejelser i forbindelse med optimering af modellen har gjort modellen mere kompleks/detaljeret.

Desuden vil vi efter moden overvejelse ikke benytte IT Directors funktionalitet eller data automatisk, da IT Director dårligt opfylder atp-husets ønsker til Inventory-systemet.

Hvorfor gik vi egentlig bort fra IT Director?

Når et system skal interagere med et andet, er det meget vigtigt at kende tekniske detaljer omkring det andet system, det der ellers vil komme fejl i dataudveksling mellem de to systemer. En af de første problemer vi stødte på med Tivolis IT Director var at vi ikke havde en beskrivelse af de tabeller som blev genereret af IT Director. Den beskrivelse der hører til de enkelte felter i IT Director er beskrivelser vi selv har indtastet, dels ud fra feltnavnene og dels fra [Nusbaum et al], men vi har ingen garanti for at vores beskrivelse er korrekt. De oplysninger som IT Director indsamler om den enkelte enhed er ret detaljerede. Da der er knyttet omkring 800 PCere på det netværk IT Director overvåger, vil der i løbet af meget kort tid blive genereret en meget stor mængde information. En stor del af den information vil løbende ændre sig efterhånden som en PC får installeret mere og mere og bliver opgraderet. Derfor vil der naturligvis også hurtigt blive dannet en masse overflødig data. Denne data kan kaldes historik for en maskine. En stor del af den historik vil være uinteressant, for det er den øjblikkelige konfiguration, der er interessant. Hvis man gemmer disse informationer for godt 1.000 computere, så vil man lynhurtigt fylde disksystemet med irrelevante data. Derfor er man nødt til at have en garbage collector (En rutine der sletter irrelevant data). Desværre var der ingen der kunne oplyse os om hvordan denne garbage collector fungerede, hvad den mente var relevant, og hvad den mente der skulle slettes. Tilmed var ingen rigtig klar over hvad der skete med de informationer om en PC, der blev taget af nettet. Ingen vidste hvor lang tid data befandt sig i systemet, fordi når en maskine bliver taget af nettet og sat på lager, vil atp stadig gerne vide hvor maskinen befinder sig.

IT Director-systemet registrere en masse om den hardware der sidder i en maskine, men der kontrollere også en masse software-afhængige data. Det vil sige at hvis en mus ikke er rigtigt installeret, vil IT Director opfatte musen forkert, og derved give nogle forkerte oplysninger til vores nye Inventory-system. Vi så helst at de data vi fik ind i systemet var rene Hardwaredata, og på ingen måde manipulerede af et stykke software.

Med den manglende informationer, samt de mange mulige fejlkilder i IT Director, følte vi ikke at det var sikkert at benytte systemet. Under et kort møde med atp blev der besluttet at IT Director ikke havde de faciliteter vi søgte efter, og det blev vedtaget at lave Inventory-systemet uafhængigt af IT Director.

Kvalitetsmål

Kriterium	Prioritet	Forklaring
Brugbart	Høj	Yderst relevant, da databasens tilblivelse primært er baseret på at det eksisterende systems manglende brugbarhed
Sikkert	Trivielt opfyldt	Intet af det indtastede data er på nogen som helst måde følsom. Derfor vil dette punkt ikke være interessant.
Effektivt	Trivielt opfyldt	Al form for udnyttelse, ligger i Access. Derfor vil effektiviteten af programmet hører inde under Access-programmellet.
Korrekt	Høj	Det er yderst relevant at systemet dækker de opstillede krav, da det er grundlaget for programellet.
Pålideligt	Høj	Endnu en af de mere grundlæggende dele for programmet. Derfor må punktet vægtes som høj.
Vedligeholdbart	Middel	Både data & system kan komme ud for både rettelser, og videreudvikling, men vi regner med at de grundlæggende dele ikke behøver fejlrettelser, eller lignende.
Testbart	Middel	Systemet skal prøvekøres og testes af udviklerne (det er os), men når det er færdigudviklet, vil det ikke være nødvendigt at kunne kører test. Dog skal man være opmærksom på at kunden kan få brug for at videre-udvikle systemet, og dette vil medføre et naturligt behov for at kunne teste, før det bliver taget i brug.
Fleksibelt	Trivielt opfyldt	Der vil sandsynligvis komme tilføjelser til systemet, men direkte ændringer vil vi ikke tage hensyn til.
Forståeligt	Middel	Systemet skal udnyttes af folk som til dagligt har med drift af IT-udstyr. Derfor må man gå udfra at de fleste har så godt kendskab til brug af lignende systemer, at man ikke behøver tage væsentlig højde for forståeligheden...
Genbrugbart	Trivielt opfyldt	Systemet vil som sådan ikke blive genbrugt, men nærmere videre-udviklet.
Flytbart	Trivielt opfyldt	Systemet er udviklet i Access, og vil derfor ikke være til at flytte. Kontakten til andre Databasesystemer vil formidles igennem ODBC.
Integrérbart	Trivielt opfyldt	Dette punkt er 100% afhængigt af Access. Systemet skal arbejde sammen med andre databasesystemer igennem en ODBC-fortolker, og derfor må det være op til Databaseprogrammørene, om denne samtale kan fungere.

Tabel 5. Oversigt over kriterier for kvalitet i programmellet.

Teknisk platform

Udstyr

PC-platform; Stationær arbejdsstation, bærbar, laserprinter (kopimaskine).

Undervejs har der været hentet data på atp-husets IBM S/390 mainframe.

Basisprogrammel

Applikation ved Microsoft Access97 DK på operativsystemerne Microsoft Windows 95 OSR2 DK, 98.2 DK og NT 4.0 Server UK.

Rapport skrevet på Corel WordPerfect 9.0 DK og Microsoft Word97 med illustrationer lavet i Corel Presentations 9.0, Microsoft PowerPoint97, Micrografx ABC FlowCharter 3.0 og CorelDRAW! 7.0.

Undervejs har internt i gruppen været brugt Winzip og pkzip til pakning af filer i zip-format, samt Acrobat Reader til læsning af rapporten og dokumentation i pdf-format.

Enkelte beskrivelser af eksisterende systemer har vi gået til via en internet browser som for eksempel Microsoft Internet Explorer 4.0 / 5.0, samt Data Dictionary på OS/390.

Views i atp-husets eksisterende systemer er hentet via ODBC i IBM DB/2 på OS/390 eller Tivoli IT Director 2.11 ved Microsoft SQL Server 6.5 på Windows NT 4.0 Server.

Gruppen har kommunikeret internt og med atp blandt andet med email, og dertil benyttede forskellige mailklienter som for eksempel IBM Lotus Notes og Microsoft Outlook Express i forskellige versioner.

Systemer og apparater

Designsprog

Dette designdokument er baseret på UML med den notation der benyttes i "Objektorienteret Analyse og Design" [Mathiassen et al].

Arkitektur

Komponentarkitektur

Figur 22. Klassediagram for systemets grundarkitektur.

Forskellen på de to DBS ⁽³⁾ er i figur 22 er at det der er forbundet med modelkomponenten er DBS for selve Invetory-systemet, mens det andet er DBS for eksisterende systemer som sagsbehandlersystemet.

Databasesystemerne vil blive lagt i en klient/server konfiguration. Systemgrænsefladen og brugergrænsefladen kontrolleres hovedsaglig af atp-husets eksisterende systemer.

Procesarkitektur

Da systemet ikke er tidskritisk, har vi ikke betragtet muligheder for kodeoptimering.

Med hensyn til samtidighed mener vi DB/2.2 tager sig af afviklingen af flere forskellige samtidige processer. Det forlyder at DB/2.2 er ret god til den slags opgaver...

Selve databaseprogrammellet ligger på en flerprocessorserver (IBM NetFinity) med Windows NT installeret, og vi har i det forbindelse ikke gjort os nogle videre bekymringer omkring kollisioner eller løkker da vi forudsætter IBM og Microsoft tilsammen har leveret et så-tæt-på-færdig-som-muligt system.

Hvordan Access 97 og ODBC klienten kalder DB/2 véd vi ikke i detaljen: Hvornår bliver data låst på felt-, record- og tabelniveau, og hvad der er regler for læse/skrive-rettigheder. Igen benytter vi bare funktionaliteten i systemerne.

Standarder

Grafisk vinduesmiljø med genveje som et tidssvarende styresystem med udgangspunkt i CUA-standarden.

For overskuelighedens skyld vil vi benytte os af et faneblads-vindue, som kun vil vise de data som brugeren har brug for.

Modelkomponent

Struktur

Da der ikke er mange ønsker om historik - faktisk kun i forbindelse med reparationer - er de fleste iterationer uden egne tilstande eller klasser. Derfor er strukturen af modellen uændret i forhold til analysedokumentet.

Funktionskomponent

Funktionskomponenten er den del af systemet, der realiserer de funktioner, som ikke implementeres direkte i modelkomponenten.

Funktionskomponenten laves ved at omforme analysens funktionsliste til en samling af operationer, hvor hver operation enten er knyttet til en af de klasser, som allerede findes i modelkomponenten eller til en ny klasse i funktionskomponenten.

For eksempel funktionen beregn slut garanti, her bruges klassen enhed, fakuradato og aftalte garantiperiode, så slutdato altså bliver beregnet udfra fakturadato plus garantiperiode.

Systemgrænsefladekomponent

Brugergrænsefladen gives ved Windows NT og Access. De data der efterspørges eller indtastes i brugergrænsefladen, bliver overført fra en DB/2.2 database og ud i brugergrænsefladen. Herunder vil vi systematisk prøve at afklare systemgrænsefladerne, og konverteringer som data vil komme igennem.

Kommunikationen mellem Inventory-systemet og andre databaser sker ved ODBC, som er en fuldt integreret del af Access 97.

Figur 23. Oversigt over Inventory-systemets systemgrænseflade.

Som det ses i figur 23, er brugergrænsefladen givet ved Access via Windows NT. Når der bliver genereret SQL-kald, af brugergrænsefladen bliver disse omdannet til en syntaks DB/2 eller DB/2.2 forstår. Dette bliver gjort af den givne ODBC, som ligger på klientmaskinen. ODBC ligger som en applikation oven på OSI-modellen og vidergiver data til sessionslaget ved hjælp af Named Pipes - OSI-lag 7 springes altså over.

På lag 6 bruges Sockets til at transformere de givne informationer om til TCP, der befinder sig på lag 5 og 4.

På lag 3 befinder IP sig, herfra bliver pakken videregivet til lag 2, hvor man definere Token Ring, sidst men ikke mindst overgives pakken til lag 1, som er det fysiske netværk, altså NIC, kabler/fibre og switche.

Hvis vores SQL-kald er lavet til den allerede eksisterende sagsbehandlertabel, vil den pakke, som bevæger sig på lag 1 nu (det er altså et elektrisk signal), blive opfanget af atp-husets mainframes OSA. OSA'en vil oversætte pakken de to første lag for derefter, at videregive datastrømmen til IP. IP-protokollen ligger kapslet ind i mainframens styresystem. Hele styresystemet i mainframen er rimelig kompleks, og vil for en nemheds skyld blot blive benævnt som OS/390. IP er en del af et af OS/390 delsystemer. OS/390 videregiver vores SQL-kald til DB/2, der også ligger på S/390. Svaret vil herefter blive videregivet til OS/390, som vil gøre som ovenstående, blot i modsat rækkefølge.

Hvis kaldet havde været ned i Inventory-systemets egen database, vil det elektriske signal blive opfanget af det netkort (NIC), som sidder i databaseserveren, blive oversat til TCP/IP, som igen via Windows NT vil oversætte det til rene SQL-kald, som vil kunne kommunikere med den DB/2.2 som ligger på Windows NT-serveren.

Da al form for opdatering af Inventory-systemets database foregår på en central DB/2.2 server, vil den tage sig af samtidige opdateringer, ligesom funktionalitet hovedsagligt vil ligge i databasemanageren (RDBMS) DB/2.2.

Bare for en ordens skyld, så strejker NIC sig over OSI lag ét og to, OSA-adaptoren de nederste og mellemste OSI lag, og TokenRing enhederne er i de to nederste OSI lag.

Inventory-systemet laves tæt på en klient/server arkitektur med distribuerede data, hvor atp-huset konverterer systemet til klient/server arkitekturen med centraliserede data, hvilket projektgruppen i videst mulige omfang tager hensyn til under hele processen.

Brugergrænsefladekomponent

Det eksisterende hardwareregistreringssystem er meget uoverskueligt, der er mange gentagelser, og er meget omstændeligt i brug. Dette er grunden til at dette projekt overhovedet er blevet sat i gang. Derfor skal vi hele tiden holde os for øje, at der er så få indtastninger som overhovedet muligt, og at systemet er hurtigt, nemt og meget overskueligt i sin tilgang til data. En stor del af den lette og overskuelige brugergrænseflade er allerede nu blevet defineret for os, af Microsoft, og deres programmel. Programmet skal nemlig udvikles i Access 97, der igen er udviklet til at fungere i et Windows NT miljø. Brugerne af systemet vil være vant til at bevæge sig rundt i et Windows NT miljø, og derfor vil det være hensigtsmæssigt at benytte så mange af de faciliteter der udbydes af Windows NT, og Access som overhovedet muligt.

Vi har af samme grund besluttet os til at bruge de standard opsætninger som man kender fra Windows NT miljøet. Det vil sige at vi såvidt muligt vil overholde CUA-standarden, og at der vil være rig brug af genvejstaster. Vores opgave vil være at præsentere så meget data for brugeren som muligt, uden at det bliver uoverskueligt, og uden der vil forekomme for mange irrelevante oplysninger. Eksempelvis er det ikke interessant at se hvilke enheder en bestemt maskine indeholder, hvis man er ude på at finde ud af noget om det firma der har leveret varen. Derfor vil de relevante data blive stillet op i nogle foruddefinerede klynger. Disse klynger skal være nemt tilgængelige, og det er gruppens erfaring at et fanebladssystem i høj grad vil gøre dette muligt.

Ved indtastning af data skal der være mulighed for både at kunne klikke sig frem til de fleste oplysninger, via dropdown-bokse, men der skal også foreligge mulighed for at maskinen selv finde relevante data, på denne måde indførers der også en slags kontrol af de indtastede varer. For at gøre det helt klart, hvad der menes er herunder et eksempel:

Ved indtastning af "Arbejdsstation" under kategori, udlukkes producenter som 3COM, og Logitech, desuden vil de modeller der fremkommer ved tryk på model-dropdownboksen kun være modeller der hører til kategorien "Arbejdsstation". Det skal helst være muligt at ved indtastning af batch-værdi udfyldes samtlige andre punkter, der allerede er kendt af systemet. Det skal naturligvis være sådan så felter som serienummer ikke bliver udfyldt, da dette er en unik værdi.

Da vores system kun har to typer brugere, og deres brug af systemet er meget ens, vil deres brugergrænseflade også blive meget ens at se på. Den eneste reelle forskel på de to typer brugere, vil være at den ene type har læse/skrive-rettigheder ned i basen, hvorimod den anden type bruger kun vil have læse-rettigheder i basen.

Da vi benytter Access 97 til implementering, ligger brugergrænsefladen i formularer, som bygges op af og med den funktionalitet Access 97 stiller til rådighed.

Tastaturgenveje til faner via tal og direkte til felter i formular via bogstaver.

Figur 24. Inventory-systemets startbilled.

Da et af de største krav til Inventory-systemet har været, at det skal være nemt at bruge, har projektgruppen valgt et menu system med to hovedvinduer hvor alle funktioner kan præsenteres. I det hovedvindue åbnes bare med klassen Enhed som indgangs vinkel, mens det andet er indgang til udskrift af Oversigter (rapporter).

I disse vinduer skal der være et fanebladselement med et antal faner, som kan vise de felter som der er brug for.

Enhedsindgang

Enhedsvinduet vil være præsenteret så man kan se enheden der er aktuel, og under vil man skulle aktivere fanerne får at se de informationer, som er tilknyttet denne enhed.

Fanen Enhed vil vise de sekundære enheder som er tilsluttet netop denne primære enhed.

Leverandørfanen indeholder informationer vedrørende den leverandør som har leveret varen til os. Samtlige informationer vedrørende kontaktformer kan også gemmes her.

Producentens forskellige kontaktformer kan lagres i et (næsten) uendeligt antal.

Faktura, garanti og service-fanen er til, fordi bruger service ønsker hurtigt, at kunne se et fakturanummer hvis varen går i stykker. Desuden kan man også se varigheden af garantien, typisk et år, samt forhold omkring en eventuel serviceaftale.

Når brugerservice eventuelt skal besøge en sagsbehandler som har et problem med denne enhed, kan lokaliteten slås op.

Navnet og andre relevante informationer, om sagsbehandleren, som har enheden.

Brugeren som har denne enhed, ville kunne slås op i denne fane. Med de informationer som BrugerService og Installationsgruppen har brug for.

I reparationsfanen kan man følge historikken vedrørende de antal gange enheden har været til reparation. Dette er taget med, for at kunne se om en enhed er for dyr og eventuelt skal skiftes ud frem for at blive reparareret.

Fanen Netværk indeholder netværksoplysninger for klient og tilsvarende domæne.

Oversigtsindgang

Denne side skal hjælpe brugerne med at bevare overblikket, så man til hver en tid kan trække formaterede forespørgsler (Access: Rapport) over de enheder og brugere der findes.

Typeoversigt: Enheder kategoriseret efter type og sorteret alfabetisk.

Alderoversigt: Enhedernes alder ud fra den registrerede produktionsdato eller fakturadato. Sorteret efter faldende alder.

Brugeroversigt: Alle brugere og alle Enheder som brugeren har. Sorteret efter bruger og derefter Enheder.

Anbefalinger

Systemets nytte

Inventory-systemet opfylder de fleste af de mål vi sate os sammen med atp-huset. Dog har det ikke været muligt at få systemet til at samarbejde med IT Director. Det har specielt fra installationsgruppens side været et udtalt ønske at IT Directors automatiserede dataindsamling er grundlaget for Inventory-systemet. Dette har som tidligere beskrevetbdesværre ikke været muligt, blandt andet på grund af manglende adgang til IT Directors dokumentation.

Ellers er det vores mening at Inventory-systemet med det analyse- og designarbejde der ligger bag, er en brugbar løsning af opgaven.

Ibrugtagningsplan

Data fra Hardwaresystemet konverteres automatisk over i Inventory-systemet. atp-huset validerer data manuelt efterfølgende.

Uddannelse af brugere og praktiske forhold ved ibrugtagning er atp-husets område

Realiseringsplan

Inventory-systemet laves og data konverteres automatisk af vsu-gruppen, mens atp-huset konverterer specielt tabelstrukturen til det gældende produktionsmiljø, samt afvikler den endelige iværksættelse.

Implementering

Database

Efter samtale med atp-husets projektledelse vil eksisterende data i hardwaresystemet blive konverteret som beskrevet i appendix C.

Struktur

Figur 32. Diagram over Inventory-systemets tabelrelationer (Bachman-inspireret). Fed er tabelnavn, understreget kursiv er primærnøgle og understreget er fremmednøgle.

I det følgende beskrives sammenhængen mellem analysedokumentets klassediagram, ovenstående relationsdiagram og relationerne i Access 97.

Den centrale klasse Enhed transformeres til tabellen T-Enhed. Idéen med at enheder indeholder enheder, for eksempel indeholder en printer et netværkskort, varetages af tabellen T-Sammenhæng hvor feltet EnhedId1 er en fremmednøgle til T-Enhed for den primære enhed og feltet EnhedId2 er fremmednøgle til T-Enhed for den sekundære enhed. T-Sammenhæng er altså et udtryk for en ordnet mange-til-mange relation for T-Enhed selv. som det ses i figur 33 opretter Access97 en automatisk spejling af T-Enhed ved en sådan konstruktion.

Figur 33. Tabelrelationer som de præsenteres i Access 97.

Tabellen T-Type er en transformation af klassen Type, hvor attributterne Versionsnummer og Batchnummer er ved en normalisering af første grad er placeret i tabellerne T-Version og T-Batch.

Tabellen T-Leverandør er en transformation af klassen Leverandør, hvor attributten Postdistrikt er flyttet til felterne Postnummer og Postdistrikt i tabellen T-Postnummer på grund af en normalisering af tredje grad. Vi har taget os den frihed at lade feltet postnummer være primærnøgle, selv om den er databærende, da vi mener et postnummer er entydigt.

Klassen Kontakt er transformeret til tabellen T-Kontakt, men attributten Kontaktform er bragt på første normalform i tabellen T-Kontaktform, hvor feltet Kontaktform indeholde oplysningerne om de forskellige kontaktformer, for eksempel "Telefonnummer" eller "Mail".

Tabellerne T-Niveau og T-Betaling er dannet for at bringe tabellen T-Serviceaftale på første normalform, hvilket styres med felterne NiveauId og BetalingId som fremmednøgler. T-Serviceaftale er dannet ud fra klassen Serviceaftale, mens T-Niveau og T-Betaling er nomaliseringen af attributten Aftaletype. T-Niveau opbevarer de serviceniveauer, der er aftale med leverandørerne af service, for eksempel "3 times tilkald" eller "Reparation ved fremsendelse". Betalingsformer for serviceaftaler gemmes i T-Betaling, for eksempel "Abonnement" eller "Årsaftale".

Klassen Netværk transformeres til tabellerne T-Netværk og T-Domæne, hvor domæne er dannet for at bringe T-Netværk på tredie normalform, hvilket giver feltet DomæneId som fremmed-nøgle i T-Netværk.

De øvrige tabeller er direkte transformationer af klasser. En mere detaljeret beskrivelse af den enkelte tabel findes i appendix B.

Diskussion

Generelt

Gruppearbejde delen på vsu er egentlig ikke planlagt efter kendte modeller. Vi var samme gruppe sidste år på gsu, og da det fungere fint, valgte vi at fortsætte.

Vi har derfor på grund af erfaringerne fra sidste år, heller ikke valgt en egentlig projektleder. Vi har alle været "lige" om alt. Derfor har vi heller ikke brugt lang tid på at finde samarbejdets rytmer, da de fandtes i forvejen.

En ting vi dog har gjort anderledes er at vi i dette projekt har valgt at føre dagbog over gruppearbejdet og diverse møder.

Vi har ligeledes skrevet ned fra gang til gang, hvem der skulle lave hvad til næste gang, både for at have styr på hvad vi skulle se på til næste møde, men også for at uddele opgaverne som de dukkede op. Alle har på den måde været ansvarlige for et tæt-på-færdig indlæg. Så et egentlig har vi haft "roller", de har bare ikke været definerede i dagligdagen.

Vi har arbejdet lidt efter princippet, de rigtige opgaver til de rigtige personer, forstået på den måde at dem der har vist meget om for eksempel Access 97 har arbejdet med det.

Koordinering i projektarbejdet er sket ved hjælp af dagbogen og løbende nye versioner af rapporten. Ved hvert gruppemøde har vi set rapporten igennem, uddelt opgaver til næste gang og har diskuteret diverse problemstillinger, for eksempel har vi brugt meget lang tid på at gennemarbejde klassemodellen og E/R diagrammerne.

Der har fast været gruppemøde hver anden søndag, og tirsdag og torsdag aften efter at Danny og Torben har holdt deres indlæg. Igen har dagbogen været mødereferat, og har været brugt til opfølgning på næste møde.

Selve rapporten har været brugt som det skriftlige resultat af projektetableringen som et selvstændigt dokument.

Projektets motivation har været det at kunne se at vi er nået længere og længere, dog har eksamen været det primære mål for os: Vi skulle lave et projekt, som vi kan gå til eksamen med og kan bestå på. Så noget af belønningen har været at vi i projektet har oplevet succes og fremgang.

Generelt har gruppen fungeret rigtig godt, til tiden måske lidt for godt, forstået på den måde, at der har været brugt lang tid på at for eksempel spise morgenmad og hyggesnakke. På den anden side har det også været det der har gjort at vi har fungeret godt. Vi har haft balancerede roller, støtte og tillid, regelmæssig ærlig evaluering, god kommunikation, godt samarbejde og så har vi haft støtte i og tillid til hinanden.

Konklusion

Sammenlignet med gsu-forløbet har vi gennem hele forløbet haft mere styr på de enkelte metodens elementer og deres sammenhænge.

I vores samarbejde med atp-huset har vi oplevet stor lydhørhed og tillid, hvilket blandt andet kan ses på IT-Directors tiltænkte og egentlige rolle i Inventory-systemet. Til daglig har der ikke været den store kontakt mellem gruppen som helhed og atp-husets projektledelse, men dette kommer af at ét af gruppens medlemmer er ansat i samme sektions som projektlederen Jakob Weincke.

Vi er bleven meget klogere ⁽⁴⁾ ...

Hillerød, 18. maj 2000

Lars Finne-Larsson	Niels Grove-Rasmussen
Mikkel Munksgaard	Michala Møller

atp-husets kommentar

I januar 2000 blev vi kontaktet af Niels Grove-Rasmussen angående hans ønske om at lave et eksamensprojekt omkring en ATP-opgave. På det tidspunkt havde vi et stort System Managementprojekt kørende. Et delprojekt omkring nyt Inventorysystem havde ikke fåret den nødvendige fokus, og vi var begyndt at overveje ekstern assistance. Det var derfor oplagt at give Michala, Mikkel, Lars og Niels muligheden for at løse opgaven.

Når vi lader en gruppe studerende lave projektet er vi selvfølgelig klar over at vi må arbejde anderledes end hvis vi havde hyret eksterne konsulenter. Således har vi valgt at præsentere vores forventninger til det fremtidige inventorysystem, og derefter har vi ladet gruppen arbejde med løsningen på egen hånd.

Vi har i perioden brugt statusmøderne til at sikre at der stadig er fremdrift i projektet. Desuden har vi diskuteret de spørgsmål som gruppen har rejst.

Den eneste større afvigelse fra vores forventninger og den løsning gruppen har produceret, er omkring automatisk opdatering/vedligehold af data i systemet. Men vi må erkende at vi ikke har givet gruppen de nødvendige forudsætninger for at udnytte vores produkt til formålet ITDIRECTOR. Dette arbejde foretager ATP selv efter iværksættelsen af gruppens inventorysystem.

Vi forventer at få et meget brugervenligt system, med faciliteter der gør det nemt at registrer nye elementer i systemet. Desuden kan vi allerede nu se at vi får et veldokumenteret og dybt gennemarbejdet system.

Undertegnede vil afslutningsvis ønske gruppen held og lykke med deres eksamen, og så vil jeg glæde mig til at vi får iværksat systemet hen over sommeren.

Jakob Weincke

Litteratur

[Christiansen og Trojel] Poul Erik Christiansen og Thomas Trojel:
Organisation og logistik (1996, Trojka, ISBN 87-89830-31-8)

[Holm-Rasmussen og Christensen] Søren Holm-Rasmussen og Ole Christensen:
Introduktion til Regnskab & Virksomhedsvurdering (2. udgave, 1999, Forlaget Systime, ISBN 87-616-0041-5)

[IT-miljø] atp:
IT-miljø (1999, atp)

[Munk-Madsen] Andreas Munk-Madsen:
Strategisk Projektledelse (1996, Forlaget Marko, ISBN 87-7751-115-8)

[Mathiassen et al] Lars Mathiassen, Andreas Munk-Madsen, Peter Axel Nielsen og Jan Stage:
Objekt Orienteret Analyse og Design (2. udgave, 1998, Forlaget Marko, ISBN 87-7751-129-8)

[Groff og Weinberg] James R. Groff og Paul N. Weinberg:
LAN Times Guide to SQL (1994, McGraw-Hill, Inc., ISBN 0-07-882026-X)

[Mose] Ole Mose:
Access97 - praktisk databasedesign (1999, IDG Danmark, ISBN 87-7843-117-4)

[Personaleguide] atp:
Personaleguide 1995 (1995, atp)

[Nusbaum et al] Barry D. Nusbaum, Julius Milezarek og Gus Nader:
Tivoli - Integration Examples for Tivoli IT Director: A First Look (1998, IBM Corp, ISBN 0-7384-0055-6) p. 229-244.

Forkortelser

ADSM Backupsystem fra IBM til LAN-data i dette tilfælde på IBM S/390.
AMS

b Bit. Mindste logiske enhed med værdien 0 eller 1.
B Byte. 8 bits [b]
BASIC Beginners' All-purpose Symbolic Instruction Code. Programmeringssprog, oprindeligt ustruktureret fortolkersprog.
BIOS Basic Input / Output System

CHAR Character, enkelt karaktér
CICS Customer Information ...
CPU Central Processing Unit
CRC Cyclic Redundancy Check. Metode til fejldetektion af en netværkspakke.
CUA Common User Access. Del af IBMs standardarkitektur (SAA) for EDB-systemer.

DB/2 Databasesystem fra IBM til forskellige platforme; S/390, AS/400, Windows etc.
DHCP Dynamic Host Configuration Protocol. Automatisk tildeling af adresse i IP-netværk af DHCP-server indenfor forud defineret interval(-ler).

ENUM Enumration. Listning af værdier

FRU IBM nummersystem. Unikt nummer for produktionsserie af type.

GB GigaByte. 1024 MB

IBM International Buisness Machines. Stor computervirksomhed.
INT Integer, heltal
IP Internet Protokol. OSI-lag 3.
IRQ Interrupt Request Que. Interruptniveauer i hardware.
ISDN Integrated Services Digital Network. Digitalt telefonnet, der starter hos kunden.

Kb Kilobit. 1024 bits [b]
KB KiloByte. 1024 bytes [B]

LAN Local Area Network

MAC Medium Access Control. Hardwareadresse i LAN.
Mb Megabits. 1024 Kb
MB MegaBytes. 1024 KB
ms milisekund. 1/1000 sekund.
MVS Multiple Virtual Systems. Operativsystem til mainframe fra IBM. Del af IBM OS/390.

NIC Network Interface Connector. Netværkskort
NT New Technology. Windows NT operativsystem fra Microsoft Inc. atp-huset anvender version 4.0.

ODBC Open DataBase Connectivity. Microsoft SQL-baseret teknik til at give adgang til andre databasesystemer.
OS/390 IBM operativsystem til IBMs mainframeplatform S/390. Indeholder bl.a. MVS.
OSA Open Systems Adaptor. IBM standard for hardwarearkitektur (Open Systems Platform) til centrale systemer.
OSI Open Systems Interconnection. Referencemodel for netværkskommunikation, også kaldet 7-lagsmodellen.

PCI Peripheral Component Interconnect. Udvidelsesbus (systembus) primært til PC-platformen, udviklet af Intel Corp. 1991-92.

RAM Ramdom Access Memory. Flygtig lagerform.
RDBMS Relational DataBase Management System. Relationelt databasesystem, fx. IBM DB/2.
ROM Read Only Memory. Fast lagerform.

SAA System Applications Architecture. Forsøg på konsistente grænseflader fra IBM
SAN Storage Area Network
SCSI Small Computer System Interface. Generel fysisk bus.
SMP Symmetric MultiProcessors. Flere processorer i én systemenhed.
SNA Systems Network Architecture. IBM netværksarkitektur, blandt andet implementeret i VTAM (Virtual Telecommunications Access Method)
SNI IBM mainframenetværk
SQL Structured Query Language. Forsøg på standard databasesprog. Også indskrevet som en del af SAA. Der findes forskellige dialekter, der kun delvist er indbyrdes kompatible.

TCP Transmission Control Protocol. OSI-lag 4.
TCP/IP se TCP og IP

UDP User Datagram Protocol. Enkel protokol uden CRC. OSI lag 3.
UML Unified Meta Language. Designsprog til systemudvikling.
UNC Universal Naming Convention. Navngivning af filstier i netværk.

VBA Visual Basic for Applications. Microsoft "standard"- programmeringssprog baseret på en delvis objektorienteret BASIC.

WAN Wide Area Network

Appendix A: Eksisterende systemer

Dette er en gennemgang af eksisterende systemer i atp-huset, med vægt på tekniske detaljer.

Systemet optræder i to former; dels et system i mainfram-miljøet bygget på IBM DB/2, dels en 'kopi' i det decentral PC-miljø på IBM Lotus Notes.

Hardwaresystem

atp-husets nuværende hardwaresystem er kort fortalt konstrueret i IBM DB/2 under OS/360 ved tre tabeller TDKHW, TDKHWARD og TDKHWKAB samlet i viewet VDKHW (View DriftKontrol HardWare) med følgende felter:

Feltnavn	Type	Længde	Beskrivelse
DAMANR	CHAR	8	Maskinnummer, ofte S/N
DAART	CHAR	16	Benævnelse, fx server.
DANAVN	CHAR	6	Navn for enhed
DALVDR	CHAR	10	Leverandør
DATYPE	CHAR	12	Maskintype/model
DAKBNR	CHAR	9	Kabelnummer
DAEL	CHAR	2	El-gruppe, bliver ikke brugt
DAADR	CHAR	4	Terminalnummer / adresse
DASNR	CHAR	4	Sektionsnummer
DAKKONT	CHAR	5	Kontornummer
DAIDAT	CHAR	6	Installationsdato
DAKID	CHAR	9	Kontaktnummer
DAGRP	CHAR	3	Garantiperiode i måneder
DAFINA	CHAR	11	Grafikdriver, oprideligt 'financieringsform'
DALPR	CHAR	3	Leasingperiode i måneder
DAOFR	CHAR	2	Grafik RAM [MB], oprindeligt 'opsigelsesfrist'
DAASD	CHAR	6	Start på afskrivningsperiode
DAAF	CHAR	3	Afskrivningsperiode i kvartaler
DAOKNT	CHAR	10	SCSI driver, oprindeligt 'ØA-kontonummer'
DAKPRI	CHAR	9	LAN driver, oprindeligt 'købspris (forsikring)'
DANPRI	CHAR	9	Antal harddiske, oprindeligt 'nypris (forsikring)'
DASDA	CHAR	6	Serviceaftalen startdato
DASTI	CHAR	3	Længde på serviceaftale
DASPRIS	CHAR	6	Købspris (faktura). Oprindeligt 'Pris på serviceaftale'
DASKON	CHAR	12	Operativsystem. Oprindeligt 'Servicekontraktnavn'
DASTLF	CHAR	8	Brugerinitialer. Oprindeligt 'Servicetelefonnummer'
DAKONC	CHAR	1	Kode for koncernaftale: J=ja, N=nej
DASTATUS	CHAR	8	Servernavn, opgave etc. Oprindeligt 'Status'
HENVMASKNR	CHAR	8	Henvisningsmaaskinnummer. Koble monitor til systemenhed
WSNR	CHAR	5	WS-nummer (workstation). Unikt løbenummer
LANADR	CHAR	12	LAN-adresse
PUADR	CHAR	8	Fysisk adresse i kontrolenhed
ADAPTOR1	CHAR	10	NIC: Tokenring, Ethernet, hastighed osv.
ADAPTOR2	CHAR	10	Grafikkkort
ADAPTOR3	CHAR	10	CD-ROM drev
ADAPTOR4	CHAR	10	Scanner
ADAPTOR5	CHAR	10	Ingen standard anvendelse
RAM	CHAR	3	RAM-mængde [MB]
HARDDISK	CHAR	3	Størrelse, oftest [GB]. Oprindeligt [MB]
NØGLENR	CHAR	6	Nøglenummer til enhed (Nøglebræt ifølge MAH)
PROCESSOR	CHAR	7	Forkortet efter uofficiel standard. Oprindeligt 'Processornummer'
COPROCES	CHAR	5	Coprocessor. Fra 386/486-dagene... Oprindeligt 'Coprocessornummer'

Tabel 6. Beskrivelse af viewet VDKHW.

IT Director

IT Director er et produkt fra IBMs datterselskab TIVOLI. IT-Director finder automatisk en del oplysninger i systemenheder, men kan kun i meget begrænset omfang scanne periferienheder. IT Director indsamler følgende [Nusbaum et al] hvert 5. sekund, med mindre andet er angivet:

CPU monitorer
- CPU utilisation
- CPU 'x' utilisation på SMP maskiner
Disk monitorer
(Indsamlingen sker for hvert ikke-flytbare fysiske drev der findes. Indsamlingen sker hvert 5. minut)
- Disk 1 workload
- Drev C: % plads brugt
- Drev C: plads tilbage
- Drev C: plads brugt
Hukommelsesmonitorer
- Låst hukommelse
- Hukommelse brugt
Netværks monitorer
(Indsamlingen sker for hvert installeret netværksdriver interface)
- Adapter 0 bytes modtaget
- Adaptor 0 bytes sendt
- Adaptor 0 pakker modtaget
- Adaptor 0 pakker sendt
- Adaptor 0 modtagefejl
- Adaptor 0 sendefejl
NT ydelsesmonitorer
(Antallet af monitorer kan variere. Indsamlingen sker direkte fra Windows NT Performance Monitor (PerfMon) sybsystemet. Disse monitorer skifter dynamisk. På et typisk Windows NT system vil mere end 3500 forskellige attributter blive overvåget af Windows NT Performance Monitor)
TCP/IP monitorer
(Interfacemonitorerne vil indsamle data for hvert konfigurerede IP netværks interface)
- Interface 0 broadcast pakker modtaget
- Interface 0 broadcast pakker sendt
- Interface 0 bytes modtaget
- Interface 0 bytes sendt
- Interface 0 unicast pakker modtaget
- Interface 0 unicast pakker sendt
- IP pakker modtaget
- IP pakker modtaget med fejl
- IP pakker sendt
- TCP forbindelser
- UDP datagrammer modtaget
- UDP datagrammer sendt
Proces monitorer
(Antallet af applikationer eller eksekveringer variere og kan konfigureres af IT Director Administrator fra Process Manager Console. Hver attribut præsenteres for hver eksekvering der overvåges. Indsamling af data sker hvert minut))
- Nuværende aktive processor
- Maksimum kørende på én gang
- Maksimum kørende i går
- Nye eksekveringer optalt
- Total eksekveringstid
- Gårsdagens eksekveringstid
- Gårsdagens nye eksekveringer
Sentry monitorer
(Sentry monitorerne afhænger af hvilke AMS pakker der er installeret, og har forskellige intervaller for indsamling af data)

Data opsamles i tabeller [Nusbaum et al] som beskrives i det følgende og stilles til rådighed i systemgrænsefladen (ODBC) ved hjælp af databasesystemet Microsoft SQL Server (p.t. version 6.5).

Spørgsmål:

Sletter IT Director automatisk?
Hvilke tabelkolonner læses automatisk?
Hvordan er It Director sat op i atp-huset? (scanningers indhold og interval)

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
DISK_TYPE	CHAR	32	Disk type (ENUM, nøgle 2)
DISK_INDEX	INT		(nøgle 3)
DISK_INTERFAC_TYPE	CHAR	32	Interface type (ENUM)
DISK_INTERFACE_DESC	CHAR	64
DISK_MEDIA_LOADED	CHAR	10	Er medie sat i nu? (ENUM)
DISK_REMOVABLE_DRIVE	CHAR	10	Er drev flytbart? (ENUM)
DISK_REMOVABLE_MEDIA	CHAR	10	Er medie flytbart? (ENUM)
DISK_DEVICE_ID	INT
DISK_LOGICAL_UNIT	INT
DISK_CYLINDERS	INT		Antal cylindre på disk
DISK_SECTORS_PER_TRACK	INT		Antal sektorer per spor på disk
DISK_SECTOR_SIZE	INT		Sektorstørrelse
DISK_TOTAL_SIZE_KB	INT		Disk lagerkapacitet [KB]
DISK_HEADS	INT		Antal hoveder i disk
DISK_BAD_SECTORS	INT		Antal sektorer med fejl på disk
DISK_PARTITIONS	INT		Antal partitioner på disk
DISK_TOTAL_SECTORS	INT		Antal sektorer på disk
DISK_FRU_INDEX	INT		FRU-værdi for disk

Tabel 7. Beskrivelse af IT Director tabel A1.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
SYSTEM_NAME	CHAR	64	Systemnavn
LOCATION	CHAR	64	Systems placering
USER_NAME	CHAR	64	Primær bruges navn
USER PHONE	CHAR	64	Primær brugers telefonnummer

Tabel 8. Beskrivelse af IT Director tabel A2.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
IDE_INDEX	INT		(nøgle 2)
IDE_BUS_TYPE	CHAR	32	IDE-bus type
IDE_LOCATION	CHAR	32	IDE tilslutning (master/slave, primær/sekundær)
DEVICES_CONNECTED	INT		Antal IDE enheder tilsluttet

Tabel 9. Beskrivelse af IT Director tabel A3.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
IDE_ADAPTER_INDEX	INT		(nøgle 2)
IDE DEVICE INDEX	INT		(nøgle 3)
DEVICE_TYPE	CHAR	32	Enhedstype (ENUM)
DEVICE_SIZE	INT		Størrelse på enhed [?]
UNIT_STATUS	CHAR	32	(ENUM)
MEDIA_STATUS	CHAR	32	(ENUM)
PRODUCT_ID	CHAR	40

Tabel 10. Beskrivelse af IT Director tabel A4.

Navn	Type	Beskrivelse
MANAGED_OBJ_ID	INT	Aktuelle objekts identitet (nøgle 1)
PHYSICAL_MEMORY_KB	INT	Total fysisk hukommelse installeret [KB]
FREE_PHYSICAL_MEMORY_KB	INT	Fri fysisk hukommelse [KB]
VIRTUAL_MEMORY_KB	INT	Total virtuel hukommelse / paging størrelse [KB]
FREE_VIRTUAL_MEMORY_KB	INT	Fri virtuel hukommelse / paging størrelse [KB]
PAGE_SIZE	INT	Page størrelse [B]

Tabel 11. Beskrivelse af it Director tabel A5.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
IP_INDEX	INT		Index (fx. adaptor-nummer) (nøgle 2)
IP_ADDRESS	CHAR	16	IP adresse i punktum-notation
IP_HOSTNAME	CHAR	255	IP host navn
IP_DOMAIN	CHAR	255	IP domænenavn
SUBNET_MASK	CHAR	16	IP subnet maske
NAMESERVER1	CHAR	16	Primær navneserver
NAMESERVER2	CHAR	16	Sekundær navneserver
DEFAULT_GATEWAY	CHAR	16	Standard gateway (router)
IP_FORWARDING	CHAR	10	IP forwarding sat til? (ENUM)
DHCP_ENABLED	CHAR	10	DHCP sat til? (ENUM)

Tabel 12. Beskrivelse af IT Director tabel A6.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
KEYBOARD_LAYOUT	CHAR	80	Beskrivelse af tastatur-layout
KEYBOARD_TYPE	CHAR	80	Tastatur-type
CONNECTOR_TYPE	CHAR	20	Stik type for tastatur (ENUM)
FRU_INDEX	INT		Index til FRU-tabel
COUNTRY_CODE	CHAR	3	Landekode (fx. US)
SUBCOUNTRY_CODE	CHAR	3	Landeunderkode (fx. 103)
CODEPAGE	INT		Codepage (fx. 437)
TYPEMATIC_RATE	INT		Karakterer per sekund
TYPEMATIC_DELAY	INT		Gentagelsesforsinkelse [ms]

Tabel 13. Beskrivelse af IT Director tabel A7.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
DRIVE_INDEX	INT		(nøgle 2)
DRIVE_TYPE	CHAR	20	Drevtype
DRIVE_NAME	CHAR	64	Drevnavn (fx G:)
DRIVE_PATH	CHAR	255	Sti til eksternt logisk drev
DRIVE_TOTAL_SIZE_KB	INT		Total størrelse [KB]
DRIVE_FREE_SIZE_KB	INT		Fri lagerplads [KB]

Tabel 14. Beskrivelse af IT Director tabel A8.

Navn	Type	Str.	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
BASE_MEMORY_KB	INT		Installeret grundhukommelse [KB]
FREE_BASE_MEMORY_KB	INT		Fri grundhukommelse [KB]
EXTENDED_MEMORY_KB	INT		Installeret ekstra hukommelse [KB]
FREE_EXTENDED_MEMORY_KB	INT		Fri ekstra hukommelse [KB]
EXTENDED_MANAGER_NAME	CHAR	64	Navn på styreprogram til ekstra hukommelse
EXTENDED_MANAGED_VERSION	CHAR	64	Version af styreprogram til ekstra hukommelse
EXPANDET_MEMORY_KB	INT		Installeret udvidet hukommelse [KB]
FREE_EXPANDED_MEMORY_KB	INT		Fri udvidet hukommelse [KB]
EXPANDED_MANAGER_NAME	CHAR	64	Navn på styreprogram til udvidet hukommelse
EXPANDED_MANAGER_VERSION	CHAR	64	Version af stypeprogram til udvidet hukommelse

Tabel 15. Beskrivelse af IT Director tabel A9.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
LABEL	CHAR	64	Kort identificerende beskrivelse
DESCRIPTION	CHAR	255	Beskrivelse af aktuelle objekt
FIRST_ATTEMPT	DATETIME		Dato og tid for første forsøgte opdatering af inventory
LAST_ATTEMPT	DATETIME		Dato og tid for sidst forsøgte opdatering af inventory
LAST_UPDATE	DATETIME		Dato og tid for sidste opdatering af inventory
DATE_CREATED	DATETIME		Dato og tid for emnets indtastning

Tabel 16. Beskrivelse af IT Director tabel A10.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
OP_SYS_INDEX	INT
OP_SYS_NAME	CHAR	64	Operativsystems navn (fx. NT eller OS/2)
OP_SYS_TYPE	CHAR	64	Operativsystems type (ENUM)
OP_SYS_VERSION	CHAR	64	Operativsystems version
OP_SYS_PRIMARY	CHAR	20	Primært operativsystem (ENUM)
OP_SYS_REVISION	CHAR	32	Operativsystems revisionsnummer (build, service pack)
OP_SYS_DESCRIPTION	CHAR	64	Beskrivelse af operativsystem

Tabel 17. Beskrivelse af IT Director tabel A11.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
PORT_INDEX	INT		(nøgle 2)
BASE_10_ADDRESS	INT
IRQ_USED	INT
LOGICAL_NAME	CHAR	32
CONNECTOR_TYPE	CHAR	40	(ENUM)

Tabel 18. Beskrivelse af IT Director tabel A12.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
PARTITION_INDEX	INT		(nøgle 2)
PARTITION_NAME	CHAR	32	Drevbogstav - normalt
PARTITION_TOTAL_SIZE_KB	INT		Partitionens samlede størrelse [KB]
PARTITION_FREE_SIZE_KB	INT		Fri plads i partition [KB]
PARTITION_LABEL	CHAR	40	Partionens beskrivelse, kort
PARTITION_FILE_SYSTEM	CHAR	32	(ENUM)

Tabel 19. Beskrivelse af IT Director tabel A13.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
PCI_BUS_NUMBER	INT		(nøgle 2)
PCI_DEVICE_NUMBER	INT		(nøgle 3)
MANUFACTURER	CHAR	40
PCI_TYPE	CHAR	40
CLASS_CODE	INT
VENDOR_ID	INT
DEVICE_ID	INT
REVISION_ID	INT
CACHE_LINE_SIZE	INT
LATENCY_TIMER	INT
MIN_GNT	INT
MAX_LAT	INT
INTERRUPT_LINE	INT
INTERRUPT_PIN	INT
ROM_BASE_ADDRESS	INT
HEADER_TYPE	INT
BIST	INT		Built-In Self-Test, indbygget selvtest
COMMAND_REGISTER	INT
STATUS_REGISTER	INT

Tabel 20. Beskrivelse af IT Director tabel A14.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
ASSET_TAG	CHAR	80

Tabel 21. Beskrivelse af IT Director tabel A15.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
TYPE	CHAR	32	Musetype (ENUM)
INTERFACE	CHAR	32	Interfacetype (ENUM)
IRQ	INT		Interruptniveau
BUTTONS	INT		Antal knapper på musen
PORT_NAME	CHAR	32
DRIVER_NAME	CHAR	32
DRIVER_VERSION	CHAR	32
DOUBLE_CLICK_RATE	INT		Interval for dobbeltklik [ms]
HANDEDNESS	CHAR	20	Højre- eller venstrehåndet (ENUM)
SENSITIVITY	INT		[mickeys/cm]

Tabel 22. Beskrivelse af IT Director tabel A16.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
PRINTER_INDEX	INT
PORT	CHAR	40
QUEUE	CHAR	40
DRIVER	CHAR	40
MODEL	CHAR	40

Tabel 23. Beskrivelse af IT Director tabel A17.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
PROCESSOR_INDEX	INT		(nøgle 2)
PROCESSOR_TYPE	CHAR	32	Processortype (ENUM)
FAMILY	CHAR	32	Processorfamilie (ENUM)
VERSION	CHAR	80	Processorversion
MAXIMUM_SPEED	INT		Maksimal clockfrekvens [MHz]
CURRENT_SPEED	INT		Clockfrekvens for installeret processor [MHz]
UPGRADE	CHAR	20	Opgraderingsmetode (ENUM)
FRU_INDEX	INT
INTERNAL_CACHE	CHAR	20	Intern (1st level) cache (ENUM)
EXTERNAL_CACHE	CHAR	20	Ekstern (2nd level) cache (ENUM)

Tabel 24. Beskrivelse af IT Director tabel A18.

Navn	Type	Størrelse	Beskrivelse
MANAGED_BJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
SCSI_ADAPTOR_INDEX	INT		(nøgle 2)
ADAPTOR_TYPE	CHAR	40
LOCATION	CHAR	40
PUN	INT		Physical Unit Number
LUN	INT		Logical Unit Number
BUS_TYPE	CHAR	40	[bits]
IO_ACCESS	CHAR	40	(ENUM)
HOST_BUS	CHAR	40	(ENUM)
HOST_BUS_WIDTH	INT		[bits]
ADDRESS_OVER_16	CHAR	40	Adresser over 16 MB (ENUM)
SCB_COMMANDS	CHAR	40	Understøtter SCB (ENUM)
SCATTER_GATHER	CHAR	40	(ENUM)
CHS	CHAR	40	Cylinder/Hoved/Sektor addressering (ENUM)
MAX_SCATTER_GATHER_LIST	INT
MAX_CDB_L FNGTH	INT		Maksimal længde af kontroldatablok [B]
ADD_MAJOR_LEVEL	INT
ADD_MINOR_LEVEL	INT
DEVICES_CONNECTED	INT

Tabel 25. Beskrivelse af IT Director tabel A19.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
SCSI_ADAPTOR_INDEX	INT		(nøgle 2)
SCSI_DEVICE_INDEX	INT		(nøgle 3)
PUN	INT		Physical Unit Number
LUN	INT		Logical Unit Number
DEVICE_TYPE	CHAR	32	(ENUM)
DEVICE_SIZE	INT
VENDOR_ID	CHAR	40
PRODUCT_ID	CHAR	40
PRODUCT_REVISION_LEVEL	CHAR	40
VENDOR_STRING	CHAR	255
VENDOR_DATA	CHAR	255
SERIAL_NUMBER	CHAR	40

Tabel 26. Beskrivelse af IT Director tabel A20.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
PORT_INDEX	INT		(nøgle 2)
BASE_10_ADDRESS	INT
IRQ_USED	INT
LOGICAL_NAME	CHAR	32
CONNECTOR_TYPE	CHAR	40	(ENUM)

Tabel 27. Beskrivelse af IT Director tabel A21.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekte identitet (nøgle 1)
SYSDESCR	CHAR	255
SYSOBJEC_ND	CHAR	255
SYSUPTIME	DATETIME
SYSCONTACT	CHAR	255
SYSNAME	CHAR	255
SYSLOCATION	CHAR	255

Tabel 28. Beskrivelse af IT Director tabel A22.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
PROGRAM_TITLE	CHAR	64
INSTALL_PATH	CHAR	255
VERSION_ID	CHAR	16
RELEASE_LEVEL	CHAR	12
VENDOR_NAME	CHAR	32
FILE_DATETIME	DATETIME
MAJOR_VERSION	CHAR	32
MINOR_VERSION	CHAR	32
REVISION	CHAR	32
BUILD	CHAR	32
LANGUAGE_EDITION	CHAR	32
ID_CODE	CHAR	32

Tabel 29. Beskrivelse af IT Director tabel A23.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
BIOS_INDEX	INT		(nøgle 2)
BIOS_MANUFACTURER	CHAR	40
BIOS_VERSION	CHAR	40
BIOS_RELEASE_DATE	DATETIME

Tabel 30. Beskrivelse af IT Director tabel A24.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
RESOURCE_INDEX	INT		(nøgle 2)
RESOURCE_USER	INT
RESOURCE_SET	INT
DESCRIPTION	CHAR	80
RESOURCE_WPE	CHAR	20
RESOURCE_NUMBER	INT
START_ADRESS	CHAR	16
END_ADDRESS	CHAR	16

Tabel 31. Beskrivelse af IT Director tabel A25.

Navn	Type	Størrelse	Beskirvelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
VIDEO_INDEX	INT		Adapter index (nøgle 2)
VIDEO_ADAPTER	CHAR	40	Aktuelle adapter (i brug)
VIDEO_TYPE	CHAR	40	Monitor-type
VIDEO_MEMORY_KB	INT		Videohukommelse [KB]
COLORS	INT		Antal farver til visning
HORIZONTAL_RES	INT		Horisontal opløsning til visning [pixel]
VERTICAL_RES	INT		Vertikal opløsning til visning [pixel]
BITS_PER_PIXEL	INT		Antal bits per pixel [b]
VIDEO_SUBSYSTEM	INT		Video subsystem, 0 = primært
SLOT_LOCATION	INT		Videoadapter slot

Tabel 32. Beskrivelse af IT Director tabel A26.

Navn	Type	Størrelse	Beskrivelse
MANAGED_OBJ_ID	INT		Aktuelle objekts identitet (nøgle 1)
COMPUTER_NAME	CHAR	16	Computernavn
USERNAME	CHAR	16	Brugernavn
DOMAIN	CHAR	16	Domænenavn
REG_OWNER	CHAR	80	Registreret bruger
REG_ORGANIZATION	CHAR	80	Registreret organisation
REG_PRODUCT_ID	CHAR	40	Registreret produkts identitet

Tabel 33. Beskrivelse af IT Director tabel A27.

Sagbehandleroplysninger

DB/2 viewene VSASTAM (View Sagsbehandler Stamdata) og VSASEKT (View Sagsbehandler Sektionsdata) som kort beskrives nedenfor. Beskrivelserne er hentet i Data Dictionary på atp-husets mainframe:

Navn	Type	Størrelse	Beskrivelse
INIT	CHAR	3	Initialer på person ansat på atp. Initialer på sagsbehandler
SBHNAVN	CHAR	30	Sagsbehandlerens fulde navn
PRVTLFNR	DECIMAL	9	atp-ansattes private telefonnummer
LOKTLFNR	DECIMAL	5	Lokaltelefonnummer. Arbejdsgiver lokaltelefonnummer
KONTORNR	CHAR	5	Kontornummer
STILLING	CHAR	20	Stillingsbetegnelse
SASTATUS	CHAR	1	Kode for elever/fiktive/udlån
STED	CHAR	4	Sektionsnummer. Sektion 0000 til 9999
GLLØNNR	DECIMAL	5	Gammelt lønnummer
PRINTER	CHAR	8	'Personlig' printer
TRANSKOD	CHAR	4	Personlig transaktionskode
SINIT	CHAR	3	Initialer på person, der sidst har opdateret
AJOURDTO	DECIMAL	9	Ajourføringsdato
AJOURTID	DECIMAL	9	Ajourføringstidspunkt

Tabel 34. Beskrivelse af viewet VSASTAM.

Navn	Type	Størrelse	Beskrivelse
STED	CHAR	4	Sektionsnummer. Sektion 0000 til 9999
HAFDNR	CHAR	1	Hovedafdelingsnummer
AFDNR	CHAR	2	Afdelingsnummer
OMRNR	CHAR	3	Områdenummer
SEKNAVN	CHAR	35	Sektionsnavn
SEKFORK	CHAR	6	Sektionsforkortelse
LEDER	CHAR	3	Sektionslederens initialer
POSTANSV	CHAR	3	Initialer på den postansvarlige
GLSEKNR	CHAR	3	Gammelt sektionsnummer
STEDHEN	CHAR	4	Stedhenvisning (??)
SINIT	CHAR	3	Initialer på den person, der sidst har opdateret
SASTATUS	CHAR	1	Kode for elever/fiktive/udlån
AJOURDTO	DECIMAL	9	Ajourføringsdato
AJOURTID	DECIMAL	9	Ajourføringstidspunkt

Tabel 35. Beskrivelse af viewet VSASEKT.

Installation

Hardware

Mainframe IBM S/390), servere (IBM NetFinity), arbejdsstationer (IBM PC 300), printere (mest Lexmark)

LAN

Protokol: TCP/IP med enkelte eksempler på NetBEUI eller IPX.

Topologi: 16 Mb TokenRing, under udskiftning fra CAU (Control Access Unit)/LAM (Local Access Module) til switched netværk

Enheder: CAU/LAM fra IBM, switche fra Madge (eneste reelle TokenRing leverandør worldwide...)

SAN

Disksys fra Hitachi, SCSI-kabinetter, RAID-konfigurationer.

Software

NT (server, enterprice, workstation), Microsoft Office, IBM DB/2, IBM Lotus Notes, systemmanagement, applikationer, værktøjer til for eksempel back-up (ADSM)

Eksterne forbindelser

analoge linjer, ISDN, fast linje (firewalls og proxys), routere samt systemer til brugerverificering.

Appendix B: Inventory-systemet

Tabeller

Datatyperne er som i Access 97. Vi henviser til dokumentation og litteratur herom.

Tabellen 'T-Batch'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Batchværdi' Datatypen "Tekst"

Batchbetegnelsen som producenten angiver den.

Feltet 'TypeId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Type.

Tabellen 'T-Betaling'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Betalingsform' Datatypen "Tekst"

Serviceaftalens betalingsform; engangsbeløb, faste intervaller, abonnementsaftale og så videre

Tabellen 'T-Bruger'

Feltet 'Id' Datatypen "Autonummerering"

Primær Nøgle.

Feltet 'Initialer' Datatypen "Tekst"

Initialer på bruger, som hentes i sagsbehandlersystemet.

Feltet 'Navn' Datatypen "Tekst"

Navn på bruger, hentes i sagsbehandlersystemet.

Feltet 'Lokaletelefonnummer' Datatypen "Tekst"

Brugerens lokaltelefonnummer.

Feltet 'Adresse' Datatypen "Tekst"

Brugerens privatadresse.

Feltet 'Postdistrikt' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Postnummer.

Feltet 'Hjemmetelefonnummer' Datatypen "Tekst"

Brugerens hjemmetelefonnummer.

Tabellen 'T-Domæne'

Indeholder begreber, der hovedsagligt er relevante for et IP-netværk. atp-huset har et single-domain design af deres netværk, så der vil ikke være mange records i denne tabel...

Feltet 'Domæne' Datatypen "Tekst"

Domænets navn. Hvis der er benyttede forkortelser eller sammenskrivninger, er det disse der registreres.

Feltet 'Subnet' Datatypen "Tekst"

Adressemasken for subnetadressering.

Feltet 'Primærnavneserver' Datatypen "Tekst"

Netværksnavnet for det primære navneserver.

Feltet 'Sekundærnavneserver' Datatypen "Tekst"

Netværksnavnet for den sekundære navneserver.

Feltet 'Gateway' Datatypen "Tekst"

Adresse for netværkets gateway.

Tabellen 'T-Enhed'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Serienummer' Datatypen "Tekst"

Enhedens serienummer som producenten angiver den, også i format.

Feltet 'Produktionsdato' Datatypen "Kort datoformat"

Hvornår enheden tages i brug i produktionsmiljøet.

Feltet 'Værdi' Datatypen "Valuta"

Enhedens forsikringsværdi. Det er kun den primæreværdi der værdisættes.

Feltet 'TypeId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Type.

Feltet 'KategoriId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Kategori.

Feltet 'FakturaId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Faktura.

Feltet 'GarantiId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Garanti

Feltet 'NetværksId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Netværk.

Feltet 'ServiceaftaleId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Serviceaftale.

Feltet 'LeverandørId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Leverandør.

Feltet 'BrugerId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Bruger. Sekundære enheder overtager 'BrugerId' fra primære enheder.

Feltet 'PlaceringId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Placering. Sekundære enheder overtager 'PlaceringId' fra primære enheder.

Tabellen 'T-Faktura'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle

Feltet 'Fakturanummer' Datatypen "Tekst"

Det på fakuraen trykte nummer.

Feltet 'Fakturadato' Datatypen "Kort datoformat"

Datoen, som er trykt på fakturaen.

Tabellen 'T-Fakturagaranti'

Tabel til kontrol af mange-til-mange relationen mellem tabellerne T-Faktura og T-Garanti.

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'FakturaId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Faktura.

Feltet 'GarantiId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Garanti.

Tabellen 'T-Garanti'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Garantiperiode' Datatypen "Tekst"

Angivelse af længden af garantien.

Tabellen 'T-Kategori'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Kategoribeskrivelse' Datatypen "Tekst"

Kategoriens beskrivende navn, for eksempel "Server".

Tabellen 'T-Kontakt'

Feltet 'Kontakt' Datatypen "Autonummerering"

Primær nøgle

Feltet 'KontaktformId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Kontaktform

Feltet 'Værdi' Datatypen "Tekst"

Værdien af den enkelte kontakt, for eksempel det reelle faxnummer.

Tabellen 'T-Kontaktform'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Kontaktform' Datatypen "Tekst"

En kort betegnelse for den enkelte kontaktform, for eksempel "Faxnummer".

Tabellen 'T-Kontaktperson'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Navn' Datatypen "Tekst"

Kontaktpersonens navn. Vi har bevidst ikke skilt navnet ud i for- og efternavn, da det ikke vil have den store nytteværdi, mens indtastningen bliver mere kompleks.

Feltet 'LeverandørId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Leverandør.

Tabellen 'T-Leverandør'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle

Feltet 'Virksomhed' Datatypen "Tekst"

Navnet på leverandørens virksomhed.

Feltet 'Adresse' Datatypen "Tekst"

Adressen for leverandøren.

Feltet 'PostnummerId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Postnummer.

Tabellen 'T-Model'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Modelbeskrivelse' Datatypen "Tekst"

Tekstbeskrivelse af modellen, oftest producentens modelbetegnelse.

Feltet 'ProducentId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Producent.

Tabellen 'T-Netværk'

Der er i det eksisterende hardwaresystem kun et sæt netværksoplysninger til hver enhed, som regel til IP-protokollen. Dette design har vi videreført - efter aftale med atp-husets projektledelse - i Inventory-systemet.

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Fysiskadresse' Datatypen "Tekst"

Enhedens fulde fysiske adresse på netværket.

Feltet 'Stiknummer' Datatypen "Tekst"

Nummeret på vægudtaget eller andet udtag i lokalet til netværket.

Feltet 'Logiskadresse' Datatypen "Tekst"

Enhedens fulde logiske adresse på netværket.

Feltet 'Navn' Datatypen "Tekst"

Enhedens netværksnavn.

Feltet 'Forwarding' Datatypen "Ja/Nej"

Om der er etableret forwarding for trafikken til enheden på netværket.

Feltet 'Dynamiskadresse' Datatypen "Ja/Nej"

Om der er sat dynamisk tildeling af logisk adresse op for enheden. Selve teldelingen fremgår af netværkets designdokumentation.

Feltet 'DomæneId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Domæne.

Tabellen 'T-Niveau'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Serviceniveau' Datatypen "Tekst"

Det aftalte niveau for service, for eksempel 3 timers tilkald, næste arbejdsdag eller 8 timer i normal arbejdstid.

Tabellen 'T-Placering'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Lokalitet' Datatypen "Tekst"

Værdien er enten et lokale i sagsbehandlersystemet, et rack eller "Hjemme". Et rack er altid placeret i atp-husets maskinstue.

Tabellen 'T-Postnummer'

Feltet 'Postnummer' Datatypen "Tekst"

Databærende primærnøgle. Postnummer, også begrænsede muligheder for udenlandske postnumre i kraft af datatypen.

Feltet 'Postdistrikt' Datatypen "Tekst"

Navnet på det gældende postnummer.

Tabellen 'T-Producent'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Producentbeskrivelse' Datatypen "Tekst"

Producentens navn, oftest det fulde navn for at undgå forveksling ved forkortelser.

Tabellen 'T-Reparation'

Feltet 'Id' Datatypen "Autonummer"

Primær nøgle

Feltet 'Startdato' Datatypen "Kort datoformat"

Datoen hvor en enhed er afsendt eller afhentet for reparation

Feltet 'Slutdato' Datatypen "Kort datoformat"

Hvornår en enhed er modtaget fra reparation

Feltet 'Beløb' Datatypen "Valuta"

Samlede reparationsomkostninger

Feltet 'Beskrivelse' Datatypen "Tekst"

Beskrivelse af reparationen i fritekst

Feltet 'VirksomhedsId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Leverandør.

Feltet 'EnhedId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Enhed.

Tabellen 'T-Sammenhæng'

Lagring af mange-til-mange relationen for enhed på enhed.

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle

Feltet 'EnhedId1' Datatypen "Langt heltal"

Fremmednøgle for den primære enhed til tabellen T-Enhed.

Feltet 'EnhedId2' Datatypen "Langt heltal"

Fremmednøgle for den sekundære enhed til tabellen T-Enhed.

Tabellen 'T-Serviceaftale'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Aftalenummer' Datatypen "Tekst"

Det på servicekontrakten trykte nummer.

Feltet 'Startdato' Datatypen "Kort datoformat"

Datoen for aftalens ikrafttræden.

Feltet 'Slutdato' Datatypen "Kort datoformat"

Datoen for aftalens ophør.

Feltet 'LeverandørId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Leverandør.

Feltet 'BetalingId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Betaling.

Feltet 'NiveauId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Niveau.

Tabellen 'T-Type'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Typebeskrivelse' Datatypen "Tekst"

Beskrivelse af typen, som regel producentens typebetegnelse.

Feltet 'ModelId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Model.

Tabellen 'T-Version'

Feltet 'Id' Datatypen "Autonummerering"

Primær nøgle.

Feltet 'Versionsnummer' Datatypen "Tekst"

Det gældende versionsnummer i den form producenten opgiver det.

Feltet 'TypeId' Datatypen "Langt heltal"

Fremmednøgle til tabellen T-Type.

Forespørgsler

Der er lavet nogle forespørgsler for at få brugergrænsefladen til at vise hvad der faktisk er i databasen. Specielt i forbindelse med Enhed-Type-Model- Producent sammenhængen, hvor fremmednøgleværdien automatisk hentes i en forespørgsel på den overliggende tabel i sammenhængen og et felt i en formular.

Forespørgslerne har vi af hensyn til overblikket navngivet med "Q-" i starten af navnet på den enkelte forespørgsel.

Formularer

Det tilstræbes at lægge funktionalitet i separate forespørgsler eller moduler, alt efter opgavens art, da dette er bedst i overensstemmelse med gældende god skik for programmering.

Brugergrænsefladen er en hovedformular, der benytter en del underformularer or at få den tidligere beskrevet faneblads-struktur til at gå op.

Formularer, både hoved- og under-, er navngivet med "F-" i starten af navnet for at fremme overskueligheden.

Rapporter

...opbygges med udstrakt brug af Access indbyggede funktionalitet for sådanne. Igen har vi søgt en entydighed i navngivningen, da rapporternes navne starter med "R-".

Makroer

Da vi har erfaret at der er store problemer med at flytte Access applikationer med makroer, har vi i videst mulige omfang undgået disse... Dette er dog ikke lykkedes helt, blandt andet grundet vores begrænsede færdigheder ud i VBA.

Appendix C: Konvertering af data

Hardwaresystemet

Data fra det eksisterende hardwaresystem overføres til Inventory-systemet med en opdaterende forespørgsel via ODBC-styret kald til viewet VDKHW ( appendix A ) eller en tidssvarende kopi af dette.

Appendix D: Projektdagbog

25JAN Start VSU. Kort om hvad er VSU. Danny siger at vi skal vælge en virksomhed til at lave projekt for. Danny udlevere side om hvorledes kan et VSU-projekt opbygges!

26JAN ATP siger OK for projektet til Niels.

27JAN VSU, almindelig undervisning. Niels fortæller kort om hvad atp vil have fra os.

01FEB VSU, almindelig undervisning

03FEB VSU, almindelig undervisning

08FEB VSU, almindelig undervisning. Snakker kort om atp-projektet. Skal høre mere om det i morgen.

09FEB Møde med atp. Fik forklaret hvad det gik ud på. Mest fik vejledningsmateriale om hvad de gerne vil have fra os. Aftalte at vi skulle lave en tidsplan som skulle afleveres til dem.

10FEB VSU, almindelig undervisning. Snakkede lidt om mødet i går. Niels har snakket mere med dem, og de har sagt at vi ikke skal holde os 100% til det materiale vi fik af Kim. Vi aftaler at vi ikke mødes på mandag.

12FEB Lars sender mail vedr. problemformulering.

14FEB Gruppemøde (aflyst). Aftaler at det ikke bliver til noget pga. arbejde og andre ting.

15FEB VSU, almindelig undervisning. Mikkel sender mail vedr. problemformulering.

17FEB VSU, alminelig undervisning. Niels har nogle informationer vedr. atp og viser os skærmprint af eksisterende system..!!

19FEB Gruppemøde hos Niels (Gørløse). Snakkede om tidsplan og om hvad atp skal have fra os gennem processen. Blev næsten færdig med problemformulering.

22FEB VSU. Fik første kopi af Niels..!! Danny bliver præsenteret for projektet og siger foreløbigt OK.
Gruppe arbejde (oven på kantinen). Set mere på problemformulering lavet div. tilføjelser/ændringer.
Niels opdatere i rapport/kopi.
Snakkede om at der også skal registreres RAM og konsulenter i systemet.

23FEB Mail fra Niels om Inventory.

24FEB VSU. Mikkel er syg..!!!! Almindelig VSU undervisning om normalisering.

25FEB Niels sender mail om at han har lavet udskrift fra atp af query til forsikring mm.
Skriver desuden at vi ikke skal se meget på det nuværende hardwaresystem, for atp går ud fra at vi laver en ny datamodel og så konverterer data.

26FEB VSU. Aflevere problemformulering til Niels Brock
Undervisning på Niels Brock om projektledelse. Skal aflevere problemformulering..!!
Niels møder for sent..!
Snakkede om projektet. Har vi en projektleder..?? Eller en mødeordstyrer..??
Vi bliver ihvertfald enige om at Lars er sidesporschef..!!
Niels læser problemformulering højt, vi siger OK, og aflevere til Danny..!! Han beder os om at udbyde nogle ting, arbejder videre med det, og ser mere på klassediagrammet.
Lektier til næste gang:

Niels: Virksomhedsdel, skrive problemformulering og IT.Director ind.
Lars: Skriver klasse diagram ind i PowerPoint.
Michala: Laver batoff analyse, og skriver mødeplan ind i Word, da Niels skal bruge det til atp.
Mikkel: Ser på problemområdet.

Lars mailer klassediagram, da han er kommet hjem.

27FEB Lars mailer klassespecifikationer.

29FEB VSU. Michala mailer afleverings/mødeplan (til brug for atp)
Almindelig VSU undervisning. Danny siger at fra nu af, vil det blive sådan at han underviser en times tid, og derefter vil der være gruppearbejde. Gruppearbejde (på MacD)
Tilpasser klassediagram og specifikation, Lars retter den og mailer tilbage.
Tilpasser lidt i Mikkels hændelses oversigt som Mikkel vil maile tilbage til os alle.!! Måske til apendix..!!??
Vi aftaler at gruppemødet på søndag skal være hos Niels.
Lars mailer revideret klassediagram og specifikation.

01MAR Michala mailer formål og battoff.

02MAR VSU, almindelig undervisning. Niels mailer tabeller.

05MAR Gruppemøde hos Niels (Gørløse). Lars arbejder videre med klassediagrammet. Alle skal se på beskrivelser af de enkelte klasser.
Mikkel skal opdatere kriterier og maile til alle (ikke kun Niels).
Michala skal se på et rigt billed..??!!

07MAR VSU. Aflevere virksomhedsdel til Niels Brock (Mikkel skriver dagbog..!!?)
Feedback på virksomhedsdel: Virksomhedsanalyse skal udvides, omstrukturering af vores klassediagram.
Niels skal færdiggøre tabel oversigten af IT.Director, så Mikkel kan påbegynde beskrivelsen af de enkelte tabeller.
Lars implementere de ændringer der er blevet lavet under dagens feedback.!
Michala har lovet at lave en kæmpe kartoffelkage, til næste gruppemøde i weekenden.
Niels udspecificere arbejdsgange, brugeroplysninger etc. Og tilføjer det i virksomheds analyse.

09MAR VSU, almindelig undervisning om SQL.
Gruppearbejde: Feedback fra Torben, Lars vil rette i klassediagrammet. Der skulle rettes en del, men Torben syntes at vi dog havde fat i noget rigtigt...
Faktisk troede han at det kunne gå hen at blive for småt, men så snakkede vi skærmbilleder, og om at lave dem i faneblad design, så det skulle blive mere overskueligt. Så han sagde OK for det.

14MAR VSU, almindelig undervisning..!!
Feedback fra Randis gruppe på virksomhedsdelen. Vi skal beskrive dataflow bedre..!! Måske skal vi forberede os noget bedre til næste gang..!! Så vi alle har et punkt at fortælle om..!!?
Til næste gang:

Michala: Laver MBI/rigt billed/dataflow diagram..??! Og skriver første del af dagbogen ind.!!
Niels: Ser på funktionaliteten jfr. Jakob og Kims bilag.
Mikkel: Laver te og kaffe til på søndag, og ser evt. lidt på..??
Lars: Ser på hændelser.!

15MAR Michala mailer dagbog.

16MAR VSU undervisning om SQL.

19MAR Gruppemøde kl. 9.00 hos Mikkel
Michala skulle på "arbejde". Tilstandsdiagrammer er påbegyndt, tilrettelser på klassediagram.

21MAR VSU. Undervisning om kvalitet.
Gruppearbejde: Talte om klasse og tilstandsdiagram. Ser opgaven igennem.
Til næste gang:

Michala: Om design formål
Niels: Om komponentarkitektur
Lars ser på standarder
Mikkel om funktionskomponent.

23MAR VSU. Torben har migræne derfor gruppearbejde hele aftenen, med en aftalt "gruppetid" hos Torben kl. 19:35
Småtilrettelser i klassediagrammet påbegyndelse og diskussion af skærmbilleder.
Torben viser hvordan der kan laves faneblade i Access, og ser igen op klassediagrammet.
Niels sender mail om funktionskomponenten.

26MAR Gruppemøde kl. 10.00 hos Niels. Gennemgår rapporten punkt for punkt i analyse og design, tilføjer og ændre til.

27MAR Michala sender mail om designformål og dataflow diagram.

28MAR VSU. Aflevere analyse og design til Niels Brock
Kort VSU undervisning. Blev færdig med logistik bogen...
Gruppearbejde, ser på skærmbilleder.
Snak med Danny kl. 19.30, lidt feedback på analyse og design, vi skal ikke lave det hele i design men i analysen.!! Dvs. at Niels skal rykke rundt på noget tekst. Danny lover at læse opgaven til næste gang.

30MAR VSU. Torben siger gruppearbejde. Lars fortæller at han har prøvet at lave lidt i Access, spiser Michalas kage og Mikkel snakker om at han vil lave et rigt billede.

02APR Gruppemødehos Mikkel kl. 10.00. Spiser morgenmad, ser igen opgaven igennem. Uddeler opgaver, Michala viser dataflow, skal skrive det ind i Power point.
Niels er ved et appendix C om konvertering af data.
Til næste gang:

Michala: Brugsmønstre, ER diagram og læse i projektledelses bogen til diskutionen.
Lars: Brugergrænseflade komponent.
Niels: UML og komponentarkitektur.
Mikkel: problem og anvendelses området.

Går i grupper:
Lars og Michala laver et ER diagram.
Mikkel og Niels ser på inventory tabellerne. Niels og Mikkel er kommet frem til at IT-Director ikke kan bruges til noget, da det ikke er entydige oplysninger der kommer frem!
Michala mailer dataflow-diagram og en del af dagbogen.

04APR VSU aflyst, aftaler derfor at mødes på atp kl. 17.00 med JAW. Fortæller om Niels' og Mikkels konklusion om IT-Director! Ser opgaven igennem. JAW vil læse den igennem, se på struktur og komme med kommentarer. Niels vil give kopi til IB og LAV.
Aftaler møde med atp på fredag. ( MIM, NGR, JAW og LAV )

06APR Gruppearbejde. Alle skal lave brugsmønstre til næste gang.
Feedback fra Danny, generel feedback på opgaven, Danny beskriver en model med datatype og dataflow, og disses vej til aktører og brugsmønstre for at opretholde den "røde" tråd i opgaven.
Vil endvidere have at vi laver flere tilstandsdiagrammer, selvom disse bliver trivielle.
Skal beskrive mere i modelkomponent strukturen og systemgrænsefladekomponenten, vil desuden have at appendix A om virksomheden atp, skal rykkes frem i opgaven.!! Ellers syntes han dog at vi har fat i noget rigtigt.

07APR Inventory møde hos atp, med NGR, MIM, JAW og LAV.
Gennemgår opgaven og kommer med små rettelser, diskuttere beslutningen om IT Director. Jakob vil gå videre med denne beslutning.

11APR VSU undervisning om VB og brugergrænsefladen. Niels fortæller om mødet i fredags.

13APR VSU undervisning om OOAD.!!
Gruppearbejde:

Michala skal lave dataflow om så det bliver sammenhængende.
Mikkel mangler Problem- og anvendelsesområdet.
Lars skal se mere på E/R diagrammet, fremmednøgler mm.
Niels skal lave beskrivelser af klasser.

16APR Gruppemøde kl. 09.00 hos Mikkel. Spiser morgenmad. Ser opgaven igennem punkt for punkt, tegner komponentstruktur og laver rettelser i E/R diagrammet.

18APR VSU. Lars skriver dagbog. Projekt kigges igennem fordi der ønskes en mere sammenhængende formulering.

Niels kigger på funktionslisten
Michala kigger på brugsmønstre
Lars kigger på tabel beskrivelser
Mikkel kigger på brugergrænsefladekomponenten.

20APR - 24APR Påske.. (Niels bliver gift :-)

25APR VSU, Michala syg. Gruppearbejde, løst og fast - mest løst...

27APR VSU, gruppearbejde, Lars får svar på sine spørgsmål, han har stillet i sin gang med implementeringen. Snakker med Torben.

30APR Gruppearbejde kl. 09.00 hos Lars. Spiser morgenmad, laver rettelser i ER diagrammet, Lars viser os lidt i Access.

02MAJ VSU, møde med. Danny og Torben.
Snak med Danny:

Om klassediagrammet: Danny har en huskeregel: Spørg altid om det består af? For eksempel består enhed af netværk.?
Syntes at tabelbeskrivelsen skal i appendix.
Siger at det er ok med over 47 sider.

Snak om Torben:

Ser på Access.

Derefter gruppearbejde:

Ser opgaven igennem, som altid punkt for punkt.

04MAJ VSU, møde Torben
Gruppearbejde: Spiser lækker is, tak Mikkel!
Gennemgår klasse, ER- og Access-diagrammer for at finde eventuelle ikke-sammehænge.

06MAJ VSU (lørdag). Gruppearbejde, Lars roder med Access.
Ser igen på de tre diagrammer og sikre sammenhængen.
Snak med Torben, roder videre med Access.

09MAJ VSU. Gruppearbejde, (9 dage til projektet skal afleveres.)
Niels har rettet lidt i ER diagrammet, ser opgaven igennem. Går tidligt for at gå hjem og skrive.

11MAJ VSU gruppearbejde, Torben roder med Access, men kommer ikke lige frem til et resultat, vil derfor se videre på det i weekenden.

14MAJ Gruppemøde hos Niels kl. 09.00. JAW er med for at evaluere projektet, snakker om opgaven og diskkutionen omkring IT-director. JAW vil skrive kommentar til opgaven og give den til NGR inden tirsdag.

16MAJ Danny udskyder aflevering af opgaven til torsdag d. 25.05.00. Gennemgår pensum og eksamen. Gruppen aftaler at fortsat mødes tirsdag og torsdag for at læse pensum sammen.
Mikkel har lavet en plan over pensum vil maile den ud til os alle, så den kan bruges til senere eksamens plan.
Aftaler at til næste gang skal alle have lavet brugsmønstre, disse deles ud med tre til hver.

18MAJ VSU. Gruppearbejde. Vi ser på tilstandsiagrammer og konstaterer at de er ret ens! Niels får dem med hjem for at lægge dem i rapporten.

23MAJ VSU. Gruppearbejde. Niels gennemgår de seneste ændringer i rapporten og der tales OSI og OSA.

25MAJ VSU. Aflevere projekt til Niels Brock (og atp). Alle har læst pensum i OOAD for hurtig repetition.

Eksamensforberedelse:

30MAJ Repetition af økonomistyring (Vi mødes i Gørløse kl. 1700).

01JUN Kristi luftfart...

06JUN Repetition af logistik (Helsingør kl. 1700).

08JUN Repetition af SQL og database (Helsingør kl. 1700).

13JUN Eksamensforberedelse; tidsplan, emner, Inventory-systemets database etc (Helsingør kl. 1700).

15/16JUN Eksamen!

1. Inventory Hardware. Atp-huset benytter inventory-begrebet, derfor gør vi også.

2. Host. I atp-huset menes mainframesystemet, men på grund af kollisionen med host begrebet i TCP/IP (UNIX) foretrækker vi mainframe. I tvivltilfælde læs mainframe (IBM S/390) - i denne rapport.

3. DBS DataBase System.

4. Eet er at være lærd, et Andet vis og klog (Holberg: "Peder Paars" 3,1; 1720)

Videregående Systemudvikling

Rapport

Forord

Begrundelse for valg

Rapport

Problemformulering og projektbeskrivelse

Problemformulering

Afgrænsning

Metoder og plan

Foranalyse

Virksomheden atp

Virksomhedsanalyse

Nuværende arbejdsgang

"Dataflow"

Brugertyper

Analyse

Opgave

Formål

Systemdefinition

Omgivelser

Problemområde

Kort om de enkelte enheders forhold til hinanden

Anvendelsesområde

Problemområde

Klynger

Struktur

Klasser

Klassen 'Bruger'

Ansvar og formål

Attributter

Operationer

Adfærdsmønster

Klassen 'Enhed'

Ansvar og formål

Attributter

Operationer

Adfærdsmønster

Klassen 'Faktura'

Ansvar og formål

Attributter

Operationer

Adfærdsmønster

Klassen 'Garanti'

Ansvar og formål

Attributter

Operationer

Adfærdsmønster

Klassen 'Kategori'

Ansvar og formål

Attributter

Operationer

Adfærdsmønster

Klassen 'Kontakt'

Ansvar og formål

Attributter

Operationer

Adfærdsmønster

Klassen 'Kontaktperson'

Ansvar og formål

Attributter

Operationer

Adfærdsmønster

Klassen 'Leverandør'

Ansvar og formål

Attributter

Operationer

Adfærdsmønster

Klassen 'Model'

Ansvar og formål

Attributter

Operationer

Adfærdsmønster

Klassen 'Netværk'

Ansvar og formål

Attributter

Operationer

Adfærdsmønster

Klassen 'Placering'

Ansvar og formål

Attributter