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

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

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”

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

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?

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)

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

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

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

Hvem bruker kravspesifikasjon-dokumentet?

Prosessen

Tradisjonell modell Waterfall modellen

Mer moderne

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

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

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

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.

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.

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)

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?

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.

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

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

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.

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

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

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

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.

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.