Der har ikke været nogle faste retningslinjer for at sikrer kvaliteten i projektet. Det skal dog ikke forstås sådan at kvalitetsstyringen har været svævende, tværtimod. Projektgruppens medlemmer har pr. definition et højt kvalitetsniveau, og er bl.a sat sammen udfra dette kriterie. Derudover har projektgruppen arbejdet sammen før på tidligere projekter, og kender derfor hinandens arbejdsmetoder.
Det har ikke været nødvendigt med en stram styring af projektet, da projektgruppen kun består af to medlemmer, som har arbejdet meget tæt sammen. Projektgruppens tætte samarbejde har bevirket at opståede uklarheder og uoverensstemmelser er blevet taget hånd om i tide, inden det evt. kunne have fået katastrofale konsekvenser for projektet. Såsom spildt arbejde og at projektplanen skrider, hvilket kan medfører brandslukning, der jo bestemt ikke er sundt for et projekt.
Det er endvidere meget ressourcekrævende at opretholde en stram kvalitetsstyring, og da gruppen, som sagt, kun består af to medlemmer er dette nedprioriteret. Begrundelsen for dette er det i forvejen meget høje kvalitetsniveau blandt gruppens medlemmer og det tætte samarbejde.
Internt i projektet er kvalitetsstyringen foregået på den måde, at hvert projektmedlem har gennemlæst og godkendt hvad den anden har udarbejdet, inden endelig godkendelse. Dette har været en naturlig del af gruppens daglige arbejde, og har betydet at projektets fokus/høje-kvalitet hele tiden er blevet holdt.
For at sikrer sporbarheden gennem hele projektet og mellem de forskellige faser, har der været en løbende gennemgang af udarbejdede dokumenter og modeller. Dette har betydet at eventuelle uoverensstemmelser mellem dokumenter og modeller er blevet fanget tids nok til ikke at få indvirken på den videre udvikling, hvilket kunnet have kostet mange ressourcer, hvis der havde været arbejdet videre ud fra et forkert grundlag.
Eksternt er kvaliteten i projektet blevet styret ved afholdelse af reviews med vores vejleder Jørgen Karrebæk. Endvidere er et møde med andre projektgrupper, der arbejder med samme teknologier som os, blevet afholdt for at give et indblik i hvad de andre laver, og samtidigt virkede det som et forum hvor eventuelle mangler eller uhensigtsmæssighedder kunne opdages og tages til efterretning. Ved også at få nogle andre øjne på, var en rigtig god måde at sikre kvaliteten på.
I samarbejde med vores kontaktpersoner os Oracle Danmark, er kvaliteten også løbende blevet sikret ved afholdelse af møder og diverse uformelle møder. Dette har gjort at vi hele tiden har kunnet holde os på sporet, og unødigt tidspild er blevet undgået.
Vi synes selv at dette har været en meget fornuftig måde at sikrer kvaliteten på, hvilket vores projekt da også er et bevis på. Nogle helt klare retningslinjer er dog blevet sat:
Alle dokumenter skrives i html-format, så de kan offentliggøres på projektets web-site. Der tillades kun simple html-tags: P, BR, UL, OL, LI, H1, H3, IMG, TABLE, TR, TD. Alle effekter lægges på i stylesheet, så der ikke skal være argumenter i de enkelte tags. Layoutet til papir-versionen lægges på i den afsluttende fase, og vil følge det specificerede stylesheet.
Der oprettes en seperat fil for hvert enkelt afsnit. Der oprettes en mappe for hver fase, og undermapper oprettes efter behov, løbende.
Der tages backup jævntligt i form af en zip-fil for hele projekt-kataloget. Backuppen flyttes til en anden computer.
Følgende regler skal overholdes når der programmeres, for at opnå en ensartet source-code.