Forord
Denne rapporten er sluttproduktet til gruppe 41 i forbindelse med faget PJ500/IPJ200 ved Norges informasjonsteknologiske høgskole (NITH) Oslo. Rapporten er skrevet av 6 studenter fra 3. klasse bachelor- og ingeniørstudiet vårsemesteret 2003. Rapporten henvender seg i utgangspunktet til veileder og sensor.
Gruppen vil rette en spesiell takk til Knut Yrvin og Petter Reinholdtsen som har vært gode støttespiller underveis i prosjektet. Vi vil også takke alle personene i Skolelinuxmiljøet som har gitt gode innspill og tilbakemeldinger.
Oppgaven var å utvikle et brukervennlig brukerforvaltningssystem for Skolelinux.
Vi har forbedret dagens mangelfulle grafiske grensesnitt.
Løsningen som leveres inneholder:
Arkitektur
Beskrivelse av løsningen
Vurdering av sluttproduktet
Vurdering av utviklingsprosessen
Kjørbar versjon av systemet
Kildekode
Andre prosjektdokumenter
Vedlegg
Innholdsfortegnelse
1.5
Presentasjon av oppdragsgiver og prosjektet
2.2
Valg av teknikker og verktøy
4.1
Beskrivelse av teknisk løsning
4.2
Beskrivelse av organisatorisk løsning
5.1
Vurdering av teknisk løsning
5.2
Vurdering av nytte for arbeidsgiver
5.3
Vurdering av utviklingsmetode
5.4
Vurdering av teknikker og verktøy
5.5
Vurdering av utviklingsprosessen
1. Innledning
I innledningen ønsker vi å gi en kort presentasjon av rapporten, oppdragsgiver, prosjektet samt visjonen og avgrensningen for prosjektet.
1.1 Presentasjon av rapporten
Denne rapporten er et resultat av prosjektet i faget PJ500 ved Norges Informasjonsteknologiske Høgskole (NITH) i Oslo.
Kapittel 2 omhandler utviklingsmetode, teknikker og verktøy. Her beskrives bruken av RUP og hvilke teknikker og verktøy vi har benyttet gjennom prosjektperioden.
Kapittel 3 tar for seg analyse og utforming av systemet. Krav til løsningen samt system arkitekturen med utvalgte use case og diagrammer med kommentarer er presentert. Vi har i tillegg tatt for oss de ikke-funksjonelle kravene i denne delen av rapporten.
Kapittel 4 gir en detaljert beskrivelse av den tekniske løsningen og av den organisatoriske løsningen.
I kapittel 5 vurderer vi sluttproduktet. Vurderingen omfatter teknisk resultat av systemet og hvilken nytte gruppen tror at systemet vil få for oppdragsgiver.
I kapittel 6 vurderes utviklingsprosessen. Her blir det lagt vekt på hvordan RUP, teknikker og verktøy har fungert for oss.
Kapittel 7 inneholder konklusjonen for dette prosjektet.
1.2 Visjon og avgrensning
1.2.1 Visjon
Vi skal lage et brukervennlig og unikt brukergrensesnitt til brukeradministrasjonssystemet i Skolelinux. Brukergrensesnittet skal ha uvurderlig verdi for brukerne.
1.2.2 Avgrensning
Vi har som mål å lage et brukergrensesnitt til brukeradministrasjonssystemet som oppfyller de viktigste kravene i kravspesifikasjonen. Vår oppgave vil bestå av å lage et godt grunnlag for videreutvikling. Dersom systemet blir implementert i Skolelinux, vil kanskje brukerne oppdage nye behov, som vil medføre at systemet kan videreutvikles. Det finnes i dag en håndfull skoler som har tatt Skolelinux i bruk, men antallet vokser, og flere vil få kompetanse i bruk av systemet. Med utstrakt bruk vil kravene bli flere, og et riktigere bilde vil skapes av brukeradministrasjonssystemet. Avgrensningen omfatter de kravene som kunden mente var kritisk for å ta Skolelinux i bruk.
1.3 Problemstilling
Kunden (Skolelinux) har behov for å utbedre dagens brukeradministrasjonssystem i Webmin. Dette systemet vil gjøre det lettere for IKT-ansvarlige på skolene.
1.4. Problemformulering
Gruppen har fått i oppgave å utvikle et system, som skal
forenkle administrasjonen av brukere i et Skolelinux operativsystem. Systemet
skal lages på grunnlag av ønsker, behov og krav fra kunden og brukerne.
1.5 Presentasjon av oppdragsgiver og prosjektet
1.5.1 Presentasjon av oppdragsgiver
Skolelinux prosjektet ble satt i gang av den idealistiske medlemsorganisasjonen
Linux
i skolen. Organisasjonen vil tilrettelegge for og informere om bruk av
fri programvare i den norske skolen, for eksempel Linux og GNU. Skolelinuxprosjektet
ble startet 2. juli 2001. 4. oktober ble forprosjektdelen støttet av
Utdannings- og forskningsdepartementet. Departementet vil videreføre Skolelinuxprosjektet.
Prosjektet Skolelinux går ut på å utvikle
en distribusjon av Linux for norske skoler.
Linux skiller seg fra andre
operativsystemer som skolene bruker ved at kildekoden er åpen. Dette gjør det
enkelt å tilrettelegge operativsystemet og brukerprogrammene for norske forhold.
Dette står i kontrast til lukkede datasystem der bidragsytere stenges ute, og
en er avhengig av velvilje fra internasjonale produsenter. Det at Linux
og åpen programvare er fritt tilgjengelig vil medføre store økonomiske
besparelser for skolene. De slipper å betale dyre lisenser for programvaren.
1.5.2 Forutsetninger for prosjektet
Oppdragsgiveren stiller med lokale, maskinvare og programvare som er nødvendig for å gjennomføre prosjektet i hele prosjektets tidsrom fra 28.1.2003 til 9.5.2003. I tillegg til dette må oppdragsgiver stille med ekstern veileder til gruppen. Den eksterne veilederens oppgave vil først og fremst være å utdype virksomhetens ønsker i prosjektet. Vedkommende skal være tilgjengelig for å gi faglig råd, være til hjelp, følge opp prosjektets fremdrift og foreta nødvendige beslutninger. NITH skal stille med intern veileder til gruppen, som skal bistå med teoretisk og metodisk veiledning.
2. Metode
2.1 Valg av utviklingsmetode
2.1.1 Bruk av RUP
Rational Unified
Process (RUP) er en utviklingsmetode som beskriver
hvordan man kan jobbe med prosjekter. RUP og andre utviklingsmetoder kan brukes
på forskjellige måter. Metodene er ofte laget for å dekke forskjellige behov. I
et utviklingsprosjekt skal en løse en spesiell problemstilling. Da benytter man
bare deler av utviklingsmetoden.
Det er viktig å velge de elementer fra uviklingsmetoden som er nyttig for å raskest mulig komme fram til en best mulig løsning. For å være effektiv må man velge hvordan man bruker utviklingsmetoden. Verktøyet styrer deg ikke gjennom en utviklingsmetode, men gir frihet til å benytte metoden som det passer deg.
RUP definerer følgende fire prosjektfaser: (våre fasenavn i parentes)
Inception (forberedelsesfasen, idéfasen)
Elaboration (utdypningsfasen)
Construction (konstruksjonsfasen)
Transition (avslutningsfasen)
Hver iterasjon omfatter seks arbeidsprosesser (workflows) i større eller mindre omfang. Fordelen med dette er at man tidligere blir klar over kritiske feil, lærer av dem og dermed forbedrer arbeidsmetoden underveis.
De arbeidsprosessene som inngår i selve utviklingsarbeidet
er:
Forretningsmodellering. (Business Modeling). I samarbeid med Skolelinux modelleres den
organisasjon og den forretningsdrift som systemet skal operere innenfor.
Kravspesifikasjon. (Requirements).
I samarbeid med Skolelinux beskrives funksjonelle krav ved hjelp av Use Casene.
Analyse og design. Vi modellerer
funksjonalitet og beskriver en teknisk løsning for systemet ved hjelp av
klasse- og sekvensdiagrammer i Microsoft Visio.
Implementering. Programmering i PERL og CGI
Test. Utprøving av systemet i et
testmiljø.
Installasjon. (deployment).
Installasjon og konfigurasjon, ferdig versjon, implementert i Skolelinux.
2.2 Valg av teknikker og verktøy
I PJ500 har gruppe 41 benyttet flere forskjellige verktøy og teknikker for å skape oversikt, og effektivisere prosessen mest mulig.
2.2.1 UML
Alle diagrammene vi har benyttet i dette prosjektet er en del av UML (Unified Modeling Language). UML er en standard objekt modelleringsteknikk og blir brukt til å visualisere, dokumentere og spesifisere de forskjellige objektene i et objektorientert system under utvikling. Dette er spesielt viktig i forhold til god kommunikasjon mellom utviklere og kunde.
I dette prosjektet har vi tatt i bruk en rekke ulike
diagrammer innen UML. Det første vi utviklet var ulike
Use Case diagrammer samt business use case diagram. Videre utviklet vi en domenemodell,
aktivitetsdiagrammer, klassediagram, sekvensdiagrammer og utplasseringsdiagram.
Diagrammene ble laget for å ha et rammeverk å utvikle etter.
2.2.2 Grupperegler
I forhold til gruppeprosessen ble det skrevet ned grupperegler helt i begynnelsen av prosjektet. Disse skulle fungere som et verktøy for å sette klare rammer rundt arbeidsinnsats og oppmøte, slik at alle gruppemedlemmene skulle ha klart for seg hva som ble forventet.
2.2.3 Risikoliste
I tillegg til gruppereglene ble det også satt opp en risikoliste som inneholdt kalkulerte problemer som kunne oppstå og forsinke prosessen. Problemene er også rangert etter sannsynlighet, og det er beregnet hvor mange timer det er sannsynlig at hvert problem vil kreve. Risikolisten inneholder også en plan for hvordan mulige problemer, som kunne oppstå, skulle løses.
2.2.4 Prosjektplan
Microsoft Project er et verktøy som blir brukt til å lage oversiktlige planer for prosjekter. I vår gruppe har Microsoft Project blitt brukt til å lage overordnede og detaljerte faseplaner for prosjektperioden.
2.2.5 Iterasjonsmål/statusrapport
I tillegg til de detaljerte faseplanene ble det satt opp iterasjonsmål før hver iterasjon. Det ble også skrevet statusrapport etter hver iterasjon. Dette er verktøy til hjelp for å beholde oversikten over hvilke mål som ble nådd og hvilke oppgaver som skal gjennomføres i iterasjonen som ligger foran.
2.2.6 Behovsanalyse
Når en skal utvikle et nytt produkt, er det viktig å ta brukerne med i prosessen. Dette kan en gjøre ved å gjennomføre en analyse av hva brukerne tenker om systemet, hva de har av krav og hva de ønsker seg av funksjonaliteter. Noe av det første gruppe 41 gjorde i prosjektet var å gjennomføre en slik behovsanalyse. I denne analysen intervjuet vi noen IKT-ansvarlige i skolen. Her fikk vi avdekket problemer, ønsker og behov som disse mente var viktig for det systemet vi skulle utvikle.
2.2.7 Systemutviklingsverktøy
Til systemutviklingen har gruppen valgt å designe alle diagrammer i Microsoft Visio. Microsoft Visio er et systemutviklingsverktøy fra Microsoft som er designet til å kunne lage alle de modellene som er nødvendig i et prosjekt som dette.
2.2.8 Andre verktøy
Flere Microsoft Office programmer er brukt. Excel er brukt til føring av tidslogger for hvert enkelt gruppemedlem, og selve rapporten er skrevet i Microsoft Word. På våre lokaler satt vi opp et Skolelinux nettverk. Her har vi benyttet diverse programmer, som for eksempel OpenOffice til skriving av dokumenter. All programmeringen har blitt utviklet i dette miljøet.
2.2.9 Prototyper
Vi har utviklet noen prototyper som et hjelpemiddel for at vi og andre kan se hva vi tenker om systemet og hvordan det vil se ut. Ofte er det lettere å vise systemet til brukerne med prototyper, enn om en skulle forklart systemet ved bruk av diagrammer.
2.2.10 Programmering
Til utviklingen av systemet har programmeringsspråket PERL blitt benyttet. Vi har også programmert noe CGI script. Programmering i disse språkene var nødvendig på grunn av at modulen vi skulle forbedre i Skolelinux var programmert i PERL og CGI fra før.
2.2.11 Installasjon
Installasjonsprogrammet i løsningen er laget som en debianpakke som implementeres i Webmin i Skolelinux ved ferdigstilling.
2.2.12 Versjonshåndtering
Alt det vi har utviklet har også blitt dokumentert som html filer på nettet. Gruppen har brukt Concurrent Versions System (CVS) til å laste opp og ned sider fra vårt hjemmeområde på Skolelinux serveren. Samtidig som en forandring skjer på vårt område, vil det bli registrert og logget. Dette gir en oversikt over forandringer som blir gjort, og det blir også sendt ut en melding til utvalgte brukere i miljøet om at det har blitt gjort en forandring.
2.2.13 Tidslogg
Gruppens medlemmer har i gjennom prosjektet skrevet tidslogg, for fellesarbeid og individuelt arbeid. Dette verktøyet bidrar til å gi oversikt over den totale arbeidsmengden, og hvordan arbeidet er fordelt mellom gruppemedlemmene. Slik forhindrer man at noen må dra hele prosjektet.
3. Analyse og utforming
Brukerne av brukeradministrasjonssystemet består i hovedsak av IKT-ansvarlige på skolene. Vi ville vite hvilke ønsker og forventinger de har til systemet, og på bakgrunn av dette utformet vi en behovsanalyse, som gå grunnlaget for kravspesifikasjonen
3.1 Krav til løsningen
Kunden hadde klare ønsker om funksjonelle krav til systemet. Kravene var at brukerne skal kunne:
Legge til/slette bruker
Utføre masseinnlegging av brukere fra fil
Opprette/slette grupper
Legge til/fjerne bruker fra en eller flere
grupper
Endre passord
Søke etter bruker(e)
Søke etter klasse(r)
3.2 Analyse og design
Vi startet med å utvikle modellene: Business Use Case, Use Case, domenemodell samt prototyper av systemet. Videre utviklet vi aktivitetsdiagrammer, sekvensdiagrammer og klassediagram. Modellene ble revidert i hver iterasjon etter behov.
3.2.1 Arkitektur
Et Architectural View er et vindu til systemet fra et gitt perspektiv som viser den viktigste informasjonen eller ideen og ignorerer resterende informasjon.
3.2.1.1 Use Case
Use Case spiller en viktig rolle i
beskrivelse av arkitekturen, og blir brukt gjennom hele prosessen. De danner
grunnlaget for utvikling av alle modeller.
Vi har valgt å legge ved Use Casene: Business Use Case, overordnet
Use Case, to detaljerte Use Case, brukeradministrasjon
og administrere brukere.
Business Use Case
Business Use Case gir et overblikk over hvordan de ulike aktørene samhandler med Skolelinux. Administrasjon er en bruker som har mulighet for å administrere skolens system. Vedkommende har i tillegg ansvaret for installering og vedlikehold av systemene på skolen. Systemutvikler er en som jobber på frivillig basis for Skolelinux.
Use Case: Overordnet
Overordnet Use Case gir oversikt over hvordan de forskjellige aktørene spiller sammen. De IKT-ansvarlige har ansvar for å administrere skolens brukere i Skolelinux. Aktørene lærer og administrasjon ved skolen har også visse rettighet til å administrere brukerne. Elever har også enkelte rettigheter i systemet.
Detaljert Use Case: Brukeradministrasjon
Dette diagrammet viser hvilke hoveddeler av systemet de forskjellige aktørene har tilgang til. IKT-ansvarlige og administrasjon har tilgang til alle deler av systemet. Lærer og elev har kun tilgang til administrere brukere.
Detaljert Use Case: Administrere brukere
IKT-ansvarlige har alle rettigheter. Administrasjon har alle rettigheter med unntak av muligheten til å slette brukere. Lærer har mulighet til å endre brukerinformasjon og passord til brukere. Eleven har kun tilgang til å endre sitt eget passord.
3.2.1.2 Logical view
Logical view adresserer de funksjonelle kravene til systemet, altså hva systemet skal gjøre for sluttbrukerne. Det viser de viktigste lagene i den konseptuelle organiseringen av software. Eksempelvis kan dette være domenemodell, klassediagram, pakkediagram, interaksjonsdiagram og aktivitetsdiagram. Vi har valgt å legge frem domenemodellen og klassediagrammet som viser systemet med de viktigste komponentene.
Domenemodell
Domenemodellen viser de
konseptuelle klassene.
Klassediagram
Klassediagrammet viser alle programmeringsklassene, men ikke alle attributter og metoder. Brukerhåndterer er avhengig av Gruppehåndterer, Passordhåndterer og tilgang- og rettighetshåndterer for å kunne opprette bruker. Gruppehåndterer er avhengig av Tilgang- og Rettighethåndterer for å kunne opprette grupper.
3.2.1.3 Process view
Process view viser de sammenfallende aspektene av systemets kjøretid, oppgaver, adferd, tråder eller prosessen og dens vekselvirkninger. Her adresserer temaer som deadlock, responstid og feiltoleranse. Under følger to eksemplarer av sekvensdiagram.
Sekvensdiagram: Opprett bruker manuelt
Dersom systemet prøver å generere et brukernavn som allerede er i bruk, vil systemet generere et liknende brukernavn automatisk.
Sekvensdiagram: Endre brukerinfo
Systemet vil gi melding om at den nye informasjonen er registrert.
3.2.1.4 Deployment View
Deployment
view beskriver hvordan de forskjellige komponentene
er koblet til de underliggende plattformene. Det er i vårt tilfelle
utplassering og installasjon.
Utplasseringsdiagram
Komponentene til brukeradministrasjonssystemet ligger i pakken Webmin-LDAP-Skolelinux. Administrator kommuniserer mot systemet ved hjelp av en nettleser. Brukeradministrasjonssystemet kommuniserer med LDAP via grensesnittet NET::LDAP. Alle komponentene i utplasseringsdiagrammet kan ligge på noden tjener.intern, men modellen viser hvordan administrator kan fjernadministrere systemet.
3.2.2 Kommentar til arkitektur
Vi har brukt mønstre i designet av klassediagrammet. I objektteknologi er et mønster
en navngitt beskrivelse av et
problem, og en løsning som kan anvendes på nye kontekster. Ideelt gir det råd
om hvordan det skal anvendes under forskjellige omstendigheter, og tar i
betraktning fordeler og ulemper. (Larman, 2001)
3.2.2.1 Informasjons Ekspert
Informasjons Ekspert er en klasse som tildeler ansvar til den klassen som har den nødvendige informasjonen til å oppfylle ansvaret. Enten har klassen informasjonen selv ellers så har den tilgang til den fra en annen klasse. Vi tar utgangspunkt i Use Caset Opprett bruker. Her er det klassen Brukerhåndterer som er Informasjons Ekspert. Denne klassen har tilgang til nødvendig informasjon.
3.2.2.2 Kontroller
Kontroller er en klasse som tildeler ansvaret for å motta eller håndtere en hendelse til en klasse. Dette kan være en fasade kontroller eller en Use Case kontroller.
I klassediagrammet, er UI en fasadekontrollerklasse. Denne kontrollerer direkte klassene Brukerhåndterer, Gruppehåndterer, Passordhåndterer samt Tildele rettigheter og tilgangshåndterer. En Use Case kontroller kontrollerer og kobler de resterende klassene i diagrammet.
3.2.2.3 Lav kobling
Kobling er et mål på hvor tett et
element er koblet til andre elementer. En klasse med ”lav kobling” er ikke
avhengig av andre klasser. Vi har designet klassediagrammet slik at klassene
får ”lav kobling”, men det viste seg å være vanskelig å gjennomføre.
3.2.2.4 Høy kohesjon
Graps-mønsteret
”Høy kohesjon” sier noe om nært funksjonelt slektskap. Kohesjon viser hvor
relatert og fokusert ansvarstildelingen til en klasse er. Ved utarbeidelse av
klassediagrammet har vi tatt hensyn til dette, og mener at høy kohesjon er
oppnådd i designet.
3.2.3 Ikke funksjonelle krav
3.2.3.1 Miljø
Webmin er laget for Linux og skrevet i PERL. Programmet benytter en nettleser, siden Webmin er en webapplikasjon.
3.2.3.2 Ytelse
Responstiden til webapplikasjonen er avhengig av nettets
ytelse og størrelsen på nettet som skal administreres.
3.2.3.3 Utvidelse muligheter
Ettersom vi har begrenset tid til å jobbe med dette prosjektet, har vi måttet nedprioritere en del funksjonalitetskrav. Vi har allikevel tatt dem med i kravspesifikasjonen med tanke på fremtidig utbedring av systemet.
3.2.3.4 Legalitetskrav
Webapplikasjonen skal være enkelt å bruke, men brukerne bør ha noe erfaring med bruk av Internett. Bruker må kunne navigere seg fram på systemet via en nettleser samtidig må brukeren være logget inn i Webmin.
3.2.3.5 Opplæring
Vi hadde som mål å utvikle et brukervennlig og enkelt system. Det skal i utgangspunktet være selvforklarende, så brukerne slipper noe videre opplæring. Vi har i tillegg utviklet en brukermanual og Skolelinux holder også kurs i bruk av systemet.
3.2.3.6 Samarbeidskrav
Siden systemet er en webapplikasjon samarbeider det kun med
nettleserne.
4. Beskrivelse av løsning
4.1 Beskrivelse av teknisk løsning
4.1.1 Beskrivelse av teknisk løsning mot kravspesifikasjon
Systemet er utviklet i en iterativ syklus med moderne
utviklingsmetoder. Designet er objektorientert. Dette bidrar til at det i
fremtiden vil være mulig å utvide med ny funksjonalitet, gjenbruke deler av
systemet, gjøre endringer uten at komplikasjoner oppstår, med mer.
Systemet er implementert i PERL. Modulen som vi har laget
for Webmin har i oppgave å administrere et nett. Det innbærer å administrere
brukere(endre passord og info), legge til, slette, grupper og brukere.
Oppretting av bruker kan gjøres manuelt eller ved
masseinnlegging fra fil.
Velger man manuelt kan man legge inn flere brukere etter
hverandre, for så å opprette alle på slutten. Brukernavnet er basert på hele
fornavnet + eventuelt første, andre bokstav, og så videre av etternavnet,
avhengig av gyldigheten til brukernavnet. Hvis man ikke velger hva passordet
skal være for brukeren(e) så er passordet lik brukernavnet. Vi kom frem til at
dette var den beste og enkleste løsningen, siden brukeren selv kan endre passord
etter første innlogging.
Ved oppretting av bruker velger man hvilke grupper brukeren
skal være med i. Det er et prekrav at gruppene er opprettet på forhånd. Det er
mulig å legge en bruker til flere grupper, noe som er svært nyttig. For
eksempel kan en bruker være medlem av gruppen 2a, elevråd og kjemiklassen.
Bruker har kun tilgang til hjemmeområder til grupper der bruker selv er med.
Ved masseinnlegging av brukere fra fil, er formatet på filen
viktig. Ved feil format kan uventede feil oppstå. En av årsakene er at
applikasjonen leser inn brukerne linje for linje. Feil som følge av manglende
eller ekstra felter vil derfor forplante seg videre. Brukerne ligger i en
katalogtjener (LDAP) som man får tilgang til gjennom en webleser. Søketiden er
avhengig av ytelsen og størrelsen på nettet som skal administreres. Liste over
brukere kan vises etter gitte søkekriterier og man får da informasjon over
hvilke grupper de aktuelle brukerne er medlem av. Det er også mulighet til å
endre informasjon om hver enkelt bruker, som navn og hvilke grupper den er
medlem av. Tilgang til bruker kan sperres hvis brukeren har brutt datareglene.
Dette gjøres enkelt ved at administrator kun endrer passord til brukeren. Dette
forenkler mye, fordi dokumenter osv til brukeren beholdes.
Bokstavene æ, ø og å støttes av system, ved at de blir gjort
om til henholdsvis a, o og a i de aktuelle brukernavnene.
4.1.2 Beskrivelse av brukermessig funksjonalitet.
Gruppen har lagt stor vekt på brukervennlighet, og har
derfor laget enkle og oversiktlige skjermbilder. Skjermbildene er enkle og
selvforklarende.
Det ble foretatt en brukertest for å verifisere at kravene til systemet var implementert og funksjonelle. Systemet er nøye testet for blant annet å sikre et godt brukergrensesnitt. Dette ble gjennomført for å gi oppdragsgiver en trygghet for at det nye systemet virker i henhold til kravspesifikasjonen.
Bruker av systemet kan med fordel ha deltatt på
opplæringskurs i regi av Skolelinux, og ha noe erfaring med Internett. Det ble
også laget en egen brukermanual med utfyllende tekst til skjermbildene.
Vi har i samsvar med brukere vurdert den brukermessige
funksjonaliteten av sluttproduktet til å være av god kvalitet.
4.2 Beskrivelse av organisatorisk løsning
Skolelinuxprosjektet er, som tidligere nevnt, igangsatt av den idealistiske medlemsorganisasjonen Linux i skolen. Prosjektet Skolelinux går ut på å utvikle en distribusjon av Linux for norske skoler. Brukere av Skolelinux er i hovedsak elever, lærer og administrasjon ved skoler. Vi har fått i oppgave å forbedre brukergrensesnitt til brukeradministrasjonssystemet. Vi har laget systemet som en debianpakke og lagt den ut i Webmin. Webmin er et modul i en nettapplikasjon som blant annet IKT-ansvarlige ved skoler bruker for å administrere skolens brukere av systemet. Ved innføringen av systemet vil det ikke være behov for større organisatoriske forandringer, enn at brukerne kan gjennomføre kurs i bruk systemet i regi av Skolelinux
5. Vurdering av sluttprodukt
5.1 Vurdering av teknisk løsning
Svakheter:
Store endringer mot slutten har gjort at vi ikke
har fått testet den endelige løsning så godt som vi kunne håpet, og koden er
generelt ikke så finpusset.
Som andre webapplikasjoner lider Webmin av
problematikk med forskjellige browsere, nett problemer
og lignende. Dette er dog forhold utenfor vår kontroll.
Styrker:
Systemet har enkle og funksjonelle løsninger på
å legge inn brukerer(e) også fra fil.
Bruker/elev har mulighet for å være medlem av
flere grupper/klasser, som for eksempel sin egen klasse og elevrådet.
Elev/bruker kan selv endre sitt eget passord.
Brukere kan flyttes mellom hovedgrupper.
Brukernavn blir generert.
Passord blir generert hvis ønskelig, men det kan
også settes ett felles passord.
5.1.1 Testing
Innledning
Testing av systemet har skjedd fortløpende gjennom store deler av prosessen. Perl er et programmeringsspråk gruppen ikke hadde kjennskap til fra tidligere, og programmererne testet derfor koden før de implementerte den i systemet. I de tidlige fasene av prosjektet testet systemererne systemet etter hvert som ny kode ble produsert, og siden vi alle satt i samme lokalet ble feil fortløpende rapportert til programmererne og rettet. Den delen av prosjektet som ny kode ble produsert ble frosset i konstruksjonsfasen og ingen ny kode skulle lages. Kravspesifikasjonen danner grunnlaget for testene og hvilke tester som skal foretas. Testansvarlig laget manuelle tester slik at hele systemet kunne testes under ett, testene består av skjemaer der inndata skal gi forventet utdata.
Testobjekter
Målet med testingen er å sjekke at:
Nye og endrede deler av systemet gir de
resultatene som er ønskelig, systemet fungerer som forutsatt.
De uendrede delene av systemet gir samme
resultat som før.
Funksjoner og egenskaper som skal testes
Opprette og slette grupper
Opprette og slette brukere, manuelt
Opprette bruker fra fil
Søke på klasser og navn
Endre brukerinformasjonen
Endre passord, elev og administrator
Testresultat
Testene ble utført og skjemaene med inndata og resultat ble returnert til programmererne slik at de kunne rette opp i de feilene som forekom. Nye versjoner av systemet ble videre testet på samme måte og prosessen ble gjentatt til vi ikke fant flere feil.
5.2 Vurdering av nytte for arbeidsgiver
Prosjektet vi har gjennomført hadde som hovedmål å lage et
brukervennlig brukerforvaltningssystem til Skolelinux og forbedre dagens
mangelfulle grafiske grensesnitt. Dette hovedmålet ble vi utfordret av
Skolelinux organisasjonen til å gjennomføre.
Den modulen av Skolelinux vi nå har utviklet vil bedre dagens
brukerforvaltningssystem i operativsystemet Skolelinux. De som vil få mest
igjen for det vi har utviklet er de IKT-ansvarlige på skoler, som har satt opp
et Skolelinux nettverk. De vil på en raskere, mer effektiv og enklere måte
kunne legge inn brukere i systemet. Vårt system vil frigjøre IKT-ansvarlige fra
mye arbeid med brukere i operativsystemet, og de vil kunne bruke mer tid på
elevene som trenger deres hjelp. Siden systemet er nokså selvforklarende og har
et enkelt grafisk grensesnitt, vil en IKT-ansvarlig
også lettere kunne delegere oppgaver til andre ansatte om det skulle være
nødvendig.
Skolelinux organisasjonen, som er vår oppdragsgiver, vil sannsynligvis i
seg selv ikke få så stort utbytte av vår modul, men modulen vil bli implementert
i operativsystemet. Det finnes i dag ikke mange systemer som på så enkel måte
takler masseinnlegging av brukere i et operativsystem. Dette kan gi Skolelinux et
forsprang i forhold til andre operativsystemer, når skoler skal velge i
markedet. Organisasjonen vil ikke ha direkte inntekter på vår modul da hele
Skolelinux bygger på et idealistisk grunnlag der alt skal være gratis.
5.3 Vurdering av utviklingsmetode
5.3.1 Vurdering av RUP
RUP er et omfattende prosesstyringsverktøy, og har vært
rammeverket i prosjektet. RUP er kort sagt en metode for å utvikle systemer. At
vi har benyttet oss av RUP har hatt flere fordeler. Det ble diskutert hvordan vi
kunne nå prosjektmålet med hensyn til tid og kunnskaper. Vi delte oppgaven inn
i mindre og mer passende enheter. Dette har etter vårt syn resultert i ett
meget solid produkt. Ved å dele opp utviklingen av systemet inn i mindre
selvstendige enheter, kunne vi på en kontrollert måte nå våre delmål. Dette gjorde at vi ikke mistet den helhetlige
oversikten.
Den største fordelen med RUP var å arbeide iterativt. Ved å
bruke iterasjoner fikk vi bedre oversikt over ulike problemstillinger tidlig i
prosessen. Feilene ble enkle å rette opp siden de ble oppdaget tidlig i
utviklingen og ikke mot slutten.
Problemer som ofte oppstår når en gruppe velger å iterere,
er at krav til systemet ikke alltid er statiske. Andre faktorer som spiller
inn:
Brukerne endrer seg
Problemet endrer seg
Teknologien endrer seg
Markedet endrer seg
5.4 Vurdering av teknikker og verktøy
5.4.1 UML
Innen utviklingen av diagrammer har vi funnet UML svært viktig, fordi det gjør kommunikasjonen god og prosessen blir oversiktlig. Business use case ble først utviklet. Det viser i hvilken sammenheng systemet virker. I vårt tilfelle viser det vårt system i sammenheng med Skolelinux. På designnivå var det use case sammen med deres beskrivelser som først ble utviklet. Først på et overordnet nivå, for så å detaljere disse ytterligere. Disse hjalp til med å skape en forståelse av hvordan systemet skulle utvikles og fungere. Klassediagrammet er også et svært viktig diagram i forhold til utviklingen av systemet. Gruppen har jobbet mye med klassediagrammet.
Alle diagrammene gruppen har utviklet, har vært til hjelp for at programmererne skulle kunne utføre sine oppgaver. De har hatt et grunnlag for å forstå hvordan systemet er tenkt og ønsket.
5.4.2 Grupperegler
Gruppereglene vi satt opp i starten av prosjektet har fungert bra. Det er likevel ofte behov for justering etter hvert som problemene oppstår. Det er ikke alltid så lett å forutsi gruppens svakheter ved prosjektstart. Det er også svært viktig at gruppen har respekt for de reglene som blir satt.
5.4.3 Risikoliste
Risikoliste er et godt hjelpemiddel for prosjekter. Arbeidsoppgaver blir omdelegert ved fravær eller ikke tilfredsstillende arbeidsinnsats av gruppemedlemmer. Andre tiltak blir gjeldende ved andre problemer. Risikolisten har vært nyttig og tidsparende, og den har gjort løsning av problemer i gruppen mye enklere.
5.4.4 Prosjektplan
Prosjektplanen har fungert som nyttig styringsverktøy i prosessen til vår gruppe. Planen har vi hatt stor bruk for da prosjektet strekker seg over så lang tid. Det ville blitt vanskelig å holde oversikten over hvor langt vi hadde kommet dersom vi ikke hadde satt opp en overordnet plan. Ut ifra dette var det forholdsvis enkelt og sette opp en mer detaljert plan for hver iterasjon i prosjektet.
5.4.5 Iterasjonsmål/statusrapport
I dette prosjektet har vi satt opp iterasjonsmål for hver iterasjon. Det har vært til god hjelp ved at vi til en hver tid visste hva som skulle bli gjort i iterasjonen. Ved at det ble skrevet en statusrapport etter hver iterasjon, har vi lett kunnet se hva som ble ferdig og hva som ikke ble ferdig. Hvis noe ikke ble ferdig innen tidrammen, måtte vi forskyve noen oppgaver. Disse dokumentene skaper god oversikt i hver iterasjon i prosjektperioden.
5.4.6 Behovsanalyse
På grunn av at systemet vi utviklet i hovedsak skal brukes
av IKT-ansvarlige på skoler, var det viktig for oss å få vite hva de syntes
skulle med i systemet. Derfor ble denne analyse utført svært tidlig i
prosessen. Dette har hjulpet oss til å se litt nærmere hva som må med i et
brukeradministrasjonssystem, og det hjalp oss til å sette noen avgrensinger for
systemet.
5.4.7 Systemutviklingsverktøy
Bruken av Microsoft Visio har fungert tilfredsstillende i utviklingen av vårt system. Grunnen til at vi har benyttet Microsoft Visio til modelleringen av modeller er at utvikleren har stor frihet til å gjøre egne valg i modelleringen. Vi valgte å bruke Visio framfor et Linux basert verktøy fordi vi har tidligere lært hvordan vi skal bruke Visio, og ønsket ikke å prioritere å bruke mye tid på å sette oss inn i et nytt Linux basert verktøy.
5.4.8 Andre verktøy
Grunnen til at vi har valgt å utvikle rapporten i et Microsoft miljø er at NITH krever at rapporten leveres i Microsoft Word. Videre synes gruppen at det er litt enklere å bruke enn OpenOffice. Sannsynligvis har dette med hva vi er mest vant til fra tidligere.
5.4.9 Prototyper
Prototypene har vært til hjelp når vi for eksempel skulle vise brukerne hva vi tenkte om systemet. Det har også vært til hjelp i forhold til kommunikasjonen mellom systemutviklerne og programmererne. Det hjalp oss til å luke ut svakheter, mangler og feil i systemet.
5.4.10 Programmering
Vi har tidligere ikke fått noen innføring i programmeringsspråkene vi måtte utvikle systemet innen, så det har vært noe jobb å sette seg inn i språkene. Grunnen til at programmeringsspråket Perl, og dens scripting i CGI, ble valgt, var på grunn av at Skolelinux krevde det, og at brukeradministrasjonssystemet allerede er programmert i disse språkene.
5.4.11 Versjonshåndtering
CVS har vært til god hjelp for å holde orden på alle dokumentene og diagrammene som vi utviklet. Det har gjort at alt vi utviklet til en hver tid har vært tilgjengelig for oss hvor som helst.
5.4.12 Tidslogg
Tidsloggen har vært nyttig for å dokumentere hvert enkelt gruppemedlems arbeid. Det har gjort at samholdet i gruppen har blitt bedre, fordi dokumentasjon på tidsbruk viser at alle gruppemedlemmene gjorde en innsats.
5.5 Vurdering av utviklingsprosessen
Vi har hatt stor nytte av faseplanen og iterasjonsplanene. Vi har fulgt planene og har for det meste klart å bli ferdige med gjøremålene innen den fastsatte tiden, med et par unntak.
Vi hadde leveranse til oppdragsgiver etter hver iterasjon.
Det var et par ganger vi ikke har klart å levere innen fristen, noe som betyr
at vi ikke har klart å følge prosjektplanen helt slavisk. Grunnen var at det
til tider var litt for høye ambisjoner satt opp i iterasjonsplanene.
Tidsfristene på noen av gjøremålene har vært for korte. Vi begynte på dette
prosjektet to uker etter ordinær tid. Dette skyldes at skolen var usikker på om
vår gruppe skulle ha forankring på diplom- eller ingeniørstudiet. Gruppen
brukte mye tid på å sette arbeidsplassen vår i stand. Vi måtte ordne med møbler
til lokalet, hardware for å bygge et Skolelinux nettverk og andre lignende
problemer. Prosjektperioden har til tider vært svært hektisk. Vi har stadig
opplevd at serveren har fått problemer. Det har medført mange timer på å
formatere og legge inn operativsystemet på nytt. Heldigvis har vi tatt høyde
for slike problemer i risikolisten. Denne listen har vært til god hjelp. Vi har
kunnet gardert oss, for å nå prosjektmålene som vi har satt oss.
6. Konklusjon
Gruppen har i vårsemesteret 2003, gjennomført hovedprosjektet i faget PJ500/IPJ200.
Vi valgte Skolelinux fordi det er en idealistisk organisasjon, som fremmer bruken av gratis programvare. Oppgave gikk ut på å forbedre det mangelfulle brukergrensesnittet i brukeradministrasjonssystemet til Skolelinux.
Gjennom kontinuerlig arbeid fordelt på fem faser med fire iterasjoner, har vi oppnådd de målene som var planlagt i prosjektplanen. Vi har benyttet RUP og UML til gjennomføringen og har fått mer erfaring i bruken av disse. Vi har også benyttet Skolelinux og fått kjennskap til de programmene som ligger her. Systemet skulle utvikles i programmeringsspråket PERL, og vi måtte derfor lære dette.
Gjennom prosessen har det stadig kommet nye ønsker og krav til hva vi skulle utvikle. Noen av disse kom så sent i prosessen at modelleringen var ferdig utviklet. Vi hadde kommet så langt i programmeringen at det ville være lite hensiktsmessig å stoppe opp for å lage nye modeller. Derfor har vi ikke rukket å oppdatere alle modeller for samtlige deler av systemet.
Prosjektet har gjort at vi har fått en større forståelse av sammenhengen mellom prosjektstyring, systemutvikling og programmering. Vi har erfart at godt samarbeid og god kommunikasjon mellom de ulike rollene har avgjørende betydning for utfallet av prosjektet.
Gruppen har gjennomført samtlige mål vi hadde for prosjektet, og er godt fornøyd med gjennomføringen og resultatet. Produktet vi har utviklet synes vi gjenspeiler visjonen vi satte oss da vi startet prosjektarbeidet, som var å lage et brukervennlig og unikt brukergrensesnitt for brukeradministrasjonssystemet. Vi synes sluttproduktet er et godt og vel gjennomtenkt produkt, noe også kunden har gitt tilbakemeldinger om.
Referanseliste
Andersen E. S. & Schwencke E. 2000. Prosjektarbeid - En
veiledning for studenter. Norway: NKI
Berntzen Lasse. 2001. Utvikling av avanserte Internett-baserte applikasjoner. Bekkestua
Christiansen T. & Torkington N. 1998. Perl Cookbook.
Danesh A.1999. Mastering Linux.
Dysthe O. Hertzberg F. & Hoel T.L. 2000. Skrive
for å lære. Norway: Abstrakt Forlag
Fowler M. & Scott K. 2000. UML Distilled, second edition - A brief guide to the standard Object
Modelling Language.
Harlan D. Powers S. Doyle P. & Ó
Fóghlú M. 1996. Perl 5 for Web Programming.
Hekman J.P. 1997. Linux in a Nutshell.
Kruchten P. 2000. The
Rational Unified Process An Introduction Second
Edition.
Larman, Craig. 2001.
Applying UML
and patterns.
Rognsaa Aa. 2000. Prosjektoppgaven
- Krav til utforming.
Siever E. Spainhour S.
& Patwardhan N. 1999. Perl in a Nutshell.
Walsh N. & Muellner
L. 1999. DocBook, The Definitive Guide.