Prosjektoppgave våren 2007

Like dokumenter
INF1050 Systemutvikling

INF1050 Systemutvikling

Læringsmål. INF1050 dagsorden 14. jan Formålet med prosjektet. Den obligatoriske prosjektoppgaven

UNIVERSITETET I OSLO

Velkommen til. INF Systemutvikling. INF1050 dagsorden 16. jan Læringsmål. Læringskomponenter. Om kurset. o Læringsmål.

Joly. Brukerdokumentasjon for foreleser/administrator

UKE 11 UML modellering og use case. Gruppetime INF1055

Beskjed fra Skagestein

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

Produktrapport Gruppe 9

Metode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

Use Case-modellering. INF1050: Gjennomgang, uke 04

Universitetet i Bergen Det matematisk-naturvitenskapelige fakultet Institutt for informatikk

Del - leveranse Del 2. Inf 2120 fredag Gruppe 1 Knut Johannes Dahle

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

Prosjektoppgave INF3290 høsten 2017

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

Dagsorden. Hovedtemaene i INF102. Fra kjernen og ut. Produksjon av informasjonssystemer. Produksjon av informasjonssystemer

Fra krav til objektdesign

2. Beskrivelse av mulige prosjektoppgaver

Fra krav til objekter. INF1050: Gjennomgang, uke 05

Prosjektoppgave INF3290 høsten 2018

Utvikling fra skallet og inn

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell (ny versjon) Dagens forelesning. Fra krav til objektdesign

Prosjektoppgave INF3290 høsten 2017

INF1050 dagsorden 31. mars Evaluering, 23. april (Uke 17) Hypotetisk-deduktiv metode. Informasjonssystemet gjenspeiler «virkeligheten

Oversikt over flervalgstester på Ifi

INF Obligatorisk innlevering 7

Intermesso. Visjonen... samling av trådene. Veivalget. Et bedre bilde av visjonen?

Her finner du bl.a. oppskrifter på: - Plenumssamlingene (s3) - Skriveseminaret (s4) - Arbeidet i grupper og krav til innleveringer (s5-6)

Eksamen i fag SIF8018 Systemutvikling. Fredag 25. mai 2001 kl

UKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

INF1050 dagsorden 24. jan 2007

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO

NB! Endring i undervisningsplanen

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

Brukermanual. Studentevalueringssystem

Oblig2 - obligatorisk oppgave nr. 2 (av 4) i INF1000

Oppdatering av person/studentforekomster i FS mot folkeregisteret

Hvorfor (og når)? INF1050 dagsorden 19. april Evaluering, 22. april (Uke 16) Informasjonssystemet gjenspeiler «virkeligheten»

Innhold. Innledning Del 1 En vei mot målet

Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5

Prosjektoppgave INF3290 høsten 2016

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

UML-Unified Modeling Language. Prosess-oversikt. Use case realisering

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

Universitetet i Bergen Det matematisk-naturvitenskapelige fakultet Institutt for informatikk

UML-Unified Modeling Language

Gruppedannelse og samarbeid. INF1050 dagsorden 25. jan Hva skal leveres, og når? Formålet med prosjektet

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav?

Forside. Eksamen i IN1030 for Våren Ingen hjelpemidler tillatt.

Kravspesifikasjon. Erik Arisholm. Simula Research Laboratory. Institutt for Informatikk. INF1050-krav-1

Metode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur

Metode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur

Universitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte

Prosjektoppgave INF3290 høsten 2015

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse

INF Obligatorisk prosjektarbeid

SLUTTRAPPORT. gruppe 42 Nils-Kristian Liborg, Bente Brevig, Tom Olav Bruaas, Eirik Lied og Hege Lid Pedersen. 25. november 2002

1. Leksjon 01: Introduksjon til faget Prosjektrettet systemarbeid

Obligatorisk oppgave 1 i INF 4130, høsten 2008

Oblig2 - obligatorisk oppgave nr. 2 (av 4) i INF1000

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell. Dagens forelesning. Fra krav til objekter

Spesifikasjon av Lag emne

SRD. Software Requirements and Design GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

Obligatorisk oppgave INF3221/4221

Obligatorisk oppgave nr. 3 (av 4) i INF1000, våren 2006

UML 1. Use case drevet analyse og design Kirsten Ribu

Oblig2 - obligatorisk oppgave nr. 2 (av 4) i INF1000 v2009

INF Obligatorisk prosjektarbeid INNHOLD:

Oblig2 - obligatorisk oppgave nr. 2 (av 4) i INF1000 h2006

Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

t Institutt for informatikk Erik Arisholm 13. mai 2009 INF1050-oppsummering-1

Planlegging og dokumentasjon

Kolonihageprosjektet. Kandidatene 60, 142, 265, 317 og 381

Forklarende tekst under hvert bilde

Brukerveiledning. For importapplikasjon til Naturbase. Versjon 17. mars 2015

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Testrapport. Studentevalueringssystem

INF100 INNLEVERING 3 HØSTEN 2004

Introduksjon til fagfeltet

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004

Eksamensveiledning. LOKALT GITT SKRIFTLIG EKSAMEN MED Mediekommunikasjon. Sist redigert 06/03/19. Gjelder fra eksamen 2019.

SafeUse Build

UML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

Fylkeskommunenes landssamarbeid. Eksamensveiledning. - om vurdering av eksamensbesvarelser. LOKALT GITT SKRIFTLIG EKSAMEN MED Mediekommunikasjon

Dagens forelesning. o Litt mer om design med UML sekvensdiagrammer. Sentralisert og delegert kontrollstil

Spesifikasjon av Lag emne. Kursregistrering g bruksmønstermodell. Dagens forelesning. Fra krav til objekter

Forprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften

Forprosjektrapport For gruppe 20:

Prosjektoppgave: Bildedatabase. TDT4145 Datamodellering og Databasesystemer. Våren 2008

INF Obligatorisk prosjektarbeid INNHOLD:

Transkript:

Prosjektoppgave våren 2007 Innledning Formålet med kurset er å bli i stand til å delta i utviklingen av informasjonssystemer. Dette innebærer: å kjenne til bruken av informasjonssystemer, å kjenne til ulike strategier for styring av systemutviklingsarbeidet, å kunne planlegge, gjennomføre og evaluere et systemutviklingsprosjekt, å kunne analysere en problembeskrivelse, samt lage en data- eller objektorientert modell ut fra ulike behov i henhold til lover og regler, på bakgrunn av en analysemodell, å kunne utforme og realisere en prototyp med brukergrensesnitt og database, å kunne evaluere en prototyp, å forstå og kunne anvende ett (eller flere) modelleringsspråk med tilhørende utviklingsmiljøer, og å forstå prinsippene for hvordan et databasehåndteringssystem kan benyttes. Prosjektet skal gi erfaring i alle disse temaene, gi en progresjon i studiet, samt utgjøre en del av grunnlaget for vurderingen (karakterbedømmelsen). Prosjektet skal gjennomføres av prosjektgrupper på 3-4 studenter. En prosjektgruppe skal samarbeide om å lage et datamaskinbasert informasjonssystem. Gruppen kan selv velge til hvilke formål informasjonssystemet skal brukes og i hvilket interesseområde (det informasjonssystemet handler om, se side 18 (øverst) i læreboka) det skal brukes. For å opprettholde tilstrekkelig framdrift og sikre at man kommer i mål, bør man velge et interesseområde som minst én i gruppen har kjennskap til. Eksempler på systemer det kan passe å lage innenfor disse rammene, er et informasjonssystem for utleie av filmer, for håndtering av varer og kunder, for reservasjoner og abonnementer i et teater, for romreservasjoner i et hotell, for å holde oversikt over husdyrhold og fôring, for å holde orden på utstillinger og gjenstander for et museum, for en organisasjon med fritidsaktiviteter, eller et adgangskontrollsystem. Det kan være en fordel om gruppen kjenner noen som ønsker et datasystem og lager systemet for deres behov, slik at oppgaven blir mest mulig realistisk. Det er også mulig å utvide eller forbedre et eksisterende system. Videre krav til hvordan systemet skal lages og hvilke verktøy som skal brukes, følger av del-innleveringene nedenfor. Studentene danner selv prosjektgrupper. Om man av en eller annen grunn skulle trekke seg fra en prosjektgruppe, er siste frist for å meddele dette til sin prosjektgruppe 16. februar. De som forsetter etter denne datoen, regner vi med vil fullføre kurset. Det vil skape store problemer for medstudentene om noen trekker seg fra prosjektet senere i kurset. 1

Hva skal leveres? Ved avslutningen av prosjektet (se punkt 6 nedenfor) skal det leveres en rapport på om lag 30 sider som inneholder tre del-rapporter. Rapporten teller om lag 40% i den endelige karakteren. Selv om vurderingen gjøres hovedsakelig på grunnlag av den innleverte rapporten, er det ikke utelukket at sensorene vil prøvekjøre systemet eller inspisere kildekoden for programmene. Derfor må rapporten angi URL og eventuelle passord til det kjørende systemet, samt angi hvordan man kan få tilgang til kildekoden for systemet. Rapporten (i form av de tre del-rapportene) leveres i 2 eksemplarer i ekspedisjonen til Institutt for Informatikk, 2. etasje, Informatikkbygget (Åpent kl. 1200-1500). Fristen er fredag 25. mai kl. 1500. Ikke skriv navn på rapportene, bare kandidatnumre. Kandidatnumrene vil finnes på Studentweb. Identifisér også rapportene med en tittel, f.eks. Avfallshåndteringssystem. Del-rapport 1. En beskrivelse av systemet som er utviklet Denne del-rapporten er av interesse for dem som skal bruke eller videreutvikle systemet. Rapporten kan bygge på tekstene fra de relevante del-innleveringene (se under). Rapporten må omfatte følgende punkter: 1. En oppdatert prosjektbeskrivelse (se del-leveranse 1 nedenfor for detaljer). 2. Bruksmønstrene (se del-leveranse 4) med kortfattede forklaringer. 3. Sekvens- og klassediagrammer for et utvalgt bruksmønster (se del-leveranse 4). 4. Et dataorientert klassediagram (ugruppert og gruppert) og en tabellstruktur for databasen. (se del-leveranse 2). Det ligger i sakens natur at det dataorienterte klassediagrammet antakelig ikke vil stemme overens med klassediagrammet for bruksmønsteret i punkt 3. Ulikhetene bør imidlertid kommenteres. 5. En kortfattet brukerdokumentasjon som viser web-grensesnittet for det ferdige systemet og som beskriver hvordan det skal brukes. Drøft gjerne hvorfor de valgte løsningene er foretrukket framfor mulige alternativer Del-rapport 2. En beskrivelse av selve utviklingsprosessen Denne del-rapporten er av interesse for dem som skal gjennomføre liknende prosjekter. Her skal dere beskrive på hvilken måte prosjektet ble gjennomført. Beskrivelsen skal være forankret i teori som er formidlet i kurset gjennom lærebøker og på andre måter. Rapporten bør omfatte følgende punkter: 1. Rammer for prosjektet (tid, penger, teknologisk plattform, ). 2. Utviklingsstrategier og utviklingsmetoder. 2

3. Milepælsplan (kanskje i flere revisjoner). 4. Risikovurderinger. 5. Oversikt over endringer som følge av reguleringsaktiviteten. 6. Juridiske og etiske betraktninger (hvis relevant). 7. Anvendte utviklingsverktøy og erfaringer med dem. 8. Anvendte plattformer og halvfabrikata og erfaringer med dem. Del-rapporten skal inneholde en oversikt over eventuelle forsinkelser i forhold til de oppsatte innleveringsfristene. Mange og ubegrunnede forsinkelser kan trekke ned i vurderingen av prosjektet. Del-rapporten bør avsluttes med en kort oppsummering av erfaringene fra systemutviklingsprosessen. Hva bør grupper som skal gjennomføre liknende prosjekter passe på? Hva gikk bra, og hva gikk ikke fullt så bra, og hvor ligger fallgruvene? Passer teorien til å beskrive det dere har opplevd i prosjektet? Fikk dere noen overraskelser eller problemer av faglig eller organisatorisk karakter? Hva ville dere gjøre annerledes neste gang dere skulle gjennomføre et tilsvarende prosjekt? Hva fikk dere ut av evalueringen av eget system, og hvilke tiltak ble truffet på grunnlag av den? Delrapport 3. En evaluering av et annet system Denne del-rapporten er av interesse for dem som er i ferd med å avslutte utviklingen av et system og skal ha ideer for den siste finpussen. Se del-leveranse 5 nedenfor. Rapporten som helhet skal avsluttes med en litteraturoversikt, dvs. en liste over de bøker, artikler og nettsteder som teorien er hentet fra. Del-leveranser På veien fram til den avsluttende leveransen skal det leveres fem del-leveranser som spesifisert nedenfor. Disse skal leveres til gruppelæreren for vurdering, tilbakemelding og godkjenning, men teller ikke i karaktervurderingen. Materiale fra del-leveransene vil imidlertid ganske sikkert kunne brukes i den avsluttende tre-delte rapporten beskrevet over. Del-leveransene skal være på pdf-format og ha filnavnene inf1050_brukernavn_delleveranse1.pdf, inf1050_brukernavn_delleveranse2.pdf,, inf1050_brukernavn_delleveranse5.pdf. der brukernavn er brukernavnet på den dokumentansvarlige i prosjektgruppen. Hver fil sendes til gruppelæreren (på epostadressen inf1050-x@ifi.uio.no der x er gruppenummeret). Angi filnavnet i subject-feltet. Er det mer enn en fil, skal filene pakkes (zip, rar, tar, tar.gz). 3

Hver gruppe skal sende bare èn e-post for hver innlevering (den dokumentansvarlige i prosjektgruppen sørger for dette), men alle gruppemedlemmene bør kopieres på denne eposten. Krav til leveransene: Leveransene skal ha: Forside med gruppenummer, dato, leveransenummer, navn på gruppemedlemmer med brukernavn og navn på prosjektet Forklarende overskrifter Beskrivelser til tabeller og figurer Beskrivelser av hvilke antagelser og forutsetninger dere har gjort (Husk sidetall på sidene) Del-leveranse 1. Prosjektbeskrivelse. Ide og mål for det påtenkte systemet 2. februar (Uke 5) Prosjektbeskrivelsen skal danne grunnlaget for en beslutning om det påtenkte systemet skal utvikles eller ikke. (I dette tilfelle er jo utfallet av denne beslutningen gitt.) Leveransen skal bestå av et dokument som skal inneholde en beskrivelse av virksomheten som informasjonssystemet skal betjene og hvilken type virksomhet det er (kortfattet, maks. 1/2 side), formålet med informasjonssystemet, interesseområdet, hvilke virkninger (effekter) systemet er tenkt å gi. Virkningene skal beskrives i forhold til interesseområdet og eksisterende informasjonssystem, en oversikt over hvilke brukergrupper systemet skal betjene og en foreløpig liste over hvilke funksjoner det skal ivareta for hver brukergruppe. Del-leveranse 2. Liten datamodell og tilsvarende database med eksempler på SQL-spørringer 23. februar (Uke 8) Det skal lages en liten kjerne for systemet, bestående av en relasjonsdatabase med minst to tabeller, koblet sammen med primærnøkkel/fremmednøkkel. Databasen skal være dokumentert ved hjelp av en datamodell (et dataorientert UML-klassediagram), både på ugruppert og gruppert form. I relasjonsdatabasen skal det være lagt inn noen få forekomster for testformål. Mot relasjonsdatabasen skal det lages minst en SQL-spørring som gir en primitiv funksjonalitet som stemmer med ett eller flere krav fra funksjonsbeskrivelsen. Leveransen skal bestå av UML-klassediagram på ugruppert form UML-klassediagram på gruppert form 4

Resultatet av å kjøre SELECT * FROM tabellnavn for alle tabellene SQL-spørringen(e) som gir en primitiv funksjonalitet med tilhørende resultater Del-leveranse 3. Kjørende system med web-grensesnitt 16. mars (Uke 11) Det skal utvikles et web-grensesnitt mot den lille kjernen fra del-leveranse 2. Grensesnittet skal kunne kalle opp SQL-spørringen fra del-leveranse 2 og vise frem resultatet. Helst bør det også finnes funksjonalitet til oppdatering av databasen. Systemet skal realiseres ved hjelp av XHTML-koding med FORMS og PHP. (Alternative realiseringsplattformer kan eventuelt brukes etter avtale med gruppelærer.) Leveransen skal bestå av Kortfattet brukerdokumentasjon som viser web-grensesnittet og beskriver hvordan det skal brukes URL til det kjørende systemet Utskrift av kildekoden for programmene Del-leveranse 4. Utvidet realisering som tilfredsstiller et bruksmønster 20. april (uke 16) Det påtenkte systemets funksjonalitet skal være uttrykt med bruksmønstre (use-cases), og det skal forklares hvordan disse bruksmønstrene oppfyller formålet med informasjonssystemet slik det er beskrevet i del-leveranse 1. (Hvis formålet har endret seg underveis, må dere redegjøre for endringene.) Hvert bruksmønster skal spesifiseres i henhold til malen aktør, trigger, normal hendelsesflyt, variasjoner. Vis hvordan et av de mer kompliserte bruksmønstrene (det holder med ett bruksmønster, men velg ikke det aller enkleste!) kan tilfredsstilles i en objektorientert utforming, dokumentert gjennom et sekvensdiagram og et objektorientert klassediagram. Klassene behøver ikke stemme overens med klassene som finnes i datamodellene fra del-leveranse 2, men hvis det blir forskjeller, så drøft gjerne årsakene til dette. Krav til detaljeringsgrad og antall sekvensdiagrammer må dere vurdere selv, men gå gjerne ut fra at det ofte er tilstrekkelig å lage et enkelt sekvensdiagram for "normal hendelsesflyt" for bruksmønsteret. Dersom en "variasjon" er komplisert eller har store konsekvenser for utformingen bør det vurderes å lage et sekvensdiagram også for variasjonen. Bruksmønstre, sekvensdiagrammer og klassediagrammer kan om ønskelig tegnes med utviklingsverktøyet Rational Rose (eller et annet verktøy). Ett av bruksmønstrene må tilsvare den funksjonaliteten som er laget i del-leveranse 3. Utvid det kjørende systemet slik at det tilfredsstiller flere av de andre bruksmønstrene. Det utvidede systemet bør omfatte minst 4 tabeller og 3 ulike skjermbilder i brukergrensesnittet. Vær oppmerksom på at realiseringsplattformen (XHTML, PHP og en relasjonsdatabase) ikke er spesielt objektorientert (selv om vi i PHP kan operere med klasser og objekter), og at nytteverdien av sekvensdiagrammer og 5

klassediagrammer for realiseringen derfor kan være svært begrenset. Selv om man etter dette kan mene at systemet ikke er "ferdig", er det ikke planen å bygge det ytterligere ut innenfor rammen av dette prosjektet! Innleveringen skal bestå av et utkast til del-rapport 1 i den endelige rapporten. Husk å oppgi URLen til det kjørende systemet, og å oppgi nødvendige passord. Del-leveranse 5. Evaluering 4.mai (Uke 18) Dette er en evaluering av del-leveranse 4 fra et av de andre prosjektene. Evalueringen skal overleveres den andre prosjektgruppen dere evaluerer, slik at den kan ta hensyn til kommentarene. Evalueringen skal bestå av 2 deler: 1. Undersøkelse av konsistens mellom de ulike beskrivelsene av systemet (UML-modeller, SQL-setningene som spesifiserer databasen, og prosjektbeskrivelsen (se del-leveranse 1) ). 2. En test av det kjørende systemet. På bakgrunn av prosjektdokumentet lager evaluatørene minst tre oppgaver som dekker den funksjonaliteten som informasjonssystemet skal kunne håndtere. Informasjonssystemet testes deretter med disse oppgavene. Manglende kommandoer i systemet, feil resultat, problemer med å velge eller finne kommandoer, tungvint interaksjon, muligheter for uforutsett ødeleggelse av data og opplevd usikkerhet i forhold til hva datasystemet gjør, skal bemerkes. Del-leveransen skal her bestå av denne evalueringsrapporten. Dokumentasjon av systemet som evalueres skal ikke leveres. Identifiser hvilket system det dreier seg om ved hjelp av tittelen på systemet (f.eks. Avfallshåndteringssystem). Endelig leveranse 25. mai (Uke 21) Finpussing av system og dokumentasjon, bl.a. skal det tas hensyn til forhold som er kommet fram i evalueringsrapporten som dere har mottatt (del-leveranse 5 fra en annen gruppe). En del av problemene som bemerkes i evalueringen kan komme av begrensninger i de verktøyene vi bruker til realiseringen, som PHP og XHTML. Det er ikke nødvendig å velge et annet verktøy for å forbedre systemet, men dere må forklare grunnen til at dere ikke har forbedret sider ved systemet som dere mener er mangelfulle. Her skal den endelige rapporten (i form av de tre del-rapportene) leveres. Husk å kontrollere at det utviklede systemet lar seg kjøre av utenforstående med oppgitt passord. 6