Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Systemutvikling I og II

Liknende presentasjoner


Presentasjon om: "Systemutvikling I og II"— Utskrift av presentasjonen:

1 Systemutvikling I og II

2 Aktuelle oppgaver Gjenbruk er blitt mer og mer aktuelt ved utvikling av datasystemer Drøft former for gjenbruk Mange software-prosjekter ender i fiasko Drøft mulige årsaker til dette og hva som kan gjøres for redusere risikoen

3 Innledning Hvorfor i dette kurset? Software engineering anskaffelse
utvikling

4 Fra skreddersøm til hyllevare
Skreddersøm (Bespoke software) Lages på bestilling Mer og mer gjenbruk også her Rimeligere Raskere Hyllevare (COTS) Lages for salg Har passert Skreddersøm i verdi Er ofte laget med utgangspunkt i skreddersøm

5 Former for gjenbruk I Småskala-gjenbruk Ferdige komponenter
Store komponenter sparer mye tid om de passer Egenutviklede, Gratis eller Innkjøpte Fordeler og ulemper med bruk av komponenter Kodebibllioteker Krav, Designmønstre, Testdata, Dokumentasjon

6 Former for gjenbruk II Storskalagjenbruk En stor komponent f.eks. ERP
Tilpasses til organisasjonen - stor oppgave (-2 år) Betongeffekten Åpen kildekode (Gratis programvare) Ferdig program som kan tilpasses. Gratis i utgangspunktet Tilpasning koster Må tilpasning gjøres tilgjengelig for andre?

7 Hyllevare (99% gjenbruk)
ShrinkWare Bare maskinkode tilgjengelig Mye ferdig funksjonalitet Kan øke funksjonalitet ved makroprogrammering Support kan være et problem

8 Hyllevare vs. Skreddersøm - Rammebetingelser
Utvikling og anskaffelse Skreddersøm: sammenvevd i et prosjekt Hyllevare: anskaffelse etter utvikling Økonomisk risiko Skreddersøm: Stor risiko for kunden Hyllevare: Mindre risiko- valg mellom flere leverandører, mindre penger involvert Brukermedvirkning Skreddersøm: Brukerne sentrale Hyllevare: Mindre brukermedvirkning

9 Aktuelle oppgaver Tegn et dataflyt-diagram som illustrerer disse arbeidsoperasjonene: ... Hvorfor ender så mange IT-prosjkter med fiasko, og hva kan gjøres for å unngå dette. Skriv et use-case som beskriver interaksjonen med en bensinpumpe Prototyping kan være aktuelt i flere situasjoner Hva er poenget med prototyping og hvilke typer prototyping har vi. Hva mener vi med inkrementell systemutvikling og vilke fordeler kan den gi framfor andre prosessmodeller.

10 Fiaskoliste skreddersøm
Rikstrygdeverket TRESS-90 (tap 1,2 milliard) ikke ferdig i 90, fortsatt uferdig i 95 - stoppet Denver flyplass (365 millioner $) Ett år forsinket pga bagasjehåndteringssystem Statens veivesen 1995 (tap 150 million) Ubrukelig system Oslo Lokaltrafikk e-Billetten (tap 300 millioner) Nedlagt prosjekt Ariane 5 styrtet i 1996 (tap 5 milliarder) Programmeringsfeil ....

11 Fiaskoliste ERP Medisinfirma FoxMeyer gikk konkurs
Bostyret saksøker konsulentfirma som gjorde dårlig jobb med innføring av SAP Gore-Tex produsenten Saksøker datafirmaer som endte opp med det doble av anslått pris og for dårlig system. Hershey (kjent sjokoladeprodusent) ERP system for dårlig slik at de ikke fikk ut varene fort nok->19% svikt i omsetningen i 3.Q 1999

12 Fiaskoliste massemarkedsvare
Vanskelig å finne tall - Ikke så tett integrert med virksomheten Mulig å erstatte med alternativt produkt USA 1996 Supporttelefoner 200 millioner samtaler * 23$ =4,6 milliarder $ årsverk med venting

13 Vanligste fiasko-årsaker
Skreddersøm Dårlig prosjektledelse Manglende forståelse av kundens behov ERP Feilaktig valg av programpakke

14 Hvor ligger vanskelighetene?
Ikke i programmering, men å styre et prosjekt med mange deltakere å finne ut hva kunden egentlig trenger å få organisasjonen til å ta systemet i bruk Er det riktig å bygge et system? Hva er det riktige systemet? Hvordan bygger man systemet riktig?

15 Analyse og kravspesifikasjon (A&K)
Beskriver nåværende situasjon Hva er problemet? Analyse er deskriptiv Kravspesifikasjon: Hva skal det nye systemet gjøre? Analyse er preskriptiv Beskriver systemets ytre: utseende og oppførsel Design: Hvordan må systemet konstrueres for å gjøre det som kreves? Beskriver systemets indre oppbygning

16 A&K Ved skreddersøm Gjøre det selv eller bruke konsulent
Kan man selv klare å formulere kravene til et system som løser de aktuelle problemene? Kravspesifikasjon er grunnlag for anbud Presis beskrivelse på grunnlag av behov Brukermedvirking

17 A&K Arbeidsmåter og dokumentasjon
Arbeidsmåter - granske organisasjonen intervjuer Spørreundersøkelser observasjon dokumentasjonsstudier Dokumentasjon - oversiktelig/forståelig Finne vesentlige punkter Krav til tekstutforming - konsistens, kryssreferanser Bruk av diagrammer og illustrasjoner Bruk av kjørbare prototyper

18 Problemanalyse beskriver
Organisasjon og generelle problemer nå. Problemet beskrevet i ulike gruppers perspektiv Sammenheng mellom bedriftens mål og krav til systemet (målhierarki) Forretningsregler

19 Diagramteknikk egnet for analyse - DFD
Dataflyt Datakilde/sluk Prosess Eksempler/Øvelse Lignings-kontoret

20 Hvordan spesifiseres kravene
Tekst i naturlig språk eller formelle språk (Sjelden aktuelt - uforståelig for ikke-spesialister) To hovedløsninger Erklæringer: "Systemet skal vise tilgjengelige flygninger" Use Case (Brukstilfeller) Skrittvis beskrivelse av brukerinteraksjonen Kundebehandler registrerer avreisedag, fra_by, til_by Systemet viser tilgjengelige flygninger ... Krav grupperes i Funksjonelle krav: Hva systemet skal kunne gjøre. Ikke funksjonelle krav: Andre krav.(f.eks svartid)

21 Use Case – Kravspesifiseringsteknikk
Bruker System 1 Kunden stikker inn bankkortet Ber om pin 2 Kunden taster inn pin Verifiserer pin og ber om beløp 3 Kunden velger beløp Sjekker om dekning på konto, returnerer kort 4 Kunden tar kortet Betaler ut pengene og belaster konto 5 Kunden tar pengene Viser saldo ...

22 Eksempler på brukstilfeller (Use Case)
Betjene kunde som vil ha opplysninger om siste faktura Gi ledelsen oversikt over utvikling i omsetning Gi driftspersonalet liste over numre som skal blokkeres

23 Use Case 1 Siste Faktura Bruker System 1 Viser meny 2 Velger kunder
Ber om kundeid 3 Registrerer kundenavn, telefonnummer eller kundenummer Finner riktig kunde. Viser personopplysninger og meny for denne kunden 4 Velger siste faktura Viser siste faktura

24 Use case Lett å forstå for bruker og utvikler
Beskriver i utgangspunktet standardforløpet (at alt går bra) Avvikende hendelsesforløp beskrives for seg selv Viktig at bare ytre egenskaper beskrives Use-case diagrammer Gir oversikt over hvilke use-case systemet har. Kan ikke erstatte use-case-teksten. Eksempel/Øvelse

25 Kravadministrasjon Hvem kom med kravet? Hvor høy prioritet har det?
Hva er kostnaden med å innfri kravet? Er det konflikter mellom krav?

26 Problemer med kravspesifisering
Vanskelig å kvalitetssikre kravspesifikasjon Lett å forstå spesifikasjonen forskjellig Kravene utvikler seg etterhvert Løses ved: Use Case Prototyping Inkrementell utvikling

27 Prototyping Papirprototyping Bruk og kast-prototyper
Skjermbilder av papir med muntlig gjennomgang og diskusjon Rimelig og effektivt Bruk og kast-prototyper Liksom-system for å anskueliggjøre noe det er vanskelig å spesifisere. Kode nok til at det viser interaksjonen. Evolusjonær prototyping Bygge systemet med ferdig funksjonalitet, men der bit for bit blir videreutviklet i samarbeid med bruker. Begynne med delene der det er klare krav eller? Farer –tidlig design og brukergrensesnittsentrering

28 Analyse og kravspek ved hyllevareinnkjøp
Forskjeller fra skreddersøm: Hyllevare løser kjente problemer Det finnes ferdige produkter å velge mellom Reduserte muligheter for brukermedvirkning Hyllevare kan tilpasses Farer ved tilpasning Tretrinns eliminering anbefalt Sjekk leverandørenes økonomi og produktinfo i brosjyre eller nett Få gjenværende produkter demonstrert Gjør en prøveinstallasjon for å teste det mest aktuelle Hva om man ikke finner passende produkt Endre krav? Tilpasse produkt? Vente?

29 Analyse og kravspek ved hyllevareutvikling
Kunde med kravspesifikasjon mangler Må finne krav som er felles for potensielle kunder Etter leveranse – utvikle videre på bakgrunn av tilbakemeldinger Prioritering av krav Spesialtilpasning av produktet

30 Design og programmering
Hvordan skal programvaren tilfredsstille kravene Mindre konsekvenser av feil enn ved kravspek Innvendig struktur viktig for vedlikeholdbarhet Kravtilfredsstillelse vanskeligere for ikke funksjonelle krav IFK vanskeligere å kontrollere IFK gjelder helheten IFK er ofte motstridende

31 Design Arkitektur- Hvordan systemet deles opp i delsystemer
Klient –tjener eller Repository eller Lagdeling Brukergrensesnitt Utvikling av skjermbilder og rapporter - brukbarhet Moduldesign Oppdeling av delsystemer. Kohesjon og kopling To tilnærminger Objektorientert og Funksjonsorientert Algoritmedesign Bestemme en trinnvis løsning av problemet Programmering Utforme detaljene slik at det kan utføres av en datamaskin Forståelighet viktig

32 Testing og inspeksjon Testing Inspeksjon
Sjekke programmet mot spesifikasjonen Ulike former for testing: Feiltesting, Statistisk testing, Stresstesting, Rygg mot rygg-testing, Akseptansetesting Testplaner Testmetoder – dekning Hvitboks og svartboks-testing Systemtester, enhetstester og integrasjonstester Inspeksjon Gå gjennom for å luke ut feil Kan brukes på alt – ikke bare programkode Ofte mer effektivt enn testing

33 Bruk og vedlikehold Dyreste fase ved skreddersøm
Ikke bare feilretting også tilpasning påbygging Vedlikeholdstyper Korrigerende Tilpassende (til ny plattform) Perfeksjonerende

34 Prosjektorganisering
Dårlig prosjektstyring gir ofte fiasko Livssyklusmodeller

35 Fossefallsmodellen Fasene:
Kravanalyse Design Koding og enhetstesting Integrasjons- og system- og akseptansetest Bruk og vedlikehold Dokument i slutten av hver fase – lett å planlegge Modellen fikk etter hvert mye kritikk Lite fleksibel Fleksibilitet er mer nødvendig her enn ved veibygging

36 Inkrementell utvikling
Systemet utvikles bit for bit Prosess Kravspesifikasjon Inkrementell utviklingsplan Inkrement 1 Inkrement 2 .. Kunden tar bitene i bruk etter hvert som de blir ferdig Kvalitetstester og tilbakemelding for hver bit Fordeler Tidlige fordeler av systemet Kravene forbedres undervieis Krever mer modulært design

37 Andre prosesser Iterativ utvikling Extreme programming (XP)
Starter uten ferdig kravspesifikasjon Videreutvikle spek og system etter hvert som kunden prøvekjører og utvikler nye ideer =evolusjonær prototyping Extreme programming (XP) Inkrementell – Brukerhistorier Arkitekturprototyper Iterativ – Brukermedvirkning Akseptansetest for hvert inkrement Hvis akseptert – tatt inn i systemet.

38 Valg av prosess Fossefall Inkrementell Iterativ XP
Store prosjekter og godt forstått problemområde Kan være risikabel Inkrementell Redusert risiko. Iterativ Egnet ved vage krav XP Egnet for prosjekter med vage krav og små team – kan være svært effektivt.

39 Spiralmodellen (Boehm)
Kombinasjon av ulike metoder med risikoanalyse Spiralmodell Starte innerst Bestemme mål og avgrensninger Vurdere alternativer og vurdere og løse risikoer Lage prototyper eller modellere/simulere Gjennomføre det som er planlagt Evaluere og verifisere utført arbeid Planlegge neste runde Hver runde kan være krav, konstruksjon eller implementering Det er mulig å ta flere runder på samme nivå. Avklare store risikoer først - hvis umulig- avbryt prosjektet.

40 Prosjektplaner Lages i starten -følges opp og blir mer detaljert etter hvert. Innhold mål, kunde, systembeskrivelse Rammer Team og roller Ressursbehov Risikoanalyse og håndtering Oppdeling av arbeidet Tidsplaner Leveranseplan

41 Risiko Noe som kan true prosjektets suksess Typiske risikoer:
Nøkkelpersoner slutter eller blir syke Kravene endrer seg Mer komplisert enn ventet Teknologiendringer kan gjøre systemet avlegs Organisasjonsendringer kan gjøre systemet unødvendig Risikohåndtering Redusere sannsynligheten for at den inntreffer Ha planer for å redusere negative konsekvenser Avklare risiko tidlig Usikkerhet kan avhjelpes med prototyping

42 Milepæler og leveranser
Leveranse kan være dokumentasjon eller deler av programvaren (Deliverable el release) Milepæl er en tidsfrist for når noe skal være ferdig Avhengig av livssyklusmodell Fossefall - fasedelte milepæler Inkrementell - moduldelte milepæler Aktivitetsplan viser hvordan aktiviteter avhenger av hverandre og tidfester dem. Eksempel

43 Etiske problemstillinger
Kvaliteten til systemene er viktig. Ikke enkelt Tidspress Krav som endrer seg Det er motsetning mellom pris/tidspress og kvalitet Vedlikeholdbarhet og fleksibilitet krever arbeid Å redusere feil krever arbeid. Ofte for lave anbud Vanlig problem i databransjen - rovdrift på de ansatte God kontakt mellom kunde og utviklere er nødvendig


Laste ned ppt "Systemutvikling I og II"

Liknende presentasjoner


Annonser fra Google