Hovedprosjekt ved institutt for Informasjonsteknologi. Høgskolen i Oslo og Akershus våren Bachelor i Anvendt Datateknologi

Transkript

1 Hovedprosjekt ved institutt for Informasjonsteknologi Høgskolen i Oslo og Akershus våren 2017 Bachelor i Anvendt Datateknologi Kristian Munter Simonsen Andreas Jacobsen Jamal Lakbir s s s236722

2 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR. 41 TILGJENGELIGHET Åpen BACHELORPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Administrativ tjeneste for SiO foreninger DATO 24. mai 2017 ANTALL SIDER / BILAG 34 / 234 PROSJEKTDELTAKERE Andreas Jacobsen, s Jamal Lakbir, s Kristian Munter Simonsen, s INTERN VEILEDER Torunn Gjester OPPDRAGSGIVER Studentskipnadden i Oslo og Akershus Foreninger (SiO) KONTAKTPERSON Mike Fürstenberg SAMMENDRAG Oppgaven er å gi SiO verktøy de kan bruke for å forenkle driften av foreninger tilknyttet SiO. Foreninger bruker i dag mange tjenester for å holde styr på sine medlemmer som fører til manglende rapportering, statistikk og flere foreninger sliter med å holde oversikt over egne medlemmer. Prosjektet skal løse dette ved å gi en robust, brukervennlig og sikker måte foreninger kan registrere og håndtere sine medlemmer på. 3 STIKKORD: Web-basert medlemshåndtering Django Web-mail

3 Forord Hensikten med dette dokumentet er å presentere utviklingsprosessen og produktet vi har utviklet for SiO Foreninger. Rapporten stiller ingen krav til forkunnskaper om systemet og kan leses av personer uten større teknisk kompetanse. Vi gjør oppmerksom på at enkelte faglige ord og utrykk er skrevet på engelsk. Disse og annen teknisk terminlogi blir videre utdypet under den tekniske ordboken. Denne prosjektrapporten er oppdelt slik at man skal få et helhetlig bilde av prosjektet og dets utvikling. For en dypere forståelse av de forskjellige delene henviser vi til vedleggene. Vi er takknemlige for støtten vi har fått under denne perioden, spesielt ønsker vi å takke SiO Foreninger ved Mike Fürstenberg, for tiden han har brukt sammen med oss gjennom utviklingen og Torunn Gjester som prosjektveileder ved HiOA.

4 Innholdsfortegnelse 1. Om prosjektet Prosjektgruppen Oppdragsgiver Hensikt med prosjektet... 2 Motivasjon Mål... 3 Resultatmål... 3 Effektmålet Metode og prosjektstyring Forberedelser og planlegging... 5 Ønsket bacheloroppdrag... 5 Start av prosjektet... 6 Intervjuprosess... 6 Rammebetingelser og personvernstiltak Prosjektstyringsverktøy... 7 PyCharm IDE... 8 Milepæler & KPI Kravspesifikasjon Kort systembeskrivelse Teknologi og miljø Utviklingsverktøy Språk Miljø Valg av rammeverk Server Git & Github SharePoint Design og Implementering Oppbygging av nettsiden Informasjonsarkitektur og navigasjon Skalerbarhet Funksjonaliteten Databasemodell Logisk databasemodell Implementering Medlemstall Testing... 32

5 6.1 Fler-nivå testing med BDD Selvevaluering og konklusjon Selvevaluering Konklusjon Måloppnåelse Vedlegg... 1 A. Prosessdokumentasjon... 1 Planlegging og metoder... 2 Valg av bacheloroppdrag... 2 Styringsdokumenter... 3 Risikovurdering... 4 Fordeling av arbeid... 5 Møter med veileder... 5 Møter med arbeidsgiver... 5 Intervjumetodikk... 6 Digitalt arbeidsverktøysett... 6 Utviklingsprosess... 8 Valg av utviklingsmodell Fossefall eller Scrum?... 8 Gjennomgang av sprintene Sprint 1 Planleggingsfase og implementering av database (5 Jan 2 Feb) Sprint 2 Bli kjent med koding; implementering av Admin og Medlem (2 Feb 2 Mar) Sprint 3 Statistikk og Epost (2 Mar 23 Mar) Sprint 4 Kalender (23 Mar 20 Apr) Sprint 5 Testing, fiks av bugs og rapportskriving (20 Apr 24 Mai) Prototyper Universell utforming Møtenotater B. Produktrapport Systemarkitektur Struktur og funksjon Modul: Medlem Medlemsoversikt Endre medlem Slett medlem Registrer medlem Modul: Statistikk Modul: Epost Front-end... 37

6 Skalering Administrator for SiO Sikkerhet Autentisering Session Glemt passord Utfordringer C. Teknisk ordbok - begrepsavklaring D. Dagbok E. Brukerhistorier F. SiO s tilbakemelding/attest G. Brukerveiledning Fra SiO Foreninger-perspektiv Fra foreningsperspektiv H. Intervjuer I. Detaljert kravspekk Rammekrav i systemet Funksjonelle krav Ikke-funksjonelle krav J. Prototyper K. Brukertester L. Sekvensdiagram M. Detaljert database N. Filstruktur O. Databasescript P. Testdokumentasjon Identifikasjon Sammendrag Avvik i forhold til testplan Vurdering av testens grundighet Gjenstående aktiviteter/oppgaver Avvik i produktet Vurdering av produktet som er testet Sammendrag av aktiviteter og lærdom Testplan Identifikasjon Innledning

7 10. Testobjekter Fremgangsmåte Godkjenningskriterier Testmiljø Testmanuskript Enhetstesting og Integrasjonstesting Systemtest -Selenium Systemtest Microsoft Test Management (Manuell testing) Q. Presentasjon R. Prosjektinformasjon S. Kilder

8 1. Om prosjektet 1.1 Prosjektgruppen Prosjektgruppen er satt sammen av tre 3. års studenter fra bachelorstudiet Anvendt Datateknologi ved HiOA. Gruppens sammensetning er valgt ut i fra den ulike kompetansen vi i gruppen har tilegnet i løpet av studiet. Vi har samlet anskaffet oss kompetanse innen de fleste grener av utdanningen da hver enkelt person i gruppen har fokusert på ulike aspekter ved studiet. Siden Anvendt Datateknologi åpner for mange ulike valgfag, har vi hatt gode muligheter til å fokusere på forskjellige fag hver for oss under utdanningsløpet. Gruppens medlemmer har også tidligere arbeidet sammen ved flere eksamensprosjekter, og har sådan funnet en god gruppedynamikk samt en god arbeidsmetode. 1.2 Oppdragsgiver SiO Foreninger er en avdeling under Studentsamskipnaden i Oslo og Akershus (SiO), som skal støtte opp om og tilrettelegge for studentforeninger. Det er i skrivende stund over 450 studentforeninger som er samlet under SiO Foreninger, der avdelingen blir ledet av Mike Fürstenberg. Han er også det som kan i dette sammenheng bli omtalt som produkteier og nærmeste kontakt til arbeidsgiver. Fürstenberg innehar god IT-kompetanse og forståelse for behovet til SiO Foreninger, men har ingen formell informatikkutdanning. Mikes Fürstenberg gode tekniske kunnskaper forenklet dialogene mellom oss og SiO Foreninger, samt det forenklet møtene. En kort prosjektbeskrivelse (Vedlegg Q. Presentasjon) ble først utformet av oss så presentert for SiO Foreninger som så på dette som en god ide og tok imot oppgaven. Gjennom gruppens egen erfaring med å drifte og starte opp studentforening har vi også noe egenerfaring når det kommer til hva som er hensiktsmessig å inkludere i en slik digital verktøykasse. SiO Foreninger ga utrykk for at deres fokus var på tilgjengelighet, brukervennlighet og ikke minst kvalitetssikring av medlemstall. 1

9 1.3 Hensikt med prosjektet Forarbeidet vårt har hovedsakelig bestått av å kartlegge hvilke funksjonaliteter studentforeninger ønsker seg, hvilken data de trenger å lagre om sine medlemmer og hva slags anonym data SiO Foreninger skal få innsyn i. Her har vi tatt i bruk intervjuer som metoden for datainnsamling, dette kommer vi videre tilbake til i rapporten. Bakgrunnen for prosjektet som senere kommer frem er å utvikle et universelt utformet system som skal kunne gjøre driften av studentforeninger enklere og mer tilgjengelig. Studentforeninger som ønsker å søke om drifts eller prosjektstøtte må gjøre dette gjennom Velferdstingets Kulturstyret. Kulturstyret deler hovedsakelig midler til de ulike foreningene basert på medlemstall som er registrert gjennom SiO Foreninger (Bildet til høyre). Det er derfor svært viktig at studentforeningene rapporterer faktiske og oppdaterte tall som i dag kan være vanskelig for mange foreninger. Motivasjon Bildet viser skjermdump fra internside til foreninger på sio.no Gruppens medlemmer har igjennom studieløpet tilegnet seg nok teknisk kunnskap til å løse alle fasene av utviklingen, vi ønsket å bruke denne kunnskapen til å løse ett problem som rammer mange studentorganisasjoner. Det at produkteier involveres i alle utviklingsleddene kjennetegner også det norske konsulentmarkedet som sammen med ønske fra produkteier om å få produktet ut til brukerne skaper en god motivasjon for oss som gruppe. Ideen til webapplikasjon er et resultat av selvopplevd frustrasjon ved å lagre medlemstall i ulike lokale dokumenter. Problemet med dette er at versjonskontroll blir problematisk ved deling av medlemsdokumentene og mangel av automatisk håndtering av medlemskapslengde. Vi kan se verdikonfigurasjonen til produktet som et verdinettverk med følgende nøkkelverdier: Økt verditilbud fra SiO Foreninger Strømlinjeformer søknadsprosessen Kvalitetssikrer medlemstall Analytisk data Enklere medlemshåndtering 2

10 1.4 Mål Ved å utvide den digitale verktøykassen forenkler vi flere aspekter ved drift av studentforeninger som fører til flere positive ringvirkninger. Disse har vi videre valgt å dele inn i resultat- og effektmål. Resultatmål Prosjektet skal resultere i et helhetlig administrasjonssystem med fokus på registering og medlemshåndtering for studentforeninger. Foreningenes personvern skal også respekteres slik at SiO ikke får innsyn i personlig data som de forskjellige foreningene lagrer. De ulike delene av systemet har ulike resultatmål, og disse blir da som følgende: - Registrering: Økt tilgjengelighet og enklere kontroll ved arrangementer og betaling. - Mail: Forbedre og forenkle formidling av foreningens arrangementer o.l. - Kalender: Forbedret oversikt for foreningens administratorer. Under er use case diagrammet for prosjektet gjengitt for ytterligere å visualisere prosjektets funksjonalitet. Visualiserte brukerhistorier av det ferdige produktet kan finnes i vedlegg E. Brukerhistorier. Fremstilling av use case diagram som viser flyt av informasjon og mulige handlinger 3

11 Effektmålet Mål for prosjektet er at mindre tid skal brukes på registering av medlemmer, data som automatisk oppdatere medlemstall ved slutt av medlemskap og enklere søknadsprosesser. Dette er direkte effekter vi ønsker at systemet skal resultere i og er det vi kaller effektmål i denne rapporten. Det er i dag over 450 studentforeninger under SiO. Hvis vi tar en antakelse om at det er i gjennomsnitt 6 personer i hvert styret tilsvarer dette 2700 potensielle brukere som får nytte av effektmålet. Skjermdump hentet fra en SiO promosjons video, redigert. 4

12 2. Metode og prosjektstyring I denne delen av rapporten vil vi ta for oss hvordan vi har jobbet og hvilke prosesser vi har valgt å bruke helt fra planleggingsfasen til det endelige produktet. På veien dit beskrives utfordringer vi har støtt på og hvordan vi har løst disse for å kunne fortsette en produktiv og forenelig videre utvikling av produktet. Blant annet har vi brukt intervjuprosesser for å utforme kravspesifikasjoner, denne metoden ble tatt i bruk etter samtale med arbeidsgiver der vi konkluderte med at dette ville gi ett best resultat. 2.1 Forberedelser og planlegging Ønsket bacheloroppdrag I september 2016, etter mislykkede forsøk på å finne arbeidsgivere (Vedlegg A. Prosessdokumentasjon Valg av bacheloroppdrag), begynte vi å lete etter arbeidsgivere og gikk aktivt ut med vår ide for oppgave i bachelorprosjekt. Gruppens medlemmer ønsket å arbeide med SiO Foreninger. Vi har jobbet mye med SiO Foreniger via foreningsdrift tidligere og er kjent med noen av problemstillingene SiO Foreninger står ovenfor. Vi mener vi innehar kompetansen til å gi SiO Foreninger verktøy de kan bruke for å forbedre foreningenes hverdag. Systemet skal også gi større kredibilitet til en forenings medlemstall. Etter kommunikasjon med Mike Furstenberg (Vedlegg A. Prosessdokumentasjon Valg av bacheloroppdrag), ble det satt opp et nytt møte hvor ideen skulle videre presenteres for leder av SiO Forening med navnet Gisle Hellsten. Han var interessert i ideen og var åpen for at dette vi la seg gjennomføre og måtte høre med ledelsen for godkjennelse. Etter noen dager fikk vi grønt lys til å starte med prosjektet for SiO Foreninger. Videre møter ble holdt med Mike Fürstenberg da hans rolle ble produkteier. Notater fra disse møtene kan finnes under prosessdokumentasjonen under vedlegg (A. Prosessdokumentasjon Møtenotater) 5

13 Start av prosjektet Prosjektet startet med å notere ned ulike oppgaver i Scrum-tavlen som besto av å finne styrker og svakheter i de ulike tilgjengelige Python-rammeverkene. Vi valgte 3 rammeverk som var av interesse for oss: Django, CherryPy og Flask. Valget ble Django som blir begrunnet mer i avsnitt «Valg av rammeverk». Dette førte til ekstra punkter i Scrum-tavlen som var å tilegne oss kunnskap rundt bruken av rammeverket. «Sjekke hvordan databasehåndtering (Migration), templating og routing fungerer» var en av taskene som ble lagt inn for å noe. Vi begynte å føre dagbok tidlig i prosjektet, denne kan finnes som under vedlegg (D. Dagbok). Intervjuprosess Ettersom sluttbrukerne av systemet er studenter ved ulike utdanningsinstitusjoner var det sentralt å vite hva som var ønskelig fra deres side. For å tilrettelegge for flest mulig valgte vi å invitere ulike foreninger med ulike krav til medlemskap og ulik foreningsstruktur. Vi var innerforstått med at vi ikke kunne tilrettelegge for alle og satte oss to mål for intervjuprosessen. Det første målet var å finne ut hvilken funksjonalitet som var ønskelig og hvordan dette kunne forenkle driften av foreningene. Det andre var å kvalitetssikre medlemsregistrering som primærfunksjonaliteten til systemet, dette ble gjort ved å kartlegge registreringsbehovene til de forskjellige foreningene. Utvalget av foreninger ble basert på foreningens tilknytning til SiO og mangfold mellom institusjoner og foreningens beskjeftigelse ble vektlagt. Under vedlegg i prosessdokumentasjon kan man lesse mer om hvilken intervjumetodikk som ble brukt ( A. Prosessdokumentasjon Intervjumetodikk). Foreningene som ble kontaktet og intervjuet var Aksjegruppen HiOA, Studentsamfunnet Chateu Neuf, HiOA Gaming, Oslo Tekniker Samfund og Samfunnet Bislett. Vi kom frem til følgende etter intervjuprosessen var fulført: Ønsket informasjon om medlemmer: Navn, epost, kjønn, fødselsdato, registreringsdato og avslutningsdato for medlemskap. Funksjon for: Kalender, kontakte medlemmer på mail, statistikk og søk av medlemmer. Web-appen ønskes skalerbar til smarttelefoner. 6

14 Notatene fra intervjuprosessen kan finnes vedlagt i H. Intervjuer. Etter intervjuprosessen satt vi oss ned for å lage førsteutkast av prosjektet i form av prototyper. Disse kan man finne under vedlegg J. Prototyper. Rammebetingelser og personvernstiltak Som studenter på anvendt datateknologi har vi fokus på sluttbrukerne av et system. Deriblant har vi flere emne som tar opp temaet om personvern. Foreningene under SiO Foreninger er atomære organisasjoner, som vil si at de er selvstyrte. Det er derfor ytterst viktig for oss å poengtere at all data som SiO Foreninger vil få tilgang til vil være anonymisert og kun styret i foreningen vil kunne få opp fullstendig informasjon om sine medlemmer. Fürstenberg har uttalt under møter at SiO Foreninger ønsker innsyn i anonymisert statistisk data når det kommer til medlemsregistreringer og lignende for å kunne få et bedre beslutningsgrunnlag når det kommer til ytterligere satsninger. Dette er bare et av flere eksempler som vil komme frem i denne rapporten som vitner til en at en god forventningsavklaring ligger i bunn av vårt samarbeid. 2.2 Prosjektstyringsverktøy Vi utvikler med bruk av SCRUM metodikk. Her definerer vi sprints og lengden på disse sprintene, etter hver sprint skal vi ha en fungerende applikasjon. Disse sprintene bruker vi Skjermdump fra YouTrack under sprint 2 7

15 JetBrains sin webapplikasjon YouTrack til å holde styr på. Feil eller problemer med en sprintdel noteres i «bug rapporter» som gjør det mulig for de andre gruppemedlemmene å se og hjelpe til med disse. Som i Git har vi også her en som kontrollere oppgaver og delegerer hjelp der det trengs. Hver sprint planlegges samlet av gruppen men vi tillater i motsetning til noen andre prosjekter endringer inne i sprinter mens vi er i dem om vi ser det som nødvendig. PyCharm IDE PyCharm er et utviklingsverktøy som er laget for programmeringsspråket Python med støtte for rammeverket Django. Den tilbyr kodeanalyse, grafisk debugger, integrert enhetstesting og versjonskontroll med bruk av Git. PyCharm tilbys i 2 versjoner, en profesjonell som koster penger og en gratisversjon; som studenter fikk vi gratis tilgang til betalingsversjonen og kunne da nyte fordeler som å kunne arbeide rett mot databasen fra PyCharm. Fremdriftsplan Under vår egen fremdriftsplan valgte vi å gå for et gant diagram. Gant diagrammet viser de mest sentrale delene av utviklingen og i hvilke perioder disse var planlagt å utføres. Vi har delt de ulike aktivitetene inn i farge for skille mellom teoretisk/dokumentasjon (blå), innspill og testing med brukere (grønn) og programmering (rødt). De ulike pilene en kan se er brukt for å beskrive avhengigheter. Altså at man kan for eksempel ikke begynne med testdrevet utvikling den 20/01 om ikke kravspesifikasjonen er ferdig til da (derav pilen). Disse er ment som et hjelpemiddel for å gi bedre oversikt om hvilke prosesser som er avhengige av at andre prosesser er fullført. Skjermdump fra av gantdiagrammet som ble brukt under utviklingen 8

16 Fremdriftsplanen er brukt som et grunnlag for KPI ene produkteieren får presentert. Det ble også gjennomført en risikovurdering av prosjektet som kan finnes vedlagt under vedlegg A. Prosessdokumentasjon Risikovurdering. Milepæler & KPI KPI eller «Key performance indicators» er en avklaring vi gjorde med vår produkteier tidlig I utviklingsfasen. Hensikten med KPI er å gi produkteier klare indikasjoner på hvordan utviklingen går. Disse ble tatt opp på våre møter for å holde utviklingsprosessen og fremdriften åpen. De mest sentrale KPI ene våre har vært: Samsvar mellom fremdrift og planlagt fremdrift (Gantdiagram). Kjører testene feilfritt (Kan være noe misledende da det å finne feil er noe som teller positivt) Milepælene våre har bygget seg opp om hvilken funksjonalitet som er på plass. Dette gjelder da hovedsakelig for utviklingsprosessen da vi også har hatt milepæler for oppsett av miljø, brukertester og testing av koder. Med andre ord følger milepælene våre likt som KPI ene og Gant diagrammet. 9

17 3. Kravspesifikasjon Kravspesifikasjon er ment for å være en veiledende hjelp for gruppemedlemmer, oppdragsgiver og veileder slik at alle er på riktig spor og følger en rød tråd fra start til slutt. Ved klare definerte avgrensinger, funksjonalitet og nytteverdi av hva som skal produseres økes forståelsen av alle parter som blir gitt i sin helhet ved ende av prosjektet. I de tilfellene vi har vært usikre på om det har vært mangel på funksjonalitet av omfanget så har dette vært et godt støttemiddel. Kravspesifikasjonen har blitt utarbeidet i samarbeid med produkteier, sluttbrukere og utviklere. 3.1 Kort systembeskrivelse Systemet skal effektivisere og forenkle prosessen med å registrere medlemmer og opprette/administrere foreninger. I tillegg gjøre håndtering av dokumentasjon med smidige handlinger slik at alt blir lagret i databasen for enklere oversikt med historikk. Mesteparten av dokumentasjonen skrives manuelt som har vært noe tungvint. Webapplikasjon har følgende grunn-funksjonalitet: Opprette, endre, slette og vise administratorer. Opprette, endre, slette og vise medlemmer. Opprette, endre, slette og vise kalender/grafer/statistikk. Detaljert kravspesifikasjon henvises til vedlegg (I. Detaljert kravspekk) 10

18 4. Teknologi og miljø 4.1 Utviklingsverktøy Hvis vi skal kunne lage et godt produkt for Studentsamskipnaden i Oslo og Akershus (SiO) vil det være viktig å bruke de rette verktøyene. Følgende teknologier har vi valgt for bruk i utviklingsmiljøene våre. De brukes også av serveren. Vi ønsker å minne om den tekniske ordboken da det kan forekomme flere tekniske ord og begrep i dette kapitelet. Python 3.5 Python er ett høynivå programmeringsspråk som er laget for å være lettleselig og nærmere engelsk syntaks enn mange andre programmeringsspråk. Python lar ofte programmerere løse problemer med færre linjer kode enn språk som C og Java. Django PostgreSQL Django er ett rammeverk bygd på Python som Python skrives i. Det er laget så du må følge MVT, har mange ferdig skrevne moduler og tilbyr god og testet sikkerhet. MVT har mange likhetstrekk med MVC-modellen. PostgresSQL er ett transaksjonelt relasjonsbassert databasesystem. Det tåler kraftig skalering, lar oss arbeide i noder/distribuerte servere om det skulle bli nødvendig og er godt støttet av Django sitt ORM språk. Mailgun Istedenfor å bruke egen epostserver benytter vi det tryggere alternativet mailgun. Der får vi managed epostlevering og ett api vi kan programmere mot. Mailgun passer også på at IP-adressen epostene sendes fra ikke kommer på spamlister. YouTrack YouTrack er ett online bug, forslag og prosjekthåndteringssystem. I YouTrack kunne vi planlegge vårt agile arbeid, delegere arbeidsoppgaver og når vi fant bugs i systemet la vi dem ut på YouTrack. Her kunne vi og se om ett gruppemedlem hadde behov for hjelp der det virket nødvendig. 11

19 4.2 Språk Vi har valgt språk basert på tilgjengelig dokumentasjon, rammeverk og ferdige pakker tilgjengelige samt en vurdering av hvor mye arbeid det vil være for gruppemedlemmene å tilegne seg kunnskap om å bruke språket. Vi har også vurdert hvor utbredt språket er og valgt med ett ønske om at det er ett språk med bred støtte som kommer til å bli oppdatert i lang tid. Som programmeringsspråk har vi derfor valgt Python 3.5, språket har god dokumentasjon, er sikkert og gruppens medlemmer mener det er raskt å lære. Da vi valgte språk så vi også på tilgjengelige rammeverk til de forskjellige språkene og fant mange gode til Python, etter språkvalget måtte vi vurdere de tilgjengelige web-rammeverkene til Python. Til slutt stod det mellom Flask og Django men valget falt på Django da rammeverket legger bedre til rette for skalerbare programmer og tvinger oss til å følge deres MVT modell som likner på MVC. MVT modellen gjør det lettere å gjenbruke kode for oss. Videre hadde Django-rammeverket mye mange moduler vi kunne bygge videre på så vi slipper skrive kode fra bunnen av. 4.3 Miljø I den tidlige fasen av programmeringen bruker vi Django sin innebygde webserver for utvikling på lokal maskin og programmet PyCharm for å skrive koden. Alle gruppens medlemmer vil kunne få individuelle virtuelle hosts ved behov men vi har som målsetning å jobbe mot samme virtuelle host. Vi forsøker å følge BDD Behaviour Driven Development hvor vi skriver scenarier med bruk av Gherkin-språket. Disse er svært lette å lese og fungerer også som del av kravspesifikasjonen, disse Gherkin-testene har tilhørende enhetstester som må oppfylles før oppgaven er ferdig. Vi skriver altså scenariet og testen før vi skriver kode, når testen er oppfylt kan vi si at koden er fungerende. En i gruppen ble satt til å lage grunnprosjektet i Django, så arbeidet resten av gruppens medlemmer utfra dette. 12

20 Valg av rammeverk Ønske var et rammeverk som ville være brukervennlig og enkel å bruke for å løse oppgaven. Vi landet på Django som er et høy-nivå Python rammeverk og veldig populær for rask og ren utvikling. Django er tilrettelagt for å bruke MVT-strukturen som gjør systemet lettere å vedlikeholde senere. Videre følger ett administrasjonsgrensesnitt med og Django har ett stort samfunn som kan bistå med hjelp samt god dokumentasjon. Django ble også valgt da vi ikke allerede kunne Django eller Python, men vi syntes det virket effektivt, godt designet og hadde ett ønske om å tilegne oss ny kunnskap som kan brukes senere igjennom bacheloroppgaven. Django gir oss også mange ferdige sikkerhetsmoduler, inkludert CSRF-tokens generert for hver bruker session, disse forhindrer CSRF-angrep (se ordliste). Server Vi kan alle kjøre prosjektet lokalt fra våre egne datamaskiner med Django sine innebygde webserver men legger etter hver sprint versjonen på master branchen i Git over på server. Denne har en offentlig ip-adresse, er koblet mot ett domene og skal simulere ett potensielt driftsmiljø. Serveren er en virtuell Ubuntu server som også genererer statistikk over ressursbruk gjort av applikasjonen. På denne serveren kjører vi Django prosjektet ved bruk av Nginx og Gunicorn. I serveren kjører applikasjonen i ett virtuelt Python miljø ved bruk av virtualenv programmet tilgjengelig via pip. Vi har deretter satt opp en virtuell vert i Nginx som lenker og gir rettigheter både til Django mappen og Gunicorn. Serveren kjører samme versjon av PostgreSQL som vi bruker i utviklingsmiljøet, alle tilgjengelige brukere på serveren er sikret med 256-bits RSA nøkler som innloggingsmetode. Brannmuren kjører på den virtuelle servere som fungerer som lastbalanse, men alle webserverne kjører også brannmur med samme oppsett. Etter en måneds drift av serveren viser loggen flere forsøk på å komme seg inn på systemet ikke gjort av oss som brannmuren har blokkert. Muren blokkerer alt unntagen det vi har spesifikt tillatt, den konfigurasjonen inneholder også noen porter vi holdt åpne under utvikling for å teste programvare men som ikke lenger trenger å være åpen. Bildet under viser oppsettet for brannmuren vår, siden Gunicorn ikke trenger noe tilgang til nettet selv kjører hele 13

21 applikasjonen bare på port 80, port 443 brukes av Google Drive og HTTPS trafikk. Vi har også åpnet for port 5432 rett mot den andre virtuelle serveren i det lokalet nettet slik at vi kan gjøre databasereplikasjon. Skjermdump som viser brannmurreglene Loggfilene fra brannmuren viser angrep både lokalt fra andre kunder med maskiner fra VPStilbyderen vår samt angrep fra internett. Serverne laster også automatisk ned nye stabile sikkerhetspakker fire ganger om dagen. Serveren sikrer brukerne ved bruk av SSL. Dette var noe av det siste vi implementerte serverside men viste seg å by på problemer da SSL sertifikasjonsserveren var nede dagen arbeidet var planlagt. Vi hadde på forhånd bestemt oss for å bruke gratistjenesten Let s Encrypt drevet av Linux Foundation. 14

22 Skjermdump fra letsencrypt.status.io som viser statusen til SSL generator serveren. Dette bruddet har ingen effekt på allerede utsende sertifikater, men vi skulle ikke ha ventet så lenge med SSL. Det viser seg at serveren for utsendelse er nede langt oftere enn serveren for de som alt har en stratifikasjon. For å forbedre dette i fremtiden har vi laget ett automatisk script på serveren som fornyer stratifikasjonen hver dag. Med det nåværende systemet kan vi ikke oppnå full score på SSL, dette er fordi siden laster inn eksterne scripts. Ved å laste ned alle scripts og kjøre alt rett fra webserveren kan vi oppnå full SSL dekning. Dette ble dog bestemt at ikke var noe vi trengte å bruke tid på, dette kunne gjøres om n For kryptering bruker vi en 2048 bits Diffle-Hellman gruppe som lar oss dele nøkler automatisk med brukerens nettleser som så verifiseres rett mot en hemmelig nøkkel i webserveren. Dette forsikrer at ingen andre kan utgi seg for å systemet eller deler av det da webserveren vil nekte alle innkommende forespørsler som ikke passer med den hemmelige nøkkelen. Siden serveren ikke serverer all scriptkode selv kan man få melding om at det er en usikker forbindelse i noen nettlesere. Chrome og FireFox blokkerer automatisk noen scripts for å gjøre siden sikker, dette har ingen synlig effekt for brukeren av siden. Men brukeren kan velge å tillate alle scripts. 15

23 Skjermdump fra FireFox med standardinnstillinger Skjermdump fra Edge med standardinnstillinger Skjermdump fra Chrome hvor vi har tillatt alle scripts Sertifikatet må fornøyes hver 3. måned men vi har ett script som fornyer det hver dag, dette er i tråd med retningslinjer gitt a Linux Foundation. For å gjøre dette bruker vi programmet Crontab på serverserie som fornøyer sertifikatet og restarter webserveren. Skjermdump fra Crontaben til brukeren som kjører systemet på serveren. Siden RAM er dyrere enn lagringsplass benytter vi oss også av servere med en lav mengde RAM men SSD lagring, vi har satt opp en 4 GB SWAP-partisjon på disse maskinene som kan brukes til å avlaste RAM om nødvendig. Illustrasjonen under viser serveroppsettet vårt. Illustrasjon av serveroppsett. 16

24 Ubuntu Server Nginx Gunicorn DomeneShop Virtualenv PostgreSQL Ubuntu Server ble valgt grunnet god tilgjengelig dokumentasjon, bevist robusthet og driftstid samt enkelt vedlikehold. Eierne av Ubuntu er raske til å komme med sikkerhetsoppdateringer og Ubuntu Server kommer med robuste nettverks og sikkerhetsfunksjoner rett ut av boksen. Gruppens medlemmer var også allerede kjent med Debian-baserte Linux distribusjoner. Vi bruker iptables via UFW som følger med Ubuntu Server som brannmur. Vi bruker Nginx som en omvendt proxy til å servere all HTML, CSS og JavaScript. Nginx gir oss bedre ytelse enn Apache for vår applikasjon og lar oss arbeide separat på applikasjons- og webserveren. For å få innhold lagd av Python-kode på hjemmesiden bruker vi Gunicorn som WSGI da Nginx ikke selv kan vise resultater av Python kode vevd inn med HTML og CSS direkte. Gunicorn ble valgt fordi det er raskt og lar oss enkelt skalere til større servere om nødvendig. Gunicorn leser Python koden og leverer HTML til Nginx Vi bruker Domene Shop til domenehosting da de er raske, billige, koblet rett mot NIX1 og NIX2. Vi har konfigurert domene til prosjektet som A- Records og epostoppsettet som TXT, MX og CNAME-Records. Vi kjører hele Django-prosjektet i ett Python virtuelt miljø på serveren. Det lar oss installere pip-pakker som kun kan kjøres av brukeren som kjører Django-prosjektet. Slik øker vi sikkerheten og fjerner både tekniske og ytelsesproblemer som kommer av å installere pip-pakker globalt på serveren. PostgresSQL er ett transaksjonelt relasjonsbassert databasesystem. Det tåler kraftig skalering, lar oss arbeide i noder/distribuerte servere om det skulle bli nødvendig og er godt støttet av Django sitt ORM språk. 17

25 Siden alle Python-pakker som installeres i serverne installeres i ett Python virtuelt miljø trenger vi ikke bekymre oss for å ødelegge noen systempakker, vi kan bruke en nyere versjon av en pakke som alt eksisterer på systemet i vår egen applikasjon mens versjonen operativsystemet bruker forblir intakt. Virtualenv lager en egen mappe der fult Python miljø settes samt pakkehåndteringsfiler og alt som trengs for å utvikle i Python, ved å kalle på ett script låser vi alle Python kommandoer til å kjøre kun med pakkene som er i miljøet. Det vil også si at det er umulig å kjøre prosjekt uten å kalle på de spesifikke pakkene i miljøet, så Gunicorn er konfigurert til å hente pakker derifra. Siden serveroppsettet vårt er annerledes enn utvikleroppsettet vil ikke nødvendigvis kode som kjører feilfritt i utviklingsmiljøet kjøre på serveren. Vi fant en løsning på disse problemene men for å lettere kunne hjelpe oss med serverproblemer i fremtiden lagde vi en PHP side med serverinfo og loggfiler. Siden er på hver av de to webserveren og heartbeat viser bare den som er satt som standard med mindre failback starter. Loggene synkroniseres ikke over serverne. Grunnen til at vi ikke synkroniserer loggene over server er at vi skal slippe dobbeltlogging samt at en feil på en server nødvendigvis ikke er samme feil som vil skje på den andre serverne, vi synkroniserer loggene med Google Drive så vi har tilgang til hver servers log for seg selv om den skulle gå ned uansett. Scriptet er spesialskrevet for Linux servere og fungerer dermed kun som det skal om det kjører på en Linux-maskin. Loggsiden er passord beskyttet med bruk av Nginx sin HTPASSWD-modul og OpenSSL-krypterte passord, vi loggfører alle forsøk på å logge inn som ikke går igjennom. Loggsiden gir heller ingen metadata til søkemotorerer så du må ha den fulle lenken for å finne siden. Ved bruk av Linux tilgangsnivåer har vi låst scriptet til kun å lese fra men aldri skrive til eller kjøre kode i symbolsk lenke loggfiler som oppdateres seg samtidig som de faktiske filene. Vi valgte PHP fremfor Python på denne siden da det vil tillate oss å se loggfiler selv om Python WSGI serveren er helt nede. For å gjøre om PHP kode til HTML og CSS som Nginx kan forstå bruker vi php-fpm (php-fastcgi process manager). 18

26 Skjermbildene under viser siden da vi brukte den for å løse ett problem vi hadde på siden vist på server. Skjermdump fra php siden som ble laget for enklere feilsøking under utviklingen, I tilfelle ett alvorlig server feil, laster vi også opp kun loggfilene i en kryptert mappe som overskrives en gang hvert 5. minutt med ny data til Google Drive. Går serverne ned vil vi ha loggfiler som er maksimalt 5 minutter gamle tilgjengelig der. 19

27 Git & Github For versjonskontroll benytter vi Git med Github som vertstjeneste. Git gir oss mulighet til å gå tilbake til tidligere versjoner / commits samt se hvem som har lastet opp hva. Prosjektet er satt opp som ett privat repository. Vi bruker også Git til å synkronisere kode til serverne med ett script vi kjører som henter ny data fra vår Master branch rett ned til produksjonsserverne når vi ønsker. Med denne metoden kan vi oppdatere hele produksjonsmiljøet vårt med ny kode med noen få tastetrykk og skulle ting feile trenger vi kun gå tilbake en versjon for å få systemet opp igjen. I utviklingsmiljø bruker vi programmet GitKraken til å styre Git, på server bruker vi Git Bash. Ved enden av hver 2. sprint setter vi den fungerende masteren som en «Releaes» i Git med nytt versjonsnummer hver gang. Utgivelsen kan lastes ned som en.zip fil og er kjørbar som ett Django prosjekt. Bildet vedlagt er et utdrag fra vår GitKraken per

28 Det er mange måter man kan arbeide sammen med bruk av Git. Vi har bestemt at ingen skal arbeide rett i master branchen med mindre det er veldig små estetiske endringer. Isteden arbeider vi i egne branches (grener) når vi jobber med egne moduler og felles grener når vi jobber sammen. Så b ruker Git sin merge funksjonalitet til få dette inn i master branch. Blir master ødelagt kan vi enkelt se hvilke endringer som er blitt gjort. Bildet under viser en merge der vi lett kan se hva som har blitt endret. Dette kan vi se både på GitHub direkte eller i GitKraken. Skjermdump fra en commit på GitHub 21

29 Med GitKraken kan vi grafisk løse konfliktene vi har i Git istedenfor å måtte holde oss til terminal. På store prosjekter som dette hvor det kan være svært mange konflikter i en merge har dette spart oss mye tid. Da velger vi den kodedelen vi ønsker å beholde, og kan beholde forskjellige dere. Altså kan vi dytte deler av ny kode til master men ikke alt, eller dytte alt. Bildet under viser en Konflikt der vi bare trenger velge en versjon (A eller B ) eller deler av hver kodesnutt i det forskjellige delene vi ønsker å beholde. Skjermdump fra en Git konflikt vist i GitKraken SharePoint For rapportskriving falt valget på Word etter å ha vurdert Google Drive sine tekstbehandlingsverktøy. Word i kombinasjon med SharePoint lar oss jobbe sammen på ett Word-dokument samtidig. Videre gir det også versjonskontroll og gruppens medlemmer var allerede kjent med bruken av Word. I SharePoint-mappen vår har vi også 1TB lagringsplass som vi har brukt til lagring av virtuelle serverbilder. 22

30 5. Design og Implementering I dette kapitelet skal vi gi en representativ gjennomgang av produktet ved å gå innom funksjonalitet, grensesnitt, database og brukerhistorier. Vi har laget en brukerveiledning for SiO Foreninger slik at kunnskap om systemet ikke blir borte over tid. Denne ligger vedlagt under vedlegg 5.1 Oppbygging av nettsiden Designet av tjenesten er hovedsakelig bygd opp rundt SiO sin eksisterende design og er ment å reflektere deres grafiske profil. Ting som overordnet navigasjons meny, ikoner til de ulike funksjonene i hovedmenyen og fargepalett er noe en enkelt kan se likheter med fra SiO sin egen hjemmeside. Noe av det vi måtte designe rundt er selve hoved funksjonaliteten til programmet, altså medlemsregistrering (Vedlegg B. Produktrapport Modul: Medlem). Informasjonsarkitektur og navigasjon Siden er bygget opp slik at man har flere muligheter for navigasjon. Enten kan man navigere seg videre fra hovedsiden gjennom bokser med kort beskrivelse om funksjonaliteten til den spesifikke undersiden eller så kan man bruke navigasjonsbaren ovenfor. Vi har passet på å gi brukeren mulighet til å avbryte ulike handlinger med tydelige avbryt knapper for å bli ledet tilbake til hovedsiden. Ved hovedsiden er det navigasjonsmuligheter til alle av sidens grener. Dette gjelder såfremt uansett hvor du er i programmet takket være den overordnede navigasjonsmenyen. Den aktive delen av programmet brukeren er på blir også visuelt representert i navigasjonsbaren ved å endre fargen for å indikere den aktive funksjonaliteten. Det er normalt å gi eksempler på informasjonsbehov en bruker har relatert til siden. Under kan du finne eksempler på disse. Everything (exhaustive research): The right thing (known-item seeking): Need it again (refinding): Som et styremedlem ved en studentforening ønsker jeg å finne utfyllende statistisk data om medlemstall for å kunne tilfredsstille mitt ønske om gode beslutningsgrunnlag. Som styremedlem ønsker jeg å sjekke om en person som ankommer et arrangement er registrert som medlem eller ei for å kunne sikre at deltakeren har betalt medlemsavgift. Som styremedlem ønsker jeg å finne tilbake til når neste styremøtet skal være slik at jeg møter opp til riktig tid. 23

31 Skalerbarhet Systemet tar i bruk rammeverket Bootstrap for håndtering av skalerbarhet med hjelp av CSS og JavaScript. Vi har også skrevet CSS kode for å finpusse for enkelte deler av systemet. Ikke alle deler av systemet skalerer like bra men hoved funksjonaliteten til systemet er anvendbar. Skjermbildene under er eksempler hvordan systemet ser ut på mobil. Se vedlegg B. Produktrapport Skalering for mer om skalering eller B. Produktrapport Front-end for mer om designelementer. Her er velkomstsiden til systemet gjengitt. Den overordnende navigasjonsmuligheten er forminsket og flyttet til toppen under en egen knapp. Navigasjonsmulighetene fra hovedsiden er enda tilstedte og nå sortert vertikalt. Her er navigasjonsbaren gjengitt. Som man kan se er den ikke helt optimal med tanke på plassen den tar opp men ellers fult fungerende. Hoved funksjonaliteten til systemet er her gjengitt, nemlig medlemsregistrering. Innput-feltene skaleres etter skjermstørrelsen som hentes fra nettleseren. Her er et annet eksempel på skalering fra «Charts»-siden. 24

32 Funksjonaliteten I dette underkapittelet ønsker vi å gi eksempel på funksjonelle brukerhistorier gjennom skjermbilder. Vi ønsker først å gi en representasjon av navigasjonsmulighetene systemet tilbyr ved hjelp av et navigasjonskart. Ett diagram over navigasjonsflyten til siden. Webapplikasjonen skal kunne gi bruker adgang til registeringsside etter oppgitt innloggingsinformasjon. Her skal bruker kunne få mulighet til å registrere nye medlemmer i en forening eller/og opprette forening. Samlet sett skal dette knyttes og lagres i database som vil gi mulighet for informasjon via statistikker og grafer. Brukerne skal bli gitt «roller» som bestemmer tilgangsnivåer som lese, opprette, endre, slette og lignende. Applikasjon skal primært være web basert og fungere på bærbare og stasjonære datamaskiner. Ideelt også for smarttelefoner og nettbrett med nettlesere. Brukerne av systemet vil primært være frivillige og styremedlemmer i foreninger. Kort oppsummert skal funksjonaliteten til systemet inneholde: - Innloggingsfunksjonalitet til tilhørende forening - Registrering og endringsmuligheter av medlemmer - Sende mail med påminnelser om medlemskapsforfall / kommende arrangementer. - Kalender for registrering av arrangementer og møter for enklere oversikt. - Vise statistisk data over medlemskap for korrekte beslutningsgrunnlag ved eventuelle tiltak - Overføre medlemstall til SiO sin API slik at de kan kvalitetssikre medlemstall og foreningen slipper å fylle inn denne og tilhørende informasjon 25

33 Under vises et eksempel av sekvensdiagrammet for registrering av medlem der systemet vil gi tilbakemelding ved feilregistrering og en vellykket registrering: I eksempelet under har vi tatt utgangspunkt i brukerhistoriene. Vi ønsker nå å visualisere brukerhistorien under med skjermbilder trinn for trinn. Flere visualiserte brukerhistorier kan finnes under vedlegg (D. Brukerhistorier) A Sekvens diagram for handlingen å legge til et nytt foreningsmedlem. Admin skal kunne legge til et nytt medlem. En/Flere admin har mulighet til å legge til flere medlemmer i systemet. Admin logger seg inn med brukernavn og passord. 26

34 Admin er logget inn og navigerer seg videre til «Members» fra hovedmenyen eller navigasjonsbaren. Admin kommer til siden «Members» som markeres som aktiv i navigasjonsmenyen og klikker seg videre til «+ New Member». 27

35 Admin legger til informasjon om medlemmet og trykker «Register new member» Medlemmet er nå lagt til og dette blir bekreftet. Man kan finne flere visualiserte brukerhistorier under vedlegg (D. Brukerhistorier). 28

36 Databasemodell Under er grunnoppsettet til databasen vår gjengitt. Hensikten med dette er å vise hvilke krav til data vi setter og hvordan disse skal lagres og kobles sammen. Det følger også med ekstra tabeller som Django generer slik at systemet skal fungere optimalt. Den fullstendige databasen med detaljerte verdier ligger som vedlegg (M. Detaljert database). Logisk databasemodell Databasens relasjonsdiagram uten entiteter. Viser relasjonene i databasen. Logisk databasemodellering er en representasjon av dataarkitekturen til et system på en grafisk måte. Det vil si at alt av detaljer som lagres i en database som attributter, kolonner, string, integer osv. ikke er med i denne modellen. Modellen tilfører informasjon av ulike entiteter og forhold til hverandre som kan jobbes mot den virkelige databasen. Vi har under gjengitt vår databasemodell for systemet. 5.2 Implementering Illustrasjon av logisk databasemodell. 29

37 Medlemstall I henhold til en endelig implementering av prosjektet er det flere aspekter ved systemet som skal snakke med eksiterende systemer. For det første er det å få implementert de registrerte foreningenes medlemstall til deres profil på sio.no. SiO sin nettside brukes blant annet av foreningene for å søke om støtte. Støtten baseres på medlemstall og ser per i dag ut slik som på bildet til høyre. Antall medlemmer, antall medlemmer ved primært lærested og antall medlemmer ved andre SiO-lærersteder vil da kunne bli automatisk satt inn ved hjelp av registeret de har benyttet seg av. Håndteringen for dette er relativt enkel og handler kun om å få lage spørringer som deretter legger til dataen i en eventuell ny søknad om støtte. Siden systemet leveres som ett testsystem SiO skal prøve ut vil ikke integrasjon med alle SiO sine systemer bli levert med, men strukturen for å enkelt koble opp er der. Skjermdump fra sio.no/foreninger sin søknadsgenerator Server SiO drifter sin egen serverinfrastruktur, så systemet er designet for å kunne kjøre på deres systemer. Hvordan de håndterer serverne er opp til dem, men databasen er designet for å kunne lett snakke med deres database og bruker samme databasespråk som resten av SiO sine databaser. Vi har kommet til enighet om at systemet skal bruke sin egen eposttjeneste, om SiO ønsker å implementere systemet skal det migreres over til SiO sin Exchange epost server. 30

38 Foreningsregister For å kunne lansere denne tjenesten må registeret av aktive studentforeninger sammenkobles med vårt system. Hver enkelt studentforening har sine respektive ledere og nestleder som står som kontaktpersoner for foreningene. Det vil da bli opprettet brukere for disse personene som må initiere bruken av systemet og legge til nye administratorer. Denne løsningen vil det være opp til SiO Foreninger å iverksette da innsyn til slik informasjon og tidsrammen vi har forholdt oss til ikke legger til rette for dette (se skjermbildet til høyre). I en slik løsning vil de blå hyper-lenkene om å registrere ny forening og registrere ny admin forsvinne og bli erstattet med en glemt passord funksjonalitet. 31

39 6. Testing Hensikten med våre tester er å finne feil i systemet samt gjøre utviklingen lettere. Vi har både skrevet tester for funksjonalitet som er implementert og skrevet tester for funksjonalitet som enda ikke var laget, når vi skrev tester for ikke enda implementert funksjonalitet lagde vi funksjonaliteten så det skulle bestå testen. Når testen gikk igjennom som grønn kunne vi konkludere med at koden fungerte. For fullstendig testdokumentasjon henviser vi til P. Testdokumentasjon i vedlegg. 6.1 Fler-nivå testing med BDD Det har blitt testet på ulike nivåer fra lav-nivå med «Behavior Driven Development» («enhetstest», «integrasjonstest» og «BDD» henvises til dataordbok/tekniske ordbok) til høynivå («akseptansetest»). Lav-nivå Enhetstesting fokuserer på å teste kode inne i moduler for seg selv, de utfører enkle operasjoner og kan brukes til å teste alt av kode. Dette for å dekke mest mulig bruk av koden og utelukke «bugs» (henvises til dataordbok/tekniske ordbok) som kan føre til feil ved bruk av ulike funksjonaliteter. Bildet under viser noen av enhetstestene våre. Skjermdump av enhetstest 32

40 «BDD» har blitt benyttet for å kombinere enhetstest med integrasjonstest til å gi en enkel forståelse av hva som testes. Dette gjøres med rammeverket «Gherkin» basert på «Cucumber», tidligere beskrevet ovenfor, der det beskrives med naturlig språk i scenarier med formatet «Given», «When» og «Then». De formatene beskriver detaljert hva hele scenario inneholder. I eksempel nedenfor bruker vi Gherkin til å teste login for en bruker. Gherkin kan kobles rett mot testkode for utviklerne men er også forståelig og testbart av ikke tekniske testere. Høy-nivå Skjermdump av "Gherkin" Høy-nivå testing legger vekt på det helhetlig ved produktet hvor funksjonalitetene testes. For eksempel, handlingene som gjøres via brukeraktivitet ved å registrere et medlem. Denne delen vil kunne gi svar på om bruker er godt fornøyd med det som utføres og imøtekommer brukervennligheten. Verktøy som benyttes her er «Selenium» for automatisert testing og «Microsoft Test Management» for manuell testing. Skjermdump av "Selenium" Nærmere detaljer av hva som er testet og hvordan det har blitt testet henvises til vedlegg (P. Testdokumentasjon). 33

41 7. Selvevaluering og konklusjon 7.1 Selvevaluering Grunnet valg av språk og rammeverk gruppens medlemmer ikke var tidligere kjent med tok det lengere tid enn forventet å implementere funksjonalitet. Dette førte til at noe av funksjonaliteten planlagt i sprinter måtte fjernes fra sprintene, vi fokuserte heller på å fullføre færre sprint-mål men gjøre det på en robust og sikker måte som kan utvides senere. Vi mener at valgene vi gjorde av teknologi gjorde oppgaven langt vanskeligere enn planlagt, vi hadde ikke lært å bruke noen av teknologien vi brukte igjennom utdanningsløpet vårt med unntak av noe av testingen. Disse utfordringene gjorde utvikling vanskeligere men gav oss også ny nyttig læring og har lært oss en helt annen måte å programmere på. 7.2 Konklusjon Planleggingsfasen av prosjektet viste seg å være mer omfattende enn forventet, men god planlegging har hjulpet oss stort og verktøyene vi planla i ga grunnlag for hele utviklingsfasen. Vi skrev kravspesifikasjonen selv på grunnlag av egen irritasjon med nåværende systemer og intervjuer med andre studentforeningen samt innspill fra arbeidsgiver. Dette utvidet planleggingsfasen betraktelig, vi fikk dog god hjelp med tilbakemelding på punkter både fra veileder og arbeidsgiver. Resten av planlegging ble gjort på grunnlag av denne kravspesifikasjonen. Spesifikasjonen ble endret under utviklingsfasen da vi så at vi ikke kunne nå alle mål som var satt. Testing med bruk av BDD gav gode resultater for oss, BDD gav oss mulighet til å skrive tekniske kodetester som vi uten noen endringer kunne bruke under brukertesting. Med god grendekning er vi også fornøyd med stabiliteten til systemet. 34

42 7.3 Måloppnåelse Prosjektet startet med grunnmål om å tilby en registreringsløsning som kan fungere for mange studentforeninger, dette mener vi at systemet oppfyller. Men det var også flere mål vi gjerne skulle ha oppfylt, men måtte sette til side for å sikre at grunnfunksjonaliteten ble lagd på en god måte. Både kravspesifikasjonen og funksjonalitet vi ville legge inn som ekstra måtte sidesetets, dette var til en stor grad grunnet å ha undervurdert hvor lang tid det ville ta å lære seg Python, Django og databaseteknologien vi brukte. Vi slet også med valg av design og epost-rammeverk og hvordan disse skulle implementeres. Ifra tidligere erfaring skrev vi kode ett sted og HTML som gjorde noe med denne koden ett annet. Men med Django genererte vi HTML rett utfra Python-klasse vårene flere ganger og hadde derfor problemer med å sette de rette attributtene og bibliotekene som ikke var direkte støttet av Django. Vi har laget en liste over mål som vi ønsket å nå men som ikke ble nådd. Mulighet til å sende epost til alle i foreningen. Verktøy for å sette inn bilder og gjøre eposter fine ved bruk av HTML og CSS. Full dekning av WCAG 2 AA Live søk istedenfor å klikke på enter for å søke etter medlemmer. Mulighet til å registrere og generere data om hvilket fakultet hvert medlem studerer på. Mot slutten av prosjektet mottok vi en evaluering av prosjektarbeidet vårt fra produkteier. Dette kan finnes under vedlegg F. SiO s tilbakemelding. 35

43 Vedlegg A. Prosessdokumentasjon Denne delen går vi gjennom ulike faser av bachelor prosjektet. Prosessen fra å finne et bacheloroppdrag til endelige utvikling av produktet og gjennomførelse av sluttdokumentasjon. Prosessen inneholder følgende: Planlegging og metoder Utviklingsprosess 1

44 Valg av bacheloroppdrag Planlegging og metoder Vi startet allerede fra juli 2016 med å snakke om mulige oppdragsgivere ønsket å skrive bacheloroppgaven for. Dette var forskjellige selskaper som Microsoft, IBM, NAV og mange flere. Når tiden nærmet seg skolestart sendte vi ut forespørsler til forskjellige arbeidsgivere for mulighet til å samarbeide med oss på bacheloroppgaven. I starten fikk vi avslag fra alle selskapene spurt, enten grunnet tidsmangel eller manglende interesse fra bedriftenes side. Gruppen fikk ett tilbud fra en studentforening om å forbedre ett eksisterende system de bruker, etter å ha evaluert oppdraget konkluderte vi med at det var for lite. Noe av målet med bacheloroppgaven for oss var å bruke ny teknologi, tilegne oss ny kunnskap og gjøre noe utfordrende. Ved noen utvekslinger av eposter utover høsten med Mike Fürstenberg; faglig leder for SiO Foreninger, ble det satt opp et møte hvor vi kunne presentere prosjektet. Vi forberedte oss til møtet med en PowerPoint-presentasjon slik at vi kunne presentere vår idé og gjøre det mest mulig interessant for vår fremtidige arbeidsgiver. Faglig leder likte presentasjonen og gav tilbakemelding om at han skulle presentere dette videre til SiO ledelsen da han alene ikke kunne gi klarsignal. Skjermdump av presentasjon for SiO 2

45 Danne omfanget av oppdraget Siden vi skrev planene og kravspesifikasjonen selv tok de tidlige fasene mer tid enn forventet. Ved å lage fremdriftsplan kunne vi grovt se hvor mye arbeid som måtte legges ned for å komme i mål med prosjektet. Endringer måtte vi regne med da alt som planlegges vil kunne endres siden vi arbeider agilt. For å informere SiO Foreninger om planene i den tidligere fasen lagde vi low-fidelity prototyper av applikasjonen vi viste frem til SiO Foreninger for å se om de var enig med hvordan vi ønsket at systemet skulle se ut. Vi avtalte møte med SiO for å vise prototypene, her diskuterte vi også hva gruppen trengte for å gjennomføre arbeidet og fikk tilbakemelding på skissene. SiO var positivt innstilt til planene våre men måtte høre med konsulenthuset BEKK om hvilke systemer vi kunne få tilgang til, BEKK utvikler de øvrige IT-løsningene til SiO. Vi hadde ukentlige møter med vår veileder selv mens vi ventet på svar fra SiO og BEKK, dette hjalp oss til å arbeide effektivt mens vi ventet på svar. Veileders innspill hjalp godt med både dokumentasjon og teknisk arbeid. Styringsdokumenter Det ble utarbeidet en fremdriftsplan alle medlemmene kunne referere til. Denne ble bruk når vi skulle se hva som gjenstod, se hva vi ikke har rukket og ble brukt til å sette krav til hva medlemmene måtte oppnå innen en gitt frist. Dette dokumentet viste også hvor ofte og når medlemmene i bachelorgruppa måtte møtes for å samarbeide. Risikoplanen ble utformat basert på styringsdokumentet. 3

46 Risikovurdering Ved å identifisere ulike risikofaktorer med tilhørende sannsynlighet og konsekvens kan en se hvilke risikoer man må arbeide med. Vi ble enige om seks overordnede risikofaktorer og førte dem opp i henhold til alminnelig risikovurdering. # Beskrivelse Sannsynlighet Konsekvens Klassifisering Tiltak 1 Noen i gruppen blir syke. 2 Full systemsvikt 3 Mangle på kompetent veiledning innen teknologi 4 Noen dropper ut av studiet 5 Endringer i kravspekk 6 Skreiv arbeidsfordeli ng Middels Middels Alvorlig God kommunikasjon mellom gruppens medlemmer. Høy Høy Kritisk Versjonskontroll og back-up håndtering Høy Middels Alvorlig Bruke tid på å opparbeide kompetanse inne teknologien og bruke guider og hjelp på nett. Lav Høy Alvorlig Ingen konkrete tiltak kan bli tatt. Middels Lav Neglisjerbar Vår arbeidsmetodikk er spesifikt tilegnet for å håndtere endringer. Middels Middels Alvorlig Ved å planlegge faser og sprinter og delegere ansvar derfra I en risikoanalyse er det altså risikoene som havner under rødt som krever strakstiltak. Risikoer som havner under gult er risikoer det er bra å være obs på men krever nødvendigvis ikke noen større strakstiltak. Vi mener å ha satt i verks tiltak for punkt to og tre som vil være gode nokk til å minske enten sannsynligheten eller konsekvensen. 4

47 Fordeling av arbeid En tidlig avgjørelse av arbeidsfordeling ble foretatt ut ifra ønsker man vil jobbe med og nye områder som man ville begi seg ut på for økt kompetanse. Vi valgte ulike ansvarsområder for å ha en bedre oversikt og holde oss til de områdene slik at vi ikke jobbet med det samme. Hvis en oppgave ble for stor var det viktig at vi kunne hjelpe hverandre for videre fremgang. Vi hadde en evaluering etter hvert møte hva som skulle jobbes videre med etter endt oppgave gjennomførelse. Frister ble satt slik at vi kunne greie å holde prosessen gående og at vi kunne følge planen inn mot den endelige fristen i mai. Møter med veileder Vi hadde ønsket en veileder med god kompetanse innen databasearkitektur da vi ser dette som en stor del av denne oppgaven. Valget falt på foreleser i databasefaget; Torunn Gjester som vi har vært svært fornøyd med i forhold til faglig kompetanse men også i hvordan rapporten skulle skrives. Møtene ble fastsatt til å være hver torsdag med status av nåværende arbeid og videre arbeid som måtte gjøres. Møter med arbeidsgiver Gruppen holdt kontinuerlig kontakt med arbeidsgiver både via møter og over epost. Arbeidsgiver manglet formell IT kompetanse men hadde likevel noe forståelse av utvikling og datasystemer. Med dette kunne det brukes flere tekniske utrykk i møte med arbeidsgiver og vi hadde mulighet til å få tilbakemelding på mer tekniske biter, som for eksempel hvordan SiO ønsket at databasen skulle designes. Før hvert møte forberedte vi en rekke spørsmål til arbeidsgiver så møtet skulle gå mer effektivt, vi fikk stille våre spørsmål så stilte arbeidsgiver sine spørsmål etter å ha svart på våre. Under møtene tok vi notater av tilbakemelding gitt av arbeidsgiver. Notater fra møtene med veileder og arbeidsgiver er beskrevet lengre ned i avsnittet om «Møtenotater». 5

48 Intervjumetodikk Vi valgte å gå for en semi-strukturert intervjumetode der vi hadde enkelte spørsmål klart før intervjuene og ellers fulgte trådene intervjuobjektene valgte å gå videre inn på. Ved å gå for en semi-strukturert metode kunne vi få svar på de spesifikke tingene vi lurte på men også avdekke andre aspekter og ønsker foreningene kunne ha. Den strukturerte biten av intervjuet omhandlet hovedsakelig hvilken informasjon foreningene lagret om sine medlemmer per i dag og hvilke ønsker de hadde for annen funksjonalitet. Ofte var ønskene om funksjonalitet og informasjonen som ble lagret om foreningene utover det som kunne forventes av en webapplikasjon som skal være brukervennlig for alle studentforeninger. Hovedformålet med intervjuprosessen var nemlig å finne de fellesnevnere flertallet av studentene ga utrykk for å ønske. Digitalt arbeidsverktøysett Valg av verktøyer til prosjektet viste seg å være utfordrende. Flere utviklings og - databaseverktøy ble prøvd, mange eposttjenester og to prosjekthåndteringsverktøy. Verktøyene vi endelig valgte ble valgt etter å prøvd verktøyene, gjort en gjennomgang av tilgjengelig funksjonalitet og hvor lett det var å finne støtte for produktet via forum på nettet. JetBrains Datagrip DataGrip lar oss koble opp mot Postgres-databasen vår. Den lar oss kjøre SQL-spørringer, generere grafer, endre data i tabeller grafisk og gir verktøy for alt vi trenger innen databasehåndtering. JetBrains PyCharm Professional PyCharm er en populær IDE for Python-utvikling, programmet følger med støtte for Django, integrert debugger, verktøy for testing inkludert grendekning, støtte for Gherkin med mye mer. Programmet er også godt dokumentert og gir oss en kommandolinje vi kan gjøre operasjoner i programmet fra. 6

49 PostgreSQL Mailgun YouTrack SharePoint GitKraken PostgresSQL er ett transaksjonelt relasjonsbassert databasesystem. Det tåler kraftig skalering, lar oss arbeide i noder/distribuerte servere om det skulle bli nødvendig og er godt støttet av Django sitt ORM språk. Istedenfor å bruke egen epostserver benytter vi det tryggere alternativet mailgun. Der får vi managed epostlevering og ett api vi kan programmere mot. Mailgun passer også på at IP-adressen epostene sendes fra ikke kommer på spamlister. YouTrack er ett online bug, forslag og prosjekthåndteringssystem. I YouTrack kunne vi planlegge vårt agile arbeid, delegere arbeidsoppgaver og når vi fant bugs i systemet la vi dem ut på YouTrack. Her kunne vi se om ett gruppemedlem hadde behov for hjelp der det virket nødvendig. SharePoint er et nettskysystem som lagrer ulike dokumenter, organisere arbeid man kan dele i gruppe. Dette gjør det lettere for oss å holde oversikt med vår framgang og er en fin løsning med lagring av reserve filer ved feil eller tap av data. GitKraken er ett program for grafisk håndtering av Git med integrasjon mot bla. GitHub. Med GitKraken kan vi enklere løse konflikter, få ett overblikk over hva som er gjort og se arbeidet i de forskjellige Git grenene enkelt. Visio Word Visio er et verktøy for utvikling av diagrammer og tegninger som egnet seg godt til illustrasjoner av ulike funksjonaliteter. Enkel i bruk og gir en god forklaring på hvordan den er i bruk. Word er et skriveprogram som har ulike funksjonaliteter for å gjøre det enklere for oss å redigere rapporten. Den gir i tillegg mulighet for at vi som gruppe kan samarbeidet over nett i sanntid. 7

50 Utviklingsprosess Valg av utviklingsmodell Fossefall eller Scrum? Det ble brukt mye tid på å velge mellom et fossefall- eller smidig (scrum) metode. Vi fikk inn forslag til at fossefallsmodellen er noe som ville passet oss siden vi jobber i faste faser av ulike sprints og er vi ferdig med en del så går vi videre til neste fase. I begynnelsen hørtes dette ut som en god ide som ville holde oss strenge på frister og gjøre at vi greier å holde en kontinuerlig fremgang (Steinberg, 2009). Skjermdump av Fossefall modell (James, 2014) 8

51 Fossefallsmetoden tillater ikke å gå tilbake til en sprint å gjøre endringer etter at den er utført, så det ble konkludert med at den ikke passet våre behov for oppgaven, særlig med tanke på at kravspesifikasjonen kunne endre seg under utviklingen. Dette innebærer at en smidig utvikling var det som hadde egnet seg best for denne oppgave. Fossefalsmodellen er en rollebasert der leder tar avgjørelsene og andre følger etter planen som er satt mens den smidige utvikling er en mer lag-basert metodikk. Dermed medførte dette en friere plan og kunne tillate endringer etter hvordan prosessen utvikler seg (Walters, 2007). Ettersom dette er en lagbasert metode vil det si at utviklere og brukere (kunder) kunne involveres mer. Brukere hadde mer innflytelse over hvordan produktet skulle representeres, vi mener dette kan gjøre at arbeidsgiver får ett produkt de til en høyere grad er fornøyd med. Skjermdump av Scrum modell (James, 2014) 9

52 Gjennomgang av sprintene Sprintene vi hadde varte i 4 uker der vi hadde 2 uker på forskjellige oppgaver. Disse forklares nærmere og vil gå innom utfordringer som oppstod. Sprint 1 Planleggingsfase og implementering av database (5 Jan 2 Feb) Tidligere beskrevet, skulle vi sette i gang med å planlegge og legge en oversikt av arbeidet for innholdet i prosjektet. Inspirasjon vi fikk var fra brukere og da oppsøkte vi forskjellige foreninger der vi foretok intervjuer og innspill som vi kunne få til utarbeidelse av kravspesifikasjoner. Da vi hadde planleggingsfasen klar var det å utforme databasen og skape de relasjonene som måtte til. Dette var arbeid med å lage ER-modeller (Entitiy Relationship) for å gjøre klar ulike data som skal lagres i ulike tabeller. Skjermdump av ER-modellen 10

53 Utfordring i sprint 1 Siden vi ikke hadde fått noen kravspesifikasjoner fra arbeidsgiver måtte vi finne ut av hva det skulle være. Dette tok mer tid enn vi hadde sett for oss. Når vi foretok de ulike intervjuene med foreninger hadde de mange ønsker som var svært krevende i implementasjon og tid. Vi måtte se om det var hensiktsmessig for oss å gå for de fleste ønsker som var egnet for deres forening eller gå for en helhetlig løsning som var for alle foreninger. Vi var enig om å gå for løsning for alle foreninger og hvis vi hadde tid kunne vi gå for noen ekstra funksjonaliteter. Ved opprettelse av databasen i «DataGrip» oppstod det konflikter i nøkkelhåndtering der tabellene ikke skjønte hvilken model den skulle knytte seg til. Dette viste seg at fremmede nøklene ikke kunne gå begge veier men bare fra den ene til den andre. Altså, at en fremmed nøkkel var det som holdt for å kunne bygge relasjon mellom to tabeller. Sprint 2 Bli kjent med koding; implementering av Admin og Medlem (2 Feb 2 Mar) Vi startet litt tidlig med å sette oss inn i rammeverket og språket siden alt var helt nytt for oss. I og med at vi ikke hadde en kompetent person innenfor disse områdene hadde vi måttet undersøke mye informasjon via internett. Da vi hadde prøvd og feilet gikk vi i gang med å sette i funksjonalitetene for administrator (styret) og medlemmer. Her skulle det lages et grensesnitt som gikk ut på at administrator skulle registrere, endre og slette medlem. Det samme gjaldt det for administratorer siden hele styret skulle ha samme rettigheter. Grunnen til at de ikke skulle ha ulike rettigheter var for å unngå avhengighet av andre i styret ved registrering av medlemmer og administratorer. Utfordring i sprint 2 Det ble en del konflikter i modellene siden dette var et nytt konsept og tok tid å sette seg inn for å forstå logikken. Her var det viktig å ha relasjonene i kronologisk rekkefølge og at en relasjon mellom to tabeller kunne ikke økes til tre eller flere tabeller. Endring av medlemmer oppstod også 11

54 Sprint 3 Statistikk og Epost (2 Mar 23 Mar) Siden denne sprinten er litt kortere enn andre var fordi vi ikke så for oss så mye arbeid i statistikk modulen men heller mer i Epost. Utarbeidelse her var å vise statistikker ut ifra data som ble registrert av medlemmer og her skulle det vises antall medlemmer og administratorer (styret). Det skulle vises aldersforskjell, månedlige registreringer av medlemmer og kjønnsfordeling. Epost modulen skulle sende ut meldinger til medlemmer av forskjellige arrangementer som skulle gjennomføres i løpet av året. Skjermdump av feil i statistikk Utfordring i sprint 3 Beregning som ble antatt viste seg å være feil da tok lengere tid enn antatt. Samt at det oppstod et problem med statistikk rammeverket og brukte for mye tid på å løse den. Det vi heller gjorde var å gå for et annet rammeverk som viste seg å være mye bedre og var mer skånsom i behandling av data. Dette rammeverket ble oppdaget senere og gikk utover arbeidet og tiden med neste sprint. 12

55 Sprint 4 Kalender (23 Mar 20 Apr) Planen var å finne en pakkeløsning for kalender der det meste var på plass av funksjonaliteter slik at vi kunne spare tid. Var en løsning som vi fant der den hadde gode funksjonaliteter men viste seg ikke å støtte for vår programmerings rammeverk. Vi fant en annen løsning som var like god men var en liten ulempe at den ikke hadde godt implementert med «Bootstrap» rammeverk. Det betydde at vi måtte gjøre mesteparten av arbeidet med utseende slik at den vil se godt nok ut for ulike digitale plattformer (mobil og nettbrett). Utfordring i sprint 4 Siden forrige sprint gikk utover tiden måtte vi finne en løsning som var nesten ferdiglaget for kalender hvor vi kunne bygge på manglende funksjonaliteter som var av behov. En annen utfordring var også at hendelser som ble registrert viste seg å være synlig for alle forskjellige foreninger. Planen var å registrere hendelser slik at alle som er registrert i den forening vil kunne se og ingen andre eksterne foreninger. Sprint 5 Testing, fiks av bugs og rapportskriving (20 Apr 24 Mai) I denne fasen fikk vi hentet oss litt igjen men var fortsatt bak skjema. Vi måtte dessverre korte ned på enhetstesting og integrasjonstesting der vi prioriterte de viktigste funksjonalitetene (Admin og Medlem). Satset heller på å kjøre en full automatisk- og manuell testing av alle funksjonalitetene i systemet. Samt akseptansetesting for foreninger og SiO-forening. Vi jobbet smått med rapporten slik at vi kunne gå tilbake og se hva som var gjort tidligere. Da prosjektet nærmet seg mot slutten måtte vi sette i gang for fullt med å fullføre rapportskriving og jobbe med små bugs som hopet seg opp under testing mot fristen. Utfordring i sprint 5 Siden vi har jobbet mot en server har det hopet seg opp feil som vi ikke hadde da vi jobbet lokalt til tider for testingens skyld. Dette måtte vi jobbe med slik at dette var klart inn mot fristen. 13

56 Skjermdump av en bug 14

57 Prototyper Prototype av forside Prototype av internside for forening 15

58 Fargevalg Prototype av forside Bilde over viser fargevalg av hvordan vi forestilte oss forsiden skulle se ut, til sammenligning med det endelige produktet som vises under. Skjermdump av den endelige fremsiden 16

59 Universell utforming "Forskrift om universell utforming " er en forskrift som omhandler hvilke krav som settes til brukertilpasning av informasjons og kommunikasjonsteknologiske løsninger. Det er en menneskerettighet å kunne konsumere innhold på nettet og denne forskriften er Norges måte å sette i gang arbeidet med å tilrettelegge for en så stor gruppe brukere som mulig. I den sammenheng er det viktig for oss å gjøre en innsats for å utvikle et produkt som er tilrettelagt for alle. Vi har lest oss opp på reglene og gått igjennom sjekklistene til W3C flere ganger for å se at vi følger disse kravene. Videre ønsket vi å oppfylle HTML5/CSS standarden satt av W3C, men da vi begynte med dette sent viste det seg å by på problemer. Flere steder skriver vi ikke HTML-koden direkte men bruker løkker til å loope ut Pythonkode som blir HTML. Dette gjør det svært vanskelig å sette rette tags i alt som blir loopet ut. Utgaven vi leverer fra oss i bachelorprosjektet oppfyller ikke alle WCAG AA krav men er nære, det burde ikke ta lang tid å utbedre applikasjonen til å fylle alle disse kravene. 17

60 Møtenotater Møte med SiO 25/01: Enten blir det samarbeid med BEKK og jobbe i deres miljø eller lokalt med SIO foreninger og jobbe med dem. Mulighet for integrering med systemet til BEKK s løsning eller systemet står ved siden av med de resterende systemet. Tillatelser med å bruke deres verktøy og bygge videre på SiO appen som er under utvikling. Hvis dette blir en fungerende prototype som viser seg å være kjempeide så kan de implementere videre i systemet. Kan implementere e-post systemet som kan kjøres på utsiden (blir vanskelig å implementere dette med systemet de har nå. De skal igangsetting med å rydde opp i systemet). Docker applikasjon enten må være hos SIO eller BEKK. Møte med veileder 26/01: Lage ER-modeler, databaser, use cases. Teste prototypen for å høre andres forslag og få mer inspirasjoner. Igangsetting med prosessrapporten. Lage skisser til sprinter. Møte med BEKK og SiO 01/02: Få tilgang til aksess til BEKK-systemet slik at vi kan jobbe det med lokalt. Bistå oss med database-systemet (mange databasetabeller). E-post funksjon blir en nøtt som skal løses. 18

61 Møte med produkteier15/02 Ønske om å kunne organisere medlemmer utefra om de er medlemmer eller ikke og legge de ikke medlemmene i egen tabell eller merke de på et eller annet vis. Medlemmene skal kunne kobles opp mot foreninger, man må også passe på at bare en viss mengde av medlemmene kan være fra ikke-studenter, dette har med tildelingsregler å gjøre. Under testing blir det viktig å høre med SiO eller foreninger om det er eventuelle endringer som må gjøres eller feil som kan dukke opp underveis. Møte med veileder 15/03: 3 rapporter med ulike deler. Produktet skal vises i presentasjon. Hvorfor vi har valgt å lage et system fra bunn istedenfor å ta en hyllevare eller produkt fra gate? Brukertest må BARE oppfylle kravspesifikasjoner. Akseptanstesting. Møte med veileder 06/04: Få frem mest mulig om produktet (og mindre om oppdragsgiver) Se mer på kravspesifikasjoner hvis vi skulle være usikker. Møte med produkteier 06/04: Behov for en foreningsoversikt hvor alle i styret sin epost er tilgjengelig. Skrive en personvernerklæring. Fokus på brukermanual slik at SIO kan videreføre arbeid av systemet. Bruke mest tid på funksjonalitet som er viktig for foreninger. Need to have and nice to have. Legge til kjønn i associaton summary (eller andre data i tillegg) (biologisk kjønn) 19

62 Møte med veileder 20/04: Kortere sammendrag. Resultat og effektmål med forbedring. Figurer av backend og frontend. Miljøet etter oversiktsdelen som kommer i starten. Metodikk kommer før miljøet (planer for prosjektet, intervjuer osv) Omfang, kompleksitet, jobbe mer systematisk. Viktig hvert avsnitt har tyngde og mening. Finne en fin balanse slik at en mindre teknisk- og teknisk person kan forstå de første sidene av sluttrapporten. 20

63 B. Produktrapport Denne delen av rapporten tar for seg produktet i tekniske detaljer. Her beskriver vi ulike funksjonaliteter som er bygget opp ut ifra hva som er behovet spesifisert i kravspesifikasjon. Mulig det blir noe gjentakelse her som er blitt gjengitt i andre deler av rapporten. Dette må til for å gi en forståelse av hva produktet innebærer. Hovedsakelig er dokumentasjon rettet for de som skal eventuelt videreutvikle dette produktet, eller for de med sterk teknisk kompetanse. Rapporten er bygget opp som følgende: Nettadresse Skal vi oppgi nettadresse her? Fortsatt noe som ikke virker og er feil Back-end Front-end Sikkerhet Utfordring 21

64 Back-end Denne delen tar for seg back-end delen av systemet og er hovedsakelig skjelettet for produktet. Rammeverket som er benyttet her er «Django» med «Python» som programmeringsspråk. For de som skal utvikle dette videre er det viktig med forståelse for rammeverket samt programmeringsspråket. Back-end delen av rapporten er bygget opp slik: Systemarkitektur Struktur og funksjon Systemarkitektur Oversikt over systemarkitekturen 22

65 Slik som arkitekturen viser lagres dataene i databasen hvor «Web Server» henter data som skal bearbeides mellom lagene i «Web Server». De ulike lagene jobber sammen med å overføre dataene mellom dem der «Django» styrer for det meste dataene, så er «Middleware» et verktøy som hjelper med å modifisere «request eller response» som kommer fra eller til «views». «ORM» (Object-relational mapping) er en programmeringsteknikk som konverterer data mellom relasjonsdatabaser og objektorienterte programmeringsspråk. I dette tilfelle er teknikken benyttet med «Django» og «PostgreSQL» slik at behandling av data blir mer orientert og gir en mer oversikt av hvor dataene blir overført til. «Django i dette tilfelle er mye dypere enn de lagene som er forklart men er ment for å holde det så enkelt som mulig. Dataene blir så da overført til «Client» som har bedt om å få se de dataene som ønsket. Blir epost benyttet sendes data fra «Web Server» til «Mail server» som ender opp hos «Client». Struktur og funksjon Filstruktur i sin helhet (vises til høyre) er organisert slik at det skal være lett forståelig og enkel tilgang til filene. Hoved funksjonalitetene for back-end ligger i «SiO» mappe som vi skal se mer på videre. Skjermdump viser hovedstruktur i prosjektet 23

66 Alt av back-end koder ligger i «views.py» i motsetning til de fleste andre programmeringsspråk hvor den er i en «controller» mappe. «Django» følger en struktur av type «MTV» (Model, Templates og Views) istedenfor «MVC» (Model, View og Controller). Forklaring av de ulike lagene: «URLS» definerer alle adressene som «Views» benytter slik at dataene blir overført til rette modul. «Views» innehar all logikken som skal overføre dataene og henter dataene fra «Models». «Models» definere strukturen av hva slags data- og hvilke typer data som er lagret. «Database» lagrer all data som kommer fra ulike lag. «Templates» viser fram all data i en finere format for bruker. Skjermdump viser livssyklus MTV (Diksha, 2015) Kilde Skjermdump viser forskjell på standard (Diksha, 2015) For å kunne utvikle noe som helst av data som kommer inn er det viktig med modeller og database for å lagre all data. Nedenfor vises Medlems-tabell med sine attributter for å bli definert slik at de danner grunnlaget for hva som fylles inn av data. 24

67 Skjermdump viser modellen for Medlem 25

68 Bildet til høyre illustrerer filstrukturen til systemet. Alt ligger strukturert under mappen SiO og hver ulike gren av systemet har en egen mappe med egne statiske filer (CSS, JavaScript osv.), migrations mappe, og templates mappe hvor HTML filene ligger. Dog er ikke all HTML som vises i prosjektet fra templates. Django bygger videre på prosjektet basert på models.py og forms.py for å nevne noen. Templates mappen på bunnen inneholder repeterbar kode som navigasjonsmenyen og lignende. Dette blir da bare referert til i fra de ulike undersidene og generert fra templates. For å klargjøre er dette da egenkonstruerte templates og ikke ferdigbygde. Skjermdump av moppestruktur for en app (eksempel CoAdmin) 26

69 Modul: Medlem Denne modulen er bygget opp slik at den skal gi en oversikt over-, registrere-, endre- og slette medlemmer. Modul for Administrator er tilnærmet lik denne modulen bortsett fra at den ikke inkludere søke-funksjonalitet. En nærmere beskrivelse av hvordan de funksjonalitetene virker: Medlemsoversikt Django har gjort det enklere for utviklere å programmere deler av funksjonalitetene slik at man slipper å bygge ting fra bunn. Dette har de gjort med såkalt «Generic Views» som er ferdig lagde metoder som kalles på (Django Documentation, u.d.). Skjermdump av "Generic views" bibliotek «ListView» kalles på slik at den generer en liste av medlemmer i en oversikts-tabell. Effektiviteten av å genere vises under med bare 2 kode linjer i vårt tilfelle. Skjermdump av "Generic Listview" «Template name» blir definert slik at oversikt av medlemmer vil kunne synes i nettleser og blir «paginated» etter 6 medlemmer på en side. Altså, når det registreres et nytt medlem som blir nummer 7 så vil det medlemmet vises på neste side. Skjermdump av sidetall (paginate) 27

70 Siden det blir en god del registrering av medlemmer vil en søke-funksjonalitet gjøre det lettere å finne om et medlem er aktiv eller ikke. Skjermdump viser metode for søke-funksjonalitet Ovenfor viser en metode for å søke opp medlemmer ved å kalle på «GET» metode slik at den henter navn-attributtet på «q» og sjekker om det stemmer. Er den riktig vil den da foreta en spørring mot databasen på om medlemmet finnes i databasen på fornavn, etternavn eller epost. Blir det ikke skrevet noe inne i søke-feltet og klikker på søke-knappen vil alle medlemmer bli listet ut. Hvis ikke medlemmet eksisterer vil den gi beskjed til bruker på frontend som vist nedenfor. Skjermdump viser bruken av "template-tag" {% %} er en innebygget «Django template-tag» som gjør det enklere å få fram det man ønsker ut til bruker på templates, i stedet for å måtte skrive ekstra metoder i back-ned (Django Documentaion, u.d.). {% %} er en del av «for-loop» som ikke vises her. {% %} viser tekstlig innhold i nettleser til bruker. 28

71 Endre medlem Ved endring av medlem tar denne noen ekstra variabler i motsetning til medlemsoversikten vist tidligere. Skjermdump viser funksjonalitet for endring av medlem «UpdateView» metoden blir kalt på for å sette i gang endringer av objektet via å kjøre mot «model» og henter skjema for endringer fra «form_class» som vises nedenfor. Ved en vellykket endring vil man bli navigert til medlemsoversikten med en «success_message» som hentes via metoden «SuccessMessageMixin». 29

72 Skjermdump viser strukturen for et skjema Grunnlaget for skjema settes i «forms.py» og her blir alt definert slik at andre deler av koder kan kalle på formen. «Meta» klassen er viktig å definere på lik linje med «init» da de viser og overfører dataene som blir kalt på. 30

73 Slett medlem Denne funksjonaliteten er ganske lik som «endre medlem» bortsett fra at den ikke gir en vellykket melding som dessverre må gjøres via en manuell metode. Skjermdump av generering for brukervennlig melding Registrer medlem Siden registrering av medlem er i sentrum har valget å skrive denne fra bunn siden det inngår detaljer som er lettere å holde orden på hvis eventuelle feil skulle dukke opp. Skjermdump av funksjonalitet for registerering 31

74 Denne funksjonen tester på om «POST» metoden er definert i «template» og hvis det er tilfelle henter den formen som er registrert i «forms.py» med navnet «RegForm». Hvis ikke all data som fylles ut i skjema stemmer vil man kunne få feilmelding i de feltene det gjelder og bli redigert tilbake til siden. Er dataene derimot riktig vil det bli lagt til et medlem med en vellykket melding. Modul: Statistikk Ideen her er å visualisere ulike statistikker, via «JavaScript», som hentes fra lagrede data av registrerte medlemmer. Disse skulle være til nytte for SiO og ulike foreninger der ønske var å dokumentere, blant annet, antall medlemmer og hvor mange registrerte medlemmer det er per måned. Skjermdump av API-data Skjermdump av JSON-data 32

75 Et viktig og kraftfullt verktøy med navnet «Django REST framework» var nødvendig for å realisere grafene (Christie, ). Rammeverket hjelper med å generere data fra «Django» til «JavaScript» i JSON format slik at dataene sendes mellom dem. Figurene over viser to formatter av data som Django genererer. Skjermdump av REST-framwork bibliotek «Rest framework» bidrar med to biblioteker som benyttes slik at de oversetter dataene fra Django og ut til grafene som vises i nettleser. Skjermdump av deler av statistikk modul Bildet over viser hvordan «ChartData» genereres med hjelp av «APIView» metoden slik at det foretar spørringer som regner ut totalen for antall administratorer (de som sitter i styret) og antall medlemmer. Videre blir dataene satt i arrays som videres sendes variablene «default_items» med «labels» og «default_items2» med «labels2». De blir da lagt til i en «dictionary» med navnet «data» og sendes da videre i en JSON «Response». 33

76 Modul: Epost For epost bruker vi den eksterne leverandører MailGun, de er eid og drevet av RackSpace som har ett rykte på seg for å være pålitelig og har holdt på lenge. MailGun gir oss ett API å programmere mot og en hjemmeside der vi kan se grafer og logger fra epostleveransene våre. Vi får kun IMAP via MailGun og kan dermed kun sende men ikke motta eposter via MailGun. Utenom å være pålitelig og gi stabilitet får vi også gratis epostutsendelser i måneden via MailGun, som har ført til at vi har kunne bruke tjenesten helt gratis under utviklingen. Det ble vurdert å sette opp en egen epostserver men dette ville krevd mye periodisk vedlikehold og vært lite hensiktsmessig da SiO har sine egne epostservere. For å få kontakt med MailGun sitt API måtte vi først sette opp DNS-ruting. Denne rutingen gjør at MailGun sine servere kan sende fra domenet vi har kjøpt via DomeneShop og inkluderer vår private MailGun API RSA-nøkkel. skjermdump fra domeneshop.no Siden MailGun bare lar oss sende ut epost har vi brukt ett alternativt domene istedenfor det originale, da kan man raskt legge til inngående utgående epost via DomeneShop, med rutingen kan vi uansett sette epostene gående fra hvor som helst som ender domenet. Vi kan altså om ønsket sende epost fra foreningsnavn@sioforeninger.no (hvor da foreningsnavn byttes ut med det faktiske navnet på foreningen). Dette har ikke blitt implementert i bachelor-fasen. MailGun gir oss ett grafisk brukergrensesnitt for å sjekke DNS-pekerene våre, dette var til stor hjelp under oppsettet. 34

77 Skjermdump fra app.mailgun.com MailGun gir oss også loggfiler over leveranse som hjelper stort når vi tester kode. Her kan vi se om en melding er levert og all dataen som ble sendt i melding i JSON-format. Skjermdump fra app.mailgun.com/app/logs/test.sioforeninger.no 35

78 For epost fra Django bruker vi pip-pakken django-anymail, denne forenkler kraftig epost oppsett for oss og har støtte for MailGun. Alle eposter som sendes lagres i databasen med informasjon om hvem som sendte mailen og når. Modellen for epostlagring viser hva vi lagrer. Skjermdump fra databasemodellen til epostdelen av systemet For validering av epostadresser bruker vi en ferdig django-pakke for epost validasjon istedenfor å bruke egne regulære utrykk. Epost støtter også HTML men uten å ha bygd verktøy for å sette dette inn for de som ikke kan HTML kode har vi ikke dokumentert dette. Koden under viser hva alle eposter kjøres igjennom før de får gå ut mot APIet, dette er relatert til og henter data fra epost viewet vi bruker. Skjermdump fra mail.py 36

79 For å sende med rett API-nøkkel og domene har vi konfigurert hele Django-prosjektet til å bruke disse verdiene hver gang anymail blir kaldt via django sin settings.py fil. Skjermdump fra settings.py Front-end Her beskrives front end med fokus på forskjellen mellom systemet for SiO og for foreninger. Hver forening kan kun se informasjon om sin egen forening men alle foreningene har samme oppsett på sidene. Når de har blitt registrert i systemet får de tilgang til utgående epost, kalender, statistikk over medlemmer, kalender, mulighet til å legge til nye medlemmer samt administrasjon av eksisterende medlemmer. Siden er skrevet på engelsk da dette under intervju prosessen ble avdekket at dette ikke ville være noe problem for foreningene. Dette åpner da også for internasjonale studenter. Skjermdump fra sioforeninger.no 37

80 Vi har valgt å bruke bootstrap sammen med egen CSS kode for å tilpasse nøyaktig ønsket design. Det er et gjennomgående design av boksene innholdet er plassert i og er ment for å gi et helhetlig inntrykk av designet på siden. Ikoner er brukt for å visualisere funksjonaliteten til den gjellende undersiden og er gitt samme farge da det ikke er statiske filer, som gir oss mulighet til å endre på dem etter eget ønske. Siden dette er en full webapplikasjon istedenfor en enkel hjemmeside laster mange av sidene tregere enn ved flere tradisjonelle hjemmesider. For å gjøre opplevelsen mykere har vi inkludert en skjerm med en «Loading» animasjon brukerne ser istedenfor en hvit side mens man navigerer mellom sidene. Når siden er ferdig å laste "fader" animasjonen vekk og siden vises. Skjermdump fra sioforeninger.no/calendar/ I kalender-applikasjonen over vil det være hjelpemidler med forklaring for hvordan ulike funksjonaliteter fungerer hvis det skulle være noe som er uforståelig. Hvordan de ser ut, ved å la musepeker ligge på teksten «What do i do?» visuelt, vises under. 38

81 Skjerdump fra sioforeninger.no/calendar/ Skjerdump fra sioforeninger.no/calendar/ Skjerdump fra sioforeninger.no/calendar/ 39

82 Skalering Siden bare styret kommer til å kontoer har vi også tillatt at en konto kan være logget på mer enn en plass samtidig. Dette etter tilbakemeldinger fra foreninger om ett ønske om at flere i foreningen skal kunne registrere nye medlemmer på for eksempel arrangementer samtidig. Foreningene ønsket også muligheten til å registrere medlemmer via mobile enheter så vi har laget systemet så det lett kan kunne brukes på små touch skjermer. Dette er gjort med bruk av store knapper og store soner rundt knappene og feltene man kan treffe med fingrene. sioforeninger.no/member_signup/ Grafene skalerer til å være synlige på små skjermer når det brukes. De blir mindre men dataen i selve diagrammene skalerer også så det som vises blir større. sioforeninger.no/chartviewhigham/ 40

83 Administrator for SiO For produkteier er det en egen administrasjonsside. Produkteier er med i en egen forening (SiO) så de også lett kan se hvordan systemet ser ut for brukerne, denne siden kan de enkelt komme seg til via administrasjonsgrensesnittet. De vanlige foreningsbrukerne har ikke tilgang til administrasjonsgrensesnittet, for å ha tilgang trenger man en spesiell konto som har superbrukerrettigheter. Med administrasjonssiden kan man se og endre alle administratorer for foreningssidene, hendelser i kalenderen, tekst om foreningene og foreningsnavn. sioforeninger.no/admin/ Administrasjonssiden lar også SiO se hvor mange medlemmer hver forening har. sioforeninger.no/admin/member/associationsummary/ 41

84 Sikkerhet Autentisering «Django» har en egen autentisering system som kommer med rammeverket som er mer robust enn å gå for en egen versjon bygget fra bunn. Den kommer med funksjonaliteter som: Rettigheter: Hvilken rolle en bruker blir gitt ut ifra flagg som blir satt; «is_superuser», «is_staff» og «is_active». Skjermdump fra tabell vist i DataGrip Grupper: Brukere kan deles inn ut ifra hvilke rettigheter de har. Passord hashing system. Begrense adgang til ulike deler av nettside. Ved å hindre ukjente fra å få aksess til deler av siden via URL har «Django» en dekoratør for å kunne pakke inn enkelte klasser eller metoder. Dekoratøren som vises til høyre anvendes i alle ulike klasser/metoder som gir aksess til ulike sider. I motsetning til dekoratøren under som brukes i «Generic views». Skjermdump fra PyCharm 42

85 Session Django følger med en session løsning, men denne går litt lengere enn vi ønsker. Her var det også vanskeligere å kontrollere lengden til hver session etc, ved å endre til en annen modul kan vi og gjøre at når du restarter maskinen må du skrive inn brukernavn og passord på nytt. Den nye modulen gav oss langt mer frihet. Skjermdump av session Dette var en løsning som passet godt inn i vårt system i motsetning til å være avhengig av den ferdig konfigurerte session som rammeverket tilbyr, den nye session modulen gir også lengere utløpstid. Skjermdump fra session tabellen vist i DataGrip 43

86 Glemt passord Glemt passord funksjonalisten var noe både vi og arbeidsgiver så på som viktig. Vi ville implementere denne tidlig men trengte en stabil epostløsning først. Etter å ha utsatt utviklingen av funksjonaliteten noe har vi nå en fungerende reset passord knapp, denne er tilgjengelige fra forsiden og sender en lenke der registrerte brukere kan endre passord via epost. sioforeninger.no/password_reset/ Det er lagt til ekstra knapper for å gjøre det lettere for brukere å navigere seg i tilfelle det er skrevet inn en feil eller at instruksjonene for å lage nytt passord ikke er mottatt. sioforeninger.no/password_reset/ 44

87 Under vises mottakelse av instruksjoner for endring av passord. 45

88 Når linken klikkes åpnes en side der man kan lage ett nytt passord, med denne siden kan man kun lage ett nytt passord en gang. Hvis bruker skriver inn feil passord vil valideringen si ifra til bruker som vist under. 46

89 Da kan det nye passordet brukes og logge seg inn i systemet. Utfordringer Siden dette var et nytt rammeverk og språk tok det tid å komme seg inn i rytmen for hvordan de er bygget opp og samspillet mellom de forskjellige delene i «Django». Valget av rammeverk til grafene gjorde utviklingen videre vanskelig, vi viser grafer med «Charts.js», som ikke har den beste integrasjonen med «Django». Vi fikk gode resultater med rammeverket men da vi prøvde andre datatyper støtte vi på problemer. Selv da vi prøvde å følge eksempler i dokumentasjon til punkt og prikke, se eksempelet illustrert i bildet vedsiden av for ett eksempel som illustrere problemene vi møtte. Etter flere forsøk på å bruke Charts.js forsøkte vi oss på ett annet rammeverk kalt Highchart. Vi støtte på noen problemer i dette også men implementeringen gikk mye lettere, det gav oss også utvidet funksjonalitet som mulighet til å laste ned bilder og PDF-filer av grafer. Skjermdump av feilen i implementering av " Chart.js " 47

90 C. Teknisk ordbok - begrepsavklaring Ord Betydning Dynamisk Evnen til å tilpasse arbeidsmetoden til endringer. arbeidsmetodikk Resultatmål Hva prosjektet skal resultere i. Effektmål Scrum Migration Templating Routing Rammeverk Beskjeftigelse Semistrukturertm etode Web applikasjon Kravspesifikasjon Jetbrains Bug Debugger Enhetstesting Versjonskontroll Gantdiagram Milepæler Transaksjonelt relasjons-basert databasesystem API IP-adresse Ønsket effekt prosjektet skal ha. Rammeverk for utvikling av komplekse informasjonssystemer. Delt opp i «Product backlog», «Sprint Backlog», «sprinter» og fungerende inkrementer av systemet. En overføring av data eller kildekode. Gjerne i sammenheng med versjonskontroll. Templating vil si å bruke ferdige fungerende deler av et system. Delegere nettverks trafikk gjennom ønsket porter o.l. Hoved virke eller det man bruker mest tid på. En intervjumetode som er en blanding av strukturert og ustrukturert metode. Et program som kan kjøres i en nettleser. Et begrep som fastsetter undersøkelse, avgrensing og definisjon av et nytt system. Jetbrains er et IT selskap som utvikler programvare for utviklere. En feil som er i systemet. Et hjelpemiddel for logging, fining eller begrensing av en bug. Testkonsept på lav nivå. Tester mot enkelte biter av kildekoden. Et system som holder oversikt over endringer i filer. Et diagram for prosjektplanlegging over tid. Spesifikke delmål i en utvikling. Oftest funksjonelle mål. Et databasesystem som gir økt kvalitetssikring ved at om en feil finnes, går databasen automatisk tilbake til siste fungerende versjon. Applikasjonsprogrammeringsgrensesnitt omhandler kommunikasjon og endringer basert på andre systemer. En unik adresse som hver enkelt enhet har. 48

91 SPAM liste Skalerbar MVT MVC Moduler Branches Deployment.zip BDD Virtualenv PIP RSA nøkkel Brannmur VPS NIX-1 En liste over svartelistede mailadresser som automatisk legges i en egen «spam mappe». Tilpasningsdyktig for større trafikk eller bruk. Model View Template er et designmønster å programmere og sortere filer i et system etter. I motsetning til den mer kjente MVC håndterer Django selv Controller. Model View Controller. Designmønster basert på adskillig av modellen, kontrolleren og «viewet». Hver del av applikasjonen vår er en egen uavhengig modul som fungerer for seg selv, det ferdige produktet er altså en sammensetning av moduler som snakker sammen. Ulike greener hvor utviklingen finner sted på /lagres. En aktiv fungerende utgave av systemet som er under utvikling. En filtype for krypterte filer. Gir bedre sikkerhet og tar mindre plass. Behaviour-Driven Development, en testmetodikk laget for å brukes både av kodere og ikke-tekniske testere. Her menes Python Virtualenv, ett virtuelt miljø som lar oss lagre andre Python-pakker og konfigurasjon enn hva som er globalt i opperativsystemet. Ett pakkebehandlingsprogram for Python, pip lar oss installere, slette og oppdater Python pip-pakker. Pip brukes for å installere Django-moduler. En kryptert nøkkel som vi bruker til å logge på servere, disse er også passordbeskyttet. RSA nøkler er mye lengere enn vanlige passord og ville vært svært upraktisk og skrive inn ved login, derfor lagres de som nøkler. Disse nøklene øker sikkerheten til serverne betraktelig. Ett program som stopper ikke-tillatt nett-trafikk over nettet og kan stoppe flere typer angrep. Virtual Private Server, en virtuell server hvor som ett opperativsystem vi kan bruke som en normal server. VPS gir oss full tilgang til hele opperatvissystemet og lar oss konfigurere det som vi vil. VPSene vi bruker følger med konfigurasjon med IP-adresser mot internet. Norwegian Internet exchange-1, dette er ett sentralt aksesspunkt drevet av UiO som gir raskt og stabilt nett ut og inn av Norge. 49

92 NIX-2 A-records ORM WSGI PHP Failback OpenSSL PHP-fpm Commits Git Enhetstest Integrasjonstest Norwegian Internet exchange-2, dette er ett sentralt aksesspunkt drevet av UiO som gir raskt og stabilt nett ut og inn av Norge. En A-Record brukes til å lenke ett domene til en ip-adresse. I vårt tilfelle er dette heartbeat-serveren. Object-relational mapping, ett språk vi bruker for å kode databasen. Dette språket er uavhengig av hvilken database som brukes så lenge databasen er støttet, man skriver koden så genereres det SQL/NoSQL for den databasemotoren man bruker. Web Server Gateway Interface, en spesifikasjon for å kunne kommunisere mellom web servere og Python-kode. WSGI gir ett rammeverk for hvordan kode skal generes og overføres. Det finnes mange Python serverapplikasjoner bassert på WSGI-spesifikasjon. Ett scriptingspråk laget for bruk på serverside, PHP lar oss raskt utvikle de tjenestene vi trenger og fungerer med svært lite konfigurasjon på Linuxserver. Failback brukes for å gjennoprette drift når noe går galt, i vårt tilfelle skifter det til en annen server når primærserveren går ned. OpenSSL er ett krypteringsbilbiotek som brukes for å sikre kommunikasjon mellom maskiner på ett nettverk. Brukes til å gjøre om PHP-kode til HTML og CSS leselig av Nginx webserveren. Med en commit laster vi opp kildekode til Git med en commit-melding om endringene, commits blir ikke synlig i en Git bracnh før den pushes (dyttes opp). Ett versjonskontrollsystem som også gir historikk, det lar oss enklere arbeide på kildekoden sammen. Enhetstester er en måte å teste kode, det skrives rett i kildekoden og kan kjøres så ofte vi vil. Enhetstester re raske og designet for å teste enkle parter av gangen, ett eksempel kan være en enhetstest som prøver å legge til en bruker, går det bra får vi ett grønt symbol i PyCharm, går det ikke får vi ett rødt. Med integrasjonstesting tester vi hvordan forskjellige moduler i systemet snakker sammen, disse skrives etter integrasjonsstestene som verifiserer at 50

93 Akseptansetest Gherkin Cucumber Bootstrap modulene fungerer i seg selv. Integrasjonstesten verifiserer at kommunikasjonen mellom dem fungerer som det skal. I akseptansekrav tester vi om applikasjonen oppfyller de kravene satt i kravspesifikasjonen. Akspetansetesting krever kodeforståelse og gjøres av både arbeidsgiver og av gruppen. Gherkin er ett språk laget for å bli forstått av Cucumber, det kan tenkes på som en utvidet versjon av Cucumber som ble laget for å løse noen av problemene i Cucumber. Cucumber er ett verktøy laget for å lage automatiserte akseptansetester, disse kan leses av ikke-tekniske brukere men kan også kjøres automatisk og utføre lavere nivå tester. Et rammeverk som har ferdigstilte tilpasninger for utarbeidelse av utseende til en nettside. 51

94 D. Dagbok Møte med nestleder Mike Fürstenberg angående hovedprosjekt for SiO Møte med SiO-ledelsen for enighet og forståelse av hovedprosjektet Møte med Torunn Gjester om innspill og råd for igangsetting av bachelor-prosjektet Møte med Kristian hvor vi gikk gjennom kravspesifikasjoner og sendte inn forslag til innspill av krav til ulike foreninger for å samle inn ideer. Intervju med herlige Peter som kom med flotte innspill til utvikling av funksjonalitet som er ønskelig. Andreas kom senere Intervju med Tom Remi om innspill til kravspek (Andreas og Jamal). Kristian jobbet Møte om videre arbeid av kravspek og sette i gang med user stories. Avtale møte med veilder og oppdragsgiver. Samt sende ut forslag om kontrakt signering Oppmøte for videre arbeid av kravspekk. Møte med Dennis og ment et møte med OTS men ble av noe grunn ikke noe av da Kristian jobbet og vi visste ikke hvem vi skulle ha møte med Møte med OTS der vi hørte deres innspill til håndtering av dokument- og medlemsregistrering. 52

95 Videre arbeid med kravspek og sette seg inn programmeringsspråket Python. Jobber hjemmefra og uviss hva de andre gjør på kontoret Møte med Hassan Ismail og fikk innspill til oppsett av e-post system. Laget arbeidsplan og fremtidsplan. Møte med veileder og arbeidsgiver for bla. signering av kontrakt Møte med Torunn med snakk om oppsett av server og søke om å benytte epost-systemet til hioa. Samt veiledet oss videre med arbeid i kravspek (være mer spesifikk) og anbefalte oss å lage user stories/use cases. I tillegg møte med SiO for kontraktsignering og videre arbeid hvor vi får møte IT-direktør av SiO. Det skal avtales et møte der vi presenterer vårt prosjektarbeid. Videre arbeidet vi med forprosjekt-rapporten Vi har laget skisser og prototyper for nettsiden. Forberedte oss for møte med IT-direktør i SiO som tar plass på onsdag. Samt laget presentasjon for møtet på onsdag Møte med IT-direktør Torkild der vi snakket om mulige løsninger for hovedprosjektet som de skal lufte videre til BEKK og forhøre seg om valgmuligheter det skal foretas Møte med Torunn hvor vi snakket om møte vi hadde i går med IT-direktør og veien videre forprosjektarbeidet. Torunn ville at vi skulle komme konkret i gang med opprettelse av databaser, ER-model og use caser. Samt starte med å skrive i prosessrapporten slik at hun klart får se om vi er på riktig spor. Dette vil gi henne en mer oversikt og kan gi mer innspill til hva som må forbedres osv. 53

96 Møte med BEKK, Mike og Torkild angående tilgang til database-tilgang og verktøy som brukes av BEKK. BEKK var villig til å gi oss tilgang der de legger av et område for oss å arbeide medderes database. Fikk dessverre ikke til en avtale med BIT om E-post løsning så må høre med Torunn hvis det er mulig for at HiOA er villig til å dekke kostnader for å leie et slikt system Møte med Torunn angående fremdrift for arbeidet og fikk sett på modellene i ER og use case.fikk råd og tips som ga mersmak av ideer til videre arbeid. E-post løsning kunne vi få til med en gratis software av en SMTP som Amir kan bistå oss med hjelp Jobber individuelt med koding og oppsett av database. Kristian forhørte seg med Laurence om tilbud av server. Mulighet for å benytte Amazon sitt gratis tilbud for studenter Møte med Torunn der vi fortalte om oppsettet av databasen er klar. Ble rådet til å sette i gang med kodinga og samtidig dokumentere det som blir gjort. Skal få til noen eksemplarer av websidens utseende Møte med oppgavefordeling og oppsett av databasen mot vår egen server vi skal jobbe mot. Postgresql var ikke så samarbeidsvillig med ubuntu server ved oppsett og måtte finne andre mulighet til å sette opp Møte med Mike og Linn der vi fikk se funksjonaliteten som skal implementeres med registrering av foreninger og antall medlemmer. Vi skal kunne koble opp med dette systemet med hensyntil antall medlemmer som blir registrert i ulike foreninger. 54

97 Møte med Torunn i dag ble det tatt opp om møten som foregikk dagen før og oppdatering av fremgang. Hun anbefalte oss å jobbe til faste tider slik at vi er synkronisert med arbeidet Felles arbeid på kontoret hvor vi videre utvikler nettsiden. Andreas måtte fikse på server siden den oppførte seg rart. Jamal og Kristian jobbet videre med nettsiden Felles arbeid på kontoret hvor vi videre utvikler nettsiden. Andreas måtte fikse på server siden den oppførte seg rart. Jamal og Kristian jobbet videre med nettsiden Felles arbeid på kontoret hvor vi videre utvikler nettsiden. Andreas måtte fikse på server siden den oppførte seg rart. Jamal og Kristian jobbet videre med nettsiden Felles økt med en oppsummering av status til nå og plan for videre arbeid. Her skal det kodes videre slik at kalender og muligens epost løsning hvis tiden er på vår side. Rapporten skal forbedres etter konstruktiv tilbakemelding fra Torunn Møte med Tor hvor vi snakket om status så langt og videre prosess med testing og rapportskriving Fellesarbeid med koding og støtet på STOR problem med migrering av prosjektet fra GIT da det måtte gjøres en del endringer på konfigurasjoner av repository og installasjon av maskin Møte med Mike der han fikk sett framgangen så langt. Fornøyd var han og hadde ønsker som han ville legget til. Diskuterte hvordan vi ser for oss prototypen skal settes inn med resten av systemet til SiO. Avtalte møte neste uke. 55

98 Møte med Torunn hvor vi viste frem prosessen så langt av nettsiden og var fornøyd med arbeidet så langt. Viktig å fokusere på rapporten fra nå og inn mot sluttfasen. Jeg fokusere på programmering mens resten fokuserer på å fylle inn rapporten slik at Torunn og jeg kan lese gjennom det som er skrevet. Gi innsyn på hva som kan forbedres og jobbe videre med rapporten Oppsummeringsmøte av arbeid som har blitt gjort og hva planen videre blir. Planlagt å kjøre Brukertesting etter påsken slik at brukere som skal anvende systemet får føle på hva som fungerer og ikke fungerer. Kristian skal jobbe videre med rapporten og invitere ulike foreninger til brukertest. Andreas jobber videre med mail slik at den vil fungere med systemet. Jamal jobber videre med å tette igjen sikkerhetshull og setter i gang med å integrasjons og system-teste Møte med Torunn hvor vi gikk gjennom rapporten. Vi fikk gode tips og råd av hva vi bør skrive om og hva som ikke bør være med videre i rapporten. Samt få til en løsning av der vi går gjennom rapporten samlet og få andre utenom fra gruppen til å lese. I tillegg hadde vi møte med Mike om forespørsel av liste over alle foreninger slik at vi kan legge til de i mottakerliste for . Der fikk vi RSS-feeds som vi kan bruke til å jobbe videre med. Var en ny gjennomgang av systemet der vi viste fram nye funksjonaliteter som han var tilfreds med og hadde noe ønsker som vi kunne implementere Etter vel overstått med litt avslapping i påsken med arbeid i mellomtiden var det tid for full Kjør med arbeid. Møte i dag om status foregående arbeid og fremtidig arbeid. Trenger å justere slik at de vil bli sendt via websiden. Mulig å legge til ekstra funksjonaliteter hvis tiden er innen rekkevidde. Videre arbeid med testing og skal igangsette full brukertesting der ulike foreninger skal kjenne på hvordan systemet fungerer i full produksjon. 56

99 Møte med Torunn angående rapporten som var litt forbedret siden sist men ikke gjort nok arbeid. Fikken tankevekker for hvor viktig det er med fokus i arbeid med rapporten da fristen nærmer seg med stormskritt. Det var noe problemer med at gruppemedlemmer ikke møtte opp i tide. Kristian føler at det ikke blir jobbet nok med rapporten til at han ikke kan gjøre noen forbedringer. Jamal har fokusert for det meste i programmering av web-appen som må allerede fra neste uke rette oppmerksomheten mot arbeid av rapporten. Tydelig forbedringer i sluttfasen må til slik at vi lander i mål. (Også gjennomført brukertest av nettsiden med en fra aksje-gruppen) Kristian og Jamal tok en felles gjennomgang av rapporten og bedret på de områdene som var viktig å fremheve. Andreas kom senere på dagen og jobbet videre med Møte med Torunn om videre arbeidsprosess med rapporten som hun var skuffet og sur over at det ikke var noe progresjon. Møte med Mike om implementering av prosjektet som skal føyes på serveren slik at de og andre foreninger kan teste web løsningen Felles møte for videre arbeidsprosess med rapporten. Vært en diskusjon om hva som bør være naturlig session-time for brukere. Laget ny design som reflekterer tilbakemeldinger fra brukertest som ble gjennomført sist. Teste mot WCAG for pekepinn om brukervennlighet. Andreas er syk og jobber hjemmefra Møte med Torunn hvor vi fikk tilbakemelding på hva som skal forbedres. Jamal jobber hjemmefra. Intet møte med SiO Innspurten er i gang og det nærmer seg mot slutten. Dette merkes med rapportskriving som tastes for harde livet. Tilbakemelding fra Torunn om hva om må utbedres og gjøres konsis. Egentlig siste veiledningsmøte i dag men Torunn har sagt seg villig til å være tilgjengelig inn mot fristen hvis det skulle være nødvendig. 57

100 Felles økt med arbeid av rapporten. Gjelder å strukturere alt arbeid som har blitt lagt ned gjennom hele prosjekt perioden. 58

101 E. Brukerhistorier Brukerhistorier skal gjenspeile faktiske handlinger som brukerne skal kunne gjennomføre og skaper et anvendt aspekt til kravspesifikasjonen. Vi har valgt å gjengi de ulike brukerhistoriene i skjermbilder som følger trinn for trinn hvordan en kan oppfylle disse scenarioene: 1. Som en del av foreningsstyret ønsker jeg å opprette en ny forening slik at jeg kan bruke administrasjonsløsningen SiO tilbyr. Fra innloggings siden trykker man på «Register new association» På neste side fører man inn ønsket foreningsnavn og trykker «Create association». 59

102 Deretter må man lage en admin for den nye organisasjonen. Men velger da organisasjonen admin har tilhørighet fra listen. Når all informasjonen er fylt inn trykker man på «Registrer new CoAdmin» 60

103 Deretter logger man seg inn med brukernavn og passord som nylig ble laget. Deretter blir man ledet til hovedsiden og kan sette i gang med bruken av systemet. Brukerhistorie fullført. 61

104 2. Som en del av foreningsstyret ønsker jeg å ha oversikt over alle antall medlemmer slik at jeg kan søke om midler. Fra hovedsiden navigerer man seg til «Statistics» På denne siden får man oversikt over flere data fra medlemsmassen. Den første som kommer er antall medlemmer og antall administratorer knyttet til foreningen. Lar man musen hvile over grafen får man tallene vist. 62

105 Eventuelt kan man laste ned grafene om man søker midler fra ander instanser som FriFond som vist under. Brukerhistorie fullført. 3. Som en del av foreningsstyret ønsker jeg å opprette arrangementer i kalender slik at mine administratorer har oversikt over kommende arrangementer. Fra navigeringssiden klikker man seg videre til kalender siden: 63

106 På kalender siden klikker man på ønsket dato øverst i hjørnet. Videre får man opp et arrangementsvindu hvor de ulike feltene er markert for hva de skal inneholde. 64

107 Deretter fyller man ut informasjon om hendelsen og trykker save. Hendelsen er nå lagret og kan sees av alle andre med samme tilhørighet til foreningen. Klikker man seg videre inn på arrangementet får man informasjonen presentert slik som på bildet til høyre. Brukerhistorie fullført. 65

108 4. Som en del av foreningsstyret ønsker jeg å søke opp medlemmer slik at jeg kan effektiv se om personen er medlem i foreningen. Fra hovedsiden navigerer man til «Members». På medlemssiden blir man presentert med en liste over medlemmer. Derfra skriver jeg inn navnet på medlemmet og trykker søke-ikonet. 66

109 Deretter får jeg medlemmet presentert med tilhørende informasjon. Brukerhistorie fullført. 5. Som en del av foreningsstyret ønsker jeg å registrere medlemmer slik at jeg kan øke medlemsmassen til foreningen. Fra hovedsiden navigerer man til «Members». 67

110 Deretter klikker man på «New member». På neste siden fører man inn informasjonen om medlemmet. På «Date of birth» og «End date» kan man enten skrive inn direkte eller benytte seg av datovelgeren fra menyen. 68

111 Etter informasjonen er fylt inn trykker man på «Register new member». Medlemmet er nå lagt til og man får bekreftelse. Brukerhistorie fullført. 69

112 6. Som en del av foreningsstyret ønsker jeg å opprette nye administratorer med forskjellige roller i foreningen slik at de kan få aksess rettigheter til CRUD (create, read, update and delete). Fra hovedsiden navigerer man seg til «Administrator»-siden. På «Admins» siden trykker man seg videre til «New Admin» 70

113 Deretter fyller man inn informasjonen om den nye administratoren samt rolle i foreningen og trykker «Register new admin». Når dette er gjort får man en bekreftelse og blir sendt tilbake til oversikten over administratorer og deres rolle. Brukerhistorie fullført. 71

114 7. Som en del av foreningsstyret ønsker jeg å få ut statistikk og grafer slik at jeg har beslutningsgrunnlag for eventuelle satsninger. Fra hovedsiden navigerer man seg til «Statistics». På følgende side får man muligheter til å se ulike grafer og statistisk informasjon om medlemsbasen. Da velger man ønsket graf fra «Drop down» menyen og får ønsket informasjon for beslutningsgrunnlag. Brukerhistorie fullført. 72

115 8. Som en del av foreningsstyret ønsker jeg å sende e-post slik at alle medlemmer får med seg viktig informasjon som foregår i foreningen. Merk: Denne funksjonaliteten er fungerende, men vi har ikke mestret muligheten til å sende mail direkte til alle medlemmer som er registrert. Videre utvikling vil finne sted og en løsning vil komme på plass. Man navigerer seg til mail siden fra hovedmenyen. På siden fyller man ut informasjonen man ønsker å dele med sine medlemmer. Her er det også mulighet for å legge til kopier, eventuelt blinde kopier. Deretter trykker man «Send». Brukerhistorie fullført. 73

116 9. Som en del av foreningsstyret ønsker jeg å endre mitt passord slik at ingen andre enn meg får tilgang til siden. Fra hovedsiden trykker man på sin egen bruker øverst til høyre og velger «Change password». Deretter fyller man inn det gamle passordet og ønsket nytt passord. Deretter får man bekreftet endringen eller får eventuelt beskjed om brukerfeil som har oppstått. Brukerhistorie fullført. 74

117 10. Som en del av foreningsstyret ønsker jeg å endre mitt passord slik at jeg kan få tilgang til siden igjen ettersom jeg har glemt mitt passord. Fra innloggingssiden trykker man på «Forgot your password?». På følgende side skriver man inn sin mailadresse som er koblet opp mot sin bruker til siden og trykker «Reset My Password» Deretter får man instrukser på hvordan man skal få frem. En mail er blitt sent til tilhørende epost med klare instruksjoner. 75

118 Mailen ser da følgende ut med tilhørende lenke for videre steg for endring av passord. Man klikker da på lenken og blir ledet videre til siden. Deretter blir man ledet til en side for endring av passord og trykker deretter «Change My Password» Deretter får man en bekreftelse på endringen og kan trykke seg tilbake til log inn siden og logge inn med nytt passord. Brukerhistorie fullført. 76

119 11. Som SiO ansatt ønsker jeg å ha redigeringsrettigheter på nettsiden slik at jeg kan fjerne eventuelle feilaktige administratorer eller foreninger. Som SiO ansatt har man rettigheter til å aksessere admin siden til Django prosjektet. Første steg er å logge inn på sin SiO bruker med rettigheter på /admin. Man blir da ledet til admin siden og kan navigere seg videre til «Administrators» Herfra kan man slette eventuelle feilaktige administratorer ved å markere en admin og velge «delete selected administrator». 77

120 Eventuelt kan man gå tilbake og velge «Associations» for å komme til muligheten for å fjerne foreninger for siden. Herfra kan man markere den ønskede foreningen og velge «Delete selected associations» fra dropdown menyen. Brukerhistorie fullført. 78

121 12. Som Admin ønsker jeg å endre informasjon om et medlem slik at jeg at jeg har oppdatert informasjon om medlemmet. Fra «Members» siden finner man ønsket medlem og trykker «Update» til høyre. 79

122 Deretter endrer man ønsket informasjon om medlemmet og trykker «Update member». Deretter blir man ledet tilbake til oversikten over medlemmer med en bekreftelse om at endringen har funnet sted. Brukerhistorie fullført. 80

123 13. Som Admin ønsker jeg å slette en ikke-aktivt medlem slik at jeg har bedre oversikt over aktive medlemmer. Fra medlemssiden finne man ønsket medlem og velger «Delete». Deretter får man spørsmål om å bekrefte ønsket handling hvor man da velger «Yes, delete». Da vil man bli ledet tilbake til medlemsoversikten og får bekreftet at ønsket handling er gjennomført. Brukerhistorie fullført. 81

124 14. Som Admin ønsker jeg å ha en oversikt over alle administratorer (styret) slik at jeg kan se hvem som er med i styret og har tilgang til siden. 82

125 Her trenger man bare å navigere seg til «Admins» siden og får da presentert oversikt over gjellende administratorer. Brukerhistorie fullført. 15. Som Admin ønsker jeg å endre informasjon om meg selv slik at jeg har riktige opplysningene om meg selv. Fra admins siden velger man «Update» og blir ledet videre. 83

126 Man utfører deretter ønsket endring og trykker på «Update Admin». Oppdateringen har da funnet sted og man får dette bekreftet. Brukerhistorie fullført. 84

127 16. Som Admin ønsker jeg å slette en administrator slik at kun dem som skal ha tilgang har det. Fra admin siden finner man ønsket admin og velger «Delete». På lik basis som medlemmer får man spørsmål om å bekrefte valget og velger da «Yes, delete». 85

128 Deretter får man en bekreftelse på at handlingen er utført og blir ledet tilbake til «Admins» siden. Brukerhistorie fullført. 86

129 F. SiO s tilbakemelding/attest Medlemsregister for frivillige studentforeninger Om prosjektet Kristian Munter Simonsen, Andreas Jacobsen og Jamal Lakbir tok kontakt med Studentsamskipnaden i Oslo og Akershus (SiO) ved SiO Foreninger høsten 2016 med en ide om å utvikle et medlemsregister for frivillige studentorganisasjoner. Dette syntes vi i SiO Foreninger var en spennende oppgave og gikk raskt i gang med å skrive en avtale om bacheloroppgave med studentene. Innledende avklaringer innledningsvis brukte man tid på å avklare hvilke tilganger studentene trengte for å skrive oppgaven. Det ble avgjort at studentene skulle kunne skrive på egne maskiner med tilgang til programkoden på SiO Foreningers øvrige nettsider og style sheets slik at medlemsregisteret skulle kunne utvikles med utseende fra SiOs øvrige nettsider. Koordinering underveis Studentene utførte selv brukerintervjuer med studentforeninger for å kartlegge foreningenes behov. Videre har SiO Foreninger hatt flere avklaringsmøter med studentene for å gjennomgå fremdrift og funksjonalitet fra SiO Foreningers side. Koordineringsmøtene ble gjennomført 1-2 ganger i måneden. Videre ble også en del av tilbakemeldingene og avklaringene gjennomført per epost. Gjennomføring Studentene har, basert på tilbakemeldingene fra SiO Foreninger og studentforeningene, laget et fullt operativt medlemsregister. Alle ønskene fra foreningene og SiO Foreninger har det ikke blitt tid til å utvikle, men de tingene som er utviklet har blitt valgt på bakgrunn av tilbakemeldinger fra studentforeningene samt en prioritering av SiO Foreninger. Systemet gir studentforeningene et medlemsregister med funksjonalitet for å registrere nye medlemmer, samt muligheten til å finne og endre medlemmer som allerede er registrerte. Systemet gir i tillegg brukerne et enkelt rapporteringsverktøy, en arrangementskalender, samt muligheten til å sende ut epost fra systemet. Vi i SiO Foreninger er svært tilfreds med den utviklingen studentene har gjort, og vil på sikt se på muligheten for å implementere denne funksjonaliteten i den øvrige funksjonaliteten vi har for studentforeninger i Oslo og Akershus. Om SiO Foreninger SiO Foreninger er en avdeling i Studentsamskipnaden i Oslo. SiO Foreningers arbeidsfelt omfatter bl.a. informasjonsvirksomhet samt støttetiltak for ca. 450 studentforeninger ved universitetet og høgskolene som er med i SiO. En del av dette arbeidet er utvikling av digitale tjenester og verktøy for å lette den administrative arbeidsbyrden for aktive i studentforeninger. Mike Fürstenberg, Faglig leder i SiO Foreninger 87

130 G. Brukerveiledning Fra SiO Foreninger-perspektiv Brukerveiledning fra SiO Perspektiv Hele nettsiden er passordbeskyttet, for å få tilgang trengs ett spesifikt brukernavn og passord. Om siden skal brukes av foreninger vil dette fjernes. Autentiseringen er gjort på webservernivå, 5 feile brukernavn og passord resulterer i at du må oppdatere siden og prøve på nytt. Brukernavn for å se systemet er «sio», passordet er «kebabsaus». Har du alt logget inn på sioforeninger.no kommer ikke denne meldingen opp. sioforeninger.no/admin For å logge på administrasjonsgrensesnittet går vi til adressen «sioforeninger.no/admin». Er du allerede logget inn med en konto som har staff-rettigheter kommer du rett inn, hvis ikke må du logge på med en konto med de korrekte rettighetene. Er du ikke logget inn på noen konto kommer du til en login skjerm, her har vi skrevet inn adressen mens vi var logget på en konto som ikke hadde administratorrettigheter. sioforeninger.no/admin/ 88

131 Logg inn med en konto som har staff-rettigheter. Når vi har logget inn kommer vi til SiO administrasjonsgrensesnittet. sioforeninger.no/admin/ I SiO administration kan SiO se alle administratorene i systemet, alle eventsene registrert i alles kalender, alle foreningenes sammendrag og alle foreningene. Om vi gjør noe i admin grensesnittet kommer det opp under «Recent actions» sioforeninger.no/admin/ Administrasjonsgrensesnittet gir ingen tilgang til å hverken se eller endre på individuelle medlemmer i foreninger. Det gir dog SiO mulighet til å se og endre på alle administratorene og all annen informasjon de har tilgang til i grensesnittet. Vi har fått en epost om at admin brukeren sam_vimes har glemt passordet sitt og vil ha ett nytt passord. Først klikker vi på «Administrators», så finner vi «sam_vimes» enten ved å se igjennom listen manuelt eller bruke søkeboksen. 89

132 sioforeninger.no/admin/coadmin/administrator/?q=sam_vimes Så klikker vi på den blå hyperlenken med sam_vimes skrevet i seg, navnet vi søkte etter. Nå kommer vi til en informasjonsside om brukeren sam_vimes, her kan vi se når brukeren sist var logget inn, når brukeren ble medlem, git brukeren utvidede tillatelser og endre all informasjon om brukeren. 90

133 For å endre passord for administrasjonsbrukeren må vi trykke på «this form» lenken under passord hash dataen som vises. Så blir vi tatt til en egen side der passord kan lages, det er satt krav til passord så de holder ett minimumsnivå av sikkerhet. Her skriver vi inn det nye passordet og klikker «CHANGE PASSWORD». Vi kommer så tilbake til siden til brukeren med en grønn melding som sier at passordet har blitt endret. Om vi ønsker å se alt som har blitt gjort med brukeren via administrasjonsgrensesnittet kan vi trykke på «History» på siden brukeren er på. For å slette en administrator går vi tilbake til administratorsiden og velger en bruker, så velger vi «Delete selected admin» fra drop-down action menyen. 91

134 sioforeninger.no/admin/coadmin/administrator/ Så klikker vi på «Go» vediden av «Actions» drop-down menyen for å utføre handlingen, så blir vi tatt til en konfirmasjonsside. sioforeninger.no/admin/coadmin/administrator/ Klikker vi på «Yes, I m sure» kommer vi tilbake til siden som viser alle administratorene med en grønn tilbakemelding om at administratoren har blitt slettet. sioforeninger.no/admin/coadmin/administrator/ Om vi ønsker å legge til en ny superbruker som SiO kan bruke må vi først lage en ny administrator. Dette gjør vi fra «Administratorssiden» vi er på, klikk «ADD ADMINISTRATOR +» knappen sioforeninger.no/admin/coadmin/administrator/ 92

135 For å legge til en administrator trenger vi en forening for administratoren, for denne brukeren nytter vi oss av foreningen SiO. Ikke legg til administratorer i faktiske studentforeninger da dette vil telle på statistikken deres. Ifra «Association» feltet hvor vi velger forening kan vi og legge til nye foreninger eller endre på eksisterende foreningsnavn. sioforeninger.no/admin/coadmin/administrator/add/ Om vi bare skulle hatt en vanlig administrator hadde det holdt å trykke «Save», men siden vi gi denne brukeren superrettigheter går vi videre med å klikke «Save and continue editing». Nå kommer vi til «Edit member» siden vi er kjent med fra tidligere. Her kan vi endre å gi Superuser status om vi ønsker at brukeren skal kunne gjøre alt, eller «Staff» om vi ønsker å bare vi noen spesifikke rettigheter. Med bruk av «Staff» kan vi manuelt fra en liste gi og fjerne rettigheter, mens superuser har alle rettighetene fra listen. sioforeninger.no/admin/coadmin/administrator/21/change/ Så scroller vi til bunnen av side nog velger SAVE, da blir vi tatt tilbake til administrasjonssiden med en grønn melding om at endringene er gjort. 93

136 sioforeninger.no/admin/coadmin/administrator/ For å se hvor mange medlemmer hver forening har går vi tilbake til administrasjonssiden forside ved å klikke den gule store «SiO administrasjon» teksten i topp baren. Denne er tilgengelig uansett hvor du er på admin siden. Fra startsiden klikker vi på «Association summary» sioforeninger.no/admin/ 94

137 Ved å klikke på «Association Summary» kommer vi til en side som viser alle foreningene og deres medlemstall. Figure 1sioforeninger.no/admin/member/associationsummary/ Om ett foreningsnavn skal endres går vi tilbake til forsiden ved å trykke på den gule «SiO administration» tekst i topp-baren igjen. Så velger vi «Associations». sioforeninger.no/admin/member/association/ Her kan vi velge en forening ved å klikke på den, om det er mange foreninger kan vi søke etter foreninger med søkebaren. Herifra kan vi også slette foreninger på samme måte som vi sletter administratorer. 95

138 For å endre navn klikker vi på foreningsnavnet, så kommer vi til den foreningsspesifikke siden. Her kan vi skrive inn ett nytt foreningsnavn og klikke på «SAVE», om ønsket kan vi også slette foreningen fra denne siden. sioforeninger.no/admin/member/association/7/change/ Når vi har trykket save kommer en grønn boks under topp baren med det nye foreningsnavnet o gen melding om at forening har blitt endret. sioforeninger.no/admin/member/association/ Fra denne siden kan vi også legge til nye foreninger, disse kan alle administratorene bli medlem av, for å legge til en ny forening klikker vi på «ADD ASSOCIATION +» knappen i høyre hjørne. sioforeninger.no/admin/member/association/ Når vi har klikket på ADD ASSOCIATION + kan vi skrive inn foreningsnavn der det står «Asoc name:» og klikke «SAVE». sioforeninger.no/admin/member/association/add/ Etter å klikket SAVE kommer vi tilbake til foreningsoversikten med melding om at foreningen er lagt til. 96

139 sioforeninger.no/admin/member/association/ For å endre passord klikker du på «CHANGE PASSWORD» til høyre i topp meny-baren. Denne er synlig uansett hvor på siden du er. Skriv inn gammelt passord og nytt passord for å endre passordet til brukeren. sioforeninger.no/admin/password_change/ Siden hver staff og superbruker også er medlem av en forening kan vi se foreningssiden knyttet til brukeren ved å klikke på VIEW SITE til høyre i topp meny-baren. Etter å ha klikket kan vi se hovedsiden, for å komme oss tilbake må vi skrive «sioforeninger.no/admin» i URL-baren. 97

140 sioforeninger.no 98

141 Fra foreningsperspektiv Hele nettsiden er passordbeskyttet, for å få tilgang trengs ett spesifikt brukernavn og passord. Om siden skal brukes av foreninger vil dette fjernes. Autentiseringen er gjort på webservernivå, 5 feile brukernavn og passord resulterer i at du må oppdatere siden og prøve på nytt. Brukernavn for å se systemet er «sio», passordet er «kebabsaus». sioforeninger.no Ved rett brukernanv og passord kommer man til login siden. Denne vil endres om systemet blir faktisk brukt slik at foreninger ikke lenger selv skal kunne registrere en ny forening, men foreningene heller hentes fra SiO sin database. sioforeninger.no 99

142 Her kan du logge inn med eksisterende brukere eller lage brukere eller foreninger. Hver bruker må være koblet opp mot en forening så foreningen må eksistere før brukeren. For å lage en ny forening trykker Knappene «Register new admin» og «Register new association» er bare for bruk under de tidlige fasene for SiO, om systemet skal brukes av foreninger skal denne dataen hentes fra SiO sine internsystemer. Dette vil gi insentiver til foreningene om å oppdatere styrelistet da bare de listet i styret på SiO sine sider vil ha tilgang, også kun foreninger som har profil på SiO sine sider vil kunne få brukere. Om foreningen din ikke eksisterer i systemet alt må du registrere den som en ny forening først ved å trykke på «Register new associatoin», her trengs kun foreningsnavnet å skrives inn. Når du har registrert en ny forening genereres all datastrukturen nødvendig automatisk av systemet. sioforeninger.no/signup/ Etter at vi har registrert en ny forening kommer vi automatisk tilbake til forsiden. 100

143 Nå som vi har registrert foreningen vår kan vi registrere en administrator for foreningen, dette gjør vi ved å trykke på «Register new admin», epost og brukernavn må være unikt. Hver administrator får en bruker-id gitt til seg selv, administratoren kan ikke selv se dette IDnummeret. sioforeninger.no/signup/ Når vi har opprettet en co-admin kan vi logge inn med brukernavnet og passordet vi lagde, da blir vi tatt til forsiden hvor foreningsnavn vises. 101

144 sioforeninger.no/dashboard/ På startsiden kan vi se topp meny-baren og en meny i hovedskjermen. Disse går til de samme sidene, men topp meny-baren er synlig ifra alle sidene. Nå kan vi prøve å legge til ett nytt medlem, klikk på «Members» knappen enten i topp-menyen eller menyen midt på siden. Da blir vi tatt til «Member overiew» siden, jeg kan vi se eksiterende medlemmer, fjerne medlemmer, endre medlemmer og legge til medlemmer. Så klikker vi på «Members» sioforeninger.no/dashboard/ 102

145 sioforeninger.no/member_overview/ Dette tar oss til «Add members» siden, jeg må vi fylle ut fornavn, etternavn, epost, kjønn, fødselsdato og når medlemskapet skal slutte. Deler av denne datoen vil senere brukes i statistikk delen, skrives noe feil kan ett medlem enkelt endres på senere. sioforeninger.no/member_signup/ 103

146 Når vi klikker på «Register new member» blir vi tatt tilbake til member overview siden med en melding om at medlemmet er lagt til. Vi kan også se medlemmet nå. sioforeninger.no/member_overview/ Om vi ønsker å slette medlemmet trykker vi på «Delete», om vi ønsker å endre medlemmet trykker vi på «Update». Update vil gi deg en side der du kan endre dataen foreningen har skrevet inn om medlemmet, men begynnelsesdato og medlems ID som blir satt av systemet blir det samme. sioforeninger.no/member_edit/22 (det siste tallet er medlemsnummer) 104

147 Når vi har oppdatert ett medlem kommer vi tilbake til medlemssiden med en melding om at medlemmet har blitt oppdatert. sioforeninger.no/member_overview/ Før vi ser på statistikk kan det være greit å legge til noen flere medlemmer, om du har medlemmer i foreningen din legger du til disse. I dette tilfelle legger jeg bare til noen testmedlemmer. Vi legger først til noen vanlige medlemmer så noen administratorer som da vil være styremedlemmer eller medlemmer delegert tilgang. sioforeninger.no/member_overview/ 105

148 For å legge til administratorer trykker vi på «Administrators» i topp meny-baren. sioforeninger.no/member_overview/ Administratorgrensesnittet fungerer som meldingsgrensesnittet men her lager man nye administratorer. Hver administrator skal være ett styremedlem eller representere plassen til ett styremedlem, passord kan deles om foreningen ønsker. Dette er så foreningen får rett statistikk over forskjell på antall styremedlemmer og vanlige medlemmer. I administrasjonsgrensesnittet kan vi lage nye administratorer, endre eksisterende administratorer eller slette administratorer for innlogget forening. Vi legger til en ny administrator ved å klikke på «+ New Admin»-knappen. sioforeninger.no/admin_overview/ 106

149 «+ New Admin»-knappen tar oss til en side der vi kan skrive inn nye administratorer. Union position er hvilken stilling personen har i foreningsstyret. Alle administratorkontoer kan legge til, endre og fjerne alle andre medlemmer og administratorer på siden. sioforeninger.no/innsidesignup/ Når vi har lagd en ny administrator blir vi tatt tilbake til «Admins» siden der vi kan se alle administratorene med en melding om at administratoren har blitt lagt til. sioforeninger.no/admin_overview/ 107

150 Nå som vi har noen medlemmer og administratorer kan vi ta en titt på statistikken for foreningen vår, dette gjør vi ved å klikke på «Statistics» i topp meny-baren. Statistisk tar oss til «Charts» siden, her kan vi se og laste ned forskjellig statistikk tilknyttet foreningen. sioforeninger.no/chartviewhigham/ For å se hva som kan vises klikker vi på «Select statistisk», la oss si vi ønsker å laste ned hvilke måneder nye medlemmer blir registrert som pdf. Først klikker vi på «Monthly registrations» fra «Select statics» menyen. Så velger vi grafen vi ønsker å laste ned ved å klikke på menyikonet vedsiden av det, så velger vi «Download as PDF documnet». Se bilde på neste side. sioforeninger.no/chartviewhighmonth/ 108

151 PDF filen generes og lastes ned av nettleseren når man klikker på knappene. Disse filene generes i større format enn det som vises på skjermen så de kan passe til fullskjermsbruk. Om man ønsker å se informasjon om en viss søyle i søylediagrammene kan man holde musepekeren over søylen. sioforeninger.no/chartviewhighmonth/ For å sende epost klikker vi på «Mail» delen av topp meny-baren Dette tar oss til siden, her kan vi skrive inn eposter med emne, vi kan sende dem til mange og skrive inn melding. Man kan skrive til primærmottaker, her kan flere mottakere skilles med komma, CC og BCC. For å sende eposten klikker vi på «Send». Foreningene kan ikke selv bestemme hvilken adresse eposten sendes fra, det går heller ikke å motta eposter på denne adressen. sioforeninger.no/post/ 109

152 Trykker vi send vil eposten sendes til alle mottakere listet, om vi forsøker å gå ut av siden når vi har begynt å skrive en epost uten å ha sendt får vi en melding som spør om vi er sikre på om vi vil forlate nå. sioforeninger.no/post/ Så kan vi navigere til «Calendar» i top meny-baren 110

153 Alle moderatorer I foreningen kan se det som skrives inn i denne kalenderen, alle moderatorer kan også endre på, legge til eller slette fra kalenderen. For å legge til en ny event neste måned trykker vi først nedover pilen der det står «May» for å navigere til Juni. Kalenderen viser alltid den måneden du er i nå som standard. sioforeninger.no/calendar/ Nå legger vi til ett arrangement den 13. Juni ved å klikke på den grønne «+» ikonet som kommer når vi har musepekeren over kalenderdagen. Ikonet skal være grønt når musen er i sammen firkant som tallet, men bli rød når musen er rett over det så ikonet blir klikkbart. Når vi trykke på ikonet kommer ett vindu der vi kan fylle ut informasjon om hendelsen, man må fylle ut hendelsesnavn og sted, men beskrivelse er valgfritt. sioforeninger.no/calendar/ 111

154 For å logge å endre passord klikker vi på nedoverpilen som står ved styremedlemmets navn og velger «Change password». Dette tar oss så til en side hvor vi kan endre passord, for å endre passord må vi kunne vært gamle passord. Om man har glemt passord kan man be en slette og lage kontoen din på nytt eller spørre SiO Forenigner om ett nytt passord. I mobilmodus flyttes menybaren til topp høyre hjørne og må klikkes på for å bli sett sioforeninger.no/member_overview/ 112

155 H. Intervjuer Gjennom intervjuprosessen fikk vi mange gode ønsker. Vi var dog nødt til å se på hva som var «need to have» og «nice to have» og gjøre et skille mellom dem. I dette prosjektet er det som tidligere nevnt en stor variasjon av hvilke brukere vi har og hvilke behov/ønsker de har. Det var altså gjennom å finne de gjentagende ønskene fra ulike foreninger at vi klarte å finne frem til hva som var «need to have». Vi valgte også å intervjue noen fagansvarlige ved HiOA for å få noen innspill. Under er våre notater, noe forenklet, etter vår intervjuprosess. Aksjegruppen HiOA ved Petter : Utsendelse av mail til medlemmer. Enkel brukeradministrasjon Mulighet for å separere/markere dem som er alumina Gi meg studentnummer så kommer opp all info om gitte bruker fra skolen Kontroll over folk som kommer på arrangement Tjene penger på medlemmer Statistikk av nåværende medlemmer Customeregistration Chateu Neuf ved Dennis: Henviser til Inside, et selvutviklet system som brukes per i dag. Sende mail til egne medlemmer Registering (lengde på historikk-alt fra 1-5 år) Bare styret som skal ta seg av administrative oppgaver Medlemskontingent 113

156 Intervju med OTS v/lise: Bruker bare fronter (helst ha programmer som kan styre alt av dokumenter, registrering osv.) Kan vær medlem uten å registrere seg (mer organisering av registrering) Betalingssystem (trimrom & bokskap) Vil nå studenter via private mail og ikke studentmail Vil se hvem som er delaktig i forskjellige arrangementer (2-3 år med historikk, muligens flere år tilbake i tid) Lage grupper (tillitsvalgte osv.) Intervju med HiOA Gaming v/envy: Statistikk over medlemsmassen Mailfunksjonalitet Internkalender for administratorer Skalerbarhet til mobile enheter Ønske om å kontrollere deltakere ved inngang. God sikkerhet Innspill fra Ismail (nettverk og systemadministrasjons fagansvarlig): OK å sette opp epost-server (men vanskelig å drifte (spam filter osv)) Sette auto-update på ubuntu (inneholder minimal services) Videresende smtp-server til annen server Relay host La SIO betale for tjenester som mailchimp osv Innspill fra Torunn (Veileder): Spikre databasen i førsteomgang (minste felles multiplum) Gjøres via mailserver til HiOA Høre med Amir eller BIT (brukerstøtte IT) 114

157 I. Detaljert kravspekk Rammekrav i systemet Følgende rammekrav og forutsetninger er satt for systemet: Webapplikasjon krever en bærbar eller stasjonær datamaskin og/eller smarte telefoner/nettbrett for å kunne anvendes. Webapplikasjon krever nettleser for å kjøre som er de i fleste nye og eldre datamaskiner. De ulike nettlesere kan være Mozilla Firefox, Microsoft Edge, Google Chrome og tilsvarende. Det kreves internett-tilgang for at webapplikasjonen skal kunne fungere. Oppdragsgiver og leverandør har ansvaret for systemets oppetid. At en studentforening er opprettet i SiO s register gjennom deres hjemmeside. Under er grunnoppsettet til databasen vår gjengitt. Hensikten med ette er å vise hvilke krav til data vi setter og hvordan disse skal lagres og kobles sammen. 115

158 Funksjonelle krav Funksjonelle krav kan enkelt beskrives som krav til hvilken funksjon programmet skal ha. Disse skal da også beskrives og gis en prioriteringsvurdering som gjengitt nedenfor. De funksjonelle kravene ble utarbeidet gjennom en intervjuprosess av ulike studentforeninger sentrert rundt Oslo og Akershus samt ønsker fra produkteier er satt meget sentralt. Referat fra disse intervjuene kan finnes i vedlegg. Prioritet # Krav Detaljer A 1 Admin skal kunne logge seg inn. En/Flere admin skal kunne få aksess med gitte innloggingsinformasjon. A 2 Admin skal kunne legge til et nytt medlem. B 3 Admin skal kunne endre en medlemsinformasjon. En/Flere ajdmin har mulighet til å legge til flere medlemmer i systemet. En/Flere admin har mulighet til å endre medlem(mer) sin personalia. A 4 Bruker skal kunne logge seg inn. En/Flere brukere skal kunne få aksess med gitte innloggingsinformasjon. A 6 Admin skal ikke kunne utføre uautoriserte handlinger/operasjoner. A 7 Systemet skal hindre uautorisert tilgang til brukerinformasjon. All funksjonalitet og sider sjekkes ut ifra admins aksessrolle. En/Flere admin skal kun ha tilgang for utførelse av handlinger som er ment for den gitte innloggingsinformasjon. B 8 Admin skal kunne hente ut datalog. En/Flere admin får muligheten til å hente ut statistikk som er av interesse. A 9 Admin skal kunne endre passord. En/Flere admin kan kunne endre passord etter gitte innloggingsinformasjon. A 10 Systemet skal bruke SSL-kryptering i all interaksjon. Alle interaksjoner mellom tjener og server er kryptert. C 11 Admin skal kunne redigere egen profil. En admin skal kunne endre sitt egen informasjon. B 12 Admin skal kunne søke etter informasjon. En/Flere admin har tilgang til en søkefunksjonalitet som gir de informasjon over data i systemet som statistikk. A 13 Oversiktlig kodestandard Lettforståelig kode som gir en oversiktlig og enkel overføring med ny funksjonalitet. 116

159 A 14 Struktur i MVT-modellen Endringer i brukergrensesnittet vil ikke gi utslag for hvordan data håndteres i modellen og omvendt. A 15 Hjelpedialog for bruker og admin. Tilgjengelig hjelp skal vises med dialog-boble ved mousehover på knapper o.l. A 16 Hindre systemfeil for bruker. Brukerne skal ikke få mulighet til å danne kritiske systemfeil ved bruk av webapplikasjon. A 17 Informativ feilmelding til bruker. Brukerne skal få gode og forståelig feilmeldinger. B 18 Bruker skal ikke trenge mer enn 3 klikk i menyvalg. B 19 Admin har tilgangsaksess for statistikk og grafer. Menyhierarkiet ikke har mer enn 2 forgreininger. Det skal gis aksess for admin til å få anonyme data av blant annet, antall medlemmer, aktiver medlemmer osv. C 20 Admin skal kunne gis rolle i styret. Det skal gis rolle til en bestemt administrator slik at man kan se hva slags rolle de har i styret. B 21 Admin skal kunne legge ut arrangementer. Ulike aktiviteter skal kunne legges ut i kalender av administratorer. B 22 Admin skal kunne sende ut E-post. Gitte informasjon vil bli sendt ut til samtlige i foreningen for å holde oppdatert hva som foregår. C 23 Systemet skal kunne sende ut varsling. Ulike aktiviteter på kalender vil det bli sendt ut varsling, hvis det ønskes, for påminnelse. 117

160 Ikke-funksjonelle krav De ikke funksjonelle kravene kan enkelt beskrives som hvordan systemet skal oppføre seg med hensyn på de funksjonelle kravene. Hvordan skal systemet implementere de funksjonelle kravene som er satt? Under vil de ikke-funksjonelle kravene være listet med tilhørende prioritet og detaljer. Prioritet Krav Detaljer A Systemet skal være brukervennlig og Brukerne er fornøyd med hvordan responsiv. systemet er laget og er fornøyd med B Bruker skal ikke bruke mer enn 5 minutter på en hovedprosess. hvor rask den er. Applikasjon av systemet er så rask at det ikke vil ta 5 minutter å gjennomføre en hovedprosess. A Lett tilgjengelig system. Systemet skal være tilgjengelig slik at det ikke er nødvendig for å laste ned egen app for webapplikasjon. B A B A A Nettsiden skal kunne tilpasse seg ettersom bruker har bærbar, stasjonær, nettbrett eller smarttelefon. Systemet skal kunne utvides på en enkel måte. Spørringer fra databasen skal ikke ta mer enn 3.5 sek. Systemet skal ha et tiltrekkende og funksjonelt design. Løsningen skal være oppnådd ved ende av fristen. Nettsiden skaleres og er brukervennlig på alle enhetstyper. Systemet skal utvikles etter standarder og «god praksis» slik at opplæring og vedlikehold av andre enn utviklerne er mulig. Informasjon som hentes fra databasen skal være redundant og tilgjengelig slik at det ikke vil ta lang tid å hente informasjon. Brukerne synes designet er rent, pent og tilgjengelig for enkel bruk av systemet. Produktet skal være fullverdig og tilfredsstille kravene som ble satt for oppdragsgiver. A Følge internasjonal standard. Krav og prinsipper som følges for utvikling og sikkerhet av webapplikasjon (OWASP og W3C). A Ivareta sikkerhet rundt brukerne. Sensitive personinformasjon skal ikke misbrukes av andre som ikke har de rette autorisasjon og autentisering. 118

161 J. Prototyper Papirprototype av databasen Prototype av forside 119

162 Prototype av internside for forening Alternativ prototype av forsiden foreninger ser 120

163 K. Brukertester Det ble mot utviklingens slutt gjennomført flere brukertester. Disse ble hovedsakelig utført med hjelp fra fremtidige brukere av systemet, nemlig frivillige i studentorganisasjoner. Måten dette ble gjennomført på var ved å gi de ulike brukerne spesifiserte oppgaver om hva de skulle utføre. Deretter var de på egenhånd. Satt brukeren seg fast i systemet hjalp vi dem videre og noterte oss problemet. Testerne av systemet ble fikk kaffe og klem i godtgjørelse da vi ikke har søkt om noe midler til godtgjørelse av testere. Vi fikk også produkteier til å teste systemet. Dette ble da gjort i en litt annen form da produkteier fikk brukernavn og passord for å teste for seg selv, fremfor at vi var tilstede. Vi fikk dog gode tilbakemeldinger som vi arbeidet med å forbedre. Etter all testingen var gjennomført og forbedringer var gjennomført ga vi nytt brukernavn og passord til produkteier for å leke seg på systemet. Det var da neglisjerbare forbedringer som var ønsket (produkteiers ord), og vi fikk deretter tilsendt en evaluering av prosjektet per 22. Mai. (E. SiO s tilbakemelding) 121

164 L. Sekvensdiagram Under har vi valgt å gjengi et sekvensdiagram. Grunnen til at vi velger å legge dette ved er at enhver funksjonalitet/handling som kan utføres i systemet følger, i all hovedsak, samme prinsipp. Det være seg å registrere admin, legge til en hendelse i kalendere, endre informasjon om et medlem eller å endre passord. Det som skiller seg mest ut er mailfunksjonaliteten. 122

165 M. Detaljert database 123

166 N. Filstruktur [4.0K] calapp [ 702] admin.py [ 91] apps.py [1022] forms.py [ 0] init.py [4.0K] migrations [ 0] init.py [4.0K] pycache [ 133] init.cpython-35.pyc [ 154] init.cpython-36.pyc [ 57] models.py [4.0K] pycache [ 253] admin.cpython-35.pyc [ 262] admin.cpython-36.pyc [ 122] init.cpython-35.pyc [ 143] init.cpython-36.pyc [ 164] models.cpython-35.pyc [ 181] models.cpython-36.pyc [ 184] tests.cpython-36.pyc [ 673] urls.cpython-35.pyc [ 647] urls.cpython-36.pyc [3.8K] views.cpython-35.pyc [3.5K] views.cpython-36.pyc [4.0K] static [4.0K] css [ 13K] calendar.css [1.8K] responsive.css [4.7K] sidebar.css [4.0K] js [ 25K] calendar.js [ 95K] jquery min.js [4.0K] templates [4.0K] calapp [ 12K] calendar (copy).html [ 15K] calendar.html [ 60] tests.py [ 694] urls.py [ 13K] views.py [4.0K] chart [7.0K] admin.py [ 89] apps.py [ 0] init.py [4.0K] migrations [ 0] init.py [4.0K] pycache [ 132] init.cpython-35.pyc [ 153] init.cpython-36.pyc [ 57] models.py [4.0K] pycache [1.5K] admin.cpython-35.pyc [1.4K] admin.cpython-36.pyc [ 121] init.cpython-35.pyc [ 142] init.cpython-36.pyc [ 163] models.cpython-35.pyc [ 180] models.cpython-36.pyc [ 183] tests.cpython-36.pyc [ 790] urls.cpython-35.pyc [ 751] urls.cpython-36.pyc [2.5K] views.cpython-35.pyc 124

167 [2.3K] views.cpython-36.pyc [4.0K] static [4.0K] css [ 710] chart.css [4.0K] js [ 43] chartgender.js [ 15K] chart.js [ 15K] chartmonth.js [ 43] highchart.js [4.0K] templates [4.0K] chart [4.0K] ChartView [9.7K] month.html [9.2K] chartviewhigh.html [ 11K] ChartView.html [ 113] tests.py [ 750] urls.py [3.3K] views.py [4.0K] CoAdmin [5.1K] admin.py [ 91] apps.py [ 13K] forms.py [ 0] init.py [4.0K] migrations [4.4K] 0001_initial.py [ 0] init.py [4.0K] pycache [3.4K] 0001_initial.cpython-35.pyc [3.0K] 0001_initial.cpython-36.pyc [ 700] 0002_auto_ _0316.cpython-35.pyc [ 671] 0002_auto_ _0316.cpython-36.pyc [ 657] 0003_auto_ _1514.cpython-35.pyc [ 641] 0003_auto_ _1514.cpython-36.pyc [ 134] init.cpython-35.pyc [ 155] init.cpython-36.pyc [4.3K] models.py [4.0K] pycache [2.2K] admin.cpython-35.pyc [2.0K] admin.cpython-36.pyc [7.8K] forms.cpython-35.pyc [7.2K] forms.cpython-36.pyc [ 123] init.cpython-35.pyc [ 144] init.cpython-36.pyc [3.5K] models.cpython-35.pyc [3.3K] models.cpython-36.pyc [ 646] serializers.cpython-35.pyc [ 633] serializers.cpython-36.pyc [1.7K] tests.cpython-36.pyc [ 627] urls.cpython-35.pyc [ 592] urls.cpython-36.pyc [5.1K] views.cpython-35.pyc [4.7K] views.cpython-36.pyc [ 226] serializers.py [4.0K] static [4.0K] css [3.2K] admin_overview.css [ 582] signup.css [4.0K] templates [4.0K] CoAdmin [3.9K] admin_delete.html [3.8K] admin_edit.html 125

168 [3.9K] admin_overview.html [1.2K] InnsideSignup.html [1.7K] password.html [1.0K] signup.html [2.8K] tests.py [ 524] urls.py [8.6K] views.py [4.0K] core [ 63] admin.py [ 87] apps.py [2.1K] forms.py [ 0] init.py [4.0K] migrations [ 0] init.py [4.0K] pycache [ 131] init.cpython-35.pyc [ 152] init.cpython-36.pyc [ 57] models.py [4.0K] pycache [ 165] admin.cpython-35.pyc [ 182] admin.cpython-36.pyc [2.1K] forms.cpython-35.pyc [1.9K] forms.cpython-36.pyc [ 120] init.cpython-35.pyc [ 141] init.cpython-36.pyc [ 162] models.cpython-35.pyc [ 179] models.cpython-36.pyc [ 182] tests.cpython-36.pyc [ 281] urls.cpython-35.pyc [ 287] urls.cpython-36.pyc [2.0K] views.cpython-35.pyc [1.9K] views.cpython-36.pyc [4.0K] static [4.0K] css [ 71K] animate.css [ 636] cover.css [3.9K] dashboard.css [ 82] network.css [ 198] profile.css [4.0K] img [ 17K] logo.svg [ 16K] SiOLogo.png [4.0K] js [ 712] picture.js [4.0K] templates [4.0K] core [2.5K] cover.html [5.4K] dashboard.html [ 436] partial_settings_menu.html [1.7K] password.html [2.3K] profile.html [2.2K] settings.html [ 60] tests.py [ 201] urls.py [3.3K] views.py [ 0] init.py [4.0K] member [ 603] admin.py [ 91] apps.py [ 10K] forms.py [ 0] init.py 126

169 [4.0K] migrations [2.3K] 0001_initial.py [ 0] init.py [4.0K] pycache [1.6K] 0001_initial.cpython-35.pyc [1.5K] 0001_initial.cpython-36.pyc [ 133] init.cpython-35.pyc [ 154] init.cpython-36.pyc [5.3K] models.py [ 356] popups.py [4.0K] pycache [ 842] admin.cpython-35.pyc [ 781] admin.cpython-36.pyc [5.2K] forms.cpython-35.pyc [5.2K] forms.cpython-36.pyc [ 122] init.cpython-35.pyc [ 143] init.cpython-36.pyc [2.6K] models.cpython-35.pyc [2.4K] models.cpython-36.pyc [ 666] popups.cpython-35.pyc [ 650] popups.cpython-36.pyc [ 988] serializers.cpython-35.pyc [ 949] serializers.cpython-36.pyc [1.3K] tests.cpython-36.pyc [ 677] urls.cpython-35.pyc [ 641] urls.cpython-36.pyc [4.6K] views.cpython-35.pyc [4.2K] views.cpython-36.pyc [ 390] serializers.py [4.0K] static [4.0K] css [3.5K] member_overview.css [1.6K] member_signup.css [ 339] popup_gender.css [4.0K] img [1.1K] man.png [1.7K] woman.png [4.0K] js [ 95K] jquery min.js [ 546] loading.js [4.0K] templates [4.0K] member [1.0K] asoc_signup.html [1.0K] member_confirm_delete.html [3.9K] member_delete.html [6.1K] member_edit.html [ 12K] member_overview.html [7.0K] member_signup.html [ 385] popup_gender.html [1.0K] tests.py [1.1K] urls.py [ 16K] views.py [4.0K] post [ 63] admin.py [ 83] apps.py [ 0] init.py [4.3K] mail.py [4.0K] migrations [1.0K] 0001_initial.py [ 0] init.py [4.0K] pycache 127

170 [1.1K] 0001_initial.cpython-35.pyc [1.0K] 0001_initial.cpython-36.pyc [ 776] 0002_auto_ _1514.cpython-35.pyc [ 736] 0002_auto_ _1514.cpython-36.pyc [ 588] 0003_remove_ _sendstatus.cpython-35.pyc [ 577] 0003_remove_ _sendstatus.cpython-36.pyc [ 131] init.cpython-35.pyc [ 152] init.cpython-36.pyc [ 596] models.py [4.0K] pycache [ 165] admin.cpython-35.pyc [ 182] admin.cpython-36.pyc [ 120] init.cpython-35.pyc [ 141] init.cpython-36.pyc [2.1K] mail.cpython-35.pyc [1.1K] mail.cpython-36.pyc [ 858] models.cpython-35.pyc [ 786] models.cpython-36.pyc [ 650] urls.cpython-35.pyc [ 622] urls.cpython-36.pyc [2.2K] views.cpython-35.pyc [1.5K] views.cpython-36.pyc [4.0K] static [4.0K] css [ 163] post.css [4.0K] javascript [ 139] post.js [4.0K] templates [4.0K] post [2.1K] post.html [ 60] tests.py [ 408] urls.py [6.1K] views.py [4.0K] pycache [ 115] init.cpython-35.pyc [ 136] init.cpython-36.pyc [3.5K] settings.cpython-35.pyc [3.3K] settings.cpython-36.pyc [1.4K] urls.cpython-35.pyc [1.3K] urls.cpython-36.pyc [ 529] wsgi.cpython-35.pyc [ 532] wsgi.cpython-36.pyc [4.0K] session_security [4.0K] fixtures [ 514] session_security_test_user.json [ 0] init.py [4.0K] locale [4.0K] cs [4.0K] LC_MESSAGES [1.1K] django.po [4.0K] es [4.0K] LC_MESSAGES [1.1K] django.po [4.0K] fr [4.0K] LC_MESSAGES [1020] django.po [4.0K] nl [4.0K] LC_MESSAGES [ 667] django.mo [1020] django.po [4.0K] pl 128

171 [4.0K] LC_MESSAGES [1.2K] django.po [4.0K] pt_br [4.0K] LC_MESSAGES [1021] django.po [4.0K] pt_pt [4.0K] LC_MESSAGES [ 989] django.po [3.2K] middleware.py [ 0] models.py [4.0K] pycache [ 153] init.cpython-36.pyc [2.0K] settings.py [4.0K] static [4.0K] session_security [5.2K] script.js [ 512] style.css [4.0K] templates [4.0K] session_security [1.5K] all.html [ 401] dialog.html [4.0K] templatetags [ 0] init.py [4.0K] pycache [ 166] init.cpython-36.pyc [ 259] session_security_tags.py [4.0K] tests [ 0] init.py [4.0K] project [ 0] init.py [4.0K] pycache [ 167] init.cpython-36.pyc [3.0K] settings.py [4.0K] static [262K] jquery.js [4.0K] templates [ 26] 404.html [ 26] 500.html [4.0K] admin [ 297] base_site.html [ 718] home.html [1.0K] urls.py [ 391] wsgi.py [4.0K] pycache [ 159] init.cpython-36.pyc [ 160] test_base.cpython-36.pyc [ 166] test_middleware.cpython-36.pyc [ 162] test_script.cpython-36.pyc [ 161] test_views.cpython-36.pyc [1.6K] test_base.py [2.8K] test_middleware.py [2.2K] test_script.py [1.8K] test_views.py [ 575] urls.py [1.4K] utils.py [ 984] views.py [5.5K] settings.py [4.0K] static [4.0K] css [2.1K] jquery.jcrop.min.css [1.8K] SiO.css 129

172 [4.0K] img [3.5K] ajax-loader.gif [ 41K] loading.gif [4.1M] PNF.gif [ 43K] sio-logo.jpg [126K] spinner.gif [2.8K] user.png [4.0K] js [ 310] date.js [ 395] ga.js [ 915] jquery.bullseye-1.0-min.js [ 16K] jquery.jcrop.min.js [2.2K] jquery.qtip.css [ 58K] jquery.qtip.js [1.3K] jquery.qtip.min.css [ 25K] jquery.qtip.min.js [ 36K] jquery.qtip.min.map [ 13K] jquery.selection.js [ 67K] jquery.typeahead.bundle.js [4.0K] jspdf [ 464] bower.json [3.2K] build.js [ 10] CNAME [4.0K] doc [3.5K] files.html [3.7K] index.html [4.0K] plugins [ 841] from_html.md [4.0K] symbols [8.3K] FontObject.html [6.3K] _global_.html [6.5K] jspdfclass.html [ 42K] jspdf.html [6.2K] jspdf-jspdf.html [ 11K] jspdf-pubsub.html [9.6K] PubSub.html [4.0K] src [351K] c work_jspdf_jspdf.js.html [148K] c work_jspdf_tools_jspdf.js.html [331K] jspdf.js.html [4.0K] docs [ 133] getting_started.md [4.0K] examples [4.0K] annotation [2.2K] test_annotation_2.html [2.7K] test_annotation.html [ 17K] test_annotation-magfactor.pdf [8.8K] test_annotation.pdf [ 17K] basic.html [4.0K] bootstrap [4.0K] css [121K] bootstrap.css [101K] bootstrap.min.css [ 21K] bootstrap-responsive.css [ 16K] bootstrap-responsive.min.css [4.0K] img [ 12K] glyphicons-halflings.png [8.6K] glyphicons-halflings-white.png [4.0K] js [ 57K] bootstrap.js [ 31K] bootstrap.min.js 130

173 [4.0K] canvg_context2d [ 52K] bar_graph_with_text_and_lines.html [4.0K] context2d [ 59K] test_context2d.html [ 935] test_context2d_paths.html [4.0K] css [ 660] editor.css [ 438] main.css [4.0K] smoothness [4.0K] images [ 180] ui-bg_flat_0_aaaaaa_40x100.png [ 178] ui-bg_flat_75_ffffff_40x100.png [ 120] ui-bg_glass_55_fbf9ee_1x400.png [ 105] ui-bg_glass_65_ffffff_1x400.png [ 111] ui-bg_glass_75_dadada_1x400.png [ 110] ui-bg_glass_75_e6e6e6_1x400.png [ 119] ui-bg_glass_95_fef1ec_1x400.png [ 101] ui-bg_highlightsoft_75_cccccc_1x100.png [4.3K] ui-icons_222222_256x240.png [4.3K] ui-icons_2e83ff_256x240.png [4.3K] ui-icons_454545_256x240.png [4.3K] ui-icons_888888_256x240.png [4.3K] ui-icons_cd0a0a_256x240.png [ 32K] jquery-ui custom.css [1.5K] downloadify.html [4.0K] html2pdf [3.9K] auto_break.html [ 18] examples.css [4.0K] images [ 27K] favicon.png [1.8K] lists.html [1.3K] page_break.html [1.9K] pdf2.html [3.5K] pdf.html [2.7K] showcase.html [5.6K] showcase_supported_html.html [ 829] simple.html [5.5K] tables.html [8.5K] total_mess.html [4.0K] images [ 36K] 24_bit.png [ 44K] 32_bit.png [ 22K] grayscale_16bpc.png [ 13K] grayscale_8bpc.png [ 37K] grayscale_alpha_16_bpc.png [ 22K] grayscale_alpha_8bpc.png [ 979] grid.png [ 12K] jpg.jpg [ 14K] png8_flat.png [ 13K] png8_trans.png [ 60K] RGB_16bpc.png [ 74K] RGBA_16bpc.png [ 11K] tiny_png_indexed.png [447K] images.html [ 552] jaxer.html [4.0K] js [1.8K] AcroForm.js [ 50K] autoprint.js [ 10K] basic.js [ 212] circles.js 131

174 [ 88K] editor.js [ 928] font-faces.js [ 167] font-size.js [ 398] from-html.js [ 165] html2canvas.js [ 50K] images.js [ 86K] images_png.js [4.0K] jquery [ 92K] jquery min.js [206K] jquery-ui custom.min.js [ 26] kitchen-sink.js [ 77] landscape.js [ 486] lines.js [ 650] rectangles.js [2.0K] string-splitting.js [4.5K] test_harness.js [ 384] text-colors.js [ 29K] theme-ambiance.js [ 196] triangles.js [ 190] two-page.js [ 723] user-input.js [ 948] jspdf.plugintemplate.js [3.6K] null-logo-trans.png [ 62K] octocat.jpg [ 54K] octocat.png [4.0K] outline [1.3K] test_outline.html [3.9K] test_outline.pdf [3.5K] runner.html [1.7K] test_from_html_css_page_breaks.html [1.7K] test_from_html.html [2.2K] test_insert_page.html [ 66K] thinking-monkey.jpg [9.8K] index.html [ 297] ISSUE_TEMPLATE.md [ 90K] jspdf.js [4.0K] libs [4.0K] canvg_context2d [102K] canvg.js [4.0K] libs [7.4K] rgbcolor.js [ 17K] StackBlur.js [ 454] README.md [4.0K] css_colors.js [ 68K] deflate.js [4.0K] Downloadify [4.0K] images [2.4K] download.png [4.0K] js [3.4K] downloadify.min.js [10.0K] swfobject.js [1.1K] LICENSE.txt [4.0K] media [2.6K] downloadify.swf [7.1K] README.textile [4.0K] src [4.0K] com [4.0K] dynamicflash [4.0K] util [4.6K] Base64.as [4.0K] tests 132

175 [2.3K] Base64Test.as [5.5K] Downloadify.as [6.3K] downloadify.js [2.9K] test.html [4.0K] html2canvas [1.0K] LICENSE [5.0K] readme.md [4.0K] src [4.0K] clone.js [8.0K] color.js [7.1K] core.js [ 698] dummyimagecontainer.js [ 227] fallback.js [1.3K] font.js [ 343] fontmetrics.js [1.4K] framecontainer.js [ 679] gradientcontainer.js [ 507] imagecontainer.js [5.7K] imageloader.js [3.8K] lineargradientcontainer.js [ 366] log.js [9.6K] nodecontainer.js [ 36K] nodeparser.js [6.2K] promise.js [ 601] proxyimagecontainer.js [3.2K] proxy.js [1.4K] pseudoelementcontainer.js [4.2K] renderer.js [4.0K] renderers [6.5K] canvas.js [ 685] stackingcontext.js [1.4K] support.js [1.8K] svgcontainer.js [ 839] svgnodecontainer.js [ 865] textcontainer.js [4.9K] utils.js [ 389] webkitgradientcontainer.js [ 503] xhr.js [2.4K] html2pdf.js [4.0K] png_support [ 16K] png.js [ 17K] zlib.js [5.5K] polyfill.js [ 48] README [4.0K] require [2.6K] config.js [ 59K] require.js [ 958] main.js [1.1K] MIT-LICENSE.txt [ 50K] npm-shrinkwrap.json [ 909] package.json [4.0K] plugins [ 55K] acroform.js [3.4K] addhtml.js [ 22K] addimage.js [8.8K] annotations.js [ 602] autoprint.js [1.0K] canvas.js [ 14K] cell.js [ 55K] context2d.js [ 35K] from_html.js 133

176 [2.2K] javascript.js [6.7K] outline.js [ 14K] png_support.js [ 628] prevent_scale_to_fit.js [9.3K] split_text_to_size.js [ 24K] standard_fonts_metrics.js [5.2K] svg.js [1.8K] total_pages.js [4.2K] xmp_metadata.js [2.3K] README.md [ 198] RELEASE.md [ 57] SUMMARY.md [4.0K] test [2.2K] 001_blankpdf.pdf [2.6K] 002_twopagedoc_oldapi.pdf [2.6K] 002_twopagedoc.pdf [2.3K] 003_demolandscape.pdf [2.3K] 004_fontsizes.pdf [2.5K] 005_demofonttypes.pdf [2.6K] 006_demotestcolors.pdf [2.4K] 007_demometadata.pdf [2.5K] 008_demorectangles.pdf [2.5K] 009_demoliness.pdf [2.8K] 010_democircles.pdf [2.4K] 011_multilinetext.pdf [2.6K] 012_multiplelines.pdf [5.1K] 013_sillysvgrenderer.pdf [2.5K] 013_sillysvgrenderer.svg [7.7K] 014_addImage.jpeg [ 10K] 014_addImage.jpeg.base64.txt [ 14K] 014_addImage.pdf.base64.txt [ 14K] 014_addImage.txt [2.4K] 015_splittext.js [6.1K] 015_splittext.pdf [3.2K] components_tests.js [ 168] index.htm [4.0K] libs [7.8K] curl min.js [3.8K] custom_fill.js [4.5K] qunit.css [ 41K] qunit.js [9.4K] pdf_generate_tests.js [1.8K] test_from_html_css_page_breaks.html [4.1K] test_harness.js [1.2K] test.html [1.2K] test_min.html [ 152] todo.txt [ 513] SiO.js [3.2K] SiO.markdown.js [4.0K] templates [ 175] 403.html [ 429] 404.html [ 268] 500.html [4.0K] admin [3.5K] chart_association.html [3.4K] chart_member.html [10.0K] base.html [ 31K] test.txt [1.8K] urls.py [ 384] wsgi.py 134

177 137 directories, 530 files O. Databasescript PostgreSQL database dump Dumped from database version Dumped by pg_dump version SET statement_timeout = 0; SET lock_timeout = 0; SET client_encoding = 'UTF8'; SET standard_conforming_strings = on; SET check_function_bodies = false; SET client_min_messages = warning; SET row_security = off; Name: plpgsql; Type: EXTENSION; Schema: -; Owner: - CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog; Name: EXTENSION plpgsql; Type: COMMENT; Schema: -; Owner: - COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language'; SET search_path = public, pg_catalog; SET default_tablespace = ''; SET default_with_oids = false; Name: Administrator; Type: TABLE; Schema: public; Owner: - CREATE TABLE "Administrator" ( id integer NOT NULL, password character varying(128) NOT NULL, last_login timestamp with time zone, is_superuser boolean NOT NULL, username character varying(150) NOT NULL, first_name character varying(30) NOT NULL, last_name character varying(30) NOT NULL, is_staff boolean NOT NULL, is_active boolean NOT NULL, date_joined timestamp with time zone NOT NULL, 135

178 ); union_position character varying(100) NOT NULL, character varying(255) NOT NULL, association_id integer NOT NULL Name: Administrator_groups; Type: TABLE; Schema: public; Owner: - CREATE TABLE "Administrator_groups" ( id integer NOT NULL, administrator_id integer NOT NULL, group_id integer NOT NULL ); Name: Administrator_groups_id_seq; Type: SEQUENCE; Schema: public; Owner: - CREATE SEQUENCE "Administrator_groups_id_seq" START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; Name: Administrator_groups_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - ALTER SEQUENCE "Administrator_groups_id_seq" OWNED BY "Administrator_groups".id; Name: Administrator_id_seq; Type: SEQUENCE; Schema: public; Owner: - CREATE SEQUENCE "Administrator_id_seq" START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; Name: Administrator_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - ALTER SEQUENCE "Administrator_id_seq" OWNED BY "Administrator".id; Name: Administrator_user_permissions; Type: TABLE; Schema: public; Owner: - CREATE TABLE "Administrator_user_permissions" ( id integer NOT NULL, administrator_id integer NOT NULL, permission_id integer NOT NULL ); 136

179 Name: Administrator_user_permissions_id_seq; Type: SEQUENCE; Schema: public; Owner: - CREATE SEQUENCE "Administrator_user_permissions_id_seq" START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; Name: Administrator_user_permissions_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - ALTER SEQUENCE "Administrator_user_permissions_id_seq" OWNED BY "Administrator_user_permissions".id; Name: Association; Type: TABLE; Schema: public; Owner: - CREATE TABLE "Association" ( id integer NOT NULL, asoc_name character varying(50) ); Name: Association_id_seq; Type: SEQUENCE; Schema: public; Owner: - CREATE SEQUENCE "Association_id_seq" START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; Name: Association_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - ALTER SEQUENCE "Association_id_seq" OWNED BY "Association".id; Name: ; Type: TABLE; Schema: public; Owner: - CREATE TABLE " " ( id integer NOT NULL, sender character varying(254) NOT NULL, "senttime" timestamp with time zone NOT NULL, subject character varying(254) NOT NULL, receiver character varying(254) NOT NULL, message text NOT NULL, association_id integer NOT NULL ); Name: _id_seq; Type: SEQUENCE; Schema: public; Owner: - 137

180 CREATE SEQUENCE " _id_seq" START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; Name: _id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - ALTER SEQUENCE " _id_seq" OWNED BY " ".id; Name: Event; Type: TABLE; Schema: public; Owner: - CREATE TABLE "Event" ( id integer NOT NULL, name character varying(50) NOT NULL, location character varying(100) NOT NULL, start timestamp with time zone NOT NULL, "end" timestamp with time zone NOT NULL, allday boolean NOT NULL, description text NOT NULL, synced boolean NOT NULL, gid character varying(100) NOT NULL, association_id integer NOT NULL ); Name: Event_id_seq; Type: SEQUENCE; Schema: public; Owner: - CREATE SEQUENCE "Event_id_seq" START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; Name: Event_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - ALTER SEQUENCE "Event_id_seq" OWNED BY "Event".id; Name: Member; Type: TABLE; Schema: public; Owner: - CREATE TABLE "Member" ( member_no integer NOT NULL, first_name character varying(50), last_name character varying(50), character varying(50), reg_date date, end_date date, date_of_birth date, gender character varying(50), association_id integer NOT NULL ); 138

181 Name: Member_member_no_seq; Type: SEQUENCE; Schema: public; Owner: - CREATE SEQUENCE "Member_member_no_seq" START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; Name: Member_member_no_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - ALTER SEQUENCE "Member_member_no_seq" OWNED BY "Member".member_no; Name: Profile; Type: TABLE; Schema: public; Owner: - CREATE TABLE "Profile" ( id integer NOT NULL, user_id integer NOT NULL ); Name: Profile_id_seq; Type: SEQUENCE; Schema: public; Owner: - CREATE SEQUENCE "Profile_id_seq" START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; Name: Profile_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - ALTER SEQUENCE "Profile_id_seq" OWNED BY "Profile".id; Name: auth_group; Type: TABLE; Schema: public; Owner: - CREATE TABLE auth_group ( id integer NOT NULL, name character varying(80) NOT NULL ); Name: auth_group_id_seq; Type: SEQUENCE; Schema: public; Owner: - CREATE SEQUENCE auth_group_id_seq START WITH 1 INCREMENT BY 1 NO MINVALUE 139

182 NO MAXVALUE CACHE 1; Name: auth_group_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - ALTER SEQUENCE auth_group_id_seq OWNED BY auth_group.id; Name: auth_group_permissions; Type: TABLE; Schema: public; Owner: - CREATE TABLE auth_group_permissions ( id integer NOT NULL, group_id integer NOT NULL, permission_id integer NOT NULL ); Name: auth_group_permissions_id_seq; Type: SEQUENCE; Schema: public; Owner: - CREATE SEQUENCE auth_group_permissions_id_seq START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; Name: auth_group_permissions_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - ALTER SEQUENCE auth_group_permissions_id_seq OWNED BY auth_group_permissions.id; Name: auth_permission; Type: TABLE; Schema: public; Owner: - CREATE TABLE auth_permission ( id integer NOT NULL, name character varying(255) NOT NULL, content_type_id integer NOT NULL, codename character varying(100) NOT NULL ); Name: auth_permission_id_seq; Type: SEQUENCE; Schema: public; Owner: - CREATE SEQUENCE auth_permission_id_seq START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; Name: auth_permission_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - 140

183 ALTER SEQUENCE auth_permission_id_seq OWNED BY auth_permission.id; Name: django_admin_log; Type: TABLE; Schema: public; Owner: - CREATE TABLE django_admin_log ( id integer NOT NULL, action_time timestamp with time zone NOT NULL, object_id text, object_repr character varying(200) NOT NULL, action_flag smallint NOT NULL, change_message text NOT NULL, content_type_id integer, user_id integer NOT NULL, CONSTRAINT django_admin_log_action_flag_check CHECK ((action_flag >= 0)) ); Name: django_admin_log_id_seq; Type: SEQUENCE; Schema: public; Owner: - CREATE SEQUENCE django_admin_log_id_seq START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; Name: django_admin_log_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - ALTER SEQUENCE django_admin_log_id_seq OWNED BY django_admin_log.id; Name: django_content_type; Type: TABLE; Schema: public; Owner: - CREATE TABLE django_content_type ( id integer NOT NULL, app_label character varying(100) NOT NULL, model character varying(100) NOT NULL ); Name: django_content_type_id_seq; Type: SEQUENCE; Schema: public; Owner: - CREATE SEQUENCE django_content_type_id_seq START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; Name: django_content_type_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - 141

184 ALTER SEQUENCE django_content_type_id_seq OWNED BY django_content_type.id; Name: django_migrations; Type: TABLE; Schema: public; Owner: - CREATE TABLE django_migrations ( id integer NOT NULL, app character varying(255) NOT NULL, name character varying(255) NOT NULL, applied timestamp with time zone NOT NULL ); Name: django_migrations_id_seq; Type: SEQUENCE; Schema: public; Owner: - CREATE SEQUENCE django_migrations_id_seq START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; Name: django_migrations_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: - ALTER SEQUENCE django_migrations_id_seq OWNED BY django_migrations.id; Name: django_session; Type: TABLE; Schema: public; Owner: - CREATE TABLE django_session ( session_key character varying(40) NOT NULL, session_data text NOT NULL, expire_date timestamp with time zone NOT NULL ); Name: id; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator" ALTER COLUMN id SET DEFAULT nextval('"administrator_id_seq"'::regclass); Name: id; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator_groups" ALTER COLUMN id SET DEFAULT nextval('"administrator_groups_id_seq"'::regclass); Name: id; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator_user_permissions" ALTER COLUMN id SET DEFAULT 142

185 nextval('"administrator_user_permissions_id_seq"'::regclass); Name: id; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY "Association" ALTER COLUMN id SET DEFAULT nextval('"association_id_seq"'::regclass); Name: id; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY " " ALTER COLUMN id SET DEFAULT nextval('" _id_seq"'::regclass); Name: id; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY "Event" ALTER COLUMN id SET DEFAULT nextval('"event_id_seq"'::regclass); Name: member_no; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY "Member" ALTER COLUMN member_no SET DEFAULT nextval('"member_member_no_seq"'::regclass); Name: id; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY "Profile" ALTER COLUMN id SET DEFAULT nextval('"profile_id_seq"'::regclass); Name: id; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY auth_group ALTER COLUMN id SET DEFAULT nextval('auth_group_id_seq'::regclass); Name: id; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY auth_group_permissions ALTER COLUMN id SET DEFAULT nextval('auth_group_permissions_id_seq'::regclass); Name: id; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY auth_permission ALTER COLUMN id SET DEFAULT nextval('auth_permission_id_seq'::regclass); 143

186 Name: id; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY django_admin_log ALTER COLUMN id SET DEFAULT nextval('django_admin_log_id_seq'::regclass); Name: id; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY django_content_type ALTER COLUMN id SET DEFAULT nextval('django_content_type_id_seq'::regclass); Name: id; Type: DEFAULT; Schema: public; Owner: - ALTER TABLE ONLY django_migrations ALTER COLUMN id SET DEFAULT nextval('django_migrations_id_seq'::regclass); Name: Administrator_ _key; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator" ADD CONSTRAINT "Administrator_ _key" UNIQUE ( ); Name: Administrator_groups_administrator_id_1ef2287e_uniq; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator_groups" ADD CONSTRAINT "Administrator_groups_administrator_id_1ef2287e_uniq" UNIQUE (administrator_id, group_id); Name: Administrator_groups_pkey; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator_groups" ADD CONSTRAINT "Administrator_groups_pkey" PRIMARY KEY (id); Name: Administrator_pkey; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator" ADD CONSTRAINT "Administrator_pkey" PRIMARY KEY (id); Name: Administrator_user_permissions_administrator_id_1a0395d9_uniq; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator_user_permissions" ADD CONSTRAINT "Administrator_user_permissions_administrator_id_1a0395d9_uniq" UNIQUE (administrator_id, permission_id); 144

187 Name: Administrator_user_permissions_pkey; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator_user_permissions" ADD CONSTRAINT "Administrator_user_permissions_pkey" PRIMARY KEY (id); Name: Administrator_username_key; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator" ADD CONSTRAINT "Administrator_username_key" UNIQUE (username); Name: Association_asoc_name_key; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Association" ADD CONSTRAINT "Association_asoc_name_key" UNIQUE (asoc_name); Name: Association_pkey; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Association" ADD CONSTRAINT "Association_pkey" PRIMARY KEY (id); Name: _pkey; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY " " ADD CONSTRAINT " _pkey" PRIMARY KEY (id); Name: Event_pkey; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Event" ADD CONSTRAINT "Event_pkey" PRIMARY KEY (id); Name: Member_ _key; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Member" ADD CONSTRAINT "Member_ _key" UNIQUE ( ); Name: Member_pkey; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Member" ADD CONSTRAINT "Member_pkey" PRIMARY KEY (member_no); Name: Profile_pkey; Type: CONSTRAINT; Schema: public; Owner: - 145

188 ALTER TABLE ONLY "Profile" ADD CONSTRAINT "Profile_pkey" PRIMARY KEY (id); Name: Profile_user_id_key; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Profile" ADD CONSTRAINT "Profile_user_id_key" UNIQUE (user_id); Name: auth_group_name_key; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY auth_group ADD CONSTRAINT auth_group_name_key UNIQUE (name); Name: auth_group_permissions_group_id_0cd325b0_uniq; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY auth_group_permissions ADD CONSTRAINT auth_group_permissions_group_id_0cd325b0_uniq UNIQUE (group_id, permission_id); Name: auth_group_permissions_pkey; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY auth_group_permissions ADD CONSTRAINT auth_group_permissions_pkey PRIMARY KEY (id); Name: auth_group_pkey; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY auth_group ADD CONSTRAINT auth_group_pkey PRIMARY KEY (id); Name: auth_permission_content_type_id_01ab375a_uniq; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY auth_permission ADD CONSTRAINT auth_permission_content_type_id_01ab375a_uniq UNIQUE (content_type_id, codename); Name: auth_permission_pkey; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY auth_permission ADD CONSTRAINT auth_permission_pkey PRIMARY KEY (id); Name: django_admin_log_pkey; Type: CONSTRAINT; Schema: public; Owner: - 146

189 ALTER TABLE ONLY django_admin_log ADD CONSTRAINT django_admin_log_pkey PRIMARY KEY (id); Name: django_content_type_app_label_76bd3d3b_uniq; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY django_content_type ADD CONSTRAINT django_content_type_app_label_76bd3d3b_uniq UNIQUE (app_label, model); Name: django_content_type_pkey; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY django_content_type ADD CONSTRAINT django_content_type_pkey PRIMARY KEY (id); Name: django_migrations_pkey; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY django_migrations ADD CONSTRAINT django_migrations_pkey PRIMARY KEY (id); Name: django_session_pkey; Type: CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY django_session ADD CONSTRAINT django_session_pkey PRIMARY KEY (session_key); Name: Administrator_da6195d4; Type: INDEX; Schema: public; Owner: - CREATE INDEX "Administrator_da6195d4" ON "Administrator" USING btree (association_id); Name: Administrator_ _f62b7289_like; Type: INDEX; Schema: public; Owner: - CREATE INDEX "Administrator_ _f62b7289_like" ON "Administrator" USING btree ( varchar_pattern_ops); Name: Administrator_groups_0e939a4f; Type: INDEX; Schema: public; Owner: - CREATE INDEX "Administrator_groups_0e939a4f" ON "Administrator_groups" USING btree (group_id); Name: Administrator_groups_a68d6894; Type: INDEX; Schema: public; Owner: - CREATE INDEX "Administrator_groups_a68d6894" ON "Administrator_groups" USING btree (administrator_id); 147

190 Name: Administrator_user_permissions_8373b171; Type: INDEX; Schema: public; Owner: - CREATE INDEX "Administrator_user_permissions_8373b171" ON "Administrator_user_permissions" USING btree (permission_id); Name: Administrator_user_permissions_a68d6894; Type: INDEX; Schema: public; Owner: - CREATE INDEX "Administrator_user_permissions_a68d6894" ON "Administrator_user_permissions" USING btree (administrator_id); Name: Administrator_username_82be8312_like; Type: INDEX; Schema: public; Owner: - CREATE INDEX "Administrator_username_82be8312_like" ON "Administrator" USING btree (username varchar_pattern_ops); Name: Association_asoc_name_c8e605ea_like; Type: INDEX; Schema: public; Owner: - CREATE INDEX "Association_asoc_name_c8e605ea_like" ON "Association" USING btree (asoc_name varchar_pattern_ops); Name: _da6195d4; Type: INDEX; Schema: public; Owner: - CREATE INDEX " _da6195d4" ON " " USING btree (association_id); Name: Event_da6195d4; Type: INDEX; Schema: public; Owner: - CREATE INDEX "Event_da6195d4" ON "Event" USING btree (association_id); Name: Member_da6195d4; Type: INDEX; Schema: public; Owner: - CREATE INDEX "Member_da6195d4" ON "Member" USING btree (association_id); Name: Member_ _7ccc105c_like; Type: INDEX; Schema: public; Owner: - CREATE INDEX "Member_ _7ccc105c_like" ON "Member" USING btree ( varchar_pattern_ops); Name: auth_group_name_a6ea08ec_like; Type: INDEX; Schema: public; Owner: - 148

191 CREATE INDEX auth_group_name_a6ea08ec_like ON auth_group USING btree (name varchar_pattern_ops); Name: auth_group_permissions_0e939a4f; Type: INDEX; Schema: public; Owner: - CREATE INDEX auth_group_permissions_0e939a4f ON auth_group_permissions USING btree (group_id); Name: auth_group_permissions_8373b171; Type: INDEX; Schema: public; Owner: - CREATE INDEX auth_group_permissions_8373b171 ON auth_group_permissions USING btree (permission_id); Name: auth_permission_417f1b1c; Type: INDEX; Schema: public; Owner: - CREATE INDEX auth_permission_417f1b1c ON auth_permission USING btree (content_type_id); Name: django_admin_log_417f1b1c; Type: INDEX; Schema: public; Owner: - CREATE INDEX django_admin_log_417f1b1c ON django_admin_log USING btree (content_type_id); Name: django_admin_log_e8701ad4; Type: INDEX; Schema: public; Owner: - CREATE INDEX django_admin_log_e8701ad4 ON django_admin_log USING btree (user_id); Name: django_session_de54fa62; Type: INDEX; Schema: public; Owner: - CREATE INDEX django_session_de54fa62 ON django_session USING btree (expire_date); Name: django_session_session_key_c0390e0f_like; Type: INDEX; Schema: public; Owner: - CREATE INDEX django_session_session_key_c0390e0f_like ON django_session USING btree (session_key varchar_pattern_ops); Name: Administrator_association_id_ a_fk_Association_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator" ADD CONSTRAINT "Administrator_association_id_ a_fk_Association_id" 149

192 FOREIGN KEY (association_id) REFERENCES "Association"(id) DEFERRABLE INITIALLY DEFERRED; Name: Administrator_gro_administrator_id_cf4ea902_fk_Administrator_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator_groups" ADD CONSTRAINT "Administrator_gro_administrator_id_cf4ea902_fk_Administrator_id" FOREIGN KEY (administrator_id) REFERENCES "Administrator"(id) DEFERRABLE INITIALLY DEFERRED; Name: Administrator_groups_group_id_d7a0f6d4_fk_auth_group_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator_groups" ADD CONSTRAINT "Administrator_groups_group_id_d7a0f6d4_fk_auth_group_id" FOREIGN KEY (group_id) REFERENCES auth_group(id) DEFERRABLE INITIALLY DEFERRED; Name: Administrator_use_administrator_id_ce6934f5_fk_Administrator_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator_user_permissions" ADD CONSTRAINT "Administrator_use_administrator_id_ce6934f5_fk_Administrator_id" FOREIGN KEY (administrator_id) REFERENCES "Administrator"(id) DEFERRABLE INITIALLY DEFERRED; Name: Administrator_user_permission_id_a434743e_fk_auth_permission_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Administrator_user_permissions" ADD CONSTRAINT "Administrator_user_permission_id_a434743e_fk_auth_permission_id" FOREIGN KEY (permission_id) REFERENCES auth_permission(id) DEFERRABLE INITIALLY DEFERRED; Name: _association_id_1233ad94_fk_Association_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY " " ADD CONSTRAINT " _association_id_1233ad94_fk_Association_id" FOREIGN KEY (association_id) REFERENCES "Association"(id) DEFERRABLE INITIALLY DEFERRED; Name: Event_association_id_7d5a1dcc_fk_Association_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Event" ADD CONSTRAINT "Event_association_id_7d5a1dcc_fk_Association_id" FOREIGN KEY (association_id) REFERENCES "Association"(id) DEFERRABLE INITIALLY DEFERRED; 150

193 Name: Member_association_id_62d782ef_fk_Association_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Member" ADD CONSTRAINT "Member_association_id_62d782ef_fk_Association_id" FOREIGN KEY (association_id) REFERENCES "Association"(id) DEFERRABLE INITIALLY DEFERRED; Name: Profile_user_id_fa0e72a2_fk_Administrator_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY "Profile" ADD CONSTRAINT "Profile_user_id_fa0e72a2_fk_Administrator_id" FOREIGN KEY (user_id) REFERENCES "Administrator"(id) DEFERRABLE INITIALLY DEFERRED; Name: auth_group_permiss_permission_id_84c5c92e_fk_auth_permission_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY auth_group_permissions ADD CONSTRAINT auth_group_permiss_permission_id_84c5c92e_fk_auth_permission_id FOREIGN KEY (permission_id) REFERENCES auth_permission(id) DEFERRABLE INITIALLY DEFERRED; Name: auth_group_permissions_group_id_b120cbf9_fk_auth_group_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY auth_group_permissions ADD CONSTRAINT auth_group_permissions_group_id_b120cbf9_fk_auth_group_id FOREIGN KEY (group_id) REFERENCES auth_group(id) DEFERRABLE INITIALLY DEFERRED; Name: auth_permiss_content_type_id_2f476e4b_fk_django_content_type_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY auth_permission ADD CONSTRAINT auth_permiss_content_type_id_2f476e4b_fk_django_content_type_id FOREIGN KEY (content_type_id) REFERENCES django_content_type(id) DEFERRABLE INITIALLY DEFERRED; Name: django_admin_content_type_id_c4bce8eb_fk_django_content_type_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY django_admin_log ADD CONSTRAINT django_admin_content_type_id_c4bce8eb_fk_django_content_type_id FOREIGN KEY (content_type_id) REFERENCES django_content_type(id) DEFERRABLE INITIALLY DEFERRED; Name: django_admin_log_user_id_c564eba6_fk_administrator_id; Type: FK CONSTRAINT; Schema: public; Owner: - ALTER TABLE ONLY django_admin_log 151

194 ADD CONSTRAINT "django_admin_log_user_id_c564eba6_fk_administrator_id" FOREIGN KEY (user_id) REFERENCES "Administrator"(id) DEFERRABLE INITIALLY DEFERRED; Name: public; Type: ACL; Schema: -; Owner: - REVOKE ALL ON SCHEMA public FROM PUBLIC; REVOKE ALL ON SCHEMA public FROM postgres; GRANT ALL ON SCHEMA public TO postgres; GRANT ALL ON SCHEMA public TO PUBLIC; PostgreSQL database dump complete 152

195 P. Testdokumentasjon Forord Denne delen av rapporten inneholder testing av selve produktet i ulike faser, hvordan vi har testet, hva som er testet og hvilke metoder som er brukt. Dokumentasjonen stiller noe krav til teknisk kompetanse, det anbefales å sette seg inn i produktet (produktdokumentasjon) før denne delen leses men er ikke et krav. Identifikasjon Denne rapporten innebærer alle tester som inngår i applikasjon. Altså, alt fra ulike deler som medlems- og administrators registrering, lesbar statistikker og registrering av ulike hendelser i kalender. Disse har blitt testet gjennom enhets-, integrasjons- og systemtesting. 1. Sammendrag Oppsummering til produktet vil være forholdsvis enkelt. Det settes høye krav offentlig tilgjengelige webapplikasjoner. Kvalitet, sikkerhet og stabilitet er sentralt. Produktet mangler et utall funksjoner, har i flere tilfeller feil som kategoriseres som kritiske og kan til tider direkte krasje. Et av problemene som går mye igjen er mangel på input validering. Applikasjonen har vist seg å være en omfattende test å gjennomføre der deler av lag måtte splittes for grundigere testing. Samt holde oversikt av ulike tester som førte til feil og rettelse av de medførte andre feil. Ved disse lagene har oppsett av testmiljø vært viktig for utførelse av hva applikasjon innebærer av mengde feil. Enhetstesting har bruken av datastubber vært nyttig, integrasjonstesting har det vært gjennom «Gherkin»-tester, som vil bli forklart utover denne rapporten, og systemtest med sine brukerhistorier for bekreftelse av produktet. Dette i sin helhet gir en indikasjon på hvordan det hele settes sammen til et endelig produkt. Vi har tatt i bruk «Selenium» for å lage skriftlige test cases og rapportere feil. «PyCharm» er blitt brukt til å skrive «Gherkin» med ulike scenarioer som testes mot kode snutter. «Selenium» er blitt brukt for å skape automatiserte tester basert på brukerhistoriene og trinnene som er laget. 153

196 2. Avvik i forhold til testplan I systemtestingen har det vært enkelte brukerhistorier som måtte testes manuelt da det ikke lot seg automatiseres uten hindringer. Dette gjelder brukerhistorier som innebærer endring og sletting av medlemmer og administratorer. Løsningen ble å lage testene manuelt slik at resultatene ble gjengitt i korrekt form. 3. Vurdering av testens grundighet Vi har fulgt testkravene vi satt opp i testplanen grundig. Noe avvik har oppstått og er ført opp under andre punkter i rapporten. Dog er alt testet tilfredsstillende men kanskje ikke optimalisert og finpusset. Gitt mer tid skulle vi gjerne utført retting av feilene funnet under test, men de måtte prioriteres ned om du ikke var veldig store. Men vi har identifisert og dokumentert de feilene vi ikke rettet opp slik at de aktuelle kan videreføre arbeidet med en myk overgang av hva vi har jobbet med. 4. Gjenstående aktiviteter/oppgaver Resterende enhetstester av kalender. Fokuset har ikke vært så mye på den delen da vi la heller mer vekt på medlem- og administrator modul. 5. Avvik i produktet Sammendrag av testresultatene: Testresultatene har vært ulike i de forskjellige fasene, vi fant flest feil under integrasjonstestingen. Systemtesting hadde også en del feil men færre enn integrasjonstestingen. Det svarte til våre forventninger da systemtestene utføres som noen av de siste testene før produktet slippes. Det er her vi tester om brukerne syntes programmet samsvarer til deres forventninger og behov. I og med at mesteparten av brukerhistoriene var vellykket selv med noen få «bugs» som kan rettes opp uten problemer. Det har også vært mye feil i selve databasen og input validering. 154

197 Avvik i systemtesting: Brukerhistorier som innebærer sletting av enkelte lagring av opplysninger feiler i «Selenium» når testing kjøres en gang til fordi den er slettet fra databasen. Dermed har vi heller kjørt dette i «MTM» for manuell testing. Å input validere felt hadde fikset brorparten av problemene som oppstår på registrering av medlemmer. 6. Vurdering av produktet som er testet Enhetstesting har det lykkes med å luke ut enkelt feil som måtte dukke opp og bygge grunnlaget for videre testing. Den har vært godt over 85% total godkjennelse og vi er fornøyd med resultatet på denne delen. Selv med 100% grendekning kan vi ikke være sikre på ett feilfritt system da det kan være feil vi ikke har sett mulighet til å skrive tester til. Da er det heller best å legge seg på et fornuftig mål mellom 80-90% av gjennomførelse. Videre i integrasjonstesting har vi lykkes med å teste alle «API er» og fått grønt lys på samtlige. Der testing har vært gjennomført for godkjente deler (alle med OK) og underkjente deler (alle med FEIL). Dette for å dekke mest mulig grad bruken av applikasjon for feil som måtte dukke opp. Systemtesting har vi testet produktet opp mot brukerhistoriene og fornøyd her med godt over 95% av testene gjennomført. Risikoen ved å sette produktet ut i drift kan innebære dårlig sikkerhet for brukere. Dette er en viktig faktor som må tas hånd om og tettes igjen for at den skal være brukervennlig. Inputvalideringsmangel gjør også at en administrator kan slette seg selv eller legge til hendelser i kalender som synes for alle ulike foreninger som egentlig skal være ment internt i en forening. 155

198 7. Sammendrag av aktiviteter og lærdom Testing av programvaren har vært utfordrende fra start til slutt. Bruken av Gherkin har vært nyttig men spesielt tidkrevende av installasjon for bruk i enhets- og integrasjonstesting. Da det var på plass var det hele positivt med spesielt Gherkin som pekte seg ut. Gherkin lot oss lage filer med testdata som kunne brukes uten å hente noe fra databasen. Integrasjonstesting med «Gherkin» var utfordrende å få fram rette kode-format ut ifra hvordan man testet. Det hele skulle settes opp for å kjøre sammenhengende og ikke individuelt. Her skulle det simuleres indirekte hva brukere foretok seg. Det å sette opp input og output data av de ulike objektene utefra en rekkefølge hadde også noe å si for at det ikke skulle feile. Siste delen skulle være mer knyttet direkte opp mot hva brukere ville gjøre i applikasjonen. Systemtesting med bruk av «Selenium» var enkel å installere samt enkel i bruk. Denne delen hadde fokuset mot brukerhistorier som kriterier for godkjennelse av produktet. Noen ganger gikk testkjøringen så fort at testingen ikke fulgte etter og endte med at det feilet. Løsningen var en kommando som ba satt inn en liten ventetid mellom hver test. Testing har vist seg å være utfordrende men svært lærerikt for gruppen, vi ble spesielt overasket over hvor ofte det å rette en feil bare ledet til at en annen feil. 156

199 8. Identifikasjon Testplan I hver sprint skulle all funksjonalitet testes på slutten av en sprint, vi trengte altså å skrive tester som oppfylte alle utviklingsmålene til hver sprint. Dette viste seg utfordrende til tider. 9. Innledning Produktet skal i sin helhet testes i ulike deler for å kunne dekke mest mulig feil for optimal drift. Systemet er delt opp i flere deler hvorav hver modul har sine gjeldende funksjonaliteter. De ulike deler av funksjonalitet for produktet innebærer: Oversikt over medlemmer Legge til medlem Endre medlem Slette medlem Søke opp medlemmer Gjeldende for administrasjon er følgende funksjonaliteter: Oversikt over administratorer Legge til administrator Endre administrator Slette administrator Statistikk og grafer gjelder følgende: Lesbare genererte statistikk og grafer 157

200 Kalender skal kunne viste til disse funksjonalitetene: Legge til hendelse Endre hendelse Slette hendelse Oversikt over alle hendelser Vise detaljert hendelse Synkronisere hendelser opp mot google kalender 10. Testobjekter Vi testet kun moduler og objekter lagd av oss, Django sine innebygde moduler og objekter vi ikke gjorde noe med utelat vi. Dette fordi Django allerede er godt testet. Enhetstesting er hovedfokuset på filer hvor alle funksjoner skal testes uavhengig av rekkefølge. De skal knyttes opp mot en «virtuell» database, såkalt «stubb». Dette gjør testingen smidig og rask der all data er knyttet opp mot minnet i maskinen. I motsetning til kobling mot database på den vanlige måten som reduserer farten på testene og fører til mer arbeid for å holde databasen sanitert. Integrasjonstesting fokuserer på alle API filer, utenom den overnevnte, og her er det viktig å kjøre filene i prioritert rekkefølge. Grunnen for prioritering er at dette skal simulere opp mot hva brukere foretar seg og da kan se hvor feilene oppstår. Systemtest er den endelige fasen som skal sette applikasjonen ut på prøve for om den er klar for offentligheten. Dette er en fase som skal simulere hva en administrator foretar seg på applikasjonen. Da kan man se om produktet har store alvorlige feil eller mindre feil som ikke påvirker brukervennligheten. 158

201 11. Fremgangsmåte Beskriv hvordan testingen skal foregå. Hvilke data skal benyttes. Hvordan automatiseres testene? Testingen skal foregå på 3 ulike planer: Enhetstest Integrasjonstest Systemtest Data som benyttes er simulerte informasjon knyttet opp mot medlemmer, administratorer og hendelser. a. Overordnet teststrategi for Enhetstesting og Integrasjonstest automatiseres ved hjelp av «Gherkin». Systemtest automatiseres ved hjelp av «Selenium» og eventuelt manuelt testes med «MTM» (Microsoft Test Management). b. Prosedyre for planlegging og gjennomføring av test Enhetstesting spesifiseres ut ifra funksjoner som er satt opp med sine gjeldende inn parameter(e). Dette avhenger av stubber som settes opp for å kunne teste mot «virtuelle» databaser. Integrasjonstesting skal spesifiseres med input og output av data som gis av API og disse kjøres mot de virkelige databaser. Systemtesting spesifiseres med data av input og output mot forhåndsbestemte brukerhistorier. Hva er kriteriene for at testene kan kjøres (oppsett av miljø, database etc)? Enhetstesting og Integrasjonstesting skal kjøres mot database og verktøyet som skal være i bruk er «Gherkin». Systemtest testes enten i «Selenium2 eller «MTM» (Microsoft Test Management) ut ifra hva som skal automatiseres eller manuelt testes. Dette gjøres med brukerhistories som kriteriums grunnlag. 159

202 Hva er kriteriene for at testene er kjørt? Enhetstesting skal oppnå 80% godkjennelse for å godtas som gyldig. Integrasjonstesting skal kunne kjøre alle «API er» og lykkes ut ifra alle data som blir satt inn. Systemtesting skal de fleste brukerhistorier være vellykket for optimalt brukergrensesnitt. Kriterier for grundighet i testen I enhetstesing skal de viktigste funksjonaliteter av kodelinjer være grønne der de ikke fører til noe alvorlige feil som hemmer funksjoner av applikasjon. Ved integrasjonstest bør alle interne grensesnitt være utført (API er). Integrasjonstesting skal alle «API er» lyse grønt med de rette meldinger som fører til at applikasjonen fungerer mer optimalt. For systemtest bør det dokumenteres hvorvidt krav i spesifikasjonen / brukerhistorier er testet. Systemtesting skal de fleste brukerhistorier være fullverdig og oppnåelig for maks tilfredstillelse av brukergrensesnitt. 12. Godkjenningskriterier Testen ansees godkjent når 80% av de enhetstesting er utført uten alvorlige av kategori A og B feil. Testen godkjennes når 95 % av brukerhistorier er gjennomført uten alvorlige av kategori A og B feil. Testen godkjennes når 95 % av de integrasjonstesting er utført uten alvorlige av kategori A og B feil. Kategori A: Feil i en eller flere funksjoner som forårsaker stopp. For eksempel maskin/system/funksjon må startes på nytt. Kategori B: Feil har alvorlige konsekvenser i systemet eller tilstøtende systemer, for eksempel feil i databaser, alvorlige feil i rapporter slik at disse tolkes feil etc. 160

203 Kategori C: Feil med mindre alvorlige konsekvenser, for eksempel mindre grad av ustabilitet, mindre funksjons-/egenskapsmangler etc. Kategori D: Feil uten alvorlige konsekvenser, for eksempel layout-/trykkfeil i skjermbilder, rapporter eller dokumentasjon som ikke har konsekvenser for forståelsen av disse. 13. Testmiljø I enhets- og integrasjonstesting har verktøyet «Gherkin» blitt tatt i bruk for å teste de viktigste «API er». Den skal hjelpe med å finne feil som oppstår ut ifra databasen som testes mot. Alt av input og output data må stemme med hva som er i databasen. «Selenium» har vært verktøyet i bruk for systemtesting og den skulle også testes mot databasen. Den hadde mer aktivitet mot selve nettsiden for å kunne tilnærme oss en realitet av bruken for applikasjon. Brukerhistoriene var fokuset her for godkjennelse av testen ut ifra hva som ble foretatt av input og output data. 161

204 Testmanuskript 14. Enhetstesting og Integrasjonstesting I denne delen testes det med «Gherkin» mot de viktigste funksjonalitetene i produktet som er «Admin» og «Medlem». 162

205 Oversikt over alle Features Oversikt over alle Steps 163

206 Legge til admin 164

207 Legge til medlem 165

208 166

209 Slette admin 167

210 168

211 Slette medlem 169

212 Endre admin 170

213 Endre medlem 171

214 172

215 Innlogging 173

216 Resultat av alle scenarioer 174

217 175

218 15. Systemtest -Selenium Her tester vi helheten av systemet i ulike brukeraktivteter og simulerer godkjente aktiviteter samt feil som kan forekomme. Det legges ut beskrivelser av brukerhistorier med utførelser gjort av «Selenium» i form av bilder. I tillegg er det lagt til HTML-tabeller for mer detaljer av ulike aktiviteter som er utført. Innlogging for admin: 1. Som Admin ønsker jeg at innloggings-systemet gir meg beskjed om feil slik at jeg kan vite hva som er feil (25). 176

219 1. Som Admin ønsker jeg å ha en sikker innlogging slik at jeg kan bruke systemet uten å være urolig for dataer som er lagret (16). 177

220 Medlemmer: 2. Som Admin ønsker jeg å søke opp medlemmer slik at jeg kan effektiv se om personen er medlem i foreningen (5). 178

221 3. Som Admin ønsker jeg å registrere medlemmer slik at jeg kan øke interesse i forening (7). 179

222 3. Som Admin ønsker jeg å avbryte registrering av medlemmer slik at jeg blir navigert tilbake til medlemsoversikt (26). 180

223 4. Som Admin ønsker jeg å endre medlemsinformasjon slik at jeg kan lagre medlem med rette opplysninger (17). 181

224 4. Som Admin ønsker jeg ikke å endre medlemsinformasjon slik at jeg kan angre mitt valg (27). 182

225 5. Som Admin ønsker jeg å slette en ikke-aktivt medlem slik at jeg kan se alle aktive medlemmer i oversikten (18). 183

226 5. Som Admin ønsker jeg ikke å slette en ikke-aktivt medlem slik at jeg kan være sikker på at medlemmet ikke lenger er aktiv (28). 184

227 6. Som Admin ønsker jeg å søke opp medlemmer slik at jeg kan effektiv se om personen er medlem i foreningen (5). 185

228 186

229 187

230 6. Som Admin ønsker jeg å søke opp medlemmer som ikke eksistere slik at jeg kan effektiv se om personen er medlem i foreningen (29). 188

231 Administrator: 7. Som Admin ønsker jeg å ha en oversikt over alle administratorer (styret) slik at jeg kan se hvem som er med i styret (19). 189

232 8. Som Admin ønsker jeg å legge til ny administrator slik at de kan få aksess rettigheter til CRUD (create, read, update and delete) (12). 190

233 8 Som Admin ønsker jeg ikke å legge til ny administrator slik at jeg kan angre mitt valg (30). 191

234 9 Som Admin ønsker jeg å endre informasjon om meg selv slik at jeg har riktige opplysningene om meg selv (20). 192

235 9 Som Admin ønsker jeg ikke å endre informasjon om meg selv slik at jeg kan angre mitt valg (31). 193

236 10 Som Admin ønsker jeg ikke å slette en administrator slik at jeg kan angre mitt valg (32). 194

237 10 Som Admin ønsker jeg å slette en administrator slik at jeg kan se alle aktive administratorer i oversikten (21). 195

238 11 Som Admin ønsker jeg ikke å slette meg selv slik at systemet ikke kollapser (22) 196

239 Kalender: 12 Som Admin ønsker jeg en kalender-oversikt slik at alle kan se ulike happeninger/kurs som foregår i løpet av semester (10). 197

240 13 Som Admin ønsker jeg å opprette arrangementer slik at jeg øker interesse for foreningen (3). 198

241 13 Som Admin ønsker jeg ikke å opprette arrangementer slik at jeg kan angre mitt valg (33). 199

242 14 Som Admin ønsker jeg å endre informasjon i kalender slik at det er riktige opplysningene om aktiviteten (23). 200

243 14 Som Admin ønsker jeg ikke å endre informasjon i kalender slik at jeg kan angre valget mitt (34). 201

244 15 Som Admin ønsker jeg ikke å slette informasjon i kalender slik at jeg kan angre valget mitt (35). 202

245 15 Som Admin ønsker jeg å slette informasjon i kalender slik at de uriktige opplysningene opphører (24). 203

246 16. Systemtest Microsoft Test Management (Manuell testing) Her tester vi alle deler av systemet ved å manuelt kjøre de med innlagte brukerhistorier. Vi legger opp test planer og kjører brukerhistorier som test-caser. Innlogging for admin: 204

247 Medlemmer: 205

248 206

249 Administrator: 207

250 Kalender: 208

251 209

252 Q. Presentasjon I dette vedlegget har vi vedlagt vårt innsalg for prosjektet. Dette er regnet som en prosjektbeskrivelse og ble presentert for SiO ledelsen i håp om å få godkjent bacheloroppdraget. 210

253 211

254 212

255 Brukt som eksempel hvordan dagens løsning er og hvordan den ikke er optimal. 213

256 Eksempel på hvordan en studentforening registrer medlemmer per dags dato. 214

257 Eksempel på hvordan duplikater av medlemslister kan skape forvirringer og komplikasjoner. 215

258 Eksempel på hvordan vi løste problematikken i vår egen forening. Nemlig ved å utviklet en egen medlemsregistrerings-løsning online. 216

259 Hvordan medlemslisten blir representert på denne siden. 217

260 218

261 Estimerte direkte brukere av systemet basert på et anslag om seks brukere som er frivillige eller i styret i hver forening. 219

262 Estiamt av indirekte brukere. Altså at hver forening har i gjennomsnitt 50 medlemmer. Vi ser på disse som indirekte brukere da disse vil få en enklere registreringsprosess hos foreningene og vil slippe å bli kontaktet ved eventuelle feil. 220

263 221

264 222

265 223

266 224

267 225

268 226

269 227

270 228

271 229

272 230

273 Merk at vi gikk bort fra MariaDB da Postgress vil fungere bedre ved selve integrasjonen av systemet. 231