Elementer av en utviklingsprosess Johannes Brodwall

Hva inngår i prosessbeskrivelsen Trygghet: Prosjektegenskaper Enhetlighet: Standard-artifakter Effektivitet: Prosessbeskrivelse Andre muligheter: Prosjektsammensetning Faglig koordinering

Prosjektegenskaper Hyppige leveranser Tett kommunikasjon I prosjektgruppen Mellom prosjektet og sponsor Reflektert forbedring: Prosjektet eier prosessen Personlig trygghet Fokus: Personer og prosjekter Tilgang til domeneeksperter Tilstrekkelig teknisk miljø Dette er listen over egenskaper Alistair Cockburn har observert som kritisker for at et prosjekt skal lykkes

Kritiske (påkrevde) artefakter “Brukermodell” Mandat Fremdriftsplan Krav “prosjektmotor” Programvare Ekstern dokumentasjon Test “Leveranse” Jeg liker ikke navnet “brukermodell”, men har ikke funnet noe bedre. Listen er destilert fra RUP, Crystal Clear og Extreme Programming RUP: Stakeholder request, Vision og Business case er forenklet og slått sammen til Mandat. Specification er byttet ut med krav og til en viss grad brukermodell. Deployment plan faller utenfor U04. Designmodell er fjernet. Analyse og Glossary er slått sammen til domenemodell. Arkitekturdokument er ikke påkrevet. Testplan er byttet ut med test XP: Følgende er ikke beskrevet i XP: Mandat, brukermodell, domenemodell og risikostrategi. Domenemodell og brukermodell erstatter XP’s System Metafor Crystal Clear: Mandat svarer til “Mission Statement”. Krav og brukermodell er anderledes strukturert. Actor-goal list, User Role Model og Use Case Model (til en viss grad) er “Brukermodell”. I tillegg beskriver Crystal Design Notes (intern eller i arkitektur), Iteration Plan (fremdriftsplan), Project Map (fremdriftsplan), Project Status (fremdriftsplan), Viewing Schedule (fremdriftsplan), Screen drafts (intern), Bug Report (???). Risikostrategi brukes i stedet for Risikoliste (Crystal, RUP), ettersom listebegrepet ofte misforståes Støtteartefakter Prosjekt-standarder Risiko-strategi Domene-modell Arkitektur-beskrivelse?

Kort beskrivelse Per artefakt: Alle artefakter bør revideres ved hver leveranse Mandat: Hvem betaler (sponsor), hvem er interessentene (brukere og andre)? Hva er det overordnede målet? Hva er budskjettmessige begresninger? Hva er viktige prioriteringer, og hva kan ofres? Krav: Se “User Stories Applied” Funksjonelle krav: INVEST Individuelle: Hver krav skal kunne implementeres individuelt Negosjerbare: Verdifulle for sponsor eller bruker Estimerbare (+/- 50% per krav, +/- 20 % for totaliteten av krav) Små: Typisk ikke over noen ukeverk per krav Testbare Ikke-funksjonelle krav: Setter begrensninger for resten av systemet. Må være testbare! Kravene bør ikke ta mer enn noen dager å komme fram til. De bør gjennomgåes ved hver iterasjon Formålet med kravdokumentet er ikke å spesifisere systemet, kun å ha grunnlag for estimater og planlegging Test: Bør være automatiske. Spesifiserer kravene i detalj Programvare: Tilfredstiller krav ved å passere tester. Ekstern dokumentasjon: SLA, driftsmanual, brukermanual Leveranse: Bør være rimelig hyppige Plan: Alle krav i prioritert rekkefølge, oppdateres med framdrift Risikostrategi: Risikoliste, plan for hver risiko, generell risikoplan (se “Slack”…) Domenemodell: Modell: 12 : a system of postulates, data, and inferences presented as a mathematical description of an entity or state of affairs Formål er å gi utvikling, test og sponsor en felles begrepsforståelse Se “Domain Driven Design” Prosjektstandarder: SCCS Kodestandard Brukermodell: Roller, Persona, Narratives/Goal (Cooper, Lockwood, Constantine) Per artefakt: Hva er formålet? Hvem skal benytte artefakter? Hvilke kriterier avgjør om man skal benytte artefakten? Hvem skal utvikle den? Hvem skal støtte? Hvem skal godkjenne? Hvor omfattende skal den være? Skjekkliste/mal på innhold og kvalitet MERK: Testene er den detaljerte kravspesifikasjonen! Dette er en såkalt “zippered process” http://c2.com/cgi/wiki?FoldedZipperedProcess

Prosessbeskrivelse Scrum Kvalitetsforbedring – hvordan? Daglige møter Faglig koordinering (Scrum-of-Scrums) Iterasjoner og leveranser – arbeid per iterasjon Framdrift via earned-value charts Kvalitetsforbedring – hvordan? Leveranseprosess Leveransetest Produksjonssetting

Arbeidsform Release starter Releasemøte: Mandat, brukermodell og krav revideres, plan revideres Iterasjon starter Iterasjonsmøte: Krav revideres, velges ut, risikostrategi revideres Kontinuelig: Oppdater software, tester, dokumentasjon Etter behov: Oppdater Standarder, risikoliste, domenemodell Iterasjonsavslutning: Demo, Plan oppdateres, domenemodell revideres Release: Demonstrasjon og eventuell installasjon av programvare. Plan revideres

Arbeid U04 revidert: Beskriv alle artefakter Beskriv arbeidsprosessen per artefakt Beskriv arbeidsprosessen per steg i iterativ utvikling Beskriv sertifiseringskrav Beskriv kvalitetskrav i utviklingsprosessen (hvem er ansvarlig for hvilken testing?) Hint: det er minst 3 testere: Teknisk test, funksjonell test (plus lasttest og stresstest) og produksjonstest CM? http://www.cmbok.com/, http://www.scmpatterns.com/book/SCMPatterns-RefCard.pdf

"The creation of genuinly new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line" - Bollinger http://www.idiom.com/~zilla/Work/Softestim/kcsest. pdf