Applikasjoner - på kort tid og til budsjett

- Det er ingen naturlov at utviklingsprosjekter skal overskride både tidsramme og budsjett, mener Per Ljåstad i Usoft.

Per Ljåstad er Usofts mann i Norge. Usoft viser både til et programvareselskap opprinnelig opprettet av Unisys, og til dette selskapets produkter, en serie verktøy for applikasjonsutvikling. Mest kjent av disse er Usoft Developer.

Ljåstad mener Usoft står foran et stort gjennombrudd, etter et fjorår som var preget av mye oppmerksomhet, ikke minst da http://www.usoft.com/homepage/index_rad_race.htm>Usoft vant en internasjonal premie i rask applikasjonsutvikling (RAD: rapid application development).

Gartner Group har utropt Usoft til "potensiell markedsleder" innen klient/tjener og web-utvikling i 1998, betinget selvfølgelig av en rekke faktorer vi mener vi vil greie å leve opptil.

Det er to egenskaper ved Usoft som Ljåstad fremhever spesielt. Den første er at verktøyet kan brukes til å utvikle applikasjoner fra en til flere tusen brukere. Det andre er at utviklingsarbeidet er det samme om man utvikler mot klient/tjener eller mot web.

– Teknologien vi bruker, kan beskrives i tre hovedpunkter, sier Ljåstad. – Det sentrale er at hele modellen beskrives gjennom en serie regler. Alle regler lagres samlet i et repositorium (repository), og defineres bare én gang. Punkt to er fritt valg av infrastruktur: web, klient/tjener, eller database. Html betraktes i hovedsak som en spesiell type grafisk brukergrensesnitt. Punkt tre er automatisk generering av applikasjonen. Denne kan selvfølgelig finpusses. Men det er et viktig poeng at når du har definert reglene som skal gjelde, kan du straks teste for å sjekke at alt virker som det skal. Endringer skjer da gjennom nye regler, eller ved å definere nye unntak.

Applikasjonsgeneratoren fordeler automatisk noen av reglene til klienten, resten til serveren. Hensikten er å redusere tallet på transaksjoner over nettet. Data som er på vei inn i systemet, valideres lokalt. Usoft ser liten grunn til å belaste nettverket med ting som kan avgjøres lokalt.

– På web leveres reglene som en Java-applet. ActiveX kommer til sommeren, presiserer Ljåstad.

Automatisk applikasjonsgenerering på grunnlag av sentralt definerte regler gjør ikke bare at en applikasjon kan defineres svært raskt. Det betyr også at endringer kan gjøres fort, og applikasjonen kan stadig tilpasses nye forhold.

– Usofts varemerke er "Business Rules Automation", forklarer Ljåstad. – Regelbasert utvikling er et stort framskritt i forhold til tradisjonelle metoder som tredje og fjerdegenerasjon, der framgangsmåten er å lage alt på en gang etter "fossefallmetoden". Reglene våre er styringsinstrumenter for bedriften. Utviklingsarbeid med Usoft tar utgangspunktet i det bedriftens ledelse mener må være formålet med hele virksomheten. Og det tar hensyn til at folk ombestemmer seg eller presiserer sine mål.

Blant Usofts 1500 lisensinnehavere i Norge er en rekke tunge kunder, blant dem Hydro, Aker-konsernet og forsvaret. Internasjonalt har selskapet rundt 400 ansatte, og rangeres blant verdens 100 største programvareselskap.

– Vår metode gjør at vi løser de to grunnleggende problemene i alt utviklingsarbeid, sier Ljåstad, og viser til at vanlige kjensgjerninger som at skreddersydde applikasjoner jevnt over overskrider budsjett og leveres langt etter tidsskjemaet. Han mener å kunne dokumentere at 90 til 95 prosent av prosjekter basert på Usofts utviklingsverktøy, ferdigstilles i tide og etter budsjett.

– Mye av årsaken til at tidsskjema og budsjetter sprekker, er at utviklerne sprer virksomhetsreglene på forskjellige steder i applikasjonen. Objekter er ikke alternativet, det er bare et annet navn på programbibliotek. Løsningen er det vi har gjort: Å samle reglene.

Det viktigste i utviklingsprosessen er følgelig å definere reglene. Det foregår etter et fast rituale.

– Vi starter med å finne fram til de som skal bli systemets nøkkelbrukere. Sammen med dem lager vi en datamodell. Det gir et visuelt bilde som brukerne aldri har problemer med å forholde seg til. Datamodellen gir reglene, og reglene uttrykkes og lagres i repositoriet. Når noe må presiseres eller forbedres, fordi vi ser at praksis slår uheldig ut, går vi alltid tilbake til datamodellen og reglene. Dette kaller vi "foretaksdrevet iterativ prosess".

Ljåstad peker på at dette arbeidet ofte kan ta utgangspunkt i en datamodell som kunden allerede har. En organisasjon han mener kunne dra nytte av Usoft, er Rikstrygdeverket. Mellom 30 og 40 prosent av arbeidet som er nedlagt i Tress gjelder datamodellen, en systematisering av en nærmest avsindig mengde regler og forskrifter. (Andre har foreslått at det kunne vært en idé å forenkle trygdesystemet før man søker å uttrykke det informasjonsteknologisk.)

Usoft gir ellers muligheter for å finne tilbake til datamodellen på grunnlag av tabellene i en eksisterende database.

Litt malurt

I Patricia Seybold Group sin "snapshot" av Usoft Developer, slås det fast at Usofts "konsepter er korrekte". Samtidig gis det kritikk på to viktige punkter. Det første er at verktøyet har et ekstremt databasesentrert synspunkt på applikasjoner. "Det virker ikke intuitivt å formulere 'business policy' som forespørsler mot en database." Det andre er at når hensynet til raske og enkle endringer av reglene er ivaretatt, går det utover et annet viktig hensyn, nemlig å ha kontroll og oversikt. Seybold etterlyser følgelig verktøy som kan hjelpe utviklerne å holde oversikt over reglene i repositoriet.

Til toppen