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 inn i RUP Hjelpe utviklere og kunder / brukere til å kommunisere bedre om systemrisiko Gi en demonstrerbar gevinst for utviklingsbedriften

Kommunikasjon For å fremme kommunikasjon er det viktig at de metodene vi bruker Er enkle å bruke Gjør at kunde og utvikler kan etablere –en felles forståelse av problemene –et felles sett av begreper for å snakke om risiko og sikkerhet Kan brukes tidlig i utviklingsprosessen

Tidlige faser - 1 Problemer rundt risiko / farer må introduseres tidlig i prosessen. Vi må vise tre ting samtidig: At det finnes farer At det er mulig å gjøre noe med de At vi har løsninger som kostnadseffektive

Tidlige faser - 2 Starter ofte med en ide / et konsept: Problem – relatert til kundegruppe. Dette vil gi oss: –overordna funksjonalitet –Systemomgivelser Løsning – et datasystem Dette er tilstrekkelig for å gjennomføre en grovanalyse eller en preliminær HazOp

UML Det er en økende interesse for koblingen risiko / sikkerhet og UML. Vi bør se på metoder som Passer sammen med use case diagrammer og sekvensdiagrammer Kan brukes til å beskrive og analysere scenarier – ”Hva skjer viss…”

UML – Use Case Use case og HazOp: Enkel teknikk som kan brukes tidlig i utviklingsprosessen. Utviklerne kan identifisere problemer sammen med kunden. –skape tillit. –vise interesse for kundens problemer. –vise hvordan utviklingsfirmaet kan gi en trygg løsning.

UML - Sekvensdiagrammer Sekvensdiagrammer og FMEA Fokus på meldingsutveksling i overordna scenarier. Analysere –Mulige feilmoder for hvert objekt. –Konsekvensen av feilmoden på totalsystemet. Dette kan hjelpe oss til å identifisere behov for barrierer

UML – klassediagrammer Klassediagrammer og FMEA. Fokus på metodene i klassene. For hver enkelt metode: Hvilke feilmoder har den Hva blir konsekvensene for systemet Hva kan vi gjøre for å fjerne feilmoden eller konsekvensen

CRC kort Dersom CRC kort blir brukt er dette en god anledning til å gjøre sikkerhetsanalyser. Vi kan ta utgangspunkt i hver klasses ansvar og samarbeid for deretter å spørre: Hva skjer viss vi får en feil i en klasse som denne klassen er avhengig av? Hva skjer viss denne klassen ikke leverer sine tjenester?

RUP - 1 Det vi gjør må passe inn i RUPs måte å tenke prosjektgjennomføring på. Iterativ utvikling Kontroll over kravprosessen Komponentbasert arkitektur Visuelle modeller Kontinuerlig verifisering av kvalitet Kontroll over endringsprosessen

RUP - 2 Vi må Huske på at i noen tilfeller sier bedriftene RUP når de egentlig mener UML. Være åpne og unngå en streng tolking av hva som er / ikke er RUP. Selv om vi fokuserer på RUP, må det vi tilbyr også kunde brukes i andre prosesser.

Et produkt i endring RUP konsepter – iterasjoner, kontinuerlig verifisering og endringskontroll. Våre utfordring - å lage metoder som det er: Enkelt å lære Enkelt å gjennomføre iterativt Enkelt å lage støtte til – maler, sjekklister, enkle verktøy

Komponentbasert utvikling FMEA passer godt for komponenter. Vi trenger støtte for å Se komponentene og systemarkitektur i sammenheng. Identifisere feilmoder Vurdere konsekvenser på systemnivå. Identifisere mulige, praktiske barrierer.

Visuelle modeller Visuelle modeller i sikkerhetsanalyse: Feiltrær (FTA) Hendelsestrær (ET) Årsak – virkningsanalyse (CCA) Praktisk erfaring indikerer at folk oppfatter info i form av bilder lettere enn info i form av tekst.

Feiltrær - FTA God grafisk notasjon. Kan inkludere programvare, prosedyrer, mennesker osv. på en enkel måte. Gir en god oversikt over problemene. Kan analyseres kvalitativt og kvalitativt. Usikker på hvor lett det er å få utviklere og kunder til å forstå notasjonen.

Hendelsestrær - ET Enkel og intuitiv metode. Viser hvor vi kan sette inn barrierer. Kan analyseres kvalitativt og kvantitativt. Lett å lese og lett å lage. Kan konstrueres ved å ta utgangspunkt i scenarier. Kan derfor lett kombineres med use case diagrammer og sekvensdiagrammer.

Årsak – virkningsanalyse - CCA Stor og ganske kompleks notasjon som kombinerer hendelsestrær, feiltrær og modellering av tid. Kraftig verktøy for å analysere komplekse og parallelle hendelsesforløp. Vanskelig å lære bort til utviklere og kunder.

Demonstrere gevinst Det er flere områder der vi har muligheter for å vise gevinst: Bedre prosjektgjennomføring –raskere –billigere Kundetilfredshet – mer fornøyde kunder Markedsføring – nye kunder

Bedre prosjektgjennomføring Salgsargumenter: Bedre oversikt over produktrisiko gir bedre kontroll over krav og testing Identifisering av behov for barrierer og ”wrapping” gir mindre behov for å reparere på koden etter som vi eller kunden oppdager problemer

Kundetilfredshet Vi kan bidra til økt kundetilfredshet ved å vise kunden at: Vi tar hans problemer på alvor Han har problemer og at vi kan gjøre noe med de på hans premisser. Han får et sikrere system

Markedsføring Utviklingsbedriften kan bruke resultatene fra BUCS i sin markedsføring ved å legge vekt på: Kundens behovet for risikoanalyse. Sine egne kunnskaper om risikoanalyse. At de har metoder og verktøy som lar utviklere og kunder sammen løse risikorelaterte problemer.