background image

Projektowanie 

systemów 

informatycznych

Metody tworzenia systemu 

informatycznego

background image

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)

background image

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

background image

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)

background image

zadani

a

fazy

dokumenta

cja

wspomaga

nie TSI

Dziedzina 

przedmiotowa 

(DP) 

Zespół 

projektują

cy 

Kryteria 

oceny 

wyniki 

analiz

cele, problemy, 

potrzeby 

informatyczne

tworzeni

systemu

kierowan

ie 

projekta

mi

prezentacja

eksperymental

na 

eksploatacja

akceptacja

korekty i 

modyfikacje

System 

informatyczn

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

background image

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)

background image

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)

background image

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)

background image

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)

background image

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)

background image

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)

background image

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 

background image

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 

background image

GK (PSI(1) - 2009)

14

Model kaskadowy 

background image

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 

background image

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

background image

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

background image

GK (PSI(1) - 2009)

18

Model prototypowania

background image

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

background image

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

background image

GK (PSI(1) - 2009)

21

Model według realizacji 

przyrostowej

background image

Model montażu z gotowych elementów

zwany też 

programowaniem z półkikł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

background image

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

background image

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

background image

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ń.

background image

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

background image

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

background image

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”.

background image

GK (PSI(1) - 2009)

29

Modyfikacje modelu 

kaskadowego – model „b”

Cechy:

podział na 

jednorazową 

ścieżkę tworzenia 

wielokrotnie 

powtarzana 

iteracyjną ścieżkę 

eksploatacji.

background image

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. 

background image

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.

background image

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

background image

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

background image

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

background image

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

background image

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. 

background image

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. 

background image

• 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

background image

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

background image

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

background image

Tradycyjn

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)

background image

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).


Document Outline