Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Systemutvikling I og II by HC12030416227

VIEWS: 19 PAGES: 43

									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 ender i
  fiasko
     Drøft mulige årsaker til dette og hva som
      kan gjøres for redusere risikoen
Innledning
  Hvorfor i dette kurset?
  Software engineering
     anskaffelse
     utvikling
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
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
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?
Hyllevare (99% gjenbruk)
  ShrinkWare
     Bare maskinkode tilgjengelig
     Mye ferdig funksjonalitet
     Kan øke funksjonalitet ved
      makroprogrammering
     Support kan være et problem
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
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.
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
  ....
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
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 $
     30 000 årsverk med venting
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
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?
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
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
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
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
Diagramteknikk egnet for analyse - DFD


   Dataflyt
   Datakilde/sluk   Lignings-
                    kontoret
   Prosess

   Eksempler/Øvelse
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)
Use Case –
Kravspesifiseringsteknikk
    Bruker                  System

1   Kunden stikker inn      Ber om pin
    bankkortet
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 ...
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
Use Case 1 Siste Faktura
     Bruker                   System

 1                            Viser meny

 2   Velger kunder            Ber om kundeid

 3   Registrerer kundenavn,   Finner riktig kunde. Viser
     telefonnummer eller      personopplysninger og
     kundenummer              meny for denne kunden

 4   Velger siste faktura     Viser siste faktura
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
Kravadministrasjon
  Hvem kom med kravet?
  Hvor høy prioritet har det?
  Hva er kostnaden med å innfri kravet?
  Er det konflikter mellom krav?
Problemer med
kravspesifisering
  Vanskelig å kvalitetssikre
  kravspesifikasjon
  Lett å forstå spesifikasjonen forskjellig
  Kravene utvikler seg etterhvert
  Løses ved:
     Use Case
     Prototyping
     Inkrementell utvikling
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
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?
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
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
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
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
Bruk og vedlikehold
  Dyreste fase ved skreddersøm
  Ikke bare feilretting også tilpasning
  påbygging
  Vedlikeholdstyper
     Korrigerende
     Tilpassende (til ny plattform)
     Perfeksjonerende
Prosjektorganisering
  Dårlig prosjektstyring gir ofte fiasko
  Livssyklusmodeller
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
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
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.
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.
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.
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
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
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
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

								
To top