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

Underbilag 14 C: Afprøvningsforskrifter til prøver og tests

Underbilag 14 C: Afprøvningsforskrifter til prøver og tests Underbilag 14 C: Afprøvningsforskrifter til prøver tests Udbud om levering, installation, implementering, support, drift vedligehold af Borgeradministrativt System (BAS) Indhold underbilag 14 C Afprøvningsforskrifter

Læs mere

Holdninger. Appendiks til bogen Struktureret Test

Holdninger. Appendiks til bogen Struktureret Test Holdninger Appendiks til bogen Struktureret Test Holdninger... 1 Appendiks til bogen Struktureret Test... 1 1. Holdningers betydning... 2 2. Holdninger generelt, der fremmer test... 2 3. De enkelte aktører...

Læs mere

Struktureret Test og Værktøjer Appendiks til bogen Struktureret Test

Struktureret Test og Værktøjer Appendiks til bogen Struktureret Test Struktureret Test og Værktøjer Appendiks til bogen Struktureret Test Struktureret Test og Værktøjer... 1 Appendiks til bogen Struktureret Test... 1 1. Definition og formål... 2 2. Kategorisering... 2 2.1

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

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

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

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

Om fejl. Appendiks til bogen Struktureret Test

Om fejl. Appendiks til bogen Struktureret Test Om fejl Appendiks til bogen Struktureret Test Om fejl... 1 Appendiks til bogen Struktureret Test... 1 1. Hvad er den rigtige fejl?... 2 2. Hvornår er en fejl alvorlig?... 2 3. Taksten på reparation af

Læs mere

Bilag 14 Prøver INSTRUKTION TIL TILBUDSGIVER:

Bilag 14 Prøver INSTRUKTION TIL TILBUDSGIVER: Bilag 14 Prøver INSTRUKTION TIL TILBUDSGIVER: Bilag 14 skal udfyldes af tilbudsgiver som del af tilbuddet. Udfyldelse skal ske i overensstemmelse med nedenstående retningslinjer. 2 14. INDLEDNING... 3

Læs mere

5.1.2 Kan IO identificeres i organisati- onen?

5.1.2 Kan IO identificeres i organisati- onen? Rød: Udgår af 17020 Gul: Ændringer og tilføjelser i 17020:2012 ISO 17020:2005, ISO 17020:2012 3 Administrative krav 5 Krav til opbygning 5.1 Administrative krav 3.1 Juridisk identificerbar afd. 5.1.1 Juridisk

Læs mere

Bias Reducing Operating System - BROS -

Bias Reducing Operating System - BROS - Bias Reducing Operating System - BROS - Accepttestspecifikation Projektgruppe 3: Rasmus Lund Jensen (11111) Nicolai Glud(11102) Jacob Roesen(10095) Mick Holmark(11065) Johnny Kristensen(10734) 1 Versionshistorik

Læs mere

Indhold. Forord... 11

Indhold. Forord... 11 Indhold Forord................................................ 11 1 Indledning.......................................... 13 1.1 Definitioner........................................ 15 1.2 Formålet med

Læs mere

Prøverne gennemføres som henholdsvis en Idriftsættelsesprøve, en Driftovertagelsesprøve og en. Prøve Delprøve Delprøve

Prøverne gennemføres som henholdsvis en Idriftsættelsesprøve, en Driftovertagelsesprøve og en. Prøve Delprøve Delprøve Bilag 12 Afprøvning Side 1 af 9 Bilag 12 Afprøvning I forbindelse med etablering af EPJ skal der gennemføres kvalitetsstyringsaktiviteter jf. bilag 10, herunder afprøvning og evaluering af den samlede

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

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

Underbilag 14 B: Oversigt over prøve- og testtyper. Udbud om levering, installation, implementering, support, drift og vedligehold af BAS

Underbilag 14 B: Oversigt over prøve- og testtyper. Udbud om levering, installation, implementering, support, drift og vedligehold af BAS Underbilag 14 B: Oversigt over prøve- og testtyper Udbud om levering, installation, implementering, support, drift og vedligehold af BAS Indhold underbilag 14 B Oversigt over prøve- og testtyper 14 B Oversigt

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

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

1. projektbesøg - inspirationsslides

1. projektbesøg - inspirationsslides 1. projektbesøg - inspirationsslides Ung og sund: Sundhedsfremmende initiativer for unge uden for eller på vej ud af uddannelsessystemet 1 Formål med projektbesøget Sikre klarhed og sammenhæng omkring

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

10 gode råd. Vælg den rette model. af konsulent Morten Korsaa, DELTA

10 gode råd. Vælg den rette model. af konsulent Morten Korsaa, DELTA 10 gode råd af konsulent Morten Korsaa, DELTA Vælg den rette model SKI rammekontrakten giver mulighed for at bruge to udviklingsmodeller den klassiske og den nye. Dit valg er afgørende for succes. Den

Læs mere

Tilfredshedsundersøgelse 2015

Tilfredshedsundersøgelse 2015 Spørgsmål 6 Tilfredshedsundersøgelse 25 I tabellen vises gennemsnittet af besvarelserne. Parenteserne viser sidste års resultat. = Laveste tilfredshed = Højeste tilfredshed ØVRIGE BRUGERE SUPERBRUGE RE

Læs mere

Udbud af Telemedicinsk løsning til hjemmemonitorering. Bilag 14 - Prøver

Udbud af Telemedicinsk løsning til hjemmemonitorering. Bilag 14 - Prøver Udbud af Telemedicinsk løsning til hjemmemonitorering Bilag 14 - Prøver 2 Indholdsfortegnelse 14. Prøver 4 14.1 Indledning 4 14.2 Afprøvningsprogram 5 14.2.1 Generelle krav til afprøvningsprogrammet 5

Læs mere

Mangelfuldt dokumenterede it-systemer. Hvordan løses udfordringen?

Mangelfuldt dokumenterede it-systemer. Hvordan løses udfordringen? Mangelfuldt dokumenterede it-systemer Hvordan løses udfordringen? Indholdsfortegnelse 1. Resume... 3 2. Introduktion... 3 3. Fordelene ved at løse udfordringen... 3 4. Løsningen... 4 4.1 Hvordan?... 4

Læs mere

BUSINESS CASE I AP PENSION 7. JUNI 2013

BUSINESS CASE I AP PENSION 7. JUNI 2013 1 BUSINESS CASE I AP PENSION 7. JUNI 2013 OM AP PENSION Etableret i 1919 Fokus på livs- og pensionsforsikring Kundeejet, selvstændig og uafhængig 240 medarbejdere Aktiver ca. 85 mia. kr. i 2012 Indbetalinger

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

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

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

Risikoen for en helbredsskade er en kombination af, hvor alvorlig helbredsskade der er fare for, og sandsynligheden for at den indtræffer.

Risikoen for en helbredsskade er en kombination af, hvor alvorlig helbredsskade der er fare for, og sandsynligheden for at den indtræffer. 13-12-2010 14:11 Arbejdspladsvurdering Procedure Definitioner Arbejdspladsvurdering (APV) er en systematisk vurdering af arbejdsmiljøet med henblik på at identificere og fjerne, reducere eller informere

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

Infoblad. ISO/TS 16949 - Automotive

Infoblad. ISO/TS 16949 - Automotive Side 1 af 5 ISO/TS 16949 - Automotive Standarden ISO/TS 16949 indeholder særlige krav gældende for bilindustrien og for relevante reservedelsvirksomheder. Standardens struktur er opbygget som strukturen

Læs mere

Audit beskrivelser for PL

Audit beskrivelser for PL 3-4-1 V01 3-4-1 V02 3-4-1 V03 3-4-1 V04 3-4-1 V05 Er der etableret et system til regelmæssig kontrol af processerne? Punktet er opfyldt, hvis der er en synlig regelmæssig måling for processen med acceptgrænser.

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

Testprocesser og målinger i test. Jesper Schultz, Nykredit 19. november 2009

Testprocesser og målinger i test. Jesper Schultz, Nykredit 19. november 2009 Testprocesser og målinger i test Jesper Schultz, Nykredit 19. november 2009 Agenda TMM måling og vores arbejde med at måle kvaliteten af den test der køres i projekter i Nykredit TMMi 2009 Baggrund Resultater

Læs mere

Kom godt i gang - vejledning i brug af Do-Best Fleksible endoskoper - kvalitetsstyret flow

Kom godt i gang - vejledning i brug af Do-Best Fleksible endoskoper - kvalitetsstyret flow INDLEDNING:... 2 DO-BEST SKAL SKABE NY VIDEN... 2 FORSIDE:... 4 BRUG AF BRUGERKODE... 5 BRUG AF MENUER OG UNDERMENUER... 5 LÆREBOG:... 5 LÆREBOG, FLEKSIBLE ENDOSKOPER... 6 FORTRYDEKNAP/RETURTAST... 6 ORDBOG....

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

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

Bilag 1: Business Case. Jordbase ved Serena Sørensen. Bilag 2.4.a - PID for Jordbase (Bilag 1 Business Case) Bestyrelsesmøde den 16.

Bilag 1: Business Case. Jordbase ved Serena Sørensen. Bilag 2.4.a - PID for Jordbase (Bilag 1 Business Case) Bestyrelsesmøde den 16. Bilag 2.4.a - PID for Jordbase (Bilag 1 Business Case) Bestyrelsesmøde den 16. marts 2015 Bilag 1: Business Case Jordbase ved Serena Sørensen Side 1 af 7 Indholdsfortegnelse 1. Introduktion... 4 2. Forvente

Læs mere

Udfasning KMD Sygedagpenge. Svarbilag. 13. marts 2013, version 1.3. Side 1/17

Udfasning KMD Sygedagpenge. Svarbilag. 13. marts 2013, version 1.3. Side 1/17 Udfasning KMD Sygedagpenge Svarbilag 13. marts 2013, version 1.3 Side 1/17 Indhold 1 INDLEDNING... 3 2 BESVARELSE KRAV OG TILBUDSPROCES... 4 3 BESVARELSE RAMMERNE FOR UDFASNINGEN... 4 3.1 UDFASNINGSSCENARIE

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

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

Handlingsanvisning. Indskriv i kontrakterne at der forventes brug af Ajour, samt i hvilket omfang.

Handlingsanvisning. Indskriv i kontrakterne at der forventes brug af Ajour, samt i hvilket omfang. Bygherre Kontrakter Projektgennemgang Er bygherre interesseret i digital aflevering? Få afklaret hvad forventningerne er til omfanget af kvalitetssikringen. Det kan være en fordel at aflevere digitalt

Læs mere

Entreprenøren skal følge et kvalitetsstyringssystem, som lever op til de i dette bilag anførte krav.

Entreprenøren skal følge et kvalitetsstyringssystem, som lever op til de i dette bilag anførte krav. 1 Bilag 1 Kvalitetsstyring. 1. Indledning. Generelt Entreprenøren skal følge et kvalitetsstyringssystem, som lever op til de i dette bilag anførte krav. Entreprenøren skal indenfor rammerne af sit kvalitetsstyringssystem

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

Vurdering af kvalitet en note af Tove Zöga Larsen

Vurdering af kvalitet en note af Tove Zöga Larsen Vurdering af kvalitet en note af Tove Zöga Larsen Kvalitet... 2 Test... 2 Hvordan finder man testdata?... 2 Dokumentation af test... 3 Review... 3 Vurderingskriterier... 3 Gennemførelsen af et review...

Læs mere

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

ER-modellen. Databaser, efterår 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

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning: Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor

Læs mere

[A20] Kick off document and process description. 1 of 5

[A20] Kick off document and process description. 1 of 5 [A20] Kick off document and process description 1 of 5 kick off document Huge Lawn Projekt Kick-Off Alle projekter og ideer er forskellige. For at vi kan give et reelt bud på dit/jeres projekt eller idé

Læs mere

Copyright 2010 Netcompany A/S. Alle rettigheder forbeholdes.

Copyright 2010 Netcompany A/S. Alle rettigheder forbeholdes. Version: 1. Status: Godkendt Godkender: Niels. Alle rettigheder forbeholdes. Elektronisk, mekanisk, fotografisk eller anden gengivelse, oversættelse eller kopiering af dette dokument

Læs mere

Denne publikation er udarbejdet af Digitaliseringsstyrelsen Landgreven 4 Postboks København K Telefon dk

Denne publikation er udarbejdet af Digitaliseringsstyrelsen Landgreven 4 Postboks København K Telefon dk Denne publikation er udarbejdet af Digitaliseringsstyrelsen Landgreven 4 Postboks 2193 1017 København K Telefon 33 92 52 00 digst@digst dk Design: Bgraphic Foto: Colourbox Elektronisk publikation: ISBN:

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

Kvalitetsstyringssystem for test af leverandørernes implementering af MedCom s profiler

Kvalitetsstyringssystem for test af leverandørernes implementering af MedCom s profiler Kvalitetsstyringssystem for test af leverandørernes implementering af MedCom s profiler Version 1.0 9. september 2014 INDHOLDSFORTEGNELSE 1 INDLEDNING OG BAGGRUND... 3 2 ANTILOPE PROJEKTET... 4 3 FASEPLAN

Læs mere

BibDok. Guide til BibDok. En metode til at dokumentere effekt af bibliotekets indsatser

BibDok. Guide til BibDok. En metode til at dokumentere effekt af bibliotekets indsatser BibDok En til at dokumentere effekt af bibliotekets er Guide til BibDok BibDok understøtter en systematisk refleksiv praksis. Det er derfor væsentligt, at I følger guiden trin for trin. 1. Sammenhæng mellem

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

Business case skabelon

Business case skabelon Business case skabelon 27. februar 2016 Den gode business case - fra beslutningsdokument til styringsdokument Forfatter: Martin J. Ernst, Jimmy Kevin Pedersen og Peter Hellmann Index Forord... 3 Ledelsesresumé...

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

Klasse 1.4 Michael Jokil 03-05-2010

Klasse 1.4 Michael Jokil 03-05-2010 HTX I ROSKILDE Afsluttende opgave Kommunikation og IT Klasse 1.4 Michael Jokil 03-05-2010 Indholdsfortegnelse Indledning... 3 Formål... 3 Planlægning... 4 Kommunikationsplan... 4 Kanylemodellen... 4 Teknisk

Læs mere

Web-baseret metadata redigeringsmodul

Web-baseret metadata redigeringsmodul Kravspecifikation Geodata Danmark Geodatacentret I/S Energivej 3 4180 Sorø Tlf. 5786 0400 Fax. 5786 0414 GIS Danmark A/S Birkemosevej 7 6000 Kolding Tlf. 7399 1100 Fax. 7399 11199 Web www.geodata.dk Web-baseret

Læs mere

Fælles projektmodel. Fælles projektmodel på tværs af Enhedsadministrationen for projekter der har IT-involvering

Fælles projektmodel. Fælles projektmodel på tværs af Enhedsadministrationen for projekter der har IT-involvering Version 3.1 opdateret 04/03-2016 Fælles projektmodel Fælles projektmodel på tværs af Enhedsadministrationen for projekter der har IT-involvering Formål: Fælles metodik for projekter der involverer AU IT.

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

It-sikkerhedstekst ST8

It-sikkerhedstekst ST8 It-sikkerhedstekst ST8 Logning til brug ved efterforskning af autoriserede brugeres anvendelser af data Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST8 Version 1 Maj 2015 Logning

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

Kontraktbilag 5 Spørgsmål og svar til udbudsmaterialet

Kontraktbilag 5 Spørgsmål og svar til udbudsmaterialet Sagsnr. -23-4-82--3 Kontraktbilag 5 Spørgsmål og svar til udbudsmaterialet Spørgsmål og svar vedrørende UDBUDSMATERIALET (Indsæt selv ekstra rækker efter behov, men behold venligst systematikken): HUSK

Læs mere

Branchens perspektiv på den gode indkøbs organisation. En måling er bedre end 100 mavefornemmelser. Per Hartlev

Branchens perspektiv på den gode indkøbs organisation. En måling er bedre end 100 mavefornemmelser. Per Hartlev Branchens perspektiv på den gode indkøbs organisation En måling er bedre end 100 mavefornemmelser Per Hartlev ph@whitebox.dk 7/11-2016 Release-styring Hjælpe værktøjer Kvalitets sikring Leverandør kontrakter

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

Rolf Fagerberg. Forår 2012

Rolf Fagerberg. Forår 2012 Forår 2012 Mål for i dag Dagens program: 1 2 3 4 5 6 Forudsætninger: DM502 og DM503 Timer: 50% forelæsninger, 50% øvelser Forudsætninger: DM502 og DM503 Eksamenform: Skriftlig eksamen: Timer: 50% forelæsninger,

Læs mere

Rolf Fagerberg. Forår 2015

Rolf Fagerberg. Forår 2015 Forår 2015 Dagens program 1 2 3 4 5 Underviser:, IMADA Forskningsområde: algoritmer og datastrukturer Underviser:, IMADA Forskningsområde: algoritmer og datastrukturer Deltagere: BA i Datalogi BA i Software

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

Vejledning til gevinstdiagram og gevinstprofiler

Vejledning til gevinstdiagram og gevinstprofiler Vejledning til gevinstdiagram og gevinstprofiler Januar 2014 Indhold 1. CENTRALE BEGREBER... 3 2. HVAD ER ET GEVINSTDIAGRAM OG GEVINSTPROFILER... 4 3. FORMÅL MED GEVINSTDIAGRAM OG GEVINSTPROFILER... 4

Læs mere

Kvalitetshåndbog. for. Houe Smed & VVS

Kvalitetshåndbog. for. Houe Smed & VVS Kvalitetshåndbog for Houe Smed & VVS Side 1 af 8 0. Indholdsfortegnelse Kvalitetshåndbog 0. Indholdsfortegnelse 1 1. Forord 2 2. Organisationsplan 3 3. Kvalitetsmålsætning 4 4. Kvalitetspolitik 4 5. Leveringsformåen

Læs mere

Evaluering af familierådslagning i Børne- og Ungerådgivningen

Evaluering af familierådslagning i Børne- og Ungerådgivningen Evaluering af familierådslagning i Børne- og Ungerådgivningen Udarbejdet af: EPO Dato: --9 Sagsid.:..-A-- Version nr.:. Indholdsfortegnelse Indledning Brugerundersøgelsens resultater Resultater af de indledende

Læs mere

Generelt Internationalisering

Generelt Internationalisering Bekendtgørelse om krav til anvendelse af Informations- og Side 1 af 7 Generelt Digital Konvergens samarbejdet, har i sit hidtidige arbejde fokuseret på at implementere vindende, digitale standarder, der

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

Erfaringer med CPR-replikering

Erfaringer med CPR-replikering Erfaringer med CPR-replikering Dette dokument beskriver en række overvejelser vi har gjort os i forbindelse med at vi har udviklet en Proof of Concept (PoC) af en CPR-replikeringstjeneste for KOMBIT. CPRs

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

Vejledning i informationssikkerhedspolitik. Februar 2015

Vejledning i informationssikkerhedspolitik. Februar 2015 Vejledning i informationssikkerhedspolitik Februar 2015 Udgivet februar 2015 Udgivet af Digitaliseringsstyrelsen Publikationen er kun udgivet elektronisk Henvendelse om publikationen kan i øvrigt ske til:

Læs mere

Produktbeskrivelse for. Min-log service på NSP

Produktbeskrivelse for. Min-log service på NSP Produktbeskrivelse for service på NSP Sundheds professionel Borger Fagsystem / Serviceudbyder Sundhed.dk 1 2 3 (Registreringsservice) (Konsolideringsservice) (Udtræksservice) Indeks Database (oprydning)

Læs mere

Agil-model versus V-model set i lyset af en testers dilemmaer

Agil-model versus V-model set i lyset af en testers dilemmaer Agil-model versus V-model set i lyset af en testers dilemmaer 1 Præsentation Foredragsholder Ane Clausen: Cand.Scient i Datalogi Københavns Universitet, Danmark Gift, 3 børn 25 års erfaring med IT: 12

Læs mere

Produktbeskrivelse for

Produktbeskrivelse for Produktbeskrivelse for Service til opfølgning på behandlingsrelationer NSP Opsamling Tjenesteudbyder Opfølgning Notifikation Side 1 af 7 Version Dato Ansvarlig Kommentarer 1.0 22-12-2011 JRI Final review

Læs mere

OFTE STILLEDE SPØRGSMÅL

OFTE STILLEDE SPØRGSMÅL Copyright 2015 EG A/S FAQ OFTE STILLEDE SPØRGSMÅL EG Clinea Dette dokument giver svar på de oftest stillede spørgsmål i forbindelse med opgradering fra MedWin til EG Clinea Copyright 2015 EG A/S FAQ Side

Læs mere

Formålet med forvaltningsrevisionen er således at verificere, at ledelsen har taget skyldige økonomiske hensyn ved forvaltningen.

Formålet med forvaltningsrevisionen er således at verificere, at ledelsen har taget skyldige økonomiske hensyn ved forvaltningen. Forvaltningsrevision Inden for den offentlige administration i almindelighed og staten i særdeleshed er det et krav, at der som supplement til revisionen af regnskabet, den finansielle revision, foretages

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

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

Information og drøftelse

Information og drøftelse Information og drøftelse Budgetbehandlingen i MED-organisationen skal følge de generelle krav om information og drøftelse i henhold til MED-rammeaftalens 7. Budgetbehandlingen skal desuden leve op til

Læs mere

Kvartalsrapport vedr. fase 1 af SKATs systemmodernisering for 1. kvartal 2008

Kvartalsrapport vedr. fase 1 af SKATs systemmodernisering for 1. kvartal 2008 Skatteudvalget (2. samling) SAU alm. del - Bilag 195 Offentligt Notat Hovedcentret Strategi og Udvikling Projektkontoret 13. juni J. nr. 08-048898 Kvartalsrapport vedr. fase 1 af SKATs systemmodernisering

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

Styring af testmiljøer almindelig god praksis

Styring af testmiljøer almindelig god praksis White paper Styring af testmiljøer almindelig god praksis Søren Beyer Nielsen Ph.D., M.Sc. Pragmatic Consult A/S v. 1.2 Pragmatic Consult A/S Stadagervej 42 2730 Herlev Danmark Tel: 44 92 23 77 Fax: 44

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

Byggeriets Evaluerings Center

Byggeriets Evaluerings Center Byggeriets Evaluerings Center Bygge Rating Notat om pointsystem til faktablade og karakterbøger for entreprenører og bygherrer Version 2015 Indholdsfortegnelse 1 Bygge Rating... 3 2 Bygge Rating for entreprenører...

Læs mere

10 spørgsmål der vil hjælpe dig med dine testcases

10 spørgsmål der vil hjælpe dig med dine testcases 10 spørgsmål der vil hjælpe dig med dine testcases Hvad er en testcase En testcase designes ud fra et eller flere test formål, som f.eks. at teste en speciel funktionalitet eller kvalitetsegenskab for

Læs mere

FAT test kan kun undtagelsesvis overføres, et eksempel kunne være verifikation af tag nummerering og el-diagrammer, som kræver en adskilt maskine.

FAT test kan kun undtagelsesvis overføres, et eksempel kunne være verifikation af tag nummerering og el-diagrammer, som kræver en adskilt maskine. Kontraktbilag 8 Prøver 1 FAT og SAT FAT og SAT skal sikre at systemet er klar til kvalificering, dvs. alle test fra IQ, OQ og PQ bør kunne genfindes. Testmateriale udarbejdet af leverandør i forbindelse

Læs mere

Referencelaboratoriet for måling af emissioner til luften

Referencelaboratoriet for måling af emissioner til luften Referencelaboratoriet for måling af emissioner til luften Rapport nr.: 77 Titel Hvordan skal forekomsten af outliers på lugtmålinger vurderes? Undertitel - Forfatter(e) Arne Oxbøl Arbejdet udført, år 2015

Læs mere

Seminar d. 19.9.2013. Klik for at redigere forfatter

Seminar d. 19.9.2013. Klik for at redigere forfatter Seminar d. 19.9.2013 Klik for at redigere forfatter M_o_R En risiko er en usikker begivenhed, der, hvis den indtræffer, påvirker en målsætning Risici kan dele op i to typer Trusler: Der påvirker målsætningen

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

INDICIUM. Løbende evaluering af forvaltningernes indsats for at forbedre sagsbehandlingen og borgerbetjeningen

INDICIUM. Løbende evaluering af forvaltningernes indsats for at forbedre sagsbehandlingen og borgerbetjeningen INDICIUM Løbende evaluering af forvaltningernes indsats for at forbedre sagsbehandlingen og borgerbetjeningen Indledning På mødet i Borgerrepræsentationen den 19. juni 2013 blev det besluttet at pålægge

Læs mere

Opsamling på Temadag 17. december 2014

Opsamling på Temadag 17. december 2014 Opsamling på Temadag 17. december 2014 Indledning Dette dokument er et forsøg på at indfange essensen af de emner, som de mange post-its beskriver under hvert af de fem temaer fra handlingsplanen. Dokumentet

Læs mere

Søren Lauesen IT-Universitetet i København

Søren Lauesen IT-Universitetet i København Hvorfor elektronisk tinglysning startede som en katastrofe Hvordan kunne det være undgået? Hvorfor deres sagsbehandlingssystem blev lukket Søren Lauesen IT-University of Copenhagen E-mail: slauesen@itu.dk

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

Projektplan for DIKU studenterprojekter

Projektplan for DIKU studenterprojekter Projektplan for DIKU studenterprojekter Forfatter: Anders Johansen, Softwareudvikler, Det Kongelige Bibliotek 29. januar, 2007 Projektplan version 1.0 Det Kongelige Bibliotek Postboks 2149, DK-1016 København

Læs mere

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Testspecifikation

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Testspecifikation Udgave 1 2. SEMESTERPROJEKT Gruppe 5 Secure O matic Testspecifikation Benjamin Sørensen, 02284 Tomas Stæhr Hansen, 03539 Stefan Nielsen, 02829 Mubeen Ashraf, 9279 Hussein Kleit, 9281 SECURE O MATIC Testspecifikation

Læs mere