Innføring i The Rational Unified Process

Presentasjon om: "Innføring i The Rational Unified Process"— Utskrift av presentasjonen:

1 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 Høgskolen i Vestfold

2 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. : IT-sjef: Teknologisk Institutt : IT-konsulent: Department, konsulentfirma Bendik Bygstad Høgskolen i Vestfold

3 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 Høgskolen i Vestfold

4 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 Høgskolen i Vestfold

5 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 Høgskolen i Vestfold

6 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 Høgskolen i Vestfold

7 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 Høgskolen i Vestfold

8 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 Høgskolen i Vestfold

9 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 Høgskolen i Vestfold

10 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 Høgskolen i Vestfold

11 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 Høgskolen i Vestfold

12 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 Høgskolen i Vestfold

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

14 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 Høgskolen i Vestfold