1 - Forord

Fra starten har alle i gruppen vist stor interesse og entusiasme for dette projekt, og for os har det hele tiden været mere end 'blot' en eksamensopgave. Vi så muligheden for at lave et godt stykke arbejde, som rent faktisk, i en senere version, kunne bruges i den virkelige verden. Vi har således tilstræbt, at produktet også skulle være velegnet til fremtidig videreudvikling og standardisering. Det har derfor ikke være mangel på lyst eller interesse, der har været årsag til de komplikationer, vi trods alt har måtte tumle med undervejs. Vi har i vores projekt, selvfølgelig haft problemer af faglig karakter, men disse har aldrig været uoverskuelige eller sænket os væsentligt. De faglig relaterede problemer har med andre ord, ikke været flere eller større end man bør og kunne forvente ved et projekt af denne type. Dette skyldes især at vi internt i gruppen supplerer hinanden godt både som uformel-, men i høj grad også som formel gruppe.

Frugten af gruppens arbejde består i øvrigt dels af programmellet på vedlagte cd, dels af følgende dokumenter:

• Produktrapporten
  Denne indeholder alle de hårde facts som diagrammer, beskrivelser m.v. Det er tiltænkt at enhver anden udviklingsorganisation, med dette dokument i hånden, skal kunne fortsætte produktudviklingen der hvor vi slap. Produktrapporten er altså en manuel til-, og en fuldstændig beskrivelse af systemet. Dokumentet er opdelt i følgende hovedafsnit: Indledning, analyse, design og implementering.
• Procesrapporten
  Dette dokument indeholder de bløde informationer og er altså en beskrivelse og en dokumentation af selve den proces som vi har gennemløbet i projektperiodens 6 uger. Det er også i procesrapporten læseren vil finde informationer om projektetablering, metodevalg, tidsplaner m. m samt mødereferater.
• Appendiks
  Her findes en datadictionary, som beskriver specielle termer benyttet i rapporten.
• Bilag
  Her findes blandt andet dele af systemets sourcekode.
  

Delprodukter:
Udover de skolerelevante ting, har opgaven også resulteret i nogle delprodukter. Her kan nævnes det webforum, som vi har brugt til udarbejdelse af rapporten. Dette forum er udviklet i PHP, og opdaterer dynamisk rapporten, som vi uploader den til serveren.
Så har det også resulteret i oprettelsen af en webserver, der kan køre dette forum, samt serverapplikationen til systemet.
Endeligt er der alle de testklienter, som vi har udviklet til at teste dele af klientsofwaren, samt teste dele af serversoftwaren.

Et udviklingsprojekt af denne type kan ikke klart beskrives som en række af kontinuerlige arbejdsfaser. Arbejdet har derimod i høj grad indeholdt iterationsprocesser, men man kan groft karakterisere projektarbejdet som en bevægelse gennem følgende faser: Foranalyse -> Analyse -> Design -> Implementering. Vi har i rapportskrivningen søgt at overholde det tidsmæssige aspekt i produktudviklingen. Dette afspejles dels via rapportstrukturen, men også i sprogbrug og formuleringer. Det er dermed vores håb, at læseren således i højere grad, vil opleve det beskrevne projekt som den dynamiske størrelse det er.

Ophavsret
Ophavsretten omhandler beskyttelse af ens arbejde, dermed menes i princippet litterære såvel som kunstneriske værker, indenfor Danmarks grænser, i alle former og udgaver. I vores tilfælde drejer det sig om en distribueret kvalitetsstyringssystem med tilhørende DB. Det er ikke tilladt nogen at lave unødige kopier af programmet, hvilket vil sige at kun gruppen selv, Stig Jensen og sensor har kopier af programmet. Med programmet menes kilde koden såvel som alt andet materiale, som omhandler projektet. Endvidere har den eksaminerende part ingen ret til at videregive programmet til andre end de personer, som er direkte involverede i projektet. Såfremt læseren er en datamatiker-studerende eller af andre grunde kan ønsker at se bilagene, kan disse rekvireres ved direkte henvendelse til forfatterne. Projektgruppen har endvidere ret til at bestemme, hvilke dele af arbejdet som ikke skal være tilgængelige via biblioteket på Roskilde EDB-skole. De tre dokumenter (Produktrapport, Procesrapport og appendiks) er offentlig tilgængelige, og må benyttes til ikke-kommercielle formål, så længe dansk lov om ophavsret overholdes.
God læselyst.

- Drengene fra CoffeVille

2 - Indledning

Indledningen indeholder en række afsnit og beskrivelser som forhåbentligtvil skabe et overblik for læseren. Først vil afsnittet opdragsgiver indeholde en beskrivelse af den oprindelige opdragsgiver og projekt-ideens 'fødsel'. Efterfølgende findes en problemstilling, som indeholder en problem-identifikation, en løsning samt en diskussion af mulige alternative løsninger. Endelig vil indledningen indeholde et afsnit som beskriver systemets forventede forøgelse af Den logistiske effektivitet i en given basisorganisation, samt afsnittene: eventuelle udvidelser og notation.

2.1 - Opdragsgiver

Dette projekt er et inhouse-projekt, og har derfor ingen ekstern opdragsgiver, ikke destomindre bygger dele af projektideen på en ekstern organisation, nemlig Siemens Danmark. Gruppen arbejdede på 2. semester på en problemstilling, som delvist var stillet af Siemens. Siemens ønskede, at kunne lette og øge styringen af deres tilbudsgivningsproces. For at give læseren en forståelse af denne problemstilling, vil den her blive kort skitseret.

Lad os forestille os, at en kunde henvender sig til Siemens, for at få et tilbud på et givent projekt. Siemens går nu i gang med at udforme deres tilbud: Nogle medarbejdere sættes på opgaven, der bliver iværksat en problemanalyse, udelt arbejdsopgaver og ansvarsområder osv. Herefter begynder man at indsamle oplysninger, om alle de delelementer, der skal indgå i tilbuddet. Dette foregår, ved at benytte afsnit og/eller brudstykker af tekst fra tidligere tilbud. Først skal disse gamle tilbud dog lokaliseres, ofte ved at 'spørge sig for' hos kolleger og andre Siemens-afdelinger. Efterhånden har tilbuds-gruppen indsamlet en række informationer, som herefter skal redigeres og tilpasses. Anstrengelserne ender som et word-dokument, hvorpå almindelig layout-redigering udføres.

Den skitserede arbejdsmetode er meget tidskrævende, og kræver endvidere, at der omhyggeligt skal læses korrektur på det færdige tilbud. Siemens erfaringer viser, at tilbud som er udarbejdet på denne måde, ofte indeholder mange fejl. Hvis kunden i sidste ende underskriver en kontrakt med Siemens, vil denne kontrakt være bindende, og derfor vil Siemens være forpligtiget til at efterkomme tilbuddet. Tilbudet betragtes altså, som et juridisk bindende dokument og netop derfor skal fejlfrekvensen holdes på et absolut minimum. Derudover ønsker Siemens at frigøre nogle af de økonomiske og menneskelige ressourcer, som er bundet i en sådan, lidt gammeldags, tilbudsudarbejdelse. Opgaven havde altså som hovedformål, at udvikle et system, som kunne kvalitetssikre tilbuds-udarbejdelses-processen, samt bidrage til en forbedret logistisk effektivitet i samme forbindelse.

For at løse 'Siemens-problemet', udarbejdede gruppen en kvalitetsstyrings-model og producerede endvidere en prototype af et kvalitetsstyrings-system. Systemet byggede blandt andet på en database indeholdende rapporter og andre tilbuds-dele. Eksamensrapporten og en kopi af prototypen blev afleveret til Siemens Danmark. Da vi ikke vedligholdt kontakten til Siemens, er samarbejdet med dem sidenhen ophørt. Denne kvalitetsstyrings-model kan der læses om i afsnittet Kvalitetsstyring.

Som sagt, er nuværende projekt et inhouse-foretagende og bygger delvist på ideen fra 2.semester, dog anlægger vi nu et mere generelt syn således, at der ikke længere er tale om et tilbudsudarbejdelses-system, men et projektudarbejdelses-/dokumentstyringssystem, altså: Et generelt system til udarbejdelse og styring af alle slags dokumenter. Denne styring er således stadig underlagt de samme kvalitetsstyringsregler, der er gældende for tilbudsudarbejdelsen. Systemet garanterer dog ikke at reglerne bliver overholdt til punkt og prikke, da der kan være forskellige regler, fra virksomhed til virksomhed. Derfor må virksomheden selv udarbejde et sæt regler, der skal overholdes af medarbejdere. Systemet giver således mulighed for, at implementere disse regler i arbejdsgangen, så dokumenthåndteringen og projektudarbejdelsen kan i størst mulig grad kvalitetsstyres. I modsætning til 2.semester-opgaven, vil det system vi denne gang 'bygger', blive et flerburgersystem.

2.2 - Problemstilling

Vi ønsker altså et system, som lidt populært sagt er et elektronisk, net-baseret 'mødested/kontor', som skal kunne bruges af mindre virksomheder/projekt-grupper til at koordinere deres fælles arbejde. 'Mødestedet/kontoret' skal kunne deles op i 'rum', således at hver bruger vil få tildelt et sted: et home. Det skal endvidere være muligt at 'binde' flere brugere sammen i grupper, således at systemet direkte understøtter teamwork/gruppearbejde og giver mulighed for at en bruger kan arbejde på eksempelvis et kapitel i en gruppe-rapport, mens en anden bruger, som er tilknyttet samme gruppe, arbejder på et andet kapitel i samme rapport. Endvidere skal der fra brugerens home/startside være mulighed for at benytte sig af alle almindelige post-funktioner, at 'opbevare' private dokumenter/notaer osv., samt have adgang til de ressourcer som basisorganisationen stiller til rådighed (eks: Kunde-lister, adresser, database-opslag, tekster osv.). Det er endvidere et ønske, at systemet ikke skal diktere brugernes geografiske placering.

Set fra brugerens synspunkt, er systemet altså todelt: Det private område, gruppe området, som han deler med andre brugere i samme gruppe, og det globale område, som er det område, der er tilgængeligt for alle i virksomheden.
For basisorganisationens kunder, skal systemet levere web-baserede oplysninger om den givne kundes forhold, og giver kunden begrænset mulighed for at redigere i disse.

2.2.1 - Identifikation

Vi har altså brug for et system som er :

• Et flerbruger-system
• Fleksibel med hensyn til brugerens geografiske placering
• Et produkt der håndtere standardisering
• En databasestruktur der vejleder i genbrug af tidligere udfærdiget dokumentafsnit

Rigt billede der afspejler ide princippet bag Pro-filer

2.2.2 - Reklamesiden

Hvorfor er vores program er at foretrække

I det følgende afsnit vil vi meget kort forklare, hvorfor det er fordelagtigt for en virksomhed at erhverve vores produkt frem for så mange andre.
Pro-Filer er et fleksibelt og enkelt udformet produkt til brug i virksomhedens daglige arbejdsgang. Ved hjælp af en browser kan Pro-Filer benyttes til lige præcist de formål der er behov for i den givne virksomhed. Dette lyder vildt, men ikke desto mindre er det sandt. Det eneste som denne fleksibilitet afhænger af, er de HIC komponenter der er installeret serverside.

Eksempler på disse HIC elementer:

·Tekstbehandling

·Dokumentstyring

·Projektudarbejdelse

·Elektronisk postkasse

·Elektronisk opslagstavle

·Grafisk manipulation og integration

·m. f.

Pro-Filer understøtter kvalitetsstyring af dokumenter efter ISO 9002 standarden og kan benyttes på et Intranet såvel som over Internettet.

Pro-Filer er bygget op omkring datawarehousing og der foreligger derfor mulighed for at versionere sine dokumenter under projektarbejde, så der altid vil være styr på af hvem, hvad der er blevet ændret og hvornår et dokumenter er blevet opdateret og i givet fald om det enkelte brudstykke bør opdateres. Dette resulterer i at alle dokumenterne altid er ’up-to-date’.

Systemet understøtter vha. database-bruger strukturen mange forskellige e-mail-adresser tilknyttet en enkelt bruger. Ud fra dette kan virksomheden sende interne nyheder, kommentarer og beskeder mm. til enten e-mail eller til elektronisk opslagstavle for derved at formidle information effektivt.

Vi, Gruppe5 mener at den opmærksomme læser, af denne rapport, vil opfatte dette afsnit som ren gentagelse af tidligere nævnte eller kommende punktopstillinger. Derfor vil vi i stedet udskyde videre opsummering af vores produkt til den forestående eksamens situation, for der at komme med et oplæg om hvad vi kan, som de andre ikke kan.

2.2.3 - Løsning

Den valgte løsning, indeholder tre serverer: en databaseserver, en web-server og hvad vi har valgt at kalde en PServer. PServeren er det eneste komponent på server siden, som vi selv vil udvikle. Dette medfører endvidere, at vi i så høj grad som muligt, bestræber os på at lave svage koblinger mellem PServeren og de andre servere, således at basisorganisationen er friere stillet med hensyn til valg af soft- og hardware.

2.2.4 - Alternative løsninger

Vi har valgt nogle teknikker til vores system, en for hvert delområde: ASP til systemets web-del, applet til klientdelen, MySQL til databasedelen og Java til at udvikle serverdelen. Men der er selvfølgelig alternativer, som vi har haft med i vores overvejelser. I nedenstående tekst er disse valg og overvejelser dokumenteret.

2.2.4.1 - Web-delen

Formålet med web-delen er et forslag til, hvordan basisorganisationen kan udveksle informationer med deres kunder. Muligheden er, at en eventuel kunde, der har bestilt et projekt, kan logge ind via sin browser, og se hvordan arbejdet skrider frem. Desuden kunne man forestille sig, at kunden kunne ændre de oplysninger virksomheden har om 'ham', via web-delen. Desuden kan det være, at potentielle kunder skal have mulighed for at bestille yderligere information fra den pågældende virksomhed.
Web-delen er ikke så stor, men det har alligevel krævet en stillingtagen. Der er mange teknologier, der understøtter server side scripting her iblandt PHP, Perlescript, CGI, Python og JSP, men vi har valgt at benytte ASP da det er en del af pensum. Dette er altså et valg truffet på baggrund af den skoleorienterede, og ikke fordi det nødvendigvis er det mest effektive. ASPvalget er et "punkt" vi har "overvejet og debatteret". Egentlig mener gruppen, at PHP ville være et bedre valg, dels på grund af den overlegne performance (jævnfør benchmark tests - se www.chamas.com/bench m.fl.), og dels fordi vi støtter den frie ide. Selve tilgangen til applet er gennem HTML4.0 standard med JavaScript support.

Fordele ved ASP:
Det er en del af pensum, som vi så får lidt øvelse i. Det er rimeligt udbredt, og forholdsvist nemt.

Ulemper ved ASP:
Det er et Microsoft produkt.
Serveren, som skal fortolke ASP siden skal have indlæst en fortolker. Denne 'fortolker' koster i langt de fleste tilfælde penge - også til Unix. Vi kunne vælge en Windows platform til vores web-server, og så køre den gratis MS Personal Web Server, men så igen - MS Windows koster også penge. Hvis der skal opnås forbindelse til MySQL serveren over netværk, skal man via Windows DSN og have en MySQL ODBC driver til at virke. For at køre SQL scripts på MySQL serveren kræves en del åbning og lukning af forbindelser, og oprettelse af ASP kommandoscripts. Man kan muligvis godt få forbindelse over netværk til en MySQL database med ASP uden Windows ODBC, (Linux), men det har ikke været muligt at finde dokumentation på det. På grund af de mange ulemper har vi overvejet at skifte til PHP efter eksamen, da Apache (gratis) har installeret en PHP fortolker. Men på nuværende tidspunkt har vi valgt ASP, da det jo er en del af pensum, og det derfor er vigtigt at vise noget i ASP.

2.2.4.2 - Web-delen

Vi har valgt at basere klient-delen på applet teknologien, men et alternativ til at lave en applet kunne være en applikation, men så skulle man hver gang have den installeret. Det kan diskuteres hvorvidt fordelene vejer tungt for en applet. I gruppen mener vi dog, at en applet vil være mere brugervenlig, da den er nemmere at gå til via sin browser, så man ikke skal igennem installationsprocedure. I en fremtidig version af systemet vil man dog kunne forstille sig både en applikation til at køre på sin normale arbejdsstation og en applet til at køre via sin browser, når brugeren er ude at rejse. Vi kunne også have valgt udelukkende at lave det i HTML, men vi mener det vil blive for tungt og langsomt, da browseren hele tiden skal loade nye HTML sider ind, eventuelt med grafisk indhold. Desuden er der ikke så mange grafiske muligheder med HTML, og der mange funktioner, der er optimeret til at blive til i Java.

2.2.4.3 - Database-delen

Der findes en lang række databaser på markedet i dag, flere af dem er gratis at benytte. MySQL er freeware på Linux, samt sourcekoden er åben. Den opnår en meget hurtig 'benchmark' og yderst veldokumenteret.
Den understøtter ikke den ekstremt avancerede SQL kode så som 'views' ect, men dette er der heller ikke brug for i det nuværende system. Endeligt kunne disse mangler rettes vha. en 'ny' PServ-funktionalitet.

2.2.4.4 - Serverdelen

Vi har valgt at kode serverdelen i Java frem for så mange andre muligheder, da Java giver os den optimale mulighed for at flytte produktet fra en platform til en anden. Desuden giver det os muligheden for at dele serverkoden med appletkoden (som beskrevet i design afsnittet), og dette giver igen nogle fordele.

2.3 - Konkurrenter

Konkurrence virksomheder samt produkter:

For at undersøge hvor stor en chance vores produkt vil have på det nuværende marked, har vi været ude med følehornene og har fået følgende resultat tilbage:

Af alle de firmaer vi mente var i kategorien - konkurrent - fandt vi ud af, at der ikke var én eneste, der havde de samme funktioner i et produkt, som vi tilbyder i vores. Der var mange firmaer der delte de fleste af vores funktioner ud over flere produkter, hvor andre kun kunne tilbyde få af dem set fra et generelt synspunkt.

I nedenstående tabel har vi lavet et lille overblik over et par af disse virksomheder inkl. produkter de tilbyder som kommer tættest på vores. I info kolonnen kan man læse hvad produkterne tilnærmelsesvis har tilfældes med vores.

Ud fra denne generelle undersøgelse vi har lavet, kan vi komme til en foreløbig konklusion, at SAS er den eneste reelle konkurrent i forhold til vores programs grundlæggende funktionalitet. Inden vi på nogen måde kan være helt sikre på, at vi har en rimelig chance for at komme ind på markedet, skal der naturligvis laves en tilbundsgående markedsundersøgelse på professionel plan, hvilket vil indebære brugen af markedsøkonomer.

2.4 - Den logistiske effektivitet

Et af målene med det færdigudviklede system, er at øge den logistiske effektivitet ved projektudarbejdelse. Om det så er en tilbudsgivningsprocedure (som hos Siemens) eller anden rapportskrivning. Dette opnås ved en optimeret arbejdsgang og en optimeret benyttelse af de ressourcer, der er stillet til rådighed. Dette medfører en reduceret risiko for fejl, samt en reducering af tid og kræfter brugt på at fremskaffe de rigtige data. For at opnå dette, skal udarbejdelsen af projektet kvalitetsstyres, hvilket igen medfører, at kvaliteten af det færdige projekt i de fleste tilfælde vil være væsentligt forhøjet.

Kvalitetsstyring

Nedenstående afsnit vil indeholde kommentarer og kortfattede beskrivelser af, hvordan man effektivt vil kunne udnytte vort program med hensyn til de daglige arbejdsrutiner. Målet er at øge den logistiske effektivitet, og dette opnås ved et samarbejde mellem brugerne af programmet, men der kræves en god disciplin for opretholdelsen af den kvalitetsstyring, som vi her forudsætter.
Ikke nok med at kvalitetsstyring er det essentielle i ISO 9000 standarden; hvilket er én af grundene til, at vi bruger den i vort projekt; men der er også mange virksomheder der i forvejen er certificerede, og det vil være nemmere for dem at bibeholde den certificering, hvis vort program opretholder muligheden for, at gennemføre kvalitetsstyring med ISO standarden i tankerne. ISO standarden er desuden en meget udbredt standard indenfor det område programmet omhandler, og derfor er det naturligt, at det netop er denne standard vi har valgt til vort program. Vi kunne også have valgt ikke at bruge nogen standard, men af hensyn til udbredelsen af standarder generelt, har vi valgt at bruge en af de mere anerkendte. Vores program vil pga. af dette være mere tiltalende for virksomheder der ønsker eller har en eventuel ISO certificering, men også andre virksomheder, da overholdelsen som før nævnt er op til brugerne af systemet.

Idéen bag kvalitetsstyring generelt

Formålet med at kvalitetsstyre er, at give et produkt den samme kvalitet, hver eneste gang, det er produceret. I vores tilfælde, er det dokumenter, der skal have den samme kvalitet hver gang. Idéen er at alle aktiviteter, der har indflydelse på kvaliteten i virksomheden, skal koordineres gennem et tværorganisatorisk samarbejde, med mål at give en optimal og ensartet kvalitet inden for de givne økonomiske rammer. Indenfor dokument- og projektstyring er det også vigtigt, at der overholdes standarder for bestemte indholdsmæssige rammer, som sørger for at kvaliteten er ens.

Hvorfor kvalitetsstyring?

Kvalitetsstyring er en af de grundlæggende idéer bag datawarehouse teknikken, der igen indgår i idéen som grundlag for vores program. For at datawarehousing fungerer, er det alfa - omega, at der bliver opretholdt en bestemt kvalitetsstyring. For at forskellige virksomheder kan udnytte vores program optimalt, er der nogle aspekter omkring ISO - kvalitetsstyringsstandarden, som vi har sat os ind i, så vores program kan leve op til kravene. Dette afsnit vil beskrive hvad det er for nogle aspekter og hvordan vi bør forholde os i forhold til dem. Desuden vil der være en række beskrivelser af metoder, som man bør forholde sig til, hvis der skal være en mulighed for en respektabel og kvalificeret kvalitetsstyring.

Krav til kvalitetsstyringssystemet

Afsnit 4 i ISO 9002 standarden er det afsnit, hvor der er dele, der omhandler de ting, vi skal tage stilling til i udviklingen af programmet.

Kvalitetsstyringssystem (4.2)
Ved indførelsen af vort program bør der udarbejdes en kvalitetshåndbog, som vi har gjort os gode overvejelser om i det nedenstående. Det er imidlertid ikke en håndbog vi har muligheder for at udarbejde, det har vi simpelthen ikke beføjelser til, men vi kommer med forslag til hvad en sådan bog kunne indeholde i forhold til vort program. Desuden er det vigtigt at givne procedurer overholdes, det er dog i sidste ende op til selve brugeren af programmet, men vi har overvejet funktioner, der vil gøre det nemmere at overholde kravene for kvalitetsstyringen. Hvorvidt dette skal implementeres, er selvfølgelig op til virksomheden selv.

Kontraktgennemgang (4.3)
Det er jo vigtigt, at den enkelte virksomhed leverer den specifikation, som udbyderen beder om. Dette kan vi ikke garantere, men vi kan ved hjælp af standard skabeloner hjælpe til, at kravene til dokumentstyringen vil blive overholdt. Men meningen er, at vi indbygger en funktion i det færdige program, som understøtter muligheden for at oprette skabeloner, der er tilpasset de bestemte standarder, der benyttes. Der skal kunne oprettes en unik skabelon til det enkelte projekt, som den dertil ansvarlige kan bruge.

Dokumentstyring (4.4)
Dokumentstyring er den primære funktion i programmet. Det er vigtigt at de dele som et projekt bliver opbygget af, er tidssvarende og korrekte. Det er forfatterens ansvar, at et dokument er opdateret korrekt og jævnligt. Vort program kan indeholde en funktion der hjælper med dette. F.eks. ligger der i kildekoden mulighed for at lave en funktion, der automatisk gør forfatteren opmærksom på, at en beskrivelse skal opdateres, hvis det er længe siden det sidst er gjort. Men det er igen kun en mulighed. Dermed bliver forældede dokumenter opdateret hurtigst muligt eller rettere arkiveret i en ny database, så de aktive ikke længere indeholder forældede data. Selve databaserne i programmet giver mulighed for, at alle gyldige udgaver af relevante dokumenter er tilgængelige, når der skal laves et nyt projekt. Dette samtidigt med, at forældede dokumenter befinder sig i en langt større og langsommere database. Det er et væsentligt spørgsmål om hvorvidt ændringer i beskrivelser skal dokumenteres eller ej, men i henhold til datawarehouse teorien bør databasens indhold ikke overskrives. Derfor arkiveres forældede dokumenter og rettelser til disse, bliver til ud fra et kopi.

Indkøb (4.5)
Det er ikke muligt for programmet at kontrollere om produktbeskrivelserne passer til det indkøbte, men vi inkorporerer en leverandørliste, der gør det muligt at se, hvem der er leverandør til hvad. Om programmet også skal kunne udarbejde en historik omkring leverandører, må hvert enkelt virksomhed tage stilling til, men vi mener ikke, det er noget der i første omgang skal tages hensyn til. Der må i hvert enkelt tilfælde kontrolleres om produktet er i overensstemmelse med produktbeskrivelsen, og når dette er kontrolleret, er der ingen grund til at føre historik over dette. Vi kan ikke i vort program stille nogle krav til leverandøren af produktet, blot arkivere oplysninger om dem. Det er samtidig forfatteren af produktbeskrivelsens ansvar at de indkøbsdata, der måtte være, bliver opdateret så de er korrekte i samme stund, som projektet ændrer status til afgivet.

Produkter leveret af køber (4.6)
På dette punkt kan vort program ikke håndtere, hvorvidt kravene bliver opfyldt. Disse produkter kan som andre produkter selvfølgelig lægges ind under produktelementer, som de almindelige produkter.

Produktidentifikation og sporbarhed (4.7)
Produktidentifikationen er klar, idet alle produktbeskrivelser bliver gemt i databasen. Med hensyn til sporbarhed er spørgsmålet også, om det skal gemmes en database, over de ændringer der sker i produktbeskrivelserne, og dermed i produkterne. Det er jo stadig muligt at se det enkelte projekt i databasen, da disse jo bliver gemt i den ældre database, jævnfør datawarehousing princippet.

Processtyring (4.8)
De krav der stilles til en standardisering af processen omkring udviklingen af et projekt, skal efterleves ved hjælp af en kvalitetshåndbog sammen med en brugsvejledning til programmet. Kvalitetshåndbogen er den der skal definere ansvar, arbejdsinstruktioner og metoder, overvågning og kriterier for arbejdsudførelse. Det er den del af kvalitetsstyringen virksomhederne selv må tage hånd om. Vi har dog lavet forslag til noget af indholdet i en eventuel kvalitetshåndbog. En brugsvejledning vil ud over at beskrive brugen af selve programmet, også beskrive hvordan tildelingen af rettigheder og ansvar løber an. Vi kan ikke tildele medarbejderne pligter, men der er lagt op til det i programmet. Brugsvejledningen vil følge med i form af hjælpefiler.

Inspektion og prøvning (4.9)
Ikke behandlet i rapporten.

Inspektions-, måle- og prøvningsudstyr (4.10)
Ikke behandlet i rapporten.

Inspektions- og prøvningsstatus (4.11)
Ikke behandlet i rapporten.

Styring af afvigende produkter (4.12)
Programmet lægger netop op til at der ikke bliver udviklet nogle projekter der afviger fra de specificerede krav. Det er den person der lægger skabelonen til et projekt, der skal sørge for, at alle relevante punkter bliver berørt og indgår i skabelonen. Derfor bliver der heller ikke nogen korrigerende handlinger. Man kan måske sige, at den korrigerende handling er indførelsen af programmet.

Håndtering, opbevaring, emballering og levering (4.14)
Det vil være mulighed, at indtaste attributter som leveringsdato for projektet, så man er så godt som sikker på at denne bliver overholdt.

Registreringer vedr. kvalitet (4.15)
Ikke behandlet i rapporten.

Interne kvalitetsaudit (4.16)
Se ideoplæg til kvalitetshåndbogen.

Uddannelse og optræning (4.17)
Der skal i en fremtidig kvalitetshåndbogen også være retningslinier for hvordan nye medarbejdere sættes ind i de procedurer der bruges i forbindelse med programmet. De skal også sætte sig ind i brugsvejledningen. Det vil ikke kræve noget specifikt kursus at sætte sig ind i programmet, men det er vigtigere, at de nye medarbejdere bliver sat ordentligt ind i retningslinierne for udarbejdelsen af projekter og vedligeholdelse af beskrivelser. De fleste funktioner vil kunne give en alm. computerbruger en relativt kortere fremdragelses- og redigerings tid. De fleste ting i vort program vil give sig selv for en alm. computerbruger, der har læst brugsvejledningen. Efter nogen tids brug vil det være muligt for en nysgerrig bruger at opdage og udforske grænsefunktioner, samt genveje i programmet, og dermed skabe positive oplevelser.

Statistiske metoder (4.17)
Der vil være store muligheder for at lave statistik med databasen, men det er ikke noget element nogen af virksomhedernes kunder bør involveres i, og ikke en funktionalitet som vi på nuværende tidspunkt implementerer.

Det er vigtigt at huske på, at alle ovenstående punkter refererer til det færdige produkt og ikke prototypen.


Kvalitetshåndbog - hvad der kunne stå

Dette afsnit omhandler muligheden for den kvalitetshåndbog, der kunne følge med programmet. Man kunne også kalde det en vejledning, men den vil ikke omhandle en vejledning til selve programmet, men derimod en vejledning til de retningslinier og ansvarsområder, der skal overholdes for, at programmet vil have optimal funktionalitet. Vi vil ikke skrive denne håndbog, da vi ikke har indsigt nok i købende virksomheders procedurer, forretningsgange og organisation. Derimod vil vi give forslag til hvilke punkter en sådan bog som minimum skulle omhandle, og specificere punkternes betydning.

Organisationsstrukturen
Alt efter i hvor stor grad programmet skal anvendes, vil det være en nødvendighed at specificere organisationsstrukturen samt lederne for henholdsvis gruppen, afdelingen eller virksomheden. Dette er vigtigt fordi ansvarsområderne skal være tydeligt afmærket, for at undgå konflikter.

Ansvarsfordeling
Dette punkt henviser til hver medarbejder, der har sit eget arbejdsområde at stå til ansvar overfor. I vores programs tilfælde ville tekstelementer være tildelt den person som skriver dem. Dermed får personen den opgave at holde dokumentet "up to date". Man kan også bruge det eksempel at en person holder op med at arbejde for en virksomhed. I dette tilfælde skal ledelsen, fordele ansvaret får personens arbejde (dokumenter m.m.) ud på andre medarbejdere.

Procedurer
Det er vigtigt, at der bliver udarbejdet nogle bestemte procedurer til behandling af dokumenter, og derved den måde brugen af vort program sker på. Dette skal gøres for at overholde kvalitetsstyringsprincippet. Nedenstående er der beskrevet yderligere essentielle punkter, til kvalitetshåndbogen, der i hvert fald bør tages stilling til i købende virksomheder. Det er ting vi selvfølgelig har taget højde for i udviklingen af programmet.

Ansvarstildeling
Dette er det samme som ovenstående ansvarsfordeling, i den forstand at der skal være en ledelse der fordeler ansvaret (og dermed ment fysiske dokumenter) ud på arbejderne.

Opdatering
Det er den ansvarlige medarbejder der skal sørge for at de enkelte beskrivelser bliver rettidigt og korrekt opdateret. Projektet skal naturligvis ikke opdateres, men der er stadig en ansvarlig medarbejder, som skal kunne tilspørges om projektet. Det vil være optimalt, men ikke implementeret, hvis programmet holder styr på tidligere opdateringer, så man kan sammenholde ændringer med beskrivelser indeholdt i allerede udarbejdede projekter. Det vil være muligt at køre en funktion, der kontrollerer databasen for fejl, og ikke mindst tekstelementer, der har overskredet tipsintervallet for sin opdatering, og der derfor skal tages stilling til om de skal opdateres. Det bliver muligt at definere et antal dage, som skal være standard for, hvor gammel en beskrivelse må være i forhold til sidste opdatering, før det er krævet at indhold eller tipsintervallet bliver opdateret.

Sletning
Det er muligt at slette et projekt eller tekstelement (flytte til ældredatabasen), men kun for den ansvarlige. Det er svært at definere formålet med at slette (fra aktiv database), men det skal dog være en mulighed. Hvis projekter eller tekstelementer slettes, skal der jo gøres opmærksom på, at der så ikke kan udregnes statistik på dem. Det er naturligvis muligt, at en beskrivelse aldrig har været i brug, og den derfor ikke har relevans. Det skal ikke være muligt at slette et tekstelement, hvis der er et projekt, så derfor bliver sletning af dokumenter en kompleks funktion der faktisk kræver at hele databasen bliver gennemsøgt.

2.5 - Eventuelle udvidelser

Beskrivelser og ideer omtalte i det nedenstående afsnit er ikke noget vi får implementeret i systemet, men er noget man bør overveje, at tilbyde en eventuel køber af systemet. Man kunne også undersøge, om det var noget, der skulle implementeres i fremtidige versioner. Specielt omkring sikkerhed, er der en del overvejelser man bør gøre, da det jo i mange tilfælde vil være meget vigtige dokumenter, der skal overføres via nettet.

2.5.1 - Sikkerhed

Java blev udviklet af Sun Microsystems med henblik på at tillade Java, at blive indlejret i hjemmesider fortolket en browser. Dette er baseret på en virtuel machine, der emulerer alle implementationer, hvor browseren understøtter en passende version af JVM.
Java er et meget robust sprog i modsætningen til mange andre programmeringssprog. I forhold til eksempelvis C har Java hverken globale variable, globale funktioner eller præprocessor-kommandoer. Samtidigt er Java designet til at være et mere sikkert sprog at udvikle i, da det ikke indeholder nogle muligheder for at generere refferance-pointere ud af 'sig selv', dvs. at det ikke er muligt at skade det omgivne miljø, samt check på hvert enkelt objekts integritet.
Men hvordan er sikkerheder i Sun's digitale kaffe? Kan man stole på Java Virtuel Machine?
Hvis man skal lytte til Process Software (IPv6-drengene på www.process.com), er mangler; Java's sikkerhedsmodel. For at fremhæve et enkelt, men grundigt dokumenteret, aspect i Javaarkitekturen, er at sikkerheden nødvendigvis må implementeres i java's applets wrapper, dvs. sikkerhed afhænger af den givne JVM.

I et fremtidigt system bør man opsætte en firewall, der kan afskærme øvrige porte effektivt. Til dette er der tre mulige løsnings modeller:

• Indkøbe en firewall til servern
• Hvis serveren er et Linux OS kan en rekompileret kernel afskærme porte i sig selv
• En løsningsmodel der benytter begge ovenstående punkter

Man kunne endvidere overveje at indkoorporere Novo's sikkerhedsmodel baseret på SecureCard ideen. Udvalgte medarbejdere får udleveret et SecureCard og en personlig kode til dette kort samt et brugerID. Den personlige kode indtastes på kortet inden brug af systemet og vil over satellit få tilsendt en 10 karekter's kode, som samtidigt er blevet registreret i systemet på et ace-software(se datadictionary). Herefter kan man med succes logge ind med brugerID og den dynamiske tildelte kode.
Et sådan løsning kunne ligge serverside, hos os, da der ville være en økonomisk besparelse at gøre ved masse-indkøb af disse kort. Derudover vil denne løsning er kun kræve en licens, til at kunne benytte ace-servern(se datadictionary) uanset hvor mange kort denne servicerer. Den server software vi taler om koster mellem 2-17000 dkkr, afhængigt af hvilken type licensaftale man laver. Det fysiske SecureCard koster ved indkøb af over 3000 enheder 650 dkkr pr. stk.

Der forefindes dokumentation til denne alternative samt fremtidige ide' på www.rsa.com.

Desuden er det værd at overveje, om man vil benytte kryptering og i så tilfælde hvilken man skal bruge, og om det skal være noget der er direkte implementeret i kernelen, eller det skal være 'add-on'. Som det er nu, skal der ændres en klasse i kernelen, hvis kryptering tilbydes. Det ville dog være værd at overveje, om man senere skal kunne skrive et plugin, der tilbyder den sikkerhed, som man i en virksomhed mener er passende til tidspunkt, økonomi og sikkerhedskrav.

2.5.2 - CBI

Business intelligence (BI)
Hvad er BI? Resultater fra analyser og statistikker af alle mulige slags bliver brugt i mange sammenhænge. BI er en filosofi, der bruger disse resultater målrettet i beslutningsprocessen. BI gennemgår i øjeblikket en udviklingsfase fra almindelig understøttelse for statistikere og analytikere, til en netværksbaseret infrastruktur for virksomhedsrapportering, der skal nå tusindvis af beslutningstagere. Derfor ser man flere netbaserede værktøjer til BI, der gør det nemmere at få adgang til resultaterne fra data-analyserne. Men for virkeligt at BI skal have en virkning, skal man have folk til at reagere på den information, de har adgang til. Således, at de tager bedre beslutninger, forbedrer processer og griber flere muligheder. Ved at blande BI og KM opnår man endnu højere effektivitet på dette beslutningsområde.

Knowledge management (KM)
Begrebet Knowledge Management florerer hidsigt i forretningslivet i øjeblikket. Princippet bag KM, eller vidensstyring, er at lade IT-systemer tage hånd om de problemer der er knyttet til store mængder viden spredt over mange dokumenter. Forskellen på KM og BI er, at hvor BI er beslutninger baserede på resultater fra analyser m.m. (strukturerede data), er KM mere videndatabaser baseret på almindelig tekst i uendelige variationer (ustruktureret information). Princippet går så ud på at give brugerne adgang til de nødvendige informationer, opstille en ramme for selve viden-formidlingen, samt at undgå at brugerne bliver bombarderet med ubrugelig information.

Collaborative Business Intelligence (CBI)
Værktøjerne til KM markedet er en væsentlig udvidelse af det traditionelle BI marked. Og ved at tilføje brugere af BI direkte til udviklingen af- og samarbejdet om KM, kombinerer man de to ting. CBI er så kombinationen af BI (strukturerede data) og KM (ustruktureret information) samlet i et datawarehouse. Denne sidste filosofi for arkiveringen af data kombineret med BI og KM (CBI), giver et miljø, hvor analytisk information, fra et datawarehouse eller OLAP værktøj, bliver brugt af analytikere samt beslutningstagere. Desuden stiller CBI et netværksbaseret bibliotek til rådighed, hvor der er mulighed for at fremlægge rapporter fra diverse kilder, samt at sted til at arbejde på de igangværende projektrapporteringer. Denne understøttelse af dynamiske rapporter, giver læserne mulighed for "live" data og alternative scenarier. Informationen vil så blive tilgængelige via et online-abonnement til dem, der skal bruge dem.

Målet med vores produkt er, at kombinere CBI med en kvalitetsstyringsmodel, der følger ISO9002 standarden, hvor det eneste brugerne skal have adgang til, er en internetbrowser, der understøtter det i teknisk platform afsnittet definerede.

2.6 - Notation

Vi skal også skrive om hvordan vi bruger begreberne:

Tabeller og lister

Brugen af tabeller og lister falder tilbage på, at det er nemt og overskueligt for enhver person at overskue. Tabellerne er ikke en del af UML. Tabellerne som benyttes i rapporten angives i nedenstående figur:

Diagrammer

Da diagrammerne er velegnede til at give overblik over en bestemt slags elementer i en afgrænset del af en beskrivelse, har vi valgt at benytte dem de steder, som er beskrevet i det nedenstående. En del af diagrammerne nedstammer direkte fra UML. Præsentationen afspejler det, vi opfatter som et minimalt udvalg af relevante elementer.
De fleste diagrammer kan påføres yderligere elementer. Vi valgte dog ikke at gøre dette, da det bare ville gøre diagrammerne svære at forstå og for uoverskuelige for os selv.

3 - Analyse

Analysedelen indeholder en analyse af opgaven, problemområdet og anvendelsesområdet. Derved kan vi afgrænse og beskrive systemet. Vi skal beskrive virkeligheden, som de kommende brugere skal se den. Resultatet skulle gerne give et overblik over systemmodellen.

3.1 - Opgaven

Afsnittet skal indeholde en beskrivelse af, hvad systemet går ud på. Vi skal give et overblik over den opgave, som vi giver os i kast med.

3.1.1 - Omgivelser

Problemområdet: Edb-systemet skal kunne registrere dokument-specifikke data for dermed at opbygge en dokumentstruktur der passer til de valgte standarder. Tilgangen til dette skal være en dynamisk baggrund, hvor dokumentforfatternes manipulation er wysiwyg. Edb-systemet vil kunne benytte data, der er tilknyttet den aktuelle kunde, dokumenttypen, dokumentforfatteren, tekstelementets emne og kategori samt diverse søgeord. Dette både til at søge efter og automatisk importerer i standard punktopstillinger ved genbrugs-funktionalitet.

Anvendelsesområdet Datamatisk dokumentmanipulation skal indgå på linje med andre grafiske instrumenter til manipulation af dokument tekst- og brudstykker. Når et projekt tilkobles en dokumentstruktur, indsættes de ønskede dokumenter, tekst- og brudstykker automatisk. Dette kan løbende justeres af brugeren, hvis en standard eller lignende ønskes ændret. Hvis en standard ændres sker dette 'rekursivt' i alle dokumenter, ved hjælp af xml-dtd struktur(for det fremtidige system).

3.1.2 - Systemdefinition

For at komme frem til en systemdefinition, der skal etablere et relevanskriterium for den objektorienterede analyse, må vi skabe et overblik over situationen med udgangspunkt i brugerens situation. Med udgangspunkt i BATOFF kriterierne er vi kommet frem til følgende systemdefinition:

Betingelser
Som udgangspunkt har vi kvalitetsstyringsmetoden, der fremleder det projektudarbejdelsessystem specificeret i indledningen. Men da vores samarbejde med Siemens Danmark er ophørt har vi ikke nogle specifikke krav til den videre udvikling. Derfor må vi benytte os af vore egne ideér til det fremtidige system.
I systemets første levetid vil det være naturligt at integrere ændringer på baggrund af en betatest, dog vil der blive taget hensyn til, at systemet ikke udvikles til en bestemt virksomhed, men er mere som et generelt program, der skal kunne passe ind hos flere virksomheder.

Anvendelsesområde
Anvendelsen er tiltænkt større virksomheder med behov for kvalitetsstyring af deres projektudvikling m.m., eller vedligeholdelse af dokumenter og andre essentielle data i en informationsdatabase. For eksempel kan det med fordel nævnes tilbudsudviklingen hos Siemens Danmark. For at datawarehouse teknikken kan opretholdes, skal vedligeholdelsen af dataene overholde bestemte krav om kvalitetsstyring. Systemet skal kunne anvendes af alle ansatte i virksomheden med forskellige rettigheder.

Teknologi
Læs venligst afsnittet Teknisk platform

Objektsystem
Styringen af projektudviklingen med mailboks, offentlige samt private foldere.

Funktionalitet
Mulighed for kvalitetsstyret vedligeholdelse af en dokument database, mailboks funktionalitet til både intern og ekstern kommunikation, samt at gemme private informationer på tværs af organisationen.

Filosofi
Et administrativt kvalitetsstyret informationssystem, kommunikationsværktøj og grafisk arbejdsplatform (Shell).

Disse forhold kan samles i følgende systemdefinition:

3.2 - Problemområdet

Virksomhederne bør ændre deres arbejdsgange. Især større virksomheder drukner i viden og dokumenter, og mister derfor overblikket.
Det væsentligste problem er, at informationer ikke bliver delt med resten af organisationen, og at beslutninger ikke nødvendigvis bliver truffet på et faktuelt grundlag, det er netop dette administrative problem, vi søger at gribe fat i.
Vi, gruppe5, oplevede hos Siemens Danmark, at alle dokumenter der blev forfattet blev sendt til en kunde, og arkiveret for med stor sandsynlighed aldrig at blive fundet, på et tidspunkt hvor man skal bruge det igen. Dette samtidigt med at der ikke blev overhold nogle dokument formaterings standarder. Kort sagt er vores mål at løse virksomheders problemer med udvikling og samling af dokumenter, som overholder firmastandarden i et administrativt system, der har fokus på den distribuerede ide.

3.2.1 - Klasser

Her beskriver vi klasserne i systemet ud fra brugerens synspunkt. Nedenstående definitioner er for klasserne som danner grundlaget for databasedesignet.

Definition

3.2.1.1 - Hændelsestabel

Hændelserne for klasserne findes ved at brainstorme over opførsel i forhold til hinanden. Herved danner vi os et billede af det fremtidige system.
Vi kan nu tage udgangpunkt i hændelsestabellen, når vi skal lave funktionslisten, som vi kan delvist implementere ud fra.
Vi bruger to betegnelser til notationen i hændelsestabellen :

* = klassen er fuldt involveret i hændelsen. (*) = klassen er delvist involveret i hændelsen.

3.2.2 - Struktur

Efter en beskrivelse af de enkelte klasser hver for sig, vil vi sætte dem i relation til hinanden. Dette gør vi i nedenstående klassediagram. Hertil hører også en forklaring til, hvordan de hænger sammen, og dette ses i følgende skema:

3.2.2.1 - Klassediagram

3.2.3 - Hændelser

Vi har valgt kun at vise tilstanddiagrammer for de klasser, der behøver en visuel forklaring til deres opførsel. Elementerne Produktafsnit og Elementer har samme adfærd.

Projekt
Et projekt oprettes, og kommer så i tilstanden "under udarbejdelse". Her bliver det så, indtil det bliver afsendt til en kunde. Så længe kunden ikke har svaret tilbage, om det er godt nok, forbliver det i tilstanden "afventer svar". Et projekt kan blive annulleret så længe det er disse to tilstande. Når det bliver annulleret kommer det i en sluttilstand, hvor det bliver gemt i databasen. Det samme sker, når kunden har svaret.

Produkt- Grafik- og Tekst-elementer
Ved oprettelsen af et element af ovenstående klasser, kommer det i tilstanden aktivt, og dermed er det tilgængeligt for alle. (Husk, der er én ansvarlig bruger). Hvis et element overskrider sin forældelsesfrist kommer det i tilstanden uddateret, og skal så opdateres for at komme i aktiv tilstand igen. Når et element bliver opdateret (altså bliver ændret i), skal der ifølge vores kvalitetsstyrings/datawarehouse filosofi tages en kopi, som gemmes i databasen. Hvis man finder ud af, at et element ikke skal bruges mere nogensinde, og derfor heller ikke skal opdateres, kan man give det statusen "Ugyldiggjort". Så kan det ikke mere bruges, men ligger dog stadig i databasen, som det skal ifølge filosofien. Det er i virkeligheden også det der sker, når der oprettes en kopi. Det "gamle" element bliver ugyldiggjort, og så er det kopien man arbejder videre på. Derudover skal det være muligt at tildele en ny ansvarlig til elementet, da det jo kan være, at en bruger bliver pensioneret eller skifter ansvarsområde.

Bruger
Når en ny bruger er oprettet, kan han få ændret den status, han har via sine brugerrettigheder. Der kan være mange forskellige rettigheder, det gør ikke, at brugeren kommer i nogen ny tilstand. Så kan han forlade virksomheden. Vi har kaldt det "pensioneret".

Postfiler
Hver bruger har sin egen postkonto, hvor han kan sende og modtage filer. En postfil kan være ny eller læst. Brugeren kan til enhver tid slette sine postfiler. Hvis en bruger bliver "pensioneret", bliver alle filer slettet.

Filarkiv
Filer i et filarkiv kan have tilstanden public, gruppe eller privat. Derudover kan de komme i en sluttilstand hvis de skal slettes. Filerne i filarkivet er heller ikke med i datawarehouset, da disse også kan være private.

3.3 - Anvendelsesområdet

Formålet med afsnittet om anvendelsesområdet er at fastlægge systemets brugsegenskaber. Resultatet skulle gerne udmunde i en kravspecifikation og en afgrænsning udledt deraf. Vi skal beskrive brugen af systemet, og give et overblik over det med en model, som vi så kan arbejde ud fra. Så skal kravene til systemet specificeres. At finde kravene til et system kræver noget eksperimentering, så dette er en iterativ proces, der også har indflydelse på resten af rapporten, ikke mindst afgrænsningen.

3.3.1 - Brug

Vi vil her fastlægge brugen af systemet. I afsnittet identifikation og løsning, har vi overordnet beskrevet, hvad det er for et system, vi forsøger at nå frem til. Her skal vi så beskrive hvordan man bruger det. Først en overordnet beskrivelse via et eksempel:
I basisorganisationen skal laves et projekt. Der nedsættes en projektgruppe, som udfærdiger en rapport. Til dette kan de bruge vort system. For at få noget ud af det, skal de overholde de krav, som basisorganisationen har beskrevet i kvalitetshåndbogen for systemet. Hvis disse krav overholdes vil projekterne blive af samme standard, som beskrevet i kvalitetsstyringsafsnittet. Ligeledes er der mulighed for oprettelse af skabeloner til de dokumenter og de færdige projekter. Ved at oprette en skabelon for strukturen af et projekt, kan sikres, at bestemte standarder bliver overholdt.
Når projektgruppen skal bruge elementer til rapporten kigger de i databasen i vort system. Elementerne overholder alle en bestemt formatering, hvilket garanterer ensartethed i den udfærdigede rapport. Hvert element er udfærdiget af en forfattet, som har ansvaret for det enkelte element. Hvis forfatteren "pensioneres" tildeles en anden forfatter. Der er således altid en ansvarlig for elementet. Dette garanterer, at det altid er muligt at finde frem til en person, der ved noget om det pågældende element. Elementet skal ligeledes have tildelt en dato, hvor den ansvarlige senest skal kigge på elementet igen for at kontrollere, om det stadig er "up to date". Dette garanterer maksimal mulighed for, at elementerne altid er opdaterede. Hvis et medlem af projektgruppen skal bruge et element hvor opdateringsdatoen er overskreden, skal han informeres herom. Han kan så tage sine forholdsregler. Når et element bliver opdateret, bliver det gamle gemt ifølge afsnittet om datawarehousing. Således kan man altid finde de rette elementer, der er blevet brugt i tidligere projekter, eller se hvordan et element har set ud tidligere. Elementerne er opdelt i kategorier og har tildelt søgemuligheder, så et projektgruppemedlem har stor chance for at finde det rette element, og endda få flere alternativer, hvis de findes. På denne måde bliver det altid den person, der har de bedste muligheder for at forfatte elementet, der rent faktisk gør det. Ekspertise kan også hentes udefra, da elementerne så bare kan lægges i databasen. Der skal dog tildeles en ansvarlig bruger. For at minimere fejl og overholde ISO 9002 standarden skal hver forfattet element godkendes. Ligeledes, hvis det bliver opdateret. Således minimeres også fejlfrekvensen.
Der er jo er flere medlemmer i en projektgruppe, og måske mange projektgrupper i en basisorganisation, samt de medlemmer i basisorganisationen, der skal vedligeholde elementerne i databasen. Derfor skal systemet være et flerbrugersystem. Dette er dog ikke nok for os. Det er vigtigt, at systemet giver så stor frihed, som muligt indenfor givne kvalitetsstyrings- og sikkerhedsrammer. Derfor skal det være muligt at bruge systemet, hvor som helst i verden. Således kan et projektmedlem sidde i Danmark og skulle bruge et element, som ikke er opdateret. Den ansvarlige for dokumentet kan befinde sig i Indien eller et andet sted i verden, have adgang til nettet via en browser, der har JMV indbygget. Så kan han starte client appletten, og sørge for, at sin kollega i Danmark kan fortsætte sit arbejde med et opdateret element.
Hvis virksomheden er multinational, giver denne mulighed ekstra fordele, da det nu er muligt at arbejde på samme projekt og kvalitetsstyre dokumentationen over landegrænser, uden at skulle sidde og e-mail til hinanden, eller anden ikke styret kommunikation.
Kort sagt skal systemet bruges til at kvalitetsstyre dokumenthåndteringen i projektudarbejdelse. For at servicere den kunde, som man laver projektet for, skal man have mulighed for at lægge dele af sin rapport online, eller anden dokumentation, der ligger i databasen, og som omhandler det projekt kunden har bestilt. Der skal selvfølgelig være sikkerhed omkring dette, da det jo er vigtige dokumenter.

3.3.1.1 - Oversigt

En kort oversigt over systemets hoveddele gives således:
Et client/server system, der skal fungere over Internettet.
Hjælp til overholdelse af ISO 9002 standarden.
Kvalitetsstyring af dokumenthåndteringen.
Optimeret og kvalitetsstyret projektsamarbejde.
Under disse ting er følgende overordnede funktioner:
Dokumenthåndtering.
Administrationsmuligheder.
Databasehåndtering (måske under administration).
Projektkommunikation (mail).
Virksomhedsspecifikke funktioner.

3.3.1.2 - Aktører

Her skal det nævnes at vi tidligere har benyttet ordet standard som en reference til tekstdokument formateringen. Dette er ikke hensigten under aktører og brugsmønsterspecifikation, her er det nemlig en projektskabelon struktur vi søger at beskrive.

Aktørspecifikation for Forfatter:
Formål: Forfatters basale behov er at oprette elementdele til brug i et til flere projekter. Endvidere kan der også ændres i fundne oplysninger fra databasen, men kun hvis personen har rettigheder til dette. Dvs. at forfatteren selv har udfærdiget elementet eller han har rettigheder via. et aktivt projekt. En forfatter skal internt i et projekt, i denne kontekst, også opfattes som pseudo forfatter.

Karakteristik: Systemets brugere er, via attributter, meget forskellige. Forfatter til element eller tilknyttet ved pensionering af tidligere forfatter har vedligeholdelses pligt til den del af databasens indhold, som han alene er den ansvarshavende til.

Aktørspecifikation for Godkender:
Formål: Formålet med Godkender er i bund og grund at godkende alle elementer som de forskellige forfattere fremstiller. Typisk vil det være en gruppeleder der får tildelt dette ansvar.

Karakteristik: Godkender er en bruger, som har bemyndigelse til at godkende elementer.

3.3.1.3 - Brugsmønstre

Alle objekter, på nær standard, indgår i vores klassediagram. Standard vil i det fremtidige produkt indgå i funktionstabellen.
Som tidligere defineret menes der følgende med Elementer: tekst-, produkt-, og grafik-brudstykker.

Brugsmønsterspecifikation for udarbejdelse af projekt:
Mønster: Brugeren skal starte med at vælge en opstillet standard, samt vælge hvilken type målgruppe produktet er rettet imod. Her skal samtidigt tilknyttes en kunde. Herefter tilknyttes de givne projekt deltagere samt give dem ansvarsområder. En standard bør nu defineres, enten ved valg af allerede eksisterende eller opbygning af en ny, ellers vil Pro-Filer default blive benyttet. Dette vil blive uddybet i afsnittet for udarbejdelse af skabelon.
Når Pro-Filer så har importeret de tidligere definerede brudstykker, kan man søge og tilknytte nye elementer til produktet. Nu kan brugeren tilføje, redigere, slette eller omrokere punktopsamlingen. I øvrigt er det muligt for brugeren at oprette nye elementer undervejs i produkt udviklings processen, såfremt han/hun ikke ønsker at benytte sig af allerede udfærdiget elementer i databasen.

Objekter: Elementer, Standard, Kunde, Bruger, Omkostning, Leverandør.

Brugsmønsterspecifikation for Udarbejdelse af standard:
Mønster: For at oprette en ny standard er samme ide som at udvikle et helt nyt projekt, men man starter bare fra punkt nul. Pro-Filer vil ikke importere nogle filer til projektet, da bruger selv skal vælge de tekst- og grafik-brudstykker der skal indgå i rapport træet (indholdsfortegnelse).Herefter skal der indtastes søgeord til standarden for at kunne finde den blandt mange andre på et senere tidspunkt.

Objekter: Elementer

Brugsmønsterspecifikation for søgning i databasen:
Mønster: For at kunne søge effektivt i arkivet, bør virksomheden internt blive enige om en formatering af søgeord eller sætninger der kan definere tekst- og grafik-brudstykker samt hele projekter og standarder. Desuden kan man søge på titler, forfatter, datoer, kunde eller leverandør.

Objekter: Projekt, Standard, Elementer, Bruger, Kunde, Omkostning, Leverandør.

3.3.2 - Funktioner

Ud fra ovenstående har vi udarbejdet en generel funktionsliste. Udarbejdelsen af funktioner er en iterativ proces, hvilket vi rigtigt får at føle, når systemet skal igennem en betatest hos nogle brugere. Desuden skal det være muligt, at man i vort system skal kunne tilpasse funktionerne fra virksomhed til virksomhed. Derfor er nedenstående funktionsliste med henblik på et generelt system.

3.3.2.1 - Komplet funktionsliste

Generelle

Projekt

Elementer

tekstafsnit, grafik ect.

Projektgruppe

Brugere

Kunde/Leverandør

*Administrator er taget med i funktionstabellen, da han skal valideres af PServer for at kunne lave strukturelle ændringer der påvirker vores system.
Han er samtidigt den der håndterer serveradministration, og har root password på den maskine der trækker PServ.
Denne maskine "serveren" er også platformuafhængig, men skal kunne trække de forskellige miljøer tidligere defineret.

3.3.2.2 - Specifikation af funktioner

Vi tilknytter til editorens brugergrænseflade de almindelige funktionaliteter, man kender fra diverse tekstbehandlingssystemer. Disse funktionaliteter er ikke alle implementeret til fulde i denne version af Pro-Filer. Vi vil prøve at få diverse services integreret i systemet som det generelle system, vi ønsker at udvikle, består af. Der er mange funktionaliteter der ikke er medtaget i den komplette funktionsliste, da vi mener de er underforståede såsom skriv, slet og flyt besked. Disse, samt visse andre funktionaliteter, vil blive håndteret af systemet, eksempelvis: . En funktionalitet ikke dokumenteret i denne rapport er , da denne funktionalitet ikke er designspecifik, men derimod er retningsbestemt af implementationen. Under specifikation af brugergrænsefladen vil vi komme nærmere ind på den mere trivielle del af produktet.

3.3.3 - Brugergrænsefladen

Dette er en diffus størrelse. Dette skyldes at systemets opbygning lægger op til virksomheds specifikke grænseflader jvf. afsnit om plugin.

3.4 - Anbefalinger

Efter at have analyseret en løsning til systemet, er vi kommet frem til følgende anbefalinger:

3.4.1 - Strategi

Vi skal kigge på strategien fra to sider. Vi skal på den ene side være færdige med en rapport og en prototype, som vi kan aflevere den 18. maj klokken 12. På den anden side skal vi mere langsigtet have udviklet et fuldt virkende system, og derfor er det vigtigt, at vi ikke laver for mange "hovsa" løsninger og "spaghetti" kode. Altså har vi to opgaver at løse. Dette betyder, at vi arbejder med en dokumentation i rapporten, der måske ikke passer, når systemet er færdig udviklet. Det kan være antagelser vi har gjort, i den tro, at systemet vil blive sådan om 5 måneder. Det er ikke sikkert, at disse antagelser kommer til at passe. Dette medfører en stor risiko for inkonsistens i rapporten, hvis vi f.eks. har antaget noget i starten af de 5 uger vi har til projektet, og det måske har ændret sig senere. Vi må derfor være ekstra opmærksomme på inkonsistens i rapporten.
Af dette kan vi udlede to strategier, som skal overholdes på samme tid:
18. maj strategi:
Vi skal have udarbejdet en analyse af systemet, og designet må ikke afvige drastisk fra analyseresultatet. Den iterative proces, analysen gennemløber, skal afsluttes så snart, der er kortlagt forudsætninger, behov og adfærd for systemet samt en foreløbig afgrænsning af systemet, og er fastlagt overordnede brugsegenskaber. Dette giver et meget fleksibelt resultat.
Designet er også en iterativ proces, der selv efter 18. maj vil blive gennemløbet . Derfor må denne strategi gå ud på, at nå en grundlæggende forståelse og en fleksibel struktur for systemet. Denne grundlæggende struktur, der opnås skal være så gennemtænkt, at den kan holde, selvom vi senere vælger at udvide funktionaliteten i systemet. Derudover skal dokumenteres de yderligere elementer, der måtte være færdigudviklede i systemet. Til sidst skal så beskrives vores intentioner for udseendet af det endelige system. Dette kan dog kun gøres overordnet, da langtfra alt vil være implementeret. Der vil opstå situationer, hvor vi bliver nødt til at lave løsninger, der helt sikkert vil blive ændret efter 18. maj, men for at få en virkende prototype til tiden, må implementeres. Resultatet af denne strategi skulle så give en fyldestgørende rapport og en prototype, der virker.
5 millioner strategien:
For at udvikle et system, der skal have en chance, når det bliver markedsført, må man tænke sig grundigt om. Dette kræver meget tid, mange overvejelser og en kode, der bærer præg af en langsigtet strategi. Dette modarbejder 18. maj strategien. Men kun delvist, da vi den 18. maj jo kodemæssigt "kun" skal fremvise en prototype. Til gengæld skal rapporten være så færdig, som muligt. Men det bliver jo så kun prototypen, der kan dokumenteres fuldt ud i rapporten. For at kunne vise en prototype, der virker, må vi sørge for, at kernen i systemet virker. Men for ikke senere at skulle lave hele kernen om, skal den kodes ordentligt, og det må derfor være dér hovedvægten af ressourcerne bliver lagt. Når denne virker stabilt, vil det være nemmere at skrive funktioner og have en mulighed for at afprøve dem. Med denne strategi bør analysedelen af rapporten være færdig hurtigt, så designet kan komme i gang. Designdelen bør så skrives iterativt. Som hovedregel skal designet dokumenteres, så snart det er sikkert fastlagt. Dette vil komme til at skride ud over 18. maj, så vi bliver nødt til at kombinere de to strategier på følgende måde:
Analysen skal være færdig hurtigt, så designet kan komme rigtigt i gang. Den iterative designdel skal derefter dokumenteres, så snart designet er sikkert fastlagt, men i slutningen af projektperioden, må selv design, som ikke er helt sikkert fastlagt, blive dokumenteret så vi kan nå vores deadline 18. maj.

3.4.2 - Udviklingsøkonomi

Siden idéen til systemet blev lagt på bordet, er der brugt rigtigt mange timer på udviklingen. En del af disse timer skyldes dog tilpasningen til et skoleprojekt. Men nøjes vi med at tage den tid med, som vi har brugt i direkte forbindelse med udviklingen af det endelige system, antager vi, at vi den 18. maj har brugt ca. 20 mandeuger på systemet Hvis vi går ud fra, at vores evner stiger proportionalt med den tid vi bruger på at kode, vil vi regne med minimum yderligere 120 mandeuger for at udvikle en beta version. Denne skal så igennem en betatest, og efter mange tilrettelser, kan man udgive en version 1 af systemet.

3.4.3 - Edb-systemets nytte og realiserbarhed

For at implementere hele kvalitetsstyringssystemet i virksomheden, skal virksomheden regne med en indkøringsperiode, hvor mange medarbejdere skal på et kort kursus. Desuden skal der skrives en kvalitetshåndbog, og måske en vejledning med procedurer, der er specifikke for den enkelte virksomhed. Administratorer af databasen skal på specielle kurser, så de ved præcist, hvordan de optimerer den bedst muligt. Det anbefales, at der så fastsættes en ibrugtagningsdato, hvorefter samtlige projekter skrives i systemet. Det er vigtigt, at retningslinierne overholdes til punkt og prikke, ellers virker kvalitetsstyringsmodellen ikke optimalt. Systemet hjælper med til at overholde modellen, men der vil altid være måder at omgås et system på, og derfor er det vigtigt, at virksomheden selv overholder den politik, den fastsætter. Da databasen jo vil være tom for tekstafsnit i starten, kræver det et stort stykke arbejde at fylde den med tidligere udfærdigede dokumenter, og deraf kan brugere drage erfaring til fremtidig udvikling. Alt dette kræver mange ressourcer, både mandetimer og penge til kurser. Så i virkeligheden vil penge til licenser kun være en begrænset del af de ressourcer, der skal bruges til realiseringen af systemet.

3.5 - Delkonklusion

3.5.1 - Kravspecifikation

De understående afsnit er ikke specifikt tilegnet denne prototype, men nærmere en prioritering af målene samt en opsummering af det fremtidige system:

Systemet skal bestå af en relationel SQL database. Vi har valgt MySQL men det skal være muligt at skifte databasen ud efter behov.
Så skal der være en server - PServ - der står for kommunikationen mellem databasen og klienterne. Serveren er skrevet i Java, så det er nemt at flytte fra platform til platform.
Klienten kan bestå af en applet, der kan køres fra en internetbrowser eller en hård klient applikation. Klienten kommunikerer med serveren og videre i databasen.

Funktionalitet
Administration af gamle/nye projekter, tekststykker, grafikelementer, produktbeskrivelser samt kunde-, leverandør- og medarbejder-kartotek. Søgning i tilknyttet database samt redigering og formatering af tekstelementer. Konvertering til diverse generelle formater så som .rtf og .html.
Dette kan stilles op i følgende overordnede funktioner:

Projektredigering.

Dokumentredigering.

Brugerhåndtering.

Kundehåndtering.

Leverandør og omkostningshåndtering.

Søgning.

Mailfunktioner.

Administrationsværktøj med bl.a. databaseoptimering.


Som det første må vi sikre os at databasen kan indeholde de elementer, der er nødvendige for at opbygge de ønskede projekter, hvilket betyder at programmet skal kunne håndtere og oprette disse. Samtlige elementer skal kunne oprettes: Grafik og billeder samt tekst- og produktelementer. Dog må vi i første omgang prioritere oprettelsen af tekstafsnit og brugen af disse højest.

Elementerne skal desuden kunne lokaliseres forholdsvis simpelt. Dette er en af de væsentligste funktioner, da det er en af de ting, koncerner normalt bruger meget tid på. Systemet skal derfor kunne tilknytte søgekriterier samt en overordnet kategori til hvert element.

Programmet skal som færdigt produkt selvfølgeligt kunne tilpasses hver enkelt virksomhed, der er interesseret i licens til programmet. For at realisere dette, vil punkter hvor der er afvigelser fra virksomhed til virksomhed, blive implementeret som plugins. Dette vil sige at har en virksomhed brug for en speciel funktionalitet, vil der være mulighed for at installere plugins med den ønskede funktionalitet.

Vi søger, at komme frem til et brugbart Java client/server forhold, som kan benyttes i de respektive arbejdsfunktioner tilknyttet virksomheden via plugins.
For at dette program kan blive en succes, vil en grundig vedligeholdelse af databasen være en forudsætning for at opfostre et indholdsrigt og kvalitets minded dokument bibliotek.

Vi har som mål at udvikle en prototype, der har et web interface udviklet i Java, som kommunikerer med en mySQL-implementeret database. Pro-Filer v1.0 er en prototype, hvilket skyldes tidsmangel til at udfærdige implementeringen, ikke mangel på evne dertil.

• Det eneste krav til platformen for produktet vil være en JVM.
• Formen vil være elektronisk dokumentstyring og manipulation.

I en endelig udgave af systemet vil det følgende være optimaliteter.
Databasen skal være fleksibel, flytbar og optimeret med hensyn til behandlingen af data.
Antallet af brugere vil være uden begrænsninger, dette resultere i en omfattende benchmark testperiode.
Der skal være funktioner til optimeringsautomatik af databaser.
Programmet skal være nemt at videreudvikle og være implementeret åbent og generelt. Dette giver modificerbare egenskaber og stabilitet.(se implementations afsnittet omkring plugins).


Formålet er er at binde en DAT med en server, over Internettet samt en evt. hård klient installation. Dette kræver et omfattende login, som verificerer oprigtigheden af den person, som søger adgang til systemet.
Denne socket connection har til hensigt at opnå tilgang, samt at benytte sig af det omfattende dokumenthåndterings-Ide-Koncept Pro-Filer.

3.5.2 - Afgrænsning

Den ovenstående kravspecifikation er for et fremragende system, der senere vil blive udviklet. Vi har dog ikke tid til det hele, så vi må afgrænse os fra følgende i kravspecifikationen. Der skal hertil nævnes, at nogle funktionaliteter kun ligger serverside og der er derfor ikke implementeret nogen GUI til disse i vores prototype. Som eksempel kan man nævne Brugerhåndteringen.

Projektredigering:
I en senere version, skal det være muligt at strukturere sine projekter med strukturskabeloner. Der skal være funktionalitet med status på projekter.

Dokumentredigering:
Vi vil i prototypen have en simpelt editor til dokumentbehandling. Senere skal man kunne lave design/skabeloner til dokumenter og have en mere avanceret editor, og man skal også kunne sætte attributter på dokumenterne. (Opdateringsdatoer m.m. med henblik på kvalitetsstyring).

Brugerhåndtering:
Vi kan i prototypen oprette og slette brugere, men funktionaliteten med brugerettigheder og ansvarsområder er ikke med.

Kundehåndtering:
Der skal senere være mulighed for indtastning af oplysninger om kunder. I prototypen af systemet kan det faktisk kun ske direkte i databasen, eller via kunde forumet.

Leverandør og omkostningshåndtering:
Det skal her i en fremtidig udgave være muligt at gemme oplysninger om leverandører og omkostninger. Det kan så overvejes, om man skal udvide systemet til at indeholde kostprisdatabase.

Søgning:
Det vil senere være muligt at søge på søgeord og andre data i databasen.

Mailfunktioner
I prototypen kan sendes mail internt, men en rigtig god mailfunktion med alt det vi kender, fra nuværende mailprogrammer, kommer først i en senere version af systemet. Dette ligger også metoder til dette i den forestående nyudgivelse af Java SDK, så dette ville være at opfinde en dyb tallerken igen.

Administrationsværktøj:
I det færdige system vil brugerhåndteringen komme under administrationsværktøjet. Desuden skal der i det færdige system være funktionalitet, der giver mulighed for vedligeholdelse af databasen. Man kunne også tænke sig en statistik funktion, der giver mulighed for statistik på status og indhold af projekter og dokumenter. Måske også på brugere, kunder og leverandører.

4. - Design

Dette afsnit dokumenterer strukturen for systemet. Vi har søgt at gøre strukturen forståelig og hovedsageligt fleksibel. Til sidst i afsnittet beskriver vi komponenterne, og fastlægger realiseringsrammerne indenfor den arkitektur vi har valgt.

4.1 - Opgaven

I designdelen skal vi skabe en stabil, men fleksibel struktur. Desuden skal den være forståelig og beskrives således, at udenforstående kan få et overblik over systemets opbygning. Designet er igen en iterativ proces, men er man i starten fleksibel nok, er det muligt at forandre systemet uden de helt store tidsmæssige omkostninger. Derfor har vi også lagt meget vægt på fleksibiliteten helt fra starten. Dette har allerede nu sparet tid, men vi vil først rigtigt kunne mærke det, når systemet videreudvikles. Designdelen af rapporten skal give et overblik over struktureringen af systemets komponenter og processer.

4.1.1 - Rettelser til analysen

Idet analysen og designet har været iterative processer, der på visse tidspunkter har overlappet hinanden, har det ikke givet mange rettelser som ikke allerede er ’indskrevet’. Den eneste væsentlige rettelse er, at vi ikke havde medtaget i klasse diagrammet et produkt der kan have flere forskellige leverandører, med hver sin omkostningsklasse tilknyttet. Dette giver en omstrukturering i klassediagrammet, der giver nogle mange til mange relationer, og derved et par nye tabeller. Dette er ikke implementeret, og det vil måske endda være en ting, der er forskellig fra virksomhed til virksomhed, alt efter hvilken politik de har på området.

4.1.2 - Kvalitetsmål

Et godt design har ingen væsentlige svagheder. Vi har, med vilje, ikke taget højde for særligt meget sikkerhed i systemet, det har vi ikke haft tid til. Til gengæld har vi gjort systemet så fleksibelt, at der er alle muligheder for at tilknytte sikkerheds aspekter i det. Dermed har vi endda taget højde for sikkerhed langt ud i fremtiden. Hvor brugbart systemet er på nuværende tidspunkt kan diskuteres, men det er jo også kun en prototype, og selv når vi når en betaversion vil brugbarheden kunne forbedres væsentligt. Men vi vil i vores struktur opnå en sådan fleksibilitet, at det giver mulighed for at udvide funktionaliteten (se afsnit om plugin).
Vi har taget højde for at delesystemer skal udskiftes og derfor er alle bindinger svage. Eksempelvis er databasen en MySQL database, men kan med de rigtige drivere nemt udskiftes med en anden SQL databaser. Vi har forsøgt at holde så lave eksterne koblinger som muligt, da det skal være muligt at køre systemet på mange forskellige grundlag.

4.2 - Teknisk platform

Udstyr afsnittet beskriver hvilken hardware man skal anskaffe sig, for at bruge systemet, og hvad vi har brugt af hardware til udviklingen.
Basisprogrammel beskriver hvilken software vi har brugt, samt hvilke teknologier vi har valgt til programmeringen og hvorfor vi har valgt dem. Desuden hvilken software, der skal anskaffes for at køre systemet.
I afsnittet Systemer og apparater omhandler specielt periferiudstyr tilkoblet vores system.

4.2.1 - Udstyr

Vi har udviklet systemet på vores egne pc'er, som vi selv har købt for vores egne penge. Der er ingen særlige maskinelle krav til den DAT, der skal køre klienten. Eneste nuværende krav er den pågældende maskine skal have adgang til Internettet via. en browser. Serverens hardware afgøres af, hvor mange brugere, der skal kunne få adgang til systemet ad gangen.

Den fysiske server er en Pentium 133mhz med 32mb Ram og 420mb harddisk. Den kører Debian, dog kun få brugere, er der rigeligt med "juice" i denne noget gamle konfiguration.

4.2.2 - Multi-tier

Flere og flere koncerner benytter multi-tier løsninger til komplekse client/server systemer. Denne metode er et resultat af det stigende behov for datatilknytning til Internettet samt bedre Return On Investment (ROI).

Multi-tier modellen benytter sig samtidigt af den ide, at delprogrammer skal være skalerbare, altså kunne udvides, genbruges, samt indeholde fornuftige interfaces til en fremtidigt komponentbaseret model.

Større programudvikling med høj On-Line-Transaction-Processing (OLTP) har gennem de seneste år bevæget sig fra two-tier til multi-tier eller n-tier. Dette skyldes, at selvom den pågældende virksomhed måske ikke har et specifikt behov for multi-tier løsningen, kan der i en nærmere fremtid foreligge et behov for noget sådan.

Web baserede multi-tier client/server forhold

UserInterface-tier eller (UI-Tier) er det lag som håndterer den faktiske bruger interaktion. Der kan udvikles mange forskellige UI til at tilgå samme data på serven. Normalt afvikler UI-tier metoder tilknyttet applikationslogik-laget. For vores system gælder følgende:

Client - siden (UI-Tier)
Fordele :

• Universel platformuafhængige klienter.
• Minimal vedligeholdelse.
• Ingen installations problemer.
• Tilgang til systemet er uden geografiske restriktioner.

Ulemper :

• Sikkerhed kan kompromitteres ved distribuering over net.

Middleware eller applikationslogik-laget er server-baseret kode, hvor med clientkoden kan interagere. Det er i dette lag hvor dokumenthåndteringen, søgninger, budgettering og ordre håndteringen mm. bliver afviklet. Middelware-objekter kan invokere metoder på DSSS (Data Store Server Side) niveau.

Middleware - siden (Server-Tier)
Applikationslogik :

• Integration af virksomhedens regler for dokumentstandarder.
• Enkelt bruger multipel database adgang.
• 'Uptodate' håndtering af dokumenter.

DSSS-laget (Data Store Server Side) er opbygget af objekter, der indkapsler databasespecifikke rutiner i direkte kontakt med DBMS produktet. Eksempeltvis kan en hypotetisk eksisterende metode som; hent_projekt_omkostning, blive implementeret til at hente data direkte fra en relationel database ved hjælp af en tilpasset SQL SELECT forespørgelsel.

Data Store Server Side - siden (Database-Tier)
Fordele :

• Simpelt UI-interface samt vedligeholdelse.
• Server specifisering via. plugins til den enkelte virksomhed.
• Aktiv forbindelses håndtering.

Ulemper :

• Sikkerhed kan kompromitteres ved distribuering over net.

Det at bygge et skalerbart client/server program til en evigt voksende bruger base har aldrig været en nem udfordring, specielt hvis kriteriet er platformuafhængighed. Ideen er at Pro-Filer skal indeholde de almindelige funktioner for distribuerede systemer så som distribuerede transaktioner, en forbindelses manager, samtidigt med administrationen er så simpelt som 'point-and-click'.

Samlet vurdering af inkorporering af Pro-Filer.
Fordele :

• Aktivt udnyttelse af Internettet som medie.
• Mulighed for bestilling af helt specifikke moduler designet til den enkelte virksomhed.
• Arbejde kan gemmes server-side ved automatisk synkronisering, så ved 'client crash' går intet tabt.
• Arbejde bliver gemt server-side så det opdaterede materiale er tilgængeligt hvis man skifter DAT.

Ulemper :

• Kræver en, med fordel hurtig, opkobling til alle brugere af systemet.
• Et server indkøb.
• Kræver 'cutting edge' (minimum JDK1.2) Java plugin pakke installeret på alle klienter.

4.2.3 - Basisprogrammel

I vores proces mod det færdige produkt arbejder vi i et forum med en struktur, hvor alle dokumenter, databaser, alt programmel samt tidsplansoversigten ligger tilgængeligt for gruppens medlemmer. Dette har til fordel at vi alle kan benytte os af de sidste nye opdaterede tekst- og brud-stykker. Dette forum er udviklet med php.
Selve Java Appleten er udviklet ved hjælp af IBM's Visual Age 3.0 og tilgangen hertil i en simpel teksteditor(vi overholder HTML4.0 standarden). Som database har vi valgt MySQL, og sproget er SQL2. MySQL kan benyttes med fordel da den er freeware til Linux maskiner. I XML er Near and Far brugt som syntaks tjekker. XML er dog ikke implementeret endnu, da XMLEditorKit stadig er under udvikling hos Sun. Vi kunne selv udvikle en, men det har vi ikke tid til, og når Sun alligevel er ved at udvikle én, kan vi lige så godt bruge den, når den kommer.
Der skal, for brugere og kunder være adgang til systemet via en web-browser. På den måde kan man få adgang til systemet fra næsten enhver computer i hele verden, og kan dermed, uanset hvor man befinder sig, arbejde sammen med sine kolleger i Danmark eller hvor de end måtte befinde sig. For at kunne få tilgang til systemet via en browser, skal der enten bruges ASP (eller anden serverside scripting/programmel), eller der kan startes en applet. Vi har valgt at benytte os af begge dele. Vi vil via en applet, gøre det muligt for brugeren at få adgang til systemet, da en applet i større grad giver os en mulighed for at udvikle et arbejdsmiljø, der har de ønskede funktioner. Derudover sikrer javamiljøet at klientdelen nemt og hurtigt kan udvikles og videreudvikles. Applet-løsningen giver også enklere og hurtigere adgang til PServeren. Vi vil dog benytte ASP som den bærende del på kundesiden da kunden kun skal have adgang til enkelte og ukomplicerede dele af databasen/systemet. Dette kan nemt gøres med ASP.

I denne implementering af systemet har vi valgt følgende:

• MySQL, v.6.9 som databaseserver. MySql er hurtig, gratis og ganske udmærket.
• Apache v.1.8 som web-server. Apache er hurtig, gratis og ganske udmærket.
• IBM's JRE port til Linux. Denne port er formentlig den hurtigste VM på markedet pt.

4.2.4 - Systemer og apperater

Ja, man kan tilslutte en printer, hvis man har lyst til det. Der eksistere ikke på nuværende tidspunkt nogle specifikationer eller krav om periferiudstyr til systemet. Der kunne overvejes at tilkoble et scannersoftware i den fremtidige grafiske editor.

4.3 - Arkitektur

Det er her nødvendig at indføre, eller i hvert fald specificere nogle begreber, for at undgå forvirring i det følgende. Først skal forskellen mellem forfatternes brug af ordene bibliotek og komponent slås fast:

Endvidere skal det nævnes at: Idet Pro-filer er et client/server-system vil vi i den resterende del af designdokumentet ofte omtale de to delsystemer hver for sig. Med clientsystemet menes således den del af systemet/arkitekturen som er unik for clientsiden samt den del der er fælles for både serverside og clientsiden. Ligeledes skal serversystemet opfattes som de dedikerede server-komponenter samt fælles-komponenter. Det skal bemærkes at systemets web-server og databaseserver ikke indgår i definitionen af de to begreber, men kun de af os udviklede klasser, strukturer og komponenter. Begreberne kan illustreres således:

Fælles-delene omfatter klasser fra model- (PDC) og funktions-komponenten (TMC). Komponenter, biblioteker og klasser vil blive beskrevet detaljeret i det følgende. Når vi i dokumentet definerer Pro-filer som et client/server er det ikke fyldestgørende udtryk. Den tekniske opbygning af Pro-filer understøtter nemlig også hvad man kunne kalde server/server og server/client arkitekturen. Grunden hertil skal findes i følgende definition:

De eneste krav til en PApplikation er altså at PKernel-klassen og PApplikationInterface'et implementeres. Det er netop i Kernel-biblioteket at funktionaliteten til blandt andet, netværkskommunikation og databaseadgang ligger. PKernel-klassen tilbyder denne funktionalitet på baggrund af en tilknyttet PKernel-configurationsfil. Når vi tidligere hævder at Pro-filer også understøtter server/server og server/client arkitekturerne, afhænger det altså af, hvordan to kommunikerende PApplikationer har konfigureret deres PKernel's. Med andre ord, hvis PApplikation A, 'tænder' for serverfunktionerne og PApplikation B ligeledes 'tænder' for disse, er der altså tale om en server/server arkitektur. Denne program-ideologi har markante ulemper, men også attråværdige fordele. Vi henviser til afsnittet delkonklusion sidst i dette dokument for en diskussion af disse. Grafisk kan omtalte opbygning illustreres på følgende vis:

Selvom det tekniske ikke sætter hindringer i vejen for at den samme PApplikation samtidig kan fungere som en client og en server, vil man i praksis vælge en 'rolle' til sin applikationen og nøjes med at 'tænde' for de funktioner som er nødvendige for at opfylde kravene til den pågældende applikationen. Dette leder os til følgende definition:

Hvor begreberne: Clientsystemet og Serversystemet dækker over 'noget abstrakt', er nøgne servere og -clienter navnet for reelle forekomster, 'noget konkret':

Pro-filer er primært designet til at opfylde 'almindelige' client/server behov, med en eller flere nøgne servere centralt placeret i basisvirksomheden hvortil der er tilknyttet et antal nøgne clienter.

De af os udviklede klasser, strukturer og biblioteker tjener, overordnet set to formål: dels at skabe en 'fungerende prototype' og dels at tilbyde udviklere en række 'værktøjer' til nemt og smertefrit at 'bygge' egne PApplikationer, det er således vigtigt at huske på at klasser, strukturer og biblioteker er udviklet, med det formål for øje, at opbygge et Profiler-FrameWork.

Endelig skal det kort nævnes, at eftersom Pro-filer er udviklet i Java, kan der i de kommende afsnit findes passager, der forudsætter at læseren har et rimeligt kendskab til dette programmeringssprog. Således, med dette, og ovenstående definitioner på plads, vil vi begynde den detaljeret gennemgang af designet for Pro-filer.

4.3.1 - Komponentarkitektur

Systemet opererer med følgende standard komponenter:

• Brugergrænsefladekomponent - også kaldet: Human Interaction Component (HIC).
• Modelkomponent - også kaldet: Problem Domain Component (PDC).
• Databaseaktionskomponent - også kaldet: Data Management Component (DMC).
• Funktionskomponent - også kaldet: Function Management Component (FMC).

Sammenhængen mellem komponenterne og de to delsystemer kan groft illustreres således:

Af figuren ses at flere af komponenterne 'deles' mellem de to systemer, nemlig PDC'en og FMC'en. PDC'en, som modellerer problemområdet, er nødvendig for begge systemer, da de begge skal kunne bearbejde, ændre og for klientsystemets vedkommende, også præsentere PDC'ens modeller og tilstande. Også FMC'en, eller rettere dele af FMC'en, er nødvendig for begge systemer. FMC'en indeholder blandt andet føromtalte Kernel-bibliotek, og således også al socketprogrameringen, og danner dermed grundlag for at en PApplikation kan kommunikere over et netværk.

Et ønske til designet har været at opbygge strukturer som vil gøre Pro-filer nemt at vedligeholde og udbygge. Ønsket er imødekommet ved at skabe et Profiler-FrameWork samt at benytte det 'platformuafhængige' udviklingssprog: Java. FrameWorket er opbygget af en række biblioteker, som ikke direkte stemmer overens med de fire nævnte standartkomponenter, undtagelserne er dog bibliotekerne: dk.dkik.profiler.pdc og dk.dkik.profiler.hic, som svarer direkte til det man traditionelt kalder: modelkomponenten og brugergrænsefladekomponenten i nævnte rækkefølge. Med andre ord, er biblioteks-opdelingen af Pro-filer ikke fundet sted, med det formål at 'tilfredsstille' litteraturen eller 'traditionerne', men derimod for at imødekomme ønsket om høj brugervenlighed og skalerbarhed. Ikke desto mindre er det ofte muligt entydigt at placere et givent bibliotek i en af de fire standard-kasser'. I de senere afsnit hvor de enkelte profiler-biblioteker, hver for sig, bliver beskrevet, vil der være en note om forholdet mellem de fire 'standard-kasser og biblioteket. Indtil videre vil vi blot nøjes med at beskrive biblioteks-strukturen. Nedenstående figur er et udklip af den javadoc-genereret dokumentation og tjener det formål at give læseren et klart overblik over omtalte struktur. Idet læseren, i øvrigt, gøres opmærksom på at der i den 'rigtige' API-dokumentation, kan forekomme små afvigelser fra figuren, og at denne derfor ikke nødvendigvis er 100% korrekt, opfylder udklippet alligevel omtalte formål.

Vi vil, som sagt, ikke beskrive de enkelte biblioteker i dette afsnit, men blot afslutte med at påpege de to hovedgrupper et bibliotek kan tilhøre:

• FrameWorket og
• det som ikke tilhører FrameWorket

Opdelingen taler næsten for sig selv, idet biblioteker som tilhører FrameWorket alle starter med dk.dkik.profiler.framework.... Læseren vil formentlig, -og med rette, mene at den sidstnævnte kategori er en noget uklar størrelse Hertil kan nævnes at man i det som ikke tilhører FrameWorket blandt andet finder den nøgne-server og den tilhørende nøgne-client, som udgør vores 'fungerende prototype'. Øvrige biblioteker er nødvendige, men på ingen måde afhængige af FrameWorket, og kunne lige så godt være placeret, eller for den sags skyld; produceret, et andet sted.

4.3.2 - Procesarkitektur

Som beskrevet ovenstående bygger systemet på en klient/server arkitektur (men kan også fungere som andet) og skal installeres med Pserv, en databaseserver og en webserver.
Systemet er jo et flerbrugersystem, af klienter er der derfor flere processer, der skal have adgang til PServ samtidigt. PServ skal så have adgang til database, eventuelt samtidigt med en webserver. Dette kan give nogle falskehalse:
Bånbredden på nettet.
Computerkraft for PServ.
Computerkraft på webserveren.
Computerkraft på databaseserveren.
Begrænsning i databaseserverens adgang.

Som det er nu, kan både Pserver, databaseserver og webserver godt ligge på samme maskine, men ved mange brugere, bør man overveje at distribuere dem proportionalt med stigningen i antal brugere, alt efter om det er klienter eller kunder, der bruger webserveren.

4.4 - Frameworket

Ud fra et 'dataflow-synspunkt' ville det være mest praktisk at starte framework-beskrivelsen med dk.dkik.profiler.framework.kernel- biblioteket, idet at dette bibliotek er det 'sted' hvor alle data'er 'kommer ind' i enhver PApplikation (Hvis vi et øjeblik ser bort fra bruger-indtastet data). Det er da også her vi vil starte vores komponent-rejse, da det er vores opfattelse, at en forståelse af kernel-biblioteket vil gøre den resterende del mere overskuelig, logisk og kortere. Inden da skal vi dog kort se på sammenhængen mellem de vigtigste biblioteker i FrameWorket, inklusiv kernel-biblioteket:

Som man kan fornemme på tegningen er kernel-biblioteket, det centrale bibliotek og andre biblioteker tjener hovedsagelig det formål at understøtte dette. Kernel-biblioteket henter sin funktionalitet fra plugin-bibloteket, bortset fra de 'basale' funktioner: netværksunderstøttelse, database-adgang. m.m. Pro-filerer altså et system baseret på plugin-ideen, og er derfor et ekstremt skalerbart systemet. Et bibliotek i systemet er altid navngivet således at det sidste led er unikt. Derfor vil dk.dkik.profiler.kernel.plugin-biblioteket, af rent praktiske grunde, i det følgende blive omtalt som plugin-biblioteket og ligeledes kaldes dk.dkik.profiler.pdc-biblioteket blot for pdc-biblioteket. Endvidere skal det nævnes at vendingen: ...X-biblioteket..., ofte bruges i betydningen: ...klasserne i X-biblioteket... hvor X er navnet på et givent bibliotek.

4.4.1 - Dk.dkik.profiler.framework.kernel

Overordnet set, danner/indeholder Kernel-biblioteket grænsefladerne til andre (del)systemer. Dels drejer det sig om grænsefladen mellem en PApplikation og et eventuelt grafisk-brugergrænseflade, - om grænsefladen til eventuelle plugin-moduler, og sidst, men ikke mindst: - om grænsefladen mellem en PApplikationen og netværket. Vi skal starte med at kigge på det sidstnævnte, som kan illustreres således:

Det er altså kernel-biblioteket, som skal fortolke de informationer computeren modtager via sin TCP/IP forbindelse, behandle disse informationer, eventuelt sende dem videre til enten PApplikation eller et plugin, eller sende et respons tilbage på nettet. Ovenstående figur er mangelfuld på det område, at den ikke viser at kommunikationen naturligvis er tovejs. For den almindelige PApplikations-programør, der benytter sig af profiler-FrameWorket, er det ikke nødvendig at vide hvordan to kernels kommunikerer over et netværk, idet en kommunikation pænt bliver kanaliseret til det rette sted i systemet. Ikke desto mindre er kommunikationen mellem sådanne kernels vigtig for os, og for den læser der ønsker den fulde forståelse af Pro-filer. En kommunikations-protokol (herefter: PProtokol) er derfor specificeret senere i dette design-dokument. I det følgende vil vi, som indikeret, først kigge på kernelens netværksegenskaber, herefter vil vi 'håndkøre' en 'samtale' mellem to kernels og endelig vil vi skitsere de to sidste af kernel-bibliotekets grænseflader.

4.4.1.1 - Struktur

Kigger vi nærmere på kernel-biblioteket, finder vi, i relation til netværks-funktionaliteten 4 vigtige klasser: PKernel, PKernelPack, PKernelSocketServer og PKernelSocketClient. PKernel-klassen er bibliotekets hoved-klasse, og er er den klasse som biblioteket er bygget op omkring. Øvrige klasser i biblioteket er tjenede-klasser eller man kunne kalde dem undersåtter. PKernelPack, PKernelSocketServer og PKernelSocketClient er altså sådanne undersåtter. Ved opstart 'læser' PKernel-objektet (vi taler her om PKernel-objektet og ikke PKernel-klassen, da vi nu er i en 'kørende' situation) sin del af 'Konfigurations-filen' og bestemmer sig for hvilken funktionalitet det skal tilbyde. Eksempelvis vil den oprette mulighed for at andre PKernel-objekter, kan 'connecte' til den. (Dette er naturligvis en funktionalitet som hovedsagelig tilhører Serversystemet) Lad os forestille os at en given PKernel ønsker at 'lytter' efter clienter på tcp/ip-port 6666, 6667 og 6668. Ved opstart vil denne kernel 'spawne' tre PKernelSocketServer-objecter som hver lytter på en af disse porte.

(Pt. er der ikke de store fordele ved at lytte på mere end en port, (bortset fra at det i sjældne tilfælde kan nedbringe 'ventetiden' nogle millisekunder), men tanken er, at det på et senere tidspunkt kan være ønskværdigt at implementere forskellig funktionalitet på de forskellige porte. Hvorfor ikke sende en e-mail til en PApplikation, med kommandoer, eller måske blot få Pro-filertil at konvertere mailen til det interne mail-format, hvorefter beskeden sendes til den ønskede afsender ? Sådanne ideer vil langt nemmere kunne blive implementeret hvis også 'lytte-portene' er konfigurebare. Under alle omstændigheder forhindrer kernel-bibiotekets opbygning ikke sådanne fremtidige ønsker.)

Efterhånden som clienterne 'ankommer' vil PKernel-objektet spawne et tilsvarende antal PKernelSocketClient-objekter. Processen kan illustreres således:

Vi kan få en bedre forståelse af kernel-strukturen ved at betragte følgende tænkte eksempel:

• PKernel starter op og opretter et PKernelSocketServer-objekt, på eks. port 6666
• En client 'ankommer' til port 6666, hvorefter PKernelSocketServer-objektet opretter et PKernelSocketClient-objekt
• PPKernelSocketServer-objektet 'går' tilbage i 'lytteposition' for at 'modtage' nye clienter, imens bliver det nyoprettet PPKernelSocketClient-objektet 'registreret' hos PKernel'en, som gemmer en pointer til dette objekt. Kommunikation mellem PApplikationen og clienten, foregår fremover via PKernelSocketClient-objektet.
• Nu sender clienten eksempelvis en login-kommandoen. Denne modtages af PKernelSocketClient-objektet
• PKernelSocketClient-objektet konverterer/påhæfter nu det indkomne til et PKernelPack-object. (PKernelPack-klassen vil blive beskrevet i detaljer senere. I denne sammenhæng er det dog nok for læseren at vide; at PKernelPack-objekter blot fungerer som 'en sætningen'. Hvis kommunikationen mellem to kernels sidestilles med en samtale mellem to mennesker, vil de sætninger der udveksles, kunne sidestilles med Pro-filer's PKernelPack-objekter.)
• PKernelSocketClient-objektet bestemmer nu om PPack'en kan behandles allerede på 'socket-niveau'. Hvis dette er tilfældet, vil behandlingen finde sted, da der således ikke er nogen grund til at 'forstyrre' de overliggende lag (hvis der findes syntaks-fejl i det indkomne, vil dette altid blive behandlet på 'socket-niveau'). Hvis det ikke er muligt at behandle PKernelPack'en her, sendes denne i stedet opad i hierarkiet til PKernel-objektet
• Omtalte PKernelPack'en kunne eksempelvis være en kommando. I sådanne tilfælde ville den afføde et svar. Dette svar bliver herefter sendt tilbage til PKernelSocketClient-objektet hvorefter det 'ligges' på nettet og transmitteres til det forbundne client-system.

Herefter sker noget tilsvarende i netværkets anden ende, hos clienten.

Som skrevet, kan et PKernel-objekt 'indlæse' plugins. Et sådant plugin kunne eksempelvis være et Mail-plugin, således at Pro-filer kunne indeholde mail-funktioner. Den opmærksomme læser har formentlig noteret sig at sådanne mail-funktioner har været omtalt i den foregående del af rapporten og derfor allerede skulle være er en del af Pro-filer. Det er da også rigtigt at mail-funktionerne 'hører' til det man kunne kalde 'basis'-funktioner, men pointen i denne sammenhæng er, at denne basis-funktionalitet er 'programmeret' som et plugin, på samme måde, og på lige fod, med alle andre plugins. Sammenhængen mellem PKernelen og plugins kan illustreres ved hjælp af følgende figur.

PKernel-klassen er altså systemets 'hjerte'. Den står for at 'binde' omverdenen sammen med resten af systemet. Vi skal i de følgende afsnit kigge nærmere på hver enkelt klasse i kernel-biblioteket og især PKernel-klassen, men først et overblik over den samlede struktur af kernel-biblioteket og sammenhængen til andre biblioteker (Figuren herunder er endvidere en samling af de to foregående figurer):

Vi har nu en forståelse af sammenhængen mellem de forskellige biblioteker i Pro-filer Netsolution . Lad os herefter se hvad der sker når en en PKernel-object initialiseres. Først registreres den pågældende PApplikation, og en pointer til denne gemmes i PKernel-objektet. Herefter læses den tilknyttede configfil, denne kan ligge på samme maskine eller den kan indlæses fra nettet via HTTP. Oplysninger i config-filen gemmes i en config-tabel i PKernel-objektet. Configfilen er opdelt i sektioner, som ofte vil være navngivet, således at de 'stemmer' overens med navnene på de objekter som skal/vil benytte dem. Adgangen til configfilen indbyder til at et objekt ikke bør læse/modificere andre config-sektioner end den som bærer objects klassenavn. Nu læser PKernel-objektet sin del af configfilen og 'beslutter' på denne baggrund om der skal oprettes en ClientSocket. Herfter 'besluttes' om der skal oprettes ServerSockets, og i givet fald på hvilke(n) port(e). Skal der kun oprettes en ClientSocket vil den givne PApplikation i princippet fungere som en nøgen client og ligeledes hvis der kun er tale om oprettelse af serversockets, er der tale om en nøgen server. Basis-systemet, eller hvad man kunne kalde for 'pro-filer styresystemet' er nu reelt klar 'til brug' men i praksis vil der stadig mangle en masse funktionalitet i systemet. Derfor, og som det sidste PKernel-objektet gør i sin initialiserings-proces, indlæses de eventuelle plugins som måtte være spcificeret i configfilen. Inden vi beskriver indlæsningen af plugins skal vi dog lige runde følgende definition:

Plugin-ideen er det smukke og smarte ved Pro-filer Netsolution og måden hvorpå et PKernel-objekts implementerer 'sine' plugin har ligeledes været udsat for en del gennemtænkning og design-omhu. I praksis foregår det på følgende måde:

• Et PKernel-objekt starter op som beskrevet ovenfor. På dette tidspunkt har dette objektet ingen anelse om hvilke plugins der skal indlæses
• Stien på hvert eneklt plugin er spcificeret i configfilen, og PKernel-objektet tager nu fat på dem en efter en.
• Forudsat at den specificerede plugin-klasse kan lokaliseres oprettes et objekt af pågældende type, dette plugin-objekt gemmes i PKernel-objektets plugin-tabel. Nu skannes objektet for 'brugbare' pluginmetoder. Kriteriet for at en 'pluginmetode' kan registreres er først og fremmest at den er public, og herefter at metode-navnet starter med ordet:profiler. Det kunne tænkes at et plugin havde brug for andre public'e metoder som ikke skal registreres som en 'pluginmetoder' hvorfor navne-kriteriet er indført. (Et plugin bør ikke have andre public'e metoder end de egentlige 'pluginmetoder' da komunikation på tværs og imellem plugins frarådes. Der stilles nemlig i Pro-filer Netsolution -systemet ikke krav til en PApplikation om at specifikke plugins skal indlæses og slet ikke i hvilken rækkefølge en eventuel indlæsning skal foregå. Inter-plugin-komunikation er derfor ikke ønskværdig. Også fundne plugin-metoder gemmes i en tabel i PKernel-objektet
• Endelig skannes de nyoprettede plugin-objekt for eventuelle public'e grafiske elementer. Hvis et eller flere af sådanne objekter findes 'leveres' disse til PApplikationen. Vi husker på at en PApplikation skal implementere PApplikationInterface'et, og netop dette faktum gør at PKernel-objektet er istand til at levere grafiske objekter til sin herre: den tilknyttede PApplikation. PApplikationInterfacet dikterer nemlig at PApplikationen implementerer en metode som hvis 'hoved' antager formen: reciveGUI(java.lang.String pluginName, java.awt.Component guiComponent). PKernel-objektet kalder altså denne metode hos PApplikationen med plugin'ets navn, og de pågældende grafiske objekt som argumenter. Herfra er det op til PApplikationen at gøre med disse referancer hvad den vil, oftest vil dette naturligvis indebære at componentet vises på skærmen.

4.4.1.2 - PProtocol

PProtocolen specificerer hvordan to PKernel-objekter, og dermed i sidste ende: to PApplikationer, 'snakker' sammen. Kernel-biblioteket indeholder, som skrevet, al socket-programmeringen og 'connecter' direkte på TCP-servicen. PProtoklollen ligger altså 'ovenpå' dette TCP-lag. PProtokollens 'plads' i OSI-modellen kan ilustreres således:

En Kernel benytter sig af en stream-forbindelse, (pt. understøttes kun TCP) med en relative simple kommando/svar-strukturer. Kernel'en er designet til at tilbyde andre Kernels et simpelt interface til resten af den pågældende PApplikation. PProtokollen specificerer ingen speciel TCP-'lytteport'.

I det følgende, når der tales om tegn og karakterer, er det med udgangspunkt i ASCII-tegnsættet. Endvidere har vi brug for følgende definition:

Komunikation mellem to PKernel-objekter foregår ganske enkelt ved at det ene PKernel-objekt, på et givent tidspunkt, sender en kommando/forespørgsel, hvorefter det, i dette tilfælde, modtagende objekt, ofte vælger at sende et svar tilbage. Selvom PProtokollen ikke direkte dikterer at en kommando/forespørgsel altid skal besvares, anses det dog for 'god kotume'. Vælger 'man' at afgive et svar skal et sådant dog overholde formen: _OK eller _FAILED. (eks: kunne et svar på kommandoen : LOGIN være <LOGIN_OK< i>eller LOGIN_FAILED) Pakker er ugyldige, set i forhold til PProtokollen, hvis de ikke overholder, de, i dette dokument, specificeret krav. Endvidere kan vi beskrive en pakke ved at den indeholder en række felter, nemlig:

• DATAPOINTER-feltet (Størrelse: 4 byte. Lovlige værdier: [0..9], [a..f] samt [A..F])
  Både kommandoer og svar kan være databærende, det vil sige at der kan sendes data (udover eventuelle parametre) med en pakke. Disse data, kan herefter benyttes af den modtagende part. Data, i denne forbindelse, er pdc-objekter, eller rettere objekt-tilstande. DATAPOINTER-felt angiver altså om transaktionen er databærende eller ej, feltet indeholder nemlig antalet af objekter som sendes.
• ID-feltet (Størrelse: 8 bytes. Lovlige værdier: [0..9], [a..f] samt [A..F])
  De næste 8 bytes, benyttes til unik at identificerer den pågældende pakke, og kaldes derfor ID-feltet. Det er nødvendig for en PApplikation, at kunne indentificere en pakke entydigt, da der ikke er nogen krav til at en PApplikation, 'behandler' de indkomne pakker i kronologisk rækkefølge, endvidere specificerer PProtokollen ingen maximum svartider, og det kan derfor ikke på forhånd bestemmes hvornår et eventuelt svar retuneres. Pakkens unikke egenskab, som herved er givet af ID-feltet er altså den eneste sikre måde at afgøre hvilke svar der 'hører' til hvilke kommandoer/forspørgsel og omvendt.
• KS-feltet (Størrelse: Variabel, dog minimum 1 byte. Lovlige værdier: Alle ASCII-tegn)
  ID-feltet efterfølges af et (variabelt) antal bytes som udgør kommando/svar-feltet. (forkortet KS-feltet). Et KS-felt skal altid afsluttes med whitespace (space eller tab). Det skal endvidere bemærkes at KS-feltet ikke er 'cAseSENsiTivE')
• PARAMETER-feltet (Størrelse: Variabel incl. 0 byte. Lovlige værdier: Alle ASCII-tegn)
  Dette felt indeholder pakkens parametre (ikke at forveksle med de føromtalte data. jvf. beskrivelsen af DATAPOINTER-feltet, og består altså af 0 eller flere bytes. Hvis denne sidste del indeholder mere end et parametre, sepereres disse af whitespace.

Pakke-strukturen kan grafisk illustreres således:

Pakken afsluttes herefter med et linjeskift (Både LineFeed og CarrigeReturn, eller en kombination af disse accepteres som linjeskift). Hvis pakken er databærende vil dette/denne blive efterfulgt af det/de tilknyttede objekt(er).

4.4.1.3 - Klasser og metoder

Mostly removed in the online version.

PKernelPack

PKernelPlugin

4.4.2 - Dk.dkik.profiler.framework.kernel.plugin

Som det er beskrevet i ovenstående afsnit, loader PKernel objektet sine plugins ved opstart. Det er defineret i configfilen, hvilke plugins, der skal loades. Det er derfor hovedsageligt disse, der bestemmer, om en PApplication skal have client eller server funktionaliteter.
Et plugin er opbygget på følgende måde:
Pluginclassen skal nedarve fra den abstrakte klasse PKernelPlugin, eller hvis pluginnet skal have databaseadgang, skal det nedarve fra PKernelPluginDB, der igen nedarver fra PKernelPlugin, men giver mulighed for at skrive statements til den i configfilen definerede database. PKernelPlugin nedarver igen fra PKern, der bare giver adgang til logfil og configfil. Idet et plugin nedarver fra PKernelPlugin betyder det også, at det skal kaldes med et PKernelobjekt. Dette PKernelobjekt giver så adgang til den PKernelSocket, som nu er tilknyttet objektet. Således kan et plugin kommunikere med omverdenen. Strukturen i selve pluginnet beskrives nedenfor.

4.4.2.1 - Struktur

Når et plugin loades, scannes pluginnet som sagt for 'brugbare' metoder af PKernel objektet. Disse metoder skal have et navn, der starter med 'profiler', så PKernelobjektet kan finde dem. Disse metoder skal naturligvis være public, for at de kan kaldes udefra. Da de samtidigt er de eneste metoder, der jo skal kaldes, vil det også være naturligt, hvis resten af metoderne, der kan være hjælpemetoder, er private.
Et plugin kan både være grafisk og ej. Hvis ikke det er grafisk, er der ikke så mange dikkedarer, andet end det før omtalte. Hvis pluginnet er grafisk derimod, skal man sørge for, at pluginnet leverer et grafisk komponent til PApplikationens recieveGUI metode, der så kan gøre med det, hvad den vil. Men i pluginnet skal holdes styr på, hvordan den del af GUI'en skal se ud, der er specifik for pluginnet.

4.4.2.2 - Klasser

4.4.3 - Dk.dkik.profiler.framework.hic

HIC'en (Human Interaction Component) indeholder de visuelle komponenter som er lavet specielt til dette program. Af eksempler kan der nævnes de kommende mail styrings komponenter (mailRecieve og mailSend). Disse elementer er kun beregnet til de programmer vi udvikler og kan ikke tænkt som generelle komponenter til andre programmer. Klasserne som kommer til at være placeret her, vil være en samling af javas generelle komponenter sat sammen til et komponent, evt. med noget tilføjet funktionalitet.

4.4.3.1 - Struktur

Når et plugin i dk.dkik.profiler.framework.kernel.plugin skal bruge en grafisk overflade skal den referere til den rigtige class-fil i denne package. Grunden til at valget er faldet på denne opbygningsform, falder tilbage på, at dette gør det nemmere at ændre GUI'en, i det tilfælde at den skal ændre udseende eller skal have udvidet funktionaliteten.
Denne package er opbygget på den måde, at der skal laves en ny class-fil, for hver GUI der skal benyttes af plugins. Dette understøtter det ovenstående om redigeringsnemhed.

4.4.3.2 - Klasser

På nuværende tidspunkt er der ikke implementeret grafiske plugins, men der vil, i en senere udgave af programmet, som minimum blive implementeret 2. De 2 plugins som det i første omgang drejer sig om, er til modtagelse og afsendelse af e-mails.

4.4.4 - Dk.dkik.profiler.framework.pdc

PDC - eller modelkomponentet er opbygget på en måde, så følgende egenskaber gør sig gældende:
Alle entiteter nedarver fra PAnEntitet. Derved får de evner til at levere SQL sætninger, så de plugins der skal rette i databasen, ved hvordan det skal gøres. F.eks. et plugin spørge PBruger objektet, hvodan PBruger objektets tabel skal se ud, og så kan PBruger objektet levere en SQL sætning til at oprette en tabel til sig selv. Derudover kan en entitet læse fra et resultsæt og den har også mulighed for sende og modtage streams, så den kan læse og skrive til nettet. Alle entiteter ved hvordan de selv skal læses og skrives fra nettet.Desuden kan man få adgang til objekternes attributter via metoder, der ligeledes er nedarvede fra PAnEntitet. Dette er beskrevet i nedenstående afsnit om struktur.

4.4.4.1 - Struktur

Strukturen for PDC er opbygget således:
Alle nedarver fra PAnEntitet:
Væsentlige metoder, som nedarves:
PAnEntitet(BufferedReader): Når denne constructor metode nedarves, kan objektet læse objekter af sin egen type via en bufferedreader.
PAnEntitet(ResultSet): Med denne constructor metode, kan objektet læse sine attributter fra databasen i et resultset.
getSQLStatementCreateTable(String[][], String): Med denne metode kan objektet regne ud, hvad tabellen i databasen, der tilhører objektet, skal hedde.
getTYPE(String): Disse metoder sørger for, at attributter af den rette type hentes i databasen. De loades ind i constructoren, og kan så kaldes af objektet.
readTYPE og writeTYPE metoderne, læser og skriver de rigtige typer fra BufferedReaderen og PrintWriteren.
PAnEntitetException:
Denne classe nedarver bare fra RunTimeException, og kan derfor kaste en sådan, og vi har så tilføjet et argument, der er en String.
PObjekt:
Disse classer (PBruger m.m.) nedarver alle fra PAnEntitet, og har alle en metode, der identificerer deres egne attributter. Senere hen vil det så være muligt at tilføje specifikke metoder til dem, så de kan læse og skrive specifikke ting fra nettet.

4.4.4.2 - Klasser

Removed from online version.

4.4.4.3 - Database

PDC komponentet er en af de data-bærene dele af frameworket hvor der bindes mellem objekt systemet og Pro-Filer databasen.Ved at nedarve fra PKernelPluginDB gives der socket adgang til data gennem en data-aware kontrol struktur i klienten. Database strukturen er defineret ved tabeller med datasæt og attributter som herunder fremstillet.

Man kunne for så vidt have benyttet mange forskellige typer SQL-databaser. Vores valg af database kunne også have hvilet på den distribueret ide som Jasmin! istedet for vores relationære database. Systemet taget i betragtning er mySQL ideel til at håndtere de påkrævede opgaver, endog med overkommelig hastighed.

Vi vil gerne kunne understøtte stream type data eks. lyd og grafik til hjælpfiler og dokumentation samt webcam komunikation og møder. Dette vil kun kunne lade sig gøre hvis vi danner attributter i databasen som kan indenholde meget store datablokke, men mener med rette at kunne afgrænse os fra dette i denne version af Pro-Filer.

I det fremtidige system kunne man forestille sig at benytte, en database som var indstillet til effektivt at kunne håndtere disse tunge DPU over net. Dette eks. ved hjælp af et grafisk interface til et xcomponent med den mere upålidelige Protocol UDP.
Denne applikationsnære protocol indenholder næsten kun socket information samt det data som skal overføres og er derfor af mindre komplex opbygning. Forbindelsesløs komunikation skaber hastighed i forhold til de pakker som går tabt og hvis CRC32-biten er sat vil DPU'en ikke bliver retransmiteret.

4.5 - Det som ikke tilhører frameworket

4.5.1 - XWindow

Mostly removed in the online version.

TreeStructureParser

TreeStructureParser

DynamicTreeStructure

4.6 - Hjemmesiden

Mulighederne indenfor hjemmeside design stod os rimeligt åbne. Det eneste vi følte var nødvendigt at inkorporere var ASP til kan udføre nogle minimale ændringer i databasen med hensyn til kunde informationerne og så valgte vi også at benytte det til et rekvirations-formular til at skaffe informationer om hjemmesidens virksomhed (de mere detaljerede informationer om brugen af ASP'en forefindes i afsnittet ASP).

Vi mente det ville være mest fordelagtigt at dele hjemmesiden op i 3 frames. Den første frame valgte vi til at være fremvisningsvinduet til de få sider vi har lavet til hjemmesiden. Frame 1 er også den eneste der har en scrollbar i den situation at det skulle blive nødvendigt.
Frame 2 og 3 er begge statiske, så de forbliver som de er når man ændrer på browserens størrelse. I frame 2 ligger login formen for kunderne af virksomheden. Når kunderne logger korrekt ind her, fremkommer en ASP-side som genererer noget html til fremvisning af de informationer som ASP-koden henter fra databasen. Her kan kunderne så se om informationerne om dem er korrekte og hvis dette ikke skulle være tilfældet, så kan de selv ændre oplysningerne og ved hjælp af submit knappen sende de korrigerede informationer retur til serveren. Udover dette kan kunderne også ændre deres password ved at trykke på Change password knappen. På den efterfølgende side skal kunden så indtaste det gamle password for at kunne ændre det på serveren. Da der ikke er konstant kontakt til serveren, dvs. at der logges på serveren hver gang der benyttes en submit knap og login knappen bliver der oprettet kontakt til db-serveren hentet/sendt informationer og så lukket igen. Derfor skal kunderne ikke tænke på at logge af serveren, de kan bare benytte en af linkene på siden eller skrive en ny url i browserens navigations felt.
Frame 3 som indeholder menuen er ikke noget specielt. den indeholder noget grafik som benyttes som links og intet andet.
Det sidste vi mener er nævneværdigt er at vi bruger stylesheets til at styre baggrunden og skriftens farve. Grunden til dette er at sørge for at have en meget fleksibel hjemmeside, som kan ændre udseende ved kun at lave ændringer relativt få steder i koden. Generelt er hjemmesidens opbygningen naturligvis også meget fleksibel med henblik på ændringer, hvis dette skulle være ønskværdigt, vores udkast er trods alt kun én mulighed ud af mange.

4.6.1 - ASP

På vores hjemmeside har vi jo valgt ASP, som her skal dokumenteres. Flg.: sider indeholder ASP:

login.asp
kunde_info.asp
info_change.asp
psw.asp
pswchange.asp
rek_info.asp


Meget at det, der forklares om den første fil gælder også for de næste, der derfor ikke vil blive forklaret så meget i dybden, hvis tingene er næsten identiske.

login.asp
Filen bliver kaldt af login.html, der indeholder en form, der sender kundeID og password med til asp filen i kaldet. Det første, der så bliver checket er, om der overhovedet er indtastet noget i felterne. Så er der erklæring af variable. Så erklæres og åbnes databaseforbindelsen. Dette gøres via Windows DSN (Data Source Name). Derefter erklæres SQL sætningen, der vælger kunden med det rette ID. Den gemmes i et commandset. Erklæring af et recordset til at indeholde kundens info. Når så recordsettet åbnes det med den kommando, der indeholder SQL sætningen og parametre, der i dette tilfælde angiver cursor type* og lock type**. Hvis det ikke er tomt (der blev fundet en kunde med rigtigt kundeID og password), åbnes en session, der husker kunden. Desuden vil han blive viderestillet til en ny side, hvor han kan ændre sine data. Hvis han ikke eksisterer, bliver han omstillet til en side uden adgang til databasen.

Derefter sættes recordset og commandoset til null og forbindelsen lukkes. Idet Response.buffer er sat til true, bliver der ikke redirected før end hele scriptet er kørt, og vi når derfor at lukke forbindelsen o.s.v.
Og oprettelse af session, der beholder kundens ID så længe kunden skal være logget ind.

Til allersidst er der noget HTML, der stort set bare importerer baggrunden.

* Cursor type:
bestemmer, hvordan records'ne i databasen skal læses. Forwardonly betyder f.eks. at de læses et ad gangen, og at cursoren kun kan bevæge sig en vej - fremad.

** Lock type:
bestemmer hvor meget adgang clienten har til databasen. (read, exe, write). Der skal selvfølgeligt sættes så lidt adgang, som muligt for at opnå mest sikkerhed. Men der ligger jo også meget sikkerhed i databasen, men det giver mulighed for at lægge brugerrettighederne i ASP.

kunde_info:
Her kommer kunden ind, hvis han har indtastet det rigtige ID og password. Her er igen en del HTML kode, hvor kundens info vises i en tabel. Først erklæres variablene, så læses kundeID fra sessionen, så vi kan kigge i rigtigt i databasen efter kundeinfo. Så oprettes forbindelse, commandoset og recordset som i foregående. SQL køres i recordset.open (via cmdDC) og resultatet lægges i variablene. Det hele nedbrydes igen. Nu kan vi bruge variablene til at vise kundens informationer i tabellen. Idet informationen samtidig er i en form, kan vi sende ændringerne videre til den næste side vi vil kalde, hvis kunden beslutter sig for at ændre noget. Det kan også være, at kunden vil ændre password. For at give lidt ekstra sikkerhed, har vi valgt at gøre dette i på en side for sig.

info_change.asp
Kort skitseret sker følgende:
Læsning af kundeID.
Variabler sættes til det, formen (på sidste side) har sendt med.
Dataforbindelse oprettes.
Commandset oprettes.
SQL erklæres (i virkeligheden bare en streng variabel).
commandset sættes til SQL.
Recordset oprettes.
Recordset åbnes(database adgang).
Kunden viderestilles. (Men det sker først til sidst p.g.a. response.buffer = true).
Forbindelse m.m. lukkes ned igen.


psw.asp
Denne fil indeholder hovedsageligt HTML. I en form i en tabel indtastes gammelt og nyt password og nyt password igen. ASP gemmer kundeID, så vi hele tiden har styr på, hvem det er, der taster.
Ved klik på en knap sendes så formen til pswchange.asp siden.

pswchange.asp
Følgende sker:
KundeID hentes.
Dataforbindelse oprettes.
Commandset oprettes og tildeles forbindelse.
SQL erklæres.
Commandset tildeles SQL.
Recordset oprettes og åbnes.
oldpsw variablen sættes.
Kundens password hentes ind i en variabel.
Forbindelse m.m. lukkes igen.
Så checkes om gammelt password er rigtigt indtastet.
Hvis det er rigtigt checkes om nyt password er tastet ens de to gange.
Hvis det er rigtigt sættes ny password variablen.
Forbindelse, commandset og recordset oprettes og sættes med SQL m.m.
Recordset åbnes (SQL køres).
Forbindelsen lukkes ned igen og kunden viderestilles alt efter om han fik indtastet korrekt eller ej.


rek_info.asp
Den sidste side, vi lige har lavet er så den, hvor kunden rekvirerer yderligere information (hvad det så skulle være).
Den bliver kaldt, hvis kunden har udfyldt en re_info.HTML side, hvor der er en form, der videresender kundeoplysninger til ASP siden. Her startes med at putte informationen ind i nogle variable.
Så viser vi kunden, hvad han har sendt os i noget HTML, hvor vi bruger variablerne (vi sender det faktisk først efter HTML'en er vist).
Herefter åbnes en forbindelse, hvor vi lægger kundens oplysninger om sig selv ned i databasen, som en mail fra "WEBMAIL" brugeren. Denne mail skal jo så sendes til en person, der står for, at sende information til kunder.
Forbindelsen nedbrydes igen, og mere er der ikke i det.

4.7 - Anbefalinger

4.7.1 - Edb-systemets nytte

Der er betragtelige fordele tilknyttet vores produkt. Den væsentligste er nok at systemets flytbarhed er platformuafhængigt da givne brugere kan benytte den platform som han/hun er komfortabel med. Den frihed man kan opnå ved hjælp af applet er en massiv fordel da man kunne på et intranet integrere systemet uden problemer. Dog vil vi være forbeholdene med at åbne det udaftil da der er mange sikkerhedsmæssige aspekter der skal overvejes inden dette kan forekomme.

4.7.2 - Ibrugtagningsplan

Dette program er designet til at være let forståeligt, næste at lege sig til produktløsinger, derfor beregner vi en kort indkøringsfase i bruger organisationen.
Et kursus til PServ administratoren vil dog være at foretrække da denne person vil være bære et ansvar for systemets brugbarhed(??lidtmere).

4.7.3 - Realiseringsplan

Udviklingsøkonomi
Da dette er et skoleprojekt kan projektet bære præg af tanker under udvikling og ikke så meget et business projekt. Pro-filer har ingen pr-ansatte eller planlagte reklamekampanger. Dog stiler vi mod et udfærdiget produkt eller ihvert tilfælde en højversion prototype.

Strategi
Selve tekstformateringen af dokumenter til firmastandarder vil, med fordel, blive håndteret i et eksternt system. Dette vil gøre produktet nemmere at vedligeholde samt åbne mulighed for at importere nye standarder uden at skulle ændre i selve PServ. Der er flere mulige løsningsmodeller til dette men XML's DTD struktur har en lovende fremtid. Desuden har IBM lavet et udemærket framework til parsing af dette.
Et hård klient til PServ vil måske kunne forbedre det sikkerhedsmæssige aspekt men dette ville kræve en yderligere analyse af PServ-protokollen samt et betragtelig arbejde med implementering af tilfredstillende klient.

4.8 - Delkonklusion

Efter at have gennemløbet designdelen må man komme til den generelle konklusion, at vi har tænkt mere på at kunne videreudvikle, end at få en prototype, som kan vise noget p.t. For at få noget godt, at videreudvikle på, har vi sørget for, at få det grundlæggende optimeret og godt virkende (PKernel). Vi har valgt at bygge grundstrukturen op omkring PKernel både til serveren og klienten. De deler altså samme 'grundklasse'. Dette giver mange fordele. Fra start, når vi koder, skal det kun gøres et sted, og i fremtiden vil det være langt lettere at opdatere og vedligholde, når det kun skal gøres i Kernelen. Men det bevirker samtidigt, at en server eller klient skal 'slukke' for nogle services, der ligger i kernelen. Derved kan man sige, at ulempen er, at der altid vil være nogle overflødeige 'services', som optager plads. Dette bevirker også, at der skal downloades nogle flere kilobytes til appletten. Men dette er den eneste umiddelbare ulempe, har vi vurderet, at disse ekstra kilobytes er for få, til at lave et andet design. Det vi er kommet frem til, er altså et fremtidssikret og udbygningsnemt design, det kræver dog en del mere kodning, for at få ordentlig klient funktionalitet.

5 - Implementering

Gruppe5 har, i den seneste tid, holdt en række uformelle interne møder hvor vi har overvejet struktur samt har skabt os et samlet overblik over det givne stadie vores produkt har nået. Disse overvejelser har resulteret i af selve implementeringen overvejende er blevet centreret om en skalerbar Kernel.
Det er både fordele og ulemper ved dette valg af fokus.
Fordele :

• Systemet har større chance for at være en skalerbar sucess.
• Dette valg har fremhævet Multi-tier og derved komponentopdelingen.
• Der foreligger mulighed at skrædersy vores system til en vilkårlig virksomhed.
• Vi har lært en masse socket programmering.

Ulemper :

• HIC'en er ikke vægtet særligt højt og derfor har en 'uvildig bruger' svært ved at se systemet som en helhed.

IT-Implementering

Mål : Vores mål var, da vi startede på dette projekt, at få udfærdiget en 'skal', der var for os funktionsdygtig. Dette kriterie mener vi at have nået da vi har mulighed at kommunikere, på et for os acceptabelt niveau, med PServ via. telnet til en database.

Problemopfattelse : Vores opfattelsen af den enkelte virksomhed som udgangspunkt har ændret sig til en opfattelse af det samlede forretningssystem fra leverandører, virksomheden og dets partnere og den endelige kunde. Denne opfattelse taget til eftertanke mente vi at det vigtigste, for vores produkt, var en så fleksibel udvidelses-specificerings faktor samt denne skulle være så simpel så mulig.

Middel :

• Gode arbejdsvaner samt en stor kop digital kaffe.

Evaluering : Vi ville gerne have nået at udvikle noget mere HIC-funktionalitet men dette blev tilsidesat da vi mente det var vigtigere at holde rapport samt design konsistent. Vi har også provet at undgå 'spagettiekode' i selve kernel for netop at fremtids sikre denne del.

Fremtid : Vi har en ide om at Pro-Filer kunne være grundlag for en fremtidig virksomhed. For dette kan lade sig gøre er det vigtigt at fastsætte nogle langsigtede rettningslinjer for fremtidig udvikling. Vi taler her om Pro-Filer's produktionskoncepter som "Mass Customization", der muliggør masseproduktion af kundeindividuelle produkter, eller "Agile Manufacturing" der kan opfattes et som konfigurerbart produktionssystem.
Pro-Filer sætter samtidigt nye standarder for logistiksystemts effektivitet både med hensyn til omkostninger og tid, og krav om uhørt fleksibilitet over for kundekrav med hensyn til varianter og nye produkter.

En ny strategi og koncept for produktion i netværk.
Vores fremtidige projekt har et anvendelsesorienteret sigte, og derfor tænkes projektet gennemført med udgangspunkt i et samarbejde med 2-4 industrivirksomheder over ca.3-4 mandeår. Alternativt kunne projektet etableres som et tæt samarbejde med en enkelt virksomhed og som kandidat hertil ville det jo være passende at iværksætte en kommunikation til vores oprindelige opdragsgivere Simens Danmark.

Rettelser til analyse: n..m omkostning

6 - Konklusion

Hvad er vi så kommet frem til efter disse seks ugers projekt forløb? Er projektet alt det vi har forventet? Har vores produkt, efter vores egen mening, en god anvendelsesmulighed ved projektudvikling og dokumentstyring i større såvel som mindre virksomheder?
De sidste 2 spørgsmål må vi svare ja til. Ikke kun er vores mål blevet mere opnåelige på en mere langsigtet plan, men vi er også blevet mere sikre på, at vores visioner har mulighed for at blive udlevet.
Hvis vi lige skal tænke på projektudviklingsarbejdet, har vi atter engang måtte 'bide i det sure æble' og indse at papirarbejdet er en meget stor og vigtig del af system udvikling af simple såvel som meget inviklede systemer. Det er nødvendigt, fordi der er mange forskellige mennesker, der arbejder på den samme helhed. Men det er især vigtigt, fordi udviklingsarbejde af denne art, indeholder mange detaljer, som man skal bruge gennem hele forløbet og det kræver, at man skal skrive det ned i en så forståelig form, at andre personer som bliver sat til at arbejde med dette, hurtigt og nemt kan få overblikket over det. Derud over kan de større projekter nemt strække sig over flere år og uden nogen form for dokumentation ville det være umuligt at gennemføre.
Tidsplanlægning er, som vi også måtte erfare på 2. semester, en af de vigtigste holdepunkter ved projektarbejde. Som navnet selv siger planlægges alle faser i et projekt, så godt som det nu kan være muligt, efter som det er kvalificerede gæt. Grunden til at vi kalder det kvalificerede gæt, er simpelthen at man på ingen måde kan vide hvor lang tid de forskellige faser vil vare. Der vil altid komme opgaver hen af vejen som vil foresage forsinkelser. En ting man skal tage i betragtning er dog, at jo mere erfaring man har med projektarbejde, det bedre vil man normalt være til at skønne fasernes længde.
Alt taget i betragtning, inklusive det at vi færdedes i et ungt miljø med en uformel omgangstone, mener vi, at det har det været et meget vellykket projekt, selvom vi har nedprioriteret programmeringsdelen.