Yhtenäinen prosessi (PU) tai " yhtenäinen prosessi (UP) " Englanti, tai " Unified Software Development Process (USDP) " on perhe olio- ohjelmistojen kehittämiseen menetelmiä . Sille on ominaista iteratiivinen ja inkrementaalinen lähestymistapa, jota ohjaavat käyttötapaukset ja joka keskittyy UML- arkkitehtuuriin ja malleihin . Se määrittelee prosessin, joka integroi kaikki suunnittelu- ja tuotantotoiminnot kehitysvaiheisiin, jotka koostuvat luomisvaiheesta, kehitysvaiheesta, rakennusvaiheesta ja siirtymävaiheesta, mukaan lukien kukin useita iteraatioita.
Vuonna 1987 Ivar Jacobson loi Objectory AB: n markkinoimaan Objectory Process -nimistä objektisuuntautunutta kehitysmenetelmää. Tämä menetelmä on tulos komponenttikeskeisestä lähestymistavasta, jonka hän oli kehittänyt vuodesta 1967 Ericson- yhtiössä . Objektiivi perustuu käyttötapauksiin , jonka käsite on kirjoittanut Jacobson. Menetelmä noudattaa sitten systemaattista lähestymistapaa, jonka tavoitteena on peräkkäin OOSE- malleja päästä ohjelmiston toteutukseen.
Vuonna 1992 Rational Software -yrityksen työntekijä Grady Booch julkaisi Booch-menetelmän olio-suuntautuneesta kehityksestä. Tämä koostuu graafisesta mallinnuskielestä , iteratiivisesta kehitysprosessista ja joukosta parhaita käytäntöjä .
Vuonna 1995 Rational Software osti Objectory AB: n ja yhdisti nämä kaksi kehitystapaa nimellä Rational Objectory Process. Yhtiö palkkasi myös James Rumbaughin , OMT- mallinnuskielen luojan .
Vuonna 1997 "yhtenäisestä mallintamiskielestä", UML: stä , tuli standardi objektiivisessa analyysissä ja suunnittelussa sen jälkeen kun kolme päämerkintää, OOSE, Booch ja OMT, yhdistettiin. sitten suurempi konsortio. Uusi merkintä integroidaan sitten Rational Objectory Process -versioon (versio 4.1).
Vuonna 1998 useiden muiden ohjelmistosuunnittelutyökaluihin erikoistuneiden yritysten hankinnan jälkeen Rational Software paransi menetelmäänsä ja nimeksi sen uudeksi nimeksi Rational Unified Process (RUP) (versio 5.0). Se on oma menetelmä, jota suojaa rekisteröity tavaramerkki.
Vuonna 1999 Jacobson, Booch ja Rumbaugh julkaisivat ”Ohjelmistokehityksen yhtenäistetyn prosessin” tarkoituksena levittää RUP: n taustalla olevia ideoita yleisölle. He huomauttavat, että tämä on sekä kehityskäytäntöjen yhtenäistäminen että käytettyjen mallien yhtenäistäminen ja että prosessi sisältää suuren määrän Rational Software -menetelmien asiantuntijoiden ja satojen muiden yritysten osallistumista.
Yhtenäinen prosessi on menetelmä ohjelmistokehitykselle, jolle on tunnusomaista:
Yhtenäinen prosessi täyttää liiketoimintaprosessin määritelmän . Sillä pyritään siis varmistamaan kehityskierto, joka sisältää systemaattisia ja toistettavia toimintoja, jotka perustuvat hyvin määriteltyihin esineisiin, samalla kun helpotetaan uusien ihmisten integrointia tiimeihin. Menetelmässä otetaan lisäksi huomioon, että tuote koostuu paitsi koodista myös kaikista elementeistä, jotka vaikuttavat ohjelmiston kestävyyteen ja myöhempään kehitykseen.
Yhtenäinen prosessi on syklinen: sen tavoitteena on hankkeiden peräkkäin tuottaa ensin elinkelpoinen versio tuotteesta ja sitten peräkkäiset julkaistavat versiot (englanninkielinen julkaisu).
Jokaisella projektilla on elinkaari neljässä vaiheessa, kukin jaettuna useaan toistoon:
Yhtenäinen prosessi tukee riskipainotteista lähestymistapaa, joka pyrkii erilaisten iteraatioiden avulla ratkaisemaan suurimmat epävarmuustekijät ensisijaisesti.
Yhtenäinen prosessi tarjoaa seuraavat työjaksot, jotka voidaan konfiguroida projektin tarpeiden mukaan:
Termiä "kurinalaisuus" käytetään myös kuvaamaan yleisiä sekvenssejä.
Toisin kuin vesiputousmalli, joka määrittelee erilliset vaiheet kullekin näistä toimintojaksoista, yhtenäinen prosessi integroi nämä toiminnot projektin eri iteraatioiden ja vaiheiden kautta. Yhtenäinen prosessi on edelleen suunniteltu käsittelemään monimutkaisia komponenttipohjaisia järjestelmiä. Siksi löydämme ideoita V-syklistä , kuten komponentteihin perustuva arkkitehtoninen visio, järjestelmän integrointi ja eri validointitasot, mutta ilman rajoitusta järjestää ne peräkkäisissä vaiheissa.
Yhtenäinen prosessi määrittelee myös roolit näihin toimintoihin osallistuville toimijoille (esim. Arkkitehti, komponenttiinsinööri, käyttöliittymäsuunnittelija jne.). Kirjoittajat korostavat kuitenkin, että nämä ovat rooleja eivätkä ihmiset; sama tiimin jäsen voi siis yhdistää useita rooleja. Yhtenäinen prosessi määrittelee lopulta sarjan esineitä, eli projektin suoritteita .
Yhtenäinen prosessi vaatii iteratiivista suunnittelua, jossa "suunnitelma edeltää toimintaa".
Periaatteena on, että kokonaissuunnitelma määrittää projektin monimutkaisuuden mukaan kullekin vaiheelle tarvittavat iteraatiot ja sijoittaa vaiheet ajoissa. Tämä yleissuunnitelma ei sisällä yksityiskohtia iteraatiota kohti. Toistot suunnitellaan vähitellen projektin edetessä. Nykyinen iterointi suunnitellaan yksityiskohtaisesti, kun se alkaa, aikataululla ja sisältötavoitteella (käsiteltävä käyttötapaus, aikaisempien iteraatioiden suoritteisiin tehtävät muutokset, suoritettavat komponentit jne.). Seuraavan iteraation suunnitelma laaditaan, kun elementit ovat tiedossa. Siksi se arvioidaan ensinnäkin pääpiirteittäin, ja sitten se puhdistetaan nykyisen iteraation aikana löydettyjen tietojen mukaan.
Luontivaiheen erityistapauksessa projektin luonnos on yleensä liian epävarma mahdollistamaan realistisen suunnittelun. Tämän vaiheen ensimmäisen iteroinnin suunnitelma olisi sen vuoksi katsottava yritykseksi suunnitelmaksi, jota tulisi tarvittaessa muuttaa. Tämän vaiheen lopussa vahvistetaan kehityksen toteutettavuus ja voidaan laatia projektin visiota vastaava yleissuunnitelma.
Käyttötapauksen säätö käyttää use case kaaviot ( DCU ) täydennettynä tekstipohjaisen esityksen. Vuodesta DCUs The analyysi, suunnittelu, käyttöönoton, toteutuksen ja testauksen mallit ovat peräisin . Näistä malleista syntyy järjestelmän arkkitehtuuri. Systemaattista lähestymistapaa ehdotetaan myös käyttötapausten johtamiseksi analyysi- ja suunnitteluluokista yksiköiden rajavalvontajärjestelmän mukaisesti . Nämä ovat myös käyttötapauksia, jotka mahdollistavat testiskenaarioiden kehittämisen, koska uuden ohjelmiston on mahdollistettava suunniteltujen käyttötapausten saavuttaminen. DCU: t ovat siis malleja, jotka takaavat kehitysprosessin johdonmukaisuuden toimimalla yhteisenä ketjuna kaikille toiminnoille.
Mallintamistoiminnot perustuvat UML: ään . Tämä mallinnuskieli kattaa ohjelmistoarkkitehtuurin ja suunnittelun rakenteelliset ja dynaamiset näkökohdat. Se helpottaa komponenttien mallintamista käyttämällä olio- lähestymistapaa . UML: n luojat ovat myös lähtökohtana yhtenäiselle prosessille, jonka oli tarkoitus täydentää UML: ää täydellisellä ja yleisellä kehitysprosessilla .
Järjestelmän arkkitehtuuri on suunniteltu alusta alkaen hyvin käytännöllisesti : se mukautetaan työympäristöön, käyttäjän tarpeisiin, olemassa olevien kirjastojen tai "tiilien" uudelleenkäytön ( uudelleenkäytön ) mahdollisuuksiin. Arkkitehtuurin kehitys on ensinnäkin raakaa ja riippumatonta käyttötapauksista (varmistamme kuitenkin, että se ei estä niiden toteutumista), sitten tunnistetaan osa keskeisistä toiminnoista ja arkkitehtuuri toistetaan ja yksityiskohtaisesti tämän joukon mukaisesti. Erittelystä tapaustarkkuudeksi arkkitehtuuri kehittyy, sisältäen lopulta uusia tapauksia jne., Kunnes arkkitehtuuri on saavuttanut riittävän korkean ja vakaan kehitystason, jotta voidaan kehittää prototyyppi, joka esitellään asiakkaan siten, että se suorittaa iteroinnin.
Iteraatio on peräkkäinen toimintosekvenssi. Lisäys on askel eteenpäin kehitysvaiheissa. Jokaisella iteraatiolla löydämme tarpeiden määrittely-, suunnittelu- ja suoritettavien prototyyppien muodostamiseen liittyvät toiminnot. Uusi iterointi, esimerkiksi prototyypin osoittamisen jälkeen käyttäjille, jatkaa määrittelyä selventämällä tai korjaamalla sitä, jatkamalla sitten kehittämistä jne.
Projekti määrittelee lisäykset, ja jokainen lisäys lisää uusia toimintoja. Lisäykset voivat seurata esimerkiksi erilaisia käyttötapoja. Vaikeus on siinä, että alahankkeet tai osuudet lopulta yhdistetään ja kunnioitetaan niiden keskinäistä riippuvuutta ja suunnitellun tuotteen yleistä johdonmukaisuutta. Siksi ehdotetaan myös komponenttien muodossa tapahtuvaa kehitystä. Se hyödyntää parhaiten objektiteknologioiden panosta.
PU yhdistää nämä kaksi tavoitetta minimoidakseen väärinkäsitysten riskit tarpeisiin nähden sekä äärettömän, määrittelemättömän, väärin määritellyn tai keskeneräisen kehityksen riskin: Täällä käyttäjä voi korjata itsensä prototyyppien suhteen käänteen kehitys . Alusta alkaen saavutetaan konkreettisia tuloksia, vaikka ne olisivatkin vain prototyyppisiä. Jotkut PU-toteutukset pitävät prototyyppejä lopullisen järjestelmän täysversioina. Tällöin alaisista toiminnoista voidaan hyvin luopua matkan varrella esimerkiksi kustannuksia tai määräaikoja koskevien kysymysten osalta . Lopuksi, jos käyttäjä tarvitsee muutosta kehityksen aikana, tämä kehitys voidaan jossain määrin integroida. Tämä ei päde peräkkäiseen kehitykseen.
PU järjestää elinkaaren ryhmitellen iteraatiot (eritelmät, analyysi, suunnittelu, toteutus ja testaus) vaiheisiin. Nämä vaiheet ovat joko alkuvaiheita (luominen) tai välivaiheita (kehittäminen, rakentaminen) tai lopullisia (siirtyminen käyttäjälle tai käyttöönotto). Nämä vaiheet leikkaavat tuotteen tuotannon ajallisena peräkkäin (jaksot), mutta sisältävät kaikki projektin strukturointitehtävät (peräkkäiset puhdistukset, iteraatiot) ja ehdottavat matriisiorganisaatiota tarjotun toiminnan kokonaismäärästä: on selvää, että luomisvaiheessa enemmän aikaa käytetään tarpeiden analysointiin kuin testaamiseen; päinvastoin, siirtymävaiheessa testit ovat edelleen kesken, kun taas tarvearviointi ja sen tarkentaminen on teoreettisesti saatu päätökseen rakennusvaiheesta lähtien.
Yhtenäinen prosessi on konfiguroitavissa ja voidaan sen vuoksi mukauttaa niiden projektien ja organisaatioiden erityispiirteisiin, joissa sitä käytetään. Yleisen menetelmän erikoistumisia on siis paljon. Myös useita perustavanlaatuisempia muunnelmia on tullut esiin, ja niiden levinneisyys on laajempaa.
Yleisnimet ja lyhenteet ovat:
Lyhenne | Nimellisarvo | Ensimmäinen versio | Tekijä (t) | Erityispiirteet |
---|---|---|---|---|
VOITA | Yhtenäinen prosessi | 1999 | Ivar Jacobson , Grady Booch ja James Rumbaugh | menetelmän yleiset ohjeet |
YLÖS | Yhtenäinen prosessi | 1999 | (katso PU) | Englanninkielinen nimi PU |
USDP | Yhtenäinen ohjelmistokehitysprosessi | 1999 | (katso PU) | toinen englanninkielinen nimi PU: lle menetelmän julkaisevan kirjan otsikon jälkeen |
TAI | Rationaalinen yhtenäinen prosessi | 1998 | Rational Software (IBM), RUP-tiimi Philippe Kruchtenin johdolla | Rational Software (IBM): n oma menetelmä, johon PU perustui |
EUP | Yritysten yhtenäinen prosessi | 2000 | Scott Ambler ja Larry Constantine | integroi toteutuksen jälkeiset vaiheet ja toiminnot kattamaan tuotannossa olevan ohjelmiston elinkaaren, kunnes se poistetaan tuotannosta; nimi on tavaramerkki. |
XUP | eXtreme Unified Process | hybridi, joka integroi UP: n äärimmäisiin ohjelmointiin . | ||
P: lle | Ketterä yhtenäinen prosessi | 2005 | Scott ambler | hybridi, joka yhdistää UP: n osajoukon ketterien menetelmien ohjeisiin - jaettu menetelmää dokumentoivana verkkosivustona, mutta ei ylläpidetty vuodesta 2006 lähtien |
2TUP | kahden kappaleen yhtenäinen prosessi | Valtech | todennäköisesti ottaa huomioon yritysten IS: n jatkuviin ja nopeisiin muutoksiin liittyvät mielijohteet ja rajoitteet | |
EssUP | Oleellinen yhtenäinen prosessi | 2006 | Ivar Jacobson | UP: n kevyt vaihtoehto integroimalla ketterät määräykset ja levittänyt hänen yrityksensä Ivar Jacobson Consulting. EssUP koostuu joukosta ns. "Välttämättömiä" käytäntöjä, jotka voidaan vapaasti valita ja yhdistää tarjoten siten joustavaa käyttöä. |
Rational Unified Process (RUP) on yhtenäisen prosessin alku ja sellaisenaan tunnetuin toteutus. Se on Rational Softwaren tuote ja tavaramerkki, jonka IBM on tällä välin hankkinut. Menetelmä toimitetaan avaimet käteen -toiminnon mukana, ja siihen liittyy työkaluja, jotka ohjaavat tiimejä prosessin mukauttamisessa ja toteuttamisessa.
RUP: n ehdottama ohjelmistokehityskehys reagoi yhtenäisen prosessin ominaisuuksiin: se on käyttäjien tarpeiden ohjaama kehitysmenetelmä, joka keskittyy ohjelmistoarkkitehtuuriin, iteratiiviseen ja inkrementaaliseen, UML: n toteuttamiseen mallinnukseen.
RUP laajentaa toimintaketjut kattamaan myös
Ketterä yhtenäinen prosessi (AUP) on yksinkertaistettu muunnos UP: stä, joka sisältää ketterät käytännöt, kuten testipohjaisen kehityksen (TDD). Siten se vie yhtenäisen prosessin peräkkäiset vaiheet ja vaiheen lopun virstanpylväät, mutta vahvistaa ketterää lähestymistapaa suosittelemalla suunnitelman päivittämistä kunkin vaiheen lopussa, mahdollisesti julkaistavan version toteuttamista lopussa kunkin vaiheen loppu, jokaisen iteraation loppu ja ketterän manifestin periaatteiden soveltaminen . Siksi mallien käyttö dokumentaatioesineenä rajoittuu vaatimusten malliin ja suunnittelumalliin. AUP rikastaa vaatimusten mallintamista liiketoimintamalleilla. Menetelmä suosittelee lisäksi mallinnuksen keskittämistä ääriviivoihin ja sellaisten yksityiskohtien välttämistä, jotka voitaisiin helposti johtaa koodista. AUP on saatavilla ilmaiseksi verkossa pakattuna arkistona, mutta sitä ei ole ylläpidetty vuodesta 2006 lähtien.
Essential Unified Process (EssUP) pyrkii keventämään yhtenäistettyä prosessia, joka vaikka iteratiivinen ja inkrementaalinen koetaan usein liian raskaana ja liian muodollisena. EssUP noudattaa tätä varten huolenaiheiden erottamisen periaatetta . Monoliittisen prosessin sijasta EssUP määrittelee joukon itsenäisiä käytäntöjä, jotka voidaan vapaasti yhdistää kontekstiin sopivaksi prosessiksi.
EssUP: n tunnistamat käytännöt on ryhmitelty kahdeksaan aiheperheeseen: tiimi, tuote, elinkaari, iteraatiot, 2.0 käyttötapaukset , arkkitehtuuri, komponentit ja testin suoritus. EssUP on saatavilla verkossa.
Yhtenäinen prosessi käyttää peräkkäisiä vaiheita, kuten vesiputoushankkeita . Vaiheita ei kuitenkaan ole rakennettu keinotekoisesti teknisten tieteenalojen mukaan, vaan ne vastaavat vaiheittaisen riskien vähentämisen logiikkaa, jolloin jokainen vaihe integroi kaikki tieteenalat vaihtelevasti. Lisäksi yhtenäinen prosessi tukee iteroivaa ja sopeutuvaa suunnittelua eikä jäykää ja yksityiskohtaista suunnittelua alkupäässä.
Yhdistetyllä prosessilla on yhtäläisyyksiä V-syklin kanssa siinä, että se keskittyy komponenteista tehtyjen järjestelmien arkkitehtuuriin ja erottaa yksikötestauksen, integraatiotestauksen ja järjestelmätestauksen. PU-vaiheita ei kuitenkaan ole rakennettu arkkitehtuuritason ja tieteenalojen mukaan, vaan ne vastaavat iteratiivisen kypsymisen logiikkaa. Lisäksi PU integroi todentamis- ja validointitoimet kussakin vaiheessa.
Yhtenäinen prosessi on lähellä ketteriä menetelmiä siltä osin kuin siinä suositaan iteratiivista ja inkrementaalista lähestymistapaa, joka keskittyy käyttäjien tarpeisiin. Se eroaa kuitenkin ketteristä menetelmistä suurimman osan vaatimusten ennakoivasta keräämisestä projektin ensimmäisten iteraatioiden aikana ja alkupään arkkitehtuurin määrittelystä ennen julkaistavien versioiden tuottamista (" julkaisu " englanniksi). Siinä keskitytään myös malleihin, kun taas ketterät menetelmät suosivat koodin tuotantoa dokumentaation sijaan. Tämä viimeinen ero on kuitenkin asetettava perspektiiviin, koska jotkut agilistit kannattavat myös mallintamiseen perustuvaa lähestymistapaa. Nämä ketterät menetelmät jakavat UP: n kanssa näkemyksen inkrementaalimallinnuksesta, jossa eri malleja (vaatimukset, analyysi, suunnittelu) puhdistetaan rinnakkain jokaisen iteraation aikana eikä peräkkäin, vaihe vaiheelta.
Yhtenäinen prosessi käyttää paljon UML- malleja . Se artikloi erityyppiset kaaviot eri mallinnustarkoituksiin (analyysi, suunnittelu, testi). Se rikastaa siten UML: ää, joka on yleinen mallintamiskieli, systemaattisella lähestymistavalla, mutta erityinen tietylle kehitysmenetelmälle.
Yhtenäinen prosessi yhdistää useiden lähestymistapojen edut ja erityisesti strukturoidun lähestymistavan vaiheittain suurella joustavuudella iteraatioissa.
Tärkein kritiikki on, että aktiviteettisekvenssien ja esineiden yksityiskohtainen kuvaus antaa PU: lle tietyn raskauden ja vaatii siksi projektiryhmän jäsenten korkeaa pätevyyttä (erityisesti: iteratiivisten lähestymistapojen hallintaa, syvällistä UML-tuntemusta, tietoa toimintojen sekvensseistä ja niiden keskinäisistä riippuvuuksista).
Yhtenäinen prosessi jättää myös paljon harkintavaltaa toiminnan mukauttamiseksi yrityksen erityispiirteisiin. Tämä joustavuus yhdistettynä prosessin monimutkaisuuteen ja suureen tulkintavapauteen voi saada aikaan PU: n erittäin jäykän toteutuksen, vaikka sillä on periaatteessa ketterän menetelmän ominaisuudet.
Usein PU: n hyväksyminen organisaatiossa johtuu halusta kurinpitää kehityskäytäntöjä erityisillä työkaluilla ja vakiintuneiden ja homogeenisten käytännesääntöjen seurannalla . Ohjelmistokehitysprosessista tehdään tällöin prosessin uudelleensuunnittelu (BPR) IT-osastojen toiminnan optimoimiseksi. Ketterä kehitys puolestaan tukee yksinkertaisimpien työkalujen valitsemista ja kielen tai menetelmän vaiheiden sujuvaa tai "työkalupakki-tyyppistä" käyttöä. Siksi on paradoksaalista tahtoa jäykistää kodifioimalla käytännöt, jotka on luonnostaan tarkoitettu joustavuuteen.
Scott Amblerin mukaan jotkut PU: n perusteet eivät voi olla rinnakkain ketteryyden määräysten kanssa: käyttötapaustaajuuksien ensisijaisuus ja ohjaava rooli on hylättävä . Todellakin, jos ne mahdollistavat oikein dokumentoida ohjelmiston käyttäytymistä, niitä ei voida käyttää hallita kaikkia hanketoiminta: rajoitteet, käyttöliittymät ja niiden kinematiikka The liiketoiminnan sääntöjä , että ohjelmisto on noudatettava voi käyttötapaukset. PU lisää myös joukon "lisäominaisuuksia" korvaamaan tämän puutteen. Siten, edelleen Amblerin mukaan, jos tarveanalyysi voi johtaa projektin, käyttötapaukset eivät voi olla ja vain muodostaa markkinointiretoriikkaa, joka on ominaista esimerkiksi instantioille, kuten RUP tai EUP .
Yhdistetyn prosessin monia kevyempiä muunnelmia on tullut lievittämään sen kuvauksen alkuperäistä raskautta. Useita ketteriä muunnelmia on myös syntynyt, ja niiden tarkoituksena on vahvistaa iteratiivisuutta, keventää dokumentaatiota tai helpottaa tiettyjen ketterien käytäntöjen integrointia prosessiin.
Viimeisimmän kehityksen ja erityisesti EssUP: n tarkoituksena on muuttaa yhtenäinen prosessi "työkalupakiksi". Periaatteena on tunnistaa ja määritellä prosessin komponentit, esimerkiksi sen jakaminen vaiheisiin, iteratiiviset pilotointitekniikat ja tietyt mallintamistekniikat, jotta ne olisivat itsenäisiä ja uudelleenkäytettäviä ja antavat projektiryhmien valita ja yhdistää prosessin kannalta merkitykselliset komponentit. yhteydessä.