1 / 47

Del III. Ledelse av systemutvikling

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. Strukturert systemutvikling (1970…).

nanji
Download Presentation

Del III. Ledelse av systemutvikling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related