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.

Slides:



Advertisements
Liknende presentasjoner
Risiko Sannsynlighetsgradering:1 = Lite sannsynlig (kan inntreffe mindre enn én gang hvert 100. år) 2 = Mindre sannsynlig (kan inntreffe mellom én gang.
Advertisements

IK-Bygg på web: Formål IK-Bygg web skal bidra til å avdekke avvik i forhold til helse, miljø og sikkerhet. Det stilles strenge krav til hvilken forfatning.
Etterlevelse - Arbeidstillatelse
Krav til dokumentasjon i kap
Praktisk info til prosjektkunder
Stock Optimiser Beslutningsstøtteverktøy for optimalt reservedelslager
- Avslutningsseminar prosjekt Fallende gjenstander
Risikovurdering Systematisk HMS – arbeid dreier seg om mestring av risiko, for å unngå skader og sykdom Mestring av risiko- redusere eller fjerne.
Reliability, Availability and Maintainability
Dokumentasjon og Planlegging av større IT-prosjekter
Hva trenger jeg av data, og hvordan skal jeg innhente disse?
Forbedringsprosjektet
Levende HMS-system – hva betyr det i praksis?
Konsekvenser ved samlokalisering av IKT-systemer
Risiko Sannsynlighetsgradering:1 = Lite sannsynlig (kan inntreffe mindre enn én gang hvert 100. år) 2 = Mindre sannsynlig (kan inntreffe mellom én gang.
Eksempel AOA (Activity On Arc)
Transformasjoner Men hva hvis relasjonen er kurvelinjær?
FUNNKe Risikovurdering informasjonssikkerhet Nettverksmøte Tromsø 10. okt Eva Henriksen, Eva Skipenes,
Oppgave gjennomgang Kap. 5 og 6.
Oppgave gjennomgang Kap. 3 og 4.
Risk identification Risk analysis
Skisse til løsningsforslag
1 Oppgave gjennomgang Kap Oppgaver -Kap 12: 1, 2, 3, 5, 7, 8, 11, 18, 19.
Skisse til løsningsforslag
Grunnleggende testteori
Verifikasjon og validering
Prototyping In 140 Sommerville kap. 8. Mål Forstå hensikten med prototyping i forskjellige utviklingsprosjekt Forstå forskjellen mellom evolusjonær og.
1 KravprosessenKravprosessen Noen sentral punkter.
Kravanalyse og spesifikasjon
IKP – basert på risiko- og sårbarhetsvurderinger i egen virksomhet
Konstruksjoners sikkerhet
Oppgaver 1)Vi anser hvert av de seks utfallene på en terning for å være like sannsynlig og at to ulike terningkast er uavhengige. a)Hva er sannsynligheten.
Human Factors (HF) i kontrollrom - En revisjonsmetode 2003
Tidligere eksamensspørsmål
Riktig kvalitet i leveransene kommer ikke av seg selv Ellen D. Varsi – Lyntale til Smidig 2010.
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.
DEKOMPONERING OG MODULARITET ~Gruppe 4~. Gjennomgang Designtyper/kriterier innen dekomponering Dekomponeringsspesifikasjon Strukturert og objektorientert.
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
Kvalitetssikring av byggeprosjekt – del 4
Risikostyringsprosessen
Foreløpig oppsummering etter tilsyn med styring av vedlikehold
CAKE session no. 7 Skader på hender og fingrer. Siden sist … Vi har nylig avsluttet vår stille avvik-serie, og vi er fornøyde med både form og innhold.
Retningslinjer for spesifikasjoner til oppdrag
Risikostyring i praksis
Page 1 WE MOVE THE INDUSTRY THAT MOVES THE WORLD RISK MANAGEMENT Fra operatørenes ståsted Solakonferansen 2014 Øivind Solberg, PhD.
N O R P R O F F Quality Management SAMARBEIDSPARTNER FOR
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.
1 Systemering In 140 forelesning nr. 2 Sommerville kap. 3.
Veiledning kvalitetssikring
Forskning – 3 grupper (OECD 1981) Grunnforskning Originale undersøkelser som har til hensikt å skape ny kunnskap og forståelse Karakteriseres ved at den.
Hypotesetesting, og kontinuerlige stokastiske variable
Veiledning Beslutningsprosess
Beredskap Risikohåndtering, kontinuitets- og katastrofeplaner.
1 Utvikling av kritiske systemer Kort sammendrag Kap. 1 og 2.
1 Utvikling av kritiske systemer Introduksjon Kap. 1 og 2 i Storey.
Hasardidentifikasjon
1 Feiltolerant programvare Hvordan få systemet til å fungere selv om det finnes ”faults”? Kap 6, Storey.
Definisjon av ulike HMS-begreper
Kvalitetssikring. er alle tiltak som er nødvendig for å sikre at et produkt vil tilfredsstille angitte krav til kvalitet og trygghet Kvalitetsarbeid krever.
ROS-analyse.
Fiskerisimulator i praksis FishTech 2016, Ålesund Olav Sjøvik Sjøvik AS.
En gjennomgang av grunnleggende begreper innen verdivurdering og ROS for IKT-løsninger Seksjon for Arkitektur og sikkerhet v / Espen Vaager Verdivurdering.
Kvalitet, risiko og avvik
CAKE Q2 Dønn tilstede/ TOTAL Awareness
Utskrift av presentasjonen:

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

3 Svar på spørsmål 1.5, 1.6 og 1.7 5) Mulige eksempler kan være: –Vaskemaskin –Mikrobølgeovn –Stekeovn –Toaster –Kaffetrakter – etc. 6) Safety: En egenskap et system har til ikke å medføre skade for mennesker eller miljø. 7) Safety-critical/safety-related system: Et system som har til å oppgave å sørge for safety.

4 Svar på spørsmål 1.10 og ) Hasardanalyse benyttes til å identifisere måter et system kan gjøre skade på mennesker og miljø. Risikoanalyse benyttes til å vurdere viktigheten av disse hasardene. 12) Primary safety: farer direkte forårsaket av datasystemets hardware. Functional safety: dekker aspekter som vedrører utstyr som direkte kontrolleres av datasystemet og er relatert til korrekt funksjonering av dataens hardware og software. Indirect safety: relatert til indirekte konsekvenser av data feil eller produksjon av uriktig informasjon.

5 Svar på spørsmål 1.16 og ) Kompleksitet gjør det vanskelig for en designer å betrakte alle egenskapene til systemet som designes og gjør det derfor mer sannsynlig for at feil lages. Det gjør det også vanskeligere å oppdage feil under testing, og det er derfor sannsynlig at flere feil ikke blir oppdaget. 22) Verifikasjon prøver å vise at et system stemmer overens med spesifikasjonen sin. Dette foretas vanligvis på modul nivå, og viser at hver modul utfører sin spesifiserte funksjon. Validering derimot prøver å avgjøre om et system i sin helhet møter brukerens krav. Validering inkluderer derfor også en betraktning om spesifikasjonen i seg selv er korrekt.

6 Svar på spørsmål ) Fault: defekt i et system Error: avvik fra forventet oppførsel i system eller sub- system. System failure: Systemet i sin helhet utfører ikke forventet funksjon. Resultatet av en programmerers bug kalles en hvilende fault. Ved aktivering av softwaren der bug’en befinner seg kan fault’en bli aktiv og produsere en error. Dvs et avvik fra forventet oppførsel. Hvis error’en medfører at systemet i sin helhet ikke utfører sin forventede funksjon sier vi at en failure har inntruffet.

7 Svar på spørsmål 2.2 2) Pålitelighet (reliability): Sannsynligheten for at system vil fungere tilfredsstillende over en gitt tidsperiode og under gitte forhold. Varierer med tiden siden sannsynligheten for at et system fungerer korrekt for en måned vil være større en sannsynligheten for at det samme systemet fungerer korrekt for et år. Pålitelighet er svært viktig der kontinuerlige, uavbrutte operasjoner kreves og hvor vedlikehold er vanskelig og dyrt. - eks: rakett kontollsystemer

8 Svar på spørsmål 2.6 og ) Integritet (integrity): et systems evne til å oppdage og rapportere feil. Spesielt viktig for kritiske systemer som er utstyrt med failsafe tilstander, eks: -nuklære shutdown systemer -landesystemer for fly. 10) Dependability: egenskap til et system som gjør at vi kan ha tillit til at systemet fungerer etter intensjonen. Dependability benyttes ofte som et samlebegrep for safety, pålitelighet, tilgjengelighet, integritet, vedlikeholdbarhet og konfidensialitet.

9 Svar på spørsmål 2.12, 2.13 og ) Safety og pålitelighet setter motstridende krav til et system. For eksempel vil et system med en failsafe tilstand garantere safety, men et slikt system vil ha pålitelighet lik null. 13) Hasard: hendelse/situasjon som potensielt kan medføre skade på mennesker eller miljø. –Eks: muligheten for å bli utsatt for bilkollisjon, lynnedslag, flystyrt. 14) En risiko assosiert med en hasard karakteriseres ved sannsynligheten for at hendelsen skal inntreffe og dens sannsynlige konsekvenser.

10 Svar på spørsmål ) Et safety case er et dokument som legger frem en safety begrunnelse av et system. Dette beskriver design og utviklingsteknikker som er benyttet i utviklingen av systemet.