Projektarbejde 13. Projektarbejde Først er det på sin plads at se lidt på de arbejdsmetoder, der med fordel kan benyttes, når man arbejder med at lave større EDB-systemer. PROBLEMLØSNINGENS FASER: l. Idé-oplæg og problemformulering 2. Problem-analyse og problem-afgrænsning 3. Design af løsning 4. Løsning 5. Dokumentation herunder test af løsning 6. Brugervejledning 7. Afsluttende vurdering Dette virker jo overskueligt. Tilsyneladende er det bare at gå i gang fra en ende af og så køre de 7 faser igennem. I virkeligheden ville det være en dårlig arbejdsmetode og også en uoverskuelig proces (herom siden). 1. Denne fase klares efter diverse diskussioner med den fremtidige bruger. 2. Problemet analyseres sammen med brugeren og en foreløbig afgrænsning defineres. Ofte vil man her definere delproblemer, som man ønsker løst først. Man skal også gøre sig klart, at måske ikke hele problemet egner sig til løsning vha. EDB NB! *) Man bør hellere være for forsigtig med, hvad man planlægger at lave, og så evt. udvide projektet siden, end gøre det modsatte!!!! 3. Hernæst skal man overveje hvilke uddata, der repræsenterer en løsning på problemet. Ofte vil man sammen med brugeren designe typiske skærmbillede eller printerudskrifter, som man måtte ønske som resultat af databehandlingen. Det er ofte først under udformningen af kravene til uddata, at det viser sig, hvilket problem der egentlig ønskes løst. Dette kan så føre til en revision af punkterne l og 2. 1
Man gør sig dernæst klart, hvilke inddata der er nødvendige for at fremskaffe de ønskede uddata. Endelig analyseres forbindelsen mellem inddata og uddata. Hvilken behandling skal der ske af inddata for at skaffe uddata? Her vil det oftest være nødvendigt at lave diagrammer, der viser processen fra inddata til uddata, især opdelt på delprocesser i forløbet. 4. Først må man undersøge hvilket anvendelses-værktøj eller programmeringssprog, der er bedst egnet til at løse den konkrete opgave. Hvis punkterne 2 og 3 nu er omhyggeligt gennemarbejdede, vil denne fase vise sig kun at være et stykke håndværk, der lige skal gøres - - - - - - 5. Testkørsler foregår ved, at programmet testes, således at alle typer af inddata er gennemprøvet, og dermed alle delgrene i låsningen er testet. Ofte vil man her vælge inddata så simple, at man selv kan gennemskue, om uddata er korrekte. Testkørsler kan med fordel laves, så snart et modul af løsningen er klar (se nedenfor). Dokumentationen består i en beskrivelse af det færdige resultat, således at senere ændringer/udbygninger kan gøres lettere. Diagrammerne fra punkterne 2 og 3 vil her ofte kunne benyttes. Dertil kommer en beskrivelse af inddata og uddata, krav hertil, typer etc. 6. Brugervejledningen skal udformes, således at en bruger, der intet kender til jeres løsning og alle jeres overvejelser undervejs, og som intet kender til programmering, alligevel kan forstå det. Her vil kommenterede skærmbilleder være en stor hjælp. 7. I den afsluttende vurdering kan man f.eks. omtale: Evt. mangler eller begrænsninger (eller måske udvidelser) der er lavet i systemet i forhold til de under pkt. 2 nævnte. Hvorledes systemet vil kunne udbygges. Hvilke brugere, der vil kunne tænkes at have glæde af systemet. Projektrapporter Projektet skal måske resultere i en rapport. Projektrapporten kan ofte med fordel laves undervejs i problemløsningens faser. Det afhænger dog af, hvad rapporten skal indeholde. Ideelt set sørger man for undervejs i sit arbejdsforløb at lave printerudskrifter, således at rapporten vokser frem, mens opgaven løses. Rapporten skal derfor til slut indeholde næsten de samme elementer som nævnt i problemløsningens faser foran. 2
Et forslag til opgaveformulering til projektrapporten kunne være: Projektrapporten skal indeholde: En forside med projektets navn og jeres navne. En indholdsfortegnelse med sidehenvisning. - Laves selvfølgelig sidst. En problemformulering - typisk på 20-30 ord. Problemanalyse og afgrænsning. Forklar hvem brugergruppen er - tænkes at være. Forklar hvilke hoveddele jeres projekt er opdelt i evt. ved hjælp af strukturdiagram(mer), medtag evt. begrundelse. Forklar hvilke dele I evt. vil undlade at implementere - gerne med begrundelse. Henvis til udskrift af skærmbilleder. Lav brugervejledning. Anvend meget gerne kommenterede skærmbilleder. Husk brugerens forudsætninger, når I laver vejledningen. Afsluttende vurdering. Omtal evt. mangler eller udvidelser i forhold til oprindelig problemformulering. Hvorledes kan programmet evt. udbygges, hvis tiden tillader det. Tanker omkring projektarbejdet etc. Som bilag vedlægges skærmudskrifter samt kommenterede udskrifter af OnClickprogramdelene. Jeg forventer at rapporten fylder ca. 6-10 sider (afhængig af hvor mange figurer etc., der medtages) eksklusiv bilag og forside. Aflevering af rapport senest: tirsdag d. 3. oktober. God fornøjelse. Jeres lærer. 3
Eksempler på informationssystemer: Informationssystem over et land. Adventure-spil. IQ-test. Turisthjælp i din by. Hjælp til nye elever på skolen. ZOO-oplysning for mindre børn. Vort solsystem. Akkorder på en guitar Dit politiske tilhørsforhold. Kategorisering af kendte Pop-, Rock- eller andre grupper. Krydderurter og deres brug. Tilskudsregler på det sociale område. Matematisk formelsamling på EDB. Ny PC - Undersøgelse af behov. Valgfag på gymnasiet/hf. Gæt en by. Kategorisering af planter/dyr. Guder/helte fra mytologien. Et historisk forløb - Den amerikanske uafhængighedskrig f.ex. Oversigt over en komponist s liv og musik. Dette er kun ment som eksempler, der skal sætte din egen fantasi i sving. På de følgende sider er gennemkørt et eksempel på det førstnævnte informationssystem. 4
Projekt: Et EDB-informationssystem om et land 1. Idéoplæg En gruppe eller en klasse er enedes om at lave et informationssystem om et land. 2. Problemanalyse og -afgrænsning Det er ikke tanken at lave et professionelt system med alle mulige oplysninger om landet, så det bedste ville nok være, om man kunne finde et land, som er forholdsvis ukendt for os danskere, og hvor en mindre, overordnet informationsmængde ville være tilfredsstillende for brugeren af vores system. Er du gymnasieelev eller elev på et HF-kursus kunne et muligt land f.eks. være Operation dagsværk-landet. Brugergruppen kunne være skolens øvrige elever i ugerne op til dagsværksugen. Der indsamles materiale om landet. Hvilke emner skal med i vore system? Historie, geografi, undervisning, erhverv, religion... Det afhænger selvfølgelig af landet og af de oplysninger, der kan skaffes. Der noteres også, hvilke dele man enes om at lade ligge (i hvert tilfælde i første omgang). (Husk på * på side 1) Man enes måske om at dele emnerne ud på delgrupper i klassen og laver en fælles Mainform som f.eks. Hver gruppe kan lave sin del færdig, og så kan det hele samles ved kald fra Mainform til slut. Beslutter I jer til at lave hver sin del af det større system, skal I være opmærksom på at få grænsefladen - dvs. den del der kan overlappe mellem grupperne - helt afklaret. Det er ofte noget, der volder store problemer. 5
3. Design af løsning Overvej nøje mediet, I bruger, samt målgruppen - (elever på skolen?) - før I starter opbygningen af systemet. Store statistikker med mange tal er måske ikke så gode som Pie-diagrammer lavet i et Windows -regneark og f.eks. overført via Windows-klippebordet til et grafik-program (f.eks. PaintBrush), som kan gemme det i et grafik-format, der kan læses af Delphi (f.eks. Bitmap BMP). Store tekster kan lægges ind i en memo, og denne kan sættes til at scrolle (indstil scrolbar i Object Inspector); men meget store tekster er nok heller ikke hensigtsmæssigt - du må plukke de vigtigste informationer ud. Har du mulighed for at scanne billeder ind, er det absolut en god idé til at gøre dit system mere spændende. Lav en første skitse - PÅ PAPIR - af hvorledes dine skærmbilleder kunne se ud, før du går i gang. Når du skal gøre det på papir, er det fordi det kan være svært at overskue, hvorledes de forskellige forme kalder hinanden og hvordan. Eksempel på skitse: 6
4. Løsning Nu er det så bare et spørgsmål om at sætte sig til maskinen og gå i gang. Praktiske råd her: A. Gem fra start dit projekt i et bibliotek for sig selv. Så ved du, hvad der hører til projektet. B. Hold øje med navnene på dine filer. Skriv evt. ned på papir løbende - så du ved, at du også gemmer under det navn, du bruger i din uses-del. Du kan også her benytte dig af Delphi s View*Project Manager (Se Hovedmenuen øverst på skærmen.). C. Hvis du benytter billeder, så vær opmærksom på, at de ikke fylder for meget. Det afhænger selvfølgelig af, hvilken maskine du bruger, men jo større og flere billeder, du bruger, jo langsommere kører dit informationssystem. Hvis problemet alligevel opstår, så vær opmærksom på, at filer/forme kan dannes under kørsel. (Se afsnit 7). D. Vær opmærksom på at give dine komponenter og forme sigende navne. F.eks. Histknap til den button, hvorfra formen med name Historie kaldes. Og kald f.eks. denne forms unit for HISTORIP.PAS, når du gemmer den. E. Test løbende, at systemet kører, som det skal. F. Når hver delsystem er færdiglavet og gennemtestet, skal det hele kobles sammen. Dette gøres ved at hente projektet med den oprindelige Mainform ind og adde files til denne. Vær opmærksom på hvilke biblioteker, de forskellige dele ligger i. Hver gang en del er added, testes systemet igen og gemmes. 7
5. Dokumentation og test af kørsel Forestil dig, at en anden person skal overtage dit arbejde og uddybe det med ny information. Han/han skulle gerne benytte denne del af dit arbejde til hurtigt at overskue, hvorledes dette gøres. Et første overblik, kan passende gives af et (eller flere) strukturdiagram: (Hvis du f.eks. var i gruppen, der skulle tage sig af punktet Erhverv). * betyder, at dette er uddybet nedenfor. ** som Eksport. 8
Lav kommenterede udskrifter af skærmbilleder efter følgende anvisning. Metode til at lave skærmudskrifter: Hent den ønskede skærm frem i Delphi. Tryk på Print Screen-tasten for at overføre hele skærmbilledet, som du ser det på din skærm, til klippebordet. Tryk på Alt-tasten og på Print Screen-tasten på én gang, hvis du kun ønsker at overføre det aktive vindue. Gå ind i jeres tekstbehandlingssystem og tryk her på Indsæt fra klippebord - ikonen. Udskriv siden eller gem den til senere udskrift. Eksempel: Bilag 3: Dette viser historieskærmens udseende, efter at undermenupunktet 1884-85 er valgt: Memo7.Visible er gjort true. Visible for de øvrige memoer er gjort false. De øvrige valg af underpunkter i menuen resulterer i tilsvarende skærmbilleder. 9
Endelig kan en tabel over formene og deres indhold være rar at have: Hovedmenu-formen: Komponent (Caption) Type Name Kalder historie Button Histknap Historie - formen erhverv Button Erhvknap Erhverv - formen religion Button Reliknap Religion - formen undervisning Button Undvknap Undervisning - formen memo1 Memo Memo1 - billed1 Image Image1 - De øvrige laves tilsvarende. 6. Brugervejledning Sæt dig i brugerens sted. Forklar ham/hende, hvorledes informationssystemet bruges ud fra hans/hendes forudsætninger. Dette gøres ofte i punktform med overskrifter som f.eks. 1. Hvorledes bringes systemet til at køre. 2. Hvad viser der sig først på skærmen. 3. Hvorledes finder jeg de ønskede informationer, hvis jeg... A. B. C... 4. Når jeg ønsker at stoppe, hvad gør jeg så. Du kan med stor fordel benytte de skærmudskrifter, du tidligere har lavet igen. 10
Delphi er i sig selv meget brugervenlig, så du kan måske føle, at brugervejledningen er lidt overflødig og en gentagelse af, hvad du allerede har lavet. Det kan du have ret i; men det er nødvendigt at lave den, når vi opbygger de komplicerede systemer siden hen, så - tag det som en regel - den skal bare være der. 7. Afsluttende vurdering Omtal her, hvad du valgte, og hvad du ikke valgte at lave, gerne med begrundelse. Kommentér hvad du lavede. Det er ikke afslørende at skrive: Nu bagefter kan jeg godt se, at det kunne have været lavet smartere, hvis jeg... Vi kan alle blive klogere - heldigvis. 11