Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 1

Projektowanie systemów

informacyjnych

Ewa Stemposz, Kazimierz Subieta

Instytut Podstaw Informatyki PAN,
Warszawa

Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa

Wykład 1

Model przypadków użycia, cd.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 2

Zagadnienia

Zagadnienia

Rational Unified Process

Model kaskadowy

Dlaczego nie model kaskadowy ?

Recepta: rozwój iteracyjny

Aktywności a fazy i iteracje

Korzyści z podejścia iteracyjnego

Podsumowanie

Planownie z uwzględnianiem iteracji

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 3

Rational Unified Process (RUP)

 Rational Unified Process − produkt firmy Rational
Software, poprzez promowanie zdyscyplinowanego podejścia
do

rozwoju

oprogramowania,

ułatwia

produkcję

oprogramowania wysokiej jakości, w przewidywalnym dla
klienta czasie i budżecie.
 RUP oparty został o zbiór sześciu najlepszych praktyk:
iteracyjny rozwój, zarządzanie wymaganiami, architektura
oparta o komponenty, modelowanie wizualne, systematyczna
weryfikacja jakości i zarządzanie zmianami.

 RUP był wykorzystywany w małych i dużych projektach
(dla różnych zastosowań) przez więcej niż 1000 organizacji

−

dane z końca 1999 roku:

 Telekomunikacja: Ericsson, Alcatel, MCI

 Transport, lotnictwo, obrona: Lockheed-Martin, British Aerospace

 Produkcja: Xerox, Volvo, Intel

 Finanse: Visa, Merrill Lynch, Schwab

 Inne: Ernst & Young, Oracle, Deloitte & Touche.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 4

Model kaskadowy

Analiza

wymagań

Projektowan

ie

Implementacja

(kodowanie,

testowanie)

Integracja

(weryfikacj

a)

Specyfikac
ja
wymagań

Specyfikacja
projektu
implementacji

Kod

Wypuszczen

ie produktu

Wymagania użytkownika

W

ten

sposób,

w

5

podstawowych

krokach,

rozwiązuje

się

większość

problemów inżynierskich, np.
buduje wieżowce i mosty.

Jeszcze w latach 80-tych
model kaskadowy był
uważany

za

jedyne

rozsądne podejście do
budowy
oprogramowania.

1

2

3

4

5

Model kaskadowy
Inne nazwy: model wodospadowy,
model sekwencyjny

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 5

Dlaczego nie model kaskadowy ? (1)

1. Błędne założenia: (a) wymagania mogą być zamrożone po

przeprowadzeniu analizy, (b) projekt implementacji będzie
„ od razu” dobry.

2. Błędna ocena kontekstu rozwoju oprogramowania.
3. Błędna ocena czynnika ludzkiego.
4. Błędna

ocena

możliwości

wykorzystania

podejścia

sekwencyjnego.

5. Niedojrzałość inżynierii oprogramowania – zaledwie

kilkadziesiąt lat doświadczenia, w przeciwieństwie do
tysięcy lat prób i błędów w innych dziedzinach, np. w
budowie budynków czy mostów.

Dlaczego nie model kaskadowy?

Ad. 1. Błędne założenie (a): wymagania mogą być “zamrożone”.

W modelu kaskadowym przyjmuje się założenie, że wymagania
na

system

zostaną

poprawnie

zdefiniowane

po

przeprowadzeniu fazy analizy, co w praktyce prawie zawsze
okazuje się niemożliwe do osiągnięcia. W większości
przypadków, wymagania zmieniają się cały czas w trakcie
rozwoju oprogramowania i fakt ten należy przyjąć do
wiadomości !!!

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 6

Dlaczego nie model kaskadowy ? (2)

 Zmiany w środowisku pracy użytkownika: Zmiany
wprowadzane w środowisku pracy użytkownika są tym
bardziej prawdopodobne, im dłużej trwa projekt, np. nie
tygodnie (czy miesiące) a lata.
 Wzrost świadomości użytkownika odnośnie rozwiązywanego
problemu, czego efektem może być i z reguły jest zmiana
specyfikacji wymagań. Użytkownik wie “dokładnie” czego
chce nie na dwa lata przed datą, kiedy oprogramowanie ma
być gotowe, ale kilka tygodni po tej dacie (po oddaniu
systemu),

gdy

oprogramowanie

przejdzie

już

fazę

rozpoznawania – efekt IKIWISI (I’ll Know It When I See It).

Co może powodować zmiany wymagań?

Ponadto, poważną przeszkodą na drodze do zamrażania
wymagań jest niemożność zdefiniowania wymagań z
dostateczną

precyzją,

na

wystarczającym

poziomie

szczegółowości.

Formalne

specyfikacje

wymagań

nie

sprawdziły się nigdzie, poza małymi, specjalizowanymi
zastosowaniami. Są trudne do wykorzystania i nieprzyjazne
dla użytkownika.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 7

Dlaczego nie model kaskadowy ? (3)

Ad. 1. Błędne założenie (b): Projekt implementacji –
zbudowany w drugim kroku – będzie dobry (i to najlepiej
„od razu”).

Przez „dobry” projekt implementacji rozumie się taki projekt,
który

zapewnia

realizację

nie

tylko

oczekiwanej

funkcjonalności, ale też osiągnięcie własności systemu takich
jak np. poprawność, odpowiednia wydajność czy niezawodność,
itp. Można wyprodukować tony papierowej dokumentacji,
przeprowadzić tysiące przeglądów, a w praktyce i tak nie
zabezpiecza to przed uniknięciem błędów w projekcie
logicznym. Inżynieria oprogramowania nie osiągnęła jak dotąd
poziomu innych dyscyplin inżynieryjnych. Być może nigdy nie
osiągnie i być może powinna częścią sztuki, ponieważ
wytwarzanie oprogramowania czasami przypomina działalność
na pograniczu psychologii, filozofii czy socjologii.

Zmiany technologicze: Software czy hardware, z którym
rozpoczynano projekt, może już nie być wytwarzany w
momencie wypuszczania produktu.
Konkurencja na rynku: Tu na niekorzyść projektu działa czas
jego realizacji – nawet doskonały produkt nie ma szans na
rynku, który poszedł już o krok dalej.

Ad. 2. Błędna ocena kontekstu rozwoju oprogramowania

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 8

Dlaczego nie model kaskadowy ? (4)

Ad. 3. Błędna ocena czynnika ludzkiego
Jeśli projekt trwa krótko, ludzie szybko widzą namacalne
rezultaty swojej działalności i pozostają przez cały czas
skoncentrowani na pracy. Błędy, wykrywane w trakcie pracy,
nie wymagają zbyt dalekich powrotów w celu przeprowadzenia
korekty.
Próba wykorzystania modelu kaskadowego odpowiedniego dla
małych projektów (kilka tygodni czy miesięcy), dla projektu
trwającego np. kilka lat, naraża ten projekt na subtelne (ale
znaczące efekty) związane z ludźmi, uczestnikami projektu:
 Progres jest widoczny w postaci rosnącego stosu papierów i
diagramów – brakuje drobnego zastrzyku adrenaliny, by być
odpowiednio zmotywowanym.
 Błędy są wykrywane poźno – dopiero podczas testowania czy
integracji – w efekcie słabego sprzężenia zwrotnego
cechującego proces sekwencyjny.
 Uczestnicy projektu mają mało okazji do ulepszania swojej
pracy – ważne dla osób niedoświadczonych lub jeśli praca
odbywa się w nowym środowisku narzędziowym.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 9

Dlaczego nie model kaskadowy ? (5)

 W podejściu sekwencyjnym każdy krok kończy się
wyprodukowaniem zbioru artefaktów, które po przeglądzie,
akceptacji i zamrożeniu są wykorzystywane jako punkt
startowy dla następnej aktywności.

W praktyce, w podejściu sekwencyjnym nacisk jest z reguły
kładziony na produkcję i zamrażanie dokumentów.

Ograniczone powroty w celu drobniejszych korekt są
tolerowane, w przeciwieństwie do zmian, które wymagałyby
powrotu do początkowych kroków, co mogłoby być przyczyną
całkowitego niepowodzenia projektu.

Stąd – dla długich projektów opartych o podejście sekwencyjne
– często obserwuje się znaczący opór kierownictwa w sytuacji
zaistnienia potrzeby zmian (wewnętrzni oponenci są często
usuwani ze składu zespołu projektowego), co w efekcie
skutkuje pogorszeniem jakości produktu finalnego.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 10

Dlaczego nie model kaskadowy ? (6)

Dla projektów małych (czas realizacji: kilka tygodni czy
miesięcy), czy też projektów z niewielką liczbą nowości
(doświadczeni ludzie, znane narzędzia, znany problem, itp.)
model sekwencyjny sprawdza się dobrze. Nie sprawdza się,
gdy jest dużo ryzyk, np. dużo niewiadomych czy dużo nowości.
W modelu sekwencyjnym jedyne, co można zrobić dla obsługi
przyszłych ryzyk, to pozostawienie zapasu czasu na obsługę
wszelkich nieprzewidzianych wydarzeń.

Ad. 4. Model sekwencyjny jest nieodpowiedni dla dużych,
złożonych projektów z dużą liczbą ryzyk?

Ad. 5. Inżynieria oprogramownia – dziedzina niedojrzała

Brak “fundamentalnych praw” w rozwoju oprogramowania
i tempo w jakim zmienia się rynek czyni produkcję
oprogramowania dziedziną o dużym stopniu ryzyka. Dlatego
ryzyka muszą być bezwzględnie brane pod uwagę przez
organizacje zajmujące się wytwarzaniem oprogramowania.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 11

Recepta: rozwój iteracyjny (1)

Podejście oparte o realizację kompletnego zbioru
funkcjonalności kontra podejście oparte o realizację
stopniową (volume-based versus time-based scheduling)

 “Wszystko czego potrzebujesz, zrobimy w ciągu dziewięciu
miesięcy” kontra “w ciągu dwóch pierwszych miesięcy zrobimy
trzy pozycje z twojej listy, w kolejnych trzech miesiącach
zrobimy to i tamto, itd.”.
 To pierwsze podejście, typowe dla procesu sekwencyjnego,
nie przynosi zbyt wielkich zysków, kiedy brakuje czasu: jak
np. decyzja o nie realizowaniu własności X, podjęta w środku
implementacji,

gdy

poświęciliśmy

już

czas

na

jej

specyfikowanie,

projekt

implementacji

i

częściową

implementację.
 Drugi sposób pracy, typowy dla podejścia iteracyjnego,
wymusza dzisiejszy rynek: produkt zostaje wypuszczony z
pewnym zbiorem własności, a potem tworzona jest następna,
ulepszona i/lub rozszerzona wersja.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 12

Recepta: rozwój iteracyjny (2)

Jak wykorzystać podejście sekwencyjne w procesie
iteracyjnym?

 Jeśli proces sekwencyjny sprawdza się zarówno dla małych
projektów, jak i dla tych z niewielką liczbą ryzyk, dlaczego nie
realizować dużych projektów podzieliwszy je na małe, z
których każdy będzie przeprowadzany w oparciu o model
kaskadowy.
Można wybrać podzbiór wymagań, zrobić dla nich projekt
logiczny i implementację, poddać weryfikacji, po czym
rozpocząć pracę z kolejnym podzbiorem wymagań, i tak dalej
aż do osiągnięcia kompletnego, stabilnego produktu finalnego.

 Jak dokonywać wyboru, co powinno być zrealizowane w
kolejnych iteracjach – jaki podzbiór wymagań i jakie ryzyka
brać pod uwagę?

 Jak się ustrzec przed zjawiskiem, by każda kolejna iteracja
nie rozpoczynała się ponownie początkiem realizacji projektu?

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 13

Recepta: rozwój iteracyjny (3)

Aw

P

Im

In

Aw - Analiza wymagań, P - Projektowanie, Im- Implementacja, In - Integracja

Aw

P

Im

In

Aw

P

Im

In

Aw

P

Im

In

jedna iteracja

czas

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 14

Korzyści z podejścia iteracyjnego

 Braki (błędy) o dużej wadze dla produktu finalnego mogą być
wykrywane wcześniej, co umożliwia wcześniejszą reakcję.

 Łatwiej (bo częściej) można uzyskiwać informacje zwrotne od
użytkownika, dzięki czemu wzrastają szanse na prawidłową
specyfikację wymagań.

 Niespójności między wymaganiami, projektem implementacji i
kodem mogą być wykrywane wcześniej.

 Zespół projektowy może poświęcić większą uwagę elementom
krytycznym w aktualnej fazie projektu.

 Praca, wykonywana przez różne grupy członków zespołu
projektowego może być bardziej równomiernie rozłożona w
czasie.

 Dzięki iteracyjnemu (ciągłemu i systematycznemu) testowaniu
łatwiej szacować statusu projektu. Cały czas są dostępne ”
niezbite dowody” ułatwiające to zadanie − ważne dla
wszystkich uczestników projektu.

 Doświadczenia, nabyte w jednym cyklu, można z powodzeniem
wykorzystywać w następnych cyklach, czy w ogóle − do
ulepszania całości procesu.

Korzyści wynikające z wykorzystania podejścia iteracyjnego

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 15

Aktywności a fazy i iteracje (1)

PoczątkowaOpracowywanie

Planowanie

Wymagania

Architektura

Projekt implementacji

Implementacja

Testowanie,

weryfikowanie

Konstrukcja Wdrażanie

Integracja

Iter.
wstępna

Iter. #1, Iter. #2

Iter.#n, Iter. #..., Iter.#m

Iter. #m+1, Iter .#m+2

Każda iteracja przebiega w oparciu o model kaskadowy; 4 fazy tworzą jeden cykl

10%

30%

50%

10%

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 16

Aktywności a fazy i iteracje (2)

W każdej z faz położony jest różny nacisk na
różne aktywności:

 Faza początkowa: tu wysiłki koncentrują się na określeniu
kontekstu systemu (aktorów), wymagań funkcjonalnych, zakresu
odpowiedzialności (głównych wymagań), ograniczeń (wymagań
niefunkcjonalnych), kryteriów akceptacji dla produktu finalnego
oraz zgrubnego planu projektu

.

 Faza opracowywania: wymaganiom nadal poświęca się wiele
uwagi,

ale

też

prowadzone

są

prace

projektowe

i

implementacyjne (w celu określenia projektu architektury i
wytworzenia prototypu, stanowiącego podstawę dla dalszych
prac) oraz planuje się mitygację technicznych ryzyk poprzez
testowanie różnych technik i narzędzi.
 Faza konstrukcji: nacisk jest położony na prace projektowe i
implementacyjne. W tej fazie prototyp jest rozwijany, aż do
uzyskania pierwszego operacyjnego produktu.
 Faza wdrażania: prace są skoncentrowane na zapewnieniu
produktowi odpowiedniej jakości: usuwa się błędy, ulepsza i/lub
uzupełnia o brakujące elementy, wypełnia bazę, trenuje
użytkowników.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 17

Aktywności a fazy i iteracje (3)

 Podstawowe zadania: (1) przeprowadzić „bardziej dokładną”
analizę, (2) wypracować fundamenty dla architektury, (3)
wyeliminować elementy obarczone największym ryzykiem, (4)
uszczegółowić plan projektu (czyli skonstruować szczegółowe
plany dla iteracji).
Decyzje architektoniczne muszą bazować na zrozumieniu
całości

systemu:

jego

funkcjonalności

i

ograniczeń

(“zrozumienie z perspektywy na milę szerokiej i na cal
głębokiej”).

 Faza opracowywania – najbardziej krytyczna z czterech
faz (wysoki koszt, wysokie ryzyko): wymagania, architektura,
plany powinny osiągnąć stabilną postać, ryzyka muszą być
zmitygowane, tak aby była możliwa realna werfikacja
zaplanowanych kosztów i czasu potrzebnego na ukończenie
projektu.
 Bada się różne rozwiązania budując prototyp(y) – w jednej
lub kilku iteracjach (zakres, rozmiar, nowości, inne ryzyka).
Budowa

prototypów

ułatwia

mitygowanie ryzyk

oraz

ustanawianie

kompromisów

między

wymaganiami

a

możliwościami środowiska implementacji.

Faza opracowywania

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 18

Planowanie z uwzględnieniem

iteracji (1)

Planowanie projektu z uwzględnieniem iteracji wymaga
rozstrzygnięcia kwestii, które nie istniały przy zastosowaniu
tradycyjnego podejścia kaskadowego, jak np.:

 Jak wiele iteracji będzie potrzebne?

 Jak długo powinna trwać każda z nich?

 W jaki sposób należy ustalić cele i „zawartość” każdej
iteracji?

 Jak należy śledzić postęp prac w trakcie realizacji iteracji?

Planowanie dużych, złożonych projektów

Ambitne próby planowania realizacji całości dużych, złożonych
projektów z dokładnością „co do minuty”, wyróżniania
aktywności i przypisywania osób do zadań na kilka miesięcy
czy kilka lat do przodu, jak wykazała praktyka − są z góry
skazane na niepowodzenie. Tworzono diagramy Gantt’a (czy
semantyczne sieci aktywności), które pokrywały całe ściany, a
mimo to projekty kończyły się niepowodzeniem. Skuteczna
realizacja szczegółowych planów wymaga posiadania zarówno
dobrego zrozumienia problemu, jak i stabilnych wymagań,
stabilnej architektury oraz ukończony choć jeden podobny
projekt, tak by w oparciu o niego można było ustalić
szczegółowy WBS.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 19

Planowanie z uwzględnieniem iteracji

(2)

Innymi słowy, jak można planować zbudowanie przez osobę X w
tygodniu n modułu Y skoro w momencie planowania, w żaden
sposób nie da się w tym czasie w ogóle wydedukować potrzeby
posiadania modułu Y? Planowanie szczegółowe jest możliwe w
tych dziedzinach inżynieryjnych, gdzie WBS jest mniej lub
bardziej zestandaryzowane i stabilne, gdzie kolejność zadań jest
wystarczajaco uporządkowana. Np. budując budynek nie można
wznosić jednocześnie piętra pierwszego i czwartego. Po
pierwszym musi powstać drugie, potem trzecie, aby można było
zająć się czwartym.

RUP rekomenduje, by realizacja projektu była opierana na
dwóch

rodzajach

planów,

różniących

się

stopniem

szczegółowości: plan faz (zgrubny – nie więcej niż jedna, dwie
strony opisu) i seria planów dla iteracji (szczegółowych).

Plan faz

Tworzony jest jeden plan faz, jeden na potrzeby całego
projektu. Plan faz obejmuje z reguły jeden cykl − czasami,
stosownie do potrzeb, kilka kolejnych cykli. Tworzony jest
bardzo wcześnie, w fazie początkowej. W każdej momencie,
może być poddawany modyfikacji.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 20

Planowanie z uwzględnieniem iteracji

(3)

Plan faz zawiera poniższe
elementy:

 Daty głównych kamieni milowych:

 LCO – określenie celów danego cyklu rozwijania projektu
(koniec fazy początkowej; projekt ma dobrze określony
zakres

odpowiedzialności

i zapewnione środki

na

realizację).

 LCA – specyfikacja architektury (koniec fazy
opracowywania; stabilizacja architektury).

 IOC – osiągnięta początkowa zdolność operacyjna
(koniec fazy konstrukcji; pierwsze beta).

 Wypuszczenie produktu (koniec fazy wdrażania i koniec
danego cyklu).

 Profile zespołowe --> jakie zasoby ludzkie są wymagane na
poszczególnych etapach cyklu.
 Specyfikację mniej ważnych kamieni milowych --> data
zakończenia każdej iteracji wraz ze specyfikacją jej celów (o ile
można je zidentyfikować).

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 21

Planowanie z uwzględnieniem iteracji

(4)

Plan iteracji

Tworzony jest jeden plan dla każdej iteracji (plan
szczegółowy). Projekt z reguły posiada dwa plany iteracji
aktywne w danym momencie:

 Plan dla bieżącej iteracji: jest wykorzystywany do
śledzenia postępów prac w trakcie realizacji iteracji.
 Plan dla następnej iteracji: jest tworzony począwszy od
połowy bieżącej iteracji i jest prawie (?) gotowy przy jej
końcu.

Plan iteracji tworzony jest za pomocą tradycyjnych technik
(diagramy Gantt’a, itp.) i narzędzi do planowania (Microsoft
Project, itp.). Cel – definiowanie zadań, przypisanie zadań do
osób i zespołów. Plan zawiera ważne daty, takie jak np.:
zakończenie budowy „czegoś”, dostarczenie komponentów z
innej organizacji czy terminy głównych przeglądów.

RUP – przyjmując za podstawę proces iteracyjny i niekończącą
się akomodację zmian celów i taktyki – zakłada tym samym, że
nie istnieją racjonalne powody, by marnować czas na
przygotowywanie

szczegółowych

planów

dla

dłuższych

horyzontów czasowych: takie plany są trudne do zarządzania,
szybko stają się nieaktualne oraz z reguły są ignorowane przez
organizacje wykonawcze).

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 22

Planowanie z uwzględnieniem iteracji

(5)



W fazie początkowej często uważa się, że iteracji nie ma, tzn.

nie ma czegoś, co można by nazwać „prawdziwą iteracją” (mini-
projektem): żaden kod nie jest produkowany, wykonywane są
przede wszystkim aktywności związane z rozpoznawaniem,
planowaniem i marketingiem.

Iteracje w fazie początkowej

 Zbudować prototyp, by przekonać siebie czy sponsora, że
proponowane rozwiązanie (lepiej: pomysł na rozwiązanie)
jest dobre.
 Zbudować prototyp, w celu mitygowania ryzyk
technicznych (np. eksploracja nowych technologii czy
nowych

algorytmów)

czy

udowodnienia,

że

cele

wydajnościowe są osiągalne.
 Przyspieszyć wdrażanie narzędzi i procesów w
organizacji.

Czasami jednak iteracja jest potrzebna, po to by:

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 23

Planowanie z uwzględnieniem iteracji

(6)

Iteracje w fazie opracowywania

Plany dla iteracji w fazie opracowywania muszą być budowane w
oparciu o trzy, najważniejsze w tej fazie elementy: ryzyka,
własności krytyczne dla osiągnięcia sukcesu i pokrycie :

 Plany powinny być budowane tak, by większość ryzyk została
zmitygowana lub „wysłana na emeryturę” właśnie w fazie
opracowywania.

 Ponieważ podstawowym celem fazy opracowywania jest
budowa stabilnej architektury, plany muszą być konstruowane
tak,

by

architektura

adresowała

wszystkie

aspekty

oprogramowania (pokrycie). Jest to ważne, bo architektura
stanowi bazę dla dalszego planowania.

 Ryzyka są bardzo ważne, ale to nie mitygacja ryzyk jest
celem ostatecznym. Ostatecznym celem jest uzyskanie
produktu, posiadającego własności uznane za krytyczne dla
osiągnięcia sukcesu.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 24

Podsumowanie (1)



Podejście

iteracyjne

ułatwia

dokonywanie

zmian

(związanych z użytkownikiem, rynkiem czy technologiami),
mitygację ryzyk, wprowadzanie technologii ponownego użycia,
podnoszenie umiejętności członków zespołu, ulepszanie
procesu jako takiego – wszystko to w efekcie skutkuje
uzyskaniem lepszej jakości produktu finalnego.

 Proces sekwencyjny jest odpowiedni dla realizacji małych
projektów, czy tych z niewielką liczbą ryzyk (mało nowości,
znane technologie, znana dziedzina problemowa, doświadczeni
ludzie), natomiast niezbyt nadaje się dla projektów dużych, z
dużą liczbą ryzyk.

 Proces iteracyjny jest realizowany w oparciu o sekwencję
iteracji. W trakcie każdej iteracji, opartej o model kaskadowy,
wykonywane są aktywności związane z wymaganiami,
tworzeniem

projektu

implementacji,

implementacją

i

szacowaniem rezultatów.

 W celu ułatwienia zarządzania procesem realizacji, iteracje
zostały

pogrupowane

w

cztery

fazy:

początkową,

opracowywania, konstrukcji i wdrażania. W każdej z faz
położono różny nacisk na różne aktywności.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b,
Slajd 25

Podsumowanie (2)

 planowaniu iteracji,

 budowie i walidacji stabilnej architektury systemu,

 definiowaniu przypadków i procedur testowych w modelu
testów,

 tworzeniu dokumentacji użytkownika,

 rozmieszczaniu aplikacji (ang. deployment).

W RUP, przypadki użycia wspomagają członków zespołu przy:

 RUP − jako proces “prowadzony” w oparciu o przypadki
użycia − uczynił z przypadków bazę dla całego procesu
budowania produktu tworząc w oparciu o nie rodzaj języka
stanowiącego podstawę do komunikacji między wszystkimi
osobami zaangażowanymi w realizację projektu.