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

Reliability, Availability and Maintainability

  • Upload
    zurina

  • View
    203

  • Download
    8

Embed Size (px)

DESCRIPTION

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. Software Engineering. Gruppe 8. Reliability , Availability, Maintainability. En bil er pålitelig dersom: - PowerPoint PPT Presentation

Citation preview

Page 1: Reliability, Availability and Maintainability

Reliability, Availability and Maintainability

Software Engineering

Gruppe 8

Hege K. JohansenHerman Kolås

Marianne E. AtesTom Vidar Lunde

Marit FindenJonas Lillevold

André Johansen

Page 2: Reliability, Availability and Maintainability

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.

Software Engineering

Gruppe 8

Page 3: Reliability, Availability and Maintainability

Reliability, Availability, Maintainability

En bil er tilgjengelig dersom: - du kan bruke den når du trenger den.

Software Engineering

Gruppe 8

Page 4: Reliability, Availability and Maintainability

Reliability, Availability, Maintainability

En bil er vedlikeholdbar dersom: - Det er lett å skaffe reservedeler

- Det som regel går an å reparere den Raskt

Software Engineering

Gruppe 8

Page 5: Reliability, Availability and Maintainability

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.

Software Engineering

Gruppe 8

Page 6: Reliability, Availability and Maintainability

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.

Software Engineering

Gruppe 8

Page 7: Reliability, Availability and Maintainability

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.

Software Engineering

Gruppe 8

Page 8: Reliability, Availability and Maintainability

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.

Software Engineering

Gruppe 8

Page 9: Reliability, Availability and Maintainability

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.

Software Engineering

Gruppe 8

Page 10: Reliability, Availability and Maintainability

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.

Software Engineering

Gruppe 8

Page 11: Reliability, Availability and Maintainability

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.

 

Software Engineering

Gruppe 8

Page 12: Reliability, Availability and Maintainability

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.

Software Engineering

Gruppe 8

Page 13: Reliability, Availability and Maintainability

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

Software Engineering

Gruppe 8

Page 14: Reliability, Availability and Maintainability

Reliability, Availability, Maintainability

type-1 unsertaintyDette 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.

Software Engineering

Gruppe 8

Page 15: Reliability, Availability and Maintainability

Reliability, Availability, Maintainability

type-2 unsertaintyDenne 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.

 

Software Engineering

Gruppe 8

Page 16: Reliability, Availability and Maintainability

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 )

Software Engineering

Gruppe 8

Page 17: Reliability, Availability and Maintainability

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

Software Engineering

Gruppe 8

Page 18: Reliability, Availability and Maintainability

Reliability, Availability, Maintainability

Vi måler tilgjengeligheten ved å finne Mean Time between Failures (MTBF).Denne finner vi slik:MTBF = MTTF + MTTRFor å presentere dette som et tall mellom 0 og 1, bruker vi formelen:A = MTBF / ( 1 + MTBF )

Software Engineering

Gruppe 8

Page 19: Reliability, Availability and Maintainability

Reliability, Availability, Maintainability

Når noe er vedlikeholdbart ønsker vi å redusereMTTR. Vi bruker derfor formelen:M = 1 / ( 1 + MTTR )

Software Engineering

Gruppe 8

Page 20: Reliability, Availability and Maintainability

Reliability Stability and Growth

• Måle pålitelighet– Forbedring i programvare?– Mindre feil?

• Interfailure times– Uendret reliability stability– Øker reliability growth

Software Engineering

Gruppe 8Software Engineering

Gruppe 8

Page 21: Reliability, Availability and Maintainability

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

Software Engineering

Gruppe 8Software Engineering

Gruppe 8

Page 22: Reliability, Availability and Maintainability

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

Software Engineering

Gruppe 8

Page 23: Reliability, Availability and Maintainability

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

Software Engineering

Gruppe 8

1

05 10

Feil sannsynlighet

Tid (år)

Page 24: Reliability, Availability and Maintainability

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

Software Engineering

Gruppe 8

Page 25: Reliability, Availability and Maintainability

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

Software Engineering

Gruppe 8

Page 26: Reliability, Availability and Maintainability

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

Software Engineering

Gruppe 886400

1/86400

0t (tid i sekunder)

Sannsynlighet f(t)

Uniform i intervallet 0 < t

< 86400

Page 27: Reliability, Availability and Maintainability

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

Software Engineering

Gruppe 8

t1

t2)( dttf

t1 t2

Sannsynlighet

Tid

Page 28: Reliability, Availability and Maintainability

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

Software Engineering

Gruppe 8

Page 29: Reliability, Availability and Maintainability

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

Software Engineering

Gruppe 8

Page 30: Reliability, Availability and Maintainability

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å

Software Engineering

Gruppe 8

Page 31: Reliability, Availability and Maintainability

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

Software Engineering

Gruppe 8

Page 32: Reliability, Availability and Maintainability

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

Software Engineering

Gruppe 8