Projektowanie systemów informacyjnych

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

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

Implementacja

(kodowanie,

testowanie)

Integracja

(weryfikacj

Specyfikac
ja
wymagań

Specyfikacja
projektu
implementacji

Kod

Wypuszczen

ie produktu

Wymagania użytkownika

ten

sposób,

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

jedyne

rozsądne podejście do
budowy
oprogramowania.

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

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ą,

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

jej

specyfikowanie,

projekt

implementacji

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 - Analiza wymagań, P - Projektowanie, Im- Implementacja, In - Integracja

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

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

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

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

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,

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ą

szacowaniem rezultatów.

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

pogrupowane

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.

Document Outline