Hovedprosjekt våren 2007
|
|
- Victoria Tone Marthinsen
- 7 år siden
- Visninger:
Transkript
1 Hovedprosjekt våren 2007 Bachelorstudiet i informasjonsteknologi ved Høgskolen i Oslo Dokument Prosessrapport Prosjekttittel: Telepower Prosjektnummer: Oppgave: Redesign av Telepower - en GSM /GPRS/SMS strømstyringssentral Prosjektperiode: November 2006 mai 2007 Gruppemedlemmer: Siril Alexandra Bache, Line Haugen og Hallvard Welde Oppdragsgiver: Cronus Engineering AS Kontaktperson: Geir Sørum tlf: Veileder: Eva Hadler Vihovde
2 1. Forord Prosessrapporten beskriver prosessen vi har vært igjennom med hovedprosjektet Telepower. Hovedprosjektet er avsluttende prosjekt for bachelorstudiet i informasjonsteknologi ved Høgskolen i Oslo. Rapporten er utformet slik at den skal kunne leses som et selvstendig dokument. Detaljert informasjon om selve produktet finnes i produktdokumentasjonen. Vi forutsetter at leseren har generelle datakunnskaper og har kjennskap til objektorientert systemutvikling. Faguttrykk og forkortelser er beskrevet i dataordboken. 2
3 2. Innholdsfortegnelse 1. Forord Innholdsfortegnelse Sammendrag Om bedriften Bakgrunn for prosjektet Dagens system Telepower Fjernstyring av hyttevarme WinTelepower Dagens tekniske løsning Erfaringer med dagens løsning Mål for prosjektet Rammebetingelser og teknologier Systembeskrivelse Idéfasen Prosjektstyring Arbeidet med å skaffe et prosjekt Telepowerprosjektet tar form - Prosjektskissen Utdypningsfasen Forprosjekt Forprosjektsrapport Arbeidsplan, arbeidsdiagram og fremdriftsplan Risikoanalyse Kravspesifikasjon UML-modellering Funksjonell modell Objektmodell Dynamisk modell Utfordringer i utdypningsfasen Prioriteringer
4 13. Konstruksjonsfasen Konfigurering av utviklingsmiljø Telefonmenyen Funksjonalitet Menyoversikt Implementasjon Rammeverket Implementasjon Programflyt Utvidelsesmuligheter Nye brukergrensesnitt Nye type enheter Utfordringer i konstruksjonsfasen Overgangsfasen Konklusjon Litteratur
5 3. Sammendrag Vår oppdragsgiver er Cronus Engineering AS. Cronus utvikler, prosjekterer og selger nøkkelferdige automatisering/industrielle IT løsninger til norsk industri og offshore. Et produkt de tilbyr er Telepower som er en strømstyringssentral. Strømstyringssentralen benyttes til å kontakte og kontrollere ulike strømstyringsenheter. På grunn av vanskeligheter med å drifte og videreutvikle Telepower, ønsket Cronus å redesigne hele telepowersystemet. Prosjektet vårt danner grunnlaget for utvikling av det nye Telepowersystemet. Vi har laget et rammeverk til strømstyringssentralen og en telefonmeny som et brukergrensesnitt til sentralen. Vi har implementert støtte for to ulike typer styringsenheter, en som kontaktes via GSM nettet og kontrolleres med tonesignalering (DTMF) og en som kontrolleres med SMSmeldinger. Strømstyringsenhetene har en temperatursensor og et relé som kan benyttes til å skru av eller på varme og belysning. 4. Om bedriften Cronus har tatt navnet sitt fra en av de tolv titanene i gresk mytologi, han var gud for tidens fremdrift. Cronus Engineering AS utvikler, prosjekterer og selger nøkkelferdige Automatisering / Industrielle IT løsninger til norsk industri og offshore. I tillegg tilbyr selskapet et bredt spekter av standardprodukter og ingeniør- / servicetjenester. (Cronus.no, u.å.) Cronus Engineering er en del av Cronus gruppen som er en norsk eid selskapsgruppering som igjen er en del av Goodtech ASA. I 2001 ble Umoe Intech AS kjøpt ut fra Umoe konsernet og endret navn til Cronus Engineering. Cronus Engineering har 60 høyt utdannede medarbeidere og har hovedkontor på Karihaugen i Oslo. Vi finner store selskaper som Hydro, Tine, Kraft, Viken, Telenor og Shell blant Cronus sine kunder. Figur 1. Cronus; gud for tiden. Illustrasjon: 5
6 5. Bakgrunn for prosjektet Cronus har opplevd problemer med å drifte og videreutvikle Telepower. De ønsker derfor et fullstendig redesign av Telepowersystemet. Cronus har en visjon for nye Telepower: En modulbasert løsning som bygger på kjente programmerings- og databasestandarder, hvor det er lagt stor vekt på skalerbarhet og enkel implementering av nye tjenester og funksjoner. Vårt prosjekt danner grunnlaget for det nye Telepowersystemet basert på Cronus sin visjon. 6. Dagens system Telepower Ett av produktene Cronus tilbyr er strømstyringssentralen Telepower. Telepowers kunder er alt fra private hytteeiere til større bedriftskunder som Hafslund. Telepower styrer blant annet fasadebelysningen på Karl Johan, lysløyper i marka og er brukt av hytteeiere til å fjernstyre varmen på hytta. Figur 2. S5011 Styringsenhet Telepower ble opprinnelig utviklet av firmaet Cresto. Cresto gikk konkurs i På forespørsel av flere kunder som brukte Telepower, kjøpte Cronus opp konkursboet til Cresto og tok over driften av Telepowersystemet.. Hyttevarme styres fra en telefonmeny som en blir presentert med når en ringer opp Telepowersentralen. De mer avanserte funksjonene som styring av gatelys og tekniske installasjoner styres fra et windowsprogram kalt WinTelepower. 6
7 6.1 Fjernstyring av hyttevarme Fjernstyring av hyttevarme skjer ved at en installerer en GSM basert styringsenhet, kalt Telepower Enheten består av en GSM-modul, et relé, en temperaturføler og en ekstern antenne. For å styre Telepower 5011, ringer brukeren Telepowersentralen og angir en kommando via telefonmenyen. Sentralen videreformidler kommandoen til riktig styringsenhet. 6.2 WinTelepower WinTelepower er et windowsprogram for styring av Telepowerenheter. Dette programmet gir mulighet for effektstyring, styring og overvåkning av utebelysning via GSM-nettet. Det er også mulighet for styring og overvåkning av tekniske installasjoner i næringsbygg som for eksempel sentralfyring. WinTelepower kommuniserer med Telepowersentralen via et analogt modem. Telepowersentralen kontakter styringsenheten via GSM-nettet. 6.3 Dagens tekniske løsning Dagens løsning benytter telefoniscriptspråket Rekoll for kommunikasjon mellom telefonkort og databasen. Databasen som ligger i bakgrunnen er Microsoft SQL 2000 server. Se figur 3 for skisse over dagens løsning. 7
8 Figur 3. Skisse over dagens løsning Illustrasjon: Cronus 6.4 Erfaringer med dagens løsning Rekoll er et telefoniscriptspråk utviklet av et fransk firma og det er få personer i Norge som har kompetanse på dette området. Cronus er nødt til å leie inn kompetanse på Rekoll ved behov. Det er også et problem for Cronus at Rekoll ikke lenger støttes av leverandør. Innholdet i databasen er importert fra en eldre dbase database. I følge Cronus preges databasen av dårlig databasedesign uten relasjoner, noe som har ført til problemer med inkonsekvente data. Kombinasjonen av scriptspråket og ugunstig databasedesign har gjort det svært vanskelig for Cronus å drifte og videreutvikle systemet. 8
9 7. Mål for prosjektet Telepower er et stort system og redesign av hele Telepowersystemet var av for stort omfang for et hovedprosjekt. Prosjektet vårt danner grunnlaget for videre utvikling av det Nye Telepowersystemet. Målet for hovedprosjektet er ikke et fullverdig system som skal settes i produksjon ved prosjektets utløp. Målet er derimot å bygge opp et helhetlig rammeverk for å implementere funksjoner og tjenester til systemet. Det må være enkelt å lage nye grensesnitt til rammeverket. Cronus ønsket at vi laget en telefonmeny som et grensesnitt til rammeverket. Telefonmenyen skal være ett av flere grensesnitt til systemet når det settes i drift. 8. Rammebetingelser og teknologier Cronus skal videreutvikle systemet vi har laget, derfor har de gjort vurderinger og lagt føringer på hvilke teknologier og verktøy vi skulle bruke i prosjektet. Systemet skulle utvikles i Java og bygges med Maven. Vi skulle benytte oss av Asterisk som telefonisystem og Fast AGI som grensesnitt mellom Javakode og Asterisk. Rammebetingelser er ytterligere definert i kravspesifikasjonen. Gitte teknologier er beskrevet i produktdokumentasjonen. 9. Systembeskrivelse Systemet vi har utviklet består av et rammeverk og en telefonmeny som er grensesnittet til rammeverket. Se figur 4. Telefon- nettet Asterisk server FAST AGI PhoneMenu.java Manager GSM- API Rammeverket nettet Styringsenhet S5011 Figur 4. Arkitekturskisse 9
10 Rammeverket er laget med tanke på at det skal være enkelt å lage nye grensesnitt til rammeverket som for eksempel applikasjons-, PDA- og webgrensesnitt. Rammeverket tar i mot en forespørsel om å utføre en oppgave på en styringsenhet, på et gitt tidspunkt. En oppgave kan være å skru av eller på en styringsenhet, lese av temperatur og hente ut bryterstatus. Støtte for flere oppgaver kan legges til senere. Alle forespørsler systemet mottar lagres. På det tidspunkt en forespørsel skal utføres legges den i en kø. Det er separate køer for styringsenheter som benytter forskjellige kommunikasjonsmetoder som for eksempel SMS eller tonesignalering (DTMF). Vi har laget køhåndterere for SMS-styringsenheter og DTMF-styringsenheter. Køhåndterene kjører parallelt og henter ut en oppgave fra riktig kø og utfører den. Hvordan en oppgave utføres er definert i et kommandoobjekt som er knyttet til en forespørsel. SMS-oppgaver utføres ved at en spesielt formatert SMS-melding sendes til styringsenheten. DTMF-oppgaver utføres ved at enheten ringes opp og oppgaven sendes via tonesignalering. Hvis en oppgave mislykkes vil systemet forsøke å utføre den på nytt etter en gitt tid, et gitt antall ganger. Tiden og antall ganger spesifiseres av Cronus i rammeverket. En kunde kan enten høre progresjonen for en oppgave over telefonmenyen eller få tilsendt en SMS-melding når oppgaven er fullført. 10
11 10. Idéfasen Idéfasen er tradisjonell og består først og fremst av lønnsomhetsvurderinger og beslutninger om prosjektets omfang, men også første modellering gjøres her. (Gurholt og Hasle, 2003) For vår del var arbeidet med å finne et aktuelt prosjekt en viktig del av idéfasen. Vi brukte også denne fasen til å gjøre en del avgjørelser i forhold til prosjektstyring og dokumenthåndtering. Arbeidet med prosjektskissen var også en viktig del av idéfasen Prosjektstyring Vi har jobbet sammen i tidligere prosjekter der vi har erfart at vi utfyller hverandre godt og oppnådd en god gruppedynamikk. Likevel satte vi opp en samarbeidsavtale for å forebygge eventuelle konflikter i gruppen. I samarbeidsavtalen definerte vi at vi skulle ha en flat demokratisk gruppestruktur og at vi ønsket å oppnå konsensus der det var mulig. Samarbeidsavtalen er vedlagt som nummer 5. Vi bestemte at prosjektdokumentene skulle optimaliseres for papir og legges ut på prosjektets hjemmeside i PDF-format. Vi bestemte oss for å bruke en online prosjektdagbok Arbeidet med å skaffe et prosjekt Det første vi gjorde for å skaffe oss et hovedprosjekt var å ta kontakt med Storebrand der ett av gruppemedlemmene jobber. De hadde ikke kapasitet til å følge opp et hovedprosjekt. Deretter laget vi en webside med presentasjon av gruppen som vi sendte til en rekke potensielle oppdragsgivere. I tillegg planla vi hvordan vi skulle presentere oss på intervjuer hos mulige oppdragsgivere. Vi ønsket oss et prosjekt som ikke var en ren webapplikasjon, men et prosjekt som ga oss stor variasjon og mulighet til å sette oss inn i nye teknologier. Vi var på møte med Instant Office og Ullevål universitetssykehus. Etter møtene fant vi ut at vi ikke ønsket noen av disse prosjektene. Instant Office hadde en webapplikasjonsoppgave med data 11
12 som skulle leses inn fra en webside, og senere presenteres. Oppdraget på Ullevål var å videreutvikle en eksisterende database i FileMaker. Vi fant ingen av disse oppdragene utfordrende nok. Vi fikk også tilbud om hovedprosjekt hos Forsvarets forskningsinstitutt. De ønsket at vi utviklet en Unmanned Arial Vehicle til deres kampsimulator. Vi fant dette prosjektet litt for smalt. Vi hadde et møte med Cronus Engineering som hadde et hovedprosjektsforslag kalt Telepower. Hovedprosjektet gikk ut på å lage et rammeverk for å utvikle en GSM/GPRS/SMS strømstyringssentral. Vi valgte dette prosjektet fordi det var annerledes og mer utfordrende enn en tradisjonell webapplikasjonsoppgave. Telepowerprosjektet gav oss den variasjonen de andre prosjektene manglet. Prosjektet gav oss muligheten til å sette oss inn i mange nye teknologier. I det hele tatt virket prosjektet meget seriøst og godt organisert. I tillegg antydet Cronus en mulighet for å jobbe videre med prosjektet etter prosjektets utløp Telepowerprosjektet tar form - Prosjektskissen Utarbeidelsen av prosjektskissen var en viktig prosess for å få en bedre forståelse av prosjektet. Forprosjektskissen ble utarbeidet på bakgrunn av informasjon fra vårt første møte med oppdragsgiver, en PowerPoint presentasjon og Cronus sine hjemmesider. 12
13 11. Utdypningsfasen Utdypningsfasen er en analysefase på systemnivå, dvs. ikke på detaljnivå for det enkelte delprodukt. I denne fasen gjøres alle modeller som innvirker på systemet som helhet (Gurholt og Hasle, 2003) Vi startet utdypningsfasen med forprosjektet som ga grunnlaget for videre spesifisering av systemet med kravspesifikasjonen og UML-modelleringen Forprosjekt I forprosjektet skal problemområdet ytterligere defineres. En skal bestemme så nøyaktig og presist som mulig hva problemområdet består av. Et viktig poeng er om problemet kan løses innenfor de rammene som er aktuelle, d.v.s. tids- og arbeidsmessige rammer og de gitte teknologiske rammene. (Iu.hio.no, u.å.) I forprosjektet vårt utarbeidet vi en forprosjektsrapport, arbeidsplan, arbeidsdiagram og fremdriftsplan Forprosjektsrapport På første veiledningsmøte ble vi oppfordret til å skrive så mye som mulig i forprosjektsrapporten. Vi skrev ned alt vi visste om prosjektet. Vi prioriterte å jobbe godt med forprosjektrapporten og brukte mye tid på å skrive og formulere rapporten. Vi brukte white board til brainstorming. Brainstormingen ble utgangspunktet til disposisjonen vår. Etter å ha fått tilbakemelding av både veileder og oppdragsgiver, reviderte vi rapporten. Denne prosessen gikk vi igjennom flere ganger. Med å skrive en grundig og omfattende rapport fikk vi en god forståelse for hva prosjektet innebar. Forprosjektrapporten ga oss et godt grunnlag for andre rapporter, det erfarte vi allerede i kravspesifikasjonen. Vi fikk svært god tilbakemelding fra veileder på forprosjektsrapporten. Det ga oss motivasjon og bekreftelse på at fremgangsmåten vår fungerte bra. 13
14 Teknologiene vi skulle benytte i prosjektet var gitt som rammebetingelser. Vi trengte derfor ikke vurdere ulike teknologier opp mot hverandre, men måtte skaffe oss en overordnet forståelse for de valgte teknologier Arbeidsplan, arbeidsdiagram og fremdriftsplan Etter vi hadde kommet godt i gang med forprosjektet startet vi med arbeidsplanen. Inspirert av RUP (Rational Unified Process) delte vi arbeidet inn i fire faser: idéfase, utdypningsfase, konstruksjonsfase og overgangsfase. Idéfasen var vi alt ferdig med, så arbeidsplanen ble da delt inn i de tre siste fasene. Vi brukte igjen white board til brainstorming som utgangspunkt for disposisjon for arbeidsplanen. Vi forsøkte å lage arbeidsplanen så konkret og detaljert som mulig. Vi satte deretter opp en skjematisk fremstilling av rekkefølgen av oppgavene i arbeidsplanen som resulterte i et arbeidsdiagram. Det ga oss en svært god oversikt over rekkefølgen oppgavene måtte utføres i. Arbeidsdiagrammet ble brukt som utgangspunkt for å sette opp fremdriftsplanen. Vi brukte Excel til å sette opp fremdriftsplanen som et Gantt-diagram. Arbeidet med disse dokumentene ga oss en bedre forståelse av de konkrete oppgaver som skulle utføres og rekkefølgen de måtte utføres i. Se vedlegg for arbeidsplan, arbeidsdiagram og fremdriftsplan, henholdsvis nummer 1, 2 og Risikoanalyse For å forsøke å redusere ulike risikoer bestemte vi oss for å sette opp en risikoanalyse. Risikoanalysen ga oss en oversikt over sannsynligheten for at et problem inntreffer og konsekvensen det eventuelt vil medføre. Sannsynlighet ganger konsekvens ga oss en verdi som vi brukte for å rangere risikoen. I risikoanalysen satt vi opp tiltak for å forebygge de ulike problemene. I tillegg satt vi opp tiltak vi skal sette i verk hvis et problem inntreffer. Risikoanalysen er vedlagt som nummer 7. 14
15 12. Kravspesifikasjon Arbeidet med forprosjektet gav oss en oversikt over hvilke ønsker Cronus hadde til systemet. Vi tok utgangspunkt i disse ønskene og laget et førsteutkast til kravspesifikasjonen. Kravspesifikasjonen ble ytterligere detaljert igjennom flere iterasjoner, basert på tilbakemeldinger fra flere møter med Cronus. Underveis i prosjektet kom Cronus med nye ønsker og omprioriteringer som medførte at kravspesifikasjonen ble oppdatert. Kravspesifikasjonen er et selvstendig dokument og er å finne som en del av sluttrapporten UML-modellering Kravene til systemets skalerbarhet og utvidelsesmuligheter var noe av det viktigste med prosjektet vårt. Dette stilte store krav til modelleringen av systemet. Etter vi hadde ferdigstilt kravspesifikasjonen, begynte vi med en overordnet UML-modellering av hele systemet. Under konstruksjonsfasen gjorde vi en mer detaljert modellering av hvert enkelt delsystem. Vi valgte å se på UML-modellen som tre deler: funksjonellmodell, objektmodell og dynamisk modell Funksjonell modell Den funksjonelle modellen viser systemets funksjonalitet fra en brukers perspektiv. Vi laget et brukstilfelle for å skru av og på et relé på en styringsenhet ved hjelp av telefonmenyen. Brukstilfelle er lagt ved som nummer 4. 15
16 Objektmodell Objektmodellen viser systemets struktur av objekter, attributter, operasjoner og relasjoner. Vi startet med et konseptuelt klassediagram som senere ble detaljert igjennom flere iterasjoner. Nedenfor er det forenklede klassediagrammer over de viktigste elementene i programmet. Mer detaljert informasjon finnes i produktdokumentasjonen. Figur 5. Forenklet klassediagram over programstruktur 16
17 Figur 6. Forenklet klassediagram over Unit-hierarkiet Figur 7. Forenklet klassediagram av kommandoobjekthierarkiet 17
18 Dynamisk modell Den dynamiske modellen beskriver systemets interne oppførsel. Vi laget sekvensdiagrammer for telefonmenyen og rammeverket. Vi brukte en top-down strategi hvor vi først satte opp en grov oversikt over aktivitetene som vi deretter detaljerte gjennom flere iterasjoner. bruker telefonmeny Grensesnitt: RequestService enhet: Unit Ringer opp Angir enhetsnr validateunitid(enhetsnr) getunit(enhetsnr) enhet supportsrelay supportsgetrelaystatus supportsgettemperature Meny Valg addrequest (unitid, commandnr) requestid loop [ status!= success Status!= failed ] status getstatus(requestid) status Figur 8. Prinsipielt sekvensdiagram for kommunikasjon mellom telefonmenyen og rammeverket 18
19 Figur 9. Prinsipielt sekvensdiagram for addrequest 19
20 Figur 10. Prinsipielt sekvensdiagram for DTMF-køhåndterer 12.2 Utfordringer i utdypningsfasen En av de største utfordringene i prosjektet var håndteringen av forespørsler til styringsenheter som kommuniserer på forskjellige måter. Styringsenheten S5011 styres med tonesignalering (DTMF), mens SMS5011 styres med spesielt formaterte SMS-meldinger. Vi trengte en måte å lagre informasjon om hvordan en oppgave utføres for hver type enhet. I tillegg trengte vi å ha separate køer for styringsenheter som benytter forskjellige kommunikasjonsmetoder. Systemet må støtte fremtidige enheter som benytter ny kommunikasjonsteknologi. Det var derfor nødvendig å kunne opprette nye køer dynamisk og ha en fleksibel måte å lagre informasjon om hvordan en oppgave utføres. 20
21 Vi fant ut at det var hensiktsmessig å lage et klassehierarki av kommandoobjekter som inneholder informasjon om hvordan en oppgave skal utføres på en type styringsenhet. For å støtte en ny type styringsenhet som kommuniserer på en ny måte, må det opprettes en ny subklasse av kommandoklassen (Command), se figur 7. For å kunne dynamisk opprette nye køer har laget vi en hashtabell kalt queues. Med kommandoklasse som nøkkel og en kø som holder objekter av kommandoklassen som verdi, se tabell 1. Nøkkel Verdi SmsCommand SmsQueue{ } DtmfCommand DtmfQueue{ } Tabell 1. Hashtabell illustrasjon Hvis det innføres en ny type kommandoklasse opprettes det automatisk en ny oppføring i queues med ny kø for den typen kommandoobjekter, se figur 11. /*gets the class of the command object assosiated with the unitrequest */ Class commandclass = unitrequest.getcommand().getsuperclass(); /* if there is not a queue of the correct command type create one */ if (! queues.containskey( commandclass ) ) { queues.put(commandclass, new LinkedBlockingQueue<UnitRequest>() ); } /*Get the correct queue from the hashtabel of queues */ Queue<UnitRequest> queue = queues.get( commandclass ); <...> /* Add the unitrequest to the correct Queue */ queue.add( unitrequest ); Figur 11. Kodeutsnitt fra RequestService.addToExecutionQueue En annen utfordring var håndtering av oppgaver som mislykkes. Hvis systemet ikke lykkes i å utføre en oppgave skal systemet forsøke å utføre oppgaven på nytt etter et gitt tidsintervall. Vi 21
22 fant en løsning på denne utfordringen som ikke bare løste problemet, men også ga ny ettertraktet funksjonalitet. Ved å lage funksjonalitet for å utføre oppgaver på et fremtidig tidspunkt, kan mislykkede oppgaver forsøkes på nytt etter en gitt tid. I tillegg gir det kunden mulighet til utføre en oppgave på et fremtidig tidspunkt Prioriteringer Utviklingen av køhåndteringsmekanismen var den største og viktigste oppgaven i prosjektet. Etter vi hadde gått igjennom første utkast av UML-modellen av systemet innså Cronus hvor omfattende køhåndteringsmekanismen kom til å bli. De ba oss prioritere å lage en fleksibel og robust køhåndteringsmekanisme fremfor bruker- og gruppehåndtering som hadde vært et ønske til å begynne med. Denne omprioriteringen førte til at vi måtte omarbeide kravspesifikasjonen og UML-modellen. 22
23 13. Konstruksjonsfasen Konstruksjonsfasen består av mange iterasjoner, hvor hver iterasjon inneholder alle de vanlige livssyklusfasene som detaljanalyse, design, implementering og testing dog på et detaljert nivå (Gurholt og Hasle 2003) Vi laget et rammeverk og en telefonmeny. Vi så på disse som separate delsystemer. På hvert enkelt av disse delsystemene har vi gått igjennom fasene analyse, design, implementering og testing Konfigurering av utviklingsmiljø Oppsett av utviklingsmiljøet har vært en tildels tidkrevende og utfordrende prosess. Teknologiene Maven, Asterisk, Manager API og Fast AGI var nye for oss og det krevde at vi brukte tid på å sette oss inn i disse. Vi benyttet oss av Maven 2 som er et prosjekt- og byggeverktøy for Javautvikling. Vi brukte mye tid på å sette oss inn i og konfigurere Maven korrekt. Når Maven var korrekt satt opp og vi hadde lært oss å bruke det, viste det seg å være et meget nyttig verktøy. Dette gjorde det enkelt å bygge Javaapplikasjonen vår og å legge til avhengigheter i prosjektet vårt som for eksempel Asterisk Fast AGI. Telefonmenyen implementerte vi med Asterisk som er et open source telefonisystem og Fast AGI som er et Javagrensesnitt til Asterisk. Det krevde også noe tid å konfigurere og sette seg inn i dette. Vi brukte også Asterisk til å ringe opp DTMF-enheter, det krevde riktig oppsett og bruk av Manager API. 23
24 13.2 Telefonmenyen Telefonmenyen er det grensesnittet ut mot kunden som vi implementerte i dette prosjektet. Det var flere grunner til at Cronus ønsket at telefonmenyen skulle være det første grensesnittet som skulle implementeres: - dagens Telepower kunder er vant til å bruke et telefongrensesnitt - det er viktig at systemet skal være tilgjengelig så lenge du har tilgang til en telefon - Asterisk er relativt ny og uprøvd teknologi for Cronus, de ønsket å undersøke om det var mulig å implementere telefonmenyen med Asterisk og Fast AGI Funksjonalitet Vi implementerte følgende funksjonalitet i henhold til første kravspesifikasjon: - velge en av følgende oppgaver: skru av eller skru på en enhet - velge å utføre oppgaven umiddelbart eller på et framtidig tidspunkt - høre oppgavens progresjon over telefon eller få tilsendt en SMS-melding når oppgaven er fullført Når denne funksjonaliteten var ferdig kom Cronus med ytterlige ønsker: - hente ut bryterstatus - lese av temperaturen på en enhet - liste opp planlagte oppgaver på en enhet - kansellere en planlagt oppgave på en enhet - telefonmenyen endres avhengig av funksjonaliteten til valgt enhet Kravspesifikasjonen ble oppdatert og de nye ønskene ble implementert. Fordi vi hadde laget systemet med tanke på utvidelse ble det lett å implementere disse ønskene, selv om de ikke var med i det første designet. 24
25 Menyoversikt Etter kunden har angitt et enhetsnummer, får kunden opplest en meny basert på de valg som støttes av enheten. Hvis kunden ønsker å skru av eller på enheten, må kunden deretter velge om oppgaven skal utføres umiddelbart eller på et framtidig tidspunkt. Hvis oppgaven skal utføres på et framtidig tidspunkt angir kunden dato og klokkeslett, i tillegg må kunden oppgi et mobilnummer for tilbakemelding. Hvis oppgaven skal utføres umiddelbart får kunden valget mellom å høre progresjon for oppgaven over telefon eller få tilsendt en SMS-melding når oppgaven er utført. Hvis kunden ønsker å hente bryterstatus eller å lese av temperaturen, kontakter systemet enheten for å sjekke temperaturen eller om bryteren står av eller på. Kunden kan også få opplest planlagte oppgaver og eventuelt kansellere en planlagt oppgave Implementasjon Telefonmenyen har vi implementert med Fast AGI som er et Javagrensesnitt til Asterisk telefonisystem. For å kommunisere med kunden benytter telefonmenyen lydfiler. Lydfilene til filnavnene er definert som konstanter, slik at de vil være enkle å forandre. Vi laget en egen klasse SoundEngine som innholder generelle metoder for å blant annet lese opp siffer, tall, ordenstall, dato, tidspunkt og temperatur. I SoundEngine har vi også laget vår egen implementasjon av Fast AGI metoden getdata som mottar tastetrykk fra kundens telefon. Vi har laget vår egen implementasjon som har egne tilpasninger og håndterer unntakssituasjoner. En kunde kan angi en dato for når en oppgave skal utføres. Som regel skal en oppgave utføres inneværende år. For å spare kunden for unødvendige tastetrykk på telefonmenyen setter vi automatisk året oppgaven skal utføres på til inneværende år. Hvis datoen angitt er før dagens dato settes året til neste år. Hvis en 28. desember 2007 legger til en oppgave som skal utføres 1. januar, settes året automatisk til
26 I første omgang testet vi telefonmenyen som et selvstendig produkt, hvor vi benyttet en testklasse som emulerte de bakenforliggende systemene som ikke var utviklet enda. Testen ble gjennomført i henhold til vår testplan. Til slutt i prosjektet ble telefonmenyen testet mot systemet som helhet. Se testrapporten for ytterlige detaljer Rammeverket Hovedsystemet vårt er et rammeverk for å implementere funksjoner og tjenester til det nye Telepowersystemet. Vi har laget den grunnleggende arkitekturen og den bakenforliggende funksjonaliteten. Vi har implementert støtte for to ulike typer styringsenheter som gir ulik funksjonalitet og kommuniserer på forskjellige måter. Rammeverket tar i mot en forespørsel fra et grensesnitt og: - lagrer forespørselen - legger den i riktig kø for utføring på riktig tidspunkt - utfører forespørsler fra køene - lagrer resultatet - sender tilbakemelding til bruker Implementasjon Rammeverket er implementert som en Javaapplikasjon. Rammeverket benytter Asterisk Manager API for å sette opp telefonsamtale til DTMF-styringsenhetene og Asterisk Fast AGI for DTMF kommunikasjonen. SMS-meldinger fra rammeverket sendes ved hjelp av Cronus sin SMS-server. Fleksibilitet og utvidelsesmuligheter har vært viktig, derfor har vi benyttet oss av en lagdeling av programmet. Vi benyttet blant annet Data Aksess Objekter (DAO) til lagring av data i systemet vårt. DAO fungerer som et lag i mellom programmet og datalageret Programflyt Systemet er bygd opp rundt 3 objekter: styringsenhet (unit), en kommando (command) og en forespørsel (unitrequest). En enhet har kommandoobjekter for alle funksjoner den støtter. Kommandoobjektene beskriver hvordan en funksjon skal utføres. Når en oppgave skal utføres 26
27 opprettes det et forespørselsobjekt. Forespørselsobjektet inneholder en referanse til enheten oppgaven skal utføres på, en referanse til kommandoobjektet som beskriver hvordan oppgaven skal utføres og et tidspunkt når oppgaven skal utføres. Forespørselsobjektet lagres i riktig dataaksessobjekt (UnitRequestDAO). Hvis oppgaven skal utføres umiddelbart legges den i riktig kø, basert på kommandoobjektet den referer til. Vi har en egen schedulertråd som hvert sekund sjekker lagrede forespørsler for oppgaver som skal utføres på nåværende tidspunkt og legger de i riktig kø. Se figur
28 En forespørsel opprettes Phonemenu Webgrensesnitt håndterer Applikasjonsgrensesnitt Framtidige utvidelser Rammeverket Grensesnitt Forespørsler lagres alltid i datalageret Hvis opppgaven skal utføres umiddelbart legges den rett i kø Datalager Scheduler Scheduleren sjekker datalageret for planlagte oppgaver som skal utføres Køer Køhåndtererene henter ut forspørsler fra riktig kø og sender de videre til sin køelementhåndterer Køhåndterer Dtmf køelement- Køhåndterer SMS køelementhåndterer DTMF-caller SMS-sender GSM-nettet S5011 styringsenhet SMS5011 styringsenhet Pilene indikerer hvem som initialiserer kontakt. Dataflyten går i de fleste tilfeller begge veier. Figur 12. Programflyt
29 Det initialiseres separate køhåndterere for hver kø. Køhåndtererne sjekker riktig kø for forespørselsobjekter. Hver køhåndterer implementerer en køelementhåndterer (QueueElementHandler) som forsøker å utføre forespørselen. Køelementhåndtereren rapporterer om forespørselen ble vellykket gjennomført eller ikke. Hvis forespørselen ble gjennomført lagres informasjon om dette i systemet. Kunne ikke forespørselen gjennomføres, legges den tilbake i systemet for å utføres på nytt etter en gitt tid, med mindre oppgaven har overskredet maks antall forsøk. Hvis forespørselsobjektet inneholder et mobilnummer, sendes det ut en SMS-melding til kunden når forespørselen enten har blitt gjennomført eller overskredet maks antall forsøk. SMS-køelementhåndtereren henter SMS-kommandoobjektet som innholder en tekststreng som skal sendes til enheten for å utføre oppgaven. Tekststrengen sendes som SMS-melding via Cronus sin SMS-server til enheten. DTMF-køelementhåndtereren ringer opp enheten og kaller på kommandoobjektets execute metode. Execute metoden sørger for nødvendig DTMF-kommunikasjon for å utføre forespørselen Utvidelsesmuligheter Utvidelsesmuligheter er essensielt for systemet. Vi har hatt fokus på at det skal være enkelt å legge til nye brukergrensesnitt og nye typer enheter som enten benytter støttede kommunikasjonsmetoder eller som benytter nye måter å kommunisere på. I tillegg er det lagt opp til at det skal være enkelt å endre måten data lagres på Nye brukergrensesnitt For å gjøre det enkelt å utvide med nye grensesnitt har vi definert hvilke metoder et grensesnitt må implementere i et interface (RequestService). Den lagvise arkitekturen i programmet er også viktig for at det skal være enkelt å utvide med nye grensesnitt.
30 Nye type enheter For nye type enheter som benytter allerede støttede kommunikasjonsmetoder (SMS eller DTMF) må det opprettes ny subklasse av GsmUnit som beskriver enheten. Enheten må få kommandoobjekter som beskriver hvordan enheten utfører oppgavene den støtter. I de fleste tilfeller kan de eksisterende kommandoklassene benyttes, bare med annen informasjon. For nye typer enheter som benytter nye måter å kommunisere på, må det opprettes en ny subklasse av typen Unit som beskriver enheten. Det må også opprettes en subklasse av klassen Command og kommandoobjekter for hver oppgave enheten støtter. Systemet vil automatisk opprette en ny kø som håndterer de nye kommandoobjektene. Det må implementeres QueueHandler og QueueElementHandler for den nye kommandoklassen Utfordringer i konstruksjonsfasen God planlegging i utdypningsfasen gav utbytte i form av få problemer i konstruksjonsfasen. Underveis i konstruksjonsfasen fikk vi flere ønsker til telefonmenyen av Cronus. Telefonmenyen vokste til å bli veldig stor, det ble derfor en utfordring å beholde brukervennligheten til menyen. Vi brukte blant annet brukertesting for å sikre at brukervennligheten var god nok etter utvidelsene. Brukertestingen er beskrevet i testrapporten. Det var litt å utfordrende få rammeverket til å ringe opp styringsenheter og sende riktig DTMFkommando til styringsenheten. Vi måtte først konfigurere Asterisk Manager API riktig for å sette opp samtalen riktig, deretter måtte vi overlate kontrollen til Fast AGI som sørger for DTMFkommunikasjonen. 30
31 14. Overgangsfasen Overgangsfasen. Her er normal programmering ferdig. Endringer gjøres kun for optimalisering (tuning) og for å rette feil ( ) overgangsfasen inneholder ferdigstilling av prosjektet. (Gurholt og Hasle, 2003) I overgangsfasen har vi demonstrert og gjennomgått systemet vi har utviklet for Cronus. Vi laget en brukerveiledning for telefonmenyen. Brukerveiledingen er et selvstendigdokument og inngår i sluttrapporten. Arbeidet med å ferdigstille alle prosjektdokumentene var det viktigste arbeidet i overgangsfasen. 31
32 15. Konklusjon Vi har laget et godt produkt som oppdragsgiver er godt fornøyd med. Vi har lagt mye vekt på fleksibilitet og utvidbarhet, noe vi har fått utbytte av ettersom prosjektet har vokst og endret seg underveis. Vi har laget en brukervennlig og god telefonmeny og et solid rammeverk. Rammeverket kan enkelt utvides til å støtte nye typer enheter, gi ny funksjonalitet og utvides med nye grensesnitt. Det har vært spennende og utfordrende å programmere en strømstyringssentral, prosjektet har krevd at vi har satt oss inn i mange nye teknologier. Vi har dratt god nytte av god planlegging og strukturert arbeid. Samarbeidet i gruppa har fungert meget godt. Vi har alle vært godt motiverte, vi har hatt en god kommunikasjon og vært flinke til å utnytte hverandres sterke sider. Disse faktorene har gjort det gøy å jobbe med prosjektet og har vært viktig for at vi har fått et resultat vi er meget godt fornøyde med. 32
33 16. Figurliste Figur 1. Cronus; gud for tiden..5 Figur 2. S5011 styringsenhet 6 Figur 3. Skisse over dagens løsning... 8 Figur 4. Arkitekturskisse... 9 Figur 5. Forenklet klassediagram over programstruktur Figur 6. Forenklet klassediagram over Unit-hierarkiet Figur 7. Forenklet klassediagram av kommandoobjekthierarkiet Figur 8. Prinsipielt sekvensdiagram for kommunikasjon mellom telefonmenyen og rammeverket Figur 9. Prinsipielt sekvensdiagram for addrequest Figur 10. Prinsipielt sekvensdiagram for DTMF-køhåndterer Figur 11. Kodeutsnitt fra RequestService.addToExecutionQueue Figur 12. Programflyt
34 17. Litteratur Cronus.no (u.å), Cronus Engineering URL: ( ) Gurholt, Gunnar og Thor E. Hasle (2003): Grunnleggende systemutvikling Oslo: Cappelen Iu.hio.no (u.å.): Forprosjekt ( ) 34
35 18. Vedlegg Vedlegg 1 Vedlegg 2 Vedlegg 3 Vedlegg 4 Vedlegg 5 Vedlegg 7 Arbeidsplan Arbeidsdiagram Fremdriftsplan Brukstilfelle Samarbeidsavtale Risikoanalyse 35
Hovedprosjekt våren 2007
Hovedprosjekt våren 2007 Bachelorstudiet i informasjonsteknologi ved Høgskolen i Oslo Dokument Kravspesifikasjon Prosjekttittel: Telepower Prosjektnummer: 07-06 Oppgave: Redesign av Telepower - en GSM/GPRS/SMS
DetaljerHovedprosjekt våren 2007
Hovedprosjekt våren 2007 Bachelorstudiet i informasjonsteknologi ved Høgskolen i Oslo Dokument Testrapport Prosjekttittel: Telepower Prosjektnummer: 07-06 Oppgave: Redesign av Telepower - en GSM/GPRS/SMS
DetaljerHovedprosjekt våren 2007
Hovedprosjekt våren 2007 Bachelorstudiet i informasjonsteknologi ved Høgskolen i Oslo Dokument Produktdokumentasjon Prosjekttittel: Telepower Prosjektnummer: 07-06 Oppgave: Redesign av Telepower - en GSM/GPRS
DetaljerHensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen
Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker
DetaljerForprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008
Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Skrevet av Ole Myrbakken, Fadima Mohamoud, Orji Okoroafor, Karen Arrendondo Side 1 PRESENTASJON Prosjekt tittel: Prosjektperiode: MetaGen 7.jan
DetaljerProduktrapport Gruppe 9
Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette
DetaljerHovedprosjekt 2014, Høgskolen i Oslo og Akershus
Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...
Detaljer1 Forord. Kravspesifikasjon
[Type text] [Type text] 3/5 Hovedprosjekt ingeniørutdanningen 09 Kravspesifikasjon Tittel på hovedprosjektet Tarantell Dashboard Gruppe 28 Bjørn Ove Pedersen Stian Dalviken Antall sider 6 Intern veileder
DetaljerKravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008
Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 1.Forord I dette dokumentet skal vi gi et bildet av de kravene som er satt til prosjektet. Dokumentet er hovedsakelig beregnet som et styringsdokument
DetaljerKravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,
Kravspesifikasjon Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 12.01.2013 Public 2013 Aker Solutions Page 1 of 7 Table of Contents Forord... 3 Om bakgrunnen... 3 Presentasjon...
DetaljerForprosjektrapport For gruppe 20:
Forprosjektrapport For gruppe 20: Kevin Johnny Galåen s135768 Ali Emre Yildirim s135573 Danh Tran s141712 Vibeke Askeland s141436 Fullført: 30.01.2009 Table of Contents Forprosjektrapport... 1 For gruppe
DetaljerStudentdrevet innovasjon
Studentdrevet innovasjon Hovedprosjekt 2013 Høgskolen i Oslo og Akershus Forprosjektrapport av Gruppe 11 Karoline Sanderengen, Mona Isabelle Yari og Randi Ueland 25.01.2013 Studentdrevet innovasjon 9 Innhold
DetaljerHovedprosjekt i data ved Høgskolen i Oslo våren 2007
Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Sluttrapport Høgskolen i Oslo Student: Martin Oppegaard Gruppe: 07-12 Dato: 25. mai 2007 Veileder ved HIO: Eva Vihovde Oppdragsgiver: Bekk Consulting
DetaljerHØGSKOLEN I OSLO OG AKERSHUS. FôrIt CDS. Avslutning
HØGSKOLEN I OSLO OG AKERSHUS FôrIt CDS Stian Strøm Anderssen, Mikkel Sannes Nylend og Shahariar Kabir Bhuiyan Gruppe 10 26.05.2014 Forord Denne rapporten oppsummerer vårt arbeid med FôrIt CDS. Under skriver
Detaljer1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer...
Side 1 1. Forord Dette dokumentet er en kravspesifikasjon og har blitt utarbeidet av arbeidsgiver og prosjektgruppen. Dokumentet består av ni kapitler. Det vil først bli presentert hvem prosjektgruppen
DetaljerGruppe 43. Hoved-Prosjekt Forprosjekt
Gruppe 43 Hoved-Prosjekt Forprosjekt Mobil Applikasjon Utvikling HiOA Bacheloroppgave forprosjekt våren 2017 Presentasjon Gruppen består av: Gebi Beshir Ole-Kristian Steiro Tasmia Faruque s182414 s189141
DetaljerKravspesifikasjon. Forord
Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den
DetaljerDokument 1 - Sammendrag
Dokument 1 - Sammendrag Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Innholdsfortegnelse Sammendrag 1 1. Innledning 1 2. Om
DetaljerDokumentasjon. Prosjektdagbok Timelister. Rolled Up Task. Rolled Up Milestone. Rolled Up Progress. Split. Page 1
ID Name Duration Start Finish 1 Planlegging 95 days Mon 02.10.06 Fri 09.02.07 2 Statusrapport 20 days Mon 02.10.06 Fri 27.10.06 3 Prosjektskisse 25 days Mon 30.10.06 Fri 01.12.06 4 Prosjektweb 31 days
DetaljerPROSESSDOKUMENTASJON
PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00
DetaljerForprosjekt for Accentures Overvåkningssystem
Forprosjekt for Accentures Overvåkningssystem Hovedprosjekt våren 2008 1. februar 2008 Forside Skrevet av: Truls Hagen Selnes Heidi Raae Sjåvik Idun Bolstad Innholdsfortegnelse Forside 1 Innholdsfortegnelse
DetaljerKravspesifikasjon. Forord
Kravspesifikasjon Forord Hensikten med en kravspesifikasjon er å gi et overblikk over programmets funksjonalitet og tilleggsfunksjoner, dette vil si både over de som er utviklet før prosjektstart, og de
DetaljerForprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline
Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016 Pillbox Punchline Gruppe 8 André Østhagen Bye, s198607 Annika Hammervoll, s198611 Hanne Rygge, s198613
DetaljerBachelorprosjekt i informasjonsteknologi, vår 2017
Bachelorprosjekt i informasjonsteknologi, vår 2017 Gruppe 29: Marthe Janson Skogen, s236357, Ingeniørfag - data Odd Einar Hoel, s236313, Ingeniørfag - data Forprosjektrapport Rapporten inneholder presentasjon,
DetaljerKravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften
Kravspesifikasjon Presentasjon Hovedprosjektet gjennomføres ved Høgskolen i Oslo, avdelingen for ingeniørutdanning. Målet med oppgaven er å utvikle en online webshop for bestilling av postkasser. Dette
DetaljerKravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet
Kravspesifikasjon Presentasjon Tittel: Oppgave: Backup for PDA/Smartphones Utvikle en applikasjon for PDA/Smartphones med funksjonalitet for backup av sms, mms, e-post, kontakter, kalender, bilder og dokumenter
DetaljerForprosjektrapport. Gruppe Januar 2016
Forprosjektrapport Gruppe 22 22. Januar 2016 Innholdsfortegnelse Innholdsfortegnelse Presentasjon Sammendrag Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Løsninger og alternativer Løsning
DetaljerHovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App
Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus Forprosjektrapport Bravo Booking App 1 Presentasjon 2 1.1 Gruppe 2 1.2 Oppdragsgiver 2 1.3 Kontaktpersoner 2 1.4 Oppgave 3 2 Dagens
DetaljerForprosjektrapport Bacheloroppgave 2017
Forprosjektrapport Bacheloroppgave 2017 Chat Modul for Webnodes Content Management System Gruppe 32 Adam Asskali, Anmer Seif, Sara Khan 20.01.2017 Veileder G. Anthony Giannoumis Innholdsfortegnelse 1.Presentasjon
DetaljerUML-Unified Modeling Language
UML-Unified Modeling Language Use case realisering Designmodellering 21.01.2004 Kirsten Ribu Use Case diagram Klassediagram Oppførselsdiagrammer: Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram
DetaljerHovedprosjekt. Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport. K-skjema og ferie kalender
Hovedprosjekt Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport Presentasjon Sted og dato Oslo, Jan 9, 2011 Prosjekt tittel Periode K-skjema og ferie kalender Utvikle et registreringssystem
DetaljerUse Case Modeller. Administrator og standardbruker
Vedlegg 1 Use Case Modeller Administrator og standardbruker 2 Use case Logge inn Bruker Bruker ønsker å logge inn Bruker har valgt å logge inn Bruker er logget inn 1. Systemet ber om brukernavn 2. Systemet
DetaljerArbeidsplan. Startfasen. Aktivitet Beskrivelse Ferdig Ansvarlig (Ressurser)
Arbeidsplan En arbeidsplan er en måte å få oversikt over de ulike fasene i prosjektet. I arbeidsplanen har vi delt arbeidet i naturlige faser og detaljert disse med estimert tidsbruk. Hovedfasene er startfasen,
DetaljerProsjektdagbok FRA 30.10-08 TIL 2.3-09. Uke Dato Personer tilstede. Beskrivelse 10:00. 44 30.10-08 Øyvind. Vi dannet gruppe og skrev Statusrapport.
Prosjektdagbok FRA 30.1008 TIL 2.309 Uke Dato Personer tilstede 44 30.1008 48 25.1108 49 02.1208 2 8.109 Tid 10:00 12:00 12:00 12:00 Beskrivelse Vi dannet gruppe og skrev Statusrapport. Kontaktet bedrifter
DetaljerForstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006
Forstudierapport Magne Rodem og Jan-Erik Strøm 18. juni 2006 Innhold 1 Introduksjon 3 2 Bakgrunn for prosjektet 3 2.1 Beskrivelse av problemer og behov........................... 3 2.2 Kort om dagens systemer................................
DetaljerForprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av:
Forprosjektrapport for Agresso R&D Ansettelsessystem Hovedprosjekt våren 2007 31.01.07 Skrevet av: Anders Hartvoll Ruud Christian Årving Leif Martin Næss Sahdia Fayyaz Moghal 1 Sammendrag Prosjektittel:
DetaljerKravspesifikasjon. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23
Utvikling av moduler til CMS for bonefish.no Gruppe 08-23 Kravspesifikasjon for hovedprosjektet utvikling av moduler til CMS for bonefish.no ved Høgskolen i Oslo, avdeling for Ingeniørutdanning våren 2008.
DetaljerKravspesifikasjon MetaView
Kravspesifikasjon MetaView BACHELOROPPGAVE VÅREN 2014 1. Presentasjon Tittel: MetaView Oppgave: Lage en applikasjon og api som skal kommunisere med MetaVision slik at det skal bli enklere for leger og
DetaljerUKE 11 UML modellering og use case. Gruppetime INF1055
UKE 11 UML modellering og use case Gruppetime INF1055 Hva skal vi i dag? Analyse og design - kapittel 5 og 7 UML modellering Ukesoppgaver 3: Modellering av krav UML UML Kompetansemål Modellering av krav
DetaljerProsessrapport. IT-infrastruktur. Prosessrapport. Høgskolen i Oslo. Avdeling for Ingeniører. 23. mai 2008
IT-infrastruktur Prosessrapport Mathias Hagen Balagumar Rajaratnam Høgskolen i Oslo Avdeling for Ingeniører 23. mai 2008 Høgskolen i Oslo Hovedprosjekt i data, 2008 Gruppe 8 side 0 PROSJEKT NR. 08-08 Studieprogram:
DetaljerUse case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?
1/15/2004 1 Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kapittel 8 i Gurholt og Hasle Kirsten
DetaljerHovedprosjektet i Data Høgskolen i Oslo våren 2010
Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Kevin Holmvik s147777 Nikolai Godager s147790 Einar Drivdal s147782 Chau Quoc Quo Do s147792 PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi
DetaljerForprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer
Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 207 Digitalisering av Sentralen UNG Gründer Gruppe 34 Kenneth Di Vita Jensen, s236745 Frank Arne Bjørkmann
DetaljerDagbok. Januar. Uke 2 ( ) Uke 3 ( ) Uke 3 (17.01, 12:45-14:00)
Dagbok Januar Uke 2 (7.1-11.1) Vi har lest halvveis på standard dokumentasjon og jobbet med forprosjektrapport. Vi har hatt vårt første møte med den interne veilederen vår Tor Hasle. Vi fortalte om at
DetaljerForprosjektrapport. Utvikle en plattform for digitalisering av foosballbord.
Forprosjektrapport Tittel Oppgave Periode Openfoos Utvikle en plattform for digitalisering av foosballbord. 3. januar til 15. juni Gruppemedlemmer Amir Ghoreshi Marcel Eggum Neberd Salimi Valentin Rey
DetaljerProsjektrapport Gruppenr FigureGame 3.0
Vedlegg 1. Prosjektavtale Avtale mellom: Reidar Kvadsheim, oppdragsgiver og Robin Juliussen, Olaf Nikolai Hansen og Inger Lill Nystad Prosjektets navn: Figure Game 3.0 Wrath of the Configuration 1. Prosjektets
DetaljerKRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015
KRAVSPESIFIKASJON Kravspesifikasjon er en beskrivelse av hvilke krav oppdragsgiver har til systemet som skal utvikles. Den fungerer som en kontrakt mellom oppdragsgiver og utviklere. DAGSPLANAPPLIKASJON
DetaljerForprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort
Forprosjektrapport Presentasjon Tittel: Oppgave: Gruppemedlemmer: Prosjektgruppe: Veileder: Hovedoppdragsgiver: Kunde av oppdragsgiver: Ansvarlig for gruppen: Faglig veileder hos BEKK: Android app for
DetaljerKRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1
KRAVSPESIFIKASJON Gruppe 2 Hovedprosjekt, Høgskolen i Oslo og Akershus Våren 2014 KRAVSPESIFIKASJON 1 CONTENTS 1. Forord... 3 2. Presentasjon... 3 2.1 Gruppens medlemmer... 3 2.2 Oppdragsgiver... 3 2.3
DetaljerBachelorprosjekt 2015
Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951) Forprosjekt Prosjektets
DetaljerHøgskolen i Oslo og Akershus. Bachelorprosjekt Hacking Cristin. (midlertidig tittel) Forprosjektrapport
Høgskolen i Oslo og Akershus Bachelorprosjekt 2017 Hacking Cristin (midlertidig tittel) Forprosjektrapport Innholdsfortegnelse: 1.0 Presentasjon s. 3 2.0 Sammendrag s. 3 3.0 Dagens situasjon s. 4 4.0 Mål
DetaljerForprosjektrapport. Gruppe 31
Forprosjektrapport Gruppe 31 1 Presentasjon Oppgave: Finne et kodespråk som kan være med på å forbedre kundetilfredsheten og brukervennligheten ved bruk av Telenor sine websider. Periode: 14. januar til
DetaljerUse Case-modellering. INF1050: Gjennomgang, uke 04
Use Case-modellering INF1050: Gjennomgang, uke 04 Kompetansemål Modellering av krav Kunne modellere ulike typer krav UML-diagrammer Innføring i grunnleggende UML-modellering Bruksmønster (use case) Sekvensdiagram
DetaljerUse case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel
Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kirsten Ribu beskriver kravene til systemet,
DetaljerForprosjektrapport ElevApp
Forprosjektrapport ElevApp Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2017 Gruppe 14 Mirko Grimm, s236630 Andreas Krutnes, s236656 Japple John Regalario, s236621 Innholdsfortegnelse
DetaljerTestrapport Prosjekt nr. 2011-22 Det Norske Veritas
Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato
DetaljerKravspesifikasjon. Forord
Forord Kravspesifikasjonen skal gi en oversikt og forståelse over det planlagte systemets funksjonalitet. Dokumentet skal gi både utviklere og oppdragsgivere innblikk i hvordan og hva systemet skal levere.
DetaljerGruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0>
Gruppenavn Prosjektnavn Beskrivelse av design For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning
Detaljer1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen
Kravspesifikasjon 1 Inledning 1.1 Presentasjon Tittel Informasjonsplattform for NorgesGruppen Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer
DetaljerPROSESSDOKUMENTASJON
PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00
DetaljerForprosjektrapport. ERTMS Driver Interface simulering. ERTMS Driver Interface simulering. Alexander Yngling Alexander.Yngling@iu.hio.
Forprosjektrapport ERTMS Driver Interface simulering Prosjektets tittel: ERTMS Driver Interface simulering Gruppe medlemmer: Hallgeir Are Olsen s141454, 3IA Hasan Akin s141460, 3IA Oppdragsgiver: NSB skolen
DetaljerTESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS
TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS Medlemmer av gruppe 35: Joakim Larsen, s150070, 3AB Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB Prosjektperiode:
DetaljerForprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549
Forprosjektrapport Gruppe 34 Bjørn Bergan Abdi Baisa Mads Larsen s161593 s156140 s156151 Magnus Dahl Hegge s153549 Presentasjon Hovedprosjektgruppe 34 består av 4 elever som nå gjennomfører sitt siste
DetaljerProduktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet
Produktrapport Hjelpemiddel portal for Parkinsonforbundet 1 Innhold: Forord ------------------------------------------------------------------------------------------------------2 Planlegging og arbeidsmetode
DetaljerForprosjektrapport. Hovedprosjekt i Informasjonsteknologi. Høgskolen i Oslo og Akershus. Våren 2016
Forprosjektrapport Hovedprosjekt i Informasjonsteknologi Høgskolen i Oslo og Akershus Våren 2016 Gruppe 24 Jon Gillingsrud og Christoffer André Belgen Fredriksen Veileder Thor E. Hasle thor.hasle@hioa.no
DetaljerFORPROSJEKT. Gruppemedlemmer: Raja Zulqurnine Ali Muddasar Hussain (Gruppeleder/Prosjektleder) Zain-Ul-Mubin Mushtaq Christopher Llanes Reyes
FORPROSJEKT I denne rapporten gjør vi analyse for hvor mye arbeid som kan gjøres. Rapporten skal også avgrense prosjektet med en mer presis beskrivelse. Den vil i tillegg blant annet inneholde teknologi
DetaljerGJENNOMGANG UKESOPPGAVER 9 TESTING
GJENNOMGANG UKESOPPGAVER 9 TESTING INF1050 V16 KRISTIN BRÆNDEN 1 A) Testing viser feil som du oppdager under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.
DetaljerForprosjekt bachelor-oppgave 2012
Forprosjekt bachelor-oppgave 2012 Oppgave nr. 4.- Styring av instrumenter. Skrevet av Jan Ingar Sethre. 1 Innhold 1. Mål og rammer... 3 1.1 Bakgrunn... 3 1.2 Mål for prosjektet... 3 1.3 Rammer og forutsetninger...
DetaljerEntobutikk 4.PROSESSRAPPORT VÅR 2011
4.PROSESSRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne prosessrapporten inneholder detaljer om alle metoder vi har benyttet og alle fasene vi gikk gjennom under gjennomføringen av hovedprosjektet ved Høgskolen
DetaljerHensikten med denne delen av kurset. Objektorientering hva er det? Objektets egenskaper. Best practises ved programvareutvikling
Objektorientert systemutvikling, litt UML og Rational Unified Process (RUP) UML Distilled kap. 2 Hensikten med denne delen av kurset Å lære og øve på modelleringsteknikker Å lære om gode designprinsipper
DetaljerStikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client.
Stikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client. Studenter: Magnus Skomsøy Bae, Marius Eggen, Magnus Krane Klasse: 3ING, Systemutvikling Produserer redaksjonelle
DetaljerSystem Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk
System Dokumentasjon Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk System Dokumentsjon 23/04/2018 Systemutvikling og dokumentasjon/ia4412
DetaljerProsessrapport. Nettside, Webshop og Beregningsmodell. Magnus Eriksen, s Øyvind Schjelderupsen, s Peder Sundbø, s141795
Prosessrapport Nettside, Webshop og Beregningsmodell. Eriksen, s141765 Schjelderupsen, s141758 Sundbø, s141795 1 Innholdsfortegnelse Forord...3 Innledning...3 Gruppen...3 Bedriften...3 Tanker rundt prosjektet...4
DetaljerMøtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon.
Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon Møtereferat: 1. møte med veileder I dette møtet presenterte vi oss for
DetaljerForprosjektrapport. Hovedprosjekt for gruppe 13, Anvendt datateknologi våren 2016
Forprosjektrapport Hovedprosjekt for gruppe 13, Anvendt datateknologi våren 2016 1.0 Presentasjon 2.0 Sammendrag 3.0 Dagens situasjon 4.0 Mål og rammebetingelser 5.0 Løsninger/alternativer 6.0 Analyse
DetaljerForprosjektrapport. Hovedprosjekt Gruppe 15
Forprosjektrapport Hovedprosjekt Gruppe 15 Erlend Gunnesen, Lars Sætaberget, Are Inglingstad, Marius Maudal 25.02.2014 Innholdsfortegnelse 1.Introduksjon... 2 1.1 Medlemmer:... 2 1.2 Oppdragsgiver:...
DetaljerHOVEDPROSJEKT I DATA VÅR 2011
PROSJEKT NR. 18 TILGJENGELIGHET åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT I DATA
DetaljerTrafikanten Pluss, delleveranse 2. Gruppe 8 Eivind Hasle Amundsen [eivinha] og Eigil Moe [eigilmo]
Trafikanten Pluss, delleveranse 2 Gruppe 8 Eivind Hasle Amundsen [eivinha] og Eigil Moe [eigilmo] 29. april 2005 Innledning I delleveranse 2 har vi jobbet med spesifikasjonene til gruppen vi kritisterte
DetaljerForprosjekt - Gruppe 12. Hovedprosjekt av
FORSIDE A V D E L I N G F O R I N G E N I Ø R U T D A N N I N G H Ø G S K O L E N I O S L O O G A K E R S H U S Forprosjekt - Gruppe 12 Hovedprosjekt av S AJ ID, OZAI RE (S 1711 9 7), S VEEN, S IMEN (S171208),
DetaljerI dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?
UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering
DetaljerHOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18
HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 INNHOLDSFORTEGNELSE 1. PRESENTASJON 2. SAMMENDRAG 3. DAGENS SITUASJON 4. MÅL OG RAMMEBETINGELSER 5. LØSNINGER \ ALTERNATIVER 6. ANALYSE AV
DetaljerPROGRAMUTVIKLINGSPLAN. Big Data and Machine Learning
PROGRAMUTVIKLINGSPLAN Big Data and Machine Learning Innholdsfortegnelse Produkt beskrivelse... 1 Team beskrivelse... 2 Prosjektets kunnskapskrav... 2 Medlemmer og roller... 2 Program prosessmodell beskrivelse...
DetaljerPROSJEKTDAGBOK GRUPPE 28
PROSJEKTDAGBOK GRUPPE 28 Uke 43-25.10.2009 Tid/Sted P35 Gruppen består av 5 medlemmer. Vi hadde en bli kjent opplegg i dag. Arbeider med å levere inn statusrapporten til fredag 30.10.2009. Uke 48-29.11.2009
DetaljerPresentasjon 2 Gruppe 2 Oppgave 2 Oppdragsgiver 2. Sammendrag 3. Dagens situasjon 3 ServiceNow 3 Coop 3. Mål og rammebetingelser 3 Mål 3 Teknologier 4
Forprosjektrapport Bachelorprosjekt for gruppe 8, våren 2017 Innholdsfortegnelse Presentasjon 2 Gruppe 2 Oppgave 2 Oppdragsgiver 2 Sammendrag 3 Dagens situasjon 3 ServiceNow 3 Coop 3 Mål og rammebetingelser
DetaljerSoftware Development Plan (1. utkast)
Software Development Plan (1. utkast) Høgskolen i Sørøst-Norge Fakultet for teknologiske fag Institutt for elektro, IT og kybernetikk SDP 12/01/2018 Systemutvikling og dokumentasjon/ia4412 Innholdsfortegnelse
DetaljerForprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold,
Hovedprosjekt i data/informasjonsteknologi Høgskolen i Oslo og Akershus Forprosjekt Prosjekttittel Unikia Android applikasjon Gruppe 13 Markus Bugge-Hundere s188909 Morten Wold Aksel Wiig s236326 s232324
DetaljerTestrapport. Studentevalueringssystem
Testrapport Studentevalueringssystem 1 Forord 1.2 Forord Dette prosjektet er et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Ingeniøravdeling
DetaljerKravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer
Kravspesifikasjon Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011 Gruppemedlemmer Adeel Yousaf Khan s141459 Mats Klingenberg Naustdal s148155 Nur M. Ahmed s148108 Thomas Wiborg s161335
DetaljerForprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen
Forprosjektrapport Presentasjon Tittel Informasjonsplatform for NorgesGruppen Oppgave Utvikle en informasjonsplatform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer Joakim Sjögren
DetaljerKRAVSPESIFIKASJON v.1.2
KRAVSPESIFIKASJON v.1.2 PROKAP Prosjektstyringsverktøy for kapasitetsplanlegging G r u p p e 2 6 A n d r é S t e n e r s e n B j a r t e A u n e O l s e n C h r i s t i a n S t r å t h H e n r i k H o
Detaljer6 Kravspesifikasjon. 6.1 Presentasjon. Tittel Precision Teaching App for Android
6 Kravspesifikasjon 6.1 Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes av studenter for å øve på fagpensum. Appen skal ta i bruk prinsipper fra Precision
DetaljerInnholdsfortegnelse. 1. Testing Feiltesting av koden Funksjonstesting: Kilder.10
1 Innholdsfortegnelse 1. Testing... 3 1.1 Feiltesting av koden... 3 1.2 Funksjonstesting:... 7 2. Kilder.10 2 1. Testing Testing av et system er nødvendig for å finne ut om systemet fungere slik det skal
DetaljerOppsummering. Thomas Lohne Aanes Thomas Amble
Oppsummering Thomas Lohne Aanes Thomas Amble 14.11.04 Kapittel 2: Data Modell Mål: Data som skal brukes av applikasjonen blir spesifisert på en formell og likevel intuitiv måte. Resultat: Vi får et konseptuelt
DetaljerDel IV: Prosessdokumentasjon
1 2 Forord Dette dokumentet omhandler detaljert beskrivelse av vår arbeidsprosess gjennom hele perioden med prosjektet. Prosessdokumentasjonen er en viktig del av sluttrapporten, og er delt opp i følgende
DetaljerHovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie
2013 Hovedprosjekt 2013 Gruppe 27 Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie Innhold 1. Presentasjon... 2 2. Sammendrag... 2 3. Dagens Situasjon... 2 4. Mål og rammebetingelser...
DetaljerTeknostorage - Lagersystem. Et lagersystem som på enkel måte kan registrere varer inn og ut fra lager. 3. januar 2012 til 11.
1 Brukerveiledning Presentasjon Tittel Oppgave Periode Gruppemedlemmer Prosjektgruppe Veileder Oppdragsgiver Kontaktperson Teknostorage - Lagersystem Et lagersystem som på enkel måte kan registrere varer
DetaljerSoftware Development Plan
Software Development Plan Værsystem Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk SDP 03/04/2018 Systemutvikling og dokumentasjon/ia4412
DetaljerSRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie
SRD GLIS Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie Innholdsfortegnelse 1. Systemoversikt... 2 2. Tekniske krav... 3 2.1. Funksjonskrav og brukergrensesnitt spesifikasjon... 3 2.2. Begrensninger...
DetaljerTeam2 Requirements & Design Document Værsystem
Requirements & Design Document Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk SRD 22/01/2018 Systemutvikling og dokumentasjon/ia4412
DetaljerArtist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.
Artist webside Innhold Artist webside...1 Gruppe medlemmer...1 Oppdragsgiver...1 Kontaktperson...2 Veileder...2 Oppgaven...2 Muligheter...2 Sammendrag...2 Dagens situasjon...2 Mål og rammebetingelser...3
Detaljer