Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

10.07.2014kap. 91 Del III. Ledelse av systemutvikling Kap. 9 Teknologier Strukturert utvikling Verktøy Prototyper Open source Integrasjon av systemer Internett-baserte.

Liknende presentasjoner


Presentasjon om: "10.07.2014kap. 91 Del III. Ledelse av systemutvikling Kap. 9 Teknologier Strukturert utvikling Verktøy Prototyper Open source Integrasjon av systemer Internett-baserte."— Utskrift av presentasjonen:

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

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

3 kap. 93 Waterfall (fossefalls) modell

4 kap. 94 Bedre: Spiralmodellen

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

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

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

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

9 kap. 99 Funksjonalitet

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

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

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

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

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

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: 1.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) 2.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 kap. 922 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)

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

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

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

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

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

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

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

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

31 kap. 931 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

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

33 kap. 933 Typer av komponenter

34 kap. 934 Internett-baserte systemer

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

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

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

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

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

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

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

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

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

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

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

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


Laste ned ppt "10.07.2014kap. 91 Del III. Ledelse av systemutvikling Kap. 9 Teknologier Strukturert utvikling Verktøy Prototyper Open source Integrasjon av systemer Internett-baserte."

Liknende presentasjoner


Annonser fra Google