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. Krav og svar - system til ansøgningsbehandling

7. System til ansøgningsbehandling (2)

8. (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).

9. 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

10. 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

11. 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, som vi ikke troede skulle være minimumskrav: 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.

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. Minimumskrav? Kun krav 148. Vi kan leve uden krav Traditionelle krav - løn og vagtplan på hospital Klassisk IEEE 830 KravA's løsningB's løsning Krav 148. Registrer arbejdstid Fang data via medarbejdernes eksisterende adgangskort Indtast data fra afdelingens eksisterende opslagstavle Krav 475. Regnskabsmæssig konsekvens Send vagtplan. Svar indenfor 24 timer Interaktiv løsning: Vis med farvekoder hvor dyrt det er at placere medarbejder N her på planen Løsningen er uanvendelig i praksis Er kravet formelt opfyldt? Tallene vises ikke Efter kontraktunderskrift leverer A opslagstavleløsningen i stedet?

Hvad er bedst: God løsning til krav 148 og dårlig løsning til krav 475. Eller omvendt? 13. Hvem skal vi vælge? 5 års besparelseVærdi af A's løsningVærdi af B's løsning Krav 148. Registrer arbejdstid Data via adgangskort: 10 mio Indtast fra opslagstavle: 0 mio Krav 475. Regnskabsmæssig konsekvens Send vagtplan. Svar indenfor 24 timer: 0 mio Interaktiv løsning med farvekoder: 800 mio I alt10 mio800 mio Kravopfyldelse er ikke ja/nej, men grader af værdi. Minimums/ufravigelige krav er uegnede. Løsningen skal være en del af kontrakten.

14. 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)

15. 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.) Bruttogevinst 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

16. Tildelingskriterie B5: Vægtede point pr. mio kr. Kravområde Vægt Point A Point B Vægtet A Vægtet B C1-C4. Indskriv patient515 C10. Udfør klinisk session C11-C14. Medicinering15230 D. Data. Vurderes via tasks (C)N/A... F10. Integrer med nyt system151 H1. Login og adgangsret00 H2-H5. Anden sikkerhed0 I. Brugervenlighed101 J2. Bruger uddannelse(omk.)0 J4. Datakonvertering01 L1. Svartid50 Vægtede point i alt Vægt i forhold til skønnet potentiale i mio kr.

17. 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

Testing

Analyse Design Program 19. 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

20. 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, rigtige brugere, rigtigt driftsmiljø. = 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) 22. (SR7.7) Kravtyper og test

23. 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

24. 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

25. 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