Reliability, Availability and Maintainability

Slides:



Advertisements
Liknende presentasjoner
NBF i går – i dag – i morgen Hva er forbundets tilbud til medlemmene? Tradisjonelt har forbundets og kretsenes spilletilbud vært rettet mot de som har.
Advertisements

De dårige følelsene. Veiene ut..
Hva slags spørsmål skal man stille på hvilke nivåer?
Klikk Aktiver redigering i meldingsfeltet.
22 tips for den faglitterære forfatteren
PowerPoint laget av Bendik S. Søvegjarto Konsept, tekst og regler av Skage Hansen.
I dette shoppingcenteret hadde kvinner en unik mulighet til å velge seg ut en passende make blant forskjellige menn.....
Gjenfinningssystemer og verktøy II
Erstatter i sin helhet skriv 1 (tidligere publisert på nettet)
Fagdag for barne- og ungdomsarbeidere Harebakken 20. november 2013
Hva trenger jeg av data, og hvordan skal jeg innhente disse?
Målinger generelt •I et moderne samfunn brukes målinger i mange ulike sammenhenger •Eksempler: –Sammenligne priser, lønninger –Høyde: størrelse på klær.
Kap 10 Estimering.
Kap 5 - Prediksjonsmodeller
UML & object models av gruppe 8
Managerial Decision Modeling
PowerPoint laget av Bendik S. Søvegjarto Konsept, tekst og regler av Skage Hansen.
Levende HMS-system – hva betyr det i praksis?
Vi har lært å bestemme: - Nullpunkter (y=0)
Gjenfinningssystemer og verktøy II
Forside Korteste sti BFS Modifikasjon Dijkstra Eksempel Korrekthet Analyse Øving Spørsmål Dijkstras algoritme Åsmund Eldhuset asmunde *at* stud.ntnu.no.
Dijkstras algoritme Åsmund Eldhuset asmunde *at* stud.ntnu.no
Eksempel AOA (Activity On Arc)
Kompleksitetsanalyse
Oppgave gjennomgang Kap. 3 og 4.
1 Oppgave gjennomgang Kap Oppgaver -Kap 12: 1, 2, 3, 5, 7, 8, 11, 18, 19.
EVALUERING AV PRODUKTER, PROSESSER OG RESSURSER. Gruppe 4 Remi Karlsen Stian Rostad Ivar Bonsaksen Jonas Lepsøy Per Øyvind Solhaug Andreas Tønnesen.
Grunnleggende testteori
Prototyping In 140 Sommerville kap. 8. Mål Forstå hensikten med prototyping i forskjellige utviklingsprosjekt Forstå forskjellen mellom evolusjonær og.
Utført av: Jeppe Flensted HiST Vår 2009
Prognose av framtidig etterspørsel
Tidligere eksamensspørsmål
Hvordan uttrykke krav Kapittel 4.4. Innledning Målet er å samles rundt ett entydig språk som ikke kan misforståes eller feiltolkes. Gjør sporbarheten.
Gruppe 3 – Presentasjon 2 Henning Kristiansen, Mats Lindh, André Hauge og Vegard Simensen.
Testing av system Gruppe 6 Henrik Bækhus Morten A. Iversen Mathias Bondeson Gunnar K. Kulleseid Svein Ivar Kristiansen Ronny Hulthin.
Teknikker for å bedre design- prosessen -Design by contract -Prototyping design -Fault-tree analyses.
Improving Products Gruppe Presenteres av : Hege-Kristin Johansen Herman Kolås Marianne Ates Marit Finden Jonas Lillevold André Johansen Tom.
Automated Testing Tool & When to Stop Testing
Object Oriented Measurement
Kontrollregler Z- tabell Kontrollregler Tillatt totalfeil
Ch 4 INTEGRASJON Integrasjon innebærer å finne alle funksjoner F som har f derivert. Disse funksjoner kalles antiderivert av f og formelen for de er det.
NÅ SKAL VI LÆRE OM LIKNINGER.
PROSJEKT: UADRESSERT REKLAME Omnibus: 23. august – 30 august 2006
Diskrete stokastiske variable
Magnus Haug Algoritmer og Datastrukturer
1 Oppgave gjennomgang Kap. 1 og 2. 2 Oppgaver -Kap 1: 5, 6, 7, 10, 12, 16, 22 og 25 -Kap 2: 2, 6, 10, 12, 13, 14 og 20.
Spørsmål og aktiviteter på ulike nivåer
SINTEF-undersøkelsen om salting og trafikksikkerhet
Kapping av plater Mål: Vi skal lage komponenter for en møbelfabrikk ut fra standardiserte plater på 12 x 24 dm. Komponentene har lengde og bredde oppgitt.
ENDRINGER I NASJONALE PRØVER ― Ny skala og måling av utvikling over tid Per Kristian Larsen Vurdering 2.
Maintenance problems - Measuring Maintenance characteristics Software Engineering Gruppe 2 Carl-Erik Herheim Leendert Wienhofen Thomas Julsen Kjartan Haugen.
BUCS Utfordringer og valg av fokus Tor Stålhane. Rammebetingelser Første spørreundersøkelse viser at det vi gjør må kunne: Brukes sammen med UML Passe.
4. Prioritizing Your Usability Problems Prioriteringer.
ENDRINGER I NASJONALE PRØVER ― Ny skala og måling av utvikling over tid Per Kristian Larsen, Vurdering 2.
Hypotesetesting, og kontinuerlige stokastiske variable
Usikkerheter og sannsynligheter Petter Mostad
Forelesning 4 HSTAT1101 Ola Haug Norsk Regnesentral
Forelesning 5 HSTAT1101 Ola Haug Norsk Regnesentral
Statistikk 2 M1 årskurs HVE 31. august 2009.
1 Utvikling av kritiske systemer Kort sammendrag Kap. 1 og 2.
Objektorientert design In 140 Sommerville kap 12 – del 1.
Stian Grønning Master i samfunnsøkonomi Daglig leder i Recogni.
Funksjoner med digitale hjelpemidler- GeoGebra Høyskolen i Oslo og Akershus Mandag Trine Foyn.
Funksjoner med digitale hjelpemidler- GeoGebra Høyskolen i Oslo og Akershus Mandag Trine Foyn.
Sluttvurdering av student i apotek Tips til utfylling av vurderings-skjema Camilla Foss, ansvarlig for apotek-praksis ved Høgskolen i Oslo og Akershus.
God undervisning og dybdelæring i matematikk
Håvard Hansen Doktorgradsstipendiat Institutt for markedsføring
Tittel på forskningsprosjekt
Dybdelæring – regneark B – Samarbeid
Utskrift av presentasjonen:

Reliability, Availability and Maintainability Software Engineering Gruppe 8 Reliability, Availability and Maintainability Hege K. Johansen Herman Kolås Marianne E. Ates Tom Vidar Lunde Marit Finden Jonas Lillevold André Johansen

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability En bil er pålitelig dersom: - den fungerer i lange tidsperioder uten at det kreves vedlikehold.  - den har lange perioder med konsistent, ønskelig adferd mellom vedlikeholds periodene.

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability En bil er tilgjengelig dersom: - du kan bruke den når du trenger den.

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability En bil er vedlikeholdbar dersom:  - Det er lett å skaffe reservedeler - Det som regel går an å reparere den Raskt

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability Det samme gjelder for software systemer. Vi vil at systemet skal være pålitelig, fungere bra i lange tidsperioder, og være tilgjengelig når vi trenger det. Dersom det trengs vedlikehold, skal dette kunne skje effektivt slik at det kjapt kan bli tilgjengelig igjen.

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability Det er ikke alltid mulig å foreta direkte målinger av disse karakteristikkene, og dette kan gjøre det spesielt vanskelig å forsikkre seg om at våre krav er oppfyllt. Vi blir nødt til å foreta indirekte målinger for å anslå hvordan systemet fyller kravene på disse punktene.

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability Software pålitelighet er et mål på hvor sannsynlig det er at produktet vil fungere feilfritt i et gitt tids- intervall. Påliteligheten angis med et tall fra 0 til 1. Jo nærmere 1 desto mer pålitelig.

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability Software tilgjengelighet Dette er et mål på hvor sannsynlig det er at produktet har fullstendig funksjonalitet på et gitt tidspunkt. Tilgjengeligheten angis med et tall fra 0 til 1. Jo nærmere 1 desto mer tilgjengelig.

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability Software vedlikeholdbarhet Dette er et mål på hvor sannsynlig det er at vedlikehold kan gjennomføres innenfor bestemte tidsrammer ved hjelp av stadfestede prosedyrer og ressurser. Vedlikeholdbarheten angis med et tall fra 0 til 1. Jo nærmere 1 desto mer vedlikeholdbart.

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability Siden pålitelighet, tilgjengelighet, og vedlikeholdbarhet måles ut fra hvilke feil som oppstår, er vi avhengige av et ferdig produkt for å kunne teste disse egenskapene.

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability Vi antar at vi klarer å finne roten til feilen vi finner, for så å løse dette problemet. I realiteten er det sannsynlig at vi kommer til å skape nye tilstander i systemet som vi på forhånd ikke hadde forventet. Disse tilstandene kan forårsake at uoppdagede feil får konsekvenser for systemet. Vi ønsker i denne prosessen å redusere sannsynligheten for at feil skal oppstå, men på kort sikt kan vi risikere at sannsynligheten øker når vi retter våre feil.  

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability Vi kan overvåke et system og registrere lengden av feilfrie tidsperioder for å kontrollere utviklingen med hensyn til pålitelighet. Vi kan da bygge opp en tabell, graf, eller liknende for å illustrere dette. Det vi da ofte vil oppdage er at vi også sent i utviklingsprosessen vil ha perioder med veldig lav pålitelighet. Dette skyldes bla. de nye tilstandene som oppstår ved retting av enkelte feil.

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability   Selv om disse dataene kan gi oss en viss ide om påliteligheten til systemet, er det for mange usikkerheter i luften til at vi kan forutse hvor lang neste feilfrie periode er. Disse usikkerhetene kan deles inn i kategorier

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability type-1 unsertainty Dette er vår usikkerhet angående hvordan systemet kommer til å bli brukt. Vi vet ikke nøyaktig hvilke input som blir sendt til systemet, og i hvilken rekkefølge de kommer. Selv om vi hadde hatt en komplett oversikt over de ulike feilene i systemet så ville vi ikke hatt anledning til å finne ut hvilken feil som kom til å gjøre seg gjeldende, og når dette ville skje.

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability type-2 unsertainty Denne kommer av vår manglende evne til å se hvilke konsekvenser fjerning av feil fører med seg. Når vi har fikset en feil, er vi ikke sikkre på at vi gjorde dette fullstendig og riktig. Vi vet heller ikke hvor mye dette kommer til å øke påliteligheten.  

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability Time to failure kan noteres slik: t1, t2, t3, t4, t5, ..., t i – 1 Gjennomsnittet av disse tidene kalles mean time to failure (MTTF). Vi kan uttrykke påliteligheten (reliability) med følgende formel: R = MTTF / ( 1 + MTTF )

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability Når en feil opppstår taper vi tid på at feilen må lokaliseres og fikses. Gjennomsnittet av disse tidene kaller vi Mean Time to Repair (MTTR).

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability Vi måler tilgjengeligheten ved å finne Mean Time between Failures (MTBF). Denne finner vi slik: MTBF = MTTF + MTTR For å presentere dette som et tall mellom 0 og 1, bruker vi formelen: A = MTBF / ( 1 + MTBF )

Reliability, Availability, Maintainability Software Engineering Gruppe 8 Reliability, Availability, Maintainability Når noe er vedlikeholdbart ønsker vi å redusere MTTR. Vi bruker derfor formelen: M = 1 / ( 1 + MTTR )

Reliability Stability and Growth Software Engineering Gruppe 8 Software Engineering Gruppe 8 Reliability Stability and Growth Måle pålitelighet Forbedring i programvare? Mindre feil? Interfailure times Uendret  reliability stability Øker  reliability growth

Reliability Stability and Growth Software Engineering Gruppe 8 Software Engineering Gruppe 8 Reliability Stability and Growth Vanskelig å forutse feil i system Forskjell mellom hardware og software Feil i hardware Kan ikke si nøyaktig når feil i hardware vil inntreffe Men kan si noe om sannsynligheten innenfor et gitt tidsrom

Reliability Stability and Growth Software Engineering Gruppe 8 Reliability Stability and Growth Eksempel: bildekk Slites ut i gjennomsnitt etter 10 år Hva med feil-sannsynligheten? Går ikke fra 0 til 1 over natten Starter på 0 når dekket er nytt Endrer seg sakte mot 1 etter hvert som det nærmer seg 10 års bruk

Reliability Stability and Growth Software Engineering Gruppe 8 Reliability Stability and Growth Kan visualisere økende sannsynlighet ved å tegne en graf Formen på kurven avhenger av: Dekkmateriale Design Type kjøring Vekt av bil Feil sannsynlighet 1 5 10 Tid (år)

Reliability Stability and Growth Software Engineering Gruppe 8 Reliability Stability and Growth Benytter samme fremgangsmåte ved modellering av programvare-svikt Definerer en probability density function, f av tiden t, f(t) Beskriver når programvaren sannsynligvis vil feile

Reliability Stability and Growth Software Engineering Gruppe 8 Reliability Stability and Growth Eksempel: feil i del av programvare Vil feile innen 24 timer Fordi man til slutt vil få en buffer overflow Kan inntreffe i hvilket som helst 1-times intervall i løpet av disse 24 timene

Reliability Stability and Growth Software Engineering Gruppe 8 Reliability Stability and Growth 24 timer = 86400 sekunder Probability density function blir da: 1/86400 for hver t mellom 0 og 86400 0 for hver t større enn 86400 Sannsynlighet f(t) Uniform i intervallet 0 < t < 86400 1/86400 86400 t (tid i sekunder)

Reliability Stability and Growth Software Engineering Gruppe 8 Reliability Stability and Growth Ikke hver funksjon er uniform Hvordan fange feilene i en passende funksjon? Funksjon f(t), tidsintervall [t1, t2] sannsynligheten for feil mellom t1 og t2 blir integralet t1 t2 Sannsynlighet Tid

Reliability Prediction Software Engineering Gruppe 8 Reliability Prediction Bygge modeller for pålitelighet Bruke tidligere informasjon om feil i systemer Eksempel: interfailure times tabell Forutse når neste feil vil inntreffe Gj.snitt av to foregående  finne tredje

Reliability Prediction Software Engineering Gruppe 8 Reliability Prediction Ser av tabellen at t2 = 30 og t3 = 113 Forutser at tid til neste feil blir: T4 = (t2 + t3)/2 = 143/2 = 71.5 Fortsetter beregning for hver observasjon: for i = 5, man har t3 = 113 og t4 = 81, og T5 blir da 97 for i = 6, man har t4 = 81 og t5 = 115, og T6 blir da 98 for i = 7, man har t5 = 115 og t6 = 9, og T7 blir da 62 osv… Bruker dataene til grafisk å representere predicted mean time to failure. 3 30 113 81 115 9 2 91 112 15

Reliability Prediction Software Engineering Gruppe 8 Reliability Prediction Mer sofistikerte pålitelighetsmodeller Noen modeller antar at endringer i hvordan systemet oppfører seg er den samme uansett hva slags feil som blir rettet opp Andre modeller gjenkjenner at feil er ulike, effekten av retting også

Reliability Prediction Software Engineering Gruppe 8 Reliability Prediction Gode pålitelighetsmodeller tar for seg begge typer usikkerhet om pålitelighet type-1 og type-2 usikkerhet Man differensierer pålitelighetsmodeller ved måten de behandler type-2 usikkerhet

Reliability Prediction Software Engineering Gruppe 8 Reliability Prediction Jelinski-Moranda modellen Første, mest kjente pålitelighetsmodellen Antar at det ikke finnes type-2 usikkerhet Allment brukte Musa modellen er basert på Jelinski-Moranda Littlewood modellen Mer realistisk enn Jelinski-Moranda Behandler hver opprettede feil’s bidrag til pålitelighet som en uavhengig vilkårlig variabel Bruker 2 kilder av usikkerhet; dobbelt stokastisk