Projektowanie

systemów

informatycznych

Metody tworzenia systemu

informatycznego

Pojęcia podstawowe

System informacyjny

- usystematyzowana i uporządkowana

sieć powiązań informacyjnych między takimi elementami, jak:
człowiek, dane, metody oraz urządzenia do zbierania, przesyłania,
przetwarzania i udostępniania danych, mających na celu
zaspokojenie potrzeb informacyjnych zainteresowanych
użytkowników.

System informatyczny

jest to system informacyjny, w którym

procesy przetwarzania danych w całości lub w części jest

realizowany za pomocą metod i narzędzi technik informacyjnych.

Strukturę systemu informatycznego tworzą:



struktura funkcjonalna

- procedury zbierania (gromadzenia),

przechowywania, przetwarzania i udostępnianie danych oraz

procedury organizacyjne korzystania z systemu informatycznego,

instrukcje robocze itp.,



struktura informacyjna

- bazy danych dziedzin, w których używany

jest system informatyczny,



struktura techniczna

- środki techniczne stosowane w

przetwarzaniu i przesyłaniu danych wraz z oprogramowaniem,



struktura przestrzenna

- zbiór miejsc, w których rozmieszczone są

elementy systemu informatycznego wraz z odpowiednią

infrastrukturą wiążącą te elementy.

2

GK (PSI(1) - 2009)

GK (PSI(1) - 2009)

3

Cykl życia systemu informatycznego

- proces złożony z

ciągu wzajemnie spójnych etapów, umożliwiających pełne i
skuteczne utworzenie, a następnie
użytkowanie systemu, aż do zaprzestania jego użytkowania.

Przedsięwzięcie informatyczne

-

zadanie (praca),

którego realizacja polega na wytworzeniu systemu
informatycznego (SI) w ramach ograniczeń nałożonych przez
czas, koszty, zasoby i jakość.

Metodyka tworzenia systemu informatycznego (TSI)

-

spójny, logicznie uporządkowany zbiór metod i procedur o
charakterze technicznym i organizatorskim, pozwalających na
zrealizowanie cyklu życia systemu informatycznego przez
zespół wykonawczy.

Zwykle metodyka jest powiązana z

odpowiednią notacją służącą do zapisywania wyniku
poszczególnych faz projektu, jako środek wspomagający ludzką
pamięć i wyobraźnię i jako środek komunikacji w zespołach
oraz pomiędzy projektantami i klientem.

Metoda

- świadomie i konsekwentnie stosowany sposób

postępowania wraz z wykorzystywaniem niezbędnych środków
służących realizacji części cyklu życia systemu
informatycznego.

Technika

- szczegółowo i konkretnie określony sposób

posługiwania się środkami realizacyjnymi (rzeczowymi),
stosowanymi w ramach przyjętej metody dla osiągnięcia
ustalonego celu.

Pojęcia podstawowe

W dziedzinie projektowania systemów

informatycznych kluczowym pojęciem jest

metodyka

tworzenia systemów informatycznych

.

Podstawowe składniki

metodyki TSI

:



formalizmy, modele opisu dziedziny przedmiotowej

(modele opisu rzeczywistości), jej statyki i dynamiki

zwane modelami konceptualnymi,



strukturalizacja procesu TSI w postaci odpowiedniej

sekwencji etapów, podetapów i poszczególnych zadań w

postaci cyklu życia systemu,



szczegółowe metody i techniki TSI, jego

dokumentowania wraz z adekwatną symboliką

graficzną,



narzędzia wspomaganego komputerowo TSI, w tym ich

prototypowania określane mianem CASE (Computer

Aided Systems Engineering),



specyfikacja wymagań merytorycznych wobec

poszczególnych twórców oraz zespołu wykonawczego

(projektowego), planującego rozwój systemu i

realizującego proces TSI,



kryteria oceny i mechanizmy kontroli jakości projektu.

Zakres i składniki metodyk

4

GK (PSI(1) - 2009)

zadani

a

fazy

dokumenta

cja

wspomaga

nie TSI

Dziedzina

przedmiotowa

(DP)

Zespół

projektują

cy

Kryteria

oceny

wyniki

analiz

cele, problemy,

potrzeby

informatyczne

tworzeni

e

systemu

kierowan

ie

projekta

mi

prezentacja

i

eksperymental

na

eksploatacja

akceptacja

korekty i

modyfikacje

System

informatyczn

y

PROCES

TWORZENIA

SYSTEMU

INFORMATYCZNEG

O

(TSI)

wycinek

rzeczywistości dla

którego tworzy się

system informatyczny

Narzędzia

komputerow

ego

wspomagani

a

Metody i

techniki

Modele DP

pojęcia

abstrakcyj

ne

para-

metry

pakiet

y

warsztat zespołu

projektującego

reguły

modelowani

a

odzwierciedlają

właściwości

dziedziny

przedmiotowej

dokument

ują

elementy

modeli

5

GK (PSI(1) - 2009)

Zakres i składniki metodyk

Prosta klasyfikacja nie jest łatwa, gdyż:



zagadnienia związane z tworzeniem systemów

informatycznych są nieustrukturyzowane co oznacza,

że nie istnieją oczywiste i jednoznaczne definicje

problemów ani sposobów ich rozwiązywania,



dziedziny przedmiotowe są bardzo specyficzne

(dynamicznie zmieniająca się sytuacja w obszarze

zastosowania procesu informatyzacji),



dynamika zmian w sferze inżynierii oprogramowania,



brak teoretycznych podstaw wyrażania potrzeb

informatycznych.

Najczęściej proponuje się klasyfikację według

następujących kryteriów:



ze względu na podejście do procesu tworzenia

systemów informatycznych,



ze względu na definiowanie danych bądź procesów w

projekcie,



ze względu na relacje między dziedziną przedmiotową

a systemem informatycznym,



ze względu na kierunek tworzenia systemów

informatycznych.

Klasyfikacja metodyk TSI

6

GK (PSI(1) - 2009)

Ze względu na

podejście do procesu tworzenia systemów

informatycznych

można wyodrębnić metodyki:

 techniczne

- analityk nie ma wpływu na organizację w

procesie tworzenia SI, gdyż występują sformalizowane

modele dziedziny przedmiotowej i ściśle określone

sposoby rozwiązań,

 społeczne

- rola analityka jest aktywna i od

uwarunkowań organizacyjno-kadrowych zależy sukces

projektu; akcentowane są przede wszystkim

organizacyjne, psychologiczne i socjologiczne problemy

występujące w procesie tworzenia SI.

Ze względu na

definiowanie danych bądź procesów w

projekcie

można wyodrębnić metodyki:

 zorientowane na dane

- koncentrują analizę i

projektowanie systemów na strukturyzacji danych

użytkowych w organizacji,

 zorientowane na procesy

- dane elementarne

specyfikuje się na podstawie analizy procesów

biznesowych w organizacji (dziedzinie przedmiotowej)

oraz potrzeb użytkowników.

Klasyfikacja metodyk TSI

7

GK (PSI(1) - 2009)

Ze względu na

zależność między dziedziną

przedmiotową a systemem informatycznym

można

wyodrębnić metodyki:

 organizacyjnego odwzorowania

(metodyka pasywna –

podejście diagnostyczne) - ponieważ decyzje i

działania są podejmowane w dziedzinie

przedmiotowej, to SI musi ściśle odwzorowywać

rzeczywistość i nie ma miejsca na innowacyjne

rozwiązania,

 organizacyjnego sterowania

(metodyka aktywna –

podejście prognostyczne) - nacisk kładzie się na

określenie potrzeb informacyjnych, a nie na

odzwierciedlenie rzeczywistości, gdyż wyodrębnia się

w dziedzinie przedmiotowej system zarządzania, w

którym podejmowane są decyzje wpływające na

dziedzinę.

Ze względu na

kierunek tworzenia SI

można wyodrębnić

metodyki:

 zstępujące

(top-down) - tworzenie systemu następuje

przez stopniowe, hierarchiczne wyodrębnianie jego

składników, aż do podstawowego poziomu

szczegółowości (od ogółu do szczegółu),

 wstępujące

(bootom-up) – tworzenie systemu

następuje na drodze stopniowego rozwijania systemu

poprzez integrację jego elementów, począwszy od

poziomu podstawowego (od szczegółu do ogółu).

Klasyfikacja metodyk TSI

8

GK (PSI(1) - 2009)

Aktualnie dominuje klasyfikacja wynikająca z
połączenia opisu dziedziny przedmiotowej i
doświadczeń praktycznych. Wyróżnić można więc
trzy podejścia metodologiczne:

 strukturalne

(strukturalno-relacyjne) - polegające

na tworzeniu uporządkowanego systemu o
hierarchicznej strukturze, którego składniki
stanowią moduły funkcji i danych oraz związki
między nimi; cechą charakterystyczną jest
oddzielne modelowanie danych i procesów,
wykorzystujące metody i techniki diagramowe i
macierzowe,

 obiektowe

- opiera się na wyodrębnieniu obiektu

(bytu, pojęcia, rzeczy) mającego odpowiednie
znaczenie w kontekście problemów danej dziedziny
przedmiotowej; cechą charakterystyczną jest
możliwość integralnego modelowania danych i
procesów,

 społeczne

- akcentuje aspekty ludzkie i społeczne

(psychologiczne i socjologiczne) w tworzeniu SI
(dotyczą tylko fazy planowania systemu).

Klasyfikacja metodyk TSI

9

GK (PSI(1) - 2009)

Ogólne wymagania na racjonalną

metodykę TSI:



powinna objąć cały cykl życia systemu

przy zapewnieniu płynnych przejść

pomiędzy fazami,



powinna obejmować różnorodne,

dostosowane do specyfiki podejścia,

metody, techniki i narzędzia,



powinna ułatwić porozumiewanie się

pomiędzy różnymi grupami

uczestniczącymi w tworzeniu SI,



powinna być stosunkowo łatwa do

opanowania i dostosowana do szerokiej

klasy problemów oraz zawierać

mechanizmy ewolucyjności i

modyfikowalności.

Ogólne wymagania do

metodyk TSI

10

GK (PSI(1) - 2009)

Model cyklu życia

- struktura procesu realizacji

cyklu życia systemu informatycznego.

Wyróżnia się następujące modele cyklu życia SI:



model kaskadowy (waterfall),



realizacja kierowana dokumentami (document-

driven),



prototypowanie (prototyping),



programowanie odkrywcze (exploratory

programming),



realizacja przyrostowa (incremental development),



montaż z gotowych elementów (composition of re-

usable components),



model spiralny (spiral model),



formalne transformacje (formal transformations).

Model cyklu życia systemu

informatycznego

11

GK (PSI(1) - 2009)

Model kaskadowy

(liniowy, wodospadowy) jest

klasycznym modelem cyklu życia systemu
informatycznego. Jest to model, który wprowadza
następujące fazy podstawowe:

 definiowania wymagań

, w której określane są cele oraz

szczegółowe wymagania wobec tworzonego systemu,

 projektowania

, w której powstaje szczegółowy projekt

systemu spełniającego ustalone wcześniej wymagania,

 produkcji

, tj. kodowania i implementacji

oprogramowania oraz indywidualnego testowania jego

elementów (modułów),

 testowania

, w której następuje integracja

poszczególnych modułów połączona z testowaniem

integracyjnym całego oprogramowania w docelowym

środowisku programistycznym,

 konserwacji

, w której system jest wykorzystywany przez

użytkownika(ów), a producent dokonuje konserwacji

elementów systemu - wykonuje modyfikacje polegające

na usuwaniu błędów, zmianach i rozszerzaniu funkcji

systemu.

12

GK (PSI(1) - 2009)

Model kaskadowy

W modelu kaskadowym często wyróżnia się pewne

dodatkowe fazy, które częściowo nakładają się na fazy
wymienione wcześniej. Są to fazy:

 strategiczna

,

wykonywana przed formalnym podjęciem

decyzji o realizacji przedsięwzięcia. W tej fazie

podejmowane są pewne strategiczne decyzje dotyczące

dalszych etapów prac. Faza ta wymaga oczywiście

przynajmniej ogólnego określenia wymagań,

 analizy

, w której budowany jest logiczny model

systemu,

 dokumentacji

, w której wytwarzana jest dokumentacja

systemu. Opracowywanie dokumentacji przebiega

równolegle z produkcją oprogramowania. Faza to może

rozpocząć się już w trakcie określania wymagań.

Ostatnie zmiany w dokumentacji dokonywane są w

fazie instalacji,

 instalacji

, w której następuje przekazanie systemu

użytkownikowi.

13

GK (PSI(1) - 2009)

Model kaskadowy

GK (PSI(1) - 2009)

14

Model kaskadowy

Główne cechy modelu kaskadowego:



tworzenie systemu podzielone jest na wyizolowane etapy, z których
każdy musi być zakończony, zanim rozpoczną się prace w etapie
następnym,



wyjścia z jednego etapu są wejściami do etapu następnego,



każdy etap podzielony jest na dwie części: część twórczą oraz część
weryfikacji i/lub zatwierdzenia,



ponowna praca, jeśli jest konieczna, jest wykonywana w kolejnych
etapach bez powrotu na pierwotny etap, na którym dany produkt
został utworzony, np. gdy pojawi się nowe wymaganie,



trudno jest cofnąć się i zmienić rozwiązania z poprzedniego etapu,



duża bezwładność na szybkie zmiany organizacyjne,



użytkownicy są zaangażowani tylko na wczesnych etapach cyklu
życia systemu,



narzucenie twórcom systemu ścisłej kolejności wykonywania prac,



wysoki koszt błędów popełnionych we wczesnych fazach tworzenia
systemu.

15

GK (PSI(1) - 2009)

Model kaskadowy

Model realizacji kierowanej dokumentami

jest jedną z form modelu kaskadowego, składa się

więc z szeregu następujących po sobie faz.

Istotnym wyróżnikiem tego modelu jest to, że

wymaga się, aby każda faza kończyła się

opracowaniem szeregu dokumentów, w pełni

opisujących jej wyniki. Dokumenty te są na bieżąco

udostępniane zamawiającemu (klientowi,

przyszłemu użytkownikowi) i dopiero po

zaakceptowaniu przez niego tej dokumentacji

rozpoczynana jest kolejna faza.

Dokumenty kończące kolejną fazę powinny

być wystarczającą podstawą do realizacji faz

dalszych.

16

GK (PSI(1) - 2009)

Model realizacji kierowanej

dokumentami

Prototypem systemu

nazywa się częściową

implementację systemu przekazywaną potencjalnym
użytkownikom, którzy oceniają rozwiązanie a swoje
uwagi i ocenę przekazują zespołowi projektowemu.

Głównym celem realizacji prototypu jest lepsze

określenie wymagań, wykrycie nieporozumień
pomiędzy zamawiającym (klientem) a twórcami
systemu, wykrycie brakujących funkcji, wykrycie
trudnych usług, wykrycie braków w specyfikacji
wymagań.
Model ten obejmuje następujące fazy:



zebranie i analiza wymagań ogólnych,



szybkie projektowanie,



budowa prototypu,



weryfikacja prototypu przez zamawiającego,



iteracyjne poprawianie projektu i prototypu, aż do

uzyskania zadowolenia zamawiającego,



jeśli klient jest zadowolony z prototypu, określenie

pełnych wymagań i budowa pełnego systemu

zgodnie z modelem kaskadowym.

17

GK (PSI(1) - 2009)

Model prototypowania

GK (PSI(1) - 2009)

18

Model prototypowania

Programowanie odkrywcze

zalecane jest w takich

przypadkach, gdy określenie wymagań klienta może być tak
trudne, że nawet budowa pojedynczego prototypu nie
wystarcza dla rozwiania wszelkich wątpliwości.

OKREŚLENIE

OGÓLNYCH

WYMAGAŃ

BUDOWANIE

SYSTEMU

TESTOWANIE

SYSTEMU

DOSTARCZENIE

SYSTEMU

ZAMAWIJĄCEMU

SYSTEM

POPRAWNY?

TAK

NIE

19

GK (PSI(1) - 2009)

Model programowania

odkrywczego

Realizacja przyrostowa

rozpoczyna się od określenia

wymagań oraz wykonania wstępnego, ogólnego projektu
całości systemu (projektowanie wysokiego poziomu).
Następnie wybierany jest pewien podzbiór funkcji systemu
(fragment systemu). Dalej, zgodnie z przebiegiem modelu
kaskadowego, wykonywany jest szczegółowy projekt oraz
implementacja tego fragmentu systemu. Po przetestowaniu
zrealizowany fragment jest dostarczany zamawiającemu, a
następnie przechodzi się do projektowania i implementacji
kolejnego fragmentu systemu, który dołącza się do
poprzednich, dzięki czemu następuje przyrost systemu.
Cechy modelu:



etapowe dochodzenie do ostatecznej postaci - przyrostowo

realizuje kolejne etapy projektu,



organizacji zamawiającego,



funkcjonalność systemu ma być dostarczana stopniowo w

pewnym przedziale czasu - tzw. dostawa fazowa,



lepsze możliwości dostawy i testowania,



mogą wystąpić trudności z dokonaniem podziału na

fragmenty, a ostatni fragment może okazać się kosztowny.

Model szczególnie przydatny w przypadku twprzenia dużych

systemów.

20

GK (PSI(1) - 2009)

Model przyrostowy

GK (PSI(1) - 2009)

21

Model według realizacji

przyrostowej

Model montażu z gotowych elementów

, zwany też

programowaniem z półki, kładzie szczególny nacisk na
możliwości redukcji nakładów przez maksymalne
wykorzystanie podobieństw tworzonego systemu do już
wcześniej utworzonych.

Gotowe elementy mogą być wykorzystywane na

różnych etapach realizacji przedsięwzięcia. Najczęściej
są one wykorzystywane na etapie produkcji
oprogramowania i implementacji.
Przykłady gotowych rozwiązań wykorzystywanych przy
tworzeniu systemów, szczególnie dla niewielkich firm:



biblioteki,



języki czwartej generacji, których złożone instrukcje

mogą być traktowane jako odwołania do wbudowanych

bibliotek,



pełne aplikacje, np. wykorzystanie przeglądarki plików

pomocy w systemie MS Windows,



szablony stron internetowych,



oprogramowanie OPEN SOURCE.

22

GK (PSI(1) - 2009)

Model montażu z gotowych

elementów

Metody pozyskania gotowych elementów:



zakup elementów ponownego użycia od dostawców,



przygotowanie elementów poprzednich przedsięwzięć do

ponownego użycia.
Zalety:



wysoka niezawodność,



zmniejszenie ryzyka,



efektywne wykorzystanie specjalistów,



narzucenie standardów.

Wady:



dodatkowy koszt przygotowania elementów ponownego

użycia,



ryzyko uzależnienia się od dostawcy elementów,



niedostatki narzędzi wspomagających ten rodzaj pracy.

23

GK (PSI(1) - 2009)

Model montażu z gotowych

elementów

Model spiralny

Model spiralny

jest chyba najbardziej ogólnym

jest chyba najbardziej ogólnym

modelem cyklu życia systemu informatycznego

modelem cyklu życia systemu informatycznego

(zaproponowany przez Boehma w 1988 r.). Cechy modelu:

(zaproponowany przez Boehma w 1988 r.). Cechy modelu:



cykliczne powtarzanie pewnej sekwencji działań - idea

krokowego dochodzenia do rozwiązania docelowego
poprzez cykliczne wykonywanie tych samych faz
tworzenia SI,



nie wyróżnia się takich działań, jak projektowanie,

programowanie itp. ale cztery cyklicznie powtarzane
etapy:

•

określanie wymagań i planowanie - ustalanie celów
produkcji kolejnej wersji systemu,

•

analiza ryzyka i ewentualna budowa prototypu,

•

konstruowanie (wytworzenie) systemu - najczęściej
w tej fazie stosuje się model kaskadowy,

•

weryfikacja oraz ocena systemu przez użytkownika i
jeżeli ocena nie jest w pełni pozytywna, następuje
kolejny cykl.

24

GK (PSI(1) - 2009)

Model spiralny

GK (PSI(1) - 2009)

25

Model spiralny

Idea spiralnego modelu cyklu
życia SI:

Zalety:

• skupienie się na

wczesnym
eliminowaniu błędów
i nie
satysfakcjonujących
rozwiązań,

• model można

stosować podczas
tworzenia systemu i
jego ulepszania,

• łączenie zalet innych

modeli i jednocześnie,
poprzez analizę
ryzyka, uniknięcie
związanych z nimi
utrudnień,

• położenie nacisku na

ponowne użycie
istniejącego
rozwiązań.

Model formalnych transformacji

jest postulowany

w ramach tzw. formalnego nurtu w inżynierii
oprogramowania. Zakłada on, że wymagania wobec
systemu specyfikowane są w pewnym formalnym języku.
Wymagania te są następnie transformowane do pewnej
postaci pośredniej bliższej kodowi w pewnym języku
programowania. Postać ta podlega dalszym
automatycznym transformacjom do kolejnych form
coraz bliższych kodowi. Jedna z kolejnych postaci
formalnych jest już na tyle bliska kodowi, że może być w
automatyczny sposób przełożona na kod w konkretnym
języku programowania. Wszystkie te transformacje
wykonywane są bez udziału ludzi.

Model ten w chwili obecnej należy uznać za

propozycję teoretyczną, która daleka jest od zastosowań
w profesjonalnej produkcji systemów. Pierwsze próby
zastosowania tego modelu wprowadziła firma Microsoft.

26

GK (PSI(1) - 2009)

Model formalnych

transformacji

Szczegółowa analiza zagadnień czasochłonności i

kosztochłonności realizacji systemu informatycznego stała się

podstawą krytyki tradycyjnych cykli życia systemu.

Nakład pracy w cyklu tworzenia systemu

Nakład pracy w cyklu tworzenia systemu

Analiza potrzeb

6%

Projektowanie

5%

Kodowanie

7%

Eksploatacja

67%

Testowanie

15%

Koszty poprawiania błędów

Koszty poprawiania błędów

Projektowanie

13%

Inne

4%

Kodowanie

1%

Analiza potrzeb

82%

27

GK (PSI(1) - 2009)

Nakłady na tworzenie SI

GK (PSI(1) - 2009)

28

Modyfikacje modelu

kaskadowego

Zasadnicze wady klasycznego modelu
kaskadowego:



model nie ujmuje we właściwy sposób etapu

eksploatacji i pielęgnacji (konserwacji) systemu,



eksploatacja i pielęgnacja mają inną naturę,

ponieważ w przeciwieństwie do etapu
projektowania i budowy systemu stanowi etap,
który właściwie nigdy się nie kończy, chyba, że
następuje śmierć systemu,



większość nakładów na system w ciągu całego jego

istnienia ma miejsce podczas pielęgnacji i może to
stanowić około 70% ogólnych kosztów cyklu
tworzenia systemu.

Z powyższych względów w praktyce często spotyka
się warianty modelu kaskadowego, znane jako
modele kaskadowe „b” i „V”.

GK (PSI(1) - 2009)

29

Modyfikacje modelu

kaskadowego – model „b”

Cechy:

•

podział na

jednorazową

ścieżkę tworzenia i

wielokrotnie

powtarzana

iteracyjną ścieżkę

eksploatacji.

GK (PSI(1) - 2009)

30

Modyfikacje modelu

kaskadowego – model „V”

Cechy:

•

lewa część V

ilustruje przejście

od analizy do

projektowania,

następnie do

programowania

oraz zwiększający

się podział

elementów

systemu,

•

prawa część V

ilustruje

narastające

składanie i

testowanie,

kończące się na

dostarczonym

produkcie,

•

ważną cecha

modelu –

odzwierciedlenie

powiązań między

różnymi etapami

przedsięwzięcia,

•

dla kierownika

przedsięwzięcia,

gdy uczestniczą w

nim firmy

zewnętrzne, model

umożliwia

dokładne

zdefiniowanie

etapów nabywania

i dostawy oraz

zatwierdzania

produktów

wynikowych

każdego etapu.

GK (PSI(1) - 2009)

31

Podsumowanie modeli cyklu

życia SI

1. Podstawowymi modelami cyklu życia SI są model

kaskadowy i model spiralny, a pozostałe stosowane w
praktyce są zwykle wariantami lub uszczegółowieniem
tych dwóch modeli.

2. Ze względu na różnorodność modeli trudno określić

jednolity standard, jednak można zdecydować się na
praktycznie użyteczne ich uogólnienie. Najczęściej w
zastosowaniach jest przyjmowany model obejmujący
następujące fazy:

•

specyfikacja systemu:
zebranie wymagań do systemu,
zdefiniowanie funkcjonalności i ograniczeń dotyczących
tworzonego systemu,

•

analiza systemu,

•

projektowanie systemu,

•

wdrażanie systemu (w tym jego walidacja, tj. sprawdzenie
czy gotowy system charakteryzuje się funkcjonalnością
zgodną z oczekiwaniami zamawiającego),

•

użytkowanie, modyfikacja i adaptacja systemu do
zmieniających się potrzeb użytkownika.

Wyróżnia się następujące

analityczne metody TSI:

Strukturalne

(hierarchia kompozycyjna),

Obiektowe

(hierarchia kompozycyjna, hierarchia uogólniająca).

 

Definicja hierarchicznego modelu systemu

informatycznego dokonuje się poprzez zastosowanie rozbioru
(analizy) tego systemu na elementy składowe.

Celem tych metod jest dostarczenie narzędzi i reguł

pozwalających na wymodelowanie realnie działającego systemu

informacyjnego oraz utworzenie specyfikacji i wymagań do

systemu informatycznego, wspierającego funkcjonowanie tego

systemu informacyjnego.  

32

GK (PSI(1) - 2009)

Analityczne metody TSI

W praktyce projektowej są stosowane dwa rodzaje metodyk TSI,

tzw. metodyki ciężkie i metodyki lekkie.

Metodyki ciężkie

są konsekwentną i rygorystyczną realizacją

wszystkich czynności związanych z tworzeniem systemu

informatycznego według przyjętego modelu cyklu życia tego systemu.

Metodyki lekkie

, zwane też zwinnymi (agile methods) są

preferowane w praktyce, gdyż:  

•nie wymagają tworzenia dużej ilości dokumentacji,

•nie definiują rygorystycznych procedur tworzenia,

•kładą nacisk na działania dające najlepszy efekt, zgodne z

przesłankami wynikającymi z doświadczenia,

•pozwalają zespołom tworzącym system na szybką pracę i szybkie

reagowanie na zmiany wymagań użytkownika.

Stosuje się przede wszystkim, gdy:

•projektowany system jest skomplikowany - nie można przewidzieć

wszystkiego co może się przydarzyć,

•zamawiający (klienci) nie do końca wiedzą czego potrzebują,

•często są zmienia wymagania.

Oferują następujące udogodnienia zamawiającemu (klientowi):

•zamawiający (klient) otrzymuje po kawałku (zamkniętą funkcjonalność)

swój produkt – wczesne wdrażanie poszczególnych kawałków,

•zamawiający może wskazywać, co chce aby było wykonane w pierwszej

kolejności.

33

GK (PSI(1) - 2009)

Ciężkie i lekkie metodyki TSI

Lekkie metodyki TSI

opierają się na następujących fundamentach

określonych przez grupę ekspertów jako

The Manifest of the Agile

Alliance

:

1.Pojedyncze osoby i interakcje pomiędzy ludźmi są ważniejsze niż

procesy i narzędzia:

•

indywidualności w zespole nie gwarantują efektywności rozwiązań,

•

dobry proces nie uchroni projektu przed klęską, gdy w zespole brak

mocnych graczy – zły proces może zniwelować wszelkie zalety ich

posiadania,

•

mocny gracz – nie koniecznie bardzo dobry projektant, ale sprawnie

współpracujący z resztą zespołu,

•

nadmiar narzędzi oraz wykorzystywanie ich za wszelką cenę jest zwykle

błędem.

2.Funkcjonujący system jest istotniejszy niż obszerna jego dokumentacja:

•

projekt bez żadnej dokumentacji nie jest idealnym rozwiązaniem,

•

dwa podstawowe elementy pozwalające nowym uczestnikom zespołu

tworzącego system na zapoznanie się z istniejącymi rozwiązaniami:

o

elementy systemu (np. kod oprogramowania) opisane w sposób

przejrzysty i czytelny, co wymaga przyjęcia i przestrzegania

pewnych standardów tworzenia tych elementów i ich

dokumentowania,

o

zespół, który dane elementy systemu utworzył; metodyki lekkie

skupiają się na ludziach i ich wzajemnych interakcjach.

34

GK (PSI(1) - 2009)

Fundamenty lekkich metodyk

TSI

3. Współpraca z zamawiającym (klientem) powinna być przedkładana

nad negocjowanie kontraktów:

•

system informatyczny nie jest zwyczajnym towarem, a więc nie jest

możliwe opisanie tego, co system powinien robić i znalezienie

wykonawcy, który go utworzy w ściśle określonym czasie i za

określoną cenę,

•

najlepszymi kontraktami są takie, które dają możliwość

współpracy zespołowi wytwarzającemu system i zamawiającemu,

•

częsty kontakt z zamawiającym jest istotnym elementem sukcesu.

4. Reakcja na zmianę jest ważniejsza niż realizowanie planu:

•

harmonogramy powinny być elastyczne,

•

wymagania do aplikacji zmieniają się: zamawiający będzie miał

jakieś uwagi, będzie nanosił poprawki, proponował dodanie lub

usunięcie jakichś funkcjonalności,

•

lepsze jest tworzenie dokładniejszych harmonogramów na krótkie

okresy i ogólniejszego planu na dłuższe przedziały czasowe.

35

GK (PSI(1) - 2009)

Fundamenty lekkich metod

TSI

36

GK (PSI(1) - 2009)

Reguły odróżniania lekkich i

ciężkich metodyk TSI

1. Najwyższym priorytetem jest zadowolenie zamawiającego

(klienta): wczesne i ciągłe dostawy wersji systemu.

2. Wszelkie zmiany wymagań, nawet w końcowych stadiach

projektu, nie są niczym złym. Zmiana wymagań jest czymś
pozytywnym, ale wymaga takiego tworzenia systemu, aby
miał elastyczną strukturę i aby każda pojawiająca się zmiana
miała minimalny wpływ na jego całość.

3. Kolejne wersje oprogramowania systemu dostarczane są

często, z naciskiem na krótkie terminy.

4. Zespół tworzący system musi mieć osoby, które w różnym

zakresie będą codziennie pracować razem z zamawiającym w
całym okresie trwania projektu.

5. Projekty powinny być budowane wokół wyróżniających się w

zespole indywidualistów. Ludzie są uznawani za
najistotniejszy czynnik sukcesu.

6. Najbardziej wydajnym i efektywnym sposobem

przekazywania informacji pomiędzy członkami zespołu jest
rozmowa, co jest charakterystyczne dla metodyk lekkich.
Różnego rodzaju specyfikacje mogą powstawać, jeżeli tylko
są potrzebne, ale nie jest to wymóg.

37

GK (PSI(1) - 2009)

Reguły odróżniania lekkich i

ciężkich metodyk TSI

7. Działające oprogramowanie jest podstawową miarą postępu

prac projektowych. Postęp projektu jest mierzony liczbą

funkcjonalności, które spełniają potrzeby zamawiającego.

8. Lekkie metodyki promują tworzenie systemu ze stałą

prędkością, bez nadmiernego forsowania tempa.

9. Ciągła dbałość o techniczną doskonałość i dobry projekt

zwiększa zwinność. Wysoka jakość jest kluczem do szybkości.

10. Prostota, rozumiana jako sztuka osiągania zamierzonego

celu przy wykorzystaniu najprostszych środków. Zmiany,

które będą musiały zostać kiedyś dokonane, będą łatwe do

przeprowadzenia dzięki prostocie już utworzonych

rozwiązań.

11.Najlepsze architektury, wymagania i projekty mają swój

początek w samoorganizujących się zespołach.

12.W regularnych odstępach czasu zespół określa, jak być

bardziej efektywnym, a potem dostosowuje się do

zdefiniowanych w ten sposób zasad. Grupa ciągle „dostraja”

swoją organizację, zasady i wzajemne relacje. Jej członkowie

są świadomi, iż zmienia się otoczenie zatem muszą zmieniać

swoje zachowanie.

• Scrum

• LSD (Lean Software Development)

• FDD (Feature Driven

Development)

• ADP (Adaptive Software

Development)

• XP (Extreme Programming)

38

GK (PSI(1) - 2009)

Najpopularniejsze lekkie

metodyki TSI

Bez względu na przyjętą metodę, metodyki i stosowane

techniki w procesie tworzenia systemu informatycznego oraz
pomimo dobrych intencji zespołu projektowego, może system
nie powstać. Przyczyn porażki może być wiele, ale najczęściej
wymienia się:



brak dobrego rozeznania zespołu projektowego w złożoności

tworzonego systemu,



zbyt optymistyczne oszacowanie kosztów systemu oraz

harmonogramu jego realizacji,



uwikłanie się zespołu projektowego w wymagający i

skomplikowany proces tworzenia systemu,



niedostateczne zaangażowanie użytkownika w proces

tworzenia systemu.

Wyjściem z tej sytuacji może być skupienie się na
prostych technikach umożliwiających skuteczną
realizację postawionych przed zespołem zadań. Taką
perspektywę tworzą lekkie metodyki TSI.

39

GK (PSI(1) - 2009)

Przyczyny niepowodzenia

Wyróżnia się dwa zasadnicze podejścia do tworzenia systemu
informatycznego: podejście

tradycyjne

i podejście

obiektowe

.

•„tradycyjne” oznacza w tym przypadku niestrukturalne;
•tworzenie projektu wysokiego poziomu oznacza
stosowanie się do dokumentu i podziału;
•brak zaangażowania użytkowników,
•zastosowanie tekstowej a nie graficznej (diagramowej)
dokumentacji,
•nacisk na sposób osiągnięcia wyników, a nie na same
wyniki.

40

GK (PSI(1) - 2009)

Podejście do tworzenia

systemu

Tradycyjn
e
podejście
do
tworzeni
a
systemu

Użytkowni
cy

Dostarczenie

warunków

odniesienia

i informacji

Warunki,

informacje

Analiza

wymagań

Analiza notatek

itp.

Określenie
wymagań

Szkic
Specyfikacji
wymagań

Poprawa
specyfikacji
wymagań

Specyfikacja
wymagań

Tworzenie

projektu

wysokiego

poziomu

Specyfikacja
projektu
wysokiego
poziomu

Do specyfikacji

programu,

kodowania

itd.

Przegląd szkicu

specyfikacji

wymagań

Specyfikac
ja

Uwagi z przeglądu

41

GK (PSI(1) - 2009)

GK (PSI(1) - 2009)

42

Podejście strukturalne

- przedmiotem zainteresowania są elementy systemu,

wzajemne powiązania tych elementów, relacje które w nim zachodzą; definiowane
są etykiety-obiekty z których system się składa, strumienie przepływu danych. To
podejście strukturalne jest w chwili obecnej najczęściej, najchętniej i
najskuteczniej stosowane do praktycznej budowy systemu informatycznego.

Podejście obiektowe

- zakłada, że procesy informacyjne i struktura w której te

procesy zachodzą stanowią pewną całość. W obiekcie który będziemy budować w
systemie będziemy wyodrębniać części związane ze strukturami danych i części
związane z algorytmami ich ... Łączne rozpatrywanie danych i metod ich daje
możliwość bardzo systematycznego budowania bardzo dużych systemów
informatycznych, ale nakłada także pewne ograniczenia :należy bowiem
rozpatrywać wtedy wszystkie procesy informacyjne i elementy systemu
informatycznego w kategoriach tzw. Klas. Do tych klas trzeba budować
odpowiednie metody danych, odpowiednie struktury danych, które odpowiadają za
gromadzenie i przetwarzanie informacji a także projektować specjalne mechanizmy
komunikacji między obiektami, dzięki czemu system zbudowany w oparciu o
metodologie obiektowa pozostaje nadal system - "obiektem spójnym", mimo że
każdy z obiektów ma daleko posunięta autonomie, że może być budowany przez
odrębne zespoły programistów.
Ta metodologia zyskuje na znaczeniu z uwagi na to że pozwala budować duże i
złożone systemy informacyjne w zespołach wieloosobowych (praca grupowa).
Jednak systemy obiektowe są o wiele trudniejsze i bardziej złożone od systemów
strukturalnych. W praktycznej działalności my zostajemy przy podejściu
strukturalnym.

Podejście przyrostowe

- metody są wyodrębnione jako odrębna filozofia, tworzenia

systemów nie koniecznie od podstaw, nie koniecznie od zera tylko jakby rozwijania
na bazie istniejących systemów, systemu o ciekawszych, bogatszych możliwościach.
Mówiąc "system informacyjny", często wydaje się nam, że to jest jakaś pojedyncza
indywidualność, którą da się łatwo wskazać, wyodrębnić. Tymczasem w
rzeczywistości możemy wyróżnić różne rodzaje systemów informacyjnych (opartych
o różną metodologie).