PROJEKTSTYRING MED DESIGNER

Transkript

1 Metode Teknisk Artikel PROJEKTSTYRING MED DESIGNER - 1 Marc de Oliveira er teamleder hos NNE, skandinavisk forhandler af Design- Assist, Designer koordinator for OUGDK og ODTUG, og fra 1. januar 2003 bestyrelsesmedlem i ODTUG. Han er uddannet Datalog fra Københavns Universitet og har arbejdet med Oracle-produkter (hovedsagelig CASE/Designer) siden Marc@deOliveira.dk. Indledning Da jeg første gang blev præsenteret for Oracle*CASE (som Designer jo hed oprindeligt) var visionen, at dette værktøj ville dække hele udviklingsforløbet fra den tidlige strategifase over analyse, design, udvikling og test til implementering og vedligeholdelse med alt hvad der var behov for af systemdokumentation og brugerhjælp. Den gang i 1989 var værktøjet ikke helt klar til at løse alle disse opgaver, men tanken med Oracle*CASE var god og principperne, som produktet byggede på, virkede gennemtænkte og holdbare. Så vi var mange, der allerede den gang kunne forestille os, hvordan produktet ville komme til at se ud en gang i fremtiden. Litteraturen Det var også i 1989, at Richard Barker skrev bogen CASE*Method - Tasks and Deliverables, hvor han beskrev en meget detaljeret projektstyringsmetode, der netop fulgte de faser, som Oracle*CASE understøttede. Senere skrev Paul Dorsey og Peter Koletzke bogen Designer Handbook, som dels er en god vejledning i brugen af Designer, men (specielt i andenudgaven fra 1999) også er et godt oplæg til, hvordan man kan styre udviklingsprojekter vha Designer. I denne sammenhæng bør man også nævne Kent Graziano og Mark A. Kramms bog Oracle Designer: A Template for Developing An Enterprise Standards Document, hvor de to foreslår navnestandarder, template-standarder, dokumentstandarder mv. Bogen indeholder en cd-rom med alle deres eksempler så man, ved blot at indsætte sin virksomheds navn, kan ophæve dem til virksomhedsstandarrder (eller evt rette dem til så de passer til vrksomhedens behov og kultur). Princip nr 1 Fælles for de nævnte bøger er, at de alle forsøger at tage højde for alle detaljer og mulige afvigelser i et udviklingsprojekt, hvilket gør dem alle ret omstændige. Og sådan bør det også altid være. Det er væsentlig nemmere at skære dele væk, der er overflødige i en given situation end at skulle tilføje manglende elementer. Der er ingen tvivl om, at jeg sikkert ville følge dem alle til punkt og prikke, hvis jeg stod overfor at skulle bygge en storebæltsbro vha Designer, men min virkelighed er normalt noget simplere end det. Mine projekter er ofte på mindre end et mandeår, og mine kunder er typisk ikke vant til at granske store mængder systemdokumentation inden de tager systemerne i brug. Hvis projektstyringsmetoden og værktøjerne er alt for omstændige, ender de med slet ikke at blive brugt, og resultatet er at man gennemfører sine udviklingsprojekter helt uden metode. Det er med den baggrund, at vi i NNEs IT-afdeling har taget alt materialet fra ovenstående forfattere og filtreret det efter følgende princip: Hvad kan vi få gratis, nu vi allerede bruger Designer som udviklingsværtøj til at gennemføre vores projekter? - Princip nr 1 I stedet for at tage udgangspunkt i traditionel dokumentation, og spørge os selv hvordan vi kunne få den ud af Designer, vendte vi opgaven på hovedet og spurgte, hvordan ville den dokumentation, der ligger i Designer, kunne præsenteres overfor folk uden kendskab til Designer. Dette ville give os et vist niveau af dokumentation, som ikke ville koste vores projekter nogen ressourcer. Hvis der derefter stadig manglede væsentlig dokumentation, måtte dette blive tilføjet senere. Og som det vil fremgå af det følgende, er det lykkedes os at vride rimeligt meget dokumentation ud af Designer. Udviklingsmodellen Med udgangspunktet i Designers Repository fandt vi følgende projektfaser anvendelige: 1. Vision/Strategi Denne fase er den initielle fase, hvor ideen om at skulle udvikle et system kommer på bordet. Det vigtigste dokument i denne fase er et visionsdokument, der kortfattet kan beskrive opgavens mål og omfang på en sådan måde, at en overordnet person kan godkende det, og derved sætte det egentlige projektarbejde igang. Andre dokumenter, der kan være anvendelige i denne fase er Procesdiagrammer, simple ER-diagrammer og overordnede funktionshierarkier. 2. Analyse I analysefasen defineres opgaven i detaljer. På samme måde som visionsfasen, er kunden meget involveret i analysefasen. Det væsentligste dokument i denne fase er Kravspecifikationen, der nøjagtigt beskriver hvilke problemer, der skal løses af systemet. For at nå frem til dette, kan det være nødvendigt at få defineret visse termer og evt at få beskrevet ER-modellen og funktionshierarkiet i detaljer. Det er også væsentligt at kunne danne sig et overblik over opgavens ressourcemæssige omfang. 3. Design I denne fase defineres løsningsmodellen. Dvs at man 4 December 2002 OracleEkspert

2 finder ud af hvordan hvert krav fra kravspecifikationen skal implementers. Fasens vigtigste dokumenter er designdokumentet, som i detaljer beskriver hvordan hvert krav skal implementeres, og testplanen, der skal sikre at kravene til systemet bliver opfyldt. 4. Implementation I denne fase implementeres systemet som beskrevet i design-dokumentet. Denne fases vigtigste dokumenter er systemdokumentet, der beskriver det færdige system, og brugervejledningerne, der overfor brugerne beskriver hvordan systemet anvendes. I denne fase foregår også modultesten, men den finder vi ikke væsentlig at dokumentere, da den ikke har direkte interesse for kunden (den skal selvfølgelig udføres alligevel!). 5. Test og overdragelse I denne fase sker den officielle systemtest, og applikationen godkendes og installeres hos kunden. Denne fases væsentligste dokument er nok testrapporten, der (forhåbentligt) bekræfter, at systemet lever op til de stillede krav. Projektlederens Datamodel For at kunne generere tilfredsstillende dokumentation til alle de nævnte udviklingsfaser har vi fokuseret på følgende elementer i Designers Repository (samt enkelte elementer, som vi har måtte tilføje). 1. Visionsrelaterede elementer I visionsfasen er der behov for generel information om applikationen. Det skal også være muligt at tilknytte ekstern dokumentation fra andre systemer og definere generelle termer som vil blive anvendt til dokumentation af systemet. Disse oplysninger findes der passende steder at definere i Designer Repository (se figur 1). Application Systems Applikationssystemerne udgør kernen i applikationerne. Her kan man definere et kort internt navn (Name) og en mere sigende applikationstitel (Display Title), samt både en kort overordnet beskrivelse af applikationen (Summary) og en mere komplet beskrivelse (Description). Business Terms Det er godt at have eet sted, hvor man kan definere de termer som bruges i ens dokumentation. På denne måde er man ikke afhængig af at forklare sine termer hver gang man bruger dem, eller at ens dokumentation skal læses i en bestemt rækkefølge. I Designer defineres termerne meget simpelt med navnet på termen og en tilhørende beskrivelse. Designers mulighed for at danne short cuts gør desuden, at generelle termer kan genbruges i flere applikationer, sådan at senere præciseringer af termerne automatisk slår igennem i alle de applikationer, der anvender den pågældende term. Documents Allerede i visionsfasen vil der typisk være behov for at arkivere dokumenter, som ikke er skabt i Designer, men leveret fra eksterne kilder (brugere, ledere, kunder etc). Typisk vil Pitch-dokumentet (dvs det dokument der initierer udviklingsprojektet) ofte være en mail, et Word dokument eller lign. I Designer repræsenterer begrebet Documents alle typer dokumenter. Simple dokumenter kan placeres i elementet Document Text og mere avancerede dokumenter, som feks Excel-regneark og MS Word dokumenter, kan blot refereres via Source Path elementet. 2. Analyserelaterede elementer Det næste som sker i projektforløbet er at alle kravene til systemet skal defineres, der skal laves et udkast til en tidsplan og projektgruppen skal defineres (se figur 2 - bemærk at de røde tabeller er tilføjet til Designers Repository af os). Desuden vil der være brug for Designers analyseværktøjer som ER-diagrammer, funktionshierarkier mv. Objectives Kravene til systemet kan man vælge at angive som Objectives. Disse har et navn, en status, en beskrivelse samt nogle elementer til angivelse af forventede ressourceforbrug. Objectives kan desuden relateres til Documents, hvilket gør det muligt at dokumentere baggrunden for kravene ved at oprette mødereferater, mails mv som har været med til at forme eller ændre kravene som Documents og relatere dem til de krav, de har haft indflydelse på. Problems Figur 1 Problems er en meget simpel struktur i Designer, der giver mulighed for at angive en start og slutdato på et OracleEkspert December

3 navngivet problem. Denne struktur har vi valgt at bruge til at definere tidsplaner. Problems kan struktureres hierarkisk, hvilket kan udnyttes til at definere både overordnede og detaljerede tidsplaner, der nemt lader sig udtrække til MS Projects Gantt-diagrammer. Entities Entiteter kan udover at indgå i ER-diagrammer også inkluderes i listen over termer, da disse ofte vil repræsentere centrale elementer i systemet. Beskrivelsen af entiteterne vil være meget mere anvendelige i en liste over termer end i en tabelbeskrivelse, som kun bliver læst af teknikkere. Functions Elementarfunktionerne (dvs de nederste funktioner i funktionshierarkiet) vil som oftest kunne anvendes direkte som systemkrav, da de jo repræsenterer, hvad der skal laves på det mest detaljerede niveau. Vi har derfor valgt at lave et lille værktøj, der kan kopiere indholdet af en funktion over i et Objectives element. Project Roles & Application Resources Til definition af projektgruppen har vi selv oprettet to tabeller uden for Designers repository: Project Roles: Denne tabel indeholder alle de persontyper, der kan indgå i et projekt, samt en udførlig beskrivelse af hvilke ansvarsområder der er knyttet til hver rolle. Application Resource: Denne tabel definerer de personer, der er tilknyttet det enkelte projekt inkl deres rolle. 3. Designrelaterede elementer Figur 3 Når kravene er kommet på plads, skal man til at finde ud af, hvordan man vil implementere dem i et nyt system. Man skal derfor kunne dokumentere hvilke moduler man vil lave (se figur 3). Modules Alle generelle oplysninger om modulerne dokumenteres i Modules. Her kan også angives oplysninger om hvor omfattende det enkelte modul vil være at udvikle og hvor langt man er nået i udviklingen. Vha System Objectives of Modules kan man også angive hvilke krav, de enkelte moduler skal løse. Det vil være en hjælp til at finde tilbage til baggrunden for at et givent modul er blevet lavet. Module Components Oplysninger relateret til modulernes enkelte datablokke dokumenteres i Module Components. Items Detaljerede oplysninger om modulernes felter dokumenteres i elementerne Items. 4. Implementationsrelaterede elementer I forbindelse med implementeringen af systemet er der behov for at kunne lave brugerdokumentation og testplaner (se figur 4). På dette tidspunkt skal det også dokumenteres, hvordan databasen er blevet implementeret. Test Steps Figur 2 Ved at basere testplanen på kravspecifikationen sikrer vi, at vi får testet netop de dele, som kunden er interesseret i. Dette fokus gør det også meget nemmere at finde frem til hvilke test, der er relevante for projektet. Ved at opdele testtrinene i følgende dele, kan vi genbruge dem til at lave en brugervejledning: 6 December 2002 OracleEkspert

4 1. Overskrift 2. Forudsætninger 3. Fremgangsmåde 4. Forventet resultat Mere om dette i afsnittet om den genererede dokumentation. Table Definitions etc Designer Repository er fyldt med elementer, der beskriver databaseobjekterne. Det er bare at vælge et niveau for, hvor meget dokumentation af databasen man vil give. 5. Elementer til test og overdragelse Testrapporten og referencemanualen kan laves ud fra den datamodel, der allerede er beskrevet i det forrige. Der skal blot oprettes et felt til testplanens konklusion i Application System elementet, hvilket kan gøres med User Extentions. Dokumenterne Figur 4 I dette afsnit vil jeg gennemgå de dokumenter man kan generere ud fra den netop beskrevne datamodel. Samtidig vil jeg løbende synliggøre, hvor stor en besparelse der ligger i at udnytte modellen. Blandt fordelene ved at generere sine dokumenter kan nævnes: 1. Dokumenterne får automatisk et ensartet udseende. 2. Man skal ikke skrive repetetive tekster, da disse kan genereres automatisk. 3. Man skal ikke bruge tid på formatering og opsætning af sine tekster. Disse skal blot være rå ASCII-tekst sådan at generatoren kan styre opsætningen. 4. Man kan senere ændre sine dokumentationsstandarder uden at skulle rette alle de tidligere skrevede dokumenter. De kan blot genreres igen efter at generatoren er blevet opdateret. Man kan generere dokumenter ud af Designer-Repository på mange måder. Man kan bruge Designers egen Reports-generator eller Web Server generatoren. Alternativt kan man selv lave en generator, der kan lave dokumenterne i det format man er interesseret i. Vi har valgt at generere dokumenterne i MS Word format, da dette er et meget udbredt format, som de fleste er fortrolige med. Dette format giver også mulighed for på en nem måde at lave indholdsfortegnelser og indeksregister. Jeg vil ikke komme nærmere ind på hvordan min MS Word generator virker. Interesserede kan læse min tidligere artikel om generering af MS Word dokumenter. 1. Visionsfasen visionsfasen. Pitch-dokument Pitch-dokumentet er rart at have, så man altid kan finde tilbage til den oprindelige baggrund for projektet. Pitch-dokumentet kommer normalt altid fra en ekstern person, og det gemmes blot som et element af typen Document, hvorfor der ikke er andet end nogle få sekunders arbejde i at få det registreret i Designer. Visionsdokumentet Visionsfasen afsluttes ved at Visionsdokumentet godkendes og underskrives af de relaterede parter. Visionsdokumentet indeholder opsummeringen og den fulde beskrivelse af hvad den ønskede applikation skal kunne. Desuden kan den eventuelt indeholde definitioner af systemspecifikke termer, samt et bilag med andre relevante dokumenter, der er tilgået projektet i Visionsfasen. Det eneste reelle dokumentationsarbejde, der ligger i denne fase, er at lave beskrivelsen af systemet (og opsummeringen). Da dette jo er selve formålet med en visionsfase, kan man ikke påstå, at dette er ekstraarbejde. Definitionen af termer sker kun i situationer, hvor man alligevel skulle have forklaret et udtryk som bliver anvendt i beskrivelsen. Ved i stedet at registrere forklaringen under Business Terms er den nem for alle parter at genfinde og den vill kunne genbruges i andre dele af dokumentationen og selv i helt andre projekter. 2. Analysefasen analysefasen. Tidsplan Tidsplanen, som er baseret på de indtastede milepæle, i form af Problems-elementer, genereres som en simpel datafil til MS Project, sådan at resultatet bliver et pænt MS Projekt Gantt-diagram. Selve milepælene er fast definerede, da de hver afspejler et projektdokument. Dvs at man kan lave en simpel funktion, der opretter en standard-tidsplan til ens projekt. Det eneste arbejde der er tilbage med at lave tidsplanen er at definere en afslutningsdato til hver milepæl. Dvs arbejdet er reduceret til det mindst mulige uden besværlige dokumentationsopgaver. Kravspecifikation Vi har valgt at bruge opsummeringen og beskrivelsen fra visionsdokumentet som indledning til kravspecifikationen af følgende grunde: 1. Det er gratis, da teksten jo allerede er skrevet. OracleEkspert December

5 2. Det er en naturlig indledning til kravspecifikationens mere detaljerede gennemgang af systemkravene. 3. Hvis der skulle dukke væsentlige nye dele op under analysefasen, som ikke var nævnt i visionsdokumentet, så har man her en mulighed for at få det nævnt uden nødvendigvis at skulle have visionsdokumentet godkendt igen. Så vises den foreløbige tidsplan med de forventede milepæle inklusiv det forventede samlede ressourceforbrug (ved at generatoren lægger alle kravenes forventede ressourceforbrug sammen). Endelig vises hvert krav med referencer til de eksterne dokumenter (Documents), de måtte være relateret til, og til sidst vises alle Documents som bilag. Dokumentet har selvfølgelig en indholdsfortegnelse og et indeksregister, hvor man kan slå navnene på de enkelte krav og bilag op alfabetisk. Dette forholdsvis omfattende dokument kan således dannes så snart kravene er definerede og alt ekstramateriale er arkiveret i Designer som Documents. Igen er der ikke noget ekstraarbejde med at få dannet kravspecifikationen udover at skulle registrere kravene til systemet, hvilket jo er hele formålet med analysefasen. Projektgruppe For at kunne generere Projektgruppe-dokumentet skal følgende to oplysninger indtastes for hver person i projektgruppen: 1. Deltagerens Initialer eller anden ID 2. Navnet på deltagerens rolle i projektet Igen svarer opgavens omfang til det nødvendige arbejde, der skal gøres. Dvs intet ekstra dokumentationsarbejde. Selve dokumentet vil indeholde en fin beskrivelse af hver rolles ansvarsområde, og deltagerene vil være grupperet under disse. 3. Designfasen Følgende dokument bør laves i forbindelse med designfasen. Designdokument En milepæl i designfasen er selvfølgelig at skrive designdokumentet. Igen har vi valgt at bruge Summary og Description fra Application Systems elementet som indledning til designdokumentet, da der igen kan være dukket væsentlige overordnede systemforhold op i designfasen, der bør fremgå. Så følger et kapitel med alle kravene og et kapitel med alle modulerne samt referencerne til hvilke(t) krav de hver er udsprunget af. Modulerne kan være genereret af Application Design Transformer en eller de kan være lavet manuelt. Uanset hvordan de er lavet skal de hver indeholde en beskrivelse af deres funktion. Som bilag viser vi igen alle de eksterne dokumenter, da der kan være kommet flere til siden kravspecifikationen blev lavet. Dokumentet indeholder selvfølgelig også en indholdsfortegnelse og et indeksregister. 4. Implementationsfasen implementationsfasen. Testplan Testplanen har vi valgt at strukturere som kravspecifikationen, så kunden kan se, at det netop er den funktionalitet, som er blevet efterspurgt, vi tester. Hvert krav bliver en sektion i testplanen og under hvert krav følger et antal testelementer hver bestående af: 1. Overskrift 2. Forudsætninger 3. Fremgangsmåde 4. Forventet resultat Hver sektion indholder felter til, at testpersonen og en godkender kan skrive under på at testen er gennemført. Da testplanen er bygget op omkring kravene er det væsentligt nemmere at overskue hvordan den skal laves, end hvis man skulle lave en testplan fra bunden. Derudover kan testplanen genbruges, når brugervejledningen skal laves. Brugervejledning Når først testplanen er lavet, kan brugervejledningen genereres uden yderligere arbejde. Brugervejledningen indledes af Summary og Description på Appliccation System, som jo allerede er skrevet. Denne indledning vil give brugeren en ide om, hvad hensigten er med systemet og hvad det kan. Derefter følger en sektion for hvert krav i kravspecifikationen, hvorunder hver test i testplanen vises med felterne: 1. Overskrift 2. Fremgangsmåde Igen er al nødvendig information allerede registrereet i Repository. Indholdsfortegnelsen og registeret er i dette dokument helt uundværligt, da brugeren skal kunne slå alle overskrifterne op i det alfabetiske register. Referencemanual Referencemanualen indeholder alt det, som ikke står i brugervejledningen. Den indeholder de generelle beskrivelser af hvert modul, deres blokke og felter. Referencemanualens indhold kan også gøres tilgængeligt on-line i det kørende system, så man altid nemt kan få adgang til oplysninger om det billede man er inde på. Modulbeskrivelserne er allerede lavet i designfasen, mens blok- og feltbeskrivelserne kan hentes fra de underliggende tabelbeskrivelser. Der ligger lidt arbejde i at gennemgå alle disse beskrivelser og evt tilpasse dem til de enkelte modulkomponenter eller felter, men dette arbejde er væsentligt nemmere end at skulle skrive en referencemanual fra bunden. Man bør også lave mindst et skærm-dump af hvert skærmbillede, sådan brugeren kan genkende billedet selv om han/hun ikke sidder ved skærmen. DIsse billeder vil også kunne bruges i systemdokumentet 8 December 2002

6 (se senere). 5. Test & overdragelsesfasen test og overdragelsesfasen. Testrapport Testrapporten beskriver konklusionen af testen. Ønsket er at testen ikke afslørede fejl, men ofte kan der være generelle kommentarer til testens forløb eller resultat. Man kan vælge at bruge Notes feltet på Application System elementet til konklussionen på testplanen. Ellers kan man oprette et nyt tekstfelt specifikt til det formål. Selve testrapporten kommer så til at indeholde dette felt samt nogle felter til at godkende og underskrive testrapporten. Den gennemførte testplan vedlægges som bilag til testrapporten. Systemdokument Systemdokumentet beskriver hele det leverede system. Dvs alle leverede moduler og den tilhørende datamodel. Alle disse oplysninger er tilgængelige i Designers Repository, så der ligger intet dokumentationsarbejde i denne opgave. Konklusion Kun fantasien sætter grænser for, hvad man kan udnytte information til, når den er placeret i en relationel database. Derfor er Designer et perfekt værktøj til projektstyring. I stedet for at skulle holde styr på stribevis af versionerede dokumenter, og hele tiden skrive statusrapporter, kan man på denne måde generere de dokumenter man har brug for når man har brug for dem (til godkendelse eller lign). Resten af tiden finder man de oplysninger man leder efter direkte i Designers Repository, hvor de alligevel bliver til, når udviklerne udfører deres arbejde. Projektstyring med Designer - 2 I næste nummer af OracleEkspert vil jeg beskrive hvordan vi har implementeret overvågningsværktøjer, som kan hjælpe både projektledere og udviklere til at danne sig et overblik over deres projekters fremdriften, estimeret resttid, milepæle mv. Jeg vil også meget gerne høre om hvordan andre udnytter Designer ifm projektstyring. Hvis I bruger Designer, så send mig et par ord om hvordan I har valgt at håndtere udfordringerne med hensyn til dokumentation, opgavefordeling, estimater, tidsplaner osv, så vil jeg bringe ideerne frem i næste nummer. SKRIV EN ARTIKEL Vi betaler dig 700 kr pr side for artikler, som trykkes i OracleEkspert (400 kr pr side for engelsksprogede artikler). Du kan også komme til at vinde OracleEkspertprisen, som i december-nummeret uddeles til forfatteren af årets bedste artikel. Deadline for artikler til OracleEkspert nr 14 (oktober 2001) er fredag den 13. september Har du lavet noget genialt, som kunne have interesse for andre Oracle-udviklere, ledere, planlæggere mv, så skriv en artikel til OracleEkspert. Sådan gør du: Aflever et oplæg på ca 200 ord via vores hjemmeside: Når oplæget er godkendt af redaktionen, kan du skrive selve artiklen. Du kan hente en template på vores hjemmeside. Artiklen skal også godkendes af redaktionen. Dette sker ud fra kriterier om seriøsitet, relevans og teknisk niveau. Artiklerne skal henvende sig til erfarne Oraclefolk. Emnet skal blot være relateret til Oracle. Den normale størrelse af en artikel er 3-6 sider. Hvis din artikel falder udenfor denne størrelse, bør du gøre os opmærksom på det, inden du begynder at skrive den. Tips: Tips, triks, hints og gode råd som trykkes i OracleEkspert, belønnes med et stort hjerte af økologisk marcipan og chokolade. Hvis du feks har fundet ud af hvordan man kan omgå en irriterende bug i et af Oracles værktøjer, hvis du har lavet en fix Select-sætning, der kan vise noget interessant om databasen, eller hvis du har opdaget en fix procedure eller funktion i databasen, så gå ind på: og beskriv det. OracleEkspert December