TDT4290 Kundestyrt Prosjekt Gruppe 10 - Bouvet Høsten 2005

Transkript

1 TDT4290 Kundestyrt Prosjekt Gruppe 10 - Bouvet Høsten 2005 NTNU Norges teknisk-naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap

2

3 Forord Dette dokumentet er rapporten til gruppe 10 i faget TDT Kundestyrt Prosjekt ved Institutt for Datateknikk og Informasjonsvitenskap (IDI) ved Norges teknisk-naturvitenskapelige universitet (NTNU) høsten Prosjektoppgaven ble tildelt av den Oslo-baserte bedriften Bouvet AS, representert ved Andreas R. Johnsen og Tom Bech. Målet med oppgaven har vært å utvikle et program for automatisk kategorisering av dokumenter. Dersom programmet gir gode resultater, ønsker Bouvet å knytte det til sitt eksisterende publiseringsverktøy. Gruppen ønsker å rette en stor takk til hovedveileder stipendiat Lillian Hella og hjelpeveileder Tarjei Lægreid for svært verdifull hjelp og støtte. Vi vil også takke kundens representanter, Andreas R. Johnsen og Tom Bech, for et godt samarbeid. Til slutt vil vi takke venner, kjærester og familie for deres tålmodighet i et semester der mye tid har gått til prosjektarbeid. Trondheim, 23. november 2005 Tarjei Kvamme Løset Ole Kristian Mørch-Storstein Martin Andreas Børke Rune Vistnes Knut Auvor Grythe

4

5 Innhold I Prosjektdirektiv 1 II Forstudium 53 III Kravspesifikasjon 111 IV Konstruksjon 147 V Implementasjon 177 VI Testdokumentasjon 217 VII Brukerdokumentasjon 255 VIII Evaluering 279 i

6

7 Del I Prosjektdirektiv 1

8 2

9 INNHOLD Innhold 1 Innledning Hensikt Omfang Oversikt Prosjektmandat Prosjektnavn Prosjektsponsor Forretningsidé og ambisjon Interessenter Bakgrunn for prosjektet Effektmål Resultatmål Prosjektets omfang Rammebetingelser Økonomi Tid Prosjektplan Utviklingsmodell Fasenes innhold Planlegging Forstudium Kravspesifikasjon Konstruksjon Programmering og dokumentasjon Test Prosjektvurdering Presentasjon og demonstrasjon Faste aktiviteter

10 INNHOLD Prosjektledelse Forelesninger og egenlæring Tid per aktivitet Organisering Prosjektleder og kundekontakt Dokument- og kvalitetsansvarlig Research-ansvarlig Teknisk ansvarlig og systemarkitekt Testleder Maler og standarder Maler Standarder Katalogstruktur Navngiving av filer Versjonskontroll 25 7 Prosjektoppfølgning Internmøter Veiledermøter Kundemøter Intern rapportering Timeføring Aktiviteter - utført og gjenstående Milepæler - nådde og ikke nådde Statusrapportering TROKK Tid Risiko Omfang Kostnad Kvalitet

11 INNHOLD 8 Kvalitetssikring Responstider Rutiner for å produsere kvalitet første gang Rutiner for godkjenning av fasedokumenter Møteinnkalling til kunden Møtereferat fra kundemøte Møteinnkalling til veileder Agenda til veiledermøtene - mal som skal følges Møtereferat fra veiledermøter A Interessenter 32 A.1 Kunderepresentanter A.2 Veiledere A.3 Prosjektgruppe B Ansvarsfordeling 34 B.1 Ansvarsfordeling i planleggingsfasen B.2 Ansvarsfordeling i forstudiet B.3 Ansvarsfordeling i kravspesifikasjonen B.4 Ansvarsfordeling i konstruksjonsfasen B.5 Ansvarsfordeling i programmerings- og dokumentasjonsfasen B.6 Ansvarsfordeling i testingen B.7 Ansvarsfordeling i prosjektvurderingen B.8 Ansvarsfordeling i presentasjon- og demonstrasjonsfasen C Maler 42 C.1 Mal for møteinnkallelse C.2 Mal for møtereferater C.3 Mal for statusrapporter C.4 Webgrensesnitt for timeregistrering C.5 Skjema for føring av timeregnskap D Risikotabell 48 E Grafisk fremstilling av prosjektplan 50 F Definisjoner og forkortelser 51 5

12 6 INNHOLD

13 FIGURER Figurer 3.1 Prosjektets faser representert med modifisert vannfallsmodell Organisasjonskart

14 8 FIGURER

15 TABELLER Tabeller 3.1 Planlagt tid per aktivitet

16 10 TABELLER

17 Kapittel 1 Innledning Dette kapittelet inneholder en kort oversikt over prosjektdirektivet til gruppe 10 i faget TDT4290 Kundestyrt Prosjekt høsten The plan is nothing; the planning is everything. Dwight Eisenhower 1.1 Hensikt Prosjektdirektivet er et dynamisk dokument som vil bli oppdatert gjennom hele prosjektets levetid. Dette dokumentet regulerer den administrative delen av prosjektet og vil fungere som en veiledning for prosjektgjennomføringen. Målgruppen for prosjektdirektivet vil være prosjektgruppen. 1.2 Omfang Prosjektdirektivet vil dekke de administrative aspektene ved prosjektgjennomføringen. Endringer i planer og tidsfrister skal alltid oppdateres i dette dokumentet. 11

18 KAPITTEL 1. INNLEDNING 1.3 Oversikt Resten av dette prosjektdirektivet er delt inn i følgende kapittel og vedlegg: Kapittel 2 definerer prosjektets mål og rammebetingelser. Kapittel 3 beskriver prosjektets faser og aktiviteter. Kapittel 4 beskriver rollefordelingen i prosjektet. Kapittel 5 inneholder krav til struktur og standarder som skal følges av prosjektgruppen. Kapittel 6 beskriver hvordan versjonskontroll skal ivaretas. Kapittel 7 beskriver rutiner for oppfølging av utført og planlagt arbeid. Kapittel 8 beskriver hvordan kvalitetssikring skal ivaretas. Vedlegg A inneholder en oversikt over interessenter. Vedlegg B inneholder ansvarsfordeling i de forskjellige fasene av prosjektet. Vedlegg C inneholder dokumentmaler. Vedlegg D inneholder en tabell med risikoer. Vedlegg E inneholder en grafisk fremstilling av prosjektplanen. Vedlegg F inneholder en liste med forkortelser og definisjoner av ord benyttet i dokumentet. 12

19 Kapittel 2 Prosjektmandat Dette kapittelet definerer prosjektets mål, omfang og rammebetingelser. 2.1 Prosjektnavn Prosjektets arbeidstittel er Automatisk klassifisering 1 av dokumenter i emnekart ved bruk av latent semantisk indeksering (LSI). Programmets navn vil være PaperPrism. På samme måte som et prisme splitter lyset i fargekategorier, skal PaperPrism dele opp dokumentene i kategorier. Gruppen mener derfor at PaperPrism er et passende navn for programmet. 2.2 Prosjektsponsor Prosjektets sponsor er Bouvet AS. Bouvet er et konsulentselskap med nærmere 200 ansatte, som gjennomfører prosjekter innenfor informasjons- og kommunikasjonsteknologi. De er et av landets største og mest aktive konsulentmiljøer innen portaler og publiseringsløsninger bygget over standarden ISO13250 Emnekart Forretningsidé og ambisjon I samarbeid med sine kunder skal Bouvet skape muligheter og forbedre prosesser ved hjelp av nye ideer og ny teknologi. Bouvets ambisjon er å være det mest troverdige konsulentselskapet med de mest fornøyde kundene og medarbeiderne i Norge. 1 Selv om tittelen på prosjektet benytter begrepet klassifisering, har gruppen i samarbeid med kunden kommet frem til at kategorisering er et mer dekkende begrep for prosjektet. Gruppen vil derfor heretter benytte ordet kategorisering. 13

20 KAPITTEL 2. PROSJEKTMANDAT 2.3 Interessenter Prosjektets interessenter står oppført i vedlegg A. 2.4 Bakgrunn for prosjektet Det har vist seg svært krevende for redaksjoner å vedlikeholde emnekart. Det er opp til forfatteren å koble en artikkel til ett eller flere emner. Dette er tidkrevende, og krever også at brukeren har full oversikt over artikkelen og taksonomien som benyttes. Resultatet er ofte at artikler ikke blir registrert med riktig emne, eller at emner blir utelatt. Kvaliteten på emnekartene på nettstedet kan derfor til tider bli mindre tilfredsstillende. 2.5 Effektmål Presisjon og kompletthet blir brukt som effektmål ved kategoriseringen av dokumenter. Med presisjon menes forholdet mellom antall relevante emner og det totale antall emner i søkeresultatet. Kompletthet er forholdet mellom antall relevante emner i søkeresultatet og det totale antall relevante emner. Ved måling av presisjon og kompletthet brukes manuelt kategoriserte dokumenter som fasit. Kompletthet blir sett på som mer kritisk enn presisjon i denne sammenhengen. En høy grad av kompletthet kan gå utover presisjonen til søkeresultater. Å redusere tiden det tar å søke etter relevante emner er et sekundært mål, som tilstrebes innfridd etter at de øvrige målene er nådd. 2.6 Resultatmål Resultatet av prosjektet skal være en prototyp av et program for automatisk kategorisering av dokumenter i emnekart. Programmet skal kunne ta inn rådata i form av en dokumentsamling, og analysere denne i forhold til en eksisterende taksonomi. Det skal også kunne ta inn et enkelt dokument, og gi forslag til relevante emner for dette dokumentet. 2.7 Prosjektets omfang Gruppen skal finne en løsning for automatisk kategorisering av dokumenter. Løsninger basert på algoritmen LSI skal i utgangspunktet undersøkes, men andre potensielle ferdigløsninger skal også vurderes. Videre skal det i prosjektet imple- 14

21 KAPITTEL 2. PROSJEKTMANDAT menteres en fungerende prototyp av programmet, og en detaljert prosjektrapport skal utarbeides og fremlegges. 2.8 Rammebetingelser Prosjektet har følgende rammebetingelser: Gruppen består av fem personer. Prosjektrapporten skal skrives på norsk. Da gruppen ikke har et reisebudsjett, vil den ikke ha anledning til å besøke kunden. Kunden har anledning til å besøke gruppen høyst fire ganger. 2.9 Økonomi Faget TDT4290 Kundestyrt Prosjekt har en studiebelastning på 15 studiepoeng, eller 310 timer per student. Gruppen har derfor et budsjett på totalt 1550 timeverk. Inkludert i dette budsjettet er et seminar i gruppedynamikk samt to fagdager Tid Prosjektet startet og avsluttes med presentasjon for kunden

22 Kapittel 3 Prosjektplan Dette kapittelet inneholder de fasene prosjektet er delt opp i, og hva de innebærer. En fase avsluttes når fasedokumentet er godkjent. Kapittelet inneholder også en beskrivelse av de aktivitetene som ikke er egne faser, men som allikevel utgjør en betydelig del av arbeidet som legges i prosjektet. 3.1 Utviklingsmodell Figur 3.1: Prosjektets faser representert med modifisert vannfallsmodell Figur 3.1 viser en modifisert utgave av vannfallsmodellen. Denne viser hvordan de forskjellige fasene i prosjektet er avhengige av hverandre, og hvordan en nådd milepæl fører prosessen over i neste fase. Modellen er modifisert i forhold til normale konvensjoner, ved at fasene prosjektvurdering og presentasjon og demo er lagt til, samt at det introduseres en tilbakekobling mellom enkelte faser. Modellen tar hensyn til at programvareutvikling svært sjelden foregår lineært. Faser som overlapper hverandre tidsmessig i prosjektplanen vil foregå i paral- 16

23 KAPITTEL 3. PROSJEKTPLAN lell. Piler som peker bakover illustrerer risiko for å måtte gå tilbake for å gjøre endringer. 3.2 Fasenes innhold Prosjektet er delt opp i åtte faser, og alle fasene vil ha egne fasedokumenter. Vedlegg E viser en grafisk fremstilling av hvordan disse fasene planlegges utført. Alle fasedokumentene, samt annen dokumentasjon for prosjektet, vil til sammen utgjøre sluttrapporten som gruppen vil overlevere sensoren, fagstaben og kunden. Ved oppstarten av hver fase vil det utarbeides en detaljert plan over arbeidspakker som skal utføres i fasen. Disse planene skal inkluderes i dette prosjektdirektivet fortløpende Planlegging Start: Slutt: Den største oppgaven innen planlegging vil være utformingen av prosjektdirektivet. Gruppen vil her måtte ta flere viktige valg, deriblant: Fordeling av roller og ansvar. Utarbeiding av maler og standarder. Valg av metoder for versjonskontroll. Rutiner for prosjektoppfølging og kvalitetssikring. Oppdatering av prosjektdirektiv. For en oversikt over arbeidspakkene i denne fasen, se vedlegg B Forstudium Start: Slutt: I denne fasen skal gruppen få en bedre forståelse for domenet oppgaven er innenfor. Gruppen skal her innhente relevant informasjon om mulige løsninger, og evaluere disse ut fra kundens kriterier. For en oversikt over arbeidspakkene i forstudiet, se vedlegg B.2. 17

24 KAPITTEL 3. PROSJEKTPLAN Kravspesifikasjon Start: Slutt: I denne fasen defineres funksjonelle og ikke-funksjonelle krav. I tillegg skal kravspesifikasjonen stille krav til brukerdokumentasjon, programmeringsdokumentasjon og installasjonsdokumentasjon. For en oversikt over arbeidspakkene i kravspesifikasjonfasen, se vedlegg B Konstruksjon Start: Slutt: I denne fasen skal det lages realiserbare spesifikasjoner basert på en overordnet systembeskrivelse. Spesifikasjonene skal definere kodemoduler, dataflyt og algoritmer. Den skal også gi et overordnet design av brukergrensesnittet mot programmet. For en oversikt over arbeidspakkene i konstruksjonsfasen, se vedlegg B Programmering og dokumentasjon Start: Slutt: I denne fasen skal systembeskrivelsen implementeres. Det er viktig at programmeringsstandarden og standard for kommentering av koden er fastsatt før selve programmeringen starter. Implementasjonen skal dokumenteres i et eget fasedokument. I tillegg skal det utarbeides brukerveiledning som skal kunne benyttes av kunden. For en oversikt over arbeidspakkene i denne fasen, se vedlegg B Test Start: Slutt: Denne fasen vil bestå av utarbeidelse, gjennomføring og godkjenning av de testene som skal utføres. Det skal produseres en overordnet testplan, samt detaljerte testplaner. Alle krav fra kravspesifikasjonen skal være testet i minst én test. Når fasen er ferdig, skal det foreligge et eget fasedokument som også inkluderer resultatet av samtlige tester. For en oversikt over arbeidspakkene i denne fasen, se vedlegg B.6. 18

25 KAPITTEL 3. PROSJEKTPLAN Prosjektvurdering Start: Slutt: I denne fasen evalueres de ulike delene av prosjektet. Evalueringen skal omfatte både prosjektets gang, resultatet og hva som eventuelt gjenstår for å kunne bruke resultatet. For en oversikt over arbeidspakkene i denne fasen, se vedlegg B Presentasjon og demonstrasjon Start: Slutt: Dette er den siste fasen i prosjektet. Her skal gruppen forberede og gjennomføre selve presentasjonen og demonstrasjonen av produktet for kunden og fagstaben. For en oversikt over arbeidspakkene i denne fasen, se vedlegg B Faste aktiviteter I tillegg til fasene, har prosjektet faste aktiviteter som må følges opp Prosjektledelse Start: Slutt: Prosjektledelsen vil foregå gjennom hele prosjektet, og består av: Rutinemessig organisatorisk virksomhet (for eksempel referatskriving). Distribusjon og koordinasjon av oppgaver. Interne gruppemøter, veiledermøter og kundemøter Forelesninger og egenlæring Start: Slutt: Egenlæringen vil foregå gjennom hele prosjektet. Dette skyldes at gruppen har lite erfaring med store deler av verktøyene som skal benyttes, og derfor må bruke en del tid på å sette seg inn i disse. 19

26 KAPITTEL 3. PROSJEKTPLAN 3.4 Tid per aktivitet Tabell 3.1 viser hvordan gruppen planlegger å fordele timebudsjettet på de forskjellige fasene. Tabell 3.1: Planlagt tid per aktivitet Aktivitet Tid Andel Prosjektledelse: 223 timer 14% Forelesninger og egenlæring: 184 timer 12% Planlegging: 110 timer 7% Forstudium: 260 timer 17% Kravspesifikasjon: 125 timer 8% Konstruksjon: 70 timer 5% Programmering og dokumentasjon: 284 timer 18% Test: 170 timer 11% Prosjektvurdering: 46 timer 3% Presentasjon og demo: 78 timer 5% 20

27 Kapittel 4 Organisering Dette kapittelet inneholder en beskrivelse av rollefordelingen til gruppen. Gruppehierarkiet er visualisert i figur 4.1. Figur 4.1: Organisasjonskart 4.1 Prosjektleder og kundekontakt Ansvarlig: Ole Kristian Mørch-Storstein Som prosjektleder og kundekontakt er Ole Kristian ansvarlig for å: Lede prosjektgruppen til et ferdig resultat innen tidsfristen. Delegere oppgaver. Innkalle til møter. Opprettholde god informasjonsflyt mellom gruppen og kunden. Løse konflikter som kan oppstå innad i gruppen eller mellom gruppen og bedriften. 21

28 4.2 Dokument- og kvalitetsansvarlig KAPITTEL 4. ORGANISERING Ansvarlig: Martin Andreas Børke Som dokument- og kvalitetsansvarlig er Martin ansvarlig for å holde orden på prosjektdokumentene. Han er også ansvarlig for å lage maler og forsikre seg om at disse blir brukt. 4.3 Research-ansvarlig Ansvarlig: Rune Vistnes Som research-ansvarlig er Rune ansvarlig for å finne relevant informasjon og bakgrunnsmateriale. 4.4 Teknisk ansvarlig og systemarkitekt Ansvarlig: Knut Auvor Grythe Som systemanalytiker og arkitekt er Knut Auvor ansvarlig for å: Legge til rette tekniske løsninger for prosjektarbeidet. Strukturere koden og forsikre seg om at denne strukturen følges. Kontrollere at koden holder tilfredsstillende teknisk kvalitet. Kontrollere at koden er lett forståelig og intuitiv. 4.5 Testleder Ansvarlig: Tarjei Kvamme Løset Som testleder er Tarjei ansvarlig for at testplaner og testspesifikasjon blir laget. Han er også ansvarlig for at testingen foregår som planlagt. 22

29 Kapittel 5 Maler og standarder Gruppen har utarbeidet et sett med maler som skal følges for rapporter, referater og innkallinger. På denne måten forenkles arbeidet for den som skal skrive disse dokumentene, samtidig som det gir en bedre oversikt for alle interessenter. 5.1 Maler I vedlegg C ligger det maler for: møteinnkalling til kunder og veiledere (figur C.1). møtereferater til kunder og veiledere (figur C.2). statusrapporter til veiledere (figur C.3). 5.2 Standarder Dette prosjektet vil etter hvert bestå av en stor mengde dokumenter. Det er derfor essensielt å ha en oversiktlig standard for katalogstruktur og navngiving av filer Katalogstruktur Gruppen har opprettet et hjemmeområde på filtjeneren ved NTNU. Hjemmeområdet ligger under stien /home/groups/kpro. Det har blitt avklart internt at alle filer som hører inn under prosjektet skal legges i denne katalogen, slik at ingen filer blir gjenglemt på lokale maskiner eller private hjemmeområder. På gruppeområdet er det opprettet et CVS-tre for fasedokumenter og kildekode. Disse ligger i hver sin katalog, og videre underkataloger opprettes der det vurderes som nødvendig. 23

30 KAPITTEL 5. MALER OG STANDARDER Navngiving av filer Filnavnet til møteinkallinger, møtereferater og statusrapporter skal starte med den tilhørende datoen i ISO-format. Eksempel: _referat.doc. Fasedokumentene skrives i L A TEX, og deles opp i én fil for hvert kapittel. Filene navngis etter overskriften på kapittelet. 24

31 Kapittel 6 Versjonskontroll Det vil i løpet av prosjektet bli opprettet et stort antall filer som flere brukere skal jobbe mot samtidig. Det er derfor viktig å ha et system som hindrer inkonsistens i disse filene allerede fra starten av. I tillegg vil gruppen basere seg på NTNUs daglige backupløsning for å hindre at disse filene går tapt. All data som endres underveis i prosjektet skal være under versjonskontroll. Dette vil i praksis si all kildekode, fasedokumentene og sluttrapporten. Dokumenter som ikke trenger å versjonskontrolleres er de mindre dokumentene, som for eksempel møteinnkallinger, referater og tredjepartsdokumenter. Ved bruk av CVS er det mulig å sammenligne dokumenter og kildekode med eldre utgaver, både for å kartlegge endringer og for å kunne rulle tilbake ved feil. Det er også mulig for flere personer å jobbe med den samme filen samtidig, hvilket er en stor fordel i dette prosjektet. 25

32 Kapittel 7 Prosjektoppfølgning For å sikre fremdriften i prosjektet er det satt opp rutiner for oppfølgning av utført og planlagt arbeid. Gruppen har opprettet en hjemmeside på adressen der informasjon om møter og viktige tidspunkter blir lagt ut. 7.1 Internmøter Internmøter avholdes mandager klokken 12:15-13:00, samt fredager klokken 12:15-13:00. Møtene blir avholdt på rom ITV458. Mandagsmøtene skal i hovedsak benyttes til å legge en detaljert plan for uken, samt å kartlegge status for fremdriften. Fredagsmøtene skal benyttes til oppsummering, samt diskusjon av problemer som eventuelt har oppstått. 7.2 Veiledermøter Møte med hoved- og hjelpeveileder blir avholdt hver onsdag klokken 13:15-14:00 på rom ITS222. Innkalling til disse møtene følger innkallelsesmalen i C Kundemøter Da kunden har tilholdssted i Oslo, er det ytret ønske om å begrense antallet møter til 3-4 møter i løpet av semesteret. Tidspunkter for disse møtene blir avklart underveis, og innkalling følger innkallelsesmalen i C.1. 26

33 KAPITTEL 7. PROSJEKTOPPFØLGNING 7.4 Intern rapportering Aktiviteter, fremgang og timeforbruk skal loggføres. Et kort sammendrag sendes ukentlig til prosjektleder Timeføring Gruppemedlemmene skal selv sørge for å rapportere antallet timer de har brukt på prosjektet hver uke. En prosjektuke regnes fra klokken 00:00 natt til mandag, til klokken 23:59 søndag kveld. Registreringen av timer gjøres individuelt via webgrensesnittet vist i vedlegg C.4. Prosjektleder fører i starten av hver uke inn timene fra foregående uke i skjemaet for timeregnskap. Dette skjemaet leveres ukentlig sammen med statusrapporten til veilederne Aktiviteter - utført og gjenstående Timene skal føres på de respektive aktivitetene. Aktivitetene vil representere fasene i prosjektet. Prosjektleder skal med hjelp av de andre gruppemedlemmene estimere hvor mye som står igjen av aktivitetene Milepæler - nådde og ikke nådde På mandagsmøtene rapporteres det hvorvidt gruppen har nådd tidsfristen for de aktuelle milepælene. Dersom en milepæl ikke er nådd, skal det utarbeides en plan for hva kan gjøre for å bedre situasjonen. 7.5 Statusrapportering Statusrapporter skal utarbeides i forbindelse med veiledermøtene, og skal sendes med møteinnkallelsen til veiledere. Statusrapportene skal inneholde utført arbeid i perioden, TROKK (se kapittel 7.6), hvilke problemer/hindringer som har oppstått, og planlagt arbeid for neste periode. Mal for statusrapportene ligger vedlagt i vedlegg C.3. 27

34 KAPITTEL 7. PROSJEKTOPPFØLGNING 7.6 TROKK TROKK står for Tid, Risiko, Omfang, Kostnad og Kvalitet. Disse faktorene skal vurderes internt på mandagsmøtene, slik at de kommer med i statusrapporten til veilederne Tid Det skal vurderes hvordan gruppen ligger an i prosjektet rent tidsmessig, og da spesielt med fokus på milepæler. Her skal den tiden som er brukt vurderes opp mot den opprinnelige tidsplanen Risiko De aktuelle risikoer er samlet i en risikotabell. Denne tabellen oppdateres fortløpende under prosjektets fremdrift. Risikoer som ikke lenger er aktuelle kan fjernes fra tabellen som sendes med statusrapport, men kan gjerne forbli stående i risikotabellen i prosjektdirektivet. Nye risikoer som oppdages skal legges til i tabellen. Risikotabellen er gitt i vedlegg D Omfang Dersom omfanget av prosjektet endres fra definisjonen i kapittel 2.7, for eksempel ved at nye krav kommer til, skal dette tas med i statusrapporten Kostnad I dette prosjektet er den aktuelle kostnaden antall timer brukt. Prosessen rundt timeføring er beskrevet i Kvalitet Under dette punktet skal det dokumenteres hvorvidt det er faktorer som fører til at produktets kvalitet må reduseres i forhold til den opprinnelige planen. Aktuelle faktorer kan være at vanskelighetsgraden er for høy, at tiden ikke strekker til eller at deloppgaver ikke lar seg løse innenfor de planlagte rammene. 28

35 Kapittel 8 Kvalitetssikring Kvalitetssikringen i dette prosjektet skal sikre at samarbeidet mellom gruppen og kunden foregår på en mest mulig effektiv måte. Den skal også sørge for at kundens implisitte og eksplisitte krav tilfredsstilles på best mulig måte. 8.1 Responstider Følgende responstider er avtalt med kunden : Godkjenning av tilsendt referat fra kundemøte: én virkedag. Tilbakemelding på fasedokumenter til gjennomsyn: to virkedager. Godkjenning av fasedokumenter: to virkedager. Besvaring av spørsmål: én virkedag. Anskaffing av avtalte dokumenter/kode: to virkedager. Det er også avtalt følgende responstider internt i gruppen: Respons på møteforespørsel: 24 timer. Godkjenning av dokument: 24 timer. 8.2 Rutiner for å produsere kvalitet første gang For å produsere kvalitet fra første stund, skal alle fasedokumenter gjennomgå en fast rutine. Før et dokument leveres inn til godkjenning hos veiledere, skal det godkjennes internt i gruppen. Én person leser gjennom hele dokumentet og ser etter feil og uklarheter, samt kontrollerer at dokumentet blir helhetlig. Denne personen er ansvarlig for at dokumentet har god kvalitet innen levering. All skrevet kode skal godkjennes av minst én person i tillegg til den som har skrevet koden. 29

36 KAPITTEL 8. KVALITETSSIKRING 8.3 Rutiner for godkjenning av fasedokumenter Aktuelle fasedokumenter skal legges ved innkallingen til veiledermøtet, slik at veilederne kan lese gjennom det. En fase anses som ferdig når veilederene har godkjent fasedokumentet. Veilederene gir tilbakemelding på selve møtet på hvorvidt dokumentet er godkjent. Dersom det ikke er godkjent gir veiledere konstruktiv tilbakemelding på hva som bør forbedres. Når dokumentet er godkjent av veiledere, skal det sendes til godkjenning av kunden. Responstid på denne godkjenningen er satt i Møteinnkalling til kunden Det er laget en mal for møteinnkalling. Denne ligger vedlagt i vedlegg C.1. Det er meget viktig at det presiseres klart hvilke forberedelser det ønskes at kunden skal gjøre før møtet. Da kunden holder til i Oslo, er det viktig å ha svært gode rutiner rundt møteinnkallinger: Et forslag til møtetidspunkt skal sendes kunden senest klokken 12:00 én uke før den dagen møtet ønskes, slik at kunden kan komme med tilbakemelding på hvorvidt det spesifiserte tidspunktet passer. Endelig møteinnkalling skal sendes til kunden senest klokken 12:00 tre virkedager før møtet avholdes. 8.5 Møtereferat fra kundemøte Mal for møtereferat ligger vedlagt i vedlegg C.2. Ved hvert kundemøte skal det utnevnes en møtereferent. Dokumentansvarlig har ansvar for å utpeke denne referenten. Møtereferater anses som en del av gruppens avtale med kunden. Møtereferatene skal derfor godkjennes av en person på gruppen i tillegg til referenten, samt av kunden. Møtereferat skal være ferdig skrevet, samt sendt til kunden, innen klokken 12:00 dagen etter møtet. Referatet distribueres til kunden via e-post med mindre annet er avtalt under møtet. Godkjenning fra kunden gjøres via e-post, der responstid er beskrevet i avsnitt

37 KAPITTEL 8. KVALITETSSIKRING 8.6 Møteinnkalling til veileder Møteinnkalling til veileder skal sendes innen klokken 12:00 dagen før møtet. Malen for møteinnkallingen ligger vedlagt i vedlegg C.1. Fast tidspunkt for dette møtet er onsdag klokken 13:15-14:00. Dersom møtet blir utsatt, skal det gis beskjed om dette innen samme tidspunkt som møteinnkallingen skal sendes. 8.7 Agenda til veiledermøtene - mal som skal følges Agendaen til veiledermøtene er lagt inn i malen for møteinnkalling. Denne finnes i vedlegg C.1. Dersom ett eller flere av de faste punktene ikke er relevante for det aktuelle møtet, skal disse fjernes fra agendaen. 8.8 Møtereferat fra veiledermøter Møtereferat fra veiledermøtet skal legges ved neste møteinnkalling, og godkjennes på neste møte. Malen for møtereferatet ligger vedlagt i vedlegg C.2. 31

38 Vedlegg A Interessenter Dette vedlegget inneholder kontaktinformasjon for alle interessenter. A.1 Kunderepresentanter Andreas R. Johnsen Bedrift: Bouvet Adresse: Sandakerveien 24C D11, Pb Nydalen, 0403 Oslo Telefon: Telefax: E-post: andreas.johnsen@bouvet.no Tom Bech Bedrift: Bouvet Adresse: Sandakerveien 24C D11, Pb Nydalen, 0403 Oslo Telefon: Telefax: E-post: tom.bech@bouvet.no Bouvet AS Postboks 4430 Nydalen N-0403 Oslo 32

39 VEDLEGG A. INTERESSENTER A.2 Veiledere Lillian Hella Stilling: Stipendiat Adresse: Institutt for datateknikk og informasjonsvitenskap, Sem Sælandsvei 7-9, 7034 Trondheim Telefon: E-post: Tarjei Lægreid E-post: A.3 Prosjektgruppe Ole Kristian Mørch-Storstein Adresse: Korsgata 22-31, 7030 Trondheim Telefon: E-post: Martin Andreas Børke Adresse: Dyre Halsegt.11, 7042 Trondheim Telefon: E-post: Rune Vistnes Adresse: Edgar B. Schieldropsvei 21-13, 7033 Trondheim Telefon: E-post: Tarjei Kvamme Løset Adresse: Aasmund Vinjes gate 1, 7015 Trondheim Telefon: E-post: Knut Auvor Grythe Adresse: Herman Krags vei 7-61, 7050 Trondheim Telefon: E-post: 33

40 Vedlegg B Ansvarsfordeling Her følger tabeller for ansvarsfordelingen i de forskjellige fasene. Tabellen for en fase blir utarbeidet ved starten av den aktuelle fasen. B.1 Ansvarsfordeling i planleggingsfasen Arbeidspakke Forklaring Ansvarlig Innledning Skrive en god innledning til fasedokumentet. Ole Kristian Prosjektmandat Prosjektnavn, sponsor og innhold. Ole Krisitan Prosjektplan Definere faser, aktiviteter og milepæler. Ole Krisitan Organisering Definere roller, organisering og ansvarsfordeling. Rune Maler og standarder Definere standard katalogstruktur, Rune, Tarjei, Mar- dokumentmaler. tin Versjonskontroll Prosedyre for versjonskontroll. Knut Prosjektoppfølging Intern rapportering, prosjektmøter, Knut statusrapportering. Kvalitetssikring Responstider, rutiner for godkjenning Martin av dokumenter, møterefer- at/innkalling. Teknisk tilrettelegginråde og lignende. Oppsett, CVS, L A TEX, gruppeom- Knut Korrektur Korrekturlese fasedokumentet og Martin sørge for at det er helhetlig. 34

41 VEDLEGG B. ANSVARSFORDELING B.2 Ansvarsfordeling i forstudiet Reduksjon stammeform Stopp-ord-filter til Uthenting av ord og ordkombinasjoner Arbeidspakke Forklaring Ansvarlig Eksisterende løsninger Studere eksisterende løsninger som bruker LSI og ontologier/emnekart. Se på måter å knytte LSI til inndel- Rune ing i emnekart på. Se på løsninger som reduserer ord til stammeform, og eventuelle forbedringer som bør gjøres. Se på alternativer for fjerning av stoppord: Generering av stoppordlister basert på statistikker fra dokumentsamlingen. Filtrering av ord som har flere treff i mange dokumenter. Se på løsninger som deler dokumenter inn i ord og ordkombinasjoner. Se på løsninger for oppdeling av sammensatte ord og vurdere verdien av dette for prosjektet. Se på løsninger for sammenkobling av Tarjei Ole Kristian Martin meningsbærende ordkombinasjoner og vurdere verdien av dette for prosjektet. LSI Studere algoritmer for LSI. Knut Programmeringsomgivelser Tarjei Datastrukturer Studere egnede programmeringsomgivelser for oppgaven. Se spesielt på Python: dokumentasjons- og teststandarder, distribusjon av moduler, utvidelsesmoduler skrevet i kompilert språk (blant annet for effektivisering av matriseoperasjoner). Se på filformat, strukturering og parsing av dokumentsamlinger, ontologier, statistikker og ordlister. Korrektur Korrekturlese fasedokumentet og sørge for at det er helhetlig. Knut Martin 35

42 VEDLEGG B. ANSVARSFORDELING B.3 Ansvarsfordeling i kravspesifikasjonen Arbeidspakke Forklaring Ansvarlig Innledning Skrive en god innledning som følger Ole Kristian IEEE 830-standarden. Overordnet Skrive en overordnet beskrivelse av Rune beskrivelse programmet som skal utvikles. Use-case Utarbeide use-case for programmet. Martin Use-case-basert Utføre en use-case-basert estimering Martin estimering av timeforbruk i videre faser. Krav til preprosesserinesseringen Innhente krav som går på prepros- Tarjei av dokumentene. Krav til klasing Innhente krav til klasingen av dokumentene. Knut Krav til kategorisering Innhente krav til kategorisering av et dokument. Tarjei Ikke-funksjonelle Innhente de ikke-funksjonelle Ole Kristian krav kravene til systemet. Korrektur Korrekturlese fasedokumentet og Martin sørge for at det er helhetlig. 36

43 VEDLEGG B. ANSVARSFORDELING B.4 Ansvarsfordeling i konstruksjonsfasen Arbeidspakke Forklaring Ansvarlig Innledning Skrive en god innledning til fasedokumentet. Ole Kristian Overordnet design Skissere opp det overordnede designet Rune til programmet. Preprosessering Utarbeide konstruksjonen av preprosesseringsmodulen. Tarjei Klasing Utarbeide konstruksjonen av klasingsmodulen. Knut Kategorisering Utarbeide konstruksjonen av kategoriseringsmodulen. Tarjei Brukergrensesnitt Utarbeide et overordnet design av brukergrensesnittene mot programmet. Martin Korrektur Korrekturlese fasedokumentet og Martin sørge for at det er helhetlig. 37

44 VEDLEGG B. ANSVARSFORDELING B.5 Ansvarsfordeling i programmerings- og dokumentasjonsfasen Arbeidspakke Forklaring Ansvarlig Preprosessering Skrive koden til preprosesseringsmodulen. Tarjei Klasing Skrive koden til klasingsmodulen. Knut Kategorisering Skrive koden til kategoriseringsmodulen. Knut Kvalitetssikring Sørge for at all kode er kommentert Tarjei på riktig måte. Implementasjonsdokument Skrive implementasjonsdokumentet. Tarjei Brukerdokumentasjon Skrive brukerdokumentasjon med Martin tilhørende installasjonsveiledning. Korrektur Korrekturlese implementasjonsdokumentet Martin og brukerdokumen- tasjonen, og sørge for at disse er helhetlige. 38

45 VEDLEGG B. ANSVARSFORDELING B.6 Ansvarsfordeling i testingen Arbeidspakke Forklaring Ansvarlig Innledning Skrive innledningen til fasedokumentet. Ole Kristian Overordnet testplan Skrive den overordnede testplanen Martin for programmet. Enhetstester Skrive enhetstestene for programmet. Tarjei Modultester Skrive modultestene for programmet. Martin System- og integrasjonstestestestene Skrive system- og integrasjon- Rune for programmet. Akseptansetester Skrive akseptansetestene for programmet. Ole Kristian Testing Sørge for at alle testene blir utførte. Tarjei Kvalitetssikring Sørge for at alle krav blir testet. Martin Korrektur Korrekturlese fasedokumentet og Ole Kristian sørge for at dette er helhetlig. 39

46 VEDLEGG B. ANSVARSFORDELING B.7 Ansvarsfordeling i prosjektvurderingen Arbeidspakke Forklaring Ansvarlig Prosessen og resultatet Hva gikk bra, hva gikk dårlig, og hva Martin kunne blitt gjort annerledes? Hvor- Kunden og oppgaven dan har gruppen samarbeidet? Kommunikasjon, samarbeid, positive og negative sider. Hvordan har gruppen opplevd oppgaven? Faget Hvordan har kommunikasjon og samarbeid med hoved- og hjelpeveileder vært? Har veiledningen vært god nok? Hvordan var faget, og er det noe som kan forandres til neste år? Videre arbeid Hva gjenstår? Gi et estimat over hvor mange timeverk som trengs for å ferdigstille produktet. Hva kan forbedres? Korrektur Korrekturlese fasedokumentet og sørge for at det er helhetlig. Rune Ole Kristian Martin Martin 40

47 VEDLEGG B. ANSVARSFORDELING B.8 Ansvarsfordeling i presentasjon- og demonstrasjonsfasen Arbeidspakke Forklaring Ansvarlig Struktur og maler Sette opp struktur og maler for presentasjonen. Martin Oppgaven Forberede presentasjon av oppgaven Rune og bakgrunnen for denne. Løsningen Forberede presentasjon av løsningen Ole Kristian gruppen kom frem til. Demonstrasjon Forberede hva som skal demonstreres, Martin samt finne testsett for demon- strasjon. Konklusjon Hvorvidt nådde gruppen målene den Martin og Rune hadde satt seg? Hva må gjøres videre? 41

48 Vedlegg C Maler Dette vedlegget inneholder malene som skal benyttes i prosjektarbeidet. 42

49 VEDLEGG C. MALER C.1 Mal for møteinnkallelse Gruppe 10 Automatisk klassifisering av dokumenter i emnekart ved bruk av LSI Møteinnkallelse Forum: Dato/tid: Sted: Møteinnkaller: Følgende er innkalt: Mål for møtet: Vedlegg : Gruppe 10, Møte XX <åååå-mm-dd> <tt:mm> <tt:mm> <stedet> <navn> <deltakernes navn, firma> <Kort om formålet med møtet og hva man ønsker å komme frem til> 1. Første vedlegg 2. andre vedlegg Agenda 1. Godkjenning av agenda 2. Godkjenning av møtereferat fra forrige veiledermøte 3. Godkjenning av møtereferat fra siste kundemøte 4. Godkjenning av statusrapport 5. Gjennomgang/godkjenning av vedlagte fasedokumenter 6. <andre saker kommer her og utover> 7. Eventuelt Opprettet Side 1 av 1 43

50 VEDLEGG C. MALER C.2 Mal for møtereferater Gruppe 10 Automatisk klassifisering av dokumenter i emnekart ved bruk av LSI Møtereferat Forum: Dato/tid: Sted: Møtedeltakere: Referent: Mål for møtet: Agenda: <navn på gruppe og ev. møtenummer> <åååå-mm-dd> <tt:mm> <tt:mm> <stedet> <deltakernes navn, firma> <navn, firma> <kort om formålet med møtet og hva man ønsket å komme frem til> 1. første punkt 2. andre punkt, osv Sammendrag <Tekst herfra> Referat <Mer detaljert hva som ble sagt og gjort> Aksjonspunkter I D Beskrivelse Frist Ansvarlig Neste møte <Neste møte er avtalt til...> Opprettet Side 1 av 1 44

51 VEDLEGG C. MALER C.3 Mal for statusrapporter Gruppe 10 Automatisk klassifisering av dokumenter i emnekart ved bruk av LSI Statusrapport Periode : <åååå-mm-dd>/<mm-dd> Vedlegg : 1. Første vedlegg 2. andre vedlegg Oppsumering <Tekst herfra> Utført arbeid i perioden Dokumenter 1 <tekst> Møter 2 <tekst> Aktiviteter 3 <tekst> TROKK m/avvik og tiltak Tidsmessig <tekst> Risiko <tekst> Omfang <tekst> Kostnad/timer <tekst> Kvalitet <tekst> Problemer Opprettet Side 1 av 1 Gruppe 10 Automatisk klassifisering av dokumenter i emnekart ved bruk av LSI <tekst> Planlagt arbeid neste periode <tekst> Opprettet Side 2 av 2 45

52 VEDLEGG C. MALER C.4 Webgrensesnitt for timeregistrering Timeregistrering - Gruppe 10 Timeregistrering - Gruppe 10 Dato Bruker Timer Kategori Submit Timer fra til (uke 36/37): Kategori knuta martinb olekrst runevi tarjeikv Prosjektledelse Forelesninger og egenlæring Planlegging Forstudium Kravspesifikasjon Konstruksjon Programmering og dokumentasjon Testing Prosjektutvikling Presentasjon og demo of :22 46

53 VEDLEGG C. MALER C.5 Skjema for føring av timeregnskap Gruppe 10 TIMEREGNSKAP Prosjekt: Uke nr.: 43 Ajour pr Automatisk klassifisering av dokumenter i emnekart ved bruk av LSI (Paper Prism) Akt nr. Beskrivelse Opprinnelig plan Brukt denne uke Brukt hittil Estimert Totalt Tjente Produktivitet Planlagt gjenstående estimat timer oppnådd Fremdrift Fremdriftsavvik Planlagt startdato Planlagt sluttdato 01 Prosjektledelse , , % % Forelesninger og egenl , , % % Planlegging % % Forstudium 260 7, % % Kravspesifikasjon , , % % Konstruksjon % % Programmering og Dok % % Test ,5 50, , Prosjektvurdering Presentasjon og demo TOTAL % %

54 Vedlegg D Risikotabell 48

55 VEDLEGG D. RISIKOTABELL Nr Risikofaktor Akt. Kons. Sanns. Strategi og tiltak Ansvar Martin 1 Sykdom etc. Alle M L Si fra til de andre om du tror du holder på å bli syk, deleger arbeidet videre. 2 Ekstraarbeid i andre prosjekter/fag/jobb. Alle H M Alle må si ifra dersom ekstraarbeid forekommer, slik at ett eller flere andre gruppemedlemer kan avlaste vedkommende. 3 Tekniske problemer. Alle M L Ikke gjøre en avhengig av enkle maskiner, dvs. lagre all informasjon eksternt. 4 Frafall av gruppemedlem. Alle H L Kan motvirkes ved å ha god lagånd. Dersom det forekommer må man redisponere menneskelige ressurser. 5 Samarbeidsproblemer med kunde. Alle L H Må alltid føre en høflig dialog, og være flinke med å oppfylle ønskene deres. 6 Interne konflikter. Alle M M/H Gruppen må verdsette åpen meningsutveksling, samtidig som den må være løsningsorientert. 7 Dårlig planlegging / feilestimeringer. 8 Misforståelser mellom kunden og gruppen. 9 Forsinkelser i forbindelse med at det er vanskelig å finne et møtetidspunkt som passer. Alle M M Kontinuerlig oppdatere tidsestimatene, samt sette av et tidsbuffer. Alle M H Holde gjenvn kontakt med kunden, og så hyppige kundemøter som mulig. Alle M M Planlegge møter så lang tid i forveien som mulig. Rune Knut Ole Kristian Ole Kristian Ole Kristian Ole Kristian Ole Kristian Ole Kristian 49

56 Vedlegg E Grafisk fremstilling av prosjektplan I D sep 2005 okt 2005 nov 2005 Task Name Start Finish Prosjektledelse Prosjektledelse Forelesninger og Forelesninger og egenlæring egenlæring Planlegging Planlegging Forstudium Forstudium Kravspesifikasjon Kravspesifikasjon Konstruksjon Konstruksjon Programmering og Programmering og dokumentasjon dokumentasjon Test Test Prosjektvurdering Prosjektvurdering Presentasjon og Presentasjon og demo 0 demo

57 Vedlegg F Definisjoner og forkortelser CVS Emnekart Et verktøy for versjonskontroll. Internasjonal standard, også kjent som ISO/IEC 13250:2003, brukes for å representere kunnskap med fokus på gjenfinnbarhet Ikke-funksjonelle krav Krav som stilles til hvordan programmet skal fungere, men som ikke er tilknyttet en bestemt brukerfunksjon. Kategorisering Klasing Kompletthet LaTeX LSI Modul Ontologi Preprosessering Presisjon Å finne emnet til et dokument ut fra innholdet i dokumentet. Å samle dokumenter i klaser (clustere), slik at dokumenter som er semantisk relatert til hverandre havner i samme klase. (recall) - Forholdet mellom antall relevante dokumenter funnet og antall relevante dokumenter. Språk for å skrive dokumenter som skal typesettes med TEX; lettere enn å skrive ren TEX. latent semantisk indeksering - En teknikk for prosessering av naturlig språk. Programvareenhet som samler et sett med subprogrammer og datastrukturer. Hierarkisk datastruktur med relevante entiteter og deres relasjoner med domenet Omforming fra dokument til ordvektor. (precision) - Forholdet mellom antall relevante dokumenter funnet og antall dokumenter funnet. 51

58 VEDLEGG F. DEFINISJONER OG FORKORTELSER Prototype Taksonomi Use-case Versjonskontroll En fungerende modell for å teste ut og få feedback på ideer og konsepter Betyr enten en hierarkisk klassifisering av ting, eller prinsipper brukt for å klassifisere. Et scenarie som beskriver hvordan et system samhandler med en bruker eller et annet system. Håntering av mange revisjoner av samme informasjonsenhet. 52

59 Del II Forstudium 53

60 54

61 INNHOLD Innhold 1 Innledning Hensikt Omfang Oversikt Dagens situasjon Publiseringsverktøyet Roller Publiseringsverktøyets funksjonalitet Assosiasjoner Use-case for eksisterende løsning Problemer med dagens situasjon Ønsket situasjon Kategorisering av dokumentsamling Enklere artikkelredigering Enklere å finne informasjon Use-case for ønsket situasjon Markedsundersøkelse Autonomy DESIRE II og synonymordlister GERHARD WEBSOM OASIS Forretningsmessige krav 76 6 Evalueringskriterier 77 55

62 INNHOLD 7 Emnekart Om emnekart Bruksområder Implementasjonsomgivelser Python Pythonmodul i C Pythonmodul i Java Selvstendige programmer Preprosessering Splitting Naiv splitting Iterativ gjennomgang med tilstandslagring Iterativ gjennomgang med tilstandslagring og look-ahead Fraseuthenting Stoppord Statisk liste Liste basert på ordfrekvens En kombinasjon Stemming Evaluering av stemmere Algoritmer Implementasjoner og verktøy Latent semantisk indeksering Om LSI Vektorromsmodellen Vektorrommet Dokument/term-matrisen VSM vs. tradisjonelle søkemetoder LSI i praksis SVD vs. SDD Vekting

63 INNHOLD 11 Valg av løsning Metode for evaluering av løsninger Vurdering av ferdigløsninger Vurdering av løsninger for egenutvikling Vurdering av implementasjonsomgivelser Vurdering av splittingløsninger Vurdering av stoppordløsninger Vurdering av løsninger for stemming Vurdering av vekting Vurdering av Singular Value Decomposition (SVD) vs. Semi Discrete Matrix Decomposition (SDD) Konklusjon A Skjermbilder 104 B Use-Case 106 C Definisjoner og forkortelser 107 D Referanser

64 58 INNHOLD

65 FIGURER Figurer 2.1 Rollene i systemet Eksempel på åpningsvindu for brukerne av utviklingsverktøyet Assosiere en artikkel til et emne Søke i eksisterende emner Eksempel på emnehierarki Illustrasjon av emnekart Et eksempel på et vektorrom Et eksempel på dokument/term-matrise Avrunding av justert sum A.1 Eksempel på mal for artikkel del A.2 Eksempel på mal for artikkel del B.1 Use-case diagram for å opprette nytt innhold

66 60 FIGURER

67 TABELLER Tabeller 2.1 Tekstlig use-case for å finne emne til en artikkel (dagens situasjon) Tekstlig use-case for å finne emne til en artikkel (ønsket situasjon) Forretningsmessige krav Beskrivelse av prioriteter Evalueringskriterier Hvor de forskjellige evalueringskriteriene blir benyttet Oppsett av tabell for vurdering av løsning Tabell for vurdering av ferdigløsninger Tabell for vurdering av implementasjonsomgivelser Tabell for vurdering av splittingløsninger Tabell for vurdering av stoppordløsninger Tabell for vurdering av løsninger for stemming Tabell for vurdering av vekting Tabell for vurdering av SVD vs. SDD

68 62 TABELLER

69 Kapittel 1 Innledning Dette kapittelet gir en oversikt over forstudiedokumentet. I denne fasen av prosjektet har gruppen gjort flere undersøkelser. Det er blant annet blitt undersøkt hva som finnes på markedet av ferdigløsninger, hva som vil være den ønskede situasjonen for kunden, samt hvilke forretningsmessige krav som foreligger. I tillegg er det sett på hva gruppen må implementere selv, samt hvilke metoder og verktøy den har til disposisjon. Til slutt er det gjort rede for hvilke valg gruppen har tatt, basert på evalueringskriterier fremlagt av kunden. Dette her er et standpunkt. Hvor er det næste?- Alt skal en prøve å vælge det bedste. Peer Gynt av Henrik Ibsen 1.1 Hensikt Dette dokumentet er utarbeidet for å gjøre rede for hvilke utfordringer og oppgaver gruppen står ovenfor, samt en evaluering av alternative løsninger. Dokumentet skal videre legge grunnlaget for arbeidet i de neste fasene. Målgruppen for forstudiedokumentet vil være kunden og prosjektgruppen. 1.2 Omfang Programmet som skal lages har som oppgave å automatisk kategorisere dokumenter i emnekart ved bruk av latent semantisk indeksering (LSI). I denne fasen av prosjektet skal gruppen sette seg grundig inn i hva som finnes av eksisterende teknologier relatert til oppgaven. Gruppen skal også evaluere hvordan disse teknologiene på best mulig måte kan benyttes for å komme frem til et produkt som tilfredsstiller kundens ønsker. Forstudiet vil senere legge grunnlaget for utviklingen av kravspesifikasjonen. 63

70 KAPITTEL 1. INNLEDNING 1.3 Oversikt Resten av forstudiedokumentet er delt inn i følgende kapittel og vedlegg: Kapittel 2 inneholder en beskrivelse av dagens situasjon for kunden. Kapittel 3 inneholder en beskrivelse av situasjonen kunden ønsker, der dokumenter blir automatisk kategorisert. Kapittel 4 inneholder en beskrivelse av de løsningene som er tilgjengelige i dag, og som helt eller delvis dekker kundens behov. Kapittel 5 inneholder de forretningsmessige kravene til programmet. Kapittel 6 inneholder de forskjellige evalueringskriteriene de forskjellige løsningene vil bli vurdert etter. Kapittel 7 beskriver ISO-standarden Emnekart. Kapittel 8 beskriver de forskjellige programmeringsspråkene som skal vurderes. Kapittel 9 beskriver løsninger som kan behandle dokumentvektorer for behandling av LSI. Kapittel 10 beskriver LSI, en teknikk for prossessering av naturlige språk. Kapittel 11 beskriver hvilke valg gruppen har tatt, og grunnlagene for disse valgene. Vedlegg A viser skjermbilder fra det eksisterende publiseringsverktøyet. Vedlegg B viser et visuelt use-case for hvordan sluttbrukerene benytter publiseringsverktøyet. Vedlegg C gir en liste med forkortelser og definisjoner av ord benyttet i dokumentet. Vedlegg D inneholder referansene benyttet i dokumentet. 64

71 Kapittel 2 Dagens situasjon Dette kapittelet beskriver publiseringsverktøyet som Bouvet i dag leverer til forskjellige bedrifter, hvordan dette virker og hvilke problemer som er forbundet med det. 2.1 Publiseringsverktøyet Bouvet tilbyr et publiseringsverktøy som legger til rette for enkel publisering av artikler og innhold på en portal. Portalen er den delen av systemet som er synlig eksternt, det vil si på Internett. Denne består av en forside, navigasjonsmenyer, presentasjonsmaler, samlesider og forskjellig funksjonalitet. Alt innhold som vises på portalen presenteres ved en presentasjonsmal. Dette er en definisjon på hva slags utseende artikkelen skal ha, for eksempel hvilke skrifttyper som skal benyttes Roller Samtlige brukere av publiseringsverktøyet og portalen har en rolle som avgjør hvilke rettigheter, ansvar og oppgaver denne brukeren har i forhold til systemet. Brukerne kan tildeles én av følgende fire roller (illustrert i figur 2.1): Besøkende - Har kun tilgang til å lese innholdet som er synlig eksternt. Bidragsyter - Kan lage nytt innhold og legge dette i kø for godkjenning av en redaktør. Redaktør - Kan lage nytt innhold, og godkjenne at innhold gjøres synlig eksternt. Administrator - Har alle rettigheten til en redaktør, og har i tillegg administratorrettigheter for systemet. Dette innebærer blant annet å legge til og fjerne brukere. 65

72 KAPITTEL 2. DAGENS SITUASJON Innhold som er lagt til av bidragsytere må altså gjennom en godkjenningsprosess før det blir synlig eksternt. Dette sørger for at materialet som gjøres synlig for besøkende holder tilstrekkelig høy kvalitet. Figur 2.1: Rollene i systemet Publiseringsverktøyets funksjonalitet Bidragsytere, redaktører og administratorer har mulighet til å logge inn i publiseringsverktøyet via et webgrensesnitt. Straks de har logget seg inn, vil de ha mulighet til å endre og legge til innhold i henhold til de rettigheter de har. Disse brukerne vil bli møtt av åpningsvinduet i figur 2.2. Hvis en bruker skal lage nytt innhold, og deretter ønsker å publisere dette, vil følgende handlingsrekkefølge finne sted: Ved å velge Skrive ny artikkel fra menyen (markert med sirkel), kommer brukeren inn på en ny side med en mal for artikler. Brukeren får der mulighet til å legge inn informasjonen som ønskes. Dette kan være tittel, ingress, bilder, tekst eller annen informasjon (se figur A.1 og A.2 i vedlegg A). Teksten som legges inn kan formateres etter forhåndsdefinerte regler. For eksempel vil *Denne teksten bli i kursiv* mens **denne teksten blir fet**. Enkelte HTML-tags kan også benyttes, for eksempel vil <br> føre til et linjeskift i teksten. Når den ønskede teksten er lagt inn kan innholdet lagres. Brukeren kan også få forhåndsvist dokumentet som er opprettet i publiseringsverktøyet. 66

73 KAPITTEL 2. DAGENS SITUASJON Figur 2.2: Eksempel på åpningsvindu for brukerne av utviklingsverktøyet Assosiasjoner Emner og innhold i artiklene assosieres til hverandre for å kunne skape logiske bindinger i innholdet på siden. Dette er viktig for å gjøre det lettere å navigere i innholdet på portalen. Assosiasjoner brukes av portalen for å: forbedre søk. gi innholdet en rik kontekst. gjøre tjenesten enklere å finne fram i, ved at alle assosiasjoner kan navigeres. knytte sammen innhold som handler om samme emne. Figur 2.3: Assosiere en artikkel til et emne 67

74 KAPITTEL 2. DAGENS SITUASJON Assosiasjon til emne En artikkel kan knyttes til flere emner, slik at innholdet i artikkelen reflekteres på best mulig måte. Løsningen er i dag laget slik at brukeren selv skriver inn et forslag til emne, og deretter trykker på en søkeknapp merket Finn... (se figur 2.3). Artikkelen vil da assosieres til emnet som ble skrevet inn. Selv om emnet ikke finnes, kan det allikevel assosieres med artikkelen. Emnet vil da måtte godkjennes og legges til emnehierarkiet av en redaktør. Redaktøren kan velge å underkjenne denne forespørselen, og eventuelt assosiere artikkelen med andre emner i stedet for. Figur 2.4: Søke i eksisterende emner Dersom brukeren ikke husker hvilke emner som eksisterer, kan vedkommende etterlate søkefeltet tomt og heller velge å søke etter alternative emner. Dette gjøres ved å trykke på Finn... med tomt søkefelt. Brukeren vil da komme inn på en ny side som vist i figur 2.4. På denne siden kan brukeren skrive inn et forslag til emne og søke fram innhold det ønskes assosiasjoner til. Dersom brukeren ikke skriver inn et forslag, vil søkemotoren returnere alle emner. Brukeren kan også spesifisere hva slags type innhold det dreier seg om for å snevre inn søket. Et blankt søk i alle emnetyper vil returnere alt innhold i portalen. 68

75 KAPITTEL 2. DAGENS SITUASJON 2.2 Use-case for eksisterende løsning Av de delene systemet består av, vil det være opprettelsen av en artikkel som er sentralt for dette prosjektet. Et use-case for opprettelse av nytt innhold i publiseringsverktøyet vises i figur B.1 i vedlegg B. Dagens situasjon baserer seg på en manuell kobling mellom artikkel og emner som vist i det tekstlige use-caset i tabell 2.1. Tabell 2.1: Tekstlig use-case for å finne emne til en artikkel (dagens situasjon) Finne emne til artikkel (dagens situasjon) ID: UC-D Mål: Assosiere artikler med emner. Forutsetning: Brukeren har skrevet en artikkel i publiseringsverktøyet. Slutt-tilstand: Brukeren har knyttet artikkelen til et eller flere emner. Aktør(er): Brukere (bidragsytere, redaktører og administratorer) (B) Systemet (S) Trigger: Brukeren er ferdig med å redigere innhold. Grunnleggende handlingssti: 1. B skriver inn forslag på emne i søkeboksen. [Alt. handlingssti A] 2. B trykker på Finn... knappen. 3. S finner emnet, og artikkelen blir knyttet til dette emnet. [Alt. handlingssti B] Alternativ handlingssti A: Alternativ handlingssti B: Alternativ handlingssti C: 4. Use-caset avsluttes. [Alt. handlingssti C] A1. B trykker på Finn... med tom søkeboks. A2. S viser en ny side der brukeren kan søke seg frem til eskisterende emner. A3. B skriver inn et forslag til emne i søkefeltet. A4. S returnerer en liste med alternative emner som passer til brukerens forslag. A5. B velger ett eller flere av disse emnene, og disse knyttes til artikkelen. A6. Use-caset fortsetter fra punkt 4. B1. S gir brukeren beskjed om at det ikke finner det emnet som ble foreslått. B2. Use-caset starter på nytt fra punkt 1. C1. B ønsker å knytte artikkelen til flere emner. C2. Use-caset fortsetter fra punkt 1. 69

76 KAPITTEL 2. DAGENS SITUASJON 2.3 Problemer med dagens situasjon Det har vist seg at brukerne har problemer med funksjonaliteten knyttet til å assosiere en artikkel med et emne. Det ser ut til å være en tendens at artikler knyttes mot emner på høyere nivåer i emnehierarkiene (se figur 2.5). Figur 2.5: Eksempel på emnehierarki Dersom en bruker for eksempel har en artikkel som omhandler hvalfangst, vil det være en risiko for at denne artikkelen knyttes mot et emne som ligger høyere opp i hierarkiet ( Hval eller Dyreverden ). En mulig grunn til dette er at det er vanskelig å ha oversikt over de alternative emnene som eksisterer. Brukerne velger derfor ofte mer generelle emner, som de vet eksisterer. De sparer dermed den tiden det tar å søke seg frem til et mer konkret emne som passer bedre med artikkelens virkelige innhold. En konsekvens av dette kan være at det oppstår assosiasjoner mellom artikler uten stor innbyrdes relevans (for eksempel hvalfangst og dinosaurer). Dette er selvsagt en uheldig situasjon, så en mulig løsning på dette problemet ønskes. 70

77 Kapittel 3 Ønsket situasjon Dette kapittelet beskriver situasjonen kunden ønsker å oppnå. Prosjektet blir gjennomført for å undersøke hvorvidt det er mulig å forenkle prosessen med kategorisering av dokumenter. 3.1 Kategorisering av dokumentsamling Det kan av flere grunner være ønskelig å tildele nye emner til samtlige eksisterende dokumenter i en dokumentsamling. For det første er det mulig at dokumentsamlingen ikke inneholder emnekoblinger fra før. I dette tilfellet vil det være helt nødvendig å kategorisere samtlige dokumenter i samlingen. Videre er det mulig at en eksisterende kategorisering av dokumentene ikke er tilfredsstillende. Dette kan for eksempel komme av at dokumentene er tildelt feil eller for generelle emner. I begge disse tilfellene vil det kunne være ressursbesparende å gjøre prosessen halvautomatisert. 3.2 Enklere artikkelredigering Kunden ønsker å gjøre det lettere for artikkelforfattere å tilordne passende emner til dokumentene de skriver. Det kunden vil ha er et program som sørger for automatisk kategorisering av dokumentet som er skrevet. Problemet i dag er at brukerne (bidragsytere, redaktører og aministratorer) ikke bruker spesifikke nok emner (se kapittel 2.3). Årsaken til at dagens løsning ikke gir bra nok kategorisering av dokumentene i emnehierarkiet, er at det er vanskelig å søke og finne emner i dagens løsning. Kunden vil ha en situasjon der brukerne kan trykke på en knapp og få opp en liste over mulige emner artikkelen kan passe inn under. Brukeren skal deretter kunne foreta en manuell godkjenning av emnene. 71

78 3.3 Enklere å finne informasjon KAPITTEL 3. ØNSKET SITUASJON Ved å gjøre det enklere for brukerne å kategorisere dokumentene, vil man også gjøre det lettere for lesere av nettstedet å gjenfinne relevante artikler. Hvis det er enkelt å finne relevante artikler under forskjellige emner, vil verdien og nytten av emnekartet på det aktuelle nettstedet bedres. 3.4 Use-case for ønsket situasjon Use-case diagram for opprettelse av nytt innhold vil fremdeles være likt som i dagens situasjon, vist i figur B.1 i vedlegg B. Forskjellen mellom dagens situasjon og den ønskede situasjonen vil ligge i hvordan brukeren tilordner emne til artikkeler. Det tekstlige use-caset i tabell 3.1 viser hvordan denne ønskede situasjonen vil kunne oppleves fra sluttbrukerens synspunkt. Tabell 3.1: Tekstlig use-case for å finne emne til en artikkel (ønsket situasjon) Finne emne til artikkel (ønsket situasjon) ID: UC-Ø Mål: Assosiere artikler med emner. Forutsetning: Brukeren har skrevet en artikkel i publiseringsverktøyet. Slutt-tilstand: Brukeren har knyttet artikkelen til et eller flere emner. Aktør(er): Brukere (bidragsytere, redaktører og administratorer) (B) Systemet (S) Trigger: Brukeren er ferdig med å redigere innhold. Grunnleggende 1. B trykker på knappen automatisk kategorisering. handlingssti: 2. S returner forslag på emner artikkelen kan kategoriseres under. 3. B velger bort emner som ikke passer. 4. B godkjenner emnene. [Alt. handlingssti A] Alternativ handlingssti: 5. Use-caset avsluttes. A1. B trykker på søk etter andre emner. A2. S viser en ny side der brukeren kan søke seg frem til eksisterende emner. A3. B skriver inn et forslag på emne i søkefeltet. A4. S returnerer en liste med alternative emner som passer til brukerens søk. A5. B velger ett eller flere av emnene. A6. Use-caset fortsetter fra punkt 4. 72

79 Kapittel 4 Markedsundersøkelse Flere selskaper har laget løsninger for automatisk kategorisering av dokumenter på sine intranett, og enkelte selskaper tilbyr salg av ferdigløsninger. I de store bedriftsportalene, blant annet SAP [3], tilbys dette som en deltjeneste i en større pakke. I dette kapittelet presenteres løsninger og prosjekter som er relevante i forbindelse med prosjektets problemstilling, hvilke algoritmer og teknikker disse benytter, samt hvorvidt de koster noe. Informasjonen er blant annet hentet fra Report on automatic classification systems [20]. 4.1 Autonomy Selskapet Autonomy har laget en løsning som blant annet inneholder automatisk kategorisering av store dokumentmengder [4]. Hovedproduktet til selskapet er IDOL Server, som er en plattform for å forstå mening og viktighet av informasjon. På denne plattformen skal de kunne bygge spesialtilpassede løsninger for den enkelte bedrift. Blant annet kan de levere følgende løsninger: Automatisk kategorisering: Produktet kan automatisk kategorisere dokumenter uten manuell input, eller med hjelp av kategorier gitt i XML eller annet format. Automatisk klasing: Produktet kan automatisk lage klaser av dokumentene, basert på forståelse av dokumentenes innhold. Automatisk taksonomi: Produktet kan automatisk generere taksonomier ut fra informasjonen i dokumentene, og lage en oversikt over hvor informasjonen er spredt. Produktet er imidlertid et kommersielt produkt, og løsningen skreddersys den enkelte kunde. Selskapets produkter benyttes av flere store kunder (Swiss Army, New York Stock Exchange m.fl.), og prisen for produktene settes individuelt for hver skreddersøm. Det står ikke noe på produktets hjemmeside om hvilke algoritmer som benyttes for kategoriseringen. 73

80 KAPITTEL 4. MARKEDSUNDERSØKELSE 4.2 DESIRE II og synonymordlister DESIRE (Development of a European Service for Information on Research and Education) var et forskningsprosjekt iverksatt av EU [6]. Prosjektets mål var å samle relevant informasjon i domenet ingeniørvitenskap på Internett. I den forbindelse ble det utført en automatisk kategorisering av engelskspråklige dokumenter på internett. Måten kategoriseringen ble gjort var ved bruk av en synonymordliste for ingeniørdomenet. Synonymordlisten som ble brukt inneholdt ord og termer mappet mot 800 kategorier. For hvert av dokumentene ble alle metadata, overskrifter og ren tekst ekstrahert. Deretter ble hver av termene fra synonymordlisten matchet mot denne teksten. Dokumentets relevans til termen ble vektet ut fra gitte faktorer. Det ble i prosjektet oppdaget at med stemming (se kapittel 9) ble langt flere dokumenter feilkategorisert enn uten. På den annen side ble 11 prosent av dokumentene ikke kategorisert uten stemming, mot bare 2 prosent med stemming. Prosjektet har ikke blitt realisert som et produkt. For mer informasjon om arbeidet med kategorisering, og resultatene av dette, henvises det til [7]. 4.3 GERHARD GERHARD (GERman Harvest Automated Retrieval and Directory) er et forskningsprosjekt satt i gang av tre tyske universiteter i samarbeid med Deutsche Forschungsgemeinschaft (DFG) [9]. GERHARD baserer seg på en UDC (Universal Decimal Classification), som er et klassifiseringsskjema for kunnskap [12]. Den automatiske kategoriseringen skjer i tre steg: Forberedelse av UDC, hovedsaklig bestående av stemming, fjerning av stoppord og oppbygning av en synonymordliste. Forberedelse av dokumentene, inkludert fjerning av stoppord. Analyse av notasjonene i dokumentene og sortering ut fra relevans til UDChierarkiet. Prosjektet har foregått i samarbeid med DESIRE prosjektet nevnt i 4.2. Første fase av prosjektet var ferdig i 1998, og andre fase pågår fremdeles med uviss ferdigstillelsesdato. Dette prosjektet har i likhet med DESIRE ikke blitt realisert som produkt. 4.4 WEBSOM WEBSOM var et prosjekt utført ved Neural Network Research Centre ved Helsinki University of Technology [10]. WEBSOM er et verktøy for å organisere tekstdokumenter i en kartstruktur slik at de blir lettere å navigere i. WEBSOM er 74

81 KAPITTEL 4. MARKEDSUNDERSØKELSE basert på algoritmen SOM (Self-Organizing Map), som organiserer dokumentene i en todimensjonal matrise slik at relaterte dokumenter legges i nærheten av hverandre. Verktøyet ble brukt til å kategorisere over en million dokumenter på åtti Usenet-nyhetsgrupper. SOM er en åpent tilgjengelig softwarepakke tilgjengelig på [13]. 4.5 OASIS OASIS (Open Architecture Server for Information Search and Delivery) var et annet EU-finansiert prosjekt. I dette prosjektet bidro en rekke europeiske universiteter [14]. Programvaren skal utføre intelligente informasjonssøk ved bruk av nevrale nettverk. Metoden for å samle dokumenter i klaser benytter seg av et flerdimensjonelt nevralt netverk som er selvlærende og klarer å finne klaser på flere hierarkiske nivåer. Det trengs ingen forhåndsdefinert kategorisering eller synonymordliste, siden dette vil bli opprettet automatisk. OASIS benytter feedback fra en bruker for å forbedre sine interne algoritmer. Programvaren er General Public Licence (GPL), og kan lastes ned via [15]. 75

82 Kapittel 5 Forretningsmessige krav Dette kapittelet beskriver de forretningsmessige kravene som er utarbeidet i samarbeid med kunden. Dette er de overordnede kravene kunden har til løsningen og funksjonaliteten i programmet. Kravene skal senere omformes til funksjonelle krav i kravspesifikasjonen. De forretningsmessige kravene vises i tabell 5.1. Tabell 5.1: Forretningsmessige krav Krav ID FO1 FO2 FO3 FO4 FO5 FO6 FO7 FO8 FO9 Beskrivelse Det skal utvikles et produkt som gjør Bouvet i stand til å vurdere om LSI er en vei å gå for å forenkle kategoriseringsprosessen. Programmet skal kunne kjøres på vanlige hardwarekomponenter. Programmet skal være evaluerbart, hvilket betyr at resultater skal kunne sammenlignes med en fasit. Programmet skal kunne kjøres med forskjellige konfigurasjonssett. Programmet skal være basert på åpen kildekode (helst GPL). Programmet skal utvikles i Python. Programmet skal være godt dokumentert. Programmet skal være lett å vedlikeholde. Programmet skal kunne knyttes til det eksisterende publiseringsverktøyet. 76

83 Kapittel 6 Evalueringskriterier Dette kapittelet presenterer evalueringskriteriene som skal danne grunnlaget for valg av løsning. Evalueringskriteriene er utarbeidet i samarbeid med kunden. Kriteriene er vektet med numeriske verdier ut fra hvor høy prioritet kunden mener kriteriene bør ha. Evalueringskriteriene vises i tabell 6.2. For en forklaring av prioritetene, se tabell 6.1. Tabell 6.1: Beskrivelse av prioriteter Prioritet Beskrivelse 1 Kriteriet bør forsøkes innfridd, men vil ikke prioriteres dersom det oppstår tidspress. 2 Kriteriet bør innfris for at programmet skal tilfredstille kundens ønsker. 3 Kriteriet må innfris for at programmet skal tilfredstille kundens krav. De forskjellige delløsningene evalueres ut fra de kriteriene som er aktuelle for det respektive domenet. Det betyr at ikke alle evalueringskriterier er med i hver evaluering. Tabell 6.3 viser en oversikt over hvilke evalueringer de forskjellige kriteriene blir benyttet i. 77

84 KAPITTEL 6. EVALUERINGSKRITERIER Tabell 6.2: Evalueringskriterier Kriterie ID Beskrivelse Prioritet Programmeringsgrensesnitt EK1 Moduler som ikke programmeres av gruppen skal være åpen 3 kildekode (helst GPL). EK2 Grensesnittet skal være enkelt. 1 EK3 Parametere det er hensiktsmessig å kunne endre skal være konfigurerbare via en konfigurasjonsfil. 2 Algoritmer EK4 LSI skal benyttes. 3 EK5 Implementasjonen skal være rask. 2 EK6 Algoritmene skal ikke fjerne meningsfylte data. 2 EK7 Algoritmene skal fjerne redundante data. 3 EK8 Det skal ikke være komplisert eller tidkrevende å tilpasse algoritmene. 3 Resultat av kategoriseringen EK9 Kompletthet: Resultatet skal inneholde en stor andel av de mulige relevante treffene. EK10 Presisjon: Resultatet skal gi et stort antall relevante treff i forhold til totalt antall treff. Ferdigløsninger EK11 Løsningen skal være gratis Tabell 6.3: Hvor de forskjellige evalueringskriteriene blir benyttet Evalueringskriterier (EK): Ferdigløsninger X X X Implementasjonsomgivelser X X Splittere X X X X X X Stoppordfilter X X X X Stemmere X X X X X X X Vekting X X X SVD vs SDD X X X X 78

85 Kapittel 7 Emnekart Dette kapittelet beskriver standarden ISO13250 Emnekart. Publiseringsløsningen til kunden er bygget på emnekartmotoren Zope. 7.1 Om emnekart Figur 7.1 viser en skjematisk representasjon av emnekart. Emnekart brukes for å representere informasjon ved bruk av emner, assosiasjoner og forekomster. Et emne representerer et konsept, som for eksempel land, folk og naturvitenskap. Assosiasjoner er relasjoner mellom de forskjellige emnene. Forekomster viser relasjonene mellom emner og relevante informasjonskilder. Figur 7.1: Illustrasjon av emnekart 79

86 KAPITTEL 7. EMNEKART 7.2 Bruksområder Emnekart er i dag for det meste brukt på nettsider. De gjør det lettere å finne frem i informasjonen som er tilgjengelig. Den klassiske måten å organisere et nettsted på er med en hierarkisk struktur, tilnærmet lik en katalogstruktur. En slik organisering er i stor grad avhengig av kategoriene som er definert av utviklerne. Ofte, om ikke alltid, vil det være flere som er uenige i oppbyggingen av hierarkiet. Fordi emnekart består av flere overlappende hierarkier med mange krysskoblinger, vil informasjon være lettere å finne. Årsaken er at det finnes flere veier til den informasjonen du søker, og du er dermed ikke avhengig av å tenke slik utviklerne forventer. Emnekart er på ingen måte begrenset kun til bruk på nettsider. De kan blant annet brukes i ekspertsystemer, spesielt innen oppbygging av en kunnskapsbase. Innholdsorganiseringssystemer er et annet bruksområde for emnekart. 80

87 Kapittel 8 Implementasjonsomgivelser Kunden ønsker en prototype de lett kan bruke sammen med programmeringsspråket Python. Dette vil naturligvis begrense utvalget av programmeringsspråk gruppen kan benytte. Aktuelle programmeringsspråk som fungerer sammen med Python er Python selv, C og Java. 8.1 Python En implementasjon i Python er klart foretrukket av kunden, siden det gir garantert kompatibilitet til eksisterende systemer. Python har et rikt sett biblioteker, og er kjent for å være raskt å lære og enkelt å programmere i. Python er imidlertid ikke spesielt raskt. Svært få i gruppen har erfaring med Python, men det anses å være et språk som er lett å lære. 8.2 Pythonmodul i C C er et meget raskt språk, og det er vanlig å implementere moduler med høye krav til ytelse i C ved bruk av Python-biblioteker, slik at de deretter kan brukes som vanlige moduler av Python. Det finnes noen ferdig programmerte LSI-implementasjoner i C. Et par personer i gruppen har også erfaring med å programmere i C. 8.3 Pythonmodul i Java Java er raskere enn Python, men tregere enn C. Java er objektorientert i likhet med Python, og det er mulig å implementere Python-moduler i det. Det finnes en del LSI-relaterte produkter som er skrevet i Java. Alle i gruppen har erfaring med Java. 81

88 KAPITTEL 8. IMPLEMENTASJONSOMGIVELSER 8.4 Selvstendige programmer En del av funksjonaliteten som trengs kan allerede være implementert i selvstendige applikasjoner. Disse er mulige å kalle fra Python. Data kan overføres ved hjelp av argumenter, eller ved å legge data i midlertidige filer. Dette er kjapt og lettvint å implementere, men gir en mindre enhetlig applikasjon. Det kan derfor være mer interessant i forbindelse med en prototyp enn en komplett applikasjon. 82

89 Kapittel 9 Preprosessering Løsningen som skal implementeres vil se på termer for å finne grader av likhet mellom dokumenter. Det er derfor nødvendig å bryte hvert dokument ned i et sett med termer. Dette trinnet vil i prosjektet bli kalt preprosessering. Termene fungerer som stikkord for dokumentene, og sammen bør disse stikkordene si mest mulig om hva et dokument inneholder uten å drukne i en støy av ord som man finner i de fleste dokumenter. Dersom man kan fjerne støy fra mengden av termer vil man kunne øke presisjonen til systemet og samtidig minske prosesseringstiden i senere trinn. Det er også en fordel å kunne gjenkjenne likheter mellom ord som kan representeres ved en felles term. På denne måten reduserer man antallet unike termer som trengs for å representere hvert dokument, og dermed også videre prosesseringstid. Viktige oppgaver ved preprosessering av dokumenter blir altså å fjerne ord som ikke sier noe om hva et dokument omhandler og å gjenkjenne likheter mellom ord som essensielt sier det samme. Dette kapittelet tar for seg ulike problemstillinger og mulige løsninger i forbindelse med preprosessering av dokumenter. 83

90 KAPITTEL 9. PREPROSESSERING 9.1 Splitting Før teksten kan analyseres må den splittes opp i deler, enten i form av enkeltord, delord eller grupper av ord. Det finnes flere mulige løsninger for å oppnå dette, hvor de mest aktuelle gjennomgås i denne seksjonen Naiv splitting Naiv splitting henter ut alle sekvenser av bokstaver som hvert sitt element, og betrakter alle tegn som ikke er bokstaver som skilletegn. Resultatet er alle enkeltord i dokumentet. Naiv splitting er enkel å implementere og svært rask (siden all tekst leses kun en gang). Dette går på bekostning av fleksibiliteten, og det blir umulig å ta hensyn til spesialtilfeller som markup, URL-er og lignende. Disse vil bli splittet opp som vanlig tekst, og alt som minner om tekst vil bli returnert som ord. Dette kan til en viss grad kompenseres for ved at man legger til markup-ord i stoppordlisten, men dette er til liten hjelp om markup og faguttrykk har samme ordlyd. Det vil også være vanskelig å hente ut fraser (se 9.1.4), siden all omkringliggende tegnsetting forkastes Iterativ gjennomgang med tilstandslagring Ved å gå gjennom teksten tegn for tegn og lagre tilstand underveis, kan en del av de største problemene med naiv splitting unngås. For eksempel kan problemet med markup unngås ved å lagre tilstanden inne i et markup-element når dette påbegynnes. Iterativ gjennomgang med tilstandslagring er fortsatt relativt lett å implementere, og kjøretiden tilsvarer naiv splitting. Imidlertid, siden tilstanden baseres på enkelttegn, vil situasjoner der man trenger å se en større sammenheng kreve flere deltilstander. Dette blir fort komplisert og vanskelig å forstå. Denne metoden er altså best egnet på dokumenter der tilstand kan bestemmes ut fra svært få tegn Iterativ gjennomgang med tilstandslagring og lookahead Iterativ gjennomgang med look-ahead skiller seg fra normal iterativ gjennomgang ved at man tillater å lese et stykke forover for å bestemme tilstand, i stedet for å kun betrakte gjeldende element. Look-ahead gjør at man kan oppdage tilstander som består av flere tegn uten å måtte gå via deltilstander, noe som gjør parseren mer oversiktlig. Ulempen er økt kjøretid. Enkelte former for tilstand er nemlig umulige å bedømme entydig uten å lese et godt stykke videre, potensielt helt til slutten av dokumentet. Eksempelvis 84

91 KAPITTEL 9. PREPROSESSERING kan XML-markup feildetekteres ved at en bruker benytter < ( mindre enn ) i klartekst, og dette kan vanskelig oppdages uten å lese forover til filen er slutt eller en ny tag oppdages. Dette gir kvadratisk kjøretid, en sterk økning fra de øvrige algoritmene. Likevel vil dette sannsynligvis bli et lite problem, da man som oftest identifiserer markup entydig etter få tegn Fraseuthenting Med fraser menes ord som naturlig hører sammen slik de står i en setning, som Jens Pikenes eller svigermors drøm. Et mål når man deler opp et dokument er å få mest mulig meningsbærende termer. Om man kan identifisere fraser som Jens Pikenes vil man intuitivt få høyere presisjon enn om man søker med de mer generelle termene Jens og Pikenes separat. Man kan også beskytte en term som er gjenkjent som en frase fra stemming, slik at man for eksempel unngår å bruke Jen og Pik som søkestrenger. Å gjenkjenne fraser basert på semantikk og forekomst er en tung oppgave, og neppe særlig aktuelt for dette prosjektet. Man kan derimot komme et stykke ved å se på tegnsetting. Fraser forekommer ofte med spesiell tegnsetting i en tekst, og man kan i flere tilfeller gjenkjenne en frase ved for eksempel å se på markup eller tegnsetting. Et kraftig verktøy for gjenkjenning av tekstmønstre er regulære uttrykk, som man blant annet finner i Python [16] Fraser i markup Noen fraser kan identifiseres ved at de er samlet i markup. Med markup menes for eksempel hermetegn, html-tags som <i> og <b> (italic og bold) eller * og **, som benyttes i kundens publiseringsverktøy. Fraser kan da for eksempel gjenkjennes som <i>svigermors drøm</i>, *svigermors drøm*, <b>svigermors drøm</b> eller **svigermors drøm**. Det hender at hele setninger, og av og til hele avsnitt, er merket med slike tags. Det vil derfor være aktuelt å innføre en øvre grense for antall ord i en slik frase. Dersom den oppmerkede teksten har flere enn et visst antall ord vil den altså ikke berøres av denne modulen Særnavn Særnavn har den spesielle egenskapen at de forekommer med stor forbokstav inne i en setning, for eksempel Prosjektleder er Ole K. Mørch-Storstein.. Dette kan gjenkjennes som et tekstmønster, og dermed utnyttes for å finne særnavn. Initialer kan gjenkjennes ved at de har en stor bokstav. Punktum etter initial trenger da ikke å markere slutten på en setning. Siden alle ord som forekommer i begynnelsen av en setning har stor forbokstav kan det være greit å se bort ifra disse. Dersom man har setningen Ole K. Mørch- 85

92 KAPITTEL 9. PREPROSESSERING Storstein er prosjektleder. vil man for eksempel gjenkjenne K. Mørch-Storstein som særnavn, noe som kan fungere bedre enn motsatt tilfelle: Er Ole K. Mørch- Storstein fra setningen Er Ole K. Mørch-Storstein prosjektleder?. Setninger blir av og til avsluttet irregulært. Om setningen avsluttes med annen tegnsetting enn forventet vil det første ordet i påfølgende setning bli oppfattet som et særnavn. Et mottiltak kan da være å stoppord-filtrere resulterende termer, slik at navn som er stoppord kan fjernes. Videre bør særnavn neppe stemmes, som nevnt tidligere, slik at for eksempel Bergen gir termen Berg Fraser med bindestrek Uttrykk på formen semi-trailer (og navn som Belle-Ile-en-Mer ) kan lett identifiseres som fraser, også i starten av setninger. Det kan derfor være fordelaktig å se etter slike sammensetninger etter at man har hentet ut særnavn fra teksten, slik at man også får hentet ut sammensetninger som ikke er en del av et navn. Videre kan man eventuelt fjerne bindestreker fra disse termene, i og med at begge skrivemåter ofte benyttes. Det er også tenkelig at stemming er hensiktsmessig i slike tilfeller. Et mulig eksempel blir da at semi-traileren blir gjenkjent som frase og representert som semitrailer. 86

93 KAPITTEL 9. PREPROSESSERING 9.2 Stoppord Før teksten kan analyseres er det viktig å fjerne stoppord. Stoppord er ord som ikke er meningsbærende i seg selv, og som dermed kun blir støy i algoritmen. Det er omdiskutert hvorvidt denne støyen påvirker resultatet ved store datasett [21], men det er uansett ønskelig å fjerne stoppord, om ikke annet som en forbedring for å redusere datamengden. For å fjerne stoppord er man avhengig av en eller flere stoppordliste. Det er flere måter å skaffe seg disse på, og valget står som regel mellom tredjeparts og selvproduserte lister Statisk liste Det finnes en norsk stoppordliste [8] som tilsynelatende oppdateres aktivt Liste basert på ordfrekvens Stoppord opptrer svært ofte. Det er derfor mulig å generere en form for stoppordliste ved å analysere dokumentsamlingen og plukke ut ord som opptrer i svært mange dokumenter. Ordene som plukkes ut vil ikke nødvendigvis være stoppord per definisjon, men de vil uansett være ord som ikke har særlig verdi i analysen En kombinasjon Kombinasjon av lister er mulig. For eksempel kan en statisk liste over kjente stoppord kombineres med stoppord uthentet ved å analysere dokumentsamlingen. På denne måten vil man få fjernet ord man vet ikke har mening i seg selv, samt fjerne ord som opptrer for ofte til å kunne være relevante. 87

94 KAPITTEL 9. PREPROSESSERING 9.3 Stemming Ord i naturlige språk har gjerne flere morfologiske varianter. I de fleste tilfeller har slike varianter av ord lignende semantiske tolkninger, og kan anses som ekvivalente hva Information Retrieval (IR) angår. Det er for eksempel ikke noe i veien for at en søkestreng som inneholder ordet konsumprisindeks gir treff som inneholder ordet konsumprisindeksen. Om man kan gjenkjenne likheten mellom ordvarianter unngår man altså å begrense informasjonssøk til bestemte bøyninger av ordene. I tillegg minsker man antall distinkte termer som trengs for å representere en dokumentmengde, noe som betyr besparelse i minnebruk og prosesseringstid. I mange språk, for eksempel i norsk, skiller morfologiske varianter seg fra hverandre ved at de har forkjellige endinger, og dermed en felles rot. En måte å klassifisere varianter av ord på er å redusere ord til rotform, eller stammeform. Denne fremgangsmåten kalles stemming, og algoritmer som tar for seg dette kalles gjerne stemmere. Nøkkeltermer i søkestrenger og dokumenter representeres da heller av stammer enn av opprinnelige ord Evaluering av stemmere I IR-applikasjoner spiller det vanligvis ikke noen rolle om de genererte stammene er faktiske ord. Det som er viktig er at ord av samme grunnbetydning sammenfaller, og at ord med forskjellige betydninger kan skilles fra hverandre. Et eksempel på ønskelig stemming er at både konge og kongelighet blir redusert til kong, mens kongle og kongler blir redusert til kongl. Stemming er imidlertid ingen triviell oppgave, og stemmere gjør uunngåelig feil. Et eksempel er stemming av ord som har mer eller mindre uvanlige bøyninger, som at skrupler kan bli skrupl mens skruppel forblir. Her har stemmeren mislykkes i å gruppere de to variantene. Dette kalles en understemmingsfeil. Et annet eksempel er stemming av ord som har en typisk bøyningsending uten at de er bøyde, som at fetter blir fett eller at både tanks og tanke blir tank. Her sammenfaller ord som ikke har noen semantisk tilknytning til hverandre, og dette kalles overstemmingsfeil. I tillegg finner man i de fleste språk eksempler på at ord er tvetydige uten kontekst, som en tanke og å tanke. Det finnes stemmingsalgoritmer som er kontekstsensitive, men disse er langt mer komplekse og bundet til språk enn algoritmer som ikke tar hensyn til kontekst. Kontekstsensitive algoritmer ser også ut til å bare delvis lykkes i klassifiseringen, og kan dermed være upålitelige. I prosjektet kan det bli nyttig å evaluere og justere stemmere for å komme frem til en bedre løsning. Det finnes flere måter å måle ytelsen til en stemmer på Direkte vurdering Dette er enn heller primitiv måte å evaluere stemmerytelse på. Her er det en fordel å danne en fasit med forhåndsdefinerte konseptuelle grupper av ord. På denne 88

95 KAPITTEL 9. PREPROSESSERING måten kan man verifisere at forsøkssett av ord sammenfaller i riktige grupper. Fremgangsmåten er kanskje mest tjenlig ved utvikling av stemmingsalgoritmer og justering av stemmereglene som algoritmen bruker Presisjon og kompletthet Når man jobber med systemer for IR kan man se på utslag i presisjon og kompletthet som mål på stemmerytelse. Her brukes dokumentsamlinger som forsøkssett, og ferdig definerte emnekart kan brukes som fasit. Dette er en aktuell fremgangsmåte for gruppen ved utprøving av forskjellige algoritmer og regler for stemming Feiltelling Feilraten ved stemming kan være en bra pekepinn på stemmerytelse. Her ser man på sammenfallsraten, som er andel ekvivalente par av ord som havner i samme gruppe, og entydighetsraten, som er antall ikke-ekvivalente ord som forblir distinkte etter stemming. Videre finner man under- og overstemmingsraten: Understemmingsrate: 1 - sammenfallsrate Overstemmingsrate: 1 - entydighetsrate Her vil en høy grad av understemming vil minke graden av kompletthet i IRsøk, og en høy grad av overstemming vil gå ut over presisjonen. Selv om det er fordelaktig å redusere antall distinkte termer i IR er det bare nyttig opp til et visst punkt. Etterhvert får man høye overstemmingsrater, og små økninger i kompletthet vinnes på bekostning av større tap av presisjon Stemmerstyrke Svake stemmere håndterer få varianter av ord, slik at kun tett relaterte ord sammenfaller. Man unngår derfor mange overstemmingsfeil, men får flere understemmingsfeil. Sterke stemmere fjerner flere endinger og kombinasjoner av endinger, og gir en mye høyere grad av sammenfall. Man får da flere overstemmingsfeil, men færre understemmingsfeil. Forskjellig styrke kan være ønskelig til forskjellige formål, og stemmerstyrke gir derfor en måte å vurdere stemmerytelse på. For måter å måle stemmerstyrke på, se [19] Algoritmer Den kanskje mest banale algoritmen for stemming er trunkering. Ved trunkering avkortes ord som overskrider en viss lengde. Med korte stammer får man da mange overstemmingsfeil, mens om man tillater lengre stammer kan man få flere understemmingsfeil. Det finnes imidlertid algoritmer som tar hensyn til andre egenskaper ved ord enn bare lengden. 89

96 KAPITTEL 9. PREPROSESSERING Lancaster Lancaster-algoritmen for stemming ble utviklet av Chris Paice ved universitetet i Lancaster på slutten av 80-tallet. Algoritmen er iterativ og fjerner endinger til den konvergerer. Stemmeren opererer med en separat fil med regler, som kan justeres. Med standard regelsett er Lancaster en heller tung stemmer, med aggressiv gruppering av ord. [2] Porter Porter-algoritmen for stemming ble utviklet av Martin Porter ved universitetet i Cambridge på 80-tallet. Porter baserer seg på at ord-endinger ofte er sammensatt av mindre endinger. Algoritmen er lineær og har fem steg der regler anvendes i hvert steg. Porter-algoritmen har vært mye brukt og omtalt de siste 20 årene. Den er implementert i flerfoldige programmeringsspråk, og tilpasset flerfoldige naturlige språk. [5] Lovins og Dawson Lovins-algoritmen for stemming ble utviklet av Julie Beth Lovins ved MIT i Stemmeren er kontekstsensitiv, og foregår i ett trinn, der den lengste endingen funnet for hvert ord blir fjernet. Algoritmen er derfor avhengig av et stort sett med regler, noe som fort blir problematisk. Algoritmen forsøker også å danne ord av stammer for å forsikre seg om at de sammenfaller med ord av lignende betydning. På dette punktet ser algoritmen ut til å svikte i flere tilfeller. [23] Dawson-algoritmen for stemming baserer seg på Lovins-algoritmen, og ble utviklet av J. L. Dawson ved universitetet i Cambridge på midten av 70-tallet. Den utvider regelsettet til Lovins og benytter en annen fremgangsmåte for danning av ord. Et problem med denne stemmeren kan være at den på grunn av sin kompleksitet er vanskelig å tilpasse andre språk. [17] Krovetz Krovetz-algoritmen for stemming ble utviklet av Bob Krovetz ved universitetet i Massachusetts i Algoritmen baserer seg på lingvistisk morfologi, og fjerner effektivt og nøyaktig bøyningsendinger. Stemmeren er heller lett, og blir derfor ofte brukt sammen med en annen stemmer, som Lancaster eller Porter, der sterkere stemming er ønskelig. [22] Implementasjoner og verktøy Stemmere er nyttige verktøy i IR, og brukes i mange av dagens løsninger. IRverdenen er imidlertid kraftig dominert av engelsk, og tilgjengeligheten på imple- 90

97 KAPITTEL 9. PREPROSESSERING mentasjoner for mindre språk reflekterer dette. Det finnes ikke så alt for mange stemmere for norsk, men det finnes verktøy som kan brukes som støtte i utviklingen av stemmingsalgoritmer for vilkårlige språk Snowball Snowball er et lite strengprosesseringsspråk laget for utvikling av stemmingsalgoritmer til bruk i IR. Mannen bak Snowball er tidligere nevnte Martin Porter, som nevner akkurat mangelen på tilgjengelige stemmere for andre språk enn engelsk som en viktig grunn til at Snowball ble realisert. Han nevner også at Snowball er et lite språk, og anslår at det kan læres på en times tid om man har erfaring med programmering. [1] PyStemmer PyStemmer er et Python-grensesnitt til Snowball. I PyStemmer finner man blant annet en implementasjon av Porter-algoritmen med norsk regelsett. PyStemmer er kryss-plattform og åpen kilde, og ble foreslått av kunden. Den er svært aktuell for prosjektet, og det kan også bli aktuelt å bruke PyStemmer/Snowball til å implementere en annen stemmingsalgoritme enn Porter for norsk. [11] 91

98 Kapittel 10 Latent semantisk indeksering Dette kapittelet gir en kort introduksjon til LSI, dens fordeler og ulemper, samt hvordan den brukes. Kapittelet baserer seg hovedsaklig på [24] og [18] Om LSI LSI er en teknikk som brukes for å finne relatert informasjon. Den forsøker å løse to av de største problemene innen informasjonsgjenfinning, nemlig polysemi- og synonymproblemet. Polysemi er faktumet at et ord kan ha flere meninger. Et eksempel på dette er ordet tilhenger, som kan bety både supporter og tilhenger til bil. Betydningen av ordet er som oftest gitt av konteksten. Vanlige søkemetoder har derimot ingen forståelse for semantikk, siden de kun ser på om et dokument inneholder et ord eller ikke. Synonymproblemet innebærer at flere ord kan ha samme mening, for eksempel ordene tog og lokomotiv. Dersom en ønsker å lese artikler om lokomotiv, og bruker søkeordet lokomotiv, ønsker en selvfølgelig også å få returnert de artiklene som bruker ordet tog. Vanlige søkemetoder som lider av disse problemene, har flere ulemper. For det første vil presisjonen i søkeresultatene være lav, og mye av informasjonen som returneres vil være irrelevant for brukeren. Et annet problem er komplettheten i søkeresultatene, siden en ofte får returnert en mindre andel av den relevante informasjonen som er tilgjengelig. Dette har sammenheng med at det finnes et utall forskjellige måter å forklare det samme konseptet på. Likevel vil et menneske kunne se en relevans mellom forskjellige artikler som handler om det samme temaet, selv om artiklene ikke alltid bruker de samme ordene. Det er her LSI kommer til sin prakt. LSI antar nemlig at dersom to artikler inneholder mange av de samme ordene, vil disse artiklene ha en viss relasjon. De betyr at et søk på lokomotiv også vil returnere dokumenter som handler om lokomotiver, men som ikke nødvendigvis inneholder 92

99 KAPITTEL 10. LATENT SEMANTISK INDEKSERING nettopp det ene spesifikke ordet Vektorromsmodellen LSI er en utvidelse av vektorromsmodellen (VSM, eng.: vector space model), som er en algebraisk modell med bruksområder innen informasjonsfiltrering og informasjonsgjenhenting. Denne modellen ble brukt for første gang i SMARTsystemet 1, som ble introdusert på 1950-tallet. VSM består av tre faser. I den første fasen vil begreper bli hentet ut fra dokumentene, som beskrevet i kapittel 9. Videre vil disse begrepene bli vektet, en teknikk som blir beskrevet litt nærmere i kapittel Til slutt vil dokumentene bli rangert med tanke på søkestrengen basert på et valgfritt mål for relevans Vektorrommet Begrepene som ekstraheres fra dokumentene i det første steget danner en vektor. Videre vil hvert dokument bli representert med en slik vektor. Verdien på hvert dokuments vektorelementer forteller hvorvidt dokumentet inneholder det gitte begrepet eller ikke. En verdi høyere enn null betyr at dokumentet inneholder det gitte ordet, mens en verdi lik null innebærer at ordet ikke finnes i dokumentet. Disse vektorene representerer posisjonene til dokumentene i et multidimensjonelt rom. Dette rommet vil ha like mange dimensjoner som det finnes begreper i dokumentsamlingen. Hvert begrep vil bli gitt hver sin akse, som alle står vinkelrette på hverandre. Når man plasserer disse vektorene ut i rommet vil nærliggende vektorer referere til dokumenter som har mange felles ord. Dokumenter som deler få ord vil derimot ha vektorer som ligger langt fra hverandre. Figur 10.1: Et eksempel på et vektorrom 1 System for the Mechanical Analysis and Retrieval of Text 93

100 KAPITTEL 10. LATENT SEMANTISK INDEKSERING Et eksempel på et slikt vektorrom ser man i figur Her er det for enkelthets skyld kun brukt tre begreper, noe som gir et enkelt tredimensjonelt rom. I tillegg er det plassert tre dokumenter inn i rommet, med de tilhørende vektorene også tegnet opp. Man ser at to av vektorene ligger relativt nærme hverandre, noe som tilsier at disse to dokumentene nødvendigvis inneholder mange av de samme ordene. Den tredje vektoren ligger derimot nokså langt fra de andre, og derfor vil dens dokument ha liten relevans i forhold til de to andre. Dette kan man utnytte til å finne relaterte dokumenter. I tillegg kan man utføre vanlige søk. Når et søk utføres vil søkestrengen behandles som et vanlig dokument. Det betyr at den vil bli gitt en vektor og dermed også plassert i det samme vektorrommet som resten av dokumentene. De dokumentene hvis vektorer ligger nærme søkestrengen sin vektor vil da være de mest relevante resultatene for søket Dokument/term-matrisen En vanlig måte å representere dette vektorrommet på er ved hjelp av en matrise. Her vil dokumentene listes opp langs den horisontale aksen, mens termene i dokumentene listes opp langs den vertikale aksen. Figur 10.2 viser et eksempel på en slik matrise. Dokumentene er her nummerert 6, 10 og 19, og tallene i matrisen representerer antallet forekomster av ordet i dokumentet. Figur 10.2: Et eksempel på dokument/term-matrise Avstanden mellom vektorene kan beregnes på flere forskjellige måter. En av disse er prikk-produktet, hvor en teller antall felles begreper vektorene har. De dokumentene hvis vektorer har høyest antall like termer som søkestrengvektoren blir regnet som de beste treffene. En annen måte å sammenligne vektorene på er basert på cosinus-koeffisientene. Denne metoden ligner på prikk-produktet, men resultatet fra denne blir i tillegg normalisert med produktet av vektorlengdene. 94

101 KAPITTEL 10. LATENT SEMANTISK INDEKSERING VSM vs. tradisjonelle søkemetoder Søking i vektorrommet har flere fordeler fremfor mer tradisjonelle søkemetoder. For det første kan dokumentene sorteres etter hvor like de er. Dette igjen fører til at man kan begrense søket til å kun inneholde for eksempel de femten mest like dokumentene. I tillegg vil det ofte være slik at de dokumentene som finnes høyt oppe på resultatlisten er de mest relevante for søket LSI i praksis Det fleste implementasjonene av LSI bruker Singular Value Decomposition (SVD) til å finne assosiasjoner mellom ordene i de relevante dokumentene. Dette innebærer å redusere vektorrommet slik at det inneholder et redusert antall dimensjoner. SVD-algoritmen gjør dette samtidig som den prøver å holde den relative avstanden mellom vektorene så lik som mulig. I og med at antall dimensjoner vil reduseres, vil enkelte av begrepene slås sammen. Dette vil føre til at man mister informasjon. Det viser seg derimot at mesteparten av denne informasjonen som går tapt er irrelevant, og det som gjenstår er underliggende sammenhenger mellom dokumentene. Selv om LSI har mye positivt å tilføre, har den også sine ulemper. Et eksempel på dette er størrelsen på matrisene det opereres på. For at hastigheten skal være respektabel bør disse være lokalisert i minnet. Kravene på maskinvaren blir bare større ettersom størrelsen på dokumentsamlingen vokser. Et annet problem er ved søkehastigheten. Mer tradisjonelle søkemetoder vil kun se på dokumenter som inneholder de gitte søkeordene. LSI vil derimot sammenligne et dokument med alle andre dokumenter, noe som fører til at søk med LSI typisk tar lenger tid SVD vs. SDD Som allerede nevnt er SVD den mest brukte algoritmen som brukes for å redusere den originale matrisen. Det finnes imidlertid alternativer til denne. En av disse er Semi Discrete Matrix Decomposition (SDD), som i større og større grad begynner å tatt i bruk i sammenheng med LSI. Hovedforskjellen på SDD og SVD er måten de lagrer og behandler matrisene på. Ord-dokument-matrisen er som allerede nevnt bygget opp av de forskjellige begrepene i dokumentene, samt dokumentene selv. Dersom dokumentsamlingen er av en viss størrelse, vil det nødvendigvis være slik at et dokument kun inneholder en brøkdel av alle begrepene. Mesteparten av matrisen vil derfor som oftest kun inneholde en null-verdi, som sier at et dokument ikke inneholder det gitte begrepet. Det er nettopp dette fenomenet SDD tar hensyn til. I praksis vil bruk av SDD føre til at matrisene tar mindre diskplass, noe som igjen vil føre til økt ytelse ved søking. Ulempen med SDD er at reduseringen av den originale matrisen tar 95

102 KAPITTEL 10. LATENT SEMANTISK INDEKSERING mye lenger tid, siden utregningene som må til er mer avanserte Vekting En metode man kan bruke for å få bedre resultater ved bruk av LSI er ordvekting. Bakgrunnen for denne påstanden er følgende to antakelser: Ord som forekommer ofte innad i et og samme dokument er sannsynligvis mer meningsfulle enn ord som bare forekommer én gang. Ord som blir brukt i flertallet av dokumentene er ofte mindre interessante enn mer dokumentspesifikke ord. Den første antakelsen gir opphav til lokal vekting. Dette innebærer å gi større lokal vekt til ord som forekommer ofte i et dokument enn de som forekommer sjelden. Lokal vekting vil føre til at de ordene som brukes sjelden ikke ignoreres i søkeresultatet. Den andre av disse antakelsene gjelder generelt for alle dokumentene, og kalles global vekting. Her vil man gi en større global vekt til ord som kun forekommer i et fåtall dokumenter, enn til de ordene som brukes i flertallet av dokumentene. Også her er meningen med vektingen å unngå at de potensielt interessante ordene skal ignoreres. I tillegg er det vanlig å normalisere som et siste steg i vektingsprosessen. Dette gjøres for å unngå at ordrike dokumenter overgår de mindre dokumentene i søkeresultatene. Normaliseringen vil kreditere små dokumenter og straffe de store dokumentene, slik at alle dokumentene til slutt har like mye innvirkning i søkingen. I praksis vil disse tre vektene multipliseres sammen, og resultatet gir verdien som til slutt brukes i matrisen. 96

103 Kapittel 11 Valg av løsning I dette kapittelet evalueres de alternative løsningene i forhold til evalueringskriteriene satt opp i samarbeid med kunden (se kapittel 6) Metode for evaluering av løsninger Evaluering av løsninger vil skje på grunnlag av evalueringskriteriene (EK) som ble gitt i tabell 6.2. De forskjellige løsningene vil bli vektet ut fra hvilken grad de dekker de forskjellige evalueringskriteriene (DG). Denne vektingen vil følge samme konvensjon som den tidligere vektingen av prioriteter med 1, 2 eller 3. Vekt 1 betyr her lav grad av dekning i forhold til det aktuelle kriteriet, mens 3 betyr høy grad av dekning. En totalsum blir regnet ut fra følgende formel: T otalsum = (EK DG) Totalsummen blir siden justert ut fra evalueringskriteriene som var med i vurderingen for å gi et tall på skalaen fra 1 til 3: Justert sum = T otalsum EK Valg av løsning gjøres på grunnlag av den justerte summen. Tabellene som brukes videre i kapittelet vil følge malen som vist i tabell Tabell 11.1: Oppsett av tabell for vurdering av løsning EK... Justert sum Løsning 1 Dekningsgrad... Justert sum Løsning 2 Dekningsgrad... Justert sum Løsning n Dekningsgrad... Justert sum 97

104 KAPITTEL 11. VALG AV LØSNING Figur 11.1: Avrunding av justert sum Denne summen må så rundes av korrekt som vist i figur Siden skalaen går fra 1 til 3, og ikke fra 0,5 til 3,5, må man ta spesielle hensyn når man runder av. 1 til 1,66 rundes av til 1. Området fra 1,67 til 2,33 rundes av til 2. 2,34 til 3 rundes av til 3. I de tilfelle hvor løsningene kommer svært likt ut vil også den uavrundete summen oppgis Vurdering av ferdigløsninger Dersom en ferdigløsning som tilfredsstiller kunden er tilgjengelig på markedet, vil det være aktuelt å se nærmere på denne. I kapittel 4 ble noen aktuelle prosjekter beskrevet. De fleste av disse prosjektene er rene forskningsprosjekter, men enkelte av resultatene ser ut til å bli brukt i kommersielle produkter. Av disse prosjektene var det kun tre som hadde tilgjengelige produkter på markedet. I tabell 11.2 blir disse evaluert ut fra evalueringskriteriene EK1, EK5 og EK12 i tabell 6.2. Gruppen anser disse som de mest sentrale evalueringskriteriene for en ferdigløsning. Tabell 11.2: Tabell for vurdering av ferdigløsninger EK1 EK4 EK11 Justert sum Autonomy WEBSOM OASIS Da Autonomy er et kommersielt produkt var det ikke mulig å oppdrive hvorvidt det ble benyttet LSI eller ikke. Det må dermed antas at løsningen ikke benytter LSI. 98

105 KAPITTEL 11. VALG AV LØSNING Ut fra dette skjemaet ser det ikke ut til at det er funnet en ideell ferdigløsning. Det kan også anses som kritisk at løsningen både skal være gratis og benytte LSI. Det er på dette grunnlag gitt at en ferdigløsning er uaktuelt Vurdering av løsninger for egenutvikling Som det ble fremstilt i foregående delkapittel vil en total ferdigløsning være uaktuelt for dette prosjektet av flere grunner. Det blir derfor aktuelt å se på hvordan det kan utvikles en ny løsning. Denne løsningen vil kunne inneholde både egenutviklede komponenter og åpen kildekode Vurdering av implementasjonsomgivelser Det er et absolutt krav at det overordnede programmet skal være implementert i Python. Imidlertid er det opp til gruppen å avgjøre hva eventuelle interne funksjoner i programmet skal være implementert i. De mest relevante alternativene vurderes her. Tabell 11.3: Tabell for vurdering av implementasjonsomgivelser EK5 EK8 Justert sum Python Pythonmodul i C Pythonmodul i Java Selvstendig program Tabell 11.3 viser at Python kommer best ut, med selvstendige programmer som en god nummer to. Imidlertid har disse to løsningene ulike bruksområder. Konklusjonen må derfor bli at Python bør brukes jevnt over, mens selvstendige programmer kan benyttes der Python ikke er effektivt nok Vurdering av splittingløsninger Ved splitting av tekst skal teksten deles opp i passende biter, og omliggende formatering skal forkastes. Det er viktig at splitteren ikke etterlater mye støy det er vanskelig å rydde opp i, som teksten man finner inne i markup-elementer. Den bør altså fjerne redundante data, noe som vil øke presisjonen. Det er også viktig at den ikke fjerner meningsfylte data, ved for eksempel å dele opp særnavn. Dette går potensielt utover både kompletthet og presisjon. I tabell 11.4 settes ulike alternativ opp mot hverandre. Naiv splitting tar hverken hensyn til markup eller særnavn, mens flerstegs splitting tar hensyn til alle disse. 99

106 KAPITTEL 11. VALG AV LØSNING Tabell 11.4: Tabell for vurdering av splittingløsninger EK2 EK5 EK6 EK7 EK9 EK10 Justert sum Naiv splitting Sporing av fraser i markup Splitting med markupfjerning Sporing av særnavn Flerstegs splitting Tabellen viser at flerstegs splitting kommer best ut blant alternativene. Man høster da inn fordelene ved de andre formene for splitting, dog på bekostning av en viss økning i kjøretid Vurdering av stoppordløsninger Hovedpoenget med stoppordlisten er å redusere antallet ord, slik at LSI-algoritmen fullfører raskere. Dette er analogt med at den fjerner flest mulig ord som ikke er meningsfulle i seg selv. Tabell 11.5 setter de ulike alternativene opp mot hverandre. Tabell 11.5: Tabell for vurdering av stoppordløsninger EK3 EK5 EK7 EK8 Justert sum Tredjeparts liste Egenprodusert liste Kombinasjon Ingen stoppordliste Tabellen viser at en kombinasjon av en tredjeparts liste og en egenprodusert liste kommer best ut. Dette virker logisk, da dette gir en større liste (forutsatt at ikke den ene listen er et direkte subsett av den andre, noe som kun skjer i spesialtilfeller) Vurdering av løsninger for stemming En viktig oppgave for en stemmer er å redusere redundante data. Stemmeren reduserer antall distinkte termer som trengs for å representere dokumenter i senere beregninger. I denne sammenhengen tolkes derfor bøyningsendinger og enkelte andre ordvedheng som redundante data. En annen viktig oppgave er å øke kompletthet ved søk. Dette skjer når ord med lignende semantiske tolkninger representeres med samme stammeform. Ved ag- 100

107 KAPITTEL 11. VALG AV LØSNING gressiv stemming vil ord med forskjellige tolkninger få samme stamme. Dette må ikke i for stor grad gå på bekostning av presisjon. Stemmeren bør være tilpasset norsk, da det ikke kan brukes mye ressurser på en slik tilpasning. Dersom algoritmen kan konfigureres åpnes muligheten for å skreddersy stemmeren i favør av kompletthet og presisjon. Tabell 11.6: Tabell for vurdering av løsninger for stemming EK3 EK5 EK6 EK7 EK8 EK9 EK10 Justert sum Norsk Porter-stemmer i PyStemmer Implementere Lancaster i Snowball Implementere Dawson i Snowball Implementere Krovetz i Snowball Ingen stemming Tabell 11.6 viser at PyStemmer kommer best ut. Den har ferdig implementert norsk stemmer og regelsettet kan konfigureres. Ingen stemming kommer dårligst ut. Her fjernes ingen redundante data, og komplettheten kan bli mye lavere enn ved bruk av en god stemmer Vurdering av vekting Vekting av matrisen skal føre til en forbedring av resultatene fra LSI. Ingen av disse vil kreve spesielt mye tid til utregning, men vil likevel ha stor innvirkning på kvaliteten på resultatene. En evaluering av forskjellige vektingsalternativer og kombisjoner av dem vises i tabell Tabell 11.7: Tabell for vurdering av vekting EK5 EK9 EK10 Justert sum Ingen vekting Kun lokal vekting Kun global vekting Kun normalisering Alle vektinger dem. 2 Det vil ikke gi stor tidsdifferanse å bruke samtlige vektinger i forhold til å kun bruke én av 101

108 KAPITTEL 11. VALG AV LØSNING Ifølge vurderingen vil det lønne seg å bruke alle vektingstypene, det vil si både lokal, global og normalisert vekting samtidig. Derfor er dette noe som bør justeres og eksperimenteres med i senere faser Vurdering av SVD vs. SDD Poenget med SVD- og SDD-algoritmene er å redusere dokument/term-matrisen, slik at støy blir fjernet og underliggende semantiske sammenhenger blir avdekket. Forskjellen på algoritmene vil i all hovedsak være hvor vanskelige de er å implementere, samt hvor hurtige de er. Hurtigheten på algoritmene kan sees på i to forskjellige faser. Den første vil være relatert til reduseringen av hovedmatrisen, mens den andre går mer på hvor raskt søket vil bli i etterkant gitt at man bruker den respektive algoritmen. Siden det er sistnevnte som er viktigst i praksis er det denne det blir lagt mest vekt på i EK5. Tabell 11.8: Tabell for vurdering av SVD vs. SDD EK5 EK7 EK8 EK10 Justert sum SVD , 5 3 SDD , 4 3 Ut fra tabell 11.8 kommer det frem at SVD vil være det marginalt beste valget for prosjektet. Dette er et realistisk resultat, siden de to algoritmene er jevngode på de fleste områdene, men samtidig vil SVD være enklere enn SDD å implementere. 102

109 KAPITTEL 11. VALG AV LØSNING 11.4 Konklusjon Gruppen har nå evaluert de alternative løsningene ut fra evalueringskriteriene, og følgende valg ble gjort på grunnlag av vektingen: Ferdigløsninger: Ingen ferdigløsning vil bli benyttet. Splitting: Det vil her benyttes iterativ splitting med tilstand og lookahead. Fjerning av stoppord: Det vil her benyttes en kombinasjon av tredjepartsog egenprodusert liste. Stemming: Til stemming vil PyStemmer bli brukt. Vektingsalgoritme: Det vil benyttes både lokal, global og normalisert vekting. Matrisereduksjon: Til matrisereduksjon vil SVD-algoritmen benyttes. Programmeringsløsning Python vil i all hovedsak bli benyttet, med innslag av separate programmer der det er hensiktsmessig. Disse valgene reflekterer kundens ønsker for det ferdige produktet, samt rammebetingelsene som er satt for prosjektet med tanke på tid og ressurser. 103

110 Vedlegg A Skjermbilder Figur A.1: Eksempel på mal for artikkel del 1 104

111 VEDLEGG A. SKJERMBILDER Figur A.2: Eksempel på mal for artikkel del 2 105

112 Vedlegg B Use-Case Figur B.1: Use-case diagram for å opprette nytt innhold 106

113 Vedlegg C Definisjoner og forkortelser Emnekart Internasjonal standard, også kjent som ISO/IEC 13250:2003, brukes for å representere kunnskap med fokus på gjenfinnbarhet GPL IR Kategorisering Klaser Kompletthet LSI Morfologi General Public Licence - En lisens som gir brukeren rett til å lese og redigere den lisensierte kildekoden. Information Retrieval - Emnet som tar for seg hvilke dokumenter som bør hentes ut fra en mengde for å møte brukerens informasjonsbehov. Det å gruppere ideer og objekter i kategorier. (clusters) - Delmengder av data der dataene i hver delmengde har fellestrekk. (recall) - Forholdet mellom antall relevante dokumenter funnet og antall relevante dokumenter. latent semantisk indeksering - En teknikk for prosessering av naturlig språk. (lingvistisk) - Formverket i et språk, ordbøynings- og ordlagingslære, formlære. Preprosessering Forberede data for bruk i en annen prosess. Presisjon SDD SMART Splitting (precision) - Forholdet mellom antall relevante dokumenter funnet og antall dokumenter funnet. Semi Discrete Matrix Decomposition - Algoritme for matrisereduksjon. System for the Mechanical Analysis and Retrieval of Text. Før tekst kan analyseres må den splittes opp i deler, enten i form av enkeltord, delord eller grupper av ord. 107

114 VEDLEGG C. DEFINISJONER OG FORKORTELSER Stemming Stoppord SVD Use-case VSM XML Redusere ord til rotform, eller stammeform Ord som forekommer svært ofte i flertallet av dokumentene. Disse ordene vil ha liten eller ingen verdi for videre tolkning av dokumentets innhold. Singular Value Decomposition - Algoritme for matrisereduksjon. Et scenarie som beskriver hvordan et system samhandler med en bruker eller et annet system. Vector Space Model - Algebraisk modell for informasjonsfiltrering og IR. extended Markup Language - Et generalisert formateringsspråk. 108

115 Vedlegg D Referanser [1] ( ). [2] ( ). [3] ( ). [4] ( ). f/classification.html. [5] ( ). [6] ( ). [7] ( ). [8] ( ). [9] ( ). [10] ( ). [11] ( ). [12] ( ). [13] ( ). [14] ( ). [15] ( ). [16] ( ). [17] J. L. Dawson, Suffix removal for word conflation, Bulletin of the Association for Literary and Linguistic Computing 2 (1974), no. 3,

116 VEDLEGG D. REFERANSER [18] J. Dowling, Information retrieval using latent semantic indexing (lsi) and a semi-discrete matrix decomposition (sdd), (2002). [19] W. B. Frakes and C. J. Fox, Strength and similarity of affix removal stemming algorithms, ACM SIGIR Forum 37 (2003), no. 1, [20] P. Gietz, Report on automatic classification systems, DAASI International (2001). [21] R. Johnston, An overview of latent semantic indexing. [22] R. Krovetz, Viewing morphology as an inference process, (1993), [23] J. B. Lovins, Development of a stemming algorithm, Mechanical Translation and Computational Linguistics 11 (1968), [24] C. Yu, J. Cuadrado, M. Ceglowski, and J. S. Payne, Patterns in unstructured data, (2002)

117 Del III Kravspesifikasjon 111

118 112

119 INNHOLD Innhold 1 Innledning Hensikt Omfang Oversikt Overordnet beskrivelse Produktperspektiv Systemgrensesnitt Brukergrensesnitt Maskinvaregrensesnitt Programvaregrensesnitt Produktfunksjoner Brukerkarakteristikk Use-case Aktører Tekstlige use-case Spesifikke krav Introduksjon Funksjonelle krav Krav til preprosessering av dokumenter Krav til klasing Krav til kategorisering Krav til konfigurerbarhet Ikke-funksjonelle krav Ytelse Implementasjonsomgivelse Vedlikeholdbarhet Portabilitet Brukergrensesnitt

120 INNHOLD 5 Use-case-basert estimering 137 A Beskrivelse av dataflytdiagrammer 140 A.1 Eksterne grensesnitt A.2 Prosesser A.3 Dataflyt B Beskrivelse av use-case 142 C Sporingsmatrise 143 D Definisjoner og forkortelser 144 E Referanser

121 FIGURER Figurer 2.1 Nivå 0 dataflytdiagram for programmet Brukergrensesnitt for programmet Skjema for use-case-basert estimering A.1 Eksternt grensesnitt i dataflytdiagrammer A.2 En prosess i dataflytdiagrammer A.3 Dataflyt i dataflytdiagrammer

122 116 FIGURER

123 TABELLER Tabeller 3.1 Administrator Publiseringsverktøy Preprosesseringsmodul Klasingsmodul Kategoriseringssmodul Use-case for preprosessering av dokumenter Use-case for klasing av en dokumentsamling Use-case for kategorisering av nye dokumenter Kravidentifikatorer Beskrivelse av vektingsgrader Krav til preprosessering Krav til klasing Krav til kategorisering Krav til konfigurerbarhet Ytelseskrav til systemet Krav til implementasjonsomgivelse Krav til vedlikeholdbarhet Krav til portabilitet Krav til brukergrensesnitt Vekting av aktører B.1 Beskrivelse av syntaks brukt i aktørtabellene B.2 Beskrivelse av syntaks brukt i de tekslige use-casene C.1 Sporingsmatrise

124 118 TABELLER

125 Kapittel 1 Innledning Dette kapittelet gir en oversikt over innholdet i kravspesifikasjonen. Strukturen på spesifikasjonen er basert på IEEEs Recommended Practice for Software Requirements Specifications [1], men vil avvike noe for å tilpasses føringer og anbefalinger lagt til dette prosjektet. If you don t know where you re going, you re unlikely to end up there. Forrest Gump 1.1 Hensikt Denne kravspesifikasjonen er utarbeidet i samarbeid med Bouvet, og skal klargjøre kravene til programmet som utvikles. Kravene er delt inn i funksjonelle og ikkefunksjonelle krav. De funksjonelle kravene skal beskrive funksjoner programmet eller deler av programmet skal utføre. De ikke-funksjonelle kravene skal beskrive rammene programmet skal utvikles innenfor. Målgruppen for kravspesifikasjonen er kunden og prosjektgruppen. Spesifikasjonen vil fungere som en kontrakt mellom de to partene som beskriver hva som er forventet av sluttresultatet. Den vil legges som grunnlag for videre konstruksjon og implementasjon, samt være til nytte for eventuell videreutvikling av programmet. 1.2 Omfang Kravspesifikasjonen omfatter kravene som er utarbeidet til programmet Paper- Prism. Dette programmet vil bli utviklet for Bouvet AS i forbindelse med faget TDT Kundestyrt Prosjekt ved NTNU. På sikt skal programmet kunne integreres med bedriftens eksisterende publiseringsverktøy. I dette prosjektet skal det 119

126 KAPITTEL 1. INNLEDNING i første omgang klargjøres hvorvidt en slik integrering vil være hensiktsmessig, basert på resultatene som kommer frem. Programmet som skal lages har som oppgave å automatisk kategorisere dokumenter i emnekart ved bruk av latent semantisk indeksering (LSI). Kategoriseringen vil foregå i to steg. Det første steget vil involvere å kategorisere en hel dokumentsamling opp mot et allerede eksisterende emnekart. Videre skal man kunne kategorisere enkeltstående dokumenter, og knytte disse opp mot en ferdigkategorisert dokumentsamling. Målet med programmet er å halvautomatisere kategoriseringen av dokumenter, som på det nåværende tidspunkt gjøres manuelt. 1.3 Oversikt Resten av denne kravspesifikasjonen er delt inn i følgende kapittel og vedlegg: Kapittel 2 inneholder en beskrivelse av de generelle faktorene som påvirker produktet og kravene til programmet. Kapittel 3 inneholder use-case for programmet. Kapittel 4 inneholder kravene til programmet. Kapittel 5 inneholder en use-case-basert estimering av timeforbruket i prosjektet. Vedlegg A beskriver syntaksen som er brukt i dataflytdiagrammene. Vedlegg B inneholder en mal for use-case. Vedlegg C inneholder en oversikt over forholdet mellom funksjonelle krav og use-casene. Vedlegg D inneholder definisjoner og forkortelser. Vedlegg E inneholder en liste over referansene i denne kravspesifikasjonen. 120

127 Kapittel 2 Overordnet beskrivelse Dette kapittelet beskriver de generelle faktorene som påvirker produktet og kravene til produktet. Den overordnede strukturen til programmet vil bli presentert, hvilket vil gi en bakgrunn som gjør det lettere å forstå kravene. 2.1 Produktperspektiv Programmet som skal utvikles vil ikke være et ferdig produkt klargjort for integrering i Bouvets eksisterende publiseringsverktøy. Bouvet ønsker selv å integrere programmet dersom resultatene virker lovende, men de vil da modifisere dette for sitt bruk. Figur 2.1 viser et dataflytdiagram på nivå 0 for programmet. Her illustreres det hvordan de to eksterne entitetene Administrator og Publiseringsverktøy samhandler med programmet. I første omgang vil programmet få inn en dokumentsamling spesifisert av administratoren, og gruppere disse dokumentene i klaser. Disse klasene vil benyttes til å skape dokument/emne-koblinger som kan legges inn i publiseringsverktøyet. Programmet vil deretter kunne ta inn et enkelt dokument, og returnere foreslåtte emner som passer til dette dokumentet. For en beskrivelse av syntaksen i dataflytdiagrammet, se vedlegg A. Det er definert fire grensesnitt for programmet: systemgrensesnitt, brukergrensesnitt, maskinvaregrensesnitt og programvaregrensesnitt. Disse vil bli forklart i de påfølgende avsnittene Systemgrensesnitt Målet med dette prosjektet er å finne ut hvorvidt en algoritme basert på LSI kan gjøre det enklere for forfattere å finne emner til sine artikler. Dersom dette gir gode resultater vil Bouvet vurdere å knytte programmet som utvikles til sitt eksisterende publiseringsverktøy. De vil da modifisere den produserte koden for å optimalisere denne mot sine systemer. Det er derfor viktig med ryddig og godt 121

128 KAPITTEL 2. OVERORDNET BESKRIVELSE Figur 2.1: Nivå 0 dataflytdiagram for programmet kommentert kode, slik at denne integreringen blir enklest mulig Brukergrensesnitt Kunden har gitt beskjed om at et grafisk brukergrensesnitt er mindre viktig, da programmet skal kunne flettes inn i deres eget produkt. Brukerne av publiseringsverktøyet vil ikke kommunisere direkte med programmet, men benytte dette gjennom det eksisterende publiseringsverktøyet. Derimot vil programmet måtte settes opp med en innledende klasing. Det vil dermed være nyttig med et brukergrensesnitt mot de administratorene som skal utføre denne jobben. Situasjonen er illustrert i figur 2.2. Som illustrert i figuren vil programmet ha to brukergrensesnitt: 1. Grensesnitt mot eksisterende system (publiseringsverktøy). 2. Grafisk grensesnitt mot administrator. Da programmet ikke skal integreres i publiseringsverktøyet som en del av dette prosjektet, vil det utstyres med et enkelt grafisk grensesnitt som illustrerer et publiseringsverktøy. På denne måten vil programmet være enklere å teste, samt at dette grensesnittet vil fungere som en god illustrasjon av programmets funksjonalitet. 122

129 KAPITTEL 2. OVERORDNET BESKRIVELSE Figur 2.2: Brukergrensesnitt for programmet Maskinvaregrensesnitt Programmet skal i første omgang kunne kjøres på en gjennomsnittlig datamaskin 1. Effektiviteten til indekseringen og søkingen er proporsjonal med ytelsen til maskinvaren. Dette gjelder spesielt med tanke på minnebruk. Det er derfor anbefalt å bruke følgende maskinvarekonfigurasjon: x86-arkitektur (AMD / Intel). Minst 2 GHz prosessor. Mellom 1 GB og 4 GB minne Programvaregrensesnitt Programmet vil bli utviklet i Python, og det kreves derfor at Python-rammeverket er installert på maskinen programmet skal bli tatt i bruk på. 2.2 Produktfunksjoner Hovedfunksjoner programmet skal utføre inkluderer: Automatisk kategorisere en dokumentsamling opp mot et emnekart (klasing). Basert på et allerede eksisterende emnekart og en dokumentsamling skal programmet returnere en liste over hvilke dokumenter som er relatert til hvilke emner. Automatisk kategorisere enkeltstående dokumenter, og knytte disse opp mot en indeksert dokumentsamling. Programmet skal kunne returnere en liste over hvilke emner et nytt dokument omhandler. Dette skal gjøres basert på en eksisterende kobling mellom emner og dokumenter. 1 Gjennomsnittlig datamaskin anno høsten

130 2.3 Brukerkarakteristikk KAPITTEL 2. OVERORDNET BESKRIVELSE Programmet som utvikles vil ha to hovedkategorier av brukere. Den første kategorien vil være artikkelforfatterne som skal benytte programmet til å finne emner relatert til sin artikkel. For disse brukerne vil det være viktig at programmet har et enkelt grensesnitt, da målet med programmet er å lette deres arbeid. Disse brukerne blir bare indirekte brukere av programmet, da de skal benytte programmet gjennom publiseringsverktøyet som illustrert i figur 2.2. Den andre kategorien av brukere er de som skal konfigurere programmet. Dette inkluderer den innledende klasingen av dokumenter og oppsett av konfigurasjonsparametere. Disse brukerne vil være utviklere fra Bouvet med høy kompetanse innen programmering. De skal jobbe direkte mot koden som er skrevet i prosjektet, og sannsynligvis også optimalisere denne for sitt bruk. 124

131 Kapittel 3 Use-case Dette kapittelet presenterer tekstlige use-case for de viktigste funksjonalitetene til programmet. Disse er viktige verktøy for å klargjøre kundens krav til programmet. Sammen med de spesifikke kravene i kapittel 4 vil disse uttrykke kundens ønsker for hvordan programmet skal fungere. For en beskrivelse av syntaksen som benyttes i kapittelet, se vedlegg B. Kapittelet vil først beskrive aktørene som er med i systemet. Deretter vil de tekstlige use-casene for systemet presenteres. Disse use-casene vil i kapittel 5 benyttes for å gjøre en use-case-basert estimering av tidsforbruket i prosjektet. 3.1 Aktører Dette avsnittet beskriver de ulike aktørene i systemet. Aktørene kan være både personer og deler av programmet. Aktørene Administrator, Publiseringsverktøy, Preprosesseringsmodul, Klasingsmodul og Kategoriseringsmodul beskrives i tabellene Aktør: Beskrivelse: Tabell 3.1: Administrator Administrator (A) Administratorens hovedoppgave er å installere systemet, samt vedlikeholde dette. Aktør: Beskrivelse: Tabell 3.2: Publiseringsverktøy Publiseringsverktøy (Pu) Publiseringsverktøyet er systemet som benyttes til å publisere nye dokumenter. I dette prosjektet benyttes et svært forenklet publiseringsverktøy utarbeidet av prosjektgruppen. 125

132 KAPITTEL 3. USE-CASE Aktør: Beskrivelse: Tabell 3.3: Preprosesseringsmodul Preprosesseringsmodul (Pr) Preprosesseringsmodulen tar inn ett eller flere dokumenter, og lager ordvektorer av disse. Aktør: Beskrivelse: Tabell 3.4: Klasingsmodul Klasingsmodul (Kl) Klasingsmodulen tar seg av klasingen av en eller flere ordvektorer. Aktør: Beskrivelse: Tabell 3.5: Kategoriseringssmodul Kategoriseringssmodul (Ka) Kategoriseringsmodulen tar seg av kategoriseringen av ett enkelt dokument ut fra eksisterende klasing. 3.2 Tekstlige use-case I dette avsnittet presenteres tekstlige use-case for de viktigste funksjonalitetene til programmet. Siden programmet baserer seg på svært lite interaksjon med fysiske brukere vil disse use-casene i stor utstrekning bygge på interne hendelser og interaksjon mellom programmets interne moduler. Tabellene viser de tekstlige use-casene for preprosessering, klasing og kategorisering. 126

133 KAPITTEL 3. USE-CASE Tabell 3.6: Use-case for preprosessering av dokumenter Preprosessering av dokumenter ID: UC-1 Mål: Gjøre et eller flere dokumenter om til ordvektorer. Forutsetning: Dokumentene må være lagret i XML-format. Slutt-tilstand: Dokumentene er gjort om til ordvektorer hvor ordene er splittet, stemmet, samt filtrert mot en stoppordliste. Trigger: Et dokument skal kategoriseres eller en dokumentsamling skal klases. Aktør(er): Preprosesseringsmodul (Pr) Administrator (A) Publiseringsverktøy (Pu) Grunnleggende 1. A mater inn en dokumentsamling [Alt. handlingssti A]. handlingssti: 2. Pr velger et ubehandlet dokument fra dokumentsamlingen. 3. Pr henter ut egennavn og lett identifiserbare fraser fra dokumentet, og legger disse i en ordvektor. 4. Pr splitter resten av dokumentet til en ordvektor. 5. Pr benytter stoppordfilter på ordvektoren fra steg Pr stemmer ordvektorene fra steg 5 for å fjerne flest mulig stemmingsformer. 7. Pr slår sammen ordvektorene fra steg 3 og 6 til en ordvektor. 8. Pr legger til den samlede ordvektoren fra steg 7 i en matrise. 9. Pr finner flere ubehandlede dokumenter i dokumentsamlingen. [Alt. handlingssti B] Alternativ handlingssti A: Alternativ handlingssti B: 10. Use-caset fortsetter fra steg 2. A1. Pu mater inn et enkelt dokument. A2. Use-caset følger grunnleggende handlingssti steg 3-7. A3. Pr sender ordvektoren videre til kategoriseringsmodulen. B1. Pr finner ingen flere ubehandlede dokumenter i dokumentsamlingen. B2. Pr sender matrisen med ordvektorer videre til klasingsmodulen. 127

134 KAPITTEL 3. USE-CASE Tabell 3.7: Use-case for klasing av en dokumentsamling Klasing av en dokumentsamling ID: UC-2 Mål: Koble en dokumentsamling opp mot en taksonomi. Forutsetning: Emnene må allerede være definert. Slutt-tilstand: Hvert dokument er tilordnet ett eller flere emne. Trigger: En kunde med en allerede eksisterende dokumentsamling ønsker å ta i bruk portalløsningen. Aktør(er): Administrator (A) Klasingsmodul (Kl) Preprosesseringsmodul (Pr) Publiseringsverktøy (Pu) Grunnleggende 1 A gir beskjed om at en dokumentsamling skal klases. handlingssti: 2 Pr preprosesserer dokumentene som vist i use-case UC Kl mottar en ordmatrise fra Pr. 4 Kl vekter verdiene i ordmatrisen. 5 Kl foretar en matrisereduksjon på ordmatrisen. 6 Kl foretar interne vektorsøk for å klase vektorene. 7 Kl sender en representasjon av klasingen til Pu. 8 Pu viser frem en representasjon av klasingen. 128

135 KAPITTEL 3. USE-CASE Tabell 3.8: Use-case for kategorisering av nye dokumenter Kategorisering av nye dokumenter ID: UC-3 Mål: Finne forslag til hvilke emner et dokument omhandler. Forutsetning: Man må ha en dokumentsamling som allerede er blitt kategorisert opp mot en taksonomi, samt en artikkel man ønsker å kategorisere. Slutt-tilstand: En liste over emner som har relevans til dokumentet. Trigger: En artikkelforfatter ønsker å finne forslag til emner til artikkelen sin. Aktør(er): Kategoriseringsmodul(Ka) Preprosesseringsmodul(Pr) Publiseringsverktøy (Pu) Grunnleggende 1. Pu gir beskjed om at en artikkel skal kategoriseres. handlingssti: 2. Pr preprosesserer artikkelen som beskrevet i use-case UC Ka mottar en preprosessert ordvektor fra Pr. 4. Ka mottar dokument-emne-koblinger fra Pu. 5. Ka lager emnevektorer av dokument-emne-koblingene. 4. Ka foretar et vektorsøk mellom ordvektoren og emnevektorene. 5. Ka leverer emnene funnet i vektorsøket til Pu, gradert etter relevans. 6. Pu mottar emnene. 129

136 Kapittel 4 Spesifikke krav Dette kapittelet besrkiver alle kravene til programvaren som skal utvikles. Ut fra disse kravene skal systemet kunne designes, og alle kravene skal kunne testes i testfasen. 4.1 Introduksjon Hvert av kravene i dette kapittelet vil bli identifisert med en kravidentifikator, også kalt krav-id. Disse vil gjøre det lettere å spore videre testing mot de aktuelle kravene. Funksjonelle krav vil tildeles en ID som starter med FK, mens IDen til de ikke-funksjonelle kravene vil starte med IF. Kravene vil videre få en påfølgende bokstav som identifiserer hvilken seksjon de tilhører. Kravene vil dermed identifiseres som følger: < Krav ID >=< F K IF > < Beskrivende bokstav >< Nummer > Tabell 4.1 viser hvilke kategorier av krav-ider som vil benyttes. Tabell 4.1: Kravidentifikatorer Krav-ID FK-P FK-C FK-K FK-T IF-Y IF-I IF-V IF-P IF-B Beskrivelse Funksjonelle krav til preprosessering. Funksjonelle krav til klasing. Funksjonelle krav til kategorisering. Funksjonelle krav til konfigurerbarhet (tilpasning). Ikke-funksjonelle krav til ytelse. Ikke-funksjonelle krav til implementasjonsomgivelser. Ikke-funksjonelle krav til vedlikehold. Ikke-funksjonelle krav til portabilitet. Ikke-funksjonelle krav til brukergrensesnitt. Alle kravene vil bli vektet ut fra hvor viktig kunden mener kravet er for programmet. En beskrivelse av de forskjellige vektingsgradene er gitt i tabell

137 KAPITTEL 4. SPESIFIKKE KRAV Tabell 4.2: Beskrivelse av vektingsgrader Vekt Beskrivelse 1 Kravet bør forsøkes innfridd, men vil ikke prioriteres dersom det oppstår tidspress. 2 Kravet bør innfris for at programmet skal tilfredstille kundens ønsker. 3 Kravet må innfris for at programmet skal tilfredstille kundens krav. 4.2 Funksjonelle krav Her vil de funksjonelle kravene som settes til programmet beskrives. En sporingsmatrise som viser hvordan de funksjonelle kravene er relatert til use-casene er gitt i vedlegg C Krav til preprosessering av dokumenter Preprosessering er den delen av programmet som utføres når et dokument skal splittes til en ordvektor. En ordvektor er en måte å representere et dokument på, der hvert ord er en dimensjon i vektoren. Hver dimensjon vil deretter bli vektet ut fra ordets viktighet for dokumentet. Tabell 4.3: Krav til preprosessering Krav-ID Beskrivelse av krav Vekting FK-P1 Programmet skal splitte dokumenter til ordvektorer. 3 Egennavn og fraser skal identifiseres som egne termer basert på tegnsetting under splittingen. FK-P2 Programmet skal utføre stemming på ordvektorer for 2 å fjerne flest mulig bøyningsformer. Egennavn og fraser skal ikke stemmes. FK-P3 Programmet skal fjerne ord som forekommer i flertallet 2 av dokumentene i dokumentsamlingen (stoppord) fra ordvektorene. FK-P4 Programmet skal ikke behandle tekstformatering som 3 om det er ord eller fraser. FK-P5 Programmet skal håndtere dokumenter på bokmål og 3 nynorsk. FK-P6 Programmet skal ikke feile ved mottak av ord og fraser 3 på andre språk enn norsk. FK-P7 Programmet skal tolke tekst med tegnsettet ISO

138 KAPITTEL 4. SPESIFIKKE KRAV Preprosessering vil være viktig for å forbedre resultatene av klasing og kategorisering. Preprosessering vil inkludere splitting, fjerning av stoppord og stemming. Målet er å få ut en ordvektor som definerer dokumentet på en mest mulig unik måte. Tabell 4.3 beskriver de funksjonelle kravene til preprosesseringen av dokumentene Krav til klasing Klasing er overgangen fra en enkel dokumentmatrise der alle ord er inkludert, til en matrise der dokumentene og emnene er samlet i klaser ut fra intern relevans. Klasingen vil ikke være synlig for brukerne av publiseringsverktøyet, men være en del av kjernen i programmet som administratorene har tilgang til. Klasing er det første som skal gjøres etter at programmet er installert. Tabell 4.4 beskriver de funksjonelle kravene til klasingen. Tabell 4.4: Krav til klasing Krav-ID Beskrivelse av krav Vekting FK-C1 Programmet skal kunne klase dokumentsamlinger. 3 FK-C2 Programmet skal kunne vise brukeren resultatet av 2 klasingen. FK-C3 Programmet skal lagre resultatet av klasingen persistent. 1 FK-C4 Programmet skal benytte en klasingsalgoritme som kan håndtere dokumentsamlinger på minst 2000 dokumenter Krav til kategorisering Dette avsnittet tar for seg krav som omhandler kategorisering av dokumenter. Å kategorisere et dokument vil i denne sammenheng si å finne alternative emner ut fra dokumentets innhold. Denne delen av programmet vil være synlig for brukerne av publiseringsverktøyet som den funksjonaliteten som settes i gang når de ønsker å finne emner til sin artikkel. Målet vil her være å presentere emner med høyest mulig relevans til den aktuelle artikkelen. Tabell 4.5 beskriver de funskjonelle kravene til kategorisering. 132

139 KAPITTEL 4. SPESIFIKKE KRAV Tabell 4.5: Krav til kategorisering Krav-ID Beskrivelse av krav Vekting FK-K1 Programmets kategoriseringsmodul skal kunne ta 3 imot et preprosessert dokument, og returnere en liste med emner som samsvarer med dokumentet. FK-K2 Programmet skal gradere mulige kategoriseringer ut 2 fra relevans. FK-K3 Programmet skal kunne knytte ett dokument til flere 3 emner (én-til-mange-relasjon). FK-K4 Programmet skal gi brukeren (artikkelforfatteren) mulighet til å velge hvilke av de alternative emnene dokumentet skal knyttes til Krav til konfigurerbarhet Programmet bør være konfigurerbart, da svært mange parametere vil ha innvirkning på programmets egenskaper under kjøring. Konfigurasjonen går ut på å justere parametere som endrer programmets oppførsel, samt muligheten for å bytte ut hele moduler av programmet. Tabell 4.6 beskriver de funksjonelle kravene til konfigurerbarhet. Tabell 4.6: Krav til konfigurerbarhet Krav-ID Beskrivelse av krav Vekting FK-T1 Utslagsgivende parametere skal kunne konfigureres av 3 administratoren via en konfigurasjonsfil. FK-T2 Programmet skal benytte generelle grensesnitt internt, 1 slik at moduler som splittere og stemmere enkelt lar seg skifte ut. FK-T3 Programmet skal inkludere muligheten for å endre 1 hvilken stoppordliste som skal benyttes. FK-T4 Maksimalt antall svar i resultatet av kategoriseringen skal kunne spesifiseres

140 4.3 Ikke-funksjonelle krav KAPITTEL 4. SPESIFIKKE KRAV Denne seksjonen tar for seg de ikke-funksjonelle kravene som stilles til programmet. Dette er krav som ikke fokuserer direkte på funksjonaliteten til programmet, men andre egenskaper som vil være viktige for brukerne Ytelse I et ferdig produkt vil ytelsen til programmet være viktig. Det vil være avgjørende for brukerne at responsen på kategoriseringen skjer innen rimelig tid. Ytelse er imidlertid ikke svært viktig i dette prosjektet, da programmet som utvikles vil være en prototype av et eventuelt ferdig produkt. Dette programmet skal ikke benyttes direkte mot sluttbrukerene, men til å teste hvorvidt denne typen kategorisering vil være hensiktsmessig. Ytelseskravene fra kunden er gitt i tabell 4.7. Tabell 4.7: Ytelseskrav til systemet Krav-ID Beskrivelse av krav Vekting IF-Y1 Programmet skal kunne håndtere en informasjonsmengde 3 på 200 emner og 2000 dokumenter. IF-Y2 Programmet skal kunne utføre klasing innen 12 timer. 2 IF-Y3 Programmet skal kunne utføre en kategorisering innen 2 2 minutter. IF-Y4 Programmet skal kunne håndtere simultane søk Implementasjonsomgivelse Kravene til implementasjonsomgivelse omhandler hvordan programmet blir implementert. Det settes krav til hvilke programmeringsspråk som skal benyttes, samt det overordnede kravet om at LSI skal benyttes i implementasjonen. Kravene til implementasjonsomgivelse er gitt i tabell

141 KAPITTEL 4. SPESIFIKKE KRAV Tabell 4.8: Krav til implementasjonsomgivelse Krav-ID Beskrivelse av krav Vekting IF-I1 Programmet skal benytte Python som primært programmeringsspråk. 3 IF-I2 Støttespråk som benyttes ved siden av Python skal 2 dokumenteres grundig. IF-I3 Biblioteker og moduler som ikke er programmerte av 2 gruppen skal dokumenteres med versjonsnummer og referanse til hvor modulen er hentet fra. IF-I4 Programmet skal benytte LSI Vedlikeholdbarhet Dette avsnittet tar for seg kravene som er satt til vedlikeholdbarheten til programmet. Dette inkluderer krav til kodekonvensjoner og dokumentasjon. Siden programmet skal kunne modifiseres for videre bruk er det svært viktig at programmet er godt dokumentert. Kravene til vedlikeholdbarhet vises i tabell 4.9. Tabell 4.9: Krav til vedlikeholdbarhet Krav-ID Beskrivelse av krav Vekting IF-V1 Det skal produseres en brukerdokumentasjon til programmet. 1 IF-V2 Brukerdokumentasjonen skal forklare og eksemplifisere 1 bruken av alle parametre som er tilgjengelige via konfigurasjonsfilen. IF-V3 Det skal produseres en installasjonsdokumentasjon til 1 programmet. IF-V4 Programmet skal ha et veldokumentert programmeringsgrensesnitt. 2 IF-V5 All kode skal kommenteres med engelske DocStrings. 3 IF-V6 Alle funksjoner og variabler skal ha engelske navn. 2 IF-V7 Koden skal være modulær

142 KAPITTEL 4. SPESIFIKKE KRAV Portabilitet Kunden ønsker at programmet skal kunne kjøres på de samme plattformene som de nå benytter til sitt publiseringsverktøy. Dette vil gjøre det mulig å teste programmet i samkjøring med de eksisterende systemene. Kravene til portabilitet er gitt i tabell Tabell 4.10: Krav til portabilitet Krav-ID Beskrivelse av krav Vekting IF-P1 Programmet skal kunne kjøres i et UNIX-lignende 3 miljø, som for eksempel Linux eller Cygwin. IF-P2 Programmet skal fungere med Python 2.3 og nyere Brukergrensesnitt Kunden har et ønske om at det skal utvikles et svært enkelt grafisk brukergrensesnitt for å illustrere programmets funksjonalitet. Kravene til dette brukergrensesnittet er gitt i tabell Tabell 4.11: Krav til brukergrensesnitt Krav-ID Beskrivelse av krav Vekting IF-B1 Et enkelt grafisk grensesnitt skal implementeres og 1 dokumenteres som eksempel på bruk av APIet. IF-B2 Grensesnittet skal tilby et forenklet publiseringsverktøy 1 med mulighet for å skrive inn en artikkel. IF-B3 Grensesnittet skal visualisere resultatet av klasingen. 2 IF-B4 Det skal være mulig å endre konfigurasjonsparameterne 1 gjennom grensesnittet. IF-B5 Brukergrensesnittet skal gi visuell feedback på progresjon

143 Kapittel 5 Use-case-basert estimering Dette kapittelet tar for seg en use-case-basert estimering av tidsforbruk i prosjektet. Timeverk-estimatet dekker alle faser etter kravspesifikasjonen, det vil si konstruksjon, implementasjon, testing og dokumentasjon. Metoden ble introdusert av Gustav Karner ved Linkøping University, og bygger på funksjonspoengestimering. Det er i dette prosjektet blitt utlevert et estimeringsskjema der det skal fylles inn forskjellige faktorer. Disse faktorene beregnes som gitt i [2]. Først må aktørene i use-casene vektes etter vanskelighetsgrad. Det benyttes her en gradering med 1/2/3, der 1 betyr enkel og 3 betyr avansert. Aktørene er vektet i tabell 5.1. Tabell 5.1: Vekting av aktører Aktør Vekt Begrunnelse Administrator 3 Administratoren er en person som samhandler med systemet gjennom et grafisk grensesnitt. Publiseringsverktøy 1 Publiseringsverktøyet er et annet system med veldefinert API. Prosesseringsmodul 1 Prosesseringsmodulen er en intern aktør. Klasingsmodul 1 Klasingsmodulen er en intern aktør. Kategoriseringsmodul 1 Kategoriseringsmodulen er en intern aktør. Deretter gis use-casene selv en vekt ut fra antall transaksjoner, det vil si antallet hendelser i stien. Her skal både den grunnleggende og alternative handlingsstier tas med. Vektene gis som følger: Færre en 4 transaksjoner: 5. 4 til 7 transaksjoner: eller flere transaksjoner:

144 KAPITTEL 5. USE-CASE-BASERT ESTIMERING Use-casene for dette programmet vil dermed gis følgende vekter: UC-1: 15. UC-2: 15. UC-3: 10. Figur 5.1 viser resultatet av use-case-estimeringen. Estimert tid for prosjektet blir her beregnet til omtrent 666 timer. Det blir benyttet 15 timeverk per usecase point, slik retningslinjene for prosjektet tilsier. Estimert tid blir dermed noe høyere enn det svært forenklede estimatet som ble foretatt i prosjektets oppstartsfase, der det ble estimert 524 timer til fasene etter kravspesifikasjonen. Det ser dermed ut til at det bør beregnes noe mer jobbing mot slutten av prosjektet enn hva som først var antatt. 138

145 KAPITTEL 5. USE-CASE-BASERT ESTIMERING Enter values in this column Actors Weight Factors Description Weight Enter NActors_i Weighted Value Comment Simple_Actor Program interface Average_Actor Interactive or protocol driven interface Complex_Actor Graphical interface Total Actor Weight 7 Use Cases Weight Factors (Bases on the number Enter of transactions in a use case) Weight NUsecases_i Weighted Value Comment Simple_Use_Case 3 or fewer transactions Average_Use_Case 4 to 7 transactions Complex_Use_Case more than 7 transactions Transaction Based Factors 40 Unadjusted Use Case Points 47 Technical Weight Factors Rating Scale is 0 to 5 TWeight_i Enter TRating_i Weighted Value Reason T1 Distributed System 0 =not important 5 =essential T2 Response or throughput performance objectives 0 =not important 5 =essential T3 End-user efficiency (online) 0 =not important 5 =essential T4 Complex internal processing 0 =not important 5 =essential T5 Code must be reusable 0 =not important 5 =essential T6 Easy to install 0 =not important 5 =essential 0,5 3 1,5 T7 Easy to use 0 =not important 5 =essential 0,5 4 2 T8 Portable 0 =not important 5 =essential T9 Easy to change 0 =not important 5 =essential T10 Concurrent 0 =not important 5 =essential T11 Includes special security features 0 =not important 5 =essential T12 Provides direct access for third parties 0 =not important 5 =essential T13 Special user training facilities are required 0 =not important 5 =essential TFactor TFactor 29,5 Technical Factor (TCF).6 + (.01*TFactor) 0,895 Experience Environmental Factors for Team and Weights Rating Scale is 0 to 5 EWeight_j Enter ERating_j Weighted Value Reason Stability F1 Faimilar with the Rational Unified Process 0 = no experience, 3=average, 5=expert 1,5 1 1,5 1 F2 Application experience 0 = no experience, 3=average, 5=expert 0, F3 Object-Oriented Experience 0 = no experience, 3=average, 5=expert F4 Lead analyst capability 0 = no experience, 3=average, 5=expert 0, F5 Motivation 0=no motivation, 3=average, 5=high F6 Stable requirements 0=extremly unstable, 5=unchanging F7 Part-time workers 0=no part time, 5=all part time F8 Difficult programming language 0=easy language, 3=average,5=difficult EFactor EFactor 11,5 3 Environmental Factor (EF) 1.4+(-0.03*EFactor) 1,055 Use Case Points UUCP 44, Person-hours per use case point EperUUCP 15 Estimated person-hours in project Effort in person-hours 665, Figur 5.1: Skjema for use-case-basert estimering 139

146 Vedlegg A Beskrivelse av dataflytdiagrammer Et dataflytdiagram gir en illustrasjon av flyten av dataene i et system, samt behandlingen av disse. Det viser hvordan data kommer fra de eksterne entitetene og hvordan de behandles i prosesser. Dette vedlegget viser hvilken syntaks som blir benyttet i dataflytdiagrammer. A.1 Eksterne grensesnitt Figur A.1: Eksternt grensesnitt i dataflytdiagrammer Eksterne grensesnitt er objekter utenfor systemet som systemet kommuniserer med. Disse fungerer som kilder og sluk i systemets dataflyt. Figur A.1 viser hvordan eksterne grensesnitt er modellert i dataflytdiagrammene. A.2 Prosesser Figur A.2: En prosess i dataflytdiagrammer 140

147 VEDLEGG A. BESKRIVELSE AV DATAFLYTDIAGRAMMER Prosesser omformer en innkommende dataflyt til en utgående dataflyt. Prosessnavnet skal beskrive hva prosessen gjør. Prosessene kan også dekomponeres i subprosesser på flere nivåer. Figur A.2 viser hvordan eksterne grensesnitt er modellert i dataflytdiagrammene. A.3 Dataflyt Figur A.3: Dataflyt i dataflytdiagrammer Dataflyt er piler som viser hvor informasjonen flyter i systemet. Disse navngis i henhold til hva slags data som går gjennom dem. Figur A.3 viser hvordan dataflyt er modellert i dataflytdiagrammene. 141

148 Vedlegg B Beskrivelse av use-case Dette kapittelet presenterer syntaksen som brukes for å beskrive use-casene som blir brukt i kravspesifikasjonen. Tabell B.1 viser hvordan aktørene i use-casene blir beskrevet, mens tabell B.2 beskriver syntaksen som blir brukt på selve usecasene. Tabell B.1: Beskrivelse av syntaks brukt i aktørtabellene Aktør: <Navn på aktøren (forkortelse).> Beskrivelse: <En beskrivelse av aktøren.> Tabell B.2: Beskrivelse av syntaks brukt i de tekslige use-casene. <Navn på use case> ID: <IDen til use-caset.> Mål: <En beskrivelse av målet for utførelse av use-caset.> Forutsetning: <En beskrivelse av hvilke forutsetninger som må være oppfylt før use-caset kan utføres.> Slutt-tilstand: <En beskrivelse av hva som vil være resultatet av en utførelse av use-caset.> Trigger: <En beskrivelse av en hendelse som vil føre til at use-caset utføres.> Aktør(er): <Her vil aktørene i use-caset listes opp på følgende form: Navn på aktør 1 (forkortelse) Navn på aktør 2 (forkortelse)... Navn på aktør n (forkortelse)> Grunnleggende <En nummerert liste som viser rekkefølgen på hendelsene handlingssti: som vil forekomme i en normal utførelse av use-caset.> Alternativ(e) <En eller flere nummererte liste som viser rekkefølgen på handlingssti(er): hendelsene som vil forekomme ved avvik fra normal utførelse.> 142

149 Vedlegg C Sporingsmatrise Dette vedlegget inneholder en sporingsmatrise som viser hvordan de funksjonelle kravene er relatert til use-casene. Matrisen er gitt i tabell C.1 Tabell C.1: Sporingsmatrise UC-1 UC-2 UC-3 FK-P1 X FK-P2 X FK-P3 X FK-P4 X FK-P5 X FK-P6 X FK-P7 X FK-C1 X FK-C2 X FK-C3 X FK-C4 X FK-K1 X FK-K2 X FK-K3 X FK-K4 X FK-T1 X X X FK-T2 X X X FK-T3 X FK-T4 X 143

150 Vedlegg D Definisjoner og forkortelser DFD DocStrings Frase Funksjonelle krav Dataflytdiagram - En modellering av hvordan data flyter gjennom et system. Dokumentasjonsstandard for Python kode. Sett med ord som hører naturlig sammen slik de står i en setning. Krav som stilles til programmets oppførsel. Ikke-funksjonelle krav Krav som stilles til hvordan programmet skal fungere, men som ikke er tilknyttet en bestemt brukerfunksjon. Kategorisering Klasing LSI Ordvektor Preprosessering Publiseringsverktoy Stemming Stoppord Finne emnet til et dokument ut fra innholdet i dokumentet. Å samle dokumenter i klaser (clustere), slik at dokumenter som er semantisk relatert til hverandre havner i samme klase. latent semantisk indeksering - En teknikk for prosessering av naturlig språk. En måte å representere et dokument på, der termene som forekommer i dokumentet representeres som verdier i vektoren. Omforming fra dokument til ordvektor. Verktøy for å redigere og publisere artikler på Internett. Redusere ord til rotform, eller stammeform Ord som forekommer svært ofte i flertallet av dokumentene. Disse ordene vil ha liten eller ingen verdi for videre tolkning av dokumentets innhold. 144

151 VEDLEGG D. DEFINISJONER OG FORKORTELSER Use-case Vektorsok Et scenarie som beskriver hvordan et system samhandler med en bruker eller et annet system. Teknikk for å finne likhet mellom vektorer. I dette tilfellet vil dokumentene representeres som ordvektorer, og vektorsøk kan dermed benyttes til å finne likhet mellom dokumentene. 145

152 Vedlegg E Referanser [1] IEEE recommended practice for software requirements specifications, IEEE Std (1998). [2] B. Anda and R. Conradi, Usecase-based effort estimation of software projects, (2005)

153 Del IV Konstruksjon 147

154 148

155 INNHOLD Innhold 1 Innledning Hensikt Omfang Oversikt Overordnet arkitektur Teknologi Moduler Dataflyt Preprosessering Dekomponering Splitting Stoppordfjerning Stemming Kombinering Avhengigheter Grensesnitt Klasing Dekomponering Generering av dokument/term-matrise Vekting Matrisereduksjon Vektorsøk mellom alle dokumenter og emner Koblinger mellom dokumenter og emner Avhengigheter Grensesnitt

156 INNHOLD 5 Kategorisering Dekomponering Generering av emne/term-matrise Søk etter ordvektor i matrise Avhengigheter Grensesnitt Brukergrensesnitt Klasing Publiseringsverktøy A Beskrivelse av dataflytdiagrammer 172 A.1 Eksterne grensesnitt A.2 Prosesser A.3 Dataflyt B Definisjoner og forkortelser 174 C Referanser

157 FIGURER Figurer 2.1 Modulene i PaperPrism Nivå 0 DFD-diagram Dekomponering av prosess 1: Preprosessering Dekomponering av prosess 2: Klasing Lokale vektingsalgoritmer Globale vektingsalgoritmer De ulike matrisene i SVD Vektorsøk mellom alle kolonnene i en matrise Resultatmatrisen som graf Vektorsøk mellom alle kolonnene i en matrise Algoritme for å klase dokumenter Dekomponering av prosess 3: Kategorisering Brukergrensesnittene mot programmet Kommandolinjeverktøy for klasing Publiseringsverktøy - åpningsvindu Publiseringsverktøy - kategorisering av dokument A.1 Eksternt grensesnitt i dataflytdiagrammer A.2 En prosess i dataflytdiagrammer A.3 Dataflyt i dataflytdiagrammer

158 152 FIGURER

159 Kapittel 1 Innledning Dette kapittelet gir en kort oversikt over innholdet i konstruksjonsdokumentet. Selve fasen har som mål å komme fra en overordnet systembeskrivelse til en realiserbar spesifikasjon. Fit the parts together, one into the other, and build your figure like a carpenter builds a house. Everything must be constructed, composed of parts that make a whole... Henri Matisse 1.1 Hensikt Hensikten med konstruksjonsfasen er å beskrive hvordan det planlagte programmet skal realiseres. I den sammenheng klargjøres det hvordan programmet skal dekomponeres, og hvordan de forskjellige modulene skal fungere. Dette inkluderer forklaringer av sammenhengene mellom dem, samt en beskrivelse av hvordan de skal implementeres. 1.2 Omfang Konstruksjonsdokumentasjonen skal klargjøre hvordan gruppen planlegger å implementere programmet. Konstruksjonen skal utformes på grunnlag av valgene tatt i forstudiet, samt kravene utformet i kravspesifikasjonen. 153

160 KAPITTEL 1. INNLEDNING 1.3 Oversikt Resten av konstruksjonsdokumentasjonen er delt inn i følgende kapittel og vedlegg: Kapittel 2 beskriver programmet på et overordnet plan. Kapittel 3 beskriver virkemåten til preprosesseringsmodulen, samt dens avhengigheter og grensesnitt. Kapittel 4 beskriver hvordan klasingsmodulen fungerer, samt dens avhengigheter og grensesnitt. Kapittel 5 beskriver hvordan kategoriseringsmodulen fungerer, samt dens avhengigheter og grensesnitt. Kapittel 6 beskriver designet av brukergrensesnittet. Vedlegg A beskriver notasjonen som er brukt i dataflytdiagrammene. Vedlegg B inneholder definisjoner og forkortelser. Vedlegg C inneholder en liste over referansene som er brukt i dette dokumentet. 154

161 Kapittel 2 Overordnet arkitektur Dette kapittelet gir en oversikt over hvordan gruppen planlegger å implementere produktet. Det presenteres også en overordnet skisse over hvilke moduler som skal implementeres, og hvordan disse forholder seg til hverandre. 2.1 Teknologi For å realisere produktet har gruppen valgt å benytte Python, C og HTML. Python skal benyttes som primært programmeringsspråk. Dette valget ble tatt allerede i forstudiet, blant annet på grunnlag av at kunden benytter Python i sitt eksisterende publiseringsverktøy. C skal benyttes som sekundært programmeringsspråk. C skal brukes til de mest tid- og minnekrevende delene av programmet, da dette språket er langt raskere enn Python og gir mer kontroll over minneforbruket. Disse delene av programmet skal enten ha et Python-API, eller kommunisere med hovedprogrammet via filskriving. HTML skal benyttes for å lage et fiktivt publiseringsverktøy. Gruppen har valgt HTML da dette er et enkelt språk for å utforme pene brukergrensesnitt. Der brukergrensesnittet skal kommunisere med programmet, vil Python benyttes til å generere HTML-koden. På denne måten kan programmet også motta parametere fra brukeren. 155

162 KAPITTEL 2. OVERORDNET ARKITEKTUR 2.2 Moduler Programmet vil som illustrert i figur 2.1 bestå av tre moduler, henholdsvis preprosesserings-, klasings- og kategoriseringsmodul. Figur 2.1: Modulene i PaperPrism Preprosessering er den modulen som tar seg av konvertering fra dokumenter til ordvektorer. På denne måten kan dokumentene samles i en matrise, og sammenlignes med hverandre. Preprosessering må gjøres før både klasing og kategorisering. Klasing er den modulen som ved hjelp av matriseoperasjoner og søkealgoritmer skal gruppere dokumentene under gitte emner. Kategorisering er den modulen som skal benyttes når et enkelt dokument skal kategoriseres. Denne modulen vil benytte en allerede klaset dokumentsamling, og ved hjelp av denne søke seg frem til hvilke emner som passer best til det nye dokumentet. 156

163 KAPITTEL 2. OVERORDNET ARKITEKTUR 2.3 Dataflyt I dette dokumentet vil dataflytdiagrammer benyttes for å beskrive funksjonaliteten i de forskjellige modulene, samt hvordan disse fungerer sammen. Syntaksen på dataflytdiagrammene som benyttes er gitt i vedlegg A. Figur 2.2: Nivå 0 DFD-diagram En overordnet beskrivelse av hvordan modulene samhandler er vist i figur 2.2. De forskjellige prosessene vil dekomponeres i de kommende kapitlene. Som figuren viser, vil preprosesseringsmodulen benyttes både ved klasing og ved kategorisering. Modulene skal delvis 1 kunne fungere selvstendig, og vil dermed kunne testes separat. 1 Med delvis menes at både klasings- og kategoriseringsmodulen er avhengige av preprosessering for å gi fornuftige resultater. 157

164 Kapittel 3 Preprosessering Før dokumentene kan brukes av videre prosesser i programmet, må de konverteres til ordvektorer. Denne konverteringen foregår i preprosesseringsmodulen. Ved å konvertere dokumentene til ordvektorer vil det være mulig å representere dem som en matrise. Dette vil være grunnleggende for at LSI-algoritmen skal kunne utføres. 3.1 Dekomponering Figur 3.1 viser en dekomponering av preprosessering (prosess 1). Preprosesseringen brukes flere steder, men dekomponeringen er lik i begge tilfellene. Figur 3.1: Dekomponering av prosess 1: Preprosessering Splitting Splitteren vil dele opp dokumentet i passende termer. Den vil returnere to Pythonlister, en med særnavn og fraser, og en med enkeltord. Særnavn og fraser skilles ut i en egen liste fordi de ikke skal stemmes, noe enkeltord skal. Denne uthentingen av særnavn og fraser skal gjøres som spesifisert i forstudiet, og regulære uttrykk vil bli benyttet til dette [1] [5]. Splitteren vil være egenprodusert i sin helhet, og være skrevet i Python. 158

165 KAPITTEL 3. PREPROSESSERING Stoppordfjerning Stoppord er ord som er uten verdi for videre prosesser, og som derfor skal fjernes fra ordvektorene. Stoppordfjerneren vil basere seg på et valgfritt antall lister med stoppord. Primært skal programmet benytte seg av en vedlagt tredjeparts liste med stoppord[3]. Det vil i tillegg være mulig å benytte andre lister dersom dette er ønskelig. Selve stoppordfjerneren vil være egenprodusert, og være skrevet i Python. Stoppordfjerning utføres på begge ordvektorene fra splittingen, siden det av og til dukker opp falske særnavn som egentlig er stoppord. Dette skjer som regel på grunn av manglende tegnsetting i dokumentene Stemming Stemming er en prosess som fjerner bøyninger og vedheng (som -lighet ) fra ord, slik at alle bøyninger og varianter av et ord får en felles term. Gruppen har her valgt å bruke en tredjeparts løsning som heter PyStemmer [4]. Denne kan benyttes uten modifikasjoner fra gruppens side. Stemmingen skal kun utføres på den ene av ordvektorene fra splittingen. Ordvektoren som inneholder fraser og særnavn skal ikke stemmes, siden de ikke har bøyningsformer Kombinering Kombineringen slår sammen de to ordvektorene igjen, og lager en datastruktur som er mer passende for videre bruk. Denne datastrukturen vil være en Pythondictionary med ord som nøkler og tallverdier som verdier. Tallverdiene vil være basert på ordforekomst, men vil siden vektes ut fra konfigurerbare vektingsalgoritmer som beskrevet i kapittel Avhengigheter Preprosesseringen er avhengig av inndata og Python. 3.3 Grensesnitt Inndata: Et sett med dokumenter, i form av ren tekst med noe markup. Utdata: Et sett Python-lister med termene i dokumentene. 159

166 Kapittel 4 Klasing Klasing er ordet som brukes for å beskrive gruppering av dokumenter under et gitt emne. Til dette benyttes latent semantisk indeksering (LSI), vektorsøk og analyse av resultatene. 4.1 Dekomponering Figur 4.1 gir en dekomponering av klasing (prosess 2). Denne dekomponeringen viser de interne prosessene i klasingen, samt dataflyten mellom disse. Figur 4.1: Dekomponering av prosess 2: Klasing Generering av dokument/term-matrise Dokumentmatrisen består av alle ordvektorene fra dokumentene. Hvert dokument er en kolonne i matrisen, og ordene i dokumentsamlingen er rader. Dokumenter som ikke inneholder gitte ord vil få verdien 0 i de respektive cellene i matrisen. I de tilfellene hvor ordene finnes i dokumentene vil cellene gis en verdi basert på lokal og global vekting (se avsnitt 4.1.2). Etter hvert som størrelsen på dokumentsamlingen øker, vil også antall ord øke. Siden hvert dokument da nødvendigvis kun vil inneholde en brøkdel av alle ordene forekommer totalt sett, vil en stor del av cellene i matrisen ha verdien 0. Derfor 160

167 KAPITTEL 4. KLASING vil matrisen bli lagret som en sparse matrise i minnet. En sparse matrise lagrer posisjonen og verdien til cellene som har en verdi ulik 0, slik at matrisen vil kreve mindre minne enn den ville gjort dersom den ikke var sparse. Emner legges også til i matrisen som pseudo-dokumenter 1. Dersom kun tittelen på emnet er tilgjengelig, vil kun denne brukes i pseudo-dokumentet. Når man derimot allerede har mer data om emnet tilgjengelig, som for eksempel synonymer eller allerede kategoriserte dokumenter under emnet, kan disse dataene benyttes for å fylle ut flere ord som har tilknytning til emnet. Dette vil med høy sannsynlighet forbedre resultatet av klasingen Vekting Figur 4.2: Lokale vektingsalgoritmer [7] Lokal vekting vil benyttes for å øke eller minske den relative viktigheten til en term i ett enkelt dokument. Det kan her benyttes tre forskjellige algoritmer, som vist i figur 4.2. Gruppen vil implementere alle de tre vektingsalgoritmene, og valg av vektingsalgoritme vil være konfigurerbart. Figur 4.3: Globale vektingsalgoritmer [7] Global vekting skal benyttes for å øke eller minske den relative viktigheten til en term over alle dokumentene. De fire mest populære algoritmene er her gitt i figur 1 Et pseudo-dokument vil bli behandlet som et vanlig dokument. Forskjellen er at et pseudodokument ikke er en del av den opprinnelige dokumentsamlingen, men et dokument som er generert av programmet under kjøring. 161

168 KAPITTEL 4. KLASING 4.3. Også her vil gruppen implementere alle vektingsalgoritmene og la valget av algoritme være konfigurerbart. Den totale vekten for et element a ij blir deretter regnet ut ved at a ij = L(i, j) G(i, j). Det vil variere hvilken kombinasjon av vektingsalgoritmer som gir best resultater for en dokumentsamling. Ved å gjøre valget av vektingsalgoritmer konfigurerbart, vil det være mulig å prøve ut hvilken kombinasjon som fungerer best for en gitt dokumentsamling. Tidligere undersøkelser på området tilsier at en lokal logaritmisk vekting kombinert med en global Entropy-vekting generelt sett gir gode resultater [7] Matrisereduksjon Matrisereduksjonen vil sørge for at ord som ofte forekommer i de samme dokumentene relateres til hverandre. Dette gjøres i vårt tilfelle ved å benytte Singular Value Decomposition (SVD) gjennom et tredjeparts C-program kalt Doug Rohde s SVD C Library (SVDLIBC) [6]. SVD er en avansert og matematisk algoritme, og vil ikke beskrives i detalj i dette dokumentet. Det som derimot er viktig å kjenne til i sammenheng med SVD er hva resultatet av algoritmen blir. En utførelse av SVDLIBC vil resultere i tre nye matriser, som vist i figur 4.4. De tre matrisene er sortert slik at mesteparten av informasjonen er samlet ved de laveste indeksene. For å kvitte seg med støy tas kun en viss mengde med data fra hver matrise med videre. Denne grensen er normalt angitt som k, som vil være en parameter i konfigurasjonsfilen. De nye vektorene representerer hva algoritmen anser som essensen i dokumentet, og elementene representerer ikke lenger forekomster av enkeltord. Figur 4.4: De ulike matrisene i SVD [8] 162

169 KAPITTEL 4. KLASING De nye matrisene er: U k - Termvektorer (essens/ord-matrise) Σ k - Singulærverdier, sortert monotont synkende (essens/essens-matrise) V T k - Dokumentvektorer, transponert (dokument/essens-matrise) De utvalgte submatrisene kan deretter multipliseres sammen som vist i figur 4.4, og man får en ny matrise kalt A k. Denne matrisen er den nærmeste k-dimensjonale representasjonen av den opprinnelige dokument/term-matrisen. A k er ikke nødvendig å generere for å løse gruppens problemstilling, men skildrer sammenhengen mellom de tre øvrige matrisene. Den informasjonens som er viktig for å løse oppgaven gruppen er tildelt ligger i matrisen Vk T. Dette vil være en matrise som inneholder dokumenter (inkludert emnene) i kolonnene, og radene vil representere det algoritmen anser som essensen i dokumentene Vektorsøk mellom alle dokumenter og emner For å finne ut hvor tett relaterte dokumenter og emner er, vil alle kolonnene i matrisen måtte sammenlignes med hverandre. Dette gjøres ved å benytte et alletil-alle vektorsøk mellom kolonnene i Vk T. Vektorsøket vil returnere en symmetrisk matrise med dokumenter og emner både i radene og kolonnene. Verdien i hver celle i matrisen vil inneholde et mål på hvor godt et dokument relaterer til et annet. Verdiene i diagonalen vil settes til 0, siden relasjon til seg selv er uinteressant og bare vil forstyrre søkingen. Samsvarsvekten mellom to kolonner er lik prikkproduktet mellom dem. For kolonnene a og b med lengde n vil dette regnes ut slik: vekt(a, b) = n 1 i=0 (a[i] b[i]) Figur 4.5 illustrerer et alle-til-alle-søk mellom kolonnene i en enkel matrise. Eksempelvis vil dokumentene A og B ha prikkprodukt lik 2, mens dokumentene B og C vil ha prikkprodukt lik 1. Figur 4.5: Vektorsøk mellom alle kolonnene i en matrise 163

170 KAPITTEL 4. KLASING Resultatmatrisen kan betraktes som en graf, der dokumenter og emner er noder, og søkeresultatene er vektede kanter uten retning. Resultatmatrisen i figur 4.5 vises med grafnotasjon i figur 4.6. Disse matrisene vil heretter bli illustrert i grafnotasjon. Figur 4.6: Resultatmatrisen som graf Koblinger mellom dokumenter og emner Emner vil potensielt sett ha meget lite metadata. Det vil derfor ikke være godt nok å kun betrakte direkte relasjoner mellom emner og dokumenter. En slik fremgangsmåte vil gi svært få treff, og flertallet av dokumentene vil forbli ukategoriserte. Gruppen vil forsøke å løse dette ved å benytte relasjoner mellom dokumenter i tillegg til å betrakte direkte relasjoner mellom emne og dokument. På denne måten kan dokumenter relateres til emner via dokumenter de er relaterte til. Et problem med denne metoden er at lange kjeder av dokumentrelasjoner fort vil inkludere urelaterte dokumenter ytters i kjeden. Det vil derfor benyttes en konfigurerbar grense for hvor lange kjeder som skal aksepteres. Figur 4.7 skildrer et kraftig forenklet eksempel som inneholder tre dokumenter og et emne. Det er allerede blitt kjørt et vektorsøk mellom dokumentene og emnene, og relasjonene mellom de forskjellige vises med tallverdier. En høy tallverdi tilsier en sterk relasjon. Dersom for eksempel grensen for å lage en relasjon til et dokument hadde blitt definert til 2, ville ikke Dokument 3 blitt direkte relatert til emnet, siden den direkte relasjonen kun er 1. Imidlertid er det relativt sterke relasjoner via Dokument 1 og 2. Derfor er det grunn til å tro at Dokument 3 også bør inkluderes. Gruppen har valgt en løsning der man finner emnerelasjoner ved å søke fra ett og ett emne, og benytte søkeresultatene til å avgjøre hvilke dokumenter som er relaterte. Dette vil bli gjort på følgende måte: Reduser antall kanter ved å fjerne alle relasjoner som er under en konfigurerbar skranke. Søk fra hvert emne og finn kanter som går til dokumenter. Avbryt søket ved en justerbar dybde. Finn maksimal flyt mellom emnet og hvert dokument. 164

171 KAPITTEL 4. KLASING Figur 4.7: Vektorsøk mellom alle kolonnene i en matrise Med denne fremgangsmåten vil dokumenter som er relaterte til mange dokumenter i emnet også inkluderes, men kun dokumenter som kan nås innenfor den gitte mengden relasjoner. Litt mer utfyllende pseudokode er listet i figur 4.8. FindClusters(AllEdges, AllSubjects) 1 Interesting nil 2 Related nil 3 for each E in AllEdges 4 do 5 if E < MinW eight 6 then 7 AllEdges AllEdges E 8 for each S in AllSubjects 9 do 10 Interesting DirectlyRelated({S}) 11 for i 1 to MaxLevels 12 do 13 Interesting Interesting DirectlyRelated(Interesting) 14 for each D in Interesting 15 do 16 if IsDocument(D) and MaxF low(s, D) < M inrelated 17 then 18 Related S Related S {D} 19 return Related Figur 4.8: Algoritme for å klase dokumenter 165

172 KAPITTEL 4. KLASING 4.2 Avhengigheter Klasingen er avhengig av inndata fra preprosesseringen og Python. For å oppnå tilfredsstillende ytelse vil man også være avhengig av tredjepartsprogrammet SVDLIBC for å utføre SVD, samt et egenprodusert C-program for matrisemultiplikasjon. 4.3 Grensesnitt Inndata: Et sett Python-lister med termene i dokumentene. Utdata: En Python-dictionary med emner som nøkler og lister med dokumenter som verdier. 166

173 Kapittel 5 Kategorisering Ordet kategorisering brukes for å beskrive valg av emnerelasjoner for et enkelt dokument som tilføres dokumentsamlingen i ettertid. 5.1 Dekomponering Figur 5.1 gir en dekomponering av kategorisering (prosess 3). Denne dekomponeringen viser de interne prosessene i kategoriseringen, samt dataflyten mellom disse. Figur 5.1: Dekomponering av prosess 3: Kategorisering Generering av emne/term-matrise Emne/term-matrisen vil minne om dokument/term-matrisen, men selve dokumentene er utelatt. Kolonnene vil dermed bestå av ordvektoren til hele emnet, der ordvektoren genereres ved å slå sammen alle dokumentene som er tilknyttet emnet og betrakte dem som et enkelt dokument. Det vil ikke bli utført en matrisereduksjon på denne matrisen, da dette vil gjøre det vanskeligere å cache matrisen. Det er meget fordelaktig å kunne lagre en ferdiggenerert matrise, for deretter å søke direkte i denne. Denne matrisen kan enten genereres jevnlig (eksempelvis som en nattlig jobb) eller inkrementelt etter hvert som nye dokumenter legges til i dokumentsamlingen. 167

174 KAPITTEL 5. KATEGORISERING Søk etter ordvektor i matrise Dokumentet som skal kategoriseres konverteres til en ordvektor tilsvarende emne/termmatrisens kolonner. Deretter utføres vektorsøk på alle emnene, og resultatet returneres som en Python-liste med emner. Listen vil være sortert etter hvor godt vektorsøket traff, og treff som er dårligere enn grensen angitt i konfigurasjonsfilen vil ikke returneres. 5.2 Avhengigheter Kategoriseringen er kun avhengig av inndata og Python. 5.3 Grensesnitt Inndata: Et sett ferdigklasede dokumenter, samt et nytt dokument som skal kategoriseres. Utdata: En liste med emner som passer til dokumentet. 168

175 Kapittel 6 Brukergrensesnitt I forbindelse med prosjektet skal det også lages et enkelt brukergrensesnitt mot programmet. Gruppen har valgt å løse denne oppgaven todelt, som illustrert i figur 6.1. Klasingen vil utføres i via kommandolinje, mens et forenklet publiseringsverktøy vil brukes for å illustrere kategoriseringen. Figur 6.1: Brukergrensesnittene mot programmet 6.1 Klasing Klasingens brukergrensesnitt vil implementeres som et kommandolinjeverktøy, og kjøres i et terminalvindu som vist i figur 6.2. Gruppen har i samarbeid med kunden valgt å prioritere bort et grafisk brukergrensesnitt, til fordel for økt fokus på forbedret funksjonalitet. Konfigureringen av klasingsmodulen vil foregå via redigering av konfigurasjonsfilen i en standard teksteditor. Dette innebærer at krav IF-B4 fra kravspesifikasjonen ikke lenger tilfredsstilles [2]. Kommandolinjeverktøyet skal gi tilbakemelding på progresjon ved bruk av en 169

176 KAPITTEL 6. BRUKERGRENSESNITT Figur 6.2: Kommandolinjeverktøy for klasing tekstlig fremdriftsindikator. Dette vil gjøre at administratoren som gjennomfører klasingen til enhver tid kan se hvor langt i prosessen klasingen er. 6.2 Publiseringsverktøy For å illustrere programmets funksjonalitet vil gruppen konstruere et forenklet publiseringsverktøy. Det vil her benyttes HTML med tilkoblinger til Python. Figur 6.3: Publiseringsverktøy - åpningsvindu Figur 6.3 viser et initielt design av åpningsvinduet i det fiktive publiseringsverktøyet. Brukeren vil her ha tre valg: se klasene fra klasingen, lese dokumentene i dokumentsamlingen eller kategorisere et nytt dokument. Dette vil være all funksjonaliteten som planlegges for det fiktive publiseringsverktøyet. Dersom brukeren velger å se klasene fra klasingen, skal disse klasene vises frem på en oversiktlig måte. For hvert emne skal brukeren kunne se hvilke dokumenter programmet har beregnet som relevante. Hvis brukeren ønsker å lese dokumentene i dokumentsamlingen, skal samtlige dokumenter i samlingen listes opp. Brukeren skal så ha mulighet til å velge ett dokument for å lese innholdet i dette dokumentet. 170

177 KAPITTEL 6. BRUKERGRENSESNITT Figur 6.4: Publiseringsverktøy - kategorisering av dokument Ved å velge å kategorisere et nytt dokument gis brukeren mulighet til å skrive inn en tekst i et tekstvindu. Brukeren skal deretter kunne velge hvor mange alternative emner som maksimalt skal presenteres, og trykke på en knapp for å kategorisere teksten (se figur 6.4). Publiseringsverktøyet skal da presentere det som beregnes til de mest relevante emnene for teksten, og presentere disse for brukeren. 171

178 Vedlegg A Beskrivelse av dataflytdiagrammer Et dataflytdiagram gir en illustrasjon av flyten av dataene i et system, samt behandlingen av disse. Det viser hvordan data kommer fra de eksterne entitetene og hvordan de behandles i prosesser. Dette vedlegget viser hvilken syntaks som blir benyttet i dataflytdiagrammer. A.1 Eksterne grensesnitt Figur A.1: Eksternt grensesnitt i dataflytdiagrammer Eksterne grensesnitt er objekter utenfor systemet som systemet kommuniserer med. Disse fungerer som kilder og sluk i systemets dataflyt. Figur A.1 viser hvordan eksterne grensesnitt er modellert i dataflytdiagrammene. A.2 Prosesser Figur A.2: En prosess i dataflytdiagrammer 172

179 VEDLEGG A. BESKRIVELSE AV DATAFLYTDIAGRAMMER Prosesser omformer en innkommende dataflyt til en utgående dataflyt. Prosessnavnet skal beskrive hva prosessen gjør. Prosessene kan også dekomponeres i subprosesser på flere nivåer. Figur A.2 viser hvordan eksterne grensesnitt er modellert i dataflytdiagrammene. A.3 Dataflyt Figur A.3: Dataflyt i dataflytdiagrammer Dataflyt er piler som viser hvor informasjonen flyter i systemet. Disse navngis i henhold til hva slags data som går gjennom dem. Figur A.3 viser hvordan dataflyt er modellert i dataflytdiagrammene. 173

180 Vedlegg B Definisjoner og forkortelser C Cache DFD Frase HTML Kategorisering Klasing Konkatenere LSI Modul Ordvektor Preprosessering Et av verdens mest brukte programmeringsspråk. Å lagre resultatet av en tung operasjon, slik at disse resultatene er enkelt tilgjengelige uten å måtte kjøre operasjonene på ny. Dataflytdiagram - En modellering av hvordan data flyter gjennom et system. Sett med ord som hører naturlig sammen slik de står i en setning. HyperText Markup Language - Språk designet for å lage dokumenter som kan vises i nettlesere. Finne emnet til et dokument ut fra innholdet i dokumentet. Å samle dokumenter i klaser (clustere), slik at dokumenter som er semantisk relatert til hverandre havner i samme klase. Å plassere innholdet i dokumentene etter hverandre slik at de blir ett dokument. latent semantisk indeksering - En teknikk for prosessering av naturlig språk. Programvareenhet som samler et sett med subprogrammer og datastrukturer. En måte å representere et dokument på, der termene som forekommer i dokumentet representeres som verdier i vektoren. Omforming fra dokument til ordvektor. 174

181 VEDLEGG B. DEFINISJONER OG FORKORTELSER Pseudo-dokument Dokument som ikke er en del av den opprinnelige dokumentsamlingen, men genereres av programmet under kjøring. Python Et programmeringsspråk. Python-dictionary En datastruktur i Python, der dataene samles i uordnede nøkkel:verdi par. Sparse matrise Splitting Stemming Stoppord SVD SVDLIBC Vektorsok En måte å representere matriser på, der posisjonen til de cellene som har en verdi ulik 0 blir lagret. Før tekst kan analyseres må den splittes opp i deler, enten i form av enkeltord, delord eller grupper av ord. Forsøk på å fjerne bøyningsformer fra ord slik at stammen til ordet står igjen. Ord som forekommer svært ofte i flertallet av dokumentene. Disse ordene vil ha liten eller ingen verdi for videre tolkning av dokumentets innhold. Singular Value Decomposition - Algoritme for matrisereduksjon. Doug Rohde s SVD C Library - Et program som utfører SVD. Teknikk for å finne likhet mellom vektorer. I dette tilfellet vil dokumentene representeres som ordvektorer, og vektorsøk kan dermed benyttes til å finne likhet mellom dokumentene. 175

182 Vedlegg C Referanser [1] Forstudium, kundestyrt prosjekt, gruppe 10. [2] Kravspesifikasjon, kundestyrt prosjekt, gruppe 10. [3] ( ). [4] ( ). [5] ( ). [6] ( ). [7] S. Dumais, Improving the retrieval of information from external sources, Behavior Research Methods, Instruments (1991). [8] T. A. Letche, Toward large-scale information retrieval using latent semantic indexing, (1996). 176

183 Del V Implementasjon 177

184 178

185 INNHOLD Innhold 1 Innledning Hensikt Omfang Oversikt Implementasjonsstandarder Standard for koding Standard for kommentering av kode Eksempel på Pythonkode Tredjeparts kode PyStemmer SciPy MySQLdb SVDLIBC MaxFlow Preprosesseringsmodul Fraseuthenting Stoppord Klasingsmodul Generering av matrise Matrisereduksjon Maksflyt Forbedring av emnevektorer Inkludering av dokumenter Inkludering av metadata Kategoriseringsmodul

186 INNHOLD 7 Brukergrensesnitt Klasing Nettgrensesnitt Datalagring Database Tabeller Datafil for kategoriseringen Intern dataflyt i klasingen Konfigurering Resultater 207 A Algoritmer 209 A.1 Lokale vektingsalgoritmer A.2 Globale vektingsalgoritmer A.3 Vektorsøk A.4 Rekursiv algoritme for å beregne kantgrafer B Databaseskjema 213 C Definisjoner og forkortelser 214 D Referanser

187 FIGURER Figurer 2.1 Eksempelkode som viser bruk av kodestandard Illustrasjon av en dokumentgraf Kommandolinjeverktøy for klasing Logisk oppbygging av det grafiske brukergrensesnittet ER-diagram for databasen Presisjon og kompletthet ved forskjellige terskelverdier A.1 Lokale vektingsalgoritmer A.2 Globale vektingsalgoritmer A.3 Vektorsøkalgoritme implementert i C A.4 Rekursiv algoritme for å beregne kantgrafer B.1 SQL database

188 182 FIGURER

189 TABELLER Tabeller 9.1 Konfigurasjonsparametere

190 184 TABELLER

191 Kapittel 1 Innledning Dette dokumentet inneholder en oversikt over hvilke standarder som er brukt i implementasjonsfasen, både hva gjelder kodestil og kommentarer i koden. Det klargjører også hvilke valg som er tatt underveis i implementasjonen. Verden eksaminerer ikke hvordan en ting settes i verk, men hvordan den faller ut. Ludvig Holberg 1.1 Hensikt Hensikten med implementasjonsdokumentet er å definere standarder for skriving og dokumentering av kode, samt å dokumentere på en lettfattelig måte hvordan programmet ble implementert. 1.2 Omfang Det presenteres ikke detaljerte beskrivelser av implementasjonen. I stedet presenteres retningslinjer gruppen har fulgt i implementasjonsfasen. Disse er ment å være en støtte for de som ønsker å lese og forstå kildekoden til programmet. 185

192 KAPITTEL 1. INNLEDNING 1.3 Oversikt Resten av denne implementasjonsdokumentasjonen er delt inn i følgende kapittel og vedlegg: Kapittel 2 presenterer kodestandardene som benyttes i programmet. Kapittel 3 beskriver tredjeparts kode som er benyttet i implementasjonen. Kapittel 4 beskriver preprosesseringsmodulen. Kapittel 5 beskriver klasingsmodulen. Kapittel 6 beskriver kategoriseringsmodulen. Kapittel 7 beskriver hvordan brukergrensesnittet er implementert. Kapittel 8 beskriver hvordan gruppen har lagret data som benyttes av programmet. Kapittel 9 beskriver hvordan programmet konfigureres. Kapittel 10 drøfter resulatene fra programmet ved kjøring med forskjellige parametere. Vedlegg A inneholder noen av algoritmene som er blitt implementert. Vedlegg B inneholder databaseskjemaet for databasen som er benyttet. Vedlegg C inneholder definisjoner og forkortelser. Vedlegg D inneholder en liste over referansene som er brukt i dette dokumentet. 186

193 Kapittel 2 Implementasjonsstandarder Dette kapittelet beskriver kodestandarden gruppen brukte i implementasjonen. Denne standarden har vært svært viktig i dette prosjektet, da koden som ble skrevet skulle kunne brukes av utviklere fra Bouvet. Ved å følge standarden har koden blitt mer lesbar og dermed lettere å forstå. 2.1 Standard for koding Dette avsnittet presenterer konvensjonene for kodestil som følges i koden. Koden skal følge engelsk standard, hvilket innebærer at alle klasser, funksjoner og variabler skal ha engelske navn. Det er også viktig at navnene som benyttes beskriver funksjonaliteten til det gitte elementet. Navngiving Klasser skal ha stor forbokstav, eksempelvis: class Matrix : Funksjoner skal ha små bokstaver, der ordene er adskilt med dersom det trengs, eksempelvis: def f e t c h s u b j e c t p a p e r r e l a t i o n s ( r e v i s i o n, type ) : 2.2 Standard for kommentering av kode Mangelfull kode Dersom man av ulike årsaker ser seg nødt til å utsette skriving av kode til senere, skal dette kommenteres i kildekoden der den manglende koden hører hjemme. 187

194 KAPITTEL 2. IMPLEMENTASJONSSTANDARDER Hensikten med dette er å gjøre det enklere å finne tilbake til den manglende kodeblokken. Slike kommentarer skal begynne med TODO, eksempelvis: i f c o n d i t i o n : # TODO: Add code here I tillegg skal gruppen markere og kommentere kode som må utbedres. Disse skal begynne med FIXME. Et eksempel på dette er: buf = s [ i ] # FIXME: check t he bounds o f s Bruk av TODO og FIXME vil gjøre det enkelt å søke etter mangelfull kode. Linjekommentarer Enkelte steder i koden vil det være naturlig å sette inn kommentarer for å forklare hvordan det er tenkt under implementasjonen. I disse tilfellene vil gruppen benytte enkle linjekommentarer. Disse kommentarene starter med # og varer ut linja, for eksempel slik: # load d e f a u l t stopword l i s t s for f i l e in s e t t i n g s [ s t o p w o r d f i l e s ] : load ( f i l e ) Docstrings Docstrings er en mye brukt standard for kommentering av Python-kode. Denne standarden er svært anvendelig for kommentering av både moduler, funksjoner, klasser og metoder. En Docstring defineres ved å inkludere en tekststreng i første delen av en definisjon. Under vises et eksempel på bruk av Docstring. def c o u n t s e n t e n c e ( s e n t e n c e ) : S p l i t s the s e n t e nce i n t o words and counts them for word in s p l i t ( s e ntence ) : count word ( word ) Denne Docstringen kan siden bli aksessert fra Pythontolkeren ved å skrive inn følgende kommando: >>> help ( c o u n t s e n t e n c e ) S p l i t s the s e ntence i n t o words and counts them 188

195 KAPITTEL 2. IMPLEMENTASJONSSTANDARDER 2.3 Eksempel på Pythonkode Koden i figur 2.1 er hentet fra filen stopwordfilter.py. Denne demonstrerer hvordan kodestandarden er blitt brukt under implementasjonen. #! / usr / bin /env python # coding : iso from s e t t i n g s import s t o p w o r d f i l t e r as s e t t i n g s def load ( filename, append = True ) : Loads a l i s t o f stopwords from a f i l e. i f not append or stopwords not in g l o b a l s ( ) : global stopwords stopwords = [ ] f i l e = open ( f i l e n a m e ) for l i n e in f i l e : word = l i n e. s t r i p ( ) i f word : stopwords += [ word ] f i l e. c l o s e ( ) def f i l t r a t e ( words ) : Removes stopwords from a l i s t o f words. Returns a l i s t o f words without stopwords. return f i l t e r (lambda word : word. lower ( ) not in stopwords, words ) # l o a d d e f a u l t stopword l i s t s for f i l e in s e t t i n g s [ s t o p w o r d f i l e s ] : load ( f i l e ) # e n a b l e t e s t i n g from command l i n e import s y s i f name == m a i n : print f i l t r a t e ( s y s. argv [ 1 : ] ) Figur 2.1: Eksempelkode som viser bruk av kodestandard 189

196 Kapittel 3 Tredjeparts kode Dette kapittelet beskrivelser tredjeparts kode som er benyttet under implementasjonen. 3.1 PyStemmer Versjon: 0.10 Infoside: PyStemmer er benyttet for å stemme ordene i dokumentene. Denne stemmeren fungerte svært bra, og ble benyttet uten modifikasjoner. 3.2 SciPy Versjon: Infoside: SciPy er benyttet for behandling av sparse matriser i Python. 3.3 MySQLdb Versjon: Infoside: MySQLdb er benyttet for databasestøtte til Python. 190

197 KAPITTEL 3. TREDJEPARTS KODE 3.4 SVDLIBC Versjon: 1.34 Infoside: Doug Rohde s SVD C Library (SVDLIBC) er et program skrevet i C. Dette benyttes for å utføre Singular Value Decomposition (SVD) på dokument/termmatrisen. Programmet kalles fra Python-programmet, og skriver resultatene til en fil. 3.5 MaxFlow Versjon: 1.1 Infoside: MaxFlow er et Pyhon-program som benyttes for å beregne den maksimale flyten mellom to punkt i ett nettverk eller i en graf. Programmet benytter seg av Ford- Fulkerson s Max Flow Labeling Algorithm [4]. 191

198 Kapittel 4 Preprosesseringsmodul Dette kapittelet beskriver valgene som ble foretatt under implementasjonen av preprosesseringsmodulen. 4.1 Fraseuthenting Med fraser menes ord som hører naturlig sammen slik de står i en setning, for eksempel navnet Jens Pikenes. Slike fraser skal hentes ut under splittingen av dokumentene, slik at disse ikke stemmes. Ved implementasjonen foretok gruppen flere valg for å optimalisere fraseuthentingen. For det første har gruppen implementert en konfigurerbar grense for hvor lange fraser som skal aksepteres i en markup-blokk. Dette vil for eksempel være tekst som står i kursiv i teksten. Denne grensen vil være nyttig, siden forfattere benytter tekstformatering på forskjellige måter. Enkelte forfattere vil skrive hele avsnitt i kursiv, og disse avsnittene bør ikke regnes som fraser. Videre ble det bestemt at bildetekst skulle tas vare på, siden dette ofte utgjorde viktig informasjon i dokumentene. Bilder som tas med i et dokument fremhever som regel et poeng i teksten, og informasjon om disse er dermed ofte viktig å ta vare på. Hva som skulle regnes som frasemarkører og markup ble også gjort konfigurerbart. Dette vil gjøre PaperPrism portabelt mellom publiseringsverktøy som benytter forskjellig syntaks for tekstformatering. Det ble også bestemt at tall skulle fjernes under splittingen. Dette valget begrunnes med at sammenligning av tall sjelden vil gi fornuftige relasjoner. Ord som er en kombinasjon av tekst og tall vil derimot tas vare på, siden ord som F16 og XL1 kan være viktig informasjon i dokumentene. 192

199 KAPITTEL 4. PREPROSESSERINGSMODUL 4.2 Stoppord Under implementasjonen av stoppordfilteret viste det seg at svært mange ord forekom i et flertall av dokumentene. Dette var ikke kun vanlige stoppord, men også ord som forskning og menneske. Disse ordene forverret resultatene, ved at de stjal fokus fra mer dokumentspesifikke ord. Stoppordlisten som gruppen har funnet på Internett viste seg også å være svært lite omfattende [2]. Denne listen inneholdt kun de vanligste norske stoppordene. Disse observasjonene resulterte i at gruppen valgte å implementere en egen stoppordliste-generator. Stoppordliste-generatoren baserer seg på at alle ord tildeles en vekt som tilsvarer produktet av global termfrekvens og antallet dokumenter ordet forekommer i. Resultatet av denne vektingen lagres som en liste i en tekstfil, der ordene er sortert etter vekten som er tildelt. Denne listen inspiseres deretter manuelt for å avgjøre hvor grensen skal settes for hva som er stoppord. 193

200 Kapittel 5 Klasingsmodul Dette kapittelet beskriver valgene som ble foretatt under implementasjonen av klasingsmodulen. 5.1 Generering av matrise Klasingen baserer seg på vektorsøk mellom dokumentvektor. Emnene opptrer som dokumenter og har tilsvarende vektorer. For å lett kunne søke mellom emner og dokumenter, plasseres de i samme matrise. Dokumenter plasseres på de laveste radene og emner på de høyeste. Hvor dette skillet er satt returneres sammen med matrisen. Matriseimplementasjonen som benyttes er scipy.sparse.dok_matrix, siden den kan representere en sparse matrise uten å bruke minne på de tomme cellene. 5.2 Matrisereduksjon Til matrisereduksjonen benyttes et tredjeparts program ved navn SVDLIBC. Dette programmet leser og skriver til fil, hvilket innebærer at støtte for skriving og lesing av SVDLIBC-støttede matriseformater er blitt implementert i Pythonprogrammet. Før kjøring av SVDLIBC skrives dokument/term-matrisen til filen tempfile (dette filnavnet er mulig å endre i konfigurasjonsfilen, men tempfile vil benyttes som navn videre i denne teksten). Deretter kjøres SVDLIBC på matrisen i tempfile, og den skriver til de tre filene tempfile-ut, tempfile-s og tempfile-vt. Disse tre filene representerer de tre matrisene U k, Σ k og Vk T, som er resultatene av SVD [1]. For å fastslå relasjoner mellom dokumenter og emner benyttes vektorsøk mellom kolonnene i tempfile-vt. Disse vektorsøkene er implementert i et eget C-program ved navn matrixmult, som benytter matrisebiblioteker fra SVDLIBC. matrixmult 194

201 KAPITTEL 5. KLASINGSMODUL skriver ut en n*n-matrise med søkeresultater til filen tempfile-searchresults. Denne filen leses deretter inn igjen av python-programmet som en matrise. Denne matrisen kan betraktes som en graf, der verdien i celle (x,y) er vekten på en kant fra x til y. 5.3 Maksflyt PaperPrism støtter en variant av maksflyt for å finne relasjoner mellom dokumenter og emner. Denne baserer seg på at man også betrakter kanter mellom dokument og dokument, slik at dokumenter kan relateres til et emne via andre dokumenter. Hvor mange kanter som aksepteres mellom emne og dokument er satt som en konfigurerbar grense, der en grense på 0 impliserer at kun direkte relasjoner benyttes. Figur 5.1: Illustrasjon av en dokumentgraf. For å kunne støtte begrensningen i antall kanter, må separate grafer beregnes for hvert emne. Dette er implementert ved at alle kanter som kan brukes legges i en liste. Først legges direkte kanter til, deretter kanter som går videre fra noder som kan nås fra de tidligere kantene. Siste steg gjentas så mange ganger som grensen tillater. Figur 5.1 illustrerer en slik graf. Etter listen med kanter er funnet, omformes listen til en datastruktur bestående av Python-dictionaries. Denne gis som argument til tredjepartsbiblioteket MaxFlow. Dette regner ut maksimal flyt fra toppnoden til de andre nodene i treet. Dersom resultatet fra MaxFlow blir høyere enn noen av kantene som går direkte ut fra emnet, vil resultatet justeres ned til dette. I figur 5.1 vil resultatet av MaxFlow være 5, mens den største kanten ut fra noden er 3. Gruppens algoritme vil da returnere 3. Dette gjøres for å unngå at dokumentrelasjoner som ikke er direkte relaterte til emnene vektes høyere enn de direkte relasjonene. 195

202 5.4 Forbedring av emnevektorer KAPITTEL 5. KLASINGSMODUL En emnevektor består i utgangspunktet bare av tittelen på emnet. Da dette ikke alltid er tilstrekkelig for å finne alle dokumenter (for eksempel i tilfeller der emnenavnet kun består av stoppord), støtter PaperPrism en utvidelse av denne vektoren ved å legge til flere termer Inkludering av dokumenter Ved å inkludere teksten fra dokumenter som allerede er blitt tilknyttet et emne, vil emnevektoren få vesentlig mer innhold. Det vil dermed bli mer sannsynlig å finne koblinger til andre dokumenter. Samtidig vil SVD gis muligheten til å finne relasjoner mellom ord som ikke forekommer i de samme dokumentene Inkludering av metadata PaperPrism støtter å inkludere tekst fra emnespesifikke metadata-felter. Slike metadata kan for eksempel være en synonymordliste eller en Wikipedia-artikkel som omhandler emnet [3]. Man kan definere egne typer metadata, og velge hvilke som skal benyttes ved kjøring av programmet. 196

203 Kapittel 6 Kategoriseringsmodul Kategoriseringsmodulen baserer seg på å generere et pseudodokument for hvert emne, ved å samle alt innhold fra dokumenter relatert til emnene. Disse dokumentene preprosesseres, og samles i en emne/term-matrise. Deretter benyttes et enkelt vektorsøk for å finne de emnene som ligger nærmest dokumentet som ønskes kategorisert. Det ble i implementasjonsfasen bestemt at vektorsøket skulle implementeres i C. Grunnen til dette var at kategoriseringsmodulen måtte optimaliseres for å tilfredsstille ytelseskravene. Matrisen genereres i en nattlig jobb som lagrer den i databasen, klar til bruk når et dokument skal kategoriseres. Det er mulig å gjøre denne genereringen inkrementelt, men dette er ikke implementert da det krever tettere integrasjon mot publiseringsverktøyet og medfører liten gevinst. Gruppen har valgt å ikke benytte latent semantisk indeksering (LSI) til denne delen av programmet, da det ikke ser ut til å være noe å tjene på det. Emnevektorene bør inneholde mer data på dette stadiet, samtidig som bruk av LSI vil føre til økt kjøretid. Sistenevnte er forholdsvis kritisk, da kategoriseringen har langt strengere krav til kjøretid enn hva klasingen har. 197

204 Kapittel 7 Brukergrensesnitt Dette kapittelet beskriver utformingen av brukergrensesnittet som ble implementert. 7.1 Klasing Figur 7.1 viser hvordan kommandolinjeverktøyet arter seg for brukeren av klasingsmodulen. Grensesnittet er kun bygget opp av ASCII-tegn, og vil gi brukeren nyttig informasjon om hva programmet til enhver tid foretar seg. Figur 7.1: Kommandolinjeverktøy for klasing 198

205 KAPITTEL 7. BRUKERGRENSESNITT 7.2 Nettgrensesnitt Nettgrensesnittet ble implementert som planlagt. Det ble i tillegg implementert funksjonalitet for å kunne velge om man vil se hvilke dokumenter som befinner seg i klasene, eller å kun se selve emnene. Det ble også lagt til muligheten for å se term-vektorer og dokument/term-matriser med forskjellige vektingsalgoritmer. Dette ble gjort for å illustrere hvilken effekt de forskjellige vektingsalgoritmene har. Figur 7.2 viser hvordan det grafiske brukergrensesnittet er oppbygd. Det har blitt vektlagt at det skal være enklest mulig, uten for stort fokus på grafikk. Figur 7.2: Logisk oppbygging av det grafiske brukergrensesnittet 199

206 Kapittel 8 Datalagring PaperPrism benytter MySQL som datalager der det er mulig. Enkelte steder har det imidlertid vist seg nødvendig å benytte lagring til fil i stedet. Dette kapittelet gir en oversikt over lagringsformatene som er brukt. 8.1 Database MySQL er benyttet som datalager for emner, dokumenter og relasjoner. Figur 8.1 viser et ER-diagram for databasen. Databaseskjemaet som er benyttet ligger vedlagt i vedlegg B. Figur 8.1: ER-diagram for databasen 200

207 KAPITTEL 8. DATALAGRING Tabeller Følgende tabeller er brukt i databasen: taxonomy: Emner og relasjoner mellom emner. papers: Dokumenter. taxonomy paper rel: Relasjoner mellom emner og dokumenter. taxonomy meta: Metadata til bruk ved utfylling av emnevektor. type-feltet tilsvarer elementer i listen taxonomy[ metadata ] i settings.py. revision meta: Metadata fra klasingen. Lagrer informasjon om innstillinger som er brukt i klasingen, for senere referanse. 8.2 Datafil for kategoriseringen Kategoriseringen benytter et egenutviklet, binært format. Dette ble gjort fordi MySQL ikke kunne levere tilstrekkelig ytelse til at søket kunne gjennomføres med tilfredsstillende hastighet. Filen har først en header, og deretter emnevektorer. Headeren har følgende form: 1. Lengde av termdata (4-byte integer) 2. Termdata (termer separert med unix-linjeskift) 3. Lengde på id-felter (4-byte integer) 4. Lengde på termvektor-felter (4-byte integer) Emnevektorene har følgende form: 1. id (ren tekst av lengde spesifisert i header) 2. vektorlengde (4-byte float) 3. vektor (4-byte floats av antall spesifisert i header) Alle tallverdier er lagret i network byte order. 201

208 8.3 Intern dataflyt i klasingen KAPITTEL 8. DATALAGRING I klasingen benyttes tredjepartsprogrammet SVDLIBC og det egenutviklede C- programmet matrixmult. Dette har innført begrensninger i form av hvordan data kan overføres, og har tvunget frem bruk av filformater som SVDLIBC støtter. Disse er brukt i dataflyt mellom PaperPrism, SVDLIBC og matrixmult. De to filformatene som har blitt brukt er: Sparse Binary Dense Binary For en beskrivelse av disse formatene henvises det til SVDLIBCs dokumentasjon 1. 1 Dokumentasjonen er inkludert i SVDLIBC. 202

209 Kapittel 9 Konfigurering Programmet som er utviklet åpner for muligheten til å justere en rekke konfigurasjonsparametere. På denne måten kan programmet tilpasses dokumentsamlingen som skal klases. Konfigurasjonsparameterene kan justeres i filen settings.py i rotkatalogen til programmet. Tabell A.1 viser konfigurasjonsparameterne som er implementert, samt detaljerte beskrivelser av disse. Tabell 9.1: Konfigurasjonsparametere Parameter Verdi Forklaring paper count [> 0] Denne parameteren avgjør hvor mange dokumenter fra dokumentsamlingen som benyttes ved klasing. cluster revision [> 0] Denne parameteren avgjør hvor klasingen lagres. Dette kan benyttes dersom flere klasingsrevisjoner ønskes. For eksempel vil cluster revisjon = 2 lagre resultater som revisjon 2. key revision [> 0] Denne parameteren avgjør hvilken revisjon som brukes som fasit. Dette benyttes ved måling av presisjon og kompletthet. categorizing dbf ile < f ilnavn > Filnavnet der emne/term-matrisen skal lagres. tmpfile prefiks Prefiks for temporære filer som benyttes til søking i kategoriseringsmodulen. search p rogram < filsti > Komplett filsti til C-programmet vectorsearch, som skal benyttes til vektorsøk i kategoriseringsmodulen. Tabellen fortsetter på neste side 203

210 KAPITTEL 9. KONFIGURERING Tabell 9.1 fortsettes fra forrige side Parameter Verdi Forklaring matrix reducer svdlibc svd Setter matrisereduksjonsalgoritmen til å være tredjepartsprogrammet SVDLIBC. < annet > Andre algoritmer for matrisereduksjon er ikke implementert, men støttes av programmet. svd binary < kommando > Angir hvilken kommando som skal brukes for å kjøre SVD. Kommandoen skal inkludere full filsti til programmet som skal kjøres. matrix binary < kommando > Angir hvilken kommando som skal brukes for å kjøre vektorsøket. Kommandoen skal inkludere full filsti til programmet som skal kjøres. svd tempfile prefiks Prefiks for temporære filer som brukes av SVD-algoritmen. Om absolutt filsti mangler vil filen lagres relativt til katalogen PaperPrism kjøres fra. Filene blir slettet ved neste kjøring av programmet. k f actor [ ] K-faktoren er en faktor mellom 0 og 1 som sier hvor mye dokument/termmatrisen skal reduseres under kjøringen av SVD-algoritmen. For eksempel vil k f actor = 0.4 redusere matrisen til 40 prosent av sin opprinnelige størrelse. clustering search threshold [ ] Parameter for hvor høyt samsvar det må være mellom to dokumenter for at de skal regnes som relaterte. 0 er svært lavt og 1 er svært høyt samsvar. max jumps [> 0] Parameter som bestemmer antallet hopp som skal aksepteres i maksflytalgoritmen som benyttes i klasingen. En verdi lik 0 vil gjøre at algoritmen kun tar hensyn til de dokumentene som er direkte relaterte til emnene. taxonomy include documents verified Om include documents settes til verif ied vil emnevektorene utvides med termene til dokumenter som er bekreftet at tilhører emnet. Tabellen fortsetter på neste side 204

211 KAPITTEL 9. KONFIGURERING Tabell 9.1 fortsettes fra forrige side Parameter Verdi Forklaring unverified Samme som over, men inkluderer kun ubekreftede dokumenter (anbefales ikke). all Inkluderer både bekreftede og ubekreftede dokumenter. none Utvider ikke emnevektoren med allerede relaterte dokumenter. expand titles T rue/f alse Parameter som bestemmer hvorvidt emnevektoren skal inkludere titlene til emnene den er underordnet. Å sette denne til True øker sannsynligheten for at SVD vil oppdage at underkategorier er relaterte til hverandre, men medfører at dokumenter også vil bli mer elaterte til andre noder i samme subtre. metadata [liste] Liste med metadata-kilder som skal benyttes ved klasing. Nye kilder kan legges til ved å legge til rader i taxonomy meta-tabellen i databasen og sette type til noe annet. Ferdigutfylte medatada fra wikipedia medfølger for de emnene der dette finnes. database host adresse Adressen til databasetjeneren der dokumentdatabasen ligger. user brukernavn Brukernavnet for databasen. passwd passord Passordet for databasen. db database Databasenavnet til dokumentdatabasen. splitter phrasewords (fra, til) En nedre og øvre grense for hvor mange etterfølgende ord som regnes som en frase. phrasetags [liste] En liste med strenger som markerer start og slutt på en potensiell frase. Dersom start- og sluttmarkørene er forskjellige angis de parvis i tupler. Tabellen fortsetter på neste side 205

212 KAPITTEL 9. KONFIGURERING Tabell 9.1 fortsettes fra forrige side Parameter Verdi Forklaring tagexceptions streng Et regulært uttrykk som angir tekst inne i markup som ikke skal fjernes ved markup-fjerning. Kan settes til None. Et eksempel er r ((?<=<bilde)(.+)(?=>)), som henter ut bildetekst fra bilde-markørene som kunden bruker, men fjerner selve markøren. punctuation streng En streng med tegn som regnes som slutten på en setning (punktsetting). stopwordfilter stopwordf iles [liste] En liste med filstien til de filene som inneholder stoppordlistene. weighting local binary Benytt binær lokal vektingsalgoritme. frequency Benytt frekvensbasert lokal vektingsalgoritme. logarithmic Benytt logaritmisk lokal vektingsalgoritme. global normal Benytt normal som global vektingsalgoritme. gfidf Benytt gfidf som global vektingsalgoritme. idf Benytt idf som global vektingsalgoritme. entropy Benytt entropy som global vektingsalgoritme. 206

213 Kapittel 10 Resultater For å måle presisjon og kompletthet på forskjellige klasingsrevisjoner, ble det implementert en algoritme som tar hensyn til at et dokument kan relateres til et annet emne enn i fasiten, uten at dette nødvendigvis er helt feil. Emnekartet som er brukt er organisert i trestrukturer, der et emne kan ha flere underemner. Dersom et dokument er plassert for høyt oppe i et tre (en generalisering) i forhold til fasiten, er dette gjerne bedre enn ingen relasjon, eller en relasjon i et annet tre. Likeens kan man si at en plassering lengre nede i treet enn i fasiten (en spesialisering) er bedre enn ingenting. Dette kan til og med være ønskelig, ettersom kunden har uttalt at relasjoner ofte ikke er spesialiserte nok. En enkel algoritme traverserer emnetrærne i klasingsrevisjonen og sammenligner hver node med tilsvarende node i fasiten. Forholdet mellom antall dokumenter som finnes i begge disse nodene og antall dokumenter som finnes i kandidatnoden gir presisjonen i denne noden. Forholdet mellom antall dokumenter som finnes i begge nodene og antall dokumenter i fasitnoden gir komplettheten i noden. For å få en indikator på presisjon og kompletthet for hele revisjonen kan man bruke gjennomsnittet av nodemålene. Denne algoritmen ville ikke ta hensyn til generaliseringer og spesialiseringer. Algoritmen som blir brukt gjør det som er beskrevet, med utvidelser for å ta hensyn til generaliseringer og spesialiseringer. Dersom et dokument som finnes i en fasitnode ikke finnes i kandidatnoden, søker algoritmen etter nærmeste forgjenger eller etterkommer som inneholder dokumentet. Når antall dokumenter summeres, vektes dokumenter med 1, der d er avstand fra noden man ser på. Kompletthet 2 d blir nå summen av disse vektene delt på antall dokumenter i fasitnoden. Presisjonen finnes ved å dele hvert ledd i denne summen med antall dokumenter i nodene som har blitt brukt for å finne leddet. Figur 10.1 viser utviklingen for presisjon og kompletthet når terskelverdien for dokumentvekter økes. Vekten angir sammenfallrate ved vektorsøk, og terskelen for denne settes her i utgangspunktet til 0,1. Dokumenter som har lavere sammenfallsrate enn dette faller ikke inn under emnet man ser på. Etterhvert som terskelen heves, kan man se at presisjonen øker. Dette vil i praksis si at irrelevante dokumenter forsvinner fra emnene. Samtidig vil man miste en andel relevante 207

214 KAPITTEL 10. RESULTATER Figur 10.1: Presisjon og kompletthet ved forskjellige terskelverdier dokumenter, slik at komplettheten synker. Når terskelen nærmer seg 1,0 ser man at presisjonen ligger nær 1,0, og at komplettheten flater ut mot en viss verdi. En presisjon på 1,0 vil si at ingen dokumenter er feil plassert. Dette er blant annet tilfelle når ingen dokumenter er plassert i det hele tatt, slik som utviklingen er her. Komplettheten flater ut mot den andelen av emnene i fasiten som ikke har dokumenter. Gruppens erfaring er at det ofte ikke er lett å optimere terskelverdien. På grafen over kan man se at det ikke er noen åpenbar terskelverdi som gir et spesielt godt forhold mellom presisjon og kompletthet. Dette blir dermed en ren avveining. 208

215 Vedlegg A Algoritmer Dette vedlegget vil vise implementasjonen av noen av algoritmene i programmet. A.1 Lokale vektingsalgoritmer Figur A.1 viser implementasjonen av de lokale vektingsalgoritmene. Koden er hentet fra filen weighting.py. A.2 Globale vektingsalgoritmer Figur A.2 viser implementasjonen av de globale vektingsalgoritmene. Koden er hentet fra filen weighting.py. A.3 Vektorsøk Vektorsøket er implementert i C på grunn av høye ytelseskrav. Figur A.3 viser et lett forenklet utsnitt av koden som brukes for å utføre søket. Merk at siden resultatmatrisen er symmetrisk blir verdier på motsatt side av diagonalen fylt inn fortløpende, noe som halverer antallet søk. A.4 Rekursiv algoritme for å beregne kantgrafer Figur A.4 viser algoritmen som benyttes for å beregne kantgrafene for hvert emne før maksflyt-algoritmen kjøres. Denne koden er hentet fra filen cluster.py. 209

216 VEDLEGG A. ALGORITMER class Vector : Generates a l o c a l l y weighted term v e c t o r. def i n i t ( s e l f, id, terms, weighting = s e t t i n g s [ l o c a l ] ) : s e l f. i d = i d i f i s i n s t a n c e ( terms, d i c t ) : s e l f. terms = terms i f w e i g h t i n g : s e l f. t o t a l = sum( terms. v a l u e s ( ) ) else : s e l f. t o t a l = 1 else : s e l f. terms = {} # term w e i g h t d i c t i o n a r y s e l f. t o t a l = l e n ( terms ) # number o f non d i s t i n c t terms # count occurrences o f terms for term in terms : term = term. lower ( ) i f term in s e l f. terms : s e l f. terms [ term ] += 1 else : s e l f. terms [ term ] = 1 # perform l o c a l w e i g h t i n g ( o p t i o n a l ) i f not weight ing : return w e i g h t i n g = e v a l ( s e l f.% s % weighting ) for term in s e l f. terms. keys ( ) : s e l f. terms [ term ] = w e i g hting ( term ) def g e t i t e m ( s e l f, key ) : i f key not in s e l f. terms : return 0 return s e l f. terms [ key ] def keys ( s e l f ) : return s e l f. terms. keys ( ) def v a l u e s ( s e l f ) : return s e l f. terms. v a l u e s ( ) def binary ( s e l f, key ) : return 1 def f r e q u e n c y ( s e l f, key ) : i f s e l f. t o t a l == 0 : # Term count i s 0, so s e l f [ key ] must always be 0. # This a v o i d s 0/0 causing ZeroDivisionError. return 0 return f l o a t ( s e l f [ key ] ) / s e l f. t o t a l def l o g a r i t h m i c ( s e l f, key ) : return math. l o g ( s e l f. f r e q u e n c y ( key ) ) / math. l o g ( 2 ) Figur A.1: Lokale vektingsalgoritmer. 210

217 VEDLEGG A. ALGORITMER class Matrix : Generates a g l o b a l l y weighted document term matrix. def i n i t ( s e l f, v e c t o r s, weighting = s e t t i n g s [ g l o b a l ], p r o g r e s s b a r = None ) : from s c i p y. s p a r s e import dok matrix s e l f. v e c t o r s = v e c t o r s s e l f. matrix = dok matrix ( ) s e l f. x l a b e l s = [ ] # paper i d s s e l f. y l a b e l s = [ ] # term l i t e r a l s s e l f. terms = {} # papercount and termcount s e l f. t o t a l = 0 # number o f non d i s t i n c t terms # count occurences o f terms for v e c t o r in v e c t o r s : b u f f e r = [ ] s e l f. x l a b e l s += [ v e c t o r. i d ] for term in v e c t o r. keys ( ) : new = term not in b u f f e r i f s e l f. terms. has key ( term ) : ( papercount, termcount ) = s e l f. terms [ term ] i f new : papercount += 1 termcount += 1 s e l f. terms [ term ] = ( papercount, termcount ) else : s e l f. terms [ term ] = ( 1, 1) i f new : b u f f e r += [ term ] s e l f. t o t a l += v e c t o r. t o t a l # p o p u l a t e matrix with w e i g h t s row = 0 i f w e i g h t i n g : w e i g h ting = e v a l ( s e l f.% s % weighting ) keys = s e l f. terms. keys ( ) for i in xrange ( l e n ( keys ) ) : term = keys [ i ] ( papercount, termcount ) = s e l f. terms [ term ] i f papercount == 1 : continue # d i s c a r d terms from only one paper s e l f. y l a b e l s += [ term ] i f w e i g h t i n g : g l o b a l w e i g h t = w eighting ( term ) else : g l o b a l w e i g h t = 1. 0 for c o l in range ( l e n ( v e c t o r s ) ) : l o c a l w e i g h t = v e c t o r s [ c o l ] [ term ] i f not l o c a l w e i g h t : continue s e l f. matrix [ col, row ] = g l o b a l w e i g h t l o c a l w e i g h t row += 1 i f p r o g r e s s b a r : p r o g r e s s b a r ( f l o a t ( i + 1) / l e n ( keys ) ) def f r e q u e n c y ( s e l f, key ) : ( papercount, termcount ) = s e l f. terms [ key ] return f l o a t ( termcount ) / s e l f. t o t a l def normal ( s e l f, key ) : s = 0. 0 for v e c t o r in s e l f. v e c t o r s : s += v e c t o r. f r e q u e n c y ( key ) 2. 0 return math. s q r t ( 1. 0 / s ) def g f i d f ( s e l f, key ) : ( papercount, termcount ) = s e l f. terms [ key ] return s e l f. f r e q u e n c y ( key ) / papercount def i d f ( s e l f, key ) : ( papercount, termcount ) = s e l f. terms [ key ] return math. l o g ( f l o a t ( l e n ( s e l f. v e c t o r s ) ) / papercount ) / math. l o g (2)+1.0 def entropy ( s e l f, key ) : ( papercount, termcount ) = s e l f. terms [ key ] s = 0. 0 for v e c t o r in s e l f. v e c t o r s : p = v e c t o r. f r e q u e n c y ( key ) / s e l f. f r e q u e n c y ( key ) i f not p : continue s += p math. l o g ( p ) / math. l o g ( 2 ) return 1. 0 s / math. l o g ( f l o a t ( l e n ( s e l f. v e c t o r s ) ) ) math. l o g ( 2 ) Figur A.2: Globale vektingsalgoritmer. 211

218 VEDLEGG A. ALGORITMER // Read matrix to s e a r c h Vt = svdloaddensebinaryfile ( s v d r e a d F i l e ( tempfile Vt ) ) ; // Create r e s u l t matrix s e a r c h r e s u l t s = svdnewdmat( Vt >rows, Vt >rows ) ; // I n i t i a l i z e r e s u l t matrix with 0 in a l l c e l l s for ( i =0; i <s e a r c h r e s u l t s >rows ; i ++) for ( j =0; j<s e a r c h r e s u l t s >c o l s ; j++) s e a r c h r e s u l t s >value [ i ] [ j ] = ( double ) 0 ; // Do a l l to a l l c o s i n e s e a r c h for ( i =0; i <s e a r c h r e s u l t s >rows ; i ++) { double s l e n = ( double ) 0 ; } for (m=0; m<k ; m++) s l e n += Vt >value [m] [ i ] Vt >value [m] [ i ] ; s l e n = s q r t ( s l e n ) ; for ( j=i +1; j<s e a r c h r e s u l t s >c o l s ; j++) { double c l e n = ( double ) 0 ; } for (m=0; m<k ; m++) c l e n += Vt >value [m] [ j ] Vt >value [m] [ j ] ; c l e n = s q r t ( c l e n ) ; double r e s = ( double ) 0 ; i f ( c l e n!= 0 && s l e n!= 0) { for (m=0; m<k ; m++) r e s += Vt >value [m] [ i ] Vt >value [m] [ j ] ; r e s /= ( s l e n c l e n ) ; i f ( r e s < 0) r e s = r e s ; } s e a r c h r e s u l t s >value [ i ] [ j ] = r e s ; s e a r c h r e s u l t s >value [ j ] [ i ] = r e s ; Figur A.3: Vektorsøkalgoritme implementert i C def g e t a t t a c h e d e d g e s ( idx, s e a r c h r e s u l t s, dim, max jumps=s e t t i n g s. c l u s t e r i n g [ max jumps ] ) : Get edges ( from, to, c a p a c i t y ) from idx to o t h e r nodes, within maximum amount o f jumps. >>> g e t a t t a c h e d e d g e s ( 0, [ [ 0, 5, 0 ], [ 5, 0, 4 ], [ 0, 4, 0 ] ], 3, 0) Set ( [ ( 0, 1, 5 ) ] ) >>> g e t a t t a c h e d e d g e s ( 0, [ [ 0, 5, 0 ], [ 5, 0, 4 ], [ 0, 4, 0 ] ], 3, 1) Set ( [ ( 1, 2, 4 ), ( 0, 1, 5 ), ( 1, 0, 5 ) ] ) >>> g e t a t t a c h e d e d g e s ( 1, [ [ 0, 5, 0 ], [ 5, 0, 4 ], [ 0, 4, 0 ] ], 3, 1) Set ( [ ( 2, 1, 4 ), ( 1, 2, 4 ), ( 0, 1, 5 ), ( 1, 0, 5 ) ] ) from s e t s import Set edges = Set ( ) for j in xrange ( dim ) : i f s e a r c h r e s u l t s [ idx ] [ j ] >= s e t t i n g s. c l u s t e r i n g [ s e a r c h t h r e s h o l d ] : edges. add ( ( idx, j, s e a r c h r e s u l t s [ idx ] [ j ] ) ) i f max jumps > 0 : for (, i, ) in edges. copy ( ) : attached = g e t a t t a c h e d e d g e s ( i, s e a r c h r e s u l t s, dim, max jumps 1) edges = edges. union ( attached ) return edges Figur A.4: Rekursiv algoritme for å beregne kantgrafer. 212

219 Vedlegg B Databaseskjema Det ble i implementasjonen opprettet en database der dokumentene, taksonomien og annen informasjon ble lagret. Figur B.1 viser databaseskjemaet for databasen som er benyttet. CREATE TABLE papers ( i d i n t ( 1 1 ) NOT NULL auto increment, t i t l e t i n y t e x t, summary text, content mediumtext, PRIMARY KEY ( i d ) ) TYPE=MyISAM; CREATE TABLE taxonomy ( i d varchar ( ) NOT NULL d e f a u l t, t i t l e t i n y t e x t NOT NULL, parent varchar ( ) d e f a u l t NULL, PRIMARY KEY ( i d ) ) TYPE=MyISAM; CREATE TABLE taxonomy paper rel ( s u b j e c t varchar ( ) NOT NULL d e f a u l t, paper i n t ( 1 1 ) NOT NULL d e f a u l t 0, r e v i s i o n i n t ( 1 1 ) NOT NULL d e f a u l t 0, v e r i f i e d t i n y i n t ( 1 ) NOT NULL d e f a u l t 0, c e r t a i n t y f l o a t d e f a u l t NULL, PRIMARY KEY ( s u b j e c t, paper, r e v i s i o n ) ) TYPE=MyISAM; CREATE TABLE taxonomy meta ( i d varchar ( ) NOT NULL d e f a u l t, type varchar ( 5 0 ) NOT NULL d e f a u l t, data text, PRIMARY KEY ( id, type ) ) TYPE=MyISAM; CREATE TABLE r e v i s i o n m e t a ( i d i n t ( 1 1 ) NOT NULL d e f a u l t 0, data t e x t NOT NULL, paper count i n t ( 1 1 ) NOT NULL d e f a u l t 0, c l u s t e r p r e c i s i o n f l o a t d e f a u l t NULL, c l u s t e r r e c a l l f l o a t d e f a u l t NULL, PRIMARY KEY ( i d ) ) TYPE=MyISAM; Figur B.1: SQL database 213

220 Vedlegg C Definisjoner og forkortelser ASCII C DocStrings Frase Kategorisering Klaser LSI Modul En standard for utveksling av tekst mellom datamaskiner. Et av verdens mest brukte programmeringsspråk. Dokumentasjonsstandard for Python kode. Sett med ord som hører naturlig sammen slik de står i en setning. Det å gruppere ideer og objekter i kategorier. (clusters) - Delmengder av data der dataene i hver delmengde har fellestrekk. latent semantisk indeksering - En teknikk for prosessering av naturlig språk. Programvareenhet som samler et sett med subprogrammer og datastrukturer. Network byte order En arkitekturuavhengig standard for lagring av flerbytes tall. Preprosessering Pseudo-dokument Python Python-dictionary Sparse matrise Forberede data for bruk i en annen prosess. Dokument som ikke er en del av den opprinnelige dokumentsamlingen, men genereres av programmet under kjøring. Et programmeringsspråk En datastruktur i Python, der dataene samles i uordnede nøkkel:verdi par. En måte å representere matriser på, der posisjonen til de cellene som har en verdi ulik 0 blir lagret. 214

221 VEDLEGG C. DEFINISJONER OG FORKORTELSER Splitting Stemming Stoppord SVD SVDLIBC Før tekst kan analyseres må den splittes opp i deler, enten i form av enkeltord, delord eller grupper av ord. Redusere ord til rotform, eller stammeform Ord som forekommer svært ofte i flertallet av dokumentene. Disse ordene vil ha liten eller ingen verdi for videre tolkning av dokumentets innhold. Singular Value Decomposition - Algoritme for matrisereduksjon. Doug Rohde s SVD C Library - Et program som utfører SVD. 215

222 Vedlegg D Referanser [1] Konstruksjon, kundestyrt prosjekt, gruppe 10. [2] ( ). [3] ( ). [4] H. J. Greenberg, Ford-fulkerson max flow labeling algorithm, (1998). FF.pdf. 216

223 Del VI Testdokumentasjon 217

224 218

225 INNHOLD Innhold 1 Innledning Hensikt Omfang Hva ble testet Hva ble ikke testet Oversikt Overordnet testplan Testfaser Enhetstest Modultest System- og integrasjonstest Akseptansetest Tester som ikke skal utføres Godkjenningskriterier Kategorisering av feil Avbruddskriterier Krav til omgivelsene Dokumentasjon av testingen Enhetstest Testskript Sjekkliste Modultest Preprosessering Klasing Kategorisering System- og integrasjonstest Testspesifikasjon

226 INNHOLD 6 Akseptansetest Testlogg Enhetstest Modultest System- og integrasjonstest Akseptansetest Oppsummering A Maler 245 B Sporingsmatrise 247 C Dokument for akseptansetest 249 D Definisjoner og forkortelser 252 E Referanser

227 TABELLER Tabeller 4.1 Overordnet modultest av preprosessering Fjerning av stoppord Dokumentinnhold Overordnet modultest av klasing Overordnet modultest av kategorisering Klasing av dokumentsamling Ytelsestest av klasingen Kategorisering av et dokument Halvautomatisk tilknytning til emner Tidsforbruk ved kategorisering Simultane kategoriseringer Konfigurasjon Brukergrensesnitt Testlogg for enhetstest Testlogg for modultest Testlogg for system- og integrasjonstest Feilrapport FID Feilrapport FID A.1 Mal for testbeskrivelse A.2 Mal for feilrapportering A.3 Mal for testlogg B.1 Sporingsmatrise mellom funksjonelle krav og tester B.2 Sporingsmatrise mellom ikke-funksjonelle krav og tester

228 222 TABELLER

229 Kapittel 1 Innledning Testfasen hadde som overordnet mål å finne og korrigere feil og mangler i produktet som ble utviklet. Dette kapittelet gir en kort oversikt over innholdet i testdokumentasjonen som er blitt utarbeidet i forbindelse med denne fasen. Dokumentet er basert på IEEE standard [1], samt retningslinjer lagt til prosjektets gjennomføring. A clever person solves a problem. A wise person avoids it. Albert Einstein 1.1 Hensikt Testing er en svært viktig del av programvareutvikling. God testing vil kunne avdekke feil på et tidlig tidspunkt, slik at konsekvensene blir minst mulige. Å avdekke feil betyr ikke i denne sammenhengen kun å korrigere feil i koden. Det innebærer i tillegg å finne feil og avvik mellom det ferdige produktet som skal leveres og kundens krav og forventninger. Verifisering og validering er begge aspekter av kvalitetssikring og testing av programvare. Validering går på hvorvidt produktet tilfredsstiller kundens ønsker: lages riktig produkt? Verifisering går derimot på hvorvidt produktet bygges ut fra kravene som er satt til det: lages produktet riktig? For å oppnå høyest mulig kundetilfredsstillelse vil det være viktig å ha fokus på begge disse aspektene under testingen [4]. 1.2 Omfang Dette dokumentet inneholder all informasjon som omhandler testingen i dette prosjektet. Det beskriver strategien og fremgangsmåten gruppen brukte for å 223

230 KAPITTEL 1. INNLEDNING validere kvaliteten på produktet før det ble levert til kunden. Testene ble basert på både de funksjonelle og de ikke-funksjonelle kravene fra kravspesifikasjonen. Testene og resultatet av disse er dokumentert grundig Hva ble testet Programmet som ble testet er PaperPrism, laget i forbindelse med faget TDT4290 Kundestyrt Prosjekt ved NTNU. Programmet ble utviklet for å se hvor godt dokumenter kan kategoriseres ved bruk av latent semantisk indeksering (LSI). Dersom kunden (Bouvet) føler at resultatene er tilfredsstillende, vil de vurdere å implementere programmet i sitt allerede eksisterende publiseringsverktøy Hva ble ikke testet Programmet som ble utviklet er ment som en ekstrafunksjonalitet til et allerede eksisterende verktøy. Implementasjonen av programmet i dette verktøyet var ikke en del av oppgaven, og dette ble derfor heller ikke testet. Det ble i forbindelse med prosjektet utviklet enkle brukergrensesnitt for å bedre forståelsen av programmets funksjonalitet. Dette brukersnittet ble heller ikke testet, da dette ikke er en del av programmet som eventuelt vil benyttes videre. 224

231 KAPITTEL 1. INNLEDNING 1.3 Oversikt Resten av testdokumentasjonen er delt inn i følgende kapittel og vedlegg: Kapittel 2 beskriver den overordnede testplanen. Denne vil legge rammeverket for den videre testingen. Kapittel 3 inneholder sjekklisten som skal benyttes til enhetstesting. Kapittel 4 inneholder spesifikasjoner for modultestene som skal utføres. Kapittel 5 inneholder spesifikasjoner for system- og integrasjonstestene som skal utføres. Kapittel 6 inneholder en beskrivelse av akseptansetesten som skal utføres. Kapittel 7 inneholder loggen fra testingen av programmet. Vedlegg A inneholder malene som skal benyttes under testingen. Vedlegg B inneholder sporingsmatriser mellom tester og krav. Vedlegg C presenterer dokumentet som ble benyttet under akseptansetesten, samt en rapport fra denne testen. Vedlegg D inneholder en oversikt over definisjonene og forkortelsene brukt i dette testdokumentet. Vedlegg E inneholder en liste over samtlige referanser i dette testdokumentet. 225

232 Kapittel 2 Overordnet testplan Dette kapittelet inneholder en oversikt over hvilke strategier og rutiner som vil benyttes under testingen av programmet. Modul- og enhetstesting gjøres underveis i implementeringen, samt mer omfattende etter hver refaktorisering. Detaljerte testspesifikasjoner for system- og integrasjonstesting vil utarbeides av testleder, og tester vil iverksettes etter at nødvendige moduler har fått sin første fungerende implementasjon. Resultater og sjekklister rapporteres til testleder. 2.1 Testfaser Programmet skal testes på flere nivå, og i forskjellige faser av utviklingen. Enkelte av testene vil utføres av prosjektgruppen, mens andre vil utføres i samarbeid med kunden. Det vil her beskrives hva slags tester som skal utføres, og hva disse innebærer. For å sikre at alle krav er dekket av testene som utføres, benyttes sporingsmatriser som kobler testene til hvilke krav som testes. Disse sporingsmatrisene er gitt i vedlegg B Enhetstest De forskjellige enhetene skal testes etter hvert som de utvikles, samt når de er ferdige. Dette skal gjøres for å luke ut flest mulig feil før modultestingen. Måten dette gjøres på er ved en sjekkliste som skal gås gjennom av programmereren. I tillegg vil det kjøres en mengde testlinjer og testskript for å validere enhetenes oppførsel. 226

233 KAPITTEL 2. OVERORDNET TESTPLAN Modultest Ferdige enheter settes sammen i moduler. Modultestene skal verifisere at enhetene i modulen fungerer tilfredsstillende sammen. Det skal også testes at modulen som enhet oppfører seg som forventet. Det vil her bli laget detaljerte tester i henhold til malen gitt i vedlegg A System- og integrasjonstest Systemtesting og integrasjonstesting slås sammen, da systemets grensesnitt er en mindre viktig del av kravspesifikasjonen. På dette stadiet skal det utføres omfattende tester med artikler og taksonomier fra forskning.no som testdata. Her er det viktig at resultater dokumenteres strukturert og i henhold til standarden Akseptansetest En akseptansetest er klargjort for å teste hvorvidt det ferdige programmet samsvarer med kundens forventninger. Det skal utarbeides en testprosedyre for denne testingen, slik at gjennomføringen holder høyest mulig kvalitet. Fordi kunden er lokalisert i Oslo, er det ikke mulig å gjennomføre denne testen før prosjektet avsluttes. Det er derfor avtalt at testen kan gjennomføres av kunden etter overlevering av produktet Tester som ikke skal utføres Programmet som utvikles skal i fremtiden kunne integreres i et allerede eksisterende publiseringsverktøy, som nevnt i kapittel Det vil derfor ikke være interessant for dette prosjektet å teste mot sluttbrukerene i betydning av de som benytter kundens publiseringsverktøy. Disse vil benytte det eksisterende grensesnittet, men med noe endret funksjonalitet. Kunden vil selv gjennomføre en eventuell integrering av programmet. Det vil dermed ikke være hensiktsmessig for prosjektgruppen å gjennomføre omfattende testing av det fiktive nettgrensesnittet som ble utviklet i forbindelse med prosjektet. Brukbarhetstesting vil derfor ikke bli gjennomført for prosjektet. 227

234 2.2 Godkjenningskriterier KAPITTEL 2. OVERORDNET TESTPLAN Hver test vil bli utstyrt med godkjenningskriterier som beskriver systemets tilstand etter at testen er utført. Disse må være oppfylt for at testen skal være godkjent. Dersom et kriterium ikke blir godkjent skal det utarbeides en rapport på hvilke feil eller avvik som ble funnet, samt iverksettes tiltak for å rette opp disse feilene eller avvikene. 2.3 Kategorisering av feil Det vil her benyttes Hans Schaefers kategorisering av feil og avvik [3]. Ifølge denne kategoriseringen kan feil og avvik havne i én av fire kategorier: Kategori A: Feil i en eller flere funksjoner som forårsaker stopp. Eksempel: maskin, system eller funksjon må startes på nytt. Kategori B: Feil som har alvorlige konsekvenser i systemet. Eksempel: feil i database, alvorlige feil i rapporter slik at disse tolkes feil. Kategori C: Feil med mindre alvorlige konsekvenser. Eksempel: mindre grad av ustabilitet, mindre funksjons- eller egenskapsmangler. Kategori D: Feil uten alvorlige konsekvenser. Eksempel: layout-/trykkfeil i skjermbilder, rapporter eller dokumentasjon som ikke går utover forståelsen av disse. Når en feil oppdages skal den kategoriseres ifølge denne standarden. 2.4 Avbruddskriterier Testingen av programmet er tildelt begrenset tid i timebudsjettet, og det er derfor viktig å vite når en test skal avbrytes. En test bør avbrytes dersom den opphører å ha nytteverdi for prosjektet. For dette programmet er det bestemt at testingen skal avbrytes dersom feil i kategori A eller B oppdages. Dersom testingen avsluttes på grunn av et avbruddskriterium, skal dette dokumenteres. Feil som er oppdaget skal da korrigeres før testingen fortsetter. Følgende rutine skal benyttes ved fortsettelse av testing: Dersom feilen blir oppdaget under enhetstesting, skal den enhetstesten som feilet utføres på nytt. Dersom feilen blir oppdaget under modultesting, skal de enhetene som endres enhetstestes på nytt. I tillegg skal den modultesten som feilet utføres på nytt. 228

235 KAPITTEL 2. OVERORDNET TESTPLAN Dersom feilen blir oppdaget under system- og integrasjonstesting, skal samtlige modultester utføres på nytt. I tillegg skal den testen som feilet utføres på nytt. Dersom feilen blir oppdaget under akseptansetesting, vil gruppen vurdere hvilke tester som skal gjennomføres på nytt ut fra karakteristikken til feilen som blir oppdaget. 2.5 Krav til omgivelsene For at testene skal kunne utføres settes det krav til følgende maskinvare: x86-arkitektur (AMD / Intel). Minst 2 GHz prosessor. Minst 1 GB ledig minne. Det vil i tillegg kreves at Python-rammeverket er installert på maskinen som benyttes til testingen. Teknisk ansvarlig (Knut Auvor Grythe) er satt ansvarlig for at nødvendig maskin- og programvare er i orden før testene utføres. 2.6 Dokumentasjon av testingen All dokumentasjon som omhandler testingen skal inkluderes i dette dokumentet. Blant annet skal følgende inkluderes: Spesifiserte tester skal utarbeides for hver av testfasene. Resultatet av testene skal dokumenteres. Feil skal rapporteres i henhold til standard. Alle feil skal kategoriseres etter kategoriene gitt i 2.3. Maler for disse er gitt i vedlegg A. 229

236 Kapittel 3 Enhetstest Dette kapittelet inneholder en beskrivelse av enhetstesten til programmet. Denne testen skal utføres på hver enhet hver gang det er blitt skrevet en tilstrekkelig mengde kode, samt når en kodeenhet regnes for å være ferdigskrevet. Testen vil være todelt. Det vil først kjøres en mengde testskript. Deretter skal koden sjekkes ved hjelp av en sjekkliste. Dersom en eller flere av testskriptene eller sjekklistepunktene slår feil, må det gjøres tiltak for å rette opp feilene. En oversikt over hvilke krav som dekkes av enhetstesten finnes i tabellene B.1 og B Testskript Det finnes to typer testskript. Den enkleste typen er testlinjer som skrives direkte i DocStrings-kommentarene til enhetene. Disse testene foregår på lavt nivå i koden, og bør ikke være for omfattende. Hensikten med dem er å illustrere og verifisere normale brukstilfeller. I tillegg til disse enkle testlinjene brukes det egne testskript på bunnen av kildekodefilene. Disse vil utføre mer omfattende enhetstester enn de enkle testlinjene. Likevel bør de ikke være unødig kompliserte. De skal heller systematisk teste enhetene i filene, og ideelt sett ta for seg alle tilfeller som kan tenkes å oppstå ved normal bruk. 230

237 KAPITTEL 3. ENHETSTEST 3.2 Sjekkliste Bruk av sjekklister er den andre fasen av enhetstesten. Sjekklisten skal gåes gjennom av forfatteren av koden etter at en kodeenhet er implementert. Meningen med den er å forsøke å holde en høy standard på koden som blir skrevet. Sjekklisten er basert på [2], men er tilpasset prosjektet, både hva gjelder kodespråk og omfang. Generelt Har alle funksjoner og variabler engelske navn? Følger koden og kommentarene prosjektets kodestandard? Er det samsvar mellom konstruksjon og implementasjon? Benyttes Python som programmeringsspråk? Dokumenteres eventuelle andre støttespråk? Variabler Finnes det variabler med forvirrende eller misvisende navn? Finnes det variabler med for like navn? Finnes det ikke-lokale variabler som kunne vært lokale? Funksjoner Finnes det funksjoner med forvirrende eller misvisende navn? Bruker alle funksjonene alle parameterene sine? Sammenligninger Brukes riktig sammenligningsoperator i alle sammenligninger? Er alle sammenligninger korrekte? (Er den rette kondisjonen sjekket?) Kontrollflyt Brukes alltid beste type løkke i enhver sammenheng? Avsluttes alle løkker? Er all nøsting korrekt? Brukes det unødvendig dype nøstinger? Avsluttes alle funksjoner? 231

238 KAPITTEL 3. ENHETSTEST Modularitet Er alle utslagsgivende parametere plassert ut i konfigurasjonsfilen? Er grensesnittene som brukes generelle nok? Input / Output Åpnes alle filene før de skal brukes? Lukkes alle filene etter bruk? Testlinjer og -skript Har alle funksjonene testlinjer i DocString-kommentaren? Illustrerer og verifiserer disse testlinjene normale brukstilfeller? Er testlinjene for omfattende? Har alle kildefiler et testskript på bunnen av filen? Er testskriptene omfattende nok? Er testskriptene for omfattende? Kommentering Er alle funksjonene kommentert på engelsk med DocStrings? Er alle kommentarene forklarende og forståelige? Er det samsvar mellom kommentarer og koden? Hjelper kommentarene til å forstå koden? Er det nok kommentarer i koden? Er det for mye kommentarer i koden? 232

239 Kapittel 4 Modultest Programmet er delt opp i tre moduler, henholdsvis Preprosessering, Klasing og Kategorisering. Hver av disse modulene skal testes separat før de integreres i programmet. Modulene skal testes fortløpende etter at de er blitt integrert, og testingen skal dokumenteres i testloggen. Dette kapittelet innekolder en beskrivelse av testene som skal utføres på modulene. 4.1 Preprosessering Dette avsnittet inneholder testene som skal utføres for modulen Preprosessering. Preprosessering er en nødvendighet for at klasing og kategorisering skal fungere. Målet med preprosesseringen er å konvertere dokumenter til ordvektorer. Testene er gitt i tabell Klasing Klasingsmodulen er den modulen som grupperer et sett med ordvektorer. Målet er at ordvektorer som representerer dokumenter skal grupperes sammen med ordvektorene som representerer emnene. Det skal utføres en overordnet modultest for klasingsmodulen, gitt i tabell Kategorisering Kategoriseringsmodulen er den modulen som tilordner ett eller flere emner til et gitt dokument. Dokumentet må være preprosessert før kategoriseringsmodulen kan benyttes. Det skal utføres en overordnet modultest for kategoriseringsmodulen, gitt i tabell

240 KAPITTEL 4. MODULTEST Tabell 4.1: Overordnet modultest av preprosessering TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon Godkjenningskriterie(r) Tabell 4.2: Fjerning av stoppord TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon MT-1 Overordnet test av preprosessering Tarjei Kvamme Løset Martin Børke FK-P1 FK-P2 FK-P5 FK-P7 Utfør en preprosessering av et norsk dokument som inkluderer egennavn og fraser. Dokumentet skal være skrevet i tegnsettet ISO Modulen skal returnere én ordvektor. 2. I ordvektoren skal egennavn og fraser være skilt ut. 3. Egennavn og fraser skal ikke være på stammeform. Godkjenningskriterie(r) MT-2 Fjerning av stoppord Tarjei Kvamme Løset Martin Børke FK-P3 FK-T3 1. Utfør en preprosessering av et dokument med en standard stoppordliste. 2. Kontroller svaret mot den brukte stoppordlisten. 3. Bytt ut stoppordlisten med en tom liste. 4. Utfør en ny preprosessering av dokumentet. 5. Kontroller at svaret inneholder stoppord. 1. Ordvektoren i det første svaret skal ikke inneholde ord fra stoppordlisten. 2. Ordvektoren i det andre svaret skal inneholde stoppord. 234

241 KAPITTEL 4. MODULTEST Tabell 4.3: Dokumentinnhold TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon Godkjenningskriterie(r) Tabell 4.4: Overordnet modultest av klasing MT-4 Overordnet modultest av klasing Tarjei Kvamme Løset Knut Auvor Grythe FK-C4 Utfør en klasing av et sett med ordvektorer Klasingen skal returnere et sett med dokument/emne-koblinger. Tabell 4.5: Overordnet modultest av kategorisering MT-3 Dokumentinnhold Tarjei Kvamme Løset Martin Børke FK-P4 FK-P6 Utfør preprosessering på et dokument som inneholder: a) Tekstformatering (html, xml eller annet) b) Ord og fraser på et annet språk enn norsk 1. Preprosesseringen skal returnere en ordvektor uten å feile. 2. Ordvektoren skal ikke inneholde tekstformatering TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon Godkjenningskriterie(r) TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon Godkjenningskriterie(r) MT-5 Overordnet modultest av kategorisering Tarjei Kvamme Løset Knut Auvor Grythe FK-K1 Utfør en kategorisering av en ordvektor. Kategoriseringen skal returnere en liste med emner. 235

242 Kapittel 5 System- og integrasjonstest Dette kapittelet inneholder en kombinert system- og integrasjonstester av systemet. Disse testene skal utføres når alle programmets moduler er satt sammen. Fokuset i disse testene vil være samhandlingen mellom modulene, samt hvordan programmet samspiller med brukeren. Det skal verifiseres at systemet samspiller med kravene gitt i kravspesifikasjonen. 5.1 Testspesifikasjon Testene som skal utføres i system- og integrasjonstestingen er gitt i tabell Tabell 5.1: Klasing av dokumentsamling TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon Godkjenningskriterie(r) SIT-1 Klasing av dokumentsamling Tarjei Kvamme Løset Knut Auvor Grythe FK-C1 FK-C2 FK-C3 IF-P1 IF-P2 Foreta en klasing av en dokumentsamling. Maskinen som benyttes skal ha et UNIX-lignende operativsystem, og ha Python 2.3 eller nyere installert. 1. Klasingen skal gjennomføres uten feil. 2. Resultatet av klasingen skal vises på skjerm. 3. Resultatet av klasingen skal være lagret persistent. 236

243 KAPITTEL 5. SYSTEM- OG INTEGRASJONSTEST Tabell 5.2: Ytelsestest av klasingen TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon Godkjenningskriterie(r) SIT-2 Ytelsestest av klasingen Tarjei Kvamme Løset Knut Auvor Grythe FK-C4 IF-Y1 IF-Y2 Foreta en klasing av en dokumentsamling med minst 2000 dokumenter og 200 emner, og ta tiden på denne klasingen. 1. Klasingen skal gjennomføres uten feil. 2. Klasingen skal ta mindre enn 12 timer. Tabell 5.3: Kategorisering av et dokument TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon SIT-3 Kategorisering av et dokument Tarjei Kvamme Løset Martin Børke FK-K1 FK-K2 IF-B1 Benytt nettgrensesnittet til å kategorisere et dokument mot en allerede klaset dokumentsamling. 1. Nettgrensesnittet skal eksistere. 2. Kategoriseringen skal gjennomføres uten feil. 3. Programmet skal returnere en liste med emner. 4. Emnene skal være rangerte etter relevans. Tabell 5.4: Halvautomatisk tilknytning til emner TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon Godkjenningskriterie(r) Godkjenningskriterie(r) SIT-4 Halvautomatisk tilknytning til emner Tarjei Kvamme Løset Martin Børke FK-K3 FK-K4 1. Utfør en kategorisering av et dokument. 2. Velg to av de alternative emnene som passer best. Dokumentet skal tilknyttes kun de to emnene som er valgt. 237

244 KAPITTEL 5. SYSTEM- OG INTEGRASJONSTEST Tabell 5.5: Tidsforbruk ved kategorisering TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon Tabell 5.6: Simultane kategoriseringer TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon SIT-6 Simultane kategoriseringer Tarjei Kvamme Løset Martin Børke IF-Y4 To kategoriseringer skal utføres samtidig mot den samme ordmatrisen. Begge kategoriseringene skal utføres som normalt. Tabell 5.7: Konfigurasjon TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon SIT-5 Tidsforbruk ved kategorisering Tarjei Kvamme Løset Martin Børke IF-Y3 Utfør en kategorisering av et dokument med tidtakning. Kategoriseringen skal ta mindre enn 2 minutter. Godkjenningskriterie(r) Godkjenningskriterie(r) Godkjenningskriterie(r) SIT-7 Konfigurasjon Tarjei Kvamme Løset Martin Børke FK-T1 FK-T4 1. Åpne opp konfigurasjonsfilen og kontroller at den inneholder konfigurasjonsparametere. 2. Juster parameteren for maksimalt antall svar i resultatet. 3. Utfør en kategorisering. 1. Konfigurasjonsfilen skal eksistere. 2. Filen skal inneholde de parametere som anses som utslagsgivende. 3. Resultatet av kategoriseringen skal ikke inneholde flere resultater enn spesifisert. 238

245 KAPITTEL 5. SYSTEM- OG INTEGRASJONSTEST Tabell 5.8: Brukergrensesnitt TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon Godkjenningskriterie(r) SIT-8 Brukergrensesnitt Tarjei Kvamme Løset Martin Børke IF-B2 IF-B3 IF-B4 IF-B5 1. Kontroller at det er mulig å endre konfigurasjonsparametere via grensesnittet. 2. Foreta en klasing av en dokumentsamling. 3. Skriv inn en artikkel, og kategoriser denne. 1. Konfigurasjonsparameterene skal kunne endres via grensesnittet. 2. Under klasingen skal brukergrensesnittet gi feedback på progresjon. 3. Resultatet av klasingen skal være visualisert. 4. Det skal være mulig å skrive inn en ny artikkel via nettgrensesnittet, og få denne kategorisert. 239

246 Kapittel 6 Akseptansetest Akseptansetesten utgjør den siste delen av testingen. Her skal produktet testes mot kundens krav og forventninger. Denne testen skal teste et vidt spekter av funksjonaliteten til programmet. Testen skal utføres av kunden selv, og det er opp til kunden å avgjøre hvorvidt testen godkjennes. Akseptansetesten gjennomføres ikke under prosjektet. Kunden er lokalisert i Oslo, og det har dermed blitt enighet om at denne testen skal kunne gjennomføres av kunden etter at prosjektet er avsluttet. Det er utarbeidet et dokument som kunden kan benytte under denne testingen. Dette dokumentet inneholder et sett med oppgaver det ønskes at kunden skal utføre. Oppgavene er beskrevet detaljert, slik at kunden ikke skal måtte bruke lang tid på å sette seg inn i grensesnittet mot programmet. Dokumentet som er utarbeidet til testen er vedlagt i vedlegg C. 240

247 Kapittel 7 Testlogg Dette kapittelet inneholder en logg for gjennomføringen av testene beskrevet i de foregående kapittlene. Testloggen for modultest og system- og integrasjonstest vil følge malen gitt i vedlegg A. 7.1 Enhetstest Tabell 7.1 viser testloggen for enhetstestene som er utført. Det er i denne tabellen ført opp datoen der samtlige enhetstester i en modul er godkjente. Tabell 7.1: Testlogg for enhetstest Modul Dato Godkjent av Preprosessering Martin Børke Klasing Martin Børke Kategorisering Martin Børke 241

248 KAPITTEL 7. TESTLOGG 7.2 Modultest Tabell 7.2 gir en testlogg for modultestene som er utført. Samtlige modultester ble gjennomført uten at feil eller avvik ble oppdaget. Tabell 7.2: Testlogg for modultest TestID Dato Godkjent / FeilID Kommentar MT Godkjent MT Godkjent MT Godkjent MT Godkjent MT Godkjent 7.3 System- og integrasjonstest Tabell 7.3 gir en testlogg for system- og integrasjonstestene. Avvik og feil er rapportert i feilrapporttabellene 7.4 og 7.5. Tabell 7.3: Testlogg for system- og integrasjonstest TestID Dato Godkjent / Kommentar FeilID SIT Godkjent Resultatet av klasingen vises ved å benytte nettgrensesnittet. SIT Godkjent SIT Godkjent SIT Godkjent Det er implementert mulighet for å velge hvilke emner det ønskes assosiasjoner til, men dokumentet og assosiasjonene legges ikke inn i databasen. SIT Godkjent SIT Godkjent SIT FID-1 SIT FID-2 242

249 KAPITTEL 7. TESTLOGG FeilID Relatert TestID Beskrivelse Kategori Tiltak Tabell 7.4: Feilrapport FID-1 FID-1 SIT-7 Parameteren for maksimalt antall svar er tilgjengelig via nettgrensesnittet, og ikke via konfigurasjonsfilen. C Feilen vil ikke bli korrigert, da det ansees som mer nyttig at parameteren holdes tilgjengelig via grensesnittet. Ansvarlig Dato for ny test Testen vil ikke utføres på nytt FeilID Relatert TestID Beskrivelse Kategori Tiltak Tabell 7.5: Feilrapport FID-2 FID-2 SIT-8 Det er ikke mulig å endre konfigurasjonsparameterne via brukergrensesnittet. C Det vil ikke bli gjort noe med denne feilen, da det i samarbeid med kunden er bestemt at parameterne skal endres via konfigurasjonsfilen. Ansvarlig Dato for ny test Testen vil ikke utføres på nytt 7.4 Akseptansetest I samarbeid med kunden ble det besluttet at akseptansetesten ikke skulle gjennomføres i prosjektet. 243

250 KAPITTEL 7. TESTLOGG 7.5 Oppsummering Enhetstestene ble gjennomført ved bruk av testskript og kodeinspeksjon. Dette så ut til å fungere svært bra i dette prosjektet, og det ble ikke oppdaget feil av kategori A eller B i verken modultestene eller system- og integrasjonstestene. Modultestene ble gjennomført fortløpende etter hvert som modulene var ferdige. Preprosesseringsmodulen var ferdig før både klasings- og kategoriseringsmodulen, slik det nødvendigvis måtte være da begge de sistnevnte er avhengige av preprosesseringsmodulen. Dette gjorde at preprosesseringsmodulen kunne testes grundig utover de modultestene som var planlagt. Modultestene ble gjennomført uten at feil eller avvik ble oppdaget i noen av modulene. Ved gjennomføringen av system- og integrasjonstestene det oppdaget avvik i test SIT-7 og SIT-8. Dette var feil som går på hvordan konfigurasjonsparameterene er gjort tilgjengelige. Disse avvikene er ikke korrigert. Programmet har med dette vært gjennom omfattende testing, uten at feil av alvorlig karakter har blitt oppdaget. Gruppen mener derfor at programmet tilfredsstiller de krav som er satt i kravspesifikasjonen. 244

251 Vedlegg A Maler Alle tester blir beskrevet med følgende maler: Mal for testbeskrivelse, tabell A.1. Mal for feilrapportering, tabell A.2. Mal for testlogg, tabell A.3. Tabell A.1: Mal for testbeskrivelse TestID Navn Ansvarlig Utføres av Relaterte krav Testspesifikasjon Godkjenningskriterie(r) <Unik identifikator for denne testen.> <Beskrivende navn for testen.> <Navn på personen som er ansvarlig for at testen utføres.> <Navn på personen som skal utføre testen.> <Identifikatorene til de kravene som testes i denne testen.> <Beskrivelse av hvordan testen skal utføres.> <En liste over de hvilke kriterier som må oppfylles for at testen skal godkjennes.> 245

252 VEDLEGG A. MALER Tabell A.2: Mal for feilrapportering FeilID Relatert TestID Beskrivelse Kategori Tiltak Ansvarlig Dato for ny test <Unik identifikator for feilen.> <Identifikator til testen der feilen ble oppdaget.> <Beskrivelse av feilen.> <Kategorien feilen havner innen, som beskrevet i kapittel 2.3.> <Tiltakene som må utføres for å få korrigert feilen.> <Navn på personen som er ansvarlig for å korrigere feilen.> <Datoen testen skal utføres på nytt (ÅÅÅÅ-MM- DD).> Tabell A.3: Mal for testlogg TestID Dato Godkjent / Kommentar FeilID <TestID> <ÅÅÅÅ- MM-DD> < Godkjent / FeilID> <Eventuelle mentarer> kom- 246

253 Vedlegg B Sporingsmatrise Dette vedlegget gir sporingsmatriser mellom krav og tester. Tabell B.1 gir en sporingsmatrise mellom funksjonelle krav og tester. Tabell B.2 gir en sporingsmatrise mellom ikke-funksjonelle krav og tester. Merknad: Det ikke-funksjonelle kravet IF-I4 er ikke direkte testet, siden bruken av LSI er grunnleggende for implementasjonen av programmet. Kravet er derfor implisitt oppfylt av implementasjonen. Tabell B.1: Sporingsmatrise mellom funksjonelle krav og tester ET MT SIT AT FK-P1 X FK-P2 X FK-P3 X FK-P4 X FK-P5 X FK-P6 X FK-P7 X FK-C1 X X FK-C2 X FK-C3 X FK-C4 X FK-K1 X X FK-K2 X FK-K3 X FK-K4 X FK-T1 X X FK-T2 X FK-T3 X FK-T4 X 247

254 VEDLEGG B. SPORINGSMATRISE Tabell B.2: Sporingsmatrise mellom ikke-funksjonelle krav og tester IF-Y1 IF-Y2 IF-Y3 IF-Y4 IF-I1 IF-I2 IF-I3 IF-I4 IF-V1 IF-V2 IF-V3 IF-V4 IF-V5 IF-V6 IF-V7 IF-P1 IF-P2 IF-B1 IF-B2 IF-B3 IF-B4 IF-B5 ET MT SIT AT X X X X X X X X X X X X X X X X X X X X X 248

255 Vedlegg C Dokument for akseptansetest Dette vedlegget inneholder dokumentet som er utarbeidet i forbindelse med akseptansetestingen av programmet. Akseptansetesten ble ikke gjennomført i løpet av dette prosjektet, men dokumentet skal kunne benyttes til akseptansetesting etter overlevering av produktet. 249

256 VEDLEGG C. DOKUMENT FOR AKSEPTANSETEST Dato: Deltakere fra kunden: Dette dokumentet utgjør akseptansetesten for programmet PaperPrism. Det vil bli gitt et sett med oppgaver som skal illustrere programmets virkemåte. Det ble i kravspesifikasjonen hentet inn krav som gikk på dokumentasjon av programmet. Før selve programmet testes ønskes det derfor at følgende punkter i dokumentasjonen kontrolleres: Biblioteker og moduler som ikke er programmert av gruppen er dokumentert med versjonsnummer og referanse til hvor modulen er hentet fra. Dette skal være gjort i implementasjonsdokumentasjonen. Det er produsert en brukerdokumentasjon til programmet. Brukerdokumentasjonen forklarer og eksemplifiserer bruken av parametere i konfigurasjonsfilen. Det er produsert en installasjonsveiledning til programmet. Programmets brukergrensesnitt består av to deler; et forenklet publiseringsverktøy og et kommandolinjeverktøy for klasing. Det forenklede publiseringsverktøyet er et hjelpemiddel gruppen har laget for å vise funksjonaliteten til kategoriseringsmodulen. Her vil man kunne skrive inn en artikkel og søke etter emner som passer til denne artikkelen. Dette brukergrensesnittet er implementert som et webgrensesnitt, og vil være tilgjengelig gjennom en vanlig nettleser. Kommandolinjeverktøyet skal benyttes når en dokumentsamling ønskes klaset. Før klasingen gjennomføres vil administratoren måtte redigere konfigurasjonsparameterene i filen settings.py. Hvordan dette skal gjøres er beskrevet i brukerveiledningen til PaperPrism. Under kjøring vil kommandolinjeverktøyet gi kontinuerlig tilbakemelding på progresjon i prosessen. På neste side følger en del oppgaver som går på funksjonaliteten til programmet. Disse er i hovedsak basert på system- og integrasjonstesten som er blitt utført, og vil føre deg/dere gjennom de viktigste aspektene ved programmet. 250

257 VEDLEGG C. DOKUMENT FOR AKSEPTANSETEST Oppgaver: Klasingsveileder AT-K1 Åpne konfigurasjonsfilen som ligger i programmets rotkatalog i en vanlig teksteditor. AT-K2 Endre konfigurasjonsparameterne til de verdiene som ønskes. AT-K3 Åpne et terminalvindu, og start opp klasingsprogrammet som spesifisert i brukerveiledningen. AT-K4 Kontroller at det gis tilbakemelding på hvor langt i prosessen programmet har kommet. Publiseringsverktøy AT-P1 Åpne publiseringsverktøyet via en nettleser. AT-P2 Se på klasene fra klasingen som er utført ved å velge Se klasene fra hovedmenyen. Til informasjon: Før testens punkt AT-P3 og AT-P4 kan gjennomføres, må emne/term-matrisen genereres som forklart i brukerveiledningen. AT-P3 Forsøk å kategorisere en ny tekst. Dette gjøres ved å velge Kategoriser et nytt dokument fra hovedmenyen. AT-P4 Trykk på Kategoriser, og kontroller at forslag til emner kommer opp. Dette var en overordnet innføring i verktøyets funksjonalitet, og du/dere står også fritt til å prøve ut funksjonalitet etter eget ønske. 251

258 Vedlegg D Definisjoner og forkortelser DocStrings Funksjonelle krav Dokumentasjonsstandard for Python kode. Krav til hvilke oppgaver systemet må være i stand til å løse. Ikke-funksjonelle krav Krav som stilles til hvordan programmet skal fungere, men som ikke er tilknyttet en bestemt brukerfunksjon. Kategorisering Klasing LSI Ordvektor Preprosessering Publiseringsverktoy Stemming Stoppord Vektorsok Finne emnet til et dokument ut fra innholdet i dokumentet. Å samle dokumenter i klaser (clustere), slik at dokumenter som er semantisk relatert til hverandre havner i samme klase. latent semantisk indeksering - En teknikk for prosessering av naturlig språk. En måte å representere et dokument på, der termene som forekommer i dokumentet representeres som verdier i vektoren. Transformasjonen fra dokument til ordvektor. Verktøy for å redigere og publisere artikler på Internett. Forsøk på å fjerne bøyningsformer fra ord slik at stammen til ordet står igjen. Ord som forekommer svært ofte i flertallet av dokumentene. Disse ordene vil ha liten eller ingen verdi for videre tolkning av dokumentets innhold. Teknikk for å finne likhet mellom vektorer. I dette tilfellet vil dokumentene representeres som ordvektorer, og vektorsøk kan dermed benyttes til å finne likhet mellom dokumentene. 252

259 Vedlegg E Referanser [1] IEEE standard for software test documentation, IEEE Std (1983). [2] C. Fox, C++ inspection checklist, Process Impact (1999). [3] H. Schaefer, Mal for testplaner, (2000). [4] Øystein Haugen ed., Verification and validation in industrial perspective, (1993). 253

260 254 VEDLEGG E. REFERANSER

261 Del VII Brukerdokumentasjon 255

262 256

263 INNHOLD Innhold 1 Innledning Hensikt Omfang Oversikt Installasjonsveiledning Krav til operativsystem og maskinvare Programvareavhengigheter Kompilering av C-programmer matrixmult vectorsearch Installasjon av PaperPrism Oppsett av databasen Oppsett av Python-path Innstillinger i settings.py Installasjon av eksempel-publiseringsverktøyet Brukerveiledning Klasing Justere konfigurasjonsparametere Klase dokumentsamlingen Generere emne/term-matrise Publiseringsverktøy Se klasene Kategorisering av et dokument Lese dokumentene A Konfigurasjonsparametere

264 258 INNHOLD

265 FIGURER Figurer 3.1 Hovedmenyen i publiseringsverktøyet Nettside med en oversikt over revisjoner av klaser Resultatet av en klasing Nettsiden for kategorisering av et nytt dokument Nettside med en liste over alle dokumentene

266 260 FIGURER

267 TABELLER Tabeller A.1 Konfigurasjonsparametere

268 262 TABELLER

269 Kapittel 1 Innledning Dette dokumentet er brukerdokumentasjonen for PaperPrism - et verktøy for automatisk kategorisering av dokumenter i emnekart ved bruk av latent semantisk indeksering (LSI). Dette programmet er utviklet av gruppe 10 i faget TDT4290 Kundestyrt Prosjekt ved NTNU, høsten All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can t get them together again, there must be a reason. By all means, do not use a hammer. IBM maintenance manual, Hensikt Hensikten med denne brukerdokumentasjonen er å informere nye brukere av PaperPrism om hvordan programmet skal installeres, samt hvordan det skal brukes. 1.2 Omfang Brukerdokumentasjonen skal lede brukeren av programmet gjennom installasjonen, vise vanlig bruk og operasjoner, samt skjermbilder fra disse. 263

270 KAPITTEL 1. INNLEDNING 1.3 Oversikt Resten av denne brukerveiledningen er delt opp i følgende kapittel og vedlegg: Kapittel 2 inneholder installasjonsveiledningen til programmet. Kapittel 3 inneholder brukerveiledningen til programmet. Vedlegg A inneholder konfigurasjonsparameterene for programmet. 264

271 Kapittel 2 Installasjonsveiledning Dette kapittelet beskriver hvordan programmet PaperPrism skal installeres på en ny maskin. 2.1 Krav til operativsystem og maskinvare PaperPrism er utviklet for å fungere i et Unix-lignende miljø. Programmet er testet med Linux og Solaris, men skal kunne fungere i alle Unix-lignende operativsystemer. En del programvare kreves også preinstallert. Av maskinvare anbefales det at det benyttes maskinvare basert på x86 arkitektur. Det kreves også en del minne og prosessorkraft for at programmet skal kjøre effektivt. Anbefalte spesifikasjoner er minimum 1Gb ledig minne og en prosessor med klokkehastighet på over 2GHz Programvareavhengigheter Klasing- og Kategoriseringsmodulene har følgende krav til programvare: Python 2.3 eller nyere, med følgende moduler: SciPy PyStemmer MySQLdb SVDLIBC med kildekode (vedlagt i deps-katalogen) GCC (eller en annen ANSI C-kompatibel kompilator) MySQL-server 265

272 KAPITTEL 2. INSTALLASJONSVEILEDNING For å bruke eksempel-publiseringsverktøyet kreves også Apache (eller tilsvarende) med følgende to innstillinger i konfigurasjonsfilen: globalt: AddHandler cgi-script.py lokalt: Options MultiViews ExecCGI 2.2 Kompilering av C-programmer Deler av PaperPrism består av C-programmer. Disse må kompileres for den maskinen programvaren skal kjøres på matrixmult matrixmult bruker enkelte funksjoner fra SVDLIBC. Den enkleste måten å kompilere det på er å legge det i samme katalog som SVDLIBC-kildekoden og kompilere det der. Fremgangsmåte: 1. Kopier matrixmult.c og svdlibc matrixmult.diff fra deps-katalogen på installasjonsmediet til katalogen der SVDLIBC-kildekoden er pakket ut. 2. Patch SVDLIBC-kildekoden: patch -p1 < svdlibc_matrixmult.diff. 3. Kompiler matrixmult: gcc -lm svd*.c matrixmult.c -o matrixmult vectorsearch vectorsearch ligger i deps-katalogen på installasjonsmediet. Den enkleste måten å kompilere det på er å legge det i en valgfri skrivbar katalog og kompilere det der. Fremgangsmåte: 1. Kopier vectorsearch.c til en skrivbar katalog og gå inn i katalogen. 2. Kompiler vectorsearch: gcc -lm vectorsearch.c -o vectorsearch. 2.3 Installasjon av PaperPrism For å installere PaperPrism må først paperprism-katalogen på installasjonsmediet kopieres til katalogen PaperPrism skal installeres i. Deretter må miljøet programmet skal kjøres i settes opp. 266

273 KAPITTEL 2. INSTALLASJONSVEILEDNING Oppsett av databasen Databaseskjemaene som er benyttet ligger i database-katalogen på installasjonsmediet. Selve tabellene ligger i filen tables.sql, mens en full dump av dataene som er benyttet ligger i filen full dump.sql For å benytte dataene må en database opprettes, og dataene må importeres. Dette kan eksempelvis gjøres ved hjelp av kommandoen mysql -h server -u bruker -p database < tables.sql For spesielt interesserte ligger scriptet og XML-dataene som ble benyttet for å populere databasen også vedlagt i database-katalogen Oppsett av Python-path PaperPrism er avhengig av at de ulike Python-modulene det består av ligger i Pythons path. Det finnes to alternativer for å løse dette: Legg til katalogen PaperPrism installeres til i Python-pathen eksplisitt. Gå inn i katalogen PaperPrism ligger i og kjør programmet derfra Innstillinger i settings.py I installasjonskatalogen til PaperPrism ligger filen settings.py. Før PaperPrism kan kjøres må enkelte innstillinger i denne filen settes, hovedsaklig stier til programmer og filer som benyttes, samt autentiseringsinformasjon for databasen. Følgende innstillinger må settes før PaperPrism vil virke (eksempelverdier i kursiv): categorizing matrix dbfile : /var/lib/paperprism/categories.db tmpfile : /tmp/paperprism-categorize search program : /usr/local/bin/vectorsearch matrix binary : /usr/local/bin/matrixmult svd binary : /usr/local/bin/svd svd tempfile : /tmp/paperprism-tempfile 267

274 KAPITTEL 2. INSTALLASJONSVEILEDNING database host : mysql.mitt-firma.no user : minbruker passwd : mittpassord db : database Se vedlegg A for en komplett liste over konfigurasjonsparametre og beskrivelser av disse Installasjon av eksempel-publiseringsverktøyet For å installere eksempel-publiseringsverktøyet, kopier katalogen browser til en katalog som kan nås fra webserveren. Dersom PaperPrism ikke er lagt til i Pythonpathen, må filene settings.py og categorize.py, samt katalogen preprocessing kopieres eller lenkes inn i browser-katalogen. 268

275 Kapittel 3 Brukerveiledning PaperPrism kan hovedsaklig utføre to oppgaver, nemlig å klase en dokumentsamling, samt å kategorisere enkeltdokumenter. Klasingen gjøres fra et kommanduvindu, mens det er laget et enkelt publiseringsverktøy som brukes for å kategorisere et dokument. Dette kapittelet inneholder en beskrive av hvordan disse to delene av programmet kan brukes. 3.1 Klasing Klasingsdelen av funksjonaliteten er implementert som et kommandolinjeverktøy. For å foreta en klasing må man først justere konfigurasjonsparameterene, og siden starte opp kommandolinjeverktøyet. I tillegg benyttes kommandolinjeverktøyet til å starte genereringen av emne/term-matrisen som benyttes i kategoriseringen Justere konfigurasjonsparametere En beskrivelse av konfigurasjonsparameterene for programmet er gitt i vedlegg A. Disse parameterene endres ved å redigere filen settings.py i en vanlig teksteditor. Denne filen befinner seg i rotkatalogen til programmet Klase dokumentsamlingen Før klasing kan iverksettes må de nødvendige endringer gjøres i settings.py (se vedlegg A for en detaljert beskrivelse av parametrene). Når dette er gjort, kan kommandoen paperprism kjøres fra et UNIX-skall. Dersom PaperPrismkatalogen ikke er lagt i operativsystemets $PATH må absolutt path til programmet benyttes. 269

276 KAPITTEL 3. BRUKERVEILEDNING Generere emne/term-matrise For at enkeltdokumenter skal kunne kategoriseres, må en emne/term-matrise genereres av den ferdigklasede dokumentsamlingen. Dette er den matrisen som det utføres vektorsøk på under kategoriseringen. Det anbefales at emne/termmatrisen regenereres jevnlig, for eksempel som en automatisk nattlig jobb. Før generering av matrisen kan iverksettes må de nødvendige endringer gjøres i settings.py (se vedlegg A for en detaljert beskrivelse av parametrene). Når det er utført kan kommandoen categorize.py kjøres fra et UNIX-skall. Dersom PaperPrism-katalogen ikke er lagt i operativsystemets $PATH må absolutt path til programmet benyttes. 3.2 Publiseringsverktøy Publiseringsverktøyet er tilgjengelig via en standard nettleser. Det første man ser når man åpner publiseringsverktøyet er en hovedmeny som vist i figur 3.1. Fra denne menyen har man tre valg. Man kan enten se en visualisering av de eksisterende klasene, lese dokumentene i dokumentsamlingen eller man kan velge å kategorisere et nytt dokument. Figur 3.1: Hovedmenyen i publiseringsverktøyet Se klasene Dersom man velger å se de eksisterende klasene vil man først komme til en oversikt over klasingsrevisjonene som finnes av den aktuelle dokumentsamlingen, som vist i figur 3.2. Revisjonene er navngitt ut fra hva administratoren valgte å kalle revisjonen i konfigurasjonsfilen. Videre kan man klikke på en revisjon for å se en visualisering av den respektive klasingen. Et eksempel på en slik visualisering er vist i figur

277 KAPITTEL 3. BRUKERVEILEDNING Figur 3.2: Nettside med en oversikt over revisjoner av klaser. Figur 3.3: Resultatet av en klasing Kategorisering av et dokument Dersom man velger å kategorisere et nytt dokument, vil man komme til vinduet vist i figur 3.4. I dette vinduet vil man ha mulighet for å skrive inn en artikkel, samt velge hvor mange aktuelle emner som maksimalt skal presenteres. 271

278 KAPITTEL 3. BRUKERVEILEDNING Figur 3.4: Nettsiden for kategorisering av et nytt dokument Lese dokumentene Det vil også være mulighet for å lese dokumentene som eksisterer i dokumentsamlingen. Ved å velge Les dokumentene fra hovedmenyen, vil man komme til et vindu som vist i figur 3.5. Her vil samtlige dokumenter i dokumentsamlingen listes opp, og ved å klikke på ett av dokumentene vil man komme til et nytt vindu der artikkelen presenteres. Det vil også være mulighet for å prøve ut vektingsalgoritmene som gruppen har implementert, for å se hvordan disse fungerer. Dette gjøres ved å krysse av for de dokumentene man ønsker å vekte, samt velge hvilke vektingsalgoritmer som skal benyttes. Det vil da presenteres en matrise med dokumentene i kolonnene, og ordene som forekommer i dokumentene i radene (dokument/term-matrise). Denne matrisen vil inneholde de vektede verdiene av ordforekomstene i dokumentene. 272

279 KAPITTEL 3. BRUKERVEILEDNING Figur 3.5: Nettside med en liste over alle dokumentene. 273

280 Vedlegg A Konfigurasjonsparametere Tabell A.1 viser konfigurasjonsparameterene til programmet. Disse kan endres i filen settings.py i rotkatalogen til Pythonkoden. Tabell A.1: Konfigurasjonsparametere Parameter Verdi Forklaring paper count [> 0] Denne parameteren avgjør hvor mange dokumenter fra dokumentsamlingen som benyttes ved klasing. cluster revision [> 0] Denne parameteren avgjør hvor klasingen lagres. Dette kan benyttes dersom flere klasingsrevisjoner ønskes. For eksempel vil cluster revisjon = 2 lagre resultater som revisjon 2. key revision [> 0] Denne parameteren avgjør hvilken revisjon som brukes som fasit. Dette benyttes ved måling av presisjon og kompletthet. categorizing dbf ile < f ilnavn > Filnavnet der emne/term-matrisen skal lagres. tmpfile prefiks Prefiks for temporære filer som benyttes til søking i kategoriseringsmodulen. search p rogram < filsti > Komplett filsti til C-programmet vectorsearch, som skal benyttes til vektorsøk i kategoriseringsmodulen. matrix reducer svdlibc svd Setter matrisereduksjonsalgoritmen til å være tredjepartsprogrammet Doug Rohde s SVD C Library (SVDLIBC). Tabellen fortsetter på neste side 274

281 VEDLEGG A. KONFIGURASJONSPARAMETERE Tabell A.1 fortsettes fra forrige side Parameter Verdi Forklaring < annet > Andre algoritmer for matrisereduksjon er ikke implementert, men støttes av programmet. svd binary < kommando > Angir hvilken kommando som skal brukes for å kjøre Singular Value Decomposition (SVD). Kommandoen skal inkludere full filsti til programmet som skal kjøres. matrix binary < kommando > Angir hvilken kommando som skal brukes for å kjøre vektorsøket. Kommandoen skal inkludere full filsti til programmet som skal kjøres. svd tempfile prefiks Prefiks for temporære filer som brukes av SVD-algoritmen. Om absolutt filsti mangler vil filen lagres relativt til katalogen PaperPrism kjøres fra. Filene blir slettet ved neste kjøring av programmet. k f actor [ ] K-faktoren er en faktor mellom 0 og 1 som sier hvor mye dokument/termmatrisen skal reduseres under kjøringen av SVD-algoritmen. For eksempel vil k f actor = 0.4 redusere matrisen til 40 prosent av sin opprinnelige størrelse. clustering search threshold [ ] Parameter for hvor høyt samsvar det må være mellom to dokumenter for at de skal regnes som relaterte. 0 er svært lavt og 1 er svært høyt samsvar. max jumps [> 0] Parameter som bestemmer antallet hopp som skal aksepteres i maksflytalgoritmen som benyttes i klasingen. En verdi lik 0 vil gjøre at algoritmen kun tar hensyn til de dokumentene som er direkte relaterte til emnene. taxonomy include documents verified Om include documents settes til verif ied vil emnevektorene utvides med termene til dokumenter som er bekreftet at tilhører emnet. unverified Samme som over, men inkluderer kun ubekreftede dokumenter (anbefales ikke). Tabellen fortsetter på neste side 275

282 VEDLEGG A. KONFIGURASJONSPARAMETERE Tabell A.1 fortsettes fra forrige side Parameter Verdi Forklaring all Inkluderer både bekreftede og ubekreftede dokumenter. none Utvider ikke emnevektoren med allerede relaterte dokumenter. expand titles T rue/f alse Parameter som bestemmer hvorvidt emnevektoren skal inkludere titlene til emnene den er underordnet. Å sette denne til True øker sannsynligheten for at SVD vil oppdage at underkategorier er relaterte til hverandre, men medfører at dokumenter også vil bli mer elaterte til andre noder i samme subtre. metadata [liste] Liste med metadata-kilder som skal benyttes ved klasing. Nye kilder kan legges til ved å legge til rader i taxonomy meta-tabellen i databasen og sette type til noe annet. Ferdigutfylte medatada fra wikipedia medfølger for de emnene der dette finnes. database host adresse Adressen til databasetjeneren der dokumentdatabasen ligger. user brukernavn Brukernavnet for databasen. passwd passord Passordet for databasen. db database Databasenavnet til dokumentdatabasen. splitter phrasewords (fra, til) En nedre og øvre grense for hvor mange etterfølgende ord som regnes som en frase. phrasetags [liste] En liste med strenger som markerer start og slutt på en potensiell frase. Dersom start- og sluttmarkørene er forskjellige angis de parvis i tupler. tagexceptions streng Et regulært uttrykk som angir tekst inne i markup som ikke skal fjernes ved markup-fjerning. Kan settes til None. Et eksempel er r ((?<=<bilde)(.+)(?=>)), som henter ut bildetekst fra bilde-markørene som kunden bruker, men fjerner selve markøren. Tabellen fortsetter på neste side 276

283 VEDLEGG A. KONFIGURASJONSPARAMETERE Tabell A.1 fortsettes fra forrige side Parameter Verdi Forklaring punctuation streng En streng med tegn som regnes som slutten på en setning (punktsetting). stopwordfilter stopwordf iles [liste] En liste med filstien til de filene som inneholder stoppordlistene. weighting local binary Benytt binær lokal vektingsalgoritme. frequency Benytt frekvensbasert lokal vektingsalgoritme. logarithmic Benytt logaritmisk lokal vektingsalgoritme. global normal Benytt normal som global vektingsalgoritme. gfidf Benytt gfidf som global vektingsalgoritme. idf Benytt idf som global vektingsalgoritme. entropy Benytt entropy som global vektingsalgoritme. 277

284 VEDLEGG A. KONFIGURASJONSPARAMETERE 278

285 Del VIII Evaluering 279

286 280

287 INNHOLD Innhold 1 Innledning Hensikt Omfang Oversikt Prosessen og resultatet Gjennomføring av de ulike fasene Planlegging Forstudie Kravspesifikasjon Konstruksjon Implementasjon Testing Dokumentasjon Evaluering Gruppeprosessen Risiko som har slått til Måloppnåelse og resultat Effektmål Resultatmål Timeforbruk Kunden og oppgaven Kunden Oppgaven Faget Kundestyrt Prosjekt Generelt om faget Forelesninger og kurs Seminar i gruppedynamikk på Røros

288 INNHOLD Prosjektplanlegging Use-case-basert estimering IT-arkitektur Forelesninger som var savnet Veiledning Evaluering av verktøy L A TEX og TeXnicCenter Microsoft Word Microsoft Excel Microsoft Visio CVS og Tortoise CVS Diverse verktøy Videre arbeid Utprøving av konfigurasjonsparametere Forbedre emnevektorer Iterativ forbedring av klasing Tidsmessig forbedring Integrasjon mot publiseringsverktøyet Tidsestimat A Referanser

289 FIGURER Figurer 2.1 Timene brukt i prosjektet fordelt over ukene Timeforbruk sammenlignet med estimert timeforbruk

290 284 FIGURER

291 TABELLER Tabeller 2.1 Oversikt over timeforbruk i prosjektet

292 286 TABELLER

293 Kapittel 1 Innledning Dette dokumentet gir en oversikt over gruppe 10 sitt arbeid i faget TDT4290 Kundestyrt Prosjekt. Gruppen har i samarbeid diskutert seg frem til hvordan den totalt sett har opplevd de forskjellige sidene av faget. Ingen mennesker forstår helt - annet enn det de selv har opplevd. Carl Konow 1.1 Hensikt Hensikten med evalueringen er å se på alle sider ved gjennomføringen av faget, spesielt de som ikke kommer frem i fasedokumentene. Det er aktuelt å både se på hva som fungerte bra og hva som fungerte dårlig. Resultatet av evalueringen gir en oppsummering av gruppens erfaringer fra prosjektet, og er forhåpentligvis nyttig både for gruppens medlemmer, kunden og fagstaben. 1.2 Omfang Evalueringen tar for seg aspekter rundt gjennomføringen av faget. Det blir her sett på både resultatet av prosjektet og prosessen frem til dette resultatet. Dette inkluderer en diskusjon av gruppearbeidet, samarbeidet med kunden og faget som helhet. 287

294 KAPITTEL 1. INNLEDNING 1.3 Oversikt Resten av denne evalueringen er delt opp i følgende kapittel og vedlegg: Kapittel 2 gir en evaluering av prosjektprosessen og resultatet av prosjektet. Kapittel 3 gir en evaluering av kunden og oppgaven som ble gitt. Kapittel 4 gir en evaluering av faget TDT Kundestyrt Prosjekt. Kapittel 5 gir en evaluering av verktøyene som er brukt i prosjektet. Kapittel 6 gir en beskrivelse av videre arbeid som gjenstår for å ferdigstille produktet. Vedlegg A gir en liste over referansene benyttet i dette dokumentet. 288

295 Kapittel 2 Prosessen og resultatet Ved evalueringen av et prosjekt vil det være vanlig bedømme prosjektet ut fra resultatet. Programmet som ble utviklet evalueres her opp mot de effekt- og resultatmålene som ble satt i prosjektdirektivet [1]. Dette kapittelet inneholder i tillegg en evaluering av prosessen som førte frem til resultatet. Det evalueres her hvordan gruppen har fungert sammen, og hvordan gjennomføringen av de forskjellige fasene har foregått. 2.1 Gjennomføring av de ulike fasene Prosjektet har vært gjennom flere svært forskjellige faser. Dette avsnittet inneholder en evaluering av hvordan gruppen har oppfattet disse fasene med hensyn til gjennomføringen Planlegging Planleggingsfasen var den første fasen i prosjektet. Gruppemedlemmene brukte her mye tid til å bli bedre kjent, og å sette seg inn i hvordan prosjektet skulle gjennomføres. Det ble også brukt en del tid til å sette seg inn i oppgaven for å forstå hva som egentlig skulle utvikles. Fordelingen av roller førte til at strukturen og fremdriften i videre faser ble enklere. I ettertid føler gruppen at denne fasen var svært nyttig, selv om den strakk seg over flere uker enn forventet Forstudie Forstudiet var den lengste fasen i prosjektet. Tidlig i forstudiet ble det foretatt et kundemøte der gruppen fikk avklart en del uklarheter i forbindelse med oppgaven. Etter dette møtet satt gruppen igjen med en langt bedre forståelse av hva som skulle utvikles. 289

296 KAPITTEL 2. PROSESSEN OG RESULTATET Oppgaven gruppen fikk tildelt var innen et fagfelt der ingen av gruppemedlemmene var vel bevandret. Dette medførte at forstudiet ble en svært viktig fase i prosjektet. Mye tid ble brukt til å sette seg inn i alternative løsninger av oppgaven, samt å undersøke hvilke arbeid andre hadde gjort innen fagområdet. Etter forstudiet var gjennomført, satt gruppen igjen med en relativt klar formening om hvordan oppgaven i grove trekk skulle løses. Gruppen jobbet svært godt sammen i denne fasen, og flere av gruppemedlemmene anser dette som en av de mest spennende fasene i prosjektet Kravspesifikasjon Kunden har gjennom hele prosjektet gitt beskjed om at gruppen står relativt fritt i hvordan de velger å løse oppgaven. Den viktigste betingelsen som ble gitt var at gruppen skulle benytte LSI-algoritmen. De resterende kravene ble i hovedsak utarbeidet av gruppen som en spesifisering av de forretningsmessige kravene fra forstudiet. Kunden godkjente forholdsvis tidlig kravene som ble foreslått, samt kom med enkelte tillegg. Tidsbruket i fasen gikk dermed i hovedsak til å utforme fasedokumentets struktur og innhold Konstruksjon Konstruksjonsfasen ble gjennomført på forholdsvis kort tid, i hovedsak fordi enkelte av gruppemedlemmene hadde gjort opp en forholdsvis klar mening om hvordan programmet kunne realiseres. Denne fasen gav også flere av gruppemedlemmene oversikt over hvordan oppgaven totalt sett skulle løses. Frem til denne fasen hadde gruppemedlemmene i stor grad konsentrert seg om hver sin del av oppgaven. Dette ble dermed ansett som en svært lærerik fase i prosjektet Implementasjon Implementasjonsfasen ble gjennomført uten store komplikasjoner. Tidlig i fasen støtte gruppen på problemer med minnebruk i matriseoperasjonene. Disse operasjonene krevde mer minne enn noen av gruppemedlemmene hadde på sine maskiner. Dette ble løst ved at gruppen fikk tilgang til en av NTNUs stormaskiner. Gruppen forsøkte deretter å redusere minnebruket ved å finjustere algoritmene, samtidig som programmeringsspråket C ble benyttet til de mest ressurskrevende operasjonene. 290

297 KAPITTEL 2. PROSESSEN OG RESULTATET Testing Testfasen ble påbegynt i slutten av kravspesifikasjonsfasen, og testene ble skrevet med utgangspunkt i kravene som ble gitt i kravspesifikasjonen. Denne fasen har deretter gått i parallell med de andre fasene i prosjektet helt frem til slutten av implementasjonsfasen. Enhetstestene og modultestene ble gjennomført uten at feil eller mangler ble oppdaget. Under system- og implementasjonstestene ble det påvist avvik fra kravspesifikasjon. Disse avvikene gikk på hvordan konfigurasjonsparameterene var gjort tilgjengelige. Avvikene ble ikke korrigert, da gruppen ikke anså slike korreksjoner som avgjørende for funksjonaliteten. Akseptansetesten ble ikke gjennomført i prosjektet, men det ble lagt opp til at kunden kunne foreta en slik test etter overlevering av produktet Dokumentasjon Dokumentasjonsfasen var den siste fasen i prosjektet. Denne ble benyttet til å sette sammen dokumentet, og sørge for at det holdt en uniform sturktur. Dette tok lang tid, og svært mange ressurser ble brukt på denne typen arbeid mot slutten av prosjektet Evaluering Denne fasen ble benyttet til å skrive dette fasedokumentet. Gruppen har her evaluert flere aspekter ved prosjektet, og kom frem til både positive og negative sider ved hvordan prosjektet ble gjennomført. 2.2 Gruppeprosessen Den interne kommunikasjonen i gruppen har fungert over all forventning. Det ble i planleggingsfasen satt av tid til to internmøter i uken. Disse har blitt brukt til å diskutere fremgang og videre arbeid, og fordeling av arbeid. Spesielt i siste del av prosjektet førte god arbeidsfordeling til at flere faser kunne gå i parallell. Gruppen satt svært ofte samlet på datasal, noe som førte til at samlede beslutninger kunne bli tatt raskt. Dette forenklet også fordelingen av arbeidsoppgaver, samt bedret samholdet i gruppen. Gruppemedlemmene kom godt overens, og det oppstod ikke noen konflikter av nevneverdig art. Det har fra dag én blitt lagt vekt på at diskusjon er positivt og øker kreativiteten i gruppen. Dette har gjort at medlemmene i gruppen raskt har tatt opp temaer de har ansett som viktige, og at disse temaene har blitt diskutert på et saklig nivå. 291

298 2.3 Risiko som har slått til KAPITTEL 2. PROSESSEN OG RESULTATET I prosjektdirektivet ble det satt opp en risikotabell med ni risikofaktorer som ble ansett som relevante for prosjektet. Allerede tidlig i prosjektet merket gruppen at punkt 2 slo til. Dette omhandler ekstraarbeid i andre fag eller annen jobb. Dette førte til mindre komplikasjoner flere ganger, men tidspunktene for slikt ekstraarbeid var heldigvis spredt forholdsvis godt mellom gruppemedlemmene. Tidlig i prosjektet opplevde gruppen også at risikotabellens punkt 8 slo til. Dette punktet omhandler misforståelser mellom kunden og gruppen. Gruppen misforsto hva omfanget av oppgaven var, og fokuserte dermed på feil områder innledningsvis. Misforståelsen ble avklart i et kundemøte tidlig i forstudiet, så konsekvensen ble forholdsvis lav. Også risikotabellens punkt 9 har slått til. I forbindelse med telefonmøter med kunden har det til tider vært vanskelig å få reservert møterom med telefonforbindelse. Dette førte ved et par anledninger til at prosessen med å avtale telefonmøter ble komplisert. Totalt sett føler gruppen at prosjektet har blitt gjennomført uten store komplikasjoner. Selv om enkelte risikoer har slått til, har disse ikke ført til store konsekvenser for gjennomføringen. 2.4 Måloppnåelse og resultat For å kunne evaluere graden av måloppnåelse, må det også kartlegges hva som er resultatet av prosjektet. Gruppen anser at prosjektet hadde tre mål: 1. Gruppemedlemmene skulle lære hvordan et større prosjekt kunne gjennomføres. 2. Det skulle utarbeides en rapport som skulle evalueres. 3. Det skulle utarbeides et produkt til kunden. Gruppen har til tider funnet det problematisk å forholde seg til disse tre målene samtidig. Det første målet anser gruppen at er oppnådd, da prosjektet ble gjennomført uten store problemer. Fra veileder og fagstaben generelt har det vært svært stort fokus på rapporten. Gruppen føler at det har blitt lagt ned mye arbeid i denne, og at resultatet her er tilfredsstillende. Dette har dessverre til tider gått på bekostning av arbeidet med produktet til kunden. Kunden har vært svært forståelsesfull på dette området, selv om fremgangen med selve produktet har vært tregere enn hva den kunne vært i et ikke-akademisk miljø. I en evaluering av produktet vil det være nyttig å måle produktet opp mot effektog resultatmålene satt i prosjektdirektivet [1]. 292

299 KAPITTEL 2. PROSESSEN OG RESULTATET Effektmål Klasingen har blitt testet på de første dokumentene i dokumentsamlingen som gruppen har fått utlevert av kunden. For å måle effekten til de forskjellige parameterne som har blitt brukt, har presisjon og kompletthet blitt regnet ut med de manuelt spesifiserte emnerelasjonene som fasit. Under utprøving av programmet har det vist seg at både presisjon og kompletthet kan forbedres kraftig ved å utvide emnevektorer med et begrenset antall svært relevante termer. Gruppen ser derfor på resultatene som lovende i forhold til effektmålene Resultatmål Resultatmålet for prosjektet var at det skulle lages en prototyp av et program for automatisk kategorisering av dokumenter i emnekart. Dette programmet skulle både kunne analysere en hel dokumentsamling i forhold til en eksisterende taksonomi, og kategorisere et enkelt dokument ved å gi forslag til emner. Gruppen vurderer resultatmålet som nådd med programmet PaperPrism. 2.5 Timeforbruk Gruppen har gjennom hele prosjektet hatt en svært streng standard for hva som skulle føres som arbeidstimer. Reisetid til møter, matpauser og andre pauser er ikke tatt med i timeføringen. Tabell 2.1 viser hvordan det totale timeforbruket er fordelt over fasene. Som tabellen viser, avviker timeforbruket en del fra opprinnelig plan. Det kan være flere grunner til dette, men en av hovedårsakene vil være at det i de siste ukene ble jobbet med svært mange forskjellige dokumenter. Denne jobben ble sett på som klargjøring av sluttrapporten, og timene ble ført på Programmering og dokumentasjon. Den siste uken i prosjektet ble timeforbruket estimert til 35 timer per person i gruppen. Dette førte til et totalt timeforbruk på 1551 timer for prosjektet. 293

300 KAPITTEL 2. PROSESSEN OG RESULTATET Tabell 2.1: Oversikt over timeforbruk i prosjektet Aktivitet Opprinneligplan Brukt Avvik Prosjektledelse: 223 timer 265,5 timer 19% Forelesninger og egenlæring: 184 timer 137,5 timer -25% Planlegging: 110 timer 111,5 timer 1% Forstudium: 260 timer 264,5 timer 2% Kravspesifikasjon: 125 timer 142,75 timer 14% Konstruksjon: 70 timer 75,75 timer 8% Programmering og dokumentasjon: 284 timer 403,5 timer 42% Test: 170 timer 68,5 timer -60% Prosjektvurdering: 46 timer 11,5 timer -75% Presentasjon og demo: 78 timer 70 timer -10% Figur 2.1 illustrerer hvordan timene ble fordelt utover ukene da prosjektet foregikk. Figuren viser at timeforbruket har økt mot slutten av prosjektet. Dette var forventet, og gruppen var forberedt på denne arbeidsbelastningen. Figur 2.1: Timene brukt i prosjektet fordelt over ukene. 294

301 KAPITTEL 2. PROSESSEN OG RESULTATET Figur 2.2 viser hvordan progresjonen i brukte timer har vært i forhold til forventet brukte timer. Gruppen la tidlig i prosjektet opp til at forventet ukentlig timebruk skulle være 25 timer per person, hvilket totalt for gruppen gav 125 timer i uken. Som figuren viser, har gruppen gjennom hele prosjektet ligget under forventet timebruk. Differansen ble imidlertid tatt igjen mot slutten av prosjektet. Figur 2.2: Timeforbruk sammenlignet med estimert timeforbruk. I kravspesifikasjonen foretok gruppen en use-case-basert estimering av timeforbruk etter kravspesifikasjonsfasen. Dette inkluderte konstruksjon, implementasjon, testing og dokumentasjon. Timeforbruket ble med denne metoden estimert til 666 timer. Ved prosjektets slutt endte det reelle timeforbruket på 548 timer. Dette tilsvarer en differanse på -18% i forhold til estimatet. 295