Wykorzystanie techniki IDEF0 i relacyjnej bazy danych we ...
Wykorzystanie techniki IDEF0 i relacyjnej bazy danych we ...
Wykorzystanie techniki IDEF0 i relacyjnej bazy danych we ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
ównoleg∏oÊç realizacji ró˝nych etapów rozwoju projektu<br />
mo˝e prowadziç do sytuacji, w której informacj´<br />
<strong>we</strong>jÊciowà dla pewnego zadania mogà stanowiç<br />
cele, które planuje si´ osiàgnàç w innym aktualnie<br />
realizowanym zadaniu. W takim wypadku nale˝y<br />
oczywiÊcie dokonaç <strong>we</strong>ryfikacji poprawnoÊci uczynionych<br />
za∏o˝eƒ po zakoƒczeniu tego zadania.<br />
Bardzo istotnà cechà <strong>techniki</strong> <strong>IDEF0</strong> jest omówiona<br />
wczeÊniej mo˝liwoÊç zbudowania hierarchicznej struktury<br />
kostek reprezentujàcych pewnà funkcj´ procesu.<br />
Umo˝liwia to tworzenie definicji zadaƒ projektowych<br />
o ró˝nym poziomie ogólnoÊci i dokonywanie<br />
dekompozycji zadaƒ uj´tych w sposób ogólniejszy na<br />
bardziej szczegó∏o<strong>we</strong> zadania czàstko<strong>we</strong>, nale˝àce<br />
do hierarchicznie ni˝szych poziomów opisu procesu<br />
projekto<strong>we</strong>go. Warto zauwa˝yç, i˝ najogólniejsze uj´cie<br />
mo˝e polegaç na potraktowaniu ca∏ego projektu<br />
jako pojedynczego zadania, dekomponowanego<br />
nast´pnie na zadania odpowiadajàce dzia∏aniom<br />
wykonywanym w procesie rozwoju projektu. Dzia∏ania<br />
takie mogà mieç zarówno charakter ÊciÊle techniczny,<br />
jak i wià˝àcy si´ np. z zarzàdzaniem projektem<br />
lub jego finansowaniem. Schemat dekompozycji<br />
zadania projekto<strong>we</strong>go na zadania o wy˝szych<br />
stopniach szczegó∏owoÊci pokazano na rys. 3.<br />
Rys. 3. Dekompozycja zadania projekto<strong>we</strong>go na zadania<br />
czàstko<strong>we</strong><br />
Wykonanie zadania projekto<strong>we</strong>go powoduje na<br />
ogó∏ powstanie nowych zasobów informacji projekto<strong>we</strong>j,<br />
które sà traktowane jako wielkoÊci wyjÊcio<strong>we</strong><br />
(efekty) tego zadania. Wynikajàca stàd zmiana<br />
dotychczaso<strong>we</strong>j definicji produktu mo˝e polegaç na<br />
zdefiniowaniu no<strong>we</strong>go komponentu i równoczesnym<br />
utworzeniu jego pierwszej <strong>we</strong>rsji, utworzeniu na podstawie<br />
jednej z ju˝ istniejàcych (niekoniecznie ostatniej)<br />
<strong>we</strong>rsji pewnego komponentu produktu jego<br />
no<strong>we</strong>j <strong>we</strong>rsji lub wprowadzeniu zmian do definicji<br />
istniejàcej <strong>we</strong>rsji komponentu. Wyniki zadania sà<br />
przechowywane w nowo utworzonych lub zmodyfikowanych<br />
w tym zadaniu <strong>we</strong>rsjach dokumentów<br />
projektowych oraz zapisach wyjaÊniajàcych sposób<br />
post´powania lub/i zawierajàcych motywacje podejmowanych<br />
decyzji. Schemat struktury informacji<br />
wyjÊcio<strong>we</strong>j, która mo˝e byç efektem wykonania zadania<br />
projekto<strong>we</strong>go, pokazano na rys. 4.<br />
Warto zauwa˝yç, i˝ miejsce danego zadania w hierarchii<br />
wszystkich zadaƒ procesu projekto<strong>we</strong>go jest<br />
jednoznacznie okreÊlone przez wartoÊç etykiety tego<br />
zadania, utworzonej zgodnie z regu∏ami sk∏adni etykiet<br />
kostek <strong>IDEF0</strong> i przechowywanej w jednym z jego<br />
atrybutów. Z uwagi na tak du˝e znaczenie tego atrybutu,<br />
jego wartoÊci powinny byç generowane przez<br />
kod aplikacji <strong>bazy</strong> <strong>danych</strong> u˝ywanej do wspomagania<br />
realizacji procesu projekto<strong>we</strong>go, a zdefiniowanie<br />
jednoznacznego indeksu na kolumnach iden-<br />
Rys. 4. Struktura informacji wyjÊcio<strong>we</strong>j zadania projekto<strong>we</strong>go<br />
tyfikatora projektu i etykiety zadania powinno dodatkowo<br />
gwarantowaç zachowanie unikatowoÊci etykiet<br />
zadaƒ w obr´bie danego projektu. Stosowanie etykiet<br />
zadaƒ projektowych budowanych zgodnie z zasadami<br />
<strong>techniki</strong> <strong>IDEF0</strong> bardzo u∏atwia wyszukiwanie<br />
w bazie <strong>danych</strong>, przy u˝yciu tworzonych w kodzie<br />
aplikacji k<strong>we</strong>rend SQL, informacji o podzbiorach zadaƒ<br />
danego projektu. Warunki wyszukiwania takich<br />
k<strong>we</strong>rend formu∏uje si´ dla etykiet zadaƒ projektowych<br />
i zawierajà one jako wartoÊci odniesienia wzorce<br />
ciàgów znakowych, które ∏atwo okreÊliç dla etykiet<br />
niektórych podzbiorów zadaƒ. Na przyk∏ad, etykiety<br />
wszystkich zadaƒ bezpoÊrednio hierarchicznie podporzàdkowanych<br />
zadaniu o etykiecie A14 sà zbudowane<br />
zgodnie z szablonem A14?, gdzie znak zapytania<br />
zast´puje dowolny pojedynczy znak na koƒcu<br />
etykiety. Z kolei wzorcem etykiet zadaƒ nale˝àcych<br />
do ga∏´zi drzewa hierarchii rozpoczynajàcej si´ od<br />
kostki o etykiecie A14 jest ciàg A14*, w którym<br />
gwiazdka oznacza dowolny ciàg znakowy o niezero<strong>we</strong>j<br />
d∏ugoÊci.<br />
Trzeba podkreÊliç, i˝ traktowanie procesu projekto<strong>we</strong>go<br />
jako zbioru zadaƒ nie pociàga za sobà<br />
koniecznoÊci okreÊlenia ich ustalonej sek<strong>we</strong>ncji, czyli<br />
nie jest równoznaczne z ograniczeniem si´ do rozpatrywania<br />
procesów o charakterze sek<strong>we</strong>ncyjnym,<br />
gdy˝ o przystàpieniu do wykonywania ka˝dego<br />
z zadaƒ decyduje wy∏àcznie dost´pnoÊç informacji<br />
<strong>we</strong>jÊcio<strong>we</strong>j oraz niezb´dnych zasobów, co czyni<br />
mo˝liwym równoleg∏e wykonywanie zadaƒ niekolidujàcych<br />
pod tym wzgl´dem ze sobà. Stosowanie<br />
kostek <strong>IDEF0</strong> jako graficznej reprezentacji zadaƒ<br />
sprzyja prawid∏o<strong>we</strong>mu rozumieniu tego aspektu<br />
proponowanego modelu procesu projekto<strong>we</strong>go.<br />
Aplikacja <strong>bazy</strong> <strong>danych</strong><br />
do wspomagania procesów projektowych<br />
Przedstawiony model procesu projekto<strong>we</strong>go zosta∏<br />
wykorzystany przy budowie aplikacji <strong>relacyjnej</strong><br />
<strong>bazy</strong> <strong>danych</strong> przeznaczonej do wspomagania procesów<br />
projektowych. Zasadniczym celem by∏o przetestowanie<br />
poprawnoÊci i przydatnoÊci modelu,<br />
zatem aplikacja mog∏a zostaç wykonana przy u˝yciu<br />
stosunkowo prostego narz´dzia, jakim jest Microsoft<br />
Access. Wykorzystano przy tym mo˝liwoÊci dostarczane<br />
bezpoÊrednio przez to Êrodowisko, takie jak<br />
tworzenie k<strong>we</strong>rend przechowywanych w bazie da-<br />
ROK WYD. LXIX ZESZYT 10/2010 21
Change language