Spis treści
WSTĘP g A J /U /i Al i ’-'i t< l»sHH
PODSTAWY T W 't> R /l-N lA SYMTMÓW
ł^ k r ts i %kUtintkj rrM-i ąlyli ;^ ^ ;r n u Yyvtcn**mlormatyi/jiych KlaiyhkaK »a met.ąj>§ tworrrnia %y*tcmi** tnformjtycznych ( jril ź y o a »vi^biu ii
*tcm4j 1 4 1 Kierunki mudytik*, p l 4 2* tjtrnec*1a ¿¿tli *uw ¿n !4 \ Afl • J 4 4 Pt! *•,*>!> rwanie •
•
<
•
•
•
|) 13 Ig 2^
25 -
%
f
A
0
<
«
•
«1 *1
P y u m a i p ro b le m y
ROZDZIAŁ 2 P l A S O W \ M | S YS l i MÓW INFORMATYCZNYCH 2 1 Cele planowania system* •* informatycznych 2 2 Proces planowania systemu informatycznego 2 3 Fcrtnolowame strategii mf<*matyzacji(mfoplanu) 2 4 InfopUn zawartość 1 znas/cm e 2 5 Metody 1 techniki analizy sytuacyjnej 2 6 Restrukturyzacja proceviw gospodarczych P y ttn u • problemy
->w **•>Q ^ w«/a* ^4
35 . . . . .
.............
#
..
35 36 37 43 44 62
ROZDZIAŁ 3 STRI KT1 RAI.NA ANALIZA I PROJEKT O W AN Ih SYSTEMÓW INFO RM ATYCZNYCH .................................................................................................................... 64 3.1 Analiza system ów informatycznych . 3 2 Zakres strukturalnego projektowania systemów 3.3. Projekt ogólny 3 4 Projektowanie wejść 1 wyjść s y s te m u .................... . . . 3 5. Projektowanie interfejsu użytkownika .. .. . . ............................... 3 6 Projektowanie plików 1 bazy danych — ..................................................................... 85 Pytania i problemy ...................................... . .................................................................................. 89 ROZDZIAŁ 4. M ETODY I TECHNIKI STRUKTURALNEJ ANALIZY I PROJEKTÓW ANIA SYSTEM ÓW INFORM ATYCZNYCH ........................................... y
4.1. R odzaje m etod i technik TfeK
....................................................................................................
91 91
64
7
4.2. 4.3. 4.4. 4.5. 4.6.
M odele zw iązków encji ............................................................................. Diagram y przepływ u d a n y c h .................................................................... Grafy ISAC ................................................................................................... Słow niki/skorow idze d a n y c h .................................................................... Norm alizacja relacyjnego m odelu d a n y c h .......................................... 4.6.1. Relacyjny model danych .............................................................. 4.6.2. Przebieg normalizacji modelu r e la c y jn e g o ............................
4.7. Techniki d e c y z y jn e ...................................................................................... 4.7.1. Rodzaje technik d e c y z y jn y c h ...................................................... 4.7.2. Tablice d e c y z y j n e ............................................................................ 4.7.3. D rzew a decyzyjne i języ k s tr u k tu r a ln y .................................... 4.8. 4.9. 4.10. Pytania
Diagramy struktury ....................................................................................... Diagram y J a c k s o n a ....................................................................................... Analiza p r z y p a d k u ......................................................................................... i p r o b le m y .........................................................................................................
R O Z D ZIA Ł 5. S Y ST E M Y O B I E K T O W E ........................................................... 5.1. M odel o b i e k t o w y ........................................................................................... 5.2. Projektow anie obiektow e ........................................................................... Pytania i p r o b le m y ......................................................................................................... R O Z D ZIA Ł 6. M E T O D Y K I S P O Ł E C Z N E ......................................................... 6.1. Założenia m etodyk s p o łe c z n y c h ............................................................... 6.2. Proces stosow ania m etodyki S S M ........................................................... 6.3. Role w zespole projektow ym ................................................................... Pytania i p r o b le m y ........................................................................................................ R O Z D ZIA Ł 7. K O M P U T E R O W O W S P O M A G A N E T W O R Z E N IE S Y S T E M Ó W IN F O R M A T Y C Z N Y C H . P A K IE T Y C A S E 7.1. Pakiety C A S E - istota i g e n e r a c j e ......................................................... 7.2. Rodzaje pakietów C A S E ............................................................................ 7.3. W spom aganie cyklu życia s y s t e m u ......................................................... 7.4. M odyfikacja system ów .............................................................................. 7.5. K ierow anie realizacją projektów ............................................................ 7.6. Bieżące doskonalenie jako ści s y s t e m u ................................................. 7.7. Integracja i standaryzacja pakietów C A S E ......................................... 7.8. Przykład pakietu C A S E - S D W .............................................................. 7.9. T endencje rozw oju pakietów C A S E ...................................................... Pytania i p r o b l e m y ........................................................................................................ R O Z D Z IA Ł 8. W D R A Ż A N IE I U Ż Y T K O W A N IE S Y S T E M Ó W IN F O R M A T Y C Z N Y C H ................................................................................................. ^ 8.1. W drażanie system ów in f o r m a ty c z n y c h ................................................ v / 8.2. U żytkow anie, m odyfikacja i ad aptacja s y s t e m u ............................... 8.3. A daptacja system u na podstaw ie standard u E u r o M e t h o d ............. Pytania i p r o b le m y ........................................ ............................................................... SPIS L IT E R A T U R Y
¿y• ■ V /* *t.
J
»*, *
V_Ul/#.......................................................................................... * 1 ■|f O
f ^’a
*•a
‘
V •4••i •**•w • % *-*.*• •*;- • «
92
105
Wstęp
organizacjami go spodarczymi i administracyjnymi stymuluje powstanie różnych para162; dygmatów, wzorców tworzenia systemów informatycznych (TSI). Je162 dnocześnie, często w tych samych organizacjach, tworzy się systemy, 167 wykorzystując zakupione pakiety zastosowań, generatory zastosowań, 175 177 prototypowanie i metodyczne podstawy TSI. Celem niniejszej książki jest prezentacja i ocena różnorodnych metodyk, technik i narzędzi TSI, adekwatnych zwłaszcza dla faz planowania, analizy i projektowania 178 informatycznych systemów zarządzania. Cel zrealizowano w dwu wymiarach 178 - teoretycznym i praktycznym. Przede wszystkim, uporządkowano 182 więc bazę terminologiczną, opracowano teoretyczno-metodologiczne 187 191 podstawy TSI. Warstwa praktyczna wyraża się w podręcznikowej 196 postaci niniejszej książki - praca pomyślana jest jako podręcznik 200 do studiowania przedmiotu „Analiza i projektowanie systemów informatycznych” na kierunkach informatycznych. Wymiar praktyczny y- oznacza też ukierunkowanie książki na profesjonalne potrzeby analityków 208 i projektantów systemów. W tym celu materiał książki zilustrowano licznymi przykładami, wynikającymi z praktyki gospodarczej. Przedstawione instrumentarium metodyczne ma szczególne znaczenie w przypadku systemów złożonych. 2|i Niniejsza książka opiera się na bogatej literaturze przedmiotu i badaniach 216 własnych. Wiodącą rolę odgrywają materiały z licznych międzynarodowych 221 konferencji poświęconych różnym aspektom TSI. Forum wymiany poglądów 227 na ten temat od 1988 roku stała się organizowana przez Katedrę Informatyki Ekonomicznej Uniwersytetu Gdańskiego cykliczna międzynarodowa konferencja pod nazwą Information Systems D evelopm ent. 7
Stosownie do celu pracy skonstruowano jej układ, uwzględniając pięć następujących czynników: . • praktyczną użyteczność i funkcjonalność metodyk, technik i narzędzi TSI w projektowaniu i wdrażaniu złożonych systemów informatycznych, • sekwencję etapów cyklu życia systemu, • rozróżnienie trzech rodzajów metodyk tworzenia systemów informatycz nych: strukturalnych, obiektowych i społecznych, • przyjęty model metodyki tworzenia systemów informatycznych, • stopień akceptacji omawianych podejść w komercyjnych metodykach i pakietach CASE światowych firm doradczych. Książka składa się z siedmiu rozdziałów. Inicjuje ją rozdział poświęcony metodologicznym podstawom TSI. Zasadnicze znaczenie w tej dziedzinie ma zaproponowany model metodyki TSI. którego głównymi składnikami są modele dziedziny przedmiotowej (konceptualne), metody i techniki TSI oraz narzędzia wspomagające, tj. pakiety CASE. Po zdefiniowaniu pojęcia „metodyka” , przeprowadzono klasyfikację metodyk TSI ze względu na różne kryteria. Następnie przedstawiono pięcioetapowy cykl życia systemu. Inne niż metodyczne paradygmaty, tj. generatory zastosowań, pakiety zastosowań, oraz prototypowanie omówiono w ostatnim punkcie rozdziału. Stosownie do faz cyklu życia systemu, w rozdziale II przedstawiono planowanie systemów informatycznych. Treść rozdziału koncentruje się wokół pojęcia strategicznego planu informatyzacji, zwanego infoplanem. Omówiono pomocniczą rolę pełnioną przez macierze encji/procesów gospodarczych oraz różnorodne metody heurystyczne, jak: SW OT, sesja MetaPlanu, Istotne Czynniki Powodzenia (ICP) czy model spójności Broekstry. Na uwagę zasługuje omówienie w rozdziale ważkiej aktualnie tematyki restrukturyzacji procesów gospodarczych (ang. BPR - business processes reengineering). Rozdział 3 dotyczy zagadnień analizy oraz ogólnego i technicznego projektowania systemów informatycznych. Szczegółowej charakterystyce, ilustrowanej licznymi przykładam i, poddano podstaw ow e zasady projektowania wejść i wyjść systemu, interfejsu użytkownika (również w graficznym standardzie WIMP) oraz plików i baz danych. Treścią IV rozdziału są podstawowe metody i techniki strukturalne przydatne w fazach planowania, analizy i projektow ania systemów informatycznych. Po przedstawieniu zasad doboru m etod i technik do poszczególnych laz cyklu życia systemu scharakteryzowano następujące diagramowe, macierzowe i tabelaryczne metody i techniki modelowania danych i procesów: modele związków encji, diagram y przepływ u danych, grafy ISAC- u, słownik/skorowidz danych, normalizację relacyjnego modelu anych, techniki decyzyjne, diagramy struktury oraz diagram y Jacksona.
8
W kolejnym rozdziale scharakteryzowano model obiektowy oraz zasady analizy i projektowania systemów wykorzystujące ten model. Trzecie z metodycznych podejść do TSI, tj. podejście społeczne, przedstawiono w rozdziale 6 . W tymże rozdziale omówiono style zachowania w zespole projektowym i ich znaczenie dla właściwego doboru i funkcjonowania zespołu. W przedostatnim rozdziale scharakteryzowano pakiety CASE, uwzględniając ich podział na: wspomagające cykl życia systemu, dotyczące przechowywania danych i kierowania projektami oraz modyfikacji i adaptacji. Bliższej analizie poddano pakiet SDW. Rozdział 8 pracy poświęcony jest zagadnieniom dwu ostatnich faz cyklu życia systemu, tj. wdrażania oraz użytkowania, modyfikacji i adaptacji systemów informatycznych. W kwestii adaptacji systemów należy docenić znaczenie opracowanej w ramach Wspólnoty Europejskiej metody EuroMethod (obecnie ISPL), pozwalającej również na realizację przetargów i kontrolę ich wykonania w odniesieniu do dużych systemów informatycznych. Autor pragnie podziękować wielu informatykom - pracownikom naukowym, konsultantom, projektantom i studentom - za dyskusje i cenne uwagi. Miały one wpływ na ostateczną postać książki. Szczególne podziękowania chciałby złożyć prof. Gordonowi B. Davisowi z Uniwersytetu Minnesota, prof. Andersowi G. Nilssonowi z Uniwersytetu w Sztokholmie i Ronaldowi Langerhorstowi z firmy CAP Gemini Volmac.
Rozdział 1
Metodologiczne podstawy tworzenia systemów informatycznych
1.1. Zakres i składniki metodyki tworzenia systemów informatycznych Kluczowym pojęciem w dziedzinie analizy, projektowania i użytkowania systemów jest metodyka tworzenia systemów informatycznych. (TSI). Można ją zdefiniować jako: spójny, logicznie uporządkowany zestaw metod i procedur o charakterze technicznym i organizatorskim pozwalających zespołowi wykonawczemu realizować cykl życia systemu. Definicja ta nie precyzuje składników metodyki TSI. Na obecnym etapie jej rozwoju są to [109; 1 1 0 ; H 5 ]7 • formalizmy, modele opisu rzeczywistości - dziedziny przedmiotowej, jej "sta ty k i i dynamiki, zwane modelami konceptualnymi, • strukturyzacja procesu TSI w postaci odpowiedniej sekwencji etapów, podetapów i poszczególnych zadań, postaci cyklu życia systemu, • szczegółowe metody i techniki TSI - jego dokumentowania (w nawiązaniu do teoretycznych konstrukcji formalizmów), wraz z adekwatną symboliką graficzną, • narzędzia wspomaganego komputerowo TSI, w tym ich prototypowania, określane mianem CASE (ąng. computer-aided systems engineering) • specyfikacja wymagań merytorycznych wobec poszczególnych twórców oraz interdyscyplinarnego zespołu wykonawczego (projektowego), planującego rozwój systemu i realizującego proces TSI, • kryteria oceny jakości projektu i systemu oraz mechanizmy jej kontroli. Powiązania pomiędzy wymienionymi składnikami w postaci uogólnionego schematu przedstawia rys. 1.1 [116]. RozpozraniejpotrzehJnfonnatycznych „orgamzacji, założonych..celów wdrożenia systemu informatycznego i występujących problemów inicjuje proces TSI realizowany i sterowany przez zespół projektowy^_Analizę dziedziny przedmiotowej przeprowadza się za pomocą modeli dziedziny przedmiotowej, określonych metod i technik oraz pakietów komputerowego U
Dziedzina przedmiotowa (DP) Cele. problemy, potrzeby informatyczne
Wyniki a n a liz
Modele DP
Reguły Imodelowama
PROCES
Pojęcia abstrakcyjne
Tworzenie systemu
TW O RZEN IA
Kierowanie projektami
Fazy
Metody i techniki
Zespół
Projektujący
SYSTEM U okumentacja
Para' metry
INFORM ATYCZNEGO
Pakiety
A l Narzędzia \ komputerowego wspomagania
Zadania
'soomaganie TSI
(TSI) Korekty i modyfikacje Prezentacja 1i eksperymentalna eksploatacja
System inform atyczny
Kryteria oceny
Akceptacja R\s. 1.1. Powiązania między składnikami metodyki TSI
wspomagania TSI. Dziedzina przedm iotow a (DP). czyli badany wycinek rzeczywistości, stanowi obiekt, dla którego tworzy się system informatyczny. Przykładami DP są: działalność organizacji gospodarczej bądź administracyjnej. gospodarka materiałowa fum y, zarządzanie kadrami, obsługa sesji egzaminacyjnej, obsługa rezerwacji biletów. Podstawy opisu dziedziny przedmiotowej są odpowiednie form alizm y, modele DP, zwane modelami konceptualnymi (por. [109]). Pozwalają one na odzwierciedlenie zarówno statyki, jak i dynamiki dziedziny przedmiotowej. Poszczególne elementy modeli mogą być dokumentowane za pomocą odpowiednich m etod i technik Mają one zazwyczaj postać diagramów. Analiza ich struktury, parametrów i zasad użytkowania pozwala na dobór właściwych n arzęd zi w sp o m ag ają 12
cych proces TSI. powszechnie nazywanych pakietami CASE (ang computer-aided systems engineering ). a scharakteryzowanych szczegółowo w rozdziale 7. W wyniku powstaje przekazany do oceny, a następnie użytkowania w organizacji gospodarczej lub administracyjnej system informatyczny _ tj. uporządkowany zestaw wzajemnie powiązanych składników : kadry, danych, procesów, sprzętu, oprogramownia i sieci komputerowej, współ pracujących dla wykonania założonych funkcji, pozwalających na rozwiązanie występujących problemów i osiągnięcie założonych celów w danej dziedzinie przedmiotowej. Problematyka zawarta w niniejszej książce dotyczy systemów informatycznych zarządzania, a więc ukierunkowanych na wspomaganie działalności organizacji gospodarczych i administracyjnych na poziomie operacyjnym, taktycznym i strategicznym. Modele, metody i skomputery zowane narzędzia tworzą podstawowy w arsztat anality ka i projektanta systemów . Oddziałują one poprzez reguły modelow ania, sposoby dokumentowania oraz komputerowego wspomagania, na procedurę i efektywność tworzenia systemu informatycznego, je s te m , opracowany w trakcie procesu TSI przy użyciu instrumentarium warsz tatowego. podlega ocenie według kryteriów spójności i kompletności projektu i systemu. W zależności od wyników oceny, system jest przyjmowany do eksploatacji bądź ponownie planowany, analizowany, projektowany i wdrażany.
1.2. Klasyfikacja metodyk tworzenia systemów informatycznych Literatura przedmiotu wskazuje na dużą różnorodność metodyk TSI. Dotyczy to wszystkich składników' metodyki: zarówno ich zakresu (zestawu pełnego lub cząstkowego), jak poszczególnych formalizmów, metod, technik i narzędzi. Jednak do tej pory, brak jest uogólnionych powszechnie uznanych podstaw teoretycznych TSI. Jakie są główne przyczyny tego stanu rzeczy? Wydaje się. że najw'ażniejsze to nowość i wczesny okres rozwoju tej dziedziny, a w związku z tym pewna żywiołowość pojawiania się propozycji i podejść. Związane z TSI zagadnienia należą do problemów n ieu stru k tu ry zo w an y ch , a więc złożonych zarówno w zakresie n.h definiowania^ jak i w konsekwencji —rozwiązywania. Na obecny stan mają też zapewne wrpływ: specyfika dziedzin przedmiotowych poddawanych procesowi modelowania, szybkie zmiany w sferze inżynierii oprogramow ania pozwalające na konstruowanie zautomatyzowanych narzędzi wspomagania procesu TSI. Zastanawiając się nad przyczynami omawianej sytuacji. Cen 13
« W t o t o |IM . ii /apulnienic to jest trudne- /<• w/gK-du na brak d ó b r« /definiowanych tcon-.vc.-moh podstaw wyra/ama potrzeb informatycznych. Występują zatem trudności w stworzeniu zaawansowanego, poprawnego logicznie, precyzyjnego i jednocześnie łatwo zrozumiałego dla użytkownika formalizmu definiowania tych potrzeb. W związku z próbą analizy metodyk TSI. ich zbiorowość należy sklasyfikować. 7 podany ch wcześniej w zględów nie jest to zadanie łatwe. Zaproponowano następujące kryteria oceny. • podejście do procesu TSI. • definiowanie danych bądź procesów w projekcie. • oddziaływanie systemu informaty cznego na dziedzinę przedmiotową, • kierunek TSI. Pierwsze podstawowe kryterium umożliwia wyodrębnienie metodyk technicznych i społecznych [Ib]. Nazwy są tu umowne, choć oddają one istotę podejść. Metodyki techniczne są ukierunkow ane na realizację dobrze ustrukturyzowanego procesu TSI. z pełnymi i sformalizowanymi modelami opisu rzeczywistości. Podejście opiera się na założeniu, ze analityk ma neutralny wpły w na organizację w procesie TSI. Z kolei metody ki społeczne akcentują organizacyjne, psychologiczne i socjologiczne problemy zw iązane z TSI. Celem tego podejścia jest zrozumienie roli s\ stemu informacyjnego w ramach sy stemu społecznego i oddziały wanie na oby dw a. Rola analityka jest tu bardziej aktywna. Powodzenie strategii TSI jest w tym wypadku uzależnione od umiejętności specy fikacji podstaw owych uwarunkowań organizacyjnych i kadrowych, a także od możliwości oddziaływ ania na nie. Metodykom technicznym zarzuca się. iż stanów ią one swoiste „książki kucharskie", które mogą ominąć istotę problemu ze w zględu na mechaniczne jego rozwiązywanie, stosownie do zalecanej w konkretnej metodyce procedury. Natomiast podejście społeczne nie pozw ala na tak dokładne sprecyzowanie potrzeb informatycznych, aby były one podstaw ą realizacji kolejnych faz cyklu życia systemu. Dobre rezultaty daje integracja obydwu podejść. System jest wówczas tworzony w pow iązaniu z jedny m z. wymie nionych w podrozdz. 1.3 i 1.4 cykli życia system u, natomiast fazę planowania realizuje się. stosując metody i techniki społeczne, scharak teryzowane w rozdz. 2 i 6 . Kwestia modelowania danych i procesów dziedziny przedmiotowej wiąże się ze strukturalny m podejściem do TSI. M etodyki zorientowane na dane koncentrują analizę i projektowanie system ów w okół strukturyzacji danych użytkowanych w organizacji. Z kolei stosując metodyki zorientowane na procesy, dokonuje się dekompozycji procesów gospodarczych w określonej dziedzinie przedmiotowej i określa związki między nimi. Na tej podstawie uw zględmając potrzeby użytkowników, specyfikuje się dane elementarne
Metodyki TSI stanow y zazwyczaj kompromis, o różnej proporcji, pomiędzy rozwiązaniami ukierunkowanymi na dane a rozwiązaniami ukierunkowanymi na procesy. Podstawą kolejnego podziału metodyk TSI są relacje pomiędzy dziedzina przedmiotową (wycinkiem rzeczywistości) a systemem informatycznym [061 . Pierwszy rodzaj związku to organizacyjne odwzorowanie zakładające pasywną rolę systemu informatycznego. Decyzje i działania są podejmowane w dziedzinie przedmiotowej. W związku z tym system informatyczny musi hyc prawdziwym jej odzwieiciedleniem, aby mógł funkcjonować efektywnie. Założenie precyzyjnego opisu istniejącej sytuacji ogranicza możliwość wprowadzania innowacyjnych rozwiązali. Przeciwne podejście —organizacyj nego sterow ania — zakłada wyróżnienie systemu sterowania, w którym podejmuje się decyzje i działania wpływające na dziedzinę przedmiotową. System informatyczny jest jego integralną częścią. Nacisk kładzie się bardziej na określanie potrzeb informatycznych, a mniej na precyzyjny opis świata rzeczywistego. W polskiej literaturze te dwa rodzaje podejść określa się mianem pasywnego i aktywnego [80]. Wreszcie ostatnie z wymienionych kry teriów umożliw ia wy odrębnienie metodyk zstępujących (ang. top-down) i wstępujących (ang. bottom-up). Podejście zstępujące oznacza tworzenie systemu poprzez stopniowe, hierarchiczne wyodrębnienie jego składników aż do podstawowego poziomu szczegółowości. Podejście wstępujące z kolei polega na stopniowym budow aniu syntezy systemu poprzez integrację jego elementów , począw szy od poziomu podstawowego. Praktycznie uży tkowane metodyki stanowią zazw yczaj swoisty kompromis pomiędzy podejściem technicznym a społecz nym. specyfikacją danych i procesów, aktywnego i pasywnego wpływu na dziedzinę przedm iotow ą oraz wstępującego bądź zstępującego toku projektowania. Aktualnie dominuje w- literaturze i praktyce klasyfikacja opierająca się na połączeniu kryteriów dotyczących opisu dziedziny przedmiotowej oraz doświadczeń praktycznych TSI. Wyróżnia się więc trzy „szkoły . trzy rodzaje podejść metodologicznych do TSI: • strukturalne, • obiektowe, • społeczne. Historycznie jako pierwsze ukształtowało się podejście strukturalne, zwane również strukturalno-relacyjnym ze względu na ścisłe powiązania z modelem relacyjnym baz danych. Jest to podejście formalne, polegające na tworzeniu uporządkow anego systemu, hierarchicznej strukturze, którego sterowalne składniki stanowią dobrze zdefiniowane moduły tunkcji i danych oraz związki między nimi. Cechą charakterystyczną, tego podejścia jest 15
oddzielne modelowanie danych i procesów, wykorzystujące diagramowe i macierzowe melody i techniki. W praktycznych zastosowaniach nadal dominuje podejście strukturalno-relacyjne, jednak w literaturze z zakresu informatyki ekonomicznej i w pracach badawczych istotniejszą rolę odgrywa podejście obiektowe. Opiera się ono na wyodrębnieniu obiektu, czyli każdego bytu pojęcia lub rzeczy, mających przypisane znaczenie w kontekście rozwiązywania problemu w danej dziedzinie przedmiotowej. Pojęcie obiektu umożliwia integralne modelowanie danych i procesów. Podejście społeczne, związane z nazwiskiem Checklanda 119], akcentuje aspekty ludzkie i społeczne - psychologiczne i socjologiczne - w tworzeniu systemów informatycznych. Ó ile wcześniej wymienione podejścia dotyczą całego cyklu życia systemu, o tyle podejście społeczne jest użyteczne w fazie planowania systemów informatycznych. (Metodyce strukturalnej poświęcono głównie rozdziały 2 . 3 i 4. podejściu obiektowemu rozdział 5, a społecznemu rozdział 6 ). Największą liczbę propozycji metodycznych, zarów no akademickich, jak i komercyjnych, ma podejście strukturalne. Przykładami uznanych metodyk strukturalnych są: • SSADM (ang. Structured Systems Analysis and Design M ethod ), standard finansowo wspierany przez rząd brytyjski, • IE (ang. Information Engineering ), m etodyka w ykorzystująca prace J. Martina, stosowana w wielkich korporacjach, • YSM (ang. Yourdon Systems M ethod ), m etodyka proponow ana przez E. Yourdona. Z kolei najbardziej zalecane metodyki obiektowe to (por. rozdz. 5): • OMT (ang. Object Modelling Technique ), • RATIONAL z językiem UML. Wreszcie, największym zainteresowaniem jak o m etodyki społeczne cieszą się (por. rozdz. 6 ): • SSM (ang. Soft Systems Methodology) P. Checklanda, • ETHICS (ang. Effective Technical and Human Implementation oj Computer-Based Systems) E. Mumford. Komercyjne metodyki, oferowane przez firmy doradcze i komputerowe. wspomagane są często przez związane z nimi pakiety C A SE. Przykładem może być metodyka Information Engineering w raz ze zw iązanym z nią pakietem IEWorkbench. Na podstawie wiedzy o metodykach, technikach i narzędziach tworzenia systemów informatycznych zespół projektowy może zaproponować własną
ónoi o a * v-* —- v - f n e , kom binow ane m etodyki TSI [119, & o s w owym wai unkięm j c h efektyw nego użytkow ania jest oprace16
niejednorodnymi technikami * I ' r ^ ^ proponowanymi dla kolejnych faz TSI. Reguty.te deCniuwiciśle możliwości transformacji poszczególnych kategorii modeli danych , procesów typowych dla kolejnych aż. cyklu życia systemu. Przykładem może być transformacja pomiędzy gratami tSAC a diagramami związków encji [ 1 1 9 ] Składniki elastycznych, kombinowanych metodyk TSI przedstawia rys. 1.2. *111
1
Rys. 1.2. Elementy elastycznej melodyki TSI
Dotychczasowe rozważania skłaniają ku próbie określenia .wymagań, które pow inna spełnić racjonalna metodyka. Wydaje się. iż najistotniejsze »z•» nich «*/>U w** 4to:■ • metodyka powinna objąć cały cykl życia systemu, od analizy do adaptacji i modyfikacji, przy jednoczesnym umożliwieniu płynnych przejść pomiędzy ✓1Imm# • /\ *-» ••• z\fłr* i II 7llll fazami; A % poszczególnymi * metodyka TSI winna objemować różnorodne, dostosowane do specyfiki podejścia, metody, techniki i narzędzia komputerowe ułatwiające Zrozum ienie problemów, ich analizę i rozwiązanie; * metodyka powinna ułatwiać porozumiewanie się pomiędzy różnych grupami zawodowymi tworzącymi nowy SI - dotyczy to zwłaszcza wstępnych faz procesu TSI, gdy należy zaoferować narzędzie (formalizm) ułatwiające porozumienie informatyków i użytkowników; * m etodyka powinna być stosunkowo łatwa do opanowania i dostosowana do szerokiej klasy problemów oraz zawierać mechanizmy ewolucyjuosęi i modyfikowalnośę.L,. •
|
17
Powyższe wymagania stanowią jednocześnie wskazówki przy dobieraniu odpowiedniej metodyki. W tym aspekcie godny podkreślenia jest wysiłek Wspólnoty Europejskiej w celu stworzenia jednolitej metodyki, którą nazwano EuroMethod. Nad jej szczegółami pracował zespół ekspertów z państw członkowskich. Zespół len, wywodzący się zarówno z instytucji badawczych, jak i organizacji gospodarczych i doradczych, brał pod uwagę podejścia metodyczne wywodzące się z następujących krajów: • Wielkiej Brytanii - SSADM (ang. Structured Systems Anulysis and Design Method), • Francji - MERISE, • Włoch - DAFNE (ang. DA ta and Function NEtworking), • Holandii - SDM (ang. System Development Methodology), • Hiszpanii - MEIN (hiszp. MEthodologica INformatica), • Niemiec - VORGEHENSMODEL, • Wielkiej Brytanii i USA - IE (ang. Information Engineering). Powstała obszerna dokumentacja metodyczna [39; 100, s.260]. Jej zastosowanie było ograniczane sprzecznymi, jak się okazało, interesami organizacji administracyjnych, gospodarczych i badawczych. Aktualnie EuroMethod (nazwa zmieniona na ISPL - ang. Information Service Procurement U tra ty) służy jako narzędzie do realizacji przetargów na duże projekty informatyczne, co przedstawiono w podrozdz. 8 .3 .
1.3. Cykl życia systemu Współczesne systemy informatyczne w organizacjach gospodarczych są złożonymi całościami, obejmującymi obszerne dziedziny przedmiotowe. Wynika to z samej istoty systemu inform atycznego w iążącego ludzi, metody i środki techniczne w celu racjonalnego w ykonania złożeń. Jednocześnie użytkownicy skonstruowanego system u oczekują, że będzie on sprawny, użyteczny, niezawodny oraz dostosow any do uprzednio zgłoszonych potrzeb informatycznych. Całość wspom nianych uwarunkowań stymuluje potizebę skutecznego kierowania projektowaniem i użytkowaniem systemu. Działania te stanowią treść procesu, który określić m ożna jako cX l życia .systemu. Cykl ten jest. ciągiem. wyodrębnionych, wzajemnie Spójnych, etapów, pozwalających na. pełne i zaprojektowanie, a następnie użytkowanie systemu informatycznego.
Mimo prob standaryzacji nie ustalono jednolitego wzorca - sta n d a rd u p jcesu tworzenia systemu informatycznego. Obecnie systemy informatyczne Powstają „w rytm " różnych cykli życia. Należy zaznaczyć, iż specyfika v * r5 “ . •Vr> A * K â— i m*v*
różnych typów cykli w dużej mierze jest uzależniona od rozwoju sprzętu i oprogramowania, a także rozwoju metodycznych podstaw tworzenia systemów informatycznych. Uznanie zyskały dwa wzorce - liniowy i spiralny. W praktyce liniowy typ cyklu życia systemu dominuje zarówno w podejściach strukturalnych, jak i obiektowych. W wielu propozycjach cykl ten podzielony jest na różną (od kilku do kilkunastu) liczbę etapów o zróżnicowanych nazwach. Liczne opracowania i podręczniki powielają tradycyjny, liniowy, „kaskadowy czy „ciężki" model cyklu życia systemu, niekiedy o nieco zmienionych sekwencjach etapów, zróżnicowanym zakresie i odmiennych terminologiach. M odyfikacje te wynikają z dążności dopasowania do celów i założeń konkretnego systemu bądź organizacji. Przyjęty proces tworzenia pozwala na racjonalne kierowanie zespołem wykonawczym, koordynowanie zadań zgodnie z przyjętym harmonogramem, kontrolowanie realizacji przyjętych założeń. Koniecznymi cechami modelu cyklu życia są jego zupełność i kompletność, oznaczające konieczność ścisłego opisu w szystkich etapów niezbędnych przy zaprojektowaniu, a następnie użytkowaniu elementów systemu: oprogramowania, sprzętu, podręczników, kadr i szkolenia. Każdy z etapów cyklu życia systemu powinien mieć ściśle określone wejścia, wyjścia, składniki, funkcje, dokumenty, sprzężenia z innymi etapam i. Uzgodniony wynik prac na każdym etapie powinien być zatwierdzony, również w sposób formalny, przez zespół wykonawczy. M ożliwe są oczywiście iteracje pomiędzy etapami, lecz ich nadmiar powoduje rozmycie granic między fazami. Może to utrudniać czy nawet uniemożliwiać kierowanie i kontrolowanie postępu prac. Przykładowy, tradycyjny, liniowy cykl życia systemu przedstawia rys. 1.3 [73]. W praktyce jednak już w trakcie użytkowania systemu dokonywanych jest wiele czynności modyfikacyjnych, które oznaczają podejmowanie zadań z zakresu planowania, analizy i projektowania. Dlatego autorzy [8 ] sugerują wyodrębnienie ścieżki tw orzenia i cykli eksploatacji Skonstruowany zgodnie z nią system podlega modyfikacjom i poszerzeniom w kolejnych cyklach eksploatacji. Rysunek 1.4 przedstawia sposób tworzenia nowych wersji udoskonalonych systemów dla danej dziedziny przedmiotowej. W związku z opisaną różnorodnością cykli życia systemu trudno jest zalecić jakiś standard (kanon), zarówno w sensie struktury , jak i terminologii, który posiadałby walor uniwersalnej akceptacji. Jednakże na podstawie analizy i uogólnienia wiedzy oraz doświadczenia z dziedziny tworzenia systemów informatycznych cykl życia systemu można podzielić na pwc
następujących podstaw ow ych faz: 1) planow anie systemu----19
Powyższe wymagania stanowią jednocześnie « skazów ki przy d o b ie r a j S in y c h typów cykli w dużej mierze jest u/alei żniona od rozwoju spr/ętu odDOwiedniej metodyki. c i oprogramowania, a takie roz.woiu m,.tA,'h„ ”L ....... • W t\ m aspekcie godny podkreślenia jest wysiłekW spidnoty Europejskie, SVstemów informatycznych. Uznanie z v S v dw [ ‘T ” ™“ w celu StW stworzenia klon, nazwano EuroMcthod ¡'spiralny. W praktyce liniowy ,vp J k l u l ^ n s ^ n n i T “ ‘ ? w CClU U iz-cuici jednolitej metodyki N . . .. ...... .......... ............... k .- l - ,UVJ .— r j v,>mu /\c ta systemu dommuie zurowno ;e; szczegółami pracow ał zespół ekspertów- z państw c /k nkowskich. 2 espoj w podejściach strukturalnych, jak i obiektowych. W wielu propozycjach ten wywodzący się zarówno z instytucji badawczych, jak i organizacji cykl ten podzielony jest na różni, (od kilku do kilkunastu, liczby etapów gospodarczych i doradczych, brał pod uwagę podejścia metodyczne o /różnicowanych nazwach. wywodzące się z następujących krajów: Liczne opracowania i podręczniki powielają tradycyjny, liniowy, . Wielkiej Brytanii - SSADM tang. Structured Systems Analysis a>k „kaskadowy czy „ciężki model cyklu życia systemu, niekiedy o nieco % * * Design Method ). zmienionych sekwencjach etapów, zróżnicowanym zakresie i odmiennych • Francji - MERISE. terminologiach. M odyfikacje te wynikają z dążności dopasowania do • Włoch - DAFNE (ang. DAta ami Function NEtworkmg), celów i załozen konkretnego systemu bądź organizacji. Przyjęty proces , Holandii - SDM (ang. System Development Methodology), tworzenia pozwala na racjonalne kierowanie zespołem wykonawczym, Hiszpanii - MEIN (hiszp. MEthodologica INfonnatica). koordynowanie zadań zgodnie z przyjętym harmonogramem, kontrolowanie Niemiec —VORGEHENSMODEL. realizacji przyjętych założeń. Koniecznymi cechami modelu cyklu życia są Wielkiej Brytanii i USA - IE (ang. Information Engineering). jego zupełność i kompletność, oznaczające konieczność ścisłego opisu Powstała obszerna dokumentacja m etodyczna [o9: 100. s.260]. jej wszystkich etapów niezbędnych przy zaprojektowaniu, a następnie zastosowanie było ograniczane sprzecznymi, jak się okazało, interesami użytkowaniu elementów systemu: oprogramowania, sprzętu, podręczników, organizacji administracyjnych, gospodarczych i badaw czych. Aktualnie kadr i szkolenia. EuroMethod (nazwa zmieniona na ISPL - ang. Information Senia Każdy z etapów cyklu życia systemu powinien mieć ściśle określone Procurement Libra/y) służy jako narzędzie do realizacji przetargów na wejścia, wyjścia, składniki, tunkcje. dokumenty, sprzężenia z innymi duże projekty informatyczne, co przedstaw iono w podrozdz. 8.3. etapami. U zgodniony wynik prac na każdym etapie powinien być zatwierdzony, również w sposób formalny, przez zespół wykonawczy. Możliwe są oczywiście iteracje pomiędzy etapami, lecz ich nadmiar 1.3. Cykl życia systemu powoduje rozmycie granic między fazami. Może to utrudniać czy nawet uniemożliwiać kierowanie i kontrolowanie postępu prac. Przykładowy. tradycyjny, liniow'y cykl życia systemu przedstawia Współczesne systemy informatyczne w organizacjach gospodarczych są złożonymi całościami, obejmującymi obszerne dziedziny przedmiotowe. rys. 1.3 [73]. W praktyce jednak już w trakcie użytkowania systemu Wynika to z samej istoty systemu inform atycznego wiążącego ludzi, dokonywanych jest wiele czynności modyfikacyjnych, które oznaczają metody i środki techniczne w celu racjonalnego w ykonania złożeń. podejmowanie zadań z zakresu planowania, analizy i projektowania. Dlatego Jednocześnie użytkownicy skonstruow anego system u oczekują, że będzie autorzy [ 8 ] sugerują wyodrębnienie ścieżki tworzenia i cykli eksploatacji on sprawny, użyteczny, niezawodny oraz dostosow any do uprzednio Skonstruowany zgodnie z nią system podlega modyfikacjom i poszerzeniom zgłoszonych potrzeb informatycznych. Całość w spom nianych uwarunkowań w kolejnych cyklach eksploatacji. Rysunek 1.4 przedstawia sposób tworzenia stymuluje potrzebę skutecznego kierowania projektow aniem i użytkowaniem nowych wersji udoskonalonych systemów dla danej dziedziny przedmiotowej. W związku z opisaną różnorodnością cykli życia systemu trudno jest systemu. Działania te stanowią treść procesu, który określić można jako LykJ Żyt'ia systemu. Cykl ten jest ciągiem wyodrębnionych, wzajemnie zalecić jakiś standard (kanon), zarówno w sensie struktury, jak i terminologii, spójnych etapów, pozwalających na pełne i skuteczne zaprojektowanie, który posiadałby walor uniwersalnej akceptacji. Jednakże na podstawie analizy i uogólnienia wiedzy oraz doświadczenia z dziedziny tworzenia ^następnie użytkowanie systemu inform atycznego. systemów informatycznych cykl życia systemu można podzielić na pięc Mimo prób standaryzacji nie ustalono jednolitego w zorca —standardu piocesu tworzenia systemu inlormatycznego. Obecnie systemy informatyczne następujących podstaw ow ych faz: powstają „w rytm różnych cykli życia. Należy zaznaczyć, iż specyfik3 1) planowanie systemu, —
1^
Integracja 1
*
Rys. 1.3. Liniowy cyk! życia systemu (73J
Z L m l m systemu. 3j projektowana: systemu, 4) wdrażanie mysiemu, 5) użytkowanie. fflpdyfikacja ^j adaptacja^sy^fgy^ i .-_
.
Jnn>m popularnym wzorcem opisu cyklu życia system u jest modd spira n>, zaproponowany przez Boehm a [10; 4 3 J, a przedstawiony na
20
Dziedzina przedm iotowa
V
Analiza potrzeb
D efiniow anie założeń (
Ścieżka tworzenia
-
W P rojektow anie
-7 W drożenie W drożenie
C
Projektowanie
’<
y
v Definiowanie założeń
Akceptacja
Cykl eksploatacji 3 Eksploatacja
Analiza potrzeb
>
Ocena
1
Rys. 1.4. Proces i SI a cykl eksploatacji [8|
rys. 1.5. Poszczególne fazy cyklu życia realizowane są spiralnie, co oznacza ich powtarzanie, w celu doskonalenia kolejnych wersji systemu, będących rezultatem doświadczeń zdobytych w trakcie użytkowania systemu. W tym sensie model spiralny zbliżony jest do prototypowania systemu, scharakteryzowanego niżej. W pierwszej f azie opracowany jest plan systemu jnibrmalycznego o zakresie zgodnym z infoplanem omówionym w' rozdziale II. A naliza ryzyka polega na ocenie finansowych i organizacyjnych konsekwencji zaprojektowania, analizy i wdrożenia infoplanu. Analiza
21
ANALIZA RYZYKA
PLANOWANIE
Analiza ryzyka oparta na wstępnych wymaganiach^ A naliza ryzyka oparta na reakcji u żytkow nika
Wstępne wymagania i planowanie projektu
Kontynuować czy nie? -V
Gotowy system Weryfikacje dokonywane przez użytkownika
W stę p n y prototyp K olejny prototyp S konstruow any system
KONSTRUOWANIE
WERYFIKACJA
Rys. 1.5. Spiralny model cyklu życia systemu 110; 4 3 1
ryzyka, przeprowadzona z perspektywy zarówno twórcy systemu, jak i użytkownika, pozwala na ocenę stopnia zagrożenia realizacji projektu ze względu na niemożność wdrożenia przyjętych założeń system u wskutek ograniczeń wielkości będących do dyspozycji zasobów finansowych, kadrowych, sprzętowych i programistycznych. W trakcie cyklu życia systemu zmienia się charakter prac planistycznych, analitycznych i projektowych, co wyraża się w brzm ieniu i znaczeniu pytań, na które twórcy systemów winni odpowiedzieć. Zm iany te ilustruje rys. 1.6 [56J. Istota problemów w kolejnych fazach sprow adza się do odpowiedzi na następujące pytania: • DLACZEGO? (Zasadność tworzenia systemu; punkt widzenia kierow nictwa firmy; ocena niezbędnych zasobów.) • CO?.(.Opis modelu danych i procesów.) • JAK? (Wdrożenie modelu; organizacja plików'; kodow anie.) • CZO M ! (Zainstalowanie i użytkowanie dobranego sprzętu i oprog ramowania.) Znaczenie poszczególnych pytań zmienia się wraz z umiejscowieniem ich w cyklu życia. Rolą strategicznego pytania DLACZEGO? maleje w kolejnych Lt/ach, podczas gdy waga pytania CZYKf?T zwjąsflnągn i wdrażaniem i użytkowaniem systemu rośnie, wypełniając .niem al łieść tworzenia systemu w końcowych fazach cyklu. Podobną ewolucję przechodzą pytania CO? i JAK? kVIi*
22
a)
b) CO ?
Metodyki tworzenia systemów informatycznych
JAK ?
Metody i techniki
Rys m 1.6. Problemy w cyklu życiu systemu |56J
W każdej fazie cyklu życia systemu określa sic:
• cele, •^działania, • kolejność realizowanych działań. • punkty przeglądu, • produkty i ich dokumentację. li
Metody określania strategicznych celów systemu inlormatycznego scharakteryzowano w rozdz. 2 w związku z tematyką planowania - mają one zastosowanie w kolejnych etapach procesu TSI. Każdy z etapów składa się z wielu działań, realizowanych w określonej sekwencji. W celu ujęcia występujących między nimi zależności bardzo często wykorzystuje się metody sieciowe. Choć treść merytoryczna działań w ramach kolejnych faz jest zróżnicowana, to niektóre spośród nich muszą być realizowane w każdej fazie - mają one charakter pow tarzalny. Oznaczając numer fazy przez ,v, powtarzalne działania określimy następująco. • ,v.J - opracowanie planu realizacji fazy, •••
• x.k - ocena wpływu tworzonego systemu informatycznego na funkc jonowanie organizacji, •••
• A./7—2 - ocena dotychczasowego stopnia wykonania planu, • x/7_i _ opracowanie planu dalszego tworzenia systemu, • x.n - kompilacja dokumentacji i przygotowanie raportu końcowego. Niektóre z tych działań w ramach każdej fazy mają charakter oceniająco-kontrolny - są punktam i przeglądu (ang. milestones). W tym miejscu zespól projektowy lub kierownictwo firmy m ogą podjąć de cyzję o dalszym kontynuowaniu projektu lub jeg o przerwaniu (ang. go/no go decision ), w zależności od oceny możliwości powodzenia. Rezultatem realizacji całego cyklu jest pow stająca w jego trakcie elektroniczna i papierowa dokum entacja system u. Interesującą, a jednocześnie ważką kw estią dla twórców systemów jest zagadnienie czasochłonności i kosztochłonności cyklu życia systemu. Szczegółowa analiza w tej kwestii leży zresztą u podstaw krytyki tradycyjnego cyklu, którego główne założenia polegają na tym. że: na początku każdego projektu ustala się stabilny zestaw potrzeb, potrzeby te mogą być zarejestrowane jako niesprzeczne i spójne, potrzeby nie zmieniają się w trakcie cyklu życia systemu. Większość tych założeń nie spraw dza się je d n a k w praktyce. Użytkownicy bowiem nie mają na wstępie sprecyzow anych potrzeb, ich specyfikacje nie są spójne, w związku z czym występują nieporozu mienia między użytkownikami a informatykami, a w konsekwencji częste zmiany systemów. Zarówno czas tworzenia systemu, jak i jego jakość są uzależnione od poprawności i zupełności etapów w stępnych, związanych z planowaniem., analizą i projektowaniem systemów. Błędy popełnione w tych fazach są zwielokrotnione czasowo i kosztow o w stadium pioje towania „lizycznego ’ bądź w trakcie wdrażania. Ilustracją tej konstatacji jest rys. 1.7 [9()J, nawiązujący do rys. 1.4.
wprowadzania zmian Czas
Rys. 1.7. Cykl życia a koszty wprowadzania zmian [90]
Dokładniejszą ilościową charakterystykę tych zależności przedsta wiono m.in. w | 8 ; 98]. Syntezę tych zależności przedstawia rys. 1.8 (sti. 26). Okazuje się, że większość nakładów pracy wykonawców i użytkowników systemu oraz nakładów na sprzęt jest związana z eksplo atacją systemu, w tym przede wszystkim z poprawą błędów, adaptacją i udoskonalaniem programów. Większość błędów (56%) jest popeł niana w trakcie analizy. Najkosztowniejsza korekta (82%) jest zwią zana z tą właśnie lazą. Poważny wysiłek naukow'o-badawczy powinien być skierowany na doskonalenie metod i technik analizy potrzeb. Jest to ważne wyzwanie w dziedzinie metodyk tworzenia systemów infor matycznych.
1.4. Modyfikacje tradycyjnego cyklu życia systemu 1.4.1. Kierunki modyfikacji Analiza teoretycznych przesłanek oraz zasad użytkowania metodyk TSI prowadzi do wniosku, iż znaczące ich unowocześnienie nastąpiło w m om encie pojaw ienia się narzędzi czwartej generacji, zwłaszcza generatorów zastosowań oraz prototypowania. Wówczas, tzn. na początku lat osiemdziesiątych, pojawiła się istotna jakościowa zmiana w podejściu do cyklu życia systemu, wynikająca zresztą z wcześniejszych negatywnych doświadczeń w projektowaniu, a przede wszystkim użytkowaniu systemów Choć stw orzenie narzędzi czwartej generacji stało się zasadniczym przełomem, nie oznacza to, iż inne, tradycyjne strategie cyklu LSI nie znajdują ju ż zastosowania.
25
„ NatUad pn,cy w cyklu lwur,cn,a systemu Eksploatacja 67%
•\ V# V %• • • 5 v .y PrOjeKtoworie *'% specy^ Kacja
Testowanie 15%
KOdOW.miO TO
»analna potrzeb 6% b) Źródła błędów Analiza potrzeb 56
w .v .w .w .v *•v•*• v• .•••••••%••••••> • ••• • • »0#0•0•0 • . • • • • • - 0*9♦0' • /» # * V v
Kodowante 7%
‘«* 1*t * • ***** *
Proiektowame 27%
Inne 10%
c) Koszty popraw iania błędów Analiza potrzeb 82°,•
Projektowanie 13% Inne 4%
^odo^ame 1% Kn\ IX kos/iocitlonnos, i prai«łiK»nnt»t: pos/c/ogOlnych tuz. cyklu /yci.i w stornu |98|
Pełna realizacja cyklu życia systemu za pom ocą tradycyjnych metod) wiąże się / następującymi p ro b lem am i rzutującym i na ich użyteczność: • mija długi okres, zanim użytkow nik zrozum ie cechy i założę'1 konstruowanego systemu, • czas pomiędzy specyfikacją systemu a teslami jest rów nież długi,
. iv/ultuiN dyskusji użNtkownik projektant pojawiaj;» się najwcześniej po powinni v asie, i to pod warunkiem, ze współpraca przebiega sprawnie, • v\ki \ u a snsienni, a zwłaszcza programowanie i testowanie. wi;»ze sie / w \ soktnu kosztami. • v ęsto w\stępuj.» pi/spadki rozminięcia sie tunkcji faktvc/nie realizowanych pi c s\ su m i \ ckiwamaim w ymżony nu w lazach planówania i analizy. I o w \ s / c sposuzczcnia legły u podst.nv zmian, udoskonaleń, nowych wzorcow tpat. u I n gmatow l projektówatua SI. do ktoiNch należą: • geneiatory zastosowań.
• pakiety zastosowań. • prototypowanie. I doskonalenia to IS 1 pi/odstawiono na
określeniem rodzaju ich wplvNvu na proces 1.0 |o7, s. 85|.
nni.iz z ins
•% Metodyczne podejście do projektowaniu
Generatory zastosowań
Pakiety zastosowań
Prototypowanie I
Ograniczenie
programowanie SKrOceme czasu tworzenie Zapewnienie bieZijcego sprzężenia zwrotnogo
System wynikowy K\, l ') \lo>Mik.u |c niiKCMi ISI (07. s SS|
Należy jednak również wspomnieć o specyficznej metodzie tworzenia małych, aczkolwiek użytecznych systemów informatycznych, często o charakterze osobistym. Rozwój przyjaznego wobec użytkownika opro gramowania narzędziowego mikrokomputerów, a także pt osty cli nn użył kowaniu narzędzi czwartej generacji, umożliwia użytkownikom pode jmowanie prób tworzenia własnych zastosowań. Naturalnie zaktes tych systemów jest ograniczony. Można jednak opracować wiele użytecznych systemów, korzystających z dostępnych arkuszy elektronicznych czy mikrokomputerowych baz danych. 27
niezbędne jest wykonanie spóinei ,tr»Un i • łożeń. G enerator może wspomimać tu n r ‘ cncj analizy i projektu /a typowanie. Generatory tego tvpu nioei Specyhkac-i1 Poprzez proto. wvróżnu> siy .r/y W p o t o o w , tSw zastosowań * > u yy klasie generator. ^ WYszukiwai»ic danych i edyęjj lub generować kody (kompilatory lub uans 1 r v ^ 10kR flperaliai* \ ftlitrt ; # j ? /yki zap. •■ ^ /astosowan i jv > / a r ń w n 0 m ałych, na bieżące r * r r — &*** •► trii y i t Y V Z P V V r* ^ .W. V .r. s S il SWi > * l'rurk $ „- - A f - y J ------' -U J łS H rc W ■. tí * * M .M # N \ laSC’7 one zalety przy ^ / ^ ^ o w a i i dla w cześniej założonycl, , Ir A í ;^0 »r,<9 r«> [ H f curd T f i' ; » l u l Wykazują . jak i n o w y c h / niu /ło ż o n y c h systemów *r- * 'r — D Nêfcé M ^ l»4 1 »Pik Ci»4 r • 1 s ti i «i k / 4. v s,osowan>y. a r ' ^ d; aksU utcc/ne P « y 1 . xvvko„ Vs u m h i w . * »i ^ Tí 11i •* A »* p1^ ' f kvt^Vi * *••• ’«'k • . u ,/ i y,L ¿ ’ ; ííi» < *i«<* ' i t : / t#4l : , I SMéUèle 15» *.1 ; * -* v - f B B j 5 * i. 4 tTS Wt A K I l K h 1 . • ... I* [, d*r . ï|tîiVi ïibf yySpfef2ÍM&r >4^ A] * ^Í.'V* , V| „ u k t a n i u danych ze z b i o r o w •;^ mi;l, u ; y w aja różni p ro G .es,„nahici c,' eraur »la 5fr v yJ f *-.v. v-,r>-\ •- VV' r > a JO 9 to ( p « | i ' t r h 1. - l 1 vanvch czcs.o jcvykan « ‘ hy s /k o lc n ia s,y w językact IP # $ •; ' i I I l v i t on U p
,.4.2. Generatory zastosowań
Ł ) ; « I * » o m !' m T h eeneratorów . łatw y ch w u ży tk ó w « « L i n i o w a n i a . Zas.osowanK .. , 0 h e , pośrednim dostęp, rozszerzyło sic odpowicdn.o d z n . ^ /C)ilawieŃ zapew nia elastyczne*. onli l w danych. \ s /y b k ic reag o w an ie w spehuan«
z lá iít e iilA w
l l i i í;^': C rrJle
Rys
_Câ»cf i
.
1.10. M enu generatora /asti^sowań M A G IC ’
w tworzeniu W , yesiawienia. G eneratory te s a baidz.o uzyteunt zapotrzebowania na nowe / - * danych. bazam i (k |n y fh , SZ B D ) stosuj, m i M p y , a ń. Ich użytków,ul
aiz.
i
ości ^ . tlv, ust posiadać w'ieazę o zaw ai iu .s l i i »strukturze u u m u im hazy ..,. w dwan y ch o r a..r „v, istosowania. Języki te skonstruowano również /. m yślą o nieinformatykaeh ÇUV VN U /Y lM 'V V aiilU jy^yi\v»vł ..... . . . iążą w £. . t •się• T -z w tędy w użytkowaniu języków zapytań w niewłaściwym imiułowaniem zapytań bądź brakiem danych danych w w bazie. Przykładam: »rmułowanieni zapytań bądź brakiem bazie. Przykładam --■» i — ™ icd\ :yków zapytań są SQI. (ang. Structured Query Latiguage) czy QUER\ i EXAMPLE. Dominuje język SQL, w który w y p o sażo n a je st większość inercyjnie dostępnych systemów baz danych. Właściwe generatory zastosow ań służą do: definiowania transakcji wejściowych, prowadzenia dialogu. __ tworzenią ba/.y danych* aktualizacji plików. tłJ K i generowania zestawień;- • \ przetwarzania zapytań. -r. ;
" ‘^ b ę d n y do wdrożenia. su te m u , d/.ięki oszczędności czasu na pmjektow anie i wysiłku zw iązanego z oprogramowaniem. Dobór pakietu uzależniony jest od specyfiki potrzeb użytkownika i dziedziny przedmiotowej. Porównanie potrzeb zawartych w infoplanie z cechami pakietu oprogramowania (rys. 1.11) prowadzi do opracowania planu jego wdrożenia. Jak wynika z rys. 1.12 pewne obszary' dziedziny przedmiotowej W' danej organizacji gospodarczej nie są objęte zakresem działania pakietu. a pewne funkcje pakietu mogą nie być użytkowane - nie dotyczą bowiem wyspecyfikowanych potrzeb informatycznych. Oceny pakietów zastosowań nie są jednoznaczne, gdyż mają one swoje wady i zalety. Do ich cech pozytyw nych należą: • krótszy czas na tworzenie systemu, przy czym zbędna jest dokładna Wi^szosć generatorów zastosowań jest konstruowana wokół określony^ "specyfikacja programistyczna. >i latają oik znacznie czas program ow ani» i testow ania w cykł® • niższe koszty, mimo dodatkowych kosztów' modyfikacji ulepszonych wersji. tniu t n ikiutory nie autom atyzują procesu projektowania* 2*í w
• • • • • •
/v
Pakiety zastosow ań zaw ierają oprogramowanie określonej dziedzins (wycinka działalności gospodarczej czy administracyjnej), całkowicie lub częściowo gotow e do wdrożeniu. Pakiety zawsze obejmują oprogramowanie, a Opcyjnie rów nież i sprzęt. Ich zastosowanie zdecydowanie redukuje czas ■ «/ -
przy sporządzaniu ■w większości systemów
1.4.3. Pakiety zastosowań
^
Otoczenie organizacji
Podstawowe wady i niedogodności wykorzystywania pakietów do tworzenia system polegają na tym, że: • pakiet może nie obejmować wszystkich pożądanych funkcji, . wiele pakietów trzeba modyfikować przed wdrożeniem, co może powiększać koszty (wprowadzanie i korekta dodatkowych błędów >. • modyfikacji w pakiecie można uniknąć jedynie poprzez zmianę realizacji określonych funkcji w przedsiębiorstwie, • powstaje duża zależność od dostawcy oprogramowania, od jego solidności i term inow ości aktualizacji kolejnych wersji pakietu. • istniejący w przedsiębiorstwie sprzęt bądź plan rozwoju komputeryzacji może nie być zgodny z wymaganiami sprzętowymi pakietu. Istnieją cztery strategie konstruowania pakietu zastosowań dla określonej dziedziny przedmiotowej:
• skonstruowanie pakietu z wieloma parametrami lub tablicami - użytkownik dobiera dogodne parametry, • adaptacja różnych modułów' do specyficznych problemów i sytuacji. • oczekiwanie, że organizacja zmieni sposób funkcjonowania, aby móc stosować pakiet, • stworzenie pakietu dla konkretnej dziedziny przedmiotowej i modyfikacja do w ym agań każdego użytkownika z wykorzystaniem np. elastycznego generatora zestawień. Dowolną kom binację tych strategii bądź każdą z nich można stosować Rys. I .l l . Konfrontacja potrzeb informatycznych i cech pakietu zastosowań w odniesieniu do dow olnego pakietu. W iększość pakietów zastosowań podlega procesow i ciągłego modyfikowania. W latach osiemdziesiątych oferow ano na polskim rynku w iele pakietów Dziedzina przedm iotow a | (działalność g o spo da rcza) zastosowań wspomagających komputerowo różne dziedziny funkcjonowania przedsiębiorstwa, jak: techniczne przygotowanie produkcji, planowanie produkcji, gospodarka środkami trwałymi, gospodarka materiałowa, zarządzanie kadrami, płace, gospodarka wyrobami gotowymi i sprzedaż, gospodarka finansowo-księgowa. Pakiety te najczęściej miały charakter cząstkowy. Są one nadal użytkowane z powodzeniem w wielu małych i średnich organizacjach gospodarczych i administracyjnych. Obecnie na rynek wprowadzane są zintegrow ane pakiety obejmujące programy, Rys. 1.12. Dziedzina przedmiotowa i pakiet zastosowań I imsiuly I funkcje pakietu /n-ioMUMfi wdru/une bezpośrednio dla wsjKiiruj;anu dziul.dnoici jfosp.xlaazcj; 2 - proceły go^wdotO dotyczące w%ajempje powiązanych procesów gospodarczych, wspomagane .«l>jni/juji jfoipulart/cj ulepszone d/ięk. fuudulnm i funkcjom pakietu /astiw w an . z • m.njuly t funkcje pakietu a u sie ru * * W bazą danych i pakiełamj ęĄ ftĘ. Przykładami takich pakietów zintegrowanych, zmienione pize/ dostawce pakietu zastosowań dla dostosowania do wymogów uzMkowmka. 4 - moduły i funkcje pakietu, klore w M użytkowane. S pręce») «ospodaaze w danej organtzasji. n.e objęte |dzidnie (*» zwanych M RP II (ang. Material Requirements Planning), a obecnie ERP pr/triUivhtorsłwti. sk n m p u lm /tm an c w sponib zadowalający. (ang. Enterprise Resources Planning), są: MAX, BAAN 11 czy R.3 niemieckiej firmy SAP. W spółczesne pakiety zintegrowane są kos/tow ne. większa liczba funkcji lub dodatkow ych cech niż wynikałoby to ® skomplikowane, wymagają zaawansowanego sprzętu inłormatycznego, toteż instalują je przede wszystkim duże, efektywne firmy. Pakiety klasy PKP specyfiki konkretnej dziedziny przedm iotow ej, cechują się specyficznym sposobem wdrażania. Zagadnienie to wykruc/a • możliwość w ielokrotnego użytkowania pakietu.
ooza zakres niniejszego opracowania, jednak warto zaznaczyć, ze opJsa, tu n teM v . techniki i narzędzia są przydatne do m odelow an.a Procesóv i prototypowania, tak ważnych w systemach ERP.
1.4.4.
P r o t o t y p o w a n ie
W tradycyjnym podejściu do TSI analityk lub projektant są specjalis tami. którzy za pomocą kwestionariuszy i w yw iadów z użytkownika*, dochodzą do precyzyjnego opisu dziedziny przedm iotow ej i zdefiniowani p o trz e b informatycznych firmy. Zarówno procedura kom unikow ania sit jak i złożoność analizowanego wycinka rzeczywistości pow odują, iż te etap TSI bardzo się wydłuża. Powstaje ..martwy okres oczekiw ania n konkretne rezultaty - wstępną eksploatację systemu. M ożna ten okre znacznie skrócić, włączając użytkownika w proces TSI. dzięki proto typowaniu systemu tang. System Prototyping lub RA D - R apid Aplicatioi
Development). Prototyp jest ogólnym modelem przyszłego system u informatycznegc który w kolejnych iteracjach je st udoskonalany aż do osiągnięci akceptowanego stopnia szczegółowości. W aspekcie tw orzenia systemó\ informatycznych można wyodrębnić trzy rodzaje prototypów [42, s. 6 ]: • prototypy eksploracyjne, ukierunkow ane na d e fin io w a n ie potrzeużytkownika, struktury systemu oraz na porów nyw anie różnych wariantov rozwiązań. • prototypy eksperym entalne, których celem jest określenie adekwatność proponowanych rozwiązań przed w drożeniem now ego system u. • prototypy ewolucyjne, które pozw alają na ocenienie w pływ u, jaki ii inne składniki systemu mają zmiany w prow adzane w specyfikacjad systemowych. I roces prototypow ania, ukierunkow any na zapew nienie szybkieg, sprzężenia zwrotnego pomiędzy analitykiem lub p rojektantem a użytków nikiem, jest sekwencją następujących kroków: D analityk lub projektant przeprowadzają w yw iad z użytkow nikiem , 2) użytkownik opisuje dziedzinę przedm iotow ą, 3) analityk lub projektant tworzą prototyp przyszłego system u, 4) użytkownik testuje prototyp i ocenia go, ^
^r(^ e^ lanf modyfikują prototyp, począw szy od czynności l
ój użytkownik aprobuje ostatecznie prototyp. in s tr u o w a n ia prototypu w ujęciu ew olucyjnym [7 3 , s. 31« rolę wicxlacT’J d n ? 5’’ ! v ' b o d ą c ą pełni użytkownik systemu.
Paradygmatem TSI, w który®
Ogólny zakres, opis dziedziny przedmiotowej przez użytkownika
Rys. 1.13. Cykl tworzenia systemu w warunkach prototypowania {73, s. 318)
W mniej złożonych przypadkach prototyp można rozwinąć poprzez kolejne iteracje w użytkow y system informatyczny. Bardziej skomplikowana dziedzina przedm iotow a wymaga jednak opracowania precyzyjniejszych specyfikacji systemowych, co często powoduje rozpoczęcia realizacji tradycyjnego cyklu życia systemu. Z prototypowaniem związana jest metoda analizy sytuacyjnej (porównaj podrozdz. 2.5) JAD. (ang. Joint Application Development). Skrótem tym oznaczone są organizacyjnie uporządkowane warsztaty, w których biorą udział wszystkie osoby zaangażowane w informatyzację firmy, w tym kierownictwo i użytkownicy. Przed rozpoczęciem sesji JAD (czasem kilkudniowej) ściśle określa się jej cel oraz oczekiwane wyniki (produkty , wyjścia). W arsztaty JA D prowadzone są przez moderatora z wykorzystanie m nowoczesnych środków audiowizualnych i innych metod wspomagających
P y t a n ia i
problemy
Lhutmki metodvki TSI I zależności między nutu' Zinterpretuj rys ! | J Jakie są ; r i r i w O " « e m u ,nfom »tyc7neSo tuP ob«l»*> rachunku» W efcw c,. ■' m chwharakle^roj delimc.K " « em u m fon rn m .™ *,, » » » m i praklęcene ,„ a„ Wlt elem entu» "«.em u o n . p . « . . « * ■»«■**.' mm,, i L] a s \ f l k . K I t m e t o d s k TSI 1SI 3 Podaj krvtena klasyfikaej. metodyk 4 O vtti różnią s * m etry ki strukturalne, obiektowe i społeczne 5 P.vlai przykładv komercyjnie dostępnych metodyk, uwzględniając ro/ne kryteria lch
klasvilkacji'*
. i i
f, Na noJsiauie r\x 1.2 spn'*x>) opracować propozycję metodyki twor/eniu system y inform atycznych u w z g l ę d n i a n e j aktualny stan wiedzy Zastanów się. które / elem enty m
a a
a
^
a
* «a aa A
tej propozycji są spójne, a które mogą być sprzeczne 7 O ceń propozycję E uroM etho d
8 Co to iev* evkl zvcia systemu ’ Podaj jego przykłady Dlaczego istntc)e duza różnorodność cykli rycia systemu 9 Ścic/ka tu-ikrzenia a cykl ckspltwticji —pinlohicnstuii, różnice, wzajemne /»ile/nośo 10 Pice podstawowych la/ cyklu życia systemu, ich kolejność i istota. 11. a .U spiralny i I Liniowy* U MUUIU cyk! W życia systemu. V --12 Na czym poleca analiza ryzyka w spiralnym modelu cyklu życia system u Spróbuj zilustrować na wybranym przez Ciebie . * r-------------- x przykładzie. j 13. Cvkl żvcia systemu a zmienność pvtań Dlaczego? Co? Jak? C zym ? 14. Znaczenie punktu pr/eglądu w realizacji każde| / faz cyklu /y c ia systemu. 15. Jakie implikacje praktyczne wynikają / zale/nosci m ięd /y cyklem życia systemu a kasztami wprowadzania zmian przedstawionej na rys 1.7 i ! 8? 16 Jakie '4 przyczyny modyfikacji liniowego cyklu życia systemu *> 17. Wymień podstawowe wzorce modyfikacji. Czym różnią się. jakie dają korzy SCi? 18. Kategorie generatorów zastosowali. V
w
^
m
19. Spróbuj opracować listę i charaktery styki ¿iktualnych w tej chwili generatorów zastosować popularnych w Polsce Wykorzystaj w tym celu ostatnie numery „Computerworld" ^ i ..P( Ku, rera . a lakze dostępne katalogi oprogramowania, np z targów informatycznych 20 Pakiet zastosowań konfrontacja potrzeb informatycznych i cech pakietu. 2i. Zalety i wady pakietów zastosowań Wykorzystując podane w pytaniu 18 żrodla, dokonaj przeglądu dostępnych na rynku polskim zintegrowanych pakietów zastosowań klasy ERP *"3‘ Jak,e znac“ ®“ m‘lM mftod>kl- techniki i narzędzia m etodycznego TSI dla wdrażam* pakietów ERP? w zór/*11 ^°*ef J pr° ,0t>P— wzorzec (paradygmat) TSI?
s>Nteniow
25. Rodzaje prototypów a proces prototypowania.
Dlaczego jest to
popularny i zalecany
Rozdział 2
Planowanie systemów informatycznych
2.1. Cele planowania systemów informatycznych P ierw s/ą lazą cyklu życia systemów inlormatyc/.nych jest planowanie, zwane również w literaturze przedmiotu strategicznym planowaniem systemu. Faza planow ania jest realizow ana w odniesieniu do dużych projektów dla złożonych dziedzin przedm iotowych. Samo zadanie planowania jest z natury skom plikow ane, interdyscyplinarne. W ym aga obszernej wiedzy nie tylko inform atycznej, ale i / zakresu zagadnień ekonom icznych oraz zarządzania firmą. Przedm iotem zainteresow ania w tej fazie są m.in.: misja gospodarcza firmy, jej cele. biznesplan, otoczenie, konkurencja. Złożoność fazy planowania systemu w ynika z konieczności zharm onizow ania zagadnień gospodarczych / aktualnym i trendam i rozw oju technologii i systemów informatycznych w celu skutecznego, podnoszącego konkurencyjność firmy wspomagania jej funkcjonowania. Poza specjalistami-informatykami w procesie planowania uczestniczy kierow nictw o firmy, rozumiejące najlepiej istotę jej funk cjonowania. Zespół projektow y stosuje metody i techniki heurystyczne, stymulujące generow anie tw órczych rozwiązań, a następnie ich dokum en towanie. Tak więc, założeniem realizacji fazy planowania systemów jest osiągnięcie dwu celów; • stworzenie systemu informatycznego skutecznie wspomagającego strate giczne cele firmy, • zaangażowanie kierownictwa firmy w proces planowania i projektowania, ą następnie użytkow ania systemu informatycznego. Planowanie systemu informatycznego wymaga identyfikacji i nadania priorytetów tym technologiom i zastosowaniom , które najbardziej wspomagają m isję i cele danej organizacji. Planowanie SI inicjowane jest na podstaw ie rezultatów i ocen użytkowania istniejących systemów. W związku z wysokim obecnie stopniem informatyzacji zarówno gospodarki, jak i administracji, czynność planowania rzadziej dotyczy systemów nowych,
35
tworzonych od podstaw. W ^ e n ^ c z y decyzje kierow nkpj! regularnie powtarzanym, s. . ’ , Ta funkcja kontroln' oraz czynniki me wymagają^zmiany J . Jynmki zewnętrzne mc . r1 winna być wykonywana periodycznie. Cechą j ^ systemów informatycznych od innych ^ fiyWu . f J ‘ictwo firm v ^ ..¡ a/iaaa oh/»imnip on analitykow-planistów, ki y or
Zaplanowanie architektury systemu informatycznego polega na określeniu zas° danych’ rodzaJu zas^so w ań , sieci komputerowej i infrastruktury technicznej w aspeKcie aspekcie procesow procesów gospodarczych danej organizacji, organizacji. Podstawowym sposobem definiowania architektury są macierzowe z a le to ¡śd pomiędzy zasobami danych, funkcjami, komórkami organizacyjnymi, ,/actncnwnniami • •_ , * «.
się analitykom-planistom. i oza i .. . nazywa się również strategicznym bądź głównym planem informatyzacj miotowej, powinni oni posiadać wiedzę z zakresu organizacji i zarządzania ,ub po prostu infoplanem . analizy i projektowania systemów, a także na tem at sprzętu siec O statnią czynnością w fazie planowania jest identyfikacja i ocena k o m p u te r o w y c h d an y ch . Ponieważ trudno sprostać ' em u spektruit obszarów zastosow ań, wynikająca z architektury systemu. Jej celem jest kompetencyjnemu, analitycy-plamści często w spółpracują z e spertami integracja poszczególnych składników systemu w spójną całość, wspomąszczególnie z zakresu sprzętu, sieci oraz baz danych. gającą misję gospodarczą w aspekcie: o
r
a
z
b
a
z
2.2. Proces plenowanis systemu informatycznego
• procesów gospodarczych i powiązań między nimi, • bazy danych, « sjeci kom puterow ej,
• sprzętu i oprogram owania. Proces planowania w ujęciu autoiów piacy [ 105J składa się z trzeci Przeglądu i oceny obszarów zastosowań dokonuje się na podstawie kolejnych etapów: kryteriów jakości i wykonalności. 1) studium misji gospodarczej, 2 ) określenia architektury systemu, 3) identyfikacji i oceny obszarów zastosow ań. 2.3. Formułowanie strategiiinformatyzacji Pierwszy etap związany jest z analizą i oceną procesów gospodarczych (infoplanu) danej organizacji gospodarczej, a więc takich zagadnień, ja k misji gospodarcza, plan strategiczny firmy czy biznesplan. R ozpatryw ane są ont A utorzy metodologii formułowania strategii informatyzacji organizacji jednak pod kątem przyszłego systemu inform atycznego firm y, który rai gospodarczych i administracyjnych preferują podejście sytuacyjne. Cechuje być tworzony w dalszych etapach cyklu życia system u. W ejściem do się ono uzależnieniem zakresu i treści planu strategicznego informatyzacji pierwszego etapu jest, sform ułow ana zazw yczaj ju ż uprzednio, misjo firmy, czyli infoplanu, od specyfiki działalności firmy, kontekstu technofirmy, będąca gospodarczym uzasadnieniem istnienia firm y. Z aś wyjściem logicznego, stylu zarządzania i struktury organizacyjnej. Pewną syntezą tego etapu jest biznesplan, czyli plan funkcjonow ania firm y w kategoriach podejść sytuacyjnych jest propozycja Earla, przedstawiona na rys. 2.1 (35, jej misji, celów i ograniczeń, zadań, istotnych czynników powodzenia, s. 71]. W trakcie form ułow ania infoplanu należy według niego uwzględniać, klientów, dostawców, konkurencji, w yrobów i usług, kadr, struktur) analizow ać i określać następujące trzy grupy zagadnień: organizacyjnej, materiałów i innych czynników . T o też na tym etapie • w yrażenie potrzeb, celów i strategii gospodarczej tirmy w kategoriach szczególnie niezbędne jest zaangażow anie k ierow nictw a firm y w prace w spom agających system ów informatycznych, zespołu planistycznego. Podstawowe zadania wykonywane w trakcie studium • ocenę aktualnie użytkow anego w firmie systemu informatycznego, misji gospodarczej polegają ną: • włączenie now ych, innow acyjnych rozwiązań z dziedziny technologii
• analizie istotnych czynników powodzenia (^mówionej niżej wśród innych informatycznej. metod planowania systemów informatycznych), M etodologia form ułow ania infoplanu jest wielostronna i złożona, • analizie konkurencji “ — ’ • od .badania różnych — u ........ a—rozpoczyna się zjawisk gospodarczych i rozwii zwiększenia w a rto fc i /an g . value chain analysis) wyrobu lub -.technologicznych. Trzy podstaw <;yklu produkcyjnym.. i twórczy przebiegają rów nolegle 36
^7
Użytkowane systemy
Cele i plany g o sp o d a rc z e
ł
Możliwości technologii informatycznej
Analityczny
Oceniający
Twórczy
Metodologia
Badania i oceny
Techniki, procesy
Praca zespołowa
Użytkownicy i specjaliści
*r Plan informatyzacji ( INFOPLAN )
V
Otoczenie
Rys. 2.1. Formułowanie strategii informatyzacji |35, s. 71]
Zróżnicowany jest również k ieru n ek realizacji każdego z procesów a więc odpowiednio: zstępujący (ang. top-down ), wstępujący (ang. bottom-ą i rozprzestrzeniający (ang. inside-out). Każdy z procesów je s t niezbędm lecz niewystarczający do opracow ania pełnego, spójnego strategicznegi planu informatyzacji. W łącznym procesie form ułow ania infoplanu bion udział różne grupy zawodowe: od kierow nictw a firm y p o p rz e z jej informatyczne i użytkowników system ów do konsultantów i zewnętrznych. W noszą oni różne rodzaje wiedzy do zadania ekonomiczną (finansową, księgową, m arketingow ą), m en ed żersk ą matyczną. pierwszego procesu (analitycznego) je s t id e n ty fik a c ja piano? i celów gospodarczych. Na tej podstaw ie definiow ane sa w spomagające ję potrzeby informatyczne, przy użyciu sformalizowanej m etodologii o charak terze analitycznym. W realizacji tego procesu w spółuczestniczą kierownic)
szcz^la^.s^tegicznęgOj^aJktycznego i operacyjnego przy udziale kierówjactwa s h iż b .in £ ę ^ t^ ^ y c h . O jólnie proces ten polega na przeprowadzeniu zstępującej procedury tra n sfo rm a c ji, „tłum aczenia” działalności gospodarczej na s y s te m y jje c g n o lp p f inform atyczną. T w orzone w ten sposób 'nformatyczne w spom agają działalność gospodarczą firmyziałul»ość ta powinna być opisana w postaci zestawu celów gospodarczych iznesp anów czy gospodarczych planów strategicznych. C zęsto należy je
sform ułować od podstaw, gdyż są niespójne, źle opracowane czy wręcz nie istnieją. N aw et jeśli zostały opracowane, mogą być nieadekwatne do procesu generow ania potrzeb informatycznych. Istnieje w iele m etod pozw alających na identyfikację systemów informatycznych wspomagających misję i cele gospodarcze firmy. Generalnie podejście takie pow inno być: • skuteczne w opisie celów, planów i strategii gospodarczych, • m ało czaso- i zasobochłonne, • pow tarzalne wraz ze zmianą strategii i innych warunków otoczenia gospodarczego, • w skazujące na kierunkowe potrzeby informatyczne, a nie na szczegółowe specyfikacje. W alory te m a najczęściej stosowana w tym celu, opracowana przez C. Bullena i J. Rockarta [12] metoda Istotnych Czynników Powodzenia (ang. Critical Success Factors - CSF). Z m iana dotychczasow ego systemu informatycznego wymaga również opisu, zro zu m ien ia i oceny istniejących systemów, jako punktu wyjścia do dalszych decyzji i prac. Jest to druga równoległa ścieżka dochodzenia do planu inform atyzacji. System informatyczny firmy ma formę albo zintegrowanej całości, albo zestawu systemów cząstkowych, wspomagających wycinki działalności organizacji gospodarczej lub administracyjnej. Ten drugi przypadek w ystępuje częściej, ze względu na szybki rozwój sprzętu i oprogram ow ania. W wyniku opisania funkcjonującego systemu, kierow nictwo uzyskuje sw oistą „m apę terytorium ” , rozpoznaje wady i zalety użytkow anego system u przed rozpoczęciem fazy definiowania infoplanu. O becnie coraz rzadziej tw orzy się system od początku (poza nowymi firm am i), toteż dom inuje podejście ewolucyjne - stopniowego rozwoju i m odyfikacji system u. Do opisu i zrozumienia architektury i zawartości użytkowanych w firmie systemów informatycznych bardzo często stosowana
jest IBM -ow ska metoda BSP. Aby natomiast ocenić eksploatowany-system, należy dobrać odpowiedni zestaw k r y t e r ió w . Najważniejsze z nich to.: zaawansowanie technologiczne systemu oraz jego znaczenie gospodarcze. Obydwa kryteria mają równorzędne znaczenie. Ich integracja w postaci tablicy oceny systemów [35. s. i4 | tworzy obraz stanu inform atyzacji firmy, pozwalający na podjęcie racjonalnych decyzji i działań w tej sterze. Powstają w ten sposób cztery archetypy użytkowanych systemów informatycznych (por. tablica na rys. >■ matycy, podczas gdy ocena znaczenia gospodarczego eksploatowanych systemów należy do ich użytkowników. Pierwsza grupa oceniających posługuje się ogólnymi pytaniami dotyczącymi niezawodności Stenia,
świetny profesjonalnie zespół informatyków przygotowuje system przy Zaawansowanie technologii m inim alnym udziale przyszłych użytkowników. Niezbędna jest wówczas ( informatycy) pogłębiona ocena systemu pod kątem jego reorganizacji bądź włączenia a«* WYSOKIE dodatkowych funkcji i zastosowań gospodarczych po ponownym sprawdzeniu NISKIE specyfikacji i analizie systemu. Naturalnie najodpowiedniejsza jest sytuacja, 05 gdy ocena zarów no poziomu zastosowań gospodarczych, jak i techno N Ponowna 1 ! Zaprzestanie O logicznego zaawansowania systemu jest wysoka. Systemy takie są najbardziej co ocena użytkowania •o >s o o użyteczne dla przedsiębiorstwa. Mimo swych walorów, winny one być Cl w5 stale doskonalone —modyfikowane i adaptowane. O> Trzecia ścieżka tworzenia strategicznego planu informatyzacji jest 0) -5oparta na podejściu rozprzestrzeniania (ang. inside-out). Jej celem jest 8 5 O id e n ty fik a c ja szans, czyli stwierdzenie, czy możliwości oferowane przez Użytkowanie (0 c ! Modyfikacja i doskonalenie N aktualne trendy rozwoju technologii informatycznej pozwolą podnieść konkurencyjność firmy lub stworzyć nowe opcje strategiczne dla niej. | 1WYSOKIE W łaśnie podejście rozprzestrzeniania pozwala w głównej mierze odkryć te szanse. Podejście to realizowane jest w trzech taktach, polegających na: Rys. 2.2. Tablica oceny systemów [35. s. 74] • badaniu (analizowaniu) nowych, innowacyjnych pomysłów i rozwiązań z dziedziny technologii informatycznej, sprawności technicznej i kosztów jeg o eksploatacji oraz takich zagadnień • specyfikacji przesłanek o charakterze organizacyjnym i kadrowym, szczegółowych, jak parametry sieci, sprzętu i oprogram ow ania. Wpływ sprzyjających w drożeniu nowatorskich rozwiązań, funkcjonowania systemu (lub jeg o braku) na działalność gospodarczą, • opracowaniu planu informatyzacji opartego na innowacyjnych roz łatwość i częstotliwość użytkowania oceniają natom iast sam i użytkownicy. wiązaniach, w wymiarze organizacyjnego i technologicznego środowiska. Systemy są oceniane według każdego z tych kryteriów zg o d n ie z określoną Pierwsza czynność oznacza szczegółową analizę potencjalnego wpływu skalą, a następnie kwalifikowane do każdej z czterech grup. now atorskich rozw iązań technologicznych na rozwój organizacyjny Systemy, których ocena jest w skazaniem do zaprzestania użytkowania, i gospodarczy firmy. Rozwiązania są generowane z wykorzystaniem metod są ju ż zdecydowanie p rz e sta rz a łe technologicznie i m erytorycznie. heurystycznych, takich jak burza mózgów czy metoda delficka. Wypracowane W pewnych przypadkach system od początku m ógł słabo wspierać pom ysły m uszą być ocenione według kryteriów wykonalności oraz funkcjonowanie firmy bądź ¡stola jej działalności zm ieniła się na tyle, iż strategicznej wartości dla firmy. Innow acyjne użytkow anie technologii stał się on bezużyteczny. Jednakże, jeśli m im o p rzestarzałeg o poziomu informatycznej inspirowane jest przez twórczych menedżerów, specjalistów sor— T T Utytkow ™ y « * " » « w ysok o je g o z n a c z e n ie dla rozumiejących walory nowych produktów sieciowych, sprzętowych i progra nwełobv snn rfCJOnOWama y’ “ “ P12“ ' 3 ™ 6 eksploatacji systemu mistycznych. W ielką rolę w procesie rozprzestrzeniania odgrywa zaan systemów ne8a‘yWne K° " ‘ynuacja eksploatacji takich gażowanie bezpośrednich użytkowników systemu. Po wygenerowaniu akceptowalnych rozwiązań innowacyjnych następuje i kosztami ° . r0* nleż sP°w odow ana obaw am i przed skutkami o charakterze organizacyjnym, uzasadniających jest zwykłe Z t ź n O statecznym bodź“ m do opracowanie modyfikacji przesłanek systemu systemu zdeevdn ° UP bądź wdrożenie przez konkurencję celowość innowacji, i planu stworzenia warunków do ich wdrożenia. Oznacza to realizację wstępnych faz cyklu życia systemu. Należy przy tym utrzymać ¿ p0Zyc* na Opracowany równowagę pomiędzy rodzajem innowacji a naturą potrzeb informatycznych systemu, głównie od ^ ^ h n l g f c z n e j . UŻytk0WaneS° oraz zapewnić możliwość wycofania się z innowacyjnego eksperymentu, charakteryzuie sie u/v^Vo • l. > . g j ‘ Jeśl1 jed n ak zastosowanie narażonego na ryzyko niepowodzenia. Jednakże późniejsze fazy cyklu, po zaaprobowaniu rozwiązania na podstawie jego zalet, realizowane są ■ « -» -i ^ konsekwentnie, zgodnie z regułami kierowania projektami.
r^ hWaC
40
skutki'
41
I
w
j a „ i9 .. sic 7 decyzjami kadrowymi. Zadani YWL-nnanie te c o za d a n ia YYią/c ' W y k o n a n ie i ^ m ło d v m p ro fe s jo n a lis to m . m e n e d /e ro r » £ * . u m ie ję tn o ści z a t a t s u u /> .h o « u m .i o h re s lo „ >c
Z
M cc-hnok*,,. T r/c h a ich ulokow ać' * ty c h o g a r a c h .u n k ^ iu iw a n , Źdz,o
i te ch n o lo g ia m fo rm a ty czn a .s lg n w a w n ilg s t r a t e g
„ ą L p i i a c j a a o n o w a to rsk ich ro zw ta za n ,n io n ..u iv « n y e h p o c in o sz a c y c ko n ku ren cc m oce firm y p o ja w ia m c tez w w y tu k u o b s e rw a c ji e c h , Uztatan, klien tó w d o staw có w . ko n ku ren tó w
D o d a t k o u o a - s p o ł p ro je k to w y ocen .
już eksp lo ato w ane w fin n ie -ę ste m y pod w z g lę d e m w p ły w a , na p o d n ie s ie » je j k o n k u re n c y jn o ś c i i w ła c z a j c J o p la n u in fo r m a t y z a c ji. N a p la n „ sk ła d a ją się
YYięc o ce n io n e
p o z y ty w n ie .
u ż y tk o w a n e
i
n u k iy fik o w a a
N \>iem \
je st
śro d o w isk a ,
yy ięc
z.aprojektoYYanie
które
u m o ż liw ia
o r g a n iz a c y jn e g o
w drażanie
i
t e c h n o lo g ic z n e j
innow acji
in t o rm a t y c z n y c ł
P o d e jście to p o leg a zatem na p o s z u k iw a n iu w y c h o d z ą c e g o /
w e w n ą tr
o rg a n iz a c ji b o d źca , sty m u lu ją c e g o p ro ce sy in n o w a c y jn e i w łą c z a n ie ic yy
fo rm u ło w a n ie stra te g iczn e g o p la n u in fo rm a t y z a c ji firm y . Po
yyy b ra n iu
o rg a n iz a c y jn y c h
w a ria n tu
in n o w a c ji
i k a d ro w y c h
in fo r m a t y c z n y c h
p rz e s ła n e k
ic h
r e a liz a c ji
'
o p ra c o w a n i
n a s tę p u je
syp
teza d o ty ch cza s Y Y ykonam ch d z ia ła ń , tj. opracow anie in fo p lan u U w zg lę d nia się yy n im
n a tu ra ln ie rezultaty
Jy y u
p o z o s ta ły c h
ś c ie ż e k
YYania p la n u in fo rm a ty z a c ji - z stę p u ją c e j i w s tę p u ją c e j. W z a s a d n ic z ą ro lę m o g ą o d e g rać
fo rm uło
czyn n o ści u
użytkow nicy. Ic h u d z ia ł yyc w s p ó łtw o rz e n iu
a k ce p ta cji i u ż y tk o w a n iu in n o w a c y jn y c h ro z w ią z a ń p rzez:
m o ż n a sty m u lo w a t
• za sto so w a n ie p rz y ja z n e j w o b e c u ż y tk o w n ik a t e c h n o lo g ii in fo rm a ty c z n e j ja k m enu d o sto so w a n e g o d o s p e c y f ik i firm y , • generatory zasto so w ań , • zaad ap to w an e d la b ra n ży sy stem y e k s p e rto w e ,
• wizualizację danych statystycznych.
Zastosow anie sieciowy ch, sprzętowych i program istycznych standardów ukierunkowuje i w spomaga użytkowników w w ykorzystyw aniu m ożliw ość dostępnych narzędzi i technologii. Planowanie informatyzacji firmy musi być ściśle zw iązane z planowa mem jej działalności gospodarczej. Każda z tych czynności ma swó rezultat końcowy zgodnie z formułą przedstaw ioną na rys. 2.3. Zaten infanlaiT^ JCSl czę*c^ shategii gospodarczej firm y i podobni* mtoplan jest składnikiem biznesplanu.
42
STRATEGICZNE PLANOWANIE GOSPODARCZE
PLANOWANIE STRATEGII INFORMATYZACJI
INFOPLAN
.»nic in ti> in u tyza c|i a Mrategiu gospodarcza lin n y
2.4. Infoplan - zawartość i znaczenie Z asadnicze znaczenie w strategii gospodarczej firmy ma określenie celów firmy w kategoriach podstawowych procesów gospodarczych służących produkcji wyrobów czy usług. Aby je osiągnąć, niezbędna jest efektywna a lo k a c ja zasobów firmy: finansowych, kadrowych, materialnych, a także informacyjnych (rys. 2.4). Zasoby informacyjne są przechowywane w pamięci kadry firm y, dokum entach i opracowaniach papierowych, wreszcie na różnorodnych nośnikach w urządzeniach techniki informatycznej, m.in.
STRATEGICZNE PLANOWANIE GOSPODARCZE
Efektywna alokacja Cele gospodarcze
Kapitału
Informacji
Zasobów Materiałów i energii pracy
środków trwałych
IN FO PLA N
Cele informatyzacji kryteria jakości. przyszłe systemy
I1
Struktura organiza cyjna. kadry informa tyczne
1
—--- -
---------------------------------------------------------------------
Ocena Architektura Sprzęt. bieżącego projekto oprogramowame wanego systemu systemu, zasoby danych
Rys. 2.4. Straicgia gospodarcza a informatyczna [56]
ę
rowa
i j ^h 7 a«nhv in fo rm ac y jn e są niezbędne do efektywnego sTerlwant 7unk1jonowaniem organizacji. Ich uporządkowanie, a nas,ępnit udostępnienie wspomaga realizacje celów firmy oraz potrzeb mformatycz, „ychX k i planowaniu strategii informatyzacji. Podstawowym, składnika* mtoplanu s , Struktura służb i kadr informatycznych, architektura system, 'zasoby (bazy) danych, niezbędny sptzęt. oprogramowanie i sieci komputerów, Treść infoplanu jest uzależniona przede wszystkim od dw u czyn. ników: • strategii, misji i celów gospodarczych firmy, • rozwoju technologii informatycznej. Obydwa te czynniki ulegają szybkim zm ianom . Z jed n ej strony pozycja firmy na rynku, bieżące zmiany perm anentnie d oko n u jące się ru nim. konkurencja (tzw. ..ssanie p o p y tu "), a z drugiej strony, cora? szybszy postęp w technologii inform atycznej (tzw. „ciśn ien ie techno logiczne") wpływają na konieczność stałej aktualizacji planu informatyzacji Przy obecnym tempie zmian zachowuje on aktualność nie dłużej nu przez 2 - 3 lata, po czym powinno się opracow ać now e w ersje infoplanu O pracow anie oraz aktualizacja tego planu w y k o n y w a n a je s t prze? infom enedżera (osobę lub zespól). Infom enedżer je st łącznikiem pomiędzy kierownictwem przedsiębiorstwa a służbami inform atycznym i. Transformuje strategię i cele gospodarcze firmy w infoplan w zakresie p o d an y m na rys 2.2. Aby sprostać temu zadaniu winien mieć rozlegle ro zezn an ie i do świadczenie w funkcjonowaniu firmy, ale i dużą wiedzę fachow ą z dziedzin\ ekonomiki przedsiębiorstw', organizacji i zarządzania, m arketingu, finansów, księgowości, a przede wszystkim — znać aktualne tendencje w dziedzinie informatyki.
2.5. Metody i techniki analizy sytuacyjnej Istnieje wiele aktywizujących, heurystycznych metod identyfikował przez lerownictwo tych obszarów działalności firmy, których informatyzai i" Sj)rzyjac rr 0j0Wi *lrmy’ skutecznemu w drażaniu je j stratę cieść ™ ° r P n° SZeniu -iej k°nkurencyjności. W śród metod, z który • sL e Z r r ™ U M °' W Pienvsz>™ należy wymień je MetaPlan (ang. MetaPlan Session) • -sesje SWOT (s ła b e strony-mocne strony-szanse-zagrożema)
• •
44
dv yn" '^ WP®*otteeS!Ł(ang. Critical Success Factor ~
SP (ang. Business Systems Planning).
Dwie pierw sze metody zostały zaadaptowane do zagadnień TSI. uprzednio bow iem były szeroko stosowane do rozwiązywania problemów z dziedziny organizacji i zarządzania. M im o że założenia sesji M etaP lan są stosunkowo proste, to lak wykazują dośw iadczenia, uzyskuje się dzięki niej bardzo użyteczne re/uitat\. a w' dłuższej perspektywie —wysokie zaangażowanie kierownictwa w projekt. M etoda zaproponow ana przez Schnelle [94] pozwala w uporządkowany sposób prow adzić dyskusję, z udziałem moderatora. Sesja ma charakter w arsztatów , przeprow adzonych dla grupy pracowników danej organizacji. W skład grupy w chodzą: przedstawiciele kierownictwa, eksperci, przyszli użytkow nicy. Przed sesją grupa zostaje podzielona na kilka zespołów realizujących następującą p ro ced u rę sesji MetaPlanu: • kilkadziesiąt sekund dyskusji nad postawionym problemem (chodzi tylko o pierw sze inspirujące pomysły, a nie obszerną dyskusję). • opracow anie indyw idualnych propozycji rozwiązania na oddzielnych kartkach papieru. • „dyskusja k a rtk o w a " w grupie nad indywidualnymi propozycjami, przyjęcie priorytetów’ i wybranie przez grupę najbardziej racjonalnych rozw iązań. Po postaw ieniu problemu i krótkiej dyskusji, mającej za zadanie zainspirowanie członków’ zespołu, uczestnicy sesji przedstawiają własne odpow iedzi, pom ysły rozwiązań i opinie. Propozycje te zapisują na kartkach papieru. Przy współudziale moderatora indywidualne propozycje porządkuje się w grupy tem atyczne, a następnie nadaje p rio ry tety w drodze dyskusji i głosowania. W yboru m ożna dokonać poprzez skalowanie odpowiedzi, a następnie zaznaczanie ich na tablicy-macierzy wariantowych rozw iązań. Procedura MetaPlanu znajduje efektywne zastosowania w odniesieniu do planowania systemów informatycznych. Należy wyspecyfikować zagadnienia, które będą podlegać tej procedurze. Jest ona pow tarzana w odniesieniu do każdego z w yodrębnionych problemów. Problemy te są tak dobrane, aby analiza otrzym anych rezultatów i rozwiązań, a następnie ich analiza porównawcza stym ulow ały realizację głównego celu sesji w sly/anie systemów in fo rm a ty czn y ch , których wdrożenie pozwoli na osiągnięcie celów i uniknięcie zagrożeń w rozwoju organizacji. Najczęściej analizowanymi problemami w następujących po sobie pięciu taktach są kolejno. • c e le f ir m y ,
• • • •
zagrożenia, działania dla osiągnięcia celów, działania dla uniknięcia zagrożeń, sgecyfikacja systemów informatycznych wspomagających osiąganie . o i pozw alających n a u n ik n ię c ie z a g ro ż e ń . 45
PO k aż d y m tak ce następuje p r e s j a . z
^
p^ęcmostatecznej specyfikacji s y s t e m ó ,
r“ u d “ “ ' "
ten s p o s ó h i j g r £
»
£
— os
, 5- N a tech„,kf
MetaPlanu nie należy patrzeć wyłącznie w aspekc.e techn.cznym - war” sesji, zespołów, procedur czy taktów. Za spraw ność techmczn, przebiegu sesji MetaPlanu w znacznej m terze o d p o w te d z .a ln y Jesl moderator. Natomiast uczestnikom sesji techm ka pozw ala zrozumtec istotę potrzeb firmy poprzez grupową, krytyczną an alizę i przedy. skutow anie strategicznych czynników jej fun kcjo now an ia, aktualni,
i rozwoju jej funkcjonowania. Identyfikacja Istotnych Czynników Powodzenia (ICP) następuje poprzez (por. rys. 2.6): • przeprow adzenie w arsztatu pozwalającego określić cele i priorytety firmy, a następnie opracowanie i przeprowadzenie ankiety dotyczącej Ic P w śród kierow nictw a firmy z uwzględnieniem rezultatów warsztatów (ankieta m oże być pow tarzana na zasadzie metody delfickiej), • po zapoznaniu się członków kierownictwa z wynikami ankiet, prze prow adzenie kolejnego warsztatu w celu ustalenia ostatecznej listy ICP. Metoda ICP ma bezpośredni związek z dalszymi fazami cyklu życia sys temu. W wyniku analizy scenariuszy decyzji związanych z poszczególnymi ICP można bowiem dokonać wyboru systemów priorytetowych. Służą one z kolei do opracowania ogólnych projektów systemów metodą prototypowania.
i w przyszłości.
>
DZIAŁANIA DLA OSIĄGNIĘCIA CELÓW
ZAGROŻENIA
DZIAŁANIA DLA UNIKNIĘCIA ZAGROŻEŃ W
SYSTEMY INFORMATYCZNE
Rys. 2.5. Technika MetaPlanu a planowanie systemów
Rys. 2.6. Definiowanie Istotnych Czynników Powodzenia
Interesującym sposobem inicjowania informatyzacji firmy jest model spójności B ro e k stry [56]. Jest on przeznaczony do analizy wpływu zmian dokonanych w jednym rodzaju czynników na inne rodzaje czynników funkcjonow ania firm y. JBroekstra wyróżnia pięć podstawowych rodzajów czynników w ystępujących w każdej organizacji, a określających sprawność jej funkcjonow ania i miejsce organizacji na rynku. Są to: • kom binacja produkt-rynek,
Swoistym łącznikiem pom iędzy strategią firm y a planowaniem wspomagających ją systemów informatycznych jest m e to d a SW OT. Procedura postępowania jest podobna. Po określeniu m ocnych i słabych stron, szans i zagrożeń firmy następuje sprecyzowanie oczekiw ań wobec systemów informatycznych wykorzystujących m ocne strony i szanse firmy • organizacja, i przeciwdziałających zagrożeniom i redukujących słabe strony. Kolejnym podejściem do planowania systemów inform atycznych jest • kadry, m e to iia .ię P _ il2 ] - Istotnych C zy n n ik ó w -P o w o d zen ia (ang. Critical • dom inująca koalicja, czyli formalne i nieformalne grup} pracowni ow . jnąjące wpływ na strategię działania firmy. , r ~ CŁF) Czy~ te 0dP2W M ąją o te z a is m działalności B adanie pow yższych czynników prow adzi do podjęcia ecyzji L f 6 J y ’ “ lych P°zy'yw ny rezultat gw arantuje jej pomyślne tokcjon™ ,an.e na tynku. ICP stosuje się do wydzielenia przez kierow nictw o 0 charakterze strategicznym . Czynniki te są ze sobą ściśle pow iązane g ownych obszarów zainteresowania dla zapew nienia ciągłości 1 zmiana któregokolwiek z nich powoduje zmiany pozostałych (por. rys. -.7.). 4«
47
r
Zmiany stają się w ten sposób przewidywalne, co pozw ala na rozważeni m in ewentualnych negatywnych skutków. W ten sposób m odel spójnośi staje się użytecznym narzędziem planow ania system u in fo rm a ty c z n e j Dzięki niemu, można na przykład przew idzieć sk u tk i w d ro żen ia system informatycznego (technologia) na kom binację rynek-produkt, organizację kadry oraz dominującą koalicję. N atom iast określenie p o trzeb y zmiai w zakresie produkowanych wyrobów i rynku d o celo w eg o identyfikuj systemy informatyczne wspomagające te zmiany. W tablicy 2.1 w odniesieni do każdego z wymienionych czynników w skazano sfery zm ian, które należ rozpatrzeć przy podejmowaniu działań. Zmiany zwykle inicjowane są przez kierow nictw o, choć inspiracj najczęściej pochodzi z otoczenia organizacji. Z m iany te m ają charakte Tablica 2.1. Sfery zmian w modelu spójności Czynnik
Sfery zmian
1. Kombinacja produkt-rynek
Sygnały rynku. Profil produkcji. F luktuacja popytu. Udział w segmencie rynku. Nowoczesność wyrobu.
2. Technologia
Postęp technologiczny. M ożliwości inw estycyjne firmy w zakresie wszystkich posiadanych zasobów.
3. Organizacja
Zadania i zakres odpowiedzialności. Struktura organizacyjna. Stył pracy.
4. Kadry
Zdobycie nowych umiejętności i wiedzy. Problem y
motywacyjne. Zagrożenie bezrobociem. Przekwalifiko wanie. Współpraca zc związkami zawodowymi. 5. Dominująca koalicja
48
Odpowiedzialność za całą organizacje. Odpowiedzialność za spójność strategii gospodarczej. Alokacja zasobów. Motywowanie i inspirowanie zmian.
technologiczny lu b rynkow y. Kierownictwo rozpoczyna od działań dotyczących czynnika, w którym potrzeba /.mian jest najbardziej odczuwalna i oczekiwana. Jednakże przed podjęciem tych zmian kierownictwo musi rozważyć, jakich zmian należy dokonać w zakresie innych czynników i ich sfer zmian w celu sprawnego osiągnięcia pożądanych rezultatów. Bardzo dogodnym narzędziem definiowania architektury systemu informatycznego danej organizacji, dającym kierownictwu możliwość ustalania priorytetów projektowania i wdrażania poszczególnych modułów, jest IB M -ow ska m e to d a BSP. Polega ona na określeniu macierzowych zależności w ystępujących w organizacji gospodarczej pomiędzy procesami gospodarczymi, kom órkam i organizacyjnymi (funkcjami), grupami danych (encjami) oraz zastosowaniami (podsystemami informatycznymi). Globalną macierz zależności, noszącą skrótowe miano Infocross |56j. przedstawiono na rys. 2.8.
WSPOMAGANIE PRZEZ SYSTEMY INFORMATYCZNE »
____ T*—
^
•
•
■- -
ORGANIZACYJNA ODPOWIEDZIALNOŚĆ
■ —-• *
»
•
•
•
1 !
i i
M i i
i i
i i
i |
:
i
: :
j :
• :
i •
j
1
i
i
i
i
!
a
i
•
1
M
; J
i
i
i
i
i
i
i
!
j
;
t •
: «
: 1
i !
i
»
•
I
•
• ;
« ;
4
• #
• •
a a
i : 4 l
i l
•
i
f
.
«
i
•
i
f
1
I
i
i
:
:
: | l
» a
-
— ■ —
—
■
i :
« f i •
: • \
i I
* t • t
Z /
SYSTEMY INFORMACYJNE
I f :
1
1
p
y
-
t o
*
*
/
l J t -" *
ł
f
JEDNOSTKI ORGANIZA CYJNE
(*
7
'
/
‘M l \v
ENCJE
1 : ♦ • • t
a
f
» i
:
[
PROCESY GOSPODARCZE
t
• •
ARCHITEKTURA SYSTEMÓW INFORMATYCZNYCH
L
- .
/
l
i
..
V
• |
j
_
*
—
1
"
—
■
INFORMATYCZNA ODPOWIEDZIALNOŚĆ »
«
•
*
*
•
•
•
*
. . . .
*
*
*
*
.
*
‘
Rys. 2.8. Macierzowe zależności * metodzie BSP |5-ł %l
Aby skutecznie zastosować metodę BSP należy wyszczególnić wszystkie składniki czterech elem entów opisu architektury systemu. Następnie m o/na przystąpić do opracow ania kolejnych macierzy. m auer/y j • gospodarcze-jednostki organizacyjne (funkcje) określa ■W
r
Funkcje 'u -
' '
PROCESY - ►FUNKCJE
f B yra k to r D yre kto r fin a n so w y (Kierownik D zia łu P la n o w a n ia S tra te g ic z n e g o
[K ie ro w n ik D ziału M a rke tin gu Kierow nik D ziału D ostaw Kierow nik Działu S przedaży ¡Kierownik Działu G ospodarki M a teria ło w e j Kierownik D ziału Produkcji Kierownik Działu Kontroli P rodukcji | Kierownik Działu Kadr 'Kierownik C enlrum Inform atyki Zarząd strategia marketing __ wytwarzanie zasobów ___ analiza rynku _____ przetwarzanie zam ówień sprzedaży kontrola produ k c ji _____ ___ ' produkcja _______ f kontakt / dostawcam i | przetwarzanie zam ów ień zakupu sterowanie zapasam i dystrybucja fakturowanie przetwarzanie płatności [ kontrola użytkowania zasobów
Procesy |'ffX" - odpowiedzialnyr
o
X
X X
X
0
o X X
4-
o o o
X X
X
o
o
o X X
o X X
o o
____ L
X - słabo powiązanyJ
Rys. 2.9. Macierz procesy gospodarcze /jednostki organizacyjne E neje 1z a s ó b
PROCESY < ► ENCJE
; w y ró b h a rm o n o g ra m [d o s ta w a J S m ó w ie n ie
Jdostawca
_ J rynek
[d z ia ł pro du kcji [ p la n pro du kcji p la n s p rz e d a ż y _________
_____
plan w ykorzystania zasobów m arketingu_______ s tra te g ia ______________ : marketing ______
?
j[
o X
J r - p o w ia z a n y
f
o
Ł']
wytwarzanie zasobow analiza rynku _________ przetwarzanie zamówień sprzedaży Kontrola produkcji produkcja ______
[kontakt z dostawcami i przetwarzanie zamówień zakupu sterowanie zapasami dystrybucja fakturowanie kontrola
owanto
Rys. żiO. Macierz procesy go»podarc2e/cncje
powiedziałności poszczególnych jednostek za grupy procesów. Jednostka może być w pełni odpowiedzialna za proces (X), powiązana / jego realizacja (0 ) lub słabo zaangażowana (—Jl-W. „realizację procesu (por. rys. 2.9). Zasadniczą rolę w definiowaniu architektury systemu odgrywa zależność między procesam i a danymi, wyrażanymi w postaci grup danych, czyli scharakteryzow anych w rozdz. 4 encji. Przedstawiona na rys. 2 .1 0 macierz określa, w zw iązku z jakim i procesami grupy danych tworzy sig_ (C). i użytkuje (U). Należy zauważyć, iż uporządkowanie zarówno procesów, jak i danych nie jest przypadkowe - procesy i dane pokrewne znajdują się obok siebie. Pow oduje to powstanie tematycznych zagnieżdżeń oznaczeń C i U, co sprzyja definiowaniu struktury systemu, złożonego z kandydatów na podsystem y (por. rys. 2.11). Jednocześnie określane są związki pomiędzy tem atycznym i grupami zagnieżdżeń. W ten sposób dochodzi do opracowania architektury systemu - określenia podsystemów informatycznych i związków między nimi (por. rys. 2.12). Na podstawie zaproponowanych na rys. 2.8 zależności m ożna wskazać i zbadać inne zależności macierzowe, sprzyjające dokładniejszem u sprecyzowaniu projektu architektury systemu informatycz nego organizacji gospodarczej. Encje
ZWIĄZKI
i zasób ! płatność ra wyrób ! harmonogram ; zapas j dostawa I zamówienie [dostawca________ fdziat produkcji_______
[ plan produkcji
________
1plan sprzedaży___________ _
[produkt________ j klient
_________
plan wykorzystania zasobów
f33ał marketingu - J O
"
s g p
1
» O O P
strategia
marketing
H -y f 1 -jr —
wytwarzanie zasobów ąnąjjzajynjtu sprzedaży przetwarzanie zamówień zarr kontrola'produkcji
-- 9 -f
P M
U
i
if u&ĄM If '
kontakt z dostawcami
u p iI C
{.V
: „ •S
starowanie zapasami fakturowanie ^przetwarzanie pła.tnośd___ kontrola użytkowa ma zasobów
y Ó V ^ ¡ 5 6 .-6 ,[t> , — r r j j g •'[•H li r— -- F -t ' 21111 "
U-
f.M-. c.i u .rur ULJ
Procesy owanie
C " - tworzenie
Rys. 2.11. Grupy tematyczne związki międ/y nimi
51
Eneje a r c h it e k t u r a
system u
zasób I płatność
in f o r m a t y c z n e g o
(faktura______ w yrób ¡'harm onogram [z apas __ d osta w ą _____________
fza mówjenie
-----------—
¡ d o s t a w c a _____________ —
fdzłałj)rodukę[i [plan produkcji_______ [p la n sprzedaży
f
--------------
klient
piań w ykorzystania zasobów [d z iał m arketingu __________
[zarząd
L
la
m a r k e tin g
________
w ytw arzanie zasobów analiza rynku przetwarzanie zamówień sprzedaży kontrola p ro d u kcji _____
pr o d u k c ja _______________
PLAN O W ANIE SPRZED A Ż ^
PRODUKCJA
t
1
k o n tą k tz dostawcam i__________ przetw arzanie zam ów ień za kupu sterow anie zapasam i___________ dystrybucja^ _______ fakturowanie przetw arzanie płatności kontrola użytkowania zasobów
Procesy s z M- sterowanie zapasamj
„GZ"- gospodarka zasobam i
„DYS." - dystrybucja
Rys. 2.12. Macierz BSP i architektura systemu inform atycznego
Tablica 2.2. Etapy wzrostu poziomu informatyki w przedsiębiorstwie [8 1 1 Etap
Charakterystyka
1. Inicjacja
Pojedyncze zastosowania. W drożenie przez tw órców zewnętrznych be/ ud/iału użytkowników.
2. Popularyzacja
Większa liczba zastosowań w przedsiębiorstwie. Ograniczony udział użytkowników. Brak planow ania informatyzacji.
3. Sterowanie (kontrola)
Planowanie informatyzacji firmy. W prow adzenie metod planowania i kontroli. Standaryzacja techno logii.
4. Integracja
5. Ukierunkowanie (orientacja) na dane
6. Nasycenie
Zastosowanie baz danych. Struktury danych. Tworzenie systemów.
Kontrola użytkownika nad zasobami informa tycznymi. Systemy informowania kierownictwa. Organizacyjna integracja przez informatykę. System informatyczny odzwierciedleniem organizacji. Wspomaganie strategicznego zarządzania.
Dobór, zastosow anie omówionych metod i przyjęty zakres planowania systemu inform atycznego zależą od poziomu świadomości i swoistej „kultury inform atycznej danego przedsiębiorstw a. Z asadnicze znaczenie ma ocena poziomu informatyki i kierunku zmian. Koncepcja etapów w z ro s t u p o z io m u in fo r m a t y k i w p rz e d s ię b io rs tw ie , zaproponowana przez R. N olana [81], wyróżniająca sześć etapów wzrostu, wymienionych i scharakteryzow anych w tablicy 2 .2 do dziś jest aktualna.
2.6. Restrukturyzacja procesów gospodarczych W ostatnich latach coraz większe zainteresowanie menedżerów firm oraz działów informatycznych wzbudza metoda restrukturyzacji (w literaturze polskiej spotyka się również określenie reinżynieria) procesów gospodarczych (ang. Business Process Reengineering - BPR). Przez restru k tu ry zację procesów gospodarczych [48, s. 46] należy rozumieć fundamentalne przemyślenie i radykalne przeprojektowanie procesów gospodarczych w celu osiągnięcia skokow ych zmian w zakresie istotnych kategorii funkcjonowania organizacji gospodarczej, takich jak koszty, jakość, poziom czy szybkość usługi. Słow a kluczow e w tej definicji to: proces, fundamentalne, radykalne i skokow a. W okół procesów gospodarczych koncentruje się istota restruk turyzacji. Proces gospodarczy to zestaw działań, wymagających jednego lub kilku w ejść, tw orzących wyjście, które posiada wartość i użyteczność dla klienta. Z asobam i wejściowymi są materiały, informacje, rynek, a w yjściem tow ary i usługi. Transform acja dokonuje się poprzez pracę kadry i technologię. D obór słów kluczowych wskazuje, że restrukturyzacja polega na zm ianie przełom ow ej dla danej firmy. Podstawowe pytanie w restrukturyzacji procesów gospodarczych nie brzmi „Jak można robić szybciej, lepiej, tan iej?” , ale „D laczego robimy to, co robimy.’ W tym przejaw ia się now atorstw o metody BPR. O znacza to również zmianę myślenia z dedukcyjnego, ukierunkow anego na rozwiązywanie problem ów, na indukcyjne. Jego cechą jest rozpoznanie nowoczesnego rozwiązania, innowacji, je j charakterystyk, a następnie poszukiw anie problemów, które dana innow acja może rozw iązać. Synonim em restrukturyzacji procesów gospodarczych jest w ięc słow o „innow acja . Różni się ona zasadniczo ikI doskonalenia procesu, co ilustruje tablica 2.3 [30. s. 11 ]. Naturalnie, jw trzeb a restrukturyzacji nie dotyczy ka/dej tirmy, ule firm borvkaiacvch sie z problemami, przewidujących powstanie mekor/y v
tpych dla siebięjy.tuacji na rynku albo też zakres, wielkość i skuteczność swej działalności gospodarczej. RestiukTuryzacja p r o c e s ó w gospodarczych winna być przedmiotem zainteresowania 53
Cs.W ^pixiafc/>ch | 'O s Ili ca 2 ,
R e s n iU u r y w i» » i n m W
Inni'\N.u ta
j ~
Radsiatny
Sfop"»0 * s
___
.
Biała karta* ’
■tan»e*ce [*»***> _______
Punki -larw
Je d iu v a /o w a / r i i UII
\i« v Ł \d n > czas
j Jc5nora/ow a lub cutfła
B pfS M P ff ! Kiotki __________
P łu g i / s t c p i u a t s *z g o n na J a b
U »i (od dołu d o tsx y 1
Kierunek /mian
s.i-foki rowil'ylunkisjny
[ WyAi » fwach tunkcii
Tyj*'*> /akrr'
Wvvikw
l ’murk'^âne
Ryyyin
k»*nin*D uvka/iuków
StymuUtiw /m ian
tk>*
Icchnoloiîu intormatu/iui
i\V\rch
Kifltufowo- \irukluialnN
K ulturo* s
Rid/aj /mian
me tylko istniejących firm. Dotyczy on;, przede w szystkim dwu gn p rz e d się b io rstw :
. zHajduJących się u trakcie transformacji rów nie/ w ym uszonej pr/< warunki zewnętrzne planujących ekspansję rynkow ą lub zugro/onyc upadkiem. • firm nowo powstających, poszukujących swej s/ansy nu rynku. Istnieją dwa podstawowy e/ynniki o g ran iczające ten wpływ. • tru d n o ść
w
o k re śle n iu
re a ln e g o
p r /y s / łe g o
z n a c z e n ia
n a jn o w sz y c
ro /w 14/an te c h n o lo g ic z n y c h w d z ia ła ln o ś c i g o s p o d a rc z e j i sp o łcc/.n e g sto p n ia ic h a k c e p ta c ji. • sto pień
sw ołx*d>.
k tó rą
p rz e d s ię b io rs tw o
ma
we
w d r a ż a n iu
nowe
te c h n o lo g ii o raz n o w y c h fo rm o rg a n iz a c y jn y c h .
Restrukturyzacja procesow gospodarczych nie zaw sze kończy si pozytywnym wynikiem Istotne jest, by kierow nictw o za cel radykalnt zmiany, uznało ponowne odkrycie przez siebie organizacji, a nie j< ulepszenie, rozszerzenie czy mody fikację. Pewną przeszkodą jest fakt, 1 istnieje zespół raczej luźnych reguł dokonania restrukturyzacji procesó» gospodarczych. NHarto w tym miejscu przytoczyć kilka (zalecanych w [41 % , s. 457]) zasad dokonywania.ręsUukluiyzacjLprocesów gospodarczych • kilka do tej pory wykonywanych odd ziejn ię^ciy n n o ści (być moż wykonywanych przez różnych pracow ników ), łączy się w jede kompleksowy rodzaj gracy, wykonywanej p r?pv jf>/Jn:)~7v;nhe lu
prz.ynajniniejjgrzez mmejsząKćzbę pracowników; Pf^ow njcy jiie^ są wykonawcami instrukcji, lecz podejmują decyzj - podejmowanie decyzji ^ ' się'sW adm kiem ich prŁy; • następuje delinearyzacja pracy, tzn. równoległe jej w ykonyw anie z» miast sekwencyjnego wykonywania poszczególnych czynności 54
.
;
V-- •
dzięki c /e m u skraca się okres między rozpoczęciem a zakończeniem procesu; . ogranicza się kontrolę, sprawdzanie i weryfikację na rzecz jakości w *y k o n y* w a n e j pracy;— • proc es > nie m ają sztywnych standardów, ale wiele wersji na potrzeby różnych w arunków , sytuacji, klientów; • ogranicza się różne uzgodnienia między realizatorami procesów; ich nadmiar staic si^ przyczyna powstawania niespójności, straty eneniii i czasu w trakcie realizacji procesu; • technologia intoi maty c /n a w coraz większym stopniu umożliwia takie funkcjonow anie poszczególnym jednostkom, jak gdyby były w pełni au to n o m ic/n e, a jednocześnie organizacja gospodarcza może korzystać / efektu centralizacji. W konkluzji należy stwierdzić, iż po zastosowaniu w' firmie restruk turyzacji procesów gospodarczych, praca poszczególnych pracowników staje się w ielow ym iarow a, obejm uje elementy podejmowania decyzji, paralclmc w ykonywane czynności, ogranicza czynności kontroli i uzgadniania, koncentruje się na potrzebach i współpracy z klientem, a nie na poleceniach kierow nictw a. R ola pracow ników zm ienia się: z kontrolowanej na upraw om ocniony, w ykonaw cza, zarządczą. Staje się to warunkiem sprawnej realizacji radykalnie przeprojektow anych procesów. W rezultacie następuje zanikanie w- o rg a n iz a c ji działów funkcjonalnych na rzecz zes połów procesów , obsługujących poszczególne procesy. Mogą one mieć charakter ..w irtu a ln y " , t/n . członkow ie takiego zespołu są w' miejscach odległych, a realizują proces, komunikując się za pom ocą technologii inform atycznej. Każdy proces przebiega w określonej strukturze hierarchicznej, zawierającej składniki procesu, działania i zadania (13, s. 65): • składniki procesu (podprocesy) to sposób organizacji procesu gospodar czego, np. proces obsługi klienta składa się ze sprzedaży, zarządzania
i transportu; • działania są w yróżnialne wśród podprocesów, przekształcają zasoby wejściowe w w yjścia systemu, użyteczne dla klienta; • zadania to najniższy poziom w hierarchii procesu, czyli standardowe procedury funkcjonow ania. J& oęesj' w ystępujące w organizacjach gospodarczych
m ożna,
, pod/te c,
tak jak na rys. 2.13 na trzy ro d zaje [86, s. 2]: . . . . . na zaspokojenie.jac^ekiwań klienta; 1•
• jy n re s y wspomagają* ^ g ió w n y c ^ -p o p rz e z sj gospodarczej;
' .»»
•
*
i
Procesy zarządzania
î f i t pom ocnicze Procesy Rys. 2.13. Rodzaje procesów gospodarczych |>S6. s. - ]
9
• procesy zarządzania, pozwalające na planow anie i kontrolę organizacj w celu realizacji procesów podstawowych i pom ocniczych. Przebieg restrukturyzacji procesów gospodarczych przedstaw iony jes na rys. 2.14. Pierwsza faza restrukturyzacji procesów g o sp odarczych wyodrębnieniu w organizacji gospodarczej tych p ro cesó w , należy v dokonać ________ radykalnego radykalnego przeprojektow ania, ssto to so w n ie stwarzanych przez innowacje. W zarysie owa id e n ty fik a c ja przebiega następująco [30, s. 27]: • specyfikacja głównych procesów firmy, • określenie granic procesów, • ocena strategicznego znaczenia każdego procesu, • określenie zasad i sekwencji przebiegu każdego procesu.
Identyfikacja stymulatorów zmian
Tworzenie wizji procesów
Charakterystyka i rozumienie istniejących procesów Projektowanie i prototypowanie nowych procesów Rys 2.14. Pr/cbicg rcstmkiuryzacji
procesów gospodarczych |30|
polega n, w których do szan procesów
W firmie średniej wielkości liczba procesów waha się od 10 do 20. Trudność dekom pozycji procesów wynika z faktu, że są one praktycznie nieskończenie pod/.ielne. Na przykład, procesy związane / zamawianiem mogą być traktow ane jak o jeden proces lub jako wiele procesów. H am m er i C ham py [48] wyróżniają 3 główne procesy w przedsiębi*lorstwie przem ysłow ym : • tw orzenie now ych produktów, • dostarczanie now ych produktów do klientów. • zarządzanie w spółpracą z klientem. Istnieje tendencja do zm niejszania liczby procesów. W przypadku stopniowego udoskonalania bardziej korzystne jest definiowanie hierarchii wielu procesów . Jednakże jeżeli celem jest radykalna zmiana, proces winien być zdefiniow any tak szeroko, jak to możliwe. Im mniej jest procesów, im szerszy jest ich kontekst, tym większa jest możliwość dokonania ra d y k a ln y c h innow acji dzięki integracji procesów, ale zarazem większe są problem y rozum ienia, pomiaru i zmian procesów. Przydatnymi praktycznymi technikam i dekompozycji procesów na składniki (podprocesy). działania i zadania są metody diagramów przepływów danych oraz diagramów struktur, przedstaw ione w pracy [ 1 2 2 ], W yróżnia się trzy podstaw'owe stym ulatory zmian: • organ izacyjno-kad«sw y7. • inform acyjny,., • inform atyczny. W ykorzystanie pierw szego typu stym ulatorów ma miejsce w pracy zespołowej w trakcie różnorodnych warsztatów. S tym ulator inform acyjny dotyczy zaś tego zakresu inform acji użytkowanej przez menedżerów, która nie jest g en ero w an a autom atycznie z systemów informatycznych. Według dostępnych szacunk ów 85% informacji związanej z realizacją procesów w organizacjach nie je st przetw arzane przez technologię informatyczną. Jest to tzw. w iedza nieustrukturyzow ana. W ydaje się, że odsetek ten będzie malał w zw iązku z dużym znaczeniem zasobów i usług Internetu. Wciąż ma miejsce taka sytuacja, iż w iele inlormacji w ynikowych generowanych przez system y inform atyczne nie jest użytkow anych przez menedżerów, bowiem są one dostarczane zbyt późno. Bardziej użyteczne jest bo /pośrednie sprzężenie zwrotne (systemy interaktywne), nawet jeśli intormacje wejściowe
są tylko oszacow ane. Z punkiiL-widzenia w pływ u informatyki na restrukturyzację proco« . .in fo r m a t y c z n e . P o z w a la ją o n e o rg a n iz a c jo ... i a d m in is t ra c y jn y m n a fu n k c jo n o w a n ie w ra d y k a ln ie now ych w a. un ac. R e s t ru k tu ry z a c ja
p ro c e só w '
g o s p o d a rc z y c h
n ie
o /n a c /a
j
. >>". ..........
r
■
t
-ile poszukiwanie i opracowywanie now ych proces» informatycznej w m etodzie B PR w iąże ,
u s t a n i najnowszych rozwiązań innowacyjnych do przeprowadzeń, ú z v ie tn e zmiany. Tak rozum iana roie tech n o lo g u , „ fo rm a ty « * S « i procesów gospodarczych m ożna w,cc p rzed staw ,ć. j, na rys. 2 . 15. Technologia informatyczna (stym ulator procesu, szansa)!
Z m ia na (radykalna popraw a)
Wynik ekonom iczny
Rys. 2.15. Model wpływu informatyki na restrukturyzację procesów gospodarczych
Przykładami innowacji-stymulatorów są m.in. rozproszone bazy danyci systemy ekspertowe, sieci telekom unikacyjne, k o m p u te ry przenośni interaktywne wideo. Wszystkie te osiągnięcia m iały istotny wpływ n restrukturyzację procesów i przeorientowanie działalności w ielu firm. Aby proces restrukturyzacji mógł być zainicjow any, należy zider tyfikować te rozwiązania z zakresu technologii i system ów informatycznycł które potencjalnie mogą być stymulatorami zm ian. P ro ced u ra postępowani w tym przypadku jest następująca: • identyfikacja potencjalnych technologicznych i k ad ro w y ch szans n. zmianę procesu, • identyfikacja potencjalnych technologicznych i k ad ro w y ch ograniczeń, określenie możliw;ości wdrożeń poszczególnych p ro cesó w , określenie, które z ograniczeń będą mogły być zaak cep to w an e. Praktycznym sposobem realizacji tej p rocedury m o g ą być sesji
Narzędzia modelowania
Ograniczenia Zagrożenia
Wdrożenie systemów i technologii informatycznej
procesów gospodarczych (30]
M etaPlanu lub SW OT. Ocena i ostateczny d o b ó r in n o w a c ji (wraz ze specyfikacją zaakceptow anych ograniczeń) uruchamiają proces radykalnego przeprojektow ania funkcjonujących w przedsiębiorstwie procesów lub zaprojektowania nowych. Są one następnie przedmiotem wdrożenia. Opisane zasady restrukturyzacji procesów gospodarczych z wykorzystaniem inno wacyjnych m ożliw ości informatyki przedstawiono na rys. 2.16. Innowacyjne możliwości technologii informatycznej należy rozpatrywać w kategoriach uogólnionych technologicznych i systemowych zastosowań, adekw atnych do pewnych procesów i problemów występujących w or ganizacjach gospodarczych. Zadaniem projektanta lub zespołu projektującego nowy proces jest uwzględnienie wszystkich innowacji technologicznych j system ow ych, sprzyjających jego przekonstruowaniu, a następnie ocena i dobór optym alnych rozwiązań. Składnikami wizji (por. rys. 2.14) zm ienionego procesu są jego cele i atry b u ty . Cele te muszą być określone jako zadania służące dokonaniu zmian. Pełne ich sformułowanie obejmuje również w skazanie typu zmiany lub udoskonalenia oraz wyznaczenie zakresu i harm onogram u zmian. Cele procesu należy określić ilościowo - zgodnie ze strategią rozwoju firmy. Przykładem może być zwiększenie udziałów firm y w segm encie rynku o 1 0 % w okresie 2 lat czy zmniejszenie pracochłonności przetw arzania zamówień o 60% w ciągu 3 lat. Natomiast atrybuty procesu są zwykle opisowymi nieliczbowymi cechami pomocniczymi w stosunku do celów procesu. Tw orzą wizję funkcjonowania procesu w przyszłości. Na przykład, do procesu zarządzania zamówieniami można w prow adzić żądanie płatności kartami kredytowymi. Atrybuty procesu m ogą być uw ażane za reguły funkcjonow ania procesu. Po opracow aniu wizji procesów należy je szczegółowo sc h a ra k teryzow ać, czyli dokonać opisu zachodzących w nich przepływów albo przystąpić bezpośrednio do projektowania nowych procesów. IsUiieje rozbieżność zdań co do konieczności opisu istniejących procesów. Przyjmuje się jednak, że warto podjąć ten wysiłek w związku z tym, iż zrozumienie istniejących procesów ułatwia komunikację między członkami zespołu, szczególnie wtedy, gdy procesy są względnie nieustrukturyzowane. Ponadto, w bardzo złożonych organizacjach nie ma możliwości przejścia do nowego procesu bez zrozum ienia istniejącego. Wykonać należy zatem następujące
czynności: • opis bieżących przepływ ów w procesie, ocenę procesu w warunkach nowych celów i atrybutów, identyfikację problem ów i wad procesu, ocenę aktualnej technologii informatycznej i organizacji procesu. N a tym etapie bardzo przydatne są różnorodne metody opisu przebiegu pracy i przepływ u dokum entów (ang. workflow miuuigement). C /m h h ^ć ta ••
2
%" M y M
‘
L
i
,
w co,,, w
„
:T ,
a
c
:
d a n T h t m ) o r a " Intranetu umożliwiaj,, elektroniczny przepływ 4 kUmR d tm :eż w p rzy p a d k u o statn ie j z fa z . tj. p r o je k t o w a n ia
i pro«*
ty p o w a n ia n o w y c h p ro c e só w , m o żn a w y k o rz y s ta ć p rz e d s ta w ,o n e w y * m etodv pracv i p rze p ły w u d o ku m e n tó w . Je st to p ro c e s d e r a c y jn y . w k,o ty„ S
2
*
do p aso w anie p o m ię d z y n o w ,, s tru k tu ra p ro c e s u , t e c h n o lo g
in fo n u a ty c z n ,
i o rg a n iz a c ja . Z a d a n ie m
o sta tn te j
la z.y
je s ,
w d ro żen i,
radykalnie przeprojektowanego procesu. ' Nowym stymulującym technologiom odpow iadają określone rodzaje sprzętu, pakiety oprogramowania czy zastosow ania sieciow e, cechujące się u ż y te c z n o ś c ią . Aktualnie można te uogólnione zasto so w an ia ująć w trzj kategorie: • tworzenie i rozwój produktów, • realizacja zamówień, • logistyka. Pierw sza sfera innowacyjnych zastosowań inform atyki ukierunkowana jest na automatyzację projektowania i prototypow ania produktu, symulację funkcjonowania prototypu, monitorowanie stanu produktu, koordynację projektowania w zespole, analizę wpływu doboru: m ateriałów , technologii czy dostawców na walory użytkowe bądź rynkow e projektowanego produktu. Zam aw ianie stanow i w now ej te c h n o lo g ii je d e n proces, począwszy od składania czy przyjm ow ania ofert, a sk o ń czy w szy na realizacji płatności. Proces ten stwarza możliwości w drożenia następujących zastosowań innowacyjnych: wyszukiwanie i p o ró w n y w an ie produktów z użyciem baz danych i system ów e k sp e rto w y c h , prognozow anie popytu, elektroniczny handel z w ykorzystaniem k o m e rc y jn y c h sieci komputerowych, elektroniczna w ym iana danych (E D I), automatyczny skład tekstu stosownie do życzeń i specyfiki klienta. System y logistyczne umożliwiają natomiast na przykład zarządzanie dużą firm ą transportową poprzez satelitarną identyfikację pojazdów czy realizację zdalnej telemetrii. Współczesna informatyka oferuje zatem bardzo wiele rozw iązań, które mogą byc stymulatorami tworzenia nowych procesów. Do najbardziej przyszłościowych należy zaliczyć:
• Z %
Ż ur
>e* m ‘ PrZepłyWem doku"“ "tów (ang. workflo*
• komputerowo wspomagana praca zespołowa (ang groupware) gospodarcze z a su w a n ia Internetu oraz Intranem
hurtownie danych (ang. dala warehouses) • systemy pozyskiwania danych (ang. data mining)
P
>'
. graficzne systemy wspomagania decyzji (ang. Executive In fo m a tio n System - HIS), w • system y ekspertow e, • erafika kom puterowa, • języki czw artej generacji, • technologie rozpoznaw ania mowy, • system y satelitarne, • m ultim edia, • uniw ersalne system y baz danych, • system y obiektow e. O kres t r a n s ł o i m a c ji g o s p o d a r c z e j sprzyja generow aniu wielu no wych p ro cesó w w iii m ach. Przeprow adzone badania 160] wykazują, iż restruktui y z a c ja procesów gospodarczych z w ykorzystaniem technologii inform atycznej p rzedstaw ia się jak na m odelu z rys. 2.17.
Rys. 2.17. Model restrukturyzacji procesów
Zaprezentow any model odpowiada zarówno restrukturyzacji procesów gospodarczych istniejących w firmach, jak i tworzeniu zupełnie nowych procesów dzięki w ykorzystaniu innowacji informatycznych. Istnieć muszą więc w zaiem nie ze soba współpracujące stym u lato ry .zm ian ^tech n o lo g ia Iśmienie tylko jednego z tych stymulatorów nie zapew nia osiągnięcia sukcesu rynkowego. W ykorzystanie pow yższego modelu było źródłem sukcesu wielu nowych linn. Przykłady funkcjonowania modelu w konkretnych przypadkach zaprezentow ano w tablicy 2.4 tbe/ podania rzeczyw istych nazw firm). 61
Tablica 1A. M M « Stymulator - technologia informatyczna
Stymulator - popyt rynkow y
Technologia mulii- W zrastające znaniedialna: gospo- ozenie technologu darcze zastosowa -1 multimedialnej i jej ud/iuł w rynku nie Internetu edukacyjnym kra jów rozwiniętych; wysokiej klasy specjaliści w dzie dzinie technologii multimedialnej. 2. Beta
Generator) oprog- \ Komputeryzacja ramowania; pakie- administracji uczelt> CASE \ ni; nowe zmodyfikowane zadania dla ad ministracji uczelni.
Projekt nowego procesu
Wynik ekonom iczny
Tw orzenie o p ro gramowania i pro duktów m ultim e dialnych. ich m ar keting i sprzedaż na rynkach krajów
O program ow anie mu| timedialne i produkty n, płytach CD RO M ; mu|.
rozw iniętych.
Procedury restruktu ryzacji adm inistracji uczelni; tw orzenie oprogram owania dla wspom agania adm i nistracji uniwersytec kiej.
Programowanie, in transmisja satelitar dostęp do sieci lokal stalacja t usługi u za na; zaawansowane nych i rozległych kresie sieci kompu elektroniczne urzą w skali kraju. terowych. dzenia akustyczne
3. Gamma Sieci komputerowe; Rosnący popyt na
tim edialne lahoratoriurr do produkcji kursów ję. zykow ych na płytach kom paktow ych; firm„ konkurująca skuteczną na rynkach światowych
Pow ielam y system m form atyczny administro. w ania uczelnią użytko wany przez wiele pod miotów'.
N iezaw odny dostaw a zaawansowanych usłusieciowych posiadając) certyfikat jakości ISO 9001; sieciowe oprogra m owanie dla routerów.
Pytania i problemy 1. Cele planowania systemów informatycznych. 2. Jakie są założenia infoplanu i jego składniki? 3. W ybierz d zied zin ę p rz ed m io to w ą z d o w o ln e g o z a k re s u d z ia ła ln o ś c i f ir m y i sform ułi
infoplan, wykorzystując strategię przedstawioną na rys. 2.1. 4 svs?emówWyw niC CZler> ? ęŚC1 taWiCy °Ceny s>'stem6vv P^ykładami znanych C 5
X r
JC 7 tXlp° wiedn,e obszary* Uzasadnij dokonany wybór.
6 P P° 7 dZy r iegią w ó d « * a informatyczną. ‘ uzasadnienia ^ b o 7 ^ Wyk° nywać 1 »Pehuać m fom enedżer. Jakie » 7 uw M umiejscowienia w składzie zarządu firmy?
8. Dobierają^tKłpowiedjde^kryteria S>lUacyjnej 1 rozwaz Pryczyny ich różnorodności sytuacyjnej sporządź tablicę charakterystyki metod analir infoplanu dla Twojego w y to a łU u ^ w h ^ SW° T’ ukierui»kowaną na powstań* ° Wyiaśnij ‘Un k c j o n ^ “ ^ ~ pięciu czynników modelu. D okonii jaki to będzie miało wpływ na
' Zmtmwm, m,
Broekst,;y- O pisz firmę w kategonad W 1 tych czynników i ocet
P0“ ? * «y»nM rood^u.
O m ó w isto tę e ta p ó w w z ro stu p o zio m u in fo rm aty k i R. N olana w p rz ed sięb io rstw ie Z in te rp re tu j p o s z c z e g ó ln e etap y na p rzy k ład zie firm y p o lsk iej. C z y m j est re s tru k tu ry z a c ja p ro c e s ó w g o sp o d a rc zy c h ? C ze m u zaw d zięcza ona sw o ją p o p u la rn o ść ? jsja p o d s ta w ie o p is ó w
rz e c z y w isty c h sy tu acji p ro b lem o w y ch zaw arty ch w p o lsk iej
ed y cji „ C o m p u te r w o rld ”
lu b innej lite ra tu rz e spróbuj o k reślić, do jak ich rezultatów
d o p ro w a d z i o d p o w ie d ź n a p y ta n ie „ Ja k m o ż n a ro b ić szy b ciej, lepiej, ta n ie j? " , a do ja k ic h „ D la c z e g o ro b im y to , c o ro b im y ? ” . W n a w ią z a n iu d o p o d a n e g o w y żej p ro b lem u w ypełnij konkretnym i w ynikam i tablicę 2.4 N a p o d s ta w ie
o trz y m a n y c h
w p y ta n ia c h
14 i 15 rezu ltató w
zw ery fik u j p rzeb ieg
re s tru k tu ry z a c ji p ro c e s ó w g o s p o d a rc z y c h iry s . 2.14). Ja k ie w' T w 'o jej o c e n ie s ą n a jw a ż n ie js z e a k tu a ln ie in fo rm aty czn e stym ulatory z m ia n '
V
Rozdział 3
Strukturalna analiza i projektowanie systemów i n f o r m a t y c z n y c h
3.1. Analiza systemów informatycznych O ptM M *» » P ' ^ ' K j la/ie t ^ r / e m . . s y s te m * m lorm m yc/m c m toplan d aje p . x i. u » i do /a m .c j.m .m ra a n u h /> ->slcmu I la n o « .,, iw t ó n ió »
* u u * s if /
c a ło ś c io w y m
.p o jr /e n ic m
n a lo m ia sl p rzed m io tem
a n a h /y je s !
w y b ra n a
n a d a n ą o rg a n ,/a c ,
d /te d z m a
p r /e d m io u » .
w ybrana J o m S m u ñ z a c ji. R e /u lia te m p iz e p ro w a d z e m a a n a liz y je s i d eliran p o trze b u z> tk o w n ik a , to lo / czasem nazw \
u
lite ra tu rz e
a n a liz a p o trzeb u /U k o w n ik a ta n g .
u/\wa
s ię
/a n u e n r
u.wr reipurements amdysii
N a /u a ta p o d k re śla ce n tra ln ą ro lę . ju k ą v\ tej t a /ie
a u
k o n se k w e n c
w c a lv m p re ve s te tw o rze n ia - o d g ry w a u ż y tk o w n ik .
Analiza poleca w praktyce na pr/eprow ad/eniu studium /agadnif związanych zarowno z działalnością gospodarczą danej organizacji, ja i z wspomagającym ią. planowanym sw tem em inform atycznym . W istoe, h.tda się rozwiązywanie prohlemow gospodarc/vch i organi/acyjm c firmy w sposób me/uleżny t*l technologii inform atyc/nej. Podstawowyn czynnościami w fazie analizy są. identyfikacja i charakterystyka problemów i celów , studium dziedziny przedmiotowej opis istniejącego systemu. systemu intonnaiycznego. • delinicja i ustalenie priorytetów zidenty fikowany ch p o trzeb użytkownilł I o wybraniu, na podstawie wniosków w ynikających z inioplafiS dziedziny przedmiotowej przeznaczonej do in fo rm aty zacji, następuj identyfikacja problemów gospodarczych i organizacyjnych, a także id a^rega^ja w w iększe grupy problemowe. Rzutują one na określenie celó* tworzonego systemu, do czego niezbędny jest szczegółow y opis tunl ¿jonującego systemu w postaci studium dziedziny przedm iotow ej w katf e,onac metodyki strukturalnej, obiektowej bądź społecznej. U stalone ceł lezący porównuje się z możliwościami i ograniczeniam i technicznym 64
organi/acyinym i. prawnymi i ekonomicznymi firmy. W takim studium w ykonalnosci system u do przybliżonego ustalenia kosztochłonności i ptuciK h ło n n o su przedsięwzięcia projektowego w dużym zakresie są w y kor/y sty w une modele proeesow i danych, opracowane w trakcie studium dziedziny przedm iotow ej. W przypadku akceptacji wymagań wynikających /c studium w ykonalności, analizę finalizuje definicja potrzeb użytkownika, dokonyw ana głow nie za pom ocą metod modelowania danych i procesów i prototypow ania. D o k u m e n ta c ja potwierdzająca realizację powyższych c/ynnosci analitycznych w raz z inloplanem staje się podstawą zainicjowania projektow ania systemu. A nalizę przeprow adza się metodami: • analizy sytuacyjnej. • m odelow aniu i prototypow ania systemów, W pierw szej grupie wyróżnia się zarówno metody tradycyjne, jak i now oczesne. Do tradycyjnych należą wy wiad, kwestionariusz, obserwacja i analiza dokum entów . Użytkowanie każdej / tych metod od strony m erytorycznej, organizacyjnej i psychologicznej zostało szeroko om ówione w adekwatnej literaturze. Znajomość tych metod stanowi niezbędny składnik wiedzy i um iejętności praktycznych analityka systemu. Metody nowoczesne wiążą się z podejściem heurystycznym ; w ykorzystują (omówione w rozdz. 2) takie techniki, jak burza mózgów. SW OT, sesja MetaPlanu czy JA D (ang. Joint Application l)evt'lopment). / kolei modelowanie i prototypowanie sa*W e m o w w iąże się / m etodam i i technikami, właściwymi dla podejść: strukturalnego, obiektow ego i społecznego. Analiza złożonych dziedzin p r/ed m io to w y ch w ym aga komplementarnego stosow ania technik analizy sytuacyjnej, m odelow ania i prototypowania. Metody te często są wspomagane kom puterow o przez odpow iednie moduły pakietów CASE. Pierw szą czynnością w fazie analizy jest studium problemów badanej dziedziny przedm iotow ej. Chodzi przede wszystkim o problemy gospodarcze, organizacyjne i m enedżerskie. W ich identyfikacji bardzo użyteczne są zw łaszcza m etody w yw iadów oraz różnego rodzaju warsztaty z udziałem kierownictwa firm y, użytkow ników oraz informatyków.. Problem y te są następnie agregow ane w tem atyczne grupy, szczegółow o charakteryzow ane w postaci tabel problemówjyb wzbogaconych wizerunków , om ów ionych w rozdz. 6. Z identyfikow ane w trakcie tego studium problemy pozw alają na określenie celów system u. Tak więc, tworzony system pow inien wspomagać realizację ustalonych celów i przyczyniać się do rozw iązyw ania
bądź ograniczania występujących trudności. Zdefiniowanie potrzeb użytkow nika jest możliwe, dzięki opracow aniu studium i charakterystyki dziedziny przedmiotowej. Służy tem u całe spektrum metod szczegółow o om ów ionych zarów no od strony teoretycznej, 65
. „ ro7d7 4-6 Naturalnie dominują diagram y przepływów jak i zastosowań w rozdz . * o Użyteczne mogą okazać Slt danych oraz diagramy z 4• s)ownjki/skorowidze danych, relacyjna wzbogacone w żerania gmry decy7yjnCi diagram y struktury cz, i obiektowe modele da . wvjścia 0pisu system u je st dtagratr, S
X
r S
a n y
następnie do szczegóiowej prezentacji da„ycl
1P
a t e n i e problemów występujących w przedsiębiorstwie, id e n ty fik u j Im fom atv/acji oraz opis dziedziny p rzedm iotow ej s t a j , Slj M d a w a opracowania studium w ykonalności sy stem u w a s p e k j i " k a d r o w y c h , materialnych i finansowych organizacji Studiu, S a Się z czterech części, oceniających w ykonalność system u poc względem: • technicznym. • organizacyjnym, • prawnym, • ekonomicznym. Zagadnienia możliwości realizacji systemu z zastosow aniem dostępne technologii informatycznej - sprzętu, oprogramowania i sieci komputerowych - oraz dokonywanie niezbędnych analiz porów naw czych parametrów technologii stanowią treść technicznej części studium. Z kolei wykonalność organizacyjna polega głównie na ocenie potrzeb zm ian struktur or ganizacyjnych i kwalifikacji pracowników. Zgodność zasad działania systemi z obowiązującymi przepisami prawnymi oraz konieczne je g o modyfikacje dotyczą wykonalności prawnej. Zazwyczaj wiele dyskusji, emocji i kontrowersji w yw ołuje kwestii wykonalności ekonomicznej. Nie brak propozycji i form uł liczenk ekonomicznej efektywności komputeryzacji firmy, z uwzględnieniem różnycł rodzajów kosztów i wyników finansowych. Praktyka dow odzi, iż trudne przeprowadzić tego typu rachunek ekonomiczny. O ile bow iem stosunkowe łatwo określić koszty systemu, o tyle oszacowanie efektów sprawia poważne trudności. Nie bez znaczenia jest też wpływ szybko zmieniającej się, jut w trakcie tworzenia systemu, technologii informatycznej. Skuteczność przedsięwzięć informatycznych należy oceniać przede wszystkim przez pryzmat podniesienia konkurencyjności firmy na rynku, a także utrzymani; !ub podniesienia jej zyskowności. ~~
cMnnnnlri
uż>rt^ zne są natomiast metody szacow ania pracosystemu N-'iwl wcnc^ ^oszti>chłonności projektow ania i wdrażani' systemu. Najbardziej znane są tu dwie m ito d y • C A W UM-° O MUngo t nConstructive r ^ Cj0"alnyChCOst 5 * -MOdel). (a" g: Punc,ion P° in'
66
Bardziej zaawansowana jest metoda analizy punktów funkcjonalnych, jej założeniem jest określenie liczonej w osohodniach pracochłonności tworzonego system u na podstawie - w przeliczeniu na punkty jego zakresu (wielkości) oraz złożoności. Zgodnie z dokonanym uprzednio szczegółowym opisem systemu wyodrębnia się pięć elementów: jego wejścia, wyjścia, zapytania, interfejsy i logiczne pliki danych. Pomocniczą rolę w ich identyfikacji mogą odegrać diagramy przepływu danych. Ocenie punktowej podlega również stopień złożoności poszczególnych składników opisu systemu, z podziałem na proste, średnio złożone i złożone. Każdy z wyodrębnionych składników oceniany jest według zawartej w odpowiednich tabelach skali punktów funkcjonalnych, uwzględniających liczbę pól lub atrybutów oraz liczbę odwołań do tych grup danych. Określona w ten sposób liczba punktów funkcjonalnych danego składnika jest dodatkowo korygowana o różne parametry wpływu, takie jak wpływ urządzeń kom unikacyjnych, rozproszenia danych, częstotliwości wykonywania transakcji i innych. Skorygowane punkty funkcjonalne netto, dotyczące poszczególnych składników zostają zsumowane. Na podstawie doświadczeń praktycznych zakłada się, iż jeden punkt funkcjonalny netto odpowiada 8 godzinom pracy w technologii języków trzeciej generacji (3GL) lub 1,5 godziny pracy w technologii języków czwartej generacji (4GL). Wyliczenia te pozw alają więc na określenie nakładów czasu pracy, a w konsekwencji kosztów w drożenia systemu. Należy zwrócić uwagę na znaczną praco chłonność dokonanego szacunku, który mimo dokładnych miar oraz w spółczynników korekty ma charakter przybliżony. Wydaje się, iż może on mieć zastosow anie w przypadku tworzenia dużych systemów, związanych z poważnymi nakładam i finansowymi. Z nacznie prostsza w swej konstrukcji jest metoda COCOMO. Daje ona jednak na ogół gorsze wyniki, a stopień przybliżenia jest znacznie gorszy. Z asada obliczania pracochłonności opiera się na oszacowaniu liczby linii k o d u niezbędnych do wdrożenia projektu. Ich liczba pozwala z kolei na określenie pracochłonności realizowanego projektu. Finalne rezultaty fazy analizy to identyfikacja i modelowanie potrzeb u ż y tk o w n ik a . Ich określeniu służy cała gama metod tradycyjnych i heurystycznych. W yniki wywiadów, kwestionariuszy, obserwacji, analizy dokumentacji, w arsztatów , burz mózgów skonfrontowane z celami projektu i jego opisem pozw alają zdefiniować potrzeby użytkownika. Definicja potrzeb może być oparta n a analizie procesów bądź „danych. Pierwsze z.podejść zbudowane jest na modelu: wejście-proces-wyjście. Formalnym ujęciem tego typu definicji potrzeb jest IBM-owska metoda Hli O Nf c.» wejście-proces-wyjście są przyjazne wobec użytkownika w zwią/ku z łatwością i przystępnością ich tworzenia. Ponieważ zarówno za. es. juk
.n u d a c h i specyfika procesów w org
Się zestaw procesów.
gospodarczych zmieniają się * sję stwor7xnie modelu
*
wykorzystywane pracz ™ » a W ,
k
Vstywać metody scharakteryzowane
mr S
p
rC
T
U h tS
sysumów.
° kazać
ż ™
cyklu życia systemu. Wyniki modelowania —
neg
Tak zdefiniowane p Z z e ^ i ^ o w ń i k a ^ ą uporządkowane, tj. ustala się « “ ntet żuje w postaci spójnej specyfikacji analizy systemu, duża,lej do opracowania jego projektu. Syntez« zasad , rezultatów analiz, systemów przedstawia rys. 3.1. Dziedzina przedm iotowa M etody:
I
• analizy sytuacyjnej =» tradycyjne =» nowoczesne • projektowanie systemów =# strukturalne =» obiektowe =*>społeczne • prototypowanie • pakiety CASE
Analiza Systemów Informatycznych
Dokumentacje Problemy i cele
Opis systemu
Studium wykonalności systemu
Potrzeby użytkownika
Rys. 3.1. Zasady i rezultaty analizy systemu
3.2. Zakres strukturalnego projektowania systemów bvć wnmw°HWJniC defjmu-ie się Ja^° Przygotowanie zmiany, która C/ a s i e M 5 - ™ ° w f Ślonym obszaize o czy w isto ści i w określon isto tL nmwL ", lWOrZCnia Systemów ^formatycznych projektowe zi do znuan zarowno w funkcjonowaniu, jak i w obsłu«
\
informatycznej danej dziedziny przedmiotowej. Projektowanie systemów informatycznych w swej istocie polega na ocenie opracowanych w trakcie fazy analizy w ariantów rozw iązań problemu, a następnie opracowaniu struktury funkcjonalnej i związanych z nią szczegółowych specyfikacji Inform atycznych dla wybranej wersji systemu. Powody, cele i potrzeby zmian występujące w działalności gospodarczej i administracyjnej danej organizacji zostały określone we wczesnych fazach cyklu życia systemu, przede wszystkim w fazie planowania. Specyfikacje przyjmują postać projektu systemu, który obejmuje określenie wejść i wyjść systemu, jego plików i bazy danych, procesów, a także interfejsu użytkownika. Tak zaprojektowany system informatyczny powinien służyć realizowaniu celów zdefiniowanych w fazie planowania. Po czym musi zostać zintegrowany z istniejącym środowiskiem gospodarczym i infrastrukturą informatyczną firmy. W licznych metodykach tworzenia systemów informatycznych, zarówno o charakterze teoretycznym , jak i pragmatycznym, faza projektowania składa się z szeregu etapów, podetapów i zadań. Przyjmuje się najczęściej, że istnieją dw ie główne fazy_proj ekto wąnia; "• p ro jek to w an ie ogólne (zwane również logicznym albo wstępnym), • projektow anie techniczne (zwane również fizycznym). . W rezultacie uzyskuje się projekt ogólny oraz projekt Techniczny. W projekcie ogólnym zarówno struktura funkcjonalna, jak i poszczególne specyfikacje przedstaw ione są w sposób niezależny od konkretnego, dostępnego na rynku sprzętu i oprogramowania. Z kolei w projekcie technicznym następuje przekształcenie technologicznie niezależnych fikacji projektu ogóinego w specyifikację dopasowane do wybranej nołogiiTnfórniatycznej, uwzględniającej sprzęt, oprogramowanie, bazę d an y ch isrecT ćo m pu terową.. Składnikami pierw szego z projektów są: • ocena i w ybór wersji systemu, projekt struktury funkcjonalnej systemu (koncepcja systemu), projekt w ejść i wyjść systemu (formatki i zestawienia), projekt dialogu użytkow nika z komputerem, czyli interiejsu użytkownika, projekt logicznej bazy danych, integracja składników systemu z kontrolą spójności i kompletności projektu.
Projekt techniczny obejmuje: projekt fizycznej bazy danych i plików danych, ę projekt struktury oprogram ow ania i poszczególnych programów, projekt rozproszenia system u, czyli dostępności zasobów danych i oprogram ow ania w sieci komputerowej. Podjęcie właściwych prac p r o j e k t o w y c h poprzedza ocena W ™ » ™ * wersji systemu. C zynność ta polega w głównej mierze na i en }
09
. ń , zakresu technologii i systemów i badaniu różnych " ariam0" ^ ' ' ^ i e d / na sformułowane w fazie analiz, infomtatycznych. stano» iac> P> ^ wvb 6 r opiera się na ocenie
problemy. Najlepsze, według przyjętych kryteriów uvkonalnoŚci ykonalnosei proponou propoiw’« an. ^ 1. ^ . k(ottM ta, WanantY Warianty rozwiązań na rozwiązanie staje « t i ^ |nw¡ci proponowane są » zespole projek. pożądanym poziomi (W nic|w0 ftnnv. użytkowników, analityko« towym. < * 9 « W > ‘ |e w „wzeledniac ¡śmiejące w organizacji , projektantów- P i P1^ ^ iospodarcze. Kandydujące rozwiązania nfzraniczenia technologu./nc _ __ n ; S b ujednoicons' opisuje sie i charakteryzuje, a nastepn e o c e n , » r z z udziałem profesjonalnych ekspertów. Naturalnie najistotmejsze są kryteria wykonalności., które można rozpatrywać w czterech p ła sz c z * , ujch i 10?, s 4 ’ | jako. . • wykonalność techniczną dotyczącą technicznych i kadrowych możliwości
realizacji propozycji, .. . wykonalno» funkcjonalną, czyli ocen« stopnia realizacji specyfikacji potrzeb, sformułowanych w ta/ie analizy. • wykonalność ekonomiczną, polegającą na określeniu efektywności rozpatrywanego wariantu - porównaniu jego kosztów i elektów , • wykonalność terminową, uwzględniającą akceptowalny horyzont czasowy szczegółowe termirn w \ konania zadań cząstkowych, kontrolowanych w punktach przeglądu. jak również zasady kierowania i harmonog ramów ania prac. Oceny są rozpisywane w postaci m acierzy porów naw czej. Zawiera ona analizę wykonalności każdego z wariantów w kategoriach czterech powyższych kryteriów. Do oceny rozwiązań niezbędne jest przyjęcie określonej skali ocen i wag dla każdego kryterium w celu ich porównania. W pierwszej kolejności odrzucane są propozycje niewykonalne. Ostatecznie zespól projektowy zleca do wykonania rozwiązanie spełniające najlepiej kombinację wymienionych wyżej kry teriów wykonalności. Jest to koncepcja systemu. Zawiera ona określenie celów systemu, dekompozycję w postaci hierarchii podsystemów i funkcji, opis ich zakresu, oszacowanie wielkości systemu. Przyjęcie przez kierownictwo firmy tej koncepcji oznacza nadanie impulsu pracom projektowym w celu stworzenia nowego systemu i zinteg rowania go z istniejącymi w firmie procesami i strukturami. Zaproponowany sy stem inożna albo kupić, jako najbardziej dopasowany pakiet zastosowań, alto tworzyć ud podstaw według określonej procedury projektowej.
yuKtn^nJÍ' Tm e?
S*ę na za*cuP gzow ego systemu, czyli pakiet« mniej złożon ^ P 1 a ^ ^ t0 W zasadzie reg ute w odniesieniu do Z o m l l Z l t SyStef W‘. P“ w P ^ P a d k u systemów złożonych. g J4 y zarządzanie dużymi organizacjami gospodarczymi sięga 70
Się po zintegrowane systemy klasy ERP (dawniej MRP II). Istnieje aktualnie bardzo bogata oferta pakietów zastosowań na rynku oprograniowama. C zynności wiążące się z tą decyzją to: identyfikacja pakietów zastosowań, które pozwalają na realizację koncepcji systemu, analiza porównawcza i ocena wykonalności tych produktów, wybór określonego pakietu, negocjacje z dostawcą bądź producentem oraz zawarcie kontraktu i wreszcie ustalenie zasad wdrożenia wybranego systemu. Zarówno więc opracowanie koncepcji systemu, jak i jego wdrożenie wymagają prac projektowych i wdrożeniowych (o różnym zakresie dla poszczególnych pakietów) o charakterze metodycznym, a więc metod, technik i narzędzi właściwych dla przypadku niezależnego tworzenia systemu. Stąd wynika ich uniwersalne znaczenie.
3.3. Projekt ogólny W przypadku wyboru ścieżki metodycznego tworzenia systemu informatycznego, wszystkie czynności projektowania ogólnego wykonywane są przez, w łasny zespół albo przez firmę-zleceniobiorcę (ang. outsourcing). Po dokonaniu w yboru wersji systemu na podstawie pozytywnej oceny jego wykonalności należy zrealizować całą sekwencję czynności o charakterze projektow ym , które pozwolą na wdrożenie koncepcji systemu. Pod stawowymi składnikam i tej koncepcji są: • dekom pozycja funkcjonalna systemu, • projekt modeli danych, _ • projekt modeli procesów. Projekt ogólny systemu stanowi swoistą syntezę opisu dziedziny .przedm iotow ej - je s t opracowaniem całościowej, m odularnej stru k tu ry ■projektowanego systemu, wykorzystującym wdrażalne modele danych i procesów. Struktura systemu przedstawiona jest w postaci diagramów dekcTfapdzycjiTunkcjonalnej bądź zależności funkcjonalnych oraz macierzy zależności procesy-dane, om ówionych jako metoda BSP w podrozdz. 2.5. i 2.6. Z aproponow ana hierarchia służy jako przewodnik w podejmowaniu kolejnych czynności projektowania ogólnego, a następnie projektowania technicznego. Techniki służące do modelowania danych na poziomie projektu ogólnego to: modelowanie związków encji na oraz słownik//skorowidz danych. Projektant - znawca technik - i użytkownik zorientowany w specyfice dziedziny przedmiotowej opracowują modele opisujące zasoby danych, niezbędne w projektow anych procesach, wyodrębnionych w trakcie dekompozycji funkcjonalnej. Modele te są tak opracowane, aby umożliwić 71
.
. „ „ w e n i e plików danych lub bazy danych systemu. związków encji oraz słow ników /skorow idzów da„ych
scharakteryzowane sti w wtpomaganiu działalności gospodarczej Funkcjonowante sytem u we procesów (funkcji)' W y ^ W o n e w S i e dekom pozycji procesy s , szczegółowo opisyw a„e, a p określą się niehierachiczne zwittzk. pomtędzy m m .. Dogodnymi narzędziami realizacji czynności modelowama procesow są omowtone ^ o d r o z d z . 4 .3 i 4 .4 techniki diagramów prz.epływu danych oraz grafó» ISAC-u wzbogaconych o7estrukturyzację procesow gospodarczych (podroż*. 2 6 ) słowniki/skorowidze danych (podrozdz. 4.5) oraz technik, decyzyjne (p o d ro zd r 4 7). Podobnie jak w przypadku projektu m odelu danych, w fazie projektowania procesów stopień precyzji, niezawodności, a przede wszystkim wdrażalności wyspecyfikowanych procesów musi być znacznie wyższy w porównaniu z modelowaniem danych czy procesów, realizowanym w fazach planowania i analizy systemów. Z koncepcją system u w iążą się podstawowe składniki projektu ogólnego, a więc jeg o w ejścia i wyjścia,
dostępne w postaci elektronicznej zamówienia, formularze przyjęć pracow ników, dokum enty obrotu materiałowego. Współczesne formatki poza częścią zn ak o w ą m ogą zaw ierać elem enty multimedialne - eraficzne i dźw iękow e. Z kolei zestawienie (lub formatka wyjściowa) jest dokum entem pasywnym , który zawiera tylko dane wcześniej zdefinio w a n e , , generow ane stosownie do przyjętych algorytmów przetwarzania. Zestawienia m ają postać elektroniczną albo papierowych wydruków użytkowych do:
• generowania dokum entów wewnętrznych i zewnętrznych, jak listy płac. faktury czy dokum enty obrotu towarowego. • zestawień o charakterze zbiorczym, porównawczym, służących prze glądaniu - zawierają one dane przenoszone bezpośrednio lub przetworzone z wielu niepow iązanych rekordów lub transakcji. Formatki i zestawienia projektuje się w procesie prototypowania w wyniku dialogu z użytkownikiem i z uwzględnianiem jego oceny. W stępnie określone m akiety formatek i zestawień ulegają stopniowemu uszczegółowieniu. Narzędziami wspomagającymi ich projektowanie mogą być pakiety C A S E (rozdz. 7) i generatory zastosowań, zawierające m.in. •interfejs użytkownika i model bazy danych. generatory form atek i zestawień (podrozdz. 1.4). Informacje zawarte w form atkach i zestaw ieniach mogą być zaznaczane przez podświetlenie, migotanie, kolor, rozm iar czcionki, wprowadzenie ramek, grafiki, głosu 3.4. Projektowanie wejść i wyjść systemu czy dźw ięku. G eneralną zasadą projektowania formatek i zestawień jest ich użyteczność m ierzona| *szybkością Wejści a j_ jw y jś d a ^ s te m ó w ^ p fo rn m ty c z n y .c h w zastosowaniach " i ,, ■■ir ^1dostępności m m lanmmdanych, ich dokładnością iti»■■-oraz zaakceptow anie przez klienta. gospodarczych mają postać formatek ekranowych i zestaw ień generowanych Źródłem inform acji wejściowych są operacje gospodarcze.Informacje na drukarkach, monitorach, ploterach. W związku z interaktywnym te są zbierane na dokum entach źródłowych lub wprowadzane bezpośrednio charakterem współczesnych systemów oraz stałym rozw ojem technologii do system u kom puterow ego. W związku z tym wprowadzanie danych informatycznej zanikają tradycyjne postaci wejść i w yjść, związane wejściowych m oże mieć charakter wsadowy lub bezpośredni. Pierwszy z projektowaniem dokumentów źródłowych, m aszynow ych nośników informacji czy tabulogramów. Formatki i zestawienia są id e n ty fik o w a n e ^ , przypadek dotyczy dokum entów źródłowych, użytkowanych do przeno szenia zarejestrow anych informacji, na ogół na magnetyczne nośniki w trakcie fazy analizy i projektow ania og ólneg o, ze w zg lęd u na danych, które pozw alają następnie na wprowadzenie danych do komputera integralny zw.ązek z diagramami przepływów danych. T a k w ięc, każdy i ich przetw arzanie. Dane uporządkowane są w ustrukturyzowane kolekcje, n z tr ll yCh' Stan° WiąCy WejŚde d0 Pro c e su ’ j « « kandydatem przetwarzane w ustalonych m om entach czasu, zachowują aktualność przez kandydatami ^ ejSCI0Wą\ wyjści°w e przepływy danych z procesu są określony czas. W prow adzanie transakcji polega na wypełnianiu form atek Pomocnicza role°oflZeSta< Wle!i- tabelarycznych b4d i w yjść graficznych, wejściowych zaprojektow anych z uwzględnieniem układu pól danych danych, które u m S r ^ iagfamy zvvi4zków encji i słowniki/skorowidze ^ określonego dokum entu źródłowego, a także typu i zakresu tych danych. i wyjściach 1WłaJ4 określenie struktury danych w wejściach Przykład form atki wejściowej, pozwalającej następnie na opracowanie faktury w system ie D ynam ics firmy Great Plain Software, przedstawia
już ws ™ „ t^ d S w In ąeJea peWne wprowadzone. D ane te “ PUbte-Pok-Jia dane, które winny być stosownie do przyjętych nr r<^ estrowane fSGBgfc użytkowników systemu' Przyjętych procedur przetwarzania. Przykładami formatek są 72
rys. 3.2. U żytkow ane przez wiele lat nośniki papierowe zostały zastąpione pr/e nośniki m agnetyczne - przede wszystkim dyski magnetyczne i optyczne.
Uraewg**
dokumentu
Kńęgui
Tiantfgf
MA02HANDL m
____
FAXTVAT
Faktura
FAV9a'00001
PZ ALKA
ALMA Numer pozycji
[Upust
Opis
Ł illo ś ć anulowana
Ilość zrealizowana
ilość zafaklurow Tibść poświadczona liośc dozam zal
C e n a je d n sprzedaży
Wartość netto sprz Cenajedn zakupu
HAN-8CEM ÖT C em enlA R *70
HAN-M00-O2 Biurko 1003 Razem
jj& u H ig i
Cl
...
'
I
1.60 Zł 64 792.50 Zł
Ogółem
V¿$irzyrr>arMZi
Wtes/w
Dekjełacia
Prowcąe
j
Rys. 3.2. Formatka wejściowa
a komputery stacjonarne przez sieci komputerowe. Sprzyja to wprowadzaniu danych w trybie bezpośrednim, które dotyczy szybko zm ieniających się danych o niestabilnym formacie. Ten tryb umożliwia bieżące wprowadzanie danych, najbardziej aktualnych i pożądanych w procesach przetwarzania podejmowania danych realizowane -i ^vjiuw »»u,uu decyzji. Bezpośrednie wprowadzanie wjjiuwau/.ctme uanycn IC S t nonrzez s ip . H n m n n tp m u /p ii 7zainstalowane Qini’tnlrvufnn,% w nich _ _ ______ jest poprzez sieci Lkomputerowe profesjonalne .terminale - mikrokomputery i stacje robocze. Specjalistycznymi urządzeniami bezpośredniego wprowadzania,danych,.o dłuższej ju ż tradycji, s ą c z y im i P,s m.1 5 £ty.czpego-i-ruagnęjy.czjąęgp., ,s;t„ „, -kodu.kreskowego ,w handlu detalicznym. T* \ 1
F Y 1
O
/ A
f
t
»
M
a
M
_
a
Najbardziej widocznym składnikiem systemu inform atycznego, uzasadZ
jest wyjścis systemu. Stanow i ono podstawę g ą a ę k ce p ta cj; fu n k cjo n o w a n ia systemu. Wyjście przekazuje informacje dostarczane użytkownikom systemu. Realizacja celów firm y i jego r
: y7
r
eg0
r
-
^
7 konanie ^
« s ys t emu- zakr es 1 ^ ,ko“ p,ikó" wej są różnorodne, podobnie iakWyftenerOWan,.,a m fornlacj ‘ wyjścl°' pozwalających na opracowanie wyiść - ‘T ł Zł° zo n o ści algorytmów * przesyłania przechowywanych danych ń u Pr°,Ste8° w yszukiw an'i obliczeniowych. skom plikow anych procedur 74
"
Wyjście m oże mieć charakter zewnętrzny lub wewnętrzny. Informacja przesyłana n a z e w n ą trz systemu inicjuje działania u jej odbiorcy lub potwierdza realizację czynności na rzecz odbiorcy. Wyjścia zewnętrzne jinaożliwiąją proces komunikowania się firmy z urzędami, klientami, dostawcami i konkurencją. W y jś c ia jw y r a jtr^ n ę przekazują informacje pozostające w ew nątrz systemu do wspomagania działalności firmy lub instytucji - przeznaczone dla kierowników działów i bezpośrednich użytkowników. Przykładami wyjść zewnętrznych są faktury, czeki, rachunki telefoniczne, oferty, bilety lotnicze, sprawozdania (miesięczne, roczne) dla urzędów i instytucji. Z kolei wyjścia wewnętrzne to różnego rodzaju zestawienia, w ydruki szczegółow e i sumaryczne, dokumenty obrotu materiałowego, odpowiedzi na zapytania, sygnalizowanie odchyleń. Istnieje również klasa w yjść zewnętrznych zwrotnych, zaprojektowanych jako częściowo w ypełnione formularze, generowane przez system. Po zainic jowaniu przez taki dokum ent transakcji (np. płatności) zostaje on uzupełniony przez jeg o odbiorców, a następnie stanowi wejście do tego samego lub innego systemu. Przykładem może być formularz zmiany adresu klienta firmy lub potwierdzenie udziału klienta w akcji marketin gowej . Inform acje w yjściow e mogą mieć różne form y i postacie, mogą być prezentowane na różnorodnych mediach i nośnikach. Najpopularniejsze to naturalnie w ydruk tekstu czy grafiki na drukarce bądź wyświetlenie na monitorze. F orm at w yjścia w tym przypadku może być: • tabelaryczny - prezentacja informacji w postaci kolumn liczb i tekstu, • strefowy — um ieszczenie danych w różnych streiach wydruku lub formatki ekranow ej, • graficzny - prezentacja materiału statystycznego w postaci różnorodnych wykresów (form a graficzna jest powiązana z tabelaryczną) czy grafika prezentacyjna, • narracyjny - opis w postaci standardowego tekstu. Przykłady najczęściej użytkowanych wyjść - tabelarycznego i graficz nego — przedstaw iono na rys. 3.3 i 3.4. Z kolei rys. 3.5 zawiera różne formy graficznej prezentacji materiału liczbowego w systemie MS EXCHL.
3.5. Projektowanie interfejsu użytkownika Sposób prow adzenia dialogu, komunikowania się człowieka z k puterem, m a coraz w iększe znaczenie, bowiem dotyczy w s/y s u. użytkowników kom puterów , niezależnie od wykształcenia czy wie ^ informatycznej. W ydłuża się też czas dialogu użytkowni u / omp W prowadzanie transakcji, użytkowanie baz danych, praca poprze/ 75
Stron*»
USTAFCllCJl
juuuprox*«i
v\J
f*l?M>
ri#rv^ry ner«:**
3jvf*p9W «)i uimpwyd1
htW
rtccvassr
Pierwsr*
C * U liO fta tt: O ta tM CstatM C*t*5tU
pień»**
yoe. fOS>Cjl $;» pojjrcji
swroiTio
!C u ly tk o -n li* »
jicítg&t
ocík: r**rcł#
•.iamijł d?łt**CY Crapa «awt.setaftt podatku
tvr.fíjl ryr iw l»y
•a i d # !*T U o i:
2« * S .
IlcJĆ fądan*
Sciłcaat ceny
m
Karva dCJta^oy
K « tr poxy
ÍC BW L&-JOO BWł-n*-«
Prowisjt
o szczegół
r.-viL'ii cu jj:i?
Pw. ujarya.wa
fc:. UJKJWI
Klawiatur*^ic¿s> $SIcys
c s:c:cau
Ifceltcr Irłdg e SVGA Color 1
Ner.ltar SCtff G »-:00Cr: ? r:# ltfo a
c sćczrau
Siudo 1002
20: BIURO m
WH-łas-02 For. ŁijaryB rw
i l 2AGR. ARGC
Siudo 1003 22S H U K HAtOLU ZAGR. ARGO
01
for. **3*:}3cwi
0
SZCttSÓL
0
SZCZEGÓŁ
RI-Biur-1003
Kr: w ic obrotowe XL ICO 110
BIURO HANDLU UCR. MCC
Rys. 3.3. Tabelaryczny fomiai wyjścia
pochłaniają niemal cały czas pracy użytkownika profesjonalnego. Dla społeczeństwa globalnej infom^cii In m n T J— ‘- 6 i pracy. W zastosowaniach eosnorh - i . u* StajC Się narzędziem naukl
{yiko zastosowań podstawowych, ti eźąca interakcja dotyczy nie ypomagą.iia decyzji, systemów 4 ^ ^ . * ? “ala^ n^ * UłSS0BÓ* ĄwffljJlOWMlia lnftrou/nir^Hi/o wnictwa oraz ct/ctemÓW systemów 76
Rynek inform atyczny w w ybranych krajach
Europy Centralnej: 1994 -1 9 9 8 ( w ielko ść sprzedaży w m ilionach $ )
Czechy Polska Słowacja Węgry
Rys. 3.4. Graficzny format wyjścia
W yb ierz ły p w y k r e s u
Pierścieniowy
Słupkowy
Kolumnowy
Liniowy
Kołowy
Radarowy
Punktowy (XY)
Złożony
Warstwowy 3-W
iL Słupkowy 3-W
Kojumnowy 3-W
Liniowy 3-W
Kołowy 3-W
Powierzch. 3-W
/
< Wstec2
Rys. 3.5. Rodzaje graficznych wyjść systemu MS EXCKL
, . znaczenie interfejsu (inne polskie nazw y: sprzęg, ekspertowych. Stąd znacz ;k~ wnika, czyli technicznego sposobu k łącze, orczyk me pr z yj ę - _ .^ wiadaj 4Cego mu oprogramowania j^(zącji_dialogu czło*tek •. niezawodną interakcję człowieka umożliwiającego sprawną. 4 e ty c z n y m . z komputerem czy systemem^^ne & wła“ r r r . - ? S T S b - perforowane, taśmy magnetyczne, d r a k a * . bębnow e. Nie istniaiv wtefv interfejsy użytkownika, bo me było tn.erak.ywnych użytkowników (i odwrotnie). Druga generacja m terfejsow funkcjonowała Od' wczesnych lat sześćdziesiątych do w czesnych osiemdziesiątych. Bvły to terminale wielodostępnych systemów informatycznych. Użytkownik mógł kontaktować się z komputerem w trybie p y tan ie-o d p o w ied ź albo poprzez polecenia zawierające określone parametry. U m ożliw iały to systemy operacyjne DOS oraz Unix. Ten sposób kom unikow ania się ma nadal zastosowanie w mikrokomputerach oraz w sieciach komputerowych. Trzecia generacja interfejsów powstała dzięki pracom badaw czym pro wadzonym w latach siedemdziesiątych przez laboratorium badawcze firmy Xerox - PARC (Palo Alto Research Center). O pracow ano tu graficzny interfejs użytkownika W IM P. Znaczenie poszczególnych liter jest następujące: W - Windows (okna). I - Icons (ikony). M - Menus (menu), P - Pointer (kursor, urządzenie wskazujące).
Standard WIMP stanowi syntezę popularnych, graficznych i znakowych form i n terakcji człowieka z komputerem, om ów ionych szczeg ó ło w o niżej ozwiązanie to zostało spopularyzowane w system ie o peracy jn y m mikrokomputerów McIntosh System 7 w 1984 roku [69], a następnie w mikre 'omputerac PC w systemach operacyjnych W indows, a także M otif nt stacjach roboczych Unix.
u ż v tk ™ „ tl f " erf ja u dominuje dotychczas w zakresie
interfejs*
wady standardu W IM ^ eglem CZ3SU wskaz3'w an0 na następujące główK *
p r a k ty c e ^ o b o w ia /^ '
p ra e k ra C 2 a « c «
zbyt wiele czasu na man
W na istocie zastosowana;0**01”
P o trz e b y
u ż y tk o w n ik a
(»
funkcJonaln4 użytkow nicy s p ę d z i
interfejsu,.ajiie koncenti#
• W lM P był pom yślany do zastosowań dwuwymiarowych, jak edytory tekstu, arkusze elektroniczne czy bazy danych, a coraz większego znaczenia nabierają rozwiązania trójwymiarowe, o większej złożoności wizualnej, niż dotychczas dominujące zastosowania dwuwymiarowe; « W lM P korzysta praktycznie z jednego zmysłu człowieka, tj. wzroku (w ograniczonym zakresie ze słuchu). W zw iązku z w ym ienionym i ograniczeniami pojawiła się, rozwijana dynamicznie, koncepcja p o st-W IM P (czwarta generacja), zakładająca równoległe w spółdziałanie innych zmysłów człowieka, rozpoznawanie gestów, kom unikow ania się w języku naturalnym przez wielu użytkowników. Nazwa w ynika z faktu, że większość dotychczasowych rozwiązań standardu WlMP została rów nież włączonych do interfejsu post-WIMP. Rozpoczęte w 1990 roku badania dały pewne wyniki w postaci interfejsów typu post-WIMP w system ach Apple Newton czy U.S. Robotics Pilot. W praktyce użytkow ane są więc aktualnie dwa rodzaje interfejsu użytkownika; • znakowy (druga generacja), • graficzny (trzecia generacja). I n te r fe js z n a k o w y pozw ala na kontaktowanie się człowieka z kom puterem poprzez sekw encje znaków alfanumerycznych. Obecnie istnieją następujące rodzaje interfejsów znakowych: • dialog p y tan ie-o d p o w ied ź, • język poleceń (ang. command language ), • język naturalny. V. W przypadku interakcji typu pytanie-odpow iedź [50] ma miejsce dialog w postaci sekwencji interakcji pomiędzy użytkownikiem a systemem. Komputer „pyta’ ’ użytkownika o określone dane. Po wprowadzeniu tych danych następuje kolejne pytanie aż do zarejestrowania wszystkich danych związanych z określoną transakcją. Praktycznie dialog taki może przybrać postać: • wyboru określonej opcji, spośród zaprezentowanego ich zestawu, poprzez wprow adzenie odpow iedniego numeru lub symbolu opcji - wykorzystanie zasady m en u znakow ego (rys. 3.6a), • udzielanie odpow iedzi w trybie ciągów znaków alfanumerycznych na zapytania system u (rys. 3.6b), • w prow adzanie danych do formatek, odpowiadających poszczegon\m polom rekordu (rys. 3.6c). , . U żytkow anie drugiej postaci interfejsu znakowego, tj. jęzv a po eeen. polega n a tym , że użytkow nicy wprowadzają bezpośrednio polecenia \ zainicjowania określonych operacji. Przykładem znakowego interfejsu typu język poleceń są rozkazy w system ach operacyjn>ch DOS czy " P Polecenie system u operacyjnego DOS dotyczące formatowaniu >s ie 79
«
Wprowadź dane o k k o o c s e Wyt^rz ¡ećną z poniższych opcji W p^cwjd; nazwisko 2. Wprowadź xn*ę 1
3 Wprowadź numer telefonu I
a ) m e to d a w y b o ru o o o
Wprowadź numer opcj> Za^ejestm» dane
Jakie jest nazw-sko Manta7 Amfccoży Nowac2yriski Jak* jest adres Ambrożego Nowaczynshego7 Szczeon. uł Jaskółki 12 Jak» fes* numer telefonu Ambrożego Nowaczynskieoo7
b) metoda rapy^r
3466-232
c) m etoda formatek
j j J J
Wprowadź dane o kliencie N ar* «s*o. Adres Nr telefonu Czy wprowadzone dane są
poprawne (T
\ *
R>s 3.6 D ialog pytanie - odpow iedź
forma! a: . , , . liUiieie » p e c y fic a u iu m u jw>ka poleceń p o p r ą * stosow anie klaw iszy M kombinacji klawisz) i klawiatur)', np. w edytorze W ordP erlect kombinacja klawiszy SH IFT F7 oznacza polecenie drukowania. Znaczenie dwu wyżej wymienionych rodzajów znakow ego interfejsu zanika, ale trwają badania nad stosowaniem ję z y k a n a tu r a ln e g o jako interfejsu uży tkownika Wykorzystywane są osiągnięcia sztucznej inteligencji Ta forma dialogu człowieka z komputerem oznacza, iż zaró w n o wejścia jak i wyjścia wyrażane są w zdaniach konwencjonalnego języ k a . Interfejs użytkownika wykorzystujący język naturalny nie znalazł w ciąż szerszego zastosowania ze względu na istniejące jego ograniczenia. W podobnym kierunku idą badania i zastosowania technologii rozpoznaw ania mowy SRT (ang. speech recognition technolog)), w której głos ludzki jest środkiem komunikacji z komputerem. W zakresie projektywąniaj. użytkowania systemów dom inuje graficzna, postać interfejsu, oznaczająca stosowanie różnorodnych form graficznych Skom unikow ania się użytkowników z k ^ ^ tfc e re n v -P e 6 tać 4 ą..iiosi miano* jak wspomniano uprzednio*. graficznego in fęrfejsu u ż y tk o w n ik a (ang. GUI - graphical user interface). Pliki, profflflpyy i polecenia są wybierani przez wskazanie--x)dppjyiedtaiej^forrny graficznej, a nie przez wypisywanie poleceń czy skrótów mnemotechnicznychjęzylSipołeceń. Efektywny interfejs 80
ułatw ia interakcję użytkow nika / komputerem, pod warunkiem, że jest /godny, a ss każdy m la /ie bardzo zbliżony, do naturalnego sposobu pracy użytkownika, c/y li sposobu, w jaki użytkownik postrzega problem. Dwie podstawowe charakterystyki graficznego interfejsu użytkownika to: • sposób p re z e n ta c ji, tj. układ intormacji na ekranie,
• prowadzenie dialogu, czyli sekwencja in terak cji między człowiekiem a kom puterem . ^ P r o j e k t o w a n i e i u ż y t k o w a n i e g r a f i c z n e g o in te r f e js u p r z e b ie g a w u k ł a d z i e czterech k o l e j n y c h w arstw [ 2 7 1 :
• • • •
warstwy warstwy warstwy warstwy
użytkownika
m etafor, m etod. urządzeń. fizycznej.
M etafory stanow ią pew ne imitacje sytuacji rzeczywistej. Metody są sposobem kontaktow ania się użytkownika z komputerem. Ż kolei warstwa urządzeń dotyczy fizycznych urządzeń eksploatowanych przez użytkpyynika, a warstwa fizyczna oznacza czynności fizyczne wykonywane w związku / użytkow aniem m etod i urządzeń. M e ta fo ra oznacza podobieństw o zachowania się systemu do czegoś, ;o użytkow nik z n a z; .codziennego życia. Przykładami metafor są: co • metafora dokum entu - gdzie ekran jest imitacją papieru i zaznaczonych rubryk, • metafora biurka - ekran jest imitacją blatu biurka z rozłożonymi m ateriałam i i różnym i akcesoriam i (zegar, kalendarz, notatnik, kartoteka, koszyk na korespondencje), z możliwością dowolnego ich przemieszczania, • metafora tablicy rozdzielczej - zawierającej używane przez użytkownika przyciski, suw aki, lampki kontrolne itd., • metafora teczek i segregatorów - czyli założone i opisane w systemie katalogi. Rysunek 3.7 przedstaw iający pulpit systemu WINDOWS 98 jest przykładem metafory biurka. M eto d y pow szechnie w iążą się z pojęciem graficznego inteitejsu użytkownika. D o podstaw ow ych metod interfejsu graficznego należą wymienione ju ż w standardzie W IM P i zintegrowane: •-Jmeiiu,
• formatki, • okna, • obiekty graficzne,~pQpulamie zw ane ikonami. M e n u to zestaw
o p c jp u u l.u y .c h
(wariantowych) wy boi ów oferowanye ^
-Użytkównikowi-.nar .akranie.. j^ferfejs prezentuje listę opcji, -
....
Rys. 3.7. Pulpit MS W IN DO W S 98 jak o m etafora biurka
jednej z nich (podświetlenie, kliknięcie czy kombinację klaw iszy) inicjuje pożądane funkcje. Po wyborze określonej opcji może ukazać się następne menu ściśle związane z poprzednim wyborem. Proces m oże być kon tynuowany w dowolnej liczbie stopni hierarchii, z m ożliw ością powrotu do wyższych stopni menu. Jest to tzw. m enu ro z w ija n e (ang. puli-down menu). Stosownie do dokonywanych wyborów i zw iązanych z nim i działań użytkownik uzyskuje odpowiednie wyniki. Istnieją różne (rys. 3.8) typy menu rozwijanego [52, s. 510]: • pojedyncze, • sekwencyjne, • wielopoziomowe, • wielopoziomowe z wieloma wierzchołkami m acierzystym i, • wielopoziomowe z wielopoziomowymi w ierzchołkam i macierzystymi i punktami zwrotnymi. Oprócz menu rozwijanego wykorzystywane je st m e n u w y s k a k u ją « ang. pop up menu), .wywoływane w miejscu położenia k u rso ra i znikające. Vi V"V| u*7 *- POl"CeniaPr°jekl°wania menu bardzo użyteczne są języki V.sutd Basic , Delphi, pozwalające je szybko tworzyć.
być dJ ś w i T ,l(!rm a,ki uz>tkow,uk wypełnia wolne pola. które mogi byt podświetlone lub migotać (pądrozdz. 3.4).
pojedyncze menu
Sekwencyjne menu
Wielopoziomowe menu
Wielopoziomowe menu z wieloma wierzchołkami macierzystymi
r
3u
Wielopoziomowe men j z wieloma wierzchołkami macierzystymi i punktami zwrotnym:
T r^ T
Rys. 3.8. Sposoby organizowania menu [52, s. 510)
Szczególną rolę odgryw a technika okien, najbardziej znana w postaci MS W indow s. Staje się ona standardem interfejsu użytkownika. Standard ten w w ydaniu IB M nosi miano powszechnego dostępu użytkownika (ang. CUA - Common User Access). Stanowi on zestaw reguł, na podstawie których użytkow nik system u współpracuje z aplikacją. Standard obejmuje zasady użytkow ania klawiatur)' i myszy, wybór opcji menu w oknie, stosowanie podpow iedzi iang. help) i zasady przejść między aplikacjami. Okienka zaw ierają przyciski, paski, suwaki (por. rys. 3.9). W okienkach mogą znajdować się formatki zawierające wyodrębnione pola do wypełnienia. N aj bardziej p o p u 1arną form ą interfejsu graficznego, opartego na Dbiektach, są ikony, czyli piktogram y, które reprezentują poszczególne ^obiekty, funkcje i polecenia systemu. Projektow anie graficznego interfejsu użytkownika wykorzystuje wiele szczegółowych zasad dotyczących: układu poszczególnych informacji i poleceń w okienku czy menu, wyglądu piktogramów, zasad kontroli poprawności w p ro w ad zan y ch danych, formułowania lunkcji pomoc) (podpowiedzi), kontroli dostępu użytkownika, w tym procedur autoryzacji i enkrypcji, kolejności dialogu, łatwości użytkowania, zmiany wielkości okien i ikon, ich przesuw ania i innych. Punktem wyjścia do projektowania graficznego interfejsu użytkow nika są diagramy przepływu danych, opracowane w trakcie analizy systemów bądź projektowania ogolnego Zasadniczą rolę odgryw ają tu przepływy do i z terminatorów (obiektów zew nęiznych).^ 0 1 creśłają one występujące we wdrożonym systemie formatki 83
wejściowe, wyjścia tabe.aryczne i graficzne oraz diaiog komunikowania się z Zestaw reguł proj zaproponowała firma pp
spoSóh
interfejsu użytkownika Najważniejsze z tych reguł dotyczą: grafjcznego
^ powinien opierać się na użytkowaniu
’ kontowych m e X odpowiadających działaniom (operacjom, akcjo*, . t e ™ « o Zo S w a n i a - użytkownik powinien mieć możliwość hezDośredniego wykonywania poszczególnych poleceń: system informuje użytkownika^) wykonaniu poszczególnej operacji lub o pow odach, dla których polecenie nie może byc wykonane: . zasady see and point (tryb wskazywania) - ekran pow .n.en zapewniać środowisko, w którym użytkownicy pracują z w ykorzystaniem pełnej mocy komputera; następuje więc bezpośrednia intei akcja z ekranem komputera poprzez wybór i wskazanie określonych obiektów , za pomocą klawiatury, myszy czy różnego rodzaju manipulatorów; • spójności - istnieje spójny ciąg czynności, poprzez które użytkownik realizuje zamierzone działania: • zasady WYSIWYG tang. What You See Is What You Get) - użytkownik ma wpływ zarówno na treść, jak i formatowanie ekranu; system winien wskazać rezultaty wyborów, dokonywanych przez użytkow nika szybko i bezpośrednio. Po zaprojektowaniu warstw metafor i metod następuje określenie warstwy urządzeń. Realizacja omówionych wyżej metod dialogu poprzez graficzny interfejs użytkownika jest wspomagana poprzez takie peryferyjne urządzeniami wejścia/wyjścia, jak: • klawiaturaj " ' • myszka, • • • •
manipulator drążkowy (ang. joystick), manipulator kulkowy (ang. irackball), ekran dotykowy (ang. touchscreen ), rysownica (ang. graphics tablet),
• U M „•fito < roZP0ZnaWania m° Wy (an- sPeech recognition technology). pośredni wpływ na S ^ u T k lf hn° l0gii inforn™ tycznej m ają beztych cech sDr/ein i • ^ konkretnego systemu. W szczególności do ekranie (pionowe i nozinmM
T tora* zes,aw znaków ldawiawlękowych, przew ijanie obrazu na
•td. Graficzny interfejs użytków Y
m
i
g
o
t
a
n
i
e
wiśc „a e k r L e j X S r l aa T * W IM P rozwijane, paski przewijania skr/v’n t T ’ m en“ Wyskaku-ią c e ' meD" ynki kontrolne, przyciski. Przykład
graficznego interfejsu użytkownika w systemie MS WINDOWS przedstawia rys. 3.9. Ostatnia z warstw, tj. warstwa fizyczna dotyczy czynności wykonywa nych na w ym ienionych urządzeniach wejścia/wyjścia, a więc klikania, użytkowania klaw iszy i manipulatorów. W systemach post-WIMP warstwa ta dotyczy reakcji innych zmysłów człowieka.
s m ts s tg n g .
a & ific
öcg
- na
j Msr* OmjbCsäj -Pjji 'lllC.*- iii r.4
Asr Uprtóo
Ł.;DSFVx*n>lft
i
I^C lV zr^lC . i
QWírvSp
C P C dfD l
Gfcnwiy jC )
3 a-i
CD DQM
_J
;VÎS
& Media
35F«WyVk?
fil]
„J
ounerłt
Ij> ? 3 5 Inch LocdDa* Loc-d 0«tk
3
jjF fiv o ric t
í>5eft
i
Swe
ylûLb
r«ation & Sports
CD-POW SjfitenF..
I
Catiei
12 1:,. T:k •-
Ffat o«FobJsji ÿÇcmcU« On
SX frvJ»
*jS>a£*wm.
1 ro o t
!nMr»N
? root
ro o t ro o t
1 3 8 2 1 Fed 18
1 4 :8 1
,
< e rs:~ l | Comptes son
gy«w» teOoflxj JkjEwbmg-ttyCc.
30€S
IÍ 3
•li 7^ 3 1
-F-SwgieSSH
Rys. 3.9. Graficzny interfejs w systemie WINDOWS
Projektowanie plików i bazy danych -M odele d a n y c h o p raco w an e w trakcie projektow ania ogól nego i w fazach w cześniejszych transformowane są na projekt plikóv i bazy danych. Plik stanow i kolekcję wystąpień jednorodnych lub po dobnych rek o rd ów , a baza danych jest kolekcją wzajemnie powiązany, plików. Pliki o d n o szą się do odrębnych zastosowań, modułów projektu wanego system u, zaś dane zgrom adzone i ustrukturyzowane w bazie s niezależne od zastosow ań, procesów, które mogą się elastycznie zmienia stosownie do zm iennych w arunków i potrzeb funkcjonowania orgam /a, i gospodarczej. Ze w zględu na dostępność na rynku oprogramowania ora walory funkcjon alne i użytkow e (w tym zwłaszcza niezależność dany o s*
f L n ic z e n ,
ich
re d u n d a n t*
.
b a z ie ,
na
ty m
e ta p ie
p ro je k to w a « ,
na różnych modelach danych, które generalni można podzielić na. . prerelacyjne. tj. hierarchiczne i sieciowe,
^
imstrelacyjne. głównie obiektowe, a poza tym dedukcyjne i temporalne. W latach osiemdziesiątych /.ostał zdominowany osiemu/j^miY^- rynek . r — baz — danych , nr/c/ relacyjne systemy zarządzania baz danych. N ajw iększe u z n a * S y t v ORACLE. PROGRESS. INFORM IX. ING RES. SY B A SE , DB2. In,camina ich częścią jest jest jx język zapytań SOL (ang. Quen Integralną ~j ~ — w . ~ v Language) ora/ narzędzia czwartej generacji (4GL), jak generatory formatek ekranów, zestawień wynikowych czy struktury rekordów. (Podstawowe założenia podejścia relacyjnego oraz zasady norm alizacji tego modelu przedstawiono w rozdz. 4.) Aktualnie uwaga specjalistów z dziedziny ba2 danych skupia się na modelu obiektowym. Projekty badaw cze prow adzą do jego komercyjnych zastosowań. Każdy system bazy danych ma określoną a r c h ite k tu r ę . Istnieją pod tym względem pewne standardy, z których najbardziej uznany je s t standard ANS1/X3/SPARC [110). Wyróżnia się w nim trzy poziom y: • Jkonceptualny, odpowiadający modelowi danych dziedziny przedmiotowej opracowanemu w trakcie analizy danych i projeklowmia ogólnego, • zew nętrzny, dotyczący wycinka modelu danych, odpowiadającego określonemu zastosowaniu lub aplikacji poszczególnego użytkownika, • wewnętrzny, stanowiący opis technicznego w drożenia projektowanej bazy danych przy użyciu konkretnego sprzętu i oprogram ow ania. Fiójpoziomową architekturę systemu bazy danych przedstaw ia rys. 1 3.10 [371. Trzy poziomy projektowania bazy danych pow szechnie nazywa,si?;. schematem, schematem logicznym i schem atem fizycznym . Schemat odpow iada poziomowi konceptualnemu. Schem at logiczny, wychodząc ze. schematu konceptualnego, opisuje bazę danych w k ategoriach modelu lerarchicznego, sieciowego, realcyjnego czy obiektowego, z uwzględnienie® L wymogow użytkowanego systemu zarządzania b azą danych. S e t o * szczpoAhś ? , T Je SLrU^ lUiy metody dostępu, indeksy i t o j l f ) y . f chniezne stosownie do param etrów w y b ra n e g o system» ■ /ar/ądzam a b m danych. ^ J .
.
.
dosteDu kteehl' a ii ^ ^ r o c z n y c h : organizacji i struktur d an y ch oraz metod;
P • *
'
hnologia baz danych i przetw arzanie p lik ó w k o n w e n c jo n a ln i ^
*
MmV
Af l
I
li
i
V
I
*
W*
•
^
—
• 4 * f •
^
^
1
^
.
*
%Ł m •
’
^«11
^ % ■ t*
I.
J
•
*
SCHEMAT ZEWNĘTRZNY 1
SCHEMAT ZEWNĘTRZNY N
POZIOM KONCEPTUALNY
SCHEMAT WEWNĘTRZNY
BAZA DANYCH Rys. 3.10. Architektura systemu bazy danych (37)
opierają się n a p o d o b n y c h kategoriach pojęciowych i funkcjonal nych. P o d sta w o w y m pojęciem je st zdefiniowany wyżej plik. Dwa. podstawowe typy plików nazywają się plikami głównymi i transak cyjnymi, Pliki głów ne zaw ierają rekordy, które są przechowywane i po zostają nie zm ienione w dłuższym okresie, jak np. pliki PRACOWNIK, KLIENT, M A T E R IA Ł . W tradycyjnych system ach mają one cha rakter kartotek. W plikach transakcyjnych rejestruje się bieżące zda rzenia g o s p o d a rc z e , rejestro w an e na dokumentach, na przykład ZAM ÓW IENIA, P Ł A T N O Ś C I, FAKTURY. O rganizacja plików może być; • sekwencyjna, tj. rekordy ułożone są w kolejności, określonej przez, Wart°ść klu cza rek o rd u , •"bezpośrednia, gdy rekordy są umieszczone w pamięci pod adresami obliczonymi na podstaw ie wartości klucza, • indeksowana - plik m a tablice indeksowe, powiązane za pomocą indeksów z odpow iednim i rekordam i. 87
A r r ô U r t tC u
S rcre g d o d tfkcw e
rent Summary Master
Użycie
C^-namr«:^
Produkt
Finanse
Tpma!
U
Klucze: O L_A ccounLS U M _M S TR
Nazwa technir.:n3 Nazwa fizyczna Grupa tadei ekran
t w
ó r z
p íi.k
n a g k ó w
k o * A
------------------------------------
GL Account S U M .M S TR k e y l
GL001Ü1
Segm enty w kluczu
Account Master
Account N um liP r Open Year Penod Index
.Account Master
Typ obiektu
Nazwa fizyczna
> y
Pożycia
OPS_Resem?d
OPS_RESEF?VEO
Long integer
At count Number Open Year
actnum br
C om posite A cto
OPENYEAR
integer
Penod index
PERINOX
Integer
.'urrenl Year Figures
CURYRFIG
Currency
PL Current Ye3r Debit
CURYDBT
Currency
~
Rozmiar rekordu:
w g nr pozycji ;_______
j®
Wszystkie
Q »0 magazynu
Podstawowa J M. KG Ilość:
Opis skrócony
Wapno
Grupa asortyment
BUDOWL
Wy£6na
Średnia ważona
TVP Substytut #1 Substytut 92
Poz magazynowa
Schemat podatku Ścieżka Główny dostawca Nazwa dostawcy
VSP_ 7 Brak
Cyfr po przecinku.
ilość
Historia
Na miejscu
1.529.000
Alokowane Przekazane
0.000
Dostępne Sprzedane Zwrócone W użyciu W naprawie Uszkodzone
*1-•~^ 3
✓ Kalendarzowy
Waluta v Transakcja
^ Obrachunkowy •/ Dekretacja
2
Zamówienie ł zal Żądana
Na zamówieniu Poziom powtórnego zam.
Dopuszczalny niedobór Poziom maksymalny
- I I . Strukturo rekordu i opis pól rekordu Z A M Ó W IE N IE
0,000 1.529.000
0,000 0,000 0,000
0,000 0,000
o.ooc 0.000
gdy duża część rekordów jest aktualizowana w jednym przebiegu, jak w przypadku systemów transakcyjnych. Jeśli system wymaga dostępu do nielicznych rekordów w jednym przebiegu programu (np. w systemach wspomagania decyzji SWD), dogodniejsza jest metoda bezpośrednia. P lik i zawierają więc rekordy, które stanowią kolekcje pól danych uporządkow anych zgodnie z zaprojektowaną wcześniej strukturą. Programy użytkow ania baz danych lub plików operują głównie na rekordach jako najm niejszych przetwarzanych jednostkach. Przykład opisu' struktury rekordu w ygenerowany w systemie DYNAMICS firmy Great Plains Software przedstaw ia rys. 3.11. Rekordy w pliku m ogą mieć s ta łą i zm ien n ą długość. Każdy rekord 0 stałej długości ma tę samą liczbę pól danych, o tej samej długości w każdym wystąpieniu rekordu w pliku. Są one charakterystyczne dla plików głów nych. W rekordach o zmiennej długości w każdym rekordzie występuje zm ienna liczba grup powtarzających. Przykładem może być plik ZA M ÓW IEN IE, którego każdy rekord zawiera różną liczbę grup po w tarzających Z A M A W IA N Y -T O W A R . Rekordy o zmiennej długości dominują w grupie plików transakcyjnych. N ajm niejszą logiczną jednostką danych przechowywaną w plikach 1 bazach danych jest pole danych. Jest ono odpowiednikiem atrybutu danych z poziom u schem atu konceptualnego. Opis każdego pola danych zawiera jeg o ty p (alfabetyczny, numeryczny, alfanumeryczny, logiczny, specjalny) oraz z a k re s , czyli maksymalną liczbę znaków w danym polu danych (przykład opisu pól rekordu ZAMÓW IENIE - rys. 3.11). Problem atyka baz danych jest bardzo rozległa i stanowi przedmiot oddzielnego kursu na studiach informatycznych. Kwestie modeli danych omawiane są w rozdz. IV niniejszej książki. W arto zapoznać się z klasycznym i pozycjam i literatury: [29; 49], a także nowszymi opra cowaniami, ukierunkow anym i na potrzeby projektantów systemów, tj. [7; 72].
Pytania i problemy 1. Podstawowe czynności w fazie analizy i ich powiązanie z rezultatami planowania ?
systemów informatycznych. 2. Czym jest studium wykonalności - na czym polega jego waga. 3. Wyjaśnij istotę metody analizy punktów fu n k c jo n aln y c h (FPA). 4. Czym jest strukturalne projektowanie systemów?
£
i
5. Projektowanie ogólne a techniczne - składniki. 6. Znaczenie projektu ogólnego - jego powiązanie
technicznym, 7. Rodzaje wejść i wyjść systemu.
. projektowaniem
9. 10. 11. 12.
POUĆIJ Vw ^ui UKUjf • 7 n-,nvch Ci pakietów o p r o g r a m o w a n ia podstaw JNa ^<1 j/V v-v— ie znanych <- i wyświetl) w ejść i w yjść visć system u. n terfej Su u ż y tk o w n ik a 1 Na czym p o l e g a z n a c z e n i e p r o j e k t o w a n i a v Z i n t e r p r e t u j znaczenie poszczególnych sk ład n ik ó w ak ro n im u W IM P . N a czym p o l e g a j ą z m i a n y zaproponow ane w k o n c e p c j i p o st-W IM P ? Rodzaje interfejsów znakow ych. P o d a j p r z y k ł a d y na p o d sta w ie z n a n e g o C i Oprog •
ramowania. 13. W arstwy g r a f i c z n e g o 14.
P odaj p rzy k ła d y
in te r fe js u
_______
W
/ T A i f
u ży tk o w n ik a .
m e ta fo r . R o z s z e r z ic h
15. S p o s o b y o r g a n i z o w a n i a m enu. 16. Reguły projektow ania g raficzn eg o
j
informatycznych
vs^'
“ -V
f
zestaw o m ó w io n y w p o d rę c z n ik u .
in te ife js u
R o z d z ia ł 4
jf i f
u ży tk o w n ik a.
17. Znaczenie bazy danych w p rojekcie sy stem ó w . 18. Na podstaw ie artykułów' z „ C o n ip u te rw o rd " , „ In fo rm a ty k i" i „ P C k u r ie r a ” o c e ń rv baz danych w P o l s c e . K t ó r y z m o d e l i d an y ch m a a k tu a ln ie n a jw ię k s z e 7 n * n •. rj Al,«czenic
praktyczne? 19.
Jaka je st
4.1. Rodzaje metod i technik
rola poziom u k o n cep tu aln eg o w a rc h ite k tu rz e b a z d a n y c h ?
20. Form y o r g a n i z a c j i plików . 2 1 . Zaprojektuj, korzystając z p ak ietu ACCES stru k tu rę re k o rd u S T U D E N T .
Istnieje duża różnorodność metod i technik tworzenia systemów informatycznych. Zw iązane są one z trzema podstawowymi podejściami do TSI: strukturalnym , o b iek to w y m ^ społecznym. W przypadku dwu pierwszych „podejść m etody _i_techniki - mają-~na. ogół -postać graficzną - różnego rodzaju m etod diagramoyyyęh. W opracowaniach na ten temat często cytow ane je s t stwierdzenie, iż rysunek wart jest więcej niż tysiąc słów. D iagram y te z reguły wspomagane są technikami tabelarycznymi i macierzowymi. W przypadku podejścia społecznego wykorzystuje sic rożnego rodzaju techniki heurystyczne. W istocie techniki związane ż podejściem społecznym najczęściej wspomagają fazę planowania w procesie TSI opartym nlTm etodykach strukturalnych lub obiektowych. W niniejszym rozdziale skoncentrowano się na metodach i technikach strukturalnych, m ających największe znaczenie w teorii i praktyce tworzenia systemów inform atycznych D otyczą one modelowania zarówno danych, jak i procesów. W tej konw encji modeluje się związki encji, tworzy diagramy p rzep ły w u danych, grafy metodyki ISAC, słownik/skorowidz danych, norm alizuje relacyjne modele danych, buduje diagramy struktur i diagramy Jacksona. W niniejszym opracowaniu przedstawiono metody i techniki: • • • •
!J... ^ ,1*« “
l
¿W M -W # ■ %
D l
4
-
‘r
* y n i*
Ijjp&K i:\r r 1v . ‘ Kf i; ' v>#: .■*- i, -N ... \ ? ;;; ó •■ v .
użyteczne w planow aniu systemów informatycznych (rozdz. 2 ), adekwatne d la projektow ania ogólnego (rozdz. 3 ), właściwe podejściu obiektow em u (rozdz. 5 ), cechujące m eto d y k i społeczne (rozdz. 6 ).
Z aprezentow ane m etody i techniki wspomagane są komputerowo przy użyciu pakietów CASE, scharakteryzow anych w rozdz. 7. Różnorodne m eto d y i techniki warto odnieść do taz cyklu życia •
s
systemu, tak jak przedstawiono to w tablicy 4.1. Niektóre z nich są
ra b "
.
.
.
, —
........ ----------------- r - --------
M e to d y
jej kierownictwa, a inne ze «m m , odpow iedzialnych za wdrożenie gospodarcze firmy. Toteż najcześciei w L
i te c h n ik i
„i„w e modele danych. P i e ™ S^ ^ d ~z "J a r i H 3 ,5’' aW° We 1 m ^ _ V4 ,VJPOdS' U
• SWOT
mialnvm h»Hź ™ any również konceptualnym bądź logicznym, jest ukierunkowany na potrzeby użytków•1-.. / N m e n i o H ' / i CkAm _i . . . J jr W nika. opisuje d zied zin ,
• Sesja MelaPkimi • Is to tn e ( '/.y n n ik i P o w o d z e n iu ( K 'P - C S F )
• MolIcI spójności lirockstry • Macier/e
.. —
B SP
•• Infopkm R e s tr tjk tu r \/a e ja
p ro c c s o w
g o s p o d n re z y d
« K o n te k sto w y d ia g ra m p rz e p ły w u d a n y c h
• Zerowy A -graf
2
Analiza
•
Diagramy dekompozycji funkcjonalnej
•
D ia g ra m )
przepływu danych
• Modele zwK|/ków encji • S ło w n ik y sk o ro w id / d a n y c h
•
G r a f y p o d e jś c ia I S A C
• Normalizacja modelu relacyjnego • Diasram w *y struktury/ Jak w fazie anali/vw oraz: 3. Projektowanie
• D iag ram y J a c k so n a • D ia g ra m y N a s s i-S h n e id e rm a n a ••
TI e c h n ik i
^ decyzyjne *A • P ro je k to w a n ie wejść/wyjść system u Projektowanie i baz danych •• P ro je K io w a iu w iplików ....... • Projektowanie interfejsu użytkow nika •
-
r . :
Diagramy struktury 4 . Wdrażanie
• Diagramy Jacksona • Diagramy N assi-Shneiderm ana Stosownie do zakresu m odyfikacji i adaptacji
5 Użytkowanie, modyfikacja
- użyt-
kowanie różnych wym ienionych m etod
fi j
,
uvvyvZ/Y
W
U
l
KJ/^KZllld
IUUU61U
lanych w konkretnej technologii baz danych. Do ważniejszych powodów różnicow ania m odeli i tworzenia modeli ograniczenie " lpodstawowych ---- «V ...V M JV H fnależą: iu.iw .q. U£I dl UL./„Cl 1IC £__1_• _ t «• ryzyka utraty kom pletnego opisu funkcjonalnego dziedziny przedmiotowej, dzięki pom inięciu kwestii wdrożeniowych oraz stworzeniu możliwości kom unikowania się kierownictwa, użytkowników i informatyków, we wspólnym, zrozumiałym języku, bez uciekania się do technicznej terminologii informatyki. Opracowano wiele formalizmów podstawowych modeli danych, spośród których należy wymienić: . • m odelow anie związków encji, • m odelow anie binarne, • rachunek predykatów , • abstrakcyjne m odele danych. • m odelow anie infologiczne. Powyższe modele zostały zinterpretowane i zweryfikowane w pracy [110]. Z kolei m odele wdrożeniowe, znane w technologii baz danych, to modele: • jLceręlacyjnę, czyli hierarchiczne i sieciowe, • .iclacyjne, • jpostrelacyjne, czyli głównie obiektowe, ale poza tym dedukcyjne oraz
i adaptacja
odpowiednie dla jednej fazy cyklu życia, a inne m o g ą m ieć zastosował»« w kilku kilku fazach. fazach. Najważniejsze m etod i technik T w N ajw ażn iejsi spośród -----strukturalnych ^nHro7riziałach. | omówiono bardziej szczegółowo w kolejnych pod rozdziałac .
4.2. Modele związków encji każdej organizacji zm ien iają się n a bieM«^ Wprawdzie dane w jednak rodzaje zbieranych, przechow yw anych i p rzcfw aizan y c ^ SIC« Poprzez ruj^i ¿Wj uogo m an ie i ^ # pozostają stabilne w dłuższym czasie. i zależności między nimi można tw orzyć modele danych. Modelować U U I k U l U V > I llv vy danych jest techniką organizowania i1 dokumentowania danych. K lodek .¥ _:J r1\ danych można opracowywać na różnych poziomach abstrakcji —
szczegółowości. Inne są oczekiwania co do obrazu danych firmy ze stto&j 92
infom>«yki. obsługującej procesy
tem poralne. N ajw iększe uznanie spośród wymienionych podstawowych modeli danych zdobył model związków encji, mimo licznych, podejmowanych w latach osiem dziesiątych prób jego zastąpienia. Ostatecznie rolę taką może spełnić m odel obiektowy, integrujący modelowanie danych i procesów, scharakteryzow any w następnym rozdziale. Łączy on cechy modelu podstaw ow ego i w drożeniow ego. M odel zw iązków encji (ang. entity/relationship), od momentu jego zaproponow ania p rzez C hena [23], stał się najbardziej popularnym formalizmem m odelowania danych na poziomie konceptualnym, początkowo w odniesieniu do baz danych, a następnie do innych klas systemów inform atycznych. Ś w iadczą o tym liczne konferencje, artykuły i integracja modeli zw iązków encji z uznanymi metodykami TS1. W krajowej literaturze przedmiotu używ ano różnych nazw tego podejścia, jak obiekt-atiybut-związek. czy relacje bytów . Zaproponow ane określenie ma charakter unikalny. 93
:: . Podstawowymi p o * * » " ' , „ U li— ta wartcścU I W <^ ! %
„ lvi,n C, o lomwNzmii są encja. alrybi, ‘ ; 0IKi„. / w i e k i e m , atrybutem M A G A Z Y N -P R A C O W N jjj
WiUci c h a r a k t e r y z o w a n o bardziej szczegółów,
kategorie p ^ o w e . PRACOWNIK
5 o ^- *N >7\<
i
m agazyn
H UJ N
MAGAZYN NR 56
i
>o
i
{Sj P / m a g a z y n i SOPOT -ARTYKUŁY! g f c NR 56 ' SĘPIA 12 ,łSKÓRZANE.!
i=
/\
^ 5 m2
ZATRUDNIA
KOWALSKI
KOWALSKI
GDANSK DŁUGA 11
y\
si Rys 4.1. Kaiegorie modelowania danych w związku M A G A Z Y N -PR A C O W N IK
Przyjmuje się, iż e n c ją (ang. entity) je st jed n o zn aczn ie identyfikowały składnik badanej rzeczywistości (dziedziny p rzed m io to w ej), o któryij informacja jest lub może być zbierana i przechow yw ana. Spotyka sit poglądy, że encją jest każdy składnik badanej dziedziny przedmiotowej który można nazwać, a więc: osoba, miejsce, rzecz, zd arzen ie, stan, pl& czy pojęcie. Encjami są: PRACOW NIK, M A G A Z Y N , K LIEN T, DO STAWCA, FAKTURA, PRZECENA, K O N T O itd. W y s tą p ie n ia m i enci PRACOWNIK są: KOWALSKI, N O W A K , T R Z E C IA K itd. W literaturze zależność tę opisuje się również jako: typ encji Z) encja. Encja stanowi więc kategorię opisu statyki dzied zin y przedmiotowej obejmującą wszystkie te wystąpienia encji, które o d p o w iad ają określoiK elinicji - kryterium - oraz posiadają id entyczną w iązk ę atrybutów az ej encji winno być przyporządkowane m inim um je d n o je j w y s tą p ić
W yróżnia się encje rzeczywiste, np. PRACOWNIK MATERIAŁ ora/ a b s tra k c y jn e , np. PROGNOZA, KONTO. Istnieje też podział na encje re g u la rn e - określane przez własne klucze (ZAMÓWIENIE) - oraz słabe, identyfikowane przez klucze obiektów regularnych POZYCJA-ASOR TYM ENTOW A (składnik ZAMÓW IENIA). Względy pragmatyczne zade cydow ały o zaproponowaniu [105] następujących rodzajów encji, opisu jących:
. role pełnione w organizacji lub systemie przez: osoby, komórki organizacyjne bądź instytucje, np. KLIENT, DOSTAWCA DZIAŁ PRA CO W NIK . KIEROW NIK; • rzeczy, np. M A SZY N A , MATERIAŁ, CZĘŚĆ, WYRÓB. USŁUGA; • zdarzenia, np. U M O W A , PROGNOZA, PROJEKT, ZAMÓWIENIE. miejsca, np. DZIAŁ, M AGAZYN. FILIA Encje opisuje się za pom ocą rzeczowników lub wyrażeń rzeczownikowych w liczbie pojedynczej. ' A try b u t je st cechą, elem entem charakteryzującym encje i związki w badanej dziedzinie przedmiotowej. Zestaw atrybutów, który jednoznacznie opisuje encję, nazyw a się w iązką atrybutów . Wiązka winna składać się z co najm niej dw u atrybutów opisujących daną encję. W danym modelu konceptualnym należy używ ać różnych nazw dla tych samych lub podobnych atrybutów , przypisanych różnym encjom. Na przykład atrybut ..adres” przypisany K LIEN TO W I, DOSTAW CY i PRACOWNIKOWI można nazw ać: k-adres, d-adres i p-adres. W podziale rodzajowym, określającym zależność atrybutu encji lub. związków od innych ich atrybutów^, w yróżnia się atrybuty pierwotne i pochodne. Atrybuty pierwotne to podstaw ow e cechy w danej encji lub związku. Nie oblicza się ich i nie wyprowadza na podstaw ie wartości innych atrybutów. Jest to natomiast właściwością atrybutów pochodnych, włączanych do wiązki atrybutów danej encji czy zw iązku, w nawiązaniu doi wymagań konkretnych łunkcji realizowanych w opisyw anej organizacji. Rola atrybutu w procedurach przetwarzania informacji jest kolejnym kryterium ich podziału. W ystępują atrybuty: • selekcyjne (klucze), służące do identyfikacji encji i związków. • opisowe, charakteryzujące werbalnie encje i związki, • proceduralne, stanow iące cechy ilościowo-wartościowe, wykorzystywane w obliczeniach. , ,, . Przykłady atrybutów encji ZAM ÓW IENIE i SKLEP wraz z określeniem ich rodzaju zaw iera tablica 4.2. _ .. . Szczególną rolę w zakresie podstawowych atrybutów encji pełni ... klucz, zwany id en ty fik ato rem . Pozwala on na jednoznaczne określane „wystąpienia encji w danej encji. Jeśli używa się jednego atrybutu dla
a 4 :
fcjwja 7/AMÓWll-Nlf
K o J / a i a ir y b iii ii
\li\hul
P ie r w o tn y . s e le k c y jn y ,
\i /;imó\iicniu
p ie r w o tn y , o p is o w y
N a /" •• U '" arii
P ie r w o tn y , p r o c e d u r a ln y
Ilość towaru
P o c h o d n y , p r o c e d u r a ln y .
W artość z a m ó w ie n ia P ie rw o tn y , s e le k c y jn y . :
SKI . I P
Nr sklepu.
P ie r w o tn y , o p is o w y .
Na/w a
P ie r w o tn y , o p is o w y .
A dres. P o w ie rz c h n ia u ż y tk o w a . O h ru l
n;i
I
"i
kw
pow .
P ie r w o tn y , p r o c e d u r a ln y . P o c h o d n y , p r o c e d u r a ln y
u ż v tk o w e j.
do czynienia z identyfikatorem p ro s ty m , a jeśli określenia encji, to mam y)■ uu ------------u r n celu używa się więcej aniżeli jednego atrybutu to z ulentyfikatore, zw iązana iązana jest jest dd zz ie atrybuty złożonym. Z każdym atrybutem zw ie dd zz in in aa atrybutu stanowiąca zbiór wartości danego atrybutu, które są jem u przyporządkowane Atrybut jest więc funkcją, wiążącą encje lub zw iązki z dziedzinami wartości. Dana dziedzina może- *przybrać postać “przedziału wartości (np* XI IUM-1. , LZdiiu J• / •* _ A. -ż * i przedziału liczb rzeczywistych), skończonego zestaw u w artości (np rozmiarów S. M. L. LX) lub wartości binarnych (T lub N, 0 lub ¿IIJiatuv> odzieży: ^ ’ ------z 1) Każdemu atrybutowi w- danym w ystąpieniu en cji lub związku przzyporżądkowana jest tylko jedna w artość z jeg p dziedziny. Jeśli dziedzina obejmuje tylko jedną wartość, mamy do czynienia nie z atrybutem , ale ze' a
•
•
■
■
stałą. 1 Zestaw atrybutów jednoznacznie opisujący daną encję lub związel nazywa się wiązką atrybutów. Z wiązką atrybutów w iąże się hierarchicZ' ność encji. Hierarchiczność jest w ażną c h a ra k te ry s ty k ą niektórych encji. Wyróżnić można mianowicie n a d e n c je (superencje) oraz podencje (subencje). Na przykład encje S T U D E N T -D Z IE N N Y i STUDENT-ZAOCZNY (każdy o innym zakresie i trybie studiów ) tworze encję STUDENT. Nadencja może zatem zaw ierać p o d en cje. Każde z nich ma inną wiązkę atrybutów, lecz w spólna część tych wiązel jest identyczna z pełną wiązką nadencji. Subencja ja k gd yby dziedzicz) wiązkę atrybutów nadencji i uzupełnia o atrybuty unikalne dla gj właśnie podencji. \ Wreszcie związek stanowi naturalne pow iązanie p o m ięd zy dwoma lut Więcej encjami w badanej dziedzinie p rzed m io to w ej. Istnieje duże oznoro ność związków w opisywanych dziedzinach przedmiotowy ^1 ,,
nie^ mo^na .)e podzielić na b in a r n e i w ie lo ra k ie . N aj części?
P rz y S e ^ opisujące podstawowe zależności m iędzy encjari rzykładem jest związek M A G A Z Y N -P R A C O W N lK m rys. 4 7 l. Z w i ^ 96
w ieloraki obejm uje więcej niż dwie encie
• •
trzykrotne, czlerokrolne Ud. Z w i t e k t r z y T Ś y , wykor/yŚtaniem'n
Chcna [23 J przedstawia rys. 4.2.
notacji
Rys. 4.2. Związek wielokrotny
W id e n ty fik o w a n iu i modelowaniu związków należy brać pod uwagę następujące ich cechy: , » • stopień zw iązku (albo liczebność), • opcyjność. Pierw sza z cech, tj. stopień związku, oznacza stosunek ilościowy między liczebnościam i wystąpień encji, uczestniczących w danym związku. Stopień zw iązku mówi zatem o tym, ile wystąpień encji.jednego rodzaju jest. pow iązanych z ilom a wystąpieniami encji innego rodzajju. Istnieją następujące stopnie związku: • np. K IE R O W N IK -D Z IA Ł , • np. W Y D Z IA Ł -P R A C O W N IK , • np. M A S Z Y N A -D E T A L . Stopień zw iązku 1:1 oznacza, iż każde wystąpienie encji KIEROWNIK jest pow iązane z tylko jednym wystąpieniem encji DZIAŁ. Inaczej: jeden KIEROW NIK kieruje jednym DZIAŁEM. W drugim przypadku każde wystąpienie encji W Y D Z IA Ł powiązane jest z jednym lub wieloma wystąpieniami encji PR A C O W N IK , przy czym każde wystąpienie encji PRA CO W N IK pow iązane jest z tylko jednym wystąpieniem encji W Y DZIAŁ. A zatem W Y D Z IA Ł zatrudnia wielu PRACOWNIKÓW, natomiast PRACOW NIK zatrudniony je st na wyłącznie jednym WYDZIALE. Trzecia z kolei opcja oznacza, iż każde wystąpienie encji MASZYNA jest powiązane z jednym lub w ielom a wystąpieniam i encji DETAL i odwrotnie: każde wystąpienie encji D E T A L pow iązane jest z wieloma wystąpieniami encji MASZYNA. Jest to uogólnienie praktycznej sytuacji, w której na każdej MASZYNIE o brab ia się jeden lub wiele DETALI, a każdy DETAL je-u 97
ac h . Ilustracja o7 ira b ia n v na
/wiijzków o rój..
h u ic lu M A S / A N
w i c iu i vi / \ •>*. . • m d i stopniach. u/npdnionii o odpow icdniif inlcrprctucjn ^ c m u n ty c /n ą , j e je d n e j
lu h
ry s 4 .3 .
a) D
n
r
a
m
l
n
t
e
r
p
r
e
t
a
c
j
a
i
Każde KONTO należy tylko do jednego KLIENTA
klient należy do
ma
Każdy KLIENT ma tylko jedno KONTO
konto
b)
Każdy PRACOWNIK jest zatru dniony tylko na jednym WYDZIALE
WYDZIAŁ jest za trud n io n y
zatrudnia
PRACOWNIK
Każdy WYDZIAŁ zatrudnia jednego lub więcej PRACOWNIKÓW
c) Każdy TOWAR jest sprzedawany w jednym lub więcej SKLEPACH jest sprzedawany sprzedaje
TOWAR
Każdy SKLEP sprzedaje jeden lub więcej TOWARÓW Rys. 4.3. Stopnie związków
Bardziej złożony przypadek kilku związków pomiędzy różnymi encjatni opisujący model danych zamawiania towarów przez klienta, przedstawieni na diagramie związków encji na rys. 4.4. Diagram w zbogacono opisam reguł semantycznych (zwanych również regułami działania lub regułami gospodarczymi - ang. business rules ), dotyczących zw iązków i encji. Istnieje kilka konwencji graficznych przedstaw iania stopnia związki w diagramach związków encji (por. rys. 4 .5 ), które m ogą być użytkować stosownie do preferencji. Diagramy związków encji m ożna przedstawi1 / użyciem kilku notacji. Nie jest to kwestia jedynie grafiki, ale i więk^ - 1 luli mniejszej treści semantycznej, przekazywanej przez w ybrany model-
f-- a,
^ KLIENT jest składane
składa
A
ZAMÓWIENIE jest na
zawiera
<
to w a r
dotyczy
Każdy KLIENT składa jedno lub więcej ZAMÓWIEŃ Każda POZYCJA znajduje się tylko na jednym Z A M Ó W IE N IU
A\
POZYCJA jest zarejestrowany
Każda POZYCJA dotyczy tylko jednego TOWARU
Każde ZAMÓWIENIE jest składane tylko przez jednego KLIENTA
Każde ZAMÓWIENIE zawiera jedną lub więcej P O Z Y C J I
Każdy TOWAR jest zarejestrowany na jednej lub więcej POZYCJACH Rys. 4.4. Diagram związków encji
KLIENT
\ ZAMÓWIENIE
KLIENT
KLIENT
r i ..............._ ’ ZAMÓWIENIE ZAMÓWIENIE | ii ■
KLIENT
i
ZAMÓWIENIE
Rys. 4.5. Konwencje graficzne stopnia związku 1:N
Rozważane dotąd związki mają charakter obligatoryjny. Przedstawiony na rys. 4.5 związek pomiędzy encjami KLIENT i ZAMÓWIENIE można opisać zdaniem: „Każdy KLIENT składa (musi składać) jedno lub wiele ZAMÓWIEŃ” . A naliza sytuacji rzeczywistych, występujących w jakiejś dziedzinie przedm iotowej, wykazuje, że poza obligatoryjnymi istnieją opcyjne związki pomiędzy encjami. Związki opcyjne opisuję siowo -jnuze • W powyższym przykładzie KLIENT pozostaje potencjalnym KLIENTEM, nawet jeżeli nie złożył nigdy ZAMÓWIENIA. Właściwszym określeniem tej sytuacji byłoby więc zdanie: „Każdy KLIENT może złożyć zero. jc no lub wiele Z A M Ó W IE Ń ” . Związek ten przedstawiono graficznie na rys. 4.6. Dokonanie werbalnego opisu dziedziny przedmiotowej jest po stawą poprawnego diagram u związków encji. . . Scharakteryzowano dotąd przede wszystkim binarne zwi i gatoryjne i opcyjne. Analiza rzeczywistych powiązań w ' Warto przedmiotowej w skazuje na znacznie większą zlozonosc powiąż' ' w tym kontekście zw rócić uwagę na zwkłgb ■ W A /ilustrowane na rys. 4.7. Z pierwszym typem związku mamy ^
* 99
jest Tłożonę
a)
z w
i ą
z e k
zwrotny KIERUJE
b)związek łączny
przesy ła
M AGAZYN SKLEP
ZAMAWIA
c) związek rozłączny
JEST PRZEWOŻONY
POJAZD
TOW AR t. Identyfikacja encji
4.7. Związki zwrotne, łączne i rozłączne
- Opracowanie w stępnego, ogólnego diagramu
• prototypowanie • anali/a sytuacyjna - JAD
związków encji • analiza dokumentów, zestawień, kartotek 3* identyfikacja i analiza atrybutów oraz związków
■k Opracowanie pełnego diagramu związków encji
• normalizacja • opis reguł funkcjonowania « macierze cncji
/uroków encii należy rozpuc/ać « I identyfikacji P r ,« , modclonana OTroki ,akics interpietacyjny. co encji. Definicja (ego i • mt uar,/ialu. clyckuc i
systemu
-rod/. w
L ■
• .lcj /nlecanu i n c l o c l a i c l przeprow adzeń* 'f i r n y C/y u ży tk o w n ik am i pr/.ys z | e g 0 „ VI„ie„ia się scharakteryzow ane w iw x fe j*
|ici|nsIyc2ne ,ne,ody analizy sytuacyjnej, ta k ie j*
‘ ^
T ,; MctaPlanu, Ich stosowanie /.wiązane jest z analiz, !m arn cu c/m m , wyznaczaniem celów i określaniem zagrożą Lp an° " a" .. „ncz-iniem tych funkcji firmy, których informatyzacja * ,iml> oraz znaczenia - ' ‘ , dlajcj ,. • • ro/v tych uczestniczy zazwyczaj Hprvduiace roz VOjju W sesjach ~ ¿aj 2 « (imiv i potencjalni użytkownicy. Na podstaw,e dyskusji, rapów, Diseninvch analityk może wyodrębnić słowa kluczowe, które », kandydata« encll Podobny rezultat daja wywiady i opisy słowne dziedziny przedmtotowej. Z prostego opisu werbalnego można przejść do standaryzowanego poprzez podporządkowanie każdego zdania pewnemu wzorcowi. Na przykład zdania rzeczownik-czasownik-rzeczownik odpowiadają wzorcowi encja-związek-encja. Przykłady takich zdań to: KIERÓW NIK kieiuje DZIAŁEM. KLIENT składa ZAMÓWIENIE. Podkreślone rzeczowniki są pierwszymi kandydatami na encje. Wykonana w pierwszej fazie identyfikacja kandydatów na encje oraz związki pozwala na opracowanie pierwszego szkicu modelu związków encji zwanego wstępnym, ogólnym modelem danych lub modelem przedsiębiorstwa. Jest on przygotowany przy współudziale uczestników warsztatów z pierwszej fazy analizy sytuacyjnej. W łaściw ą metódą. opracowania tego modelu jest prototypowanie (por. pkt 3.4.4), umożliwiające opis statyki dziedziny przedmiotowej w kategoriach diagram ów związków encji, począwszy od stosunkowo prostego modelu do obejm ującego główne encje wycinka rzeczywistości oraz związki między nimi. W stępny, ogólny model nie zawiera opisów' związków, określania identyfikatorów, atrybutów, podencji. W tej postaci jest on zrozumiały i akceptowany przez kierownictwo firmy i stanowi podstawę prac nad pełnym modelem danych. Wstępny konceptualny model danych, opracowany w pierwszej fazie, umożliwia podjęcie pełnego zakresu prac analitycznych, zw anych również analiząjiąnych. Chodzi tu przede wszystkim o: * • identyfikację atrybutów, £ • przyporządkowanie ich poszczególnym encjom, przeprowadzenie hierarchizacji encji - zaproponowanie nadencji i podencji. • określenie identyfikatorów oraz nany na bazie analizy semantycznej opis zw iązków między encjamiJednak n o l T I f ^ wykorzystuje się wyniki poprzedniej faz) dokumentów r Ą ^ f n e g 0 Przeprowadzenia tego etapu jest analiz« ’ portow>kartotek, formatek. Analiza dokumentów pozwala m 102
identyfikację pełnego spektrum atrybutów w modelu danych „adkowame ich poszczególnym encjom i związkom Nie iL ttnoraz h " przypoczynnosc mechaniczna. Wymaga ona a n a liw , bynajmmej pomiędzy atrybutami. Prowadzi to do modyfikacji o c ó T Za,eżności poiegajiicej na wyodrębnieniu nowych encii inm eg0 mode,u danych, [ nmdclii ogólnego, w y o d r ę b n i e ń ^ identyfikatorów encji. Pomocniczym narzędziem Drzv mali - T czynności może być omówiona w niniejszym rnzH i >' tych relacyjnych modeli danych. J ym r°ZdZ,ale "°™altzacja Trudniejszą czynnością jest opis związków między encjami. Można ,u posłużyć stę dwoma równolegle realizowanymi metodami: macierzami
DOSTAW CA
TOW AR
S T R A T E G IA Z A M A W IA N IA
SKLEP
M A G A ZY N
ZAPAS
H IS T O R IA SPRZEDAŻY
MODEL Z A M A W IA N IA
I I
PREDYKTOR
Rys. 4.8. Związki między encjami Tablica 4.4. Macierz specyfikacji encji Obiekty
Towar
Strategia zamawia-
Predyktor
Historia Dostawa Sklep Magazyn sprzedaży
mawia
Predyktor
i • Model-zamawiania Strategia-zam aw iania Hisioria-sprzedaży Dostawa
103
Macierze są tworz.one poprzednich fazach
identyfikacja atrybutów na nientacli, formatkach, kartotekach itd;' przeprowadzenie normalizacii któro i związków, J1’ U ° ra
r
*
P° ZWala na typowanie encji
opracowanie pełnego diagramu związków encji.
4.3. Diagramy przepływu danych Najhardziej znaną i powszechnie stosowana m e w k ,• • „¡«'Strukturalnego s , d iag ram y przepiywu danych (DIPD>~ twórców systemów są one wręcz t r a k t o w a ir ' ‘ Wlelu strukturalnego. Mimo dominującej, „historycznie” J¡ d \ syn° mm Podejścia DPD stanowią naturalnie jedną z wielu metod i te ^ UZ ukształtowaneJ Pozycji uproszczeń dotyczy również samych DPH i h ° ° l strukturalnych- Wiele czterech kategori, mow wymaga znajomości wielu reemł
jest dostarczony przez j
zaopatruje
DOSTAW CA
tow ar
jest
k l ie n t
przekazuje
zaopatnjje
dotyczy
składane
jest przeka zywany __
<
magazyn
jest ' zam awiany
składa
wa
u •
z ^ w a n ie oiagra-
i kompletny opis dziedziny przedmiotowej w k a t e g ^ O T o t a t c y c h podstawa prac projektowych i wdrożeniowych. Paradoksalnie DPD s» techniką o najdłuższym okresie użytkowania, zachowującą „d końca la sześcdziestątych aktualność, co w dziedzinie informatyki należy do rzadkości G AN ESARSON
YOURDON - DEMARCO
zaopatruje się w
Proces
Przepływ Składnica
Obiekt zewnętrzny
m W ® W rul* cjc o określonym stopniu złożoności Inentrchiczme uporz4d ' . modelowaniu procesów gospodar. DPD znajdują również zas.osow ^ g. strategicznym ^ czyeh or^ m'^ CJ' \ / , ię m podejściu strukturalnym, bowiem znajduj, zastosowanie w metodykach zorientowanych obiektowo, w ich wllrstvvie fU',kt ó wspomniano uprzednio, tworzenie DPD opiera się na c z t e r y pojęciowych i odpowiadających ,m symbolach graficznych, /■możvc/onveh V inżynierii oprogramowania , teorn grafów. S , to ( , nawiasach podano naziwy siosowane zamiennie w literaturze polskiej): k
a
t e g
o
r i a
c h
proces (funkcja). przepływ danych, ' -f składnica (zbiór, magazyn), • terminator (obiekt zewnętrzny). Istnieje kilka konwencji graficznych, z których najczęściej użytkowane są dwie: Yourdona-DeMarco i Gane’a-Sarsona, przedstawione na rys. 4.10. Ogólne definicje poszczególnych terminów zawiera tablica 4.5. Tablica 4.5. Znaczenia pojęciowe w diagramach przepływów danych Znaczenie
Pojęcie 1. PROCES
Funkcja, działalność gospodarcza realizowana w systemie, przekształcająca dane wejściowe w wynikowe
2. PRZEPŁYW DANYCH
Powiązanie między procesami i innymi kategoriami DPD
3.
Kolekcja danych, które muszą być przechowywane w systemie określony czas
SK ŁA D N IC A
DANYCH 4. 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
Obiekt zewnętrzny [ ( terminator) przepływ danych
przepływ
Składnica danych **
pxm
Zale¿noki pomiędzy podstawowymi kategoriami PDP PDF
S1
towary
2.1 KLIENT ------
zamówienie ----------► zamówienia ZAMAWIANIE hurtowe -------------------- t o w a r ó w list TaKiura przewozowy Dział v zamówień a------- ^
S2 DOSTAWCY Rys. 4.12. DPD procesu ZAMAWIANIE TOWARÓW
Rysunek 4.11 przedstawia istotę oraz podstawowe zależności pomiędzy kategoriami pojęciowymi DPD. Z kolei prosty DPD będący ilustracją zastosowania kategorii pojęciowych i graficznych DPD w odniesieniu do procesu ZA M AW IA NIA TOWARÓW zapisany w notacji Gane’a-Sarsona zaprezentowano na rys. 4.12. Proces ma numer identyfikacyjny 2.1 i jest realizowany w DZIALE-ZAMOWIEN. Terminatorami, stanowiącymi otoczenie systemu a będącymi źródłem i przeznaczeniem danych, są: KLIENT oraz DOSTAW CA. KLIENT generuje przepływ danych ZAMÓ WIENIE, a przyjm uje FAKTURĘ. Z kolei terminator HURTOWNIA jest odbiorcą przepływu danych ZAMÓWIENIE-HURTOWE oraz nadawcą LISTU-PRZEWOZOWEGO. W systemie przechowywane są dane o klientach i towarach w postaci składnic TOWARY i DOSTAWCY. Dane zawarte w poszczególnym ZAMÓWIENIU, uzupełnione o dane z obydwu składnic pozwalają opracować przepływ ZAMÓWIENIE-HURTOWE. Podobnie dane z LISTU-PRZEW OZOW EGO, otrzymanego od HURTOWNI, uzupeł nione o dane ze składnic TOWARY i DOSTAWCY służą przygotowaniu przepływu danych FAKTURA. W ten sposób proces ZAMAWIANIE-TOWARÓW przekształca dane wejściowe na wynikowe. Proces oznacza transformację danych wejściowych w wynikowe, toteż nazwa procesu winna w y k o n y ^ ^ ^ ^ ^ i^ O P S e , jak np. ZAM A WI A Ń I^TO W A RO W , KONTKÓi-X-KRED\ TOW UALIZACJA-KONTA-KLIENTA. Nazwa winna_oddawać istotę opis jeg o przebiegu dokonywany jest poza diagramem przy tych technik strukturalnych. DPD nie wskazują kolejności realizacji
107
n
wykonywane zarówno sekwencyjnie, Jaj. procesów - moga one h>c *;nulek ^ o/nacza> « ^ o w Jest o/nacza. 1Z iż kuku kilka pprocesów j^ r i równolegle. Ten ostatni i jy
Z
danych lub kolekcji grup . danych [47 s - - '
Z
^ ^ jednorodne struktury danych, 'c7e2ó|nych dokumentów czy komunikaló» f a k t u r a , p r z y j ę c e -p r a c o w n ik a
M d v pr/eplyw nta swoja unikalna nazwę adekwatną do z a w a r t y m ó w l - p h « inacej struktnry danych. Ten sam przepływ danych raoie występować wielokrotnie w określonym DPD. Strzałka p r z e p t y w u ^ ^ kierunek ruchu grup danych pomiędzy procesami, sk adntcam , _ j j * mmatorami Przepływ zakończony strzałkami na obydwu końcach oznacza dialog pomiędzy różnymi kategoriami DPD. Włączanie przepływów danych w diagram winno uwzględniać wiele zasad: • niedopuszczalne sa bezpośrednie przepływy danych pomiędzy składnicami lub pomiędzy składnicami a terminatorami i odwrotnie - przepływy winny być w’ tym czasie przetworzone przez proces, • przepływy wejściowe i wynikowe (do i ze składnicy danych) nie noszą nazw - nazw'a składnicy identyfikuje jednoznacznie: jeżeli jednak zawartość grupy danych w- przepływne jest częścią struktury grupy danych tej składnicy należy nazwę przepływu sformułować i umieścić. W trakcie konstruowania diagramów przepływów danych można wykorzystywać ich cechy rozbieżności i zb ież n o ści. Wprowa dzenie przepływów rozbieżnych ma znaczenie w następujących przy padkach: • kopie danej grupy danych przesyłane są do różnych składników systemu - procesów, składnic czy terminatorów, • grupa danych jest dekomponowana na mniejsze składowe grupy danych, rozsyłane do różnych części systemu, stosownie do wejściowych wymagań procesów, składnic i terminatorów, I • grupy danych charakteryzują się tą samą strukturą danych elementarnych. . niektóre dane elementarne spełniają rolę parametrów, co pozwala na te sortowanie stosownie do wartości tych parametrów. , ipn r,2yWadf m PrzePływu rozbieżnego jest rys. 4.13. W odwrotnym szczególną62 T ' ana ^eSt zasac*a zbieżności przepływ ów danych. Po łączą sie . T £ruPy danYch zawarte w składnikowych przepływach danych Przer^v!^)nl - grUPę danych w jednym zagregow anym przep ły ń u g e n e ro w a n ia ^ ^ ™ Wykazuj ą SW£* użyteczność zwłaszcza w procesach generowania dokumentów na podstawie różnych danych. 108
FAKTURY
Roki sk ład n icy jest przechowywanie danych w postaci jednorodnych kolekcji, grup danych, tworzonych i użytkowanych przez różne procesy w różnym czasie. Zaistnienie składnicy w DPD ma uzasadnienie wówczas gdy przechowywane tam dane służą realizacji co najmniej dwu procesów! Nazwa składnicy to rzeczownik w liczbie mnogiej. Struktura grupy danych składnicy najczęściej odpowiada strukturze wejściowych i wyjściowych przepływów danych. W związku z tym przepływom tym nie nadaje się nazwy, byłoby to bowiem powtórzenie nazwy, tyle że w liczbie pojedynczej. Wspomniane wyżej zasady zbieżności i rozbieżności danych oznaczają agregowanie i dezagregowanie przepływów danych w składnicy danych. Ponieważ grupy danych zawarte w takich przepływach stanowią wycinki złożonej grupy danych ze składnicy, nadaje się w tym przypadku nazwy przepływom danych. Składnice^ danych biorą udział w czterech.podstawowyeh-operacjach: wyszukiwania, wprowadzania, skreślania i aktualizacji. Trzy ostatnie operacje, inicjowane przez przepływy danych, zmieniają zawartość składnicy danych. Zmiany dotyczą jednej, niektórych lub wszystkich grup danych w określonej składnicy. Rys. 4.14 przedstawia podstawowe operacje dokonywane na składnicach danych. Zamieszczony na nim przypadek c) oznacza inicjowany przez proces dialog ze składnicą danych, dopuszczający wszystkie rodzaje operacji na niej, stosownie do interaktywnego trybu pracy. Podobną funkcję spełniają dw ie oddzielne, skierowane przeciwnie strzałki. Jednak rozwiązanie w przypadku c) nie tylko upraszcza diagram, ale i w sposób Wyraźny wiąże pytanie z odpowiedzią, podkreślając interaktywny charakter przepływów danych. •«¡¿asS I
v ’ t; * r
■
..
;v- Era ;
r: jCJ“ iw
W prowadzanie Aktualizacja
a) A
niezbędne okazuje się jednolite oznaczenie w ' Par zys t oś ci jak uczyniono to na rys. 4.15. O znaczenia rod^ u- ,ak zamiennie. skowe 1 hterowe stosuje się
Skreślanie
Wyszukiwanie
a Klient
c) Dialog Identyfikacja
—►
Opis funkcji
—►
R ys. 4 |4 . Podstaw ow e operacje na składnicach danych
Terminator oznacza obiekt z e w n ę tr z n y - czy ogólniej: system zewnętrzny, współpracujący z systemem analizowanym lub projektowanym przy użyciu DPD. Przykładami terminatorów w diagram ie opisującym funkcjonowanie organizacji gospodarczej są najczęściej: KLIENT, DO I STAWCA, BANK i inne. Modelowanie może dotyczyć również jedynie wycinka działalności firmy, odpowiadającego analizow anem u i projekto wanemu systemowi. W takich przypadkach terminatorami stają się jednostki; organizacyjne, grupy osób i osoby funkcjonujące w ram ach danej organizacji, np. MAGAZYN, DZIAŁ-KADR, D Y REK TO R. Poniewai terminator znajduje się na zewnątrz dziedziny przedm iotow ej, w procesie tworzenia systemu nie można zmieniać jego zawartości, organizacji luk f ^* wewnętrznych procedur z nim związanych. Zasada ta oznacza rowmez. że w diagramach przepływu danych nie przedstawia się dowolnych, faktycznie istniejących związków pomiędzy term inatoram i. Terminator; nie łączą się też przepływami ze składnicami danych. W szystkie .dąfl* wprowadzane i wyprowadzane z terminatorów podlegają przetwarzani»; w procesach. .
Nazwy składnic danych i terminatorów m ogą być wielokrotni*, powtarzane w DPD pod warunkiem reprezentowania tej samej składnią lub tenninatora. Rozwiązanie to sprzyja podniesieniu czytelności diagramów przez uniknięcie nagromadzenia przepływów danych, wokół jednej składni, czy terminatora, w określonym diagramie. Ponieważ w D PD występ#
Fizyczna lokalizacja Miejsce realizacji
D1
Klienci
D2
*
h. V
Pracownicy
•
c
i C.,
D1
Klienci
Rys. 4 . 15. Oznaczenia składnicy danych procesu i terminatora [44 ]
Rozumienie poszczególnych pojęć nie wystarcza do tworzenia spójnych i kom pletnych diagramów przepływu danych. Pierwsze prace na ich temat [33; 44] nie poruszały praktycznych zagadnień modelowania dziedziny przedmiotowej przy użyciu DPD. Ale wyzwoliły one wiele istotnych problemów wymagających rozwiązania. Praktyczne ich użytkowanie od końca lat siedemdziesiątych doprowadziło do opracowania wielu uogólnień wprowadzających zasady modelowania, sprzyjające spójnemu, kompletnemu, dokładnemu i przejrzystemu opisowi dziedziny przedmiotowej. Szczególne znaczenie m ają tu doświadczenia wielu firm konsultingowych, jak Ernst & Young czy Deloitte & Touche. DPD stały się jednym z podstawowych składników metodyk tworzenia systemów informatycznych użytkowanych komercyjnie. Zakres tego postępu można ocenić porównując podstawowe opracowania tej samej szkoły analizy strukturalnej [33; 129]. O ile pierwsza praca zawiera podstawowe kategorie i zasady użytkowania DPD. o tyle droga dotyczy wielu metodycznych wskazówek praktycznych, powiązań
DIAGRAM K O N T E K S T O W Y
D IA G R A M Z E R O W Y (S Y S T E M O W Y )
h ie r a r c h ia d ia g r a m ó w
POZIOM PROCESÓW ELEMENTARNYCH
Rys. 4.16. Warslw ozycji hierarchicz
Opracowanie diagramu ko„,eks,„ jerowego, zwanego również eks,ow=go srało sie „ , procesu wyodrębniania d ia g r a n ,^ ™ 0" 5'" ’' u "rożliwia Wą ^ u do specyfikacji procesów CU ™ "a " ¡« 'y c h noz „ ™ rozPoczęcie
4.16. isiotnym elenrenre^dt™ " amych- tak jak przlda hierarcha procesów. Stosowany j ^
~w
h
ia
^
7
i
' Jest «Rymanie j e S ? '° "a >ys-
u r : r nykod
- - -;oivillUWym Warto zauważyć, że gdyby na każdym poziomie, poczawszv od zerowego, wyodrębnić 7 procesów, to na pierwszym noz 49, na drugim 343, na trzecim 2401 itd Przy takiei r w y y lch globalny diagram przepływu danych przesiałby już być dla Togotolw S czytelny. D etom pozycja j ^ w r y jnarzjdziem opanowania z l o ż t S systemu . je g o op|SU. jSTop.en złożoności sysTeńu- j e T zT tón^w any , w jakim ś zakres,e można go mierzyć liczbą poziomów hierarchii dekompozycyjnej (wyłączywszy poziom kontekstowy): • system prosty liczy od 2 do 3 poziomów, • system średnio złożony - od 3 do 5 poziomów, • system złożony - powyżej 5 poziomów. -
. W
T T
U l i
Y
Jeśli poszczególne ścieżki hierarchicznej dekompozycji są rozbudowane \rdanym D PD w zróżnicowanym zakresie, to mówi się o jego skośności. kontekstow y^ definiuje zakres ii panice orani ra systemu. Przedstawia IV.U-' “* _D iagram ~ on powiązania system u z jego otoczeniem, czyli kontekstem, w którym system funkcjonuje. System przedstawiany jest jako pojedynczy proces. Na jego obwodzie przedstaw ia się terminatory a w szczególnych przypadkach zewnętrzne składnice danych, powiązane p r z e p ł y w danych. amiu : _ ---------------j ^,ru ^cu ig bezpośrednio uc^puMcumo przepływami Ze względów technicznych często znajduje tu zastosowanie zasada kilkakrotnego um ieszczania tych samych terminatorów, zróżnicowanych oznaczeniami. Przepływy do (i z) terminatorów przekraczają granice systemu. W trakcie tworzenia diagramu kontekstowego analityk wykonuje następujące czynności: przedstawienie systemu w postaci jednego procesu, ustalenie w spólnie z użytkownikami, zorientowanymi w specy ice dziedziny przedm iotow ej, listy podstawowych zdarzeń zapytań (operacji w ejściow ych) i związanych z nimi odpowie i wynikowych); odpow iadają one przepływom danych wiązącyc sy z- otoczeniem: w ^ ¿ c n ie m ; określenie źródeł i przeznaczenia danych - odpowiadają im terminator; oraz zewnętrzne składnice danych T A .ii
t
PunkteSt° We^ f zrozum iatego dla kierownictwa przedsiębiorstwa wyjścia procesu dekompozycji w postaci hierarchii
«..„.m i p rzyeolm , any d u f f , i ■
swoisui ..mapę terytorium " dzie. kontekstowego przedstaw,ono „a
rfzim przedmiotowej. 1 rzjktou rv'S. 4.17.
inne m agazyny
Mm / Przesunięcia \ ’ faktura otrzymane mlędzyd o s ta w y ^ 1 magazynowe
dane
księgowość
d o s ta w c a
polecenie księgowania
Pz przyjęcie zewnętrzner Wz
wydanie zewnętrzne
odbiorca
Fa faktura dla odbiorcy^
administrowanie \ gospodarką magazynową
/
-j /
\ \
wykaz zapasów minimalnych wykaz towarów zamówionychs
zestawienie stanów 1 , magazynowych
zaopatrzenie
zestawienia ilosciowo-wartościowe wykaz stanu ^ w różnych przekrojach realizacji zamówień
ZARZĄD
Rys. 4.17. Diagram kontekstowy
Dekompozycja procesu w diagramie kontekstowym rozpoczyna cię od stworzenia diagramu zerowego (zwanego również systemowym), wynikającego bezpośrednio z diagramu kontekstowego. Decydująca jest tu dekompozycja jednego procesu z diagramu kontekstowego na kilka procesów. Są one agregatami dekomponowanymi dalej aż do funkcji elementarnych. Na poziomie zerowym do diagramu wprowadza się też wewnętrzne składnice danych oraz przenosi terminatory z diagramu kontekstowego. Procesy, składnice danych oraz terminatory powiązane są przepływami danych z diagramu kontekstowi0’ Przepływy w diagramie kontekstowym wiązane są w logiczne grupy, z których każda reprezentuje proces w systemie. Każdy z tych procesów jest następu dekomponowany w kolejnych poziomach hierarchicznych [ 1 ; 129]. W trakcie dekompozycji diagramów obowiązuje zasada, iż tylko przepływy danych-
które pojawiły się na poziomie zerowym mona hierarchii. Jeśli pojawią się nowe przepływy danych nr/^ ych poziomach «o o nie 4 ^ przykładem d.agramu zerowego (systemowego), wynikahcSn r J Kontekstowego, przedstawionego na rys. 4.17, d‘agramu
« s la w c a
M m^ otrzymane
zew nętrzne
faktura dostaw
Wz wydanie zewnętrzne
odbiorca
inne magazyny
/
ewidencja ' dokum entów obrotu k. m agazyno\ w ego z
wydane
polecenie ksieqowani emitowanie poleceń księgowania
Fa ^ „fa ktu ra odbiorcy
karty stanów magazynowych
aktualizacja kart stanów magazyno wych
wykaz zapasów^, minimalnych
wykaz towarów zamówionych / N / tworzenie zestawienlSn raportów /śtanów \ • zestawień magazynowych \
^
zaopat rzenie
ZARZĄD
zestalenia iioścjowo•waijościowe w różnych przekrojach
wykaz realizacja zamówień
Rys. 4.18. Zerowy diagram pr/e p ly wu danych
Najważniejsze praktyczne wskazówki realizacji strukturalnej analizy i projektowania system ów informatycznych przy użyciu diagramów przepływów danych przedstawiono w tablicy 4.6.
4.4. Grafy ISAC Metodyka ISA C (ang. Information Systems Work and Analysis oj Changes), w rozum ieniu autorów [6 8 ] to szereg sterowalnych i spojn>c etapów oraz m etod tworzenia systemów informatycznych wraz z regu ami generowania odpow iednich dla każdego z tych etapów opis*.
115
Tablica -W> P r .ik iu /n e za^aiK użytkow ania D P I) |5 ó : I 2 l>| p r /e p h w u danych uporządkowane s.j u hierarchią:
I Diaeraim o diagram kc»niok^iou \ .
• d i a g r a m zerowy ( s y s t e m o w y ) .
r
w
• priven elemeniame . ; Pugraim po/walajy na np.> •.ysieni.m o rożnym stopniu złożoności: • system prosiv od 2 d o .' p o zio m ó w ,
• system średnio /łożony: od 3 do 5 poziomów. • s\storn /ło ż o n y : p o w yże j 5 p oziom ów
3. Diagram me może być wiek s/v niz formal A4. 4
W d ekom pozveji procesow o b o w ią z u je zasada
5
Wszystkie kalegorie wysypujące na po/iomie n-1 musza hyc poka/ane na poziomic
h
n i rów nież w postaci z d e k o m p le to w a n e j) Nazw \ ka teg o rii w określone| h ie ra rc h ii d ia g ra m ó w są u n ik a ln e .
" Nie nadaje sie nazw przepływom do i ze składnic) danych. 8. Niedopuszczalne są przepływy m i^l/y składnicami i pomigd/y temiinaiorami. 9 . Składnica winna być użytkowana pr/c/ co najmniej dwa procesy. 10. Nie w \ stepu iq
• procedur) poe/qfku i końca. • pede.
• bloki decyzyjne, • identyczne nazwy procesów i przepływów. II Strzałka do składnicy oznacza, /e dokonuje się konkretnych zmian (wprowadzanie aktualizacja, skreślanie). 12. Strzałka ze składnicy danych oznacza, ze dane są czytane. 13. Diagram zawiera zarówno ręczne, jak i zautomatyzowane procesy.
graficznych i tabelarycznych sposobów dokumentowania. Proces ten wychodzi od potrzeb i problemów doświadczanych oraz koncepcji opracowanych przez użytkowników, aby dojść do specyfikacji procedur systemowych i programów komputerowych (rys. 4.19). Analiza zmian
Tworzenie systemu informatycz nego
Analiza i projektowanie
SI Inny rozwój Wdrożenie
SI Użytkowanie innego Rys. 4.19. Proces TS1 w metodyce ISAC [ 68 )
Z n A 7 7 w yCJą W r cesie TS1 jest kreślona jako ana l i z zm ian (AZ,. W jej wymku zoS,aje podjęta decyzja, czy SI b ^ e iworżony poprzez ana ,zę. projektowanie i wdrożenie, czy U ™ ,rzehy , problemy użytkownika można rozwiązać w inny sposńb 1 związany z technolog,ą informatyczną. Celem analizy zmian jest ta danie typów zmian (ulepszeń), które należy wprowadzić, aby rozwiązać problemy , zaspokoić potrz.eby informatyczne występujące aktualnie w organi zacji. Badanie to powmno dotyczyć przyczyn problemów, a nie ich skutków. Decyzje podjęte w wyniku AZ mogą być następujące (są to kierunki zmian): . uruchomienie nowych kierunków działalności gospodarczej, np. produkcji lub systemów dystrybucji, • zmiany organizacyjne, • doskonalenie systemu porozumiewania się pracowników, ich szko lenie, • tworzenie systemów informatycznych. W wypadku podjęcia tej ostatniej decyzji podejmuje się (por. rys. 4.19) ciąg czynności związanych z TSI. Celem pierwszego etapu - analizy i p ro jek to w an ia - SI jest opracowanie modeli opisujących różne aspekty SI, przy czym system informatyczny to system skonstruowany do generowania, zbierania, przechowywania, przetwarzania i interpretowania informacji. Analiza i projektowanie SI to nie tylko wykonanie podstawowych, wynikających z cyklu życia systemu czynności analityczno-projektowych, lecz również proces uczenia się i komunikowania twórców systemu - użytkowników, analityków i projektantów. Proces TSI jest sterowany przez użytkowników. Do skonstruowania SI niezbędne są różne rodzaje wiedzy, w tym m.in. wiedza o TSI oraz wiedza o ekonomicznych i organizacyjnych aspektach badanej dziedziny przedmiotowej. W trakcie analizy i projektowania SI są wykonywane dwa rodzaje pracy, jedna ukierunkowana na problemy, druga na dane. Zadaniem pierwszej z nich jest stymulowanie użytkowników w identyfikowaniu ich problemów oraz w spom aganie ich w trakcie procesu rozwiązy wania problemów. Opracowane modele opisują, co SI powinien wyko nywać i zawierać, aby wyszczególnione problemy rozwiązać. Zmiana akcentu następuje w wyniku zorientowania pracy na dane. Uwzględniając modele skonstruowane przez użytkowników w poprzedniej fazie, określa jak wyspecyfikowane potrzeby informacyjne powinny być zaspo kojone za pom ocą odpowiedniego sprzętu komputerowego oraz tec no logii przetwarzania danych. W konsekwencji proces analizy i projek owanie SI w metodyce ISAC dekomponowany jest na cztery następujące stadia:
praca problemowo zorientowana (intologiczna)
twarzania, tu
mum . . porozumiewaniu się
różnych grup zawodowych uczestniczących w procesie
TSI. • jako baza dla projektu systemu danych. Zadaniem fazy PSD jest stworzenie p ro jek tu niezależnego od sprzętu. Dla procedur komputerowych są konstruowane struktury danych i programów. Rozpatruje się też kwestie niezawodności, elastyczności i bezpieczeństwa stworzonych SI. Wreszcie cel obszaru adaptacji sprzętu to wybór konkretnego sprzętu i oprogramowania do eksploatacji SI oraz adaptacja opracow anych w fazie PSD modeli do wymogów tego sprzętu i oprogramowania. AS dotyczy zatem tylko komputerowych procedur SI. Dla każdej z pięciu faz opracowano zestaw metod o charakterze graficznym i tabelarycznym. Ich zestawienie zawiera tablica 4.7. Styl tych technik, omówionych szerzej w [113; 117].
1Jtvków i projektantów systemów. Różne te grupy nostr™ • * 1 ób bieżącą sytuację i problemy. Ważną zasadą AZ S v c h dotyczą dyskutow ane zmiany, powinny decydować “ °S°by’ ian są mniej lub bardziej trafne. W związku z tvm 6 Wananty rikcionalność i w yk onalno ść proponowanych zmian F badaĆ «ego kierunku zm ian oznacza stopień, w jakim rozwiązuj" pr„blem. W ykonalność z kole,, oznacza ocenę realno« w y k o n a L o n o w a n y c h k,erunkow zmran. M.mo zarysowanego uporzaiowai a l realizac ji analizy zmian, jej systematyka jest jedynie wsparciem d a w pełni twórczej działalności wykonawców tego stadium. Tablica 4.7. Techniki użytkowane w podejściu ISAC Faza TSI 1 Analiza zmian
Struktura danych
Struktura procesów
A - grały, strony tekstowe, tablice cech. tablice problemów, tablice potrzeb zmian, listy grup zainteresowań, listy celów plan nakładów
i harmonogramy TSI A - grafy, strony telcstowe, tablice cech
2. Studium działania
analiza kosztów/nakładów
listy podsystemów, harmonogramy TSI tablicei cech
3. Analiza informacji I-g ra fy , C -grafy, strony tekstowe, katalog pojęć 4. Projektowanie struktury danych
listy procesów, tablice procesów
D - grafy, strony te kstowe, tablice cech tablice projektu, stuktury zbioru danych, D -siruktury
listy programów/procesów P-slruktury, listy operacji, tablice zadań pracy
E - grafy, strony tel cstowe, tablice cech
5. Adaptacja sprzętu
opisy zbiorów/rekordów danych* w zory rozplanowania danych,
P-struktury, listy operacji, tablice pracy
D -slruktury
Analiza zm ian je s t inicjow ana przez badanie i specyfiko ^ iwiadczanych i oczekiw anych w przyszłości problemów. u(josko. !encjalne potrzeby zm ian, których przeprowadzenie m ić funkcjonowanie organizacji. Formą dokumentacji Konty»t-lemów, w yszczególniająca każdy z P™bleraÓ^ n T k T goni tej czynności je st identyfikacja grup za" \ ^ bezpośredni vodowvr,h „,„oT«.^vfiifnwane problemy ^^ kierownictwo
119
_
cio nti s i rejestrowane w postaci ich listy, w której ,kmvl„c się dotyczące jej problem y
resu TSI. Grupy każdej 7w w IU możliwo* P wpłynąć na m >
różne grupv S zaintetesowań w trakcie AZ. Nadmiar ndywidual. „Tch problemów stanowi przeszkodę w dalszej pracy toteż s , 0„e k i w a n e w grupy problemów, które stanów,c będą zalązk, przysz. d f «lów nvch działań w ram ach A -g rafu z e ro w e g o c z y sy stem o w eg o i wynOsaiicej z niego h ierarch ii A -g rafó w . Porównanie its t próbie, mów oraz grap zainteresow ań p ro w ad zi d o s tw o rz e n ia lis ty g r u p próbie.
mów.
, , . . Najbardziej pracochłonną od strony dokumentacyjnej czynnością jest opis stanu rzeczywistego badanej dziedziny przedmiotowej, bieżących działań oraz ich otoczenia. Podstawowymi sk ład n ik am i ogólnego modelu d zia ła ń są:
• A-grafy. • strony tekstowe dla poszczególnych A-grafów. • tablice cech. Do konstrukcji tego modelu wykorzystuje się rów nież dotychczasowe wyniki AZ w układzie przedstawionym na rys. 4.20. Na ogół jednej grupie problemów odpowiada jedna czynność w A-grafie ogólnym . Podstawowe oznaczenia graficzne A-grafów przedstawia rys. 4.21.
i Drzenłvu/óL ^ mie-^cu zauważyć, iż A-grafy um ożliw iają opis zbiorów materiałówi nnH6 ^ a informacXjnych ale i rzeczyw istych (rzeczy, danych p o m ie d z ^ 38 § y pozwalaJ4 jedynie na opis przepływów przedmiotowa m P™CeSa™ ' sUadnicami oraz term inatoram i. Dziedzin* e
s
zapasami towarowymi ^ 120
t
? w pracy ja k ° uproszczon^ p^ kład * 2 ^ “ ^ ISA C jeSt S08”0^
Zbiór rzeczywisty Zbiór informacyjny Zbiór mieszany
Przepływ rzeczywisty
Przepływ informacyjny
Przepływ mieszany •
Działanie
Rys. 4.21. A-grafy - oznaczenia graficzne [681
W wyniku przeprowadzonej analizy dokonano opisu, którego syntezą jest A -graf Z (rys. 4.22). Z A-grafu Z wynika, iż głównym celem gospodarki towarowej przedsiębiorstwa jest zapewnienie ciągłości* sprzedaży na rynku poprzez utrzymywanie właściwych pod względem ilościowym i asortymentowym zapasów towarów (4A), składanie terminowych zamówień (6A) na racjonalne partie zakupu oraz opracowywanie dla poszczególnych grup towarowych bądź dostawców właściwych harmonogramów dostaw (6B). W ielkość zapasów towarowych jest wynikiem czynności magazyno wania (4) - przyjm ow ania dostaw towarów (1A) i sprzedaży towarów (2A). Strum ień dostaw towarowych nie przebiega żywiołowo, lecz jest kształtowany poprzez plany dostaw towarowych (5A).Czynność planowania (5) jest realizow ana na podstawie analizy szeregów czasowych sprzedaży (2A), zawartych um ów (3A), sprawozdań z wykonania umów (3B) przez poszczególnych dostaw ców oraz z analizy wykonania planów dostaw (5B). Czynność bieżącego kształtowania strumienia dostaw towarowych podlega służbie zaopatrzenia (6). Na podstawie planów (5A) oraz raportów stanów magazynowych (4B) opracowywane są harmonogramy dostaw (6B) oraz składane są zam ów ienia (6A). Strona tekstowa w sposob bardziej szczegółowy charakteryzuje poszczególne działania, zbiory i przepływy w A-grafie Z. Przestrzeń dostępna w poszczególnych blokach na ogół nie Pozwala na pełny ich opis. Obydwie te formy dokumentacji me podają danVch ilościow ych i jakościowych o dziedzinie przedmiotowej, jej składnicach i czynnościach. Charakterystyki te podaje się w tablicach cech.
4.5. Słowniki/skorowidze danych SPR A W O Z D A N IA Z W YKONANIA UMÓW
UMOWY
SPRZEDAi, towarów
dostawy towarów
Siownik/skorowidz * * * * danych czy składnicy danych w " p o ^ c T " c S'™k,U0' P^pTywu , związanych z mmi operatorów relacy ńvc„ I T danych połam, d an y ch w bazach danych s S 'n "iki s ta ją * rodzajami operatorów: sekwencji, selekch" ó P° WiąZane Są interpretację sem antyczną i graficzną p r z Ł ™ ^ ^ ' Ch
f
MAGAZYNOWANIE
m i
P rz e d s ta w io n e w y żej tech n ik ' p rz e p ły w ó w danych. Dla o k r e ś l e m » '" '^ ^ « k a c j e e n c ii , khH . d zied zin y przedmiotowej n ie/h ,..i ■ zawadości przyszlei h adn,c'
P L A N O W A N IE
R A PO R TY STAN Ó W
N azw a
M AG AZYNO W YCH
operatora
ANA LIZA W Y K O N A N IA PLANÓW DOSTAW
plany do staw tow arów
ZA O PA T R Z E N IE
HARMONOGRAM ZAPASY TOWARÓW
ZAMÓW IENIA
Oznaczenie
Suma pewnej liczby ADRES składników danych
KOD-POCZTOWY+ MIEJSCOWOĆ+ ULICA+NR-DOMU
2. Selekcja
Wybór jednej TYTUŁ spośród szeregu wystąpień składnika danych
[MGRIDRIPROF.1
3. O p cy jn o ść
Wystąpienie określonego składnika danych 0 lub 1 raz
4. Iteracja
Rys. 4.22. A-graf gospodarki towarowej przedsiębiorstwa
fa/lrh ° raZ do
1 U^C PotencJa^ne potrzeby zmian, realizow ane w kolejnych J ° Wania ^otrzebom tym nadaje się odpowiedni priorytet stosowniej
etanv uwzetsdP.°?lię zy Poszczególnymi grupami zainteresow ań. Kolejno' iformazbbżnnp1^ Iagramowe * tabelaryczne m etody i techniki, stylem r * Dom inu^ iSA C-ow ską m etodą dokumentacji
w szerokim zakręci* v 4 . 8 ) T ^ n i ^ z ł " °ray? Wa” e Są diaSramy Jacksona (por. podroż ISAC pozw ala na ° ° P1SU d a n y ch > 1 p ro c e só w . Metodyk P ^ e js c ta p o m ię d zy p o s z c z e g ó ln y m i technikami.
Przykład
1. S e k w e n c ja
DOSTAW
Porównanie celów badanej dziedziny przedmiotowej ze sta n e m rzeczywis- jj ym (tablica problemów, A-grafy, tablice cech) um ożliw ia dokonanie jego'
Interpelacje
ADRES KLIENTA
ZAMÓWIENIE Wystąpienie określonego składnika danych 0 (praktycznie 1) lub więcej razy
ADRES-WYSYŁKI+ (ADRES ROZRACHUNKU)
{DATAZAMÓWIENIA+ NAZWA-KLIENTA+
A D R E S -W Y S Y Ł K I+ POZYCJAASORTYMENTOWA}
Przepływy danych oraz składnice danych są najczęściej odpowiednikami dokumentów w ystępujących w danej organizacji gospodarczej. Przykładem jest tu zam ów ienie towarów. Poprzez w yod ręb n ien ie składników danych oraz określenie operatorów relacyjnych m ięd zy nim i następuje zdefiniowanie słownika/skorowidza danych w układzie: ZAM ÓW IENIE = ^ P -Z A M Ó W IE N IA + DA T A -Z A M Ó W IE N IA + 123
+ n a z w a
adres
-d o s t a w o
+
+
{K O D -T O W A R U +
n a z w a -t o w a r d
+ ILOŚĆ-ZAMÓWIONA + CENA TOWARU + WARTOŚĆ-TOWARU} + WARTOŚĆ-OGÓLEM Naturalnie w ten sposób można opisać wszystkie dokumenty wy. stępujące w analizowanej i projektowanej dziedzin.e przedmtotowej. Pozwał, Wtspecyftkowanie atrybutów encji występujących w modelu związków encji Porównanie atrybutów pozwala na unikntęce redundancj, poprze, wyeliminowanie powtarzających się składników danych. Słownik/skorowidz danych umożliwia określenie zawartości bazy danych poprzez zdefiniowanie struktur danych. Ma to szczególne znaczenie w przypadku relacyjnych baz
,0 „
a
danych.
4.6. Normalizacja relacyjnego modelu danych 4.6.1. Relacyjny model danych Model ten został zaproponowany przez Codda [25; 26] i m iał znaczący, praktyczny wpływ na rozwój baz danych na świecie. Począw szy od lat osiemdziesiątych systemy baz danych były zdom inow ane przez podejście relacyjne. Ma ono swoje źródło w teorii algebry relacji, która stała się punktem wyjścia rozwijanej dynamicznie teorii relacyjnych baz danych. W niniejszym opracowaniu zrezygnowano z szerszej jej prezentacji na rzecz spojrzenia na model relacyjny z punktu w idzenia użytkownika. Podstawowym pojęciem modelu jest oczywiście relacja. Definiuje się ji najprościej jako [72, s. 583] dwuwymiarową tablicę elem entów . Tak więc dla przykładu tablica 4.9 przedstawia znorm alizowaną relację STUDENT. Należy zwrócić uwagę na pew ne własności pow yższej tablicy, stanowiącej relację. Na przecięciu wiersza i kolum ny relacji znajduje się jedna dana elementarna, nierozkładalna, a nie zbiór w artości. Każdy *Cy nazywa s*ę krotką (ang- tupie) W relacji nie m a powtórzeń i U* to e k ma znaczenia - relacja pozostaje §■
7
Tnf
STUDENT w y n o f l “ 124
KCZn° ŚĆ relaCji' W
reW
Tahlicą 4.9. RelaC¡a: STUDF.NT
Każda relacja ma pewne własności zwane atrybutami. Odpowiadała one kolumnom tablicy. W przypadku relacji STUDENT atrybutami , a
Nr-legit. Imię, Nazwisko itd. Specyfikacja airybutów pozwala na przyiecie następującego opisu relacji STUDENT: STUDENT < Nr-legit, Imię, Nazwisko, Rok, Grupa, Kier-stud> Dane elem entarne w kolumnie są jednorodne (tego samego rodzaju), tzn. danemu atrybutowi przypisana jest określona dziedzina (domena) dopuszczalnych jego wartości. Dziedzinami wartości dla poszczególnych atrybutów są np.: Nr-legit Imię
Nazwisko Rok Grupa Kier-stud
- zbiór numerów legitymacji danej uczelni, albo zbiór liczb naturalnych w określonym przedziale, - zbiór dopuszczalnych prawem imion, albo zbiór skoń czonych sekwencji liter, spacji oraz dywizu (imiona dwuczłonowe), - zbiór nazwisk albo zbiór skończonych sekwencji liter oraz dywizu (nazwiska dwuczłonowe), - skończony zbiór liczb naturalnych [1, 5], - skończony zbiór liczb naturalnych [10, 59], - zbiór kierunków studiów w danej uczelni albo zbiór sekw encji liter i spacji.
Atrybutom przypisuje się unikalne nazwy. Liczba atrybutów określa liczbę członów w danej relacji. Relacja STUDENT jest 6-członowa. Różne atrybuty w jednej lub w wielu relacjach mogą być związane z tą samą dziedziną. K olejność występowania atrybutów nie jest, jak w prz\ padku kotek, znacząca. Przedstaw ione wyżej zależności pozwalają na bardziej r ścisłą definicję relacji [29, s. 80]. Otóż jeżeli istnieją zbiory £>„ D:, niekoniecznie różne, to R je s t relacją na tych zbiorach, jeśli jest to zbiór r i I “Porządkowanych krotek takich, że ii, e £>,, d2 e D,
I
i
125
e D„. Zbion />,. />:......U nazywaim dziedzinami relacji R. „ zaś )jc?b członów tej relacj i. ^ W każdej relacji co najmniej jeden atrybut pełni rolę 'rfentyfikat0r zwanego kluczem lub kluczem głównym. Pozwala on jednoznaczn*’ identyfikować k w rek'idenlvfik.iwać krotki krolki relacji. Klucz K l u c z główny fio u n y można oznaczyć ja jak relaci I STUDENT .Nr-legil i. Jl W celu zapewnienia jednoznaczności identyfikacji krotek klucz głóWn może składać się / kombinacji atry butów (w skrajnym p r z y p a l I z wszystkich atrybutów atrybi relacji). Jest to t/w. k lu c z z ło ż o n y . W relacji m0ż znajdować się kilka kombinacji atrybutów ....... rposiadających - — “j«i^i1 " wiasności w łasn o J Mówi h fV k a<*iiuyuujących n d y d u ją c y c h ]y|> foj, la e n m iK a c y jiie . im u w i się mv wówczas uo k iMluUcLz/zadcm identyfikacyjne. ] i! potencjalnych. Wreszcie w sytuacji, gdy atrybut dy w relacji Rl występuje atrvh,„ if*7PŚnip jego iPcrn wartości u/itrfnć/M o« ----* > który nie jest kluczem głównym, a jednocześnie są wartościam klucza głównego innej relacji R2, wtedy mamy do czynienia z kluczem obcym. Zależności między kluczami pozwalają na utrzym anie spójności . między relacjami w bazie danych. Cechę tę najlepiej można przedstawić na przykładzie bazy danych obsługi ocen studenckich. W przykładowej bazie w systępują trzy powiążą r w ić J Z , relacje: icje; ei nrr*wT»-V»-»% -
—
STUDENT (lab. 4.9), WYKŁAD (tab. 4.10) i O CEN A (tab. 4.1 j).
następująco:
• 'W ,o „ y c h
,
cJath Przedsiawia sie W YKLA D < Na7w CJaCh' ? W ,?C 0 C E N A T N ~ r'„ Rok „ ... - * « - N« - » y k . S to p ią ^ wiście zakłada się, Ze JCSt. u" lka,na, wykład j est’ Dr " t T * Wykładu studiów u, , tom,dst w reJacji OCENA wv«u ° y Pf2ez Jednego TŚ* . y danych wyraża , ! PUJe klucz 2łożonv c y ?®Wcę, na. , a ę wsp6,"*mi dziedzir j;nośf tej • * . relacje STU D ENT , O C EN a określonych ,, STlJOENT, OCENA • okreslonych
tyłikacyjnych studenta oznar™ aj\ WSpÓlną dz«edzine n..m i Nr-stud. ' cz°nych odpowiednimi merow iue 'den„ ... ^ p jw ie d n im i atrybutami: Nr-les 11 relacje W YKŁAD i OCENA ............. Utam' : relacje W Y K ŁA D i OCENA mają wspólną dziedzinę nazw przedmiotów
oznaczonych odpowiednio atrybutami: Nazwa i Naz-wyk
. relacje STU D EN T i W YKŁAD mają wspólną dziedzinę roku studiów studenta i wykładu oznaczonych odpowiednio atrybutem Rok i Rok-w Tu właśnie pojawiają się podstawowe cechy relacyjnej bazy danych bowiem zw iązki między krotkami są reprezentowane przez wartości atrybutów pochodzących ze wspólnej dziedziny.
Tablica 4.10. Relacja WYKŁAD — ł
N azw a
-------
1
ek on om ia
W y k ła d o w c a
R o k -w
O lsze w sk i
II - g o d z .
1
60
socjologia
S z c z e p a ń sk i
2
15
finanse
W ie rzb a
2
30
j sym ulacja
K o n d ra to w ic z
15
T a b lic a 4 . 1 1. R e la c ja O C E N A r — -------------------------
N r-stud 10308 10308 15921
J
N a z -w y k s o c jo lo g ia
1
S to p ie ń
[
1
3 ,0
1
s y m u la c ja e k o n o m ia
Ttnnn a ekonom i
4 ,5 1
5 .0
4 ,0
so c jo lo g ia e k o n o m i;
2.0
[
4.6.2. Przebieg normalizacji modelu relacyjnego Analiza dokum entów, przeprowadzona w podrozdz. 4.5 wykazuje, iż wiele dokum entów cechuje się występowaniem g ru p powtarzanych, np. grupy ^ pow tarzającej POZYC JA-ASORTYMENTÓW A dla dokumentu ZAMÓWIENIE. Poniew aż model relacyjny wymaga atomowych, nierozkładalnych danych na przecięciu wiersza i kolumny, relacja ZAMÓWIENIE a w konsekw encji cała relacyjna baza danych cechowałaby się dużą nadmiarowością danych - redundancją. Miałaby ona znaczący wpływ na podniesienie kosztów przechowywania i użytkowania nadmiarowych baz danych. Istnieje zatem konieczność racjonalizacji organizacji relacyjnych struktur danych. M ożliwość taką stwarza metoda normalizacji. Idea ta a jednocześnie technika opracowana przez Codda [26] uwzględnia trzy Postaci norm alne. A ktualnie istnieje możliwość normalizacji relacyjnego modelu danych do piątej postaci [62]. Dwie ostatnie postaci normalne dotyczą przypadków szczególnych w analizie danych. W niniejszej pracy ograniczono się do trzech postaci, co ma praktyczne znaczenie w infor matycznych systemach zarządzania. Dzięki procesow i normalizacji relacji można wyodrębnić relacje 0 najwyższym stopniu niezależności danych, ustalić odpowiedni zakies
amtmtów związanych z daną relacją, a w konsekwencji w fazie ekSp|oal han danych ocraniczyć do n ie/W n eg o minimum czynności z w j * z/ operacjami iworzenia. skreślania, modyfikacji i wyszukiwania. -• -4UU# jeg. ■, model konceptualny został opracowany, to technika normalizacji m również służyć sprawdzaniu jego poprawności albo tworzeniu bard°^ elastycznego modelu, odpowiadającego przyszłym zmianom, które m mieć miejsce przy realizacji wyżej wymienionych operacji. Wedłuo q ^ proces normalizacji relacji przebiega na trzech poziomach nazyw odpowiednio pierwszą, drugą i trzecią postacią normalną. W nawi • do modelu danych gospodarki zapasami towarowymi proces ten z 0,0 zrealizowany do trzeciej postaci normalnej, z pom inięciem for strony zagadnienia, omówionej w cytowanej literaturze. P ro c01 przedstawiony jest na rys. 4.23 [72J. Gs ie,!
PLIKI NIE ZNORMALIZOWANE
(rekordy z powtarzanymi grupami danych)
1. Dekompozycja wszystkich struktur danych w dwuwymiarowe rekordy
PIERWSZA POSTAĆ NORMALNA (rekordy bez grup powtarzanych)
2. Dla rekordów ze złożonymi kluczami głównymi sprawdzenie czy pozostałe atrybuty są zależne od całego klucza. DRUGA POSTAĆ NORMALNA (wszystkie niekluczowe atrybuty są w pełni funkcjonalne zależne od klucza głównego)
3. Sprawdzenie prawazenie funkcjonalnych zależności między atrybutami niekluczowymi TRZECIA POSTAĆ NORMALNA (wszystkie niekluczowe atrybuty są w pełni funkcjonalne zależne od klucza głównego i wzajemnie niezależne) Rys. 4.23. Proces
■Mnalizacji
K lK y ^
^
^
[72]
Załóżmy, ze dostawę towaru, rozlokowaną w magazynach przedsięhiorstwa handlowego można opisać za pomocą następującej relacji-' TOWAR < Sym ol-towaru. Nazwa-,owaru, Ccna-jednosikoJa iS to w a r u Sym bol-dostaw cy Nazwa-dostawcy, (Nr-magaz.ynu, Adres', Powierzchnia, llosć-w-magazynie) > A!iy df?K,c? laCja być znorma'*zowana w pierwszej postaci normalnej (IN h), wszystkie elementy relacji powinny zawierać jedynie wartości zatomizowane, tak jak w przypadku relacji STUDENT. Pierwszy etap n o rm alizacji polega na wyodrębnieniu grup powtarzanych atrybutów ¡ utworzeniu z nich nowych relacji. Pierwsza postać normalna (INF) relacji TOWAR (po dodaniu do nazw subskryptu 1) będzie przedstawiała się następująco: TO W A R -1 < Sym bol-tow aru, Nazwa-towaru, Cena-jednostkowa, Ilość-towaru. Symbol-dostawcy, Nazwa-dostawcy> ZAPAS-1 Identyfikator wyjściowej relacji staje się atrybutem każdej nowej relacji, choć nie musi stać się atrybutem kluczowym tej relacji. Drugi etap w procesie normalizacji polega na określeniu funkcjonalnych zależności zw iązanych z atrybutami kluczowymi i takim wyodrębnieniu relacji, że ich atrybuty niekluczowe są w pełni funkcjonalnie zależne od klucza głównego. Proces ten dotyczy więc relacji o kluczu złożonym. Atrybuty są funkcjonalnie zależne wówczas, gdy wartość jednego z nich jednoznacznie określa wartość drugiego, np.: Symbol-towaru <— Nazwa-towaru Nr-magazynu <— Adres W wyniku opisanych czynności relacje są w drugiej postaci normalnej (2NF). D la podanego przykładu w 2NF otrzymuje się następujące relacje: TO W A R -2 < S vm bol-tow aru, Nazwa-towaru, Cena-jednostkowa, Ilość-towaru, Symbol-dostawcy, Nazwa-dostawcy > ZAPAS-2 < Sym bol-tow aru, Nr-magazynu, llość-w-magazynie > MAGAZYN-2 < Nr-m agazynu, Adres, Powierzchnia> . . . W trzecim etapie normalizacji następuje identyfikacja funkcjonalnych zależności m iędzy atrybutami niekluczowyińi oraz wyodrę nieme w związku z tym nowych relacji. Każdy atrybut niekluczowy staje się zależny od klucza głównego. Po wykonaniu tego etapu atrybuty m uczowe są wzajemnie niezależne - nie ma między nimi tunkcjona nyc z ezn Sytuacja ta dotyczy relacji TOWAR-2, gdzie można wyod¡*bn£ r £ DOSTAWCA, w związku z funkcjonalną zależnością po ę 0 bolem-dostawcy a Nazwą-dostawcy. Ostatecznie, trzecia p> (3NF) relacji TO W A R w wyniku procesu nonnahzacji p następująco:
129
N-izwa-towaru. Cena jednostkowa, \\oit r n w \R-1 towaru. S>m t
n r ia .,ZVnu, Ilo śe -w -m a g a /y m e >
Z A P A S -3 < S y m M ± ^ ’-y* i L X j ^ 7 ^ v ie r z c h n ia >
MAOAZYN-3 <
ą
«
^
; ‘ Ńa/\va-ciost;iwcy>
DO STAW C A -.' ^ ¿ ¡ ^ r ^ n a l n a z punktu w id z e n ia o g ra n ic z ę « , Postać ta jes n i ^ /weiyfikować. p o ró w n u ją c opracowany
p'cov « 4 i druga postacią nonnalną. a zwłaszcza z relacj, nieznormalizowaną.
4.7. Techniki decyzyjne 4.7.1. Rodzaje technik decyzyjnych Procesy opisywane w diagramach przepływu danych cechują si? wzajemnymi powiązaniami nazywanymi logiką system u. Dogodnymi narzędziami opisu wzajemnych związków logicznych w procesach są techniki decyzyjne, do których należy zaliczyć przede w szystkim tablice decyzyjne a następnie język strukturalny i drzewa decyzyjne. 4.7.2. Tablice decyzyjne Tablice decyzyjne to jedna z technik służących rozwiązywaniu problemów (por. [64; 87; 114]). Dzięki tablicy decyzyjnej m ożna w zwięzły sposób określić, jakie czynności (działania) należy podjąć przy spełnieniu pewnych, z góry określonych warunków. Tablice często lepiej - w porów naniu z innymi metodami - nadają się do określania czynności, które wynikają z przeprowadzenia skomplikowanych prób, poniew aż: • można sprawdzić, czy wzięto pod uwagę wszystkie m ożliw e wyniki prób, • ukazany jest związek między przyczyną (warunki) a skutkiem (decyzje). • dla ułatwienia analizy różnych kombinacji w ariantow e rozwiązania umieszcza się obok siebie. Opracowane po raz pierwszy w firmie General Electric tablice decyzyjne pozwalają w bardzo poglądowy sposób przedstaw ić złożone zależności i związki. Zazwyczaj niesłusznie wiąże się technikę tablic decyzyjnych wy ączme z metodami informatycznymi. W ielką zaletą tablic decyzyjnych jest to, ze można je stosować bezpośrednio w pracy kierowniczej ilustracyjnej, ponieważ zapis i rozum ienie tablicy decyzyjnej nic Z Z f ł 3 Znajt° ^ ości technik 1 metod informatycznych. W spom niany stereotyp P awił, ze tablice decyzyjne są wykorzystywane głów nie na wszystkich 130
etapach projektowania systemów informatvc7 nv h projekcie ogólnym, projekcie technicznym i w , V ? * Wanalizie ^ te m u , Tablica decyzyjna jest określona stmktnr. Pohamowania, sobą re g u ł decyzyjnych. Każda tablica p o d z i e l '80 Zbl0rU związanych ze „loki (pola) i posiada struktur* przedstawioną u 7 ******
Nazwa tablicy
Reguła l1 9- ........................ ...
1 Warunki o im
Czynności
3 Wybór 4 Wybór czynności
A oto treść i interpretacja poszczególnych bloków: 1. W ARUNKI (inne określenia, założenia warunków, zbiór warunków): sform ułowanie warunków niezbędnych w procesie decydowania. Blok zawiera zapisywane poziomo w kolejności logicznej wyrażenie typu „JEŚLI ... , określające zmienne, które wywierają wpływ na proces decyzyjny. 2. CZYNNOŚCI (inne określenia: działania, decyzje, zbiór czynności). Blok ten stanowi wyszczególnienie wszystkich możliwych czynności, które m ogą być realizowane w wyniku określonej kombinacji warunków ujętych w części pierwszej tablicy decyzyjnej. W nawiązaniu do wyboru warunków blok drugi zawiera wyrażenia typu „TO...” . 3. W YBÓR W A R U N K Ó W (inne określenia: opis warunków, pozycje warunków, w skaźniki lub układy warunków) - prezentuje konkretne stany (w artości) poszczególnych warunków. Umieszczone w tym bloku symbole w skazują, czy warunek umieszczony w danym wierszu bloku warunków je st spełniony, nie jest spełniony lub nie ma wpływu na decyzje. K ażdy warunek może być oznaczony następującymi symbolami: T (TAK) lub 1 - w arunek spełniony, N (NIE) lub 0 - w arunek nie jest spełniony, lub spacja - warunek nie jest znaczący. 4. WYBÓR CZY N N O ŚCI (inne określenia: decydowanie, opisy działań, pozycje czynności) — zaw iera symbole identyfikujące czynności odpowiadające danem u układowi warunków. Stosowane w tym o u symbole m ają następujące znaczenie: X - czynność (decyzja) ma być podjęta, - , lub spacja — czynności nie należy podejm ow ać.
■ I S K P K o t ó pomiędzy czterema głównymi częściami w #i( decyzyjnych można ująć następuj*»: • warunki możliwe
• warunki spełnione • czynności możliwe
' CZp " tó e m 'ś S rz w i,z a n y m z wyborem wanmków i wyborem czy„ności j e . reo ła decyzyjna (kolejne kolumny tablicy decyzyjnej), czyi, wyrażeń* L jace. jaki warunek iub układ warunków mus, hyc spełń,ony, aby została podjęta zdefiniowana czynność lub grupa zdeftmowanych czynności. Renuły decyzyjne to zatem kombinacje warunków , działań, możliWe w danej sytuacji decyzyjnej. Liczba reguł decyzyjnych ściśle wiąże sie z liczba możliwych warunków. Jeśli występuje w warunkach, to zakładając binarny opis warunków (T lub N), maksymalna liczba reguł wynosi 2*. W praktyce, rozpatrywana liczba reguł jest na ogół m niejsza. Ostatnim elementem tablicy jest jej nazwa związana zarówno z istotą rozwiązywanego problemu, jak i inwencją autora tablicy. Istnieją trzy podstawowe postaci tablic decyzyjnych: • proste. • rozszerzone (rozwinięte). • mieszane. Przedstawiony wyżej opis struktury tablicy decyzyjnej dotyczy tablicy prostej. W rozszerzonych (rozwiniętych) tablicach decyzyjnych, w blokach wyboru warunków i wyboru czynności nie stosuje się sym boli T, N, lub X dla oznaczenia warunków lub decyzji, lecz zapis słowny lub skrócony. W celu odczytania warunku trzeba połączyć zapis umieszczony w bloku warunków z zapisem w bloku wyboru w arunków . Podobnie, aby odczytać czynność (działanie), należy połączyć zapis zam ieszczony w bloku działań z zapisem w bloku wyboru działań. W tablicach decyzyjnych mieszanych stosuje się zapis i oznaczenia wskaźników warunków i czynności zarówno z tablic prostych jak i rozwiniętych. zasadW k° nStrU0Waniu tab,ic decyzyjnych należy przestrzegać następujących • z wszystkimi warunkami wiążą się odpow iednie czynności, k o m b i ^ 0 • 0mbinacj i wartjnków nie m ożna w iązać z różnymi kombinacjami czynności, jeden raz1^ ^
decyzy-*na winna ty ć zarejestrow ana w tablicy tylko
Przedstawione posłużyły do anaii™ ; • IC&uiy Konstruowania tablic decyzyjny^ występujących w i ™ZWIązama wieiu problem ów decyzyjny^1 żujących w działalności przedsiębiorstw handlow ych. Do g f 132
egzemplifikacji w niniejszym rozdziale wybrano zagadnienia analizy wniosku kredytowego (przykład A) oraz przyznawania nagród zespołom pracowników sklepów za wyniki w sezonie letnim (przykład B). W opisach przykładów dokonano również pewnych uogólnień i skrótów. W przykładach tych chodzi bowiem głównie o aspekt dydaktyczny, pełną i klarowną weryfikację omówionych uprzednio zasad stosowania tablic a w konsekwencji inspirację do samodzielnych zastosowań w różnorodnych sytuacjach decyzyjnych organizacji gospodarczych i administracyjnych. P rz y k ła d A Przedsiębiorstwo handlowe pragnie zwiększyć swoje obroty, a tym samym osiągnąć większy, związany z nimi zysk. Nie posiada ono dostatecznych własnych środków w obrocie, aby sfinansować zakupy w celu zgromadzenia niezbędnych zapasów towarowych. W tej sytuacji przedsiębiorstwo handlowe występuje do banku z wnioskiem o kredyt. Przy podejmowaniu decyzji odnośnie do zgłoszonego wniosku bank analizuje osiągnięte wartości następujących relacji ekonomicznych w przedsiębiorstwie (winny one być zatem wcześniej przeanalizowane przez kierownictwo przedsiębiorstwa handlowego): 1. Relację między dynamiką wzrostu kosztów a dynamiką sprzedaży w badanym okresie (wskaźnik O), 2. W skaźnik cyklu rozliczeniowego należności Wn wyrażony następującą zależnością: Wn =
N xO
gdzie: N - bieżące należności wobec dostawców, S - wielkość sprzedaży, 0 - liczba dni w danym okresie (tu kwartale, a więc 0 - 9 0 ) . G ranicznym i w ielkościam i w odniesieniu do powyższych wskaźników są odpowiednio: dla 0 = 1 , a dla W„= 18 dni. Uwzględniając r żne om ma j wartości pow yższych warunków bank może podjąć następujące
15 .“
1—
4. Nie przyznaw ać kredytu. A oto poszczególne reguły decyzyjne: 1- Jeżeli w badanym okresie relacja ^ (wskaźnik O ) je st m niejsza od 1, a wskazm
m
kosztów i sprzedaży ‘ Uu roziiczeniowego y
należnościW od18 p e ł n e j w y s o k o ś c i . 2.Jm enżeielijszw s k a ź n i k y n i ż 1 8 d n i . n a l e ż y k r e d y t p o d w y ż s z o n y m JeżeliwskaźnikD je s t w ię k s z y l u b r ó w n y p r z y z n a ć k r e d y t o g r a n ic z o n e j w y s o k o ś c i w sf^ downioskowanw esgkoa.źnikisąwiększe (odpowiednioporów w n y i n i e n a le ż y yższego przedstawia m niejszy
w
d n i. n a le ży p rz y z n a ć k re d y t bank
D je st m n iejszy od I a w s k a ź n ik Wn ró w n y | uh p rzyzn ać oprocentow aniu.
przy
3.
w p e łn e j w y s o k o ś c i i d J dnaJ(
I. a w sk a źn ik
18 dni. należy
%
m n ie jsz
w
Ul,kti
4. Jeżeli obydwa D
I
Rozw iązanie
od sw o ic h g ra n ic z n y c h w ie lk Wn ró w ny 18 d n i) p rzy zn a w a ć Lr° ''C* problem u
ta b lic a d e c v
J• a 4.13
Tablica 4 1 1 Tablica decyzyjna oceny wniosku kredytowego Reguły decy/yjnc Kredvt bankowy
I. Wskaźnik D>1
W skaźnik W' < 18 dni 1. Przy/nać kredyt w pełnej wysokości 2. Przyznać kredyt w pełnej wysokości przy podwyższonym oprocentowaniu 3. Przyznać kredyt u ograniczonej wy sokości 4. Nie przyznawać kredytu
Przykład B Kierownictwo przedsiębiorstwa handlow ego postanow iło przyznać nagrody zespołom pracowników poszczególnych sklepów za wkład prac) w okresie czterech miesięcy sezonu letniego oraz osiągnięty wzrost obrotów . Brano pod uwagę następujące warunki: 1. Czy zespół pracowników zrealizował pełny w ym iar czasu pracy sklepu? 2. Czy zespół przekroczył średniomiesięczną dynamikę obrotów wynoszącą 115% w stosunku do średniej poprzednich m iesięcy roku? zależności od stopnia spełnienia powyższych kryteriów podejmować s ą ecyzje o przyznaniu poszczególnym załogom zróżnicow anej w ysokości decyzyjne 10° %'
^ bowiązuj^ Przy tym następujące regu1)
d y n am ik ^ * zr®ajiz°w ał pełny w ym iar czasu pracy sklepu i uzysk® przyznanaSpełna n a g r o d a ^
‘° “ Staje PracownUcom
I
c\
jeżeli przewidywany wymiar czasu pracy „ie ™ fat . dynamika obrotów byta wyższa niż 115%, należy t nagrody. y p y nac /5% wysokości
3, jeżeli załoga zrealizowała pełny wymiar czasu pracy sldenu lec, • rfo|ała asrrignae 115% wzrostu obrotów, to uzyskuj/ona 50% w“ „ t ś c i
SPel" '0"e’ " * * * *
4' p r f y z n a w a f "
należy
syntetycznym ujęciem i rozwiązaniem przedstawionego zagadnienia jest prosta tablica decyzyjna (tablica 4,14). gaaniema
Reguły decyzyjne
Nagrody 1 1. Czy pełny wymiar czasu pracy sklepu zrealizowany
L
2. Czy dynamika obrotów >115%
T
T
1. Przyznać nagrodę w pełnej wysokości
2
3
4
N
T
N
T
N
N
X
2. Przyznać 75% wysokości nagrody
X
3. Przyznać 50% wysokości nagrody
X
4. Nie przyznawać nagrody
X
W naw iązaniu do uprzednich wyjaśnień omawiany problem przed stawiono i rozw iązano w tablicy 4.15 w postaci rozszerzonej tablicy decyzyjnej (P oznacza pełny wymiar czasu pracy sklepu, a N - niepełny). Tablica 4.15. Rozszerzona tablica decyzyjna premiowania pracowników Reguły decyzyjne Nagrody dla załóg sklepu 1
2
3
4
P
N
P
N
2. D ynam ika obrotów
>115%
>115%
<115%
<115%
3. W ysokość nagrody
100%
75%
50%
1. W skaźnik czasu
1
0%
Porównanie tablic 4 .1 4 i 4.15 wskazuje, iż konstrukcja rozwiniętej iablicy decyzyjnej p row ad zi do znacznego zredukowania pierwo yc Um iarów adekw atnej prostej tablicy decyzyjnej, uproszczenia zapisu
135
ctosowanie tej postaci w odniesieniu do opisll
'Todczyt"- Toteż zaleca W » ; wiciu prohleniów dce>z l . ^
„ programach lo m p u - . bardziej dogodne sa tablicy decyzyjnej należy za.
oraanizacji gospodarczych. na tabUcach
Natomi®,,
ciecyzyjnych
e D|a „konstruowania mieszanej lć „znaczenia zarówno z labliCJ,
4.14, jak i 4.15.
wskazują, iż tablice decyzyjne są użyteczn, Zaprezentowane p r z y jJ a d ^ ^ ^ ^ decyzj'i zrutynizow anych, , wię’
technika » Pr/>p
decyzyjne sa stale w dłuższym okresie. Dziedzinami
^ • I n T T o d a ^ m i nii ich stosowanie w sferze, np. ekonomiki z e d ie l orsma. są: zakupy lewarów , wybór dostaw cy, nal,czarne kar umownychl cospodarka zapasami (przekwalifikowań,e zapasów , wybó, paramenów modeli zapasów ), sprzedaż (przecena tow arow . przyjmowanie zamówień), działalność zatrudnieniowo-płacowa (zasady przyjmowania i awansowania pracowników, wypłacanie dodatków i za siłk ó w , naliczania naeród) czy system finansowy (obliczanie stawek podatków i innych obciążeń). W przypadku podejmowania decyzji w sytuacjach probabilis tycznych (szybko zmieniający się zakres warunków i d ecyzji) - rola i znaczenie tablic decyzyjnych bynajmniej nie m aleją, jakkolw iek ich aktualność jest znacznie krótsza (np. w an alizie rynku). Przykłady i możliwości wykorzystania tablic decyzyjnych istnieją w większości stanowisk pracy, zwłaszcza na stanowiskach k ierow n iczych . Zakres ich stosowania zależy od inwencji podejmującego decyzję. N iezależnie od tego, czy stosuje się tablice decyzyjne w p ro b a b ilisty czn y ch , czy w deterministycznych procesach decyzyjnych, ich duża ścisłość konstrukcyjna zapewnia zarówno pełność ujęcia zagadnienia, jak i elim in o w a n ie nadmiaru informacji.
Oprócz niewątpliwych zalet tablice decyzyjne m ają pewne wady. Główna z nich to duży zakres reguł decyzyjnych R w przypadku większej liczby warunków (R = T ). Część z nich jest redukowana poprzez logiczną analizę problemu decyzyjnego. Również określone metody formalne pozwalają na eliminację możliwych do w ystępow ania sprzeczności i nadmiarów. Oddzielnym zagadnieniem jest stosowanie tablic decyzyjnych z wykorzy staniem komputerów. Zastosowanie tablic decyzyjnych do opisu ^CSt znaczn‘e mniej rozpowszechnione aniżeli schematów świp^W^° i ° Z^ ^ a^ram^w Jacksona. Niemniej jednak opracowano ua decyzyinp3 ^ szereg Pr°gramów i systemów przekształcających tablice translatory n n r ? f r d m y - k ° m p U te r0 W e ’ ^ i n t e r p r e t e r y , p r e p r o c e s o r y czy motanych narzei ’ vWaniC decyzyjnych z wykorzystaniem wspo
» w L y c S c lri ? r° ','yCh P°ZWala R ó w n i k o m na a u to m a ty « yc" proccdur Podejmowania decyzji. 136
4.7.3. Drzewa decyzyjne i język strukturalny T e c h n ik a drzew decyzyjnych jest blisko spokrewniona z tablicami
decyzyjny1™- Poszczególne luki drzew oznaczają warunki, natomiast węzłv _ sp ełn ien ie warunków lub czynności. Dla przykładu A drzewo decyzyjne, nawiązujące do zasad przyznawania kredytu bankowego (przykład A tablica 4.13), przedstawia się jak na rys. 4.24. Wskaźnik
D
Wskaźnik Wn Wn < 18 - pełny kredyt
Wn> 1 8 - pełny kredyt z podwyższonym oprocentowaniem
Wn < 1 8 - kredyt w ograniczonej wysokości
Wn > 18 - nie przyznać kredytu
Rys. 4.24. Drzewo decyzyjne przyznawania kredytu bankowego
Sytuację decyzyjną z przykładu można opisać również za pomocą języka strukturalnego (ang. structured English). Poszczególne reguły decyzyjne m ożna przedstawić w postaci ściśle powiązanych wyrażeń typu „JEŚLI.. .TO ...IN A CZEJ” :
in a c z e j
D cl I JEŚLI TO INACZEJ TO D£1 JEŚLI TO INACZEJ TO
Wn<18 pełny kredyt Wn>18 pełny kredyt, podwyższone oprocentowanie Wn<18 kredyt w ograniczonej wysokości Wn>18 nie przyznawać kredytu
137
4.8. Diagramy struktury , „ r o i e k t o w a n i a technicznego oraz. pr„jek.
,
r % i ; , — " V »•''odniesicnin do projektowania M * one zastosowanie " ¡ ¿ vslvwane są również, jako technika i,„ n
nroeramów. ale *ykor/
funkcjonalnej dekompozycji poziomie projektu technicznego. D strukturę systemu lub imH,ułów. zawierają one dodatki
.
jujl| archltekturę system u na
y¡ct odzwierciedlają ^lam . hierarchję wzajemnych zależności , wy danych i sterowania miedzy
modułami. . są L węzłów, czyli modułow, oraz Diagramy struktur zbudo Przedstawiają one moduły systemu tuków, czyli powiązań m iędj, j slerowania. Diagramy ,„h programu p o w n ązan p P ^ ^ hierarchicznej, struktury najczęściej pr/y o j * również pow iązania sieciowe. choć w ramach “ ^ ^ i e n i u do opracowania listy piać Przykład diagramu st > poszczegó,ne moduty wykonywane są od przedstawiono na o 1*-
~ •
kiwania rekordu pracownika do
pro»fam ^TieichicinieP zdekomponowanym do modułów. Interpretacje poszczególnych symboli graficznych w diagramach struktur przedstaw« rys. 4.26. Przygotowanie listy płac
CM
Nr pracownika Identyfikator ^ Rekord pracownika Wyszukiwanie rekordu pracownika
Nazwisko pracownika
Płaca brutto
o^Płaca netto
Obliczanie płacy brutto
Obliczanie płacy netto
Szczegóły potrąceń (podatki, ubezpieczenia) /
/
‘/
/
i
/
'
Drukowanie czeku
Potrącenia ogółem
.......
.
Oblicz potrącenia
Rys. 4.25. Diagram struktury - opracowanie list płac
J
' •
• ■<
ł
M odul
Pow iązanie
przywołaniu innych modułów przez dany n S u ł
V
Złącza danych i identyfikacji
O
#
? fi!T n ? a ełementów danych lub identyfikacji z jednego modułu do drugiego (sterowania)
Główne decyzje Wybór jednego spośród Kilku modułów i przekazanie mu sterowania
S p r z ę ż e n ie zw r o tn e
Powtórzenie określonego modułu od 0 do n razy
Rys. 4.26. Symbole graficzne w diagramach struktur
Analiza diagramu (rys. 4.25) wykazuje, że moduły reprezentujące poszczególne zadania uporządkowane są w trybie zstępującym jako kolejne submoduły w hierarchii. Zadania wykonywane przez moduły na niższym poziomie diagram u struktur cechują się coraz większym poziomem szczegółowości, bowiem każdy moduł wyższego poziomu obejmuje zadania realizowane przez moduły na niższym poziomie. Moduł stanowi więc odpowiednik jednorodnego choć podzielnego zadania. Każdy moduł opisany jest jedynie przez sw oją nazwę, która ściśle powinna oddawać jego treść, bowiem diagram y nie pozwalają na inny opis zawartości poszczególnego modułu. Opisu tego można dokonać przy pomocy innych technik, zwłaszcza decyzyjnych. M oduły w diagramach struktur wykonywane są w kolejności zstępującej a na danym poziomie hierarchii od lewej do prawej. Moduły na różnych poziomach zintegrowane są za pomocą powiązań. Powiązanie pom iędzy dwoma modułami na kolejnych poziomach oznacza Przekazanie sterow ania z modułu wyższego poziomu — przywołującego ~ do modułu niższego poziomu. Moduł na najwyższym poziomie, nazywany rdzeniem, inicjuje sterowanie w systemie lub programie. Moduły nie 139
n l rdzenia sterowanie przekazywane • modu!y powl,lny byc luźno związane, minimalnie wzajemnie zależne . . sll|imodułó'V są liśćnj'' i . yion1ów. Jeden moduł może ograniczaw p yw przyszłych zmian w jednym module na inne moduły. - zwrócić uwagę, ' 1^ nj/szefio stopnia k<>lcJ M-deży ¡* 1 owyzsze charakterystyki diagramów struktur wskazują że s i c o pposiatlaj‘ r/c IZ p oIw u 2 1 - mc określa wamnków przekazywania sterowań,a a„, f eZby Mcm»™* kilkl; . "Sterowań,e " " R w a njest i a ' zawsze sic«**»™ ™ '¡«bv I p o p ® ^ » ™ P°d^ d a »Hek««wego. Technika diagramów strukiur bard“ 1 omw mvel. cykli p o w tó rz . przekazy*, \ VM^I!> ^ n m n nic wn w j •• J --■wamnkow •*---U'pr,‘ określa p r ^ ^ jest wyk„ rZys.ywana w pakietach CASE adaptacji do w y p ro w ad zi' »ne m e modelom zadań ,pr/e/, submod, zwrotnie modułom inicjującym, po wykonan,u ^ '" « iuuii Uły, powiazam« p0Staci strukturalnej użytkowanego kodu programowego. niższego poziomu w hierarchii diagramu. W momencie pełnej realizac systemu lub programu sterowanie wraca do rdzenia. Istnieje jeden kierunek związku sterowania między dwoma modułami w diagramie struktury, C/v,A Diagramy Jacksona , , . ł./v»ui B nie m c może nu jeżeli moduł A uruchamia działanie modułu -B *to moduł i n i r i n u a r f i m k c i o n n w a n i n modułu A. S ó w a ć funkcjonowania modułu _ modutan,i przesyłane st, grupy Graficznym narzędziem opisu struktur W ramach każdego p^d anych i identyfikacji. Dgramów an e są diagram y Jacksona, nazwane t T ™ ! dan5,Ch' jak 1 •>"danych oznaczane złączami w * . id c „ ty f ik a c y j n e w skazuje grupy Jacksona (57; 58j. Ta podwójna użyieczność H' SWe8° lwórc5' Msłużą przetwarzaniu mrtomia- . da„ych je s , wykorzystywane ich formalnej współzależności. S tru k tu r danych 'gramow »Przyja także danych, które maja byc p r z u _ nalomias, 7Jącze identyfikacji - * danego program u p o zw alaj, bowiem t w ^ t T * ‘ w>"iko^ przez moduł odbiorcy do „ b dutów |ub rekordów. Z łącza danych opisane również przy użyciu diagramów I d , ć1"7 Prosramów, indeksowania iub wyszukiw di jmach struktur w obydwu kierunkach. strukturami hierchicznym i o dowolnei lic h ą one z nalury i identyfikacji mogą d opisania sekw encji w diagramach Diagram Jacksona tworzy się poprzez z ,st, Poz'<>mów hierarchii, Powyższe oznaczenia śluzą 00 ^ P uż tkow ane są diagramy konstrukcji: * ? P ^ « « » o w a m e trzech zasadniczych • sekwencji, struktury. Poziom szczcgoowo , owadzenje notacji selekcji • selekcji (wyboru), i ueracji rys. 4.26). Sposób użytkowania tych • iteracji. dwu notacji przedstawia rys. 4.27. , , V
I
U
I
U
'
U
t
U
W
l
l
‘ “
"
‘
H
^
Selekcja _1 fi ^
a) ——
y '
J ~ » uviviwji siuacia się
• i*
Rys. 4 . 2 7 .
•1
Notacje .selekcji i iteracji w diagramach slruklury
Diagram struktur uporządkowany hierarchicznie pow inien charak teryzować się dwoma cechami [105, s. 147]: • spójnością modułów, tj. każdy moduł winien realizować jedną i jedną tunkcję, co umożliwia jego ponowną integrację z przyszły1111 programami i systemami, 140
i S
i a
?
j r
>
W
f
e
'
- - .co w.ęcej sKtadników na niższym poziomie hierarchii, z których tylko jeden jest wykonywany dla każdego wystąpienia składnika wyższego poziomu. Wreszcie iteracja oznacza, że każde wystąpienie składnika wyższego poziomu składa się z zero, jednego lub większej liczby składników niższego poziomu. Trzy podstawowe konstrukcje diagramów Jacksona można przedstawić zarówno graficznie, jak i przy użyciu pseudokodu (por. •ys. 4.28). Przykład struktury danych, opisanej za pomocą diagramów Jacksona, przedstawia rys. 4.29. Diagramy Jacksona okazują się szczególnie użyteczne w fazie technicznego projektowania danych i programów. Metodyczny zakres •agramów został przez Jacksona rozszerzony [58] w celu objęcia Pełnego zakresu fazy projektowania. Podejście to znane jest pod nazwą j s d (ang. Jackson Systems Design) i wykorzystuje trzy rodzaje technik:
Sekwencja
Aseq: B;
C; D; A end
Iteracja
itr
w
h
i
l
e
B>
A end A sel B; A a lt C; A a lt
A sel
A sel B; A alt C; A alt D; A end
Selekcja
A i«r u n til «condition»
B; A alt C; A alt D; A end
D; A end
Rys. 4.28. Symbole w diagramach Jacksona |58]
ZAMÓWIENIE
SYMBOL I ZAMÓWIENIA I
DATA ZAMÓWIENIA
NAZWA TOWARU
SYMBOL TOWARU
NAZWA DOSTAWCY
TOWAR
ADRES
I
DOSTAWCA
WARTOŚĆ DOSTAWY
DATA
1 I
dostawy
CENA
Rys. 4.29. Struktura danych opisana diagramem Jacksona
• diagramy sieci systemu, . zaprezentow ane wyżej diagramy Jacksona opisu struktur danych i programów, . pseudokod. Diagramy sieci systemu zbliżone są do diagramów przepływu danych. O p is u ją one jednak jedynie ogólne zależności pomiędzy strumieniami danych a program am i, występującymi w danym systemie. Na diagramie sieci (rys. 4.30) koła oznaczają strumienie danych, a prostokąty - programy. Dopuszczalne są jedynie powiązania strumień danych-program lub program-strumień danych. Diagram z rys. 4.30 pozwala na realizację całego projektu według metodyki JSD. Jej dalsza realizacja polega na opracowaniu dla każdego wyodrębnionego w diagramie sieci systemu programu, jego proceduralnej logiki na zasadzie dopasowania struktur odpowiednich strumieni danych wejściowych i wynikowych.
Strumień danych
Strumień danych
Program 1
Strumień danych
Strumień Program 2
danych
Strumień danych
Strumień danych
Rys. 4.30. Diagram sieci systemu
Przebieg procesu je st następujący: • opis każdego strum ienia danych wejściowych lub wynikowych w postaci diagramów Jacksona, • łączenie struktur danych określonego programu w jedną stukturę piogramu na zasadzie doboru korespondujących danych wejściowych i wyru o y obydwu strum ieni, . • opracowanie listy operacji niezbędnych do przetworzenia wejściowych w w ynikow e a następnie przyporządkowanie yc odpowiednim składnikom opracowanej w punkcie poprze nim
. „„„u . .
' Przekształcenie struktury programów w pseudokod, uwzględniają . struktury selekcji i iteracji. 143
¡, nmicj skuteczne pr/y haidziej złożonym ' struktur program ów o p f c * * powoduje w ykorzystań,e
ws,emach. B « p o ^ " 11 diagramami ' ' ąC„ora,orów kodu p a ^ o w C A S E . diagramów ja k o w e> c 1
410. Analiza przypadku Celem niniejszego przypadku j e , analiz, i projekt księgarń, ..Bes.se,«er [56J. * J E
K
Rwctsellcr" funkcjonuje od 1925 roku i specjalizuje * * n a zamówienie. W łaścicielem firm y jes, r o d « zannerza rozwinąć i pow iększyć sw oje przedsi,.
bimZ Ponieważ liczba zamówień rośme, firma przestaje byc * fekhwn i jak kiedyś Obecnie administrowanie przedsiębiorstw em me jest wspomagane komputerem. W związku z tym. iż dotychczasow y system zarządzania firma jest dobry, pan Książkiewicz zdecydow ał, aby został o. skomputeryzowany w całości bez jakichkolwiek m odyfikacji. Jedynym warunkiem usprawnienia administracji jest to, aby przy jej okazji nie ucierpieli klienci firmy.
Poproszono pana Eksperckiego, aby ten pomógł uspraw nić księgarnię ..Bestseller". Pan Ekspercki prześledził działanie przedsiębiorstw a. Z jego raportu wynika, że firma działa, jak opisano poniżej. Księgarnia „Bestseller" rozpoczyna swój dzień pracy od zebrania zamówień. Zamówienia te pochodzą od klientów firmy. Pan Klientowicz sprawdza wszystkie zamówienia klientów, a następnie dla każdego wystawia kartę zamówienia. Dane o kiążkach (ISBN, wydawca, cena sprzedaży, itp-l dostępne są w spisie książek. Spis książek jest bieżąco aktualizowany na ^podstawie iniormacji dostarczonych przez poszczególnych wydawców. Po rejestracji, karty zamówień wkładane są do pudełka z przychodzący111' zamówieniami. Na koniec dnia zamówienia te są zabierane przez pana Sprzedawczyńskiego. Dla każdej zamówionej książki pan S p r z e d a w c z y ń ^ ' wystawia kartę zakupu i umieszcza w segregatoże: „książki na zakupy’ • końcu tygodnia zawartość tego segregatora je st podstawą ^ j a w i e n i a zamówień dla poszczególnych w ydaw ców . Aby wystać Drzerhn1110^ ieme’ ^ ^przedawczyński potrzebuje inform acji o wydamy które odnri ™*!! W odpowiednim katalogu w jego dziale. Karty z a b f z datą zamów -ą Wystawionym zamówieniom do wydawców, t f ? niami gdzie ocTw Umieszczane Si* w pudełku z w ystaw ionym i za To0 ’ 8 ‘e °CZekują na re^ zację. Książki m ogą być dostarczone W * * 144
dnia. Kiedy książki nadchodzą, pan Sprzedawczyński, używając listu
który jest związany z przesyłką, przegląda zamówienia do wydawcy, aby spraw dzić ich zawartość. Jeśli przesyłka odpowiada z a m ó w i e n i o m i książka jest w dobrym stanie przekazuje wraz z odpowiednią k a r t ą zakupu panu Klientowiczowi. Pan Klientowicz na podstawie kart z a m ó w i e ń w ystaw ia fakturę dla klienta i razem z książką wysyła ją do klienta. Kopia łaktury jest zarejestrowana i umieszczona w pudełku z nie z a p ł a c o n y m i fakturami u pana Pieniążka. Kiedy poczta przynosi potwier dzenia zapłaty, faktura wyjmowana jest z pudełka. Jeśli faktura nie jest z a p ła c o n a w ustalonym terminie, do klienta wysyła się ponaglenie. W regularnych odstępach czasu pan Pieniążek otrzymuje zestawienie nie z a p ła c o n y c h faktur. Paktury te zostają opłacone po sprawdzeniu, że dostarczone książki są w dobrym stanie. Polecenie 1. Opisz za pom ocą diagram u kontekstowego aktualny system informacyjny księgarni „B estseller” . Polecenie 2. Przedstaw bardziej precyzyjnie za pomocą diagramu zerowego system informacyjny księgam i „Bestseller” . Polecenie 3. Wykonaj diagram związków encji księgami „Bestseller” . Polecenie 4. Opracuj słow nik/skorow idz księgami „Bestseller” . Polecenie 5. Zrealizuj pow yższe polecenia za pomocą wybranego pakietu CASE. p rzew o zo w eg o ,
Pytania i problemy 1. Na c z y m p o le g a z n a c z e n ie m eto d i technik w T S I ? 2. U zasad n ij d o b ó r o k r e ś lo n y c h m e to d i te c h n ik d o p o sz c z e g ó ln y c h faz cyklu życia system u. 3. R o d z a je m e t o d p o z w a l a ją c y c h m o d e lo w a ć sta ty k ę d z ie d z in y p rze d m io to w ej. 4. M o d e l z w i ą z k ó w e n c ji — d e f in ic je p o s z c z e g ó ln y c h k a teg o rii. 5. Podaj p r z y k ł a d y r ó ż n y c h r o d z a jó w en c ji.
,
.,
6- Dla w y b ra n e g o p rz y k ła d u o pracuj tablicę ilustrującą różnorodność rodzajów encji i a tr y b u tó w , w z o r u j ą c s ię n a ta b lic y 4 .2 i ry s u n k u 4.1. 2. T y p y z w i ą z k ó w w m o d e la c h z w ią z k ó w e n c ji - p o d aj p rz y k ła d y .
n p n i?
8- Jakie są p rz y c z y n y z n a c z e n ia i pop u larn o ści diagram ów przepływ u danych ( D P D ). 9 - P o d s ta w o w e k a te g o r ie p o ję c io w e i g ra fic z n e D PD . •0. O p ra c u j d ia g r a m k o n te k s to w y i z e ro w y fu n k c jo n o w a n ia
,„vL-nr-/vstuiac w y zi
p ra k ty c z n e z a s a d y z a w a r t e w ta b lic y 4 .6 . , .. ” ■ W n a w ią z a n iu d o p o w y ż s z e g o p r z y k ła d u o p ra c u j d .a g ra m z w ią z k ó w encji. *2. P o ró w n a j te c h n ik i D P D o r a z IS A C . . 13' O p ra c u j s ł o w n i k / s k o r o w i d z d a n y c h d o w o d u o s o b is te g o i p ra w a ja z d y .
145
’ 14. Opierając ' M ę n a fz & c z y w is ty m dokum encie (z a m ó w ie n ie , fa k tu ra , lis t p r /e w o cJokumenr SAD), p r z e p r o w a d ź n o r m a l i z a c j ę z a w a r t y c h w d o k u m e n c i e d a n y c h ^
Rozdział 5
Systemy obiektów*
trzeciej postaci norm alnej. /5. Techniki decyzyjne - ich znaczenie dla p ro je k to w a n ia sys te m ó w .
16. Diagram y struktury - podstaw ow e kategorie pojęciow e .
17.
R óżnice i podobieństwa m ię d z y diagram am i stru k tu ry a d ia g r a m a m i J a c k s o n a
IS. Ocen przydatność d ia g ra m ó w
na
p o d s ta w ie
występujących w trakcie sesji e g za m in a cyjn e j.
s tru k tu r y z a c ji
danych
i
Pr° ces<5\v
5.1. Model obiektowy Zmienność współczesnych systemów gospodarczych powoduje zwięk szenie wymagań w odniesieniu do elastyczności i adaptacyjnej sprawności, wspomagających je systemów informatycznych. Zwłaszcza w fazach analizy i projektowania strukturalnego, specyfikacja oraz opis danych i procesów przebiegają w zasadzie odrębnie i są wykonywane przez różne grupy zawodowe: • modelowanie danych przez specjalistów baz danych, • modelowanie procesów przez programistów. Wprawdzie w kolejnych fazach cyklu życia systemu istnieją punkty styczne i integrujące, jednak nie mają one charakteru scalającego. Przykładem mogą być punkty przeglądu dotychczasowych wyników prac oraz kategorie modelowania zarówno danych, jak i procesów w określonych metodach tworzenia systemów informatycznych, jak diagramy przepływu danych czy diagramy ISAC. Nie zmienia to jednak faktu, że wszelkie modyfikacje dokonywane na danych i procesach mają trudny do przewidzenia wzajemny wpływ i podważają spójność i jakość projektowanego lub użytkowanego systemu. Potencjalne skutki tych zmian należy więc każdorazowo ocenić, dokonując dalszych, niezbędnych modyfikacji zarówno w zakresie modeli danych, jak i procesów.
flWjifîV.vi#
Potrzeba rozwiązania tego problemu stała się w dziedzinach analizy i projektowania systemów informatycznych, programowania oraz baz danych inspiracją do nowego podejścia zwanego obiektowo zorientow anym lub obiektowym (ang. object-oriented). Ten rodzaj modelu danych wywodzi S*Ç z obiektowych języków programowania (SIMULA, SMALLTALK) oraz języków reprezentacji wiedzy. Podstawową cechą odróżniającą modelowanie „flhie.ktnwe-.Qd. podejścia .struMyiätogg-Q Jednoczesne m*vri«*i atyki i dyjianuki-(danych i pre
VI „ N o w i n i e o h ie k io w e upiera się na z a s a d z i e m o d u lary. Mihiu • modu|,m danych wraz z procedurami
pr/odmiotouej. U I* - ' uórc na .uch n,,cruw.
■
J . 0 UOS t-lcmi-n.u danych d o .y c y w lej ^ j Jm. „ piywu „a dane * procedury
sytuacji je d M U i ok
j(
^
^
m ja n o
o b |e k t u
, stan
fi' w innveil Niociuiti'-ii.
podstawę koncepcji n1° d |‘ V'v‘‘'’ k M in l„ p e a n y d , «
a
^1^ SC;^ 1 modelowania obiektowego ^
p o (lsta w Im y .
k lń ry
*
'"‘" " l i T o t n ' a n .y e .n e w*z> integralności (u n iU h ,o ść wartości atrybutu, r P a ln o ś ć j e n wartości zerowych, zakres w artość, atrybutu i inne) ;;Tz zw azkow setnantycznych m iędzy obiektam i. G łó w n y m pojęciami modelu podstawowego « , |9 I |. poza w ym ienionym juz obiektem , Jeg0: enkapsulacja lub hemtetyzacja tang. . m e od y. atrybut, polifortizni. identyfikator (klucz), przesyłanie kom unikatów, klasy obiektów. h ie ra rc h ie
klas. dziedziczenie oraz ogniwa.
System w podejściu obiektowym stanowi kolekcję ro /n y ch rodzajów,
wzajemnie powiązanych elementów zw anych obiektami, spełniających w nim określona rolę. Obiektem jest każdy byt - pojęcie lub rzecz - mający znaczenie w kontekście rozwiązywania problem u w danej dziedzinie przedmiotowej. Dwa obiekty są - tak jak w rzeczyw istości - dwoma unikalnymi, oddzielnymi obiektami (bytami), nawet jeśli posiadają dokładnie takie same cechy. np. dwie identyczne maszyny. O biekty są odróżniane poprzez swoje istnienie, a nie cechy opisowe. Każdy obiekt stanowi oddzielny moduł czy kapsułę i zawiera dane i procesy, um ożliw iające odgrywanie określonej roli w rzeczywistym systemie. Rozw iązanie to nosi miano enkapsulacji bądź hermetyzacji i oznacza wzajemną niezależność danych. ^przechowywanych w różnych modułach. Koncepcja ta zakłada, iż zarówno dane (atrybuty i w-artości) dotyczące obiektu, jak i procesy realizowane na nich. powinny być modelowane równocześnie. Obiekt różni się więc od. encji ujęciem dynamicznych aspektów systemów. Interpretacja obiektu jest bardzo uniwersalna i obejmuje takie reprezentacje, jak encja (z procesam i), pojęcie. zdarzenie, ciąg liczb, łańcuch znaków', okno, dysk, schem at bazy danych czy słow nik/skorowidz danych. Przykładami obiektów z zakresu funkcjonowania organizacji gospodarczej są: KLIENT, PRACOW NIK, JA N KOWALSKI. BILANS. KONTO, MAGAZYN-ODZIEŻOWY. W szystko, co wiadomo o obiekcie, zawarte jest w jego atrybutach (zw anych rów nież zmiennvIfliL a wszystkie interakcje wyrażone są w "m etodach. D zięki temu można modyfikować zakres atrybutów i m etod"danego obiektu bez skutków dla innych obiektów w systemie. Każ.dy obiekt posiada jeden lub więcej atrybutów oraz jedną * .1 teto . Atrybut to określony, pojedynczy składnik danych w obiekcja 148
Wartości atrybutów obiektu zmieniają się w czasie i stanowią o stanie obiektu Atrybut może miec pojedynczą wartość lub zestaw wartości ze swoiei dziedziny. W budowane w obiekt procesy, które operują na wartościach atrybutów noszą miano metod. Tak więc metodami obiektu ZAMÓWIENIE mogą hyć np. Podaj-adres, Óblicz-sumę. Wydrukuj czy Anuluj. Tylko metody zapewniają w spółdziałanie obiektów' w modelu obiektowym. Stanowią one rod/aj warstwy ochronnej, ograniczenia otaczającego dane obiektu. Rozróżnić należy dwa rodzaje metod: zewnętrzne (ang. public) oraz wewnętrzne (ang. private). M etody zew nętrzne umożliwiają interakcję z innymi obiektami modelu poprzez odpowiedzi na komunikaty innych obiektów oraz wysyłanie komunikatów własnych. Dostęp do danych obiektu jest zatem możliwy jedynie poprzez inicjowanie jego metod zewnętrznych. Metody wewnętrzne SŁł z kolei inicjowane przez metody zewnętrzne w celu uruchomienia odpowiednich procedur przetwarzających i aktualizujących wartości atrybutów, opisujących aktualny stan danego obiektu. Rysunek 5.1 ilustruje zależności pom iędzy atrybutami i metodami obiektu ZAMÓWIENIE. Obiekt ZAMÓWIENIE
Metoda
Atrybuty
J
Rys. 5.1. Obiekt ZAMÓWIENIE
Bardziej rozbudow aną propozycją terminologiczną 19 1’ ' A t n ™ reślenie procesów obiektu jako operacji, natomiast metoda jest ybranym w drożeniem operacji dla klasy ob.ektow ^M e.odann p ^ s u ydrukuj będą w tym przypadku: Drukuj-zbtory-ASCII, Drukuj /.n, -b in arn e czy D r u k u j-w -try b ie -g ra fic z n y m .
r m n r f;7 m
O znacza
Istotną cechą system ów obiektowych jest u. po i różnych >, że ta sam a nazw a może odnosić się do rożnych metod w rożnych i--
"
149
d hL
i , metody o różnych nazwach mogą realizować identyczne S ę k a c h . pu< ■ jsaniu każdcmu obiektowi unikalne -W :& SV oJ £ $ £ £ b i e ż n e g o od wartości atrybutów obiektu. .de„,yfikal; i. Identyfikator ' obiektowo /orientow any język programowania ^
^
me,0dy'. ‘to m u m k u ty powodują
”
" *
- r ,r X ™
• “ ” T S nadawcą, a adres
—
danegorodzaju obiektu
tj
CASE. — pozwala metod _ $obą poprzez przesyłane
"alara'm u nal systemie kontaktują ^ danic)ednego obiektu w stosunku Obiekty w .. s)< stanowiące zą Qbiekt-odbiorca odpowiada k o m u n i k a t y (^ zreaUz0Vvać jedną z Jc&° ^ kom unikat obiektu-nadawcy • do
S
strukturze danych
1 bez ingerencji
» » V
~
s
» •* trKCh części [99. s. w j
r •
" przez
« i ™
«• • • ¿ * 3 t L S s “ * *
kategoria klasy przedstawiana części:
gfaficZnie m°dele o b iitó w e JCSt J3k0 Prostokąt składający s ^ g S
• nazwy klasy obiektu, • zestawu atrybutów klasy obiektu • zestawu m etod klasy obiektu Przykłady graficznego o n i s T T E nu< , , w diagram ach przedstaw iono n ^ y s £
oraz SKLEP
PRACOWNIK
"
"
"
biek,U' i ° ^ winien wykonać.
skazanej metodv. metody. : wskazanei d Przykład działania komunikatu jest przedstaw' iony na rys. 5.2.
.
wy
Komunikat obiektu
Nazwisko Data-urodzenia Staż Wykształcenie Adres Grupa-zaszeregowania
SKLEP
rlO-U-S!
Nazwa Adres Branża Powierzchnia Liczba-zatrudnionych
Zamówienie Przyjęcie Zmiana-adresu Ubezpieczenie Zmiana-grupy-zaszeregowania Zwolnienie Przejście-na-em eryturę
Uruchomienie Dostawa v Zatrudnienie-pracownika Przeprowadzenie-spisu-kontrolnegi Przeprowadzenie-przeceny
Rys. 5.3* Oznaczenia klas obiektów w diagram ach
Z kategorią klasy obiektu wiąte
Zamówienie L____
J
V
V
Odbiorca
Metoda
Nazwa + Adres v ------Parametry Rys. 5.2. Komunikat obiektu
wiele o b ie k ió w tó g i^ w skazuje, że występuje w niej obiekty te gmoow-mp zaJu-Poprzez przeprow adzenie k la sy fW grupowane są w klasy obiektów . K lasa obiektu jest « * 150 ***■
ono'przyporządków anie atrybutów i m_ hierarchicznej zależności między mmi. uporządkowana jest z uwzględnieniem
hierarchiczna klas obiektow . specjaUzacji ich funkcji nadrzędna klasa obiektów
w dziedzinie przedmiotowej. og° ^ podrzędna-subklasą.(podklasćL). w hierarchii nazywa się superklasą, a U P kolei wystąpiemem Subklasa jest oczywiście wystąpienmm klasy, superklasy. Zależności te przedstawia rys. • metody superklasy obiektu Podklasa dziedziczy zarówno w danej hierarchii. Oznacza to, izattybu^,^ e^ czeniu, obiekty - nawet
k la s a
P odklasa 1
Podklasa 3
P o d k la s a 2
P o d k lasa 2.1
P o d k la s a 2.2 I
P o d k l a s a 3.1
I
Podklasa 3.2
I
Rys. * 5 .4 . H ie ra rc h ia k las o b ie k tó w
o różniącej się strukturze - mogą mieć te sam e m etody dotyczące wspólnej części atrybutów. A zatem każda klasa (subklasa) obiektów w hierarchii dziedziczy wszystkie atrybuty i m etody superklasy i może mieć dodatkowe atrybuty i metody. Obiekt jest k o m b in a c ją wspólnych cech (atrybutów) zawartych w klasie i unikalnych w wystąpieniu. Atrybuty odnoszące się do wszystkich obiektów danej klasy są atrybu tami klasy, natomiast odnoszące się do w ystąpienia obiektu - atrybu tami wystąpienia. Podobna term inologia o b o w iązu je w przypadku metod. Zasady dziedziczenia atrybutów w odniesieniu do hierarchii obiektów: PRACOWNIK, PRACOW NIK-NAUKOW Y, A D IU N K T przed stawia rys. 5.5. PRACOWNIK-NAUKOWY dziedziczy zatem w szystkie atrybuty obiektu PRACOWNIK, natomiast obiekt A D IU N K T atrybuty obydwu superklas. Podobnie przedstawia się sprawa dziedziczenia m etod, zachowania obiektu. Metody, operacje wykonywane na obiekcie PR A C O W N IK , to np.: zatrudnienie, zwolnienie, zapłata i przeniesienie. W przypadku PRACOWNIKA-NAUKOWEGO można dodać: promocję, odbycie stażu naukowego itd. Oczywiście metody dotyczące obiektu PR A C O W N IK są dziedziczone przez PRACOWNIKA-NAUKOWEGO i A D IU N K TA . Przedstawiony wyżej model dziedziczenia nazyw any je s t pojedynczym. bowiem każda-klasa .obiektów '-,jna^|m yw yżej']edną superklasę. Mod obiektowy pozwala również na w ielokrotne dziedziczenie, co ozna.cz&.# dany obiekt dziedziczy atrybuty i metody z dow olnej liczby superklas. w dziedziczeniu wielokrotnym hierarchia stanow i w ięc sieć wzajemn* powiązanych struktur dziedziczenia. K oncepcję w ielokrotnych strukW dziedziczenia przedstawia rys. 5.6. • #
PRACOWNIK Nr-identyfikacyjny Nazwisko Imię Data-urodzenia ________ ______ PRACOWNIK-NAUKOWY Rok-ukończenia-studiów Specjalność-naukowa Katedra
1
ADIUNKT Data-obrony Temat-pracy Promotor Rys. 5.5. Hierarchia klas obiektów - dziedziczenia atrybutów
w sieci następuje tw orzen ie diagramów klas obiektów. W naw iązaniu d
podanego wyżej przykładu ogniwa, na rys. 5.7 przedstaw iono asociar-° KUPUJE łączącą klasy obiektów KLIENT i PA K IET-O PRO GRAM O V/ą NJA. Oznaczenia graficzne klas obiektów i ogniw w diagram ach ki obiektów przedstawione są na rys. 5.8. ^
PAKi Et - o p r o g r a m o w a n ią
KLIENT
Nazwa Producent Wersja Data-produkcji Pojemność-pamięci Platforma
Nazwa Adres Branża Telefon
Fax
Kupuje
Zamówienie Zmiana-adresu Zmiana-zamówienia Przesłanie-faktury Opłata
Jest kupowany
Przyjęcie-oferty Zamówienie Dostarczenie Sprzedaż Zmiana-wersji Przyjęcie-opłaty
Rys. 5.7. Asocjacja 1:N w modelu obiektowym
Klasa 1
Nazwa ogniwa
roia-1
rola-2
Klasa
Tylko jedna Wiele (zero lub więcej)
Klasa Rys. 5.8. Oznaczenia graficzne w diagramach klas
Opcyjna (zero lub jeden) o biektów w notacji O M T [91]
dwukie™ '*°«'a. W pow yższej asocjacji
binarnej je&'ona
S
p a S e t -o p r o g r a m o w a n ia
0 W A N IA te t-k u p o w a n y -p r z e z KLIENTA n o » im ,v n , g r- 154
s g
f f »
»
asocjacji, p r z y p o r o w a n e jff
ktow n azy w a n e s ą rolam i a so cja cji. A socjacja f V— W
również opisywana za pomocą atrybutów. A trybutam i asocjacji KLIFNT Kupuje PAKIET-OPROGRAM OW ANIA są: RUfcNT Data-zakupu, Data-dostawy, Forma-płatności, Forma-dostawy. Podobnie jak związki w modelu związków encji, asocjacje w modelu obiektowym charakteryzują się takimi cechami, jak liczebność'l.opcyjność. Znajduje to wyraz w rozbudowanych diagramach modeli obiektowych i to zarówno w m odelach klas obiektów, jak i wystąpień obiektów. W obiek towych językach program ow ania odpowiednikami asocjacji są odsyłacze. Przedstaw ione wyżej kategorie stanowią rdzeń podstawowego modelu obiektowego. Liczne aktualnie publikacje proponują różne modyfikacje i odmiany zarysow anego modelu.
5.2. Projektowanie obiektowe B adania i zastosow ania podejścia obiektowego koncentrowały się początkowo w okół obiektow ych języków programowania oraz obiektowych baz danych. W m iarę wzrostu zainteresowania tym podejściem w odniesieniu do bardziej złożonych aplikacji, pojaw iła się potrzeba opracowania m etodycznych podstaw analizy i projektowania systemów obiektowych. Przedstawione dotąd propozycje cechują się różnorodnością. Łączą je jednak dw ie podstaw ow e cechy wspólne, odróżniające je od strukturalnych systemu m etodyk tw orzenia systemów informatycznych: • oparcie procesu projektow ania na jednej kategorii pojęciowej, tj. obiekcie. • inicjow anie procesu od identyfikacji obiektów, a nie od dekompozycji funkcji. W praw dzie, podobnie ja k w podejściu strukturalnym, utrzymane zostają tradycyjne fazy w procesie tworzenia systemu obiektowego, to jednak zanikają bariery m iędzy nimi, dzięki wprowadzeniu wspólnej we wszystkich fazach kategorii pojęciow ej — obiektu - swoistego wspólnego języka. Obiekty św iata rzeczyw istego z fazy analizy transformowane są na obiektv systemowe w fazie projektow ania, a te z kolei na obiekty języków programowania i baz danych w fazie wdrażania, obejmującej programowanie. Rozwiązanie to kontrastuje z paradygmatem tradycyjnego cyklu życia systemu, adaptującym różnorodne w swej naturze metody i techn i o realizacji kolejnych faz, a nawet szczegółowych zadań cyklu. Stosowany jest tu m .in. opis w erbalny, tablice, formularze, cała gama diagramów, Pseudokod, kod języ k ó w programowania. Poważnym problemem staje się 155
kategoriam i
p o ję c io w y m i p0
trzy poziom y (warstwy)
ZASTOSOWANIA
MODELE
KLASY OBIEKTÓW Rys. 5.9. Poziomy modelu obiektowego [99]
156
Zasadnicza idea prototypowania polega na wstępnym ogólnym opisie dziedziny przedm iotow ej a następnie uszczegółowianiu tego opisu w kolej nych iteracjach, aż do pełnego zaprojektowania, a następnie wdrożenia systemu. Zgodnie z powyższym i zasadami oraz opisanym trójpoziomowym wzorcem m odelow ania, sekwencja tw orzenia systemu obiektowego jest następująca: • zaprojektow anie modelu działalności gospodarczej, który określa obiekty dziedziny przedm iotow ej oraz asocjacje pomiędzy nimi, • zdefiniow anie klas obiektów oraz ich ról (ang. responsibilities) w modelu, • projektow anie i w drażanie zastosowań. T w orzenie modelu należy rozpocząć od ogólnego opisu werbalnego podstawowego cyklu funkcjonow ania danej organizacji. Opis ten służy nie do dalszej dekom pozycji procesów, jak w podejściu strukturalnym, lecz do identyfikacji obiektów . Kandydatami na obiekty są przede wszystkim występujące w opisie rzeczow niki. Podstawowy opis cyklu funkcjonowania organizacji rozbudow ywany jest w kolejnych, uszczegółowiających zdaniach charakteryzujących dziedzinę przedmiotową. Następuje identyfikacja zestawu adekwatnych dla danej dziedziny przedmiotowej obiektów i związków między nim i. W trakcie kw alifikow ania obiektów wstępnie analizowana jest ich zaw artość inform acyjna (atrybuty), oraz wykonywane procedury (metody). W ten sposób pow staje najpierw biblioteka obiektów, a następnie szkic m odelu obiektow ego - klas obiektów i wiążących je asocjacji. Celem kolejnego etapu je st ścisłe zdefiniowanie zidentyfikowanych uprzednio klas obiektów . O znacza to jednoznaczne określenie pełnego zestawu ich a try b u tó w i m etod. Czynność ta ma bezpośredni wpływ na weryfikację opracow anej uprzednio wersji modelu obiektowego. Specyfikacja atrybutów i m etod m oże przebiegać według różnych zasad, podejść, ukierunkowanych na: • dane, • procesy, • role. Koncepcje ich specyfikacji przedstaw ia rys. 5.10. Pierw sze podejście polega na określeniu danych (atrybutów), które dana klasa obiektów winna zawierać a następnie sposobów ich przetwarzania, czyli metod. M ożliw e je s t inne podejście, tj. identyfikacja metod realizo wanych przez klasę obiektów , a następnie projektowanie struktur an>° • umożliwiających w drażanie tych metod. Obydwa podejścia nawiązują do strukturalnych technik tw orzenia systemów, jak diagiamy przepływu any ' diagramy dekom pozycji funkcjonalnej. Trzecia faza projektow ania modelu obiektowego metodyką prototyp, wą i0 Projektowanie i w drażanie zastosowań. Najbardziej znaczące zastosowania 157
METODY: Ukierunkowanie na procedury
'U \\
Ukierunkowanie na role
Ukierunkowanie na dane jkiowanie klas obiektów |9 9 |
Rvs. 5.10. Identyfikacja i proje
W
sa wdrażane w postaci m odelu lub m o d e li o b i e k t o w y c h dziedziny przedmiotowej. Zastosowania tworzone na b ie żąco są s to s u n k o w o proste, dotyczą sp ecy ficzn y ch potrzeb. Przykłady stanow ią z e s ta w ,e n ,a n a życzenie, zapytania, rejestrowanie now ych typów
tr a n s a k c ji,
zm ian y
procedur
użytkowania. Znacznie bardziej rozbudowana je st m etodyka O M T (ang. Object-Oriented Methodology), której w głównej m ierze pośw ięcona jest praca [99]. Dwa zagadnienia mają decydujące znaczenie dla użytkowania metodyki OMT: przyjęte modele dziedziny przedm iotow ej oraz struktura projektowania systemu. Podstawę modelowania stanowią trzy ro d zaje m odeli: obiektowy, dynamiczny i funkcjonalny. Wiodącą rolę odgryw a m o d el obiektowy, opisany za pomocą diagramów obiektów, scharakteryzow anych uprzednio. Model dynamiczny, przy użyciu diagramów przekształceń stanów , opisuje dynamiczne aspekty systemu, zmieniające się w czasie. M odelow ane są trzy kategorie pojęciowe: stany obiektów, przekształcenia obiektów oraz zdarzenia. W diagramach przekształceń stanów węzłami są stany obiektów , łukanii przekształcenia stanów, inicjowane przez zdarzenia. M odel dynamiczny umożliwia określenie i wdrożenie aspektów sterow ania system em . Wreszcie model funkcjonalny opisuje transformacje wartości danych w systemie, czyli procedury obliczeniowe. Narzędziem m odelow ania funkcjonalnego $ scharakteryzowane uprzednio diagramy przepływu danych. T e trzy modele stanowią spójne, wzajemnie powiązane składniki pełnego opisu systemu. Metodyka OMT bazuje również na kaskadow ym cyklu życia sy ste m u , uwzględniejącym iteracje pomiędzy fazami. W yróżnia się cztery następuje etapy tworzenia systemu obiektowego• analiza, • projekt systemu. 158
• projekt obiektowy, • wdrożenie. W fazie analizy system u następuje identyfikacja i analiza problemu W celu /rozum ienia i modelowania dziedziny przedmiotowej oraz określenia co tworzony system winien wykonywać. Faza realizowana jest przy współudziale użytkowników systemu w zrozumiałych dla nich kategoriach pojęciowych, specyficznych dla danego zastosowania. Rezultatem analizy jest precyzyjny, spójny, zrozumiały i poprawny model, składający się z trzech części: • obiektów i wzajem nych związków (model obiektowy), • dynam icznego przepływu sterowania (model dynamiczny), • funkcjonalnych transformacji danych (model funkcjonalny). Fazę analizy rozpoczyna postawienie problemu, określenie potrzeb informatycznych. Jest to podstawa opracowania kolejno modeli: obiektowego, dynamicznego i funkcjonalnego. Stosownie do opisanych wyżej cech modelu obiektow ego tworzony jest opis dziedziny przedmiotowej, co pozwala na specyfikację obiektów za pomocą technik omówionych w m etodyce prototypow ania. Kolejno identyfikowane są: obiekty i ich klasy, asocjacje, m etody, role, atrybuty, dziedziczenie, ścieżki dostępu dla zapytań. M odel dynam iczny opisuje zachowanie systemu i jego obiektów. Analiza dynam iki system u polega na identyfikacji zdarzeń i reakcji na nie. Zdarzenia te inicjują łańcuchy kolejnych stanów i przekształceń obiektów, opisane następnie w postaci diagramów przekształceń stanów. Tworzy się je dla każdego obiektu modelu, w celu wskazania przesyłanych do niego oraz generow anych zdarzeń. Do wskazanych stanów i przekształceń przypisane są operacje, opisujące czynności wykonywane w odpowiedzi na zdarzenia. A lgorytm y przekształceń definiowane są w fazie wdrożenia. Najistotniejsze je s t określenie scenariuszy, czyli sekwencji zdarzeń, występujących w trakcie konkretnego pojedynczego przebiegu użytkowego systemu. Scenariusze te, na zasadzie analizy typowych dialogów pomiędzy użytkownikiem i system em , przedstawiają podstawowe interakcje, wejścia i wyjścia system u. M odel funkcjonalny przedstawia, w jaki sposób wartości atrybutów są obliczane poprzez funkcjonalne zależności opisane diagiamami przepływu danych. Procesy DPD odpowiadają transformacjom diagramów przekształceń stanów, natom iast przepływ y danych zestawom atrybutów w diagramie obiektów. Na podstaw ie m odelu obiektowego w fazie projektow ania systemu następuje dekom pozycja systemu na podsystemy. Podejmowane są » f i decyzje dotyczące architektury tworzonego systemu oraz wspołbiezn
159
hM M -v -u o n . nie les, ani obieMeni. ani fiin k q i,. leQ adjn- 1 ■ j kl:»'. Obiektów, asocjacji. metod i 0gra. pakietem w/ajoinme ' " " ‘'■ ¿ „ „ ¡„ „ a n e -p rrtg i / " 'm m i Podsystemami. „kvc.i. m a jf .'- 1* ‘ ‘ ¡jem vlik.nva.n przez uslugi. M ore zapewnia. Podsyslem jeM • wykonujących jakieś wspólne zadanie ...... * " " " C 1 * p r r c 'i i a r » a sprzęgi ok.e. projektowe a . funkcjonowania
w ^ ii w w h . generowanie g ra fik i ud . Z kolei' ,.m_,.ik,J międzv p o d sy slc m a n ,i. in n e d e c y z je i prace •
u Kj |a / j c d o ty czą o p ty m a liz a c ji param étré» ■ strategii r o z w i ą z y w a n i a problem« ja s o M w p:,nliçci , sp rzętu .
k° " O nraœ w anv w fazie analizy model o b ie k to w y j e s t r o z w ija n y w trakcie „rolektow ania obiektowego, ukierunkow an eg o na z a p ro je k to w a n ie sintknt, L v c h oraz algorytmów dla w yspecyfikow anych u p r z e d n io k las obiektów. Określane są teraz ścisłe definicje klas asocjacji i o g n iw o r a z algorytmy metod Specyfikacje te są następnie w y k o rz y sty w a n e w ta z ie wdrożenia. Następuje przejście do pojęć u k ierun ko w any ch k o m p u te r o w o , a także integracja modeli dynamicznego i fun kcjon aln ego p o d w z g lę d e m kategorii m o d e lu obiektowego. Operacje modelu d y n a m ic z n e g o o r a z p ro c e s y modelu funkcjonalnego przekształcane są na m etody p rz y p is a n e k la s o m obiektów modelu obiektowego. W ostatniej fazie następuje w drożenie dotychczasow ych wyników analizy i projektowania w określonym o b ie k to w y m j ę z y k u programowania lub bazie danych. Transformacja o p raco w an y ch p r o je k tó w n ie j e s t złożona, bowiem kategorie modelowania wszystkich etapach cyklu.
o b ie k to w e g o
m a ją
z a sto so w a n ie we
Trzecia metoda tworzenia systemów obiektow ych, zw ana FUSION [28], ukierunkowana jest na role pełnione przez obiekt w modelu. Obiekt traktowany jest tu jako niezależna, zintegrow ana, samozarządzająca jednostka. Jako taki wykonuje on szereg przyporządkow anych mu zadań (ról). A zatem podstawowym zadaniem w projektow aniu modelu obiektowego jest określenie ról, jakie każdy obiekt pełni w systemie. Obowiązuje tu zasada enkapsulacji. tj. „ukryw ania" w ew nętrznej struktur) każdego obiektu. Dopiero po sformułowaniu ról obiektów można roz patrywać ich wewnętrzną strukturę, tzn. atrybuty i m etody. Model o îektow) funkcjonuje na zasadzie w zajem nego w ypełniania zapro1 owanych ról przez każdą z klas obiektów . N ajczęściej role le , ac^aJ3 inicjowanie przesyłania oraz p rzetw arzan ie i przesyłać n1 h
'/ a S 1 cC m , " obiekcie- Na przykład w ykonanie roli ZŁOŻEodpow iedni^ « P raZ ° biekt O M Ó W IE N IE pow oduje przęsła»« pr/yiecie k kornumkat6w do obiektów T O W A R i DOSTAWCA otnunikat0w zwrotnych, przetw arzanie w g określonej meto* 160
pr/eka/anych informacji w celu „nr,,,,.,
■ •
ISSZE!
Od Strony użytkowania systemu " ’ t * “ "M Ó W IE N IA . .. . i w ;i „nadanie a , , , ; , komunikatu i ...................i .n .i c j uJ VeJa dro*'Przedstawia o- wybór ISliJw 1a sie S1
l ^
^
^
t t i ^ M 0W ,EN ,Ł WIEN1E o utworzeniu
0 wysianie przez nowo utworzony obiekt formatki do w ypełnienia wartościami
na, . • nazwami atrybutów
» wysłanie przez obiekt komunikatu do simerklasv w r*i. do listy podklas. " ’prowadzenia M ożliwość bezpośredniej interakcji pomiędzy obiektami bez in.erencii programu kontrolnego stanowi o naturze podejścia o b iek .o w eg o fam o nom,cznctsc, obtektow. Na przykład obiekt ZAMÓWIENIE ZAKUPU zawtora dane .. wielostopniowej transakcji: propozycja zamówienia jego akceptacja, wydrukowam e. wysianie, potwierdzenie dostawy, o p ia « fe Aby zachow ać zasadę autonomiczności, obiekt musi przechowywać pe e dane o kolejnych stanach transakcj, oraz posiadać metody realizach przekształceń stanów Po ustaleniu ról naslępuje specyfikacja metod 1 atrybutów, które um ożliwiają wypełnienie ról przez obiekt. A ktualnie dąży się do zestandaryzowania różnych podejście w roz w i a n i e jednolite w projekcie RATIONAL, który jest wspólnym przedsię wzięciem G. Boocha f i l ] , I. Jacobssona [59] i J. Rumbaugh [91] Proponowanym standardem jest język obiektowy UML (ang Unified Modeling Language).
Pytania i problemy 1. S k ła d n ik i p o d s t a w o w e g o m o d e lu o b ie k to w e g o . 2. Isto ta i i n t e r p r e t a c j a p o d s t a w o w y c h p o ję ć m o d e lu o b ie k to w e g o . 3. A tr y b u ty i m e t o d y o b ie k tu S T U D E N T . 4. O p ra c u j h i e r a r c h i ę k la s o b ie k t ó w , ilu s tru ją c d z ie d z ic z e n ie a try b u tó w i m etod. 5. P rz y k ła d y k o m u n ik a tó w ' o b ie k tu . 6. M o d e l o w a n i e s y s t e m u o b i e k t o w e g o o p ie r a ją c e g o się n a p o d e jśc iu proto ty po w ym . 7. M e to d y k a O M T - j e j e ta p y , m e to d y i te c h n ik i.
R o z d z ia ł 6
Metodyki społeczne
6.1. Założenia m etodyk s p o łe c z n y c h Z podejściem zarówno strukturalnym, jak i obiektow ym wiążą się pojęcia inżynierii systemów oraz inżynierii oprogram ow ania. Ich cechą jest spojrzenie „inżynierskie", polegające na wyborze odpow iednich środków dla osiągnięcia celu. który jest pojmowany jak o w ykonalne zadanie, zdefiniowane na początku podejmowanego działania. Z ałożenie stiukturalne oznacza, że istnieje dobrze zdefiniowana sy tu acja p ro b le m o w a (dotycząca określonej dziedziny przedmiotowej), tzn. jest zgoda co do istoty problemu, pozostaje jedynie zagadnienie organizacyjno-techniczne: ja k sobie z tym poradzić? Problemy w świeeie rzeczywistym są rozw iązyw ane poprzez poszukiwanie efektywnych środków dla osiągnięcia w yznaczonych celów. Cały zakres działań jest kierowany na osiągnięcie założonego celu. Działania te uporządkowane są w sekwencję etapów, rozpoczynającą się od określenia celów i potrzeb, poprzez opracowanie wariantów projektow anego obiektu i systemu, do wyboru i realizacji określonej opcji, spełniającej założony cel. przy przyjętych kryteriach racjonalności. Każda z faz je st wspomagana przez zestaw metod, technik i narzędzi. Rezultatem realizacji tej strategii jest specyfikacja, mająca najczęściej charakter graficzny (diagram ). Taki opis systemu umożliwia jego wdrożenie i użytkow anie. W iele ustrukturyzowanych (uporządkowanych) zagadnień ekonom icznych poddaje się tej procedurze. Jak jednak wskazano w' podrozdz. 1.3, w iele tak przygoto wanych specyfikacji systemowych zawiera błędy, pow odujące dodatkowe poważne nakłady w kolejnych fazach cyklu życia system u - na korektę, modyfikację i adaptację systemu. Koszty te m ogą być zwielokrotnione w sytuacjach niepewnych, nieustrukturyzowanych, źle zdefiniowanych, /.wiązanych z ryzykiem (niekiedy poważnym). Podejścia strukturalne wari! it°We znaczn‘e °§rariiczają (lub wręcz ignorują) kw estie różnorodności postrzegania i interpretacji danego zagadnienia, jego r£)Z' 162
wiązywania nie tylko w zgodzie z zasadami loeiki ale i 7 , • mniej racjonalnych czynników psychologicznych i' Podejścia te rac sprawdzają si, zatem w sytuacjach nlcuporządklanych kontrowersyjnych, zmtennych. nieostrych, w których cele są ro “ yte czy ł W a trudne do określeń,a. W sytuacjach tych same cele są problematyczne l0,e z staw ,a stę względem ntch pytania: jakie są cele’ Co chcemJ osiągnąć? W e w spółczesnej gospodarce klasa tych właśnie sytuacji problemowych nabiera znaczenia, a organizacje gospodarcze i menedżerowie muszą urmec je rozwiązywać. W tych przypadkach swoje zalety wykazuia m etodyki społeczne. W meritum metodyk społecznych wpisują sie jako najbardziej znaczące, podejście ETHICS fang. Effective Technical and Humań Implémentation o f Computer-Based Systems) E. Mumford [79] oraz podejście SSM (ang. Soft Systems Methodology) P. Checklanda [17] W przypadku metodyki ETHICS tworzenie systemu jest tu postrzegane nie jako zagadnienie techniczne, lecz organizacyjne, które dotyczy procesu zmiany. M etodykę tę w yróżniają trzy aspekty: - — • psychologiczny, • socjologiczny, • znaczenia zm iany. Aspekt psychologiczny akcentuje zagadnienie satysfakcji pracownika (użytkownika, tw órcy system u) z pracy. Chodzi o dopasowanie oczekiwań i aspiracji pracow nika do wykonywanej przez niego pracy (jej natury) oraz do oczekiw anego wkładu we właściwe wykonywanie pracy. Stąd cała teoria dotycząca pomiaru satysfakcji z pracy, na podstawie różnych kryteriów. Wymiar socjologiczny oznacza udział (stąd czasami mówi się o podejściu partycypacyjnym) w szystkich osób i komórek organizacyjnych, związanych z podejm owaniem decyzji, dotyczących projektowania, wdrożenia i użyt kowania system u. Poniew aż proces TSI jest procesem zmiany, zatem jego realizacja m oże pociągać za sobą konflikty interesów pomiędzy wszystkimi uczestnikami tego procesu. Pomyślne wdrożenie zależy więc od procesu negocjowania w zespole projektowym. Wszystkie strony zaangażowane w zmiany w inny być reprezentowane, a firma winna stworzyć mechanizm komunikowania się, negocjow ania i porozumiewania się na za zasadzie współuczestnictwa w szystkich stron i grup interesów. Mechanizm ten oznacza pow ołanie oprócz zespołu projektowego również komitetu sterującego (ang. steering committee), złożonego z przedstawicieli zarzą u •przyszłych użytkow ników , opracowującego zalecenia i ocen> a zc.pt i Projektowego. Idea komitetu sterującego została zaadaptowana w m e to ^ k aa strukturalnych i obiektowych, szxzegolnie w odniesieniu o iazy p ^ Najbardziej reprezentatywna w tej klasie podejść do tworzenia informatycznych je st opracow ana przez P. Checklan a me t . i 63
* ' • , íír/nvch pracach, m.in. 16: 17: *8: |9 : 20: 21; 22). o ^ w ninjcj SZym rozdziale przedstawiono żenieni społecznej sz 0¿ ^ proces modelowania przy wykorzystaniu podstawowe * ; charakterystyką adekwatnych m etod i technik, melodyki s p o U / MI ‘ wywiera wpływ na inne podejścia, Zr
zemr l - , l n e
Wvra/en» lei lendencji jest włączenie tazy planowania — uklundnych metodykach T S I ,sesji, M ctaPłaa,
S Istotnych Czynników Powodzeń,a. m tidelspojnosc, B ro ek sh , czy restrukturyzacja procesów gospodarczych - pat,z rozdz. ->. Mei
i dopuszi svstenm ‘lJczenie"się złożonych sytuacji problem ow ych prowadzi do podejmowania działania - celowego, sensownego dla użytkowników systemu, zmieniającego sytuację problemową. Uczenie się system u następuje poprzez proces zapytań, który prowadzi do wybrania jedego spośród wariantów działań. Wybrane działanie zmienia sytuację problem ow ą w pożądanym kierunku. U podstaw metodyki SSM leży pięć podstaw ow ych założeń, które dotyczą: rozumienia metodyki społecznej jako procesu zarządzania, różnorodności spojrzeń, ocen i działań, użyteczności pojęć systemowych, koncepcji systemu działań ludzkich, metodyki jako systemu zapytań. Zarządzanie w podejściu SSM jest rozum iane szeroko - jako proces zapewniania i utrzymania zorganizowanego działania. O znacza to, iż każdy menedżer w dowolnej dziedzinie działalności reaguje i próbuje oddziaływać na proces ciągłych zmian (ang. flux), będących w interakcji zdarzeń i pomysłów (por. rys. 6.1). Zarządzanie polega na reagowaniu na ten splot ciągłych zmian, tj. na jego postrzeganiu i ocenie, decydowaniu o działaniu oraz podejmowaniu działania. Ten ciągły proces p ro w a d z ić postrzegania i oceniania oraz dalszych działali. N aw et m im o zgody co do istoty problemu mogą istnieć różne propozycje rozw iązań. Rozwiązanie to horv7 n n P
GmU m° Że StaĆ się źród*em innego. P roblem ^, rozwiązany’ ^ zm ian. D otyczy on krótszego
s S e r emCT We8°* W t e y m t o ^ m a m y do czynienia * decyzje o * Pomys*ów ewokujących zmiany, a w k o n s e k w e n c ji uecyzje o podejmowaniu działań. 164
Ciągłe zmiany wzajemnie oddziałujących zdarzeń i
pomysłów
C Czas » —._ Dział anie 1
/
Postrzeganie^
Postrzeganie i ocena (części) ciągłych zmian
prowadzi do
S/
Decyzje o działaniu
Rys. 6.1. Koncepcja zarządzania w ujęciu SSM ( 19]
Kolejnym założeniem metodyk społecznych jest spostrzeżenie, iż osoby i autonom iczne grupy dokonują zróżnicowanych ocen sytuacji problem ow ej, co może prowadzić do różnych działań. Stwarza to problemy (kontrowersje), z którymi menedżer musi sobie radzić. Ich rozwiązanie byłoby niem ożliw e, gdyby różne spostrzeżenia i oceny nie pokrywały się w jakim ś zakresie. To częściowe pokrywanie się, jest warunkiem istnienia organizacji. Poniew aż to pokrywanie się nie jest kompletne, występujące niedopasowania interpretacji faktów i logiki istniejących sytuacji prob lemowych stanow ią powód i istotę pracy menedżerskiej. Stw ierdzenie, iż w świadomej realizacji procesu zarządzania (rys. 6.1), użyteczne będą p o jęcia system ow e, jest trzecim założeniem SSM. System jest rozum iany jak o całość, która jest wyposażona w cechy, a dokładniej -jo zw ijąjący się zestaw cech (ang. emergent properties). Ważnym zadaniem badawczym je st więc ocena, do jakiego stopnia pojęcia systemowe ją . użyteczne w w yjaśnianiu postrzeganej rzeczywistości, której składniki są ściśle pow iązane. Stosow ane dotąd w praktyce przez badaczy systemowych pojęcia systemu naturalnego i sztucznego okazały się nieodpowiednie w odniesieniu do złożonych system ów społecznych. Stąd w SSM zaproponowano pojęcie systemu d z ia ła ln o śc i lu d zk iej (ang. human activity sytem ). rozumianego jako zestaw działań powiązanych w logiczną strukturę, stanowiących W arunkiem użyteczności tej nowej k a t e g o r i i jest stworzenie zestawu pow iązanych ze sobą pojęć stosowanych do opisu działań w swiecie rzeczywistym (dziedzinie przedmiotowej), co z kolei jest uzależnione *. 165
p B W '' . . , „y ślen ia o wybranym celowym . a „ n soosobach mówicm.*' • jmcrpretacji danej osoby. celowej działalno*« o d P ; k;Uegoriach poszczególnych działaniu. Opis celowego dzwtfani do a k c e p u b l -
G o to w o ść
interpreiacp czy I £
£
£
£
danego cc *
WeT Z Z
*
lkowany analitycznie,
J l f p o iw zg lęd e m zaiożeń opisyw anej dziedzin,
'¿ • - • » t " pewnego i
oznacza. £
^
.» —
HotYC/y0110 kazdtJ
, * t S .
J £
2
i
‘S
2
,v rhow ania i doświadczenia,
c™ y«^m ^
X h « W z w i U u Z ty m dow ota „r/wanych do z r o z u m i e n i a m m oie być odzwterctadlunaprzez celowa działalność w św iece rzeczyw y ^ różnych punkt„ w wtdzema. talka systemów działalność, 'traktowanie SSM jak o procesu W re s z c ie , p * ° ' )ecz.nej polega na porównywam« zapytań. U c z e n ie s tc w modeli systemów dztaialnosc, czy sty ch modeli działalności c sytuacji problem ow ej. Założenie to & ) z o ™ ^ f " r p ™ d S,aw ia cyk, uczenia * ilustruje rys. 6.2 \u> s. j-
k /
(Sytuacja problemowa w świecie rzeczywistym
Modele celowej działalności
Porównanie modeli z postrzeganą rzeczywistością
Działania dla poprawy sytuacji problemowej
Uporządkowana dyskusja o zmianach i środkach dla umożliwienia przeprowadzenia
tych zmian Rys. 6.2. Cykl uczeniu się w metodyce SSM 122]
w metodyce społecznej. Jest to operacja cyklicznego systemu uczącego się, w którym opracowane modele konceptualne są wykorzystywane do rozpoznania sytuacji problemowej, a następnie zainicjowania i uporządkowania dyskusji o celowej zmianie. W procesie uczenia się osiąga się wysoce jednoznaczne porównanie. Celem tego porównania, realizowanego w końcowych fazach metodyki, jest zapewnienie gotowości podejmowania działań celowych w badanej sytuacji problemowej. Działania te zdefiniowane są w trakcie dyskusji zainicjowanej w fazie porównań. Proces TSI, w ujęciu metodyki SSM. jest więc procesem partycypacyjnym, rozwijanym w drodze dyskusji.
6.2. Proces stosowania metodyki SSM M etodyka SSM jest realizowana w siedmioetapowym procesie, w sek wencji pokazanej na rys. 6.3 [17, s. 163]. Kolejnymi fazami w tym procesie są:
I
Podejmowanie działań > dla udoskonalenia f sytuacji problemowej
W prowadzenie do sytuacji problemowej
Określenie pożądanych i wykonalnych zmian
Porównanie modeli z działaniami w świecie rzeczywistym
Rozpoznanie
sytuacji problemowej
Świat rzeczywisty Myślenie systemowe o świecie rzeczywistym
Sformułowanie podsta wowych definicji dla odpowiednich systemów celowej działalności RJ
Opracowanie moce» konceptualnych < systemów opisanych ez definicje podstawowe
6.3. Proces użytkowania melodyki SSM H?-
' ,twprowadzenie do sytuacji problemowej. 2) ro z p o z n a n ie f ^ ^ j ^ S n w y c h 2) sformułowanie uenm tji i 4, £
^
i "
u
d l a odpow iednich systen,6
konceptualnych dla systemów opisanych pr2e,
definicje podsunrowe.
świecie rzeczyw istym ,
5) porównanie modeli z działania..
6i określenie pożądanych i rzeczywistych /m ian, 7 p o d e j m o w a n ie d z ia ła ń w celu doskonaleń,a sytuacj, problem owej. Etany I . ->oraz 5-7 realizowane są . wdrażane w ś w ie c e rzeczywisty^ i etapy 3 > * ™ sferze abslrakcJL Sekwencj a ta ma na celu osiągnięcie przejrzystości opisu, a nie ścisłego przepisu, którego kolejność musi być
bezwzględnie przestrzegana. Proces przebiega od rozpoznania i określenia problemu do podjęcia zdecydowanego działania w celu dokonania pozytywnych zmian w sytuacji problemowej. W łaściw ą podstawą tej transformacji jest doświadczenie. W przypadku SSM je st ono wzbogacone 0 zastosowanie myślenia systemowego. Stosownie do procesu przedstawionego na rys. 6.3, po stwierdzeniu 1 zlokalizowaniu sytuacji problemowej następuje jej rozpoznanie. Nigdy opis i ocena sytuacji problemowej nie są neutralne. W iedza, doświadczenie i interes dotyczą sposobu postrzegania i przyjęcia tego, co je st najistotniejsze w charakterystyce sytuacji problemowej. W łaściw ą tech n ik ą realizacji dwu pierwszych faz metodyki SSM są w zbogacone w iz e ru n k i (ang. rich pictures). Są one odwzorowaniem struktury i dynam iki analizowanej sytuacji, tj. powiązań i zależności między stanow iskam i i komórkami organizacyjnymi, pełnionymi przez nie rolam i, w ystępującym i konfliktami, strukturami, zdarzeniami i procesami w sytuacji problem ow ej. Technicznie mają one istotnie postać „obrazków", zawierających rysunki, ikony, symbole, powiązania i opisy. Sposób prezentacji pow inien być taki, aby byl dostatecznie wyrazisty i nie wymagał dodatkow ych w yjaśnień. Wzbogacone wizerunki pozwalają na skupienie się na najistotniejszych elementach sytuacji problemowych. Poprzez wizualizację sytuacji tw orzą one pomost, wspólną platformę dyskusji dla wszystkich uczestników procesu TSI. a więc zespołu projektowego, komitetu sterującego i użytkowników. Przykładem wzbogaconego wizerunku jest rys. 6.4.
7r ,GZynn0SC1 ,dentyfikacji i rozpoznaw ania sytuacji problem ow ej można zrealizować na trzy sposoby: • wstennp°\Wa^ e sk*ad™kdw struktury i dynam iki sytuacji problemoweja nasienni/ ^
168
T
!rZecieg0 1 z w a rte g o etapu procesu (por. rys. * rozpoznania sytuacji p r o b . e n -
Dział informatyki przesyła nieaktualno , Informacje
Dział Zamówień
Hurtownie
Ocena niezawodności dostawców
Obsługa informatyczna gospodarki towarowej /
Supermarket
Dział Informatyki
Dział Finansowy
Propozycje kredytowe
o Straty z tytułu nieracjonalnej ' gospodarki towarowej
\ w supermafk-ihce
Dyrekcja
Ocena jakośd i ceny Iowa row
Ocena zdolności finansowej
Klienci
BANK
Transport
Zainteresowanie zewnętrzne, nadzór, kontrola
Obszary sprzeczności i konfliktów
Główne problemy, obawy, kłopoty
Związki
Rys. 6.4. W zbogacony wizerunek gospodarki towarowej supermarketu
• charakterystyka struktury i dynamiki sytuacji problemowej wzbogacona ° listę zaangażow anych osób z określeniem oraz analizą ich ról. Pierw szy sposób pozw ala na formowanie udokumentowanego wzbo gaconym w izerunkiem obrazu, określającego, jakie są wzajemne relacje 169
gj » • . snuktury i dyna “
«¡vtu'icii problemowej. Wielu praktyków sądzi jednak ■. absm,kcyjn>, szczególnie w odniesieniu do
E d i konfliktowych sytuacji problemowych. Poszukiwano zatem
-sposób pozwala na wykorzystanie wy„ik6tt porównania między modelami a światem rzeczywistym. w konsekwencji sprzyja wiec rozumieniu i rozpoznań,u sytuacj, problemowej (fazy f i 2 procesu). Wadą tego podejścia jest ukierunkowanie myślenia na udoskonalenie efektywności już istniejących procesów i zadań, bez głębszej zmiany. Trzecie podejście wychodzi z założeń pierwszego sposobu, ale jest oparte na bardziej zaawansowanych zasadach, uwzględniających zakres pracy, obowiązków, uprawnień i ról osób oraz. jednostek zaangażowanych
w daną sytuację problemową. W rezultacie rozpoznania sytuacji problem owej i jej opisania przez wzbogacone wizerunki można przystąpić do zdefiniow ania systemu (lub
systemów) celowej działalności. Etap ten polega na określeniu tzw. definicji podstawowych (ang. root definitions) dotyczących system ów działalności Judzkiej. Czynność ta oznacza dokonywanie różnych interpretacji, przydatnych w dyskutowaniu, rozważaniu procesów i struktur w św iecie rzeczywistym. Wspólne rozpoznawanie sytuacji problemowej, poprzez uwzględnienie różnych punktów' widzenia (niem. Weltenschaiumgen), pozwala na osiągnięcie właściw-ej percepcji, a następnie podjęcie działań doskonalących bieżącą sytuację. W trakcie opracowywania definicji podstaw ow ych (zwanych definicjami CATWOE) rozpatruje się następujące elem enty: C (ang. customers) - osoby zyskujące lub tracące w wyniku celowej działalności (klienci), A (ang. actors) - wykonawcy celowej działalności, 1 (ang. transfonnation) - przedstawienie celow ej działalności proces w ejście-transform acja-w yjście (proces w po. staci przekształceń), (niem. Weltcmschauung) - punkt widzenia, który nadaje sens definicji a ^
q
p
podstawowej w danym kontekście, ~ osoby mogące w strzym ać proces transformacJi T (właściciel),
nei .
- założenia i ograniczenia otoczenia j ę g j , F
.
mowane przez system jako dane (ograniczenia środowiska).
świadome, szczeuółow fW° WyCh winno być konstruow ane poprze? CATWOE Rdzeniem , rozw?żanie kolejnych składników mnemoniku (przekształcenie) procesu P° dstawowej Jest T ~ transform acja wyjście systemu pr/v czvm znilenia określone w ejście w pożądane •P ym wejście musi zawierać się w wyjściu. Obowiązuje 170
też zasada, że abstrakcyjne wejście jest przekształcane w abstrakcyjne wyjście, podobnie jak rzeczywiste wejście musi przekształcić się w wyjście rzeczyw iste. Nie zawsze w praktyce dokonuje się tu właściwej interpretacji, popełniając błąd, polegający na złym zdefiniowaniu, zwłaszcza wyjścia. Transform acja przebiega zatem według następującego schematu: TO W A RY ZAKUPIONE
► TOWARY DOSTARCZONE
a nie: TO W A R Y ZAKUPIONE ------ > INFORMACJE O TOWARACH Celem trzeciego etapu jest sformułowanie spójnego zestawu definicji podstawowych CATW OE. na podstawie których można opracowywać modele konceptualne rozwiązania sytuacji problemowej. Przykładem definicji podstawowej, nawiązującej do przypadku identyfikacji i rozpoznania sytuacji problemowej gospodarki zapasami supermarketu, jest rys. 6.5 DEFINICJA PODSTAWOWA :
Użytkowany przez supermarket system sterowania zapasami towarowymi, zapewniający aktualną informacją, pozwalający podejmować racjonalne decyzje dla zadowalającego zaspokojenia popytu konsumentów, przez sprawną organizację dostaw towarowych i minimalizację strat z tytułu braków towarowych czy zapasów nadmiernych.
C
Klienci, dostawcy
A
D ział Zamówień, Dział Informatyki
T
Niesprawna obsługa _____ ^ gospodarki towarami ^
racjonalne, zcptymalizowanc. sterowanie gospodarką towarami
S t e r a n e zapasami tom rawym i przy prognostycznych i badań operacyjnych mazc zaspokajania papym klienta» i podniesie,tm zysku superntark.,,, O
Dyrekcja supermarketu
E
Dostawv Dostawytowarów towarowi technologii informatycznej, tykłama, now
'
Rys. 6.5. Detluicju podstawowa GATWOB
171
„
., ‘ ic,, .pracowanie modelu konceptualne,;« jako sekwencji w ^system « . . 1..*, 1 r ' n n v h, np r o c e s ó w reahzowanycn re a liz o w a n y c h w ie ceiowej celowej ‘I T - C n i c modelu inicjowane jesl przez w ybór i dobór działalność. ' „ vn„ości. działania występujące w danej sytuacji czasowników op. >. ^ ZOTtać jednoznacz„ie sprecyzowane w definicjach P r o w e n to w e j. W i n ^ " ^ . ^ na mu ^ d k o w a „ e prol?jcill J • \ / ^f*!i / uporządkow ane zonH«:« wybranie z logicznymi zależnością,ni pomiędzy czynnościami. czynność,am ,. O U dpow dpow iednie tedm e wybranie cz mności i określenie powiązań między mm, przesadza o użyteczności i takcjonalności projektow anego sys,en,u. dztęk,Iransdomtacjom określony™ w definicjach podstawowych. W metodyce SSM. podobnte ja k w projektowaniu strukturalnym, zalecane jest zastosowanie zasady „7 plus m inus 2" składowych K ońcow [19] do ocenv oceny liczby procesów procesow smuuww ^ . . system u. .w ..« ,« ;,y „model ,uuej k o n c e p tu a ln y " o p is u je docelowy system, który m o ż e być korygowany, m o d y f ik o w a n y , adaptowany i doskonalony w wyniku procesów komuniko wania i kontroli w zmieniającym się uotoczeniu. iu ^ c m u . W w zw iązku lz tym, iym, z eksploatowanym systemem i jego poszczególnymi podsystem am i winien być zintegrowany podsystem m onitorow ania i ste ro w a n ia , który sprawdza poprawność aprawnosc poszczególnych poszczegoinycn operacji upciucji i puuk.jim.ijt. podejm uje działania u/mmmm w kcelu tiu /.imany zmiany \ i udoskonalenia systemu. Istnieją trzy podstaw owe kryteria uwzględniane iworzeniu moutriu KUiiLCjnumnc^w, zwane / P i l i l i j3E j u , [20, s.39]. Są to: IU. przy tworzeniu modelu konceptualnego, • skuteczność (ang. efficacy) - pozwala odpow iedzieć na pytanie „Czy zaangażowane środki wywołuia wywołują zamierzony efe k t? " wydajność (ang. efficiency), czyli „Jaka jest relacja pom iędzy wartością anych zaso zasobów otrzymanego wynikli a wartością zaangażow zaangażowanych b ó w'?’ ?"’ • vefektywność (ang. effectiveness) „Czy transform wychodzi lv n v ycncój t >s\ ^JLy u cli I M U l H l cacja iL jct T 1 w yw lU U Z lI naprzeciw długofalowemu celowi analizowanego system u działalności ludzkiej?" 1
a
.
•
t
i
J
M
A 4
n
U
M
r
/
1
J
P
ł l v
P
I
•
' o
W
v
'
.
l u
l ^
'
_a
V ^ /
T
'
v / < ł7
I
I r ł A
.
l M
'
^
.
__ __
I
________
1
.
. 1 ____________ A . ___________________
v
1 1
^
I ' r\ fl n r t
j
n
u
n
i
^
v
u
I
1
J
v
j
i
/ M
t
t r \
i
v
u
i
v
j
u
#1 1111 j
I
w
/ I «
*
r-m l
CU
•
•
^
l v z u
.
v l ( |
1 «a
Model konceptualny sterowania zapasami superm arketu, w nawiązaniu do wzbogaconego wizerunku oraz definicji podstaw ow ej (rys. 6.4 i 6.5) przedstawiono na rys. 6.6. Dla danej sytuacji problemowej może pow stać kilka wzbogaconych wizerunków, opracowane daną . r rprzez j ^ iróżne UZ.11C osoby usuoy i grupy zaangażow ane w aaną SYtuacie nrnhiiam rm ,* . ° . > uację problemową, ponieważ zasadą SSM jest dopuszczenie różnych ^ IU U 1 zw iązana je st adekw pnnH o cto. l t o o ^ rrTT ™ r w “n ? f ? ynl.,Z, ni°h 2wiazana j ei*t adekw atna atna definicja definicja 6 5 i fi fi°Wah * model konceptualny. Przedstaw ione na rys. 6.4, Antvr™ uciiiuLjd podstawowa poastawowa ii m odel konceptualny d o ty c z ą te d n ,^ ^ ^ model konceptualny P *
w "y * « r * widzenia projektanta system u)* W praktyce.
i grun , v’ uc6ocJowania i porozum iew ania osuu i grup z a in te re s o Z i.T l" ,! ! ! ! ! ' Z * * * ™ ? * * ' Po raaim iev ran i* ^ i definicji podstawow ° h ,adania się różnych w zbogaconych w iz e r u n k ó w J P ł o w y c h dochodzi do określenia pożądanej zm iany. 172
Obrót towarowy
Ewidencja towarów
Tworzenie modeli zapasów
Analiza zapasów
Prognozowanie
Ocena strategii zakupu
Bieżące zamawianie
Negocjowanie warunków dostaw Zamówienia
Określenie kryteriów • skuteczność • wydajność • efektywność
Monitorowanie, kontrola
Podejmownie działań korygujących
Kryteria : 1• Skuteczność - czy istnieje sprawniejszy sposób sterowania zapasami w celu dostosowania ich do popytu klientów ?
2. Wydajność - jak zmienia się relacja pomiędzy zyskiem a ponoszonymi kosztami gospodarki towarami ?
3. Efektywność - czy przyjęty model zarządzania gospodarką towarową sprzyja ekspansji rynkowej supermarketu ?
Rys. 6.6. Model konceptualny sterowania zapasami towarowymi .supermarketu
Tw orzenie m odelu konceptualnego wynika więc z deitnicji pod stawowych. K ażde oznaczenie tych definicji prowadzi do konkretnych działań w m odelu, natom iast każdy składnik modelu powinien odnosić się do konkretnej części definicji C A T W O E . W ten sposób kształtowane jest 173
nwakt powiązanie Spojrzenie rożnych
podstawowych i modelu konceptualnego, 1mu pr()wadzić będ ?ic do nie ^ mają różne znaczenie dla różnych
niT Z Cownfe do punktu widzenia. Etap ten dostarcza zatem wielu i i s untów d ziała ń . Każdy model skoncentrow any jest wokół sposobu postrzegania rzeczywistości, zadeklarowanego " S CATWOE. stosownie do jednego z podstaw ow ych założeń SSM - różnorodności spojrzeń, ocen i działa,,. D lateg o w 0pinii Chcckianda na model konceptualny należy patrzeć pod kątem jeg„ spójności i przekonania do jego funkcjonalność,. a m e bezwzględnej
^ ^ W ynikające z definicji podstawowych modele konceptualne mogą być uporządkowane w hierarchię zależności. Model konceptualny preedstawiający system sterowania zapasami towarowymi w superm arkecie (rys, 6.6) może być więc „zanurzony” w szerszej perspektyw ie gospodarki finansowej firmy. Kolejne, ściśle powiązane fazy po opracowaniu modelu konceptualnego przenoszą proces tworzenia systemu do sfery realn ej (wykonawczej) i polegają na: • porównaniu modelu konceptualnego z sytuacją problem ow ą w celu uzyskania listy pożądanych zmian, • określeniu pożądanych zmian, możliwości i sposobów ich dokonania, a także skutków ich przeprowadzenia, • efektywnym przeprowadzeniu zmian, zaproponowanych w całym procesie. Modele konceptualne służą znalezieniu o dpow iedzi na pytania pojawiające się w fazie porównywania modeli z rzeczyw istością. Istnieje wiele sposobów przeprowadzenia takiej analizy porów naw czej. Podstawowe sposoby opierają się na zarejestrowaniu różnic pom iędzy modelami a rzeczywistymi zdarzeniami i ich ocenie albo pom iarze w edług kryteriów skuteczności, wydajności i efektywności. Różnice te i oceny są następnie dyskutowane pod kątem ich istotności dla funkcjonow ania przyszłego systemu. Można również opracować scenariusz funkcjonow ania modelu w aspekcie definicji podstawowych. W rezultacie realizacja tego etapu zapewnia podstawy do zorganizowania dyskusji na tem at istoty sytuacji p o emowej i wprowadzenia uzgodnionych zm ian w kolejnym etapie, aby nnip Z^C SyutUaCj? Pr°kleraową. Ostatni etap pozw ala na podjęcie akcji /aDrnnn ^ ° stalecznym wdrożeniu modelu z uw zględnieniem poprawek zaproponowanych w fazach 5 i 6. P O w i n ^ b ^ ^ J S ’ SytUaCji problem oweJ * proponow anej zmiany Stosowane nr/v v u °w ana, czego w yrazem je s t pism o ręczne. y konstruowaniu w zbogaconych w izeru n k ó w , defimej« 174
p o d s t a w o w y c h CA TW O E oraz modeli konceptualnych zamiast dostępnych p r e c y z y j n y c h opisów graficznych w pakietach CASE. Wynika to z akcen t o w a n i a aspektów socjologicznych i psychologicznych oraz z podkreślania ich przewagi nad aspektami technicznymi lub z podporządkowania technologii w a r t o ś c i o m hum anistycznym .
6.3. Role w zespole projektowym System y inform atyczne tworzone są w zespołach. Jak wykazał Checkland postrzeganie sytuacji problemowej przez każdego z członków zespołu m oże być zróżnicowane, choć występują pewne obszary pokrywania się ocen i interpretacji. Sytuacja jest dodatkowo komplikowana przez psychologiczne style zachowania poszczególnych członków zespołu. Istnieją różne klasyfikacje styli zachowania; w niniejszym opracowaniu przed stawiono propozycje de Bono [56]. Powodzenie przedsięwzięcia projekto wego zależy od właściwego doboru zespołu, z uwzględnieniem od powiednich um iejętności, możliwości twórczych, doświadczenia i styli zachowania. Role pełnione w grupie m ają charakter albo form alny (szef, asystent, kierownik działu, specjalista), albo nieform alny. Wiążą się one właśnie z czterem a podstaw ow ym i stylami zachowania, którymi są: • • • i
prom otor, pom ocnik (ang. supporter), sterujący (ang. controller ijn3 I 1tVK 1 W al / P oszczególne style są charakterystyczne dla danej osobowości 1 w za-
PROMOTOR
STERUJĄCY
-ANAbjTYK
6.7. Stylć zachowania 175
W kresie Poza stylem dom inującym , każda ¥ i Szic niezmienne w ^ " ś l o n y podsiyl. tak jak przedstaw iono to „ osoba w ramach stylu ma okt* ^ ^ si, „bok przeć,ęc, a osi rv
(-----
i
PO M O C N IK
prom otor
POMOCNIK
PROMOTOR
_________
i-
-
[
1 STE R U JĄ C Y
A NALITYK
ANALITYK
STERUJĄCY
+ O d p o w ie d zia ln y + + + + + + -
Bardzo emocjonalny Chce szybkich zmian Globalista Stymuluje Spontaniczny Głośno myśli Manipulacyjny Konkurencyjny Prowokacyjny Głośny Niesystematyczny
+ + + + +
P om ocny P o siad a intuicję U nika konfliktów D obry s łu ch acz E m o cjo n aln y
-
C zuły na k o m p le m e n ty nB ez za s ad " M usi być m iły Ł a tw o się p rze k o n u je
---------------------: I—
POMOCNIK
PROMOTOR
'
—
I
.
r
•
PO M O C N IK
PROM OTOR
vv • /
*
J
- f ,
* » |
•
I • V
llS, \ >
*1 ’
1
STERUJĄCY
ANALITYK
STERUJĄCY
ANALITYK
+ Naturalny przywódca + Aktywny i ambicjonalny + Niezależny + Sprawny + Kompetentny + Odpowiedzialny
+ Stabilizujący / + Koncepcyjny + Zbiera fakty + Dobry słuchacz + Bardzo systematyczny + Można na nim polegać
- Niecierpliwy - Niepodtrzymujący - Arogancki - Żądny władzy
- Niekomunikatywny - Introwertyczny - Trochę nudny - Niecierpliwy i wątpiący
• Nieinspirujący
Ryi>. 6.8. Zalety i wady poszczególnych stylów zachowania [56] 176
linl
w s p ó łr z ę d n y c h
s ą a d a p to w a in e i n ro e a n r ,v l„ z
•
zachowania. Osoby o podstylach znajdoiacVch ! L ' ° panować in"y styl rys. 6.7. cechują się stabilnością cech swego t ”! ™ kwadra,u na n a zy w a n e są s u p e r p r o m o to r a m i, su p e ra n a lity k a m i h d
ZaCh° W ania’ totó*
W największym skrócie; promotor generuje twń łagodzi konflikty, nie bronią^sw ego z d a n ia f hez naturalny lider (kierownik powierzanych mu zadań wykonawczych Testy dowodź “ dom inują style zachowania analityka i i prom otora w ystępują znacznie rzadziej Bliższa rh i wad poszczególnych stylów z a c h o w l ^ s * ,u z a c h o w a ń , danej osoby następuję
pomocnik w5'konawca ^
SteruJąceS°
A naliza zespołu projektowego pod kątem stylów zachowania po szczególnych je g o członków w zasadniczy sposób izutuje „a efektyw no« funkcjonow ania zespołu projektow ego i w konsekwencji na Z tw orzonego system u tnformatycznego. Obecność kilku naturalnych l i r ó w czyi, sterujących w zespole grozi ustawiczną walką o przywództwo! Zespół /ło żo n y jedynie z analityków zostanie pozbawiony bieżącej twórczej inspiracji, zapew nianej przez promotorów. A zatem, optymalny skład zespołu to: J e d e n sterujący, jeden promotor i po kilku analityków i pom ocników w ykonujących rudymentarną pracę.
Pytania i problemy 1. 2. 3. 4. 5. 6.
Jakie przesłanki legły u podstaw powstania metodyk społecznych? Scharakteryzuj podejście ETHICS. Podstawowe założenia metodyki SSM. Na czym polega koncepcja zarządzania w ujęciu SSM. Cykl uczenia się w metodyce SSM. Przedstaw proces stosowania metodyki SSM i wskaż na techniki właściwe dla poszczególnych faz. ?• Zinterpretuj znaczenie poszczególnych liter CATWOE. 8. Przedyskutuj sytuację problemową związaną z doskonaleniem procesu dydaktycznego na Twoim kierunku albo umacnianiem pozycji Twojej firmy na rynku. Zastosuj proces użytkowania metodyki SSM - por. rys 6.3 - i na podstawie rezultatów otrzymanych w punkcie 7 opracuj: • wzbogacony wizerunek, • definicję podstawową CATWOE, • model konceptualny. ■ W iedząc o cechach poszczególnych styli zachowania, spróbuj skonstruować optymalny
zespół projektowy. Uzasadnij swój wybór.
Komputerowo w spom agane tworzenie systemów informatycznych.
Pakiety CASE
7.1. Pakiety CASE - istota i generacje Idea wspomaganego komputerem tworzenia system ów informatycznych (Tsi) nie jest nowa. Już na początku lat siedem dziesiątych przeprowadzono w tej dziedzinie pewne badania, eksperymenty i wdroż.enia. Chodzi tu przede wszystkim o pakiet PSL/PSA. opracow any na Uniwersytecie Michigan. Prawdziwy jednak przełom w tej dziedzinie nastąpił w latach osiemdziesiątych, wraz z masowym użytkow aniem mikrokomputerów. Stworzyły one możliwość powiązania dotychczasow ego bogatego dorobku w sferze metodyk TSI z cechą przyjazności (ang. user-friendliness ) oprogramowania. Powstają w ten sposób liczne pakiety wspomagające proces TSI, nazywane powszechnie w świecie CASE, od ang. C - computer, A - aided, assisted, S - software, system , E - engineering. Sformułowanie zostało po raz pierwszy użyte przez prof. J. Manleya z Camegie Mellon University w 1981 r. O kreśla on tym pojęciem narzędzia, które wspomagają zautom atyzow ane tw o rzen ie systemów informatycznych w trakcie cyklu życia system u. J P a k i ety C A S E stanowią [105, s. 169] zastosowanie technologii kom puterow ej w odniesieniu do procesów, technik i metodyk tworzenia systemów inform atycznych. Spotyka się również zamiennie skrót IPSE (ang. integrated project supporting environment). Niektórzy autorzy podkreślają, że chodzi w tym przypadku o pakiety wspomagające przede wszystkim inżynierię oprogramowania lub kierowanie projektami. Nazwa CA SE je st skrótem powszechnie stosowanym w różnych językach. D o p o w stan ia tech n o lo g ii CASE rzyczym a się wiedza metodologiczna o tw orzeniu system ów informatyczc
A
s
k
tote^
r 4
178
p
Z
s
v
^
r
7 a
r a ik r o k o m
k p u t e r ó w
-
D
r o g ę
r o z w
o ju
p a k ie t6 w
ka ? defi?ic-ii’ p°jęcie technologii C A S E je s t bardzo pojemne, n° tej kategorii różnorodne narzędzia i pakiety z dziedziny
Lata osiemdziesiąta
Zastosowania mikrokomputerów
Metodyki strukturalne oparte na liniowym cyklu życia systemów
Przyjazne oprogramowanie narzędziowe mikrokomputerów, graficzny interfejs dla użytkownika
Rys. 7.1. Rozwój pakietów CASE
inżynierii oprogram ow ania. Była to oczywiście reakcja twórców oprog ramowania na im pulsy rynkowe. Jednakże genezy pakietów CASE należy upatrywać w próbach komputerowego wspomagania użytkowania bądź autom atyzow ania faz analizy i projektowania systemów informatycznych, a więc w p o d staw ach metodologicznych TSI. Odtąd pakiety CASE są nierozłącznie zw iązane z metodykami TSI. Powszechnie toruje sobie drogę p rzek o n an ie, iż bez swoistego przewodnika - metodyki TSI - w ykorzystanie pakietu CASE może mieć ograniczone bądź wręcz negatywne oddziaływ anie. W praw dzie historia technologii CASE jest krótka, lecz można już mówić o dw u jej generacjach [31]. Pierwsze narzędzia wycinkowo wspomagały użytkow anie poszczególnych technik bądź realizację pewnych fragmentów cyklu życia systemu. Zadania te realizowano autonomicznie, bez zapew nienia autom atycznego przepływu opisów pomiędzy kolejnymi fazami, lub w ykorzystania wspólnej encyklopedii systemu. Pierwsze pr u ty c ASE elim inow ały konieczność realizacji rudymentarnych czynności analityków, projektantów i programistów, zwłaszcza poprzez komputer) .' "ję generowania, aktualizacji i modyfikacji różnego rodzaju
lagram 179
Doświadczenie w użytkowaniu pakietów CASE oraz logika metodyk tworzenia systemów skłaniały ku ich integracji w pakiety w s p o m a g a ją cały proces TSI. W ten sposób, począwszy od 1986 roku powstawały kolejne pakiety CASE (drugiej generacji) zwane pakietam i zintegrow anym i czyli J-CASE. Integracja przebiegała wokół pełnej realizacji cyklu żyCia systemu oraz encyklopedii zawierającej wszystkie opisy system u (diagramy macierze, tablice, opisy słowne) oraz powiązania między nimi. Podstawowym składnikiem pakietu CASE (rys.7.2) je st encyklopedia systemu, zwana również repozytorium (ang. repositoty). M ożna ją, określić jako bazę danych twórców systemu - zbiornicę w szystkich obiektów Występujących w danym systemie oraz zależności m iędzy nimi wraz' z modułem zarządzania obiektami. Obiekty te to różnego rodzaju specyfikacje' systemowe, jak diagramy przepływu danych, zw iązków encji, Jacksona diagramy struktury, schematy baz danych, prototypy system ów , formatki ekranów czy zestawień wynikowych, definicje dialogu, m enu i programy zastosowań. W ten sposób encyklopedia system u je s t składnikiem
Edytory diagramów
Moduł kontroli spójności
\
Prototypowanie
Encyklopedia systemu
Generowanie kodu
systemu
7.2. Podstaw
owe ^ ia d n ik i pakietu CASE
• • • • • •
edytory diagram ów różnorodnych technik TS17— -------------generator kodu programowego, m oduł prototypow ania systemów, m oduł m odyfikacji i adaptacji systemów. m oduł eksportu/im portu danych, m oduł kontroli spójności systemu.
D o d atk o w e m oduły występujące w różnych pakietach to: edytory w erbalnych opisów systemu (powiązane często logicznie z edytorami graficznym i), moduły zapytań i generowania zestawień, przygotowanie dokumentacji systemu, kontroli wersji projektu i poufności danych, samouczki. Pakiety obejm ujące wszystkie lub większość wymienionych modułów, charakteryzują się na ogół wysokim stopniem integracji, wzajemnej współzależności i sekwencji użytkowania. Coraz większego znaczenia nabiera jednak kw estia autonom iczności modułów. Na przykład generator kodu APS w pakiecie E xcelerator może być użytkowany niezależnie, z pominięciem odpow iedniego m odułu w ysokiego poziomu. Specyfikacje do generatora przygotowuje się autonomicznie na zasadzie prototypowania. Oprogramowanie CASE m a w ów czas charakter m o d ularny i określa się go mianem M-CASE. Pakiety C A SE użytkow ane są najczęściej przez pojedynczego twórcę w odniesieniu do danego projektu. Tworzy on lokalną encyklopedię tego projektu, m ieszczącą się w ramach centralnej encyklopedii, zawierającej pełne inform acje o zrealizow anych, aktualnych i planowanych systemach inform atycznych danej organizacji. Systemy informatyczne powstają jednak w zespołach. O czyw iście m ożliw a jest równoległa praca projektantów na różnych m odułach danego pakietu CASE. Bardziej pożądane jest jednak jednoczesne m odelow anie danych czy procesów przez zespół projektantów. Rozwiązanie to je s t m ożliw e dzięki sieciom i oprogramowaniu sieciowemu. Lokalna encyklopedia system u może być aktualizowana przez cały zespo równolegle, dzięki serwerom sieciowym. Stawia to określone zadania przed m odułem zarządzającym encyklopedią systemu, który powinien zapobieeać w nrow adzaniu zmian do danej specyfikacji przez Projektu system u inform atycznego w CASE w sieci przedstaw ia rys. 7.3.
w
"oC
>>>y Encyklo pedia systemu;
m
Projektant
Lokalna sieć komputera
Równoczesne użytkowanie Analityk
Infomenedżer
Równoległa aktualizacja
ił Analityk
Użytkownik
Projektant
Rys. 7.3. Użytkowanie pakietu CASE w sieci
Aktualne udoskonalenia pakietów CASE drugiej generacji zm ierzają ku. • uzupełnieniu o możliwości technik projektow ania i program ow ania systemów w czasie rzeczywistym, • zastosowaniu baz wiedzy i systemów ekspertow ych dla doradztwa w zakresie alternatywnych rozwiązań.
7.2. Rodzaje pakietów CASE Duża różnorodność pakietów CASE na rynku oprogram ow ania (jest ich aktualnie kilkaset) stwarza pewne problem y z ich klasyfikacją. Czynnikami, które wpływają na brak precyzji tej klasyfikacji są: szybki rozwój i doskonalenie pakietów, zm ieniająca się oferta rynkow a, tj. proponowanie nowych pakietów przy jednoczesnym zanikaniu ju ż wprovvadzonych, różnorodność metodyczna, brak standardów oraz niejednolitość pakietów obejmujących zmienny obszar tem atyczny. P odstaw ow e kryteria Jdąsyfikącyjne to: ----------• kompioksoweso,T _• otwartość. 182
elastyczność metodologiczna. j
. rodzaj w spom aganego modelu dziedziny .przedmiotowej
i
owanym b yJ,rałum t o i m poaziatu podziału jesl jest kompleksowoś« i • p al ec pe *Prcyjm 7 * , jest narzędzi CA SE. Z te g o jp u n k tu ^ d d ^ n ia dzieli sie ie na• cząstkow e, - l.c-c ;y*>a * pośrednie, j ■\ ,- / z in te g ro w a n e .^ ^ ... J U uTa w m \ £ j ' a C ząstk o w y M k t X A S Ł ® SEpmaga użytkowanie w ybranei metodv c z y je c h m k t. Przykładam i takiego pak ieti * np. GraphDoc, p o z w ^ S na generow anie A -grafów , czy I-grafów w metodyce ISAC bądź edytory graficzne diagram ów przepływów danych, diagramów związków encji lub innych technik diagram owych. Z kolei pakiety pośrednie pozwalają na wspomaganie jednego lub kilku etapów cyklu życia procesu TSI w określonej metodyce- Pakiety te w ykorzystują repozytorium (encyklopedię systemu) Z bardziej znanych produktów CASE warto wymienić tu: Excelerator czy Teamwork. Celem użytkowania pakietów zintegrowanych jest wspomaganie całego cyklu życia systemu, począwszy od analizy strategicznej działalności gospodarczej firm y i definiow ania założeń systemu, poprzez.jego projekt, do w drożenia przy użyciu generatorów kodu i schematu bazy danych. Pakiety te na ogół pow iązane są ściśle z pewną metodyką tworzenia systemów inform atycznych oraz relacyjną bazą danych. Egzemplifikacją takiego pakietu je st Inform ation Engineering Workbench firmy Knowledgware. N arzędzia cząstkow e m ogą być użytkowane niemal ad , podczas gdy efektyw ne stosow anie pakietów zintegrowanych wymaga specjalis tycznego przeszkolenia. F u n k c jo n a ln y z a k re s typow ego zintegrowanego pakietu CASE przedstawia rys. 7.4 [74], Poszczególne narzędzia odpowiadają głównym fazom cyklu życia system u, a więc planowaniu i analizie (narzędziom analizy), projektow aniu (narzędziom planowania i projektowania i analizatoro wi projektu), w drażania (generatorow i kodu) oraz eksploatacji, modyfikacji i adaptacji (narzędziom testowania). Pogrubione strzałki na rys. 7.4 oznaczają automatyczny lub półautom atyczny przepływ specyfikacji projektowych lub program istycznych pom iędzy poszczególnymi fazami. W pierwszej fazie następuje o p raco w anie ogólnego opisu, modelu, szkicu_badanejjizigdjdny^ -Ptzedm iotow ej^-M aja one postać diagramów i macierzy. Przygotowanie różnorodnych g raficzn y ch opisów w tej fazie jest czasochłonne, y ajnosc twórcy system u m oże być zwielokrotniona dzięki grafice komputerów j 'g e n e ro w a n iu i edycji różnorodnych grafów i schematów, a amui ie*ocenie rozw iązań alternatywnych w celu modyfikacji i u os 'on- ernla Technika kon stru ow an ia tych grafów powinna być stosunkowo prosta, aby
hoc
użytkownicy m ogli j ą zrozum ieć i stosować.
183
Narzędzia planowania i analizy
Narzędzie projektowania
Encyklopedia systemu - typów danych - definicji danych - struktur baz danych - zdefiniowanych formatek ekranów - wzorów zestawień - diagramów projektów - procedur - przypadków testowania
Analizator projektu
Projektowanie, grafika, wydruki
Generator kodu
Narzędzia testowania
czynności zautomatyzowane
czynności wspomagane
komputerowo Rys. 7.4. Zakres funkcjonalny zintegrowanego pakietu
W p r o ie k t s
Z Z T fr s t e m u Z
P ° w i" ie "
° le ‘ P ° W in ie n m ie ć
CASE f73]
ła t w o tra n s fo rm o w a n y c e c h y J e d n o z n a c z n o ś c i,
programowy. Projekt' L i t kon *7° aUloraatycznie g en erow any na kod wskazującego biedv skład • • r0 0Wany Przez a n a liz a to ra projektu, i zupełności projektu. ' sem antyczne’ M ró w n ież b rak spójności
Podlega testowaniu dla s p r a w d z a ^ fazie k o d Pr° g ramowy Podobna procedura choć prowadyn • ? m a reallzacji celó w systemu. schematu - najczęściej r e la c y jn i m etodam i>dotyczy generowania oddziaływać na zmiany w praiek™ h 7 ' danych' W y™ki testu mogą zaznaczyć, iż pakiety CASP • W m odelu system u . Należy liwiającego płynne p r z e iś r ip T tharakteru »autom atu” um ożspecyfikacji potrzeb infonm tv °P ISU d zied zin y p rzed m io to w ej lub t e y danych. Z c a l, £ £ $ ? $ * d° k° du w y n ik o w eg o i schematu dążą producenci pakietów C A sp m rozw ,ązanie stanow i c e l, d o którego a dom inują pak iety otwarte na
184
rożne opcje metodyczne powiązane z sobą logicznie, lecz nie automatycznie. Stąd generatory kodów poszczególnych języków projektowania, będące składnikam i pakietu CASE, często użytkowane są jako oddzielne pakiety oprogram ow ania. r J K w estia bezpośredniego związku pakietu z określoną metodyką jest podstawą kryterium otwartości, tj. podziału na pakiety otwarte i dedykowane. Założeniem pakietów otwartych jest stworzenie elastycznego narzędzia które m oże być wykorzystane w całości lub w części; w odniesieniu do różnych m etodyk TSI, stosownie do preferencji użytkownika. Pakiety te skoncentrow ane są wokół encyklopedii systemu i posiadają budowę m odularną. U żytkow nik decyduje o doborze modułów właściwych dla danego projektu. Pakiety mają najczęściej poszerzającą się liczbę sprzęgów (ang. bridge) do najbardziej popularnych systemów zarządzania bazami danych oraz generatorów kodu. Rozwiązanie takie znakomicie poszerza zakres użytkow ania pakietu. Przykładem tego typu pakietu jest System D evelopm ent W orkbench. N atom iast narzędzia dedykowane są bardzo ściśle zw iązane z określoną metodyką. Integracja metodyki i narzędzia jest elem entem określonej strategii rynkowej producenta oprogramowania bądź firmy doradczej. Istnieje zatem ścisły związek między fazami, zadaniami czy technikam i danej m etodyki tworzenia systemów informatycznych a m odułam i danego pakietu. T ak powiązane są pakiet Prokit* Workbench z m etodyką STRADIS czy Information Engineering Workbench z podejściem Inform ation Engineering. Z bliżony do zarysow anego jest podział Vesseya [102] nawiązujący do pakietów CASE w spom aganych metodycznie. Otóż wyróżnia on pakiety: • kierujące zespołem projektowym i narzucające sposób tworzenia systemu. np. poprzez kom unikaty błędów, • doradcze —zachęcające do określonej procedury metodycznej, np poprzez kom unikaty ostrzegaw cze, • elastyczne, pozostaw iające twórcy swobodę doboru metodyki. W odniesieniu do trzeciego kryterium można wyodrębnić: • pakiety b ez reguł m etodycznych, i • pakiety z w budow anym i regułam i metodycznymi, ! • pakiety z m ożliw ością w łasnego rozbudowania ręguł metodycznych. Pierwszy rodzaj narzędzi CASE stanowią proste edytory poszczególnych diagramów czy m acierzy. Ich celem jest szkicowanie graliki s> stantu. Utrzymana je st kontrola spójności i zupełności opisów. Regub zapisane są przede wszystkim w zintegrowanych i dedy owanyc CASH. Z łam an ie reguł je s t sygnalizow ane. Podejmowane * Umożliwienia tw órcom system u i użytkownikom zapisu ł t e } •«sad. Pakiety takie uw zględniają elem enty sztucznej inteligencji.
próby
■ wvf,rium podziała jest wybrany m odel dziedziny p rWll. . wyróżnia * pakiety C A S E w s p o n t a ^ s tru k tu ra ln i obiektowe bądź społeczne m etodyk, tw o rzen ia system** pakietów CASE zdom inow ane są przez odniesienie do cyklu żyda systemu. Tymczasem stosowane są one do szerszej kiasy ae dn eń jak' przechowywanie danych, k.erow am e real.zacją projeklu, modyfikacja i adaptacja systemów. Z tego punktu w tdzem a sy ntetyc2„ą, Obszerna jednocześnie precyzyjną klasyfikację opracow ała firm a doradcza CASE Research [15]. Uwzględnia się w mej pięc następujących klas.. a
pakietów CASE: • przechowywania danych, • wspomagania cyklu życia systemu, • adaptacji i modyfikacji systemów, • kierowania realizacją projektów, • bieżącego doskonalenia jakości systemu. Bieżące doskonalenie jakości systemu
Kierowanie \ Wspomaganie realizacją cyklu życia projektu / systemu
Modyfikacja i adaptacja
Przechowywanie
danych Rys. 7.5. Model klasyfikacji pakietu C A S E [15]
Podaną klasyfikację graficznie przedstaw ia rys. 7 .5 ............. W KOiejii , erec Pun^ ac^ scharakteryzowano wymienione klasy pakietów , począ1 C asf T ^ ZI wsPomagających cykl życia system u. W praktyce pal intetmiin!^eC nie omtwiT
dan^ch w Postaci en cy k lo p ed ii system u stał] adnikiem większości pakietów i śro d o w isk CASE, l
przedstawiono ^ p u n k e f e T i
Wf
•
duety
ca^
t
^ ”
A—
środow isk CASJE._
L
°
dp0wi edni ą d eflnicj«
enc>'kl01
tendencJi w ylania się k lasy fik acja na: ™
' ,Z° S' a,y jUŻ obszem ie zaprezentowane jako wycinkowe pośrednie, zintegrow ane, otwarte, dedykowane czy też o r ń ż Z , , uw zględniania reguł metodycznych, śro d o w isk a CASE tworzone s , p r a ż znaczących producentów sprzętu i oprogramowania. Zmierzab onTdo opracow ań,a swoistych standardów CASE, umożliwiających kompatybi n o t tw orzonego t użytkow ego oprogramowania. Przykładami są tu AD/Cvc e firm y IBM oraz CO HESIO N DEC-a. AD/Cycle Podane klasyfikacje dotyczą przede wszystkim narzędzi CASE zw iązanych z podejściem strukturalnym. Zintegrowane pakiety w coraz w iększym stopniu obejm ują jednak komputerowe wspomaganie modeli obiektow ych, ja k np. przedstawiony w pkt 7.8.2 pakiet SDW Z przyczyn w yjaśnionych w rozdz. 6, w podejściu społecznym unika się pakietów CASE. N ależy zaznaczyć, że w związku z szybko postępującymi zmianami na rynku oprogram ow ania, pozycja i znaczenie wymienionych w niniejszym rozdziale konkretnych produktów może się zmieniać.
7.3. Wspomaganie cyklu życia systemu A kronim C A SE najczęściej kojarzony jest ze wspomaganiem cyklu życia system u. Istotnie, w tej dziedzinie stworzono największą liczbę popularnych narzędzi. M im o prac nad integracją pakietów CASE, zazwyczaj są one sp ecjalizo w an e i w spom agają wybraną część cyklu. Wśród producentów oprogram ow ania nastąpiła tu wyraźna specjalizacja. Pakiety w spom agające cykl życia system u można podzielić na [43; 46]: • planow ania strategicznego i modelowania gospodarczego, • w ysokiego poziom u (ang. upper CASE lub front end tools), • niskiego poziom u (ang. lower CASE lub backend tools). P ierw sza klasa pakietów CASE wiąże się z wstępną fazą cyklu życia systemu. W y m aga ona specyficznych podejść, metod i narzędzi. Znaczenie tego typu narzędzi w zrasta w związku ze strategią wspomagania celów organizacji gospodarczej systemami i technologią informatyczną. Określone zostają bazy danych, sieci komputerowe i zastosowania z nimi związane, które należy zaprojektow ać i wdrożyć. Wynikiem planowania strategicznego oraz m odelow ania działalności gospodarczej jest przede wszyst tz strategiczny p la n inform atyzacji (ang. Information Strategy Plan), i wany w skrócie infoplanem . Jak stwierdzono w rozdziale 2, podstawowe zależności pom iędzy jednostkami organizacyjnymi procesam i gospodarczym i i strukturami danych (encjami, danp, organizuj
18
?
■ü
o n w n d /e n ia ,
jej zadania, istotne czynni strukturę organizacyjną
p
Przykład u“a c " a z y
problemy, potrzeby informatyczne, howywany w encyklopedii pakietu svs.en,u informatycznego.
planowania systemu inform atycznego (zależność
„«w.«v/encie) zawiera rys. 7.6. Page V e rs io n A u th o r
System D evelopm ent W orkbench System exam ple 6 Type : R elationship m atrix nrnrp^V Name pruoc^y * * ©ncie ^ }
----------------------------
.
M o d ifie d : 14-03 -1 99 6 D a te : 14 -03-19 9 6 -------------
D M entity
zasó b p ła tn o ś ć l fa k tu ra w yrób h a rm o n o g ra m j zapas d o s ta w a z a m ó w ie n ie d o s ta w c a dział produkcji oían produkcji è plan sp rz e d a ż y ii I produkt 1 f klient 1 I rynek plan w ykorzystania z a so b ó w [ dział m arketingu - ■zarząd — ■—i u C TT u strategia U u marketing * U cl U w ytw arzanie z a so b o w u c __i c C u U analiza rynku przetw arzanie zam ów ień sprzedaży h— c U u kontrola produkcji u c c U u produkcja u u u c kontakt z d o staw cam i u u C u przetw arzanie zam ó w ień zakupu u U u u c sterow anie z a p a sa m i u u u u dystrybucja u u fakturow anie u u u u u u u przetw arzanie płatności u [kontrola użytkow ania z a so b ó w u u u
Iu
-^
: 1 : :
TT u
u
L
u
t A ^ .i ! . J&. .
u u u c
U
u
u
.i
••¿¿a
u
_____;
SU
u
c c
.<—
u c u c
m
JŁ
2 L
IA activity
„ U" - użytkow a n i e
mc m -
tw orzenie
Rys. 7.6. Macierz planowania systemu w pakiecie SD W
Poza techniką BSP zasadnicze znaczenie w tej klasie pakietów CAS mają scharakteryzowane w rozdz. 2 techniki analizy sytuacyjnej, ja k sesj MetaPianu, SWOT czy CSF - istotne czynniki pow odzenia. Dodatkowyi mw — . PianU StrategiczneS° ^ ogólne diagram y dziedziny przeć otowej, jak diagram dekompozycji funkcjonalnej, diagram kontekstów; zerowy czy systemowy A-graf, ogólny model związków encji czy obiektow;
k 188
— 616 zillte8rowanych, użytecznych, komputerów ych podejść do planowania system ów inform atycznych. Prop<
„cw anym i przez firmy doradcze i stosowanymi w praktyce metodykami planow ania strategicznego i modelowania gospodarczego poza BSP finnv ang' a,egic and " ,f0— p‘a^ r™ ' d c e czy SU M M IT rhrm y nCoopers Lybrand. 5>— Pakiety w ysokiego poziom u stają się głównym środkiem wspomagania realizacji taz analizy i projektowania systemów. Umożliwiają one sprecyzow anie i zarejestrowanie potrzeb informatycznych, opracowanie projektów, przy jednoczesnym utrzymaniu kompletności, spójności i po prawności specyiikacji. Pakiety te różnią się znacznie zakresem technik diagram ow ych, jak również technicznym i programistycznym sposobem realizacji. G łów nym zadaniem tej grupy pakietów jest generowanie różnorodnych diagram ów oraz utrzymywanie ich spójności i kompletności. Obecnie dostępnych jest około 100 rodzajów diagramów związanych ze strukturalną analizą i projektowaniem systemów. Również w podejściu obiektowym proponow ane są techniki diagramowe, omówione w rozdz. 5. Ogólnie d ia g ra m y te można podzielić na trzy grupy: • opisu statyki dziedziny przedmiotowej, • opisu dynam iki, • inne diagram y. Podstaw ow ym typem diagramu definiowania statyki jest model związków encji zaproponowany przez Chena. Dotąd opracowano liczne jego m odyfikacje i konwencje. Innym rodzajem modelowania danych są binarne m odele NIAM . Najbardziej uznanym rodzajem opisu dynamiki dziedziny przedm iotow ej są diagramy przepływu danych w konwencji Y ourdona-D eM arco lub G ane’a-Sarsona. Do techniki tej nawiązują diagram y W a rd a -M e łlo ra w odniesieniu do systemów pracujących w czasie rzeczyw istym , wzbogacone o oznaczenia sterowania przepływami danych i procesam i. In n e diagram y opisujące zarówno elementy statyki, jak i dynam iki dziedziny przedmiotowej to: grafy 1SAC, sieci Petri. diagramy struktury, diagram y Jacksona i W amiera-Orra. Najprostszy pakiet w ysokiego poziom u składa się z edytorów diagramów związków encji i diagram ów przepływów danych, prostego słownika/skorowidza danych oraz program u sprawdzającego spójność i kompletność opisow Ta najuboższa w ersja jest wzbogacana o edytory i™1)'0 îagnuno danych oraz pełną encyklopedię systemu. Przykładami pakietów wysokiego poziomu są: • Excelerator produkcji INTERSOLV, • System D evelopm ent W orkbench z Cap Gemini • Information E ngineering W orkbench hrmy Know e g Pakiety niskiego poziom u ukierunkowane ^ Projektowania technicznego, program owani ,
,T i ar
^ mpdyf i kacj i
X
infnm ritvcziw ch. W ykorzystują one jako wejście i użytkowania sysienl 1^ rezultatem faz planow ania strategicznego, specyfikacje systemów. v ziom u um ożliw iają automatyczne analizy i projekKnuuu . ^
aenerinvanie formatek, w zorów zestawień, —
b a/ danych o ra / kodu. C / y „ n „ ści „
można podzielić na trzy glowne grupy. . generowaniakod“ l
usuwania błędów (ang.
komputerowego wspomagania tworzenia fomtatek. menu, struktur danych
‘ o "1le istnieje zgoda co do w yodrębnienia grupy narzędzi CASE niskiego poziomu, o tyle ich klasyfikacja jest przedm iotem kontrowersji. Nakładaj, się tu pewne podziały z dziedziny inżynier,, program owania, pojawiali, nowe trendy i pojęcia, np. narzędzia czw artej g en eracji. Wiele różnorodnych z natun' rodzajów oprogram ow ania anonsow anych jest jako pakiety CASE. Wydaje się. iż aktualnie m ożna je d n a k w y ró ż n ić trzy podstawowe rodzaje pakietów C A S E niskiego poziom u. • generatory kodów, • profesjonalne narzędzia czwartej generacji, • narzędzia zastosowań dla użytkownika.
Najbardziej znanym narzędziem tej klasy pakietów C A SE są generatory kodów. Rezultatem wykorzystania właściwego generatora kodu jest kod źródłowy w ustalonym języku trzeciej generacji, np. C O B O LU , PASCALU, PL-1 czy C++. Technologia ta, mimo wysokiego stopnia zaawansowania, nie ma charakteru automatycznej transformacji i w ym aga stałej współpracy programisty. Przykładami generatorów kodów są A PS, D ELTA , NETRON//CAP, TELON, Micro Focus COBOL P rogram m er’s Workbench. Istnieje kilka sposobów rozwiązania problemu generow ania kodu. Najbardziej znany polega na bezpośrednim wprowadzaniu do generatora kodu specyfikacji przygotowanych przy użyciu narzędzi CASE w ysokiego poziom u. Procedura polega na interaktywnym trybie pracy pom iędzy d w o m a rodzajami i poziomami pakietów. Ma to miejsce szczególnie w zintegrowanych pakietach CASE (I-CASE). Inne rozwiązania polegają na transformacji wysokiego poziomu specyfikacji użytkownika i program isty, opracowanych a danego pakietu, i zapisywaniu ich w kodzie konkretnego języka programowania.
Z kolei profesjonalne narzędzia czw artej g en eracji umożliwiają orzeme złożonych zastosowań w systemach transakcyjnych. Przykładami czv T i^ O M J°,nalnych Są CORVISłON, ID EA L, M A N T IS, N A T U R A L którzv n™ ^ te stosowane są przez użytkowników-nieinformatyków, y P tn ą stworzyć proste zastosowania w spom agania bieżących decyzji-
190
3 użytkow nika są: FO CU S, M APPER RA , , Narzędzia te umożliwiają użytkownikom opracow ani torm atek ekranowych, formularzy zestawień oraz menu. R A M IS
SAS
N
T
7.4. Modyfikacja systemów K ońcow a faza cyklu życia systemu, tj. jego użytkowanie, zawiera « w, w sobie czynności m odyfikacji i adaptacji systemu, ukierunkowane na ,« stałe utrzym yw anie bądz podnoszenie jego jakości. W tradycyjnym rozum ieniu m odyfikacja (ang. re-engineering) obejmuje zarówno korektę błędów i braków, jak i stałe poszerzanie istniejącego systemu dla zaspokojenia nowych potrzeb informatycznych. Obydwie czynności wymagają oparcia na dobrze udokum entowanych, spójnych, kompletnych i poprawnych specyfikacjach systemowych. Często powstawały one w różnych okresach, tw orzone przez różne zespoły, przy użyciu różnych technik i narzędzi' Toteż jednym z podstawowych problemów w rozbudowie systemów jest trudność w zrozumieniu ich analitycznych, projektowych i programistycznych specyfikacji. Dochodzi problem wzajemnych współzależności. Otóż zmiana jednego, p ozornie naw et izolowanego aspektu systemu bez analizy i spraw dzenia potencjalnego wpływu na inne elementy systemu, staje się źródłem pow ażnych dylem atów i niepowodzeń w fazie jego eksploatacji. Konieczność rozw iązania tych problemów, przy jednoczesnej złożoności współczesnych system ów informatycznych, stała się stymulatorem rozwoju metod m odyfikacji system ów i wspomagającej je klasy systemów CASE. Przez m odyfikację system u należy rozumieć proces zmiany, adaptacji istniejącego system u. O ile bowiem pakiety CASE wspomagające cykl życia system u należy wiązać z tworzeniem nowych systemów, o tyle modyfikacja dotyczy system ów już eksploatowanych. M odyfikacja stw arza możliwości zmian i uzupełnień systemu zarówno dla użytkow ników , ja k i twórców systemów informatycznych: • użytkow nik m oże definiować zmiany i korekty w eksploatowanym systemie w m iarę pojaw iających się potrzeb informatycznych, • analitycy i projektanci w drażają proponowane zmiany, przygotowując odpow iednie specyfikacje, . • programiści dokonują zmian dokumentacji projektowej na po stawie kodu pro g ram u, zm ian technologii przetwarzania, restrukturyzacji program ów, oceny wpływu zmian na koszty użytkowania systemu. Stosow nie do pow yższych założeń i oczekiwań rozwinę y się i towały narzędzia C A SE modyfikacji systemów. Celem tej Uasy p Jest „ocalenie” istniejących zasobów, zainwestowanych uprzeć m p
W zw ią z k u z potrzebą zmian założeń systemów,
Zadanie to osiąga się na podstaw ie analizy R o z ró ż n ia się trzy ro d zaje [105] pakietów • restrukturyzacji systemów, ••
• opracowanie strukturalnej postaci programów, • zmiana technologii przetwarzania danych. Zadaniem pierwszego rodzaju restrukturyzacji jest ułatw ienie użyt kowania opracowanych uprzednio programów7 poprzez doprow adzenie ich do postaci strukturalnej. Często programy te nie posiadają żadnych dokumentacji, a zatem trudno zrozumieć ich strukturę a tym bardziej dokonać niezbędnych zmian, korekt i adaptacji. Zrestrukturyzowane programy mogą być nadal eksploatowane na poziom ie kodu źródłow ego bez wspomagania pakietami CASE. Duże znaczenie ma IBM -ow'ski pakiet COBOL Structuring Facility, który dokonuje restrukturyzacji programów w języku COBOL. Zarówno wejściem, jak i w yjściem je st kod źródłowy COBOL-u. Drugi rodzaj restrukturyzacji ma miejsce wówczas, gdy następuje zm iana technologii przetwarzania danych w system ie, np. z przetwarzania opartego na plikach danych do użytkowania określonego system u zarządzania bazą danych. Przykładami tego rodzaju restrukturyzacji są rów nież: zmiana systemu bazy danych z hierarchicznej na relacyjną czy obiektowo zorientowaną bądź też zmiana wersji języka, w którym przygotowano oprogramowanie. Znanymi i praktycznie stosow anym i pakietam i restruk turyzacji są: • Reasoning (Reasoning Systems Inc.) • Recycle (Software Rense Company Ltd) • DISCOVER (Software Emancipation Technology TnrA
J92
I U2ży.kowanie
p nś
;
r
ku- cobol ~
pakietów restrukturyzacji programami u s u w a j ¡ ¡ w T ® * " Po pewnym okres,e użytkowania systemu zazwyczaj pojawia sie potrzeba jeg o zasadniczej zmiany, „odmłodzenia” . Wynika to ze w zgL fiw technologicznych, tj. statego rozwoju sprzętu, oprogramowania i sied kom puterow ych, oraz funkcjonalnych, tj. rozwoju firmy, zmiany jej celów strategu rynkowej , potrzeb informatycznych. Mimo tych zmian wiele składników eksploatowanego dotąd systemu(-ów) zachowuje swoją aktualność i użyteczność. W ymienić tu można choćby typowe struktury danych czy algorytm y rudym entarnych funkcji ewidencyjnych i sprawozdawczych oraz związane z nimi oprogramowanie. Zasady racjonalności pracy powodują, że zespoły twórców systemów chcą zachować te składniki istniejącego! przestarzałego systemu i odtworzyć je w nowej jego wersji. C elem m o d y fik a c ji i a d a p ta c ji zw ro tn ej lub odtwarzania jest opracow anie opisów wysokiego poziomu dla programów zastosowań użytkow anego system u. Ma ono zastosow anie w stosunku do eks ploatowanych systemów informatycznych, które nie posiadają dokumentacji, opisu oprogram ow ania systemu na wysokim poziomie albo opis ten jest nieczytelny, niespójny, niekompletny. Pakiety modyfikacji zwrotnej CASE stwarzają m ożliw ość zmiany, udoskonalenia istniejącego systemu poprzez adaptację i wykorzystanie całości lub części jego eksploatowanego dotychczas oprogram owania do nowych założeń i architektury systemu informatycznego. Również w przypadku wycofywanego z użytkowania systemu wybrane jego fragm enty m ożna odtw orzyć dzięki modyfikacji zwrotnej w nowym systemie danej dziedziny przedmiotowej. T echnicznie m odyfikacja zwrotna jest odwrotnością generowania kodu. Punkt w yjścia stanow i bowiem istniejący kod źródłowy lub definicja (schemat w ew nętrzny) bazy danych. Celem jest stworzenie pełnej dokumen tacji anality czn o —projektow ej, którą autor istniejącego oprogramowania mógłby opracow ać sam odzielnie, gdyby stosował metody i narzędzia tworzenia system ów inform atycznych. Kod źródłowy istniejącego systemu jest analizow any z w ykorzystaniem narzędzi CASE modyfikacji zwrotnej pod w zględem składni i semantyki. Dzięki temu można odtworzyć struktury danych oraz grafy przepływ u sterowania. M ogą one przybrać postać schematów blokow ych, tablic i drzew decyzyjnych, języka strukturalnego czy diagram ów struktury. Opisy te wprowadzane są do ęn cy k lo p ei systemu pakietu C A SE. Odzyskane oprogramowanie, ^ raogą posłużyć program istom do wdrażanych zmian, uzupe men i . w now ym system ie. W ten sposób następuje oprogram owania, bezpow rotnie traconych w przypadku br
193
'T
1
u,- no nj onisanvin procesie encyklopedia systemu umożliwia — onei specyfikacji sys,em u przez. różne
narzędzia CASE w
^ ^ , n f i k i system ów na niskim
poZi o S n o d " A S E projektowania, analizy i planowania pozwala na: . identyfikację głównych procesów w systemie w postaci diagramów rM*7 c?r)łvwovv danych, , .. . O^s modeli danych jako diagramów zwtązkow encj, czy dtagramow Bachmana. Rezultaty tej modyfikacji ukierunkowanej na opisy i narzędzia wysokiego poziomu nie zawsze 's ą jednoznaczne. W trakcie użytkow ania systemu, jeo0 założenia i potrzeby mogły się bowiem w ielokrotnie zm ieniać czy m ęcz analitycy i projektanci mogli popełniać błędy. Toteż uzyskane drogą modyfikacji zwrotnej specyfikacje analityczne oraz projekt należy ponownie ocenić wspólnie z użytkownikiem. Spośród narzędzi C A SE modyfikacji zwrotnej warto zwrócić uwagę na: • • • •
Pathvu produkcji XA Systems, Inspector z Language Technology, Source Code Analyser lirmy Digital, ViaCenter z ViaSoft.
Rolę pomocniczą w procedurach m odyfikacji zw rotnej pełnią inter pretery', kompilatory oraz programy usuwania błędów. W praktyce modyfikacja systemu jest zadaniem złożonym toteż wymagania twórców systemów dotyczą m ożliw ości rów noległej lub zamiennej modyfikacji. Modyfikację można przeprowadzić w dwu kierunkach [15]: zstępującym oraz wstępującym. Nosi ona m iano m odyfikacji i adaptacji kompleksowej. Pełne kom pleksowe narzędzie modyfikacji łączy cechy pakietu restrukturyzacji, m odyfikacji zw rotnej i narzędzia wspomagającego cykl życia systemu, zarówno na w ysokim ja k i niskim poziomie. Procedury modyfikacyjne w obydw u kierunkach m ogą dla danego systemu przebiegać niezależnie, równolegle lub zam iennie w sposób powiązany. Zależności te przedstawia rys. 7.7. W przypadku modyfikacji w kierunku w stępującym użytkow ane są pakiety restrukturyzacji i modyfikacji zwrotnej. O perują one na nieustrukuryzowanym kodzie eksploatowanego systemu. Pakiety C A S E modyfikacji r?Wnież wykorzystywać ustm kturyzow aną postać programów
194
Modyfikacja wstępująca Modyfikacja zstępująca Kod źródłowy nieustrukturyzowany
Nowe cele, potrzeby i zależności systemu
Pakiet restrukturyzacji
Pakiety CASE modyfikacji zwrotnej
Ustrukturyzowane programy
Specyfikacje algorytmów i struktur danych
Pakiety CASE \ wysokiego , poziomu !
Modele danych i procesów
Encyklopedia v systemu ,
Zintegrowany pakiet CASE
Pełna dokumentacja analityczno-projektowa
Oprogramowanie systemu '
^
,km ^
*4% J*4
Rys. 7.7. Modyfikacja kompleksowa - użytkowanie pakietów CASE
Nowe cele, założenia i potrzeby informatyczne w stosunku do użytkowanego system u informatycznego, inicjują modyfikację w kierunku zstępującym . Realizuje się ją za pomocą narzędzi CASE wysokiego P°ziomu. N ie m ogą to być jednak czynności izolowane. Nowe modele unych i procesów m uszą być spójne z przechowywanymi w encyklopedii systemu specyfikacjam i eksploatowanego systemu. Nowe moduły mogą wiązać się z użytkowaniem istniejącego nieustrukturyzowanego kodu, m
ii )dvtikacji zwrotnej. Tak właśnie , zatem z uruchomieniem P ^ ^ ^ p e i n a m odyfikacja kompleksowa. ! » sposób kombinowany -■ P « » » ^ pH/vvalaj;, „a generowanie, Specyfikacje zawarte w C A SE. w zajem nte powiązanych: za pomocą * n^ w an^ : cto0Wej oraz kom pletnego oprogram ow ania dokumentacji analityczno-p . SyS,™ L a k ,e n zowana powyżej modyfikacja kompleksowa może przebiegać praktycznie w środowisku jednego zintegrowanego p a k im C SE. Ziozone systemy infonna.yczne, tworzone w dłuższym okres,e. oparte są „ zróżnicowanym oprogramowaniu. Stąd sprawny w lej sytuacj, pakte, modyfikacii kompleksowej winien pozwalać na elastyczną transform ację specyfikacji pomiędzy różnymi pakietami oprogramowania. Pewne znaczenie mooa tu mieć sprzęgi pomiędzy narzędziami CASH a system am i zarządzania bazami danych czy generatorami kodów. Jednak ze względu na wysoki poziom merytoryczny wymagań niezawodności istnieje niew iele pakietów realizują cych to’zadanie. Z bardziej znanych należy w ym ienić B achm an Toolset produkcji firmy Bachman Information Systems pozw alający na tworzenie modeli danych z projektów plików i bazy danych typu IMS. Firm a ta rozwija również narzędzia pozwalające określić specyfikację system u na podstawie kodu w COBOL-u. Pakiety modyfikacji system ów są szczególnie potrzebne w związku ze zmianami zachodzącymi m.in. w am erykańskich systemach bankowych, opracowanych jeszcze w latach 1960-1980. Z użytkowaniem tych pakietów wiąże się też rozwiązanie problemu roku 2000 - Y 2K.
7.5. Kierowanie realizacją projektów Kierow'anie realizacją projektów, zwane często w skrócie kierowaniem projektami, u'ykracza poza zakres informatyki i ma zastosow anie w wielu innych dziedzinach działalności. Przed pojaw ieniem się pakietów CASE istniało już oprogramowanie wspomagające kierowanie realizacją projektów, bazujące na metodach badań operacyjnych w tym w szczególności analizy sieciowej. Pozwalają one ograniczać koszty i trudności powodowane opóźnieniami realizacji projektów poprzez ilościow e, sform alizowane p anowame i kontrolę przedsięwzięć w kategoriach czasu i zasobów, p niema te mogą być wcześniej sygnalizowane a odpo w ied n ie działania Pakiety te dołi*czano ja k * oddzielne moduły do WSpomaga.W c h cykl życia system u bądź stosowano
niezależnieyC ^ k o w a n ie ^ y 196
u ÓW informatycznych w iązało się z użytpakietów k ie ro w a n ia p ro je k ta m i. S p e c y fik a ta
dotyczy metod szacowania zasobów oraz integracji z innymi składnikami środow iska TS1 , tworzonego systemu. Otóż okazuje się, iż bardzo trud™ „szacow ne czas a zwłaszcza zasoby niezbędne do zaprojektowania systemu inform atycznego. M etody estymacji istotnie różnią się od stosowanych w odniesieniu do innych rodzajów działalności. Jednocześnie większość systemów informatycznych projektowana jest przez zespoły (grupy) robocze Dotyczy to szczególnie systemów złożonych. Stąd ogromne znaczenie ma m o ż liw o ś ć k o rz y s ta n ia z dostępu do zaso b ó w i m o d ułó w n arzęd zia oraz 7. d o k u m e n ta c ji syste m u .
Dwie głów ne funkcje realizowane przez pakiety CASE dotyczące kierow ania projektam i to: • w spom aganie sprawnej realizacji procesu projektowania i wdrażania system ów , • sterow anie zm iennym i tworzonymi w trakcie tego procesu. Pakiety C A SE dotyczące kierow ania projektam i można podzielić na [15. 53]: • planow ania i kontroli, • kierow ania konfiguracją, • sterow ania w ersjam i. W praktyce najw iększe znaczenie m ają pakiety planowania i kontroli. Pakiety k iero w an ia konfiguracją i sterow ania wersjami są z kolei charakterystyczne dla zastosow ań informatycznych. N arzędzia planow ania i kontroli wspomagają zdefiniowanie i przy gotow anie projektu, proces planow ania i kontroli zasobów (w układzie czasow ym , finansow ym , innych zasobów materialnych, kadrowym), estymację czasu i zasobów, harmonogramowanie, kierowanie i motywowanie zespołu, zarządzanie zm ianam i, ryzykiem i jakością. Najczęściej zawierają one pięć następujących funkcji: • planow anie, • szacow anie czasu i zasobów , • sym ulację skutków zm ian, • kontrolę realizacji projektu, • kom unikow anie się w zespole. _ W iodąca je s t funkcja planow ania realizacji projektu, bardzo sciste powiązana z cyklem życia systemu. Proces tworzenia systemu jest podzie ony liniowo na etapy a te z kolei hierarchicznie na funkcje, zadania i czynności różnego stopnia. N iektóre z nich stanow ią punkty przeglądu w cy u życia systemu. D o każdej czynności przyporządkowane są czas jej r e a i J , niezbędne zasoby oraz pow iązania z innymi czynnosctamt. Aby o sią, ą ten stan uporządkow ania, należy: • zidentyfikow ać poszczególne czynności,
: ; "
d
t *
%SZ
* zasoby
p 0™
1" ^
«w -
H^hnione czynności zostają powiązane w siec a następnie Wyodrębmo : n n o ś c j k ry t y c z n e , których opóźniona realizacja w y s z c z e g ó ln ić « «. q przedsięw zięcia. C zynności te wiąże P ow szechnie stosowanymi metodami w dziedzinach
Ł o w nia i kontroli systemów są metody analizy sieciow ej w tym l Ł ó l n i e PERT Pewne znaczenie wciąż mają pionierskie w tej dziedzinie o ro s i w użyciu wykresy Gantta. Opracowanie harm onogram u złożonego projektu, wymagającego integracji i koordynacji rożnych zasobów dla kolejnych czynności, bez pakietu wspom agającego kom puterow o, byłoby zadaniem czasochłonnym i trudno sterowalnym. Planowanie realizacji projektu jest bardzo scisle zw iązane z funkcją sza co w a n ia n ie zb ę d n e g o czasu i zaso b ó w '. Funkcja posługuje się na ogół trzema poziomami pomiaru czasu i zasobów, m inim alnym , najbardziej prawdopodobnym oraz maksymalnym. W łaściw a ocena czasu realizacji poszczególnych czynności i etapów wiąże się z m ożliw ością oszacow ania ich p ra c o c h ło n n o śc i. Mamy tu do czynienia z oceną specyficznej pracy informatyków w zakresie pracochłonności analizy m etodam i strukturalnymi, projektowania formatek, zestawień plików czy dialogu, programowania w konkretnym języku komputerowym. W tym aspekcie szczególnie zalecane są dwie m eto d y: metoda COCOMO i metoda analizy punktów funkcjonal nych FPA. Metoda COCOMO opracow ana przez B oehm a wiąże się z określaniem pracochłonności projektu poprzez oszacow anie liczby linii kodu źródłowego, niezbędnych dla jego realizacji oraz w ydajności programisty. Metoda FPA pozwala na szacowanie pracochłonności tw o rzo n eg o systemu poprzez ocenę lic z e b n o ś c i i z ło ż o n o ś c i wejść, w yjść, zapytań i zbiorów tworzonego systemu. Przykładami pakietów CA SE szacow ania niezbędnych zasobów' na podstawie metody analizy punktów funkcjonalnych są Project Bridge hrmy ABT oraz SPQR/20 produkcji Software P roductivity Research. Pakiety kierowania projektami w istotny sposób m ogą w spom agać proces decyzyjny kierownika i zespołu projektow ego, poprzez ocenę skutków wariantów: „co-jeśLi’*. Dzieje się tak poprzez sym ulację skutków zmian, np. restrukturyzacji kadr, opóźnień w dostawach, awarii sprzętu. Potwierdzona jest u za eżność między czasem realizacji projektu a dostępnym i zasobam i. Iw ; ^
zaso
Przeznaczonych jest na realizację projektu, czyli im bardziej
zasohóu/°SZt0W? y-’ tym szybc'ej może być on sfinalizow any. Ograniczanie skrajnościami0, wydłużame czasu realizacji projektu. Pom iędzy tymi ? Wlde “ ów rozw iązań, k tó re m ożna ocenić .asa zie symulacji określonych zm iennych, n a przykład:
m
• przedłużania czasu realizacii cyklu życia system u, '
, . “ y n n o ic, etapu lub całego
a ograniczania zasobów kadrowych, materialnych czy finansowych • w prow adzania nowych czynności. ^ ’ W w yniku analizy skutków tych zmian, można w fazie planowania dokonać wyboru najdogodniejszego ro z w ija n ia w kwestii terminów , kosztow przy określonym kryterium sprawnośei przebiegu p ro c e k Funkcja sym ulacyjna jest również bardzo użyteczna w trakcie realizacii projektu. Stwarza ona możliwość korekty projektu, przez analizę wzajemnych w pływ ów i utrzym aniu jego spójności dla zachowania wykonalności celu projektu. W tej klasie systemów pozostają pakiety CASE o charakterze doradczym . C hodzi o w spom aganie twórców systemów w doborze w łaściw ych technik czy narzędzi CASE w realizacji danej czynności (lub ich ciągu) w procesie TSI. Taki ekspertowy charakter ma np. pakiet H yperA nalyst firmy Rapid Systems Development. O pracow any i oszacowany plan kierowania projektem staje się podstawą kontroli je g o realizacji za pom ocą narzędzi CASE. W szczególności w ykonyw ane są następujące procedury: porów nanie przyjętego harm onogram u prac z bieżącą jego realizacją, sygnalizow anie problem ów potencjalnie zagrażających wykonaniu planu, m onitorow anie jeg o realizacji, zachow anie zapisów przebiegu realizacji projektu, bieżące w ydaw anie poleceń o zadaniach do wykonania przez zespół w ykonaw czy, poszczególnych jego członków, wydawanie komunikatów o przydzielaniu zasobów . W spom aganie planow ania i kontroli projektów obejmuje również moduły k o m u n ik o w a n ia się w zespole (np. przesyłanie komunikatów, pocztę elektroniczną), narzędzia osobiste, jak pakiety harmonogramowania czy arkusze kalkulacyjne oraz moduły dokumentowania wspomagające wytwarza nie dokum entacji zw iązanej z różnymi fazami cyklu życia systemu. W tym przypadku pakiety C A SE kierow ania projektami użytkuje się równolegle ze zintegrow anym oprogram ow aniem narzędziowym, np. LOTUS Notes. Drugą kategorią pakietów CASE wspomagających kierowanie projektami są narzędzia k o n tro li w e rsji p ro je k tu . Ich odrębność wynika z a tu. iz składniki system u przechodzą serię wersji zarówno w trakcie tworzenia. jak i użytkow ania. Z m iany realizuje się, gdy: • stw ierdzono błędy w projekcie systemu, • nastąpiła zm iana potrzeb bądź założeń systemu, • oprogram ow anie m usi być dostosowane do innego sprzę u
,
u
• systemtwOTzy się iteracyjnie z wykorzystaniem mełody p r o m o w a n i* £v ?
•
ffi
t
■
■
-
i
l
"4
•
■
• 199
J ™ nm iwianci klasy pakietów CASK są narzędzia ° Stamit n ^ r a e j ą Ich celem j e s t ' tworzenie system u na podstawie kierowania konfigu 14 g { to pow ażnym zagadnieniem ¿ « . ¿ h i może być p o d a n y przy gdy kazd) sktadn tworzeniu
.
-
K ierow anie ko n figu racją tradycyjnie
^mowego, a w odniesieniu do w ykorzystania dokum entów , danych tekstowych
1 i n Duże0TznanTe /.dobyty sobie, poza w ym ienionym i ju ż uprzednio, następujące pakiety CASE kierowania projektam i: • • • • •
Artemis firmy Metier. firstCASE z AGS Management Systems, Macproject produkcji Claris. Project Bridge i Project Workbench firmy ABT, Project Manager Workbench (PMW) z H oskynsa,
• Project Manager firmy DEC. Użytkowanie pakietów CASE jest szczególnie sensow ne w odniesieniu do tworzenia złożonych systemów inform atycznych, integrujących wiele modułów. Przy ewidentnych korzyściach, koszty zakupu pakietu i aktualizacji systemu są jednak wysokie.
7.6. Bieżące doskonalenie jakości system u Narzędzia CASE są bardziej ukierunkow ane na ja k o ść systemów informatycznych aniżeli na efektywność procesu TSI. Istnieje zatem potrzeba bieżącego redukowania błędów i braków w ystępujących w e wstępnych fazach cyklu życia systemu w celu osiągnięcia bardziej niezawodnych i poprawnych zastosowań. Poprzez w ery fik ację, sp raw d zan ie i testowanie następuje porównanie wyników każdej fazy TSI z zało żen iam i i specyfika cjami z lazy poprzedniej. M ożna tego dokonać p o p rzez opracowanie i testowanie prototypu. Poza prototypow aniem , typow ym i czynnościami lealizowanymi w tej klasie pakietów CA SE są: sym ulacja, testowanie, porównywanie zawartości zbiorów i program ów . K ażda z faz T S I wymaga specyficznych metod i technik bieżącego doskonalenia jak o ści. W ten sposob usuwanie błędów, braków i n ied o ciąg n ięć n ie je s t jedynie wyodrębnioną czynnością, lecz stałym składnikiem p ro cesu TSI. Spośród ar ziej znanych narzędzi doskonalenia jakości należy w ym ienić: • Evaluator firmy QA Training, • Test Manager z DEC, • XPED1TER produkcji PANSOPHIC.
7.7. Integracja i standaryzacja pakietów CASE
Złożoność zadań tworzenia systemów informatycznych w naturalny sposob skłam ała do mtegracji pakietów C ASE. W praktyce realizują e na rynku oprogram ow ania dwie koncepcje integracji pionowej i piziomêj P/ e ™ S“ Przyjęło postać zintegrowanych pakietów CASE * 07jUm,e s,ę P™ znie trarzędzia wspomagające system u od planow am a strategicznego, poprzez narzędzia wysokiego poziom u, do narzędzi niskiego poziomu. Przykładem takiego pakietu ¡est Inform ation Engineering Facility lub System Development Workbench (w raz ze sprzęgam i do baz danych i generatorów kodu). Znaczącym w zbogaceniem potencjału integracyjnego pakietu CASE są sprzęgi (ang. bridges), które łączą go z popularnymi bazami danych oraz generatorami program ów . Ideę tego typu integracji przedstawia rys. 7.S [56].
Encyklo pedia systemu
Baza danych
Inne oprogramowanie: systemy zarządzania bazami danych, języki programowania narzędzia 4 GL
Pakiet CASE
Rys. 7.8. Integracja narzędzi CASE z oprogramowanie narzędziowym
O prócz integracji pionowej pojawiła się koncepcja integracji poziomej C-CA SE (ang: component CASE), czyli integracji składnikowej. Została ona zaproponow ana przez duże firmy komputerowe, między innymi IBM i DEC. K oncepcja ta odpow iada pojęciu środowiska CASE i polega na opracowaniu standardu, do którego dostosowują się producenci oprogramowania, pragnący wejść na ry n ek danego producenta sprzętu. Integracja typu C-CASE stwarza znacznie w iększe m ożliw ości integracyjne. Przykładami są. • E xternal Source Form at (ESF) firmy IBM, • A T ools Integration Standard (ATIS), proponowana encyklopedia systemu, t S
T
^p rzed staw io n y m i w podrozdz. 7 , rodzajami paide,ów
CASH pożądana je st również integracja szersza, która “ elastyczność w przesyłaniu, a następnie użytkowaniu wymkow pracy
201
.' ofosuiacvcli w różnych fazach cyklu życia systemu różnych zespole ■. - ^ ^ mozn., następujące sytuacje w ym agaj,ce rożne narzędzia ■ ■ . narzętizia CA SE danego producenta: w y m a g a n ia cyklu życia systemu z n
a
^
S i projektami, modyfikacji i adaptacj. oraz przechowywanta danych, . przesyłanie plików - analiz, projektów, baz danych czy programów między pakietami CASE (wycinkowymi, zintegrow anym , ) na tym samym poziomie cyklu życia systemu, , . . integracja pomiędzy pakietami lub modułami CA SE w ysokiego poziomu -, oferowanymi na rynku systemami zarządzania bazami danych i genera torami kodu. dokonywana poprzez opracowanie odpow iednich sprzęgów. Spośród opracowanych technik tran sferu danych pom iędzy pakietami CASE wymienić należy przede wszystkim: . dostosowanie parametrów eksportu plików je d n e g o n arzęd zia do encyklopedii systemu drugiego lub adptację w zajem ną struktury przesy łanych plików i encyklopedii, • transfer plików w ramach standardu, opracow anego przez danego producenta oprogramowania w jego środow isku C -C A SE , • przyjęcie standardu międzynarodowego, w ypracow anego przez producen tów oprogramowania CASE i ekspertów. Podejmowane są również próby standaryzacyjne w dziedzinie pakietów CASE w aspekcie międzynarodowym. N ajw iększe znaczenie przypisuje się: • CDIF (ang. CASE Data Interchange Format ), zaproponow any przez Electronic Industries Association, • ANSI/ISO IRDS (ang. Information Resource Dictionary System) w zakresie modelowania danych.
7.8. Przykład pakietu CASE - SDW Opracowano wiele porównawczych dotyczących narzędzi CASE. Porów nania te z natury są ogólne. Ze względu na konieczność ujednolicenia tenow oceny często traci się specyfikę danego pakietu. T oteż w niniejszym ~
' U, zdecydowano się na bliższą charakterystykę pakietu SDW (ang. PakipT e n ? ' W01 ^ >enc^ ' zweryfikowanego edukacyjnie i empirycznie,
produkowany
^
^ pov/ym o tw a rty m pakietem C A S E [97], wy*
popularnym E BranCh flm iy C aP G em in i PANDATA, świecie kilkadzip^f0^ 116 W B eneluksu. D o tej p o ry sprzedano na SDM (ang System D
^ 8°
względu na s
^ M °io tej * * * $ może bye narzędziem w spom agającym również
SDW Jest ści^ e zw iązany z metodyk
inne m etodyki wybrane metody i techniki. SDW należy zaliczyć do pakietów wysokiego poziomn (ang. CASE) jed„ ¿ ' * sprzęgi do najbardziej uznanych generatorów kodów (DSA Tinset SY N O N /2), baz. danych (ORACLE, PROGRESS, INFORMIX) i'narzędzi czw artej generacji (UNIFACE, TELON, CSP). Ogólnie koncepcje pakiem SDW przedstaw ia rys. 7.9 (skróty wyjaśniono w tablicy 7.1).
Encyklopedia systemu
oprogramowanie koordynujące współpracę edytorów poszczególnych technik z encyklopedią systemu Rys. 7.9. Struktura pakietu SDW [561
C entralnym składnikiem pakietu jest encyklopedia bezpośrednio w spółpracują podstaw owe moduły e ytory 1 moduły liczba i zakres m erytoryczny są systematycznie | i m ożliw ości, autom atyzujące kolejne lec i w technik w ramach informatycznych. Aktualny zakres wspomagania metod pakietu SD W przedstaw iono w tablicy 7.1. 203
Tablica 7.1 M oduły pakiem SDW Tablica /.i. iviwiiij i
---------------------- '
___ _________ _ _ _ _ _ ----------
’
Moduł wspomaga:
JN (! / '* d
T
Organi/aiii’.' &
,'omnlnv „n.s struktury zarad zan ia orgam /acj. gospodarczej, nmcesów * niej występujących, „biegu dokumentów
(0M) '
2. Information Planing
dekompozycję funkcjonalna systemu informatycznego oraz tworzenie infoplanu. wykorzystujące macierze zależności meto dyki BSP u źv ,
3. Information Analysis (IA)
k0Wanie metodyki ISAC zwłaszcza tworzenia A-grafów
oraz I-grafów projektowanie i aktualizację modeli danych bazujących na
4. Data Modeling (DM)
5.
SDW - Function Analysis (FA)
6. Data Analysis (DA)
podejściu związków encji tworzenie modelu dynamiki dziedziny przedmiotowej poprzez hierarchie diagramów przepływu danych normalizację relacyjnych modeli danych do czwartej postaci normalnej (4 NF)
7. Prototyping (PT)
projektowanie dialogu c/.łowiek-kom puter oraz formatek i ze stawień
8. Structured Design (SD)
projektowanie struktury systemu i program ów przy użyciu diagramów struktury
9. Lano Matries (LM)
analizę i projektowanie systemów za pom ocą macierzy Lano
10. NIAM (NIAM)
metodykę NIAM opisu semantyki baz danych
11. Jackson Structures (JS)
projektowanie struktur programów i danych, wykorzystujące diagramy Jacksona
12. Process Flows(PF)
projekt logiki programu w postaci diagramów Nassi-Shneidermana
13. State Transitions (ST)
tworzenie i użytkowanie diagramów przekształceń stanów
14. Obiect Oriented Modelling (0 0 )
użytkowanie obiektowej metodyki tworzenia system ów
15. Function Point Analysis (FP)
ocenę niezbędnych zasobów kadrowych i materialnych dla wdrożenia projektowanego systemu
16. ISO 9000 (ISO)
wprowadzenie normy jakości gospodarczych
17. SAP (SAP)
18. Bridges -
in \r 19- Version Control -0. SD Write Report Generation
ISO 9000
w organizacjach
użytkowanie pakietu SAP R3 w fazach planowania,, analizy i projektowania systemu transformację modeli danych do najpopularniejszych baz danych: ORACLE, INFORMIX, PROGRES, SY B A SE, DB2 kontrolę kolejnych wersji systemu generowanie raportów i dokumentacji, w ykorzystujące zasoby przechowywane w Encyklopedii Systemu SD W
W trakcie użytkow ania pakietu wykorzystuje się technikę okien, edytor graficzny do generowania diagramów, edytor znakowy do wprowa dzania tekstu oraz rozwijane menu z ikonami. Zarówno diagramy, jak i tekst zapisywane są w encyklopedii systemu złożonej z obiektów i związków między nimi. Spójność opisów systemu jest sprawdzana w sposób bezpośredni w trakcie opracow yw ania diagramów lub na życzenie, po przygotowaniu pełnego opisu. Złam anie reguł spójności jest sygnalizowane jako błędy _ odchylenia niedopuszczalne - i jako ostrzeżenia - odchylenia, które mogą być akceptowane. Spójność utrzymywana jest również w hierarchicznie pow iązanych diagram ach. P akiet SD W m oże być użytkowany na autonomicznych stanowiskach m ikrokom puterow ych pod PC-DOS-em lub w wersji sieciowej (MS-DOS, N ET W A R E , PC-N ET, Token-Ring). T a forma umożliwia wspólną pracę zespołu projektow ego, poprzez im port/eksport danych pomiędzy lokalnymi encyklopediam i a centralną encyklopedią systemu. Stosowane są dwa rodzaje dostępu do encyklopedii - poprzez wyszukiwanie i aktuali zację. W pierw szym przypadku pożądana część encyklopedii jest ekspor tow ana z encyklopedii centralnej. W aktualizowanym trybie pracy dodat kowo następuje blokada odpowiedniej części encyklopedii centralnej.
System Development Workbench System : EXAMPLE 5 Type : Entity Relationship Diagram Name : ALMAR4
Page : 1 Version :
Author : Modified : 14-03-1996 Date : 14-03-1996
KLIENT
0
4
ZAMÓWIENIE
POZYCJA ASORTYMENTOWA
TOWAR
O F E R T A
FAKTURA
PRODUCENT
T O
W
Rys. 7.10. Model związków encji w pakiecie SD W
A R O
W
A
S ystem D eve lo p m en t W o rkb e n ch System Type Name
EXAMPLE 2 Data Flow Diagram Księgowość firm y diagram kontekstowy
Version Author
: :
D a te
: 1 4 -0 3 -1 9 9 6
umowy pracy Pracownicy **
zm odyfikowany rejestr
zaświadczenia o pracy
informacje o płacach
składek ZUS
świadectwa pracy
1. System zatrudnieniowo -płacowy
informacje o ilości rekordów zm odyfikowane rejestry
dane personalne
v informacje o pracownikach' \ ________i płacach________ \ rozporządzenia aktualizacji
deklaracje podatkowe
Urząd Skarbowy
rozporządzenia o wypłatach
Rys. 7.II. Diagram kontekstowy systemu zatrudnieniowo-płacowego
System Development Workbench System : EXAMPLE 2 Type : Data Flow Diagram Name : 1 System zatrudnieniowo-placowy
Pracownicy^ *r — ■?
dane . I 1 Ewidencja personalne pracowników
informacje o liczbie rekordów
: 1 : :
Date
: 14-03-1996
2. Ewidencja
L
dane I personalne
f
ytau
J
Dyrekcja firmy
4. Przeglą- ^ aante rejestrów
Dyrekqa firmy
\ rejestrów *n*odyf.kowani
rejmy
Dział płac informacje o płacach listy płac
Urząd
o wvntaiprh
!
!-
3. Zliczanie 1 rekordów
Page Version Author
Informacje o pracow nikach I płacach
I
6. Wyszuki-^ (iłftntft w anie ^ informacji
deklaracje podatkowe
skarbowy
7. Drukowanie
św iadectw a pracy zaśw iadczenia
etykiety
;)drosoW< raporty
y
-12. Diagram zerowy wygenerowany w pakiecie SD W
Pracownicy
U/.ytkowmk może modyfikować zablokowaną część encvklooedii Każdy moduł SDW umożliwia tworzenie, przechowywanie i wyprowadzanie standardow ych wydruków zarówno grafiki, jak i tekstu. Niestandardowe m ożliw ość, generow ania zestawień i grafiki w dowolnych przekrojach zaw iera generator raportów SD W rite (rys. 7.10-7.12). Pozwala on praktycznie generować wszystkie informacje zawarte w encyklopedii systemu Edytor tekstu SDW może natomiast wymieniać dane z innymi procesorami tekstu poprzez pliki ASCII. Tekst w formacie ASCII może być zapamiętany i przechowywany w encyklopedii systemu. Pakiet umożliwia przechowywanie kolejnych w ersji system u dzięki modułowi SDW Version Control.
7.9. Tendencje rozwoju pakietów CASE R ynek oprogram ow ania pakietów CASE jest bardzo zmienny. Niektóre produkty utrzym ują się na nim przez dłuższy czas, podczas gdy inne, m im o agresyw nych kampanii reklamowych, nie znajdują większego uznania. N iektóre produkty zm ieniają nazwę. Producenci poszczególnych pakietów łączą się, modyfikując nazwy produktów. Podana w podrozdz. 7.1 klasyfikacja cechuje się trw ałością, ale rynek oprogramowania CASE należy oceniać w edług aktualnej sytuacji, której obiektywnym odzwierciedleniem są przede w szystkim dane zaw arte na następujących stronach Internetu: • http: / /o siris.su n d erlan d . ac.uk/sst/casehom e.htm l • http: / /osiris.sunderland.ac.uk/rif/m etacase/m etacase.hom e.htm l • http: / /o s iris . suderland.ac.uk/rif/m oose.hom e.htm l • h ttp ://w w w .qucis.queensu.ca/Softw are-E ngineering/case.htm l • h ttp ://w w w .a s ta rte .c h /m t/ •
h ttp : / / w w w .y a h o o .c o m /C o m p u te rs _ a n d _ In te rn e t/S o ftw a re /d e v e lo p -
m e n t.T o o ls / • http:/ / w w w .y ah o o .co m /Com puters.and.Intem et/Softw are/Sołtw are
n
g in e e rin g / . Bieżącą inform ację rynkow ą o charakterze porównawczym opracowały różne firm y i zespoły C A SE Reports czy CASE Industry Directones oraz w ydaw nictw o periodyczne CA SE Trends. W p ierw szy m okresie pakiety CASE strukturalne. G am a tych m etod byta stopniowo wz ogacana plan o w an ie sy ste m ó w inform atycznych i reslru u r y ^ gospodarczch (B PR ). M oduły wspomagające te “ e“ ^ składnikiem pakietów C A SE. wzrostem zn aczen ia pakietów ERP (M
Bo ^
o sj<, wraz K
ZJ* " ‘w g to w adzano lub modyfi)• J zwłaszcza 207
Engineer (LBMS). Case/D esigner 2000 (O R A C LE), S oftw are through Pictures (Interactive Development Environm ents), M A E S T R O (Softlab), LOCANA (Rapid Prototyping Laboratory); • obiektowe: Object Maker (Mark V System s Ltd.). O bjectory Support Environments (Objector)' Corporation), Rational Rose (Rational), OOATool (Object International, Inc.), Bridge Point (Project T ech n o lo g y Inc.), System Architect (Popkin Software and System s), C A D R E Team work (CADRE Technologies Inc.). Lista ta naturalnie zmienia się z upływem czasu. Z atem wyrobienie sobie poglądów na temat aktualnych zastosow ań i zn aczen ia pakietów CASE wymaga skorzystania ze w skazanych w yżej źró d e ł, głównie elektronicznych. Pytania i problemy 1. Istota i generacje pakietów C A S E . 2. Składniki pakietu CASE. 3. Podstawowe kryteria klasyfikacji p a k ie tó w C A S E .
4. Zinterpretuj modei klasyfikacji pakietów CASE podstawiony na rys. 7.5. 6 Znaczeń02* ^ W odniesieniu do pakietów m odyfikacji system u. 6. Znaczenie pakietów CASE kierowania realizacją projektów.
8 Pr7 CZym
f 3 mtegraeJa 1 slandaryzacja pakietów CASE.
j.
Rozdział 8
Wdrażanie i użytkowanie systemów informatycznych
8.1. Wdrażanie systemów informatycznych Z łożone i kosztochłonne czynności planowania, analizy i projektowania system ów inform atycznych syntetyzowane są w technicznym projekcie system u, zw anym rów nież specyfikacją systemu. Dokument ten służy całem u zespołowi projektowemu, tj. analitykom, projektantom, programistom, specjalistom baz danych, profesjonalnych pakietów oprogramowania, sprzętu i sieci kom puterow ych, do rozpoczęcia kolejnej fazy w cyklu życia systemu — wdrażania systemu informatycznego. Polega ona na zbudowaniu now ego system u inform atycznego i przekazaniu go do eksploatacji. W fazie wdrażania systemu informatycznego następuje istotna jakościowa zmiana w funkcjonow aniu organizacji gospodarczej, w wymiarze zarówno technicznym , ja k i - przede w szystkim - psychologiczno-socjologicznym. W zw iązku z tym należy dążyć do zminimalizowania oporu_przed dokonyw aniem tej zm iany. Rozważyć trzeba następujące możliwości zw iększenia stopnia akceptacji wdrażanego systemu przez kierownictwo firm y i je g o przyszłych użytkow ników [75, s. 270]: • pozyskanie zaangażow ania kierow nictw a firmy, • przy jęcie zasady stopniow ego rozwoju, • elasty czn o ść w doborze param etrów projektu, • u w zględnienie aspektów socjotechnicznych. O siągnięcie skutecznego poziom u zainteresowania i zaangażowania kierow nictw a firm y w trakcie wdrażania zaprojektowanego systemu jest podstaw ow ym w arunkiem pow odzenia podjętego przedsięwzięcia. Trudno liczyć na efektyw ne poparcie kierownictwa bez podjętej znacznie wcześniej, w spółpracy w realizacji fazy planow ania metodami analizy sytuacyjnej (por. rozdz. 2). W pływ system u na sposób wykonywania indywidualnej bądź zespołow ej pracy je st oceniany i ostatecznie akceptowany przez kierow nictw o. Z asadniczym argum entem za wdrożeniem nowego systemu
209
r
nroiektowy fakt likwidacji lub znaczącego jest a ity k u lo « m v p rx ^ runkcjom)waniu tirm y. m ających w pływ na jej ° f ? KKZ
konkurencyjność. N iekiedy stopniow a. przeprow adzana
»■'m iłych zakresach zmiana może hyc łatw iejsza do ak cep ta cji zarów no
d li kierownictwa, iak , użytkowników, wziąwszy pod uw agę. ,z procesy związane z tworzeniem system ów inform atycznych m ają charakter długoterminowy. Należy jednak zaznaczyć, iż zasada ta m e m a zastosowania w p r z e p a d k u dokonywania radykalnej zmiany np. poprzez restrukturyzacje procesów gospodarczych z wykorzystaniem technologu inform atycznej (por. podrozdz. 2.6 oraz [60; 61]). Zarówno natura makroekonomicznych t m ikroekonom icznych procesów gospodarczych, jak i technologia inform atyczna zm ieniają się. T em po tych zmian jest coraz szybsze. Twórcy system ów m uszą uw zględniać aspekt elastyczności systemu. Oznacza to w praktyce tw orzenie system ów w taki sposób, aby procedury' i technologie m ogły być w ym ieniane na coraz nowocześniejsze. W praktyce jest to zadanie niełatw e, zw aży w szy trudność przewidywania trendów rozwoju w inform atyce. Jednak sam o odczucie elastyczności projektowanego systemu winno tow arzyszyć analitykom i projektantom w trakcie procesu jego tw orzenia. Proces tw o rzen ia i sam system zawierają składniki techniczne i społeczne: sprzęt, oprogram ow anie, procedury', kadry-. Istotne jest, by wdrażanie systemu przebiegało na zasadzie równoległego, zharmonizownego uwzględniania tych składników . T rak to w an ie każdego z nich bądź indywidualnie, bądź jako priorytetow ego, bez przew idyw ania wzajemnych interakcji, w znacznej mierze m oże p rzy czy n ić się do ostatecznego niepowodzenia przedsięwzięcia projektow ego. Wdrażanie^ system u informatycznego obejmuje takie czynności i zadania, jak. zakup sprzętu, instalacja bądź rozwój sieci kom puterow ej, zainstalowanie J)azy danych^^apro^ądzgnie do niej danych7~opracow anie i testowanie" -programów, zakup pakietów oprogramowania, przygoto w a n ie ^ ia ^ m e n t a cji mysiemu oraz przeszkolenie jego użytkowników. T)opiero~wówczas system ten można przekazać do eksploatacji. Czynności te m o żn a u p o r z ą d k o w a ć w następujący ciąg: _ * ż lie c ią T o r a p u t e r o tr '6 0r^
“ S^ laCja^
^
lfo ™ aty cz n e ^ ' wraz
• wdrożenie i p r a e t e s t o w a n i e ^ T d ^ ^ ^ ramowania^i J p przetestowan*e j programów, zakup pakietów
& r210
oprog-
późniejsza ich realtzacja może mieć charakter równoległy. Zainstalowanie sp rzętu , sieci kom puterow ych umożliwia podjecie prac „ad 0p X ramowaniem systemu. Parametry sprzętu i sieci ulegaj, aktualnie b a Z dynam icznym zmtanom. Wynikają z tego wnioski o potrzebie z jednd strony szybktego wdrażania systemu, a z dnrgiej - zapewnienia dokonyLanh unowoczesmen. Naturalnie niemal każda współczesna organizacji g ot podarcza postada komputerową infrastrukturę sprzętowo-sieciową toteż wdrożenie systemu komputerowego wiąże się raczej z jej unowocześnianiem; tj. m odyfikacją , adaptacją bądź poszerzaniem. Przypadki pełnej wymiany należą raczej do w yjątków . J Inna sytuacja dotyczy bazy danych, której struktury danych opracowane zostały w e w cześniejszych etapach cyklu życia systemu. Struktury te należy dostosow ać do param etrów oprogramowania obsługującego bazę danych, czyli system u zarządzania bazą danych (SZBD). Aktualnie jest to najczęściej system relacyjny, bardzo rzadko sieciowy. Dużego znaczenia nabiera podejście obiektow e, toteż na rynku oprogramowania oferowane są tzw. u niw ersalne serwery baz danych (proponowane np. przez firmy IN F0R M 1X i O R A C LE), mające charakter relacyjno-obiektowy. Wdrażając i użytkując b azy danych, można posługiwać się istniejącym oprog ram ow aniem , skoncentrow anym wokół zakupionego i zainstalowanego w cześniej SZ B D (bądź jego kolejną ulepszoną wersją). Wdrożenie bazy danych m oże oznaczać jednak konieczność zakupu nowego systemu zarządzania bazą danych wraz towarzyszącym oprogramowaniem (narzędzia czw artej g eneracji, języ k zapytań SQL, pakiety CASE). K o lejn y m istotnym składnikiem wdrażania systemu informatycznego je st je g o oprogramowanie. W trakcie tworzenia i testowania programów w ykorzystuje się zarów no zakupione pakiety oprogramowania, jak i oprog ram ow anie dedykow ane, przygotowane przez zespół programistów, a ukierun kow ane n a specyfikę danego zastosowania. W ykorzystuje się algorytmy w y sp ecyfikow ane w fazie projektow ania systemu, opisane przy użyciu diagramów struktury, Jacksona, N assi-Schneiderm ana czy Wamiera-Orra. a także za p o m o cą tablic decyzyjnych. W związku z tym pojawia się często p o trzeb a opracow ania programów integrujących pakiet) ram o w an ia z p ro g ram am i i podprogram am i dedykowanymi, a osc oprogram ow ania w firm ie tw orzy jej bibliotekę oprogramowania, zynnosc program istyczne m ogą być w znaczący sposób przyspieszone. ię 1 • w ykorzystaniu zasad prototypowania systemu; kolejne iteracje w coraz w ięk szy m w ym iarze oprogramowanie systemu, do wersji J
włącznie; • miar7P liryhe • językom czw artej generacji, ograniczającym w znacznej mierze l u b * linii kodu w program ie; 211
, i , kióre w sposób automatyczny generują na podstaw ie ^ i S s y d e m u znaczące partie kodu program u: generatory kodu są S 2 Î S ^ g r o w a t ^ ^ ó w CASE. ^ ^ ’ którego^p ró ^m ow stne moduły wymagają jedy nie adaptacji do specyfiki określonej trrmy.
m w drażania „ p ro g ra m o w a n ia je s t jeg o
zwłaszcza programów dedykow anych. R ozróżnić tu można testowanie, zw taszczt» f * n ie
•indyw idualne, dotyczące spraw dzania popraw ności poszczególnych modułów oprogramowania,
.
. zintezrowane. zwane testami akceptacyjnym t. a zw iązane z kontrolą i korektą całości oprogramowania systemu, harm onijnego w spółdziałania wszystkich jego modułów.
Ostatnimi zadaniami w fazie wdrażania system u są: testow anie i zainstalowanie. W przeciwieństwie do poprzednich testów na tym etapie chodzi o całościową, zintegrowaną kontrolę, a następnie korektę funkcjonowania wszystkich modułów i całości w drażanego system u. Testowi podlega spójność, sprawność i efektywność w spółdziałania kadry, sprzętu, sieci komputerowych, baz danych i oprogram ow ania w osiąganiu celów założonych w fazie planowania. Testowanie m oże opierać się na ściśle sformalizowanych zasadach kontroli jakości QA (ang. cjuality assurance ) lub TQM (ang. total quality management). Aby test m ógł o d być się na danych rzeczywistych, wprowadza się stosow nie do przyjętej struktury danych i parametrów' SZBD odpowiednie dane rzeczyw iste z organizacji gospodarczej do plików i bazy danych. Poszczególne pliki oraz baza danych mogą cechować się dużą liczebnością rekordów . Ich w prow adzenie jest więc czynnością czasochłonną. Zazwyczaj przynajm niej część tych danych była wcześniej zarejestrow ana i p rzech o w y w an a w postaci elektronicznej w dotychczasowym system ie lub system ach użytkow anych w' firmie. Istnieje zatem możliwość konw ersji tych p lik ó w do bazy danych wdrażanego systemu przy użyciu specjalistycznego oprogramowania. Ściśle związane z sobą są zagadnienia opracow ania dok u m en tacji dla użytkowników oraz ich szkolenia. W sposób naturalny, sto so w n ie do
^ y .ran! J m e lo d y k i’ lw o rz o n a J e s t dokumentacja system u w całym cyklu ■p ^ Iera ona °P*S m°deli w kolejnych fazach cyklu, przygotowana odDowipr|C u p0St.a(d PaPter°wej i elektronicznej, z wykorzystaniem “ ^ i? v ’ tóChniki : C h o ć « € « dokumentacji, zwłaszcza znakomita iei w L IWW' Î przy wsPółudziale użytkow ników systemu, W
profesjonalny charakte^ Tof ^ niezrozum iała ze względu na swój ez istnieje konieczność opracowania dokumentacji 212
! maK=riat‘™ szkoleniow ych, ukierunkowanych na przygotowanie użytkow nikow do sprawnej eksploatacji systemu. Szkolenia winny przygotować pracowników w pierwszej fazie do spraw nego użytkow ania zainstalowanego sprzętu, działającego zgodnie z odpow iednim system em operacyjnym . Następnie pracownicy powinni opanow ać funkcje w drażanego systemu, stosownie do specyfiki kom puteryzow anego stanow iska pracy. Przeszkolenie pracowników dużych instytucji ubezpieczeniow ych, banków czy urzędów auminisiracji administracji w w związku związku j j r ^ y ui/.ęuuw z w drażaniem system u inform atycznego jest poważnym zadaniem, realizo w anym w dłuższym okresie, wymagającym często zatrudnienia kadry sp ecjalisty czn y ch firm doradczych i szkoleniowych. Dobry program szkoleniow y w ykorzystuje zestaw y zróżnicowanych metod i fo rm 'n au czania, jak: w ykłady, rozw iązyw anie przypadków, dyskusje seminaryjne, ćw iczenia laboratoryjne, korzystanie z komputerowych samouczków, studiow anie m ateriałów szkoleniow ych oraz biuletynów lub materiałów przesyłanych Intranetem . W y k o n an ie w szystkich czynności i uzyskanie pozytywnych rezultatów testu o znacza zainstalow anie wdrażanego systemu i przekazanie go do eksploatacji użytkow nikom . Kompleksowo proces wdrażania systemu info rm aty czn eg o przedstaw iony jest na rys. 8.1.
(/
8.2. Użytkowanie, modyfikacja i adaptacja systemu, . I#**
f
O statnią fazą cyklu życia systemu jest jego użytkowanie (eksploatacja), p o w iązan e z w prow adzeniem koniecznej modyfikacji i adaptacji. Faza eksploatacji p o leg a na stałym wykorzystywaniu systemu informatycz nego do w sp o m ag an ia bieżącej działalności organizacji, przez genero w anie i do starczanie użytecznej informacji. Jest to więc faza zbierania ow oców realizacji cyklu życia systemu dzięki współdziałaniu kadry, sprzętu, sieci, oprogram ow ania i bazy danych. Na podstawie bieżących transakcji w p ro w ad za się dane do poszczególnych plików bazy danych, w w yniku czego następuje jej aktualizacja; przesyłanie i przetwarzanie danych o d b y w a się stosow nie do przyjętych algorytmów generowania form atek i zestaw ień końcow ych, odpowiedzi na zapytania dotyczące podejm o w an ia bieżących i perspektyw icznych decyzji gospodarczych A dm inistratorzy system u, w m iarę pojaw iania się potrze . ora ' j lub p rzep ro w ad zają szkolenia kadry i użytkowników. ° P ier^ ' Przyjętym p ro jek cie system u, opracow uje się harmonogram t określający sekw encję czynności, w ykonywanych bieżąco i okresóv o.
it*:
Kadry (zespół wdrożeniowy)
Systemy zarządzania bazami danych
Techniczny projekt
systemu Systemy operacyjne Języki programowania Generatory zastosowań Pakiety zastosowań klasy MRPII
Rynek sprzętu i sieci komputerowych
Wdrażanie system u informatycznego
i—---1.
—■ .......-n
I|
3.
7.
5,
Opracowanie, Zakup i Zainstalowanie integracja i instalacja i* r* i test całego przetestowanie sprzętu i sieci systemu oprogramowania komputerowej j i *
Przekazanie systemu do eksploatacji
L
2.
4.
Wdrażanie i przetestowanie bazy danych
6. Opracowanie dokumentacji systemu
Przeszkolenie użytkowników
Rys. 8.1. Proces wdrażania systemu informatycznego
Elementem tego harmonogramu jest kontrola jakości użytkowanego systemu, systemu
^
^ecyzJa 0 podjęciu m odyfikacji lub adaptacji
zW1a z ^ r SlemU rZaC^ 0 Prze^)‘e2a płynnie. Podstawowe interwencje związane z użytkowaniem systemu dotyczą: 214
. usuw ania błędów w funkcjonowaniu, zwłaszcza oprogramowania, bazy danych i sieci kom puterow ej, y
. odzyskiw ania system u (ang. recovery) po jego zawieszeniu lub upadku C zynność, pow yższe, polegające na stałym ulepszaniu technologicznym system u, jeg o pielęgnow aniu, w miarę pojawiania się braków i błędów służą m odyfikacji system u. M odyfikacja m a charakter kosmetycznych, drobnych, choć ciągłych korekt, nie zm ieniających w zasadniczy sposób zakresu funkcjonalnego i technologicznego użytkow anego systemu. Jednakże zarówno organizacja gospodarcza, ja k i jej otoczenie m ogą podlegać zmianom skokowym. W zw iązku z tym system ulega stopniowej dezaktualizacji, która może podw ażyć sensow ność użytkow ania wdrożonego systemu. W skrajnym przypadku eksploatow any system może firmie szkodzić zamiast wspomagać realizację założonych celów i zadań. Są trzy podstawowe czynniki w pływ ające na dezaktualizację systemu: • w ew nątrzorganizacyjne transform acje, wynikające ze zmiany strategii gospodarczej firm y, & zm iany w otoczeniu organizacji gospodarczej, związane przede wszystkim ze zm ian ą popytu na produkow ane wyroby lub usługi oraz ze wzmoc n ieniem roli konkurencji, • zm iany w technologii inform atycznej, które m ogą znacznie podnieść spraw ność i now oczesność posiadanej infrastruktury sprzętowo-programistycznej firm y. D w a o statn ie czynniki często stym ulują zainicjowanie przemian w ew n ątrzo rg a n izacy jn y ch . W e w szystkich tych przypadkach należy w prow adzić radykalne zm iany użytkowanego systemu informatycznego, czyli je g o a d a p ta c ję . Jej narzędziem może być restrukturyzacja procesów gospodarczych B PR (por. podrozdz. 2.6). Proces adaptacji oznacza w praktyce powtórzenie cyklu życia systemu w o d n iesieniu do określonego m odułu lub modułów wdrożonego systemu. W fazie p lan o w an ia adaptacji określa się więc problemy, cele i potrzeby, sporządza infoplan. M oże on dotyczyć w ybranego modułu lub większej liczby p ro ced u r system u. Po dokonaniu analizy, opracowuje się projekt now ego sy stem u , który zostaje wdrożony. Najbaidziej kosztowne zmiany dotyczą sprzętu, podczas gdy najbardziej czasochłonna jest adaptacja oprogram ow ania. M niejszym problem em jest restrukturyzacja czy zmiana form atów bazy danych, dokonyw ana za pom ocą program w
U żytkow anie systemu, a zwłaszcza jego wiąże się z pow ażnym i nakładami materialnymi i D o d z e i z rosnącą liczbą użytkowanych systemów w organtzacj. gospodarczej 215
alitvków i projektantów przeznacza się na coraz więcej czasu pracy an Nvdrożonych system ów koszt kosztem eksploatację. nlf ytlka^ ojek‘tONvania nowych system ów . Z ależność tę planowania, analizy i P J przedstawia rys. 8.2 l i w . s-
Czas pracy
Czas dostępny na tworzenie
analityków i j * programistów
*
*
*
*
Czas niezbędny na użytkowanie, modyfikcję i adaptację istniejących systemów
Liczba wdrożonych sytemow Rys. 8.2. Wdrożone systemy a czas eksploatacji [104. s. 363J
Wspomniana wyżej kontrola użytkowanego system u m oże m ieć postać audytu informatycznego [104. s. 363] w ykonyw anego p rzez wyspe cjalizowaną fi mię doradczą. Audyt funkcjonowania system u oznacza zebranie i ocenę informacji nt.: odpowiedniego poziom u p rzesz k o le n ia kadry, nowoczesności i adekwatności stosowanej m etodologii i technologu, racjonalności wykorzystania zasobów kadrowych i kom puterowych, poziomu satysfakcji użytkownika z eksploatowanego systemu, posiadanego i stoso wanego inioplanu oraz pełnej dokumentacji systemu, istnienia procedur udoskonalania i odzyskiwania systemu. Wyniki audytu stają się podstawą do podejmowania decyzji co do wprowadzenia zm ian w systemie informatycznym lub decyzji o jego dezaktualizacji i wycofaniu z użytkowania-
Adaptacja systemu na podstawie standardu EuroMethod z propozycją europeiskieao to rt j ' 27' k0-’arzy się przede WSZyS Najnowsza wersja a » ! ', » * m etodyki T S I (por. rozdz
Sem ce Proouremen, 216
information
T T P° f ‘S P L {ang' >), ukierunkowana jest przede wszystki
Proces adaptacji Si r Składanie Ofert Konkurs projektów Odpowiedzi (projekty) zainteresowanych organizacji Wybór dostawcy Przyznanie kontraktu
Proces Produkcji Akceptacja zestawu produktów Akceptacja stanu i planu Sterowanie zmianą kontraktu
Proces Finalizowania Akceptacja stworzonych i dostarczonych produktów Zakończenia kontraktu
Rys. 8.3. Proces adaptacji SI [40, s. 11]
efektyw ne kierow anie zakupem systemu infoimatycznego w drodze przetargu. W zw iązk u z o g rom nym i środkam i przeznaczanym i na zakup systemów 1 tech n o lo g ii inform atycznej w państw ach Unii, narzędzie typu EM ułatwia kontrolę p rzeb ieg u przedsięw zięć zw iązanych z inform atyzacją. EM, użytkow ana p raw id ło w o , pozw ala na osiągnięcie potencjalnych korzyści 217
. ni„ „ „ H e m arządzanm r>z>k W 7Ć HuroMelhod zosia przy zakupie te .
związanym z przejściem do zm ienionej sytuacji, więc w ce|u w spom agania organizacji ^ ^ tóinorodnych sytuacjach, poprzez skłanianie kosztów i czasu realizacji, zarządzania - je m ,te g o
zrozum ienia.
S zczeg ó to w e ce.e
f T s p lm a tn t w z ^ m ie g o zrozumienia m iędzy klientam i i dostaw cam i SI na otwartym międzynarodowym rynku poprzez zap ew n ien ie przew od nika. uzupełnionego zestawem pojęć i term inologii, użytkow anych w trakcie zawierania transakcji, . poprawienie trafności zakupów SI poprzez branie pod uw agę pełni sytuacji problemowej i związanego z mą ryzyka, • zapewnienie podstawy dla harmonizacji różnych m etod. Aby sprostać szybkim zmianom, w spółczesne o rg an izacje potrzebują jeszcze bardziej skutecznych i elastycznych system ów inform atycznych (SI). Adaptacja SI danej organizacji, mająca sprostać je j now ym potrzebom , jest podstawowym zadaniem, które winno być zrealizo w an e tak szybko i tak efektywnie, jak to możliwe. Ten właśnie proces je s t w spom agany przez EM. EuroMethod może być użytkow ana w całym p ro cesie zakupu, począwszy od pojawienia się potrzeb na now y lub zm o d y fik o w an y SI do sfinalizowania kontraktu, który spełnia określone w cześniej w ym agania. Z tego powodu wprowadzono pojęcie zakupu SI, które o p isu je ten proces. EuroMethod porządkuje i wspomaga proces zakupu, w szczególności strategię zakupu, relację klient-dostaw ca i zarządzanie re a liz a c ją kontraktu dla wzrostu możliwości osiągnięcia pożądanego ro zw iązan ia w ramach limitu czasu i kosztów. W EuroM ethod koncepcja ad ap tacji S I została wprowadzona, aby uwzględnić różne typy projektów , k tó re m o g ą być powiązane z systemami informatycznymi. A daptacja system u inform atycz nego może więc przybrać następujące postaci: • tworzenie systemu, • użytkowanie systemu, • projektowanie systemu, • modyfikacja i adaptacja zwrotna,
• restrukturyzacja procesów gospodarczych • instalacja systemu, • różnego rodzaju studia systemów. dowolny klient z ^ a w fa d o w T ^ p r° jekt adaP tacji SI, w którym Klient może pochodzić zarówn ** (dzieło) u d o w o ln eg o dostawcy. a dostawca może być organizacja * pubU czneg0’ j* * 1 pryw atnego, klienta. Klient i dostawra zew nętrzną lub d ziałem w organizacji ni°g ą funkcjonow ać w ró żn y ch krajach. D ° 218
A daptacja SI
Potrzeby
Zarządzanie relacją na poziomie kontraktu
Spełnienie Użytkowanie Euromethod
Projekt SI Metody x kierowania projektami
Kierowanie projektem SI Zalecenia planu Produkty Usługi
ł
Informacja Umiejętność
Tworzenie SI
Użytkowanie
Wiedza Metody N tworzenia SI
Rys. 8.4. Projekt adaptacji SI [39, s. 8]
zasto so w an ia E uroM ethod w ystarczą dw ie strony powiązane formalnym p o ro zu m ien iem o podjęciu adaptacji SI. K ontrakt może być prawnym p o ro zu m ien iem , łączącym różne organizacje, lub wewnętrznym poro zu m ien iem p o m ięd zy dw om a działam i tej samej organizacji. W celu o siąg n ięcia pełn y ch korzyści, EuroM ethod w inna być stosowana zarówno p rzez klienta, ja k i dostaw cę. Jednakże naw et jeśli je st ona użytkowana tylko p rzez je d n ą stronę, to opłaca się dzięki lepszemu planowaniu i zarząd zan iu projektam i. D la każdej postaci adaptacji SI, EuroM ethod definiuje trzy podstawowe procesy: sk ład an ia ofert, produkcji i finalizow ania (rys. 8.3). W każdym z tych p ro cesó w w ykonyw ane są pew ne typy transakcji klient-dostaw ca. T ran sak cja o b ejm u je w ym ianę w ytw orów pom iędzy klientem i dostawcą. W p ro sty ch p ro cesach zakupu, transakcje składania zamówień przebiegają w sposób zb liżo n y do kolejności przedstaw ionej na rys. 8.4. W złożonych procesach zak u p u m oże być w ięcej transakcji, takich jak: • ogłoszenie zaproszenia do zainteresowanych, odpowiedzi zainteresowanych o rg anizacji, w stępny w ybór potencjalnych dostawców;
219
• > k tó w . o d p o w ie d zi zainteresowanych organizacją
. ogłoszenie konkur^ ^ ullc kontraktu. wybór dostawcy. Pr/> «odejmowany przez zespół wykonawczy, 'projekt adaptacji ^ J oduktów i u słu g, które spełniają potrzeby Celem projektu jest dostań. . ^ Wyn[ki adaptacji systemu informatycznego znoszone przez k lie n u i(0 ^ ’ z w ykorzystaniem EuroMethod ^ o t l n w e S O ^ s ld N zee stanu początkowej przedstawia rys- 8l5,
Stan początkowy adaptacji SI_________________ Potrzeby adaptacji SI
\n\om\a\.yczr\Qqo'.
Stan początkowy systemu * * * *
r
Specyfikacje stanu początkowego systemu informatycznego
źródło informacji procesy zespół system komputerowy
Specyfikacje przyszłego systemu informatycznego
Składniki eksploatacyjne dotąd nie zainstalowane:
Plany adaptacji SI
* plan przekazania
* sprzęt * oprogramowanie * podręczniki itp.
* plany projektów
Adaptacja SI # Produkcja * Finalizowanie
Stan końcowy adaptacji SI Stan początkowy systemu informatycznego: * * * *
źródło informacji procesy zespól system komputerowy
Specyfikacje stanu końcowego systemu informatycznego
X
_
...
Mm
r Nie zainstalowane jednostki użytkowanego systemu
M k
ftm -
Plany przyszłych adaptacji SI
-
'Ś•* M i
|IM "
Rys. 8.5. Stany początkowy i końcowy adaptacji SI 141* s. 55] 220
ii'* *
1
Pytania i problem y 1 . J a k ie c z y n n ik i z w ię k s z a ją sto p ień ak ceptacji system u w drażanego w firm ie?
2. C z y n n o ś c i z w ią z a n e z w d ra ż a n ie m sy stem u inform atycznego. 3. O p ie ra ją c się na a k tu a ln y c h p u b lik acjach i zaso b ach interenetow ych, opracuj ofertę s p r z ę to w ą d la s y s te m u p ła c o w e g o średniej w ielkości firm y, z uw zględnieniem : • m ik r o k o m p u te ró w , • m in ik o m p u te r ó w , • sieci k o m p u te ro w y c h . 4. O p ra c u j s tro n ę In te rn e to w ą takiej oferty z o d p o w ied n im i odsyłaczam i. 5. P o d s ta w o w e p ro b le m y i z a sad y u ż y tk o w a n ia m o d y fik acji i adaptacji system u - wyjaśnij z a le ż n o ś c i p o m ię d z y lic z b ą tw o rz o n y c h a u ż y tk o w an y ch system ów . t).
N a c z y m p o le g a a u d y t in fo rm a ty c z n y ?
7. Ja k je s t r o z u m ia n a w E u ro M e th o d a d a p ta c ja system u. Podaj jej postaci i przykłady. 8. O c e ń p r z y d a tn o ś ć E u ro M e th o d d la p rz e p ro w a d z a n ia przetargów inform atycznych. 9. J a k ie s ą fa z y p ro c e s u ad a p tac ji SI? 10. N a p o d s ta w ie ry s. 8.4 w y ja ś n ij
re la c je
m ię d z y
k lie n te m
a d o sta w c ą sy stem u
in f o r m a ty c z n e g o . 11
Z in te r p re tu j z m ia n y d o k o n y w a n e dzięki ad aptacji SI (por. rys. 8.5).
Spis literatury
[ 1] Amadio W.. System Development. A Practical Approach. Mitchell Publishing, Santa [ 2]
| 3] [ 4] [ 5] [ 6] [ 7] [ 8] [ 9]
Cruz 1989. Analyst Workbench. Infotech State o f the Art Report, Maidenhead 1987. ANSI (1975), American National Standards Institute Study Group on Database Management Systems Interim Report. ACM 1975. Applied Prokit*Workbench, McDonnel Douglas 1990. Avison D.. Fitzgerald G.. Information Systems Development: Methodologies, Techniques and Tools, McGraw-Hill, London 1995. Avison D.. Shah H., The Information Systems Development Cycle, McGraw-Hill, London 1997. Beynon-Davies P.. Systemy baz danych, WNT, Warszawa 1998. Birrel N. D., Ould M. A., A Practical Handbook fo r Software Development, Cambridge University Press. Cambridge 1985. Blokdijk A., Blokdijk P., Planning and Design o f Information Systems, Academic Press, London 1994.
[10] Boehm B. W.. A Spiral Model o f Software Development and Enhancement, „IEEE Computer” , 1988, nr 5, s. 67-72. r n i R°n°h ° bje' t' 0rien,ed Des<8'i with Applications, Benjamin C um m ings 1991. p U Cn^ ' ' Rockan J- F- * primer on Critical Success Factors, CISR Working
.
aper’
,an
**001 Ot Management MIT 1994, nr 69.
LoiJdo^ 1995 Pard J” Examinin* Business Process Re-Engineering, Cranfield University,
New York 1996 ^ ^ ^rahant W. J., Managing the Change Process, McGraw-Hill, 115] CASE: Research Report, „CASE Research” /nfontiation Processing 205-217. *
1 9 8 9
.
* Inf ormation Design] ™ P° d red- H’ J- bugler, North Holland, Amsterdam 1986, s.
[17] Check land P., Systems ThinH „o c [18] Checkland, P., Casar A Vi ??le m s Practice, W iley, Chichester 1981. Account, Journal of A on'lleA ™ ConcePi ° f an Appreciative System: A Systematic Systems Analysis” 1986, nr 13. 222
| ] 9] Checkland P.. S o f t S y s t e m s M e t h o d o l o g y , w: R a t i o n a l A n a l y s i s f o r a P r o b l e m a t i c W o r l d , pod red. Rosenhead. Wiley, Chichester 1989. |20] Checkland P.. Scholes J„ S o f t S y s t e m s M e t h o d o l o g y i n A c t i o n . Wiley. Chichester 1990 [211 Checkland P., S y s t e m s S c i e n c e , w: S y s t e m s S c i e n c e . A d d r e s s i n g G l o b a l I s s u e s , pod red. Stowell F. A., West D., Howell J. G., Plenum Press, New York 1993 s7—10 [22] Checkland P., Hallvell S., Information Systems and Information Systems-Making Sense o f the Field, Wiley, Chichester 1998. [23] Chen P. P. S., T h e E n t i t y - R e l a t i o n s h i p M o d e l : T o w a r d a U n i f i e d V i e w o f D a t a , CISR Working Paper, Cambridge Massachusetts Institute of Technology, 1977, nr 30. [24] Coad P., Yourdon E., O b j e c t - O r i e n t e d A n a l y s i s , Yourdon Press 1991. [25] Codd E. F„ A r e l a t i o n a l M o d e l o f D a t a f o r L a r g e S h a r e d D a t a B a n k s , „Communications of the A CM ” , 1970, nr 13, s. 377-387. 126] Codd E. F., Further Normalization o f the Data Base Relational Model, w: Data Base Systems, pod red. Rustin R.. Prentice Hall, New York 1982, s. 33-64. [27] Cofta P., Graphical user Interface, Politechnika Gdańska, Gdańsk 1994. [28] Coleman D. (red), Object-Oriented Development. The FUSION Method, Prentice Hall 1994. [29] Date C. J., Wprowadzenie do baz danych, WNT, Warszawa 1981. [30] Davenport T. H., Process Innovation: Re-Engineering Work through Information Technology, Harvard Business School Press, Boston 1993. [31] Davis J. M., The Evolution o f CASE, „The SQL Database Journal” 1989, nr 2, s. 856-89. [32] Davis J. M., The Evolution o f CASE, „The SQL Database Journal” 1991, nr 3, s. 88-90. [33] DeMarco T., Structured Anaysis and Design, Yourdon Inc., New York 1978. [34] Dewitz S. D., Systems Analysis and Design and the Trrransition to Objects, McGraw-Hill, New York 1996. [35] Earl M., Management Strategies fo r Information Technology, Prentice Hall, New York 1989. [36] Elek A., Rawiński T„ Wrycza S., Charakterystyka wybranych narzędzi komputerowo wspomaganego tworzenia systemów informatycznych, Prace Badawcze Politechniki Gdańskiej 1989, nr 162. [37] Elmasri R., Navathe S. B., Fundamentals o f Database Systems, The Benjamin/Cummings, Redwood City 1994. [38] Embley D. W.. Kurtz B., Woodfield S. N ., Object-Oriented Systems Analysis, Yourdon Press 1992. [39] EUROM ETHOD Management Report, EUROMETHOD Project, Brussels 1994. [40] Introducing EUROMETHOD, EUROGROUP, EUROMETHOD Project, Brussels 1996. [41] Procurement Handbook on EUROMETHOD, ESI/FAST, Munich 1996. [42] Floyd C., A Systematic Look at Prototyping, w: Approaches to Prototyping, Sponger Verlag, Berlin-Heidelberg 1984. [43] Fuglewicz P.. Stnpor K„ Trojnar A., CASE dla ludzi. LUPUS, Warszawa 1995 [44] Gane C. P., Sarson T., Structured Systems Analysts Tools and Technique , Hall, New York 1979. [45] Caspars« W. (red.),
. P r o je k to z m w s tw o . E
.
WNT
le m e n ty
w ie d z y
Warszawa 1988. . . ono [46] Gibson M. L., The CASE Philosophy, „Byte” 1989. kwiecień, s.~ ~ . [47] Gibson M. L„ Hughes G. T„ Sytems Analysis and Destgn. A Conqtrehensne M ethodology with CASE, Boyd & Fraser 1994. 223
o
M
Champy J..
E n g in e e r in g
th e
C o r p o r a tio n .
A
M a n ife s to
fo r
B U s i m
148] Hammer M.. ' ^ . New York 1993. R e v o lu tio n . Harper Bu. " '/|wfe/WzfI
B azs
danyt
f50] Havryszkiewycz 1. T.,
" w n
Sydney IW |5 1 ] Helmench A., to n
to
S y ste m s
A n a ly s is
a n d
D e s ig n
, P ren tic e Hall
Ma„ageme„,wi*EVKOMETHOD. w: W rycza S. International C o n f e r e n c e o n In f o r m a tio n System ,
’'.Methods and Tool*. Theory and Practice” . Sopot. S epLb “ 199-6' , a rvnrae J F Valacich J. S.. Modern Systems A nalysis and Design , The [52] Hofter J. A.. u e o rc e j. Beniamin Cummings, Reading 1996. Benjamin
, T
h a n d b o o k
|53] Holloway S., biagoou
fo r
in fo r m a tio n
m a n a g e r s ,
A vebury
j.
„41 flta * , < » * O E . 2 M 5 2 7 -3 IBM 1984. 5 S ¿ f o r m a t i o n P r o c e s s i n g 8 6 . H. I. Kugler (red.). North Holland. Amsterdam 1986. [56] Information M anagement. Cap Gemini PANDATA. Gdansk Utrecht 1991. 57 Jackson M. A.. P r i n c i p l e s o f P r o g r a m D e s i g n . New York, Academic Press 1975. [58] Jackson M. A.. System Development, Prentice Hh.I1, Englewood C liffs 1983. [59| Jacobson I.. O b j e c t - O r i e n t e d S o f t w a r e E n g i n e e r i n g , A d d ison -W esley, Reading 1992. [60] Janson M.. Wrycza S.. IT in Small Companies: A Case Study o f Business Transformation in Poland, w: Proceedings of the 4th International Conference on Systems Integration, Prague 1996, s. 156-162. [61] Janson M.t Wrycza S., Information Technology as an E nabler o f Business Processes Designing During Macroeconomic Transformation , w: Business Process Modelling, pod red. Scholz-Reiter B„ Stickel E., Springer, Berlin 1996; s. 207 -217. [62] Kent W.t A Simple Guide to Five Normal Forms in Relational D atabase Theory, „Communication of the ACM” 1983, nr 26, s. 120-125. [63] Kim W., Introduction to Object-Oriented Data Bases , Massachusetts Institute of Technology. Cambridge 1990. [64] KisieLnicki J., M elody in fo rm a ty c vte , PWE, Warszawa 1981. [65] Langefors B., Theoretical Analysis o f Information System s f Philadelphia Studentlitteratur/Auerbach, Lund 1973. [66] Lockeman P. C., Mayer H. C., Information Systems D esign , Techniques and software Support, w: [55], s. 617-634. 1671
McGraw-Hill, N ew TorkTjgf‘ Approach Pre
1691 t
° ’ Ni,SS0n
^
Implementation Inf°™ 'ation Systems'
^form ation Systems Development, a Systematic
CC Ha“’ New York. 1981.
Retding l9 8 1 irt/I
Guidelines, The Apple Desktop Interface, Addison Wesley,
Fi
|75| Martin J Odell J. J Podsuw y meloil obieklm nch. WNT. Warszawa 1»7 O rZ d s im .
S y S ,m S S m 'ySlS■ S y M m S
Alfred W*"“ Ltd,
[771 Merlyn V.. Boone G.. CASE Pm lu a d e ific a tio n Model. „CASE Bulletin" I9ft9 marzec. ’ [781 Miller D„ Projektowanie metodyczne, WNT. Warszawa 1987. [79] Mu in lord E„ Effective Requirements Analysis and Systems Design: The ETHICS Method. McMillan Baringstoke 1995. [80] Niedzielska E.. Projektowanie systemow informatycznych, PWE, Warszawa 1977. [81] Nolan R. L„ Managing the Computer Resource: A Stage Hypothesis. ..Communication of the A C M " 1973, nr 7. s. 399-405. [82] Obolensky N., Practical Process Reengineering, Kogan Page. London 1995. 1831 Olle T. W.. Sol H. G., Verrijn-Stuart A. A. (red.). Information Systems Design Methodologies: a Comparative Review, NorUi Holland, Amsterdam 1982. [84] Olle T. W .. Sol H. G., Tully C. J. (red.). Information Systems Design Methodologies: a Feature Analysis, North-Holland, Amsterdam 1983. [85] Olle T. W., Verrijn-Stuart A. A., Sol H. G. (red.). Information Systems Design Methodologies, Improving the Practice, North Holland, Amsterdam 1986. [86] Ould M. A., Business Processes, Wiley 1995. [87] Pollack S. L., Hicks H. T., Harrison W. J., Tablice decyzyjne, PWN, Warszawa 1975. [88] Richards N., ADICycle - A New Unofficial Standard?, w: [95], s. 147-162. 189J Rock-Evans R., Palmer I., Data Analysis, „Computer Weekly" 1980-1981, pazdziernik-luty. [90] Rosenquist C. J., Entity Life Cycle Models and Their Applicability to Information Systems Development Life Cycles. A Framework to Information Systems Design and Implementation, „The Computer Journal" 1982, nr 2, s. 307-316. [91] Rumbaugh J. i in., Object-Oriented Modeling and Design, Prentice Hall, Englewood C liffs 1991. [92] Schlaer S., Mellor S. J., Object-Oriented Systems Analysis. Modelling the World in [93] [94] [95] [96] [97] [98] [99]
Data, Yourdon Press 1988. Schlaer S., M ellor S. J., Object Lifecycles: Modelling the World States, Yourdon Press 1992. Schnelle E., The Metaplan Method. Communication Tools fo r Planning and U am ing Groups, MetaPlan, Quickbom 1979. Spurr K„ Layzell P. (red), CASE on Trial. Wiley 1990. Stewart T. A., The Search fo r the Organization o f Tomorrow, „Fortune” z 18 maja 1992 r. System Development Workbench Manual, Cap Gemini, Utrecht 1995 Tavolato P.,Vincena K., A Prototyping Methodology and its Tool, w: Approaches to Prototyping, pod red. Budde i in.. Springer, Berlin 1984, s. 434-446. Taylor D. A ., Object-Oriented Information Systems. Planning and Implementation.
W iley, N ew York 1992. [100] Tudor D. J., Tudor I. J„ Systems Analysis and Design. NCC Biackwell. Oxford [101] Van Dam A., Post-WIMP User Interfaces, „C om m unications o f the ACM , [102] V essey I., Jarvenpaa S. L.. Tractinsky N„ * * * * * Tools and M ethodology Companions, „Communications o f the ACM
199>. k
90 105. .. [103] V ossen G., D ata Models , Database Languages and Database Manag S.
A ddison-W esley, Wokingham 1990.
5.
1104] Wcllierite J. C.. V « W N. P.. S y ste m s A u a iy x t* a n d D e s ig n , d e s , P r m i c e s Publishinf Co.. St Paul/Minneapolis 1994. ' esl ,1051 M M I I.. B e n tk y L D.. Barlow V. M.. S y s te m s A n a ly s is a n d D e s ig n M e n , , Irwin. Barr Ridge 1994. fl06J Wierzbicki T.. Informatyka w zarządzaniu* PWN, Waiszawa 1984. ¡101} Wilson B„ S y ste m : Concepts. M ethodologies a n d A p p lic a tio n s , Wiley, Chichester IQs II08J W irfs-B rock R.. W ilkerson B .. W ie n er L.. D e s ig n in g O b je c t- O r ie n te d S o ft Prentice Hall J990. a re ' 1109] W ojtkow ski G.. Wojtkowski W ., Wryczą S., Z u p a n c ic J. (red.), S y s t e m s D e v e lo M ethods fo r th e N ext C entury . Plenum Press, New York 1997. 1110] W ryczn S., Konceptualne m odelow anie baz danych, Uniwersytet Gdański, Gdańsk 11 11J Wryczą S.. Som e Com m ents a n d C o n stitu en ts o f C o n te m p o r a r y Information S D evelopm ent .M ethodologies, Proceedings of the IMACS, IFAC, IIA SA Third Inte ^ Ste>ns
Symposium on Systems Analysis and Simulation, Berlin, wrzesień 1988 s 1 Gdańsk 2] Wryczn S.. Współczesne metodyki tworzenia systemów informatycznych PTC » — „ 'o f c The ExtensionPossibilities o f T ool's Scope Supportin [113] Wrycza S.. The
a J
S
£
b
l ]FIp WG 9.1. Conference on Information Berlin, iipiec .9 8 9 . W„Hci„g Grottp , ,
S , The Content a n d Use o f A n a ly s t W o r k b e n c h in
Development.
Information System
Procedings of Xth International Conference on Systems Science, Wroclaw.
w rzesień 1989.
[115] Wrycza S., Współczesne m etodyki tw o rzen ia s y s te m ó w i n f o n n a t y c z n y c h z a r z ą d z a n ia , PTC. Gdańsk 1989. [116] Wrycza S., Roles a n d C onnections A m o n g C o n s titu e n ts o f I n fo r m a tio n S ystem s Development M ethodologies, Proceedings of The Fourth International Symposium on Computer and Information Sciences, Cesme, Turkey, październik-listopad 1989, s. 1175-1182. [117] Wrycza S.. The ISAC -D riven T ra n sitio n B e tw e e n R e q u ir e m e n ts A n a l y s i s and ER Conceptual M odelling, Information Systems, Pergamon Press 1990, nr 6, s. 603-614. [118] Wrycza S., The Im pact o f C A SE W o rk b e n ch es on T e a m w o r k o f I n fo r m a tio n S ystem s D evelopers, Proceedings of the First European Conference on C o m p u te r -S u p p o r te d Co-operative Work, London, wrzesień 1989, s. 174-189. [119] Wrycza S., A ktualne trendy k o m p u te ro w o w s p o m a g a n e g o tw o r z e n ia sy ste m ó w inform atycznych, Wiosenna Szkoła PTI, Świnoujście, maj 1990. r . ? 'C,Za 3'’ ża k ie ty C A S E - w yzw ania, m o żliw o śc i, b a r ie r y , Conference Proceedings fl?ii w H2 7 1 w
cChambre dC Commerce Franco-Polonaise, Warszawa 1991. ycza . (red.), Proceedinds o f Third International C onference on Information Sopot 1992 ™latyka dla ekonomistów, Wydawnictwo UG, Gdansk 1993. \ ' 7, Inf onnation Systems Development E ducation; Assumptions
D evel°Pers W orkbench,
[1231 Wrvcza 8
and Practirp ^
Addressing Glohal
^ n f’ ^
WeSt D ” Howe11
G- <*>■>
Systems science.
1124] Wrycza S. Plata-P^m ™ PreSS' NeW York 1993> s- 481-486. The C ase o f P o l a n d * [ n m * T" ^ ISSU**' *" Inf o r m a tio n Systems M a n a g m e n t
International Conference on nfUpanC1C J" Wrycza S., (red.) Proceeding of the Fourt s. 289-296. ormation Systems Development, Bled, wrzesień 1994,
226
[125] W r y c z a S., Z u p a n c ic J. (red ). In fo rm a tio n
S y ste m s
P r o c e e d in g s
D e v e lo p m e n t -
IS O '
96
o f
T he
F ifth
M e th o d s a n d
In te r n a tio n a l T o o ls
C o n fe r e n c e
, T heory and Practice,
S o p o t, w rz e s ie ń 1996. [126] W ry c z a S. i in.. E u ro p e a n
In fo rm a tic s
C o n fe re n c e
1127] W r y c z a S.,
o n
S y ste m s
E a ste r n
E urope
in
P r o c e e d in g s o f F ifth
S y ste m s ,
S tr u c tu r e d
S tr u c tu r e d
[130] Z u p a n c ic J., W r y c z a S. (re d ). In fo rm a tio n
a n d
C o rk , Ireland 1997, s. 1527-1528. Euromethod, G d a ń sk 1997.
d o
1128] Y o u r d o n E., C o n s ta n tin e L „ M o d e rn
C e n tr a !
In fo rm a tio n
W p ro w a d z e n ie
1129] Y o u r d o n E „ 4 5 3 -4 5 9 .
in
A n a ly s is
-
Y o u rd o n Press, N ew Y ork 1978.
, P ren tice H all, E n glew ood C liffs 1989, s.
P r o c e e d in g s
D e v e lo p m e n t
B le d . S lo v e n ia , w rz e s ie ń 1994.
D e sig n ,
IS D ' 94
o f T he
F o u rth
M e th o d s a n d
In te r n a tio n a l
T o o ls.
C o n fe r e n c e
T heory and Practice,
