Hovedprosjekt 2003 for Dataingenirer Hovedprosjekt for dataingenirer Ml

Hovedprosjekt 2003 for Dataingeniører

Hovedprosjekt for dataingeniører ü Mål • Utføre oppdrag hos ekstern oppdragsgiver • Næringsliv • Fo. U • Levere et produkt til avtalt tid • Erfaring i realistisk prosjektarbeid • Del av eksamensarbeidet for Ingeniørutdanningen ü Dagens presentasjoner • Prosjektstyring (CH) • Iterativ utvikling (CH) • Prosjekter i praksis i næringslivet (Øystein Amland)

Styringsregler: Murphy’s lover 1. Ingenting er så lett som det ser ut 2. Alt tar lenger tid enn du tror 3. Alt som kan gå galt vil gå galt 4. Alt som kan gå galt vil gå galt på verst tenkelige tidspunkt Korollar: Hvis det finnes et verre tidspunkt, vil det gå galt da 5. Hvis ingenting kan gå galt, går noe galt likevel 6. Hvis du ser fire måter noe kan gå galt på, og du håndterer alle disse, vil en femte måte du ikke har tenkt på opptre når du minst aner det 7. Ting som overlates til seg selv utvikler seg fra dårlig til verre 8. Hvis alt ser ut til å gå bra, har du oversett noe Dessuten: Murphy var en optimist

Prosjektstyring – Hva inngår? (1) ü Estimering • Hva skal gjøres (aktiviteter) • Oppgavene som skal løses • Avhengigheter mellom oppgavene • Hvor stor er oppgaven • Estimering ü Planlegging • Hvilke ressurser er tilgjengelige • Tid - Tidsfrist • Penger - Budsjett • Mennesker – Prosjektgruppe + andre ressurser • Hvem gjør hva • Tildeling av aktiviteter til personer • Når gjøres hva • Tidsplanlegging

Prosjektstyring – Hva inngår? (2) ü Oppfølging • • • Hvordan er framdriften i henhold til planen? Hvilke aktiviteter ligger godt an? Hvilke aktiviteter er forsinket? Har noen problemer? Er det dukket opp uforutsette ting eller endringer? ü Korreksjon • • • Trenger noen hjelp? Omfordele arbeid? Flere folk? ( - vel, ikke i dette prosjektet) Endre løsningsmetode? Endre rekkefølge på aktiviteter? Endre strategi? ü Revidere planen • Endre tidsplan? (- vel, ikke i dette prosjektet)

Prosjektstyring - Estimering ü Mål: Gi et forslag til ressursbehov for et prosjekt • Totalt antall timer som medgår ü Prosess • • Bryt arbeidet ned i passende, mindre aktiviteter Estimer nødvendige ressurser for hver aktivitet Summer estimater for alle aktivitetene Legg til for prosjektmøter etc – Typisk 1 -3 timer per uke ü Det er vanskelig å spå, særlig om framtiden! • • Finnes mange metoder, men erfaringstall er essensielle En enkel metode: Lichtenberg modellen - virker bra i praksis Murphy 1: Ingenting er så lett som det ser ut Murphy 2: Alt tar lenger tid enn du tror

Lichtenberg estimeringsmodell (1) ü For hver aktivitet, oppgi… • Min - Minste tenkelige tid som trengs • Tro - Trolig tid som trengs • Max - Største tenkelige tid som trengs ü Modellen beregner for hver aktivitet… • Forventet tid: • Usikkerhet: ü Totalt estimat… • Forventet total tid: • Total usikkerhet:

Lichtenberg estimeringsmodell (2) ü Link på hjemmesiden for Hovedprosjekt 2002

Prosjektstyring - Planlegging ü Definere aktiviteter • Navn • Estimere omfang – Summen av total tid som medgår • Avhengigheter mellom aktiviteter – Hva kan gå i parallell ü Tildele ansvar • Hvem utfører hvilke aktiviteter ü Sette sammen aktivitetene til en helhet • • Total prosjektplan Kalendertid Milepæler PERT-diagram • Avhengigheter mellom aktiviteter • Kritisk sti = Korteste tiden prosjektet kan ta • Gantt-diagram • Viser aktiviteter på tidsskala • Kan også vise hvem som gjør hvilke aktiviteter

Gantt diagram - Plan

Prosjektstyring – Noen gullkorn If you fail to plan, you plan to fail. Plans are worthless. Planning is essential. Eisenhower A good plan today is better than a perfect plan tomorrow. Patton It is a mistake to look too far ahead. Only one link in the chain of destiny can be handled at a time. Winston Churchill

Prosjektstyring - Oppfølging ü Prosjektdeltagerne må rapportere… • Forbrukt tid på hver aktivitet • Estimert gjenstående tid på hver aktivitet • Problemer som har dukket opp ü Prosjektleder følger opp planen ved å… • Samle data fra prosjektdeltagerne • Plotte framdrift ved rapporteringstidspunkt ü Gantt-diagram • Visualisere oppgaver, ansvar og framdriftsplan • Følge opp framdrift

Gantt diagram - Oppfølging I dag

Prosjektstyring - Problemhåndtering ü Vær proaktiv – prøv å forutse problemer ü Ta fatt i problemer tidlig Ting som overlates til seg selv utvikler seg fra dårlig til verre. Murphys 7. Lov ü Ikke tro at problemer løser seg av seg selv ü Tilkall hjelp om nødvendig • Konkret kompetanse • Erfaring

Prosjektstyring – Time Boxing ü Ofte: Har kun tilgjengelig en viss tid for å gjøre en oppgave Enhver aktivitet vokser til å bruke all tilgjengelig tid. Parkinsons lov ü Time Boxing: Planlegge med å bruke kun tilmålt tid • • • Dele opp i aktiviteter Tildele hver aktivitet sin tilmålte tid Samlet tid summerer til total tilmålt tid Bruke kun tilmålt tid på hver aktivitet Passe klokken strengt! Gå videre når tiden er over. ü Prosjektoppgaven er av denne typen • Kompromiss mellom ideelt mål og tilgjengelige ressurser • Planlegging: Prosjektplanlegging + Time Boxing

Prosjektstyring - Risiko ü Prosjekter har alltid risiko • Ressurser • Mangler folk - Mangler penger • Kompetanse • Mangler kompetanse - Misforstår krav - Overser viktige krav • Kommunikasjon • Dårlig koordinering – Misforståelser – ”Dårlig kjemi” • Teknologi – Ny? • Klarer vi å utnytte den? - Er den god nok for vårt prosjekt? • Tidsfrister • Sykdom - Feilvurderer arbeidsomfang - Samarbeidspartnere ü Fjerne risiko • Identifisere risiko, evaluere effekt og sannsynlighet • Ha en plan for å håndtere risiko hvis den opptrer • Utvikle prototyper (del-løsninger) og teste dem tidlig

Utviklingsmodell - Fossefallmodellen ü Tradisjonelt: Fossefallsmodellen ü Fungerer dårlig i praksis for IT-prosjekter Kravspes. Analyse og design Koding Integrasjon System Test T I D

Faser i fossefallsmodellen ü Kravspesifikasjon • Beskrive fullstendig alle systemets egenskaper • Anta at de er uendret for resten av prosjektet ü Analyse og design • Utforme systemet i detalj: • Alle grensesnitt, komponenter, klasser, all kommunikasjon, fullstendig databaseskjema, etc. • Få endringer i design under koding ü Koding • Programmere alle komponentene i systemet slik beskrevet i designdokumentasjonen • Teste hver komponent - enhetstest ü Integrasjon • Integrere alle komponentene til et fullstendig system. ü Systemtest • Teste det fullstendige systemet

Risiko i fossefallsmodellen R I S I K O Kravspes. Analyse og design Koding Integrasjon System Test T I D

Utviklingsmodell - Iterativ utvikling (1) Iterasjon 1 Iterasjon 2 Iterasjon 3 Time Box: typisk 2 -4 uker • Komponenter med høy risiko utvikles i tidlige iterasjoner. • Hver iterasjon lager en kjørbar release • Hver release er fullstendig integrert og testet

Utviklingsmodell – Iterativ utvikling (2) ü Første prosjektplan • • • Grov plan for hele prosjektet Milepæler for alle iterasjoner Detaljert plan for første iterasjon Første estimater Vurdering av risiko ü I hver iterasjon… • • ”Mini” fossefall prosess Arbeide med ”små” tema om gangen Utvikle testet og kjørbar kode Tilbakemelding fra brukerne Aktiviteter som det ikke ble tid til utsettes til neste iterasjon Planlegg neste iterasjon i mer detalj Revurder estimater

Utviklingsmodell – Iterativ utvikling (3) ü Utvikle i bredden – ”vidt og grundt”… • Dekke alle deler av systemet i tidlige iterasjoner • Kritisk funksjonalitet tidlig • Fokus på samspill mellom ulike komponenter ü Risiko… • Angripe tema med høy risiko tidlig • Utvikle prototyper for å lære om risiko-områder • Revurder risiki - effekt og sannsynlighet

Risiko i iterativ utvikling Risiko Fossefall Risiko iterativ R I S I K O Iterasjon 1 Iterasjon 2 T I D Iterasjon 3

Iterativ utvikling - Essens ü Fokus i tidlige iterasjoner • Høyrisiko tema – ukjente, vanskelige • Bygge basisarkitektur • Bygge kritisk funksjonalitet ü Små steg • Kontinuerlig tilbakemelding fra brukerne • Time Box iterasjoner ü Iterativ (adaptiv) planlegging • Planlegge kun neste iterasjon i detalj • Milepæler for kommende iterasjoner • Revurdere estimater fortløpende ü I hovedprosjektet: Trolig… • 2 ukers iterasjoner • Tilbakemelding fra brukerne etter hver iterasjon • Kontinuerlig testing

Unified Process

Unified Process – Disipliner ü Business modelling – Virksomhetsmodellering • Modellere data og prosesser i virksomheten med UML ü Requirements – Kravspesifikasjon • Beskrive funksjonelle krav med Use Case • Ikke-funksjonelle krav – ytelse, påtrykk, etc ü Analysis and Design - Analyse og design • Arkitektur, komponenter, objekter, databaser, nettverk etc • Analyse: Fokus på virksomheten – Hva skjer med hvilke data • Design: Fokus på tekniske løsninger - Hvordan skal det virke ü Implementation – Implementasjon ü Test – Testing • Enhets- og Integrasjonstest ü Deployment – Utrulling

Unified Process – Faser (1) ü Inception • • Forstå siktemål og nytte av systemet i virksomheten Første utkast til kravspesifikasjon Omfang - initielle estimater Hovedvekt: Overordnet forståelse av krav og omfang. ü Inception = Forprosjektet i hovedoppgaven • Problembeskrivelse • Risikovurdering • Tidsplan Krav til leveranse ü Elaboration • • • Videreutvikle kravspesifikasjon Iterativ utvikling av basisarkitektur og kritisk funksjonaliteten Fokus på risiko - utvikle deler med høy risiko først I hver iterasjon: Fullstendig integrasjon og testing av all kode Hovedvekt: Kravspesifikasjon, analyse og design. Noe koding.

Unified Process – Faser (2) ü Construction • • Iterativ utvikling av resten av funksjonaliteten I hver iterasjon: Fullstendig integrasjon og testing av all kode Forberedelser for utrulling (deployment) Hovedvekt: Koding. Noe design. ü Transition • • Beta testing Utrulling hos brukerne Opplæring av brukerne Hovedvekt: Utrulling, feilretting

Testing ü Testing er essensielt for å sikre at systemet fungerer korrekt Alt som kan gå galt vil gå galt. Murphys 3. lov Hvis du ser fire måter noe kan gå galt på, og du håndterer alle disse, vil en femte måte du ikke har tenkt på opptre når du minst aner det. Murphys 6. lov

Test Først – En god arbeidsvane ü Test Først • • • Testing av hver enkelt klasse - Enhetstesting Praksis fra Extreme Programming (XP) Skriv en testdriver for en klasse før klassen selv skrives Testdriver og klasse kan eventuelt skrives i parallell Fordeler: • Testkode for enhetstestene blir faktisk skrevet! • Kan kjøre testene igjen senere for se om nye feil er introdusert • Oppklarende for design • Kan ”bevise” korrekthet ved å kjøre alle testene ü JUnit – Nyttig verktøy for å skrive testdrivere • Se mer på www. junit. org

Test Først - Eksempel ü Testdriver for metoden Sale. get. Total() Public class Sale. Test extends Test. Case { public void test. Total() { // sett opp testdata Money total = new Money( 7. 5 ); Money price = new Money( 2. 5 ); Item. ID id 1 = new Item. ID( 1 ); Product. Spec spec 1 = new Product. Spec( id 1, price, ”Prod 1” ); Metode arvet fra Junitklassen Test. Case Item. ID id 2 = new Item. ID( 2 ); Product. Spec spec 2 = new Product. Spec( id 2, price, ”Prod 2” ); // opprett et salg Sale sale = new Sale(); sale. make. Line. Item( spec 1, 1 ); sale. make. Line. Item( spec 2, 2 ); } // sjekk resultatet assert. Equals( sale. get. Total(), total ); }

Et siste råd på veien… ü Fokus på produktet og brukernes behov ü Fokus på risiko ü Bygge basisarkitektur tidlig ü Bygge kritisk funksjonalitet tidlig ü Bygge systemet iterativt - ”Bredt og vidt” ü Planlegge og følge opp ü What Every Computer Consultant Needs to Know: 1) In case of doubt, make it sound convincing. 2) Do not believe in miracles. Rely on them. Murphy ☺

LYKKE TIL MED ABEIDET!