Egységesített szoftverfejlesztési folyamat

Egy tipikus projekt profilja, amely az egységes folyamat négy fázisának egymáshoz viszonyított méretét mutatja

Az egységes szoftverfejlesztési folyamat vagy egységes folyamat egy iteratív és inkrementális szoftverfejlesztési folyamat keretrendszer. Az egyesített folyamat legismertebb és legszélesebb körben dokumentált finomítása a racionális egységes folyamat (RUP). További példa az OpenUP és az agilis egységes folyamat .

Áttekintés

Az egységes folyamat nem egyszerűen egy folyamat, hanem egy bővíthető keretrendszer, amelyet egyedi szervezetek vagy projektek számára kell testre szabni. A racionális egységes folyamat ehhez hasonlóan egy testreszabható keretrendszer. Ennek eredményeként gyakran lehetetlen megmondani, hogy a folyamat finomítása az UP-ból vagy a RUP-ból származott-e, ezért a neveket általában felcserélhetően használják.

Az egységes folyamat elnevezést a racionális egységes folyamattal szemben általában az általános folyamat leírására használják, beleértve azokat az elemeket is, amelyek a legtöbb finomításban közösek. Az egységes folyamatnév a védjegybitorlással kapcsolatos lehetséges problémák elkerülésére is szolgál, mivel a Rational Unified Process és a RUP az IBM védjegyei. A folyamatot leíró első könyv az The Unified Software Development Process címet viselte.ISBN 0-201-57169-2 ), és 1999-ben adta ki Ivar Jacobson, Grady Booch és James Rumbaugh . Azóta számos, a Rational Software- hez nem kötődő szerző publikált könyveket és cikkeket az Unified Process néven, míg a Rational Software- hez kapcsolódó szerzők a Rational Unified Process nevet részesítették előnyben.

2012-ben megjelent a fegyelmezett agilis szállítási keretrendszer, egy hibrid keretrendszer, amely stratégiákat fogad el és terjeszt ki az egységes folyamatból, scrum-ból, extrém programozásból és egyéb módszerekből.

Egységes folyamatjellemzők

Iteratív és inkrementális

Diagram, amely azt szemlélteti, hogyan változik a különböző tudományágak relatív hangsúlya a projekt során

Az egységes folyamat egy iteratív és inkrementális fejlesztési folyamat. A kidolgozási, építési és átmeneti szakaszok időkeretes iterációk sorozatára oszlanak. (A kezdeti fázist egy nagy projektnél iterációkra is fel lehet osztani.) Minden iteráció egy inkrementációt eredményez, amely a rendszer olyan kiadása, amely az előző kiadáshoz képest hozzáadott vagy javított funkciókat tartalmaz.

Bár a legtöbb iteráció magában foglalja a legtöbb folyamattudomány ( pl. követelmények, tervezés, megvalósítás, tesztelés) munkáját, a relatív erőfeszítés és a hangsúly a projekt során megváltozik.

Architektúra-központú

Az egységes folyamat ragaszkodik ahhoz, hogy az architektúra álljon a projektcsapat rendszerformálásra irányuló erőfeszítéseinek középpontjában. Mivel egyetlen modell sem elegendő a rendszer minden aspektusának lefedésére, az egységes folyamat több építészeti modellt és nézetet támogat.

A folyamat egyik legfontosabb eredménye a végrehajtható architektúra alapvonala, amely a kidolgozás fázisában jön létre. A rendszer ezen részleges megvalósítása az architektúra érvényesítését szolgálja, és a további fejlesztés alapjaként szolgál.

Kockázat-központú

Az egységes folyamat megköveteli, hogy a projektcsapat a projekt életciklusának korai szakaszában a legkritikusabb kockázatok kezelésére összpontosítson. Az egyes iterációk szállítmányait, különösen a kidolgozási szakaszban, úgy kell kiválasztani, hogy először a legnagyobb kockázatokat kezeljék.

Használati eset vezérelt

A használati esetek az elsődleges modellező eszközök a rendszer funkcióinak meghatározásához. Egyszerű kommunikációs eszközként is szolgál a műszaki és nem műszaki csapattagok számára.

Projekt életciklusa (az egységes folyamat fázisai)

Az egységes folyamat a projektet négy fázisra osztja:

• Kezdő
• Kidolgozási (mérföldkő)
• Építési (kiadás)
• Átmeneti (végső gyártási kiadás)

Mindegyik fázis általában több iterációt tartalmaz (I1, E1, E2, C1 stb. az UP fázis ábráján). Az iterációk pontos száma az egyes fázisokban a projekt méretétől és jellegétől függ. Az UP fázis illusztrációja pontosan 1, 2, 4 és 2 iterációt tartalmaz a négy fázisban, de ez csak egy példa arra, hogyan nézhet ki egy adott projekt.

Kezdő fázis

A kezdő fázis a projekt legkisebb fázisa, és ideális esetben elég rövidnek kell lennie. Ha a kezdeti fázis hosszú, akkor ez túlzott előzetes specifikációra utalhat, ami ellentétes az egységes folyamat szellemével.

Fejlesszünk ki egy hozzávetőleges képet a rendszerről, készítsük el az üzleti tervet, határozzuk meg a projekt terjedelmét, és állítsunk elő egy durva költségbecslést és projekt ütemtervet.

Kidolgozási fázis

A kidolgozási fázisban a projektcsapattól elvárják, hogy a rendszerkövetelmények nagyobb részét rögzítsék. A kidolgozás elsődleges célja azonban az ismert kockázati tényezők megtalálása és kezelése, valamint a rendszer architektúra létrehozása és érvényesítése. Az ebben a fázisban végzett általános folyamatok közé tartozik a használati eset diagramok, fogalmi diagramok (csak alapvető jelöléssel ellátott osztálydiagramok ) és csomagdiagramok (architekturális diagramok) létrehozása.

Az architektúra érvényesítése elsősorban egy végrehajtható architektúra alapvonalának megvalósításán keresztül történik. Ez a rendszer részleges megvalósítása, amely magába foglalja az architektúra legjelentősebb komponenseit. Kis időkeretes iterációk sorozatába épül fel. A kidolgozási fázis végére a rendszerarchitektúrának stabilizálódnia kell, és a végrehajtható architektúra alapvonalának demonstrálnia kell, hogy az architektúra támogatja a kulcsfontosságú rendszerfunkciókat, és megfelelő viselkedést mutat a teljesítmény, a méretezhetőség és a költségek szempontjából.

A kidolgozási fázis végső állomása egy terv (beleértve a költség- és ütemterv becsléseket) az építési fázisra vonatkozóan. Ezen a ponton a tervnek pontosnak és hitelesnek kell lennie, mivel a kidolgozási fázis tapasztalatain kell alapulnia, és mivel a jelentős kockázati tényezőket a kidolgozási fázis során kezelni kellett.

Építési fázis

Az építési fázis a projekt legnagyobb fázisa. Ebben a fázisban a rendszer fennmaradó része a kidolgozási fázisban lerakott alapokra épül. A rendszer funkciói rövid, időkorlátos iterációk sorozatában kerülnek megvalósításra. Minden iteráció egy futtatható szoftver kiadással zárul. Az építési fázis során szokás teljes szövegű használati eseteket írni, és minden egyes ilyen eset egy új iteráció kezdetét jelenti. Ebben a fázisban gyakran használt Egységes Modellezési Nyelv (UML) diagramok közé tartoznak a tevékenység diagramok, szekvencia diagramok, együttműködési diagramok, állapotátmenet diagramok és interakció áttekintő diagramok. Az iteratív megvalósítás során először az alacsonyabb kockázatú és könnyebb elemek kerülnek kivitelezésre. Az építési fázis végső állomása a szoftver, amely készen áll az átmeneti fázisban történő telepítésre.

Átmeneti fázis

A végső projektfázis az átmeneti fázis. Ebben a fázisban a rendszer telepítésre kerül a célfelhasználókhoz. Az első kiadás(ok)ból kapott visszajelzések alapján további finomítások is szükségessé válhatnak, amelyek az átmeneti fázis több iterációja során kerülnek beépítésre. Az átmeneti fázis magába foglalja a rendszer konverziókat és a felhasználók képzését is.

Finomítások és variációk

Az egységes folyamat különböző finomításai eltérnek egymástól abban, hogyan kategorizálják a projekt diszciplínáit vagy munkafolyamatait. A racionális egységes folyamat (RUP) kilenc diszciplínát határoz meg: üzleti modellezés, követelmények, elemzés és tervezés, megvalósítás, tesztelés, telepítés, konfiguráció- és változáskezelés, projektmenedzsment és környezet. Az vállalati egységes folyamat (EUP) nyolc "vállalati" diszciplína hozzáadásával bővíti a RUP-ot. Az agilis finomítások az UP-ból, mint például az OpenUP/Basic és az agilis egységes folyamat (AUP) leegyszerűsítik a RUP-ot a diszciplínák számának csökkentésével.

A finomítások eltérnek a különböző projektmunkákra helyezett hangsúlyban is. Az agilis finomítások áramvonalasítják a RUP-ot a munkafolyamatok egyszerűsítésével és az elvárt munkadarabok számának csökkentésével.

A finomítások abban is különböznek, hogy mi történik az átmeneti fázis után. A racionális egységes folyamatban az átmeneti fázist tipikusan egy új kezdői fázis követi. Az vállalati egységes folyamatban az átmeneti fázist egy termelési fázis követi.

Az egységes folyamat finomításainak és variációinak száma végtelen. Az egységes folyamatot alkalmazó szervezetek elkerülhetetlenül saját módosításokat és kiterjesztéseket vezetnek be. Az alábbiakban néhány ismertebb finomítás és variáció található.

• Agile Unified Process (AUP) egy könnyű változat, amelyet Scott W. Ambler fejlesztett ki
• Basic Unified Process (BUP), az IBM által kifejlesztett könnyű változat és az OpenUP előfutára
• Enterprise Unified Process (EUP), a racionális egységes folyamat kiterjesztése
• Essential Unified Process (EssUP), egy könnyű variáció, amelyet Ivar Jacobson fejlesztett ki
• Open Unified Process (OpenUP), az Eclipse Process Framework szoftverfejlesztési folyamat
• Rational Unified Process (RUP), az IBM / Rational Software fejlesztési folyamat
• Rational Unified Process-System Engineering (RUP-SE), a RUP egy változata, amelyet a Rational Software a System Engineeringnek szabott meg

Hivatkozások

• Kroll, Per; Kruchten, Philippe (2003). The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. ISBN 0-321-16609-4ISBN 0-321-16609-4.
• Kruchten, Philippe (2004). The Rational Unified Process: An Introduction (3rd Ed.). ISBN 0-321-19770-4ISBN 0-321-19770-4.
• Ambler, Scott (2002). Agile Modeling: Effective Practices for EXtreme Programming and the Unified Process [archivált változat]. J. Wiley (2002). ISBN 0-471-20282-7. Hozzáférés ideje: 2024. június 2. [archiválás ideje: 2019. augusztus 8.] 
• Scott, Kendall (2002). The Unified Process Explained. ISBN 0-201-74204-7ISBN 0-201-74204-7.
• Bergstrom, Stefan; Raberg, Lotta (2004). Adopting the Rational Unified Process: Success with the RUP. ISBN 0-321-20294-5ISBN 0-321-20294-5.
• Ambler, Scott; Constantine, Larry (2002). The Unified Process Transition and Production Phases [archivált változat]. CMP Books (2002). ISBN 1-57820-092-X. Hozzáférés ideje: 2024. június 2. [archiválás ideje: 2019. július 14.] 
• Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. ISBN 0-13-111155-8ISBN 0-13-111155-8.

Fordítás

Ez a szócikk részben vagy egészben az Unified Process című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.