Автор неизвестен - Rational unified process - страница 1

Страницы:
1  2 

RATIONAL UNIFIED

PROCESS

Opis metodyki i procesu produkcji

oprogramowania

rational unified process

Rational Umfi^ Pr°cess (RUP) to proces iteracyjnego

Proces RUP nie jest pojedynczym, scisle okreslonym procesem, ale raczej ezkbfonem procesu. Zostal on iaprojektowany w celu przystosowania do charakteru konkretnej organizacji (przedsi^biorstwa), konkretnego zespolu projektowego lUb nawet charakteru konkretnego

paaoSnoUcZosZkbnokrUetR;UcPh "X*^ elementy w

Rational Unified Process (RUP) to takze nazwa oprogramowania, opracowanego przez Rational Software (obecnie dost^pnego     w IBM). Produkt ten zawiera

naodw'krzenRatnrasoShoowac,oymhweers^MU}Pkt6ry pozwala

historia

Proces Rational si?ga swoimi korzeniami do oryginalnego modelu spiralnego Barrego Boehma - jeden z glownych .utorow RuP, K?n HortrLn, prowadz* razem z Ы^ш. Podejscie RationaR (tRational ft

nre°t;ess^3obre^^^3w^pp!odz,jlci^az^

oraz

Autorzy procesu skupili si<? na diagnozowaniu charakterystyk projektow, ktore zakonczyly si? fiaskiem. Post?p uijab w ten sposol), j^robowv ali poznac^przyczynyi owych niepowodzen. Przygl^dali si? r0wniez 6wczeSnie

i^sws romwszynwaeiyioonperpsmyania i

Lista najczeiszych bl^ zawierala nastjujace rzeczy:

1.     Zarzadzanie wymaganiami Ad hoc (najczeficiej brak zLldzama nimi)

3. Architektura oprogramowania nieodporna na obci^Zenia (ang. Brittle

4. Zbytnia, niepotrzebna zloZonosc oprogramowania

7. Subiektywna ocena post?pu projektu

8. Brak zarzadzania ryzykiem

9. Brak automiatyzacji"prowadzema projektu

О Niepowodzenie projektu byl0 spowodowane kombinacjl

dobrych praktyk, ktore nazwane zostaly wlasnie Rational

О Proces RUP zostal opracowany z uzyciem tych samych tedrn*. kt6rych Rational uzywal do modelowania

system6w - j?zyka UML. J?zyk UML powstawal r6wnolegle z RUP (r6wniez jako polaczenie dojwiadczenia w modelowaniu firm Objectory i Rational).

podstawy i najlepsze

praktyki

rup bazuje na zbiorze zasad inzynierii programowania

oraz najlepszych praktykach, na przyklad: Iteracyjnym wytwarzaniu oprogramowania (Iterative

2. Zarzadzaniu wymaganiami (Requirement Management)

3. UcrponuntrbhitedkaurchiSj na komponentach

4. Graficznym projektowaniu oprogramowania

5. Kontroli jakosci oprogramowania (Quality Assurance)

6. Procesu kontroli zmian w oprogramowaniu (Change

Management)

iteracyjne wytwarzanie oprogramowania

Wymagania podczas procesu wytwarzania oprogramowania ulegaja cz?stym zmianom, z

^awj^:aod!ru,•po;^rг''zr:n|'^az^m;;^6mrskuj^ »

RUP uzywa podejscia iteracyjnego i przyrostowego z nast?pujacych powod6w:

Integracja oprogramowania robiona krok po kroku podczas wytwzrzzniz oprogramowania, ograniczajac go do mniejszej liczby element6w

Integracja jest prostsza i mniej kosztowna

Skladowe oprogramowania sa projektowane oddzielnie i latwiej poddaja si?

Latwiej wykrywac zmiany wymagan i latwiej nimi zarzadzac

Ryzyka identyfikowane i atakowane sa wczesnie poniewaz kazda iteracja pozwala wykryc kolejne ryzyka

W iteracjach ulepszana jest architektura oprogramowania

praktykowane przy kazdym kamieniu milowym. W tej sytuacji, kamienie milowe stanowia zach?t? dla udzialowc6w oraz dostarczaja informacj? dotyczaca spelnienia wymagan przez system oraz gotowosci organizacji do jego wdrozenia.

koncowych systemu poprzez identyfikacj? i specyfiikacj? Ich potrzeb oraz wykrywanie zLany tych wymagan. Zalety zzrzZadzzniz

' Г zs 'ns:ш;^^:wymzgznizml sklada

projektami nazywa   Interesariuszami) .

UdISsllltzcjz problemu i jego wartosci z gl6wnymi

^od^s;6^b^oncmp CsZzrkoezhZiladzezr^)a rZSP0kIZzZniiChW jakiз.   Definicja systemu - tworzenie proje^u funkcj onzlnosci na

Pl^zlizidk6ymZggzl^, wyb6r kolejnosci realizacji (atakowania)

5. Zaw?zanie definicji systemu - uszczeg6lzwizniel

scenariuszy przypadk6w uzycia razem z uzytkownikami

systemu w c£lu stworzenia dokladnej Specyfikacji wymagan (ang. Software Requirements Specification - SRS), kt6ra 8 moze sluzyc (i na og6l sluzy) jako umowa pomi?dzy

6. Zarzadzanie zmmnami wymagan - zorzadzanie

architektura bazuj4ca na komponentach

о Uzycie architektury bazujacej na komponentach pozwala

^Knm^grzmmnWZzУ;ZzZImbУieZlb«iaZZnУCh obiekt6w (w

о Architektura oprogramowania zyskuje na znaczeniu w miar? jak systemy informatyczne staja si? coraz wi?ksze i bardziej zlozone. RuP skupia si? na stwoTzeniu prostej architektury w poczatkowych iteracjach. Staje si? ona prototypem dla pemszej fazy implementa^ (development). Ewoluuje ona w kazdej iteracji zblizajac si? do architektury finalnej. RUP zaklada reguly і ograniczenia projektowe w celu uchwycenia regul architektury. Poprzez iteracyjne wytwarzanie

^ntyfikacji komponent6w; kt6re moga by6 w dalszej technologii typu CORBA, COM, JEE.

wizualne modelowanie

oprogramowania

о Abstrakcja projektowzniz od kodu 1 przedstzwienie koncepcji za pomoca blok6w

pIPo^udlRc,dePg0pseacwfУmuZgawyeImzgzne modele 1

kontrola i weryfikacja jakosci oprogramowania

0 Or:^tjiZkoSr0^I^УZlntSZc^SliZbymZ jeusnktem

^вд^ш™ w nia wszystkich czlonk6w

Z^RdSZ^kagg^ tylko

SPlego procWsu. Pgoces koncentruje si?,na *

^nWn£^шgZg0(Wp^^SZkWSшklorJo^^zru

zarzadzanie zmianami w oProgramowaniu

0 ^o^a^^ ^ ^^isItdone:ednycll

nieuniknione. RUp defniuje metody sledzenia, ewidencji і kontroli zmian. Zdefiniowane sa takze rzw. sec,re „ork0pWces (bezpieczne przestrznnie roboc^e), bfeo ^«иад na ^^to^fe, zy zmwnW w inn^ch systemach nlie wplyna na

pyos:e^zrzztwn^nnempZr:hzterrУisIe

zorientowanej komponentowo.

cykl zycia projektu

Cykl ^ w RUp bazuje na modelu spiralnym.

projektowych. Cykl zycia w RUP uklada zadania w fazy і iteracje.

Projekt zostal podzielony na cztery fazy:

1. Faza rozpocz?cia (Inception phase)

2. Faza opracowywania (Elaboration phase)

3. Faza konstrukcji (Construction phase)

4. Faza przekazania systemu (Transition phase)

faza rozpocz^cia

0 W fazie tej formulowany jest problem finansowa. Dodatkowo uzupelnia si? go o prosty

faza rozpocz^cia

Po stworzeniu powyzszych dokument6w projekt

sprawdza si? wedlug nast?pujacych kryteri6w: > Wgoda urytkownik6w na oszacowany koszt/czas

Zrozumienie wymagan poprzez ocen? jakosci gl6wnych

przypadk6w uzycia.

scesu wyz^ .koszt6w priorytet6w ryzyka 1

> Rozmiar stworzonego prototypu architektury.

Wydatki rzeczywiste wzgl?dem wydatk6w planowanych.

> Jezeli wst?pny projekt nie osiagnie kamienia milowego (ang. milestone* nazywbnego Lfecycle Obf ective

Milestone, moze byc alb0 zakonczony, alb0 faza ta moze

zostac jeszce raz powt6rzona (w celu ulepszenia projektu

faza opracowania

-  W tej fazie projekt systemu nabiera ksztalt6w. Przeprowadzona jest podstawowa architektura systemu.

1 skKTwgszo m t^k^^zz kssecwioii zostali

2. Zostala opracowana architektura systemu.

3. Architektura ta pozwala realizowaC gl6wne przypadki uzycia.

4. Sprawdzona zostala zgodnosc zagadnienia biznesowego oraz listy

5. Stworzony zostal plan prac dla calego projektu.

   Jezeli projekt nie moze przePsC tew fazy, ciagle mamy czas na jego

faza konstrukcji

W fazie    gl6wny nacisk polozony jest na

[bIU^W]kWm^nenУ;SWl^h:UfnШkCe0^Ш^ШІ

wi??wszkcshoIsroperkzczpchoImozmibУyc^^^^^ :o^zUk■£ °o^yc^. pnozjiIs0jree^ldzie^dnyzlnje

Wprtoegrfzmteoo~^gltapUeu^^^zo:wenrkjzw

faza przekazania systemu

0 ^l^lm60ju^^^wnsWe:e<^:::cc^

okreslonymi w pierwszej fazie.

о Spelnienie cel6w jest tozsame z osiagnieciem Product Release Milestone i zakoiicZeniem cyklu wytwarzania oprogramowania.

FAZY PROJEKTOWANIA I PRZEKSZTALCANIA W METODYCE RUP

Poczqtkowa   ; Oprac. 1 ; Oprac. 2 ; Budow. 1; Budow. 2 Budow. N Przeksit. 1; Przelcszt 2

ITERACJE

dyscypliny i post^p prac

о RUp bazuje na zbi0rze klock6w (building blocks, content

elements). Opisuja one, co ma zostac stworzone, jakie

krok po kroku jak

о Gl6wne klocki:

> Rola (Roles) - Kto? - Rola definiuje zbi6r wymaganych umiej?tnosci, kompetencji і odpowiedzialnosci.

Страницы:
1  2 


Похожие статьи

Автор неизвестен - 13 самых важных уроков библии

Автор неизвестен - Беседы на книгу бытие

Автор неизвестен - Беседы на шестоднев

Автор неизвестен - Богословие

Автор неизвестен - Божественность христа