Anskaffelse og kravspecifikation SR7_LifeCycle og anskaffelsesplan

SR7: LifeCycle og anskaffelsesplan Kilder SR: Soren Lauesen: Software requirements - Styles and techniques. Addison-Wesley, 2002. UID: Soren Lauesen: User interface design - A software engineering perspective. Addison-Wesley, 2005. Fra kapitel 5. SL-07: Søren Lauesen: Vejledning til kravskabelon SL-07. Samfundslitteratur, 2007. 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 Who does what? Customer or supplier? Elicitation Tender Writing proposal Comparing proposals Formulation Validation Checking Verification Contract Design & program Accept test Reqs management & release planning Next release

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 Task: 1.2 Checkin Purpose: Give guest a room . . . Frequency: . . . 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.

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 Task: 1.2 Checkin Proposal B Purpose: Give guest a room . . . Rating: 3 Frequency: . . . 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. From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

8. SR7.3 Comparing proposals Hotel system evaluation Proposals 0 (bad) - 5 (excellent) A B C Normal requirements 3 4 5 Weakest requirements 3 2 0 Total product points 6 6 5 Priorities and weights? Understands our problem 1 3 5 Track record 4 1 4 Solidity 5 4 4 Total points 16 14 18 Base price 25 20 15 Option 1: Floor map 10 6 - Option 2: . . . 8 - 8 If stakeholders don’t agree? Ideal evaluation Proposals A B C Business value (NPV) 100 100 90 Supplier’s price 25 20 15 Internal investment costs 30 25 10 Net value 45 55 65 From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

9. Kravskabelon B3. 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 Kunden vælger den leverandør der ud fra en helhedsbetragtning giver mest værdi til prisen. Vægtning? Prioriterede kriterier? Minimax? Intet er sikkert. Multi-kriterie beslutning !

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

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

12. (SR7.7) Typiske afsluttende tests 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 . . .

13. (SR7.7) Kravtyper og test Overtagelsesprøve mv. 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. Indirekte gennem skærmbilleder (eller inspektion af databasen?) Inspektion og funktionstest, grænsetest, ulovlige værdier, etc. 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)

14. Ekstra: Anskaffelsesplan - et typisk eksempel Organisation Informanter Valider krav Vurdering af tilbud Usability test Annoncering Datavalidering Dokumentation Kurser og træning Dataskabelse Daglig drift Kunne det betale sig? 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 Leverandør Tilbud Informanter Kontraktunderskrift Tidligt bevis Udvikling / tilpasning Installationsprøve Systemtest Datakonvertering Dokumentation Kurser Anvendelsesprøve Support og hotline Driftsprøve Vedligehold

15. Ekstra: Drivkræfter og show-stoppere (Kotter) Hvor er vi? (skala 0-5) 3/10 27/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

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

17. Erfaringer med SL-07 Mail fra Niels Walentin Johansen, Amager Forbrænding, 12-02-2008: 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. 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: At der lægges en plan for behandlingsforløbet (1, 2) At patienten bliver booket til det planlagte behandlingsforløb (3 - 5) At patienten orienteres om mødedato og klokkeslæt (6) Hyppighed: En eller flere gange for hver patient Trin Eksempel på løsning 2.1 Vurdering 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.2 Iværksættelse af us/beh. straks I princippet foregår der det samme, . . . Systemet understøtter akut oprettede forløb. 2.3 Booking* - kalender Lægesekretærer og sundhedsfagligt personale skal . . . I systemet opbygges elektroniske bookingkalendere . . . 2.4 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.5 Booking - 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.6 Indkaldelsesbrev/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.