PLAN. IN 331 Produkt og prosessforbedring i systemutvikling DEL 4 Valg av prosessmodell. Geir Amsjø.

Transkript

1 ACT PLAN IN 331 Produkt og prosessforbedring i systemutvikling DEL 4 Valg av prosessmodell Geir Amsjø geirams@ifi.uio.no, geir.amsjo@spitia.no DO CHECK 4 Oktober 2002 IN331 1 Først litt om prosjekter Når en organisasjon ser behov for å løse et konkret problem som skiller seg fra vanlig drift vil den ofte starte et prosjekt, for å sikre full fokus på problemløsningen og for å kunne delegere ansvaret til den best egnede personen. Det finnes et utall av filosofier, organiseringsformer, metoder og verktøy rundt prosjektstyring og prosjektledelse. Tradisjonell tankegang tilsier at prosjektleder belønnes for vel gjennomført prosjekt. Hun skal få privilegiet å fokusere på prosjektets målsetning og vil instinktivt forsøke å unngå at målet endrer seg. (Vanskeligere å treffe bevegelige mål). Stabilitet fremfor endringsvillighet. 4 Oktober 2002 IN331 2

2 Organisering av prosjekt Basisorganisasjon kontra prosjektorganisasjon Project Manager influence 80% Line Manager influence 20% Autonomous Project Matrix Balanced Matrix Func. Matrix Internal 4 Oktober 2002 IN331 3 Prosjektstyring - tradisjonellt Level of influence Cost of defects Management involvement (innovative) Management involvement Plan Analyse Develop Test Deliver 4 Oktober 2002 IN331 4

3 Fra idé til effekt Linjeorganisasjonen definerer prosjekt med klart resultatmål, følger opp prosjektene og tar ut effekten av resultatet fra prosjektet Resultat Define project Execute project Terminate project No-go No-go No-go Evaluation phase Go Establish steering group Go Follow up project Maintain product Effekt 4 Oktober 2002 IN331 5 S-kurve Cost t Time 4 Oktober 2002 IN331 6

4 Prosessmodell overblikk Prosessmodeller på 3 nivåer: "Globalt nivå", organisasjonsnivå og prosjektnivå Pre-defined process models RUP, XP, Cleanroom... Inspires Generic Process model Project type 1 process model Project type 2 process model Project type n process model 4 Oktober 2002 IN331 7 Det vanskelige valget... Det første man må bestemme seg for er om man faktisk har behov for en veldefinert prosessmodell. Helhjertet! For å gjøre valget er det viktig å kjenne seg selv. Dette er overraskende vanskelig. Hvilke kjennetegn skal vi se etter? Hva er det som betyr mest for valg av prosessmodell? Kan vi bruke samme modell overalt, eller trenger vi varianter (eller kanskje et repertoar av ulike modeller)? Hovedkategorier av prosessmodeller: Vannfall (sekvens) Inkrementell (oppdeling) Evolusjonær (repeterende) 4 Oktober 2002 IN331 8

5 Vannfallsmodell Requirements Analyse Design Implement Integrate System test Product Velprøvd, veldokumentert modell Velegnet til trinnvis nedbrytning Er enkel prosjektstyrningsmessig Krever stabilitet Krever nøye analyse og planlegging Leder til big-bang integration 4 Oktober 2002 IN331 9 Evolusjonær: Code and Fix Code Fix Deliver God modell for prototyping Gir maksimal fleksibilitet Krever lav kompleksitet Leder til lav kvalitet Leder til dårlig vedlikeholdsbarhet 4 Oktober 2002 IN331 10

6 Evolusjonær: extreme Programming 4 Oktober 2002 IN Evolusjonær Gilb s EVO 4 Oktober 2002 IN331 12

7 Inkrementell: MSF Microsoft Solution Framework: Process View Z I L STABI NG I Release ENV I S I O N I N G Scope Complete Vision Approved D E OPI EL V N G Project Plan Approved N P L AN G N I 4 Oktober 2002 IN MSF inspirert prosessmodell 4 Oktober 2002 IN331 14

8 Inkrementell - Cleanroom Hvordan planlegge omfang og rekkefølge av inkrementer? Høy risiko først? Det sikre først? Små eller store? Teknologidrevet rekkefølge? Even-Andre Karlsson, "A construction planning process", 3rd annual International Conference on Cleanroom Software Engineering Practices, 9-11 October 1996, College Park, Maryland, USA 4 Oktober 2002 IN Evolusjonær/inkrementell - RUP Rational Unified Process: Process Workflows Inception Elaboration Phases Construction Transition Business modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Change & Configuration Mgmt Project Management Environment Preliminary Iteration(s) #1 #2 #n #n+1 Iterations #n+2 #m #m+1 4 Oktober 2002 IN331 16

9 The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 4 Oktober 2002 IN Alistair Cockburn En av initiativtagerne bak The Agile Alliance Kjent for bøkene Writing effective Use-cases og Agile Software Development Har publisert en rekke artikler om Objektorientering, Use-cases og menneskeorienterte metoder. Startet selskapet Humans and Technology der han nå virker som konsulent. Sitat fra artikkel i Crosstalk, Okt 2002: Being agile is a declaration of prioritizing for project maneuverability with respect to shifting requirements, shifting technology, and a shifting understanding of the situation. Other priorities that might override agility include predictability, cost, schedule, process-accreditation, or use of specific tools. NB: Link til Crosstalk Okt 2002 (en rekke artikler om Agile Software Development) ligger på IN331 hjemmesiden. 4 Oktober 2002 IN331 18

10 Alistair Cockburn - tradeoffs Different projects need different methodology trade-offs. A little methodology does a lot of good; after that, weight is costly. Larger teams need more communication elements. Projects dealing with greater potential damage need more validation elements. Formality, process, and documentation are not substitutes for discipline, skill, and understanding. Interactive, face-to-face communication is the cheapest and fastest channel for exchanging information. Increased communication and feedback reduces the need for intermediate work products. Concurrent and serial development exchange development cost for speed and flexibility. Efficiency is expendable in non-bottleneck activities. Sweet spots speed development. 4 Oktober 2002 IN AC- Lokalisering av sweet-spot Planlegging er et onde og må minimaliseres For lite planlegging For mye planlegging 4 Oktober 2002 IN331 20

11 AC - Prosjektkategorisering Any one methodology is likely to be appropriate for only one of the boxes on one of the planes. Thus, at least 150 or so methodologies are needed! 4 Oktober 2002 IN AC - Vektlegging av metodikk Et minimum av metodikk er alltid bra. Etter det koster det for mye! 4 Oktober 2002 IN331 22

12 Avveiing basert på dyktighet Formalisme, Prosess og Dokumentasjon kan ikke erstatte disiplin, dyktighet og forståelse 4 Oktober 2002 IN Forenklet Prosjektkategorisering Rich McCabe and Michael Polen Software Productivity Consortium NB: Er også å finne på Crosstalk, Okt Oktober 2002 IN331 24

13 Konklusjoner (?) Utvalget av (mer eller mindre) veldefinerte modeller begynner å bli stort! Trangen til å hoppe på nye, moderne metoder virker stor; ønsket om at noen endelig har funnet the Silver Bullet er tilstede. De mest fremtredende parameterne til prosessvalg går på dimensjonene prosjektstørrelse og kritikalitet. Øvelse: Hva skjedde med ønsket om stabilitet? Er det ikke mulig å bli for endringsvillig? Endringer medfører omarbeiding ( rework ), gjør det ikke? 4 Oktober 2002 IN331 25