IT-Kravspecifikation med SL-07. Søren Lauesen, oktober 2012 IT-University of Copenhagen

Transkript

1 IT-Kravspecifikation med SL-07 Søren Lauesen, oktober 2012 IT-University of Copenhagen

2 2. Traditionelle krav - løn og vagtplan på hospital Krav 148: Systemet skal kunne registrere den daglige faktiske arbejdstid for hver medarbejder. Krav 475: Systemet skal kunne beregne regnskabsmæssige konsekvenser af en given vagtplan i kroner og øre. Absolutte krav. Både leverandør A og B siger de opfylder dem. Krav A's løsning B's løsning Krav 148. Registrer arbejdstid Krav 475. Regnskabsmæssig konsekvens Fang data via medarbejdernes eksisterende adgangskort Send vagtplan. Svar indenfor 24 timer Løsningen er uanvendelig i praksis Efter kontraktunderskrift leverer A opslagstavleløsningen i stedet? Klassisk IEEE 830 Indtast data fra afdelingens eksisterende opslagstavle Interaktiv løsning: Vis med farvekoder hvor dyrt det er at placere medarbejder N her på planen Er kravet formelt opfyldt? Tallene vises ikke

3 3. Hvad kan vi lære af det? Kravopfyldelse er ikke ja/nej, men grader af værdi. Hvad er bedst: God løsning til krav 1 og dårlig løsning til krav 2. Eller omvendt? Absolutte/ufravigelige krav er uegnede. Løsningen skal være en del af kontrakten.

4 4. Skriv krav 475 som use case? Hovsa-trigger. Use case 475: Beregn regnskabsmæssig konsekvens af vagtplan Hvad bruges det Trigger: Brugeren vil beregne konsekvensen til og hvornår? Precondition: Brugeren er logget på 1. Systemet viser en liste af vagtplaner 2. Brugeren vælger en vagtplan 3. Brugeren vælger "Beregn konsekvens" 4. Systemet beregner konsekvensen 5. Systemet viser konsekvensen Exception: Ingen vagtplaner i listen Selvopfunden dialog. Leverandør B må vrages. Trivielle detaljer - forført af skabelonen. Ingen værditilvækst. Use cases kan ikke fange problemer med ukendt løsning men der er de forretningskritiske behov ofte. Er use cases krav? Skrives, men bruges ikke

5 5. SL-07: Task descriptions. Støt arb.opgave C1, C2... C2: Lav vagtplan Hyppighed: Hver 14. dag. I nogle afdelinger... Start: Når der er fred i vagten. Slut: Når der bliver travlt. Subtask og varianter: 1. Dan ny vagtplan. 2. Registrer ferie. To slags ferie... 2p. Nuv. problem: Små lapper med ønsker mange måneder frem. 3. Bemand vagter. Tjek rette kompetencer, ferie, overenskomster og undgå tillæg. 3p. Nuv. problem: Svært at gøre manuelt. Fejl og for mange tillæg. 3a. Vikarer endnu ikke i systemet. 3b. Skaf medarb. fra anden afdeling. Eksempler på løsning: Automatisk ud fra sidste plan... Systemet kontrollerer feriereglerne. Systemet har en tidshorisont på flere år. Systemet foreslår bemanding af ubemandede vagter. Advarer om brudte regler og unødige tillæg. Støtter "puslespillet" med undo og flere forsøgsudgaver. Viser ledige fra andre afdelinger. 4. Send planen til kommentering. En udskrift af planen er nok. 5. Parker planen eller frigiv den. Udføres af menneske plus computer Eksempel på computers del - ikke krav

6 6. Leverandørsvar (typisk, men ikke eksemplarisk) C2: Lav vagtplan Hyppighed: Hver 14. dag. I nogle afdelinger... Start: Når der er fred i vagten. Slut: Når der bliver travlt. Subtask og varianter: 1. Dan ny vagtplan. 2. Registrer ferie. To slags ferie... 2p. Nuv. problem: Små lapper med ønsker mange måneder frem. 3. Bemand vagter. Tjek rette kompetencer, ferie, overenskomster og undgå tillæg. 3p. Nuv. problem: Svært at gøre manuelt. Fejl og for mange tillæg. 3a. Vikarer endnu ikke i systemet. 3b. Skaf medarb. fra anden afdeling. 4. Send planen til kommentering. 5. Parker planen eller frigiv den. Tilbudt løsning: Automatisk ud fra sidste plan. OK. Systemet kontrollerer feriereglerne. Op til to år frem. Støttes. Se skærmbilleder i... Ledige også fra andre hospitaler. En udskrift af planen er nok.

7 7. Kundens vurdering af løsning ved teknisk afklaring C2: Lav vagtplan Hyppighed: Hver 14. dag. I nogle afdelinger... Start: Når der er fred i vagten. Slut: Når der bliver travlt. Subtask og varianter: 1. Dan ny vagtplan. 2. Registrer ferie. To slags ferie... Nuv. problem: Små lapper med ønsker mange måneder frem. 3. Bemand vagter. Tjek rette kompetencer, ferie, overenskomster og undgå tillæg. Nuv. problem: Svært at gøre manuelt. Fejl og for mange tillæg. 3a. Vikarer endnu ikke i systemet. 3b. Skaf medarb. fra anden afdeling. 4. Send planen til kommentering. 5. Parker planen eller frigiv den. Eksempler / løsning: Automatisk ud fra sidste plan... Systemet kontrollerer feriereglerne. Kun 12 mdr ud i fremtiden. Systemet foreslår bemanding af ubemandede vagter. Tillægsberegning batch - 24 timer. Flere udgaver besværligt. Kan vise ledige fra andre hospitaler. Samlet point: 0 (som i dag)

8 8. Forretningsmæssige mål og hvordan de opnås Bruger: Planlægger i afdelingen C1 Månedlig timeregnskab til pers.afd. C2 Lav vagtplan Bruger: Medarbejder i afdelingen C3 Registrer faktisk arbejdstid C4 Byt vagter C5 Sygdom hos medarbejder Bruger: Personaleafdeling C6 Kontroller vagtplaner C7 Ændringer af lønsedler C8 Registrer nye medarbejdere Forretningsmæssige mål Personaleafdeling: Automatiser nogle opgaver Fjern fejlkilder Overhold 120-dags reglen Mindre trivielt arb. og stress Hospitalsafdeling: Mindre overarbejdsbet. mv. Hurtigere vagtplanlægning Bedre plankvalitet Lavere IT udgifter Task Ikke hierarkisk nedbrydning, men mange-tilmange Forretningsmæssig værdi Ansatte: 5000 Overarb.bet: 20% til 10% IT udgifter nu: 30 mio/år Sparede Mio DKK årsværk over 5 år ? 5? 10 (blød faktor) (400) (blød faktor) 50

9 9. Forretningsproces ikke hierarkisk nedbrydning Proces 2: Behandlingsforløb Start: Patienten henvises af egen læge eller kommer akut. Slut: Patienten er helbredt eller... Trin: 1. Indskriv patienten 2. Stil diagnoser 3. Planlæg behandling 4. Udfør behandling 5. Vurder resultat 6. Udskriv patient Løsning: C1: Indskriv inden ankomst C2: Indskriv akut C10: Udfør klinisk session C10: Udfør klinisk session C10: Udfør klinisk session C10: Udfør klinisk session C3: Udskriv patient...

10 10. SL-07 princip for tasks, sikkerhed, svartider... Nummer og navn på det overordnede krav. Antagelser leverandøren kan gøre, fx brugerne er sygeplejersker, opgaven udføres n gange daglig. Eksempler og baggrundsoplysninger Kundens behov Løsningseksempel -> tilbudt løsning Kode: 1. Delkrav 1p. Problem i dag 2. Delkrav... Kravnoter når der ikke er plads i tabellen. Løsningsnoter når der ikke er plads i tabellen. Og realistiske eksempler på alt

11 11. Kravskabelon SL-07 A. Baggrund og vision, vejledning... B. Overordnede behov B1. Forretningsmæssige mål B2. Early proof of concept B3, B4, B5. Tildelingskriterier mv. C. Arbejdsopgaver systemet skal støtte C1. Indskriv patient 1% genbrug C10. Udfør klinisk session... D. Data systemet skal anvende D1. Diagnoser D2. Diagnosetyper D3. Ydelser... 20% genbrug 1% genbrug E. Andre funktionelle krav E1. Systemgenerede hændelser E2. Komplekse beregninger og regler E3. Udskrifter og rapporter E4. Udbygning af systemet 30% genbrug F. Integration med eksterne systemer G. Teknisk it-arkitektur G1. Brug af eksisterende HW og SW G2. Nyt hardware og software... H. Sikkerhed 50% genbrug H1. Login og adgangsret for brugere H2. Sikkerhedsadministration H3. Sikring mod tab af data H4. Sikring mod utilsigtet brugeradfærd H5. Sikring mod trusler I. Brugervenlighed og design 80% I1. Indlæring og effektivitet i daglig brug I2. Tilgængelighed og Look-and-Feel J. Andre krav og leverancer J1. Andre standarder der skal følges J2. Uddannelse J3. Dokumentation 80% genbrug J4. Datakonvertering J5. Installation K. Kundens leverancer L. Drift, support og vedligehold L1. Svartider L2. Tilgængelighed L3. Datalagring L4. Support L5. Vedligehold 90% genbrug

12 12. Tilgængelighed (driftseffektivitet) hvorfor lige 99.8%? Systemet er ude af drift når en del af brugerne ikke kan få støttet deres arbejdsopgaver som normalt. Årsagen til driftsstoppet kan være: 1. Kundens forhold, fx fejl i kundens udstyr 2. Udefra kommende fejl, fx strømsvigt 3. Leverandørens forhold, fx fejl i software eller fejlagtig konfiguration 4. Planlagt vedligehold 5. Utilstrækkelig hardware kapacitet Løsningsnote: Måling af tilgængelighed Et driftsstop regnes altid for at vare i mindst 20 minutter, selv hvis driften reelt genetableres inden. Hvis en driftsperiode varer mindre end 60 minutter, regnes den for en del af driftsstoppet.... Der medregnes kun driftsstop som skyldes... Krav til driftstid: Eksempel på løsning: Kode: 1. Tilgængeligheden skal opgøres periodisk og der skal tages hensyn til hvor stor en del af brugerne der oplever driftsstoppet. 2. I tidsrummet fra 0:00 til 24:00 på alle dage skal tilgængeligheden være 99,8 %. Tilgængeligheden opgøres månedligt. Leverandøren: OK. Det koster 20 mio/år (Jeg ville have foreslået 99,5%. Det koster kun 5 mio/år.)

13 13. SL-07: L2. Tilgængelighed (driftseffektivitet) Systemet er ude af drift når en del af brugerne ikke kan få støttet deres arbejdsopgaver som normalt. Årsagen til driftsstoppet kan være: 1. Kundens forhold, fx fejl i kundens udstyr 2. Udefra kommende fejl, fx strømsvigt 3. Leverandørens forhold, fx fejl i software eller fejlagtig konfiguration 4. Planlagt vedligehold 5. Utilstrækkelig hardware kapacitet Løsningsnote: Måling af tilgængelighed Et driftsstop regnes altid for at vare i mindst 20 minutter, selv hvis driften reelt genetableres inden. Hvis en driftsperiode varer mindre end 60 minutter, regnes den for en del af driftsstoppet.... Der medregnes kun driftsstop som skyldes... Krav til driftstid: Eksempel på løsning: Kode: 1. Tilgængeligheden skal opgøres periodisk og der bør tages hensyn til hvor stor en del af brugerne der I tidsrummet fra 8:00 til 18:00 på alle hverdage skal systemet have høj tilgængelighed. Open target Tilgængeligheden opgøres månedligt. Her er tilgængeligheden mindst %. (Kunden forventer 99,8 %). 99,9% 20 mio/år. Alternativ: 99,5% 5 mio/år.

14 14. Nå forretningsmål for EPJ. Fra SL-07, B1 Formål med nyt system: Effektiv støtte af klinikerne. Færre fejlmedicineringer. Løbende forbedring af arbejdsgange. Lavere driftsomkostninger. Overordnede løsninger: Alt nødvendigt data til rådighed i ét system. Undgå manuelle mellemled. Indtast ordinationen straks. Systemet kontrollerer for... Let at opbygge standardplaner. Let at integrere med nye systemer. Konkurrenceudsættelse. Relaterede krav: Støtte til C10. Systemintegration. Støtte til C10-C14. Støtte til C30. F10 (integration med nye systemer) Alle krav. Tildelingskriterier. Ikke krav til leverandøren, men nyttig viden

15 15. Risikable krav: Kan ikke udbedres til sidst Fra kravskabelon SL-07, B2: Risikable krav: - Effektiv støtte til grundlæggende arbejdsopgaver - Rimelig svartid med det planlagte antal brugere - Rimelig brugervenlighed - Mulighed for egen / 3. parts udvidelse af systemet -... Leverandøren skal tidligt demonstrere at disse krav kan opfyldes. Skal ske inden for de første uger efter kontraktens underskrift (ellers kan kontrakten opsiges) Proof-of-concept Risiko-reduktion: Fx testsystem med simuleret belastning. Usability test med mockup. Få 3. part til at teste udvidelighed. Hav en anden leverandører i baghånden: Ellers er det for tungt at opsige kontrakten og man vælger at leve med et dårligt system. Den der lyver vinder. Han skal stoppes tidligt.

16 16. Minimumskrav og tildelingskriterier Regler ved EU udbud: 1. Der skal være minimumskrav. Dårligere tilbud afvises. 2. Der skal beregnes ét godhedstal pr. tilbud. Det højeste tal er vinderen. 3. Leverandørerne skal kende beregningsmetoden på forhånd. Problemer ved offentlige projekter: 4. Hvilke af de 1000 krav er minimum (ufravigelige)? Umuligt at afgøre. 5. Hvordan skal vi vægte eller prioritere 1000 krav? Løsning: 6. Fastsæt minimum for kravområder i stedet for enkelt-krav. 7. Tildeling ud fra forretningsmæssig værdi.

17 17. B3. Minimumskrav til elektronisk patientjournal Point: -2 (ikke støttet), -1 (ubekvemt), 0 (som i dag), 1 (effektivt), 2 (meget effektivt) Kravområde Min. point Lev. A Lev. B C1-C4. Indskriv patient -2 1 C10. Udfør klinisk session (*) 0 1 C11-C14. Medicinering 0 2 D. Data. Vurderes via tasks N/A N/A... F10. Integrer med nyt system (*) 1 1 H1. Login og adgangsret 0 0 H2-H5. Anden sikkerhed -1-1 I. Brugervenlighed (*) 0 1 J2. Uddannelse 0 0 J4. Datakonvertering 0 1 L1. Svartid (*) 0 0 * Vurderes også ved det tidlige bevis (proof of concept)

18 18. Tildelingskriterie B4: Nettogevinst i mio kr. over 5 år Forretningsmål 5-års Opf.grad Risiko 5-års værdi potentiale A B A B A B 1. Effektiv støtte af klinikerne 1000 mio % Reducer medicineringsfejl 250 mio % Løbende procesforbedring 250 mio % Mindre driftsomk (se omk.) Bruttogevinst over 5 år 1500 mio 725 Nettogevinst over 5 år Lev. A Lev. B Bruttogevinst over 5 år 725 Produktets pris 100 Kundens hardware-udgifter 50 Medarbejderuddannelse 28 Driftsudgifter over 5 år 100 Samlede omkostninger over 5 år 278 Nettogevinst for 5 år 447

19 19. Tildelingskriterie B5: Vægtede point pr. mio kr. Kravområde Vægt Point A Point B Vægtet A C1-C4. Indskriv patient C10. Udfør klinisk session C11-C14. Medicinering D. Data. Vurderes via tasks (C) N/A... F10. Integrer med nyt system H1. Login og adgangsret 0 0 H2-H5. Anden sikkerhed 0-1 I. Brugervenlighed J2. Bruger uddannelse (omk.) 0 J4. Datakonvertering 0 1 L1. Svartid 5 0 Vægtede point i alt Vægt i forhold til skønnet potentiale i mio kr. Vægtet B

20 20. Resultat: Vægtede point pr. mio kr. Lev. A Vægtede point i alt 135 Produktets pris 100 Kundens hardware-udgifter 50 Medarbejder uddannelse 28 Driftsudgifter for 5 år 100 Samlede omkostninger for 5 år 278 Point pr. mio kr. 0,49 Lev. B

21 21. etl - hvorfor hotline overbelastes 1. Hvordan tinglyser man skøde på en ejerlejlighed? Muligheder: enfamiliebolig, andelslejlighed, landbrugsejendom, men ikke ejerlejlighed. Kur: Ring til hotline en time daglig i tre uger. Svar: Vælg enfamiliebolig - som i loven. 2. Er det gratis at udføre en prøvetinglysning, og hvor meget afprøver den? 3. Anmeldelse afvist. Men hvorfor? Prøv igen - håb på Jackpot? 4. Hvornår bliver sager udtaget til manuel behandling? (Nogle skrev "glædelig jul" i feltet meddelelser til tinglysningsmedarbejderen. Resultat: Sagen blev udtaget til manuel behandling - to måneders behandlingstid). Hvad sagde kravene om brugervenlighed? Krav 153: Kvalitetssikring af brugervenlighed. Leverandøren skal under udviklingen kontrollere den eksterne portals brugervenlighed.... Tilbudsgiver skal beskrive hvordan. Svar på krav 153: Test med Rolf Molichs principper (tænke højt med tidlig prototype). Svar bilag 21, kvalitetssikring, dvs.: Testleder guider testdeltagerne igennem opgaverne, stiller uddybende spørgsmål, og hjælper hvor det er nødvendigt. Ændring 32, : Brugervenlighedstest erstattes af en meget tæt dialog mellem [leverandørens og kundens eksperter] Ups!

22 22. Kravspec: Med brugerhistorier Anmeldelse af bodeling Hans og Grethe blev gift i 1989, men nu skal de skilles. De har i hele ægteskabet boet i Hans' ejendom og de har aftalt at Grethe skal blive boende. Hans logger sig ind på Frem toner en velkomsttekst. Der er tekst og tegning for tingbogen over fast ejendom, bilbogen... Han kan se et ikon for informationscenter... Hans klikker på teksten for fast ejendom. Herefter får han vist et login-billede... Hans har sin digitale signatur lagret på sin PC... Han bliver bedt om at oplyse om han vil tinglyse eller forespørge på fast ejendom... og sin adresse... og om han skal arbejde med oplysninger om ejer, pant, servitutter eller andet. Han vælger ejer og bliver bedt om at oplyse om det er - endeligt skøde - endeligt skøde på flere ejendomme - skøde betinget af købesummens betaling - (og fire andre muligheder, herunder bodeling) I alt 5 A4-sider for dette eks. Teksten siger det ikke er krav. Færdigt system: 22 skærmbilleder for at tinglyse et skøde

23 23. Kravspec: Med use cases Kontekst: Hvad skal han bruge resultatet til? Use case A.5. Egentlig står der bare: 1. Bruger vælger en udfyldt anmeldelse 2. Systemet udfører en prøvetinglysning 3. Brugeren får resultatet Andre use cases: Udfyld anmeldelse Vedhæft fil Underskriv digitalt... Vælg anmeldelse hver gang

24 24. Med SL-07 skabelonen. Systemet skal støtte C1... C1: Tinglys ejerskab Hyppighed: Få gange i borgerens liv Bruger: Almindelig borger Delopgaver og varianter: 1. Udfyld tinglysningsoplysninger (se data i kapitel D) 1a. Hent evt. en parkeret sag 2. Vedhæft evt. dokumenter 3. Prøvetinglys sagen og se hvad der evt. skal ændres. Prøvetinglys evt. igen. 3p. Hvad koster det? Også hvis der er fejl? 4. Giv betalingsinformation og send til tinglysning. 5. Underskriv det nødvendige. 6. Parker evt. sagen. Dækker kontekst plus 6 use cases Eksempler på løsning: Systemet markerer hvilke data der skal udfyldes. Systemet forklarer fejlen i borgerligt sprog. Priserne vises på forhånd. Systemet forklarer hvad der nu vil ske og hvor lang tid der vil gå. Systemet bruger digital signatur. Valgfri delopgaver og rækkefølge Udføres af bruger + computer Eksempel på computers del - ikke krav

25 25. Nogle projekter der har brugt SL Administration af genbrugspladser 2. Knowledge management i en kreditforsikringsvirksomhed 3. Effektiv ansættelse af nye medarbejdere 4. Projektstyring i et SW hus 5. Bookingsystem på hospitaler 6. Socialministeriet DHUV 7. Registrering af miljøoplysninger på Novo Nordisk 8. Studieportal til den Grafiske Højskole 9. Kontrol af arbejdsmiljø 10. Roskilde kommune EOJ 11. Afvikling af en Olympiade 12. Produkt til registrering af erhvervsmæssig kørsel 13. Knowledge Management i Patent- og Varemærkestyrelsen 14. ITIL support i medicinalvirksomhed 15. Overvågning af vindmølledrift 16. CRM til Danske Spil 17. Knowledge management i globale projekter 18. Flight training service 19. Kursusadministration, Grundfos 20. Styring af multinational kuvertering og print 21. Administration af aftenskoler 22. Styring af arbejdsmiljø 23. Dokumentstyring i medicinalindustrien 24. GIS-støtte til alarmcentral 25. Skat forskud

26 26. Erfaringer fra Vestsjællands Amt 1999 Traditionelt Skriv krav Alle spørges. Alle finder på ønsker. Kombineres til een. Få forstår kravene. Tid: 25 uger Vurdér forslag Alle har en mening. Politisk valg. Tid: 10 personmåneder. Med SL-07 Skriv krav Triumviratet skriver krav, specielt arb.opgaver. Alle kan rette opgaverne og tilføje eksempler. Tid: 3 uger (første gang) Vurdér forslag Udfør opgaverne med systemet og giv det en karakter. Udvalgte interessenter spørges. Ingen tvivl. Tid: 1 personmåned.

27 27. Andre erfaringer Fordele: 1. Meget hurtigere at skrive krav og vurdere tilbud. 2. Systematisk styring fra business case til løsning. 3. Kravene er behov de siger ikke hvad systemet skal gøre. 4. Velegnet til agil udvikling. Venstre-siderne ændres meget lidt. 5. Leverandørerne får frihed til at bruge det de har og være innovative. 6. Der er en eksemplarisk kravspec at gå ud fra med realistiske eksempler. Ulemper: 1. Ser let ud, men første gang bliver det helt i skoven. 2. Kræver 3 * 3 timer at lære (on-the-job training). 3. Leverandørerne svarer som de plejer ikke godt nok til at sammenligne dem (trods detaljeret vejledning i kravspecifikationen). 4. Kunderne bruger sjældent tid på at se hvordan tilbuddet opfylder behovene. 5. Kun få konsulenter kender SL-07 metoden. 6. FM gav Statens projektkontor besked på at prøve SL-07, men intet er sket.