webbaserad kommunikationsplattform · 2008. 6. 12. · det finns vissa problem som kan uppstå med...

Webbaserad kommunikationsplattform

Henrik Ekblom & Mikael Wågberg

Mars 2008 Examensarbete, 30hp

Handledare på CS‐UmU: Lena Palmquist Examinator: Per Lindström

UMEÅ UNIVERSITET INSTUTITIONEN FÖR DATAVETENSKAP

90187 UMEÅ

Webbaserad kommunikationsplattform 2

Sammanfattning En webbaserad kommunikationsplattform har utvecklats. Plattformens huvuduppgift är

att hantera kommunikationen mellan studenter och lärare. Utvecklingsarbetet har

fokuserats på att ta fram ett system som ska kunna expanderas, som erbjuder förbättrad

säkerhet, användbarhet och effektivitet. En användarstudie med en webbaserad enkät

och diskussioner med användare av det gamla systemet användes för att fastställa vad

som var problemen med det gamla systemet. Implementationen av databasen och

säkerheten för systemet lades som en grund för att nå de uppsatta målen. En relativt

enkelt grafiskt gränssnitt implementerades för testning av funktioner men ett

designkoncept föreslogs för fortsatt utveckling av gränssnittet.


Abstract

A communication platform for the web

A web based platform for communication has been developed. The main task for the

platform is to handle the communication between students and their teachers. The

development has been focusing on building a system that is expandable, offer improved

security, usability and efficiency. A user study including an online survey and discussions

with users of the old system was used to determine what the problems with the old

system were. The implementation of the database and a security approach for the

system was laid as a foundation to achieve the goals set up at the start. A relatively

simple graphical user interface was also implemented for testing purposes but a design

approach was suggested on how to continue the development of the GUI.


Tack till

Lena Palmquist, Lars Norlin, Anders Marklund, Jon Persson, Jan‐Erik Moström, Marie

Folkesson‐Karling och Apberget.se för all hjälp under arbetets gång.

Ett speciellt tack till Marcus ”Spike” Norlund!


Innehållsförteckning

1. Inledning ......................................................................................................................... 10

1.1 Bakgrund .................................................................................................................. 10

2. Problembeskrivning ........................................................................................................ 12

2.1 Mål ............................................................................................................................ 13

3. Förundersökning ............................................................................................................ 15

3.1 Enkätundersökning ................................................................................................... 15

3.1.1 Tillvägagångssätt ............................................................................................... 15

3.1.2 Målgrupp ........................................................................................................... 16

3.1.3 Resultat .............................................................................................................. 17

3.1.4 Felkällor ............................................................................................................. 17

3.2 Kreativa möten ......................................................................................................... 18

3.3 Referenssystem ........................................................................................................ 18

4. Gamla systemet .............................................................................................................. 20

4.1 Övergripande beskrivning ........................................................................................ 20

4.2 Tekniken ................................................................................................................... 20

4.2.1 Databas .............................................................................................................. 21

4.2.2 Användargränssnitt ........................................................................................... 21

4.3 Gränssnitt ................................................................................................................. 21

4.3.1 Inloggningen ...................................................................................................... 22

4.3.2 Huvudsida .......................................................................................................... 23

4.3.3 Kurssidor ............................................................................................................ 24

4.3.4 Meddelanden .................................................................................................... 25


4.3.5 Redigering av kurser .......................................................................................... 26

4.3.6 Frånvaro ............................................................................................................ 27

4.3.7 Portfolio ............................................................................................................. 28

4.4 Administration .......................................................................................................... 28

5. Det nya systemet ............................................................................................................ 30

5.1 Introduktion ............................................................................................................. 30

5.2 Målgrupper ............................................................................................................... 30

5.3 Gränssnitt ................................................................................................................. 32

5.3.1 Skisser ................................................................................................................ 32

5.3.2 Prototyp ............................................................................................................. 35

5.4 Teknik ....................................................................................................................... 39

5.4.1 Windows Small Business Server 2003/IIS6 ........................................................ 39

5.4.2 ASP.Net 3.5 ........................................................................................................ 40

5.4.3 Ajax .................................................................................................................... 40

5.4.4 Databas .............................................................................................................. 41

5.5 Säkerhet.................................................................................................................... 43

5.5.1 Forms Authentication ........................................................................................ 44

5.5.2 Roller ................................................................................................................. 44

5.5.3 SSL ..................................................................................................................... 45

5.5.4 Kontroll av indata .............................................................................................. 47

6. Diskussion ....................................................................................................................... 49

Referenser .......................................................................................................................... 52

Bilagor ................................................................................................................................ 55


Bilaga 1 ........................................................................................................................... 56

Enkät ........................................................................................................................... 56

Bilaga 2 ........................................................................................................................... 60

Enkätresultat .............................................................................................................. 60

Bilaga 3 ........................................................................................................................... 64

Prioritetslista – funktioner ......................................................................................... 64

Prioritering 1 ‐ Basfunktioner ..................................................................................... 64

Prioritering 2 – Underlätta större arbeten ................................................................. 65

Prioritering 3 – Underlätta mindre arbeten ............................................................... 65

Prioritering 4 – Visioner .............................................................................................. 65

Bilaga 4 ........................................................................................................................... 66

Serverspecifikation ..................................................................................................... 66


Figurförteckning

Figur 1 ‐ Första frågan på enkätundersökningen ............................................................... 16

Figur 2 ‐ Första steget av inloggningen .............................................................................. 22

Figur 3 ‐ Andra steget av inloggningen ............................................................................... 22

Figur 4 ‐ Första sidan efter inloggning för lärare ................................................................ 23

Figur 5 ‐ Huvudsidan inne i "Klassrummet" ........................................................................ 24

Figur 6 ‐ Information om specifik kurs för lärare ................................................................ 25

Figur 7 ‐ Meddelanden – Inkorg ......................................................................................... 25

Figur 8 ‐ Meddelande ‐ Läs meddelande / Svara ............................................................... 26

Figur 9 ‐ Sida för redigering av kurser ................................................................................ 27

Figur 10 ‐ Vy över frånvarosammanställning för elever ..................................................... 27

Figur 11 ‐ Eleverna laddar upp sina svar på inlämningsuppgifter ...................................... 28

Figur 12 ‐ Tidigt skiss av generell design ............................................................................ 33

Figur 13 ‐ Skiss ett moment senare .................................................................................... 34

Figur 14 ‐ Skiss från nästa moment, grund gjord i Flash med anteckningar om vidare

förändringar. ...................................................................................................................... 35

Figur 15 ‐ Generellt prototypförslag för elevanvändare. ................................................... 36

Figur 16 – Administratorvy med listning av personer med allergier .................................. 37

Figur 17 ‐ Låst arbetsyta ..................................................................................................... 38

Figur 18 ‐ ER‐schema över hela databasen ........................................................................ 42

Figur 19 ‐ Detaljbeskrivning av databasen ......................................................................... 43


1. Inledning

Detta projekt bestod i att skapa en ny plattform för ThorenGruppen och Thoren Business

School för den interna kommunikationen, främst mellan lärare och elever.

ThorenGruppen har ett system vid namn Progress (se avsnittet ”Gamla systemet”) som

från början var tänkt som kommunikationsplattform, men systemet har visat sig passa

dåligt för den gymnasieverksamhet som ThorenGruppen har utökat till idag. Det gamla

systemet har vart svåranvänt, haft dålig prestanda samt att administrationen har varit

besvärlig och tidskrävande.

Progress skapades 2001 och blev en plattform för all kommunikation mellan elever och

lärare på de distansutbildningar som bedrevs i företaget. Huvudsyftet för systemet var

att ge lärarna möjligheten att skicka ut uppgifter till eleverna som eleverna i sin tur kunde

genomföra och därefter skicka tillbaka till läraren. Funktioner för att hålla reda på elevers

närvaro och studieresultat har också varit en viktig del i systemet.

1.1 Bakgrund

ThorenGruppen AB är ett av Sveriges snabbast växande utbildningsföretag och

tillhandahåller olika slags utbildningar som gymnasieutbildningar, komvuxutbildningar,

företagsutbildningar, m.m. Utbildningarna genomförs till stor del på distans, men även

lokalt. ThorenGruppen driver dessutom en gymnasieskola kallad Thoren Business School

(TBS) som i dagsläget finns i fyra städer i Sverige.


2. Problembeskrivning

ThorenGruppen har bestämt sig för att göra en uppdatering av Progress för att få ett

system som känns mer modernt och samtidigt är mer anpassat efter dess nuvarande

användningsområde. När Progress skapades var det i första hand tänkt för att användas

för distansutbildningar, men eftersom det nu används av både gymnasieelever och

företagskunder har det visat sig att systemet inte riktigt är anpassat för detta.

Det nuvarande systemet startade som ett litet system och därefter har nya funktioner

plåstrats på utan att ha en grundstruktur som klarar av expansion. Progress börjar enligt

ThorenGruppen nå sin gräns i hur många fler användare som kan läggas till samt hur

många nya funktioner som kan implementeras.

Det finns vissa problem som kan uppstå med användandet av en digital version för

kommunikation mellan lärare och elever i jämförelse med att ha

direktkommunikationen, människa till människa (Barab, Kling, & Gray, 2003). I den

digitala versionen läggs begränsningar in i vad elever kan skriva vilket är positivt ur vissa

perspektiv, t.ex. då administratören för systemet kan ta bort diskussioner och inlägg som

på något sätt är opassande för skolans regler. Nackdelen kan vara att vissa diskussioner

kan behöva göras direkt mellan två personer, t.ex. då en kurator pratar med en elev om

något problem. Progress och det nya systemet är dock inte den enda kommunikationen

mellan lärare och elev, den direkta kommunikationen finns kvar i skolan under vanliga

lektioner och raster etc. Plattformen är istället ett komplement till den konventionella

undervisningen och finns för att förenkla det administrativa arbetet.


2.1 Mål

Specifikationerna för arbetet har skapats under förstudien till projektet, men innan

arbetet påbörjades fanns det grundläggande mål som skulle uppnås.

• Att skapa en användarvänlig kommunikationsplattform

o Lättnavigerad med en intuitiv design

o Effektivisera arbetet i systemet

o Effektivisera administrationen av systemet

o Bättre feedback till användarna

o Roligare användning

• Förbättra säkerheten

o Kryptering av kommunikation

o Kryptering av data (lösenord m.m.)

o Bättre kontroll av skadlig indata i formulär

Målet med arbetet är att skapa en grund till ett nytt system som i sin tur skall leda fram

till en fullt fungerande plattform vilken hösten 2008 ska ersätta det gamla systemet.


3. Förundersökning

För att få en grund till systemet behövdes en prioriteringslista på de funktioner som var

viktigast att implementera initialt. För att skapa denna prioritering genomfördes möten

med ledningen på ThorenGruppen där deras önskemål fördes fram samt en

enkätundersökning som användarna av det gamla systemet fick genomföra.

Enkätundersökningen (se ”3.1 Enkätundersökning”) som genomfördes hade till syfte att

få fram önskemål hos det nya systemet samt åsikter om det gamla systemet. Resultatet

från enkätundersökningen framfördes vid mötena med ledningen för att få fram en

prioritering som kunde stå för både ledningen och användarna.

3.1 Enkätundersökning

Syftet med förundersökningen var att få en uppfattning om hur det gamla systemet

fungerade och vad användarna tyckte om det, samt att få fram användarnas önskemål av

funktioner till det nya systemet.

3.1.1 Tillvägagångssätt

Enkäten genomfördes som en webbenkät (se Figur 1). Frågorna och svaren fanns

upplagda på en hemsida där respondenten kunde fylla i textrutor (där fritext användes

som svarsalternativ) samt fylla i ett av flera färdiggjorda svarsalternativ (t.ex. där

användaren ombads gradera från 1‐6 ett förslag till en ny funktion) i en s.k.

radioknapplista1. Tillvägagångssättet med internet som medium valdes för att

insamlingen av data skulle snabbas upp samt förenklas (Dahlström, 2005). Detta var

nödvändigt då detta projekt hade ett relativt litet tidsspann. De data som samlades in

1 En lista med knappar (se Figur 1) där användaren av en webbsida kan trycka in en av flera knappar för att välja ett alternativ (Microsoft ASP.NET Team, 2007)


lagrades i en databas och ett gränssnitt togs fram för att lista alla svaren samt sortera

dessa utifrån olika kriterier.

Respondenterna fick veta varför de var utvalda att svara på detta undersökningsformulär

då det är viktigt att förklara detta (Dahlström, 2005). Målgruppen var dagens användare

av Progress där det stora flertalet kommet att använda det nya systemet, således var det

aktuellt att fråga denna grupp. Dahlström menar vidare att enkäter uppdelade på flera

sidor bör ha en indikator på var i enkäten man befinner sig. Respondenten kan annars

avbryta enkäten i förtid. En annan fördel med att ha frågorna uppdelade på flera sidor är

att de redan ifyllda svaren sparas undan i databasen om något fel skulle uppstå. Enkäten

som genomfördes var uppdelad på flera sidor baserat på ovanstående fördelar men även

för att hålla ned storleken på enkätsidan.

Figur 1 ‐ Första frågan på enkätundersökningen

3.1.2 Målgrupp

Enkätens målgrupp var de användare som använde det gamla Progress, dessa användare

kategoriserades i fyra olika grupper: lärare, gymnasieelever, distanselever och övriga.

Dessa kategorier skiljdes åt genom att skicka ut olika länkar till enkäten där länken

innehöll information om vilken kategori den svarande tillhörde.


3.1.3 Resultat

Resultatet av enkäten sammanställdes i en PowerPoint‐presentation (se Bilaga 2 ) som

användes som underlag vid den intervju/diskussion (se ”3.2 Kreativa möten”) vi hade

med ThorenGruppens ledning. Svaren sammanfattade den generella syn användarna

hade på det nuvarande systemet samt deras åsikter om framtida funktioner till det

kommande systemet. Några av resultaten var:

• Användarna använde Progress frekvent, största delen flera gånger per dag.

• Chattfunktion i det kommande systemet var önskvärt.

• Bloggfunktion hade jämt utspridda svar på skalan 1‐6 för önskvärdhet.

• Kalenderfunktion i det kommande systemet var mycket önskvärt.

• Gästbok i det kommande systemet var önskvärt.

Vidare sade enkäten att användarna upplevde Progress för komplicerat att använda samt

erbjöd dålig användbarhet ur grafisk synpunkt samt funktionalitetsmässigt.

Resultatet av enkäten sammanställdes på en generell nivå utan att gå in på detaljer om

vad de olika grupperna hade svarat. Enkäten skulle ge ett underlag för ett kreativt möte

(se ”3.2 Kreativa möten” nedan) med ThorenGruppens ledning samt lärare. Detta

underlag skulle generera den slutgiltiga prioritetslistan för det kommande systemet.

3.1.4 Felkällor

Trots försök att eliminera felkällor av olika slag under enkätundersökningen finns det

alltid risk för felaktigheter i svaren. Några av dessa är:

• Lärare kan ha fyllt i enkät som var menad för elever. Lärarna fick ett separat

utskick med en internetlänk till deras enkät men såg även elevernas internetlänk

(på den allmänna nyhetsplatsen i det gamla systemet Progress).

• Utskicket skedde via Progress vilket gjorde att de som inte använde Progress

under den period enkäten var ute kan ha missat att fylla i den.


3.2 Kreativa möten

Efter det att enkätundersökningen genomförts hölls möten med ledningen på

ThorenGruppen samt med ett par lärare på Thoren Business School. Dessa intervjuer

genomfördes för att få fram ledningens specifika önskemål samt för att få en mer

detaljerad översikt över de problem som det gamla systemet hade. Genom att föra fram

enkätsvaren under dessa kreativa möten kunde ledningen få inblick i hur användarna

upplevt det gamla systemet, samt vilka förslag till förbättringar som fanns. Dessa möten

ledde i sin tur fram till en idé över hur det nya systemet skulle se ut och en prioritering

över funktioner kunde tas fram (se bilaga 4).

Ett av ledningens krav var att systemet måste vara framtidssäkert och ha utrymme för

expansion när nya skolor startas och många nya användare skall läggas till. Det gamla

systemet saknade även ett effektivt användargränssnitt för att ändra/skapa stora

mängder data (exempelvis lägga till frånvaro för flera elever samtidigt), vilket också var

ett krav på det nya systemet. Utöver detta fanns kravet på förbättrad säkerhet. Lärarnas

önskemål skiljde sig en del från ledningens då det mer inriktades mot användbarhet, där

användbarhetsförbättringar var prioriterat.

3.3 Referenssystem

Det gamla systemet (Se avsnitt 4) kunde användas som referens då dess grundfunktioner

var likartade som funktionerna i det nya. Önskemålen ovan vägdes mot den tid som

fanns utsatt för projektet och en prioriteringslista kunde skapas vilken var grunden för

den fortsatta utvecklingen av Progress.

Att undersöka konkurrerande system var även det en bra informationskanal då de var

liknande system som redan var i drift och således kunde ses som fungerande referenser.

Eftersom tanken med att digitalisera lärandet inte är unik för ThorenGruppen finns det

även andra företag som utvecklat motsvarande plattformar för detta. Genom att titta på

liknande system och undersöka vilka lösningar de har valt att använda sig av har många

idéer uppkommit till utvecklingen av detta system.


4. Gamla systemet

4.1 Övergripande beskrivning

ThorenGruppens nuvarande system är en kommunikationsplattform som heter Progress.

Dess uppgift är att hantera kommunikationen mellan elever och lärare. Via Progress får

lärarna möjlighet att lägga ut kursmaterial och annan information rörande utbildningen.

Eleverna kan då ta del av den informationen och därefter utföra eventuella uppgifter.

Samma system hanterar också inlämningar av uppgifter, dvs. eleverna får tillgång till sina

uppgifter via Progress, utför dessa och lämnar därefter in dem via plattformen. Lärarna

kan då ladda ner elevernas inlämnade uppgifter och genomföra rättningen.

Systemet har utöver detta funktioner för att:

• Lärarna ska ha möjlighet att skicka ut inlämningsuppgifter till eleverna

• Användarna ska kunna skicka meddelanden till andra användare.

• Lärarna ska kunna registrera närvaro för kursdeltagare.

• Användarna ska kunna se överblicksbilder över kursers aktiviteter.

• Målsmännen till eleverna ska ha möjlighet att logga in och se elevens närvaro.

• Lärarna ska kunna lägga upp diagnostiska tester som kursdeltagarna genomför

direkt på plattformen.

• Användarna ska kunna diskutera kurserna via ett forum.

4.2 Tekniken

Det gamla systemet utvecklades under 2001 och är baserat på ASP med en

Accessdatabas som grund. Systemet är anpassat efter Internet Explorer och saknar i viss

mån stöd för andra webbläsare. Många av bristerna som systemet har beror just på de

tekniska aspekterna eftersom det använder sig av gammal teknik.


4.2.1 Databas

Den Microsoft Accessdatabas som används fungerade tillfredsställande för denna mindre

applikation då det inte var många samtidiga SQL‐anrop. Access är en databashanterare

som är utvecklad för att hantera mindre applikationer med ett begränsat antal anrop.

När användarskaran växte då Thoren Business School startade nya skolor runt om i

Sverige fick databasen problem med att hantera alla samtidiga anrop på en acceptabel

tid. Ett exempel på ett problem som kunde uppstå var att en elev laddade upp en stor fil

till systemet från en dator som är uppkopplad via modem, vilket medförde att databasen

låstes upp för skrivning så länge filen laddades upp. Detta var inte ett stort problem men

har med tidens gång och en ökande användargrupp lett till att fler upplever systemet

som långsamt. Att få responstider av ett datasystem som ligger på flera sekunder får

enligt Schneiderman användare att uppleva systemet som långsamt (Shneiderman, 1984,

s. 267).

4.2.2 Användargränssnitt

Programmeringsspråket som användes för att vara gränssnittet mellan användaren och

databasen var ASP – Active Server Pages (Microsoft, 2007). Språket är ett serverside‐

språk där koden kompileras i realtid till hemsidor som webbläsare kan läsa. Nackdelar

med denna teknik är:

• Koden kompileras i realtid vilket kan leda till längre responstider.

• ASP använder VBscript vilket medför att man ej få samma funktionalitet som

t.ex. det fullständiga Visual Basic ger.

• ASP saknar ett välutvecklat stöd för HTML‐kontroller – vilket medför att

programmeraren måste implementera mycket manuellt som det i t.ex. ASP.NET

finns färdiga klasser för: valideringskontroller, inloggningssystem (se ”5.5.1

Forms Authentication”).

4.3 Gränssnitt

Det nuvarande systemet har ett utseende som många användare upplever som plottrigt

och för färgglatt (se bilaga 1 för enkätsvaren). Mappningen och färgsättningen av länkar

och knappar är ej genomtänkt, det finns ingen tydlig koppling mellan systemets

funktioner och gränssnittets utseende vilket Norman (2002) anser vara nödvändigt. Detta

i sin tur leder till att systemet är svårnavigerat och användaren känner ej tillit till

systemet.


4.3.1 Inloggningen

Det finns fem olika typer av användare: Kursdeltagare, Kunder, Utbildare, Målsmän och

Administratör. Alla typer förutom administratören kan logga in i systemet på samma sida

(se Figur 2) genom att först välja vilken användarkategori man tillhör och därefter logga

in med användarnamn och lösenord (se Figur 3). Administratören måste dock logga in via

en separat sida som ser likadan ut som den i Figur 3.

Figur 2 ‐ Första steget av inloggningen

Figur 3 ‐ Andra steget av inloggningen


4.3.2 Huvudsida

Huvudsidan ser olika ut beroende på vem som loggar in, är det en lärare som loggar in

syns en sammanställning över vilka kurser läraren har (se Figur 4). Eleverna kommer

direkt in i det som kallas ”Klassrummet” (se Figur 5), på förstasidan får eleven se den

övergripande information som är inlagd. Det kan vara information som rör hela skolan

eller en hel klass. Läraren kommer in i ”Klassrummet” vid ett senare skede (se ”Figur 6 ‐

Information om specifik kurs för lärare”).

Figur 4 ‐ Första sidan efter inloggning för lärare


Figur 5 ‐ Huvudsidan inne i "Klassrummet"

4.3.3 Kurssidor

Varje kurs som finns inlagd i systemet har en egen plats där elever kommer åt de

dokument som läraren på kursen har laddat upp (se Figur 6), denna vy är i ”det gamla

progress” och ej inne i ”Klassrummet”. Här kan även den inloggade läraren se vilka elever

som är inskrivna på kursen samt vilka lärare som har tillgång till den.

Lista över användarens tillgängliga kurser

Lista över elever Meny


Figur 6 ‐ Information om specifik kurs för lärare

4.3.4 Meddelanden

I systemet kan lärare och elever skicka meddelanden till varandra. Användarna har en

traditionell in‐/utkorg (se fig.5). För att skicka ett meddelande måste eleven först klicka

på ”Nytt Mail” och därefter vem han/hon vill skicka meddelandet till genom att klicka på

personens namn i användarlistan i mitten av sidan (Figur 7 & Figur 8).

Figur 7 ‐ Meddelanden – Inkorg

För att lärare ska komma till ”Klassrummet” måste dom klicka här för den kurs dom vill se i ”Klassrummet”

Inkorgen

Användarlista


Figur 8 ‐ Meddelande ‐ Läs meddelande / Svara

4.3.5 Redigering av kurser

Lärarna har möjligheten att gå in och redigera vilka kurser som eleverna deltar i, detta

går endast att göra elev‐för‐elev och inte för flera elever samtidigt. Det betyder att om

man vill redigera ett datum för en kursstart måste detta göras för varje elev separat (se

Figur 9) vilket kan bli väldigt tidskrävande. Denna funktion skapades på den tid på

Progress användes främst för distanselever där eleverna kunde ha olika kursstarter fast

de läste samma kurs. Vid gymnasiestudier läser eleverna en kurs under samma tidpunkt

vilket betyder att datumet för kursstarten är samma för alla elever i samma kurs.


Figur 9 ‐ Sida för redigering av kurser

4.3.6 Frånvaro

Lärarna lägger till frånvaron för varje elev separat. Elever, målsmän och lärare har

möjlighet att se en sammanställning av elevens frånvaro där endast läraren har möjlighet

att redigera frånvaron (se Figur 9)

Figur 10 ‐ Vy över frånvarosammanställning för elever


4.3.7 Portfolio

Lärarna skapar inlämningsuppgifter som eleverna ska skicka in svar på inne i systemet.

Detta gör eleverna genom att ladda upp dokumenten till en ”Portfolio” som eleven har

till varje kurs. Det finns ingen möjlighet för eleven eller läraren att se en sammanställning

över alla filer som laddats upp.

Figur 11 ‐ Eleverna laddar upp sina svar på inlämningsuppgifter

4.4 Administration

Administrationen av det gamla systemet har visat sig vara mycket tidskrävande och

kostsam för företaget. Den administration som genomförs handlar mest om att nya

kurser och utbildningar skall läggas in i systemet och därefter skall rätt elever läggas in i

rätt utbildning/klass o.s.v. Gränssnittet för det gamla systemet saknar många delar som

hade underlättat det administrativa arbetet avsevärt, som t.ex. att administrera flera

elever samtidigt, o.s.v. Administrationen har även många gånger gjorts på ett sådant sätt

att det varit lätt att göra fel vilket i sin tur har lett till logiska fel i databasen.


5. Det nya systemet

5.1 Introduktion

Efter att ha fått en bild av vilka funktioner ThorenGruppen vill att deras system skall ha

kommer det nya systemet att få en communityliknande grund med användaren i

centrum. Det centrala är kommunikationsdelen mellan lärare och elev med utskick av

uppgifter från lärare och svar på dessa uppgifter av elever. Med användaren i centrum

kan systemet erbjuda en överskådlig bild av användarens kommande aktiviteter samt

dennes meddelandeinkorg och övriga delar som är knutna till användaren. En

community‐plattform kan erbjuda denna centralisering av användaren och en utformning

så att det viktiga hamnar i fokus.

Den största fördelen med det föregående systemet är dess åtkomlighet genom att den är

webbaserad. Denna del bibehålls i det nya systemet med förnyelse av tekniken för att få

en effektivare och snabbare plattform. Det grafiska gränssnittet kommer även det att

byggas om för att göra användandet mer intuitivt, effektivisera arbetet tidsmässigt, passa

bättre in i ThorenGruppens grafiska profil samt för att ge systemet ett modernare och

pålitligare utseende.

5.2 Målgrupper

Användarna av systemet är inte en homogen grupp då de består av en mångfald av olika

användartyper vilka kan ha olika stor erfarenhet av systemet samt syfte med

användandet. Här är en lista över kategorier av användare, en estimering av deras

erfarenhet av det gamla systemet samt deras primära uppgifter i systemet:


• Elever o Gymnasieelever

Vana av gamla systemet: Förväntad relativt god då elever av systemet får bärbar dator från skolan samt förväntas sköta skolarbetet genom systemet

Huvudmål: Ta emot samt svara på skoluppgifter och meddelanden från lärare

o Vuxenutbildning/Komvux Vana av gamla systemet: Kan variera då personer i den

eftergymnasiala utbildningen kan gå enstaka eller flera kurser Huvudmål: Ta emot samt svara på skoluppgifter och

meddelanden från lärare

• Personal o Ordinarie lärare

Vana av gamla systemet: Förväntad relativt god då utskick huvuddelen av det administrativa arbetet sker i systemet

Huvudmål: Sköta det administrativa med uppgifter, närvaro samt kontakt med elever

o Vikarier lärare Vana av gamla systemet: Kan variera då vikariat kan vara

kortvarigt Huvudmål: Sköta det administrativa med uppgifter, närvaro

samt kontakt med elever o Administratörer

Vana av gamla systemet: Förväntad god då de skall administrera systemet

Huvudmål: Administrera systemet, hantera stora mängder in‐/utdata, t.ex. inmatning av alla elever på en skola/klass/o.s.v.

o Övrig personal Vana av gamla systemet: Kan variera Huvudmål: Få information om aktuell arbetsplats

• Målsmän o Vana av gamla systemet: Kan variera o Huvudmål: Få information om deras barns skolgång


5.3 Gränssnitt

Gränssnittet är den yta som ligger mellan användare och det bakomliggande systemet, i

detta fall en grafisk representation av de data som finns samt verktyg för att modifiera

dessa data. Gränssnittets uppgift är att göra tekniken transparent för användaren och

därigenom förbättra användbarheten (Wilding, 1998). Vidare skall gränssnittet förenkla

huvudmålen för användaren men har även fler uppgifter, som att förmedla en viss känsla

och att få användaren att känna sig trygg med systemet genom att använda sig av

konceptuella modeller som användaren förstår (Norman, 2002, s. 189).

Baumann och Thomas skriver om olika skalor som användarens upplevelser hamnar i

(Baumann & Thomas, 2002). Skalorna som bör tas i beaktande är:

• Uppfyller förväntningar – Besvikelse

• Intressant – Tråkigt

• Alternativt – Normal

• Följer trend – Sätter trend

Att ge användaren bättre feedback var ett av målen i projektet, dvs. användaren ska få

information från systemet när input givits. För att åstadkomma detta finns många olika

tekniker tillgängliga. Det nya systemet kommer att ge feedback till användaren på olika

sätt bl.a.:

• Laddningsindikatorer o När systemet processar data.

• Dialogrutor o För att göra användaren uppmärksam på viktiga moment. T.ex. att man har en

dialogruta som frågar administratörsanvändaren en extra gång innan

administratörer tar bort ett betyg för en elev.

• Bekräftelser på moment o För att visa användaren att systemet mottagit input. T.ex. att man skriver ut

”Meddelandet skickat!” när användaren skickat iväg ett meddelande.

5.3.1 Skisser

Till en början användes brainstorming som metod för att få ut skisser till den design som

skulle representera ovanstående idéer och mål. Layouter togs fram med penna och

papper (se Figur 12) och ett första utkast lades in Macromedia Flash för att få en

helhetsbild (se


Figur 13). Flash erbjuder ett snabbt sätt att få ut ett utkast på design samt enklare

funktioner.

Figur 12 ‐ Tidigt skiss av generell design


Figur 13 ‐ Skiss ett moment senare

Nästa steg var att skapa de grafiska elementen i Adobe Illustrator, vilket är det program

som användes för att göra de slutgiltiga bilddetaljerna (se Figur 14).


Figur 14 ‐ Skiss från nästa moment, grund gjord i Flash med anteckningar om vidare förändringar.

5.3.2 Prototyp

De skisser som togs fram gav en grogrund för att få en grafisk generell prototyp över

systemet samt mer specifika mallar som sattes in i olika scenarion.

Utifrån målgruppernas förväntade vana av att använda systemet och mål som satts upp

bör således designen inte vara statisk utan bör anpassas för avsedd användare. De med

liten datorvana bör erbjudas en enkel design där huvudinformationen lätt

uppmärksammas. Vidare kan de med mer datorvana erbjudas ett mer komplext

gränssnitt för att förenkla in‐/utmatning av större mängder data. En administratör skall

t.ex. kunna lista alla eleverna i en skola som tillhör en viss klass och har busskort, något

som målsmän inte behöver. Att göra funktioner och grafik lättförståeliga med god

mappning där det inte inkräktar på funktionaliteten är dock att föredra (Norman, 2002, s.

191) Detta används på de gemensamma ytor som alla användare kommer att se. Ett

exempel

är den del där utloggningen sker. Den bör ha en text som beskriver handlingen ”logga ut”

samt ha en gängse använd ikon i typ av ett hänglås som låses upp eller en pil som pekar

ut genom en dörr vilket illustrerar att användaren loggar ut ur systemet.

Standardisering får användaren att referera till vardagliga händelser (lämnar en plats – pil

ut genom dörr) samt referera till liknande situationer i andra digitala system (t.ex. logga

ut från Hotmail). Detta fungerar när inget annat fungerar men även som en god grund i

design (Norman, 2002, s. 200).

Vissa generella mål för designen sattes upp för att ha en grund att arbeta från. Systemet

skulle utformas på ett sätt användarna upplevde som intressant för att uppmana till

användning, generellt följa en standard för att inte avskräcka ovana användare, anses

som stabilt för att få användarens tillit samt följa en grafisk trend som använder element

från Webb 2.02 för att upplevas som nytt samt erbjuda en öppen och luftig design.

2 Ett uttryck som myntades av mjukvaruutvecklaren Tim O’Reilly under O’Reilly Media Web 2.0 conference, 2004. Web 2.0 innefattar främst idéer om programmering av hemsidor men även grafiska element.


Med detta i åtanke sattes följande designprototyper ihop:

Figur 15 ‐ Generellt prototypförslag för elevanvändare.

"Inprogress" var systemets arbetsnamn under utvecklingen. Testlogotypens och användarbildens spegling i underlaget samt glansen i ikonen (se Figur 15) är grafiska element från Webb 2.0.

Ikon Testlogotyp Användarbild


Figur 16 – Administratorvy med listning av personer med allergier

En viktig uppgift för administratorn och övrig personal i systemet var att kunna lista

många objekt beroende på olika egenskaper. Figur 16 visar ett förenklat scenario då en

administratör har listat personer med allergier av olika slag. Sådana listningar skall även

vara lätta att skriva ut för att kunna få ett papper med denna information, t.ex. inför en

resa med en klass. Listorna i systemet kommer att vara exporterbara till Microsoft Excel‐

dokument, vilket kan förenkla hantering om någon extern källa vill ha denna lista, t.ex.

den camping som klassen skall resa till.

På samma sätt skall data enkelt kunna läggas in i systemet. Användaren skall kunna mata

in data på flera poster samtidigt, t.ex. mata in personerna i en hel klass på en enda sida,

föra in frånvaro för en klass på en enda sida etc. Detta har varit ett problem i det förra

systemet Progress, då data matades in för en person i taget på separata sidor.

Länk för att låsa systemet


Figur 17 ‐ Låst arbetsyta

En funktion som byggts in i systemet öppnas genom den länk som heter ”Lås” (se Figur

16). När systemet är låst (se Figur 17) måste användaren mata in sitt lösenord för att

kunna fortsätta arbeta. Denna skärm kommer även upp automatiskt efter 20 minuter.

Detta för att obehöriga inte skall komma åt systemet om användaren glömt att logga ut

när denne lämnar datorn. Beroende på inställningar i systemet kan bakgrunden till

låsningen vara delvis transparent (se Figur 17) men kan även göras heltäckande så att

bakomvarande element inte syns. Detta kan vara användbart om användaren arbetar

med konfidentiell information något som exempelvis skolkuratorn kan ha behov av.

Delvis transparent bakgrund till låsningen


5.4 Teknik

Det nya systemet bygger på två huvuddelar, ASP.Net 3.5 samt databashanteraren MySql

5.0. Systemet är en webbaserad databasdriven lösning som kommer att vara tillgänglig

för alla användare via internet. Det kommer att köras på en helt egen webbserver som

ThorenGruppen tillhandahåller och håller i drift.

5.4.1 Windows Small Business Server 2003/IIS6

Systemets server är av märket Dell och införskaffades efter förundersökningen var gjord.

Nedan följer en kortfattad specifikation av servern (se bilaga 2 & 3 för fullständig

specifikation):

• Intel 2.4GHz quad‐core

o Processorbelastningen är inte så stor på en webbapplikation som är

effektivt kodad och skall handha max 5000 användare.

• 4Gb ramminne

o Ramminnet används för att cacha data från databasen, vilket kan

snabba upp datahämtning avsevärt.

• Två RAID 1‐speglade hårddiskar, 500Gb st.

o Användarna kommer generellt inte att ha behov av lagring av filer

större än några megabyte per styck. Extra utrymme har reserverats för

framtida hopslagning med företagets intranät då större filer kan

komma att lagras, bl.a. filmer. Raid 1 speglar informationen likadant på

de båda hårddiskarna vilket medför snabbare läsning samt extra

säkerhet . Om en av hårddiskarna skulle gå sönder finns informationen

även lagrad på den andra.


5.4.2 ASP.Net 3.5

ASP.Net 3.5 är utvecklad av Microsoft och är en vidareutveckling av deras ASP3‐teknik.

Plattformen har flera positiva sidor, vilket ledde till att den blev stommen i systemet,

dessa fördelar är bl.a. (Microsoft ASP.NET Team, 2007):

• Antal rader kod för att göra komplicerade system kan hållas nere tack vare

inbyggda delar, bl.a. ”Validation Controls” som validerar indata.

• Källkoden kompileras vilket gör att användare av systemet använder

färdigkompilerade filer för att generera sidorna vilket i sin tur medför snabba

laddningstider.

• Webbservern IIS har inbyggt stöd för att undvika problem med bl.a.

minnesläckor och oändliga loopar i koden. Upptäcks sådant startas aktuella

processer sömlöst om.

• Då källkoden ligger färdigkompilerad på servern kan programmeringsspråket

väljas bland flera olika, bl.a. VB.Net, J# eller C# (detta systems språk).

Det finns nackdelar då man jämför ASP.Net med andra alternativ (oftast open source‐

scriptspråket PHP). En av de stora nackdelarna är att ASP.Net är utvecklat för att köras på

Microsofts IIS‐server, vilken kräver Microsoft Windows (Microsoft ASP.NET Team, 2007).

Detta var dock ingen nackdel i detta fall då operativsystemet på servern som tillhandahöll

webbservern var Microsoft Windows Server 2003.

5.4.3 Ajax

Ajax står för ”Asynchronous JavaScript and XML” vilket är ett samlingsnamn för olika

tekniker som används för att skapa mer interaktiva webbapplikationer (AJAX: Microsoft

ASP.NET Team, 2007). Tekniken som används bygger på XMLHttpRequest‐objekt vilket

gör det möjligt att med hjälp av JavaScript göra serveranrop utan att hela sidan laddas

om. Det innebär att man bara kan uppdatera den del av sidan som förändrats istället för

hela sidan. DOM som står för Document Object Model är det som gör det möjligt att

förändra innehållet på sidan med JavaScript (Batra, 2006).

3 Active Server Pages


Det nya systemet använder sig av Ajax på de ställen där data ska hämtas från databasen,

är det en avancerad förfrågan som skickas till databasen som tar lång tid kommer

användandet av Ajax att göra det möjligt att använda sig av en animerad bild som visar

att systemet är upptaget. Största fördelen med tekniken är dock att trafiken mellan

klienten och servern minskas avsevärt eftersom klienten ”återanvänder” de delar av

sidan som inte har förändrats.

5.4.4 Databas

Databashanteraren som systemet använder sig av är av typen MySQL 5.0 där

lagringstypen på tabellerna är InnoDB4, detta för att ha stöd för sekundära nycklar och

triggers. Dessa funktioner saknade tidigare versioner av MySQL och därför valdes MySQL

5.0 som databashanterare. För att systemet ska ha potential för att ytterligare kunna

utökas har tabellerna gjorts så generella som möjligt, dvs. det finns möjlighet att använda

databasen till ett intranät med fildelning samtidigt som det används som

kommunikationsplattform mellan lärare och elever.

5.4.4.1 MySQL

MySQL är världens mest använda open source‐databashanterare och används av många

av världens största databasdrivna webbplatser, bl.a. Google, Wikipedia, Flickr och

Facebook (MySQL AB). Från början härstammar MySQL från Sverige där det har

utvecklats, men numera ägs MySQL av Sun Microsystems. Gränssnitten som användes till

databashanteraren var NaviCat 8 (Navicat) och MySQL Administrator 1.2 (MySQL

Administrator). Dessa verktyg har använts på olika sätt, där NaviCat främst har använts

vid skapandet av tabeller och procedurer, MySQL Administrator har använts vid

administration av själva MySQL‐servern.

5.4.4.2 Databasstruktur

Databasen är konstruerad utifrån tanken att systemet skall vara förberett för framtida

expansion och fler användningsområden än inom utbildning samt att det även ska kunna

användas som intranät. För att komma fram till en struktur som fungerar har olika

scenarion av extremfall tänkts igenom, t.ex. om en person ska ha två olika användare

4 InnoDB är en lagringsmotor i MySQL som till skillnad mot typen MyISAM gör det möjligt att använda sig av transaktioner och sekundärnycklar (Dyer, 2005, ss. 42‐44).


(fallet där en elev också arbetar som lärare) kan man inte ha personnumret som

primärnyckel eftersom det kommer finnas två användare med samma personnummer.

Det är emellertid svårt att på förhand föreställa sig alla tänkbara extremfall men alla

tabeller har utformats på ett så generellt sätt som möjligt för att kunna hantera detta.

När databasstrukturen hade upprättats skapades ett ER‐schema över databasen (Padron‐

McCarthy & Risch, 2005, ss. 27‐53). Ett ER‐schema ger en väldigt bra överblick över hur

databasen är konstruerad. Vidareutveckling underlättas när det finns en grafisk

representation av databasen att jobba efter, vilket även är till nytta för utomstående som

ska sätta sig in i systemets uppbyggnad. Figur 18 visar en överblicksbild över hela

databasens uppbyggnad.

Figur 18 ‐ ER‐schema över hela databasen


Figur 19 visar en detaljerad bild över en liten del av databasen, tabellen som lagrar

användare, tabellen som lagrar alla systemets ”grupper” samt tabeller för dess

relationer. Bilden visar även hur användarna ärver attribut från tabeller som innehåller

ytterligare information om just den specifika användaren, dvs. är användaren en elev

erhålles ytterligare information om användaren från elevtabellen.

Tabellen ”Grupp” i systemet kommer att innehålla samtliga grupperingar av användare,

exempelvis kan en grupp vara ”klass”, som i sin tur ingår i gruppen ”årskull”, som i sin tur

ingår i gruppen ”skola”, o.s.v. På så vis kommer all grupphantering att bli dynamisk och

man får en hierarkisk struktur på alla grupper i systemet. Användarhanteringen kommer

också att använda sig av arv, där varje användare i tabellen ”Elev” hör till föräldratabellen

”Användare”. Genom att göra på detta sätt kommer alla elever att få alla attribut som

finns i tabellen användare vilken är gemensam för samtliga användartyper i systemet.

Figur 19 ‐ Detaljbeskrivning av databasen

5.5 Säkerhet

Då mycket av den information som finns i systemet är känslig hade säkerheten högsta

prioritet. Genom hela utvecklingsprocessen har säkerheten varit i centrum och varje steg

har tänkts igenom för att i största möjliga mån förebygga eventuella säkerhetsluckor.

.Net‐plattformen erbjuder ett stort paket av färdiga säkerhetslösningar vilket har

underlättat arbetet, bl.a. Forms Authentication och Rollhanteringen som nämns nedan.


Lösenorden som lagras är samtliga krypterade med hjälp av hashning5 och saltning6, där

varje lösenord har flera separata saltningar.

5.5.1 Forms Authentication

För att hålla reda på att användaren är autentiserad användes .Net Forms Authentication.

I första stadiet kontrolleras om användarens namn och lösenord stämmer överens.

Stämmer detta loggas användaren in, inloggningen hanteras av Forms Authentication

genom hela användandet av den aktuella sessionen, som avslutas antingen genom att

användaren loggar ut manuellt genom utloggningsknappen eller stängning av

webbläsaren. Användarens inloggning hålls kvar genom en session och en relaterad

session‐cookie, vilka skapas automatiskt. Detta kan leda till s.k. session hijacking, då

någon illvillig person kommer över den cookie som den rättmätiga användaren har och

använder för att få access till dennes inloggning. Detta är taget i beaktande och systemet

har funktioner som märker av om fel person använder fel cookie.

5.5.2 Roller

Även om användaren är autentiserad och inloggad betyder det inte att användaren har

rätt att komma åt allt som finns i systemet. Administratörer har exempelvis rätt att lägga

till och ta bort elever, vilket inte eleverna själva har. För att hantera detta användes .Net

Roles. Det är ett system för att ge olika användare rättighet att komma åt specifika

platser på en hemsida. Den rollhantering som är standardiserad och förinställd kräver en

Microsft MS SQL‐databashanterare vilket inte användes. Detta löstes genom att göra en

egen Role‐klass vilket gav fördelen att rollerna kunde hämtas ifrån en MySql‐

databashanterare. Att göra egna Role‐klasser möjliggörs då interfacet RoleProvider

används.

5 I detta fall en envägskryptering för strängar.

6 Sträng som blandas med den sträng som ska krypteras.


I utveckling av systemet användes följande roller som grund (roller kan senare läggas till

och tas bort):

• Gud

o Används av några enskilda personer. Kan t.ex. lägga till/ta bort skolor,

och administratörer från systemet.

• Administratör

o Någon eller några personer per skola kommer att vara administratör,

vilken t.ex. kan lägga till/ta bort lärare.

• Lärare

o Lärarna kan t.ex. lägga till/ta bort elever och skriva in nyheter för skolan

och klasser i systemet.

• Personal

o Personal som inte är lärare får denna roll.

• Elev

o Har inga rättigheter att ändra något i systemet förutom sina egna

objekt, såsom meddelande, uppgifter etc.

• Målsman

o Kan se information om sitt barn, t.ex. frånvaro, provresultat och betyg.

Rollerna har en hierarkilknande struktur då en roll har de rättigheter som underliggande

roller har. T.ex. har rollen Gud rättighet att lägga till/ta bort elever.

5.5.3 SSL

För att förhindra sniffning7 av data som skickas mellan server och klienten (användaren)

använder det nya systemet SSL – Secure Socket Layer. Detta innebär att trafiken

krypteras och blir oanvändbar för eventuella avlyssnare. SSL är ett säkerhetslager som

körs mellan TCP och ovanstående lager, t.ex. HTTP (Howard & LeBlanc, 2003).

Krypteringsgraden är ofta antingen 40 eller 128 bitar, vilket motsvarar längden på den

krypteringsnyckel som används. En högre bitlängd på nyckeln ger ett säkrare

krypteringssystem och det nya systemet använder krypteringsgraden 128 bitar. Då all

information skall krypteras/dekrypteras kan systemet få en minskad prestanda i

7 Att avlyssna trafik mellan två parter, i detta fall att avlyssna trafiken som skickas mellan klient och server. Bl.a. lösenord kan snappas upp om dessa skickas okrypterat i klartext.


jämförelse med ett okrypterat system men säkerheten ligger i fokus och det är beräknat

att prestandan skall räcka till för att få en snabb och användbar plattform även med SSL.

Vidare erbjuder Secure Socket Layer ett certifikat där en trejdepart garanterar att den

sida klienten försöker ansluta till verkligen är den sida som anges, detta för att förhindra

falska sidor som lurar användaren att skicka in t.ex. sitt användarnamn (Klarqvist &

Corneliusson). Det finns olika s.k. Certificate Authorities (CA), utfärdare av godkända

certifikat som de stora webbläsarna litar på (Mozilla Firefox, Internet Explorer m.fl.). Det

går att skapa ett eget certifikat för att garantera att den sida klienten surfar in på är den

som utges men då måste användaren godkänna att den litar på certifikatet. Att använda

en pålitlig CA är därför att föredra.

SSL kan användas med en‐ eller tvåvägscertifiering. Med envägscertifiering har bara

servern ett certifikat och med tvåvägscertifiering har även klienten ett certifikat för att

förvissa servern om dess äkthet. I detta system används envägscertifiering då det räcker

att användaren litar på servern.

SSL fungerar på följande sätt (Klarqvist & Corneliusson):

1. Klienten ansluter med en krypterad uppkoppling med prefixet HTTPS istället för

HTTP.

2. Från servern skickas den publika nyckeln och information om certifikatet till

klienten.

3. Certifikatet har olika data som processas av klienten, t.ex. giltighetsperiod och

domännamn.

4. Data som skickas tillbaka från klienten krypteras med hjälp av den publika

nyckeln.

5. Data tas emot av servern som dekrypterar den med dess privata nyckel.

6. Data (HTML‐sidan) som skall returneras till klienten krypteras med den privata

nyckeln för att obehöriga personer inte skall kunna dekryptera dessa data.

7. Webbläsaren tar emot sidan och visar upp den genom att dekryptera den med

den öppna nyckeln.


5.5.4 Kontroll av indata

Eftersom alla indata som användare kan mata in i ett system skall ses som möjligt

skadliga måste skydd mot detta implementeras (Howard & LeBlanc, 2003). Med hjälp av

inbyggda klasser för validering i ASP.Net 3.5 blir det på ett enkelt sätt möjligt att

kontrollera alla indata som matas in via formulären i systemet. Det finns även inbyggda

klasser för att skapa parameteriserade SQL‐anrop till databasen, på så vis kan man

skydda sig mot skadliga SQL‐injections (Padron‐McCarthy & Risch, 2005, ss. 260‐262).


6. Diskussion

Arbetet med utvecklingen av ”det nya systemet” har i det stora hela fungerat ganska bra,

men givetvis har problem uppkommit som vid de flesta projekt. Tidsplaneringen är den

del som har varit det allra svåraste under arbetets gång, främst beroende på att vi har

saknat erfarenhet av att utveckla ett system som är i den här omfattningen, men även

beroende på andra faktorer. Dessa faktorer har bl.a. varit att vi i december blev

administratörer för det gamla systemet i och med att den person som utvecklat och

administrerat det tidigare slutade. Detta resulterade i att en del av vår tid gick åt till

arbete med det gamla systemet. I och med detta arbete har vi dock fått en god inblick i

vad som krävts av en administratör av ett system som vi sedan kunnat använda vid

planeringen av det nya systemet.

Vi hade även problem med att kunna avgöra vilken typ av server vi skulle beställa, även

detta på grund av bristande erfarenhet inom ämnet. För att lättare kunna avgöra vilken

kapacitet vi behövde på servern tog vi kontakt med bl.a. Apberget.se (en

ungdomscommunity) för att få tips om detta. När servern väl blev beställd var det ganska

lång leveranstid på den vilket även det ledde till en förskjutning i tidsplanen.

Huvudmålet med projektet var att förbättra användarvänligheten och säkerheten, detta

anser vi har åtgärdats i och med de lösningar vi har valt att använda oss av. Eftersom

gränssnittet inte är helt klart så är det svårt att säga om effektiviteten i användandet har

förbättrats eftersom inga användbarhetstester har gjorts på det nya systemet. Dock kan

antagandet göras att det förenklade gränssnittet kommer att leda till förbättrad

effektivitet jämfört med ThorenGruppens gamla system. Detta eftersom Normans

forskningsresultat pekar på att god mappning av gränssnittet leder till detta (Norman,

2002). Detta har avklarats:

• Systemet har fått väl igenomtänkt säkerhet med bl.a. SSL, kontroll av alla indata till systemet och kryptering av känsliga data.

• Designen är gjord för att effektivisera arbetet samtidigt som det skall inbjuda till användning från många användargrupper.

• Feedback används för att ge användaren information om vad som händer. Bl.a. används en laddningsindikator i de AJAX‐fönster som laddar information för att användaren skall veta att något händer.

• Systemet är modulförberett vilket gör att många nya funktioner kan läggas till utan att komplikationer uppstår i databasen.


• Systemet har fått en modularitet som gör att nya funktioner kan läggas till i framtiden genom att databasen är utbyggbar och webbsidorna är separata för olika funktioner.

• Systemet har en bättre skalbarhet då MySQL som databashanterare är snabbare än Microsoft Access, vilken Progress använder.

Lärdomarna i detta projekt har varit otroligt många, bland annat har vi aldrig tidigare

gjort följande (vi har således fått lära oss detta under projektets gång):

• Planerat ett så här stort system.

• Satt upp en komplett webbserver.

• Konfigurerat SSL‐protokoll.

• Krypterat data.

• Använt Visual Studio 2008/ASP.Net 3.5.

• Använt AJAX, m.m.

Den största lärdomen vi har fått är hur omfattande det är att designa databasen på ett

bra sätt från start då den är kärnan i systemet. Denna del är även väldigt tidskrävande

men det är väl spenderad tid då misstag i databasdesignen kan generera mycket

merarbete i slutändan, vilket vi bl.a. själva har upplevt då vi administrerat det gamla

systemet (Progress).

I skrivande stund är systemet ej i drift och saknar omfattande delar av gränssnittet för att

det ska vara möjligt att kunna använda systemet fullt ut. Utvecklingen kommer att

fortsätta och baseras på den prioriteringslista som tagits fram. Förhoppningen är att

under tiden som systemet är i drift ska ny funktionalitet fortsätta utvecklas som i sin tur

ska kunna leda till att systemet ska kunna säljas till andra skolor och företag. Vi har

väldigt många idéer om vad som kan implementeras i framtida versioner eftersom

möjligheterna för en webbapplikation är otroligt stora när man bl.a. använder sig av Ajax.

Några framtida idéer:

• Lärare kan skicka ut massutskick till elever via SMS om t.ex. inställda lektioner

m.m.

• Distanselever och lärare kan boka in ”hjälptimmar” där läraren och eleverna har

möjlighet att chatta med varandra och chatten sparas för framtida bruk.

• Lärare inom samma ämne på olika skolor i Sverige kan lägga ut kursmaterial som

är åtkomligt av alla andra lärare inom samma ämne.

• Hantering av RSS‐flöden.


Referenser

AJAX: Microsoft ASP.NET Team. (den 21 11 2007). AJAX: The Official Microsoft ASP.NET

Site. Hämtat från AJAX: The Official Microsoft ASP.NET Site: http://www.asp.net/ajax/

den 21 11 2007

Barab, S. A., Kling, R., & Gray, J. H. (2003). Designing for virtual communities in the service

of learning. New York: Cambridge University Press.

Batra, S. (2006). AJAX ‐ Asynchronous Java Script and XML. Salzburg: University of Applied

Science and Technology.

Baumann, K., & Thomas, B. (2002). User interface design for electronic appliances.

London: Taylor & Francis.

Dahlström, J. (2005). Internetundersökningar ‐ när, för vad och varför? Jönköping:

Internationella Handelshögskolan.

Dyer, R. J. (2005). Mysql in a nutshell. Sebastopol, Calif.: O’Reilly.

Ejlertsson, G. (2005). Enkäten i praktiken : en handbok i enkätmetodik. Lund:

Studentlitteratur.

Howard, M., & LeBlanc, D. (2003). Writing secure code. Redmond, Wash.: Microsoft

Press.

Klarqvist, F., & Corneliusson, P. (u.d.). Swesecure. Hämtat från Swesecure:

http://www.swesecure.com den 15 Febrari 2008

Microsoft. (den 22 11 2007). Active Server Pages. Hämtat från Active Server Pages:

http://msdn2.microsoft.com/en‐us/library/aa286483.aspx den 22 11 2007

Microsoft ASP.NET Team. (den 21 11 2007). The Official Microsoft ASP.NET Site. Hämtat

från The Official Microsoft ASP.NET Site: http://www.asp.net den 21 11 2007

MySQL AB. (u.d.). MySQL. Hämtat från MySQL: www.mysql.com Januari 2008

Navicat. (u.d.). Navicat. Hämtat från http://www.navicat.com September 2007


Norman, D. A. (2002). The Design of Everyday Things. New York: Basic Books.

Padron‐McCarthy, T., & Risch, T. (2005). Databasteknik. Lund: Studentlitteratur.

Shneiderman, B. (1984). Response Time and Display Rate in Human Performance with

Computers. Maryland: Department of Computer Science, University of Maryland.

Wilding, C. (1998). Practical GUI screen design: making it usable. Conference on Human

Factors in Computing Systems (ss. 125‐126). Los Angeles: ACM, New York.


Bilagor


Bilaga 1

Enkät

Sida 1


Sida 2


Sida 3


Sida 4

Sida 5


Bilaga 2

Enkätresultat


Bilaga 3

Prioritetslista – funktioner

Stödord från kreativt möte.

Möte 2007‐10‐25

Medverkande:

Anders (Vice Vd), Marie (Education Manager), Jon (Administratör), Henrik (Utvecklare),

Mikael (Utvecklare)

Prioritering 1 Basfunktioner Lärare/handledare

o Grupper Skapa nya gr. Administrera sina gr. Lista sina gr.

o Frånvaro Registrera Administrera

o Aktiviteter Skicka Ta emot Betygsätta

o Distans Kursrelaterat: Studiehandledning, kursplan (skolverkets) Personligt: studieplan Manual över hur systemet fungerar

o Nyheter Lägga till nyheter Administrera nyheter

Administrator o Grupper

Skapa nya gr. Administrera sina gr. Lista sina gr.

o Frånvaro Registrera Administrera


o Nyheter Lägga till Administrera

Elever/distanselever/kursdeltagare o Schema o Se nyheter o Uppgifter

Ta emot Svara

Föräldrar o Se nyheter o Se avkommans

Närvaro Schema Resultat Kommande uppgifter

Prioritering 2 – Underlätta större arbeten Lärare/handledare

o Betyg Betygsdokument IUP

Alla o Kalender o Individuella scheman o Distans:

Captivate‐film över hur systemet funktioner

Prioritering 3 – Underlätta mindre arbeten Alla

o Dynamiska scheman o Sjukanmälning i progress o Chatt

Prioritering 4 – Visioner Lärare/övriga

o Mail implementerat o Instant Messaging o SMS‐påminnelser o IP‐telefoni o RSS


Bilaga 4

Serverspecifikation

webbaserad kommunikationsplattform · 2008. 6. 12. · det finns vissa problem som kan uppstå med...

Documents