Modele i metody eksploracji danych

Istota projektowania

strukturalnego

Z metod projektowania systemów informatycznych

obecnie najczęściej stosowanych w praktyce zdecydowanie wciąż
wyróżnia się metody oparte na

podejściu strukturalnym

, chociaż

za nowocześniejsze uważa się

podejście obiektowe

Istotą

metod projektowania strukturalnego

jest

upraszczanie złożonego systemu poprzez systematyczne
rozkładanie go na prostsze elementy składowe wraz z
koncentracją uwagi na coraz drobniejszych szczegółach,
przy czym określa się w postaci strumieni informacyjnych
relacje wiążące te wyróżnione elementy składowe.

Metody projektowania strukturalnego przedstawiają

podejście formalne oparte na tworzeniu systemu całościowego,
składającego się z wydzielonych elementów podrzędnych, o
hierarchicznej strukturze zstępującej, powiązanych dobrze
zdefiniowanymi modułami relacji i funkcji.

W projektowaniu strukturalnym zakłada się

naprzemienne etapy:

analizy

syntezy

(projektowanie) i

oceny

(wdrożenia testowe).

GK (PSI(2) - 2009)

Istota projektowania

strukturalnego

Podstawowe koncepcje projektowania
strukturalnego:

zasada uściślania krokowego

(faza analizy),

zasada modularyzacji

(faza projektowania).

Obowiązują dwa zasadnicze kryteria:



kryterium spójności modułów

(cohesion)

- moduły

muszą współpracować ze sobą, nie mogą być
sprzeczne, muszą komplementarnie się uzupełniać,



kryterium więzi międzymodułowych

(coupling)

integrowanie wyników pracy innych modułów,
współpraca między modułami a systemem.

Przyjęta strukturalna metoda TSI obejmuje

następujące

fazy realizacji systemu



Definicji,



Analizy,



Projektu,



Budowy,



Wdrożenia,



Eksploatacji.

W ramach każdej z tych faz realizowanych jest z różnym

nasileniem 11 następujących

procesów tworzenia systemu

informatycznego



Definicji wymagań,



Badania istniejących systemów,



Projektu i budowy bazy danych,



Projektu i budowy modułów,



Konwersji danych,



Dokumentowania,



Testowania,



Szkolenia,



Wdrożenia,



Asysty po wdrożeniu.

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

Głównym celem fazy DEFINICJI

jest określenie funkcji

zarządzania najwyższego poziomu zarządzania oraz wymagań
systemu informacyjnego niezbędnych do ujęcia w
przewidywanym systemie informatycznym. Faza DEFINICJI
kończy się określeniem obszaru funkcjonalnego tworzonego
systemu informatycznego.

Cele fazy DEFINICJI:



rozpoznanie i zrozumienie funkcji i procesów zarządzania

(biznesowych) zachodzących w informatyzowanej organizacji,



rozpoznanie i zrozumienie zawartości oraz przepływów

strumieni danych związanych z realizacją funkcji i procesów

zarządzania,



zbadanie rozpoznanych funkcji i procesów zarządzania oraz

systemu informacyjnego z punktu widzenia wymagań

określanych dla przyszłego systemu informatycznego,



określenie wymagań dotyczących systemu informatycznego i

jego komunikacji (interfejsu) z otoczeniem,



określenie wymagań dotyczących architektury i konfiguracji

sprzętu dla systemu informatycznego,



uzyskanie akceptacji kierownictwa organizacji dla dalszych

prac związanych z tworzeniem systemu informatycznego.

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza DEFINICJA

efi

liz

że

Definicja wymagań
Badanie istniejących systemów
Architektura techniczna
Projekt i budowa bazy danych
Projekt i budowa modułów
Konwersja danych
Dokumentacja
Testowanie
Szkolenie
Wdrożenie
Asysta po wdrożeniu

Udział procesów tworzenia systemu informatycznego w

realizacji fazy DEFINICJA

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza DEFINICJA

GK (PSI(2) - 2009)

Udział procesów tworzenia systemu informatycznego w

realizacji fazy DEFINICJA

Proces

Udział

procentowy w

realizacji fazy

Definicja wymagań

52,7

Badanie

istniejących

systemów

18,2

Architektura techniczna

5,5

Projekt i budowa bazy
danych
Projekt i budowa modułów

Konwersja danych

7,3

Dokumentacja

1,8

Testowanie
Szkolenie
Wdrożenie
Asysta po wdrożeniu

Zarządzanie projektem

14,5

Metoda projektowania

strukturalnego

faza DEFINICJA

Wejście do

fazy DEFINICJA

(powinny zostać dostarczone

zespołowi projektującemu praz zamawiającego, a w
przypadku, gdy ich nie dostarczy – projektant musi wytworzyć
je sam):



model procesów biznesowych istniejącego systemu,



model danych wysokiego poziomu,



standardy dokumentacji i formularze.

Wyniki

fazy DEFINICJA



model zdarzeń i procesów biznesowych,



model funkcji wysokiego poziomu,



model wymagań informacyjnych,



definicja struktury organizacji (elementy wewnętrzne i

zewnętrzne organizacji, które mają współpracować z

tworzonym systemem,



wstępna architektura techniczna (wymagania dotyczące

sprzętu, oprogramowania, narzędzi i konfiguracji),



wstępne wymagania dotyczące interfejsu tworzonego

systemu.

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza DEFINICJA

Czynniki zapewniające poprawną realizację fazy DEFINICJA:


jasne sformułowanie celów tworzonego systemu

informatycznego (zarząd organizacji),



aktywne uczestniczenie członków zarządu organizacji i

bezpośrednich przyszłych użytkowników systemu

informatycznego w pracach nad tworzeniem systemu,



zagwarantowanie pełnego dostępu zespołowi projektującemu

system informatyczny do informacji o procesach zarządzania

oraz o istniejącym systemie informacyjnym i istniejących

systemach informatycznych w organizacji i mogących wywierać

wpływ na tworzony system informatyczny,



kierownik projektu potrafi efektywnie zarządzać procesem

tworzenia systemu informatycznego.

Ryzyko występujące w procesie realizacji fazy DEFINICJA

wynika głównie z:


niewłaściwego określenie zakresu i/lub dziedziny systemu,



braku środków finansowych na wytworzenie systemu

informatycznego,



braku należytego doświadczenia zespołu projektowy do

prowadzenia prac nad systemem informatycznym o wymaganym

zakresie w danej dziedzinie.

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza DEFINICJA

Głównym celem fazy ANALIZA

jest sformułowanie szczegółowych

wymagań do tworzonego systemu informatycznego.

Cele fazy ANALIZA:


utworzenie wiernych i kompletnych modeli procesów

biznesowych, funkcji zarządzania i danych dla tworzonego
systemu informatycznego,



opracowanie szczegółowych wymagań funkcjonalnych,

informacyjnych i operacyjnych dla tworzonego systemu
informatycznego,



określenie architektury technicznej sprzętu komputerowego i

oprogramowania systemowego dla potrzeb tworzonego systemu
informatycznego,



opracowanie metodyki przechodzenia od aktualnego

systemu(ów) do tworzonego systemu informatycznego.

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza ANALIZA

efi

liz

że

Definicja wymagań

Badanie istniejących systemów
Architektura techniczna
Projekt i budowa bazy danych
Projekt i budowa modułów
Konwersja danych
Dokumentacja
Testowanie
Szkolenie

Wdrożenie

Asysta po wdrożeniu

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza ANALIZA

Udział procesów tworzenia systemu informatycznego w

realizacji fazy ANALIZA

GK (PSI(2) - 2009)

Proces

Udział

procentowy w

realizacji fazy

Definicja wymagań

45,9

Badanie

istniejących

systemów

13,2

Architektura techniczna

12,3

Projekt i budowa bazy
danych
Projekt i budowa modułów

Konwersja danych

9,8

Dokumentacja

0,8

Testowanie

0,8

Szkolenie

2,5

Wdrożenie

0,8

Asysta po wdrożeniu

Zarządzanie projektem

13,9

Metoda projektowania

strukturalnego

faza ANALIZA

Udział procesów tworzenia systemu informatycznego w

realizacji fazy ANALIZA

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza ANALIZA

Wejście do

fazy ANALIZA:



modele procesów biznesowych i funkcji,



model wymagań informacyjnych,



definicja struktury organizacyjnej,



istniejący system interfejsów,



wymagania interfejsu systemowego,



istniejąca architektura techniczna,



architektura techniczna (inicjująca),



wymagania konwersji danych.

Wyniki

fazy ANALIZA



model danych - model związków encji, opisujący logiczną strukturę

danych,



szczegółowy model procesów biznesowych i funkcji - szczegółowy opis

procesów i funkcji z określeniem ich hierarchii i innych powiązań,



model funkcji systemu i ich powiązania z funkcjami

nieinformatyzowanymi,



techniczna architektura sprzętu i oprogramowania, wymagana dla

działania nowego systemu,



strategia konwersji danych,



wymagania do szkoleń,



wstępna strategia wdrażania – opis polityki wdrażania systemu i opis

jego powiązań informacyjnych z systemem istniejącym oraz wymagania

do szkoleń personelu z zakresu możliwości i sposobów korzystania z

nowego systemu.

Czynniki zapewniające poprawną realizację fazy ANALIZA:



powołanie komisji użytkownika do oceniania rozwiązań

proponowanych przez zespół projektowy,



stosowanie wymaganych standardów dokumentacyjnych dla

kontrolowania kompletności wyników prac projektowych oraz ich

zgodności z wymaganiami zamawiającego system,



kompletne i dobrze przygotowane wyniki fazy DEFINICJA,



dobrze określona strategia rozwoju systemu informacyjnego

organizacji,



dobrze określona architektura techniczna istniejącego

systemu(ów) informatycznych w organizacji, z którymi ma

współpracować system tworzony.

Ryzyko występujące w procesie realizacji fazy ANALIZA wynika

głównie z:



rozpoczęcia tej fazy bez akceptacji przez zamawiającego wyników

fazy DEFINICJA,



braku należytego doświadczenia zespołu projektowego w zakresie

przewidzianych do stosowania (też wymaganych przez

zamawiającego) metod i narzędzi prowadzenia prac projektowych,



tego, że zamawiający (lub jego przedstawiciel) nie uczestniczy w

pracach koncepcyjnych i oceniających w zakresie uzgodnionym z

kierownikiem projektu,



tego, że kierownik projektu nie przestrzega ściśle zasad przyjętej

metodyki tworzenia systemu,



niewłaściwie dostosowanego zakresu szkolenia użytkownika do

zakresu systemu informatycznego.

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza ANALIZA

efi

liz

że

Definicja wymagań

Badanie istniejących systemów
Architektura techniczna
Projekt i budowa bazy danych
Projekt i budowa modułów
Konwersja danych
Dokumentacja
Testowanie
Szkolenie

Wdrożenie

Asysta po wdrożeniu

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza PROJEKT

Udział procesów tworzenia systemu informatycznego w

realizacji fazy PROJEKT

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza PROJEKT

Udział procesów tworzenia systemu informatycznego w

realizacji fazy PROJEKT

Proces

Udział

procentowy w

realizacji fazy

Definicja wymagań
Badanie

istniejących

systemów

Architektura techniczna

1,0

Projekt i budowa bazy
danych

3,3

Projekt i budowa modułów

60,2

Konwersja danych

6,0

Dokumentacja

7,5

Testowanie

6,1

Szkolenie

1,5

Wdrożenie

0,2

Asysta po wdrożeniu

Zarządzanie projektem

14,2

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza PROJEKT

Wejście do

fazy PROJEKT:



model danych - model związków encji, opisujący logiczną

strukturę danych,



model procesów biznesowych i funkcji - szczegółowy opis

procesów i funkcji z określeniem ich hierarchii i innych

powiązań,



techniczna architektura sprzętu i oprogramowania,



wymagania dotyczące bezpieczeństwa tworzonego systemu,



strategia konwersji danych,



wymagania dokumentacyjne,



strategia wdrażania.

Wyniki

fazy PROJEKT



projekt logiczny bazy danych,



projekt standardów określenie reguł, do który powinni stosować

się projektanci,



projekt aplikacji - katalog wszystkich modułów aplikacji wraz ze

wskazaniem w jaki sposób będą one wspierały procesy i funkcje

biznesowe,



wstępna wersja dokumentacji użytkownika - przewodnik

użytkownika,



wstępna wersja dokumentacji technicznej (w tym wskazania dla

programistów do wykonania i do testowania oprogramowania),



model testowania procesów systemowych - model testowania,

zawierający odpowiednie scenariusze pełnego testu modułów

wspomagających każdy proces i funkcję biznesową.

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza PROJEKT

Wejście do

fazy PROJEKT:



model danych - model związków encji, opisujący logiczną

strukturę danych,



model procesów biznesowych i funkcji - szczegółowy opis

procesów i funkcji z określeniem ich hierarchii i innych

powiązań,



techniczna architektura sprzętu i oprogramowania,



wymagania dotyczące bezpieczeństwa tworzonego systemu,



strategia konwersji danych,



wymagania dokumentacyjne,



strategia wdrażania.

Wyniki

fazy PROJEKT



projekt logiczny bazy danych,



projekt standardów określenie reguł, do który powinni stosować

się projektanci,



projekt aplikacji - katalog wszystkich modułów aplikacji wraz ze

wskazaniem w jaki sposób będą one wspierały procesy i funkcje

biznesowe,



wstępna wersja dokumentacji użytkownika - przewodnik

użytkownika,



wstępna wersja dokumentacji technicznej (w tym wskazania dla

programistów do wykonania i do testowania oprogramowania),



model testowania procesów systemowych - model testowania,

zawierający odpowiednie scenariusze pełnego testu modułów

wspomagających każdy proces i funkcję biznesową.

Zasadnicze rozwiązania projektowe w obszarze organizacji danych:



wejścia do SI tzn. określenie zakresu, częstotliwości, objętości i

postaci danych dostarczanych do si oraz sposób ich

wprowadzania,



baza danych oraz pliki tradycyjne,



wyjścia z si tzn. określenie zakresu, częstotliwości, objętości i

postaci danych emitowanych przez si do użytkowników oraz

sposób ich udostępniania,



procedury ochrony dostępu do danych oraz zabezpieczające je

przed zniszczeniem i nieupoważnionym użytkowaniem,



procedury ochrony elementów organizacyjnych systemu

informatycznego.

Zasadnicze rozwiązania projektowe w obszarze technologii
przetwarzania danych:



procesy podstawowe SI ukierunkowane na wspieranie realizacji

procesów i funkcji biznesowych (obsługa bazy danych

(ładowanie , aktualizacja, wyszukiwanie i udostępnianie danych

użytkownikom i oprogramowaniu), przetwarzanie, generowanie

raportów, kontrola i weryfikacja danych,)



procesy pomocnicze, których celem jest utrzymanie wymaganego

poziomu sprawności i niezawodności realizacji procesów

podstawowych oraz racjonalności wykorzystania urządzeń

technicznych wraz z systemami komputerowymi (procedury

awaryjne, ochrona dostępu do systemu i danych, restrukturyzacja

systemu technicznego i danych),



komunikacja użytkownika z systemem oraz poszczególnych

elementów struktury przestrzennej SI ze sobą i otoczeniem

(projektowanie interfejsów).

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza PROJEKT

Głównym celem fazy BUDOWA

jest wygenerowanie aplikacji

(oprogramowania użytkowego) oraz zaimplementowanie bazy
danych według ustaleń przyjętych na poziomie w fazie PROJEKT.

Cele fazy BUDOWA:


dostarczenie do zatwierdzenia użytkownikowi dobrze poprawnie

utworzonego
i należycie przetestowanego tworzonego systemu,



dostosowanie kodów źródłowych modułów i bazy danych do

przyjętych standardów,



dostarczenie dokumentacji służącej użytkowaniu i konserwacji

systemu.

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza BUDOWA

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza BUDOWA

Udział procesów tworzenia systemu informatycznego w

realizacji fazy BUDOWA

efi

liz

że

Definicja wymagań

Badanie istniejących systemów
Architektura techniczna
Projekt i budowa bazy danych
Projekt i budowa modułów
Konwersja danych
Dokumentacja
Testowanie
Szkolenie

Wdrożenie

Asysta po wdrożeniu

GK (PSI(2) - 2009)

Proces

Udział

procentowy w

realizacji fazy

Definicja wymagań
Badanie

istniejących

systemów
Architektura techniczna

Projekt i budowa bazy
danych

1,2

Projekt i budowa modułów

42,9

Konwersja danych

6,9

Dokumentacja

3,9

Testowanie

29,3

Szkolenie

1,0

Wdrożenie

0,6

Asysta po wdrożeniu

Zarządzanie projektem

14,2

Metoda projektowania

strukturalnego

faza BUDOWA

Udział procesów tworzenia systemu informatycznego w

realizacji fazy BUDOWA

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza BUDOWA

Wejście do

fazy BUDOWA:



projekt logiczny bazy danych,



plan wyposażenia technicznego systemu,



projekt modułów aplikacji i menu



moduł konwersji danych



wstępna dokumentacja techniczna i użytkowa,



moduły testów integracyjnych systemu,



wstępne materiały szkoleniowe,



strategie przejścia od systemu dotychczasowego do tworzonego.

Wyniki

fazy BUDOWA



projekt fizycznej bazy danych,



standardy wytwarzania systemu,



kod modułów aplikacji,



moduły konwersji danych,



interfejsy,



dokumentacja szkoleniowa,



wyniki indywidualnego testowania modułów aplikacji,



plan instalacji systemu.

Czynniki zapewniające poprawną realizację fazy BUDOWA:



kierownik projektu i kierownicy zespołów realizacyjnych powinni

dokładnie szacować i planować wykonanie poszczególnych

elementów systemu informatycznego,



niedopuszczalne są znaczne zmiany w funkcjach przeznaczonych

do oprogramowania i bazie danych,



natychmiastowe reagowanie zespołu projektowego na wszelkie

wskazówki dotyczące przestojów lub błędów oszacowania

pracochłonności i terminów realizacji prac,



rzetelne wykonywanie testowania wytworzonych modułów

programowych.

Ryzyko występujące w procesie realizacji fazy BUDOWA wynika

głównie z:



kierownik nie panuje nad właściwym wytwarzaniem i porządkiem

kompletowania modułów programowych i bazy danych,



zespół projektujący nie rozumie ograniczeń systemu i sposobu

testowania tworzonego systemu,



zespół testujący projektuje niewłaściwe testy,



zestawy danych testujących nie są możliwe do użycia w procesie

testowania.

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza BUDOWA

Głównym celem fazy WDROŻENIE

jest zainstalowanie nowego

systemu, przygotowanie personelu zamawiającego do jego
użytkowania i administrowania systemem i przejście do fazy
eksploatacji. Zespół wdrażania dokonuje instalacji, szkoli
personel, pomaga w testach i oddaje system do eksploatacji.

Cele fazy WDROŻENIE :


instalowanie aplikacji,



przygotowanie użytkowników do eksploatacji systemu,



sprawdzenie czy nowy system spełnia wszystkie postawione

kryteria,



przekazanie systemu do eksploatacji.

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza WDROŻENIE

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza WDROŻENIE

Udział procesów tworzenia systemu informatycznego w

realizacji fazy WDROŻENIE

efi

liz

że

Definicja wymagań

Badanie istniejących systemów
Architektura techniczna
Projekt i budowa bazy danych
Projekt i budowa modułów
Konwersja danych
Dokumentacja
Testowanie
Szkolenie

Wdrożenie

Asysta po wdrożeniu

GK (PSI(2) - 2009)

Proces

Udział

procentowy w

realizacji fazy

Definicja wymagań
Badanie

istniejących

systemów
Architektura techniczna

Projekt i budowa bazy
danych
Projekt i budowa modułów

Konwersja danych

23,0

Dokumentacja

Testowanie

26,0

Szkolenie

20,0

Wdrożenie

17,0

Asysta po wdrożeniu

Zarządzanie projektem

14,0

Metoda projektowania

strukturalnego

faza WDROŻENIE

Udział procesów tworzenia systemu informatycznego w

realizacji fazy WDROŻENIE

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza WDROŻENIE

Wejście do

fazy WDROŻENIE:



moduły konwersji danych,



kod aplikacji,



plan instalacji systemu,



biblioteka użytkownika,



przewodnik użytkownika,



szkolenie z baz danych,



kryteria i specyfikacje testu akceptacji,



plan szkolenia.

Wyniki

fazy WDROŻENIE



przekonwertowane i zweryfikowane dane,



wyniki testu akceptacji po weryfikacji według kryteriów testu akceptacji,



skonfigurowany system wraz z koniecznym środowiskiem do

implementacji i eksploatacji bazy danych oraz oprogramowania

aplikacyjnego systemu,



użytkownicy przygotowania do posługiwanie się nowym systemem,



przygotowani administratorzy systemu,



software, dokumentacja i hardware, wliczając terminale i sieci,

wymagane do eksploatacji systemu,



system gotowy do przekazania do eksploatacji.

Czynniki zapewniające poprawną realizację fazy WDROŻENIE:



oddanie i instalacja systemu na czas,



poczucie zaangażowania i współuczestniczenia użytkowników we

wdrażaniu systemu,



wystarczająca architektura systemu,



pomyślne wyniki testu akceptacyjnego systemu,



system jest dobrze zorganizowany, skonstruowany i rozwiązuje

postawione problemy.

Ryzyko występujące w procesie realizacji fazy WDROŻENIE wynika

głównie z:



zespół testujący nie może ogarnąć wielości systemu podczas

testów akceptacyjnych,



zespół szkolący nie ma wystarczającej ilości czasu, by odpowiednio

przeszkolić użytkowników, personel pomocniczy oraz

administratorów,



nowi użytkownicy, którzy po raz pierwszy stykają się z systemem

chcą wnosić propozycje lub poprawki, które nie są istotne z uwagi

na działanie systemu,



nieefektywna komunikacja z informatyzowaną organizacją w

zakresie przygotowywania jej do wdrożenia systemu,



zespół zajmujący się wdrożeniem systemu nie wypracował pełnego

scenariusza wprowadzania systemu do organizacji .

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza WDROŻENIE

W procesie

eksploatacji

, a więc wykorzystywania go

zgodnie z przeznaczeniem, system informatyczny jest
poddawany ciągłej obserwacji, która ma na celu uzyskanie
odpowiedzi na następujące zasadnicze pytania:



czy system jest, sprawny, skuteczny i ekonomiczny,



czy jest potrzeba usprawnienie funkcjonowania systemu i

jeżeli tak, to co i jak usprawnić,



czy usprawnienie będzie opłacalne.

Jeżeli usprawnienie SI jest konieczne i opłacalne, następuje

doskonalenie systemu (modernizacja, konserwacja), które

może przyjąć postać:



usuwania błędów (corrective maintenance,

18%



dopasowania funkcjonalnego SI do zmieniających się

warunków jego eksploatacji (adaptive maintenance,

20%



rozwoju systemu (perfective maintenance,

32%

GK (PSI(2) - 2009)

Metoda projektowania

strukturalnego

faza EKSPOLATACJA

GK (PSI(2) - 2009)

PROCES

DEFINICJ

ANALIZ

PROJEKT

BUDOW

WDROŻENI

EKSPLOATACJA

Suma

Definicja wymagań

2,9

5,6

8,5

Badanie systemu
istniejącego

1,0

1,6

2,6

Architektura
techniczna

0,3

1,5

0,3

2,1

Projektowanie i
budowa bazy danych

0,9

0,4

1,3

Projektowanie i
budowa modułów

17,5

19,8

37,3

Konwersja danych

0,4

1,2

1,8

3,2

0,7

7,3

Dokumentacja

0,1

2,2

1,8

4,2

Testowanie

0,1

1,8

13,6

0,8

16,3

Szkolenie

0,3

0,4

0,6

1,9

Wdrażanie

0,1

0,2

0,5

0,9

Serwis

3,4

Zarządzanie projektem

0,8

1,7

4,1

6,6

0,4

0,6

14,2

Suma

5,6

12,1

29,1

46,2

3,0

4,0

100,0

Metoda projektowania

strukturalnego

podsumowanie

Procentowy udział poszczególnych procesów w realizacji
faz metody:

Język modelowania wykorzystywany w fazie analizy

(w metodzie Yourdona) jest językiem graficznym i
obejmuje:

diagramy przepływu danych

(data flow diagrams,

DFD

specyfikacja procesów

(process specifications,

PSPEC

diagramy związków encji

(entity relationship diagrams,

ERD

słownik danych

(data dictionary,

diagramy przejść stanów

(state-transition diagrams,

STD

GK (PSI(2) - 2009)

Narzędzia modelowania i

projektowania strukturalnego

GK (PSI(2) - 2009)

POJĘCIE

ZNACZENIE

PROCES

Funkcja, proces

gospodarczy realizowany w
systemie, przekształcający
dane wejściowe w wynikowe

PRZEPŁYW DANYCH

Powiązanie pomiędzy

procesami i innymi
kategoriami DFD

SKŁADNICA DANYCH

Kolekcja danych które

muszą być przechowywane w
systemie w określonym
czasie

TERMINATOR (OBIEKT

ZEWNĘTRZNY)

Źródło lub przeznaczenie

danych - zewnętrzne obiekty,
z którymi system komunikuje
się, tj. osoby, działy,
jednostki organizacyjne

Narzędzia modelowania i

projektowania strukturalnego

DFD

Proces

przetwarza (transformuje) wartości danych. Z

punktu widzenia DFD, procesy mogą być złożonymi zestawami
różnych elementarnych funkcji, z których niektóre mogą działać
równolegle, mogą mieć uboczne efekty polegające na zmianie
niektórych danych lub stanów, oraz mogą produkować złożone
wyniki.

Diagramy przepływu danych specyfikują wyłącznie

podstawowe przeznaczenie lub funkcję procesu, w postaci jego
lakonicznej nazwy oraz (niekiedy) krótkiego opisu, natomiast
nie informują o kolejności wykonywania procesów.

Istotne jest,

jakie dane wpływają do procesu i jakie są wytwarzane
(produkowane) przez proces

Diagram procesu
pokazuje tylko jego
nazwę, wejście i
wyjście

Narzędzia modelowania i

projektowania strukturalnego

DFD

GK (PSI(2) - 2009)

Terminator (interfejs, aktor)

to aktywny

obiekt z

zewnętrza systemu, który „uruchamia” diagram przepływu

danych poprzez dostarczenie danych inicjujących działalność

procesów przedstawionych na diagramie. Jest nim również

obiekt zewnętrzny, który wykorzystuje dane wytworzone przez

procesy systemu.

W diagramach przepływu danych nie

przedstawia się dowolnych, faktycznie istniejących związków

pomiędzy terminatorami. Wszystkie dane wprowadzane i

wyprowadzane od terminatorów podlegają przetwarzaniu w

procesach.

Przykłady terminatora: użytkownik programu, czujnik
temperatury, sprzedawca, bank, zarząd firmy.

DFD nie zajmuje się opisywaniem tego, w jaki sposób

terminator generuje dane wejściowe, ani też w jaki sposób je
wykorzystuje.

Terminator może być zastąpiony przez proces lub diagram

dynamiczny, z ewentualnym powołaniem bardziej elementarnych
terminatorów komunikujących się z procesem zastępującym
terminatora.

GK (PSI(2) - 2009)

Narzędzia modelowania i

projektowania strukturalnego

DFD

Składnicą danych (magazynem)

jest pasywny obiekt, który

służy jako nazwana przechowalnia danych

w postaci

jednorodnych kolekcji i grup danych

, które istnieją z założenia,

lub które są pośrednikami w przepływie danych pomiędzy

poszczególnymi procesami. Składnica nie ma charakteru kolejki

lub stosu. Nie jest też aktywnym obiektem, który wymusza

przepływ danych. Składnica danych może zawierać wiele

obiektów różnego typu, przy czym w większości przypadków, opis

tych obiektów ogranicza się do lakonicznego określenia ich

charakteru lub przeznaczenia.

GK (PSI(2) - 2009)

Narzędzia modelowania i

projektowania strukturalnego

DFD

DFD nie zajmuje się

ani organizacją

składnic danych, ani

też kolejnością w jakiej

dane są wkładane lub

wyjmowane ze

składnicy.

Składnica

na DFD ma sens, gdy

przechowywane tam

dane służą realizacji

co najmniej dwu

procesów.

Składnice

danych biorą udział w

operacjach:

wyszukiwania,

wprowadzania,

skreślania i

aktualizacji.

1. Poziomy dekomponowania diagramów przepływu danych (DFD) i

zasady oznaczania procesów umożliwiają opis systemu na
różnych, wymaganych względami projektowymi, stopniach
szczegółowości.

2. Ze względu na zapewnienie czytelności diagramu DFD można na

nim umieścić

nie więcej niż siedem procesów

oraz związanych z

nimi przepływów danych, składnic i terminatorów.

3. Proces dekompozycji przebiega w układzie hierarchicznym,

począwszy od najbardziej ogólnego diagramu

kontekstowego

specyfikacji funkcji elementarnych, dalej niedekomponowalnych
(atomowych). Określanie, które procesy należy uznać za
atomowe (elementarne) pozostaje w gestii projektanta systemu.

4. Jeden diagram DFD może zawierać procesy o różnym stopniu

zdekomponowania.

5. Nie jest z góry określona liczba poziomów szczegółowości DFD,

ale z praktyki wynika, że nie należy przekraczać trzech
poziomów.

GK (PSI(2) - 2009)

Narzędzia modelowania i

projektowania strukturalnego

–

dekompozycja DFD

GK (PSI(2) - 2009)

Narzędzia modelowania i

projektowania strukturalnego

–

kontekstowy DFD

Diagram kontekstowy

(context diagram,

) definiuje zakres i

granice systemu i przedstawia powiązania (interakcje) tworzonego

systemu z jego otoczeniem, tj. kontekstem, w którym system

funkcjonuje. Diagram CD jest diagramem DFD, od którego rozpoczyna

się dekompozycję funkcjonalną systemu.

Podstawowe zasady tworzenia diagramu kontekstowego:



przedstawienie tworzonego systemu w postaci jednego procesu, a na

jego obwodzie przedstawia się terminatory i, w szczególnych

przypadkach zewnętrzne składnice danych, powiązane bezpośrednio

przepływami danych. Ze względów technicznych często znajduje tu

zastosowanie zasada kilkakrotnego umieszczania tych samych

terminatorów,



ustalenie wspólnie z użytkownikami, zorientowanymi w specyfice

dziedziny przedmiotowej, listy podstawowych zdarzeń - zapytań

(operacji wejściowych) i związanych z nimi odpowiedzi (operacji

wynikowych), które będą interpretowane jako odpowiadające im

przepływy danych wiążące system z otoczeniem,



określenie źródeł i przeznaczenia danych - odpowiadają im

terminatory oraz zewnętrzne składnice danych.

GK (PSI(2) - 2009)

Narzędzia modelowania i

projektowania strukturalnego

DFD 0

1. Diagram zerowy wynika bezpośrednio z diagramu

kontekstowego.

2. Decydująca jest tu dekompozycja jednego procesu z

diagramu kontekstowego na kilka procesów, które są

agregatami dekomponowanymi dalej, aż do procesów

elementarnych (atomowych).

3. Na poziomie zerowym wprowadza się wewnętrzne składnice

danych oraz przenosi terminatory z diagramu

kontekstowego.

4. Procesy, składnice danych oraz terminatory powiązane są

przepływami danych z diagramu kontekstowego.

GK (PSI(2) - 2009)

Specyfikacja procesów

jest wykonywana dla każdego

najniższego procesu ujętego w diagramie DFD. Jest ona
szczegółowym opisem reguł działania podanych
przez użytkownika, które realizuje dany proces, tzn. definiuje co
należy robić w celu przekształcenia danych wejściowych w
wynikowe. Specyfikacja procesów musi spełniać dwa podstawowe
wymagania:



musi mieć taką postać, aby była możliwa jej weryfikacja przez

użytkownika i analityka,



musi mieć postać pozwalająca na efektywną komunikację

między współuczestnikami procesu tworzenia systemu
informatycznego.
Narzędzia specyfikacji procesów mogą być różne, ale jednakowe
dla wszystkich etapów projektu. Mogą to być: strukturalny język,
warunki początkowe/końcowe, tablice decyzyjne, diagramy
blokowe, język naturalny.

Narzędzia modelowania i

projektowania strukturalnego

specyfikacja w DFD

Przykład:

GK (PSI(2) - 2009)

Przykład specyfikacji

procesu generowanie raportu

stanu pojazdów:

DO
GET

ID_pojazdu, kmPrzejechane, StanPojazdu,

maxLiczbaPalet, nrRejestracyjny

FROM

TERMINATOR DYSPOZYTORNIA AS statystykiPojazdow
noweStatystyki = statystykiPojazdu

SAVE

statystykiPojazdow

TO STORE

POJAZDY

WHILE

dane wszystkich pojazdów zostaną zaktualizowane

GET * FROM STORE

POJAZDY

aktualneDanePojazdow

formatuj aktualneDanePojazdow

SAVE

aktualneDanePojazdow

TO STORE

RAPORTSTANUPOJAZDOW

GET * FROM STORE

RAPORTSTANUPOJAZDOW

danePojazdow

SEND

danePojazdow

TERMINATOR KIEROWNICTWO

Narzędzia modelowania i

projektowania strukturalnego

specyfikacja w DFD

GK (PSI(2) - 2009)

Narzędzia modelowania i

projektowania strukturalnego

PSPEC

Graficznym narzędziem algorytmicznej

specyfikacji procesów elementarnych jest

schemat

PSPEC

obejmujący:

nazwa procesu

(indeks procesu jak np. indeks na

diagramie DFD),

dane wejściowe

(odpowiadające wejściowym

przepływom danych na DFD),

dane wyjściowe

(odpowiadające wyjściowym

przepływom danych na DFD),

opis algorytmu

(w dowolnej, ale jednolitej dla całego

projektu, notacji) przetwarzającego dane wejściowe na
dane wyjściowe.

GK (PSI(2) - 2009)

Narzędzia modelowania i

projektowania strukturalnego

ERD

Diagram związków encji

(ERD) rodzaj

graficznego przedstawienia związków pomiędzy encjami
używany w projektowaniu systemów informatycznych
do przedstawienia konceptualnych modeli danych
wykorzystywanych w systemie.

Diagram pokazuje logiczne związki pomiędzy

różnymi encjami, związki te mają dwie cechy:

opcjonalność

, która mówi o tym, czy każda encja musi

czy też może wystąpić równocześnie z inną. Np.
POJAZD musi być kierowany przez OSOBĘ, która jest
kierowcą, natomiast OSOBA nie musi, ale może być
kierowcą,

krotność

(1:1, 1:N, M:N).

GK (PSI(2) - 2009)

Narzędzia modelowania i

projektowania strukturalnego

Słownik danych

(DD)

Słownik jest repozytorium

wszystkich terminów (składników modeli: wejść, wyjść,
obiektów itd.) używanych w projekcie, w szczególności
zawiera definicje wszystkich atrybutów użytych w opisach
typów obiektów i relacji.

Notacja stosowana w zapisach słownika:

•=

- składa się,

•+

- spójnik „i”,

•()

- jest opcjonalne, tzn. może wystąpić lub nie,

•{}

- iteracja (wielokrotne wystąpienie elementu),

•[]

- alternatywa (wybór jednej z kilku opcji),

•|

- separator,

•**

- komentarz,

•@

- identyfikator.

Przykłady:

zamówienie = nazwa_klienta + adres_klienta +

{towar}

płeć = {MK}

pytanie_o_oferty = [nazwa_oferty, numer_oferty, towar] +
[cena]
informacja_o_ofertach = id_oferty + nazwa_oferty + cena

GK (PSI(2) - 2009)

Przykład słownika danych:

Faktura

-ID_faktury = @rok + miesiac +
numerporzadkowy

•rok = [2000-2100]

•miesiac = [1-12]

•numerporzadkowy = [0-9]
- ID_zlecenia

-dataWystawienia = rok + miesiac + dzien

•rok = [2000-2100]

•miesiac = [1-12]

•dzien = [1-31]

-dataPlatnosci = rok + miesiac + dzien

•rok = [2000-2100]

•miesiac = [1-12]

•dzien = [1-31]
- oplacono = [True | False]
- cenaZaKm = [{0-9} | . ]

Narzędzia modelowania i

projektowania strukturalnego

GK (PSI(2) - 2009)

Narzędzia modelowania i

projektowania strukturalnego

STD

Diagram przejść stanów

(STD) pokazuje zachowanie się

systemu w czasie Przede wszystkim są stosowane przy tworzeniu
systemów czasu rzeczywistego, ale ze względu na swoją
elastyczność mogą też służyć do prezentowania sposobu
realizacji funkcji systemu nie uwarunkowanego czasowo.

Stanem obiektu

jest zestaw wszystkich wartości

atrybutów tego obiektu oraz jego aktualnych powiązań z innymi
obiektami w danej chwili czasowej. Stan obiektu trwa w czasie,
aż do momentu zajścia zdarzenia lub operacji, które zmienia
stan na inny.

Przejście

między stanami zachodzi natychmiastowo po

zdarzeniu i nieskończenie krótko (w ramach sensownego
przybliżenia) oraz może być uwarunkowane spełnieniem
dodatkowych warunków.

Zdarzeniem

jest coś, co następuje w jednym punkcie

czasowym (z punktu
widzenia naszej percepcji czasu) i warte jest analizowania z
punktu widzenia celów projektowanego systemu
informatycznego. Samo zdarzenie nie trwa w czasie, ale fakt
zaistnienia zdarzenia jest zarejestrowany i trwa, aż do
momentu, gdy jakiś podmiot go „skonsumuje”. Mogą
występować zdarzenia

zewnętrzne

(zachodzące poza systemem)

wewnętrzne

(mające źródło w systemie). W momencie zajścia

zdarzenia realizowana jest pewna czynność określana jako

akcja

GK (PSI(2) - 2009)

Podsumowanie podejścia

strukturalnego



Niewystarczająco wspomagają rozpoznawanie i
modelowanie niefunkcjonalnych wymagań
systemowych.



Są ogólne pod tym względem, że zwykle nie
zawierają wskazówek pomagających
użytkownikom w podjęciu decyzji, czy konkretna
metoda jest odpowiednia dla określonego
problemu, czy nie.



Często nie obejmują porad, jak przystosować
wybraną metodę do ustalonego środowiska.



Prowadzą zwykle do utworzenia zbyt obszernej
dokumentacji. Istota wymagań systemowych
może być ukryta w masie zapisanych szczegółów.



Opracowane modele są bardzo szczegółowe i
użytkownikom trudno jest je zrozumieć. Tacy
użytkownicy nie mogą autentycznie sprawdzić
realizmu tych modeli.

Document Outline