RUP (Rational Unified Process) to iteracyjna metodyka wytwarzania oprogramowania. To w pełni konfigurowalna platforma obsługi procesów dotyczących tworzenia oprogramowania. Głównym celem tego podejścia jest produkcja wysokiej jakości oprogramowania w przewidywanym budżecie oraz czasie klienta. Projekt RUP powstał w celu przystosowania do konkretnego charakteru projektu, organizacji lub nawet zespołu projektowego. Podejście to zakłada budowanie systemu w kolejnych przebiegach. Jest to tak zwana ciężka metodologia ze względu na to, że duży nakład stosuje się wobec dokumentacji projektowej.
Ukształtowanie metodyki umożliwia dopasowanie procesu tworzenia danego systemu do potrzeb konkretnego projektu biorąc pod uwagę spektrum możliwości. Daje to jej dużą elastyczność dzięki której może być stosowana zarówno przy mniejszych jak i większych przedsięwzięciach.
Struktura RUP może być analizowana z dwóch perspektyw, tak zwanych wymiarów:
- wymiar statyczny (dotyczy statycznych stron projektu, między innymi możemy do nich zaliczyć: artefakty, dyscypliny, role czy aktywności)
- wymiar dynamiczny (przedstawia strony dynamiczne procesu, tutaj opisane jako terminy : iteracje, fazy czy kamienie milowe).
RUP to metodyka tworzenia oprogramowania związana ze spiralnym modelem cyklu życia danego oprogramowania. Powstał na bazie analizy najczęściej występujących niepowodzeń w projektach i został oparty o takie zasady jak: iteracyjne oraz przyrostowe tworzenie danego oprogramowania, sterowane ryzykiem oraz priorytetami, które ułatwiają integrację całego kodu. Oprócz tego bazuje na zbiorze pewnych zasad inżynierii oprogramowania a także na najlepszych praktykach, takich jak:
- iteracyjne wytwarzanie oprogramowania (w związku z częstymi zmianami w trakcie wytwarzania oprogramowania, wytwarzanie w kolejnych iteracjach umożliwia skupienie się głównie na obszarach najbardziej ryzykownych, w momencie kiedy iteracja kończy się stworzeniem artefaktu, redukuje to ryzyko w projekcie)
- zarządzanie wymaganiami (zarządzanie to skupia się głównie na zaspokajaniu oczekiwań końcowych użytkowników systemu za pomocą identyfikacji oraz pewnej specyfikacji ich potrzeb)
- używanie architektury opierającej się na komponentach (umożliwia to tworzenie systemu bardzo łatwo rozszerzalnego, który jednocześnie jest systemem intuicyjnym, natomiast komponentem jest zbiór powiązanych obiektów, metodyka ta skupia się na tworzeniu prostej architektury, która staje się prototypem dla pierwszej fazy implementacji, podczas każdej iteracji ewoluuje ona do architektury finalnej)
- graficznym projektowaniu oprogramowania (jest to abstrakcyjne projektowanie kodu oraz przedstawienie koncepcji za pośrednictwem bloków graficznych, jest to bardzo efektywny sposób ukazania perspektywy rozwiązania, daje możliwość wybrania jednego z najlepszych sposobów implementacji zbioru funkcjonalności, jest to też pośredni produkt między implementacją a analizą biznesowego procesu)
- kontroli jakości oprogramowania (proces kontroli pomaga w planowaniu kontroli jakości a także jej ocenie za pomocą wbudowania jej w cały proces tworzenia projektu a także przez zaangażowanie w nią członków zespołu, podejście to zakłada, że każdy jeden członek zespołu odpowiada za jakość w ciągu całego procesu, który koncentruje się na spełnianiu wymaganego poziomu jakości)
- procesu kontroli zmian w oprogramowaniu (proces ten definiuje różnego rodzaju metody ewidencji, kontroli oraz śledzenia zmian, koncepcja ta jest powiązana ściśle z tworzeniem architektury zorientowanej komputerowo).