Systemutvikling I og II

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 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) 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 Prosess Eksempler/Øvelse Lignings-kontoret

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)

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 ...

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, telefonnummer eller kundenummer Finner riktig kunde. Viser personopplysninger og 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 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

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 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

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 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.

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.

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