Hovedoppgave. Anvendelse av UML til dokumentering av generiske systemer. Morten Østbø. UML / UML verktøy. Visualisere Felles. Spesifisere.

Størrelse: px
Begynne med side:

Download "Hovedoppgave. Anvendelse av UML til dokumentering av generiske systemer. Morten Østbø. UML / UML verktøy. Visualisere Felles. Spesifisere."

Transkript

1 Hovedoppgave Anvendelse av UML til dokumentering av generiske systemer Morten Østbø UML / UML verktøy Visualisere Felles Spesifisere Programvare utvikler Dokumentere Konstruere System A System B STAVANGER 2000

2

3 HØGSKOLEN I STAVANGER Denne hovedoppgaven med tittelen Anvendelse av UML til dokumentering av generiske systemer er gjennomført i forbindelse med sivilingeniørstudiet ved, retning datateknikk. Oppgaven SIVILINGENIØRUTDANNINGEN er utført for Statoil KTJ IT, sektor for Oppstrøm. Arbeidet er utført ved Statoils hovedkontor på Forus i Prosty prosjektet sine lokaler i perioden januar - juni INFORMASJONSTEKNOLOGI Faglig ansvarlig for denne oppgaven har vært førsteammanuensis ved, Kåre Auglænd. Veiledere i Statoil har vært dr. ing. Harald Rønneberg og siv.ing. Oral Sjøflot. HOVEDOPPGAVE I tillegg til mine to enestående dyktige veiledere, ønsker jeg å takke følgende for å ha hjulpet meg i forbindelse med oppgaven: John Krogstie, Andersen Consulting Linje: Carl-Fredrik Sørensen, TietoEnator Johannes Sametinger Institutt Tor for Stålhane, elektronikk Sintef og databehandling Kåre Veland, Statoil Arnor Solberg, Sintef Geir Abrahamsen og Geir Knudsen Linje datateknikk Semester: Våren 1999 ÅPEN Stavanger, 20. juni 2000 Forfatter: Morten Østbø Veileder(e): Morten Østbø Dr. ing. Harald Rønneberg, siv.ing. Oral Sjøflot Faglig ansvarlig: Kåre Auglænd Tittel på hovedoppgaven: Anvendelse av UML til dokumentering av generiske systemer Emneord/stikkord: gjenbruk av dokumentasjon systemdokumentasjon UML Unified Modelling Language generiske systemer UML-verktøy Sidetall: 108 Stavanger, 20. juni 2000

4 Forord Denne hovedoppgaven med tittelen Anvendelse av UML til dokumentering av generiske systemer er gjennomført i forbindelse med sivilingeniørstudiet ved, retning datateknikk. Oppgaven er utført for Statoil, Konserntjenester Informasjonsteknologi, sektor for Oppstrøm. Arbeidet er utført ved Statoils hovedkontor på Forus i Prosty prosjektet sine lokaler i perioden januar - juni Faglig ansvarlig for denne oppgaven har vært førsteammanuensis ved, Kåre Auglænd. Veileder i Statoil har vært dr. ing. Harald Rønneberg og siv.ing. Oral Sjøflot. I tillegg til mine enestående veiledere ønsker jeg å takke følgende for å ha hjulpet meg i forbindelse med oppgaven: John Krogstie, Andersen Consulting Carl-Fredrik Sørensen, TietoEnator Johannes Sametinger Tor Stålhane, Sintef Kåre Veland, Statoil Arnor Solberg, Sintef Geir Abrahamsen og Geir Knudsen Du vil finne denne rapporten på pdf-format, linker og annet relevant stoff på internett adressen: PDF versjonen av oppgaven har den fordelen at alle referanser fungerer som hyperlinker (navigerbare ved å klikke på referanse). De fleste litteraturhenvisninger har link til internett. Stavanger, 26. juni 2000 Morten Østbø iv

5 Sammendrag Dokumentasjon i form av tekst, figurer og modeller er en viktig del av en programvareleveranse. I vedlikeholdsfasen er det viktig å ha oppdatert dokumentasjon som både kan gi oversikt og detaljer omkring systemet. I en systemportefølge hvor en felles del går igjen fra system til system, er det i tillegg viktig å unngå redundans i dokumentasjonen, samtidig som man er i stand til å tegne et komplett bilde for hvert system. Denne hovedoppgaven fokuserer på hvordan man kan anvende modelleringsspråket UML og UML verktøy til å visualisere en systemportefølge grafisk for å dokumentere systemene uten redundans i modeller og tilhørende tekstbasert dokumentasjon. Oppgaven benytter et konkret prosjekt som eksempel og rettesnor. Den starter med å fastslå prosjektets dokumentasjonsbehov. Dokumentasjonsbehovet er grovt sett å presentere en oversikt over systemet, både overordnet og detaljert, uten å skape redundans i dokumentasjonen. Dette som et utgangspunkt for gjenbruk ved spesifikasjon av nye systemer i samme portefølge. Ut i fra dokumentasjonsbehovene fastsettes krav til modelleringsspråk. Språket må kunne gi en overordnet og detaljert presentasjon av systemet, samtidig som man unngår redundans i diagramtegning. Dette oppnår språket i stor grad ved å kunne uttrykke begrepene brukt innenfor objektorientert teknologi, med andre ord støtte av et objekt perspektiv. UML gjennomgås med fokus på hvordan gjenbruk kan uttrykkes ved hjelp av modelleringsspråket. Deretter foretas en vurdering av UML opp mot fastsatte krav. UML er funnet til å støtte godt opp omkring et objekt-orientert perspektiv. Språket er vurdert til å ha godt potensiale til å kunne uttrykke gjenbruk uten å skape redundans i dokumentasjonen. Neste del av oppgaven ser på hvordan UML verktøy håndterer en systemfamilie, - generiske systemer. Et viktig krav til verktøyet er å kunne presentere et komplett bilde av et system, både felles del og spesiell del, uten redundans i modeller og tekstbasert dokumentasjon. Ingen av de to vurderte UML-baserte verktøyene, Select fra Princeton Software, eller Rational Rose fra Rational Corporation er i stand til å ivareta dette viktige generiske aspektet. Det er mulig å få til deler i verktøyene, men man må sette sammen modellene for hvert system i portefølgen. Dermed får man redundans i diagramtegning. Likevel kan man med verktøyene ivareta andre viktige sider ved dokumentasjonen av et system, nemlig å få presentert en oversikt over systemet, og man får et verktøy hvor det er mulig å samle all dokumentasjon tilhørende et system, både modeller og tekstbasert dokumentasjon. Rational Rose er vurdert til å være det verktøyet som har kortest vei til å imøtekomme fastsatte krav. Min anbefaling til prosjektet blir derfor (i prioritert rekkefølge): 1. Innkalle begge leverandørene til møte for å se hva som er mulig å oppnå av forpliktende avtaler omkring fremtidig utvikling. Det er essensielt å få avtalefestet en gjennomføringsplan for implementasjon av ikke-oppfylte absolutte krav. 2. Dersom punkt 1 av forskjellige årsaker ikke ønskes gjennomført, anbefaler jeg å utnytte de mulighetene som eksisterer i Rational Rose. Det kan se ut som om prosjektet blir nødt til å leve med redundans i dokumentasjonen i en tid til, men har nå mulighet til å få på plass en overordnet og detaljert oversikt over systemene. v

6

7 AnvendelseavUML Innhold 1 Innledning Oppgavetekst Bakgrunn Mandat Definisjon generisk system Målsetting Avgrensninger Kort om Statoil Statoil konsern Statoil KTJ IT Prosty prosjektet Midas modell for systemutvikling Rapportens oppbygning Prosty dokumentasjon Terminologi og begreper Forventet dokumentasjon Dokumentasjon er det sekundære Kunsten å utelate Objekt-orientert dokumentasjon Visjonsdokument og kravspesifikasjon ISO veiledning for dokumentasjon Midas dokumentkrav Dagens Prosty dokumentasjon Forstudie Kravspesifikasjon Funksjonell spesifikasjon Testplaner Forvaltningsdokumentasjon Prosty dokumentasjonsbehov Brukerdokumentasjon Driftsdokumentasjon Systemdokumentasjon Oppsummering Krav til modelleringsspråk Rammeverk for vurdering av språkkvalitet Dugelighet for domene Dugelighet for deltakernes kunnskap Dugelighet til å uttrykke deltakernes kunnskap Dugelighet for bedring av felles forståelse Dugelighet til bedring av teknisk aktørs tolkning Brukergrupper (aktører) Krav til modelleringsspråk for Prosty Overordnede krav Elementene i rammeverket Vektlegging av krav Dugelighet for domene Dugelighet for deltakernes kunnskap...42 vii

8 AnvendelseavUML Dugelighet til å uttrykke deltakernes kunnskap Dugelighet for bedring av felles forståelse Dugelighet til bedring av teknisk aktørs tolkning Oppsummering og videre arbeide Unified Modelling Language (UML) Generelt om UML standarden Generelle konsepter UML diagrammer Use Case diagram Aktivitetsdiagram Samhandlingsdiagram Sekvensdiagram Tilstandsdiagram Klassediagram Objektdiagram Komponent diagram Produksjonsettingsdiagram UML utvidelsesmekanismer Stereotyper Tagged values Constraints Profiler UML til gjenbruk Avhengigheter Interface Gjenbruk av komponenter Collaborations, frameworks og patterns Parameterisering av pakker (template packages) Gjenbruk av Use Cases Dokumentering av arbeidsprosesser Modellering av databaser Modellering av rapporteringslag Black-box komponent modellering Oppsummering og videre arbeide Vurdering av UML som modelleringspråk UML og språkkvalitet Dugelighet for domene Dugelighet for deltakernes kunnskap Dugelighet til å uttrykke deltakernes kunnskap Dugelighet for bedring av felles forståelse Dugelighet til bedring av teknisk aktørs tolkning Konklusjon UML og språkkvalitet Hva UML løser og ikke løser Aktuell bruk av UML Andre aspekt Anbefaling Oppsummering...72 viii

9 AnvendelseavUML 6 UML verktøy Generelt om CASE verktøy Byggesteinene i verktøyet Prosessuavhengig verktøy Brukergrupper og behov Krav til UML verktøy Overordnede krav Uaktuelle kriterier Den ideelle løsning av det generiske aspekt Kilder til krav Vektlegging av krav Generisk aspekt Dokumentasjon Flerbruker støtte, database og utvekslingsformater Diagrammer og UML notasjon Navigering, synsvinkler (views) og skjuling av informasjon Konfigurasjonsstyring Systemkrav Leverandør Oppsummering og videre arbeide Vurdering av UML baserte verktøy Select Kort introduksjon til Select Generisk aspekt Dokumentasjon Flerbruker støtte, database og utvekslingsformater Diagrammer og UML notasjon Navigering, synsvinkler (views) og skjuling av informasjon Konfigurasjonsstyring Systemkrav Leverandør Drøfting av generisk aspekt i Select Rational Rose Introduksjon til Rational Rose Generisk aspekt Dokumentasjon Flerbruker støtte, database og utvekslingsformater Diagrammer og UML notasjon Navigering, synsvinkler (views) og skjuling av informasjon Konfigurasjonsstyring Systemkrav Leverandør Drøfting av generisk aspekt i Rose Oppsummering og videre arbeide Konklusjon og anbefaling til Prosty prosjektet Konklusjon på verktøybruk Oppsummering av Select Karaktersum for Select Oppsummering av Rational Rose...98 ix

10 AnvendelseavUML Karaktersum for Rational Rose Drøfting av konsekvenser av eventuelle valg Konsekvenser av å ikke benytte UML verktøy Konsekvenser av å benytte UML verktøy Forkaste UML Konklusjon på bruk av verktøy Anbefaling til Prosty prosjektet Anbefaling på verktøy valg Anbefaling på hvordan UML bør tas i bruk Anbefaling på hvordan verktøy bør tas i bruk Anbefaling omkring Select Forslag til videre arbeid Oppsummering Ordliste og forkortelser Referanser x

11 Innledning 1 Innledning Dette kapittelet omhandler oppgavens utgangspunkt, oppgaveteksten slik den er formulert fra veilederne i Statoil, bakgrunn og forutsetninger for oppgaven, egen tolkning av oppgaveteksten med presiseringer og avgrensninger. Ut fra dette formuleres målene med arbeidet. Kapittelet inneholder også en presentasjon av Statoil og Prosty prosjektet som er benyttet som eksempel og rettesnor. 1.1 Oppgavetekst Oppgaveteksten slik den ble formulert av veilederne i Statoil, Oral Sjøflot og Harald Rønneberg: Anvendelse av UML 1 til dokumentering av generiske systemer I forbindelse med Prosty prosjektet satses det på omfattende gjenbruk av kode og dokumentasjon. På dokumentasjonssiden har ikke prosjektet lykkes med å finne en god måte for å få til gjenbruk. Det blir mye kopiering som resulterer i mye redundans som krever oppdatering på flere steder. UML har blitt lansert som en kandidat for å få til mer gjenbruk av dokumentasjon i Prosty. Oppgavengårutpå: å sette seg inn i dokumentasjonsbehovet til Prosty og på det grunnlaget komme opp med hvilke krav som stilles til et modelleringsspråk for at prosjektet skal lykkes med gjenbruk av sin dokumentasjon å sette seg inn i UML og på det grunnlaget avgjøre om UML tilfredstiller kravene Prosty stiller å, hvis svaret på forrige punkt er ja, sette seg inn i minst to verktøy som støtter UML for å identifisere det best egnede verktøyet å til slutt gi en anbefaling til Prosty prosjektet. 1.2 Bakgrunn Prosty prosjektet er et utviklingsprosjekt som har pågått i Statoil i 4 år. Pr. i dag stilles ingen formelle krav til utformingen av dokumentasjonen til systemet. Dette har ført til at det stort sett er den enkelte utviklers forgodtbefinnende og egne preferanser, sammen med tidligere praksis, som i stor grad avgjør utseendet og kvaliteten på dokumentasjonen. I presset mellom ferdigstillelsestidpunkt og kostnader har dokumentasjon blitt et nedprioritert område og i en stor grad overlatt til ekstern leverandør. Det spesielle med Prosty prosjektet er at det er mye (ca %) gjenbruk av kode. Det samme har en til nå ikke oppnådd med dokumentasjonen selv om det eksempelvis kunne vært behov for å ha en generell dokumentasjonsbit som automatisk oppdateres alle steder den er tatt i bruk når det er oppdateringer i den generelle dokumentasjonen. Statoil benytter et eksternt konsulentselskap, TietoEnator, under konstruksjonsfasen. TietoEnator 1. Eng. fork.: Unified Modelling Language. Modelleringsspråk for programsystemer. Omtalt i kapittel

12 Innledning har nylig tatt i bruk UML verktøyet Select. Samtidig ser vi at UML er i ferd til å utvikle seg som et standard universelt modelleringsspråk og ønskes derfor nå vurdert for eventuell bruk i prosjektfaser hvor Statoil er involvert. Prosjektet ønsker en anbefaling på hvorvidt UML er egnet til å dokumentere hele eller deler av systemet, og dersom UML er velegnet, ønskes en vurdering av UML-basert verktøy som kan generere og lagre dokumentasjonen. Hovedoppgaven har en tidlig arbeidshypotese som går ut på at UML er en velegnet notasjon for dokumentering av generiske systemer og som legger tilrette for gjenbruk av dokumentasjon. UML alene gir relativt liten mergevinst, men det kan oppnås en betydelig mergevinst ved anvendelse av et velutviklet verktøy. 1.3 Mandat Mandatet for oppgaven er å se på Statoils Prosty prosjekt sin praksis for systemdokumentasjon. Å sette seg inn i Prosty prosjektets systemdokumentasjon og dokumentstruktur er sentralt for gjennomføringen av oppgaven. På bakrunn av Prosty prosjektets dokumentasjonsbehov og krav til dokumentasjon settes opp generelle krav til modelleringsspråk for dokumentering av generiske systemer. I en stor bedrift som Statoil er det er ikke bare teori og praksis som påvirker veivalget. Leverandører, innkjøpte systemer, interne og eksterne rådgivere, samt strategier og planer legger alle en føring for mulige veivalg. I denne oppgaven tar en ikke hensyn til eventuelle føringer fra disse parter. Videre går mandatet ut på å gjøre seg grundig kjent med UML, og de mulighetene dette gir for dokumentering av systemer. Herunder ligger en fordypning i UML semantikken, hvilke utbyggingsmuligheter og muligheter for lokale tilpasninger som eksisterer eller kan foretas. Etter en vurdering av UML språkets dugelighet til dokumentering av generiske systemer vil det eventuelt bli nedsatt krav til UML verktøy og deretter foretatt en praksisbit som går ut på å teste to av markedets antatt beste systemer. Etter foretatt test vil det bli trukket en konklusjon og gitt en anbefaling på hvordan Prosty prosjektet for fremtiden bør basere sin systemdokumentasjon for generiske systemer som Prosty prosjektet. Det vil også bli fremmet forslag til videre arbeid. 1.4 Definisjon generisk system Booch definerer en generisk klasse som: En klasse som opptrer som en mal for andre klasser, og hvor malen kan parameteriseres av andre klasser, objekter og/eller operasjoner. En generisk klasse må instansieres (med utfylte parametre) før objekter kan opprettes. [Booch 94]. Booch definerer også en generisk funksjon som: En operasjon på et objekt. En generisk funksjon i en klasse kan redefineres i subklasser. Dvs. For et gitt objekt er dette implementert gjennom et sett av metoder deklarert i forskjellige klasser relatert gjennom deres arvehierarki. [Booch 94]. Egen definisjon på generisk system: Et generisk system er et programsystem bygget opp av parameteriserbare moduler/komponenter og som har den fordelen at det lett lar seg tilpasse ulike og nye brukerkrav ved å sette sammen eksisterende komponenter med nye parameterverdier. -12-

13 Innledning Ikke alle systemer man i dagligtale kaller generiske er strengt generiske. Typisk ser man systemer hvor visse deler av systemet går igjen fra en implementasjon til en annen, mens det også eksisterer spesielle biter for hver implementasjon. Utfordringen for utviklerne blir å maksimere gjenbruksgraden både av kode og dokumentasjon. Prosty systemet er et generisk system og prosjektet benytter komponentbasert utvikling for å oppnå generiskhet. TietoEnator har kommersialisert systemet under et annet navn, Energy Components, og fra deres internettsider kan en lese hvilke fordeler komponent-basert utvikling gir [TietoEnator 00]: Tilbyr et felles teknologisk fundament for hele industrien. Gir høyere gjenbruksnivå. Gir mekanismer for sømløs integrasjon med andre forretningsapplikasjoner. Forbedrer produktiviteten. Forbedrer kvaliteten (utvikles og testes en gang, brukes om igjen). 1.5 Målsetting Overordnet målsetting med gjennomføringen av denne hovedoppgaven er: Gi en anbefaling til Prosty prosjektet på hvorvidt UML er et egnet modelleringsspråk, og eventuelt anbefale ett UML-basert modelleringsverktøy. Delmål: Presentere en forståelse og definisjon av begrepet generiske systemer. Presentere en oversikt over Prosty prosjektets systemdokumentasjon. Utarbeide krav til modelleringsspråk. Gi en oversikt over UML og hvilke muligheter dette modelleringsspråket gir. Diskutere og fastsette krav som bør stilles til et UML verktøy ut i fra et generisk system synspunkt. Gjennomføre test av UML verktøy og vurdere dugelighet av disse opp mot fastsatte krav. Trekke konklusjoner og gi en anbefaling på om UML er et egnet modelleringsspråk for prosjektet og eventuelt hvilket (av de to) UML-verktøyene Prosty prosjektet bør benytte. 1.6 Avgrensninger Det er ikke en del av oppgaven å: Se på de fasene i utviklingsløpet hvor Statoil ikke er involvert, men hvor konsulentselskapet TietoEnator foretar utviklingen. Fokus vil derfor ligge på de tidlige fasene, og ikke minst på innføring- og bruksfasen, hvor dokumentasjonen er levende. Å fokusere på bruker- og driftsdokumentasjon. Fokus vil bli satt på systemdokumentasjon. Bruker- og driftsdokumentasjon vil bli fokusert bare i mindre grad. -13-

14 Innledning Etablere rutiner for systemdokumentasjon og sette opp formelle krav til systemdokumentasjon. Utarbeide UML profiler 1 tilpasset Prosty prosjektets arbeidsområde. I forbindelse med vurderingen av UML kunne det vært naturlig å se nærmere på UML profiler og vurdere gevinsten av å etablere UML profiler for oljerelaterte produksjonsdata. Opprette/utvikle UML basert dokumentasjon for Prosty prosjektet. Denne oppgaven vil begrense seg til å gi en vurdering/anbefaling av hvorvidt UML er egnet til å dokumentere slike systemer som Prosty, - generiske systemer. Anskaffe og innføre et UML basert verktøy for dokumentering av generiske systemer. Det lengste denne oppgaven vil gå er å anbefale bruken av et verktøy ved å vise til gevinsten som kan oppnås ved bruk. Foreta kost/nytte vurdering. Dette er en teknisk anbefaling. 1.7 KortomStatoil Statoil konsern Den norske stats oljeselskap a.s - Statoil - er en av verdens største nettoselgere av råolje, og en betydelig leverandør av naturgass i Europa. I Skandinavia er Statoil den største markedsfører av bensin og oljeprodukter. Statoil er den ledende aktør på norsk kontinentalsokkel. De senere årene har konsernet foretatt en gradvis ekspansjon av sin internasjonale oppstrømsvirksomhet. [Statoil 00] Selskapet har til formål selv eller sammen med andre å drive undersøkelse etter, og utvinning, transport, foredling og markedsføring av petroleum og avledede produkter, samt annen virksomhet. Statoil har ansvaret for å ivareta interessene til Statens direkte økonomiske engasjement i interessentskap for undersøkelse og leting etter, utbygging, produksjon og transport av olje og gass på den norske kontinentalsokkelen. Selskapet ble stiftet i Samtlige aksjer eies av den norske stat. [Statoil 00] I 1998 hadde konsernet en omsetning på 107 milliarder kroner. Ved utgangen av året utgjorde antall årsverk omkring [Statoil 00] Statoil KTJ IT Organisasjonsenheten Statoil Konserntjenester Informasjonsteknologi (KTJ IT) omfatter konsernets IT personell. Med 462 ansatte pr. 1. januar 2000 og omtrent like mange konsulenter utgjør Statoil KTJ IT en av norges største IT bedrifter. Statoil KTJ IT s visjon og forretningside fremkommer av figur Prosty prosjektet Prosty er Statoils system for produksjonsoppfølging. Det brukes på alle lisenser Statoil er operatør på norsk sokkel. Prosty brukes daglig og er grunnlaget for rapportering av produksjon og ope- 1. UML profiler - utvidelsesmekanisme for UML språket. Se kap. 4.3 UML utvidelsesmekanismer på side

15 Innledning rasjon av installasjonene til partnere og Oljedirektoratet. [Eureka 00] Visjon STATOIL skal være verdensberømt for sine resultater på å integrere forretning og informasjonsteknologi. Forretningside Vi skal gjøre det enkelt å forandre forretningen ved at vi tar ansvar for en informasjonsarkitektur der du lett kan utveksle og gjenfinne informasjon. Vi skal skape verdi for Statoil ved å anvende vår IT kompetanse i Statoils forretningsprosesser. Figur 1-1: Statoil KTJ IT s visjon og forretningside. [Eureka 00] Systemet inneholder funksjoner til bruk ved planlegging, oppfølging og rapportering av olje-, kondensat- og gassproduksjon på Statoil opererte lisenser. Prosty oppbevarer historiske produksjonsdata fra hele feltets levetid, og er Statoils offisielle kilde for produksjonsdata. Prosty er et felles system som brukere vil kjenne seg igjen i uansett driftsenhet. For hver lisens vil det være en egen installasjon av Prosty med tilhørende data. [Eureka 00] Prosjektet er organisert med et totalprosjekt som er en overbygning av alle de hittill 12 innføringsprosjektene. Statoil benytter konsulenter fra TietoEnator under utviklingen av systemet. I 1999 gikk det med ca. 25 årsverk, interne og eksterne, til utvikling og innføring av systemet. TietoEnator har kommersialisert systemet under navnet Energy Components. Prosty prosjektet benytter en blanding av tolags og trelags klient/tjener arkitektur. De tidligste prosjektene benyttet tolags arkitektur, men dette er en på vei bort fra. I trelags arkitekturen er det nederste laget en database tjener som også inneholder litt av forretningslogikken. Det midterste laget er en applikasjonstjener som inneholder mest mulig av forretningslogikken. Det øverste laget er en PC klient som kjører klientdelen av applikasjonen. Ved bruk av tolags programvarearkitektur ligger det meste av forretningslogikken på klientdelen. Se figur 1-2. Systemet har land- og offshorebaserte brukere. Der hvor offshore installasjonene har god kommunikasjonsforbindelse, det vil si kabelbasert kommunikasjon (>256 kb/s), benyttes det landstasjonerte databasetjenere. For anlegg med langsommere satelittbasert kommunikasjon (<64 kb/s) er det vanlig å distribuere både database- og applikasjonstjener ut på offshore installasjonen. Merk at det er ingen synkronisering av informasjon mellom de ulike systemer/installasjoner. Det vil si at hver lisens har sin egen installasjon av Prosty systemet og sitt eget driftsmiljø. Det er dette som utgjør det spesielle i Prosty prosjektet, nemlig at hver installasjon består av en generell bit og en spesiell bit. I enkelte tilfeller utgjør dette at det bare er 5% ny kode. Utviklingsprosjektets utfordring er å maksimere gjenbruksgraden samtidig som kostnads- og tidsrammer prioriteres overholdt. Alle systemene er basert på samme logiske og fysiske datamodell. Det er også et felles rapporteringslag som benyttes for enklere rapporter. -15-

16 Innledning klient applikasjon database Figur 1-2: Prosty programvarearkitektur. Statoil er i førersetet i de tidlige og sene faser av hvert innføringsprosjekt, selv om prosjektlederansvaret som utøves av en Statoil person gjelder alle faser. Det er Statoil som foretar forstudiet og skriver kravspesifikasjonen. TietoEnator utarbeider funksjonell spesifikasjon som godkjennes av Statoil. Deretter utvikler TietoEnator systemet. Statoil står for innføringen og forvaltningen av systemet. I disse sene faser er kvaliteten på systemdokumentasjonen avgjørende for i hvilken grad man har mulighet for å oppnå høy gjenbruksprosent når neste fase skal iverksettes. Statoil står selv for utviklingen av grensesnitt mot øvrige system brukt i Statoil og utviklingen av rapporter fra Prosty. Det spesielle med Prosty prosjektet er: Gjenbruksgrad stor tross stor ulikhet i de enkelte områder systemene dekker. Kompleksitet og størrelse. Versjonshåndtering. Historisk ballast er tung: kombinasjon av gammel og ny teknologi. Prosjektleder Oral Sjøflot gir følgende viktige poeng om Prosty systemene: Hvert felt i nordsjøen har sin egen installasjon. Det eksisterer ingen kommunikasjon mellom systemene. Det eksisterer mange grensesnitt til andre system. F.eks. oljelasting, transport, miljøsystem, reservoarsimulering. Intensjon om integrasjon med flere system som f.eks. SAP og Landmark OpenWorks. Alle system bygger på samme datamodell. I enkelte tilfeller er det små forskjeller. Systemet brukes av flere oljeselskap. Kode deles. Systemet tilbyr et felles rapporteringslag for enkel ad-hoc rapportering Midas modell for systemutvikling Prosty prosjektet baserer seg på Midas [Midas 91], Statoils egen systemutviklingsmodell som -16-

17 Innledning følger fossefallsmodellen 1. Den definerer 9 faser gjennom et systemutviklingsløp: 0. Prosjektforslag 1. Forstudium 2. Kravspesifikasjon 3. Modellering og evaluering 4. Funksjonell spesifikasjon 5. Datasystemarkitektur 6. Programmering 7. Systeminstallasjon 8. Prosjektvurdering For hver fase finnes en fasebeskrivelse, beskrivelse av faseresultater og hjelp til hvordan hver av fasene skal utføres og aktiviteter som inngår. Midas er et hjelpemiddel til hvordan prosjektet kan gjennomføres. I henhold til Midas er det mulig, der det er naturlig, å definere avvik i forhold til Midas. Dette benytter Prosty prosjektet seg av, og definerer prosjektfasene sine til å være: 0. Forstudie 1. Brukerkravspesifikasjon 2. Konstruksjon - gjennomføres av eksternt konsulentselskap 3. Innføring I kravspesifikasjonsfasen legger Prosty prosjektet opp til et spesifikasjonsløp som er basert på eksisterende komponenter/funksjonalitet. Spesifikasjonsarbeidet tar utgangspunkt i etablerte Prosty systemer. Nødvendige funksjonsendringer og forbedringer i forhold til tidligere Prosty versjoner på grunn av andre tekniske løsninger og nye arbeidsmetoder tillates. Nye skjermbilder prototypes. [Eureka 00] 1.8 Rapportens oppbygning Rapportens oppbygging gjenspeiler tilnærmingen til stoffet. Del 1, innledningen, er oppstarten med klargjøring av oppgaven og synliggjøring av hvordan stoff og oppgave skal angripes. Del 2 går i dybden på problemet og belyser det teoretiske grunnlaget. Prosty dokumentasjonsbehov klargjøres, krav til modelleringsspråk fastsettes, UML gjennomgås og vurderes opp mot krav. Konklusjon og anbefaling på UML bruk foretas. Del 3 fastsetter krav til UML verktøy og evaluering av verktøy foretas opp mot fastsatte krav. Del 4 trekker slutninger, foretar anbefalinger og beskriver konsekvenser ut fra de fastsatte mål for oppgaven. Del 5, er avrundingen av oppgaven med ordliste, referanseliste og litteraturhenvisninger. 1. Fossefallsmodellen er et sekvensielt utviklingsløp hvor en fase ferdigstilles før neste fase tar til. Dette står i kontrast til et inkrementelt utviklingsløp hvor man kan arbeide parallelt på flere faser. -17-

18

19 Prosty dokumentasjon 2 Prosty dokumentasjon I dette kapittelet gis først en presentasjon av terminologi og begreper brukt innen dokumentasjon. Deretter ser jeg på hva jeg forventer å finne av dokumentasjon og litt på hvilke krav som bør settes til dokumentasjonen. Så ser jeg på Prosty dokumentasjonen, hvordan den oppbevares, hvilke formelle dokumenter som inngår, og litt på lagringsformat. Dette fører frem til avrundingen på kapittelet hvor Prosty prosjektets dokumentasjonsbehov fastslås. 2.1 Terminologi og begreper I dette avsnitt presenteres terminologi og begreper omkring dokumentasjon. Dokument: En unik identifiserbar informasjonsenhet for menneskelig bruk, slik som en rapport, spesifikasjon, manual eller bok. [ISO 6592] Statoils definisjon: En begrenset mengde informasjon produsert med en spesiell hensikt. Informasjonen kan være en kombinasjon av tegn, tall, figurer, tegninger, modeller, bilder og lyd. Den må være mulig å regenerere og den kan være lagret på ethvert medium. Basert på [Berge 97]. Dokumentasjon: En samling av ett eller flere dokumenter. [ISO 6592] Programvare dokumentasjon: All dokumentasjon av et programvaresystem. Inkluderer prosjekt dokumentasjon og forvaltningsdokumentasjon. Prosjekt dokumentasjon: Dokumentasjon produsert gjennom prosjektets faser frem til og med produksjonsetting. Ofte dokumenteres hver fase i utviklingsløpet separat. Prosjektdokumentasjon inkluderer også informasjon som planlegging, endringshåndtering, prosjektkontroll, osv. Forvaltningsdokumentasjon: Samlebegrep for bruker-, drifts- og systemdokumentasjon. Den del av dokumentasjonen som brukes til å dokumentere systemet etter at det er tatt i bruk. Se figur 2-4 på side 28. Brukerdokumentasjon: Den delen av forvaltningsdokumentasjonen som beskriver bruken av systemet og er skrevet for sluttbrukerne. F.eks. brukermanual, referansemanual, referansekort. Systemdokumentasjon: Den del av forvaltningsdokumentasjonen som dokumenterer programvareløsningen til systemet. Prosjektdokumentasjonen danner grunnlaget for systemdokumentasjonen. Driftsdokumentasjon: Den del av forvaltningsdokumentasjonen som beskriver de maskinvaretekniske løsningene og distribusjonen av programvare til ulike maskinvarekomponenter. Beskriver også driftsrutiner for systemet. F.eks. prosedyrer for start og stopp av systemet, backup, osv. 2.2 Forventet dokumentasjon Før jeg ser på Prosty prosjektets dokumentasjon, skal jeg kort se på hva vi forventer å finne av dokumentasjon for et prosjekt av Prosty prosjektets størrelsesorden. Merk at dette delkapittelet ikke er ment å være en endelig liste over formelle krav til dokumentasjon, men utdrag og anbefalinger fra litteraturen på hva og hvordan man bør dokumentere. -19-

20 Prosty dokumentasjon Dokumentasjon er det sekundære Booch slår fast at dokumentasjon av systemets arkitektur og implementasjon er viktig, men produksjonen av slik dokumentasjon må aldri få drive utviklingsprosessen: dokumentasjon er essensielt, men sekundært produkt av utviklingsprosessen. Det er også viktig å huske at dokumentene er levende produkter som må tillates å utvikle seg gjennom den iterative og inkrementelle evolusjonen av programvareversjoner. [Booch 94] Kunsten å utelate D Souza og Wills hevder at kunsten å produsere god dokumentasjon er å kunne utelate ting, men på en konsistent og meningsfull måte, slik at dokumentene blir velstrukturerte, konsistente og lesbare. [D Souza 99] Objekt-orientert dokumentasjon Sametinger foreslår å benytte den samme objekt-orienterte tankegang også for dokumentasjonen. Dette vil gjøre det mulig å gjenbruke dokumentasjonen ved å utvide og endre den uten å lage flere kopier [Sametinger 94]. Dette oppnås ved å anvende arv-, og gjenbruksprinsippene også på dokumentasjonen Visjonsdokument og kravspesifikasjon Leffingwell og Widrig hevder det er naturlig å finne følgende dokumenter tilhørende de første fasene av et prosjekt [Leffingwell 00]: Visjonsdokument som på et høyt abstraksjonsnivå definerer både problemet og løsningen. Applikasjonen beskrives i generelle former. Kravspesifikasjon inneholdende Use-Case modell. Med dagens verktøy og teknikker foretrekker Leffingwell og Widrig å tenke på programvarekravene som en logisk struktur, heller enn et fysisk dokument. Utarbeidelsen av de forskjellige kravene til systemet blir innlemmet i det Leffingwell og Widrig kaller den moderne programvarekravpakke (PKP). Programvarekravpakken er utgangspunktet for design-, og testmodellen og brukerdokumentasjonen. Se figur 2-1 på side 21. Også Leffingwell og Widrig foreslår en objekt-orientert dokumentstruktur for en produktfamilie. Kravspesifikasjonen for en av de individuelle familiemedlemmer kan da inneholde referanser - linker eller sporet fra - til produktfamilie dokumenter, eller de kan reprodusere alle kravene fra dette dokument. Fordelen med den første fremgangsmåten er at endringer tilhørende alle familiemedlemmer kan foretas kun et sted. Se figur 2-2 på side 22. [Leffingwell 00] ISO veiledning for dokumentasjon I ISO-6592 Guidelines for the documentation of computer-based application systems [ISO 6592] presenteres en metode for å definere et passende sett med dokumenter til bruk gjennom livssyklusen til et programvareprosjekt, inkludert dets definisjon og bruk. -20-

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer

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

Hensikten 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

Detaljer

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling Oppdatert 15. jan. 2014, Svend Andreas Horgen (studieleder Informasjonsbehandling og itfag.hist.no) Her er noen generelle retningslinjer

Detaljer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller

Detaljer

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

I 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

Detaljer

Grunnleggende om Evaluering av It-systemer

Grunnleggende om Evaluering av It-systemer Grunnleggende om Evaluering av It-systemer Hva er å evaluere? Foreta en vurdering av systemet og avklare nytten det har for brukerne. En systematisk innsamling av data som gir informasjon om nytteverdien

Detaljer

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu UML 1 Use case drevet analyse og design 20.01.2004 Kirsten Ribu 1 I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 2 Domenemodell visualisering

Detaljer

Bakgrunn. Kurset krever ingen spesielle forkunnskaper om modellering.

Bakgrunn. Kurset krever ingen spesielle forkunnskaper om modellering. Bakgrunn Modellering har lenge vært et kjent begrep innen systemutvikling. På 80-tallet ble metoder som Yourdon/Demarco og Gane&Sarson brukt for å lage dataflyt-diagrammer. Etter hvert ble disse integrert

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

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

Use 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

Detaljer

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

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 VERSJON: PROSJEKTPLAN (1.0) 24. SEPTEMBER, 2004 prosjektplan.doc GRUPPE 12 PROSJEKTPLAN: PROSJEKTLEDELSE: USE CASE: KVALITETSSIKRING: ANDRÉ

Detaljer

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009 Kravspesifikasjon med UML use case modellering Erik Arisholm 25.02.2009 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet

Detaljer

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer...

1. 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

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

Jernbaneverkets erfaringer med implementering av RAMS

Jernbaneverkets erfaringer med implementering av RAMS Jernbaneverkets erfaringer med implementering av RAMS Terje Sivertsen, seksjonsleder signal Infrastruktur Teknikk, Premiss og utvikling Jernbaneverket RAMS-seminar, NJS, Oslo, 18. april 2007 1 Innhold

Detaljer

Presentasjon 1, Requirement engineering process

Presentasjon 1, Requirement engineering process Presentasjon 1, Requirement ing process Prosessodeller Hvorfor bruke prosessmodeller? En prosessmodell er en forenklet beskrivelse av en prosess En prosessmodell er vanligvis lagd ut fra et bestemt perspektiv

Detaljer

NOVUG 3 februar 2009

NOVUG 3 februar 2009 NOVUG 3 februar 2009 Tjenestekatalog og CMDB En kombinasjon som fungerer i praksis 2008 Prosesshuset AS All tillhørende informasjon kan bli endret uten varsel 1 Introduksjon Stig Bjørling Ellingsen Gründer

Detaljer

Use 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. 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,

Detaljer

AlgDat 12. Forelesning 2. Gunnar Misund

AlgDat 12. Forelesning 2. Gunnar Misund AlgDat 12 Forelesning 2 Forrige forelesning Følg med på hiof.no/algdat, ikke minst beskjedsida! Algdat: Fundamentalt, klassisk, morsomt,...krevende :) Pensum: Forelesningene, oppgavene (pluss deler av

Detaljer

Innhold. Innledning... 15. Del 1 En vei mot målet

Innhold. Innledning... 15. Del 1 En vei mot målet Innledning.............................................. 15 Del 1 En vei mot målet Kapittel 1 Utviklingsarbeidet.............................. 22 1.1 Systemutviklerens arbeid...............................

Detaljer

Løsningsforslag til Case. (Analysen)

Løsningsforslag til Case. (Analysen) Løsningsforslag til Case (Analysen) Dette er en skisse til løsning av Case et med bussinformasjonssystemet. Jeg kaller det en skisse fordi det på den ene siden ikke er noe fasitsvar og fordi løsningen

Detaljer

Installere JBuilder Foundation i Windows XP

Installere JBuilder Foundation i Windows XP Installere JBuilder Foundation i Windows XP Installasjon av JBuilder Foundation på Windows (dekker her spesifikt fremgangen ved bruk av Microsoft Windows XP Professional, men det vil mest trolig ikke være

Detaljer

IT I PRAKSIS!!!!! IT i praksis 20XX

IT I PRAKSIS!!!!! IT i praksis 20XX IT I PRAKSIS 1 IT i praksis 20XX 2 IT I PRAKSIS FORORD 3 INNHOLD 4 IT I PRAKSIS Styringsmodell for utviklingsprosjekter (SBN) 5 Fra en idé til gevinstrealisering styringsmodell for utviklingsprosesser

Detaljer

Installere JBuilder Foundation i Mandrake Linux 10.0

Installere JBuilder Foundation i Mandrake Linux 10.0 Installere JBuilder Foundation i Mandrake Linux 10.0 Installasjon av JBuilder Foundation på Linux (dekker her spesifikt fremgangen ved bruk av Mandrake Linux 10.0, men distribusjon vil gjøre liten eller

Detaljer

PRESENTASJON. Prosjektnr: 43E Prosjektnavn: BILs nettsider Jone Tveitane Dato: 17.12.2006

PRESENTASJON. Prosjektnr: 43E Prosjektnavn: BILs nettsider Jone Tveitane Dato: 17.12.2006 PRESENTASJON Prosjektnr: 43E Prosjektnavn: BILs nettsider Elev: Jone Tveitane Dato: 17.12.2006 1 INNHOLDSFORTEGNELSE 1 OPPGAVESTILLER... 3 2 PROBLEMSTILLING... 3 3 HVORFOR DENNE OPPGAVE... 3 4 HVORDAN

Detaljer

Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner

Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner Software Engineering - definisjoner Kap. 2 Prosessen Utviklingsprosessen Modeller for utvikling Bauer: Etablering og bruk av gode ingeniørmessige prinsipper for å fremskaffe økonomisk programvare som er

Detaljer

Introduksjon til fagfeltet

Introduksjon til fagfeltet LC238D http://www.aitel.hist.no/fag/_dmdb/ Introduksjon til fagfeltet Datafiler side 2 Databasesystemer side 3-5 Databasearkitektur ANSI/SPARC side 6-7 Datamodeller side 8 Flerbruker databasesystem side

Detaljer

Design og dokumentasjon

Design og dokumentasjon Design og dokumentasjon Information Architecture Peter Morville& Louis Rosenfeld Kapittel 12 29.01.2015 Håkon Tolsby 1 Ny fase i prosjektet Fokusskifte: Fra planlegging til produksjon Fra overordnet arkitektur

Detaljer

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Fastsatt som forskrift av Utdanningsdirektoratet 3. april 2006 etter delegasjon i brev 26. september 2005 fra Utdannings-

Detaljer

Teknologiforum, Clarion hotel, Gardermoen 2015-10-26/27. En introduksjon til SOSI del 1 Regler for UML modellering

Teknologiforum, Clarion hotel, Gardermoen 2015-10-26/27. En introduksjon til SOSI del 1 Regler for UML modellering Teknologiforum, Clarion hotel, Gardermoen 2015-10-26/27 SOSI versjon 5.0 Morten Borrebæk Kartverket En introduksjon til SOSI del 1 Regler for UML modellering (fra forretningsprosesser til tjenestemodeller)

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 2. juni 2014 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 4 sider Vedlegg: Ingen Tillatte hjelpemidler:

Detaljer

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:

Detaljer

INF5120 - Oblig 2. Hour Registration System (HRS)

INF5120 - Oblig 2. Hour Registration System (HRS) INF5120 - Oblig 2 Hour Registration System (HRS) 1 av 40 1 Innholdsfortegnelse 1 Innholdsfortegnelse... 2 2 Innholdsfortegnelse for figurer... 3 3 Hour Registration System (HRS)... 4 3.1 Introduksjon...

Detaljer

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

Detaljer

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: XX Eksamen i fag SIF8018 Systemutvikling

Detaljer

PROSJEKTBESKRIVELSE. Hovedprosjekt Standardisering av digitalisert landskapsinformasjon. (BIM for landskap)

PROSJEKTBESKRIVELSE. Hovedprosjekt Standardisering av digitalisert landskapsinformasjon. (BIM for landskap) PROSJEKTBESKRIVELSE Hovedprosjekt Standardisering av digitalisert landskapsinformasjon (BIM for landskap) Innhold Bakgrunn... 2 Hovedoppgave... 2 Omfang og krav til leveranse... 4 Fremdrift... 4 Økonomi...

Detaljer

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

Detaljer

nettbasert produksjon og distribusjon av lydbøker

nettbasert produksjon og distribusjon av lydbøker nettbasert produksjon og distribusjon av lydbøker Formater i PipeOnline DAISY (Digital Accessible Information System) er en veletablert internasjonal standard for strukturering av digitale lydbøker. Standarden

Detaljer

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

Kravspesifikasjon. 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

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. 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.

Detaljer

Oppfølgingsdokument. Kode 009 29. januar 2004 GymPack. D01-2004 Oppfølgingsdokument. Periode 009 Forfatter. Hanne Johnsen

Oppfølgingsdokument. Kode 009 29. januar 2004 GymPack. D01-2004 Oppfølgingsdokument. Periode 009 Forfatter. Hanne Johnsen Periode 009 Forfatter Hanne Johnsen www.multipro-skien.no www.kiprod.com www.prosjekt.kiprod.com 1 av 7 Oppgaver for D01-2004: I denne perioden har vi konstruert infokiosken, detaljert use caser, og begynt

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 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...

Detaljer

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1 1 FORORD Dette dokumentet er brukerveiledningen, og skal være en veiledning

Detaljer

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger PROEX.NO En webbasert samhandlingsløsning. Utviklet av Eskaler as Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger Telefon: 51 87 48 50 Fax: 51 87 40 71 Dette dokumentet inneholder en

Detaljer

3. Kravspesifikasjon. Experior - rich test editor for FitNesse -

3. Kravspesifikasjon. Experior - rich test editor for FitNesse - 3. Experior - rich test editor for FitNesse - 3.1. Forord Dette dokumentet inneholder krav til funksjonalitet i Experior og hvordan denne skal integreres inn i selve FitNesse. I tillegg spesifiseres krav

Detaljer

Brukerdokumentasjon. Webservices og webklient for kodeverk/ kodeverdi verifisering

Brukerdokumentasjon. Webservices og webklient for kodeverk/ kodeverdi verifisering Brukerdokumentasjon Webservices og webklient for kodeverk/ kodeverdi verifisering Innholdsfortegnelse... 3... 3... 3... 3... 4... 4... 4... 4... 8... 9... 10!... 10 "... 11 # $... 11 1. Om systemet 1.1.

Detaljer

RETNINGSLINJER FOR SKRIVING AV SLUTTRAPPORT VED BACHELOROPPGAVE

RETNINGSLINJER FOR SKRIVING AV SLUTTRAPPORT VED BACHELOROPPGAVE RETNINGSLINJER FOR SKRIVING AV SLUTTRAPPORT VED BACHELOROPPGAVE Det gis ulike anbefalinger for hvordan en prosjektrapport skal se ut. Noen krav til innhold og utseende er beskrevet i forslaget nedenfor.

Detaljer

God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04

God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04 Mer om UML God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04 1 I dag Litt repetisjon GRASP mønstre og OO design Prosjektoppgaven:

Detaljer

det offentlige kartgrunnlaget (DOK)

det offentlige kartgrunnlaget (DOK) geografiske data som er tilrettelagt for plan- og byggesaksarbeid = det offentlige kartgrunnlaget (DOK) Terje Nuland, geodataavdelingen Det offentlige kartgrunnlaget ØK FKB DOK Lover forskrifter veiledning

Detaljer

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.

Artist 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

Trip Tracker - Tracks your trip. Harald H. Tjøstheim Dagfinn Rasmussen Jan Magne Tjensvold

Trip Tracker - Tracks your trip. Harald H. Tjøstheim Dagfinn Rasmussen Jan Magne Tjensvold Trip Tracker - Tracks your trip Harald H. Tjøstheim Dagfinn Rasmussen Jan Magne Tjensvold Våren 2006 Sammendrag Trip Tracker er et klient-tjener system for sporing og plotting av koordinater fra en GPS-mottaker

Detaljer

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1 Oppsummering : IMT2243 Systemutvikling Målformuleringen i emnebeskrivelsens : Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring

Detaljer

Produktrapport Gruppe 9

Produktrapport 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

Detaljer

En oversikt over forskjellige aspekter ved sikkerhetspolicyer

En oversikt over forskjellige aspekter ved sikkerhetspolicyer En oversikt over forskjellige aspekter ved sikkerhetspolicyer Ketil Stølen Sjefsforsker/Professor II SINTEF/UiO Oslo 23. mars 2006 Innhold Hva mener vi med sikkerhet? Hva er en policy? Policyer versus

Detaljer

INF 5120 Obligatorisk oppgave Nr 2

INF 5120 Obligatorisk oppgave Nr 2 INF 5120 Obligatorisk oppgave Nr 2 Vigdis Bye Kampenes Stein Grimstad Gruppe 26 INF 5120 Obligatorisk oppgave Nr 2... 1 1 Business model... 2 Innledende kommentarer... 2 Andre avgrensninger... 2 Scoping

Detaljer

HENSIKT OG OMFANG...2

HENSIKT OG OMFANG...2 Generelle bestemmelser Side: 1 av 12 1 HENSIKT OG OMFANG...2 1.1 Regelverkets enkelte deler...2 2 GYLDIGHET...3 2.1 Dispensasjon fra teknisk regelverk...3 2.2 Dispensasjon fra forskrifter...3 3 NORMGIVENDE

Detaljer

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen.

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen. Kort innføring i design og programmeringsfasen Jarle Larsen/Tore Berg Hansen 2.11.04 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314 Prosjektrettet systemarbeid Resymé:

Detaljer

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, System integration testing Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, Innhold Presentasjon Hva er integration testing (pensum) Pros og cons med integrasjonstesting Når bruker vi integration

Detaljer

IDRI3001 Bacheloroppgave i Drift av datasystemer

IDRI3001 Bacheloroppgave i Drift av datasystemer IDRI3001 Bacheloroppgave i Drift av datasystemer Kjell Toft Hansen, 15.04.2015 Bachelor Informatikk Drift av datasystemer Sammendrag Her er noen studiespesifikke retningslinjer for veiledning og vurdering

Detaljer

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Høgskolen i Telemark 2 Lars- Martin Hejll Høgskolen I Telemark Oppgave 1 Spørsmål fra pensum (20%) 1. Nødvendige aktiviteter i systemutvikling:

Detaljer

Tittel Objektorientert systemutvikling 2

Tittel Objektorientert systemutvikling 2 EKSAMENSFORSIDE Fagnr. OBJ208 Tittel Objektorientert systemutvikling 2 Ansvarlig faglærer Viggo Holmstedt Klasse(r) Dato IS/IN 2 11.06.2009 Eksamensoppgaven Ant. sider inkl. består av følgende: forside

Detaljer

Høgskolen i Oslo og Akershus

Høgskolen i Oslo og Akershus Høgskolen i Oslo og Akershus Gruppe 2 Forprosjektrapport Presentasjon Oppdragsgiver: Prosjekttittel: Definisjon: Accenture Shera Shera er en «event»-applikasjon til Android der man kan registrere arrangementer

Detaljer

STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen

STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen Tid: Mandag 06.08.2007, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent

Detaljer

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet Kravspesifikasjon Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Tittel: Oppgave: Gruppemedlemmer: Digitalt Helsekort for Gravide Utvikle en prototype

Detaljer

RAPPORTSKRIVING FOR ELEKTROSTUDENTER

RAPPORTSKRIVING FOR ELEKTROSTUDENTER RAPPORTSKRIVING FOR ELEKTROSTUDENTER FORORD Dette notatet er skrevet av Åge T. Johansen, Høgskolen i Østfold. Det er skrevet for å gi studenter en veiledning i rapportskriving. Informasjonen er ment å

Detaljer

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste?

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste? Kort om evaluering og testing av It-systemer Hvordan vurdere, verdsette, velge og teste? Evaluere - Bokmålsordboka Evaluere Vurdere, verdsette, gi karakter for. Vurdere Bedømme, verdsette. Bedømme Dømme

Detaljer

OWGS (Obstacle Warning GPS System)

OWGS (Obstacle Warning GPS System) OWGS (Obstacle Warning GPS System) Enkelt Effektivt Sikkert Fleksibelt Innhold OFU prosjekt VG faksimile Hovedmål Utvikle en arkitektur (verdikjede, organisasjon, teknisk) for OWGS Prosjektet skal utvikle

Detaljer

1. Hvilke type krav angår sikkerhet og pålitelighet?

1. Hvilke type krav angår sikkerhet og pålitelighet? 1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b), IS side 88, lærebok s.96 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan

Detaljer

Forprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av:

Forprosjektrapport 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:

Detaljer

Aktivitetskart. Fremdriftsplan: denne prosessen: Peder Sundbø. ferdigstilt uke 8. fastslåing av prosjekt. Magnus Eriksen. Uke 8.

Aktivitetskart. Fremdriftsplan: denne prosessen: Peder Sundbø. ferdigstilt uke 8. fastslåing av prosjekt. Magnus Eriksen. Uke 8. Aktivitetskart Planlegging dato: 29.01-09 TIL 7.2-09 Kravspesifikasjon beskrivelser Papirprototyp ER-diagram Planlegging og fastslåing av prosjekt En del av kravspesifikasjon. Grafisk visning av systemets

Detaljer

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp { En selvstendig plattform som kan brukes til å formidle kurs på nett med dagsaktuell teknologi. Oppgave 5, av Fredrik Johnsen Oppgavestiller

Detaljer

Delt opp i tre strategier: forretningststrategi, organisasjonsstrategi og informasjonstrategi.

Delt opp i tre strategier: forretningststrategi, organisasjonsstrategi og informasjonstrategi. Oppsummering infosys Strategier Delt opp i tre strategier: forretningststrategi, organisasjonsstrategi og informasjonstrategi. Forretningststrategi Porters modell - konkurransefordel Bedriften oppnår konkurransefordel

Detaljer

Egenevalueringsskjema

Egenevalueringsskjema Egenevalueringsskjema for foretakets IT-virksomhet forenklet versjon basert på 12 COBIT prosesser Dato: 10.07.2012 Versjon 2.6 Finanstilsynet Tlf. 22 93 98 00 post@finanstilsynet.no www.finanstilsynet.no

Detaljer

John-Kjell.Hoset@Stretch.no 9513 5625 EN INNFØRING I BPM

John-Kjell.Hoset@Stretch.no 9513 5625 EN INNFØRING I BPM John-Kjell.Hoset@Stretch.no 9513 5625 EN INNFØRING I BPM 1 AGENDA DEL1 HVA ER BPM Hva er BPM Utfordringen Gruppearbeid DEL2 PRAKTISK MODELLERING OG DEMO MED BIZAGI Hva er BPMN BPMN modellering verktøy

Detaljer

Workshop NGIS API. Lars Eggan, Norconsult Informasjonssystemer desember 2014

Workshop NGIS API. Lars Eggan, Norconsult Informasjonssystemer desember 2014 Workshop NGIS API Lars Eggan, Norconsult Informasjonssystemer desember 2014 1 NGIS i WinMap NGIS-klient Hente datasett fra en NGIS portal Oppdatere portalen med endringer gjort lokalt Spesiallaget funksjonalitet

Detaljer

Risikoanalysen beskriver status per 30.04.13 med tiltak/kommentarer for hver enkel risikofaktor.

Risikoanalysen beskriver status per 30.04.13 med tiltak/kommentarer for hver enkel risikofaktor. Felles studentsystem Telefon: 22852738 USIT, Universitetet i Oslo Telefax: 22852970 Postboks 1086, Blindern E-mail: fs-sekretariat@usit.uio.no 0316 Oslo URL: www.fs.usit.uio.no FS-13-089 ALL Til: Styret

Detaljer

Arkitektur. Kirsten Ribu Høgskolen i Oslo 10.02.04 10.02.2004 1

Arkitektur. Kirsten Ribu Høgskolen i Oslo 10.02.04 10.02.2004 1 Arkitektur Kirsten Ribu Høgskolen i Oslo 10.02.04 10.02.2004 1 I dag Generelt om arkitektur N-lags arkitektur MVC Model View Controller mønsteret 10.02.2004 2 Hva er arkitektur? Oppdelingen av et system

Detaljer

Manual for innlegging av standard sideinnhold og nyheter via «backend»

Manual for innlegging av standard sideinnhold og nyheter via «backend» Manual for innlegging av standard sideinnhold og nyheter via «backend» 23.3.2006 Utarbeidet av: 2 Innlogging og beskrivelse av hovedelement i «backend» For å få tilgang til redigeringsmodul velges følgende

Detaljer

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5 Testrapport Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 24.5.2013 Public 2013 Aker Solutions Page 1 of 5 Innledning I denne rapporten vil vi skrive om testingen som

Detaljer

1. SQL datadefinisjon og manipulering

1. SQL datadefinisjon og manipulering Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag SQL datadefinisjon og manipulering Tore Mallaug 7.10.2008 Lærestoffet er utviklet for faget Databaser 1. SQL datadefinisjon og manipulering

Detaljer

Kirsten Ribu - Høgskolen i Oslo 05.05.04

Kirsten Ribu - Høgskolen i Oslo 05.05.04 Prosessmodellering Strukturert analyse og design et overblikk Gurholt & Hasle, kapittel 10 Kirsten Ribu - Høgskolen i Oslo 05.05.04 1 Perspektiver på modellering Datamodellering var lenge den mest brukte

Detaljer

Veiledning for innlevering av masteroppgaver til biblioteket

Veiledning for innlevering av masteroppgaver til biblioteket Veiledning for innlevering av masteroppgaver til biblioteket Selvregistrering i Brage for studenter ved TEK-NAT Alle masteroppgaver - også de som ikke skal gjøres offentlig tilgjengelig - skal leveres

Detaljer

REFERAT. Saksliste. 1. Status endringsønsker 2. Prosjektmøte alternative løsninger

REFERAT. Saksliste. 1. Status endringsønsker 2. Prosjektmøte alternative løsninger Møtetype: SAP HR prioriteringsråd/prosjektmøte alternative løsninger Til stede: Tore Bjørn Hatleskog, UiS, Elisabeth Boye Okkenhaug, HiNT, Wenche Fjørtoft, HiSF, Laila Torp UNINETT FAS/HiST, Arild Halsetrønning,

Detaljer

Technical Integration Architecture Teknisk integrasjonsarkitektur

Technical Integration Architecture Teknisk integrasjonsarkitektur Kap. 6 Technical Integration Architecture Studentpresentasjon av Cato Haukeland Oversikt Introduksjon -spesifikasjon Krav Beskrivelse Servicenivå Sikkerhet Plan Best practices Introduksjon Masterdokument

Detaljer

HØRINGSNOTAT OM forlag TIL ENDRINGER I DOK- FORSKRIFTEN

HØRINGSNOTAT OM forlag TIL ENDRINGER I DOK- FORSKRIFTEN HØRINGSNOTAT OM forlag TIL ENDRINGER I DOKFORSKRIFTEN Ved alminnelig høring av utkast til forskrift om endring til forskrift om dokumentasjon og omsetning av produkter til byggverk (DOKforskriften) av

Detaljer

Lansering av ny versjon av KF Lokal tjenestekatalog

Lansering av ny versjon av KF Lokal tjenestekatalog Lansering av ny versjon av KF Lokal tjenestekatalog Kommuneforlaget lanserer nå en ny versjon(4.4.) av KF Lokal tjenestekatalog, heretter kalt lokal tjenestekatalog. Mange av endringene kommer som resultat

Detaljer

Ettersom IT-bransjen er meget kompleks, kan kurset også anbefales til andre bransjer.

Ettersom IT-bransjen er meget kompleks, kan kurset også anbefales til andre bransjer. KURSBESKRIVELSE Del 1: Grunnleggende kurs, 3 dager Del 2: Prosjektoppstart med fokus på IT-prosjekter, 2 dager Del 3: Utviklingsfaser innenfor IT integrasjonsprosjekter, 2 dager Del 4: Prosjektavslutning

Detaljer

Tom Røise 2/28/2007. IMT2243 : Systemutvikling 1. Forelesning IMT2243 1. mars 2007. Tema : Litteratur : Strukturert analyse. Strukturert analyse

Tom Røise 2/28/2007. IMT2243 : Systemutvikling 1. Forelesning IMT2243 1. mars 2007. Tema : Litteratur : Strukturert analyse. Strukturert analyse Forelesning IMT2243 1. mars 2007 Tema : Litteratur : Art.saml. Punkt 9 : Kap. 9. SASD - modellen, E. Andersen Metoden går ut på å anvende et sett teknikker i arbeidet med å lage gode systemmodeller /beskrivelser

Detaljer

Mamut Open Services. Mamut Kunnskapsserie. Kom i gang med Mamut Online Survey

Mamut Open Services. Mamut Kunnskapsserie. Kom i gang med Mamut Online Survey Mamut Open Services Mamut Kunnskapsserie Kom i gang med Mamut Online Survey Kom i gang med Mamut Online Survey Innhold MAMUT ONLINE SURVEY... 1 KOM I GANG MED MAMUT ONLINE SURVEY... 3 MAMUT-BRUKERE: OPPRETT

Detaljer

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING INF1050 V16 HVA ER KRAVHÅNDTERING? Kravhåndtering er prosessen å identifisere, analysere og spesifisere kravene til et nytt system eller et system som skal forbedres

Detaljer

Lansering av fire standarder for universell utforming

Lansering av fire standarder for universell utforming 2. desember 2013 Lansering av fire standarder for universell utforming RUDOLPH BRYNN PROSJEKTLEDER STANDARD NORGE Standard Norge Privat og uavhengig medlemsorganisasjon Utvikler standarder på de fleste

Detaljer

Oversikt over kurs, beskrivelser og priser Høst 2015. Bedriftsinterne kurs. kurs@qualisoft.no +47 518 70000. Kursnavn Forkunnskaper Dato/Sted

Oversikt over kurs, beskrivelser og priser Høst 2015. Bedriftsinterne kurs. kurs@qualisoft.no +47 518 70000. Kursnavn Forkunnskaper Dato/Sted Oversikt over kurs, beskrivelser og priser Høst 2015 Bedriftsinterne kurs Kursnavn Forkunnskaper Dato/Sted Basiskurs i QualiWare Introduksjon til (BPM) Business Process Management Professional Certificate

Detaljer

Programvare arkitekturer

Programvare arkitekturer Programvare arkitekturer 14. oktober 2001, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker

Detaljer

TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen

TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS GRUPPE 15 Kenneth Ådalen Vegard Gulbrandsen Kien Trung Nguyen Dataingeniørutdanningen, Høgskolen i Oslo Våren 2009 2 S i d e FORORD I dette dokumentet tar

Detaljer

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn INF1050: Systemutvikling 11. februar 2015 Modellering av krav Universitetslektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering

Detaljer

02 www.blastmanager.no

02 www.blastmanager.no 02 NY NETTBASERT DOKUMENTASJONS OG PLANLEGGINGSTJENESTE FOR BERGSPRENGERE OG ALLE SOM ER INNVOLVERT I SPRENGNINGSARBEID. KNYTTER AKTØRENE SAMMEN BYGGHERRE / KONSULENT HOVEDENTREPRENØR UTFØRENDE ENTREPRENØR

Detaljer

Informasjonsorganisering. Information Architecture Peter Morville & Jorge Arango Kapittel 4, 5 & 6

Informasjonsorganisering. Information Architecture Peter Morville & Jorge Arango Kapittel 4, 5 & 6 Informasjonsorganisering Information Architecture Peter Morville & Jorge Arango Kapittel 4, 5 & 6 Bevissthet om sted, omgivelser og tingenes plassering Ting er noe vi forstår i relasjon til noe annet Informasjonsomgivelsenes

Detaljer

Livsløpstesting av IT-systemer

Livsløpstesting av IT-systemer Livsløpstesting av IT-systemer Testing, validering og evaluering Teste Undersøke ved hjelp av tester om systemet fungerer slik det er beskrevet Validere Bekrefte hvordan systemet virkelig fungerer, om

Detaljer

FITS Tilgjengelighets- og kapasitetsstyring

FITS Tilgjengelighets- og kapasitetsstyring FITS Tilgjengelighets- og kapasitetsstyring Becta 2004 Utgitt på norsk av Senter for IKT i utdanningen i 2012 FITS tilgjengelighets- og kapasitetsstyring Innhold TKS 1 Introduksjon... 1 TKS 2 Oversikt...

Detaljer

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer...

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer... Innholdsfortegnelse Presentasjon..................................................... 3 Sammendrag.................................................... 4 Dagens situasjon.................................................

Detaljer