Innføring i The Rational Unified Process Bendik Bygstad NITH 1.time: Noen grunnproblemer i systemutvikling 2.time: Hovedprinsipper i RUP 3.time: Strukturen i et RUP-prosjekt 4.time: RUP og UML Bendik Bygstad 9.1.06 Høgskolen i Vestfold

Førsteamanuensis Bendik Bygstad Utdannelse 2005: PhD Computer Science. Universitetet i Aalborg 1987: Mag.art Universitetet i Oslo Erfaring 1999-: Norges Informasjonsteknologiske Høgskole NITH 1995-: Fagrevisor ISO 9000, BS7799. TI Sertifisering. 1991-99: IT-sjef: Teknologisk Institutt 1985-91: IT-konsulent: Department, konsulentfirma Bendik Bygstad 9.1.06 Høgskolen i Vestfold

Noen grunnproblemer i systemutvikling Hovedprinsipper i RUP Hva er en SW utviklingsprosess? Litt historikk: Hvilket problem forsøker vi å løse? Hvilke metoder brukes i Norge? Introduksjon til RUP RUP på ulike nivåer Hovedprinsipper Hovedstruktur i RUP-prosjekter Litt om kritikken mot RUP Bendik Bygstad 9.1.06 Høgskolen i Vestfold

Hva er en SW utviklingsprosess? En beskrivelse av hvem som skal gjøre hva, og hvordan, - for å utvikle et SW-produkt. Grunnmodell: Fra System Engineering Viktige rammebetingelser: Teknologi Verktøy Mennesker Organisasjon Bendik Bygstad 9.1.06 Høgskolen i Vestfold

Behovet for rammeverk for systemutvikling Litt historikk om software engineering. Periode Utviklingsprosess Problemer 60-tallet: Uformelle metoder NATO erklærte ”Softwarekrisen” i 1968. Løsning: Software Engineering. 70-tallet Fossefallsmetoden Brukerkrav fryses tidlig, før brukerne har sett systemet. 80-tallet Fossefallsvarianter Prototyping Fortsatt stivhet i fossefallsmetoden. Prototyping ikke skalerbart. 90-tallet Iterative og inkrementelle metoder Styring av evolusjonære prosjekter vanskelig. Økende kompleksitet i rammeverkene. 2000 - Ulike rammeverk: RUP, XP, Scrum, DSDM etc Fremdeles mange mislykkede prosjekter… Bendik Bygstad 9.1.06 Høgskolen i Vestfold

Hovedproblemer i systemutvikling Standish Group: Chaos Report 2000: - Vellykkede prosjekter: 28% - Problematiske prosjekter: 49% - Mislykkede prosjekter: 23% Hovedårsaker til mislykkede prosjekter: - Manglende brukerkrav - Uklare mål - Ufullstendige krav - Krav endres underveis - Manglende planlegging Bendik Bygstad 9.1.06 Høgskolen i Vestfold

Behovet for en utviklingsprosess (hvorfor kan vi ikke bare programmere…?) Mestre teknisk kompleksitet Fra krav til modell: Forstå behov Fra modell til komponent: Realisere løsning Fra komponent til produksjon: Sikre stabil drift Styre prosjekter Økonomisk Tid Kvalitet Bendik Bygstad 9.1.06 Høgskolen i Vestfold

Hvilke metoder brukes i Norge? Method Use 2003 Use 2002 Own method 78 % 79 % RUP 29 % 23 % XP 21 % 17 % MSF 19 % OPEN 11 % 0 % PSO 7 % Other methods 10 % 13 % Kilde: Fagerstrøm,A., Bygstad,B., Østensen,T. (2003): Adoption of systems development methods, and market orientation. An empirical investigation in Norway. Nokobit 2003. Bendik Bygstad 9.1.06 Høgskolen i Vestfold

Hva kjennetegner ’egen metode’? Own methodology is of Share of Own method Share of FSDM = “Yes” Iterative type 55 % 43 % Waterfall type 30 % 23 % Other type 10 % 7 % No answer 5 % Bendik Bygstad 9.1.06 Høgskolen i Vestfold

Introduksjon til RUP RUP er en prosessmodell for OO systemutvikling (Det finnes andre: OPEN, Catalysis, MSF, XP, DSDM...) Introdusert i 1999 Jacobson, Booch, Rumbaugh Bygger på Jacobsens arbeid hos Ericsson Software Engineering: Best Practice Andre kilder: Nygård/Dahl: Objektorientert programmering Boehm: Iterativ utvikling/risikohåndtering Tom Gilb: Inkrementell utvikling Mitroff: Stakeholders Software Engineering Institute: CMM etc Bendik Bygstad 9.1.06 Høgskolen i Vestfold

RUP på tre nivåer RUP er er prosessmodell for systemutvikling. Det er viktig å tilpasse RUP til typen av oppgave og omfanget av den. RUP er: I praktisk bruk: 1. Noen grunnleggende prinsipper Må følges (se neste side) 2. En beskrivelse av trinn i prosessen, og Følges i hovedsak, men de viktigste produkter (artifacts) tilpasses 3. Et stort smørgåsbord (3700 web-sider!) av aktiviteter teknikker, artifacts, Velges nøye etter behov templates etc Bendik Bygstad 9.1.06 Høgskolen i Vestfold

Hovedprinsipper i RUP Prinsipp Beskrivelse Use Case drevet Kilde: Gary Evans: Lightening up a heavyweight Prinsipp Beskrivelse Use Case drevet Arkitektur-sentrert Iterativ Inkrementell Styrt Hele systemet tar utgangspunkt i use cases, utviklet i Samarbeid med brukere. Hvert use-case viser til en tjeneste for en brukergruppe. Testing tar utgangspunkt i use cases. Arkitekturen viser (i ulike views) hvordan systemet er strukturelt bygget opp. Problemet og løsningen deles opp i mindre deler, som Utvikles gjennom iterasjoner, små prosjekter som resulterer I en release. Hver iterasjon bygger inkrementelt på resultatet av forrige Iterasjon. Prossesen er styrt, i den forstand at du alltid skal vite hva neste skritt er, og at alle artifacts som blir laget er underlagt konfigurasjonsstyring. Bendik Bygstad 9.1.06 Høgskolen i Vestfold

Hovedstruktur i RUP-prosjekt Bendik Bygstad 9.1.06 Høgskolen i Vestfold

Litt om kritikken mot RUP 2000: Beck: Extreme programming Vekt på kode, ikke modeller Tettere samarbeid med kunde Parprogrammering 2003: Respons fra Rational Mer vekt på programmerers ferdigheter ’Agile RUP’ 2005: Larman: Striden avblåst - ulike metoder til ulike behov Bendik Bygstad 9.1.06 Høgskolen i Vestfold