ISI Wykłady

Terminarz i zawarto
wykadw sala 126 WI1

godz. 12:15-13:45
W1 26.02.2014
Od slajdu 1 do 45
W2 05.03.2014
Od s.46
W3 12.03.2014
Od s.94
W4 19.03.2014
Od s. 125
W5 26.03.2014
Od s.162
W6 03.04.2014
Od s. 218
W7 - 10.04.2014
Od s. 258
W8 - 24.04.2014
Od s. 351
W9 30.04.2014
W10 07.05.2014
W11- 14.05.2014
W12- 28.05.2014
W13-04.06.2014
W14-11.06.2014
W15-16.06.2014 (poniedziaek)
s. 537
INYNIERIA SYSTEMW
INFORMATYCZNYCH I
Dr hab. n.t. Boena miakowska prof. ndzw. ZUT
Informacje podstawowe o
przedmiocie
Wymiar przedmiotu 30 W+ 30 L
Wagi w ocenie kocowej za przedmiot:
(1W+0.6 L)/1.6
5 punktw ECTS
Przedmiot bdzie kontynuowany w semestrze III
studiw jako INYNIERIA SYSTEMW
INFORMATYCZNYCH II
ZAGADNIENIA
ORGANIZACYJNE
TRECI I EFEKTY
KSZTACENIA
Treci programowe
przedmiotu
Podstawowe pojcia (system informacyjny, informatyczny, inynieria
systemw informatycznych).
Relacje miedzy systemem informacyjnym a system
informatycznym, rola zasobw informacyjnych i procesy
informacyjno - decyzyjne w organizacji. System informatyczny jako
obiekt techniczny.
Obecne i postulowane zastosowania systemw informatycznych.
Struktura systemu informatycznego: funkcjonalna, informacyjna,
organizacyjno-przestrzenna i techniczna.
Pojcia podstawowe w modelowaniu i analizie systemw
informatycznych, metody, techniki, metodyki, metodologie.
Modele cyklu ycia systemu informatycznego.
Treci programowe
przedmiotu
Faza analizy i modelowania w cyklu ycia systemu
informatycznego organizacji.
Analiza systemu informatycznego: czynnoci, podstawowe
rezultaty i zoono fazy analizy systemu informatycznego.
Analiza potrzeb, precyzowanie zakresu, standardy tworzenia
specyfikacji. Metody i narzdzia planowania i analizy systemu
informacyjnego. Analiza potrzeb uytkownika. Kluczowe czynniki
sukcesu fazy analizy i projektowania systemw informatycznych.
Dokumentacja fazy analizy i modelowania systemu informatycznego.
Treci programowe
przedmiotu
Przegld metod projektowania systemw informatycznych.
Metody strukturalne. Modelowanie danych i procesw: cele i metody
opisania potrzeb informacyjnych, diagram zwizkw encji - tworzenie i
przykady, okrelenie zalenoci pomidzy procesami, diagramy
przepywu danych - elementy, tworzenie i przykady, klasyfikacja
(diagramy kontekstowe, zerowe i szczegowe) przykady.
Paradygmat obiektowy w projektowaniu systemu informatycznego.
Metody analizy i projektowania obiektowego. UML.
Metody wytwarzania systemw informatycznych uwarunkowanych
czasem.
Podejcie socjo - spoeczne do budowy systemw informatycznych.
Swobodne metody wytwarzania oprogramowania. Metodyka Scrum,
FDD, programowanie ekstremalne, projektowanie adaptacyjne,
Projektowanie systemw informatycznych z uyciem wielokrotnym.
Treci programowe
przedmiotu
Szacowanie czasu realizacji systemw informatycznych, kosztw,
efektw, zagroe i ryzyka w procesie wytwarzania systemu
informatycznego.
Jako systemw informatycznych i jako procesw jego
budowy.
Bezpieczestwo systemw informatycznych
Korzyci z inwestycji informatycznych.
Ryzyko przedsiwzi informatycznych
Wskanik zagroenia przedsiwzicia informatycznego
Metody testowania oprogramowania.
Techniki wspomagajce procesy wytwarzania oprogramowania
Zaliczenie wykadu
Efekty ksztacenia w obszarze

wiedzy
IC_1A_C/05/01_W01 student zna metody
gromadzenia i przetwarzania danych w systemach
informatycznych
IC_1A_C/05/01_W02 student zna podstawowe
techniki, metody i metodyki tworzenia systemw
informatycznych
IC_1A_C/05/01_W03 student zna metody
strukturalne, obiektowe i elastyczne projektowania
systemw informatycznych
IC_1A_C/05/01_W04 - zna zastosowania

umiejtnoci
IC_1A_C/05/01_U01 student potrafi przeprowadzi proces
analizy systemu informatycznego z uyciem wybranej
metody
IC_1A_C/05/01_U02 - potrafi przeprowadzi proces
projektowania systemu informatycznego z uyciem wybranej
metodologii oraz metodyki
IC_1A_C/05/01_U03 - potrafi sporzdzi prototyp systemu
informatycznego
IC_1A_C/05/01_U04 - potrafi opracowa odpowiedni do
etapu cyklu ycia systemu informatycznego dokumentacje
techniczna

kompetencji spoecznych
IC_1A_C/05/01_K01 - rozumie potrzeb stosowania
obowizujcych zasad prawnych i aspektw zwizanych z
dziedzin przedmiotow w procesie wytwarzania systemw
informatycznych
Zasady zaliczania przedmiotu

Zaliczenie pisemne (5 pyta-zada: pytania 1
weryfikacja IC_1A_C/05/01_W01; pytanie 2 IC_1A_C/05/01_W02, itd. za zadanie weryfikuje
umiejtnoci od IC_1A_C/05/01_U01 do
IC_1A_C/05/01_U04 oraz IC_1A_C/05/01_K01)
Wagi w ocenie kocowej za przedmiot:
(1W+0.6 L)/1.6
Rodzaj studiw
Kierunek Inynieria Cyfryzacji
5
punktw
ECTS
Termin
studia stacjonarne I stopnia
Termin
zaliczenia
wykadw:
16.06.2014
r. sala 126 WI2
Termin
podstawowy
I termin poprawkowy
30.06.2014 r. Godz. 12-14 sala 215
II termin poprawkowy
10.09.2014 r. godz. 10-12 sala 215
Zasady zaliczania przedmiotu

przedmiotu
Jeli wszystkie efekty osignito w terminie podstawowym
(pozytywna ocena z kadego zadania) to:
ocena kocowa za wykad = rednia z ocen uzyskanych za
poszczeglne pytania
Jeli nie osignito wszystkich efektw w terminie podstawowym

to:
terminu podstawowego = ndst.
student ma prawo do dwch poprawek niezaliczonych efektw ksztacenia,
ocena kocowa za wykad = (rednia z pozytywnych ocen efektw + 2 *ip)/(ip+1)

gdzie ip liczba poprawek
jest podstaw do obliczenia pozytywnej oceny za wykad:
13
Ocena
za
efekt 1
Ocena
za
efekt 2
Ocena
za
efekt 3
Ocena
za
efekt 4
Ocena
za
efekt
5-8
Ocena
za
efekt 9
I poprawka
Nie dotyczy
Zaliczono
efekt 2 oraz
efekty 5-8
na ocen
dst
Zaliczono
efekt 2
ocen dst
efekty 5-8
niezaliczone
(ndst)
II
poprawka
Nie
dotyczy
Nie
dotyczy
Zaliczon
o efekt
5-8 na
ocen
dst
Ocena kocowa za wykad
dobry
(podstawa: rednia z
pozytywnych ocen za
efekty)
4,0 Ocena za
przedmiot
W terminie
podstawowym ocena
ndst
W terminie
poprawkowym dobry
(podstawa: rednia z
pozytywnych ocen za
efekty)
3,0 Ocena za wykad
W terminie
podstawowym terminie
pierwszej poprawki
ocena ndst
W drugim terminie
poprawkowym dobry
(podstawa: rednia z
pozytywnych ocen za
efekty)
2,67 Ocena za wykad
14
Literatura
Cadle J., Yeates D.: Zarzdzanie procesem tworzenia
systemw informacyjnych ,WNT, Warszawa 2001.
Dbrowski W., Stasiak A., Wolski M.: modelowanie
systemw informatycznych w jzyku UML 2.1 w praktyce,
PWN 2007
Flasiski M.: Zarzdzanie projektami informatycznymi,
PWN, Warszawa 2006.
Graessie P. i inni: UML 2.0 w akcji, Przewodnik oparty na
projektach, Helion 2008
Beynon-Davies Paul:Inynieria systemw informatycznych
Olejniczak W., Szyjewski Z.: Inynieria systemw
informatycznych w e-gospodarce,
Literatura cd..
Jaszkiewicz A.: Inynieria oprogramowania, Helion,
Gliwice 1997.
Leffingwell D. i inni: Zarzdzanie wymaganiami. Seria:
Inynieria oprogramowania, WNT, Warszawa 2003
Pritchard C.: Zarzdzanie ryzykiem w projektach, teoria
i praktyka, WIG-PRESS, Warszawa 2002
miaek M.: Zrozumie UML 2.0 metody
modelowania obiektowego, Helion, Gliwice 2005.
Wrycza S. i inni: Jzyk UML 2.0 w modelowaniu
systemw informatycznych, Helion, Gliwice 2005.
Konsultacje
roda godz. 14:00-15:30 pokj 113
Kontakt :bsmialkowska@zut.edu.pl
PODSTAWOWE
DEFINICJE
Systemy informacyjne
(systematyka poj)
zbir zasad, metod i procedur tworzenia, przesyania,

magazynowania i przetwarzania informacji
formalny zesp rodkw kapitaowych oraz algorytmw,
ktrych funkcjonowanie przejawia si w zbieraniu,
kodowaniu, magazynowaniu, przetwarzaniu, dekodowaniu i
uytkowaniu danych potrzebnych dla podejmowania decyzji i
zarzdzania
usystematyzowana i uporzdkowana sie powiza midzy
takimi elementami jak: czowiek, dane, metody oraz
urzdzenia do zbierania, gromadzenia, przesyania i
przetwarzania danych, majcych na celu zaspokojenie
potrzeb informacyjnych zainteresowanych ogniw
Systemy informatyczny
(systematyka poj)
celowe zestawienie ludzi, danych, procesw, sposobw

komunikacji, infrastruktury sieciowej i urzdze
komputerowych, ktre to elementy wspdziaaj w celu
zapewnienia codziennego funkcjonowania organizacji jak
rwnie wspieraj rozwizywanie problemw i podejmowanie
decyzji przez kadr kierownicz
spenia funkcj systemu informacyjnego
okrelony, wyodrbniony obszar systemu informacyjnego dla
danego obiektu obsugiwany za pomoc technicznych
rodkw informatyki
oparte na technologii komputerowej rozwizanie
pojedynczego problemu biznesowego. Moe by to aplikacja,
rozwizanie sprztowe lub poczenie obu tych skadnikw
Systemy informacyjne
(systematyka poj)
system informatyczny moe by jedn z czci

skadowych systemu informacyjnego
system informacyjny moe si skada z wicej ni jednego
systemu informatycznego
system informacyjny niekoniecznie musi zawiera elementy
infrastruktury IT
zbir powizanych ze sob elementw, ktrego funkcj jest
przetwarzanie danych przy uyciu techniki komputerowej,
takich jak: Sprzt, Oprogramowanie, Zasoby osobowe
(ludzie), elementy organizacyjne (czyli procedury
korzystania z systemu informatycznego, instrukcje robocze
itp.) oraz elementy informacyjne (np. bazy wiedzy - na
przykad podrcznik ksigowania w wypadku systemu FK)
Porwnanie poj
System informacyjny - to system, ktrego celem
dziaania jest dostarczanie odbiorcy informacji,
uytecznej do jego dziaania.
Przykady : system monitorowania bezpieczestwa
obiektu, telewizja itp.
System informatyczny (SI) - to system

informacyjny lub informacyjno-decyzyjny w ktrym
zastosowano komputery.
Przykady: system rekrutacji na UWM, system finansowoksigowy itp.
Informatyka w kompleksowym
zarzdzaniu organizacj (np.:
gospodarcz)
Cele gospodarcze
STARTEGICZNE
OPERACYJNE
OBSUGA POSPRZED.
DYSTRYBUCJA
PRODUKCJA / SERWIS
ZAOPATRZENIE
REALIZ. ZAMWIENIA
SPRZEDA
ROZWJ PRODUKTW
Proces
gospodarczy
SPECJALISTA
KIEROWNIK
DYREKTOR
ZARZD
Organizacja
Rozwj SI
ROZWJ SYSTEMU INFORMATYCZNEGO
uytkownik
NAJWYSZY SZCZEBEL ZARZDZANIA
SYSTEM
EKSPERCKI
SYSTEM
WSPOMAGANIA
DECYZJI
WYSZA I REDNIA KADRA KIEROWNICZA,

ANALITYCY BIZNESOWI
SYSTEM
INFORMOWANIA
KIEROWNICTWA
REDNIA KADRA KIEROWNICZA,

ANALITYCY BIZNESOWI
SYSTEM
INFORMATYCZNY
ZARZDZANIA
REDNIA KADRA KIEROWNICZA,

PERSONEL ADMINISTRACYJNY
SYSTEM
REJESTRACYJNY
PERSONEL ADMINISTRACYJNY,
OPERATORZY, AUTOMATY
Rozwj SI
produkt
DECYZJE BIZNESOWE
SYSTEM
EKSPERCKI
SYSTEM
WSPOMAGANIA
DECYZJI
SYSTEM
INFORMOWANIA
KIEROWNICTWA
SYSTEM
INFORMATYCZNY
ZARZDZANIA
INFORMACJA ZARZDCZA
DANE ZAGREGOWANE
DANE ZINTEGROWANE
SYSTEM
REJESTRACYJNY
WYSPY INFORMACYJNE
Rozwj SI
CELE STRATEGICZNE
SYSTEM
EKSPERCKI
SYSTEM
WSPOMAGANIA
DECYZJI
SYSTEM
INFORMOWANIA
KIEROWNICTWA
SYSTEM
INFORMATYCZNY
ZARZDZANIA
SYSTEM
REJESTRACYJNY
CELE OPERACYJNE
Restrukturyzacja organizacji
Zmiana struktury (czsto zmniejszenie ilociowe):
zasobw organizacji (majtek, zatrudnienie)
rde finansowania
asortymentu produktw
rynku zbytu
w celu utrzymania lub wzmocnienia pozycji rynkowej
Strategie restrukturyzacji
przedsibiorstw w Polsce
Rynkowa: konkurencja krajowa, import, opacalno
eksportu, nowe formy marketingu, jako produktu,
potencja produkcyjny, sieci dystrybucji, rozeznanie
rynku
Produktowa: oferta produktowa, jako produktw,
nowoczesne maszyny, koszty jednostkowe
produkcji,
Co to jest Business Process

Reengineering (BPR)?
Metoda szybkiego i radykalnego przeprojektowania
strategicznych, dodajcych warto z punktu widzenia
klienta, procesw oraz powizanych z nimi systemw,
procedur, struktury organizacyjnej, w celu optymalizacji toku
pracy i produktywnoci organizacji
D. Morris, J. Brendon
Co to jest Business Process

Reengineering ?...
BPR to fundamentalne przemylenie od nowa i radykalne

przeprojektowanie procesw w firmie, prowadzce do
dramatycznej (przeomowej) poprawy osiganych wynikw
(takich jak koszty, jako, serwis i szybko)
M. Hammer, J. Champy
Przedmiot reinynierii
Definicja procesu:
Zbir czynnoci wymagajcy na wejciu zasobw i dajcy
na wyjciu rezultat, majcy konkretn warto dla klienta
M. Hammer, J. Champy
Organizacja
funkcjonalna a procesy
(np.: gospodarcze)
ZLECENIE PRODUKCYJNE
REALIZACJA ZLECENIA
SPRZEDA
Cel reorganizacji procesw

Np.: OSIGNICIE PRZEWAGI KONKURENCYJNEJ
poprzez
Obnianie kosztw procesw
Podnoszenie jakoci produktw
Skracanie czasu trwania procesw
Podnoszenie satysfakcji klientw
Skala i zakres zmian w

reinynierii
WYGADZANIE
WSKI
SZEROKI
PRZEPROJEKTOWANIE
Analiza wariantw zmian
Zakres zmian
Moliwe efekty
Umiarkowana poprawa
Dziaalnoci
Ryzyko:
Due, due
skomplikowanie
Moliwe efekty
Niewielki wpyw na
dziaalno firmy
Ryzyko:
Mae
Moliwe efekty
Radykalna poprawa caej
dziaalnoci
Ryzyko:
Due, decyzja:wszystko
albo nic
Moliwe efekty
Radykalna poprawa
wybranych procesw
Ryzyko:
Ograniczone do
wybranych procesw
Skala zmian
Kontekst czasowy wdraania

informatyki i reinynierii
Poprzedzenie reorganizacji procesw wdroeniem
Jednoczesne wdroenie systemu informatycznego i
przeprowadzanie reorganizacji procesw
Przeprowadzenie reorganizacji procesw przed
rozpoczciem procesu wdroenia systemu
informatycznego
Najpierw system informatyczny,

pniej reorganizacja
Wdroenie SI:
Reorganizacja:
Zaleta: mniejsze ryzyko niepowodzenia, mniejsze

obcienie zasobw ludzkich
Wada: konieczno rekonfiguracji systemu w celu
uwzgldnienia zmian, dodatkowa pracochonno,
odoenie korzyci w czasie, iteracyjne dochodzenie do
rozwizania
Jednoczenie system
informatyczny i reorganizacja
Wdroenie SI:
Reorganizacja:
Zaleta: krtki czas przeprowadzania zmian i uzyskania

korzyci, dobrze dopracowane zmiany i narzdzia
Wada: due ryzyko niepowodzenia, due obcienie
zasobw ludzkich
Najpierw reorganizacja, pniej

system informatyczny
Wdroenie SI:
Reorganizacja:
Zaleta: brak
Wada: bardzo kosztowne stosowanie narzdzi
zastpczych/starych, niebezpieczestwo zaniecha lub
spycenia zmian, ktre wymagaj wsparcia
informatycznego
Informatyka jako czynnik

umoliwiajcy przeprowadzenie
reinynierii procesw
Robienie tego co ju robimy lepiej, szybciej i taniej (w nowy
sposb)
Robienie zupenie nowych rzeczy dziki nowym
moliwociom, jakie daje nam informatyka (pomysy na nowe
dziaania)
Informatyka jako narzdzie

wspomagajce przeprowadzenie
restrukturyzacji
Pomiar efektywnoci istniejcych procesw, analiza
procesw
Diagnoza i analiza istniejcych procesw
Projektowanie nowych procesw
Zarzdzanie procesem restrukturyzacji
Benchmarking procesw
Wzajemne oddziaywanie
systemu informatycznego i
reinynierii
Zmiany wymuszane przez system informatyczny

Zmiany wspomagane przez system informatyczny
Restrukturyzacja i reinynieria
a SI
sia nowych technologii

nie ley w nich samych
a w kreatywnych i innowacyjnych zastosowaniach
ZADANIA INYNIERII
SYSTEMW
INFORMATYCZNYCH
Czym zajmuje si inynieria

systemw informatycznych?
Inynieria umiejtno projektowania i realizacji
projektw, np. budowli, systemw,
urzdze itp.
Inynieria systemw informatycznych to
dziedzina inynierii, ktra obejmuje wszystkie
aspekty (nie tylko techniczne) procesu tworzenia
systemw informatycznych (SI), we wszystkich
fazach jego istnienia i wytwarzania
Dwa nurty inynieria

W inynierii SI wystpuj dwa nurty:
formalny - postuluje stosowanie metod formalnych;
praktyczny postuluje metody powstae na bazie
wiedzy i dowiadcze zdobytych w procesie
realizacji prac projektowych nad SI. Stosowane s tu
specjalne notacje graficzne, nie w peni
sformalizowane.
Tworzeniem, rozwojem i pielgnacj

zajmuje si
Inynieria systemw
informatycznych
(zwana rwnie inynieri oprogramowania)

Inynieri systemw informatycznych jest dziedzin
praktyczn, a jednoczenie sztuk projektowania,
utrzymywania i rozwoju aplikacji.
Dziaania te mog si zakoczy albo sukcesem, albo
porak.
Inynieria systemw informatycznych odsania tajniki:
funkcjonowania systemw informatycznych,
projektowania systemw informatycznych,
implementacji systemw i tworzenia aplikacji,
metod zarzdzania procesem tworzenia SI

Okrela:
Sposoby prowadzenia przedsiwzi
informatycznych;
Techniki planowania, szacowania kosztw,
harmonogramowania i monitorowania;
Metody analizy i projektowania systemw;
Techniki zwikszania niezawodnoci
oprogramowania;

Okrela:
Sposoby testowania systemw;
Sposoby przygotowania dokumentacji technicznej i
uytkowej;
Procedury kontroli jakoci;
Metody redukcji kosztw konserwacji;
Techniki pracy zespoowej
Dlaczego ta dziedzina jest

wana?
Oglny kryzys procesw wytwarzania systemw
informatycznych
Ciga potrzeba doskonalenia i usprawniania procesw
wytwarzania systemw informatycznych
Nowe zastosowania systemw informatycznych
Dlaczego zdarzaj si nieudane

projekt informatyczny ?
Miar niepowodzenia projektu jest niedotrzymania
jednego lub wicej z nastpujcych parametrw:
Budet
Czas realizacji
Funkcjonalno
Rzeczywisto w statystyce
w ponad 50% przedsiwziciach informatycznych
przekraczany jest termin i budet projektu,
ponad 25% przedsiwzi informatycznych jest

przerywanych.
Rzeczywisto w statystyce
Marsz ku klsce ???
Zdecydowana wikszo duych projektw
informatycznych jest z gry skazana na niepowodzenie!
Polskie przykady
Informatyzacja PZU
Informatyzacja ZUS
System POJAZD
Informatyzacja urzdw skarbowych
The Standish Group

Amerykaska instytucja badawcza.
Dziaalno: kompleksowa analiza rynku
amerykaskiego w zakresie
skutecznoci realizacji projektw
informatycznych.
www.standishgroup.com
Kolejne raporty: The CHAOS Chronicles od

1994 r. do 2013 r.
Dlaczego CHAOS?
Chaos stan niezorganizowania, zamtu, nieadu
O chaosie w projektowaniu SI decyduje przewaajca
liczba przedsiwzi zakoczonych :
niepowodzeniem w sensie ilociowym, czyli:
przekroczeniem estymowanego czasu trwania
dziaa projektowych;
przekroczeniem budetu;
porzuceniem z okrelonych powodw;
niepowodzeniem w sensie jakociowym, kiedy
gotowy system wykazuje du niezgodno z
pierwotn specyfikacj wymaga uytkownika.
rdo:
http://versionone.com/assets/img/files/ChaosManifesto2013.pdf
Udany projekt
Zakres
Produkt kocowy
Udany
projekt
Koszty
Koszty realizacji
Termin
Czas
Realizacja projektw - statystyki

rdo: http://versionone.com/assets/img/files/ChaosManifesto2013.pdf
Rok
2004
2006
2008
2010
2012
Nieudane
czciowo
53 %
44 %
44 %
42 %
43 %
Nieudane
cakowicie
18 %
19%
24 %
21 %
18 %
Udane
projekty
29 %
35 %
32 %
37 %
39 %
Jakie
projekty
100%
90%
80%
70%
60%
Udane projekty
50%
Nieudane cakowicie
40%
Nieudane czciowo
30%
20%
10%
0%
2004
2006
2008
2010
2012
Realizacja projektw - statystyki

rdo: http://versionone.com/assets/img/files/ChaosManifesto2013.pdf
Rok
2004
2006
2008
2010
2012
Czas
84 %
72 %
79 %
71 %
74 %
Koszt
56 %
47%
54 %
46 %
59 %
Zrealizowana
funkcjonalno
zaprojektowana
64 %
68 %
67 %
74 %
69 %
czynnik
60%
50%
40%
Nieudane czciowo
30%
Nieudane cakowicie
Udane projekty
20%
10%
0%
2004
2006
2008
2010
2012
Czynniki sukcesu
Czynnik
1994
2000
Zaangaowanie uytkownika
16%
16%
Wsparcie zarzdu (kierownictwa, sponsora)
14%
18%
Jasne sformuowanie wymaga
13%
6%
Waciwe planowanie
10%
Brak
Realne oczekiwania
8%
Brak
Krtsze etapy projektowania
8%
10%
Kompetentny zesp projektowy
7%
Brak
Jasno okrelona wasno projektu

(odpowiedzialno)
5%
Brak
Jasna wizja i cele
3%
12%
Ciko pracujcy, skupiony na projekcie zesp
2%
Brak
Brak (ew. 7)
14%
Formalna metodyka
Brak
6%
Zastosowanie standardw infrastruktury
Brak
8%
Brak (ew. 4)
5%
1%
5%
Dowiadczony kierownik zespou
Wiarygodne oszacowanie
Inne
Realizacja maych projektw

czynniki sukcesu
Czynniki sukcesu
Liczba
projektw
Wsparcie zarzdu (kierownictwa, sponsora)
20
Zaangaowanie uytkownika
15
Optymalizacja
15
Wiedza z dziedziny zarzdzania projektem
12
Zwinne procesy
10
Jasne sformuowanie wymaga
Dojrzaoci rodowiska
Realne oczekiwania - wykonalno
Narzdzia i infrastruktura
rdo:
Wyniki badania
20 maych
(do 1mln$)
projektw
ukoczonych
w 2012 r.
Mae a due projekty

rnice w osigniciu sukcesu
Projekty mae (do 1 mln $)
Projekty due (powyej 10 mln $)
Nieudane czciowo
Nieudane czciowo
nieudane ckowicie
Nieudane cakowicie
udane projekty
Udane projekty
Dane z 2012 roku
rdo:
Wnioski z bada
Chaos w obszarze projektowania SI spowodowany jest
bdami ludzkimi, a nie czynnikami technologicznymi
SI maj coraz wiksz zoono (np.: Windows 2000
35 mln linii kodu a Windows XP okoo 50 mln linii kodu)
Liczba osb zaangaowanych w tworzenie zoonych SI
wzrasta (np.: przy tworzeniu Windows NT 3.1 brao
udzia 200 programistw i 140 testerw za w Windows
2000 - 1400 programistw i 1700 testerw)
Wzrasta liczba uytkownikw zoonych SI (np.: liczba
uzytkownikw Linuxa w roku 1992 wynosia 1000 a w
1998 7,5 mln osb ).
Podstawowe problemy w
tworzeniu SI
Niewaciwa interpretacja wymaga klienta
Czste i zbyt pne zgaszanie zmian zwizanych z
oprogramowaniem
Nieprawidowe oszacowanie czasu realizacji projektu
(opnienia czasowe)
Nieprawidowe oszacowanie budetu i zasobw
Problemy w komunikacji pomidzy czonkami zespou
projektowego
Podstawowe problemy w
tworzeniu SI
Dua liczba maych bdw w oprogramowaniu,
wynikajca z nieprawidowego testowania
Problemy wdroeniowe i brak odpowiedniej pielgnacji
oprogramowania
rda zoonoci systemw

informatycznych
Zoono
dziedzinowa
Software
Zoono
technologiczna
Zoono
psychologiczna
Metody projektowania
Cigle niedoskonae metody i narzdzia tworzenia i
weryfikacji systemw informatycznych
XP
HELP!
PSL/
PSA
UM
L
DFD
ERD
SADT
RSL/
REVS
Kryzys oprogramowania
Dugi i kosztowny cykl tworzenia oprogramowania
Dugi i kosztowny cykl ycia SI, wymagajcy staych zmian
Wysokie koszty utrzymania oprogramowania
Wysokie prawdopodobiestwo niepowodzenia projektu
programistycznego
Sprzeczno pomidzy odpowiedzialnoci wspczesnych
systemw informatycznych, a ich zawodnoci
Problemy wspdziaania niezalenie zbudowanego
oprogramowania, szczeglnie istotne przy dzisiejszych
tendencjach integracyjnych
Kryzys oprogramowania
Uzalenienie organizacji od systemw komputerowych i
przyjtych technologii przetwarzania informacji (czsto
niestabilnych w dugim horyzoncie czasowym)
Denie do przystosowania istniejcych i dziaajcych
systemw do nowych wymaga i tendencji oraz platform
sprztowo-programowych
Niski stopie powtarzalnoci poszczeglnych przedsiwzi
Niska kultura ponownego uycia wytworzonych
komponentw projektw i oprogramowania
Szybki rozwj narzdzi informatycznych
Prawa Murphiego
jeeli gdziekolwiek moe pojawi si bd, tam na pewno
si pojawi
nie ma programw bezbdnych, s tylko takie w
ktrych dotd nie znaleziono bdu
gwne bdy powstaj na

styku: klient firma
informatyczna, projektantprogramista, programistakomputer
Obecne i postulowane
zastosowania SI - rodzaje SI
Dua
Istniej oczywicie wyjtki np. bankowe systemy kredytowe
Dugi
Czas reakcji
Zoono
Transakcyjne on-line
Transakcyjne off-line
Proste systemy raportujce
Systemy informowania
kierownictwa
Systemy inteligentne
Maa
Krtki
Ewolucja SI do
zarzdzania firm
DEM
ERP
CRM
MRP II
MRP
IC
1960
1970
1980
1990
2000
IC (Inventory Control) - zarzdzanie gospodark magazynow

MRP (Material Requirments Planing) - planowanie potrzeb materiaowych poprzez
wydawanie zlece zakupu i produkcji dokadnie w takim momencie, aby dany produkt
pojawi si w potrzebnej chwili i wymaganej iloci
MRP II (Manufacturing Resource Planing) - planowanie zasobw produkcyjnych
poszerzone o bilansowanie zasobw produkcyjnych i dystrybucj (gwny skadnik BIS)
ERP (Enterprice Resource Planing) - (okrelana jako MRP III - Money Resource Planing
lub MRP II Plus) planowanie zasobw przedsibiorstwa wraz z procedurami finansowymi,
w tym ksigowo zarzdcza, cash flow i rachunek kosztw dziaania
DEM (Dynamic Enterprice Modeler) - dynamiczne modelowanie przedsibiorstwa,
umoliwiajce bezporednie przejcie od modelu firmy do gotowej konfiguracji aplikacji

dla poszczeglnych uytkownikw
CRM (Customer Relationship Management) - zarzdzanie kontaktami z klientem
MRP II Plus (ERP)

Standard MRP II Plus to rozwinicie koncepcji wariantu rozwinitego standardu
MRP II. W zwizku z tym realizuje on dodatkowo nastpujce funkcje:
zarzdzanie zmianami konstrukcyjnymi i technologicznymi,
zarzdzanie dokumentacj techniczn,
integracja z systemami CAD/CAM/CAP,
zarzdzanie remontami i serwisem (zlecenia i umowy),
zarzdzanie jakoci,
dystrybucj (planowanie potrzeb, transportu i obsuga zlece) i rozwinita
obsuga sprzeday,
zarzdzanie rodkami trwaymi i wyposaeniem,
zarzdzanie kadrami i pacami i strumieniami rodkw patniczych,
rachunkowo zarzdcza,
kontroling,
generowanie raportw,
integracja multimediw,
przegldarki baz danych, itp.
DEM
Standard DEM to zintegrowane narzdzie umoliwiajce zarwno opracowanie
nowych jak i udoskonalanie istniejcych procesw gospodarczych (reinynieria).
Umoliwia on dynamiczne stworzenie modelu lokalnego (np. jeden dzia firmy)
jak i obejmujcy wszystkie dziay korporacji w oparciu o odpowiednie modele
odniesienia.
PROJEKT MODELU
Model
przedsibiorstwa
Model branowy
PROJEKT MODELU
LOKALNEGO
FAZY
ZAKRES
MODEL
ODNIESIENIA
BIBLIOTEKA
KOMPONENTW
Model oglny
GWNA BIBLIOTEKA WZORCW

(REPOZYTORIUM)
DEM
Wprowadza si tu optymalizacj, ktra pozwala na bieco wprowadza
zmiany w funkcjonowaniu firmy. Dziki temu przedsibiorstwo wraz z
systemem yje i ewoluuje.
model
funkcjonalny
przegld z
uytkownikami
kluczowymi
wizja
dyskusje
Implementacja
(faza podstawowa)
symulacje
optymalizacja
..................
dyskusje z
Zarzdem
krytyczne
wskaniki
sukcesu
model
procesowy
optymalizacja
Strategia rozwoju organizacji i

informatyzacji
MISJA ORGANIZACJI
BADANIE OTOCZENIA
BADANIE
ORGANIZACJI
(szanse i zagroenia)
(mocne i sabe strony)
WIEDZA O RYNKU
TRENDY
TECHNOLOGICZNE
STRATEGIA ROZWOJU ORGANIZACJI

STRATEGIA INFORMATYZACJI
ORGANIZACJI
ZSI a otoczenie organizacji

moliwoci systemw rozproszonych
ZSI
sie lokalna
stacje robocze systemu

serwer
przedsibiorstwa
sie rozlega
serwer kontrahenta
serwer klienta
serwer dostawcy
MRP (ERP)
CRM
back office
front office
PRZEDSIBIORSTWO - ORANIZACJA
KLIENT (KONTRAHENT)
Systemy CRM
Systemy klasy MRP, ERP stanowi rozwizania dedykowane wewntrznemu

zarzdzaniu przedsibiorstwem
przedsibiorstwem..
Systemy CRM (Customer Relationship Management) pozwalaj rwnie
zarzdza kontaktami z klientem
klientem..
Systemy CRM
CM
(Contact Management)
proste
jednostanowiskowe
aplikacje,
funkcje kalendarza i baza
danych pozwalaj na analiz
danych dotyczcych klienta i
historii kontaktw
SFA
(Sales Force Automation)
oraz:
CRS - Call Reporting Systems
TMS - Territory Management Systems
SMS - Sales Management Systems
STA - Sales Team Automation
CRM
(Customer Relationship Management)
udostpnianie klientowi
informacji on-line,
zarzdzanie sprzeda,
obsuga klienta w ramach
jednego systemu
CRM:
systemy obsugujce kanay komunikacji z klientem,

systemy front-office obejmujce m.in. marketing, sprzeda,
wsparcie klienta,
systemy analityczne.
KLIENCI
...
fax
telefon
FRONT OFFICE
E-mail
Systemy wymiany informacji
OBSUGA KLIENTW
MARKETING
SPZREDA
SYSTEMY INFORMATYCZNE
zarzdzania firm
zarzdzania zasobami
ludzkimi
zarzdzania finansami
SERWIS
...
HURTOWNIE DANYCH
ZARZDZANIE WIEDZ
ANALITYKA
BACK OFFICE
WWW
Funkcje (moduy) CRM:

sprzeda:
zarzdzanie
kontaktami
(profile,
struktura,
historia
kontaktw sprzeday),
zarzdzanie kontem (generowanie ofert, zamwienia,
transakcje),
analizy w ramach cyklu sprzeday,
monitorowanie statusu klienta i potencjalnych kontaktw
handlowych;
zarzdzanie terminarzem i korespondencj:
kalendarz i baza danych uytkownikw (grup),
obsuga poczty tradycyjnej i elektronicznej (fax, e-mail);
marketing:
zarzdzanie kampani,
katalog produktw,
konfigurator produktw,
cenniki i oferty,
analizy efektywnoci kampanii,
dystrybucja informacji o kilentach zainteresowanych ofert;
Funkcje (moduy) CRM:

telemarketing:
ukadanie list telefonicznych wg definicji grup docelowych,
automatyczne wybieranie numeru,
generowanie list potencjalnych klientw,
zbieranie zamwie;
serwis i wsparcie klienta po sprzeday:
przydzielenie, ledzenie i raportowanie zada,
zarzdzanie problemem serwisowym,
kontrola zamwie,
obsuga gwarancyjna i pogwarancyjna;
integracja z systemami ERP:
zarzdzanie finansami, ksigowo, produkcja, dystrybucja,
zarzdzanie zasobami ludzkimi;
synchronizacja danych - dotyczy wspdziaania pomidzy
urzdzeniami (np. laptopy) a centraln baz danych lub innymi
bazami i serwerami aplikacji;
e-commers - realizowanie handlu elektronicznego;
call center - usugowe wsparcie klienta.
Ewolucja SIZ
zintegrowane systemy
informatyczne
systemy czasu rzeczywistego
STOPIE
INTEGRACJI
systemy sztucznej inteligencji

systemy informowania kierownictwa
systemy eksperckie
systemy wspomagania decyzji
systemy informacyjno-decyzyjne
systemy ewidencyjno-transakcyjne
CZAS
1960
1970
1980
1990
2000
Ewolucja ZSI
Mwic o ZSI naley mie na uwadze:
system zarzdzania zorganizowany (SIZ) moduowo
Umoliwia etapowe wdraanie tych skadowych,
ktre s niezbdne z uwagi na specyfik firmy.
obsugujcy
wszystkie
sfery
dziaalnoci
przedsibiorstwa
Poczwszy od marketingu i planowania oraz
zaopatrzenia, poprzez techniczne przygotowanie
produkcji i jej sterowanie, dystrybucj, sprzeda,
gospodark remontow, a do prac finansowoksigowych i kadrowych.
wszystkie zasoby danych, procedury zarzdzania,
sterowanie i regulacja procesw wytwrczych s
przetwarzane
przy
wsparciu
technologii
informatycznej
Cechy ZSI
Zintegrowane systemy informatyczne stanowi urzeczywistnienie idei integracji
kompleksowych systemw informatycznego wspomagania procesw zarzdzania w
przedsibiorstwie z kompleksowymi systemami komputerowego wytwarzania.
Gwne cechy ZSI:
kompleksowo funkcjonalna - obejmuje wszystkie sfery firmy,
integracja danych i procesw - dotyczy wymiany informacji wewntrz firmy jak i
z jej otoczeniem,
elastyczno strukturalna (skalowalno) i funkcjonalna - dynamiczne
dopasowanie przy zmiennych wymaganiach i potrzebach otoczenia,
otwarto - moliwo rozbudowy systemu i tworzenie nowych pocze
zewntrznych,
zaawansowanie merytoryczne - moliwo penego informatycznego wsparcia
procesw informacyjno-decyzyjnych
zaawansowanie technologiczne - zgodno ze standardami
programowymi oraz moliwo przenoszenia na inne platformy
zgodno z przepisami (np. ustaw o rachunkowoci)
sprztowo-
Przykadowy sposoby
integracji cd
Faza I - Analiza przedsibiorstwa obejmuje:
okrelenie celw strategicznych przedsibiorstwa
zdefiniowanie problemw, wymaga i kryteriw wyboru ZSI
udokumentowanie istniejcych procedur dziaania
opracowanie opisw procesw podstawowych i pomocniczych
przygotowanie koniecznej restrukturyzacji przedsibiorstwa
ocena skali przedsiwzicia, ryzyka, kosztw i terminw realizacji
(studium wykonalnoci)
Faza II - Opracowanie koncepcji informatyzacji przedsibiorstwa
obejmuje:
selekcja i wybr gotowego ZSI
zestawienie oprogramowania aplikacyjnego wedug modelu
prototypowania
modelowanie
konfiguracji
oprogramowania
narzdziowego,
systemowego,
sieciowego
oraz
opracowanie
projektu
infrastruktury technicznej
Informatyzacja organizacji a
problemy jej restrukturyzacji
(uwarunkowanie tworzenia ZSI)
strategia rozwoju organizacji
oraz
strategia jej informatyzacji
restrukturyzacja
organizacji
REALIZACJA
ZSI
techniczna
infrastruktura
informatyki
oprogramowanie aplikacyjne
oraz
transfer wiedzy
Informatyzacja organizacji, majca na celu wdroenie ZSI, wymaga
poprzedzenia tego procesu zmianami o charakterze organizacyjnym.
Restrukturyzacja jest przemyleniem od podstaw i radykalnym
przeprojektowaniem procesw gospodarczych w celu osignicia
zdecydowanego polepszenia biecych, zasadniczych miar wydajnoci
(jako, szybko dziaania, poziom obsugi klientw).
Rodzaje restrukturyzacji:
podstawowa - orientacja ta podwaa wszystkie zaoenia, na ktrych
opiera si dziaalno gospodarcza, czyli dotychczasow strategi
przedsibiorstwa oraz jego procedury operacyjne,
radykalna - w zalenoci od potrzeb tworzone (definiowane) s nowe
procesy, a nie usprawniane istniejce,
istotna - wzrost efektywnoci ma na celu znaczne podniesienie
sprawnoci funkcjonowania przedsibiorstwa, a nie jedynie jej
marginalny przyrost, osigany w wyniku technik cigego doskonalenia,
restrukturyzacja procesw - przeamuje si dotychczasowe podziay
funkcjonalne i likwiduje w ten sposb nieefektywno, bdc
skutkiem przekazywania pracy midzy wyspecjalizowanymi
jednostkami (dziaami) i pracownikami; dziaanie musi by
zorganizowane wok procesw, a nie wok indywidualnych zada.
W konsekwencji chodzi o stworzenie przedsibiorstwa nowego typu
(zorientowanego procesowo).
okrelenie procesw w przedsibiorstwie (pocztek-koniec,
waciciel, dostawcy-klienci, wsplne zalenoci czyli podprocesy,
powizania z zasobami i zasileniami),
zmiany w zarzdzaniu (wizja i misja przedsibiorstwa, kultura
wewntrz-organizacyjna,
metody
kierowania,
rekrutacja
i
motywacja pracownikw
Informatyzacja nie moe wspiera nieefektywnych i niewydajnych
procesw. Dziaania restrukturyzacyjne powinny by nadrzdne w
stosunku do prac projektowo-wdroeniowych ZSI.
Informatyzacja przedsibiorstwa:
faza pierwsza - analiza i definicja procesw, celw, funkcji, struktur
danych, itp.,
faza druga - modelowanie procesw zgodnie z celami przedsibiorstwa,
utworzenie struktury organizacyjnej firmy i modelu systemu
informatycznego,
faza trzecia - tworzenie szczegowych specyfikacji procesw i
tworzenie ZSI.
Restrukturyzacja
przedsibiorstwa
Przygotowanie infrastruktury
informatycznej
Podejcie konwencjonalne dziaania

szeregowe
z
koniecznoci
modyfikacji
modelowania
procesw
gospodarczych po drugim a
nawet trzecim etapie
etapie..
Budowa ZSI
Restrukturyzacja
przedsibiorstwa
Budowa ZSI
Podejcie zalecane - dopuszcza

si
rwnolego
prac
restrukturyzacyjnych i wstpnych
wdroeniowych z moliwoci
iteracyjnego
uszczegowiania
dziaa
wdroeniowych
i
przygotowywania
docelowej
infrastruktury..
infrastruktury
Uzyskanie kompletnej
infrastruktury informatycznej
Struktura SI
Funkcjonalna (struktura funkcji - jakie funkcje
realizuje SI? jaki jest ich podzia i zwizki midzy
sob?)
Informacyjna (struktura informacji w SI, co jest
danymi wejciowymi i wynikowymi SI?),
Organizacyjno-przestrzenna (jak system jest
podzielony? gdzie realizowane s przestrzennie jego
funkcje?)
Techniczna (struktura infrastruktury technicznej SI
wyrnienie serwerw, procesorw, stacji roboczych,
czy, itp.)
Pojcia podstawowe w
modelowaniu i analizie
Analiza SI proces budowy koncepcji - logicznego
model systemu,
Modelowanie SI obejmuje proces uszczegawiania
modelu logicznego do opracowania oprogramowania
systemu,
Metodyka to ustandaryzowane dla wybranego
obszaru podejcie do rozwizywania problemw.
Metodyka abstrahuje od merytorycznego kontekstu
danego obszaru, a skupia si na metodach realizacji
zada, szczeglnie metodach zarzdzania
Wykad 3 13.III.2014
Metodyka skupia si na
metodach
Metody (w tym metody rozwizywania zada) s
przedmiotem bada a w wyniku tych bada powstaj
uoglnienia i w ten sposb powstaje nowa dziedzina
wiedzy, ktrej przedmiotem s owe metody.
Metody -> badanie metod ->wiedza ->nauka
Metodologia
Nauka o metodach bada naukowych, ich
skutecznoci i wartoci poznawczej to
metodologia.
Klasycznie wyrnia si metodologie w:
naukach cisych
naukach przyrodniczych
naukach spoecznych
Metody -> badanie metod -> metodologia
Metodyka a metodologia
metodologia skupia si na odpowiedzi na pytanie:
Co naley robi?,
metodyka koncentruje si na poszukiwaniu odpowiedzi
na pytanie:
Jak to naley robi?

Metodyka dy ku praktyce wykonawczej, a
metodologia ku teorii zazwyczaj sprawnego dziaania.
Metodologia nauk technicznych

(tworzenia oprogramowania)
Wiele nauk posiada wasne metodologie lub
korzysta z dorobku innych,
W naukach technicznych czsto dokonuje si
pomiaru za pomoc miernikw z zachowaniem
waciwych warunkw otoczenia a uzyskane
tak wyniki mog by zbierane i porwnywane z
wynikami uzyskanymi przez innych badaczy
przy zachowaniu tych samych zmiennych lub
nieznacznej ich modyfikacji.
Do opracowania stosuje si tu czsto opis
matematyczny.
CYKL YCIA SYSTEMU

INFORMATYCZNEGO
Co to jest cykl ycia SI

(ang. software life cycle) ?
Rozwj oprogramowania jest zoonym procesem
realizowanym etapowo w okrelonym czasie.
W celu zapewnienia powtarzalnej jakoci realizowanego
projektu
definiuje
si
pojcie
cyklu
ycia
oprogramowania dzielc cao przedsiwzicia na
szereg tzw. faz ycia oprogramowania.
Poszczeglnym
stadiom
rozwoju
aplikacji
przyporzdkowuje si odpowiednie zestawy czynnoci,
ktrych celem jest uporzdkowanie przebiegu prac,
umoliwienie planowania i zarzdzania dostpnymi
zasobami.
Rodzaj oraz kolejno zdefiniowanych faz skadaj si
na tzw. model cyklu ycia oprogramowania.
Cykl ycia SI
Proces zoony z cigu wzajemnie spjnych etapw
pozwalajcych na pene i skuteczne stworzenie, a
nastpnie uytkowanie systemw informatycznych
Oglny cykl ycia systemu

Projektowanie
Interfejs
uytkownika
Planowanie
strategiczne
Analiza
Wymaga
Dane
Procesy
Wdraanie
E
K
S
P
L
O
A
T
A
C
J
A
Projekt
Projekt - ograniczony w czasie zesp powizanych ze
sob dziaa prowadzcych do wytworzenia
unikalnego wyrobu lub usugi.
Mimo rnic w skali i w istocie wszystkie projekty
posiadaj nastpujce elementy:
okrelony cel,
dat rozpoczcia i zakoczenia,
okrelony koszt,
absorbuj okrelone zasoby,
wykonywane s przez ludzi.
Zakres projektw
informatycznych:
tworzenia nowych systemw informatycznych;
wdroenia standardowych aplikacji;
modyfikacji standardowych systemw.
Cykl projektowy pozwala

zdefiniowa czynnoci w procesie budowy
systemu,
wprowadzi i utrzyma spjno miedzy
wieloma projektami w tej samej organizacji,
wprowadzi punkty kontrolne w zarzdzaniu
projektem na rnych etapach jego rozwoju
Udziaowcy projektu SI
Kluczowymi udziaowcami projektu s:
klient - odbiorca wyniku przedsiwzicia,
konsument - uytkownik wyniku projektu,
waciciel - organizacja realizujca projekt,
zarzdzajcy projektem- odpowiedzialny za
realizacj celu,
uczestnik - czonek zespou realizujcego projekt,
sponsor - osoba lub organizacja finansujca projekt
lub udostpniajca zasoby,
podwykonawcy.
Dziedziny zwizane z procesem

projektowania SI:
Zarzdzanie projektami;
Praca grupowa;
Procedury wyboru oprogramowania;
Metody szacowania kosztw oprogramowania;
Wspomaganie podejmowania decyzji;
Analiza systemowa i metodyki projektowania;
Komunikacja interpersonalna.
Szczegowy wykaz faz cyklu

ycia systemu informatycznego
faza
aza strategiczna,
okrelenie wymaga,
analiza modelowanie,
projektowanie,
implementacja oprogramowania,
integracja i testowanie SI,
wdroenie,
utrzymanie,
likwidacja.
Okrelenie wymaga Projektowanie Implementacja Testowanie
Faza strategiczna
Analiza
Utrzymanie
Wdroenie
Dokumentacja
Likwidacja
W cyklu ycia SI wyrnia si

fazy podstawowe:
Okrelanie wymaga - okrelane s tu cele oraz
szczegowe wymagania wobec tworzonego systemu,
Projektowanie tu powstaje szczegowy projekt SI
speniajcego ustalone wczeniej wymagania,
Implementacja/kodowanie oraz testowanie moduw projekt zostaje zaimplementowany w konkretnym rodowisku
programistycznym oraz wykonywane s testy poszczeglnych
moduw,
testowanie - nastpuje tu integracja poszczeglnych
moduw poczona z testowaniem czci i caego SI,
Konserwacja - oprogramowanie jest wykorzystywane przez
uytkownika, producent dokonuje konserwacji SI, wykonuje si
modyfikacje, zmiany i rozszerzania funkcji SI oraz usuwa
ewentualne bdy y
Fazy dodatkowe w cyklu ycia

SI
Strategiczna - wykonywana przed formalnym podjciem
decyzji o realizacji przedsiwzicia tu podejmowane s
decyzje strategiczne o podejmowanym przedsiwziciu
ustala si : zakres, koszt, czasu realizacji itp.
Analiza - budowany jest logiczny model systemu,
Dokumentacja - wytwarzana jest dokumentacja uytkownika opracowywanie dokumentacji przebiega rwnolegle z
produkcj oprogramowania faza praktycznie rozpoczyna si
ju w trakcie okrelania wymaga - sugeruje si nawet, e
podrcznik uytkownika dla przyszego systemu jest dobrym
dokumentem opisujcym wymagania - ostatnie uaktualnienia
w dokumentacji dokonywane s w fazie instalacji SI.
Instalacja - nastpuje przekazanie systemu uytkownikowi,
Likwidacja - czynnoci zwizane z wycofaniem SI.
Cykl ycia SI
Definiowanie
Proces projektowania systemu
Analiza
Projektowanie
Implementacja
Zainstalowanie, testowanie,
usuwanie bdw
Wdroenie
Szkolenie i przekazanie
systemu
systemu uytkownikowi
Utrzymanie i rozwj systemu
Re-inynieria systemu / zastpienie systemu innym /
zamknicie systemu
Cykl ycia SI -inaczej

Analiza
Projektowanie
Konstrukcja
Testowanie
Sprawdzenie osignicia
celw
Sprawdzenie zgodnoci
ze specyfikacj
WDRAANIE
Etapy cyklu ycia SI a

dokumentacja
1. Okrelenie wymaga
2. Projektowanie
3. Implementacja
4. Testowanie
5. Rozwj & pielgnacja
Dokumentacja I
Dokumentacja II
Zrozumienie problemu
MODELE CYKLU
YCIA SYSTEMU
INFORMATYCZNEGO
Rodzaje modeli cyklu ycia SI
Model kaskadowy (ang. waterfall)

Realizacja kierowana dokumentami (ang. document
driving)
Prototypowanie (ang. prototyping)
Programowanie odkrywcze (ang. exploratory
programming)
Realizacja przyrostowa (ang. incremental
development)
Monta z gotowych elementw (ang. composition of
re-usable components)
Model spiralny (ang. spiral)
Elastyczne metody wytwarzania systemw informatycznych
(ewolucyjne metody)
Model kaskadowy
Model kaskadowy
(ang. waterfall) jest jednym z
najbardziej rozpowszechnionych
modeli cyklu ycia oprogramowania.
Nazwa model kaskadowy zostaa po
raz pierwszy uyta w artykule
Winstona W. Roycea pt.:
"Managing the Development of
Large Software Systems.
Planowanie
Analiza
Projektowanie
Implementacja
Model kaskadowy jest uznawany czsto za do

przestarzay i mao elastyczny gdy:
nie mona przej do kolejnej fazy przed zakoczeniem poprzedniej
(sztywno narzucony iteracyjny proces),
powtarzanie dowolnej iteracji (fazy) czsto okazuje si kosztowne,
cisa kolejno postpowania utrudnia komunikacj z klientem.
Testowanie
Konserwacja
Programowanie odkrywcze
Sporzd
ogln
specyfikacj
Zbuduj
system
Skorzystaj z
systemu
Nie
System spenia
wymagania?
Tak
Dostarcz
system
klientowi
Problemy wynikajce podczas programowania odkrywczego (ang. exploratory

programming)) to midzy innymi:
programming
brak prawdziwej i penej specyfikacji co uniemoliwia kompletn weryfikacj systemu,
bardzo kosztowna i trudna konserwacja tak zbudowanego systemu,
niespjna i do chaotyczna struktura systemu
Model spiralny
Analiza
Definiowanie
Projektowanie
Implementacja
Model spiralny
Model spiralny zosta
zaproponowany w 1986 roku
przez Barryego Boehma w
artykule
A spiral model of software
development and
enhancement.
Zaproponowany cykl ycia
oprogramowania czy w sobie
elementy projektowania /
konstruowania systemu zgodnie
z modelem kaskadowym oraz z
elementami prototypowania.
Procedura ewolucyjna
(strukturalna)
System dzielimy na elementarne czci, a dopiero na
kocu dziaa projektowych przystpujemy do
integracji caego systemu i wykonania testw.
Jej cech charakterystyczn jest projektowanie nadne,
tzn. e cay czas jestemy nastawieni na zmieniajcy si
cel.
Poniewa wraz z upywem czasu cel, ktry zosta
okrelony wczeniej ulega zmianie, musimy przez cay
czas analizowa i kontrolowa proces projektowania. W
ten sposb staramy si zminimalizowa straty,
spowodowane wadliwym dziaaniem systemu.
Kosztem etapowej modyfikacji systemu, uzyskujemy efekt
aktualnoci systemu.
Procedura ewolucyjna
Procedura przyrostowa
(strukturalna)
Pozwala projektowa system etapami w przypadku, gdy nie
ma innych rodkw, aby projektowa od razu cay system.
Zesp projektujcy, przy dobrej organizacji pracy, jest stale,
rwnomiernie zajty realizacj projektu. Prace nad projektem
odbywaj si metod cig, bez zbdnej akcyjnoci.
Organizacj prac nad SI mona porwna do tworzenia
osiedla domw gdzie poszczeglne brygady pracuj przy
budowie jednego domu, a nastpnie przenosz si na
budow nastpnego domu. Na ich miejsce przychodzi nowa
brygada, ktra kontynuuje prac pierwszej brygady.
Klamr spinajc poszczeglne etapy projektowania s
pierwsze i ostatnie etapy (Wymagania, analiza i koncepcja,
testowanie, instalacja i eksploatacja) przeprowadza si dla
caego SI. W tych ostatnich - dba si o spjno caego SI.
Procedura przyrostowa
WAGA ETAPW
CYKLU YCIA SI
Koszty naprawy bdw a etapy

cyklu ycia SI
Ilo bdw
0.1
Okrelanie wymaga
56%
0.5
Projektowanie
26 %
Implementacja
7%
Testowanie
20
Pielgnacja
Etap
Koszty usuwania bdw

na etapie Pielgnacji
oprogramowania s
200 razy wiksze ni na
etapie Okrelania
wymaga na
Od techno- do antypo-centrycyzmu w projektowaniu SI

Klasyczne podejcie do projektowania systemw
informatycznych dla zarzdzania byo technocentryczne.
Opierao si ono na zaoeniu, e trzeba woy wiele
wysiku w tworzenie i optymalizowanie coraz
doskonalszych systemw komputerowych. Natomiast
uytkownicy systemw mieli si do nich dostosowa.
Takie podejcie byo iluzj, poniewa celem systemu nie
jest przetwarzanie danych tylko wiedza, ktra pozwoli
nam podejmowa rozmaite decyzje. Natomiast ta wiedza
rodzi si w umyle czowieka. Dlatego te czowiek jest
punktem wyjcia w projektowaniu nowoczesnych
skomputeryzowanych systemw zarzdzania.
Od techno- do antypo-centrycyzmu w projektowaniu SI

Nowe podejcie to antypo-centryzm - nie mona
doskonali systemw zarzdzania firm przy zaoeniu
,e czowiek jest dodatkiem. Komputer nie zastpuje
ludzi, ale wspomaga twrcze mylenie z czego mog si
zrodzi nowe koncepcje, nowe idee. I dopiero to
wszystko razem moe zapewni sukces biznesowy.
Przykadem tego kierunku jest podejcie spoeczne
(ang. soft approaches)
rodowisko metodyki tworzenia SI
Reguy
modelowania
Modele
Dziedzina
przedmiotowa (DP)
Cele problemy, potrzeby
informatyczne
Wyniki analiz
DP
Pojcia
abstrakcyjne
Metody i
techniki
parametry
PROCES TWORZENIA
SYSTEMU
INFORMATYCZNEGO
Fazy
kierowanie
Zesp
projektujcy
dokumentacja
Prezentacja
i eksperymentalna
eksploatacja
pakiety
Narzdzia
komputeroweg
o wspomagania
tworzenie
Zadania
wymagania
Korekty i modyfikacje
SI
Kryteria
oceny
Oglne wymagania do
metodyki tworzenia SI
metodyka powinna obj cay cykl ycia
systemu informatycznego,
metodyka powinna obejmowa rnorodne,
dostosowane do specyfiki podejcia, metody,
techniki i narzdzia komputerowe
wspomagajce proces tworzenia systemu i
analiz,
metodyka powinna uatwia porozumiewanie
si pomidzy rnymi grupami zawodowymi
tworzcymi SI,
metodyka powinna by stosunkowo atwa w
uytkowaniu, powinna mc ewoluowa i
podlega modyfikacjom
Model tworzenia systemu

informacyjnego
Realizacja systemu
Metodyka projektowania
Stosowana metodyka projektowania systemu informacyjnego zaley od wielu
czynnikw, takich jak:
infrastruktura zarzdzania,
dysponowane zasoby,
kwalifikacje kadry uytkownika i projektantw,
organizacja i specyfika jej otoczenia.
Metodyka projektowania
Podejcia do metodyki projektowania
uwzgldniajce aspekt czasu:
projektowanie diagnostyczne, w
ktrym za punkt wyjcia przyjmuje si
obecny stan organizacji, a projektant
pragnie j usprawni;
projektowanie prognostyczne, gdzie

za punkt wyjcia bierzemy nasz wizj
organizacji w przyszoci, a nie
interesuje nas stan obecny.
Podejcie
diagnostyczne
Stan obecny
Podejcie
prognostyczne
czas
Podejcie diagnostyczne
Podejcie diagnostyczne, najbardziej popularne, nazywane jest czste
podejciem tradycyjnym. W podejciu tym projektuje si system lepszy od
istniejcego.
W podejciu diagnostycznym znamy obiekt i jego niedomagania oraz
istniejce moliwoci poprawy. Naszym zadaniem jest poprawa tego stanu.
Formuujemy kryterium oceniajce oraz istniejce warunki ograniczajce.
Celem jest zaprojektowanie systemu lepszego ni obecnie funkcjonujcy.
Podejcie prognostyczne
W podejciu prognostycznym w zasadzie nie interesuje nas obecna sytuacja.
Pierwszym zadaniem jest okrelenie horyzontu czasu, a cilej, punktu w
przyszoci na jaki projektujemy system.
Przyjmujemy zasad, e nasz system powinien by przez dugi czas
nowoczesny. Oczywicie decydenci pragn, aby ich system by jak najduej
nowoczesny. Jednak, aby ten postulat zrealizowa, naley zdawa sobie
spraw z faktu, e horyzont czasu jest duszy, tym nasza wiedza o przyszych
warunkach funkcjonowania obiektu jest mniejsza. I nie jest to tylko zwizane z
naszymi pragnieniami, ale w przewaajcej mierze z tym, e projektujc
system metod prognostyczn zwiksza si ryzyko podjcia nietrafionych
decyzji.
Dlatego te decyzja przyjcia diagnostycznego czy prognostycznego
podejcia do projektowania jest decyzj strategiczn.
FAZA STRATEGICZNA
Faza strategiczna (studium

strategy phase, feasibility study
osigalnoci)
Okrelenie wymaga
Faza strategiczna
Projektowanie
Implementacja
Analiza
Testowanie
Konserwacja
Instalacja
Dokumentacja
Faza strategiczna jest wykonywana zanim podejmowana jest decyzja

o realizacji przedsiwzicia.
Nazywana take strategicznym planem rozwoju informatyzacji
(SPRI) lub studium osigalnoci.
Czynnoci w fazie strategicznej

Dokonanie serii rozmw (wywiadw) z przedstawicielami klienta
Okrelenie celw przedsiwzicia z punktu widzenia klienta
Okrelenie zakresu oraz kontekstu przedsiwzicia
Oglne okrelenie wymaga, wykonanie zgrubnej analizy i projektu systemu
Propozycja kilku moliwych rozwiza (sposobw realizacji systemu)
Oszacowanie kosztw oprogramowania
Analiza rozwiza
Prezentacja wynikw fazy strategicznej przedstawicielom klienta oraz korekta
wynikw
Okrelenie wstpnego harmonogramu przedsiwzicia oraz struktury zespou
realizatorw
Okrelenie standardw, zgodnie z ktrymi realizowane bdzie przedsiwzicie
Faza strategiczna - wsppraca z

klientem
Klient
Zleceniodawca
Przyszy uytkownik
Wykonawca
Po stronie klienta warto wyrni zleceniodawc i przyszych uytkownikw.
Stara si uwzgldni kryteria obydwu stron, ale naley pamita, e system
bdzie gwnie oceniany przez przyszych uytkownikw.
Wanym elementem fazy strategicznej jest jasne okrelenie celw
przedsiwzicia z punktu widzenia klienta. Nie zawsze s one oczywiste, co
czsto powoduje nieporozumienia pomidzy klientem i wykonawc.
Rwnie wane jest okrelenie ogranicze klienta (np. finansowych,
infrastruktury, zasobw ludzkich, czasu wdroenia, itd.)
Przykad: system
harmonogramowania zlece
Przedsibiorstwo farmaceutyczne zlecio wykonanie analizy krytycznych procesw
funkcjonowania jednego z wydziaw. Jednym z nich jest harmonogramowanie
zlece, ktre wydzia otrzymuje z dziau marketingu. Zlecenie oznacza
wyprodukowanie pewnej iloci konkretnego produktu, przy czym moliwe s
dodatkowe wymagania, np. ograniczenie terminu wykonania.
Cele przedsiwzicia z punktu widzenia klienta:

zwikszenie wydajnoci pracy wydziau poprzez szybsz i efektywniejsz
realizacj zlece,
zmniejszenie opnie w realizowaniu zlece
uwzgldnienie wszelkich ogranicze, zapewniajce praktyczn wykonalno
proponowanych harmonogramw
zapewnienie moliwoci rcznego modyfikowania harmonogramu
opracowanie harmonogramu w formie atwej do wykorzystania przez kadr
kierownicz wydziau oraz automatyzacja przygotowania zamwie dla
magazynu na pprodukty.
Zakres i kontekst przedsiwzicia

Zakres przedsiwzicia: okrelenie fragmentu procesw informacyjnych
zachodzcych w organizacji, ktre bd objte przedsiwziciem. Na tym etapie
moe nie by jasne, ktre funkcje bd wykonywane przez oprogramowanie, a
ktre przez personel, inne systemy lub standardowe wyposaenie sprztu.
Kontekst systemu: systemy, organizacje, uytkownicy zewntrzni, z ktrymi
tworzony system ma wsppracowa.
System harmonogramowania zlece
Zakresem przedsiwzicia jest funkcjonowanie komrki wydziau obejmujcego
przygotowanie harmonogramu wykonywania zlece. Nie jest okrelone, czy
harmonogramy maj by drukowane automatycznie, czy system ma tylko
dostarcza odpowiednich informacji.
Systemami zewntrznymi s: system komputerowy dziau marketingu, osoba
definiujca technologiczne moliwoci wydziau, kadra kierownicza.
Decyzje strategiczne
Wybr modelu, zgodnie z ktrym bdzie realizowane przedsiwzicie
Wybr technik stosowanych w fazach analizy i projektowania
Wybr rodowiska (rodowisk) implementacji
Wybr narzdzia CASE
Okrelenie stopnia wykorzystania gotowych komponentw
Podjcie decyzji o wsppracy z innymi producentami lub zatrudnieniu ekspertw
Ograniczenia
Maksymalne nakady, jakie mona ponie na realizacj przedsiwzicia
Dostpny personel
Dostpne narzdzia
Ograniczenia czasowe
Po prezentacji wynikw dla klienta kocowym wynikiem moe by przyjcie lub
odrzucenie oferty twrcy oprogramowania. Faza strategiczna jest nieodczn
czci cyklu produkcji oprogramowania, wobec czego nie powinna by
wykonywana na koszt i ryzyko producenta oprogramowania
Harmonogram przedsiwzicia
Ustalenie planu czasowego dla poszczeglnych faz i zada.
Nazwa zadania
Wstpne zbieranie wymaga
Budowa prototypu
Ocena prototypu
Opracowanie wymaga
Analiza
Projekt dziedziny problemu
Projekt interfejsu uytkown.
Projekt bazy danych
Diagram Gantta
Stycz
Luty
Marz
Kwie
Maj
Czer Lip
Sierp Wrze
Pad
Listo Grud
Ocena rozwiza
Czste kryteria oceny:
koszt
czas realizacji
niezawodno
moliwo ponownego uycia
przenono na inne platformy
wydajno (szybko)
W fazie strategicznej czsto

rozwaa si kilka rozwiza, z
powodw wieloci celw
przedsiwzicia (czyli kryteriw
oceny) lub niepewnoci
(niemoliwoci precyzyjnej oceny
spodziewanych rezultatw).
Rozwizanie
A
B
C
Koszt (tys. z)
120
80 175
Czas (miesice)
33
30 36
Prezentacja i porwnanie
Niezawodno (bdy/tydzie)
5
9 13
poszczeglnych rozwiza Ponowne uycie (%)
40
40 30
w postaci tabelarycznej
Przenono (%)
90
75 30
Wydajno(transakcje/sek)
0.35 0.75
1
Oszacowanie wartoci podanych w tabeli moe by trudnym problemem.
Niepewno jest czynnikiem

utrudniajcym wybr
najlepszego rozwizania.
Niepewno i ryzyko
Rozwizanie
Pesymistyczny koszt [tys z]
Optymistyczny koszt [tys z]
A
100
40
B
80
65
Optymistyczne i pesymistyczne oszacowania:
Mona wybra jedno z dwch

rozwiza, A lub B, w zalenoci od
tego, czy przyjmujemy
optymistyczny, czy te
pesymistyczny punkt widzenia.
Prawdopodobiestwo subiektywne
Rozwizanie
Prawdopodobiestwo pesymistycznego rozwizania
Prawdopodobiestwo optymistycznego rozwizania
A
0.5
0.5
B
0.2
0.8
Poprzez pomnoenie kosztw przez prawdopodobiestwa uzyskujemy spodziewany koszt:

A:
100 * 0.5 + 40 * 0.5
= 50 + 20 = 70
B:
80 * 0.2 + 65 * 0.8
= 16 + 52 = 68 : rozwizanie B jest lepsze
Ze wzgldu na subiektywno oszacowa naley jednak rozway wiele wariantw.
Przykad
Drzewa ryzyka
Firma chce przystpi do

przetargu. Przygotowanie oferty
przetargowej jest kosztowne.
Firma moe przetarg wygra lub
przegra. Zatrudnienie
dodatkowego eksperta zwiksza
szans firmy. Co robi?
Wierzchoki drzewa odpowiadaj

sytuacjom, w ktrych mog zaj
Zatrudnienie
pewne zdarzenia.
eksperta
Krawdzie oznaczaj przejcia do
Zatrudniono
Nie znaleziono
nowych sytuacji.
eksperta
eksperta
Krawdziom s przypisane
0.8
0.2
prawdopodobiestwa.
Przetarg
Przetarg
Kady scenariusz zdarze (li w
drzewie) jest zwizany z
Sukces
Poraka
Sukces
Poraka
kosztem.
0.9
0.1
0.5
0.5
Zysk
Oczekiwany zysk
+45
- 20
+55
-10
45*0.8*0.9 + (-20)*0.8*0.1 + 55*0.2*0.5 + (-10)*0.2*0.5 = 35.3
Szacowanie kosztu
oprogramowania
Szacowanie kosztw przeprowadza si dla kadego z alternatywnych rozwiza.
Na koszt oprogramowania skadaj si nastpujce gwne czynniki:
koszt sprztu bdcego czci tworzonego systemu
koszt wyjazdw i szkole
koszt zakupu narzdzi
nakad pracy
Trzy pierwsze czynniki s do atwe do oszacowania.
Oszacowanie kosztw oprogramowania jest praktycznie utosamiane z
oszacowaniem nakadu pracy.
Techniki oszacowania nakadw

pracy
Modele algorytmiczne. Wymagaj opisu przedsiwzicia przez wiele
atrybutw liczbowych i/lub opisowych. Odpowiedni algorytm lub formua
matematyczna daje wynik.
Ocena przez eksperta. Dowiadczone osoby z du precyzj potrafi
oszacowa koszt realizacji nowego systemu.
Ocena przez analogi (historyczna). Wymaga dostpu do informacji o
poprzednio realizowanych przedsiwziciach. Metoda podlega na wyszukaniu
przedsiwzicia o najbardziej zblionych charakterystykach do aktualnie
rozwaanego i znanym koszcie i nastpnie, oszacowanie ewentualnych rnic.
Wycena dla wygranej. Koszt oprogramowania jest oszacowany na podstawie
kosztu oczekiwanego przez klienta i na podstawie kosztw podawanych przez
konkurencj.
Szacowanie wstpujce. Przedsiwzicie dzieli si na mniejsze zadania,
nastpnie sumuje si koszt poszczeglnych zada.
Algorytmiczne modele
szacowania kosztw
Historycznie, podstaw oszacowania jest rozmiar systemu liczony w liniach kodu
rdowego. Metody takie s niedokadne, zawodne, sprzyjajce patologiom, np.
sztucznemu pomnaaniu iloci linii, ignorowaniu komentarzy, itp.
Obecnie stosuje si wiele miar o lepszych charakterystykach (z ktrych bd
omwione punkty funkcyjne). Miary te, jakkolwiek niedokadne i oparte na
szacunkach, s jednak konieczne. Niemoliwe jest jakiekolwiek planowania bez
oszacowania kosztw. Miary dotycz take innych cech projektu i oprogramowania,
np. czasu wykonania, jakoci, niezawodnoci, itd.
Jest bardzo istotne uwolnienie si od religijnego stosunku do miar, tj. traktowanie ich
jako obiektywnych wartoci policzonych przez komputer. Podstaw wszystkich
miar s szacunki, ktre mog by obarczone znacznym bdem, nierzadko o rzd
wielkoci. Miary naley traktowa jako latarni morsk we mgle - moe ona nas
naprowadzi na dobry kierunek, moe ostrzec przed niebezpieczestwem.
Obowizuje zasada patrzenia na ten sam problem z wielu punktw widzenia (wiele
rnych miar) i zdrowy rozsdek.
Metoda szacowania kosztw

COnstructive COst MOdel
COCOMO
COCOMO jest oparte na kilku formuach pozwalajcych oszacowa cakowity
koszt przedsiwzicia na podstawie oszacowanej liczby linii kodu. Jest to gwna
sabo tej metody, gdy:
liczba ta staje si przewidywalna dopiero wtedy, gdy koczy si faza projektowania
architektury systemu; jest to za pno;
pojcie linii kodu zaley od jzyka programowania i przyjtych konwencji;
pojcie linii kodu nie ma zastosowania do nowoczesnych technik programistycznych,
np. programowania wizyjnego.
COCOMO oferuje kilka metod okrelanych jako podstawowa, porednia i detaliczna.
Metoda podstawowa: prosta formua dla oceny osobo-miesicy oraz czasu
potrzebnego na cao projektu.
Metoda porednia: modyfikuje wyniki osignite przez metod podstawow poprzez
odpowiednie czynniki, ktre zale od aspektw zoonoci.
Metoda detaliczna: bardziej skomplikowana, ale jak si okazao, nie dostarcza
lepszych wynikw ni metoda porednia.
Function Point Analysis, FPA
Metoda punktw funkcyjnych

Metoda punktw funkcyjnych oszacowuje koszt projektu na podstawie
funkcji uytkowych, ktre system ma realizowa. Std wynika, ze metoda ta
moe by stosowana dopiero wtedy, gdy funkcje te s z grubsza znane.
Metoda jest oparta na zliczaniu iloci wej i wyj systemu, miejsc
przechowywania danych i innych kryteriw. Te dane s nastpnie mnoone przez
zadane z gry wagi i sumowane. Rezultatem jest liczba punktw funkcyjnych.
Punkty funkcyjne mog by nastpnie modyfikowane zalenie od dodatkowych
czynnikw zoonoci oprogramowania.
Istniej przeliczniki punktw funkcyjnych na liczb linii kodu, co moe by
podstaw dla metody COCOMO.
Metoda jest szeroko stosowana i posiada stosunkowo mao wad.
Niemniej, istnieje wiele innych, mniej popularnych metod, posiadajcych swoich
zwolennikw.
Metoda Delphi
Metoda Delphi zakada uycie kilku niezalenych ekspertw, ktrzy nie mog
si ze sob w tej sprawie komunikowa i naradza. Kady z nich szacuje koszty i
nakady na podstawie wasnych dowiadcze i metod. Eksperci s anonimowi.
Kady z nich uzasadnia przedstawione wyniki.
Koordynator metody zbiera wyniki od ekspertw. Jeeli znacznie si rni,
wwczas tworzy pewne sumaryczne zestawienie (np. redni) i wysya do
ekspertw dla ponownego oszacowania. Cykl jest powtarzany a do uzyskania
pewnej zgody pomidzy ekspertami.
Inne metody
Metoda analizy podziau aktywnoci (activity distribution analysis):
Projekt dzieli si na aktywnoci, ktre s znane z poprzednich projektw.
Nastpnie dla kadej z planowanych aktywno ustala si, na ile bdzie ona
bardziej (lub mniej) pracochonna od aktywnoci ju wykonanej, ktrej
koszt/nakad jest znany. Daje to szacunek dla kadej planowanej aktywnoci.
Szacunki sumuje si dla uzyskania caociowego oszacowania.
Metody oszacowania pracochonnoci testowania systemu
Metody oszacowania pracochonnoci dokumentacji
Metody oszacowania obcienia sieci
....
Podsumowanie: kluczowe
czynniki sukcesu
Szybko pracy. Szczeglnie w przypadku firm realizujcych
oprogramowanie na zamwienie, opnienia w przeprowadzeniu fazy
strategicznej mog zaprzepaci szans na wygranie przetargu lub na
nastpne zamwienie. Faza ta wymaga wic stosunkowo nieduej liczby
osb, ktre potrafi wykona prac w krtkim czasie.
Zaangaowanie kluczowych osb ze strony klienta. Brak akceptacji dla
sposobu realizacji przedsiwzicia ze strony kluczowych osb po stronie
klienta moe uniemoliwi jego przyszy sukces.
Uchwycenie (oglne) caoci systemu. Podstawowym bdem popenianym
w fazie strategicznej jest zbytnie przywizanie i koncentracja na pewnych
fragmentach systemu. Niemoliwe jest w tej sytuacji oszacowanie kosztw
wykonania caoci. atwo jest te przeoczy szczeglnie trudne fragmenty
systemu.
Podstawowe rezultaty fazy

strategicznej
Udostpniamy klientowi raport, ktry obejmuje:
definicj celw
przedsiwzicia
opis zakresu przedsiwzicia
opis systemw zewntrznych, z ktrymi system bdzie
wsppracowa
oglny opis wymaga
oglny model systemu
opis proponowanego rozwizania
oszacowanie kosztw
wstpny harmonogram prac

strategicznej cd..
Raport oceny rozwiza, zawierajcy informacj o rozwaanych
rozwizaniach oraz przyczynach wyboru jednego z nich.
Opis wymaganych zasobw - pracownicy, oprogramowanie,
sprzt, lokale, ...
Definicje standardw.
Harmonogram fazy analizy
FAZA OKRELANIA
WYMAGA DLA
SYSTEMU
INFORMATYCZNEGO
Okrelenie wymaga
Celem fazy okrelenia wymaga jest ustalenie wymaga klienta wobec tworzonego
systemu. Dokonywana jest zamiana celw klienta na konkretne wymagania
zapewniajce osignicie tych celw.
Klient rzadko wie, jakie wymagania zapewni osigniecie jego celw.
Ta faza nie jest wic prostym zbieraniem wymaga, lecz procesem, w ktrym klient
wsplnie z przedstawicielem producenta konstruuje zbir wymaga zgodnie z
postawionymi celami.
Okrelenie wymaga
Faza strategiczna
Projektowanie
Implementacja
Analiza
Testowanie
Konserwacja
Instalacja
Dokumentacja
W przypadku systemu na zamwienie analitycy maj bezporedni kontakt z

przedstawicielami klienta. Faza ta wymaga duego zaangaowania ze strony
klienta, ze strony przyszych uytkownikw systemu i ekspertw w dziedzinie.
Trudno okrelenia wymaga

Klient z reguy nie wie dokadnie w jaki sposb osign zaoone cele.
Cele klienta mog by osignite na wiele sposobw.
Due systemy s wykorzystywane przez wielu uytkownikw. Ich cele s
czsto sprzeczne. Rni uytkownicy mog posugiwa si inn terminologi
mwic o tych samych problemach.
Zleceniodawcy i uytkownicy to czsto inne osoby. Gos zleceniodawcw
moe by w tej fazie decydujcy, chocia nie zawsze potrafi oni waciwie
przewidzie potrzeby przyszych uytkownikw.
Poziomy oglnoci opisu

wymaga
Definicja wymaga, to oglny opis w jzyku naturalnym. Opis taki jest
rezultatem wstpnych rozmw z klientem.
Specyfikacja wymaga, to czciowo ustrukturalizowany zapis
wykorzystujcy zarwno jzyk naturalny, jak i proste, czciowo
przynajmniej sformalizowane notacje.
Specyfikacja oprogramowania, to formalny opis wymaga.
Formalna specyfikacja oznacza bardzo dokadne zdekomponowanie wymaga

(najlepiej w pewnym formularzu) na krtkie punkty, ktrych interpretacja nie
powinna nastrcza trudnoci lub prowadzi do niejednoznacznoci. Formalna
specyfikacja powinna stanowi podstaw dla fazy testowania.
Jako opisu wymaga

Dobry opis wymaga powinien:
By kompletny oraz niesprzeczny.
Opisywa zewntrzne zachowanie si systemu a nie sposb jego realizacji.
Obejmowa ograniczenia przy jakich musi pracowa system.
By atwy w modyfikacji.
Bra pod uwag przysze moliwe zmiany wymaga wobec systemu.
Opisywa zachowanie systemu w niepodanych lub skrajnych sytuacjach.
Wykad 5 - 27.03.2014 r.
Cd fazy okrelania wymaga
do SI
Okrelenie wymaga
Faza strategiczna
Projektowanie
Implementacja
Analiza
Testowanie
Konserwacja
Instalacja
Dokumentacja
Zalecenia dla fazy definicji

wymaga
Wymagania uytkownikw powinny by wyjaniane poprzez krytyk i
porwnania z istniejcym oprogramowaniem i prototypami.
Powinien by uzyskany stan porozumienia pomidzy projektantami i
uytkownikami dotyczcy projektowanego systemu.
Wiedza i dowiadczenia potencjalnej organizacji podejmujcej si rozwoju
systemu powinny wspomc studia nad osigalnoci systemu.
W wielu przypadkach duym wspomaganiem jest budowa prototypw.
Wymagania uytkownikw powinny by: jasne, jednoznaczne, weryfikowalne,
kompletne, dokadne, realistyczne, osigalne.
Metody rozpoznania wymaga

Wywiady i przegldy. Wywiady powinny by przygotowane (pytania) i
podzielone na odrbne zagadnienia. Podzia powinien przykrywa cao tematu i
powinny by przeprowadzone na reprezentatywnej grupie uytkownikw.
Wywiady powinny doprowadzi do szerokiej zgody i akceptacji projektu.
Studia na istniejcym oprogramowaniem. Do czsto nowe oprogramowanie
zastpuje stare. Studia powinny ustali wszystkie dobre i ze strony starego
oprogramowania.
Studia wymaga systemowych. Dotyczy sytuacji, kiedy nowy system ma by
czci wikszego systemu.
Studia osigalnoci. Okrelenie realistycznych celw systemu i metod ich
osignicia.
Prototypowanie. Zbudowanie prototypu systemu dziaajcego w zmniejszonej
skali, z uproszczonymi interfejsami.
Rodzaje wymaga do SI
Wymagania
funkcjonalne
Wymagania
niefunkcjonalne
Wymagania funkcjonalne
Opisuj funkcje (czynnoci, operacje) wykonywane przez system.
Funkcje te mog by rwnie wykonywane przy uyciu systemw zewntrznych.
Mog by wyspecyfikowane w jzyku naturalnym lub w pewnej notacji.
Jzyk naturalny jest najczciej stosowanym sposobem opisu wymaga.
Ma on jednak wady:
Niejednoznaczno jzyka naturalnego, ktra utrudnia precyzyjny opis
wymaga. Moe take prowadzi do niejednoznacznoci w interpretacji
tego samego tekstu przez rne osoby.
Elastyczno jzyka naturalnego, ktra pozwala wyrazi te same treci
na wiele sposobw. Utrudnia to wykrycie powizanych wymaga i moe
prowadzi do trudnoci w wykryciu sprzecznoci.
Uwaa si, e dobrym sposobem specyfikacji wymaga funkcjonalnych s
diagramy przypadkw uycia.
Inne metody specyfikacji

wymaga
Formalizm matematyczny. Stosuje si rzadko, dla dobrze zdefiniowanych
problemw raczej o maej skali.
Jzyk naturalny strukturalny. Jzyk naturalny z ograniczonym sownictwem
i skadni. Poszczeglne tematy i zagadnienia wyspecyfikowane w punktach i
podpunktach.
Tablice, formularze. Wyspecyfikowanie wymaga w postaci (zwykle
dwuwymiarowych) tablic, kojarzcych rne aspekty (np. tablica ustalajca
zaleno pomidzy typem uytkownika i rodzajem usugi).
Diagramy blokowe: tradycyjna forma graficzna pokazujca wymagany cykl
przetwarzania.
Diagramy kontekstowe: ukazuj system w postaci jednego bloku oraz jego
powizania z otoczeniem, wejciem i wyjciem.
Formularz wymaga funkcjonalnych

W formularzach zapis jest podzielony na konkretne pola, co pozwala na atwe
stwierdzenie kompletnoci opisu oraz na jednoznaczn interpretacj.
Przykad jednej zapenionej tabeli wg przyjtego formularza:
Nazwa funkcji
Edycja dochodw pracownika
Opis
Funkcja pozwala edytowa czne dochody podatnika uzyskane w danym roku.
Dane
wejciowe
Informacje o dochodach pracownikw uzyskane uzyskanych z rnych rde:

kwoty przychodw, koszty uzyskania przychodw oraz zapaconych zaliczek na
poczet podatku dochodowego. Informacje o dokumentach opisujcych dochody z
poszczeglnych rde.
Dokumenty oraz informacje dostarczone przez podatnika.
rdo danych
wejciowych
Wynik
Warunek
wstpny
Warunek
kocowy
Efekty uboczne
Powd
Dane wpisywane przez pracownika firmy podatkowej.

Kwota dochodu = kwota przychodu - kwota kosztw (zarwno dla konkretnych
dochodw, jak i dla cznych dochodw podatnika). czne kwoty przychodw,
kosztw uzyskania dochodw oraz zapaconych zaliczek s sumami tych kwot dla
dochodw z poszczeglnych rde.
Jak wyej.
Uaktualnienie podstawy opodatkowania.
Funkcja pomaga przypieszy obsug klientw oraz zmniejszy ryzyko popenienia
bdw.
Porzdkowanie wymaga
Hierarchia wymaga funkcjonalnych:
Z reguy funkcje mona rozbi na podfunkcje.
Format tekstowy:
Funkcja nadrzdna f1
funkcja f1.1
funkcja f1.2
funkcja f1.3
funkcja f1.3.1
funkcja f1.3.2
funkcja f1.3.3
funkcja f1.4
funkcja f1.4.1
funkcja f1.4.2
funkcja f1.4.3
Notacje graficzne:
funkcja f1
funkcja f1.1
funkcja f1
funkcja f1.2
funkcja f1.3
funkcja f1.1
funkcja f1.2
funkcja f1.3.1
funkcja f1.3
funkcja f1.3.2
funkcja f1.3.1
funkcja f1.3.2
funkcja f1.3.3
funkcja f1.4
funkcja f1.4.1
funkcja f1.4.2
funkcja f1.4.3
funkcja f1.3.3
Na kadym poziomie ten sam

poziom szczegowoci.
Kolejno funkcji nie ma znaczenia.
Niektre funkcje mog by wykonywane
wielokrotnie.
Wyszczeglnia tylko funkcje widoczne
dla uytkownikw.
Przykad: Funkcje systemu

harmonogramowania zlece
Zarzdzanie zleceniami (oglna funkcja systemu)
Przygotowanie zamwie na pprodukty

Ewidencja zlece
Przygotowanie kart zada
Edycja technologicznego opisu wydziau
Harmonogramowanie zlece
Edycja opisu maszyn
Ustalanie harmonogramu
Wczytywanie
informacji o zleceniach
Edycja opisu operacji
Edycja harmonogramu
Wywietlanie
Edycja opisu wyrobw
Graficzna prezentacja
harmonogramu
Wydruk
Sprawdzanie
kompletnoci opisu
Wydruk harmonogramu
Wydruk informacji
technologicznych
Wymagania niefunkcjonalne
Opisuj ograniczenia, przy ktrych system ma realizowa swoje funkcje.
Wymagania dotyczce produktu.
Np. musi istnie moliwo operowania z systemem wycznie za pomoc
klawiatury.
Wymagania dotyczce procesu.
Np. proces realizacji harmonogramowania zlece musi by zgodny ze
standardem opisanym w dokumencie XXXA/96.
Wymagania zewntrzne.
Np. system harmonogramowania musi wsppracowa z baz danych systemu
komputerowego dziau marketingu opisan w dokumencie YYYB/95.
Niedopuszczalne s jakiekolwiek zmiany w strukturze tej bazy.
Weryfikacja wymaga
niefunkcjonalnych
Wymagania niefunkcjonalne powinny by weryfikowalne, tj. powinna istnie
moliwo sprawdzenia czy system je rzeczywicie spenia. Np. wymaganie system
ma by atwy w obsudze nie jest weryfikowalne.
Cecha
Wydajno
Rozmiar
atwo
uytkowania
Niezawodno
Przenaszalno
Weryfikowalne miary
Liczba transakcji obsuonych w cigu sekundy
Czas odpowiedzi
Szybko odwieania ekranu
Wymagana pami RAM
Wymagana pami dyskowa
Czas niezbdny dla przeszkolenia uytkownikw
Liczba stron dokumentacji
Prawdopodobiestwo bdu podczas realizacji transakcji
redni czas pomidzy bdnymi wykonaniami
Dostpno (procent czasu w ktrym system jest dostpny)
Czas restartu po awarii systemu
Prawdopodobiestwo zniszczenia danych w przypadku awarii
Procent kodu zalenego od platformy docelowej
Liczba platform docelowych
Koszt przeniesienia na now platform
Istotne czynniki definiowania

wymaga niefunkcjonalnych
Moliwoci systemu: Zestaw funkcji, ktre ma wykonywa system,
uporzdkowany hierarchicznie.
Objto: Ilu uytkownikw bdzie pracowa jednoczenie? Ile terminali ma
by podczone do systemu? Ile czujnikw bdzie kontrolowanych
jednoczenie? Ile danych bdzie przechowywane?
Szybko: Jak dugo moe trwa operacja lub sekwencja operacji? Liczba
operacji na jednostk czasu. redni czas niezbdny dla jednej operacji.
Dokadno: Okrelenie stopnia precyzji pomiarw lub przetwarzania.
Okrelenie wymaganej dokadnoci wynikw. Zastpienie wynikw
ilociowych jakociowymi lub odwrotnie.
Ograniczenia: ograniczenia na interfejsy, jako, skal czasow, sprzt,
oprogramowanie, skalowalno, itd.

Interfejsy komunikacyjne: sie, protokoy, wydajno sieci, poziom abstrakcji
protokow komunikacyjnych, itd.
Interfejsy sprztowe: specyfikacja wszystkich elementw sprztowych, ktre
bd skaday si na system, fizyczne ograniczenia (rozmiar, waga), wydajno
(szybko, RAM, dysk, inne pamici), wymagania co do powierzchni
lokalowych, wilgotnoci, temperatury i cinienia, itd.
Interfejsy oprogramowania: Okrelenie zgodnoci z innym oprogramowaniem,
okrelenie systemw operacyjnych, jzykw programowania, kompilatorw,
edytorw, systemw zarzdzania baz danych, itd.
Interakcja czowiek-maszyna: Wszystkie aspekty interfejsu uytkownika,
rodzaj jzyka interakcji, rodzaj sprztu (monitor, mysz, klawiatura), okrelenie
formatw (ukadu raportw i ich zawartoci), okrelenie komunikatw dla
uytkownikw (jzyk, forma), pomocy, komunikatw o bdach, itd.

Adaptowalno: Okrelenie w jaki sposb bdzie organizowana reakcja na
zmiany wymaga: dodanie nowej komendy, dodanie nowego okna interakcji, itd.
Bezpieczestwo: zaoenia co do poufnoci, prywatnoci, integralnoci,
odpornoci na hakerw, wirusy, wandalizm, sabota, itd.
Odporno na awarie: konsekwencje bdw w oprogramowaniu, przerwy w
zasilaniu, kopii zabezpieczajcych, czstotliwoci skadowania, dziennika zmian,
itd.
Standardy: Okrelenie dokumentw standardyzacyjnych, ktre maj
zastosowanie do systemu: formaty plikw, normy czcionek, polonizacja,
standardy procesw i produktw, itd.
Zasoby: Okrelenie ogranicze finansowych, ludzkich i materiaowych.
Skala czasowa: ograniczenia na czas wykonania systemu, czas szkolenia,
wdraania, itd.
Dokument wymaga
Wymagania powinny by zebrane w dokumencie - opisie wymaga.
Dokument ten powinien by podstaw do szczegowego kontraktu midzy
klientem a producentem oprogramowania.
Powinien take pozwala na weryfikacj stwierdzajc, czy wykonany system
rzeczywicie spenia postawione wymagania.
Powinien to by dokument zrozumiay dla obydwu stron.
Czsto producenci nie s zainteresowaniu w precyzyjnym formuowaniu
wymaga, ktre pozwolioby na rzeczywist weryfikacj powstaego systemu.
Zasady tworzenia dokumentu

wymaga
Wymagania funkcjonalne powinny by oddzielone od wymaga
niefunkcjonalnych.
Naley rozdziela opisy poszczeglnych wymaga (w punktach lub akapitach).
Dla kadego wymagania powinien by podany powd jego wprowadzenia: cele
przedsiwzicia, ktrych osignicie jest uwarunkowane danym wymaganiem.
Konieczne jest prowadzenie sownika

Opis wymaga moe zawiera terminy niezrozumiae dla jednej ze stron. Mog to by
terminy informatyczne (niezrozumiae dla klienta) lub terminy dotyczce dziedziny
zastosowa (niezrozumiae dla przedstawicieli producenta).
Wszystkie specyficzne terminy powinny by umieszczone w sowniku, wraz z wyjanieniem.
Sownik powinien precyzowa terminy niejednoznaczne i okrela ich znaczenie w
kontekcie tego dokument (by moe nieco wsze).
Jako dokumentu wymaga

Styl
Jasno: jednoznaczne sformuowania, zrozumiay dla uytkownikw i
projektantw. Strukturalna organizacja dokumentu.
Spjno: brak konfliktw w wymaganiach.
Modyfikowalno: wszystkie wymagania s sformuowane w jasnych punktach,
ktre mog by wyizolowane z kontekstu i zastpione przez inne.
Ewolucja
Moliwo dodawania nowych wymaga, moliwo ich modyfikacji
Odpowiedzialno
Okrelenie kto jest odpowiedzialny za sformuowanie danego wymagania, istotne
w przypadku modyfikacji.
Medium
Dokument papierowy lub elektroniczny.
Staranne kontrolowanie wersji dokumentu.
Zawarto dokumentu
Informacje
organizacyjne
Przykadowy
spis
treci
Streszczenie
Spis treci
Status dokumentu (roboczy, 1-sza faza, zatwierdzony, ...)
Zmiany w stosunku do wersji poprzedniej
1. Wstp
1.1. Cel
1.2. Zakres
1.3. Definicje, akronimy i skrty
1.4. Referencje, odsyacze do innych dokumentw
1.5. Krtki przegld
2. Oglny opis
2.1. Walory uytkowe i przydatno projektowanego systemu
2.2. Oglne moliwoci projektowanego systemu
2.3. Oglne ograniczenia
2.4. Charakterystyka uytkownikw
2.5. rodowisko operacyjne
2.6. Zaoenia i zalenoci
3. Specyficzne wymagania
3.1. Wymagania co do moliwoci systemu
3.2. Przyjte lub narzucone ograniczenia.
Kluczowe czynniki sukcesu

Zaangaowanie waciwych osb ze strony klienta
Pene rozpoznanie wymaga, wykrycie przypadkw i dziedzin szczeglnych i
nietypowych. Bd popeniany w tej fazie polega na koncentrowaniu si na
sytuacjach typowych.
Sprawdzenie kompletnoci i spjnoci wymaga. Przed przystpieniem do
dalszych prac, wymagania powinny by przejrzane pod ktem ich kompletnoci
i spjnoci.
Okrelenie wymaga niefunkcjonalnych w sposb umoliwiajcy ich
weryfikacj.
FAZA ANALIZY
Analiza
Okrelenie wymaga
Projektowanie
Faza
analizy
Faza strategiczna
Implementacja
Analiza
Testowanie
Konserwacja
Instalacja
Dokumentacja
Celem fazy okrelenia wymaga jest udzielenie odpowiedzi na pytanie:

Co i przy jakich ograniczeniach system ma robi?
Wynikiem tej fazy jest zbir wymaga na system.
W odrnieniu, celem fazy projektowania jest udzielenie odpowiedzi na pytanie:
Jak system ma by zaimplementowany?
Wynikiem jest projekt oprogramowania, czyli opis sposobu implementacji.
Celem fazy analizy jest udzielenie odpowiedzi na pytanie:
Jak system ma dziaa?
Wynikiem jest logiczny model systemu, opisujcy sposb realizacji przez system
postawionych wymaga, lecz abstrahujcych od szczegw implementacyjnych.
Analiza
Analiza wcza nastpujce czynnoci:
Rozpoznanie, wyjanianie, modelowanie, specyfikowanie i dokumentowanie
rzeczywistoci lub problemu bdcego przedmiotem projektu;
Ustalenie kontekstu projektu;
Ustalenie wymaga uytkownikw;
Ustalenie wymaga organizacyjnych
Inne ustalenia, np. dotyczce preferencji sprztowych, preferencji w zakresie
oprogramowania, ogranicze finansowych, ogranicze czasowych, itd.
Analiza nie zajmuje si zmian rzeczywistoci poprzez wprowadzenie tam
nowych elementw np. w postaci systemu komputerowego.
Jej celem jest dokadne rozpoznanie wszystkich tych aspektw rzeczywistoci,
ktre mogyby mie wpyw na posta, organizacj lub wynik projektu.
Model analityczny
Z reguy wykracza poza zakres odpowiedzialnoci systemu. Przyczyny:
Ujcie w modelu pewnych elementw dziedziny problemu nie bdcych czci systemu
czyni model bardziej zrozumiaym. Przykadem jest ujcie w modelu systemw
zewntrznych, z ktrymi system ma wsppracowa.
Na etapie modelowania moe nie by jasne, ktre elementy modelu bd realizowane
przez oprogramowanie, a ktre w sposb sprztowy lub rcznie.
Dostpne rodki mog nie pozwoli na
realizacj systemu w caoci.
Celem analizy moe by wykrycie tych
fragmentw dziedziny problemu, ktrych
wspomaganie za pomoc oprogramowania
bdzie szczeglnie przydatne.
Dziedzina problemu
Model analityczny
Zakres
odpowiedzialnoci
systemu
Notacje w fazie analizie

Rodzaje
notacji
Jzyk naturalny
Notacje graficzne
Specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny
Szczeglne znaczenie maja notacje graficzne. Inynieria oprogramowania

wzoruje si na innych dziedzinach techniki, takich jak elektronika i mechanika.
Zalety notacji graficznych potwierdzaj badania psychologiczne.
Funkcje notacji
Narzdzie pracy analityka i projektanta, zapis i analiza pomysw
Wsppraca z uytkownikiem
Komunikacja z innymi czonkami zespou
Podstawa implementacji oprogramowania
Zapis dokumentacji technicznej
Notacje powinny by przejrzyste, proste, precyzyjne, atwo zrozumiae,
umoliwiajce modelowanie zoonych zalenoci.
Metodyki strukturalne i
obiektowe
Metodyki strukturalne - metody tradycyjne rozwijane od lat 60-tych.
cz statyczny opis danych oraz statyczny opis procesw. Analiza
strukturalna rozpoczyna si od budowy dwch rnych modeli
systemu: modelu danych oraz modelu funkcji. Te dwa modele s
integrowane. Wynikiem jest model przepywu danych. Wad
podejcia s trudnoci w zintegrowaniu modeli.
Metodyki obiektowe - rozwijane od lat 80-tych, oparte na
wyrnianiu obiektw cznie z operacjami. Ostatnio coraz bardziej
popularne.
Metodyki strukturalne
DIAGRAMY ZWIZKU ENCJI - ERD
DIAGRAMY PRZEPYWU DANYCH DFD
DIAGRAMY STANW- STD
Diagramy zwizkw encji

(ang. entity relationship diagram)
E/R lub ERD diagramy
To metoda graficzna modelowania

schematu logicznego bazy danych,
diagramy ERD skadaj si z trzech
gwnych
elementw (zbioru
encji, atrybutw i zwizkw)
Model (diagramy) E/R

Model zaproponowany w publikacji P.P.Chen: The Entityrelationship Data Model: toward a unified view of data, ACM
Transactions on Database Systes, Vol. 1, 1976
Jest to model danych dla poziomu
konceptualnego, okrelony jako:
Model jednostka-zwiazek
Model zwizku encji
Model obiektowo-zwizkowy
Entities and relationspips are a

natural way to organize physical
things as well as information (Peter
Chen)
189
Model zwizku encji

Podstaw spostrzegania wiata s encje (obiekty)
i zwizki zachodzce midzy tymi encjami
(obiektami).
Encje (ang. entity) s wystpieniami obiektw,
ktre istniej.
Z kad encj zwizany jest zbir atrybutw
opisujcych te encje.
Midzy encjami zachodz pewne zwizki np.: encje
klient oraz konto s w zwizku posiada
poniewa klient banku posiada konto bankowe.
Encje i ich zwizki zwyko si opisywa przy
pomocy diagramw ERD (ang. Entity Relationship
Diagram)
190
Definicje skadowych
diagramu ERD (lub ER lub E/R)
Zbir encja (entity sets) analogia klasy,
encje jako elementy zbioru encji s
odpowiednikami obiektw, bdcych
instancjami klasy inaczej rzeczowniki
odwzorowujce obiekty modelowanego
wiata rzeczywistego
Atrybut jest to taki element, ktrego
warto charakteryzuje wasno encji
Zwizek opisuje poczenie midzy
dwoma lub wiksz liczb zbiorw encji
191
Encje
192
Przykady poj:
Zbiorami encji s: studenci, wykadowcy,
przedmioty_kursy, oceny_za_kurs, filmy, studia,
wypoyczenia, czytelnicy, ksiki, itp.,
Encja student opisana jest atrybutami:
nr_index, nazwisko, imie1, imiona, rok,
status, adres_s, adres_k, szkola, itp..
Midzy zbiorem encji wykadowcy a zbiorem
encji przedmioty_kursy zachodzi zwizek
prowadzi_kurs lub zwizek
prowadzony_przez
193
Diagramy zwizkw encji ER, E/R

lub ERD
nazwisk
o
Nr rachunku
adres
klient
saldo
1..n
posiad
a
konto
194
Diagramy zwizkw encji przykad
195
Diagramy zwizkw encji (inna

forma)
196

forma)
Przykadowy model ER z encjami i liczebnociami w

diagramie ER.
a) relacja jeden do jeden
b)relacja jeden do wiele
c)relacja wiele do wiele
197
Zwizki pomidzy encjami
Tabela A
Tabela B
dla kadego wiersza w tabeli A musi istnie dokadnie

jeden wiersz w tabeli B
dla kadego wiersza w tabeli B moe istnie zero, jeden lub
wiele wierszy w tabeli A
198

forma)
PK klucz gwny
FKx klucz obcy
Diagram ERD. Dane pracownikw i

klientw
199
Diagramy zwizkw encji cd..
200
Etapy budowy diagramw zwizku

encji
Na
budow modelu ER
nastpujcych krokw:
skada
si
szereg
identyfikacji encji,
identyfikacji relacji pomidzy encjami,
identyfikacji atrybutw encji, ustalenia kluczy
gwnych.
201
Diagramy przepywu danych

(ang. DATA FLOW DIAGRAMS DFD)
Pokazuj przepyw danych midzy wiatem zewntrznym a
modelowanym systemem, oraz przepyw danych midzy procesami w
systemie. Diagramy te s na tyle proste, e mog by zrozumiae dla osb
bez wyksztacenia informatycznego. Modelowanie przepywu danych
pomaga odpowiedzie na pytania:
Jakie funkcje powinien realizowa system?
Jakie s zalenoci midzy nimi?
Jakich transformacji powinien dokonywa system?
Jakie dane s przeksztacane na jakie wyniki?
Jakiego rodzaju prac wykonuje system?
Skd bierze informacj potrzebn do pracy?
Gdzie dostarcza otrzymane wyniki?
SYMBOLE DIAGRAMW w DFD
Symbole w diagramach DFD
Obiekt zewntrzny
(external entity)
Obiekty zewntrzne (terminatory, encje

zewn., external entities) - rda lub miejsca
przeznaczenia informacji, zewntrzne w
stosunku do systemu; reprezentuj
zewntrzne w stosunku do analizowanego
systemu rda powstania i miejsca
przeznaczenia informacji (te, ktre
dostarczaj i odbieraj dane); KLIENT,
DOSTAWCA, BANK i inne prostokty.
Proces
Procesy (funkcje, proceses) - czyli

transformacje danych; definiuj sposb
wykonywania jednej lub wicej funkcji
(program, procedura, algorytm, operacja
rczna czy zautomatyzowana (cakowicie
lub czciowo) - wszystkie czynnoci
wykonywane na danych) - okrgi, owale.
Zbir danych
(data store)
Zbiory danych (magazyny, skadnice,

data stores) - miejsca, gdzie dane s
przechowywane midzy procesami, ktre
na nich operuj; reprezentuj miejsca
przechowywania danych midzy
procesami (dostpne s tylko z
procesw). Zaistnienie skadnicy w DFD
ma sens wtedy, kiedy przechowywane
tam dane su realizacji co najmniej
dwch procesw; wszelkiego rodzaju
KARTOTEKI - dwie poziomy linie.

Przepyw danych
(data flow)
Przepywy danych (strumienie, data

flows) - przedstawiaj obieg danych w
systemie; powizania pomidzy procesami
a innymi elementami DFD - strzaki
skierowane (opisane!).
Przykadowy diagram DFD
Zamwienie wyrobu
Klient
Potwierdzenie
zamwienia wyrobu
Sprawd
list
wyrobw i
potwierd
zamwienie
Lista wyrobw
oznaczenia
Obiekt
zewntrzny
proces
Zbiorniki danych
Podzia DFD ze wzgldu na

stopie szczegowoci
Kontekstowe,
Zerowe (systemowe),
Szczegowe (procesw elementarnych).
1. Diagramy kontekstowe
Najmniejszy stopie szczegowoci - pokazuje powizania

systemu z otoczeniem tj.:
zakres i granice systemu;
rda i odbiorcy informacji;
gwne wejcia i wyjcia systemu (tzn. informacje pynce
midzy wiatem zewn. a systemem).

stopie szczegowoci
2. Diagramy zerowe (systemowe)
Przedstawiaj ogln struktur systemu, obrazuj:
gwne procesy systemu,
obiekty zewntrzne,
magazyny danych,
przepywy.

stopie szczegowoci
3. Diagramy szczegowe
Dokadny obraz procesw i podsystemw - dalsze
uszczegowienie.
W trakcie dekompozycji diagramw obowizuje zasada, i tylko
przepywy danych, ktre pojawiy si na poziomie zerowym mog
wystpi na niszych poziomach hierarchii.
Przeznaczenie diagramw DFD
Przeznaczenie diagramw:
Diagramy kontekstowe i systemowe - dla projektantw, programistw i

uytkownikw systemu.
Diagramy szczegowe - dla projektantw i programistw.
Zasady tworzenia diagramw

DFD
Uporzdkowanie diagramw w hierarchi: kontekstowe, zerowe,
szczegowe,
Uchwycenie gwnych procesw i uszczegowienie jest bardziej
odpowiednie ni uoglnianie procesw elementarnych,
Przypisanie jednoznacznych nazw dla procesw, obiektw i
magazynw,
Przestrzeganie, eby adne dane niewykorzystywane przez proces nie
wpyway do niego,
Przestrzeganie, aby kady proces mia wejcie i wyjcie,
Zapewnienie, aby kady przepyw mia pocztek i koczy si na
procesie,

DFD
Przestrzeganie, aby wszystkie dane wprowadzane lub
wyprowadzane z obiektw zewntrznych podlegay
przetwarzaniu w procesach i nie dopuszcza przepyww midzy
skadnicami a obiektami zewntrznymi,
Konsekwentne uywanie symboli,
Oznaczenie w odpowiedni sposb powtarzajcych si elementw,
Unikanie nadmiernie zoonych DFD (max 9 procesw na
jednym DFD),
Weryfikowanie diagramw,
Opisanie kadego elementu w sowniku danych (data
dictionary).
Przykadowy diagram kontekstowy dla systemu obsugi hurtowni

1.
- oferta dostawcy;
2.
- faktura za dostarczony
towar;
3.
- zamwienie na towar
wysane do dostawcy;
4.
- dane dostawcy;
5.
- oferta dla odbiorcy;
6.
- faktura za zakupiony towar;
7.
- dane odbiorcy;
8.
- zamwienie na towar;
9.
- informacja o patnociach;
10.
- stawki VAT;
11.
- rejestr wystawionych faktur;
12.
- rejestr otrzymanych faktur;
13.
- wytyczne i zarzdzenia;
14.
- analizy i zestawienia.
DFD-1 dla systemu obsugi

hurtowni
1.
- oferta dostawcy;
2.
- faktura za dostarczony towar;
3.
- zamwienie na towar wysane do dostawcy;
4.
- dane dostawcy;
5.
- oferta dla odbiorcy;
6.
- faktura za zakupiony towar;
7.
- dane odbiorcy;
8.
- zamwienie na towar;
9.
- informacja o patnociach;
10.
- stawki VAT;
11.
- rejestr wystawionych faktur;
12.
- rejestr otrzymanych faktur;
13.
- wytyczne i zarzdzenia;
14.
- analizy i zestawienia statystyczne.
15.
- zapis danych o towarach z oferty,
16.
- dane o towarach do dokumentw;
17.
- dane o towarach do faktur;
18.
- zapis danych o odbiorcy;
19.
- zapis danych o dostawcy;
20.
- dane o firmach do zestawie,
21.
- zapis faktury otrzymanej,
22.
- dane o fakturach do rejestru,
23.
- zapis faktury wytworzonej.
Proces projektowania
strukturalnego
WYKAD 6 - 03.04.2014 R.
Obiekty, zbiory obiektw

W wielu przypadkach przy definicji klasy naley dokadnie ustali, z jakiego
rodzaju abstrakcj obiektu mamy do czynienia.
Naley zwrci uwag na nastpujce aspekty:
czy mamy do czynienia z konkretnym obiektem w danej chwili czasowej?
czy mamy do czynienia z konkretnym obiektem w pewnym odcinku czasu?
czy mamy do czynienia z opisem tego obiektu (dokument, metadane)?
czy mamy do czynienia z pewnym zbiorem konkretnych obiektw?
Np. klasa samochd. Moe chodzi o:
egzemplarz samochodu wyprodukowany przez pewn fabryk
model samochodu produkowany przez fabryk
pozycj w katalogu samochodw opisujcy wasnoci modelu
histori stanw pewnego konkretnego samochodu
Podobnie z klas gazeta. Moe chodzi o:
konkretny egzemplarz gazety kupiony przez czytelnika
konkretne wydanie gazety (niezalene od iloci egzemplarzy)
tytu i wydawnictwo, niezalene od egzemplarzy i wyda
parti egzemplarzy danej gazety dostarczan codziennie do kiosku
Obiekty
Obiektem jest rzecz lub pojcie obserwowane w wiecie rzeczywistym
ktrego dotyczy SI. Obiekt jest odrnialny od innych obiektw, ma dobrze
okrelone granice i nazw.
Obiektem moe by take pewien zamknity fragment oprogramowania
(dana, procedura, modu, dokument, okienko dialogu,...), ktrym mona
operowa jako zwart bry (wyszukiwa, wiza, kopiowa, blokowa,
usuwa, indeksowa, ...).
Obiekt posiada swoj tosamo, ktra wyrnia go spord innych
obiektw. Tosamo obiektu jest niezalena od wartoci jakichkolwiek jego
atrybutw i od jego lokacji w wiecie rzeczywistym lub w przestrzeni
adresowej komputera.
Obiekt posiada stan, ktry moe zmienia si w czasie (bez zmiany
tosamoci obiektu).
Obiekty
Obiekt moe by zoony, tj. moe skada si z mniejszych obiektw.
Obiekt zoony odnoszcy si do modelowanej rzeczywistoci zawiera w sobie
wszystkie cechy modelowanego obiektu.
Obiekt moe by powizany z innymi obiektami zwizkami skojarzeniowymi.
Obiekt ma przypisane zachowanie, tj. zestaw operacji ktre wolno do niego

stosowa. Implementacja operacji jest zwana metod.
Obiekt ma przypisany typ, tj. wyraenie jzykowe, ktre ogranicza budow

obiektu, ustala operacje, ktre wolno wykona na obiekcie, oraz ogranicza
kontekst, w ktrym dany obiekt moze by uyty w programie.
Przykad obiektu
Wypa
Wpa
Sprawd
stan
KONTO
Numer 123-4321
Porwnaj
podpis
Waciciel Jan Kowalski

Upowaniony Ewa Kowalska
Nalicz
procent
SaldoZ 34567
....
Upowanij
Zlikwiduj
konto
Zmie
upowanienie
Obiekt zoony
Obiekt moe skada si z pewnej liczby komponentw (atrybutw), ktre take

mog by zoone.
Komponenty obiektu mog by traktowane jako obiekty (pod-obiekty) lub
mog by uwaane za kategori rn od obiektw.
Nie powinno istnie ograniczenie rozmiaru obiektu, liczby komponentw
skadajcych si na obiekt lub liczby poziomw hierarchii komponentw.
Obiekt zoony reprezentujcy pewien byt wiata rzeczywistego powinien
zawiera wewntrz siebie wszelkie informacje, ktre odnosz si do tego bytu.
Ustalenia, ktre informacje odnosz si do danego obiektu, a ktre do innego,
zale od modelu pojciowego projektanta lub programisty i nie powinny
podlega ograniczeniom ze strony bazy realizacyjnej.
Obiekty zoone
(kompozytowe)
Pracownicy
Pracownik
Zatrudnienia
Nazwisko
Zatrudnienie
Dzieci
Dziecko Dziecko
Pracownik
..
.
Stanowisko
.....
Zatrudnienie
Dzieci
Dziecko Dziecko
Zatrudnienie
Zatrudnienia
Nazwisko
..
.
Stanowisko
.....
Zatrudnienie
.....
Powizania pomidzy obiektami

Na poziomie realizacyjnym powizania pomidzy obiektami mona sobie wyobrazi
jako wskaniki prowadzce od obiektu do obiektu.
PRACOWNIK
Nazwisko Nowak
Zarobek 1500
PracujeW
PRACOWNIK
Nazwisko Kowal
Zarobek 2500
PracujeW
PRACOWNIK
Nazwisko Babel
Zarobek 2000
PracujeW
Diagram klas:
PRACOWNIK
Nazwisko
Zarobek
0..* PracujeW
Prezes
Zatrudnia
NrFirmy 102030
Zatrudnia
Nazwa Syntex
Zatrudnia
FIRMA
Prezes 0..1
Zatrudnia
FIRMA
NrFirmy
Nazwa
Na poziomie pojciowym powizania nie maj charakteru wskanikw, lecz pewnych

abstrakcyjnych nitek czcych obiekty.
Asocjacje: abstrakcyjne oznaczenia powiaza na diagramach klas.
Powizania jako nitki czce

obiekty
Sprzedajcy
OSOBA
Bober
OSOBA
Kowalska
Porednik
Kupujcy
Transakcja
Diagram klas:
Transakcja
Sprzedajcy OSOBA Kupujcy
Sprzedajcy
Porednik
OSOBA
Nowak
Kupujcy
OSOBA
Wilczek
Nazwisko
Porednik
Porednik
Transakcja
Transakcja
Kupujcy
OSOBA
Macig
Sprzedajcy
OSOBA
Bielicka
Atrybuty powiza
OSOBA
Bober
Sprzedajcy
Diagram klas:
OSOBA
Kowalska
Kupujcy
Porednik
Nazwisko
Transakcja
Dom
1992.11.05
300000
Transakcja
Plac
1995.08.16
40000
Porednik
Porednik
OSOBA
Nowak
Kupujcy
Sprzedajcy
OSOBA
Wilczek
Transakcja
Porednik
Transakcja
Samochd
1998.05.15
20000
Kupujcy
OSOBA
Macig
Sprzedajcy
OSOBA
Bielicka
DaneTransakcji
PrzedmiotTransakcji
DataTransakcji
WartoTransakcji
Modelowanie powiza jako

obiektw
OSOBA
Bober
Sprzedajcy
OSOBA
Kowalska
Kupujcy
Porednik
TRANSAKCJA
Plac
1995.08.16
40000
Porednik
OSOBA
Nowak
Kupujcy
Sprzedajcy
Porednik
OSOBA
Macig

Nazwisko
OSOBA
Wilczek
Porednik
0..*
Transakcja
PrzedmiotTransakcji
DataTransakcji
0..* WartoTransakcji
0..*
TRANSAKCJA
Samochd
1998.05.15
20000
Kupujcy
Diagram klas:
TRANSAKCJA
Dom
1992.11.05
300000
Sprzedajcy
OSOBA
Bielicka
Liczno asocjacji
A
B: min = 1, max = 1
B: min = 1, max = n
B: min = 0, max = 1
A: min = 1, max = n
A: min = 0, max = n
A: min = 0, max = n
A
Oznaczenia
licznoci na
diagramie klas:
A
1..*
A
0..*
0..*
1..*
0..1
Komunikaty
Komunikat jest wyraeniem jzykowym skierowanym do obiektu. Nazwa uyta w
komunikacie jest nazw metody skojarzonej z obiektem. rdem komunikatu jest
pewien obiekt lub aktualnie dziaajcy program. Komunikat moe mie parametry.
Obiekt otrzymujcy komunikat wykonuje odpowiedni metod, ktra moe
zmieni jego stan.
Wypa ( 1000 )
Wypa
OK, wypaciem
Graj
??? bd!
Sprawd
stan
Nalicz
procent
Wpa
KONTO
Porwnaj
podpis
Numer 123-4321
SaldoZ 34567
Upowaniony ...
....
Zlikwiduj
konto
Upowanij
Zmie
upowanienie
Po wykonaniu metody obiekt, ktry otrzyma komunikat, moe zwrci odpowied

do obiektu lub programu, ktry go wysa. Odpowied nie jest komunikatem.
Przesyanie komunikatw a
rwnolego
Czsto termin przesyanie komunikatw (message passing) jest mylnie
interpretowany. Zgodnie z wypowiedziami niektrych autorw, obiekty
komunikuj si ze sob asynchronicznie i rwnolegle poprzez mechanizm
komunikatw, za obiektowo postuluje tak rwnolego (lub wrcz
rozwizuje problem rwnolegoci).
S to pogldy nieuzasadnione i naiwne. S one oparte na budowaniu pochopnej
analogii ze wiatem rzeczywistym, gdzie obiekty posiadaj wasn autonomi i
funkcjonuj niezalenie od siebie, komunikujc si midzy sob w ramach swoich
potrzeb.
Obiektowo nic takiego nie zakada. Przetwarzanie rwnolege jest wanym
i trudnym problemem, cakowicie niezalenym w stosunku do obiektowoci, a
w szczeglnoci do mechanizmu przesyania komunikatw.
Komunikat naley rozumie jako

obiektowy odpowiednik woania procedury.
Klasa, interfejs, typ

Mnstwo nieporozumie na tle rozrnie pomidzy tymi pojciami.
Klasa. Zestaw cech wsplnych dla obiektw zarwno w planie ich populacji, jak
i zmian zachodzcych w czasie. Klasa jest jednostk ponownego uycia i obrotu
handlowego. Zawiera wszystko to, co jest potrzebne do tego, aby j umieci
wewntrz pewnej aplikacji, w szczeglnoci, implementacj metod,
implementacj blokw reakcji na zdarzenia, itd.
Interfejs. Komplet informacji o tych wasnociach obiektw klasy, ktre s
niezbdne do ich poprawnego uycia. Interfejs posiada znaczenie pojciowe dla
uytkownika lub programisty, pozwalajc na manipulowanie zewntrznymi
cechami obiektw i przewidywanie skutkw tych manipulacji. Interfejs moe by
(nieodpatnie) opublikowany w podrczniku. Pojedynczy interfejs moe
cechowa wiele implementacji, jak rwnie jedna klasa moe by wyposaona w
wiele interfejsw.
Typ. Specyfikacja ograniczajca kontekst, w ktrym obiekty danej klasy mog
by uyte w wyraeniach, zapytaniach lub programach. Typ okrela rwnie
reprezentacj wartoci przechowywanych wewntrz obiektu. Niekiedy typ
okrela rwnie wewntrzn budow obiektw. Typ jest pojciem rnym
zarwno od klasy jak i od interfejsu.
Ekstensja klasy
Ekstensja
klasy OSOBA
OSOBA
Nazwisko Nowak
RokUr 1951
OSOBA
Nazwisko
RokUr
Wiek()
OSOBA
Nazwisko Kowalska
RokUr 1975
OSOBA
Nazwisko Abacki
RokUr 1948
OSOBA
Nazwisko Nowacki
RokUr 1940
PRACOWNIK
Zarobek
Dzia
ZarobekNetto()
ZmieZarobek(...)
PRACOWNIK
Nazwisko Nowak
RokUr 1951
Zarobek 2000
Dzia zabawki
PRACOWNIK
Nazwisko Abacki
RokUr 1948
Zarobek 2500
Dzia zabawki
Ekstensja klasy
PRACOWNIK
PRACOWNIK
Nazwisko Nowacki
RokUr 1940
Zarobek 3000
Dzia sprzeda
Klasy
Klasa jest nazwanym zbiorem obiektw o podobnych wasnociach.
Za
Wasnoci te (zestaw atrybutw, metody) s okrelone w definicji klasy.
definicja:
Stosunek klasa/podklasa oznacza zawieranie si zakresw znaczeniowych.
Np. zbir obiektw Student zawiera si w zbiorze obiektw Osoba.
Klasa jest miejscem przechowywania cech obiektw, ktre s niezmienne
Dobra
definicja: (inwariantw). Klasa nie jest zbiorem obiektw i nie jest definicj zbioru
obiektw. Stosunek klasa/podklasa oznacza, e obiekty podklasy posiadaj

wszystkie inwarianty nadklasy, plus swoje inwarianty. Np. klasa Student ma
wszystkie inwarianty klasy Osoba, plus niektre wasne.
Najwaniejsze
inwarianty to:
Nazwa, czyli jzykowy identyfikator obiektu

Typ, czyli statyczna budowa obiektu (atrybuty)
Metody, czyli operacje, ktre mona wykona na obiekcie
Moliwe s
inne inwarianty:
Zdarzenia lub wyjtki, ktre mog zaj w operacjach na obiekcie

Obsuga zdarze lub wyjtkw
Lista eksportowa, okrelajca, ktre atrybuty dostpne s z zewntrz
Ograniczenia, ktrym musi podlega kady obiekt
......
Wyodrbnienie klasy
Obiekty KONTO
(punkt widzenia uytkownika)
Wypa
Sprawd
stan
Nalicz
procent
Wpa
Wpa
Wpa
KONTO
Porwnaj
Porwnaj
podpis
Porwnaj
podpis
podpis
Numer 123-4321
SaldoZ 34567
Upowaniony ...
Zlikwiduj
Zlikwiduj
....
konto
Zlikwiduj
konto
konto
Upowanij
Zmie
upowanienie
Wypa
Sprawd
stan
Nalicz
procent
KONTO
Numer: char[8]
SaldoZ: integer
Waciciel: string
Upowaniony: string
....
Upowanij
Klasa KONTO
Wpa
Porwnaj
podpis
Zlikwiduj
konto
Zmie
upowanienie
Zwizki
jest wystpieniem
klasy
123-4321
34567
Jan Kowalski
....
Obiekty KONTO
(reprezentacja wewntrz pamici)
Typowe klasy:
Identyfikacja klas i
obiektw
przedmioty namacalne (samochd, czujnik)

role penione przez osoby (pracownik, wykadowca, student)
zdarzenia, o ktrych system przechowuje informacje (ldowanie samolotu,
wysanie zamwienia, dostawa),
interakcje pomidzy osobami i/lub systemami o ktrych system przechowuje
informacje (poyczka, spotkanie, sesja),
lokalizacje - miejsce przeznaczone dla ludzi lub przedmiotw
grupy przedmiotw namacalnych (kartoteka, samochd jako zestaw czci)
organizacje (firma, wydzia, zwizek)
wydarzenia (posiedzenie sejmu, demonstracja uliczna)
koncepcje i pojcia (zadanie, miara jakoci)
dokumenty (faktura, prawo jazdy)
klasy bdce interfejsami dla systemw zewntrznych
klasy bdce interfejsami dla urzdze sprztowych
Zadania:
Proces tworzenia
modelu obiektowego
Identyfikacja klas i obiektw

Identyfikacja zwizkw pomidzy klasami
Identyfikacja i definiowanie pl (atrybutw)
Identyfikacja i definiowanie metod i komunikatw
Czynnoci te s wykonywane iteracyjnie. Kolejno ich wykonywania nie jest
ustalona i zaley zarwno od stylu pracy, jak i od konkretnego problemu.
Inny schemat realizacji procesu budowy modelu obiektowego polega na
rozpoznaniu funkcji, ktre system ma wykonywa. Dopiero w pniejszej fazie
nastpuje identyfikacja klas, zwizkw, atrybutw i metod. Rozpoznaniu funkcji
systemu su modele funkcjonalne (diagramy przepywu danych) oraz model
przypadkw uycia.
Techniki obiektowe
1. Ukrywanie implementacji (enkapsulacja)
okrelone jednoznacznie i niezmiennie interfejsy
stosowanie instrukcji np.: typedef ukrywajcej wykorzystywane
typy i wyraenia
podzia programu na mniejsze czci (dynamicznie i statycznie
czone biblioteki)
Techniki obiektowe
2. Wielokrotne wykorzystanie implementacji (poliformizm)
podzia programu na klasy
zamykanie kodu metod w obiekty o podobnej funkcjonalnoci
stosowanie wzorcw projektowych np.: obiekt factory
wykorzystywanie klas i metod szablonowych
Polimorfizm
Kada klasa ma wasn metod

dochody.
S one niezalene i s
niezalenie programowane
PRACOWNIK
....
dochody()
....
obiekt
obiekt
obiekt
OSOBA
nazwisko
kategoria
....
....
STUDENT
....
dochody()
....
obiekt
obiekt
obiekt
EMERYT
....
dochody()
....
obiekt
obiekt
Techniki obiektowe
3. Dziedziczenie
zmniejszanie odpowiedzialnoci klas (obiektw)
okrelanie relacji bycia czym i bycia podobnym do czego
zapewnienie mechanizmu wymienialnoci obiektw
wykorzystanie mechanizmw polimorfizmu
rozszerzanie odpowiedzialnoci (specjalizacja)
Wyodrbnienie hierarchii
dziedziczenia
Hierarchia dziedziczenia
Klasa
oglna
Klasa
wyspecjalizowana
OSOBA
Nazwisko
Imi
RokUrodz
Wiek()
PRACOWNIK
Nazwisko
Imi
RokUrodz
Zarobek
Firma
Zdjcie
Wiek()
ZarobekNetto()
ZmieZarobek(...)
OSOBA
Nazwisko
Imi
RokUrodz
Wiek()
PRACOWNIK
Zarobek
Firma
Zdjcie
ZarobekNetto()
ZmieZarobek(...)
Wielokrotne dziedziczenie
Przy wielodziedziczeniu klasa moe dziedziczy z dwch lub wicej klas.
POJAZD
ciar
.....
prdko_eksploat()
POJAZD_LDOWY
ilo_k
max_prdko
.....
SAMOCHD
TRAKTOR
POJAZD_WODNY
wyporno
max_prdko
.....
AMFIBIA
AGLWKA
JACHT
Wielodziedziczenie prowadzi do anomalii i wad koncepcji.

Z tego wzgldu niektre jzyki (m.in. Java) rezygnuj z wielodziedziczenia.
W wiekszoci anomalie s konsekwencj faktu, e przy pomocy wielodziedziczenia prbuje
si opanowa koncepcj dynamicznych rl obiektu.
Techniki obiektowe
4. Kompozycja (agregacja)
okrelenie relacji zawierania w si w czym (bycie czci)
okrelenie relacji zawierania w sobie (bycie caoci)
kontrola nad innymi obiektami
rola providera usugodawcy
realizacja wzorcw typu Adapter, Proxy
Techniki analizy obiektowej

Budowa statycznego modelu klas
Analiza funkcji i przypadkw uycia
Weryfikacja klas i obiektw
Identyfikacja i definiowanie metod oraz komunikatw
Modelowanie stanw i przej midzy stanami
Modelowanie procesw i przepyww danych
Modelowanie przepywu sterowania
Inne
Wiele tych technik bdzie omwione podczas prezentacji
metodyki OMT.
Co to jest metodyka obiektowa?

Metodyka wykorzystujca pojcia obiektowoci dla celw modelowania
pojciowego oraz analizy i projektowania systemw informatycznych.
Podstawowym skadnikiem jest diagram klas, bdcy zwykle wariantem
notacyjnym i pewnym rozszerzeniem diagramw encja-zwizek.
Diagram klas zawiera: klasy, w ramach klas specyfikacje atrybutw i metod,
zwizki generalizacji, zwizki asocjacji i agregacji, licznoci tych zwizkw,
rnorodne ograniczenia oraz inne oznaczenia.
Uzupenieniem tego diagramu s inne: diagramy dynamiczne uwzgldniajce
stany i przejcia pomidzy tymi stanami, diagramy interakcji ustalajce
zalenoci pomidzy wywoaniami metod, diagramy funkcjonalne (bdce
zwykle pewn mutacj diagramw przepywu danych), itd.
Popularno zdobya koncepcja przypadkw uycia (use cases), ktrej
podstawowym celem i walorem jest odwzorowanie struktury systemu z punktu
widzenia jego uytkownika.
Przykady: Express, OODA(Booch), OMT(Rumbaugh), OOSA(Shlaer-Mellor),
Objectory(Jacobson), MOSES/OPEN, OOA/OOD(Coad/Yourdon), Notacja UML, RUP.
Rnice pomidzy metodykami

Podejcia proponowane przez rnych autorw rni si czciowo, nie musz
by jednak ze sob sprzeczne. Nie ma metodyk uniwersalnych. Analitycy i
projektanci wybieraj kombinacj technik i notacji, ktra jest w danym
momencie najbardziej przydatna.
Poszczeglne metodyki zawieraj elementy rzadko wykorzystywane w praktyce
(np. model przepywu danych w OMT).
Notacje proponowane przez rnych autorw nie s koniecznie nierozerwalne z
sam metodyk. Np. notacji UML mona uy dla metodyki Coad/Yourdon.
Narzdzia CASE nie narzucaj metodyki; raczej, okrelaj one tylko notacj.
Twierdzenia, e jakie narzdzie CASE jest oparte na konkretnej metodyce jest
czsto wycznie hasem reklamowym. Nawet najlepsze metodyki i narzdzia
CASE nie s w stanie zapewni jakoci projektw.
Kluczem do dobrego projektu jest zesp dowiadczonych, zaangaowanych i
kompetentnych osb, dla ktrych metodyki, notacje i narzdzia CASE su
jako istotne wspomaganie.
Historia metod analizy i

projektowania obiektowego
UML
Ang. Unified Modeling Language,
Zunifikowana notacja do analizy i
projektowania (modelowania)
obiektowego
Formalny jzyk modelowania
obiektowego
Co jest wane w UML ?
Paradygmat obiektowy, poniewa tworzy on

podstawy jzyka UML.
Modelowanie strukturalne i behawioralne,
poniewa pozwalaj zrozumie wymogi stawiane
systemowi i jego architektur.
UML jako jzyk

elementy diagram diagram
zwizki
zwizki
elementy
UML jest po prostu jzykiem wizualnym, sucym

do modelowania i opisywania systemw za
pomoc blokw konstrukcyjnych: elementw,
zwizkw midzy nimi i diagramw.
Schemat modelu systemu w

UML
Model systemu
Diagramy
zachowania
Diagramy
klas
Diagramy
obiektw
Diagramy
wdroenia
Diagramy
komponentw
Diagramy
struktury
Diagramy
przebiegw
Diagramy
kooperacji
Diagramy
stanw
Diagramy
przypadkw
uycia
Diagramy
czynnoci
Diagramy
interakcji
Diagramy w UML.
Diagramy schemat przedstawiajcy zbir bytw.
Najczciej jest grafem, w ktrym wierzchokami s
elementy, a krawdziami zwizki.
Diagramy struktury
Diagramy zachowania
statyczne aspekty systemu dynamiczne aspekty systemu
diagramy klas
diagramy obiektw
diagramy komponentw
diagramy wdroenia
diagramy przypadkw uycia

diagramy interakcji:
- diagramy przebiegu
- diagramy kooperacji
diagramy stanw
diagramy czynnoci
Elementy w UML
Strukturalne wyraone rzeczownikami.
Najbardziej statyczne elementy modelu.
Reprezentuj skadniki pojciowe albo fizyczne.
Klasy
Kooperacje
Przypadki uycia
Hierarchia
odpowiedzialnoci
Wzy
Interfejsy
Komponenty
Elementy w UML
Czynnociowe dynamiczna cz modelu w UML.
Wyraone czasownikami. Opisuj zachowanie w czasie i w
przestrzeni. Powizane z elementami strukturalnymi.
Maszyna stanowa
Interakcja
wywietl
komunikat
Zachowanie polegajce na
wymianie komunikatw
midzy obiektami.
stan
Okrela cig stanw jakie obiekt

lub interakcja moe przyj.
stany
przejcia midzy stanami
zdarzenia powodujce przejcia
czynnoci odpowiedzi na zdarzenia
komunikaty
cigi akcji w odpowiedzi na
komunikaty
poczenia midzy obiektami
Elementy w UML
Grupujce bloki na ktre
moe by dany model
rozoony.
Rola organizacyjna.
Komentujce objanienia pisane

w celu uwypuklenia lub zaznaczenia
dowolnych skadnikw systemu.
Pakiety
Modele
Pakiety
Zrby
Podsystemy - rodzaje pakietw
Notatka
elementy strukturalne
elementy czynnociowe
inne pakiety
Notatka
Wymagania
Elementy w UML
Zwizki su do czenia elementw. Uywane do budowy
poprawnych modeli.
Uoglnienie
Zaleno
Realizacja
Powizanie
Wykad 7 10.04.2014
cd faza analizy - UML
Schemat modelu systemu w

UML
Model systemu
Diagramy
zachowania
Diagramy
klas
Diagramy
obiektw
Diagramy
wdroenia
Diagramy
komponentw
Diagramy
struktury
Diagramy
przebiegw
Diagramy
kooperacji
Diagramy
stanw
Diagramy
przypadkw
uycia
Diagramy
czynnoci
Diagramy
interakcji
Diagramy przypadkw
uycia
Przynaleno do:
Diagramw interakcji
Diagramw zachowa
Diagramy przypadkw uycia

Przypadek uycia jest przypadkiem, w ktrym dany
system jest uywany w celu speniania jednego lub
wikszej liczby wymaga uytkownikw.
Diagramy te wychwytuj fragment funkcji
udostpnianych przez system.
Okrelaj wymagania funkcjonalne systemu
Przypadki uycia dotykaj kadej innej czci projektu
systemu.
Przypadki uycia nie okrelaj wymaga
niefunkcjonalnych systemu
Elementy diagramw
przypadkw uycia
Aktor to kto (co), kto (co) musi wspdziaa z
modelowanym systemem.
Aktor w UMLu jest klas (nie obiektem!) o nadanym
stereotypie Actor.
Mona go oznacza poprzez
Ikon
- klas ze tzw. stereotypem
<< Actor >>
Czytelnik
Czytelnik
Aktorzy mog by: ludmi wchodzcymi w interakcj, systemami

zewntrznymi, czciami systemu, ktre maj wpyw na
funkcjonowanie systemu, ale same przez ten system nie mog by
zmieniane (jak np. zegar systemowy).
Diagram przypadkw uycia

Przypadek uycia (use-case)
jest sposobem, w jaki aktorzy uywaj (chc
uywa) systemu
jest podstawow jednostk funkcjonalnoci.
definiuje wymagania funkcjonalne systemu
Czego potrzebuj uytkownicy?
Bibliotekarz...
Czytelnik...
Diagram use-case
Definiuje
granice systemu, czyli jak daleko siga model

jego kontekst, czyli co pozostaje na zewntrz
uytkownikw systemu, czyli aktorw
funkcje systemu,
zalenoci midzy uytkownikami i
funkcjami
... i jest czytelny dla odbiorcy!
Inne elementy diagramw

przypadkw uycia
Blok ponownego uycia: Pokazuje fragment
systemu, ktry jest uywany przez kilka przypadkw
uycia; moe by oznaczony jako samodzielny
przypadek uycia.
Relacja typu << include >> (wskazuje na wsplny fragment
wielu przypadkw uycia (wyczony "przed nawias");)
lub << extend >> (strzaka prowadzi od przypadku uycia, ktry

czasami rozszerza inny przypadek uycia) : zwizek zachodzcy
midzy dwoma przypadkami uycia lub przypadkiem
uycia a blokiem ponownego uycia.
Nazwa systemu wraz z otoczeniem systemu:
Pokazuje granic pomidzy systemem a jego
otoczeniem.
Diagram use-case - przykad

<<ex tends>>
<<ex tends >>
dodanie k sik i
dodani e c z asopi sm a
dod anie t y tuu
aktualiz ac ja ty tuu
<<us es>>
<<uses >>
<<us es >>
dodani e
adm inistrac ja
Bibliotek arz
Uycie funkcji
Aktor uywa funkcji (wykonuje funkcj) - od uytkownika
do funkcji
Bibliotekarz
rezerwacja
Zalenoci midzy funkcjami

Funkcja uszczegawia funkcj
jest to relacja dziedziczenia typu <<extends>>
od funkcji szczegowej do funkcji oglnej
<<extends>>
dodanie czasopisma
dodanie tytuu
Zalenoci midzy funkcjami

Funkcja wywouje inn funkcj
relacja zalenoci funkcji
ponowne uycie funkcji/komponentu
rodzaj zalenoci funkcja wywouje funkcj
<<uses>>
od funkcji woajcej do funkcji woanej
<<uses>>
dodanie
administracja
Wychwytywanie przypadkw
uycia
Analiza opisu systemu z punktu widzenia przyszego
uytkownika.
Wymagania konieczne (bez nich system nie bdzie
funkcjonowa).
Wymagania opcjonalne (podane, mog by
porzucone jako pierwsze w chwili napotkania
nieprzewidzianych trudnoci w chwili napotkania
nieprzewidzianych trudnoci w realizacji systemu.
Ktrych funkcji aktor oczekuje od systemu?
Czy aktor musi czyta, modyfikowa, tworzy lub
likwidowa pewne informacje w systemie?
Wychwytywanie przypadkw
uycia cd
Czy aktor powinien by powiadomiony o zdarzeniach
w systemie lub sam informowa system? Co te
zdarzenia reprezentuj w kategoriach funkcji?
Czy codzienna praca aktora moe by uproszczona
lub bardziej efektywna?
Jakich danych we/wy wymaga system? Skd
pochodz i dokd s kierowane?
Jakie s wskie garda obecnego dziaania?
Wane uwagi do tworzenia

diagramw przypadkw uycia
Dla kadego aktora, znajd funkcje (zadania), ktre powinien
wykonywa w zwizku z jego dziaalnoci w zakresie zarwno
dziedziny przedmiotowej, jak i wspomagania dziaalnoci
systemu informacyjnego.
Staraj si powiza w jeden przypadek uycia zesp funkcji
realizujcych podobne cele. Unikaj rozbicia jednego przypadku
uycia na zbyt wiele pod-przypadkw.
Nazwy dla przypadkw uycia: powinny by krtkie, ale
jednoznacznie okrelajce charakter zadania lub funkcji.
Nazwy powinny odzwierciedla czynnoci z punktu widzenia
aktorw, a nie systemu, np. "wpacanie pienidzy", a nie
"przyjcie pienidzy od klienta".

Opisz przypadki uycia przy pomocy zda w jzyku naturalnym,
uywajc terminw ze sownika.
Uporzdkuj aktorw i przypadki uycia w postaci diagramu.
Niektre z powstaych w ten sposb przypadkw uycia mog
by mutacjami lub szczeglnymi przypadkami innych
przypadkw uycia. Przeanalizuj powizania aktorw z
przypadkami uycia i ustal, ktre z nich s zbdne lub mog by
uoglnione.
Wyodrbnij "przypadki bazowe", czyli te, ktre stanowi istot
zada, s normalnym, standardowym uyciem. Pomi czynnoci
skrajne, wyjtkowe, uzupeniajce lub opcyjne.
Nazwij te przypadki bazowe. Ustal powizania przypadkw
bazowych z innymi przypadkami, poprzez ustalenie ich
wzajemnej zalenoci: sekwencji czy alternatywy.

Doda zachowania skrajne, wyjtkowe, uzupeniajce lub opcjonalne. Ustali powizanie przypadkw bazowych z tego rodzaju
zachowaniem. Moe ono by take powizane w pewn struktur.
Bloki specyfikowane wewntrz kadego przypadku uycia nie
powinny by zbyt oglne lub zbyt szczegowe. Zbyt szczegowe
bloki utrudniaj analiz. Zbyt oglne bloki zmniejszaj moliwo
wykrycia blokw ponownego uycia. Struktura nie moe by zbyt
dua i zoona.
Staraj si wyizolowa bloki ponownego uycia. Przeanalizuj
podobiestwo nazw przypadkw uycia, podobiestwo nazw i
zachowania blokw ponownego uycia wystpujcych w ich
specyfikacji. Wydzielenie bloku ponownego uycia moe by
powizane z okreleniem oglniejszej funkcji lub dodaniem nowej
specjalizacji do istniejcej funkcji
Diagramy klas i obiektw

Przynaleno do:
Diagramw struktury

Klasa przedstawia elementy wiata o podobnej
semantyce i podobnym zachowaniu.
Posiada nazw, operacje i atrybuty.
nazwa pochodzi z dziedziny zastosowania
standard nazywania klas
Jak wyodrbni klasy? (top-down, buttom-up)
Diagramy klas i obiektw cd

Operacje to usugi oferowane przez klas
operacja ma argumenty i typ wartoci
interfejs, deklaracja a definicja typu
operacje mog by statyczne
ich zakres obejmuje klas a nie obiekt
operacje mog by abstrakcyjne
posiadaj tylko deklaracj operacji, definicje s
w klasach potomnych
Diagramy klas i obiektw cd

Atrybuty to informacje zawarte w klasie/obiekcie
cechy klasy/obiektu
relacje z innymi klasami/obiektami
atrybuty statyczne
atrybuty wywiedzione (derived) /
typy atrybutw
Jak odrni klas od atrybutu?
Stereotypy (ang. stereotypes)

Stereotyp suy do stworzenia nowego rodzaju
obiektu ma podstawie obiektu zdefiniowanego ju w
standardzie UML
Najprostszym sposobem dodania nowego stereotypu
jest dodanie nazwy stereotypu
<<nazwa stereotypu>>
przy nazwie obiektu.
W standardzie UML jest zdefiniowanych kilkadziesit
stereotypw np.
<<interface>>
Stereotypy cd
Np. gdy chcemy wrd klas wyrni wyjtki (bo maj
one zupenie inne zastosowanie ni reszta klas),
mona to zrobi dodajc nowy stereotyp
<<exception>>
Naley pamita, e wprowadzanie wasnych
oznacze do diagramw zmniejsza
natychmiastow ich czytelno. Dlatego z
moliwoci tworzenia nowych stereotypw
naley korzysta tylko wtedy, gdy rzeczywicie
jest taka potrzeba
Diagramy klas i obiektw zakres

widocznoci operacji i atrybutw
+ publiczne (public)
widoczne dla wszystkich
# chronione (protected)
widoczne dla potomkw
prywatne (private)
widoczne wewntrz klasy (kontenera)
implementacyjne (implementation)
widoczne wewntrz pakietu (nadkontenera)

asocjacje
Reprezentuj relacje, w jakich znajduj si klasy/obiekty
posiadaj liczno (krotno)
wi 1 lub wicej klas
mog by nazwane i posiada role
mog mie wasnoci i ograniczenia
K s i k a
ID : S tring
+ pos iada
1..*
podaj ID ()
1.. 1
Ty tu
ty tu : S tring
IS B N : S tring
podaj ty tu()

krotno asocjacji
Asocjacja oznacza liczb obiektw (nie klas!),
ktre s ze sob skojarzone
okrelone przez dolny i grny zakres
okrelane liczb naturaln (0, 1, 2, ...) lub
gwiazdk (* - dowolna liczba)
maj due znaczenie na etapie projektu
Jaka jest rnica midzy oznaczeniami: * i 1..* ?

agregacja
Modeluj relacj cz-cao
agregacja wspdzielona (shared) - cz moe
nalee do wielu caoci
agregacja skadowa (composition) - cz jest
cile uzaleniona od caoci
Ksika
ID : String
podaj ID()
Tom
+skada si
ID tomu : int
1..1
1..*

zaleno
Jest oglnym okreleniem zalenoci (dependency)
dwch klas/obiektw
od klasy zalenej do nadrzdnej
czsto uywane ze stereotypem (tu <<friend>>)
powizanie elementw na rnych poziomach
abstrakcji
Ksika
Tom
ID : String
podaj ID()
ID tomu : int
<<friend>>
Co to jest dziedziczenie?
Dziedziczenie czyli generalizacja lub specjalizacja
jest zwizkiem pomidzy klasami, czcymi klas
bardziej ogln (nadklas) z jedn lub wicej klas
(tzw. podklas) bdcych jej specjalizacjami.
Klasa, bdca specjalizacj danej klasy, oprcz
atrybutw nadklasy moe posiada (i z reguy
posiada) te swoje atrybuty.
Dziedziczenie inwariantw do klas jest tranzytywne
(przechodnie).

Dziedziczenie
Potomek dziedziczy cechy przodka
uatwia zarzdzanie zoonoci
zakres widocznoci w dziedziczeniu
klasa abstrakcyjna jako przodek dostarcza tylko
definicji operacji
polimorfizm operacji
tryby dziedziczenia: overlapping, disjoint,
complete, incomplete
Tryb dziedziczenia
Overlapping
Np. Podzia, w ktrym osoba moe by jednoczenie
studentem i pracownikiem, ale nie musi.
Osoba
{overlapping}
Student
Pracownik
Overlapping
perspektywa projektowa
Osoba
0..1
Student
0..1
Pracownik
Tryb dziedziczenia Disjoint

Czyli podzia
rozczny. Jest to
podzia domylny.
Oznacza, e np.
dana osoba nie
moe by
jednoczenie
pracownikiem
i studentem.
Osoba
Imie
Nazwisko
Data urodzenia
Wiek()
{disjoint}
Student
Pracownik
Numer
indeksu
Numer grupy
Data zatrudnienia
Pensja
Disjoint - perspektywa
projektowa
Osoba
Imie
Nazwisko
Data urodzenia
Wiek()
0..1
{xor}
0..1
Student
Pracownik
Numer
indeksu
Numer grupy
Data zatrudnienia
Pensja
Tryb dziedziczenia Complete

Czyli podzia cakowity, jest to podzia domylny.
Wszystkie klasy zostay ju okrelone i adna nowa nie
bdzie dodawana.
Nadklasa jest klas abstrakcyjn.
{abstract}
Osoba
{complete}
Student
Pracownik
Tryb dziedziczenia
Incomplete
Czyli podzia klas niecakowity.
Nie wszystkie podklasy zostay zdefiniowane, nadklasa
nie jest klas abstrakcyjn.
Istnieje moliwo dodania nowych klas.
Osoba
{incomplete}
Student
Pracownik
Przykadowy diagram klas z

dziedziczeniem
Wydawnictwo
ID : String
podaj ID()
{complet e}
Ksika
podaj ID()
Czasopismo
podaj ID()
Diagram klas - cd
Tytu jest klas abstrakcyjn

Ksika i Czasopismo s specjalizacjami Tytuu
Czytelnik moe mie wiele Wypoycze
Wypoyczenie dotyczy jednego Czytelnika
Przykad diagramu klas

W y daw nic two + jes t k opi
ID : String
0..*
Tytu
+jest rez erwowany prz ez
naz wa
/ li c zba reze rwac ji 1..1
1 .. 1
1..1
Ty tu k s i ki
IS BN : S trin g
+ dotyc z y
0..1
W ypo y cz enie
data : Date
Ty tu cz asopis ma
IS S N : S tring
Dane c zy telnika
imi
+ jes t z wi zane
nazwisk o
1..1
0..* adres
0.. *
+s k ada
1..1
0..*
Rez erwac ja
d ata : Date
Diagramy obiektw
przedstawia egzemplarze elementw z diagramu klas;
przedstawia si obiekty, czyli konkretne instancje klas i zwizki
midzy nimi.
obrazuje zbir obiektw i ich zwizkw w danej chwili;
czsto nazywany jest diagramem instancji (przedstawia
instancje klas a nie same klasy);
zawiera na og: obiekty, wizania, notatki, ograniczenia,
pakiety, podsystemy, klasy.
Diagram jest rzutem pewnych egzemplarzy elementw
wystpujcych na diagramie klas - bierze si tu pod uwag
przypadki rzeczywiste lub prototypowe.
Diagramy stanw
Przynaleno do:
Diagramw zachowa
Dynamiczne zachowanie obiektu

- Diagram stanu (STD)
Modeluje cykl (fazy) ycia obiektu
okrela dozwolone stanu obiektu
definiuje dopuszczalne przejcia
okrela zdarzenia, na ktre obiekt reaguje
okrela akcje, jakie zachodz podczas przejcia
Diagram stanu - stany obiektu

i przejcia
Dopuszczalne stany
stany pocztkowy i kocowy
jeden ze stanw porednich
Przejcie jest opisane przez
zdarzenie, ktre wyzwala przejcie
warunek, ktry weryfikuje dopuszczalno
przejcia
akcj, ktra jest wykonywana w momencie
przejcia
Diagram stanu - stany

obiektw w UML
Reprezentacja stanu
nazwa
zmienne stanu
czynnoci
zniszczona
entry: usu z rejestru
Reprezentacja przejcia
zdarzenie [warunek] / akcja ^ nowe-zdarzenie
zapisz [operacja dozwolona] / ^dysk.zapisz()
Diagram stanu - zdarzenia w

UML
Cztery rodzaje zdarze w UMLu
warunek staje si prawdziwy
odbir sygnau od innego obiektu
wywoanie operacji przez inny obiekt
upyw okrelonego czasu
bdy (poza definicj UML)
Diagram stanu - obsuga

zdarze
Wywoania operacji
wywoujcy obiekt jest aktywny
wywoywany obiekt jest pasywny
Obsuga sygnaw
wywoywany i wywoujcy obiekt musz by
aktywne
sygna jest obiektem ze stereotypem
<<signal>>
Diagram stanu - stany i

podstany
Stan moe mie podstany
typu or - aktywny jest jeden podstan
typu and - aktywnych moe by kilka
podstanw
zarezerwowana
zwrot
wypoyczona
zarezerwowana
wypoyczenie
Modelowanie dynamiczne w
UML
Diagramy modelowania zachowania
czynnoci (activity diagram)
odwzorowuj akcje wykonywane na obiektach
dokonuj podziau odpowiedzialnoci za akcje
wsppracy (collaboration diagram)

wi wsppracujce obiekty z uwzgldnieniem kolejnoci
pokazuj zalenoci midzy obiektami
sekwencji (sequence diagram)
305
Diagramy aktywnoci
(czynnoci)
Przynaleno do:
Diagramw zachowa
Diagram aktywnoci
(czynnoci)
Suy do modelowania czynnoci i zakresu odpowiedzialnoci
elementw bd uytkownikw systemu.
Jest niejako podobny do diagramu stanu, jednak w
odrnieniu od niego nie opisuje dziaa zwizanych z jednym
obiektem a wieloma, pomidzy ktrymi moe wystpowa
komunikacja przy wykonywaniu czynnoci.
Diagramy czynnoci stosuje si w modelowaniu:
wysokopoziomowych procesw biznesowych

systemw oraz podsystemw
scenariuszy przypadkw uzycia
procesw systemowych charakteryzujcych si du liczb rwnolegych czynnoci i
sytuacji decyzyjnych
Operacji i algorytmw
Notacja w diagramach
aktywnoci (czynnoci)
Aktywno/Czynno - rodzaj zachowania,
skadajcego si z przynajmniej jednej akcji.
Czynno moe by interpretowana rnie, np.: jako
zadanie do wykonania i to zarwno przez czowieka,
jak i przez komputer. Mog cechowa si
rozbudowan funkcjonalnoci, (np. zoony procesy
biznesowe bd algorytmy przetwarzania).
Akcja reprezentuje wykonanie pojedynczej operacji,
ktrej nie mona rozbi na mniejsze jednostki na
diagramie. Na przykad akcjami mog by funkcje
matematyczne.
Przepyw kontroli i danych
Przerwania
aktywnoci (czynnoci) cd
utworzenie znacznika sterowania
zniszczenie wszystkich
znacznikw sterowania
zniszczenie danego znacznika
sterowania
Decyzje (Wyjcie decyzji stanowi
dwa lub wicej przepyww, z
ktrych tylko jeden moe by
zrealizowany).
1. Warunek logiczny - rne warunki
musz si wyklucza, aby zapewni
jednoznaczny przepyw sterowania
2. Rozgazienie (decyzja)
cieki wspbiene
Rozwidlenie - fork
Akcje wspbiene
Scalenie sterowania - join
Zczenia
Kady przypyw sterowania
docierajcy do wejcia inicjuje
proces wyjciowy
Proces wyjciowy jest
inicjalizowany dopiero po
dotarciu znacznikw od
wszystkich przypyww
synchronizacja
Mona do przepywu doda
ograniczenia { }
Przykad diagramu aktywnoci
Diagramy sekwencji
przebiegu
Przynaleno do:
Diagramw zachowa
Modelowanie dynamiczne
w UML diagramy sekwencji
Diagram sekwencji wskazuj:
jak obiekty wspdziaaj ze sob
sposb wysyania i odbioru zdarze
Wystpuje tu skadowa czasu
: B ib l i o te k a rz
: W y d a w n ic t w o
: C z y te ln ik
z a re z e rw u j
c z y is t n ie je ?
p o b ie rz lic z b
314
Typy zdarze w diagramach

sekwencji
UML rozrnia typy zdarze
synchroniczne, np. wywoania metod
asynchroniczne, np. sygnay
proste, np. przekazanie kontroli
synchroniczne z natychmiastowym powrotem
315
Istnienie obiektu w
diagramach sekwencji
Prostokt na linii ycia obiektu
pocztek - aktywacja obiektu
koniec - dezaktywacja obiektu
usunicie obiektu - znak X
iteracja - prostokt obejmujcy zdarzenia
rekursja - wywoanie wasnych operacji
316
Diagramy komponentw
Przynaleno do:
Diagramw struktury
Wstp do diagramw
komponentw (komponent/pakiet)
Komponent - reprezentuje jeden fizyczny modu kodu.
Komponent to wymienialny, wykonywalny fragment systemu, z
ukrytymi szczegami implementacyjnymi
Jest podsystemem, ktry organizuje zwizane ze sob
elementy
Komponent udostpnia zestaw interfejsw, moe te wymaga
pewnych interfejsw do funkcjonowania.
Komponent to wymienny, wykonywalny fragment systemu o
hermetyzowanych szczegach implementacyjnych.
Zwykle su do ponownego wykorzystania
Funkcjonalno oferowana przez komponent jest dostpna
przez interfejsy
318
Diagram komponentw
Diagram komponentw suy do pokazania zwizkw

pomidzy komponentami i interfejsami
Przykady opisu komponentw
Diagram pakietw
W miar wzrostu wielkoci modelowanego systemu,
ronie liczba wykorzystywanych elementw (klas,
interfejsw, komponentw...)
Mona grupowa modelowane byty w pakietach.
Dobrze zaprojektowane pakiety skadaj si z
podobnych znaczeniowo i razem zmieniajcych si
bytw. S luno powizane ze sob, ale silnie spjne
wewntrznie.
Dostp do zawartoci pakietw jest kontrolowany
Reprezentacja graficzna pakietu (Nazwa pakietu (moe
te by napisana na zakadce):
Pakiety cd
Komponenty mona grupowa w pakiety
Relacje midzy pakietami mog by:
Zaleno (<<merge>>), generalizacja (<<access>>), import
elementw (<<import>>)
Widoczno elementw w pakiecie jest

analogiczna do widocznoci cech klas
U s u g i
k a t a lo g o w e
GUI
O b s u g a
w y po y c z e
B az a dany c h
322
Powizania pakietw
rodzaje zalenoci
<< import >> umoliwia dostp w klasie rda do
zawartoci klasy celu (w Pakiecie1 mona teraz
uywa klasy B bez podawania cieki). Odpowiada
dziedziczeniu publicznemu (nastpny import
przejmie te klas B).
<< access >> podobnie, ale jak dziedziczenie
prywatne (nastpny import nie umoliwi ju dostpu
do klasy B)
<< merge >> powoduje przyczenie zawartoci
klasy docelowej z zachowaniem okrelonej listy
regu. W praktyce mao uyteczne i rzadko uywane
Pakiety
Pakiety i komponenty systemu
s fizyczn reprezentacj elementu modelu
relacja zalenoci komponentw
relacje ze znacznikiem {location}
przyporzdkowanie komponentw do zasobw
dostp do usug poprzez interfejsy
relacja wywoania (stereotyp <<calls>>)
Dialog
logowania
Meneder
okien
324
Stereotypy komponentw
executable - okrela komponent, ktry mona
wykona na wle;
library - okrela dynamiczn lub statyczn
bibliotek obiektw;
table - okrela komponent reprezentujcy tabel
bazy danych;
file - okrela komponent reprezentujcy
dokument zawierajcy kod rdowy lub
dane;
document - okrela komponent reprezentujcy
dokument;
Uwagi o diagramach
komponentw - podsumowanie
Diagramy pakietw (ang. package diagrams) su do
modelowania fizycznego i logicznego podziau systemu.
Pakiety s elementem strukturalizujcym elementy UML i
su do grupowania ich wedug dowolnego kryterium. W
pakiecie mona umieci praktycznie dowolne elementy:
klasy, komponenty, przypadki uycia, a take inne pakiety. W
ten sposb przedstawiaj one drzewiast struktur
elementw modelu.
Pakiety doskonale nadaj si do wizualizacji podstawowych
zalenoci pomidzy czciami systemu, dziki czemu atwo
oceni jako i stopie powiza pomidzy nimi.
Uwagi o diagramach
Dobra struktura pakietw, w ktrej zalenoci s jasno
uporzdkowane oraz nie wystpuj (lub wystpuj tylko na
niskim poziomie) zalenoci cykliczne, wspiera pniejsz
rozbudow systemu.
Przydaj si gwnie w duych aplikacjach, podzielonych na
wiele podsystemw, poniewa w prosty sposb obrazuj
podstawowe zalenoci pomidzy nimi.
Pakiet tworzy take jednostk hermetyzacji: elementy z
pakietu odwouj si do elementw zewntrznych posugujc
si ich penymi kwalifikowanymi (zawierajcymi nazwy
pakietw) nazwami, zgodnie z ich zakresem widocznoci.
Uwagi o diagramach
Wewntrz pakietu elementy mog odwoywa si do siebie
bezporednio.
Elementy wewntrz pakietu mog mie jeden z dwch
poziomw widocznoci: prywatny lub publiczny.
Elementy publiczne s widziane i mog by uyte poza
wasnym pakietem, natomiast prywatne - nie.
Aby elementy pakietu mogy odwoa si do elementw
prywatnych z innego pakietu, musz go importowa.
Oznacza to, e elementy te staj si dla importujcego
pakietu widoczne. Import pakietu oznaczany jest zalenoci
ze sowem kluczowym << import >>.
Diagramy wdroe
Przynaleno do:
Diagramw struktury
Diagramy wdroe
(ang. deployment diagram)
przedstawiaj powizania midzy oprogramowaniem
(artefaktami) i sprztem (wzami).
odzwierciedlaj fizyczn struktur caego systemu, z
uwzgldnieniem oprogramowania i sprztu.
jednostki oprogramowania s reprezentowane przez artefakty
(czyli skompilowane wersje komponentu, ktry mona
uruchomi), dane i biblioteki.
odgrywaj istotn rol przy wdraaniu duych, rozproszonych
systemw ale s rzadko uywane przy modelowaniu mniejszych i
rednich systemw.
pozwalaj doprecyzowa znaczenie i funkcj oprogramowania
oraz sprztu.
Diagram rozmieszczenia
diagram wdroena
Rozmieszczenie (deployment)
fizyczna architektura systemu
przyporzdkowanie moduw do urzdze
zalenoci midzy zasobami
Us ugi
k atalogowe
S erwer
aplikac ji
Usugi
k atalogowe
331
Przykad diagramu wdroe
Diagramy kooperacji
(komunikacji)
Przynaleno do:
Diagramw interakcji
Diagramy kooperacji
Nazwano go diagramem komunikacji (ang. communications
diagram) a w UML 1.x by to collaboration diagram
Jest rozszerzon wersj wspdziaania
Skupia si on na obiektach wchodzcych w skad interakcji i
wymienianymi przez nie komunikatach, natomiast w
mniejszym stopniu ni diagram sekwencji (cho nadal
obecnym) wskazuje na aspekt czasowy. Z tego powodu
obiekty na diagramie komunikacji s umieszczone tak, aby
atwo mona byo opisa ich relacje pomidzy sob.
Komunikacje s przedstawiane za pomoc linii czcych
obiekty, natomiast przesyane midzy obiektami komunikaty i
dane s umieszczane obok tych linii.
Diagramy kooperacji komunikacji

Kady komunikat jest opatrzony etykiet liczbow,
wskazujc na kolejno ich wysyania.
Etykieta ta ma posta liczb oddzielonych kropkami. W
przypadku rozdzielenia sterowania kady krok
powoduje dodanie do etykiet krokw nastpnych
kolejnych pl z liczbami, np. krok 2 powoduje
utworzenie krokw 2.1, 2.2 lecych bezporednio za
nim. Krok 2.1 posiada kroki 2.1.1 i 2.1.2, itd.
W odrnieniu od diagramw sekwencji, diagramy
komunikacji nie mog przekaza wielu informacji
dotyczcych interakcji, np. blokw komunikatw.
Przykad diagramu kooperacji

- komunikacji

kooperacji - komunikacji
W pierwszym kroku tworzenia diagramu komunikacji naley
okreli jakie obiekty wejd w jego skad, a nastpnie
zdefiniowa zwizki pomidzy nimi.
W kolejnym kroku wprowadzane s symbole (opisy wraz ze
strzakami) komunikatw zapisywane rwnolegle do linii
asocjacji, bd w poziomie.
Strzaka powinna wskazywa kierunek przepywu
komunikatu. Jako ostatni element na diagram nanoszona
jest numeracja kolejnoci komunikatw.

kooperacji komunikacji cd
Po zakoczeniu tworzenia diagramu kady komunikat musi
mie numer swojej kolejnoci, nazw operacji, oraz strzak
ustalajc kierunek przepywu.
W przypadku duej iloci komunikatw pyncych w tym
samym kierunku i pomidzy tymi samymi obiektami
dozwolone jest uywanie jednej strzaki z kilkoma
etykietami. Dodatkowo mona oznacza opisem, bd
typem strzaki, z jakiem rodzajem komunikatu mamy do
czynienia.
Kluczowe czynniki sukcesu

fazy analizy
Zaangaowanie waciwych osb ze strony klienta
Kompleksowe i caociowe podejcie do problemu, nie
koncentrowanie si na partykularnych jego aspektach
Nie unikanie trudnych problemw (bezpieczestwo,
skalowalno, szacunki objtoci i przyrostu danych, itd.)
Zachowanie przyjtych standardw, np. w zakresie notacji
Sprawdzenie poprawnoci i wzajemnej spjnoci modelu
Przejrzysto, logiczny ukad i spjno dokumentacji

analizy obiektowej
Poprawiony dokument opisujcy wymagania
Sownik danych zawierajcy specyfikacj modelu
Dokument opisujcy stworzony model, zawierajcy:
diagram klas
diagram przypadkw uycia
diagramy sekwencji komunikatw (dla wybranych sytuacji)
diagramy stanw (dla wybranych sytuacji)
raport zawierajcy definicje i opisy klas, atrybutw, zwizkw,
metod, itd.
Harmonogram fazy projektowania
Wstpne przypisanie ludzi i zespow do zada
FAZA PROJEKTOWANIA
Metodologie tworzenia i
projektowania SI
S
rne nurty (podejcia):

Strukturalne,
Obiektowe,
Przyrostowe,
Komponentowe,
Aspektowe,
Podejcia do wytwarzania oprogramowania
okrelonej klasy (np.. systemw czasu
rzeczywistego, ekspertowych, zintegrowanych,
etc),
Zalene od przyjtego modelu cyklu ycia
systemu
projektowania SI cd
Podejcie strukturalne - przedmiotem
zainteresowania s elementy systemu,
wzajemne powizania tych elementw, relacje
ktre w nim zachodz; definiowane s
etykiety-obiekty z ktrych system si skada,
strumienie przepywu danych. To podejcie
strukturalne jest w chwili obecnej najczciej,
najchtniej i najskuteczniej stosowane do
praktycznej budowy systemu
informatycznego.
.
projektowania SI cd
Podejcie obiektowe - zakada, e:
procesy informacyjne i struktura w ktrej te procesy
zachodz stanowi pewn cao,
w systemie wyodrbnia si cznie dane i metod w
kategoriach tzw. klas,
Do tych klas trzeba budowa odpowiednie metody danych,
odpowiednie struktury danych, ktre odpowiadaj za
gromadzenie i przetwarzanie informacji a take projektowa
specjalne mechanizmy komunikacji midzy obiektami,
system zbudowany w oparciu o metodologie obiektowa
pozostaje systemem - "obiektem spjnym", mimo e kady z
obiektw ma daleko posunita autonomie i moe by
budowany przez odrbne zespoy programistw,
Ta metodologia pozwala budowa due i zoone systemy
informacyjne w zespoach wieloosobowych (praca grupowa).
Jednak systemy obiektowe s o wiele trudniejsze i bardziej
zoone od systemw strukturalnych.
Projektowanie obiektowe
Etapy projektowania obiektowego:
Znajdowanie obiektw
Identyfikacja klas i obiektw
Skadanie obiektw
Okrelanie agregacji i kompozycji
Konstrukcja systemu
Komunikacja, asocjacje pomidzy obiektami
Rozbudowa systemu
Weryfikacja istniejcej struktury, dodanie nowych pomocnych
klas i obiektw
Wielokrotne wykorzystanie obiektw
METODYKI
SPOECZNE
przykad
Podstawowe zaoenia
metodyki SSM
metodyka spoeczna rozumiana
jako proces zarzdzania
rnorodno ocen sytuacji
problemowej
uyteczno poj systemowych
koncepcja systemu dziaa
ludzkich
metodyka jako systemu zapyta
Koncepcja zarzdzania w ujciu SSM
czas
Cykl uczenia si w metodyce

SSM
Proces stosowania SSM
Wykad 8 24.04.2014
PORWNANIE
METODYK
Rnice midzy metodykami

Podejcia proponowane przez rnych autorw rni si czciowo,
nie musz by jednak ze sob sprzeczne. Nie ma metodyk uniwersalnych.
Analitycy i projektanci wybieraj kombinacj technik i notacji, ktra jest w
danym momencie najbardziej przydatna.
Poszczeglne metodyki zawieraj elementy rzadko wykorzystywane w
praktyce (np. model przepywu danych w OMT).
Notacje proponowane przez rnych autorw nie s koniecznie nierozerwalne z
sam metodyk. Np. notacji UML mona uy dla metodyki Coad/Yourdon.
Narzdzia CASE nie narzucaj metodyki; raczej, okrelaj one tylko notacj.
Twierdzenia, e jakie narzdzie CASE jest oparte na konkretnej metodyce
jest czsto wycznie hasem reklamowym. Nawet najlepsze metodyki i
narzdzia CASE nie s w stanie zapewni jakoci projektw.
Kluczem do dobrego projektu jest zesp dowiadczonych,
zaangaowanych i kompetentnych osb, dla ktrych metodyki, notacje i
narzdzia CASE su jako istotne wspomaganie.
Nowe kierunki rozwoju

metod projektowania
Najwaniejsze kierunki innowacji:
Integracja systemw danych i procesw
Unifikacja funkcji czstkowych systemw
Zwikszanie dostpnoci do bazy danych dla
wszystkich komrek organizacyjnych
Upowszechnienie nowoczesnych sposobw
prezentacji danych (wizualizacji) dla celw
wspomagania ich analizy
Doskonalenie procesw podejmowania decyzji i
ich przekazywania
Zmierzanie do budowy moduowej i otwartoci
caego systemu
Dalsze innowacje ...

Zapewnienie kompleksowego charakteru
funkcjonowania caego systemu (dostpno,
skutecznoci decyzji w caoci)
Stae podnoszenie zaawansowania
merytorycznego i technologicznego (metody
zarzdzania + sam system)
Zmierzanie do osignicia elastycznoci
funkcjonalnej i strukturalnej
Zapewnienie staej zgodnoci ze zmieniajcymi
si elementami otoczenia a zwaszcza stanem
prawnym ewoluujcym zgodnie z przyjtymi
procedurami legislacyjnymi
Bezpieczestwo, poufno, integralno,
hierarchia hase i przywileje dostpu
projektowania SI
S
rne nurty (podejcia):

Strukturalne,
Obiektowe,
Przyrostowe,
Komponentowe,
Aspektowe,
Podejcia do wytwarzania oprogramowania
okrelonej klasy (np.. systemw czasu
rzeczywistego, ekspertowych, zintegrowanych,
etc),
Zalene od przyjtego modelu cyklu ycia
systemu
Dalsze innowacje - wzorce

oprogramowania
wzorce analizy (analysis patterns)
wzorce projektowe (design
patterns)
wzorce architektoniczne
(architecture patterns)
wzorce aplikacji (application
frameworks)
Inne metody projektowania

SI zwizane z cyklu ycia
Metoda Spiralna - zmodyfikowanie tradycyjnej spirali o
wystpowanie przeskokw, dziki temu moemy wraca do
dowolnego punktu jak i przeskoczy niektre etapy.
Teoria Win-Win, ktra gosi, i najlepszy jest proces w ktrym
wszyscy wygrywaj. Naley:
Zidentyfikowa wszystkich
Okreli warunki sukcesu
Negocjowa podczas tworzenia prototypw
Metody Zwinne (agile software development methods) bardziej swobodne od tradycyjnych metody tu ludzie s
waniejsi od sztywnych procedur - Zmniejszenie nacisku
na dokumentacj i formalizacj - Z uytkownikiem
powinno si wsppracowa a nie negocjowa. Waniejsza
jest umiejtno reagowania ni szczegowy i sztywny
plan - Metody te mona stosowa do niewielkich systemw
METODOLOGIE
ZWINNE
Metodyki zwinne
Metodyka Crystal (Crystal family),
Projektowanie zorientowane na waciwoci
(Feature Driven Development - FDD),
Modelowanie zwinne (Agile Modeling),
Programowanie ekstremalne (Extreme
Programming),
Adaptacyjny rozwj oprogramowania
(Adaptive Software Development),
Metodyka scrum (Scrum development),
Prototypowanie (Prototyping methodology),
Szybkie programowanie internetowe
(Internet Speed Development),
Pragmatyczne programowanie (Pragmatic
Programming).
METODOLOGIE
ZWINNE
FDD - FUTURE DRIVEN DEVELOPMENT
FDD (zwinne metodologie) charakterystyka

metodyka tworzenia oprogramowania,
wspomagajca zarzdzanie fazami analiz,
projektowania i konstrukcji oprogramowania
jest projektowaniem zorientowanym na
waciwoci
prace rozpoczynaj si od okrelenia oglnego
modelu systemu.
FDD (zwinne metodologie) charakterystyka

okrelana jest domena projektu i iteracyjnie
dzielona na coraz to mniejsze znaczeniowo
obszary.
kady niepodzielny obszar znaczeniowy jest
opracowywany przez przypisan do niego
grup projektantw, w wyniku czego powstaje
model szczegowy, bdcy skadnikiem
caociowego modelu systemu.
zesp projektantw korzysta z
opracowanych wczeniej wymaga
systemowych i przypadkw uycia.
FDD dobre praktyki IOP
oparcie procesu o wymagania klienta

architektura systemu
krtkie iteracje
indywidualna odpowiedzialno za
kod
inspekcje
FDD role w zespole
Menader projektu
Eksperci dziedzinowi
Gwny architekt
Menader programistw
Gwni programici
Waciciele klas
FDD pojcie cechy
Zasadniczym elementem procesu FDD jest cecha

(feature) produktu.
Cech jest may fragment funkcjonalnoci produktu.
Cecha w SI dostarcza klientowi interesujce go wyniki.
Opisuje wymagania funkcjonalne wg schematu:

<action>the<result><by|of|to|from|for>a(n)<object>
Grupuje si w zbiory cech wg schematu:

<action>-ing<buisness
deliverable><by|of|to|from|for>a(n)<object>
FDD (Feature Driven

Development)
... zosta utworzony pomidzy rokiem 1997 a 1999 w United
Overseas Bank w Singapurze przez zesp, ktremu
przewodzi Jeff De Luca. Zesp ten w swojej pracy bazowa
na materiaach Petera Coada, rwnie czonka zespou, ktry
wprowadzi idee Feature definition i Feature list[1].
[1] David J. Anderson, Eli Schragenheim: Agile Management
for Software Engineering
FDD ...
... opiera si na nastpujcych
zaoeniach:
system sucy budowaniu innych
systemw powinien by skalowalny,
proste procesy s najlepsze,
dobre procesy pozwalaj zespoowi na
skupienie si na wynikach,
krtkie, ukierunkowane na cechy
produktu i iteracyjne cykle s najlepsze.
Feature Driven
Development
... definiuje pi procesw wysokiego
poziomu[1]:
opracowanie oglnego modelu (modelowanie
ksztatu),
zbudowanie listy cech,
plan projektu na podstawie cech,
projektowanie,
wytworzenie.
[1] Stephen Palmer: Feature Driven Development and
Extreme Programming
FDD jest uwaany za dobr

mieszank zasad i
elastycznoci, ktra
stanowi prosty w
wykorzystaniu szkielet dla
projektu.
FDD realizacja metody
zaoeniem jest inkrementacyjne opracowywanie
poszczeglnych funkcjonalnoci systemu

projekt w myl FDD skada si z piciu sekwencyjnie nastpujcych po
sobie etapw.
Opracowanie
oglnego
modelu
Okrelenie
listy
funkcjonalnoci
Planowanie
na
podstawie
funkcjonalnoci
Projektowanie
na
podstawie
funkcjonalnoci
Wykonywanie
w
oparciu o
funkcjonalnoci
FDD faza I
stworzenia zespou projektowego pod kierownictwem Gwnego

Architekta,
przeprowadzenia przegldu dziedziny problemu,
studiowanie dokumentw z wymaganiami i z dziedziny problemu,
przygotowanie alternatywnych modeli w oddzielnych maych grupach
projektowych,
wypracowanie wsplnego modelu,
Zatwierdzenie oglnego modelu,
Zdokumentowanie istotnych zaoe dotyczcych
projektu i alternatywnych rozwiza.
Opracowanie
oglnego
modelu
Okrelenie
listy
funkcjonalnoci
Planowanie
na
podstawie
funkcjonalnoci
Projektowanie
na
podstawie
funkcjonalnoci
Wykonywanie
w
oparciu o
funkcjonalnoci
Opracowanie oglnego
modelu
Krok ten dotyczy zdefiniowania wstpnego
ksztatu projektu. Czonkowie zespou
tworzcego oprogramowanie i udziaowcy
systemu definiuj wsplnie wstpny,
prowizoryczny model tego, co powinno zosta
wytworzone.
Kocowym efektem tego etapu powinien by
model klas zdefiniowany w jzyku UML
FDD faza II
na podstawie specyfikacji wymaga systemowych oraz opracowanego

modelu/modeli opracowywanie s list funkcjonalnoci
Listy maj charakter hierarchiczny i zawieraj funkcjonalnoci gwne
Rozdrabnianie funkcjonalnoci na coraz nisze poziomy
Przegldanie list przez uytkownikw i inwestorw w celu kontroli
poprawnoci i kompletnoci
Opracowanie
oglnego
modelu
Okrelenie
listy
funkcjonalnoci
Planowanie
na
podstawie
funkcjonalnoci
Projektowanie
na
podstawie
funkcjonalnoci
Wykonywanie
w
oparciu o
funkcjonalnoci
Zbudowanie listy cech

Wykorzystujc wiedz zebran w
poprzednim etapie, czonkowie
zespou i udziaowcy opracowuj
moliwie szczegow list
podanych cech systemu.
W procesie tym mog zosta
wykorzystane ju istniejce
dokumenty, na przykad specyfikacje
przypadkw uycia.
FDD faza III
sformowania zespou planujcego

okrelenia kolejnoci implementacji
przypisania zbioru cech gwnym programistom
przypisania klas do programistw
Opracowanie
oglnego
modelu
Okrelenie
listy
funkcjonalnoci
Planowanie
na
podstawie
funkcjonalnoci
Projektowanie
na
podstawie
funkcjonalnoci
Wykonywanie
w
oparciu o
funkcjonalnoci
FDD faza IV
sformowania zespou programistw pod kierunkiem Gwnego

Programisty.
opcjonalnego przegldu dziedziny problemu i studiowania
dokumentw referencyjnych
stworzenia diagramw sekwencji
uszczegowienia modelu obiektowego
zapisania nagwkw klas i metod
inspekcji projektu
Opracowanie
oglnego
modelu
Okrelenie
listy
funkcjonalnoci
Planowanie
na
podstawie
funkcjonalnoci
Projektowanie
na
podstawie
funkcjonalnoci
Wykonywanie
w
oparciu o
funkcjonalnoci
FDD - faza V
implementacja kodu klas

przeprowadzenia inspekcji kodu
testowania jednostkowego
integracji nowego kodu z produktem
Opracowanie
oglnego
modelu
Okrelenie
listy
funkcjonalnoci
Planowanie
na
podstawie
funkcjonalnoci
Projektowanie
na
podstawie
funkcjonalnoci
Wykonywanie
w
oparciu o
funkcjonalnoci
Projektowanie i
wytwarzanie
Szef programistw wybiera ma grup cech, ktre powinny
zosta wytworzone w przecigu nastpnych dwch, trzech
tygodni, a nastpnie identyfikuje klasy zwizane z tymi cechami
oraz osoby, ktre bd nad tymi klasami pracoway.
Zesp, przydzielony do zrealizowania wybranych cech, okrela
szczegowe diagramy sekwencji dla kadej cechy. Nastpnie
osoby odpowiedzialne za dane klasy tworz je i opisuj ich
metody.
Zanim nastpi ostatni etap wytwarzanie, zesp dokonuje
inspekcji projektu. W fazie wytwarzania osoba odpowiedzialna za
klas tworzy jej kod, opracowuje testy pakietw i integruje klas z
pozostaymi elementami systemu. Kierownik zespou podejmuje
decyzj, czy mona dane cechy doda do gwnej wersji aplikacji.
METODOLOGIE
ZWINNE
SCRUM - Taktyka Myna
rdo:
Ken Shwaber Sprawne zarzdzanie projektami metod
SCRUM
Tytu oryginau:
Agile Project Management with SCRUM
http://www.agilealliance.org
Troch historii
pocztek lat 90-tych
Twrcy: Ken Schwaber i Jeff Southerland
Cel: pomoc organizacjom zmagajcym si ze
skomplikowanymi projektami
programistycznymi
... ukierunkowuje organizacj na tworzenie
produktw, ktre maj szans odnie sukces na
rynku. Bez powanych zmian, czsto w przecigu
trzydziestu dni, zespoy s w stanie stworzy
uyteczny i gotw do zademonstrowania
fragment produktu. SCRUM moe zosta
zaimplementowany na pocztku projektu lub
nawet ju w trakcie jego realizacji.
SCRUM
Najbardziej wprowadzajcy w
zakopotanie i paradoksalny
proces do zarzdzania
skomplikowanymi projektami
Ken Shwaber
SCRUM jest ...

... zbiorem wzajemnie powizanych praktyk i zasad, ktre
optymalizuj rodowisko produkcyjne, redukuj nadmiern
biurokracj w organizacji i synchronizuj wymagania rynku z
iteracyjnymi prototypami.
Bazujc na nowoczesnych teoriach zwizanych z kontrol
procesw, SCRUM sprawia, e oprogramowanie moe zosta
skonstruowane w oparciu o dostpne zasoby, mie akceptowaln
jako, a projekt nie przekroczy terminu dostawy.
Co trzydzieci dni, nawet jeli wykorzystywana jest nie do koca
opanowana technologia, klientowi jest dostarczana jaka
funkcjonalno, ktra jest dla niego uyteczna (What is SCRUM:
http://www.controlchaos.com/)
Kiedy stosowa ?
Skomplikowane projekty kiedy
nie mona przewidzie wszystkiego co
moe si przydarzy lub nawet nie
mona ich szczegowo opisa w
momencie powstawania
Klienci nie do koca wiedz czego
potrzebuj
Czsto zmieniajce si wymagania
Co oferuje ?
Oferuje szkielet oraz zestaw zachowa,
ktre utrzymuj wszystko na widoku
Wszystko odbywa si na zdrowym rozsdku
brak nakazw typu: teraz zrb to
Oparty na iteracyjnej, przyrostowej
strukturze procesu -> wybierana jest cz,
ktra stanowi przyrost funkcjonalnoci
Prowadzenie i monitorowanie projektw w
taki sposb aby dostarczy najlepsze
rezultaty
Udogodnienia dla klienta

Nabywca (klient) dostaje po
kawaku (zamknit funkcjonalno)
swj produkt wczesne wdraanie
poszczeglnych kawakw
Nabywca moe powiedzie co
chce aby byo zrobione w
pierwszej kolejnoci
SCRUM - charakterystyka
Istot metody Scrum jest adaptacyjny,
samoorganizujcy si proces wytwarzania
oprogramowania.
Zakada ewolucyjny styl tworzenia
oprogramowania.
Koncentrujc si na zadaniach zarzdzania pozostawia
wolny wybr w wyborze technik prowadzenia prac
programistycznych.
Ewolucyjny styl to generalnie iteracja, a pojedynczy
cykl to w istocie podprojekt kaskadowy skadajcy si z
opracowania wymaga, analizy, projektowania,
kodowania i wdroenia trwajcy nie duej ni 30 dni.
SCRUM - zarzdzanie
Rozpoczcie prac zwizane jest ze
Spotkaniem Planowania Cyklu (Sprint
planning meeting),
Zakoczenie prac z nieformalnym
Spotkaniem Przegldowym (Scrum
Review meeting).
S rwnie Codzienne Spotkania Zespou
projektantw i programistw (Daily Scrum
meeting).
SCRUM - kontrola
Scrum przewiduje czste dziaania zarzdcze

skupiajce si na identyfikowaniu problemw i
przeszkd w pracach inynieryjnych
Bieca samokontrola caego zespou, codzienne

spotkania, (Daily scrum meeting) 15 minut,
1. Co robiem wczoraj?
2. Co bd robi dzisiaj?
3. Co mi przeszkadza w pracy?
W trakcie spotkania omawiane s problemy oraz
planowane s posunicia z nich wynikajce.
SCRUM planowanie cyklu

Spotkanie poprzedzajce rozpoczcie cyklu
organizacja dziaa.
Zdejmowanie cech z rejestru zada.
Stworzenie rejestru zada przebiegu.
Obejmuje wszystkich czonkw zespou (prosiaki i
kurczaki).
Chicken okrelaj cel przebiegu.
Pig ucilaj rejestr zgodnie z okrelonym celem.
Etapy Scrum
Scrum podzielony jest na trzy gwne etapy:
rozpoczcie gry (pregame),
faza produkcji (development phase),
gra na zakoczenie (postgame).
Faza rozpoczcia
Obejmuje czynnoci planowania i opracowania
zarysu architektury systemu (Architecture high
level design).
W trakcie tej fazy wszystkie znane wymagania s
spisywane i opracowywana jest lista wymaga
(Product backlog list).
Lista ta jest otwarta, a zadania do realizacji
dopisywane s do niej w trakcie caego procesu
tworzenia oprogramowania.
Faza rozpoczcia
rdem wymaga s przede wszystkim
uytkownicy, ale rwnie dzia marketingu i
sprzeday, dzia obsugi klienta oraz sam zesp
projektantw-programistw.
Wymaganiom zestawionym na licie przypisywane
s priorytety.
Na podstawie listy opracowywana jest architektura
systemu.
Faza produkcji
Kadorazowo, gdy do listy dopisywane s nowe
wymagania, s one rozpatrywane w ramach
specjalnego spotkania (Design Review Meeting).
Rozpatrywane s rwnie zmiany w architekturze
systemu wynike z wprowadzenia nowych wymaga.
Faza zakoczenia
Finalnie, w ramach oddzielnego spotkania, tworzony
jest podzbir listy wymaga.
Zawarte tam wymagania przeznaczone s do
realizacji w ramach aktualnej iteracji (sprint backlog
list).
Faza zakoczenia projektu

Rozpoczyna si wraz z ustaleniem pomidzy
uytkownikiem a projektantami, e wymagania s
zrealizowane (lista wymaga jest pusta).
System jest przygotowany do instalacji.
W tej fazie wykonywana jest ostateczna integracja
moduw i testowanie, a take przygotowuje si
dokumentacj.
Spotkanie podsumowujce (Scrum Review Meeting omawiane s na nim postpy prac oraz formuowane s
wnioski, nowe wpisy do listy wymaga lub postulowane s
generalne zmiany w architekturze systemu).
SCRUM - dokumentacja
Rejestr zada (Product backlog), tzw. historyjki
klienta (User stories)
Must be
Should be
Nice to have
Rejestr zada przebiegu (Sprint product backlog)

Wykres spalania (Burn down) wykres
pracochonnoci
SCRUM tworzenie rejestru

przebiegu
rozbicie ycze klienta, na elementarne czynnoci
techniczne, konieczne do realizacji analizowanego celu
oszacowanie kadej czynnoci technicznej na koszt
roboczo-godziny potrzebnej do zrealizowania funkcjonalnoci
przyporzdkowanie odpowiednich czynnoci do realizacji
osobom najbardziej kompetentnym do jej wykonania, co
ustala sam zesp, nie kierownik,
zsumowanie wszystkich roboczo-godzin z wszystkich
wybranych czynnoci i sprawdzeniu czy czna ich liczba
przekracza, czy nie zapenia godzin jednego penego cyklu,
dopenienie lub ujecie wybranych czynnoci, by jak najdokadniej zmieci si czasowo w przebiegu jednego cyklu (30 dni).
SCRUM Rejestr zada przebiegu

(pregame)
obejmuje czynnoci planowania i opracowania zarysu
architektury systemu.
W trakcie tej fazy wszystkie znane wymagania s spisywane
i opracowywana jest lista wymaga (Product backlog).
rdem wymaga s przede wszystkim uytkownicy, ale
rwnie dzia marketingu i sprzeday, dzia obsugi klienta
oraz sam zesp projektantw-programistw.
Wymaganiom zestawionym na licie przypisywane s
priorytety.
Na podstawie listy opracowywana jest architektura systemu.
Finalnie, w ramach oddzielnego spotkania, tworzony jest
podzbir listy wymaga.
Ustalany jest cel przebiegu.
SCRUM - dokumentacja
pracochonno
Proces estymacji pracochonnoci polega na
gromadzeniu informacji statystycznej o przebiegu
projektu i wyznaczaniu na ich podstawie kosztu prac.
Kadego dnia aktualizowana jest pozostaa do realizacji
liczba roboczogodzin
Aproksymacja pokazuje
przybliony termin
zakoczenia przebiegu w
odniesieniu do tempa
prac
Aktualizuje si wtedy
rejestr przebiegu.
SCRUM dokumentacja fazy

produkcji
(Product backlog). Lista ta jest otwarta, a zadania do
realizacji dopisywane s do niej w trakcie caego
procesu tworzenia oprogramowania.
(Sprint backlog list). Zawarte tam wymagania s
realizowane w ramach aktualnej iteracji
Rozpatrywane s zmiany w architekturze systemu
wynike z wprowadzenia nowych wymaga.
Kontrola procesu wytwrczego estymacj wykresu
pracochonnoci
Role uczestnikw projektu

ScrumMaster
Waciciel produktu
Zesp
Users
Klient
Managers
Rola Chicken okrelaj cel przebiegu.

Rola Pig ucilaj rejestr zgodnie z
okrelonym celem
Inne osoby
Rola ScrumMaster
ScrumMaster jest liderem, a nie
kierownikiem
Odpowiedzialny za:
Przywdztwo
Prowadzenie
Dostarczanie wskazwek
Uczy zesp metodyki SCRUM
Pomoc wacicielowi produktu w wyborze
najbardziej wartociowych zalegoci produktowych
SPRAWIA EBY SCRUM DZIAAO
ScrumMaster cd.
Usuwanie barier pomidzy projektantami, a
wacicielem produktu tak aby waciciel produktu
bezporednio kierowa rozwojem projektu
Uczenie waciciela produktu maksymalizacji zwrotw
kosztw i speniania swoich celw przy pomocy SCRUM
Poprawa ycia zespou projektujcego poprzez
uatwienie mu pracy twrczej
Poprawa wydajnoci zespou projektowego na
wszelkie moliwe sposoby
Poprawa praktyk inynierskich oraz narzdzi tak, by
kady przyrost funkcjonalnoci by moliwy do wydania
Udostpnianie zaktualizowanych informacji o
postpach zespou wszystkim stronom
Rola Product Owner

Gwarant prac we waciwym
kierunku
Zajmuje si:
Tworzeniem wymaga uytownika
(User stories)
Nadawaniem priorytetw dla wymaga
Budowaniem rejestru wymaga
(Product Backlog)
Rola Waciciel produktu

Reprezentuje interesy kadej z
zainteresowanych stron
Odpowiedzialny za:
Zebranie pocztkowych (oglnych)
wymaga
Przypisywanie priorytetw zadaniom
funkcjonalnym i niefunkcjonalnym
Wybr najbardziej wartociowej
funkcjonalnoci (na pocztku), a
nastpnie nadbudowywanie jej
Rola zespou
Sam organizuje swoj prac

Zbiorowa odpowiedzialno
Moe wybiera zadania do zrealizowania
Moe si podzieli na mniejsze zespoy
Najbardziej optymalny to 7 osb

BRAK INTEGRACJI Z ZEWNTRZ
Scrum wprowadza interesujce narzdzie

zarzdcze jest nim omawiana ju lista wymaga
(produkt backlog list).
Opisuje ona wszystko to, co powinno si znale
w ostatecznej wersji oprogramowania (wedle
aktualnej wiedzy).
W ten sposb lista wymaga opisuje wszystko, co
naley zrobi w projekcie.
Lista zwykle zawiera waciwoci, funkcje, usterki,
defekty, dania rozszerze i dania uaktualnie
technologicznych.
Do zarzdzania list przeznaczony jest

pracownik - Zarzdca Projektu.
On trzyma piecz nad dodawaniem
nowych pozycji do listy, jak
i usuwaniem pozycji gdy s
zrealizowane.
W pragmatyce rozwoju oprogramowania
open source taka lista nosi nazw to
do list.
Na diagramie przebiegu projektu nie

przedstawiono jednego istotnego procesu
biegncego niezalenie od procesw
wytwrczych.
Jest nim estymacja pracochonnoci.
W trakcie caego projektu rwnolegle
z pracami projektowymi
i implementacyjnymi trwa proces oceny
pracochonnoci postulatw zawartych w
licie wymaga.
W pocztkowych fazach projektu oceny te s

zgrubne, lecz w miar gromadzenia informacji z
postpu prac implementacyjnych staj si coraz
bardziej dokadne.
Proces estymacji pracochonnoci polega na
gromadzeniu informacji statystycznych
o przebiegu projektu i wyznaczaniu kosztu prac na
ich podstawie.
Estymacja pracochonnoci nie bierze pod uwag
duych zmian w architekturze systemu lub
uytkowanej technologii.
W przypadku projektu prowadzonego metod Scrum od

pocztku zaleca si by uytkownik wraz z zespoem
projektantw spdzi kilkanacie dni nad opracowaniem
listy wymaga.
Musz si w niej znale zapisy dotyczce zarwno
wymaga biznesowych jak
i technologicznych.
Celem nadrzdnym pierwszej iteracji produkcyjnej jest
pokazanie uytkownikowi jakiego fragmentu
funkcjonalnoci systemu zaimplementowanego
w ramach wybranej technologii.
Naley przewidzie du ilo pracy przy

pierwszej iteracji, bo dochodz tu prace nad
opracowaniem szkieletu systemu, do ktrego
bd dodawane funkcjonalnoci
w ramach kolejnych iteracji.
Pierwsza iteracja produkcyjna rni si od
kolejnych rwnie z tego powodu, e na jej list
wymaga wpisane s takie zadania jak:
zapoznanie si z technikami Scrum, organizacje
zespow Scrum, rozdzia rl
w projekcie.
Dalsze iteracje s prostsze i szybsze.
Kady cykl to w istocie podprojekt

kaskadowy skadajcy si
z opracowania wymaga, analizy,
projektowania, kodowania
i wdroenia trwajcy nie duej ni
30 dni.
SCRUM - przebieg
Czynnoci zarzdcze w fazie

produkcji zasadzaj si na
spotkaniach organizacyjnych.
Rozpoczcie prac zwizane jest ze
Spotkaniem Planowania Cyklu (Sprint
planning meeting),
Zakoczenie prac z nieformalnym
Spotkaniem Przegldowym (Scrum
Review meeting).
S rwnie Codzienne Spotkania
Zespou projektantw i programistw
(Daily Scrum meeting).
Sprinty i spotkania
Rodzaje:
Spotkanie planujce sprint ->
pocztek sprintu
Sprint
Codzienny SCRUM
Przegld sprintu
Retrospektywne spotkanie sprintu
Spotkanie Planowania Cyklu
(Sprint
planning meeting) organizowane jest przez zarzdc
procesu dwukrotnie.
W pierwszym spotkaniu bior udzia uytkownicy, nabywcy,
zarzd i zesp projektantw. Ustala si cele i priorytety
wanie rozpoczynajcej si iteracji. Wymagania wpisuje si
we wspomnian wyej list (Sprint product backlog).
W drugim spotkaniu bior udzia jedynie wykonawcy i
Zarzdca Scrum, ktrzy ustalaj sposb przeprowadzenia prac
przy implementacji wymaga.
Codzienne Spotkania Scrum (Daily

Scrum meeting) s krtkie, najwyej 15 minut,
maj na celu motywowanie personelu oraz
ledzenie postpw prac.
W trakcie spotkania omawiane s problemy
oraz planowane s posunicia z nich
wynikajce.
W spotkaniach uczestniczy zesp
projektantw i programistw oraz zarzdca
Scrum.
Spotkanie podsumowujce
(Scrum Review Meeting) odbywa si
w ostatni dzie trwania iteracji
produkcyjnej (iteracja nie trwa wicej ni
30 dni).
Omawiane s na nim postpy prac oraz
formuowane s wnioski, nowe wpisy do
listy wymaga lub postulowane s
generalne zmiany
w architekturze systemu.
Spotkanie planujce sprint

(max. 8 godzin)
W spotkaniu uczestnicz:
ScrumMaster
Waciciel produktu
Zesp
Dwa etapy:
PIERWSZY (max. 4 godziny)
Wybr co zostanie zrealizowane podczas sprintu
DRUGI (max. 4 godziny)

Rozplanowanie szczegw zadania
Sprint (30 dni)
Pocztek: spotkanie planujce sprint

Codzienny SCRUM (max. 15 minut)
Cel: synchronizacja prac zespou
- ScrumMaster
- Zesp
Odpowiedzi na pytania:
Co zrobie w projekcie od ostatniego spotkania ?
Co planujesz zrobi w projekcie midzy obecn chwil, a
kolejnym spotkaniem ?
Jakie przeszkody stoj na drodze realizacji zaoe
danego sprintu oraz tego projektu ?
Koniec: przegld sprintu
Zalegoci sprintu
Zalegoci sprintu zmienia zesp
Zadania przydzielony czas
wykonania od 4 do 16 godzin
Zadania, ktre wykraczaj poza
ten czas traktowane s jako
nieodpowiednio zdefiniowane.
Zalegoci produktowe
Lista wymaga projektowych o
ustalonych priorytetach wraz szacowanym
czasem zamiany kadego jej elementu na
ukoczon funkcjonalno produktu.
Szacunki wyraa si w dniach i s tym
precyzyjniejsze, im wyej na licie
priorytetw znajduje si dany element
zalegoci produktowych.
Lista ta ewoluuje w kierunku zmian
warunkw biznesowych i technologii.
Zalegoci produktowe
Na licie znajduj si:
Wymagania funkcjonalne
Wymagania niefunkcjonalne
wraz z okreleniem priorytetw

(ustalane wedug wanoci dla klienta
oraz zalenoci)
Przegld sprintu
(max. 4 godziny)
Zesp
ScrumMaster
Waciciel produktu
Ewentualnie udziaowcy
Prezentowanie wykonanych zada oraz

zastanowienie si co powinno by
nastpnie zrealizowane.
Retrospekcja sprintu
(max. 3 godziny)
ScrumMaster
Zesp
Skorygowanie prac zespou tak by

kolejny sprint by bardziej
efektywny i przyjemny
Przebieg SCRUM
Kilka zespow:
Projekt skalowalny.
Pierwszy zesp robi fundament
przygotowuje infrastruktur do pracy
etapowej
Kilka zespow
Przed przystpieniem do prac nowych
zespow musz by ustalone m.in.
Zalegoci funkcjonalne i niefunkcjonalne

Zasady komunikacji
Zasady przechowywania kodu
itd.
Zespoy w projekcie
skalowalnym.
Pojedyncze osoby z pierwszego
zespou doczane s do zespow
jako eksperci
Projekty skalowalne
Scrum Scrumw
Dodatkowe spotkanie
ScrumMaster
Pojedyncze osoby z zespow
Przebieg taki sam jak przy codziennym
SCRUM
Dokumenty w SCRUM
POZIOMO:
Zalegoci produktowe-Pozostae dni

Zalegoci sprintu
PIONOWO:
- Ile pozostao do wykonania
Wykres wypalania
Uywany przy:
- Zalegoci sprintu
- Zalegoci produktowe
Problemy przy wdraaniu

Mao informacji np. dla zarzdu na
temat przebiegu aktualnego SCRUM
Co gdy zarzd wymusza dodatkowe
raporty
Przykad
dodatkowego raportu
Jako typowe rda

marnotrawstwa wskazuje:
nieukoczon prac
Nieukoczone oprogramowanie szybko si
dezaktualizuje i z kadym dniem maleje
prawdopodobiestwo, e kiedykolwiek wejdzie
ono do przemysowej eksploatacji. Do czasu
gdy takie oprogramowanie zostanie
zintegrowane z reszt systemu, pochania ono
zasoby i stwarza ryzyko finansowe.
Minimalizowanie iloci niedokoczonego
oprogramowania, ktre z jakich wzgldw nie
zostao uruchomione jest zarwno
ograniczaniem ryzyka jak i redukcj
marnotrawstwa.
... rda marnotrawstwa:

dodatkowe procesy
Typowym procesem, ktry nie stanowi wartoci dla projektu
jest tworzenie dokumentacji. Zasadnicze pytania w tym
przypadku brzmi czy klient naprawd uwaa
dokumentacj za przydatn i wartociow? Czy jest ona
nam do czego potrzebna? A jeli odpowied na ktre z
nich jest twierdzca naley pamita o tym aby
generowane dokumenty byy krtkie i moliwie oglne.
Dokumentacj na pewno warto tworzy gdy jest kto kto na
ni czeka, na przykad programici, ktrzy oczekuj od
analityka zdefiniowania przypadkw uycia. Ale nawet
wtedy trzeba szuka innych efektywniejszych drg
przekazywania informacji na przykad tworzy testy
akceptacyjne zamiast spisywa wymagania. Naley
rwnie pamita o tym aby dokumentowa szczegy
danej cechy dopiero gdy rozpoczyna si iteracja, w
ktrej ma by ona implementowana.

dodatkowe cechy
Bardzo czsto wydaje si, e dodanie kilku nowych cech do
systemu bdzie z jakich wzgldw korzystne.
Programici maj tendencje do poszerzania systemu o
nowe funkcje choby po to by sprawdzi jak dziaaj.
Niestety takie dziaanie musi by uznane za
marnotrawstwo. Kady fragment kodu w programie
musi przecie zosta napisany, zintegrowany,
przetestowany, a potem musi by utrzymywany. Kady
kawaek kodu podnosi zoono systemu i stanowi
potencjalne miejsce wystpienia bdu.
Z tego punktu widzenia jeli kod nie jest potrzebny na teraz
to jego tworzenie jest trwonieniem zasobw.

przeczanie zada
Obcianie ludzi prac nad kilkoma projektami
jednoczenie jest marnotrawstwem. Za
kadym razem gdy programista przecza
si midzy zadaniami w rnych projektach
traci pewn ilo czasu na przemylenie
sobie tego to co ma do zrobienia i na
wejcie w rytm pracy nad nowym
zadaniem.
Najszybsz drog do ukoczenia dwch
projektw jest zrealizowanie najpierw
jednego projektu, a potem drugiego.
Rwnolega praca skutkuje czstym
przeczaniem si midzy zadaniami, a tym
samym powoduje zmarnowanie duej liczby

oczekiwanie
Jednym z gwnych rde marnotrawienia czasu
jest oczekiwanie na to a co si wydarzy.
Przykadem s tu opnienia w rozpoczciu
projektu, w tworzeniu wymaga czy te w
testowaniu. Opnienia zmniejszaj warto
systemu dla klienta, a do tego redukuj
szybko z jak mona zareagowa na jego
potrzeby.

przemieszczanie
Pierwszym problemem jest przemieszczanie si ludzi. Chodzi
tu o sytuacj, w ktrej programista poszukuje odpowiedzi
na pytanie lub potrzebuje pomocy przy jakim
technicznym problemie. Jeli nie jest w stanie uzyska
jej na miejscu wwczas zmuszony jest do tracenia czasu
na przemieszczanie si w poszukiwaniu osb ktre bd
w stanie mu pomc na przykad przedstawicieli klienta.
Do tego programista traci koncentracj i wybija
si z rytmu pracy. Jest to powane rdo
marnotrawstwa.
Drugi problem to przemieszczanie rozmaitych artefaktw
na przykad dokumentacji. Kade jej przekazanie od
analityka do projektanta, od projektanta do programisty i
od programisty do testera jest potencjalnym rdem
strat - dokumentacja z reguy nie zawiera penej wiedzy
osoby, ktra j przekazuje.

defekty
Ilo strat powodowanych przez defekty jest
zoeniem wpywu defektu na system i
czasu przez jaki defekt pozostawa nie
wykryty. Sposobem na redukcj strat
powodowanych przez defekty jest jak
najszybsze ich wykrywanie. Rozwizaniem
s tu praktyki takie jak testowanie
utworzonego kodu, czste integrowanie i
wczesne przekazywanie kolejnych wyda
systemu do eksploatacji.
Podsumowanie - oglne wymogi

dla metodyk tworzenia SI
Dotychczasowe rozwaania pozwalaj na okrelenie oglnych
wymaga na racjonaln metodyk tworzenia SI
powinna obj cay cykl ycia systemu
pynnych przej pomidzy fazami,
przy
winna obejmowa rnorodne, dostosowane

podejcia, metody, techniki i narzdzia,
do
zapewnieniu
specyfiki
powinna uatwi porozumiewanie si pomidzy rnymi grupami

tworzcymi SI,
powinna by stosunkowo atwa do opanowania i dostosowania do
szerokiej
klasy
problemw
oraz
zawiera
mechanizmy
ewolucyjnoci i modyfikalnoci.
Realizacja prac
PROJEKTOWOWDROENIOWYCH
Wybrane metodyki wdroe ZSI
Wdraanie systemw:
Z roku na rok ronie liczba przedsibiorstw, ktre szukajc metod
na popraw jakoci zarzdzania oraz podniesienia efektywnoci
dziaania, decyduj si na wdroenie systemu informatycznego
wspomagajcego zarzdzanie klasy MRP/ERP.
Duy nacisk w wypadku takiej decyzji kadziony jest na sam wybr
oprogramowania i jego dostawcy.
Troch w cieniu pozostaje samo wdroenie, od ktrego w praktyce
zaley waciwe i zgodne z oczekiwaniami dziaanie systemu.
Wdroenie systemu:
Wdroenie zintegrowanego systemu zarzdzania jest
przedsiwziciem bardzo zoonym.
Stanowi najwiksz inwestycj informatyczn w
przedsibiorstwie w przekroju kosztw, stopnia zoonoci
oraz czasu wdroenia.
Nie jest to jednak operacja tylko techniczna - zakup
komputerw, okablowanie budynku oraz instalacja
oprogramowania.
Ze wzgldu na strategiczne znaczenie tej decyzji dla
przedsibiorstwa wdroenie powinno by procesem
samooceny, analizy, gruntownej zmiany procesw
biznesowych oraz uczenia si.
Czas wdroenia systemu zintegrowanego jest stosunkowo dugi moe

wynosi przecitnie 2 - 3 lata lub duej.
Instalacja samego sprztu, przygotowanie infrastruktury oraz instalacja
podstawowego oprogramowania, jest procesem znacznie krtszym i
trwa okoo szeciu miesicy.
Wdroenie systemu zintegrowanego w przedsibiorstwie nie oznacza
w praktyce poczenia dwch lub wicej dziaw w sie komputerow.
Dziay te bd ostatecznie zintegrowane dopiero wtedy, gdy pojawi si
pomidzy nimi paszczyzna integracji funkcjonalnej i procesowej,
koordynacja stanie si automatyczna, informacje bd dostpne
natychmiast, a wspomniane dziay zaczn ze sob wsppracowa i
traktowa si wzajemnie jako klienci wewntrzni.
Za wdroony mona uzna go dopiero wtedy, kiedy zapewni on
wspprac, koordynacj oraz zintegruje dziaania poszczeglnych
komrek, tak aby wspierajc si, dziaay efektywnie na rzecz realizacji
jednego celu firmy.
11 etapw wdroenia systemu

zintegrowanego wg APICS:
1. Przygotowanie kierownictwa firmy do zarzdzania w warunkach
stosowania systemu komputerowego oraz planowania procesu
wdroeniowego (pierwszy miesic).
2. Okrelenie zamierze oraz wyznaczenie celw komputeryzacji
przedsibiorstwa i wdraania poszczeglnych moduw systemu
(drugi miesic).
3. Szkolenie zespou wdroeniowego w zakresie zasad systemu i
znajomoci moduw skadajcych si na Closed Loop systemu
(2-4 miesic).
4. Inwentaryzacja obecnego otoczenia organizacyjnego, wybr
uytkownikw, zaprojektowanie przyszego otoczenia systemu
(3-6 miesic).
5. Projektowanie Systemu Informowania Kierownictwa w

powizaniu z moduami systemu, projektowanie konfiguracji
sprztowej i programowej (5-6 miesic).
6. Instalowanie komputerw, sieci, stacji roboczych lub terminali,
systemu operacyjnego, oprogramowania systemu (6-9 miesic).
7. Stworzenie tzw. pilota systemu i szkolenie pracownikw z
wykorzystaniem pilota (9-12 miesic).
8. Sukcesywne dostosowanie moduw systemu do codziennej
dziaalnoci przedsibiorstwa i zastpienie dotychczasowego
systemu (12-15 miesic).
9. Przeprowadzenie konwersji zasobw danych i sukcesywne
wdraanie Closed Loop systemu (15-18 miesic).
10. Rozszerzenie stopnia przetwarzania do penego zakresu systemu
(18-24 miesic).
11. Przegld rozwiza po wdroeniu i przeprowadzenie
ewentualnych zmian (20-26 miesic).
Wdroenie systemu
zintegrowanego - reguy
Niezalenie jednak od metodyki w procesie wdroenia wyrni
mona nastpujce, zasadnicze, nastpujce po sobie etapy:
ETAP I - przygotowanie wdroenia
Etap rozpoczynajcy si od powoania zespou wdroeniowego do
momentu wyboru systemu oraz podpisania kontraktu z firm,
ktra bdzie wdraaa system.
ETAP II - organizacja projektu i prototypowanie
Rozpoczyna si on z chwil podpisania kontraktu z dostawc, a
koczy wraz z przygotowaniem prototypu nowego systemu.
ETAP III - wdraanie systemu w komrkach

funkcjonalnych przedsibiorstwa
Etap ten rozpoczyna si zakoczeniem prac nad prototypem, a
koczy, gdy ostatnia objta projektem komrka organizacyjna
rozpocznie prac na nowym systemie.
ETAP IV - integracja systemu oraz
doskonalenie bazy
danych
Pocztkiem tego etapu jest rozpoczcie pracy przez komrki
funkcjonalne wedug nowego systemu, natomiast kocem etapu
i caego wdroenia jest stwierdzenie osignicia zaoonych w
projekcie celw.
Metodyki wdroenia systemu

zintegrowanego (ZSI):
Oprcz przygotowania wdroenia systemu informatycznego
naley zaprojektowa (wzgldnie przeprojektowa) system
zarzdzania przedsibiorstwem.
Takie dziaania wymagaj metodycznego podejcia.
Metodyka wdroenia jest to sformalizowany, szczegowy
opis z podziaem na poszczeglne etapy i czynnoci dziaa
wykonywanych w procesie wdroenia.
Metodyki wdroenia (ZSI)cd

Metodyka obejmuje wszelkie dziaania poczwszy od etapu
przygotowania projektu, a po faz postimplementacyjnego
testowania wdroonego systemu.
W procedurze wdraania systemu najwiksze warto maj:
wiedza, dowiadczenie oraz kompetencje osb
zaangaowanych we wdraanie, metodyka za jest tym
narzdziem, ktre wspomaga i syntetyzuje ich prac.
Metodyka jest planem dziaania, na podstawie ktrego
przebiegaj prace wdroeniowe.
Podstawowym zadaniem metodyki jest uporzdkowanie
oraz usystematyzowanie prac zwizanych z wdroeniem
systemu.

Na potrzeby wdraania zintegrowanych systemw
zarzdzania (ZSI) stworzonych zostao kilka metodyk
wdroeniowych.
Praktycznie kady duy producent i firma wiadczca
usugi wdroeniowe systemw tej klasy dysponuje wasn
metodyk.
W kadej z metodyk wyrnione s fazy dziaania, ktre w
zalenoci od metodyki obejmuj rny zakres czynnoci
wchodzcych w ich skad.
Zalenie od metodyki jest to od trzech do jedenastu faz.
Fazy te mog przebiega sekwencyjnie, nachodzi na
siebie lub by prowadzone rwnolegle.

Kady z producentw (integratorw) posiada take inne
(czsto wasne) narzdzia wspomagajce proces wdroenia
systemu.
adna z metodyk nie gwarantuje udanego oraz
bezproblemowego wdroenia.
Systematyzacja prac wraz z ich podziaem na poszczeglne
czci jest sposobem zapewnienia kontroli nad przebiegiem
wdroenia.
Realizacja ZSI (wdraanie) jako przedsiwzicie

informatyczne
Metodyka
punktw
kontrolnych
(MPK),
stosowana
do
projektowania ZSI obejmuje
obejmuje::
identyfikacj i analiz problemu
okrelenie zadania projektowego
opracowanie zaoe (lub wybr gotowego ZSI)
szczegow koncepcj systemu
projekt techniczny ZSI
oprogramowanie ZSI (lub modyfikacj gotowego ZSI)
przygotowanie przedsibiorstwa do wdroenia
testowanie (wdraanie)
eksploatacja, konserwacja i rozwj systemu

informatyczne
Realizacja ZSI jako przedsiwzicia informatycznego na tle
metodyki punktw kontrolnych (MPK) jest zgodna ze schematem
schematem::
przedsiwzicie informatyczne
Strategia funkcjonowania i rozwoju przedsibiorstwa

Strategia informatyzacji przedsibiorstwa
Identyfikacja i analiza problemu
Restrukturyzacja przedsibiorstwa
Przygotowanie prototypu
Modyfikacja prototypu
Testowanie systemu
MPK
Eksploatacja, konserwacja i rozwj

systemu

informatyczne
Szkolenie
wstpne
Przedsiwzicia
wdroeniowe
Decyzja o informatyzacji
Wybr systemu informatycznego 2

Szkolenie uytkownikw
Powoanie zespou
wdroeniowego
Koncepcja planu wdroenia
Powoanie dziedzinowych
grup wdroeniowych
Okrelenie kierunku i zakresu
dostrojenia systemu
Opracowanie planu wdroenia
Instalacja sprztu i
oprogramowania
Szkolenie informatykw
uytkownika
Utworzenie prbnej bazy
danych
Procedury treningowe
Szkolenie
zespou
dziedzinowego
Szkolenie
uytkownikw
Wstpne
przygotowanie
wdroenia
1
2
31
33
32
34
4
5
8
9
10
11
12
Przygotowanie projektu zmian
13
Wdroenie w obszarach
dziedzinowych
14
Prbna eksploatacja
15
Ocena wdroenia systemu
16
Eksploatacja i doskonalenie
systemu
Szkolenie
zespou
wdroeniowego
17
8
9
Waciwe
przygotowanie
wdroenia
10
11
12
13
14
14
14
Realizacja
wdroenia
15
16
17
Przykad faz wdraania ZSI

(systemu klasy ERP)
Faza Wyboru:
Podczas fazy wyboru, firma definiuje swoje potrzeby oraz
wymagania wobec systemu.
Pozwala to na dokonanie waciwego wyboru jednego z wielu
oferowanych na rynku systemw.
Wybrane rozwizanie powinno w jak najwikszym stopniu
odzwierciedla model biznesowy funkcjonowania firmy.
Oznacza to, e w przedsibiorstwie produkcyjnym wdraa si
system obsugujcy model biznesowy przedsibiorstwa
produkcyjnego a nie np. instytucji finansowej.
Faza Implementacji:
Kady projekt wdroeniowy systemu poprzedzony jest
niezbdnymi pracami analitycznymi.
Analiza procesu biznesowego pozwala na przygotowanie
wytycznych do wprowadzenia zmian. Zastosowanie
zaproponowanych rozwiza pozwala na zmniejszenie kosztw
dziaalnoci i usprawnienie zarzdzania.
Analiza obejmuje rwnie przygotowanie do prac wdroeniowych.
Jest ona podstaw dokonania wyboru waciwego modelu i
opracowania propozycji rozwizania biznesowego.
Faza Implementacji cd
Poza analiz faza Implementacji obejmuje opracowanie
planu wdroenia, konfiguracj optymalnego sprztu i
oprogramowania.
Realizowany jest peen cykl implementacyjny obejmujcy
dostaw i integracj infrastruktury informatycznej z waciw
aplikacj, szkolenia, symulacje.
Zesp wdroeniowy obejmuje pracownikw firmy i
konsultantw i jest odpowiedzialny za projekt, a jego pomylne
zakoczenie jest sukcesem zespou.
Motywacja, odpowiedzialno zespou jest trwaym elementem
kadej metodyki. Jeeli standardowa wersja systemu wraz z
rozwizaniem dla danej brany nie jest wystarczajca, wwczas
podczas trwania tej fazy wykonuje si zadania z fazy
optymalizacji.
Faza Optymalizacji:
W trakcie fazy optymalizacji wykonywane s prace, polegajce

na modyfikacji systemu w zakresie udoskonalenia i
rozszerzenia wykorzystywanych procesw i funkcji o nowe
elementy.
Optymalizacja systemu polegaa take na modyfikacji systemu
w celu likwidacji drobnych bdw, wykrytych podczas
przeprowadzonych symulacji. Bdy te nie byy jednak
krytyczne wobec funkcjonowania systemu.
Metodyka Target Enterprise:

Metodyka ta jest stosowana przy wdroeniu systemu BAAN
IV przez firm Ernst & Young. Skada si ona z nastpujcych
etapw:
1. odwzorowanie,
2. pilota,
3. migracja.
Fazy wdroenia nastpuj kolejno po sobie, forma patnoci
regulowana jest kadorazowo w oparciu o umow.
Metodyka BASIS:
Metodyka ta zostaa opracowana przez amerykask firm SSA
(System Software Associates Inc.) dla potrzeb wdraania systemu
BPCS. Wykorzystywana jest przez firmy ISA oraz Deliotte &
Touche i obejmuje 5 faz:
1. definicja projektu,
2. przygotowanie wdroenia,
3. wykonanie zmian i ich weryfikacj,
4. wdroenie,
5. przegld oraz optymalizacj dziaania systemu.
Fazy projektu 1,2,3 mog czciowo na siebie nachodzi. Kada
faza rozliczana jest oddzielnie w ramach umowy.
Metodyka Implex:
1. Definiowanie projektu
Celem tego etapu jest okrelenie celw projektu, zrozumienie
rodowiska gospodarczego, okrelenie kierunkw usprawnienia firmy
oraz ustanowienia organizacji projektu. Czynnociami wykonywanymi
w pierwszym etapie s m.in. przeprowadzenie narady inicjujcej oraz
ocena istniejcego stanu funkcjonowania firmy.
2. Projektowanie rozwizania
Celem tego etapu jest uzgodnienie i udokumentowanie procesw
gospodarczych firmy, okrelenie priorytetw zmian oraz
przeprojektowanie sposobw dziaania oraz struktury. Czynnociami
wykonywanymi w ramach tego s: prezentacja metody,
udokumentowanie procesw gospodarczych, analiza i wybr
procesw do przeprojektowania oraz ich przeprojektowanie.
Metodyka Implex ..cd

3. Konfiguracja rozwizania
Czynnoci wykonywane w ramach tego etapu:
* utworzenie opisu konfiguracji,
* instalacja rodowiska technicznego,
* utworzenie rodowiska operacyjnego,
* konfiguracja systemu ERP,
* szkolenia czonkw zespou wdroeniowego,
* sprawdzenie oraz kontrola konfiguracji,
* opracowanie wstpnych instrukcji pracy.

4. Wdroenie rozwizania
* wprowadzenie do bazy danych informacji o firmie,
* wykonanie testu pilotaowego systemu,
* szkolenie uytkownikw kocowych systemu,
* wykonanie tzw. testu penoskalowego.

5. Rozruch eksploatacyjny
* przygotowanie uruchomienia,
* przeprowadzenie uruchomienia,
* utworzenie wstpnego planu poprawek i usprawnie.
W metodyce IMPLEX poszczeglne fazy realizowane s na og
kolejno, cho niekiedy mog si pokrywa.
Metodologia wdroenia
wedug QAD:
We wdroeniu uczestnicz zarwno przedstawiciele klienta, jak i
konsultanci QAD.
Po stronie klienta tworzony jest Zesp ds. Projektu, w skad ktrego
wchodz kierownicy poszczeglnych obszarw oraz uytkownicy
kluczowi odpowiedzialni za gwne obszary dziaania
przedsibiorstwa.
Za cao prac odpowiada Kierownik Projektu. Prac Zespou ds.
Projektu koordynuje Komitet Wykonawczy zoony z Kierownikw
Obszarw.
Po stronie QAD Polska pracuje zesp konsultantw
odpowiedzialnych za poszczeglne obszary systemu. Ciaem
nadzorczym projektu jest Komitet Sterujcy zoony z czonkw
zarzdu obu firm oraz kierownikw projektu.
Wybrane metodyki wdroe

systemw:
Fazy
System,
Metodyka
Charakterystyka
Baan IV,
Target
Enterprise
1) Odwzorowanie, 2) Pilota, 3) Migracja.

Fazy odbywaj si kolejno.
BPCS,
BASIS
1) Zdefiniowanie projektu,
2) Przygotowanie wdroenia,
3) Wykonanie zmian i sprawdzenie
systemu,
4) Wdroenie,
5) Przegld dziaania nowego systemu.
Fazy 1, 2 i 3 mog czciowo si
pokrywa.
Faz
y
System,
Metodyka
10
DyNAMICS
Charakterystyka
1) Definicja wdroenia,
2) Prowadzenie wdroenia,
3) Organizacja wdroenia,
4) Projekt funkcjonalny,
5) Projekt szczegowy,
6) Dostosowanie i uzupenienie,
7) Przygotowanie instalacji,
8) Instalacja,
9) Szkolenia,
10) Praca rwnolega.
Wydzielenie nadzoru nad projektem
jako osobna (2) faza.
Fazy
System,
Metodyka
Charakterystyka
Movex,
Implex
1) Definiowanie projektu,
2) Projektowanie rozwizania,
3) Konfiguracja rozwizania,
4) Wdroenie rozwizania,
5) Rozruch eksploatacyjny.
Fazy na og nie pokrywaj si.
MFG/PRO, Q 1) Okrelenie potrzeb,

Advantage
2) Ustalenia I planowanie,
3) Prototyp,
4) Przygotowanie systemw,
5) Realizacja pilota,
6) Wdroenie (szkolenie uytkownikw)
7) Serwis.
Fazy
System,
Metodyka
Charakterystyka
IFS
1) Analiza wdroeniowa,
Applications, 2) Implementacja,
AIM
3) Rozruch systemu.
Fazy przebiegaj sekwencyjnie.
R/3,
Accelerated
SAP
1)
2)
3)
4)
5)
Przygotowanie projektu,
Model biznesowy,
Realizacja,
Ostateczne przygotowanie,
Uruchomienie systemu i
wspomaganie.
Fazy
3
System,
Metodyka
Charakterystyka
R/3,
Method
R/3
1) Planowanie i ocena,
2) Projekt rozwizania i prototyp,
3) Dostawa i przyswajanie.
Integracja metodyki z reinynieri
procesw. Dalszy podzia faz na
etapy.
Podstawowe fazy wdroenia:

definiowanie projektu - po przedstawieniu metodyki i zakresu
projektu Zesp Konsultantw wykonuje opis przedsibiorstwa
(analiza przedwdroeniowa), a kierownik zespou definiuje
szczegowy harmonogram wdroenia, plan wdroenia projektu
oraz kosztorys.
Odbywa si te dostawa zakupionego sprztu oraz instalacja
oprogramowania. Powstae produkty projektu (analiza, budet i
harmonogram) i ewentualne w nich zmiany zatwierdza Komitet
Sterujcy.
Podstawowe fazy wdroenia..cd

modelowanie rozwiza - rozpoczyna si od szkole
uytkownikw kluczowych i administratora.
Kolejny etap podzielony jest na dwa cykle: wypracowanie

koncepcji systemu i pilotowa implementacja.

W pierwszym cyklu (wypracowanie koncepcji systemu )
uzgadniane s sposoby funkcjonowania poszczeglnych
obszarw dziaania przedsibiorstwa po przeniesieniu ich do
systemu.
Po sesji interdyscyplinarnej, w ktrej uczestnicz wszyscy
konsultanci oraz Zesp ds. Projektu, nastpuj spotkania
zespow w poszczeglnych obszarach.
Opracowywany jest prototyp konwersji danych (przeniesienie
danych z dotychczasowego systemu informatycznego) oraz
wykonywany test pilotowy przeniesienia danych (pilotowa
implementacja).

Cykl pierwszy koczy si prezentacj wypracowanej
koncepcji, spisaniem uwag do skorygowania w cyklu drugim
oraz zatwierdzeniem wynikw przez Komitet Sterujcy; moe
pojawi si te konieczno zmodyfikowania czci systemu.
Cykl drugi to pilotowe wprowadzenie w ycie ustalonych
zasad. Efektem jest opracowanie szczegowych procedur
pracy w systemie i rozwizanie ewentualnych problemw.
Koczy si weryfikacj opisw procedur i ich akceptacj przez
Komitet Sterujcy.
Podstawowe fazy wdroenia

kolejne fazy..cd
testy akceptacyjne - tworzone scenariusze testowe maj za
zadanie sprawdzi poprawno implementacji poszczeglnych

procesw biznesowych w systemie. Formalne zatwierdzenie
uruchamianej funkcjonalnoci.
realizacja planu przejcia - ostatni etap wdroenia przed
uruchomieniem systemu rozpoczyna si od weryfikacji
poprawnoci parametryzacji.
Nastpnie przygotowywane s instrukcje stanowiskowe oraz
szkolenia uytkownikw kocowych. Stanowiska pracy s
weryfikowane przez suby informatyczne. Przenoszone s
dane statyczne (klienci, indeksy materiaowe itd.) oraz
dynamiczne (bilans otwarcia, rozrachunki kontrahentw) ze
starego systemu.
Po weryfikacji wprowadzonych danych podejmowana jest
decyzja o rozpoczciu pracy w systemie.

asysta powdroeniowa - konsultanci QAD zapewniaj
wsparcie uytkownikowi a do momentu zamknicia
pierwszego miesica ksigowego. Wdroenie koczy si
audytem powdroeniowym, podpisaniem protokou
zakoczenia projektu oraz przekazaniem do dziau obsugi
serwisowej.
Korzyci z wdroenia
systemu:
7-19% poprawa wydajnoci pracy
do 95% - terminowo dostaw
30-40% - skrcenie czasu powstawania wyrobu
poprawa funkcjonowania magazynw materiaw i produktw,
zmniejszenie zapasw
do 50% - zwikszenie zysku

lepsze wykorzystanie posiadanych mocy produkcyjnych
rwnomierna poda wyrobw finalnych
zmniejszenie zapotrzebowania na kapita obrotowy
Problemy spotykane podczas

wdroe:
problem utosamiania si z projektem
Wdroenie Zintegrowanego Systemu Wspomagania Zarzdzania
jest czsto postrzegane jako zagadnienie informatyczne a nie z
zakresu zarzdzania.
Nic wic dziwnego, e wdroenie, ktrego cel nie zostanie
prawidowo zdefiniowany, praktycznie nie moe zakoczy si
powodzeniem.
Brak zaangaowanie najwyszej kadry kierowniczej jest
najczstszym powodem niepowodzenia wdroenia.

wdroecd
problem zarzdzania projektem
Czsto, zawenie kompetencji grupy wdraajcej w
poczeniu z brakiem dostatecznej woli menederw
przedsibiorstwa, w ktrym odbywa si wdroenie, jest
przyczyn niepowodzenia.
problem wiedzy o standardzie systemu

Do nieznajomoci metodyki zintegrowanych systemw
zarzdzania przyznaje si kilkanacie % informatykw
zatrudnionych w duych polskich przedsibiorstwach.

wdroecd
problem interpretacji
Wykorzystanie w przedsibiorstwie Zintegrowanego Systemu
Wspomagania Zarzdzania, wymaga od kadry kierowniczej
oraz pracownikw szerszego spojrzenia na wykonywan
prac. Brak takiego podejcia moe spowodowa utrat
koordynacji dziaania.
problem anachronicznych managerw

Nowoczesne systemy komputerowego wspomagania
zarzdzania wymagaj odpowiednio elastycznych
menederw.
Sukces wdroenia
zintegrowanego systemu
zarzdzania
Podaje si, i 90% projektw wdroeniowych koczy si po
wyznaczonym terminie i z przekroczonym budetem lub nie
koczy si w ogle.
Niepowodzenie wdroenia odbija si negatywnie na caym
przedsibiorstwie.
Aby wdroenie zakoczyo si sukcesem musz by spenione
nastpujce warunki:
Czynniki sukcesu wdroenia:
1. Klient wybiera system speniajcy wymagania oraz

profesjonalnego Dostawc (kapita, referencje, dowiadczenie,
ludzie, metodyka itd.).
2. Klient posiada zdefiniowany budet. Budet jest na bieco
kontrolowany.
3. Umowa midzy Dostawc a Klientem jest dobrze

skonstruowana. Okrelony jest zakres odpowiedzialnoci
Dostawcy i Klienta, a przez to okrelone s wzajemne
obowizki.
4. Zdefiniowany i udokumentowany jest zakres projektu, cel
projektu, wymagania, potrzeby i oczekiwania Klienta.
Czynniki sukcesu
wdroeniacd
5. Projekt jest prowadzony wedug okrelonej metodyki, ktra
zakada midzy innymi:
- Wyznaczenie zespou wdroeniowego skadajcego si z
pracownikw Dostawcy i Klienta, na czele ktrego stoi
Kierownik Projektu.
- Podzielenie projektu na fazy, etapy, zadania.
- Konsekwentnie przestrzeganie metodyki i harmonogramu
np. dokumentowanie poszczeglnych prac, co pozwala w
por zainterweniowa, w przypadku opnie.
- Zarzdzanie ryzykiem, czyli przewidywanie i ocena
niesprzyjajcych zdarze, wraz z ich eskalacj i okreleniem
sposobw zapobiegania lub zaradzenia im.
Czynniki sukcesu wdroeniacd

6. W Zespole wdroeniowym s najlepsi ludzie:
- Dostawca - zapewnia kompetentnych i dowiadczonych
analitykw, projektantw, programistw, konsultantw.
- Klient - zapewnia najlepszych kompetentnych pracownikw
z wiedz o firmie.
7. Zesp wdroeniowy jest zintegrowany m.in. poprzez:
- Stworzenie dobrej atmosfery pracy.
- Wspln lokalizacj zespou projektowego (to samo
pomieszczenie).
- Wsplne wyjazdy, spotkania integracyjne.
8. Zaangaowanie w projekt pracownikw Dostawcy oraz
Klienta. Motywowanie przez klienta swoich pracownikw,
poprzez np. wynagrodzenie za nadgodziny spdzone przy
projekcie.
Zesp projektowoprojektowo-wdroeniowy
Na jako i powodzenie przedsiwzicia maja wpyw:
struktura i skad zespou projektowo-wdroeniowego
styl pracy kierownika
organizacja biecych dziaa w ramach przedsiwzicia
Zesp projektowo-wdroeniowy powinien posiada nastpujc struktur:
komitet sterujcy
komitet wykonawczy
podzespoy wykonawcze
KOMITET STERUJCY
KOMITET WYKONAWCZY
PODZESPOY WYKONAWCZE
ZESP A
ZESP B
ZESP C
grupy
funkcjonalne
grupy
funkcjonalne
grupy
funkcjonalne
grupy
pomocnicze
grupy
pomocnicze
grupy
pomocnicze
Komitet Sterujcy
To gremium strategicznego zarzdzania caym przedsiwziciem, powoywane po
podpisaniu kontraktu, a w jego skad wchodz
wchodz::
sponsor przedsiwzicia (waciciel biznesowy systemu) - najczciej

czonek
kierownictwa
(zarzdu,
dyrekcji)
informatyzowanego
przedsibiorstwa - koordynator, upowaniony do podejmowania decyzji
dotyczcych zmian organizacyjnych, kontroli terminowoci i zgodnoci z
budetem,
gwny kierownik projektu ze strony wykonawcy (integratora) - projektant
(analityk)
znajcy
system
i
specyfik
informatyzowanego
przedsibiorstwa,
kierownik projektu ze strony informatyzowanego przedsibiorstwa zwykle jeden z kluczowych uytkownikw lub gwny informatyk
odpowiedzialny za koordynacj grup pracownikw oddelegowanych do prac
projektowo--wdroeniowych,
projektowo
dowiadczeni konsultanci zewntrzni - w peni niezaleni wzgldem
realizatora (integratora) systemu,
przedstawiciele uytkownikw kluczowych
Gwne zadania
zadania::
podejmowanie strategicznych decyzji dotyczcych caoci projektu,
zatwierdzanie zakresu i planu realizacji ZSI,
monitorowanie ZSI (analiza raportw kom
kom.. wykonawczego),
rozpatrywanie wnioskw wpywajcych na zakres, terminy i budet
przedsiwzicia,
okresowa ocena i zatwierdzanie rezultatw prac projektowo
projektowo-wdroeniowych,
stymulowanie dziaa zapobiegawczych w sytuacjach kryzysowych
kryzysowych..
Komitet Wykonawczy
To gremium taktycznego zarzdzania caym przedsiwziciem, w jego

skad wchodz
wchodz::
gwny
kierownik
przedsiwzicia
ze
strony
wykonawcy
(integratora) ZSI,
kierownik
przedsiwzicia
ze
strony
informatyzowanego
przedsibiorstwa,
kierownicy dziedzinowi - dowiadczeni wdroeniowcy w zakresie
poszczeglnych moduw funkcjonalnych,
uytkownicy kluczowi (np
(np.. g
g.. ksigowy, g
g.. analityk, specjalista ds
ds..
organizacji i zarzdzania, specjalista informatyk, ...
Komitet Wykonawczy
Gwne zadania
zadania::
przygotowanie planu realizacji ZSI,
ustalenia w zakresie podziau prac i odpowiedzialnoci,
biece zarzdzanie realizacj prac projektowo
projektowo--wdroeniowych,
opracowanie planu dokumentujcego realizacj ZSI (projekt
dziaa, szacowanie czasu i kosztw, podzia zasobw, uycie
technik szczegowych i narzdzi, harmonogramy dziaania i
kontroli),
ustalanie procedury monitorowania wydajnoci i jakoci
prowadzonych prac,
inicjowanie dziaa korygujcych w przypadku zagroe
realizacyjnych,
powoanie i biece koordynowanie prac zespow wykonawczych,
opracowywanie okresowych raportw dokumentujcych stan
zaawansowania dziaa (postp prac w stosunku do punktw
kontrolnych),
Podzespoy Wykonawcze
To gremia (4-6 osobowe) przypisane do moduw funkcjonalnych ZSI, w
jego skad wchodz
wchodz::
analitycy,
projektanci,
konsultanci,
szkoleniowcy,
przyszli uytkownicy moduw
Gwne zadania
zadania::
biece realizowanie przydzielonych zada,
dokumentowanie prowadzonych prac,
okresowe przygotowywanie raportw z realizowanych zda,
Wrd podzespow wykonawczych mona wyrni
wyrni::
grupy funkcjonalne w obszarze zagadnie technicznych, szkolenia
uytkownikw, logistyki, instalacji i testowania, inynierii
systemowej, konserwacji i infrastruktury technicznej
grupy pomocnicze w zakresie finansw, analizy ryzyka i
zapewnienia jakoci, zarzdzania dokumentacj, zasobw ludzkich
ludzkich..
Zbyt dua liczebno grup funkcjonalnych i pomocniczych moe

spowodowa rozbudowanie struktury zarzdzajcej przedsiwziciem
przedsiwziciem..
Std mona wyrni inne rozwizania organizacyjne podzespow
wykonawczych::
wykonawczych
struktura izomorficzna
dokadne odwzorowanie struktury ZSI przez gwne moduy
funkcjonalne
kierownik jest integratorem
pewne zagroenia wystpuj, gdy czci przedsiwzicia
wymagaj rnego czasu realizacji
uczestnicy nie skupiaj si na caoci przedsiwzicia (to rola
kierownika) lecz na swoich obszarach
zesp specjalistw
dua odpowiedzialno kierownika ale ma ma wadz nad
specjalistami (dua kompetencja specjalistw - mniejsza
kierownika)
zesp jest samorzdny - od specjalistw zaley koordynacja
struktura partnerska
may indywidualizm czonkw zespou - decyzje poprzez
wypracowanie wsplnego stanowiska
duy nacisk na twrcze wspdziaanie
zalecana ale trudna ze wzgldu na psychik ludzk - kady
chce by kierownikiem
Wykad 6 10.04.2013
PROCESY KIEROWNICZE
I WYKONAWCZE PRZY
TWORZENIU SI
Procesy kierownicze
Procesy kierownicze
monitorowanie dziaa
dziaa::
odpowiedzialne
za
organizowanie
planowanie przedsiwzicia (cele, wymagania, ograniczenia)

opracowanie harmonogramu
szacowanie kosztw
organizowanie zespow wykonawczych
zarzdzanie jakoci
zarzdzanie ryzykiem
zarzdzanie zmianami
zarzdzanie komunikowaniem si wykonawcw
zarzdzanie kontaktami z kooperantami
kooperantami..
Procesy wykonawcze
Procesy wykonawcze s zwizane z tworzeniem produktw
produktw::
specyfikacja wymaga i ogranicze
analizowanie wymaga i ogranicze
specyfikowanie
systemu
struktury
funkcjonalnej
projektowanie szczegowe
szkolenie uytkownikw
instalowanie systemu
konwersja danych
integrowanie i testowanie systemu
konserwowanie i rozwj systemu
systemu..
realizowanie
ROLA I STYL PRACY

KIEROWNIKA
PROJEKTU
INFORMATYCZNEGO
Rola i styl pracy kierownika

Kompetencje i dowiadczenia kierownika (gwnego jak i podzespow)
determinuj biece funkcjonowanie wykonawcw
wykonawcw..
Postaw kierownika mona okreli przy pomocy stylu jego dziaania
dziaania::
styl autokratyczny
sam podejmuje decyzje i skrupulatnie kontroluje ich wykonanie

dobre rozwizanie w przypadku dowiadczonego i kompetentnego
zespou
styl demoralizuje zesp (brak twrczego zaangaowania)
niebezpieczestwo pominicia istotnego sygnau generowanego przez
otoczenie zespou
sprawdza si przy realizacji rednich i niewielkich przedsiwziciach
o maym ryzyku realizacji
styl totalnej wolnoci
duo swobody przy oglnie zarysowanych celach dziaania

wymaga duej inicjatywy i twrczego dziaania wykonawcw
niebezpieczestwo zagubienia gwnego celu przedsiwzicia
sprawdza si w przypadku niewielkich przedsiwzi o nowatorskim
charakterze wymagajcym kreatywnoci realizatorw
styl demokratyczny
decyzje podejmowane przez kierownika po wysuchaniu wszystkich

sugestii
decyzja uwzgldnia wiele punktw widzenia a decyzje zobowizuj
wszystkich realizatorw
tyrania wikszoci - gin indywidualnoci
dugie czasy decydowania i bdy przy maym dowiadczeniu zespou
ZARZDZANIE
PRZEDSIWZICIEM
INFORMATYCZNYM
Zarzdzanie przedsiwziciem
Organizacja prac oraz sprawno ich
zarzdzania caym procesem realizacyjnym
realizacyjnym..
przebiegu
zaley
od
Proces zarzdzania wymaga zorganizowania caoci dziaa ujtych w

plan zarzdzania (stanowicy ramy dyscyplinujce przedsiwzicie)
zawierajcy m.in
in.:
.:
identyfikacja problemu - majce wpyw na zarzdzanie cele,
wymagania i ograniczenia
okrelenie struktury funkcjonalnej i realizacyjnej ZSI
organizacja przedsiwzicia - scenariusze dziaa, struktura
zespow, role i odpowiedzialno
organizacja dziaa - podzia przedsiwzicia na etapy (fazy),
okrelenie punktw kontrolnych
harmonogram przedsiwzicia - zalenoci midzy dziaaniami,
oszacowanie czasu, punkty kontrolne, wykonawcy
analiza ryzyka - identyfikacja zagroe i sposoby obniania
ryzyka
procedury monitorowania i raportowania
raportowania..
Praktyka wskazuje na konieczno zarzdzania przedsiwziciem na
trzech poziomach
poziomach::
strategicznym
taktycznym
operacyjnym
Okrelenie zada (czynnoci) dla poszczeglnych realizatorw nastpuje
przez ustalenie zakresu odpowiedzialnoci
na
poziomie
strategicznym
uzgadnia
si
zakresy
odpowiedzialnoci
stron
przedsiwzicia
(podpisanie
kontraktu
z
dostawc,
kierownictwem przedsibiorstwa i
ewentualnie stronami trzecimi)
na
poziomie
taktycznym
definiowany
jest
zakres
odpowiedzialnoci za realizacj
kadego z punktw kontrolnych (z
uwzgldnieniem czasu, kosztw,
jakoci i akceptowalnoci przez
przyszego uytkownika)
powstaje
opis
ukazujcy
osoby
odpowiedzialne
za
opracowanie harmonogramu i
monitorowanie prac
na poziomie operacyjnym szczegowo okrela si realizatorw

poszczeglnych dziaa i zakres ich odpowiedzialnoci
CPM - Czas trwania zada
3
. .
1
. .
. .
5
. .
. .
0
. .
. .
4
. .
. .
15
. .
7
. .
10
. .
. .
7,5
. .
. .
4
. .
6
. .
3
. .
. .
10
. .
. .
12,
5
. .
. .
22,
5
. .
. .
5
. .
10
. .
5
. .
. .
30
. .
. .
15
. .
11
CPM - Wyznaczanie EST i EFT

10 14
4
. .
3
0 1
1
. .
10 15
5
. .
10 10
0
. .
5
15 30
15
. .
7
30 40
10
. .
40 47,5
7,5
. .
47,5 51,5
4
. .
6
40 43
3
. .
0 10
10
. .
10 22,5
12,
5
. .
EST5-6 = Max (EFT3-5, EFT4-5) = 30
9
74 79
5
. .
51,5 74
22,
5
. .
10
51,5 81,5
30
. .
81,5 86,5
5
. .
51,5 65,5
15
. .
11
EST8-11 = Max (EFT2-8, EFT6-8, EFT7-8,) = 51,5
CPM - Wyznaczanie LFT i LST

10 14
4
26 30
3
0 1
1
9 10
10 15
5
10 15
10 10
0
10 10
5
15 30
15
15 30
7
30 40
10
30 40
40 47,5
7,5
40 47,5
47,
51,5
5
4
47,5 51,5
40 43
3
48,5 51,5
0 10
10
0 10
10 22,5
12,
5
39 51,5
LFT5-6 = Min (LST6-7, LST6-8) = 40
51,5 74
22,
5
54 76,5
51,5 81,5
30
51,5 81,5
74 79
5
76,5 81,5
10
81,5 86,5
5
81,5 86,5
51,
65,5
5
15
71,5 86,5
11
LFT6-8 = Min (LST8-9, LST8-10, LST8-11,) = 51,5
CPM - Rezerwa czasowa ti
ti = LSTi ESTi
lub
ti = LFTi EFTi
ESTi EFTi
ti
LSTi LFTi
CPM - Rezerwa czasowa ti

t3-5=16
10 14
4
26 30
3
t1-3=9
0 1
1
9 10
10 15
5
10 15
10 10
0
10 10
5
15 30
15
15 30
7
30 40
10
30 40
40 47,5
7,5
40 47,5
t8-9=2,5
47,
51,5
5
4
47,5 51,5
40 43
t6-8=8,5 3
48,5 51,5
0 10
10
0 10
10 22,5
12,
5
39 51,5
t2-8=29
51,5 74
22,
5
54 76,5
51,5 81,5
30
51,5 81,5
74 79
5
t9-10=2,5
76,5 81,5
10
81,5 86,5
5
81,5 86,5
51,
65,5
5
15
71,5 86,5
t8-11=21
11
CPM wyznaczenie cieki

krytycznej (brak rezerwy czasowej
t3-5=16
10 14
4
26 30
3
t1-3=9
0 1
1
9 10
10 15
5
10 15
10 10
0
10 10
5
15 30
15
15 30
7
30 40
10
30 40
40 47,5
7,5
40 47,5
t8-9=2,5
47,
51,5
5
4
47,5 51,5
40 43
t6-8=8,5 3
48,5 51,5
0 10
10
0 10
10 22,5
12,
5
39 51,5
t2-8=29
51,5 74
22,
5
54 76,5
51,5 81,5
30
51,5 81,5
74 79
5
t9-10=2,5
76,5 81,5
10
81,5 86,5
5
81,5 86,5
51,
65,5
5
15
71,5 86,5
t8-11=21
11
CPM - podsumowanie
harmonogramowanie zada polega na sukcesywnym
rozwaaniu czasu rwnolegle (rwnoczenie)
trwajcych zada
zadania wchodzce w skad cieki krytycznej
(zadania krytyczne) nie posiadaj adnej rezerwy
czasowej
jeeli ktrekolwiek zadania krytyczne zostanie
opnione, spowoduje to opnienie czasu realizacji
caego projektu
rezerwa czasowa dla zada nie bdcych krytycznymi
okrela ilo czasu, o ktr zadanie moe zosta
opnione bez konsekwencji dla czasu realizacji
projektu
CPM - Skracanie czasu realizacji

projektu
Istota skracania czasu realizacji projektu
istnieje moliwo zrealizowania zada w czasie
krtszym ni wynikaoby to z aktualnej cieki
krytycznej
szybsza realizacja wybranych zada najczciej
wynika z koniecznoci
wczeniejszego zakoczenia zaplanowanego ju projektu
dotrzymania terminu realizacji w przypadku, gdy zrealizowane
ju zadania zostay zrealizowane z opnieniem
szybsza realizacja projektu wymaga
zastosowania bardziej zaawansowanych technologii
realizacji zada w formie nadgodzin
innych dziaa
2 strategie skracania projektu
maksymalne (moliwe do uzyskania) skrcenie
wymagane (oczekiwane) skrcenie
CPM - Skracanie czasu realizacji

projektu
Zasady i reguy skracania projektu

skracanie projektu mona prowadzi wycznie w odniesieniu
do zada wchodzcych w skad cieki krytycznej
w celu skrcenia projektu konieczna jest identyfikacja cieki
krytycznej
skracanie zada wymaga zgromadzenia dodatkowych informacji
normalny czas i koszt realizacji zada
moliwy czas skrcenia zada
inny sposb realizacji zadania
koszt skrcenia poszczeglnych zada
zatrudnienie dodatkowego pracownika
wynajcie/zakup dodatkowego sprztu
zastosowanie innej technologii

CPM - Jednostkowy koszt skrcenia

koszt przypadajcy na jednostk
czasu
[z/godz.]
[z/dzie]
[z/miesic] .
ks kn
kj
tn ts
gdzie:
tn czas normalny
ts czas skrcenia
kn koszt normalny
ks koszt w czasie skrcenia
koszt
k
s
k
n
czas
realizacji
CPM - Algorytm skracania czasu

realizacji projektu
(1) okrel wszystkie moliwe sekwencje zada
(2) okrel minimalny czas realizacji projektu (okrel ciek krytyczn)
(3) okrel normalny koszt realizacji projektu (suma kosztw realizacji
wszystkich przewidzianych zada)
(4) okrel jednostkowy kosztw skrcenia kadego z zada
(5) uszereguj zadania nalece do cieki krytycznej od najtaszej do
najdroszej
(6) sukcesywnie skracaj czas trwania operacji znajdujcych si na ciece
krytycznej,
rozpocznij od skracania zadania powodujcego najmniejszy
jednostkowy przyrost dodatkowych kosztw
zakocz na zadaniu, ktrego skrcenie najbardziej podnosi koszt
projektu
przy kadym skrceniu zadania sprawd, czy nie powstaje nowa
cieka krytyczna
kontynuuj krok 6 do chwili
maksymalnego skrcenia projektu
uzyskania oczekiwanego (podanego) skrcenia
Program Evaluation and Review

Technique (PERT)
Wykorzystywana do szacowania czasu
trwania projektw, kiedy wystpuje duy
element niepewnoci
Wykorzystuje metody probabilistyczne, bazuje
na optymistycznym, najbardziej
prawdopodobnym i pesymistycznym czasie
trwania projektu
Wady: dodatkowa praca (3 szacowania na
czynno), s lepsze metody -> rzadko
uywana w praktyce
PERT
Podstawowe zaoenia metody PERT
metoda CPM zakada dostpno dokadnej informacji
na temat czasu realizacji poszczeglnych zada
brak dokadnej informacji o czasie trwania
poszczeglnych zada skania do oszacowania tego
czasu
dowiadczony meneder jest wstanie okreli
przedzia czasu realizacji poszczeglnych czynnoci
(estymaty czasu)
najwczeniej jak to tylko moliwe (czas optymistyczny) a
spodziewany czas zakoczenia (czas najbardziej
prawdopodobny) m
najpniej jak to tylko moliwe (czas pesymistyczny) b
PERT
czas trwania kadego zadania oszacowany jest za
pomoc oczekiwanego czasu ti oraz wariancji vi i
odchylenie standardowego i
Oczekiwany czas realizacji zadania
a 4mi bi
ti i
6
Wariancja czasu realizacji
vi
bi ai
36
Odchylenie standardowe
vi
PERT
Oczekiwany (redni) czas realizacji zada znajdujcych
si na dowolnej ciece schematu zalenoci obliczany
jest jako suma oczekiwanych czasw realizacji tych
zada ti
Wariancja czasu realizacji zada znajdujcych si na
dowolnej ciece stanowi sum wariancji tych zada
zakada si, e zadania

wchodzce w skad
cieki s wzajemnie
niezalene
cieka krytyczna w metodzie PERT jest tak
PERT
PERT weighted average =
8 workdays + 4 X 10 workdays + 24 workdays
days
6
= 12
Crytical Chain Scheduling

(acuch krytyczny)
Dotyczy tego czy wyrobimy si w czasie czy nie
Bierze pod uwag ograniczone zasoby i
wprowadza bufor w celu zapewnienia
zakoczenia projektu na czas
Zakada, e zadania nie s wykonywane w
multitaskingu, poniewa to czsto wydua
czas
Przykad multitaskingu
Bufor i acuch krytyczny

Wane prawa:
Marphyego: jeeli co ma pj le, pjdzie le
Parkinsona: praca si rozszerza, eby wypeni cay
dostpny czas
Bufor - dodatkowy czas na wykonanie zadania

Usuwamy bufor z poszczeglnych czynnoci,
gdzie nie potrzeba i w zamian:
Dodajemy go na koniec przed dat zakoczenia
projektu
Dodajemy przed zadaniami na ciece krytycznej
Przykad metody krytycznego

acucha
Ktr metod wybra?

Zaley od: rozmiaru projektu, ryzyka,
zoonoci
Gantt
Mniejsze, mniej zoone projekty
CPM (cieka krytyczna)

rednia wielko/zoono/ryzyko
PERT
Wysokie ryzyko
rednia wysoka zoono
Skracanie czasu trwania projektu

Skracanie czasu trwania czynnoci krytycznych
Dodanie wicej zasobw
Zmian ich zakresu
Crashing - najwiksze skrcenie

harmonogramu przy najmniejszym wzrocie
kosztw
Fast tracking - wykonywanie zada
rwnolegle lub tak, eby nachodziy na siebie
Crashing i Fast Tracking

Original
schedule
Shortened
duration thru
crashing
Overlapped
Tasks or fast
tracking
Kontrola harmonogramu
Testy: na ile realistyczny jest nasz
harmonogram
Nie wyklucza moliwoci wydarzenia si
czego nieprzewidzianego
Nie zakada, e kady bdzie pracowa na
100% wydajnoci przez cay czas
Opracowa plan zmian harmonogramu
I co nam z tego wyszo?
Podsumowanie
Pytania i odpowiedzi
jak dugo bdzie trwa i ile bdzie kosztowa projekt,
czy posiadamy ludzi, sprzt, wyposaenie i materiay do
realizacji projektu,
ktre fazy i zadania w caym projekcie s krytyczne,
jaki jest wpyw rnych scenariuszy biznesowych,
jaki jest najlepszy wariant organizacyjny
przedsiwzicia,
jak dokumentowa prac,
jak zapewni monitorowanie projektu.
Podsumowanie cd..
W fazie realizacji projektu naley:
wiedzie czy projekt realizowany jest zgodnie z planem
(zakres, harmonogram, budet),
umie oceni jakie s konsekwencje zaobserwowanych
odchyle od planu biznesowego,
ustawicznie oszacowywa i planowa pozostay zakres
prac,
sporzdzi szczegowe plany realizacyjne na najbliszy
nadchodzcy okres (cykle tygodniowe)
Podsumowanie cd..
Narzdzie powinno pozwala na:
prognoz czasu trwania i kosztw realizacji,

identyfikacj zada krytycznych,
analiz wykorzystanych zasobw oraz ich bilansowanie,
sporzdzanie harmonogramw (pracy, zatrudnienia,
zuycia materiaw, etc.),
analiz rnych scenariuszy zdarze i analiz wraliwoci
projektu,
monitorowanie przedsiwzicia, kontrolowanie
zaawansowania czasowego, rzeczowego,
wszechstronn ocen planu, w tym odchyle,
Podsumowanie
Narzdzie powinno pozwala na:
podjecie dziaa korygujcych, np.: modyfikacja
struktury projektowej,
wspomaganie pracy grupowej (poczta elektroniczna,
www, wsplne raporty, etc),
usprawnienie systemu komunikacji poprzez przesyanie
drog elektroniczn wiadomoci, raportw,
uzyskiwanie pomocy, porad i objanie, komunikatw i
przypomnie w kadym okresie pracy,
swobodn wymian informacji z innymi aplikacjami.
Podsumowanie cd..
Kolejne kroki:
okrelenie i analiza wymaga,
zbudowanie planu,
definicja zakresu,
planowanie zasobw (kto i czym),
definiowanie zada (co),
przydzielenie zasobw,
szacowanie czasu zada (jak dugo),
definiowanie zalenoci,
szacowanie kosztw (za ile),
budowa harmonogramu (na kiedy),
budetowanie kosztw (za ile, na kiedy),
budowa planu projektu.
Podsumowanie cd..
Jakie dane wprowadzi:
termin rozpoczcia projektu,

wszystkie wane zadania,
szacowany czas trwania zada,
przydzielone zasoby,
zalenoci pomidzy zadaniami,
znane ograniczenia, lokalizujc je w czasie i przypisujc
do zada,
definicja ostatecznych terminw dla zada,
kalendarz projektu oraz kalendarze zasobw i zada,
plan bazowy,
dane o rzeczywistym stanie zadania.
Zarzdzanie na poziomie strategicznym dotyczy
dotyczy::
zdefiniowania celw przedsiwzicia
ustalenie zakresu koniecznej restrukturyzacji
okrelenie zapotrzebowania na niezbdne zasoby (finanse, sprzt,
ludzie, technologie)
ustalenie zasad planowania, organizacji i kontroli
Cele przedsiwzicia definiuje si na bazie celw gospodarczych
obiektu z wykorzystaniem cech SMART
SMART::
specyficzne (specific) - uwzgldniaj elementy specyficzne dla
obiektu np
np.. rozwizania organizacyjno
organizacyjno--techniczne, procesy
produkcyjne, stosowane technologie
mierzalne (measurable) - pozwalaj na jednoznaczne okrelenie
osignicia celu np
np.. redukcja kosztw, skrcenie czasu realizacji
produkcji, zmniejszenie zapasw
akceptowalne (acceptable) - akceptowalne przez wszystkich
zainteresowanych
realistyczne (realistic) - osigane w rozsdnym czasie przy
okrelonych nakadach
uwarunkowane czasowo (time
me--related) - okrelaj, co i kiedy ma by
zrealizowane..
zrealizowane
Zarzdzanie na poziomie taktycznym opiera si o tzw
tzw.. punkty
kontrolne (kamienie milowe), okrelajce efekty osigane w kolejnych
krokach dziaania
dziaania..
Planowanie na tym poziomie dotyczy
dotyczy::
zdefiniowania punktw kontrolnych i ich wzajemnych zalenoci
ustalenie organizacji i przebiegu prac
okrelenie odpowiedzialnoci w osiganiu punktw kontrolnych
ustalenie zasad obiegu informacji wrd realizatorw prac
projektowo--wdroeniowych
projektowo
wdroeniowych..
To stany, ktre maj by osignite (przez ktre musi przej cae
przedsiwzicie). Okrelaj co naley osign a nie jak.
Podstawowe cechy tych punktw:
jednoznaczno i obiektywizm sformuowania
realizm
mierzalno oparta na kontrolowanych kryteriach
Poziom
strategiczny taktyczny operacyjny
Wyszczeglnienie dziaa
Zdefiniowanie celw przedsiwzicia
Ustalenie
zakresu
przedsibiorstwa
Okrelenie
zasoby
restrukturyzacji
zapotrzebowania
na
konieczne
Ustalenie zasad planowania, organizowania i

kontroli prac
Zdefiniowanie punktw
wspzalenoci
kontrolnych
ich
Ustalenie organizacji i przebiegu prac

Okrelenie odpowiedzialnoci
punktw kontrolnych
Ustalenie zasad
realizatorw prac
obiegu
osiganiu
informacji
Zdefiniowanie dziaa szczegowych

osignicia punktw kontrolnych
wrd
dla
Ustalenie zespow wykonawczych

Imienny przydzia wykonawcw do zada
Oszacowanie koniecznych zasobw
Okrelenie czasu realizacji prac i ich cieki
krytycznej
MONITOROWANIE
POSTPU PRAC
Monitorowanie postpu prac

Monitorowanie (realizowane zwykle na poziomie taktycznym
operacyjnym) odbywa si przez
przez::
porwnanie planw z realnymi dokonaniami (ocena postpu prac)
identyfikowanie odchyle od planu
podejmowanie dziaa korygujcych
poziom taktyczny
modyfikacje
rezultaty planu
efekty dziaa
CO OSIGN
plan punktw kontrolnych
plan odpowiedzialnoci
CO OSIGN
plan dziaa
zakres odpowiedzialnoci dziaania
modyfikacje
poziom operacyjny
organizacja
przedsiwzicia
organizacja dziaa
Monitorowanie postpu prac

Aby moliwe byo biece monitorowanie dziaa i podejmowanie
ewentualnych krokw profilaktycznych w przypadku zagroe
konieczna jest skrupulatne dokumentowanie caej dziaalnoci
dziaalnoci..
Dokumentacja taka musi obejmowa
obejmowa::
zatwierdzone wymagania i oczekiwania uytkownikw
wzgldem realizowanego systemu
konieczne zmiany organizacyjne w ramach restrukturyzacji
przedsibiorstwa
przyjt do realizacji koncepcja systemu
ewentualnie pojawiajce si na bieco zmiany uytkownikw
w odniesieniu do wczeniej przyjtych ustale
plan prac projektowo
projektowo--wdroeniowych
dokumentacj uytkow (wraz z ewentualnymi zmianami)
dokumentacj eksploatacyjn (wraz z ewentualnymi
zmianami)
materiay szkoleniowe
szkoleniowe..
PRACA ZESPOOWA
Praca zespoowa
Zwikszenie efektywnoci pracy zespou jest

wpywajcym na zarzdzanie przedsiwziciem.
przedsiwziciem.
czynnikiem
Rozwizaniem moe by koncepcja pracy zespoowej wspomagana

odpowiednim instrumentarium informatycznym
Gwne przesanki stosowania tej koncepcji
koncepcji::
skrcenie czasu
realizacji
przez
zwielokrotnienie
wydajnoci pracy - zadania mog by realizowane
rwnolegle przez czonkw zespou
wzmocnienie indywidualnego potencjau twrczego czonkowie zespou uzupeniaj si i dynamizuj swj
potencja twrczy
podniesienie jakoci produktw zespou na wyszy poziom dziki wypracowanym przez zesp procedurom i
odpowiednie metody dziaania wzrasta poziom jakoci
produktw pracy zespou
zespou..
Praca zespoowa
Bdc w rnych miejscach

wszyscy komunikuj si w tym
samym
czasie
np.chat
internetowy, wideokonferencja,
...
tzw. dystrybucja synchroniczna
Wszyscy komunikuj si w tym

samym miejscu i czasie np.
podczas narady.
Potrzebuj tyle narzdzi do
komunikowania
si,
co
do
wyszukiwania i prezentowania
danych
w ukadzie twarz w
twarz
Praca w ramach zespou

odbywa si niezalenie od
fizycznej obecnoci czy czasu.
Typowa praca zespoowa
Dane (pliki, informacje) dostpne

s w jednym miejscu, do ktrego
maj dostp w rnym czasie
czonkowie zespou.
tzw. dystrybucja asynchroniczna
3
Miejsce
Obecnie najczciej wykorzystywane

systemy informacyjne w dziedzinie ekonomii
i zarzdzania ukierunkowane s gwnie
na usprawnianie zarzdzania w celu lepszego
zaspokajania potrzeb wszystkich
uczestnikw procesw gospodarczych.
Interpretacja
wskanikw
Podejmowanie
decyzji
Gromadzenie
danych
Proste
kierowanie
nakazowe
Obiekt ekonomiczny
Strategia ekonomiczna
Najwaniejsze kierunki
innowacji wprowadzanych w
SI oparte s na:
integracji systemw, danych i procesw,
unifikacji funkcji czstkowych systemw,
zwikszania dostpnoci do bazy danych
dla wszystkich komrek organizacyjnych,
upowszechniania nowoczesnych sposobw
prezentacji danych (wizualizacji) dla
celw wspomagania ich analizy,
doskonalenia procesw podejmowania
decyzji
i ich przekazywania,
zmierzania do budowy moduowej i
otwartoci caego systemu,
Dalsze wymagania dotyczce

projektowanego systemu
zapewnienia kompleksowego
charakteru funkcjonalnego caego
systemu,
staego podnoszenia zaawansowania
merytorycznego i technologicznego,
zmierzania do elastycznoci
funkcjonalnej
i strukturalnej,
zapewnienia staej zgodnoci ze
zmieniajcymi si elementami otoczenia
systemowego, a zwaszcza z aktualnym
stanem prawnym, ewoluujcym zgodnie z
przyjtymi procedurami legislacyjnymi.
Oglne zalecenia dla SI

Ekonomiczne systemy informacyjne s
projektowane i realizowane w taki sposb, aby
dane przetwarzane przez w system byy
bezpieczne i na kadym jego etapie chronione.
Dlatego te w jak najwikszym stopniu musi by
zapewniona poufno i integralno wszelkich
danych posiadanych przez system, a dostpno
do danych zawartych w systemie powinna by
zgodna z przyjt hierarchi hase i przywilejw
dostpu.
Najnowsze trendy projektowe

Najnowsze prace odwoujce si
do inynierii oprogramowania
przewiduj wystpowanie a
12 faz procesu projektowego.
1.Inicjalizacja systemu i wstpne

planowanie:
Znalezienie potencjalnego obszaru zastosowania
systemu informatycznego, ktry wspomoe lub
zastpi dotychczasowe metody przetwarzania
informacji.
2.Analiza wymaga i specyfikacja

wymaga:
Identyfikacja problemw, ktre nowy system
informacyjny ma rozwiza. Zarysowanie
waciwoci operacyjnych systemu, wydajnoci
i zasobw sprztowych niezbdnych do
uytkowania i konserwowania systemu.
3. Specyfikacja funkcjonalna
i prototypowanie:
Identyfikacja i formalizacja obiektw oblicze, ich
atrybutw i zalenoci. Specyfikacja transformacji,
ktrym obiekty bd podlega.
4. Dekompozycja problemu:
Podzia systemu na logiczne podsystemy na
podstawie wymaga i specyfikacji. Analiza
logicznych podsystemw pod ktem uycia ju
istniejcych komponentw informatycznych.
Selekcja rozwiza: wykona samodzielnie, kupi,
wykorzysta ju istniejce.
5. Projekt architekturalny i specyfikacja

konfiguracji:
Okrelenie zalenoci pomidzy podsystemami,
komponentami i moduami w sposb uwzgldniajcy
szczegy ich budowy i wymagania wobec nich.
6. Szczegowe projektowanie i specyfikacja
komponentw:
Opracowanie i kodyfikowanie metod przetwarzania
informacji w komponentach.
7. Implementacja komponentw i usuwanie

bdw:
Wytwarzanie kodu rdowego komponentw na
podstawie uprzednich specyfikacji. Testowanie
podstawowych funkcji komponentw.
8. Asemblacja systemu i testowanie:
Weryfikacja komponentw pod ktem kompletnoci
i zgodnoci ze specyfikacj. Asemblacja produktu
z komponentw, weryfikacja wydajnoci
podsystemw systemu jako caoci.
9. Przegld dokumentacji i dostarczenie

systemu:
Opracowywanie i systematyzowanie
dokumentacji powstaej w trakcie prowadzenia
projektu pod ktem raportw dla odbiorcy.
10. Opracowanie procedur instalacyjnych
i instalacja:
Opracowanie dokumentacji instalacyjnej
opisujcej sposb instalacji systemu.
11. Szkolenie dla uytkownikw:

Zapoznanie uytkownikw z systemem.
Zapoznanie ich z moliwociami i
ograniczeniami systemu.
12. Uytkowanie i konserwacja
oprogramowania:
Uytkowanie, usuwanie bdw dostrzeonych
w trakcie uytkowania, rozbudowywanie
systemu o nowe waciwoci, poprawa
wydajnoci systemu.
Jednak nawet najlepsza metodologia nie zabezpiecza

przed bdami, bo istnieje luka poznawcza w
projektach informatycznych
Stopie szczegowoci prac
Sposb wnioskowania
Procesy
makro
Luka
poznawcza
Procesy
mikro
Od ogu
do szczegu
Prace analityczne
i projektowe
Dedukcyjne prace
analityczne i projektowe
o duym stopniu oglnoci
Eksperyment lub
symulacja
lub ?
Od szczegu
do ogu
Problemy na tym poziomie umykaj

zespoom analitycznym i projektowym
na skutek natoku szczegw
Na tym poziomie problemy staj si

zbyt oglne dla zespow projektowych
zajmujcych si zagadnieniami podstawowymi
Indukcyjne prace
analityczne i projektowe
dotyczce problemw
szczegowych
JAKO OPROGRAMOWANIA
Jako specyfikacji wymaga

Jest rezultatem:
analizy
sformuowania wymaga jakociowych
przedoonych przez uytkownika
(waciciela biznesowego),
wyboru metodyki (sposobu) realizacji fazy analizy i definicji,
posiadanych kwalifikacji przez zesp analitykw,
posiadanych narzdzi wykorzystywanych na etapie specyfikacji
wymaga i analizy.
WSKANIKI
JAKOCIOWE
WYMAGANIA
TECHNIKI
WYMAGANIA
JAKOCIOWE
OGRANICZENIA
REALIZACJA
PROCESU
DEFINICJI
ROZWIZANIE
OPROGRAMOWANIE
NARZDZIOWE
JAKO SPECYFIKACJI
WYMAGA I ANALIZY
ISTNIEJCE
SYSTEMY
PODOBNE
WIEDZA
ZESPOU
KSZTATOWANIE
JAKOCI
Jako projektowa
Jest rezultatem:
sformuowania wymaga jakociowych zawartych w wymaganiach
specyfikacji wymaga),
wyboru sposobu realizacji procesu projektowania,
posiadanych kwalifikacji przez zesp projektowego,
posiadanych narzdzi wykorzystywanych w etapie projektowania.
WSKANIKI
JAKOCIOWE
WYMAGANIA
KONSTRUKCYJNE
JAKO
SPECYFIKACJI
WYMAGA I
ANALIZY
REALIZACJA
PROCESU
DEFINICJI
WYMAGANIA
JAKOCIOWE
TECHNOLOGIA
PROCESU
PROJEKTOWANIA
OPROGRAMOWANIE
NARZDZIOWE
ISTNIEJCE
SYSTEMY
PODOBNE
OGRANICZENIA
WIEDZA
ZESPOU
PROJEKTANTW
ROZWIZANIE
FUNKCJONALNOFUNKCJONALNOKONSTRUKCYJNE
KSZTATOWANIE
JAKOCI
PROJEKTOWEJ
TECHNOLOGIE
PRZETWARZANIA
JAKO PROJEKTOWA
(w
Jako potencjalna
Jest rezultatem:
zmian w rozwizaniach konstrukcyjnych zachodzcych w procesie
produkcji oprogramowania i testowania,
jakoci zastosowanych elementw programowych i materiaowych,
wyboru technologii produkcji oprogramowania.
ROZWIZANIA
PROJEKTOWE
JAKOC
PROJEKTOWA
OPROGRAMOWANIE
NARZDZIOWE
REALIZACJA
PROCESU
PRODUKCYJNEGO
JAKO POTENCJALNA
TECHNOLOGIA
PROGRAMOWANIA
KSZTATOWANIE
JAKOCI
POTENCJALNEJ
Jako eksploatacyjna
Jest rezultatem:
wyboru procesu eksploatacji,
poziomu jakoci potencjalnej,
wyboru warunkw eksploatacji,
postawionych wymaga eksploatacyjnych.
WARUNKI
EKSPLOATACJI
WYMAGANIA
JAKOC
POTENCJALNA
PROCES
EKSPLOATACJI
JAKO EKSPLOATACYJNA
KSZTATOWANIE
JAKOCI
EKSPLOATACYJNEJ
Jak mierzy si jako

oprogramowania?
Proces
programowy
og czynnoci
zwizanych z
wytwarzaniem
oprogramowania, w
celu uwiarygodnienia
przed klientem
dojrzaoci
kompetencyjnej
Miary organizacji
(procesu)
Przedsiwzicie
informatyczne
w celu lepszej estymacji
czasu i kosztu, kontroli
jakoci realizowanych
zada, oceny
produktywnoci i,
oglnie, poddawane s
kontroli przedsiwzicia
Miary przedsiwzicia
(projektu
Produkt
programowy
zarwno jego jako,
jak rwnie inne,
niejakociowe cechy
produktu
Miary programw jako
produktw
Miary oprogramowania
Miary
procesu
programowego
Mog by uyte do
poprawy produkcji i
serwisu
oprogramowania
Miary projektu
Opisuj cechy
charakterystyczne i dziaanie
projektu
Miary produktu
Opisuj cechy produktu
Niektre
miary mona
zaliczy do
kilku kategorii
jednoczenie
Wybrane miary procesw

wytwarzania oprogramowania
Proces
programowy
og czynnoci
zwizanych z
wytwarzaniem
oprogramowania, w
przed klientem
dojrzaoci
kompetencyjnej
Miary organizacji
Przedsiwzicie
informatyczne
og czynnoci
kontrolnych w celu
lepszej estymacji czasu
i kosztu, jakoci
realizowanych zada,
oceny produktywnoci
Miary przedsiwzi
Produkt
programowy
og czynnoci
zwizanych z jakoci
produktu, i inne
niejakociowe jego
cechy
Miary programw jako
produktw
procesu wytwarzania
oprogramowania
Metryki
Wpyw rnych czynnikw na

proces wytwarzania
oprogramowania
Czynniki ekonomiczne,
organizacyjne, prawne,
spoeczne, itp
Integralno
rozwiza
Bezpieczestwo
rozwiza
Niezawodno
oprogramowania
Inne metryki
oprogramowania
Celowo, zakres
przedsiwzicia
czynniki funkcjonalne
Zgodno
rozwiza z
warunkami
procesu
wytwarzania
oprogramowan
ia
czynniki techniczne
Pomiar procesw programowych

pozwala oceni sposb realizacji (dojrzao) procesu
programowego (jako caoci)
pozwala na wyrnienie tych procesw gwnych, ktre
realizowane s poprawnie, i tych ktre nie s
miary procesu powinny by zbierane z wielu
przedsiwzi i urednione z duszego okresu czasu
wysoka ocena dojrzaoci uatwia przekonanie klienta,
e organizacja jest w stanie dostarczy
oprogramowanie na czas, w ramach budetu, o dobrej
jakoci
Monitorowanie procesw
programowych
Monitorowanie odbywa si przez:
porwnanie planw z realnymi dokonaniami (ocena
postpu prac)
identyfikowanie odchyle od planu
podejmowanie dziaa korygujcych
poziom taktyczny
rezultaty
planu
efekty
dziaa
modyfikacje
CO OSIGN
plan punktw kontrolnych
plan odpowiedzialnoci
CO OSIGN
plan dziaa
zakres odpowiedzialnoci
dziaania
poziom operacyjny
modyfikacje
organizacja
przedsiwzicia
organizacja
dziaa
Normy jakoci dla procesu

programowego
ISO 8402
Oprogramowanie jest
rozumiane jako jeden
z rodzajw wyrobw
ISO 9000
Wytyczne wyboru
modelu
Terminologia
ISO 9001
ISO 9002
ISO 9003
Modele systemu
jakoci
ISO 9004
Elementy systemu
jakoci
IEC/TC 56
ISO/IEC 1508
Niezawodno
oprogramowania
systemw
krytycznych
Bezpieczestwo
oprogramowania
systemw
krytycznych
Jako jako metryka procesu

Model jakoci
ISO 9000
jego egzemplarzem jest
dokumentuje
Firmowy podrcznik
jakoci
Firmowy proces
jakoci
jego egzemplarzem jest

jest uywany przy opracowaniu
Plan jakoci
przedsiwzicia 1
Plan jakoci
przedsiwzicia 2
Wspomaga
Plan jakoci
przedsiwzicia 3
Zarzdzanie
jakoci
przedsiwzi
Polityka i system jakoci

Polityka jakoci to oglne intencje i zamierzenia danej organizacji w
odniesieniu do jakoci [ISO8402] wyraana w sposb formalny przez zarzd firmy.
Musi by zdefiniowana i udokumentowana;
Musz by okrelone cele i zaangaowanie w jako;
Musi by zgodna z dziaaniami przedsibiorstwa i oczekiwaniami klienta;
Musi by zakomunikowana i rozumiana na wszystkich szczeblach zarzdzania.
System jakoci to struktura organizacyjna, przydzia odpowiedzialnoci,

procedury postpowania, zasoby uyte do implementacji polityki jakoci w danej
organizacji [ISO8402]
penomocnik lub zesp do spraw jakoci;
ksiga jakoci: udokumentowane procedury systemu jakoci.
Miara procesw wytwarzania

oprogramowania zgodne z zarzdzaniem
jakoci
Ukierunkowanie na klienta (rwnie klient wewntrzny)
Przywdztwo (budowa wizji, identyfikacja wartoci)
Zaangaowanie ludzi (satysfakcja, motywacja, szkolenia)
Podejcie procesowe i pomiary
Podejcie systemowe
Cige doskonalenie
Rzetelna informacja (zbieranie i zabezpieczanie danych do
podejmowania obiektywnych decyzji)
Partnerstwo dla jakoci (bliskie zwizki producentw z
klientami)
Inne ekonomiczne miary procesu

procesw programowych
Jako produktu jest tylko jednym z czynnikw wpywajcych
na wynik ekonomiczny firmy. Inne aspekty to:
Reklama i promocja produktu

Renoma producenta
Rodzaj i zakres gwarancji oraz innych usug dla klientw
Przyzwyczajenia klientw
Sposb wyceny rozmaitych wersji produktu
Inwestycje niezbdne wewntrz firmy
Koszty reorganizacji firmy
Koszty szkole
Koszty zakupu narzdzi CASE
Nakady na dokadne testowanie oprogramowania
Zwrot nakadw nastpuje zwykle po pewnym czasie i

czsto nie moe by traktowany jako pewny.
Obiekty pomiaru procesu

programowego
Obiekty
Atrybuty bezporednio mierzalne
Specyfikacje rozmiar, ponowne uycie, modularno,

nadmiarowo, funkcjonalno,
poprawno skadniow, ...
Projekty
rozmiar, ponowne uycie, modularno,
spjno, funkcjonalno,...
Kod
rozmiar, ponowne uycie, modularno,
spjno, zoono, strukturalno, ...
Dane
testowe
....
Wskaniki
syntetyczne
zrozumiao,
pielgnacyjno, ...
rozmiar, poziom pokrycia,...
jako, zoono,
pielgnacyjno, ...
niezawodno,
uywalno,
pielgnacyjno, ...
jako,...
....
....
Obiekty pomiaru oprogramowania

Obiekty
Wskaniki
syntetyczne
Specyfikacja
architektury
Projekt
szczegowy
Testowanie
czas, nakad pracy, liczba zmian

wymaga, ...
czas, nakad pracy, liczba znalezionych
usterek specyfikacji,...
czas, nakad pracy, liczba znalezionych
bdw kodu, ...
....
jako, koszt,
stabilno, ...
koszt, opacalno,
...
koszt, opacalno,
stabilno, ...
....
....
Obiekty pomiaru oprogramowania

Obiekty
Wskaniki
syntetyczne
Personel
wiek, cena, ...
Zespoy
wielko, poziom komunikacji,

struktura,...
cena, wielko, ...
wydajno,
dowiadczenie,
inteligencja, ...
wydajno, jako,
...
uywalno,
niezawodno, ...
niezawodno, ...
wygoda, jako,...
....
Oprogramo
wanie
Sprzt
Biura
....
cena, szybko, wielko pamici

wielko, temperatura, owietlenie,...
....
Przykadowe miary wydajnoci

zasobw
Czynniki
wpywajce
na ogln
Wydajno
Zasobw
Wydajno
Warto
Jako
Niezawodno
Defekty
Koszt
Ilo
Wielko
Funkcjonalno
Personel
Czas
Pienidze
Zasoby
Sprzt
Zoono
Ograniczenia
rodowiskowe
Oprogramowanie
Trudno
problemu
CMM: Capability Maturity Model

Poziom dojrzaoci organizacyjnej firmy
wytwarzajcej oprogramowanie
SEI, Pittsburg, USA
5. Optymalizujcy
1989-1993
4. Zarzdzany ilociowo
3. Zdefiniowany
2. Zarzdzany (powtarzalny)
1. Pocztkowy
Niedojrzao i dojrzao procesw

programowych
Niedojrzao
Improwizacja podczas procesu

wytwrczego
Proces jest wyspecyfikowany, ale
specyfikacja nie jest stosowana
Dorane reagowanie w sytuacji
kryzysw
Harmonogram i budet s
przekraczane
Funkcjonalno jest stopniowo
okrajana
Jako produktu jest niska
Brak obiektywnych kryteriw
oceny
Dojrzao
Zdolno do budowy
oprogramowania jest cech
organizacji a nie personelu
Proces jest zdefiniowany,
znany i wykorzystywany
Proces jest obserwowany i
ulepszany
Prace s planowane i
monitorowane
Role i odpowiedzialnoci s
zdefiniowane
Obiektywna, ilociowa ocena
Problemy z dojrzaoci procesu

Czy dojrzay, realizowany na wysokim

poziomie kompetencji proces wytwarzania
oprogramowania musi skutkowa
osigniciem sukcesu (realizacj
oprogramowania na czas, w ramach
zaplanowanego budetu, dobrej jakoci)?
Pomiary przedsiwzi
informatycznych (projektw)
Proces
programowy
og czynnoci
zwizanych z
wytwarzaniem
oprogramowania, w
przed klientem
dojrzaoci
kompetencyjnej
Miary organizacji
Przedsiwzicie
informatyczne
og czynnoci
kontrolnych w celu
lepszej estymacji czasu i
kosztu, jakoci
realizowanych zada,
oceny produktywnoci
Miary przedsiwzi
Produkt
programowy
og czynnoci
zwizanych z jakoci
produktu, i inne
niejakociowe jego
cechy
Miary programw jako

produktw
Pomiary przedsiwzicia
informatycznego
Pomiary procesu programowego, analizowane nie
na poziomie caej organizacji, lecz na pojedynczo
realizowanych przedsiwziciach
Pomiary przedsiwzicia pozwalaj na:
ocen stanu realizacji przedsiwzicia

ledzenie potencjalnych zagroe
wyodrbnienie obszarw krytycznych
przydzielanie pracownikom zada w projekcie
biec ocen jakoci powstajcego produktu
kontrol czynnikw kosztowych przedsiwzicia i
kontrol harmonogramu realizacji projektu
Pomiary przedsiwzicia
informatycznego
Obowizuj tu zwykle takie miary jakie wynikaj z
nadrzdnego procesu programowego
(organizacji) ale s i inne
Pomiar przedsiwzicia programistycznego jest
zaley od przyjtej w przedsiwziciu metod
prowadzenia projektu metodyki
Miary przedsiwzicia zale rwnie od
techniki prowadzenia przedsiwzicia
od paradygmatw programowych
Miary przedsiwzicia informatycznego zale
rwnie od miar oceny produktu
oprogramowania
Oczekiwania wzgldem oprogramowania to

miara przedsiwzicia informatycznego
(projektu)
Wymagania
A jaka jest rzeczywisto?
Wymagania
OPNIENIE
Software
Softwarek
Cztery wymiary biecej oceny

przedsiwzicia informatycznego
koszt
czas
oprogramowanie
jako
zakres
Realizacja oprogramowania jako

kompromis
krtki termin
niski koszt
przebieg typowy
przebieg
maksymalny
wysoka jako
przebieg
zalecany
wysoka
akceptacja
uytkownika
(ZAKRES)
Miary produktu programowego

Proces
programowy
og czynnoci
zwizanych z
wytwarzaniem
oprogramowania, w
przed klientem
dojrzaoci
kompetencyjnej
Miary organizacji
Przedsiwzicie
informatyczne
og czynnoci
kontrolnych w celu
lepszej estymacji czasu
i kosztu, jakoci
realizowanych zada,
oceny produktywnoci
Miary przedsiwzi
Produkt
programowy
og czynnoci
zwizanych z jakoci
produktu, i inne
niejakociowe jego
cechy
Miary programw jako
produktw
Podzia miar produktu programowego

Pomiar produktu (oprogramowania)
Miary statyczne
pomiary
reprezentacji
systemu, takich
jak projekt,
program,
dokumentacja
Miary dynamiczne
pomiary
wykonujcego si
programu.
Miary produktu
(oprogramowania)
Rnorodne metryki uwzgldniaj m.in. nastpujce aspekty
wraliwo na bdy,
wspzaleno zada,
moliwoci testowania,
wielko i koszt projektu,
czstotliwo wystpowania awarii,
czas trwania projektu,
dostpno systemu,
zagroenia projektu (ryzyko),
propagacja bdw,
czas gotowoci produktu,
ilo linii kodu, zoono kodu,
kompletno wymaga,
zoono programu,
kompletno planowania,
zoono obliczeniowa,
stabilno wymaga,
funkcjonaln, moduow,
odpowiednio posiadanych
atwo implementacji,
zasobw sprztowych,
rozmiar dokumentacji,
materiaowych i ludzkich,
ilo zada wykonanych

terminowo i po terminie,
efektywno zespou, efektywno

poszczeglnych osb.
Miary produktu
(oprogramowania)
Koszt
Produktywno
Jako
Niezawodno
Zoono
Zoono obliczeniowa
(algorytmiczna)
Zgodno ze standardami
Otwarto
Przenaszalno
Rozwijalno
Uyteczno
Efektywno
Podatno na modyfikacji
Satysfakcja uytkownika
Wielko funkcjonalna (FP)
Dugo (np. LOC, software
science)
Sterowalno (np. V(G) )

Ergonomiczno
Sposb uycia danych
Pielgnowalno
Miary wielokryterialne
tzw. efekt skali
Zrwnowaony System Miar i
tzw. Strategiczna Karta Wynikw
Dojrzao realizacyjna
oprogramowania
Rne metryki hybrydowe
Istniej ich setki i wiele wiele
innych
Ktre miary wybra do

oceny produktu?
Podstawowa metryka
oprogramowania to jego jako
Zapewnienie jakoci to zesp dziaa zmierzajcych do
wytworzenia u wszystkich zainteresowanych przekonania,
e dostarczony produkt waciwie realizuje swoje funkcje i
odpowiada aktualnym wymaganiom i standardom.
Jako oprogramowania mona wyrazi technicznymi
czynnikami mierzalnymi oraz niemierzalnymi
obiektywnie czynnikami psychologicznymi.
Podstaw obiektywnych wnioskw co do jakoci
oprogramowania s pomiary parametrw
uytkowych (niezawodnoci, szybkoci dziaania, itp..
Jako oprogramowania (metryka

oprogramowania jako produktu)
Jako gotowych produktw programistycznych jest
bardzo trudna do zmierzenia ze wzgldu na:
eksplozj danych testowych,
zoono oprogramowania,
wieloaspektowo,
identyczno wszystkich kopii produktu,
nisk przewidywalno wszystkich aspektw
zastosowa oprogramowania w dugim czasie.
Gotowe oprogramowanie moe mie zastosowanie w
rnej skali a przy zmianie skali pomiary jakoci mog
okaza si nieadekwatne,
Pomiary mog by bardzo kosztowne, czasochonne
lub niewykonalne (z powodu niemoliwoci stworzenia
rodowiska pomiarowego przed wdroeniem);
Miary jakoci produktu

programowego
ISO/IEC 9126 Software engineering - Product
quality
Part
Part
Part
Part
1:
2:
3:
4:
Quality model (2001)

External metrics (2003)
Internal metrics (2003)
Quality in use metrics (2004)
ISO/IEC 9126:2001
Jako produktu programowego
funkcjonalno
dopasowanie
dokadno
atwo
wspdziaania
bezpieczestwo
niezawodno
uyteczno
dojrzao
odporno na
bdy
odzyskiwalno
zrozumiao
wyuczalno
operacyjno
atrakcyjno
efektywno
efektywno
czasowa
zuycie
zasobw
konserwowalno
przenono
analizowalno
zmienialno
stabilno
testowalno
adaptowalno
instalowalno
zgodno
zastpowalno
Jako uytkowa
efektywno
produktywno
bezpieczestwo
satysfakcja
Zwizki midzy miarami jakoci

produktu programowego i procesu
jego wytwarzania
Proces
jako
procesu
Produkt programowy
wpywa na
atrybuty
jakoci
wewntrznej
zaley od
Miara
procesu
Miara
wewntrzna
wpywa na
zaley od
Wynik dziaania produktu
atrybuty
jakoci
zewntrznej
wpywa na
atrybuty
jakoci
uytkowej
zaley od
Miara
zewntrzna
Miara
jakoci
uytkowej
Kontekst
uycia
Zwizki midzy atrybutami

zewntrznymi i wewntrznymi jakoci
oprogramowania
Zdatno do
pielgnacji
Liczba parametrw
procedur
Zoono
cykliczna
Niezawodno
Wielko programu
w wierszach kodu
Przenono
Liczba komunikatw
o bdach
Wygoda
uytkownika
Wielko podrcznika
uytkownika
Zwizek miar kontrolnych i

predykcyjnych oprogramowania
Proces tworzenia
oprogramowania
Produkt
programowy
Pomiary
kontrolne
Pomiary
predykcyjne
Decyzje
menederskie
Rne podejcia do problemu jakoci

Podejcie:
europejskie
amerykaskie
japoskie
Co podlega ocenie
jakoci
Zgodno ze
specyfikacj
Satysfakcja
uytkownika
Wszystko co
mona poprawi
Niezgodno ze
specyfikacj
Niespenienie
oczekiwa
uytkownika
Wszystko co
mona poprawi
(kady
mankament)
Jak si mierzy jako?
Obiektywne
mierzalne kryteria
techniczne
Subiektywne
niemierzalne
oceny
uytkownika
Subiektywne i
obiektywne oceny
i kryteria
Rodzaj systemu
pomiarowego
specyfikacje i
badania kontrolne,
testowanie,
nadzorowanie
procesu,
standaryzacja
analiza wymaga,
badania
konkurencji,
ocena satysfakcji
klienta
system
kompleksowy,
cige
doskonalenie
producent
producent
kady
producent, ekspert
klient, uytkownik,
laik
kady
Kiedy jest za jako
Kto odpowiada za
jako ?
Kto weryfikuje jako?
Norma IEEE-730
Norma IEEE-730 podaje oglne ramy planu zapewniania jakoci. Powinien on
obejmowa nastpujce zagadnienia:
analiza punktw widzenia
referencje wykonawcy
zarzdzanie przedsiwziciem informatycznym
dokumentacja
standaryzacja dziaa
przegldy i audyty
zarzdzanie konfiguracj oprogramowania
raport napotykanych trudnoci i podjtych dziaa prewencyjnych
wykorzystywane metody i narzdzia
kontrola kodu, mediw, dostawcw
zarzdzanie hurtowniami danych
pielgnacja
Norma IEEE-730 uzupeniono i uszczegowiono norm IEEE-983.
Rola systemw komputerowego

wspomagania procesw
pomiaru oprogramowania
Rodzaje systemw komputerowego

wspomagania procesw pomiaru
oprogramowania
Komputerowe
wspomaganie
przedsiwzi
informatycznych
( np.. CASE, program do
zarzdzania projektami,
zarzdzania wersjami,
PRINCE2, Mind Manager,
CMTJava - narzdzie do
wyznaczania metryk w
programach w jzyku Java
itp., )
Pakiety
gromadzce dane i
histori pomiarw
Pakiety wspomagajce
diagnostyk
programw
(programy testujce)
Pakiety
wspomagajce
organizacj
(np.. Hudson w firmie Tieto)
Typy narzdzi
wspomagajcych
Ze wzgldu na kompleksowo mona podzieli na:
Czstkowe
Porednie
Zintegrowane
Dedykowane
Otwarte
Doradcze
Wspomagajce zarzdzanie zasobami
Elastyczne
Inne uwagi oglne o

metrykach programw
Metryki s tworzone i stosowane na bazie dowiadczenia i zdrowego
rozsdku, co obnia ich warto dla tzw. teoretykw informatyki.
Metryki powinny by wykorzystywane jako metody wspomagania
ekspertw. Metryki stosowane formalistycznie mog by grone.
Najlepiej jest stosowa zestawy metryk, co pozwala zmniejszy bdy
pomiarowe.
Przede wszystkim zdrowy rozsdek i dowiadczenie.
Pomimo pochodzenia empirycznego, metryki skutecznie pomagaj w
szybkiej i mniej subiektywnej ocenie oprogramowania.
Specjalizacja metryk w kierunku konkretnej klasy oprogramowania
powinna dawa lepsze i bardziej adekwatne oceny ni metryki
uniwersalne.
Wskazane jest wspomaganie metod opartych na metrykach
narzdziami programistycznymi.
Inne wnioski
Porwnanie miar oprogramowania jest
utrudnione ze wzgldu na indywidualny charakter
przedsiwzi informatycznych, programw, procesw
programowych, miar, braku jednolitego standardu
odniesienia, itp.
Miary oprogramowania maj czsto wartoci
kategoryczne (np. miary jakoci)
Metryk jakoci naley uywa na wszystkich
trzech poziomach pomiaru oprogramowania
(proces programowy, przedsiwzicie programistyczne,
gotowy produkt programowy)
KORZYCI Z INWESTYCJI
INFORMATYCZNYCH
Korzyci z inwestycji w
informatyzacj
Czy inwestycje informatyczne zmieniaj w zasadniczy sposb
pozycj ekonomiczno-finansow firmy?
Tak - w sposb
zasadniczy
Nie
wg J. Kisielnickiego
wg M. Niedwiedziskiego
Klasyfikacja (przykadowa) efektw informatyzacji

Klasyfikacja efektw informatyzacji moe by bardzo rna
rna::
jednorazowe - w momencie wdraania systemu (np. spadek zatrudnienia)
cige - w caym okresie eksploatacji (np. poprawa wykorzystania aparatu
produkcyjnego)
bezporednie - np. obnika kosztw przetwarzania danych
porednie - np. poprawa zaopatrzenia materiaowego
pierwotne - zmniejszenie np. zmniejszenie amortyzacji po wycofaniu zbdnych
urzdze
wtrne - np. obnika kosztw wasnych (podobnie jak efekty porednie)
globalne
techniczne - wzrost szybkoci, dokadnoci, szczegowoci i poufnoci
przetwarzania danych
ekonomiczne - wspomaganie wzrostu efektu ekonomicznego np. przez
biecy nadzr nad firm
organizacyjne - usprawnienie struktury organizacyjnej (np. obiegu
dokumentw)
socjo-psychologiczne - integracja pracownikw przez lepsze poznanie
ichpotrzeb
czstkowe
Sposb (przykadowy) oceny

przedsiwzi IT
Organizacja ocenia, mierzy, szacuje i uzasadnia
koszty na kadym etapie przygotowania i realizacji
przedsiwzicia
czy strategia informatyzacji firmy zostaa opracowana na
podstawie strategii biznesowej
czy szczegowy projekt zosta sprecyzowany
czy projekt jest w penej fazie rozwoju
czy projekt zosta zatwierdzony
czy projekt wprowadzono w ycie
czy projekt dziaa od pewnego czasu
czy projekt jest bliski koca
Sposb (przykadowy) oceny przedsiwzi IT

Niektre metody oceny
oceny::
Zwrot z inwestycji (ROI - Return-On-Investment) wie si z ocen aktualnej wartoci
kosztw i przyszych wpyww i polega na ocenie czasu i wartoci zwrotu poniesionych
kosztw. Najczciej stosowana do porwnania rnych alternatywnych projektw pod
katem zwrotu kosztw.
Analiza kosztw i korzyci (CBA - Cost - benefit analysis) wie si z prb oszacowania
kosztw kadego elementu projektu i wartoci korzyci ekonomicznej z rozwoju projektu.
Metody wielu celw i wielu kryteriw (MOMC - Multi-objective, Multi-criteria methods)
zakada istnienie innych wartoci ni ekonomiczne, std polega na uszeregowaniu
okrelonych preferencji wg przyznanych im wag. Poniewa wagi mog by ocen
subiektywn tworzone s alternatywne scenariusze uwzgldniajce rne cele.
Wartoci graniczne (Boundary values) dostarcza surowego porwnania cakowitych
wydatkw z innymi poczonymi wartociami np. cakowity koszt IT a cakowity dochd lub
czny koszt na jednego pracownika lub cakowite wydatki na IT a zysk netto.
Zwrot z zarzdzania (ROM - Return on Management) wie si z szacowaniem korzyci w
zarzdzaniu, czyli okrela zysk wynikajcy z poprawy zarzdzania firm przez porwnanie
oszacowania zysku z zastosowaniem IT i bez.
Kluczowe czynniki sukcesu (Critical succes factors) polega na wyspecyfikowaniu tych
czynnikw, ktre s gwarantem sukcesu informatyzacji oraz ocenia jaka jest rola IT w
osiganiu powodzenia.
Metody dowiadczalne pozwalaj dokona oceny na drodze budowy prototypu
(prototyping), symulacji komputerowej (simulation) lub inscenizacji (gameplaying).
Inne (patrz Materiay Konferencji Efektywno zastosowa SI Szczyrk 2001 - Nowak J.S
Przegld metod oceny inwestycji informatycznychstr.61 (T.II))
RYZYKO
W PRZEDSIWZICIACH
INFORMATYCZNYCH
14
Okrelenie ryzyka
Istnieje wiele okrele dotyczcych pojcia ryzyka ale we
wszystkich
mona
spotka
opini,
i
ryzyko
jest
charakteryzowane przez dwa podstawowe elementy
elementy:
niepewno
zdarzenie,
ktre
powoduje
urzeczywistnienie ryzyka, (jeli urzeczywistnienie jest
pewne powinno by klasyfikowane jako ograniczenie
realizacji przedsiwzicia informatycznego)
skutki urzeczywistnienie si ryzyka powoduje
wystpienie negatywnych konsekwencji lub strat.
Ryzyko jest nieodcznym elementem
przedsiwzicia informatycznego.
realizacji
kadego
Profesjonalne podejcie do przedsiwzi informatycznych

wymaga stosowania przez kierownika projektu skutecznej
metody zarzdzania ryzykiem.
Model Software Engineering Institute (SEI)

zarzdzania ryzykiem
inwentaryzacj potencjalnych zagroe tworzenie listy specyficznych dla danego
przedsiwzicia elementw ryzyka
wymiana informacji o ryzyku na

rnych poziomach organizacji,
istotnych z punktu widzenia caoci
przedsiwzicia
IDENTYFIKACJA
ocena p-stwa (dla kadego

ryzyka) wystpienia ryzyka i
rozmiar potencjalnych start.
Okrela si rwnie skutki
wystpienia kilku elementw
ryzyka.
STEROWANIE
korygowanie odchyle
od
przewidywanych
rezultatw
dziaa
podjtych
w
celu
agodzenia lub unikania
ryzyka
ANALIZA
KOMUNIKACJA
wykorzystanie informacji o
ryzykach
w
rnych
decyzjach i dziaaniach
majcych
na
celu
zagodzenie
skutkw
urzeczywistnienia si ryzyk
LEDZENIE
PLANOWANIE
monitorowanie statusu ryzyk

oraz dziaa rozpocztych w
celu agodzenia lub unikania
ryzyka
WSKANIK ZAGROENIA
PRZEDSIWZICIA
INFORMATYCZNEGO

Wskanik zagroenia przedsiwzicia informatycznego to ilociowe
okrelenie (miara) szansy powodzenia realizowanego przedsiwzicia
UWAGA! aden wskanik nie zastpi zdrowego rozsdku!!!

Wskanik ten powinien by reprezentowany przez dwie skadowe
(odnoszone do ukadu wykonawca-zleceniodawca):
stan motywacji do pomylnego zakoczenia przedsiwzicia,
stan moliwoci wykonawczych pomylnego zakoczenia
WSKANIK ZAGROENIA
MOTYWACJE
Bardzo mocno korzystny dla przedsiwzicia
10
Mocno korzystny dla przedsiwzicia
Dostatecznie korzystny dla przedsiwzicia
Zauwaalnie korzystny dla przedsiwzicia
Nieznacznie korzystny dla przedsiwzicia
Obojtny dla przedsiwzicia
Nieznacznie niekorzystny dla przedsiwzicia
-2
Zauwaalnie niekorzystny dla przedsiwzicia
-4
Dostatecznie niekorzystny dla przedsiwzicia
-6
Mocno niekorzystny dla przedsiwzicia
-8
Bardzo mocno niekorzystny dla przedsiwzicia -10
MOLIWOCI

Warto skadowych wskanika zagroenia (motywacja i moliwoci)
moe by wyznaczona na podstawie wartoci tzw. sprawczych i
wykonawczych
czynnikw
zagroenia
przedsiwzicia
informatycznego
Czynniki sprawcze zagroenia przedsiwzicia informatycznego
opisuj te elementy oraz te waciwoci (cechy) dziaalnoci ukadu
zleceniodawca-wykonawca, ktre generuj przyczyny upadku (lub
powodzenia) przedsiwzicia informatycznego.
Zbir wartoci czynnikw sprawczych zagroenia przedsiwzicia
informatycznego okrela warto stanu motywacji
Czynniki wykonawcze zagroenia przedsiwzicia informatycznego
opisuj te elementy oraz te waciwoci (cechy) dziaalnoci ukadu
zleceniodawca-wykonawca, ktre okrelaj fizyczn realizowalno
Zbir wartoci czynnikw wykonawczych zagroenia przedsiwzicia

informatycznego okrela warto stanu moliwoci
Wskanik zagroenia przedsiwzicia

informatycznego
Wartoci czynnikw sprawczych i wykonawczych mog
wyznaczone na podstawie listy zidentyfikowanych ryzyk.
Ryzyka te okrela si czynnikami
przedsiwzicia informatycznego
pierwotnymi
by
zagroenia
W tym celu dla kadego zidentyfikowanego ryzyka czynnika

pierwotnego naley okreli:
czy dany czynnik pierwotny (ryzyko) wpywa na okrelony
czynnik sprawczy czy wykonawczy?
liczb okrelajc biecy stopie urzeczywistnienia si
danego ryzyka,
jak dany czynnik pierwotny (ryzyko) wpywa na okrelony
czynnik sprawczy lub wykonawczy: czy powoduje jego wzrost
czy spadek?
Czynniki pierwotne zagroenia przedsiwzicia informatycznego
mog by okrelone na podstawie kwestionariuszy identyfikacji
ryzyka. Kwestionariusz taki zawiera list potencjalnych rde
ryzyk dla konkretnego przedsiwzicia, do ktrej naley doczy
list pyta (przynajmniej jedno pytanie do rda) umoliwiajcych
identyfikacj tych ryzyk.
Algorytm okrelania wskanika zagroenia przedsiwzicia informatycznego

zdefiniowanie zbioru czynnikw pierwotnych zagroenia (ryzyk)
R = (r1, r2, ..., rn);
skonstruowanie (dla kadego czynnika ryzyka) kwestionariusza oceny wartoci
danego czynnika, umoliwiajcego ustalenie jego biecej wartoci;
zdefiniowanie zbioru czynnikw sprawczych zagroenia
S = (s1, s2, ..., sn);
dla kadego czynnika sprawczego zdefiniowanie formuy przedstawiajcej
zaleno midzy wybranymi czynnikami pierwotnymi zagroenia (ryzykami) a
danym czynnikiem sprawczym;
zdefiniowanie zbioru czynnikw wykonawczych zagroenia
W = (w1, w2, ...,wm);
dla kadego czynnika wykonawczego zdefiniowanie formuy przedstawiajcej
zaleno midzy wybranymi czynnikami pierwotnymi zagroenia (ryzykami) a
danym czynnikiem wykonawczym;
okrelenie stanu motywacji (M) jako wypadkowej czynnikw sprawczych

przedsiwzicia informatycznego:
M 10...10
M v is s i
v is
i 1
waga i-tego czynnika sprawczego
okrelenie stanu moliwoci (P) jako wypadkowej czynnikw wykonawczych

zagroenia przedsiwzicia informatycznego:
P 10...10
P v iw w i
i 1
v iw waga i-tego czynnika wykonawczego
okrelenie wskanika zagroenia przedsiwzicia informatycznego

WZI = (M,P)

ISI Wykłady

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ISI Wykłady

Uploaded by

Copyright:

Available Formats

Terminarz i zawarto

wykadw sala 126 WI1

Efekty ksztacenia w obszarze

Efekty ksztacenia w obszarze

Efekty ksztacenia w obszarze

Zasady zaliczania przedmiotu

30.06.2014 r. Godz. 12-14 sala 215

10.09.2014 r. godz. 10-12 sala 215

Zasady zaliczania przedmiotu

Jeli nie osignito wszystkich efektw w terminie podstawowym

ocena kocowa za wykad = (rednia z pozytywnych ocen efektw + 2 *ip)/(ip+1)

Ocena kocowa za wykad

zbir zasad, metod i procedur tworzenia, przesyania,

celowe zestawienie ludzi, danych, procesw, sposobw

system informatyczny moe by jedn z czci

System informatyczny (SI) - to system

WYSZA I REDNIA KADRA KIEROWNICZA,

REDNIA KADRA KIEROWNICZA,

REDNIA KADRA KIEROWNICZA,

Co to jest Business Process

Co to jest Business Process

BPR to fundamentalne przemylenie od nowa i radykalne

Cel reorganizacji procesw

Skala i zakres zmian w

Analiza wariantw zmian

Kontekst czasowy wdraania

Najpierw system informatyczny,

Zaleta: mniejsze ryzyko niepowodzenia, mniejsze

Zaleta: krtki czas przeprowadzania zmian i uzyskania

Najpierw reorganizacja, pniej

Informatyka jako czynnik

Informatyka jako narzdzie

Zmiany wymuszane przez system informatyczny

sia nowych technologii

Czym zajmuje si inynieria

Dwa nurty inynieria

Tworzeniem, rozwojem i pielgnacj

Czym zajmuje si inynieria

Czym zajmuje si inynieria

Czym zajmuje si inynieria

Dlaczego ta dziedzina jest

Dlaczego zdarzaj si nieudane

ponad 25% przedsiwzi informatycznych jest

The Standish Group

Kolejne raporty: The CHAOS Chronicles od

Realizacja projektw - statystyki

Realizacja projektw - statystyki

Wsparcie zarzdu (kierownictwa, sponsora)

Jasne sformuowanie wymaga

Krtsze etapy projektowania

Kompetentny zesp projektowy

Jasno okrelona wasno projektu

Jasna wizja i cele

Ciko pracujcy, skupiony na projekcie zesp

Zastosowanie standardw infrastruktury

Dowiadczony kierownik zespou

Realizacja maych projektw

Wsparcie zarzdu (kierownictwa, sponsora)

Wiedza z dziedziny zarzdzania projektem

Jasne sformuowanie wymaga

Realne oczekiwania - wykonalno

Mae a due projekty

Projekty due (powyej 10 mln $)

Dane z 2012 roku

450.80.9 + (-20)0.80.1 + 550.20.5 + (-10)0.20.5 = 35.3