Del III Ledelse av systemutvikling n Kap 9

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

Strukturert systemutvikling (1970…) n n n n n 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) 9/25/2021 kap. 9 2

Waterfall (fossefalls) modell 9/25/2021 kap. 9 3

Bedre: Spiralmodellen 9/25/2021 kap. 9 4

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

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

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

4 generasjons programmeringsspråk n n 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: n n n Inkluderer databasesystem Inkluderer verktøy for å utvikle brukergrensesnitt + programmeringsspråk Wizards for standardoperasjoner Eksempler: Access, Visual Cafe og tyngre miljø som. Net 9/25/2021 kap. 9 8

Funksjonalitet 9/25/2021 kap. 9 9

Eksempel: Microsoft Access n n n n 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 9/25/2021 kap. 9 10

Prototyping n n n 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. 9/25/2021 kap. 9 11

Fordeler med prototyper n n n 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. 9/25/2021 kap. 9 12

Utviklingsprosess med prototype Analyse (brukermiljø, problemer, løsningsmetodikker, mål) Utvikling av prototype (f. eks. i Access) Slutttesting av bruker Tid 9/25/2021 kap. 9 Systemet i produksjon, (mindre endringer) 13

Open source n n n 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 n n n Viktigst Tar tid (også kalendertid) Iterativ Brukermedvirkning Arbeidsform: Møter og e. Post Dokumentasjon som bruker kan lese, oppdateres daglig Deler av systemet kan være aktuelt å utvikle som prototyper (”mock-up”) 9/25/2021 kap. 9 15

Case: Modellprogram n n n Programmet tar en geometribeskrivelse av et propellblad, gitt av kunde, og legger på arbeidsmonn Ideen er å lage modeller det støpte emnet i utgangspunkt tilfredsstiller alle krav. Da unngås arbeid med å slipe ned bladet 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 n n Som et forskningsfinansiert program Flere løsninger: 1. 2. n n n 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 n n n 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 n n n Flere og flere kunder kan tilby en CAD modell Vi må imidlertid ta utgangspunkt i snittdata (måleverdier for hvert snitt) Men ideen er nå å integrere løsningene over med en CAD modell

Utvikling av prototype n n n 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) 9/25/2021 kap. 9 22

Igangsetting av systemet n n n 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 9/25/2021 kap. 9 23

CASE (Computer-Aided Software Engineering) n n Automatisering av strukturerte teknikker i programmeringsfasen CASE miljø består av: n n n 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 9/25/2021 kap. 9 24

Eksempel: Du. Pont Cable Management Services n n n 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) 9/25/2021 kap. 9 25

120 dagers ramme n n n 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 skal. Gjør det ikke det, får kunden pengene tilbake. Metoden egner seg best når kunden selv har gode ideer om behovet. 9/25/2021 kap. 9 26

Systemintegrasjon n 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: n n 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) 9/25/2021 kap. 9 27

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

ERP (Enterprise Resource Planning) n n n Integrasjon gjennom et totalsystem Store og kostbare system (SAP, Baan, …) Mye arbeid i tilpasning n n n 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. 9/25/2021 kap. 9 29

ERP problemer n n Størrelsen gir ekstra kompleksitet Integrasjon er vanskelig n n F. eks. , hvilke data trenger vi om en person: n For å selge henne en sykkel n For å selge henne bilforsikring n For å gi lån til luksusleilighet i utlandet n 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? 9/25/2021 kap. 9 30

Eksempel: Colgate-Palmolive n n n n 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 9/25/2021 kap. 9 31

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

Typer av komponenter 9/25/2021 kap. 9 33

Internett-baserte systemer 9/25/2021 kap. 9 34

Application Servers n n n n 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 9/25/2021 kap. 9 35

Web Services n n 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å 9/25/2021 kap. 9 36

Beskrive tjenesten 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. 9/25/2021 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. kap. 9 37

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

Bruk Data (beløp, kontonr, m. m. ) 9/25/2021 kap. 9 39

Teknologien er der n n n 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 9/25/2021 kap. 9 40

Eksempler n n n 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 n Vellykkede prosjekter: n n n Klare mål Konkret, start og slutt, mellomfaser 10% ledelse, 90% sunn fornuft Hovedproblem 1: Å holde oversikten Hovedproblem 2: Å begrense prosjektet 9/25/2021 kap. 9 42

Nøkkelfaktorer (store prosjekter) n Bestem fundamentet: n n n n n Standarder (konnektivitet, forenkling) Åpen arkitektur (gir fleksibilitet) Web-tilpasning (der dette er nyttig) Bruk utprøvede ferdige systemer og komponenter 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. 9/25/2021 kap. 9 43

Fokus på data og funksjoner n n n 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 9/25/2021 kap. 9 44

Nøkkelfaktorer (små prosjekter) n n n 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 9/25/2021 kap. 9 45

Internett-prosjekter n n n Som andre prosjekter Mer kommunikasjon, samarbeid, iterasjon Problemer: n n n n 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 9/25/2021 kap. 9 46

Hva skal til? n n n 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