Checklister. Appendiks til bogen Softwaretest. Indhold

Størrelse: px
Starte visningen fra side:

Download "Checklister. Appendiks til bogen Softwaretest. Indhold"

Transkript

1 Checklister Appendiks til bogen Softwaretest Indhold Checklister... 1 Appendiks til bogen Softwaretest Indledning Checkliste til review af foranalysen Checkliste til review af analysefasen Checkliste til review af designfasen Checkliste til review af kode Checkliste til 'Test af test' Checkliste til review af datamodel Checkliste til review af moduldiagram Checkliste til review af klassemodel Checkliste til overdragelsesreview Checkliste til driftsreview Kvikstart Checklisten er tilgængelig online på som appendiks Side 1 af 24

2 1. Indledning Checklister bruges til at støtte reviews. Forberedelsen bliver nemmere, og gennemførelsen bliver mere systematisk. Spørgsmålene kan enten bruges til at gå slavisk frem efter, eller de kan bruges til at summere op på et review. Ikke alle spørgsmål behøver at være relevante for et givent review. Vælg de spørgsmål ud der skal besvares. Dokumenter alle benægtende svar i reviewrapporten, sammen med årsagen. Dokumenter de spørgsmål der ikke kan besvares, sammen med årsagen. Checklister er en del af et kvalitetsstyringssystem. De indgår dermed i det præventive 0-fejl arbejde. Man kan nøjes med at bruge dem til simpel efterkontrol af færdige produkter. Men jo mere aktivt kvaliteten bliver styret, jo mere bliver checklisterne en del af sikringen snarere end kontrol. Når kvalitetsstyringen er fuldt udbygget, f.eks. efter ISO 9000 standarden, bliver efterkontrollen mindre, og checklisterne vil kun indeholde de nyeste erfaringer og risici. Det øvrige er indbygget i procedurer. Listerne vil stadig være nyttige. Det er da en fornøjelse at checke at det hele fungerer, og tiden til at hakke en checkliste af, er givet godt ud. Reviews er et godt middel til erfarings- og videnspredning. Checklister øger yderligere den nytte. En checkliste skal ejes af en person eller afdeling i virksomheden. Selv når checklisterne er en del af et kvalitetsstyringssystem, skal ansvaret for hver listes udbygning og vedligeholdelse være fuldt defineret. Uajourførte checklister er døende checklister. Checklister dokumenterer vedtagne standarder, og er på den måde indiskutable. Når spørgsmålet er sat på listen, skal det tages alvorligt. De er en hjælp, således at det der engang er diskuteret, ikke skal trævles igennem igen. Det betyder ikke at checklisterne er statiske. De skal holdes levende. Hvis der findes en fejl på et senere tidspunkt end ønskeligt, skal der defineres et checkspørgsmål, der fanger den tidligere. Det sker som seriøs videreudvikling, foretaget af den ansvarlige for checklisten. Spørgsmålenes relevans skal også vurderes, og spørgsmål udgår om nødvendigt. Men brug ikke tiden på de konkrete reviews til det. Nøjes med at markere at der er brug for at vurdere det senere. Spring ikke en checkliste over, fordi den virker bekendt eller overflødig. Selv den mest erfarne pilot checker tingene før start og landing. Selvom det er en triviel procedure, hvor der gang efter gang udføres de samme handlinger, og checkes de samme ting. Husk at udbyttet nogle gange ligger i, at alt er i skønneste orden. Checklister er mest synlige på inspektioner. Men ethvert review kan summeres op ved hjælp af dem. 2. Checkliste til review af foranalysen Foranalysen er udviklernes grundlag for at beskrive det rette system. Foranalysen beskriver den ønskede forretningsmæssige forandring. Et review af foranalysen er en mulighed for at skaffe et komplet, korrekt og stabilt grundlag. Resultatet af foranalysen er en kravspecifikation, med eller uden Use Cases. Spørgsmål: 1. Er kravspecifikationen komplet således at alle krav er til stede - den skal kunne skrives under som en kontrakt Side 2 af 24

3 2. Er hvert krav kvantificeret i form af et eksakt målbart mål - det er ikke nok at kræve et hurtigt system, der skal specificeres målbare tider og volumener 3. Er hvert krav operationelt, således at det er let at måle - det er ikke nok at det kun kan måles på nordpolen hvert andet år 4. Er hvert krav entydigt - opfatter alle interessenter det på samme måde 5. Er hvert krav kommunikerbart - en matematisk formel kan være præcis, men ikke nødvendigvis det bedste til formidling 6. Er hvert krav sporbart - kan man se, hvem der har stillet kravet 7. Er kravene set under eet 'ikke-overlappende' - specifikke uafhængige krav er bedre end brede formuleringer med potentielt overlap 8. Er kravene set under eet 'ikke modstridende' - visse modstridende krav kan ikke undgås, fx på områder hvor performance kolliderer med andre systemegenskaber, men de modstridende punkter skal være dokumenterede 9. Er kravene indbyrdes beskrevet på et ensartet og tilstrækkelig detaljeret niveau - en stor forskel skal motiveres 10. Er kravene vurderet med hensyn til deres økonomiske vægt - evt. sværvægtere skal være synlige 11. Er der taget stilling til systemets levetid - en levetid over fem år stiller større krav til vedligeholdelse, udbygning og flytbarhed 12. Indeholder foranalysen en godkendt Cost/Benefit beregning - og kan den eftervises og efterkalkuleres 13. Er kravene stemt af med de nuværende og kommende forretningsgange på brugsstederne - specielt hvis der stilles krav på andres vegne, således at det ikke er de egentlige brugere, der er ophav 14. Betyder kravene en kraftig omlægning af forretningsgange - hvis omlægningen ikke er identificeret, kan det skabe problemer for testen senere 15. Har alle interessenter været involveret i at stille krav og involveret i at godkende dem - en interessentanalyse kan hjælpe til med at besvare spørgsmålet 16. Er hvert krav godkendt specifikt af brugere/betalere - en underskrift er minimum Side 3 af 24

4 17. Er det enkelte krav testbart senere i forløbet - hvis det er brugere der skal teste, skal spørgsmålet rettes til dem 18. Dokumenterer kravspecifikationen kriterierne for at godkende ibrugtagningen - eller i det mindste hvornår de defineres, hvis det er på et senere tidspunkt 19. Er alle krav relevante - en kravspecifikation må ikke blive for 'fed' af ligegyldige krav 20. Kan analysen gennemføres på foranalysens resultat - dem der skal gennemføre analysen skal besvare spørgsmålet, og med kravspecifikationen som det eneste grundlag 21. Er der skelnet mellem 'nødvendige' og 'ønskværdige' krav - i modsat fald skal det slås fast at alt er 'nødvendigt' 22. Er kravene til integration og samspil med andre systemer beskrevet - på en måde der er målbar og operationel 23. Er der uafklarede forhold, og fremgår de i så fald tydeligt - dette spørgsmål skal besvares højt af alle tilstedeværende 24. Er der stillet konkrete krav til nøjagtigheden af systemets data og beregninger - man kan godt nøjes med at specificere et generelt krav, men spørgsmålet må gerne stilles, for at høre om der er tunge sager på tapetet. 25. Er der stillet krav til systemets robusthed - især hvis nogle interessenter forventer 100 % robusthed, skal det fremgå 26. Er der stillet krav til ensartetheden af systemet - helst med henvisning til en standard 27. Er der stillet krav til brugervenlighed - igen kan en standard bruges som henvisning, suppleret med de krav der udspringer af brugernes og brugsstedets forhold 28. Er der stillet krav til testbarheden - det er nødvendigt at vide hvor megen tid der er til rådighed til test, og hvilke typer af testere der skal kunne gøre det 29. Er der stillet krav om forvaltningsegnetheden - gerne som rammer for en egentlig forvaltningsaftale, selv på dette tidlige tidspunkt 30. Er der stillet krav til graden af genbrug - evt. hensigtserklæringer kan ikke bruges, der er brug for at se kravene på tryk 31. Er kravene til ydeevne synlige og omkostningsberegnede - og især at det fremgår om kravene er komplette Side 4 af 24

5 32. Er der stillet krav til sikkerhed omkring dataintegritet, dataopbevaring, datatransport, autorisation etc. - de må ikke udskydes til analysen 33. Er der stillet krav om systemets flytbarhed - hvis flytbarhed kun er 'ønskværdig', skal det fremgå 34. Er der driftsmæssige krav der skal være afklaret på dette tidspunkt, og som ikke er med i kravene - især hvis de skal hentes hos forskellige interessenter 35. Er der stillet krav om fall-back procedurers omfang og ambition - det kan være en del af mange andre krav, fx sikkerheds- eller driftsmæssige, men det skal checkes at det er tilfældet 36. Er der specificeret en procedure for behandling af ændringsønsker - det er altid rart at få sin 'Change Control Procedure' (CCP) godkendt, før den er nødvendig at bruge 37. Er der en vurdering af hvor mange ændringsønsker der vil blive fremsat - selvom det er umuligt at kvantificere, kan diskussionen være nyttig 38. Er den nødvendige forretningsmæssige viden til stede - er brugerne kompetente i forhold til kravenes ambitioner 39. Er den nødvendige IT-faglige viden til stede - er IT-siden kompetent i forhold til kravenes ambitioner 40. Er estimaterne på udviklingstid og afleveringsfrister godkendte og realistiske - der kan godt være afvigende meninger, men det er jo det, man er samlet for, så man kan få det på bordet 41. Er der taget stilling til strategier for udvikling, test og implementering - de er ofte underforståede, men derfor kan der godt være uoverensstemmelser 42. Er der skrevet en testspecifikation - eller i hvert fald taget stilling til om og hvornår det skal gøres 43. Er der taget stilling til hvem der skal udarbejde testdata til hver testfase - det drejer sig især om dem der skal udarbejdes uden for projektgruppen, dvs. til bruger- og accepttest 44. Er estimering foretaget ved hjælp af en formel og anerkendt teknik - det kan være for eksempel være Function Points 45. Er der taget stilling til hvilke typer af forretningsmæssige risici, der bliver aktuelle - og udtrykt i brugersprog af brugere Side 5 af 24

6 46. Er der taget stilling til hvilke risici der kan opstå for udviklingsforløbets succes - her kan erfaringen og eksempler hjælpe diskussionen på gled 47. Ud over de allerede stillede spørgsmål kan der så svares ja til at alle standarder og retningslinier for foranalysen er overholdte - det gælder også evt. vedtagne ISO-, AQAP- og IEEE-standarder. 48. Kan kravspecifikationen erklæres for fejlfri - i modsat fald skal svarene dokumenteres i reviewrapporten 49. Kan reviewdeltagerne underskrive reviewrapporten - i modsat fald skal svarene dokumenteres i reviewrapporten 3. Checkliste til review af analysefasen Review af analysen gennemføres af opgavestillere og testere. Det skal afgøre om der er beskrevet en løsning der helt og fuldt opfylder de stillede krav, inden for det aftalte budget. Spørgsmål: 1. Kan det klart konstateres, at der er funktioner, der opfylder hvert enkelt krav, der er specificeret i kravspecifikationen - det kan være svært at svare ja til, men det vil være en test i sig selv 2. Kan det klart konstateres, at der er data, der opfylder hvert enkelt krav, der er specificeret i kravspecifikationen - det kan være lige så svært at svare på, men det er et endnu vigtigere spørgsmål, hvis målet er 0-fejl 3. Er der funktioner i systemet, der skal sørge for at imødegå de forretningsmæssige risici ved at bruge systemet - der bør være funktioner, der forhindrer at de opstår, og funktioner der rapporterer noget unormalt 4. Passer de definerede funktioner med de daglige forretningsgange - ellers skal der aktiviteter på planen, der ændrer forretningsgange 5. Passer funktioner i deres afgrænsning til autorisationen af brugerne - måske skal autorisationsniveauerne ændres, men der kan også være skudt galt på funktionernes indhold og afgrænsning 6. Passer de data, der bruges i en funktion, med autorisationen af brugerne - stil spørgsmålet, uanset svaret på det foregående 7. Passer de definerede funktioner med brugernes uddannelse - ellers skal der uddannelsesaktiviteter på planen før implementering 8. Kræver de definerede funktioner ændringer i andre systemer - og er de dokumenteret i en oversigtlig form Side 6 af 24

7 9. Er alle data, der bruges, dokumenterede - helst i et Repository eller lignende værktøj 10. Dokumenterer analysen at alle data er til rådighed, på det sted og på det tidspunkt i organisationen hvor de skal bruges - det er en forudsætning for at systemet ikke senere skal blive opfattet som tungt at arbejde med 11. Omfatter analysen en dokumentation af datas kvalitet og pålidelighed i brugerorganisationen - det har betydning for den grad af robusthed der skal være en del af funktionerne 12. Genererer systemet selv data, og er de en del af analysens dokumentation - de skal også dokumenteres i et Repository 13. Er alle data undersøgt for redundans - ellers kan man være sikker på at mængden af redundante data øges 14. Lever analysen op til kravet om svartider, datamængder etc. - spørgsmålet stilles traditionelt først efter designfasen, men der kan det være for kostbart at ændre systemet 15. Er der afhængigheder til andre systemer udover dem der var en del af kravene - der skal argumenteres for hver afhængighed 16. Er de driftsmæssige behov analyseret - ellers skal der aktiviteter på planen, der gør det 17. Er behovet for nye/ændrede driftsprocedurer identificeret - med distribuerede arkitekturer og mange typer servere, bliver denne del af analysen ikke mindre 18. Er behovet for den fremtidige support identificeret - før det er gjort kan der ikke beregnes en cost/benefit 19. Har analysen dokumenteret behovet for et revisionsspor, også kaldet 'audit trail', og andre revisionsmæssige behov - denne del af analysen kan være udført sideløbende, separat fra det almindelige udviklingsarbejde 20. Kan det med den ønskede grad af tydelighed konstateres, at det endelige system vil have den krævede grad af brugervenlighed - kravet til denne egenskab skal påvises opfyldt i analysefasen 21. Kan det med den ønskede grad af tydelighed konstateres, at det endelige system vil have den krævede grad af indbyggede hjælp- og støttemuligheder - kravet skal påvises opfyldt i analysefasen 22. Kan det med den ønskede grad af tydelighed konstateres at det endelige system vil have den krævede grad af sikkerhed - kravet til denne egenskab skal påvises opfyldt i analysefasen Side 7 af 24

8 23. Dokumenterer analysen omfanget og udseendet på systemdokumentationen - det bør ligge som standard, men der kan være nogle valgmuligheder med hensyn til hvilke dele, der skal være blivende dokumentation 24. Dokumenterer analysen udseendet og omfanget af brugerdokumentationen - det bør være en del af kontrakten, det skal blot konstateres opfyldt i analyseresultatet 25. Omfatter analysen en vurdering af hver funktions testbarhed - resultatet af analysen er en samlet testplan for system- og/eller brugertest, og derfor skal tiderne holde 26. Er alle dele af analysen godkendt af de relevante interessenter - hver del skal reviewes og godkendes, både for funktioners og datas vedkommende 27. Kan designerne godkende analysen som mulig at designe på den til rådighed stående tid - en særlig variant på foregående spørgsmål 28. Stemmer analysens resultat med det vedtagne budget for at udvikle systemet - der er brug for at estimere hvor mange mandetimer, den resterende del af arbejdet kræver, og at det er inden for budgettet 29. Giver analysen grund til at tro at grundlaget for Cost/Benefit beregningen har ændret sig - det er et gedigent faresignal hvis en del af det forventede udbytte ikke kan påvises 30. Ud over de allerede stillede spørgsmål kan der så svares ja til at alle standarder og retningslinier for analysen er overholdte - dette gælder også evt. vedtagne ISO-, AQAP- og IEEE-standarder 31. Kan analyseresultatet erklæres for fejlfrit - i modsat fald skal svarene dokumenteres i reviewrapporten 32. Kan reviewdeltagerne underskrive reviewrapporten - i modsat fald skal svarene dokumenteres i reviewrapporten 4. Checkliste til review af designfasen Det kræver god håndværksmæssig kunnen at designe et enkelt og testbart system på grundlag af analysens løsningsbeskrivelse. Designreviewet skal konstatere, at det er gået godt, og checklisten skal sørge for, at det kan konstateres hurtigt og troværdigt. Det er nyttigt at involvere opgavestillere og andre designere. Men det kalder også på medvirken af testere. Spørgsmål: 1. Er analysen fuldt og helt omsat i designet - spørgsmålet skal gerne besvares af både analytikere og designere Side 8 af 24

9 2. Er der mere med i designet end i analysen - det skal motiveres, for principielt er det forbudt 3. Er der taget stilling til arkitektur - bruges der standardløsninger hvor det er muligt 4. Optræder alle funktioner synligt i systemet - med klar reference til løsningen 5. Optræder alle data synligt i systemet - med klar reference til løsningen 6. Er alle de kommende fysiske komponenter beskrevet - i en form der kan bruges som grundlag for konstruktion 7. Bliver hver entitet/klasse oprettet, læst, opdateret og slettet i en synligt, veldefineret og dokumenteret komponent - evt. dokumenteret i et CRUD-diagram 8. Er alle attributterne på entiteter/klasser beskrevet - det er en klar misforståelse at udsætte noget til konstruktionen 9. Er alle grænseflader beskrevet - fordelt på de tre typer af interne, eksterne til andre systemer i samme driftsmiljø og eksterne til andre driftsmiljøer 10. Er alle skærmbilleder beskrevet og godkendt af opdragsgiver eller brugere - de kan evt. fremstilles af brugerne selv 11. Er alle databaser definerede - med en kraftig involvering af DBA, og evt. leveret af dem som underleverance 12. Er kravene til tilgængelighed kendte - og er det sandsynliggjort at de kan opfyldes 13. Er kravene til ensartethed kendte - og opfyldes de af designet 14. Er kravene til brugervenlighed kendte - og opfyldes de af designet 15. Er designet testbart i sig selv - det er det vi er i gang med at finde ud af 16. Leder designet til et testbart system - der skal være grundlag for systemtest 17. Kan designet udbygges fremover Side 9 af 24

10 - og leder det til et fysisk system, der er let at udbygge 18. Er der tilstræbt genbrug - som regel skal der gøres en indsats for at få det genbrug der teknisk er mulig 19. Øger det nye system den fremtidige mulighed for genbrug - er det ønskelige øgede omfang fastsat formelt 20. Er ændringer til andre systemer identificeret og accepteret - problemet er at de kan give ændringer i ens eget system, hvis de ikke kan gennemføres som forudsat 21. Er samspillet mellem manuelle rutiner og systemet beskrevet - på en måde der kan forstås af brugerne af de manuelle rutiner 22. Følger designdokumentationen en vedtagen standard - og synes andre, at den er læselig 23. Er navnestandarden fulgt - detailspørgsmål på det foregående 24. Er 'exception-handling' beskrevet - det vil sige 'error-handling', afvisninger og fejlmeddelelser til brugere, ikke mindst vedrørende netværk og databaser 25. Er backup og recovery fastlagt - og er niveauet i overensstemmelse med en evt. politik på området 26. Er alle attributter beskrevet i et Repository - eller en tilsvarende registrering der sikrer ajourførte og tilgængelige beskrivelser 27. Er alle valideringsregler beskrevet - en databeskrivelse er ikke komplet uden 28. Er kravene til drift og support beskrevet - de kan ikke afleveres tidligt nok for at give mulighed for at forberede sig 29. Er accessmetoder fastlagt og beskrevet - gerne i form af formel accessmodellering 30. Er alle logiske input designede og beskrevne - det er f.eks. skærmbilleder, transaktionsdata, lyspenne, berøringsfølsomme skærme, menuvalg, stregkoder og sensorer 31. Er alle logiske output designede og beskrevne - det er f.eks. skærmbilleder, logfiler, transaktionsdata, svar, notifikationer og websider 32. Er krav til kapacitet kendte og beskrevne Side 10 af 24

11 - RAM, CPU, buffere og grafikkort 33. Er der specielle krav til systemsoftware - for eksempel operativsystem, transaktionsservere, DBMS, Application Server 34. Er krav til konvertering kendte og beskrevne - konvertering kan være årsag til ændringer i analyse og design, hvis den ikke låses fast senest i designfasen 35. Er brugervejledninger og indbygget hjælp og støtte, designede - det skal være færdigt før konstruktionsfasen begynder 36. Er uddannelsen i systemet designet, og godkendt af målgruppen - kursusindhold og uddannelsesmateriale koster tid at fremstille og skal designes fornuftigt 37. Er alle underleverandører adviseret - og på plads med formelle aftaler 38. Ud over de allerede stillede spørgsmål kan der så svares ja til at alle standards og retningslinier for designet er overholdte - det gælder også evt. vedtagne ISO-, AQAP- og IEEE-standarder 39. Kan designresultatet erklæres for fejlfrit - i modsat fald skal svarene dokumenteres i reviewrapporten 40. Kan reviewdeltagerne underskrive reviewrapporten - i modsat fald skal svarene dokumenteres i reviewrapporten 5. Checkliste til review af kode Det er en forudsætning for review af kode, at der har været gennemført en designfase, og at designet er reviewet. Kodens fysiske mængde kræver, at det detaljerede design er ført frem på komponentniveau. Reviewet af designet har derfor omfattet en del af de generelle egenskaber ved koden: robustheden for komponenten som helhed vedligeholdelsesvenlighed for hele designet nøjagtigheden af formler og beregninger nøjagtigheden (precision) af datavariable Bemærkningerne skal ses i lyset af ønsket om at review på kode skal reduceres til mindst muligt. Alt hvad der kan reviewes og godkendes i faser forud for kodning, skal blive det. Kode er et relativt grundlag at kontrollere og måle på. Mængden af den gør den også mindre egnet til review. Spørgsmål, der går på det specifikke sprog, er ikke medtaget. Der må opstilles standarder og checklister for det eller de sprog der benyttes. Checklisten tager udgangspunkt i, at der reviewes en komponent ad gangen. Det er designere og kollegaer, der er reviewdeltagere. Side 11 af 24

12 Spørgsmål: 1. Er designede komponenter kodet i tilsvarende moduler - eller begrund hvorfor der er flyttet rundt på koden i forhold til designet 2. Er hver komponent komplet i forhold til sin opgave - eller får det hjælp af andre moduler 3. Er kodens kontrolstruktur acceptabel - den letteste måde at kontrollere det på, er at bruge et af de simple forvaltningsværktøjer, der viser struktur og sammenhænge, ved at bruge koden som input 4. Er kodens indrykning og disponering efter standard - eller som minimum fornuftig 5. Er koden læsbar - og udpeg på reviewet de konkrete steder der ikke umiddelbart er til at forstå 6. Er der dele af koden, der virker overflødige - eller er det på nogen måde overraskende, at den er der 7. Er navnestandarden fulgt - og er alle navne, uanset standarden, til at læse og forstå 8. Er koden robust i en grad, der hindrer nedbrud - den generelle robusthed er reviewet i designet, men der skal checkes interne risici, fx: mellemregninger over- og underflow zerodivide løkkers start og slut opslag i tabeller med en variabel 9. Er der interne buffere, dynamiske tabeller eller andet, der kan få overflow - en uddybning af foregående spørgsmål 10. Bliver alle returværdier i in- og eksterne kald validerede - stol aldrig på et andet modul 11. Er alle datavariable initierede - stol aldrig på en kompilers eller et operativsystems adfærd, den ændrer sig i morgen 12. Er der beregnet en McCabe kompleksitet for modulet, og er den acceptabel ( <10 ) - det er nemmere at gøre på koden end på designet, hvor det skal tælles med håndkraft 13. Er 'exception-handling' tydelig - den må ikke ligge som en manglende eller tom else-udgang, fordi det ikke kan ske 14. Er alle beregninger korrekte i forhold til kravspecifikationen Side 12 af 24

13 - det er især et spørgsmål om at programmøren har forstået algoritmers brug og indhold 15. Er alle beregninger korrekte i forhold til kompilerens oversættelse af dem - det er bedst at sikre sig med parenteser og flere instrukser, hvis man er usikker 16. Er reviewerne trygge ved beregningerne - det er et spørgsmål om gennemskuelighed og logisk opstilling af koden 17. Er koden vedligeholdelsesvenlig - reviewerne skal vurdere, hvor nemt det bliver at ændre i den 18. Kan komponenten forstås på 15 minutter - eller på den tid der er specificeret i standarden 19. Kan den forventede performance opfyldes - det vil vise sig i systemtesten, men evt. flaskehalse kan identificeres på denne White-Box facon 20. Er koden testbar med hensyn til antallet af veje - er antallet kendt 21. Er koden testbar med hensyn til den tid, der er til rådighed - et spørgsmål der kan forekomme udviklere ligegyldigt, men ikke nødvendigvis for testere 22. Ud over de allerede stillede spørgsmål kan der så svares ja til at alle standards og retningslinier for konstruktion er overholdte - det gælder også evt. vedtagne ISO-, AQAP- og IEEE-standarder 23. Kan konstruktionen erklæres for fejlfri - i modsat fald skal svarene dokumenteres i reviewrapporten 24. Kan reviewdeltagerne underskrive reviewrapporten - i modsat fald skal svarene dokumenteres i reviewrapporten 6. Checkliste til 'Test af test' Hvor godt er testen lagt til rette? Og hvornår er det et godt spørgsmål at stille? Svarene bruges til at måle om testen er planlagt godt nok. Men det er ikke nok at stille det overordnede spørgsmål: Er vi forberedt godt nok? Der er brug for en konkretisering af det. Checklistens indhold kan spredes ud på de øvrige checklister. Efter hver udviklingsfase skal en del af testen være planlagt, og de tilsvarende checkspørgsmål skal stilles. De er samlet her for overblikkets skyld, og for at give en model der kan bruges til en samlet godkendelse. Modellen er den konsulenter bruger, når de skal vurdere, om en test er planlagt godt nok. Modellen er inklusive scoring, og med retningslinier for at bruge resultatet. Checklisten er ideel som afslutning på et testplanlægningsseminar. Spørgsmålene kan besvares enkeltvis af deltagerne og derefter gennemgås samlet, for at få en opfattelse af status. Hvert spørgsmål kan besvares med et X i JA, et kryds i NEJ, eller en BÅDE/OG besvarelse ved at sætte kryds i begge kolonner. Grunden til at der må besvares med både JA og NEJ er at modellen bruges i praksis. Når et Side 13 af 24

14 rigtigt projekts planlægning vurderes, er der uvægerlig en håndfuld af spørgsmålene, der kun kan besvares fornuftigt med et både/og. Prøv selv. Svarene behandles i to omgange. Først ved at give nogle point for JA/NEJ og BÅDE/OG. Derefter kategoriseres de rene 'NEJ'. Spørgsmål Ja Nej 1 Der vedligeholdes en liste over fundne fejl 4 2 Der er udpeget en ansvarlig for test 3 3 Alle testere gennemgår en vedtagen uddannelse 1 4 Systemtesten udføres af egentlige testere 3 5 Testen planlægges i en selvstændig planlægningsproces 3 6 Testaktiviteterne optræder synligt på projektplanen 4 7 Alle testaktiviteter er bemandede 3 8 Alle testaktiviteter er tidsestimerede 3 9 Der er udarbejdet dokumenterede testcases 4 10 Testcases giver tilsammen en ønsket og kendt testdækning 4 11 Begrebet testdækning bruges overhovedet 1 12 Regressionstest kan udføres automatisk 2 13 Hvert testforløb logges, ikke kun eventuelle fejl 4 14 Kriteriet for afslutning af testen kan måles objektivt 2 15 Testen sker i niveauer, f.eks. modul, system, integration, etc Testerne anvender fælles kendte og anerkendte testteknikker 1 17 Resultatet af en test reviewes og godkendes 3 18 Interessenterne kan deltage i, eller følge, forløbet 1 19 Testcases planlægges før kodning 4 20 Testforløbets fremdrift og færdiggørelsesgrad måles løbende 2 21 Testplanlægningen er godkendt formelt 3 22 Testere har de ønskværdige og nødvendige værktøjer 2 23 Testforløbet er planlagt på grundlag af formelle retningslinjer 1 24 Testforløbet designes og dokumenteres ens i organisationen 1 25 Det nødvendige tidsforbrug til test er estimeret før testen starter 2 26 Komponenters kompleksitet vurderes maskinelt (altså vha et værktøj) 2 27 Fejlrapporter opsamles i en database 2 28 Udviklere og testere bruger samme testbegreber 1 Første behandling af svarene: optælling af point En JA-markering tæller 0 point En NEJ-markering tæller 4 point En markering i begge kolonner tæller 2 point Den samlede score bedømmes således: 0-28 point: Dette testforløb er velplanlagt. Det har gode muligheder for et roligt og vellykket forløb. Side 14 af 24

15 29-56 point: Det ser godt ud, forudsat visse justeringer. Der er både mulighed for et tilfredsstillende som et utilfredsstillende forløb point: Forløbet bliver højst sandsynligt utilfredsstillende. Det er nødvendigt at sætte aktiviteter i gang til at imødegå en klar risiko for et turbulent forløb point: Testen skal tilrettelægges forfra. I de tilfælde hvor der er brug for at sætte forbedrende tiltag i gang, er spørgsmålet så nu: hvad skal der ændres på. For det første kan alle spørgsmålene vurderes enkeltvis. Det vil give grund til at ændre på nogle forhold. Men spørgsmålenes sammensætning er ikke tilfældig. For at få en indikation af hvad der skal forbedres, er der behov for at kategorisere svarene. Ellers kan man risikere at rette på forhold, der faktisk ikke giver den ønskede forbedring. Anden behandling af svarene: kategorisering Alle de rene NEJ'er, d.v.s. dem der har udløst fire point, skal placeres i en af fire kategorier. Tallet 1,2,3 eller 4 der er noteret ved hvert spørgsmål, repræsenterer kategorierne. Antallet af rene NEJ'er med et 1-tal optælles. Ligeså antallet af 2-taller, 3-taller og 4-taller. De fire kategorier er: 1. Uddannelse 2. Værktøjer 3. Ressourcer & Organisation 4. Metoder & Teknikker Fordelingen af de rene NEJ'er i hver kategori peger på de typer af mangler, der skal udbedres. Hvis det viser sig at der er behov for flere ressourcer, vil det ikke være smart at sætte ind med uddannelse. Eks.: En projektgruppe har en besvarelse med fire rene NEJ'er, og det er på spørgsmålene 12, 14, 21 og 25. Vi ser at det giver tre i kategori 2 og 1 i kategori 3. Der er brug for at diskutere om de nødvendige værktøjer er til rådighed. Spørgsmålenes placering i en kategori er diskutabel. Spørgsmålene er diskutable i det hele taget. Men ved at besvare dem får man den diskussion, der er brug for. Spørgsmålene skal bruges til at træffe beslutninger. Det betyder at man ikke får garanti for et succesfuldt projektforløb ved at kunne svare JA til det hele. Men man har forbedret sin planlægning markant, ved at have taget stilling til alle spørgsmålene. Det samme gælder for kategorierne. Ved at placere NEJ'erne, får man en diskussion og beslutning om den tilsvarende kategori. 7. Checkliste til review af datamodel Datamodellen skal reviewes og godkendes som en væsentlig del af testforløbet. Side 15 af 24

16 Der er en vis diskussion om brugere, og/eller andre ikke IT kyndige, kan teste en datamodel. Checklisten kan bruges under alle omstændigheder. Enten er brugere deltagere på et fortolkende review, hvor de forklarer udviklerne hvordan modellen forstås. Eller også er de deltagere på en Walk-Through/Play-Through, hvor testdata eller scenarier, spilles igennem af brugere og udviklere i fællesskab. Reviewet skal teste datamodellen, som en færdig model af systemet. Det sikrer den indholdsmæssige validering. Reviewet skal også undersøge om dataanalysen er udført ordentlig. Det er grunden til, at der er spørgsmål om andet end lige den tegnede model. F.eks. også om hvordan entiteterne er identificeret. Spørgsmål: Modellen 1. Er modellen komplet - eller er der underforståede dele, der ikke er vist 2. Er alle entiteter vist - det er et detailspørgsmål på det foregående, men reviewdeltagerne skal sige ja 3. Er relationerne korrekte - og fuldt definerede 4. Er attributterne fuldt definerede - det skal konstateres uden for datamodellen, typisk i et Repository 5. Kan datamodellen tolkes af brugere inden for forretningsområdet - dokumenter de dele i reviewrapporten der ikke kan tolkes 6. Kan datamodellen forstås af udviklerne - det er farligt med områder, der indholdsmæssigt er modelleret efter andres forskrifter, 'med ført hånd', uden at udvikleren har forstået det 'helt' 7. Er modellen ikke-redundant - hver del af den skal være unik og nødvendig 8. Er modellen korrekt i forhold til standarden - eller i det mindste i forhold til projektets egne retningslinier De følgende spørgsmål er nødvendige at besvare i 0-fejl udvikling. Hvis modellen skal være komplet, korrekt og stabil. De er besvaret af udviklerne som en del af dataanalysen. Men de skal besvares igen i testen af modellen, for at være sikker på, at der ikke er huller. 9. Er hver entitet identificeret og verificeret med hensyn en forekomst af den: hvor den opstår i brugerorganisationen hvor og hvordan den indrapporteres hvem der indrapporterer den hvor og hvordan i systemet den oprettes Side 16 af 24

17 hvor og hvordan i systemet den læses hvor og hvordan i systemet den ændres hvor og hvordan i systemet den slettes hvor og hvordan i systemet den kommunikeres til andre systemer hvor og hvordan i systemet den rapporteres som output hvor og hvordan i systemet den indgår i beregninger hvordan den kan testes i systemtesten hvordan den kan testes i brugertesten hvordan den vedligeholdes 8. Checkliste til review af moduldiagram Mange udviklere sætter pris på at fremstille et moduldiagram. Det fungerer som en bro imellem løsningen der er specificeret i analysen, og det fysiske system på maskinen. Checklisten tager sit udgangspunkt i, at der til reviewet foreligger et samlet moduldiagram over hele produktet. Spørgsmål: 1. Har det enkelte modul den højest mulige binding (Cohesion) 2. Har det enkelte modul den lavest mulige kobling (Coupling) 3. Er nedbrydningen (faktoriseringen) komplet 4. Når moduler kaldes af andre: vurder rimeligheden 5. Passer grænseflader på begge sider af et kald 6. Udfører flere moduler det samme, det være sig fysisk eller logisk 7. Er nogle moduler unødigt specialiserede 8. Er strukturen overdreven 'kort' 'høj', 'tyk' eller 'tynd' 9. Er modulstørrelsen fornuftig i forhold til de kommende programmer 10. Er der opnået det mulige 'fan-in' 11. Er 'fan-out' ok 12. Ligger 'scope-of-effect' inden for 'scope-of-control' 13. Er der moduler med hukommelse (state memory) 14. Forekommer der 'decision-split' 15. Er der balance i diagrammet mellem den indgående og udgående proces ('afferent' kontra 'e- Side 17 af 24

18 fferent') 16. Er kalderegler for moduler overholdt 17. Overføres/returneres der datavariable uden om kaldet 18. Overføres/returneres der kontrolvariable uden om kaldet 19. Vurdering af modulers binding: - Hvis den eneste fornuftige måde at beskrive modulets funktionalitet på, er ved hjælp af en sammensat sætning, eller en sætning med et komma, eller en sætning med flere verber, har modulet sandsynligvis en lavere binding end 'funktionel'. - Hvis sætningen indeholder tidsorienterede ord som 'først', 'næste', 'efter', 'derpå', 'start', 'skridt', 'da' eller 'indtil' har modulet sandsynligvis 'temporær' eller 'procedural' binding. Det kan, dog i de færreste tilfælde, indikere 'sekventiel' binding. - Hvis der ikke følger et specifikt objekt umiddelbart efter verbet, er det sandsynligvis 'logisk' bundet. F.eks. 'valider alle transaktioner'. - Ord som 'initier', 'oprydning', 'housekeeping' og 'afslutning' peger på temporær binding. - 'Funktionelt' bundne moduler kan beskrives ved hjælp af een sætning, uden bisætninger, og ved hjælp af eet verbum. 9. Checkliste til review af klassemodel Checklisten gælder både for klassemodellen der dokumenterer analysen, og for den detaljerede model der dokumenterer designet. Spørgsmålene er i så høj grad de samme, at det er lettere at justere på inspektionstidspunktet. Spørgsmål: 1. Kan modellen forstås af brugere. - selvfølgelig skal selve notationsformen forklares, men den samlede model skal kunne fortolkes af brugere 2. Kan den enkelte klasse forstås af brugere. - identificer de klasser der ikke kan, og find årsagen. 3. Er modellen dokumenteret, således at der ikke er dele, der skal forklares. - er der viden i udviklingsgruppen, der skal forklares eller tillægges, fordi den ikke er dokumenteret 4. Er systemets afgrænsning korrekt i forhold til den forretningsmæssige nytte. - et vigtigt spørgsmål, fordi det er en af de mulige fælder, man kan falde i. Hele verden er fuld af objekter, der nemt kan defineres som klasser. Samtidig er der ikke matematiske regler for valg af klasser, så man skal sikre sig, at systemet ikke kun defineres af udviklere, der får øje på objekter. Side 18 af 24

19 5. Check klassernes navne. Kan de godkendes af brugerne. - et spørgsmål der erfaringsmæssigt åbner videre diskussioner. 6. Check at der ikke er forvekslet subklasser med attributter, check begge veje. - faktisk en ret almindelig fejl af 'nybegyndere'. Hvornår er 'bil' en klasse, og hvornår er det en attribut på klassen 'transportmidler'. Det er ikke en subklasse, hvis der skal registreres de mængder, man ejer, af hvert transportmiddel. Så langt de fleste gange giver det sig selv, men det skal checkes på inspektionen. 7. Kan alle klasser genkendes af brugerne som konkrete og eksisterende. - simpelt check, for at se om der er skabt nye klasser af hensyn til systemet. Der skal skelnes mellem konkrete, som kan godkendes af brugerne, og abstrakte, der f.eks. bruges til at være 'overklasse' for flere subklasser. Typisk for at repræsentere fælles attributter eller metoder. 8. Er associationerne mellem klasser korrekte, og kan de valideres som sådan af brugere. - korrekte associationer, og ikke mindst komplette, er vigtige, og at få dem godkendt og afgrænset. 9. Er associationernes attributter korrekte. - hvis den aktuelle valgte metode tillader at associationer har attributter. 10. Er associationerne dikteret af systemets forretningsmæssige nytte eller optræder nogle af hensyn til systemets konstruktion. - det er et godt spørgsmål til at verificere OO-analysen. 11. Er operationerne så klare, at så man kan definere konkrete metoder til dem. - spørgsmålet er vigtigst efter analysefasen. Der vil man have operationerne defineret pr. klasse. Senere er det for sent. 12. Når der er flere metoder til en operation, udfører de så den samme operation. - spørgsmålet stilles efter det detaljerede design. Det er en almindelig fejl at flere metoder er defineret til en operation, men hvor metoderne alligevel ikke kan siges at være ens, blot med en forskellig fysisk implementering. 13. Check antallet af associationer mellem klasser. Kontroller alle der ikke er binære. - det er problematisk med mangesidede associationer, hvor tre eller flere klasser skal ses i sammenhæng. Det giver typisk flere fejl senere. Men det er f.eks. tilladt i OMT-metoden. 14. Check 'Traceability'. I implementeringsfasen skal enhver del af systemet, det være sig en attribut, metode, klasse, etc. kunne føres tilbage til designet. Enhver del af designet skal igen kunne føres tilbage til en del af analysen. - selvom 'traceability' netop øges ved at bruge OO, er der grund til at sikre sig. Dette er en af de store fordele der skal nås med OO, af hensyn til den fremtidige systemforvaltning. Der er penge på spil i dette spørgsmål. 15. Check 'indkapsling'. Er den maksimal, således at alle attributter og metoder, der ikke er nødvendige at kende udenfor en klasse, heller ikke er det. - dette er også et af de centrale spørgsmål, som er vigtigt, fordi det er en af fordelene, der skal Side 19 af 24

20 opnås. Ved at få indkapslet en del af attributterne og operationerne, fås en nemmere forvaltning, og mindre omskrivning, når systemet ændres, eller der rettes en fejl. 16. Check hierarkiets dybde med hensyn til klasser og subklasser, og den dertil hørende nedarvning af attributter og operationer. Hvis der er mere end fem niveauer, skal det begrundes med solide brugsmæssige argumenter. - selvfølgelig kan det være rigtigt med et dybt hierarki. Men der kan også være sket det, at udviklerne er blevet teoretikere. Et tegn på det er store, smukt konstruerede hierarkier, med omfangsrige begrundelser for de enkelte niveauer af nedarvethed og videre delegering. De bør testes op imod virkelighedens verden. 17. Kan hver 'message' godkendes af brugerne. - de skal forekomme som udveksling af meddelelser mellem den virkelige verdens virkelige objekter. 18. Er 'multiple inheritance' nødvendig når den optræder, og er den håndteret korrekt. - selvom det kan give fordele, er det også en mulighed for at skabe kompleksitet. 10. Checkliste til overdragelsesreview Systemet er nu færdigudviklet og -testet. I overdragelsen krydses de punkter af, der skulle have været checket og godkendt før. De bliver det igen, men med en enkelt ny detalje: Testerne på reviewet er systemforvaltere, der godkender at systemet kan accepteres, til de kommende års aktive systemforvaltning. Spørgsmål: 1. Det forretningsmæssige Opfylder systemet de forretningsmæssige krav. Findes der en liste over udestående ændringsønsker, og hvad er status på de enkelte punkter. 2. Test Er der sat et mål for testens dækningsgrad. Er den ønskede dækningsgrad nået. Er den opnåede dækningsgrad dokumenteret. Eksisterer der et testmiljø til det nye system. Eksisterer der testdatabaser til systemet, med testklasser og -metoder. Er testen dokumenteret i form af testaktiviteter. Eksisterer der testcases til systemet. Er der udarbejdet en testdrejebog til system-/brugertest. 3. Kvalitetsstyring Er den gennemført. Er den dokumenteret. Er den godkendt som tilstrækkelig. Er der brugt kendte standarder for analyse, design og konstruktion. Er der brugt en kendt standard for dokumentationen. Side 20 af 24

Idékatalog Planlægning og brug af test i statslige it-projekter

Idékatalog Planlægning og brug af test i statslige it-projekter Idékatalog Planlægning og brug af test i statslige it-projekter Januar 2014 INDHOLD 1. INDLEDNING...1 2. TYPER AF TEST...2 3. PLANLÆGNING AF TEST I FASERNE...6 3.1 IDÉFASEN...6 3.2 ANALYSEFASEN...7 3.3

Læs mere

0-fejl udvikling. Appendiks til bogen Softwaretest

0-fejl udvikling. Appendiks til bogen Softwaretest 0-fejl udvikling Appendiks til bogen Softwaretest 0-fejl udvikling... 1 Appendiks til bogen Softwaretest... 1 1. Muligheder og forudsætninger... 2 2. Udgifter ved 0-fejl... 2 3. Indtægter ved 0-fejl...

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Maj 2015 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

DD110 - Detaljeret projektplan

DD110 - Detaljeret projektplan Version: 1.3 Status: Godkendt Godkender: Dokumenthistorik Version Dato Navn Status Bemærkninger 1.0 9-11-2007 Endelig Initiel version 1.1 22-11-2007 Godkendt 1.2 28-11-2007

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Januar 2014 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

High performance maksimér potentialet. En måling er bedre end 100 mavefornemmelser. Per Hartlev ph@whitebox.dk 30/9-2015

High performance maksimér potentialet. En måling er bedre end 100 mavefornemmelser. Per Hartlev ph@whitebox.dk 30/9-2015 High performance maksimér potentialet En måling er bedre end 100 mavefornemmelser Per Hartlev ph@whitebox.dk 30/9-2015 Release-styring Hjælpe værktøjer Kvalitets sikring Leverandør kontrakter Kurser Opgave

Læs mere

GPS stiller meget præcise krav til valg af målemetode

GPS stiller meget præcise krav til valg af målemetode GPS stiller meget præcise krav til valg af målemetode 1 Måleteknisk er vi på flere måder i en ny og ændret situation. Det er forhold, som påvirker betydningen af valget af målemetoder. - Der er en stadig

Læs mere

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK Mission Critical o Projekt Information management o Processer, metoder & værktøjer. Side 1 of 11 Projekt information Projekt information management inkluderer alle de processer, som er nødvendige for at

Læs mere

Region Midtjylland Proces for Change Management

Region Midtjylland Proces for Change Management Region Midtjylland Proces for Change Management Version 1.1 Forord Dette dokument beskriver RMIT s Change Management proces. Processen beskriver minimumskravene (need to have) for at få processen til at

Læs mere

Softwaretest. - også af "ikke testbar" software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco.

Softwaretest. - også af ikke testbar software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco. Softwaretest - også af "ikke testbar" software DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco.dk Hvorfor softwaretest? Software er sjældent fejlfri Test sikrer at softwaren

Læs mere

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING 2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING Baggrund Udgangspunktet er projekt 2, dvs. en blog om cupcakes, hvor målgruppe, afsender og modtager allerede er defineret. Du bliver nu bedt om at udvikle et

Læs mere

PED/15.10.2007 Auditorhåndbog for OTS Version 1

PED/15.10.2007 Auditorhåndbog for OTS Version 1 PED/15.10.2007 Auditorhåndbog for OTS Version 1 Side 1/10 Indhold 1. Forord 2. Hvad er audit? 3. Hvor ofte skal auditor gennemføre audit og med hvilken funktion? 4. Rollen som auditor 5. Planlægning Indkaldelse

Læs mere

PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER

PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER 1 INTRODUKTION 1.1 Formålet med Practitioner-eksamen er at give eksaminanden mulighed for at demonstrere forståelse af PRINCE2. Samtidig skal eksaminanden

Læs mere

Konference om Cloud Computing 18. maj 2011. Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD

Konference om Cloud Computing 18. maj 2011. Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD Konference om Cloud Computing 18. maj 2011 Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD POC, hvad er det? En søgning på internettet viser, at de fleste sites

Læs mere

Vejledning til. Sikkerhedskvalitetsstyringssystem for driftsledelse

Vejledning til. Sikkerhedskvalitetsstyringssystem for driftsledelse Vejledning til Sikkerhedskvalitetsstyringssystem for driftsledelse 1 Forord Sikkerhedskvalitetsstyringssystem for drift af elforsyningsanlæg (SKS-driftsledelse) indeholder anvisninger på kvalitetsstyringsaktiviteter

Læs mere

Rollebeskrivelser. Programroller ift. den fællesstatslige programmodel

Rollebeskrivelser. Programroller ift. den fællesstatslige programmodel Rollebeskrivelser Programroller ift. den fællesstatslige programmodel Indholdsfortegnelse Rollebeskrivelser... 1 1. Programprofiler... 3 1.1. Formand for programbestyrelse/programejer... 3 1.2. Programleder...

Læs mere

Proceduren Proceduren for en given vare eller varetype fastlægges ud fra:

Proceduren Proceduren for en given vare eller varetype fastlægges ud fra: Forudsætning for CE-mærkning En fabrikant kan først CE-mærke sit produkt og dermed få ret til frit at sælge byggevaren i alle EU-medlemsstater, når fabrikanten har dokumenteret, at varens egenskaber stemmer

Læs mere

IKT programmer for Facilities Management. Vejledning for førstegangskøbere: Præsentation & debat

IKT programmer for Facilities Management. Vejledning for førstegangskøbere: Præsentation & debat DFM Workshop 05.10.09 09 IKT programmer for Facilities Management Vejledning for førstegangskøbere: Præsentation & debat Vejledning til systemkøberen Hvorfor en vejledning? Opbygning, highlights og vigtige

Læs mere

Navit sp/f. Del A Gennemførelse

Navit sp/f. Del A Gennemførelse Den Internationale Kode for Sikker Drift af Skibe og Forebyggelse af Forurening (International Safety Management-koden (ISM-koden)) Med rettelser gældende pr. 1. juli 2010 Del A Gennemførelse 1. Generelt

Læs mere

CV Jakob Niemann. Resumé: Nøglekvalifikationer. Personlighed. Født: 24/02 1976

CV Jakob Niemann. Resumé: Nøglekvalifikationer. Personlighed. Født: 24/02 1976 Jakob Niemann IT Konsulent Født: 24/02 1976 Rosendalsgade 11, 2. TV. 2100 København Ø Tlf: +45 2859 9808 JakobNiemann@gmail.com Resumé: Test og Quality Manager med mere end 15 års IT erfaring. Har stor

Læs mere

Supermarkedsmodellen for design af brugergrænseflade

Supermarkedsmodellen for design af brugergrænseflade Supermarkedsmodellen for design af brugergrænseflade Denne note er skrevet frit efter Peter Huber, som på et kursus i Efteruddannelsescenteret fortalte om supermarkedsmodellen til design af brugergrænseflader.

Læs mere

A K A D E M I E T SVENDSEN & KJÆR. Målstyring Enkelt og effektivt. Ann Møller Svendsen

A K A D E M I E T SVENDSEN & KJÆR. Målstyring Enkelt og effektivt. Ann Møller Svendsen A K A D E M I E T SVENDSEN & KJÆR Målstyring Enkelt og effektivt Ann Møller Svendsen Forord I en verden, der til stadighed er i forandring, er det af afgørende betydning at have en klar vision, en præcis

Læs mere

Application Management Service

Application Management Service Application Management Service I dette Whitepaper vil vi beskrive nogle af vores erfaringer med Application Management. De fleste virksomheder har på et tidspunkt lavet, eller fået lavet, en mindre applikation,

Læs mere

Svendeprøve Projekt Tyveri alarm

Svendeprøve Projekt Tyveri alarm Svendeprøve Projekt Tyveri alarm Påbegyndt.: 8/2-1999 Afleveret.: 4/3-1999 Projektet er lavet af.: Kasper Kirkeby Brian Andersen Thomas Bojer Nielsen Søren Vang Jørgensen Indholds fortegnelse 1. INDLEDNING...3

Læs mere

2. Metode. 2.1 Interessentanalyse Interessenterne i projektet er vist i nedenstående figur: Aftalekalenderprojektet. Indledning

2. Metode. 2.1 Interessentanalyse Interessenterne i projektet er vist i nedenstående figur: Aftalekalenderprojektet. Indledning 2. Metode Indledning Projektet er udført med flg. faser: Foranalyse (uden iterationer) Analyse (udarbejdelse af kravspecifikation afsnit 9.1, herunder use case beskrivelser afsnit 9.2) Design af skærmbilleder

Læs mere

IT-projektledelse F2006. Opfølgning og kvalitetssikring

IT-projektledelse F2006. Opfølgning og kvalitetssikring IT-projektledelse F2006 Opfølgning og kvalitetssikring Hvorfor planlægge når projekter sjældent følger planen? Hvad er opfølgning? Hvad skal der følges op på? Levels of control checkpoint reports project

Læs mere

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning Rollebeskrivelser i den fællesstatslige programmodel - Vejledning August 2013 Indhold 1. LÆSEVEJLEDNING... 1 2. FORMAND FOR PROGRAMBESTYRELSEN (PROGRAMEJER)... 2 3. PROGRAMLEDER... 3 4. FORANDRINGSEJER...

Læs mere

FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014

FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014 FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014 LIDT OM MIG SELV Erfaring NIELS-HENRIK HANSEN 35+ års samlet IT erfaring 15+ år som test manager Certificeret Inspection Leader ISEB Foundation

Læs mere

Professionel Udvælgelse i byggeriet Skabeloner

Professionel Udvælgelse i byggeriet Skabeloner Professionel Udvælgelse i byggeriet Skabeloner Vejledning i anvendelsen af skabeloner til brug for udvælgelse, herunder prækvalifikation i byggeriet Marts 2013 Byggeriets Evaluerings Center SOLIDARISK

Læs mere

Bilag 18, Revisionsstandard og audit

Bilag 18, Revisionsstandard og audit Bilag 18, Revisionsstandard og audit Version Ændringer Dato 2.1 Ændret i - Punkt 1.1 - Krav 18.3 - Krav 18.5 - Krav 18.6 - Krav 18.9 - Krav 18.10 - Krav 18.11 - Krav 18.12 - Krav 18.14 - Krav 18.16 tilføjet

Læs mere

Kort og godt om test af arkiveringsversioner

Kort og godt om test af arkiveringsversioner Kort og godt om test af arkiveringsversioner Data og dokumenter fra den offentlige forvaltnings it-systemer, som skal bevares for eftertiden, skal afleveres til arkiv i form af arkiveringsversioner. Arkiveringsversioner

Læs mere

Nye testteknikker fra ISTQB - direkte fra hylderne. Ole Chr. Hansen

Nye testteknikker fra ISTQB - direkte fra hylderne. Ole Chr. Hansen Nye testteknikker fra ISTQB - direkte fra hylderne Ole Chr. Hansen TestExpo 29. Januar 2015 Præsentation Ole Chr. Hansen Managing Consultant Fellow SogetiLabs Global Innovation Team Blog - http://ochansen.blogspot.com

Læs mere

ETC sæt strøm til projektstyringen

ETC sæt strøm til projektstyringen ETC sæt strøm til projektstyringen Sådan får du succes med projektestimering Få styr på projekter og deadlines Denne publikation indeholder en gennemgang af den nye ETC-funktion i TimeLog Project. Med

Læs mere

Kvalitetshåndbog. for. Smedefirmaet. MOELApS

Kvalitetshåndbog. for. Smedefirmaet. MOELApS Kvalitetshåndbog for Smedefirmaet Stålkonstruktioner, Trapper, gelændere, porte, Låger, hegn, altaner, m.m. Veludført arbejde giver personlig tilfredsstillelse Side 1af 8 Udarb.:PH Godk.:LH Dato: 09-01-2013

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

Læs mere

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5 Databaser og SQL Introduktion til SQL Kap 1-5 1 Dagens gang Databaser Database begreber Mapning af klasser til relationel model Normalisering Opgaver til næste gang 2 Databasebegreber A database is a:

Læs mere

ISRS 4410 DK Assistance med regnskabsopstilling. ifølge dansk revisorlovgivning. ISRS 4410 DK Januar 2012

ISRS 4410 DK Assistance med regnskabsopstilling. ifølge dansk revisorlovgivning. ISRS 4410 DK Januar 2012 International Auditing and Assurance Standards Board Januar 2012 International Standard om beslægtede opgaver Assistance med regnskabsopstilling og yderligere krav ifølge dansk revisorlovgivning International

Læs mere

Effektiv søgning på web-steder

Effektiv søgning på web-steder Effektiv søgning på web-steder 7. maj 1998 Udarbejdet af DialogDesign ved Rolf Molich, Skovkrogen 3, 3660 Stenløse Indhold 1. Indledning 3 1.1. Model for søgning 3 2. Forskellige former for søgning 4 2.1.

Læs mere

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning Rollebeskrivelser i den fællesstatslige programmodel - Vejledning Januar 2014 Indhold 1. LÆSEVEJLEDNING... 1 2. FORMAND FOR PROGRAMBESTYRELSEN (PROGRAMEJER)... 2 3. PROGRAMLEDER... 3 4. FORANDRINGSEJER...

Læs mere

Pixibog business casen kort fortalt... 2. 1: Projektbasis... 3. 2: Leverancen... 4. 3: Milepæle og tidsplan... 6. 4: Ressourcer... 7. 5: Økonomi...

Pixibog business casen kort fortalt... 2. 1: Projektbasis... 3. 2: Leverancen... 4. 3: Milepæle og tidsplan... 6. 4: Ressourcer... 7. 5: Økonomi... Pixibog business casen kort fortalt... 2 1: Projektbasis... 3 1.1: Projektidentifikation...3 1.2: Projektansvarlige...3 2: Leverancen... 4 2.1: Mål og rammer...4 2.2: Fremgangsmåde...5 2.3: Risikoanalyse

Læs mere

Håndbog til projektledelse

Håndbog til projektledelse Mere info kontakt Julie Kirstine Olsen Udviklingskonsulent juols@ikast-brande.dk Tlf.: 9960 4153 Mads Ballegaard Konsulent mabal@ikast-brande.dk Tlf.: 9960 4021 Produceret af Håndbog til projektledelse

Læs mere

Forberedelse og planlægning af GMP Audit

Forberedelse og planlægning af GMP Audit Forberedelse og planlægning af GMP Audit Juli, 2014 Indledning I de kommende sider får du nogle hurtige tips og råd til din forberedelse og planlægning af en GMP audit. Dette er ikke en komplet og grundig

Læs mere

Styregruppeformænd i SKAT Kort & godt (plastkort)

Styregruppeformænd i SKAT Kort & godt (plastkort) Håndbogen for Styregruppeformænd i SKAT Kort & godt (plastkort) 80% af alle projekter, hvor der er uigennemskuelighed fejler Lange projekter er mere risikofyldte end korte Transparente projekter har oftere

Læs mere

Tjeklisten for bedre indtjening

Tjeklisten for bedre indtjening Tak fordi du har downloadet Den ultimative tjekliste for bedre indtjening. Manglende indtjening hænger ofte sammen med, at der er ting i dit workflow, du kan forbedre. En tjekliste er uvurderlig, for den

Læs mere

UC Effektiviseringsprogrammet. Projektgrundlag. Fælles UC Videoplatform 08-05-2014

UC Effektiviseringsprogrammet. Projektgrundlag. Fælles UC Videoplatform 08-05-2014 UC Effektiviseringsprogrammet Projektgrundlag Fælles UC Videoplatform 08-05-2014 Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen Produkt: Projektgrundlag, ver. 27/8-2013 1 Stamdata Stamdata

Læs mere

Gennemsnit og normalfordeling illustreret med terningkast, simulering og SLUMP()

Gennemsnit og normalfordeling illustreret med terningkast, simulering og SLUMP() Gennemsnit og normalfordeling illustreret med terningkast, simulering og SLUMP() John Andersen, Læreruddannelsen i Aarhus, VIA Et kast med 10 terninger gav følgende udfald Fig. 1 Result of rolling 10 dices

Læs mere

uddybende beskrivelse af processen i forbindelse med fremsøgning af sagsakter?

uddybende beskrivelse af processen i forbindelse med fremsøgning af sagsakter? UDBUD AF BYGGESAGSSYSTEM OFFENTLIGT UDBUD, OFFENTLIGGJORT DEN 3. JULI 2015. SPØRGSMÅL OG SVAR NR. 1 (17/08/2015) NR. 1. 2. REFERENCE SPØRGSMÅL SVAR Bilag 1. Krav 9 Bilag 1. Krav 17 Er det muligt at få

Læs mere

Bilag 9, Kvalitetssikring

Bilag 9, Kvalitetssikring Bilag 9, Kvalitetssikring Version Ændringer Dato 2.1 Ændret i: 06-02-2014 - Punkt 1 - Punkt 2 - Krav 9.1 - Krav 9.2 - Krav 9.3 - Krav 9.5 - Krav 9.6 - Krav 9.7 - Krav 9.8 - Tilføjet krav 9.14 - Tilføjet

Læs mere

Brugervejledning til Landsbyggefondens regnskabsindberetningssystem

Brugervejledning til Landsbyggefondens regnskabsindberetningssystem LANDSBYGGEFONDEN 11. marts 2015 Brugervejledning til Landsbyggefondens regnskabsindberetningssystem (for boligorganisationer og selvejende institutioner) 2. udgave Indholdsfortegnelse 1. I 1 NDLEDNING...

Læs mere

--> Året der gik --> Opgaver og udvikling --> Trivsel og samarbejde -->

--> Året der gik --> Opgaver og udvikling --> Trivsel og samarbejde --> Hvad er MUS? En systematisk, periodisk, planlagt og velforberedt dialog mellem en medarbejder og den leder, som medarbejderen refererer til MUS er en samtale om mål og muligheder Formålet er at medarbejderens

Læs mere

Spillemyndighedens certificeringsprogram Program for styring af systemændringer

Spillemyndighedens certificeringsprogram Program for styring af systemændringer SCP.06.00.DK.1.0 Indhold Indhold... 2 1 Formålet med program for styring af systemændringer... 3 1.1 Overblik over dette dokument... 3 1.2 Version... 3 2 Certificering... 4 2.1 Certificeringsfrekvens...

Læs mere

Datamodeller. 1. Elementerne. Vi betragter E/R-diagrammet, som et diagram over entiteter og relationer Tegneregler: Entitet

Datamodeller. 1. Elementerne. Vi betragter E/R-diagrammet, som et diagram over entiteter og relationer Tegneregler: Entitet Datamodeller I forlængelse af noten om normalisering, følges der her op med redskabet E/R-diagrammer til opstilling af en datamodel, opfat således dette som en alternativ metode mere end endnu et redskab

Læs mere

Titel Nr. Udgave dato. Udarb. af Godkendt af Gyldighed Erstatter nr. Udgave dato. Gældende

Titel Nr. Udgave dato. Udarb. af Godkendt af Gyldighed Erstatter nr. Udgave dato. Gældende Formål Formålet med kvalitetsstyring er overordnet, at der skabes en forbedringskultur, der kan beskrives som en systematisk, fortløbende proces i 4 dele: Planlægning af opgaveløsning (procedurer) Opgaveløsning

Læs mere

Projektstyring. Dag 3

Projektstyring. Dag 3 Akademifaget Projektstyring Dag 3 m/u PRINCE2 Foundation certificering i samarbejde med PRINCE2 is a registered trade mark of the Cabinet Office 1 Analyse Projektmandat Mål delmål Produktbaseret planlægning

Læs mere

Projekt - Visual Basic for Applications N på stribe

Projekt - Visual Basic for Applications N på stribe Projekt - Visual Basic for Applications N på stribe Mikkel Kaas og Troels Henriksen - 03x 3. november 2005 1 Introduktion Spillet tager udgangspunkt i det gamle kendte 4 på stribe, dog med den ændring,

Læs mere

ADM - P.2.3.130 - Analyserapport og ledelsens evaluering - 2013, ver. 1.3C

ADM - P.2.3.130 - Analyserapport og ledelsens evaluering - 2013, ver. 1.3C Side 1 af 6 Udskrevet er dokumentet ikke dokumentstyret. Analyserapport og ledelsens evaluering - 2013 Niveau: Niveau 2 Dokumentbrugere: KS-chef, Led, SysAns Øvrige: Redaktør: jba Fagansvarlig SysAns Dokumentnummer:

Læs mere

Strategi 2013-2017 Danmarks Miljøportal

Strategi 2013-2017 Danmarks Miljøportal Strategi 2013-2017 Danmarks Miljøportal Introduktion Danmarks Miljøportal (DMP) har ansvaret for en digital infrastruktur på miljøområdet, der gør det muligt for myndigheder og offentlighed at få nem adgang

Læs mere

Business case. for. implementering af InCare på plejecenter med 40 beboere

Business case. for. implementering af InCare på plejecenter med 40 beboere Dato: 2012 J.nr.: xx Business case for implementering af InCare på plejecenter med 40 beboere Version: 3.2 2/11 Indholdsfortegnelse 1. Ledelsesresume... 3 2. Løsningsbeskrivelse... 4 Projektets navn eller

Læs mere

Bilag 1 Tidsplan Version 0.9 05-05-2014 0

Bilag 1 Tidsplan Version 0.9 05-05-2014 0 Bilag 1 Tidsplan Version 0.9 05-05-2014 0 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 2.1 ETAPER I UDVIKLINGSPROJEKTET... 3 2.1.1 ETAPE I - AFKLARING... 3 2.1.2 ETAPE II ANALYSE, DESIGN,

Læs mere

Evaluering af Satspuljeprojektet Børne-familiesagkyndige til støtte for børn i familier med alkoholproblemer

Evaluering af Satspuljeprojektet Børne-familiesagkyndige til støtte for børn i familier med alkoholproblemer Sundhedsstyrelsen Evaluering af Satspuljeprojektet Børne-familiesagkyndige til støtte for børn i familier med alkoholproblemer Konklusion og anbefalinger September 2009 Sundhedsstyrelsen Evaluering af

Læs mere

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt Scope Management ITU 11-09-2013 @janhmadsen Dagsorden Oplægsholder Projektstyring Scope Management i en fælles kontekst Definitioner Scope Management - styring af omfang ved projektets start under projektets

Læs mere

strategi drejer sig om at udvælge de midler, processer og de handlinger, der gør det muligt at nå det kommunikationsmæssige mål. 2

strategi drejer sig om at udvælge de midler, processer og de handlinger, der gør det muligt at nå det kommunikationsmæssige mål. 2 KOMMUNIKATIONSSTRATEGIENS TEORETISKE FUNDAMENT I den litteratur, jeg har haft adgang til under tilblivelsen af denne publikation, har jeg ikke fundet nogen entydig definition på, hvad en kommunikationsstrategi

Læs mere

Spørgeskemaer. Øjvind Lidegaard Gynækologisk klinik Rigshospitalet

Spørgeskemaer. Øjvind Lidegaard Gynækologisk klinik Rigshospitalet Spørgeskemaer Øjvind Lidegaard Gynækologisk klinik Rigshospitalet Spørgeskemaer Hvornår er spørgeskemaer relevante? Forberedelse til spørgeskemaer Udformning af spørgeskemaer Udformning af spørgsmål Validitet

Læs mere

Foranalyse for edagsordensprojekt og devices

Foranalyse for edagsordensprojekt og devices Foranalyse for edagsordensprojekt og devices Udarbejdet af Jesper Rønnov og Morten Hougaard Sidst revideret d. 13/01/11 Sammenfatning af foranalysen... 2 Mulige veje frem for projektet... 2 A. Fujitsu

Læs mere

Eleven kan handle med overblik i sammensatte situationer med matematik. Eleven kan anvende rationale tal og variable i beskrivelser og beregninger

Eleven kan handle med overblik i sammensatte situationer med matematik. Eleven kan anvende rationale tal og variable i beskrivelser og beregninger Kompetenceområde Efter klassetrin Efter 6. klassetrin Efter 9. klassetrin Matematiske kompetencer handle hensigtsmæssigt i situationer med handle med overblik i sammensatte situationer med handle med dømmekraft

Læs mere

Punkter som ikke synes relevante for det givne projekt besvares med: ikke relevant

Punkter som ikke synes relevante for det givne projekt besvares med: ikke relevant Modtagelseserklæring Modtagelseserklæring for AAU ITS Infrastruktur version 4. Anvendelse Modtagelseserklæringen skal anvendes i forbindelse med projekter drevet af PMO, AIU eller IFS. Projektlederen er

Læs mere

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2 UC Effektiviseringsprogrammet Projektgrundlag Business Intelligence version 1.2 9. september 2014 1 Stamdata Stamdata Projektnavn (forventet): Projektejer: Projekttype: Business Intelligence It-chef Hans-Henrik

Læs mere

Ringkøbing-Skjern Kommune. Informationssikkerhedspolitik

Ringkøbing-Skjern Kommune. Informationssikkerhedspolitik Ringkøbing-Skjern Kommune Informationssikkerhedspolitik Indholdsfortegnelse Indholdsfortegnelse... 1 1. Indledning... 2 2. Formål... 2 3. Holdninger og principper... 3 4. Omfang... 3 5. Sikkerhedsniveau...

Læs mere

Projektlederens guide til tilfredsstillende geoinformationsprodukter

Projektlederens guide til tilfredsstillende geoinformationsprodukter Projektlederens guide til tilfredsstillende geoinformationsprodukter Projektlederens guide er udarbejdet på baggrund af projektet: MobilGIS til natur- og arealforvaltere en web-baseret prototype. Projektet

Læs mere

IT-SIKKERHEDSPOLITIK UDKAST

IT-SIKKERHEDSPOLITIK UDKAST IT-SIKKERHEDSPOLITIK UDKAST It-sikkerhedspolitikken tilstræber at understøtte Odsherred Kommunes overordnede vision. It- og øvrig teknologianvendelse, er et af direktionens redskaber til at realisere kommunens

Læs mere

Mandag: HVAD ER ET PROJEKT?

Mandag: HVAD ER ET PROJEKT? Mandag: HVAD ER ET PROJEKT? Hvorforhar vi projekter? Resultater! Fokus på en opgave der ikke er mulig i linjeorganisationen Arbejde på tværs af en organisation Afgrænsning af styringsområde Bedre styring

Læs mere

Tirsdag: PROJEKTLEDELSE OG -ARBEJDE

Tirsdag: PROJEKTLEDELSE OG -ARBEJDE Tirsdag: PROJEKTLEDELSE OG -ARBEJDE Hvad Er det en god har idé? vi lært? (CBA/BC) Hvad har vi lavet? (projektevaluering) Hvornår har vi et projekt? (projektgeografi) Hvad skal vi levere? (produktmål) Interessentanalyse

Læs mere

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England.

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England. Cookievejledningens Tekniske Guide Den tekniske guide beskriver fem skridt til overholdelse af cookiereglerne: 1. Fastlæggelse af webejendom 2. Undersøgelse af om der sættes cookies på hjemmesiden 3. Afgivelse

Læs mere

Baggrundsnote om logiske operatorer

Baggrundsnote om logiske operatorer Baggrundsnote om logiske operatorer Man kan regne på udsagn ligesom man kan regne på tal. Regneoperationerne kaldes da logiske operatorer. De tre vigtigste logiske operatorer er NOT, AND og. Den første

Læs mere

ER-modellen. Databaser, efterår 2002. Troels Andreasen. Efterår 2002

ER-modellen. Databaser, efterår 2002. Troels Andreasen. Efterår 2002 Databaser, efterår 2002 ER-modellen Troels Andreasen Datalogiafdelingen, hus 42.1 Roskilde Universitetscenter Universitetsvej 1 Postboks 260 4000 Roskilde Telefon: 4674 2000 Fax: 4674 3072 www.dat.ruc.dk

Læs mere

Journalmodulet er udviklet specifikt til psykologer med stor fokus på sikkerhed. Journalen indeholder bl.a.:

Journalmodulet er udviklet specifikt til psykologer med stor fokus på sikkerhed. Journalen indeholder bl.a.: ClinicCare Web Produktblad 2012 Psykologjournal ClinicCare/ Novolog ClinicCare udvikles af firmaet Novolog, som siden 1995 har udviklet systemer til sundheds-sektoren. Indhold Journalmodulets opbygning

Læs mere

Metoden er meget anvendt i praksis, og er særdeles velegnet, hvis du ønsker at undersøge holdninger hos et større antal af mennesker.

Metoden er meget anvendt i praksis, og er særdeles velegnet, hvis du ønsker at undersøge holdninger hos et større antal af mennesker. Spørgeskemaer Metoden er meget anvendt i praksis, og er særdeles velegnet, hvis du ønsker at undersøge holdninger hos et større antal af mennesker. Hvad er et spørgeskema? Et spørgeskema består i sin bredeste

Læs mere

Overdragelse til itdriftsorganisationen

Overdragelse til itdriftsorganisationen Overdragelse til itdriftsorganisationen Indhold 1. Formål med tjeklisten 3 2. Tjeklisten 5 2.1 Governance 5 2.2 Processer 5 2.3 Support af slutbrugere 6 2.4 Viden og dokumentation 8 2.5 Kontrakt, leverandørsamarbejde

Læs mere

App-strategi for Randers Kommune December 2012. Bilag 2: Procesvejledning for app-udvikling i Randers Kommune

App-strategi for Randers Kommune December 2012. Bilag 2: Procesvejledning for app-udvikling i Randers Kommune Bilag 2: Procesvejledning for app-udvikling i Randers Kommune Procesvejledningen har til formål, at skabe overblik over app-udviklingsprocessen, og skal sikre kvalitet og genkendelighed blandt apps ene

Læs mere

Projekt DAF. Digitale annonceordrer og fakturaer Funktionel kravspecifikation Infrastruktur

Projekt DAF. Digitale annonceordrer og fakturaer Funktionel kravspecifikation Infrastruktur IT & Operational Developement Projekt DAF Digitale annonceordrer og fakturaer Funktionel kravspecifikation Infrastruktur Politiken Jyllandsposten Berlingske Tidende OMD Carat Mediaedge:CIA Mediacom Initiative

Læs mere

Guide til kravspecifikation

Guide til kravspecifikation Side 1 af 10 10. november 2008 Guide til kravspecifikation Version 1.0. Denne guide indeholder en række råd til brug i kravspecifikationer for IT systemer, der skal anvende NemLog-in løsningen. Hensigten

Læs mere

"SAP" betyder det SAP-selskab, med hvem du indgik kontrakt om tjenesten.

SAP betyder det SAP-selskab, med hvem du indgik kontrakt om tjenesten. Serviceaftaleprogram for Ariba Cloud Services Garanti for Tjenestens tilgængelighed Sikkerhed Diverse 1. Garanti for Tjenestens tilgængelighed a. Anvendelighed. Garantien for tjenestens tilgængelighed

Læs mere

Kom godt i gang - vejledning i brug af Do-Best Lager og logistik - kvalitetsstyret flow

Kom godt i gang - vejledning i brug af Do-Best Lager og logistik - kvalitetsstyret flow INDLEDNING:... 2 DO-BEST SKAL SKABE NY VIDEN... FEJL! BOGMÆRKE ER IKKE DEFINERET. FORSIDE:... 4 BRUG AF BRUGERKODE... 5 BRUG AF MENUER OG UNDERMENUER... 5 LÆREBOG:... 5 LÆREBOG, LAGER OG LOGISTIK... 6

Læs mere

Taldata 1. Chancer gennem eksperimenter

Taldata 1. Chancer gennem eksperimenter Taldata 1. Chancer gennem eksperimenter Indhold 1. Kast med to terninger 2. Et pindediagram 3. Sumtabel 4. Median og kvartiler 5. Et trappediagram 6. Gennemsnit 7. En statistik 8. Anvendelse af edb 9.

Læs mere

Virksomhedens salgspipeline. Business Danmark november 2009 BD272

Virksomhedens salgspipeline. Business Danmark november 2009 BD272 Virksomhedens salgspipeline Business Danmark november 2009 BD272 Indholdsfortegnelse Indledning... 2 Rapportens opbygning... 2 Hovedkonklusioner... 3 Metode og validitet... 3 Salgs- og marketingafdelingernes

Læs mere

Microsoft Dynamics AX Scanfak. Fall

Microsoft Dynamics AX Scanfak. Fall 1 Microsoft Dynamics AX Scanfak Fall 16 - faktura management & workflow Med faktura management & workflow systemet Scanfak fra GITS kan du afhjælpe de tunge administrative rutiner ved håndtering af kreditor

Læs mere

Administrator v1.0 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk

Administrator v1.0 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk Administrator v1.0 QUICK GUIDE Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk INTRODUKTION TIL REKVI-KONTOR Ideen med Rekvi-Kontor systemet udsprang

Læs mere

Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer

Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer INDLÆG 13 : DYNAMICS AX Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer Tonny Bybæk, Lau Bøgelund Larsen Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer

Læs mere

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase Indholdsfortegnelse 5. Administrationsdatabase... 2 5.1 Metadata... 2 5.2 Administrationsdata... 3 5.2.1 Indstillingsmuligheder... 3 5.2.2 Webside... 4 5.2.3 Klikafgift (Udgået)... 4 5.2.4 Modtageboks...

Læs mere

Fælles regionale principper for. systematisk læring af patientklager

Fælles regionale principper for. systematisk læring af patientklager Fælles regionale principper for systematisk læring af patientklager Fælles regionale principper for systematisk læring af patientklager Læring af patientklager handler om at lytte, agere og forbedre. Formålet

Læs mere

Spørgeskema til evaluering af virksomhedens modenhed

Spørgeskema til evaluering af virksomhedens modenhed Spørgeskema til evaluering af virksomhedens modenhed Med fokus på øget vækst og større konkurrencekraft FORMÅL: Dette spørgeskema har til hensigt at identificere virksomhedens modenhed indenfor vigtige

Læs mere

Innovationens Syv Cirkler

Innovationens Syv Cirkler Innovationens Syv Cirkler Med denne gennemgang får du en kort introduktion af Innovationens Syv Cirkler, en model for innovationsledelse. Dette er en beskrivelse af hvilke elementer der er betydende for

Læs mere

IT-strategi og ROI baseret på IT

IT-strategi og ROI baseret på IT IT-strategi og ROI baseret på IT Indhold Udarbejdelse af en IT-strategi Udarbejdelse af en ROI-case til ledelsen (business case) Praktisk eksempel på Case forløb 10-05-2012 EG Copyright 2 Faser i udarbejdelse

Læs mere

Daglig brug af JitBesked 2.0

Daglig brug af JitBesked 2.0 Daglig brug af JitBesked 2.0 Indholdsfortegnelse Oprettelse af personer (modtagere)...3 Afsendelse af besked...4 Valg af flere modtagere...5 Valg af flere personer der ligger i rækkefølge...5 Valg af flere

Læs mere

Kommentar fra KMS til Specifikation af Serviceinterface for Person

Kommentar fra KMS til Specifikation af Serviceinterface for Person Kommentar fra KMS til Specifikation af Serviceinterface for Person Organisation Side Kapitel Afsnit/figur/tabel /note Type af kommentar (generel (G), redaktionel (R), teknisk (T)) Kommentar KMS-1 G Godt

Læs mere

VISMA DOCUMENTCENTER Kompetansedag ed e ag ne 2011

VISMA DOCUMENTCENTER Kompetansedag ed e ag ne 2011 VISMA DOCUMENTCENTER Agenda Maventa Hvordan påvirker det Visma Document Center? Status Nyhedsoversigt Konvertering Eksternt arkiv Gennemgang af ny funktionalitet Hvad kommer? Frem mod næste version Page

Læs mere

Ud af krisen. Software på tværs, 15. juni 2009

Ud af krisen. Software på tværs, 15. juni 2009 Ud af krisen Software på tværs, 15. juni 2009 Om Ative Agile udvikling og rådgivning Klassisk udviklingsmodel Krav Design Ændrer sig Implementering Tager for lang tid Springes over Mareridt Test Deployment

Læs mere

E2E Teststrategi Engrosmodellen

E2E Teststrategi Engrosmodellen E2E Teststrategi Engrosmodellen Et overblik over metode og proces Ver. 1.00 FRE August 2013 1 Kort om: End to End (E2E) Test Generelt om End-to-End (E2E) Test Formålet med at gennemføre en E2E test er

Læs mere

TILFREDSHEDSUNDERSØGELSE

TILFREDSHEDSUNDERSØGELSE TILFREDSHEDSUNDERSØGELSE Parkering Danmark Postboks 301 1502 København V Tlf. 31148908 Mail: info@parkeringdanmark.dk Side 1 af 18 Kontortid: Mandag - Torsdag 14-16 Indhold Tilfredshedsanalyse... 3 Analysens

Læs mere

Demo rapport. Rapporten genereret den: 8-10-2011 Powered by. Demo rapport - 1 / 42

Demo rapport. Rapporten genereret den: 8-10-2011 Powered by. Demo rapport - 1 / 42 Demo rapport Rapporten genereret den: 8-10-2011 Powered by Demo rapport - 1 / 42 Få udbytte af din feedback Det er almindelig kendt at arbejdsglæde og høj performance ofte er sammenhængende. UdviklingsKompas

Læs mere