Ujednolicony proces
Część serii poświęconej |
tworzeniu oprogramowania |
---|
Unified Software Development Process lub Unified Process to iteracyjne i przyrostowe ramy procesu tworzenia oprogramowania . Najbardziej znanym i obszernie udokumentowanym udoskonaleniem ujednoliconego procesu jest racjonalny ujednolicony proces (RUP). Inne przykłady to OpenUP i Agile Unified Process .
Przegląd
Zunifikowany proces nie jest po prostu procesem, ale raczej rozszerzalną strukturą, którą należy dostosować do konkretnych organizacji lub projektów. Rational Unified Process jest podobnie konfigurowalną strukturą. W rezultacie często nie można stwierdzić, czy udoskonalenie procesu wywodzi się z UP, czy z RUP, dlatego nazwy te są często używane zamiennie.
Nazwa Ujednolicony proces w przeciwieństwie do racjonalnego ujednoliconego procesu jest ogólnie używana do opisania ogólnego procesu, w tym elementów wspólnych dla większości udoskonaleń. Nazwa Unified Process jest również używana w celu uniknięcia potencjalnych problemów związanych z naruszeniem znaku towarowego, ponieważ Rational Unified Process i RUP są znakami towarowymi IBM . Pierwsza książka opisująca ten proces nosiła tytuł The Unified Software Development Process ( ISBN 0-201-57169-2 ) i została opublikowana w 1999 roku przez Ivara Jacobsona , Grady'ego Boocha i Jamesa Rumbaugha . Od tego czasu różni autorzy niezwiązani z Rational Software publikowali książki i artykuły używając nazwy Unified Process , podczas gdy autorzy związani z Rational Software preferowali nazwę Rational Unified Process .
W 2012 roku został wydany framework Disciplined Agile Delivery , hybrydowy framework, który przyjmuje i rozszerza strategie z Unified Process, Scrum, XP i innych metod.
Ujednolicona charakterystyka procesu
Iteracyjne i przyrostowe
Ujednolicony proces to iteracyjny i przyrostowy proces rozwoju. Fazy opracowania, budowy i przejścia są podzielone na serie ograniczonych czasowo iteracji. (Fazę wstępną można również podzielić na iteracje w przypadku dużego projektu). Każda iteracja skutkuje przyrostem , czyli wydaniem systemu zawierającym dodatkowe lub ulepszone funkcje w porównaniu z poprzednim wydaniem.
Chociaż większość iteracji będzie obejmowała pracę w większości dyscyplin procesu ( np. Wymagania, Projektowanie, Implementacja, Testowanie), względny wysiłek i nacisk będą się zmieniać w trakcie projektu.
Zorientowany na architekturę
Zunifikowany proces podkreśla, że architektura leży u podstaw wysiłków zespołu projektowego zmierzających do ukształtowania systemu. Ponieważ żaden pojedynczy model nie jest wystarczający do pokrycia wszystkich aspektów systemu, ujednolicony proces obsługuje wiele modeli architektonicznych i widoków.
Jednym z najważniejszych rezultatów procesu jest bazowa architektura wykonywalna, która jest tworzona podczas fazy opracowywania. Ta częściowa implementacja systemu służy do walidacji architektury i działa jako podstawa do dalszego rozwoju.
Zorientowany na ryzyko
Ujednolicony proces wymaga od zespołu projektowego skupienia się na rozwiązaniu najbardziej krytycznych zagrożeń na wczesnym etapie cyklu życia projektu. Produkty każdej iteracji, zwłaszcza w fazie opracowywania, muszą zostać wybrane, aby zapewnić, że największe zagrożenia zostaną uwzględnione w pierwszej kolejności.
Cykl życia projektu (Fazy ujednoliconego procesu)
Zunifikowany proces dzieli projekt na cztery fazy:
- Początek
- Opracowanie (kamień milowy)
- Budowa (wydanie)
- Przejście (ostateczna wersja produkcyjna)
Każda faza będzie generalnie zawierać wiele iteracji (nazwanych I1, E1, E2, C1 itd. na ilustracji fazy UP). Dokładna liczba iteracji w każdej fazie zależy od skali i charakteru projektu. Należy zauważyć, że ilustracja fazy UP zawiera dokładnie 1, 2, 4 i 2 iteracje w czterech fazach, ale jest to jedynie przykład tego, jak może wyglądać konkretny projekt.
Faza początkowa
Incepcja to najmniejsza faza projektu, a najlepiej powinna być dość krótka. Jeśli Faza Początkowa jest długa, może to wskazywać na nadmierną specyfikację z góry, co jest sprzeczne z duchem Zunifikowanego Procesu.
Opracuj przybliżoną wizję systemu, opracuj uzasadnienie biznesowe, zdefiniuj zakres i opracuj przybliżony kosztorys i harmonogram projektu.
Faza opracowania
Oczekuje się, że w fazie opracowywania zespół projektowy przejmie znaczną większość wymagań systemowych. Jednak głównym celem opracowania jest zajęcie się znanymi czynnikami ryzyka oraz ustanowienie i zweryfikowanie architektury systemu. Typowe procesy podejmowane w tej fazie obejmują tworzenie diagramów przypadków użycia , diagramów koncepcyjnych ( diagramy klas z tylko podstawową notacją) i diagramów pakietów (diagramy architektoniczne).
Architektura jest weryfikowana przede wszystkim poprzez implementację linii bazowej architektury wykonywalnej. Jest to częściowa implementacja systemu, która zawiera podstawowe komponenty o największym znaczeniu architektonicznym. Jest zbudowany w serii małych, ograniczonych czasowo iteracji. Do końca fazy opracowywania architektura systemu musi się ustabilizować, a bazowa architektura wykonywalna musi wykazać, że architektura będzie obsługiwać kluczowe funkcje systemu i wykazywać właściwe zachowanie pod względem wydajności, skalowalności i kosztów.
Końcowym produktem końcowym fazy opracowania jest plan (wraz z szacunkowymi kosztami i harmonogramem) dla fazy budowy. Na tym etapie plan powinien być dokładny i wiarygodny, ponieważ powinien opierać się na doświadczeniach z etapu opracowywania, a istotne czynniki ryzyka powinny zostać uwzględnione na etapie opracowywania.
Faza budowy
Budowa to największa faza projektu. W tej fazie pozostała część systemu jest budowana na fundamencie położonym w Opracowaniu. Funkcje systemu są wdrażane w serii krótkich, ograniczonych czasowo iteracji. Każda iteracja skutkuje wykonywalną wersją oprogramowania. Zwyczajem jest pisanie pełnotekstowych przypadków użycia podczas fazy konstruowania, a każdy z nich staje się początkiem nowej iteracji. Typowe języka UML (Unified Modeling Language ) używane w tej fazie obejmują diagramy czynności , diagramy sekwencji , diagramy współpracy , diagramy przejść między stanami oraz diagramy przeglądowe interakcji . Wykonano iteracyjną implementację elementów o niższym ryzyku i łatwiejszych. Końcowym produktem fazy konstrukcyjnej jest oprogramowanie gotowe do wdrożenia w fazie przejściowej.
Faza przejściowa
Ostatnią fazą projektu jest przejście. W tej fazie system jest wdrażany u docelowych użytkowników. Informacje zwrotne otrzymane z pierwszej wersji (lub pierwszych wersji) mogą skutkować dalszymi udoskonaleniami, które zostaną wprowadzone w trakcie kilku iteracji fazy przejściowej. Faza przejściowa obejmuje również konwersje systemu i szkolenie użytkowników.
Udoskonalenia i wariacje
Udoskonalenia ujednoliconego procesu różnią się między sobą sposobem kategoryzowania dyscyplin projektu lub przepływów pracy . Rational Unified Process definiuje dziewięć dziedzin: modelowanie biznesowe , wymagania , analiza i projektowanie , implementacja , testowanie , wdrażanie , zarządzanie konfiguracją i zmianami , zarządzanie projektami oraz środowisko . Zunifikowany proces korporacyjny rozszerza RUP poprzez dodanie ośmiu dyscyplin „korporacyjnych”. Zwinne udoskonalenia UP, takie jak OpenUP/Basic i Agile Unified Process, upraszczają RUP, zmniejszając liczbę dyscyplin.
Udoskonalenia różnią się także naciskiem położonym na różne artefakty projektu . Zwinne udoskonalenia usprawniają RUP, upraszczając przepływy pracy i zmniejszając liczbę oczekiwanych artefaktów.
Udoskonalenia różnią się również specyfikacją tego, co dzieje się po fazie przejściowej. W Rational Unified Process po fazie Przejściowej zazwyczaj następuje nowa faza Początkowa. W ujednoliconym procesie przedsiębiorstwa po fazie przejściowej następuje faza produkcyjna.
Liczba udoskonaleń i odmian ujednoliconego procesu jest niezliczona. Organizacje korzystające z ujednoliconego procesu niezmiennie wprowadzają własne modyfikacje i rozszerzenia. Poniżej znajduje się lista niektórych z bardziej znanych udoskonaleń i odmian.
- Agile Unified Process (AUP), lekka odmiana opracowana przez Scotta W. Amblera
- Basic Unified Process (BUP), lekka odmiana opracowana przez IBM i prekursor OpenUP
- Enterprise Unified Process (EUP), rozszerzenie Rational Unified Process
- Essential Unified Process (EssUP), lekka odmiana opracowana przez Ivara Jacobsona
- Open Unified Process (OpenUP), proces tworzenia oprogramowania Eclipse Process Framework
- Rational Unified Process (RUP), proces tworzenia oprogramowania IBM / Rational
- Oracle Unified Method (OUM), proces rozwoju i wdrażania Oracle
- Rational Unified Process-System Engineering (RUP-SE), wersja RUP dostosowana przez Rational Software for System Engineering
- Kroll, Per; Kruchten, Philippe (2003). Prosty racjonalny ujednolicony proces: praktyczny przewodnik po RUP . ISBN 0-321-16609-4 .
- Kruchten, Philippe (2004). Racjonalny ujednolicony proces: wprowadzenie (wyd. 3). ISBN 0-321-19770-4 .
- Amblera, Scotta (2002). Modelowanie zwinne: skuteczne praktyki programowania ekstremalnego i ujednoliconego procesu . J.Wiley. ISBN 0-471-20282-7 .
- Scott, Kendall (2002). Wyjaśnienie ujednoliconego procesu . ISBN 0-201-74204-7 .
- Bergstrom, Stefan; Raberg, Lotta (2004). Przyjęcie Rational Unified Process: Sukces z RUP . ISBN 0-321-20294-5 .
- Ambler, Scott ; Konstantyn, Larry (2002). Ujednolicone fazy przejścia i produkcji procesu . Książki CMP. ISBN 1-57820-092-X .
- Larman, Craig (2004). Programowanie zwinne i iteracyjne: przewodnik menedżera . ISBN 0-13-111155-8 .