2. Styringsdokumenter
2. Styringsdokumenter 2. Styringsdokumenter .................................................................................................................. 1 2.1 Prosjektskisse........................................................................................................................ 3 Foreløpig tittel: ........................................................................................................................ 3 Medlemmene............................................................................................................................ 3 Kontaktinformasjon oppdragsgiver:............................................................................... 3 Beskrivelse av prosjektet: ................................................................................................... 3 2.2 Prosjektdagbok ..................................................................................................................... 4 Utdrag: ........................................................................................................................................ 4 28. Oktober 2014 ............................................................................................................... 4 09 . Januar 2015 ................................................................................................................. 4 16. Februar 2015 ............................................................................................................... 5 27. februar 2015 ................................................................................................................ 5 19. mars 2015 ..................................................................................................................... 5 30. april 2015 ...................................................................................................................... 5 2.3 Forprosjektrapport ............................................................................................................. 6 Presentasjon ............................................................................................................................. 6 Tittel........................................................................................................................................ 6 Oppgave: ............................................................................................................................... 6 Problemstilling: .................................................................................................................. 6 Gruppemedlemmer: ......................................................................................................... 6 Prosjektgruppe: Gruppe 15 ........................................................................................... 7 Sammendrag ............................................................................................................................ 7 Dagens situasjon ..................................................................................................................... 7 Mål og rammebetingelser ................................................................................................... 8 Løsninger /alternativer ....................................................................................................... 9 Analyse av virkninger ........................................................................................................... 9 Arbeidsmetode ..................................................................................................................... 10 Milepælsplan ......................................................................................................................... 11 Fremdriftsplan...................................................................................................................... 12 2.4 Arbeidsplan og fremdriftsplan .................................................................................... 13 Arbeidsplan ........................................................................................................................... 13 Arbeidsted .............................................................................................................................. 14 Arbeidsmetode ..................................................................................................................... 14 Vedlegg - Styringsdokumenter 1 Milepælsplan ......................................................................................................................... 14 Fremdriftsplan...................................................................................................................... 15 Risikoplan ...............................................................Feil! Bokmerke er ikke definert. 2.5 Kravspesifikasjonen......................................................................................................... 17 Oppgaven:............................................................................................................................... 17 Forklaring på produktets hensikt: ................................................................................ 17 Prioriteringer og avgrensninger fra oppdragsgiver og gruppen: ..................... 18 Forbehold: .............................................................................................................................. 18 Oppgave: ................................................................................................................................. 18 Oppgaven er ikke:................................................................................................................ 19 Dokumentstandard: ........................................................................................................... 19 Kode:......................................................................................................................................... 19 Alternativer for tastaturoppsett: ............................................................................... 19 Navigasjonsverktøy for brukeren: ................................................................................ 19 Problemstilling: .................................................................................................................... 20 Moduler: .................................................................................................................................. 20 Modul: Database.............................................................................................................. 20 Modul: Søkealgoritme ................................................................................................ 20 Modul: Databaseadministrasjonsverktøy ............................................................. 20 Modul: Kommunikasjonsverktøy ........................................................................... 20 Modul: Tastaturmapping ............................................................................................. 20 Annet ........................................................................................................................................ 20 Ressurser: .......................................................................................................................... 20 Presentasjonsform: ........................................................................................................ 21 Brukerhistorier................................................................................................................ 21 Prosesskrav ......................................................................................................................... 21 Testing og godkjenning ................................................................................................ 21 Datagrunnlag:................................................................................................................... 22 Testgrunnlag: ................................................................................................................... 22 Setninger:........................................................................................................................... 22 Skriveverktøy ................................................................................................................... 22 Designvalg ...................................................................................................................... 22 Datasikkerhet ........................................................................................................................ 22 Vedlegg - Styringsdokumenter 2 2.1 Prosjektskisse Hovedprosjekt i data/informasjonsteknologi ved Høgskolen i Oslo og Akershus våren 2015 Oslo 02. desember 2014 Foreløpig tittel: Bliss [Syn] – Bliss med synonymer Medlemmene: Davood Arayeshshamsabad (HINGDATA) s188072 Magnus William Eriksen (HINGDATA) s188112 Faraz German (HINGDATA) s188090 Zakaria el Mansouri (HINGDATA) s188104 Kontaktinformasjon oppdragsgiver: Oppdragsgiver: Turbodevs AS Org.nr: 912 976 076 Kontaktperson: Nina Bauge(daglig leder) og Tobias Andersen(nest leder) Telefon: 928 04 277 Epost: [email protected] Besøksadresse: St. Olavs gt. 32, 0166 Oslo Beskrivelse av prosjektet: Turbodevs er en nystartet bedrift som jobber med utvikling av hjelpesystemer, og videreutvikling av eksisterende produkter for brukere og brukervennlighet. Dette prosjektet har sin plass i bedriften som en modul i et større planlagt og påbegynt system som er rettet mot at flere brukere skal kunne ta i bruk et ideologisk språk og for å øke bruksområdene til språket. Prosjektet går på å videreutvikle en eksisterende symboldatabase «Bliss», fra en ekstern leverandør. «Bliss» er en database med symboler som danner et ideografisk språk. Denne databasen inneholder enkeltsymboler, som sammensatt danner ord. Databasen inneholder også ord, men de står kun som et enkeltsymbol og det er ikke ført opp hvilke symboler ordene er satt sammen av. Deler av oppgaven vil være å videreutvikle databasen så det er egne tabeller for verb, substantiv, adjektiv og andre ordklasser. Det skal også lages en kobling mellom ord og de tegnene det er satt sammen av. Videre skal det også implementeres mulighet for at enkelte brukere skal kunne ha en tabell over synonymer. Det er ikke alle brukere av dette ideografiske språket som klarer å bruke ordene med den rekkefølgen eller sammensettingen av symboler som det er definert i den eksisterende databasen. Dette er en gruppe brukere som kunne ha god nytte av å kunne sette opp synonymer i samarbeide med pedagog. Del to av oppgaven er å lage en webapplikasjon hvor brukeren kan sette sammen ord «synonymer» ved å velge enkeltstående symboler fra en liste over ordklasser. Det skal Vedlegg - Styringsdokumenter 3 ganske fritt være mulig å trekke symboler fra listene over ordklasser til et rutenett på skjermen der synonymet blir satt sammen, og så linkes til eksisterende ord. Det skal også være mulig og omrokere plasseringen av enkeltsymboler i eksisterende ord for å lage et synonym. Viktig å påpeke at dette prosjektet utvikles for støtteapparatet og at brukergruppen til denne webapplikasjonen er pedagoger og foresatte til brukerne av det ideologiske språket. Foreløpige valg av teknologier ligger på bruk av MVC .NET og C# for utvikling av webapplikasjonen, og bruk av MySQL for databasen. Utvikler verktøy vil blant annet bestå av Visual Studio og Redmine + Mercurial + Bitbucket for prosjektstyring og versjonskontroll. 2.2 Prosjektdagbok For å holde oversikt over hva vi snakket om på̊ gruppemøtene og for å dokumentere arbeidsfordeling, laget vi møtedagbok. Disse loggene ble skrevet under gruppemøtene. Der skriver vi både hva vi har gjort og hva som er planen videre. Dagboken hjalp oss veldig med å huske gjennomført arbeid underveis i hovedprosjektet og var til hjelp under rapportskriving og sluttfasen. Utdrag: 28. Oktober 2014 Gruppen hadde sitt første møte med oppdragsgiver. På dette møtet presenterte oppdragsgiver hva han ønsket at gruppen skulle lage. Oppdragsgiver skulle ha rollen som project owner, mens veilederen skulle være rådgivere angående teknologier som skulle brukes, og en sterk fagperson. Vi gikk så igjennom hvilken type teknologi som kunne være aktuell å bruke. Alle fikk i oppgave etter møte om å lage en skisse over hvordan webapplikasjonen kan se ut og databasen. 09 . Januar 2015 Vi møttes kl: 11.00 på Espresso House Pilestredet. Da skulle vi planlegge hvordan vi skal skrive forprosjektet. Vi fant en mal på HiOA sidene sider som brukte. Oppgaven ble at Zakaria tok for seg presentasjon, sammendrag, fremdriftsplan og milepælplan, Faraz tok for seg mål og rammebetingelser og løsninger, Magnus tok for seg Dagens situasjon og skulle sette sammen dokumentet, og Davood tok for seg analyse av virkninger. Vedlegg - Styringsdokumenter 4 16. Februar 2015 Vi møttes kl 08.00. Da fortsatte vi arbeidet med databasen, holder fortsatt på med usecase etter litt uenigheter med oppdragsgiver. Vi bestemmer oss for å få en enighet med dem snarest, og starte å dele ansvarsområder. Forstår at alle ikke kan jobbe med samme ting. Faraz tar for seg tastaturet, Magnus tar for seg databasen, Davood tar for seg design, og Zakaria tar for seg API. Zakaria kontaktet turbodevs, og fikk til et møte. Det betyr ikke at de som ikke f. eks har ansvar for database ikke skal være tilgjengelig til hjelp, og gå gjennom denne koden. Alle skal til enhver tid vite hva alle holder på med, og forstå kodingen slik at hvis det blir noe sykdom har vi en backup plan til å ta over. 27. februar 2015 Magnus har kommet med et utkast av databasen, Zakaria prøver å få til et møte med oppdragsgiver slik at de får sett på det. Faraz jobbet videre med tastaturet, og Davood med designet og laget et forslag til design i Balsamiq Mockups. 19. mars 2015 Vi har møte med Turbodevs. Viser dem hvor langt vi har kommet. Dem får blant annet sett på databasen, webapplikasjonen, og forslag til tastatur etter at Faraz fant ut at det var vanskeligere å programmere tastaturet enn antatt. Alle får beskjed om å hjelpe til her, så vi får til et utkast her. 30. april 2015 Dagen er inne for å teste, vi skulle ønske dette kom tidligere. Testingen fant sted på Ullevål sykehus hos blissgruppen. Der møtte vi på blissleder, to psykologer og en lærer som skulle teste produktet vårt. Magnus forklarte hvordan Balsamiq Mockupen fungerte før de begynte å teste denne og Faraz forklarte hvordan tastaturet fungerte. Når det var tid for å teste, skrev Zakaria ned punkter og resultater på hvordan testingen gikk. Til slutt snakket Davood om valg av design, og grunnen til hvorfor det ble slik som det ble før vi skulle få tilbakemeldinger på resultatet. Blissgruppen var meget imponert og fornøyd med resultatet. Vi bestemte oss for å ta fri resten av kvelden, og starte med å få produktet fullstendig ferdig etter å tatt kommentarene deres i betraktning. Vedlegg - Styringsdokumenter 5 2.3 Forprosjektrapport Presentasjon Tittel: BlissBase Oppgave: “Databasetilpasning med grensesnitt” Produkter: Videreutvikle en database og en webapplikasjon til å administrere den med. Her ber vi prosjektgruppen videreutvikle en eksisterende symboldatabase fra en ekstern leverandør. Databasen er laget for lagring av enkeltsymboler, symbolsekvenser og ulike rekkefølger av symbolsekvenser i et ideografisk symbolspråk. Webapplikasjonen kan brukes for å komponere og omrokere symbolkombinasjoner. Hensikt: Å tilrettelegge bruken av språket til brukernes egen uttrykksform, samle erfaringer og tilrettelegge for bruk med tekniske hjelpemidler. Ressurser: Oppdragsgiver dekker kostnader til databaselisenser for gruppemedlemmene, formidler kontakt mellom relevante fagpersoner og prosjektgruppen og vil samarbeide om utforming av kravspesifikasjon med prioriteringer. Problemstilling: Modernisere og videreutvikle en eksisterende symboldatabase, med tilhørende webapplikasjon for å muliggjøre bruk av synonymer og kontrollert vokabular Gruppemedlemmer: - Davood Arayeshshamsabad (HINGDATA) s188072 - Magnus William Eriksen (HINGDATA) s188112 - Faraz German (HINGDATA) s188090 - Zakaria el Mansouri (HINGDATA) s188104 Vedlegg - Styringsdokumenter 6 Prosjektgruppe: Gruppe 15 Veileder: Thor Hasle([email protected]) Oppdragsgiver: Turbodevs AS Org. nr: 912 976 076 Kontaktperson: Nina Bauge(Daglig leder) og Tobias Andersen Telefon: 928 04 277 Epost: [email protected] Besøks-adresse: St. Olavs gt. 32, 0166 Oslo Faglig veileder: Nina Bauge og Tobias Andersen Sammendrag Prosjektet går i hovedsak ut på å videreutvikle en eksisterende database som kun består av en tabell uten relasjoner til å bli en søkbar og skalerbar relasjons database. Databasen skal også utvides så det er mulig å lage symboler for ord som er vanskelig og «uttale» for deler av brukergruppen. Det er et ønske fra oppdragsgiver at databasen skal ha støtte for kontrollert vokabular. Databasen skal kodes på en faglig korrekt måte da det fra oppdragsgivers side kan bli aktuelt å implementere den på andre plattformer og i andre programmeringsspråk. Det skal også være en administrativ brukergruppe som kan validere foreslåtte synonymer og ha muligheten til å importere oppdaterte utgaver av Blissymbols til databasen. Som et brukergrensesnitt til databasen skal det utvikles en web applikasjon. Det kommer til å være mest fokus på funksjonalitet med tanke på at brukergruppen vil være støttegruppen til brukerne av det ideografiske språket Blissymbols og derfor ikke forekommer noen spesifikke behov for universell utforming. Webapplikasjonen kodes i ASP.NET MVC 5 og vi vil bruke MSSQL som databasekontroller. Dagens situasjon I dag brukes teknologien i nesten alt for å øke effektivitet og gjøre ting sikrere. Flere og flere tjenester kommer nå på nettet for å gjøre det enklere for brukere. Vår oppgave er basert på videreutvikling av en eksisterende symboldatabase (Bliss). Videre skal det også implementeres mulighet for at enkelte brukere skal kunne ha en tabell over synonymer. Det er ikke alle brukere av dette ideografiske språket som Vedlegg - Styringsdokumenter 7 klarer å bruke ordene med den rekkefølgen eller sammensettingen av symboler som det er definert i den eksisterende databasen. TurboDevs AS ble grunnlagt av gruppen bak bachelorprosjektet EEGBliss på Høgskolen i Oslo og Akershus 2014. Selskapet har som mål å videreutvikle konseptet bak EEGBliss til et ferdig produkt. EEGbliss er et system som lar brukere av det ideografiske symbolspråket blissymbols styre ulike programmer bare ved å tenke på symbolene. Systemet skal ta i bruk Emotiv sitt elektroencefalogram (EEG) headset for å gjøre avlesningen av tankene til brukerne. Systemet har som oppgave å holde styr på blissymboler og protokollene for programmene brukeren ønsker å interagere med. Per i dag har vi hatt to møter med oppdragsgiver der vi snakket om hva oppgaven vår handler om og har fått informasjon om at per i dag finnes det en database som er basert på symboler. I tillegg har vi snakket om kravspesifikasjonene. Vi har også hatt møter mellom oss gruppemedlemmer hvor vi har diskutert om prosjektet vårt. Mellom oss har vi delt oppgaver i forhold til forprosjektet og snakket om hvordan vi skal håndtere prosjektet. Mål og rammebetingelser Problemstilling Modernisere og videreutvikle en eksisterende symboldatabase, med tilhørende webapplikasjon for å muliggjøre bruk av synonymer og kontrollert vokabular. Læringsmål Lage komplekse relasjoner i en database. Jobbe sammen med en bedrift. Gi en utfyllende akademisk beskrivelse av vårt prosjekt. Prosjektstyring. Vedlegg - Styringsdokumenter 8 Bli kjent med involverte parter, nettverksbygging. Produktmål Utvikle en relasjonsdatabase for Blissymbols. o Skape relasjoner mellom tegn i en eksisterende database o Lage støtte for synonymer o Implementere kontrollert vokabular o Lage brukergrupper for administrering og validering av synonymer Utvikle en webapplikasjon o Funksjonell webapplikasjon som bruker databasen o Gi sluttbrukere og administrerende brukere et grensesnitt mot databasen Vårt arbeid innebærer at denne databasen kan bli brukt over andre plattformer, og at vårt produkt har mulighet til å bli bygd videre på og skalert. Vi har avgrenset prosjektet til å bruke 50 – 100 forskjellige BLISS-symboler, men målet er å utvikle kode som kan skaleres til å ta i bruk de resterende symbolene også. Løsninger /alternativer Ved bruk av MSSQL tenker vi å begynne å lage relasjoner i denne databasen. Til utvikling av webapplikasjonen som tar i bruk denne databasen, har vi tenkt på å bruke ASP.NET MVC 5. Dette sammen med angular.js der det trengs for å få enkelte sider til å fungere dynamisk. Det er mulighet for å bruke PHP å utvikle webapplikasjonen som tar i bruk denne databasen, men da burde vi bruke MySQL til databasen. PHP er gratis å bruke og trenger ikke en egen Windows-server for å hoste webapplikasjonen. ASP.NET trenger Visual Studio, mens PHP er mye mer fleksibelt og kan brukes overalt. Analyse av virkninger Fordeler ulemper ved å bruke LAMP: Linux, apache, MySql og PHP. Vedlegg - Styringsdokumenter 9 Dette er en plattform som ikke har utgifter i forhold til programvarelisenser. PHP er et språk med en slak læringskurve og mange store nettforum for utviklere. PHP er et språk som ikke blir compilert, men som blir interpeted når det kjører. Dette er positivt hvis man jobber med et program som man oppdaterer koden ofte på. Noen ufordeler ved LAMP er at det ikke er helt gjennomgående tilbakekompabilitet ved nye oppdateringer. Dette betyr at en oppdatering av LAMP stakken kan føre til at deler av koden må oppdateres. Det er også noe mer manuell oppdatering på plattformen litt utfra hvilken Linux distribusjon som blir brukt. Fordeler ved bruk av ASP.NET MVC og MSSQL. ASP.NET blir kompilert ned til maskinkode og vil kjøre raskere en PHP. Til utvikling av en .NET applikasjon kan man bruke Visual Studio som er en av de kraftigste IDE'ene som finnes. Man kan komme langt med Visual Studio Express for Web, men den støtter ikke plugins. Et alternativt IDE med åpen kildekode er MonoDevelop. Det er mulig å sette opp ASP.NET på en Linux maskin med Mono og MySql, men det er noen fordeler ved Microsoft server og IIS + MSSQL. Mye av fordelene går på automatiske oppdateringer som ikke vil kreve oppdatering av programkoden og full tilbakekompabilitet ved eventuelle oppdateringer av .NET, MSSQL, IIS eller Windows. Arbeidsmetode Vi vil i store trekk følge Scrum. I motsetning til en arbeidsplass hvor man gjerne jobber med et prosjekt daglig, så vil det ikke være hver eneste dag i en sprint hvor vi får jobbet med oppgaven. Det vi kommer til å gjøre da er å i begynnelsen av en sprint avtale dagene som vi skal jobbe i gruppe med oppgaven og gjennomføre et daglig scrum møte på de dagene. Den første dagen i en sprint vil vi også samlet bestemme alle sakene i saksloggen som skal løses i løpet av sprinten. Enten det er implementasjon eller andre oppgaver. Som utviklerverktøy kommer vi til å bruke redmine som prosjektstyringsverktøy med saksliste, kalender, gantt, forum med mer. Alle i gruppen må følge med på oppdateringer på serveren da det blant annet vil bli lagt ut møtetider og Vedlegg - Styringsdokumenter 10 rombestillinger. Det er også forventet at gruppemedlemmene jobber med å løse problemer innen frister, selv om det ikke er satt opp et fysisk møte. Vi vil også bruke mercurial og bitbucket som versjonskontroll. Dette er ikke for å ha en liste over hvem som har skyld hvis noe går galt, men for å ha muligheten til å finne eventuelle feil i tidligere revisjoner og rette de som nødvendig. Dette er også en fin måte for at gruppemedlemmene kan jobbe på forskjellige deler av koden uten at man blir tvunget til å manuelt sette den sammen. Milepælsplan Hva skal leveres? Uke Dato Forprosjekt 4 23.01.2015 Iterasjon 1 5 01.02.2015 Kravspesifikasjon 6 06.02.2015 Iterasjon 2 7 15.02.2015 Iterasjon 3 9 27.02.2015 Beta testing 9 27.02.2015 Iterasjon 4 11 13.03.2015 Iterasjon 5 13 27.03.2015 Iterasjon 6 15 10.04.2015 Produkt 15 10.04.2015 Fremvise produktet 17 22.04.2015 Testing 17 24.04.2015 Ferdig produkt 17 26.04.2015 Dokumentasjon 21 22.05.2015 Levere hovedprosjekt 22 26.05.2015 kl 12.00 Prøvepresentasjon 23 04.06.2015 Presentasjon 24 08-11.06.2015 Vedlegg - Styringsdokumenter 11 Fremdriftsplan Vedlegg - Styringsdokumenter 12 2.4 Arbeidsplan og fremdriftsplan Arbeidsplan Et mål for oss med hovedprosjektet har vært at arbeidet skal være så likt en reell arbeidssituasjon som mulig for å kunne forberede oss til arbeidslivet. De fleste av oss i gruppen jobber ved siden av studiene, og alle i gruppen har et valgemne dette semesteret. For å sikre et høyt fokus på hovedprosjektet og at vi samtidig kunne fokusere på andre ting ble vi enige om faste dager for jobbing med prosjektet. Vi har alle høye ambisjoner for prosjektet, og ønsket å legge flere timer i dette. Timeplanen ble planlagt som følger: Mandag 8-16 8 Tirsdag 12-18 6 Onsdag Valgemne og jobb Torsdag 8-16 8 Fredag 08-14 6 Lørdag Valgemne og jobb Søndag 12-16 4 Denne varierte en del de to siste ukene før innleveringsfrist, der vi arbeidet hver time vi kunne arbeide. Totalt sett har vi endt opp med å jobbe mer enn de 32 timene pr uke som vi først planla, men det har vært helt i tråd med både ambisjoner og ønske fra den enkelte. Vedlegg - Styringsdokumenter 13 Arbeidsted Vi har benyttet to forskjellige steder for jobbing med prosjektet enten HiOA’s lokaler på Holbergs plass eller Espresso house Pilestredet som har blitt mest benyttet, da vi var så heldige å få et helt bord for oss selv. I tillegg til å være et svært godt egnet lokale, satt vi her med oppdragsgiver i umiddelbar nærhet. Dette gjorde at vi kunne spørre med en gang det dukket opp avgjørelser som måtte tas, og oppdragsgiver kunne umiddelbart involveres i testing av ny funksjonalitet. Arbeidsmetode Gruppen ble inspirert av arbeidsmetoden Scrum. Dette er et rammeverk som er tilegnet for utvikling av programvarebasert system. Denne metoden går ut på at man jobber inkrementelt og iterativt gjennom hele arbeidsprosessen. For hver andre uke hadde vi mål om å bli ferdig med en iterasjon, som skal gjennom analysering og testing. Denne metoden falt vi ut fra til å begynne med på grunn av at vi ikke helt forsto hva oppdragsgiver ønsket seg. Da brukte vi arbeidsmetoden fossefall som deler utviklingen opp i konkrete utviklingsoppgaver. Metoden kalles fossefall fordi resultatet av hver utviklingsoppgave danner grunnlaget for neste. Etter å ha brukt fossefallsmetoden å fått hovedprosjektet til å rulle med oppdragsgiver. Gikk vi over til Scrum metoden. Dette gjorde vi gjennom hele produktutviklingen, og etter fullføring av et mål, satt vi og diskuterte hva som hadde blitt gjort siden sist. Mot slutten av hvert gruppemøte ble det avtalt hva som skulle gjøres videre. Milepælsplan Hva skal leveres? Uke Dato Forprosjekt 4 23.01.2015 Iterasjon 1 5 01.02.2015 Kravspesifikasjon 6 06.02.2015 Iterasjon 2 7 15.02.2015 Iterasjon 3 9 27.02.2015 Beta testing 9 27.02.2015 Iterasjon 4 11 13.03.2015 Iterasjon 5 13 27.03.2015 Iterasjon 6 15 10.04.2015 Produkt 15 10.04.2015 Fremvise produktet 17 22.04.2015 Vedlegg - Styringsdokumenter 14 Testing 17 24.04.2015 Ferdig produkt 17 26.04.2015 Dokumentasjon 21 22.05.2015 Levere hovedprosjekt 22 26.05.2015 kl 12.00 Prøvepresentasjon 23 04.06.2015 Presentasjon 24 08-11.06.2015 Fremdriftsplan Vedlegg - Styringsdokumenter 15 Risiko plan Risikotype Tap av data Risikograd Middels Forebygging Utslag Backup Ingen tap av redmine, data Backup dropbox, og ekstern harddisk Gjøre et Lite tekniske grundig problemer. Vedlegg - Styringsdokumenter Vurdering HUSK å lagre flere steder. Tekniske problemer Høy Grundig forarbeid er 16 forarbeid. Teste mange ulike teknologier og verktøy. Finnes flere veiledere på skolen, og ledere hos oppdragsgiver som kan hjelpe oss. Ha alt vi avtaler skriftlig uansett hva. Sykdom veileder og oppdragsgiver Middels Uenigheter innad gruppen, og med oppdragsgiver. Middels For stor arbeidsmengde Høy Planlegge godt, og fordele arbeid med tidsfrister. Sykdom innad gruppen Høy Holde oss i aktivitet ved hjelp av trening. tingen, hjalp oss veldig med tap av problemer. Ingen problemer, godt fornøyd med det. Gikk bra, kan alltids kommunisere ved hjelp av epost. Litt uenigheter under oppbygningen av database, men kom til en enighet til slutt. Arbeidsmengden ble for stor. Bedre undersøkelser. Ingen sykdom, bare forkjølelse. Vi skulle ikke ha vært optimister, og vært strengere med tidsfrister. Jevnlig fysisk aktivitet hjalp for å unngå sykdom. 2.5 Kravspesifikasjonen Oppgaven: I denne oppgaven er hensikten å lage et Open Source, alternativt kommunikasjonsverktøy for Blissbrukere, med høy grad av brukertilpasning. Et langsiktig mål er å kunne integrere løsningen med andre mainstram kommunikasjonsplattformer som Facebook-chat. Vi vil først gå gjennom produktets hensikt, deretter prioriteringer og avgrensninger fra oppdragsgiver sammen med gruppen. Deretter vil vi gå nærmere inn på brukerhistorier og utfyllende krav. Forklaring på produktets hensikt: Kommunikasjon mellom Bliss-brukere er kommunikasjon mellom brukere som har en begrenset innsikt og forståelse for språk, syntaks og nyansering. Bliss-brukere bruker jevnt over et utvalg symboler som er tilpasset deres daglige behov. Vedlegg - Styringsdokumenter 17 Mange Bliss-symboler er svært komplekse og sammensatte. Enkelte av disse er sammensatt av tilsammen 15 symboler. En Bliss-bruker kan ha et vokabular på totalt 20 symboler, som igjen er sammensatt av totalt 70 symboler. Ved klassiske peke-brett vil brukeren få fullt utbytte av sine 20 symboler uten å ta stilling til dets 70 bestanddeler. Langt på vei kan sammensetting av symboler handle om nyansering og bøyninger I en teknisk løsning må man sørge for at brukeren får fullt utbytte av disse 20 symbolene. Prioriteringer og avgrensninger fra oppdragsgiver og gruppen: Gjenkjennelighet + Konsekventhet > Kontroll Brukeren uttrykker et sammensatt symbol med sitt vokabular[1]. Brukeren får tilgang på en synonymordbok. Synonymene brukeren skriver med baserer seg på den enkelte brukers oppfatning av symboler. Ved å avgrense alternativene til det eksisterende Bliss-vokabularet vil mottageren ha størst forutsetning for å forstå betydningen utfra kontekst. Her ser vi for oss at ett sammensatt symbol kan ha minst ett synonym. Synonymet er en sekvens av andre symboler. Sekvensen er ikke nødvendigvis en “fasit” til hvordan symbolet faktisk er sammensatt. Hensikten ved å ha flere synonymer tilgjengelig på hvert symbol er fordi tolkningen av et begrep kan endre seg med kontekst[2] og brukere seg imellom.[3] Sekvensen kan også være ufullstendig. I et tenkt samarbeid mellom tilbyder og pårørende gir man anledning til å sette sammen og lagre synonymordbøker for brukere Forbehold: Brukeren har et tastatur der ulike taster er ‘mappet’ til grunnleggende symboler Brukeren kan og vil bruke flere symboler enn hva som er umiddelbart tilgjengelig på det synlige tastaturet Oppgave: Å tilrettelegge for å lage søkbare sekvenser av verdier Å søke opp sekvensene og vise resultatet med bildeoutput Autocomplete-funksjonalitet Vedlegg - Styringsdokumenter 18 Oppgaven er ikke: Å sette sammen nye symboler med noe form for geometrisk eller språklig presisjon. Å forholde seg til Bliss-språkets syntaks Å lære seg Bliss-språket Dokumentstandard: Oppdragsgiver har pålagt gruppen å bruke IEEE standard for software dokumentasjon når de skriver. Kode: Oppdragsgiver har pålagt oss å kode på engelsk, og kommentere koden på engelsk. Det er også et krav å legge ut kildekoden som Open-Source. BlissBase er lisensiert under (CC BY-SA 4.0), link finner du her http://creativecommons.org/licenses/bysa/4.0/. Alternativer for tastaturoppsett: Bliss Keyboardlayout: Kanadisk forslag. Kyboardmapping av fysisk tastatur. Kana / Moving Key: Brukt til japanske digitale løsninger. Løser utfordringer i det japanske språket, som er beslektet med vår problemstilling. Setter høye krav til kognitiv funksjonsevne[6]. Digitalt tastatur: Klønete i mange sammenhenger, kan fort utestenge muligheter for Digitalt pekebrett: Aktuelt når man har brukere med svært begrenset vokabular Navigasjonsverktøy for brukeren: Tastatur og mus I dette prosjektet åpner vi for at brukeren benytter seg av tastatur og mus. Vedlegg - Styringsdokumenter 19 Problemstilling: Modernisere og videreutvikle en eksisterende symboldatabase, med tilhørende webapplikasjon for å muliggjøre bruk av synonymer og kontrollert vokabular. Moduler: Modul: Database Utvikle en skalerbar database over Blissymboler som kan benyttes i ulike prosjekter hvor Bliss er involvert, og som kan utvides med flere språk. Databasen skal kunne testes med en funksjonell prototype i .NET. Databasen skal danne grunnlaget for fleksibel bruk av Bliss-språket i sammenheng med ulike kommunikasjonsverktøy. Dokumentasjon og prosessrapport: ER-diagram -gjerne anledning til å evaluere underveis Modul: Søkealgoritme Søkefunksjon/algoritme som kommer med forslag basert på input. Modul: Databaseadministrasjonsverktøy Webapplikasjon Sette sammen og lagre synonymer av objekter basert på sekvenser av objekter. Modul: Kommunikasjonsverktøy Webapplikasjon Tekstfelt med autocomplete Benytter søkealgoritme og databasemodul Både input og output representeres av tilhørende bilde Kan utformes som et chatverktøy Modul: Tastaturmapping Tilegne hver tast på tastaturet et symbol Annet Ressurser: Tilgang på database med bilder Keyboardmapping, Kanadisk Skisser av layout Vedlegg - Styringsdokumenter 20 Presentasjonsform: Integrere webapplikasjon og GitHub Brukerhistorier Brukeren skal kunne sette sammen sekvenser av elementer og lagre dem enkeltvis Brukeren skal kunne begynne å skrive i tekstfeltet med enkeltsymboler og få opp forslag til sammensatte symboler Enkeltelementer i databasen skal kunne knyttes til flere sekvenser. I praksis skal sekvensene kunne fungere som synonymer for enkeltelementene. Enkeltelementene skal kunne knyttes opp mot en id, et bilde, opptil flere sekvenser av synonymer og navn. Navn på hvert enkeltelement vil kunne variere basert på hvilket språk den påloggede brukeren har registrert som hovedspråk. Brukeren har id, navn, språk, ordbok Oppgaven består i å utforme et administrasjonsverktøy, for en digital synonymordbok for et ideografisk symbolspråk. Denne ordboken skal kunne fungere som basis for et kontrollert vokabular. Hovedbrukeren regnes som typisk normalfungerende. Denne hovedbrukeren administrerer en synonymordbok på vegne av sin klient. Hver klient kan være representert av flere hovedbrukere. Hver hovedbruker kan administrere ordbøker på vegne av flere klienter. Hver klient skal ha en hoved-administrator som gir andre hovedbrukere tillatelse til å administrere for sin klient. Status som klientadministrator kan overtras til andre hovedbrukere Klientbrukeren skal ha tilgang på et skriveverktøy. Prosesskrav Testing og godkjenning Databasens funksjoner skal testes med white box testing for å sjekke at koden fungerer som forventet. Etter at white and black box testingen har blitt utført, skal databasens funskjoner Vedlegg - Styringsdokumenter 21 testes på personer som ikke har forhåndskunnskaper om koden for å avdekke feil i koden eller brukerfeil som kan oppstå om man bruker databasens funksjoner på en måte som utviklerne selv ikke har tenkt på. Datagrunnlag: 32 symboler, se vedlegg Testgrunnlag: Setninger: Hver setning består av symboler. Hvert symbol er et sammensatt symbol. Brukeren skal kunne begynne å skrive et ord med grunnleggende symboler og få forslag til auto fullføring av ordet, dvs det sammensatte symbolet, basert på tilgjengelighet i ordboka og/eller brukermønster. Setninger: Jeg vil ha spagetti Buksene er ukomfortable Du lukter godt Værsågod Beklager Skriveverktøy Fremkalling av enkeltsymboler basert på keybindings, basert på tastaturlayout fra bliss canada. Vi ønsker at skriveverktøyet skal ha ferdig mappet keyboard Designvalg Vi ønsker å la gruppen stå fritt her. Datasikkerhet Vi ønsker at studendene skal komme med anbefalinger og tilrettelegge for sikkerhetskopiering og backup av databasen. Vi ønsker et redundant og driftssikkert system [1] Hvorfor ikke bare gi brukeren anledning til å uttrykke dette symbolet direkte? Se avsnittet ‘Forbehold’. [2] Dette kan sammenlignes ved vår hverdagslige opplevelse av å ha glemt et ord, og Vedlegg - Styringsdokumenter 22 beskrive ordet ved å vise til beslektede begreper og rene assosiasjoner. [3] Detaljnivået er ikke konsekvent; Hva er et enkeltsymbol? Er det geometriske former, grunnsymboler eller andre sammensatte symboler? Dette er opp til den enkelte bruker, og dens pårørende, å vurdere. [4] Arbeidsminne, konseptuell forståelse, vokabular Vedlegg - Styringsdokumenter 23
© Copyright 2024