Del III. Ledelse av systemutvikling Kap. 9 Teknologier Strukturert utvikling Verktøy Prototyper Open source Integrasjon av systemer Internett-baserte systemer Prosjektledelse Kap. 10 Ledelse rekruttering implementering av systemer resultatmåling 04.04.2017 kap. 9

Strukturert systemutvikling (1970…) 3 gen. programmeringsspråk (Cobol, Fortran, Simula) ”Strukturert programmeringsmetodologi” Prosjektstyringssystem Databasesystem Online og batch applikasjoner i samme system Programmering for stormaskiner (noe minimaskiner) Profesjonelle programmerere (men ofte selvlærte) Diverse utviklingsverktøy (svak integrasjon) Prosess for validering av ferdig produkt Brukermedvirkning ved start (kravspesifikasjon) og slutt (installasjon) 04.04.2017 kap. 9

Waterfall (fossefalls) modell 04.04.2017 kap. 9

Bedre: Spiralmodellen 04.04.2017 kap. 9

Mer realistisk? start Fokus bør være her Kravspesifikasjon Systemdesign Programmering/ Systemutvikling Fokus ofte her ferdig system 04.04.2017 kap. 9

Strukturert utvikling (1980-) Mer disiplin Standarder for utvikling, dokumentasjon, brukergrensesnitt (redusere personlige variasjoner) Større pålitelighet, færre feil Inspeksjoner, for å finne feil så tidlig som mulig Mer effektiv ressursbruk Tidskontroll m.m., som ved andre typer prosjekter Krav til utviklingsmetode og kontroll (f.eks. i systemer for det militære) 04.04.2017 kap. 9

Protester (2000-) Nye ideer: Idé: ”Agile” programming Rapid Prototyping Idé: Kjappere utvikling Utnytte kompetansen til individuelle programmerere Gjøre programmering kreativt og spennende igjen 04.04.2017 kap. 9

4 generasjons programmeringsspråk Tradisjonelt fokus på språket, Cobol, Fortran, Algol, PL/1, Visual Basic, C, … Men språket er bare en liten del av utviklingsmiljøet Verktøy: teksteditor, kompilator, komponenter er viktigere 4 generasjonsspråk: Inkluderer databasesystem Inkluderer verktøy for å utvikle brukergrensesnitt + programmeringsspråk Wizards for standardoperasjoner Eksempler: Access, Visual Cafe og tyngre miljø som .Net 04.04.2017 kap. 9

Funksjonalitet 04.04.2017 kap. 9

Eksempel: Microsoft Access Enkel innebygget relasjonsdatabasesystem (kan erstattes med mer profesjonell database) Verktøy for ”å tegne” brukergrensesnitt Enkel visuell ”query builder” Wizarder for å lage makroer Visual Basic for Applications (VBA) Sluttbrukerverktøy? Godt egnet for utvikling av prototyper, for ”ekstrem programmering”, for systemer for små/mellomstore organisasjoner God integrasjon med andre Office programmer og med Windows 04.04.2017 kap. 9

Prototyping Bruk av effektive verktøy for å lage en første versjon av et system Kan være anvendbar eller bare en ”mock up” Prototypen kan i seg selv bli det ferdige systemet, eller en kan reprogrammere i annet verktøy/språk Med bedre prototyper viskes grensen ut mellom prototypeverktøy og sluttverktøy - prototypen blir det ferdige systemet Prototyper er spesielt aktuelle for interaktive systemer, der effektiviteten av det endelige systemet ligger i samspill mellom menneske og maskin, ikke alene i programvaren. Eller for å teste komplekse algoritmer, nye metoder, etc. 04.04.2017 kap. 9

Fordeler med prototyper En prototype er en håndfast ting, som ofte kan brukes direkte. Gir brukerne langt bedre idé om det ferdige systemet enn en kravspesifikasjon. Kan utvikles hurtig, en får god feedback tidlig i prosessen Ukjente og vanskelige deler kan prøves ut tidlig i prosjektet Kjapp utvikling er ofte essensielt i en dynamisk verden, en har behov for ny funksjonalitet nå, ikke om ett år. Om ett år vet en heller ikke hvordan omgivelsene vil være. Men: Prototyping erstatter ikke det initiale arbeidet med å vurdere hva kunden virkelig har behov for. En for tidlig prototype kan derfor være skadelig, da en i for stor grad fokuserer på den løsningsmetodikken som prototypen representere. 04.04.2017 kap. 9

Utviklingsprosess med prototype Analyse (brukermiljø, problemer, løsnings-metodikker, mål) Utvikling av prototype (f.eks. i Access) Slutt-testing av bruker Systemet i produksjon, (mindre endringer) Tid 04.04.2017 kap. 9

Open source Mye kode tilgjengelig på nett Spesielt i Java Mange utviklingsmiljøer baserer seg i stor grad på å sette sammen ferdige moduler Tilgangen kan være som i form av kode (som kan tilpasses), men også som ferdige moduler som kan nås via en programinterface (API). Så selv om vi utvikler et nytt system trenger vi ikke utvikle alt.

Analysefasen Viktigst Tar tid (også kalendertid) Iterativ Brukermedvirkning Arbeidsform: Møter og ePost Dokumentasjon som bruker kan lese, oppdateres daglig Deler av systemet kan være aktuelt å utvikle som prototyper (”mock-up”) 04.04.2017 kap. 9

Case: Modellprogram Programmet tar en geometribeskrivelse av et propellblad, gitt av kunde, og legger på arbeidsmonn Ideen er å lage modeller der det støpte emnet i utgangspunkt tilfredsstiller alle krav. Da unngås arbeid med å slipe ned bladet til det tilfredsstiller kravene. En første versjon av programmet lager en ny geometri, glatter snittkurver, m.m. Denne fungerer rimelig godt, men det er et problem at vi kan få avvik om kunden kun har gitt få data.

Eksempel – første versjon

Videreutvikling modellprogram Som et forskningsfinansiert program Flere løsninger: Ta utgangspunkt i parametrene som styrer geometrien, som lengde på hvert snitt, stigning m.m. og interpolere ut far disse (snitt i mellom, nye snitt på toppen) Alternativt, ta utgangspunkt i modellen fra første versjon, la bruker legge inn ekstra snitt, og glatte disse automatisk Ideen er at alle kundedata skal bevares, samtidig som vi kommer fram til et strømlinjeformet blad. La ned mye arbeid i å teste løsning 1, men denne fungerte ikke. Laget derfor løsning 2, som fungerer.

Bedre modell

I dette prosjektet Tenketid, 100 timer over ett år Testing av løsninger, 100 timer over to måneder Implementering av løsning, 50 timer over tre uker.

Forbedret Flere og flere kunder kan tilby en CAD modell Vi må imidlertid ta utgangspunkt i snitt-data (måleverdier for hvert snitt) Men ideen er nå å integrere løsningene over med en CAD modell

Utvikling av prototype Høy innsats av programmerer God kjennskap til verktøyet viktig Brukerne er lite involvert (stort sett for å avklare detaljer) Liten grad av iterasjon (boka sier høy grad av iterasjon, men vi har unnagjort denne delen i analysefasen) Utviklerne tester systemet selv (i første omgang) 04.04.2017 kap. 9

Igangsetting av systemet Innlegging av bakgrunnsdata (fra tidligere system) Brukerne gjør slutt-test Systemutviklerne ”stand-by” for å rette opp feil og mangler - høy aktivitet, men mest detaljer Ofte glidende overgang fra testing til produksjon Hyppige (men mindre) endringer i de første ukene, avtar deretter Nå får en gevinsten ved å ha gjort en god studie i starten 04.04.2017 kap. 9

CASE (Computer-Aided Software Engineering) Automatisering av strukturerte teknikker i programmeringsfasen CASE miljø består av: Informasjonslager (datastrukturer, komponenter og moduler, forretningsregler, prosjekthåndteringsdata) ”Frond-end” verktøy for planlegging og design (diagrammer, grafikk, automatiske konsistentsjekker….) ”Back-end” verktøy for å generere kode (ofte for flere plattformer) Arbeidsstasjon for utvikling (kraftig, gode grafiske egenskaper, stor skjerm) Timeboxing, garantert leveranse innen 120 dager. RAD - Rapid Application Development, tid er kritisk, ofte viktigere enn kompleksitet, funksjonalitet og annen ressursbruk 04.04.2017 kap. 9

Eksempel: DuPont Cable Management Services Kabling av telefon og data for eget firma Informasjonssystem som kunne gi data om alle kabler, utstyr m.m. Fleksibilitet viktig, stadig nye krav til nett (stemme, data, video) Tilpasningsdyktighet, for å kunne bruke systemet også i andre sammenhenger Bruk av CASE/RIPP (Rapid Iterative Production Prototyping) 04.04.2017 kap. 9

120 dagers ramme Fase 1: ”Go-ahead” (1 dag) Fase 2: Systemdefinisjon. Beskrive systemkomponenter, akseptansekriterier, sluttprodukt er en systembeskrivelse med fast pris som legges fram for kunden (29 dager) Fase 3: Timebox. Detaljerte design spesifikasjoner, iterative prototyper, endelige prototype (90 dager) Fase 4: Installasjon (1 dag) Kunden får nå 3 måneder til å vurdere om systemet gjør det det skal. Gjør det ikke det, får kunden pengene tilbake. Metoden egner seg best når kunden selv har gode ideer om behovet. 04.04.2017 kap. 9

Systemintegrasjon Store fordeler - ”store once - use many times”, enklere oppdatering, mer fleksibel bruk, høyere kvalitet… Vanskelig: Forskjellige systemer krever forskjellig typer av data, forskjellig kvalitet, oppdateringsgrad, etc. Vanskelig å tilfredsstille alle med et enhetlig system… Løsningsmetoder: Bruk av databasesystemer ERP - Enterprise Resource Planning Systems ”Middelware”, komponenter For mindre bedrifter: Integrasjon av ferdige systemer ved bruk av standarder som Office pakken, SQL, ODBC, VBA (Visual Basic for Applications) 04.04.2017 kap. 9

Software Development Light Krav til strategisk programvare: Tilpasset bedriften til enhver tid! Styrke bedriftens konkurransefortrinn Det krever: Bedriften har kontroll over programvaren Dynamisk programvare Implementasjon: 2 lags modell (Brukergrensesnitt og database) Endringsorientert programvare Reduksjon av koplinger Reduksjon av behovet for uttesting Egen artikkel – øving 04.04.2017 kap. 9

ERP (Enterprise Resource Planning) Integrasjon gjennom et totalsystem Store og kostbare system (SAP, Baan,…) Mye arbeid i tilpasning Norsk Hydro og Statoil, 1 milliard hver Felleskjøpet Trondheim, 100 millioner uten å lykkes Dell Computer bruke 200 millioner dollar før de skrinla sitt prosjekt Tids- og kostnadsoverskridelser er vanlige Mange fiaskoer Inneholder: Applikasjoner for ordreprosessering, produksjon, innkjøp, lager, planlegging, finans, regnskap, kundehåndtering (CRM), m.m. 04.04.2017 kap. 9

ERP problemer Størrelsen gir ekstra kompleksitet Integrasjon er vanskelig F.eks., hvilke data trenger vi om en person: For å selge henne en sykkel For å selge henne bilforsikring For å gi lån til luksusleilighet i utlandet For å gi henne fast ansettelse ERP systemer påvirker bedriftens måte å operere på. Hvor skal vi la systemet bestemme og hvor skal bedriften bestemme? Er bedriftens markeder og produksjonsmetoder forstått før en setter i gang? Er bedriftsmiljøet mottagelig for store endringer? 04.04.2017 kap. 9

Eksempel: Colgate-Palmolive Krise, tapte i konkurransen med andre, nedgang i salgsvolum og fortjeneste Desentralisert struktur med nasjonal og regional kontroll i mer enn 200 land Visjon: Bli et virkelig globalt selskap, sentralisert struktur, integrert forretningsmiljø med standardiserte prosesser Prototype i USA basert på SAP (ERP) Deretter full utbygging basert på SAP, Oracle (DBMS) og Solaris (Op.sys) - 270 servere, 3000 samtidige brukere, $430 millioner Økte salg, kortere leveringstider, mer sentralisere innkjøp, lavere kostnader, større lønnsomhet, mer effektiv IT drift Ledelsen klarte å overbevise bedriften om at dette var eneste mulig løsning Ideell for ERP: enkle produkter, globale produkter, kompleks logistikk 04.04.2017 kap. 9

”Middelware” - komponenter Mellom applikasjon og underliggende data, derav ordet. Består av standarder og komponenter Forenkler systemutvikling Sette sammen en applikasjon av ferdige komponenter 04.04.2017 kap. 9

Typer av komponenter 04.04.2017 kap. 9

Internett-baserte systemer 04.04.2017 kap. 9

Application Servers Virtuell applikasjonsserver tilbyr et sett av integrerte tjenester (integrasjon gjennom å lage et nytt lag) Konnektivitet til underliggende systemer Implementerer forretningsprosessene (”business logic”) Automatisering av lav-nivå prosesser (kodegenerering) Middelware, applikasjonsserveren mellom back-end systemene og klientene Ferdige komponenter (i MS- og Java-verdenen) Skalabilitet, applikasjonsserveren fordeler oppgavene mellom et sett av servere 04.04.2017 kap. 9

Web Services Vi er fra tidligere vant til å kunne utføre forskjellige tjenester på et dataanlegg (søking, lagring, beregninger…) Ideen med Web Services er å tilby samme funksjonalitet over mange anlegg, gjerne med forskjellige plattformer Ingen ny tanke, men ny innpakning Mange måter å implementere ideen på 04.04.2017 kap. 9

Beskrive tjenesten Alle opplysninger om Web tjenesten, inkl. data som det er behov for, legges inn i en formell beskrivelse. De som skal bruke tjenesten finner alle opplysninger her. Vi bygger en XML konverter rundt koden i vårt interne datasystem. Denne skal konvertere data (inn/ut) fra XML til det aktuelle prog. språket. 04.04.2017 kap. 9

Presentasjon/gjenfinning Vi kan sende en elektronisk forespørsel til et UDDI register for å finne aktuelle tilbydere. Gjennom UDDI kan vi presentere tjenesten utad (en slags “Gule sider”) 04.04.2017 kap. 9

Bruk Data (beløp, kontonr, m.m.) 04.04.2017 kap. 9

Teknologien er der Vi har altså teknologien for å implementere Web-services Gir muligheter for stor fleksibilitet Et standard grensesnitt mot omverdenen Web servicen kan så implementeres fritt Standardisering uten ensretting 04.04.2017 kap. 9

Eksempler Google Apps, epost, dokumentlagring, Office produkter m.m. – tilsvarende Lotus Notes men gratis/billig. Brukes av mange små firma. Banktjenester over nett rettet mot firma …vi vil helt sikkert se en kraftig utvikling her

Prosjektledelse Vellykkede prosjekter: Klare mål Konkret, start og slutt, mellomfaser 10% ledelse, 90% sunn fornuft Hovedproblem 1: Å holde oversikten Hovedproblem 2: Å begrense prosjektet 04.04.2017 kap. 9

Nøkkelfaktorer (store prosjekter) Bestem fundamentet: Standarder (konnektivitet, forenkling) Åpen arkitektur (gir fleksibilitet) Web-tilpasning (der dette er nyttig) Bruk utprøvede ferdige systemer og komponenter der dette er mulig Disiplin, planlegging, dokumentasjon, og ledelse Dokumenter systemkrav (kravspesifikasjon, prototyper) Kjøp tjenester, men vurdere leverandørene nøye (referanser) Planlegg konvertering av eksisterende data Etter implementering, fullfør dokumentasjon, manualer, etc. 04.04.2017 kap. 9

Fokus på data og funksjoner Software Engineering går i dag mot mer høynivå systemer Her kan en beskrive datatyper og funksjoner Kode kan genereres automatisk Fordel, det blir færre feil, færre små tuer som kan velte store lass Blant annet NASA bruker slike metoder. Gjennom sitt Universal Systems Language forsøker de å løfte systemutvikling ut over kode-nivået 04.04.2017 kap. 9

Nøkkelfaktorer (små prosjekter) Oversikt over hva som skal gjøres Notat: Systemspesifikasjon/behovsanalyse Gjennomdiskutert blant alle aktører Prøvet ut nye og ukjent teknologi, teknikker og metoder Første fase: Bare det aller nødvendigste Realistiske tidsplaner 04.04.2017 kap. 9

Internett-prosjekter Som andre prosjekter Mer kommunikasjon, samarbeid, iterasjon Problemer: Brukere av alle kategorier Ofte ingen mulighet for opplæring (intuitive systemer) Hjelp ikke alltid tilgjengelig Potensielt et stort antall samtidige brukere Noe svakere programvare og standarder Ikke full kontroll med ressurser (avh. av offentlige nett) Åpner for hacking, sabotasje, ”denial of service”, etc. Åpner mot konkurrenter 04.04.2017 kap. 9

Hva skal til? En årsak til at mange prosjekter feiler er uklare mål. En god gjennomarbeidet beskrivelse av hva en skal oppnå er helt nødvendig. En må også vurdere hvilke funksjoner en må ha, og hva som er bare “nice to have”. De siste kan med fordel utelates til en senere fase. En må ha en idé om løsningsmetoder og hvordan prosjektet skal gjennomføres. Realistiske kostnads og tidsrammer Pass på at insentivene til de som deltar er i overensstemmelse med overordnede insentiver