Anskaffelse og kravspecifikation SR7_LifeCycle og anskaffelsesplan

SR7: LifeCycle og anskaffelsesplan Kilder SR: Soren Lauesen: Software requirements - Styles and techniques. Addison-Wesley, UID: Soren Lauesen: User interface design - A software engineering perspective. Addison- Wesley, Fra kapitel 5. SL-07: Søren Lauesen: Vejledning til kravskabelon SL-07. Samfundslitteratur, Ekstra: Nye slides som ikke har noget sidestykke i bøgerne. Mange slides er vist i dansk oversættelse. © 2002, 2005, Pearson Education retains the copyright to the slides from the books, but allows restricted copying for teaching purposes only. It is a condition that the source and copyright notice is preserved on all the material.

3. SR7.1 Requirements in product life cycle Inception Elicitation Formulation Checking Contract Design & program Accept test Reqs management & release planning Validation Verification Tender Writing proposal Comparing proposals Next release Who does what? Customer or supplier?

4. (SR7.5) What to answer Req 1: yes; Req 2: yes... [Does the supplier know what he says yes to?] Piles of screens and technical descriptions? [How does it relate to me?] Show how you meet the requirements (e.g. simple screen outlines) [He is willing to cooperate] Sell your track record (“How we solved this customer problem... “) [He will help us out] Show that you understand his problem (go behind the requirements) [He understands - probably the others don’t] Show how to deal with it [He is willing to help - even if he misunderstood a bit] Show how to exceed the expectations [Wow!]

5. (SR7.5) Supplier’s proposal Sub-tasks: 1.Find room. Problem: Guest wants neighboor rooms; price bargain. 2.Record guest as checked in. 3.Deliver key. Problem: Guests forget to return the key; want two keys. Variants: 1a.Guest has booked in advance. Problem: Guest identification fuzzy. Proposal: Floor map developed as an option. See outline on page xx. See room screen p. yy. See guest screen and check-in screen, p. zz We provide no support for electronic keys. Planned for release 5 in 1.5 years. User may search for any field using wild- carding. Task:1.2 Checkin Purpose:Give guest a room... Frequency:... Supplier's reply

6. (SR7.5) Guard yourself State assumptions (sparingly) Offer as an option (where you know your price is high) Ignore the problem (we take the battle later - if the customer notices at all) Risk assessment plus safeguards (each requirement plus... ) Example: R26: The response time shall be at most 0.5 seconds on average when moving from one screen to the next. Never above 2 seconds. (200 simultaneous users) Supplier A: No problem, our response times are of that magnitude. Supplier B: We find a way out later, probably the customer doesn’t notice. Supplier C: Assumption: 2 seconds in 95% of the cases is sufficient. Supplier D: We offer 5 times the usual HW speed to meet the requirement. Supplier E: We offer 2 seconds in 95% of the cases. Option A: 2 seconds in 99%. Price: xxx $. Option B: 2 seconds always. Price:... (and explain why).

7. SR7.4 Customer’s rating Sub-tasks: 1.Find room. Problem: Guest wants neighbor rooms; price bargain. 2.Record guest as checked in. 3.Deliver key. Problem: Guests forget to return the key; want two keys. Variants: 1a.Guest has booked in advance. Problem: Guest identification fuzzy. Assessment: Floor map developed as an option. Very convenient display of bargain prices. If guest is not booked, cumbersome to switch to that task. No support for electronic keys. Tests show no tolerance for spelling errors. Very long search time for names. Task:1.2 CheckinProposal B Purpose:Give guest a room...Rating: 3 Frequency:... From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 Customer's assesment

8. SR7.3 Comparing proposals Hotel system evaluationProposals 0 (bad) - 5 (excellent)ABC Normal requirements345 Weakest requirements320 Total product points665 If stakeholders don’t agree? Ideal evaluationProposals ABC Business value (NPV) Supplier’s price Internal investment costs Net value From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 Priorities and weights? Understands our problem135 Track record414 Solidity544 Total points Base price Option 1: Floor map106- Option 2:...8-8

9. SL-07 B3+B4 Tildelingskriterier Valget af leverandør sker ud fra: -Forretningsmæssig værdi af løsningen (point for hvert forretningsmæssigt mål) -Risiko (tidligt bevis, referencer, modenhed, mv.) -Leveringstid -Pris Intet er sikkert. Multi-kriterie beslutning ! Kunden vælger den leverandør der ud fra en helhedsbetragtning giver mest værdi til prisen. Vægtning? Prioriterede kriterier? Minimax?

10. 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.En leverandør scorer højt de fleste steder, men uventet dårligt ét sted: Resultat? Vi skal vælge ham. Løsning: 6.Fastsæt minimum for kravområder i stedet for enkelt-krav. 7.Tildeling: Vægt kravområderne ud fra forretningsmæssig værdi eller vurder nettogevinst for hvert tilbud.

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

12. Tildelingskriterie: Nettogevinst i mio kr. over 5 år Forretningsmål 5-års poten- tiale Opf.grad5-års værdi ABAB 1. Effektiv støtte af klinikerne 1000 mio Reducer medicineringsfejl 250 mio Løbende procesforbedring 250 mio Mindre driftsomk (se omk.) Nettogevinst over 5 år 1500 mio725 Nettogevinst over 5 år Lev. ALev. B Bruttogevinst over 5 år725 Produktets pris100 Kundens hardware-udgifter50 Medarbejder uddannelse28 Driftsudgifter for 5 år100 Samlede omkostninger for 5 år278 Nettogevinst for 5 år447 Opfyldelsesgrad inkl. risikofradrag

13. Tildelingskriterie: Nettogevinst i mio kr. over 5 år Forretningsmål 5-års poten- tiale Opf.gradRisiko5-års værdi ABABAB 1. Effektiv støtte af klinikerne 1000 mio0.530% Reducer medicineringsfejl 250 mio1.010% Løbende procesforbedring 250 mio1.040% Mindre driftsomk (se omk.) Nettogevinst over 5 år 1500 mio725 Nettogevinst over 5 år Lev. ALev. B Bruttogevinst over 5 år725 Produktets pris100 Kundens hardware-udgifter50 Medarbejder uddannelse28 Driftsudgifter for 5 år100 Samlede omkostninger for 5 år278 Nettogevinst for 5 år447

14. Tildelingskriterier: Vægtede point pr. mio kr. Kravområde VægtMin. pointLev. ALev. B C1-C4. Indskriv patient5-21 C10. Udfør klinisk session C11-C14. Medicinering1502 D. Data. Vurderes via tasks (C)N/A... F10. Integrer med nyt system1511 H1. Login og adgangsret000 H2-H5. Anden sikkerhed0 I. Brugervenlighed1001 J2. Bruger uddannelse(omk.)00 J4. Datakonvertering001 L1. Svartid500 Vægtede point i alt Vægt i forhold til skønnet potentiale i mio kr.

15. Resultat: Vægtede point pr. mio kr. Lev. ALev. B Vægtede point i alt135 Produktets pris100 Kundens hardware-udgifter50 Medarbejder uddannelse28 Driftsudgifter for 5 år100 Samlede omkostninger for 5 år278 Point pr. mio kr.0.49

Analyse Design Program 16. Ekstra: Skal vi teste andet end kravene? Ja ! Brugere Designspec Kode Domænekrav Tester's tricks Test cases: Brugertest... Beta test Støt opg. C1-C8 Højst 5 kritiske problemer Skærmbilleder:... Knapper:... Branch test, tom løkke Dato tom, navn ok Dato ok, navn tom Grænsetest, ulovlig værdi Værelse 1000 Værelse a7% Udfør opgave + Usability test Check ind fra gaden Check ind booket Inspicer skærme prøv funktioner Find gæst, mange match Find gæst, ingen match

17. Ekstra: Test af kvalitetskrav 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. Kan ske inden for de første __ uger efter kontraktens underskrift (eller kontrakten kan opsiges). Proof-of-concept Risiko-reduktion: Fx testsystem med simuleret belastning. Usability test. Få 3. part til at teste udvidelighed. Kvalitetskrav Højst 5 kritiske problemer 95% svartider højst 1,3 s Usability test Performance test Svært at udbedre til sidst

Installationsprøve: Systemtest: Anvendelsesprøve: (Deployment test) Overtagelsesprøve: (Acceptance test) Driftsprøve: (Operational test) Hardware, software, eksterne produkter. Test grundlæggende funktioner. Test alle krav. (Undtagen dem der vedrører drift) Grænse-test, specielle tilfælde, etc. (Der bruges specielt opsat databaseindhold) Produktionsdata (datakonvertering). Test med rigtige opgaver og rigtige brugere. = System test + Deployment test. Test resterende krav, fx svartider i drift, oppetid, hot-line (SR7.7) Typiske afsluttende tests

R1:Systemet skal opbevare data svarende til datamodellen... R2:Systemet skal have skærm- billeder og menuer som i... R3:Systemet skal kunne registrere at et værelse repareres... R4:Systemet skal støtte arbejds- opgaverne check ind... R5:Højst 1 af 5 begyndere må møde kritiske problemer under check ind. R6:Skift til næste skærm må højst tage 1,3 s i 95% af tilfældene. R7:Forkalkulation af reparations- ordrer skal ramme indenfor 5% af faktiske omkostninger. Overtagelsesprøve mv. Indirekte gennem skærmbilleder (eller inspektion af databasen?) Inspektion og funktionstest, grænsetest, ulovlige værdier, etc. Ekspertbrugere prøver det (grænsetest, ulovlige værdier, etc.?) Usability test med det rigtige system Testopsætning og simulation + driftsprøve efter overtagelse Målinger et halvt år efter (Forhåbentlig huskede vi at samle data op før og efter) 19. (SR7.7) Kravtyper og test

20. Ekstra: Anskaffelsesplan - et typisk eksempel IT-afdeling Finde kravene Tjek krav Udbud Leverandørvalg Kontraktunderskrift Tidligt bevis Udvikling / tilpasning Installationsprøve Systemtest Datakonvertering Dokumentation Kurser Anvendelsesprøve Support og hotline Driftsprøve Eftervurdering Vedligehold Garantiperiode udløber Kontrakten udløber Organisation Informanter Målsætning + as-is mål Valider krav Vurdering af tilbud Usability test Informanter Annoncering Datavalidering Dokumentation Kurser og træning Dataskabelse Annoncering Daglig drift Kunne det betale sig? To-be mål Leverandør Tilbud Informanter Kontraktunderskrift Tidligt bevis Udvikling / tilpasning Installationsprøve Systemtest Datakonvertering Dokumentation Kurser Anvendelsesprøve Support og hotline Driftsprøve Vedligehold

21. Ekstra: Drivkræfter og show-stoppere (Kotter) Hvor er vi? (skala 0-5) 3/1027/10... Følelse af nødvendighed (stop selvtilfredsheden) Stærk, styrende koalition Klar vision Kommunikeret vision Forhindringer fjernet Kortsigtede gevinster synlige Fortsæt efter første sejr Kulturændring

22. SR7.10 Requirements tracing Goals & demands Reqspec Design Program Operation Goal-domain tracing (8.7) Domain-reqs tracing (8.8) Reviews and tests (9.3) Direct implementation (7.6) Verification (7.6) Embedded trace inf (7.6) System & accept test (7.7) Consistency checks (9.2) Validation Verification From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

Mail fra Niels Walentin Johansen, Amager Forbrænding, : PS. Registreringssystemet fra vores gamle projekt er netop nu under programmering. Jeg brugte vores gamle opgave ved at klippe opgaveovervejelsesdelen fra og sende resten ud til nogle leverandører, der bød på opgaven. De fortalte alle, at det var en god metode til kravformulering. 23. Erfaringer med SL-07 Vestsjællands Amt, Patientadm. og ventelisteadm. maj-2000: De næste tre slides er fra leverandørens svar. Tilføjelser til Amtets tekst er blå, slettede ting er røde og overstregede. Desuden var der skærmbilleder og generel beskrivelse af løsningen. Slide tre viser et eksempel. Dette var første gang task-metoden blev brugt i et rigtigt udbud. Den gang hed det (desværre) use cases, fordi vi ikke selv havde set den fundamentale forskel. Bemærk også den manglende brug af bydemåde i venstre søjle. Vi havde præket - men... Resultatet er at venstre side er lovlig as-is i stedet for rent domæne-niveau. Vi havde heller ikke opdaget at man i leverandørens svar skulle kunne se både kundens oprindelige løsningseksempel og leverandørens tilføjelse. Jeg har selv indsat og farvemarkeret forskellene.

Use case:2 Patientforløb - VISITATION OG PLAN Formål:A.At der lægges en plan for behandlingsforløbet (1, 2) B.At patienten bliver booket til det planlagte behandlingsforløb (3 - 5) C.At patienten orienteres om mødedato og klokkeslæt (6) Hyppighed:*En eller flere gange for hver patient TrinEksempel på løsning 2.1Vurdering og prioritering Visiterende personale (overlæge, samt evt. andre personalegrupper) vurderer, hvilken behandling*/undersøgelse* patienten skal modtage på baggrund af et samlet overblik over patientens situation. Visiterende personale tager stilling til den længst accepterede ventetid før undersøgelse/behandling påbegyndes. Plejepersonalet skal kunne se hvor patienten er i venteforløbet*, både til at kunne informerer patienten, men også for at kunne danne sig et overblik over samtlige venteforløb Behandlingen kan udsættes såfremt at patienten ønsker det eller såfremt anden årsag begrunder det. Systemet fremviser patientens tidligere patientforløb på eget/andre sygehuse, herunder kritiske* medicinske data. Fra systemet kan oplysningerne printes ud. I systemet registreres der ventegrupper*. Systemet viser patientens venteforløb, herunder hvad patienten venter på, samt hvor længe patienten skal/må vente. Systemet viser hvilke patienter der har ventet længere end det ventegruppen tillader. Dette vises både på skærmen og som udskrift. Via en kontrolliste for servicemålsrapporten, vises hvilke patienter, der har ventet længere end det, ventegruppen tillader. I systemet registreres passiv* venteperiode. 2.2Iværksættelse af us/beh. straks I princippet foregår der det samme,... Systemet understøtter akut oprettede forløb. 2.3Booking* - kalender Lægesekretærer og sundhedsfagligt personale skal... I systemet opbygges elektroniske bookingkalendere Booking - finde en tid Personalet skal kunne finde udvalgte tider afhængig af ressourcer*, tidsintervaller og tider til bl.a. specielle typer af undersøgelse/behandling/operation. Ofte skal patienten i berøring med flere ressourcer på én gang og på samme dag. Patienten skal f.eks. i narkose og opereres. I systemet søger man efter ledige tider på tværs af flere ressourcer. I systemet booker man på flere samtidige ressourcer f.eks. til operationsbooking, hvor der skal kunne bookes kirurgi, anæstesi og operationspersonale.

2.5Booking - overblik Personalet skal kunne se hvor, hvornår og hvad patienten skal til Hvis patienten har flere patientforløb, kan personalet komme til at give patienten en mødedato/tid hvor patienten allerede har en tid i forvejen. Personalet vil gerne kunne koordinerer det således, at patienten evt. kan få flere mødetider på samme dag og evt. gerne i forlængelse af hinanden. Personalet skal have et overblik over de patienter der møder, bl.a. med oplysninger om patientdata, den bookede tid, diagnoser* og bemærkninger. I systemet ser man den registrede aftale, samt patientens identitet, ydelsens omfang og karakter, tid og sted for ydelsen, samt eventuelt tilknyttede behandlere*. Det er muligt af få vist alle patientens bookinger. I forbindelse med udsøgning af ledige tider kontrollerer systemet, om patienten har overlappende tider. Man kan således ikke komme til at booke overlappende tider. Har patienten fået 2 overlappende mødetider adviserer systemet herom, uanset hvilke afdelinger der er reserverede tider på. Systemet viser patientens reserverede tider for samtlige patientforløb, så tiderne fra andre ambulatorier også kommer med. (over en periode på f.eks. 14 dage). Udskrift af daglige mødelister. Listerne udskrives automatisk. Det er muligt at vælge hvilke oplysninger der skal med på listen. Endvidere vises bookingoplysningerne på en on-line oversigt. 2.6Indkaldelsesbrev/ventebrev Fra henvisningen er modtaget skal patienten senest 8 dage efter modtage et indkaldelsesbrev med mødedato og klokkeslæt til patientens første besøg. Det er sædvanligvis lægesekretæren der udsender indkaldelsesbreve. En patient skal måske til flere forundersøgelser inden der tages beslutning om endelig behandling. Patienten skal derfor orienteres om flere mødetider og skal måske indkaldes flere gange. Patienten har en mødetid f.eks. 3 måneder frem, vil lægesekretæren skrive et erindringsbrev til patienten. Fra systemet udskrives et indkaldelsesbrev, baseret på forud defineret skabelon. Skabelonen er defineret af IT-afdelingen og superbrugere. I indkaldelsesbrevet står evt kan stå. mere end én mødetid, og patienten kan indkaldes flere gange.. Skal patienten komme til flere forundersøgelser sendes flere indkaldelsesbreve. Systemet udskriver automatisk et erindringsbrev til patienten på et brugerdefineret antal dage før det første besøgEt erindringsbrev bestilles og udskrives fra systemet.