Systemutvikling I og II

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 $ • 30 000 å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 • 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

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

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