Kap. 22 – Developing a System

Presentasjon om: "Kap. 22 – Developing a System"— Utskrift av presentasjonen:

1 Kap. 22 – Developing a System
How Information Technology Is Conquering the World: Workplace, Private Life, and Society Professor Kai A. Olsen, Universitetet i Bergen og Høgskolen i Molde

2 Kravspesifikasjon IT prosjekter har vært plaget av:
Budsjettoverskridelser Tidsoverskridelser Mange fiaskoer Uklarhet om mål er oppnådd Ofte legger en skylden på uklare kravspesifikasjoner Med kravspesifikasjonen ønsker en: Bedre styring (jfr. Øving 6) Fastere former Kontroll over budsjett og tid Systemer som dekker kundens behov

3 Kravspesifikasjon kan være mangt…
Et formelt dokument, en juridisk bindende kontrakt, mellom kunde og utvikler om hva som skal gjøres En prototype En liste av mål for systemet, samt en skisse til løsning Kan starte med en vag ide ”hei, vi har et problem med å lage en ordreplan”

4 Forskjellige typer av krav kan inngå:
Generelle Funksjonelle Krav til implementasjon Effektivitet Brukervennlighet

5 Problemer Upresise mål
Kravspesifikasjonen beskriver ikke brukernes virkelige behov Spesifikasjonene er inkonsistente og ikke komplette Spesifikasjonene er for detaljerte (låser utviklerne), mange punkter, svak overordnet forståelse Misforståelser mellom bruker, de som utvikler spesifikasjonene og utviklerne Kravspesifikasjonen forutsetter en stabil verden, det har vi sjelden Kravspesifikasjonen tar ikke hensyn til at visse mål er vanskelig å oppnå Hva når de egentlige kravene endres over tid?

6 Kan føre til… Forsinket leveranse Fordyret leveranse
Behov for store endringer etter installasjon Systemet blir benyttet galt, lite eller ikke i det hele tatt Systemet kan være upålitelig Kritiske brukere Meget store vedlikeholdskostnader Dårlig tilpassning til andre systemer Systemet blir fort avleggs Indirekte kostnader (jobben blir ikke gjort)

7 Ofte Store kostnader til utvikling og tilpassning
Systemet blir tatt i bruk Det virker Men uklart om en har oppnådd noe F.eks. (fra en vit. artikkel): It is therefore very unlikely that any ERP implementation can simply be asserted to be a success or a failure Men det er selvfølgelig systemer som er en åpenbar suksess eller en åpenbar fiasko

8 Kravspesifikasjonsprosessen
Hvordan man håper at prosessen skal gå!

9 Kravspesifikasjon etter IEEE/ANSI 830-1993
Introduction Purpose Scope of the product Definitions References Overview of document General description Product perspective Product functions User characteristics General constraints Assumptions and dependencies Specific requirements functional, non-functional, interface, performance, database and network requirements, etc. Index

10 Hvem bruker kravspesifikasjon-dokumentet?

11 Prosessen

12 Tradisjonell modell Waterfall modellen

13 Mer moderne

14 Kanskje mer realistisk?
Denne fasen er lite formalisert, åpen, med mange usikkerheter Utvikling av systemet (detaljspesifikasjon, programmering…) Denne fasen bør være formalisert, entydig og sikker

15 4 kritiske aktiviteter:
Mål Beskriv målene for systemet, oversikt over problemet, hvorfor et nytt system kan være nødvendig, begrensninger som budsjett… Bakgrunnskunnskap Organisasjon, anvendelsesområde, andre systemer… Organisering Organiser data og informasjon samlet inn til nå, prioriter mål Brukerkrav Hva er brukernes krav til det nye systemet

16 Mål Skal fortelle oss hva vi skal oppnå, hensikten (”rationale”)
Disse kan brukes når vi må ta avgjørelser underveis (f.eks. for å velge mellom brukervennlighet og effektivitet) Målene blir viktige når systemet skal evalueres

17 Prototyping Alternativer: Mange fordeler: Bruk og kast
Evolusjonær prototyping (mer aktuell nå med bedre verktøy) Mange fordeler: Kan vise hvordan systemet vil bli, inklusiv ”look and feel” Håndfast Lettere for brukerne å forholde seg til en prototype enn en spesifikasjon, mer og bedre tilbakemeldinger Hurtigere utvikling Understøtter utvikling i faser Gir utviklerne tidlige kunnskaper om metoder, tidsbruk m.m.

18 Mange varianter av prototyper
Prototype av hele systemet, prototypen kan da bli systemet Av deler av systemet: Brukergrensesnitt Komplekse tekniske løsninger Tidsaspekt Det er smart å konsentrere seg om ukjente deler først. Prototyper kan hjelpe oss her. Fysiske deler kan printes med 3D der det er nødvendig.

19 Validering gjennom prototype
Validering gjennom prototyping: Velg testpersoner Utvikle testscenario Utfør scenario Mange krav kan best testes gjennom prototype: Opplæring Brukervennlighet Effektivitet (delvis)

20 Testing Kan kravene testes? Eksempel: Hvilket krav er testbart?
Kan vi gjøre en eller flere tester i det ferdige systemet for å vise at kravet er oppfylt Eksempel: Systemet skal være lett å lære? 95% av brukerne skal kunne benytte systemet etter 10 minutter? Hvilket krav er testbart?

21 Viktigst Vurder dagens systemer og rutiner
Hva er fundamentalt, hva kan endres og tilpassestil en ny (IT) verden Eksempler: Fjerne kostpenger for reiseregningene Erstatte signaturer med PIN koder Fjerne kontanter La passasjerene bestille billetter selv. Ideen er altså å ikke bare bruke IT for å automatisere funksjoner i verden av i dag, men også dra nytte av mulighetene som ligger i IT til å endre denne verden.

22 Oppsummering Følgende må være på plass:
Det er viktig å vite målsettingene for systemet Vi må ha en god og utarbeide idé av systemfunksjonaliteten Brukergruppene må være kjent Vi må ha valgt metodikk Vi må vite hvordan systemet skal implementeres Koplinger til andre systemer må være kjent Installasjonsfasen må være beskrevet Før vi starter utviklingen av systemet

23 Små systemer – store systemer
Mange av de konkrete eksemplene vi har brukt tidligere har vært for små systemer Små systemer har mange fordeler: Oversiktlige Begrenset arbeidsmengde Få brukere, få installasjoner Da kan vi få en betydelig reduksjon av arbeidet med: Kravspesifikasjon Testing Opplæring Med store systemer blir alt annerledes, spesielt om de utvikles under en detaljert kravspesifikasjon

24 Case: Ny bedrift En helt ny bedrift skal utvikles
Da står vi fritt til å legge opp rutiner i administrasjon og i produksjon Kan bygge egne systemer, kjøpe ferdige systemer eller satse på en kombinasjon Det som er viktig er å tenke IT fra starten av.

25 Viktig modell Parker and Benson, Information Economics: Linking Information Technology and Business Performance, Prentice Hall, 1988.

26 IT som en sentral innsatsfaktor
IT skal hjelpe oss å tenke nytt, vi skal ikke først definere forretningsmodellen og så bruke IT for å realisere denne. Med IT kan vi: Automatisere Heve effektiviteten til personalet Tilby fleksible produkter Gi kundene tilgang til data ….

27 Case: Propellblad Tradisjonell prosess – fra støpt emne til ferdig propellblad: Støperi leverer støpte emner Maskinering av rot og kontur Maskinering av bladflate Sliping/ polering og slutt-kontroll Ny prosess – unngå maskinering: Støperi leverer støpte emner Maskinering av rot og kontur Sliping av bladflate med robot Sliping/ polering og slutt-kontroll

28 Effektivisering Maskinering til nominelle mål er svært kostbart – 8000 kr/time. Krever avanserte maskiner, stor slitasje på maskinen Ved å støpe nøyaktigere og å slipe kan vi utnytte frihetsgradene i standarden som setter kvalitetskravene. Slipeprosessen er langt billigere enn maskinering. Denne kan effektiviseres med bruk av roboter.

29 Sliping med robot Vi trenger program som kan styre roboten.
To muligheter: Kreve gode emner og la roboten slipe av de ytterste 1-2 mm Ha en robot som også kan måle bladet slik at vi kan beregne nøyaktig hvor mye som fjernes. Begge løsningene vil gi betydelige innsparinger. Vi har et forskningsprosjekt sammen med SINTEF for å utrede og teste mulighetene.