Estimering. INF1050: Gjennomgang, uke 09

Transkript

1 Estimering INF1050: Gjennomgang, uke 09

2 Kompetansemål Estimering Hva og hvorfor? Estimeringsprinsipper Estimeringsprosessen Spesifikasjonsbasert testing / Strukturbasert testing Estimeringsmodeller COCOMO II / Planning Poker

3 Bakgrunn for estimering Hva? Hvorfor? Utfordringer Estimeringsprinsippene

4 Estimering: Hva? Estimering Beregne ukjente størrelser Danner grunnlag for anbud og budrunder Mål Utlede et sett med parametere som tilfører leveransen en høy grad av trygghet Man er sikker på å kunne levere et akseptabelt produkt gitt prosjektets rammer Hensyn Produktets egenskaper / funksjoner / kvalitetsattributter Innsats fra deltakere Øvrige ressurser Tidsrammer / Budsjett / Teknologi

5 Estimering: Hva? Hva kan estimeres? Kostnader Hvor mye vil utviklingen koste? Hvordan skal midlene disponeres? Tidsbruk Hvor lang tid vil utviklingen ta? Hvordan skal innsatsen fordeles? Ressurser Hvilke ressurser vil vi trenge?

6 Estimering: Hvorfor? Estimering Forutse en realistisk prosess Bedre planlegging av prosjektet Ressurs- og arbeidsfordeling Prioritering av arbeidsoppgaver Avgjøre prosjektets lønnsomhet / nytteverdi (gevinstrealisering) En slags garanti til kunden om at man kommer til å levere Bør levere realistiske anbud Utgangspunkt for styring og måling av fremgang i prosjektet Tids- og kostnadsrammer

7 Estimering: Utfordringer Estimering Vanskelig å mestre Sammenheng mellom estimat og kravspesifikasjon Kvaliteten på kravspesifikasjonen er toneangivende for nøyaktigheten av estimatet Utfordringer (domene- og prosjektrelaterte) Høy kompleksitet Prosjektets omfang (scope) er dårlig definert / endrer seg underveis Utviklingstider estimeres av ikke-utviklere Utviklere er altfor optimistiske Ikke nok tid settes av til testing av systemet

8 Estimering: Utfordringer Oppdragsgiverrelaterte utfordringer Forskjellen på det enkle og det umulige Utilstrekkelig kravspesifikasjon / uklare krav Lite kunnskap om oppgaven / problemet Feilaktige forventninger Politikk og organisasjonsdynamikk Kommunikasjonsproblemer med leverandør Avsetter for lite tid / ressurser til oppfølging Anbudsprosessen er kunstig Velger alltid laveste anbud

9 Estimering: Utfordringer Leverandørens utfordringer Mangel på erfaring med planlegging / gjennomføring av lignende prosjekter Fare for at man overfører irrelevante erfaringer Mangel på lærdom fra tidligere prosjekter Stort sett svært dårlige til å lære av tidligere erfaringer For lite fokus på risiko Overoptimisme / naivitet Det skjer ikke oss Valg av systemutviklingsprosess Mangel på kunnskap om hva som kjennetegner / påvirker de ulike prosessene Krav Aktører Risiko Utviklerteam Aktiviteter Kundeforhold Ressurser

10 Estimeringsprinsippene 1. Erfaring fra fortiden Basis for estimering Tidligere erfaringer fra lignende prosjekter 2. Kunnskap om fremtiden Kravspesifikasjonen kan endres Sluttproduktet endres Hva vet vi om prosjektets begrensninger? Tid, budsjett, kundehensyn 3. Justeringer for å overføre fortid til fremtid Justeringsfaktorer Hvilke hensyn må tas? Sett prosjektet i kontekst og juster for begrensninger

11 Gjennomgang av ukesoppgaver Ukens tema: Testing av programvare

12 Oppgave 1 Ved bruk av SCRUM er det vanlig å estimere brukerhistorier fra en backlog (prioritert av produkteier). Ved oppstart av hver Sprint estimeres historiene, ved å tildele story points. Brukerhistoriene vurderes mot hverandre (relativ estimering). Brukerhistoriene deles i oppgaver som estimeres hver for seg. Disse gis et tidsestimat (absolutt estimering) i timer. Under estimering benyttes Planning Poker Cards (1,2,3,5,8,13,21). Alle i teamet som har noe å gjøre med de ulike brukerhistoriene er med på estimering. For hver brukerhistorie legger alle ned et kort samtidig. Er det veldig store avvik, kan det bli en diskusjon.

13 Oppgave 1(a) Hva kan være grunnen til at det har blitt så populært å estimere på denne måten?

14 Oppgave 1(a): Løsningsforslag Hva kan være grunnen til at det har blitt så populært å estimere på denne måten? Fordeler med Planning Poker Flere hoder tenker bedre enn ett Teammedlemmene har ulike erfaringer Enkel og engasjerende måte å estimere på Inkluderer alle nødvendige parter fra utviklerteamet Spørsmål stilles og informasjon blir delt Store avvik må begrunnes og nye synsvinkler kommer frem Samtidig visning av estimater kan forbedre estimatet Det første estimatet vil ofte fungere som et anker / Man lar seg påvirke

15 Oppgave 1(b) Hva er årsaken til at man som regel benytter seg av relativ estimering av brukerhistorier?

16 Oppgave 1(b): Løsningsforslag Hva er årsaken til at man som regel benytter seg av relativ estimering av brukerhistorier? Spørsmål: Kan dette skipet frakte to lastebiler?

17 Oppgave 1(b): Løsningsforslag Hva er årsaken til at man som regel benytter seg av relativ estimering av brukerhistorier? Spørsmål: Kan dette skipet frakte to lastebiler? Kontekst: Skipet har tidligere fraktet tre lastebiler Forbedret beslutningsgrunnlag Hva gir denne informasjonen oss?

18 Oppgave 1(b): Løsningsforslag Hva er årsaken til at man som regel benytter seg av relativ estimering av brukerhistorier? Spørsmål: Kan dette skipet frakte to lastebiler? Svar: Ja. Mest sannsynlig. Relativ estimering Bruker kontekst (forhold) for å estimere skipets last

19 Oppgave 1(b): Løsningsforslag Hva er årsaken til at man som regel benytter seg av relativ estimering av brukerhistorier? Nøyaktig estimering av antall timer er svært krevende Vi er flinkere til å vurdere mengde / størrelse enn tid Kontekst og sammenligninger gir ofte en bedre forståelse Oppgavene vektes i henhold til hverandre Forholdet er uavhengig av hvem som utfører oppgaven Lettere å vurdere brukerhistorier opp mot hverandre Eksempel: En brukerhistorie tar X ganger så lang tid å implementere som en annen

20 Oppgave 1(c) Diskuter svakheter og problemer ved denne måten å estimere på. Både når det gjelder brukerhistorier og oppgaver.

21 Oppgave 1(c): Løsningsforslag Diskuter svakheter og problemer ved denne måten å estimere på. Brukerhistorier kan være vage / tvetydige Inneholder ofte for få / irrelevante detaljer Utviklere kan misforstå Løser et problem for enkelt / for komplisert Utviklere har begrenset med kjennskap til hva som kreves Mangel på erfaring fra lignende oppgaver / prosjekter Gjennomsnitt er ikke alltid et godt mål Median kan foretrekkes

22 Oppgave 1(c): Løsningsforslag Diskuter svakheter og problemer ved denne måten å estimere på. Øvrige ulemper ved gruppeestimering Ressurskrevende sammenlignet med individuell estimering Group think kan forekomme Ønske om harmoni påvirker avgjørelsene >> Alle er enige med sjefen Group polarisation Samlet er gruppen mer optimistisk enn hver enkelt

23 Oppgave 2 Diskuter om det er etisk forsvarlig at et programvarefirma bevisst bruker en tvetydig kravspesifikasjon for å estimere for lavt (tilby en lav pris) for å få en kontrakt, hvor de senere krever en høy pris for endringer i kravspesifikasjonen som de vet vil komme.

24 Oppgave 2: Løsningsforslag Etiske aspekter ved bevisst over- og underestimering Skaper en kunstig anbudsprosess Ingen har tiltro til estimatene Disse kommer uansett til å endre seg Hva skjer dersom alle følger samme praksis? Denne typen praksis kan virke ødeleggende i lengden Systemutviklere kan oppfattes som utspekulerte Systemutviklere tas ikke på alvor Viktig å bevare gode kunderelasjoner Viktig med gode referanser

25 Oppgave 2: Løsningsforslag Etiske aspekter ved bevisst over- og underestimering

26 Oppgave 3 Et programvarefirma har fått i oppgave å utvikle et sikkerhetskritisk system, designet for å kontrollere en radioterapimaskin for behandling av kreftpasienter. Systemet skal integreres i maskinen og kjøres på en spesialprosessor med et gitt minne (256 Mbytes). Maskinen kommuniserer med et pasientdatabasesystem, som henter inn detaljer om pasienten. Etter behandling oppdateres databasen. Ved bruk av COCOMO-metoden har innsatsen som kreves for å utvikle systemet blitt estimert til 26 månedsverk. Alle faktorer som påvirker kostnadene var satt til 1 da estimatet ble beregnet.

27 Oppgave 3(a) Forklar hvorfor dette estimatet bør justeres for å inkludere personell-, produkt-, og organisasjonsfaktorer.

28 Oppgave 3(a): Løsningsforslag Estimater som tar høyde for øvrige faktorer COCOMO-modellen Algoritmisk modell Estimat (månedsverk) = A * SIZE B * M A = Konstant faktor avhengig av type programvare og type organisasjon (2.94) Size = KSLOC Antall kodelinjer i 1000 (1000(K) Source Lines of Code) B = Basert på produktkompleksitet (størrelse, innovasjonsgrad) (1-1.5) Reflekterer økt innsats som følge av økt prosjektomfang M = Faktor baser på syv prosjekt- og prosessattributter

29 Oppgave 3(a): Løsningsforslag Estimater som tar høyde for øvrige faktorer M = Syv prosjekt- og prosessattributter (1 6) Produktkompleksitet (Reliability and complexity RCPX) Krav til gjenbruk Plattform Personellkapasitet Personellerfaring Tidsramme Supportfasiliteter (Reuse required RUSE) (Platform difficulty PDIF) (Personnel capability PERS) (Personnel experience PREX) (Schedule SCED) (Support facilities FCIL) Jo høyere tall, desto lenger tid vil prosjektet ta

30 Oppgave 3(a): Løsningsforslag Estimater som tar høyde for øvrige faktorer Et prosjekt handler om mer enn antall kodelinjer Personell-, produkt-, og organisasjonsfaktorer påvirker prosjektet Øvrige faktorer som påvirker prosjektet Hvilke ressurser man har til rådighet Utviklernes kompetanse, budsjett- og tidsrammer, teknologi Hvilken type produkt som skal utvikles Hvordan organisasjonen fungerer / disponerer ressurser Hvordan alt henger sammen Det store bildet

31 Oppgave 3(b) Foreslå fire faktorer som kan ha stor effekt på COCOMOestimatet, og foreslå mulige verdier for disse faktorene. Begrunn svaret.

32 Oppgave 3(b): Løsningsforslag Foreslå fire faktorer som kan ha stor effekt på COCOMOestimatet, og foreslå mulige verdier for disse faktorene. Produktkompleksitet: 2 Dette er et kritisk system, tilnærmet ingen toleranse for feil Det skal integreres med et eksisterende databasesystem Høye sikkerhetskrav Plattform: 1.5 Systemet skal kjøre på en eksisterende plattform med en rekke begrensninger Må man hente inn eksterne personer med domenekunnskap om plattformen?

33 Oppgave 3(b): Løsningsforslag Foreslå fire faktorer som kan ha stor effekt på COCOMOestimatet, og foreslå mulige verdier for disse faktorene. Personellerfaring: 2.5 Mange nye utfordringer som krever kompetanse innen området Viktig med erfarne utviklere Viktig med et samkjørt utviklerteam: Hvordan er gruppesammensetningen? Tidsramme: 2 Systemet er kritisk, og derfor estimeres det høyere enn for andre prosjekter Sannsynlig at det brukes lengre tid på testing og feilretting

34 Faresignaler for underestimering Høy usikkerhet og lang varighet på prosjektet Lite relevant erfaring Prosjektet er betydelig større enn tidligere prosjekter Sterkt ønske om å starte prosjektet fra de som estimerer Vanskelig å evaluere estimatene Prosjektleveranser med liten grad av fleksibilitet Manglende skille mellom prosesser for estimat, plan, og tilbud Kundens forventinger / budsjett er kjent for de som estimerer

35 Sammenligning av metoder

36 Spørsmål? Ta kontakt Yulai Fjeld uio.no Husk å inkludere emnekoden! Andre gruppelærere Delta på gruppetimene

37 Takk til Foilene er basert på Tidligere presentasjoner laget av Emilie Hallgren og Kristin Brænden Eksisterende forelesningsnotater av Dag Sjøberg og Yngve Lindsjørn Sommerville, I. (2010). Software Engineering (9th Edition). Pearson.

38 Takk for meg Neste uke : Prosjektledelse og teamarbeid