Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Systemutvikling I og II in 102. Aktuelle oppgaver Gjenbruk er blitt mer og mer aktuelt ved utvikling av datasystemer Drøft former for gjenbruk Mange software-prosjekter.

Liknende presentasjoner


Presentasjon om: "Systemutvikling I og II in 102. Aktuelle oppgaver Gjenbruk er blitt mer og mer aktuelt ved utvikling av datasystemer Drøft former for gjenbruk Mange software-prosjekter."— Utskrift av presentasjonen:

1 Systemutvikling I og II in 102

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 Manglende forståelse av kundens behov 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) Analyse 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 1. Kundebehandler registrerer avreisedag, fra_by, til_by 2. 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 BrukerSystem 1Kunden stikker inn bankkortet Ber om pin 2Kunden taster inn pinVerifiserer pin og ber om beløp 3Kunden velger beløpSjekker om dekning på konto, returnerer kort 4Kunden tar kortetBetaler ut pengene og belaster konto 5Kunden tar pengeneViser 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 BrukerSystem 1Viser meny 2Velger kunderBer om kundeid 3Registrerer kundenavn, telefonnummer eller kundenummer Finner riktig kunde. Viser personopplysninger og meny for denne kunden 4Velger siste fakturaViser 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 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 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 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 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 in 102. Aktuelle oppgaver Gjenbruk er blitt mer og mer aktuelt ved utvikling av datasystemer Drøft former for gjenbruk Mange software-prosjekter."

Liknende presentasjoner


Annonser fra Google