ISI Wykłady
-
Upload
adrian-glinski -
Category
Documents
-
view
38 -
download
2
description
Transcript of 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 s. 537
W14-11.06.2014
W15-16.06.2014 (poniedziaek)
-
INYNIERIA SYSTEMW INFORMATYCZNYCH I
Dr hab. n.t. Boena miakowska prof. ndzw. ZUT
-
Informacje podstawowe o przedmiocie
Wymiar przedmiotu 30 W+ 30 LWagi w ocenie kocowej za przedmiot:
(1W+0.6 L)/1.65 punktw ECTSPrzedmiot 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 informatycznychKorzyci z inwestycji informatycznych. Ryzyko przedsiwzi informatycznych
Wskanik zagroenia przedsiwzicia informatycznego
Metody testowania oprogramowania.Techniki wspomagajce procesy wytwarzania oprogramowaniaZaliczenie wykadu
-
Efekty ksztacenia w obszarze wiedzy
IC_1A_C/05/01_W01 student zna metody gromadzenia i przetwarzania danych w systemach informatycznychIC_1A_C/05/01_W02 student zna podstawowe techniki, metody i metodyki tworzenia systemw informatycznychIC_1A_C/05/01_W03 student zna metody strukturalne, obiektowe i elastyczne projektowania systemw informatycznychIC_1A_C/05/01_W04 - zna zastosowania systemw informatycznych
-
Efekty ksztacenia w obszarze umiejtnoci
IC_1A_C/05/01_U01 student potrafi przeprowadzi proces analizy systemu informatycznego z uyciem wybranej metodyIC_1A_C/05/01_U02 - potrafi przeprowadzi proces projektowania systemu informatycznego z uyciem wybranej metodologii oraz metodykiIC_1A_C/05/01_U03 - potrafi sporzdzi prototyp systemu informatycznegoIC_1A_C/05/01_U04 - potrafi opracowa odpowiedni do etapu cyklu ycia systemu informatycznego dokumentacje techniczna
-
Efekty ksztacenia w obszarze 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 przedmiotuZaliczenie 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.65 punktw ECTSTermin zaliczenia wykadw:
Rodzaj studiwTermin
Kierunek Inynieria Cyfryzacji studia stacjonarne I stopnia
Termin podstawowy 16.06.2014 r. sala 126 WI2
I termin poprawkowy 30.06.2014 r. Godz. 12-14 sala 215
II termin poprawkowy 10.09.2014 r. godz. 10-12 sala 215
-
13
Jeli wszystkie efekty osignito w terminie podstawowym (pozytywna ocena z kadego zadania) to:
Jeli nie osignito wszystkich efektw w terminie podstawowym to:
ocena kocowa za wykad = rednia z ocen uzyskanych za poszczeglne pytania
Zasady zaliczania przedmiotuZasady zaliczania przedmiotu
terminu podstawowego = ndst.
student ma prawo do dwch poprawek niezaliczonych efektw ksztacenia,
gdzie ip liczba poprawekjest podstaw do obliczenia pozytywnej oceny za wykad:
ocena kocowa za wykad = (rednia z pozytywnych ocen efektw + 2 *ip)/(ip+1)
-
14
Ocena za
efekt 1
Ocenaza
efekt 2
Ocenaza
efekt 3
Ocena za
efekt 4
Ocena za
efekt5-8
Ocena za
efekt 9
I poprawka II poprawka
Ocena kocowa za wykad
3 3 5 5 4 4 Nie dotyczy Nie dotyczy
dobry(podstawa: rednia z pozytywnych ocen za
efekty) 4,0 Ocena za
przedmiot
3 2 5 5 2 5
Zaliczono efekt 2 oraz efekty 5-8 na ocen
dst
Nie dotyczy
W terminie podstawowym ocena
ndstW terminie
poprawkowym dobry(podstawa: rednia z pozytywnych ocen za
efekty)3,0 Ocena za wykad
3 2 5 5 2 5
Zaliczono efekt 2
ocen dstefekty 5-8
niezaliczone (ndst)
Zaliczono efekt 5-8 na ocen dst
W terminie podstawowym terminie
pierwszej poprawkiocena ndst
W drugim terminiepoprawkowym dobry(podstawa: rednia z pozytywnych ocen za
efekty)2,67 Ocena za wykad
-
LiteraturaCadle 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 2007Flasiski M.: Zarzdzanie projektami informatycznymi, PWN, Warszawa 2006.Graessie P. i inni: UML 2.0 w akcji, Przewodnik oparty na projektach, Helion 2008Beynon-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 2003Pritchard 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.
-
Konsultacjeroda godz. 14:00-15:30 pokj 113
Kontakt :[email protected]
-
PODSTAWOWE DEFINICJE
-
Systemy informacyjne (systematyka poj)zbir zasad, metod i procedur tworzenia, przesyania, magazynowania i przetwarzania informacjiformalny zesp rodkw kapitaowych oraz algorytmw, ktrych funkcjonowanie przejawia si w zbieraniu, kodowaniu, magazynowaniu, przetwarzaniu, dekodowaniu i uytkowaniu danych potrzebnych dla podejmowania decyzji i zarzdzaniausystematyzowana 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 kierowniczspenia funkcj systemu informacyjnegookrelony, wyodrbniony obszar systemu informacyjnego dla danego obiektu obsugiwany za pomoc technicznych rodkw informatykioparte 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 informacyjnegosystem informacyjny moe si skada z wicej ni jednego systemu informatycznego system informacyjny niekoniecznie musi zawiera elementy infrastruktury ITzbir 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 pojSystem 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 finansowo-ksigowy itp.
-
Informatyka w kompleksowym zarzdzaniu organizacj (np.: gospodarcz)
PR
OD
UK
CJA
/ S
ER
WIS
RE
ALI
Z. Z
AM
W
IEN
IA
OB
SU
GA
PO
SP
RZE
D.
Procesgospodarczy
SP
RZE
DA
DY
STR
YB
UC
JA
ZAO
PATR
ZEN
IE
RO
ZW
J P
RO
DU
KT
WCele gospodarcze
STARTEGICZNE
OPERACYJNE
Organizacja
SPECJALISTA
KIEROWNIK
DYREKTOR
ZARZD
-
Rozwj SI
SYSTEMEKSPERCKI
SYSTEM WSPOMAGANIA
DECYZJI
SYSTEM INFORMOWANIA KIEROWNICTWA
SYSTEM INFORMATYCZNY
ZARZDZANIA
SYSTEM REJESTRACYJNY
RO
ZW
J SY
STE
MU
INFO
RM
ATY
CZN
EG
O
NAJWYSZY SZCZEBEL ZARZDZANIA
WYSZA I REDNIA KADRA KIEROWNICZA, ANALITYCY BIZNESOWI
REDNIA KADRA KIEROWNICZA, ANALITYCY BIZNESOWI
REDNIA KADRA KIEROWNICZA, PERSONEL ADMINISTRACYJNY
PERSONEL ADMINISTRACYJNY, OPERATORZY, AUTOMATY
uytkownik
-
SYSTEMEKSPERCKI
SYSTEM WSPOMAGANIA
DECYZJI
SYSTEM INFORMOWANIA KIEROWNICTWA
SYSTEM INFORMATYCZNY
ZARZDZANIA
SYSTEM REJESTRACYJNY
RO
ZW
J SY
STE
MU
INFO
RM
ATY
CZN
EG
O
DECYZJE BIZNESOWE
INFORMACJA ZARZDCZA
DANE ZAGREGOWANE
DANE ZINTEGROWANE
WYSPY INFORMACYJNE
produkt
Rozwj SI
-
SYSTEMEKSPERCKI
SYSTEM WSPOMAGANIA
DECYZJI
SYSTEM INFORMOWANIA KIEROWNICTWA
SYSTEM INFORMATYCZNY
ZARZDZANIA
SYSTEM REJESTRACYJNY
RO
ZW
J SY
STE
MU
INFO
RM
ATY
CZN
EG
O
CELE STRATEGICZNE
CELE OPERACYJNE
Rozwj SI
-
Restrukturyzacja organizacji
Zmiana struktury (czsto zmniejszenie ilociowe): zasobw organizacji (majtek, zatrudnienie) rde finansowania asortymentu produktw rynku zbytu
w celu utrzymania lub wzmocnienia pozycji rynkowej
-
Rynkowa: konkurencja krajowa, import, opacalno eksportu, nowe formy marketingu, jako produktu, potencja produkcyjny, sieci dystrybucji, rozeznanie rynkuProduktowa: oferta produktowa, jako produktw, nowoczesne maszyny, koszty jednostkowe produkcji,
Strategie restrukturyzacji przedsibiorstw w Polsce
-
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
-
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
Co to jest Business Process Reengineering ?...
-
Przedmiot reinynierii
Definicja procesu:
Zbir czynnoci wymagajcy na wejciu zasobw i dajcy na wyjciu rezultat, majcy konkretn warto dla klienta
M. Hammer, J. Champy
-
iOrganizacja funkcjonalna a procesy (np.: gospodarcze)
ZLECENIE PRODUKCYJNE
REALIZACJA ZLECENIASPRZEDA
-
Cel reorganizacji procesw
Np.: OSIGNICIE PRZEWAGI KONKURENCYJNEJ
poprzez
Obnianie kosztw proceswPodnoszenie jakoci produktw
Skracanie czasu trwania proceswPodnoszenie satysfakcji klientw
-
Skala i zakres zmian w reinynierii
WSKI SZEROKI
WYGADZANIE
PRZEPROJEKTOWANIE
-
Analiza wariantw zmian
Skala zmian
Zakres zmian
Moliwe efektyUmiarkowana poprawa DziaalnociRyzyko:Due, due skomplikowanie
Moliwe efektyRadykalna poprawa caej dziaalnociRyzyko:Due, decyzja:wszystko albo nic
Moliwe efektyNiewielki wpyw na dziaalno firmyRyzyko:Mae
Moliwe efektyRadykalna poprawa wybranych proceswRyzyko:Ograniczone do wybranych procesw
-
Kontekst czasowy wdraania informatyki i reinynierii
Poprzedzenie reorganizacji procesw wdroeniem systemu informatycznego
Jednoczesne wdroenie systemu informatycznego i przeprowadzanie reorganizacji procesw
Przeprowadzenie reorganizacji procesw przed rozpoczciem procesu wdroenia systemu informatycznego
-
Najpierw system informatyczny, pniej 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
Wdroenie SI:
Reorganizacja:
-
Jednoczenie system informatyczny i reorganizacja
Zaleta: krtki czas przeprowadzania zmian i uzyskania korzyci, dobrze dopracowane zmiany i narzdzia
Wada: due ryzyko niepowodzenia, due obcienie zasobw ludzkich
Wdroenie SI:
Reorganizacja:
-
Najpierw reorganizacja, pniej system informatyczny
Zaleta: brak
Wada: bardzo kosztowne stosowanie narzdzi zastpczych/starych, niebezpieczestwo zaniecha lub spycenia zmian, ktre wymagaj wsparcia informatycznego
Wdroenie SI:
Reorganizacja:
-
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 systemw informatycznych
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 systemw informatycznych
zajmuje si
Inynieria systemw informatycznych
(zwana rwnie inynieri oprogramowania)
-
Czym zajmuje si inynieria systemw informatycznych?
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
-
Czym zajmuje si inynieria systemw informatycznych? Okrela:
Sposoby prowadzenia przedsiwzi informatycznych;
Techniki planowania, szacowania kosztw, harmonogramowania i monitorowania;
Metody analizy i projektowania systemw;
Techniki zwikszania niezawodnoci oprogramowania;
-
Czym zajmuje si inynieria systemw informatycznych? 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 proceswwytwarzania 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 PZUInformatyzacja ZUSSystem POJAZDInformatyzacja urzdw skarbowych
-
The Standish Group
Kolejne raporty: The CHAOS Chronicles od 1994 r. do 2013 r.
Amerykaska instytucja badawcza.Dziaalno: kompleksowa analiza rynku amerykaskiego w zakresie skutecznoci realizacji projektw informatycznych. www.standishgroup.com
-
Dlaczego CHAOS?
O chaosie w projektowaniu SI decyduje przewaajcaliczba 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.
Chaos stan niezorganizowania, zamtu, nieadu
rdo: http://versionone.com/assets/img/files/ChaosManifesto2013.pdf
-
Udany projektZakres
Czas
Koszty
Produkt kocowy
TerminKoszty realizacji
Udany projekt
-
Realizacja projektw - statystykiRok
Jakie projekty
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 %
rdo: http://versionone.com/assets/img/files/ChaosManifesto2013.pdf
0%10%
20%
30%40%
50%60%
70%
80%90%
100%
2004 2006 2008 2010 2012
Udane projekty
Nieudane cakowicie
Nieudane czciowo
-
Realizacja projektw - statystyki
Rok
czynnik
2004 2006 2008 2010 2012
Czas 84 % 72 % 79 % 71 % 74 %
Koszt 56 % 47% 54 % 46 % 59 %
Zrealizowanafunkcjonalno zaprojektowana
64 % 68 % 67 % 74 % 69 %
rdo: http://versionone.com/assets/img/files/ChaosManifesto2013.pdf
0%
10%
20%
30%
40%
50%
60%
2004 2006 2008 2010 2012
Nieudane czciowo
Nieudane cakowicie
Udane projekty
-
Czynniki sukcesuCzynnik 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
Dowiadczony kierownik zespou Brak (ew. 7) 14%
Formalna metodyka Brak 6%
Zastosowanie standardw infrastruktury Brak 8%
Wiarygodne oszacowanie Brak (ew. 4) 5%
Inne 1% 5%
-
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 6
Dojrzaoci rodowiska 5
Realne oczekiwania - wykonalno 3
Narzdzia i infrastruktura 1
Wyniki badania 20 maych(do 1mln$) projektw
ukoczonych w 2012 r.
rdo: http://versionone.com/assets/img/files/ChaosManifesto2013.pdf
-
Mae a due projekty rnice w osigniciu sukcesu
Projekty mae (do 1 mln $) Projekty due (powyej 10 mln $)
Nieudane czciowo
Nieudane cakowicie
Udane projekty
Nieudane czciowo
nieudane ckowicie
udane projekty
Dane z 2012 roku
rdo: http://versionone.com/assets/img/files/ChaosManifesto2013.pdf
-
Wnioski z badaChaos w obszarze projektowania SI spowodowany jest bdami ludzkimi, a nie czynnikami technologicznymiSI 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 ).
-
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
Podstawowe problemy w tworzeniu SI
-
rda zoonoci systemw informatycznych
Software
Zoono technologiczna
Zoono dziedzinowa
Zoono psychologiczna
-
Metody projektowaniaCigle niedoskonae metody i narzdzia tworzenia i weryfikacji systemw informatycznych
UML
DFDERD
XP
SADT
PSL/PSA
RSL/REVS
HELP!
-
Kryzys oprogramowaniaDugi 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
gwne bdy powstaj na styku: klient firma informatyczna, projektant-programista, programista-komputer
jeeli gdziekolwiek moe pojawi si bd, tam na pewno si pojawinie ma programw bezbdnych, s tylko takie w ktrych dotd nie znaleziono bdu
-
Obecne i postulowane zastosowania SI - rodzaje SI
Transakcyjne on-lineTransakcyjne off-lineProste systemy raportujceSystemy informowania kierownictwaSystemy inteligentne
Zoono
Cza
s re
akcj
i
Dua
Maa
Krtki
Dugi
Istniej oczywicie wyjtki np. bankowe systemy kredytowe
-
1960 1970 1980 1990 2000
IC
MRP
MRP II
ERP
DEM
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 ilociMRP II (Manufacturing Resource Planing) - planowanie zasobw produkcyjnychposzerzone 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
CRM (Customer Relationship Management) - zarzdzanie kontaktami z klientem
Ewolucja SI do zarzdzania firm
-
Standard MRP II Plus to rozwinicie koncepcji wariantu rozwinitego standarduMRP 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.
MRP II Plus (ERP)
-
Standard DEM to zintegrowane narzdzie umoliwiajce zarwno opracowanienowych 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 modeleodniesienia.
GWNA BIBLIOTEKA WZORCW (REPOZYTORIUM)
MODEL ODNIESIENIA
BIBLIOTEKA KOMPONENTW
FAZY ZAKRES
PROJEKT MODELU PROJEKT MODELU
LOKALNEGO
Model oglny
Model branowy
Model przedsibiorstwa
DEM
-
Wprowadza si tu optymalizacj, ktra pozwala na bieco wprowadzazmiany w funkcjonowaniu firmy. Dziki temu przedsibiorstwo wraz zsystemem yje i ewoluuje.
krytyczne wskaniki sukcesu
wizjaImplementacja
(faza podstawowa)optymalizacja. . . . . . . . . . . . . . . . . .
optymalizacja
dyskusje symulacje
model funkcjonalny
model procesowy
dyskusje z Zarzdem
przegld z uytkownikami kluczowymi
DEM
-
Strategia rozwoju organizacji i informatyzacji
MISJA ORGANIZACJIMISJA ORGANIZACJI
BADANIE OTOCZENIA(szanse i zagroenia)
BADANIE ORGANIZACJI
(mocne i sabe strony)
WIEDZA O RYNKUTRENDY
TECHNOLOGICZNE
STRATEGIA ROZWOJU ORGANIZACJI
STRATEGIA INFORMATYZACJI ORGANIZACJI
-
stacje robocze systemuserwer przedsibiorstwa
serwer kontrahenta serwer klienta serwer dostawcy
sie rozlega
sie lokalna
ZSI a otoczenie organizacji moliwoci systemw rozproszonych
ZSI
-
SystemySystemy klasyklasy MRP,MRP, ERPERP stanowistanowi rozwizaniarozwizania dedykowanededykowane wewntrznemuwewntrznemuzarzdzaniuzarzdzaniu przedsibiorstwemprzedsibiorstwem..SystemySystemy CRMCRM ((CustomerCustomer RelationshipRelationship ManagementManagement)) pozwalajpozwalaj rwnierwniezarzdzazarzdza kontaktamikontaktami zz klientemklientem..
back office
KLI
EN
T (K
ON
TRA
HE
NT)
KLI
EN
T (K
ON
TRA
HE
NT)
CRMCRMMRP (ERP)
PRZEDSIBIORSTWO - ORANIZACJA
front office
Systemy CRM
-
CRM(Customer Relationship Management)
CM (Contact Management)
proste jednostanowiskoweaplikacje,
funkcje kalendarza i bazadanych pozwalaj na analizdanych dotyczcych klienta ihistorii kontaktw
SFA(Sales Force Automation)
udostpnianie klientowi informacji on-line,
zarzdzanie sprzeda, obsuga klienta w ramach
jednego systemuoraz:oraz:
CRS - Call Reporting SystemsTMS - Territory Management SystemsSMS - Sales Management SystemsSTA - Sales Team Automation
Systemy CRM
-
WWW E-mail fax ... telefonSystemy wymiany informacji
OBSUGA KLIENTW
SERWISMARKETING SPZREDA
zarzdzania firm zarzdzania zasobami
ludzkimi zarzdzania finansami
SYSTEMY INFORMATYCZNE HURTOWNIE DANYCH
ZARZDZANIE WIEDZ
ANALITYKA
FRO
NT
OFF
ICE
BA
CK
OFF
ICE
KLIENCI
...
systemy obsugujce kanay komunikacji z klientem,systemy front-office obejmujce m.in. marketing, sprzeda,wsparcie klienta,
systemy analityczne.CRM:
-
sprzeda: zarzdzanie kontaktami (profile, struktura, historiakontaktw sprzeday),
zarzdzanie kontem (generowanie ofert, zamwienia,transakcje),
analizy w ramach cyklu sprzeday, monitorowanie statusu klienta i potencjalnych kontaktwhandlowych;
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 pomidzyurzdzeniami (np. laptopy) a centraln baz danych lub innymibazami i serwerami aplikacji;
e-commers - realizowanie handlu elektronicznego; call center - usugowe wsparcie klienta.
Funkcje (moduy) CRM:
-
systemy ewidencyjno-transakcyjne
STOPIE INTEGRACJI
CZASCZAS
1960 1970 1980 1990 2000
systemy informacyjno-decyzyjne
systemy wspomagania decyzjisystemy eksperckie
systemy informowania kierownictwa
systemy sztucznej inteligencji
zintegrowane systemy informatyczne
Ewolucja SIZ
systemy czasu rzeczywistego
-
system zarzdzania zorganizowany (SIZ) moduowo
obsugujcy wszystkie sfery dziaalnociprzedsibiorstwa
wszystkie zasoby danych, procedury zarzdzania,sterowanie i regulacja procesw wytwrczych sprzetwarzane przy wsparciu technologiiinformatycznej
Mwic o ZSI naley mie na uwadze:
Umoliwia etapowe wdraanie tych skadowych,ktre s niezbdne z uwagi na specyfik firmy.
Poczwszy od marketingu i planowania orazzaopatrzenia, poprzez techniczne przygotowanieprodukcji i jej sterowanie, dystrybucj, sprzeda,gospodark remontow, a do prac finansowo-ksigowych i kadrowych.
Ewolucja ZSI
-
Cechy ZSIZintegrowane systemy informatyczne stanowi urzeczywistnienie idei integracjikompleksowych systemw informatycznego wspomagania procesw zarzdzania wprzedsibiorstwie z kompleksowymi systemami komputerowego wytwarzania.
Gwne cechy ZSI:
kompleksowo funkcjonalna - obejmuje wszystkie sfery firmy,
integracja danych i procesw - dotyczy wymiany informacji wewntrz firmy jak iz jej otoczeniem,
elastyczno strukturalna (skalowalno) i funkcjonalna - dynamicznedopasowanie przy zmiennych wymaganiach i potrzebach otoczenia,
otwarto - moliwo rozbudowy systemu i tworzenie nowych poczezewntrznych,
zaawansowanie merytoryczne - moliwo penego informatycznego wsparciaprocesw informacyjno-decyzyjnych
zaawansowanie technologiczne - zgodno ze standardami sprztowo-programowymi oraz moliwo przenoszenia na inne platformy
zgodno z przepisami (np. ustaw o rachunkowoci)
-
Faza I - Analiza przedsibiorstwa obejmuje:okrelenie celw strategicznych przedsibiorstwazdefiniowanie problemw, wymaga i kryteriw wyboru ZSIudokumentowanie istniejcych procedur dziaaniaopracowanie opisw procesw podstawowych i pomocniczychprzygotowanie koniecznej restrukturyzacji przedsibiorstwaocena skali przedsiwzicia, ryzyka, kosztw i terminw realizacji
(studium wykonalnoci)
Faza II - Opracowanie koncepcji informatyzacji przedsibiorstwaobejmuje:
selekcja i wybr gotowego ZSIzestawienie oprogramowania aplikacyjnego wedug modelu
prototypowaniamodelowanie konfiguracji oprogramowania narzdziowego,
systemowego, sieciowego oraz opracowanie projektuinfrastruktury technicznej
Przykadowy sposoby integracji cd
-
Informatyzacja organizacji a problemy jej restrukturyzacji
(uwarunkowanie tworzenia ZSI)
Informatyzacja organizacji, majca na celu wdroenie ZSI, wymagapoprzedzenia tego procesu zmianami o charakterze organizacyjnym.
REALIZACJA ZSI
strategia rozwoju organizacji oraz
strategia jej informatyzacji
restrukturyzacja organizacji
techniczna infrastruktura
informatyki
oprogramowanie aplikacyjne oraz
transfer wiedzy
-
Restrukturyzacja jest przemyleniem od podstaw i radykalnymprzeprojektowaniem procesw gospodarczych w celu osigniciazdecydowanego 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 strategiprzedsibiorstwa oraz jego procedury operacyjne,
radykalna - w zalenoci od potrzeb tworzone (definiowane) s noweprocesy, a nie usprawniane istniejce,
istotna - wzrost efektywnoci ma na celu znaczne podniesieniesprawnoci funkcjonowania przedsibiorstwa, a nie jedynie jejmarginalny 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.
Informatyzacja organizacji a problemy jej restrukturyzacji
-
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, kulturawewntrz-organizacyjna, metody kierowania, rekrutacja imotywacja pracownikw
Informatyzacja nie moe wspiera nieefektywnych i niewydajnychprocesw. Dziaania restrukturyzacyjne powinny by nadrzdne wstosunku 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 systemuinformatycznego,
faza trzecia - tworzenie szczegowych specyfikacji procesw itworzenie ZSI.
Informatyzacja organizacji a problemy jej restrukturyzacji
-
Informatyzacja organizacji a problemy jej restrukturyzacji
Restrukturyzacja przedsibiorstwa
Przygotowanie infrastruktury informatycznej
Budowa ZSI
Podejcie konwencjonalne --dziaaniadziaania szeregoweszeregowe zzkoniecznocikoniecznoci modyfikacjimodyfikacjimodelowaniamodelowania proceswproceswgospodarczychgospodarczych popo drugimdrugim aanawetnawet trzecimtrzecim etapieetapie..
Restrukturyzacja przedsibiorstwa
Budowa ZSI
Uzyskanie kompletnej infrastruktury informatycznej
Podejcie zalecane -- dopuszczadopuszczasisi rwnolegorwnolego pracpracrestrukturyzacyjnychrestrukturyzacyjnych ii wstpnychwstpnychwdroeniowychwdroeniowych zz moliwocimoliwociiteracyjnegoiteracyjnego uszczegowianiauszczegowianiadziaadziaa wdroeniowychwdroeniowych iiprzygotowywaniaprzygotowywania docelowejdocelowejinfrastrukturyinfrastruktury..
-
Struktura SIFunkcjonalna (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 systemw informatycznych
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 Metody --> badanie metod > badanie metod -->wiedza >wiedza -->nauka>nauka
-
Metodologia
Nauka o metodach bada naukowych, ich skutecznoci i wartoci poznawczej to metodologia.
Klasycznie wyrnia si metodologie w:naukach cisychnaukach przyrodniczychnaukach spoecznych
Metody Metody --> badanie metod > badanie metod --> metodologia> metodologia
-
Metodyka a metodologia
metodologia skupia si na odpowiedzi na pytanie:
metodyka koncentruje si na poszukiwaniu odpowiedzi na pytanie:
Metodyka dy ku praktyce wykonawczej, a metodologia ku teorii zazwyczaj sprawnego dziaania.
Co naley robi?,
Jak to naley robi?
-
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 procesemrealizowanym etapowo w okrelonym czasie.W celu zapewnienia powtarzalnej jakoci realizowanegoprojektu definiuje si pojcie cyklu yciaoprogramowania dzielc cao przedsiwzicia naszereg tzw. faz ycia oprogramowania.Poszczeglnym stadiom rozwoju aplikacji
przyporzdkowuje si odpowiednie zestawy czynnoci,ktrych celem jest uporzdkowanie przebiegu prac,umoliwienie planowania i zarzdzania dostpnymizasobami.Rodzaj oraz kolejno zdefiniowanych faz skadaj sina 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
Analiza Wymaga
Projektowanie
Procesy
Interfejs uytkownika
Dane Wdraanie
EKSPLOATACJA
Planowanie strategiczne
-
ProjektProjekt - 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 pozwalazdefiniowa 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 strategiczna,aza strategiczna,okrelenie wymaga,okrelenie wymaga,analiza analiza modelowanie,modelowanie,projektowanie,projektowanie,implementacja oprogramowania,implementacja oprogramowania,integracja i testowanie SI,integracja i testowanie SI,wdroenie,wdroenie,utrzymanie,utrzymanie,likwidacja.likwidacja.
Okrelenie wymaga Projektowanie Implementacja Testowanie Utrzymanie
Faza strategiczna Analiza Wdroenie
Dokumentacja Likwidacja
-
W cyklu ycia SI wyrnia si W cyklu ycia SI wyrnia si fazy podstawowe: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 oprogramowanie jest wykorzystywane przez uytkownika, producent dokonuje konserwacji SI, wykonuje si uytkownika, producent dokonuje konserwacji SI, wykonuje si modyfikacje, zmiany i rozszerzania funkcji SI oraz usuwa modyfikacje, zmiany i rozszerzania funkcji SI oraz usuwa ewentualne bdy ewentualne bdy yy
-
Fazy dodatkowe w cyklu ycia Fazy dodatkowe w cyklu ycia SISI
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 Analiza Projektowanie Implementacja Zainstalowanie, testowanie,
usuwanie bdw Szkolenie i przekazanie
systemu uytkownikowi Utrzymanie i rozwj systemu Re-inynieria systemu / zastpienie systemu innym /
zamknicie systemu
Proces projektowania systemu
Wdroenie systemu
-
Cykl ycia SI -inaczejAnaliza
Projektowanie
Konstrukcja
Testowanie
Sprawdzenie osigniciacelw
Sprawdzenie zgodnoci ze specyfikacj
WDRAANIEWDRAANIE
-
Etapy cyklu ycia SI a dokumentacja
1. Okrelenie wymaga2. Projektowanie3. Implementacja4. Testowanie5. Rozwj & pielgnacja
Dokumentacja I
Zrozumienie problemu
Dokumentacja II
-
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
PlanowaniePlanowanie
AnalizaAnaliza
ProjektowanieProjektowanie
ImplementacjaImplementacja
TestowanieTestowanie
KonserwacjaKonserwacja
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.
Model kaskadowy jest uznawany czsto za doprzestarzay 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.
-
Programowanie odkrywcze
Sporzd Sporzd ogln ogln
specyfikacjspecyfikacj
Zbuduj Zbuduj systemsystem
Skorzystaj z Skorzystaj z systemusystemu
Dostarcz system
klientowi
System spenia System spenia wymagania?wymagania?
NieNieTakTak
Problemy wynikajce podczas programowania odkrywczego Problemy wynikajce podczas programowania odkrywczego (ang. (ang. exploratoryexploratoryprogrammingprogramming) ) to midzy innymi:to midzy innymi:
brak prawdziwej i penej specyfikacji co uniemoliwia kompletn weryfikacj systemu, brak prawdziwej i penej specyfikacji co uniemoliwia kompletn weryfikacj systemu,
bardzo kosztowna i trudna konserwacja tak zbudowanego systemu,bardzo kosztowna i trudna konserwacja tak zbudowanego systemu,
niespjna i do chaotyczna struktura systemuniespjna i do chaotyczna struktura systemu
-
Model spiralny
Definiowanie
Analiza
Projektowanie
Implementacja
-
Model spiralny
Model spiralny zostazaproponowany 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
Okrelanie wymaga
Projektowanie
Implementacja
Testowanie
Pielgnacja
56%56%26 %
7%
Koszty usuwania bdw na etapie Pielgnacji oprogramowania s 200 razy wiksze ni na etapie Okrelania wymaga na
Etap
Ilo bdw
0.1
0.5
1
5
20
-
Od techno- do antypo-centry-cyzmu w projektowaniu SI
Klasyczne podejcie do projektowania systemw informatycznych dla zarzdzania byo techno-centryczne. 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-centry-cyzmu 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)
-
Dziedzina Dziedzina przedmiotowa (DP)przedmiotowa (DP)
PROCES TWORZENIA PROCES TWORZENIA SYSTEMU SYSTEMU
INFORMATYCZNEGOINFORMATYCZNEGOZesp Zesp
projektujcyprojektujcy
SISI
Wyniki analizWyniki analiz Cele problemy, potrzeby Cele problemy, potrzeby informatyczneinformatyczne
KryteriaKryteria
ocenyoceny
Korekty i modyfikacjeKorekty i modyfikacje
Prezentacjai eksperymentalna
eksploatacja
tworzenietworzenie
kierowaniekierowanie
ModeleModele
DPDP
Metody i Metody i technikitechniki
Narzdzia Narzdzia komputerowegkomputerowego wspomaganiao wspomagania
Reguy Reguy modelowaniamodelowania
parametryparametry pakietypakiety
ZadaniaZadania
wymaganiawymagania
FazyFazy
dokumentacjadokumentacja
Pojcia Pojcia abstrakcyjneabstrakcyjne
rodowisko metodyki tworzenia SI
-
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 systemu informatycznego
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 systemu informatycznego
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
Podejcie prognostyczne
czasStan obecny
-
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 osigalnoci)
Okrelenie wymaga Projektowanie Implementacja Testowanie Konserwacja
Faza strategiczna Analiza InstalacjaDokumentacja
strategy phase, feasibility study
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
Wykonawca
Zleceniodawca Przyszy uytkownik
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 celwprzedsiwzicia 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.)
Klient
-
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
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.
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.
-
Decyzje strategiczneWybr modelu, zgodnie z ktrym bdzie realizowane przedsiwzicieWybr technik stosowanych w fazach analizy i projektowaniaWybr rodowiska (rodowisk) implementacjiWybr narzdzia CASE Okrelenie stopnia wykorzystania gotowych komponentw Podjcie decyzji o wsppracy z innymi producentami lub zatrudnieniu ekspertw
OgraniczeniaMaksymalne 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 przedsiwziciaUstalenie planu czasowego dla poszczeglnych faz i zada.
Diagram Gantta
GrudNazwa zadania
Wstpne zbieranie wymaga
Budowa prototypu
Ocena prototypu
Opracowanie wymaga
Analiza
Projekt dziedziny problemu
Projekt interfejsu uytkown.
Projekt bazy danych
ListoPadWrzeSierpLipCzerStycz Luty Marz Kwie Maj
-
Ocena rozwiza
W fazie strategicznej czsto rozwaa si kilka rozwiza, z powodw wieloci celw przedsiwzicia (czyli kryteriw oceny) lub niepewnoci (niemoliwoci precyzyjnej oceny spodziewanych rezultatw).
Czste kryteria oceny: koszt czas realizacji niezawodno moliwo ponownego uycia przenono na inne platformy wydajno (szybko)
Prezentacja i porwnanie poszczeglnych rozwizaw postaci tabelarycznej
RozwizanieKoszt (tys. z)Czas (miesice)Niezawodno (bdy/tydzie)Ponowne uycie (%)Przenono (%)Wydajno(transakcje/sek)
A120
335
4090
0.35
B8030
94075
0.75
C175
36133030
1
Oszacowanie wartoci podanych w tabeli moe by trudnym problemem.
-
Niepewno i ryzyko
Niepewno jest czynnikiem utrudniajcym wybr najlepszego rozwizania.
Optymistyczne i pesymistyczne oszacowania:
RozwizaniePesymistyczny koszt [tys z]Optymistyczny koszt [tys z]
A100
40
B8065
Mona wybra jedno z dwch rozwiza, A lub B, w zalenoci od tego, czy przyjmujemy optymistyczny, czy te pesymistyczny punkt widzenia.
Prawdopodobiestwo subiektywne
RozwizaniePrawdopodobiestwo pesymistycznego rozwizaniaPrawdopodobiestwo optymistycznego rozwizania
A0.50.5
B0.20.8
Poprzez pomnoenie kosztw przez prawdopodobiestwa uzyskujemy spodziewany koszt: A: 100 * 0.5 + 40 * 0.5 = 50 + 20 = 70B: 80 * 0.2 + 65 * 0.8 = 16 + 52 = 68 : rozwizanie B jest lepszeZe wzgldu na subiektywno oszacowa naley jednak rozway wiele wariantw.
-
Drzewa ryzykaWierzchoki drzewa odpowiadaj sytuacjom, w ktrych mog zaj pewne zdarzenia.Krawdzie oznaczaj przejcia do nowych sytuacji.Krawdziom s przypisane prawdopodobiestwa.Kady scenariusz zdarze (li w drzewie) jest zwizany z kosztem.
PrzykadFirma chce przystpi do przetargu. Przygotowanie oferty przetargowej jest kosztowne. Firma moe przetarg wygra lub przegra. Zatrudnienie dodatkowego eksperta zwiksza szans firmy. Co robi?
Zatrudnienieeksperta
Przetarg Przetarg
Zatrudnionoeksperta0.8
Nie znalezionoeksperta
0.2
Sukces0.9
Sukces0.5
Poraka0.1
Poraka0.5
Zysk +45 - 20 +55 -10
Oczekiwany zysk 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 kodurdowego. 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 bdomwione punkty funkcyjne). Miary te, jakkolwiek niedokadne i oparte naszacunkach, s jednak konieczne. Niemoliwe jest jakiekolwiek planowania bezoszacowania 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 ichjako obiektywnych wartoci policzonych przez komputer. Podstaw wszystkichmiar s szacunki, ktre mog by obarczone znacznym bdem, nierzadko o rzdwielkoci. Miary naley traktowa jako latarni morsk we mgle - moe ona nasnaprowadzi na dobry kierunek, moe ostrzec przed niebezpieczestwem.Obowizuje zasada patrzenia na ten sam problem z wielu punktw widzenia (wielernych miar) i zdrowy rozsdek.
-
Metoda szacowania kosztw COCOMO
COnstructive COst MOdel
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.
-
Metoda punktw funkcyjnych
Function Point Analysis, FPA
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 DelphiMetoda 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 systemuMetody oszacowania pracochonnoci dokumentacjiMetody 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
-
Podstawowe rezultaty fazy 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
Okrelenie wymaga Projektowanie Implementacja Testowanie Konserwacja
Faza strategiczna Analiza Instalacja
Dokumentacja
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.
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 wymagaKlient 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 wymagaDobry 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 Projektowanie Implementacja Testowanie Konserwacja
Faza strategiczna Analiza Instalacja
Dokumentacja
-
Zalecenia dla fazy definicji wymaga
Wymagania uytkownikw powinny by wyjaniane poprzez krytyk iporwnania z istniejcym oprogramowaniem i prototypami.
Powinien by uzyskany stan porozumienia pomidzy projektantami iuytkownikami dotyczcy projektowanego systemu.
Wiedza i dowiadczenia potencjalnej organizacji podejmujcej si rozwojusystemu 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 wymagaWywiady 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 funkcjonalneOpisuj 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 wymagaFormalizm matematyczny. Stosuje si rzadko, dla dobrze zdefiniowanychproblemw raczej o maej skali.
Jzyk naturalny strukturalny. Jzyk naturalny z ograniczonym sownictwemi skadni. Poszczeglne tematy i zagadnienia wyspecyfikowane w punktach ipodpunktach.
Tablice, formularze. Wyspecyfikowanie wymaga w postaci (zwykledwuwymiarowych) tablic, kojarzcych rne aspekty (np. tablica ustalajcazaleno pomidzy typem uytkownika i rodzajem usugi).
Diagramy blokowe: tradycyjna forma graficzna pokazujca wymagany cyklprzetwarzania.
Diagramy kontekstowe: ukazuj system w postaci jednego bloku oraz jegopowizania z otoczeniem, wejciem i wyjciem.
-
Formularz wymaga funkcjonalnychW formularzach zapis jest podzielony na konkretne pola, co pozwala na atwe stwierdzenie kompletnoci opisu oraz na jednoznaczn interpretacj.
Nazwa funkcjiOpis
Dane wejciowe
rdo danychwejciowychWynikWarunekwstpny
WarunekkocowyEfekty ubocznePowd
Edycja dochodw pracownikaFunkcja pozwala edytowa czne dochody podatnika uzyskane w danym roku.
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.
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.
Przykad jednej zapenionej tabeli wg przyjtego formularza:
-
Porzdkowanie wymagaHierarchia wymaga funkcjonalnych:Z reguy funkcje mona rozbi na podfunkcje.
Format tekstowy:
Funkcja nadrzdna f1funkcja f1.1funkcja f1.2funkcja f1.3
funkcja f1.3.1funkcja f1.3.2funkcja f1.3.3
funkcja f1.4funkcja f1.4.1funkcja f1.4.2funkcja f1.4.3
Notacje graficzne:
funkcja f1
funkcja f1.4.3
funkcja f1.4.2
funkcja f1.4.1
funkcja f1.4
funkcja f1.3.2
funkcja f1.3.3
funkcja f1.3
funkcja f1.1
funkcja f1.2
funkcja f1.3.1
funkcja f1
funkcja f1.3funkcja f1.1 funkcja f1.2
funkcja f1.3.2
funkcja f1.3.3
funkcja f1.3.1
Na kadym poziomie ten sampoziom 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)
Ewidencja zlece Edycja technologicznego opisu wydziau Harmonogramowanie zlece
Wczytywanie informacji o zleceniach
Wydruk informacji o zleceniach
Wywietlanie informacji o zleceniach
Edycja opisu maszyn
Sprawdzanie kompletnoci opisu
Wydruk informacji technologicznych
Edycja opisu operacji
Edycja opisu wyrobw
Ustalanie harmonogramu
Edycja harmonogramu
Graficzna prezentacja harmonogramu
Wydruk harmonogramu
Przygotowanie kart zadaPrzygotowanie zamwie na pprodukty
-
Wymagania niefunkcjonalneOpisuj 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
CechaWydajno
Rozmiar
atwouytkowaniaNiezawodno
Przenaszalno
Weryfikowalne miaryLiczba transakcji obsuonych w cigu sekundyCzas odpowiedziSzybko odwieania ekranuWymagana pami RAMWymagana pami dyskowaCzas niezbdny dla przeszkolenia uytkownikwLiczba stron dokumentacjiPrawdopodobiestwo bdu podczas realizacji transakcjiredni czas pomidzy bdnymi wykonaniamiDostpno (procent czasu w ktrym system jest dostpny)Czas restartu po awarii systemuPrawdopodobiestwo zniszczenia danych w przypadku awariiProcent kodu zalenego od platformy docelowejLiczba platform docelowychKoszt przeniesienia na now platform
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.
-
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.
-
Istotne czynniki definiowania wymaga niefunkcjonalnych
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.
-
Istotne czynniki definiowania wymaga niefunkcjonalnych
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 wymagaWymagania 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 sownikaOpis 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
StylJasno: 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
OdpowiedzialnoOkrelenie kto jest odpowiedzialny za sformuowanie danego wymagania, istotne w przypadku modyfikacji.
Medium
Dokument papierowy lub elektroniczny.Staranne kontrolowanie wersji dokumentu.
-
Zawarto dokumentu
Przykadowyspis
treci
StreszczenieSpis treciStatus dokumentu (roboczy, 1-sza faza, zatwierdzony, ...)Zmiany w stosunku do wersji poprzedniej
Informacjeorganizacyjne
1. Wstp1.1. Cel1.2. Zakres1.3. Definicje, akronimy i skrty1.4. Referencje, odsyacze do innych dokumentw1.5. Krtki przegld
2. Oglny opis2.1. Walory uytkowe i przydatno projektowanego systemu2.2. Oglne moliwoci projektowanego systemu2.3. Oglne ograniczenia 2.4. Charakterystyka uytkownikw2.5. rodowisko operacyjne2.6. Zaoenia i zalenoci
3. Specyficzne wymagania3.1. Wymagania co do moliwoci systemu3.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
-
Faza analizy
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.
Okrelenie wymaga Projektowanie Implementacja Testowanie Konserwacja
Faza strategiczna Analiza InstalacjaDokumentacja
Analiza
-
Analiza
Rozpoznanie, wyjanianie, modelowanie, specyfikowanie i dokumentowanierzeczywistoci lub problemu bdcego przedmiotem projektu;
Ustalenie kontekstu projektu;
Ustalenie wymaga uytkownikw;
Ustalenie wymaga organizacyjnych
Inne ustalenia, np. dotyczce preferencji sprztowych, preferencji w zakresieoprogramowania, ogranicze finansowych, ogranicze czasowych, itd.
Analiza wcza nastpujce czynnoci:
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 analitycznyZ 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. Zakres
odpowiedzialnocisystemu
Model analityczny
Dziedzina problemu
-
Notacje w fazie analizieRodzaje notacji
Jzyk naturalnyNotacje graficzneSpecyfikacje - 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 pomyswWsppraca z uytkownikiemKomunikacja z innymi czonkami zespouPodstawa implementacji oprogramowaniaZapis 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. Analizastrukturalna rozpoczyna si od budowy dwch rnych modelisystemu: modelu danych oraz modelu funkcji. Te dwa modele sintegrowane. Wynikiem jest model przepywu danych. Wadpodejcia s trudnoci w zintegrowaniu modeli.
Metodyki obiektowe - rozwijane od lat 80-tych, oparte nawyrnianiu obiektw cznie z operacjami. Ostatnio coraz bardziejpopularne.
-
Metodyki strukturalne
DIAGRAMY ZWIZKU ENCJI - ERDDIAGRAMY PRZEPYWU DANYCH DFDDIAGRAMY 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)
-
189
Model (diagramy) E/R
Model zaproponowany w publikacji P.P.Chen: The Entity-relationship 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-zwiazekModel zwizku encjiModel obiektowo-zwizkowy
Entities and relationspips are a natural way to organize physical things as well as information (Peter Chen)
-
190
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)
-
191
Definicje skadowych diagramu ERD (lub ER lub E/R)
Zbir encja (entity sets) analogia klasy, encje jako elementy zbioru encji s odpowiednikami obiektw, bdcyc