Præsentation er lastning. Vent venligst

Præsentation er lastning. Vent venligst

Anskaffelse og kravspecifikation SR6_Quality. SR6: Kvalitetskrav Kilder SR: Soren Lauesen: Software requirements - Styles and techniques. Addison-Wesley,

Lignende præsentationer


Præsentationer af emnet: "Anskaffelse og kravspecifikation SR6_Quality. SR6: Kvalitetskrav Kilder SR: Soren Lauesen: Software requirements - Styles and techniques. Addison-Wesley,"— Præsentationens transcript:

1 Anskaffelse og kravspecifikation SR6_Quality

2 SR6: Kvalitetskrav 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 3. SR6.1 Quality factors ISO 9126 Functionality Accuracy Security Interoperability Suitability !! Compliance !! Reliability Maturity Fault tolerance !! Recoverability !! Usability Efficiency Maintainability Testability Changeability Analysability !! Stability !! Portability Adaptability Installability !! Conformance !! Replaceability !! McCall US Airforce 1980 Operation: Integrity Correctness !! Reliability Usability Efficiency Revision: Maintainability Testability Flexibility Transition: Portability Interoperability Reusability !! Use as check lists

4 4. SR6.2 Kvalitetsmatrix (ud fra McCall's faktorer) Årsag: 1.Svært at køre hotellet når systemet er nede. Check ind er fx umuligt når man ikke kan se værelsets status. 2.Vi går mest efter små hoteller. De har utrænede vikarer. 3.Kunderne har mange slags regnskabssystemer. Vigtigt med smertefri integration. 4.Integration med regneark, etc. ligegyldig. Den indbyggede statistik burde være nok. 5.Skal være meget lettere at installere end eksisterende systemer. Ideelt skal en receptionist kunne gøre det selv. Drift Sikkerhedx Fejlfrihedx Oppetid1 Brugervenlighed2 Svartid mv.x Ændring Retbarhedx Testbarhedx Udvidelighedx Overførsel Flytbarhedx Integration34 Genbrugelighedx Installerbarhed5 Kritisk Vigtig Som vi plejer Mindre vigtig Glem det Kvalitets- faktorer for hotelsystem

5 Efficiency Response time Capacity Accuracy...

6 6. (SR6.3A+6.5A) Svartidskrav Urealistisk R10:Når man går fra et felt til det næste, skal man kunne taste indenfor 0,2 s. R11:Når man går fra et skærmbillede til det næste, skal man kunne taste indenfor 1,3 s. R12:Visning af simple rapporter på skærmen skal ske indenfor 20 s. R20:Visning af simple rapporter på skærmen skal ske indenfor 20 s i 95% af tilfældene. Det må aldrig tage over 80 s. Skal gælde i 95% af tilfældene ved spidsbelastning, dvs.: 20 brugere arbejder med sagsbehandling (arbejdsopgave T12) og 100 brugere med kundesupport (arbejdsopgave T10) Mental skiftetid Ellers skifter man task Ellers nedsættes tastetiden Processtyring - spidsbelastning R30:Systemet skal kunne behandle én alarm på 1 sekund, 1000 alarmer på 5 sekunder.

7 R2:Systemet skal beregne en belægningsprognose indenfor 20 s. R3:Systemet skal beregne en belægningsprognose indenfor 40 s. R4:Systemet skal beregne en belægningsprognose indenfor ___ s. 7. (SR6.3A) Åbent mål (target) Bedst mulig er 40 s? Ingen prøver 20 s Åbent mål men hvor vigtigt? R5:Systemet skal beregne en belægningsprognose indenfor ___ s. (Kunden forventer 20 s.) Åbent mål + forventning Krav til svartider Når man går fra et felt til det næste skal brugerens tastehastighed ikke nedsættes. Visning af simple rapporter skal ske inden brugeren taber tålmodigheden. Eksempel på løsning Man kan taste inden ___s. (Kunden forventer 0,2 s) Rapporten skal være synlig inden ___s. (Forventer 20 s) Formulering i kravskabelon SL-07:

8 8. SR6.3C Cost/benefit of response time 1234min 1 2 $ or ratio System cost Benefit (saved time) Benefit/cost Response time

9 9. Extra: Queues and response time Busy + queue Computer idle I need 8 seconds service Computer idle Busy 3 more seconds Busy plus one in queue Waiting time0 s3 s3 + 8 s Service time8 s Response time8 s11 s19 s Computer busy My request Computer load: 20%p = 80%p ≈ 16%p ≈ 3% Computer load: 80%p = 20%p ≈ 16%p ≈ 13%

10 10. SR6.5B Response times, M/M/1 Average 99% 95% 90% 80% System load Response factor Example: Service time: Time to process one request Average service time: 8 s (exp. distr.) Average interarrival time:10 s (exp. distr.) System load: 8/10 = 0.8 Service time: Exponential distribution Average response time: 5  service time = 40 s 90% responses within: 12  service time = 96 s

11 11. SR6.5C Response times, M/D/1 Average 99% 95% 90% 80% System load Response factor Service time: Constant Example: Service time: Time to process one request Average service time: 8 s (constant) Average interarrival time:10 s (exp. distr.) System load: 8/10 = 0.8 Average response time: 3  service time = 24 s 90% responses within: 6  service time = 48 s From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

12 12. SR6.4 Capacity and accuracy requirements Capacity requirements: R1:The product shall use < 16 MB of memory even if more is available. R2:Number of simultaneous users < 2000 R3:Database volume: #guests < 10,000 growing 20% per year #rooms <1,000 R4:Guest screen shall be able to show at least 200 rooms booked/occu- pied per day, e.g. for a company event with a single “customer”. Accuracy requirements: R5:The name field shall have 150 chars. R6:Bookings shall be possible at least two years ahead. R7:Sensor data shall be stored with 14 bit accuracy, expanding to 18 bits in two years. R8:The product shall correctly recognize spoken letters and digits with factory background noise ___ % of the time. Tape B contains a sample recorded in the factory.

13 Usability: Let at lære, effektivt at bruge, let at huske subjektiv tilfredshed, forstå hvad der sker

14 Eksempler: Systemet gør som programmøren har tænkt, men brugeren: P1.Kan ikke finde ud af at starte søgningen. Finder endelig ud af at bruge F10. P2. Tror han har fuldført opgaven, men glemte at klikke på Opdatér. P3. Ser rabatkode-feltet, men kan ikke finde ud af den kode han skal bruge. P4. Siger det er tåbeligt at skulle bruge 6 skærme til at udfylde 10 felter. P5.Vil udskrive en liste af rabatkoder, men det kan systemet ikke. 14. SR6.6B Usability / brugervenligheds problemer Alvorlighed: 1Manglende funktion (strengt taget ikke brugervenlighed) 2Task failure 3Irriterende, besværligt 4Mellem-problem (lykkes efter længere tid) 5Lille problem (lykkes efter kort tid) Kritisk problem = Manglende funktion, task failure, irriterende - oplevet af mange brugere

15 Formål: Finde usability problemer 15. SR6.6C Usability test - tænke-højt forsøg Typisk bruger Log-fører Lytter Registrerer problemer Forsøgsleder Stiller opgaverne Lytter - spørger evt. forsigtigt Jeg prøver det her fordi... Brugeren bemærker ikke... Bør gøres inden programmering - skærmbilleder på papir

16 16. Ekstra: Usability test - tænke-højt forsøg med Mockup Typisk bruger Log-fører Lytter Registrerer problemer Jeg prøver det her fordi... Brugeren bemærker ikke... Formål: Finde usability problemer Forsøgsleder Stiller opgaverne Skifter "billeder" Udfylder svarfelter Erfaringer, fx Bruel & Kjær: Ca. 3 iterationer. Tager 1-3 uger. Programmeringen bliver lettere og hurtigere. Produktet sælger langt bedre. Ret og redesign Test igen

17 17. SR6.7 Usability-krav - 1 Problemtælling R1:Højst 1 af 5 begyndere må møde kritiske problemer under opgave Q og R. Højst 5 mellem-problemer på listen. Risk Kunde Lev. Tastetrykstælling R3:Morgenmad skal kunne registreres med 5 tastetryk pr. værelse. Ingen brug af mus. Tidtagning R2:Begyndere skal kunne udføre opgave Q og R på i alt 15 min. Erfarne brugere opgave Q, R og S på i alt 2 min. Meningsmåling R4:80% af brugerne skal synes systemet er let at lære. 60% vil anbefale det til andre. Forståelighedsmåling R5:Vis 5 brugere 10 fejlmeddelelser, fx Beløb for stort. Spørg om årsagen. 80% af svarene skal være mindst 8 på 13-skalaen. Detaljer: En begynder har fået 5 min instruktion... Opg. Q: John Simpson ringer og vil bestille et værelse...

18 18. SR6.7 Usability-krav - 2 Design-niveau krav R6:Systemet skal have de skærmbilleder der er vist i bilag xx, og knapperne skal virke som beskrevet i bilag yy. Risk Kunde Lev. Produkt-niveau krav R7:For alle felter med en kode, skal brugeren kunne vælge koden fra en drop-down liste. Krav til udviklingsprocessen R9:Leverandøren skal teste 3 iterationer af brugergrænsefladen (papir-prototype) for at fjerne de værste problemer. Overholdelse af GUI standard R8:Systemet skal overholde GUI standarden zz. Desuden må menuerne højst have tre niveauer. Hvis kunden ikke er tilfreds efter tredje iteration, kan han hæve kontrakten.

19 Tidtagning Problemtælling Tastetrykstælling Meningsmåling Forståelighedsmåling GUI standard Let at lære Effektivt at bruge Let at huske Subjektiv tilfreds Forstå hvad der sker ?? God Nyttig Kun indikationer 19. UID1.6H Den bedste kravtype - afhænger af... Tidlig udvikling Sen udvikling Købe et system

20 20. SL-07: I1. Indlæring og effektivitet i daglig brug

21 Security: Trusler og beskyttelse, Identifikation, Rettigheder

22 22. SR6.8A Sikkerhed og trusler System Lønseddel Nysgerrige øjne Wire tapping TruslerØdelæggerForebyggelse Input, fxFx FejltagelseIntegritetLogisk kontrol Ulovlig brugÆgthedPassword... Wire tappingFortrolighedKryptering Wire tapping Disk crash From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 Lagring/proces Disk crashTilgængelighedDublerede diske ProgramfejlIntegritetTestmetoder Virus sletter dataTilgængelighedAntivirus... Output, fx KabelbrudTilgængelighedMultiple linier BedrageriFortrolighedRevision Virus sender dataÆgthedKryptering... CIA + A: Confidentiality= fortrolighed Integrity= integritet Availability= tilgængelighed + Authenticity= ægthed

23 23. SR6.8B Risikovurdering - hotelsystem Trussel Input Fup-booking Lagring Disk crash Comp. crash Sabotage Bedrageri Virus Output Printerfejl Antagelser: Tabe databasen med alle bookinger:1.000.000 Tabe computer- adgang 1 dag: 50.000 On-line booking uden dækning: 3.000 Bedrager der fjerner fakturagrundlag1.000.000 Adm. rod når fakturaer ikke printes2.000 Beløb i kr. Gange pr.TabTab årpr. gangpr. år 103.00030.000 0.31000.000300.000 150.00050.000 0.11000.000100.000 0.21000.000200.000 11000.0001000.000 202.00040.000

24 24. SR6.9A Sikkerhedskrav vedr. trusler R1:Beskyt mod tab af databasen. Estimeret tab skal være < 1 pr. 50 år. R2:Beskyt mod disk crash. Estimeret tab skal være < 1 pr. 100 år. R3:Systemet skal bruge dublerede diske (RAID disks). From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 R4:Systemet skal beskytte mod virus der sletter/ødelægger filer. Antal angreb der ikke undgås < ______. R5:Systemet skal have antivirus og firewall mod virus. R6:Systemet skal følge god regnskabspraksis. Leverandøren skal sørge for certificering. R7:Systemet skal forhindre at brugere sletter fakturaer før de overføres til regnskabssystemet. R8:Leverandøren skal som en option tilbyde at systemet tjekker creditkort og tilbageholder beløb. R9:Leverandøren skal vedlægge en risikovurdering og foreslå beskyttelsesforanstaltninger.

25 Delopgaver vedr. brugeres adgang:Eksempler på løsning:Kode: 1.Identificer brugeren.Hver bruger har et brugernavn og et password. Gerne også en alternativ form, fx stemme... 1p.Problem: Brugeren har været væk... En anden kan bruge rettighederne. Systemet timer ud efter 5 min. 1q.Problem: Hvis systemet timer ud er det besværligt at logge på igen. Systemet kræver kun passw. Timeout er stedafhængig. 2.Kontrollér at bruger har de krævede rettigheder. (Se liste nedenfor). 2p.Problem: I dag har brugerne et passw til hvert system. Tit på opslagstavlen ! Kun ét brugernavn og passw. pr. bruger (single sign-on). 25. SL-07:H1 Login - hvad er behovet egentlig? Rettigheder 1.Ret til at ordinere medicin på afdeling M. 2.Ret til at se patientdata på afdeling M. 3.Ret til at registrere klinisk data (ydelser og diagnoser) på afdeling M.... En tilsynsførende på afdeling M kan fx have rettighed 2 og 3.

26 Delopgaver vedr. sikkerhedsadministration:Eksempler på løsning:Kode: 1.Tildel eller fjern rettigheder for en bruger. 1a.Brugeren skal oprettes. 1p.Problem: En lang række brugere skal oprettes, fx lige inden månedsstart. Automatisk overførsel af data fra personalesystemet. 1q.Problem: En hasteindkaldt vikar er endnu ikke i personalesystemet, men skal have adgangsret. Mulighed for midlertidig oprettelse udenom sikkerheds- administrationen. 1r.Problem: Sikkerhedsadministrationen skal holde styr på sammenhængen mellem 4000 brugere og 300 rettigheder. Hver bruger tildeles en eller flere roller, fx læge i afdeling M og tilsynsførende i afdeling N. 1s.Problem: Sikkerhedsadministrationen glemmer at oprette og fjerne rettigheder på de rigtige tidspunkter, fx... Rettigheder kan defineres så de gælder for en periode, fx fra den dag personen ansættes. 2.Opret nye rolletyper med nye kombina- tioner af rettigheder. 3.Få oversigt over hvem der har ret til... 26. SL-07:H2 Sikkerhedsadministration Sikkerhedsadministrationens arbejde omfatter nedenstående delopgaver. Vanskeligt:Når 120 nye medarbejdere er ansat og skal have rettigheder fra dag 1.

27 Roller EntitetReceptionistShift managerAdministrator GæstCRURD (periodisk) OpholdCRURD (periodisk) Vær.tilstandCRUD (ej særrabat)U (særrabat)D (periodisk) VærelseRRCRUD ServiceCRUD (ej særrabat)U (særrabat)D (periodisk) Service typeRRCRUD Rettigheder man kan have: CRUD = Create, Read, Update, Delete Krav 1 :Hver rolle har kun de rettigheder der fremgår af tabellen. Krav 2:En bruger kan have en eller flere af disse roller og har dermed alle de rettigheder som disse roller giver. Eksempler på løsning: a:Rettighederne kontrolleres i database-systemet. b:Brugerens skærmbilleder viser kun de funktioner han har ret til at bruge. 27. Ekstra: Adgangsrettigheder, hotelsystem

28 Maintenance

29 29. SR6.10 Maintenance Product Corrective maintenance Preventive maintenance New release Perfective maintenance Maintenance cycle: Report: Record and acknowledge. Analyze: Error, change, usability, mistake? Cost/benefit? Decide: Repair? reject? work-around? next release? train users? Reply: Report decision to source. Test: Test solution. Related defects? Carry out: Install, transfer user data, inform. Don't just prioritize

30 Maintenance performance R1:Supplier’s hotline shall analyze 95% of reports within 2 work hours. Urgent defects (no work around) shall be repaired within 30 work hours in 95% of the cases. R2:When reparing a defect, related non-repaired defects shall be less than 0.5 in average. R3:For a period of two years, supplier shall enhance the product at a cost of ___ per Function Point. Risk Cust. Suppl 30. SR6.11A Maintenance requirements Support features R4:Installation of a new version shall leave all database contents and personal settings unchanged. R5:Supplier shall station a qualified developer at the customer’s site. R6:Supplier shall deposit code and full documentation of every release and correction at ____________.

31 Development process requirements R7:Every program module must be assessed for maintainability according to procedure xx. 70% must obtain “highly maintainable” and none “poor”. R8:Development must use regression test allowing full re- testing in 12 hours. 31. SR6.11B Maintainability requirements Risk Cust. Suppl Program complexity requirements R9:The cyclomatic complexity of code may not exceed 7. No method in any object may exceed 200 lines of code. Product feature requirements R10:Product shall log all actions and provide remote diagnostic functions. R11:Product shall provide facilities for tracing any database field to places where it is used.

32 Kravområde Dialog-funktion Data Integration Platform Svartid Sikkerhed Brugervenlighed Love & regler Support Vedligehold 32. Ekstra: Tre af kravenes dimensioner Forretn. mål Domæne Produkt Design Proces Kravniveau Ja-nej Talskala Point (fx 5-trinskala) Kan ikke vurderes Målemetode


Download ppt "Anskaffelse og kravspecifikation SR6_Quality. SR6: Kvalitetskrav Kilder SR: Soren Lauesen: Software requirements - Styles and techniques. Addison-Wesley,"

Lignende præsentationer


Annoncer fra Google