Unified Process (UP)

Unified Process (UP) Scott Kendall(2002) The Unified Process Explained Historia Luennon sisältö UP prosessin periaatteet Perusperiaatteet Iteraatio, inkrementti, julkaisu Unified process kuvaus Tehtäväkokonaisuudet Iteraatiot ja tehtäväkokonaisuudet Neljä vaihetta UP onnistumiset ja haasteet Rational Unified Process

Historia Requirements college Rational näkemys OMT Booch Rational Unified Process 5.0 1998 Rational Objectory Process 4.1 1996-1997 Objectory Process 1.0-3.8 1987-1995 Toimintotestaus Suorituskyky testaus Vaatimusten hallinta Muutosten hallinta Business engineering Data engineering Käyttöliittymäsuunnittelu SQA prosessi UML 1.0 UML 0.5 kehitys Ericssonilla Ivar Jacobson 1960-luvulla UP prosessin perusteet 1/2 Peräkkäiset iteraatiot, joista jokainen muodostaa oman vesiputouksensa Iteroiva vaihetuotteen kehittäminen Perusperiaatteet 1. Iteratiivinen ja inkrementaalinen 2. Käyttötapausohjattu 3. Ohjelmistoarkkitehtuurikeskeinen 4 päävaihetta, joiden sisällä on viisi tehtäväkokonaisuutta; Tehtäväkokonaisuussykliä voidaan iteroida saman vaiheen sisällä useita kertoja

UP prosessin perusteet 2/2 Päävaiheet Aloitusvaihe (inception) Tuotekonseptin vaihtoehtojen kartoitus Tarkentamisvaihe (elaboration) Perusarkkitehtuurin kiinnittäminen ja projektisuunnittelu Konstruktiovaihe (construction) Iteratiivinen (beta)testiversioiden toteutus, kehittäminen käyttökokemusten ja palautteen mukaan, tuotteen toteutus Luovutusvaihe (transition) Tuloksena saadaan paketoitu valmis järjestelmä, tuotteen siirto asiakkaalle Tehtäväkokonaisuudet Vaatimusten määrittely (requirements) Analyysi (analysis) Suunnittelu (design) Toteutus (implementation) Testaus (test) Perusperiaatteet 1/6 1. Käyttötapausohjattu Käyttötapaukset ohjaavat koko kehitystyötä; käyttötapauksien keräämisestä alkaen koodin tekemiseen ja testaukseen asti. Järjestelmän käyttöön liittyvä työ- tai tehtäväkokonaisuus, joka tuottaa lisäarvoa käyttäjälle/käyttäjille, jossa toimijoina ovat käyttäjät Kuvataan mitä toimintoja järjestelmältä vaaditaan. Kuvaus koostuu käyttäjistä ja käyttötapauksista käyttäjien ja järjestelmän välillä. Käyttäjät eivät ole tietojärjestelmän osa. Ne voivat syöttää tietoa järjestelmään tai vastaanottaa tietoa järjestelmästä. Käyttäjät voivat olla paitsi ihmisiä, myös toisia tietojärjestelmiä, jotka kommunikoivat tämän järjestelmän kanssa ohjelmien välityksellä.

Perusperiaatteet 2/6 1. Käyttötapausohjattu Hyötyjä Kuvaa vaatimukset järjestelmän käyttäjän näkökulmasta Käyttötapaukset kirjoitettu tavallisella kielellä mahdollisuus ymmärtää paremmin Vaatimusten jäljitettävyys paranee Työ pystytään pilkkomaan palasiksi ja jakamaan osaprojekteille Tavoitteita: Looginen prosessi vankkaa järjestelmää kohti Muuttuvien vaatimusten kanssa toimiminen Taipuisa muuttamaan suunnitelmaa Jatkuva integrointi Aikainen ymmärrys Jatkuva riskien seuranta/ fokusointi Perusperiaatteet 3/6 2. Ohjelmistoarkkitehtuurikeskeinen Arkkitehtuuri on välttämätön perusta, jolle järjestelmä rakennetaan Käyttötapaukset kertovat tehtävän, arkkitehtuuri muodon näitä kehitetään rinnakkain Tavoite on rakentaa arkkitehtuuri joka mahdollistaa vaatimusten realisoinnin nyt ja tulevaisuudessa Arkkitehtuuri on yleinen näkemys, jonka jokaisen tiimiläisen tulee jakaa, jotta tuotteesta tulisi vankka, taipuisa, laajennettava ja kannattava

Perusperiaatteet 4/6 2. Ohjelmistoarkkitehtuurikeskeinen Arkkitehtuuri määritellään aikaisessa vaiheessa, mutta se tarkentuu ja laajentuu projektin aikana Tehdään erilaisia näkymiä järjestelmästä, että saadaan parempi kuva rakenteesta Miksi ohjelmistoarkkitehtuuri on tärkeää UP:ssä Auttaa ymmärtämään kokonaiskuva Pystytään jakamaan ohjelmistokehityksen resurssit Mahdollistaa uudelleenkäytön Kehittää ohjelmistojärjestelmää jatkuvasti Ohjaa käyttötapauksia Järkevät inkrementit Perusperiaatteet 5/6 3. Iteraatio (Iteration) Miniprojekti (tietyt toiminnot), joka toteutetaan iteraatiosuunnitelman mukaan ja tuloksena on toimiva julkaisu (release) (ulkoinen tai sisäinen) Iteraation vaiheet ovat analyysi, suunnittelu, toteutus ja testaus eli lähes koko elinkaari perinteisessä ohjelmistokehityksessä. Iteraatioita voi olla monta tuotekehityksen elinkaaren aikana. Täydentyvää kehittämistyötä (ratkaisua syventävää) Ratkaisua koskevaa tietoa lisäävä ja syventävä työstäminen Paranevan tietämyksen ja stabiloituvien piirteiden mukaan ottaminen järjestelmään Palaute, concurrent engineering

Perusperiaatteet 6/6 3. Inkrementti Pieni, suoritettava/toimiva osa järjestelmästä, joka voidaan testata oikeassa laitteistossa. Laajentaa tuotteen tähän astista toiminnallisuutta. Toiminnallisuus Lisäävää kehittämistyötä (ratkaisua laajentava) Ominaisuuksia tuotteeseen lisäävä työstäminen Vaiheittain kehittäminen Ydinjärjestelmä+ inkrementit UP antaa raamit Unified process on suunniteltu joustavaksi ja laajennettavaksi prosessiksi voi valita erilaisia elinkaaria voi valita erilaisia tuotoksia määrittelee aktiviteetit ja niille tekijät mallien käsittely

UP prosessikuvauksen rakenne Iteraatio, inkrementti ja julkaisu Julkaisu N koostuu koko toiminnallisuudesta, joka on kehitetty vastaavassa iteraatiossa N ja kaikissa edellisissä iteraatioissa eli julkaisu 3 = inkrementti 1 + inkrementti 2 + inkrementti 3 Iteraatio N tuottaa vastaavan inkrementin N ja ylläpitää edellisten inkrementtien toiminnallisuudet ("1",, "N-1"). Eli tuottaa julkaisun N Iteraatio voi muuttaa (mahdollisesti myös poistaa) edellisten Hilkka inkrementtien Heikkilä toiminnallisuuksia.

Unified process Release Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iter. Aloitusvaihe (Inception) Tarkentamisvaihe (Elaboration) Konstruointivaihe (Construction) Luovutusvaihe (Transition) Aika Tuotteen ominaisuudet Alustavat mallit Alustava tuotearkkitehtuuri Tarvittaessa prototyyppi Riskit Alustava projektisuunnitelma Onnistumiskriteerit Täydennetyt mallit Toteutettu toimiva perusarkkitehtuuri Arkkitehtuurikuvaus Riskit Seuraavan vaiheen projektisuunnitelma Onnistumiskriteerit Alustava käyttöohje Lähes täydelliset mallit Beta - versio Arkkitehtuurikuvaus Seuraavan vaiheen projektisuunnitelma Onnistumiskriteerit Käyttöohje Installointivalmis ohjelmisto Dokumentit Täydelliset mallit Arkkitehtuurikuvaus Käsikirjat www-palvelut yms. Tehtäväkokonaisuudet Analysis Model Design Model määritellään (specified by) toteutetaan (implemented by) Use Case Model ymmärretään (realized by) sijoitetaan (distributed by) varmennetaan (verified by) Deployment Model Implementation Model Test Model

Iteraatiot ja tehtäväkokonaisuudet Tehtäväkokonaisuud et Vaatimusten määrittely Aloitusvaihe Tarkentamisvaihe Konstruointivaihe Luovutusvaihe Analyysi Suunnittelu Toteutus Testaus Esiiteraatio(t) 1 Iteraatio #2 Iteraatio #3 Iteraatio #n Iter #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Esimerkkiprosessi Aloitusvaihe Tarkennusvaihe Konstruktiovaihe Luovutusvaihe Vaatimusten määrittely Vaatimusten määrittely Vaatimusten määrittely Vaatimusten määrittely Vaatimusten määrittely Vaatimusten määrittely Analyysi Analyysi Analyysi Analyysi Analyysi Analyysi Suunnittelu Suunnittelu Suunnittelu Suunnittelu Suunnittelu Suunnittelu Toteutus Toteutus Toteutus Toteutus Toteutus Testaus Testaus Testaus Testaus Testaus Inkrementti 1 Inkrementti 2 Inkrementti 3 Inkrementti 4 Inkrementti 5 Inkrementti 6 Inkrementti 7

Päävaiheet Aloitusvaihe (inception) Tarkentamisvaihe (elaboration) Konstruktiovaihe (construction) Luovutusvaihe (transition) Aloitusvaihe Päämääränä määritellä tietyn järjestelmän bisnestapaus Ensimmäisen version perusteella sitoudutaan kehitysprojektiin, myöhemmillä perustellaan projektin jatkamista Määritellään mikä on järjestelmän sisältö ja miten se toimii ympäristönsä kanssa Tutki korkean tason toiminnalliset ja eitoiminnalliset vaatimukset Kokoa arkkitehtuuriehdotus Tunnista kriittisimmät riskit, joita projekti voi kohdata ja määrittele miten projekti tiimi niiden kanssa toimii

Aloitusvaihe Määrittele muutamia arvoja, esimerkiksi tuottavuus (ROI), jotka perustelevat projektia taloudelliselta kannalta Ei ole tarkoitus olla kovin aikaa vievää ja kallista tutkimusta Ajatus on saada järjestelmästä tarpeeksi tietoa, jotta tiedetään kannattaako sitä ruveta kehittämään Tarkenna bisnestapausta ja projektisuunnitelmaan aloitusvaiheen tulosten perusteella Isoin ja tärkein tehtäväkokonaisuus tässä vaiheessa on Vaatimusten määrittely Korkeintaan kaksi iteraatiota tässä vaiheessa Aloitusvaiheen tuotokset visio: yleinen näkemys projektin vaatimuksista, tärkeimmät ominaisuudet ja rajoitteet ensimmäinen käyttötapausmalli (10% - 20% valmiusaste) taloudelliset mahdollisuudet riskiarviointi projektisuunnitelma, josta näkyy vaiheet ja iteraatiot mahdolliset prototyypit

Tarkennusvaihe Päämääränä löytää suurin osa toiminnallisista vaatimuksista ja tuottaa vakaa arkkitehtuuripohja Määritä kaikille toiminnallisiin vaatimuksiin liittyvät käyttötapaukset Luo perusarkkitehtuuri Siirrä huomio kriittisistä riskeistä merkittäviin riskeihin (esim. vaikuttavat aikataulun lipsumiseen ja budjetin ylittämiseen) Määrittele järjestelmän laatutaso ei-toiminnallisten vaatimusten suhteen (esim. luotettavuus ja vasteaika) Tarkennusvaihe Painopiste määrittyy sen mukaan missä on merkittävimmät riskit Jos tekniset riskit ovat suuret -> arkkitehtuuri tärkeää Jos vaatimukset ovat epäselviä -> vaatimuksien määrittely ja käyttötapausten määrittely tärkeää Suurin osa analyysi tehtäväkokonaisuudesta tapahtuu tässä vaiheessa Suunnitteluvaihe on analyysivaiheen ohella toinen tärkeä tehtäväkokonaisuus tarkennusvaiheessa

Tarkennusvaiheen tuotokset käyttötapausmalli (ainakin 80% valmiusaste) lisävaatimukset, kuten ei-toiminnalliset, jotka eivät suoraan liity käyttötapauksiin, ovat tunnistettu arkkitehtuurikuvaus proto arkkitehtuurista riskiarviointi tarkentunut projektisuunnitelma, josta näkyy iteraatiot ja niiden arviointikriteerit mahdollisesti käyttöohjeet Konstruktiovaihe Päämääränä on tuottaa toimiva versio järjestelmästä beta-asiakkaille Viimeistele käyttötapausmalli (kaikki toiminnalliset vaatimukset on sovittu ja sovitettu järjestelmässä) Viimeistele kaikki muutkin mallit (analyysi, suunnittelu, käyttöönotto, toteutus ja testaus) Päivitä arkkitehtuurikuvaus vastaamaan tuotettavaa järjestelmää

Konstruktiovaihe Seuraa kriittisiä (vaikuttaa järjestelmän elinkelpoisuuteen) ja merkittäviä (vaikuttaa budjettiin, aikatauluun tai kumpaankin) riskejä Suurin osa työstä konstruktiovaiheessa menee toteutus tehtäväkokonaisuuteen Suurin osa integrointi ja järjestelmätestauksesta tehdään konstruktiovaiheessa Konstruktiovaiheen tuotokset toimiva ohjelmisto käyttöohjeet julkaisukuvaus Luovutusvaihe Päämääränä on tuottaa toimiva versio järjestelmästä kaikille asiakkaille Valmistaudu järjestelmän käyttöönottoon Valmista dokumentointi Käyttöönotto Ohjelmiston muokkaaminen asiakkaiden mukaan Kerää tietoja vioista ja korjaa niitä Tehtäväkokonaisuudet eivät tässä vaiheessa näy Unified process kuvauksessa Järjestelmän pitäisi olla toimivassa kunnossa tässä vaiheessa Yleensä vain yksi iteraatio

Työn tekijät Käyttötapausmäärittelijä Järjestelmäsuunnittelija Käyttöliittymäsuunnittelija Tee arkkitehtuurisuunnittelu Arkkitehti Komponenttiinsinööri Käyttötapausinsinööri Järjestelmäintegroija Toteuta integrointitestaus Toteuta systeemi-testaus Testausinsinööri Integrointitestaaja Systeemitestaaja Työn tekijät ja tehtäväkokonaisuudet Vaatimusten määrittely Rakenna aluemalli Rakenna bisnesmalli Etsi toimijat ja käyttötapaukset Rakenna käyttötapausmalli Tarkenna käyttötapaukset Tee käyttöliittymän prototyyppi Priorisoi käyttötapaukset Päivitä arkkitehtuurikuvaus Analyysi Tee arkkitehtuur i-analyysi Analysoi käyttötapaus Analysoi luokka Analysoi paketti Suunnittelu Suunnittele käyttötapaus Suunnittele luokka ja paketti Toteutus Suorita arkkitehtuuritoteutus Toteuta luokka Suorita yksikkötesti Toteuta alijärjestelmä Integroi järjestelmä Testaus Suunnittele testaus Analysoi onnistuminen Toteuta testaus Unified Process - onnistumiset Riskien pienentäminen Tarkemmat työmäärä- ja aikatauluarviot Ongelmat huomataan aikaisemmin Vaatimusten muuttaminen Projektitiimin yhtenäisyys Palautetta eri vaiheiden, ja siten eri tekijöiden, välillä Projekti voidaan aloittaa pienemmillä resursseilla Mahdollista tuottaa prototyyppi aikaisessa vaiheessa Parempi yhteistyö asiakkaan kanssa Virheistä oppiminen Joustavuus Jatkuva integrointi Kehittyminen on näkyvää

Unified Process - Haasteita Kommunikointi Lisääntynyt projektin hallinta Kokonaisuuden hallinta ja samalla aikaa inkrementaalisten osasten hallinta Epäselvät vaatimukset Julkaisujen lisääntyminen Ylläpito ja vikojen korjaus jokaiselle julkaisulle Integroinnin lisääntyminen Dokumentoinnin lisääntyminen Työtaakka on lisääntynyt, työ on uuvuttavaa 2 inkrementtiä menossa samaan aikaa ei hengähdystaukoa Aikataulutavoitteet lyhyillä väleillä Uudet haasteet testaukselle Työt voidaan helposti siirtää Rational Unified Process

The Rational Unified Process Hyvin yksityiskohtainen eritystapaus Unified prosessista Rationalin myymä tuote, joka sisältää Laajat HTML sivut elektronisesti jaossa, modulaarinen Työkalumentoreita, jotka antavat tukea Rationalin työkalusetin käyttäjille Dokumenttipohjat suurimmalle osalle prosessin tuotoksista Erilaisia oppaita RUP sisältää 9 työvaihetta Bisnes mallintaminen Vaatimukset Analyysi ja suunnittelu Toteutus Testaus Käyttöönotto Projektin hallinta Kokoonpanon ja Muutosten hallinta Ympäristö http://www-3.ibm.com/software/awdtools/rup/ The Rational Unified Process RUP kahdeksan pääperiaatetta Hyökkää suurimpien riskien kimppuun aikaisin ja jatkuvasti tai ne hyökkäävät sinun kimppuun Varmistu, että tuotat lisäarvoa asiakkaillesi Keskity ajettavaan/ toimivaan ohjelmistoon Ota muutokset huomioon aikaisessa vaiheessa Sovi perusarkkitehtuuri aikaisessa vaiheessa Rakenna järjestelmäsi komponenteista Työskennelkää yhtenä tiiminä Tee laadusta elämäntapa

Luentotehtävä Lue Per Krollin artikkeli Transitioning from waterfall to iterative development (http://www- 106.ibm.com/developerworks/rational/libra ry/4243.html ) Miten artikkelissa perusteellaan iteratiivisen tuotekehityksen parempi toimivuus? Mitä asioita on mietittävä siirryttäessä vesiputousmallista iteratiiviseen kehitykseen? Mitä mieltä itse olet näistä prosessimalleista?