Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Krav til biblioteksystemer l Foreleser: Runar Eggen, epost: l Trenger vi spesifisere krav? l Litt om kravspesifikasjoner.

Liknende presentasjoner


Presentasjon om: "Krav til biblioteksystemer l Foreleser: Runar Eggen, epost: l Trenger vi spesifisere krav? l Litt om kravspesifikasjoner."— Utskrift av presentasjonen:

1

2 Krav til biblioteksystemer l Foreleser: Runar Eggen, epost: l Trenger vi spesifisere krav? l Litt om kravspesifikasjoner l Bibliotekstandarder l IT-standarder l Funksjonalitet i biblioteksystemer

3 Trenger bibl. stille krav? l Er ikke de systemene bibliotek trenger ferdige? l Hvorfor skal vi lære om kravspesifikasjoner? l Enkelte av dagens systemer over 20 år gamle l Utvikling går fort

4 Hvorfor stille krav? l Viktig å vite hva man betaler for l Viktig å vite om man kan få mer for pengene et annet sted l Plikt til å utnytte ressursene til beste for bibliotekeier/brukere l Bibliotekarens viktigste verktøy l Må ikke bare kunne bruke systemet, men også velge det system som er best

5 Konservativisme 1 l Har man arbeidet 20 år i et system, er det kanskje det eneste man kan. l Da forsvarer man status quo, selv om det er faglig galt. l Leverandører kan også ha interesse av å forsvare status quo.

6 Konservatisme 2 l PC-brukere, Mac-brukere og Unix-tilhengere er ofte nærmest fundamentalister. Det samme gjelder biblioteksystembrukere. l De fleste biblioteksystem kjører i dag på Windows eller Linux/Unix, men dette er ingen naturlov. l Enkle brukergrensesnitt senker endringsterskelen, fordi bruker må investere mindre tid i systemet.

7 Et lite regnestykke l Et bibliotek skal katalogisere bøker. I ett system bruker man ett minutt lenger på hver katalogisering. En billig arbeidstime koster 200 kr. l I løpet av katalogiseringsprosessen bruker man 1667 timer eller kr ekstra på et ineffektivt system. l For kr får man kjøpt mye biblioteksystem.

8 Spesifikasjonen vanskeligst l Ikke noe annet kan i samme grad forkrøple sluttresultatet som kravspesifikasjonen. l Jo seinere en feil i programvaren oppdages, jo dyrere er de å rette opp. l Mange feil er latente og oppdages først i en annen fase enn de oppstod i. l Det gjøres mange feil i krav. l Typisk er uriktige fakta, utelatelser, inkonsistenser og tvetydigheter. l Feil i krav kan oppdages. Kilde:http://www.aitel.hist.no/fag/_pum/omkrav/omkrav.doc

9 Kravspesifikasjoner som gikk galt l TRESS-90. Trygdeetatens nye system ble skrinlagt etter at flere hundre mill. kr. var brukt. l Ariane 501-raketten, ESAs prestisjeprosjekt. Raketten eksploderte 30 sek. etter oppskytning pga. spesifikasjonsfeil i programvaren til styresystemet.

10 Viktige suksessfaktorer l Brukermedvirkning l Støtte fra toppledelsen l Klart definerte krav l Andre faktorer: skikkelig planlegging, realistiske forventninger, kortere milepæler, kompetent personale, eierskap, klar visjon og mål, hardt arbeidende og fokusert stab. Kilde:http://www.aitel.hist.no/fag/_pum/omkrav/omkrav.doc

11 Spesifikasjonens faser l Finne behov. Problemanalyse l Fastsette krav l Spesifikasjon av krav l Kontroll av endringer i krav Kilde:http://www.aitel.hist.no/fag/_pum/omkrav/omkrav.doc

12 Vanligste feil i kravspek l Manglende info –Funksjon, egenskap –Grensesnittdefinisjoner –Ytelseskrav (svartid, databasebelastning) –Kvalitetskrav (menneskelige faktorer, pålitelighet, sikkerhet) l Gal info –Konstruksjon istedenfor krav –Ikke hva kunden ønsker –Tvetydige krav –Inkonsekvente krav –Ikke testbare krav l Unødvendig info –Kjekt å ha Kilde:http://www.aitel.hist.no/fag/_pum/omkrav/omkrav.doc

13 Kravspek for utvikling/kjøp l Biblioteksystemer er til en viss grad hyllevare, og de fleste bibliotekarer vil derfor i liten grad ta del i systemutvikling. l Men for mange bibliotek vil valg og innføring av et nytt system være et stort prosjekt som krever en spesifikasjon. l Det kan ofte bli snakk om tilpasninger av hyllevare.

14 Krav skal leve lenge l Kravspesifikasjonen skal leve lenge, ofte lenger enn de første programmene den spesifiserte. l Det er derfor viktig at den er modifiserbar. Da må den være konsistent, og ikke redundant. Dvs. at et man bruker ord konsekvent og at et tema/objekt behandles ett sted.

15 Databasen viktig(st) l Databasen er minst like viktig som programmene. Dataene skal leve lenger. l Databasestruktur må kunne endres. l Data må kunne masse-endres og hentes ut uten programmering. l Viktig å følge standarder, som f.eks. SQL. –Ikke alle biblioteksystem gjør dette.

16 Brukervennlighet og fleksibilitet l Det er av og til en konflikt mellom brukervennlighet og fleksibilitet. l En programleverandør som får motstridende krav fra forskjellige kunder, må velge mellom å vedlikeholde forskjellige kodeversjoner eller å legge inn parameterstyring av programmene. l Stor grad av parameterstyring kan gjøre systemet komplisert å sette opp og bruke. Løsning: Gode installasjonsprogrammer og dokumentasjon. Evt. sentral drift.

17 Brukervennlighet 2 l Brukergrensesnitt i et biblioteksystem bør likne andre programmer slik at kunnskap får overføringsverdi.

18 Bibliotekstandarder 1 l MARC-formatet - hvilket MARC-format? –MARC-formatet langt fra perfekt –Unødvendig komplisert (00-feltene, indikatorer, delfelter) –Lite egnet for programmering –Lite konsekvent (bl.a. bruk av indikatorer) –Selvmotsigende (for eksempel aldersgrupper i 008- feltet) –Snevert (kun brukt av bibliotek) –Foreldet –MEN bedre med en standard enn ingen!

19 Bibliotekstandarder 2 l MARC-formatet er så utbredt at det blir krevende å skifte det ut. l Tendens til å gå tilbake til ett MARC-format (UKMARC er lagt ned, svenskene går over til MARC21.) l XML kan bli viktig framover. Generelt format med generelle verktøy l XML-innpakket MARC l Hva betyr det at man er XML-kompatibel? l Dublin Core kan redusere behovet for MARC- katalogisering.

20 Bibliotekstandarder 3 l Dublin Core The Elements (ikke bare bibliotek) –Title –Creator –Subject –Description –Publisher –Contributor –Date –Type –Format –Identifier –Resource Identifier –Source –Language –Relation –Coverage –Rights

21 Bibliotekstandarder 4 l AACR 2 –Ble til i en annen tid (hva trenger du ordningsord til i dag for eksempel?) –Hva er ordningsord? (tenk biografier) –Svært detaljert –Systemene tar hånd om mye av reglene (. - trenger du ikke tenke på lenger) –ISBD-visning en fordel, men ikke absolutt nødvendig. Men KOMPAKT og lett å lese! –Bedre med en standard enn ingen!

22 Bibliotekstandarder 5 l CCL – Common Command Language l Mange sier de følger det. l Men ofte har de bare noe som likner. l Hvem vet hva det er? l Spiller det noen rolle?

23 Bibliotekstandarder 6 l Z39.50 er en protokoll for samtidig søking og oppdatering i flere databaser. Fra 1990-årene. Programvare tilgjengelig lenge, men begrenset utbredelse. l NILL – Norsk fjernlånstandard (Norwegian InterLibrary Lending). Ganske ny, de første applikasjonene ute nå.

24 IT-standarder – operativsystem 1 l Tre hovedtyper: Windows, MacIntosh og Unix (Linux er en Unix-variant) l Windows og Unix mest aktuelle for biblioteksystemer l Alle operativsystemene gir mulighet for grafisk grensesnitt l Eldre biblioteksystemer har tegnbasert grensesnitt (BIBSYS, eldre Bibliofil-versjoner, Mikromarc 1)

25 IT-standarder - operativsystem 2 l Windows - hvilken Windows? l 32 og 16 bits Windows l 32 bits programmer går ikke på Windows 3.x l 32 bits Windows er fra og med Win95 l Hvis en leverandør sier at systemet går på 16 bits Windows, skal du ikke kjøpe det. Det betyr at det ikke utnytter mer moderne Windows- versjoner.

26 IT-standarder - operativsystem 3 l Operativsystemuavhengig? l Web-baserte biblioteksystemer sies å være operativsystemuavhengig. Stemmer det? l På serversiden: Serveren må kjøre ett eller annet operativsystem. l På klientsiden: Ja, men ikke alle systemer støtter alle HTML-versjoner, og er heller ikke like gode i alle nettlesere. l Et system bør la seg kjøre i de vanligste nettleserne. I Norge i dag (oktober 2004) er dette Opera, Mozilla og Internet Explorer.

27 IT-standarder – grensesnitt 1 l Grafisk grensesnitt et absolutt krav i dag –Det er bare en viktig systemleverandør i Norge som ikke oppfyller dette. l Unicode –gjør det mulig å representere alle alfabet i ett tegnsett. 16 bits tegn istedenfor 8, hvilket gir forskjellige tegn istedenfor 255. De færreste biblioteksystem tilbyr unicode i dag.

28 IT-standarder – grensesnitt 2 l Web-grensesnitt begynner å bli vanlig, ikke bare for søk, men også for utlån og katalogisering l Web-grensesnitt har mange fordeler og minst en ulempe –Fordeler: operativsystemuavhengig på klientsiden, små krav til linje, stedsuavhengig –Ulemper: vanskeligere, men ikke umulig, å få inn funksjonalitet

29 Klient-tjener (client-server) l Teknologien populær i Windows-miljø l Tynne eller tykke klienter (tynne krever mindre av linjer og maskiner) l Windows krever ”mellomklient” hvis man må via internett for å nå serveren. l Citrix ICA-klient brukes bl.a. av MM2. l Flerlagsarkitektur (multi-tier) gjør klientprogrammene og serverprogrammene mer uavhengige av hverandre.

30 IT-standarder – dokumenter l Dokumenter bør være i standard- formater. l Dokumenter bør ikke være i proprietære formater som Microsoft Word osv. l Dokumenter skal kunne leses om flere hundre år. l Derfor er XML viktig for bibliotek.

31 Funksjonalitet i biblioteksystemet l Her skal vi se på: –Hva ”alle” systemer har/bør ha –Hva noen systemer har –Nye tjenester –Bibliotekmarkedet –Biblioteksystem-markedet

32 Hva ”alle” systemer har/bør ha l Innkjøpssystem l Katalogsystem m/autoritetsregister l Utlånssystem l Publikumssøk m/bestilling, melding på web l Tidsskriftsystem l Statistikk og rapportfunksjon enkel å bruke! l Sanntids oppdatering, én database l Filialhåndtering, konsortiehåndtering

33 Skille klinten fra hveten l Siden "alle" systemer har de fleste basisfunksjonene, blir det viktig å vite hvor forskjellene ligger. l Ikke alle forskjellene like nødvendige, men de kan fortelle om utviklingstakt.

34 Hva noen systemer har 1 l Publikumstjenester: l Mappa mi/Lånerprofil l Selvbetjening og utlånsautomat l Epost- og SMS-varsling (forfalte lån, ank. reserveringer) l Søk fra mobiltelefon l Katalogkrydder/Innsyn l Visning av fulltekstdokumenter l Z39.50-basert samsøk l Z39.50 server og Z39.50 klient

35 Hva noen systemer har 2 l Utlån l System nede-funksjon l Fjernlånssystem l Direct mail til lånergrupper l Forhåndsreservering til en best tid (booking) l Boken kommer l Bilde av lånerne l Forskjellige lydsignaler i utlånsskranke l Import av lånerdata fra skoleadm. systemer

36 Hva noen systemer har 3 l Katalog/Innkjøp: l Enkel kopiering av katalogposter fra andre l Filtre ved import av data for å luke ut uønsket informasjon l Integrert innkjøp av bøker (Ved bestilling i nettbokhandel overføres katalogdata og innkjøpsdata til ditt biblioteksystem)

37 Hva noen systemer har 4 l Generelt: l Grafisk grensesnitt l Brukertilpasning (skjermbilder, søkbarhet, rettigheter, rutiner etc.) l Replikering (kopiering av db med toveis oppdatering) l Sentral drifting

38 Hva noen systemer har 5 l Generelt: l Databasen bør være SQL-kompatibel, eventuelt kompatibel med etterfølgende standarder l Alle klientfunksjoner bør kunne kjøres i en nettleser (se f.eks. reindex.net)

39 Bokomslag, omtale, innh.fort. l ISBN brukes til å koble den lokale bibliotekkatalogen til en sentral base der omslagsbilde, forlagets bokomtale, baksidetekst og, i noen tilfeller, innholdsfortegnelse ligger. l Flere norske biblioteksystemer har tatt i bruk slike løsninger.

40 Bokomslag, bokomtale, innh.fort.

41 Også BIBSYS har dette

42 Og Bibliofil har det

43 Mulige nye tjenester 1 l Samtidig oppdatering av flere systemer (Z39.50 gjør det mulig å katalogisere i flere baser samtidig) l Forbedret samtidig søk i flere baser (Se UB Karlsruhe, BIMIN, NORZIG) l karlsruhe.de/hylib/en/kvk.html karlsruhe.de/hylib/en/kvk.html l

44 Mulige nye tjenester 2 l Automatisert fjernlån (NILL) l Integrering av digitale ressurser –innebærer at systemet kan se hvilke tidsskrifter institusjonen abonnerer på, og brukerne kan dermed lese disse på sin PC

45 Mulige nye tjenester 3 l Open Archive Initiative –Automatisk høsting av data til samkataloger –Automatisk høsting av data til tverrfaglige databaser (f.eks. Oljedirektoratet) l Open URL (standard) l Norsk digitalt bibliotek (ABM) l Søk i heterogene ressurser, f.eks. bibliotek/bokhandel/web som hos UB Karlsruhe, SFX/Metalib, Z portal, Endeavor) l Paradigmeprosjektet (arkivering av Internett). Kun for forskere!

46 Mulige nye tjenester 4 l Felles lånerkort for alle norske bibliotek (prosjekt igangsatt) l Håndtering av alle tegnsett (arabisk, hindi etc. krever Unicode, få systemer har det i dag) l Sentralt vedlikeholdte databaser over databaser (SFX/Metalib) l Emneportaler (Bibsys m.fl.)

47 Mulige nye tjenester 5 l Vekting av treff. Dette gjøres i søkemotorer på web, hvorfor ikke i biblioteksystemer? l Komponentbaserte systemer –Biblioteksystemet kan settes sammen av standardkomponenter fra forskjellige leverandører –Korter utviklingstid og øker omstillingsevne

48 Initiativ savnet! l Z-portaler ikke på langt nær så utbredt som man skulle tro l Regionale portaler f.eks. folkebibl. l Faglige portaler l Markedet har ikke fungert her l Naturlig oppgave for Norsk Digitalt Bibliotek og ABM!

49 Bibliotekenes framtid l Lex armlengde – man er interessert i de bøker man har innen armlengdes avstand. l Lex tastetrykk – man er interessert i den informasjon man har tilgjengelig ved hjelp av et par tastetrykk. l Informasjon her og nå – ikke om ei uke jfr SFX/Metalib l Ingen bruker fornøyd med en referanse! l Lånere skal ikke behøve gå til biblioteket! l Sluttbrukerstyrt fjernlån

50 Hvordan det kan gjøres l The Cochrane Library er frikjøpt av SHDIR for alle norske brukere – en av verdens aller beste medisinske databaser. Sjekker om du kommer fra en norsk IP- adresse. l

51 Systemgenerasjoner l 1. generasjon: Tegnbaserte stor/minimaskinsystemer. Proprietær db. Katalog og utlån ofte de første modulene. l 2. generasjon: Tegnbaserte PC-systemer. l 3. generasjon: Grafisk grensesnitt. "Komplette systemer". Web-basert publikumssøk. Lenking til fulltekstdokumenter. SQL database. l 4. generasjon: Komponentbasert. Gjennomført web- grensesnitt i hele systemet. Fulltekst integrert, som f.eks. søking i fulltekstdokumenter, samtidig søk i heterogene ressurser, kobling til elektroniske tidsskrifter, systemet vet om du har abbonnement. Z- portaler. Mobiltelefoner/mobile terminaler.

52 Bibliotekmarkedet l Hovedgrupper l Allmenne (folkebibliotek, videregående skoler, grunnskoler) l Fagbibliotek –Høyskoler (små og mellomstore) –Universitet (store) –Spesialbibliotek (sykehus, musikkbibliotek, departementer, oftest små) –Firmaers informasjonssentre (ikke opphengt i marcformat eller tradisjonelle bibliotekdyder)

53 Biblioteksystem-markedet l Forskjellige systemer dominerer de forskjellige markedsnisjene. Ofte historiske årsaker til hvilke systemer som dominerer hvilke nisjer, ikke nødvendigvis systemenes egenskaper avgjørende. l Folkebibliotek: Bibliofil, Mikromarc og Aleph l Skolebibliotek: Mikromarc, Bibliofil og Tidemann l Universitet og høgskoler: Bibsys, Aleph og Mikromarc l Spesialbibliotek: Mikromarc, Tidemann, Bibsys og Bibliofil

54 Faktorer å vurdere ved kjøp 1 l Funksjonalitet, brukervennlighet l Videreutvikling l Lett å skifte ut (dataene viktigere enn system). Må med i kontrakt! l Operativsystem, maskinplattform, minnekrav l Norsk leverandør og brukerstøtte l Pris (anskaffelse, årlig avgift, hjelp) l Samarbeid med andre bibliotek

55 Faktorer å vurdere ved kjøp 2 l Er systemet moderne i dag? l Hvis ikke, er det sannsynligvis at det vil være det om et år? Om fem år? l Systemene i norske bibliotek er generasjon, men 4. generasjon er tilgjengelig. l Vi kan derfor komme til å se en omfattende utskifting i de neste årene.

56 Sentral drifting l Fordeler: –IT-avdelinger glade for å slippe ansvar for biblioteket (marginalt) –Biblioteket glade for å slippe ansvar for IT (kompetanse) –Sikrere backup –Alltid siste versjon installert l Ulemper: –Ikke alltid gratis –Båndbredde kan være problem

57 Leverandører av katalogdata l Biblioteksentralen – slik bibliotek vil ha dem l Forlagsentralen – ofte raskest l Nasjonalbiblioteket – "gratis" poster l Bibsys – "gratis" poster for outsidere l Samme arbeidet gjøres minst 3-4 ganger i Norge l Dere bør ikke gjøre det enda en gang l Internett – "gratis" poster l Hvem har copyright til katalogposter?

58 Tenk økonomi og trivsel! l BS og FS tilbyr integrert bokkjøp og overføring av katalogpost og eksemplaropplysninger. l Mer enn halvparten av arbeidet spart ved å bruke ferdige katalogposter. l Brukerne betaler for arbeidstiden din!

59 Forslag til videre lesning l (teknisk web-mag., månedlig) l (teknisk web-mag., kvartalsvis) l (generelt, 20 nr årlig) l (postlister) l (Nasjonalbiblioteket) l Norsk digitalt bibliotek Norsk digitalt bibliotek (Paradigme-prosjektet) m (Z39.50 in your library) m

60 Leverandørene Biblioteksystemer l l l l l Katalogdata l Alle bibliotekkataloger i landet

61 Standarder l l l l l rmarc.html rmarc.html

62 Forelesning 2: Hva alle bør ha l Innkjøpssystem l Katalogsystem m/autoritetsregister l Utlånssystem l Publikumssøk m/bestilling, melding på web l Tidsskriftsystem l Statistikk og rapportfunksjon enkel å bruke! l Sanntids oppdatering l Filialhåndtering, konsortiehåndtering

63 Innkjøpssystem (Akkvisisjon) l Innkjøpssystemet skal holde orden på –anskaffelsesønsker –bokvalg –ordre –oppfølging (purring etc) –mottak –mediebudsjett l Det bør ha mulighet for direkte kommunikasjon med leverandører

64 Innkjøp l Valutahåndtering l Leverandøropplysninger l Bestille for andre bibliotek/filialer l Håndtere flere konti –Vise forbruk/tilgjengelige midler grafisk l Overføre penger mellom år l Fordeling av budsjett over måneder –Forskellig mønster bøker/tidsskrifter l Bruke EAN for å søke

65 Innkjøp l Bøker som skal bestilles, må kunne reserveres l Endring av eksemplarstatus –Setting av innstillinger for hvordan mottatte bøker skal behandles (innbinding, utlån etc).

66 Innkjøp l Et innkjøpssystem er ikke et regnskapssystem, men kan likevel gi god økonomisk oversikt. l Egne regler for regnskapssystem

67 Katalogisering l Det må kunne styres hva som skal autoriseres l Katalogprogram må ha tilgang til –Bibliografiske data –Eksemplaropplysninger –Autoritetsfiler –Emneord –Klassifikasjonssystem

68 Katalogisering l Autoritetsregistre må kunne oppdateres direkte fra katalogprogrammet l Endring av autoritetsregistre bør ha en kontrollmekanisme som "Ønsker du virkelig å gjøre dette?". –Globalt å bytte ut en term med en annen kan være risikabelt

69 Katalogisering l Sømløs kopiering av eksterne poster l Sømløs kommunikasjon m/Innkjøp l Sømløs kommunikasjon m/Utlån og fjernlånsfunksjon l Forhåndsvisning i ISBD/MARC, evt. andre standardformater l Bør kunne velge hvilket format data skal lagres i og vises i

70 Katalogisering – søk l Søking må kunne høyre-, venstre- og midttrunkeres l Trunkeringstegn bør være valgfritt l "Alt" bør være søkbart, også eksemplaropplysninger –Kommandosøk –Indeksblaing –Grafisk søk

71 Katalogisering l Henvisninger må kunne håndteres direkte i katalogisering (autoritet) l Søk på en form må gi treff på de andre formene –Eks.: Mumle Gåsegg må også gi treff på Johan Borgen

72 Katalogisering l Katalogisering av flerbindsverk må være mulig og enkel å utføre l Lenking mellom versjoner av et dokument bør være mulig l Lenking av bind i flerbindsverk nødvendig l FRBR Functional Requirements for Bibliographic Records l Hvis du er interessert i FRBR, se: l

73 Katalogstatistikk l Årlig tilvekst l Total samling l Samlingens fordeling på fag, medietype, lånergrupper og filialer l Tilvekstens fordeling på fag, medietype, lånergrupper og filialer l Budsjettets fordeling på fag, medietype, lånergrupper og filialer l Bibliotekmyndigheters krav

74 Søking l Søking i samlingen bør være tilgjengelig fra alle større moduler l Grensesnitt bør helst være nokså likt fra modul til modul l Det bør være mulig å lagre søk l Det bør være mulig å få personifiserte meldinger om nyheter

75 Utlån l Registrere utlån og tilbakelevering –Varsel til skrankepersonale l Reservere dokumenter l Forhåndsreservere (booke) l Fornye lån l Purre/Rykke l Reserveringsbrev/epost

76 Utlån l Fleksibelt oppsett av utlånsbetingelser og overdagspenger l Enkelt oppsett for når bibliotekets filialer er åpne l Justere forfallsdato tilsvarende, slik at ikke bøker forfaller på dager biblioteket er stengt.

77 Utlån l Utlån av elektroniske dokumenter er spesielt l Bør elektroniske dokumenter tilbakeleveres? –Hvis ikke, må dokumentet bli ubrukelig når lånetid er utløpt –Hvis ja, hva skiller det fra et vanlig lån?

78 Rapporter l Det bør være enkelt å ta ut rapporter på –Ankomne reserveringer –Uavhentede reserveringer –Bøker som er/har vært reservert –Lånere som skylder penger –Lånere som er sperret –Bøker som skal flyttes –Eksemplarer med en bestemt status Det bør være enkelt å modifisere rapporter og skape sine egne

79 Utlånsstatistikk 1 l Totalt antall lån i en gitt periode l Lån fordelt på filial, lånergruppe, faggruppe, materialtype l De mest utlånte titler (innkjøp) l De minst utlånte titler (kassering) l De mest aktive lånergrupper (ta hensyn til i mediebudsjett?) l De minst aktive lånergrupper (markedsføring)

80 Utlånsstatistikk 2 l Statistikk bør lett la seg kopiere til andre programmer (tekstbehandling, regneark) l Grafer bør produseres l Bør kunne definere nye statistikker, for eksempel ved hjelp av SQL l Bør tilfredsstille myndigheters krav

81 Utlån - Fjernlån l Systemet bør håndtere både innlån fra andre bibliotek og utlån til andre bibliotek. l Bør håndtere kopier og elektroniske lån l Bør gjøre bruk av nasjonale og internasjonale standarder l I Norge: NILL og Base Bibliotek

82 Publikumssøk l Skal være selv-instruerende l Skal likevel ha kraftige søkemuligheter –Velge mellom ett eller flere-felt-skjerm, indeksblaing, grafisk søk l Bør ha valgfritt språk l Bør vise lenkede dokumenter (flerb.) l Bør ha kart over biblioteket l Et eksempel: Informatikkbiblioteket: l

83 Publikumssøk l Bør kunne reservere –også be om fjernlån l Bør kunne se nyheter i biblioteket l Bør kunne se de mest populære titler l Bør kunne se egne lån l Bør kunne avbestille reserveringer l Bør kunne se tilknyttede dokumenter (både fulltekst og evt. lenkede referanser)

84 Publikumssøk og andre bibl. l Andre bibliotek vil ønske å se MARC- poster slik at de kan kopiere eller sjekke egen katalogisering l Andre bibliotek vil ønske å be om fjernlån

85 Tidsskriftkontroll l Heftekontroll l Sirkulasjonskontroll l Utsending av innholdsfortegnelse l Tilgang til elektronisk tidsskrifthefte (kan også plasseres andre steder i systemet) l Varsling om nye hefter for tidsskrifter innen låners interessefelt

86 Tidsskriftkontroll l Utgivelsesmønstre varierer l System må være fleksibelt l System kan bli svært komplisert l Avhengig av god datamodell og planlegging

87 Oppetid l Systemets oppetid –Må være oppe så lenge biblioteket er åpent –Bør være oppe 24t x 7 l Brukerstøtte bør være tilgjengelig i bibliotekets åpningstid

88 Sikkerhet 1 l Databasen må ikke være fysisk tilgjengelig for alle brukere –ODBC er en måte å oppnå dette på (Open Database Connection) l Databasen må ha muligheter for selv- reparasjon ved f.eks. strømbrudd. –Checkpoints, rollback –Loggfiler –Speiling

89 Sikkerhet 2 l Forskjellige brukergrupper må kunne settes opp med forskjellige adgangsnivåer l Bibliotek i konsortier bør ikke se hverandres utlånsdata

90 Dette er ingen spesifikasjon l Forelesningsnotatene fra denne og forrige forelesning er kun en generell innføring, de er ingen kravspesifikasjon l Mange institusjoner har laget svært detaljerte krav, mange av dem kan gjenbrukes! l Ikke sikkert at du finner et system som tilfredsstiller ALLE kravene – må veie krav mot hverandre


Laste ned ppt "Krav til biblioteksystemer l Foreleser: Runar Eggen, epost: l Trenger vi spesifisere krav? l Litt om kravspesifikasjoner."

Liknende presentasjoner


Annonser fra Google