1 Systemering In 140 forelesning nr. 2 Sommerville kap. 3.

Slides:



Advertisements
Liknende presentasjoner
Hvor stor er en fisk? Yggdrasil Hvor stor er en fisk?  Vanlige kundetyper og prosjekter  Faktorer som påvirker.
Advertisements

Etablering av effektiv produksjon på tvers av landegrenser
Stock Optimiser Beslutningsstøtteverktøy for optimalt reservedelslager
Høgskolen i Oslo - GM Vær metodisk  Definer og forstå problemet  Spesifiser hva du har av hardware  Lag en prototyp av brukersnittet  Design.
Prosjektgjennomføring
Prosjektstyring In 140 Sommerville kap 4.
Meld. St. 18 (2010–2011) En inkluderende skole – hvorfor og hvordan
Grunnleggende spørsmål om naturfag
EKommune-strategi - verkt ø ykasse Ellen Karin Larsen, KS.
Ideutvikling - Problemdefinisjonen. Hva gjør de erfarne problemløserne? •Samler og analyserer informasjon og data •Snakker med mennesker som kjenner problemet.
Levende HMS-system – hva betyr det i praksis?
Introduksjon til in 140 Systemering. In 140 Systemering Forelesninger Rom B137 –Mandag –Onsdag Foreleser: Hans F. Nordhaug Lærebok:
Offentlige anskaffelser 5 Gjennomføring av konkurranser
23. januar 2004TDT4285 Planl&drift IT-syst1 Tjeneroppgraderinger TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI.
Oppgave gjennomgang Kap. 3 og 4.
1 Oppgave gjennomgang Kap Oppgaver -Kap 12: 1, 2, 3, 5, 7, 8, 11, 18, 19.
Grunnleggende testteori
IN320 Statoil Hjemmekontor Gruppe1 1 Statoil Hjemmekontor -Ett Lite Skritt Videre.
Utforming av arkitektur
Prosjektstyring In 140 Sommerville kap 4.
Verifikasjon og validering
Programvare-prosesser
Prototyping In 140 Sommerville kap. 8. Mål Forstå hensikten med prototyping i forskjellige utviklingsprosjekt Forstå forskjellen mellom evolusjonær og.
Systemmodeller In 140 Sommerville kap. 7. Mål Forstå hensikten med kontekstmodell Forstå ideene bak –oppførselsmodellering –datamodellering –objektmodellering.
Objektorientert utforming In 140 Forelesning Nr 13 Sommerville kap 12 – del 2.
Introduksjon til systemutvikling
IKP – basert på risiko- og sårbarhetsvurderinger i egen virksomhet
Bygg og funksjon – å bestille et bygg – roller i en byggeprosess
Som bakteppe i arbeidet ved Voksenhabiliteringstjenesten
Human Factors (HF) i kontrollrom - En revisjonsmetode 2003
Empiriske metoder Oppgaveanalyse, observasjon
Combining Compound Conceptual User Interface Components with Modelling Patterns - a Promising Direction for Model-based Cross-platform User Interface Development.
1 19. januar 2006 TDT4285 Planl&drift IT-syst Om du ønsker, kan du sette inn navn, tittel på foredraget, o.l. her. Forelesning nr 6: Dynamisk dokumentasjon.
Testing av system Gruppe 6 Henrik Bækhus Morten A. Iversen Mathias Bondeson Gunnar K. Kulleseid Svein Ivar Kristiansen Ronny Hulthin.
© Eurokompetanse a.sISO 9000:2000 august 2001 nr. 1.
Konfigurasjonsstyring Configuration Management
CARISMA Context-Aware Reflective Middleware System for Mobile Applications.
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.
N O R P R O F F Quality Management SAMARBEIDSPARTNER FOR
Prosjektledelse In 140 Forelesning Nr 18 a Sommerville kap
Aktivitets-Biblioteket for Verdikjedeprosjekter i
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.
Arkivlederseminar, IKA Kongsberg
Objektorientert utforming In 140 Sommerville kap. 12.
Brukermedvirkning In 140 Forelesning. Historie Skandinaviske tradisjon Sosio-teknisk metode NJMF-prosjektet( ) –Dataavtalen LO-NAF(i dag NHO) –Arbeidsmiljøloven.
Programvareendring del 1 In 140 Forelesning Nr 21 Sommerville kap 27, 1. Del.
Programvare- prosesser - del2 In 140 Forelesning nr. 4 Sommerville kap. 3.
Telenors satsing på fri programvare Paul Skrede - GoOpen 2009.
Med kikkerten for det blinde øyet? Innlegg på nHS’ prosjektledersamling Hallgeir Gammelsæter.
In Forelesning Sommerville kap 4 andre del
Forstudie Nå situasjonen: dagens situasjon med ulemper og fordeler
Gamle systemer In 140 Sommerville kap 26. Forelesninger fremover 8/4:Gamle systemer 22/4: Systemevolusjon og vedlikehold 28/4: Konfigurasjonsstyring.
Gamle systemer In 140 Forelesning Nr 19 Sommerville kap 26.
DRI2001 h05 - Forelesning 21.sept Arild Jansen 1 Systemutviklingsarbeidet – et overblikk DRI2001 forelesning 21. sept. 05 Hva er systemutvikling.
DRI2001 h04 - Forelesning Arild Jansen 1 Systemutviklingsarbeidet – et overblikk DRI2001 forelesning Hva er systemutvikling (SU)
FINF- H -04, 21 september 2004 Arild Jansen. AFIN/UiO 1 FINF Forelesning uke 39 Personvern som premiss for SU-prosessen Diskusjon om personvern som.
FINF- H -05, 13. september 2005 Arild Jansen. AFIN/UiO 1 FINF Forelesning 13.sept Personvern som premiss for SU-prosessen Diskusjon om personvern.
Objektorientert design
Senter for teknologi, innovasjon og kultur (TIK) - Universitetet i Oslo ORGANIZATIONS AND KNOWLEDGE TIK ESST Module 4 Jon Vatnaland.
Objektorientert utforming In 140 Forelesning Nr 11 Sommerville kap 12 – del 1.
Systemmodeller In 140 Forelesning nr. 9 Sommerville kap. 7.
1 Utvikling av kritiske systemer Kort sammendrag Kap. 1 og 2.
Objektorientert design In 140 Sommerville kap 12 – del 1.
Introduksjon til in 140 Systemering. In 140 Systemering Forelesninger Rom 112 –Mandag –Torsdag Lærebok: –Sommerville, Ian. Software.
Programvare-prosesser
Rammer for og organisering av eForvaltningen
12. Organisasjonsutvikling
12. Organisasjonsutvikling
Utskrift av presentasjonen:

1 Systemering In 140 forelesning nr. 2 Sommerville kap. 3

2 Emner n Systemegenskaper n Systemer og miljøet de er i n Systemmodellering n Systemutviklingsprosessen n Innkjøp av it-systemer

3 Introduksjon n SU vil si å spesifisere, utforme, lage, validere, sette i drift og holde vedlike et system i sin helhet. n Ikke bare maskinvare, men helheten av programvare, maskinvare, miljø og brukere - det vi kaller et system n Definisjon: –Et system er en samling av komponenter som arbeider sammen for å nå et mål.

4 Systemer n Komponentene henger tett sammen og er avhengige av hverandre. n Et system kan inneholde et annet system, som inneholder et tredje system. Hierarkisk struktur. n Mer enn summen av delene - systemegenskaper. –Pålitelighet –Brukbarhet –Bi-effekter

5 Systemer forts. n Bør kjenne til systemer fordi programvare er en viktig del av dem (programvaren vil være meningsløse hvis den ikke tilhører en gitt kontekst) –Apollo < 10 MB programvare –Romferga ca 100 MB

6 Systemegenskaper n To hovedtyper –Funksjonelle egenskaper hva du kan utføre med systemet –Ikke-funksjonelle pålitelighet ytelse trygghet sikkerhet n Ikke-funksjonelle er vanskelige å få tak på.

7 Systemomgivelser n Forhold til andre systemer n Systemet kan virke på omgivelsene. n Omgivelsene kan virke på systemet. n Organisatorisk miljø –faktorer som påvirker: Prosessendring Forandring av jobbinnhold Organisatoriske endringer Makt/innflytelse n Hvordan skal man forholde seg til omgivelsene? –Omgivelsene tilpasse seg til systemet eller systemet til omgivelsene?

8 Systemmodellering n Blokkdiagram med de største undersystemene og koblingen mellom dem pluss kort beskrivelse. Eksempel Innløps-ventil Trommelmotor Varme-elementUtpumpe ProgramvelgerTemperaturvelgerTemperatur-føler Dørføler Nivåføler Styringsenhet

9 Funksjonelle systemkomponenter n Kan klassifiseres som: –Sensorkomponenter –Aktuatorkomponenter –Behandlingskomponenter –Kommunikasjonskomponenter –Koordineringskomponenter –Grensesnittkomponenter n Hver komponent kan inneholde programvare n De fleste typene finnes i alle systemer.

10 S ystemutviklingsprosessen n Trinnene: –Kravspesifikasjon –Systemutforming –Undersystemutforming –Systemintegrasjon –Systeminstallasjon –Systemevolusjon –Systemkassering n Tverrfaglig aktivitet n Mange kompromisser - mye løses i software

11 Systemkravspesifikasjon n Finne kravene for systemet som helhet gjennom kontakt med kunde og sluttbrukere –Abstrakt funksjonell –Ikke funksjonelle systemegenskaper –Uønskede egenskaper n Hva er hensikten heller enn hvilke funksjoner n Som oftest ulike meninger mellom sluttbrukere om krav til systemet

12 Systemutforming n Hvordan skape den ønskede funksjonalitet gjennom komponentene systemet skal bygges av. –Del opp kravene –Identifiser subsystemer –Fordel krav på subsystemer –Spesifiser subsystemfunksjonalitet –Definer subsystemgrensesnitt –Iterativ prosess –Mange mulige løsninger –Politikk

13 Undersystemutvikling n Lage de spesifiserte undersystemene n En blanding av hyllevare og egenutviklede komponenter n Hyllevare –Er det andre som har samme problem? Hvis JA=>Stor mulighet for at det finnes løsninger på markedet –Systemtilpasning er ofte nødvendig.

14 Systemintegrering n Innebærer å sette undersystemene sammen n Inkrementell (skrittvis) integrasjon er bedre enn Big Bang. –alt er ikke ferdig samtidig –lettere å finne feil n Feil oppstår pga undersystemene ikke passer sammen –Vanskeligheter med undersystemer fra forskjellige leverandører –Versjonshåndtering

15 Systeminstallasjon n Mange mulige problemer –Miljøet avviker fra forutsetningene –Potensielle brukere kan være mot systemet. –Parallellkjøring –Fysiske problemer

16 Drift n Etter installasjon - drift n Kontinuerlig læring er nødvendig (forskjell på læring og opplæring) n Endring av arbeidsprosesser n Brukes ikke som forutsatt

17 Vedlikehold (evolusjon) n Store og komplekse system - langt liv n evolusjon for å –rette feil –tilpasses til nye krav –ta del i øket maskinvarekapasitet –tilpasses reorganisering –endringer I omgivelsene

18 Vedlikehold forts n Kostbart fordi –nøye vurdering av endringsforslag. –en endring kan føre til andre endringer i andre subsystem. –utformingsavgjørelser er glemt. –strukturen blir dårligere for hver endring; nye endringer enda vanskeligere. –vedlikeholderne trenger tid for å forstå hvordan systemet henger sammen og kan endres.

19 Systemkassering n Noen undersystem kan brukes videre n Overføring av data til nytt system –Kan være kostbart n Sensitiv informasjon n Arkivering (Historisk dokumentasjon) n Sletting av data

20 Innkjøp av IT-systemer n Kan kjøpes –ferdig –subsystemer eller utvikles i egen organisasjon n Beslutningen er vanskelig og kan ta lang tid n Tett knyttet til systemutviklingsprosessen –For å kjøpe eller få bygd systemet, trengs en spesifikasjon –Hyllevaresystemer ofte økonomisk. Disse må identifiseres.

21 Innkjøp forts n Software er “lim” - limvare (glueware) –Limet koster også penger... mindre å spare på hyllevare –COTS passer sjelden kravene Finn det nærmeste Tilpass kravene... konsekvenser? –Skreddersydde systemer Kravspesifikasjon er kontraktsgrunnlag I en fase etter kontraktsinngåelse kan krav endres, men endringspris må avtales. –Bruk av underleverandører

22 Sammendrag n Systemutvikling er komplisert og tverrfaglig n Systemegengskapene gjelder systemet som helhet –ytelse,sikkerhet, trygghet, brukbarhet n Systemarkitekturen beskrives med blokkdiagrammer n Funksjonelle komponenter er sensorer, aktuatorer, beregnings-, koordinasjons-, kommunikasjons- og grensesnittkomponenter n Systemutviklingsprosessen inneholder spesifikasjon, utforming, utvikling, integrasjon og testing. Systemintegrasjonen er spesielt kritisk. n Anskaffelse av IT-systemer består av spesifisering, anbudsinnbydelse, valg av leverandør og kontraktsinngåelse. COTS inngår normalt.