RUP rób aż nie zrobisz (Początek)

1. Wstęp

Dziś oto nastał dzień w którym rozpoczynam serię wpisów (dłuuugą) o metodyce RUP (Rational Unified Process). Na początku wprowadzę trochę ogólników i wyjaśnię czym jest bohater tego postu a pod koniec tekstu powiem co w kolejnych częściach się znajdzie.

2. Czym jest RUP ?

Zacznijmy od tego, że RUP sięga aż do modelu spiralnego Barry’ego Boehma który to stawiał twardo na potężną analizę każdego kroku i podjętego działania oraz częste testy wszystkiego. W naszej metodyce jest to moim zdaniem bardzo odczuwalne – widać gołym okiem nacisk na maksymalne zminimalizowanie ryzyka.

Wracając jednak do podstaw, RUP to proces iteracyjnego wytwarzania oprogramowania stworzony przez IBM (a dokładniej Rational Software Corporation, które to zostało przez IBM wchłonięte).
Ogólnie rzecz biorąc RUP powstał na podstawie analizy najczęściej popełnianych błędów przez twórców oprogramowania. Załapuje się tutaj na przykład: zła komunikacja w zespole/zespołach, błędy w analizie początkowej, słabe testy oprogramowania, brak zarządzania ryzykiem czy brak automatyzacji projektu.

(I tak mam wrażenie, że ponad połowa RUP to ciągłe analizy i testy : P)

3. Najważniejsze cechy

a) Iteracyjność – czyli takie sprinty ze SCRUM. Każda kolejna wersja programu jest gotowa w równych odstępach czasu dzięki czemu klient na bieżąco może obserwować postęp prac oraz sprawdzać czy rzeczywiście robimy to co powinniśmy (żeby nie wyszło na to, że zlecił nam aplikację w C# a my użyliśmy JavaScriptu : P).

b) Zarządzanie wymaganiami – czyli wiemy co wymaga od nas klient oraz, zależnie od złożoności programu, jakie zmiany mogą nastąpić (należy je najlepiej wykryć wcześniej, aby później nie było problemów z implementacją kodu/featursa).

c) Architektura bazuje na komponentach – o ile dobrze się orientuję, chodzi o podział kodu programu na komponenty (obiektowość kodu) co pozwala na dobrą jego organizację nawet przy bardziej złożonych projektach.

d) Wizualne modelowanie oprogramowania – w skrócie jest to przedstawienie w sposób graficzny kodu/programu.

e) Testy jakości – RUP zakłada, że wszystkie osoby pracujące nad kodem muszą być zaangażowane w testy oprogramowania.

f) Zarządzanie zmianami w oprogramowaniu – zmiany są płynne i dobrze monitorowane.

4. Po co o tym w ogóle piszę : D ?

Tak, to bardzo dobre pytanie ! Otóż postanowiłem, że przeprowadzę drobny (!), jednoosobowy (!) projekt na RUP’ie. To znaczy, spróbuję go w pewien sposób symulować i przejść przez każdą z faz projektu. Każda kolejna faza będzie jednym wpisem w tej serii. Jak to wyjdzie ? Zobaczymy, mam nadzieję, że fajnie bo może być ciekawie 🙂

Reklamy

Posted on 2011/10/08, in Inne and tagged , , , , . Bookmark the permalink. Dodaj komentarz.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj / Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj / Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj / Zmień )

Connecting to %s

%d blogerów lubi to: