2/3/2014 INSTITUTT FOR INFORMASJONSTEKNOLOGI, HØGSKOLEN I OSLO OG AKERSHUS FÔRIT CDS Mikkel Sannes Nylend Shahariar Kabir Bhuiyan Stian Strøm Anderssen
Denne siden skal være blank. 1
Presentasjon Prosjektgruppe: Gruppe 10 Deltakere: Tittel: Stian Strøm Anderssen, s177437 Mikkel Sannes Nylend, s181115 Shahariar Kabir Bhuiyan, s181104 FôrIt CDS Oppgave: Vi skal lage en sporingsapp for fiskefôr som skal brukes av fiskeoppdrettere til å spore bestillinger av fiskefôr. Appen skal gjøre det mulig for brukere å se hvor forsendelsen er på kart, hvor mye de har bestilt, hvor mye de faktisk får og når de får det. Oppdragsgiver: Goodtech Projects & Services AS Per Kroghs vei 4 1065 Oslo 2
Forord Prosjektet utføres som hovedprosjekt for institutt for informasjonsteknologi på Høgskolen i Oslo og Akershus på vegne av Goodtech Projects & Services AS. I kravspesifikasjonen skal det settes opp krav til hvordan produktet skal lages. Kravene er delt inn i prioriterte og ønskede krav. Ved tid til overs kan de ønskede kravene implementeres. Kravene er satt i samråd med Goodtech. En ordliste som forklarer begreper finnes i siste kapittel. Dette dokumentet fungerer som et styringsdokument under hovedprosejktet. Dokumentet skal være en enighet mellom utviklerne, Goodtech og leverandøren av fiskefôr i prosjektperioden. Kravene spesifisert i dette dokumentet, er krav og retningslinjer for hvordan prosjektet skal utføres. Alle parter skal være inneforstått med de nevnte krav. 3
Innholdsfortegnelse Presentasjon...2 Forord...3 1 Systembeskrivelse...5 2 Rammekrav for systemet...5 3 Funksjonelle krav...6 3.1 Prioriterte krav...6 3.2 Ønskede krav...7 3.3 Tilleggsfunksjonalitet...7 4 Ikke-funksjonelle krav...7 4.1 Produktkrav...7 4.1.1 Brukervennlighet...7 4.1.2 Ytelse...8 4.1.3 Sikkerhetskrav...8 4.1.4 Testkrav og feilhåndtering...8 4.2 Prosesskrav...8 5 Dokumentasjonskrav...9 5.1 Teknisk dokumentasjon...9 5.2 Brukerdokumentasjon...9 5.3 Prosjektdokumentasjon...9 6 Diagrammer og modeller... 10 7 Ordliste... 12 4
1 Systembeskrivelse Vi skal lage en sporingsapplikasjon for fiskefôr for Goodtech Projects & Services AS. Applikasjonen skal gjøre det enklere for brukere å spore bestilt mengde fiskefôr. Formålet med applikasjonen er å gjøre det enklere for kunden å få informasjon om bestillinger. Siden systemet skal brukes av fiskeoppdrettere er det et krav om at applikasjonen primært skal kjøres på mobile klienter. 2 Rammekrav for systemet Systemet skal programmeres ved bruk av Java. Appen skal programmeres med rammeverket Vaadin-Framework som støtter Vaadin- TouchKit. Løsningen skal kunne kjøre på mobile plattformer. o Det vil si mobiler og nettbrett med mobilnett. o Hittil støttes bare ios og Android. o Windows Phone 7/8 skal få støtte av Vaadin etterhvert (forventes i Q2 2014). Appen skal bygges ved bruk av Maven byggevertøy. Det skal også brukes Javascript og CSS for å gjøre applikasjonen pen, brukervennlig og responsiv. Data leveres av en webservice. Wireshark skal brukes for å sikre at datatrafikken til applikasjonen blir så liten som mulig. Applikasjonen skal bygges opp etter de 7 prinsippene om universell utforming: o Enkel og intuitiv i bruk o Forståelig informasjon o Toleranse for feil o Like muligheter for alle o Fleksibel i bruk o Lav fysisk anstrengelse o Størrelse og plass for tilgang og bruk (Sitat ref.: http://no.wikipedia.org/wiki/universell_utforming) 5
3 Funksjonelle krav Funksjonelle krav beskriver funksjoner eller tjenester som et system skal implementere. Vi skiller mellom prioriterte krav, ønskede krav og tilleggsfunksjonalitet. De prioriterte kravene er funksjonene som vi kommer til å ha hovedfokus på å få ferdig. Ønskede krav er funksjonalitet vi ønsker å implementere. Tilleggskrav er krav vi skal implementere hvis vi blir ferdig med prioriterte og ønskede krav tidligere enn forventet. Alle funksjonelle krav er satt i prioritert rekkefølge. 3.1 Prioriterte krav Systemet skal ha en innloggingsfunksjon. En bruker av applikasjonen skal kun se data relevant for sin lokasjon og sine ordre. Systemet skal vise informasjon om hver ordre via en informasjonsside kalt Min side. o Ordrenummer unikt identifikasjonsnummer til ordren o Vareid unikt identifikasjonsnummer til varen o Varenavn Hvilken type vare o Skipning Et oppdrag (båtens tur) o Tidspunkt ordren er lastet på leveransebåt o Planlagt lastet Summen av de planlagte lastemengder på alle ordrelinjer knyttet til en ordre. o Faktisk losset Den totale lastemengde på alle ordrelinjer som faktisk er lastet om bord i båt. o Ordrelinje Hver ordrelunjer har en vare, en ordre kan ha flere ordrelinjer. o Type (bulk/sekk) Måleenheter for levering av fiskefor Systemet skal kun vise aktive skipninger. Det vil si aktuelle ordrer som er på vei, eller som er på vei til å lastes. Systemet skal til enhver tid vise posisjonen til orderen. Systemet skal vise alle ordrelinjer for innkommende ordre. Systemet skal ha en side hvor en kan finne informasjon om leverandøren, Goodtech og om FôrIt CDS. Systemet skal inneholde versjonsinformasjon og driftsmeldinger. Systemet skal vise kommentar til ordrene (info om bestilt vann og diesel). 6
3.2 Ønskede krav Systemet skal vise forventet ankomst for båten. Systemet skal ha en side for innstillinger hvor en kan endre fargevalg, skriftstørrelse og språk. Systemet skal ha en mulighet for å rapportere feil. 3.3 Tilleggsfunksjonalitet Systemet kan vise statistikk i form av grafer. Systemet kan bestille ordrer. Systemet kan kansellere ordrer. Systemet kan endre ordrer. Systemet skal vise historikk over hva en har kjøpt før. 4 Ikke-funksjonelle krav Ikke-funksjonelle krav beskriver kvalitetene til et system. Vi deler opp ikke-funksjonelle krav i to deler, produktkrav og prosesskrav. 4.1 Produktkrav Produktkrav beskriver krav til et ferdig produkt som ikke er en direkte funksjon. Dette omhandler krav til brukervennlighet, ytelse, sikkerhet og testing/feilhåndtering. 4.1.1 Brukervennlighet Ved bruk av applikasjonen skal det være maks 5 trykk på skjerm for å utføre ønsket oppgave. Terskelen for å bruke applikasjonen skal være så lav som mulig. Data som presenteres skal kunne leses raskt og tydelig. Fargevalget skal være intuitivt og enkelt og ivareta prinsippet om universell utforming. Det skal ikke være nødvendig å lese en bruksanvisning før en starter å bruke applikasjonen. 7
4.1.2 Ytelse Når en skal lage webapplikasjoner er det viktig å tenke på datatrafikk. Siden applikasjonen kjører på nett, og ikke lokalt på den mobile enheten, er det mer data som må lastes inn for at applikasjonen skal kjøres. Det er derfor viktig at det blir tatt hensyn til dette når applikasjonen skal utvikles. Systemet skal kun hente den mest relevante informasjonen som brukeren trenger. o Dette er for å gi minst mulig datatrafikk for brukeren. Systemet skal være raskt og responsivt. 4.1.3 Sikkerhetskrav Bruker logger med inn med brukernavn og passord. Applikasjonen skal ligge på Internett. Ved innlogging er det satt et maks antall forsøk på å skrive inn passord. Ved maks antall forsøk vil kontoen til bruker bli låst, og en systemansvarlig må kontaktes. Når applikasjonen skal kommunisere med webservicen, kreves en autentifikasjon med brukernavn og passord, for å bekrefte identiteten til applikasjonen. 4.1.4 Testkrav og feilhåndtering Hvis det oppstår feil i systemet, skal feilen logges og bruker varsles på en intuitiv måte. Logikken i programmet skal enhetstestes ved hjelp av programmerte testmetoder. Applikasjonen skal integrasjonstestes. Alle komponenter testes før de settes sammen til et system. 4.2 Prosesskrav Prosesskrav beskriver krav til prosessen rundt utvikling av produktet. Vi skal følge Scrum med sprinter på 2 uker. Vi skal også følge arbeidsprinsippet KISS. 8
5 Dokumentasjonskrav Dokumentasjonskrav beskriver krav om dokumentasjonen til produktet og prosjektet. Vi skiller mellom teknisk dokumentasjon, brukerdokumentasjon og prosjektdokumentasjon. 5.1 Teknisk dokumentasjon All kode skal kommenteres på en slik måte at en ekstern utvikler lett skal kunne sette seg inn i koden og videreutvikle produktet. Skjerminnhold, meldinger, rapporter og annen dokumentasjon skal skrives på norsk. Variabelnavn og entitetsnavn skal skrives på engelsk for å gjøre videre utvikling enklere i henhold til internasjonale standarder. Under utvikling av produktet følger gruppen Goodtech sine retningslinjer for utvikling. 5.2 Brukerdokumentasjon Det lages en brukermanual som beskriver funksjonaliteten til systemet. Manualen skal ligge på internett og skal kunne lastes ned ved behov. 5.3 Prosjektdokumentasjon Dagbok skal skrives for hver arbeidsdag. All dokumentasjon skal skrives på norsk. Innholdet i sluttdokumentasjonen skal være: o o Testdokumentasjon o Prosjektskisse o Kontrakt o Brukerveiledning o Produktrapport o Prosessrapport o Ordbok o Kilder 9
6 Diagrammer og modeller Diagrammet og modellen under beskriver hvordan applikasjonen kommuniserer. Klienten snakker med webapplikasjonen som ligger i DMZ. Webapplikasjonen snakker med en webservice. Figur 1: Enkel modell av arkitekturen til systemet. 10
Figur 2: Et Use-Case diagram av systemet. 11
7 Ordliste Begrep Bruker Bulk CSS DMZ Java Javascript KISS Maven Scrum Sekk Skipning Sporing Universell utforming Definisjon Kunde som har bestilt vare og som skal bruke applikasjonen til å finne informasjon om ventende leveranse. Mengdeenhet brukt til å beskrive kvantum bestilt fiskefor. Cascada Style Sheet, et designsråk for å definere hvordan ting skal ligge. Demilitarized zone, en sone mellom brannmur og internett. I en DMZ er gjerne porter for web-trafikk fra internett åpne. Programmeringsspråk brukt for utvikling av applikasjonen. Programmeringsspråk som definerer interaksjon i skjermbilder. Keep It Simple, Stupid, sier at designet bør være et sentralt mål og unødvendig kompleksitet bør unngås. Byggeverktøy som programmet bygges opp og kompileres med. Smidig utviklingsmetode brukt til prosjektutvikling. Mengdeenhet for å beskrive kvantum bestilt fiskefor. Selve oppdraget til leveransebåten. Kunde skal få opp lokasjon til båt på kart Prinsipp som omhandler hvordan en applikasjon kan tilpasses alle brukere på en god måte. Prinsippet fokuserer mest på tilpasning av applikasjonen mot mennesker 12
Webservice Wireshark med ulike spesielle behov. En metode for kommunikasjon mellom to enheter over internett. Program for å måle datatrafikk. 13