Del III. Ledelse av systemutvikling

Presentasjon om: "Del III. Ledelse av systemutvikling"— Utskrift av presentasjonen:

1 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 kap. 9

2 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) kap. 9

3 Waterfall (fossefalls) modell
kap. 9

4 Bedre: Spiralmodellen
kap. 9

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

6 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) kap. 9

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

8 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 kap. 9

9 Funksjonalitet kap. 9

10 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 kap. 9

11 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. kap. 9

12 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. kap. 9

13 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 kap. 9

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

15 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”) kap. 9

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

17 Eksempel – første versjon

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

19 Bedre modell

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

21 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

22 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) kap. 9

23 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 kap. 9

24 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 kap. 9

25 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) kap. 9

26 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. kap. 9

27 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) kap. 9

28 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 kap. 9

29 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. kap. 9

30 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? kap. 9

31 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) 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 kap. 9

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

33 Typer av komponenter kap. 9

34 Internett-baserte systemer
kap. 9

35 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 kap. 9

36 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å kap. 9

37 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. kap. 9

38 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”) kap. 9

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

40 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 kap. 9

41 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

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

43 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. kap. 9

44 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 kap. 9

45 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 kap. 9

46 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 kap. 9

47 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