Del III. Ledelse av systemutvikling

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: • ”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) - 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 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