Kap. 10 Systemutvikling System Engineering



Like dokumenter
Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner

Presentasjon 1, Requirement engineering process

Tom Røise 18. Februar 2009

Systemutvikling (Software Engineering) Professor Alf Inge Wang

Model Driven Architecture (MDA) Interpretasjon og kritikk

Tom Røise IMT 2243 : Systemutvikling 1. Forelesning IMT Mars Designfasen i SU-prosjekter : Generelle steg i Designprosessen

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

Dagens. Faglærers bakgrunn IMT 1321 IT-LEDELSE. Faglærer : Tom Røise 11.Jan IMT1321 IT-Ledelse 1

Distributed object architecture

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise IMT2243 : Systemutvikling 1

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted.

Jernbaneverkets erfaringer med implementering av RAMS

Livsløpstesting av IT-systemer

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren Testrapport

Tom Røise IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar Klassediagrammet. Klasse

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Lykke til! Eksamen i fag TDT4140 Systemutvikling NTNU Norges teknisk-naturvitenskapelige universitet

21. Objektorientert Analyse (OOA) Kap. 21 Objektorientert Analyse (OOA)

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Funksjonalitet og oppbygning av et OS (og litt mer om Linux)

Systemarkitektur. INF1050: Gjennomgang, uke 07

Technical Integration Architecture Teknisk integrasjonsarkitektur

Sikkerhet, risikoanalyse og testing: Begrepsmessig avklaring

INF3430/4431. VHDL byggeblokker og testbenker

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise IMT2243 : Systemutvikling 1

SPIRIT OF INNOVATION NY PLATTFORM FOR INFORMASJONSSTØTTE PÅ BRO RUNE VOLDEN ULSTEIN POWER & CONTROL AS

Læringsmål og pensum. Utvikling av informasjonssystemer. Oversikt. Systemutvikling Systemutvikling i seks faser Femstegs prosedyre for programmering

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO

Oppsummering. Thomas Lohne Aanes Thomas Amble

Kap. 11 Analysemodeller og -prinsipper Analysis Concepts and principles

BUSINESS SERVICE MANAGEMENT

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11

Kravspesifikasjon med UML use case modellering. Erik Arisholm

Kvalitet og programvare. Når bare det beste er godt nok. Produktet prosessen eller begge deler?

CORBA Component Model (CCM)

Eksamen INF

STE6221 Sanntidssystemer Løsningsforslag

Referansearkitektur use cases. Kjell Sand SINTEF Energi AS NTNU Institutt for elkraftteknikk

Hvordan komme i gang med ArchiMate? Det første modelleringsspråket som gjør TOGAF Praktisk

Generelt om operativsystemer

Klargjøring av begreper

Programvare arkitekturer

SIE 4005, 9/10 (4. Forelesn.)

Frokostseminar for arkitektfaget SAMSPILL MELLOM BYGG OG TERRENG - GIS-BIM 9. juni 2010

Kapittel 7 & 8. Kravspesifikasjoner & Data design. Thomas Tjøstheim og Thomas Edvinsen. 20 September Kapittel 7 & 8 p.1/20

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

IT-ledelse 25.jan - Dagens

Er Noark 5 og Datakvalitet det neste steget for depot? Thomas Sødring thomas.sodring@jbi.hio.no /

Team2 Requirements & Design Document Værsystem

Ny generasjon PC-basert styring fra Siemens. SIMATIC S Software Controller

INF 5120 Obligatorisk oppgave Nr 2

Requirement Engineering Process

Statisk testing. Testing uten datamaskin, men med vår egen evne til å vurdere og analysere

Automatisering av datasenteret

API: Application programming interface, eller programmeringsgrensesnitt

ARK 2014 Arkitekturfaget - observasjon fra en tjenesteleverandør

Forprosjekt. Oppgavens tittel: Motorstyring Dato: Jon Digernes Institutt/studieretning: Program for elektro og datateknikk

Systemutvikling (Software Engineering) TDT 4110 IT Grunnkurs Professor Guttorm Sindre

Kap. 12 Analysemodellering (Analysis Modeling)

TDT4160 Datamaskiner Grunnkurs Gunnar Tufte

Agenda. TDT4140: Kravinnhenting. Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav. Den organisatoriske dimensjonen

Håndtering av minne i et OS

DRI2001 h04 - Forelesning Systemutvikling og nettsteder

Helhetlig integrasjonsplattform. Per Olav Nymo

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

Programvareutvikling (store systemer)

En kravspesifikasjon skal være så konkret og detaljert at det er mulig å teste det ferdige produkt/system opp mot store deler av denne.

Prosessmodell. Hurtigguider - rammeverk Sist redigert Snorre Fossland Eier og driver Snorres Modellbyrå

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING

Hvordan bedømmer Gartner de lange linjene?

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

PETROMAKS & Integrerte Operasjoner. Rådgiver Tor-Petter Johnsen, PETROMAKS

Internasjonale trender og utvikling av programvare Arild Larsen, Unitech Power Systems AS

LÆREPLAN I PROSJEKT TIL FORDYPNING FOR VG1 ELEKTROFAG

Konfigurasjonsstyring

A Study of Industrial, Component-Based Development, Ericsson

INF5120 Oblig 2 - Timeregistreringssystem Gruppe 25 Annette Kristin Levine Nils-Kristian Liborg Unni Nyhamar Hinkel

Arkitektur. Kirsten Ribu Høgskolen i Oslo

Kjenn din PC (Windows7)

Datasystemer og informasjonssystemer

Forslag til løsning. Oppgave 1

Innhold Forord...3 Begreper og akronymer...4 Systembeskrivelse...5 Generelt...5 Funksjonelle krav...7 Ikke-Funksjonelle krav...9 Prioritering...

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

Hva er en kø? En lineær datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn først

// PRESENTASJONER FRA NJAVA

Installasjon av OneStop Reporting Produktene på Terminalserver

Nye krav i ISO 9001, hvilke er de og hvordan implementere disse i TQM? Ragna Karoline Aasen

Transkript:

Kap. 10 Systemutvikling System Engineering - Utvikling og integrering av både maskin- og programvare. - Hvordan oppstår behov for programvare? - Hvordan inngår programvare i en sammenheng med andre (del)systemer, maskinvare og personell? 10. Introduksjon Systemutvikling oppstår som en konsekvens av en prosess kalt system engineering (systemutvikling/systemering). Systemutvikling fokuserer på et mangfold av elementer: Analyse, konstruksjon og organisering av disse elementene til et system som kan være: - et produkt, en tjeneste, eller en teknologi for å behandle informasjon eller kontroll. Systemutvikling Kap. 10 Systemutvikling 1 Systemutvikling Kap. 10 Systemutvikling 2 10. Introduksjon Systemutviklingsprosessen kalles information engineering når sammenhengen er forretningsvirksomhet. Når det skal produseres (bygges) et produkt, kalles prosessen product engineering (produktutvikling/produktkonstruksjon). Begge sørger for å integrere programvare til de andre elementene i et datamaskinbasert system. 10.1 Datamaskinbaserte systemer Definisjon av system (Webster): 1. En mengde eller arrangement av ting som er relatert til hverandre slik at de danner en enhet eller organisatorisk helhet. 2. En mengde fakta, prinsipper, regler, etc. klassifisert og arrangert i en ordnet form slik at det viser en logisk plan som forbinder de forskjellige delene. 3. En metode eller plan for klassifisering eller arrangering (ordning). 4. En etablert måte å gjøre noe på, en metode eller prosedyre. Systemutvikling Kap. 10 Systemutvikling 3 Systemutvikling Kap. 10 Systemutvikling 4 10.1 Datamaskinbaserte systemer -2 Datamaskinbasert system (Computerbased system, Webster): Et sett eller arrangement av elementer som er organisert for å oppnå en metode, prosedyre eller kontroll ved å behandle informasjon (prosessere info). Programvare (software): Programmer, datastrukturer og dokumentasjon som skal effektivisere den logiske metoden, prosedyren eller kontroll som kreves. Maskinvare: Elektroniske enheter (CPU, RAM...) som har prosesseringskapasitet, elektromekaniske enheter (sensorer, motorer, pumper..) som gir funksjoner til den eksterne verden. 10.1 Datamaskinbaserte systemer -3 Personell: Brukere og operatører av maskin og programvare. Database: En organisert samling av informasjon som aksesseres via programvare og er en integrert del av systemfunksjonen. Dokumentasjon: Manualer, formularer (skjema) og annen informasjon som beskriver bruk eller operasjon av systemet. Prosedyrer: Stegene som definerer den spesifikke bruk av hvert systemelement, eller den prosedyremessige sammenheng som systemet er i. Elementene kombineres på forskjellige måter for å overføre (transformere) informasjon. Eks: En robot transformerer en kommandofil som inneholder instruksjoner til et sett kontrollsignaler som forårsaker en spesifikk fysisk aksjon. Systemutvikling Kap. 10 Systemutvikling 5 Systemutvikling Kap. 10 Systemutvikling 6 1

10.1 Datamaskinbaserte systemer -4 Makroelement: er et datamaskinbasert system som er en del av et større datamaskinbasert system. Systemutviklernes oppgave er å definere elementene til det spesifikke datamaskinbaserte systemet i sammenheng med det totale hierarki av systemer (makroelementer). 10.2 System/utviklingshierarki Fig 10.1 viser hierarki av systemer. Sett ovenfra gir oversikt Videre nedover i systemet blir det mer detaljert og komplisert. På øverste nivå (WV world view) er det flere domener. Hvert domene består av elementer. Hvert element består av tekniske komponenter. I programvare kan en komponent være: et program, en programkomponent, en modul, en klasse eller et objekt, eller et språkelement. Systemutvikling Kap. 10 Systemutvikling 7 Systemutvikling Kap. 10 Systemutvikling 8 The Hierarchy Business or Product Domain World view Domain of interest Domain view System element Element view Detailed view 10.2.1 Systemmodellering Systemutvikling er en modelleringsprosess. Det lages modeller som definerer prosessen fra forskjellige synspunkt: viser prosessens oppførsel, definerer input og output til modellen, og forbindelser til omgivelsene. For å få en hensiktsmessig modell må en gjøre: 1. Antakelser som reduserer antall variasjoner 2. Forenklinger slik at en kan lage en modell på kort tid. 3. Avgrensninger (mot omgivelsene) 4. Rammebetingelser 5. Preferanser (for dataarkitektur, funksjoner etc..) Systemutvikling Kap. 10 Systemutvikling 9 Systemutvikling Kap. 10 Systemutvikling 10 Systemmodellering og -simulering Sanntidssystemer (real time systems) og embedded systems kalles ofte reaktive systemer. De mottar input fra fysiske omgivelser, og prosesserer ut fra dette (interruptstyrte). Det stilles høye krav til pålitelighet for slike systemer (flytrafikkontroll, (fabrikk)automasjon, robotkontroll osv.) Det brukes nå CASE-verktøy til systemmodellering og simulering i utviklingsprosessen. Simuleringsmodellen kan brukes til å teste systemet og/eller systemkomponenter. 10.3 Oversikt over utvikling av forretningsområde Business process Engineering Målet for Business process Engineering (BPE) er å definere arkitekturer som vil gjøre en virksomhet i stand til å bruke informasjon effektivt. BPE brukes til å lage en total plan for å implementere slike arkitekturer. De forskjellige arkitekturene må analyseres og konstrueres i samsvar med forretningsmål: data arkitektur applikasjons arkitektur teknologisk Se fig 10.2. Systemutvikling Kap. 10 Systemutvikling 11 Systemutvikling Kap. 10 Systemutvikling 12 2

Product Engineering The complete product System analysis (World view) 10.4 Oversikt over produktutvikling (Product Engineering) capabilities hardware Processing requirement data function software Component engineering (Domain view) behavior Analysis & Design Modeling (Element view) program component Software Engineering Construction & Integration (Detailed view) Målet med produktutvikling er å overføre kundens behov (ønsker) til et sett av definerte egenskaper til et produkt (som virker). Produktutvikling må også utvikle arkitektur og infrastruktur. Arkitekturen må omfatte fire systemkomponenter: 1. Programvare 2. Maskinvare 3. Data og databaser 4. Personell Fig. 10.3 viser produktutviklingshierarkiet. Systemutvikling Kap. 10 Systemutvikling 13 Systemutvikling Kap. 10 Systemutvikling 14 10.4 Produktutvikling (Product Engineering) Systemutviklingen starter med kundedefinerte mål og begrensninger, og det lages en representasjon (beskrivelse) av: funksjoner ytelse grensesnitt konstruksjonsbegrensninger informasjonsstruktur som kan tilordnes hvert systemelement. Systemets produktområde (virkeområde, rekkevidde, kontekst scope) må defineres. 10.4 Produktutvikling-2 Kriterier som styrer valg av systemkonfigurasjon er basert på tilordning av funksjoner og ytelse til (generiske) system element: 1. Prosjektvurderinger: kan denne konfigurering bygges innenfor de gitte tids- og kostnadsrammer? Hva er risikofaktorene ved kostnads- og planestimatene? 2. Forretningsmessige vurderinger: Er denne konfigurering den mest lønnsomme? Kan den selges (med suksess)? Vil den totale avkastning forsvare utviklingsrisiki? Systemutvikling Kap. 10 Systemutvikling 15 Systemutvikling Kap. 10 Systemutvikling 16 10.4 Produktutvikling -3 3. Teknisk analyse Eksisterer teknologien som kreves? Er funksjonalitet og ytelse sikret? Kan konfigurasjonen vedlikeholdes (rimelig)? Finnes nødvendige tekniske ressurser? Hvilke risiki er forbundet til teknologien? 4. Produksjonsevaluering Er produksjonsutstyret (lokaler etc..) tilgjengelig? Er det knapphet på nødvendige komponenter? Kan nødvendig (fornuftig) kvalitetssikring utføres? 5. Personell hensyn: Er kvalifisert personale tilgjengelig for utvikling og produksjon? Er det politiske problemer? Forstår kunden hva systemet vil utføre? 10.4 Produktutvikling -4 6. Grensesnitt mot omgivelsene: Har den foreslåtte konfigurering et riktig (passende) grensesnitt mot systemets (eksterne) omgivelser? Håndteres maskin-maskin og menneske-maskin kommunikasjon på en intelligent (hensiktsmessig) måte? 7. Juridiske vurderinger: Introduserer denne konfigurering utilbørlig ansvarsrisiko? Kan eiendomsretten beskyttes? Er det mulige krenkelser eller overtredelser? Systemutvikling Kap. 10 Systemutvikling 17 Systemutvikling Kap. 10 Systemutvikling 18 3

10.4 Produktutvikling -5 Systemutviklerne må også vurdere hyllevare som løsning på kundens problem: Finnes tilsvarende system allerede? Kan (hoved)deler av systemet kjøpes fra tredjepartsleverandører? Resultatet av vurderingene er at det velges en spesifikk systemkonfigurasjon og spesifikasjon av funksjoner og (maskin og program) ytelse, personell, databaser, dokumentasjon og prosedyrer. 10.5 Behovskartlegging (Reqirement Engineering) Kartlegge (Elicitation) finne ut hva kunden krever (ønsker) Analyse & forhandlinger forstå forholdet mellom forskjellige kundekrav, og formulere de slik at en oppnår et vellykket resultat Kravspesifikasjon lage en konkret modell av kravene. Systemmodellering lage en representasjon av kravene som kan vurderes i forhold til korrekthet Fullstendighet konsistens Validering gjennomgang (reviewing) av modellen Administrasjon (management) identifisere, kontrollere og spore krav og endringer som vil bli gjort (i kravene). Systemutvikling Kap. 10 Systemutvikling 19 Systemutvikling Kap. 10 Systemutvikling 20 Product Architecture Template Architecture Flow Diagram user interface processing operator interface operator requests operator interface CLSS queries, reports, displays acquisition request sorting reports shunt control status CLSS processing & control report requests timing/location data input processing process and control functions maintenance and self-test output processing reader decoding part number shunt control shunt controller raw bar bin code data shunt commands location data base access report CLSS reports line sensor data speed key formating acquisition sort records mainframe communications BCR status driver diagnostics shunt status pulse tach input sensor status formated communications status reporting data data acquisition interface reader status diagnostic interface output interface Systemutvikling Kap. 10 Systemutvikling 21 Systemutvikling Kap. 10 Systemutvikling 22 Systemanalyse Systemanalysen omfatter de fleste oppgaver som inngår i utviklingen av et edbsystem (computer system engineering). I enkelte sammenhenger brukes systemanalyse om bare å lage kravspesifikasjon (software requirement analysis). Her brukes systemanalyse i vid betydning, vi ser på alle systemelementer. Systemanalyse -2 Målene med systemanalyse er: 1. Identifisere kundenes behov. 2. Evaluere systemkonseptet for egnethet (feasibility). 3. Utføre økonomisk og teknisk analyse. 4. Tilordne funksjoner til maskin-, programvare, personell, databaser, og andre systemelementer. 5. Sette kostnads- og planbegrensninger (rammebetingelser). 6. Lage en systemdefinisjon som danner fundamentet for alt etterfølgende arbeid. Det lønner seg å gjøre grundig arbeid i systemanalysen! Systemutvikling Kap. 10 Systemutvikling 23 Systemutvikling Kap. 10 Systemutvikling 24 4

Identifisering av behov osv.. Identifisering av behov Forprosjekt Økonomisk analyse Teknisk analyse Modellering av systemarkitektur Identifisering av behov -2 Fremgangsmåte for behovskartlegging: 1. Definere mål for systemet i samarbeid med kunden Hvilken informasjon produseres? Hvilken informasjon er tilgjengelig? Hvilke funksjoner og ytelse kreves? Systemereren sørger for at det skilles klart mellom behov (krav) og ønsker (tilleggsfunksjoner, kjekt å ha ) 2. Når målene er definert, må tilleggsinformasjon evalueres: Eksisterer nødvendig teknologi? Hvilke spesielle ressurser kreves i utviklingen? Hvilke begrensninger er satt på kostnader og planlegging (rammebetingelse)? Systemutvikling Kap. 10 Systemutvikling 25 Systemutvikling Kap. 10 Systemutvikling 26 5