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-