Hovedoppgave 2002 for Dataingeniører

Presentasjon om: "Hovedoppgave 2002 for Dataingeniører"— Utskrift av presentasjonen:

1 Hovedoppgave 2002 for Dataingeniører
Carsten Helgesen AI – Data HiB

2 Hovedoppgave for dataingeniører
Mål Utføre oppdrag hos ekstern oppdragsgiver Næringsliv FoU Levere et produkt til avtalt tid Erfaring i realistisk prosjektarbeid Del av eksamensarbeidet for Ingeniørutdanningen Dagens presentasjoner Prosjektstyring (CH) Iterativ utvikling (CH) Testing (Inger Lien Krabbestig)

3 Styringsregler: Murphy’s lover
Ingenting er så lett som det ser ut Alt tar lenger tid enn du tror Alt som kan gå galt vil gå galt Alt som kan gå galt vil gå galt på verst tenkelige tidspunkt Korollar: Hvis det finnes et verre tidspunkt, vil det gå galt da Hvis ingenting kan gå galt, går noe galt likevel 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 Ting som overlates til seg selv utvikler seg fra dårlig til verre Hvis alt ser ut til å gå bra, har du oversett noe Dessuten: Murphy var en optimist

4 Prosjektstyring – Hva inngår? (1)
Estimering Hva skal gjøres (aktiviteter) Oppgavene som skal løses Avhengigheter mellom oppgavene Hvor stor er oppgaven Estmering 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

5 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)

6 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 til Murphy 2: Alt tar lenger tid enn du tror

7 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:

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

9 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

10 Gantt diagram - Plan

11 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

12 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

13 Gantt diagram - Oppfølging
I dag

14 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

15 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

16 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

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

18 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

19 Risiko i fossefallsmodellen
T I D Integrasjon System Test Koding Analyse og design Kravspes.

20 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

21 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

22 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

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

24 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

25 Unified Process

26 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

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

28 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

29 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

30 Test Først – En god arbeidsvane
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å

31 Metode arvet fra Junit-klassen TestCase
Test Først - Eksempel Testdriver for metoden Sale.getTotal() Public class SaleTest extends TestCase { public void testTotal() { // sett opp testdata Money total = new Money( 7.5 ); Money price = new Money( 2.5 ); ItemID id1 = new ItemID( 1 ); ProductSpec spec1 = new ProductSpec( id1, price, ”Prod1” ); ItemID id2 = new ItemID( 2 ); ProductSpec spec2 = new ProductSpec( id2, price, ”Prod2” ); // opprett et salg Sale sale = new Sale(); sale.makeLineItem( spec1, 1 ); sale.makeLineItem( spec2, 2 ); // sjekk resultatet assertEquals( sale.getTotal(), total ); } Metode arvet fra Junit-klassen TestCase

32 ☺ 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 ☺

33 LYKKE TIL MED ABEIDET!